Subject: [v6ops] Implementation Status of PREF64

From: David Farmer <[email-masked]>
Date: Fri, 24 Sep 2021 12:19:32 -0500

Are there and host or router implementations of PREF64 (RFC8781) out in the
wild yet?

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: Erik Kline <[email-masked]>
Date: Fri, 24 Sep 2021 15:26:20 -0700

My understanding is that Android supports
<https://cs.android.com/android/_/android/platform/packages/modules/NetworkStack/+/70d7ffa59f1f4ac242d8409143108466025102c7>
handling PREF64 RA options.

On Fri, Sep 24, 2021 at 10:21 AM David Farmer <farmer=
[email-masked]> wrote:

> Are there and host or router implementations of PREF64 (RFC8781) out in
> the wild yet?
>
> Thanks
>
>
> --
> _______________________________________________
> v6ops mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/v6ops
>

---

From: Lorenzo Colitti <[email-masked]>
Date: Sat, 25 Sep 2021 09:53:38 +0900

Yes, it should be supported by (most) devices running Android R or above.
If you try it and it doesn't work, or you find a bug, let me know and we'll
look into it.

I don't know of any router implementations at the moment. +Jen Linkova
<[email-masked]> might. On my home network I use a simple python script
that sends an RA from a non-existent link-local address containing only the
option and no other info. Because RA supports multiple sources of
information this just works; even if the primary router stops sending RAs.
I can share that script if you like.

---

From: Owen DeLong <[email-masked]>
Date: Fri, 24 Sep 2021 19:54:29 -0700

Now if they could only implement DHCPv6.

Owen

> On Sep 24, 2021, at 3:26 PM, Erik Kline <[email-masked]> wrote:
> 
> My understanding is that Android supports <https://cs.android.com/android/_/android/platform/packages/modules/NetworkStack/+/70d7ffa59f1f4ac242d8409143108466025102c7> handling PREF64 RA options.
> 
> On Fri, Sep 24, 2021 at 10:21 AM David Farmer <farmer=[email-masked] <mailto:[email-masked]>> wrote:
> Are there and host or router implementations of PREF64 (RFC8781) out in the wild yet?
> 
> Thanks
> 
> 
> -- 
> David Farmer               Email:[email-masked] <mailto:[email-masked]>
> [email-masked] <mailto:[email-masked]>
> https://www.ietf.org/mailman/listinfo/v6ops <https://www.ietf.org/mailman/listinfo/v6ops>

---

From: Mark Smith <[email-masked]>
Date: Sat, 25 Sep 2021 17:08:33 +1000

> Now if they could only implement DHCPv6.

What problem would that solve?

It won't solve the problem of recording IPv6 addresses in use:

https://ipv6tao.blogspot.com/2021/09/the-stateful-dhcpv6-myth-no-it-doesnt.html

---

From: Owen DeLong <[email-masked]>
Date: Sat, 25 Sep 2021 00:44:18 -0700

DHCP by itself, no.

DHCP+NAC, well, yes… yes it does.

You see, with NAC (Network Admission Control), you don’t get on the network unless and/or until
you’ve properly completed the 802.1x authentication process and part of that includes (potentially)
requiring you to have an address that the DCHP server will vouch for being tied to your DUID and/or
MAC address.

So while the article you site is sort of correct to some extent as far as it goes, it presumes a set
of limitations on the network that isn’t true for many enterprise networks.

Owen

> On Sep 25, 2021, at 00:08 , Mark Smith <[email-masked]> wrote:
> 
> 
> 
> On Sat, 25 Sep 2021, 12:55 Owen DeLong, <owen=[email-masked] <mailto:[email-masked]>> wrote:
> https://ipv6tao.blogspot.com/2021/09/the-stateful-dhcpv6-myth-no-it-doesnt.html <https://ipv6tao.blogspot.com/2021/09/the-stateful-dhcpv6-myth-no-it-doesnt.html>
> 
> 
> 
> 
> Owen
> 
> 
>> On Sep 24, 2021, at 3:26 PM, Erik Kline <[email-masked] <mailto:[email-masked]>> wrote:
>>

---

From: Lorenzo Colitti <[email-masked]>
Date: Sun, 26 Sep 2021 14:40:20 +0900

If you have NAC you don't need DHCPv6 for anything. RFC 7934 section 9.1.

---

From: Lorenzo Colitti <[email-masked]>
Date: Sun, 26 Sep 2021 17:00:14 +0900

Since a couple of folks asked, I put the script up on github:

https://github.com/lcolitti/radvd-pref64

It's pretty basic, only taking the interface name on the command line and
hardcoding the NAT64 prefix 64:ff9b::/96, a lifetime of 1800 and an
interval of 240s. I included the openwrt hotplug script I use as well. It
works well on openwrt 18.06 but haven't tested anything more recent. I
think the code should work on python 3 as well, but that's mostly untested.

Pull requests accepted, though if someone has time to work on this, they
might be better off contributing support to radvd or odhcpd.

On Sat, Sep 25, 2021 at 9:53 AM Lorenzo Colitti <[email-masked]> wrote:

> <[email-masked]> might. On my home network I use a simple python
> script that sends an RA from a non-existent link-local address containing
> only the option and no other info. Because RA supports multiple sources of

---

From: Owen DeLong <[email-masked]>
Date: Sun, 26 Sep 2021 01:32:27 -0700

It depends on your environment. Your anti-dhcp religion is NOT helping.

Owen

> On Sep 25, 2021, at 22:40 , Lorenzo Colitti <lorenzo=[email-masked]> wrote:
> 
> On Sat, Sep 25, 2021 at 4:44 PM Owen DeLong <owen=[email-masked] <mailto:[email-masked]>> wrote:
> DHCP by itself, no.
> 
>> On Sep 25, 2021, at 00:08 , Mark Smith <[email-masked] <mailto:[email-masked]>> wrote:
>> 
>> 
>>

---

From: Mark Smith <[email-masked]>
Date: Sun, 26 Sep 2021 23:49:13 +1000

> DHCP+NAC, well, yes… yes it does.

So NAC somehow gives DHCPv6 the ability to record hosts' Link Local
Addresses? How?

> requiring you to have an address that the DCHP server will vouch for being

What does "includes (potentially)
requiring" mean? Isn't that another way of saying "optional"?

Can you provide more details of this NAC system and how it works?

> of limitations on the network that isn’t true for many enterprise networks.

The article is about limitations of the  DHCPv6 protocol, and how it does
not provide what many people claim it does.

It didn't make any presumptions about enterprise networks limitations,
because not having those limitations doesn't somehow make DHCPv6 do
something it wasn't designed to do and is incapable of doing.

Regards,
Mark.

---

From: Owen DeLong <[email-masked]>
Date: Mon, 27 Sep 2021 14:04:21 -0700

> On Sep 26, 2021, at 06:49 , Mark Smith <[email-masked]> wrote:
> 
> 
> 
> On Sat, 25 Sep 2021, 17:44 Owen DeLong, <[email-masked] <mailto:[email-masked]>> wrote:
> DHCP by itself, no.
> 
> So NAC somehow gives DHCPv6 the ability to record hosts' Link Local Addresses? How?

1. You have to use at least one  Link Local to communicate with the DHCPv6 server.
2. NAC prevents you from getting on the network (meaningfully) until you authenticate with NAC
	using an address supplied by the DHCPv6 server.
3. The DHCPv6 server w
> requiring" mean? Isn't that another way of saying "optional"?

Yes… The NAC administrator can choose whether or not this is a requirement.

> Can you provide more details of this NAC system and how it works?

There are plenty of vendors out there you can contact and there are a variety of methods.

Mostly they piggyback on 802.1x.

In the tightest forms, it goes something like this (oversimplified and generic):

0. Port starts out locked down to communicating with DHCPv6 server and NAC authenticator only.
1. Use LL address to send DHCPv6 request.
2. Get DHCPv6 address and use that for 802.1x authentication. There are a variety of options
	here including authentication of not only the machine, but also the individual currently
	using the machine and the classification of network privileges based on either or both
	of these factors, etc.
3. A filter is added to your port permitting your presented DHCPv6 address (which the NAC authenticator
	has validated matches to your MAC and LL address) that permits your LL and DHCPv6 addresses
	to communicate with the rest of the network. Any additional policies can also be added at this
	point if the administrator chooses.

> The article is about limitations of the  DHCPv6 protocol, and how it does not provide what many people claim it does.

Sure, and as far as that goes, the article is technically true, but misleading as DHCPv6 while not a complete solution
is a key component in a workable solution.

> It didn't make any presumptions about enterprise networks limitations, because not having those limitations doesn't somehow make DHCPv6 do something it wasn't designed to do and is incapable of doing.

Bottom line, however, is you can’t do the kind of address validation you’re talking about without it.

No, DHCPv6 isn’t a complete solution, but you can’t combine SLAAC with the other pieces to form
a complete solution, but you can build it with DHCPv6.

In IPv4, this is a non-issue because everyone takes DHCP for granted. In IPv6, this isn’t an issue unless
you want to allow Android devices to roam your network, in which case, you either give up full control
of your network admission process or you give up on Androids.

Owen

---

From: Jen Linkova <[email-masked]>
Date: Tue, 28 Sep 2021 09:39:58 +1000

> Are there and host or router implementations of PREF64 (RFC8781) out in the wild yet?

