All,
I submitted a new individual draft regarding address selection
policy conflicts.
This document tries to speculate what kind of conflicts we
will have, and how we can address them.
This document is not based on any specific proposed address
selection mechanisms.
I'd like to have comments
On 8 jul 2009, at 15:12, Rémi Després wrote:
The u/l bit is reserved for global use as Brian Carpenter also noted.
Well, it gets complex.
Discussing the point offline in Stockholm might be better than by
mail.
Would that be useful?
The whole point of NAT64 is to work with unmodified
The DNS64 has to stuff the IPv4 bits somewhere in the IPv6 bits.
Although it's simpler to do that at a 32 bit boundary (and a 16 bit
boundary has checksumming advantages), as far as I know all of this
happens in software and can be handled fast enough even if the rules
get more complex to
On 9 jul 2009, at 16:05, Christian Huitema wrote:
The DNS64 does not have to stuff the IPv4 bits somewhere in the
IPv6 bits. It could also use mapping tables to map the IPv4 bits to
arbitrary IPv6 bits.
There are about 3.7 billion usable IPv4 addresses. Do you really want
to make a table
There are about 3.7 billion usable IPv4 addresses. Do you really want
to make a table that big, when the IPv6 host is going to expose
everything to every IPv6 node it talks to anyway?
Very few hosts speak to 3.7 billion peers at the same time. Those who do
probably have dual stack. In most
On 9 jul 2009, at 21:55, Christian Huitema wrote:
There are about 3.7 billion usable IPv4 addresses. Do you really want
to make a table that big, when the IPv6 host is going to expose
everything to every IPv6 node it talks to anyway?
Very few hosts speak to 3.7 billion peers at the same time.
In message 6504f50e-c15b-4233-bd5d-f917f35bb...@muada.com, Iljitsch van Beijn
um writes:
On 8 jul 2009, at 15:12, R=E9mi Despr=E9s wrote:
The u/l bit is reserved for global use as Brian Carpenter also noted.
Well, it gets complex.
Discussing the point offline in Stockholm might be
