Re: [v6ops] [dhcwg] Fwd: New Version Notification for draft-link-dhc-v6only-01.txt

[<[e-mail]>]

Hi Bernie, 

Please see inline. 

Cheers,
Med

> -----Message d'origine-----
> De : Bernie Volz (volz) [mailto:[e-mail]]
> Envoyé : mardi 10 décembre 2019 17:11
> À : BOUCADAIR Mohamed TGI/OLN; Jen Linkova; [e-mail]
> Cc : V6 Ops List
> Objet : RE: [dhcwg] Fwd: New Version Notification for draft-link-dhc-
> v6only-01.txt
> 
> Hi:
> 
> Is (8):
> 
> 	(8) Consider returning an address from the range defined in RFC7335
> for IPv6-only hosts. Such IPv4 addresses are required anyway for some IPv6-
> only hosts (those with a CLAT for example).
> 
> 	====
> 	   The result is that 192.0.0.0/29 may be used in any system
> 	   that requires IPv4 addresses for backward compatibility with IPv4
> 	   communications in an IPv6-only network but does not emit IPv4
> packets
> 	   "on the wire".
> 	====
> 
> But RFC7335 says (in section 4):
> 
>    IANA has defined a well-known range, 192.0.0.0/29, in [RFC6333],
>    which is dedicated for DS-Lite.  As defined in [RFC6333], this subnet
>    is only present between the B4 and the Address Family Transition
>    Router (AFTR) and never emits packets from this prefix "on the wire".
> <---
>    464XLAT has the same need for a non-routed IPv4 prefix, and this same
>    need may be common for other similar solutions.  It is most prudent
>    and effective to generalize 192.0.0.0/29 for the use of supporting
>    IPv4 interfaces in IPv6 transition technologies rather than reserving
>    a prefix for every possible solution.
> 
> So, this address is only used "on the host" (not on the wire), so why would
> there be any need for the DHCP server to assign this address?