There is an ER opened with Juniper to get it supported - the date to
be confirmed yet ;( So talking to your vendors might help.

-- 
SY, Jen Linkova aka Furry

---

From: Lorenzo Colitti <[email-masked]>
Date: Tue, 28 Sep 2021 10:11:02 +0900

> point if the administrator chooses.

I don't see how DHCPv6 is required for any of this. What you describe above
boils down to, "a machine is allowed to use the network only if its MAC
address is acceptable to the network". That can be done with SLAAC just as
well. Let me reword for SLAAC:

0. Port starts out locked down to communicating with NAC authenticator only.
1. Use LL address to send RS.
2. Get IPv6 address from SLAAC and use that for 802.1x authentication.
There are a variety of options
here including authentication of not only the machine, but also the
individual currently
using the machine and the classification of network privileges based on
either or both
of these factors, etc.
3. A filter is added to your port permitting your presented MAC address to
to communicate with the
rest of the network. Any additional policies can also be added at this
point if the administrator chooses.

This is better than the DHCP version above because it allows the client to
use multiple IP addresses and does not need to be re-done when the IP
address changes.

---

From: Mark Smith <[email-masked]>
Date: Tue, 28 Sep 2021 12:18:44 +1000

I'm broadly quite confused by both of these scenarios, in the sense that I
thought 802.1X just used layer 2 frames (because it's an IEEE protocol),
and authentication needed to be completed successfully on a host's
interface before IP could be used. No pre-existing IPv4 or IPv6
connectivity was required to successfully perform 802.1X.

In other words, 802.1X is layer 2 access control to the network, at the
device's layer 2 point of attachment, that either grants or denies
permission to send and receive layer 2 frames other than 802.1X frames.

Since 802.1X authentication is per layer 2 point of attachment, that then
creates the handle for the layer 2 device to do things like record layer 3
addresses used by the 802.1X authenticated entity, regardless of how the
IPv4 and/or IPv6 addresses are acquired, generated or configured.

Regards,
Mark.

On Tue, 28 Sep 2021, 11:11 Lorenzo Colitti, <[email-masked]> wrote:

> I don't see how DHCPv6 is required for any of this. What you describe
> above boils down to, "a machine is allowed to use the network only if its
> MAC address is acceptable to the network". That can be done with SLAAC just
> as well. Let me reword for SLAAC:
>

---

From: Lorenzo Colitti <[email-masked]>
Date: Tue, 28 Sep 2021 11:48:05 +0900

You're right. 802.1x is L2 only, and authenticates the entire MAC address
(with all its IPv4 and IPv6 addresses).

But Owen: the conclusion is the same. If you have 802.1x you don't need
DHCPv6 for tracking, all you need to do is to be able to track which IPv6
addresses were assigned to a given client over time. Basically, the
neighbour binding logging that many vendors alreay support. +Enno Rey
<[email-masked]> provided a good summary in his blog post Does One Need
DHCP(v6)?
<https://theinternetprotocolblog.wordpress.com/2020/03/14/does-one-need-dhcpv6/>

On Tue, Sep 28, 2021 at 11:18 AM Mark Smith <[email-masked]> wrote:

>> 3. A filter is added to your port permitting your presented MAC address
>> to to communicate with the
>> This is better than the DHCP version above because it allows the client
>> to use multiple IP addresses and does not need to be re-done when the IP
>> address changes.
>>
>

---

From: Owen DeLong <[email-masked]>
Date: Mon, 27 Sep 2021 21:54:34 -0700

> On Sep 27, 2021, at 18:11 , Lorenzo Colitti <lorenzo=[email-masked]> wrote:
> 
> On Tue, Sep 28, 2021 at 6:04 AM Owen DeLong <owen=[email-masked] <mailto:[email-masked]>> wrote:
> 
> I don't see how DHCPv6 is required for any of this. What you describe above boils down to, "a machine is allowed to use the network only if its MAC address is acceptable to the network". That can be done with SLAAC just as well. Let me reword for SLAAC:

No… That’s not what it amounts to.

It amounts to a machine can only use the network _IF_ it completes 802.1x Authentication _AND_ the IP address(es) it is using match the DHCP server’s expectation of the address it issued to the MAC address in question.

> 2. Get IPv6 address from SLAAC and use that for 802.1x authentication. There are a variety of options
> 3. A filter is added to your port permitting your presented MAC address to to communicate with the
> This is better than the DHCP version above because it allows the client to use multiple IP addresses and does not need to be re-done when the IP address changes.

Sometimes the network administrator doesn’t want the host using multiple IP addresses for a variety of reasons.

Just because you think it is better in the environments where you operate doesn’t mean it’s better for everyone in every environment.

I repeat… Your anti-DHCP religion is NOT HELPING.

Owen

---

From: Lorenzo Colitti <[email-masked]>
Date: Tue, 28 Sep 2021 14:21:20 +0900

On Tue, Sep 28, 2021 at 1:54 PM Owen DeLong <owen=
[email-masked]> wrote:

> It amounts to a machine can only use the network _IF_ it completes 802.1x
> Authentication _AND_ the IP address(es) it is using match the DHCP server’s
> expectation of the address it issued to the MAC address in question.
>

Why would you want to do this? IPv6 addresses are plentiful and ephemeral.
What does it matter to some server on the Internet (or, in general,
off-link) if a given host uses 2001:db8:1:2:3::f00 or 2001:db8:1:2:3::b00
or both? Why take the privacy implications of using a fixed IID (because
DHCPv6 can't seamlessly change IIDs) to talk to all off-link destinations
all the time?

> IP addresses for a variety of reasons.

Ok, but that's also harmful for a variety of reasons, and for general
purpose devices, it's not recommended by the IETF. That's exactly what RFC
7934 is about - explaining why it's harmful.

Not helping with what? The transition to IPv6? But if so - why bother using
IPv6 if it's just just 128-bit IPv4, with one address per host, no dynamic
address changes (because DHCPv6 can't really support that) and NAT (because
if you can't tell the host that its network configuration has changed, you
need to ensure that the configuration *doesn't* change)? Why use IPv6 to do
that, which requires hosts to implement all the associated complexities
such as NAT traversal, NAT keepalives, etc.? That model works perfectly
well today using IPv4, and I'm pretty sure that OS support for IPv4 isn't
going anywhere any time soon.

---

From: Vasilenko Eduard <[email-masked]>
Date: Tue, 28 Sep 2021 08:51:18 +0000

Hi all,
NAC (or any other solution that collects logs from the switch) is not capable to see SLAAC address because it is self-appointed.
Except for the situation when the switch is doing deep snooping and record all IPv6 addresses.
Do I understand the situation right: SAVI (supported by 1.5 vendors) is mandatory for such IP address logging?
But SAVI is not available on WiFi AP…
I still do not see how to collect IP addresses from L2 devices. NAC or anything else – it does not matter.

The logging from routers is a little bit easy because the router has an ND cache.
We would miss the host that did not communicate with a particular router yet, but it is probably not a problem.
It is indeed possible for some centralized solution (Infoblox?) to collect and correlate ND cache logs from all routers.
Is it implemented? Why?
My guess: 1) different YANG models – not easy to do; and 2) low level of IPv6 adoption in the Enterprise – not many people care yet.
It is possible to develop in this direction standardizing YANG models.

Reminder about status quo: IPv6 has a very low adoption level in Enterprises. Only OTT has adopted IPv6 widely.
DHCP is interoperable with different vendors and already installed. It is ready now to trace IP addresses.
If we would insist that Enterprises should replace it with something else – they could stay on IPv4 and do nothing.
Especially if we would insist that they should replace all switches with switches from one particular vendor.

I have my guess what would be chosen by Enterprises: DHCP or Android,
when some governments would push them strongly for IPv6 adoption.
It would be so good excuse against BYOD that is a nightmare for Enterprises from a security point of view.
Lorenzo, you are risking for your company to miss the huge market. For what? It looks religious.

Eduard
From: v6ops [mailto:[email-masked]] On Behalf Of Lorenzo Colitti
Sent: Tuesday, September 28, 2021 5:48 AM
To: Mark Smith <[email-masked]>; Enno Rey <[email-masked]>
Cc: David Farmer <farmer=[email-masked]>; V6 Ops List <[email-masked]>; Jen Linkova <[email-masked]>; Owen DeLong <owen=[email-masked]>
Subject: Re: [v6ops] Implementation Status of PREF64

You're right. 802.1x is L2 only, and authenticates the entire MAC address (with all its IPv4 and IPv6 addresses).

But Owen: the conclusion is the same. If you have 802.1x you don't need DHCPv6 for tracking, all you need to do is to be able to track which IPv6 addresses were assigned to a given client over time. Basically, the neighbour binding logging that many vendors alreay support. +Enno Rey<mailto:[email-masked]> provided a good summary in his blog post Does One Need DHCP(v6)?<https://theinternetprotocolblog.wordpress.com/2020/03/14/does-one-need-dhcpv6/>

On Tue, Sep 28, 2021 at 11:18 AM Mark Smith <[email-masked]<mailto:[email-masked]>> wrote:
I'm broadly quite confused by both of these scenarios, in the sense that I thought 802.1X just used layer 2 frames (because it's an IEEE protocol), and authentication needed to be completed successfully on a host's interface before IP could be used. No pre-existing IPv4 or IPv6 connectivity was required to successfully perform 802.1X.

In other words, 802.1X is layer 2 access control to the network, at the device's layer 2 point of attachment, that either grants or denies permission to send and receive layer 2 frames other than 802.1X frames.

Since 802.1X authentication is per layer 2 point of attachment, that then creates the handle for the layer 2 device to do things like record layer 3 addresses used by the 802.1X authenticated entity, regardless of how the IPv4 and/or IPv6 addresses are acquired, generated or configured.

Regards,
Mark.
On Tue, 28 Sep 2021, 11:11 Lorenzo Colitti, <[email-masked]<mailto:[email-masked]>> wrote:
On Tue, Sep 28, 2021 at 6:04 AM Owen DeLong <owen=[email-masked]<mailto:[email-masked]>> wrote:

---

From: Bob Harold <[email-masked]>
Date: Tue, 28 Sep 2021 08:14:16 -0400

> https://ipv6tao.blogspot.com/2021/09/the-stateful-dhcpv6-myth-no-it-doesnt.html
That is an interesting article, thanks for the viewpoint.
Where I am, we find that DHCP is cost-effective and efficient, and helps us
find hosts easily 99+% of the time.  We do poll the routers and switches
for IP/MAC/port mapping, but to poll all our devices takes much longer than
the DHCP lease time and is expensive in terms of traffic, servers, and
storage.  NAC and 802.1x would be very expensive.
So DHCP is the best solution for us.  Please support it.

 --
Bob Harold

---

From: daveb <[email-masked]>
Date: Tue, 28 Sep 2021 09:22:58 -0400

At 08:14 AM 9/28/2021, Bob Harold wrote:

>On Sat, Sep 25, 2021 at 3:08 AM Mark Smith 
><<mailto:[email-masked]>[email-masked]> wrote:
>
>
>On Sat, 25 Sep 2021, 12:55 Owen DeLong, 
><owen=<mailto:[email-masked]>[email-masked]> wrote:
><https://ipv6tao.blogspot.com/2021/09/the-stateful-dhcpv6-myth-no-it-doesnt.html>https://ipv6tao.blogspot.com/2021/09/the-stateful-dhcpv6-myth-no-it-doesnt.html
>
>
>Where I am, we find that DHCP is cost-effective 
>and efficient, and helps us find hosts easilyÂ 
>99+% of the time.Â  We do poll the routers and 
>switches for IP/MAC/port mapping, but to poll 
>all our devices takes much longer than the DHCP 
>lease time and is expensive in terms of traffic, 
>servers, and storage.Â  NAC and 802.1x would be very expensive.
>So DHCP is the best solution for us.Â  Please support it.

Agreed.  I believe the DOCSIS specification says 
"The eRouter MUST NOT support SLAAC on its 
Operator-facing interface." so DHCP is basically 
required for that infrastructure.  However SLAAC 
would have to additionally be enabled on that 
same infrastructure to support client devices 
behind a bridged cable modem that do not support DHCP.

--
Dave Bernardi

>Â --Â
>Bob Harold
>
>
>
>
>Owen
>
>
>>On Sep 24, 2021, at 3:26 PM, Erik Kline 
>><<mailto:[email-masked]>[email-masked]> wrote:
>>
>>My understanding is that Android 
>><https://cs.android.com/android/_/android/platform/packages/modules/NetworkStack/+/70d7ffa59f1f4ac242d8409143108466025102c7>supports 
>>On Fri, Sep 24, 2021 at 10:21 AM David Farmer 
>><farmer=<mailto:[email-masked]>[email-masked]> wrote:
>>David FarmerÂ  Â  Â  Â  Â  Â  Â 
>>Â  <mailto:[email-masked]>Email:[email-masked]
>>University of MinnesotaÂ Â
>>2218 University Ave SEÂ  Â  Â  Â  Phone: 612-626-0815
>>Minneapolis, MN 55414-3029Â Â  Cell: 612-812-9952
>><mailto:[email-masked]>[email-masked]
>><mailto:[email-masked]>[email-masked]
><mailto:[email-masked]>[email-masked]
><mailto:[email-masked]>[email-masked]

---

From: Mark Smith <[email-masked]>
Date: Wed, 29 Sep 2021 01:15:26 +1000

Well DOCIS equipment doesn't comply with RFC8504 then.

On Tue, 28 Sep 2021, 23:23 daveb, <[email-masked]> wrote:

> On Sat, Sep 25, 2021 at 3:08 AM Mark Smith <[email-masked] >
> wrote:
>
>
> On Sat, 25 Sep 2021, 12:55 Owen DeLong, <owen= [email-masked]>
> wrote:
> Where I am, we find that DHCP is cost-effective and efficient, and helps
> us find hosts easilyÂ 99+% of the time.Â  We do poll the routers and
> switches for IP/MAC/port mapping, but to poll all our devices takes much
> longer than the DHCP lease time and is expensive in terms of traffic,
> Agreed.  I believe the DOCSIS specification says "The eRouter MUST NOT
> support SLAAC on its Operator-facing interface." so DHCP is basically
> required for that infrastructure.  However SLAAC would have to additionally
> be enabled on that same infrastructure to support client devices behind a
> bridged cable modem that do not support DHCP.
>
> --
> Dave Bernardi
>
>
>
> Â --Â
> Bob Harold
>
>
>
>
> Owen
>
>
> David FarmerÂ  Â  Â  Â  Â  Â  Â Â  Email:[email-masked]

---

From: Fernando Gont <[email-masked]>
Date: Tue, 28 Sep 2021 12:40:13 -0300

On 28/9/21 02:21, Lorenzo Colitti wrote:
> On Tue, Sep 28, 2021 at 1:54 PM Owen DeLong
> <owen=[email-masked] <mailto:[email-masked]>>
> wrote:
>
>     It amounts to a machine can only use the network _IF_ it completes
>     802.1x Authentication _AND_ the IP address(es) it is using match the
>     DHCP server’s expectation of the address it issued to the MAC
>     address in question.
>
>
> Why would you want to do this? IPv6 addresses are plentiful and
> ephemeral. What does it matter to some server on the Internet (or, in
> general, off-link) if a given host uses 2001:db8:1:2:3::f00 or
> 2001:db8:1:2:3::b00 or both? Why take the privacy implications of using
> a fixed IID (because DHCPv6 can't seamlessly change IIDs) to talk to all
> off-link destinations all the time?

Could you please elaborate why "DHCPv6 can;t seamlessly change IIDs"?

In any case: Let's not over-hype what RFC8981 provides: it helps privacy
in scenarios where there is a large number of systems on the same link,
and also limits the window of time during which an address can be used.

However, for many (e.g. automated) attacks, you don't need an address to
be stable for longer than a few dozen minutes.....

>>     This is better than the DHCP version above because it allows the
>>     client to use multiple IP addresses and does not need to be
>>     re-done when the IP address changes.
>     Sometimes the network administrator doesn’t want the host using
>     multiple IP addresses for a variety of reasons.
>
>
> purpose devices, it's not recommended by the IETF. That's exactly what
> RFC 7934 is about - explaining why it's harmful.

Please define harmful. Some could argue that the impact of multiple
addresses on network devices is harmful, too.

> Not helping with what? The transition to IPv6? But if so - why bother
> using IPv6 if it's just just 128-bit IPv4, with one address per host, no
> dynamic address changes (because DHCPv6 can't really support that) and
> NAT (because if you can't tell the host that its network configuration
> has changed, you need to ensure that the configuration *doesn't*
> change)?

Well: RFC8978 -- I experience that every other day, and I use SLAAC on
my home network.

As per "multiple addresses": the general case of multi-address,
multi-router scenario is currently simply broken.

P.S.: I'm just the messenger here....
--
Fernando Gont
Director of Information Security
EdgeUno
PGP Fingerprint: DFBD 63E3 B248 AE79 C598 AF23 EBAE DA03 0644 1531

“This communication is the property of EdgeUno or one of its group companies and/or affiliates. This electronic message contains information which may be privileged or confidential. The information is intended to be for the exclusive use of the individual(s) named above and if you are not the intended recipient be aware that any non-explicitly authorized disclosure, copying, distribution or use of the contents of this information, even if partially, including attached files, is strictly prohibited, and will be considered a criminal offense. Please notify [email-masked] about the unintended receipt of this electronic message and delete it.”

---

From: Philip Homburg <[email-masked]>
Date: Tue, 28 Sep 2021 17:57:18 +0200

> multi-router scenario is currently simply broken.

Do you mean that RFC 8028 is broken or that nobody implements it?

And I assume with 'multi-router scenario' you mean routers that don't 
coordinate. If you have multiple routers that are aware of each other
then a multi-prefix, multi-router scenario works just fine. At least, it
works for me :-)

---

From: "STARK, BARBARA H" <[email-masked]>
Date: Tue, 28 Sep 2021 16:01:16 +0000

Just to provide a few more facts inline with <bhs>...
Barbara

From: v6ops <[email-masked]> On Behalf Of Lorenzo Colitti
Sent: Tuesday, September 28, 2021 12:21 AM
To: Owen DeLong <owen=[email-masked]>
Cc: V6 Ops List <[email-masked]>; Jen Linkova <[email-masked]>
Subject: Re: [v6ops] Implementation Status of PREF64

On Tue, Sep 28, 2021 at 1:54 PM Owen DeLong <owen=[email-masked]<mailto:[email-masked]>> wrote:
No... That's not what it amounts to.

It amounts to a machine can only use the network _IF_ it completes 802.1x Authentication _AND_ the IP address(es) it is using match the DHCP server's expectation of the address it issued to the MAC address in question.

Why would you want to do this? IPv6 addresses are plentiful and ephemeral. What does it matter to some server on the Internet (or, in general, off-link) if a given host uses 2001:db8:1:2:3::f00 or 2001:db8:1:2:3::b00 or both? Why take the privacy implications of using a fixed IID (because DHCPv6 can't seamlessly change IIDs) to talk to all off-link destinations all the time?

<bhs> Just as a note, MAC address or DUID are not the only "identities" that can be used with 802.1x. Some managed or factory-configured devices are given a specific identity and credentials to prove the identity for use with 802.1x. A very common "telco wireline" network architecture is for the CE router to do 802.1x authentication which then lets the RADIUS server tell the DHCP server configuration info specific to that device - such as the stable (effectively static) IPv4/v6 addresses and IPv6 prefix to assign to that device. 3GPP networks don't need 802.1x because they have IMEI/IMSI. Fixed wireless broadband services use 3GPP-defined networks to supply broadband access and have been very limited from an IPv6-prefix-assignment perspective by the lack of prefix assignment other than PREF64 in 3GPP network equipment. Naturally, it's impossible to deploy DHCPv6 if the vendor whose equipment is used doesn't support DHCPv6. I've seen some people suggest that operators should completely replace their entire networks to use a vendor that does support DHCPv6 - which is a very humorous and unrealistic suggestion. PREF64 is all those fixed wireless subscribers get. Many large enterprises use RADIUS with DHCP in a manner similar to wireline networks. I'm not aware of widely-deployed equipment that supports good RADIUS/RA integration for similar device configuration via RA.

This is better than the DHCP version above because it allows the client to use multiple IP addresses and does not need to be re-done when the IP address changes.
Sometimes the network administrator doesn't want the host using multiple IP addresses for a variety of reasons.

Ok, but that's also harmful for a variety of reasons, and for general purpose devices, it's not recommended by the IETF. That's exactly what RFC 7934 is about - explaining why it's harmful.

<bhs> Enterprise networks are not general-purpose networks. They do not want devices (which may in other contexts be used as "general-purpose" devices) to behave like general-purpose devices. They want to control and restrict what those devices do. And until the equipment available to enterprises allows them assert this level of control, IETF can create Best Practices and fume about lack of enterprise IPv6 deployment until it's blue in the face. It's not "harmful" for enterprise operators to restrict what devices can do inside their enterprise network. It's a good and necessary security practice.

I repeat... Your anti-DHCP religion is NOT HELPING.

Not helping with what? The transition to IPv6? But if so - why bother using IPv6 if it's just just 128-bit IPv4, with one address per host, no dynamic address changes (because DHCPv6 can't really support that) and NAT (because if you can't tell the host that its network configuration has changed, you need to ensure that the configuration *doesn't* change)? Why use IPv6 to do that, which requires hosts to implement all the associated complexities such as NAT traversal, NAT keepalives, etc.? That model works perfectly well today using IPv4, and I'm pretty sure that OS support for IPv4 isn't going anywhere any time soon.

<bhs> I mostly agree. Unfortunately, some governments are putting pressure on enterprises and government networks (which are just a type of enterprise network) to support IPv6. This is largely due to messaging coming from the IETF. Maybe IETF should produce a Best Practice recommendation that enterprise and government networks not support IPv6 until all tools they need to properly secure an IPv6-enabled network are widely available as software updates to legacy equipment.
Barbara

---

From: Owen DeLong <[email-masked]>
Date: Tue, 28 Sep 2021 09:17:44 -0700

> On Sep 27, 2021, at 22:21 , Lorenzo Colitti <[email-masked]> wrote:
> 
> On Tue, Sep 28, 2021 at 1:54 PM Owen DeLong <owen=[email-masked] <mailto:[email-masked]>> wrote:

Because whether you like it or not, whether you approve of it or not, some enterprise policies require it.

It’s not a technical problem. It’s a policy problem.

> Ok, but that's also harmful for a variety of reasons, and for general purpose devices, it's not recommended by the IETF. That's exactly what RFC 7934 is about - explaining why it's harmful.

What you call harm, others call policy. It’s not your or the IETF’s job to tell enterprises what their network policy should be, let alone holdup IPv6 adoption because you can’t get it through
your head that no matter what the IETF or you or anyone else says, they have the capability in IPv4, they like the capability, and they won’d deploy IPv6 without it.

So which is the greater harm? Holding up IPv6 adoption by enterprises because you don’t like their policies, or the policies themselves?

IMHO, it’s the delay of IPv6 deployment that is the greater harm here.

> Not helping with what? The transition to IPv6? But if so - why bother using IPv6 if it's just just 128-bit IPv4, with one address per host, no dynamic address changes (because DHCPv6 can't really s…

Yes.

DHCPv6 can support dynamic address changes on pretty much the same terms as SLAAC.

You can tell the host that its network configuration changes just as well with DHCPv6 as you can with SLAAC, so no, this does not create a need for NAT.

DHCP has all the same timers that SLAAC does.

Owen

---

From: JORDI PALET MARTINEZ <[email-masked]>
Date: Tue, 28 Sep 2021 18:24:57 +0200

Hi Barbara,

I don’t think I can agree with your comments about recommending not deploying in enterprise (and thus government) networks.

In fact, I think it is key for advancing the IPv6 deployment that governments require it in any administration network including any acquisitions (hardware, software, services, links, etc.). That encourages the ecosystem to move on to IPv6, including enterprises that want to participate in government tenders.

Governments use taxes from citizens. Governments will commit crimes if they buy any service or product that uses public money and not support IPv6, because that will mean wasting money and requiring in a few years, to buy the same again, even before it is amortized.

I’ve deployed IPv6 in a few dozens of ministries, government buildings and other administration networks, of different sizes (even country level) in several countries in at least 3 continents, and I’ve never found any problems.

It is a paradigm shift, which requires revisiting how the devices attach to the networks, whether they are ethernet drops or WiFi. That’s it.

There are ways to use SLAAC (I don’t recommend using DHCPv6 because the lack of Android and derivatives support), and ensure proper security, such as 802.1x.

In fact, depending on IP (v4 or v6) addresses for providing security I believe is wrong and prone to be faked by attackers.

Regards,

Jordi

@jordipalet

El 28/9/21 18:02, "v6ops en nombre de STARK, BARBARA H" <[email-masked] en nombre de [email-masked]> escribió:

Barbara

On Tue, Sep 28, 2021 at 1:54 PM Owen DeLong <owen=[email-masked]> wrote:

<bhs> Just as a note, MAC address or DUID are not the only “identities” that can be used with 802.1x. Some managed or factory-configured devices are given a specific identity and credentials to prove the identity for use with 802.1x. A very common “telco wireline” network architecture is for the CE router to do 802.1x authentication which then lets the RADIUS server tell the DHCP server configuration info specific to that device – such as the stable (effectively static) IPv4/v6 addresses and IPv6 prefix to assign to that device. 3GPP networks don’t need 802.1x because they have IMEI/IMSI. Fixed wireless broadband services use 3GPP-defined networks to supply broadband access and have been very limited from an IPv6-prefix-assignment perspective by the lack of prefix assignment other than PREF64 in 3GPP network equipment. Naturally, it’s impossible to deploy DHCPv6 if the vendor whose equipment is used doesn’t support DHCPv6. I’ve seen some people suggest that operators should completely replace their entire networks to use a vendor that does support DHCPv6 – which is a very humorous and unrealistic suggestion. PREF64 is all those fixed wireless subscribers get. Many large enterprises use RADIUS with DHCP in a manner similar to wireline networks. I’m not aware of widely-deployed equipment that supports good RADIUS/RA integration for similar device configuration via RA.

<bhs> Enterprise networks are not general-purpose networks. They do not want devices (which may in other contexts be used as “general-purpose” devices) to behave like general-purpose devices. They want to control and restrict what those devices do. And until the equipment available to enterprises allows them assert this level of control, IETF can create Best Practices and fume about lack of enterprise IPv6 deployment until it’s blue in the face. It’s not “harmful” for enterprise operators to restrict what devices can do inside their enterprise network. It’s a good and necessary security practice.

Barbara

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

**********************************************
IPv4 is over
Are you ready for the new Internet ?
http://www.theipv6company.com
The IPv6 Company

This electronic message contains information which may be privileged or confidential. The information is intended to be for the exclusive use of the individual(s) named above and further non-explicilty authorized disclosure, copying, distribution or use of the contents of this information, even if partially, including attached files, is strictly prohibited and will be considered a criminal offense. If you are not the intended recipient be aware that any disclosure, copying, distribution or use of the contents of this information, even if partially, including attached files, is strictly prohibited, will be considered a criminal offense, so you must reply to the original sender to inform about this communication and delete it.

---

From: Owen DeLong <[email-masked]>
Date: Tue, 28 Sep 2021 11:14:24 -0700

> There are ways to use SLAAC (I don’t recommend using DHCPv6 because the lack of Android and derivatives support), and ensure proper security, such as 802.1x.

Funny… I don’t recommend Android for exactly that reason. lol

> In fact, depending on IP (v4 or v6) addresses for providing security I believe is wrong and prone to be faked by attackers.

It’s not about using the address for security, it’s about securing the address for auditing.

Owen

>  
> Regards,
> Jordi
> 
> @jordipalet
> 
>  
> 
>  
>  
> El 28/9/21 18:02, "v6ops en nombre de STARK, BARBARA H" <[email-masked] <mailto:[email-masked]> en nombre de [email-masked] <mailto:[email-masked]>> escribió:
>  
> From: v6ops <[email-masked] <mailto:[email-masked]>> On Behalf Of Lorenzo Colitti
> To: Owen DeLong <owen=[email-masked] <mailto:owen=[email-masked]>>
> Cc: V6 Ops List <[email-masked] <mailto:[email-masked]>>; Jen Linkova <[email-masked] <mailto:[email-masked]>>
> _______________________________________________ v6ops mailing list [email-masked] <mailto:[email-masked]> https://www.ietf.org/mailman/listinfo/v6ops <https://www.ietf.org/mailman/listinfo/v6ops>
> http://www.theipv6company.com <http://www.theipv6company.com/>
> The IPv6 Company
>

---

From: Gert Doering <[email-masked]>
Date: Tue, 28 Sep 2021 20:39:50 +0200

Hi,

On Tue, Sep 28, 2021 at 06:24:57PM +0200, JORDI PALET MARTINEZ wrote:
> I don???t think I can agree with your comments about recommending not deploying in enterprise (and thus government) networks.
> 

As a matter of fact, I know of at least one deployment in a "fortune 500"
company that was seriously impaired due to lack of DHCPv6 support in
Android.  They want control over address assignment, tracking of address
assignments, and DHCP is the machinery they use for it (plus NAC, making
sure that only assigned IPv6 addresses can be used).

But they want to support Android devices.

So, still no IPv6 today...

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: JORDI PALET MARTINEZ <[email-masked]>
Date: Tue, 28 Sep 2021 21:02:29 +0200

Yep, I understand the usage of addresses for auditing and because the apps that were doing that auditing were not supporting IPv6 addresses, it was neccesary to modify them and then take in consideration that using IP addresses is not necessarily the best way.

El 28/9/21 20:14, "Owen DeLong" <owen=[email-masked]> escribió:

Owen

Regards,

Jordi

@jordipalet

Barbara

Barbara

---

From: Fernando Gont <[email-masked]>
Date: Tue, 28 Sep 2021 16:23:14 -0300

On 28/9/21 16:02, JORDI PALET MARTINEZ wrote:
> Yep, I understand the usage of addresses for auditing and because the
> apps that were doing that auditing were not supporting IPv6 addresses,
> it was neccesary to modify them and then take in consideration that
> using IP addresses is not necessarily the best way.

Centrally-assigned addresses are useful for a variety of reasons.

Guess what happens anywhere where "life still goes on" without a
specific technology, and the folks producing such technology are
stubborn enough not to address the needs/requests of those meaning to
deploy it?

Thanks,

---

From: Philip Homburg <[email-masked]>
Date: Tue, 28 Sep 2021 21:36:16 +0200

> With SLAAC, you can begin advertising an additional prefix right
> now.
> 
> You cant get rid of the old one so fast, you have to wait for the
> timers to expire.

Indeed I was sloppy. In addition to adding a prefix right now, you can 
also deprecate the old prefix without waiting for timers to expire.

The net effect is that new flows use the new prefix right away, but the old
prefix can be used for 2 hours longer. So timers are limited to 2 hours.

If I remember correctly, there was a draft in 6man that tried to change that
for dealing with flash renumbering. But other parts of the draft got too
complex and the draft seems to have stalled.

> Yes, but actually, this is more effective, also as the DHCP
> reconfigure will also be able to deprecate the previous address
> immediately if needed.

True. Though I don't want to bet on every IoT device implementing reconfigure.

In any case, for a very large part of internet traffic it is important that
new flows use the new address. Many applications agressively kill flows that
don't seem to make progress so there no real need to wait for the old
addresses to disappear.

---

From: Gert Doering <[email-masked]>
Date: Tue, 28 Sep 2021 22:28:45 +0200

Hi,

> prefix can be used for 2 hours longer. So timers are limited to 2 hours.

Indeed, this can be done with SLAAC.

But - the folks asking for proper DHCPv6 support in Android are not
deploying SoHo networks where ISPs tend to change prefixes every now
and then, but managed enterprise networks.  Prefixes change when the
admin says so, and they know how to deal with DHCP lease timers, 
change prefixes at times when nobody is at work, and so on.

So the standard argument from the "DHCPv6 sucks, because!" camp is
really totally ignoring reality.

(Now: supporting a DHCPv6 *server* on an Android device running as
mobile hotspot with frequently changing uplink connectivity - here I
totally agree that DHCPv6 is not the right tool for such a network
setup.  But nobody is asking for it, and refusing DHCPv6 client support
because DHCPv6 server support on the same device is not a useful
thing sounds a bit... "painted myself into a corner" -ish)

Gert Doering
        -- NetMaster

---

From: Philip Homburg <[email-masked]>
Date: Tue, 28 Sep 2021 22:49:55 +0200

>Indeed, this can be done with SLAAC.

I responded to Owen, who was arguing that DHCP is better suited to deal
with flash renumbering than SLAAC.

>change prefixes at times when nobody is at work, and so on.

Indeed. 

>thing sounds a bit... "painted myself into a corner" -ish)

The impression I got was that the main reason to refuse to implement
DHCPv6 IA_NA on Android is to always have a sufficiently large number
of addresses available. With SLAAC you just pick what you want from a
/64. Which DHCPv6 you might be limited to one address.

The argument strikes me as odd, because a router or a switch can limit a 
device to just a few (or one) IP address. And I have encoutered such
devices often enough to know that it is not just a theoretical concept.

---

From: Mark Smith <[email-masked]>
Date: Wed, 29 Sep 2021 08:37:10 +1000

> /64. Which DHCPv6 you might be limited to one address.

It's not. Lorenzo has explained why many times, including in the last week
or so on this mailing list.

Lorenzo has worked out like I have worked out that reducing external
dependencies (such as a dependency on a central server) makes things more
reliable, and also makes deploying new capabilities to hosts easier and
quicker.

---

From: Owen DeLong <[email-masked]>
Date: Tue, 28 Sep 2021 18:42:57 -0700

> On Sep 28, 2021, at 12:02 PM, JORDI PALET MARTINEZ <jordi.palet=[email-masked]> wrote:
> 

What else you got?

Owen

>  
> 
>  
>  
> El 28/9/21 20:14, "Owen DeLong" <owen=[email-masked] <mailto:owen=[email-masked]>> escribió:
>

---

From: Owen DeLong <[email-masked]>
Date: Tue, 28 Sep 2021 18:49:04 -0700

> On Sep 28, 2021, at 12:36 PM, Philip Homburg <[email-masked]> wrote:
> 

Sort of… You can end the preferred lifetime right away and shorten the valid
lifetime significantly.

> prefix can be used for 2 hours longer. So timers are limited to 2 hours.

Yes, you can shorten the valid timer to 2 hours, but it’s 2 hours from the last
time you advertised the prefix in an RA.

> complex and the draft seems to have stalled.

It’s also a wonderful attack surface if you can forge an RA that will shut
down a network.

> True. Though I don't want to bet on every IoT device implementing reconfigure.

Fair enough, I wouldn’t want to, either. OTOH, I am much more willing to accept
IoT devices sticking around on the old prefix for a bit longer than most other
things.

> don't seem to make progress so there no real need to wait for the old

Yes, that’s a common workaround for the poor real world relationship to some
aspects of the specification.

Nonetheless, there are environments where SLAAC is great and environments where
DHCPv6 is a better choice at least in the opinion of those that make the decisions
for those environments.

Lack of Android DHCPv6 support is stalling IPv6 deployment in some of those cases.

Owen

---

From: Owen DeLong <[email-masked]>
Date: Tue, 28 Sep 2021 18:54:55 -0700

> On Sep 28, 2021, at 1:49 PM, Philip Homburg <[email-masked]> wrote:
> 

Not necessarily better, but equally well suited at least.

> devices often enough to know that it is not just a theoretical concept.

If that’s the reason, it’s very silly. With DHCP, the android should act
as a DHCP Relay for it’s hotspot clients. With SLAAC, the whole handset
as a bridge that decrements hop count thing strikes me as odd in the
extreme to begin with.

Owen

---

From: JORDI PALET MARTINEZ <[email-masked]>
Date: Wed, 29 Sep 2021 08:22:49 +0200

Certificates, user/password, …

 

El 29/9/21 3:43, "Owen DeLong" <owen=[email-masked]> escribió:

What else you got?

Owen

 

Owen

Regards,

Jordi

@jordipalet

Barbara

Barbara

---

From: Owen DeLong <[email-masked]>
Date: Wed, 29 Sep 2021 00:55:52 -0700

I rarely find either of those in packet headers for logging on routers or traffic sampling. I suppose YMMV.

Owen

> On Sep 28, 2021, at 23:22 , JORDI PALET MARTINEZ <jordi.palet=[email-masked]> wrote:
> 
> El 29/9/21 3:43, "Owen DeLong" <owen=[email-masked] <mailto:owen=[email-masked]>> escribió:
>  
>  
> 
> 
>> On Sep 28, 2021, at 12:02 PM, JORDI PALET MARTINEZ <jordi.palet=[email-masked] <mailto:jordi.palet=[email-masked]>> wrote:
>>

---

From: Vasilenko Eduard <[email-masked]>
Date: Wed, 29 Sep 2021 08:22:47 +0000

It is not true in general:
reducing external dependencies (such as a dependency on a central server) makes things more reliable, and also makes deploying new capabilities to hosts easier and quicker.

Yes, the distributed protocol is more tolerant to natural disasters, or power outages, or war. (do we need all of these for the 1st hop?!?)
But no, in normal situations additional complexity always brings less reliability and security. Additional complexity is inevitable for any distributed protocol.

Eduard
From: v6ops [mailto:[email-masked]] On Behalf Of Mark Smith
Sent: Wednesday, September 29, 2021 1:37 AM
To: Philip Homburg <[email-masked]>
Cc: v6ops list <[email-masked]>
Subject: Re: [v6ops] Implementation Status of PREF64

Indeed.

It's not. Lorenzo has explained why many times, including in the last week or so on this mailing list.

Lorenzo has worked out like I have worked out that reducing external dependencies (such as a dependency on a central server) makes things more reliable, and also makes deploying new capabilities to hosts easier and quicker.

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

---

From: Philip Homburg <[email-masked]>
Date: Wed, 29 Sep 2021 10:51:25 +0200

>reliable, and also makes deploying new capabilities to hosts easier and

I'll try to remember that this is now the reason the Android doesn't
support DHCPv6. For me it doesn't pass the laugh test.

Basically Android devs are telling operators that they are stupid. People
who have been running big IPv4 networks for decades don't know what they
are doing.

It is trivial to run DHCP in a decentralised mode. Every CPE is effectively
doing that. But somehow, misguided operators never figured that out and
insist on a central database. A cause that really needs to be faught by a
mobile handset OS.

In a typical 802.1x installation, credentials are stored in a central server.
So even getting access requires the central server to be up and running.
Including all the paths between the wifi access point and that server.
There are some hints that it would be good if every wifi host would get a
unique /64. Likely in large environments, this prefix would come from a
central server and there is nothing Android can do about that.

But they can still show their commitment to the cause by not supporting
DHCPv6. 

It seems rather sad to me.

I'm a bit confused about the 'deploying new capabilities to hosts'. 
Historically, DHCP has been very flexible in picking up new features.
The reason for that is that only the DHCP server need to serve them.
All other components, like routers are unaware.

Recently, 6man has a discussion about a generic RA option, in particular
because it is so hard to get agreement on new RA options. Let alone 
get vendor support for options that are added.

So it seems the complete opposite: if you want new capabilies quickly, 
go for DHCP. If you want to wait forever for your router vendor to support
something new, go for RA.

---

From: David Farmer <[email-masked]>
Date: Wed, 29 Sep 2021 11:28:54 -0500

> reliable, and also makes deploying new capabilities to hosts easier and

I had told myself I was going to stay out of this round of the DHCP vs. RA
config, oh well, that lasted about 5 days, guess I was lying to myself. :(

So you are saying we should ditch DNS and go back to HOST files? Because
external dependencies are BAD! Well, it ain't quite that simple.
Sometimes, external dependencies help a solution scale and they are
necessary.

Oh, and where is the shared fate we were promised for PREF64 RA? A script
that announces a separate RA doesn't provide any shared fate. Yes, it is
only a temporary hack, I get that. But, there is the rub, there is a
chicken-and-egg problem here. Until, at least some, router vendors
implement PREF64 RA, why would host vendors implement it? And, until, at
least some, host vendors implement PREF64 RA, why would any router
vendors implement it?

So why would DHCPv6 be any different, well, most DHCP
server implementations have a way to encode, at least, basic unknown DHCP
Options, it's not pretty, but it avoids the chicken-and-egg problem. I'm
not aware of any router advertisement implementations that have a mechanism
to encode unknown RA options, mostly because there weren’t supposed to be
very many options, supposedly, that was going to be DHCP's realm.

However, by deciding the DHCPv6 is BAD, you have changed part of that
equation, without accounting for an easier way to implement new RA options
that become necessary without DHCPv6 being available. Furthermore, DHCPv6
is necessary for certain kinds of networks. If you don't want Android used
on those kinds of networks, say that, and also stop selling Android to
users of those networks. Otherwise, if you want to keep selling Android to
users of those networks, at least provides an optional DHCPv6 client,
disable it by default, or require a separate installation, but don't
require jailbreaking to install a DHCPv6 client on Android. And, if you
insist on not providing an Android DHCPv6 client then work with the
community to provide a mechanism to ease the issue of unknown RAs. I don't
think draft-troan-6man-universal-ra-option was that solution, but that
doesn’t mean we don't need one.

In many cases, your arguments are correct, but you are not providing
complete solutions, to replace the solutions you are rejecting.

I'm really getting sick and tired of this argument, especially everyone
talking past each other, and despite what you think this is very much
delaying IPv6 deployment for many networks.

Thanks.

---

From: Nick Hilliard <[email-masked]>
Date: Wed, 29 Sep 2021 18:41:17 +0100

Mark Smith wrote on 28/09/2021 23:37:
> dependencies (such as a dependency on a central server) makes things 
> more reliable, and also makes deploying new capabilities to hosts easier 
> and quicker.

You sure about that?

https://mailarchive.ietf.org/arch/msg/ipv6/NMWxPx3QEFNmUC1-kGuwyyNrRdw/

Even if you had, that would be fine and you're welcome to your opinions. 
  Other people disagree because it doesn't make sense on their deployments.

Nick

---

From: Mark Smith <[email-masked]>
Date: Thu, 30 Sep 2021 07:34:38 +1000

"Laughable", "sad"?

Not worth a response.

---

From: Mark Smith <[email-masked]>
Date: Thu, 30 Sep 2021 08:15:37 +1000

> https://mailarchive.ietf.org/arch/msg/ipv6/NMWxPx3QEFNmUC1-kGuwyyNrRdw/

That's perfectly consistent with that.

Deprecating DHCPv6 is removing a dependency.

See RFC1925 truth 12.

>   Other people disagree because it doesn't make sense on their deployments.

If they want to hobble IPv6, such that it is nothing more than a copy of
IPv4 with bigger addresses, what is the point of going to the expense and
effort of deploying IPv6 when most enterprises have plenty of IPv4 address
space via RFC1918 and 100.64/10 if they were willing to abuse it a bit?

A hobbled deployment of IPv6, hobbled such that it doesn't provide any
useful benefit over IPv4, is just pure business expense. Increased profit
is an exceptionally strong disincentive to incurring those.

Regards,
Mark.

---

From: David Farmer <[email-masked]>
Date: Wed, 29 Sep 2021 21:14:46 -0500

> is an exceptionally strong disincentive to incurring those.

So, instead of just telling people they are doing IPv6 wrong (building a
hobbled network) and that DHCP doesn't provide them what they think it
does; How about making sure there are good open-source tools to build what
you think is a non-hobbled network that meets their needs? In other words,
how about providing some good open-source ARP and ND router scraping tools?

Now you could point the finger back at me too, but then I'm not saying that
building networks with DHCPv6 is building a hobbled network, nor am I
refusing to provide a DHCPv6 client for a very popular mobile and IoT
platform. So, at least in my opinion, that puts more onus on you than me.

So, I agree that DHCP logging (both IPv4 and IPv6) by itself isn't enough,
and yes you also need to scrape ARP and ND out of the routers. However, ARP
and ND scrapping by themselves aren't enough either, DHCP logging provides
much better granularity than is practical from ARP and ND scrapping, at
least using SNMP. Also, by having both you can make some assumptions about
suspicious access clients that are statically configuring addresses instead
of doing DHCP on the access network as they should be.

I agree that limiting DHCPv6 clients to only IA-NA  and not providing IA-TA
is a bad implementation of DHCPv6. Further, I recommend SLAAC, and we
provide SLAAC, for general-purpose (AKA public) access networks with IPv6.
But, we also have many networks where that is not appropriate, where I have
regulatory and contractual compliance requirements, to protect non-public
information, things like FERPA, HIPPA, PCI, and CMMC(1-4). Long-term we
want these networks doing IPv6 too.

Android smartphones, probably belong on a general-purpose access network
with SLAAC for IPv6 in most cases. However, Android is also on many IoT
devices, things like point-of-sale terminals, credit card terminals,
environmental monitoring sensors, etc... Many of those things I don't want
on general-purpose access networks and some of those will have compliance
requirements we have to meet. We think DHCPv6 is perfectly appropriate for
these networks, and probably for server networks too.

In conclusion, while I agree with most of your arguments that DHCPv6 isn't
necessarily the right way to do IPv6, especially for general-purpose
(public) access networks, that doesn’t mean I think DHCPv6 doesn’t have a
place in many other networks, and it would be very helpful if Android
provided a DHCPv6 client, even as a non-default option.

Thanks

---

From: Owen DeLong <[email-masked]>
Date: Wed, 29 Sep 2021 19:16:05 -0700

> On Sep 29, 2021, at 15:15 , Mark Smith <[email-masked]> wrote:
> 
> 
> 
> On Thu, 30 Sep 2021, 03:41 Nick Hilliard, <[email-masked] <mailto:[email-masked]>> wrote:
> https://mailarchive.ietf.org/arch/msg/ipv6/NMWxPx3QEFNmUC1-kGuwyyNrRdw/ <https://mailarchive.ietf.org/arch/msg/ipv6/NMWxPx3QEFNmUC1-kGuwyyNrRdw/>
> 
> 

It’s also completely ignorant of the reality of the human factors problems it will create.

In most large companies, the folks who control the routers are the “networking team”.
The folks who control host configuration, OTOH, are mostly the “corporate IT team”.
In many (if not most, certainly every large organization I’ve experienced) such
enterprises, there is significant tribalism, mutual distrust and a good does of mutual
disrespect between these two teams.

Despite the extent to which the IT Team is already objecting to the inability to control
FHR details on the hosts they administer due to the interaction between RA and DHCPv6,
you now want to further propose that they lose even more control over host configuration
and move more of those details into routers.

It may remove a technical dependency in theory, but it’s going to create a political mess
that will even further deploy IPv6 in many such organizations.

> If they want to hobble IPv6, such that it is nothing more than a copy of IPv4 with bigger addresses, what is the point of going to the expense and effort of deploying IPv6 when most enterprises have plenty of IPv4 address space via RFC1918 and 100.64/10 if they were willing to abuse it a bit?

IPv6 with working DHCPv6 for environments that want it is still quite a bit more than a copy of IPv4 with bigger addresses.

Nonetheless, restoring the e2e addressing model and true peer-to-peer networking _IS_, in fact, worth the effort and expense IMHO.

Even with NAT, IPv4 will hit some scaling limits in the address space eventually. It’s not entirely clear how many of the 16 bits available in port numbers can be added to IPv4 addresses to pretend they’re bigger (which is what NAT effectively does), but even if we assume we can get up to 8 of them, that’s still not likely to be enough IPv4 to survive long term.

> A hobbled deployment of IPv6, hobbled such that it doesn't provide any useful benefit over IPv4, is just pure business expense. Increased profit is an exceptionally strong disincentive to incurring those.

Contrary to your rhetoric, adding DHCPv6 as an option administrators can choose for their networks does NOT hobble IPv6.

Contrary to your rhetoric, adding DHCPv6 as an option administrators can choose to deploy or not WILL remove a disincentive that currently exists for deploying IPv6.

You’ve got multiple operators with real world networks telling you this and yet you still try to pretend that because their idea of networking doesn’t conform to your preconceived notions of how they SHOULD want to do it, they’re simply wrong and should be dismissed.

It is this kind of belligerent rhetoric that gives IPv6 a bad name and makes it hard to gain traction.

Owen

---

From: Lorenzo Colitti <[email-masked]>
Date: Thu, 30 Sep 2021 14:42:40 +0900

On Wed, Sep 29, 2021 at 1:01 AM STARK, BARBARA H <[email-masked]> wrote:

> I’m not aware of widely-deployed equipment that supports good RADIUS/RA
> integration for similar device configuration via RA.
>

ISTR building a network that did this circa 2011, but it was not enterprise
hardware, it was a Juniper BNG. It supported dynamic VLAN creation based on
first-sign-of-life (or maybe RS), and got prefix information from RADIUS:
Framed-IPv6-Prefix for the PIO in the RA, Delegated-IPv6-Prefix for
subsequent PD requests.

> <bhs> I mostly agree. Unfortunately, some governments are putting
> pressure on enterprises and government networks (which are just a type of
> enterprise network) to support IPv6. This is largely due to messaging
> coming from the IETF. Maybe IETF should produce a Best Practice
> recommendation that enterprise and government networks not support IPv6
> until all tools they need to properly secure an IPv6-enabled network are
> widely available as software updates to legacy equipment.
>

Do you actually think it's the equipment that's the issue here? Even if the
equipment isn't capable of logging neighbour table bindings via syslog
(which most vendors have for a while), scraping ND tables isn't that hard
to do. I think the issue is more around operational familiarity and the
idea that because we do things this way in IPv4 we must to do them the same
way in IPv6 as well.

---

From: Lorenzo Colitti <[email-masked]>
Date: Thu, 30 Sep 2021 14:53:22 +0900

> So, still no IPv6 today...

Is there any other way to break this logjam than to implement DHCPv6 IA_NA
and accept one IPv6 address per device? What about DHCPv6 PD or
/64-per-host? What about resurrecting draft-ietf-dhc-addr-registration
<https://datatracker.ietf.org/doc/draft-ietf-dhc-addr-registration/>, so
the device can inform the network of addresses it has created?

---

From: Mark Smith <[email-masked]>
Date: Thu, 30 Sep 2021 16:18:59 +1000

> the device can inform the network of addresses it has created?

GRAND will do that for all address types and address generation methods.

https://datatracker.ietf.org/doc/html/draft-ietf-6man-grand-07

---

From: [email-masked]
Date: Thu, 30 Sep 2021 08:20:06 +0200 (CEST)

> the device can inform the network of addresses it has created?

We would love to use IA_PD only, and no IA_NA. Having DHCPv6 PD for
Android would be a significant step in that direction.

Steinar Haug, AS2116

---

From: Gert Doering <[email-masked]>
Date: Thu, 30 Sep 2021 09:00:47 +0200

Hi,

> is an exceptionally strong disincentive to incurring those.

The main benefit of IPv6 is "more addresses".

All the rest is wishful thinking, some of it delusional (like "unlimited
chains of extention headers are beneficial" or "ND is better than ARP,
because, multicast").

Said enterprise network has completely allocated all RFC1918 space plus
a significant amount of public IPv4 space to internal deployments - stuff
like Kubernetes clusters with a rigid addressing structure to be able to
scale hosts/pods as needed eat a full /16 per cluster.  So RFC1918 is not
exactly "many addresses" in such an environment.

Which leads to duplicate use of certain parts of 10.x, and *that* leads
to double-NAT "solutions", and generally waste of human lifetime to keep
it running.

IPv6 in "it just works and has more addresses" can solve this just fine,
and that is a good argument for enterprise to invest in IPv6.

Religion, politics, and "nah, you can't do that, because we think it's
not good for you" leads to "okay, then we'll not do IPv6, fine, we have
no time to rebuild all our networks anyway, postponed to 2025".

Gert Doering
        -- NetMaster

---

From: Gert Doering <[email-masked]>
Date: Thu, 30 Sep 2021 09:06:03 +0200

Hi,

> Android would be a significant step in that direction.

IA_PD in which context?  LTE networks, DSL networks, or "general purpose
enterprise network"?

This thread seems to be jumping around quite a bit, so I try to understand
your requirements.

(I can see IA_PD in LTE and DSL networks, and I understand that some
people want it in "general purpose wifi networks", but I do not see that
as a reasonable requirement for normal people's devices)

Gert Doering
        -- NetMaster

---

From: Lorenzo Colitti <[email-masked]>
Date: Thu, 30 Sep 2021 16:06:45 +0900

On Thu, Sep 30, 2021 at 11:16 AM Owen DeLong <owen=
[email-masked]> wrote:

> Nonetheless, restoring the e2e addressing model and true peer-to-peer
> networking _IS_, in fact, worth the effort and expense IMHO.
>

Owen, I think you need to realize that IPv6 by itself does not provide
end-to-end addressing. It only provides end-to-end addressing *if
sufficient addresses are available*, and if *it's possible to inform
devices of network configuration changes*. DHCP as currently managed and
deployed is terrible at both those things. Yes, I know it's possible to
*sort of* make DHCPv6 do this via reconfigure, multiple DUIDs, etc., but
current implementations and operational models do not do this.

As for network changes - sure, it's possible to ensure that things don't
change, like an enterprise network that uses PI space.

But as for sufficient addresses... as you said yourself in this thread,
(some) operators want to use DHCPv6 in order to ensure a single address per
device. This will *not* result in end-to-end connectivity. It will result
in the device getting that single address running NAT66 and and and all the
other functions inside that device or connected to it getting private IPv6
addresses and non-end-to-end connectivity. We tried to write this down in RFC
7934 sections 3 and 4
<https://datatracker.ietf.org/doc/html/rfc7934#section-3>.

So again: if all we're getting from the transition to IPv6 is 128-bit IPv4
with NAT, then why bother?

---

From: Owen DeLong <[email-masked]>
Date: Thu, 30 Sep 2021 00:10:33 -0700

> On Sep 29, 2021, at 22:53 , Lorenzo Colitti <lorenzo=[email-masked]> wrote:
> 
> On Wed, Sep 29, 2021 at 3:40 AM Gert Doering <[email-masked] <mailto:[email-masked]>> wrote:
> Is there any other way to break this logjam than to implement DHCPv6 IA_NA and accept one IPv6 address per device? What about DHCPv6 PD or /64-per-host? What about resurrecting draft-ietf-dhc-addr-registration <https://datatracker.ietf.org/doc/draft-ietf-dhc-addr-registration/>, so the device can inform the network of addresses it has created?

DHCPv6 PD is fine and environments where having the phone act like a router is desirable will probably be willing to do that.

That’s already there on the server side, but they’re still going to want IA_NA for the LAN connection side of it.

I don’t think there’s any way forward that doesn’t require implementing DHCPv6 IA_NA. There’s just too much momentum behind it in the enterprise from the IPv4-based expectations.

It also doesn’t help that any additional options in RA (which are mostly a bad idea anyway as RA was supposed to be very lightweight) wouldn’t be administered by the people who administer the DHCP servers in IPv4 in most enterprises.

The teams that normally administer the host configurations through DHCPv4 options aren’t going to want to have to open tickets with the networking team to get those options set up in RA, they’re going to want to administer them via DHCPv6 directly.

Owen

---

From: Vasilenko Eduard <[email-masked]>
Date: Thu, 30 Sep 2021 07:12:20 +0000

+1.
“Show me another solution” is a good message. Just idea or theory is not enough.
David has mentioned OpenSource. I would say that vendor product is needed too.
Ed/
From: v6ops [mailto:[email-masked]] On Behalf Of David Farmer
Sent: Thursday, September 30, 2021 5:15 AM
To: Mark Smith <[email-masked]>; Lorenzo Colitti <[email-masked]>
Cc: v6ops list <[email-masked]>
Subject: Re: [v6ops] Implementation Status of PREF64

On Wed, Sep 29, 2021 at 5:16 PM Mark Smith <[email-masked]<mailto:[email-masked]>> wrote:

On Thu, 30 Sep 2021, 03:41 Nick Hilliard, <[email-masked]<mailto:[email-masked]>> wrote:

So, instead of just telling people they are doing IPv6 wrong (building a hobbled network) and that DHCP doesn't provide them what they think it does; How about making sure there are good open-source tools to build what you think is a non-hobbled network that meets their needs? In other words, how about providing some good open-source ARP and ND router scraping tools?

Now you could point the finger back at me too, but then I'm not saying that building networks with DHCPv6 is building a hobbled network, nor am I refusing to provide a DHCPv6 client for a very popular mobile and IoT platform. So, at least in my opinion, that puts more onus on you than me.

So, I agree that DHCP logging (both IPv4 and IPv6) by itself isn't enough, and yes you also need to scrape ARP and ND out of the routers. However, ARP and ND scrapping by themselves aren't enough either, DHCP logging provides much better granularity than is practical from ARP and ND scrapping, at least using SNMP. Also, by having both you can make some assumptions about suspicious access clients that are statically configuring addresses instead of doing DHCP on the access network as they should be.

I agree that limiting DHCPv6 clients to only IA-NA  and not providing IA-TA is a bad implementation of DHCPv6. Further, I recommend SLAAC, and we provide SLAAC, for general-purpose (AKA public) access networks with IPv6. But, we also have many networks where that is not appropriate, where I have regulatory and contractual compliance requirements, to protect non-public information, things like FERPA, HIPPA, PCI, and CMMC(1-4). Long-term we want these networks doing IPv6 too.

Android smartphones, probably belong on a general-purpose access network with SLAAC for IPv6 in most cases. However, Android is also on many IoT devices, things like point-of-sale terminals, credit card terminals, environmental monitoring sensors, etc... Many of those things I don't want on general-purpose access networks and some of those will have compliance requirements we have to meet. We think DHCPv6 is perfectly appropriate for these networks, and probably for server networks too.

In conclusion, while I agree with most of your arguments that DHCPv6 isn't necessarily the right way to do IPv6, especially for general-purpose (public) access networks, that doesn’t mean I think DHCPv6 doesn’t have a place in many other networks, and it would be very helpful if Android provided a DHCPv6 client, even as a non-default option.

Thanks

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

---

From: Lorenzo Colitti <[email-masked]>
Date: Thu, 30 Sep 2021 16:16:32 +0900

There are already vendor solutions.

https://theinternetprotocolblog.wordpress.com/2020/03/14/does-one-need-dhcpv6/

On Thu, Sep 30, 2021 at 4:12 PM Vasilenko Eduard <
[email-masked]> wrote:

> *From:* v6ops [mailto:[email-masked]] *On Behalf Of *David Farmer
> *Sent:* Thursday, September 30, 2021 5:15 AM
> *To:* Mark Smith <[email-masked]>; Lorenzo Colitti <
> [email-masked]>
> *Cc:* v6ops list <[email-masked]>
> *Subject:* Re: [v6ops] Implementation Status of PREF64
>
>
>
>
>
> Now you could point the finger back at me too, but then I'm not saying
> that building networks with DHCPv6 is building a hobbled network, nor am I
> I agree that limiting DHCPv6 clients to only IA-NA  and not providing
> IA-TA is a bad implementation of DHCPv6. Further, I recommend SLAAC, and we

---

From: Ola Thoresen <[email-masked]>
Date: Thu, 30 Sep 2021 09:30:00 +0200

> as a reasonable requirement for normal people's devices)

Can't speak on Steinars behalf, but today, with so many applications 
being run as containers, simple and easy to use virtualization 
platforms, internet sharing etc. etc. I think it is a reasonable 
requirement for normal peoples devices to be able to get i buch of 
prefixes that can be assigned to docker networks, VMs, shared access and 
so on.

I would really like my laptop to do a PD-request when VirtualBox starts 
up, or when I start Podman or Docker etc.

Rgds.

/Ola (T)

---

From: Gert Doering <[email-masked]>
Date: Thu, 30 Sep 2021 09:32:44 +0200

Hi,

> up, or when I start Podman or Docker etc.

And this, in particular, is not something "normal people" do on their
Laptops.

I can see that geeks want this.

("shared access" is more the LTE/DSL category again, not so much
"connect to a general purpose network")

Gert Doering
        -- NetMaster

---

From: Ola Thoresen <[email-masked]>
Date: Thu, 30 Sep 2021 09:41:56 +0200

> I can see that geeks want this.

Well. I know a lot of people (including people from Microsoft) are 
promoting also running regular windows desktop apps as containers.

But also anyone working with development, creating "cloud applications" 
etc. would benefit from this.  Whether they are "geeks" or not just 
because they are developers might be a fun discussion over a beer 
sometime...

-- 

Ola Thoresen
nLogic AS

---

From: Owen DeLong <[email-masked]>
Date: Thu, 30 Sep 2021 00:53:36 -0700

> On Sep 30, 2021, at 00:06 , Lorenzo Colitti <lorenzo=[email-masked]> wrote:
> 
> On Thu, Sep 30, 2021 at 11:16 AM Owen DeLong <owen=[email-masked] <mailto:[email-masked]>> wrote:
> Owen, I think you need to realize that IPv6 by itself does not provide end-to-end addressing. It only provides end-to-end addressing if sufficient addresses are available, and if it's possible to inform devices of network configuration changes. DHCP as currently managed and deployed is terrible at both those things. Yes, I know it's possible to *sort of* make DHCPv6 do this via reconfigure, multiple DUIDs, etc., but current implementations and operational models do not do this.

It inherently provides E2E address transparency so long as nobody sticks packet header mutilation (i.e. NAT) in the path.

I understand that there are things you don’t like about DHCPv6, but what you aren’t getting here is that no matter how good or bad those things are, they are what some institutions want and they  WILL NOT DEPLOY IPv6 without IA_NA period.

What you want to allow or not on your own network is fine, but you’re a device manufacturer with significant market share. The fact that you’re holding the entire industry hostage to your personal attitudes by telling people what capabilities they can’t have if they want your devices on their network is going to lead to one of two eventualities and neither of them is the one you want…

1. Enterprises will simply continue to stall on IPv6 until there’s android support.
or
2. Enterprises will simply start selling their android users “too bad, so sad, your device won’t work with our network, get something with proper IPv6 support.”

> As for network changes - sure, it's possible to ensure that things don't change, like an enterprise network that uses PI space.

And there are precisely a lot of enterprises in that boat.

> But as for sufficient addresses... as you said yourself in this thread, (some) operators want to use DHCPv6 in order to ensure a single address per device. This will not result in end-to-end connectivity. It will result in the device getting that single address running NAT66 and and and all the other functions inside that device or connected to it getting private IPv6 addresses and non-end-to-end connectivity. We tried to write this down in RFC 7934 sections 3 and 4 <https://datatracker.ietf.org/doc/html/rfc7934#section-3>.

In the networks that choose to implement it that way, so be it. Frankly, for all practical purposes from the outside perspective, that’s still e2e. There aren’t multiple devices behind that device with whatever crazy NAT scheme is going on in the device (which, frankly, makes little sense and won’t really help anything), so since one address identifies the correct device in a transparent manner, that’s most of what most people care about from an E2E perspective.

As to sections 3 and 4 of RFC7934, I’ll answer as follows:

	Privacy addressing is a myth. It really doesn’t prevent tracking, it just moves it up the stack.

	Multiple processors share addresses on lots of systems without NAT, so it’s not clear to me why this doesn’t work
	The current IWLAN spec is here: 24327-c00.zip <https://www.3gpp.org/ftp/Specs/archive/24_series/24.327/24327-c00.zip> btw. Perhaps I’m misunderstanding the spec, but it looks like
	the application processor would mostly be talking through the tunnel using addresses provided for the tunnel
	interior by its home agent. In that case, it’s not really an issue. However, simultaneous attachment and/or
	roaming between MIPv6 and the corporate LAN is considered undesirable by a number of enterprise security
	departments, so disabling this functionality isn’t exactly viewed as a bad thing in the very cases we are
	discussing.

	For tethering, I think we can all agree that IA_PD is preferable. The handset is a router at that point.

	Most enterprises aren’t wild about supporting random hypervisors they don’t control, so again, disabling
	this capability is viewed as a feature, not a bug in those environments.

	Enterprises that are deploying DHCPv6 are most likely to run dual stack. I think that the tradeoff of
	either DHCPv6 IA_NA single address _OR_ 464XLAT is one administrators can make an informed
	decision about on a network by network basis.

	ILA is a draft which expired in 2017.

	I think that administrators can make an informed decision between whether or not they wish to support
	things like TARP or per-application IPv6 addresses. I don’t think an equipment vendor should be making that
	decision for them.

	DHCPv6 PD is widely available and 3GPP release 10+ is sufficiently widely deployed that I think this concern
	is obsolete.

For section 4:

	These may be valid tradeoffs, but they’re choices that the network administrator should make,
	not something where an equipment vendor should substitute their judgment for the network administrator’s.

	The added latency for provisioning an address via DHCP vs. SLAAC is almost zero and in some cases,
	DHCPv6 can be faster due to the lack of need for DAD.

	In general, the provisioning operation in question will occur at network attachment time anyway and in
	the environments where this is a concern, a self-assigned address isn’t going to get anywhere until the
	provisioning function completes anyway. As such, this doesn’t really provide any additional problems.

	We deal with failures of DHCP in dhcpv4 today and there’s the same challenge if you don’t get an RA
	in response to your RS or if DAD fails too many times or… The alleged increase in complexity is a stretch
	at best.

	The goals of the concluding paragraph of section 4 are laudable, but they ignore some of the other
	reasons that many enterprise networks want to have greater control and accountability on addressing
	that can be achieved with SLAAC, RFC4941, etc.

	It also ignores the possibility of providing additional host configuration information and/or requirements
	via DHCP options that simply cannot be achieved with SLAAC.

> So again: if all we're getting from the transition to IPv6 is 128-bit IPv4 with NAT, then why bother?

Because we need more addresses and it won’t be 128-bit IPv4 with NAT in reality.

In IPv4 with NAT, a single address identifies god-only-knows how many hosts.

At the worst in the scenario you describe, that would only be true with tethering where IA_PD was not
supported, which should be mostly rare. For all other situations, even if there is NAT, it still only identifies
a single physical host, even if there are VMs behind the NAT (and hopefully there aren’t because chances
are that if the network administrators wanted to allow handsets running hypervisors on their WLAN, they’d
be issuing multiple addresses to the handset).

Bottom line, the potential harms described in RFC-7934 are vastly outweighed by the harms of the
deployment delays being caused by android’s lack of IA_NA support.

Further bottom line, appeasing the environments that want this will not cause the vast majority
of other environments to suddenly run DHCPv6 in preference to SLAAC. Where SLAAC meets the
need, nobody is going to go to the trouble of implementing a DHCPv6 server.

Owen

---

From: Lorenzo Colitti <[email-masked]>
Date: Thu, 30 Sep 2021 17:05:50 +0900

> need, nobody is going to go to the trouble of implementing a DHCPv6 server.

Actually it will be the opposite. Everybody in the industry knows DHCP and
understands the pull/refresh model. In the absence of a counterweight, that
model will end up being used everywhere. In my experience, folks suggest
disabling SLAAC at the first sign of problems caused by the operator
assuming the pull model... unless disabling SLAAC it breaks some real
functionality. I've seen this happen quite often, for many reasons (driver
bugs, firmware bugs, wireless controller bugs, etc).

---

From: Fernando Gont <[email-masked]>
Date: Thu, 30 Sep 2021 05:28:12 -0300

On 30/9/21 02:42, Lorenzo Colitti wrote:
[...]
>
> Do you actually think it's the equipment that's the issue here? Even if
> the equipment isn't capable of logging neighbour table bindings via
> syslog (which most vendors have for a while), scraping ND tables isn't
> that hard to do. I think the issue is more around operational
> familiarity and the idea that because we do things this way in IPv4 we
> must to do them the same way in IPv6 as well.

When you are dealing with a pile of work/issues/problems, this logic is
exactly what leads to "there's no way I'm going to deploy IPv6".

Thanks,

---

From: Fernando Gont <[email-masked]>
Date: Thu, 30 Sep 2021 05:32:44 -0300

On 30/9/21 02:53, Lorenzo Colitti wrote:
> Is there any other way to break this logjam than to implement DHCPv6
> IA_NA and accept one IPv6 address per device? What about DHCPv6 PD or

Part of the problem here is the assumption that in all scenarios hosts
are and/or should be free to choose.

The reality is that, in a corporate network, "my network, my rules". --
that also applies to SLAAC -- just not gracefully -- since network
devices can limit the number of addresses per device.

SLAAC can be nice ("good" or "doable") for many scenarios. But there are
certainly others where the admin or security team wants to apply policy.
And SLAAC doesn't play nice there....

---

From: "Pascal Thubert (pthubert)" <[email-masked]>
Date: Thu, 30 Sep 2021 08:43:15 +0000

There is, Lorenzo,

and strangely enough to me you are still opposing the technical evolution of SLAAC that would make them to be fully efficient – RFC 8505<https://datatracker.ietf.org/doc/html/rfc8505>.

I see that our support of First Hop Security (that includes snooping) is explicitly cited in that article. RFC 8505 solves the corner case of snooping, e.g., silent nodes which the article inelegantly ignores but are a real issue when you do not have DHCP to provide a complete state.

If needed the infra could easily republish an RFC 8505 registration to that resurrected draft-ietf-dhc-addr-registration<https://datatracker.ietf.org/doc/draft-ietf-dhc-addr-registration/> that you suggest as we do for LISP today, but we foresee a more distributed registrar, e.g., with eVPN (draft-thubert-bess-secure-evpn-mac-signaling)<https://datatracker.ietf.org/doc/html/draft-thubert-bess-secure-evpn-mac-signaling-00>.

RFC 8505 allows the device to configure any address it likes as long as it’s not duplicate. It is an alternative from DHCP where the host is still in control of its addresses; it’s still autoconf, but made stateful. It is less work on the host that already has SLAAC than implementing draft-ietf-dhc-addr-registration<https://datatracker.ietf.org/doc/draft-ietf-dhc-addr-registration/> as you suggest in you other mail.

I’m still baffled and sad that we are not working together on making this happen in a demo.

Keep safe;

Pascal

From: v6ops <[email-masked]> On Behalf Of Lorenzo Colitti
Sent: jeudi 30 septembre 2021 9:17
To: Vasilenko Eduard <[email-masked]>
Cc: v6ops list <[email-masked]>; David Farmer <farmer=[email-masked]>
Subject: Re: [v6ops] Implementation Status of PREF64

On Thu, Sep 30, 2021 at 4:12 PM Vasilenko Eduard <[email-masked]<mailto:[email-masked]>> wrote:
+1.
“Show me another solution” is a good message. Just idea or theory is not enough.
David has mentioned OpenSource. I would say that vendor product is needed too.
Ed/
From: v6ops [mailto:[email-masked]<mailto:[email-masked]>] On Behalf Of David Farmer
Sent: Thursday, September 30, 2021 5:15 AM
To: Mark Smith <[email-masked]<mailto:[email-masked]>>; Lorenzo Colitti <[email-masked]<mailto:[email-masked]>>
Cc: v6ops list <[email-masked]<mailto:[email-masked]>>
Subject: Re: [v6ops] Implementation Status of PREF64

Thanks

---

From: Lorenzo Colitti <[email-masked]>
Date: Thu, 30 Sep 2021 18:16:27 +0900

Pascal,

>From what's been said so far on this thread, do you think that an
implementation would achieve anything? Many of the posts here say things
like, "my network, my rules", and "this network has a policy of requiring
DHCPv6". Would be interested in seeing whether any of the folks on this
thread who are saying that Android should implement DHCPv6 support your
proposal, since it's obviously not DHCPv6. :-)

I'm all for finding another solution to this problem, but given some of the
messages on this thread it doesn't look like there's much room for
compromise.

Cheers,
Lorenzo

On Thu, Sep 30, 2021 at 5:43 PM Pascal Thubert (pthubert) <pthubert=
[email-masked]> wrote:

> There is, Lorenzo,
>
>
>
> and strangely enough to me you are still opposing the technical evolution
> of SLAAC that would make them to be fully efficient – RFC 8505
> <https://datatracker.ietf.org/doc/html/rfc8505>.
>
>
>
> I see that our support of First Hop Security (that includes snooping) is
> explicitly cited in that article. RFC 8505 solves the corner case of
> snooping, e.g., silent nodes which the article inelegantly ignores but are
> a real issue when you do not have DHCP to provide a complete state.
>
>
>
> If needed the infra could easily republish an RFC 8505 registration to
> that resurrected draft-ietf-dhc-addr-registration
> <https://datatracker.ietf.org/doc/draft-ietf-dhc-addr-registration/> that
> you suggest as we do for LISP today, but we foresee a more distributed
> registrar, e.g., with eVPN (draft-thubert-bess-secure-evpn-mac-signaling)
> <https://datatracker.ietf.org/doc/html/draft-thubert-bess-secure-evpn-mac-signaling-00>
> .
>
>
>
> RFC 8505 allows the device to configure any address it likes as long as
> it’s not duplicate. It is an alternative from DHCP where the host is still
> in control of its addresses; it’s still autoconf, but made stateful. It is
> less work on the host that already has SLAAC than implementing
> draft-ietf-dhc-addr-registration
> <https://datatracker.ietf.org/doc/draft-ietf-dhc-addr-registration/> as
> you suggest in you other mail.
>
>
>
> *From:* v6ops <[email-masked]> *On Behalf Of *Lorenzo Colitti
> *Sent:* jeudi 30 septembre 2021 9:17
> *To:* Vasilenko Eduard <[email-masked]>
> *Cc:* v6ops list <[email-masked]>; David Farmer <farmer=
> [email-masked]>

---

From: Vasilenko Eduard <[email-masked]>
Date: Thu, 30 Sep 2021 10:03:47 +0000

Hi Lorenzo,
Sorry, but this URL has no reference to the product or OpenSource that is capable to collect ND logs from the wide range of routers (multi-vendor!), correlate them, and present them for forensic, billing, or troubleshooting purposes.
No one vendor or developer of OpenSource spends resources behind your idea.
What you propose is just not possible to implement in production now.
Why these people do not believe you?
You would not go anywhere with your idea if you would not persuade them (especially Infoblox as the leader).
The first question that they would have to you may be: show me the YANG model to provision boxes and show me the data model for statistics that they would generate?
Ups, it is proprietary for all vendors…

IMHO: no chance that your idea would fly if it would not have any DDI product that supports it.
Eduard
From: Lorenzo Colitti [mailto:[email-masked]]
Sent: Thursday, September 30, 2021 10:17 AM
To: Vasilenko Eduard <[email-masked]>
Cc: David Farmer <farmer=[email-masked]>; Mark Smith <[email-masked]>; v6ops list <[email-masked]>
Subject: Re: [v6ops] Implementation Status of PREF64

Thanks

---

From: "Pascal Thubert (pthubert)" <[email-masked]>
Date: Thu, 30 Sep 2021 10:14:15 +0000

I have the same perception of that thread and the IPv6 woes one on NANOG as you do. For one thing we cannot extract DHCPv6 brutally as a rotten tooth.
We need to understand what it’s used for and provide a better replacement that will slowly take over. SLAAC cannot be that. The problem of SLAAC is not the AAC piece, it’s the SL. SL lacks observability, and that’s what prevent it from being a replacement to the database that the operators and network managers need, e.g., for forensics.

I think there’s a golden path where DHCP is pushed deeper in the infra so that at first it is no more visible to the end device but still available to the operations that require it, and then we move on to the point where it becomes fully redundant and ceases to exist, by the user’s own decision, on his own agenda.

The network beyond the first hop has evolved tremendously, and we want to keep the host agnostic for the most part. RFC 8505 goes a lot way to signal things that the modern back ends (wireless, overlays) need to routing and proxying.

I just published how it can replace MLD to avoid the related multicast (https://datatracker.ietf.org/doc/draft-thubert-6lo-multicast-registration/) and that request actually came from outside the IETF and real world deployments. Note that RFC 8505 does not use MLD as it does not use the SNMA, but MLD is still a source of multicast that can be saved on the link and complexity in the stack.

If we need more, I’m happy to work on the more complete set with you all.

Keep safe;

Pascal

From: Lorenzo Colitti <lorenzo=[email-masked]>
Sent: jeudi 30 septembre 2021 11:16
To: Pascal Thubert (pthubert) <[email-masked]>
Cc: Vasilenko Eduard <[email-masked]>; v6ops list <[email-masked]>; David Farmer <[email-masked]>
Subject: Re: [v6ops] Implementation Status of PREF64

Pascal,

From what's been said so far on this thread, do you think that an implementation would achieve anything? Many of the posts here say things like, "my network, my rules", and "this network has a policy of requiring DHCPv6". Would be interested in seeing whether any of the folks on this thread who are saying that Android should implement DHCPv6 support your proposal, since it's obviously not DHCPv6. :-)

I'm all for finding another solution to this problem, but given some of the messages on this thread it doesn't look like there's much room for compromise.

Cheers,
Lorenzo

On Thu, Sep 30, 2021 at 5:43 PM Pascal Thubert (pthubert) <pthubert=[email-masked]<mailto:[email-masked]>> wrote:
There is, Lorenzo,

Keep safe;

Pascal

From: v6ops <[email-masked]<mailto:[email-masked]>> On Behalf Of Lorenzo Colitti
Sent: jeudi 30 septembre 2021 9:17
To: Vasilenko Eduard <[email-masked]<mailto:[email-masked]>>
Cc: v6ops list <[email-masked]<mailto:[email-masked]>>; David Farmer <farmer=[email-masked]<mailto:[email-masked]>>
Subject: Re: [v6ops] Implementation Status of PREF64

Thanks

---

From: Nick Hilliard <[email-masked]>
Date: Thu, 30 Sep 2021 13:22:47 +0100

> That's perfectly consistent with that.

in fairness, it's entirely inconsistent.  PVD support depends on 
provisioning servers.  DHCPv6 depends on provisioning servers.  Both 
involve external dependencies.  Incidentally, so does 802.1x.

This one-sided fascination with the reliability of certain types of 
external dependencies (e.g. dhcpv6 servers) but obliviousness in 
relation to others (dot1x auth servers / pvd servers) is quite peculiar.

Nick

---

From: Nick Hilliard <[email-masked]>
Date: Thu, 30 Sep 2021 14:05:25 +0100

> must to do them the same way in IPv6 as well.

if this is a serious proposal, it would be great if you could write up a 
draft and circulate it in v6ops.

Nick

---

From: Mark Smith <[email-masked]>
Date: Thu, 30 Sep 2021 23:27:50 +1000

On Thu, 30 Sep 2021, 15:43 Lorenzo Colitti, <lorenzo=
[email-masked]> wrote:

> ISTR building a network that did this circa 2011, but it was not
> enterprise hardware, it was a Juniper BNG. It supported dynamic VLAN
> creation based on first-sign-of-life (or maybe RS), and got prefix
> information from RADIUS: Framed-IPv6-Prefix for the PIO in the RA,
> Delegated-IPv6-Prefix for subsequent PD requests.
>
>
> the equipment isn't capable of logging neighbour table bindings via syslog

What is the main problem IPv6 was designed to solve?

Lack of IPv4 addresses.

What problem don't many enterprises have since they're using RFC1918s, and
could misuse 100.64/10 if they really need to get more.

Most enterprises don't have the main problem that IPv6 is designed to solve.

For IPv6 to be adopted by many enterprises, there will need to be other
reasons that are of business value.

Regards,
Mark

---

From: Chris Cummings <[email-masked]>
Date: Thu, 30 Sep 2021 09:08:05 -0500

>
> I'm all for finding another solution to this problem, but given some of
> the messages on this thread it doesn't look like there's much room for
> compromise.
>

Lorenzo, the compromise is that you stop blocking the implementation of
something that many people are asking for so that they can run their
networks as they see fit, and leave the decision on how they want to run
things up to them instead of forcing the decision onto them based off of
your beliefs about how IPv6 should work. DHCPv6 doesn't need to be a
default, it just needs to be an option for people to use. Without it, I
know for a fact that v6 rollouts are slower than they need to be as I have
seen networks shrug off IPv6 because they can't use DHCP with all of their
devices (Android).

Chris Cummings

On Thu, Sep 30, 2021 at 4:17 AM Lorenzo Colitti <lorenzo=
[email-masked]> wrote:

> I'm all for finding another solution to this problem, but given some of
> the messages on this thread it doesn't look like there's much room for
> compromise.
>
> Cheers,
> Lorenzo
>
>> <https://datatracker.ietf.org/doc/draft-ietf-dhc-addr-registration/>
>> that you suggest as we do for LISP today, but we foresee a more distributed
>> So, I agree that DHCP logging (both IPv4 and IPv6) by itself isn't
>> enough, and yes you also need to scrape ARP and ND out of the routers.
>> However, ARP and ND scrapping by themselves aren't enough either, DHCP
>> logging provides much better granularity than is practical from ARP and ND
>> scrapping, at least using SNMP. Also, by having both you can make some
>> assumptions about suspicious access clients that are statically configuring
>> addresses instead of doing DHCP on the access network as they should be.
>>
>>
>>
>> In conclusion, while I agree with most of your arguments that DHCPv6
>> isn't necessarily the right way to do IPv6, especially for general-purpose

---

From: Nick Buraglio <[email-masked]>
Date: Thu, 30 Sep 2021 09:37:34 -0500

On Tue, Sep 28, 2021 at 1:40 PM Gert Doering <[email-masked]> wrote:

> > I don???t think I can agree with your comments about recommending not
> deploying in enterprise (and thus government) networks.
> >
> > In fact, I think it is key for advancing the IPv6 deployment that
> governments require it in any administration network including any
> acquisitions (hardware, software, services, links, etc.). That encourages
> the ecosystem to move on to IPv6, including enterprises that want to
> participate in government tenders.
>
With an operational hat on, I have been watching this dilema play out for
quite some time, hoping for some level of agreement or compromise. I know I
am not alone in the thinking that this is a significant impediment to IPv6
deployment, which is already a hard sell for many more conservitive
organizations. I agree with Gert, there are plenty of easy "no" answers for
"should I deploy IPv6", but this one is often cited as a technical
limitation for a reasonable number of required devices - especially since
more and more IoT-style devices are being built using Android.

>From the point of view of an operational or. planning engineer, this kind
of disagreement doesn’t matter much because of lack of support for things
that are expected - regardless of the *actual* usefulness or technical
correctness, it serves as an easy door to close which in turn results in a
significant impediment to deployment.

I have literally heard - in the last 30 days - the argument that v6 cannot
be deployed because it lacks DHCP client support for certain devices, the
largest contingency of which are Android,

which makes it inconsistent with how this facility does their host address
management.

It does not matter how the mechanics work, but they need to be consistent
at some level (and in the cases I have seen that comes down to using a
centralized management platform to dole out addressing. Tracking is a "nice
to have", but having a dual stack network that uses different allocation
mechanisms creates a prickly experience for those that need to sell the
option of using IPv6.

An absolutely *critical* piece of IPv6 deployment is management buy-in, and
telling non-technical management level folks that “we manage this one way
and that another way” is akin to saying “this is operationally more
expensive, which is a cost center, not a cost saver”, and as pointed out in
another part of this thread, a business case is *really* useful in
proposing IPv6 deployment.

I am not advocating for anything, but consistency lends itself to lower
overhead and that will get IPv6 in more places than “it works the same on
everything except this”, which clearly hasn’t been working for quite some
time.

nb

> So, still no IPv6 today...
ᐧ

---

From: Kevin Myers <[email-masked]>
Date: Thu, 30 Sep 2021 15:11:22 +0000

You’re not alone Nick.  I’ve been reading this over the last week and thinking the same thing – this is absolutely an impediment to IPv6 adoption. As an advocate for IPv6 that implements it every day in ASNs for operators (both SP and Enterprise), the disregard for operator choice is disheartening and frustrating.

Many of the slack groups I’m in have been reading this thread and echoing the same comments. None of the publicly traded companies I consult for want anything to do with SLAAC in enterprise environments and have said they’ll keep running IPv4 until DHCPv6 is more universally available on all mobile platforms. The peers I collaborate with that also consult for the Fortune 500 crowd have said the same thing.

Lack of choice for operators does nothing to improve IPv6 adoption. The assumption that operators are making inferior technical choices is just plain wrong.  Many of the world’s largest companies are bound by regulatory environments that spent 20+ years in a DHCP world and won’t shift quickly – if ever. Technical merit will yield to organizational requirements every day of the week.

It's not just mainstream enterprise, the lack of operator choice affects other sectors we build networks in like energy, manufacturing, education and government – all with their own regulatory issues.

If the goal of dying on the hill of technical superiority was to ensure we prevent anyone other than webscale companies or cloud operators to easily deploy IPv6 in the next 10 years, I think we got there.

The last 10 years have shown that holding out for IPv4 exhaustion to force IPv6 and rigid implementation guidelines without flexibility for operators is a failed strategy and it needs to get easier or we’ll have this debate in another 10 years.

From: v6ops <[email-masked]> On Behalf Of Nick Buraglio
Sent: Thursday, September 30, 2021 9:38 AM
To: Gert Doering <[email-masked]>
Cc: V6 Ops List <[email-masked]>; JORDI PALET MARTINEZ <jordi.palet=[email-masked]>
Subject: Re: [v6ops] Implementation Status of PREF64

On Tue, Sep 28, 2021 at 1:40 PM Gert Doering <[email-masked]<mailto:[email-masked]>> wrote:
Hi,

With an operational hat on, I have been watching this dilema play out for quite some time, hoping for some level of agreement or compromise. I know I am not alone in the thinking that this is a significant impediment to IPv6 deployment, which is already a hard sell for many more conservitive organizations. I agree with Gert, there are plenty of easy "no" answers for "should I deploy IPv6", but this one is often cited as a technical limitation for a reasonable number of required devices - especially since more and more IoT-style devices are being built using Android.

From the point of view of an operational or. planning engineer, this kind of disagreement doesn’t matter much because of lack of support for things that are expected - regardless of the *actual* usefulness or technical correctness, it serves as an easy door to close which in turn results in a significant impediment to deployment.

I have literally heard - in the last 30 days - the argument that v6 cannot be deployed because it lacks DHCP client support for certain devices, the largest contingency of which are Android,

which makes it inconsistent with how this facility does their host address management.

It does not matter how the mechanics work, but they need to be consistent at some level (and in the cases I have seen that comes down to using a centralized management platform to dole out addressing. Tracking is a "nice to have", but having a dual stack network that uses different allocation mechanisms creates a prickly experience for those that need to sell the option of using IPv6.

An absolutely *critical* piece of IPv6 deployment is management buy-in, and telling non-technical management level folks that “we manage this one way and that another way” is akin to saying “this is operationally more expensive, which is a cost center, not a cost saver”, and as pointed out in another part of this thread, a business case is *really* useful in proposing IPv6 deployment.

I am not advocating for anything, but consistency lends itself to lower overhead and that will get IPv6 in more places than “it works the same on everything except this”, which clearly hasn’t been working for quite some time.

nb

Gert Doering
        -- NetMaster

---

From: Vasilenko Eduard <[email-masked]>
Date: Thu, 30 Sep 2021 15:23:16 +0000

Hi Lorenzo,
How fast is Android refreshment time? (for example, I am still using 6.2 on one device)
I mean: how much time would be needed to start adoption between your decision to support DHCPv6 and old devices would be naturally refreshed?
How long delay in Enterprise IPv6 adoption is already pre-programmed?
Eduard
From: Vasilenko Eduard
Sent: Thursday, September 30, 2021 1:06 PM
To: 'Lorenzo Colitti' <[email-masked]>
Cc: David Farmer <farmer=[email-masked]>; Mark Smith <[email-masked]>; v6ops list <[email-masked]>
Subject: RE: [v6ops] Implementation Status of PREF64

Hi Lorenzo,

Cc: David Farmer <farmer=[email-masked]<mailto:farmer=[email-masked]>>; Mark Smith <[email-masked]<mailto:[email-masked]>>; v6ops list <[email-masked]<mailto:[email-masked]>>

Thanks

---

From: Mikael Abrahamsson <[email-masked]>
Date: Thu, 30 Sep 2021 17:31:14 +0200 (CEST)

> The first question that they would have to you may be: show me the YANG model to provision boxes and show me the data model for statistics that they would generate?

https://datatracker.ietf.org/doc/html/rfc8344 contains the ND/ARP 
bindings, so subscribing to operational data changes (or periodically 
fetching it) would indeed scrape the ARP/ND tables over time.

-- 
Mikael Abrahamsson    email: [email-masked]

---

From: "Dale W. Carder" <[email-masked]>
Date: Thu, 30 Sep 2021 10:33:57 -0500

> draft and circulate it in v6ops.

from https://datatracker.ietf.org/doc/html/rfc7934

   In most aspects, the IPv6 protocol is very similar to IPv4.  This
   similarity can create a tendency to think of IPv6 as 128-bit IPv4,
   and thus lead network designers and operators to apply identical
   configurations and operational practices to both.  This is generally
   a good thing because it eases the transition to IPv6 and the
   operation of dual-stack networks.  However, in some design and
   operational areas, it can lead to carrying over IPv4 practices that
   are limiting or not appropriate in IPv6 due to differences between
   the protocols.

   One such area is IP addressing ...

Is there enough meat for a -bis document?  I don't currently believe so.

Dale

---

From: Owen DeLong <[email-masked]>
Date: Thu, 30 Sep 2021 08:41:35 -0700

> On Sep 30, 2021, at 01:05 , Lorenzo Colitti <lorenzo=[email-masked]> wrote:
> 
> On Thu, Sep 30, 2021 at 4:53 PM Owen DeLong <owen=[email-masked] <mailto:[email-masked]>> wrote:
> Actually it will be the opposite. Everybody in the industry knows DHCP and understands the pull/refresh model. In the absence of a counterweight, that model will end up being used everywhere. In my experience, folks suggest disabling SLAAC at the first sign of problems caused by the operator assuming the pull model... unless disabling SLAAC it breaks some real functionality. I've seen this happen quite often, for many reasons (driver bugs, firmware bugs, wireless controller bugs, etc).

We can agree to disagree, but multiple people are still telling you that the android stance on this
is currently delaying IPv6 deployment.

True, there may be a few environments that are running SLAAC despite a desire not to because
of android. More true, there are many environments not running IPv6 today because of android’s
refusal to support IA_NA.

I stand by my earlier statement that this will not end well if it persists.

Of the three possible outcomes, the least likely is universal acceptance of SLAAC only.
The more probable is that android becomes irrelevant or unsupported in environments that
don’t want to deploy without IA_NA and they deploy anyway.
The most likely is failure to deploy IPv6 at the enterprise level. That’s where we are today.

Only the first one is good for you.

Either of the first two work for me, frankly.

Unfortunately, the last one is the current status quo and I don’t see it changing any time soon
unless android finally supports IA_NA.

Owen

---

From: Owen DeLong <[email-masked]>
Date: Thu, 30 Sep 2021 08:49:06 -0700

Pascal’s proposal isn’t a bad idea, but it’s an entirely different use case from what is being discussed here.

Therefore, yes, I support Pascal’s proposal, but implementing it would not obviate the need for IA_NA support.

They are somewhat orthogonal issues.

Owen

> On Sep 30, 2021, at 02:16 , Lorenzo Colitti <lorenzo=[email-masked]> wrote:
> 
> Pascal,
> 
> On Thu, Sep 30, 2021 at 5:43 PM Pascal Thubert (pthubert) <pthubert=[email-masked] <mailto:[email-masked]>> wrote:
> There is, Lorenzo,
> 
>  
> 
> and strangely enough to me you are still opposing the technical evolution of SLAAC that would make them to be fully efficient – RFC 8505 <https://datatracker.ietf.org/doc/html/rfc8505>.
> 
>  
> 
> If needed the infra could easily republish an RFC 8505 registration to that resurrected draft-ietf-dhc-addr-registration <https://datatracker.ietf.org/doc/draft-ietf-dhc-addr-registration/> that you suggest as we do for LISP today, but we foresee a more distributed registrar, e.g., with eVPN (draft-thubert-bess-secure-evpn-mac-signaling) <https://datatracker.ietf.org/doc/html/draft-thubert-bess-secure-evpn-mac-signaling-00>.
> 
>  
> 
> RFC 8505 allows the device to configure any address it likes as long as it’s not duplicate. It is an alternative from DHCP where the host is still in control of its addresses; it’s still autoconf, but made stateful. It is less work on the host that already has SLAAC than implementing draft-ietf-dhc-addr-registration <https://datatracker.ietf.org/doc/draft-ietf-dhc-addr-registration/> as you suggest in you other mail.
> 
>  
> 
> To: Vasilenko Eduard <[email-masked] <mailto:[email-masked]>>
> Cc: v6ops list <[email-masked] <mailto:[email-masked]>>; David Farmer <farmer=[email-masked] <mailto:[email-masked]>>
> https://theinternetprotocolblog.wordpress.com/2020/03/14/does-one-need-dhcpv6/ <https://theinternetprotocolblog.wordpress.com/2020/03/14/does-one-need-dhcpv6/>
>  
> 
> On Thu, Sep 30, 2021 at 4:12 PM Vasilenko Eduard <[email-masked] <mailto:[email-masked]>> wrote:
> 
> +1.
> 
> From: v6ops [mailto:[email-masked] <mailto:[email-masked]>] On Behalf Of David Farmer
> To: Mark Smith <[email-masked] <mailto:[email-masked]>>; Lorenzo Colitti <[email-masked] <mailto:[email-masked]>>
> Cc: v6ops list <[email-masked] <mailto:[email-masked]>>
> On Wed, Sep 29, 2021 at 5:16 PM Mark Smith <[email-masked] <mailto:[email-masked]>> wrote:
> 
>  
>

---

From: Nick Hilliard <[email-masked]>
Date: Thu, 30 Sep 2021 16:51:33 +0100

> Is there enough meat for a -bis document?  I don't currently believe so.

the benefits and issues provided in sections 3 and 4 of this document 
are weak enough that they don't really provide enough justification for 
the document to be worth maintaining as a BCP.  From this point of view, 
a -bis would a good idea.

It would be troubling for the IETF to continue to refer to the document 
as a BCP without a substantial revision.

Nick

---

From: Owen DeLong <[email-masked]>
Date: Thu, 30 Sep 2021 08:59:07 -0700

> On Sep 30, 2021, at 03:14 , Pascal Thubert (pthubert) <pthubert=[email-masked]> wrote:
> 

It’s both, actually. The AAC side interferes with certain aspects of policy enforcement that are important in some environments.
 
> I think there’s a golden path where DHCP is pushed deeper in the infra so that at first it is no more visible to the end device but still available to the operations that require it, and then we mo…

This is the problem, right here… There are networks where the administrators do NOT WANT this to be up to the user. They want control over certain policy aspects on their network. You are free to call them whatever names you want, but their networks are part of the target audience for IPv6 and they aren’t going to deploy it unless they have at least equivalent policy enforcement tools to what they have in IPv4 and they’re going to have to be implemented in a way that provides at least some familiarity or clear roadmap of the transition.

Today, that’s IA_NA combined with other enforcement mechanisms such as NAC providing dynamic switch port ACLs. Yes, 802.1x is an L2 protocol, but contrary to earlier statements, the NAC server can pull data from multiple sources and push an ACL onto the switch port that will limit the client(s) attached to that port to the addresses and capabilities permitted by the NAC policy configured (including limiting the L3 addresses that can be forwarded to the one(s) assigned by the DHCPv6 server, if desired).

If you’ve got a better idea for enterprise-level policy enforcement than IA_NA and IA_PD (where permitted), by all means, present it.

If not, then yeah, support for IA_NA is essential to forward progress in the enterprise.

Owen

---

From: Owen DeLong <[email-masked]>
Date: Thu, 30 Sep 2021 09:19:32 -0700

> What is the main problem IPv6 was designed to solve?

Correct.

> What problem don't many enterprises have since they're using RFC1918s, and could misuse 100.64/10 if they really need to get more.
> 

Not entirely true… More accurately, many enterprises are able to pretend they don’t have this problem today because of the above.

However, eyeball providers DO have this problem and its getting worse. Further, eyeball providers are on some of the thinnest margins
and consumer IP access is at the low end of the market, so paying for more and more IPv4 addresses and more and more expensive
(and more complex) IPv4 solutions and higher support costs for those IPv4 solutions becomes a non-starter at some point.

Either consumer access in general will become significantly more expensive, or eyeball providers will start having to find a way to
surcharge IPv4 services (whether that’s in the form of an IPv4 surcharge or an overall price increase with an IPv6-only discount
or whatever).

I already know enterprises that are experiencing pain because their outsourced contractors in certain parts of the world are basically
IPv6-only already and the fact that their contractors can’t interact with the corporate network via IPv6 is causing issues.

> For IPv6 to be adopted by many enterprises, there will need to be other reasons that are of business value.

Employee/contractor connectivity is of vale to most enterprises. There’s a time coming when that’s going to require IPv6 support.

Owen

---

From: [email-masked]
Date: Thu, 30 Sep 2021 19:04:18 +0200

Owen,

> surcharge IPv4 services (whether that’s in the form of an IPv4 surcharge or an overall price increase with an IPv6-only discount

typically they only use a 1/65535th of an IPv4 address ((one TCP port) although they share it at L7).
it would certainly be possible to improve on that.

> IPv6-only already and the fact that their contractors can’t interact with the corporate network via IPv6 is causing issues.

would you have more details on that.
last time I tried going IPv6 only, that was completely unworkable.
(while doing IPv4 only is perfectly fine.)

> Employee/contractor connectivity is of vale to most enterprises. There’s a time coming when that’s going to require IPv6 support.

that's what we have been saying for 25 years.
perhaps time to accept reality. ;-)

O.

---

From: Nick Buraglio <[email-masked]>
Date: Thu, 30 Sep 2021 12:09:46 -0500

On Thu, Sep 30, 2021 at 12:04 PM <[email-masked]> wrote:

> >> What problem don't many enterprises have since they're using RFC1918s,
> and could misuse 100.64/10 if they really need to get more.
> >>
> > Not entirely true… More accurately, many enterprises are able to pretend
> they don’t have this problem today because of the above.
> >
> > However, eyeball providers DO have this problem and its getting worse.
> Further, eyeball providers are on some of the thinnest margins
> > and consumer IP access is at the low end of the market, so paying for
> more and more IPv4 addresses and more and more expensive
> > (and more complex) IPv4 solutions and higher support costs for those
> IPv4 solutions becomes a non-starter at some point.
> >
> > Either consumer access in general will become significantly more
> expensive, or eyeball providers will start having to find a way to
> > surcharge IPv4 services (whether that’s in the form of an IPv4 surcharge
> or an overall price increase with an IPv6-only discount
> > or whatever).
>
> > I already know enterprises that are experiencing pain because their
> outsourced contractors in certain parts of the world are basically
> > IPv6-only already and the fact that their contractors can’t interact
> with the corporate network via IPv6 is causing issues.
>

This is very doable now with a few caveats - I use an IPv6-only network for
my daily work and have for quite a while. The largest caveat is that for a
workstation / daily driver network an upstream NAT64/DNS64 is more or less
required for backward compatibility to legacy IP resources. However, as far
as running "IPv6-only" on the host, that's very easy on pretty much any
modern OS, and a very large amount of resources are dual stacked so the
translation requirements become less and less every day.

> > Employee/contractor connectivity is of vale to most enterprises. There’s
> a time coming when that’s going to require IPv6 support.
>
ᐧ

---

From: Gert Doering <[email-masked]>
Date: Thu, 30 Sep 2021 19:10:25 +0200

Hi,

> it would certainly be possible to improve on that.

Is that our goal?  

Make CGNAT44 solutions scale to amazeballs level, to avoid deploying IPv6?

[..]
> (while doing IPv4 only is perfectly fine.)

IPv6-only without a NAT64 gateway is not workable today.

IPv4-only is not workable either - if you need/want to access resources
that sit behind a DS-Lite ISP connection which has unhindered IPv6, and
CGNAT'ed IPv4...

[..]
> perhaps time to accept reality. ;-)

So what would that be?  "Sell more NAT boxes, give up on IPv6"?

There's certainly more money to be made, in helping panicking customers
sort out their NAT444 mess "we are losing millions every hour!"...

Gert Doering
        -- NetMaster

---

From: [email-masked]
Date: Thu, 30 Sep 2021 19:21:54 +0200

Gert,

>> it would certainly be possible to improve on that.

No, but our goal failed. So let's take stock.

> Make CGNAT44 solutions scale to amazeballs level, to avoid deploying IPv6?

The eyeball networks aren't depending on CGNAT44, they use public IPv4 addresses.
My point was that the utilisation of those IPv4 addresses could be improved by orders of magnitude, simply by using more ports than just 443.

> IPv6-only without a NAT64 gateway is not workable today.

Indeed. And if you depend on a NAT64 gateway your application has the same set of issues as if it was behind a NAT44.

> that sit behind a DS-Lite ISP connection which has unhindered IPv6, and

The DS-lite part isn't relevant here, but yes, if there is an IPv6 only service, you can only reach that from the IPv4 only host if you go through a NAT46.
Are you aware of any services like that today?

> sort out their NAT444 mess "we are losing millions every hour!"...

That's not my expertise, but my impression isn't that there is lot of money in selling more NAT boxes.
Nor is anyone panicking either.

The reality is unfortunately that NAT has benefits. Which would also be required in IPv6.
And if significant deployments still would require NAT with IPv6... the gains over IPv4 are questionable.
(For example the trend of Enterprises to tunnel their traffic to the cloud for "services". Marketing name: SASE.)

End to end is certainly dead. So as much as I'd like the purety of the IPv6 architecture, we're not going to do networking like it's 1990 again any time soon.

O.

---

From: Owen DeLong <[email-masked]>
Date: Thu, 30 Sep 2021 10:26:09 -0700

> On Sep 30, 2021, at 10:04 , [email-masked] wrote:
> 
> Owen,
> 

It’s not the inability to do IPv4, the sites in question aren’t IPv4-only, but it turns out that many VPN solutions fail utterly through CGN.

In many countries, it’s virtually impossible to do IPv4 without CGN, but you can readily get IPv6 direct and thus their VPNs to IPv6-
capable customers work while they struggle with IPv4-only customers.

Since my clients are often the IPv4-only customers in question, I see this a lot and the most workable solution is to literally deploy
at least enough IPv6 on the customer side to support the IPv6 VPN termination, even if you end up sending silly IPv4 across the
established tunnel. Usually, I’m able to convince most of my clients that it’s a good opportunity to just dual-stack the systems that
the remote contractors need to access and once IPv6 has that foot in the door and they begin to see that IPv6 isn’t so painful after
all, more complete IPv6 deployment often follows soon after.

> perhaps time to accept reality. ;-)

I can’t say how fast it’s coming. Certainly it’s a lot slower both than I had hoped and than I had expected, nonetheless, I am seeing
it in the wild now and if you look at the IPv6 statistics for India, I think you’ll see a clear indication of why.

Owen

---

From: Owen DeLong <[email-masked]>
Date: Thu, 30 Sep 2021 10:28:08 -0700

> On Sep 30, 2021, at 10:10 , Gert Doering <[email-masked]> wrote:
> 
> Hi,
> 

Sadly, it is some people’s preference, yes.

Owen

---

From: Gábor LENCSE <[email-masked]>
Date: Thu, 30 Sep 2021 19:32:47 +0200

> IPv6-only without a NAT64 gateway is not workable today.
Well, it depends on, how you define "IPv6-only". If we are talking about 
"IPv6-only access and core network", any of the 5 IPv4aaS solutions 
(464XLAT, DS-Lite, MAP-T, MAP-E, Lw4o6) may be used, and only 464XLAT 
uses a stateful NAT64 gateway.

Gábor

---

From: [email-masked]
Date: Thu, 30 Sep 2021 19:38:31 +0200

> Well, it depends on, how you define "IPv6-only". If we are talking about "IPv6-only access and core network", any of the 5 IPv4aaS solutions (464XLAT, DS-Lite, MAP-T, MAP-E, Lw4o6) may be used, and only 464XLAT uses a stateful NAT64 gateway.

I was referring to IPv6 only as meaning IPv6 end to end.
Which is the only case where an application would benefit from IPv6.

O.

---

From: Owen DeLong <[email-masked]>
Date: Thu, 30 Sep 2021 10:40:08 -0700

> On Sep 30, 2021, at 10:21 , [email-masked] wrote:
> 
> Gert,
> 

I disagree. I think there is a subtle but important difference between “our goal failed” and “our goal hasn’t succeeded yet”.

While I agree we should take stock and consider alternatives to accelerate the deployment of IPv6, I do not
think that declaring failure and giving up on IPv6 transition is the right answer.

> The eyeball networks aren't depending on CGNAT44, they use public IPv4 addresses.

That’s only really true in North America and Europe and can’t be sustained much longer even there.

Much of Asia (especially India and China) are using varieties of CGN and NAT444, NAT4444, etc.

Much of Africa, despite their RIR still having a free pool is also deploying CGN rather than public
addresses, in part due to absurd policies that are based on the premise that protecting the free pool
somehow increases the viable longevity of IPv4 while actually hampering deployment progress in
general.

> My point was that the utilisation of those IPv4 addresses could be improved by orders of magnitude, simply by using more ports than just 443.

My point is that making it possible for consumers to use protocols beyond TCP, UDP, and ICMP
would be a good thing.

> Indeed. And if you depend on a NAT64 gateway your application has the same set of issues as if it was behind a NAT44.

There are a couple of additional failure modes (e.g. Skype behind NAT44 has NAT traversal, last I looked, Skype
behind NAT64 was more of a complete failure).

> Are you aware of any services like that today?

Yes, but not in the sense you are meaning:

(114) ~ % host jimtest.delong.com                                                                                                                                2021/09/30 10:35:06
jimtest.delong.com has IPv6 address 2620:0:930::dead:beef:cafe

No A record. Web server is alive on port 80 there.

> Nor is anyone panicking either.

Well… yes and no. When CGN goes wrong, it often goes horribly wrong and there is a fair amount of
panic in those instances. Not to mention the call center costs and the cost in terms of customer good
will and trust, brand reputation, SLA credits, etc.

> The reality is unfortunately that NAT has benefits. Which would also be required in IPv6.

I remain unconvinced of this. Please explicate.

> (For example the trend of Enterprises to tunnel their traffic to the cloud for "services". Marketing name: SASE.)

True, but I don’t accept the premise. You’re going to have to provide more than a simple allegation that
a) NAT has benefits
and
b) NAT would be the only way to achieve those benefits in IPv6

> End to end is certainly dead.

Why? Again, I remain unconvinced of this.

> So as much as I'd like the purety of the IPv6 architecture, we're not going to do networking like it's 1990 again any time soon.

Seems a lot of people would like it, so what, exactly, is preventing it?

Owen

---

From: Gert Doering <[email-masked]>
Date: Thu, 30 Sep 2021 19:42:02 +0200

Hi,

> Indeed. And if you depend on a NAT64 gateway your application has the same set of issues as if it was behind a NAT44.

That was actually a typo.  That was intended to read "is well workable today".

It works.  We've tested it on various networks.  Like, IETF wifi :-)

Some applications break, but thanks to the good work of Apple and others,
many more work nicely from an IPv6-only host today - through a NAT64 if the
other end is still IPv4-only.

> Are you aware of any services like that today?

Most eyeball ISPs in DE do DS-Lite today.

So if I want "VPN to my home network" - located behind such an ISP - I
need to do VPN over v6.

So if I'm coming from a v4-only network (like a mobile hotspot somewhere),
I can't do what I want.

IPSEC coming from an DS-Lite network to an IPv4-only corporate VPN server
also breaks in interesting ways - sometimes it works, sometimes it only
works for a while, etc.

[..]
> The reality is unfortunately that NAT has benefits. Which would also be required in IPv6.

Of course.  NAT is a useful tool.

If I have a choice on whether I want to use NAT or not, it's beneficial.

If I am forced to use NAT due to address space constraints, it's an 
annoyance, and it makes networks more brittle than necessary (like: every
Kubernetes cluster uses the *same* RFC1918 /16 inside, and when you
report reachability problems, the first question support needs to ask
is something like "ok, so, yes, 10.2.7.27, but which instance of that?"...)

Gert Doering
        -- NetMaster

---

From: Gert Doering <[email-masked]>
Date: Thu, 30 Sep 2021 19:45:26 +0200

Hi,

> uses a stateful NAT64 gateway.

That's not "ipv6-only" in an interesting way, no more than "a BGP-free
MPLS core" is relevant for users of said network.  For all I care the
network could be a any-to-any switched ATM network with no IP at all... :-)

