Un brin de réseau

Ce blog propose des articles sur les technologies réseaux et leur utilisation, le tout illustré avec des maquettes et des captures.

Python freeradius-api Python diffplus

L'IPv6 appliqué au BNG Partie 1

Un précédent article a rappelé des fondamentaux de l'IPv6 que nous appliquons ici au BNG (Broadband Network Gateway), un élément important des réseaux des opérateurs et en particulier des FAI. Plus anciennement appelé BRAS (Broadband Remote Access Server) :


    The BRAS […] is the aggregation point for the user traffic.
    It provides aggregation capabilities (e.g. IP, PPP, Ethernet)
    […] it can also support policy management and IP QoS in the
    access network. In this document, the term BRAS is used to
    describe the ATM-centric device described in TR-092.

Le TR-101 du Broadband Forum définit le rôle de BNG ainsi :


    IP Edge Router where bandwidth and QoS policies may
    be applied. This term is used instead of BRAS to denote
    an Ethernet-centric IP edge node in this document.

Autrement dit, le BNG constitue le point de terminaison des sessions des abonnés (subscribers) ainsi que leur porte de sortie (first-hop router).

Plus concrètement, le BNG implémente notamment : l'appartenance des subscribers à leur VRF (leur instance de table de routage : Internet ou L3VPN dédié), l'application de leur profil de QoS (downstream traffic shaping) et l'assignation de paramètres IP au CPE (Customer-Premises Equipment)—le routeur déployé sur site client. Cet article se concentre justement sur ce dernier point, à savoir les mécanismes d'adressage du CPE par le BNG :

Les candidats pour assurer un tel adressage sont les fameux SLAAC et DHCPv6, sans oublier IPv6CP de PPP. Leur application au BNG présente une certaine learning curve en raison de la myriade de combinaisons possibles et du couplage avec les attributs RADIUS—sujet de l'article suivant.

En image

bng-ipv6-arch
Cet article porte sur l'adressage IPv6 du CPE côté WAN (accès IPoE ou PPP) et côté LAN.

Dans ce schéma, les hôtes derrière le CPE accèdent à Internet (ou leur L3VPN) via une connectivité IPv6 établie entre ce dernier et le BNG. Cette connectivité s'ajoutant à celle IPv4 déjà en place, nous parlons d'accès dual-stack. À titre d'exemple, si votre opérateur le supporte, votre PC lui-même est sans doute en dual-stack : il possède à la fois une adresse IPv4 privée (NATée en public par la box) et une adresse IPv6 publique (inchangée par la box).

Le CPE du schéma est ici bien un routeur et non un bridge. Autrement dit, nous considérons dans cet article l'accès routé et non bridgé. Le Broadband Forum distingue ceci avec les termes respectifs de Routed et Bridged RG (Residential Gateway—synonyme de CPE) et la RFC 6788 le résume bien :


    A residential gateway device […] can be a Layer-3 (routed) device
    or a Layer-2 (bridged) device.  The residential gateway for Broadband
    Forum networks is defined in [TR124].

En précisant bien ce que représente le BNG en fonction du cas :


    The Edge Router, also known as the Broadband Network Gateway (BNG),
    is the first IPv6 hop for the user.  In cases where the RG is bridged,
    the BNG acts as the default router for the hosts behind the RG.  In
    cases where the RG is routed, the BNG acts as the default router for
    the RG itself.  This node implements IPv6 router functionality.

Notion de session

Le trait en pointillés CPE-BNG sur le schéma est couramment appelé « session » que le TR-146 définit ainsi :


    A Session is a logical construct intended to represent a
    network connectivity service instance at a network node.

