RFC 1752
The Recommendation for the IP Next Generation Protocol
Network Working Group, S. Bradner, Harvard University, A. Mankin, ISI. Request for Comments: 1752. Category: Standards Track. Dated January 1995. Okay bestie, this is the RFC that picks the successor to IPv4, so grab your 🧋 because we're about to get into it 💅✨
The Recommendation for the IP Next Generation Protocol 🎀
Status of this Memo 🌸
This document specifies an Internet standards track protocol for the Internet community, and requests discussion and suggestions for improvements. Please refer to the current edition of the "Internet Official Protocol Standards" (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited.
Abstract 🦋
This document presents the recommendation of the IPng Area Directors on what should be used to replace the current version of the Internet Protocol. This recommendation was accepted by the Internet Engineering Steering Group (IESG).
Table of Contents 📋
1. Summary. . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Background . . . . . . . . . . . . . . . . . . . . . . . 4
3. A Direction for IPng . . . . . . . . . . . . . . . . . . 5
4. IPng Area. . . . . . . . . . . . . . . . . . . . . . . . 6
5. ALE Working Group. . . . . . . . . . . . . . . . . . . . 6
5.1 ALE Projections. . . . . . . . . . . . . . . . . . . . . 7
5.2 Routing Table Size . . . . . . . . . . . . . . . . . . . 7
5.3 Address Assignment Policy Recommendations. . . . . . . . 8
6. IPng Technical Requirements. . . . . . . . . . . . . . . 8
6.1 The IPng Technical Criteria document . . . . . . . . . . 9
7. IPng Proposals . . . . . . . . . . . . . . . . . . . . . 11
7.1 CATNIP. . . . . . . . . . . . . . . . . . . . . . . . . 11
7.2 SIPP. . . . . . . . . . . . . . . . . . . . . . . . . . 12
7.3 TUBA. . . . . . . . . . . . . . . . . . . . . . . . . . 13
8. IPng Proposal Reviews. . . . . . . . . . . . . . . . . . 13
8.1 CATNIP Reviews . . . . . . . . . . . . . . . . . . . . . 14
8.2 SIPP Reviews . . . . . . . . . . . . . . . . . . . . . . 15
8.3 TUBA Reviews . . . . . . . . . . . . . . . . . . . . . . 16
8.4 Summary of Proposal Reviews. . . . . . . . . . . . . . . 17
9. A Revised Proposal . . . . . . . . . . . . . . . . . . . 17
10 Assumptions . . . . . . . . . . . . . . . . . . . . . . 18
10.1 Criteria Document and Timing of Recommendation . . . . . 18
10.2 Address Length . . . . . . . . . . . . . . . . . . . . . 19
11. IPng Recommendation. . . . . . . . . . . . . . . . . . . 19
11.1 IPng Criteria Document and IPng. . . . . . . . . . . . . 20
11.2 IPv6. . . . . . . . . . . . . . . . . . . . . . . . . . 21
12. IPv6 Overview . . . . . . . . . . . . . . . . . . . . . 21
12.1 IPv6 Header Format . . . . . . . . . . . . . . . . . . . 24
12.2 Extension Headers. . . . . . . . . . . . . . . . . . . . 25
12.2.1 Hop-by-Hop Option Header . . . . . . . . . . . . . . . . 25
12.2.2 IPv6 Header Options. . . . . . . . . . . . . . . . . . . 26
12.2.3 Routing Header . . . . . . . . . . . . . . . . . . . . . 27
12.2.4 Fragment Header. . . . . . . . . . . . . . . . . . . . . 28
12.2.5 Authentication Header. . . . . . . . . . . . . . . . . . 29
12.2.6 Privacy Header . . . . . . . . . . . . . . . . . . . . . 30
12.2.7 End-to-End Option Header . . . . . . . . . . . . . . . . 32
13. IPng Working Group . . . . . . . . . . . . . . . . . . . 32
14. IPng Reviewer . . . . . . . . . . . . . . . . . . . . . 33
15. Address Autoconfiguration. . . . . . . . . . . . . . . . 33
16. Transition . . . . . . . . . . . . . . . . . . . . . . . 34
16.1 Transition - Short Term. . . . . . . . . . . . . . . . . 35
16.2 Transition - Long Term . . . . . . . . . . . . . . . . . 36
17. Other Address Families . . . . . . . . . . . . . . . . . 37
18. Impact on Other IETF Standards . . . . . . . . . . . . . 38
19. Impact on non-IETF standards and on products . . . . . . 39
20. APIs . . . . . . . . . . . . . . . . . . . . . . . . . . 39
21. Future of the IPng Area and Working Groups . . . . . . . 40
22. Security Considerations. . . . . . . . . . . . . . . . . 40
23. Authors' Addresses . . . . . . . . . . . . . . . . . . . 43
Appendix A Summary of Recommendations . . . . . . . . . . . . . 44
Appendix B IPng Area Directorate. . . . . . . . . . . . . . . . 45
Appendix C Documents Referred to the IPng Working Groups. . . . 46
Appendix D IPng Proposal Overviews. . . . . . . . . . . . . . . 46
Appendix E RFC 1550 White Papers. . . . . . . . . . . . . . . . 47
Appendix F Additional References. . . . . . . . . . . . . . . . 48
Appendix G Acknowledgments. . . . . . . . . . . . . . . . . . . 521. Summary ✨
1.1. Hmm, lol, we don't have one yet
Part 1 ends here. The rest of the RFC is coming in the next parts, so stay tuned, bestie 🫶
3. A Direction for IPng ✨
okay so in September 1993 Phill Gross, who chaired the IESG, put out "A Direction for IPng" 💅 [Gross94]. He was basically summing up what came out of the ipdecide BOF and an open IESG plenary in Amsterdam 🌸. Here's the vibe he set:
- The IETF needs to move toward closure on IPng.
- The IESG has the responsibility for developing an IPng recommendation for the Internet community.
- The procedures of the recommendation-making process should be open and published well in advance by the IESG.
- As part of this process, the IPng WGs may be given new milestones and other guidance to aid the IESG.
- There should be ample opportunity for community comment prior to final IESG recommendation.
The memo also announced "a temporary, ad hoc, 'area' to deal specifically with IPng issues." 🎀 Phill asked two of the current IESG members, Allison Mankin (Transport Services Area) and Scott Bradner (Operational Requirements Area), to act as Directors for the new area 👑. The Area Directors got a specific charge on how to look into the different IPng proposals and how to base their recommendation to the IETF. They were also asked to make a specific recommendation 🧚.
- Establish an IPng directorate.
- Ensure that a completely open process is followed.
- Develop an understanding of the level of urgency and the time constraints imposed by the rate of address assignment and rate of growth in the routing tables.
- Recommend the adoption of assignment policy changes if warranted.
- Define the scope of the IPng effort based on the understanding of the time constraints.
- Develop a clear and concise set of technical requirements and decision criteria for IPng.
- Develop a recommendation about which of the current IPng candidates to accept, if any.
4. IPng Area 🦋
after the IPng Area got formed, they recruited a directorate (see Appendix B) 💖. The members were picked for both their general and their specific technical expertise. Each person was then asked to get their management to approve their participation in the process, and to confirm that they understood how the IETF process works 🫶.
they were super intentional about including a wide spectrum of knowledge 🌈. The directors are experts in security, routing, the needs of large users, end system manufacturers, Unix and non-Unix platforms, router manufacturers, theoretical researchers, protocol architecture, and the operating regional, national, and international networks. On top of that, several directorate members were deeply involved in each of the IPng proposal working groups 🔥.
the directorate works as the direction-setting and preliminary review body that the area's charge asked for ✨. It has biweekly conference calls, an internal mailing list, and it's super active on the Big-Internet mailing list 💜. The directorate held open meetings at the March 1994 Seattle and July 1994 Toronto IETF meetings, plus two additional multi-day retreats 🍓. To keep the IPng process as open as possible, they took minutes at these meetings and published them. They also put the archives of the internal IPng mailing list on an anonymous ftp site: Hsdndev.harvard.edu: pub/ipng. 💅
5. ALE Working Group 🌸
they needed a reasonable estimate of how much time was left before the IPv4 address space ran out, so they could figure out how big the IPng effort should be 🙈. If the remaining time was about the same as what it would take to deploy a replacement, then they'd have to select an IPng that only fixed the address limitations, because there wouldn't be enough time to develop any other features. If more time seemed available, they could consider additional improvements 👑.
the IETF formed an Address Lifetime Expectations (ALE) Working Group in 1993, "to develop an estimate for the remaining lifetime of the IPv4 address space based on currently known and available technologies." [Solens93a] Tony Li of Cisco Systems and Frank Solensky of FTP Software are the co-chairs 🦋. The IETF also asked the working group to consider whether developing more stringent address allocation and utilization policies might buy more time for the transition 💅.
5.1 ALE Projections
the ALE Working Group met at the November 1993 Houston, [Solens93b] March 1994 Seattle [Bos93] and July 1994 Toronto [Solens94] IETF meetings ✨. At the Seattle meeting they projected, and then confirmed at the Toronto meeting, that using the current allocation statistics the Internet would exhaust the IPv4 address space between 2005 and 2011 😭.
some members of the ipv4-ale and big-internet mailing lists questioned how reliable this projection was 🙈. It's been criticized as both too optimistic and too pessimistic 💀.
some people pointed out that this type of projection assumes no paradigm shifts in IP usage 🔥. If someone were to develop a new 'killer application', (for example cable-TV set top boxes.) the resulting rise in demand for IP addresses could make this an over-estimate of the time available 🌈.
there might also be a problem with the data behind the projection 🎀. The InterNIC hands out IP addresses in large chunks to regional Network Information Centers (NICs) and network providers. The NICs and providers then re-allocate addresses to their customers. The ALE projections used the InterNIC assignments without looking at the actual rate of address assignment to end users, because the accuracy of that data seems quite a bit higher 🧚. Using this once-removed data may add a level of over-estimation, since it assumes the rate of large block allocation will continue, and that might not be the case 💜.
these factors make the ALE estimates less reliable, but overall they seem to show enough time left in the IPv4 address space to consider adding features in an IPng besides just expanding the address size 🫶. That still holds even when you account for the time needed for development, testing, and deployment ⭐.
5.2 Routing Table Size
another big scaling issue is the growing size of the routing tables that backbone routers need 🍓. Adopting CIDR block address assignment and aggregating routes shrank the tables for a while, but now they're expanding again 😭. Providers now need to advertise their routes more aggressively, and only in aggregates. Providers must also advise their new customers to renumber their networks in the best interest of the entire Internet community 💅.
exhausting the IPv4 address space may be moot if this issue gets ignored and no routers can be found that keep up with table size growth 💀. Before CIDR was implemented, the backbone routing table was growing at a rate about 1.5 times as fast as memory technology 🔥.
we should also note that even though IPng addresses are designed with aggregation in mind, switching to IPng won't solve the routing table size problem unless the addresses are assigned rigorously to maximize the effect of that aggregation 🙈. This efficient route advertising can be maintained because IPng includes address autoconfiguration mechanisms, which allow easy renumbering if a customer decides to switch providers 🦋. Customers who receive service from more than one provider may limit how efficient any route aggregation can be 🌸. [Rekhter94]
5.3 Address Assignment Policy Recommendations
the IESG Chair charged the IPng Area with considering more stringent assignment policies, reclaiming some addresses that were already assigned, or making a serious effort to renumber significant portions of the Internet 👑. [Gross94]
the IPng Area Directors endorse the current address assignment policies in view of the ALE projections 💖. We don't feel anyone should take specific efforts to reclaim underutilized addresses that are already assigned, or to forcefully renumber major portions of the Internet 🙅. We do feel, however, that we should all encourage network service providers to help new customers renumber their networks to conform to the provider's CIDR assignments 🫶.
the ALE Working Group recommends that we consider assigning CIDR-type address blocks out of the unassigned Class A address space ✨. The IPng Area Directors concur with this recommendation 🎀.
6. IPng Technical Requirements 💜
the IESG outlined the kinds of criteria we should use to judge whether an IPng proposal is suitable, in RFC 1380 [Gross92] 🧚. The IETF refined that understanding further with the recommendations from a Selection Criteria BOF held at the November 1992 IETF meeting in Washington D.C. [Almqu92] We felt we needed more input to pin down the requirements, so we issued a call for white papers [Bradner93] 🌈. That call went out as RFC 1550, and it was meant to reach both inside and outside the traditional IETF crowd, so we'd get the broadest possible understanding of the requirements for a data networking protocol with the broadest possible application 🦋.
we received twenty one white papers in response to the RFC 1550 solicitation (see Appendix E) 🎀. We heard from industries that many people feel will be the major providers of data networking services in the future: the cable TV industry [Vecchi94], the cellular industry [Taylor94], and the electric power industry [Skelton94] ⚡. We also got papers covering military applications [Adam94, Syming94, Green94], ATM [Brazd94], mobility [Simpson94], accounting [Brown94], routing [Estrin94a, Chiappa94], security [Adam94, Bell94b, Brit94, Green94, Vecchi94, Flei94], large corporate networking [Britt94, Fleisch94], transition [Carpen94a, Heager94], market acceptance [Curran94, Britt94], host implementations [Bound94], plus a number of other issues [Bello94a, Clark94, Ghisel94] 🔥.
these white papers, a Next Generation Requirements (ngreq) BOF (chaired by Jon Crowcroft and Frank Kastenholz) held at the March 1994 Seattle IETF meeting, discussions within the IPng Area Directorate, and a lot of discussion on the big-internet mailing list were all used by Frank Kastenholz and Craig Partridge to revise their earlier criteria draft [Kasten92] into "Technical Criteria for Choosing IP The Next Generation (IPng)." [Kasten94] 💅 This document is the "clear and concise set of technical requirements and decision criteria for IPng" that the IESG Chair asked for in the charge 👑. We used it as the basic guideline while evaluating the IPng proposals ✨.
6.1 The IPng Technical Criteria document 📋
okay so the IPng folks wrote down a whole list of criteria (borrowed from Kasten94) that any proposal had to hit. it's giving checklist energy 💅
- complete specification - the proposal must fully describe the proposed protocol 📜 we have to pick an IPng by pointing at specific documents, not future work 🙅♀️
- architectural simplicity - the IP-layer protocol should be as simple as possible, and the jobs better suited to other protocol layers should be handled there 🧩
- scale - the IPng Protocol must allow identifying and addressing at least
10**9leaf-networks (and preferably much more) 🌍 - topological flexibility - the routing architecture and protocols of IPng must allow for many different network topologies 🕸️ they must not assume that the network's physical structure is a tree 🌳❌
- performance - a state of the art, commercial grade router must be able to process and forward IPng traffic at speeds capable of fully utilizing common, commercially available, high-speed media at the time 🏎️💨
- robust service - the network service and its associated routing and control protocols must be robust 🛡️
- transition - the protocol must have a straightforward transition plan from IPv4 🦋
- media independence - the protocol must work across an internetwork of many different LAN, MAN, and WAN media, with individual link speeds ranging from ones-of-bits per second to hundreds of gigabits per second 🌈
- datagram service - the protocol must support an unreliable datagram delivery service 📨
- configuration ease - the protocol must permit easy and largely distributed configuration and operation 🥰 automatic configuration of hosts and routers is required ⚙️
- security - IPng must provide a secure network layer 🔐 no notes 🫶
- unique names - IPng must assign unique names to all IP-Layer objects in the global, ubiquitous, Internet 🏷️ these names may or may not have any location, topology, or routing significance 🤷♀️
- access to standards - the protocols that define IPng and its associated protocols should be as freely available and redistributable as the IPv4 and related RFCs 📖 there must be no specification-related licensing fees for implementing or selling IPng software 💸🚫
- multicast support - the protocol must support both unicast and multicast packet transmission 📣 dynamic and automatic routing of multicasts is also required 🙌
- extensibility - the protocol must be extensible, meaning it must be able to evolve to meet the future service needs of the Internet 🌱 this evolution must be achievable without requiring network-wide software upgrades 🙅♀️💻
- service classes - the protocol must allow network devices to associate packets with particular service classes and provide them with the services specified by those classes 🎟️
- mobility - the protocol must support mobile hosts, networks and internetworks 🚗💨
- control protocol - the protocol must include elementary support for testing and debugging networks (e.g., ping and traceroute) 🔍
- tunneling support - IPng must allow users to build private internetworks on top of the basic Internet Infrastructure 🚇 both private IP-based internetworks and private non-IP-based (e.g., CLNP or AppleTalk) internetworks must be supported 💜
7. IPng Proposals ✨
okay so by the time the IPng Area showed up, the IETF had already put a ton of effort into fixing the addressing and routing problems of the Internet 🧠 a bunch of proposals were floating around, and some of them even got their own working groups. a lot of those groups later merged into bigger groups with more consensus 🤝 all of these efforts had different takes on the problems and tried to optimize different parts of the solution 🎀
by February 1992 the Internet community had developed four separate proposals for IPng [Gross92], "CNAT" [Callon92a], "IP Encaps" [Hinden92a], "Nimrod" [Chiappa91], and "Simple CLNP" [Callon92b]. by December 1992 three more showed up: "The P Internet Protocol" (PIP) [Tsuchiya92], "The Simple Internet Protocol" (SIP) [Deering92] and "TP/IX" [Ullmann93]. after the March 1992 San Diego IETF meeting, "Simple CLNP" evolved into "TCP and UDP with Bigger Addresses" (TUBA) [Callon92c], and "IP Encaps" evolved into "IP Address Encapsulation" (IPAE) [Hinden92b] 🌸
by November 1993, IPAE merged with SIP but kept the name SIP 🫶 then this group merged with PIP, and the resulting working group called themselves "Simple Internet Protocol Plus" (SIPP) 👑 at the same time, the TP/IX Working Group changed its name to "Common Architecture for the Internet" (CATNIP) 🦋
none of these proposals were wrong, and none of the others were right 🙅♀️ every single one of them would work in some ways, and each one offered a path past the obstacles we face as the Internet grows 🌈 the job of the IPng Area was to make sure the IETF understood the proposals, learned from them, and gave a recommendation on which path best solves the basic issues while setting up the best foundation for the future 💖
the IPng Area evaluated three IPng proposals, as they were described in their RFC 1550 white papers: CATNIP [McGovern94], SIPP [Hinden94a] and TUBA [Ford94a]. the IESG saw Nimrod as too much of a research project to be an IPng candidate 🔬 since Nimrod represents one possible future Internet routing strategy, we asked for a paper describing any requirements Nimrod would put on an IPng, to add to the requirements process [Chiappa94] 📝
7.1 CATNIP
okay CATNIP is the convergence protocol 💫 here's how it's described:
"Common Architecture for the Internet (CATNIP) was conceived as a convergence protocol. CATNIP integrates CLNP, IP, and IPX. The CATNIP design provides for any of the transport layer protocols in use, for example TP4, CLTP, TCP, UDP, IPX and SPX, to run over any of the network layer protocol formats: CLNP, IP (version 4), IPX, and CATNIP. With some attention paid to details, it is possible for a transport layer protocol (such as TCP) to operate properly with one end system using one network layer (e.g., IP version 4) and the other using some other network protocol, such as CLNP." [McGovern94]
"The objective is to provide common ground between the Internet, OSI, and the Novell protocols, as well as to advance the Internet technology to the scale and performance of the next generation of internetwork technology."
"CATNIP supports OSI Network Service Access Point (NSAP) format addresses. It also uses cache handles to provide both rapid identification of the next hop in high performance routing as well as abbreviation of the network header by permitting the addresses to be omitted when a valid cache handle is available. The fixed part of the network layer header carries the cache handles." [Sukonnik94]
7.2 SIPP
and now SIPP 💜 this is how they described it:
"Simple Internet Protocol Plus (SIPP) is a new version of IP which is designed to be an evolutionary step from IPv4. It is a natural increment to IPv4. It was not a design goal to take a radical step away from IPv4. Functions which work in IPv4 were kept in SIPP. Functions which didn't work were removed. It can be installed as a normal software upgrade in internet devices and is interoperable with the current IPv4. Its deployment strategy was designed to not have any 'flag' days. SIPP is designed to run well on high performance networks (e.g., ATM) and at the same time is still efficient for low bandwidth networks (e.g., wireless). In addition, it provides a platform for new internet functionality that will be required in the near future." [Hinden94b]
"SIPP increases the IP address size from 32 bits to 64 bits, to support more levels of addressing hierarchy and a much greater number of addressable nodes. SIPP addressing can be further extended, in units of 64 bits, by a facility equivalent to IPv4's Loose Source and Record Route option, in combination with a new address type called 'cluster addresses' which identify topological regions rather than individual nodes."
"SIPP changes in the way IP header options are encoded allows for more efficient forwarding, less stringent limits on the length of options, and greater flexibility for introducing new options in the future. A new capability is added to enable the labeling of packets belonging to particular traffic 'flows' for which the sender requests special handling, such as non-default quality of service or 'real-time' service." [Hinden94a]
7.3 TUBA
last but not least, TUBA 🎀 here's the description:
"The TCP/UDP Over CLNP-Addressed Networks (TUBA) proposal seeks to minimize the risk associated with migration to a new IP address space. In addition, this proposal is motivated by the requirement to allow the Internet to scale, which implies use of Internet applications in a very large ubiquitous worldwide Internet. It is therefore proposed that existing Internet transport and application protocols continue to operate unchanged, except for the replacement of 32-bit IP addresses with larger addresses. TUBA does not mean having to move over to OSI completely. It would mean only replacing IP with CLNP. TCP, UDP, and the traditional TCP/IP applications would run on top of CLNP." [Callon92c]
"The TUBA effort will expand the ability to route Internet packets by using addresses which support more hierarchy than the current Internet Protocol (IP) address space. TUBA specifies the continued use of Internet transport protocols, in particular TCP and UDP, but specifies their encapsulation in ISO 8473 (CLNP) packets. This will allow the continued use of Internet application protocols such as FTP, SMTP, TELNET, etc. TUBA seeks to upgrade the current system by a transition from the use of IPv4 to ISO/IEC 8473 (CLNP) and the corresponding large Network Service Access Point (NSAP) address space." [Knopper94]
"The TUBA proposal makes use of a simple long-term migration proposal based on a gradual update of Internet Hosts (to run Internet applications over CLNP) and DNS servers (to return larger addresses). This proposal requires routers to be updated to support forwarding of CLNP (in addition to IP). However, this proposal does not require encapsulation nor translation of packets nor address mapping. IP addresses and NSAP addresses may be assigned and used independently during the migration period. Routing and forwarding of IP and CLNP packets may be done independently." ([Callon92c]
8. IPng Proposal Reviews ✨
okay so the IPng Directorate was reviewing all the candidate proposals 🧐 they hashed it out on their biweekly teleconferences and on their mailing list 📬 meanwhile the Big-Internet mailing list was going off too, especially once the Area Directors dropped some super specific questions to get everyone talking [Big] 💬
the directorate members were each asked to evaluate the proposals ahead of a two day retreat near Chicago on May 19th and 20th 1994 🌆 the retreat kicked off with a roundtable where everyone aired their views: the Area Directors, the Directorate, and a bunch of guests the working group chairs had invited for each proposal [Knopper94b] 🎀 we're gonna publish these reviews plus a more detailed compendium review of each proposal as companion memos 📝
here's the summary table of the three proposals against the requirements in the IPng Criteria document 📊 just so you know, these don't necessarily reflect the views of the Area Directors 🙈 the key:
Yesmeans the reviewers mainly felt the proposal met the criterion ✅Nomeans the reviewers mainly felt it did not 🚫Mixedmeans the reviewers had mixed reviews with none dominating 🌀Unknownmeans the reviewers mainly felt the documentation didn't address the criterion 🤷♀️
CATNIP SIPP TUBA
------ ---- ----
complete spec no yes mostly
simplicity no no no
scale yes yes yes
topological flex yes yes yes
performance mixed mixed mixed
robust service mixed mixed yes
transition mixed no mixed
media indepdnt yes yes yes
datagram yes yes yes
config. ease unknown mixed mixed
security unknown mixed mixed
unique names mixed mixed mixed
access to stds yes yes mixed
multicast unknown yes mixed
extensibility unknown mixed mixed
service classes unknown yes mixed
mobility unknown mixed mixed
control proto unknown yes mixed
tunneling unknown yes mixed8.1 CATNIP Reviews 🌷
all the reviewers felt CATNIP isn't completely specified 😬 BUT, and this is a big but, a bunch of reviewers thought its ideas were super innovative and that CATNIP showed the best vision of all the proposals 💜 the use of Network Service Attachment Point Addresses (NSAPs) is really well thought out, and the routing handles are seriously creative 🦋
the goal of uniting three major protocol families, IP, ISO-CLNP and Novell IPX, is honestly so admirable 👑 but the consensus was that the developers hadn't come up with detailed enough plans to actually pull that off 🥺
the plans they did describe suffer from the complexity of trying to be a union of a bunch of existing network protocols 🌀 some reviewers felt CATNIP is basically just mapping IPv4, IPX, and SIPP addresses into NSAPs, and so it doesn't really tackle the routing problems of the current and future Internet 💀
on top of that, the reviewers felt CATNIP has poor support for multicasting and mobility, and it doesn't specifically deal with important stuff like security and autoconfiguration 😭
8.2 SIPP Reviews 💅
most of the reviewers, including the ones who were already into other proposals, felt (as one reviewer put it) that SIPP is an "aesthetically beautiful protocol well tailored to compactly satisfy today's known network requirements." 🫶✨ the SIPP Working Group was the most dynamic over the last year, and they produced a myriad of documentation covering almost every aspect needed for a complete protocol description 📚🔥
the biggest problem the reviewers had with SIPP was IPAE, SIPP's transition plan 😩 the overwhelming feeling was that IPAE is fatally flawed and could not be made to work reliably in an operational Internet 💔
there was significant disagreement about whether the SIPP 64 bit address size is adequate 🤔 sure, you can enumerate 10**15 end nodes in 64 bits, but people have different views on how much inefficiency real-world routing plans introduce [Huitema94] 🙃 the majority felt that 64 bit addresses don't leave enough room for the hierarchy the future Internet needs 📉 and since nobody has any experience with extended addressing and routing concepts of the type SIPP proposes, the reviewers were generally pretty uncomfortable with that methodology 😬 they also felt the design introduces some significant security issues 🚨
a number of reviewers felt SIPP didn't address the routing issue in any useful way 🗺️ in particular, nobody has seriously tried to come up with ways to abstract topology information or to aggregate information about areas of the network 🫠
finally, most of the reviewers questioned the level of complexity in the SIPP autoconfiguration plans, and in SIPP in general, apart from the header itself 🧩
8.3 TUBA Reviews 🦋
the reviewers generally felt the most important thing TUBA has going for it is that it's based on CLNP, and there's significant deployment of CLNP-capable routers throughout the Internet 🌐 there was way less agreement that there's significant deployment of CLNP-capable hosts or actual networks running CLNP 🤷♀️ another big plus for TUBA is the potential for convergence of ISO and IETF networking standards 🫶 a number of reviewers pointed out that if TUBA were based on a changed CLNP, the advantage of an existing deployed infrastructure would be lost and the convergence potential would be reduced 😭
a number of aspects of CLNP were felt to be a problem by the reviewers, including the inefficiencies from the lack of any particular word alignment of the header fields, CLNP source route, the lack of a flow ID field, the lack of a protocol ID field, and the use of CLNP error messages in TUBA 🙈 the CLNP packet format or procedures would have to be modified to resolve at least some of these issues 🛠️
there seems to be a profound disagreement within the TUBA community about whether the IETF can modify the CLNP standards 🥊 in the Houston presentation, the TUBA folks said they felt "clone and run" was a legitimate process 🍓 that's also what the IAB proposed in "IP version 7" [IAB92] 📜 but the TUBA community hasn't reached consensus that this view is reasonable 🫣 lots of people, including a number of the CLNP document authors, are adamant that this isn't an issue and the IETF can make modifications to the base standards 💪 but many others are just as adamant that the standards can only be changed through the ISO standards process 🙅♀️ and since the overwhelming feeling within the IETF is that the IETF must 'own' the standards its future is built on, this disagreement within the TUBA community was pretty disquieting 😟
for a number of reasons, including prejudice in a few cases (ugh 😤), the reviews of the TUBA proposals were much more mixed than for SIPP or CATNIP 🌀 clearly TUBA meets the requirements for scaling to large numbers of hosts, supports flexible topologies, is media independent, and is a datagram protocol ✅ it was less clear to the reviewers that TUBA met the other IPng requirements, and those views varied widely 🤔
there was also disagreement over whether it's wise to use NSAPs for routing, given the wide variety of NSAP allocation plans 🗂️ the Internet would have to restrict NSAP use to those allocated with the actual underlying network topology in mind, if the required degree of aggregation of routing information is going to be achieved 🧠
8.4 Summary of Proposal Reviews 📋
the tea: significant problems were seen in all three proposals ☕ to one degree or another, both SIPP and TUBA would work in the Internet context, but each had its own problems 🌸 some of these would have to be fixed before either one could be ready to replace IPv4, let alone carry the Internet into the future 🚀 other problems could be dealt with over time ⏳ CATNIP was felt to be too incomplete to be considered 💀
9. A Revised Proposal 🎀
like I said above, there was a lot of talk about the strengths and weaknesses of the various IPng proposals during the IPng 'BigTen' retreat on May 19th and 20th 1994 [Knopper94b] 🫶 after the retreat, Steve Deering and Paul Francis (two of the co-chairs of the SIPP Working Group) sent a message to the sipp mailing list recapping the retreat discussions and proposing some changes to SIPP [Deering94a] 📨
the message noted "The recurring (and unsurprising) concerns about SIPP were:
(1) complexity/manageability/feasibility of IPAE, and
(2) adequacy/correctness/limitations of SIPP's addressing and routing model, especially the use of loose source routing to accomplish 'extended addressing'".
they "proposed to address these concerns by changing SIPP as follows:
- Change address size from 8 bytes to 16 bytes (fixed-length).
- Specify optional use of serverless autoconfiguration of the 16-byte address by using IEEE 802 address as the low-order ("node ID") part.
- For higher-layer protocols that use internet-layer addresses as part of connection identifiers (e.g., TCP), require that they use the entire 16-byte addresses.
- Do not use Route Header for extended addressing."
after a lot of discussion on the sipp and big-internet mailing lists about these proposed changes, the SIPP working group published a revised version of SIPP [Deering94b] 🎉, a new addressing architecture [Francis94] 🏗️, and a simplified transition mechanism [Gillig94a] ✨ these were submitted to the IPng Directorate for their consideration 📬
this proposal is a synthesis of multiple IETF efforts 🧶 most of the basic protocol comes from the SIPP effort, the autoconfiguration and transition portions were influenced by TUBA, the addressing structure is based on the CIDR work, and the routing header evolved out of the SDRP deliberations 🌈
10. Assumptions 🧚
10.1 Criteria Document and Timing of Recommendation 🎀
okay so before we get to the recs, we're making two big assumptions about what the community agrees on 💅 first, that the IPng criteria document is the reasonable set of requirements for an IPng, and second, that a specific recommendation should be made now and that from this point on the IETF should proceed with a single IPng effort 🫶
as we said above, the IPng Technical Criteria document [Kasten94] was developed in an open manner and got a ton of discussion on a bunch of mailing lists 📬 we think there's a strong consensus that this document accurately reflects the community's technical requirements that an IPng should be able to meet ✨
a main topic on the big-internet mailing list this spring, plus the open IPng directorate meeting in Seattle, was whether we needed to make a specific IPng recommendation right now 👀 some people felt more research would help resolve some of the issues that are still open 🔬 others said picking a single protocol to work on would clarify the picture for the community, focus the IETF's resources on finalizing its details, and, since "there are open research items" could be said at any point in history, there might never be a 'right' time 🥲 the way that argument goes, it's giving never-ending loop 💀
our read of the community is that there's a consensus that a specific recommendation should be made now 💖 this lines up with the views shared during the ipdecide BOF in Amsterdam [Gross94] and in some of the RFC 1550 white papers [Carpen94a] 🌸
there's no particular reason to think the basic recommendation would be significantly different if we waited another six months or a year 🕰️ sure, some unresolved details could get filled in if we delayed, but the current fragmentation of the IETF's energies limits how efficient that detail resolution is 🙈 concentrating the IETF's resources behind a single effort seems to us like the more efficient way to go 🔥
10.2 Address Length 🦋
okay, address size and format were one of the most hotly debated parts of the whole IPng design thing 😭 during the process, four distinct views came out of it:
- the view that 8 bytes of address are enough to meet the current and future needs of the Internet (squaring the size of the IP address space) 🧁 more would waste bandwidth, promote inefficient assignment, and cause problems in some networks (such as mobiles and other low speed links) 📱
- the view that 16 bytes is about right 🌈 that length supports easy auto-configuration as well as organizations with complex internal routing topologies in conjunction with the global routing topology now and well into the future 🧚
- the view that 20 byte OSI NSAPs should be used in the interests of global harmonization 🌍
- the view that variable length addresses, which might be smaller or larger than 16 bytes, should be used to embrace all the above options and more 💜 that way the address size could be adjusted to the demands of a particular environment, and the ability to meet any future networking requirements is ensured 👑
good technical and engineering arguments were made for and against all of these views 🫠 unanimity wasn't achieved, but we feel a clear majority view emerged that 16 byte fixed length addresses were the best compromise between efficiency, functionality, flexibility, and global applicability [Mankin94] ✨ honestly the tea was served 🍵
11. IPng Recommendation 👑
after a great deal of discussion in many forums and with the consensus of the IPng Directorate, we recommend that the protocol described in "Simple Internet Protocol Plus (SIPP) Spec. (128 bit ver)" [Deering94b] be adopted as the basis for IPng, the next generation of the Internet Protocol 🚀 we also recommend that the other documents listed in Appendix C be adopted as the basis of specific features of this protocol 📚
this proposal resolves most of the perceived problems, especially in the areas of addressing, routing, transition and address autoconfiguration 🎀 it includes the broad base of the SIPP proposal effort, flexible address autoconfiguration features, and a merged transition strategy 🫶 we believe it meets the requirements outlined in the IPng Criteria document and provides the framework to fully meet the needs of the greater Internet community for the foreseeable future 🔮
11.1 IPng Criteria Document and IPng 📝
a detailed review of how IPng meets the requirements set down in the IPng Criteria document [Kasten94] will soon be published 👀 here's our honest feelings about how responsive IPng is to each criterion 💅
- complete specification 📖 the base specifications for IPng are complete, but transition and address autoconfiguration do remain to be finalized
- architectural simplicity 🧠 the protocol is simple, easy to explain, and uses well established paradigms
- scale 📈 an address size of 128 bits easily meets the need to address 10**9 networks, even in the face of the inherent inefficiency of address allocation for efficient routing
- topological flexibility 🌐 the IPng design places no constraints on network topology except for the limit of 255 hops
- performance 🏎️ the simplicity of processing, the alignment of the fields in the headers, and the elimination of the header checksum will allow for high performance handling of IPng data streams
- robust service 🛡️ IPng includes no inhibitors to robust service, and the addition of packet-level authentication allows the securing of control and routing protocols without having to have separate procedures
- transition 🔄 the IPng transition plan is simple and realistically covers the transition methods that will be present in the marketplace
- media independence 🦋 IPng retains IPv4's media independence, and it may be possible to make use of IPng's Flow Label in some connection-oriented media such as ATM
- datagram service 📦 IPng preserves datagram service as its basic operational mode, though it is possible that the use of path MTU discovery will complicate the use of datagrams in some cases
- configuration ease ⚙️ IPng will have easy and flexible address autoconfiguration, which will support a wide variety of environments from nodes on an isolated network to nodes deep in a complex internet
- security 🔐 IPng includes specific mechanisms for authentication and encryption at the internetwork layer; the security features do rely on the presence of a yet to be defined key management system
- unique names 🏷️ IPng addresses may be used as globally unique names, although they do have topological significance
- access to standards 📢 all of the IPng standards will be published as RFCs with unlimited distribution
- multicast support 📡 IPng specifically includes multicast support
- extensibility 🧩 the use of extension headers and an expandable header option feature will allow the introduction of new features into IPng when needed, in a way that minimizes the disruption of the existing network
- service classes 🎟️ the IPng header includes a Flow Label which may be used to differentiate requested service classes
- mobility 🚶 the proposed IPv4 mobility functions will work with IPng
- control protocol 🎛️ IPng includes the familiar IPv4 control protocol features
- tunneling support 🚇 encapsulation of IPng or other protocols within IPng is a basic capability described in the IPng specifications
11.2 IPv6 🌸
the IANA has assigned version number 6 to IPng 🎉 the protocol itself will be called IPv6 ✨
the remainder of this memo is used to describe IPv6 and its features 💖 this description is an overview snapshot, so the standards documents themselves should be referenced for definitive specifications 📖 we also make a number of specific recommendations about the details of the proposed protocol, the procedures required to complete the definition of the protocol, and the IETF working groups we feel are necessary to get the task done 🫶
12. IPv6 Overview ✨
okay so IPv6 is the new version of the Internet Protocol, and it's giving "glow-up without a total rebrand" 💖 it was designed as an evolutionary step from IPv4, not a revolutionary one. Stuff that already worked in IPv4 got kept, stuff that didn't work or was barely used got removed or made optional, and a few new features got added where they were actually needed 🦋
The important features of IPv6 include: [Hinden94c]
- expanded addressing and routing capabilities 🌸 The IP address size goes from 32 bits to 128 bits, so way more nodes can be addressed, there are more levels of addressing hierarchy, and auto-configuration of addresses is simpler.
Multicast routing scales better because multicast addresses get a "scope" field ✨
There's also a new type of address called a "cluster address," which identifies topological regions instead of individual nodes. Paired with the IPv6 source route capability, cluster addresses let nodes have extra say over the path their traffic takes 🗺️
- simplified header format 💅 Some IPv4 header fields got dropped or made optional. This cuts the common-case processing cost of handling packets and keeps the bandwidth overhead of the IPv6 header as low as possible, even though the addresses are much bigger. The IPv6 addresses are four times longer than the IPv4 addresses, but the IPv6 header is only twice the size of the IPv4 header. no notes, that's iconic 🔥
- support for extension headers and options 🧚 IPv6 options live in separate headers that sit in the packet between the IPv6 header and the transport-layer header. Most of these option headers don't get examined by any router along the delivery path until the packet reaches its final destination, so routers can handle packets with options way faster. Another win: unlike IPv4, IPv6 options can be any length and aren't capped at 40 bytes. That, plus how they get processed, means IPv6 options can do stuff that just wasn't practical in IPv4 💜
A key extensibility feature is that an option can encode what a router or host should do if it doesn't recognise the option. This lets new functionality roll into a live network with minimal danger of disruption 🫶
- support for authentication and privacy 🔐 IPv6 includes an extension for authentication and data integrity. It's a basic element of IPv6, and support for it will be required in all implementations.
IPv6 also defines an extension for confidentiality through encryption. Support for this one will be strongly encouraged in all implementations 🙈
- support for autoconfiguration 🌈 IPv6 supports several forms of autoconfiguration, from "plug and play" node addressing on an isolated network all the way up to the full-featured facilities offered by DHCP ⭐
- support for source routes 🗺️ IPv6 includes an extended function source routing header designed to support the Source Demand Routing Protocol (SDRP). SDRP's purpose is to let sources pick their own routes, which complements the route selection that existing routing protocols provide for both inter-domain and intra-domain routes. [Estrin94b]
- simple and flexible transition from IPv4 🦋 The IPv6 transition plan is aimed at meeting four basic requirements: [Gillig94a]
- Incremental upgrade. Existing installed IPv4 hosts and routers can be upgraded to IPv6 at any time, without depending on any other hosts or routers being upgraded.
- Incremental deployment. New IPv6 hosts and routers can be installed at any time, with no prerequisites.
- Easy Addressing. When existing installed IPv4 hosts or routers get upgraded to IPv6, they can keep using their existing address. They don't need to be given new addresses.
- Low start-up costs. Little or no preparation work is needed to upgrade existing IPv4 systems to IPv6, or to deploy new IPv6 systems 💖
- quality of service capabilities 👑 A new capability lets packets belonging to particular traffic "flows" get labelled, for flows where the sender has asked for special handling, like non-default quality of service or "real-time" service 🎀
12.1 IPv6 Header Format 🎀
The IPv6 header is longer than the IPv4 header, but it's honestly so much more streamlined. A bunch of functions that used to live in the IPv4 header have either been moved into extension headers or dropped entirely. [Deering94b]
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|Version| Flow Label |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Payload Length | Next Header | Hop Limit |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+ +
| |
+ Source Address +
| |
+ +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+ +
| |
+ Destination Address +
| |
+ +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- Version 🔢 The Internet Protocol version number. IPng has been assigned version number 6. (4-bit field)
- Flow Label 🏷️ A host can use this field to label packets it wants special handling for from routers inside a network, like non-default quality of service or "real-time" service. (28-bit field)
- Payload Length 📏 The length of the rest of the packet after the IPv6 header, in octets. To allow payloads bigger than 64K bytes, if this field is 0, the actual packet length is found in a Hop-by-Hop option. (16-bit unsigned integer)
- Next Header 👉 Identifies the type of header right after the IPv6 header. It uses the same values as the IPv4 Protocol field. (8-bit selector field)
- Hop Limit 🛑 Limits the damage from routing loops. Every node that forwards the packet decrements the Hop Limit field by 1. If the Hop Limit gets decremented to zero, the packet is discarded. (8-bit unsigned integer)
- Source Address 🙋 The address of the initial sender of the packet. (128-bit field)
- Destination Address 🎯 The address of the intended recipient of the packet. This might not be the ultimate recipient if an optional Routing Header is present. (128-bit field)
12.2 Extension Headers 🧚
In IPv6, optional internet-layer information gets encoded in separate headers that can sit between the IPv6 header and the transport-layer header in a packet. There are a small number of these extension headers, and each one is identified by its own distinct Next Header value. [From a number of the documents listed in Appendix C.]
12.2.1 Hop-by-Hop Option Header 🌸
The Hop-by-Hop Options header carries optional information that every node along a packet's delivery path has to examine. It's identified by a Next Header value of 0 in the IPv6 header, and it has this format:
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Next Header | Hdr Ext Len | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +
| |
. .
. Options .
. .
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- Next Header 👉 Identifies the type of header right after the Hop-by-Hop Options header. It uses the same values as the IPv4 Protocol field. (8-bit selector)
- Hdr Ext Len 📐 The length of the Hop-by-Hop Options header in 8-octet units, not counting the first 8 octets. (8-bit unsigned integer)
- Options 🧩 Holds one or more TLV-encoded options. (Variable-length field, sized so that the complete Hop-by-Hop Options header is an integer multiple of 8 octets long.)
12.2.2 IPv6 Header Options 💜
Two of the currently defined extension headers, the Hop-by-Hop Options header and the End-to-End Options header, can carry a variable number of Type-Length-Value (TLV) encoded "options." They look like this:
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- - - - - - - - -
| Option Type | Opt Data Len | Option Data
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- - - - - - - - -- Option Type 🏷️ The identifier for the type of option (8-bit field)
- Opt Data Len 📏 The length of this option's Option Data field, in octets. (8-bit unsigned integer)
- Option Data 📦 Data specific to the Option Type. (Variable-length field)
The Option Type identifiers are encoded so that their highest-order two bits say what action must be taken if the processing IPv6 node doesn't recognise the Option Type 🤯
00 - skip over this option and continue processing the header
01 - discard the packet
10 - discard the packet and send an ICMP Unrecognized Type message
to the packet's Source Address, pointing to the unrecognized
Option Type
11 - undefined.For Hop-by-Hop options only, the third-highest-order bit of the Option Type says whether or not this option's Option Data gets included in the integrity assurance computation done when an Authentication header is present. Option data that changes en route has to be left out of that computation 🔒
12.2.3 Routing Header 🗺️
The Routing header is how an IPv6 source lists one or more intermediate nodes (or topological clusters) it wants the packet to "visit" on the way to the destination. This particular form of the Routing Header is designed to support SDRP. [Estrin94b]
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Next Header |Routing Type=1 |M|F| Reserved | SrcRouteLen |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| NextHopPtr | Strict/Loose Bit Mask |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
. .
. Source Route .
. .
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+Okay so the Routing header is the one that lets a packet carry its own little route plan 🗺️✨ Here's how the fields work, bestie 💖
Next Headertells you which header comes right after the Routing header. It uses the same values as the IPv4 Protocol field (8-bit selector) 🎀Routing Typesays what kind of routing this header is doing. The value MUST be 1 👑MREflag is short for Must Report Errors 🚨 If this bit is set to 1, and a router can not further forward a packet (with an incompletely traversed source route), as specified in the Source Route, the router MUST generate an ICMP error message. If this bit is set to 0, and a router can not further forward a packet (with an incompletely traversed source route), as specified in the Source Route, the router SHOULD NOT generate an ICMP error message 🙈Fflag is the Failure of Source Route Behavior flag 💅 If this bit is set to 1, it means that if a router can not further forward a packet (with an incompletely traversed source route), as specified in the Source Route, the router MUST set the value of theNextHopPtrfield to the value of theSrcRouteLenfield. That way, the later forwarding is based solely on the destination address 🦋 If this bit is set to 0, it means that if a router can not further forward a packet (with an incompletely traversed source route), as specified in the Source Route, the router MUST discard the packet 💀Reservedis set to zero when sending and ignored when receiving. No drama 🌸SrcRouteLenis the Source Route Length, which is the number of source route elements or hops in the SDRP Routing header 🧚 You can work out the length of the SDRP routing header from this value (length = SrcRouteLen * 16 + 8). This field may not exceed a value of 24. (It's an 8 bit unsigned integer 🍓)NextHopPtris the Next Hop Pointer, which is the index of the next element or hop to be processed. It starts at 0 so it points to the first element or hop in the source route 🌈 When Next Hop Pointer is equal to Source Route Length, the Source Route is completed. (8 bit unsigned integer ⭐)Strict/Loose Bit Maskgets used when making a forwarding decision 🔥 If the value of the Next Hop Pointer field is N, and the N-th bit in the Strict/Loose Bit Mask field is set to 1, the next hop is a Strict Source Route Hop. If this bit is set to 0, the next hop is a Loose Source Route Hop. (It's a 24 bit bitpattern 🫶)Source Routeis a list of IPv6 addresses showing the path this packet should follow 🛤️ A Source Route can contain an arbitrary intermix of unicast and cluster addresses. (It's an integral multiple of 128 bits 💜)
12.2.4 Fragment Header
The Fragment header is used by an IPv6 source to send payloads larger than would fit in the path MTU to their destinations. (Note: unlike IPv4, fragmentation in IPv6 is performed only by source nodes, not by routers along a packet's delivery path 🙌) The Fragment header is identified by a Next Header value of 44 in the immediately preceding header, and it looks like this 🧩
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Next Header | Reserved | Fragment Offset |Res|M|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Identification |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+Next Headeridentifies the type of header immediately following the Fragment header. It uses the same values as the IPv4 Protocol field (8 bit selector) 🎀ReservedandResare set to zero when sending and ignored when receiving 🌸Fragment Offsetis the offset, in 8-octet units, of the following payload, relative to the start of the original, unfragmented payload. (13-bit unsigned integer 🦋)Mflag: 1 = more fragments; 0 = last fragment 🍓Identificationis a value given to the original payload that's different from any other fragmented payload sent recently with the same IPv6 Source Address, IPv6 Destination Address, and Fragment Next Header value. (If a Routing header is present, the IPv6 Destination Address is that of the final destination 🧚) The Identification value is carried in the Fragment header of all of the original payload's fragments, and the destination uses it to identify all fragments belonging to the same original payload. (32 bit field 💖)
12.2.5 Authentication Header
The Authentication header is used to provide authentication and integrity assurance for IPv6 packets 🔐 Non-repudiation MAY be provided by an authentication algorithm used with the Authentication header, but it is not provided with all authentication algorithms that might be used with this header. The Authentication header is identified by a Next Header value of 51 in the immediately preceding header, and it looks like this ✨
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Next Header | Auth Data Len | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Security Association ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
. .
. Authentication Data .
. .
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+Next Headeridentifies the type of header immediately following the Authentication header. It uses the same values as the IPv4 Protocol field (8-bit selector) 🎀Auth Data Lenis the length of the Authentication Data field in 8-octet units. (8-bit unsigned integer 💅)Reservedis set to zero when sending and ignored when receiving 🌸Security Assoc. IDis, when combined with the IPv6 Source Address, how the receiver(s) figure out which pre-established security association this packet belongs to. (32 bit field 🔥)Authentication Datais the algorithm-specific info needed to authenticate the source of the packet and assure its integrity, as specified for the pre-established security association 🫶 (It's a variable-length field, and it's an integer multiple of 8 octets long 🦋)
12.2.6 Privacy Header
The Privacy Header is all about confidentiality and integrity 🕵️♀️💜 It works by encrypting the data to be protected and putting that encrypted data in the data portion of the Privacy Header. Either a transport-layer (e.g., UDP or TCP) frame MAY be encrypted, or an entire IPv6 datagram MAY be encrypted, depending on the user's security requirements. This encapsulating approach is necessary to provide confidentiality for the entire original datagram. If present, the Privacy Header is always the last non-encrypted field in a packet 🔒
The Privacy Header works between hosts, between a host and a security gateway, or between security gateways. This support for security gateways lets trustworthy networks exist without the performance and monetary costs of security, while still keeping traffic safe as it transits untrustworthy network segments 🌈✨
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Security Association Identifier (SAID) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
. Initialization Vector .
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Next Header* | Length* | Reserved* |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
| Protected Data* +-+-+-+-+-+-+-+-+-+-+
| | trailer* |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
*encryptedSecurity Association Identifier (SAID)identifies the security association for this datagram 🪪 If no security association has been established, the value of this field SHALL be 0x0000. A security association is normally one-way. An authenticated communications session between two hosts will normally have two SAIDs in use (one in each direction) 💞 The receiving host uses the combination of SAID value and originating address to tell which association is the right one. (32 bit value 💫)Initialization Vectoris OPTIONAL, and its value depends on the SAID in use 🌸 For example, the field MAY contain cryptographic synchronization data for a block oriented encryption algorithm. It MAY also be used to hold a cryptographic initialization vector. A Privacy Header implementation will normally use the SAID value to figure out whether this field is present and, if it is, what its size and use are. (Presence and length depend on the SAID 🧚)Next Header(encrypted) identifies the type of header immediately following the Privacy header. It uses the same values as the IPv4 Protocol field (8 bit selector) 🎀Reserved(encrypted) is ignored on reception 🙈Length(encrypted) is the length of the Privacy Header in 8-octet units, not including the first 8 octets. (8-bit unsigned integer 🍓)Protected Data(encrypted) MAY contain an entire encapsulated IPv6 datagram, including the IPv6 header, a sequence of zero or more IPv6 options, and a transport-layer payload. Or it MAY just be a sequence of zero or more IPv6 options followed by a transport-layer payload. (Variable length 🦋)
The trailer field only shows up when the algorithm needs it. 🎀 Some algorithms need padding, like filling things out to a full cryptographic block size for block-oriented encryption. Others need a place to stash authentication data for an encryption algorithm that gives confidentiality without authentication. 🔐
- trailer (Algorithm-dependent Trailer) - encrypted - it's there only when the algorithm in use requires it. (presence and length dependent on SAID) ✨
12.2.7 End-to-End Option Header 🦋
The End-to-End Options header is for optional info that only the packet's destination node(s) need to look at. 👀 It's identified by a Next Header value of TBD in the header right before it. It has the same format as the Hop-by-Hop Option Header, except you can exclude an option from the authentication integrity assurance computation. That's the main difference, and it's giving precision 💜
13. IPng Working Group ✨
We recommend that a brand new IPng Working Group get formed to produce specs for the core functionality of the IPv6 protocol suite. 🌸 The group will carry out the recommendations of the IPng Area Directors, as outlined at the July 1994 IETF and in this memo. We recommend this group be chaired by Steve Deering of Xerox PARC and Ross Callon of Wellfleet. 👑
The main job is to produce a set of documents that define the basic functions, interactions, assumptions, and packet formats for IPv6. We recommend that Robert Hinden of Sun Microsystems be the editor for these documents. The documents listed in Appendix C will be the starting point for the final document set. 📚
The IPng Working Group's work includes:
- complete the IPv6 overview document
- complete the IPv6 detailed operational specification
- complete the IPv6 Addressing Architecture specification
- produce specifications for IPv6 encapsulations over various media
- complete specifications for the support of packets larger than 64KB
- complete specifications of the DNS enhancements required to support IPv6
- complete specification of ICMP, IGMP and router discovery for support of IPv6.
- complete specification of path MTU discovery for IPv6
- complete specifications of IPv6 in IPv6 tunneling
- complete the suggested address format and assignment plan
- coordinate with the Address Autoconfiguration Working Group
- coordinate with the NGTRANS and TACIT Working Groups
- complete specifications of authentication and privacy support headers
The group should also consider a few selected enhancements, including:
- consider ways to compress the IPv6 header in the contexts of native IPv6, multiple IPv6 packets in a flow, and encapsulated IPv6
- consider specifying support for a larger minimum MTU
14. IPng Reviewer 💅
Right now, the IPng Area Directors, the IPng Directorate, and the chairs of the proposed ipng working group are the ones juggling all the parallel efforts going on across the different parts of IPng. 🤹 It's working okay for now, but it can not be maintained over the long run. One reason is that the IPng Area will eventually be dissolved, and its Directorate disbanded. 😭 It'll also get way harder once IPng-related activities start up in other IETF areas.
We recommend that an IPng Reviewer be appointed to be specifically responsible for making sure a consistent view of IPv6 is maintained across the related working groups. We feel this function is required, because the interactions between the parts of the IPng effort are complex and the IPng-related work is spread across a number of IETF areas. We recommend that Dave Clark of MIT be offered this appointment. 🫶
This would be a long-term task, involving review of ongoing activities. The aim is not for the IPng Reviewer to make architectural decisions, since that's the job of the various working groups, the IAB, and the IETF as a whole.. The aim is to spot gaps or misunderstandings before they reach the point where functionality or interworkability is threatened. 🔍
15. Address Autoconfiguration 🧚
As data networks get more complex, the need to bypass at least some of that complexity and move toward "plug and play" gets more and more urgent. 🌈 A user can not be expected to understand the details of the network architecture or know how to configure the network software in their host. In the ideal case, a user should be able to unbox a new computer, plug it into the local network, and "just" have it work, without entering any special information. 💖 Security concerns may restrict how transparent address autoconfiguration can be in some environments, but the mechanisms must be in place to support whatever level of automation the local environment is comfortable with.
The basic requirement of "plug and play" operation is that a host must be able to acquire an address dynamically. That can happen when it attaches to a network for the first time, or when it needs to be readdressed because it moved or because the identity of the network changed. There are many other functions required to support a full "plug and play" environment. [Berk94] Most of these have to be handled outside the IPv6 Area, but a focused effort to define a host address autoconfiguration protocol is part of the IPv6 process. ⭐
We recommend that a new Address Autoconfiguration Working Group (addrconf) get formed, with Dave Katz of Cisco Systems and Sue Thomson of Bellcore as co-chairs. The purpose of this group is to design and specify a protocol for allocating addresses dynamically to IPv6 hosts. The address configuration protocol must be suitable for a wide range of network topologies, from a simple isolated network to a sophisticated globally connected network. It should also allow for varying levels of administrative control, from completely automated operation to very tight oversight. 🎀
The scope of this group is to propose a host address autoconfiguration protocol that supports the full range of topological and administrative environments where IPv6 will be used. The idea is that, together with IPv6 system discovery, the address autoconfiguration protocol gives hosts the minimal bootstrapping information they need to acquire further configuration information, such as what DHCP provides in IPv4. 🧠 The scope does not include router configuration or any other host configuration functions. However, the group is within its rights to investigate and document how this work interacts with related functions, including system discovery, DNS autoregistration, service discovery, and broader host configuration issues, so these functions integrate smoothly. [Katz94a]
The working group is expected to finish its work around the end of 1994 and disband at that time. The group will use the "IPv6 Address Autoconfiguration Architecture" [Katz94b] draft document as the basis of its work. 📝
16. Transition 🦋
The move from IPv4 to IPv6 has two separate needs to meet. 🌍 There's a short-term need to define specific technologies and methods for transitioning IPv4 networks, including the Internet, into IPv6 networks and an IPv6 Internet. There's also a long-term need for broad-based operational planning for the transition. That includes developing methods that allow decentralized migration strategies, understanding the ramifications of a long period of coexistence when both protocols are part of the basic infrastructure, and developing an understanding of the type and scope of architectural and interoperability testing needed to keep the Internet reliable and manageable in the future. 💜
16.1 Transition - Short Term 💫
Any IPng transition plan has to take into account the realities of what types of devices vendors will build and what network managers will deploy. 🛠️ The IPng transition plan must define the procedures needed to successfully implement the functions vendors are likely to include in their devices. This applies even when there are good arguments against a particular function, such as header translation. If products will exist, it's better for them to interoperate than not. 🤝
We recommend that a new IPng Transition (NGTRANS) Working Group get formed, with Bob Gilligan of Sun Microsystems and xxx of yyy as co-chairs. Its job is to design the mechanisms and procedures that support the transition of the Internet from IPv4 to IPv6, and to advise on which procedures and techniques are preferred. 🌷
The group's work falls into three areas:
- Define the processes by which the Internet will make the transition from IPv4 to IPv6. As part of this effort, the group will produce a document explaining to the general Internet community what mechanisms will be used in the transition, how the transition will work, the assumptions about infrastructure deployment inherent in the operation of these mechanisms, and the types of functionality application developers will be able to assume as the protocol mix changes over time.
- Define and specify the mandatory and optional mechanisms vendors should implement in hosts, routers, and other components of the Internet so the transition can be carried out. Dual-stack, encapsulation, and header translation mechanisms must all be defined, as well as the interaction between hosts using different combinations of these mechanisms. The specifications produced will be used by people implementing these IPv6 systems. 🧑💻
- Articulate a concrete operational plan for the Internet to make the transition from IPv4 to IPv6. The result will be a transition plan that network operators and Internet subscribers can actually execute. 🚀
[Gillig94c]
The working group is expected to finish its work around the end of 1994 and disband at that time. The group will use the "Simple SIPP Transition (SST)" [Gilig94a] overview document as the starting point for its work. that's the whole tea, bestie 🌈
16.2 Transition - Long Term 🦋
Okay so there's a whole pile of transition stuff beyond just the specific IPv4 to IPv6 mechanisms and how they get deployed, operated, and played with each other 💅. The ramifications and procedures of moving to a new technology, or to a new version of an existing one, must be fully understood 😭 that's the whole vibe.
We recommend that the Transition and Coexistence Including Testing (TACIT) Working Group, which got started a few months ago, look into some of the basic issues of putting new tech into an established Internet 🌸. TACIT isn't going to stop at the upcoming move to IPv6, because enhancements to IPv6 (IPv6ng) will get developed and accepted over time 👀 and then those need deploying into whatever the Internet looks like at that point. TACIT will be more operationally focused than NGTRANS and will keep going well into the actual IPv6 transition 🧚.
The main areas of exploration are:
- Make the transition from a currently deployed protocol to a new protocol while accommodating heterogeneity and decentralized management. 🎀
- Since it is often difficult or impossible to replace all legacy systems or software, it is important to understand the characteristics and operation of a long period of coexistence between a new protocol and the existing protocol. 🫶
- The Internet must now be considered a utility. We are far removed from a time when a new technology could be deployed to see if it would work in large scale situations. Rigorous architectural and interoperability testing must be part of the predeployment phase of any proposed software for the Internet. Testing the scaling up behaviors and robustness of a new protocol will offer particular challenges. The WG should determine if there are lessons to be learned from: OSPF, BGP4 and CIDR Deployment, the AppleTalk 1 to 2 transition, DECnet Phase 4 to Phase 5 planning and transition, among others. 🔥
The TACIT Working Group will explore each of these facets of the deployment of new technology and develop a number of documents to help guide users and managers of affected data networks and provide to the IETF:
- Detailed descriptions of problem areas in transition and coexistence, both predicted, based on lessons learned, and observed as the IPv6 process progresses. 🌈
- Recommendations for specific testing procedures. 🍓
- Recommendations for coexistence operations procedures. 💜
- Recommendations for the smoothing of decentralized transition planning. ✨
[Huston94]
17. Other Address Families 🧚
There are lots of environments where one or more network protocols are already deployed, or where someone has put serious planning into a comprehensive network addressing plan 📋. In those cases there may be a temptation to bring IPv6 in by using the existing addressing plan to define all or part of the IPv6 addresses 🤔. The upside is that it allows unified management of address space across multiple protocol families, and using common addresses can help make the transition from other protocols to IPv6 easier 💖.
If the existing addresses are globally unique and assigned with regard to network topology, this may be a reasonable idea 🌸. The IETF should work with other organizations to develop algorithms that could be used to map addresses between IPv6 and other environments. The goal for any such mapping must be to provide an unambiguous 1 to 1 map between individual addresses 🎯.
Suggestions have been made to develop mapping algorithms for Novell IPX addresses, some types of OSI NSAPs, E164 addresses and SNA addresses 📱. Each of these possibilities should be carefully examined to make sure that using such an algorithm solves more problems than it creates 🧐. In some cases it may be better to recommend either that a native IPng addressing plan be developed instead, or that an IPv6 address be used within the non-IP environment. [Carpen94b]
We recommend that, in conjunction with other organizations, recommendations about the use of non-IPv6 addresses in IPv6 environments and IPv6 addresses in non-IPv6 environments be developed 🤝.
18. Impact on Other IETF Standards 📚
Many current IETF standards are affected by IPv6, and honestly it's a lot 😭. At least 27 of the current 51 full Internet Standards must be revised for IPv6, along with at least 6 of the 20 Draft Standards and at least 25 of the 130 Proposed Standards. [Postel94]
Sometimes the revisions are simple text changes. For example, in a number of RFCs an IP address gets mentioned in passing as a "32 bit IP address", even though IP addresses aren't directly used in the protocol being defined 🙈. All of the standards track documents will have to be checked to see if they contain such references 🔍.
In most of the rest of the cases, revisions to the protocols, including packet formats, will be required 🛠️. Often the address is just being carried as a data element, and a revised format with a larger field for the address will have no effect on the functional paradigm 💅.
In the remaining cases, some facet of how the protocol operates will change because of IPv6. For example, the security and source route mechanisms are fundamentally changed from IPv4 with IPv6 🚨. Protocols and applications that relied on the IPv4 functionality will have to be redesigned or rethought to use the equivalent function in IPv6 🥺.
In a few cases this is a chance to decide whether some of the RFCs should be moved to historic, for example EGP [Mills84] and IP over ARCNET. [Provan91] 🪦
The base IPng Working Group will address some of these, existing IETF working groups can work on others, and new working groups must be formed to deal with a few of them 🧩. The IPng Working Group will be responsible for defining new versions of ICMP, ARP/RARP, and UDP. It will also review RFC 1639, "FTP Operation Over Big Address Records (FOOBAR)" [Piscit94] and RFC 1191 "Path MTU Discovery" [Mogul90] 👀.
Existing working groups will examine revisions for some of the routing protocols: RIPv2, IS-IS, IDRP and SDRP. A new working group may be required for OSPF 🗺️.
The existing DHCP Working Group may be able to revise DHCP and examine BOOTP 📬.
A TCPng Working Group will be formed soon, and new working groups will have to be formed to deal with standards such as SNMP, DNS, NTP, NETbios, OSI over TCP, Host Requirements, and Kerberos, as well as reviewing most of the RFCs that define IP usage over various media 🌈.
On top of the standards track RFCs mentioned above, there are many Informational and Experimental RFCs that would be affected as well, plus numerous Internet Drafts (and the standards track RFCs we missed) 😅.
We recommend that the IESG commission a review of all standards track RFCs to make sure a full list of affected documents is compiled. We recommend that the IESG charge current IETF working groups with the task of understanding the impact of IPv6 on their proposals and, where appropriate, revise the documents to include support for IPv6 💖.
We recommend that the IESG charter new working groups where required to revise other standards RFCs 🎀.
19. Impact on non-IETF standards and on products 🛍️
Many products and user applications that rely on the size or structure of IPv4 addresses will need to be modified to work with IPv6 🔧. The IETF can help investigate the impacts of IPv6 on non-IETF standards and products, but the primary responsibility for doing so sits with the other standards bodies and the vendors 🤷♀️.
Examples of non-IETF standards that are affected by IPv6 include the POSIX standards, Open Software Foundation's DCE and DME, X-Open, Sun ONC, the Andrew File System and MIT's Kerberos 📖. Most products that provide specialized network security, including firewall-type devices, are among those that must be extended to support IPv6 🛡️.
20. APIs 👩💻
It's traditional to say that the IETF does not "do" APIs 🙃. There are lots of reasons for this, but the one most often cited is that TCP/IP is used in too many environments, with too many operating systems, programming languages, and platforms. The feeling is that the IETF shouldn't try to define a language and operating system independent interface in the face of that much complexity 🌀.
We feel that this historical tendency for the IETF to avoid dealing with APIs should be reexamined in the case of IPv6 ✨. We feel that in a few specific cases, a particular type of API is so prevalent that a single common solution for the modifications made necessary by IPv6 should be documented 💜.
We recommend that Informational RFCs be solicited or developed for these few cases. In particular, the Berkeley-style sockets interface, the UNIX TLI and XTI interfaces, and the WINSOCK interfaces should be targeted. A draft document exists that could be developed into the sockets API description 🧦. [Gillig94b]
21. Future of the IPng Area and Working Groups 🌅
In our presentation at the Houston IETF meeting, we said the existing IPng proposal working groups would not be forced to close down after the recommendation was made. Each of them has been working on technologies that may have applications beyond their IPng proposal, and those technologies shouldn't get lost 💫.
Since the Toronto IETF meeting, the existing IPng working groups have been returned to the Internet Area 🏠. The group members may decide to close down the working groups or to continue some of their efforts. The charters of the working groups must be revised if they choose to continue, since they would no longer be proposing an IPng candidate 📝.
In Toronto, the chairs of the SIPP Working Group requested that the SIPP Working Group be concluded 👋. The chairs of the TUBA Working Group requested that the TUBA Working Group be understood to be in hiatus until a number of the documents in process were completed, at which time they would request that the working group be concluded 💤.
We recommend that the IPng Area and its Directorate continue until the basic documents have entered the standards track in late 1994 or early 1995, and that after that time the area be dissolved and those IPng Area working groups still active be moved to their normal IETF areas 🥳.
22. Security Considerations ✨
okay bestie, security is the thing the internet has been getting roasted for forever 💀. Every conference, workshop, and article seems to say the same thing: the security we can actually get is way below what we need for what the internet is used for now and what it'll be used for later 😬. A bunch of the RFC 1550 White Papers called this out and asked for better security [Adam94, Bell94b, Brit94, Green94, Vecchi94, Flei94], and so did "Realizing the Information Future" [Nat94].
In February of 1994, the IAB held a workshop on security in the Internet architecture 🧠. Its report [IAB94] digs into lots of security problem areas and makes a pile of recommendations for making the Internet safer for its users.
We really think improving the basic level of security on the Internet is vital for it to keep thriving 🌈. Users need to be able to trust that their exchanges can't be tampered with, diverted, or exposed 🔒. Organizations that want to do business on the Internet need real confidence in who they're talking to and how safe their communications are. The goal is simple: strong protection as a matter of course, all across the Internet ✨.
As the IAB report points out, a lot of the necessary tools aren't part of the internetworking layer. Higher-level tools could totally use strong security features from the internetworking layer if those features existed 🏗️. We expect plenty of special high-level security packages for specific Internet groups, but support for basic packet-level authentication is what unlocks a much-needed, widespread security infrastructure across the whole Internet.
It's best to separate support for authentication from support for encryption 🔑. You should be able to use each function on its own. Sometimes all you need is to confirm who you're talking to, and other times the data has to stay private 🤫.
Here's our recommendation: IPv6 supports packet authentication as a basic and required function. Applications should be able to count on that feature in every IPv6 implementation 💖. Support for a specific authentication algorithm should also be mandated, while support for additional algorithms should be optional.
So we recommend that support for the Authentication Header be required in all compliant IPv6 implementations 🎀.
We recommend that support for a specific authentication algorithm be required. That algorithm should be picked by the time the IPv6 documents are offered as Proposed Standards 📜.
We recommend that support for the Privacy Header be required in IPv6 implementations 🫶.
We recommend that support for a privacy authentication algorithm be required. Same deal: that algorithm should be determined by the time the IPv6 documents are offered as Proposed Standards 📜.
Obviously, you'd need a key management infrastructure to actually use the authentication and encryption headers 🗝️. But defining that infrastructure is outside the scope of the IPv6 effort. There are ongoing IETF activities in this area though, and the IPv6 transition working groups must coordinate with them 🤝.
Also obviously, authentication and encryption can add to the cost and affect the performance of systems. But a more secure infrastructure is worth the penalty 💪. Whatever penalty there is should also shrink over time as software and hardware assistance gets better ⚡.
Firewalls are everywhere on the Internet now 🧱. We hope the authentication and privacy features in IPv6 reduce the need for them, but we get that they'll keep being used for the foreseeable future. So clear guidance should be given to firewall developers on the best ways to design and configure them in an IPv6 environment 📋.
We recommend that an "IPv6 framework for firewalls" be developed. This framework should explore how the Authentication Header can be used to strengthen firewall technology, and detail how a firewall should analyze the IPv6 packet 🔍.
Some aspects of security still need more study 🤔. For example, [Vecchi94] pointed out that even in non-military situations, there are places where procedures to thwart traffic analysis will be required. That could be done with encrypted encapsulation, but this and similar requirements must be handled on an ongoing basis by the Security Area of the IETF 🕵️. The IPv6 design also has to be flexible enough to support adding these security features later on.
We believe IPv6, with its inherent security features, will be the foundation the Internet keeps expanding its functionality and user base on 🌸. Periodt 💅.
23. Authors' Addresses 🎀
Meet the two authors who wrote this down, with their contact info:
Scott Bradner
Harvard University
10 Ware St.
Cambridge, MA 02138
Phone: +1 617 495 3864
EMail: sob@harvard.edu
Allison Mankin
USC/Information Sciences Institute
4350 North Fairfax Drive, Suite 400
Arlington, VA 22303
Phone: +1 703-807-0132
EMail: mankin@isi.eduAppendix A - Summary of Recommendations 📝
Here's the big recap of every recommendation, section by section, so you don't have to dig through the whole doc 🧁:
5.3 Address Assignment Policy Recommendations
changes in address assignment policies are not recommended
reclamation of underutilized assigned addresses is not currently
recommended
efforts to renumber significant portions of the Internet are not
currently recommended
recommend consideration of assigning CIDR-type address blocks out
of unassigned Class A addressees
11. IPng Recommendation
recommend that "Simple Internet Protocol Plus (SIPP) Spec. (128
bit ver)" [Deering94b] be adopted as the basis for IPng
recommend that the documents listed in Appendix C be the basis of
IPng
13. IPng Working Group
recommend that an IPng Working Group be formed, chaired by Steve
Deering and Ross Callon
recommend that Robert Hinden be the document editor for the IPng
effort
14. IPng Reviewer
recommend that an IPng Reviewer be appointed and that Dave Clark
be that reviewer
15. Address Autoconfiguration
recommend that an Address Autoconfiguration Working Group be
formed, chaired by Dave Katz and Sue Thomson
16.1 Transition - Short Term
recommend that an IPng Transition Working Group be formed, chaired
by Bob Gilligan and TBA
16.2 Transition - Long Term
recommend that the Transition and Coexistence Including Testing
Working Group be chartered
17. Other Address Families
recommend that recommendations about the use of non-IPv6 addresses
in IPv6 environments and IPv6 addresses in non-IPv6
environments be developed
18. Impact on Other IETF Standards
recommend the IESG commission a review of all standards track RFCs
recommend the IESG charge current IETF working groups with the
task of understanding the impact of IPng on their proposals
and, where appropriate, revise the documents to include support
for IPng
recommend the IESG charter new working groups where required to
revise other standards RFCs
20. APIs
recommend that Informational RFCs be developed or solicited for a
few of the common APIs
21. Future of the IPng Area and Working Groups
recommend that the IPng Area and Area Directorate continue until
main documents are offered as Proposed Standards in late 1994
22. Security Considerations
recommend that support for the Authentication Header be required
recommend that support for a specific authentication algorithm be
required
recommend that support for the Privacy Header be required
recommend that support for a specific privacy algorithm be
required
recommend that an "IPng framework for firewalls" be developedAppendix B - IPng Area Directorate 👑
Here's the squad that made up the IPng Area Directorate 🌟:
J. Allard - Microsoft <jallard@microsoft.com>
Steve Bellovin - AT&T <smb@research.att.com>
Jim Bound - Digital <bound@zk3.dec.com>
Ross Callon - Wellfleet <rcallon@wellfleet.com>
Brian Carpenter - CERN <brian.carpenter@cern.ch>
Dave Clark - MIT <ddc@lcs.mit.edu >
John Curran - NEARNET <curran@nic.near.net>
Steve Deering - Xerox <deering@parc.xerox.com>
Dino Farinacci - Cisco <dino@cisco.com>
Paul Francis - NTT <francis@slab.ntt.jp>
Eric Fleischmann - Boeing <ericf@atc.boeing.com>
Mark Knopper - Ameritech <mak@aads.com>
Greg Minshall - Novell <minshall@wc.novell.com>
Rob Ullmann - Lotus <ariel@world.std.com>
Lixia Zhang - Xerox <lixia@parc.xerox.com>Daniel Karrenberg of RIPE joined the Directorate when it was formed, but had to bow out because his day job got too demanding 😭.
After the Toronto IETF meeting, Paul Francis left the Directorate to chase other interests 🦋. Robert Hinden of Sun Microsystems and Yakov Rekhter of IBM joined the squad 🎉.
Appendix C - Documents Referred to the IPng Working Groups 📚
These are the documents that got handed off to the IPng Working Groups 🧚:
- [Deering94b] Deering, S., "Simple Internet Protocol Plus (SIPP) Spec. (128 bit ver)", Work in Progress.
- [Francis94] Francis, P., "SIPP Addressing Architecture", Work in Progress.
- [Rekhter94] Rekhter, Y., and T. Li, "An Architecture for IPv6 Unicast Address Allocation", Work in Progress.
- [Gillig94a] Gilligan, R., "Simple SIPP Transition (SST) Overview", Work in Progress.
- [Gillig94b] Gilligan, R., Govindan, R., Thomson, S., and J. Bound, "SIPP Program Interfaces for BSD Systems", Work in Progress.
- [Atkins94a] Atkinson, R., "SIPP Security Architecture", Work in Progress.
- [Atkins94b] Atkinson, R., "SIPP Authentication Header", Work in Progress.
- [Ford94b] Ford, P., Li, T., and Y. Rekhter, "SDRP Routing Header for SIPP-16", Work in Progress.
- [Hinden94c] Hinden, R., "IP Next Generation Overview", Work in Progress.
Appendix D - IPng Proposal Overviews 🌈
And last but not least, the overviews of the IPng proposals themselves ⭐:
- [Ford94a] Ford, P., and M. Knopper, "TUBA as IPng: A White Paper", Work in Progress.
- [Hinden94a] Hinden, R., "Simple Internet Protocol Plus White Paper", RFC 1710, Sun Microsystems, October 1994.
- [McGovern94] McGovern, M., and R. Ullmann, "CATNIP: Common Architecture for the Internet", RFC 1707, Sunspot Graphics, Lotus Development Corp., October 1994.
Appendix E - RFC 1550 White Papers ✨
okay bestie, this is the lineup of white papers that answered RFC 1550, the IPng white paper solicitation 🦋 each one came from a different corner of the networking world, so here they all are, one by one:
- [Adam94] Adamson, B., "Tactical Radio Frequency Communication Requirements for IPng", RFC 1677, NRL, August 1994.
- [Bello94a] Bellovin, S., "On Many Addresses per Host", RFC 1681, AT&T Bell Laboratories, August 1994.
- [Bello94b] Bellovin, S., "Security Concerns for IPng", RFC 1675, AT&T Bell Laboratories, August 1994.
- [Bound94] Bound, J., "IPng BSD Host Implementation Analysis", RFC 1682, Digital Equipment Corporation, August 1994.
- [Brazd94] Brazdziunas, C., "IPng Support for ATM Services", RFC 1680, Bellcore, August 1994.
- [Britt94] Britton, E., and J. Tavs, "IPng Requirements of Large Corporate Networks", RFC 1678, IBM, August 1994.
- [Brownl94] Brownlee, J., "Accounting Requirements for IPng", RFC 1672, University of Auckland, August 1994.
- [Carpen94a] Carpenter, B., "IPng White Paper on Transition and Other Considerations", RFC 1671, CERN, August 1994.
- [Chiappa94] Chiappa, N., "IPng Technical Requirements Of the Nimrod Routing and Addressing Architecture", RFC 1753, December 1994.
- [Clark94] Clark, R., Ammar, M., and K. Calvert, "Multiprotocol Interoperability In IPng", RFC 1683, Georgia Institute of Technology, August 1994.
- [Curran94] Curran, J., "Market Viability as a IPng Criteria", RFC 1669, BBN, August 1994.
- [Estrin94a] Estrin, D., Li, T., and Y. Rekhter, "Unified Routing Requirements for IPng", RFC 1668, USC, cisco Systems, IBM, August 1994.
- [Fleisch94] Fleischman, E., "A Large Corporate User's View of IPng", RFC 1687, Boeing Computer Services, August 1994.
- [Green94] Green, D., Irey, P., Marlow, D., and K. O'Donoghue, "HPN Working Group Input to the IPng Requirements Solicitation", RFC 1679, NSWC-DD, August 1994.
- [Ghisel94] Ghiselli, A., Salomoni, D., and C. Vistoli, "INFN Requirements for an IPng", RFC 1676, INFN/CNAF, August 1994.
- [Heager94] Heagerty, D., "Input to IPng Engineering Considerations", RFC 1670, CERN, August 1994.
- [Simpson94] Simpson, W. "IPng Mobility Considerations", RFC 1688, Daydreamer, August 1994.
- [Skelton94] Skelton, R., "Electric Power Research Institute Comments on IPng", RFC 1673, EPRI, August 1994.
- [Syming94] Symington, S., Wood, D., and J. Pullen, "Modeling and Simulation Requirements for IPng", RFC 1667, MITRE, George Mason University, August 1994.
- [Taylor94] Taylor, M., "A Cellular Industry View of IPng", RFC 1674, CDPD Consortium, August 1994.
- [Vecchi94] Vecchi, M., "IPng Requirements: A Cable Television Industry Viewpoint", RFC 1686, Time Warner Cable, August 1994.
Appendix F - Additional References 📚
these are the extra sources the document leans on, from BOF minutes and mailing list threads to work-in-progress drafts and older RFCs 🌸
- [Almqu92] Almquist, P., "Minutes of the Selection Criteria BOF", Washington DC IETF, November 1992, (ietf/nov92/select-minutes-92nov.txt).
- [Berkow94] Berkowitz, H., "IPng and Related Plug-and-Play Issues and Requirements", Work in Progress, September 1994.
- [Bos94] Bos, E. J., "Minutes of the Address Lifetime Expectations BOF (ALE)", Seattle IETF, March 1994, (ietf/ale/ale-minutes-94mar.txt).
- [Big] Archives of the big-internet mailing list, on munnari.oz.au in big-internet/list-archives.
- [Bradner93] Bradner, S., and A. Mankin, "IP: Next Generation (IPng) White Paper Solicitation", RFC 1550, Harvard University, NRL, December 1993.
- [Callon87] Callon, R., "A Proposal for a Next Generation Internet Protocol", Proposal to X3S3, December 1987.
- [Callon92a] Callon, R., "CNAT", Work in Progress.
- [Callon92b] Callon, R., "Simple CLNP", Work in Progress.
- [Callon92c] Callon, R., "TCP and UDP with Bigger Addresses (TUBA), A Simple Proposal for Internet Addressing and Routing", RFC 1347, DEC, June 1992.
- [Carpen93] Carpenter, B. and T. Dixon, "Minutes of the IPng Decision Process BOF (IPDECIDE)", /ietf/93jul/ipdecide-minutes-93jul.txt, August 1993.
- [Carpen94b] Carpenter, B, and J. Bound, "Recommendations for OSI NSAP usage in IPv6", Work in Progress.
- [Chiappa91] Chiappa, J., "A New IP Routing and Addressing Architecture", Work in Progress.
- [Clark91] Clark, D., Chapin, L., Cerf, V., Braden, R., and R. Hobby, "Towards the Future Internet Architecture", RFC 1287, MIT, BBN, CNRI, ISI, UC Davis, December 1991.
- [Deering92] Deering, S., "The Simple Internet Protocol", Big-Internet mailing list, 22 Sept. 1992.
- [Deering94a] Deering, S., and P. Francis, Message to sipp mailing list, 31 May 1994.
- [Estrin94b] Estrin, D., Zappala, D., Li, T., Rekhter, Y., and K. Varadhan, "Source Demand Routing: Packet Format and Forwarding Specification (Version 1)" Work in Progress.
- [Fuller93] Fuller, V., Li, T., Yu, J., and K. Varadhan, "Classless Inter-Domain Routing (CIDR): an Address Assignment and Aggregation Strategy", RFC 1519, BARRNet, cisco Systems, MERIT, OARnet, September 1993.
- [Gillig94c] Gilligan, B., "IPng Transition (ngtrans)", Work in Progress.
- [Gross92} Gross, P., and P. Almquist, "IESG Deliberations on Routing and Addressing", RFC 1380, ANS, Stanford University, November 1992.
- [Gross94] Gross, P. "A Direction for IPng", RFC 1719, MCI, December 1994.
- [Hinden92a] Hinden, R., "New Scheme for Internet Routing and Addressing (ENCAPS)", Work in Progress.
- [Hinden94b] Hinden, R., Deering, S., and P. Francis, "Simple Internet Protocol Plus", Working Group Charter, April 1994.
- [Hinden92b] Hinden, R., and D. Crocker, "A Proposal for IP Address Encapsulation (IPAE): A Compatible version of IP with Large Addresses", Work in Progress.
- [Huston94] Huston, G., and A. Bansal, draft charter for the "Transition and Coexistence Including Testing (TACIT) Working Group, June 1994.
- [Huitema93] Huitema, C., "IAB Recommendations for an Intermediate Strategy to Address the Issue of Scaling", RFC 1481, INRIA, July 1993.
- [Huitema94] Huitema, C., "The H ratio for address assignment efficiency", RFC 1715, INRIA, October 1994.
- [IAB92] Internet Architecture Board, "IP Version 7", Work in Progress.
- [IAB94] Braden, R., Clark, D., Crocker, S., and C. Huitema, "Report of IAB Workshop on Security in the Internet Architecture - February 8-10, 1994", RFC 1636, USC/Informaiton Sciences Institute, MIT Laboratory for Computer Science, Trusted Information Systems, Inc., INRIA, IAB Chair, June 1994.
- [Kasten92] Kastenholz, F, and C. Partridge, "IPv7 Technical Criteria", Work in Progress.
- [Kasten94] Partridge, C., and F. Kastenholz, "Technical Criteria for Choosing IP: The Next Generation (IPng)", RFC 1726, BBN Systems and Technologies, FTP Software, December 1994.
- [Knopper94a] Knopper, M., and P. Ford, "TCP/UDP Over CLNP-Addressed Networks (TUBA)", Working Group Charter, January 1994.
- [Knopper94b] Knopper, M., and D. Piscitello, "Minutes of the BigTen IPng Retreat, May 19 & 20 1994".
- [Leiner93] Leiner, B., and Y. Rekhter, "The MultiProtocol Internet", RFC 1560, USRA, IBM, December 1993.
- [Mankin94] Mankin, A., and S. Bradner, message to big-internet, tuba, sipp, catnip and ietf mailing lists, 7 July 1994.
- [Mills84] Mills, D. "Exterior Gateway Protocol Formal Specification", RFC 904, UDEL, April 1984.
- [Mogul90] Mogul, J., and S. Deering, "Path MTU Discovery", RFC 1191, DECWRL, Stanford University, November 1990.
- [Nat94] National Research Council, "Realizing the Information Future: The Internet and Beyond", National Academy Press, 1994.
- [Piscit94] Piscitello, D., "FTP Operation Over Big Address Records (FOOBAR)", RFC 1639, Core Competence, June 1994.
- [Provan91] Provan, D., "Transmitting IP Traffic over ARCNET Networks", RFC 1051, Novell, February 1991.
- [Postel94] Postel, J., Editor, "Internet Official Protocol Standards", RFC 1720, USC/Information Sciences Institute, November 1994.
- [Solens93a] Solensky, F., and T. Li, "Charter for the Address Lifetime Expectations Working Group", FTP Software, Cisco Systems, November 1993.
- [Solens93b] Solensky, F., "Minutes of the Address Lifetime Expectations BOF (ALE)", Houston IETF, November 1993, (ietf/ale/ale-minutes-93nov.txt).
- [Solens94] Solensky, F., "Minutes of the Address Lifetime Expectations BOF (ALE)", Toronto IETF, July 1994, (ietf/ale/ale-minutes-94jul.txt).
- [Sukonnik94] Sukonnik, V., "Common Architecture for Next-Generation IP (catnip), Working Group Charter, April 1994.
- [Tsuchiya92] Tsuchiya, P., "The 'P' Internet Protocol", Work in Progress.
- [Ullmann93] Ullmann, R., "TP/IX: The Next Internet", RFC 1475, Process Software Corporation, June 1993.
Appendix G - Acknowledgments 🫶
okay the thank-yous, and they're so deserved 💖
getting to this stage of the recommendation was not even vaguely possible without a whole crowd of people 😭 a huge shoutout to the IPng Directorate (listed in Appendix B), and to Frank Kastenholz and Craig Partridge, who wrote the Criteria document, plus Jon Crowcroft, who co-chaired the ngreq BOF. Their work was critical 👑 The chairs, members and document authors of the three IPng proposal working groups, the ALE working group and the TACIT working group also laid the groundwork this recommendation is sitting on, so they deserve the biggest flowers 🌸
we also want to thank everyone who took the time to respond to RFC1550 and who gave us the broad understanding of all the different data networking requirements that any IPng proposal has to cover 🧚
the members of the IESG, the IAB, and the always active folks on the various mailing lists gave us lots of insights into the issues we were facing 💅
plenty of other individuals gave us sometimes spirited but always useful counsel during this process 🙈 they include (in no particular order) Radia Perlman, Noel Chiappa, Peter Ford, Dave Crocker, Tony Li, Dave Piscitello, Vint Cerf and Dan Lynch ✨
and a special thank-you to David Williams and Cheryl Chapman, who took on the occasionally impossible task of making sure what is written here resembles English to some degree 💀🎀
to all of the many people mentioned above and the ones we've skipped in our forgetfulness: thank you for making this task doable 💜🦋
📦 where this page comes from
- ietf: rfc1752 1995-01
- 💖 girlified by claude-haiku-5-5 on : a language model's rewrite of the original, under its terms