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

From: Jen Linkova <[email-masked]>
Date: Tue, 10 Dec 2019 11:02:04 +1100

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: <[email-masked]>
Date: Tue, Dec 10, 2019 at 10:44 AM
Subject: New Version Notification for draft-link-dhc-v6only-01.txt
To: Tomek Mrugalski <[email-masked]>, Lorenzo Colitti
<[email-masked]>, Jen Linkova <[email-masked]>, Michael C.
Richardson <[email-masked]>

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

---

From: <[email-masked]>
Date: Tue, 10 Dec 2019 10:31:31 +0000

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:[email-masked]] De la part de Jen Linkova
> Envoyé : mardi 10 décembre 2019 01:02
> À : [email-masked]
> Cc : V6 Ops List
> Objet : [dhcwg] Fwd: New Version Notification for draft-link-dhc-v6only-
> 01.txt
> 
> Hello,
> 
> _______________________________________________
> dhcwg mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/dhcwg

---

From: "Bernie Volz (volz)" <[email-masked]>
Date: Tue, 10 Dec 2019 16:11:16 +0000

Hi:

Is (8):

	====

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 <[email-masked]> On Behalf Of [email-masked]
Sent: Tuesday, December 10, 2019 5:32 AM
To: Jen Linkova <[email-masked]>; [email-masked]
Cc: V6 Ops List <[email-masked]>
Subject: Re: [dhcwg] Fwd: New Version Notification for draft-link-dhc-v6only-01.txt

Hi Jen,

==

While yours is: 

==

==

====

Cheers,
Med

> Envoyé : mardi 10 décembre 2019 01:02 À : [email-masked] Cc : V6 Ops 
> List Objet : [dhcwg] Fwd: New Version Notification for 
> draft-link-dhc-v6only- 01.txt
> 
> Hello,
> 
> 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.
> 
> 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
> 
> 
> --

---

From: Ted Lemon <[email-masked]>
Date: Tue, 10 Dec 2019 08:39:21 -0800

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?

> On Dec 10, 2019, at 8:11 AM, Bernie Volz (volz) <[email-masked]> wrote:
> 
> Hi:
> 
> Is (8):
> 
> v6ops mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/v6ops

---

From: "Bernie Volz (volz)" <[email-masked]>
Date: Tue, 10 Dec 2019 16:53:30 +0000

I've debated that issue on end and not going to do it any further. I completely disagree - server should return whatever it would have returned if the option is were not present.

- Bernie

---

From: Ted Lemon <[email-masked]>
Date: Tue, 10 Dec 2019 09:09:35 -0800

> I've debated that issue on end and not going to do it any further. I completely disagree - server should return whatever it would have returned if the option is were not present.

How about “server SHOULD return 0.0.0.0; server MAY return some other bogus address, which the client MUST ignore”?   The reason I’m hassling you about this is that you have a very specific solution in mind, and it’s not a long-term solution.   I don’t mind accommodating your solution, but I don’t want to be married to it for the rest of eternity.

---

From: "STARK, BARBARA H" <[email-masked]>
Date: Tue, 10 Dec 2019 17:16:32 +0000

> 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

> > 	(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).
> >
> > 	====
> > 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
> >
> > 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.
> >
> > * 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.
> >
> > 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.
> >
> > ==
> > (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).
> >
> > ====
> >> 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:
> >> 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=
> >
> > 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=
> >
> > 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=
> 
> 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=

---

From: David Farmer <[email-masked]>
Date: Tue, 10 Dec 2019 11:24:17 -0600

Bernie,

Could you provide a couple of pointers to threads where the 0.0.0.0 address
issue was discussed?

I would like to better understand the issues around using 0.0.0.0 as the
address returned, with making you re-debate the issue.

Thanks

On Tue, Dec 10, 2019 at 10:53 AM Bernie Volz (volz) <[email-masked]> wrote:

