RFC 2956
Overview of 1999 IAB Network Layer Workshop
Overview of 1999 IAB Network Layer Workshop 🌸
okay bestie, let's get into RFC 2956 📄✨. It's titled Overview of 1999 IAB Network Layer Workshop, and it came out of the Network Working Group in October 2000. M. Kaat from SURFnet ExpertiseCentrum bv wrote it, and it's in the Informational category 💖. That means it's sharing info with the Internet community, not setting a standard. The title block doesn't list anything it obsoletes or updates, so it's a standalone summary 🦋.
Here's the table of contents, unchanged 🎀:
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 . . . . . . . . . . . . . . . . . . 16Status of This Memo 💅
This memo gives info to 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 ✨
okay so this doc is an overview of a workshop the Internet Architecture Board (IAB) ran on the Internet Network Layer architecture 🧚. SURFnet hosted it in Utrecht, the Netherlands, on 7-9 July 1999. The goal was to understand where the network layer stands and how it affects the continued growth and usage of the Internet 🌸. They looked at different technical scenarios for the (foreseeable) future and at how outside influences might shake things up. This report lists the conclusions and recommendations for the Internet Engineering Task Force (IETF) community 💖.
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 called the IP layer. The workshop's goal was to talk about where the Network Layer is right now, and how the mechanisms and technologies that are already deployed, or coming later, might affect the continued growth and usage of the Internet ✨.
The biggest issues on the table were:
- Status of IPv6 deployment and transition issues
- Alternative technical strategies in case IPv6 is not adopted
- Globally unique addresses and 32 bit address depletion
- Global connectivity and reachability
- Fragmentation of the Internet
- End to end transparency and the progressive loss thereof
- End to end security
- Complications of address sharing mechanisms (NAT, RSIP)
- Separation of identification and location in addressing
- Architecture and scaling of the current routing system
The participants looked at several technical scenarios and talked about how feasible and likely each one was to actually get deployed 🍓. Some examples were a full migration to IPv6, IPv6 showing up only in certain segments of the network, no significant IPv6 deployment at all, and more segmentation of the IPv4 address space because of NAT devices 😭.
From those scenarios, the group spotted some trends and outside influences that could seriously change the network layer, like wireless network tech, mobile networked devices, and special purpose IP devices 🧚♀️.
These technical issues were marked as important goals:
- Deployment of end to end security
- Deployment of end to end transport
- Global connectivity and reachability should be maintained
- It should be easy to deploy new applications
- It should be easy to connect new hosts and networks to the Internet ("plug and ping") 🫶
By "deployment of end to end transport," they mean it's a goal to deploy new applications that span from any host to any other host without intermediaries. That requires transport protocols with that same span (see also [1]) 🌷.
This document sums up the conclusions and recommendations the workshop came up with. Not every participant agreed with every statement, and it wasn't clear whether anyone agreed with all of them. The recommendations, though, are based on strong consensus among the participants 💜.
2. Conclusions and Observations 👑
The participants reached a bunch of conclusions and observations on several of the issues from section 1. Sections 2.1-2.10 go through these one by one 💅.
2.1 Transparency 🌈
In the discussions, transparency meant the original Internet idea of a single universal logical addressing scheme, plus the mechanisms that let packets flow from source to destination essentially unaltered [1] 🦋. That traditional end to end transparency has been lost in today's 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 🍓. Examples are network address translation devices, the use of private addresses, firewalls, application level gateways, proxies, and caches. These mechanisms increase the fragmentation of the network layer, which causes problems for many applications on the Internet. It adds up to complexity in application design and holds back the deployment of new applications. It also has a severe effect on the deployment of end to end IP security 💀.
Another result of fragmentation is "split DNS," also called "two faced DNS." That means 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 probably won't be restored, because some of these mechanisms have intrinsic value (for example firewalls, caches, and proxies), and some people may consider the loss of transparency a security feature 🔥. Even so, the workshop concluded that end to end transparency is desirable and an important issue to keep pursuing. Transparency is explored further in [1] ✨.
2.2 NAT, Application Level Gateways & Firewalls 🎀
The previous section pointed out that deploying NAT (Network Address Translation), Application Level Gateways, and firewalls causes a loss of network transparency 🫶. Each one 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 communication, and "always-on" hosts. The endpoint identifiers used to set up connections, i.e. IP addresses, are globally ambiguous and not stable (see [2]) 😭.
NAT, application level gateways, and firewalls keep getting deployed more and more, because each one has advantages, real or perceived 🧚. More deployment means network transparency keeps declining, and that holds back new applications 💅. A lot of new applications will need specialized Application Level Gateways (ALGs) added to NAT devices before they'll work correctly through a NAT device. Some applications still can't work well through NAT even with an ALG 🙈.
2.3 Identification and Addressing 💖
In the original IPv4 network architecture, hosts were globally, permanently, and uniquely identified by an IPv4 address 🌸. That IP address identified the node and also located it on the network. IPv4 basically mixes up the meaning of node identity with the mechanism used to deliver packets to the node 🍓. Deploying mechanisms that split the network into multiple address spaces breaks the assumption that a host can be uniquely identified by a single IP address. On top of that, hosts may want to move to a different location in the network and still keep the same identity. Not separating a host's identity from its location causes a number of problems in the current architecture 😭.
Several technologies right now use tunneling to work around the problem, or they can't be deployed when there are separate address spaces 🌈. If a node could have some sort of unique identifier or endpoint name, that would help solve a number of these problems ✨.
The workshop concluded that, on theoretical grounds, it may be desirable to separate node identity from node locator. This is especially true for IPsec, because IP addresses are used (in transport mode) as identifiers that are cryptographically protected, so they MUST remain unchanged during transport 🔥. Still, this separation of identity and location won't be available as a near-term solution, and it will probably require changes to transport level protocols 🦋. The current IPsec specification does allow using some other identifier than an IP address, though 💜.
2.4 Observations on Address Space 🌷
There's a significant risk that a single 32 bit global address space won't be enough for foreseeable needs or desires 💀. Participants had different opinions on how long new IPv4 addresses will still be available for assignment, ranging from 2 to 20 years 👑. Still, nobody doubts that right now, users can't get as much IPv4 address space as they want. That's partly because of the current stewardship policies of the Regional Internet Registries (RIRs) 😭.
The workshop concluded that it ought to be possible for anybody to have global addresses when they need or want them 💖. Not having that holds back some types of applications. It should be noted, though, 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 big complication at those boundaries. It's often perceived as a security feature because people confuse NATs with firewalls 🙈.
to be continued in part 2 💅✨
2.5 Routing Issues 🛣️
okay so routing scaling was a HUGE topic, bestie 😭 With current tech, the number of prefixes we can use is limited by how long the routing algorithm takes to converge, not by memory size, lookup time, or anything else. Nobody knows the exact limit, but there's some speculation (of extremely unclear validity 💀) that it's on the order of a few hundred thousand prefixes. Beyond the computational load of calculating routing tables, people also care about how long it takes to spread routing updates across the network, and about how robust and secure the current routing system is. The only known addressing scheme that gives scalable routing depends on topologically aggregated addresses, which means sites have to renumber whenever their position in the global topology changes. And renumbering is still operationally difficult and expensive ([3], [4]) 😩. It's not clear whether IPv6 would fix the current routing problems, but it should do so if it makes renumbering easier ✨.
At least one backbone operator is worried about convergence time for internetwork-wide routing during a failover. This operator believes current convergence times are on the order of half a minute, and possibly getting worse 📉. Others in the routing community didn't think convergence times were a current issue. Some folks, who believe real-time applications (e.g. telephony) need sub-second convergence, are concerned about what a half-minute convergence means for those apps 📞.
Further research is needed on routing mechanisms that might help ease the current entropy in the routing tables, and that could help reduce the convergence time of routing computations 🔬.
The workshop talked about global routing in a hypothetical scenario with no distinguished root global address space. Nobody had an idea how to make that work 🫠. There's currently no well-defined proposal for a new routing system that could solve that problem.
For IPv6 routing specifically, the GSE/8+8 proposal and the IPNG WG analysis of that proposal ([5]) are still being examined by the IESG 👀. The workshop had no consensus on whether this proposal could be made deployable.
2.6 Observations on Mobility 🧳
mobility and roaming require a globally unique identifier, and it's giving main-character energy that this doesn't have to be an IP address 💜. Mobile nodes must have a widely usable identifier for their location on the network. That's a problem if private IP addresses are used or if the IP address is ambiguous (see also section 2.3). Right now, tunnels are used to route traffic to a mobile node 🚇. Another option would be to keep state information at intermediate points in the network whenever the packets get changed. But that reduces flexibility and 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 wasn't discussed in detail, because a separate IAB workshop is planned on this topic 🗓️.
2.7 DNS issues 🌐
If IPv6 gets widely deployed, the current line of thinking is that site renumbering will be way more frequent than it is today 😬. That'll affect DNS updates. It's not clear what the scale of DNS updates might be, but in the most aggressive models it could be millions a day 🤯. Deploying 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 that possible ([6]) 🎀.
Another issue is the security side of frequent updates, since they'd have to be done dynamically. Unless we have fully secured DNS, this could increase security risks 🔐. Cached TTL values might cause problems, because the cached records of renumbered hosts won't be updated in time. This gets especially bad if rapid renumbering is needed 🥲.
Another issue we already mentioned is the deployment of split DNS (see section 2.1) 🍰. It's widely used in the Intranet model, where DNS gives different info to inside and outside queries. This doesn't necessarily depend on whether private addresses are used on the inside, because firewalls and policies may also make it desirable. Split DNS seems inevitable, since Intranets will remain widely deployed. But operating a split DNS raises a lot of management and administrative issues 📋. As a workaround, a DNS Application Level Gateway ([7]) (perhaps as an extension to a NAT device) may be deployed. It intercepts DNS messages and modifies the contents to provide the appropriate answers. The downside is that it interferes with the use of DNSSEC ([8]) 🙅♀️.
The deployment of split DNS, or more generally the existence of separate name spaces, makes using Fully Qualified Domain Names (FQDNs) as endpoint identifiers more complicated 🧩.
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's meant as an alternative (or a complement) to network address translation (NAT) for IPv4, but other uses are possible too (for example, allowing end to end traffic across firewalls). It's similar to NAT in that it lets a small number of external IPv4 addresses be shared among a bunch of hosts in a local address domain (called a 'realm'). But 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 know what their temporary external address is 👁️. The addresses and other info are obtained from an RSIP server, and the packets are tunneled across the first routing realm ([9], [10]).
The difference between NAT and RSIP is a big deal 💅. An RSIP client knows it's using an IP address from another address space. With NAT, neither endpoint knows the addresses in the packets are being translated. Unlike NAT, RSIP has the potential to work with protocols that need IP addresses to stay unmodified between source and destination. For example, NAT gateways rule out using IPsec across them, while RSIP servers can allow it [11] 🔐.
Adding RSIP to NATs may let them support some applications that can't work with traditional NAT ([12]) ✨. But it does require hosts to 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 aren't well known right now, so more RSIP research is required 🔍.
Both NAT and RSIP assume the Internet keeps a core of global address space with a coherent DNS 🌍. There's no fully prepared model for NAT or RSIP without that core. So NAT and RSIP face an uncertain future whenever the IPv4 address space is finally exhausted (see section 2.4) 😰. That's why it's 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 you make optimistic assumptions about RSIP (it's still being defined, and a bunch of features haven't been implemented yet), the combo of NAT and RSIP seems to work in most cases 🤞. Whether RSIP brings specific new problems, as well as removing some of the NAT issues, still has to be figured out.
Both NAT and RSIP may struggle with the future killer application, especially if it needs QoS features, security and/or multicast 🚨. And if it needs peer to peer communication (i.e. there'd be no clear distinction between a server and a client) or assumes "always-on" systems, that 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 from IPv4 to IPv6 ([13]) 🌷. The impact of adding RSIP support to hosts isn't quite clear yet, but it's less than adding IPv6 support, since most applications probably don't need to be changed. RSIP also needs no changes to the routing infrastructure. Techniques like automatic tunneling ([14]) and 6to4 ([15]) would let IPv6 traffic ride over the existing IPv4 routing infrastructure too 🚋. RSIP is mainly a tool for extending the life of IPv4, but it's not a roadblock for the transition to IPv6 🙌. RSIP development is behind IPv6, so more study is needed to figure out what its issues might be.
2.10 Observations on IPv6 🌟
A big question at the workshop was whether deploying IPv6 is feasible and probable. The conclusion was 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, like what was done for the Y2K problem. If problems are found, they must be resolved 🔧. Since implementing IPv6 code has serious costs, good business arguments are needed to promote IPv6 💼.
Another important question was whether IPv6 could help solve the current routing system problems and make the Internet scale better. The conclusion was that "automatic" renumbering is really important when prefixes need to be changed periodically to optimize addressing topology and routing 🔄. That also means any IP layer and configuration dependencies in protocols and applications will have to be removed ([3]). One example mentioned was the use of IP addresses in the PKI (IKE) 🔑. There might also be security issues with "automatic" renumbering, since DNS records have to be updated dynamically (see also section 2.7).
Realistically, because of the dependencies mentioned, IPv6 renumbering can't be truly automatic or instantaneous. But it has the potential to be much simpler operationally than IPv4 renumbering, and that's 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. That would make things way more complex, and it's 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 isn't much experience with renumbering yet (maybe only for small sites) 🐣.
3. Recommendations 🎀
3.1 Recommendation on Namespace ✨
okay so the workshop wants the IAB to set up a panel to give the IETF specific advice on a few things 🫶
- i) whether we should get more parts of the stack to use a namespace for end to end interactions, so that a) NAT works 'better', and b) we get 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 job, or whether it makes more sense to let the various subsystems 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 more refining and studying, ngl 🧚 It doesn't break the end to end network model the way NAT does, because an RSIP host explicitly knows its temporary global address. So RSIP could actually fix some of the NAT issues 🌸 Still, it's way too early to recommend it as a mainstream direction right now 🙈
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 ✨ BUT 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. no cap, that part is the make-or-break 😭
3.3.2
Network address translation techniques are not just for pure IPv4 environments. They should also be seen as part of the starting point for migrating to IPv6 🦋 And if RSIP is successful, it can be a starting point for the IPv6 transition too 💜
The basic ideas behind the IPv4 specific mechanisms NAT and RSIP are already showing up in parts of the proposed IPv6 migration path (NAT-PT for NAT, and SIIT and AIIH for RSIP). But NAT and RSIP for IPv4 are not directly part of a documented transition path to IPv6, so it's a little bit of a plot twist 🍓
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. this is literally homework for the IETF 📚
3.3.3
The draft analysis of the 8+8/GSE proposal should be evaluated by the IESG and either accepted or rejected, without disturbing ongoing IPv6 deployment work ✨ The IESG should use broad expertise in that evaluation, including liaison with the endpoint namespace panel (see section 3.1). it's giving teamwork 🫶
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). Current IPsec specs already support several different Identity types (e.g. Domain Name, User@Domain Name), so 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. this one is serious bestie 😤
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 put a heavier burden on DNS. So it is recommended to the IETF that, except for 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 🛑
To encourage widespread deployment of IPsec, rapid deployment of DNSSEC is recommended to the operational community 🌸
3.6 Recommendations on Routing 🦋
The only known addressing scheme that produces scalable routing mechanisms depends on topologically aggregated addresses. That means sites have to renumber when their position in the global topology changes. So recommendation 3.3.1 is vital for routing IPv6 ✨
The same argument applies to IPv4, but 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 💜
Without a new addressing model to replace topological aggregation, and without 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 migrating to a new network layer of any kind, since they expose network layer internal details such as addresses 🙈
So it is 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 without such awareness. Some applications and services may still need to be aware of IP addresses. Until we have a uniform address space for the Internet again, those applications and services will necessarily have limited deployability and/or require ALG support in NATs 🥲
We also 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 🔥
This is a serious section, so I'm keeping it straight. 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. Read those two sections carefully, because security depends on them 🔐
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.
[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.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.eduAuthor'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.nlFull 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 ✨
📦 where this page comes from
- ietf: rfc2956 2000-10
- 💖 girlified by claude-haiku-5-5 on : a language model's rewrite of the original, under its terms