Re: [Iot-directorate] [dhcwg] [Last-Call] Iotdir last call review of draft-ietf-dhc-v6only-03

[Jen Linkova <[e-mail]>]

On Fri, Jun 26, 2020 at 9:53 PM Philip Homburg
<[e-mail]> 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