Subject: [Last-Call] Iotdir last call review of draft-ietf-dhc-v6only-03

From: Pascal Thubert via Datatracker <[email-masked]>
Date: Tue, 23 Jun 2020 02:55:34 -0700

Reviewer: Pascal Thubert
Review result: Ready with Issues

draft-ietf-dhc-v6only-03 IOT-DIR review
_______________________________________

   This document specifies a DHCPv4 option to indicate that a host
   supports an IPv6-only mode and willing to forgo obtaining an IPv4
   address if the network provides IPv6 connectivity. It is very readable
   and provides a clear justification of why the DHCP-based solution is
   well suited to address the problem.

   "
                                             ... IPv6-only mode (either
   because the OS and all applications are IPv6-only capable or because
   the host has some form of 464XLAT [RFC6877] deployed),
   "
   Do we have a good reference of what we mean by the v6-only mode of a host
   - or an interface for that matter ?

   Else it would help to define it before we use it. Note, the terminology
   defines a "IPv6-only capable host" but not the "mode".

   "
   A DHCPv4 client SHOULD allow a device administrator to configure
   IPv6-only preferred mode
   "
   and later
   "
                                 In a typical deployment scenario, a
   network administrator would not configure the DHCPv4 server to return
   the IPv6-only Preferred option unless the network provides NAT64
   service.

   ...

   However it seems unlikely that any new transition technology would
   arise and be widely adopted in any foreseeable future.  Therefore
   adding support for non-existing technologies seems to be suboptimal
   and the proposed mechanism implies that NAT64 is used to facilitate
   connectivity between IPv6 and IPv4.
   "

   I have a hard time with that one. Adding a byte or 2 of flags in the
   IPv6-Only Preferred option to indicate that the network supports NAT64
   and having the host request the address if it needs the service and it's not
   there does not seem to cost a lot and protects the future.

---

From: "Eric Vyncke (evyncke)" <[email-masked]>
Date: Tue, 23 Jun 2020 13:18:39 +0000

Thank you Pascal for your extensive review.

-éric

-----Original Message-----
From: Pascal Thubert via Datatracker <[email-masked]>
Reply-To: Pascal Thubert <[email-masked]>
Date: Tuesday, 23 June 2020 at 11:55
To: "[email-masked]" <[email-masked]>
Cc: "[email-masked]" <[email-masked]>, "[email-masked]" <[email-masked]>, "[email-masked]" <[email-masked]>
Subject: Iotdir last call review of draft-ietf-dhc-v6only-03
Resent-From: <[email-masked]>
Resent-To: Lorenzo Colitti <[email-masked]>, <[email-masked]>, <[email-masked]>, <[email-masked]>, <[email-masked]>, <[email-masked]>, Eric Vyncke <[email-masked]>, <[email-masked]>, Bernie Volz <[email-masked]>
Resent-Date: Tuesday, 23 June 2020 at 11:55

    Reviewer: Pascal Thubert

       "

       "

       ...

---

From: Lorenzo Colitti <[email-masked]>
Date: Wed, 24 Jun 2020 00:12:08 +0900

>    there does not seem to cost a lot and protects the future.

