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

[<[e-mail]>]

Re-,

The draft says the following: 

   The client SHOULD stop the DHCP
   configuration process for at least V6ONLY_WAIT seconds or until a
   network attachment event happens.

While I interpret your response as: 

   The client MUST stop the DHCP
   configuration process for at least V6ONLY_WAIT seconds or until a
   network attachment event happens.

Bernie, OK to close (8) from my initial review list.  

Cheers,
Med

> -----Message d'origine-----
> De : Bernie Volz (volz) [mailto:[e-mail]]
> Envoyé : mercredi 11 décembre 2019 14:30
> À : BOUCADAIR Mohamed TGI/OLN
> Cc : Jen Linkova; [e-mail]; V6 Ops List
> Objet : RE: [dhcwg] Fwd: New Version Notification for draft-link-dhc-
> v6only-01.txt
> 
> Med:
> 
> If this option is in play, no address is "assigned" to the client as that
> requires the DHCPREQUEST/DHCPACK messages and the client "stops" after a
> DHCPOFFER if the option was returned. So, you can't use this if you want to
> assign an address.
> 
> I'm not sure what is being done today:
> 1) Are you saying there is no support for this in DHCP. If so, then this is
> not something that can be used to activate this support.
> 2) Are you saying that it works fine as is today (since the DHCP server can
> be configured (somehow) to return this). If so, then don't use the option
> (at least on the server for the pools).
> 
> I think your request is different than this ipv6-only option. So, if you
> feel that something is needed, feel free to write a draft (likely it would
> require a new option that the server is told to do this special behavior).
> 
> - Bernie
> 
> -----Original Message-----
> From: [e-mail] <[e-mail]>
> Sent: Wednesday, December 11, 2019 7:49 AM
> To: Bernie Volz (volz) <[e-mail]>
> Cc: Jen Linkova <[e-mail]>; [e-mail]; V6 Ops List
> <[e-mail]>
> Subject: RE: [dhcwg] Fwd: New Version Notification for draft-link-dhc-
> v6only-01.txt
> 
> Re-,
> 
> Please see inline.
> 
> Cheers,
> Med
> 
> > -----Message d'origine-----
> > De : Bernie Volz (volz) [mailto:[e-mail]] Envoyé : mercredi 11
> > décembre 2019 12:20 À : BOUCADAIR Mohamed TGI/OLN Cc : Jen Linkova;
> > [e-mail]; V6 Ops List Objet : Re: [dhcwg] Fwd: New Version
> > Notification for draft-link-dhc- v6only-01.txt
> >
> > Not sure how this is supposed to work today (is this documented
> somewhere)?
> > Is dhcp server already assigning addresses in the special range?
> 
> [Med] DHCP servers are not used today to assign these addresses. The
> selection of the address is local to the host. There is no ambiguity for
> some IPv4aaS techniques (DS-Lite uses 192.0.0.2) but not for CLAT
> (192.0.0.0/29).
> 
>  If so, why
> > not continue that practice and don’t honor the ipv6-only option on
> server.
> 
> [Med] That wouldn't work because my proposal is for the server to return
> the ** same ** address to all requesting hosts with ipv6-only enabled. That
> address will be passed to modules such as CLAT. This behavior is already
> required by this draft:
> 
>    As an optional optimization an IPv6-mostly pool MAY be configured
>    with a dedicated IPv4 address to be returned to IPv6-only capable
>    clients.  In that case the server SHOULD specify that address as the
>    client's network address and MUST NOT verify its uniqueness.
>                                 ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
> 
> The value I see in returning an address from this well-known range is that
> the host does not even need to pause, i.e., this text won't be required
> anymore in the draft:
> 
> ==
> If the
>    IPv6-only Preferred option returned by the server contains non-zero
>    value the client SHOULD set the V6ONLY_WAIT timer to that value.  If
>    the server returns zero value the client MUST use its own
>    configuration for V6ONLY_WAIT timer.  The client SHOULD stop the DHCP
>    configuration process for at least V6ONLY_WAIT seconds or until a
>    network attachment event happens.  The host MAY disable IPv4 stack
>    completely for V6ONLY_WAIT seconds or until the network disconnection
>    event happens.
> ==
> 
> The host won't emit IPv4 packets "on the wire" when assigned with such
> address.
> 
> >
> > - Bernie
> >
> > > On Dec 11, 2019, at 1:28 AM, "[e-mail]"
> > <[e-mail]> wrote:
> > >
> > > 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