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

["STARK, BARBARA H" <[e-mail]>]

> From: Ted Lemon
> 
> I really think you should have a clear justification for doing anything other
> than returning 0.0.0.0.   Anything else is going to be more complicated in the
> long term.   The justification “because 0.0.0.0 would be filtered out by the
> server” seems like it’s very implementation-dependent and not really that
> big a deal.   Is that your only reason?

Some CE routers are coded to have special handling for 0.0.0.0. Multiple ISPs use that address for IPTV multicast traffic (on a VLAN dedicated to that traffic). I could envision such routers having issues with getting 0.0.0.0 from DHCPv4. CE router vendors and their chipset vendors do the darnedest things sometimes (as Cloudflare discovered wrt 1.1.1.1).  I think widespread testing of CE routers is needed if the returned address is going to be required to 0.0.0.0. 

Here is language from BBF TR-124 (requirement LAN.IGMP.ROUTED): "It MUST be possible to configure a WAN-facing IPv4 interface with an IPoE encapsulation and no IPv4 address visible by the access network. It MUST be possible to receive multicast traffic on such an interface, independent of whether upstream IGMP is sent on this interface or not. The RG's IGMP proxy-routing function MUST be able to send upstream IGMP traffic on such an interface, using an unspecified (0.0.0.0/::) IPv4 source address."

I'm leaning toward not over-specifying what address gets returned.
Barbara

> > On Dec 10, 2019, at 8:11 AM, Bernie Volz (volz) <[e-mail]> wrote:
> >
> > 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?
> >
> > 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://urldefense.proofpoint.com/v2/url?u=https-
> 3A__www.ietf.org_internet-2Ddrafts_draft-2Dlink-2Ddhc-2Dv6only-
> 2D01.txt&d=DwIGaQ&c=LFYZ-o9_HUMeMTSQicvjIg&r=LoGzhC-
> 8sc8SY8Tq4vrfog&m=33aAfD-_FR1KRE0V6ypGFDGQdX-
> 9KUziTA0aOUPM_fc&s=DzE8klltpk82gJ3XzwS9A8PiHNYR2q402g8UWh8Xt2U
> &e=
> >> Status:         https://urldefense.proofpoint.com/v2/url?u=https-
> 3A__datatracker.ietf.org_doc_draft-2Dlink-2Ddhc-
> 2Dv6only_&d=DwIGaQ&c=LFYZ-o9_HUMeMTSQicvjIg&r=LoGzhC-
> 8sc8SY8Tq4vrfog&m=33aAfD-_FR1KRE0V6ypGFDGQdX-
> 9KUziTA0aOUPM_fc&s=FBjuCqg_Ixxezn9-
> uLWOLklYsoQIldbHPwLSnrlQJFQ&e=
> >> Htmlized:       https://urldefense.proofpoint.com/v2/url?u=https-
> 3A__tools.ietf.org_html_draft-2Dlink-2Ddhc-2Dv6only-
> 2D01&d=DwIGaQ&c=LFYZ-o9_HUMeMTSQicvjIg&r=LoGzhC-
> 8sc8SY8Tq4vrfog&m=33aAfD-_FR1KRE0V6ypGFDGQdX-
> 9KUziTA0aOUPM_fc&s=_t-
> fCYtxlOU9YxIBkkb7oscAi6CY_02zzn1qqNOuo0Q&e=
> >> Htmlized:       https://urldefense.proofpoint.com/v2/url?u=https-
> 3A__datatracker.ietf.org_doc_html_draft-2Dlink-2Ddhc-
> 2Dv6only&d=DwIGaQ&c=LFYZ-o9_HUMeMTSQicvjIg&r=LoGzhC-
> 8sc8SY8Tq4vrfog&m=33aAfD-_FR1KRE0V6ypGFDGQdX-
> 9KUziTA0aOUPM_fc&s=bJXJbD0K1NOH_N4nGk96SdlvK8QCFJyAKK6gU0dPtr
> E&e=
> >> Diff:           https://urldefense.proofpoint.com/v2/url?u=https-
> 3A__www.ietf.org_rfcdiff-3Furl2-3Ddraft-2Dlink-2Ddhc-2Dv6only-
> 2D01&d=DwIGaQ&c=LFYZ-o9_HUMeMTSQicvjIg&r=LoGzhC-
> 8sc8SY8Tq4vrfog&m=33aAfD-_FR1KRE0V6ypGFDGQdX-
> 9KUziTA0aOUPM_fc&s=IPcu30Gmr2x1twxcRh4EnDeO_ojo0HmPxDuZnO9oIF
> 4&e=
> >>
> >> 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://urldefense.proofpoint.com/v2/url?u=https-
> 3A__www.ietf.org_mai
> >> lman_listinfo_dhcwg&d=DwIGaQ&c=LFYZ-
> o9_HUMeMTSQicvjIg&r=LoGzhC-8sc8SY
> >> 8Tq4vrfog&m=33aAfD-_FR1KRE0V6ypGFDGQdX-
> 9KUziTA0aOUPM_fc&s=AstqYdooWFy
> >> nLiqa7N_ScMghbhhKVAmCSZ8xOiJ6jfM&e=
> >
> > _______________________________________________
> > dhcwg mailing list
> > [e-mail]
> > https://urldefense.proofpoint.com/v2/url?u=https-
> 3A__www.ietf.org_mail
> > man_listinfo_dhcwg&d=DwIGaQ&c=LFYZ-
> o9_HUMeMTSQicvjIg&r=LoGzhC-8sc8SY8T
> > q4vrfog&m=33aAfD-_FR1KRE0V6ypGFDGQdX-
> 9KUziTA0aOUPM_fc&s=AstqYdooWFynLi
> > qa7N_ScMghbhhKVAmCSZ8xOiJ6jfM&e=
> >
> > _______________________________________________
> > v6ops mailing list
> > [e-mail]
> > https://urldefense.proofpoint.com/v2/url?u=https-
> 3A__www.ietf.org_mail
> > man_listinfo_v6ops&d=DwIGaQ&c=LFYZ-o9_HUMeMTSQicvjIg&r=LoGzhC-
> 8sc8SY8T
> > q4vrfog&m=33aAfD-_FR1KRE0V6ypGFDGQdX-
> 9KUziTA0aOUPM_fc&s=oCMmIfgiQWTZbA
> > 6Rx5Lakxg6tbO2d2vg5h9asQ6lnZk&e=
> 
> _______________________________________________
> dhcwg mailing list
> [e-mail]
> https://urldefense.proofpoint.com/v2/url?u=https-
> 3A__www.ietf.org_mailman_listinfo_dhcwg&d=DwIGaQ&c=LFYZ-
> o9_HUMeMTSQicvjIg&r=LoGzhC-8sc8SY8Tq4vrfog&m=33aAfD-
> _FR1KRE0V6ypGFDGQdX-
> 9KUziTA0aOUPM_fc&s=AstqYdooWFynLiqa7N_ScMghbhhKVAmCSZ8xOiJ6jf
> M&e=