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

[Lorenzo Colitti <[e-mail]>]

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]> 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]>
> > Sent: mercredi 24 juin 2020 02:20
> > To: Pascal Thubert (pthubert) <[e-mail]>
> > Cc: [e-mail]; [e-mail];
> > [e-mail]; [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]> 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
>