IPv6 destination header option for IPv4 translator mapping notification

To overcome the shortage of IPv4 addresses within the Internet, Network Address and Port Translators (NATs) have been widely deployed, such that multiple IPv4 nodes can share a single IPv4 address. However, that method is known to break certain application protocols, which need to know their own assigned external IP address and/or port number (i.e. the transport address). New solutions are now under consideration which would extend NAT mechanisms such that IPv6 nodes could access the IPv4 Internet. This memo proposes an in-band method for such a IPv6-IPv4 NAT to notify affected IPv6 applications of the IPv4 transport address associated with any of their active communication flows. A new option for the IPv6 Destination extension header, the Translated Flow Mapping option is hereby defined to carry this information.

TBD. The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in .

An IPv4-IPv6 NAT performs two separate functions: It receives IPv4 packets on its IPv4 interface, translates them to IPv6. To that end, for each IPv4 packet, it crafts a new IPv6 header to replace the IPv4 header, may modify the inner transport protocol header. Then, it sends the resulting translated IPv6 packets through its IPv6 interface. Reciprocally, it translates IPv6 packets into IPv4 packets. The details of IPv4-IPv6 translation are beyond the scope of this document, please refer to [whatever IETF ends up specifying for this] instead.

When a translator receives an IPv4 packet, following certain conditions, it inserts an IPv6 Destination extension header containing a Translated Flow Mapping option (as defined in the next section). As a general rule, this option MUST NOT be inserted, if the resulting packet would exceed the known MTU to the IPv6 destination, or 1280 bytes if there is no known MTU.

For connection-oriented transport protocols, this option SHOULD be inserted is part of the protocol handshake, and SHOULD NOT be inserted otherwise.

This option SHOULD be inserted within DCCP Sync, DCCP Sync/Ack and DCCP Listen packets. See and .

TBD.

This option SHOULD be inserted within TCP SYN and TCP SYN/ACK packets. See .

Processing of the flow mapping option is optional. In fact, an IPv6 implementation that does not support the flow mapping option MUST ignore it, according to (this is not a new requirement for IPv6 implementation). The content of the flow mapping option is merely informational. Hence, there are no particular requirements as regards its processing. An IPv6 stack that implements the flow mapping option MAY store and or forward the flow mapping informations, as it sees fit. For instance, it might forward the informations to the application (see below for an example API) if it requests them.

0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Option Type | Option Length | Mapped Port | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Mapped IPv4 Address | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Remote IPv4 Address | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ The Translated Flow Mapping option format is defined as follow: XXX (TBD: IANA) 12 (12 bytes) If the type of the first header that is not an IPv6 extension header is DCCP, SCTP, TCP, UDP or UDP-Lite, the transport protocol mapped port number. This is the destination port number found in the original IPv4 packet that was translated into the IPv6 packet containing this option. Otherwise, this must be set to zero by sender, and ignored by receivers. Destination IPv4 address, as found in the origin IPv4 packet before translation. Source IPv4 address, as found in the origin IPv4 packet before translation. The Translated Flow Mapping option requires a 4n alignment (as defined per section 4.2).

TBD.

The Translated Flow Mapping option requires an IPv6 Option number. IPv6 Option Number :

HEX act chg rest --- --- --- ----- XX 00 0 XXXXX Translated Flow Mapping The first two bits indicate that the IPv6 node may skip over this option and continue processing the header if it doesn't recognize the option type, and the third bit indicates that the Option Data may not change en-route. This document should be listed as the reference document.

This section is non-normative. It defines a potential API to retrieve the flow mapping information as an extension to the Advanced IPv6 socket API . The flow mapping informations shall be passed to applications using a structure defined in <netinet/in.h>, and containing at least the following fields:

struct in6_ipv4flowmapping { struct uint16_t i4fm6_mapped_port; struct in_addr i4fm6_mapped_addr; struct in_addr i4fm6_remote_addr; }; For datagram (type SOCK_DGRAM) and raw (type SOCK_RAW) sockets, a socket option can configure receiving the flow information as ancilliary data on a per-packet basis, using recvmsg. This socket option shall be set to 0 (off) by default. Setting it to 1 (on) shall enabled flow mapping infos reception. Setting it to -1 (default) shall disable it. When enabled, an ancilliary data with level IPPROTO_IPV6, type IPV6_IPV4FLOWMAPPING shall be returned to the application, if a Flow Mapping option was found in the received packet.

int on = 1; setsockopt(fd, IPPROTO_IPV6, IPV6_RECVIPV4FLOWMAPPING, &yes, sizeof(yes)); For a connected socket, a read-only socket option may be used to fetch the flow mapping information if known (i.e. if at least one packet with a Flow Mapping Option was received). If unknown, the returned structure shall contain all zeroes.

struct in6_ipv4flowmapping val; getsockopt(fd, IPPROTO_IPV6, IPV6_IPV4FLOWMAPPING, &val, sizeof(val));