Transmission of IPv6 over IPv4 Domains without Explicit Tunnels
Extracted elements (22)
IPv4 fragmentation is permitted (the DF bit must not be set) because, while undesirable for performance, it is not disastrous and avoids black-holing packets when an intermediate IPv4 subnet has a smaller MTU than the 6over4 default of 1480 bytes.
The mechanism uses IPv4 multicast as a 'virtual Ethernet' to allow isolated IPv6 hosts on a link with no directly connected IPv6 router to become fully functional IPv6 hosts, without requiring IPv4-compatible addresses or manually configured tunnels.
The TTL is set to a low configurable value (default 8) to contain 6over4 traffic within the intended IPv4 domain and prevent packets from accidentally propagating beyond it.
IPv6 packets carried by 6over4 use IPv4 protocol type 41, the same value assigned in RFC 1933 for explicitly tunneled IPv6-in-IPv4, ensuring consistency with the broader IPv6 transition mechanism suite.
On ATM networks where IPv4 multicast relies on complex mechanisms, IPv6-over-IPv4-over-ATM is expected to perform worse than native IPv6 over ATM, making 6over4 less suitable for ATM deployments.
An IPv6 address prefix used for stateless autoconfiguration of an IPv4 (6over4) interface MUST have a length of 64 bits, except for a special transition case described in Section 7.
Any IPv6 prefix assigned to a 6over4 subnet MUST be unique within its scope (site-local or global), just as for any other IPv6 subnet prefix.
During transition, when a router handles both native LAN and 6over4 on the same physical interface, the prefix-length for link-local addresses MUST be 128 (not 64) so that the two address types can be distinguished.
If IPv4 options are present, padding SHOULD be added to the IPv4 header so that the IPv6 header starts on a 32-bit boundary offset from the end of the datalink header.
IPv4 multicast MUST be available in the domain. An IPv6 packet with a multicast destination address DST MUST be transmitted to the IPv4 Organization-Local Scope multicast address formed as 239.OLS.DST14.DST15, where DST14 and DST15 are the last two bytes of the IPv6 multicast address.
The IPv4 'do not fragment' bit MUST NOT be set in the encapsulating IPv4 header. This allows intermediate IPv4 subnets to fragment oversized packets rather than dropping them.
The IPv4 Time to Live field SHOULD be set to a low value to prevent 6over4 packets from accidentally leaking out of the IPv4 domain. This MUST be a configurable parameter with a recommended default of 8.
IPv6 multicast is mapped to IPv4 multicast addresses in the 239.192.0.0/16 block (Organization-Local Scope). The OLS octet SHOULD be 192. If the /16 block is exhausted, expansion blocks from RFC 2365 (using only a /16 sized sub-block) may be used.
Neighbor Discovery uses three IPv4 multicast groups in the 6over4 domain: 239.OLS.0.1 (all-nodes), 239.OLS.0.2 (all-routers), and 239.OLS.Y.Z (solicited-node, derived from the low-order 24 bits of the target's IPv4 address).
The default MTU for IPv6 packets over an IPv4 domain is 1480 octets (1500 minus 20 bytes for the IPv4 header). It may be overridden by a Router Advertisement MTU option or by manual node configuration.
The Interface Identifier for a 6over4 interface is the 32-bit IPv4 address of that interface (in network byte order), left-padded with zeros to 64 bits. The Universal/Local bit is zero, indicating the identifier is not globally unique.
The IPv6 link-local address for a 6over4 virtual interface is formed by appending the 64-bit Interface Identifier (zero-padded IPv4 address) to the prefix FE80::/64, yielding FE80::W.X.Y.Z.
Boundary routers MUST discard multicast IPv4 packets whose source or destination is an Organization-Local Scope multicast address if they arrive on interfaces outside that scope, to prevent spoofed 6over4 multicast injection.
IPv6 security (IPsec) MUST be implemented even when IPv4 security is available, because IPv4 security does not protect IPv6 traffic once it leaves the 6over4 domain. Redundant double-encryption SHOULD be avoided for efficiency; apply security at the IPv6 layer.
To defend against spurious unicast 6over4 packets, boundary routers MUST discard incoming IPv4 packets with protocol type 41 from unknown sources. The recommended technique is to configure the boundary router to accept protocol-41 packets only from a trusted source address range.
IPv6 packets are encapsulated in IPv4 packets using IPv4 protocol type 41. The IPv4 header carries source and destination IPv4 addresses; the IPv4 body contains the IPv6 header followed immediately by the payload, with no additional headers between them.
The Source/Target Link-layer Address option for 6over4 unicast is 8 bytes: Type (1 byte, 1=source or 2=target), Length (1 byte, value=1 meaning 8 octets), 2 reserved zero bytes, and the 32-bit IPv4 address in network byte order.