We (the authors) did discuss this at some length and we opted for the
current behaviour for reasons of simplicity. Here are a few reasons why:

   1. Typically, DHCP clients do not often provide information to the DHCP
   server in options (except perhaps the vendor class identifier). Mostly, the
   client puts options in the PRL, and the server includes (or not) the
   options that were requested. So, using only one option the client cannot
   easily indicate to the server "I support transition mechanisms A, B, and
   D". The server would have to return a bitmap of all the transition
   technologies that the network supports. The client would then have to check
   whether it supported one of those technologies, and if it did not support
   any, would proceed with a DHCPREQUEST as normal. This means that the server
   must consider the case where the client asked for the IPv6-only option but
   then proceed to request IPv4. This complicates server implementation
   compared to the current draft, where the server can simply respond with
   0.0.0.0 and the client MUST NOT request it.
   2. A bitmask of transition mechanisms would require defining a new
   registry, a process for creation of new options, etc.
   3. A bitmask of transition mechanisms would not be sufficient if the
   network operator wished to place the transition mechanisms in some priority
   order ("use NAT64 if you support it, otherwise use 4rd and otherwise
   MAP-T"). This would then have to become a list of options.

That complexity is a downside of supporting multiple transition mechanisms.
And the upside is limited. We do feel that the likelihood of another
transition technology becoming widely used by end hosts is low, because
NAT64 is already so widely deployed and so easy to implement in hosts. (In
fact, if the host doesn't care about IPv4 literals or IPv4-only apps, the
work required to implement NAT64 is actually zero.) Additionally, if a new
transition technology does end up being widely supported by hosts, it's
always possible to define a new DHCP option code for it.

So we felt that it was best to keep this option simple. IIRC (but other
authors and chairs, please correct me if I'm wrong) there was not much
discussion in the WG that this should be changed, so I think the WG was
pretty happy with the current semantics.

Cheers,
Lorenzo

---

From: "Pascal Thubert (pthubert)" <[email-masked]>
Date: Tue, 23 Jun 2020 16:36:12 +0000

Hello Lorenzo:

I agree with 1 2 and 3. 1 and 2 in particular are not overly complex to specify and code, and seem pretty useful. 3 is more complex and more on the nice-to-have side. I would have done one and 2. But hey, the consensus can be otherwise.

I’m concerned because this transition seems to last a lot longer than we thought. It may last 20 more years, or never really end. We may not have seen something coming that will make it so that a node that needs NAT64 may be fooled in a network that has something newer.

Now, if you have an escape strategy for that day like this other option and you can prove there’s no place for backward compatibility problem at that time, then fine with me. Also fine with me is if that draft is only for NAT64, in which case you could even have NAT64 in the name of the option to make things clearer.

If the consensus is to go without any of the above, well, that what consensus is for. I’ll keep fingers crossed…

Take care,

Pascal

From: Lorenzo Colitti <[email-masked]>
Sent: mardi 23 juin 2020 17:12
To: Pascal Thubert (pthubert) <[email-masked]>
Cc: [email-masked]; [email-masked]; [email-masked]; [email-masked]
Subject: Re: Iotdir last call review of draft-ietf-dhc-v6only-03

On Tue, Jun 23, 2020 at 6:55 PM Pascal Thubert via Datatracker <[email-masked]<mailto:[email-masked]>> wrote:

We (the authors) did discuss this at some length and we opted for the current behaviour for reasons of simplicity. Here are a few reasons why:

  1.  Typically, DHCP clients do not often provide information to the DHCP server in options (except perhaps the vendor class identifier). Mostly, the client puts options in the PRL, and the server includes (or not) the options that were requested. So, using only one option the client cannot easily indicate to the server "I support transition mechanisms A, B, and D". The server would have to return a bitmap of all the transition technologies that the network supports. The client would then have to check whether it supported one of those technologies, and if it did not support any, would proceed with a DHCPREQUEST as normal. This means that the server must consider the case where the client asked for the IPv6-only option but then proceed to request IPv4. This complicates server implementation compared to the current draft, where the server can simply respond with 0.0.0.0 and the client MUST NOT request it.
  2.  A bitmask of transition mechanisms would require defining a new registry, a process for creation of new options, etc.
  3.  A bitmask of transition mechanisms would not be sufficient if the network operator wished to place the transition mechanisms in some priority order ("use NAT64 if you support it, otherwise use 4rd and otherwise MAP-T"). This would then have to become a list of options.
That complexity is a downside of supporting multiple transition mechanisms. And the upside is limited. We do feel that the likelihood of another transition technology becoming widely used by end hosts is low, because NAT64 is already so widely deployed and so easy to implement in hosts. (In fact, if the host doesn't care about IPv4 literals or IPv4-only apps, the work required to implement NAT64 is actually zero.) Additionally, if a new transition technology does end up being widely supported by hosts, it's always possible to define a new DHCP option code for it.

So we felt that it was best to keep this option simple. IIRC (but other authors and chairs, please correct me if I'm wrong) there was not much discussion in the WG that this should be changed, so I think the WG was pretty happy with the current semantics.

Cheers,
Lorenzo

---

From: Philip Homburg <[email-masked]>
Date: Tue, 23 Jun 2020 19:07:12 +0200

>    Now, if you have an escape strategy for that day like this other
>    option and you can prove there's no place for backward compatibility
>    problem at that time, then fine with me. Also fine with me is
>    if that draft is only for NAT64, in which case you could even
>    have NAT64 in the name of the option to make things clearer.

Another way to look at it:
I consider NAT64-to-hosts a really bad idea. Implementing 464xlat in a CPE
or other router is not that bad, but making sure that every host in your
network can properly support NAT64 or 464xlat is not something you should
want.

What if some of your hosts are doing native IPv4 and some NAT64, that makes
troubleshooting even worse.

NAT64 looks good from a network management point of view because a large part
of your network can unaware of IPv4. However, with this option all of your 
network needs to provide native IPv4 and you need to deal with NAT64 as well.

In the far future, it is possible that networks will stop supporting IPv4
and that some hosts connect to a IPv4 service somewhere in the internet.

So, it is likely that any other protocol would go the same route? Is there
a benefit for hosts that do not implement NAT64 to set this option?

In the unlikely case we get there, we can probably allocate a new option.

---

From: Michael Richardson <[email-masked]>
Date: Tue, 23 Jun 2020 13:26:39 -0400

> network can properly support NAT64 or 464xlat is not something you should

Huh? NAT64 can involves no host changes at all (other than not having IPv4 to
succeed in network attachment, and as Lorenzo said, IPv4 literals in some ancient protocols).

    > troubleshooting even worse.

Yes, what if.

You'll know which hosts are doing native IPv4 (native, to me, btw, means
public IPv4. I think you mean NAT44. Some hosts do NAT44 and some do NAT64 to
reach IPv4 addresses)

But, hosts that support being IPv6-only will set the flag, and older hosts
will not.  So over time, all the hosts are IPv6-only.

The alternative is that lots of hosts are dual-stack.

    > a benefit for hosts that do not implement NAT64 to set this option?

Mostly, "hosts" do not implement NAT64, they run IPv6 and avoid IPv4.

--
Michael Richardson <[email-masked]>, Sandelman Software Works
 -= IPv6 IoT consulting =-

---

From: Ted Lemon <[email-masked]>
Date: Tue, 23 Jun 2020 13:28:56 -0400

> network can properly support NAT64 or 464xlat is not something you should

On the other hand, if you use 464xlat, it means that every endpoint needs to speak IPv4. This is a significant added cost for constrained devices. So requiring IPv4 and 464xlat on these devices seems like a much higher cost than using NAT64 for the cases where some non-constrained endpoint can’t speak IPv6 for some reason, or isn’t reachable over IPv6. The set of cases where this is necessarily true may not be that large. E.g., the most sensible case would be connecting to the cloud; in this case, NAT64 works fine.

---

From: Philip Homburg <[email-masked]>
Date: Tue, 23 Jun 2020 19:39:44 +0200

>succeed in network attachment, and as Lorenzo said, IPv4 literals in some ancien

I don't know if you consider http://192.0.2.1/ an ancient protocol, but this
is typically something that breaks with NAT64.

However, NAT64 is also a complete violation of core IPv6 standards.
1) RFC 4443 (ICMP6) Section 2.4, (c):
    Every ICMPv6 error message (type < 128) MUST include as much of
    the IPv6 offending (invoking) packet (the packet that caused the
    error) as possible without making the error message packet exceed
    the minimum IPv6 MTU [IPv6].

  There is no way an NAT64 gateway is going to make that work. Worse, RFC 4884
  put funny bits at ofset 128. 

2) IPv4 links can have MTUs lower than 1280. Again this is incompatible with 
   IPv6 specifications.

Then, if you say no host changes required, you imply the use of DNS64, which is
incompatible with a DNSSEC validating resolver on the host (unless that 
resolver is aware of the presence of DNS64).

---

From: Michael Richardson <[email-masked]>
Date: Tue, 23 Jun 2020 14:56:34 -0400

> is typically something that breaks with NAT64.

Yes, I do consider it past it's time, but not as ancient as FTP.
It does have literals in the protocol, in the Host: header.

https://192.0.2.1/ is the modern equivalent, and due to the IPv4 literal,
does not get security, so it doesn't work.

---

From: Jen Linkova <[email-masked]>
Date: Wed, 24 Jun 2020 10:20:16 +1000

Hi Pascal,

Thank you for reviewing the document.
I believe Lorenzo explained why the draft supports NAT64 only.

Re: the terminology comment:
On Tue, Jun 23, 2020 at 7:55 PM Pascal Thubert via Datatracker
>    defines a "IPv6-only capable host" but not the "mode".

I'll update the Terminology section with the following definition:
IPv6-only mode as 'a mode of operation when a host acts as IPv6-only
capable and does not have IPv4 addresses assigned (except for IPv4
link-local
   address [RFC3927]).

Would it address your comment?

--
SY, Jen Linkova aka Furry

---

From: Lorenzo Colitti <[email-masked]>
Date: Wed, 24 Jun 2020 10:17:41 +0900

> troubleshooting even worse.

I think these arguments apply to any host-based transition technology, and
any network that mixes IPv4-capable and IPv6-only devices. So in that
sense, it doesn't seem to argue either for or against supporting multiple
transition mechanisms in this option.

> In the unlikely case we get there, we can probably allocate a new option.

Right.

---

From: Lorenzo Colitti <[email-masked]>
Date: Wed, 24 Jun 2020 10:42:57 +0900

On Wed, Jun 24, 2020 at 1:36 AM Pascal Thubert (pthubert) <
[email-masked]> wrote:

> Now, if you have an escape strategy for that day like this other option
> and you can prove there’s no place for backward compatibility problem at
> that time, then fine with me. Also fine with me is if that draft is only
> for NAT64, in which case you could even have NAT64 in the name of the
> option to make things clearer.
>

I think the escape strategy here is to define a new DHCPv4 option, yes.

As for putting NAT64 in the name of the option, I'm not sure that's
particularly useful. The only case in which this would make a difference is
if a new transition technology becomes widely deployed - otherwise it
doesn't matter what the name is. If the new technology is mostly
transparent to hosts just like NAT64 is, then we would want to continue to
use the same option. If we put NAT64 in the name of the option we might not
be able to do that easily. So that argues against making the option more
"NAT64 specific" than it already is.

I think the only case for making the option more "NAT64 specific" is if a
new transition technology becomes widely deployed which is *not*
transparent to hosts (i.e., it requires hosts to do work to support IPv4),
and the technology is successful enough (and enough time has passed) that
all hosts of interest support that option, and no longer support NAT64. In
that case, the option currently being defined in this draft would no longer
be useful.

Like I said, this all seems pretty unlikely to me. In particular it seems
unlikely that a transition technology would become widely deployed if it
requires hosts to do work - there doesn't seem to be much of an incentive
for that to happen given that NAT64 is widely deployed (and thus
deployable) and requires zero work for hosts. Additionally, as IPv6-only
networks become more deployed and IPv4-only apps age out, the incentive to
do that work reduces, and it seems likely that any new transition
technology that is defined will be transparent to hosts because things like
IPv4 literals and IPv6-only apps are a thing of the past.

Further, any new technology that we expect to be used on hosts will need to
consider the impact on legacy NAT64-capable hosts, and there will be an
incentive to make those hosts work. So at that time, we might find a better
migration strategy than to define a new option and we can update this
document with the result.

---

From: Michael Richardson <[email-masked]>
Date: Tue, 23 Jun 2020 23:29:16 -0400

> "NAT64 specific" than it already is.

I strongly agree with you -- putting the name in does not particularly help,
I think.

I am less convinced that having the name would harm us in the end, if we
picked it carefully, but I have a hard time finding that name.

The key point of the option is that host does not need IPv4.
I agree with some commenters that it isn't obvious that it implies that NAT64
is available.  But, we have other signals for that, I think.

NAT64 puts *no* requirements on the hosts (except that they be willing to
succeed network attachment without IPv4).
I can imagine some other v6-over-v4 mechanism (inspired by 6to4, or Teredo perhaps) could
perhaps be introduced which did not involve the network creating state.
But in that case, it would also be transparent to the end host, as you say.

--
]               Never tell me the odds!                 | ipv6 mesh networks [
]   Michael Richardson, Sandelman Software Works        |    IoT architect   [
]     [email-masked]  http://www.sandelman.ca/        |   ruby on rails    [