Une session suit les trois étapes classiques d'un service connection-oriented : établissement de la connexion, suivi de son état et destruction. Ce cycle de vie, davantage détaillé dans l'article des attributs RADIUS de l'IPv6, permet notamment de suivre et d'administrer l'ensemble des sessions depuis le BNG—le network node dans l'extrait ci-dessus. Les exemples de cet article porteront sur des sessions IPoE et PPP (PPPoE mais c'est tout autant valable sur L2TP).


    # Exemple de sessions actives sur BNG Huawei

    <bng>display access-user domain brindereseau.fr
    ------------------------------------------------------------------------------------
    UserID     Username               Interface     IP address               MAC
               Vlan                                 IPv6 address             Access type
    ------------------------------------------------------------------------------------
    16448      session1@brinderes...  Eth-Trunk0.1  10.20.30.40              0c3d-1aed-3300
               1023/1831                            2001:DB8:CAFE:BABE::/64  IPOE
    16449      session2@brinderes...  Eth-Trunk0.2  10.20.1.183              0c3d-1afc-3300
               2000/101                             2001:DB8:DEAD:C0DE::/64  PPPoE
    17801      session3@brinderes...  Eth-Trunk0.2  10.20.0.16               0c3d-1a72-fc00
               2000/101                             2001:DB8:FEED:BEEF::/64  PPPoE
    23657      session4@brinderes...  Loop2         10.20.3.61               -
               -/-                                  -                        PPPoLNS
    24793      session5@brinderes...  Loop2         10.20.2.156              -
               -/-                                  -                        PPPoLNS

Apparaissent ici différents types de session : IPoE (ou DHCP) et PPP dans les cas Ethernet (PPPoE) et L2TP (PPPoLNS). Ce type dépend de plusieurs facteurs : choix architecturaux de l'opérateur (par exemple, privilégier l'IPoE pour les box grand public, privilégier le PPP pour les clients pro) ou encore la technologie sous-jacente (interconnexion L2TP entre deux opérateurs, réseau de collecte tiers imposant l'IPoE ou le PPP).


    # Exemple de sessions détruites sur BNG Huawei (avec la cause)

    <bng>display aaa offline-record brief
    -------------------------------------------------------------------------
    ID     Name                           IP address        MAC
           Reason
    -------------------------------------------------------------------------
    21504  session1@brindereseau.fr       10.20.30.40       0c3d-1aed-3300
           ARP with detect fail
    19524  session4@brindereseau.fr       10.20.3.61        -
           LAC clear session
    257    session5@brindereseau.fr       10.20.2.156       -
           PPP with echo fail
    23168  session3@brindereseau.fr       10.20.0.16        0c3d-1a72-fc00
           PPP with echo fail

Enfin, sous ce trait en pointillés CPE-BNG peut typiquement se trouver un simple lien physique point-à-point entre les deux équipements (fibre monomode, par exemple), un réseau d'accès Ethernet mutualisé et étendu sur un backbone IP/MPLS ou encore un tunnel L2TP entre deux opérateurs.

Plan de l'article

Partie 1 (cette page)

Partie 2 (page suivante)

En résumé

Deux modèles d'adressage existent pour l'interface WAN du CPE : numbered (adressage GUA) et unnumbered (adressage LLA). Le RIPE préconise le premier. Le deuxième, bien que répandu pour l'accès Internet grand public, possède quelques inconvénients et s'avère peu compatible avec l'attribut RADIUS Framed-IPv6-Route—n'ayant pas trouvé de ressources à ce sujet, mais ayant expérimenté le phénomène en lab, j'ai rédigé un article dédié.

Plusieurs mécanismes existent pour l'adressage WAN et LAN du CPE par le BNG : SLAAC, DHCPv6 et IPv6CP de PPP. Ces mécanismes véhiculent des paramètres IPv6 provenant souvent d'attributs RADIUS—sujet de l'article suivant.

L'adressage en /127 pour le lien WAN (l'équivalent du /31 en IPv4) n'est à ma connaissance possible qu'en adressage statique ou via un /127 alloué dans le préfixe délégué par DHCPv6 et son option IA_PD, solution non illustrée dans cet article—voir le complément d'informations plus bas. En effet, les mécanismes d'adressage dynamique ne délivrent que du /64 ou du /128 (avec SLAAC ou DHCPv6 et son option IA_NA).

SLAAC est adapté tant pour l'adressage WAN (sur IPoE et PPP) que LAN. Il n'assigne pas d'adresse précise, mais peut véhiculer un /64 dans lequel les nœuds autoconfigurent leur adresse avec la méthode EUI-64 par exemple. IPv6 distingue deux rôles de nœud : host et router. Une différence notable est que l'host (e.g., un PC) ajoute automatiquement une route par défaut vers le router (e.g., un CPE) lui ayant annoncé son /64.

DHCPv6 est adapté tant pour l'adressage WAN (sur IPoE et PPP) que LAN. Il assigne une adresse précise avec l'option IA_NA et délègue un préfixe avec l'option IA_PD (un /48 ou /56 typiquement)—préfixe que le CPE redécoupe en /64 pour ses interfaces LAN. Ne véhiculant ni le réseau /64 de rattachement (dit on-link), ni la route par défaut, il se combine souvent avec SLAAC qui fournit ces paramètres.

IPv6CP est adapté pour l'adressage WAN. Contrairement à IPCP, il ne permet pas au BNG d'assigner directement une adresse au CPE mais négocie les IID (Interface ID) des interfaces IPv6 afin de former leur adresse LLA (rendant au passage la procédure DAD redondante). Les mécanismes SLAAC et DHCPv6 s'emploient par la suite pour l'adressage GUA. IPv6CP permettant au BNG d'assigner un IID spécifique au CPE, il devient indirectement possible d'assigner une adresse précise—et sans DHCPv6—en combinant IPv6CP et SLAAC.

To be numbered, or not to be

Nous avons vu dans les bases que trois types d'adresse unicast existent en IPv6 : LLA (link-local), GUA (publique) et ULA (privée unique). Aussi, la question de préférer tel ou tel type d'adressage pour le côté WAN du CPE se pose. Le TR-177 du Broadband Forum définit ainsi deux modèles :


    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.
bng-ipv6-numbered-or-unnumbered
Deux modèles d'adressages sont définis : numbered et unnumbered.