> I've debated that issue on end and not going to do it any further. I
> completely disagree - server should return whatever it would have returned
> if the option is were not present.
>
> - Bernie
>
> Cc: [email-masked]; Jen Linkova <[email-masked]>;
> [email-masked]; V6 Ops List <[email-masked]>
> 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?
>
> >       (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).
> >
> >       ====
> > 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?
> >
> DHCPDISCOVER/OFFER/REQUEST/ACK (stops at OFFER), this work could not be
> used to assign any address.
> >
> > - Bernie
> >
> > (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.
> >
> disable including it in the request. The document should include a
> discussion on the default behavior.
> option, having a discussion to what extent the feature is likely to be
> enabled would be needed.
> >
> connectivity" rather than "IPv4" in general. This is because an IPv4
> address is required for CLAT for example.
> >
> > ==
> >> Htmlized:
> https://datatracker.ietf.org/doc/html/draft-link-dhc-v6only
> >> Diff:
> https://www.ietf.org/rfcdiff?url2=draft-link-dhc-v6only-01
> >>
> >> Abstract:

-- 
===============================================
David Farmer               Email:[email-masked]
Networking & Telecommunication Services
Office of Information Technology
University of Minnesota
2218 University Ave SE        Phone: 612-626-0815
Minneapolis, MN 55414-3029   Cell: 612-812-9952
===============================================

---

From: "Bernie Volz (volz)" <[email-masked]>
Date: Tue, 10 Dec 2019 18:08:00 +0000

You can probably see much of the discussion by going to https://mailarchive.ietf.org/arch/browse/dhcwg/?q=0.0.0.0 (search DHC WG mailing list for 0.0.0.0) – just look at the recent emails from December 2019.

BTW: I am personally done debating the issue (this is not a DHC WG co-chair statement related to the WG discussion), but just that I am done debating this myself (as there’s little point in repeating my arguments). It will be up to the WG to decide (via rough consensus) as to what ends up in the document if it is adopted.

  *   Bernie

From: David Farmer <[email-masked]>
Date: Tuesday, December 10, 2019 at 12:24 PM
To: Bernie Volz <[email-masked]>
Cc: Ted Lemon <[email-masked]>, "[email-masked]" <[email-masked]>, "[email-masked]" <[email-masked]>
Subject: Re: [v6ops] [dhcwg] Fwd: New Version Notification for draft-link-dhc-v6only-01.txt

Bernie,

Could you provide a couple of pointers to threads where the 0.0.0.0 address issue was discussed?

I would like to better understand the issues around using 0.0.0.0 as the address returned, with making you re-debate the issue.

Thanks

On Tue, Dec 10, 2019 at 10:53 AM Bernie Volz (volz) <[email-masked]<mailto:[email-masked]>> wrote:
I've debated that issue on end and not going to do it any further. I completely disagree - server should return whatever it would have returned if the option is were not present.

- Bernie

-----Original Message-----
From: Ted Lemon <[email-masked]<mailto:[email-masked]>>
Sent: Tuesday, December 10, 2019 11:39 AM
To: Bernie Volz (volz) <[email-masked]<mailto:[email-masked]>>
Cc: [email-masked]<mailto:[email-masked]>; Jen Linkova <[email-masked]<mailto:[email-masked]>>; [email-masked]<mailto:[email-masked]>; V6 Ops List <[email-masked]<mailto:[email-masked]>>
Subject: Re: [v6ops] [dhcwg] Fwd: New Version Notification for draft-link-dhc-v6only-01.txt

> On Dec 10, 2019, at 8:11 AM, Bernie Volz (volz) <[email-masked]<mailto:[email-masked]>> wrote:
>
> Hi:
>
> Is (8):
>
>          The result is that 192.0.0.0/29<http://192.0.0.0/29> may be used in any system
>   IANA has defined a well-known range, 192.0.0.0/29<http://192.0.0.0/29>, in [RFC6333],
>   and effective to generalize 192.0.0.0/29<http://192.0.0.0/29> for the use of supporting
> From: dhcwg <[email-masked]<mailto:[email-masked]>> On Behalf Of
> [email-masked]<mailto:[email-masked]>
> To: Jen Linkova <[email-masked]<mailto:[email-masked]>>; [email-masked]<mailto:[email-masked]>
> Cc: V6 Ops List <[email-masked]<mailto:[email-masked]>>
>   The result is that 192.0.0.0/29<http://192.0.0.0/29> may be used in any system
>> De : dhcwg [mailto:[email-masked]<mailto:[email-masked]>] De la part de Jen Linkova
>> Envoyé : mardi 10 décembre 2019 01:02 À : [email-masked]<mailto:[email-masked]> Cc : V6 Ops
>> From: <[email-masked]<mailto:[email-masked]>>
>> To: Tomek Mrugalski <[email-masked]<mailto:[email-masked]>>, Lorenzo Colitti
>> <[email-masked]<mailto:[email-masked]>>, Jen Linkova <[email-masked]<mailto:[email-masked]>>, Michael C.
>> Richardson <[email-masked]<mailto:[email-masked]>>
>>
>>
>>
>> tools.ietf.org<http://tools.ietf.org>.
>>
>> The IETF Secretariat
>>
>>
>> --
>> [email-masked]<mailto:[email-masked]>
> [email-masked]<mailto:[email-masked]>
> [email-masked]<mailto:[email-masked]>

_______________________________________________
v6ops mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/v6ops

David Farmer               Email:[email-masked]<mailto:[email-masked]>

---

From: Ted Lemon <[email-masked]>
Date: Tue, 10 Dec 2019 10:21:11 -0800

> 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…

The idea here is that the returned address is bogus and won’t work.   So if the CE router tries to use it for anything, it’s going to break, whether it’s 0.0.0.0 or 192.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 don’t think this would be violated.   Is DHCPv4 currently configuring an address of 0.0.0.0 for IGMP to use?  :)

---

From: "STARK, BARBARA H" <[email-masked]>
Date: Tue, 10 Dec 2019 19:41:11 +0000

On Dec 10, 2019, at 9:16 AM, STARK, BARBARA H <[email-masked]<mailto:[email-masked]>> wrote:
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.

Consider the possibility of a CE router that says: “Proper DHCP servers don’t send bogus addresses. I’m receiving a bogus address from this DHCP server. That means this DHCP server must be compromised, which means the network is compromised, which means I can trust nothing on this network. I shall now (choice A) cease all communication with this network; (or choice B) continue to send DHCPv4 messages frequently until I get one that has a non-bogus address.” We just don’t know. We had no idea that there were chipsets in routers with chipset firmware that considered messages to/from 1.1.1.1 a threat and a security violation. It’s important not to assume that routers are tolerant of 0.0.0.0 in DHCP responses. I think whoever wants 0.0.0.0 mandated or preferred needs to be the one to prove that it would not cause harm, because I’m not seeing evidence of real benefit of such normative language. If the IP address(es) to return are left up to the deployer, then the deployer can make sure whatever they do works in their network, with their server and middleboxes and whatever clients are attaching. [BTW, Ted, I’m having to change my email client settings every time to have different rules for responses to text vs. html/rich text – this is IETF, darn it, so we should all be using plain text; personal experiment over; rules favoring plain text are staying and no more switching options to satisfy people who don’t reply to text with text.]

---

From: Ted Lemon <[email-masked]>
Date: Tue, 10 Dec 2019 11:44:22 -0800

On Dec 10, 2019, at 11:41 AM, STARK, BARBARA H <[email-masked]> wrote:
> Consider the possibility of a CE router that says: “Proper DHCP servers don’t send bogus addresses. I’m receiving a bogus address from this DHCP server. That means this DHCP server must be compromised, which means the network is compromised, which means I can trust nothing on this network. 

That DHCP client would be a DHCP client that doesn’t implement the specification, since the specification would say MUST accept yiaddr=0.0.0.0 when in v6-only mode.   That client would not be asking for the v6-only option, and hence would never see a yiaddr of 0.0.0.0.

---

From: <[email-masked]>
Date: Wed, 11 Dec 2019 06:28:18 +0000

Hi Bernie, 

Please see inline. 

Cheers,
Med