---

From: [email-masked]
Date: Wed, 24 Jun 2020 09:04:16 +0200

> succeed network attachment without IPv4).

Apart from forcing all IPv6 applications to be compliant with the NAT "architecture".

Ole

---

From: "Pascal Thubert (pthubert)" <[email-masked]>
Date: Wed, 24 Jun 2020 07:57:06 +0000

Hello Jen

That's great. I realize that I'm asking you to state the perfectly obvious for someone who designs a phone in 2020. 
Still that context scopes the applicability of the draft, which is a lot more than that. 

Ideally that definition would indicate that the IPv6 only mode may include:
1) accessing IPv4 services via a fully transparent mapping system such as NAT64
2) translating or tunneling IPv4 traffic to traverse the v6-only network such as 464XLAT

This way we can say later in the spec that 
-if the transition mechanism is not fully transparent to the host then the server MUST NOT place the option, 
- the mechanism is compatible with solutions based on NAT64, DNA64 and XLAT, and also any other fully transparent mechanism.

The goal is to be prepared for that future where another mechanism becomes prevalent that requires host attention.

Take care,

Pascal

> From: Jen Linkova <[email-masked]>
> Sent: mercredi 24 juin 2020 02:20
> Cc: [email-masked]; [email-masked];
> [email-masked]; [email-masked]
> Subject: Re: [dhcwg] Iotdir last call review of draft-ietf-dhc-v6only-03
> 
> Hi Pascal,
> 
> IPv6-only mode as 'a mode of operation when a host acts as IPv6-only capable
> and does not have IPv4 addresses assigned (except for IPv4 link-local
>    address [RFC3927]).
>