Dans la suite, nous choisissons le modèle numbered—qui se justifie et permet d'étudier les mécanismes d'assignation. Mais arrêtons-nous un instant sur la différence entre les deux modèles. L'adressage LLA, ou unnumbered, est systématique et obligatoire en IPv6. Aussi, pourquoi ne pas s'en contenter plutôt que d'y adjoindre un autre adressage ? Le RIPE-690 apporte plusieurs conseils sur le sujet.

Il évoque l'adressage LLA comme solution adaptée à certains scénarios :


    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.

    It is most useful in scenarios where it is known that only CPEs will be attached
    to the WAN link, and where a “pingable” address of the CPE is known (e.g. because
    the ISP-provided CPEs are always “pingable” on the first delegated address).

Il ne recommande pas l'adressage ULA :


    Some operators use ULAs for numbering the WAN link to the end-user CPE. This
    approach may cause numerous problems and is therefore strongly discouraged.

Et recommande idéalement l'adressage GUA :


    In order to facilitate troubleshooting and have a future proof network, you should
    consider numbering the WAN links using GUAs, using a /64 prefix out of a dedicated
    pool of IPv6 prefixes. If you decide to use /127 for each point-to-point link, it
    is advisable to allocate a /64 for each link and just use one /127 out of it.

Cet adressage GUA, bien que préconisé, demande davantage de travail à l'opérateur. Car, comme écrit dans l'extrait, un ou plusieurs préfixes devront être réservés dans son IPAM pour adresser les liens WAN. Par la suite, les mécanismes d'assignation, en lien avec le BNG et le RADIUS, devront être maîtrisés puis configurés—alors que l'adressage LLA consiste (en gros) en un ipv6-enable sur les interfaces CPE-BNG et réduit donc les OPEX (Operating Expense).

Si l'adressage LLA semble tout indiqué car plus simple, il peut s'avérer insuffisant. Dans la pratique, il peut bien se prêter à l'accès Internet grand public (qui emploie généralement la délégation de préfixes avec l'option IA_PD de DHCPv6). Dans les services fournis aux clients pro et afin de router les réseaux publics (GUA) et privés (ULA) de leur L3VPN, l'attribut RADIUS Framed-IPv6-Route est souvent utilisé. Or, les BNG imposent parfois (à tort) que l'interface WAN du CPE soit adressée (numbered) afin de rendre ces routes opérationnelles.

