Network Working Group B. Carpenter Internet Draft CERN 21 March 1994 Expires 26 September 1994 File name draft-carpenter-aeiou-00.txt Address Extension by IP Option Usage (AEIOU) Status of this Memo This document is an Internet Draft. Internet Drafts are working documents of the Internet Engineering Task Force (IETF), its Areas, and its Working Groups. Note that other groups may also distribute working documents as Internet Drafts. Internet Drafts are draft documents valid for a maximum of six months. Internet Drafts may be updated, replaced, or obsoleted by other documents at any time. It is not appropriate to use Internet Drafts as reference material or to cite them other than as a ``working draft'' or ``work in progress.'' Please check the 1id-abstracts.txt listing contained in the internet-drafts Shadow Directories on nic.ddn.mil, nnsc.nsf.net, nic.nordu.net, ftp.nisc.sri.com, or munnari.oz.au to learn the current status of any Internet Draft. Distribution of this memo is unlimited. Comments should be submitted to the big-internet@munnari.oz.au mailing list. Abstract This document proposes an addressing extension mechanism for IP as a possible life extender while awaiting IPng. AEIOU proposal It is possible that no IPng candidate will be considered mature enough in time to be widely deployed before the IPv4 address space is fully allocated. This document suggests a way to cope with this risk. Although it does not propose a new IPng candidate, the proposal does amount to a major change to IP, requiring new versions of host and router software. However, the impact on existing code is much less than that of any IPng proposal. By the same token, the only problem that it tackles is the address space problem. During the process of collecting requirements for IPng, a number of people have stated the need to fix the IPv4 address space problem by Carpenter [Page 1] Draft Address Extension by IP Option Usage (AEIOU) 21 March 1994 flexible address extensions beyond 32 bits. However, if this means that IPv4 addresses should be replaced by bigger addresses, it breaks the current Internet routing and addressing architecture. AEIOU proposes to tackle the problem differently. Firstly, three conservative measures should be taken: 1. Do not extend the global Internet address space or modify the global routing architecture. 2. Do deploy CIDR and BGP4. Be very restrictive on allocations to new sites (i.e. give them the minimum CIDR space that will satisfy them for one or two years). 3. Do not allocate any new network numbers to sites that already have at least one network number of any class (A, B, C). Try to recover unused numbers and CIDRise sparse networks. Encourage use of RFC 1597. Secondly, provide a simple address extension mechanism as an IP option: 4. Add two new IPv4 options "Source Address Extension" (SAE) and "Destination Address Extension" (DAE). Type: [copied, class 0, option number TBD] Length: 6 Data: 4 octet address extension (AE) The AE options are carried transparently and survive fragmentation. Neither, either, or both may be present. 5. AEs are allocated by a site (not to a site) when it has run out of addresses in its share of the IPv4 32-bit address space. The AE space is structured like Class A, B and C space and all normal subnetting techniques apply. A host in AE space can be considered to have an address in the form of a 64-bit couplet (site address, AE). Each site has a globally unique 32-bit site address, which can be any IPv4 address from the site's IANA-allocated IPv4 address space. This site address then "hides" all the site's AEs. For example, the site currently allocated the Class B network 128.141 could use 128.141.141.141 as its site address, and this would be the wide-area address used for routing all packets to the site's 32-bit AE space. Wide-area routing does not change. Routing to non-AE hosts does not change. 6. Hosts now fall into three classes: Carpenter [Page 2] Draft Address Extension by IP Option Usage (AEIOU) 21 March 1994 OLD hosts; still running 32-bit IP only. NEW hosts; AE options implemented, but no allocated AE (i.e. NEW hosts are still in the global 32-bit space.) By convention, AE=0.0.0.0 for NEW hosts. AE hosts; AE options implemented, and an AE allocated. AE hosts are in the new 64-bit space. The following table shows which combinations of hosts can talk to each other, using 32 or 64 bit addresses. OLD NEW AE ---------------------- OLD | 32 | 32 | no | (There might be some cases | | | | where OLD and AE hosts can NEW | 32 | 32 | 64 | talk, if they are on the | | | | same subnet.) AE | no | 64 | 64 | ---------------------- The outline of the deployment plan follows. Stage 1: A site address is allocated for every Internet site. On-site routers are upgraded to AE. All servers are upgraded from OLD to NEW. OLD clients can still access NEW servers. Stage 2: Ensure that all newly installed clients are AE hosts. New clients no longer consume 32-bit addresses. Stage 3: Progressively convert OLD clients to AE. This means upgrading software versions, and renumbering clients. At the same time, RFC 1597 addresses could be transformed into AEs if required. Stage 4: Sites will now have many unused 32-bit addresses recovered during Stage 3. A fraction of these can be recovered by further use of CIDR, and can be re-allocated as site addresses for new Internet sites. Stage 5: Theoretically, all servers can now be converted from NEW to AE. At this stage almost all 32-bit addresses can be recovered and re-used as in Stage 4. We now have a two-tier Internet address scheme (32-bit site address space managed by IANA, and 32-bit AE space managed by individual sites). Thirdly, some more details: 7. IP packets flow from source to the destination site exactly as Carpenter [Page 3] Draft Address Extension by IP Option Usage (AEIOU) 21 March 1994 they do today. The SAE and DAE options are copied (even if fragmentation occurs). At the ingress router on the destination site, if the DAE option is present, it is used by local routing protocols to route the packet to the correct physical subnet. These routing protocols can be any of those in use today, except that they look at the DAE field instead of the normal IP destination address (DA). This is not optimal for router performance. However, the obvious solution of having the ingress router swap the DAE and the DA does not work, since this would disturb the TCP and UDP pseudo-header checksum calculation. 8. On a subnet such as Ethernet, a rather straightforward extension of ARP (EARP, extended ARP) is needed to obtain the physical address corresponding to the (site address,DAE) couplet. For further study, but clearly soluble. 9. DNS RR's will include the AE when it exists. The DNS reply will directly imply whether a host is OLD (no AE), NEW (AE = 0.0.0.0) or AE. 10. I haven't worked out how the AE is handled at the socket API yet. This is the biggest problem if software changes are to be minimised. It's no worse than for SIPP, of course. It can also be argued that forcing applications to use an API with multiple address formats (for example, AF_INET and AF_INETE in the case of BSD sockets) is good, because this will be needed for the real IPng when it comes. 11. FOOBAR (RFC 1545) can handle it for FTP. 12. etc. Lots more to be written, by analogy with the SIPP and TUBA transition documents. References TBD Disclaimer and acknowledgements. This is a personal view and does not necessarily represent that of my employer. AEIOU is not the same as EIP (RFC 1385) but it is in some sense a simple inversion of the EIP idea, which has been at the back of my mind for two years. It resembles the original (1992) IPAE draft too and has some similarities to TP/IX (RFC 1475). Other ideas came from the IPng transition discussions in general, and there is a clear Carpenter [Page 4] Draft Address Extension by IP Option Usage (AEIOU) 21 March 1994 resemblance to the DECnet Phase V deployment process. Various individuals have commented on the earlier versions of this document; a full list will be included in a future version. Author's Address Brian E. Carpenter Group Leader, Communications Systems Phone: +41 22 767-4967 Computing and Networks Division Fax: +41 22 767-7155 CERN Telex: 419000 cer ch European Laboratory for Particle Physics E-mail: brian@dxcoms.cern.ch 1211 Geneva 23, Switzerland Expires 26 September 1994 File name draft-carpenter-aeiou-00.txt Carpenter [Page 5]