Dave Thaler escribió:
[...]
I think you need to consider what scenario you're targeting NAT-PT
for.
I would argue that a dual-stack OS with IPv4 disabled is not a common
scenario.
why not?
I thought this was one of the primary scenarios..
I mean, i though we were targetting for the case when there are no more
v4 addresses and people deploy v6 networks
People that deploy v6-only networks will just hand out a DNS64 server
address as the IPv6 address all clients should use for their DNS server.
So all I meant is that there's no need to distinguish hosts that are not
IPv4-capable vs hosts that have an IPv4 stack disabled vs hosts that
have both IPv4 and IPv6 enabled (but no IPv4 address).
agree
I think your point is that in an IPv6-only network, native IPv4
obviously won't work, and having v4mapped addresses on the wire won't
work from the current dual-stack OSs tested. So you either need them
fixed or you need them to use some prefix other than the v4mapped range.
exactly
Hence Brian Carpenter's suggestion to default to v4mapped but allow
configuration to support some other prefix, which sounds reasonable.
There's no magic answer that's occurring to me.
this other prefix would be also a global prefix or is a local prefix
assigned by the local network for this (i.e. what we called the Pref64
in the nat64 draft)
However, I would still argue strongly that we should not require changes
to existing dual-stack nodes in order to deploy something that doesn't
break apps. (Requiring changes in IPv6-only nodes is much less bad,
although still undesirable.)
mmm, so you think we should include that in the requirements draft?
(btw i agree with the requirement in general)
For informational purposes, it might be interesting to
repeat your experiments using the range ::/96 (the range reserved for
IPv4-compatible addresses, which were deprecated but are still in
the RFC 3484 table as less preferred than native IPv6, just above
the v4mapped range).
good point
actually this is already contained in the rfc3484 default policy table,
so it would provide the benefits of the v4mapped, maybe withotu the problems
I just tried on Vista SP1 and it does send out a packet natively to
a ::/96 address, although I believe Windows XP still supported
v4-compatible tunnels and so won't (but XP doesn't claim to work
on IPv6-only networks).
good!
we are organizing a trial of this in the v6 only network at the ietf on
sunday, so we cna report back on the meeting
(again, if people are interested to join, let me know)
So, we have then 4 options so far:
- v4mapped prefix
- v4compatible prefix
- another global prefix assigned by iana for this
- use of local prefixes in each site
For me, if the compatible prefix doesn't has the problems of the v4
mapped prefix, would be the best option at this point.
It is not so obvious to me the choice between the last two, though
Regards, marcelo
-Dave
_______________________________________________
Int-area mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/int-area