ipv6-only on one endpoint of the connection, this is the interesting part,
with translation (NAT64 or NAT46) if having to communicate with an ipv4-only
endpoint.  Like, facebook datacenters, or t-mobile handsets.

Gert Doering
        -- NetMaster

---

From: [email-masked]
Date: Thu, 30 Sep 2021 20:01:37 +0200

> Seems a lot of people would like it, so what, exactly, is preventing it?

It's not at all apparent that Enterprises wants it nor would benefit from it. As of now.

O.

---

From: Owen DeLong <[email-masked]>
Date: Thu, 30 Sep 2021 11:19:26 -0700

> On Sep 30, 2021, at 11:01 , [email-masked] wrote:
> 

Agreed… IMHO, the current frontier that actually matters is content providers.

Forward progress of major content providers would enable monostack eyeballs.

Monostack eyeballs would then become the driver for enterprise. As I mentioned, some of my enterprise
clients are already experiencing this and it is growing.

Owen

---

From: Brian E Carpenter <[email-masked]>
Date: Fri, 1 Oct 2021 08:32:42 +1300

> No, but our goal failed. So let's take stock.

We designed for co-existence, despite calling it "transition".

We have co-existence, and no drop-dead date for IPv4.

Why is this a problem?

   Brian

---

From: Gert Doering <[email-masked]>
Date: Thu, 30 Sep 2021 22:35:15 +0200

