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

["Pascal Thubert (pthubert)" <[e-mail]>]

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 <[e-mail]>
Sent: lundi 29 juin 2020 17:55
To: Pascal Thubert (pthubert) <[e-mail]>
Cc: Jen Linkova <[e-mail]>; [e-mail]; [e-mail]; [e-mail]; [e-mail]
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.

Pascal, would that work for you?

On Wed, Jun 24, 2020 at 4:57 PM Pascal Thubert (pthubert) <[e-mail]<mailto:[e-mail]>> wrote:
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


> -----Original Message-----
> From: Jen Linkova <[e-mail]<mailto:[e-mail]>>
> Sent: mercredi 24 juin 2020 02:20
> To: Pascal Thubert (pthubert) <[e-mail]<mailto:[e-mail]>>
> Cc: [e-mail]<mailto:[e-mail]>; [e-mail]<mailto:[e-mail]>;
> [e-mail]<mailto:[e-mail]>; [e-mail]<mailto:[e-mail]>
> Subject: Re: [dhcwg] Iotdir last call review of draft-ietf-dhc-v6only-03
>
> 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
> <[e-mail]<mailto:[e-mail]>> wrote:
> >    "
> >                                              ... 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".
>
> 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