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 2

Suite de la première partie de l'IPv6 appliqué au BNG—qui se concentrait sur le mécanisme SLAAC pour l'adressage WAN et LAN du CPE—nous étudions ici les autres mécanismes existants, à savoir DHCPv6 et IPv6CP de PPP.

Plan de l'article

DHCPv6 pour l'adressage WAN

Sans surprise, DHCPv6 assure un rôle globalement similaire à celui de DHCPv4 mais comporte des différences fondamentales dont :

Finalement, sa RFC 8415 résume bien ces points :


    DHCPv6 can provide a device with addresses assigned by a DHCPv6
    server and other configuration information […]

    DHCPv6 also provides a mechanism for automated delegation of IPv6
    prefixes using DHCPv6, as originally specified in [RFC3633].  Through
    this mechanism, a delegating router can delegate prefixes to
    requesting routers.  Use of this mechanism is specified as part of
    [RFC7084] and by [TR-187].

    DHCP can also be used just to provide other configuration options
    (i.e., no addresses or prefixes).  That implies that the server does
    not have to track any state; thus, this mode is called "stateless DHCPv6".

Et met bien en évidence la combinaison DHCPv6-SLAAC :


    Parameters can be provided statelessly, or in combination with
    stateful assignment of one or more IPv6 addresses and/or IPv6
    prefixes.  DHCPv6 can operate either in place of or in addition to
    stateless address autoconfiguration (SLAAC).

Pourquoi DHCPv6 ne fournit pas subnet mask et gateway ?

Question pertinente et la raison provient sans doute de l'antériorité de SLAAC : conçu avant DHCPv6, il fournit déjà ces paramètres ; par conséquent, nul besoin d'introduire de la redondance en les fournissant avec DHCPv6. Cela dit, trois drafts défendent pourtant cette dernière possibilité :

Si aucun ne semble avoir abouti, leur lecture n'en reste pas moins instructive. Le premier, en particulier, résume bien la motivation :


    In many IPv6 deployments, particularly in edge networks, end devices
    obtain configuration information about default routers, on-link
    prefixes and addresses from Router Advertisements as defined in
    Neighbor Discovery.  In some deployments, however, there is a strong
    desire not to use Router Advertisements at all and to perform all
    configuration via DHCP [RFC3315].  For example, network
    administration may want to control all host configuration through a
    single centralized DHCP service in order to more closely manage which
    addresses are assigned and in use.

Et cela s'entend. Configurer DHCPv6 et SLAAC conjointement présente une certaine learning curve. Alors que DHCPv4 se suffit à lui-même (en particulier sur les LAN), un admin système-réseau doit ici comprendre les limites de DHCPv6, doit positionner les flags adéquats avec SLAAC et le configurer de sorte à fournir réseau de rattachement (on-link) et route par défaut (gateway). La présentation qui accompagne le draft se veut ainsi plus franche et amusante :

« Why does IPv6 take away options that were available in DHCPv4? »
« I want to do this, I did it with IPv4, it works, why can't I can't do this with IPv6? »

L'une de ses diapositives reprend d'ailleurs brièvement l'historique pour expliquer le pourquoi de l'absence de ces options dans DHCPv6 :

bng-ipv6-dhcpv6-history
Diapositive résumant et expliquant le pourquoi de l'absence des options évoquées ci-dessus dans DHCPv6.

DHCPv6 over PPP

Avant d'entamer les exemples et les captures, notons que le standard de DHCPv6 le rend nativement compatible avec PPP :


    The basic operation of DHCPv6 provides configuration for clients
    connected to the same link as the server.

La notion de link étant définie ainsi :


    A communication facility or medium over
    which nodes can communicate at the link
    layer, i.e., the layer immediately below
    IP.  Examples are Ethernet (simple or
    bridged); Point-to-Point Protocol (PPP) and
    PPP over Ethernet (PPPoE) links; and
    Internet-layer (or higher) "tunnels", such
    as tunnels over IPv4 or IPv6 itself.

Autrement dit, DHCPv6 peut délivrer une adresse à une interface Ethernet mais aussi une interface PPP (et peut déléguer un préfixe au CPE associé). Cela contraste avec DHCPv4 qui—à ma connaissance—n'est pas ou peu supporté sur PPP (IPCP, utilisé pour l'adressage, diffère d'IPv6CP comme on le verra).

