[...] > > 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). 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. 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. 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.) 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). 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). -Dave _______________________________________________ Int-area mailing list [email protected] https://www.ietf.org/mailman/listinfo/int-area