[Med] This is to ease remote troubleshooting of the IPv4aaS component (CLAT, B4) of the IPv6-only host. Controlling the IPv4 address configured locally allows to make use of tools such as PROBE (https://tools.ietf.org/html/rfc8335) to remotely assess the status of the IPv4aaS component via an IPv6 network.

> 
> And as the IPv6-only option means that the host never completes the
> DHCPDISCOVER/OFFER/REQUEST/ACK (stops at OFFER), this work could not be
> used to assign any address.
> 
> - Bernie
> 
> -----Original Message-----
> From: dhcwg <[e-mail]> On Behalf Of
> [e-mail]
> Sent: Tuesday, December 10, 2019 5:32 AM
> To: Jen Linkova <[e-mail]>; [e-mail]
> Cc: V6 Ops List <[e-mail]>
> Subject: Re: [dhcwg] Fwd: New Version Notification for draft-link-dhc-
> v6only-01.txt
> 
> Hi Jen,
> 
> Thank you for sharing this updated version. Below some points that I do
> think need more clarification in the I-D:
> 
> (1) The document is too NAT64 centric. The proposal may apply as well for
> other IPv6-only deployment scenarios (typically, unmanaged IPv6-only CPEs
> with IPv4aaS).
> 
> (2) A discussion on the benefit of this extra signal compared to relying on
> existing signals (pref64, aftr_name, map_container...). For example, a host
> that supports the option is ready to wait at minimum 300s and disable its
> IPv4 configuration regardless of what is happening on the IPv6 leg. How is
> that superior to a host delaying DHCP process by xxx ms should be explained
> further.
> 
> (3) How "IPv6-only preferred" mode is supposed to be set at the host side:
> 
> ==
>    A DHCP client SHOULD allow a device administrator to configure
>    IPv6-only preferred mode either for a specific interface (to indicate
>    that the device is IPv6-only capable if connected to a NAT64 network
>    via that interface) or for all interfaces.
> ==
> 
> * I guess the default value when the option is supported by a host is to
> disable including it in the request. The document should include a
> discussion on the default behavior.
> * If an explicit action is needed from the user to enable including the
> option, having a discussion to what extent the feature is likely to be
> enabled would be needed.
> 
> (4) The document is still mixing the DHCP client vs. host behaviors. For
> example,
> 
>    Clients not capable of operating in an IPv6-only NAT64 environment
>    ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
>    MUST NOT include the IPv6-only Preferred option in the Parameter
>    Request List of any DHCP packets and MUST ignore that option in
>    packets received from DHCP servers.
> 
> does not make sense for a DHCP client.
> 
> Also, how the host is able to assess/determine that it is (not) capable to
> behave in the IPv6 mode?
> 
> (5) The definition of IPv4aaS is not aligned with other RFCs: e.g., RFC8585
> says the following:
> 
>    "IPv4aaS" stands for "IPv4-as-a-Service", meaning transition
>    technologies for delivering IPv4 in IPv6-only connectivity.
> 
> While yours is:
> 
>    IPv4-as-a-Service: a deployment scenario when end hosts are expected
>    to operate in IPv6-only mode by default and IPv4 addresses can be
>    assigned to some hosts if those hosts explicitly opt-in to receiving
>    IPv4 addresses.
> 
> (6) Do you consider a host with CLAT function as an IPv6-only host?
> 
> If so, the following definition should be updated to refer to "IPv4
> connectivity" rather than "IPv4" in general. This is because an IPv4
> address is required for CLAT for example.
> 
> ==
>    IPv6-only capable host: a host which does not require IPv4 and can
>    operate on IPv6-only networks.
> ==
> 
> (7) Wouldn't the following add an extra delay for applications requiring
> CLAT?
> 
> ==
> The host MAY disable IPv4 stack
>    completely for V6ONLY_WAIT seconds or until the network disconnection
>    event happens.
> ==
> 
> (8) Consider returning an address from the range defined in RFC7335 for
> IPv6-only hosts. Such IPv4 addresses are required anyway for some IPv6-only
> hosts (those with a CLAT for example).
> 
> ====
>    The result is that 192.0.0.0/29 may be used in any system
>    that requires IPv4 addresses for backward compatibility with IPv4
>    communications in an IPv6-only network but does not emit IPv4 packets
>    "on the wire".
> ====
> 
> Cheers,
> Med
> 
> > -----Message d'origine-----
> > De : dhcwg [mailto:[e-mail]] De la part de Jen Linkova
> > Envoyé : mardi 10 décembre 2019 01:02 À : [e-mail] Cc : V6 Ops
> > List Objet : [dhcwg] Fwd: New Version Notification for
> > draft-link-dhc-v6only- 01.txt
> >
> > Hello,
> >
> > Thanks to everyone for very productive centi-thread on
> > draft-link-dhc-v6only-00 ;)
> > Here is the improved version, -01.
> >
> > The main changes:
> >
> > - The option is not zero length anymore. It has 4-bytes value which
> > might contain V6ONLY_WAIT timer. Benefits:
> >     --- allows the network administrators to pilot the changes and
> > rollback quickly if needed;
> >     --- addressed some concern about an option having zero length
> > (allegedly it might confuse some clients)
> >
> > - Using a dedicated address to return to clients is now an optional
> > optimisation. By default the server is expected just to return a
> > random address (as usual).
> >
> > - Typos fixed (probably some new typos added though).
> >
> > The authors would like the DHC WG to consider adopting this document.
> >
> > Thank you!
> >
> > ---------- Forwarded message ---------
> > From: <[e-mail]>
> > Date: Tue, Dec 10, 2019 at 10:44 AM
> > Subject: New Version Notification for draft-link-dhc-v6only-01.txt
> > To: Tomek Mrugalski <[e-mail]>, Lorenzo Colitti
> > <[e-mail]>, Jen Linkova <[e-mail]>, Michael C.
> > Richardson <[e-mail]>
> >
> >
> >
> > A new version of I-D, draft-link-dhc-v6only-01.txt has been
> > successfully submitted by Jen Linkova and posted to the IETF
> > repository.
> >
> > Name:           draft-link-dhc-v6only
> > Revision:       01
> > Title:          IPv6-Only-Preferred Option for DHCP
> > Document date:  2019-12-09
> > Group:          Individual Submission
> > Pages:          10
> > URL:
> > https://www.ietf.org/internet-drafts/draft-link-dhc-v6only-01.txt
> > Status:         https://datatracker.ietf.org/doc/draft-link-dhc-v6only/
> > Htmlized:       https://tools.ietf.org/html/draft-link-dhc-v6only-01
> > Htmlized:       https://datatracker.ietf.org/doc/html/draft-link-dhc-
> v6only
> > Diff:           https://www.ietf.org/rfcdiff?url2=draft-link-dhc-v6only-
> 01
> >
> > Abstract:
> >    This document specifies a DHCP 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.
> >
> >
> >
> >
> > Please note that it may take a couple of minutes from the time of
> > submission until the htmlized version and diff are available at
> > tools.ietf.org.
> >
> > The IETF Secretariat
> >
> >
> > --
> > SY, Jen Linkova aka Furry
> >
> > _______________________________________________
> > dhcwg mailing list
> > [e-mail]
> > https://www.ietf.org/mailman/listinfo/dhcwg
> 
> _______________________________________________
> dhcwg mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/dhcwg