idnits 2.17.1 draft-iab-ipv6-nat-03.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** You're using the IETF Trust Provisions' Section 6.b License Notice from 12 Sep 2009 rather than the newer Notice from 28 Dec 2009. (See https://trustee.ietf.org/license-info/) 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 : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (March 6, 2010) is 5158 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Unused Reference: 'RFC3041' is defined on line 645, but no explicit reference was found in the text -- Obsolete informational reference (is this intentional?): RFC 3041 (Obsoleted by RFC 4941) -- Obsolete informational reference (is this intentional?): RFC 4960 (Obsoleted by RFC 9260) -- Obsolete informational reference (is this intentional?): RFC 5389 (Obsoleted by RFC 8489) Summary: 1 error (**), 0 flaws (~~), 2 warnings (==), 4 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group D. Thaler 3 Internet-Draft Microsoft 4 Intended status: Informational L. Zhang 5 Expires: September 7, 2010 UCLA 6 G. Lebovitz 7 Juniper 8 March 6, 2010 10 IAB Thoughts on IPv6 Network Address Translation 11 draft-iab-ipv6-nat-03.txt 13 Abstract 15 There has been much recent discussion on the topic of whether the 16 IETF should develop standards for IPv6 Network Address Translators 17 (NATs). This document articulates the architectural issues raised by 18 IPv6 NATs, the pros and cons of having IPv6 NATs, and provides the 19 IAB's thoughts on the current open issues and the solution space. 21 Status of this Memo 23 This Internet-Draft is submitted to IETF in full conformance with the 24 provisions of BCP 78 and BCP 79. 26 Internet-Drafts are working documents of the Internet Engineering 27 Task Force (IETF), its areas, and its working groups. Note that 28 other groups may also distribute working documents as Internet- 29 Drafts. 31 Internet-Drafts are draft documents valid for a maximum of six months 32 and may be updated, replaced, or obsoleted by other documents at any 33 time. It is inappropriate to use Internet-Drafts as reference 34 material or to cite them other than as "work in progress." 36 The list of current Internet-Drafts can be accessed at 37 http://www.ietf.org/ietf/1id-abstracts.txt. 39 The list of Internet-Draft Shadow Directories can be accessed at 40 http://www.ietf.org/shadow.html. 42 This Internet-Draft will expire on September 7, 2010. 44 Copyright Notice 46 Copyright (c) 2010 IETF Trust and the persons identified as the 47 document authors. All rights reserved. 49 This document is subject to BCP 78 and the IETF Trust's Legal 50 Provisions Relating to IETF Documents 51 (http://trustee.ietf.org/license-info) in effect on the date of 52 publication of this document. Please review these documents 53 carefully, as they describe your rights and restrictions with respect 54 to this document. Code Components extracted from this document must 55 include Simplified BSD License text as described in Section 4.e of 56 the Trust Legal Provisions and are provided without warranty as 57 described in the BSD License. 59 Table of Contents 61 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 62 2. What is the Problem? . . . . . . . . . . . . . . . . . . . . . 3 63 2.1. Avoiding Renumbering . . . . . . . . . . . . . . . . . . . 4 64 2.2. Site Multihoming . . . . . . . . . . . . . . . . . . . . . 4 65 2.3. Homogenous Edge Network Configurations . . . . . . . . . . 5 66 2.4. Network Obfuscation . . . . . . . . . . . . . . . . . . . 6 67 2.4.1. Hiding Hosts . . . . . . . . . . . . . . . . . . . . . 6 68 2.4.2. Topology Hiding . . . . . . . . . . . . . . . . . . . 8 69 2.4.3. Summary Regarding NAT as a Tool for Network 70 Obfuscation . . . . . . . . . . . . . . . . . . . . . 9 71 2.5. Simple Security . . . . . . . . . . . . . . . . . . . . . 9 72 2.6. Discussion . . . . . . . . . . . . . . . . . . . . . . . . 10 73 3. Architectural Considerations of IPv6 NAT . . . . . . . . . . . 10 74 4. Solution Space . . . . . . . . . . . . . . . . . . . . . . . . 11 75 4.1. Discussion . . . . . . . . . . . . . . . . . . . . . . . . 13 76 5. Security Considerations . . . . . . . . . . . . . . . . . . . 13 77 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13 78 7. IAB Members at the time of this writing . . . . . . . . . . . 14 79 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 14 80 8.1. Normative References . . . . . . . . . . . . . . . . . . . 14 81 8.2. Informative References . . . . . . . . . . . . . . . . . . 14 82 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 15 84 1. Introduction 86 In the past, the IAB has published a number of documents relating to 87 Internet transparency and the end-to-end principle, and other IETF 88 documents have also touched on these issues as well. These documents 89 articulate the general principles on which the Internet architecture 90 is based, as well as the core values that the Internet community 91 seeks to protect going forward. Most recently, RFC 4924 [RFC4924] 92 reaffirms these principles and provides a review of the various 93 documents in this area. 95 Facing imminent IPv4 address space exhaustion, recently there have 96 been increased efforts in IPv6 deployment. However, since late 2008 97 there have also been increased discussions about whether the IETF 98 should standardize network address translation within IPv6. People 99 who are against standardizing IPv6 NAT argue that there is no 100 fundamental need for IPv6 NAT, and that as IPv6 continues to roll 101 out, the Internet should converge towards reinstallation of the end- 102 to-end reachability which has been a key factor in the Internet's 103 success. On the other hand, people who are for IPv6 NAT believe that 104 NAT vendors would provide IPv6 NAT implementations anyway as NAT can 105 be a solution to a number of problems, and that the IETF should avoid 106 repeating the same mistake as with IPv4 NAT, where the lack of 107 protocol standards led to different IPv4 NAT implementations, making 108 NAT traversal difficult. 110 An earlier effort, [RFC4864], provides a discussion of the real or 111 perceived benefits of NAT and suggests alternatives for most of them, 112 with the intent of showing that NAT is not required to get the 113 desired benefits. However, it also identifies several gaps remaining 114 to be filled. 116 This document provides the IAB's current thoughts on this debate. We 117 believe that the issue at hand must be viewed from an overall 118 architectural standpoint in order to fully assess the pros and cons 119 of IPv6 NAT on the global Internet and its future development. 121 2. What is the Problem? 123 The discussions on the desire for IPv6 NAT can be summarized as 124 follows. Network address translation is viewed as a solution to 125 achieve a number of desired properties for individual networks: 126 avoiding renumbering, facilitating multihoming, internal topology 127 hiding, preventing host counting, and simple security. We discuss 128 below each of these perceived benefits from NAT. 130 2.1. Avoiding Renumbering 132 As discussed in [RFC4864] Section 2.5, the ability to change service 133 providers with minimal operational difficulty is an important 134 requirement in many networks. However, renumbering is still quite 135 painful today, as discussed in [I-D.carpenter-renum-needs-work]. 136 Currently it requires reconfiguring devices that deal with IP 137 addresses or prefixes, including DNS servers, DHCP servers, 138 firewalls, IPsec policies, and potentially many other systems such as 139 intrusion detection systems, inventory management systems, patch 140 management systems, etc. 142 In practice today, renumbering does not seem to be a significant 143 problem in consumer networks, such as home networks, where addresses 144 or prefixes are typically obtained through DHCP, and are rarely 145 manually configured in any component. However in managed networks, 146 renumbering can be a serious problem. 148 We also note that many, if not most, large enterprise networks avoid 149 the renumbering problem by using provider-independent (PI) IP address 150 blocks. The use of PI addresses is inherent in today's Internet 151 operations. However in smaller managed networks that cannot get 152 provider-independent IP address blocks, renumbering remains a serious 153 issue. Regional Internet Registries (RIRs) constantly receive 154 requests for PI address blocks; one main reason that they hesitate in 155 assigning PI address blocks to all users is the concern about the PI 156 addresses' impact on the routing system scalability. 158 2.2. Site Multihoming 160 Another important requirement in many networks is site multihoming. 161 A multihomed site essentially requires that its IP prefixes be 162 present in the global routing table to achieve the desired 163 reliability in its Internet connectivity as well as load balancing. 164 In today's practice, multihomed sites with PI addresses announce 165 their PI prefixes to the global routing system; multihomed sites with 166 provider-allocated (PA) addresses also announce the PA prefix they 167 obtained from one service provider to the global routing system 168 through another service provider, effectively disabling provider- 169 based prefix aggregation. This practice makes the global routing 170 table scale linearly with the number of multihomed user networks. 172 This issue was identified in [RFC4864] Section 6.4. Unfortunately, 173 no solution except NAT has been deployed today that can insulate the 174 global routing system from the growing number of multihomed sites, 175 where a multihomed site simply assigns multiple IPv4 addresses, one 176 from each of its service providers, to its exit router which is an 177 IPv4 NAT box. Using address translation to facilitate multihoming 178 support has one unique advantage: there is no impact on the routing 179 system scalability, as the NAT box simply takes one address from each 180 service provider, and the multihomed site does not inject its own 181 routes into the system. Intuitively it also seems straightforward to 182 roll the same solution into multihoming support in the IPv6 183 deployment. However, one should keep in mind that this approach 184 brings all the drawbacks of putting a site behind a NAT box, 185 including the loss of reachability to the servers behind the NAT box. 187 It is also important to point out that a multihomed site announcing 188 its own prefix(es) achieves two important benefits that NAT-based 189 multihoming support does not provide. First, end-to-end 190 communications can be preserved in face of connectivity failures of 191 individual service providers, as long as the site remains connected 192 through at least one operational service provider. Second, 193 announcing one's prefixes also gives a multihomed site the ability to 194 perform traffic engineering and load balancing. 196 2.3. Homogenous Edge Network Configurations 198 Service providers supporting residential customers need to minimize 199 support costs (e.g., help desk calls). Often a key factor in 200 minimizing support costs is ensuring customers have homogenous 201 configurations, including the addressing architecture. Today, when 202 IPv4 NATs are provided by a service provider, all customers get the 203 same address space on their home networks, and hence the home gateway 204 always has the same address. From a customer support perspective, 205 this perhaps represents the most important property of NAT usage 206 today. 208 In IPv6, link-local addresses can be used to ensure that all home 209 gateways have the same address, and to provide homogenous addresses 210 to any other devices supported by the service provider. Unlike IPv4, 211 having a globally unique address does not prevent the use of a 212 homogenous address within the subnet. It is only in the case of 213 multi-subnet customers that IPv6 NAT would provide some homogeneity 214 that wouldn't be provided by link-local addresses. For multi-subnet 215 customers (e.g., a customer using a wireless access point behind the 216 service provider router/modem), service providers today might only 217 discuss problems (for IPv4 or IPv6) from computers connected directly 218 to the service provider router. 220 It is currently unknown whether IPv6 link-local addresses provide 221 sufficient homogeneity to minimize help desk calls. If they do not, 222 providers might still desire IPv6 NATs in the residential gateways 223 they provide. 225 2.4. Network Obfuscation 227 Most network administrators want to hide the details of the computing 228 resources, information infrastructure, and communications networks 229 within their borders. This desire is rooted in the basic security 230 principle that an organization's assets are for its sole use and all 231 information about those assets, their operation, and the methods and 232 tactics of their use are proprietary secrets. Some organizations use 233 their information and communication technologies as a competitive 234 advantage in their industries. It is a generally held belief that 235 measures must be taken to protect those secrets. The first layer of 236 protection of those secrets is preventing access to the secrets or 237 knowledge about the secrets whenever possible. It is understandable 238 why network administrators would want to keep the details about the 239 hosts on their network, as well as the network infrastructure itself, 240 private. They believe that NAT helps achieve this goal. 242 2.4.1. Hiding Hosts 244 As a specific measure of network obfuscation, network administrators 245 wish to keep secret any and all information about the computer 246 systems residing within their network boundaries. Such computer 247 systems include workstations, laptops, servers, function-specific 248 end-points (e.g., printers, scanners, IP telephones, point of sale 249 machines, building door access-control devices), and such. They want 250 to prevent an external entity from counting the number of hosts on 251 the network. They also want to prevent host fingerprinting, i.e., 252 gaining information about the constitution, contents, or function of 253 a host. For example, they want to hide the role of a host, as 254 whether it is a user workstation, a finance server, a source code 255 build server, or a printer. A second element of host fingerprinting 256 prevention is to hide details that could aid an attacker in 257 compromising the host. Such details might include the type of 258 operating system, its version number, any patches it may or many not 259 have, the make and model of the device hardware, any application 260 software packages loaded, those version numbers and patches, and so 261 on. With such information about hosts, an attacker can launch a more 262 focused, targeted attack. Operators want to stop both host counting 263 and host fingerprinting. 265 Where host counting is a concern, it is worth pointing out some of 266 the challenges in preventing it. [Bellovin] showed how one can 267 successfully count the number of hosts behind a certain type of 268 simple NAT box. More complex NAT deployments, e.g., ones employing 269 Network Address Port Translators (NAPTs) with a pool of public 270 addresses that are randomly bound to internal hosts dynamically upon 271 receipt of any new connection, and do so without persistency across 272 connections from the same host are more successful in preventing host 273 counting. However, the more complex the NAT deployment, the less 274 likely that complex connection types like the Session Initiation 275 Protocol (SIP) [RFC3261] and the Stream Control Transmission Protocol 276 (SCTP) [RFC4960] will be able to successfully traverse the NAT. This 277 observation follows the age-old axiom for networked computer systems: 278 for every unit of security you gain, you give up a unit of 279 convenience, and for every unit of convenience you hope to gain, you 280 must give up a unit of security. 282 If fields such as fragment ID, TCP initial sequence number, or 283 ephemeral port number are chosen in a predictable fashion (e.g., 284 sequentially), then an attacker may correlate packets or connections 285 coming from the same host. 287 To prevent counting hosts by counting addresses, one might be tempted 288 to use a separate IP address for each transport-layer connection. 289 Such an approach introduces other architectural problems, however. 290 Within the host's subnet, various devices including switches, 291 routers, and even the host's own hardware interface often have a 292 limited amount of state available before causing communication using 293 a large number of addresses to suffer significant performance 294 problems. In addition, if an attacker can somehow determine an 295 average number of connections per host, the attacker can still 296 estimate the number of hosts based on the number of connections 297 observed. Hence such an approach can adversely affect legitimate 298 communication at all times, simply to raise the bar for an attacker. 300 Where host fingerprinting is concerned, even a complex NAT cannot 301 prevent fingerprinting completely. The way that different hosts 302 respond to different requests and sequences of events will indicate 303 consistently the type of a host that it is, its OS, version number, 304 and sometimes applications installed, etc. Products exist that do 305 this for network administrators as a service, as part of a 306 vulnerability assessment. 308 These scanning tools initiate connections of various types across a 309 range of possible IP addresses reachable through that network. They 310 observe what returns, and then send follow-up messages accordingly 311 until they "fingerprint" the host thoroughly. When run as part of a 312 network assessment process, these tools are normally run from the 313 inside of the network, behind the NAT. If such a tool is set outside 314 a network boundary (as part of an external vulnerability assessment 315 or penetration test) along the path of packets, and is passively 316 observing and recording connection exchanges, over time it can 317 fingerprint hosts only if it has a means of determining which 318 externally viewed connections are originating from the same internal 319 host. If the NATing is simple and static, and each host's internal 320 address is always mapped to the same external address and vice versa, 321 the tool has 100% success fingerprinting the host. With the internal 322 hosts mapped to their external IP addresses and fingerprinted, the 323 attacker can launch targeted attacks into those hosts, or reliably 324 attempt to hijack those hosts' connections. If the NAT uses a single 325 external IP, or a pool of dynamically assigned IP address for each 326 host, but does so in a deterministic and predictable way, then the 327 operation of fingerprinting is more complex, but quite achievable. 329 If the NAT uses dynamically assigned addresses, with short-term 330 persistency, but no externally learnable determinism, then the 331 problem gets harder for the attacker. The observer may be able to 332 fingerprint a host during the lifetime of a particular IP address 333 mapping, and across connections, but once that IP mapping is 334 terminated, the observer doesn't immediately know which new mapping 335 will be that same host. After much observation and correlation, the 336 attacker could sometimes determine if an observed new connection in 337 flight is from a familiar host. With that information, and a good 338 set of man-in-the-middle attack tools, the attacker could attempt to 339 compromise the host by hijacking a new connection of adequately long 340 duration. If temporal persistency is not deployed on the NAT, then 341 this tactic becomes almost impossible. As the difficulty and cost of 342 the attack increases, the number of attackers attempting to employ it 343 decreases. And certainly the attacker would not be able to initiate 344 a connection toward a host for which the attacker does not know the 345 current IP address binding. So the attacker is limited to hijacking 346 observed connections thought to be from a familiar host, or to 347 blindly initiating attacks on connections in flight. This is why 348 network administrators appreciate complex NATs' ability to deter host 349 counting and fingerprinting, but such deterrence comes at a cost of 350 host reachability. 352 2.4.2. Topology Hiding 354 It is perceived that a network operator may want to hide the details 355 of the network topology, the size of the network, the identities of 356 the internal routers, and the interconnection among the routers. 357 This desire has been discussed in [RFC4864] Sections 4.4 and 6.2. 359 However the success of topology hiding is dependent upon the 360 complexity, dynamism, and pervasiveness of bindings the NAT employs 361 (all of which were described above). The more complex, the more the 362 topology will be hidden, but the less likely that complex connection 363 types will successfully traverse the NAT barrier. Thus the trade-off 364 is reachability across applications. 366 Even if one can hide the actual addresses of internal hosts through 367 address translation, this does not necessarily prove sufficient to 368 hide internal topology. It may be possible to infer some aspects of 369 topological information from passively observing packets. For 370 example, based on packet timing, delay measurements, the Hop Limit 371 field, or other fields in the packet header, one could infer the 372 relative distance between multiple hosts. Once an observed session 373 is believed to match a previously fingerprinted host, that host's 374 distance from the NAT device may be learned, but not its exact 375 location or particular internal subnet. 377 Host fingerprinting is required in order to do a thorough distance 378 mapping. An attacker might then use message contents to lump certain 379 types of devices into logical clusters, and take educated guesses at 380 attacks. This is not, however, a thorough mapping. Some NATs change 381 the TTL hop counts, much like an application-layer proxy would, while 382 others don't; this is an administrative setting on more advanced 383 NATs. The simpler and more static the NAT, the more possible this 384 is. The more complex and dynamic and non-persistent the NAT 385 bindings, the more difficult. 387 2.4.3. Summary Regarding NAT as a Tool for Network Obfuscation 389 The degree of obfuscation a NAT can achieve will be a function of its 390 complexity as measured by: 391 o The use of one-to-many NAPT mappings; 392 o The randomness over time of the mappings from internal to external 393 IP addresses, i.e., non-deterministic mappings from an outsider's 394 perspective; 395 o The lack of persistence of mappings, i.e., the shortness of 396 mapping lifetimes and not using the same mapping repeatedly; 397 o The use of re-writing in IP header fields such as TTL. 399 However, deployers be warned: as obfuscation increases, host 400 reachability decreases. Mechanisms such as STUN [RFC5389] and Teredo 401 [RFC4380] fail with the more complex NAT mechanisms. 403 2.5. Simple Security 405 It is commonly perceived that a NAT box provides one level of 406 protection because external hosts cannot directly initiate 407 communication with hosts behind a NAT. However one should not 408 confuse NAT boxes with firewalls. As discussed in [RFC4864] Section 409 2.2, the act of translation does not provide security in itself. The 410 stateful filtering function can provide the same level of protection 411 without requiring a translation function. For further discussion, 412 see [RFC4864] Section 4.2. 414 2.6. Discussion 416 At present, the primary benefits one may receive from deploying NAT 417 appear to be avoiding renumbering, facilitating multihoming without 418 impacting routing scalability, and making edge consumer network 419 configurations homogenous. 421 Network obfuscation (host hiding, both counting and fingerprinting 422 prevention, and topology hiding) may well be achieved with more 423 complex NATs, but at the cost of losing some reachability and 424 application success. Again, when it comes to security, this is often 425 the case: to gain security one must give up some measure of 426 convenience. 428 3. Architectural Considerations of IPv6 NAT 430 First it is important to distinguish between the effects of a NAT box 431 vs. the effects of a firewall. A firewall is intended to prevent 432 unwanted traffic [RFC4948] without impacting wanted traffic, whereas 433 a NAT box also interferes with wanted traffic. In the remainder of 434 this section, the term "reachability" is used with respect to wanted 435 traffic. 437 The discussions on IPv6 NAT often refer to the wide deployment of 438 IPv4 NAT, where people have both identified tangible benefits and 439 gained operational experience. However the discussions so far seem 440 mostly focused on the potential benefits that IPv6 NAT may, or may 441 not, bring. Little attention has been paid to the bigger picture, as 442 we elaborate below. 444 When considering the benefits that IPv6 NAT may bring to a site that 445 deploys it, we must not overlook a bigger question: if one site 446 deploys IPv6 NAT, what is the potential impact it brings to the rest 447 of the Internet that does not do IPv6 NAT? By "the rest of the 448 Internet", we mean the Internet community that develops, deploys, and 449 uses end-to-end applications and protocols and hence are affected by 450 any loss of transparency (see [RFC2993] and [RFC4924] for further 451 discussion). This important question does not seem to have been 452 addressed, or addressed adequately. 454 We believe that the discussions on IPv6 NAT should be put in the 455 context of the overall Internet architecture. The foremost question 456 is not how many benefits one may derive from using IPv6 NAT, but more 457 fundamentally, whether a significant portion of parties on the 458 Internet are willing to deploy IPv6 NAT, and hence whether we want to 459 make IP address translation a permanent building block in the 460 Internet architecture. 462 One may argue that the answers to the above questions depend on 463 whether we can find adequate solutions to the renumbering, site 464 multihoming, and edge network configuration problems, and whether the 465 solutions provide transparency or not. If transparency is not 466 provided, making NAT a permanent building block in the Internet would 467 represent a fundamental architectural change. 469 It is desirable that IPv6 users and applications be able to reach 470 each other directly without having to worry about address translation 471 boxes between the two ends. IPv6 application developers in general 472 should be able to program based on the assumption of end-to-end 473 reachability (of wanted traffic), without having to address the issue 474 of traversing NAT boxes. For example, referrals and multi-party 475 conversations are straightforward with end-to-end addressing, but 476 vastly complicated in the presence of address translation. 477 Similarly, network administrators should be able to run their 478 networks without the added complexity of NATs, which can bring not 479 only the cost of additional boxes, but also increased difficulties in 480 network monitoring and problem debugging. 482 Given the diversity of the Internet user populations and the 483 diversity in today's operational practice, it is conceivable that 484 some parties may have a strong desire to deploy IPv6 NAT, and the 485 Internet should accommodate different views that lead to different 486 practices (i.e., some using IPv6 NAT, others not). 488 If we accept the view that some, but not all, parties want IPv6 NAT, 489 then the real debate should not be on what benefits IPv6 NAT may 490 bring to the parties who deploy it. It is undeniable that network 491 address translation can bring certain benefits to its users. 492 However, the real challenge we should address is how to design IPv6 493 NAT in such a way that it can hide its impact within some localized 494 scope. If IPv6 NAT design can achieve this goal, then the Internet 495 as a whole can strive for (re-installing) the end-to-end reachability 496 model. 498 4. Solution Space 500 From an end-to-end perspective, the solution space for renumbering 501 and multihoming can be broadly divided into three classes: 503 1. Endpoints get a stable, globally reachable address: In this class 504 of solutions, end sites use provider-independent addressing and 505 hence endpoints are unaffected by changing service providers. 506 For this to be a complete solution, provider-independent 507 addressing must be available to all managed networks (i.e., all 508 networks that use manual configuration of addresses or prefixes 509 in any type of system). However, in today's practice, assigning 510 provider-independent addresses to all networks, including small 511 ones, raises concerns with the scalability of the global routing 512 system. This is an area of ongoing research and experimentation. 513 In practice, network administrators have also been developing 514 short-term approaches to resolve today's gap between the 515 continued routing table growth and limitations in existing router 516 capacity [NANOG]. 517 2. Endpoints get a stable but non-globally-routable address on 518 physical interfaces but a dynamic, globally routable address 519 inside a tunnel: In this class of solutions, hosts use locally- 520 scoped (and hence provider-independent) addresses for 521 communication within the site using their physical interfaces. 522 As a result, managed systems such as routers, DHCP servers, etc. 523 all see stable addresses. Tunneling from the host to some 524 infrastructure device is then used to communicate externally. 525 Tunneling provides the host with globally routable addresses 526 which may change, but address changes are constrained to systems 527 that operate over or beyond the tunnel, including DNS servers and 528 applications. These systems, however, are the ones that often 529 can already deal with changes today using mechanisms such as DNS 530 dynamic update. However, if endpoints and the tunnel 531 infrastructure devices are owned by different organizations, then 532 solutions are harder to incrementally deploy due to the incentive 533 and coordination issues involved. 534 3. Endpoints get a stable address which gets translated in the 535 network: In this class of solutions, end sites use non-globally- 536 routable addresses within the site, and translate them to 537 globally routable addresses somewhere in the network. In 538 general, this causes the loss of end-to-end transparency which is 539 the subject of [RFC4924] and the documents it surveys. If the 540 translation is reversible, and the translation is indeed reversed 541 by the time it reaches the other end of communication, then end- 542 to-end transparency can be provided. However if the two 543 translators involved are owned by different organizations, then 544 solutions are harder to incrementally deploy due to the incentive 545 and coordination issues involved. 547 Concerning routing scalability, although there is no immediate 548 danger, routing scalability has been a long time concern in 549 operational communities, and an effective and deployable solution 550 must be found. We observe that the question at hand is not about 551 whether some parties can run NAT, but rather, whether the Internet as 552 a whole would be willing to rely on NAT to curtail the routing 553 scalability problem, and whether we have investigated all the 554 potential impacts of doing so to understand its cost on the overall 555 architecture. If effective solutions can be deployed in time to 556 allow assigning provider-independent IPv6 addresses to all user 557 communities, the Internet can avoid the complexity and fragility and 558 other unforeseen problems introduced by NAT. 560 4.1. Discussion 562 As [RFC4924] states: 563 A network that does not filter or transform the data that it 564 carries may be said to be "transparent" or "oblivious" to the 565 content of packets. Networks that provide oblivious transport 566 enable the deployment of new services without requiring changes to 567 the core. It is this flexibility that is perhaps both the 568 Internet's most essential characteristic as well as one of the 569 most important contributors to its success. 571 We believe that providing end-to-end transparency, as defined above, 572 is key to the success of the Internet. While some fields of traffic 573 (e.g., Hop Limit) are defined to be mutable, transparency requires 574 that fields not defined as such arrive un-transformed. Currently, 575 the source and destination addresses are defined as immutable fields, 576 and are used as such by many protocols and applications. 578 Each of the three classes of solution can be defined in a way that 579 preserves end-to-end transparency. 581 While we do not consider IPv6 NATs to be desirable, we understand 582 that some deployment of them is likely unless workable solutions to 583 avoiding renumbering, facilitating multihoming without adversely 584 impacting routing scalability, and homogeneity are generally 585 recognized as useful and appropriate. 587 As such, we strongly encourage the community to consider end-to-end 588 transparency as a requirement when proposing any solution, whether it 589 be based on tunneling or translation or some other technique. 590 Solutions can then be compared based on other aspects such as 591 scalability and ease of deployment. 593 5. Security Considerations 595 Section 2 discusses potential privacy concerns as part of the Host 596 Counting and Topology Hiding problems. 598 6. IANA Considerations 600 [RFC Editor: please remove this section prior to publication.] 602 This document has no IANA Actions. 604 7. IAB Members at the time of this writing 606 Marcelo Bagnulo 607 Gonzalo Camarillo 608 Stuart Cheshire 609 Vijay Gill 610 Russ Housley 611 John Klensin 612 Olaf Kolkman 613 Gregory Lebovitz 614 Andrew Malis 615 Danny McPherson 616 David Oran 617 Jon Peterson 618 Dave Thaler 620 8. References 622 8.1. Normative References 624 8.2. Informative References 626 [Bellovin] 627 Bellovin, S., "A Technique for Counting NATted Hosts", 628 Proc. Second Internet Measurement Workshop , 629 November 2002, 630 . 632 [I-D.carpenter-renum-needs-work] 633 Carpenter, B., Atkinson, R., and H. Flinck, "Renumbering 634 still needs work", draft-carpenter-renum-needs-work-05 635 (work in progress), January 2010. 637 [NANOG] "Extending the Life of Layer 3 Switches in a 256k+ Route 638 World", NANOG 44 , October 2008, . 642 [RFC2993] Hain, T., "Architectural Implications of NAT", RFC 2993, 643 November 2000. 645 [RFC3041] Narten, T. and R. Draves, "Privacy Extensions for 646 Stateless Address Autoconfiguration in IPv6", RFC 3041, 647 January 2001. 649 [RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, 650 A., Peterson, J., Sparks, R., Handley, M., and E. 652 Schooler, "SIP: Session Initiation Protocol", RFC 3261, 653 June 2002. 655 [RFC4380] Huitema, C., "Teredo: Tunneling IPv6 over UDP through 656 Network Address Translations (NATs)", RFC 4380, 657 February 2006. 659 [RFC4864] Van de Velde, G., Hain, T., Droms, R., Carpenter, B., and 660 E. Klein, "Local Network Protection for IPv6", RFC 4864, 661 May 2007. 663 [RFC4924] Aboba, B. and E. Davies, "Reflections on Internet 664 Transparency", RFC 4924, July 2007. 666 [RFC4948] Andersson, L., Davies, E., and L. Zhang, "Report from the 667 IAB workshop on Unwanted Traffic March 9-10, 2006", 668 RFC 4948, August 2007. 670 [RFC4960] Stewart, R., "Stream Control Transmission Protocol", 671 RFC 4960, September 2007. 673 [RFC5389] Rosenberg, J., Mahy, R., Matthews, P., and D. Wing, 674 "Session Traversal Utilities for NAT (STUN)", RFC 5389, 675 October 2008. 677 Authors' Addresses 679 Dave Thaler 680 Microsoft Corporation 681 One Microsoft Way 682 Redmond, WA 98052 683 USA 685 Phone: +1 425 703 8835 686 Email: dthaler@microsoft.com 688 Lixia Zhang 689 UCLA Computer Science Department 690 3713 Boelter Hall 691 Los Angeles, CA 90095 692 USA 694 Phone: +1 310 825 2695 695 Email: lixia@cs.ucla.edu 696 Gregory Lebovitz 697 Juniper Networks, Inc. 698 1194 North Mathilda Ave. 699 Sunnyvale, CA 94089 700 USA 702 Email: gregory.ietf@gmail.com