Hi,

> We have co-existence, and no drop-dead date for IPv4.

Co-existence means it's easy to avoid doing IPv6 at all, because everyone
else will (have to!) find a way to cope with such laziness.

Thus, DS-lite, CGN, NAT64, ...

Gert Doering
        -- NetMaster

---

From: Clark Gaylord <[email-masked]>
Date: Thu, 30 Sep 2021 16:47:37 -0400

And no co-existence means no one would have ever run IPv6. I completely
agree we need NAT64 awareness, but that in and of itself isn't a compelling
single stack story. It *does* demonstrate that single stack may be *viable*
but it doesn't make it compelling.

Making the case for IPv6 being *essential* is when enterprises start
thinking IPv6 is fundamental to their system architecture, for example by
unlocking scalability, end-to-end transparency, or security advantages.

---

From: Brian E Carpenter <[email-masked]>
Date: Fri, 1 Oct 2021 09:52:24 +1300

> Thus, DS-lite, CGN, NAT64, ...

Sure, we should definitely stop working on any more RFCs in this area,
except perhaps how-to guides.

(But I don't think it's laziness, it's short-term thinking.)

    Brian

---

From: "Hamilton, Robert" <[email-masked]>
Date: Thu, 30 Sep 2021 21:23:28 +0000

I distinctly remember one of our network guys saying, "We'll never have wi-fi here. It's insecure, and...there's just no need for it."

As soon as someone higher-up got a wi-fi device that they wanted to use at work, our whole campus got wi-fi. Imagine that.

Customers with hand-held devices, phones, or whatever the future hand-helds are, will need to talk to someone with IPv6, because there will be too many devices for them all to have IPv4 addresses. I think if you want to have customers, you're going to have to have IPv6. If you don't want those customers, then it won't matter what protocol you won't be using any more.

R;

Rob Hamilton
Infrastructure Engineer
Chemical Abstracts Service
A Division of the American Chemical Society

-----Original Message-----
From: v6ops <[email-masked]> On Behalf Of Brian E Carpenter
Sent: Thursday, September 30, 2021 4:52 PM
To: Gert Doering <[email-masked]>
Cc: Lorenzo Colitti <lorenzo=[email-masked]>; Jen Linkova <[email-masked]>; V6 Ops List <[email-masked]>; Owen DeLong <owen=[email-masked]>
Subject: [EXT] Re: [v6ops] Is there a problem? [was: Why enterprises aren't adopting IPv6]

[Actual Sender is [email-masked]]

    Brian

_______________________________________________
v6ops mailing list
[email-masked]
https://smex12-5-en-ctp.trendmicro.com:443/wis/clicktime/v1/query?url=https%3a%2f%2fwww.ietf.org%2fmailman%2flistinfo%2fv6ops&umid=af636383-f8a1-4f47-b499-50797f95b19a&auth=0463bafb6650d356e56a2e2e21a2156df1672070-71768b2b39dc928a2381bc43d5a5adf1742f92b0

Confidentiality Notice: This electronic message transmission, including any attachment(s), may contain confidential, proprietary, or privileged information from CAS, a division of the American Chemical Society ("ACS"). If you have received this transmission in error, be advised that any disclosure, copying, distribution, or use of the contents of this information is strictly prohibited. Please destroy all copies of the message and contact the sender immediately by either replying to this message or calling 614-447-3600.

---

From: Owen DeLong <[email-masked]>
Date: Thu, 30 Sep 2021 14:27:55 -0700

> On Sep 30, 2021, at 12:32 , Brian E Carpenter <[email-masked]> wrote:
> 

In short, because continuing to support v4 is an expense for those that have deployed
v6 being externalized onto them by those who have not.

Owen

---

From: Lorenzo Colitti <[email-masked]>
Date: Fri, 1 Oct 2021 09:10:15 +0900

On Fri, Oct 1, 2021 at 12:59 AM Owen DeLong <owen=
[email-masked]> wrote:

> This is the problem, right here… There are networks where the
> administrators do NOT WANT this to be up to the user. They want control
> over certain policy aspects on their network. You are free to call them
> whatever names you want, but their networks are part of the target audience
> for IPv6 and they aren’t going to deploy it unless they have at least
> equivalent policy enforcement tools to what they have in IPv4 and they’re
> going to have to be implemented in a way that provides at least some
> familiarity or clear roadmap of the transition.
>

I don't think anybody disagrees (well, I certainly don't) that networks
should be able to limit what services devices can and cannot access on
their network. Let's take that as a given.

I think that what SLAAC advocates are saying is "IA_NA and one IPv6 address
per device" is not the right way to do that. IPv6 addresses are plentiful,
and there's no need to force devices to only have one. Just as an example:
DHCPv6 PD is strictly superior to DHCPv6 NA in terms of functionality. The
tracking and admission control ability are exactly the same, but PD doesn't
have the problem of limiting the number of addresses per device.

Proponents of DHCPv6 can say until the cows come home that "IA_NA and one
address per device" is more deployable because people are accustomed to
DHCPv4 and one IP address per device. That's true, but it does *not* make
it a superior technical solution. Why can't we do better? More importantly,
reading this thread - why aren't we *trying* to do better? The IETF is a
technical forum, not an IPv6 promotion organization. While it might be fun
to bash implementations for not implementing particular solutions, what we
should be doing here is looking for better technical solutions to this
problem that don't have the drawbacks that IA_NA has.

---

From: Owen DeLong <[email-masked]>
Date: Thu, 30 Sep 2021 17:35:21 -0700

> On Sep 30, 2021, at 17:10 , Lorenzo Colitti <lorenzo=[email-masked]> wrote:
> 
> On Fri, Oct 1, 2021 at 12:59 AM Owen DeLong <owen=[email-masked] <mailto:[email-masked]>> wrote:
> I don't think anybody disagrees (well, I certainly don't) that networks should be able to limit what services devices can and cannot access on their network. Let's take that as a given.
> 
> I think that what SLAAC advocates are saying is "IA_NA and one IPv6 address per device" is not the right way to do that. IPv6 addresses are plentiful, and there's no need to force devices to only have one. Just as an example: DHCPv6 PD is strictly superior to DHCPv6 NA in terms of functionality. The tracking and admission control ability are exactly the same, but PD doesn't have the problem of limiting the number of addresses per device.