DHCPv6 stateless

Illustrons les propos suivants :


    Stateless DHCP [RFC3736] is used when DHCP is not used for obtaining
    a lease but a node (DHCP client) desires one or more DHCP "other
    configuration" parameters, such as a list of DNS recursive name
    servers or DNS domain search lists [RFC3646].

Avec des captures :

Remarquons qu'en mode stateless, l'échange client-serveur se déroule donc en deux messages seulement (Information-Request et Reply) :


    5.1.  Client/Server Exchanges Involving Two Messages

       When a DHCP client does not need to have a DHCP server assign IP
       addresses or delegated prefixes to it, the client can obtain other
       configuration information such as a list of available DNS servers
       [RFC3646] or NTP servers [RFC5908] through a single message and reply
       exchange with a DHCP server.

Alors qu'en mode stateful, comme nous allons le voir, l'échange se déroule en quatre messages (comme en DHCPv4) :


    5.2.  Client/Server Exchanges Involving Four Messages

       To request the assignment of one or more addresses and/or delegated
       prefixes, a client first locates a DHCP server and then requests the
       assignment of addresses and/or delegated prefixes and other
       configuration information from the server.

À moins que client n'active l'option Rapid Commit—afin d'accélérer la procédure d'adressage—auquel cas l'échange s'opère en deux messages :


    The Rapid Commit option is used to signal the use of the two-message
    exchange for address assignment.

Cette option existant aussi en DHCPv4 (RFC 4039).

DHCPv6 stateful

Comme dit plus haut, DHCPv6 permet l'assignation d'adresses et la délégation de préfixes via les deux options IA_NA et IA_PD (j'exclus l'option IA_TA utilisée pour l'assignation d'adresses temporaires—le principe, point de vue échange protocolaire, reste similaire aux adresses non-temporaires) :


    The client uses IA_NA options (see Section 21.4) to request the
    assignment of non-temporary addresses, IA_TA options (see
    Section 21.5) to request the assignment of temporary addresses, and
    IA_PD options (see Section 21.21) to request prefix delegation.

Concrètement—et comme énoncé dans les bases avec les best practices de redécoupage d'un préfixe IPv6—le BNG délègue typiquement un préfixe /48 ou un /56 au client (le CPE ici) qui le redécoupe en un ou plusieurs /64 pour son ou ses interfaces LAN :


    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.

    For example, if the client in Figure 1 were delegated
    2001:db8:0::/48, it might generate 2001:db8:0:1::/64 and
    2001:db8:0:2::/64 for assignment to the two links in the
    subscriber network.

Schématiquement :

bng-ipv6-dhcpv6
Le BNG assigne au CPE une adresse /128 pour l'interface WAN et délègue un préfixe /48 que le CPE redécoupe en /64 pour ses interfaces LAN.

Soit en capture :

Dans les captures ci-dessus, le CPE émet deux requêtes Solicit distinctes pour obtenir son adresse (option IA_NA) puis son préfixe (option IA_PD). En théorie, une seule transaction suffit (mais je ne suis pas parvenu à le tester sur le matériel en question) :


    This document assumes that a client SHOULD use a single transaction
    for all of the IA options required on an interface; this simplifies
    the client implementation and reduces the potential number of
    transactions required (for the background on this design choice,
    refer to Section 4 of [RFC7550]).

