RFC 1385
EIP: The Extended Internet Protocol
EIP: The Extended Internet Protocol 🦋
Okay bestie, the title block first 💅 This one is from Network Working Group, RFC 1385, written by Z. Wang at University College London, dated November 1992. It's not a standard. It's an information doc for the Internet community. The title block doesn't list anything it obsoletes or updates, so it's standing on its own ✨
Status of this Memo 📜
This memo provides information for the Internet community. It does not specify an Internet standard. Distribution of this memo is unlimited.
Summary 🌸
The Extended Internet Protocol (EIP) is a framework for fixing address space exhaustion with a new addressing and routing scheme, and it keeps maximum backward compatibility with current IP. It can seriously cut down on the changes current Internet systems need and make the transition way less painful 🫶 This is an "idea" paper, so they really want discussion on Big-Internet@munnari.oz.au 💌
Introduction 🧚
Okay so the Internet has two big scaling problems: address exhaustion and routing explosion [1-2] 😭 The Internet is going to run out of Class B numbers soon, and the 32-bit IP address space will be totally used up in a few years. The total number of IP networks is also going to grow to the point where routing algorithms can't route based on a flat network number. Not ideal.
A bunch of short-term fixes have been proposed recently to use the remaining address space more efficiently and ease the immediate pain [3-5]. But it's important to develop and deploy a long-term solution before the 32-bit address space runs out 👑
The obvious move would be to replace current IP with a new internet protocol that has no backward compatibility with current IP. People have put forward a bunch of proposals: Pip[7], Nimrod [8], TUBA [6] and SIP [14]. But IP is basically the cornerstone of the current Internet, so swapping it for a new "IP" means fundamental changes to a lot of stuff (e.g., routing, routers, hosts, ARP, RARP, ICMP, TCP, UDP, DNS, FTP) 💀
Migrating to a new "IP" basically creates a whole new "Internet" 🌈 Building and rolling out that new "Internet" would take a huge amount of time and effort. Plus, to keep old and new systems talking during the transition, almost every upgraded system would have to run the new and old versions in parallel, and figure out which version to use based on whether the other side has been upgraded. Chaotic energy.
Here's what the full swap would actually require:
- Border Routers: Border routers have to be upgraded to provide address translation for IP packets across boundaries. The translation has to happen on outgoing IP packets as well as incoming packets to IP hosts. ✨
- Subnet Routers: Subnet routers have to be upgraded and handle both the new and the old packet formats. 🍓
- Hosts: Hosts have to be upgraded and run both the new and the old protocols in parallel. Upgraded hosts also have to figure out whether the other side is upgraded, so they pick the right protocol to use. 🎀
- DNS: The DNS has to be modified to map domain names to new addresses. 🦋
- ARP/RARP: ARP/RARP have to be modified, and upgraded hosts and routers have to handle both old and new ARP/RARP packets. 💜
- ICMP: ICMP has to be modified, and upgraded routers have to be able to generate both old and new ICMP packets. However, it may be impossible for a backbone router to tell whether a packet came from an upgraded host or from an IP host that was translated by a border router. 🙈
- TCP/UDP Checksum: The pseudo headers may have to be modified to use the new addresses. 🔥
- FTP: The DATA PORT (
PORT) command has to be changed to pass new addresses. 💅
In this paper, we argue that an evolutionary approach can extend the addressing space while keeping backward compatibility 🦋 The Extended Internet Protocol (EIP) we present here can be used as a framework where a new routing and addressing scheme can solve address exhaustion and still keep maximum backward compatibility with current IP. Main character energy ✨
EIP has a bunch of really good features:
- EIP allows the Internet to have a virtually unlimited number of network numbers, and over
10**9hosts in each network. 👑 - EIP is flexible enough to fit most routing and addressing schemes, like those proposed in Nimrod [8], Pip [7], NSAP [9] and CityCodes [10]. EIP also lets new fields like Handling Directive [7] or CI [11] be added. 🧚
- EIP can substantially reduce the amount of modifications to current systems and greatly ease the transition. In particular, it doesn't require upgraded hosts and subnet routers to run two sets of protocols in parallel. 🫶
- EIP doesn't require any changes to all assigned IP addresses and subnet structures in local area networks, and it doesn't require modifications to ARP/RARP, ICMP, or TCP/UDP checksum. 🌸
- EIP can greatly ease the transition. During the transition period, no upgrade is required for subnet routers. EIP hosts keep full compatibility with IP hosts within the same network, even after the transition period. During the transition period, IP hosts can talk to any hosts in other networks through a simple translation service. 💖
For the rest of the paper, IP refers to the current Internet Protocol, and EIP refers to the Extended Internet Protocol. (EIP is pronounced "ape", which is a step forward in the evolution :-) 🦧✨
Extended Internet Protocol (EIP) ✨
Okay bestie, so here's the EIP header layout 🦋 Figure 1 is the picture, and then I'll walk you through every field inside it 💅
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|Version| IHL |Type of Service| Total Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Identification |Flags| Fragment Offset |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Time to Live | Protocol | Header Checksum |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Source Host Number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Destination Host Number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| EIP ID | EIP Ext Length| EIP Extension (variable) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+Figure 1: EIP Header Format
Version: 4 bits
The Version field is identical to that of IP 🎀 It's set purely for compatibility with IP hosts, and EIP hosts don't check it.
IHL: 4 bits
Internet Header Length is identical to that of IP. IHL is set to the length of the EIP header purely for compatibility with IP, and EIP hosts don't check this field. see below the EIP Extension Length field for more details)
Type of Service: 8 bits
The ToS field is identical to that of IP. Same energy, no notes 🌸
Total Length: 16 bits
The Total Length field is identical to that of IP ✨
Identification: 16 bits
The Identification field is identical to that of IP 🧚
Flags: 3 bits
The Flags field is identical to that of IP 🍓
Fragment Offset: 13 bits
The Fragment Offset field is identical to that of IP 💜
Time to Live: 8 bits
The Time to Live field is identical to that of IP ⭐
Protocol: 8 bits
The Protocol field is identical to that of IP 🦋
Header Checksum: 16 bits
The Header Checksum field is identical to that of IP 🫶
Source Host Number: 32 bits
The Source Host Number field identifies the source host, but it's only unique within the source network. Think of it as the host portion of the source IP address, the equivalent of that part 🎀
Destination Host Number: 32 bits
The Destination Host Number field identifies the destination host, but it's only unique within the destination network. It's the host portion of the destination IP address, the same vibe as the source side 🌈
EIP ID: 8 bits
The EIP ID field equals 0x8A. The EIP ID value is picked so that, to IP hosts and IP routers, an EIP packet looks like a regular IP packet with a new IP option, with the following parameters:
COPY CLASS NUMBER LENGTH DESCRIPTION
---- ----- ------ ------ -----------
1 0 TBD varThe option is Option: Type=TBD. Iconic, right? 👑
EIP Extension Length: 8 bits
The EIP Extension Length field tells you the total length, in octets, of the EIP ID field, the EIP Extension Length field, and the EIP Extension field together. The IHL field above can only specify a maximum of 60 bytes, which is considered too short in the future 🙈 So EIP hosts actually use the EIP Extension Length field to work out the total header length:
The total header length = EIP Extension Length + 20.
That means the maximum header length of an EIP packet is then 276 bytes. Main character header length, fr fr 💅
EIP Extension: variable
The EIP Extension field holds the Source Network Number, the Destination Network Number, and other fields. The format of the Extension field isn't specified here. In its simplest form, it can hold two fixed size fields as the Source Network Number and Destination Network Number, which extend the addressing space. Since the Extension field is variable in length, it can handle almost any routing and addressing scheme 🦋 For example, it can hold the "Routing Directive" etc specified in Pip [7], or the "Endpoint IDs" suggested in Nimrod [8], or the "CityCode" [10]. It can also hold other fields like the "Handling Directive" [7] or the "Connectionless ID" [11] ✨
EIP achieves maximum backward compatibility with IP by making the extended space look like an IP option to IP hosts and routers 🎀
When an IP host receives an EIP packet, it safely ignores the EIP Extension field, because to the IP host it looks like a new, and therefore unknown, IP option. Because of that, there's no need to translate incoming EIP packets that are destined for IP hosts, and there's also no need for subnet routers to be upgraded during the transition period (see later section for more details) 🫶
EIP hosts or routers can still tell whether a packet is an IP packet or an EIP packet, by checking the EIP ID field, whose position is fixed in the header 💖
The EIP Extension field holds the Source and Destination Network Numbers, which are only used for communication between different networks. For communication within the same network, the Network Numbers may be left out. When the Extension field is left out, there's barely any difference between an IP packet and an EIP packet, so EIP hosts can stay fully compatible with IP hosts within one network 🌸
In EIP, the Network Numbers and Host Numbers are separate, and the IP address field is used for the Host Number in EIP. There are a bunch of advantages to this, bestie 😭
- It keeps full compatibility between IP hosts and EIP hosts for communication within one network. The Network Number isn't needed for communication within one network. A host can leave out the Extension field if it doesn't need anything else in it, when it talks to another host in the same network 🧚
- It lets the IP subnet routers route EIP packets by treating the Host Number as the IP address during the transition period, so the subnet routers aren't required to be upgraded along with the border routers 🍓
- It lets ARP/RARP work with both EIP and IP hosts without any modifications 💜
- It makes translation at the border routers much easier. During the transition period, while the IP addresses are still unique, the network portion of the IP addresses can be directly extracted and mapped to EIP Network Numbers ⭐
Modifications to IP Systems
In this section we go through the changes to IP systems that are needed for the transition to EIP. Because EIP and IP are so similar, the amount of change needed for current systems is way reduced 🦋
- Network Numbers: Each network has to be assigned a new EIP Network Number based on the addressing scheme used. The mapping between the IP network numbers and the EIP Network Numbers can be used for the translation service (see below) 🎀
- Host Numbers: There's no need to assign EIP Host Numbers. All existing hosts can use their current IP addresses as their EIP Host Numbers. New machines may be allocated any number from the 32-bit Host Number space, since the structure placed on IP addressing is no longer necessary. However, during the transition, allocation of EIP Host Numbers should still follow the IP addressing rule, so that the EIP Host Numbers are still globally unique and can still be read as IP addresses. This allows a more gradual transition to EIP (see below) 🌈
- Translation Service: During the transition period, while the EIP Host Numbers are still unique, an address translation service can be provided to IP hosts that need to talk to hosts in other networks across the upgraded backbone networks. The translation service can be provided by the border routers. When a border router receives an IP packet, it gets the Destination Network Number by looking it up in the mapping table between IP network numbers and EIP Network Numbers. The border router then adds the Extension field with the Source and Destination Network Numbers into the packet, and forwards it to the backbone networks. It's only necessary to translate the outgoing IP packets into EIP packets. There's no need to translate EIP packets back into IP packets, even when they're destined for IP hosts, because the Extension field in EIP packets looks like just an unknown IP option to IP hosts, and they ignore it during processing 💅
- Border Routers: The new EIP Extension has to be implemented, and routing has to be done based on the Network Number in the EIP Extension field. The border routers may have to provide the translation service for outgoing IP packets during the transition period 👑
- Subnet Routers: No modifications are required during the transition period, while the EIP Host Numbers (which equal the IP addresses) are still globally unique. Subnet routing is carried out based on the EIP Host Numbers, and while the EIP Host IDs are still unique, subnet routers can work out, by treating the EIP Host Number as the IP address, whether a packet is destined for remote networks, and forward it correctly. The Extension field in EIP packets also looks like an unknown IP option to the IP subnet routers, and they ignore it during processing. However, subnet routers eventually have to implement the EIP Extension and route based on Network Numbers once EIP Host Numbers are no longer globally unique 🔥
- Hosts: The EIP Extension has to be implemented. Routing has to be done based on the Network Number in the EIP Extension field, and also based on the Host Number and subnet mask if subnetting is used. IP hosts may communicate with any hosts within the same network at any time. During the transition period, while the EIP Host Numbers are still unique, IP hosts can communicate with any hosts in other networks via the translation service 🧚
- DNS: A new resource record (RR) type "N" has to be added for EIP Network Numbers. The RR type "A", currently used for IP addresses, can still be used for EIP Host Numbers. RR type "N" entries have to be added, and RR type "PTR" has to be updated. All other entries remain unchanged 🍓
- ARP/RARP: No modifications are required. ARP and RARP are used for mapping between EIP Host Numbers and physical addresses 💜
- ICMP: No modifications are required ⭐
- TCP/UDP Checksum: No modifications are required. The pseudo header includes the EIP Source and Destination IDs instead of the source and destination IP addresses 🦋
- FTP: No modifications are required during the transition period, while IP hosts can still communicate with hosts in other networks via the translation service. After the transition period, though, the
DATA Port (Port)command has to be modified to pass the port number only and ignore the IP address. A new FTP command may be created to pass both the port number and the EIP address, to allow a third party to be involved in the file transfer 🫶
Transition to EIP ✨
okay so this is the plan for how we actually get everyone over to EIP 🦋 and ngl it's giving smooth. EIP can seriously cut down the drama of transitioning bc the updated hosts and subnet routers do NOT have to run two protocols in parallel just to talk to old and new systems. 💅
During the transition, IP hosts can still talk to any machine on the same network with zero changes 🫶. As long as the EIP Host Numbers (aka the 32-bit IP addresses) are still globally unique, IP hosts can reach hosts in other networks through a translation service run by the border routers. literally so cute 🌸
Here's the transition timeline:
Phase 0:
- a) Choose an addressing and routing scheme for the Internet.
- b) Implement the routing protocol.
- c) Assign new Network Numbers to existing networks.
Phase 1:
- a) Update all backbone routers and border routers.
- b) Update DNS servers.
- c) Start translation service.
Phase 2:
- a) Update first the key hosts such as mail servers, DNS servers, FTP servers and central machines.
- b) Update gradually the rest of the hosts.
Phase 3:
- a) Update subnet routers.
- b) Withdraw the translation service.
The translation service can keep running for as long as the Host IDs (i.e., the 32-bit IP address) are still globally unique 🧚. Once the IP address space is exhausted, the translation service gets withdrawn and the remaining IP hosts can only communicate with hosts inside the same network 😭. Meanwhile, networks can use any numbers in the 32-bit space for addressing their hosts 🌈.
Related Work
okay the next bit is about a proposal called IPAE, from Hinden and Crocker 💜 it has the same vibe of trying to change as little of the current IP system as possible while still extending the addressing space [12]. the twist is that IPAE uses encapsulation, so the extended space rides along as IP data 🎀. but people found out that the 64 bits of IP data returned by an ICMP packet are too small to hold the Global IP addresses 💀. so when a router gets an ICMP generated by an old IP host, it can't turn it into a proper ICMP packet 🙈. if you want the deets, check [13] 🔍.
Discussions
the header length thing: EIP doesn't necessarily make the header much longer, bc most of the fields in the current IP are still needed in the new protocol ✨. there's still debate over whether fragmentation and the header checksum are necessary in the new internet protocol, but no consensus has been reached yet 🤷♀️.
EIP assumes that IP hosts and routers silently ignore unknown IP options, as required by [15,16] 🌸. some people have raised concerns about whether current IP routers and hosts on the Internet can handle unknown IP options properly 😬.
so to look into it, we ran a bunch of experiments on the use of IP options 🧪. we picked 35 hosts across 30 countries on the Internet 🌍. a TCP test program (based on ttcp.c) sent data to the echo port (tcp port 7) of each host 📨. each host got two tests, one with an unknown option (type 0x8A, length 40 bytes) and one without any options 🎀.
it's really hard to make the two tests run under exactly the same conditions, but we tried our best to keep them as close as possible 🫶. the two tests (test-opt and test-noopt) ran on the same machine (a Sun4) in parallel, like "test-opt& ; test-noopt&", and then again in reverse order, like "test-noopt& ; test-opt&", so each test pair actually ran twice 🔁. each host got pinged before the tests so the domain name info was already cached before the name lookup 💅.
the experiments ran at three sites: UCL, Bellcore and Cambridge University 🏫. the tcp echo throughput results (KB/Sec) are listed in the Appendix 📊.
the results show the IP option was handled properly, and there's no visible performance difference under this test setup 👑🌈.
References
- [1] Chiappa, N., "The IP Addressing Issue", Work in Progress, October 1990.
- [2] Clark, D., Chapin, L., Cerf, V., Braden, R., and R. Hobby, "Towards the Future Architecture", RFC 1287, MIT, BBN, CNRI, ISI, UCDavis , December 1991.
- [3] Solensky, F. and F. Kastenholz, "A Revision to IP Address Classifications", Work in Progress, March 1992.
- [4] Fuller, V., Li, T., Yu, J., and K. Varadhan, "Supernetting: an Address Assignment and Aggregation Strategy", RFC 1338, BARRNet, cisco, Merit, OARnet, June 1992.
- [5] Wang, Z., and J. Crowcroft, "A Two-Tier Address Structure for the Internet: a solution to the problem of address space exhaustion", RFC 1335, University College London, May 1992.
- [6] Callon, R., "TCP and UDP with Bigger Addresses (TUBA), a Simple Proposal for Internet Addressing and Routing", RFC 1347, DEC, June 1992.
- [7] Tsuchiya, P., "Pip: The 'P' Internet Protocol", Work in Progress, May 1992
- [8] Chiappa N., "A New IP Routing and Addressing Architecture", Work in Progress, 1992.
- [9] Colella, R., Gardner, E., and R. Callon, "Guidelines for OSI NSAP Allocation in the Internet" RFC 1237, NIST, Mitre, DEC, July 1991.
- [10] Deering, S., "City Codes: An Alternative Scheme for OSI NSAP Allocation in the Internet", Work in Progress, January 1992.
- [11] Clark, D., "Building routers for the routing of tomorrow", in his message to Big-Interent@munnari.oz.au, 14 July 1992.
- [12] Hinden, R., and D. Crocker, "A Proposal for IP Address Encapsulation (IPAE): A Compatible Version of IP with Large Addresses", Work in Progress, July 1992.
- [13] Partridge, C., "Re: Note on implementing IPAE", in his message to Big-Interent@munnari.oz.au, 17 July 1992.
- [14] Deering, S., "SIP: Simple Internet Protocol", Work in Progress, September 1992.
- [15] Braden, R., Editor, "Requirements for Internet Hosts -- Communication Layers", RFC 1122, ISI, October 1989.
- [16] Almquist, P., Editor, "Requirements for IP Routers", Work in Progress, October 1991.
Appendix
okay the Appendix is where the receipts live 📜🧾. here's the throughput data from UCL, with each destination tested twice 🔍:
Throughput Test from UCL (sartre.cs.ucl.ac.uk)
Destination Host test-noopt test-opt
------------------- ---------- ---------
oliver.cs.mcgill.ca 1.128756 1.285345
oliver.cs.mcgill.ca 1.063096 1.239709
bertha.cc.und.ac.za 0.094336 0.043917
bertha.cc.und.ac.za 0.075681 0.057120
vnet3.vub.ac.be 2.090622 2.228181
vnet3.vub.ac.be 1.781374 1.692740
itdsrv1.ul.ie 1.937596 2.062579
itdsrv1.ul.ie 1.928313 1.936784
sunic.sunet.se 11.064797 11.724055
sunic.sunet.se 10.861720 10.840306
pascal.acm.org 2.463790 0.810133
pascal.acm.org 1.619088 0.860198
iti.gov.sg 1.565320 1.983795
iti.gov.sg 1.564788 1.921803
rzusuntk.unizh.ch 9.903805 11.335920
rzusuntk.unizh.ch 9.597806 10.678098
funet.fi 9.897876 9.382925
funet.fi 10.487118 11.023745
odin.diku.dk 5.851407 5.482946
odin.diku.dk 5.992257 6.243283
cphkvx.cphk.hk 0.758044 0.844406
cphkvx.cphk.hk 0.784532 0.745606
bootes.cus.cam.ac.uk 28.341705 29.655824
bootes.cus.cam.ac.uk 24.804125 23.240990
pesach.jct.ac.il 1.045922 1.115802
pesach.jct.ac.il 1.330429 0.978184
sun1.sara.nl 10.546733 11.500778
sun1.sara.nl 9.624833 10.214136
cocos.fuw.edu.pl 1.747777 1.702324
cocos.fuw.edu.pl 1.676151 1.716435
apple.com 4.449559 4.145081
apple.com 6.431675 5.520443
gorgon.tf.tele.no 1.199810 1.374546
gorgon.tf.tele.no 0.508642 0.993261
kogwy.cc.keio.ac.jp 3.626448 3.249590
kogwy.cc.keio.ac.jp 3.913777 4.094849
exu.inf.puc-rio.br 1.913925 1.795235
exu.inf.puc-rio.br 1.154936 1.114775
inria.inria.fr 2.299561 0.599665
inria.inria.fr 1.219282 0.873672
kum.kaist.ac.kr 0.252704 0.254199
kum.kaist.ac.kr 0.236196 0.172367
sunipc1.labein.es 1.398777 1.243588
sunipc1.labein.es 0.876177 0.602964
wifosv.wsr.ac.at 0.531153 0.803387
wifosv.wsr.ac.at 0.773935 0.557798
uunet.uu.net 7.813556 6.764543
uunet.uu.net 7.969203 6.657325
infnsun.aquila.infn.it 2.321197 2.402477
infnsun.aquila.infn.it 2.400196 2.695016
muttley.fc.ul.pt 0.545775 0.434672
muttley.fc.ul.pt 0.284124 0.266017
dmssyd.syd.dms.csiro.au 2.734685 2.857545
dmssyd.syd.dms.csiro.au 1.168154 1.462789
hamlet.caltech.edu 2.552804 2.897286
hamlet.caltech.edu 3.839141 2.407945
sztaki.hu 0.294196 0.403697
sztaki.hu 0.236260 0.388755
menvax.restena.lu 0.465066 0.515361
menvax.restena.lu 0.358646 0.511985
nctu.edu.tw 0.484372 0.816722
nctu.edu.tw 0.705733 1.109228
xalapa.lania.mx 0.899529 0.822544
xalapa.lania.mx 1.150058 0.881713
truth.waikato.ac.nz 1.438481 1.993749
truth.waikato.ac.nz 1.325041 1.833999Throughput Test from Bellcore (latour.bellcore.com)
Here's the rest of the test results, first from one site and then from Cam U:
Destination Host test-noopt test-opt
------------------ ---------- ---------
oliver.cs.mcgill.ca 1.820014 2.128104
oliver.cs.mcgill.ca 1.979981 1.866815
bertha.cc.und.ac.za 0.099289 0.035877
bertha.cc.und.ac.za 0.118627 0.103763
vnet3.vub.ac.be 0.368476 0.694463
vnet3.vub.ac.be 0.443269 0.644050
itdsrv1.ul.ie 0.721444 0.960068
itdsrv1.ul.ie 0.713952 0.953275
sunic.sunet.se 2.989907 2.956766
sunic.sunet.se 2.100563 2.010292
pascal.acm.org 2.487185 3.896253
pascal.acm.org 1.944085 4.269323
iti.gov.sg 2.401733 2.735445
iti.gov.sg 2.950990 2.793121
rzusuntk.unizh.ch 4.094820 3.618023
rzusuntk.unizh.ch 2.952650 2.245001
funet.fi 6.703408 5.928008
funet.fi 7.389722 5.815122
odin.diku.dk 2.094152 2.450695
odin.diku.dk 5.362362 4.690722
cphkvx.cphk.hk 0.092698 0.106880
cphkvx.cphk.hk 0.496394 0.681994
bootes.cus.cam.ac.uk 2.632951 2.631322
bootes.cus.cam.ac.uk 3.717170 1.335914
pesach.jct.ac.il 0.684029 0.921621
pesach.jct.ac.il 0.390263 1.095265
sun1.sara.nl 3.186035 2.325166
sun1.sara.nl 3.053797 3.081236
cocos.fuw.edu.pl 0.154405 0.124795
cocos.fuw.edu.pl 0.120283 0.105825
apple.com 12.588979 12.957880
apple.com 13.861733 12.211125
gorgon.tf.tele.no 1.280217 1.112675
gorgon.tf.tele.no 0.243205 0.631096
kogwy.cc.keio.ac.jp 6.249789 5.075968
kogwy.cc.keio.ac.jp 3.387490 4.583511
exu.inf.puc-rio.br 2.089536 2.233711
exu.inf.puc-rio.br 2.476758 2.249439
inria.inria.fr 0.653974 0.866246
inria.inria.fr 0.739127 1.130521
kum.kaist.ac.kr 1.541682 1.312546
kum.kaist.ac.kr 0.906632 1.042793
sunipc1.labein.es 0.101496 0.091456
sunipc1.labein.es 0.054245 0.101585
wifosv.wsr.ac.at 1.044443 0.369528
wifosv.wsr.ac.at 0.596935 0.870377
uunet.uu.net 9.530348 8.999789
uunet.uu.net 8.941888 6.075660
infnsun.aquila.infn.it 1.619418 1.569645
infnsun.aquila.infn.it 1.156780 1.158000
muttley.fc.ul.pt 0.353632 0.416126
muttley.fc.ul.pt 0.221522 0.155505
dmssyd.syd.dms.csiro.au 3.433901 3.272839
dmssyd.syd.dms.csiro.au 3.408975 3.130188
hamlet.caltech.edu 5.367756 6.325031
hamlet.caltech.edu 4.828718 5.676571
sztaki.hu 0.301120 0.362481
sztaki.hu 0.253222 0.519892
menvax.restena.lu 0.364221 0.480789
menvax.restena.lu 0.456882 0.580778
nctu.edu.tw 0.246523 1.199412
nctu.edu.tw 0.423476 0.630833
xalapa.lania.mx 0.748642 0.607284
xalapa.lania.mx 0.716781 0.643030
truth.waikato.ac.nz 2.197595 2.072601
truth.waikato.ac.nz 2.489748 2.186684
Throughput Test from Cam U (cus.cam.ac.uk)
Destination Host test-noopt test-opt
------------------ ---------- ---------
oliver.cs.mcgill.ca 1.128756 1.285345
oliver.cs.mcgill.ca 1.063096 1.239709
bertha.cc.und.ac.za 0.031218 0.031221
bertha.cc.und.ac.za 0.034405 0.034925
vnet3.vub.ac.be 0.568487 0.731320
vnet3.vub.ac.be 0.558238 0.581415
itdsrv1.ul.ie 1.064302 1.284707
itdsrv1.ul.ie 0.852089 1.025779
sunic.sunet.se 7.179942 6.270326
sunic.sunet.se 5.772485 6.689160
pascal.acm.org 1.661248 1.726725
pascal.acm.org 1.557839 1.428193
iti.gov.sg 0.600616 0.926690
iti.gov.sg 0.772887 0.956636
rzusuntk.unizh.ch 3.645913 4.504969
rzusuntk.unizh.ch 1.853503 2.671272
funet.fi 4.190147 3.421110
funet.fi 2.270988 3.789678
odin.diku.dk 1.361227 0.993901
odin.diku.dk 1.977774 2.415716
cphkvx.cphk.hk 1.173451 1.298421
cphkvx.cphk.hk 1.151376 1.184210
bootes.cus.cam.ac.uk 269.589141 238.920081
bootes.cus.cam.ac.uk 331.203020 293.556436
pesach.jct.ac.il 0.343598 0.492202
pesach.jct.ac.il 0.582809 0.930958
sun1.sara.nl 1.529277 1.470571
sun1.sara.nl 0.896041 0.894923
cocos.fuw.edu.pl 0.131180 0.142239
cocos.fuw.edu.pl 0.137697 0.148895
apple.com 1.330794 0.453590
apple.com 0.856476 0.714661
gorgon.tf.tele.no 0.094793 0.099981
gorgon.tf.tele.no 0.167257 0.151625
kogwy.cc.keio.ac.jp 0.154681 0.178868
kogwy.cc.keio.ac.jp 1.095814 0.871496
exu.inf.puc-rio.br 0.454272 0.384484
exu.inf.puc-rio.br 0.705198 0.690708
inria.inria.fr 0.149511 0.150021
inria.inria.fr 0.071125 0.077257
kum.kaist.ac.kr 0.721184 0.549511
kum.kaist.ac.kr 0.250285 0.296195
sunipc1.labein.es 0.519284 0.491745
sunipc1.labein.es 0.990174 1.009475
wifosv.wsr.ac.at 0.360751 0.418554
wifosv.wsr.ac.at 0.344268 0.326605
uunet.uu.net 4.247430 3.305592
uunet.uu.net 3.139251 2.945469
infnsun.aquila.infn.it 0.480731 0.782631
infnsun.aquila.infn.it 0.230471 0.292273
muttley.fc.ul.pt 0.239624 0.334286
muttley.fc.ul.pt 0.586156 0.419485
dmssyd.syd.dms.csiro.au 3.630623 3.607504
dmssyd.syd.dms.csiro.au 1.743162 2.994665
hamlet.caltech.edu 5.897946 4.650703
hamlet.caltech.edu 5.118200 5.622022
sztaki.hu 0.338358 0.225206
sztaki.hu 0.113328 0.112637
menvax.restena.lu 0.224967 0.359237
menvax.restena.lu 0.452945 0.472345
nctu.edu.tw 2.549709 2.037245
nctu.edu.tw 2.229093 2.469851
xalapa.lania.mx 0.713586 0.810107
xalapa.lania.mx 0.612278 0.731705
truth.waikato.ac.nz 1.438481 1.993749
truth.waikato.ac.nz 1.325041 1.833999Security Considerations 🔒
Okay, bestie, this one is short and sweet 🥹 Security issues are not discussed in this memo. 🫶
Author's Address 🖊️
And here's who wrote it 💜
Zheng Wang
Dept of Computer Science
University College London
London WC1E 6BT, UK
EMail: z.wang@cs.ucl.ac.ukThat's the whole RFC, babe! 🌈✨
📦 where this page comes from
- ietf: rfc1385 1992-11
- 💖 girlified by claude-haiku-5-5 on : a language model's rewrite of the original, under its terms