And what everyone else is saying is “It doesn’t matter what you (collectively) think is or is not the right way to do it, it’s my network and I want to do it my way.” Until you make that possible, I’m not implementing your new protocol.

> Proponents of DHCPv6 can say until the cows come home that "IA_NA and one address per device" is more deployable because people are accustomed to DHCPv4 and one IP address per device. That's true, but it does not make it a superior technical solution. Why can't we do better? More importantly, reading this thread - why aren't we trying to do better? The IETF is a technical forum, not an IPv6 promotion organization. While it might be fun to bash implementations for not implementing particular solutions, what we should be doing here is looking for better technical solutions to this problem that don't have the drawbacks that IA_NA has.

That’s not what is being said. A lot of this has little to do with what they are accustomed to and a lot more to do with a combination of:
	+	Enterprise policies that they cannot conveniently change
	+	Government and other regulations that they cannot avoid
	+	Reporting requirements that they cannot subvert
	+	Limitations of the tools they have available to comply with the above.
etc.

In other words, you keep trying to suggest that there are alternative technical solutions, but you ignore the fact that this is NOT a technical problem.

It’s a political problem and for now, at least, the important thing to them is these politics. IPv6 is something they’re potentially willing to do if it
doesn’t create the above political problems for therm.

On virtually every platform except android, it doesn’t.

