diff options
Diffstat (limited to 'doc/rfc/rfc2956.txt')
| -rw-r--r-- | doc/rfc/rfc2956.txt | 899 |
1 files changed, 899 insertions, 0 deletions
diff --git a/doc/rfc/rfc2956.txt b/doc/rfc/rfc2956.txt new file mode 100644 index 0000000..da8ac92 --- /dev/null +++ b/doc/rfc/rfc2956.txt @@ -0,0 +1,899 @@ + + + + + + +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. + +Abstract + + This 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. + +Table of Contents + + 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 + + + +Kaat Informational [Page 1] + +RFC 2956 1999 IAB Network Layer Workshop October 2000 + + + 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 + +1. Introduction + + From July 7 to July 9, 1999 the Internet Architecture Board (IAB) + held a workshop on the architecture of the Internet Network Layer. + 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 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 Alternative technical strategies in case IPv6 is not adopted + 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 sharing mechanisms (NAT, RSIP) + o Separation of identification and location in addressing + o Architecture and scaling of the current routing system + + 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. + + + + + + + +Kaat Informational [Page 2] + +RFC 2956 1999 IAB Network Layer Workshop October 2000 + + + 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 [1]). + + 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. + +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 + 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. + + + + + + + +Kaat Informational [Page 3] + +RFC 2956 1999 IAB Network Layer Workshop October 2000 + + + 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 Level Gateways & Firewalls + + The previous section indicated 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. NAT especially 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 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. + +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 mechanism used to deliver packets 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 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. + + + + +Kaat Informational [Page 4] + +RFC 2956 1999 IAB Network Layer Workshop October 2000 + + + 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. + +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 new IPv4 addresses will + still be available for assignment ranged from 2 to 20 years. + However, there is no doubt that at the present time, users cannot + obtain as much IPv4 address space as they desire. This is partly a + result of the current stewardship policies of the Regional Internet + Registries (RIRs). + + 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. With current technology, the number of prefixes that + can be used is limited by the time taken for the routing algorithm to + converge, rather than by memory size, lookup time, or some other + factor. The limit is unknown, but there is some speculation, of + extremely unclear validity, that it is on the order of a few hundred + thousand prefixes. Besides the computational load of calculating + routing tables, the time it takes to distribute routing updates + across the network, the robustness and security of the current + routing system are also important issues. The only known addressing + + + +Kaat Informational [Page 5] + +RFC 2956 1999 IAB Network Layer Workshop October 2000 + + + 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 ([3], [4]). + 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 ([5]) are still being examined by the IESG. + There is no consensus in the workshop whether this proposal could be + made deployable. + +2.6 Observations on Mobility + + Mobility and roaming require a globally unique identifier. This does + not have to be an IP address. Mobile nodes must have a widely usable + identifier for their location 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 a separate IAB + workshop is planned on this topic. + + + + + + +Kaat Informational [Page 6] + +RFC 2956 1999 IAB Network Layer Workshop October 2000 + + +2.7 DNS issues + + If IPv6 is widely deployed, the current line of thinking is that site + renumbering will be significantly more frequent than today. This + will have an impact on DNS updates. It is not clear what the scale + of DNS updates might be, but in the most aggressive models 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. + + 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 ([7]) (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 ([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 identifiers more complex. + +2.8 NAT and RSIP + + Realm-Specific IP (RSIP), a mechanism for use with IPv4, is a work + item of the IETF NAT WG. It is intended as an alternative (or as a + complement) to network address translation (NAT) for IPv4, but other + uses are possible (for example, allowing end to end traffic across + firewalls). It is similar to NAT, in that it allows sharing a small + number of external IPv4 addresses among a number of hosts in a local + address domain (called a 'realm'). However, it differs from NAT in + that the hosts know that different externally-visible IPv4 addresses + are being used to refer to them outside their local realm, and they + + + + + +Kaat Informational [Page 7] + +RFC 2956 1999 IAB Network Layer Workshop October 2000 + + + 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 ([9], [10]). + + 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 [11]. + + The addition of RSIP to NATs may allow them to support some + applications that cannot work with traditional NAT ([12]), 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 ([1]). + + 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). + +2.9 NAT, RSIP and IPv6 + + Assuming IPv6 is going to be widely deployed, network address + translation techniques could play an important role in the transition + process from IPv4 to IPv6 ([13]). The impact of adding RSIP support + + + +Kaat Informational [Page 8] + +RFC 2956 1999 IAB Network Layer Workshop October 2000 + + + 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 ([14]) and 6to4 ([15]) + 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. + +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 should be made, as + was done for the Y2K problem, 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). + + 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). + + + +Kaat Informational [Page 9] + +RFC 2956 1999 IAB Network Layer Workshop October 2000 + + +3. Recommendations + +3.1 Recommendation on Namespace + + The workshop recommends the IAB to appoint a panel to make specific + recommendations to the IETF about: + + i) whether we should encourage more parts of the stack to adopt a + namespace for end to end interactions, 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 refinement and + study. It does not break the end to end network model in the same + way as NAT, because an RSIP host has explicit knowledge of its + temporary global address. Therefore, RSIP could solve some of the + issues with NAT. However, it is premature to recommend it as a + mainstream direction at this time. + + It is recommended that the IETF should actively work on RSIP, develop + the details and study the issues. + +3.3 Recommendations on IPv6 + +3.3.1 + The current model of TLA-based addressing and routing should be + actively pursued. However, straightforward site renumbering using + TLA addresses is really needed, should be as nearly automatic as + possible, and should be shown to be real and credible by the IPv6 + community. + +3.3.2 + Network address translation techniques, in addition to their + immediate use in pure IPv4 environments, should also be viewed as + part of the starting point for migration to IPv6. Also RSIP, if + successful, can be a starting point for IPv6 transition. + + + + + + + +Kaat Informational [Page 10] + +RFC 2956 1999 IAB Network Layer Workshop October 2000 + + + 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. + +3.3.3 + The draft analysis of the 8+8/GSE proposal should be evaluated by the + IESG and accepted or rejected, without disturbing ongoing IPv6 + deployment work. The IESG should use broad expertise, including + liaison with the endpoint namespace panel (see section 3.1) in their + evaluation. + +3.4 Recommendations on IPsec + + It is urgent that we implement and deploy IPsec using some other + identifier than 32-bit IP addresses (see 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 ([8]) should be + strongly encouraged to facilitate widespread deployment of IPsec + (including IKE) without address-based Identity types. + +3.5 Recommendations on DNS + + Operational stability of DNS is paramount, especially during a + transition of the network layer, and both IPv6 and some network + address translation techniques place a heavier burden on DNS. It is + therefore recommended to the IETF that, except for those changes that + are already in progress and will support easier renumbering of + networks and improved security, no fundamental changes or additions + to the DNS be made for the foreseeable future. + + In order to encourage widespread deployment of IPsec, rapid + deployment of DNSSEC is recommended to the operational community. + + + + +Kaat Informational [Page 11] + +RFC 2956 1999 IAB Network Layer Workshop October 2000 + + +3.6 Recommendations on Routing + + The only known addressing scheme which produces scalable routing + mechanisms depends on topologically aggregated addresses, which + requires that sites renumber when their position in the global + topology changes. Thus recommendation 3.3.1 is vital for routing + IPv6. + + Although the same argument applies to IPv4, the installed base is + simply too large and the PIER working group showed that little can be + done to improve renumbering procedures for IPv4. However, NAT and/or + RSIP may help. + + In the absence of a new addressing model to replace topological + aggregation, and of clear and substantial demand from the user + community for a new routing architecture (i.e. path-selection + mechanism) there is no reason to start work on standards for a "next + generation" routing system in the IETF. Therefore, we recommend that + work should continue in the IRTF Routing Research Group. + +3.7 Recommendations on Application layer and APIs + + Most current APIs such as sockets are an obstacle to migration to a + new network layer of any kind, since they expose network layer + internal details such as addresses. + + It is therefore recommended, as originally recommended in RFC 1900 + [3], 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. + +4. Security Considerations + + The workshop did not address security as a separate topic, but the + role of firewalls, and the desirability of end to end deployment of + IPsec, were underlying assumptions. Specific recommendations on + security are covered in sections 3.4 and 3.5. + + + + + + +Kaat Informational [Page 12] + +RFC 2956 1999 IAB Network Layer Workshop October 2000 + + +References + + [1] Carpenter, B., "Internet Transparency", RFC 2775, February + 2000. + + [2] Hain, T., "Architectural Implications of NAT", Work in + Progress. + + [3] Carpenter, B. and Y. Rekhter, "Renumbering Needs Work", RFC + 1900, February 1996. + + [4] Ferguson, P and 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", Work in Progress. + + [6] Crawford, M., and C. Huitema, "DNS Extensions to Support IPv6 + Address Aggregation and Renumbering", RFC 2874, July 2000. + + [7] Srisuresh, P., Tsirtsis, G., Akkiraju, P. and A. Heffernan, + "DNS extensions to Network Address Translators (DNS_ALG)", RFC + 2694, September 1999. + + [8] Eastlake, D., "Domain Name System Security Extensions", RFC + 2535, March 1999. + + [9] M. Borella, D. Grabelsky, J. Lo, K. Tuniguchi "Realm Specific + IP: Protocol Specification", Work in Progress. + + [10] M. Borella, J. Lo, D. Grabelsky, G. Montenegro "Realm Specific + IP: Framework", Work in Progress. + + [11] G. Montenegro, M. Borella, "RSIP Support for End-to-end IPsec", + Work in Progress. + + [12] M. Holdrege, P. Srisuresh, "Protocol Complications with the IP + Network Address Translator", Work in Progress. + + [13] Tsirtsis, G. and P. Srisuresh, "Network Address Translation - + Protocol Translation (NAT-PT)", RFC 2766, February 2000. + + + + + + + + +Kaat Informational [Page 13] + +RFC 2956 1999 IAB Network Layer Workshop October 2000 + + + [14] Gilligan, R. and E. Nordmark, "Transition Mechanisms for IPv6 + Hosts and Routers", RFC 2893, August 2000. + + [15] B. Carpenter, K. Moore, "Connection of IPv6 Domains via IPv4 + Clouds", Work in Progress. + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Kaat Informational [Page 14] + +RFC 2956 1999 IAB Network Layer Workshop October 2000 + + +Appendix A. Participants + + Harald Alvestrand harald@alvestrand.no + Ran Atkinson rja@corp.home.net + Rob Austein sra@hactrn.net + 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@lcs.mit.edu + Matt Crawford crawdad@fnal.gov + Robert Elz kre@munnari.OZ.AU + Tony Hain tonyhain@microsoft.com + Matt Holdrege matt@ipverse.com + Erik Huizer huizer@cs.utwente.nl + Geoff Huston gih@telstra.net + Van Jacobson van@cisco.com + Marijke Kaat Marijke.Kaat@surfnet.nl + Daniel Karrenberg Daniel.Karrenberg@ripe.net + John Klensin klensin@jck.com + Peter Lothberg roll@Stupi.SE + Olivier H. Martin Olivier.Martin@cern.ch + Gabriel Montenegro gab@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@alum.mit.edu + 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 + EMail: Marijke.Kaat@surfnet.nl + + + + + + +Kaat Informational [Page 15] + +RFC 2956 1999 IAB Network Layer Workshop October 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. + + + + + + + + + + + + + + + + + + + +Kaat Informational [Page 16] + |