What you miss in IPv6.... (Was: Re: Fw: how 200 /48's fails the job [Re: [address-policy-wg] Policy proposal: #gamma IPv6 Initial Allocation Criteria])

On Wed, 2005-04-06 at 21:10 +0200, Florian Weimer wrote:
> * Michael Dillon:
> 
> > If RIPE really and truly believes that IPv6 will become
> > the future core protocol of the public Internet, then RIPE
> > should allocate an IPv6 /32 to every RIPE member who has
> > PI addresses.
> 
> No, if everyone believed that IPv6 is the future, policies would not
> matter much, and there would be little fighting.  Everyone would jump
> through almost any hoop to get what they think they need. 8-)
> 
> But this is not the case.  I don't follow the v6 wars closely, but it
> appears that several promised improvements over v4 won't be delivered
> (look at the A6/bitlabel/DNAME deprecation, or even the protocol
> design optimized for forwarding implementations which now are being
> phased out).

A6 could cause a long chain of servers to be asked where 1 lookup is
enough for normal reverse queries.
Also things as signing would become a large

Bitlabel is just a different way of writing down reverses, which btw
would be incompatible with A6.

DNAME exists and is being used. It is sort of a Domain CNAME :)
How else did you think I aliased ip6.int to ip6.arpa for silly slow
people who do not upgrade their DNS resolvers.

The "protocol design optimized for forwarding implementations". You can
be referring to a couple of things here, though I can tell you that the
header structure is aligned and there is no checksumming anymore, as the
hardware layer usually already does that. This speeds IPv6 up already by
a couple of factors compared to IPv4, even though one has to look at a
128bit address instead of a IPv4 one.

Anything else?

Greets,
 Jeroen

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 240 bytes
Desc: This is a digitally signed message part
URL: </ripe/mail/archives/address-policy-wg/attachments/20050407/e130647b/attachment.sig>