]> Nominet UK

Edmund Halley Road Oxford OX4 4DQ United Kingdom +44 1865 332211 ray.bellis@nominet.org.uk http://www.nominet.org.uk/

Asia Pacific Network Information Centre

gih@apnic.net http://www.apnic.net/

Internet Area End-to-end applications have difficulty distinguishing between packets that have been passed through a Network Address Translator (NAT) and packets that have been passed along a clear end-to-end path. We propose mechanisms for IPv4 and IPv6 whereby NAT devices explicitly signal their operation as a means of allowing applications to distinguish the presence of otherwise undetected NATs in the end-to-end path.

End-to-end applications have difficulty distinguishing between packets that have been passed through a Network Address Translator (NAT) and packets that have been passed along a clear end-to-end path. The problem identified here is that detecting the presence of NATs in the path can be challenging for an application. The UPnP Forum has defined the Internet Gateway Device (IGD) V2.0 protocol as a means of detecting the presence of a local NAT, and as a means of directing the NAT to perform certain actions regarding the NAT binding behaviour between internal addresses and ports and external addresses and ports. However, this approach fails if the NAT is not local, or if there are one or more remote NATs in the end-to-end path in addition to a local NAT. For example, an application may believe that IGD has successfully detected the NAT, and the application can use the IGD protocol to learn the external IP address that is used by the NAT for this application's communications, to direct the NAT to perform certain port mappings and to assign a lease time to a NAT binding, but the presence of a Carrier Grade NAT (CGN) further along the network path is then undetectable by the application using the IGD protocol, and the application behaves unpredictably. We note the directive in concerning the setting of a bit flag in the IPv4 packet header by NATs, and we redefine here the use of this bit flag as a means of distinguishing the presence of an otherwise undetected NAT in the end-to-end path. We also define an IPv6 hop-by-hop option with similar semantics. To allow a distinction to be drawn between NATs that are detected by IGD-capable applications and all other otherwise IGD-undetected NATs in the path, we propose here (but do not specify) an extension to the IGD protocol to allow IGD to direct the NAT not to apply the mechanisms herein on a per-binding basis, in the same manner as IGD already allows for control of the binding time in the NAT.

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 .

For IPv4 packets all NATs MUST set the NAT Present bit ("E", below) in the header of all IPv4 packets that have had their address and/or port fields altered by the NAT.

The high-order bit of the IPv4 fragment offset field has been defined for use by NATs in . The bit field is laid out as follows:

In the context of detection of NATs, the currently-assigned values for this bit are defined as follows: If the bit is set to 0, the packet has not traversed a NAT, or the NAT has been directed not to set the bit in a manner supported by an IGD interaction. If the bit is set to 1, the packet has been altered by one or more NAT devices along the path.

For IPv6 the presence of a NAT is conveyed in a hop-by-hop NAT Present option containing an 8 bit counter. All IPv6 NATs MUST increment this counter value in the NAT Present option in all packets that have had their address and/or port fields altered by the NAT. If this option is not present in the packet, the NAT MUST add the option to the packet header with an initial value of 1.

The option is laid out as follows:

Note that the two highest order bits of the tag are both clear, indicating that the option should be skipped if it is not recognised, and that the third highest-order bit is set, indicating that the option's value may change en-route.

All protocol-translating NATs MUST apply the relevant NAT Present bit or option on outbound packets.

Applications that receive a packet with a non-zero NAT Present option MUST assume that the IP header's source and destination address, the transport level source and destination ports and even the IP version value may have been altered by a NAT in the end-to-end path. We anticipate (but do not define) that applications will access the NAT Present value using the UNIX "getsockopt()" system call or its equivalent in other operating systems. An application MAY use extensions to the IGD protocol to direct a NAT NOT to add the NAT Present option as part of the IGD-managed settings on individual NAT bindings. If the IPv4 bit or IPv6 option is already present in a packet and its value is non-zero, the IGD protocol extension MUST be ignored. Hence for IPv4 the bit must remain set, and for IPv6 for value must be incremented, as specified above.

RFC 3514 defines other forms of semantic intent that would set this bit field in the IPv4 header. We are comfortable that these additional semantics are entirely consistent with this IPv4 NAT Present bit.

TBD

This document requests registration of the value TBC1 in the IANA Hop-by-Hop Option Type registry, with required 'act' value of '00' and 'chg' value of '1'.

The author wishes to thank the following for their feedback and reviews during the development of this idea: Steven M. Bellovin, Adrian Kennard.

&rfc0791; &rfc2119; &rfc2460; &rfc3022; &rfc3514; UPnp Forum

NB: to be removed by the RFC Editor before publication. draft-bellis-behave-natpresent-00 Initial draft