Subject: Re: Draft: PI addressing derived from AS numbers

From: "J. Noel Chiappa" <[email-masked]>
Date: Tue, 25 Feb 2003 10:39:29 -0500

> From: Eliot Lear <[email-masked]>

    > So what I'm getting from this discussion is that 8+8 is too late but
    > 16+16 is too large???

I would suggest that 16+16 be done not with a complete second IPv6 header,
but rather one of the routing headers (I forget the formal name). That would
make it somewhat smaller.

Anyway, why does header size matter that much? Those on slow links (< 56K)
will be using header compression anyway, so it doesn't really matter for them
since the average packet will have all that stuff compressed out anyway, and
for those on fast links, who cares about a few extra bytes?

Check out the average web page to see how many stupid little icons it has on
it, how many JavaScript files it loads, how many pop-up windows (with their
own images and Javascript) it loads, etc, etc. (Every Web page designer ought
to be sentenced by law to using a 28.8 modem for all their online access...
but I digress.)

    > I would agree that 16+16 is too large. How about 4+16?  

You mean, wrap an IPv6 packet in an IPv4 packet?

First, that would produce a packet of the exact same length as my suggestion
above (an IPv4 header is 20 bytes, after all).

It would have the advantage that it could be carried over existing
substrate. It would have the disadvantage that you'd be limited to a 32-bit
locator, something that's already causing us grief.

(And don't even *think* about moving some of the "local" topology
information into the IPv6 addresses, leaving only the "global" stuff in the
IPv4 header. Long architectural rant about why you don't spread
functionality across two namespaces left out, as an exercise to the reader.)

	Noel

---

From: Brian E Carpenter <[email-masked]>
Date: Wed, 26 Feb 2003 15:09:02 +0100

"J. Noel Chiappa" wrote:
> substrate. 

It has the further advantage of being already implemented, at
a basic level.

> It would have the disadvantage that you'd be limited to a 32-bit

More precisely, we don't know how to aggregate 32 bit locators
any better than 64 bit locators. 4 billion wide-area locators 
doesn't seem to be too bad in itself.

> functionality across two namespaces left out, as an exercise to the reader.)

Ah, but pragmatic rant about how it's likely to happen anyway
also left out :-( .

  Brian

---

From: David Conrad <[email-masked]>
Date: Wed, 26 Feb 2003 09:52:21 -0800

Brian,

On Wednesday, February 26, 2003, at 06:09  AM, Brian E Carpenter wrote:
> any better than 64 bit locators.

Um.  Yes we do.  It is called CIDR.  It is well understood and has the 
minor advantage of being deployed.  What we don't know how to do is 
aggregate in the face of people refusing to aggregate for 
'non-network-topologic' (e.g., economic, political, business, etc.) 
reasons.  One known and obvious way of doing this is by separating the 
two and providing a mapping.  Locators can then be re-arranged without 
getting into non-network-topologic arguments.

Rgds,
-drc

---

From: Brian E Carpenter <[email-masked]>
Date: Fri, 28 Feb 2003 17:15:34 +0100

I meant that we know how to do it for 64 bits (PA) or 32 bits (CIDR)
equally well. I agree with waht you say.

   Brian