idnits 2.17.1 draft-chan-tsvwg-eipf-cgnat-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: ---------------------------------------------------------------------------- == The page length should not exceed 58 lines per page, but there was 6 longer pages, the longest (page 6) being 60 lines Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) ** There are 88 instances of too long lines in the document, the longest one being 14 characters in excess of 72. == There are 16 instances of lines with non-RFC6890-compliant IPv4 addresses in the document. If these are example addresses, they should be changed. == There are 7 instances of lines with private range IPv4 addresses in the document. If these are generic example addresses, they should be changed to use any of the ranges defined in RFC 6890 (or successor): 192.0.2.x, 198.51.100.x or 203.0.113.x. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == The "Author's Address" (or "Authors' Addresses") section title is misspelled. == The document doesn't use any RFC 2119 keywords, yet seems to have RFC 2119 boilerplate text. -- The document date (Feb 21, 2022) is 793 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) == Unused Reference: 'RFC5128' is defined on line 263, but no explicit reference was found in the text -- Obsolete informational reference (is this intentional?): RFC 5389 (Obsoleted by RFC 8489) Summary: 2 errors (**), 0 flaws (~~), 7 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group Louis Chan 3 INTERNET-DRAFT 4 Intended status: Standard Track Juniper Networks 5 Expires: Aug 21, 2022 Feb 21, 2022 7 Enhanced Port Forwarding functions with CGNAT 8 draft-chan-tsvwg-eipf-cgnat-00.txt 10 Abstract 12 There is a need for peer-to-peer (P2P) communication under the use of CGNAT in 13 service providers. With the combination of home gateway, this becomes NAT444. 15 In RFC5128, methods of using UDP hole punching solves the problem partially when 16 EIM (Endpoint-Independent Mapping) is supported in NAT device in the path, and 17 there exists a common rendezvous server. 19 The success rate of UDP hole punching is high, but not TCP hole punching in 20 practical world. Also, the P2P solution requires a common server in the public 21 internet to exchange the IP and port information. 23 In this draft, a method is described to achieve incoming TCP or UDP session without 24 a common rendezvous server in NAT444 situation. 26 Status of this Memo 28 This Internet-Draft is submitted in full conformance with the provisions of BCP 78 29 and BCP 79. 31 Internet-Drafts are working documents of the Internet Engineering Task Force 32 (IETF). Note that other groups may also distribute working documents as Internet- 33 Drafts. The list of current Internet-Drafts is at 34 http://datatracker.ietf.org/drafts/current/. 36 Internet-Drafts are draft documents valid for a maximum of six months and may be 37 updated, replaced, or obsoleted by other documents at any time. It is 38 inappropriate to use Internet-Drafts as reference material or to cite them other 39 than as "work in progress." 41 This Internet-Draft will expire on Aug 21, 2022. 43 Copyright Notice 45 Copyright (c) 2017 IETF Trust and the persons identified as the document authors. 46 All rights reserved. 48 This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating 49 to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of 50 publication of this document. Please review these documents carefully, as they 51 describe your rights and restrictions with respect to this document. Code 52 Components extracted from this document must include Simplified BSD License text as 53 described in Section 4.e of the Trust Legal Provisions and are provided without 54 warranty as described in the Simplified BSD License. 56 Table of Contents 58 1. Introduction ......................................................... 2 59 2. Conventions used in this document..................................... 3 60 3. Port acquiring procedure in Application............................... 3 61 4. Endpoint Independent port forwarding (EIPF) Enhancement .............. 4 62 4.1. When this feature enabled in CGNAT with EIM...................... 4 63 4.2. When this feature is enabled in CGNAT with both EIM and EIF ..... 4 64 5. Retrieval of IP and port information via HTTP......................... 5 65 5.1. IP and port - URI /ipport/ ...................................... 5 66 5.2. IP and port range - URI /ipportrange/............................ 5 67 6. Compatibility ........................................................ 6 68 7. Security Considerations .............................................. 6 69 8. References ........................................................... 6 70 8.1. Normative References ............................................ 6 71 8.2. Informative References .......................................... 6 72 9. Acknowledgments....................................................... 7 74 1. Introduction 76 The purpose of this document is to describe to a way to allow incoming TCP or UDP 77 sessions under NAT444 situation. 79 The success rate of TCP and UDP session would be guaranteed under this proposal. 81 There would be two sections in the draft. 83 - The first section describes a procedure for an application in end device to 84 detect and allocate TCP or UDP port for its use for incoming session. The 85 required tools are STUN [RFC5389] and UPNP [RFC6970]. 87 - The second section describes a method for residential gateway RG to discover the 88 usable port range under a CGNAT deployment with port-block-allocation. In turn, 89 the home gateway could allocate TCP or UDP to the end devices via UPNP, NAT-PMP 90 [RFC6886] or PCP [RFC6887]. 92 2. Conventions used in this document 94 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", 95 "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be 96 interpreted as described in RFC 2119 [RFC2119]. 98 In this document, these words will appear with that interpretation only when in ALL 99 CAPS. Lower case uses of these words are not to be interpreted as carrying 100 significance described in RFC 2119. 102 3. Port acquiring procedure in Application 104 PC1-----RG-------CGNAT------Internet------PC2 105 | 106 +-----STUN server 108 - Private network: PC1: 192.168.1.10, RG: 192.168.1.1 109 - WAN: RG: 10.1.1.20, CGNAT: 10.1.1.1 110 - CGNAT: public IP 100.1.1.1 111 - PC2: public IP 201.1.1.10 113 Here is an example of step to acquire a TCP or UDP port 115 - Application in PC1 sends a STUN request to STUN servers in public internet. The 116 STUN server would reply the XOR-mapped-address. E.g. 118 100.1.1.1:1024 ;public ip is 100.1.1.1 with port 1024 120 This detects both public IP address and the UDP port available. This assumes the 121 same TCP port is also available since most CGNAT implementations allocate the 122 same port number for both TCP and UDP with EIM enabled. 124 The application will then send UPNP request to residential gateway RG, 125 192.168.1.1, for port forward TCP port 1024 to the local device IP, 126 192.168.1.10. 128 - CGNAT, due to PBA allocation and a special setting enabled, TCP traffic sent to 129 100.1.1.1:1024 as destination would be forwarded to RG 10.1.1.20:1024 without 130 changing port value. Then, RG would pass the TCP traffic to PC1 with 131 192.168.10.1:1024 as destination due to the registration of UPNP. In this case, 132 PC2 could initiate a direct TCP session to PC1 via 100.1.1.1:1024. 134 - UDP would work in the same way. Any host in the internet could create TCP or UDP 135 session directly with the application in PC1 137 The above procedure assumes both RG and CGNAT have EIM capability enabled. 139 The application in PC1, optionally, could release the UPNP mapping after finishing 140 the session. 142 4. Endpoint Independent Port Forwarding (EIPF) Enhancement 144 4.1. When this feature enabled in CGNAT with EIM 146 - the associated TCP or UDP port is UNCHANGED for the inbound traffic if there is 147 no matching session in the NAT table. 148 - only the IP address is going through NAT process. That is changing the public IP 149 to a private IP 150 - It is working like port forward function in a NAT44 151 - In the example, any IP source address, 202.1.1.1 or 222.1.1.1, sending traffic 152 to 100.1.1.1:1024. CGNAT would translate the traffic as 10.1.1.20:1024 as 153 destination. 154 - UDP hole punching would be compatible if the UDP session is still in RG and 155 CGNAT session table. Port 1024 would follow the translation. 157 4.2. When this feature is enabled in CGNAT with both EIM and EIF 159 - EIF (Endpoint-Independent Filtering), described in RFC5128, will happen only if 160 the external host already has a session through EIM. 161 - The TCP or UDP port is kept UNCHANGED for any other external hosts sending 162 inbound traffic. 163 - For example, there is a session originated from PC1 to PC3, 201.1.1.20 165 PC1-----------RG----------CGNAT-----------Internet---------PC3 166 | 167 +---------------------PC4 169 Src: 192.168.1.10:3333 10.1.1.20:4444 100.1.1.1:1033 171 Dst: 201.1.1.20:5555 201.1.1.20:5555 201.1.1.20:5555 173 When PC3 sends traffic with different source port, 201.1.1.20:6666 and 174 destination 100.1.1.1:1033, CGNAT should honor the EIF behavior. It would be 175 translated back to 10.1.1.20:4444. 177 When other host without any session established through EIM, and it sends 178 traffic with destination port 1033, the port 1033 should not be changed at 179 CGNAT. 181 When PC4 send traffic to 100.1.1.1:1033, the port 1033 is kept UNCHANGED. PC4 182 has no previous established sessions with PC1. 184 This behavior is an optional implementation with EIF enabled. Another option is 185 to make EIPF and EIF exclusive. 187 5. Retrieval of IP and port information via HTTP 189 The internet service provider host a HTTP web server for the enquiry of IP and port 190 information. Two URIs are suggested 192 5.1. IP and port - URI /ipport/ 194 With the URI /ipport/, the HTTP response is clear text with IP:PORT, where IP is 195 the external public IP address and the PORT is external port as seen. 197 For example, the response is 199 100.1.1.1:1040 201 The HTTP response should be human readable with a web browser. 203 Although TCP port 1040 is seen here, it is assumed that UDP port 1040 is also 204 available from CGNAT for incoming mapping. 206 5.2. IP and port range - URI /ipportrange/ 208 With the URI /ipportrange/, the HTTP response is clear text with 210 IP:PORT_START:PORT_END 212 IP:PORT_START:PORT_END 214 IP:PORT_START 216 Where is ASCII character for line feed. 218 The response is a human readable format in a normal web browser. 220 For examples, here are valid responses 222 a) Single line 224 100.1.1.1:1024:1031 226 Port range 1024 to 1031 assigned for both TCP and UDP. 228 b) Two lines 230 100.1.1.1:1024:1031 232 100.1.1.1:1064:1071 234 Port ranges 1024 to 1031 and range 1064 and 1071 are assigned for both TCP and UDP. 236 It is possible to have multiple port block allocated to the same private IP address 237 from CGNAT perspective. 239 If the RG device or application could not support multiple entries of IP and port 240 range, it should take one of the lines, preferably the first line. 242 Human user or RG could use this information to plan for incoming services. For 243 example, when PC1 requests a TCP 8888 port forward from RG via UPNP [RFC6970], NAT- 244 PMP [RFC6886] or PCP [RFC6887], RG would counter offer another TCP port 1031. 246 6. Compatibility 248 TBD 250 7. Security Considerations 252 TBD 254 8. References 256 8.1. Normative References 258 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", 259 BCP 14, RFC 2119, March 1997. 261 8.2. Informative References 263 [RFC5128] Srisuresh, P., Ford, B., and D. Kegel, "State of Peer-to- 264 Peer (P2P) Communication across Network Address 265 Translators (NATs)", March 2008. 267 [RFC5389] Rosenberg, J., Mahy, R., Matthews, P., and D. Wing, 268 "Session Traversal Utilities for NAT (STUN)", October 2008. 270 [RFC6886] S. Cheshire and M. Krochmal. NAT Port Mapping Protocol (NAT-PMP), 271 April 2013. 273 [RFC6887] Wing, D., Cheshire, S., Boucadair, M., Penno, R., and P. 274 Selkirk, "Port Control Protocol (PCP)", April 2013. 276 [RFC6970] Boucadair, M., Penno, R., and D. Wing, "Universal Plug and 277 Play (UPnP) Internet Gateway Device - Port Control 278 Protocol Interworking Function (IGD-PCP IWF)", July 2013 280 9. Acknowledgments 282 The following people have contributed to this document: 284 Author Address 286 Louis Chan (editor) 287 Juniper Networks 288 2604, Cityplaza One, 1111 King's Road 289 Taikoo Shing 290 Hong Kong 292 Phone: +852-25876659 293 Email: louisc@juniper.net