>> Of course, any host can avoid that by running 464xlat. Which just comes at >> the cost of hard to diagnose network problems. Of course this proposal makes >> it even worse by running native IPv4 next to pure NAT64 and 464xlat (and of >> course native IPv6 as well), making it extra hard for any operator to figure >> out what is going on. > >I'm not sure how this proposal is different from having two VLANs - >one is dual-stack and one is IPv6-only. The only difference is that >all hosts belong to one IPv6 subnet. The difference is that you know what you can expect. On a dual stack vlan you have completely standard native IPv4 behavior. On a NAT64 vlan you know you can expect a lot of weirdness that is hard to debug, but atleast you don't have native IPv4 also included in the mix. >Actually you can say exactly the same about any dual-stack network. >It's hard to troubleshoot because sometimes the device is using IPv4, >sometimes it's using IPv6... Which is an unfortunate side-effect of the current state. However, on a dual stack lan, there is exactly one way to do IPv4 and one way to do IPv6. There is not traffic that is actually IPv4 translated to IPv6. On dual stack, an DNS A query is just that, same for AAAA. On NAT64 with DNS64 as is strongly suggested by people in the discussion, AAAA can return a translated address, or is can avoid doing that if a DNSSEC validating resolver asked. A host that uses 464xlat can send A queries and use them. A host without 464xlat may still send A queries and fail, for whatever reason. What if a host receives a broken (according to IPv6 specs) error ICMP and ignores it? Howmany network engineers would correctly diagnose such an issue? >Are you suggesting we move to run IPv4-only hosts and 464xlat on the >first-hop routers? I'm saying that the only sensible way to deploy NAT64 is to do 464xlat on the first hop router. >Unfortunately there are networks where this would not work. I'm not saying that NAT64 should be deployed at all. So if NAT64 doesn't work for a network, then use one of many other ways of providing IPv4, including just providing dual stack. -- last-call mailing list last-call@xxxxxxxx https://www.ietf.org/mailman/listinfo/last-call
