Signalling the Presence of NAT
draft-bellis-behave-natpresent-00

Abstract

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.

Status of this Memo

This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79.

Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at http://datatracker.ietf.org/drafts/current/.

Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress."

This Internet-Draft will expire on April 25, 2012.

Copyright Notice

Copyright (c) 2011 IETF Trust and the persons identified as the document authors. All rights reserved.

This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.

Table of Contents

• 1. Introduction
• 2. Terminology used in this document
• 3. Specification
• 3.1. IPv4
• 3.1.1. Definition
• 3.1.2. Syntax
• 3.2. IPv6
• 3.2.1. Definition
• 3.2.2. Syntax
• 3.3. Protocol Translation
• 4. Application Processing
• 5. Related Work
• 6. Security Considerations
• 7. IANA Considerations
• 8. Acknowledgements
• 9. References
• Appendix A. Change Log
• Authors' Addresses

1. Introduction

End-to-end applications have difficulty distinguishing between packets that have been passed through a Network Address Translator (NAT) [RFC3022] 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 [IGDP] 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 [RFC3514] concerning the setting of a bit flag in the IPv4 [RFC0791] 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 [RFC2460] 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.

2. Terminology used in this document

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 [RFC2119].

3. Specification

3.1. IPv4

3.1.1. Definition

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.

3.1.2. Syntax

The high-order bit of the IPv4 [RFC0791] fragment offset field has been defined for use by NATs in [RFC3514].

                                
       0
      +-+
      |E|
      +-+
                
                            

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:

0x0

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.

0x1

If the bit is set to 1, the packet has been altered by one or more NAT devices along the path.

3.2. IPv6

3.2.1. Definition

For IPv6 [RFC2460] 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.

3.2.2. Syntax

                                
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |  Type = TBC1  |   LEN = 0x01  |    VALUE      |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
                
                            

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.

3.3. Protocol Translation

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

4. Application Processing

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.

5. Related Work

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.

6. Security Considerations

TBD

7. IANA Considerations

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'.

8. Acknowledgements

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

9. References

Appendix A. Change Log

NB: to be removed by the RFC Editor before publication.

draft-bellis-behave-natpresent-00

• Initial draft

Authors' Addresses