Subject: [v6ops] IPv6-Only Preferred DHCPv4 option

From: Jen Linkova <[email-masked]>
Date: Wed, 4 Dec 2019 23:09:08 +1100

Hello,

One of the biggest issue in deploying IPv6-only LANs is how to do it
incrementally, when some hosts work just fine in NAT64 environment
while some legacy devices still need IPv4. Doubling the number of
network segments (having an IPv6-only and dual-stack segments of each
type) is an operational nightmare. So it would be just awesome if all
devices can co-exist in the same network segment and hosts capable of
operating in IPv6-only environment do not consume IPv4 addresses.
So here is the draft proposing a new DHCPv4 option to help saving IPv4
addresses and deploying IPv4-as-a-service:

Name:           draft-link-dhc-v6only
Revision:       00
Title:          IPv6-Only-Preferred Option for DHCP
Document date:  2019-12-04
Group:          Individual Submission
Pages:          9
URL:
https://www.ietf.org/internet-drafts/draft-link-dhc-v6only-00.txt
Status:         https://datatracker.ietf.org/doc/draft-link-dhc-v6only/
Htmlized:       https://tools.ietf.org/html/draft-link-dhc-v6only-00
Htmlized:       https://datatracker.ietf.org/doc/html/draft-link-dhc-v6only

Abstract:
   This document specifies a DHCP option to indicate that a host
   supports an IPv6-only mode and willing to forgo obtaining a IPv4
   address if the network provides IPv6 access.

Any comments/suggestions/reviews are highly appreciated!

Adding v6ops@ to Cc: as the problem is related to operating IPv6-only networks.

Thank you!
-- 
SY, Jen Linkova aka Furry

---

From: Bjørn Mork <[email-masked]>
Date: Wed, 04 Dec 2019 14:31:17 +0100

> Htmlized:       https://datatracker.ietf.org/doc/html/draft-link-dhc-v6only

  "While IPv6-only capable devices might use a
   heuristic approach to learning if the network provdes IPv6-only
   functionality and stop using IPv4 if it does, it might be practically
   undesirable.  One important reason is that when a host connects to a
   network, it does not know if the network is IPv4-only, dual-stack or
   IPv6-only.  To ensure that the connectivity over whatever protocol is
   present becomes available as soon as possible the host usually starts
   configuring both IPv4 and IPv6 immidiately.  If hosts were to delay
   requesting IPv4 until IPv6 reachability is confirmed, that would
   would penalize IPv4-only and dual-stack networks, which does not seem
   practical. "

Why can't the client just release the IPv4 address when it finds it has
IPv6 connectivity?  This would also avoid the problems you introduce
when the network falsely claims IPv6 support.

Bjørn

---

From: <[email-masked]>
Date: Wed, 4 Dec 2019 13:56:33 +0000

Hi Bjørn, 

Blindly releasing the IPv4 address when an IPv6 connectivity is available is problematic because the host does not know if a NAT64 function is available for a given network attachment. A host that discovers the presence of NAT64 (because a pref64 was discovered) can safely release any assigned IPv4 address. No additional signal is needed in such case.

Jen, do you have a case where you want to deploy IPv6-only host without announcing pref64 to that host? 

Cheers,
Med

> -----Message d'origine-----
> De : dhcwg [mailto:[email-masked]] De la part de Bjørn Mork
> Envoyé : mercredi 4 décembre 2019 14:31
> À : Jen Linkova
> Cc : [email-masked]; V6 Ops List; [email-masked]
> Objet : Re: [dhcwg] IPv6-Only Preferred DHCPv4 option
> 
> _______________________________________________
> dhcwg mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/dhcwg

---

From: Lorenzo Colitti <[email-masked]>
Date: Wed, 4 Dec 2019 23:40:09 +0900

> when the network falsely claims IPv6 support.

Doing this creates a bad user experience, because once an IPv4 address is
assigned to the device, apps immediately start using it. At that point,
taking the address away is disruptive, potentially causing user-visible
errors.

---

From: Philip Homburg <[email-masked]>
Date: Wed, 04 Dec 2019 16:04:54 +0100

>Any comments/suggestions/reviews are highly appreciated!

I wonder about the deployment scenario.

Basically the draft assumes that an operator is running both a dual stack
network and IPv4-as-a-service in the form of NAT64.

The draft assumes a migration path to NAT64, so we can assume that the 
IPv4 in dual stack is behind NAT as well.

In general, address shortage on a local network behind NAT is not a problem
(RFC 1918 space is big enough).

So the main motivation I can find for running NAT64 next to dual stack is
to collect statistics.

I wonder how many network would offer two ways to do IPv4 just to collect
statistic on how many hosts can both do NAT64 and have been modified to send
the new DHCP option, which does not benefit the host.

---

From: Tommy Pauly <[email-masked]>
Date: Wed, 04 Dec 2019 07:51:46 -0800

Hi Jen,

Thanks for posting this draft! I find it to be both a well-written document, and a great solution.

This will be particularly critical for networks that want to adopt IPv6-only (read, NAT64), but can't easily ensure that *all* devices on the network upgrade to support that. This concept of IPv6-mostly networks is a good stepping stone! =) What we've seen in cellular networks for NAT64 rollout has had hiccups, and an option like this to smooth the transition would have been useful there. But without an option like this, I don't see a good way for less-managed networks (enterprise Wi-Fis, public Wi-Fis) to make the transition since they can't guarantee what devices are on their networks.

As a client OS vendor, I think this would be easy for the client hosts to implement, and we'd likely see a scenario in which pretty quickly, most modern mobile devices and laptops would support this, and we'd end up with using v4 on networks only for more "legacy" devices.

I'd certainly support this document going forward and being adopted.

Best,
Tommy

> On Dec 4, 2019, at 4:09 AM, Jen Linkova <[email-masked]> wrote:
> 
> Hello,
> 
> v6ops mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/v6ops

---

From: Lencse Gábor <[email-masked]>
Date: Wed, 4 Dec 2019 17:10:04 +0100

Hi Med,

12/4/2019 2:56 PM keltezéssel, [email-masked] írta:
> A host that discovers the presence of NAT64 (because a pref64 was discovered) can safely release any assigned IPv4 address.

Maybe I'm misunderstanding something, but I do not agree. Unfortunately 
not all applications are compatible with NAT64. Please see our results in:

S. Répás, T. Hajas and G. Lencse, "Application Compatibility of the 
NAT64 IPv6 Transition Technology", /Proceedings of the 37th 
International Conference on Telecommunications and Signal Processing 
(TSP 2014)/, (Berlin, Germany, 2014. July, 1-3.) Brno University of 
Technology, pp. 49-55. DOI: 10.1109/TSP.2015.7296383
Full text is available from: 
http://www.hit.bme.hu/~lencse/publications/TSP-2014-AC.pdf

Best regards,

Gábor

---

From: Ted Lemon <[email-masked]>
Date: Wed, 4 Dec 2019 09:29:12 -0800

This is good in principle. The client behavior section should require the client to send a parameter request list and to specify the option code of the new option in the list along with any other options it expects to get. 

> On Dec 4, 2019, at 04:09, Jen Linkova <[email-masked]> wrote:
> 
> Hello,
>

---

From: <[email-masked]>
Date: Wed, 4 Dec 2019 17:48:28 +0000

Hi Gabor,

Please see inline.

Cheers,
Med

________________________________
De : v6ops [[email-masked]] de la part de Lencse Gábor [[email-masked]]
Envoyé : mercredi 4 décembre 2019 17:10
À : [email-masked]
Objet : Re: [v6ops] [dhcwg] IPv6-Only Preferred DHCPv4 option

Hi Med,

12/4/2019 2:56 PM keltezéssel, [email-masked]<mailto:[email-masked]> írta:

Maybe I'm misunderstanding something, but I do not agree.

Med: My assumption is what in the draft: the mode is explicitly set by a user.

   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.

   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.

Unfortunately not all applications are compatible with NAT64.

Med: Sure. All the issues discussed in RFC6269 apply. Some of them can be solved:

* bittorrent: https://tools.ietf.org/html/draft-boucadair-pcp-bittorrent-00
* SIP: https://tools.ietf.org/html/draft-boucadair-pcp-nat64-experiments-00

Please see our results in:

S. Répás, T. Hajas and G. Lencse, "Application Compatibility of the NAT64 IPv6 Transition Technology", Proceedings of the 37th International Conference on Telecommunications and Signal Processing (TSP 2014), (Berlin, Germany, 2014. July, 1-3.) Brno University of Technology, pp. 49-55. DOI: 10.1109/TSP.2015.7296383
Full text is available from: http://www.hit.bme.hu/~lencse/publications/TSP-2014-AC.pdf

Med: Thanks for the pointer. These issues are not specific to NAT64; many of them can be solved (see the pointers above, for example).

Best regards,

Gábor

---

From: Michael Richardson <[email-masked]>
Date: Wed, 04 Dec 2019 13:22:09 -0500

> Thanks for posting this draft! I find it to be both a well-written document, and a great solution.

As an author, thank you.
I think that this document grew quickly from hallway discussion at IETF106.

    > As a client OS vendor, I think this would be easy for the client hosts
    > to implement, and we'd likely see a scenario in which pretty quickly,
    > most modern mobile devices and laptops would support this, and we'd end
    > up with using v4 on networks only for more "legacy" devices.

A question that we had was whether or not hosts in a IPv6-mostly network
should configure IPv4-LL addresses in order to speak to legacy-v4-only hosts.

The DHCPv4 option has a payload value that can be returned with information.
Right now, it's a boolean: if the option exists the network is ready.
We have considered two things:

1) We could put a time at which the host should recheck for v4.  This avoids
   making mis-configuration of IPv6-mostly networks permanent.  The question
   is not whether such a recheck timeout should exist (it must); but rather
   whether we should allow it to be configured in the option, or if we can
   just suggest some implementation local value.

2) Whether or not IPv4-LL (169.254.0.0) addresses should be configured or not.
   We could make this an option in the payload here as well.

We wind up with four classes of v4-hosts:

1) IPv4-only legacy hosts which do not speak IPv6 at all.
   (The old printer in the corner, a whole plethora of stupid Web-Connected IoT devices)
   Some might not even have IPv4-LL addresses though!

2) Dual-Stack hosts do not understand this option.
   They have IPv4-LL and IPv6-LL addresses as well as IPv6 GUAs and ULAs, so
   they can talk to any host on the network.

3) Dual-Stack hosts which have an operational need for IPv4 that is not
   satisfied by NAT64, and which therefore either do not include this option,
   or for which the network is aware of their need, and does not answer with
   the option set.

4) Dual-Stack hosts which turn off their IPv4.
   Do they keep IPv4-LL so that they can talk to (1)?

[5) IPv6-only capable hosts which never speak IPv4]

--
]               Never tell me the odds!                 | ipv6 mesh networks [
]   Michael Richardson, Sandelman Software Works        |    IoT architect   [
]     [email-masked]  http://www.sandelman.ca/        |   ruby on rails    [

--
Michael Richardson <[email-masked]>, Sandelman Software Works
 -= IPv6 IoT consulting =-

---

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

There is also a question of whether the V6ONLY-WAIT time value that the client should use be returned in the option - i.e., the option should be a 4 (or 2) octet option returning an unsigned integer of the time. Perhaps returning 0 indicates the client should use its default (thus the valid values would be 0 or 300 >= value <= max (86,400 sec, 24 hours?)).

This was discussed while draft was in development but we didn't end up with a decision. So, worth discussing a bit on list.

A minor note about the draft requesting use of (DHCPv4) option code 108. Per RFC3679 this was in use as a "swap path" option at some point, though never published as a draft. That is why it is marked as "REMOVED/unassigned" as the idea was to NOT reuse these option numbers until there was a need (i.e., no other just "unassigned" option codes were available). While I have no objection if the draft wishes to request use of that option code, I just wanted to point out that there could be some other conflicting usage out in the wild.

- Bernie

---

From: Brian E Carpenter <[email-masked]>
Date: Thu, 5 Dec 2019 08:53:11 +1300

As an ex-author of an ex-draft that suggested using IPv6 to tell hosts to avoid IPv4, I'm curious to know whether a draft that suggests using IPv4 to tell hosts to prefer IPv6 will also be accused of being an operational nightmare.

Regards
   Brian

---

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

I think there is a typo in Section 2 (middle paragraph):

   Another benefit of using DHCPv4 for signalling is that IPv4 will be
   disabled only if both the client and the server indicate IPv6-only
   capability.  It allows IPv6-only capable clients to turn off **IPv6**
   only upon receiving an explicit signal from the network and operate
   in dual-stack or IPv4-only mode otherwise.

I think that "turn off IPv6" should be "turn off IPv4".

Also s/signalling/signaling/.

- Bernie

-----Original Message-----
From: dhcwg <[email-masked]> On Behalf Of Jen Linkova
Sent: Wednesday, December 4, 2019 7:09 AM
To: [email-masked]
Cc: [email-masked]; V6 Ops List <[email-masked]>
Subject: [dhcwg] IPv6-Only Preferred DHCPv4 option

Hello,

One of the biggest issue in deploying IPv6-only LANs is how to do it incrementally, when some hosts work just fine in NAT64 environment while some legacy devices still need IPv4. Doubling the number of network segments (having an IPv6-only and dual-stack segments of each
type) is an operational nightmare. So it would be just awesome if all devices can co-exist in the same network segment and hosts capable of operating in IPv6-only environment do not consume IPv4 addresses.
So here is the draft proposing a new DHCPv4 option to help saving IPv4 addresses and deploying IPv4-as-a-service:

Abstract:

Thank you!

---

From: Nick Hilliard <[email-masked]>
Date: Wed, 4 Dec 2019 20:43:03 +0000

Brian E Carpenter wrote on 04/12/2019 19:53:
> As an ex-author of an ex-draft that suggested using IPv6 to tell
> hosts to avoid IPv4, I'm curious to know whether a draft that
> suggests using IPv4 to tell hosts to prefer IPv6 will also be accused
> of being an operational nightmare.

I haven't read the draft yet - and won't get to it for a couple of days 
- but am also curious about why this approach is better than the other 
way around :-)

Nick

---

From: Ted Lemon <[email-masked]>
Date: Wed, 4 Dec 2019 12:44:52 -0800

On Dec 4, 2019, at 12:43 PM, Nick Hilliard <[email-masked]> wrote:
> approach is better than the other way around :-)

Because once the device knows it’s on an IPv6-only network, it doesn’t have to keep trying to get an IPv4 lease, and we don’t have to deal with the problem of it getting a lease before it gets an answer from DHCPv6 or RA and then having running connections that would be killed.

---

From: Fred Baker <[email-masked]>
Date: Wed, 4 Dec 2019 12:49:08 -0800

On Dec 4, 2019, at 4:09 AM, Jen Linkova <[email-masked]> wrote:
> while some legacy devices still need IPv4.

A general comment - I don't think this is "devices" as much as it is "applications". I'm thinking here of issues raised in RFC 2993 among others.

I would argue that NAT64 is subject to the same issues as NAT44; there is a coupling between the network and application layers in that an IP address is used as an application layer identifier, and a coupling between addressing domains in the network in that hosted applications presume that an address they use is meaningful to and means the same to an application in another domain. RFC 3439 talk about coupling primarily in terms of time, but couplings such as I describe are also dangerous, and I would argue that the issues raised in RFC 2993 are direct results of coupling. So, whenever an address is embedded in application data and interpreted or used by the peer application, there will be a NAT issue.

What would I want to do about it? I would not want to see an ALG (to my mind, that works against higher layer security such as TLS or IPSec), but rather see the application use an application layer identifier such as a DNS name. 

Of course, my opinion plus some loose change might obtain a cup of coffee...

---

From: Jen Linkova <[email-masked]>
Date: Thu, 5 Dec 2019 07:49:59 +1100

> As an ex-author of an ex-draft that suggested using IPv6 to tell hosts to avoid IPv4, I'm curious to know whether a draft that suggests using IPv4 to tell hosts to prefer IPv6 will also be accused…

I hope not and let me explain why I have that hope ;)
AFAIR the main issue with using IPv6 to signal to the host 'pls turn
of IPv4' was that many IPv4-only networks might not have IPv6 security
in place. So an attacker can use IPv6 to a)turn off IPv4 and b) break
IPv6 by sending a rogue RA.

