[Docs] [txt|pdf|xml|html] [Tracker] [Email] [Nits]

Versions: 00

Network Working Group                                          R. Bellis
Internet-Draft                                                Nominet UK
Obsoletes: 3514 (if approved)                                  G. Huston
Updates: 791 (if approved)                                         APNIC
Intended status: Standards Track                        October 23, 2011
Expires: April 25, 2012


                     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



Bellis & Huston          Expires April 25, 2012                 [Page 1]


Internet-Draft               NAT Signalling                 October 2011


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

   2.  Terminology used in this document . . . . . . . . . . . . . . . 3

   3.  Specification . . . . . . . . . . . . . . . . . . . . . . . . . 4
     3.1.  IPv4  . . . . . . . . . . . . . . . . . . . . . . . . . . . 4
       3.1.1.  Definition  . . . . . . . . . . . . . . . . . . . . . . 4
       3.1.2.  Syntax  . . . . . . . . . . . . . . . . . . . . . . . . 4
     3.2.  IPv6  . . . . . . . . . . . . . . . . . . . . . . . . . . . 4
       3.2.1.  Definition  . . . . . . . . . . . . . . . . . . . . . . 4
       3.2.2.  Syntax  . . . . . . . . . . . . . . . . . . . . . . . . 5
     3.3.  Protocol Translation  . . . . . . . . . . . . . . . . . . . 5

   4.  Application Processing  . . . . . . . . . . . . . . . . . . . . 5

   5.  Related Work  . . . . . . . . . . . . . . . . . . . . . . . . . 5

   6.  Security Considerations . . . . . . . . . . . . . . . . . . . . 6

   7.  IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 6

   8.  Acknowledgements  . . . . . . . . . . . . . . . . . . . . . . . 6

   9.  Normative References  . . . . . . . . . . . . . . . . . . . . . 6

   Appendix A.  Change Log . . . . . . . . . . . . . . . . . . . . . . 6

   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . . . 7















Bellis & Huston          Expires April 25, 2012                 [Page 2]


Internet-Draft               NAT Signalling                 October 2011


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




Bellis & Huston          Expires April 25, 2012                 [Page 3]


Internet-Draft               NAT Signalling                 October 2011


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

   The bit field is laid out as follows:


          0
         +-+
         |E|
         +-+


   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.





Bellis & Huston          Expires April 25, 2012                 [Page 4]


Internet-Draft               NAT Signalling                 October 2011


3.2.2.  Syntax

   The option is laid out as follows:


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


   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.



Bellis & Huston          Expires April 25, 2012                 [Page 5]


Internet-Draft               NAT Signalling                 October 2011


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.  Normative References

   [IGDP]     UPnp Forum, "InternetGatewayDevice:2 specification",
              12 2010, <http://upnp.org/specs/gw/
              UPnP-gw-InternetGatewayDevice-v2-Device.pdf>.

   [RFC0791]  Postel, J., "Internet Protocol", STD 5, RFC 791,
              September 1981.

   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
              Requirement Levels", BCP 14, RFC 2119, March 1997.

   [RFC2460]  Deering, S. and R. Hinden, "Internet Protocol, Version 6
              (IPv6) Specification", RFC 2460, December 1998.

   [RFC3022]  Srisuresh, P. and K. Egevang, "Traditional IP Network
              Address Translator (Traditional NAT)", RFC 3022,
              January 2001.

   [RFC3514]  Bellovin, S., "The Security Flag in the IPv4 Header",
              RFC 3514, April 1 2003.


Appendix A.  Change Log

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

   draft-bellis-behave-natpresent-00




Bellis & Huston          Expires April 25, 2012                 [Page 6]


Internet-Draft               NAT Signalling                 October 2011


      Initial draft


Authors' Addresses

   Ray Bellis
   Nominet UK
   Edmund Halley Road
   Oxford  OX4 4DQ
   United Kingdom

   Phone: +44 1865 332211
   Email: ray.bellis@nominet.org.uk
   URI:   http://www.nominet.org.uk/


   Geoff Huston
   Asia Pacific Network Information Centre

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






























Bellis & Huston          Expires April 25, 2012                 [Page 7]


Html markup produced by rfcmarkup 1.129d, available from https://tools.ietf.org/tools/rfcmarkup/