6. AFTR Element
6. AFTR Element
6.1. Definition
An AFTR element is the combination of an IPv4-in-IPv6 tunnel endpoint and an IPv4-IPv4 NAT implemented on the same node.
6.2. Encapsulation
The tunnel is a point-to-multipoint IPv4-in-IPv6 tunnel ending at the B4 elements.
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.
6.3. Fragmentation and Reassembly
As noted previously, fragmentation and reassembly need to be taken care of by the tunnel endpoints. As such, the AFTR MUST perform fragmentation and reassembly if the underlying link MTU cannot accommodate the encapsulation overhead. Fragmentation MUST happen after the encapsulation on the IPv6 packet. Reassembly MUST happen before the decapsulation of the IPv6 header. A detailed procedure has been specified in [RFC2473] Section 7.2.
Fragmentation at the Tunnel Entry-Point is a lightweight operation. In contrast, reassembly at the Tunnel Exit-Point can be expensive. When the Tunnel Exit-Point receives the first fragmented packet, it must wait for the second fragmented packet to arrive in order to reassemble the two fragmented IPv6 packets for decapsulation. This requires the Tunnel Exit-Point to buffer and keep track of fragmented packets. Consider that the AFTR is the Tunnel Exit-Point for many tunnels. If many devices simultaneously source a large number of fragmented packets through the AFTR to its managed B4 elements, this will require the AFTR to buffer and consume enormous resources to keep track of the flows. This reassembly process will significantly impact the AFTR's performance. However, this impact only happens when many clients simultaneously source large IPv4 packets. Since we believe that the majority of the clients will receive large IPv4 packets (such as watching video streams) instead of sourcing large IPv4 packets (such as sourcing video streams), reassembly is only a fraction of the overall AFTR's workload.
When the AFTR's resources are running below a pre-defined threshold, the AFTR SHOULD generate a notification to the administrator before the resources are completely exhausted. The threshold and notification procedures are implementation dependent and are out of scope for this document.
Methods to avoid fragmentation, such as rewriting the TCP Maximum Segment Size (MSS) option or using technologies such as the Subnetwork Encapsulation and Adaptation Layer as defined in [RFC5320], are out of scope for this document.
6.4. DNS
As noted previously, a DS-Lite node implementing a B4 element will perform DNS resolution over IPv6. As a result, DNS packets are not expected to go through the AFTR element.
6.5. Well-Known IPv4 Address
The AFTR SHOULD use the well-known IPv4 address 192.0.0.1 reserved by IANA to configure the IPv4-in-IPv6 tunnel. That address can then be used to report ICMP problems and will appear in traceroute outputs.
6.6. Extended Binding Table
The NAT binding table of the AFTR element is extended to include the source IPv6 address of the incoming packets. This IPv6 address is used to disambiguate between the overlapping IPv4 address space of the service provider customers.
By doing a reverse lookup in the extended IPv4 NAT binding table, the AFTR knows how to reconstruct the IPv6 encapsulation when the packets come back from the Internet. That way, there is no need to keep a static configuration for each tunnel.