Owen

---

From: Lorenzo Colitti <[email-masked]>
Date: Fri, 1 Oct 2021 10:53:42 +0900

On Fri, Oct 1, 2021 at 9:35 AM Owen DeLong <owen=[email-masked]>
wrote:

> That’s not what is being said. A lot of this has little to do with what
> they are accustomed to and a lot more to do with a combination of:

Ok, but many of these points can be addressed in other ways:

   - For reporting: many vendor platforms support ND binding logging via
   syslog, and something like draft-ietf-dhc-addr-registration
   <https://datatracker.ietf.org/doc/draft-ietf-dhc-addr-registration/>
   would likely make it much easier for networks that use DHCPv6 only for
   tracking/forensics (vs. for access control) to move away from IA_NA.
   Specifically, it would satisfy the reporting requirements and make it a lot
   easier for the tools to adapt because it's still using the DHCPv6 protocol.
   - Enterprise policies and government regulations are not written in a
   vacuum, they're written to address business and legal requirements, and I
   really don't think you can credibly claim that DHCPv6 is a business or
   legal requirement. The legal requirements are things like tracking, access
   control, etc.

> In other words, you keep trying to suggest that there are alternative
> technical solutions, but you ignore the fact that this is NOT a technical
> problem.
>

Actually what I'm saying is that we (the IETF) *do* have a technical
problem, regardless of the status of implementations, which the IETF
doesn't have much of a say in anyway. The problem is: there is no IETF
consensus that "IA_NA with one address per device" is a good technical
solution. So: why aren't we looking for a way that's better for everyone
involved (users, implementers, operators)? Even if you're 100% convinced
that utimately all platforms will implement IA_NA with one address per
device, isn't it a better outcome if that model is limited to a few
networks, and networks with less stringent requirements or less dogmatic
operators can use a technically better solution that we come up with in the
meantime?

