Iljitsch van Beijnum escribió:
On 8 jul 2009, at 9:42, marcelo bagnulo braun wrote:
for example, suppose you want to run shim6 on the nat64 box, how
would you do it if you cannot use the lower 64 bits to store crypto
info?
So then you would have one NAT64 with two Prefix64s, where the CGA
proves that Prefix64a and Prefix64b belong to the same box? I guess
you could do that. But the assumption with Shim6 is that you have two
ISPs that give you two address ranges. That would only apply if the
NAT64 user and the NAT64 are in different networks, and at least the
NAT64 is multihomed. So:
ISP2
/ \
v6client --- ISP1 NAT64
\ /
ISP3
In my opinion, that would be an extremely unusual case: in networks
large enough to have some IPv4 addresss space, the NAT64 would be done
locally. In smaller networks, the ISP would probably do it. Getting
NAT64 service from a random place somewhere is not impossible, but not
exactly an obvious solution. Especially because the NAT64 service
provider would need a mechanism to authenticate its users.
I agree this case at this point seems far away, but i am not sure i
understand the timeframe where nat64 will be around and how pervasive
they will be.
I was just pointing a case with currently defined technologies that this
would impose a limitation. the goal was just to put an example that it
is possible to find
OTOH, as i said earlier, this can be addressed by using a Pref64 shorter
than 32 bits, so we can embed the IPv4 addres in the prefix part.
Regards, marcelo
We can go out of our way to find strange use cases and build in
support for them, but wasn't the idea that we need to get NAT64 in the
grubby hands of actual users within a reasonable timeframe?
--------------------------------------------------------------------
IETF IPv6 working group mailing list
ipv6@ietf.org
Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------