Ce dernier point rappelle que les architectures réseaux découlent non seulement de la pensée (conception et bonne compréhension des standards) mais aussi des limitations du matériel (interprétation et implémentation propriétaire). Et il n'est pas toujours possible, quand on sélectionne du matériel, d'entrer dans un tel niveau de détail dans le cahier des charges (« je veux que le BNG puisse véhiculer des Framed-IPv6-Route sur de l'unnumbered »).

Un adressage WAN en /127 ?

Comme vu dans les bases, les liens point-à-point IPv6 peuvent être adressés en /127, ce qui ressort bien dans l'extrait du RIPE :


    In order to facilitate troubleshooting and have a future proof network, you should
    consider numbering the WAN links using GUAs, using a /64 prefix out of a dedicated
    pool of IPv6 prefixes. If you decide to use /127 for each point-to-point link, it
    is advisable to allocate a /64 for each link and just use one /127 out of it.

Le /127 n'étant possible qu'en adressage statique, nous ne l'illustrons pas dans la suite—et, bien qu'elle existe, j'exclus la solution où le CPE alloue un /127 pour son interface WAN dans le préfixe délégué par DHCPv6 et son option IA_PD.

La RFC 3633 originelle de l'option IA_PD, maintenant obsolète, interdisait l'utilisation du préfixe délégué—ou d'un subnet alloué dedans—sur l'interface qui le reçoit (l'interface WAN du CPE ici) :


    […] with the following exception: the requesting router MUST
    NOT assign any delegated prefixes or subnets from the delegated
    prefix(es) to the link through which it received the DHCP message
    from the delegating router.

Un errata semble avoir levé la restriction (sans réelle explication, merci aux auteurs). Depuis, la RFC 6603 l'autorise plus ou moins explicitement :


    Furthermore, it may be required that the prefix configured on the
    uplink interface has to be aggregatable with the delegated prefixes.

Et le TR-124 du Broadband Forum, mis à jour en juillet 2024, le mentionne également dans WAN.IPv6.12 :


    If the RG does not have a globally scoped address on its WAN interface
    after having been delegated a prefix, it MUST create addresses for itself
    from the delegated prefix. It MUST have at least one address and MAY have more.

J'imagine que les besoins et implémentations existantes ont poussé le standard DHCPv6 a évoluer et a lever la restriction.

Enfin, cet article résume bien l'historique :


    In early drafts of the DHCPv6 Prefix Delegation (RFC 3633), the
    IA_PD delegated prefix was only allowed to be assigned to the
    CPE’s LAN-side interfaces and could not overlap with the prefix
    of the CPE’s WAN link.

    The result of this restriction was that service providers required
    one routing table entry to reach the CPE device and a separate
    route to reach the networks behind it.

    This restriction was later relaxed with the addition of the DHCPv6
    Prefix Exclude Option (RFC 6603), and then eliminated completely
    in the latest DHCPv6 specification (RFC 8415).

Et précise l'intérêt de pouvoir utiliser sur l'interface WAN un subnet alloué dans le préfixe délégué : 


    This article describes how to configure CDRouter to support a CPE
    device that uses DHCPv6 Prefix Delegation to derive both its LAN
    side subnet prefix(es) as well as its global WAN address.

    This is a popular deployment strategy that permits the service
    provider to use a single aggregate route for all traffic being
    forwarded to the CPE device and its descendant networks.

En conclusion, une telle utilisation est donc tout à fait possible aujourd'hui, mais n'est sans doute pas supportée par la majorité des CPE. Aussi, je ne l'illustre pas dans la suite de l'article—l'important étant de savoir qu'elle existe et quel en est l'intérêt.

Les mécanismes d'adressage étudiés dans la suite ne délivrent pour le lien WAN que du /64 ou du /128 (avec SLAAC ou DHCPv6 et l'option IA_NA).

SLAAC pour l'adressage WAN

SLAAC (StateLess Address AutoConfiguration)—qui relève plus du mécanisme que du protocole (il n'y a pas de PDU SLAAC)—est défini dans la RFC 4862 :


    The stateless mechanism allows a host to generate its own addresses
    using a combination of locally available information and information
    advertised by routers.

    To ensure that all configured addresses are likely to be unique on a
    given link, nodes run a "duplicate address detection" algorithm on
    addresses before assigning them to an interface.

Nous retiendrons trois points, à savoir que SLAAC permet :

Ainsi, SLAAC peut adresser l'interface WAN d'un CPE. Plus précisément, si configuré pour, le CPE autoconfigure l'adresse de son interface WAN dans le préfixe /64 annoncé par le BNG—je vous renvoie aux bases pour comprendre la raison de cette taille /64.

Le terme stateless signifie que les routeurs exécutant SLAAC ne maintiennent pas d'état lié aux informations échangées. Un routeur qui annonce un préfixe ne maintient pas de table d'assignation : il l'annonce, c'est tout ; et les nœuds qui le reçoivent autoconfigurent ou non une adresse dedans.


    The stateless approach is used when a site is not particularly
    concerned with the exact addresses hosts use, so long as they are
    unique and properly routable.  On the other hand, Dynamic Host
    Configuration Protocol for IPv6 (DHCPv6) [RFC3315] is used when a
    site requires tighter control over exact address assignments.

Ainsi, le routeur ayant annoncé le préfixe ne connaît pas les adresses générées dedans—et il n'en a pas forcément besoin. C'est typiquement le cas d'une box Internet grand public : elle adresse en IPv6 les hôtes du LAN avec SLAAC, et n'a pas besoin de connaître les adresses générées. On pourrait penser que si, du fait de l'habitude avec DHCPv4, mais non : elle les connaît en temps voulu lorsqu'elle reçoit des paquets à router à leur destination (et déroule alors l'ARP pour résoudre leur adresse MAC). Comme le précise l'extrait, cela s'oppose au comportement stateful de DHCPv6.

Par la pratique

Dans les captures ci-dessous, le CPE sollicite avec un message RS (Router Solicitation) le BNG qui lui annonce avec un message RA (Router Advertisement) le préfixe 2001:DB8:CAFE:BABE::/64 via ICMPv6 et son option PIO (Prefix Information Option). Le CPE autoconfigure ensuite l'adresse de son interface WAN dans ce préfixe, par exemple avec la méthode EUI-64.

Les flags OnLink et Autonomous

Regardons alors les adresses et routes générées :

Non seulement le CPE a généré son adresse dans le /64 annoncé, mais il a également ajouté la route connected correspondante. Les flags Autonomous et OnLink (abrégés A et L) rendent en partie possible ces actions—je dis « en partie » car le CPE n'interprète pas forcément les flags reçus : cela dépend de sa configuration. Noter que le standard en vigueur positionne effectivement ces flags à TRUE par défaut :


    AdvOnLinkFlag
         Default: TRUE

    AdvAutonomousFlag
         Default: TRUE

Soit en capture :

La route connected—conséquence du flag L=1 donc—permet au CPE de communiquer directement avec les autres nœuds connectés au même /64, sans passer par une gateway (autrement dit, cela lui permet d'envoyer de l'ARP à ces nœuds). Cela paraît trivial. Mais rappelons qu'en IPv6, une adresse assignée à une interface se veut avant tout non structurée (sans réseau associé). La RFC 5942 résume bien le propos en comparant avec l'IPv4 :


    IPv4 implementations typically associate a netmask with an address
    when an IPv4 address is assigned to an interface.  That netmask
    together with the IPv4 address designates an on-link prefix.

    The behavior of IPv6 as specified in Neighbor Discovery (ND)
    [RFC4861] is quite different.  The on-link determination is separate
    from the address assignment.  A host can have IPv6 addresses without
    any related on-link prefixes […] Any assigned address on an interface
    should initially be considered as having no internal structure
    as shown in [RFC4291].

    IPv6 packets sent using the Conceptual Sending Algorithm as described
    in [RFC4861] only trigger address resolution for IPv6 addresses that
    the sender considers to be on-link […]

Le préfixe annoncé par le BNG devient off-link et la table de routage du CPE omet alors le /64 connected :

Cette table de routage permet d'anticiper la deuxième partie : c'est typiquement celle obtenue avec DHCPv6. Contrairement à DHCPv4 et son option 1-SubnetMask, DHCPv6 ne fournit pas de masque quand il assigne une adresse (avec son option IA_NA). De même, contrairement à DHCPv4 et son option 3-Router, il ne fournit pas la route par défaut. C'est bien SLAAC qui fournit ces paramètres, raison pour laquelle DHCPv6 s'emploie souvent de pair avec.

L'off-link et la topologie P2MP

L'off-link se prête bien, à mon sens, aux réseaux d'accès de topologie P2MP (Point-to-Multipoint). Pour illustrer le propos, prenons comme référence le schéma de la RFC 6957 :


    +------+         +----+
    | CPE3 |---------| AN |
    +------+         +----+
                       |
                       |
    +------+         +----+
    | CPE2 |---------| AN |---+
    +------+         +----+   |
    +------+            |     |
    | CPE1 |------------+     |
    +------+               +-----+
                           | BNG |--- Internet
                           +-----+

              Figure 1: DSL and Fiber Access Architecture

Dans ce schéma, les CPE sont volontairement isolés les uns des autres en L2 pour des raisons de sécurité (éviter le MAC spoofing, par exemple). Autrement dit, les trames broadcast ou multicast émises par un CPE—pour résoudre l'adresse MAC d'une adresse IP, par exemple—ne sont pas reçues par les autres, mais uniquement par le BNG ; seul lui peut communiquer avec eux : c'est la topologie P2MP. Pour reprendre le texte accompagnateur du schéma :


    In a DSL or Fiber access architecture depicted in Figure 1, CPE1,
    CPE2, CPE3, and the BNG are IPv6 nodes, while AN is an L2 bridge
    providing connectivity between the BNG and each CPE.  The AN enforces
    a split-horizon model so that CPEs can only send and receive frames
    (e.g., Ethernet frames) to and from the BNG but not to each other.

Plus haut, le document mentionnait explicitement la topologie P2MP et l'isolation qui en découle :


    […] IPv6 nodes on the same point-to-multipoint domain cannot
    have direct communication: any communication between them must
    go through the first-hop router of the same domain.

Le MEF parle aussi de topologie E-Tree, aussi connue sous le nom de Hub-and-Spoke : « An E-Tree is a rooted multipoint service […] providing sites with hub and spoke multipoint connectivity ». Si certains documents voient des différences subtiles entre ces trois topologies (P2MP, E-Tree et Hub-and-spoke), elles sont, à ma connaissance, synonymes. La RFC 7152 §3.3 en présente d'ailleurs des applications classiques (dont le BNG).

Par exemple, la RFC 4562 qui définit le MAC-Forced Forwarding :


    It is required that all traffic to and from customer hosts located at
    different premises (i.e., accessed via different subscriber lines or
    via different access networks) be forwarded via an AR, and not
    bridged or switched at layer-2 (Requirement 1; see also requirement
    R-40 in [TR101]).  This enables the access network service provider
    to use the AR(s) to perform security filtering, policing, and
    accounting of all customer traffic.

Et qui référence d'ailleurs le R-40 d'une ancienne version du TR-101 du Broadband Forum—alors appelé DSL Forum—encore disponible sur l'IETF :


    R-40  The Access Node MUST be able to prevent forwarding traffic between user ports (user
          isolation). This behavior MUST be configurable per S-VID.

Plusieurs techniques existent pour implémenter une telle isolation L2 sur un switch, du simple Port Isolation d'Huawei au MAC-Forced Forwarding (RFC sus-citée) ou encore le Private VLAN de Cisco (RFC 5517). Le but n'est pas ici de décrire davantage ces mécanismes—ils auront été évoqués. De même, si le réseau d'accès s'étend sur un backbone IP/MPLS, le VPLS Hub-and-Spoke permet une telle isolation ou encore l'EVPN E-Tree.

Mais reprenons le schéma de référence précédent et appliquons-le au cas de l'accès bridgé auquel, selon moi, l'off-link profite tout particulièrement—bien que je n'ai trouvé aucune documentation à ce sujet :

bng-ipv6-slaac-offlink
Application de l'off-link sur l'accès bridgé. La topologie est P2MP (Point-to-Multipoint).

Dans ce schéma, les hôtes sont connectés au BNG sans passer par un routeur intermédiaire (CPE) et sont adressés dans le même /64. J'ai vu ceci en action sur un réseau d'accès de type campus : chaque chambre de chaque bâtiment, munie d'une prise Ethernet câblée en cuivre jusqu'à un switch d'agrégation, arrive in fine sur le BNG (via le backbone ou non). Les utilisateurs branchent leur PC à ces prises et se retrouvent directement connectés en L2 au BNG.

Comme expliqué plus haut, les hôtes sont volontairement isolés les uns des autres en L2 : ils ne peuvent communiquer directement entre eux et doivent forcément passer par le BNG, leur seule porte de sortie. Et la table de routage de l'off-link reflète parfaitement ceci :


    HOST#show ipv6 route

    ND  ::/0 [2/0] via FE80::E1E:BAFF:FEEE:0, GigabitEthernet0/0
    L   2001:DB8:CAFE:BABE:EB5:29FF:FEC4:0/128 [0/0] via GigabitEthernet0/0, receive
    L   FF00::/8 [0/0] via Null0, receive

    Codes: L - Local, ND - ND Default

En effet, la route par défaut ::/0 suffit pour joindre Internet et les hôtes du même réseau d'accès (du même /64). Dans tous les cas, l'hôte source cherchera à passer par le BNG et émettra un message NS afin de résoudre l'adresse MAC de ce dernier (associée à l'adresse IPv6 FE80::E1E:BAFF:FEEE:0).

Dans cet accès bridgé, un /64 on-link poserait effectivement problème :


    HOST#show ipv6 route

    ND  ::/0 [2/0] via FE80::ED6:A4FF:FE19:0, GigabitEthernet0/0
    NDp 2001:DB8:CAFE:BABE::/64 [2/0] via GigabitEthernet0/0, directly connected
    L   2001:DB8:CAFE:BABE:EB4:D0FF:FEFD:0/128 [0/0] via GigabitEthernet0/0, receive
    L   FF00::/8 [0/0] via Null0, receive

    Codes: L - Local, ND - ND Default, NDp - ND Prefix

Car, avec cette table de routage, un hôte voulant communiquer avec un autre dans ce /64 cherchera à résoudre l'adresse MAC associée à l'adresse IPv6 de ce dernier via un message NS émis avec une trame multicast. Or, l'hôte de destination ne recevra jamais ce message, les hôtes étant isolés en L2. Seul le BNG le recevra et n'y répondra pas à moins de le configurer comme proxy ND (RFC 4389)—fréquent sur IPv4, dépourvu de l'off-link, avec le proxy ARP.

Erreur d'implémentation de l'off-link

Cette distinction on-link et off-link a d'ailleurs mené à une implémentation erronée—que je trouve amusante, car elle témoigne bien de la complexité inhérente à l'IPv6—documentée dans la RFC 5942 déjà citée précédemment :


    One incorrect implementation behavior illustrates the severe
    consequences when the IPv6 subnet model is not understood by the
    implementers of several popular host operating systems. […]
    The host incorrectly assumes an invented prefix is on-link.  This
    invented prefix typically is a /64 that was written by the developer
    of the operating system network […] it can cause connectivity problems
    in Non-Broadcast Multi-Access (NBMA) networks.  Having incorrectly
    assumed an invented prefix, the host performs address resolution when
    the host should send all non-link-local traffic to a default router.
    Neither the router nor any other host will respond to the address
    resolution, preventing this host from sending IPv6 traffic.

L'histoire raconte qu'un développeur, sans doute peu familier avec ces notions, a hardcodé l'aspect on-link d'un préfixe /64 censé être off-link. Conséquence ? Le réseau étant NBMA, le trafic ND émit par un hôte pour joindre d'autres hôtes dans ce /64 n'est jamais reçu par ces derniers, et est ignoré par le BNG qui ne constitue pas le destinataire (et car non configuré comme proxy ND). Les hôtes ne pouvaient donc communiquer entre eux.

Le modèle off-link règle le problème en ce que les hôtes empruntent leur route par défaut vers le BNG pour sortir vers toute autre adresse ou réseau.

L'off-link et l'économie d'énergie !

Enfin, remarquons, dans un tout autre contexte, que le récent draft-ietf-6man-ipv6-over-wireless (2024) tire aussi parti de l'off-link :


    Instead, the IPv6 routers […] are connected to one another directly
    (classical NBMA, aka full mesh) or indirectly via other routers (Point
    to MultiPoint, P2MP, aka partial mesh).  The not-onlink model is used
    throughout, so hosts do not look each other up, saving all the associated
    broadcast.  Instead, they rely on the routers to forward the packets inside
    and outside the Subnet.

Et ce, afin d'éviter le broadcast inutile sur des réseaux LoWPAN (Low-Power Wireless Personal Area Network) :


    The key design points in this architecture derive from the original
    observations made at the 6LoWPAN WG for constrained devices and
    networks, and focus on avoiding waste of limited resources such as
    spectrum and energy, by using broadcasts only when broadcast is
    really needed, and decoupling the IP abstraction of a Subnet from the
    broadcast domains to avoid Subnet-wide broadcast storms.  To that
    effect, this architecture leverages the not-onlink model and routing
    inside the Subnet, which enables to form potentially large MLSNs
    without creating a large broadcast domain at the link layer.

Et si Autonomous vaut 0 ?

Nous venons de voir que le flag OnLink (ou L) peut valoir 0 ou 1. Mais qu'en est-il du flag Autonomous (ou A) ? La théorie nous dit que s'il vaut 0, le CPE doit ignorer le préfixe /64 annoncé, et ce, même si L est positionné :


    If the Autonomous flag is not set, silently ignore the Prefix
    Information option.

Cela peut étonner. On pourrait s'attendre—avec la combinaison L=1,A=0—à ce que le CPE instancie une route connected associée au /64 annoncé, sans pour autant autoconfigurer une adresse dedans (sur l'interface ayant reçu le message RA du BNG, c'est-à-dire l'interface WAN ici).

Techniquement, rien ne l'empêche, sachant que l'interface en question possède forcément une adresse LLA (link-local) permettant la communication non seulement avec des adresses LLA sur le lien mais aussi avec des adresses du réseau on-link—comme en témoigne le ping dans la capture IPoE ci-dessous. Sur Cisco, la commande ipv6 nd autoconfig prefix permet ainsi de forcer l'ajout de la route connected même si l'interface reçoit L=1,A=0 comme flags :

Nous constatons donc une fonctionnalité du CPE—probablement due à des besoins apparus au fil de l'eau—non conforme avec le standard. Vous l'aurez compris, ces flags induisent une multitude de combinaisons, résumées dans la section suivante, pas évidentes à appréhender.

Combinaisons des flags OnLink et Autonomous

Combinaisons possibles des flags OnLink et Autonomous.
Flag OnLink ou L Flag Autonomous ou A Le nœud ajoute une route connected associée au /64 annoncé Le nœud autoconfigure son adresse dans le /64 annoncé
0 0 Non
0 1 Non Oui
1 0 Non
1 1 Oui

La combinaison la plus répandue—et la moins risquée car majoritairement supportée—est sans nul doute celle par défaut : L=1,A=1. Oui, tout ça pour ça !

Les flags Managed et OtherConfig

Les flags Managed et OtherConfig (abrégés M et O) du message RA suggèrent au CPE quels mécanismes employer pour récupérer ses paramètres, M correspondant à l'adressage et O à la récupération « d'autres informations » comme les DNS, le search domain (RFC 8106) ou les NTP (RFC 5908).

Dans les captures précédentes, ces flags étaient positionnés à leur valeur par défaut par le BNG, à savoir FALSE :


    AdvManagedFlag
        Default: FALSE

    AdvOtherConfigFlag
        Default: FALSE

Signifiant alors au CPE que SLAAC fournit tous les paramètres. Les autres combinaisons possibles sont :

Combinaisons possibles des flags Managed et OtherConfig.
Flag Managed ou M Flag OtherConfig ou O Adressage de l'interface Récupération « d'autres informations »
0 0 SLAAC
0 1 SLAAC DHCPv6 stateless
1 0 DHCPv6 stateful
1 1

La deuxième partie sur DHCPv6 illustre les combinaisons M=0,O=1 (ou DHCPv6 stateless) et M=1 (ou DHCPv6 stateful). Noter que la combinaison M=1,O=0 avec DHCPv6 pour l'adressage et SLAAC pour les autres informations n'existe pas, comme le précise la RFC 4861 :


    If the M flag is set, the O flag is redundant and
    can be ignored because DHCPv6 will return all
    available configuration information.

Exemple de SLAAC fournissant tous les paramètres (adressage et autres informations, les DNS ici) :

Idéalement, le BNG positionne ces flags en adéquation avec le mode d'adressage choisi et configuré côté CPE.


    #
    aaa
     default-user-name template MY-TEMPLATE include mac-address noseparator
     domain brindereseau.fr
      radius-server group MY-RADIUS-SERVER
      ipv6 nd autoconfig managed-address-flag
      ipv6 nd autoconfig other-flag dhcpv6
    #
    interface Eth-Trunk0.2
     user-vlan 101 qinq 2000
     ipv6 enable
     ipv6 address auto link-local
     pppoe-server bind Virtual-Template 2
     bas
      access-type layer2-subscriber default-domain authentication brindereseau.fr
      default-user-name-template MY-TEMPLATE
     #
     interface Virtual-Template2
      ppp authentication-mode chap
      ppp chap user MY-BNG
      ppp keepalive interval 10 retransmit 3
    #

DAD (Duplicate Address Detection)

Revenons à l'adresse autoconfigurée par le CPE sur son interface WAN suite au message RA reçu du BNG. Avant de la considérer effective, le CPE vérifie son unicité en exécutant la procédure DAD sur le lien avec l'envoi d'un message NS en multicast. La non-réponse à ce message par les voisins au bout d'un certain temps (1 seconde ici) signifie unicité. Le CPE envoie ici par la suite—c'est optionnel—un message unsolicited NA (l'équivalent d'un gratuitous ARP).

Sur la topologie P2MP décrite auparavant, cette procédure DAD ne peut fonctionner en l'état : le message NS ne sera reçu que par le BNG, les hôtes étant isolés en L2. Le mécanisme de proxy DAD (RFC 6957) peut alors s'utiliser sur le BNG, qui traitera ces messages NS et en maintiendra une binding table.

Dans le cas PPP, cette procédure DAD est en réalité redondante avec IPv6CP—que nous abordons dans la deuxième partie.

La sélection du routeur par défaut

Afin de sortir vers Internet (ou vers le L3VPN client), le CPE doit posséder une route par défaut vers le BNG. En IPv4, plusieurs méthodes existent :

Dans le monde IPv6, DHCPv6 ne fournit pas la route par défaut (choix des concepteurs—nous voyons pourquoi dans la deuxième partie). La fournir avec BGP ou un IGP est bien sûr toujours possible, ainsi que via l'astuce de la directly connected static route pour un accès PPP.

Mais SLAAC. Oui, encore. Plus précisément, le message RA d'ICMPv6 peut suffire à fournir la route par défaut via le flag Prf :

La RFC 4861 définit en effet l'algorithme Default Router Selection qui, en lien avec la RFC 4191, se base sur la valeur du flag Prf afin de sélectionner un routeur par défaut. Rappelons qu'IPv6 distingue deux rôles de nœud : host et router. Et l'algorithme en question n'est (étrangement) défini que pour l'host. De plus, un nœud hôte n'émet pas non plus de message RA dédié, comme son nom l'indique (Router Advertisement), au rôle de routeur.

À titre d'exemple, sur Cisco, la présence (resp. l'absence) de la commande ipv6 unicast-routing permet au nœud de se considérer routeur (resp. hôte) :