> De : Bernie Volz (volz) [mailto:[email-masked]]
> Envoyé : mardi 10 décembre 2019 17:11
> À : BOUCADAIR Mohamed TGI/OLN; Jen Linkova; [email-masked]
> Cc : V6 Ops List
> Objet : RE: [dhcwg] Fwd: New Version Notification for draft-link-dhc-
> v6only-01.txt
> 
> Hi:
> 
> Is (8):
> 

[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.

> 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.
>

---

From: "Bernie Volz (volz)" <[email-masked]>
Date: Wed, 11 Dec 2019 11:20:06 +0000

Not sure how this is supposed to work today (is this documented somewhere)? Is dhcp server already assigning addresses in the special range? If so, why not continue that practice and don’t honor the ipv6-only option on server.

- Bernie

> On Dec 11, 2019, at 1:28 AM, "[email-masked]" <[email-masked]> wrote:
> 
> Hi Bernie, 
> 
> Please see inline. 
> 
> Cheers,
> Med
>

---

From: <[email-masked]>
Date: Wed, 11 Dec 2019 12:48:57 +0000

Re-,

Please see inline. 

Cheers,
Med

> Envoyé : mercredi 11 décembre 2019 12:20
> À : BOUCADAIR Mohamed TGI/OLN
> Cc : Jen Linkova; [email-masked]; 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.

> would
> > [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.
> >
> >>
> for
> on
> >> 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:
> >>
> >>> Diff:           https://www.ietf.org/rfcdiff?url2=draft-link-dhc-
> v6only-
> >> 01
> >>>
> >>> Abstract:

---

From: "Bernie Volz (volz)" <[email-masked]>
Date: Wed, 11 Dec 2019 13:30:06 +0000

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: [email-masked] <[email-masked]> 
Sent: Wednesday, December 11, 2019 7:49 AM
To: Bernie Volz (volz) <[email-masked]>
Cc: Jen Linkova <[email-masked]>; [email-masked]; V6 Ops List <[email-masked]>
Subject: RE: [dhcwg] Fwd: New Version Notification for draft-link-dhc-v6only-01.txt

Re-,

Please see inline. 

Cheers,
Med

> De : Bernie Volz (volz) [mailto:[email-masked]] Envoyé : mercredi 11 
> décembre 2019 12:20 À : BOUCADAIR Mohamed TGI/OLN Cc : Jen Linkova; 
> [email-masked]; V6 Ops List Objet : Re: [dhcwg] Fwd: New Version 
> Notification for draft-link-dhc- v6only-01.txt
> 

 If so, why

==
If the

> >> De : Bernie Volz (volz) [mailto:[email-masked]] Envoyé : mardi 10 
> >> décembre 2019 17:11 À : BOUCADAIR Mohamed TGI/OLN; Jen Linkova; 
> >> [email-masked] Cc : V6 Ops List Objet : RE: [dhcwg] Fwd: New 
> >> Version Notification for draft-link-dhc- v6only-01.txt
> >>
> >> Hi:
> >>
> >> Is (8):
> >>
> >> RFC7335 for IPv6-only hosts. Such IPv4 addresses are required 
> >> anyway for some
> IPv6-
> (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.
> >
> >>
> >> DHCPDISCOVER/OFFER/REQUEST/ACK (stops at OFFER), this work could 
> >> not be used to assign any address.
> >>
> >> - Bernie
> >>
> >> 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:
> >>
> >> other IPv6-only deployment scenarios (typically, unmanaged 
> >> IPv6-only
> CPEs
> >> with IPv4aaS).
> >>
> >> 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
> >> (3) How "IPv6-only preferred" mode is supposed to be set at the 
> >> host
> side:
> >>
> >> ==
> >> * 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.
> >>
> >> connectivity" rather than "IPv4" in general. This is because an 
> >> IPv4 address is required for CLAT for example.
> >>
> >> ==
> >>> De : dhcwg [mailto:[email-masked]] De la part de Jen 
> >>> Linkova Envoyé : mardi 10 décembre 2019 01:02 À : [email-masked] 
> >>> Cc : V6 Ops List Objet : [dhcwg] Fwd: New Version Notification for
> >>> - The option is not zero length anymore. It has 4-bytes value 
> >>> which might contain V6ONLY_WAIT timer. Benefits:
> >>> - 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).
> >>>

---

From: <[email-masked]>
Date: Wed, 11 Dec 2019 14:12:57 +0000

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

> Envoyé : mercredi 11 décembre 2019 14:30
> 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.
> 
> 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
> 
> [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
> [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:
> 
> 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
> > >>   Router (AFTR) and never emits packets from this prefix "on the
> wire".
> > >> <---

---

From: "Bernie Volz (volz)" <[email-masked]>
Date: Thu, 12 Dec 2019 16:04:09 +0000

Hi:

Just to add one additional point regarding middleboxes … I did confirm (not by actual testing but checking with developers) that at least one middlebox will not pass the DHCPOFFER if the address in the yiaddr field is not appropriate to the network segment the client is on. So, it would not let the DHCPOFFER with yiaddr of 0.0.0.0 go to the client. This is exactly the reason I think this is a bad idea and we MUST NOT do it; the address in the yiaddr must be a “normal” address that the client COULD use. (And asking the middlebox to change to allow an “invalid” address if the IPv6-only option is present in the DHCPOFFER would require a software/firmware update which is not desirable.)

And, here are sections from RFC2131 that clearly indicate that there is no need for a server to “reserve” this address for any particular time:

From section 3.1:

   2. Each server may respond with a DHCPOFFER message that includes an
      available network address in the 'yiaddr' field (and other
      configuration parameters in DHCP options).  Servers need not
      reserve the offered network address, although the protocol will
      work more efficiently if the server avoids allocating the offered
      network address to another client.

And later in step 4:

     A server MAY choose to mark addresses offered to clients in

     DHCPOFFER messages as unavailable.  The server SHOULD mark an

     address offered to a client in a DHCPOFFER message as available if

     the server receives no DHCPREQUEST message from that client.

And in section 4.3.1:

   While not required for correct operation of DHCP, the server SHOULD

   NOT reuse the selected network address before the client responds to

   the server's DHCPOFFER message.  The server may choose to record the

   address as offered to the client.

(This SHOULD NOT seems more strict than the earlier text.)

This is why the server I work on has a configurable time period for which we remember that we offered the lease to a client and don’t give it to another client (this allows time for the client to send the request) – we don’t however commit this to disk (except in the case where the lease is leased to the client and it would expire before this short offered period elapses – we then extend the lease to cover that short time). This does mean if the server is reloaded, we might reuse the lease for a different client. However, the DHCP protocol handles this fine as if the original client sends a DHCPREQUEST with this “reassigned” lease, we would respond with a DHCPNAK – which causes the client to restart the discover process and then everything would hopefully work out.

  *   Bernie

From: dhcwg <[email-masked]> On Behalf Of Bernie Volz (volz)
Sent: Tuesday, December 10, 2019 1:08 PM
To: David Farmer <[email-masked]>
Cc: [email-masked]; V6 Ops List <[email-masked]>; Ted Lemon <[email-masked]>
Subject: Re: [dhcwg] [v6ops] Fwd: New Version Notification for draft-link-dhc-v6only-01.txt

  *   Bernie

From: David Farmer <[email-masked]<mailto:[email-masked]>>
Date: Tuesday, December 10, 2019 at 12:24 PM
To: Bernie Volz <[email-masked]<mailto:[email-masked]>>
Cc: Ted Lemon <[email-masked]<mailto:[email-masked]>>, "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>, "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>
Subject: Re: [v6ops] [dhcwg] Fwd: New Version Notification for draft-link-dhc-v6only-01.txt

Bernie,

Thanks

- Bernie

-----Original Message-----
From: Ted Lemon <[email-masked]<mailto:[email-masked]>>
Sent: Tuesday, December 10, 2019 11:39 AM
To: Bernie Volz (volz) <[email-masked]<mailto:[email-masked]>>
Cc: [email-masked]<mailto:[email-masked]>; Jen Linkova <[email-masked]<mailto:[email-masked]>>; [email-masked]<mailto:[email-masked]>; V6 Ops List <[email-masked]<mailto:[email-masked]>>
Subject: Re: [v6ops] [dhcwg] Fwd: New Version Notification for draft-link-dhc-v6only-01.txt

> draft-link-dhc-v6only-01.txt
>
> Hi Jen,
>

---

From: Ted Lemon <[email-masked]>
Date: Thu, 12 Dec 2019 08:16:23 -0800

> Just to add one additional point regarding middleboxes … I did confirm (not by actual testing but checking with developers) that at least one middlebox will not pass the DHCPOFFER if the address in…

Can you tell us what brand of middlebox this is?   What software version?   How long ago this behavior was last seen?

What you are saying here is effectively that for all eternity, we must configure this broken middlebox to believe that some IPv4 address that will never be assigned on a link is valid on the link, and configure the DHCP server to know what IPv4 subnet is valid on a particular link, even when IPv4 is no longer in use on that link.

This is, frankly, ridiculous.   If software is broken, we should not design our protocols around that brokenness.  Remember back when we did that for Microsoft’s broken implementation of ASCII strings in their DHCP client back in ~Windows 95?   And now that code is still in every DHCP server?  This is a similar situation.

The reality is that if a network operator wants to be able to disable IPv4 for clients that can use IPv6, they are going to be motivated to fix brokenness on their network.   If they don’t care to do that, they probably aren’t going to bother with this anyway.   And if they don’t care to do that, it’s really not our problem.

You, as a Cisco employee, can perfectly well configure your DHCP server to always send an IP address that works on the link, and this middlebox will still work.   But if we say that DHCP servers MUST not use a fixed address (e.g. 0.0.0.0), then we are saying not that you can choose to do this, but that we are all forced to do this.   That’s the wrong call.

---

From: "Bernie Volz (volz)" <[email-masked]>
Date: Thu, 12 Dec 2019 16:33:49 +0000

No, it is not ridiculous. This is because this is the defined behavior as per RFC2131. 0.0.0.0 is not a valid address to assign to a device. And, your proposal would change that behavior which has been well established for over 20 years (since RFC2131 and probably even back to BOOTP). That is why it is not a good idea to change this well-established behavior.

Your analogy to Windows 95 is also bad as this was incorrect behavior which is different than changing the behavior.

- Bernie

---

From: "Bernie Volz (volz)" <[email-masked]>
Date: Thu, 12 Dec 2019 17:36:10 +0000

Ted - see https://mailarchive.ietf.org/arch/msg/v6ops/D1maPWpHn8Y20t9iHmMdP9jxrFk.

I would prefer the text say either can be used and also explain that using 0.0.0.0 could issues with intermediate devices (relay agents, switches, etc) that may be inspecting these packets. Hence, no "SHOULD" for 0.0.0.0. And, obviously it must say that a client MUST NOT send a DHCPREQUEST if yiaddr is 0.0.0.0 (though likely it would just get a DHCPNAK even if it did).

A server returns either a real IPv4 address or 0.0.0.0 in the yiaddr field. Note that using 0.0.0.0 could cause issues with intermediate devices (relay agents, switches, etc.) that may be inspecting the DHCP packets.

> In the long term, requiring what goes into yiaddr to be an IP address that will work on the link is simply not going to work.  This mode of operation assumes that IPv4 is supported at all on the link, but what we want in the long term is for it not to be supported at all on the link.   So the solution that we come up with has to work for that use case.

That link needs a v4 address for the relay agent. So, you will need IPv4 there anyway. This was not a mechanism (as was proposed by Sunset4) to completely disable and remove IPv4; it was a mechanism to tell dual stack devices that still wanted IPv4 but were capability of using certain transition technologies that they don't need IPv4 as IPv6 and the transition technology is (should be) available and they should use it.

- Bernie

-----Original Message-----
From: Ted Lemon <[email-masked]> 
Sent: Thursday, December 12, 2019 11:44 AM
To: Bernie Volz (volz) <[email-masked]>
Subject: Re: [dhcwg] [v6ops] Fwd: New Version Notification for draft-link-dhc-v6only-01.txt

> No, it is not ridiculous. This is because this is the defined behavior as per RFC2131. 0.0.0.0 is not a valid address to assign to a device. And, your proposal would change that behavior which has…

Then I guess we should use the mechanism defined in RFC2131 for disabling IPv4?  :)

In the long term, requiring what goes into yiaddr to be an IP address that will work on the link is simply not going to work.  This mode of operation assumes that IPv4 is supported at all on the link, but what we want in the long term is for it not to be supported at all on the link.   So the solution that we come up with has to work for that use case.

Why is it not okay to say SHOULD use 0.0.0.0, but MAY use a real IPv4 address, in order to work around the middlebox bug you’re describing on networks where this turns out to be necessary?

---

From: Roy Marples <[email-masked]>
Date: Thu, 12 Dec 2019 20:37:24 +0000

On 12/12/2019 16:04, Bernie Volz (volz) wrote:
> Hi:
> 
> Just to add one additional point regarding middleboxes … I did confirm 
> (not by actual testing but checking with developers) that at least one 
> middlebox will not pass the DHCPOFFER if the address in the yiaddr field 
> is not appropriate to the network segment the client is on. So, it would 
> not let the DHCPOFFER with yiaddr of 0.0.0.0 go to the client. This is 
> exactly the reason I think this is a bad idea and we MUST NOT do it; the 
> address in the yiaddr must be a “normal” address that the client COULD 
> use. (And asking the middlebox to change to allow an “invalid” address 
> if the IPv6-only option is present in the DHCPOFFER would require a 
> software/firmware update which is not desirable.)
MUST is such a strong word .....

Taking your view should we scrap these RFC's as there are boxes in the 
wild that refuse DHCP leases if the option is present:

RFC4039 - Rapid Commit
RFC4361 - Node specific client id
RFC4702 - DHCP FQDN (when DNS encoding is used)

I could spend time trawling the dhcpcd list archives for more (these are 
just off the top of my head) but I don't have the time right now.

I've always taken the view that dhcpcd should support all RFC's and 
enable modern defaults. I don't see this changing here...
I can quite easily see the same boxes refusing leases if the client 
supplies this new option - so again, taking your view - it should not be 
enabled by default.

You can argue that said boxes are not RFC compliant, but that is the 
same as the argument here - nothing in the standard says that 0.0.0.0 
cannot be offered.

Roy

---

From: "Bernie Volz (volz)" <[email-masked]>
Date: Thu, 12 Dec 2019 21:02:49 +0000

> You can argue that said boxes are not RFC compliant, but that is the same as the argument here - nothing in the standard says that 0.0.0.0 cannot be offered.

Yes, there is no text that directly says 0.0.0.0 MUST NOT be offered. But it is pretty clear:

Field      DHCPOFFER            DHCPACK             DHCPNAK
-----      ---------            -------             -------
...
'yiaddr'   IP address offered   IP address          0
           to client            assigned to client

Offering 0.0.0.0 is not given the client an address it can use. There's plenty of documents that document 0.0.0.0 is not a destination address on the network. I can't see how in the absence of this use case, 0.0.0.0 would ever be a valid yiaddr in a DHCPOFFER.

And, when given two choices - one that clearly works (offer an address that the client could use) vs offering 0.0.0.0 which could have issues, why would you chose to do something that you know has a chance of breaking things. It just makes no sense to do so. And, this option is for the case where IPv4 service IS available to clients that need it, but if the client doesn't need it and can use IPv6 transition mechanism for IPv4 service.

Nothing we "change" or "enhance" is 100% certain to work everywhere - there are just too many (often broken) assumptions people make. But that's exactly my argument for assigning a real address - one less risk you need to take that something somewhere will break because it wasn't expected. Thank you for your cases where this demonstrates why being conservative in what we do is best.

And, in terms of being conservative, if someone (a vendor, a site) has used whatever option value IANA eventually assigns to the IPv6-only option and a client sends it in the PRL, this will cause problems as the client is not using it as "IPv6-only" and so it will fail because it will either think the server's reply with a yiaddr of 0 is bad or it will try a DHCPREQUEST and fail to get any address (likely will get a DHCPNAK). This process will repeat and the client will not come online. If instead the server sends a usable address, the client will likely be happy and come online (though it may not understand the returned option data).

Finally, if you're hinting that if something is going to break (ignoring the offered address issue) if the IPv6-only option is present, there's not much we can do about that except hope that it is fixed. Or, perhaps we should stop issuing new option assignments?

- Bernie

-----Original Message-----
From: dhcwg <[email-masked]> On Behalf Of Roy Marples
Sent: Thursday, December 12, 2019 3:37 PM
To: Bernie Volz (volz) <[email-masked]>; David Farmer <[email-masked]>; Ted Lemon <[email-masked]>
Cc: [email-masked]
Subject: Re: [dhcwg] [v6ops] Fwd: New Version Notification for draft-link-dhc-v6only-01.txt

On 12/12/2019 16:04, Bernie Volz (volz) wrote:
> middlebox will not pass the DHCPOFFER if the address in the yiaddr 
> field is not appropriate to the network segment the client is on. So, 
> it would not let the DHCPOFFER with yiaddr of 0.0.0.0 go to the 
> client. This is exactly the reason I think this is a bad idea and we 
> MUST NOT do it; the address in the yiaddr must be a “normal” address 
> that the client COULD use. (And asking the middlebox to change to 
> allow an “invalid” address if the IPv6-only option is present in the 
> DHCPOFFER would require a software/firmware update which is not 
> desirable.)

Taking your view should we scrap these RFC's as there are boxes in the wild that refuse DHCP leases if the option is present:

RFC4039 - Rapid Commit

I could spend time trawling the dhcpcd list archives for more (these are just off the top of my head) but I don't have the time right now.

I've always taken the view that dhcpcd should support all RFC's and enable modern defaults. I don't see this changing here...
I can quite easily see the same boxes refusing leases if the client supplies this new option - so again, taking your view - it should not be enabled by default.

You can argue that said boxes are not RFC compliant, but that is the same as the argument here - nothing in the standard says that 0.0.0.0 cannot be offered.

Roy

---

From: Roy Marples <[email-masked]>
Date: Thu, 12 Dec 2019 22:23:33 +0000

> Field      DHCPOFFER            DHCPACK             DHCPNAK

But yet there is no error assiging the unspecified address to an interface.
On BSD, it shows as an address via ifconfig.
On Linux and Solaris it removes any currently assigned address (via 
ifconfig).

Now on BSD (historically) it actually had a use - it needed to be 
assigned to get DHCP to work (this is no longer an issue, just noting 
it). Some PPP/VPN implementations (on BSD and other OS) also assign the 
unspecified address like so.

Does it go anywhere? No. But that's not the point - the address *as an 
address* is valid. How it's used by the host is entirely upto the host.
Any middleware specifying unspecified behaviour is broken by design.

> And, when given two choices - one that clearly works (offer an address that the client could use) vs offering 0.0.0.0 which could have issues, why would you chose to do something that you know has…

I see an issue with being handed an address and a faulty client which 
implements this option performing DAD, spots a host that's actually 
using it and then declining the lease.

Using the unspecified address clearly works here.

So which is more at fault - trying to validate currently undefined 
behaviour to trying to validate an address offered?

Both are equally at fault in my eyes, thus the better semantic of 
offering an unspecified address wins.

> Nothing we "change" or "enhance" is 100% certain to work everywhere - there are just too many (often broken) assumptions people make. But that's exactly my argument for assigning a real address - o…

Agreed

> And, in terms of being conservative, if someone (a vendor, a site) has used whatever option value IANA eventually assigns to the IPv6-only option and a client sends it in the PRL, this will cause p…

This is true.
However, in this case the standard is currently undefined behaviour for 
this option.
We are talking about defining it - exactly the same as the unspecified 
address here. It's currently undefined and your middleware box has the 
same issue as this vendor with the duplicated code.

> Finally, if you're hinting that if something is going to break (ignoring the offered address issue) if the IPv6-only option is present, there's not much we can do about that except hope that it is…

And the reason we can't take the same stance with your middleware box is?

Also, the breakage I am referring to is no lease offered at all - the 
upstream box is totally silent in all cases.

Roy

---

From: David Farmer <[email-masked]>
Date: Thu, 12 Dec 2019 16:53:54 -0600

On Thu, Dec 12, 2019 at 3:03 PM Bernie Volz (volz) <[email-masked]> wrote:

> Offering 0.0.0.0 is not given the client an address it can use. There's
> plenty of documents that document 0.0.0.0 is not a destination address on
> the network. I can't see how in the absence of this use case, 0.0.0.0 would
> ever be a valid yiaddr in a DHCPOFFER.
>

Wait a sec, RFC2563 a standards-track document specifies that 0.0.0.0 is
returned in yiaddr, many DHCP servers support this and option 116. Now I
agree it is a very similar use case, but it's nothing new.

Many older DHCP clients support RFC2563, Win95, Win2000 are examples. I
think many newer clients don't support it.

Nevertheless, using 0.0.0.0 may still be a bad idea, but it is standardized
and therefore valid by definition.

Thanks

---

From: "Bernie Volz (volz)" <[email-masked]>
Date: Thu, 12 Dec 2019 23:09:18 +0000

That is a good find. I didn’t recall this.

On the surface, it looks like this document does a similar thing to the v6only option (stop DHCP). And, if yiaddr was 0, this would require checking both the autoconfigure and v6only to see how to proceed?

   DHCPOFFERs with a 'yiaddr' of 0x00000000 will only be sent by DHCP
   servers supporting the Auto-Configure option when the DHCPDISCOVER
   contained the Auto-Configure option.  Since the DHCPDISCOVER will
   only contain the Auto-Configure option when a DHCP client knows how
   to handle it, there will be no inter-operability problems.

It is likely something that the authors of draft-link-dhc-v6only will need to think about if a yiaddr of 0 is allowed for that case? Personally, another good argument not to use a yiaddr of 0 as it has a special semantic per RFC2563.

Note that this was also a question that was raised for draft-link-dhc-v6only – should it auto configure a link-local address. Perhaps they want to mention RFC2563 as one way to control this on the client side.

Thanks much for pointing out this document!! (Not sure how widely implemented this is as no one else mentioned it.)

  *   Bernie

From: David Farmer <[email-masked]>
Sent: Thursday, December 12, 2019 5:54 PM
To: Bernie Volz (volz) <[email-masked]>
Cc: Roy Marples <roy=[email-masked]>; Ted Lemon <[email-masked]>; [email-masked]
Subject: Re: [dhcwg] [v6ops] Fwd: New Version Notification for draft-link-dhc-v6only-01.txt

Wait a sec, RFC2563 a standards-track document specifies that 0.0.0.0 is returned in yiaddr, many DHCP servers support this and option 116. Now I agree it is a very similar use case, but it's nothing new.

Many older DHCP clients support RFC2563, Win95, Win2000 are examples. I think many newer clients don't support it.

Nevertheless, using 0.0.0.0 may still be a bad idea, but it is standardized and therefore valid by definition.

Thanks

---

From: Lorenzo Colitti <[email-masked]>
Date: Fri, 13 Dec 2019 09:42:40 +0900

On Fri, Dec 13, 2019 at 1:16 AM Ted Lemon <[email-masked]> wrote:

> What you are saying here is effectively that for all eternity, we must
> configure this broken middlebox to believe that some IPv4 address that will
> never be assigned on a link is valid on the link, and configure the DHCP
> server to know what IPv4 subnet is valid on a particular link, even when
> IPv4 is no longer in use on that link.
>

Ted, welcome to the Internet. 'Tis is a place full of middleboxes. Many of
them behave incorrectly. It's great to have you here :-)

But seriously: this sould not be surprising. DHCP has been around for
decades, and yiaddr field is pretty fundamental to the protocol, so you'd
expect there to be some ossification in place. Sure, we can attempt to
ignore it and proceed anyway, but it's a tradeoff. Saying that yiaddr
SHOULD or MUST be 0.0.0.0 creates incompatibility problems and complicates
server implementation. What do we gain by doing so? Why can't we just say
that the server MAY return 0.0.0.0, and if it does so, the client MUST NOT
request 0.0.0.0 but must instead assume that that server has nothing to
offer?

---

From: Roy Marples <[email-masked]>
Date: Fri, 13 Dec 2019 00:50:31 +0000

> That is a good find. I didn’t recall this.

I concurr, a veru good find.

> 
> On the surface, it looks like this document does a similar thing to the 
> v6only option (stop DHCP). And, if yiaddr was 0, this would require 
> checking both the autoconfigure and v6only to see how to proceed?

I still don't understand why we need to check anything if yiaddr is 
unspecified.

> It is likely something that the authors of draft-link-dhc-v6only will 
> need to think about if a yiaddr of 0 is allowed for that case? 
> Personally, another good argument not to use a yiaddr of 0 as it has a 
> special semantic per RFC2563.

Really?
Are you entirely sure that your middleware box is going to allow the 
unspecified address if this option is present AND allows it?

Sorry but that is just going to far.
RFC's have been updated in the past to allow for more conditions on 
pre-existing behaviour - this is no different.

I have no idea what the bee in your bonet is about forcing an address at 
this point as clearly we have RFC's which allow the unspecified address 
in yiaddr. There is clear vocal opposition to the proposal to force an 
address where there is no need to be one.

 > Thanks much for pointing out this document!! (Not sure how widely
 > implemented this is as no one else mentioned it.)

dhcpcd-6.3.0 supported this in 2014.
I would imagine the support for it is quite wide.

Roy

---

From: Roy Marples <[email-masked]>
Date: Fri, 13 Dec 2019 00:54:19 +0000

On 13/12/2019 00:42, Lorenzo Colitti wrote:
> On Fri, Dec 13, 2019 at 1:16 AM Ted Lemon <[email-masked] 
> <mailto:[email-masked]>> wrote:
> 
>     What you are saying here is effectively that for all eternity, we
>     must configure this broken middlebox to believe that some IPv4
>     address that will never be assigned on a link is valid on the link,
>     and configure the DHCP server to know what IPv4 subnet is valid on a
>     particular link, even when IPv4 is no longer in use on that link.
> 
> 
> Ted, welcome to the Internet. 'Tis is a place full of middleboxes. Many 
> of them behave incorrectly. It's great to have you here :-)
> 
> decades, and yiaddr field is pretty fundamental to the protocol, so 
> you'd expect there to be some ossification in place. Sure, we can 
> attempt to ignore it and proceed anyway, but it's a tradeoff. Saying 
> that yiaddr SHOULD or MUST be 0.0.0.0 creates incompatibility problems 
> and complicates server implementation. What do we gain by doing so? Why 
> can't we just say that the server MAY return 0.0.0.0, and if it does so, 
> the client MUST NOT request 0.0.0.0 but must instead assume that that 
> server has nothing to offer?

A better wording would be the server SHOULD return 0.0.0.0 but the 
client MUST ignore the actual value - the server has nothing to offer 
for the address.

This mirrors plenty of existing RFC's that talk about reserved bit 
fields which future RFC's want to use.

Roy

---

From: Lorenzo Colitti <[email-masked]>
Date: Fri, 13 Dec 2019 10:13:30 +0900

> client MUST ignore the actual value - the server has nothing to offer

I really don't see why returning a fake address is preferable. A real
address is easier for many servers to return, and is more compatible with
middleboxes. It also has the advantage that if a client changes its mind
(maybe it has in the meantime found out that there is no IPv6 on the link?)
it can request it and get it - and again, this all works today because
returning real addresses is, in general, what DHCP does. :-)

What is the advantage of returning a fake address?

---

From: Roy Marples <[email-masked]>
Date: Fri, 13 Dec 2019 01:35:33 +0000

On 13/12/2019 01:13, Lorenzo Colitti wrote:
> I really don't see why returning a fake address is preferable.

Please.

All documentation refers to the 0.0.0.0 address as UNSPECIFIED.
It's not fake, it's just all zeros.

UNSPECIFIED means just that. You cannot put ANY specification on it 
otherwise it would not be UNSPECIFIED.

> A real 
> address is easier for many servers to return, and is more compatible 
> with middleboxes.

We've already agreed that middleboxes HAVE to accept yiaddr unspecified 
thanks to RFC2563.

> It also has the advantage that if a client changes its 
> mind (maybe it has in the meantime found out that there is no IPv6 on 
> the link?) it can request it and get it - and again, this all works 
> today because returning real addresses is, in general, what DHCP does. :-)

If a client changes it mind it can renew out of bounds and omit the new 
option. It can say RENEW 1.2.3.4 and the server can OFFER 0.0.0.0.
In just the same way today that a client can request 10.0.0.1 and the 
server will OFFER 192.168.0.1.

DHCP already caters for this :)