---

From: "Pascal Thubert (pthubert)" <[email-masked]>
Date: Wed, 24 Jun 2020 08:10:02 +0000

Hello Lorenzo and Michael;

I tried to digest that in my other mail to Jen; I’d be perfectly happy if the escape strategy is to define the properties of the transition mechanisms that are compatible with the option and if there’s text that tells the server not to place the option if the mechanisms in place are not compatible, see my other message.

What’s to answer is that all the below makes sense to me, and I’ll trust you on likelihood. If a condensate of that could find a way to the section 4, that would probably make the rest of the way through IESG smoother for the document.

Take care,

Pascal

Sent: mercredi 24 juin 2020 03:43

On Wed, Jun 24, 2020 at 1:36 AM Pascal Thubert (pthubert) <[email-masked]<mailto:[email-masked]>> wrote:
Now, if you have an escape strategy for that day like this other option and you can prove there’s no place for backward compatibility problem at that time, then fine with me. Also fine with me is if that draft is only for NAT64, in which case you could even have NAT64 in the name of the option to make things clearer.

As for putting NAT64 in the name of the option, I'm not sure that's particularly useful. The only case in which this would make a difference is if a new transition technology becomes widely deployed - otherwise it doesn't matter what the name is. If the new technology is mostly transparent to hosts just like NAT64 is, then we would want to continue to use the same option. If we put NAT64 in the name of the option we might not be able to do that easily. So that argues against making the option more "NAT64 specific" than it already is.