Si nous appliquons la théorie au CPE, qui joue ici le rôle de router, cela signifierait qu'il ne peut sélectionner et instancier une route par défaut vers le BNG. Gênant donc. Pourtant, la RFC 7084, justement dédiée aux requirements des routeurs CPE, nous dit :


    W-3:  Absent other routing information, the IPv6 CE router MUST use
          Router Discovery as specified in [RFC4861] to discover a
          default router(s) and install a default route(s) in its routing
          table with the discovered router's address as the next hop.

Nous voyons, de nouveau, une déviation entre le standard originel et un autre plus récent. Sur Cisco, les commandes suivantes, qui s'appliquent à l'interface WAN en l'occurrence, permettent ainsi de forcer l'ajout automatique d'une route par défaut (même si le CPE possède le rôle de router, donc) :


    ipv6 address autoconfig default   # autoconfigurer une adresse + générer la route par défaut
    ipv6 nd autoconfig default-router # ne générer que la route par défaut

SLAAC pour l'adressage LAN

Parce qu'intrinsèque à IPv6—en 1997 déjà les spécifications de l'IPv6 mentionnaient l'autoconfiguration d'adresse comme feature requise—SLAAC s'affiche comme protocole de choix pour l'adressage LAN (son probable objectif premier) et car massivement supporté.

