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 mi
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.
> 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 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 tabl
> 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 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 clie
Le 7 juil. 09 à 21:56, Dave Thaler a écrit :
-Original Message-
From: Rémi Després [mailto:remi.desp...@free.fr]
Sent: Tuesday, July 07, 2009 3:03 AM
To: Christian Huitema
Cc: Brian E Carpenter; Xing Li; 6man; Behave WG; Dave Thaler
Subject: Re: Perils of structured host identifiers
> -Original Message-
> From: Rémi Després [mailto:remi.desp...@free.fr]
> Sent: Tuesday, July 07, 2009 3:03 AM
> To: Christian Huitema
> Cc: Brian E Carpenter; Xing Li; 6man; Behave WG; Dave Thaler
> Subject: Re: Perils of structured host identifiers (was: Modifie
Christian Huitema wrote:
[...]
> Structured identifiers are not compatible with privacy address
> extensions. Moreover, embedding addresses in identifiers discloses
> information that would otherwise have remained hidden behind the NAT
> and the firewall. The IPv4 address encoded in the host identi
On 7 jul 2009, at 20:27, Christian Huitema wrote:
I'm not seeing this.
vXuser - routers -- vXserver
v6user - NAT64 -- v4server
In the first case, the addresses are visible everywhere. In the
second
case, the destination address (in one form or another) is visible
everywhe
> I'm not seeing this.
>
> vXuser - routers -- vXserver
>
> v6user - NAT64 -- v4server
>
> In the first case, the addresses are visible everywhere. In the second
> case, the destination address (in one form or another) is visible
> everywhere. How is this suddenly a privacy issue?
CGA are not only used in SEND, but also in SHIM6, and they have a clear
potential in other applications. You can take the narrow view that CGA are only
useful to secure neighbor discovery, but doing that limits any future
application.
Iljitsch makes another point, that CGA are inherently not us
May I throw a dose of caution in this debate about host identifiers formats?
Many transition mechanisms rely on encoding information in the 64 bit host
identifier. This is of course a tempting design point, because it diminishes
the amount of state that servers have to keep. For example, Teredo
Le 7 juil. 09 à 15:40, Christian Huitema a écrit :
CGA are not only used in SEND, but also in SHIM6, and they have a
clear potential in other applications.
I agree that other useful uses of CGAs are possible.
For those where CGAs never appear in link-layer addresses, compliance
with the u-
On 7 jul 2009, at 15:40, Christian Huitema wrote:
I think Iljitsch missed the point about privacy. Consider an IPv4
enterprise network manager that wants to gain IPv6 access. Embedding
the internal IPv4 addresses in the IPv6 address makes these
addresses public, while previously they were p
Christian,
Thanks for this analysis.
Caution is indeed a must before any amendment of a basic document.
As my proposal is, its relationship with cryptographically generated
addresses (and with secure neighbor discovery which uses it) should
however not be a problem.
The proposal is, in sho
16 matches
Mail list logo
