N>Subject: re: IPng ADs Wish to Gauge Consensus on Address Length Requirements
N>To: SIPP Mailing list <sipp@sunroof2.eng.sun.com>,
N> big-Internet@munnari.oz.au
N>Date: Thu, 7 Jul 1994 15:35:29 -0500 (EST)
N>Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US
N>From: "Daniel L. McDonald" <danmcd@sundance.itd.nrl.navy.mil>
N>Cc: mankin@cmf.nrl.navy.mil, sob@hsdndev.harvard.edu,
N> "Daniel L. McDonald" <danmcd@sundance.itd.nrl.navy.mil>
N>Message-Id: <9407072035.aa15952@sundance.itd.nrl.navy.mil>

>> Hi, TUBA, SIPP, CATNIP, BIG-INTERNET, and IETF:

N>Hi from SIPP, IETF, and BIG-INTERNET.

>> At this time it would appear to us that there is considerable consensus
>> that a fixed length, topologically structured, hierarchical

N>Yes, you said the magic words, "FIXED LENGTH." I have espoused the virtues
N>of fixed length addresses before. My biggest beef with variable length
N>addresses is the issue of maintaining additional state or taking additional
N>time to parse an address whose length I don't know at the start. Granted,
N>flow ID's and optimizing for certain common ("fast path") cases may help
N>this, but flow ID's still require tables with flow ID's for keys, and
N>today's common case may be tomorrow's exception. Authentication and
N>encryption also present problems similar to flow ID's with key lookup. I
N>don't want to rewrite my (statically configured) OS kernel in 4 years when
N>today's common cases no longer exist. (Although, admittedly, current trends
N>in OS research may render this argument obsolete.)

N>Parsing addresses is a problem all along the path (both network hops, and
N>within each system) an IPng datagram takes. Both routers and end-systems
N>have to parse addresses, at least to the point of finding a fast path. Our
N>implementation experience has shown us that variable length addresses adds a
N>whole new layer of complexity to things such as:

N> * Routing lookups
N> * User interface issues
N> * Storage requirements
N> * Address parsing (for lookups, incoming packets, etc.)

N>Yes, you said the magic words, "FIXED LENGTH." I have espoused the virtues
N>of fixed length addresses before. My biggest beef with variable length
N>addresses is the issue of maintaining additional state or taking additional
N>time to parse an address whose length I don't know at the start. Granted,
N>flow ID's and optimizing for certain common ("fast path") cases may help
N>this, but flow ID's still require tables with flow ID's for keys, and
N>today's common case may be tomorrow's exception. Authentication and
N>encryption also present problems similar to flow ID's with key lookup. I
N>don't want to rewrite my (statically configured) OS kernel in 4 years when
N>today's common cases no longer exist. (Although, admittedly, current trends
N>in OS research may render this argument obsolete.)

N>Parsing addresses is a problem all along the path (both network hops, and
N>within each system) an IPng datagram takes. Both routers and end-systems
N>have to parse addresses, at least to the point of finding a fast path. Our
N>implementation experience has shown us that variable length addresses adds a
N>whole new layer of complexity to things such as:

N> * Routing lookups
N> * User interface issues
N> * Storage requirements
N> * Address parsing (for lookups, incoming packets, etc.)

N>Since it is still fixed length it has none of the nightmares of
N>variable-length addresses.

>> longer than 16 byte fixed length address now.

N>I would like to see why we NEED any address space above 16-bytes. Does
N>anyone have any solid arguments as to why 16 bytes is not enough? I've seen
N>ones for 8, but not 16.

N>Also, let's consider alignment issues if picking a size above 16 bytes. 20
N>blows 8-byte alignment, 24 does not. (But of course, if 128-bit machines
N>happen, 24-byte addresses will be annoying on 128-bit machines.)

N>But hey, at least it's fixed length.

>> only 16 byte length addresses now but ability
>> to lengthen the address later.

N>This will add confusion to implementations, and smacks of variable-length.
N>Experience with OSI implementations shows that many do not handle NSAP's
N>greater than 20 bytes.

N>Absolutely not a good idea.

>> At this point the consensus among the IPng directorate
>> and on several of the mailing lists seems fairly clear
>> (a 16 byte length address is good for those things).

N>Yes, but IMHO, no MORE than 16 bytes.

>> This is a good time to bring forward your remaining views
>> about the requirements for address length for IPng.

N>My position can be best summarized as:

N> The SMALLEST possible fixed-length address. And that length
N> better have a good justification for why it cannot be smaller.

N>--
N>Dan McDonald | Mail: {danmcd,mcdonald}@itd.nrl.navy.mil --------------+
N>Computer Scientist | WWW: http://wintermute.itd.nrl.navy.mil/danmcd.html |
N>Naval Research Lab | Phone: (202) 404-7122 #include <disclaimer.h> |
N>Washington, DC | "Rise from the ashes, A blaze of everyday glory" — Rush +