Address Extension by IP Option Usage BOF (AEIOU) Reported by Peter Ford/LANL Brian Carpenter's Presentation on AEIOU Brian Carpenter presented his ideas on Address Extension by IP Option Usage (AEIOU). The motivation for AEIOU is consideration of the case where no IPng is ready for deployment before IP addresses run out. AEIOU is not positioned as an IPng candidate, but it is a new version of IP which is to provide interim connectivity for IP until IPng is fully deployed. As such, AEIOU is a limited form of insurance against IPv4 address depletion. Brian gave an overview of AEIOU (see draft-carpenter-aeiou-00.txt). What is needed is flexible address extension beyond IP's 32 bits. One goal for AEIOU is to avoid changing addressing and routing in the wide area. Brian assumes that several ``conservation measures'' would be in effect. We would not extend the global IPv4 address space or modify global routing. We would leverage the current deployment of CIDR and new sites would only get the address space they ``need'' for the next one to two years. There would also be a recycling and recovery process on the current allocation of IP addresses. Private networks would be encouraged to use RFC 1597. Discussion There was a fair amount of spirited debate on RFC 1597, revolving around whether or not it was mandatory, that it was not always applicable if a site would eventually connect to the Internet, etc. Many feel that private addresses are a mistake, while others point out that it is irresponsible to use global address space for numbering hosts that never talk outside their site. Further debate on RFC 1597 was left to the ALE group. AEIOU adds two new IP options: Source Address Extension (SAE) and Destination Address Extension (DAE). Each site has its current IANA address space that is globally known, and it picks one of these addresses as a site address. The AEs are managed within a site. It is pointed out that it is dangerous to assume that new options will survive passage across the Internet; Rob Ullman has done some investigation on what routers and hosts do to options. AE is the low-order part of the ``new'' AEIOU address. Steve Deering noted that this is a dual to IPAE, and the MOBILEIP Working Group has studied this extensively. In the new world there are three classes of systems: o Old, 32 bit IP only o New, AE capable, don't use AE o AE, AE used, now have 64-bit addresses Brian presented a matrix where only old and AE cannot talk to each other. It was pointed out that one should carve out part of the global IPv4 space for AEs to be allocated. This way within a site an old host can talk to an AE host since the AE part of the address will be unique within the site and can be used as the IPv4 address to talk to an old IPv4 host within the site. Mike O'Dell noted that this could be net 10, and it would never be routed in the global Internet. Deployment of AEIOU requires that all routers within a site be upgraded. Paul Traina noted that option checking may slow down routers, and that the fastest routers tend to be attached to LANs within a site---exactly those routers that will need to look at AE options. It is also noted that servers that AE hosts depend on will need to be upgraded before AE clients are deployed. During discussion several issues emerged: o The system on the other end has to change to AE to reach you if you are AE. o Checksum only protects 32 bits of address, so potential of misdelivery is greater. o Eric Fleischman noted that AE addresses the ``toaster net'' problem, for example, a power company. This ignited a discussion of application relays as the solution to the ``toaster net'' problem. o A lot of software needs to be changed for AEIOU: SNMP, DNS, ARP, etc. The API for sockets would need to be extended. o Steve Deering noted that you need more than 32 bits to enumerate ``sites''/network terminations. Brian pointed out that AEIOU was an interim, not a final, solution. Summary discussion focused on whether or not AEIOU was too much effort for the return, in light of IPng efforts. Many felt that this would hamper IPng efforts and Eric Fleischman asked that if we deployed AEIOU, wouldn't it cause several people to think that they did not have to worry about deploying IPng? John Curran noted that a lot of this work has to happen anyway and suggested that AEIOU could be a ``hip pocket'' solution requiring a minimum change set. It was noted that the real IPv4 issue at this time is what goes into ``Internet-in-a-box.'' What's Next for AEIOU Given the parallel problems of AEIOU and IPng, Steve Deering recommended that AEIOU should withdraw in favor of IPng efforts. Adding a new protocol (AEIOU) also implies a new thing to transition from to IPng which could unnecessarily complicate matters. After this discussion, Brian is not inclined to propose it as an ``active proposal.'' No mandate for a working group is perceived, but it is worth keeping the discussion alive for anybody interested (send mail to Brian Carpenter if this is you). Deering noted that AEIOU should go into the same status as as EIP: honored, revered, unimplemented. Attendees David Arneson arneson@ctron.com Nutan Behki nebhki@newbridge.com Jim Bound bound@zk3.dec.com Scott Bradner sob@harvard.edu Jerry Burchfield burchfiel@bbn.com Frank Cannata cannata@cabletron.com Brian Carpenter brian@dxcoms.cern.ch Brett Chappell bchappe@relay.nswc.navy.mil Bobby Clay clay@pscni.nasa.gov Alex Conta conta@lassie.lkg.dec.com Matt Crawford crawdad@fncent.fnal.gov John Curran jcurran@nic.near.net Stephen Deering deering@parc.xerox.com Peter DiCamillo Peter_DiCamillo@brown.edu Sean Doran smd@use.net Kjeld Borch Egevang kbe@craycom.dk Robert Elz kre@mulga.cs.mu.oz.au H. Tom Fitzpatrick fitz@ddn.af.mil Eric Fleischman ericf@atc.boeing.com Peter Ford peter@goshawk.lanl.gov Shoji Fukutomi fuku@furukawa.co.jp Marc Hasson marc@mentat.com Kenneth Hays hays@scri.fsu.edu Denise Heagerty denise@dxcoms.cern.ch Geoff Huston g.huston@aarnet.edu.au Akira Kato kato@wide.ad.jp Manu Kaycee kaycee_m@timeplex.com J. Scott Marcus smarcus@bbn.com Michael McLay mclay@eeel.nist.gov Pushpendra Mohta pushp@cerf.net Rina Nathaniel rina@rnd-gate.rad.co.il Michael O'Dell mo@uunet.uu.net Andrew Partan asp@uunet.uu.net Michael Patton map@bbn.com Robert Roden roden@roden.enet.dec.com Michal Rozenthal michal@fibronics.co.il Frank Solensky solensky@ftp.com Tim Streater t.c.streater@dante.org.uk John Tavs tavs@vnet.ibm.com Fumio Teraoka tera@csl.sony.co.jp Paul Traina pst@cisco.com Willem van der Scheun scheun@sara.nl Gary Veum veum@boa.gsfc.nasa.gov Justin Walker justin@apple.com Jane Wojcik jwojcik@bbn.com Shinichi Yoshida yoshida@sumitomo.com Jessica Yu jyy@merit.edu