What this draft proposes is to use DHCPv4 to signal to the host 'pls
turn of IPv4' . The same protocol, not IPv6. So there is a shared fate
here - it the network allows rogue DHCP servers then IPv4 is doomed
anyway.  But it's all is working over IPv4, no IPv6 involved.

---

From: Jen Linkova <[email-masked]>
Date: Thu, 5 Dec 2019 08:39:58 +1100

> when the network falsely claims IPv6 support.

One reason has been mentioned by Lorenzo: releasing an IPv4 address is
disruptive to applications (point taken, we'll update the draft text
to make it clear).
Another reason is that it would bring back all objections we heard
about IPv6-only RA flag: 'an attacker sends an IPv6 packet - and
IPv4-only network might not have IPv6 security in place - and breaks
IPv4'. What we are proposing is that DHCP server must be explicitly
configured as 'this network/pool is IPv4-as-a-service' so to do any
harm
the attacker needs to deploy a rogue DHCP - in which case your IPv4 is
trouble anyway.

---

From: Jen Linkova <[email-masked]>
Date: Thu, 5 Dec 2019 08:51:35 +1100

> Blindly releasing the IPv4 address when an IPv6 connectivity is available is problematic because the host does not know if a NAT64 function is available for a given network attachment. A host that…

it would be no difference from what
https://tools.ietf.org/html/draft-ietf-6man-ipv6only-flag was
proposing. And as many of us know, that draft was not able to reach
consensus, the main objection being 'we can not allow an IPv6 packet
to turn off IPv4'.
What dhc-v6only draft does is  allowing the DHCPv4 server to be
configured in such way that  hosts can selectively turn off IPv4. No
IPv6 traffic involved, everything operates over IPv4.

> Jen, do you have a case where you want to deploy IPv6-only host without announcing pref64 to that host?

I *am* deploying them right now, because pref64 draft is with IESG
right now and many of my routers are not able to send out PREF64 RA
option yet.

I agree that in theory pref64 presence is a very good implicit signal
for 'you don't really need IPv4'. However when a host connects to a
network it does not know if pref64 is available when it starts DHCPv4
process. So to use RAs as a signal you need to either delay DHCPv4 (==
penalize v4-only and dual-stack networks) or do all those undesirable
RELEASE tricks later.
I believe this is discussed in the Introduction and the Section 2 of
the draft but I'll look into how to clarify the text.

---

From: Jen Linkova <[email-masked]>
Date: Thu, 5 Dec 2019 08:54:19 +1100

> This is good in principle. The client behavior section should require the client to send a parameter request list and to specify the option code of the new option in the list along with any other o…

Thanks Ted! A clarifying question: the draft currently say
(https://tools.ietf.org/html/draft-link-dhc-v6only-00#section-3.2)

"IPv6-only capable clients SHOULD include the IPv6-only Preferred
option in the Parameter Request List in DHCPDISCOVER and DHCPREQUEST
messages."

Do you think smth else should be required here?

---

From: Fernando Gont <[email-masked]>
Date: Wed, 4 Dec 2019 19:19:52 -0300

> anyway.  But it's all is working over IPv4, no IPv6 involved.

Disclaimer: I haven't red the document.

But based on your description, I would suggest that the subject line is
changed. And that if there's similar wording in the document, that's
changed, too.

An DHCPv4 option to turn off IPv4 is acceptable (the two protocols are
*npt* being entangled). Whereas the subject line makes one thing that
you are using IPv4 to convey IPv6 signals -- where in fact you seem to
be using IPv4 to signal information about IPv4.

I'd bet that simple change in wording will save you a lot of time ;-)

Thanks,
-- 
Fernando Gont
SI6 Networks
e-mail: [email-masked]
PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492

---

From: Jen Linkova <[email-masked]>
Date: Thu, 5 Dec 2019 10:07:13 +1100

> should configure IPv4-LL addresses in order to speak to legacy-v4-only hosts.

Actually the more I think about it the more I believe the host should
be doing whatever they are doing w/o DHCPv4 presence.
Android does not configure IPv4 link-locals, MacOS does. Making the
same OS behaving differently ("no DHCPv4 whatsoever" vs "DHCPv4 server
responded with IPv6-only Preferred option") might be undesirable. As
an operator I'd expect that IPv6-only capable host would behave the
same way on a dedicated IPv6-only segment and on IPv6-mostly segment.

---

From: Jen Linkova <[email-masked]>
Date: Thu, 5 Dec 2019 10:10:57 +1100

> - but am also curious about why this approach is better than the other

I hope that after you read the draft (you only need read pages 2-7
actually) your curiosity is going to be satisfied ;)
Otherwise I'll do my best to answer any questions you might have on that topic!

---

From: Jen Linkova <[email-masked]>
Date: Thu, 5 Dec 2019 10:26:44 +1100

> A general comment - I don't think this is "devices" as much as it is "applications". I'm thinking here of issues raised in RFC 2993 among others.

You are right, it's applications getting broken w/o IPv4 indeed. The
text is saying 'devices' just for the sake of brevity: as a network
engineer I see *devices* connecting to the network, and IPv4 addresses
being assigned to the devices. A device just a box with a number of
applications (+ an OS) running inside.
However there are cases when an application needs an IPv4 address to
operate while the whole device does not. Think of a device with
464XLAT  enabled (e.g. an Android phone). The same application might
work perfectly fine on a mobile phone connected to an IPV6-only WiFi
but gets broken if I run it on my macbook connected to the same
network.

Would it be better if the sentence you quoted would be saying 'while
some legacy devices still need IPv4 addresses as their OSes and/or
applications depend on IPv4'?

> What would I want to do about it? I would not want to see an ALG (to my mind, that works against higher layer security such as TLS or IPSec), but rather see the application use an application layer…

NAT64 is not perfect and is not a silver bullet but I do not think we
have any better tool right now. At least NAT64 is used for iPv4-only
destinations only so damage is contained (and the footprint will be
reducing over time, I hope).
-- 
SY, Jen Linkova aka Furry

---

From: Lorenzo Colitti <[email-masked]>
Date: Thu, 5 Dec 2019 08:57:19 +0900

> - but am also curious about why this approach is better than the other

Here are a couple of reasons why we believe this proposal will fare better
than the IPv6-only flag:

   1. It has a clear goal and clear semantics.  There was little consensus
   on the meaning of the IPv6-only flag. Did it mean that there was no IPv4 on
   the link? That the network should not provide IPv4 addresses? Or that hosts
   should never send packets with IPv4 ethertypes? If the latter, why not drop
   the packets in the infrastructure? But then, what about link-local? And so
   on. In contrast, this option's goal is very clear (conserve IPv4 addresses)
   and its meaning is very clear: here's an IPv4 address if you want it, but
   please don't use it if you don't need it.
   2. It is using a protocol that already configures IPv4 to configure
   IPv4. The IPv6-only flag was trying to affect IPv4 using an IPv6 protocol,
   and that allows attackers to mount attacks on existing networks that have
   not deployed IPv6 and thus have no IPv6 security measures in place.

---

From: Jen Linkova <[email-masked]>
Date: Thu, 5 Dec 2019 11:26:12 +1100

> I think that "turn off IPv6" should be "turn off IPv4".

Oh indeed! Will be fixed in -01.
Thanks for pointing out!

---

From: Roy Marples <[email-masked]>
Date: Thu, 5 Dec 2019 00:30:33 +0000

Hi Jen!

I maintain dhcpcd, a fairly popular DHCP and DHCPv6 client.

> addresses and deploying IPv4-as-a-service:

I disagree with a fair chunk of this.
It assumes that IPv6 is the be-all and end-all. Maybe one day we will 
have IPv8?

It would be much better to say that DHCP as a whole is disabled.
See RFC 2563 for an equivalent DHCP option for IPv4LL. This is fair 
enough because it's all IPv4 addresses. Set both options and you're golden.

BUT - what if we need to enable DHCP again? Should clients still listen 
for FORCERENEW? It does pose a small dilema because there isn't actually 
anything to renew.

So maybe we could let this new option fit in with T1 and T2 timers 
(well, effectively T2 as there's no address to unicast from) and you can 
even set this to infinity if you wanted to.

Roy

---

From: Mark Smith <[email-masked]>
Date: Thu, 5 Dec 2019 11:52:35 +1100

On Thu, 5 Dec 2019, 10:57 Lorenzo Colitti, <lorenzo=
[email-masked]> wrote:

>    1. It has a clear goal and clear semantics.  There was little
>    consensus on the meaning of the IPv6-only flag. Did it mean that there was
>    no IPv4 on the link? That the network should not provide IPv4 addresses? Or
>    that hosts should never send packets with IPv4 ethertypes? If the latter,
>    why not drop the packets in the infrastructure? But then, what
>    about link-local? And so on. In contrast, this option's goal is very clear
>    (conserve IPv4 addresses) and its meaning is very clear: here's an IPv4
>    address if you want it, but please don't use it if you don't need it.
>
>
So I haven't read the draft either, although the following applied in the
context of the the IPv6-only flag draft and I think this one.

Why aren't IPv4 (and IPv6) addresses acquired on-demand when the first
application opens an IPv4 (or IPv6) socket, and then released when the last
application closes the last IPv4 socket?

It seems to me that it is really only tradition that devices acquire
network layer addresses when the host boots up or when an interface
attaches to a new link. Devices are acquiring addresses even though there
may never be applications running on the host that use the address.

If hosts only acquired IPv4 addresses via DHCPv4 based on when the first
IPv4 application started running, then when a host is only running IPv6
only applications, it would never acquire an IPv4 address because it
wouldn't need one, meaning never try to use DHCPv4 (so would avoid the
link-layer broadcast DHCP_DISCOVERS) and never use ARP (avoid link-layer
broadcast ARP Requests).

If all IPv4 on-demand hosts on a link are then only running IPv6 only
applications, IPv4 would not ever appear on the link. Hosts would
effectively switch off IPv4 on links themselves because they don't need it.

More generally, IPv4 would automatically drain away from networks more
hosts exclusively running IPv6 only applications appear. In this scenario,
there would be no need for any out-of-band signalling mechanism to say
switch off IPv4, such as what this draft proposes or what the IPv6-only RA
flag draft proposed.

Some might say they want hosts to acquire addresses for security purposes
of knowing what devices are on a link. However, I can attach to a link,
purposely not acquire an IPv4 (or an IPv6) address, yet spoof packets with
IPv4 or IPv6 addresses. In other words, if you truly want to have an audit
trail of devices that attach to your link/network for security purposes,
you need to do it at layer1 and/or layer 2 at the point of attachment of
the device, not layer 3.

>    1. It is using a protocol that already configures IPv4 to configure

---

From: David Farmer <[email-masked]>
Date: Wed, 4 Dec 2019 18:57:53 -0600

> same way on a dedicated IPv6-only segment and on IPv6-mostly segment.

Regarding IPv4-LL, I like Roy Marples suggestion of combining this with RFC
2563 to determine if a host is to configure an IPv4-LL, and in that case,
the address returned should be 0.0.0.0.

Also, is there any reason that 0.0.0.0 shouldn't be the address retunded by
a server "if the IPv6-only Preferred option is present in the Parameter
Request List received from the client and the corresponding DHCP pool is
explicitly configured as belonging to an IPv6-mostly network segment" as
discussed in Section 3.3?

Thanks

-- 
===============================================
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: Jen Linkova <[email-masked]>
Date: Thu, 5 Dec 2019 12:00:43 +1100

Hi Roy,

> It assumes that IPv6 is the be-all and end-all. Maybe one day we will

Oh I do hope that by the time we start deploying IPv8-only networks
we'll be done with IPv4 ;))
On a serious note: if one day we discover that we also have other
scenarios (in addition to IPv6-only networks) when we might want to
provide IPv4-as-a-service, the proposed mechanism still can be used I
believe.
While the draft keeps mentioning IPv6-only and NAT64 as a prerequisite
for disabling IPv4, it's only because it's the only use case exist
today.
If I wake up tomorrow to find out that we have IPv2020 and majority of
my devices can operate on IPv2020-only while I still have to provide
IPv4 for some hosts, we can do 's/IPv6/IPv2020/g' in the text.

> It would be much better to say that DHCP as a whole is disabled.

Sorry, I'm not sure I understand. The draft is proposing that if a
client is willing to live w/o IPv4 and the server confirms that IPv4
is optional on the network segment, the client is disabling DHCP for
some time.
What would you like us to change?

> for FORCERENEW? It does pose a small dilema because there isn't actually

The draft covers that scenario. DHCPv4 is disabled for V6ONLY_WAIT seconds.

---

From: Jen Linkova <[email-masked]>
Date: Thu, 5 Dec 2019 12:02:52 +1100

On Thu, Dec 5, 2019 at 11:58 AM David Farmer <[email-masked]> wrote:
> Also, is there any reason that 0.0.0.0 shouldn't be the address retunded by a server "if the IPv6-only Preferred option is present in the Parameter Request List received from the client and the corresponding DHCP pool is explicitly configured as belonging to an IPv6-mostly network segment" as discussed in Section 3.3?

We discussed that but some concerns were raised - allegedly it might
make some DHCP-snooping switches very unhappy.

---

From: David Farmer <[email-masked]>
Date: Wed, 4 Dec 2019 19:09:01 -0600

On Wed, Dec 4, 2019 at 7:03 PM Jen Linkova <[email-masked]> wrote:

> > Also, is there any reason that 0.0.0.0 shouldn't be the address retunded
> by a server "if the IPv6-only Preferred option is present in the Parameter

If that is really the case then I think some discussion on selecting the
address returned is probably needed in the draft.

Thanks.

---

From: Roy Marples <[email-masked]>
Date: Thu, 5 Dec 2019 01:12:10 +0000

> What would you like us to change?

Just the wording basically.
It assmues only IPv6.
I dislike it when different protocol families discuss each other - IPv6 
should not turn off IPv4, likewise IPv4 should not turn off IPv6.
I would prefer it if Iv6 was not mentioned at all outside of a use case 
for the option.

"The network" should say if each protocol should be used *for* each 
protocol.
I know for sure that there are other network protocols at the equivalent 
OSI layer - sure not as popular as IPv6 but why exclude them as well?

> The draft covers that scenario. DHCPv4 is disabled for V6ONLY_WAIT seconds.

Is the wait seconds even needed?
Just set the T2 timer and treat it as leasing the unspecified address. 
Less data on the wire, less churn in DHCP clients. V6ONLY_WAIT provides 
nothing of value as I see it.

Roy

---

From: Roy Marples <[email-masked]>
Date: Thu, 5 Dec 2019 01:16:14 +0000

> make some DHCP-snooping switches very unhappy.

I quickly skimmed RFC2131 and nothing is mentioned about any assigned 
address being unspecified or otherwise invalid.

So as I see it, what the client should do is Unspecified Behaviour.
We could treat it as any other standard and define it.

It's not as if current implementations don't barf on current RFC's .....

Roy

---

From: Mark Smith <[email-masked]>
Date: Thu, 5 Dec 2019 12:19:38 +1100

> It assumes that IPv6 is the be-all and end-all. Maybe one day we will

Going by the now almost entire lack of existence of Appletalk, IPX,
DECNET, XNS, VINES (I haven't seen or heard of any of them in a
network since 1999),  it's likely IPv6 will be the single network
layer protocol in the future. Running a single network layer protocol
is cheaper and easier, which is why those others have gone away (that
also explains why nearly all links use or emulate (Wifi) Ethernet
framing, unless they specifically can't).

IPv6 will have a life, just as IPv4 has had a life, and those other
past protocols have had a lives. IPv6 is designed to last for much
longer than almost any of them, centuries most likely, so I don't
think we shouldn't be worrying about accommodating "IPv8" now at the
cost of making IPv4 easier to move away from. We don't have any idea
what "IPv8"'s transition requirements are or what it will even look
like.

---

From: Roy Marples <[email-masked]>
Date: Thu, 5 Dec 2019 01:36:57 +0000

> what "IPv8"'s transition requirements are or what it will even look

And this affects the wording and intent of my proposal how?

1 client sends DISCOVER with I CAN WORK WITHOUT DHCP ADDRESS option
2 server sends I HAVE NO DHCP ADDRESS option with T2 timer
3 client reads this and will retry in T2 seconds

This satisfies the use case the OP put forward and makes no mention of 
any other protocol than DHCP AND makes things much simpler to actually 
implement.
What did I miss?

Roy

---

From: Lorenzo Colitti <[email-masked]>
Date: Thu, 5 Dec 2019 11:19:52 +0900

> link-layer broadcast DHCP_DISCOVERS) and never use ARP (avoid link-layer

Speaking as an OS implementer: how do I know whether an application is an
IPv4 application?

   - When it calls getaddrinfo() with AF_UNSPEC? Pretty much all apps do
   that.
   - When it creates an IPv4 socket? But what if it's creating an IPv4
   socket for the purpose of connecting to another network on the system
   (e.g., cellular data) that does have IPv4?
   - When it does a connect() on an IPv4 socket? But what if that's just a
   happy eyeballs stack that is using IPv4 because it might be available?
   - What if the app knows it needs IPv4 and will refuse to do any
   networking if it doesn't find an IPv4 address on the system?

---

From: Mark Smith <[email-masked]>
Date: Thu, 5 Dec 2019 13:26:22 +1100

> And this affects the wording and intent of my proposal how?

I wasn't addressing your specific proposal.

I was addressing this comment.

"> It assumes that IPv6 is the be-all and end-all. Maybe one day we will
> have IPv8?"

and indirectly this comment:

> anything to renew."

A network/link using the sort of mechanism in this draft and the past
IPv6-Only RA flag draft have made conscious decision to switch off
IPv4. They have actively decided that "IPv6 is the be-all and end-all"
is their intent from now on.

They know they're very unlikely to need to switch IPv4 back on on that
link (otherwise, why would they enable these types of mechanisms?),
which means we don't have to place much if any weight on situations
such as "BUT - what if we need to enable DHCP again? Should clients
still listen for FORCERENEW? "

If somebody wanted to switch IPv4 back on on that link, after they've
actively enabled one of these IPv4 switch off types of mechanisms,
then it would be reasonable for us to assume they're willing to reboot
all of the hosts or similar to boot strap DHCPv4 again. They they're
not willing to go to that effort, then they're not ready to switch
IPv4 off yet.

> any other protocol than DHCP
>AND makes things much simpler to actually
> implement.
> What did I miss?
>

---

From: Jen Linkova <[email-masked]>
Date: Thu, 5 Dec 2019 13:27:21 +1100

On Thu, Dec 5, 2019 at 11:53 AM Mark Smith <[email-masked]> wrote:
> Why aren't IPv4 (and IPv6) addresses acquired on-demand when the first application opens an IPv4 (or IPv6) socket, and then released when the last application closes the last IPv4 socket?

- Because then all devices in my network would request IPv4 all the
time.  Even if an application supports IPv6, it might still try to
open IPv4 socket. In case it's on a dual-stack or IPv4-only network.
Therefore I'd not achieve my goal of reducing IPv4 footprint in the
network.
- If the host is running clat, then applications might open IPv4
sockets but it does not necessary mean the host itself needs an IPv4
address. It might not if the network provides NAT64. Or it might if
the network is just dual-stack or IPv4-only.

---

From: Lorenzo Colitti <[email-masked]>
Date: Thu, 5 Dec 2019 11:27:36 +0900

> nothing of value as I see it.

I think there is value because the two are conceptually different.

The T2 timer is about the validity of the address that is offered, and
specifies how often that address should be renewed if the client accepts
the offer. The V6ONLY_WAIT timer is about how long the client should wait
before asking again if it doesn't accept the offer. I think these two could
be very different. For example, if IPv4 is a very scarce resource and
almost al clients are IPv6, the operator will want to use short lease times
(e.g., 1 hour, or shorter) to ensure that hosts that disconnect from the
network don't tie up scarce IPv4 addresses when they're not connected. That
same operator would want the V6ONLY_WAIT timer to be large in order to
avoid excessive load on the DHCP server (and to conserve battery on the
devices).

If there is consensus that this is useless we can remove it, but I don't
see a a strong reason to give up that extra flexibility. Is there?

---

From: Lorenzo Colitti <[email-masked]>
Date: Thu, 5 Dec 2019 11:29:11 +0900

On Thu, Dec 5, 2019 at 11:27 AM Lorenzo Colitti <[email-masked]> wrote:

> the offer

Ok, not renewed, rebound. But I think the point still stands.

---

From: Roy Marples <[email-masked]>
Date: Thu, 5 Dec 2019 02:50:29 +0000

On 05/12/2019 02:27, Lorenzo Colitti wrote:
> On Thu, Dec 5, 2019 at 10:12 AM Roy Marples <[email-masked] 
> <mailto:[email-masked]>> wrote:
> 
> The T2 timer is about the validity of the address that is offered

Wrong.
The T2 timer addresses the lease as a whole. At this point the address 
is just meta data, just like domain or dns servers.

, and
> the offer. The V6ONLY_WAIT timer is about how long the client should 
> wait before asking again if it doesn't accept the offer.

Wrong again.
Or at least V6ONLY_WAIT is at the very least badly worded, but DHCP 
should not depend on any IPv6 settings - or vice versa. Is it too much 
to ask to keep protocol setup separate?

As we're not offering an address in this situation, how is V6ONLY_WAIT 
different from a timer source that cannot exist? As such, why invent a 
new timer source?

> I think these 
> two could be very different. For example, if IPv4 is a very scarce 
> resource and almost al clients are IPv6, the operator will want to use 
> short lease times (e.g., 1 hour, or shorter) to ensure that hosts that 
> disconnect from the network don't tie up scarce IPv4 addresses when 
> they're not connected. That same operator would want the V6ONLY_WAIT 
> timer to be large in order to avoid excessive load on the DHCP server 
> (and to conserve battery on the devices).
> 

I don't see any extra flexibility offered. You talk about lease times 
and yet say T1/T2 can't be used - why? All I see is more complication 
when things can be kept simple.

Roy

---

From: Lorenzo Colitti <[email-masked]>
Date: Thu, 5 Dec 2019 12:48:10 +0900

> is just meta data, just like domain or dns servers.

Regardless: the T2 timer is about the validity of the information that is
offered. The V6ONLY_WAIT timer is different: it's about when the client
should ask again if the client *does not request* the offer.

> to ask to keep protocol setup separate?

Then suggest a name that you like more? I can think of DISCOVER_WAIT and
INIT_WAIT, but I'm fine with any name that has WG consensus.

> different from a timer source that cannot exist? As such, why invent a

In the document as currently worded, the network does offer an address. It
says that the client MUST NOT configure the address if it supports the new
option.

> when things can be kept simple.

There's a difference in semantics: the least time is meaningful to clients
that request the lease and directly affects their behaviour and the number
and frequency of DHCP packets that they send. The V6ONLY_WAIT timer is
meaningful to clients that do not request the lease. As in the example I
provided, the operator is likely going to want to configure them
differently. We should also bear in mind that there may be devices on the
path (e.g., relays, snooping switches) that see these offer packets. Using
a separate timer avoids the possibility that these devices would act on the
T2 field in ways that we don't anticipate or desire. Using a separate
option also makes it clear that there is no need for this document to
update RFC 2132 and RFC 8415 to amend the definition of the IP address
lease time option and the T1/T2 timers.

>From a complexity perspective, I think a separate timer is actually
simpler. While it does need to be parsed, that needs to happen anyway. The
fact that it's a separate option and has separate semantics makes it easier
to reason about the behaviour of the state machine than if we were
overloading the existing option. As the maintainer of a popular DHCP client
myself, I would prefer it.

Additionally, I would expect that a separate option would be simpler to
implement on the server side. This is because the server can just continue
to consider the lease time a property of the address pool, and treat this
new option simply as a statically-configured option that is returned to
clients iff they requested it in the PRL. If we use the same field for the
lease timer and the V6ONLY_WAIT timer, then the server will need to change
the lease timer in DHCPOFFER packets depending on whether the option was
requested or not, and I would expect that to be more complex. +Tomek
Mrugalski <[email-masked]> any thoughts on this?

---

From: Roy Marples <[email-masked]>
Date: Thu, 5 Dec 2019 04:45:59 +0000

On 05/12/2019 03:48, Lorenzo Colitti wrote:
> On Thu, Dec 5, 2019 at 11:50 AM Roy Marples <[email-masked] 
> Regardless: the T2 timer is about the validity of the information that 
> is offered. The V6ONLY_WAIT timer is different: it's about when the 
> client should ask again if the client *does not request* the offer.

So in simple terms.
The server offers some information.
Given this information (in current DHCP semantics) we can RENEW (T1) or 
REBIND (T2).
If the client does not request the offer (hey! I see this new fangled 
option here that says NO DHCP) the client can still accept the T2 timer 
at the very least.

Think of the analogus RFC 7083 - Modification to Default Values of 
SOL_MAX_RT and INF_MAX_RT. This RFC goes out of its way not to add new 
timers.

> In the document as currently worded, the network does offer an address. 
> It says that the client MUST NOT configure the address if it supports 
> the new option.

You are directly correlating T2 to an address. Please don't - T2 is for 
the whole lease.

> There's a difference in semantics: the least time is meaningful to 
> clients that request the lease and directly affects their behaviour and 
> the number and frequency of DHCP packets that they send. The V6ONLY_WAIT 
> timer is meaningful to clients that do not request the lease.

I'm not fully following here.
DISOVER - DHCP optional
server says - OK, retry around T2 (our new option)

vs

DISCOVER - No new option, I want a lease
server says - Sure! here's T1 and T2 timers

  As in the
> example I provided, the operator is likely going to want to configure 
> them differently. We should also bear in mind that there may be devices 
> on the path (e.g., relays, snooping switches) that see these offer 
> packets. Using a separate timer avoids the possibility that these 
> devices would act on the T2 field in ways that we don't anticipate or 
> desire. Using a separate option also makes it clear that there is no 
> need for this document to update RFC 2132 and RFC 8415 to amend the 
> definition of the IP address lease time option and the T1/T2 timers. >
> simpler. While it does need to be parsed, that needs to happen anyway.

Only because you are insistent in putting it into a new option.
It's not needed.

> The fact that it's a separate option and has separate semantics makes it 
> easier to reason about the behaviour of the state machine than if we 
> were overloading the existing option. As the maintainer of a popular 
> DHCP client myself, I would prefer it.

Well, if you prefer extra code, unit tests and bloat, don't let me stop you.
But when it comes to my code I would rather keep it lean and mean.

Or to put it another way - I would not like anyone to force needless 
code when it's not really needed.

> implement on the server side. This is because the server can just 
> continue to consider the lease time a property of the address pool, and 
> treat this new option simply as a statically-configured option that is 
> returned to clients iff they requested it in the PRL. If we use the same 
> field for the lease timer and the V6ONLY_WAIT timer, then the server 
> will need to change the lease timer in DHCPOFFER packets depending on 
> whether the option was requested or not, and I would expect that to be 
> more complex. +Tomek Mrugalski <mailto:[email-masked]> any 
> thoughts on this?

 From what I'm proposing, the extra option server side is like DHCP:on/off
It's not complex or rocket science. It addreses the need.
There is no concern about IPv6 or future IPv8 or whatever.

Roy

---

From: Jen Linkova <[email-masked]>
Date: Thu, 5 Dec 2019 16:32:50 +1100

On Thu, Dec 5, 2019 at 9:20 AM Fernando Gont <[email-masked]> wrote:>
> be using IPv4 to signal information about IPv4.

What exactly is negotiated using the proposed mechanism is "*if* the
network provides NAT64 service, the host does not need an IPv4
address".

---

From: Fernando Gont <[email-masked]>
Date: Thu, 5 Dec 2019 02:51:55 -0300

> network provides NAT64 service, the host does not need an IPv4

Let me rephrase my question. What are the semantics of the option? "Turn
off IPv4?" -- If that's the semantics, then what triggered the use of
the option, from the pov of the ipv4 host, is rather irrelevant.

Side question: What if the network provides NAT64 service, but there are
local nodes that do not implement IPv6 (e.g., printers)?

Thanks!

Cheers,

---

From: Lorenzo Colitti <[email-masked]>
Date: Thu, 5 Dec 2019 15:33:59 +0900

DISOVER - DHCP optional
> server says - Sure! here's T1 and T2 timers

The problem is that these two packets are the same except for one option.
>From the perspective of a recipient that does not understand the option,
those two packets are exactly the same.

---

From: Alexandre Petrescu <[email-masked]>
Date: Thu, 5 Dec 2019 07:42:02 +0100

Hi, v6opsers,

Are we supposed to discuss this draft now?

Alex

---

From: Jen Linkova <[email-masked]>
Date: Thu, 5 Dec 2019 18:01:16 +1100

> I would prefer it if Iv6 was not mentioned at all outside of a use case

There is a catch there.
Right now the *only* possible scenario when a host might consider IPv4
optional is that:
1) the host supports IPv6
2) either all applications on that host work in NAT64 environment or
the host is doing 464XLAT.
3) the network provides NAT64.
The host knows if conditions #1 and #2 are met and signals it to the
network, so DHCP server responds 'OK, #3 is met as well'.

