idnits 2.17.1 draft-ietf-nat-arch-implications-00.txt: ** The Abstract section seems to be numbered Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Cannot find the required boilerplate sections (Copyright, IPR, etc.) in this document. Expected boilerplate is as follows today (2024-04-18) according to https://trustee.ietf.org/license-info : IETF Trust Legal Provisions of 28-dec-2009, Section 6.a: This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. IETF Trust Legal Provisions of 28-dec-2009, Section 6.b(i), paragraph 2: Copyright (c) 2024 IETF Trust and the persons identified as the document authors. All rights reserved. IETF Trust Legal Provisions of 28-dec-2009, Section 6.b(i), paragraph 3: This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://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. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** Missing expiration date. The document expiration date should appear on the first and last page. ** The document seems to lack a 1id_guidelines paragraph about Internet-Drafts being working documents. ** The document seems to lack a 1id_guidelines paragraph about 6 months document validity -- however, there's a paragraph with a matching beginning. Boilerplate error? ** The document seems to lack a 1id_guidelines paragraph about the list of current Internet-Drafts. ** The document seems to lack a 1id_guidelines paragraph about the list of Shadow Directories. == No 'Intended status' indicated for this document; assuming Proposed Standard == The page length should not exceed 58 lines per page, but there was 6 longer pages, the longest (page 2) being 61 lines Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an Introduction section. ** 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.) ** The document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. ** There are 134 instances of too long lines in the document, the longest one being 7 characters in excess of 72. ** The abstract seems to contain references ([RFC1631]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. Miscellaneous warnings: ---------------------------------------------------------------------------- == Line 151 has weird spacing: '... stream the d...' -- 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.) -- Couldn't find a document date in the document -- date freshness check skipped. Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Missing Reference: 'RFC1631' is mentioned on line 141, but not defined ** Obsolete undefined reference: RFC 1631 (Obsoleted by RFC 3022) == Unused Reference: 'RFC 1631' is defined on line 251, but no explicit reference was found in the text == Unused Reference: 'RFC 2101' is defined on line 254, but no explicit reference was found in the text ** Obsolete normative reference: RFC 1631 (Obsoleted by RFC 3022) ** Downref: Normative reference to an Informational RFC: RFC 2101 Summary: 15 errors (**), 0 flaws (~~), 6 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group Yakov Rekhter 3 Internet Draft cisco Systems 4 Expiration Date: February 1999 6 Implications of NATs on the TCP/IP architecture 8 draft-ietf-nat-arch-implications-00.txt 10 1. Status of this Memo 12 This document is an Internet-Draft. Internet-Drafts are working 13 documents of the Internet Engineering Task Force (IETF), its areas, 14 and its working groups. Note that other groups may also distribute 15 working documents as Internet-Drafts. 17 Internet-Drafts are draft documents valid for a maximum of six months 18 and may be updated, replaced, or obsoleted by other documents at any 19 time. It is inappropriate to use Internet- Drafts as reference 20 material or to cite them other than as "work in progress." 22 To view the entire list of current Internet-Drafts, please check the 23 "1id-abstracts.txt" listing contained in the Internet-Drafts Shadow 24 Directories on ftp.is.co.za (Africa), ftp.nordu.net (Northern 25 Europe), ftp.nis.garr.it (Southern Europe), munnari.oz.au (Pacific 26 Rim), ftp.ietf.org (US East Coast), or ftp.isi.edu (US West Coast). 28 2. Abstract 30 In light of the growing interest in, and deployment of network 31 address translation (NAT - RFC 1631), this document will present some 32 highlights of the architectural implications. A reader is assumed to 33 be well familiar with the principles of NAT operations [RFC1631]. 35 3. Implications on routing and addressing 37 Use of NATs allows to build a TCP/IP network as a collection of 38 routing realms, rather than require the network to be a single 39 routing realm. Routing realms are interconnected via NATs, where a 40 NAT is assumed to be connected to two or more routing realms. 42 Regardless of whether a network is constructed as a single routing 43 realm, or as an interconnection of multiple routing realms, an IP 44 address carried in a packet acts as a "locator". The distinction 45 between the former (single routing realm) and the latter (multiple 46 routing realms) is that in the former case the same address acts as a 47 locator across the whole network (network-wide locator), while in the 48 latter case the same address acts as a locator only within a part of 49 the network (within a single routing realm). Moreover in the former 50 case to act as a locator, an address in the IP header has to be 51 modified at the boundaries between routing realms. This, in turn, 52 implies that addresses in the IP header may not be preserved end-to- 53 end (in fact, they are guaranteed not to be preserved end-to-end for 54 any communication than spans multiple routing realms). 56 With NATs temporal uniqueness of IP addresses is no longer assured. 57 It may be quite short, possibly comparable to a transport connection 58 time. In such cases an IP address is no longer a suitable long-term 59 end point identifier. This has some impact on end-to-end security 60 (see below). Note that DHCP, PPP, and renumbering are some of the 61 other factors that make IP addresses unsuitable as long-term end- 62 point identifiers. 64 Constructing a network out of multiple routing realms allows to build 65 a network whose size is no longer bounded by the scaling limitations 66 of the IP routing system. Using multiple routing realms, instead of 67 a single one allows to reduce the load on the network layer routing 68 system, as the routing system has to handle routing only within 69 individual routing realms. As a result, the amount of routing 70 information that the routing system has to handle is bounded by the 71 size of the individual routing realms that form a network, rather 72 than by the size of the whole network. 74 Use of multiple routing realms, instead of a single one, may permit 75 relaxation of some of the constraints on IP address assignment within 76 a network. Specifically, since the routing system operates within the 77 confines of a single routing realm, any constraints on address 78 assignment imposed by the routing system are confined to a single 79 routing realm as well. 81 For example, addresses are required to be unique only within a single 82 routing realm, but not across multiple routing realms. This 83 simplifies IP address administration and management, as each routing 84 realm could administer and manage its address space independent of 85 all other routing realms, thus reducing the amount of required 86 coordination among organizations involved in address administration 87 and management, and ultimately reducing the cost associated with 88 address administration and management. 90 Likewise, hierarchical address assignment required to support 91 hierarchical routing is required only within individual routing 92 realms (only within parts of the network), but not across multiple 93 routing realms (not across the whole network). This reduces the need 94 for renumbering when network topology changes (e.g., an enterprise 95 changes its Internet Service Provider), which in turn lowers the 96 overall cost of operations by reducing the cost of renumbering. 98 Complexity of interconnecting routing realms with NATs depends (among 99 other factors) on the network topology at the level of routing 100 realms. Current practice could be closely (although not precisely) 101 approximated by a two level hierarchy, with the Internet being at the 102 top level of the hierarchy. Further work is needed to understand how 103 routing realms could be interconnected (via NATs) in an arbitrary 104 (mesh) topology. 106 Since NATs maintain state associated with inter-realm connectivity, 107 failure of a NAT may cause disruption of inter-realm connections 108 handled by the NAT. Techniques such as "hot stand-by" NAT could be 109 used to avoid the disruption. Such techniques require syncronization 110 of state between the "primary" and the "hot stand-by". 112 4. Implications on DNS 114 A network formed by multiple routing realms relies on DNS for 115 providing connectivity among these realms. This places certain 116 requirements on DNS. 118 For a network formed by a set of interconnected routing realms, fully 119 qualified domain names are required to be unique across the whole set 120 (across the whole network), even if IP addresses are no longer unique 121 across the set. Note that this requirement has to be satisfied 122 regardless of whether the network is formed by a single or multiple 123 routing realms. 125 A routing realm may contain one or more zones. 127 In general one should try to avoid (or at least minimize) spreading a 128 single DNS zone across multiple routing realms. This is because 129 spreading a DNS zone across multiple routing realms increases the 130 amount of manual configuration on NATs interconnecting these realms. 132 Further work is required to identify implications on DNS in the 133 presence of DNS Security and DNS Dynamic Updates. 135 5. Implications on transport layer 137 Since communication across multiple routing realms requires addresses 138 in the IP header to be modified at the boundaries between the realms, 139 transport header checksum has to be adjusted at the boundaries 140 between the realms. Procedures for doing this are described in 141 [RFC1631]. 143 6. Implications on applications 145 If hosts in different routing realms communicate among themselves via 146 an application that carries IP addresses in the application data 147 stream (e.g., FTP), the NATs that interconnect the realms have to be 148 augmented with the Application Layer Gateway (ALG) functionality for 149 that application. This is because IP addresses are guaranteed to be 150 unambiguous only within a single routing realm. Thus when they are 151 carried in the application data stream the data stream has to be 152 modified as it crosses routing realm's boundaries by the NATs placed 153 at the boundaries. Modifying this application data stream requires to 154 understand the semantics of the stream, which in turn requires the 155 ALG functionality specific to the application. 157 Unconstrained proliferation of applications that carry IP addresses 158 in the application data stream clearly complicates support of such 159 applications across multiple routing realms. Whether this is a 160 problem of practical significance, or how wide is going to be the 161 proliferation of such applications is a matter of opinion. 163 Applications that do not carry IP addresses in the application data 164 stream place no additional requirements, other than what is required 165 by NAT (address translation and transport header checksum 166 adjustment). 168 The discussion on whether applications should carry IP addresses in 169 the application data stream is outside the scope of this document, 170 but may well be within the scope of the overall TCP/IP architecture. 172 7. Implications on security 174 As long as a security mechanism doesn't depend on addresses in the IP 175 header being preserved end-to-end, using such mechanism for 176 communications that span multiple routing realms places no additional 177 requirements on either the mechanism or NATs. For example, use of SSH 178 for communications that span multiple routing realms poses no 179 problem, as proven by operational experience. 181 On the other hand, the use of IPSec, or any other protocol which uses 182 IP addresses as part of a security association, for communications 183 that span multiple routing realms is problematic. Use of IPSec is 184 likely to require boundaries between different IP Security domains to 185 be aligned with routing realms boundaries. More work is needed to 186 identify specific scenarios where IPSec could work, as well as the 187 scenarios where IPSec is not going to work. 189 While NATs clearly limit the scope where IPSec could be applicable 190 (or vice versa, IPSec could limit the scope where NATs could be 191 applicable), one need to remember that IPSec is just one mechanism 192 for providing security, but not the only one possible. Moreover, 193 there are scenarios where IPSec could be used in conjunction with 194 NATs. 196 The discussion on whether IPSec should depend on preserving addresses 197 in the IP header end-to-end is outside the scope of this document, 198 but may as well be within the scope of the overall TCP/IP 199 architecture. 201 For applications that carry IP addresses in the application data 202 stream, a combined NAT/ALG needs to "see" the application data stream 203 in clear. If security is viewed as necessary for such applications, 204 then satisfying this requires to align security domains with routing 205 realms boundaries, at least for such applications. 207 8. Implications on performance 209 It is quite clear that performing IP forwarding on a packet requires 210 less processing than performing NAT. Whether this difference has any 211 practical impact is a matter of opinion. 213 The impact on performance is clearly going to be more significant for 214 applications that carry IP addresses in the application data stream, 215 and handling such applications require not just NAT, but ALG as well 216 (which has longer path length than NAT). 218 9. "Many-to-one", "one-to-many" 220 NATs allow to model a collection of hosts as a single "virtual" host. 221 Doing this requires no host modifications. One possible application 222 of this mechanism is to provide load sharing across multiple servers. 224 NATs allow to present a host with a single IP address as if the host 225 would have multiple IP addresses. Doing this requires no 226 modifications to host software. One possible application of this 227 mechanism is support connectivity between multi-homed sites and the 228 Internet. 230 10. Preserving addresses end-to-end 232 In general any application that assumes that addresses in the IP 233 header would be preserved end-to-end is going to be impacted by NATs, 234 as NATs clearly violate this assumption. The degree of the impact may 235 depend on a variety of factors, and is likely to be application 236 specific. 238 The discussion on whether the TCP/IP architecture should evolve to 239 explicitly recognize the possibility that addresses in the IP header 240 may not be preserved end-to-end is outside the scope of this 241 document, but may well be within the scope of the overall TCP/IP 242 architecture. 244 11. Security Considerations 246 The impact of NATs on security is discussed in section "Implications 247 on security" of this document. 249 12. References 251 [RFC 1631], Egevang, K., Francis, P., "The IP Network Address 252 Translator", RFC 1631, May 1994 254 [RFC 2101], Carpenter et. al., "IPv4 Address Behavior Today", RFC 255 2101, February 1997 257 13. Acknowledgments 259 TBD 261 14. Author's Addresses 263 Yakov Rekhter 264 cisco Systems 265 170 West Tasman Drive 266 San Jose, CA 95134 267 Email: yakov@cisco.com 268 Phone: 1-914-215-2128