Cette section se veut brève car les mécanismes décrits auparavant demeurent valides tant sur le WAN que sur le LAN, à cela près que le LAN concerne plus les host que les router—deux rôles distingués par IPv6, le premier engendrant notamment la sélection automatique d'un routeur par défaut.

bng-ipv6-slaac-lan
SLAAC est utilisé côté LAN du CPE pour adresser les hôtes.

Dans ce schéma, soit l'opérateur configure manuellement l'interface LAN du CPE (assignation statique d'un /64), soit le CPE assigne automatiquement à son interface LAN un /64 qu'il alloue dans le préfixe délégué par DHCPv6 avec l'option IA_PD—le sujet même de la partie suivante, qui se prête d'ailleurs bien à l'accès Internet grand public. Le premier scénario s'applique davantage aux clients pro (qui peuvent d'ailleurs imposer leur propre /64 à assigner).

Cas pratique : SLAAC sur la Freebox

À titre d'exemple, une Freebox Révolution adresse les équipements du LAN avec SLAAC :

cap-bng-ipv6-freebox
Une Freebox Révolution annonçant à un hôte du LAN des paramètres IPv6 : le préfixe /64 dans lequel s'autoconfigurer et « d'autres informations » comme le serveur DNS.

Finalement, cette capture ressemble fortement à la précédente (tirée d'une simple simulation en lab). J'ai masqué certaines informations car elle provient d'un client réel : mon propre accès Internet ! On voit aussi que l'échange SLAAC succède à celui DHCPv4, l'hôte étant en dual-stack.

Rendez-vous sur la deuxième partie de l'article qui porte sur les mécanismes DHCPv6 et IPv6CP de PPP.