Now if we stop assuming IPv6 - even worse, if we stop assuming NAT64
being the only transition mechanism - we might end up in a following
situation:
[host] : dear network, IPv4 is optional for me  (because the host can
work in NAT64 environment)
[ the network] ah great, we've been trying to reduce IPv4 footprint so
we deployed IPv15 and the corresponding transition mechanisms, namely
NAT15-to-4, so I'm not going to give an address.

So the host is willing to make IPv4 optional *conditionally*  and
currently that condition is 'NAT64'. We either explicitly describe
that condition in the draft or - as it's been suggested in the thread
- we start encoding it in the option. So if the option value is '1' it
means 'IPv6-Only with NAT64', value 2 - some other 6-to-4 transition
technology we might invent tomorrow, and 3 - some shiny IPv4-to-IPv15
thingy.

> nothing of value as I see it.

I suspect it would complicate the configuration. Currently my lease
time is 30 mins. But I do not want IPv6-only capable clients to come
back so often, so I'd be probably setting V6ONLY_WAIT to a number of
hours. While IPv4 clients will continue to receive short lease time.

---

From: Jen Linkova <[email-masked]>
Date: Thu, 5 Dec 2019 18:08:23 +1100

On Thu, Dec 5, 2019 at 4:52 PM Fernando Gont <[email-masked]> wrote:
> off IPv4?" --

"Turn off IPv4 if $CONDITION is met". Currently $CONDITION is
hardcoded in the draft as 'NAT64'.
It is critical that both server and the client assume the same condition.

> If that's the semantics, then what triggered the use of

It is relevant. We do not want the host to send the option because it
supports NAT64 environment, while the server is responding with the
option because the administrator enabled IPX for that segment.

> local nodes that do not implement IPv6 (e.g., printers)?

Those nodes will continue receive IPv4 addresses.
If your question is 'how IPv6-only hosts on that segment would talk to
those IPv4-only devices' - well, they would not. If I need to migrate
a segment to IPv6-mostly mode I would not put any IPv4-only services
there which IPv6-only devices need to access.
Pls remember that the administrator needs to explicitly enable this
functionality for the network segment.

---

From: <[email-masked]>
Date: Thu, 5 Dec 2019 07:54:59 +0000

Hi Jen, 

Please see inline. 

Cheers,
Med

> De : Jen Linkova [mailto:[email-masked]]
> Envoyé : mercredi 4 décembre 2019 22:52
> À : BOUCADAIR Mohamed TGI/OLN
> Cc : Bjørn Mork; [email-masked]; V6 Ops List; draft-link-dhc-
> [email-masked]
> > Blindly releasing the IPv4 address when an IPv6 connectivity is available
> is problematic because the host does not know if a NAT64 function is
> available for a given network attachment. A host that discovers the
> presence of NAT64 (because a pref64 was discovered) can safely release any
> assigned IPv4 address. No additional signal is needed in such case.
> 

[Med] I think this design is suboptimal. 

Instead of requiring a PREFIX64 RA option (changes to hosts/routers) + DHCP option (changes to hosts/dhcp server) to solve your problem, you can achieve the same goal with one single DHCP option (PREF64) and without touching to the routers. 

> penalize v4-only and dual-stack networks) or do all those undesirable

[Med] The machinery will be almost the same as you are doing with your new option. You don't need to delay DHCPv4. The only difference is the signal on which to rely to make the decision.

NEW:
   The client MUST NOT configure the IPv4 address provided 
   in the DHCPOFFER if the client discovers a valid PREF64.

