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