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) <pthubert@xxxxxxxxx> 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 <furry13@xxxxxxxxx>
> Sent: mercredi 24 juin 2020 02:20
> To: Pascal Thubert (pthubert) <pthubert@xxxxxxxxx>
> Cc: iot-directorate@xxxxxxxx; draft-ietf-dhc-v6only.all@xxxxxxxx;
> dhcwg@xxxxxxxx; last-call@xxxxxxxx
> 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
> <noreply@xxxxxxxxx> 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
-- last-call mailing list last-call@xxxxxxxx https://www.ietf.org/mailman/listinfo/last-call