---

From: Lorenzo Colitti <[email-masked]>
Date: Thu, 5 Dec 2019 17:13:44 +0900

On Thu, Dec 5, 2019 at 4:55 PM <[email-masked]> wrote:

> [Med] The machinery will be almost the same as you are doing with your new
> option. You don't need to delay DHCPv4. The only difference is the signal
> on which to rely to make the decision.
>

I don't think that works. What is needed is a signal to the host that IPv4
should not be used if the host is capable of IPv6-only operation. That
signal *must* be available before DHCPv4 assigns an address to the
interface, because once an address is assigned, the host will not wait for
anything else and will allow apps using it immediately. This is by design;
it ensures that IPv4-only networks are as fast as they possibly can be.
Therefore, this signal cannot be in any IPv6 packet, including an RA, a RFC
7050 DNS reply, a PCP NAT64 option, or a DHCPv6 option.

---

From: Philip Homburg <[email-masked]>
Date: Thu, 05 Dec 2019 09:42:41 +0100

In your letter dated Thu, 5 Dec 2019 08:53:11 +1300 you wrote:
>As an ex-author of an ex-draft that suggested using IPv6 to tell hosts to avoi
>d IPv4, I'm curious to know whether a draft that suggests using IPv4 to tell h
>osts to prefer IPv6 will also be accused of being an operational nightmare.

I think this draft has different issues.

The good thing about this draft is that it doesn't affect legacy networks or
legacy hosts. It also doesn't affect any host that doesn't implement this
draft. 

The good thing about this mechanism is that it is the DHCP server that decides
what to do. Given that the DHCP servers hand out IPv4 addresses, we already
need to trust the DHCP server. So this draft clearly put functionality
where it belongs.

I'm not sure that it makes sense for an operator to implement this draft.

Though I have to admit, this draft could finally end the discusion on
whether the default SSID on a meeting network should be NAT64 or dual stack.
With this option it would be upto the host to pick the right way of doing
IPv4.

---

From: Philip Homburg <[email-masked]>
Date: Thu, 05 Dec 2019 09:49:24 +0100

>   networking if it doesn't find an IPv4 address on the system?

I agree with Lorenzo here. Changing a host to defer trying to get an IPv4
address while at the same time not showing any delay to the user when the
device connects to a new network would be an enormous amount of effort with
essentally no benefit to the vendor of the host device.

---

From: <[email-masked]>
Date: Thu, 5 Dec 2019 08:58:53 +0000

Lorenzo,

IMO, a host will need to “pause” the v4 configuration for xxx ms to make sure the configuration (v4/v6) is consistent.

Consider the example of an application that needs CLAT to work. Even if the DHCPv4 returns a signal that it is safe to release the IPv4 address, that application will need to wait for the PREF64 to work. The delay for that application will be the same.

Cheers,
Med

De : Lorenzo Colitti [mailto:[email-masked]]
Envoyé : jeudi 5 décembre 2019 09:14
À : BOUCADAIR Mohamed TGI/OLN
Cc : Jen Linkova; Bjørn Mork; [email-masked]; V6 Ops List; [email-masked]
Objet : Re: [dhcwg] IPv6-Only Preferred DHCPv4 option

I don't think that works. What is needed is a signal to the host that IPv4 should not be used if the host is capable of IPv6-only operation. That signal *must* be available before DHCPv4 assigns an address to the interface, because once an address is assigned, the host will not wait for anything else and will allow apps using it immediately. This is by design; it ensures that IPv4-only networks are as fast as they possibly can be. Therefore, this signal cannot be in any IPv6 packet, including an RA, a RFC 7050 DNS reply, a PCP NAT64 option, or a DHCPv6 option.

---

From: Bjørn Mork <[email-masked]>
Date: Thu, 05 Dec 2019 10:00:39 +0100

> network, so DHCP server responds 'OK, #3 is met as well'.

There is a fair amount of IoT devices requiring access to one specific
CDN hosted dual-stack service, and only that. These devices will always
work in an IPv6 only environment, even without NAT64, and they know it.

Not that these hosts ever will implement any new DHCP feature, but still..

Hosts considering NAT64 optional for IPv6-only operation will probably
become more and more common as "all" (most) services get dual-stack.  I
believe you are limiting the scope unnecessarily by requiring NAT64
here.

Bjørn

---

From: Lorenzo Colitti <[email-masked]>
Date: Thu, 5 Dec 2019 18:11:59 +0900

On Thu, Dec 5, 2019 at 5:58 PM <[email-masked]> wrote:

> IMO, a host will need to “pause” the v4 configuration for xxx ms to make
> sure the configuration (v4/v6) is consistent.
>

Hosts do not do this today, and I don't think they will start doing so. The
reason is that they cannot tell whether another protocol will start
working. If they wait xxx ms to make sure the other protocol comes up, they
are slowing down all connections to single-stack networks by xxx ms, making
their users unhappy.

Note that IPv6 has built-in delays in the protocol itself (DAD for the
link-local address; various randomized delays) that make it very difficult
to get anything done before at least 1-2 seconds have passed. Hosts that
know that 70% of networks are IPv4-only will not want to wait 1-2 seconds
to connect to those networks.

---

From: <[email-masked]>
Date: Thu, 5 Dec 2019 13:24:38 +0000

Re-,

Please see inline.

Cheers,
Med

Envoyé : jeudi 5 décembre 2019 10:12

On Thu, Dec 5, 2019 at 5:58 PM <[email-masked]<mailto:[email-masked]>> wrote:
IMO, a host will need to “pause” the v4 configuration for xxx ms to make sure the configuration (v4/v6) is consistent.

Hosts do not do this today, and I don't think they will start doing so. The reason is that they cannot tell whether another protocol will start working. If they wait xxx ms to make sure the other protocol comes up, they are slowing down all connections to single-stack networks by xxx ms, making their users unhappy.

[Med] Do you mean that clients that receive the signal to release IPv4 configuration will make the users unhappy anyway because they will need to wait for the pref64 to properly work?

Note that IPv6 has built-in delays in the protocol itself (DAD for the link-local address; various randomized delays) that make it very difficult to get anything done before at least 1-2 seconds have passed. Hosts that know that 70% of networks are IPv4-only will not want to wait 1-2 seconds to connect to those networks.

[Med] In that case, what is the benefit for the host to indicate its ipv6-only mode support?

---

From: Michael Richardson <[email-masked]>
Date: Thu, 05 Dec 2019 08:53:43 -0500

> same way on a dedicated IPv6-only segment and on IPv6-mostly segment.

I see the logic: that they shouldn't change.
I think that a lot of desktop OSes go for IPv4-LL when DHCPv4 fails because
their IPv4 logic was written before IPv6 was a thing.

I think that if I set up an IPv6-mostly segment it is because I know that
there are hosts which speak IPv4 only, or which have IPv4-only applications
which do not work through NAT64.  (An IPv4-only printer is such an "application")

I think that the DHCPv4 option is a clue that configuring IPv4-LL addresses
is a good thing.   Does Android configure IPv4-LL when it has IPv4?  I think
that this also varies by the host OS.

Having said this, I don't feel strongly about it either way.

---

From: Michael Richardson <[email-masked]>
Date: Thu, 05 Dec 2019 08:56:32 -0500

David Farmer <[email-masked]> wrote:
    Jen> Actually the more I think about it the more I believe the host
    Jen> should be doing whatever they are doing w/o DHCPv4 presence. Android
    Jen> does not configure IPv4 link-locals, MacOS does. Making the same OS
    Jen> behaving differently ("no DHCPv4 whatsoever" vs "DHCPv4 server
    Jen> responded with IPv6-only Preferred option") might be undesirable. As
    Jen> an operator I'd expect that IPv6-only capable host would behave the
    Jen> same way on a dedicated IPv6-only segment and on IPv6-mostly
    Jen> segment.

    > 2563 to determine if a host is to configure an IPv4-LL, and in that case, the
    > address returned should be 0.0.0.0.

I agree.
I didn't know that we had 2563 to turn off LL.
So hosts should do whatever they want, and if the operator does not want
v4LL, then they can turn this on.

    > Also, is there any reason that 0.0.0.0 shouldn't be the address retunded by a
    > server "if the IPv6-only Preferred option is present in the Parameter Request
    > List received from the client and the corresponding DHCP pool is explicitly
    > configured as belonging to an IPv6-mostly network segment" as discussed in
    > Section 3.3?

I think that we were concerned that stupid hosts might configure it by
mistake.

---

From: Lorenzo Colitti <[email-masked]>
Date: Thu, 5 Dec 2019 23:18:47 +0900

On Thu, Dec 5, 2019 at 10:24 PM <[email-masked]> wrote:

> Hosts do not do this today, and I don't think they will start doing so.
> The reason is that they cannot tell whether another protocol will start
> *[Med] *Do you mean that clients that receive the signal to release IPv4
> configuration will make the users unhappy anyway because they will need to
> wait for the pref64 to properly work?
>

Well, that's the intent of the pref64 RA option. That allows the pref64 to
be communicated in the same packet as the rest of the configuration
parameters.

> [Med] In that case, what is the benefit for the host to indicate its

The option improves the situation by allowing the host to wait for IPv6
only if it is expected to exist. Hosts that implement the option allow
networks to provide better service and create an incentive for networks to
support IPv6, which is good for everybody in the long term.

---

From: Lorenzo Colitti <[email-masked]>
Date: Thu, 5 Dec 2019 23:20:22 +0900

> that this also varies by the host OS.

Stock Android does not support IPv4-LL.

---

From: Lorenzo Colitti <[email-masked]>
Date: Thu, 5 Dec 2019 23:21:59 +0900

> v4LL, then they can turn this on.

Do any popular operating systems implement RFC 2563?

> I think that we were concerned that stupid hosts might configure it by

That, or that DHCP relays or snooping switches might get confused.

---

From: Ted Lemon <[email-masked]>
Date: Thu, 5 Dec 2019 06:39:18 -0800

On Dec 4, 2019, at 8:46 PM, Roy Marples <roy=[email-masked]> wrote:
> Given this information (in current DHCP semantics) we can RENEW (T1) or REBIND (T2).
> If the client does not request the offer (hey! I see this new fangled option here that says NO DHCP) the client can still accept the T2 timer at the very least.
> 
> Think of the analogus RFC 7083 - Modification to Default Values of SOL_MAX_RT and INF_MAX_RT. This RFC goes out of its way not to add new timers.

There is a reason why DHCP includes a parameter request list option.  If the client doesn’t ask for this newfangled option, it shouldn’t see it.  And so we can know for sure that the client supports this capability, because it asked for it.

Is there any reason why we /wouldn’t/ want to do this?

---

From: Roy Marples <[email-masked]>
Date: Thu, 5 Dec 2019 14:47:59 +0000

> Is there any reason why we /wouldn’t/ want to do this?

None at all.

I think it's a good option to have, but I strongly believe it should 
just be a boolean on/off option.

The host should be as dumb as possible.
If the server knows *something* else is around that it should use 
instead it can disable DHCP via this option.

The *something* else is probably IPv6 but I don't see why this RFC 
should mention it other than a use case.

Roy

---

From: Roy Marples <[email-masked]>
Date: Thu, 5 Dec 2019 15:00:53 +0000

On 05/12/2019 09:11, Lorenzo Colitti wrote:
> link-local address; various randomized delays) that make it very 
> difficult to get anything done before at least 1-2 seconds have passed. 
> Hosts that know that 70% of networks are IPv4-only will not want to wait 
> 1-2 seconds to connect to those networks.

IPv4 has built in delays as well. DHCP delay randomisation and DAD 
timings via RFC 5227.
NetBSD has RFC 5227 in the kernel and works very nicely.

I once saw a PDF that claimed Solaris does the same, although my hands 
on experience says if it does work it uses timings different from the RFC.

Roy

---

From: Lorenzo Colitti <[email-masked]>
Date: Fri, 6 Dec 2019 00:11:41 +0900

> NetBSD has RFC 5227 in the kernel and works very nicely.

True. Coincidentally, we've actually been finalizing an implementation
<https://android-review.googlesource.com/c/platform/packages/modules/NetworkStack/+/1095791>
in
the last few weeks. The current client just sends a DISCOVER as soon as it
possibly can and takes the first offer it gets.

> on experience says if it does work it uses timings different from the RFC.

IIRC we found the RFC timings to be way too long for mobile devices that
move between networks often, so we lowered them.

---

From: Roy Marples <[email-masked]>
Date: Thu, 5 Dec 2019 15:13:33 +0000

On 05/12/2019 15:11, Lorenzo Colitti wrote:
> On Fri, Dec 6, 2019 at 12:01 AM Roy Marples 
> <roy=[email-masked] 
> <mailto:[email-masked]>> wrote:
> 
>     IPv4 has built in delays as well.. DHCP delay randomisation and DAD
>     timings via RFC 5227.
> <https://android-review.googlesource.com/c/platform/packages/modules/NetworkStack/+/1095791> in 
> the last few weeks. The current client just sends a DISCOVER as soon as 
> it possibly can and takes the first offer it gets.
> 

I would be supportive of an RFC to bring the timings/number of probes in 
line with IPv6 DAD as well.

Roy

---

From: Simon Hobson <[email-masked]>
Date: Thu, 5 Dec 2019 16:16:50 +0000

Another typo, I think. Top of page 2 it says :
"Therefore it would be beneficial for IPv6 deployment if operators could implement IPv4-mostly (or IPv4-as-a-Service) segments ..."
Should that be IPv6-mostly ?

Roy Marples <roy=[email-masked]> wrote:

> It assumes that IPv6 is the be-all and end-all.

It is, for all practical purposes.

> Maybe one day we will have IPv8?

Many people said "why go to so many bits for IPv6 addresses ?". The answer being (partly) so that the need for another mass migration should be a long long looooong time away - most likely long after all of us are no longer interested, and IPv4 is as common as AppleTalk, IPX, DECNet, etc !

> Mark Smith <[email-masked]> wrote:

> So I haven't read the draft either, although the following applied in the context of the the IPv6-only flag draft and I think this one.
> 

Just think about it.
An application starts, and wants to know what protocols it can use - it can't unless something else has forced addresses to be assigned.
Or it needs to know what addresses are available (perhaps it's configured to use only certain addresses) - it can't unless something has forced them to be assigned.
The host (or administrator of it) may wish to apply firewall rules - bit tricky if there's no protocols active !

When starting an application, the user would have a further delay while an address was obtained and configured. And what address family would the system configure ? Would it do the initial DNS request to the IPv4 server it gets from the DHCP4 server ? Or would it send it to the IPv6 server it gets from RAs ? Would it wait for "long enough" to know what address families are available, or just use the first that came up ?

What about Bonjour/mDNS/Zeroconf ? Would you suppress them until needed ? How would another device connect to a service offered on this host if you suppressed configuring interface(s) and sending mDNS advertisements until something local needed it ?

In reality, most systems (as a whole, taking into account everything running on them) are so chatty that the host would be forced to obtain and configure addresses of all families on all interfaces pretty well as soon as it's started up.

Simon

---

From: Jen Linkova <[email-masked]>
Date: Fri, 6 Dec 2019 09:26:07 +1100

> I think this draft has different issues.

The authors would be happy to work on getting them fixed if you could
elaborate on what those issues are ;)

> I'm not sure that it makes sense for an operator to implement this draft.

I'm an operator who could not wait to implement that draft (and I'm
aware of at least one other operator who might be interested).
Maybe I'm not creative enough but all other options of incremental
deployment of IPv6-only I've come up with are much more ugly
(doubling the number of SSIDs/VLANs or having a portal when users have to
request IPv4 so their MACs are whitelisted etc).

> With this option it would be upto the host to pick the right way of doing

Exactly! Wouldn't it be awesome? ;)

---

From: Jen Linkova <[email-masked]>
Date: Fri, 6 Dec 2019 11:00:37 +1100

> believe you are limiting the scope unnecessarily by requiring NAT64

