RFC 1726
Technical Criteria for Choosing IP The Next Generation (IPng)
RFC 1726: Technical Criteria for Choosing IP The Next Generation (IPng) 🦋
okay bestie, this one is a December 1994 Informational RFC 💖 It was written by C. Partridge (BBN Systems and Technologies) and F. Kastenholz (FTP Software). It's Category: Informational, so it's advice, not a standard. The header doesn't list anything it obsoletes or updates, so it's just doing its own thing ✨
Status of this Memo 🌸
Okay so this memo is giving info for the Internet community 💅 It is not an Internet standard of any kind, and distribution is unlimited 🫶
Abstract ✨
So this doc was sent to the IPng Area as a response to RFC 1550 🎀 Getting published here does NOT mean the IPng Area agrees with any of the ideas inside 🙈 If you have comments, send them to the big-internet@munnari.oz.au mailing list. And the main vibe is that this RFC lays out the mobility-related criteria to think about when designing and picking the Next Generation of IP 🔥
Table of Contents 🧚
1. Introduction. . . . . . . . . . . . . . . . . . . . . . . 2
2. Goals . . . . . . . . . . . . . . . . . . . . . . . . . . 3
3. Note on Terminology . . . . . . . . . . . . . . . . . . . 4
4. General Principles. . . . . . . . . . . . . . . . . . . . 4
4.1 Architectural Simplicity. . . . . . . . . . . . . . . . . 4
4.2 One Protocol to Bind Them All . . . . . . . . . . . . . . 4
4.3 Live Long . . . . . . . . . . . . . . . . . . . . . . . . 5
4.4 Live Long AND Prosper . . . . . . . . . . . . . . . . . . 5
4.5 Co-operative Anarchy. . . . . . . . . . . . . . . . . . . 5
5. Criteria. . . . . . . . . . . . . . . . . . . . . . . . . 6
5.1 Scale . . . . . . . . . . . . . . . . . . . . . . . . . . 7
5.2 Topological Flexibility . . . . . . . . . . . . . . . . . 8
5.3 Performance . . . . . . . . . . . . . . . . . . . . . . . 9
5.4 Robust Service. . . . . . . . . . . . . . . . . . . . . . 10
5.5 Transition. . . . . . . . . . . . . . . . . . . . . . . . 12
5.6 Media Independence. . . . . . . . . . . . . . . . . . . . 13
5.7 Unreliable Datagram Service . . . . . . . . . . . . . . . 15
5.8 Configuration, Administration, and Operation. . . . . . . 16
5.9 Secure Operation. . . . . . . . . . . . . . . . . . . . . 17
5.10 Unique Naming . . . . . . . . . . . . . . . . . . . . . . 18
5.11 Access. . . . . . . . . . . . . . . . . . . . . . . . . . 19
5.12 Multicast . . . . . . . . . . . . . . . . . . . . . . . . 20
5.13 Extensibility . . . . . . . . . . . . . . . . . . . . . . 21
5.13.1 Algorithms. . . . . . . . . . . . . . . . . . . . . . . . 22
5.13.2 Headers . . . . . . . . . . . . . . . . . . . . . . . . . 22
5.13.3 Data Structures . . . . . . . . . . . . . . . . . . . . . 22
5.13.4 Packets . . . . . . . . . . . . . . . . . . . . . . . . . 22
5.14 Network Service . . . . . . . . . . . . . . . . . . . . . 22
5.15 Support for Mobility. . . . . . . . . . . . . . . . . . . 24
5.16 Control Protocol. . . . . . . . . . . . . . . . . . . . . 25
5.17 Private Networks. . . . . . . . . . . . . . . . . . . . . 25
6. Things We Chose Not to Require. . . . . . . . . . . . . . 26
6.1 Fragmentation . . . . . . . . . . . . . . . . . . . . . . 26
6.2 IP Header Checksum. . . . . . . . . . . . . . . . . . . . 26
6.3 Firewalls . . . . . . . . . . . . . . . . . . . . . . . . 27
6.4 Network Management. . . . . . . . . . . . . . . . . . . . 27
6.5 Accounting. . . . . . . . . . . . . . . . . . . . . . . . 27
6.6 Routing . . . . . . . . . . . . . . . . . . . . . . . . . 27
6.6.1 Scale . . . . . . . . . . . . . . . . . . . . . . . . . . 28
6.6.2 Policy. . . . . . . . . . . . . . . . . . . . . . . . . . 28
6.6.3 QOS . . . . . . . . . . . . . . . . . . . . . . . . . . . 28
6.6.4 Feedback. . . . . . . . . . . . . . . . . . . . . . . . . 28
6.6.5 Stability . . . . . . . . . . . . . . . . . . . . . . . . 28
6.6.6 Multicast . . . . . . . . . . . . . . . . . . . . . . . . 29
7. References . . . . . . . . . . . . . . . . . . . . . . . . 29
8. Security Considerations . . . . . . . . . . . . . . . . . 30
9. Acknowledgements. . . . . . . . . . . . . . . . . . . . . 30
10. Authors' Addresses. . . . . . . . . . . . . . . . . . . . 311. Introduction 💖
So this version was commissioned by the IPng area of the IETF 🌈 Its whole job is to define a set of criteria for judging the protocols that are proposed to become the next generation of IP ✨
The criteria here were pulled together from a bunch of places, like "IP Version 7" [1], "IESG Deliberations on Routing and Addressing" [2], and "Towards the Future Internet Architecture" [3]. They also came from the IPng Requirements BOF at the Washington D.C. IETF Meeting in December of 1992, the IPng Working Group meeting at the Seattle IETF meeting in March 1994, and discussions on the Big-Internet mailing list (big-internet@munnari.oz.au, send requests to join to big-internet-request@munnari.oz.au) 📬 Add in discussions with the IPng Area Directors and Directorate, plus the mailing lists for each individual IPng effort, and it's a whole squad of input 🫶
This doc assumes a new IP-layer protocol is actually wanted 🧐 The community is still debating whether we could stretch the life of IPv4 a good chunk longer by engineering things better, like routing protocols, or whether we should develop IPng now. This document does NOT try to answer that question 🙈
We'd love to thank literally hundreds of people who shared their views and insights with us 🥹 BUT, and this is important, the memo is only the personal opinion of the authors. It in no way represents, and should not be read as representing, the ISOC, the IAB, the IRTF, the IESG, the IETF, the Internet community as a whole, or the authors' employers 💅
2. Goals 🎀
Okay so the big idea here is that a list of criteria helps the IETF make evaluating IPng proposals easier 💖 Developers can prioritize their work and make smart choices about where to spend more or less time. The list can also help the community tell which proposals are serious contenders and which ones just aren't up to the task 🔥
But real talk, these criteria probably aren't enough to pick the single best proposal 🙃 Stuff like trading a little performance (e.g., packets per second routed) for a bit more functionality (e.g., more flexible routing) can't really be solved with a simple checklist. Still, the authors believe that at minimum, protocols that meet these criteria can serve as the future IPng 👑
The criteria were first an ordered list, meant to rank how important each one is 📋 Eventually the layout changed. Now each criterion is presented without weighting, but each one has a time frame that says roughly when that criterion, or a feature of it, should be available ⏰
They tried to write the criteria as goals or requirements, not as demands for specific engineering solutions 🧠 Like, people in the community talked about making route aggregation a requirement. The authors think route aggregation is not a requirement in and of itself, but rather one part of a solution to the real problem of scaling to some very large, complex topology 🌍 So NOT listed as a requirement: route aggregation. Instead the doc lists the more general functional goal of having the routing scale, rather than the particular mechanism of route aggregation 🦋
For timing, the authors used two guiding principles 🧭 First, IPng has to offer an internetwork service akin to IPv4's, but improved to handle the well-known and widely understood problems of scaling the Internet architecture to more end-points and an ever-increasing range of bandwidths 📈 Second, users and network managers have to want to upgrade their equipment to support IPng 🥺 At a minimum, that second point means there must be a straightforward way to transition systems from IPv4 to IPng. But it also strongly suggests that IPng should offer features IPv4 doesn't have, because new features are a motivation to deploy IPng more quickly 🚀
3. Note on Terminology 🧚
The existing proposals tend to distinguish between endpoint identification of, e.g., individual hosts, and topological addresses of network attachment points 🤔 This memo doesn't make that distinction. It uses the term "address" the way IPv4 uses it currently, meaning both the identification of a particular endpoint or host AND the topological address of a point on the network ✨ The authors assume that if the endpoint/address split sticks around, the proposals will make the proper distinctions with respect to the criteria listed below 💜
4. General Principles 🌸
4.1. Architectural Simplicity 💅
In anything at all, perfection is finally attained not when there is no longer anything to add, but when there is no longer anything to take away. Antoine de Saint-Exupery
Okay so the authors believe that lots of communications functions are better handled at protocol layers other than the IP layer 🎀 They picture protocol stacks as hourglass-shaped, with IPng in the middle, or waist, of the hourglass ⏳ That means essentially all higher-layer protocols make use of and rely on IPng. And since IPng sits in the "protocol hourglass," it encompasses a wide variety of lower-layer protocols too 🫶 When IPng doesn't perform a particular function or provide a certain service, it should not get in the way of the other elements of the protocol stack that might want to perform that function 🙌
Wait, I need to be careful here: the original says "should not," so in capitals that's the exact key-word phrase I should keep. Lowercase in my own voice: it should not get in the way 💖
4.2. One Protocol to Bind Them All 🧝
One of the most important things about The Internet is that it provides global IP-layer connectivity 🌍 The IP layer is the point of commonality among all the nodes on the Internet. Basically, the main goal of the Internet is to provide an IP Connectivity Service to everyone who wants it ✨
This does NOT mean the Internet is a One-Protocol Internet 🙅♀️ The Internet is today, and shall remain in the future, a Multi-Protocol Internet 🌈 Multi-protocol operations are required to allow for continued testing, experimentation, and development, and because service providers' customers clearly want to be able to run protocols such as CLNP, DECNET, and Novell over their Internet connections 💻
4.3. Live Long 🦋
It is very difficult to change a protocol as central to the workings of the Internet as IP 😭 Changing it frequently is even more of a problem. Honestly this simply cannot be done 💀 The authors believe it's impossible to expect the community to make significant, non-backward-compatible changes to the IP layer more often than once every 10-15 years. To be conservative, they strongly urge protocol developers to consider what the Internet will look like in 20 years and design their protocols to fit that vision 🔮
As a data point, the SNMP community has had great difficulty moving from SNMPv1 to SNMPv2 🥲 Frequent changes in software are hard, bestie 💜
4.4 Live Long AND Prosper ✨
okay so, we're honestly not convinced that bigger addresses and more efficient routing are enough to make anyone switch to IPng 🙄. Switching means vendors, service providers, and users all dealing with service disruptions and whatnot. Those problems can get "solved" way more simply with faster routers, balkanization of the Internet address space, and other hacks 💅. But that's a band-aid, bestie 🩹.
We believe there must be positive functional or operational benefits to switching to IPng. Real reasons, not vibes 🎀
In other words, IPng must be able to live for a long time AND it must allow the Internet to prosper and grow to serve new applications and user needs 🌈👑
4.5 Co-operative Anarchy 🦋
this one is my favorite ngl 😭. A huge reason the Internet is so successful is that there's no single, centralized point of control or promulgator of policy for the whole network 🌸. Each constituent gets to tailor its own networks, environments, and policies to fit its needs. The constituents only have to cooperate as much as they need to in order to interoperate 🫶.
We believe this decentralized and decoupled nature of the Internet must be preserved. Only a minimum amount of centralization or forced cooperation will be tolerated by the community as a whole 💜. Hard pass on the big-brain central boss.
We also believe this decoupled nature has some tangible benefits. For example,
- It is easier to experiment with new protocols and services and then roll out intermediate and final results in a controlled fashion. 🧪
- By eliminating a single point of control, a single point of failure is also eliminated, making it much less likely that the entire network will fail. 🛟
- It allows the administrative tasks for the network to be more widely distributed. 📋
An example of the benefits of this "Cooperative Anarchy" can be seen in the benefits derived from using the Domain Naming System over the original HOSTS.TXT system. It's giving main character energy 👑
5. Criteria 📋
this section lists the criteria we suggest the IP The Next Generation proposals be evaluated against 🧐.
Each criterion gets its own section. The first paragraph of each one is a short, one or two sentence statement of the criterion. The additional paragraphs then explain it in more detail, clarify what it does and does not say, and give some indication of its relative importance.
Each criterion also includes a subsection called "Time Frame". This is meant to give a rough idea of when the authors believe the criterion will become "important" ⏰. We believe that if an element of technology is significant enough to include in this document, then we probably understand it well enough to predict how important it will be. In general, these time frames mean that, within the desired time frame, we should be able to get an understanding of how the feature will be added to a protocol, perhaps after discussions with the engineers doing the development. Time Frame is not a deployment schedule, though, since deployment schedules depend on non-technical issues, like vendors figuring out whether a market exists, users fitting new releases into their systems, and so on 🙃.
5.1 Scale 📏
CRITERION 🎯
The IPng Protocol must scale to allow the identification and addressing of at least 10**12 end systems (and preferably much more). The IPng Protocol, and its associated routing protocols and architecture must allow for at least 10**9 individual networks (and preferably more). The routing schemes must scale at a rate that is less than the square root of the number of constituent networks [10].
DISCUSSION 💬
The initial, motivating purpose of IPng is to let the Internet grow beyond the size constraints imposed by the current IPv4 addressing and routing technologies 🚀.
Both aspects of scaling matter. If we can't route, connecting all these hosts is worthless, but without connected hosts there's no point in routing, so we must scale in both directions 🔁.
In any proposal, particular attention must be paid to describing the routing hierarchy, how the routing and addressing will be organized, how the different layers of routing interact, and the relationship between addressing and routing 🗺️.
Particular attention must also be paid to describing what happens when the size of the network approaches these limits. How are network, forwarding, and routing performance affected? Does performance fall off, or does the network simply stop as the limit is neared? 😬
This criterion is the essential problem motivating the transition to IPng. If the proposed protocol does not satisfy this criterion, there is no point in considering it 💀.
We note that one of the white papers solicited for the IPng process [5] indicates that 10**12 end nodes is a reasonable estimate, based on the expected number of homes in the world and adding two orders of magnitude for "safety". However, this white paper treats each home in the world as an end-node of a world-wide Internet. We believe that each home in the world will in fact be a network of the world-wide Internet. Therefore, if we take [5]'s derivation of 10**12 as accurate, and change their assumption that a home will be an end-node into a home being a network, we may expect that there will be the need to support at least 10**12 networks, with the possibility of supporting up to 10**15 end-nodes 🏠🌍.
Time Frame
any IPng proposal should be able to show immediately that it has an architecture for the needed routing protocols, addressing schemes, abstraction techniques, algorithms, data structures, and so on, that can support growth to the required scales 📐.
Actual development, specification, and deployment of the needed protocols can be deferred until IPng deployment has extended far enough to require such protocols. A proposed IPng should be able to demonstrate ahead of time that it can scale as needed 🔮.
5.2 Topological Flexibility 🕸️
CRITERION 🎯
The routing architecture and protocols of IPng must allow for many different network topologies. The routing architecture and protocols must not assume that the network's physical structure is a tree 🌳🙅♀️.
DISCUSSION 💬
As the Internet becomes ever more global and ubiquitous, it will develop new and different topologies 🌐. We already see cases where the network hierarchy is very "broad", with many subnetworks each with only a few hosts, and where it is very "narrow", with few subnetworks each with many hosts. We can expect these and other topological forms in the future. Furthermore, since we expect IPng will allow for many more levels of hierarchy than IPv4 allows, we can expect very "tall" and very "short" topologies as well 📏✨.
Constituent organizations of the Internet should be allowed to structure their internal topologies in any manner they see fit. Within reasonable implementation limits, organizations should be allowed to structure their addressing in any manner. We specifically want to point out that if the network's topology or addressing is hierarchical, constituent organizations should be able to allocate to themselves as many levels of hierarchy as they wish 🎨.
It is very possible that the diameter of the Internet will grow to be extremely large, perhaps larger than 256 hops 🤯.
Neither the current nor the future Internet will be physically structured as a tree, nor can we assume that connectivity can occur only between certain points in the graph. The routing and addressing architectures must allow for multiply connected networks and be able to utilize multiple paths for any reason, including redundancy, load sharing, and type- and quality-of-service differentiation 🛤️🔀.
Time Frame
we believe Topological Flexibility is an inherent element of a protocol, and therefore should be immediately demonstrable in an IPng proposal 💖.
5.3 Performance ⚡
CRITERION
okay so the bar here is that a state of the art, commercial grade router must be able to process and forward IPng traffic at speeds that fully use common, commercially available, high-speed media of the time 🔥 Plus, at a minimum, a host must be able to get data transfer rates with IPng that are comparable to what IPv4 gets, using similar levels of host resources 💖
DISCUSSION
network media speeds keep going up and up 📈 so the Internet's switching elements (routers) really need to keep up with them 🦋
we only limit this to commercially available routers and media 💅 if a site can buy a media technology "off the shelf," then it should also be able to buy the routing technology "off the shelf." sure, you can always find newer, faster stuff in some lab or research center, but that's not the point 🙈 we do believe IPng should still be routable fast enough to fully use the fastest available media, even if that means specially built, custom devices 🛠️✨
we expect more and more services to show up on the Internet 🌐 so it's not crazy to think the ratio of "local" traffic (traffic that stays on your own local network) to "export" traffic (traffic going to or coming from a network other than your own local network) will shift, and the percent of export traffic will go up 📈💜
also, the host performance requirement should not be read as "IPng only needs to be as good as IPv4." if an IPng candidate can do better than IPv4 with the same resources (or the same transfer rates with fewer resources), that's iconic and so much better 👑 many researchers also think a proper IPng router should be able to route IPng traffic over links at speeds that can fully use an ATM switch on the link 🌸
some developments suggest that very high speed point-to-point connections may become super common 🚀 in particular, [5] says OC-3 speeds may be widely used in the Cable TV Industry, and there may be lots of OC-3 speed lines connecting to central switching elements 📡
processing the IPng header, and the headers after it (like the transport header), can get way more efficient by aligning fields on their natural boundaries and making header lengths whole multiples of typical word lengths (32, 64, and 128 bits have been suggested) 🧚 that way the alignment carries through to the following headers too 🫶
BUT (and this is important, bestie) optimizing the fields and lengths only for today's processors may not be enough for the long term 😭 processor word and cache-line lengths and memory widths keep increasing. when you design the header, you should predict word widths one or two CPU generations into the future and optimize for those 🔮 if IPv4 and TCP had been optimized for the processors that were common when they were designed, they would be super efficient for 6502s and Z-80s 💀
Time Frame
an IPng proposal must give a plausible argument for how it will scale up in performance 🎀 (obviously nobody can fully predict the future 🙈) the idea is to show that if the trends in processor performance and memory performance keep going, and maybe with techniques like parallelism, there's good reason to believe the proposed IPng will scale as technology scales 🌈
5.4 Robust Service 🛡️
CRITERION
the network service and its associated routing and control protocols must be robust 💪
DISCUSSION
Murphy's Law applies to networking 😭 any proposed IPng protocol must be well-behaved when faced with malformed packets, misinformation, and occasional failures of links, routers and hosts 🫠 IPng should also handle willful management and configuration mistakes gracefully (service outages should be minimized) 🩹
another way to put this: IPng must make it possible to keep the Internet tradition of being conservative in what is sent, but liberal in what one is willing to receive 🫶
we note that IPv4 is reasonably robust, and any proposed IPng must be at least as robust as IPv4 💅
hostile attacks on the network layer and Byzantine failure modes must be dealt with in a safe and graceful manner 🥷
we note that Robust Service is, in some form, part of security, and vice-versa 🔐
the detrimental effects of failures, errors, buggy implementations, and misconfigurations must be localized as much as possible 🧯 for example, misconfiguring a workstation's IP Address should not break the routing protocols 🙅♀️ in the event of misconfigurations, IPng must to be able to detect and at least warn, if not work around, any misconfigurations 🚨
due to its size, complexity, decentralized administration, error-prone users and administrators, and so on, the Internet is a very hostile environment 🌪️ if a protocol cannot be used in such a hostile environment, then it is not suitable for use on the Internet 💀
some predictions say that as the Internet grows, and as more and more technically less-sophisticated sites get connected, there will be more failures in the network 📉 part of this is just size: if the size of the network goes up by a factor of n, the total number of failures can be expected to increase by some function of n 🔢 also, as network users become less sophisticated, they will make more innocent, well meaning mistakes, either in configuration or in using their systems 🙈
the IPng protocols should be able to keep operating in an environment that suffers more total outages than we are currently used to 🌧️ similarly, the protocols must protect the general population from errors (either of omission or commission) made by individual users and sites 🫂
Time Frame
we believe the elements of Robust Service should be available immediately in the protocol, with two exceptions 🎀
the security aspects of Robust Service are, in fact, described elsewhere in this document 🔐
protection against Byzantine failure modes is not needed immediately 🙌 a proposed architecture for it should be done immediately, though 📋 prototype development should be completed in 12-18 months, with final deployment as needed ⏳
5.5 Transition 🦋
CRITERION
the protocol must have a straightforward transition plan from the current IPv4 🗺️
DISCUSSION
a smooth, orderly transition from IPv4 to IPng is needed 🫶 if we can't transition to the new protocol, then no matter how wonderful it is, we'll never get to it 😭
we believe a "flag-day" transition, where all hosts and routers have to change over at once, is not possible 🚫 the size, complexity, and distributed administration of the Internet make that kind of cutover impossible 🙃
so IPng will need to co-exist with IPv4 for some time 🤝 there are a few ways to do this, like requiring hosts to support two stacks, converting between protocols, or using backward compatible extensions to IPv4 🧩 every scheme has strengths and weaknesses, and those have to be weighed ⚖️
also, in all probability, there will be IPv4 hosts on the Internet effectively forever 🥹 IPng must provide mechanisms that let these hosts keep communicating, even after IPng has become the dominant network layer protocol 🌸
an absence of a rational, well-defined transition plan is not acceptable 🚫 the difficulty of running a network that is transitioning from IPv4 to IPng must be minimized 🧹 (a good target is that running a mixed IPv4-IPng network should be no more difficult, and preferably less difficult, than running IPv4 in parallel with existing non-IP protocols 🎯)
a network in transition must still be robust too 💪 IPng schemes that maximize stability and connectivity in mixed IPv4-IPng networks are preferred 👑
finally, IPng is expected to evolve over time, so it must be possible for multiple versions of IPng to coexist on the network 🌈 some will be in production use, and some will be experimental, developmental, or for evaluation use 🧪 transition plans must address this issue 📝
the transition plan must address the following general areas of the Internet's infrastructure 🗂️
- Host Protocols and Software
- Router Protocols and Software
- Security and Authentication
- Domain Name System
- Network Management
- Operations Tools (e.g., Ping and Traceroute)
- Operations and Administration procedures
the impact on protocols which use IP addresses as data (e.g., DNS, distributed file systems, SNMP and FTP) must be specifically addressed 🔍
the transition plan should address cost distribution too 💸 that means it should identify which tasks are required of the service providers, of the end users, of the backbones and so on 🧾
Time Frame
a transition plan is required immediately ⏰🎀
5.6 Media Independence ✨
CRITERION 🎀
Okay so the protocol MUST work across an internetwork of many different LAN, MAN, and WAN media, with individual link speeds ranging from a ones-of-bits per second to hundreds of gigabits per second. Multiple-access and point-to-point media MUST be supported, as MUST media supporting both switched and permanent circuits. 💖
DISCUSSION 💅
The best part about IP is that it works over just about anything 🦋 and that generality MUST be preserved. Adding new technologies has to stay easy, and old technologies have to keep working, so that ability MUST be maintained. 🫶
We think this range of speed is right for the next twenty years 🔥, though we may wish to require terabit performance at the high end. At the very least, we expect media running at 500 gigabits per second to be commonly available within 10 years ⭐. The low end of the speed range comes from things like pagers and ELF 🧚 (ELF connects to submerged submarines and has a "speed" on the order of <10 characters per second>). Literally a whole different vibe 💀.
By switched circuits, we mean both "permanent" connections such as X.25 and Frame Relay services AND "temporary" dialup connections similar to today's SLIP and dialup PPP services 🌈, and perhaps ATM SVCs. The temporary kind means dynamic network access is REQUIRED 🙈. That's the ability to unplug a machine, move it to a different point on the network topology, and plug it back in, possibly with a changed IPng address. We note that this is an aspect of mobility 🌸.
By work, we mean we're hoping a stream of IPng datagrams (whether from one source or many) can come close to filling the link at high speeds, while also scaling gracefully to low speeds 🍓.
Lots of network media are multi-protocol, so it's essential that IPng can peacefully co-exist with other protocols on them 🫧. Routers and hosts MUST be able to discriminate among the protocols that might be present on such a medium. For example, on an Ethernet, a specific IPng Ethernet Type value might be called for. Or the old IPv4 Ethernet type gets used, and the first four bits (the version number in the old IPv4 header) tell IPv4 and IPng apart 🎀.
Different media have different MAC address formats and schemes 💜. A node MUST be able to dynamically determine the MAC address of a node, given that node's IP address. We explicitly prohibit using static, manually configured mappings as the standard approach 🚫.
Another part of this criterion is that many different MTUs will show up in an IPng internetwork ✨. IPng MUST be able to operate in such a multi-MTU environment, and it MUST be able to adapt to the MTUs of the physical media it runs over. Two possible techniques are path MTU discovery and fragmentation and reassembly, though other techniques might certainly be developed 🌷.
As of this writing (mid 1994), ATM seems to be set to become a major network media technology 👑. Any IPng SHOULD be designed to operate over ATM. Still, IPng MUST still be able to operate over other, more "traditional" network media 🍭. Also, a host on an ATM network MUST be able to interoperate with a host on another, non-ATM, medium, with no more difficulty or complexity than hosts on different media can manage today using IPv4 🤝.
IPng MUST be able to deal with both "dumb" media, like what we have today, and newer, more intelligent media 🧠. IPng functions MUST be able to exist harmoniously with lower-layer versions of the same, or similar, functions. Routing and resource management are two areas where designers should pay particular attention 🔍. Some subnetwork technologies include integral accounting and billing capabilities, so IPng MUST provide the correct control information to those subnetworks 💸.
Time Frame ⏰
Specifications for current media encapsulations (that is, all encapsulations that are currently Proposed standards, or higher, in the IETF) are REQUIRED immediately 🚀. These specifications MUST include any auxiliary protocols needed, such as an address resolution mechanism for Ethernet or the link control protocol for PPP. A general "guide" SHOULD also be available immediately to help others build additional media encapsulations 📚. Newer encapsulations can be developed as the need becomes apparent 🌟.
Van Jacobson-like header compression SHOULD be shown immediately, as SHOULD any other aspects of very-low-speed media 🐢. Similarly, any specific aspects of high-speed media SHOULD be shown immediately 🏎️.
5.7 Unreliable Datagram Service 🦋
CRITERION 🎀
The protocol MUST support an unreliable datagram delivery service. 💖
DISCUSSION 💅
We're obsessed with IP's datagram service because it works so well 😭, so we MUST keep it. In particular, being able to send an independent datagram within IPv4, without any prearrangement, is extremely valuable. It may even be required for some applications, such as SNMP, and it MUST be retained 🫶.
The design principle that says we can take any datagram and throw it away with no warning or other action, or take any router and turn it off with no warning, and datagram traffic still works, is super powerful 🔥. It vastly enhances the robustness of the network and vastly eases administration and maintenance. It also vastly simplifies the design and implementation of software [14] 👑.
The Unreliable Datagram Service SHOULD also support some minimal level of service, something approximately equivalent to IPv4 service ✨. This does two jobs. It eases the task of IPv4/IPng translating systems when they map IPv4 traffic to IPng and back, and it simplifies fitting IPng into small, limited environments like boot ROMs 🧚.
Time Frame ⏰
The Unreliable Datagram Service MUST be available immediately. 🚀
5.8 Configuration, Administration, and Operation 🍓
CRITERION 🎀
The protocol MUST permit easy and largely distributed configuration and operation. Automatic configuration of hosts and routers is REQUIRED 🫧.
DISCUSSION 💅
People complain that IP is hard to manage 😩. We can't plug and play yet, and we MUST fix that problem 🔧.
We do note that fully automated configuration, especially for large, complex networks, is still a research topic 🔬. Our main concern is small and medium sized, less complex networks 🏡, places where the essential knowledge and skills wouldn't be as easy to find.
For this criterion, the proposal SHOULD address address assignment and delegation procedures and restrictions. Also, "ownership" of addresses (for example, by a user or a service provider) has recently become a concern, and that issue SHOULD be addressed 💜.
We require that a node be able to dynamically obtain all of its operational, IP-level parameters at boot time through a dynamic configuration mechanism 🌈. A host MUST be able to dynamically discover routers on its local network. Ideally, the info a host learns this way would also let it make a sensible choice of which first-hop router to send any given packet to 🧭. IPng MUST NOT mandate that users or administrators manually configure first-hop routers into hosts 🙅.
IPng's ability to run on isolated subnets is a real strength of IPv4 🏝️, so IPng hosts MUST be able to work on networks without routers present 🌸.
Additional elements of this criterion are:
- Ease of address allocation.
- Ease of changing the topology of the network within a particular routing domain.
- Ease of changing network provider.
- Ease of (re)configuring host/endpoint parameters such as addressing and identification.
- Ease of (re)configuring router parameters such as addressing and identification.
- Address allocation and assignment authority MUST be delegated as far "down" the administrative hierarchy as possible. 🌳
The requirements of this section apply only to IPng and its supporting protocols (such as for routing, address resolution, and network-layer control). As far as IPng is concerned, we only care about how routers and hosts get their configuration information 🎯.
Automatic configuration of hosts is a huge, complicated problem, and getting config info into hosts and routers is just one small piece of it 🧩. A lot of extra, non-Internet-layer work is needed before we can do "plug-and-play" networking 🛠️. Other pieces include things like autoregistering new nodes with DNS, configuring security service systems (e.g., Kerberos), setting up email relays and mail servers, locating network resources, adding entries to NFS export files, and so on 📬. For the most part, these don't depend on the IPng protocol at all (other than, maybe, the format of addresses) 🙃.
We require that any IPng proposal not impede or prevent, in any way, the development of "plug-and-play" network configuration technologies 🚧.
Automatic configuration of network nodes MUST NOT prevent users or administrators from also manually configuring their systems 🖐️.
Time Frame ⏰
A method for plug and play on small subnets is immediately REQUIRED 🚀.
We believe this is an extremely critical area, because a major complaint across the whole IP community is how hard it is to administer large IP networks 😤. Plus, easy installation is likely to speed up the deployment of IPng 🎉.
5.9 Secure Operation 🔐
CRITERION
IPng must provide a secure network layer. 💅
DISCUSSION
Okay bestie, we need to be sure we didn't accidentally build a network that's a cracker's playground 😭🔥
To meet the Robustness criterion, we need some stuff people usually brush off as "security" 🙈. Think stopping a villain from injecting bogus routing packets and wrecking the routing system inside the network 💀. This criterion covers the security bits that aren't already needed for Robustness.
Non-repudiation of origin is another piece of the security puzzle. To properly support the simple accounting that's expected, we believe it's a necessary feature 🧾✨.
To safely support the needs of the commercial world, IP-level security must be able to stop eavesdroppers from watching traffic and figuring out traffic patterns 👀. This is especially important on multi-access networks like cable TV networks [5] 📺.
Aspects of security at the IP level to be considered include:
- Denial of service protections [6],
- Continuity of operations [6],
- Precedence and preemption [6],
- Ability to allow rule-based access control technologies [6]
- Protection of routing and control-protocol operations [9],
- Authentication of routing information exchanges, packets, data, and sources (e.g., make sure that the routing packet came from a router) [9],
- QOS security (i.e., protection against improper use of network-layer resources, functions, and capabilities),
- Auto-configuration protocol operations in that the host must be assured that it is getting its information from proper sources,
- Traffic pattern confidentiality is strongly desired by several communities [9] and [5].
Time Frame
Security should be an integral component of any IPng from the beginning. 🫶
5.10 Unique Naming 🏷️
CRITERION
IPng must assign all IP-Layer objects in the global, ubiquitous, Internet unique names. These names may or may not have any location, topology, or routing significance. 🧚
DISCUSSION
So we use the term "Name" here the same way the NIMROD proposal uses "End Point Identifier", or the way IP Addresses uniquely identify interfaces and hosts in IPv4. These names may or may not carry any routing or topology information. See [11] if you want more tea on this topic ☕.
IPng must provide identifiers that are suitable for use as globally unique, unambiguous, and ubiquitous names for endpoints, nodes, interfaces, and the like. Every datagram must carry the identifier of both its source and its destination (or some method must be available to determine these identifiers, given a datagram). We believe this is required to support certain accounting functions 🧮.
Other functions and uses of unique names are:
- To uniquely identify endpoints (thus if the unique name and address are not the same, the TCP pseudo-header should include the unique name rather than the address)
- To allow endpoints to change topological location on the network (e.g., migrate) without changing their unique names.
- To give one or more unique names to a node on the network (i.e., one node may have multiple unique names)
An identifier must refer to one and only one object while that object is in existence. Furthermore, after an object ceases to exist, the identifier should be kept unused long enough to ensure that any packets containing the identifier have drained out of the Internet system, and that other references to the identifier have probably been lost. 🧼 We note that "existence" is as much an administrative issue as a technical one. For example, if a workstation is reassigned, given a new IP address and node name, and attached to a new subnetwork, is it the same object or not? 🤔 This does argue for a namespace that is relatively large and relatively stable 🌸.
Time Frame
We see this as a fundamental element of the IP layer, and it should be in the protocol from the beginning. 👑
5.11 Access 📖
CRITERION
The protocols that define IPng, its associated protocols (similar to ARP and ICMP in IPv4) and the routing protocols (as in OSPF, BGP, and RIP for IPv4) must be published as standards track RFCs and must satisfy the requirements specified in RFC1310. These documents 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. 💸🚫
DISCUSSION
An essential part of how the Internet and its protocols grew is that the specs are freely available to anyone who wants a copy 🌈. Beyond just keeping the cost of learning about the tech low, free access made it easy for researchers and developers to pull portions of old protocol specs into revised ones. This kind of easy access to standards documents is required for IPng 🎀.
Time Frame
An IPng and its related protocols must meet these standards for openness before an IPng can be approved. ✅
5.12 Multicast 📡
CRITERION
The protocol must support both unicast and multicast packet transmission. Part of the multicast capability is a requirement to be able to send to "all IP hosts on a given subnetwork". Dynamic and automatic routing of multicasts is also required. 🦋
DISCUSSION
IPv4 has made heavy use of the ability to multicast requests to all IPv4 hosts on a subnet, especially for autoconfiguration. This ability must be retained in IPng 💖.
Unfortunately, IPv4 currently uses the local media broadcast address to multicast to all IP hosts. This behavior is anti-social in mixed-protocol networks and should be fixed in IPng. 🙄 There's no good reason for IPng to send to all hosts on a subnet when it only wishes to send to all IPng hosts. The protocol must make allowances for media that do not support true multicasting.
In the past few years, we've begun to deploy support for wide-area multicast addressing in the Internet, and it has proved valuable 🔥. This capability must not be lost in the transition to IPng.
The ability to restrict the range of a multicast to specific networks is also important. Furthermore, it must be possible to "selectively" multicast packets. That is, it must be possible to send a multicast to a remote, specific portion or area of the Internet (such as a specific network or subnetwork) and then have that multicast limited to just that specific area. Furthermore, any given network or subnetwork should be capable of supporting 2**16 "local" multicast groups, i.e., groups that are not propagated to other networks. See [8].
It should be noted that addressing (specifically the syntax and semantics of addresses) has a great impact on the scalability of the architecture 📈.
Currently, large-scale multicasts are routed manually through the Internet. While that's fine for experiments, a "production" system requires that multicast routing be dynamic and automatic ⚙️. Multicast groups must be able to be created and destroyed, hosts must be able to join and leave multicast groups, and the network routing infrastructure must be able to locate new multicast groups and destinations and route traffic to those destinations, all without manual intervention. 🙌
Large, topologically dispersed, multicast groups (with up to 10**6 participants) must be supported. Some applications are given in [8].
Time Frame
Obviously, address formats and algorithms for processing and interpreting the multicast addresses must be immediately available in IPng. Broadcast and Multicast transmission/reception of packets are required immediately. Dynamic routing of multicast packets must be available within 18 months. ⏳
We believe that Multicast Addressing is vital to support future applications such as remote conferencing 🎥. It's also used quite heavily in the current Internet for things like service location and routing 💜.
5.13 Extensibility 🧩
CRITERION
The protocol must be extensible; 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. IPng is expected to evolve over time. As it evolves, it must be able to allow different versions to coexist on the same network. 🌱
DISCUSSION
We don't know today all of the things we'll want the Internet to be able to do 10 years from now 🔮. At the same time, it isn't reasonable to ask users to switch to a new protocol every decade 😩. So we believe it must be possible to extend IPng to support new services and facilities. It's essential that any extensions can be incrementally deployed to only the systems that want to use them. Systems upgraded this way must still be able to talk to systems that haven't been upgraded 🫶.
There are several aspects to extensibility:
5.13.1 Algorithms
The algorithms used in processing IPng information should be decoupled from the protocol itself. It should be possible to change these algorithms without necessarily requiring protocol, datastructure, or header changes. 🧠
5.13.2 Headers
The content of packet headers should be extensible. As more features and functions are required of IPng, it may be necessary to add more information to the IPng headers. We note that for IPv4, the use of options has proven less than entirely satisfactory, since options have tended to be inefficient to process 🐢.
5.13.3 Data Structures
The fundamental data structures of IPng should not be bound with the other elements of the protocol. E.g., things like address formats should not be intimately tied with the routing and forwarding algorithms, the way the IPv4 address class mechanism was tied to IPv4 routing and forwarding. 🙅♀️
5.13.4 Packets
It should be possible to add additional packet types to IPng. These could be for, e.g., new control and/or monitoring operations. 🛠️
We note that, everything else being equal, having larger, oversized, number spaces is preferable to having number spaces that are "just large enough". Larger spaces give network designers and operators more flexibility, and allow further experimentation by scientists, engineers, and developers 🧪✨. See [7].
Time Frame
A framework showing mechanisms for extending the protocol must be provided immediately. 🚀
5.14 Network Service ✨
CRITERION
okay bestie, the criterion is that the protocol must allow the network (routers, intelligent media, hosts, and so on) to tag packets with particular service classes and give them the services those classes promise. 💅
DISCUSSION
for lots of reasons, like accounting, security and multimedia, it's desirable to treat different packets differently inside the network. 🎀
multimedia is now on our desktops and it's gonna be an essential part of future networking, so we have to find ways to support it. a failure to support it might push users toward protocols other than IPng 😭
the IETF multicasts have shown we can already support multimedia over internetworks, just with some hitches. if the network can be guaranteed to deliver the service levels this traffic needs, we'll dramatically boost its success 🔥
this criterion covers things like policy-based routing, flows, resource reservation, network service technologies, type-of-service and quality-of-service, and so on 🦋
to properly support commercial provision and use of internetwork service, and to account for it (the economic principle of "value paid for value received" 💖), it must be possible to get guarantees of service levels. and if the network can't keep a previously guaranteed service level, it must report that to whoever it guaranteed the service to. no surprises, periodt 💅
network service provisions must be secure. the network-layer security must generally prevent one host from surreptitiously obtaining or disrupting resources that another host has validly acquired. ⚠️ (some security failures are acceptable, but the failure rate must be very low and should be quantifiable. this part is seriously important, bestie 💀)
one of the parameters of network service that may be requested must be cost-based. 💰
as far as possible, given the limits of the underlying media and IP's model of a robust internet datagram service, real-time, mission-critical applications must be supported by IPng [6]. 👑
users must be able to confirm that they are actually getting the services they requested. 🫶
Time Frame
this should be available within 24 months. 🌈
5.15 Support for Mobility 🦋
CRITERION
the protocol must support mobile hosts, networks and internetworks. 🚀
DISCUSSION
mobility is becoming more and more important, honestly. just look at all the portables everyone is carrying 📱. remember that Apple commercial with someone's Powerbook automatically connecting to her computer back at the office? iconic. there have been a bunch of pilot projects showing ways to support mobility in IPv4, and they all have some drawbacks. but, like network service grades, if we can support mobility, IPng will have features that encourage transition ✨
we're using a super encompassing definition of "mobility" here. people usually mean one of two things: 1) hosts that physically move and stay connected (through some wireless datalink) while sessions and transport-layer connections stay 'open' or 'active', or 2) disconnecting a host from one spot in the network, plugging it back in somewhere else entirely, and carrying on working. both forms are required. 🌸
reference [6] talks about possible future use of IP-based networks on US Navy ships, planes, and shore installations. their basic model is that each ship, plane and shore installation represents at least one IP network. the ship- and plane-based networks are obviously mobile, since the craft move all over the world 🌍. plus, most, if not all, Naval surface combatants carry some aircraft (at minimum, a helicopter or two). so not only must there be mobile networks (the ships that move around), but there must be mobile internetworks too: ships carrying aircraft, where each aircraft has its own network connected to the ship's network, and the whole thing is moving 🚢✈️ main character energy
there's also the need for dynamic mobility. a plane might take off from aircraft carrier A and land on carrier B, so it'd obviously want to "connect" to B's network. it gets even more complex because the plane might want to keep connectivity to its "home" network, meaning it stays connected to the ship-borne networks of both carriers, A and B 🤯
and these needs aren't just for the navy. they apply to the civilian and commercial world too, like civil airliners, commercial cargo and passenger ships, trains, cars and so on 🚗🚆
Time Frame
the mobility algorithms are stabilizing, and we'd hope to see an IPng mobility framework within a year 🥹
5.16 Control Protocol 🛠️
CRITERION
the protocol must include elementary support for testing and debugging networks. 🔍
DISCUSSION
an important feature of IPv4 is ICMP and its debugging, support, and control features. the specific ICMP messages that have proven extraordinarily useful in IPv4 are Echo Request/Reply (a.k.a ping), Destination Unreachable and Redirect. functions similar to these should be in IPng 🏓
this criterion explicitly doesn't concern itself with configuration-related ICMP messages. we believe those are adequately covered by the configuration criterion in this memo 🙈
one limitation of today's ICMP that should be fixed in IPng's control protocol is that more than just the IPng header plus 64 bits of a failed datagram should be returned in the error message. sometimes that's way too little to carry all the critical protocol info that explains why a datagram failed 😩 at minimum, any IPng control protocol should return the entire IPng and transport headers (including options or nested headers). 💜
Time Frame
support for these functions is required immediately ⚡
5.17 Private Networks 🧚
CRITERION
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 internetworks (e.g., CLNP or AppleTalk) must be supported. 🌐
DISCUSSION
in the current Internet, these capabilities are used by the research community to develop new IP services and features (e.g., the MBone), and by users to connect non-IP islands over the Internet (e.g., CLNP and DecNet use in the UK) 🏝️
building networks on top of the Internet has been shown to be really useful. private networks let the Internet get extended and modified in ways that 1) the original builders didn't foresee and 2) don't disrupt the day-to-day operations of other users ✨
we also note that tunneling is widely used in the IPv4 Internet today to provide these capabilities 🚇
finally, there might not be any features that specifically need to be added to IPng to support the desired functions. you could treat a private network protocol simply as another IP client protocol, just like TCP or UDP. if that's the case, then IPng must not prevent these functions from being performed. 🙅♀️
Time Frame
some of these capabilities may be required to support other criteria (e.g., transition), so the timing of the specifications is governed by those other criteria (e.g., immediately in the case of transition). others may be produced as desired. 🗓️
6. Things We Chose Not to Require 💜
this section has items that we felt shouldn't impact the choice of an IPng. listing an item here does not mean a protocol MUST NOT do something. it means the authors don't believe it matters whether the feature is in the protocol or not. if a protocol includes one of these items, that's cool. if it doesn't, that's cool too. a feature might be necessary to meet some other criterion, and our whole point is just that the feature doesn't need to be required for its own sake 🌷
6.1 Fragmentation 🧩
the technology exists for path MTU discovery, and presumably IPng will keep providing it. so we believe that IPng Fragmentation and Reassembly, as provided in IPv4, isn't necessary. fragmentation has been shown to be detrimental to network performance, so we strongly recommend avoiding it 🙅♀️
6.2 IP Header Checksum 🧮
there's been discussion suggesting the IP Checksum doesn't provide enough error protection to be worth its performance impact. the argument is that there's almost always a stronger datalink-level CRC, and end-to-end protection comes from the TCP checksum. so we believe an IPng checksum isn't required per-se 🤷♀️
6.3 Firewalls 🧱
some folks have asked for IPng to include support for firewalls. the authors believe firewalls are one particular solution to the problem of security, so they don't consider firewall support a valid requirement for IPng. (at the same time, we'd hope that no IPng is hostile to firewalls without offering some equivalent security solution 🛡️)
6.4 Network Management 📊
network management properly is a task for additional protocols and standards, like SNMP and its MIBs. we believe network management, per se, isn't an attribute of the IPng protocol. it's viewed as a support, or service, function, so network management should be developed to fit IPng, and not the other way round 🎯
6.5 Accounting 🧾
we believe accounting, like network management, must be designed to fit the IPng protocol, and not the other way round. so accounting, in and of itself, isn't a requirement of IPng. however, there are some facets of the protocol that were specified to make accounting easier, like non-repudiation of origin under security, and the unique naming requirement for sorting datagrams into classes. and remember, a parameter of network service that IPng must support is cost 💸
6.6 Routing 🗺️
Routing is a super critical part of the Internet, no cap. The IETF literally has a whole separate Area chartered to deal only with routing issues 😭. That Area is separate from the more general Internet Area.
We see that routing is also a critical component of IPng 💅. Scaling, Addressing, and Network Services are all intimately entwined with routing. To really stress how important it is, we gave it its own chapter, listing some of the requirements and issues that IPng routing has to deal with. We believe all of these issues fall out of the general criteria from the previous chapter ✨.
6.6.1 Scale 🌍
First and foremost, the routing architecture has to scale up to support a very large Internet 🚀. Current expectations are for an Internet of about 10**9 to 10**12 networks. The routing architecture must be able to handle networks of this size. Even more, it must handle that size without needing massive, global databases and algorithms. Those would basically be single points of failure, which is not robust 💀. And because of the nature of Internet administration (cooperative anarchy), it would be impossible to keep them consistent 🙈.
6.6.2 Policy 📜
Networks, both transit and non-transit, must be able to set their own policies for the types of traffic they will admit 🎀. The routing architecture must make these policies available to the network as a whole. Furthermore, nodes must be able to pick routes for their traffic based on those advertised policies 🦋.
6.6.3 QOS 🚦
A key element of the network service criteria is that different applications want different grades of network service 🌈. It is essential that this service information gets propagated around the network.
6.6.4 Feedback 💬
As users select specific routes to send their traffic over, they must be provided feedback from the routing architecture 🫶. This feedback should let the user figure out whether the desired routes are actually available, whether the desired services are being provided, and so forth.
This would let users modify their service requirements or even change their routes, as needed 🧚.
6.6.5 Stability 🧘♀️
Adding more data into the routing system (routes are based not only on connectivity, as in IPv4, but also on policies, service grades, and so on) means the stability of the routes may suffer 😬. We offer as evidence the early ARPANET, which experimented with load-based routing. Routes would stay in flux, hopping from one saturated link to another, unused, link. Chaotic, honestly 🙃.
This must not be allowed to happen. If anything, routes should be even more stable under IPng's routing architecture than under the current architecture.
6.6.6 Multicast 📡
Multicast will be even more important in IPng than it is today in IPv4 🌸. Multicast groups may be very large and very distributed, and membership in them will be very dynamic. The routing architecture must be able to cope with all of that.
Furthermore, the routing architecture must be able to build multicast routes dynamically, based on factors like group membership, member location, requested and available qualities of service, and so on 👑.
7. References 📚
[1] Internet Architecture Board, "IP Version 7", Draft 8, Work in Progress, July, 1992.
[2] Gross, P., and P. Almquist, "IESG Deliberations on Routing and Addressing", RFC 1380, IESG Chair, IESG Internet AD, November 1992.
[3] Clark, D., Chapin, L., Cerf, V., Braden, R., and R. Hobby, "Toward the Future Internet Architecture", RFC 1287, MIT, BBN, CNRI, USC/Information Sciences Institute, UC Davis, December 1991.
[4] Dave Clark's paper at SIGCOMM '88 where he pointed out that the design of TCP/IP was guided, in large part, by an ordered list of requirements.
[5] Vecchi, M., "IPng Requirements: A Cable Television Industry Viewpoint", RFC 1686, Time Warner Cable, August 1994.
[6] 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.
[7] Bellovin, S., "On Many Addresses per Host", RFC 1681, AT&T Bell Laboratories, August 1994.
[8] Symington, S., Wood, D., and J. Pullen, "Modelling and Simulation Requirements for IPng", RFC 1667, Mitre Corporation and George Mason University, August 1994.
[9] Internet Architecture Board, "Report of the IAB Workshop on Security in the Internet Architecture, RFC 1636, IAB, June 1994.
[10] Private EMAIL from Tony Li to IPNG Directorate Mailing List, 18 April 1994 18:42:05.
[11] Saltzer, J., On the Naming and Binding of Network Destinations", RFC 1498, M.I.T. Laboratory for Computer Science, August 1993.
[12] Postel, J., "Transmission Control Protocol - DARPA Internet Program Protocol Specification", STD 7, RFC 793, DARPA, September 1981.
[13] EMAIL from Robert Elz to the Big Internet mailing list, approximately 4 May 1994.
[14] Chiappa, N., "Nimrod and IPng Technical Requirements", Work in Progress.
8. Security Considerations 🔐
Okay, bestie, this part is serious 😳. Security is not directly addressed by this memo. However, this memo sets the goals for a new generation of network layer protocol, and the security that such a protocol provides is addressed. Security comes up as an issue in several of the requirements stated here. On top of that, a specific requirement for security has been made 🛡️.
9. Acknowledgements 🫶
The authors gratefully acknowledge the assistance and input provided by the many people who have reviewed and commented upon this document. Thank you, legends 💜.
10. Authors' Addresses 💌
Craig Partridge BBN Systems and Technologies 10 Moulton St. Cambridge, MA 02138
EMail: craig@aland.bbn.com
Frank Kastenholz FTP Software, Inc. 2 High St. North Andover, MA, 01845-2620 USA
EMail: kasten@ftp.com
📦 where this page comes from
- ietf: rfc1726 1994-12
- 💖 girlified by claude-haiku-5-5 on : a language model's rewrite of the original, under its terms