I think the only case for making the option more "NAT64 specific" is if a new transition technology becomes widely deployed which is *not* transparent to hosts (i.e., it requires hosts to do work to support IPv4), and the technology is successful enough (and enough time has passed) that all hosts of interest support that option, and no longer support NAT64. In that case, the option currently being defined in this draft would no longer be useful.

Like I said, this all seems pretty unlikely to me. In particular it seems unlikely that a transition technology would become widely deployed if it requires hosts to do work - there doesn't seem to be much of an incentive for that to happen given that NAT64 is widely deployed (and thus deployable) and requires zero work for hosts. Additionally, as IPv6-only networks become more deployed and IPv4-only apps age out, the incentive to do that work reduces, and it seems likely that any new transition technology that is defined will be transparent to hosts because things like IPv4 literals and IPv6-only apps are a thing of the past.

Further, any new technology that we expect to be used on hosts will need to consider the impact on legacy NAT64-capable hosts, and there will be an incentive to make those hosts work. So at that time, we might find a better migration strategy than to define a new option and we can update this document with the result.

---

From: Lorenzo Colitti <[email-masked]>
Date: Wed, 24 Jun 2020 17:45:34 +0900

> Apart from forcing all IPv6 applications to be compliant with the NAT

That's true, unfortunately. That said, I think it'ss also the only
transition mechanism that works without the host having an ipv4 address,
and thus the only one that is a step along the way to true IPv6-only hosts.

---

From: Philip Homburg <[email-masked]>
Date: Wed, 24 Jun 2020 11:14:56 +0200