You are right indeed. Strictly speaking what the option signals is
'all destinations the host might want to connect to are reachable over
IPv6 - either natively or by some transition mechanism deployed in the
network'. Indeed *some* devices might not need NAT64 even now if all
destinations they ever need access are IPv6-enabled. Maybe one day,
when 99.999% of traffic becomes IPv6 we might not need NAT64.
However practically speaking...While a device *might* be sure that it
does not even need NAT64 and can operate on pure IPv6-only, I do not
believe it's a realistic or practical to expect that a network
operator would mark the given segment as 'IPv4-as-a-Service' w/o
deploying NAT64.
While writing the text I did think about corner cases 'all
destinations the network provides an access to are Ipv6-enabled so
NAT64 is not needed' but they are a corner cases and trying to capture
them in the draft might do more harm than good...

What we might do is to clarify the definition of an IPv6-only capable
host and say that a host MAY be considered an IPv6-only capable if
it's guaranteed somehow that all destinations the host ever is going
to reach are IPv6-enabled - but I'm not really sure it's a good idea..

---

From: Jen Linkova <[email-masked]>
Date: Fri, 6 Dec 2019 11:05:39 +1100

> Should that be IPv6-mostly ?

Oh indeed, thanks for pointing this out. I seem to constantly mistake
IPv4 for IPv6 and vice versa in the draft ;))
Will fix in -01.

---

From: Lorenzo Colitti <[email-masked]>
Date: Fri, 6 Dec 2019 09:41:29 +0900

> should mention it other than a use case.

There is actually a reason why the option is specific to IPv6. Here's why.
The primary reason for the existence of option is that hosts (especially
moblie hosts) don't want to wait to find out what's available before they
make networking available to applications. This is why when they connect
they initiate IPv4 and IPv6 (and whatever else they have) in parallel. The
option as written conveys two important bits of information to the host:

   1. The network would prefer the host not use IPv4 if the host has
   something else available.
   2. Something else *is available* on this network, so the host is not
   going to wait forever for it.

In the current draft, "something else" is specifically IPv6 (because not
really any other credible alternative to IPv4) and more specifically, IPv6
with NAT64 (because there is no other IPv6 transition mechanism that is
widely implemented in hosts today - all the others are implemented in the
network).

I think you're saying that this option should mean "I'd prefer you not use
IPv4 except as a last resort" option, as opposed to "I'd prefer you use
IPv6 instead". What that means is that the option will only be providing #1
and not #2. I think it's worse that what we are currently proposing. The
reasons are:

   1. If we make this an "IPv4 as last resort" option, a client that gets
   the option is not being told if there is anything else available. So, say
   that the administrator sets this option because they want hosts to prefer
   IPX (or netbeui, or appletalk, or whatever) over IPv4. What if the host
   doesn't support/use any of those protocols, but only supports IPv6, which
   is the overwhelmingly common case today? The host doesn't really have a
   clear path forward. The only thing it can do is try IPv6 "for a while", and
   then go back to DHCPREQUEST (assuming the offer is still valid, and if not
   go back to DHCPDISCOVER), and use IPv4 anyway. That seems like a bad user
   experience.
   2. If we make this an "IPv4 as a last resort option" instead of a
   "please use IPv6" option, is that hosts will simply assume that the option
   means "please use IPv6". Even though this assumption is technically
   incorrect, if enough hosts do it, from a deployment perspective it won't
   matter, because network operators won't be able to use this option code for
   anything other than IPv6-only networks. That outcome is worse than if we
   had explicitly defined this as a "please use IPv6" option, because
   well-behaved hosts will have to incur the additional complexity to build
   the technically correct implementation that can never be used in practice.

If we really don't want to make this option specific to IPv6, then we can
define an option that can convey multiple alternatives. In other words, the
option would mean "please don't use IPv4 if you support any of the
alternative protocols listed in this option". We could initially define an
alternative code only for "IPv6-only with NAT64", but if later some other
protocol comes along, or some other IPv6 transition mechanism becomes
widely deployed on hosts, we could add a code for it. Personally I don't
think this is worth the engineering complexity because I don't see any
other credible alternative than IPv6-only with NAT64, but I would much
prefer it over an option that doesn't say anything at all about what else
is available.

---

From: Mark Smith <[email-masked]>
Date: Fri, 6 Dec 2019 11:58:36 +1100

On Thu, 5 Dec 2019 at 13:20, Lorenzo Colitti <[email-masked]> wrote:
>> If hosts only acquired IPv4 addresses via DHCPv4 based on when the first IPv4 application started running, then when a host is only running IPv6 only applications, it would never acquire an IPv4 address because it wouldn't need one, meaning never try to use DHCPv4 (so would avoid the link-layer broadcast DHCP_DISCOVERS) and never use ARP (avoid link-layer broadcast ARP Requests).
>
>
> Speaking as an OS implementer: how do I know whether an application is an IPv4 application?
>

So these are reasonable questions, and they're uncovering some
assumptions and a view point I have:

- the hosts in question are commonly single homed (and I should know
better *, however I would't be surprised if that is the unstated
assumption of most people when they imagine the scenario being
discussed)

- the on-demand I'm imagining is inspired by the dial-on-demand that
used to be implemented with ISDN, triggered by IP traffic. ISDN
connection establishment happened quickly enough that it was tolerable
by end-users. If a DHCPv4 transaction occurred within 100 ms, users
will perceive it as instant - "Response Times: The 3 Important Limits"
- https://www.nngroup.com/articles/response-times-3-important-limits/

- IPv6 only applications clearly indicate they're IPv6 only, by only
opening IPv6 sockets.

This latter point is probably a significant difference between what is
being proposed here and what I'm thinking. My thinking is probably
about a passive and longer term mechanism that would result in IPv4
disappearing over time, rather than an active mechanism that purposely
switches IPv4 off on dual stack hosts.

Responding to these points for completeness:

> When it calls getaddrinfo() with AF_UNSPEC? Pretty much all apps do that.

They wouldn't be IPv6 Only applications.

> When it creates an IPv4 socket? But what if it's creating an IPv4 socket for the purpose of connecting to another network on the system (e.g., cellular data) that does have IPv4?

Yes, this would be an issue with what I was describing.

What I'm thinking about would probably more result in "IPv6 Only"
being a host level status on a host, covering all interfaces (1 or
many), rather than an interface status. In other words, if a host is
only currently running IPv6 Only applications, then there is no need
for any IPv4 addresses on any of its interfaces.

> When it does a connect() on an IPv4 socket? But what if that's just a happy eyeballs stack that is using IPv4 because it might be available?

As above, not an IPv6 Only application if trying to use HE.

> What if the app knows it needs IPv4 and will refuse to do any networking if it doesn't find an IPv4 address on the system?

Not an IPv6 Only application.

I see value in both applications being explicit about what Internet
Protocol they want to use (e.g. on demand addressing per above), and
also being agnostic about it.

Regards,
Mark.

(* "The Rapid Rise of the Mobile Multi-Homed Host" -
https://www.ausnog.net/sites/default/files/ausnog-2013/presentations/D01%20P06-the%20rapid%20rise%20of%20the%20mobile%20multihomed%20host.pdf)

---

From: Ted Lemon <[email-masked]>
Date: Thu, 5 Dec 2019 17:50:06 -0800

What’s an ipv6-only application?  Normally I would expect an application to be stack-neutral. 

> On Dec 5, 2019, at 16:59, Mark Smith <[email-masked]> wrote:
>

---

From: Mark Smith <[email-masked]>
Date: Fri, 6 Dec 2019 12:57:48 +1100

>From RFC 3493:

For example, to create an IPv6/TCP socket, applications make the
   call:

      s = socket(AF_INET6, SOCK_STREAM, 0);

   To create an IPv6/UDP socket, applications make the call:

      s = socket(AF_INET6, SOCK_DGRAM, 0);

For example, this application only listens on IPv4 or IPv6, but never both:

https://github.com/markzzzsmith/replicast

Regards,
Mark.

---

From: Ted Lemon <[email-masked]>
Date: Thu, 5 Dec 2019 18:37:33 -0800

That wasn’t my question. I know how to write one. Can you give me an example of one in the wild?  It has to be something that gets serious use. 

> On Dec 5, 2019, at 17:58, Mark Smith <[email-masked]> wrote:
>

---

From: Mark Smith <[email-masked]>
Date: Fri, 6 Dec 2019 14:24:47 +1100

On Fri, 6 Dec 2019, 13:37 Ted Lemon, <[email-masked]> wrote:

> That wasn’t my question. I know how to write one. Can you give me an
> example of one in the wild?  It has to be something that gets serious use.
>

I'm not sure what the point of your question is.

I mentioned my thinking is probably more future and long term because
applications would need to be explicitly IPv6 only. I understand that's not
going to be many today.

The trouble with dual stack applications is that they aren't explicitly
saying whether they want or expect IPv4, IPv6 or both from the network.

Since what the applications want from the network is ambiguous, it's hard
to know if an application would be happy with an IPv6 only network
connection.

Taking IPv4 away from these ambiguous applications always creates a risk of
breaking them.

An application that explicitly said "I only want IPv6" doesn't have that
risk.

> >>>>> If hosts only acquired IPv4 addresses via DHCPv4 based on when the
> first IPv4 application started running, then when a host is only running
> IPv6 only applications, it would never acquire an IPv4 address because it
> >>>> When it creates an IPv4 socket? But what if it's creating an IPv4
> >>>> When it does a connect() on an IPv4 socket? But what if that's just a
> >>>> What if the app knows it needs IPv4 and will refuse to do any

---

From: Jen Linkova <[email-masked]>
Date: Fri, 6 Dec 2019 18:14:34 +1100

On Thu, Dec 5, 2019 at 12:09 PM David Farmer <[email-masked]> wrote:
> If that is really the case then I think some discussion on selecting the address returned is probably needed in the draft.

The draft currently suggests that the server is configured with a
dedicated IPv4 address per pool for this purpose:

"If the pool is explicitly configured with a dedicated IPv4
   address to be returned to IPv6-only capable clients the server MUST
   specify that address as the client's network address and MUST NOT
   verify its uniqueness.  Otherwise the server SHOULD follow the
   recommendations in [RFC2131].  The client is not expected to use that
   IPv4 address so if the client responds with the DHCPREQUEST message
   for that address the server SHOULD respond with DHCPNAK.
"

If there is no dedicated address, I guess it does not really matter
what address from the pool is returned.
Or am I missing anything?

---

From: Lorenzo Colitti <[email-masked]>
Date: Fri, 6 Dec 2019 16:21:19 +0900

On Fri, Dec 6, 2019 at 4:14 PM Jen Linkova <[email-masked]> wrote:

>    verify its uniqueness.

That seems difficult to implement on the server. Why not just return a
normal OFFER from the pool? That way, if something unexpected happens and
the client sends a DHCPREQUEST for it, the server can hand it out as normal.

The alternative is risky. If the server uses a bogus OFFER value, and some
client requests it and the server hands it out, that creates the
possibility for misconfiguration or bugs to create really bad outcomes
where multiple hosts have the same IP address, or some things on the
network (e.g., snooping switches) think that multiple hosts have the same
IP address. +Tomek Mrugalski <[email-masked]> any thoughts on
whether this can be implemented easily and reliably on the server side?

---

From: <[email-masked]>
Date: Fri, 6 Dec 2019 08:01:08 +0000

Hi Lorenzo,

Please see inline.

Cheers,
Med

Envoyé : jeudi 5 décembre 2019 15:19

On Thu, Dec 5, 2019 at 10:24 PM <[email-masked]<mailto:[email-masked]>> wrote:
Hosts do not do this today, and I don't think they will start doing so. The reason is that they cannot tell whether another protocol will start working. If they wait xxx ms to make sure the other protocol comes up, they are slowing down all connections to single-stack networks by xxx ms, making their users unhappy.

Well, that's the intent of the pref64 RA option. That allows the pref64 to be communicated in the same packet as the rest of the configuration parameters.
[Med] If there is no delay then, the signals (pref64 presence, v6-only presence) are redundant. No?

The option improves the situation by allowing the host to wait for IPv6 only if it is expected to exist.
[Med] The host can “wait” without requiring the option. The key point is that an administrator sets “ipv6-mode” supported.

Hosts that implement the option allow networks to provide better service and create an incentive for networks to support IPv6
[Med] I’m not sure about this benefit for the NAT64 case as many features depends on the discovery of the prefix64.

That’s said, I do see a possible value for the network side but for other IPv6-only deployments:

·         CPE in DS-Lite mode

·         CPE in A+P mode

If ds-lite (or a+p) mode is explicitly enabled (managed CPE), DHCPv4 won’t be issued. In addition, if the CPE is ds-lite and a+p compliant, then RFC8026 will be used. No need for additional signal.

Now, if the CPE is ds-lite/a+p capable (non-managed CPE) but does not know if the network is ds-lite/a+p capable, the CPE will issue both DHCPv4 and DHCPv6 requests. If no “checks” are implemented at the DHCPv4 server side, the CPE may be assigned an IPv4 address in addition to receiving OPTION_AFTR_NAME. The CPE will need to release the IPv4 address.

With your option, the situation will be much more simple and the server will be returning an address in 192.0.0.0/29 (RFC6333, Section 5.7).

Cheers,
Med

---

From: Philip Homburg <[email-masked]>
Date: Fri, 06 Dec 2019 11:04:07 +0100

>request IPv4 so their MACs are whitelisted etc).

Can you describe why offering both NAT64 and native IPv4 on the same lan
doesn't work?

Note that I don't have a strong opinion on what would be enough demand from
operators. It seems to me that running both dual stack and NAT64 on the same
network is bad from an operational point of view. But if people want to do
it anyway, then it is fine with me.

One thing that worries me a bit is that with this option the host signals that
it doesn't need an IPv4 address if there is NAT64.

There are two things that can go wrong: the network provides the NAT64 
transation prefix in a way that the host doesn't understand. 

The second thing, what if some other IPv4aaS technology becomes popular,
do we need a new option for every IPv4aaS technology?

---

From: Philip Homburg <[email-masked]>
Date: Fri, 06 Dec 2019 11:10:42 +0100

>       s = socket(AF_INET6, SOCK_STREAM, 0);

Technically that does not create an IPv6/TCP socket.

See Section 3.7, in RFC 3493.

---

From: Lorenzo Colitti <[email-masked]>
Date: Fri, 6 Dec 2019 19:37:16 +0900

> Can you describe why offering both NAT64 and native IPv4 on the same lan

It uses lots of IPv4 addresses. Additionally, many hosts prefer native IPv4
over IPv6+NAT64, so they will keep DHCP running even if they get IPv6 with
NAT64. Even if the hosts changed this behaviour, hosts typically start IPv4
immediately when they connect. Because IPv6 provisioning is often slower
than IPv4, the host will get an IPv4 address first. And once it gets an
IPv4 address it generally doesn't want to release it later because doing so
could disrupt application sockets.

---

From: Lorenzo Colitti <[email-masked]>
Date: Fri, 6 Dec 2019 19:43:38 +0900

> presence) are redundant. No?

The pref64 option doesn't guarantee the absence of a delay. This DHCP
option tell hosts: this network can provide IPv6-only service with NAT, and
would prefer that hosts use it over IPv4. That gives the host a reason to
wait before it configures IPv4, or not to configure IPv4 at all, because it
knows that (unless there is an outage or misconfiguration), native IPv6
with NAT64 will arrive very soon. The pref64 option is there to ensure that
NAT64 arrives as soon as possible and doesn't require roundtrips to the DNS
forwarders (or even to the root and then to the IANA servers).

> only if it is expected to exist.
>
> [Med] The host can “wait” without requiring the option. The key point is
> that an administrator sets “ipv6-mode” supported.
>