And this is also a bone of contention - we should not be allowing a 
state dependant on another.
It's bad enough a hostname from DHCP saying foo and from DHCPv6 saying bar.
I would hope a sys admin would at least know if they ran NAT64 or not 
which is kinda the purpose of this RFC.

> What is the advantage of returning a fake address?

It's not fake. IT'S AN UNSPECIFIED ADDRESS.
CAPS for emphasis because it's like IMPORTANT.
The unspecified address is a real address for both IPv4 and IPv6.

Let me put it another way.

It's perfectly possible for a DHCP server to supply non zero addresses 
to all clients that are unreachable to anyone other than the host they 
are destined for.

How is this different from returning the unspecified address? For all 
intents and purposes, it's just as unreachable.

The address is neither fake, nor invalid - it's just unspecified.
Which is perfect to match this new RFC.

Roy

---

From: Lorenzo Colitti <[email-masked]>
Date: Fri, 13 Dec 2019 11:10:38 +0900

> otherwise it would not be UNSPECIFIED.

Starting a terminology discussion will not help settle this issue. What I'm
talking about is an address that cannot be used by the client to
communicate with the network. We can call an address fake, or green cheese,
or whatever. The question is: why is it preferable to return such an
address? It seems to me that it is preferable to return an address that
could instead be used for communication.