>    That's true, unfortunately. That said, I think it'ss also the
>    only transition mechanism that works without the host having an
>    ipv4 address, and thus the only one that is a step along the
>    way to true IPv6-only hosts.

Making IPv6 hosts deal with all the brokenness of IPv4, which includes NAT,
small PMTUs, bad ICMPs, is not progress. And then the way DNS64 breaks with
local DNSSEC validation is another negative factor.

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.

This is just something that should not be deployed.

---

From: Lorenzo Colitti <[email-masked]>
Date: Wed, 24 Jun 2020 18:17:41 +0900

On Wed, 24 Jun 2020, 18:15 Philip Homburg, <[email-masked]>
wrote:

> And then the way DNS64 breaks with

I'm not sure that's actually a problem TBH. Most popular implementations
support DNS64 synthesis these days. Certainly I would expect more hosts to
support DNS64 synthesis then to support DNSSEC.

---

From: Jen Linkova <[email-masked]>
Date: Thu, 25 Jun 2020 09:14:13 +1000

> course native IPv6 as well), making it extra hard for any operator to figure

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.
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...
I found it *much* easier to capture/troubleshoot flows in one protocol
than in two.

> This is just something that should not be deployed.

Are you suggesting we move to run IPv4-only hosts and 464xlat on the
first-hop routers?
Unfortunately there are networks where this would not work.

---

From: Michael Richardson <[email-masked]>
Date: Thu, 25 Jun 2020 10:18:19 -0400

> Apart from forcing all IPv6 applications to be compliant with the NAT "architecture".

When you say NAT "architecture", you are thinking, I guess of:
    - no IP address literals in protocol
    - no call-back patterns, like FTP, SIP,
    - UDP or TCP only

But, I don't think that's true.

Yes, it requires all IPv4-only end points (servers, etc.) to be compliant with the
NAT "architecture", but they already have to do that.
I think that IPv6-only applications are free to do anything they want.

---

From: [email-masked]
Date: Thu, 25 Jun 2020 16:28:59 +0200

Michael,

>    - no call-back patterns, like FTP, SIP,

and support NAT traversal (ICE, STUN...)
PCP...

> I think that IPv6-only applications are free to do anything they want.

Please explain why that's not true?

IPv6 only application --- NAT64 --- IPv4 only application

Cheers,
Ole

---

From: Philip Homburg <[email-masked]>
Date: Fri, 26 Jun 2020 13:53:29 +0200

>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.

>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

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.

---

From: Jen Linkova <[email-masked]>
Date: Mon, 29 Jun 2020 11:38:40 +1000

> 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??'

> not traffic that is actually IPv4 translated to IPv6.

Unless I provide hosts with DNS64 on a dual-stack LAN ;-P

> 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.

> 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.

---

From: Michael Richardson <[email-masked]>
Date: Sun, 28 Jun 2020 23:25:54 -0400

> the host to a dual-stack segment or by changing DHCPv4 client config)

I think, if the DHCPv4-server can be told to selectively ignore the
dhc-v6only option for that host, that we can make it dual-stack without
touching the client config.

The host would think it's on a network that doesn't offer IPv6-only.

So I think that the option makes troubleshooting easier :-)

---

From: Lorenzo Colitti <[email-masked]>
Date: Tue, 30 Jun 2020 00:54:54 +0900

So, to come back to the original reason for this thread: after thinking
about Pascal's suggestion, I'm not sure that we can come up with a
definition of "transparent" that we can confidently state will match
as-yet-undefined transition mechanisms for which this option would be
appropriate.

