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

[<[e-mail]>]

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