> We've already agreed that middleboxes HAVE to accept yiaddr unspecified

Well, except that the middleboxes themselves don't agree. We can ignore
them, but if we do, we run the risk of making things not work. We need to
look at those risks and make trade-offs.

> server will OFFER 192.168.0.1.

That doesn't seem very useful since the client doesn't know what to
request. Sure, the client can send another discover (or, if it's in
renewing or rebinding, another request) without the option. But if it has
already received an address from the server, it doesn't need to do that. It
can just request it.

---

From: Ted Lemon <[email-masked]>
Date: Thu, 12 Dec 2019 21:27:02 -0500

Returning a constant IP address simplifies all cases except the legacy case. The middle box problem is likely minimal if it even still exists. I would like us to optimize for success, not for how things are now. 

I’m not advocating MUST. I’m advocating SHOULD. Clearly at least one DHCP server vendor will not follow the should. That’s fine. SHOULD specifies the preferred behavior but does not forbid other behavior. 

> On Dec 12, 2019, at 19:42, Lorenzo Colitti <[email-masked]> wrote:
> 
> Saying that yiaddr SHOULD or MUST be 0.0.0.0 creates incompatibility problems and complicates server implementation. What do we gain by doing so?

---

From: "Bernie Volz (volz)" <[email-masked]>
Date: Fri, 13 Dec 2019 02:26:50 +0000