Enfin, arrêtons-nous un instant sur la table de routage du CPE (qu'importe le cas IPoE ou PPP) :


    CPE#show ipv6 route

    ND  ::/0 [2/0] via FE80::ED6:A4FF:FE19:0, GigabitEthernet0/0
    S   2001:DB8:ABCD::/48 [1/0] via Null0, directly connected
    C   2001:DB8:ABCD:1::/64 [0/0] via GigabitEthernet0/1, directly connected
    C   2001:DB8:ABCD:2::/64 [0/0] via GigabitEthernet0/2, directly connected
    L   2001:DB8:ABCD:1::1/128 [0/0] via GigabitEthernet0/1, receive
    L   2001:DB8:ABCD:2::1/128 [0/0] via GigabitEthernet0/2, receive
    LC  2001:DB8:CAFE:BABE:70DD:C85A:96D5:1FE4/128 [0/0] via GigabitEthernet0/0, receive
    L   FF00::/8 [0/0] via Null0, receive

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

Nous retrouvons l'adresse /128 assignée par le BNG ainsi que deux /64 alloués dans le /48 délégué par le BNG et assignés aux interfaces LAN. Les items de conf suivants rendent possible cette allocation-assignation automatique :


    !
    interface GigabitEthernet0/0
     description WAN
     no ip address
     ipv6 enable
     ipv6 address autoconfig default
     ipv6 address dhcp
     ipv6 dhcp client pd PREFIX-FROM-PROVIDER
    !
    interface GigabitEthernet0/1
     description LAN1
     no ip address
     ipv6 enable
     ipv6 address PREFIX-FROM-PROVIDER ::1:0:0:0:1/64
    !
    interface GigabitEthernet0/2
     description LAN2
     no ip address
     ipv6 enable
     ipv6 address PREFIX-FROM-PROVIDER ::2:0:0:0:1/64
    !

La variable PREFIX-FROM-PROVIDER reçoit comme valeur le préfixe délégué par le BNG, de sorte à pouvoir la référencer plus tard dans les interfaces LAN pour l'allocation-assignation automatique des /64.

DHCPv6 pour l'adressage LAN

Comme la section sur SLAAC pour l'adressage LAN, celle-ci se veut brève, les concepts de DHCPv6 pour le WAN s'appliquant aussi au LAN.

bng-ipv6-dhcpv6-lan
DHCPv6 et son option IA_NA est utilisé côté LAN du CPE pour adresser les hôtes.

Rappelons que DHCPv6 se combine avec SLAAC afin d'annoncer aux hôtes, non seulement leur adresse /128, mais aussi le /64 de rattachement (dit on-link) à laquelle appartient l'adresse. Sans cela, les hôtes sur le même LAN ne peuvent communiquer entre eux. En effet, pour citer la RFC 5942 :


    The assignment of an IPv6 address -- whether through IPv6
    stateless address autoconfiguration [RFC4862], DHCPv6 [RFC3315],
    or manual configuration -- MUST NOT implicitly cause a prefix
    derived from that address to be treated as on-link and added to
    the Prefix List.  A host considers a prefix to be on-link only
    through explicit means, such as those specified in the on-link
    definition in the Terminology section of [RFC4861] (as modified
    by this document) or via manual configuration.

De plus, les hôtes ajoutent automatiquement une route par défaut vers le CPE grâce à SLAAC et non DHCPv6 qui ne véhicule pas ce paramètre.

Notons qu'en combinant DHCPv6 et SLAAC comme décrit ci-dessus, l'hôte possède donc deux adresses IPv6—celle assignée par DHCPv6 et celle qu'il autoconfigure dans le /64 annoncé par SLAAC. Pour rappel, c'est le flag Autonomous de SLAAC qui engendre cette autoconfiguration d'adresse chez l'hôte. Et ne pas le positionner serait une mauvaise idée car, pour reprendre la RFC 4862 :


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

L'hôte ignorera le /64 annoncé et se retrouvera sans réseau on-link (mais on avait vu que certaines implémentations ne respectent pas cette règle).

IPv6CP pour l'adressage WAN

PPP tend un piège avec IPv6CP (RFC 5072), le soi-disant équivalent d'IPCP pour IPv4 :


    This document defines the method for sending IPv6 packets over PPP
    links, the NCP for establishing and configuring the IPv6 over PPP,
    and the method for forming IPv6 link-local addresses on PPP links.

En effet, IPv6CP négocie les IID (Interface ID) des nœuds du lien PPP afin de s'assurer de leur unicité avant de former les LLA respectives :


    This Configuration Option provides a way to negotiate a unique, 64-
    bit interface identifier to be used for the address autoconfiguration
    [3] at the local end of the link (see Section 5).

En termes clairs, IPv6CP ne permet pas l'échange ou l'assignation d'adresses IPv6, contrairement à IPCP pour les adresses IPv4. Le TR-187 du Broadband Forum le rappelle bien :


    The main difference between IPCP and IPV6CP is that IPCP is able to
    complete the configuration procedure for the client and to allocate
    an IPv4 address to the client, while IPV6CP is only used to configure
    the link-local address.

Une fois la phase IPv6CP terminée, l'assignation GUA (ou ULA) passe par les mécanismes SLAAC ou DHCPv6 (c'est pourquoi nous les avons vus avant) :


    In order to configure an IPv6 Global Unicast Address an additional
    mechanism is required. This mechanism can be SLAAC or DHCPv6.

