5. B4 Element
5. B4 Element
5.1. Definition
The B4 element is a function implemented on a dual-stack-capable node, either a directly connected device or a CPE, that creates a tunnel to an AFTR.
5.2. Encapsulation
The tunnel is a multipoint-to-point IPv4-in-IPv6 tunnel ending on a service provider AFTR.
See Section 7.1 for additional tunneling considerations.
Note: At this point, DS-Lite only defines IPv4-in-IPv6 tunnels; however, other types of encapsulation could be defined in the future.
5.3. Fragmentation and Reassembly
Using an encapsulation (IPv4-in-IPv6 or anything else) to carry IPv4 traffic over IPv6 will reduce the effective MTU of the datagram. Unfortunately, path MTU discovery [RFC1191] is not a reliable method to deal with this problem.
A solution to deal with this problem is for the service provider to increase the MTU size of all the links between the B4 element and the AFTR elements by at least 40 bytes to accommodate both the IPv6 encapsulation header and the IPv4 datagram without fragmenting the IPv6 packet.
However, as not all service providers will be able to increase their link MTU, the B4 element MUST perform fragmentation and reassembly if the outgoing link MTU cannot accommodate the extra IPv6 header. The original IPv4 packet is not oversized. The packet is oversized after the IPv6 encapsulation. The inner IPv4 packet MUST NOT be fragmented. Fragmentation MUST happen after the encapsulation of the IPv6 packet. Reassembly MUST happen before the decapsulation of the IPv4 packet. A detailed procedure has been specified in [RFC2473] Section 7.2.
5.4. AFTR Discovery
In order to configure the IPv4-in-IPv6 tunnel, the B4 element needs the IPv6 address of the AFTR element. This IPv6 address can be configured using a variety of methods, ranging from an out-of-band mechanism, manual configuration, or a variety of DHCPv6 options.
In order to guarantee interoperability, a B4 element SHOULD implement the DHCPv6 option defined in [RFC6334].
5.5. DNS
A B4 element is only configured from the service provider with IPv6. As such, it can only learn the address of a DNS recursive server through DHCPv6 (or other similar method over IPv6). As DHCPv6 only defines an option to get the IPv6 address of such a DNS recursive server, the B4 element cannot easily discover the IPv4 address of such a recursive DNS server, and as such will have to perform all DNS resolution over IPv6.
The B4 element can pass this IPv6 address to downstream IPv6 nodes, but not to downstream IPv4 nodes. As such, the B4 element SHOULD implement a DNS proxy, following the recommendations of [RFC5625].
To support a security-aware resolver behind the B4 element, the DNS proxy in the B4 element must also be security aware. Details can be found in [RFC4033] Section 6.
5.6. Interface Initialization
The B4 element can be implemented in a host and CPE in conjunction with other technologies such as native dual-stack. The host and the CPE SHOULD select to start only one technology during initialization. For example, if the CPE selects to start in native dual-stack mode, it SHOULD NOT initialize the B4 element. This selection process is out of scope for this document.
5.7. Well-Known IPv4 Address
Any locally unique IPv4 address could be configured on the IPv4-in-IPv6 tunnel to represent the B4 element. Configuring such an address is often necessary when the B4 element is sourcing IPv4 datagrams directly over the tunnel. In order to avoid conflicts with any other address, IANA has defined a well-known range, 192.0.0.0/29.
192.0.0.0 is the reserved subnet address. 192.0.0.1 is reserved for the AFTR element, and 192.0.0.2 is reserved for the B4 element. If a service provider has a special configuration that prevents the B4 element from using 192.0.0.2, the B4 element MAY use any other addresses within the 192.0.0.0/29 range.
Note: A range of addresses has been reserved for this purpose. The intent is to accommodate nodes implementing multiple B4 elements.