Network Working Group M. Kaat Request for Comments: 2956 SURFnet ExpertiseCentrum bv Category: Informational October 2000 Overview of 1999 IAB Network Layer Workshop Status of this Memo This memo provides information for the Internet community. It does not specify an Internet standard of any kind. Distribution of this memo is unlimited. Copyright Notice Copyright (C) The Internet Society (2000). All Rights Reserved.
AbstractThis document is an overview of a workshop held by the Internet Architecture Board (IAB) on the Internet Network Layer architecture hosted by SURFnet 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 Internet Engineering Task Force (IETF) community. 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . 2 2. Conclusions and Observations . . . . . . . . . . . . . . . 3 2.1 Transparency. . . . . . . . . . . . . . . . . . . . . . 3 2.2 NAT, Application Level 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. . . . . . . . . . . . . . . . . . . . . . . 7 2.8 NAT and RSIP. . . . . . . . . . . . . . . . . . . . . . 7 2.9 NAT, RSIP and IPv6. . . . . . . . . . . . . . . . . . . 8 2.10 Observations on IPv6. . . . . . . . . . . . . . . . . . 9 3. Recommendations. . . . . . . . . . . . . . . . . . . . . . 10 3.1 Recommendations on Namespace . . . . . . . . . . . . . . 10 3.2 Recommendations on RSIP. . . . . . . . . . . . . . . . . 10 3.3 Recommendations on IPv6. . . . . . . . . . . . . . . . . 10 3.4 Recommendations on IPsec . . . . . . . . . . . . . . . . 11
3.5 Recommendations on DNS . . . . . . . . . . . . . . . . . 11 3.6 Recommendations on Routing . . . . . . . . . . . . . . . 12 3.7 Recommendations on Application Layer and APIs. . . . . . 12 4. Security Considerations. . . . . . . . . . . . . . . . . . 12 References. . . . . . . . . . . . . . . . . . . . . . . . . . 13 Appendix A. Participants. . . . . . . . . . . . . . . . . . . 15 Author's Address. . . . . . . . . . . . . . . . . . . . . . . 15 Full Copyright Statement . . . . . . . . . . . . . . . . . . 16
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") By the notion "deployment of end to end transport" it is meant that it is a goal to be able to deploy new applications that span from any host to any other host without intermediaries, and this requires transport protocols with similar span (see also ). This document summarizes 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. section 1. In the following sections 2.1-2.10 these conclusions will be described. 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 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 . 2]). NAT, application level 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 this inhibits the deployment of new applications. Many new applications will require specialized Application Level Gateways (ALGs) to be added to NAT devices, before those applications will work correctly when running through a NAT device. However, some applications cannot operate effectively with NAT even with an ALG.
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 could have some sort of a unique identifier or endpoint name this would help in solving a number of problems. It was concluded that it may be 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 cryptographically protected and hence MUST remain unchanged during transport. However, such a separation of identity and location will not be available as a near-term solution, and will probably require changes to transport level protocols. However, the current specification of IPsec does allow to use some other identifier than an IP address.
scheme which produces scalable routing mechanisms depends on topologically aggregated addresses, which requires that sites renumber when their position in the global topology changes. Renumbering remains operationally difficult and expensive (, ). It is not clear whether the deployment of IPv6 would solve the current routing problems, but it should do so if it makes renumbering easier. At least one backbone operator has concerns about the convergence time of internetwork-wide routing during a failover. This operator believes that current convergence times are on the order of half a minute, and possibly getting worse. Others in the routing community did not believe that the convergence times are a current issue. Some, who believe that real-time applications (e.g. telephony) require sub-second convergence, are concerned about the implications of convergence times of a half minute on such applications. Further research is needed on routing mechanisms that might help palliate the current entropy in the routing tables, and can help reduce the convergence time of routing computations. The workshop discussed global routing in a hypothetical scenario with no distinguished root global address space. Nobody had an idea how to make such a system work. There is currently no well-defined proposal for a new routing system that could solve such a problem. For IPv6 routing in particular, the GSE/8+8 proposal and IPNG WG analysis of this proposal () are still being examined by the IESG. There is no consensus in the workshop whether this proposal could be made deployable. 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 a separate IAB workshop is planned on this topic.
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. 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 depend on whether private addresses are used on the inside, as 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 () (perhaps as an extension to a NAT device) 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 (). 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 identifiers more complex.
know what their temporary external address is. The addresses and other information are obtained from an RSIP server, and the packets are tunneled across the first routing realm (, ). The difference between NAT and RSIP - that an RSIP client is aware of the fact that it uses an IP address from another address space, while with NAT, neither endpoint is aware that the addresses in the packets are being translated - is significant. Unlike NAT, RSIP has the potential to work with protocols that require IP addresses to remain unmodified between the source and destination. For example, whereas NAT gateways preclude the use of IPsec across them, RSIP servers can allow it . The addition of RSIP to NATs may allow them to support some applications that cannot work with traditional NAT (), but it does require that hosts be modified to act as RSIP clients. It requires changes to the host's TCP/IP stack, any layer-three protocol that needs to be made RSIP-aware will have to be modified (e.g. ICMP) and certain applications may have to be changed. The exact changes needed to host or application software are not quite well known at this moment and further research into RSIP is required. Both NAT and RSIP assume that the Internet retains a core of global address space with a coherent DNS. There is no fully prepared model for NAT or RSIP without such a core; therefore NAT and RSIP face an uncertain future whenever the IPv4 address space is finally exhausted (see section 2.4). Thus it is also a widely held view that in the longer term the complications caused by the lack of globally unique addresses, in both NAT and RSIP, might be a serious handicap (). 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 new problems, as well as removing some of the NAT issues, remains to be determined. Both NAT and RSIP may have trouble with the future killer application, especially when this needs QoS features, security and/or 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). 13]). The impact of adding RSIP support
to hosts is not quite clear at this moment, but it is less than adding IPv6 support since most applications probably don't need to be changed. And RSIP needs no changes to the routing infrastructure, but techniques such as automatic tunneling () and 6to4 () would also allow IPv6 traffic to be passed over the existing IPv4 routing infrastructure. While RSIP is principally a tool for extending the life of IPv4, it is not a roadblock for the transition to IPv6. The development of RSIP is behind that of IPv6, and more study into RSIP is required to determine what the issues with RSIP might be. 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). Realistically, because of the dependencies mentioned, IPv6 renumbering cannot be truly automatic or instantaneous, but it has the potential to be much simpler operationally than IPv4 renumbering, and this is critical to market and ISP acceptance of IPv6. 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 renumbering (maybe only for small sites).
While the basic concepts of the IPv4 specific mechanisms NAT and RSIP are also being used in elements of the proposed migration path to IPv6 (in NAT-PT for NAT, and SIIT and AIIH for RSIP), NAT and RSIP for IPv4 are not directly part of a documented transition path to IPv6. The exact implications, for transition to IPv6, of having NAT and RSIP for IPv4 deployed, are not well understood. Strategies for transition to IPv6, for use in IPv4 domains using NAT and RSIP for IPv4, should be worked out and documented by the IETF. section 3.1) in their evaluation. section 2.3). The current IPsec specifications support the use of several different Identity types (e.g. Domain Name, User@Domain Name). The IETF should promote implementation and deployment of non-address Identities with IPsec. We strongly urge the IETF to completely deprecate the use of the binary 32-bit IP addresses within IPsec, except in certain very limited circumstances, such as router to router tunnels; in particular any IP address dependencies should be eliminated from ISAKMP and IKE. Ubiquitous deployment of the Secure DNS Extensions () should be strongly encouraged to facilitate widespread deployment of IPsec (including IKE) without address-based Identity types.
RFC 1900 , that IETF protocols, and third-party applications, avoid any explicit awareness of IP addresses, when efficient operation of the protocol or application is feasible in the absence of such awareness. Some applications and services may continue to need to be aware of IP addresses. Until we once again have a uniform address space for the Internet, such applications and services will necessarily have limited deployability, and/or require ALG support in NATs. Also we recommend an effort in the IETF to generalize APIs to offer abstraction from all network layer dependencies, perhaps as a side- effect of the namespace study of section 3.1. sections 3.4 and 3.5.
 Carpenter, B., "Internet Transparency", RFC 2775, February 2000.  Hain, T., "Architectural Implications of NAT", Work in Progress.  Carpenter, B. and Y. Rekhter, "Renumbering Needs Work", RFC 1900, February 1996.  Ferguson, P and H. Berkowitz, "Network Renumbering Overview: Why would I want it and what is it anyway?", RFC 2071, January 1997.  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", Work in Progress.  Crawford, M., and C. Huitema, "DNS Extensions to Support IPv6 Address Aggregation and Renumbering", RFC 2874, July 2000.  Srisuresh, P., Tsirtsis, G., Akkiraju, P. and A. Heffernan, "DNS extensions to Network Address Translators (DNS_ALG)", RFC 2694, September 1999.  Eastlake, D., "Domain Name System Security Extensions", RFC 2535, March 1999.  M. Borella, D. Grabelsky, J. Lo, K. Tuniguchi "Realm Specific IP: Protocol Specification", Work in Progress.  M. Borella, J. Lo, D. Grabelsky, G. Montenegro "Realm Specific IP: Framework", Work in Progress.  G. Montenegro, M. Borella, "RSIP Support for End-to-end IPsec", Work in Progress.  M. Holdrege, P. Srisuresh, "Protocol Complications with the IP Network Address Translator", Work in Progress.  Tsirtsis, G. and P. Srisuresh, "Network Address Translation - Protocol Translation (NAT-PT)", RFC 2766, February 2000.
Full Copyright Statement Copyright (C) The Internet Society (2000). All Rights Reserved. This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English. The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns. This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. Acknowledgement Funding for the RFC Editor function is currently provided by the Internet Society.