IPv6 in access and L2TP

Theoretical foundations and architecture

Today a subscriber needs IPv6 as much as IPv4, and the BNG must give it an address for the CPE itself, a prefix for the home network and DNS information, without breaking accounting, VRF binding and routing. PPPoE and IPoE do this differently: PPP negotiates only the interface identifier (IPv6CP), while the prefixes come from Router Advertisement and DHCPv6 (IA_NA for the WAN address, IA_PD for the delegated prefix). The lesson covers the M/O flags and RA parameters, the difference between SLAAC and DHCPv6, prefix delegation and its routing on the BNG, and the RADIUS attributes for IPv6. It then reviews the transition mechanisms: DS-Lite (RFC 6333) with the AFTR, NAT64/DNS64, 464XLAT and 6rd. The second part is L2TPv2 (RFC 2661) for wholesale access: the LAC accepts the PPP session, the LNS of another operator terminates it, and RADIUS delivers the tunnel attributes (RFC 2868). It assumes the knowledge of PPPoE/IPoE, RADIUS and CGNAT from the earlier lessons of the module.

How a subscriber gets IPv6: the roles of RA and DHCPv6

In IPv4 DHCP gives the address, mask, gateway and DNS in one exchange. In IPv6 the functions are split: the CPE learns its default gateway only from the Router Advertisement (RFC 4861), while DHCPv6 (RFC 8415) does not carry a gateway. The RA is sent in reply to a Router Solicitation and periodically; it contains the M flag (managed: the address via DHCPv6) and the O flag (other: other parameters such as DNS via DHCPv6), the router lifetime (1800 s by default, 0 means "not a gateway"), the RA interval (RFC 4861 default maximum 600 s, many platforms use 200 s) and the Prefix Information Option (PIO) with the prefix, the valid/preferred lifetimes (2592000 and 604800 s by default) and the L (on-link) and A (autonomous: SLAAC may build an address) flags. For SLAAC the prefix must be a /64. The operator practice: on the WAN link set M=1 or SLAAC with O=1, and hand out the LAN prefix via DHCPv6 IA_PD. Long RA intervals slow the detection of a gateway failure and of a prefix change: on broadband access they are kept in hundreds of seconds, not minutes.

PPPoE and IPoE: how the start differs

In PPPoE, after LCP and authentication, the IPv6CP NCP (RFC 5072) negotiates only the 64-bit interface identifier; the WAN address is built by SLAAC from the RA or issued by DHCPv6 IA_NA, and PD is requested by a separate DHCPv6 exchange. The RADIUS profile controls the prefixes: Framed-IPv6-Prefix (97) for the WAN address, Delegated-IPv6-Prefix (123, RFC 4818) for PD, Framed-IPv6-Pool (100), Framed-IPv6-Route (99), Framed-Interface-Id (96), DNS-Server-IPv6-Address (169, RFC 6911). IPoE has no PPP session: the life cycle is set by the RA, DHCPv6 and the lease, and the subscriber is identified by the link-local address, the DUID and the relay data (option 18 Interface-ID and 37 Remote-ID, RFC 3315/4649) from the access node, which acts as a Lightweight DHCPv6 Relay Agent (RFC 6221). Without an LDRA on the access node the BNG does not know which port the subscriber is on.

Prefix delegation and its routing

IA_PD (RFC 3633, then RFC 8415) gives the CPE a LAN prefix: most often /56 or /60 (rarely /48), sometimes /64 for simple devices. The pool size is computed from the length difference: a /40 pool with /56 holds 2^16 = 65536 subscribers, a /48 pool with a /64 per WAN holds 65536 too. The main task of the BNG is to install, for every delegated prefix, a route with the CPE link-local address as the next hop on the subscriber interface, otherwise return traffic from the core cannot reach the home network. These routes are not advertised into the IGP one by one: the BNG summarizes the pool (one route for a /40) and announces it into the IGP/BGP, and when the session is cleared the route disappears. For PPPoE the route disappears with the interface. For IPoE it depends on the lease: with an unstable lease use short T1/T2 and reachability checks so as not to keep routes of "dead" CPEs. When a BNG fails and a backup takes over, the delegated prefix must stay the same (a binding in RADIUS or synchronization), otherwise the subscriber changes the prefix and breaks the home network.

DS-Lite, NAT64/DNS64, 464XLAT, 6rd

DS-Lite (RFC 6333): the access network is IPv6-only, and the CPE (B4, Basic Bridging BroadBand element) encapsulates IPv4 packets in IPv6 toward the operator AFTR (Address Family Transition Router), where NAT44 is performed. The CPE learns the AFTR address from DHCPv6 option 64 (AFTR-Name, RFC 6334) and resolves it through DNS. Private IPv4 addresses of subscribers are not needed in the operator network and RFC 6598 addresses for NAT444 are not spent; the B4 IPv6 address is part of the translation key, so different subscribers may have identical private IPv4. Downsides: the tunnel adds a 40-byte header (1460 for the inner IPv4 on a 1500 MTU), accounting must use the subscriber IPv6, and ports and logging are the same as in CGNAT. NAT64 (RFC 6146) with DNS64 (RFC 6147) gives IPv6-only clients access to IPv4 servers: DNS64 synthesizes AAAA from A with the prefix 64:ff9b::/96 (RFC 6052) or its own, and NAT64 translates the packets. Applications with IPv4 literals do not work; 464XLAT (RFC 6877) closes this: a CLAT on the device translates IPv4 into IPv6 and a PLAT (NAT64) at the operator returns it to IPv4; the scheme is common in mobile networks. 6rd (RFC 5969) is the opposite variant: IPv6 over an IPv4 access network without state, the subscriber prefix is built from its IPv4 address and the operator 6rd prefix, with a Border Relay at the edge. Today it is a temporary measure when the access cannot be moved to IPv6.

L2TPv2: LAC, LNS and wholesale

L2TPv2 (RFC 2661) carries PPP frames over IP. The LAC (L2TP Access Concentrator) accepts the PPP session and the LNS (L2TP Network Server) terminates it. The transport is UDP, port 1701. First the control connection (tunnel) is built: SCCRQ - SCCRP - SCCCN, then a session per subscriber: ICRQ - ICRP - ICCN. Control messages are reliable (Ns/Nr numbers, ZLB as an acknowledgement) and the keepalive is the Hello message (60 s by default). The tunnel can be authenticated with a shared secret (challenge/response, MD5); L2TP has no encryption, and IPsec (RFC 3193) provides it when needed. Tunnel ID and Session ID are local to each side. The overhead is IP 20 + UDP 8 + L2TP 6-12 + PPP 2-4 bytes, so the MSS is chosen (usually 1400-1412) bearing in mind that PPPoE on the LAC already gives an MTU of 1492.