idnits 2.17.1 draft-bellis-behave-natpresent-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- -- The draft header indicates that this document obsoletes RFC3514, but the abstract doesn't seem to mention this, which it should. -- The draft header indicates that this document updates RFC791, but the abstract doesn't seem to mention this, which it should. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year (Using the creation date from RFC791, updated by this document, for RFC5378 checks: 1981-09-01) -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (October 23, 2011) is 4569 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) -- Possible downref: Non-RFC (?) normative reference: ref. 'IGDP' ** Obsolete normative reference: RFC 2460 (Obsoleted by RFC 8200) ** Downref: Normative reference to an Informational RFC: RFC 3022 ** Downref: Normative reference to an Informational RFC: RFC 3514 Summary: 3 errors (**), 0 flaws (~~), 1 warning (==), 5 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group R. Bellis 3 Internet-Draft Nominet UK 4 Obsoletes: 3514 (if approved) G. Huston 5 Updates: 791 (if approved) APNIC 6 Intended status: Standards Track October 23, 2011 7 Expires: April 25, 2012 9 Signalling the Presence of NAT 10 draft-bellis-behave-natpresent-00 12 Abstract 14 End-to-end applications have difficulty distinguishing between 15 packets that have been passed through a Network Address Translator 16 (NAT) and packets that have been passed along a clear end-to-end 17 path. We propose mechanisms for IPv4 and IPv6 whereby NAT devices 18 explicitly signal their operation as a means of allowing applications 19 to distinguish the presence of otherwise undetected NATs in the end- 20 to-end path. 22 Status of this Memo 24 This Internet-Draft is submitted in full conformance with the 25 provisions of BCP 78 and BCP 79. 27 Internet-Drafts are working documents of the Internet Engineering 28 Task Force (IETF). Note that other groups may also distribute 29 working documents as Internet-Drafts. The list of current Internet- 30 Drafts is at http://datatracker.ietf.org/drafts/current/. 32 Internet-Drafts are draft documents valid for a maximum of six months 33 and may be updated, replaced, or obsoleted by other documents at any 34 time. It is inappropriate to use Internet-Drafts as reference 35 material or to cite them other than as "work in progress." 37 This Internet-Draft will expire on April 25, 2012. 39 Copyright Notice 41 Copyright (c) 2011 IETF Trust and the persons identified as the 42 document authors. All rights reserved. 44 This document is subject to BCP 78 and the IETF Trust's Legal 45 Provisions Relating to IETF Documents 46 (http://trustee.ietf.org/license-info) in effect on the date of 47 publication of this document. Please review these documents 48 carefully, as they describe your rights and restrictions with respect 49 to this document. Code Components extracted from this document must 50 include Simplified BSD License text as described in Section 4.e of 51 the Trust Legal Provisions and are provided without warranty as 52 described in the Simplified BSD License. 54 Table of Contents 56 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 58 2. Terminology used in this document . . . . . . . . . . . . . . . 3 60 3. Specification . . . . . . . . . . . . . . . . . . . . . . . . . 4 61 3.1. IPv4 . . . . . . . . . . . . . . . . . . . . . . . . . . . 4 62 3.1.1. Definition . . . . . . . . . . . . . . . . . . . . . . 4 63 3.1.2. Syntax . . . . . . . . . . . . . . . . . . . . . . . . 4 64 3.2. IPv6 . . . . . . . . . . . . . . . . . . . . . . . . . . . 4 65 3.2.1. Definition . . . . . . . . . . . . . . . . . . . . . . 4 66 3.2.2. Syntax . . . . . . . . . . . . . . . . . . . . . . . . 5 67 3.3. Protocol Translation . . . . . . . . . . . . . . . . . . . 5 69 4. Application Processing . . . . . . . . . . . . . . . . . . . . 5 71 5. Related Work . . . . . . . . . . . . . . . . . . . . . . . . . 5 73 6. Security Considerations . . . . . . . . . . . . . . . . . . . . 6 75 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 6 77 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 6 79 9. Normative References . . . . . . . . . . . . . . . . . . . . . 6 81 Appendix A. Change Log . . . . . . . . . . . . . . . . . . . . . . 6 83 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 7 85 1. Introduction 87 End-to-end applications have difficulty distinguishing between 88 packets that have been passed through a Network Address Translator 89 (NAT) [RFC3022] and packets that have been passed along a clear end- 90 to-end path. 92 The problem identified here is that detecting the presence of NATs in 93 the path can be challenging for an application. The UPnP Forum has 94 defined the Internet Gateway Device (IGD) V2.0 protocol [IGDP] as a 95 means of detecting the presence of a local NAT, and as a means of 96 directing the NAT to perform certain actions regarding the NAT 97 binding behaviour between internal addresses and ports and external 98 addresses and ports. However, this approach fails if the NAT is not 99 local, or if there are one or more remote NATs in the end-to-end path 100 in addition to a local NAT. 102 For example, an application may believe that IGD has successfully 103 detected the NAT, and the application can use the IGD protocol to 104 learn the external IP address that is used by the NAT for this 105 application's communications, to direct the NAT to perform certain 106 port mappings and to assign a lease time to a NAT binding, but the 107 presence of a Carrier Grade NAT (CGN) further along the network path 108 is then undetectable by the application using the IGD protocol, and 109 the application behaves unpredictably. 111 We note the directive in [RFC3514] concerning the setting of a bit 112 flag in the IPv4 [RFC0791] packet header by NATs, and we redefine 113 here the use of this bit flag as a means of distinguishing the 114 presence of an otherwise undetected NAT in the end-to-end path. 116 We also define an IPv6 [RFC2460] hop-by-hop option with similar 117 semantics. 119 To allow a distinction to be drawn between NATs that are detected by 120 IGD-capable applications and all other otherwise IGD-undetected NATs 121 in the path, we propose here (but do not specify) an extension to the 122 IGD protocol to allow IGD to direct the NAT not to apply the 123 mechanisms herein on a per-binding basis, in the same manner as IGD 124 already allows for control of the binding time in the NAT. 126 2. Terminology used in this document 128 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 129 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 130 document are to be interpreted as described in [RFC2119]. 132 3. Specification 134 3.1. IPv4 136 3.1.1. Definition 138 For IPv4 packets all NATs MUST set the NAT Present bit ("E", below) 139 in the header of all IPv4 packets that have had their address and/or 140 port fields altered by the NAT. 142 3.1.2. Syntax 144 The high-order bit of the IPv4 [RFC0791] fragment offset field has 145 been defined for use by NATs in [RFC3514]. 147 The bit field is laid out as follows: 149 0 150 +-+ 151 |E| 152 +-+ 154 In the context of detection of NATs, the currently-assigned values 155 for this bit are defined as follows: 157 0x0 If the bit is set to 0, the packet has not traversed a NAT, or 158 the NAT has been directed not to set the bit in a manner 159 supported by an IGD interaction. 161 0x1 If the bit is set to 1, the packet has been altered by one or 162 more NAT devices along the path. 164 3.2. IPv6 166 3.2.1. Definition 168 For IPv6 [RFC2460] the presence of a NAT is conveyed in a hop-by-hop 169 NAT Present option containing an 8 bit counter. 171 All IPv6 NATs MUST increment this counter value in the NAT Present 172 option in all packets that have had their address and/or port fields 173 altered by the NAT. If this option is not present in the packet, the 174 NAT MUST add the option to the packet header with an initial value of 175 1. 177 3.2.2. Syntax 179 The option is laid out as follows: 181 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 182 | Type = TBC1 | LEN = 0x01 | VALUE | 183 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 185 Note that the two highest order bits of the tag are both clear, 186 indicating that the option should be skipped if it is not recognised, 187 and that the third highest-order bit is set, indicating that the 188 option's value may change en-route. 190 3.3. Protocol Translation 192 All protocol-translating NATs MUST apply the relevant NAT Present bit 193 or option on outbound packets. 195 4. Application Processing 197 Applications that receive a packet with a non-zero NAT Present option 198 MUST assume that the IP header's source and destination address, the 199 transport level source and destination ports and even the IP version 200 value may have been altered by a NAT in the end-to-end path. 202 We anticipate (but do not define) that applications will access the 203 NAT Present value using the UNIX "getsockopt()" system call or its 204 equivalent in other operating systems. 206 An application MAY use extensions to the IGD protocol to direct a NAT 207 NOT to add the NAT Present option as part of the IGD-managed settings 208 on individual NAT bindings. 210 If the IPv4 bit or IPv6 option is already present in a packet and its 211 value is non-zero, the IGD protocol extension MUST be ignored. Hence 212 for IPv4 the bit must remain set, and for IPv6 for value must be 213 incremented, as specified above. 215 5. Related Work 217 RFC 3514 defines other forms of semantic intent that would set this 218 bit field in the IPv4 header. We are comfortable that these 219 additional semantics are entirely consistent with this IPv4 NAT 220 Present bit. 222 6. Security Considerations 224 TBD 226 7. IANA Considerations 228 This document requests registration of the value TBC1 in the IANA 229 Hop-by-Hop Option Type registry, with required 'act' value of '00' 230 and 'chg' value of '1'. 232 8. Acknowledgements 234 The author wishes to thank the following for their feedback and 235 reviews during the development of this idea: Steven M. Bellovin, 236 Adrian Kennard. 238 9. Normative References 240 [IGDP] UPnp Forum, "InternetGatewayDevice:2 specification", 241 12 2010, . 244 [RFC0791] Postel, J., "Internet Protocol", STD 5, RFC 791, 245 September 1981. 247 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 248 Requirement Levels", BCP 14, RFC 2119, March 1997. 250 [RFC2460] Deering, S. and R. Hinden, "Internet Protocol, Version 6 251 (IPv6) Specification", RFC 2460, December 1998. 253 [RFC3022] Srisuresh, P. and K. Egevang, "Traditional IP Network 254 Address Translator (Traditional NAT)", RFC 3022, 255 January 2001. 257 [RFC3514] Bellovin, S., "The Security Flag in the IPv4 Header", 258 RFC 3514, April 1 2003. 260 Appendix A. Change Log 262 NB: to be removed by the RFC Editor before publication. 264 draft-bellis-behave-natpresent-00 265 Initial draft 267 Authors' Addresses 269 Ray Bellis 270 Nominet UK 271 Edmund Halley Road 272 Oxford OX4 4DQ 273 United Kingdom 275 Phone: +44 1865 332211 276 Email: ray.bellis@nominet.org.uk 277 URI: http://www.nominet.org.uk/ 279 Geoff Huston 280 Asia Pacific Network Information Centre 282 Email: gih@apnic.net 283 URI: http://www.apnic.net/