On Fri, Jun 26, 2020 at 9:53 PM Philip Homburg <pch-ietf-7@xxxxxxxxxxxxxx> wrote: > >> 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. I'm comparing two troubleshooting flowcharts, one for "a dual-stack vlan + NAT64 vlan", another one is for "a single vlan, the host behaviour is controlled by the host setting the DHCPv4 option". In both cases the logic is: - check if the host is IPv6-only or not; - check if the host is supposed to be IPv6-only or not (either by checking what network segment the host is attached or by checking the DHCPv4 client option config); - check if making host a dual-stack solves the issue (either by moving the host to a dual-stack segment or by changing DHCPv4 client config) - if the issue is IPV6-only related - troubleshoot. I really do not see how/why it matters if I have two segments or one (ex. having one segment is much easier actually - we eliminate a randomness of 'what SSID was that device connected when the issue happened??' > >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. Unless I provide hosts with DNS64 on a dual-stack LAN ;-P > 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? If an engineer is not willing to diagnose such a complex issue they are welcome to configure their DHCP servers so they do not respond with the option. Problem solved. > >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. I do not think many people deploy NAT64 just for sake of deploying NAT64. All cases I know about are driven not by strong affection for NAT64 technology but by the need of migrating to IPv6-only hosts, because dual-stack hosts are not an option anymore. -- SY, Jen Linkova aka Furry -- last-call mailing list last-call@xxxxxxxx https://www.ietf.org/mailman/listinfo/last-call
