[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Draft: PI addressing derived from AS numbers



"J. Noel Chiappa" wrote:
> 
>     > From: Eliot Lear <lear@cisco.com>
> 
>     > 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 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
> locator, something that's already causing us grief.

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.

> (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.)

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

  Brian