Lightweight 4over6: An Extension to the Dual-Stack Lite Architecture
Extracted elements (25)
IPv4 fragmentation identifiers could be rewritten by an lwB4 to fall within its allocated port set to prevent reassembly collisions when multiple B4s share the same IPv4 address. However, splitting the identifier space in this fashion would increase the probability of reassembly collision for all connections through the lwB4.
Lightweight 4over6 moves the NAPT44 function from the centralized AFTR to the distributed lwB4 CPE. This reduces AFTR state from per-flow (active NAPT sessions) to per-subscriber (binding table entries), lowering memory, processing, and logging overhead at the service provider and eliminating the need for a Carrier Grade NAT.
lw4o6 is compared to MAP-E (RFC 7597): both provide complete independence between IPv6 subnet prefixes and IPv4 addresses. MAP-E introduces an algorithmic IPv6-to-IPv4 address relationship enabling direct meshed connectivity, while lw4o6 maintains per-subscriber binding state centrally and uses hub-and-spoke forwarding.
Lightweight 4over6 uses the same IPv4-in-IPv6 tunneling mechanism as DS-Lite (RFC 6333). RFC 6333 sections on encapsulation (5.2/6.2), fragmentation and reassembly (5.3/6.3), and tunneling/Traffic Class mapping (7.1) MUST be implemented by both the lwB4 and lwAFTR.
For both the lwAFTR and the lwB4, ICMPv6 MUST be handled as described in RFC 2473. The DNS considerations in Sections 5.5 and 6.4 of RFC 6333 apply to lw4o6, and lw4o6 implementations MUST comply with all requirements stated there.
For TCP and UDP traffic, the NAPT44 in the lwB4 MUST conform to the behavior and best current practices documented in RFC 4787, RFC 5508, and RFC 5382. If the lwB4 supports DCCP, the requirements in RFC 5597 MUST also be implemented.
If the lwB4's IPv6 encapsulation source address changes for any reason (e.g., DHCPv6 lease expiry), the lwB4's dynamic provisioning process MUST be re-initiated. When the public IPv4 address or Port Set ID changes, the lwB4 MUST flush its NAPT table.
In a Lightweight 4over6 domain, the binding information MUST be synchronized across the lwB4s, the lwAFTRs, and the provisioning server. It is RECOMMENDED that operators use a single provisioning mechanism to prevent interworking complexity.
On receipt of an ICMPv6 error message (Type 1, Code 5) from the lwAFTR, the lwB4 MUST validate that the source address matches the configured lwAFTR address. If they do not match, the lwB4 MUST discard the ICMP error message to prevent acceptance of forged messages.
The lwAFTR MUST rate-limit ICMPv6 error messages sent back to lwB4s to defend against DoS attacks generated by abusive users.
The lwAFTR MUST support hairpinning of traffic between two lwB4s by performing decapsulation and re-encapsulation of packets from one lwB4 destined to another lwB4 on the same lwAFTR. The hairpinning policy MUST be configurable.
The lwAFTR MUST synchronize its binding table with the port-restricted address provisioning process. The lifetime of binding table entries MUST be synchronized with the lifetime of address allocations. If not participating in provisioning, synchronization MUST occur via other methods such as out-of-band static update.
The lwB4 MUST implement DHCPv6-based configuration using OPTION_S46_CONT_LW as described in RFC 7598; the softwire lifetime is bound to the DHCPv6 lease lifetime. If stateful IPv4 configuration or additional IPv4 options are required, DHCP 4o6 (RFC 7341) MUST be used.
The lwB4 MUST support dynamic port-restricted IPv4 address provisioning using the port-set algorithm from RFC 7597 Section 5.1. The number of a-bits SHOULD be 0, allocating a single contiguous port set to each lwB4.
The NAPT44 in the lwB4 MUST implement ICMP message handling conforming to RFC 5508. If the lwB4 receives an ICMP error for errors detected inside the IPv6 tunnel, it relays the ICMP error message to the original source, conforming to RFC 2473 Section 8.
Unless an lwB4 is allocated a full IPv4 address, it is RECOMMENDED that PSIDs containing the system ports (0-1023) not be allocated to lwB4s, as these ports are more likely to be reserved by middleware.
When the lwAFTR receives an outbound IPv4-in-IPv6 packet and no binding table match is found (e.g., no matching IPv4 address, port out of range), it MUST discard or apply a policy on the packet. When no binding match is found for an inbound IPv4 packet, the lwAFTR MUST discard it.
When the lwB4 receives an IPv4-in-IPv6 packet, if the IPv6 source address does not match the configured lwAFTR address, the packet MUST be discarded. If the decapsulated IPv4 packet has an invalid destination address or port not matching the lwB4's configuration, it MUST be dropped.
For inbound ICMPv4 echo request/reply (Type 0 or 8), the lwAFTR uses the ICMP Identifier field as the source port for binding table lookup and forwards to the matched lwB4 IPv6 address. For all other ICMPv4 types, the embedded transport-layer header in the ICMP data field is used to extract the source port per RFC 5508 REQ-3.
The Lightweight AFTR (lwAFTR) is an IPv4-in-IPv6 tunnel endpoint that maintains per-subscriber address binding only and does not perform NAPT44. It uses its binding table for both ingress filtering of outbound packets and encapsulation of inbound IPv4 packets destined to the correct lwB4.
The Lightweight B4 (lwB4) is a dual-stack CPE function that supports port-restricted IPv4 address allocation, implements NAPT44, and creates an IPv4-in-IPv6 softwire tunnel to an lwAFTR. It differs from a DS-Lite B4 in that it performs the NAPT44 function rather than delegating it to the AFTR.
The lwAFTR binding table contains 3-tuple entries: the lwB4's IPv6 address, the allocated public IPv4 address, and the restricted port set. This contrasts with DS-Lite's 5-tuple NAPT table, as the lwAFTR requires only per-subscriber state.
As the port space for a subscriber shrinks due to IPv4 address sharing, the randomness of source port numbers is decreased significantly, making it easier for an attacker to guess the port number in use. This can result in attacks ranging from throughput reduction to broken connections or data corruption.
Non-contiguous port sets (which may be generated pseudorandomly per RFC 6431) improve port number randomness compared to contiguous port sets, provided the attacker is outside the lw4o6 domain and does not know the port-set generation algorithm. Contiguous port sets do not reduce the guessing threat.
The lw4o6 /128 tunnel source IPv6 address is structured as: 64-bit operator-assigned prefix (right-padded with zeros to 64 bits), 16-bit zero padding, 32-bit public IPv4 address, and 16-bit PSID (left-padded with zeros; all zeros if no PSID is provisioned).