idnits 2.17.1 draft-iab-ntwlyrws-over-03.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Looks like you're using RFC 2026 boilerplate. This must be updated to follow RFC 3978/3979, as updated by RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- == No 'Intended status' indicated for this document; assuming Proposed Standard 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.) ** The document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. ** The document seems to lack a both a reference to RFC 2119 and the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. RFC 2119 keyword, line 210: '...tographically protected and hence MUST...' Miscellaneous warnings: ---------------------------------------------------------------------------- -- 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 (July 2000) is 8683 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) ** Downref: Normative reference to an Informational draft: draft-carpenter-transparency (ref. '1') == Outdated reference: A later version (-09) exists of draft-iab-nat-implications-06 ** Downref: Normative reference to an Informational draft: draft-iab-nat-implications (ref. '2') ** Downref: Normative reference to an Informational RFC: RFC 1900 (ref. '3') ** Downref: Normative reference to an Informational RFC: RFC 2071 (ref. '4') -- Possible downref: Normative reference to a draft: ref. '5' == Outdated reference: A later version (-08) exists of draft-ietf-ipngwg-dns-lookups-06 ** Downref: Normative reference to an Historic draft: draft-ietf-ipngwg-dns-lookups (ref. '6') ** Downref: Normative reference to an Informational draft: draft-ietf-nat-dns-alg (ref. '7') ** Obsolete normative reference: RFC 2535 (ref. '8') (Obsoleted by RFC 4033, RFC 4034, RFC 4035) == Outdated reference: A later version (-07) exists of draft-ietf-nat-rsip-protocol-05 ** Downref: Normative reference to an Experimental draft: draft-ietf-nat-rsip-protocol (ref. '9') == Outdated reference: A later version (-05) exists of draft-ietf-nat-rsip-framework-03 ** Downref: Normative reference to an Experimental draft: draft-ietf-nat-rsip-framework (ref. '10') == Outdated reference: A later version (-04) exists of draft-ietf-nat-rsip-ipsec-02 ** Downref: Normative reference to an Experimental draft: draft-ietf-nat-rsip-ipsec (ref. '11') == Outdated reference: A later version (-05) exists of draft-ietf-nat-protocol-complications-01 ** Downref: Normative reference to an Informational draft: draft-ietf-nat-protocol-complications (ref. '12') ** Downref: Normative reference to an Historic draft: draft-ietf-ngtrans-natpt (ref. '13') == Outdated reference: A later version (-06) exists of draft-ietf-ngtrans-mech-04 == Outdated reference: A later version (-07) exists of draft-ietf-ngtrans-6to4-03 Summary: 16 errors (**), 0 flaws (~~), 9 warnings (==), 3 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Internet Architecture Board M. Kaat 2 INTERNET-DRAFT SURFnet ExpertiseCentrum bv 3 July 2000 5 Overview of 1999 IAB Network Layer Workshop 6 draft-iab-ntwlyrws-over-03.txt 8 Status of this Memo 10 This document is an Internet-Draft and is in full conformance with 11 all provisions of Section 10 of RFC2026. 13 Internet-Drafts are working documents of the Internet Engineering 14 Task Force (IETF), its areas, and its working groups. Note that 15 other groups may also distribute working documents as Internet- 16 Drafts. 18 Internet-Drafts are draft documents valid for a maximum of six months 19 and may be updated, replaced, or obsoleted by other documents at any 20 time. It is inappropriate to use Internet-Drafts as reference 21 material or to cite them other than as "work in progress." 23 The list of current Internet-Drafts can be accessed at 24 http://www.ietf.org/ietf/1id-abstracts.txt 26 The list of Internet-Draft Shadow Directories can be accessed at 27 http://www.ietf.org/shadow.html. 29 Distribution of this memo is unlimited. 31 Abstract 33 This document is an overview of a workshop held by the Internet 34 Architecture Board (IAB) on the Internet Network Layer architecture 35 hosted by SURFnet in Utrecht, the Netherlands on 7-9 July 1999. 36 The goal of the workshop was to understand the state of the network 37 layer and its impact on continued growth and usage of the Internet. 38 Different technical scenarios for the (foreseeable) future and the 39 impact of external influences were studied. This report lists the 40 conclusions and recommendations to the IETF community. 42 Comments should be submitted to the workshop@dl.surfnet.nl mailing 43 list. 45 Table of Contents 47 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . 2 48 2. Conclusions and Observations . . . . . . . . . . . . . . . 3 49 2.1 Transparency. . . . . . . . . . . . . . . . . . . . . . 3 50 2.2 NAT, Application Level Gateways & Firewalls . . . . . . 4 51 2.3 Identification and Addressing . . . . . . . . . . . . . 4 52 2.4 Observations on Address Space . . . . . . . . . . . . . 5 53 2.5 Routing Issues. . . . . . . . . . . . . . . . . . . . . 5 54 2.6 Observations on Mobility. . . . . . . . . . . . . . . . 6 55 2.7 DNS Issues. . . . . . . . . . . . . . . . . . . . . . . 7 56 2.8 NAT and RSIP. . . . . . . . . . . . . . . . . . . . . . 7 57 2.9 NAT, RSIP and IPv6. . . . . . . . . . . . . . . . . . . 8 58 2.10 Observations on IPv6. . . . . . . . . . . . . . . . . . 9 59 3. Recommendations. . . . . . . . . . . . . . . . . . . . . . 10 60 3.1 Recommendations on Namespace . . . . . . . . . . . . . . 10 61 3.2 Recommendations on RSIP. . . . . . . . . . . . . . . . . 10 62 3.3 Recommendations on IPv6. . . . . . . . . . . . . . . . . 10 63 3.4 Recommendations on IPsec . . . . . . . . . . . . . . . . 11 64 3.5 Recommendations on DNS . . . . . . . . . . . . . . . . . 11 65 3.6 Recommendations on Routing . . . . . . . . . . . . . . . 11 66 3.7 Recommendations on Application Layer and APIs. . . . . . 12 67 4. Security Considerations. . . . . . . . . . . . . . . . . . 12 68 References. . . . . . . . . . . . . . . . . . . . . . . . . . 13 69 Appendix A. Participants. . . . . . . . . . . . . . . . . . . 14 70 Author's Address. . . . . . . . . . . . . . . . . . . . . . . 15 72 1. Introduction 74 From July 7 to July 9, 1999 the Internet Architecture Board (IAB) 75 held a workshop on the architecture of the Internet Network Layer. 76 The Network Layer is usually referred to as the IP layer. The goal 77 of the workshop was to discuss the current state of the Network Layer 78 and the impact various currently deployed or future mechanisms and 79 technologies might have on the continued growth and usage of the 80 Internet. 82 The most important issues to be discussed were: 84 o Status of IPv6 deployment and transition issues 85 o Alternative technical strategies in case IPv6 is not adopted 86 o Globally unique addresses and 32 bit address depletion 87 o Global connectivity and reachability 88 o Fragmentation of the Internet 89 o End to end transparency and the progressive loss thereof 90 o End to end security 91 o Complications of address sharing mechanisms (NAT, RSIP) 92 o Separation of identification and location in addressing 93 o Architecture and scaling of the current routing system 94 The participants looked into several technical scenarios and 95 discussed the feasibility and probability of the deployment of each 96 scenario. Among the scenarios were for example full migration to 97 IPv6, IPv6 deployment only in certain segments of the network, no 98 significant deployment of IPv6 and increased segmentation of the IPv4 99 address space due to the use of NAT devices. 101 Based on the discussion of these scenarios several trends and 102 external influences were identified which could have a large impact 103 on the status of the network layer, such as the deployment of 104 wireless network technologies, mobile networked devices and special 105 purpose IP devices. 107 The following technical issues were identified to be important 108 goals: 110 o Deployment of end to end security 111 o Deployment of end to end transport 112 o Global connectivity and reachability should be maintained 113 o It should be easy to deploy new applications 114 o It should be easy to connect new hosts and networks to the 115 Internet ("plug and ping") 117 By the notion "deployment of end to end transport" it is meant that 118 it is a goal to be able to deploy new applications that span from any 119 host to any other host without intermediaries, and this requires 120 transport protocols with similar span (see also [1]). 122 This document summarizes the conclusions and recommendations made by 123 the workshop. It should be noted that not all participants agreed 124 with all of the statements, and it was not clear whether anyone 125 agreed with all of them. The recommendations made however are based 126 on strong consensus among the participants. 128 2. Conclusions and Observations 130 The participants came to a number of conclusions and observations on 131 several of the issues mentioned in section 1. In the following 132 sections 2.1-2.10 these conclusions will be described. 134 2.1 Transparency 136 In the discussions transparency was referred to as the original 137 Internet concept of a single universal logical addressing scheme and 138 the mechanisms by which packets may flow from source to destination 139 essentially unaltered [1]. This traditional end to end transparency 140 has been lost in the current Internet, specifically the assumption 141 that IPv4 addresses are globally unique or invariant is no longer 142 true. 144 There are multiple causes for the loss of transparency, for example 145 the deployment of network address translation devices, the use of 146 private addresses, firewalls and application level gateways, proxies 147 and caches. These mechanisms increase fragmentation of the network 148 layer, which causes problems for many applications on the Internet. 149 It adds up to complexity in applications design and inhibits the 150 deployment of new applications. In particular, it has a severe 151 effect on the deployment of end to end IP security. 153 Another consequence of fragmentation is the deployment of "split DNS" 154 or "two faced DNS", which means that the correspondence between a 155 given FQDN and an IPv4 address is no longer universal and stable over 156 long periods (see section 2.7). 158 End to end transparency will probably not be restored due to the fact 159 that some of the mechanisms have an intrinsic value (e.g. firewalls, 160 caches and proxies) and the loss of transparency may be considered by 161 some as a security feature. It was however concluded that end to end 162 transparency is desirable and an important issue to pursue. 163 Transparency is further explored in [1]. 165 2.2 NAT, Application Level Gateways & Firewalls 167 The previous section indicated that the deployment of NAT (Network 168 Address Translation), Application Level Gateways and firewalls causes 169 loss of network transparency. Each of them is incompatible with 170 certain applications because they interfere with the assumption of 171 end to end transparency. NAT especially complicates setting up 172 servers, peer to peer communications and "always-on" hosts as the 173 endpoint identifiers, i.e. IP addresses, used to set up connections 174 are globally ambiguous and not stable (see [2]). 176 NAT, application level gateways and firewalls however are being 177 increasingly widely deployed as there are also advantages to each, 178 either real or perceived. Increased deployment causes a further 179 decline of network transparency and this inhibits the deployment of 180 new applications. Many new applications will require specialized 181 Application Level Gateways (ALGs) to be added to NAT devices, before 182 those applications will work correctly when running through a NAT 183 device. However, some applications cannot operate effectively with 184 NAT even with an ALG. 186 2.3 Identification and Addressing 188 In the original IPv4 network architecture hosts are globally, 189 permanently and uniquely identified by an IPv4 address. Such an IP 190 address is used for identification of the node as well as for 191 locating the node on the network. IPv4 in fact mingles the semantics 192 of node identity with the mechanism used to deliver packets to the 193 node. The deployment of mechanisms that separate the network into 194 multiple address spaces breaks the assumption that a host can be 195 uniquely identified by a single IP address. Besides that, hosts may 196 wish to move to a different location in the network but keep their 197 identity the same. The lack of differentiation between the identity 198 and the location of a host leads to a number of problems in the 199 current architecture. 201 Several technologies at this moment use tunneling techniques to 202 overcome the problem or cannot be deployed in the case of separate 203 address spaces. If a node could have some sort of a unique 204 identifier or endpoint name this would help in solving a number of 205 problems. 207 It was concluded that it may be desirable on theoretical grounds to 208 separate the node identity from the node locator. This is especially 209 true for IPsec, since IP addresses are used (in transport mode) as 210 identifiers which are cryptographically protected and hence MUST 211 remain unchanged during transport. However, such a separation of 212 identity and location will not be available as a near-term solution, 213 and will probably require changes to transport level protocols. 214 However, the current specification of IPsec does allow to use some 215 other identifier than an IP address. 217 2.4 Observations on Address Space 219 There is a significant risk that a single 32 bit global address space 220 is insufficient for foreseeable needs or desires. The participants' 221 opinions about the time scale over which new IPv4 addresses will 222 still be available for assignment ranged from 2 to 20 years. 223 However, there is no doubt that at the present time, users cannot 224 obtain as much IPv4 address space as they desire. This is partly a 225 result of the current stewardship policies of the Regional Internet 226 Registries (RIRs). 228 It was concluded that it ought to be possible for anybody to have 229 global addresses when required or desired. The absence of this 230 inhibits the deployment of some types of applications. It should 231 however be noted that there will always be administrative boundaries, 232 firewalls and intranets, because of the need for security and the 233 implementation of policies. NAT is seen as a significant 234 complication on these boundaries. It is often perceived as a 235 security feature because people are confusing NATs with firewalls. 237 2.5 Routing Issues 239 A number of concerns were raised regarding the scaling of the current 240 routing system. With current technology, the number of prefixes that 241 can be used is limited by the time taken for the routing algorithm 242 to converge, rather than by memory size, lookup time, or some other 243 factor. The limit is unknown, but there is some speculation, of 244 extremely unclear validity, that it is on the order of a few hundred 245 thousand prefixes. Besides the computational load of calculating 246 routing tables, the time it takes to distribute routing updates 247 across the network, the robustness and security of the current 248 routing system are also important issues. The only known addressing 249 scheme which produces scalable routing mechanisms depends on 250 topologically aggregated addresses, which requires that sites 251 renumber when their position in the global topology changes. 252 Renumbering remains operationally difficult and expensive ([3], [4]). 253 It is not clear whether the deployment of IPv6 would solve the 254 current routing problems, but it should do so if it makes renumbering 255 easier. 257 At least one backbone operator has concerns about the convergence 258 time of internetwork-wide routing during a failover. This operator 259 believes that current convergence times are on the order of half a 260 minute, and possibly getting worse. Others in the routing community 261 did not believe that the convergence times are a current issue. 262 Some, who believe that real-time applications (e.g. telephony) 263 require sub-second convergence, are concerned about the implications 264 of convergence times of a half minute on such applications. 266 Further research is needed on routing mechanisms that might help 267 palliate the current entropy in the routing tables, and can help 268 reduce the convergence time of routing computations. 270 The workshop discussed global routing in a hypothetical scenario 271 with no distinguished root global address space. Nobody had an idea 272 how to make such a system work. There is currently no well-defined 273 proposal for a new routing system that could solve such a problem. 275 For IPv6 routing in particular, the GSE/8+8 proposal and IPNG WG 276 analysis of this proposal ([5]) are still being examined by the IESG. 277 There is no consensus in the workshop whether this proposal could be 278 made deployable. 280 2.6 Observations on Mobility 282 Mobility and roaming require a globally unique identifier. This does 283 not have to be an IP address. Mobile nodes must have a widely usable 284 identifier for their location on the network, which is an issue if 285 private IP addresses are used or the IP address is ambiguous (see 286 also section 2.3). Currently tunnels are used to route traffic to a 287 mobile node. Another option would be to maintain state information 288 at intermediate points in the network if changes are made to the 289 packets. This however reduces the flexibility and it breaks the end 290 to end model of the network. Keeping state in the network is usually 291 considered a bad thing. Tunnels on the other hand reduce the MTU 292 size. Mobility was not discussed in detail as a separate IAB 293 workshop is planned on this topic. 295 2.7 DNS issues 297 If IPv6 is widely deployed, the current line of thinking is that site 298 renumbering will be significantly more frequent than today. This 299 will have an impact on DNS updates. It is not clear what the scale 300 of DNS updates might be, but in the most aggressive models it could 301 be millions a day. Deployment of the A6 record type which is defined 302 to map a domain name to an IPv6 address, with the provision for 303 indirection for leading prefix bits, could make this possible ([6]). 305 Another issue is the security aspect of frequent updates, as they 306 would have to been done dynamically. Unless we have fully secured 307 DNS, it could increase security risks. Cached TTL values might 308 introduce problems as the cached records of renumbered hosts will 309 not be updated in time. This will become especially a problem if 310 rapid renumbering is needed. 312 Another already mentioned issue is the deployment of split DNS (see 313 section 2.1). This concept is widely used in the Intranet model, 314 where the DNS provides different information to inside and outside 315 queries. This does not necessarily depend on whether private 316 addresses are used on the inside, as firewalls and policies may also 317 make this desirable. The use of split DNS seems inevitable as 318 Intranets will remain widely deployed. But operating a split DNS 319 raises a lot of management and administrative issues. As a work 320 around, a DNS Application Level Gateway ([7]) (perhaps as an 321 extension to a NAT device) may be deployed, which intercepts DNS 322 messages and modifies the contents to provide the appropriate 323 answers. This has the disadvantage that it interferes with the use 324 of DNSSEC ([8]). 326 The deployment of split DNS, or more generally the existence of 327 separate name spaces, makes the use of Fully Qualified Domain Names 328 (FQDNs) as endpoint identifiers more complex. 330 2.8 NAT and RSIP 332 Realm-Specific IP (RSIP), a mechanism for use with IPv4, is a work 333 item of the IETF NAT WG. It is intended as an alternative (or as a 334 complement) to network address translation (NAT) for IPv4, but other 335 uses are possible (for example, allowing end to end traffic 336 across firewalls). It is similar to NAT, in that it allows sharing a 337 small number of external IPv4 addresses among a number of hosts in a 338 local address domain (called a 'realm'). However, it differs from 339 NAT in that the hosts know that different externally-visible IPv4 340 addresses are being used to refer to them outside their local realm, 341 and they know what their temporary external address is. The 342 addresses and other information are obtained from an RSIP server, 343 and the packets are tunneled across the first routing realm ([9], 344 [10]). 346 The difference between NAT and RSIP - that an RSIP client is aware of 347 the fact that it uses an IP address from another address space, while 348 with NAT, neither endpoint is aware that the addresses in the packets 349 are being translated - is significant. Unlike NAT, RSIP has the 350 potential to work with protocols that require IP addresses to remain 351 unmodified between the source and destination. For example, whereas 352 NAT gateways preclude the use of IPsec across them, RSIP servers can 353 allow it [11]. 355 The addition of RSIP to NATs may allow them to support some 356 applications that cannot work with traditional NAT ([12]), but it 357 does require that hosts be modified to act as RSIP clients. It 358 requires changes to the host's TCP/IP stack, any layer-three protocol 359 that needs to be made RSIP-aware will have to be modified (e.g. ICMP) 360 and certain applications may have to be changed. The exact changes 361 needed to host or application software are not quite well known at 362 this moment and further research into RSIP is required. 364 Both NAT and RSIP assume that the Internet retains a core of global 365 address space with a coherent DNS. There is no fully prepared model 366 for NAT or RSIP without such a core; therefore NAT and RSIP face an 367 uncertain future whenever the IPv4 address space is finally exhausted 368 (see section 2.4). Thus it is also a widely held view that in the 369 longer term the complications caused by the lack of globally unique 370 addresses, in both NAT and RSIP, might be a serious handicap ([1]). 372 If optimistic assumptions are made about RSIP (it is still being 373 defined and a number of features have not been implemented yet), the 374 combination of NAT and RSIP seems to work in most cases. Whether 375 RSIP introduces specific new problems, as well as removing some of 376 the NAT issues, remains to be determined. 378 Both NAT and RSIP may have trouble with the future killer 379 application, especially when this needs QoS features, security and/or 380 multicast. And if it needs peer to peer communication (i.e. there 381 would be no clear distinction between a server and a client) or 382 assumes "always-on" systems, this would probably be complex with 383 both NAT and RSIP (see also section 2.2). 385 2.9 NAT, RSIP and IPv6 387 Assuming IPv6 is going to be widely deployed, network address 388 translation techniques could play an important role in the transition 389 process from IPv4 to IPv6 ([13]). The impact of adding RSIP support 390 to hosts is not quite clear at this moment, but it is less than 391 adding IPv6 support since most applications probably don't need to be 392 changed. And RSIP needs no changes to the routing infrastructure, 393 but techniques such as automatic tunneling ([14]) and 6to4 ([15]) 394 would also allow IPv6 traffic to be passed over the existing IPv4 395 routing infrastructure. While RSIP is principally a tool for 396 extending the life of IPv4, it is not a roadblock for the transition 397 to IPv6. The development of RSIP is behind that of IPv6, and more 398 study into RSIP is required to determine what the issues with RSIP 399 might be. 401 2.10 Observations on IPv6 403 An important issue in the workshop was whether the deployment of 404 IPv6 is feasible and probable. It was concluded that the transition 405 to IPv6 is plausible modulo certain issues. For example applications 406 need to be ported to IPv6, and production protocol stacks and 407 production IPv6 routers should be released. The core protocols are 408 finished, but other standards need to be pushed forward (e.g. MIBs). 409 A search through all RFCs for dependencies on IPv4 should be made, as 410 was done for the Y2K problem, and if problems are found they must be 411 resolved. As there are serious costs in implementing IPv6 code, good 412 business arguments are needed to promote IPv6. 414 One important question was whether IPv6 could help solve the current 415 problems in the routing system and make the Internet scale better. 416 It was concluded that "automatic" renumbering is really important 417 when prefixes are to be changed periodically to get the addressing 418 topology and routing optimized. This also means that any IP layer 419 and configuration dependencies in protocols and applications will 420 have to be removed ([3]). One example that was mentioned is the use 421 of IP addresses in the PKI (IKE). There might also be security 422 issues with "automatic" renumbering as DNS records have to be 423 updated dynamically (see also section 2.7). 425 Realistically, because of the dependencies mentioned, IPv6 426 renumbering cannot be truly automatic or instantaneous, but it has 427 the potential to be much simpler operationally than IPv4 renumbering, 428 and this is critical to market and ISP acceptance of IPv6. 430 Another issue is whether existing TCP connections (using the old 431 address(es)) should be maintained across renumbering. This would 432 make things much more complex and it is foreseen that old and new 433 addresses would normally overlap for a long time. 435 There was no consensus on how often renumbering would take place or 436 how automatic it can be in practice; there is not much experience 437 with renumbering (maybe only for small sites). 439 3. Recommendations 441 3.1 Recommendation on Namespace 443 The workshop recommends the IAB to appoint a panel to make specific 444 recommendations to the IETF about: 446 i) whether we should encourage more parts of the stack to adopt a 447 namespace for end to end interactions, so that a) NAT works 448 'better', and b) we have a little more independence between the 449 internetwork and transport and above layers; 450 ii) if so, whether we should have a single system-wide namespace for 451 this function, or whether it makes more sense to allow various 452 subsystems to chose the namespace that makes sense for them; 453 iii) and also, what namespace(s) [depending on the output of the point 454 above] that ought to be. 456 3.2 Recommendations on RSIP 458 RSIP is an interesting idea, but it needs further refinement and 459 study. It does not break the end to end network model in the same 460 way as NAT, because an RSIP host has explicit knowledge of its 461 temporary global address. Therefore, RSIP could solve some of the 462 issues with NAT. However, it is premature to recommend it as a 463 mainstream direction at this time. 465 It is recommended that the IETF should actively work on RSIP, 466 develop the details and study the issues. 468 3.3 Recommendations on IPv6 470 3.3.1 471 The current model of TLA-based addressing and routing should be 472 actively pursued. However, straightforward site renumbering using 473 TLA addresses is really needed, should be as nearly automatic as 474 possible, and should be shown to be real and credible by the IPv6 475 community. 477 3.3.2 478 Network address translation techniques, in addition to their 479 immediate use in pure IPv4 environments, should also be viewed as 480 part of the starting point for migration to IPv6. Also RSIP, if 481 successful, can be a starting point for IPv6 transition. 483 While the basic concepts of the IPv4 specific mechanisms NAT and 484 RSIP are also being used in elements of the proposed migration path 485 to IPv6 (in NAT-PT for NAT, and SIIT and AIIH for RSIP), NAT and 486 RSIP for IPv4 are not directly part of a documented transition path 487 to IPv6. 489 The exact implications, for transition to IPv6, of having NAT and 490 RSIP for IPv4 deployed, are not well understood. Strategies for 491 transition to IPv6, for use in IPv4 domains using NAT and RSIP for 492 IPv4, should be worked out and documented by the IETF. 494 3.3.3 495 The draft analysis of the 8+8/GSE proposal should be evaluated by 496 the IESG and accepted or rejected, without disturbing ongoing IPv6 497 deployment work. The IESG should use broad expertise, including 498 liaison with the endpoint namespace panel (see section 3.1) in 499 their evaluation. 501 3.4 Recommendations on IPsec 503 It is urgent that we implement and deploy IPsec using some other 504 identifier than 32-bit IP addresses (see section 2.3). The current 505 IPsec specifications support the use of several different Identity 506 types (e.g. Domain Name, User@Domain Name). 507 The IETF should promote implementation and deployment of non-address 508 Identities with IPsec. We strongly urge the IETF to completely 509 deprecate the use of the binary 32-bit IP addresses within IPsec, 510 except in certain very limited circumstances, such as router to 511 router tunnels; in particular any IP address dependencies should be 512 eliminated from ISAKMP and IKE. 513 Ubiquitous deployment of the Secure DNS Extensions ([8]) should be 514 strongly encouraged to facilitate widespread deployment of IPsec 515 (including IKE) without address-based Identity types. 517 3.5 Recommendations on DNS 519 Operational stability of DNS is paramount, especially during a 520 transition of the network layer, and both IPv6 and some network 521 address translation techniques place a heavier burden on DNS. It is 522 therefore recommended to the IETF that, except for those changes 523 that are already in progress and will support easier renumbering of 524 networks and improved security, no fundamental changes or additions 525 to the DNS be made for the foreseeable future. 527 In order to encourage widespread deployment of IPsec, rapid 528 deployment of DNSSEC is recommended to the operational community. 530 3.6 Recommendations on Routing 532 The only known addressing scheme which produces scalable routing 533 mechanisms depends on topologically aggregated addresses, which 534 requires that sites renumber when their position in the global 535 topology changes. Thus recommendation 3.3.1 is vital for routing 536 IPv6. 538 Although the same argument applies to IPv4, the installed base is 539 simply too large and the PIER working group showed that little can 540 be done to improve renumbering procedures for IPv4. However, NAT 541 and/or RSIP may help. 543 In the absence of a new addressing model to replace topological 544 aggregation, and of clear and substantial demand from the user 545 community for a new routing architecture (i.e. path-selection 546 mechanism) there is no reason to start work on standards for a 547 "next generation" routing system in the IETF. Therefore, we 548 recommend that work should continue in the IRTF Routing Research 549 Group. 551 3.7 Recommendations on Application layer and APIs 553 Most current APIs such as sockets are an obstacle to migration to 554 a new network layer of any kind, since they expose network layer 555 internal details such as addresses. 557 It is therefore recommended, as originally recommended in 558 RFC 1900 [3], that IETF protocols, and third-party applications, 559 avoid any explicit awareness of IP addresses, when efficient 560 operation of the protocol or application is feasible in the absence 561 of such awareness. Some applications and services may continue to 562 need to be aware of IP addresses. Until we once again have a uniform 563 address space for the Internet, such applications and services will 564 necessarily have limited deployability, and/or require ALG support in 565 NATs. 567 Also we recommend an effort in the IETF to generalize APIs to offer 568 abstraction from all network layer dependencies, perhaps as a side- 569 effect of the namespace study of section 3.1. 571 4. Security Considerations 573 The workshop did not address security as a separate topic, but the 574 role of firewalls, and the desirability of end to end deployment of 575 IPsec, were underlying assumptions. Specific recommendations on 576 security are covered in sections 3.4 and 3.5. 578 References 580 [1] B. Carpenter, "Internet Transparency", 581 draft-carpenter-transparency-05.txt, December 1999 582 (work in progress). 584 [2] T. Hain, "Architectural Implications of NAT", 585 draft-iab-nat-implications-06.txt, April 1999 (work in progress). 587 [3] B. Carpenter, Y. Rekhter, "Renumbering Needs Work", RFC 1900, 588 February 1996. 590 [4] P. Ferguson, H. Berkowitz, "Network Renumbering Overview: Why 591 would I want it and what is it anyway?", RFC 2071, January 1997. 593 [5] M. Crawford, A. Mankin, T. Narten, J.W. Stewart, III, L. Zhang, 594 "Separating Identifiers and Locators in Addresses: An Analysis of 595 the GSE Proposal for IPv6", draft-ietf-ipngwg-esd-analysis-05.txt, 596 October 1999 (work in progress). 598 [6] M. Crawford, C. Huitema, S. Thomson, "DNS Extensions to Support 599 IPv6 Address Aggregation and Renumbering", 600 draft-ietf-ipngwg-dns-lookups-06.txt, November 1999 601 (work in progress). 603 [7] P. Srisuresh, G. Tsirtsis, P. Akkiraju, A. Heffernan, 604 "DNS extension to Network Address Translators (DNS_ALG)", 605 draft-ietf-nat-dns-alg-04.txt, June 1999 (work in progress). 607 [8] D. Eastlake, "Domain Name System Security Extensions", RFC 2535, 608 March 1999. 610 [9] M. Borella, D. Grabelsky, J. Lo, K. Tuniguchi "Realm Specific IP: 611 Protocol Specification", draft-ietf-nat-rsip-protocol-05.txt, 612 January 2000 (work in progress). 614 [10] M. Borella, J. Lo, D. Grabelsky, G. Montenegro "Realm Specific IP: 615 Framework", draft-ietf-nat-rsip-framework-03.txt, December 1999 616 (work in progress). 618 [11] G. Montenegro, M. Borella, "RSIP Support for End-to-end IPsec," 619 draft-ietf-nat-rsip-ipsec-02.txt, February 2000 620 (work in progress). 622 [12] M. Holdrege, P. Srisuresh, "Protocol Complications with the 623 IP Network Address Translator (NAT)", 624 draft-ietf-nat-protocol-complications-01.txt, June 1999 625 (work in progress). 627 [13] G. Tsirtsis, P. Srisuresh, "Network Address Translation - Protocol 628 Translation (NAT-PT)", draft-ietf-ngtrans-natpt-07.txt, October 629 1999 (work in progress). 631 [14] R.E. Gilligan, E. Nordmark, "Transition Mechanisms for IPv6 Hosts 632 and Routers", draft-ietf-ngtrans-mech-04.txt, May 1999 633 (work in progress). 635 [15] B. Carpenter, K. Moore, "Connection of IPv6 Domains via IPv4 636 Clouds without Explicit Tunnels", draft-ietf-ngtrans-6to4-03.txt, 637 October 1999 (work in progress). 639 Appendix A. Participants 641 Harald Alvestrand Harald.Alvestrand@maxware.no 642 Ran Atkinson rja@corp.home.net 643 Rob Austein sra@epilogue.com 644 Steve Bellovin smb@research.att.com 645 Randy Bush randy@psg.com 646 Brian E Carpenter brian@hursley.ibm.com 647 Vint Cerf vcerf@MCI.NET 648 Noel Chiappa jnc@ginger.lcs.mit.edu 649 Matt Crawford crawdad@fnal.gov 650 Robert Elz kre@munnari.OZ.AU 651 Tony Hain tonyhain@microsoft.com 652 Matt Holdrege holdrege@lucent.com 653 Erik Huizer Erik.Huizer@sec.nl 654 Geoff Huston gih@telstra.net 655 Van Jacobson van@cisco.com 656 Marijke Kaat Marijke.Kaat@sec.nl 657 Daniel Karrenberg Daniel.Karrenberg@ripe.net 658 John Klensin klensin@mail1.reston.mci.net 659 Peter Lothberg roll@Stupi.SE 660 Olivier H. Martin Olivier.Martin@cern.ch 661 Gabriel Montenegro gab@eng.sun.com 662 Keith Moore moore@cs.utk.edu 663 Robert (Bob) Moskowitz rgm@htt-consult.com 664 Philip J. Nesser II pjnesser@nesser.com 665 Kathleen Nichols kmn@cisco.com 666 Erik Nordmark nordmark@eng.sun.com 667 Dave Oran oran@cisco.com 668 Yakov Rekhter yakov@cisco.com 669 Bill Sommerfeld sommerfeld@alum.mit.edu 670 Bert Wijnen wijnen@vnet.ibm.com 671 Lixia Zhang lixia@cs.ucla.edu 673 Author's Address 675 Marijke Kaat 676 SURFnet ExpertiseCentrum bv 677 P.O. Box 19115 678 3501 DC Utrecht 679 The Netherlands 680 Phone: +31 30 230 5305 681 Fax: +31 30 230 5329 682 E-mail: Marijke.Kaat@sec.nl