RFC 3869
IAB Concerns and Recommendations Regarding Internet Research and Evolution
IAB Concerns and Recommendations Regarding Internet Research and Evolution 🎀
Part 1 of 8 💖
The vibe check (title block) ✨
- RFC: 3869, in the Network Working Group series
- Authors: R. Atkinson, Ed. and S. Floyd, Ed.
- Published by: the Internet Architecture Board (IAB)
- Category: Informational
- Date: August 2004
- Obsoletes / Updates: the header doesn't list any RFCs this one obsoletes or updates 🫶
Status of this Memo 📜
bestie, this memo is just here to give information to the Internet community 🧚 It does not specify an Internet standard of any kind. Distribution of it is unlimited, so share away 💅
Copyright Notice ©️
Copyright (C) The Internet Society (2004).
Abstract 🌸
okay so this doc talks about how the IAB is worried that Internet research has to keep going to help the Internet infrastructure evolve, and that it needs steady, sufficient non-commercial funding to make that happen 🔥 literally the whole point in one breath.
Table of Contents 📚
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 2
1.1. Document Organization. . . . . . . . . . . . . . . . . . 2
1.2. IAB Concerns . . . . . . . . . . . . . . . . . . . . . . 3
1.3. Contributions to this Document . . . . . . . . . . . . . 4
2. History of Internet Research and Research Funding. . . . . . . 4
2.1. Prior to 1980. . . . . . . . . . . . . . . . . . . . . . 4
2.2. 1980s and early 1990s. . . . . . . . . . . . . . . . . . 5
2.3. Mid-1990s to 2003. . . . . . . . . . . . . . . . . . . . 6
2.4. Current Status . . . . . . . . . . . . . . . . . . . . . 6
3. Open Internet Research Topics. . . . . . . . . . . . . . . . . 7
3.1. Scope and Limitations. . . . . . . . . . . . . . . . . . 7
3.2. Naming . . . . . . . . . . . . . . . . . . . . . . . . . 8
3.2.1. Domain Name System (DNS). . . . . . . . . . . . 8
3.2.2. New Namespaces. . . . . . . . . . . . . . . . . 9
3.3. Routing. . . . . . . . . . . . . . . . . . . . . . . . . 9
3.3.1. Inter-domain Routing. . . . . . . . . . . . . . 10
3.3.2. Routing Integrity . . . . . . . . . . . . . . . 11
3.3.3. Routing Algorithms. . . . . . . . . . . . . . . 12
3.3.4. Mobile and Ad-Hoc Routing . . . . . . . . . . . 13
3.4. Security . . . . . . . . . . . . . . . . . . . . . . . . 13
3.4.1. Formal Methods. . . . . . . . . . . . . . . . . 14
3.4.2. Key Management. . . . . . . . . . . . . . . . . 14
3.4.3. Cryptography. . . . . . . . . . . . . . . . . . 15
3.4.4. Security for Distributed Computing. . . . . . . 15
3.4.5. Deployment Considerations in Security . . . . . 15
3.4.6. Denial of Service Protection. . . . . . . . . . 16
3.5. Network Management . . . . . . . . . . . . . . . . . . . 16
3.5.1. Managing Networks, Not Devices. . . . . . . . . 16
3.5.2. Enhanced Monitoring Capabilities. . . . . . . . 17
3.5.3. Customer Network Management . . . . . . . . . . 17
3.5.4. Autonomous Network Management . . . . . . . . . 17
3.6. Quality of Service . . . . . . . . . . . . . . . . . . . 17
3.6.1. Inter-Domain QoS Architecture . . . . . . . . . 18
3.6.2. New Queuing Disciplines . . . . . . . . . . . . 19
3.7. Congestion Control . . . . . . . . . . . . . . . . . . . 19
3.8. Studying the Evolution of the Internet Infrastructure. . 20
3.9. Middleboxes. . . . . . . . . . . . . . . . . . . . . . . 21
3.10. Internet Measurement . . . . . . . . . . . . . . . . . . 21
3.11. Applications . . . . . . . . . . . . . . . . . . . . . . 22
3.12. Meeting the Needs of the Future. . . . . . . . . . . . . 22
3.13. Freely Distributable Prototypes. . . . . . . . . . . . . 23
4. Conclusions. . . . . . . . . . . . . . . . . . . . . . . . . . 23
5. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 23
6. Security Considerations. . . . . . . . . . . . . . . . . . . . 24
7. Informative References . . . . . . . . . . . . . . . . . . . . 24
8. Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 29
9. Full Copyright Statement . . . . . . . . . . . . . . . . . . . 301. Introduction 💫
bestie, this doc covers the history of funding for Internet research, is worried about where that funding is at right now, and points out a few specific research areas the IAB thinks deserve more attention 🦋 Current funding levels for Internet research are not generally adequate, and several important research areas are seriously underfunded. This has to get fixed so the Internet can keep evolving and developing. It's giving urgent 😭
1.1. Document Organization 🗂️
so the first part is a high-level look at the history of Internet research funding, just to give some background context ✨ Early funding came mostly from the U.S. government. Then in the second half of the 1990s there was a stretch of commercial funding plus funding from several governments. Lowkey though, commercial funding for Internet research has been cut back because of the recent economic downturn 📉
The second part is an incomplete list of open Internet research topics 🍓 These are only examples, meant to show how wide the open research topics are. This section backs up the main idea that ongoing research is needed to keep the Internet infrastructure evolving. That includes research on the medium-time-scale evolution of the Internet infrastructure, as well as research on longer-time-scale grand challenges. It also covers lots of research issues that the Internet research community is already actively looking into 🔥
Areas covered in this section include naming, routing, security, network management, and transport. Issues that need more research also include more general architectural stuff like layering and communication between layers. General topics in this section also include modeling, measurement, simulation, test-beds, etc. We're focusing on topics related to the IETF and IRTF (Internet Research Task Force) agendas. (For example, Grid issues are not discussed in this document because they are addressed through the Global Grid Forum and other Grid-specific organizations, not in the IETF.) 🙈
Wherever possible, the examples in this document point to separate documents on these issues, and only give a high-level summary of what those documents raise 💅
1.2. IAB Concerns 🌈
In the aftermath of September 11 2001, governments seem to have renewed their interest in funding research on Internet-related security issues. From [Jackson02]: "It is generally agreed that the security and reliability of the basic protocols underlying the Internet have not received enough attention because no one has a proprietary interest in them".
That quote gets at a key issue in funding for Internet research. Because no single organization (e.g., no single government, software company, equipment vendor, or network operator) feels like it owns the global Internet infrastructure, research on the general issues of that infrastructure often isn't adequately funded 🥺 In our current challenging economic climate, it's not surprising that commercial funding sources are more likely to fund research that leads to a direct competitive advantage 💀
The main thesis of this document is that if commercial funding is the main source of funding for future Internet research, the future of the Internet infrastructure could be in trouble 🚨 Besides which projects get funded, the funding source can also shape the content of the research, for example, toward or against the development of open standards, or with varying degrees of care about how the developed protocols affect other traffic on the Internet 👀
At the same time, lots of significant networking research contributions have come from commercial funding ✨ However, for most of the topics in this document, relying only on commercially-funded research would not be adequate. Much of today's commercial funding is focused on technology transition, taking results from non-commercial research and putting them into shipping commercial products. We haven't tried to dig into each research issue below to discuss the potentials and limitations of commercial funding in that particular area.
On a more practical note, if there were no commercial funding for Internet research, then few research projects would be taken all the way to completion with implementations, deployment, and follow-up evaluation 🛠️
Is there theoretically a possibility of too much funding for Internet research? Sure, but that is far from the current problem 🙄 There's also a lot that could be done within the network research community to make Internet research more focused and productive, but that would belong in a separate document 🧚
1.3. Contributions to this Document 🫶
A bunch of people directly contributed text to this document. Following current conventions, though, the official RFC author list only includes the key editors 💖 The Acknowledgements section at the end thanks the other people who contributed in some form.
2. History of Internet Research and Research Funding 🕰️
2.1. Prior to 1980 📼
Most of the early research into packet-switched networks was sponsored by the U.S. Defense Advanced Research Projects Agency (DARPA) [CSTB99]. That includes the initial design, implementation, and deployment of the ARPAnet, which connected several universities and other DARPA contractors. The ARPAnet originally came online in the late 1960s. It grew in size during the 1970s, still mostly with DARPA funding, and showed how useful packet-switched networking could be 🎀
DARPA funding for Internet design started in 1973, just four years after the initial ARPAnet deployment. That support was one result of earlier DARPA funding for packet radio and packet satellite research. Having multiple networks (ARPAnet, packet radio, and packet satellite) created the need for internetworking research 🌸 So the Internet arose largely as a consequence of DARPA research funding for those three networks. It did not arise only incidentally from the commercially-funded work at Xerox PARC on Ethernet 👑
2.2. 1980s and early 1990s 🌸
okay so the ARPAnet switched over to the Internet Protocol (IP) on January 1, 1983 🦋, which is approximately 20 years before this document was written. lowkey wild. Throughout the 1980s the U.S. Government kept pouring strong research and development funding into Internet tech 💰. DARPA stayed the key funding source, but it got backup from other DoD (U.S. Department of Defense) funding 💅 (e.g., via the Defense Data Network (DDN) program of the Defense Communication Agency (DCA)) and other U.S. Government funding too (e.g., U.S. Department of Energy (DoE) funding for research networks at DoE national laboratories, and (U.S.) National Science Foundation (NSF) funding for academic institutions). That money covered basic research, applied research (including freely distributable prototypes), buying IP-capable products, and operating support for IP-based government networks like ARPAnet, ESnet, MILnet, the NASA Science Internet, and NSFnet 🔥.
During the 1980s the U.S. DoD wanted to step back from running operational network services for academic institutions 🙈, so funding for most academic activities moved over to the NSF during the decade. NSF's first move was sponsoring CSnet in 1981 🎀. By 1986 NSF was also sponsoring networking research projects (e.g., Mills' work on Fuzzballs) 🧚. In the late 1980s NSF created the NSFnet backbone 🌈, sponsored several NSF regional networks (e.g., SURAnet), and set up interconnections with several international research networks ⭐.
Okay, but here's the important bit 📝: NSF's sponsorship was focused on achieving core NSF goals, like connecting scientists at leading universities to NSF supercomputing centers. The needs of high-performance remote access to supercomputers drove the overall NSFnet performance. As a side effect, students and faculty at those universities got a relatively high-performance Internet environment 😭. As those students graduated, they drove both commercial use of the Internet and the nascent residential market. It is no accident that this was the environment the world wide web emerged from 🫶.
Most research funding outside the U.S. during the 1980s and early 1990s was focused on the ISO OSI networking project or on then-new forms of network media (e.g., wireless, broadband access) 📡. The European Union was a significant source of research funding for the networking community in Europe during this period 🇪🇺. Some of the best early work in gigabit networking was undertaken in the UK and Sweden 👑.
2.3. Mid-1990s to 2003 🌷
Starting in the middle 1990s, U.S. Government funding for Internet research and development got seriously reduced 📉. The premise was that the growing Internet industry would pay for whatever research and development was needed. Some funding kept coming from European and Asian organizations during this period (e.g., the WIDE Project in Japan [WIDE]) 🌏. Reseaux IP Europeens [RIPE] is an example of market-funded networking research in Europe during this period 💜.
Experience during this period has shown that commercial firms have often focused on donating equipment to academic institutions and promoting somewhat vocationally-focused educational projects 🎓. Many of the commercially-funded research and development projects appear to have been selected because they looked likely to give the funding source a specific short-term economic advantage over its competitors 🤑. Higher risk, more innovative research proposals generally have not been funded by industry 🥲. A common view in Silicon Valley has been that established commercial firms are not very good at transitioning cutting edge research into products, but were instead good at buying small startup firms who had successfully transitioned such cutting edge research into products 🚀. Unfortunately, small startup companies are generally unable financially to fund any research themselves 💀.
2.4. Current Status 🦋
The result of reduced U.S. Government funding and profit-focused, low-risk, short-term industry funding has been a decline in higher-risk but more innovative research activities 📉. Industry has also been less interested in research to evolve the overall Internet architecture, because that work doesn't translate into a competitive advantage for the firm funding it 🙃.
The IAB believes that it would be helpful for governments and other non-commercial sponsors to increase their funding of both basic research and applied research relating to the Internet, and to sustain these funding levels going forward 🫶.
3. Open Internet Research Topics 🔎
This section mainly talks about some specific topics the IAB thinks merit additional research ✨. Research, of course, isn't just devising a theory, algorithm, or mechanism to accomplish a goal. It also means evaluating the general efficacy of the approach, and then the benefits vs. the costs of deploying that algorithm or mechanism 🧠. Important cautionary notes about this discussion are given in the next sub-section ⚠️. This particular set of topics is not meant to be comprehensive, but instead is meant to show off the breadth of open Internet research questions 🌈.
Other discussions of problems of the Internet that merit further research include the following: [CIPB02,Claffy03a,Floyd,NSF03a,NSF03b].
3.1. Scope and Limitations 🧚
This document is NOT intended as a guide for public funding agencies as to exactly which projects or proposals should or should not be funded 🙅♀️.
In particular, this document is NOT intended to be a comprehensive list of all of the research questions that are important to further the evolution of the Internet. That would be a daunting task, and would presuppose a wider and more intensive effort than we have undertaken in this document 😮💨.
Similarly, this document isn't meant to list the research questions that are judged to be only of peripheral importance, or to survey the current (global; governmental, commercial, and academic) avenues for funding for Internet research, or to make specific recommendations about which areas need additional funding 📚. The purpose of the document is to persuade the reader that ongoing research is needed towards the continued evolution of the Internet infrastructure 💖. The purpose is not to make binding pronouncements about which specific areas are and are not worthy of future funding.
Not making binding pronouncements is the whole point, bestie. This doc is a nudge, not a rulebook 🫣.
For some research clearly relevant to the future evolution of the Internet, there are grand controversies between competing proposals or competing schools of thought 🥊. It is not the purpose of this document to take positions in these controversies, or to take positions on the nature of the solutions for areas needing further research 🤐.
That all carefully noted, the rest of this section discusses a broad set of research areas, noting a subset of particular topics of interest in each one 🌸. Again, this list is NOT comprehensive. It's meant to suggest that a broad range of ongoing research is needed, and to propose some candidate topics 🍓.
3.1.1. Terminology 📖
Several places in this document refer to 'network operators'. By that term, we intend to include anyone or any organization that operates an IP-based network. We are not using that term in the narrow meaning of commercial network service providers 💅.
3.2. Naming 🏷️
The Internet currently has several different namespaces, including IP addresses, sockets (specified by the IP address, upper-layer protocol, and upper-layer port number), Autonomous System (AS) number, and the Fully-Qualified Domain Name (FQDN) 🗂️. Many of the Internet's namespaces are supported by the widely deployed Domain Name System [RFC-3467] or by various Internet applications [RFC-2407, Section 4.6.2.1].
3.2.1. Domain Name System (DNS) 🧃
The DNS system, while it works well given its current constraints, has several stress points 😬.
The current DNS system relies on UDP for transport, rather than SCTP or TCP. Given the very large number of clients using a typical DNS server, it is desirable to minimize the state on the DNS server side of the connection. UDP does this well, so it is a reasonable choice, though this has other implications, for example a reliance on UDP fragmentation 🫠. With IPv6, intermediate fragmentation is not allowed and Path MTU Discovery is mandated. However, the amount of state required to deploy Path MTU Discovery for IPv6 on a DNS server might be a significant practical problem 🤯.
One implication of this is that research into alternative transport protocols, designed more for DNS-like applications where there are very many clients using each server, might be useful 🦄. Of particular interest would be transport protocols with little burden for the DNS server, even if that increased the burden somewhat for the DNS client 🎯.
Additional study of DNS caching, both currently available caching techniques and also potential new caching techniques, might help find ways to reduce the offered load for a typical DNS server 📉. In particular, examining DNS caching through typical commercial firewalls might be interesting if it led to alternative firewall implementations that were less of an obstacle to DNS caching 🔥.
The community lacks a widely-agreed-upon set of metrics for measuring DNS server performance. It would be helpful if people would seriously consider what characteristics of the DNS system should be measured 📏.
Some in the community would advocate replacing the current DNS system with something better. Past attempts to devise a better approach have not yielded results that persuaded the community to change 🙈. Proposed work in this area could be very useful, but might require careful scrutiny to avoid falling into historic design pitfalls 🕳️.
With regards to DNS security, major technical concerns include finding practical methods for signing very large DNS zones (e.g., and tools to make it easier to manage secure DNS infrastructure 🔐.
Most users are unable to distinguish a DNS-related failure from a more general network failure. Hence, maintaining the integrity and availability of the Domain Name System is very important for the future health of the Internet 💜🌐.
3.2.2. New Namespaces 🌌
Additionally, the Namespace Research Group (NSRG) of the Internet Research Task Force (IRTF) studied adding one or more additional namespaces to the Internet Architecture [LD2002]. Many members of the IRTF NSRG believe there would be significant architectural benefit to adding one or more additional namespaces to the Internet Architecture 🧩. Because smooth consensus on that question, or on the properties of a new namespace, was not obtained, the IRTF NSRG did not make a formal recommendation to the IETF community regarding namespaces 🤷♀️. The IAB believes that this is an open research question worth examining further 🔍.
Finally, we believe that future research into the evolution of Internet-based distributed computing might well benefit from studying the addition of new namespaces as part of a new approach to distributed computing ✨.
3.3. Routing 🛣️
Okay so the routing system we've got rn works pretty well for most people 💖 but ngl the unicast routing architecture is kinda suboptimal in a bunch of spots: end-to-end convergence times in global-scale catenets (a system of networks interconnected via gateways); the ability of the existing inter-domain path-vector algorithm to scale well beyond 200K prefixes; the ability of both intra-domain and inter-domain routing to use multiple metrics and multiple kinds of metrics concurrently; and the ability of IPv4 and IPv6 to support widespread site multi-homing without undue adverse impact on the inter-domain routing system. Policy is ALSO a whole thing, for both intra-domain and inter-domain routing 🙈. Routing policy is directly tied to money for network operators, so the applied research should ideally look at economics as well as the technical stuff. Main character energy for real 💅
This one has clear commercial interest, but it's giving "unlikely to get solved by commercial research funding" unless there's some kind of consortium 🫶
3.3.1. Inter-domain Routing 🌍
The current operational inter-domain routing system has somewhere between 150,000 and 200,000 routing prefixes in the default-free zone (DFZ) [RFC-3221]. ASIC technology handles the worry about forwarding packets at super high speeds ⚡ and it also handles the worry about how long longest-prefix-match computations take ✨. BUT some senior folks in the Internet routing community are worried that end-to-end convergence might hit fundamental algorithmic limits (not hardware limits, algorithmic ones 😭) once the DFZ is somewhere between 200,000 and 300,000 prefixes. Researching whether that worry is actually well-founded in scientific terms feels very timely 🦋
Separately from that, recent work showed there can be significant BGP convergence issues today. Right now it looks like the convergence issues we're seeing come from how network operators have configured BGP, and NOT from some kind of fundamental algorithmic problem [MGVK02]. This convergence time issue makes the apparent network outage way longer than it should be 💀. More applied research into which parts of a BGP configuration hit convergence times the hardest would help fix the operational problems we're seeing now 🌸
Also, inter-domain routing currently needs a ton of human engineering of specific inter-AS paths so that reasonably optimal paths get used by real traffic. Ideally the inter-domain routing system would pick reasonably optimal paths all on its own 🧚. Recent work suggests better BGP policy mechanisms might help make sure reasonably optimal paths are normally the ones used for inter-domain IP traffic [SMA03]. Continued applied research here could lead to much better technical approaches 👑
The current approach to site multi-homing has a seriously undesirable side effect: it significantly increases the growth rate of prefix entries in the DFZ, because it gets in the way of prefix aggregation 😩. We need research into new routing architectures that can support large-scale site multi-homing without the bad effects on inter-domain routing that the current multi-homing technique has.
BGP was originally built for inter-domain routing, mostly inside service provider networks but also with some use by multi-homed sites 🎀. Now some people are trying to use BGP in other contexts too, like highly mobile environments, where it's way less obviously a good fit 🙈. Research into inter-domain routing and/or intra-domain policy routing might lead to other approaches for emerging environments where BGP isn't the best option anymore 🦋
3.3.2. Routing Integrity 🔐
There's been more awareness lately of the longstanding problem of getting strong authentication into the Internet inter-domain routing system, and it's a big deal 🫣. The routing mechanisms we actually use today (like BGP TCP MD5 [RFC-2385], OSPF MD5, and RIP MD5 [RFC-2082]) give cryptographic authentication for routing protocol messages, but NO authentication of the actual routing data 😭. Recent proposals (like S-BGP [KLMS2000]) for fixing that in inter-domain routing look hard to deploy across the Internet, partly because they rely on a single trust hierarchy (like a single PKI) 🥺. Similar proposals for intra-domain routing (like OSPF with Digital Signatures, [RFC-2154]) are argued to be computationally infeasible to deploy in a large network 🧮
Here's the recurring challenge with any kind of inter-domain routing authentication: there's no single completely accurate source of truth about which organizations are allowed to advertise which address blocks 🤷♀️. So we need to develop alternative ways to authenticate routing system data 💖. Being able to do partial authentication of routing data would be a huge help, because it would make it easier to roll out routing authentication mechanisms bit by bit 🌈. Also, non-hierarchical trust models (like the web of trust used in the PGP application) might make incremental deployment easier and might also address worries about centralized administration of the routing system. That's why it deserves more study and consideration ✨
3.3.3. Routing Algorithms 🧮
The current Internet routing system mainly relies on two algorithms. Link-state routing uses the Dijkstra algorithm [Dijkstra59]. Distance-Vector routing (like RIP) and Path-Vector routing (like BGP) use the Bellman-Ford algorithm [Bellman1957, FF1962]. More basic research into graph theory as applied to routing is worth doing 🕸️, and it might produce algorithms that enable a new routing architecture or otherwise improve the routing system 💜
Currently deployed multicast routing relies on the Deering RPF algorithm [Deering1988]. Ongoing research into alternative multicast routing algorithms and protocols might help ease current concerns about how well multicast routing scales 🌟
The deployed Internet routing system assumes the shortest path is always the best path. This is provably false 💀, but it's a reasonable compromise given the routing protocols we have available right now 🫠. The Internet doesn't have deployable approaches for policy-based routing or for routing with alternative metrics (meaning some metric other than the number of hops to the destination) 😤. Examples of alternative policies include: the path with the lowest monetary cost; the path with the lowest probability of packet loss; the path with minimized jitter; and the path with minimized latency 🍓. Policy metrics also need to take business relationships into account. Historic work on QoS-based routing mostly didn't work out, partly because it didn't adequately consider the economic and commercial side of the routing system, and partly because it didn't adequately consider security implications 🥀
Moving from the current inter-domain routing system to any new one is unlikely to be a trivial exercise 😮💨. So any proposal for a new routing system needs to carefully consider and document deployment strategies, transition mechanisms, and other operational considerations 📝. Because inter-domain routing is all about crossing domains and interoperating, smooth transitions away from one inter-domain routing system are likely to be really hard to pull off 🫣. Separately, the inter-domain routing system doesn't have strong market forces pushing people to migrate to better technical approaches. So it seems unlikely the commercial sector will be where a significantly improved inter-domain routing system comes from 🥹
3.3.4. Mobile and Ad-Hoc Routing 📡
Some of the earliest DARPA-sponsored networking research was about packet radio networks, but mobile routing [IM1993] and mobile ad-hoc routing [RFC-2501] are pretty recent arrivals on the Internet, and they aren't widely deployed yet 🌙. The current approaches are NOT the last word in either of those areas 🙅♀️. We believe more research into routing support for mobile hosts and mobile networks is needed. More research for ad-hoc mobile hosts and mobile networks is also worth doing. Ideally, mobile routing and mobile ad-hoc routing should be native, built-in capabilities of the Internet routing architecture 🛸. This will probably take a big evolution from the existing Internet routing architecture 🦋. (NB: "mobility" here isn't just about mobile phones 📱. It's defined super broadly, including laptops people carry around, cars, trains, aircraft, and so forth ✈️🚗🚆)
This topic covers a whole bunch of issues 😵💫. The more distributed and dynamic nature of partially or completely self-organizing routing systems (including the end nodes associated with them) creates unique security challenges, especially around Authorization, Authentication, and Accounting, and around key management 🔑. Scalability of wireless networks can be hard to measure or to achieve. Enforced hierarchy is one approach, but it can be super limiting 🙃. So less constraining approaches to wireless scalability are wanted 💫. Wireless link-layer protocols usually know something about current link characteristics, like link quality, sublayer congestion conditions, or transient channel behavior 📶. So it's desirable to find ways to let network-layer routing use that data too. That raises architectural questions about what the proper layering should be and which functions belong in which layer 🧩, plus practical questions about how and when this kind of information sharing should happen in real implementations 🛠️
3.4. Security 🛡️
The Internet has a reputation for not having enough security, and honestly that reputation is kinda unfair 😤. The Internet does have a number of standardized security mechanisms, and some of them are widely deployed ✅. BUT there are still a bunch of open research questions about Internet security 🕵️♀️. The big ones are that security mechanisms need to be incrementally deployable and easy to use 🫶. As Schiller puts it: "[Security] technology must be easy to use, or it will not be configured correctly. If mis-configured, security will be lost, but things will `work'" [Schiller03]. Iykyk, and it's so true 💀🔥
3.4.1. Formal Methods ✨
okay so bestie, we still need funding for basic research on Internet security 💰🔐, including formal methods research on security algorithms, protocols, and systems. no cap, this is foundational stuff.
for example, we'd really benefit from more formal study of non-hierarchical trust models 🕸️, like PGP's Web-of-Trust model. a hierarchical trust model can really limit how we secure parts of the Internet 🙃, like the inter-domain routing system. so research on brand new trust models for the Internet, or on whether existing non-hierarchical ones fit Internet problems, would be seriously worth it 💜.
there's been some work applying formal methods to cryptographic algorithms and cryptographic protocols 🧁, but the existing techniques for formally evaluating algorithms and protocols just aren't automated enough 😩. so a lot of protocols don't get formally evaluated in a timely way, and that's a problem because formal evaluation has often uncovered serious anomalies in cryptographic protocols 😭. building automated tools for applying formal methods to cryptographic algorithms and/or protocols would be so helpful 🫶.
3.4.2. Key Management
the Internet community keeps running into the same big question 🤔: how do we design, implement, and deploy key management that actually fits the huge range of security contexts out there? most of the current unicast key management work focuses on hierarchical trust models 👑, mostly because it grew out of corporate or military "top-down" operating models 🏢.
the lack of key management methods that work with non-hierarchical trust models (see above) is a major constraint on how we can secure Internet components 🚧.
research that removes those constraints by developing practical key management methods for non-hierarchical trust models would be extremely helpful 🙌.
other topics worth researching include key management techniques like non-hierarchical key management architectures (for supporting non-hierarchical trust models; see above) 🦋. these would be useful for ad-hoc groups in mobile networks and/or distributed computing 📱.
some progress has been made recently, but scalable multicast key management is still far from solved 🥲. existing approaches only work by adding big constraints to the problem scope so they can ship a deployable solution. a more general approach to scalable multicast key management, with broader applicability and fewer constraints, would really level up the Internet's capabilities 🚀.
in lots of cases, attribute negotiation is a key feature of a key management protocol 🎀. experience with the Internet Key Exchange (IKE) so far has shown it's unduly complex 🤯. a lot of IKE's complexity comes from its very general attribute negotiation capabilities. a new key management approach that supports significant attribute negotiation without creating challenging levels of deployment and operations complexity would be a huge win 🏆.
3.4.3. Cryptography
we need to keep funding open-world research in both cryptography and cryptanalysis 🌍. most governments put their cryptographic research into the military sector 🪖. that's understandable, but those efforts often have limited (or no) publications in the open literature 📕. the Internet engineering community has to work from the open literature, so open-world research has to keep going in the future 🔮.
3.4.4. Security for Distributed Computing
MIT's Project Athena was an important and broadly successful distributed computing research project 🏛️✨. it developed the Kerberos [RFC-1510] security system, which is still widely deployed in campus environments 🎓. however, inter-realm Kerberos isn't as widely deployed, or seen as widely successful, as single-realm Kerberos 🥺. the need for scalable inter-domain user authentication is getting more urgent as ad-hoc and mobile computing spread 📈. so work on scalable mechanisms for mobile, ad-hoc, and non-hierarchical inter-domain authentication would be very helpful 💖.
3.4.5. Deployment Considerations in Security
lots of work has gone into theoretically perfect security that's impossible to deploy 🙃💀. unfortunately, the S-BGP proposal is a good research product with significant unresolved deployment challenges 😬. it isn't obvious how you'd widely deploy S-BGP without first deploying a large-scale inter-domain public-key infrastructure, and also centralizing route advertisement policy enforcement in the Routing Information Registries or some similar body 🏛️. historically, public-key infrastructures have been either very difficult or impossible to deploy at large scale 😵. security mechanisms that need extra infrastructure haven't been deployed well 📉. we desperately need security that is general, easy to install, and easy to manage 🫠✨.
3.4.6. Denial of Service Protection
historically, the Internet community has mostly ignored pure Denial of Service (DoS) attacks 🙈. that made sense once, since those attacks were rare and hard to defend against 🛡️. but a recent trend in adversarial software (e.g., viruses, worms) is adding features that turn infected hosts into "zombies" 🧟. zombies can be controlled remotely to mount a distributed denial of service attack on some victim machine 💥. in lots of cases, the authorized operators of systems don't know that some or all of their systems have become zombies 😱. it looks like non-trivial numbers of zombies are now endemic in the global Internet, which makes distributed denial of service attacks a much bigger concern 🚨. so Internet threat models need to assume significant numbers of zombies are present 🧠. this makes designing protocols that stay resilient under distributed denial of service attacks super important for the health of the Internet 🩺💜. some work has been done on this front [Savage00], [MBFIPS01], but more is needed 🙏.
3.5. Network Management
the Internet had early success in network device monitoring with the Simple Network Management Protocol (SNMP) and its associated Management Information Base (MIB) 📊. managing whole networks has had comparatively less success than monitoring individual devices 😅. there are also a bunch of operator requirements that the current Internet management framework doesn't support well 🫤. so it's desirable to enhance the current Internet network management architecture so it fully supports operational needs 🛠️.
sadly, network management research has historically been very underfunded 💸. operators have complained that existing solutions are inadequate 😤. research is needed to find better solutions 🔍✨.
3.5.1. Managing Networks, Not Devices
right now there are few or no good tools for managing a whole network instead of isolated devices 🙅♀️. for example, the lack of appropriate network management tools has been named as one of the major barriers to widely deploying IP multicast [Diot00, SM03] 📡. current network management protocols, like the Simple Network Management Protocol (SNMP), are totally fine for reading the status of well-defined objects from individual boxes 📦. managing networks instead of isolated devices means being able to see the network as one big distributed system 🌐. research is needed on scalable distributed data aggregation mechanisms, scalable distributed event correlation mechanisms, and distributed and dependable control mechanisms 🧩.
applied research into ways of managing sets of networked devices seems worthwhile 💅. ideally, that management approach would support distributed management rather than being strictly centralized 🦋.
3.5.2. Enhanced Monitoring Capabilities
SNMP doesn't always scale well for monitoring large numbers of objects across many devices in different parts of the network 😵💫. an alternative worth exploring is scalable, distributed monitoring that works not on individual devices, but on groups of devices and on the network-as-a-whole 🌸. this needs scalable techniques for data aggregation and event correlation of network status data coming from lots of locations in the network 🧚.
3.5.3. Customer Network Management
an open issue in network management is helping users and others identify and resolve problems in the network 🙋♀️. say a user can't access a web page 🥀. it would be so useful if they could easily find out, without having to run ping and traceroute, whether the web server was down 🖥️, whether the network was partitioned due to a link failure 🔌, whether there was heavy congestion along the path 🚗💨, whether the DNS name couldn't be resolved 🔤, whether the firewall blocked the access 🧱, or whether some other specific event happened 🎯.
3.5.4. Autonomous Network Management
more research is needed to improve how automated network management systems are and to localize management 🤖. autonomous network management might involve applying control theory, artificial intelligence, or expert system technologies to network management problems 🧠✨.
3.6. Quality of Service
the research and development work on adding QoS to the Internet architecture has been intense for more than ten years now [RFC-1633, RFC-2474, RFC-3260, RFC-2205, RFC-2210] 📚, and yet we still don't have end-to-end QoS in the Internet [RFC-2990, RFC-3387] 😩. the IETF is great at defining individual QoS mechanisms, but not so great at deployable QoS architectures 🫣. so while Differentiated Services (DiffServ) mechanisms have been standardized as per-hop behaviors 🎀, there's still a lot to learn about deploying that or other QoS mechanisms for end-to-end QoS 🧐. on top of purely technical issues, this includes close attention to the economic models and deployment strategies that would make it easier to deploy more QoS in the network 💰✨.
in many cases, deploying QoS mechanisms would significantly increase operational security risks [RFC-2990] 🚨. so any new research on QoS mechanisms or architectures ought to specifically discuss the potential security issues with the new proposal(s) and how to mitigate them 🛡️💜.
in some cases, demand for QoS mechanisms has dropped because of more resilient voice/video coding techniques 🎤📹. these are better suited for the best-effort Internet than the older coding techniques that were originally designed for circuit-switched networks 🔄.
one thing that's blunted the demand for QoS is how the Internet infrastructure went from heavy congestion in the early 1990s 🚦 to overprovisioning in backbones and in many international links now 🌊. so research in QoS mechanisms also has to carefully consider the relative costs and benefits of QoS in different places in the network ⚖️. applied research into QoS should explicitly consider the economic issues of deploying and operating a QoS-enabled IP network [Clark02] 💖🌈.
3.6.1. Inter-Domain QoS Architecture ✨
okay so bestie, picture a router out on the deployed inter-domain Internet 🌐. by default it just does best-effort forwarding of IP packets, and it doesn't care whether the source or destination is a direct customer of whoever runs that router. no cap, this is a big reason the global Internet can scale so well 💖. but it also makes it kinda hard to roll out inter-domain Quality of Service (QoS) mechanisms 😭.
deploying existing QoS stuff, like Differentiated Services or Integrated Services, across an inter-domain boundary creates a huge, super easy to exploit denial-of-service vulnerability for any network offering inter-domain QoS 💀. that's literally why network operators have been avoiding inter-domain QoS. the Internet would benefit from more research into alternative QoS approaches, especially ones that don't create these vulnerabilities and can be deployed end-to-end [RFC-2990] 🦋.
and ngl the business side is messy too 🙈. current business models don't line up with inter-domain QoS, mostly because it's impractical or impossible to authenticate who's actually sending the would-be preferred traffic while still forwarding at line-rate. without that, it's unclear how an operator could bill for or otherwise recover the costs of the preferred service 💅. so any new inter-domain QoS work needs to carefully consider the economic and security implications of the proposal 👑.
3.6.2. New Queuing Disciplines 🎀
the overall Quality-of-Service for traffic is partly determined by how the routers schedule and manage their queues 🧚. there are a bunch of existing mechanisms (like RED) that work well, but improved active queuing strategies might still be devised 🔥. mechanisms that lower the implementation cost in IP routers might help more folks deploy active queue management, for example 🌸.
3.7. Congestion Control. 🌊
okay so TCP's congestion avoidance and control mechanisms, from 1988 [Jacobson88], have been a key factor in keeping the Internet stable, and the bulk of the Internet's traffic uses them 💜. but congestion control needs to be expanded and modified to handle a wide range of new requirements 😭. think new apps like streaming media and multicast, new environments like wireless networks or very high bandwidth paths, and new requirements for minimizing queueing delay ✨. there's already a lot of solid work on several of these issues, but considerably more needs to be done 💅.
we'd note that research on TCP congestion control is also not yet "done" 🙈. there's still a lot to accomplish in high-speed TCP, and in adding robust performance over paths with significant reordering, intermittent connectivity, non-congestive packet loss, and the like 🫶.
several of these issues raise difficult fundamental questions about the potential costs and benefits of increased communication between layers 🤔. would it help transport to receive hints or other information from routing, from link layers, or from other transport-level connections? if so, what would it cost robust operation across diverse environments? 🧐
for congestion control in routers, active queue management and Explicit Congestion Notification are generally not yet deployed, and there's a range of proposals, in various states of maturity, in this area 🌈. at the same time, there's a ton we still don't understand about how queue management interacts with other factors in the network 💀. router-based congestion control is also needed for detecting and responding to aggregate congestion, like in Distributed Denial of Service attacks and flash crowds 🚨.
as more apps need to transfer very large files over high delay-bandwidth-product paths, the stress on current congestion control raises the question of whether we need more fine-grained feedback from routers 🍓. this includes the challenge of letting connections skip the delays of slow-start and quickly use newly-available bandwidth ⚡. on a bigger level, we don't understand the potential and limitations of best-effort traffic over high delay-bandwidth-product paths, given the current feedback from routers, or the range of possibilities for more explicit feedback 🧠.
there's also a need for long-term congestion control research that's separate from the specific functional requirements above 🔭. we know very little about the congestion control and traffic dynamics of a large, complex network like the global Internet, with its heterogeneous and changing traffic mixes, link-level technologies, network protocols, router mechanisms, congestion patterns, pricing models, and the like 🌍. expanding that knowledge will likely need a rich mix of measurement, analysis, simulations, and experimentation 🧪.
3.8. Studying the Evolution of the Internet Infrastructure 🦖
the evolution of the Internet infrastructure has been frustratingly slow and difficult, with long stories about the struggles of adding IPv6, QoS, multicast, and other functionality 😤. we need a more scientific understanding of the evolutionary potentials and difficulties of the Internet infrastructure 🔬.
this evolutionary potential is shaped not only by the technical issues of the layered IP architecture, but by other factors too 🎭. these include changes in the environment over time (like the recent overprovisioning of backbones and the deployment of firewalls), and the role of the standardization process 📜. economic and public policy factors are critical too, including the central fact that the Internet is a decentralized system, with key players being individuals, ISPs, companies, and entire industries 🏢. deployment issues matter a lot as well, including the endless chicken-and-egg problem of having enough customers to justify rolling out a service whose usefulness depends on how big the customer base is in the first place 🐣.
overlay networks might serve as a transition technology for some new functionality, starting with an initial deployment in overlay networks and moving into the core later if it seems warranted 🪜.
there are also more obstacles to the Internet's evolution in the form of increased complexity [WD02], unanticipated feature interactions [Kruse00], interactions between layers [CWWS92], interventions by middleboxes [RFC-3424], and the like 🌀. because complexity seems inevitable, research is needed to understand architectural mechanisms that can handle increased complexity without decreasing the robustness of performance in unknown environments, and without closing off future possibilities for evolution 🦋. more concretely, research is needed on how to evolve the Internet while still keeping its core strengths, like the current degree of global addressability of hosts, end-to-end transparency of packet forwarding, and good performance for best-effort traffic 💪.
3.9. Middleboxes 📦
research is needed to address the challenges posed by the wide range of middleboxes [RFC-3234] 🧩. this includes issues of security, control, data integrity, and the general impact of middleboxes on the architecture 🛡️.
in many ways middleboxes are a direct outgrowth of commercial interests, but we need to look beyond near-term needs, research their broader implications, and explore ways to improve how middleboxes are integrated into the architecture 🔍.
3.10. Internet Measurement 📊
measuring the Internet is a recurring challenge, and there have been lots of discussions about how measurement studies should be an integral part of Internet research [Claffy03] 📈. in this discussion, we define measurement quite broadly 🌐. for example, there are tons of challenges in measuring performance along any substantial Internet path, especially when the path crosses administrative domain boundaries 🚧. there are also challenges in measuring protocol and application usage on any high-speed Internet link 🏎️. many of the problems discussed above would benefit from more frequent measurement, as well as better quality measurement on the deployed Internet ⏱️.
a key issue in network measurement is that most commercial Internet Service Providers consider the particular characteristics of their production IP network(s) to be trade secrets 🔐. ways need to be found for cooperative measurement studies, for example to let legitimate non-commercial researchers measure relevant network parameters while still protecting the privacy rights of the measured ISPs 🤝.
without measured data, there's possibly an over-reliance on network simulations in some parts of the Internet research community, and probably not enough validation that existing simulation models are reasonably good representations of the deployed Internet (or of some plausible future Internet) [FK02] 🎮.
without solid measurement of current Internet behavior, it's very hard to know what unknown operational problems exist that need attention, and it's equally hard to fully understand the impact of changes (past or future) on the Internet's actual behavioral characteristics 🕵️♀️.
3.11. Applications 📱
research is needed on a wide range of issues related to Internet applications 🎈.
taking email as one example application, research is needed to understand the spam problem, and to investigate tools and techniques that mitigate the effects of spam, including tools and techniques that help implement legal and other non-technical anti-spam measures [ASRG] 📧. "spam" is a generic term for a range of significantly different types of unwanted bulk email, with many kinds of senders, content, and traffic-generating techniques 🗑️. as one part of controlling spam, we need a much better understanding of its many different characteristics and how they interact with each other 🧠.
3.12. Meeting the Needs of the Future 🚀
as network size, link bandwidth, CPU capacity, and the number of users all increase, research will be needed to make sure the Internet of the future scales to meet these growing demands 📈. we've discussed some of these scaling issues in specific sections above 🫶.
however, for all of the research questions discussed in this document, the goal must be not only to meet the challenges we face today, but also the challenges that can be expected to emerge in the future 🔮.
3.13. Freely Distributable Prototypes ✨
okay so the U.S.'s DARPA has historically funded freely distributable versions of Internet tech 🦋 think TCP/IPv4, RSVP, IPv6, and IP security, running on operating systems like 4.2 BSD, 4.3 BSD, 4.4 BSD, and Tenex. bestie, the big lesson here is that a new technology spreads way faster when there's an unencumbered, freely distributable prototype 🚀 that companies can build into commercial products, and that non-commercial prototypes can use too. Japan's WIDE Project has also funded some of this work, mostly on IPv6 for 4.4 BSD and Linux. [WIDE] We believe applied networking research has a better shot at succeeding when the research teams make their software implementations freely available for both commercial and non-commercial use 💅 Some successes that prove the point: DARPA funded TCP/IPv4 integration into the 4.x BSD operating system [MBKQ96], DARPA/USN funded ESP/AH design and integration into 4.4 BSD [Atk96], and separate DARPA/USN and WIDE funding gave us freely distributable IPv6 prototypes [Atk96, WIDE]. the receipts are immaculate 🧾✨
4. Conclusions
okay the vibe check: this document has walked through the history of research funding for the Internet and highlighted some open research questions 🌈 The IAB believes more research is needed to push the evolution of the Internet infrastructure forward, and that consistent, sufficient non-commercial funding is needed to make that research happen 💜
and just so nobody gets confused 🙈 this document is NOT suggesting any direct or indirect role for the IAB, the IETF, or the IRTF in handling funding for Internet research. not it, not us, not them 💀
5. Acknowledgements
big thank-you energy 🫶 the people who directly contributed to this document in some form include Ran Atkinson, Guy Almes, Rob Austein, Vint Cerf, Jon Crowcroft, Sally Floyd, James Kempf, Joe Macker, Craig Partridge, Vern Paxson, Juergen Schoenwaelder, and Mike St. Johns 👑
we're also grateful to Kim Claffy, Dave Crocker, Michael Eder, Eric Fleischman, Andrei Gurtov, Stephen Kent, J.P. Martin-Flatin, and Hilarie Orman for feedback on earlier drafts of this document 🌸
we also drew from the following reports: [CIPB02,IST02,NV02,NSF02,NSF03,NSF03a] 📚
6. Security Considerations
⚠️ okay this one is serious, so listen up 🙈 this document does not itself create any new security issues for the Internet community. however, security issues within the Internet Architecture are mainly discussed in Section 3.4 above, so if you're looking for the real security tea, go there first 🔐 it's giving "read the fine print or get hacked" energy, and we love a responsible bestie 🫶
7. Informative References ✨
okay bestie, this is the reading list 📚💅 every source is copied word for word so you can go find the receipts 🔍
[ASRG] Anti-Spam Research Group (ASRG) of the IRTF. URL
"http://asrg.sp.am/".
[Atk96] R. Atkinson et al., "Implementation of IPv6 in 4.4
BSD", Proceedings of USENIX 1996 Annual Technical
Conference, USENIX Association, Berkeley, CA, USA.
January 1996. URL
http://www.chacs.itd.nrl.navy.mil/publications/CHACS/
1996/1996atkinson-USENIX.pdf
[Bellman1957] R.E. Bellman, "Dynamic Programming", Princeton
University Press, Princeton, NJ, 1957.
[Claffy03] K. Claffy, "Priorities and Challenges in Internet
Measurement, Simulation, and Analysis", Large Scale
Network meeting, (US) National Science Foundation,
Arlington, VA, USA. 10 June 2003. URL
"http://www.caida.org/outreach/
presentations/2003/lsn20030610/".
[Claffy03a] K. Claffy, "Top Problems of the Internet and What
Sysadmins and Researchers Can Do To Help", plenary talk
at LISA'03, October 2003. URL
"http://www.caida.org/outreach/presentations/
2003/netproblems_lisa03/".
[Clark02] D. D. Clark, "Deploying the Internet - why does it take
so long and, can research help?", Large-Scale
Networking Distinguished Lecture Series, (U.S.)
National Science Foundation, Arlington, VA, 8 January
2002. URL: http://www.ngi-
supernet.org/conferences.html
[CSTB99] Computer Science and Telecommunications Board, (U.S.)
National Research Council, "Funding a Revolution:
Government Support for Computing Research", National
Academy Press, Washington, DC, 1999. URL
"http://www7.nationalacademies.org/cstb/
pub_revolution.html".
[CIPB02] Critical Infrastructure Protection Board, "National
Strategy to Secure Cyberspace", The White House,
Washington, DC, USA. September 2002, URL
"http://www.whitehouse.gov/pcipb".
[CWWS92] J. Crowcroft, I. Wakeman, Z. Wang, and D. Sirovica, "Is
Layering Harmful?", IEEE Networks, Vol. 6, Issue 1, pp
20-24, January 1992.
[Diot00] C. Diot, et al., "Deployment Issues for the IP
Multicast Service and Architecture", IEEE Network,
January/February 2000.
[Deering1988] S. Deering, "Multicast Routing in Internetworks and
LANs", ACM Computer Communications Review, Volume 18,
Issue 4, August 1988.
[Dijkstra59] E. Dijkstra, "A Note on Two Problems in Connexion with
Graphs", Numerische Mathematik, 1, 1959, pp.269-271.
[FF1962] L. R. Ford Jr. and D.R. Fulkerson, "Flows in Networks",
Princeton University Press, Princeton, NJ, 1962.
[FK02] S. Floyd and E. Kohler, "Internet Research Needs Better
Models", Proceedings of 1st Workshop on Hot Topics in
Networks (Hotnets-I), Princeton, NJ, USA. October
2002. URL
"http://www.icir.org/models/bettermodels.html".
[IM1993] J. Ioannidis and G. Maguire Jr., "The Design and
Implementation of a Mobile Internetworking
Architecture", Proceedings of the Winter USENIX
Technical Conference, pages 489-500, Berkeley, CA, USA,
January 1993.
[IST02] Research Networking in Europe - Striving for Global
Leadership, Information Society Technologies, 2002.
URL "http://www.cordis.lu/ist/rn/rn-brochure.htm".
[Jacobson88] Van Jacobson, "Congestion Avoidance and Control",
Proceedings of ACM SIGCOMM 1988 Symposium, ACM SIGCOMM,
Stanford, CA, August 1988. URL
"http://citeseer.nj.nec.com/jacobson88congestion.html".
[Jackson02] William Jackson, "U.S. should fund R&D for secure
Internet protocols, Clarke says", Government Computer
News, 31 October 2002. URL
"http://www.gcn.com/vol1_no1/security/20382-1.html".
[Kruse00] Hans Kruse, "The Pitfalls of Distributed Protocol
Development: Unintentional Interactions between Network
Operations and Applications Protocols", Proceedings of
the 8th International Conference on Telecommunication
Systems Design, Nashville, TN, USA, March 2000. URL
"http://www.csm.ohiou.edu/kruse/publications/
TSYS2000.pdf".
[KLMS2000] S. Kent, C. Lynn, J. Mikkelson, and K. Seo, "Secure
Border Gateway Protocol (S-BGP)", Proceedings of ISOC
Network and Distributed Systems Security Symposium,
Internet Society, Reston, VA, February 2000.
[LD2002] E. Lear and R. Droms, "What's in a Name: Thoughts from
the NSRG", expired Internet-Draft, December 2002.
[MBFIPS01] Ratul Mahajan, Steven M. Bellovin, Sally Floyd, John
Ioannidis, Vern Paxson, and Scott Shenker, "Controlling
High Bandwidth Aggregates in the Network", ACM Computer
Communications Review, Vol. 32, No. 3, July 2002. URL
"http://www.icir.org/pushback/".
[MBKQ96] M. McKusick, K. Bostic, M. Karels, and J. Quarterman,
"Design and Implementation of the 4.4 BSD Operating
System", Addison-Wesley, Reading, MA, 1996.
[MGVK02] Z. Mao, R. Govindan, G. Varghese, & R. Katz, "Route
Flap Dampening Exacerbates Internet Routing
Convergence", Proceedings of ACM SIGCOMM 2002, ACM,
Pittsburgh, PA, USA, August 2002.
[NV02] NetVision 2012 Committee,"DARPA's Ten-Year Strategic
Plan for Networking Research", (U.S.) Defense Advanced
Research Projects Agency, October 2002. Citation for
acknowledgement purposes only.
[NSF02] NSF Workshop on Network Research Testbeds, National
Science Foundation, Directorate for Computer and
Information Science & Engineering, Advanced Networking
Infrastructure & Research Division, Arlington, VA, USA,
October 2002. URL "http://www-
net.cs.umass.edu/testbed_workshop/".
[NSF03] NSF ANIR Principal Investigator meeting, National
Science Foundation, Arlington, VA, USA. January 9-10,
2003, URL "http://www.ncne.org/training/nsf-
pi/2003/nsfpimain.html".
[NSF03a] D. E. Atkins, et al., "Revolutionizing Science and
Engineering Through Cyberinfrastructure", Report of NSF
Advisory Panel on Cyberinfrastructure, January 2003.
URL "http://www.cise.nsf.gov/evnt/reports/
atkins_annc_020303.htm".
[NSF03b] Report of the National Science Foundation Workshop on
Fundamental Research in Networking. April 24-25, 2003.
URL "http://www.cs.virginia.edu/~jorg/workshop1/NSF-
NetWorkshop-2003.pdf".
[Floyd] S. Floyd, "Papers about Research Questions for the
Internet", web page, ICSI Center for Internet Research
(ICIR), Berkeley, CA, 2003 URL
"http://www.icir.org/floyd/research_questions.html".
[RFC-1510] Kohl, J. and C. Neuman, "The Kerberos Network
Authentication Service (V5)", RFC 1510, September 1993.
[RFC-1633] Braden, R., Clark, D., and S. Shenker, "Integrated
Services in the Internet Architecture: an Overview",
RFC 1633, June 1994.
[RFC-2082] Baker, F. and R. Atkinson, "RIP-2 MD5 Authentication",
RFC 2082, January 1997.
[RFC-2210] Wroclawski, J., "The Use of RSVP with IETF Integrated
Services", RFC 2210, September 1997.
[RFC-2154] Murphy, S., Badger, M., and B. Wellington, "OSPF with
Digital Signatures", RFC 2154, June 1997.
[RFC-2385] Heffernan, A., "Protection of BGP Sessions via the TCP
MD5 Signature Option", RFC 2385, August 1998.
[RFC-2407] Piper, D., "The Internet IP Security Domain of
Interpretation for ISAKMP", RFC 2407, November 1998.
[RFC-2501] Corson, S. and J. Macker, "Mobile Ad hoc Networking
(MANET): Routing Protocol Performance Issues and
Evaluation Considerations", RFC 2501, January 1999.
[RFC-2990] Huston, G., "Next Steps for the IP QoS Architecture",
RFC 2990, November 2000.
[RFC-3221] Huston, G., "Commentary on Inter-Domain Routing in the
Internet", RFC 3221, December 2001.
[RFC-3234] Carpenter, B. and S. Brim, "Middleboxes: Taxonomy and
Issues", RFC 3234, February 2002.
[RFC-3424] Daigle, L. and IAB, "IAB Considerations for UNilateral
Self-Address Fixing (UNSAF) Across Network Address
Translation", RFC 3424, November 2002.
[RFC-3467] Klensin, J., "Role of the Domain Name System (DNS)",
RFC 3467, February 2003.
[RFC-3535] Schoenwaelder, J., "Overview of the 2002 IAB Network
Management Workshop", RFC 3535, May 2003.
[RFC-3387] Eder, M., Chaskar, H., and S. Nag, "Considerations from
the Service Management Research Group (SMRG) on Quality
of Service (QoS) in the IP Network", RFC 3387,
September 2002.
[RIPE] RIPE (Reseaux IP Europeens), Amsterdam, NL. URL
"http://www.ripe.net/ripe/".
[Savage00] Savage, S., Wetherall, D., Karlink, A. R., and
Anderson, T., "Practical Network Support for IP
Traceback", Proceedings of 2000 ACM SIGCOMM Conference,
ACM SIGCOMM, Stockholm, SE, pp. 295-306. August 2000.
[Schiller03] J. I. Schiller, "Interception Technology: The Good, The
Bad, and The Ugly!", Presentation at 28th NANOG
Meeting, North American Network Operators Group
(NANOG), Ann Arbor, MI, USA, June 2003. URL
"http://www.nanog.org/mtg-0306/schiller.html".
[SM03] P. Sharma and R. Malpani, "IP Multicast Operational
Network Management: Design, Challenges, and
Experiences", IEEE Network, Vol. 17, No. 2, March
2003.
[SMA03] N. Spring, R. Mahajan, & T. Anderson, "Quantifying the
Causes of Path Inflation", Proceedings of ACM SIGCOMM
2003, ACM, Karlsruhe, Germany, August 2003.
[WD02] Walter Willinger and John Doyle, "Robustness and the
Internet: Design and Evolution", Unpublished/Preprint,
1 March 2002, URL
"http://netlab.caltech.edu/internet/".
[WIDE] WIDE Project, Japan. URL "http://www.wide.ad.jp/".8. Authors' Addresses 🎀
okay bestie, this is the part where the document finally tells you WHO wrote it and WHO was on the IAB team at the time 💅✨ the contact is iab@iab.org 📧
Internet Architecture Board EMail: iab@iab.org
the IAB members when this was published were:
- Bernard Aboba 🦋
- Harald Alvestrand (IETF chair) 👑
- Rob Austein 🌸
- Leslie Daigle (IAB chair) 👑
- Patrik Faltstrom 🧚
- Sally Floyd 💜
- Mark Handley 🫶
- Bob Hinden 🍓
- Geoff Huston (IAB Executive Director) ⭐
- Jun-ichiro Itojun Hagino 🌈
- Eric Rescorla 🔥
- Pete Resnick 💖
- Jonathan Rosenberg 🎀
ngl there's also a little side note 🙈 Ran Atkinson, one of the editors, was an IAB member when this doc was first created in November 2002, and Vern Paxson (the IRTF chair) is an ex-officio member of the IAB too. iykyk 💅
Full Copyright Statement 📜
Copyright (C) The Internet Society (2004). This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights. 🔒
This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/S HE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 💀
Intellectual Property 🧾
The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document, or the extent to which any license under such rights might or might not be available. It also doesn't claim it has made any independent effort to identify any such rights. 🤷♀️ Info on the IETF's procedures for rights in IETF Documents is in BCP 78 and BCP 79.
Copies of IPR disclosures made to the IETF Secretariat, any assurances of licenses to be made available, or the result of an attempt to get a general license or permission for implementers or users to use those proprietary rights can be obtained from the IETF's online IPR repository at http://www.ietf.org/ipr. 🗂️
The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Send that info to the IETF at ietf-ipr@ietf.org. 📬
Acknowledgement 🫶
Funding for the RFC Editor function is currently provided by the Internet Society. 💖
that's the whole doc, bestie!! 🌈✨
📦 where this page comes from
- ietf: rfc3869 2004-08
- 💖 girlified by claude-haiku-5-5 on : a language model's rewrite of the original, under its terms