And, having this option just be returned by the server when requested and if configured means no server changes are needed. Servers aren’t swapped out (updated) as frequently as clients, so that’s a big win for deployment. And, that’s a strong reason to allow normal processing – and it also means no middlebox issues.

It is perfectly normal for a client to initiate a DHCPDISCOVER but never follow up with a DHCPREQUEST – the client disconnected or was power cycled or … So there’s nothing wrong with assigning a “real” address.

Again, I think (with any necessary (?) consideration of RFC2563) we can allow 0.0.0.0 to be returned.

See my earlier email on this topic (allowing either a real or 0.0.0.0 address to be returned by the server in yiaddr).

  *   Bernie

From: dhcwg <[email-masked]> On Behalf Of Lorenzo Colitti
Sent: Thursday, December 12, 2019 9:11 PM
To: Roy Marples <roy=[email-masked]>
Cc: [email-masked]; Ted Lemon <[email-masked]>; Bernie Volz (volz) <[email-masked]>
Subject: Re: [dhcwg] [v6ops] Fwd: New Version Notification for draft-link-dhc-v6only-01.txt

Please.

Starting a terminology discussion will not help settle this issue. What I'm talking about is an address that cannot be used by the client to communicate with the network. We can call an address fake, or green cheese, or whatever. The question is: why is it preferable to return such an address? It seems to me that it is preferable to return an address that could instead be used for communication.