Which administrator? If you mean the host administrator: only very few
hosts have administrators that understand networking. Most hosts don't. And
it's silly to wait unconditionally if the host doesn't know if the network
provides IPv6-only service. Almost all networks (except for cellular
networks, which don't use DHCP) don't provide such a service today, and it
doesn't make sense to wait unconditionally on all networks just because a
very few networks support IPv6-only.

---

From: <[email-masked]>
Date: Fri, 6 Dec 2019 12:25:41 +0000

Re-,

Please see inline.

Cheers,
Med

Envoyé : vendredi 6 décembre 2019 11:44

On Fri, Dec 6, 2019 at 5:01 PM <[email-masked]<mailto:[email-masked]>> wrote:
[Med] Do you mean that clients that receive the signal to release IPv4 configuration will make the users unhappy anyway because they will need to wait for the pref64 to properly work?

The pref64 option doesn't guarantee the absence of a delay. This DHCP option tell hosts: this network can provide IPv6-only service with NAT, and would prefer that hosts use it over IPv4.
[Med] Assuming the host is modified to behave in this mode.

That gives the host a reason to wait before it configures IPv4, or not to configure IPv4 at all, because it knows that (unless there is an outage or misconfiguration), native IPv6 with NAT64 will arrive very soon.
[Med] Still it will wait in that case.

The pref64 option is there to ensure that NAT64 arrives as soon as possible and doesn't require roundtrips to the DNS forwarders (or even to the root and then to the IANA servers).
[Med] Yes. My point is that this information is explicit enough that a NAT64 service is available and that only the IPv6 prefix should be configured.

A host that is not supporting this mode won’t wait and will retrieve both ipv4/IPv6 configuration (if available).

Which administrator?
[Med] The one you have in the draft:

                              ^^^^^^^^^^^^^^^^^^^^^^

Perhaps, I misunderstood the intent of the draft. If you are referring to the network administrator that is able to touch that parameter on hosts on the LAN, that administrator can also disable dhcpv4 for IPv6-capable devices (on specific interfaces/networks). We don’t have a problem them.

Otherwise, I don’t see how a device can set automatically “IPv6-only preferred mode”. Do you?

---

From: Gert Doering <[email-masked]>
Date: Fri, 6 Dec 2019 13:39:36 +0100

Hi,

> Can you describe why offering both NAT64 and native IPv4 on the same lan

"number of IPv4 addresses in the pool" comes to mind.

Like, 80% of all hosts are fine with IPv6+NAT64, so why provision a large
enough subnet to cover 100% of all expected hosts if 20% will do?

IPv4 seems to be somewhat in short supply these days.

Gert Doering
        -- NetMaster
-- 
have you enabled IPv6 on something today...?

SpaceNet AG                      Vorstand: Sebastian v. Bomhard, Michael Emmer
Joseph-Dollinger-Bogen 14        Aufsichtsratsvors.: A. Grundner-Culemann
D-80807 Muenchen                 HRB: 136055 (AG Muenchen)
Tel: +49 (0)89/32356-444         USt-IdNr.: DE813185279

---

From: Philip Homburg <[email-masked]>
Date: Fri, 06 Dec 2019 15:10:23 +0100

>IPv4 seems to be somewhat in short supply these days.

With a few exceptions, just about any DHCP pool I come across these 
days is using RFC 1918.

Are you running out of RFC 1918 addresses in your pool? Or is the setup
that you give publicly routable IPv4 addresses to all dual stack hosts
and want to only put hosts that support NAT64 behind NAT?

In that case, what's the rational for providing dual stack hosts with public
IPv4 addresses?

---

From: Ted Lemon <[email-masked]>
Date: Fri, 6 Dec 2019 06:30:56 -0800

I really feel like there is some point-missing going on here. It is trivial to make this feature only activate for clients that support it. If that is done, then there is no reason to assign an address at all. The offer doesn’t even need to include that option. So any discussion of what address to send is irrelevant and unnecessary. 

> On Dec 6, 2019, at 06:10, Philip Homburg <[email-masked]> wrote:
> 
> 
>>

---

From: Gert Doering <[email-masked]>
Date: Fri, 6 Dec 2019 15:38:31 +0100

Hi,

> With a few exceptions, just about any DHCP pool I come across these 

What a horrible way!  Forcing your users behind a NAT!

> In that case, what's the rational for providing dual stack hosts with public

What's the rationale for forcing NAT44 on your users?

(Speaking of a certain dual-stack ssid, why are we offering public v4 
there?)

Gert Doering
        -- NetMaster

---

From: "Bernie Volz (volz)" <[email-masked]>
Date: Fri, 6 Dec 2019 14:45:28 +0000

Even if an "assigned" address is sent (which requires fewer changes on the DHCP server implementation), it should only be "associated" with that client for a very short duration (the server I work on limits it to 2 minutes by default and this is not saved to persistent storage). A DHCPACK is what confirms the lease for the returned lease-time and this is never sent (as the client will not send a DHCPREQUEST per the draft).

Existing servers can deploy this without ANY changes (provided you have a means to configure the server with whatever option number is finally assigned).

Personally, I would NOT recommend breaking the semantics of a DHCPOFFER and always include an address because you never know how intermediate devices that may be "snooping" this traffic will handle this; for example, the intermediate device might drop what it feels is an invalid packet.

One change to the server may be to simply not even temporarily associate the 'assigned' address with the client (since the client is not expected to send a DHCPREQUEST). But, again, I doubt this would be necessary.

Even in cases where there are minimal addresses available with a lot of clients coming online at once, the DHCP server would drop DHCPDISCOVERs that it has no available lease for. Thus, the client will just retry for a bit until an address becomes available. But other than generating the excess traffic, the end result is the same eventually - the client will stop DHCP.

This is one nice aspect of this design - there are minimal changes needed to deploy it at servers (and in fact, most servers may need no changes).

- Bernie

-----Original Message-----
From: v6ops <[email-masked]> On Behalf Of Ted Lemon
Sent: Friday, December 6, 2019 9:31 AM
To: Philip Homburg <[email-masked]>
Cc: [email-masked]
Subject: Re: [v6ops] IPv6-Only Preferred DHCPv4 option

>> Like, 80% of all hosts are fine with IPv6+NAT64, so why provision a 
>> large enough subnet to cover 100% of all expected hosts if 20% will do?
>> 
> Are you running out of RFC 1918 addresses in your pool? Or is the 
> setup that you give publicly routable IPv4 addresses to all dual stack 
> hosts and want to only put hosts that support NAT64 behind NAT?
>

---

From: "Bernie Volz (volz)" <[email-masked]>
Date: Fri, 6 Dec 2019 14:51:23 +0000

> There is a reason why DHCP includes a parameter request list option.  If the client doesn’t ask for this newfangled option, it shouldn’t see it.  And so we can know for sure that the client support…

Even if a DHCP server sent the option without it being requested, why would the client use it if it didn't ask for it?

- Bernie

---

From: Philip Homburg <[email-masked]>
Date: Fri, 06 Dec 2019 15:57:30 +0100

>What a horrible way!  Forcing your users behind a NAT!

It's a legacy protocol. If users want a routable address, they can use
IPv6. This is only for connecting to less advanced parts of the internet.

(I have to admit there does also seem to be a lot of NAT without IPv6)

>What's the rationale for forcing NAT44 on your users?

I think you provided the rational earlier: running out of IPv4 addresses.

In any case, NAT64 is also NAT. For users, there is not a big difference 
between NAT44 and NAT64. In my opinion, NAT44 is better than NAT64, but the
difference is not big.

>(Speaking of a certain dual-stack ssid, why are we offering public v4

Possibly because there is no other use for those addresses :-)

---

From: "Bernie Volz (volz)" <[email-masked]>
Date: Fri, 6 Dec 2019 14:59:28 +0000

I agree with Lorenzo. Keep it simple (see previous email that there really should be no work on the DHCP servers to support this capability).

Yes, you could reserve an address, but I don’t see that as required. Note that I had suggested this to the authors before the draft was published as an optimization; I don’t think it should be the norm. And with many servers, you could probably just do this via configuration (i.e., if PRL contains “IPv6-Only” option, override the client identity with a fixed unique name, add a fixed address / reservation for that unique name).

  *   Bernie

From: v6ops <[email-masked]> On Behalf Of Lorenzo Colitti
Sent: Friday, December 6, 2019 2:21 AM
To: Jen Linkova <[email-masked]>; Tomek Mrugalski <[email-masked]>
Cc: V6 Ops List <[email-masked]>; [email-masked]; [email-masked]; Michael Richardson <[email-masked]>
Subject: Re: [v6ops] [dhcwg] IPv6-Only Preferred DHCPv4 option

On Fri, Dec 6, 2019 at 4:14 PM Jen Linkova <[email-masked]<mailto:[email-masked]>> wrote:
"If the pool is explicitly configured with a dedicated IPv4
   address to be returned to IPv6-only capable clients the server MUST
   specify that address as the client's network address and MUST NOT
   verify its uniqueness.

That seems difficult to implement on the server. Why not just return a normal OFFER from the pool? That way, if something unexpected happens and the client sends a DHCPREQUEST for it, the server can hand it out as normal.

The alternative is risky. If the server uses a bogus OFFER value, and some client requests it and the server hands it out, that creates the possibility for misconfiguration or bugs to create really bad outcomes where multiple hosts have the same IP address, or some things on the network (e.g., snooping switches) think that multiple hosts have the same IP address. +Tomek Mrugalski<mailto:[email-masked]> any thoughts on whether this can be implemented easily and reliably on the server side?

---

From: Michael Richardson <[email-masked]>
Date: Fri, 06 Dec 2019 10:25:40 -0500

> for that address the server SHOULD respond with DHCPNAK.

This is why this document belongs in DHC, because this is new server logic :-)
I think that maybe we are trying to be too cute here.

The goal is not to assign an address, but ciaddr is a fixed field, so we have
to put something in, and I think that we are worried that 0.0.0.0 is going to
confuse DHCP relay nodes that snoop.

At this point, Jen is trying to give the DHCP administrator some rope with
which to work around confusing the snoop node by creating a pool of one
address.

Maybe we can return 225.0.0.1.

---

From: "Bernie Volz (volz)" <[email-masked]>
Date: Fri, 6 Dec 2019 15:59:51 +0000

I would keep it simple and not change the server's processing with respect to the a (temporarily) assigned address in the DHCPOFFER.

See my other email on the topic (https://mailarchive.ietf.org/arch/msg/dhcwg/T_5gklM3klgjHeMOlOhEF4e-IWI).

- Bernie

-----Original Message-----
From: v6ops <[email-masked]> On Behalf Of Michael Richardson
Sent: Friday, December 6, 2019 10:26 AM
To: Jen Linkova <[email-masked]>
Cc: V6 Ops List <[email-masked]>; [email-masked]; [email-masked]
Subject: Re: [v6ops] [dhcwg] IPv6-Only Preferred DHCPv4 option

    > for that address the server SHOULD respond with DHCPNAK.

This is why this document belongs in DHC, because this is new server logic :-) I think that maybe we are trying to be too cute here.

The goal is not to assign an address, but ciaddr is a fixed field, so we have to put something in, and I think that we are worried that 0.0.0.0 is going to confuse DHCP relay nodes that snoop.

At this point, Jen is trying to give the DHCP administrator some rope with which to work around confusing the snoop node by creating a pool of one address.

--
Michael Richardson <[email-masked]>, Sandelman Software Works  -= IPv6 IoT consulting =-

---

From: Ted Lemon <[email-masked]>
Date: Fri, 6 Dec 2019 08:02:02 -0800

On Dec 6, 2019, at 6:45 AM, Bernie Volz (volz) <[email-masked]> wrote:
> which requires fewer changes on the DHCP server implementation

This is almost certainly not true.  In order for this to work, you’re going to have to have some special-purpose code to support it.  Better to do the clean solution than a hack that minimizes changes to the server at the expense of more complication in the client-server interaction.

> Existing servers can deploy this without ANY changes (provided you have a means to configure the server with whatever option number is finally assigned).

I think it’s okay to require changes to the server.   This is a significant new feature.

> Personally, I would NOT recommend breaking the semantics of a DHCPOFFER and always include an address because you never know how intermediate devices that may be "snooping" this traffic will handle…

This is definitely not an issue, though, because the network operator is choosing to deploy this.  They can be responsible for ensuring correct behavior if there are any middleboxes intercepting the DHCPv4 traffic and doing stuff with it.   Expecting this to Just Work with no infrastructure changes seems unnecessary.

> Even if a DHCP server sent the option without it being requested, why would the client use it if it didn't ask for it?

If the DHCP server knows the client supports the feature, it can assume that when it sends the option, the client will implement the specified behavior.   If it doesn’t know for sure that the client supports the feature, then you have to deal with a much more complex set of possible behaviors.   Why add that complexity?

And that’s assuming that the client behaves correctly.  If you just send the new option, another possibility is that the client crashes when it doesn’t recognize the option, as we used to see with certain printers I the manufacturer of which I will not mention.   Or that it does some other random thing.  Why chance it?

---

From: Ted Lemon <[email-masked]>
Date: Fri, 6 Dec 2019 08:02:35 -0800

> confuse DHCP relay nodes that snoop.

ciaddr is 0.0.0.0 in a DHCPOFFER, right?

---

From: "Bernie Volz (volz)" <[email-masked]>
Date: Fri, 6 Dec 2019 16:18:28 +0000

Comments inline below (BV>).

  *   Bernie

From: Ted Lemon <[email-masked]>
Date: Friday, December 6, 2019 at 11:02 AM
To: Bernie Volz <[email-masked]>
Cc: Philip Homburg <[email-masked]>, "[email-masked]" <[email-masked]>, "[email-masked]" <[email-masked]>
Subject: Re: [v6ops] IPv6-Only Preferred DHCPv4 option

On Dec 6, 2019, at 6:45 AM, Bernie Volz (volz) <[email-masked]<mailto:[email-masked]>> wrote:
which requires fewer changes on the DHCP server implementation

BV> Why are any changes needed to the server? It’s normal processing will work just fine … if the network segment has the new option configured, it will return it if the client requests it. Then the server will never see the DHCPREQUEST and the address assigned to the client will just “timeout” in a short period (at least on our server, within 2 minutes or whatever an administrator has configured) and be usable by other clients. End of story as client has turned off DHCPv4 and everyone is happy. And, no changes to anything on the server. This is not different than a case where there the client never sends a DHCPREQUEST or selects a DHCPREQUEST from a different server.

BV> If the client does proceed to a DHCPREQUEST, normal processing would happen, and client would get the lease (or perhaps receive a DHCPNAK is some other device was assigned the lease because the short time it had been held expired).

BV> This is all normal DHCPv4 processing and so no changes are needed.

BV> Why there is no need? Yes, you could do optimizations to (1) have perhaps a much shorter temporary assignment time or (2) use a “reserved” address for clients that request this option in the PRL. But these are not necessary, and everything works just fine without the changes.

BV> Why need this testing to confirm that middleboxes aren’t doing bad stuff. If you stick to normal DHCP semantics, nothing needs to be tested or changed in your infrastructure. Yes, I am expecting this to work with no infrastructure changes as this is STANDARD DHCP. The DHCPOFFER just never turns in to a DHCPREQUEST – so what … this can happen today on all DHCP networks if the client stops (powered down, disconnects from network).

BV> If a DHCP client crashes when it receives an unknown option, my guess is that it would be quickly fixed as this just is broken behavior. Again, I’m not saying that a server should send this option if it wasn’t requested by a client, but I’m just clarifying your statements that even if a client were to see some arbitrary option that it didn’t request, it shouldn’t be doing anything with it. And, I would suspect that you would be hard pressed to find a client that crashes when it receives an unknown option.

BV> I will say that one issue that could exist with this option that is a bit unusual is that it is currently 0-length. We have only one other zero-length option that I recall, and that is Rapid Commit (which is client to server, not server to client). So, it is possible that there are clients that are unhappy about zero-length options. But again, in the ideal world no client will see this option unless it has requested it (in the PRL).

---

From: Lorenzo Colitti <[email-masked]>
Date: Sat, 7 Dec 2019 01:35:30 +0900

On Sat, Dec 7, 2019 at 1:02 AM Ted Lemon <[email-masked]> wrote:

> This is almost certainly not true.  In order for this to work, you’re
> going to have to have some special-purpose code to support it.  Better to
> do the clean solution than a hack that minimizes changes to the server at
> the expense of more complication in the client-server interaction.
>

I don't think this option requires any server changes other than the code
to parse and serialize the option. That the server doesn't even need to
know or care whether the client supports the option or not. At worst, it
can simply blindly include the option on any pool that is configured to
send it. Obviously, in the presence of buggy clients, the server should
only send the option if it was requested, but servers typically already do
that. The offer behaviour can stay the same: if the server gets a discover,
it picks an address and responds with an offer from the pool. Per RFC 2131
section 3.1, that address need not be reserved, but it could be reserved
for a brief time as well. Either works. If the client gets the option and
decides it doesn't need IPv4, it won't send a request; after a while, the
server can free the address if it had briefly reserved it. If the client
wants IPv4, it will send a request and get an ack.

