Internet DRAFT - draft-bellis-behave-natpresent
draft-bellis-behave-natpresent
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]