The first part of Pascal's definition ("accessing IPv4 services via a fully
transparent mapping system such as NAT64") seems easy to understand/define.
But the implementation of the second part ("translating or tunneling IPv4
traffic to traverse the v6-only network such as 464XLAT") is, if you think
about it, actually very specific to NAT64 and 464xlat. If we introduce a
new 4underover6 transition mechanism that is transparent, but is not
compatible with implementations that do IPv4 using 464xlat, then is the
option appropriate or not? I don't think it's easy to make that
determination today because we don't know how 4underover6 works. But
when we do define 4overunder6, and know how it works, it will be easy to
decide whether this option is appropriate. And in fact, 4underover6 might
even be intentionally designed to work well with this option. At that time,
it will be easy to update this RFC saying whether networks that use
4underover6 can use the option and under which circumstances.

So I think I would still prefer to leave this option as being
NAT64-specific. And I really don't think there's much of a downside,
because, well... YAGNI. I really don't see another transition technology
becoming widely deployed at this point, given that NAT64 is already
basically free for hosts to implement.

We could update the document to say that NAT64 is widely deployed, and at
the present time, the wide deployment in hosts of a new transition
technology seems very unlikely given that on IPv6-only networks IPv4 is a
legacy service, and given that NAT64 already provides good compatibility
with little to no implementation required on the host. We could say that if
this is not the case, then a new DHCP option may need to be defined for
that new transition mechanism, unless that new transition mechanism is such
that legacy hosts that only implement NAT64 and 464xlat can use it.

Pascal, would that work for you?

On Wed, Jun 24, 2020 at 4:57 PM Pascal Thubert (pthubert) <
[email-masked]> wrote:

> - the mechanism is compatible with solutions based on NAT64, DNA64 and
> XLAT, and also any other fully transparent mechanism.
>
> capable

---

From: "Pascal Thubert (pthubert)" <[email-masked]>
Date: Mon, 29 Jun 2020 16:16:36 +0000

Sure it would, Lorenzo.

As you point out, NAT64 is a wide enough scope to justify the introduction of option. So if you drink from that cup, we’re all set.
My initial suggestion was along those lines, naming the option based on its scope of applicability, the scope being a network that does NAT64.

The alternative to define transparent etc… was in the case you wished to allow the option in a context that is not NAT64 and not known by a legacy stack that uses the option. In that case you effectively enter the complex game of describing what works and what works not and limit the DHCP server sending the option in the what works case. I agree that’s more complex than useful for the foreseeable future.  I figured you wanted that at some point when you and Michael reacted against placing NAT64 in the name of the option.

Take care,

Pascal

From: Lorenzo Colitti <[email-masked]>
Sent: lundi 29 juin 2020 17:55
To: Pascal Thubert (pthubert) <[email-masked]>
Cc: Jen Linkova <[email-masked]>; [email-masked]; [email-masked]; [email-masked]; [email-masked]
Subject: Re: [dhcwg] Iotdir last call review of draft-ietf-dhc-v6only-03

So, to come back to the original reason for this thread: after thinking about Pascal's suggestion, I'm not sure that we can come up with a definition of "transparent" that we can confidently state will match as-yet-undefined transition mechanisms for which this option would be appropriate.

The first part of Pascal's definition ("accessing IPv4 services via a fully transparent mapping system such as NAT64") seems easy to understand/define. But the implementation of the second part ("translating or tunneling IPv4 traffic to traverse the v6-only network such as 464XLAT") is, if you think about it, actually very specific to NAT64 and 464xlat. If we introduce a new 4underover6 transition mechanism that is transparent, but is not compatible with implementations that do IPv4 using 464xlat, then is the option appropriate or not? I don't think it's easy to make that determination today because we don't know how 4underover6 works. But when we do define 4overunder6, and know how it works, it will be easy to decide whether this option is appropriate. And in fact, 4underover6 might even be intentionally designed to work well with this option. At that time, it will be easy to update this RFC saying whether networks that use 4underover6 can use the option and under which circumstances.

So I think I would still prefer to leave this option as being NAT64-specific. And I really don't think there's much of a downside, because, well... YAGNI. I really don't see another transition technology becoming widely deployed at this point, given that NAT64 is already basically free for hosts to implement.

We could update the document to say that NAT64 is widely deployed, and at the present time, the wide deployment in hosts of a new transition technology seems very unlikely given that on IPv6-only networks IPv4 is a legacy service, and given that NAT64 already provides good compatibility with little to no implementation required on the host. We could say that if this is not the case, then a new DHCP option may need to be defined for that new transition mechanism, unless that new transition mechanism is such that legacy hosts that only implement NAT64 and 464xlat can use it.

On Wed, Jun 24, 2020 at 4:57 PM Pascal Thubert (pthubert) <[email-masked]<mailto:[email-masked]>> wrote:
Hello Jen

Take care,

Pascal

> From: Jen Linkova <[email-masked]<mailto:[email-masked]>>
> To: Pascal Thubert (pthubert) <[email-masked]<mailto:[email-masked]>>
> Cc: [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>;
> [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>
> <[email-masked]<mailto:[email-masked]>> wrote:
> >    "