As Bernie says, if the pool is too small for the number of clients (which
it will be, if this option is to be useful), and too many clients send
discovers simultaneously (e.g., they're rebooted all at the same time),
then the server will either not respond with offers to some of them, or
will respond with offers and be forced to nak if two clients request the
same address. Things continue to work.

The current text in the draft proposes an optimization on top of that:

   If the pool is explicitly configured with a dedicated IPv4

This does indeed require code changes on the server side. But I think it
would be good if such changes were optional. Additionally, this
optimization creates the problem that if the client and responds to the nak
with a discover, and the server replies with the same offer as before, then
the client could gets stuck in a loop.

Personally, I would NOT recommend breaking the semantics of a DHCPOFFER and
> always include an address because you never know how intermediate devices
> that may be "snooping" this traffic will handle this; for example, the
> intermediate device might drop what it feels is an invalid packet.
>
>
> This is definitely not an issue, though, because the network operator is
> choosing to deploy this.  They can be responsible for ensuring correct
> behavior if there are any middleboxes intercepting the DHCPv4 traffic and
> doing stuff with it.   Expecting this to Just Work with no infrastructure
> changes seems unnecessary.
>

I don't think this is a good justification for doing things that could
break compatibility. It's true that the network operator is choosing to
deploy this. But the network operator may not fully control all the devices
on the network, and even if they do, fixing bugs is expensive: the bug
needs to be reported, the vendor (assuming they're still around) might need
to be convinced that it's a bug, code changes need to be made, the device
may need to be updated to a substantially newer version, software needs to
be re-qualified, etc. I agree with Bernie that if we can avoid changing the
observed behaviour, that would be better.

---

From: Ted Lemon <[email-masked]>
Date: Fri, 6 Dec 2019 10:55:05 -0800

Lorenzo, it might help for you to make explicit why you do not want to require changes on the server. This seems like a short sicher choice for a solution that’s going to be deployed for a long time. Why not do it right given we’re going to have to live with it for decades?

> On Dec 6, 2019, at 08:35, Lorenzo Colitti <[email-masked]> wrote:
> 
> 
> I don't think this option requires any server changes other than the code to parse and serialize the option. That the server doesn't even need to know or care whether the client supports the option or not. At worst, it can simply blindly include the option on any pool that is configured to send it. Obviously, in the presence of buggy clients, the server should only send the option if it was requested, but servers typically already do that. The offer behaviour can stay the same: if the server gets a discover, it picks an address and responds with an offer from the pool. Per RFC 2131 section 3.1, that address need not be reserved, but it could be reserved for a brief time as well. Either works. If the client gets the option and decides it doesn't need IPv4, it won't send a request; after a while, the server can free the address if it had briefly reserved it. If the client wants IPv4, it will send a request and get an ack.
> 
> As Bernie says, if the pool is too small for the number of clients (which it will be, if this option is to be useful), and too many clients send discovers simultaneously (e.g., they're rebooted all at the same time), then the server will either not respond with offers to some of them, or will respond with offers and be forced to nak if two clients request the same address. Things continue to work.
> 
> This does indeed require code changes on the server side. But I think it would be good if such changes were optional. Additionally, this optimization creates the problem that if the client and responds to the nak with a discover, and the server replies with the same offer as before, then the client could gets stuck in a loop.
> 
> I don't think this is a good justification for doing things that could break compatibility. It's true that the network operator is choosing to deploy this. But the network operator may not fully control all the devices on the network, and even if they do, fixing bugs is expensive: the bug needs to be reported, the vendor (assuming they're still around) might need to be convinced that it's a bug, code changes need to be made, the device may need to be updated to a substantially newer version, software needs to be re-qualified, etc. I agree with Bernie that if we can avoid changing the observed behaviour, that would be better.

---

From: Simon Hobson <[email-masked]>
Date: Fri, 6 Dec 2019 21:42:03 +0000

> - IPv6 only applications clearly indicate they're IPv6 only, by only

I think "IPv6 only" applications are a rare thing, and will remain so for a long time. Applications that can use IPv4 or IPv6, and which can work fine in IPv6 if IPv4 isn't available, are likely to be the norm for some time.

For an application to signal such compatibility modes to the OS would need substantial changes to the interaction model between application and OS. In the general case, that's just not going to happen.

> Ted Lemon <[email-masked]> wrote:

> Lorenzo, it might help for you to make explicit why you do not want to require changes on the server. This seems like a short sicher choice for a solution that’s going to be deployed for a long tim…

As previously described in terms of identifying bugs in intermediate equipment, raising bug reports, persuading the vendor (if they are still around and the kit is still in support) to fix it, and then rolling out the fix ...
Why require changes in DHCP servers when it can be done without any code changes at all ?

Perhaps define the option such that DHCP server vendors can, if they so desire, code in some optimisations - but I would say that allowing it to work without code changes would be much better.

There is one thought that comes to mind ... In effect, where this option is deployed, then (native) IPv4 is considered a legacy protocol that's being deprecated - why invest more effort than needed in supporting it.

---

From: "Bernie Volz (volz)" <[email-masked]>
Date: Fri, 6 Dec 2019 22:07:38 +0000

I fully agree (no server changes, minimum investment for DHCPv4).

So where are these proposed changes to be done anyway?

In terms of adding new options, this happens by IETF/IANA all of the time and most servers, while they may ship with a pre-configure set, support defining new options and configuring instances of these options. And, servers already have the logic to return a configured option if the client sends that option in its Parameter Request List option.

And, in terms of the DHCPDISCOVER never transitioning to a DHCPREQUEST, what here needs changing? RFC2131 is clear that there are no issues with this as section 4.3.2 states:

         ... Because
      the servers have not committed any network address assignments on
      the basis of a DHCPOFFER, servers are free to reuse offered
      network addresses in response to subsequent requests.  As an
      implementation detail, servers SHOULD NOT reuse offered addresses
      and may use an implementation-specific timeout mechanism to decide
      when to reuse an offered address.

Section 3.1 also has:

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

(In the server I work on, we took that avoids to mean within a reasonably short time period - by default 2 minutes though configurable.)

Is it the potential probing of an address before offering it? Is so, what's the harm? (And RFC2131 recommends this be configurable as to whether it happens.)

Sure, there are things you might do to optimize (such as what was mentioned in the draft), but I don't see that being necessary at all for this deployment. And, in some cases (such as if the client where to have changed its mind between the DHCPDISCOVER and when DHCPOFFER is returned, perhaps it is a bad thing - since you never really want to lease that address and this would require additional special logic). After the discussions, I just can't see this optimization being worth it since if all addresses are in use, the client just ends up sending DHCPDISCOVERs (which server drops if it cannot assign a lease). But other than wasting some packets and time before DHCPv4 is disabled, there's no harm.

---

From: Jen Linkova <[email-masked]>
Date: Mon, 9 Dec 2019 10:53:46 +1100

> >enough subnet to cover 100% of all expected hosts if 20% will do?

Exactly.

> Are you running out of RFC 1918 addresses in your pool?

Yes, I am. I've run out of private addresses.
So just deploying NAT64 and giving IPv4 address to all devices by
default does not solve my problem,
as all those devices will be consuming IPv4 addresses, despite the
fact that >80% of those devices would work just fine w/o IPv4.

---

From: Jen Linkova <[email-masked]>
Date: Mon, 9 Dec 2019 11:01:08 +1100

> I really feel like there is some point-missing going on here. It is trivial to make this feature only activate for clients that support it. If that is done, then there is no reason to assign an add…

The goal is that whatever the server does, it should be able to
distinguish it  from any failure scenarios and stop asking. That's the
reason why we are not suggesting that
the server should just ignore requests from the clients if the clients
sends the option. The positive signal 'I understand the option and
this network is offering IPv6-only service'. Is there any way to do it
w/o sending an OFFER back?

---

From: Ted Lemon <[email-masked]>
Date: Sun, 8 Dec 2019 16:47:34 -0800

If the client lists the option in the parameter request list, then the server knows it supports it. It can then send back a dhcpoffer with no address, knowing the client will do the right thing.

I don’t think there is a way to shut the client up if it does not support the new behavior. 

> On Dec 8, 2019, at 16:01, Jen Linkova <[email-masked]> wrote:
>

---

From: Jen Linkova <[email-masked]>
Date: Mon, 9 Dec 2019 11:53:57 +1100

> Yes, you could reserve an address, but I don’t see that as required. Note that I had suggested this to the authors before the draft was published as an optimization; I don’t think it should be the…

I'm fine with it. I'll remove the reference to a dedicated address to return.
So just to summarise the discussion: we have a number of options on the table:
a) let server just return *an* address from the pool, assuming that as
the host would not accept the offer anyway, the address will be made
available again soon;
   pros:
      --- no changes on the server side;
      --- it would look normal to smart middle boxes
   cons:
      --- might lead to higher pool utilisation
b) return some bogus address (0.0.0.0 or smth else)
    pros:
       --- client would not be able to assign it (hmm..theoretically)
      --- optimized pool usage
   cons:
      --- requires changes on the server
      --- might trigger unexpected behaviour on smart middle boxes
(==> slowing down the adoption)

c) do not offer anything, do smth esle instead (what exactly?)

After writing it down like that I do agree that we shall probably choose a) ;)

> The alternative is risky. If the server uses a bogus OFFER value, and some client requests it and the server hands it out, that creates the possibility for misconfiguration or bugs to create really bad outcomes where multiple hosts have the same IP address, or some things on the network (e.g., snooping switches) think that multiple hosts have the same IP address. +Tomek Mrugalski any thoughts on whether this can be implemented easily and reliably on the server side?

---

From: Jen Linkova <[email-masked]>
Date: Mon, 9 Dec 2019 12:47:47 +1100

> This is definitely not an issue, though, because the network operator is choosing to deploy this.  They can be responsible for ensuring correct behavior if there are any middleboxes intercepting th…

The question is: how massive those infrastructure changes are and
what's the failure scenarios are expected. We might impede or even
completely prevent the adoption if the entrance barrier is too high.
Also in many cases people operating services (like DHCP) are not the
same people who are looking after the network infrastructure.

I see a big difference between 'incrementally enabling smth on clients
and servers' and 'getting switching and WiFi vendors involved and
upgrade the network infrastructure - which means moths or years of
delay, not mentioning non-obvious failure scenarios, when only some
clients are connected to way-too-smart-boxes'.
If we can make it transparent to the switching infrastructure we
probably should.
--
SY, Jen Linkova aka Furry

---

From: Ted Lemon <[email-masked]>
Date: Sun, 8 Dec 2019 17:52:52 -0800

We’ve always assumed that the highest possible entry barrier is changes on the client. I’m not aware of any middleware that wouldn’t handle this correctly, and apparently Bernie isn’t either. I think this is a non issue. If we can get support in clients, we should be able to deploy. 

> On Dec 8, 2019, at 17:48, Jen Linkova <[email-masked]> wrote:
>

---

From: "Bernie Volz (volz)" <[email-masked]>
Date: Mon, 9 Dec 2019 02:26:56 +0000

I’m with Jen to go with option A in her list. Safest and requires fewer changes / testing.

I said I have no idea whether middleware would have any issues, sure “i am not aware” — but I haven’t done any testing and don’t see a need to as option a is so much better.

- Bernie

> On Dec 8, 2019, at 8:53 PM, Ted Lemon <[email-masked]> wrote:
>

---

From: Jen Linkova <[email-masked]>
Date: Mon, 9 Dec 2019 15:30:37 +1100

On Mon, Dec 9, 2019 at 12:52 PM Ted Lemon <[email-masked]> wrote:
>
> We’ve always assumed that the highest possible entry barrier is changes on the client.

I'd say it's a barrier between 'now' and '100% adoption'. But it's not
a barrier for an incremental deployment. In this case in particular -
I'd not expect 100% of devices to support the option, but as many of
those devices would not have IPv6-only capability as well, that's
fine. So the long tail is acceptable here - that long tail is what we
are deploying IPv6-mostly (IPv4-as-a-Service) networks anyway.

>I’m not aware of any middleware that wouldn’t handle this correctly, and apparently Bernie isn’t either. I think this is a non issue. If we can get support in clients, we should be able to deploy.

To prove existence it's  enough to provide a single example. Proving
non-existence is much harder and absence of evidence is not evidence
of absence.
Practically speaking I'd prefer to minimize the risk.
While do not know the probability of a smart infrastructure device
getting an allergic reaction to abnormal DHCP packet, the potential
impact is quite high.

I'm not sure what's the impact of returning an address (ex. for making
that address unavailable for a short period of time)?

---

From: Lorenzo Colitti <[email-masked]>
Date: Mon, 9 Dec 2019 15:03:27 +0900

> After writing it down like that I do agree that we shall probably choose

I would change b) "return 0.0.0.0" and add:

d) configure a specific address from the pool for all IPv6-only-capable
clients
    pros:
       --- most efficiently preserves IPv4 addresses. Always works even if
all clients ask for an address at the same time.
   cons:
      --- requires changes on the server
      --- client cannot actually get the address, so if it sends a request,
things won't go well.

In that sense I think b) is a non-starter, and I don't think c) is feasible
either: we do need to return something to the client, otherwise it can't
know that IPv6-only will work, and I don't think there's anything other
than OFFER that the server respond with (I don't think NAK is typically
sent in response to DISCOVER).

So I think we're down to a) offer a regular address from the pool, and d)
offer a bogus address. The draft attempts to do both right now. I wonder if
we could leave d) in the text, but make it clear that it's just a possible
optimization?

---

From: Lorenzo Colitti <[email-masked]>
Date: Mon, 9 Dec 2019 15:37:09 +0900

> getting an allergic reaction to abnormal DHCP packet, the potential

+1

> that address unavailable for a short period of time)?

The only downside that I can think of is that if you have a thundering herd
of devices that come online all at the same time (e.g., power loss and
site-wide reboot), the offers handed to the v6only-capable devices, in the
brief time they are allocated, can exhaust the pool such that
v6only-incapable devices cannot immediately get an address. However, the
server can mitigate that in two ways:

   1. When issuing an offer, don't reserve the address, or reserve it for a
   very short time.
   2. When issuing an offer to a v6only-capable device, don't reserve the
   address. If the v6only-capable device then comes back and sends a request
   (which it shouldn't, unless something very strange happens), then the
   address may be in use by a v6only-incapable device. In that case, the
   v6only-capable device will get a nak and can go back to discover.

---

From: Lorenzo Colitti <[email-masked]>
Date: Mon, 9 Dec 2019 15:39:52 +0900

Ted,

It sounds like you're arguing that the network should put 0.0.0.0 in the
yiaddr field when sending an offer, even if doing so requires more server
changes. What I don't understand though, is: why? What is the advantage of
putting 0.0.0.0 in the offer? What do those server changes buy us?

Cheers,
Lorenzo

On Mon, Dec 9, 2019 at 9:47 AM Ted Lemon <[email-masked]> wrote:

> If the client lists the option in the parameter request list, then the
> server knows it supports it. It can then send back a dhcpoffer with no
> address, knowing the client will do the right thing.
>
> >> I really feel like there is some point-missing going on here. It is
> trivial to make this feature only activate for clients that support it. If
> that is done, then there is no reason to assign an address at all. The
> offer doesn’t even need to include that option. So any discussion of what
> address to send is irrelevant and unnecessary.
> >
> large

---

From: Mark Smith <[email-masked]>
Date: Mon, 9 Dec 2019 18:31:29 +1100

> I would change b) "return 0.0.0.0" and add:

A possible idea related to this:

- issue a unique IPv4 link local addresses i.e. from within 169.254.0.0/16

- specify a subnet mask for the address of 255.255.255.255

- don't provide a default router

It is legitimate to reuse 169.254.0.0/16 on many different links.

A subnet mask of 255.255.255.255 says to the host that all destinations are
reachable via the default router, and that there are no reachable
destinations directly on the link.

However, as there is no default router to forward to, the host itself would
generate a destination unreachable message and give it to the sending
application.

(A multi-homed host is likely to have a default route out one of its other
interfaces. Source address selection should choose that other interface's
IPv4 address rather than the 169.254.0.0/16 address. The 169.254.0.0/16
interface wouldn't be used.)

Regards,
Mark.

>       --- client cannot actually get the address, so if it sends a
> request, things won't go well.
>
> In that sense I think b) is a non-starter, and I don't think c) is
> feasible either: we do need to return something to the client, otherwise it
> can't know that IPv6-only will work, and I don't think there's anything
> other than OFFER that the server respond with (I don't think NAK is
> typically sent in response to DISCOVER).
>

