Un brin de réseau — BNG et Framed-IPv6-Route

BNG et Framed-IPv6-Route

Cet article compare l'interprétation par plusieurs BNG (Cisco, Huawei, Juniper) des routes subscriber retournées en RADIUS dans les cas IPv4 (Framed-Route) et IPv6 (Framed-IPv6-Route), et ce, en s'appuyant sur des output recueillis durant des tests ou des éléments trouvés sur des documentations.

Nous allons constater que certains BNG :

considèrent les Framed-IPv6-Route comme directly connected
ne supportent pas le modèle dit « unnumbered » de l'IPv6 pour ces routes (ce qui, en un sens, contredit le point précédent)

Cet article ne critique en aucun cas les équipementiers—grâce auxquels nous opérons des réseaux—mais s'amuse de certains choix d'implémentation. De plus, la validité des résultats présentés se limite aux plateformes testées.

Cela dit…l'IPv6 appliqué au BNG ne date pas d'hier et les bizarreries constatées perdureront probablement (sur ces plateformes ou d'autres).

Plus précisément, nous allons constater :

BNG	Bizarrerie	Modèle unnumbered supporté ?
Cisco XE	Les `Framed-IPv6-Route` sont connected (contrairement aux `Framed-Route`) mais aussi static	Oui
Cisco XR	Les `Framed-IPv6-Route` sont connected mais requièrent l'adressage du subscriber (autrement dit, une gateway)	Non
Huawei	Les `Framed-IPv6-Route` ne sont pas connected et ont comme gateway une adresse anycast Subnet-Router	Non

L'article rappellera au moment opportun la signification du modèle unnumbered de l'IPv6 (qui s'oppose au modèle numbered)—c'est différent de la notion et de la commande unnumbered que vous avez pu rencontrer sur des interfaces IP. Enfin, le focus porte sur l'accès PPP mais je soupçonne des résultats similaires pour l'accès IPoE (non testé sur Cisco, testé sur Huawei et présenté ici).

Problème posé

Soit un routeur CPE raccordé en dual-stack à un BNG et qui obtient avec SLAAC un /64 pour l'adressage de son interface WAN IPv6 :

bng-framed-ipv6-route-schema — Schéma typique d'un accès dual-stack fourni à un client pro. Le CPE porte des LAN IPv4-IPv6 routés sur le même lien WAN.

Les attributs RADIUS retournés au BNG sont :


    +-------------+--------------------+----+----------------------------+
    | Username    | Attribute          | Op | Value                      |
    +-------------+--------------------+----+----------------------------+
    | subscriber1 | Framed-IP-Address  | := | 10.10.10.10                |
    | subscriber1 | Framed-IP-Netmask  | := | 255.255.255.255            |
    | subscriber1 | Framed-Route       | += | 192.168.1.0/24 0.0.0.0     |
    | subscriber1 | Framed-Route       | += | 192.168.2.0/24 0.0.0.0     |
    +-------------+--------------------+----+----------------------------+
    | subscriber1 | Framed-IPv6-Prefix | := | 2001:db8:cafe:babe::/64    |
    | subscriber1 | Framed-IPv6-Route  | += | 2001:db8:dead:c0de::/64 :: |
    | subscriber1 | Framed-IPv6-Route  | += | 2001:db8:feed:beef::/64 :: |
    +-------------+--------------------+----+----------------------------+
    | subscriber1 | VRF(*)             | := | SUBSCRIBER1-VRF            |
    +-------------+--------------------+----+----------------------------+
    (*) le nom de l'attribut varie selon les équipementiers : Cisco-AVPair, Huawei-VPN-Instance, Virtual-Router (Juniper), etc.

L'interface WAN du CPE obtient du BNG une adresse IPv4 (/32) et un préfixe IPv6 (/64). Rappelons qu'en IPv6, un BNG peut effectivement assigner un préfixe à une interface via le mécanisme SLAAC. Si la possibilité d'assigner une adresse IPv6 (/128) existe avec DHCPv6 et son option IA_NA—autant sur IPoE que sur PPP—c'est bien l'assignation d'un préfixe qui engendre des tables de routage bizarres, d'où ce choix comme point de départ ici. De plus, le scénario n'est pas rare (les CPE supportant davantage SLAAC que DHCPv6).

Les notations 0.0.0.0 et :: dans les attributs Framed-Route et Framed-IPv6-Route s'emploient fréquemment et équivalent à l'adresse du subscriber (retournée en RADIUS au BNG comme ci-dessus, ou allouée dans un pool configuré sur le BNG). Les routes véhiculées par ces attributs auront donc comme gateway l'adresse de l'interface WAN du CPE. C'est d'ailleurs obligatoire, comme le précise cette documentation Nokia :


    <gateway-address> must be the routed subscriber host IP address.
    ‟0.0.0.0” is automatically interpreted as the host IPv4 address for managed IPv4 routes.
    ‟::” and ‟0:0:0:0:0:0:0:0” are automatically interpreted as the wan-host IPv6 address for managed IPv6 routes.

    If the Framed-Route or Framed-IPv6-Route is invalid (for example because the gateway address specified
    does not match the host wan IP address or because the host bits are not zero) […]

Vous voyez sans doute déjà venir le problème. En IPv4, notre subscriber a bien une adresse avec Framed-IP-Address (pris en compte par DHCP ou PPP-IPCP). En IPv6, il n'a pas d'adresse précise car pas de Framed-IPv6-Address (pris en compte par l'option IA_NA de DHCPv6 et non SLAAC ni PPP-IPv6CP).

Noter que l'attribut Framed-Interface-Id, combiné à Framed-IPv6-Prefix, permet d'assigner une adresse précise dans le cas d'un accès PPP. Le BNG assigne à l'interface WAN du CPE : l'Interface ID avec IPv6CP, le préfixe avec SLAAC. Le CPE autoconfigure ensuite son adresse depuis ces paramètres. Selon le BNG, ça change ou non les tables de routage. Cette combinaison ne sera pas davantage discutée dans cet article.

Concrètement

L'affichage du subscriber sur un BNG donnera typiquement :


    my-imaginary-bng#show subscribers username subscriber1
    +-------------+-------+-----------------+--------------+-------------------------+
    | Username    | Type  | VRF             | IPv4 address | IPv6 prefix             |
    +-------------+-------+-----------------+--------------+-------------------------+
    | subscriber1 | PPPoE | SUBSCRIBER1-VRF | 10.10.10.10  | 2001:db8:cafe:babe::/64 |
    +-------------+-------+-----------------+--------------+-------------------------+

Sans même parler de contexte BNG—c'est-à-dire, en voyant le CPE et le BNG comme de simples routeurs—nous nous attendons à la table de routage IPv4 suivante sur le BNG :


    my-imaginary-bng#show routing-table ipv4 vrf SUBSCRIBER1-VRF
    +----------------+-------------+----------+
    | Destination    | Gateway     | Distance |
    +----------------+-------------+----------+
    | 10.10.10.10/32 | [connected] | 0        | # from Framed-IP-Address := 10.10.10.10
    | 192.168.1.0/24 | 10.10.10.10 | 1        | # from Framed-Route += 192.168.1.0/24 0.0.0.0
    | 192.168.2.0/24 | 10.10.10.10 | 1        | # from Framed-Route += 192.168.2.0/24 0.0.0.0
    +----------------+-------------+----------+

Dans un accès PPP, le BNG affiche effectivement l'adresse du pair comme connected :


    xr-bng#show route vrf SUBSCRIBER1-VRF ipv4 subscriber

    A    10.10.10.10/32 is directly connected, 00:01:14, BE1.2.pppoe493

Tout comme dans un accès IPoE :


    xr-bng#show route vrf SUBSCRIBER1-VRF ipv4 subscriber

    A    10.10.10.10/32 is directly connected, 00:06:03, BE1.2.ip3

Et cela fait complètement sens : l'adresse—non portée par le BNG mais par le CPE en face—est bien directement attachée au lien. Ce comportement se simule même, comme ci-dessous, sur de l'ancien matériel (Cisco 2691) jouant ici le rôle de BNG.

Accès PPP (sur interface série) :


    old-bng#show ip route

    C    10.10.10.10 is directly connected, Serial1/0 # adresse du pair PPP (interface WAN du CPE)
    C    10.11.11.11 is directly connected, Loopback0

Accès IPoE :


    old-bng#show ip route

    C    10.10.10.0/24 is directly connected, GigabitEthernet0/0   # LAN /24 du serveur DHCP
    L    10.10.10.254/32 is directly connected, GigabitEthernet0/0 # adresse du serveur DHCP

    old-bng#show ip cef
    Prefix               Next Hop             Interface
    10.10.10.0/24        attached             GigabitEthernet0/0
    10.10.10.10/32       attached             GigabitEthernet0/0 # adresse assignée à l'interface WAN du CPE
    10.10.10.254/32      receive              GigabitEthernet0/0
    (…)

Souvenez-vous par exemple de l'article sur RIP : c'est en effet le résultat obtenu sur les routeurs de l'IGP. En particulier ici, les deux LAN IPv4 ne sont pas connected mais ont bien une gateway correspondant à l'adresse de l'interface WAN du CPE—et leur distance a aussi été incrémentée. Ceci nous est trivial.

Mais…quid des LAN IPv6 ? quelle va être la gateway ? sachant que le CPE n'a pas d'adresse IPv6 connue du BNG mais seulement un préfixe assigné. Allons-nous obtenir la table de routage IPv6 suivante (incorrecte) ?


    my-imaginary-bng#show routing-table ipv6 vrf SUBSCRIBER1-VRF
    +-------------------------+-------------------------+----------+
    | Destination             | Gateway                 | Distance |
    +-------------------------+-------------------------+----------+
    | 2001:db8:cafe:babe::/64 | [connected]             | 0        | # from Framed-IPv6-Prefix := 2001:db8:cafe:babe::/64
    | 2001:db8:dead:c0de::/64 | 2001:db8:cafe:babe::/64 | 1        | # from Framed-IPv6-Route += 2001:db8:dead:c0de::/64 ::
    | 2001:db8:feed:beef::/64 | 2001:db8:cafe:babe::/64 | 1        | # from Framed-IPv6-Route += 2001:db8:feed:beef::/64 ::
    +-------------------------+-------------------------+----------+

Ce problème a sans doute poussé les BNG à considérer les Framed-IPv6-Route comme connected. Et, par soucis d'homogénéité je devine, même les Framed-Route pour des modèles plus récents. Regardons maintenant comment les BNG s'en sortent.

Cisco XE


    xe-bng#show subscriber session

    Uniq ID Interface    State    Service     Up-time  TC Ct. Identifier
    172     Vi2.1        authen   Lterm       00:00:11 0      subscriber1

    xe-bng#show ip route vrf SUBSCRIBER1-VRF

    C     10.10.10.10 is directly connected, Virtual-Access2.1 # from Framed-IP-Address := 10.10.10.10
    U     192.168.1.0/24 [1/0] via 10.10.10.10                 # from Framed-Route += 192.168.1.0/24 0.0.0.0
    U     192.168.2.0/24 [1/0] via 10.10.10.10                 # from Framed-Route += 192.168.2.0/24 0.0.0.0

    xe-bng#show ipv6 route vrf SUBSCRIBER1-VRF

    C   2001:DB8:CAFE:BABE::/64 [0/0] via Virtual-Access2.1, directly connected # from Framed-IPv6-Prefix := 2001:db8:cafe:babe::/64
    U   2001:DB8:DEAD:C0DE::/64 [1/0] via Virtual-Access2.1, directly connected # from Framed-IPv6-Route += 2001:db8:dead:c0de::/64 ::
    U   2001:DB8:FEED:BEEF::/64 [1/0] via Virtual-Access2.1, directly connected # from Framed-IPv6-Route += 2001:db8:feed:beef::/64 ::

    Codes: C - connected, U - per-user static route

La table de routage IPv4 est bien celle attendue :

L'adresse IPv4 assignée avec Framed-IP-Address est une route connected
Les Framed-Route ne sont pas connected et ont comme gateway cette adresse

Mais la table de routage IPv6 montre que :

Le préfixe IPv6 assigné avec Framed-IPv6-Prefix est une route connected (ok)
Les Framed-IPv6-Route sont connected et n'ont pas d'adresse comme gateway !

Avec comme seul affichage la table de routage IPv6 sans les commentaires, nous distinguerions difficilement le Framed-IPv6-Prefix des Framed-IPv6-Route. La distance reste le seul discriminant. Nous voyons d'ailleurs des routes connected avec une distance de 1. L'aspect connected des Framed-IPv6-Route trouve sans doute sa raison dans l'assignation d'un préfixe au subscriber : le BNG ne peut en déduire une gateway.


    xe-bng#show ip route vrf SUBSCRIBER1-VRF 10.10.10.10
    Routing entry for 10.10.10.10/32
      Known via "connected", distance 0, metric 0 (connected, via interface)
      Routing Descriptor Blocks:
      * directly connected, via Virtual-Access2.1

    xe-bng#show ip route vrf SUBSCRIBER1-VRF 192.168.1.0
    Routing entry for 192.168.1.0/24
      Known via "static", distance 1, metric 0
      Routing Descriptor Blocks:
      * 10.10.10.10

    xe-bng#show ip route vrf SUBSCRIBER1-VRF 192.168.2.0
    Routing entry for 192.168.2.0/24
      Known via "static", distance 1, metric 0
      Routing Descriptor Blocks:
      * 10.10.10.10

De plus, si le détail des routes IPv4 ci-dessus est cohérent, celui des routes IPv6 ci-dessous se révèle intriguant : les Framed-IPv6-Route sont à la fois connected et static. En réalité, l'un n'empêche pas l'autre et cette combinaison—que Cisco nomme Directly Connected Static Routes—arrive lorsque le routeur (BNG) positionne l'une de ses interfaces comme gateway d'une route statique (per-user ici).


    xe-bng#show ipv6 route vrf SUBSCRIBER1-VRF 2001:DB8:CAFE:BABE::/64
    Routing entry for 2001:DB8:CAFE:BABE::/64
      Known via "connected", distance 0, metric 0, type connected
      Routing paths:
        directly connected via Virtual-Access2.1

    xe-bng#show ipv6 route vrf SUBSCRIBER1-VRF 2001:DB8:DEAD:C0DE::/64
    Routing entry for 2001:DB8:DEAD:C0DE::/64
      Known via "static", distance 1, metric 0, type per-user
      Routing paths:
        directly connected via Virtual-Access2.1

    xe-bng#show ipv6 route vrf SUBSCRIBER1-VRF 2001:DB8:FEED:BEEF::/64
    Routing entry for 2001:DB8:FEED:BEEF::/64
      Known via "static", distance 1, metric 0, type per-user
      Routing paths:
        directly connected via Virtual-Access2.1

Il n'empêche qu'une différence de traitement apparait clairement entre les Framed-Route et Framed-IPv6-Route. Nous pouvons supposer qu'une partie du code implémentant IPv4 a été reprise puis adaptée avec un peu de bricolage pour le besoin IPv6 apparu plus tard.

Un point fort de XE : le modèle unnumbered

Le constat du connected pour les Framed-IPv6-Route lève une question : pourquoi s'embêter à adresser l'interface WAN du CPE ? Elle joue le rôle de gateway pour ces routes ; or, nous venons de voir leur aspect connected. Autant se contenter de l'adressage link-local par défaut de l'IPv6.

Le TR-177 du Broadband Forum définit ainsi le modèle unnumbered par opposition au modèle numbered :


    Numbered WAN model     The WAN interface of the RG has its own IPv6 GUA.
    Unnumbered WAN model   The WAN interface of the RG does not have its own IPv6 GUA.

Le RIPE-690 l'évoque également :


    Some operators decide to leave the WAN link to the end-user CPE unnumbered which
    means no GUA, so only link-local addresses are used at both ends of the link.

Schématiquement :

bng-framed-ipv6-route-unnumbered — Les LAN IPv6 portés par le CPE sont routés sur le lien WAN laissé unnumbered (adressage link-local par défaut de l'IPv6).

Les attributs RADIUS IPv6 du subscriber se limitent alors à :


    +-------------+--------------------+----+----------------------------+
    | Username    | Attribute          | Op | Value                      |
    +-------------+--------------------+----+----------------------------+
    | subscriber1 | Framed-IPv6-Prefix | := | 2001:db8:cafe:babe::/64    |
    | subscriber1 | Framed-IPv6-Route  | += | 2001:db8:dead:c0de::/64 :: |
    | subscriber1 | Framed-IPv6-Route  | += | 2001:db8:feed:beef::/64 :: |
    +-------------+--------------------+----+----------------------------+

L'opérateur ne s'encombre plus de l'allocation des /64 pour les Framed-IPv6-Prefix dans son IPAM et les OPEX (Operating Expense) s'en retrouvent réduites. Cela ne constitue qu'une étape dans un processus, certes, mais une étape plus une autre…sans oublier la libération pour le déprovisioning.

Table de routage IPv6 résultante :


    xe-bng#show ipv6 route vrf SUBSCRIBER1-VRF

    C   2001:DB8:CAFE:BABE::/64 [0/0] via Virtual-Access2.1, directly connected # from Framed-IPv6-Prefix := 2001:db8:cafe:babe::/64
    U   2001:DB8:DEAD:C0DE::/64 [1/0] via Virtual-Access2.1, directly connected # from Framed-IPv6-Route += 2001:db8:dead:c0de::/64 ::
    U   2001:DB8:FEED:BEEF::/64 [1/0] via Virtual-Access2.1, directly connected # from Framed-IPv6-Route += 2001:db8:feed:beef::/64 ::

Pour preuve du bon fonctionnement, j'ai simplement ping un des LAN IPv6 (Framed-IPv6-Route) depuis le BNG :


    xe-bng#ping vrf SUBSCRIBER1-VRF 2001:db8:feed:beef::1

    Sending 5, 100-byte ICMP Echos to 2001:DB8:FEED:BEEF::1, timeout is 2 seconds:
    !!!!!
    Success rate is 100 percent (5/5), round-trip min/avg/max = 21/21/22 ms

(La requête ICMPv6 est sourcée avec l'adresse de la Loopback de terminaison du subscriber—absente des attributs RADIUS car non pertinent ici.)

Conclusion : XE supporte nativement le modèle unnumbered pour les Framed-IPv6-Route.

Cela peut sembler logique et évident. Mais sachez que Cisco XR et Huawei—et sans doute d'autres BNG—ne le supportent pas et requièrent l'adressage de l'interface WAN du CPE (autrement dit, une gateway) afin de prendre en compte les Framed-IPv6-Route, ce qui contredit l'aspect connected.

Cisco XR


    xr-bng#show subscriber session all username

    Username             Interface              State   Subscriber IP Addr / Prefix
                                                        LNS Address (Vrf)
    --------------------------------------------------------------------------------
    subscriber1          BE1.2.pppoe493         AC      10.10.10.10 (SUBSCRIBER1-VRF)             # from Framed-IP-Address := 10.10.10.10
                                                        2001:db8:cafe:babe::/64 (SUBSCRIBER1-VRF) # from Framed-IPv6-Prefix := 2001:db8:cafe:babe::/64

    xr-bng#show route vrf SUBSCRIBER1-VRF ipv4 subscriber

    A    10.10.10.10/32 is directly connected, 00:01:14, Bundle-Ether1.2.pppoe493 # from Framed-IP-Address := 10.10.10.10
    A    192.168.1.0/24 is directly connected, 00:01:14, Bundle-Ether1.2.pppoe493 # from Framed-Route += 192.168.1.0/24 0.0.0.0
    A    192.168.2.0/24 is directly connected, 00:01:14, Bundle-Ether1.2.pppoe493 # from Framed-Route += 192.168.2.0/24 0.0.0.0

    xr-bng#show route vrf SUBSCRIBER1-VRF ipv6 subscriber

    A    2001:db8:cafe:babe::/64 is directly connected 00:01:17, Bundle-Ether1.2.pppoe493 # from Framed-IPv6-Prefix := 2001:db8:cafe:babe::/64
    A    2001:db8:dead:c0de::/64 is directly connected 00:01:17, Bundle-Ether1.2.pppoe493 # from Framed-IPv6-Route += 2001:db8:dead:c0de::/64 ::
    A    2001:db8:feed:beef::/64 is directly connected 00:01:17, Bundle-Ether1.2.pppoe493 # from Framed-IPv6-Route += 2001:db8:feed:beef::/64 ::

    Codes: AC - Activated, A - access/subscriber


    xr-bng#show subscriber session all username

    Username             Interface              State   Subscriber IP Addr / Prefix
                                                        LNS Address (Vrf)
    --------------------------------------------------------------------------------
    0cd8.a0c6.5c00       BE1.2.ip3              AC      10.10.10.10 (SUBSCRIBER1-VRF) # from Framed-IP-Address := 10.10.10.10


    xr-bng#show route vrf SUBSCRIBER1-VRF ipv4 subscriber

    A    10.10.10.10/32 is directly connected, 00:06:03, Bundle-Ether1.2.ip3 # from Framed-IP-Address := 10.10.10.10
    A    192.168.1.0/24 [1/0] via 10.10.10.10, 00:06:03                      # from Framed-Route += 192.168.1.0/24 0.0.0.0
    A    192.168.2.0/24 [1/0] via 10.10.10.10, 00:06:03                      # from Framed-Route += 192.168.2.0/24 0.0.0.0

    Codes: AC - Activated, A - access/subscriber

L'output ci-dessus est uniquement pour comparaison avec l'IPv4 sur PPP. Attributs RADIUS utilisés :


    +----------------+--------------------+----+----------------------------+
    | Username       | Attribute          | Op | Value                      |
    +----------------+--------------------+----+----------------------------+
    | 0cd8.a0c6.5c00 | Framed-IP-Address  | := | 10.10.10.10                |
    | 0cd8.a0c6.5c00 | Framed-IP-Netmask  | := | 255.255.255.0              |
    | 0cd8.a0c6.5c00 | Framed-Route       | += | 192.168.1.0/24 0.0.0.0     |
    | 0cd8.a0c6.5c00 | Framed-Route       | += | 192.168.2.0/24 0.0.0.0     |
    +----------------+--------------------+----+----------------------------+
    | 0cd8.a0c6.5c00 | Cisco-AVPair       | := | ip:vrf-id=SUBSCRIBER1-VRF  |
    +----------------+--------------------+----+----------------------------+

Ici, c'est plus direct : les Framed-Route et Framed-IPv6-Route sont toutes connected ! La gestion a comme été unifiée suite à la différence visible sur XE. Sans les commentaires, impossible de distinguer visuellement l'origine des routes (en terme d'attributs RADIUS). Le détail confirme l'aspect connected :


    xr-bng#show route vrf SUBSCRIBER1-VRF ipv4 10.10.10.10/32
    Routing entry for 10.10.10.10/32
      Known via "subscriber PPP_SUBSCR", distance 2, metric 0 (connected)
      Routing Descriptor Blocks
        directly connected, via Bundle-Ether1.2.pppoe493

    xr-bng#show route vrf SUBSCRIBER1-VRF ipv4 192.168.1.0/24
    Routing entry for 192.168.1.0/24
      Known via "subscriber PPP_SUBSCR", distance 1, metric 0 (connected)
      Routing Descriptor Blocks
        directly connected, via Bundle-Ether1.2.pppoe493

    xr-bng#show route vrf SUBSCRIBER1-VRF ipv4 192.168.2.0/24
    Routing entry for 192.168.2.0/24
      Known via "subscriber PPP_SUBSCR", distance 1, metric 0 (connected)
      Routing Descriptor Blocks
        directly connected, via Bundle-Ether1.2.pppoe493


    xr-bng#show route vrf SUBSCRIBER1-VRF ipv6 2001:db8:cafe:babe::/64
    Routing entry for 2001:db8:cafe:babe::/64
      Known via "subscriber IPV6ND_SUBSCR", distance 2, metric 0 (connected)
      Routing Descriptor Blocks
        directly connected, via Bundle-Ether1.2.pppoe493

    xr-bng#show route vrf SUBSCRIBER1-VRF ipv6 2001:db8:dead:c0de::/64
    Routing entry for 2001:db8:dead:c0de::/64
      Known via "subscriber", distance 2, metric 0 (connected)
      Routing Descriptor Blocks
        directly connected, via Bundle-Ether1.2.pppoe493

    xr-bng#show route vrf SUBSCRIBER1-VRF ipv6 2001:db8:feed:beef::/64
    Routing entry for 2001:db8:feed:beef::/64
      Known via "subscriber", distance 2, metric 0 (connected)
      Routing Descriptor Blocks
        directly connected, via Bundle-Ether1.2.pppoe493

Les valeurs des distances diffèrent de XE. La Framed-IP-Address possède une distance de 2 et les Framed-Route de 1—je m'attendais à l'inverse. Pour le cas IPv6, les routes possèdent toutes une distance de 2—je m'attendais à 1 pour le Framed-IPv6-Prefix.

Étonnamment, d'après mes tests, XR ne supporte pas le routage des Framed-IPv6-Route sur un lien WAN unnumbered, contrairement à XE. Sans l'attribut Framed-IPv6-Prefix, les routes sont tout bonnement ignorées—je n'ai malheureusement pas de debug à donner pour preuve.

L'adressage de l'interface WAN du CPE devient alors obligatoire pour charger de telles routes. Une contradiction saute aux yeux : les routes sont connected ⇒ pas besoin de gateway ⇒ le BNG requiert l'adressage de l'interface WAN du CPE (qui joue le rôle de gateway).

Cette documentation Nokia semble évoquer la même contrainte :


    The route included in the Framed-IPv6-Route attribute is accepted as a managed route
    only if its next hop is a WAN host (DHCPv6 IA-NA, SLAAC, or /128 data-triggered).

Autrement dit—tout du moins je l'interprète ainsi—le BNG charge les routes à condition que le subscriber soit adressé (par SLAAC, comme dans notre cas, ou par DHCPv6 et son option IA_NA). Étrangement, le BNG Huawei testé impose la même condition.

Et pourtant ça tourne

J'ai réalisé un test simple qui montre bien que l'unnumbered fonctionne tout de même. Il suffit de désactiver l'autoconfiguration d'adresse sur le CPE, ce qui laisse son interface WAN dans l'adressage link-local par défaut (j'ai redémarré le CPE pour enlever tout cache potentiel) :


    cpe#sho run int Dialer1

    interface Dialer1
     mtu 1492
     ip address negotiated
     encapsulation ppp
     dialer pool 1
     ipv6 address autoconfig default # le CPE ignore maintenant le préfixe annoncé dans les RA envoyés par le BNG
     ipv6 enable
     ppp chap hostname subscriber1
     ppp chap password my-password
    end

    cpe#sho ipv6 int brief

    Dialer1                [up/up]
        FE80::ED8:A0FF:FEC6:5C00
        2001:DB8:CAFE:BABE:ED8:A0FF:FEC6:5C00 # le CPE n'autoconfigure plus son adresse GUA

    cpe#conf t
    cpe(config)#ipv6 route ::/0 Dialer1 # ajout d'une route par défaut (car "autoconfig default" désactivé plus haut)
    cpe(config)#do sho ipv6 route

    S   ::/0 [1/0] via Dialer1, directly connected
    ND  ::/0 [2/0] via FE80::72E4:22FF:FE54:C4EA, Dialer1
    NDp 2001:DB8:CAFE:BABE::/64 [2/0] via Dialer1, directly connected
    L   2001:DB8:CAFE:BABE:ED8:A0FF:FEC6:5C00/128 [0/0] via Dialer1, receive
    C   2001:DB8:FEED:BEEF::/64 [0/0] via Loopback0, directly connected
    L   2001:DB8:FEED:BEEF::1/128 [0/0] via Loopback0, receive
    L   FF00::/8 [0/0] via Null0, receive

    Codes: C - Connected, L - Local, S - Static

Ci-dessus, le CPE n'autoconfigure plus son interface WAN dans le préfixe 2001:db8:cafe:babe::/64 assigné par le BNG et reste unnumbered. Le CPE ignore le préfixe annoncé par le BNG dans les messages RA—ce qui, soit dit en passant, illustre bien l'aspect stateless de SLAAC : le BNG annonce le préfixe et c'est tout ; il ne s'assure pas de sa prise en compte effective par le CPE.

Exécutons maintenant un ping vers un des LAN IPv6 (Framed-IPv6-Route) depuis le BNG :


    xr-bng#ping vrf SUBSCRIBER1-VRF 2001:db8:feed:beef::1

    Sending 5, 100-byte ICMP Echos to 2001:db8:feed:beef::1, timeout is 2 seconds:
    !!!!!
    Success rate is 100 percent (5/5), round-trip min/avg/max = 21/22/24 ms

(La requête ICMPv6 est sourcée avec l'adresse de la Loopback de terminaison du subscriber—absente des attributs RADIUS car non pertinent ici.)

Conclusion : le ping tourne même si l'interface WAN du CPE reste unnumbered. Le Framed-IPv6-Prefix, bien que demandé et interprété côté BNG, ne sert finalement à rien.

En d'autres termes, le BNG impose l'adressage de l'interface WAN du CPE sans vraie raison, sinon pour un besoin lié à son implémentation. Le même comportement s'observe chez Huawei sur des accès PPP et IPoE.

D'ailleurs, les `Framed-Route` sont aussi connected sur XR donc…

Donc la même question qu'en IPv6 se pose : pourquoi s'embêter à adresser l'interface WAN du CPE en IPv4 ? Nous pouvons toujours avancer que le BNG perçoit la Framed-IP-Address comme un prérequis pour signifier l'IPv4-awareness du lien WAN (et ainsi dérouler IPCP dans le cas PPP).

Mais IPv6 possède cette caractéristique qu'il profite d'un adressage link-local par défaut (également valide sur PPP avec IPv6CP) ; par conséquent, l'IPv6-awareness du lien WAN devient implicite et l'adressage du subscriber ne devrait donc plus être obligatoire—comme testé avec succès sur XE.

Le comportement décrit ci-dessus se vérifie même sur de l'ancien matériel (Cisco 2691) avec une interface série PPP (le routeur joue le rôle de BNG) :


    old-bng#debug ip route

    #
    # 1 Aucune adresse IPv4 assignée à l'interface Serial1/0
    # ⇒ IPv4CP non exécuté et le lien n'est pas IPv4-aware
    #

    old-bng#sho run int s1/0

    interface Serial1/0
     no shutdown
     encapsulation ppp
     no ip address

    # Ajout de routes IPv4 vers le CPE (pour simuler des Framed-Route)
    old-bng(config)#ip route 192.168.10.0 255.255.255.0 Serial1/0
    old-bng(config)#ip route 192.168.20.0 255.255.255.0 Serial1/0

    # Les routes IPv4 ajoutées ci-dessous n'apparaissent pas encore
    old-bng#sho ip route

    old-bng#

    #
    # 2 Assignation d'une adresse IPv4 à l'interface Serial1/0
    # ⇒ IPv4CP exécuté et le lien devient IPv4-aware
    #

    old-bng(config)#int s1/0
    old-bng(config-if)#ip address 1.1.1.1 255.255.255.0
    *Mar  1 00:42:33.903: RT: add 1.1.1.0/24 via 0.0.0.0, connected metric [0/0]
    *Mar  1 00:42:34.907: RT: add 192.168.10.0/24 via 0.0.0.0, static metric [1/0]
    *Mar  1 00:42:34.911: RT: add 192.168.20.0/24 via 0.0.0.0, static metric [1/0]

    # Les routes IPv4 apparaissent aussitôt
    old-bng#sho ip route

    C    1.1.1.0/24 is directly connected, Serial1/0
    S    192.168.10.0/24 is directly connected, Serial1/0
    S    192.168.20.0/24 is directly connected, Serial1/0

    Codes: C - connected, S - static


    old-bng#debug ipv6 route

    #
    # 1 Aucune adresse IPv6 assignée à l'interface Serial1/0
    # ⇒ IPv6CP non exécuté et le lien n'est pas IPv6-aware
    #

    old-bng#sho run int s1/0

    interface Serial1/0
     no shutdown
     encapsulation ppp
     no ip address

    # Ajout de routes IPv6 vers le CPE (pour simuler des Framed-IPv6-Route)
    old-bng(config)#ipv6 route 2001:db8:cafe:babe::/64 Serial1/0
    old-bng(config)#ipv6 route 2001:db8:feed:beef::/64 Serial1/0

    # Les routes IPv6 ajoutées ci-dessous n'apparaissent pas encore
    old-bng#sho ipv6 route

    old-bng#

    #
    # 2 Assignation d'une adresse Activation de l'IPv6 sur l'interface Serial1/0
    # ⇒ IPv6CP exécuté et le lien devient IPv6-aware
    #

    old-bng(config)#int s1/0
    old-bng(config-if)#ipv6 enable
    *Mar  1 00:45:03.879: IPv6RT0: connected, Route add FF00::/8 [new]
    *Mar  1 00:45:03.887: IPv6RT0: static, Route add 2001:DB8:FEED:BEEF::/64 [new]
    *Mar  1 00:45:03.891: IPv6RT0: static, Route add 2001:DB8:CAFE:BABE::/64 [new]

    # Les routes IPv6 apparaissent aussitôt
    old-bng#sho ipv6 route

    S   2001:DB8:CAFE:BABE::/64 [1/0] via ::, Serial1/0
    S   2001:DB8:FEED:BEEF::/64 [1/0] via ::, Serial1/0
    L   FF00::/8 [0/0] via ::, Null0

    Codes: C - connected, S - static, L - local

Nous retrouvons précisément le comportement décrit, à savoir :

Obligation d'assigner une adresse IPv4 à l'interface pour rendre le lien IPv4-aware et charger les routes IPv4.
Il suffit bien d'activer IPv6 sur l'interface pour charger les routes IPv6 !

Et nul besoin d'adjoindre une adresse IPv6 à l'interface : l'adresse link-local suffit (modèle unnumbered), comme elle le devrait sur les BNG.

Huawei

Sur BNG Huawei, j'ai pu tester davantage de combinaisons avec l'attribut Framed-IPv6-Route :

Combinaisons testées sur le BNG Huawei (cela peut paraître beaucoup mais une symétrie se dessine dans les output entre les différents cas).
Accès	Attribut RADIUS	Mécanisme ou protocole associé
PPP	Framed-IPv6-Prefix	SLAAC
	Delegated-IPv6-Prefix	DHCPv6 avec l'option `IA_PD`
	Framed-IPv6-Address	DHCPv6 avec l'option `IA_NA`
IPoE	Framed-IPv6-Prefix	SLAAC
	Delegated-IPv6-Prefix	DHCPv6 avec l'option `IA_PD`
	Framed-IPv6-Address	DHCPv6 avec l'option `IA_NA`

Comme Cisco XR, le BNG Huawei requiert l'adressage du subscriber pour charger les Framed-IPv6-Route. Il n'est considéré adressé que si la réponse RADIUS contient l'un des attributs du tableau (ou s'il est adressé via un pool configuré sur le BNG). Le BNG semble donc implémenter l'algorithme :


    if Access-Accept.attributes has (Framed-IPv6-Prefix or Delegated-IPv6-Prefix or Framed-IPv6-Address) then
        # Subscriber's CPE WAN interface is addressed ⇒
        # Framed-IPv6-Route are valid and will be loaded
        load_framed_ipv6_routes()
    endif

Les attributs RADIUS utilisés dans le test sont communs aux accès PPP et IPoE :


    +-------------+------------------------+----+----------------------------+
    | Username    | Attribute              | Op | Value                      |
    +-------------+------------------------+----+----------------------------+
    | subscriber1 | Framed-IP-Address      | := | 10.10.10.10                |
    | subscriber1 | Framed-IP-Netmask      | := | 255.255.255.255            |
    | subscriber1 | Framed-Route           | += | 192.168.1.0/24 0.0.0.0     |
    | subscriber1 | Framed-Route           | += | 192.168.2.0/24 0.0.0.0     |
    +-------------+------------------------+----+----------------------------+
    | subscriber1 | Framed-IPv6-Prefix     | := | 2001:db8:cafe:babe::/64    | # Mécanisme associé : SLAAC
    | subscriber1 | Framed-IPv6-Route      | += | 2001:db8:dead:c0de::/64 :: |
    | subscriber1 | Framed-IPv6-Route      | += | 2001:db8:feed:beef::/64 :: |
    +-------------+------------------------+----+----------------------------+
    | subscriber1 | Huawei-VPN-Instance    | := | SUBSCRIBER1-VRF            |
    +-------------+------------------------+----+----------------------------+


    +-------------+------------------------+----+----------------------------+
    | Username    | Attribute              | Op | Value                      |
    +-------------+------------------------+----+----------------------------+
    | subscriber1 | Framed-IP-Address      | := | 10.10.10.10                |
    | subscriber1 | Framed-IP-Netmask      | := | 255.255.255.255            |
    | subscriber1 | Framed-Route           | += | 192.168.1.0/24 0.0.0.0     |
    | subscriber1 | Framed-Route           | += | 192.168.2.0/24 0.0.0.0     |
    +-------------+------------------------+----+----------------------------+
    | subscriber1 | Delegated-IPv6-Prefix  | := | 2001:db8:abcd::/48         | # Mécanisme associé : DHCPv6-IAPD
    | subscriber1 | Framed-IPv6-Route      | += | 2001:db8:dead:c0de::/64 :: |
    | subscriber1 | Framed-IPv6-Route      | += | 2001:db8:feed:beef::/64 :: |
    +-------------+------------------------+----+----------------------------+
    | subscriber1 | Huawei-VPN-Instance    | := | SUBSCRIBER1-VRF            |
    +-------------+------------------------+----+----------------------------+


    +-------------+------------------------+----+----------------------------+
    | Username    | Attribute              | Op | Value                      |
    +-------------+------------------------+----+----------------------------+
    | subscriber1 | Framed-IP-Address      | := | 10.10.10.10                |
    | subscriber1 | Framed-IP-Netmask      | := | 255.255.255.255            |
    | subscriber1 | Framed-Route           | += | 192.168.1.0/24 0.0.0.0     |
    | subscriber1 | Framed-Route           | += | 192.168.2.0/24 0.0.0.0     |
    +-------------+------------------------+----+----------------------------+
    | subscriber1 | Framed-IPv6-Address    | := | 2001:db8:cafe:babe::1/128  | # Mécanisme associé : DHCPv6-IANA
    | subscriber1 | Framed-IPv6-Route      | += | 2001:db8:dead:c0de::/64 :: |
    | subscriber1 | Framed-IPv6-Route      | += | 2001:db8:feed:beef::/64 :: |
    +-------------+------------------------+----+----------------------------+
    | subscriber1 | Huawei-VPN-Instance    | := | SUBSCRIBER1-VRF            |
    +-------------+------------------------+----+----------------------------+

Les output sur le BNG se ressemblent fortement. Seuls quelques paramètres changent dans chaque cas (je vous invite à le voir en parcourant les onglets) :


    huawei-bng#display access-user domain brindereseau.fr
    ------------------------------------------------------------------------------
    UserID     Username                Interface      IP address       MAC
               Vlan          IPv6 address             Access type
    ------------------------------------------------------------------------------
    4544       subscriber1             Eth-Trunk0.2   10.10.10.10      0cd8-a0c6-5c00 # CPE WAN IPv4 address (from Framed-IP-Address)
               2             2001:DB8:CAFE:BABE::/64  PPPoE                           # CPE WAN IPv6 prefix (from Framed-IPv6-Prefix)
    ------------------------------------------------------------------------------

    huawei-bng#display ip routing-table vpn-instance SUBSCRIBER1-VRF protocol unr

    Destination/Mask    Proto   Pre  Cost        Flags NextHop         Interface
        10.10.10.10/32  Unr     63   0             D   10.10.10.10     Eth-Trunk0.2 # from Framed-IP-Address := 10.10.10.10
        192.168.1.0/24  Unr     62   0             D   10.10.10.10     Eth-Trunk0.2 # from Framed-Route += 192.168.1.0/24 0.0.0.0
        192.168.2.0/24  Unr     62   0             D   10.10.10.10     Eth-Trunk0.2 # from Framed-Route += 192.168.2.0/24 0.0.0.0

    huawei-bng#display ipv6 routing-table vpn-instance SUBSCRIBER1-VRF protocol unr

    Destination  : 2001:DB8:CAFE:BABE::                    PrefixLength : 64 # from Framed-IPv6-Prefix := 2001:db8:cafe:babe::/64
    NextHop      : 2001:DB8:CAFE:BABE::                    Preference   : 64
    Cost         : 0                                       Protocol     : Unr
    RelayNextHop : ::                                      TunnelID     : 0x0
    Interface    : Eth-Trunk0.2                            Flags        : D

    Destination  : 2001:DB8:DEAD:C0DE::                    PrefixLength : 64 # from Framed-IPv6-Route += 2001:db8:dead:c0de::/64 ::
    NextHop      : 2001:DB8:CAFE:BABE::                    Preference   : 62
    Cost         : 0                                       Protocol     : Unr
    RelayNextHop : ::                                      TunnelID     : 0x0
    Interface    : Eth-Trunk0.2                            Flags        : D

    Destination  : 2001:DB8:FEED:BEEF::                    PrefixLength : 64 # from Framed-IPv6-Route += 2001:db8:feed:beef::/64 ::
    NextHop      : 2001:DB8:CAFE:BABE::                    Preference   : 62
    Cost         : 0                                       Protocol     : Unr
    RelayNextHop : ::                                      TunnelID     : 0x0
    Interface    : Eth-Trunk0.2                            Flags        : D

    Codes: D - download to fib, Unr - user network route


    huawei-bng#display access-user domain brindereseau.fr
    ------------------------------------------------------------------------------
    UserID     Username                Interface      IP address       MAC
               Vlan          IPv6 address             Access type
    ------------------------------------------------------------------------------
    4864       subscriber1             Eth-Trunk0.2   10.10.10.10      0cd8-a0c6-5c00 # CPE WAN IPv4 address (from Framed-IP-Address)
               2             2001:DB8:ABCD::/48       PPPoE                           # CPE WAN IPv6 prefix (from Delegated-IPv6-Prefix)
    ------------------------------------------------------------------------------

    huawei-bng#display ip routing-table vpn-instance SUBSCRIBER1-VRF protocol unr

    Destination/Mask    Proto   Pre  Cost        Flags NextHop         Interface
        10.10.10.10/32  Unr     63   0             D   10.10.10.10     Eth-Trunk0.2 # from Framed-IP-Address := 10.10.10.10
        192.168.1.0/24  Unr     62   0             D   10.10.10.10     Eth-Trunk0.2 # from Framed-Route += 192.168.1.0/24 0.0.0.0
        192.168.2.0/24  Unr     62   0             D   10.10.10.10     Eth-Trunk0.2 # from Framed-Route += 192.168.2.0/24 0.0.0.0

    huawei-bng#display ipv6 routing-table vpn-instance SUBSCRIBER1-VRF protocol unr

    Destination  : 2001:DB8:ABCD::                         PrefixLength : 48 # from Delegated-IPv6-Prefix := 2001:db8:abcd::/48
    NextHop      : 2001:DB8:ABCD::                         Preference   : 64
    Cost         : 0                                       Protocol     : Unr
    RelayNextHop : ::                                      TunnelID     : 0x0
    Interface    : Eth-Trunk0.2                            Flags        : D

    Destination  : 2001:DB8:DEAD:C0DE::                    PrefixLength : 64 # from Framed-IPv6-Route += 2001:db8:dead:c0de::/64 ::
    NextHop      : 2001:DB8:ABCD::                         Preference   : 62
    Cost         : 0                                       Protocol     : Unr
    RelayNextHop : ::                                      TunnelID     : 0x0
    Interface    : Eth-Trunk0.2                            Flags        : D

    Destination  : 2001:DB8:FEED:BEEF::                    PrefixLength : 64 # from Framed-IPv6-Route += 2001:db8:feed:beef::/64 ::
    NextHop      : 2001:DB8:ABCD::                         Preference   : 62
    Cost         : 0                                       Protocol     : Unr
    RelayNextHop : ::                                      TunnelID     : 0x0
    Interface    : Eth-Trunk0.2                            Flags        : D

    Codes: D - download to fib, Unr - user network route


    huawei-bng#display access-user domain brindereseau.fr
    ------------------------------------------------------------------------------
    UserID     Username                Interface      IP address       MAC
               Vlan          IPv6 address             Access type
    ------------------------------------------------------------------------------
    4352       subscriber1             Eth-Trunk0.2   10.10.10.10      0cd8-a0c6-5c00 # CPE WAN IPv4 address (from Framed-IP-Address)
               2             2001:DB8:CAFE:BABE::1    PPPoE                           # CPE WAN IPv6 address (from Framed-IPv6-Address)
    ------------------------------------------------------------------------------

    huawei-bng#display ip routing-table vpn-instance SUBSCRIBER1-VRF protocol unr

    Destination/Mask    Proto   Pre  Cost        Flags NextHop         Interface
        10.10.10.10/32  Unr     63   0             D   10.10.10.10     Eth-Trunk0.2 # from Framed-IP-Address := 10.10.10.10
        192.168.1.0/24  Unr     62   0             D   10.10.10.10     Eth-Trunk0.2 # from Framed-Route += 192.168.1.0/24 0.0.0.0
        192.168.2.0/24  Unr     62   0             D   10.10.10.10     Eth-Trunk0.2 # from Framed-Route += 192.168.2.0/24 0.0.0.0

    huawei-bng#display ipv6 routing-table vpn-instance SUBSCRIBER1-VRF protocol unr

    Destination  : 2001:DB8:CAFE:BABE::1                   PrefixLength : 128 # from Framed-IPv6-Address := 2001:db8:cafe:babe::1/128
    NextHop      : 2001:DB8:CAFE:BABE::1                   Preference   : 64
    Cost         : 0                                       Protocol     : Unr
    RelayNextHop : ::                                      TunnelID     : 0x0
    Interface    : Eth-Trunk0.2                            Flags        : D

    Destination  : 2001:DB8:DEAD:C0DE::                    PrefixLength : 64 # from Framed-IPv6-Route += 2001:db8:dead:c0de::/64 ::
    NextHop      : 2001:DB8:CAFE:BABE::1                   Preference   : 62
    Cost         : 0                                       Protocol     : Unr
    RelayNextHop : ::                                      TunnelID     : 0x0
    Interface    : Eth-Trunk0.2                            Flags        : D

    Destination  : 2001:DB8:FEED:BEEF::                    PrefixLength : 64 # from Framed-IPv6-Route += 2001:db8:feed:beef::/64 ::
    NextHop      : 2001:DB8:CAFE:BABE::1                   Preference   : 62
    Cost         : 0                                       Protocol     : Unr
    RelayNextHop : ::                                      TunnelID     : 0x0
    Interface    : Eth-Trunk0.2                            Flags        : D

    Codes: D - download to fib, Unr - user network route


    huawei-bng#display access-user domain brindereseau.fr
    ------------------------------------------------------------------------------
    UserID     Username                Interface      IP address       MAC
               Vlan          IPv6 address             Access type
    ------------------------------------------------------------------------------
    5312       subscriber1             Eth-Trunk0.2   10.10.10.10      0cd8-a0c6-5c00 # CPE WAN IPv4 address (from Framed-IP-Address)
               2             2001:DB8:CAFE:BABE::/64  IPOE                            # CPE WAN IPv6 prefix (from Framed-IPv6-Prefix)
    ------------------------------------------------------------------------------

    huawei-bng#display ip routing-table vpn-instance SUBSCRIBER1-VRF protocol unr

    Destination/Mask    Proto   Pre  Cost        Flags NextHop         Interface
        10.10.10.10/32  Unr     63   0             D   10.10.10.10     Eth-Trunk0.2 # from Framed-IP-Address := 10.10.10.10
        192.168.1.0/24  Unr     62   0             D   10.10.10.10     Eth-Trunk0.2 # from Framed-Route += 192.168.1.0/24 0.0.0.0
        192.168.2.0/24  Unr     62   0             D   10.10.10.10     Eth-Trunk0.2 # from Framed-Route += 192.168.2.0/24 0.0.0.0

    huawei-bng#display ipv6 routing-table vpn-instance SUBSCRIBER1-VRF protocol unr

    Destination  : 2001:DB8:CAFE:BABE::                    PrefixLength : 64 # from Framed-IPv6-Prefix := 2001:db8:cafe:babe::/64
    NextHop      : 2001:DB8:CAFE:BABE::                    Preference   : 64
    Cost         : 0                                       Protocol     : Unr
    RelayNextHop : ::                                      TunnelID     : 0x0
    Interface    : Eth-Trunk0.2                            Flags        : D

    Destination  : 2001:DB8:DEAD:C0DE::                    PrefixLength : 64 # from Framed-IPv6-Route += 2001:db8:dead:c0de::/64 ::
    NextHop      : 2001:DB8:CAFE:BABE::                    Preference   : 62
    Cost         : 0                                       Protocol     : Unr
    RelayNextHop : ::                                      TunnelID     : 0x0
    Interface    : Eth-Trunk0.2                            Flags        : D

    Destination  : 2001:DB8:FEED:BEEF::                    PrefixLength : 64 # from Framed-IPv6-Route += 2001:db8:feed:beef::/64 ::
    NextHop      : 2001:DB8:CAFE:BABE::                    Preference   : 62
    Cost         : 0                                       Protocol     : Unr
    RelayNextHop : ::                                      TunnelID     : 0x0
    Interface    : Eth-Trunk0.2                            Flags        : D

    Codes: D - download to fib, Unr - user network route


    huawei-bng#display access-user domain brindereseau.fr
    ------------------------------------------------------------------------------
    UserID     Username                Interface      IP address       MAC
               Vlan          IPv6 address             Access type
    ------------------------------------------------------------------------------
    6080       subscriber1             Eth-Trunk0.2   10.10.10.10      0cd8-a0c6-5c00 # CPE WAN IPv4 address (from Framed-IP-Address)
               2             2001:DB8:ABCD::/48       IPOE                            # CPE WAN IPv6 prefix (from Delegated-IPv6-Prefix)
    ------------------------------------------------------------------------------

    huawei-bng#display ip routing-table vpn-instance SUBSCRIBER1-VRF protocol unr

    Destination/Mask    Proto   Pre  Cost        Flags NextHop         Interface
        10.10.10.10/32  Unr     63   0             D   10.10.10.10     Eth-Trunk0.2 # from Framed-IP-Address := 10.10.10.10
        192.168.1.0/24  Unr     62   0             D   10.10.10.10     Eth-Trunk0.2 # from Framed-Route += 192.168.1.0/24 0.0.0.0
        192.168.2.0/24  Unr     62   0             D   10.10.10.10     Eth-Trunk0.2 # from Framed-Route += 192.168.2.0/24 0.0.0.0

    huawei-bng#display ipv6 routing-table vpn-instance SUBSCRIBER1-VRF protocol unr

    Destination  : 2001:DB8:ABCD::                         PrefixLength : 48 # from Delegated-IPv6-Prefix := 2001:db8:abcd::/48
    NextHop      : 2001:DB8:ABCD::                         Preference   : 64
    Cost         : 0                                       Protocol     : Unr
    RelayNextHop : ::                                      TunnelID     : 0x0
    Interface    : Eth-Trunk0.2                            Flags        : D

    Destination  : 2001:DB8:DEAD:C0DE::                    PrefixLength : 64 # from Framed-IPv6-Route += 2001:db8:dead:c0de::/64 ::
    NextHop      : 2001:DB8:ABCD::                         Preference   : 62
    Cost         : 0                                       Protocol     : Unr
    RelayNextHop : ::                                      TunnelID     : 0x0
    Interface    : Eth-Trunk0.2                            Flags        : D

    Destination  : 2001:DB8:FEED:BEEF::                    PrefixLength : 64 # from Framed-IPv6-Route += 2001:db8:feed:beef::/64 ::
    NextHop      : 2001:DB8:ABCD::                         Preference   : 62
    Cost         : 0                                       Protocol     : Unr
    RelayNextHop : ::                                      TunnelID     : 0x0
    Interface    : Eth-Trunk0.2                            Flags        : D

    Codes: D - download to fib, Unr - user network route


    huawei-bng#display access-user domain brindereseau.fr
    ------------------------------------------------------------------------------
    UserID     Username                Interface      IP address       MAC
               Vlan          IPv6 address             Access type
    ------------------------------------------------------------------------------
    6016       subscriber1             Eth-Trunk0.2   10.10.10.10      0cd8-a0c6-5c00 # CPE WAN IPv4 address (from Framed-IP-Address)
               2             2001:DB8:CAFE:BABE::1    IPOE                            # CPE WAN IPv6 address (from Framed-IPv6-Address)
    ------------------------------------------------------------------------------

    huawei-bng#display ip routing-table vpn-instance SUBSCRIBER1-VRF protocol unr

    Destination/Mask    Proto   Pre  Cost        Flags NextHop         Interface
        10.10.10.10/32  Unr     63   0             D   10.10.10.10     Eth-Trunk0.2 # from Framed-IP-Address := 10.10.10.10
        192.168.1.0/24  Unr     62   0             D   10.10.10.10     Eth-Trunk0.2 # from Framed-Route += 192.168.1.0/24 0.0.0.0
        192.168.2.0/24  Unr     62   0             D   10.10.10.10     Eth-Trunk0.2 # from Framed-Route += 192.168.2.0/24 0.0.0.0

    huawei-bng#display ipv6 routing-table vpn-instance SUBSCRIBER1-VRF protocol unr

    Destination  : 2001:DB8:CAFE:BABE::1                   PrefixLength : 128 # from Framed-IPv6-Address := 2001:db8:cafe:babe::1/128
    NextHop      : 2001:DB8:CAFE:BABE::1                   Preference   : 64
    Cost         : 0                                       Protocol     : Unr
    RelayNextHop : ::                                      TunnelID     : 0x0
    Interface    : Eth-Trunk0.2                            Flags        : D

    Destination  : 2001:DB8:DEAD:C0DE::                    PrefixLength : 64 # from Framed-IPv6-Route += 2001:db8:dead:c0de::/64 ::
    NextHop      : 2001:DB8:CAFE:BABE::1                   Preference   : 62
    Cost         : 0                                       Protocol     : Unr
    RelayNextHop : ::                                      TunnelID     : 0x0
    Interface    : Eth-Trunk0.2                            Flags        : D

    Destination  : 2001:DB8:FEED:BEEF::                    PrefixLength : 64 # from Framed-IPv6-Route += 2001:db8:feed:beef::/64 ::
    NextHop      : 2001:DB8:CAFE:BABE::1                   Preference   : 62
    Cost         : 0                                       Protocol     : Unr
    RelayNextHop : ::                                      TunnelID     : 0x0
    Interface    : Eth-Trunk0.2                            Flags        : D

    Codes: D - download to fib, Unr - user network route

Comme sur Cisco XE, la table de routage IPv4 est bien celle attendue :

L'adresse IPv4 assignée avec Framed-IP-Address est une route connected—le NextHop étant égal à Destination/Mask
Les Framed-Route ne sont pas connected et ont comme gateway cette adresse

Rien à signaler dans la table de routage IPv6 du cas Framed-IPv6-Address ! elle ressemble à celle IPv4 avec l'adresse IPv6 du subscriber en gateway. Le début d'article précisait bien que l'assignation d'un préfixe avec SLAAC donne des tables de routage bizarres mais non celle d'une adresse avec DHCPv6 IA_NA.

Dans les cas Framed-IPv6-Prefix et Delegated-IPv6-Prefix, la table de routage IPv6 montre que :

Le préfixe IPv6 assigné avec ces attributs est une route connected (ok)
Les Framed-IPv6-Route ont comme gateway une adresse anycast Subnet-Router !

Pour rappel, l'adresse réseau en IPv6 correspond effectivement à une adresse anycast réservée (RFC 4291 §2.6.1) :


    The Subnet-Router anycast address is predefined.  Its format is as
    follows:

    |                         n bits                 |   128-n bits   |
    +------------------------------------------------+----------------+
    |                   subnet prefix                | 00000000000000 |
    +------------------------------------------------+----------------+

    The "subnet prefix" in an anycast address is the prefix that
    identifies a specific link.  This anycast address is syntactically
    the same as a unicast address for an interface on the link with the
    interface identifier set to zero.

Il faut bien reconnaître le tour de passe-passe du BNG Huawei. Ne pouvant déduire une gateway, il positionne l'adresse anycast Subnet-Router du préfixe assigné (Framed-IPv6-Prefix ou Delegated-IPv6-Prefix), ce qui respecte le standard et aboutit sur une table de routage IPv6 techniquement valide et ressemblant à celle IPv4.

Cela justifie par la même le besoin d'adresser l'interface WAN du CPE et le non-support du modèle unnumbered : les Framed-IPv6-Route ne sont ici pas connected et requièrent donc une gateway, comme les Framed-Route en IPv4.

Tout va bien alors ?

Le stratagème dont use Huawei a ses incohérences.

Tout d'abord, les CPE ne répondent pas tous à l'adresse anycast Subnet-Router—le CPE du test, par exemple, n'y répond pas par défaut (ce billet de l'APNIC étudie d'ailleurs le comportement de différents routeurs). Ce n'est pas gênant sur PPP car le BNG ne tentera jamais de résoudre l'adresse MAC de la gateway avec ND (Neighbor Discovery)—l'ARP de l'IPv6. En réalité, sur PPP, on le rappelle, nul besoin de gateway : le trafic émis par un pair se destine forcément à l'autre (et le modèle unnumbered devrait donc être d'autant plus supporté). En effet, pour citer le TR-187 du Broadband Forum :


    Note that PPP interfaces do not use Neighbor Discovery mechanisms for Link-layer address
    resolution. In PPP there is no concept of link-layer addresses, so all IPv6 on-link datagrams are
    sent to the PPP peer for processing.

    The PPP link can be unnumbered (i.e. only using link-local addresses) or the BNG can assign
    IPv6 addresses to the remote peer via SLAAC or DHCPv6. The BNG end of the PPP interface
    will typically only have a link-local IPv6 address.

Deuxièmement, dans le cas Delegated-IPv6-Prefix, indiquer une telle adresse anycast Subnet-Router est incorrect : le CPE redécoupe le préfixe délégué généralement pour ses LAN et non pour son interface WAN, adressée différemment ou laissée unnumbered. En effet, pour citer la RFC 8415 :


    In a typical scenario (…) the client subnets a single delegated
    /48 prefix into /64 prefixes and assigns one /64 prefix to each
    of the links in the subscriber network.

Par conséquent, l'interface WAN du CPE ne porte pas l'adresse anycast Subnet-Router pourtant positionnée comme gateway sur le BNG. Une fois encore, ce n'est pas gênant sur PPP car le BNG ne déroule pas ND.

Ces deux incohérences trahissent l'intention du BNG qui positionne l'adresse anycast Subnet-Router juste pour obtenir une table de routage valide d'un point de vue technique (syntaxiquement) mais en réalité incohérente (sémantiquement). En gros, il requiert une gateway pour instancier une entrée dans la RIB.

J'ai d'ailleurs déroulé le même test que sur Cisco XR : j'ai désactivé l'autoconfiguration d'adresse sur le CPE, ce qui a laissé son interface WAN dans l'adressage link-local par défaut. Résultat (sans surprise) : le ping à destination d'un des LAN IPv6 (2001:db8:feed:beef::/64 par exemple) tournait quand même, ce qui prouve que l'unnumbered fonctionne même si le BNG impose l'adressage de l'interface WAN du CPE.

Mais en quoi c'est gênant du coup ?

Les deux incohérences identifiées ci-dessus sont théoriquement gênantes pour un accès IPoE.

Lorsque le BNG doit router des paquets à destination des réseaux portés par le CPE et correspondant aux Framed-IPv6-Route, il exécute ND pour résoudre l'adresse MAC de la gateway—une adresse anycast Subnet-Router ici. Or, nous venons d'expliquer que le CPE ne répond pas forcément à cette adresse, soit car non configuré pour, soit car son interface WAN ne la porte même pas (cas du Delegated-IPv6-Prefix).

Alors comment le BNG résout-t-il l'adresse MAC pour la positionner dans les trames Ethernet ? Dans la pratique, le BNG Huawei ne déroule même pas ND et positionne directement l'adresse MAC du subscriber mémorisée lors de la montée de session (tout ça pour ça !) :


    huawei-bng#display access-user domain brindereseau.fr
    ------------------------------------------------------------------------------
    UserID     Username                Interface      IP address       MAC
               Vlan          IPv6 address             Access type
    ------------------------------------------------------------------------------
    5312       subscriber1             Eth-Trunk0.2   10.10.10.10      0cd8-a0c6-5c00
               2             2001:DB8:CAFE:BABE::/64  IPOE
    ------------------------------------------------------------------------------


    huawei-bng#display access-user domain brindereseau.fr
    ------------------------------------------------------------------------------
    UserID     Username                Interface      IP address       MAC
               Vlan          IPv6 address             Access type
    ------------------------------------------------------------------------------
    6080       subscriber1             Eth-Trunk0.2   10.10.10.10      0cd8-a0c6-5c00
               2             2001:DB8:ABCD::/48       IPOE
    ------------------------------------------------------------------------------


    huawei-bng#display access-user domain brindereseau.fr
    ------------------------------------------------------------------------------
    UserID     Username                Interface      IP address       MAC
               Vlan          IPv6 address             Access type
    ------------------------------------------------------------------------------
    6016       subscriber1             Eth-Trunk0.2   10.10.10.10      0cd8-a0c6-5c00
               2             2001:DB8:CAFE:BABE::1    IPOE
    ------------------------------------------------------------------------------

Ce comportement du BNG se déduit en toute logique car comme expliqué plus haut :

Cas du Framed-IPv6-Prefix—le CPE du test n'était pas configuré pour répondre à l'adresse anycast Subnet-Router
Cas du Delegated-IPv6-Prefix—le CPE du test ne portait pas l'adresse anycast Subnet-Router
Les captures ne montraient de plus aucun trafic ND cherchant à résoudre cette adresse anycast

Si non suffisant, pour être définitivement certain, comme précédemment, j'ai désactivé l'autoconfiguration d'adresse sur le CPE :


    cpe#sho run int gi0/0

    interface GigabitEthernet0/0
     ip address dhcp
     ipv6 enable
     ipv6 address autoconfig default # le CPE ignore maintenant le préfixe annoncé dans les RA envoyés par le BNG
    end

    cpe#sho ipv6 int brief

    GigabitEthernet0/0     [up/up]
        FE80::ED8:A0FF:FEC6:5C00
        2001:DB8:CAFE:BABE:ED8:A0FF:FEC6:5C00 # le CPE n'autoconfigure plus son adresse GUA

Le ping tournait quand même sans aucun trafic ND visible sur la capture :


    huawei-bng#ping ipv6 vpn-instance SUBSCRIBER1-VRF 2001:db8:feed:beef::1

      PING 2001:DB8:FEED:BEEF::1 : 56  data bytes, press CTRL_C to break
        Reply from 2001:DB8:FEED:BEEF::1 bytes=56 Sequence=1 hop limit=64 time=2 ms
        Reply from 2001:DB8:FEED:BEEF::1 bytes=56 Sequence=2 hop limit=64 time=2 ms
        Reply from 2001:DB8:FEED:BEEF::1 bytes=56 Sequence=3 hop limit=64 time=2 ms
        Reply from 2001:DB8:FEED:BEEF::1 bytes=56 Sequence=4 hop limit=64 time=3 ms
        Reply from 2001:DB8:FEED:BEEF::1 bytes=56 Sequence=5 hop limit=64 time=4 ms

      --- 2001:DB8:FEED:BEEF::1 ping statistics---
        5 packet(s) transmitted
        5 packet(s) received
        0.00% packet loss
        round-trip min/avg/max=2/2/4 ms

En conclusion, les BNG gardent une part d'implémentation propriétaire, plus ou moins opaque, devinable ou déductible par rétro-ingénierie. Les standards en vigueur définissent des protocoles (structures de données et mécanismes associés) et des requirements, mais des flous demeurent parfois et mènent à des choix et interprétations de la part des équipementiers, qui contraignent ensuite les architectures mises en place par les exploitants du matériel.

`Delegated-IPv6-Prefix` vs `Framed-IPv6-Route`

Remarquons une dernière chose étonnante de la part du BNG Huawei. Il permet ce schéma :

bng-framed-ipv6-route-unnumbered-delegated-prefix — Le BNG supporte le modèle unnumbered pour le préfixe /48 délégué au CPE et, in fine, pour les réseaux /64 assignés aux interfaces LAN.

Le schéma ci-dessus correspond typiquement à un accès Internet IPv6 grand public (souvent IPoE). Le BNG délègue à la box un préfixe avec DHCPv6 IA_PD et laisse le lien WAN unnumbered. La box le redécoupe en un /64 côté LAN et exécute ensuite (généralement) SLAAC pour adresser les hôtes.

Mais pas celui-ci :

bng-framed-ipv6-route-unnumbered-ipv6-only — Le BNG ne supporte pas le modèle unnumbered pour les réseaux /64 portés par le CPE et correspondant aux `Framed-IPv6-Route`.

En quoi est-ce étonnant ? Les schémas se ressemblent fortement et l'unnumbered est permis pour l'un mais pas pour l'autre. Le BNG sait router des paquets à destination des /64 du premier schéma—bien que l'interface WAN du CPE soit unnumbered—mais ne sait pas router des paquets à destination des /64 du deuxième schéma si l'interface WAN est unnumbered…un aspect contradictoire apparait donc de nouveau.

La seule différence est que, dans le premier schéma, le BNG considère (à tort) que l'interface WAN du CPE porte l'adresse anycast Subnet-Router du préfixe délégué 2001:db8:abcd::/48.

Juniper

Cette section sera plus brève que les précédentes car je n'ai pas pu tester l'IPv6 sur BNG Juniper. Cependant, cet article en libre accès de leur knowledge base apporte des éléments. Le test porte sur un accès PPP (sur L2TP) et utilise les attributs RADIUS suivants :


    +--------------+------------------------+----+-------------------------------+
    | Username     | Attribute              | Op | Value                         |
    +--------------+------------------------+----+-------------------------------+
    | testtest.com | Framed-IP-Address      | := | 20.20.20.1                    |
    | testtest.com | Framed-Route           | += | 192.192.192.0/24 20.20.20.1 1 |
    +--------------+------------------------+----+-------------------------------+
    | testtest.com | Framed-IPv6-Pool       | := | ipv6-pd-pool                  |
    | testtest.com | Framed-IPv6-Route      | += | 2a00:a600:0603::/48 :: 1      |
    +--------------+------------------------+----+-------------------------------+

En lien avec la syntaxe des attributs Framed-Route et Framed-IPv6-Route évoquée en début d'article, la route IPv4 contient ici le nexthop explicite 20.20.20.1 correspondant—obligatoirement—à l'adresse de l'interface WAN du CPE. La notation implicite 0.0.0.0 aurait aussi pu être employée ou :: dans sa version IPv6. D'ailleurs, comme la documentation Nokia citée, l'article mentionne la même contrainte concernant le nexthop des routes RADIUS :


    Note: The Nexthop attribute in a framed route is not applicable anymore. Since the subscriber IP address is
    used as the nexthop in all cases, there is no need to have an additional attribute for nexthop for framed routes.

Le test utilise l'attribut Framed-IPv6-Pool—décrit dans la RFC 3162—au lieu de Framed-IPv6-Prefix mais le principe reste le même : le BNG allouera dans ce pool, à la réception de l'Access-Accept, un préfixe IPv6 à assigner à l'interface WAN du CPE en SLAAC. Analysons les output :


    labroot@JTAC-MX480-lab1#run show subscribers

    Interface           IP Address/VLAN ID                      User Name                      LS:RI
    si-1/0/0.3221225478 20.20.20.1                              testtest.com            default:default # CPE WAN IPv4 address (from Framed-IP-Address)
    *                   2015:ceed:0:4::/64                                                              # CPE WAN IPv6 prefix (from Framed-IPv6-Pool)

    labroot@JTAC-MX480-lab1#run show route

    inet.0: 8 destinations, 8 routes (8 active, 0 holddown, 0 hidden)
    20.20.20.1/32      *[Access-internal/12] 00:00:42 Private unicast  # from Framed-IP-Address := 20.20.20.1
    192.192.192.0/24   *[Access/13] 00:00:42, metric 1 Private unicast # from Framed-Route += 192.192.192.0/24 0.0.0.0

    inet6.0: 6 destinations, 6 routes (6 active, 0 holddown, 0 hidden)
    2015:ceed:0:4::/64 *[Access/13] 00:00:42 Private unicast           # from Framed-IPv6-Pool := ipv6-pd-pool
    2a00:a600:603::/48 *[Access/13] 00:00:42, metric 1 Private unicast # from Framed-IPv6-Route += 2a00:a600:0603::/48 ::

Constat :

Le BNG traite différemment l'adresse IPv4 assignée du préfixe IPv6 assigné : l'adresse est marquée Access-internal et le préfixe Access (comme les routes).
Comme sur Cisco XR, les routes ne semblent pas avoir d'adresse comme gateway.

Difficile de se prononcer sur le support ou non du modèle unnumbered avec ces seuls output et sans test supplémentaire. Nous noterons juste que l'article met en avant le modèle numbered et porte sur ce dernier. Cette documentation Juniper évoque bien le modèle unnumbered comme possibilité (uniquement pour le cas Delegated-IPv6-Prefix, comme Huawei étrangement) mais je n'ai pu trouver d'article le confirmant ou l'infirmant.

Les routes retournées en RADIUS sont marquées à la fois Private-unicast (qui s'apparente à du connected à mon sens) et Access. En effet, les BNG différencient souvent les routes originées en RADIUS de celles originées par d'autres protocoles—c'était aussi le cas sur les autres BNG testés :


    xe-bng#show ip route vrf SUBSCRIBER1-VRF

    C     10.10.10.10 is directly connected, Virtual-Access2.1 # from Framed-IP-Address := 10.10.10.10
    U     192.168.1.0/24 [1/0] via 10.10.10.10                 # from Framed-Route += 192.168.1.0/24 0.0.0.0
    U     192.168.2.0/24 [1/0] via 10.10.10.10                 # from Framed-Route += 192.168.2.0/24 0.0.0.0

    xe-bng#show ipv6 route vrf SUBSCRIBER1-VRF

    C   2001:DB8:CAFE:BABE::/64 [0/0] via Virtual-Access2.1, directly connected # from Framed-IPv6-Prefix := 2001:db8:cafe:babe::/64
    U   2001:DB8:DEAD:C0DE::/64 [1/0] via Virtual-Access2.1, directly connected # from Framed-IPv6-Route += 2001:db8:dead:c0de::/64 ::
    U   2001:DB8:FEED:BEEF::/64 [1/0] via Virtual-Access2.1, directly connected # from Framed-IPv6-Route += 2001:db8:feed:beef::/64 ::

    Codes: C - connected, U - per-user static route


    xr-bng#show route vrf SUBSCRIBER1-VRF ipv4 subscriber

    A    10.10.10.10/32 is directly connected, 00:01:14, BE1.2.pppoe493 # from Framed-IP-Address := 10.10.10.10
    A    192.168.1.0/24 is directly connected, 00:01:14, BE1.2.pppoe493 # from Framed-Route += 192.168.1.0/24 0.0.0.0
    A    192.168.2.0/24 is directly connected, 00:01:14, BE1.2.pppoe493 # from Framed-Route += 192.168.2.0/24 0.0.0.0

    xr-bng#show route vrf SUBSCRIBER1-VRF ipv6 subscriber

    A    2001:db8:cafe:babe::/64 is directly connected 00:01:17, BE1.2.pppoe493 # from Framed-IPv6-Prefix := 2001:db8:cafe:babe::/64
    A    2001:db8:dead:c0de::/64 is directly connected 00:01:17, BE1.2.pppoe493 # from Framed-IPv6-Route += 2001:db8:dead:c0de::/64 ::
    A    2001:db8:feed:beef::/64 is directly connected 00:01:17, BE1.2.pppoe493 # from Framed-IPv6-Route += 2001:db8:feed:beef::/64 ::

    Codes: AC - Activated, A - access/subscriber


    huawei-bng#display ip routing-table vpn-instance SUBSCRIBER1-VRF protocol unr

    Destination/Mask    Proto   Pre  Cost        Flags NextHop         Interface
        10.10.10.10/32  Unr     63   0             D   10.10.10.10     Eth-Trunk0.2 # from Framed-IP-Address := 10.10.10.10
        192.168.1.0/24  Unr     62   0             D   10.10.10.10     Eth-Trunk0.2 # from Framed-Route += 192.168.1.0/24 0.0.0.0
        192.168.2.0/24  Unr     62   0             D   10.10.10.10     Eth-Trunk0.2 # from Framed-Route += 192.168.2.0/24 0.0.0.0

    huawei-bng#display ipv6 routing-table vpn-instance SUBSCRIBER1-VRF protocol unr

    Destination  : 2001:DB8:CAFE:BABE::                    PrefixLength : 64 # from Framed-IPv6-Prefix := 2001:db8:cafe:babe::/64
    NextHop      : 2001:DB8:CAFE:BABE::                    Preference   : 64
    Cost         : 0                                       Protocol     : Unr
    RelayNextHop : ::                                      TunnelID     : 0x0
    Interface    : Eth-Trunk0.2                            Flags        : D

    Destination  : 2001:DB8:DEAD:C0DE::                    PrefixLength : 64 # from Framed-IPv6-Route += 2001:db8:dead:c0de::/64 ::
    NextHop      : 2001:DB8:CAFE:BABE::                    Preference   : 62
    Cost         : 0                                       Protocol     : Unr
    RelayNextHop : ::                                      TunnelID     : 0x0
    Interface    : Eth-Trunk0.2                            Flags        : D

    Destination  : 2001:DB8:FEED:BEEF::                    PrefixLength : 64 # from Framed-IPv6-Route += 2001:db8:feed:beef::/64 ::
    NextHop      : 2001:DB8:CAFE:BABE::                    Preference   : 62
    Cost         : 0                                       Protocol     : Unr
    RelayNextHop : ::                                      TunnelID     : 0x0
    Interface    : Eth-Trunk0.2                            Flags        : D

    Codes: D - download to fib, Unr - user network route

Peut-être que, finalement, ce type de route (access, subscriber ou user) signifie pour le BNG :

Accès PPP—le nexthop est forcément le pair (le CPE)
Accès IPoE—l'adresse MAC de l'interface WAN du CPE est mémorisée puis positionnée dans les trames Ethernet et nul besoin d'ARP ni ND

Cela ne reste qu'une supposition suite aux tests et constatations.

Enfin, d'après ce billet sur le forum Juniper, l'aspect Private-unicast des routes RADIUS est relativement récent : auparavant, elles avaient pour gateway l'adresse de l'interface WAN du CPE. Nous retrouvons un peu la différence de comportement entre Cisco XE (avec gateway) et XR (sans).

Revue des bizarreries

Tableau résumant les particularités constatées par BNG—d'autres modèles rentrent probablement dans ces cases (ne pas hésiter à me partager votre retour d'expérience).
BNG	Route	Considérée comme…	Gateway	Unnumbered possible ?
Cisco XE	Framed-Route	Static	Adresse assignée au CPE (`Framed-IP-Address`)	(non applicable en IPv4)
Cisco XE	Framed-IPv6-Route	Static-Connected	(aucune)	Oui
Cisco XR	Framed-Route	Subscriber-Connected	(aucune)	(non applicable en IPv4)
Cisco XR	Framed-IPv6-Route	Subscriber-Connected	(aucune)	Non
Huawei	Framed-Route	Unr-Static	Adresse assignée au CPE (`Framed-IP-Address`)	(non applicable en IPv4)
Huawei	Framed-IPv6-Route	Unr-Static	Adresse assignée au CPE (`Framed-IPv6-Address`) — ou — Adresse anycast Subnet-Router du préfixe assigné au CPE (`Framed-IPv6-Prefix` ou `Delegated-IPv6-Prefix`)	Non
Juniper	Framed-Route	Access-Connected	(aucune)	(non applicable en IPv4)
Juniper	Framed-IPv6-Route	Access-Connected	(aucune)	Peut-être

Les tables de routage IPv4 obtenues sur Cisco XE et Huawei correspondent à celles attendues : les Framed-Route ont comme gateway l'adresse de l'interface WAN du CPE (attribut Framed-IP-Address) considérée, elle, comme connected. Sur XR et Juniper cependant, elles apparaissent sans gateway.

La table de routage IPv6 obtenue sur Huawei dans le cas Framed-IPv6-Address (assignation d'une adresse et non d'un préfixe) est analogue à celle IPv4 : les Framed-IPv6-Route ont comme gateway l'adresse de l'interface WAN du CPE.

Les tables de routage IPv6 obtenues sur Huawei dans les cas Framed-IPv6-Prefix et Delegated-IPv6-Prefix sont étranges voire incohérentes : les Framed-IPv6-Route ont comme gateway l'adresse anycast Subnet-Router du préfixe. Or, l'interface WAN du CPE ne porte pas forcément cette adresse, ce qui ne semble pas déranger le BNG qui, de toute façon, ne cherche même pas à la résoudre avec ND (accès IPoE).

Les tables de routage IPv6 obtenues sur Cisco XE-XR et Juniper révèlent des Framed-IPv6-Route sans gateway, comme directement attachées au BNG. Nous devinons la raison : l'impossibilité pour les BNG de positionner une adresse comme gateway quand l'interface WAN du CPE se voit assigner un préfixe (ce qui a sans doute pousser les plateformes à généraliser le comportement aux Framed-Route comme vu sur XR et Juniper). Elles n'apparaissent pas ainsi sur Huawei, mais c'est tout comme.

Enfin, les BNG ne supportent pas tous avec les Framed-IPv6-Route le modèle unnumbered de l'IPv6—défini par le Broadband Forum et le RIPE—qui consiste à laisser l'interface WAN du CPE dans l'adressage link-local par défaut. Plus précisément, certains BNG imposent (à tort) l'adressage de l'interface WAN du CPE—modèle numbered—mais sans réelle raison sinon pour un soucis d'implémentation. Car comme testé sur Cisco XR et Huawei, désactiver l'autoconfiguration d'adresse sur l'interface WAN du CPE—qui ignore alors le préfixe assigné par le BNG—n'empêche pas le bon fonctionnement.