Of course, there may still remain network operators that say, "my network,
my rules; my one IA_NA way or the highway". But if your main concern is
accelerating IPv6 adoption, then if we come up with a solution that's not
IA_NA and satifies some (even if not all) enterprise requirements, then
that's pretty likely to help adoption of IPv6 in enterprises that have a
real business need for IPv6.

---

From: Owen DeLong <[email-masked]>
Date: Thu, 30 Sep 2021 20:55:52 -0700

> On Sep 30, 2021, at 18:53 , Lorenzo Colitti <lorenzo=[email-masked]> wrote:
> 
> On Fri, Oct 1, 2021 at 9:35 AM Owen DeLong <owen=[email-masked] <mailto:[email-masked]>> wrote:
> For reporting: many vendor platforms support ND binding logging via syslog, and something like draft-ietf-dhc-addr-registration <https://datatracker.ietf.org/doc/draft-ietf-dhc-addr-registration/> would likely make it much easier for networks that use DHCPv6 only for tracking/forensics (vs. for access control) to move away from IA_NA. Specifically, it would satisfy the reporting requirements and make it a lot easier for the tools to adapt because it's still using the DHCPv6 protocol.

But those tools aren’t readily available as already built-in enterprise management tools. IA_NA is.
> Enterprise policies and government regulations are not written in a vacuum, they're written to address business and legal requirements, and I really don't think you can credibly claim that DHCPv6 is a business or legal requirement. The legal requirements are things like tracking, access control, etc.