---

From: Ted Lemon <[email-masked]>
Date: Mon, 9 Dec 2019 05:50:52 -0800

If we return the option, that should be enough. 

> On Dec 8, 2019, at 22:03, Lorenzo Colitti <lorenzo=[email-masked]> wrote:
> 
> In that sense I think b) is a non-starter, and I don't think c) is feasible either: we do need to return something to the client, otherwise it can't know that IPv6-only will work, and I don't think there's anything other than OFFER that the server respond with (I don't think NAK is typically sent in response to DISCOVER).

---

From: Fred Baker <[email-masked]>
Date: Mon, 9 Dec 2019 06:48:37 -0800

Sorry for the delay in following up. This is an active thread.

> On Dec 4, 2019, at 3:26 PM, Jen Linkova <[email-masked]> wrote:
> 

It might.

I spent some time looking for the definition of "dual stack" (for another reason), and found that while the term is used in some 94 IPv6-related RFCs, it is never really defined. To me, and I think the authors of those various RFCs, the implication is that one could turn either IPv4 or IPv6 off, and peers using the remaining protocol would still be able to use whatever service the device or application offers. At my former employer, the term was generally used to mean that a system was generally IPv4-capable but had some IPv6 capabilities as well. The nearest thing to a definition that I found was in RFC 3750, but even there one has to read it carefully.

RFC 3750 makes the point about the OS offering either or both, but some applications requiring IPv4, and of transitions being not only for the OS, but for applications.

> reducing over time, I hope).

Speaking as a co-author of stateless IPv4/IPv6 NAT (which is about connecting from {IPv4|IPv6} to {IPv6|IPv4}, and is used by NAT64, which is about connecting statefully from an IPv6-only network to an IPv4-only network), I would agree that neither stateless nor stateful IPv4/IPv6 translation is a "silver bullet" - primarily due to issues raised in RFC 2993. My co-authors wanted to not have to move all of their IPv4-only servers to the IPv6-only network before being about to test it. They wanted the evolving IPv6-only network to be able to access IPv4-only servers on day 1, even though they had the full intention of making all servers IPv6-capable over time, or duplicating them with IPv6-only servers. Translation gave them the capability of getting there in a limited fashion while they pursued the remainder of the process.

The "better tool", if I understand RFC 2993 correctly, would be 
(1) to remove network layer addresses from application layer applications, so that there is no coupling between the application layer and the network layer, or
(2) make the application equally able to use IPv4 or IPv6 addresses, or
(3) deploy separate instances of the application for use in IPv4 and IPv6 networks. 

Each has issues...

---

From: Gábor LENCSE <[email-masked]>
Date: Mon, 9 Dec 2019 16:33:02 +0100

On 12/9/2019 15:48, Fred Baker wrote:

[...]

> (1) to remove network layer addresses from application layer applications, so that there is no coupling between the application layer and the network layer, or

MPT could do something like that. It could also be considered as an IPv6 
transition technology, as it supports any IP version tunnel over 
(several) any IP version paths. Do you think that it could be useful for 
the above purpose?

Please see our I-D: https://tools.ietf.org/html/draft-lencse-tsvwg-mpt-04

and our slides: 
https://datatracker.ietf.org/meeting/99/materials/slides-99-intarea-mpt-network-layer-multipath-library-00

Best regards,

Gábor

---

From: Tomek Mrugalski <[email-masked]>
Date: Tue, 10 Dec 2019 00:40:55 +0100

On 06.12.2019 17:02, Ted Lemon wrote:
> going to have to have some special-purpose code to support it.  Better
> to do the clean solution than a hack that minimizes changes to the
> server at the expense of more complication in the client-server
> interaction.
This part of the discussion seems to have been mostly settled. But in
case it isn't, here's another opinion. As a DHCP server vendor, I'd very
much prefer no code changes. For several reasons:

1. You can start using the option now, without any server upgrades, just
tweak the server configuration to send one extra option. This is
expected to be a significant factor in the adoption process.

2. The basic DHCPv4 mechanism of clients requesting options in PRL and
the server sending them is decades old and there are tons of policy
mechanisms around it (send only when requested, force sending to
specific devices or class of devices, treat devices that request that
option as a separate class, etc.) These are all well understood by
network admins.

3. Extra logic requires extra testing. There may be incompatibilities,
especially with firewalls and relays that attempt to track state. Some
of them may be hard to detect.

Having said that, I'm willing to implement code changes if I have to.

Tomek

---

From: Tomek Mrugalski <[email-masked]>
Date: Tue, 10 Dec 2019 00:44:44 +0100

On 06.12.2019 17:18, Bernie Volz (volz) wrote:
> BV> I will say that one issue that could exist with this option that
> is a bit unusual is that it is currently 0-length. We have only one
> other zero-length option that I recall, and that is Rapid Commit
> (which is client to server, not server to client). So, it is possible
> that there are clients that are unhappy about zero-length options.

Agree it's a valid concern. It could have affected some middleboxes
(snooping relay, firewall tracking state etc.). Fortunately, it's going
to be addressed in upcoming -01 rev. The option format is redefined to
be 4 octets long and will contain a timer value.

Tomek

---

From: Tomek Mrugalski <[email-masked]>
Date: Tue, 10 Dec 2019 01:05:40 +0100

On 06.12.2019 08:21, Lorenzo Colitti wrote:
> normal OFFER from the pool? That way, if something unexpected happens
> and the client sends a DHCPREQUEST for it, the server can hand it out
> as normal.
>
> The alternative is risky. If the server uses a bogus OFFER value, and
> some client requests it and the server hands it out, that creates the
> network (e.g., snooping switches) think that multiple hosts have the
> same IP address. +Tomek Mrugalski
> <mailto:[email-masked]> any thoughts on whether this can
> be implemented easily and reliably on the server side?

I would go with a normal OFFER from the pool. Some servers (such as Kea)
don't reserve the address at all when sending back OFFERS. This seems
like the most robust approach. Clients that correctly implement the
draft would never send a REQUEST for addresses offered. Buggy clients
that implement the draft in a broken way and request the address, would
simply get the address and the server will continue offering other
addresses to IPv6-only Preferred capable clients. In Kea, sending an
address from a pool would work out of the box and not a single address
would be allocated for ipv6-only preferred clients.

The alternative (bogus address or small pool of just one address) is
much more tricky to set up and there may be messy corner cases. Every
DHCP server I know does various checks if the address belongs to a pool
(so setting something completely out of the range could break down
various mechanisms), it could mess up statistics and thresholds. The
fundamental role every DHCP server is supposed to play is to ensure that
the addresses are not duplicated and there are many mechanisms to help
ensure that. If we decided to go with bogus address shared by all
ipv6-only preferred clients, most (all?) of such mechanisms would have
to be conditionally disabled. Let's not do that.

Tomek

---

From: Ted Lemon <[email-masked]>
Date: Mon, 9 Dec 2019 16:17:35 -0800

On Dec 9, 2019, at 4:05 PM, Tomek Mrugalski <[email-masked]> wrote:
> The alternative (bogus address or small pool of just one address) is much more tricky to set up and there may be messy corner cases. Every DHCP server I know does various checks if the address belongs to a pool (so setting something completely out of the range could break down various mechanisms), it could mess up statistics and thresholds. The fundamental role every DHCP server is supposed to play is to ensure that the addresses are not duplicated and there are many mechanisms to help ensure that. If we decided to go with bogus address shared by all ipv6-only preferred clients, most (all?) of such mechanisms would have to be conditionally disabled. Let's not do that.

It’s hard to imagine how this could be possible.   You allocate the address, then verify that it’s okay to send?   That’s backwards.  I would expect you to allocate an address that is available and valid to send.  Otherwise you’d have to re-run the allocation algorithm multiple times until you come up with an address that works.  So in fact I think that the allocation algorithm in this case would just be a no-op, and that would not require a lot of extra fuss.

---

From: Tomek Mrugalski <[email-masked]>
Date: Tue, 10 Dec 2019 01:35:01 +0100

> A minor note about the draft requesting use of (DHCPv4) option code 108. Per RFC3679 this was in use as a "swap path" option at some point, though never published as a draft. That is why it is mark…

As a person who put that text there, let me explain my reasons. RFC2132
(Mar 1997) said that option codes 128-255 were reserved for
site-specific options. RFC3942 (Nov 2004) reclassified 128-223 as a
general purpose option codes under IANA governance. However, any
implementation created between 1997 and 2004 could have used those
option codes for whatever purpose they desired. It's been quite a long
time ago, but we all know about long tails.

With that in mind, I tried to find the lowest option code that's
available. I was not able to find any specific information about prior
use of codes 102-107, except RFC3679 saying they were returned (and thus
previously used by someone). Code 108 seems safer than other codes - it
is below 128, RFC3679 explicitly says that there was an idea to use it
for swap path, but that must have died quickly if no I-D was ever
published about it. So it seems like a safe bet.

At the end of the day, this is only a request for IANA. If this gets
published, they may honor or ignore it.

Tomek

p.s.
Apologies for sending it today. Museums are supposed to be closed on
Mondays.

---

From: Ted Lemon <[email-masked]>
Date: Mon, 9 Dec 2019 16:51:00 -0800

> published about it. So it seems like a safe bet.

I tend to agree.

---

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

> transation prefix in a way that the host doesn't understand.

I do not think the network is expected to provide NAT64 prefix now in any way.
Our pref64 draft has not been published yet, and anyway it's an
additional signal.

> do we need a new option for every IPv4aaS technology?

Ah, that's the unresolved issue in the draft yet, some more work (and
input from the WG) required.
What could be done here:
1) we can declare that we do not believe there is any chance of any
other transition mechanism for IPv6-only hosts to appear any time
soon.
2) we can - as it's been proposed - add a field to encode the
transition technologies supported by the host (e.g. as a bit mask).

Personally I'd be very surprised to see any new mechanism to be
developed and adopted but I'd not oppose #2 either.

---

From: Tomek Mrugalski <[email-masked]>
Date: Tue, 10 Dec 2019 02:14:44 +0100

On 05.12.2019 04:48, Lorenzo Colitti wrote:
> Additionally, I would expect that a separate option would be simpler to implement on the server side. This is because the server can just continue to consider the lease time a property of the address pool, and treat this new option simply as a statically-configured option that is returned to clients iff they requested it in the PRL. If we use the same field for the lease timer and the V6ONLY_WAIT timer, then the server will need to change the lease timer in DHCPOFFER packets depending on whether the option was requested or not, and I would expect that to be more complex. +Tomek Mrugalski any thoughts on this?
>From the server perspective, a new option is much simpler. There's no question about it. Every DHCP server I know has the ability to define custom options, so deploying this should be a simple configuration change, no code change. Most servers offer reach policy mechanisms to govern sending options back that can be used to fine tune sending the option back (blacklist specific devices, list clients by MAC/client-id/whatever, do client classifications, etc.).

In the DHCP protocol, most burden of tracking various timers is on the client side. Server really needs to track lease expiration since there's no lease being assigned, there's no state to maintain here on the server side.(Ok, it's a bit of oversimplification.) This should scale really well.

Tomek

---

From: Tomek Mrugalski <[email-masked]>
Date: Tue, 10 Dec 2019 02:25:07 +0100

On 05.12.2019 05:45, Roy Marples wrote:
>> On Thu, Dec 5, 2019 at 11:50 AM Roy Marples <[email-masked] <mailto:[email-masked]>> wrote:
>>
>>      > The T2 timer is about the validity of the address that is offered
>>
>>     Wrong.
>> Regardless: the T2 timer is about the validity of the information that is offered. The V6ONLY_WAIT timer is different: it's about when the client should ask again if the client *does not request* the offer.
> 
> So in simple terms.
That's a good analogy. Would it be helpful if the V6ONLY_WAIT description was update to say something similar to: "Upon reception of the V6ONLY_WAIT option, the client sets its reverts back to DHCPDISCOVER retransmission and sets its retransmission timer to V6ONLY_WAIT seconds"? The effect would be mostly the same, with two changes:

1. technically it would not introduce a new timer
2. it would most likely require update of RFC2131

I don't particularly like that approach, but could live with that if that's what the consensus is.

>>     to ask to keep protocol setup separate?
Perhaps it's poorly named, but it's very much DHCPv4 option. The option is not supposed to affect any IPv6 behavior.

How about calling it what it really is: DISABLEV4? 

Tomek

---

From: Lorenzo Colitti <[email-masked]>
Date: Tue, 10 Dec 2019 10:47:41 +0900

On Tue, Dec 10, 2019 at 10:25 AM Tomek Mrugalski <[email-masked]>
wrote:

> That's a good analogy. Would it be helpful if the V6ONLY_WAIT description
> was update to say something similar to: "Upon reception of the V6ONLY_WAIT
> option, the client sets its reverts back to DHCPDISCOVER retransmission and
> sets its retransmission timer to V6ONLY_WAIT seconds"?

If it sets its retransmission timer to V6ONLY_WAIT seconds, then if the
first discover is dropped, will the second one be V6ONLY_WAIT seconds after
that? That seems bad. Once the V6ONLY_WAIT timer fires, we want the
retransmission interval to be back to a low value, like 1-2 seconds, right?

Perhaps it's poorly named, but it's very much DHCPv4 option. The option is
> not supposed to affect any IPv6 behavior.
>

It's not just "disable IPv4". It's "disable IPv4, because you there's this
other thing instead". See
https://mailarchive.ietf.org/arch/msg/dhcwg/Xc0yQIXWkKMCLlxhM-Bp0EW0P7w and
follow-ups.

---

From: "STARK, BARBARA H" <[email-masked]>
Date: Tue, 10 Dec 2019 14:03:46 +0000

On Tue, Dec 10, 2019 at 10:25 AM Tomek Mrugalski <[email-masked]<mailto:[email-masked]>> wrote:
That's a good analogy. Would it be helpful if the V6ONLY_WAIT description was update to say something similar to: "Upon reception of the V6ONLY_WAIT option, the client sets its reverts back to DHCPDISCOVER retransmission and sets its retransmission timer to V6ONLY_WAIT seconds"?

If it sets its retransmission timer to V6ONLY_WAIT seconds, then if the first discover is dropped, will the second one be V6ONLY_WAIT seconds after that? That seems bad. Once the V6ONLY_WAIT timer fires, we want the retransmission interval to be back to a low value, like 1-2 seconds, right?

It's not just "disable IPv4". It's "disable IPv4, because you there's this other thing instead". See https://mailarchive.ietf.org/arch/msg/dhcwg/Xc0yQIXWkKMCLlxhM-Bp0EW0P7w<https://urldefense.proofpoint.com/v2/url?u=https-3A__mailarchive.ietf.org_arch_msg_dhcwg_Xc0yQIXWkKMCLlxhM-2DBp0EW0P7w&d=DwMFaQ&c=LFYZ-o9_HUMeMTSQicvjIg&r=LoGzhC-8sc8SY8Tq4vrfog&m=4d24eNHJHAEFS_Y3-CipdZq80gyQxXT1VGfeLc9lkcE&s=UZx2lQrGUCc1rleXnzrXpv8AT2jJ1qNVp4CCn94OpwU&e=> and follow-ups.

<bhs> Is it really “disable IPv4 ...” or “disable DHCPv4 address acquisition for a while”? I thought hosts were still free to use autoconfigured IPv4 addresses (169.254.x.x) on the LAN. I ask because I don’t want to go down that rat-hole of people thinking it might be ok for routers to start blocking everything on the IPv4 ethertype if this option is sent from the router’s DHCPv4 server. We’re just trying to save on DHCPv4 address assignment with this, aren’t we?

---

From: Ted Lemon <[email-masked]>
Date: Tue, 10 Dec 2019 06:38:43 -0800

Good point. We’re wrestling with the same thing for ipv6 right now. 

> On Dec 10, 2019, at 06:04, STARK, BARBARA H <[email-masked]> wrote:
> 
> 
> On Tue, Dec 10, 2019 at 10:25 AM Tomek Mrugalski <[email-masked]> wrote:
> It's not just "disable IPv4". It's "disable IPv4, because you there's this other thing instead". See https://mailarchive.ietf.org/arch/msg/dhcwg/Xc0yQIXWkKMCLlxhM-Bp0EW0P7w and follow-ups.
>