> -----Original Message----- > From: marcelo bagnulo braun [mailto:[EMAIL PROTECTED] > Sent: Monday, July 21, 2008 4:01 AM > To: [email protected] > Cc: Dave Thaler; Dan Wing; Jari Arkko; Iljitsch van Beijnum; Philip > Matthews; Brian E Carpenter; Alberto García > Subject: practical issues with using v4-mapped addresses for nat64 > > Hi, > > (discussing this in int area rather than behave following the > guidelines > of the ADs) > > Dave suggested that we could use v4-mapped addresses to represent v4 > addresses in v6 land, when using the nat64. > > This has the advantage that dual stack nodes will automatically prefer > native v6 connectivity cause the rfc3484 default policy table implies > that. > > (the main argument is that if we use a different prefix, dual stack > hosts will need to implement some way to determine which is translated > connectivity vs translated connectivity, so legacy hosts, will not be > able to distinguish that and may end up using translated connectivity > and the apps that don't work through nat would fail) > > We have been doing some tests about how current OSes work with v4- > mapped > addresses and the results are not very encouraging. > > We (well, mostly Iljitsch actually) have made the following simple > trial > scenario. > > We have a IPv6 server and we have created the following RR: > > All under runningipv6.net: > > test1 IN AAAA ::ffff:83.149.65.1 > > test2 IN AAAA ::ffff:83.149.65.1 > IN AAAA 2001:1af8:2:5::2 > > note that ::ffff:83.149.65.1 is unreachable in IPv6, but 83.149.65.1 is > reachable in IPv4. > > So, when we have a dual stack machine as a source, the following > happens > when we try to go to these FQDNs using Safari on Mac or IE on Vista (we > captured the packets to determine which IP version was used): > > Both Windows vista and MacOS Leopard Dual stack connecting to test1: it > works so it sends IPv4 packets... this seems reasonable, but i wonder > if > it is always ok. > Both Windows vista and MacOS leopard Dual stack sending to test2: it > works and it they both send IPv6 packets, (this is what we want!)
Yes, this is excellent news. > When we have a source machine that is v6-only (i.e. the v4 stack is > disabled), the following happens: > MacOs Leopard v6-only stack sending to test1: doesn't send any packets > Windows vista sending packets to test1: doesn't send any packet > > MacOs Leopard v6-only sending packets to test2: stalled and then works > using v6 packets, so it seemed it has preferred first the mapped > address > and then fall back to the real v6 > Windows vista sending packets to test2: it works, so it preferring the > real v6 address right away > > So, the conclusion from this is that we have a problem with v6 only > hosts, since they seem to assume that v4-mapped are not usable when the > v4 stack is down, even when they get this address in a dns AAAA RR. > So according to this, using the v4-mapped address would imply that v6 > only nodes would not work and would need updating. If this is the case, > then i think we are better of with the other failure mode i.e. dual > stack nodes sometimes preferring translated connectivity i think, cause > seems a less severe failure and can be avoided by not exposing > synthetic > AAAA RR to dual stack hosts (which can be done by having no DNS64 > functionality in the NDS server that is serving the dual stack hosts) > > (the other possibility is that we got our tests wrong :-) We did this > in > a minute, so it may well be wrong. > So this needs host updates in the most popular OSes. 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. Hence while I agree that the OS's tested appear to be problematic, it's not clear to me that that's a very useful data point. Remember that the case you're evaluating here is a dual-IP-version network, not a v6-only network (I believe we already agreed the question is moot in a v6only network). If you have a dual-IP-version network and a host OS that supports both IPv4 and IPv6, why would anyone disable IPv4 on the host? That doesn't seem like a very important case to me. The real v6-only scenario you want to test is stacks/devices that have _no_ IPv4 implementation at all, and you want to know whether those treat v4mapped addresses the same way as any other native IPv6 address when connected to a dual-IP-version network. -Dave > Alternatively, we > could depend on the fact that A records result in v4-mapped addresses > in > the stack anyway and forego the DNS64 step, but in that case changes > are > also necessary because the resolver only provides v4-mapped addresses > to > applications when there is IPv4 reachability. > > We have left the RR in the server, in case anyone else want to try them > and share the results. > > We have additional RR so you can have more fun > > All under runningipv6.net: > > test1 IN AAAA ::ffff:83.149.65.1 > > test2 IN AAAA ::ffff:83.149.65.1 > IN AAAA 2001:1af8:2:5::2 > > test3 IN AAAA ::ffff:83.149.65.1 > IN A 83.149.65.1 > > test4 IN AAAA ::ffff:83.149.65.1 > IN AAAA 2001:1af8:2:5::2 > IN A 83.149.65.1 > > Regards, Iljitsch and marcelo > _______________________________________________ Int-area mailing list [email protected] https://www.ietf.org/mailman/listinfo/int-area
