[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 <email@example.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
> 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
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 :-( .