Well, except that the middleboxes themselves don't agree. We can ignore them, but if we do, we run the risk of making things not work. We need to look at those risks and make trade-offs.

That doesn't seem very useful since the client doesn't know what to request. Sure, the client can send another discover (or, if it's in renewing or rebinding, another request) without the option. But if it has already received an address from the server, it doesn't need to do that. It can just request it.

---

From: Roy Marples <[email-masked]>
Date: Fri, 13 Dec 2019 04:26:29 +0000

On 13/12/2019 02:10, Lorenzo Colitti wrote:
> On Fri, Dec 13, 2019 at 10:35 AM Roy Marples 
> <roy=[email-masked] 
> <mailto:[email-masked]>> wrote:
> 
> Starting a terminology discussion will not help settle this issue.

Plently of POSIX documents refer to all zero address as unspecified.
This is long standing.

If you want to call it fake, cheese or green or whatever is your bag.
But lets be clear, I didn't start the discussion, you started the fake news.

> What 
> I'm talking about is an address that cannot be used by the client to 
> communicate with the network. We can call an address fake, or green 
> cheese, or whatever. The question is: why is it preferable to return 
> such an address? It seems to me that it is preferable to return an 
> address that could instead be used for communication.

Because we sent an option to say we don't need an address.
If the server accepts this options any address returned we would just 
discard ....... so the actual use of this address is unspecified - do we 
use it or not?

Neo: WOAH

> them, but if we do, we run the risk of making things not work. We need 
> to look at those risks and make trade-offs.

So far we have a middlebox that doesn't agree with *current* RFC's.
I don't see how the proposal to allow the unspecified address here can't 
break what is already broken?

> renewing or rebinding, another request) without the option. But if it 
> has already received an address from the server, it doesn't need to do 
> that. It can just request it.

Eh?
The client will request it's default set of options. This is what I see

Client - don't need an address if something better, but here I am!
Server - I don't have anything better, here's an address!
Client - I want to renew, but I understand if there's something better!
Server - Here lad, I know something better so deprecate and continue!
Client - I accept the unspecified address so I discard what I have and 
use something better!

In this case we've not made any extra requests, just accepted the 
response into the flow.

Is this not the underlying goal of the new RFC?

Roy

---

From: Roy Marples <[email-masked]>
Date: Fri, 13 Dec 2019 05:08:47 +0000

> to look at those risks and make trade-offs.

Why should we care about what middleboxes (what does this even mean?) 
impose outside of a RFC?

For example, I could make a DHCP server that only responds to requests 
with a client ID that is a MAC address. It will ingore anything else.
There are examples of this in the wild which i deal with here and now - 
should DUID not be the default in contratiction to RFC 4361 conforming 
applications?

This is no different from your middlebox example that doesn't work with 
the unspecified address.

So ...... why is your case more special than mine?

Roy