Sure, but the tools people have that do that today are based on DHCP and the path of least resistance (both bureaucratic and technical) is IA_NA.
> Actually what I'm saying is that we (the IETF) do have a technical problem, regardless of the status of implementations, which the IETF doesn't have much of a say in anyway. The problem is: there is no IETF consensus that "IA_NA with one address per device" is a good technical solution. So: why aren't we looking for a way that's better for everyone involved (users, implementers, operators)? Even if you're 100% convinced that utimately all platforms will implement IA_NA with one address per device, isn't it a better outcome if that model is limited to a few networks, and networks with less stringent requirements or less dogmatic operators can use a technically better solution that we come up with in the meantime?

There’s also no consensus that it isn’t a viable solution that would allow enterprises to move forward. Virtually every other vendor has implemented it and android is the one standing in the way of progress here. While I realize we’re discussing this in the context of an IETF list at the moment, the reality is that this thread really is more about facilitating deployment than protocol development and IA_NA will accomplish that even if you don’t like it.

> Of course, there may still remain network operators that say, "my network, my rules; my one IA_NA way or the highway". But if your main concern is accelerating IPv6 adoption, then if we come up with a solution that's not IA_NA and satifies some (even if not all) enterprise requirements, then that's pretty likely to help adoption of IPv6 in enterprises that have a real business need for IPv6.

I think what you are not hearing is that there are already MANY enterprise operators that are saying “my network, my rules; my one IA_NA way or the highway”.

If you want to come up with other solutions in parallel, be my guest, but please make it possible for android to obtain an address via IA_NA.

Owen

---

From: Lorenzo Colitti <[email-masked]>
Date: Fri, 1 Oct 2021 13:12:18 +0900

On Fri, Oct 1, 2021 at 12:56 PM Owen DeLong <owen=
[email-masked]> wrote:

> If you want to come up with other solutions in parallel, be my guest, but
> please make it possible for android to obtain an address via IA_NA.
>

Before doing that I think we should explore better solutions. Once we find
a solution that meets enterprise needs and has better properties,
implementing IA_NA will be a lot less cocerning in terms of long-term
impact on IPv6 deployment, because greenfield enterprise deployments that
aren't already wedded to IPv4 and DHCP will be able to use the new solution.

---

From: David Farmer <[email-masked]>
Date: Fri, 1 Oct 2021 00:14:50 -0500

> aren't already wedded to IPv4 and DHCP will be able to use the new solution.

You are saying you object to the fact that with IA_NA the operator can
choose to only assign one address. I will concur that assigning only one
IPv6 address is utter stupidity.

So, is there a compromise somewhere between 1 and 2^64 addresses to be had?
Isn't it possible to request multiple addresses, that is to request
multiple IA_NA options? Then if the server returns a number of addresses
below a threshold, then refuse the addresses?

If there is no compromise between 1 and 2^64 possible, then your one
address objection is a smokescreen.  And, you are really saying that a host
must be able to select the IIDs it chooses and you are rejecting the
managed address paradigm altogether, you seem to be say the operator can't
tell the host which IIDs it is permitted to use. In my mind, the managed
address paradigm seems pretty fundamental to the protection of highly
restricted data.

Thanks.

---

From: Lorenzo Colitti <[email-masked]>
Date: Fri, 1 Oct 2021 14:50:24 +0900

On Fri, Oct 1, 2021 at 2:15 PM David Farmer <farmer=[email-masked]>
wrote:

> So, is there a compromise somewhere between 1 and 2^64 addresses to be
> had? Isn't it possible to request multiple addresses, that is to request

Well, let's find out. :-)

Let's see if we get enough consensus to work on an RFC that says that all
general-purpose DHCPv6 clients are entitled to receive N addresses; that
any network that does not provide that number of addresses is in violation
of the RFC; and that any client disabling the IPv4 stack if it does not get
at least N addresses is in full compliance with all IETF specifications
including RFC 8415.

Personally I will be very surprised if you get consensus on any N even on
this thread (let alone the WG or the IETF). The reason for that 1 is
unacceptable to some folks, but any time you go beyond 1, then lots of
infrastructure needs to be changed. And that's the rub here: IMO, when
folks say they want DHCPv6, it's not because they want security or access
control or tracking or whatever else. It's because they want to run their
networks *in the same way as they do in IPv4*. That means an IPAM that maps
one MAC to one IP and one DNS name, for example. If you're an enterprise,
that's a legitimate desire: why pay costs that you don't think are
necessary? The problem is that the enterprise does not pay the costs of
NAT; device manufacturers, app developers, and users do. It would be good
for users to stop having to pay those costs when we upgrade to IPv6. This
is where we're stuck I think.

Another reason for not having a hard number is that TCAM is expensive and
that any number that would provide enough flexibiilty in the long term
(e.g., one IPv6 address per app on the device) would likely be too
expensive today. That's obviously easily solved with DHCPv6 PD, but the
problem with DHCPv6 PD is that it's not IA_NA, and requires infrastructure
to be changed. Same problem as above.

Anyway, we can try this out as a thought experiment. I'll start: how about
N=64?

---

From: David Farmer <[email-masked]>
Date: Fri, 1 Oct 2021 00:55:39 -0500

On Thu, Sep 30, 2021 at 12:43 AM Lorenzo Colitti <lorenzo=
[email-masked]> wrote:

> to do.

The reference you provided is for switches, not routers, yes many people
use them as routers.  *I*'m not aware of most routers logging ND and ARP
without debug level logging which isn't recommended on production routers
running at full tilt.  If I'm wrong about that, I'd love to hear it.

Scraping ND and ARP via SNMP, sucks, and doesn’t scale well, if I remember
correctly you have to fetch individual lines of the table. We found a much
lower impact on the routers using the command line and screen scraping ssh
sessions, yea it's ugly, but it works. We burn a couple of beefy machines
scraping our network, ~4k switched, +15K APs, ~10K L3 interfaces, +150K mac
addresses, with an average of 5 addresses per MAC, not to mention a quite
sizable backend Oracle DB instance to track it all.

I've been asking about telemetry streaming of ND and ARP deltas only, but
haven't been getting traction on that, but I haven't pushed too hard
either, we have had other priorities with our vendors.

I think some open-source tools for ND and ARP scraping aimed at
medium-sized enterprise networks with a hundred switches or less and a few
thousand clients or smaller would go a long way to planting new habits in
the IT industry.

I think the issue is more around operational familiarity and the idea that
> because we do things this way in IPv4 we must to do them the same way in
> IPv6 as well.
>

Yes, that is a big part of it. But, with the added frustration, that by
calling it DHCPv6, we very much give the allusion that you can just do
things the same way you did them with IPv4. So can you really blame people
for drinking the kool-aid? Furthermore, DHCPv4 and DHCPv6 are really quite
different things, and it isn't the "easy button" that they thought they
had. Throw in the fact most IT shops barely keep their heads above water,
strategic thinking becomes pretty rare and a luxury most organizations do
have. Then the last straw, Android doesn't support DHCPv6, any doubt why
IPv6 deployment is lagging in enterprises?

Thanks.

---

From: David Farmer <[email-masked]>
Date: Fri, 1 Oct 2021 01:30:00 -0500

On Fri, Oct 1, 2021 at 12:50 AM Lorenzo Colitti <lorenzo=
[email-masked]> wrote:

> On Fri, Oct 1, 2021 at 2:15 PM David Farmer <farmer=
> networks *in the same way as they do in IPv4*. That means an IPAM that
> maps one MAC to one IP and one DNS name, for example. If you're an
> enterprise, that's a legitimate desire: why pay costs that you don't think
> are necessary? The problem is that the enterprise does not pay the costs of

Well, we run a quite sizable IPv6 network, I haven't looked at the numbers
in a couple of years, but we were seeming an average of 4 and change IPv6
address per MAC address including LL, we had some outliers with a few
hundred and even one with more than a thousand. Let's be generous, call it
5 IPv6 GUA addresses per host on average. I think almost 13 times average
might be a bit much, but 2 to 5 times the average seems reasonable, so I'd
probably start with a limit of 25 per host on our network. But, I need to
go look at what the 90th, 95th, and 99th percentiles are at, I just don't
remember.

So, for an RFC how about 10, I have a much bigger budget than a lot of
networks.

Next bid, please.

Thanks

---

From: Gert Doering <[email-masked]>
Date: Fri, 1 Oct 2021 08:38:30 +0200

Hi,

> Customers with hand-held devices, phones, or whatever the future hand-helds are, will need to talk to someone with IPv6, because there will be too many devices for them all to have IPv4 addresses.…

The laziness of content providers (twitter, many news sites) to implement
IPv6 has not led to "loss of customers".  Instead, it had led to "providers
on the eyeball side need to ensure that IPv4-only content still works".

Incentives are wrong - content saving money leds to other people having
higher costs, and no way to move the hurt where it needs to be.

(And yes, laziness.  It's not like people have plans "we do this next
year", otherwise they would have done it 10 years ago "next year" - they
just do not care)

Gert Doering
        -- NetMaster