Cela dit, à l'instar d'IPCP qui permet à un pair (BNG) d'assigner une adresse IPv4 à l'autre (CPE), IPv6CP permet d'assigner un IID. Par conséquent, assigner une adresse précise devient indirectement possible—sans DHCPv6 et son option IA_NA—en combinant IPv6CP et SLAAC.

Enfin, IPv6CP s'assurant de l'unicité des IID sur le lien PPP, la procédure DAD (Duplicate Address Detection) devient redondante et peut être désactivée :


    As long as the interface identifier is negotiated in the IPV6CP phase
    of the PPP connection setup, it is redundant to perform duplicate
    address detection (DAD) as a part of the IPv6 Stateless Address
    Autoconfiguration protocol […]

Voici des captures sur le lien WAN d'un CPE de test terminé sur un vrai BNG Cisco (aussi je masque certaines informations) :

cap-bng-ipv6-slaac-ppp-iid-req
IPv6CP—Le CPE indique son IID au BNG, dérivé de l'adresse MAC 0c:d8:a0:c6:5c:00.
cap-bng-ipv6-slaac-ppp-iid-nakn
IPv6CP—Le BNG refuse l'IID avec un Nak et assigne un autre IID au CPE.

Logs du BNG :


    Vi2.1 IPV6CP: I CONFREQ [REQsent] id 1 len 14
    Vi2.1 IPV6CP:    Interface-Id 0ED8:A0FF:FEC6:5C00 (0x010A0ED8A0FFFEC65C00)
    Vi2.1 IPV6CP AUTHOR: Says use id 0000:0000:0000:0001
    Vi2.1 IPV6CP: O CONFNAK [REQsent] id 1 len 14
    Vi2.1 IPV6CP:    Interface-Id 0000:0000:0000:0001 (0x010A0000000000000001)

Logs du CPE :


    # Avant l'établissement de la session PPP, l'IID est 0ed8:a0ff:fec6:5c00

    CPE#show ipv6 int brief

    Dialer1                [administratively down/down]
        FE80::ED8:A0FF:FEC6:5C00

    # Après l'établissement de la session PPP, l'IID est 0000:0000:0000:0001

    CPE#debug ipv6 address

    [PPP Events]IPV6ADDR: Notification: Address FE80::ED8:A0FF:FEC6:5C00/10 is down on Dialer1
    [PPP Events]IPV6ADDR: Notification: Address FE80::ED8:A0FF:FEC6:5C00 removed from Dialer1
    [PPP Events]IPV6ADDR: Notification: Address FE80::1 added to Dialer1
    [PPP Events]IPV6ADDR: Notification: Address FE80::1/10 is up on Dialer1

    CPE#show ipv6 int brief

    Dialer1                [up/up]
        FE80::1
        2001:DB8:CAFE:BABE::1

    CPE#show run int dialer 1

    interface Dialer1
     ipv6 address FE80::1 link-local # commande automatiquement ajoutée par le CPE à la réception de l'IID assigné par le BNG !

Les logs dévoilent bien le comportement interne du CPE :

L'adresse GUA est générée dans le /64 annoncé par SLAAC—non visible dans la capture, car déjà illustré dans la première partie.

Bonne question car l'interface PPP (le Dialer1) ne porte pas d'adresse MAC—plus généralement, d'identifiant au format EUI-48 ou EUI-64. Le CPE emprunte alors, en l'occurrence, l'adresse MAC de l'interface Ethernet portant le PPPoE et liée à l'interface PPP, conformément à :


    If an IEEE global identifier (EUI-48 or EUI-64) is available
    anywhere on the node, it should be used to construct the tentative
    interface identifier due to its uniqueness properties.

Conclusion

Voir le résumé en début de première partie !