Internet Architecture Board M. Kaat INTERNET-DRAFT SURFnet ExpertiseCentrum bv August 1999 Overview of 1999 IAB Network Layer Workshop draft-ietf-iab-ntwlyrws-over-00.txt Status of this Memo This document is an Internet-Draft and is in full conformance with all provisions of Section 10 of RFC2026. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet- Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. Distribution of this memo is unlimited. Abstract This document is an overview of a workshop held by the Internet Architecture Board (IAB) on the Internet Network Layer architecture at SURFnet ExpertiseCentrum in Utrecht, the Netherlands on 7-9 July 1999. The goal of the workshop was to understand the state of the network layer and its impact on continued growth and usage of the Internet. Different technical scenarios for the (foreseeable) future and the impact of external influences were studied. This report lists the conclusions and recommendations to the IETF community. Comments should be submitted to the workshop@dl.surfnet.nl mailing list. Kaat Expires February 2000 [page 1] Internet Draft Network Layer Workshop Aug 1999 Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . 2 2. Conclusions and Observations . . . . . . . . . . . . . . . 3 2.1 Transparency. . . . . . . . . . . . . . . . . . . . . . 3 2.2 NAT, Application Gateways & Firewalls . . . . . . . . . 4 2.3 Identification and Addressing . . . . . . . . . . . . . 4 2.4 Observations on Address Space . . . . . . . . . . . . . 5 2.5 Routing Issues. . . . . . . . . . . . . . . . . . . . . 5 2.6 Observations on Mobility. . . . . . . . . . . . . . . . 6 2.7 DNS Issues. . . . . . . . . . . . . . . . . . . . . . . 6 2.8 NAT and RSIP. . . . . . . . . . . . . . . . . . . . . . 7 2.9 NAT, RSIP and IPv6. . . . . . . . . . . . . . . . . . . 8 2.10 Observations on IPv6. . . . . . . . . . . . . . . . . . 8 3. Recommendations. . . . . . . . . . . . . . . . . . . . . . 9 3.1 Recommendations on Namespace . . . . . . . . . . . . . . 9 3.2 Recommendations on RSIP. . . . . . . . . . . . . . . . . 9 3.3 Recommendations on IPv6. . . . . . . . . . . . . . . . . 9 3.4 Recommendations on IPSEC . . . . . . . . . . . . . . . . 9 3.5 Recommendations on DNS . . . . . . . . . . . . . . . . . 10 3.6 Recommendations on Routing . . . . . . . . . . . . . . . 10 3.7 Recommendations on Application Layer and APIs. . . . . . 10 4. Security Considerations. . . . . . . . . . . . . . . . . . 10 References. . . . . . . . . . . . . . . . . . . . . . . . . . 11 Appendix A. Participants. . . . . . . . . . . . . . . . . . . 12 Author's Address. . . . . . . . . . . . . . . . . . . . . . . 12 1. Introduction From July 7 to July 9, 1999 the Internet Architecture Board (IAB) held a workshop on the Internet Network Layer architecture. The Network Layer is usually referred to as the IP layer. The goal of the workshop was to discuss the current state of the Network Layer and the impact various, either currently deployed or future, mechanisms and technologies might have on the continued growth and usage of the Internet. The most important issues to be discussed were: o Status of IPv6 deployment and transition issues o Globally unique addresses and 32 bit address depletion o Global connectivity and reachability o Fragmentation of the Internet o End to end transparency and the progressive loss thereof o End to end security o Complications of address translation mechanisms (NAT, RSIP) o Separation of identification and location in addressing o Architecture and scaling of the current routing system Kaat Expires February 2000 [page 2] Internet Draft Network Layer Workshop Aug 1999 The participants looked into several technical scenarios and discussed the feasibility and probability of the deployment of each scenario. Among the scenarios were for example full migration to IPv6, IPv6 deployment only in certain segments of the network, no significant deployment of IPv6 and increased segmentation of the IPv4 address space due to the use of NAT devices. Based on the discussion of these scenarios several trends and external influences were identified which could have a large impact on the status of the network layer, such as the deployment of wireless network technologies, mobile networked devices and special purpose IP devices. The following technical issues were identified to be important goals: o Deployment of end to end security o Deployment of end to end transport o Global connectivity and reachability should be maintained o It should be easy to deploy new applications o It should be easy to connect new hosts and networks to the Internet ("plug and ping") This document summarises the conclusions and recommendations made by the workshop. It should be noted that not all participants agreed with all of the statements, and it was not clear whether anyone agreed with all of them. The recommendations made however are based on strong consensus among the participants. 2. Conclusions and Observations The participants came to a number of conclusions and observations on several of the issues mentioned in section 1. In the following sections 2.1-2.10 these conclusions will be described. 2.1 Transparency In the discussions transparency was referred to as the original Internet concept of a single universal logical addressing scheme and the mechanisms by which packets may flow from source to destination essentially unaltered [1]. This traditional end to end transparency has been lost in the current Internet, specifically the assumption that IPv4 addresses are globally unique or invariant is no longer true. There are multiple causes for the loss of transparency, for example the deployment of network address translation devices, the use of Kaat Expires February 2000 [page 3] Internet Draft Network Layer Workshop Aug 1999 private addresses, firewalls and application level gateways, proxies and caches. These mechanisms increase fragmentation of the network layer, which causes problems for many applications on the Internet. It adds up to complexity in applications design and inhibits the deployment of new applications. In particular, it has a severe effect on the deployment of end to end IP security. Another consequence of fragmentation is the deployment of "split DNS" or "two faced DNS", which means that the correspondence between a given FQDN and an IPv4 address is no longer universal and stable over long periods (see section 2.7). End to end transparency will probably not be restored due to the fact that some of the mechanisms have an intrinsic value (e.g. firewalls, caches and proxies) and the loss of transparency may be considered by some as a security feature. It was however concluded that end to end transparency is desirable and an important issue to pursue. Transparency is further explored in [1]. 2.2 NAT, Application Gateways & Firewalls In the previous section it was already discussed that the deployment of NAT (network Address Translation), application level gateways and firewalls causes loss of network transparency. Each of them is incompatible with certain applications because they interfere with the assumption of end to end transparency. Especially NAT complicates setting up servers, peer to peer communications and "always-on" hosts as the endpoint identifiers, i.e. IP addresses, used to set up connections are globally ambiguous and not stable (see [2]). NAT, application gateways and firewalls however are being increasingly widely deployed as there are also advantages to each, either real or perceived. Increased deployment causes a further decline of network transparency and inhibits the deployment of new applications. 2.3 Identification and Addressing In the original IPv4 network architecture hosts are globally, permanently and uniquely identified by an IPv4 address. Such an IP address is used for identification of the node as well as for locating the node on the network. IPv4 in fact mingles the semantics of node identity with the routing path to the node. The deployment of mechanisms that separate the network into multiple address spaces breaks the assumption that a host can be uniquely identified by a single IP address. Besides that hosts may wish to move to a Kaat Expires February 2000 [page 4] Internet Draft Network Layer Workshop Aug 1999 different location in the network but keep their identity the same. The lack of differentiation between the identity and the location of a host leads to a number of problems in the current architecture. Several technologies at this moment use tunneling techniques to overcome the problem or cannot be deployed in the case of separate address spaces. If a node should have some sort of a unique identifier or endpoint name this would help in solving a number of problems. It was concluded that it is desirable on theoretical grounds to separate the node identity from the node locator. This is especially true for IPSEC, since IP addresses are used (in transport mode) as identifiers which are protected and hence MUST remain unchanged during transport. This will however not be a near term solution, and will probably require changes to transport level protocols. With the current specification of IPSEC it is possible to use some another identifier than an IP address. 2.4 Observations on Address Space There is a significant risk that a single 32 bit global address space is insufficient for foreseeable needs or desires. The participants' opinions about the time scale over which IPv4 addresses will not be available anymore ranged from 2 to 20 years. At this moment users cannot obtain as much IPv4 address space as they desire. This is partly a result of the current stewardship policies of the registries. It was concluded that it ought to be possible for anybody to have global addresses when required or desired. The absence of this inhibits the deployment of some types of applications. It should however be noted that there will always be administrative boundaries, firewalls and intranets, because of the need for security and the implementation of policies. NAT is seen as a significant complication on these boundaries. It is often perceived as a security feature because people are confusing NATs with firewalls. 2.5 Routing Issues A number of concerns were raised regarding the scaling of the current routing system. The number of 100K prefixes in routing tables might be the limit that BGP4+ can handle. Not only the computational load, but also robustness and security of the current routing system are important issues. The implementation of topological routing, and therefore addressing, would require renumbering. This remains operationally difficult and expensive ([3], [4]). It is not clear whether the deployment of IPv6 would solve the current routing Kaat Expires February 2000 [page 5] Internet Draft Network Layer Workshop Aug 1999 problems, it should however make renumbering easier. Another issue that was identified is the convergence time of routing during a fail-over. Currently convergence time is in the order of 30 seconds, and that might get worse. Especially for real time applications that need sub-second convergence this is a problem. We either need a next generation routing system that can handle the current entropy in the topology or real easy renumbering for garbage collection in the routing graph. Assuming the case where there would not be a distinguished root global address space anymore, nobody had an idea how to make such a system work. There is currently no well-defined proposal for a new routing system that would solve the problems. The GSE/8+8 proposal and the analysis of the group that studied the proposal ([5]) is still being examined by the IESG. There is no consensus whether this proposal could be deployed. 2.6 Observations on Mobility Mobility and roaming require a globally unique identifier. This does not have to be an IP address. Mobile nodes have to be located on the network, which is an issue if private IP addresses are used or the IP address is ambiguous (see also section 2.3). Currently tunnels are used to route traffic to a mobile node. Another option would be to maintain state information at intermediate points in the network if changes are made to the packets. This however reduces the flexibility and it breaks the end to end model of the network. Keeping state in the network is usually considered a bad thing. Tunnels on the other hand reduce the MTU size. Mobility was not discussed in detail as there will be a separate IAB workshop on this issue in the near future. 2.7 DNS issues In the case that IPv6 will be widely deployed it is foreseen at this moment that frequent renumbering will take place. This will have an impact on DNS updates. It is not clear what the scale of DNS updates might be, it could be millions a day. Deployment of the A6 record type which is defined to map a domain name to an IPv6 address, with the provision for indirection for leading prefix bits, could make this possible ([6]). Another issue is the security aspect of frequent updates, as they would have to been done dynamically. Unless we have fully secured DNS, it could increase security risks. Cached TTL values might introduce problems as the cached records of renumbered hosts will not be updated in time. This will become especially a problem if rapid renumbering is needed (days versus hours versus minutes). Kaat Expires February 2000 [page 6] Internet Draft Network Layer Workshop Aug 1999 Another already mentioned issue is the deployment of split DNS (see section 2.1). This concept is widely used in the Intranet model, where the DNS provides different information to inside and outside queries. This does not necessarily depends on whether private addresses are used on the inside, firewalls and policies may also make this desirable. The use of split DNS seems inevitable as Intranets will remain widely deployed. But operating a split DNS raises a lot of management and administrative issues. As a work around a DNS application level gateway ([7]) may be deployed which intercepts DNS messages and modifies the contents to provide the appropriate answers. This has the disadvantage that it interferes with the use of DNSSEC ([8]). The deployment of split DNS, or more generally the existence of separate name spaces, makes the use of Fully Qualified Domain Names (FQDNs) as endpoint names more complex. 2.8 NAT and RSIP Realm-Specific IP (RSIP) is designed as an alternative to network address translation (NAT). It allows a client in one routing realm to directly use addresses and other routing parameters from a second realm. The addresses and other information are obtained from an RSIP server and the packets are tunneled across the first routing realm ([9], [10]). This architecture does not break the end to end model as NAT does, but it does require that hosts are modified to act as an RSIP client. An important difference between NAT and RSIP is that an RSIP client is aware of the fact that it uses an IP address from an other address space, while with NAT both endpoints in either space the address translation is transparent. This means that NAT will not work with protocols that require that the IP addresses remain unmodified between the source and destination. It is a widely held view that in the longer term the complications with NAT ([11]) might be a serious handicap. It was concluded that in the case of widely deployed NAT and RSIP a core of global address space with a coherent DNS must be assumed for this to work. If optimistic assumptions are made about RSIP (it is still being defined and a number of features have not been implemented yet), the combination of NAT and RSIP seems to work in most cases. Whether RSIP introduces specific problems, e.g. with end to end security, remains to be determined.[MK: issues????] Both NAT and RSIP may have trouble with the future killer application, especially when this needs QoS features, security and/or Kaat Expires February 2000 [page 7] Internet Draft Network Layer Workshop Aug 1999 multicast. And if it needs peer to peer communication (i.e. there would be no clear distinction between a server and a client) or assumes "always-on" systems, this would probably be complex with both NAT and RSIP (see also section 2.2). This could create a chicken and egg problem for new applications. 2.9 NAT, RSIP and IPv6 Assuming IPv6 is going to be widely deployed, NAT could have a function in the transition process from IPv4 to IPv6 ([12]). Maybe RSIP could have a similar function. RSIP has substantially less impact on applications than IPv6 has, and needs less change to the routing infrastructure. However, for hosts to deploy RSIP a new TCP/IP stack has to be implemented on them, just as with IPv6 hosts. The development of RSIP is behind on IPv6, and more study into RSIP is required to determine what the issues with RSIP might be. 2.10 Observations on IPv6 An important issue in the workshop was whether the deployment of IPv6 is feasible and probable. It was concluded that the transition to IPv6 is plausible modulo certain issues. For example applications need to be ported to IPv6, and production protocol stacks and production IPv6 routers should be released. The core protocols are finished, but other standards need to be pushed forward (e.g. MIBs). A search through all RFCs for dependencies on IPv4 must be done (like for the Y2K problem has been done) and if problems are found they must be resolved. As there are serious costs in implementing IPv6 code, good business arguments are needed to promote IPv6. One important question was whether IPv6 could help solve the current problems in the routing system and make the Internet scale better. It was concluded that "automatic" renumbering is really important when prefixes are to be changed periodically to get the addressing topology and routing optimized. This also means that any IP layer and configuration dependencies in protocols and applications will have to be removed ([3]). One example that was mentioned is the use of IP addresses in the PKI (IKE). There might also be security issues with "automatic" renumbering as DNS records have to be updated dynamically (see also section 2.7). Another issue is whether existing TCP connections (using the old address(es)) should be maintained across renumbering. This would make things much more complex and it is foreseen that old and new addresses would normally overlap for a long time. There was no consensus on how often renumbering would take place or how automatic it can be in practice; there is not much experience with IPv6 renumbering (maybe only for small sites). Kaat Expires February 2000 [page 8] Internet Draft Network Layer Workshop Aug 1999 3. Recommendations 3.1 Recommendation on Namespace The appointment by the IAB of a panel to make a recommendation to the IETF about: i) whether we should encourage more parts of the stack to adopt a namespace other than the 32-bit numbers, so that a) NAT works 'better', and b) we have a little more independence between the internetwork and transport and above layers; ii) if so, whether we should have a single system-wide namespace for this function, or whether it makes more sense to allow various subsystems to chose the namespace that makes sense for them; iii) and also, what namespace(s) [depending on the output of the point above] that ought to be. 3.2 Recommendations on RSIP RSIP is an interesting idea, but it needs further study. It does not break the end to end network model as a host has explicit knowledge of its temporary global address. Therefore, RSIP could solve some of the issues with NAT. It is premature to recommend it as a mainstream direction at this moment. It is recommended that the IETF should actively work on RSIP, develop the details and study the issues. 3.3 Recommendations on IPv6 TLA-based addressing and routing deployment should be actively pursued. Effective renumbering is really needed, must be as automatic as possible, and should be made real and credible with TLA addresses. NAT (and maybe RSIP) should be viewed as part of the migration path to IPv6. The examination by the IESG of the 8+8/GSE area should not disturb the ongoing IPv6 work. The IESG should use broad expertise, and should liaise with the endpoint namespace panel (see section 3.1) in their examination. 3.4 Recommendations on IPSEC It is urgent to implement and deploy IPSEC using some other identifier than binary 32-bit IP addresses (see section 2.3). Kaat Expires February 2000 [page 9] Internet Draft Network Layer Workshop Aug 1999 The current spec allows the use of another kind of identifier. The IP address dependency should be eliminated from IKE. 3.5 Recommendations on DNS It is recommended that no more fundamental changes at this moment should be proposed to the DNS. In order to encourage widespread deployment of IPSEC, rapid deployment of DNSSEC is encouraged. 3.6 Recommendations on Routing In order to make topological routing scale, IPv6 site renumbering should work as automatically as possible (see section 3.3). On automatic IPv4 site renumbering it was concluded that there is not much that can be done; the installed base is simply too large and there is not enough effort or interest in the IETF for this. See also the PIER Working Group conclusions. However, NAT and/or RSIP may help with renumbering. It is premature to start more work on a "next generation" routing system in the IETF. A possible place to work on this issue would be the IRTF Routing Research Group. 3.7 Recommendations on Application layer and APIs Most current APIs (not just sockets) are an obstacle to migration to a new network layer of any kind. The IPv6 socket API has steps in the right direction. It is recommended that applications should lose IP addresses (conform RFC 1900 [3]). Also it should be tried to generalise APIs to offer more abstraction. 4. Security Considerations (MK: needs to be done) Kaat Expires February 2000 [page 10] Internet Draft Network Layer Workshop Aug 1999 References [1] B. Carpenter, "Internet Transparency", draft-carpenter-transparency-02.txt, August 1999 (work in progress). [2] T. Hain, "Architectural Implications of NAT", draft-iab-nat-implications-04.txt, April 1999 (work in progress). [3] B. Carpenter, Y. Rekhter, "Renumbering Needs Work", RFC 1900, February 1996. [4] P. Ferguson, H. Berkowitz, "Network Renumbering Overview: Why would I want it and what is it anyway?", RFC 2071, January 1997. [5] M. Crawford, A. Mankin, T. Narten, J.W. Stewart, III, L. Zhang, "Separating Identifiers and Locators in Addresses: An Analysis of the GSE Proposal for IPv6", draft-ietf-ipngwg-esd-analysis-04.txt, February 1999 (work in progress). [6] M. Crawford, C. Huitema, S. Thomson, "DNS Extensions to Support IP Version 6", draft-ietf-ipngwg-dns-lookups-04.txt, May 1999 (work in progress). [7] P. Srisuresh, G. Tsirtsis, P. Akkiraju, A. Heffernan, "DNS extension to Network Address Translators (DNS_ALG)", draft-ietf-nat-dns-alg-04.txt, June 1999 (work in progress). [8] D. Eastlake, "Domain Name System Security Extensions", RFC 2535, March 1999. [9] M. Borella, D. Grabelsky, J. Lo, "Realm Specific IP: Protocol Specification", draft-ietf-nat-rsip-protocol-01.txt, April 1999 (work in progress). [10] J. Lo, M. Borella, D. Grabelsky, "Realm Specific IP: A Framework", draft-ietf-nat-rsip-framework-01.txt, May 1999 (work in progress). [11] M. Holdrege, P. Srisuresh, "Protocol Complications with the IP Network Address Translator (NAT), draft-ietf-nat-protocol-complications-01.txt, June 1999 (work in progress). [12] G. Tsirtsis, P. Srisuresh, "Network Address Translation - Protocol Translation (NAT-PT), draft-ietf-ngtrans-natpt-06.txt, June 1999 (work in progress). Kaat Expires February 2000 [page 11] Internet Draft Network Layer Workshop Aug 1999 Appendix A. Participants Harald Alvestrand Harald.Alvestrand@maxware.no Ran Atkinson rja@corp.home.net Rob Austein sra@epilogue.com Steve Bellovin smb@research.att.com Randy Bush randy@psg.com Brian E Carpenter brian@hursley.ibm.com Vint Cerf vcerf@MCI.NET Noel Chiappa jnc@ginger.lcs.mit.edu Matt Crawford crawdad@fnal.gov Robert Elz kre@munnari.OZ.AU Tony Hain tonyhain@microsoft.com Matt Holdrege matt@ascend.com Erik Huizer Erik.Huizer@sec.nl Geoff Huston gih@telstra.net Van Jacobson van@cisco.com Marijke Kaat Marijke.Kaat@sec.nl Daniel Karrenberg Daniel.Karrenberg@ripe.net John Klensin klensin@mail1.reston.mci.net Peter Lothberg roll@Stupi.SE Olivier H. Martin Olivier.Martin@cern.ch Gabriel Montenegro gab@eng.sun.com Keith Moore moore@cs.utk.edu Robert (Bob) Moskowitz rgm@htt-consult.com Philip J. Nesser II pjnesser@nesser.com Kathleen Nichols kmn@cisco.com Erik Nordmark nordmark@eng.sun.com Dave Oran oran@cisco.com Yakov Rekhter yakov@cisco.com Bill Sommerfeld sommerfeld@orchard.arlington.ma.us Bert Wijnen wijnen@vnet.ibm.com Lixia Zhang lixia@cs.ucla.edu Author's Address Marijke Kaat SURFnet ExpertiseCentrum bv P.O. Box 19115 3501 DC Utrecht The Netherlands Phone: +31 30 230 5305 Fax: +31 30 230 5329 E-mail: Marijke.Kaat@sec.nl Kaat Expires February 2000 [page 12]