Subject: Re: [v6ops] Is there a problem? [was: Why enterprises aren't adopting IPv6]

From: Brian E Carpenter <[email-masked]>
Date: Sat, 2 Oct 2021 08:50:33 +1300

Hi Gert,
On 01-Oct-21 19:38, Gert Doering wrote:
> Hi,
> 
> On Thu, Sep 30, 2021 at 09:23:28PM +0000, Hamilton, Robert wrote:
>> 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.
> 
> 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)

Another way to describe it is what economists call "externalities", i.e.
costs that an enterprise creates for the community that it does not
pay for. The classical example is pollution - my fire pollutes your air,
and you pay the price while I use the heat.

The solution is "polluter pays", some way to force the cost of the
externality back onto the enterprise that creates it. How can we
force the costs back onto IPv4-only enterprises?

   Brian

---

From: Philip Homburg <[email-masked]>
Date: Fri, 01 Oct 2021 22:32:09 +0200

>force the costs back onto IPv4-only enterprises?

So it seems that you saying that running IPv6 has no net benefit in a 
world dominated by IPv4. It seems that by now, eyeball providers have found
some benefit in providing IPv6. 

However, we see that, for example, many content providers see no benefit in
IPv6. Why is it that for them, a direct connection over IPv6 is not worth the
effort compared to a connection through a CGNAT? 

Obviously, there is no way to force anybody to pay anything. We spend decades
to make sure that internet traffic is cheap. 

What can be done is to try find ways to make IPv4-as-a-service cheaper.

---

From: Owen DeLong <[email-masked]>
Date: Sat, 2 Oct 2021 01:02:55 -0700

> On Oct 1, 2021, at 13:32, Philip Homburg <[email-masked]> wrote:
> 
> 
>> 

Eyeball providers are out of IPv4 addresses and acquisition cost exceeds customer value. Eyeball providers need a much larger supply of IPv4 addresses to support IPv4-only content providers than the content providers do. 

Content providers are not (yet) facing shortage and their revenue per address is a much higher ratio than eyeball providers. 

This, like toxic polluters, lazy content providers are externalizing the cost of their laziness onto the eyeball providers. 

> effort compared to a connection through a CGNAT? 

Because they don’t pay the costs of that CGNAT. They create the cost, but the eyeball providers are forced to pay it. 

> to make sure that internet traffic is cheap.

Major eyeball providers could, actually start demanding higher settlements for IPv4 peering than v6 and use that to start pushing some of the V4 costs back onto the content providers. 

> What can be done is to try find ways to make IPv4-as-a-service cheaper. 

That’s exactly the opposite of a good outcome, TBH. 

Owen

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

---

From: Philip Homburg <[email-masked]>
Date: Sat, 02 Oct 2021 12:14:10 +0200

> Eyeball providers are out of IPv4 addresses and acquisition cost
> exceeds customer value. Eyeball providers need a much larger supply
> of IPv4 addresses to support IPv4-only content providers than the
> content providers do.

As far as I know, eyeball providers have waited until the last possible
moment with offering IPv6 to customers. For example, my phone got IPv6 address
(on mobile) just weeks ago.

Even then, most countries have less than 50% adoption of IPv6 by eyeball
providers.

So it seems like eyeball providers didn't do IPv6 when they had enough 
IPv4 addresses. And that they are out of address suddenly everybody has
to do IPv6.

Of course, I'm happy that my phone now finally has an IPv6 address.

> Major eyeball providers could, actually start demanding higher
> settlements for IPv4 peering than v6 and use that to start pushing
> some of the V4 costs back onto the content providers.

I think for a long time, the internet community at large has argued against
eyeball providers demanding money from content providers.

However, in the cases where an eyeball provider is already collecting
money from content providers, what is stopping them from offloading the
cost of the CGNAT and IPv4 addresses to the content providers? That seems like
an easy way out.

The classical argument again this is that the customers of the eyeball ISP
should pay for access to IPv4. They are the ones that want the content.

---

From: Vasilenko Eduard <[email-masked]>
Date: Sun, 3 Oct 2021 17:34:32 +0000

Many IP addresses could improve privacy, but “improve privacy” could be classified as harmful to internal Enterprise traffic.
It is a tiny advantage for traffic going to the Internet that could not overcome the complexity and cost of managing many virtual things (bigger logs, more difficult troubleshooting, additional requirements to CAM tables).
I suspect that it is not enough motivation to pay the price for Enterprises.
Is anything else exist that could justify many IP addresses in the Enterprise environment?
PS: we do not have many addresses for an apartment or a house.
Eduard
From: v6ops [mailto:[email-masked]] On Behalf Of David Farmer
Sent: Friday, October 1, 2021 9:30 AM
To: Lorenzo Colitti <lorenzo=[email-masked]>
Cc: v6ops list <[email-masked]>
Subject: Re: [v6ops] Implementation Status of PREF64

On Fri, Oct 1, 2021 at 12:50 AM Lorenzo Colitti <lorenzo=[email-masked]<mailto:[email-masked]>> wrote:
On Fri, Oct 1, 2021 at 2:15 PM David Farmer <farmer=[email-masked]<mailto:[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 multiple IA_NA options? Then if the server returns a number of addresses below a threshold, then refuse the addresses?

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?

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
--
===============================================
David Farmer               Email:[email-masked]<mailto:[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: Owen DeLong <[email-masked]>
Date: Wed, 6 Oct 2021 11:57:37 -0700

> On Sep 30, 2021, at 22:50 , Lorenzo Colitti <[email-masked]> wrote:
> 
> On Fri, Oct 1, 2021 at 2:15 PM David Farmer <farmer=[email-masked] <mailto:[email-masked]>> wrote:

No. It’s not IETF’s place to tell network operators what rules they can and cannot apply to addressing on their own networks.

Further, making the IPv4 stack contingent on the number of addresses you get in IPv6 is just plain silly. The two are unrelated.

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

You’re right, because it’s an unreasonable demand and you’re demonstrating that it’s your desire to dictate to operators
limitations you want to put on their ability to manage their networks. It’s proof that you’d rather see IPv6 fail to get deployed
than accept that you can’t force operators to bend to your will.

Eventually you, and by extension, android, will be seen as damage and routed around on this basis.

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

I’m fine with N=64 as a minimum value for N if you will back off from MUST and “can disable the IPv4 stack to prove the device can
be a proxy for Lorenzo’s temper tantrum” to SHOULD.

Owen

---

From: Owen DeLong <[email-masked]>
Date: Wed, 6 Oct 2021 22:47:00 -0700

> On Oct 2, 2021, at 03:14 , Philip Homburg <[email-masked]> wrote:
> 

Depends on where you live.

T-Mo in the US has been v6 for years… Same with VZW and even ATT.

Not sure where SPRINT/Softbank/whatever they became (T-mo?) is now,
but they’ve been trying their best to become irrelevant in the US market for
years now.

MVNOs still lag, but most of them aren’t significant fractions of the market any
more anyway. I think “Metro by T-Mo” is still lagging as well.

> Even then, most countries have less than 50% adoption of IPv6 by eyeball

That depends on how you measure. If you just count by number of providers,
that’s probably true because the many many small ISPs are among the biggest
laggards in that market. If you count eyeballs passed, not sure that’s so much
the case, at least in the US. Comcast, AT&T, Cox, and others have all deployed
IPv6 to their eyeball customers. Verizon FIOS is still lagging here, to the best
of my knowledge.

> IPv4 addresses. And that they are out of address suddenly everybody has

Not at all… But even if they had done IPv6 much earlier (and many of the
larger ones did), until the content providers their customers most care about
reaching are on IPv6, they don’t have the option of running IPv6-only customers.

> eyeball providers demanding money from content providers.

Not very successfully so far, though that is admittedly changing recently.

> cost of the CGNAT and IPv4 addresses to the content providers? That seems like

There are multiple types of costs and some of them are hard to quantify.
It’s not as simple as one might hope, but yes, this might be possible.

> should pay for access to IPv4. They are the ones that want the content.

Which comes back to my argument that eyeball providers should start offering
a discount to customers willing to take IPv6-only services and/or surcharge
customers demanding IPv4 service.

Owen

---

From: Lorenzo Colitti <[email-masked]>
Date: Thu, 7 Oct 2021 16:04:17 +0900

On Thu, Oct 7, 2021 at 3:57 AM Owen DeLong <[email-masked]> wrote:

> 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.
>
>
> No. It’s not IETF’s place to tell network operators what rules they can
> and cannot apply to addressing on their own networks.
>

Ok, so remove that text and just say: all general-purpose DHCPv6 clients
are entitled to receive N addresses, and that any client that does not
enable IPv6 if it does not get at least N addresses is in compliance with
IETF specifications.

If this is not acceptable, then why not? It looks like you're making a
point of principle here: network operators should be able to set policies
on how many IPv6 addresses are handed out, but hosts should not be able to
set policies on how many IPv6 addresses they accept. Why the asymmetry?

Further, making the IPv4 stack contingent on the number of addresses you
> get in IPv6 is just plain silly. The two are unrelated.
>

Sorry. that was a typo. As you say, IPv4 has nothing to do with this. What
I meant to say was, "disabling the IPv6 stack".

---

From: Nick Hilliard <[email-masked]>
Date: Thu, 7 Oct 2021 12:27:45 +0100

Lorenzo Colitti wrote on 07/10/2021 08:04:
> It looks like you're making a 
> point of principle here: network operators should be able to set 
> policies on how many IPv6 addresses are handed out

It's a point of local policy.  But yeah, a network operator doesn't need 
to be told by the ietf how many ip addresses they are obliged to hand 
out on their networks.

> but hosts should not 
> be able to set policies on how many IPv6 addresses they accept.

Sure they can.  There's nothing stopping a dhcpv6 client from refusing 
to enable ipv6 on an interface if it gets less than N addresses.

> Why the asymmetry?

Because your policy is not someone else's policy.

Nick

---

From: Alexandre Petrescu <[email-masked]>
Date: Thu, 7 Oct 2021 15:15:18 +0200

Le 30/09/2021 à 07:53, Lorenzo Colitti a écrit :
> On Wed, Sep 29, 2021 at 3:40 AM Gert Doering <[email-masked] 
> <mailto:[email-masked]>> wrote:
> 
> 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...
> 
> 
> 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?

But to register an address in DNS with a DHCP tool one would still need
the manufacturers of modems in Android devices to unblock the DHCPv6 UDP
port numbers or the DHCP-related IP multicast addresses.

Alex

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

---

From: Alexandre Petrescu <[email-masked]>
Date: Thu, 7 Oct 2021 15:18:39 +0200

Le 30/09/2021 à 08:20, [email-masked] a écrit :
>>> 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).
>>>
>> 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?
> 
> 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.

I agree, having even a limited DHCP (maybe only IA_PD, or only address 
registering, or other limitations) working on Android on a cellular 
modem would be a significant achievement.

One such limitation is 'stateless DHCP'.  It is a 'may' in 3GPP 
documents.  However, even that simple limited DHCPv6 is prohibited in 
3GPP modems.

The problematic text in 3GPP TS 23.501 is the following:
 > /64 IPv6 prefix allocation shall be supported via IPv6 Stateless
 > Auto-configuration according to RFC 4862 [10], if IPv6 is supported.
 > The details of Stateless IPv6 Address Autoconfiguration are described
 > in clause 5.8.2.2.3. IPv6 parameter configuration via Stateless
 > DHCPv6 (according to RFC 3736 [14]) may also be supported.

Remark the 'may' in the last line.

In practice there is no DHCPv6 allowed by any 3GPP modem out there.

Alex

> Steinar Haug, AS2116

---

From: "STARK, BARBARA H" <[email-masked]>
Date: Thu, 7 Oct 2021 13:20:44 +0000

> to enable ipv6 on an interface if it gets less than N addresses.

Host policy should be dictated by the people in control of the host and not IETF.
IETF has no business restricting the rights of device owners and private networks operators to dictate what devices are allowed to do on their network. This sort of prohibition on device owners and private network admins setting host policy would be 100% harmful.
I'm having visions of IETF becoming not unlike the Texas legislature in its desire to dictate "morality".
Barbara

---

From: Alexandre Petrescu <[email-masked]>
Date: Thu, 7 Oct 2021 15:29:25 +0200

Le 30/09/2021 à 15:27, Mark Smith a écrit :
> 
> 
> On Thu, 30 Sep 2021, 15:43 Lorenzo Colitti, 
> <lorenzo=[email-masked] 
> <mailto:[email-masked]>> wrote:
> 
> On Wed, Sep 29, 2021 at 1:01 AM STARK, BARBARA H <[email-masked] 
> <mailto:[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.
> 
> 
> 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.

I learn at a little wide scale here, that the problem the enterprises
will face if they dont move to IPv6 is a little different.

There is one thing to be a big enteprise, but there are many more
smaller enterprises.  These small ones recently get their presence on
the web faster and cheaper, on IPv6, because the providers of hosting
space offer them that access cheaper on IPv6 (ikoula, etc.)

If one large enterprise forbids its personnel to see these new fast
moving growing numbers of small enteprises, then they face a big problem
in their of competition and innovation capabilities.

Alex

> Regards, Mark
> [email-masked] <mailto:[email-masked]> 
> <https://www.ietf.org/mailman/listinfo/v6ops>
> 
>

---

From: Alexandre Petrescu <[email-masked]>
Date: Thu, 7 Oct 2021 15:51:55 +0200

Le 30/09/2021 à 17:23, Vasilenko Eduard a écrit :
> 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?

I think this question is rhetorical.

I once worked in a project during 3 days, in which we compiled and made
several DHCPv6 packages ready for submission to Store of Android apps.
But we needed 5 euros - or so - to be alowed to.  We decided to stop
short on spending that small amount of money; there are several reasons
for stopping that, not the least being that it would not be working on
3G links (our main goal) but only on WiFi; also, it would upset
Administrators of Store; last but not least it would cross our ethical
limits about how to spend money.

I think fundamentally people at owner of Android met a few technical
problems when trying to build DHCPv6 packages too; when they realized it
was not within their reach to solve them - it was within Qualcomm or
similar, reach - then they started to develop a non-DHCP religtion.  I
know other people at some operator who have a hard time negotiating with
phone manufacturer who depends on modem manufacturer; these are indeed
hard negotiations where the technical aspects are often distorted.

I think the fundamental problem lies at modem manufacturer nowadays.

The interesting thing to note is about IPR and patents.  IPv6 is known
to be relatively free of patents, whereas DHCP is not.  There is
something old about IPR and RAND conditions on DHCP(v4!) at Cisco.
There is also something old about Qualcomm and 2G (pre-GPRS) patents.
It might be that Qualcomm decided to avoid being called names because of
these DHCP IPR claims, and so decided to do IPv6 free of patents, i.e.
without DHCP.  It is laudable.

It is a personal interpretation of history.

If that is so, then one can not tell bad things about SLAAC, Qualcomm
and DHCP religion.  It is all good that way that it is, but still there
is something missing.

Alex
PS: in an interest of a full disclosure, and still be open, still be 
correct, to be fully complete, I must say also that one member of our 
discussions here recently pointed my to a hack of a modem made by 
unofficial activities but at a public URL 
https://4pda.to/forum/index.php?showtopic=678549&st=17700#entry90297458 
which seems to address the problem of a particular 3GPP modem brand 
blocking DHCPv6 in a hacking way (hacking==testing, maybe a bit 
underground, maybe a bit unreliable, whose high-level interest is 
unknown).  I will not try it myself because of these 'hacking' aspects, 
but there it is to be.

> 
> 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,
> 
> 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] 
> <mailto:[email-masked]>] *Sent:* Thursday, September 30, 2021 
> 10:17 AM *To:* Vasilenko Eduard <[email-masked] 
> <mailto:[email-masked]>> *Cc:* David Farmer 
> <farmer=[email-masked] 
> <mailto:farmer=[email-masked]>>; Mark Smith 
> <[email-masked] <mailto:[email-masked]>>; v6ops list 
> <[email-masked] <mailto:[email-masked]>> *Subject:* Re: [v6ops] 
> Implementation Status of PREF64
> 
> There are already vendor solutions.
> 
> 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.
> 
> “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
> 
> 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:
> 
> 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.
> 
> 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.
> 
> 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]> 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: Alexandre Petrescu <[email-masked]>
Date: Thu, 7 Oct 2021 16:02:27 +0200

Le 30/09/2021 à 19:38, [email-masked] a écrit :
>>> 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.
> 
> I was referring to IPv6 only as meaning IPv6 end to end.
> Which is the only case where an application would benefit from IPv6.

IPv6 end to end, despite of IPv6-to-IPv4-to-IPv6 like NAT64 is the only
tool that makes work a few visioconference tools which break if NAT64 is
there.

Visoconference braking in presence of NAT64 was the case at an IETF
meeting maybe in Singapour, or so.

Since then, the visioconference tools evolved a lot.

There is one that I would like to try which is this whatsapp web beta on
PC which works apparently without the need of the Android to be
connected (earlier it mandated the Android to be connected even if I was
on PC).

I dont know if you followed recent developments in these visio
multimedia and 2-factor authentications but there was a tendency to
mandate keeping both Android and PC connected if one wanted some
advanced app like like simulators, safe paying, etc.  There seems to be
a nascent tendency where the mandating of the smartphone to be connected
in order for the others to work (PC, etc.) seems to disappear.

That tendency is similar to the tendency where first they required the
smartphone to be connected in order for the smartwatch to work, or the
smartphone to be connected in order to be able to open the car door.
Nowadays the smartphone is no longer mandated to be connected in order
for the watch or the car to work.

It might advance along these lines, or not.

If it advances along these lines, it might that the problem of Android
forbidding DHCPv6 might no longer be that hard.

Alex

> O.

---

From: [email-masked]
Date: Thu, 7 Oct 2021 16:17:26 +0200

> I'm having visions of IETF becoming not unlike the Texas legislature in its desire to dictate "morality".

in the IPv6 working group we have seen multiple areas where this tussles play out like that. Almost like a proxy war.
If it's prefix length or if it's DHCP vs RA or others.

Any views on how we as a community can move away from acting as the IPv6 morality police?

O.

---

From: Alexandre Petrescu <[email-masked]>
Date: Thu, 7 Oct 2021 16:34:50 +0200

> Any views on how we as a community can move away from acting as the IPv6 morality police?

For my part, I think I can help constructing a list of variables (MTU, 
prefix, printer address, etc.) communicated by RA, DHCP, both or none.

Alex

---

From: David Farmer <[email-masked]>
Date: Fri, 8 Oct 2021 11:28:49 -0500

On Thu, Oct 7, 2021 at 8:21 AM STARK, BARBARA H <[email-masked]> wrote:

> IETF has no business restricting the rights of device owners and private
> networks operators to dictate what devices are allowed to do on their
> network. This sort of prohibition on device owners and private network
> admins setting host policy would be 100% harmful.
>

Ok, the IETF shouldn't pick N, I'm ok with that. But, does that mean you
think it is inappropriate for host implementations to enforce some number
of IPv6 addresses be available? Or, are you saying that is completely up to
network operators?

I will note a few things;

1. The IETF hasn't picked a value of  N, but it has, through RFC7934, said
that N<1.
2. In effect Android already enforces, N<1, by only supporting the
self-assigned addressing model of SLAAC.
3. However, by not supporting a DHCPv6 client, Android doesn't support the
managed-assignment addressing model of DHCPv6.

In an effort to find a compromise that allows Android to support DHCPv6 and
therefore the managed-assignment addressing model, I'm suggesting it is
reasonable for DHCPv6 clients to require the availability of more than one
IPv6 address before it enables it's IPv6 stack, and it sounds like Lorenzo
is at least open to discuss such a comprise.

However, it seems that some people are insisting that network operators
should be able to assign one and only one IPv6 address per client.
Personally, I think this argument is utterly futile, is creating a
deadlock, and it is holding back the deployment of IPv6. However, this
deadlock is not caused only by Android not supporting DHCPv6, but it is
also caused by those that insist that assigning one and only one address is
a valid IPv6 deployment strategy, and that network operators should have
ultimate and unilateral control in this matter.

I'm willing to concede that network operators need to allocate more than
one IPv6 address per client.. Furthermore, I think it is very important
that all major operating systems allow for both IPv6 address
assignment models, self-assigned (SLAAC) and managed-assignment (DHCPv6).

I'm having visions of IETF becoming not unlike the Texas legislature in its
> desire to dictate "morality".
> Barbara
>

Insisting the network operators have ultimate and unilateral control of
this issue is equally dictating "morality".

Thanks.

David Farmer               Email:[email-masked]

---

From: David Farmer <[email-masked]>
Date: Fri, 8 Oct 2021 11:47:20 -0500

WOOPS! I meant N greater than 1, so, that should have been N>1.

Sorry about that.

On Fri, Oct 8, 2021 at 11:28 AM David Farmer <[email-masked]> wrote:

> In an effort to find a compromise that allows Android to support DHCPv6
> and therefore the managed-assignment addressing model, I'm suggesting it is

---

From: "STARK, BARBARA H" <[email-masked]>
Date: Fri, 8 Oct 2021 18:35:08 +0000

From: David Farmer <[email-masked]>

Ok, the IETF shouldn't pick N, I'm ok with that. But, does that mean you think it is inappropriate for host implementations to enforce some number of IPv6 addresses be available? Or, are you saying that is completely up to network operators?

1. The IETF hasn't picked a value of  N, but it has, through RFC7934, said that N>1.
2. In effect Android already enforces, N<1, by only supporting the self-assigned addressing model of SLAAC.
3. However, by not supporting a DHCPv6 client, Android doesn't support the managed-assignment addressing model of DHCPv6.

In an effort to find a compromise that allows Android to support DHCPv6 and therefore the managed-assignment addressing model, I'm suggesting it is reasonable for DHCPv6 clients to require the availability of more than one IPv6 address before it enables it's IPv6 stack, and it sounds like Lorenzo is at least open to discuss such a comprise.

However, it seems that some people are insisting that network operators should be able to assign one and only one IPv6 address per client. Personally, I think this argument is utterly futile, is creating a deadlock, and it is holding back the deployment of IPv6. However, this deadlock is not caused only by Android not supporting DHCPv6, but it is also caused by those that insist that assigning one and only one address is a valid IPv6 deployment strategy, and that network operators should have ultimate and unilateral control in this matter.

I'm willing to concede that network operators need to allocate more than one IPv6 address per client.. Furthermore, I think it is very important that all major operating systems allow for both IPv6 address assignment models, self-assigned (SLAAC) and managed-assignment (DHCPv6).

Insisting the network operators have ultimate and unilateral control of this issue is equally dictating "morality".

<bhs> Just a few points:
- RFC7934 is scoped to "general-purpose end hosts" (which is not defined and therefore you can define the term any way that makes sense for you). RFC7934 is very specifically *not* scoped to all hosts.
 - I used the term "private network operators" in my comment and not "network operators". Just to be clear, "private network operators" include enterprises, small businesses, and home owners and not ISPs. I make no statement about ISPs. So you're saying that I should not be allowed to operate my home network any way I want (so long as that doesn't interfere with others' rights - e.g., doesn't allow my devices or my network to be used as part of a DDoS attack) because the IETF has claimed it has rights to dictate my home network and device addressing policies? <sarcasm>Maybe IETF should encourage legislators to pass a law that anyone can sue somebody (bounty of $10k?) for helping a home network owner subvert an IETF BCP.</sarcasm> And you think that my objection to IETF claiming rights over my network is *me* dictating morality? Really? No. I absolutely, 100%, claim full ownership of my home network and its policies (other than those that could interfere with other living human beings' networks and devices). If you can explain how my only allowing a host to have a single address is harmful (presents a security risk) *to somebody else* then let's discuss. If you're patronizingly trying to prevent me from what you think would be self-harm (e.g., allowing home owners to assign just a single address might cause some home owners mental anguish) or because you think hosts should have rights, then there's nothing for us to discuss.
Barbara   // BTW, I changed the <1 to >1 in the quoted text

---

From: Owen DeLong <[email-masked]>
Date: Fri, 8 Oct 2021 13:36:29 -0700

> On Oct 8, 2021, at 9:28 AM, David Farmer <farmer=[email-masked]> wrote:
> 
> 
> 
> On Thu, Oct 7, 2021 at 8:21 AM STARK, BARBARA H <[email-masked] <mailto:[email-masked]>> wrote:
> > > but hosts should not

If I operate a network, I don’t think that a host should be able to demand N addresses from my network (for any value of N).

It can ask. I can give it as many or as few as I’m willing. It can decide to use what I offer or not.

> 1. The IETF hasn't picked a value of  N, but it has, through RFC7934, said that N<1.

I doubt that. N<1 would be utterly useless… Perhaps N>1?

> 2. In effect Android already enforces, N<1, by only supporting the self-assigned addressing model of SLAAC.

Yes, because Android has a large market share, they are, in effect, through their refusal to adopt IA_NA, bullying (or at least attempting to bully) network operators that choose to implement IPv6.

This divides the community into three groups…

	+	Those that are not implementing IPv6 at least in part because of this issue
		(probably the vast majority of enterprises at this point)
	+	Those that are being subverted by this bullying
	+	Those that are implementing IPv6 in a “sorry, android, you can’t play until you fix it” mode.
		(by far the least populous group for now)

> In an effort to find a compromise that allows Android to support DHCPv6 and therefore the managed-assignment addressing model, I'm suggesting it is reasonable for DHCPv6 clients to require the avai…

The client is free to implement whatever minimums to implement its v6 stack it wants. IETF doesn’t need to weigh in on this, no standardization is required.

Android will simply become known as oddly dysfunctional in IPv6 which is an apt description for such behavior.

> However, it seems that some people are insisting that network operators should be able to assign one and only one IPv6 address per client. Personally, I think this argument is utterly futile, is cr…

Network operators by and large own the networks they are operating and they should have unilateral control over the numbering decisions on those networks. To claim that some hardware vendor should be entitled to override the operators wishes just because they don’t like the implications is silly.

Do I think that network operators _SHOULD_ allocate more than one address per client? Absolutely.
Do I think that it is IETF or Google’s or Lorenzo’s place to say that they MUST? Absolutely not.
Heck, I’d like to see ISPs required to hand out /48s per site regardless of customer type or size.

Nonetheless, the operator pays for and builds the infrastructure, the operator deals with registering the address and takes responsibility (at least in the enterprise case) for the goings on on the operator’s network. As such, yes, the operator gets to absolutely decide what resources any given host is allowed on their network.

> I'm willing to concede that network operators need to allocate more than one IPv6 address per client.. Furthermore, I think it is very important that all major operating systems allow for both IPv6…

I’m willing to concede that they should. I’m also willing to accept android shutting down its IPv6 stack if it wants to throw a temper tantrum over the resource constraints of the network it’s trying to attach to. I’m not willing to take that next step and say that operators should be dictated to by IETF, Google, Lorenzo, et. al.

> I'm having visions of IETF becoming not unlike the Texas legislature in its desire to dictate "morality".

Yeah, let’s let every android user sue for $10,000 if they can’t get their preferred number of addresses… Yay.

Owen

---

From: David Farmer <[email-masked]>
Date: Fri, 8 Oct 2021 15:58:59 -0500

On Fri, Oct 8, 2021 at 1:36 PM STARK, BARBARA H <[email-masked]> wrote:

>
>
> *From:* David Farmer <[email-masked]>
>
>
> that N>1.
> 2. In effect Android already enforces, N>1, by only supporting the
> - RFC7934 is scoped to “general-purpose end hosts” (which is not defined
> and therefore you can define the term any way that makes sense for you).
> RFC7934 is very specifically **not** scoped to all hosts.
>

Are all Android devices general-purpose? Probably not. However, the
overwhelming majority are, at least by my understanding of the intent of
RFC7934. So, it doesn't seem unreasonable to me for Android to treat all
Android devices as general-purpose from a device implementation
perspective. Therefore, I think RFC7934 applies, but more importantly the
makers of Android seem to think it applies to their devices.

>  - I used the term “private network operators” in my comment and not
> “network operators”. Just to be clear, “private network operators” include
> enterprises, small businesses, and home owners and not ISPs. I make no
> statement about ISPs. So you’re saying that I should not be allowed to
> operate my home network any way I want (so long as that doesn’t interfere
> with others’ rights – e.g., doesn’t allow my devices or my network to be
> used as part of a DDoS attack) because the IETF has claimed it has rights
> to dictate my home network and device addressing policies? <sarcasm>Maybe
> IETF should encourage legislators to pass a law that anyone can sue
> somebody (bounty of $10k?) for helping a home network owner subvert an IETF
> BCP.
>

And, you seem to be saying the makers of Android have no right to determine
what protocols they will implement in their products.

You have the right to determine the rules for your network, but you don't
have the right to expect every product on the market to be compatible with
all the rules you choose. Of course you have the right to choose not to buy
those products. And, the makers of products have the right to choose not to
sell products that are compatible with your rules. That is free enterprise,
and how free markets work.

</sarcasm> And you think that my objection to IETF claiming rights over my
> network is **me** dictating morality? Really? No. I absolutely, 100%,
> claim full ownership of my home network and its policies (other than those
> that could interfere with other living human beings’ networks and devices).
> If you can explain how my only allowing a host to have a single address is
> harmful (presents a security risk) **to somebody else** then let’s
> discuss. If you’re patronizingly trying to prevent me from what you think
> would be self-harm (e.g., allowing home owners to assign just a single
> address might cause some home owners mental anguish) or because you think
> hosts should have rights, then there’s nothing for us to discuss.
>

The IETF's job, in my mind, is to find the middle ground. That is to create
specifications and recommendations that reasonably balance and harmonize
all stakeholders needs, but there has to be some give and take in that.

You have the right to determine the rules for your network, but the makers
of Android have a right to determine the kinds of networks and the
protocols they will support.

That is why I'm saying network operators, public or private, don't have
ultimate and unilateral control, they have, and should have, a lot of
control, but that control is moderated by the makers of equipment, and the
actual users, when they are not directly the operator of the network.

I'm simply trying to find compromise. I very much want Android to implement
DHCPv6. I think the managed-assignment addressing model it provides is
important for lots of reasons, not the least of which is, for use on
networks with highly protected data. However, nothing about the
managed-assignment addressing model and DHCPv6, is incompatible with
allowing, or even requiring, multiple addresses per device. And, the one
and only one addressing model is very much IPv4 thinking, at least in my
opinion. In IPv6 it is very much possible to support multiple managed
addresses at the same time.

If the parties in this dispute dig their heels in, and are not willing to
consider some compromise, we will be stuck with the status quo. I
personally find the status quo unacceptable, and it has our industry in a
very sad state, if I may say so.

> Barbara   // BTW, I changed the <1 to >1 in the quoted text

Well one of them, I changed the other one.

Thanks.

---

From: Owen DeLong <[email-masked]>
Date: Fri, 8 Oct 2021 14:05:29 -0700

> And, you seem to be saying the makers of Android have no right to determine what protocols they will implement in their products.

I’m not sure if that’s Barbara’s intent or not… I will say this:

I think Google/Lorenzo/Android have every right to decide what to put in.

I’m not calling for an RFC that says they have to implement IA_NA.

I’m saying that they SHOULD implement it and that I would like it better if they DID implement it.

I am saying that their failure to implement it is an impediment to IPv6 adoption in the enterprise and some other environments.

Personally, I think that eventually people will simply decide “OK, android, no IPv6 for you, enjoy that CGN NAT4444444 world over
there or possibly this NAT46 environment here.”

But that eventuality will be put off for as long as possible and IPv6 in the enterprise will be procrastinated with it.

Owen

---

From: David Farmer <[email-masked]>
Date: Fri, 8 Oct 2021 16:32:02 -0500

> I doubt that. N<1 would be utterly useless… Perhaps N>1?

Yes, I meant N>1, but let's explore N<1 for a moment ;

One could argue that means NAT, and more specifically Port-Translation NAT.

So, does that mean the IETF needs to specify and equipment vendors
implement Port-Translation NAT for IPv6? I know a lot of network operators,
especially enterprise networks, that at least say they want that. And, you
are saying the network operators should have ultimate and unilateral
control.

Again, network operators, public and private, have, and should have, a lot
of control, but it is not ultimate and unilateral control.

Thanks.

---

From: Ted Lemon <[email-masked]>
Date: Fri, 8 Oct 2021 18:23:21 -0400

It amazes me to see a serious discussion here that's motivated by a belief
about what "most enterprises are doing and why" that isn't based on any
cited data about what and why. It would be awfully nice if this discussion
could be set aside until such data is sourced.

I suspect the reason that most enterprises that aren't deploying IPv6
aren't deploying it is because they see cost and no benefit. Fixing the
DHCPv6 problem, if indeed it is a problem, won't change that.

This is not to say that the individual operational issues people have
discussed here aren't real issues or don't matter, but it would be nice if
we could keep it real. If the problem is that it's not working for you,
that's a valid problem. But it's not necessarily the same problem that
other enterprises are struggling with, if indeed they are struggling with
it at all.

On Fri, Oct 8, 2021 at 4:37 PM Owen DeLong <owen=[email-masked]>
wrote:

> If I operate a network, I don’t think that a host should be able to demand
> N addresses from my network (for any value of N).
>
> Yes, because Android has a large market share, they are, in effect,
> through their refusal to adopt IA_NA, bullying (or at least attempting to
> bully) network operators that choose to implement IPv6.
>
> The client is free to implement whatever minimums to implement its v6
> stack it wants. IETF doesn’t need to weigh in on this, no standardization
> is required.
>
> Network operators by and large own the networks they are operating and
> they should have unilateral control over the numbering decisions on those
> networks. To claim that some hardware vendor should be entitled to override
> the operators wishes just because they don’t like the implications is silly.
>
> Nonetheless, the operator pays for and builds the infrastructure, the
> operator deals with registering the address and takes responsibility (at
> least in the enterprise case) for the goings on on the operator’s network.
> As such, yes, the operator gets to absolutely decide what resources any
> given host is allowed on their network.
>
> I’m willing to concede that they should. I’m also willing to accept
> android shutting down its IPv6 stack if it wants to throw a temper tantrum
> over the resource constraints of the network it’s trying to attach to. I’m
> not willing to take that next step and say that operators should be
> dictated to by IETF, Google, Lorenzo, et. al.
>

---

From: David Farmer <[email-masked]>
Date: Fri, 8 Oct 2021 21:12:52 -0500

> other enterprises are struggling with, if indeed they are struggling with

I'd love to see data too.

Nevertheless, Android not supporting DHCPv6 is a problem. I have it and I
know lots of others that have it too. It has not prevented me from
deploying IPv6 for the most part. As I've said I'm happy to use SLAAC for
general-purpose users. The problem I have is that Android is a
cost-effective and popular platform for many non-general-purposes use
cases. I would like to support IPv6 on the networks supporting these
devices with DHCPv6's managed-assignment addressing model. I'm happy to
provide more than one address, in fact, I have no real interest in setting
a limit at all, maybe a sanity limit like 64 or more, but I would like the
network to assign the addresses, not the devices.

Do I think the lack of DHCPv6 in Android is impeding IPv6 deployment? In
some cases yes and in other cases no. I agree that the lack of DHCPv6 in
Android is just an excuse for many and if that excuse goes away, they will
simply find another excuse to not deploy IPv6. That doesn’t mean there
aren't perfectly valid uses for the managed-assignment addressing model of
DHCPv6, and as I said that model isn't incompatible with allowing or even
requiring multiple addresses.

I think a DHCPv6 client requiring multiple addresses before it fully
enables GUA IPv6 is a reasonable compromise, and I would very much like to
see Android implement a DHCPv6 client on that basis. On the other hand, I'm
not sure requiring 64 addresses before turning on GUA IPv6 is reasonable. I
think requiring an IA_NA and an IA_TA is a reasonable start, but I'd
consider multiple IA_NA or other options.  Note that with IA_TA, it doesn't
make sense to only have one temporary address. A client needs a new IA_TA
when the preferred time expires, so at least one valid but not preferred
address is necessary for temporary addresses to work as intended. So an
IA_NA and an IA_TA would be a minimum of 3 addresses, possibly more
depending on the preferred and valid times of the temporary addresses,
which are under the control of the network operator with IA_TA.

I’m willing to consider other definitions of what multiple addresses mean.
Also, maybe we could look at a DHCPv6 option, to inform the client how many
addresses are available via IA_NA and IA_TA per client. The server could
lie, but the client can ask for more addresses to validate, and if the
server says more than the minimum set by Android addresses are available
I'm not sure what value lying would have.

I like some of the other proposals from earlier in the thread, like DHCPv6
PD and /64-per-host, I even have a feature request for RFC8273 in with my
router vendor, but both of those are really more for general-purpose use
cases. I'm willing to consider something
like draft-ietf-dhc-addr-registration, but I'm not sure the compliance
regimes like PCI and NIST-800-171 will accept that. I'd be willing to try,
but support for something like that is probably years out, I think
something like DHCPv6 with a minimum number of addresses is much more
realistic to implement in the short term.

Thanks

---

From: Alexandre Petrescu <[email-masked]>
Date: Sat, 9 Oct 2021 12:27:33 +0200

Le 08/10/2021 à 18:28, David Farmer a écrit :
>     IETF has no business restricting the rights of device owners and
>     private networks operators to dictate what devices are allowed to do
>     on their network. This sort of prohibition on device owners and
>     private network admins setting host policy would be 100% harmful.
> 
> 
> think it is inappropriate for host implementations to enforce some 
> number of IPv6 addresses be available? Or, are you saying that is 
> completely up to network operators?
> 
> 3. However, by not supporting a DHCPv6 client, Android doesn't support 
> the managed-assignment addressing model of DHCPv6.
> 
> and therefore the managed-assignment addressing model, I'm suggesting it 
> is reasonable for DHCPv6 clients to require the availability of more 
> than one IPv6 address before it enables it's IPv6 stack, and it sounds 
> like Lorenzo is at least open to discuss such a comprise.

"DHCPv6 clients to require availability of more than one IPv6 address"?
or
"Android clients to require availability of ~"?

If the latter, then they have already authored a BCP 'Host Address 
Availability', or something like that.  That requires the availability 
of more than one address.  That BCP is agreed through WG and is twisted 
such as to _almost_ required DHCPv6-PD even though it does not really.

That BCP requires that the provider provides a /64 and it assumes that 
in that /64 there are more than one address.  That BCP forgets that all 
these addresses within a /64 are actually on a single subnet.  But, that 
BCP is good in that it forbids that a single /128 is assigned to a Host. 
  It requires a /64 but at the same time one single /64 is just one 
address, really.

This confusion between one /64 and one address is obvious in many 
contexts.  Operators I talk to ask me why 2^64 addresses are not 
sufficient for my subnets in lab, in cars, etc.  There is no clear 
explanation available in a single at hand, and each time I provide an 
explanation of why /64 is really just one address.

The explanation of why a single /64 is actually one address relies on a 
combination of (1) the 64 IID len mandated by RFC 4291, the 000-prefixed 
addresses, the Ethernet being the basis of all IPv6-over-foo RFCs, on 
the reluctance to propose any non-64 IID, and on the SLAAC specification.

Few people have a broad view of all these documents simultaneously.

> should be able to assign one and only one IPv6 address per client. 

I have not met any such person, on my part.

It might have been the case in year 2003 when GPRS started some 
deployment, but not anymore, especially since that BCP was written.

All operators assign at least a /64 to a requester.  All have their 
minds in comfort with respect to that BCP, because they think a /64 
equals 2^64 addresses.

> also caused by those that insist that assigning one and only one address 
> is a valid IPv6 deployment strategy, and that network operators should 
> have ultimate and unilateral control in this matter.
> 

I agree.

> this issue is equally dictating "morality".

I think many operators should still understand better what IPv6 is and 
that Google IPv6 is just a part of it however large and millionaire (in 
terms of Android devices) might it be.

Alex

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

---

From: Owen DeLong <[email-masked]>
Date: Sat, 9 Oct 2021 09:08:27 -0700

> On Oct 8, 2021, at 14:32 , David Farmer <farmer=[email-masked]> wrote:
> 
> 
> 
> On Fri, Oct 8, 2021 at 3:36 PM Owen DeLong <owen=[email-masked] <mailto:[email-masked]>> wrote:
> 
> 
>> On Oct 8, 2021, at 9:28 AM, David Farmer <farmer=[email-masked] <mailto:farmer=[email-masked]>> wrote:
>> 

Ewww

> 
> So, does that mean the IETF needs to specify and equipment vendors implement Port-Translation NAT for IPv6? I know a lot of network operators, especially enterprise networks, that at least say they want that. And, you are saying the network operators should have ultimate and unilateral control.  

Please no. We didn’t specify it (until it was widely deployed) in IPv4 and I think sending the signal that it SHOULD NOT be standardized in IPv6 is perfectly fine.

In IPv4, it was a work around for an address shortage. If IPv6 experiences such an address shortage, I’ll accept that we might need to consider such a thing. Short of that, code is available, operators are free to deploy it if they really want it, but I don’t think we should sanction it.

OTOH, IA_NA is already sanctioned and android’s failure to implement it is delaying IPv6 adoption in the enterprise.

I don’t know of anyone whose desire for IPv6 PAT has delayed enterprise adoption beyond the point where the ability to use stateful inspection without NAT was adequately explained to them.

> Again, network operators, public and private, have, and should have, a lot of control, but it is not ultimate and unilateral control. 

Fine, but IA_NA is standardized and SHOULD be implemented on any IPv6 host with sufficient capabilities to do so.

Owen

---

From: Gert Doering <[email-masked]>
Date: Sat, 9 Oct 2021 18:16:05 +0200

Hi,

On Sat, Oct 09, 2021 at 09:08:27AM -0700, Owen DeLong wrote:
> I don???t know of anyone whose desire for IPv6 PAT has delayed enterprise adoption beyond the point where the ability to use stateful inspection without NAT was adequately explained to them.

IPv6 NAT solutions exist, so that point is moot anyway...

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: Owen DeLong <[email-masked]>
Date: Sat, 9 Oct 2021 14:00:20 -0700

> On Oct 8, 2021, at 15:23 , Ted Lemon <[email-masked]> wrote:
> 
> It amazes me to see a serious discussion here that's motivated by a belief about what "most enterprises are doing and why" that isn't based on any cited data about what and why. It would be awfully nice if this discussion could be set aside until such data is sourced.
> 
> I suspect the reason that most enterprises that aren't deploying IPv6 aren't deploying it is because they see cost and no benefit. Fixing the DHCPv6 problem, if indeed it is a problem, won't change that.

That’s a valid and true statement. However, I’m seeing enterprises that have Indian contractors that are having difficulties because said contractors are now in a position of needing IPv6 VPNs and IPv6 access to their client’s resources in order to fulfill their contracts.

Many of those enterprises do see benefit to deploying IPv6 and would prefer to just deploy it generally to avoid the hassles associated with figuring out exactly what the contractors need access to and making IPv6 work only there.

Among those, the chief reason not to just fully deploy IPv6 is the inability to have positive addressing control and still support android devices.

> This is not to say that the individual operational issues people have discussed here aren't real issues or don't matter, but it would be nice if we could keep it real. If the problem is that it's not working for you, that's a valid problem. But it's not necessarily the same problem that other enterprises are struggling with, if indeed they are struggling with it at all.

It’s not working for a number of clients I’ve discussed the matter with. It’s fine for me personally as I don’t have to support android devices on my network, they just don’t get v6 addresses on my network.

However, many of my enterprise clients have deemed this unacceptable and won’t deploy IPv6 in the LAN or WLAN until they have a solution for positive address control that includes android.

Owen

> 
> On Fri, Oct 8, 2021 at 4:37 PM Owen DeLong <owen=[email-masked] <mailto:[email-masked]>> wrote:
> 
> 
> https://www.ietf.org/mailman/listinfo/v6ops <https://www.ietf.org/mailman/listinfo/v6ops>

---

From: "STARK, BARBARA H" <[email-masked]>
Date: Sun, 10 Oct 2021 17:09:09 +0000

In-line, with <bhs2>.
Barbara

Ok, the IETF shouldn't pick N, I'm ok with that. But, does that mean you think it is inappropriate for host implementations to enforce some number of IPv6 addresses be available? Or, are you saying that is completely up to network operators?
<bhs2> My primary objection is to the suggestion that IETF should specify "N". Host devices (including malware and privacy-violating IP-enabled TVs that scan the local network and use microphones to listen to sounds inside the home, etc) will do whatever they want. I think a lot of the things host implementations do are inappropriate. Personally, I do think it's inappropriate for my DVRs, DVD player, oven, refrigerator, and TVs to have lots of GUA IPv6 addresses. This makes it really hard for me to track what devices are on my home network. But that's neither here nor there. This is IETF. I think for IETF to recommend "N" (because no matter how much a BCP might say "MUST", it's still only a recommendation) for all devices is highly inappropriate.</bhs2>
 I will note a few things;
 1. The IETF hasn't picked a value of  N, but it has, through RFC7934, said that N>1.
<bhs2> For "general-purpose" devices, only.</bhs2>
2. In effect Android already enforces, N>1, by only supporting the self-assigned addressing model of SLAAC.
3. However, by not supporting a DHCPv6 client, Android doesn't support the managed-assignment addressing model of DHCPv6.
 In an effort to find a compromise that allows Android to support DHCPv6 and therefore the managed-assignment addressing model, I'm suggesting it is reasonable for DHCPv6 clients to require the availability of more than one IPv6 address before it enables it's IPv6 stack, and it sounds like Lorenzo is at least open to discuss such a comprise.
<bhs2> Android is already allowed (by IETF, legally, etc - by pretty much everyone except Google) to support DHCPv6. IETF doesn't need to take any action, whatsoever, to "allow" Android to support DHCPv6. BTW, my Chromecast (which I'm guessing is not Android) has a single DHCPv6-assigned address. It seems to work just fine. But I wouldn't characterize it as general-purpose.</bhs2>
 However, it seems that some people are insisting that network operators should be able to assign one and only one IPv6 address per client. Personally, I think this argument is utterly futile, is creating a deadlock, and it is holding back the deployment of IPv6. However, this deadlock is not caused only by Android not supporting DHCPv6, but it is also caused by those that insist that assigning one and only one address is a valid IPv6 deployment strategy, and that network operators should have ultimate and unilateral control in this matter.
<bhs2> Why does my Chromecast need multiple IPv6 addresses assigned to it? And why is my assigning my Chromecast a single IPv6 address not a valid strategy? It sure makes it easy for me to see what my Chromecast is doing. I like being able to see what devices are doing inside my home network. Unlike some people in IETF, I don't think the Internet (or my LAN branch of it) is for host devices (to do whatever they want and dictate to people what the people are and aren't allowed to do wrt managing a home network). </bhs2>
I'm willing to concede that network operators need to allocate more than one IPv6 address per client.. Furthermore, I think it is very important that all major operating systems allow for both IPv6 address assignment models, self-assigned (SLAAC) and managed-assignment (DHCPv6).
 <bhs2> I agree. And all but one major OS already does.</bhs2>
I'm having visions of IETF becoming not unlike the Texas legislature in its desire to dictate "morality".
Barbara

<bhs> Just a few points:

Are all Android devices general-purpose? Probably not. However, the overwhelming majority are, at least by my understanding of the intent of RFC7934. So, it doesn't seem unreasonable to me for Android to treat all Android devices as general-purpose from a device implementation perspective. Therefore, I think RFC7934 applies, but more importantly the makers of Android seem to think it applies to their devices.

<bhs2> My husband's Nook eReader is an Android device. I wouldn't classify it as general-purpose. But I only let that device connect to my guest network (along with the Nest devices, where they hopefully can't threaten the rest of my network). It does get SLAAC there. But I don't see any reason why it needs multiple IPv6 GUA addresses. </bhs2>
 - I used the term "private network operators" in my comment and not "network operators". Just to be clear, "private network operators" include enterprises, small businesses, and home owners and not ISPs. I make no statement about ISPs. So you're saying that I should not be allowed to operate my home network any way I want (so long as that doesn't interfere with others' rights - e.g., doesn't allow my devices or my network to be used as part of a DDoS attack) because the IETF has claimed it has rights to dictate my home network and device addressing policies? <sarcasm>Maybe IETF should encourage legislators to pass a law that anyone can sue somebody (bounty of $10k?) for helping a home network owner subvert an IETF BCP.

<bhs2> That's not at all what I'm saying. Google owns the Android OS and I'm not aware of any country or international law that says Google doesn't have the right to determine what protocols to implement. Which means they do have the right. Furthermore, I support their right. But that doesn't mean I have to approve of their doing this. And it certainly doesn't mean IETF needs to bless this decision or try to negotiate a way for Google to agree to add support for IA_NA. I'm saying IETF has no business blessing this decision or negotiating away other device manufacturer and user/people rights in order to get Google to support IA_NA. </bhs2>

You have the right to determine the rules for your network, but you don't have the right to expect every product on the market to be compatible with all the rules you choose. Of course you have the right to choose not to buy those products. And, the makers of products have the right to choose not to sell products that are compatible with your rules. That is free enterprise, and how free markets work.

<bhs2> Agreed. Which is why there are no Android devices on my primary home network, and no general-purpose Android devices on any part of my network.</bhs2>

</sarcasm> And you think that my objection to IETF claiming rights over my network is *me* dictating morality? Really? No. I absolutely, 100%, claim full ownership of my home network and its policies (other than those that could interfere with other living human beings' networks and devices). If you can explain how my only allowing a host to have a single address is harmful (presents a security risk) *to somebody else* then let's discuss. If you're patronizingly trying to prevent me from what you think would be self-harm (e.g., allowing home owners to assign just a single address might cause some home owners mental anguish) or because you think hosts should have rights, then there's nothing for us to discuss.

The IETF's job, in my mind, is to find the middle ground. That is to create specifications and recommendations that reasonably balance and harmonize all stakeholders needs, but there has to be some give and take in that.

You have the right to determine the rules for your network, but the makers of Android have a right to determine the kinds of networks and the protocols they will support.

That is why I'm saying network operators, public or private, don't have ultimate and unilateral control, they have, and should have, a lot of control, but that control is moderated by the makers of equipment, and the actual users, when they are not directly the operator of the network.

I'm simply trying to find compromise. I very much want Android to implement DHCPv6. I think the managed-assignment addressing model it provides is important for lots of reasons, not the least of which is, for use on networks with highly protected data. However, nothing about the managed-assignment addressing model and DHCPv6, is incompatible with allowing, or even requiring, multiple addresses per device. And, the one and only one addressing model is very much IPv4 thinking, at least in my opinion. In IPv6 it is very much possible to support multiple managed addresses at the same time.

<bhs2> I agree it would be nice if Android implemented IA-NA. But I'm not willing to negotiate away my right to buy non-Android devices that support just a single IA_NA address in order to achieve that. This isn't something I'm willing to compromise on. If Android wants to implement IA_NA in a way that requires 5 or 10 or 20 addresses to be then it already has that right - there's nothing stopping it (outside Google). Just like it has the right (as we have established above) not to do IA_NA, at all. IETF doesn't need to say or write anything for Android to be able to do this. No negotiation needed. What you're suggesting, is to negotiate away current capabilities that people have from other devices in exchange for Android to allow its OS a little more freedom. It's like a hostage negotiation. I object strongly to such negotiation.</bhs2>

If the parties in this dispute dig their heels in, and are not willing to consider some compromise, we will be stuck with the status quo. I personally find the status quo unacceptable, and it has our industry in a very sad state, if I may say so.

Thanks.

---

From: Philip Homburg <[email-masked]>
Date: Sun, 10 Oct 2021 22:26:52 +0200

>is at least open to discuss such a comprise.

There is one thing I don't quite understand in this discussion. For a
long time it seemed to be the position of Andoid devs that only SLAAC could
support the number of addresses Android needs. DHCP IA_NA was not suitable.

Now we are having a discussion whether networks should for example support 
64 addresses using IA_NA.

Android is not a new operating system with many unexpected features. 
Android 12 was released recently. I don't know for how long I have had
android devices connect to my network using IPv6, but it is quite a 
few years.

In all that time, I never noticed the android device using more than one
or two IPv6 addresses.

Now obviously I'm not pushing my phone enough that I don't see it using
more than, say, 10 addresses. I'm a bit curious, what are those extra
addresses for? Addresses that are so special, you need them immediately
when connecting to the network.

The strange thing is, my laptop has quite a few IPv4 address. Each VM with a 
network in bridge mode gets its own address for the guest. Addresses 
get added when VMs get started. And expire as stopped VMs fail to 
renew leases.

Why is it that android is so special, it cannot dynamically request more
addresses when it needs them?

---

From: Clark Gaylord <[email-masked]>
Date: Sun, 10 Oct 2021 17:04:39 -0400

The predictability of assigned/managed addresses is less a problem for your
arbitrary client/phone and more of an issue for the potential use case, for
example, of IoT/instrumentation devices where the endpoints are perceived
to need more active management than the typical phone.

--ckg

On Sun, Oct 10, 2021, 16:27 Philip Homburg <[email-masked]>
wrote:

> and

---

From: Owen DeLong <[email-masked]>
Date: Sun, 10 Oct 2021 16:45:49 -0700

> On Oct 7, 2021, at 00:04 , Lorenzo Colitti <[email-masked]> wrote:
> 
> On Thu, Oct 7, 2021 at 3:57 AM Owen DeLong <[email-masked] <mailto:[email-masked]>> wrote:
> Ok, so remove that text and just say: all general-purpose DHCPv6 clients are entitled to receive N addresses, and that any client that does not enable IPv6 if it does not get at least N addresses is in compliance with IETF specifications.
> 
> If this is not acceptable, then why not? It looks like you're making a point of principle here: network operators should be able to set policies on how many IPv6 addresses are handed out, but hosts should not be able to set policies on how many IPv6 addresses they accept. Why the asymmetry?

You’re absolutely free to do so. Nothing in IETF specs says that you can’t turn off the IPv6 stack if you don’t get N addresses for whatever value of N you want.

As such, I guess we’re in agreement and you can go enable IA_NA now. No IETF effort required.

> Sorry. that was a typo. As you say, IPv4 has nothing to do with this. What I meant to say was, "disabling the IPv6 stack”.

In that case, go for it with my blessing.

Owen

---

From: Owen DeLong <[email-masked]>
Date: Sun, 10 Oct 2021 17:14:09 -0700

Alexandre,

You’re fighting a different battle than the one most people in this thread care about.

I’m not saying it’s not a good fight, but fighting uphill with 3GPP and Lorenzo on the 3GPP interface(s) is not what is delaying
enterprise IPv6 rollout.

Support for IA_NA on the WLAN interface(s) is the key issue here.

To the best of my knowledge, everyone EXCEPT android supports that.

Owen

> On Oct 7, 2021, at 06:18 , Alexandre Petrescu <[email-masked]> wrote:
> 
> 
> 
> I agree, having even a limited DHCP (maybe only IA_PD, or only address registering, or other limitations) working on Android on a cellular modem would be a significant achievement.
> 
> One such limitation is 'stateless DHCP'.  It is a 'may' in 3GPP documents.  However, even that simple limited DHCPv6 is prohibited in 3GPP modems.
>

---

From: Owen DeLong <[email-masked]>
Date: Sun, 10 Oct 2021 17:16:19 -0700

> On Oct 7, 2021, at 06:20 , STARK, BARBARA H <[email-masked]> wrote:
> 
>>> but hosts should not

Agreed, but the device manufacturer, OTOH, is somewhat in control of what their device will or won’t do and if Lorenzo/Google want to impose that limitation on their implementation, the IETF shouldn’t be able to stop them any more than it should be able to dictate that they must do so.

Guess what, Lorenzo… That’s the current situation. The IETF is mute on how many devices must be provided via IA_NA or whether or not you can implement some minimum acceptable number or disable the IPv6 stack as a result.

Therefore, you are not prohibited from doing so.

Owen

---

From: Lorenzo Colitti <[email-masked]>
Date: Mon, 11 Oct 2021 12:35:00 +0900

On Mon, Oct 11, 2021 at 9:16 AM Owen DeLong <owen=
[email-masked]> wrote:

> Agreed, but the device manufacturer, OTOH, is somewhat in control of what
> their device will or won’t do and if Lorenzo/Google want to impose that
> limitation on their implementation, the IETF shouldn’t be able to stop them
> any more than it should be able to dictate that they must do so.
>
> Guess what, Lorenzo… That’s the current situation. The IETF is mute on how
> many devices must be provided via IA_NA or whether or not you can implement
> some minimum acceptable number or disable the IPv6 stack as a result.
>

Ok, but would that solve the issue in this thread?

Suppose an OS developer ships a DHCPv6 implementation that requires N
addresses and does not enable the IPv6 stack unless it receives all of
them. How does that do anything to address statements such as, "my network,
my rules" that have been made on this thread? Any operator that wants to
assign only one address per device still cannot use such hosts on their
network, and can still criticise the implementation for not doing what they
want.

What I think David was suggesting is: if we reach consensus on some
reasonable value of N, then the IETF could write a BCP to that effect. That
would help to some extent, because if an operator complains that the
implementation does not work on a network that has N=1, the OS developer
could point to the BCP as justification for why.

---

From: Owen DeLong <[email-masked]>
Date: Sun, 10 Oct 2021 21:36:40 -0700

> On Oct 10, 2021, at 20:35 , Lorenzo Colitti <lorenzo=[email-masked]> wrote:
> 
> On Mon, Oct 11, 2021 at 9:16 AM Owen DeLong <owen=[email-masked] <mailto:[email-masked]>> wrote:
> Suppose an OS developer ships a DHCPv6 implementation that requires N addresses and does not enable the IPv6 stack unless it receives all of them. How does that do anything to address statements such as, "my network, my rules" that have been made on this thread? Any operator that wants to assign only one address per device still cannot use such hosts on their network, and can still criticise the implementation for not doing what they want.

At least it provides a possible way forward for networks that don’t want to assign addresses outside of IA_NA or IA_PD to provide addressing to android devices.

Surely a single IA_NA + a routed IA_PD would meet your requirements, right?

> What I think David was suggesting is: if we reach consensus on some reasonable value of N, then the IETF could write a BCP to that effect. That would help to some extent, because if an operator complains that the implementation does not work on a network that has N=1, the OS developer could point to the BCP as justification for why.

I don’t think that’s really necessary. I think there are already adequate documents about single-address is less than ideal in the existing RFCs/BCPs.

Owen

---

From: Lorenzo Colitti <[email-masked]>
Date: Mon, 11 Oct 2021 15:12:38 +0900

On Mon, Oct 11, 2021 at 1:36 PM Owen DeLong <owen=
[email-masked]> wrote:

> At least it provides a possible way forward for networks that don’t want
> to assign addresses outside of IA_NA or IA_PD to provide addressing to
> android devices.
>

IA_PD, even by itself without IA_NA, has none of the concerns in this
thread. RFC 7934 explicitly recommends it, actually. Not sure if enterprise
network operators can or would want to deploy IA_PD though. Is that
something that we can nudge the industry towards?

> I don’t think that’s really necessary. I think there are already adequate
> documents about single-address is less than ideal in the existing RFCs/BCPs.
>

The existing BCPs also say that running an IA_NA-only network is not
recommended, but that doesn't prevent folks from saying it's necessary. I
think we'd want to make a stronger statement than that.

---

From: Vasilenko Eduard <[email-masked]>
Date: Mon, 11 Oct 2021 08:33:02 +0000

Ø  I don’t know of anyone whose desire for IPv6 PAT has delayed enterprise adoption beyond the point where the ability to use stateful inspection without NAT was adequately explained to them.
Then how to deal with the MHMP environment?
If the host has 2 addresses from different providers (for redundancy) then how to properly choose combination {source IP, next hop} for a particular session?
Any implementation of RFC 8028?
IPv4 was using Private IP for such site with ad-hoc NAT translation on gateways to specific Carrier.

Ed/
From: v6ops [mailto:[email-masked]] On Behalf Of Owen DeLong
Sent: Saturday, October 9, 2021 7:08 PM
To: David Farmer <farmer=[email-masked]>
Cc: v6ops list <[email-masked]>; Owen DeLong <owen=[email-masked]>
Subject: Re: [v6ops] Implementation Status of PREF64

On Oct 8, 2021, at 14:32 , David Farmer <farmer=[email-masked]<mailto:farmer=[email-masked]>> wrote:

On Fri, Oct 8, 2021 at 3:36 PM Owen DeLong <owen=[email-masked]<mailto:[email-masked]>> wrote:

On Oct 8, 2021, at 9:28 AM, David Farmer <farmer=[email-masked]<mailto:farmer=[email-masked]>> wrote:

Ewww

Owen

---

From: Vasilenko Eduard <[email-masked]>
Date: Mon, 11 Oct 2021 08:43:08 +0000

+1
The discussion is strange for me too.
I could not imagine the motivation behind "many IP addresses".

Ed/
-----Original Message-----
From: v6ops [mailto:[email-masked]] On Behalf Of Philip Homburg
Sent: Sunday, October 10, 2021 11:27 PM
To: [email-masked]
Cc: David Farmer <farmer=[email-masked]>
Subject: Re: [v6ops] Implementation Status of PREF64

>and therefore the managed-assignment addressing model, I'm suggesting 
>it is reasonable for DHCPv6 clients to require the availability of more 
>than one
>IPv6 address before it enables it's IPv6 stack, and it sounds like 
>Lorenzo is at least open to discuss such a comprise.

There is one thing I don't quite understand in this discussion. For a long time it seemed to be the position of Andoid devs that only SLAAC could support the number of addresses Android needs. DHCP IA_NA was not suitable.

Android is not a new operating system with many unexpected features. 
Android 12 was released recently. I don't know for how long I have had android devices connect to my network using IPv6, but it is quite a few years.

In all that time, I never noticed the android device using more than one or two IPv6 addresses.

Now obviously I'm not pushing my phone enough that I don't see it using more than, say, 10 addresses. I'm a bit curious, what are those extra addresses for? Addresses that are so special, you need them immediately when connecting to the network.

The strange thing is, my laptop has quite a few IPv4 address. Each VM with a network in bridge mode gets its own address for the guest. Addresses get added when VMs get started. And expire as stopped VMs fail to renew leases.

Why is it that android is so special, it cannot dynamically request more addresses when it needs them?

---

From: Alexandre Petrescu <[email-masked]>
Date: Mon, 11 Oct 2021 11:05:51 +0200

> I’m not saying it’s not a good fight, but fighting uphill with 3GPP and Lorenzo on the 3GPP interface(s) is not what is delaying

Thanks for the clarification.

> Support for IA_NA on the WLAN interface(s) is the key issue here.

Thanks for clarifying it.

To me, IA_NA on WLAN for Android is easy to deal with.  We already 
built, installed and configured several Android smartphones with 
multiple DHCPv6 clients on Android WiFi interfaces.  It is at research 
scale, not at industry-wide deployment scale, but it worked fine.

An enterprise network might deploy its own DHCPv6 .apk's into employee's 
Android smartphones, for that particular enterprise network.

Beyond that, maybe what IA_NA-WLAN-Android effort wants is to have these 
.apk's built into the Android smartphones and tablets?  Or maybe try to 
have these DHCPv6 .apk's accepted in the respective Store?  Has somebody 
tried to submit them?  What was the reply from the store owner?

As a side note, that problem - have DHCPv6 .apk's accepted into the 
respective store - is probably as hard as persuading github to put their 
servers on IPv6.

Alex

---

From: David Farmer <[email-masked]>
Date: Mon, 11 Oct 2021 10:58:22 -0500

On Sun, Oct 10, 2021 at 10:35 PM Lorenzo Colitti <lorenzo=
[email-masked]> wrote:

>> Guess what, Lorenzo… That’s the current situation. The IETF is mute on
>> how many devices must be provided via IA_NA or whether or not you can
>> implement some minimum acceptable number or disable the IPv6 stack as a
>> result.
>>

I think additional guidance on DHCPv6 deployment is clearly needed,
probably including the trade-offs (pro and cons) and other details related
to such deployments in various contexts. It’s not clear to me if this is
best accomplished through a BCP or an Informational document. Furthermore,
I believe the most important BCP of N>1 has already been made in RFC7934. I
have an open mind on whether or not additional BCP recommending a
particular value of N for DHCPv6 IA_NA and/or IA_TA will be useful.
However, at the very least I think a discussion of these issues in an
Informational document is called for.

I will add, there are two values of N to consider; The first being, what is
a reasonable limit, if any, for a DHCPv6 server to impose on the number of
IPv6 address it will provide to a client, this is likely a
larger number, maybe even 64 or larger. Second, what is a reasonable limit,
if any, for a DHCPv6 client to impose before configuring GUA IPv6
addresses, this is likely a smaller number, maybe even as few as 2 or 3.
Also, do these apply to IA_NA or IA_TA, or a combination of the two?

Thanks.

---

From: Owen DeLong <[email-masked]>
Date: Mon, 11 Oct 2021 09:00:21 -0700

> On Oct 10, 2021, at 23:12 , Lorenzo Colitti <lorenzo=[email-masked]> wrote:
> 
> On Mon, Oct 11, 2021 at 1:36 PM Owen DeLong <owen=[email-masked] <mailto:[email-masked]>> wrote:
> IA_PD, even by itself without IA_NA, has none of the concerns in this thread. RFC 7934 explicitly recommends it, actually. Not sure if enterprise network operators can or would want to deploy IA_PD though. Is that something that we can nudge the industry towards?

I see no reason that enterprise operators would need to oppose IA_PD as the prefix is entirely accountable to the authenticated device.

However, they’re not going to want IA_PD addresses on the directly attached interface. They’re going to want IA_NA there and to route the IA_PD prefix to the host via ND resolution of the MAC of it’s IA_NA address.

> The existing BCPs also say that running an IA_NA-only network is not recommended, but that doesn't prevent folks from saying it's necessary. I think we'd want to make a stronger statement than that.

I don’t think a stronger statement is needed.

Owen

---

From: Ted Lemon <[email-masked]>
Date: Mon, 11 Oct 2021 12:13:43 -0400

On Mon, Oct 11, 2021 at 12:01 PM Owen DeLong <owen=
[email-masked]> wrote:

> However, they’re not going to want IA_PD addresses on the directly
> attached interface. They’re going to want IA_NA there and to route the
> IA_PD prefix to the host via ND resolution of the MAC of it’s IA_NA address.
>
> This isn't really necessary, although it's common practice. If the device
is not going to use the prefix on the DHCP-ward link, it can use the
address on the link it /does/ use the prefix on as its GUA. Its link-local
address on the DHCP-ward link will suffice for routing, and is known to the
DHCP server because that's the address it used to do the IA_PD.

---

From: Owen DeLong <[email-masked]>
Date: Mon, 11 Oct 2021 09:33:06 -0700

> On Oct 11, 2021, at 02:05 , Alexandre Petrescu <[email-masked]> wrote:
> 
> 
> 
> To me, IA_NA on WLAN for Android is easy to deal with.  We already built, installed and configured several Android smartphones with multiple DHCPv6 clients on Android WiFi interfaces.  It is at research scale, not at industry-wide deployment scale, but it worked fine.

I suspect that most enterprises aren’t going to drive their android users that way. Native support for IA_NA on WLAN in the android OS is what is creating an additional barrier to enterprise adoption.

> An enterprise network might deploy its own DHCPv6 .apk's into employee's Android smartphones, for that particular enterprise network.

Most enterprises expect this feature to be built into the OS. I suspect that any IA_NA implementation that became popular would end up in an arms race with Lorenzo disabling them in updates.

> Beyond that, maybe what IA_NA-WLAN-Android effort wants is to have these .apk's built into the Android smartphones and tablets?  Or maybe try to have these DHCPv6 .apk's accepted in the respective Store?  Has somebody tried to submit them?  What was the reply from the store owner?

I’m not up on such efforts, but I think it is safe to say that most enterprises expect the OS to come native with proper DHCP support for each applicable IP stack.

> As a side note, that problem - have DHCPv6 .apk's accepted into the respective store - is probably as hard as persuading github to put their servers on IPv6.

Well… There is progress in that area… GitHub just put some of their resources on IPv6, though GitHub itself still isn’t. As a result, I’ve moved most of the projects I have
any authority over onto Bitbucket because it does have good IPv6 support.

Owen

---

From: David Farmer <[email-masked]>
Date: Mon, 11 Oct 2021 11:37:48 -0500

> something that we can nudge the industry towards?

I think this is a perfectly reasonable option for the general purpose use
case, but I will note there is no clear guidance for the use case of IA_PD
on Hosts, and even the guidance for the use of IA_PD with routers is
somewhat fuzzy or at least incomplete, in my opinion. Nevertheless, this
may or may not be reasonable for special or restricted purpose use cases,
especially when compliance regimes are required, like PCI or NIST-800-171.
I support IA_PA on hosts, but whether or not that is an acceptable
replacement for IA_AN and/or IA_TA for all use cases is very much an open
question, and not entirely a technical question for that matter.

> think we'd want to make a stronger statement than that.

As I said, I'm open to additional BCP, and at a minimum, I think additional
Informational guidance is needed regarding DHCPv6 development.

While that is true for the general purpose use case, there is no guidance
that IA_NA-only is inappropriate for other use cases. And Android is
clearly being used in other use cases. Furthermore, that would seem to mean
a combination of IA_NA and IA_TA is acceptable even for the general purpose
use case.

Thanks.

---

From: Owen DeLong <[email-masked]>
Date: Mon, 11 Oct 2021 10:09:37 -0700

> On Oct 11, 2021, at 09:37 , David Farmer <farmer=[email-masked]> wrote:
> 
> 
> 
> On Mon, Oct 11, 2021 at 1:13 AM Lorenzo Colitti <lorenzo=[email-masked] <mailto:[email-masked]>> wrote:
> I think this is a perfectly reasonable option for the general purpose use case, but I will note there is no clear guidance for the use case of IA_PD on Hosts, and even the guidance for the use of IA_PD with routers is somewhat fuzzy or at least incomplete, in my opinion. Nevertheless, this may or may not be reasonable for special or restricted purpose use cases, especially when compliance regimes are required, like PCI or NIST-800-171. I support IA_PA on hosts, but whether or not that is an acceptable replacement for IA_AN and/or IA_TA for all use cases is very much an open question, and not entirely a technical question for that matter.

At the point where a host solicits and/or accepts IA_PD, it has effectively declared itself to be a router.

Since most android devices have multiple interface and the ability to provide a “hotspot” capability, they are, in fact, routers.

Owen

---

From: David Farmer <[email-masked]>
Date: Mon, 11 Oct 2021 12:52:09 -0500

On Mon, Oct 11, 2021 at 12:09 PM Owen DeLong <owen=
[email-masked]> wrote:

> At the point where a host solicits and/or accepts IA_PD, it has
> effectively declared itself to be a router.
>
> Since most android devices have multiple interface and the ability to
> provide a “hotspot” capability, they are, in fact, routers.
>

Yes, that is technically correct, and I expect most enterprises don't, or
at least don't want to, view Android devices as routers. Also, I expect
extending the network or "tethering" is not acceptable behavior in a PCI
or NIST-800-171 compliance contexts. So, that is part of the challenge for
this approach. and why this may not be an acceptable replacement for IA_AN
and/or IA_TA.

Thanks

---

From: Philip Homburg <[email-masked]>
Date: Mon, 11 Oct 2021 20:47:13 +0200

>    Yes, that is technically correct, and I expect most enterprises
>    don't, or at least don't want to, view Android devices as routers.
>    Also, I expect extending the network or "tethering" is not
>    acceptable behavior in a PCI or NIST-800-171 compliance contexts.
>    So, that is part of the challenge for this approach. and why
>    this may not be an acceptable replacement for IA_AN and/or IA_TA.

I wonder what they are doing the IPv4 case. It is hard stop an IPv4 device
from offering NAT to downstream devices. At least, in the case
where the enterprise does not have full control over the host.

---

From: "STARK, BARBARA H" <[email-masked]>
Date: Mon, 11 Oct 2021 18:57:42 +0000

> where the enterprise does not have full control over the host.

My experience with other smartphones suggests they only support router/hotspot functionality when connected to a radio access network (LTE, 5G). That allows the Wi-Fi to be used to supply the hotspot. I haven't seen the smartphone act as a Backhaul STA and an AP simultaneously. As has been pointed out, this discussion is primarily around Wi-Fi upstream connectivity.
Barbara

---

From: David Farmer <[email-masked]>
Date: Mon, 11 Oct 2021 14:34:54 -0500

On Mon, Oct 11, 2021 at 1:58 PM STARK, BARBARA H <[email-masked]> wrote:

> My experience with other smartphones suggests they only support
> router/hotspot functionality when connected to a radio access network (LTE,
> 5G). That allows the Wi-Fi to be used to supply the hotspot. I haven't seen
> the smartphone act as a Backhaul STA and an AP simultaneously. As has been
> pointed out, this discussion is primarily around Wi-Fi upstream
> connectivity.
> Barbara
>

This has been my experience as well, I haven't seen WiFi to WiFi tethering
provided as an option. But I suppose WiFi to USB or Bluetooth or possibly
other interface types is possible. I've only seen the cellular interface as
the source for tethering to date on smartphones and tablets. But, Internet
sharing on Windows and other OS is equally an issue in this respect.

More generally, by policy, we don’t allow our enterprise network to extend
by the users of the network. We do look for rogue WiFi networks and, to the
extent possible, look for other extensions to our network, this has been
done primarily with IPv4 to date. We are pretty lenient to first offenders,
but employees have been fired and students expelled for repeated offenses.

Nevertheless, explicitly allowing IA_PD could be viewed as explicitly
allowing network extension, and therefore viewed unfavorably especially in
a compliance context.

Thanks.

---

From: Philip Homburg <[email-masked]>
Date: Mon, 11 Oct 2021 21:40:39 +0200

> router/hotspot functionality when connected to a radio access
> network (LTE, 5G). That allows the Wi-Fi to be used to supply the
> hotspot. I haven't seen the smartphone act as a Backhaul STA and
> an AP simultaneously. As has been pointed out, this discussion is
> primarily around Wi-Fi upstream connectivity. 

If it is not some of tethering, then why does android need so many 
IPv6 addresses? Do android devs run a kubernetes cluster on their phones?

I just tried bluetooth tethering between android 11 and android 9. 
Surprisingly, that did not result in IPv6 on downstream phone (I tried
both possibilities). Sharing the 4G connection over wifi does result in
IPv6 on the downstream device.

---

From: Owen DeLong <[email-masked]>
Date: Mon, 11 Oct 2021 17:38:17 -0700

> On Oct 11, 2021, at 10:52 , David Farmer <[email-masked]> wrote:
> 
> 
> 
> On Mon, Oct 11, 2021 at 12:09 PM Owen DeLong <owen=[email-masked] <mailto:[email-masked]>> wrote:
> 
> 
>> On Oct 11, 2021, at 09:37 , David Farmer <farmer=[email-masked] <mailto:farmer=[email-masked]>> wrote:
>> 
>> 
>> 
> Yes, that is technically correct, and I expect most enterprises don't, or at least don't want to, view Android devices as routers. Also, I expect extending the network or "tethering" is not acceptable behavior in a PCI or NIST-800-171 compliance contexts. So, that is part of the challenge for this approach. and why this may not be an acceptable replacement for IA_AN and/or IA_TA.

Agreed… I’m fine with android implementing IA_NA and then duking it out over how many IA_NA/IA_TA addresses it requires to not shut down the IPv6 stack.

Most of the enterprises that I know of holding up IPv6 deployments “because android” are willing to work around this in various ways (It might get a PD, but
the delegated prefix may have significant restrictions or no access to the LAN, etc.)

The clients I’ve talked to are willing to work with the scenario where android only partially breaks on their network as long as it gets at least one IA_NA
address and they can manage that. They don’t mind a user having an android that can open a ticket to be told “yeah, that’s because android’s
iPv6 implementation is broken, here’s Lorenzo’s email.” The don’t want a situation where android just breaks outright because it thinks it created
an address through SLAAC that can’t actually reach anything like it expects (which is what happens currently, because android utterly and in blatant
violation of the RFCs ignores the M bit).

Owen

---

From: Owen DeLong <[email-masked]>
Date: Mon, 11 Oct 2021 17:52:22 -0700

> On Oct 11, 2021, at 11:47 , Philip Homburg <[email-masked]> wrote:
> 

<IMG SRC="https://img.pixers.pics/pho_wat(s3:700/FO/49/51/46/41/700_FO49514641_490d0fb2b8756decd854bfc2cd105cf9.jpg,700,525,cms:2018/10/5bd1b6b8d04b8_220x50-watermark.png,over,480,475,jpg)/stickers-illustration-of-cartoon-three-monkeys-see-hear-speak-no-evil.jpg.jpg”>

Mostly.

Owen

---

From: Lorenzo Colitti <[email-masked]>
Date: Tue, 12 Oct 2021 13:38:46 +0900

> DHCP server because that's the address it used to do the IA_PD.

+1, that's how I think such an implementation would behave.

---

From: Lorenzo Colitti <[email-masked]>
Date: Tue, 12 Oct 2021 13:50:39 +0900

> sharing on Windows and other OS is equally an issue in this respect.

Wifi to wifi tethering has been supported by many Android devices for years.

IIRC it cannot be disabled specifically by the enterprise: if the device is
in managed mode, the enterprise can disable all tethering, and if the
device is owned by the user, there is no way for the enterprise to disable
it. To me this is a clear example of how if networks insist on providing
only one address per device, the outcome will be NAT66 implementations in
those devices.

---

From: "Pascal Thubert (pthubert)" <[email-masked]>
Date: Tue, 12 Oct 2021 08:12:22 +0000

When that’s the case, and the node needs, say, less than 1000 addresses, could we delegate a /118?
This way, we can build a /64 NBMA subnet, which maintains the subnet boundary at /64, but allow routing inside.
We could, e.g., terminate vxlan on the /118 and use routing over them.
I would love to see that…

Pascal

From: v6ops <[email-masked]> On Behalf Of Lorenzo Colitti
Sent: mardi 12 octobre 2021 6:39
To: Ted Lemon <[email-masked]>
Cc: v6ops list <[email-masked]>
Subject: Re: [v6ops] Implementation Status of PREF64

On Tue, Oct 12, 2021 at 1:14 AM Ted Lemon <[email-masked]<mailto:[email-masked]>> wrote:
However, they’re not going to want IA_PD addresses on the directly attached interface. They’re going to want IA_NA there and to route the IA_PD prefix to the host via ND resolution of the MAC of it’s IA_NA address.

This isn't really necessary, although it's common practice. If the device is not going to use the prefix on the DHCP-ward link, it can use the address on the link it /does/ use the prefix on as its GUA. Its link-local address on the DHCP-ward link will suffice for routing, and is known to the DHCP server because that's the address it used to do the IA_PD.

---

From: Alexandre Petrescu <[email-masked]>
Date: Tue, 12 Oct 2021 10:41:01 +0200

>> On Oct 10, 2021, at 23:12 , Lorenzo Colitti
[...]
>> IA_PD, even by itself without IA_NA, has none of the concerns in 
>> this [other] thread. RFC 7934 explicitly recommends it [DHCPv6
>> Prefix Delegation], actually.

I tend to disagree, and I was so disagreeing since the editing of the
respective Internet Draft.

The way RFC7934 is formulated does not so explicitely recommend DHCPv6-PD.

RFC7934 has a text that says 'can':
> Multiple IPv6 addresses can be provided in the following ways: [a
> 3rd bullet is DHCPv6-PD]

In the section 8 "Recommendations", the DHCPv6-PD is a MAY:
> The prefix MAY be provided using DHCPv6 PD, SLAAC with per-device 
> VLANs, or any other means.

Generally speaking, the use of terms 'MAY', 'can', and similar
formulations about possibilities are not real recommendations.  They are 
ways to fend off discussions and pretend to describe compromises.

A real recommendation is capitalized, like in 'it is RECOMMENDED'.  Such 
a formulation is absent from this BCP RFC7934.

Alex

---

From: Mark Smith <[email-masked]>
Date: Tue, 12 Oct 2021 19:45:00 +1100

> I would love to see that…

How many nodes are these NBMA subnets?

Why not give each node a /64? If you're doing flat routing, which it
sounds like you are, a /48 provides 64K /64s.

For GUA address space, APNIC RIR fees amount to about $0.03 Australian
dollars or less per annum (not per month!) for a /48 (and they're
effectively free if your IPv4 address space costs more than IPv6). GUA
/48 space is very, very cheap. (In any organisation paying RIR fees,
there probably isn't a cheaper per-unit cost resource. Pens in the
stationary cupboard cost far more than that.)

If you're using ULA address space, each ULA you generate is a /48, so
for example if your NBMA subnet is 250K nodes, you'll need only 4 x
ULA /48s to give each node a /64.

(With some of the EVPN work that is going on regarding ND proxying to
reduce multicast traffic, it has occurred to me that a lot of
organisations could do a single EVPN across their whole network,
fitting all devices within a single /64. In the 90s, before layer 3
switches, there was a saying - "bridge where you can, route where you
must". A big flat layer 2 domain, if you can do it, is quite a lot
easier. If there is any need for subnet boundaries, it's more likely
to be able to create security domains, although I don't entirely agree
with that, I think zero trust networks is a far better idea.)

Regards,
Mark.

---

From: Gert Doering <[email-masked]>
Date: Tue, 12 Oct 2021 10:45:39 +0200

Hi,

On Tue, Oct 12, 2021 at 08:12:22AM +0000, Pascal Thubert (pthubert) wrote:
> When that???s the case, and the node needs, say, less than 1000 addresses, could we delegate a /118?
> I would love to see that???

This is an interesting comment indeed.

I do not feel comfortable with giving out /64 or larger to "random
devices connecting to Wifi", as that (think "1000 devices in a building")
will drastically increase the number of subnets required for a generic
office building - where a /56 might be sufficient before, with plenty of
headroom, you'd then need a full /48 (or more, if you want/need to keep 
routing aggregated, and have to set aside something like a /52 per 
"end device segment").

Now, "something which will aggregate to a /64 in total, for an arbitrary
number of devices" - like, a /96, given 4 billion addresses each to up to
4 billion devices - would definitely be something nice to have.

But I assume that this is not going to work, as I hear that this is 
not (only) for "things happening inside the device" but also "tethering",
which would require a /64 then.  Which, incidentially, is a use case
not desired in Enterprise context.

Gert Doering
        -- NetMaster

---

From: Alexandre Petrescu <[email-masked]>
Date: Tue, 12 Oct 2021 10:59:56 +0200

Le 12/10/2021 à 02:38, Owen DeLong a écrit :
> 
> 
>> On Oct 11, 2021, at 10:52 , David Farmer <[email-masked] 
>> <mailto:[email-masked]>> wrote:
>> 
>> 
>> 
>> On Mon, Oct 11, 2021 at 12:09 PM Owen DeLong 
>> <owen=[email-masked] 
>> <mailto:[email-masked]>> wrote:
>> 
>> 
>> 
>>> On Oct 11, 2021, at 09:37 , David Farmer 
>>> <mailto:farmer=[email-masked]>> wrote:
>>> 
>>> 
>>> 
>>> On Mon, Oct 11, 2021 at 1:13 AM Lorenzo Colitti 
>>> On Mon, Oct 11, 2021 at 1:36 PM Owen DeLong 
>>> <owen=[email-masked] 
>>> <mailto:[email-masked]>> wrote:
>>> 
>>> Suppose an OS developer ships a DHCPv6 implementation that 
>>> requires N addresses and does not enable the IPv6 stack unless it
>>> receives all of them. How does that do anything to address 
>>> statements such as, "my network, my rules" that have been made on
>>> this thread? Any operator that wants to assign only one address
>>> per device still cannot use such hosts on their network, and can
>>> still criticise the implementation for not doing what they want.
>>> 
>>> At least it provides a possible way forward for networks that 
>>> don’t want to assign addresses outside of IA_NA or IA_PD to 
>>> provide addressing to android devices.
>>> 
>>>  this thread. RFC 7934 explicitly recommends it, actually. Not 
>>> sure if enterprise network operators can or would want to deploy
>>>  IA_PD though. Is that something that we can nudge the industry 
>>> towards?
>>> 
>>> 
>>> I think this is a perfectly reasonable option for the general 
>>> purpose use case, but I will note there is no clear guidance for 
>>> the use case of IA_PD on Hosts, and even the guidance for the use
>>> of IA_PD with routers is somewhat fuzzy or at least incomplete,
>>> in my opinion. Nevertheless, this may or may not be reasonable
>>> for special or restricted purpose use cases, especially when
>>> compliance regimes are required, like PCI or NIST-800-171. I
>>> support IA_PA on hosts, but whether or not that is an acceptable
>>> replacement for IA_AN and/or IA_TA for all use cases is very much
>>> an open question, and not entirely a technical question for that
>>> matter.
>> 
>> Since most android devices have multiple interface and the ability 
>> to provide a “hotspot” capability, they are, in fact, routers.
>> 
>> 
>> So, that is part of the challenge for this approach. and why this 
>> may not be an acceptable replacement for IA_AN and/or IA_TA.
> 
> Agreed… I’m fine with android implementing IA_NA and then duking it 
> out over how many IA_NA/IA_TA addresses it requires to not shut down
>  the IPv6 stack.
> 
> Most of the enterprises that I know of holding up IPv6 deployments 
> “because android” are willing to work around this in various ways (It
> might get a PD, but the delegated prefix may have significant 
> restrictions or no access to the LAN, etc.)
> 
> The clients I’ve talked to are willing to work with the scenario 
> where android only partially breaks on their network as long as it 
> gets at least one IA_NA address and they can manage that. They don’t
>  mind a user having an android that can open a ticket to be told 
> “yeah, that’s because android’s iPv6 implementation is broken, here’s
> Lorenzo’s email.” The don’t want a situation where android just
> breaks outright because it thinks it created an address through SLAAC
> that can’t actually reach anything like it expects (which is what
> happens currently, because android utterly and in blatant violation
> of the RFCs ignores the M bit).

A similar way in which Android might break because it does not do DHCPv6
is in my home setting in a future tense.

My ISP CPE offers both IPv4 and IPv6; for IPv6 it offers either SLAAC or
DHCPv6 but not simultaneously.

In the near future, when I turn off IPv4 at home definitively, and opt
for DHCPv6 on the ISP CPE, the Android tablet will stop being connected
to the Internet even though the Windows PC will continue.

Towards that future, I intermittently turn off IPv4 on my Windows PC to
see how Internet works from home on IPv6, on SLAAC or on DHCPv6.

I dont know whether I will prefer DHCPv6 or SLAAC at home in the future,
but it might be that SLAAC might not cope with several subnets, and an
automated DHCPv6-PD might help.

Alex

---

From: "Pascal Thubert (pthubert)" <[email-masked]>
Date: Tue, 12 Oct 2021 09:15:17 +0000

Hello Gert,

Yes, tethering is another story and that would be for another interface that would not be part of the subnet. 

Here we were talking of the address (range) that is assigned to the Wi-Fi interface, when that is the main connection of the phone, in which case it does not do tethering. So, different story.

Keep safe;

Pascal

> From: Gert Doering <[email-masked]>
> Sent: mardi 12 octobre 2021 10:46
> To: Pascal Thubert (pthubert) <[email-masked]>
> Cc: Lorenzo Colitti <[email-masked]>; Ted Lemon <[email-masked]>;
> v6ops list <[email-masked]>
> > This way, we can build a /64 NBMA subnet, which maintains the subnet
> boundary at /64, but allow routing inside.
> devices connecting to Wifi", as that (think "1000 devices in a
> building") will drastically increase the number of subnets required for
> a generic office building - where a /56 might be sufficient before,
> with plenty of headroom, you'd then need a full /48 (or more, if you
> want/need to keep routing aggregated, and have to set aside something
> like a /52 per "end device segment").
> 
> Now, "something which will aggregate to a /64 in total, for an
> arbitrary number of devices" - like, a /96, given 4 billion addresses
> each to up to
> But I assume that this is not going to work, as I hear that this is not
> (only) for "things happening inside the device" but also "tethering",

---

From: "Pascal Thubert (pthubert)" <[email-masked]>
Date: Tue, 12 Oct 2021 09:22:17 +0000

Hello Mark

As you point out, the idea is to maintain the well-known subnet aggregation boundary at /64,  so for the rest of the world your address plan does not change. If /118 is not enough, give a /112. Wasting "because we can" or "because it's cheap" is very convincing. This leaves a lot of room for future stuff in that subnet without impacting the global plan.

The old saying is s you say, old. We actually route a lot at L2 now (L2R / ISIS, LISP, eVPN, you name it). If we route in the subnet, let's aggregate as well.

Keep safe;

Pascal

> From: Mark Smith <[email-masked]>
> Sent: mardi 12 octobre 2021 10:45
> for example if your NBMA subnet is 250K nodes, you'll need only 4 x ULA
> /48s to give each node a /64.
> 
> easier. If there is any need for subnet boundaries, it's more likely to
> be able to create security domains, although I don't entirely agree
> > This isn't really necessary, although it's common practice. If the
> device is not going to use the prefix on the DHCP-ward link, it can use
> the address on the link it /does/ use the prefix on as its GUA. Its
> link-local address on the DHCP-ward link will suffice for routing, and
> is known to the DHCP server because that's the address it used to do
> the IA_PD.
> >
> >
> >

---

From: Philip Homburg <[email-masked]>
Date: Tue, 12 Oct 2021 11:33:17 +0200

>not desired in Enterprise context.

I don't see why tethering would require a /64. If the downstream devices
supports DHCPv6 IA_NA then it would work just fine.

Actually, for tethering with DHCPv6 IA_NA, you don't need PD. You can just
relay the request from the downstream device. (Whether actually relay,
or generate a new request). Obviously PD would help if ND state in the
first hop router is an issue. 

It is only when the downstream device insists on SLAAC that you would need
a /64.

---

From: Owen DeLong <[email-masked]>
Date: Tue, 12 Oct 2021 08:29:18 -0700

What’s the advantage to this vs. delegating /64s?

If you’ve got a subnet that’s a /64 and you’re using it to route discrete /118s within the subnet, that’s just going
to create net mask confusion among the peers. I suppose if you’re looking to make it difficult for peer to peer
traffic between the delegated subnets, that’s one possible way to do it, but it’s unlikely to be reliable at
preventing peer to peer communication while just creating behaviors that will be confusing to end users that
don’t know the unique characteristics of your particular network in this regard.

Owen

> On Oct 12, 2021, at 01:12 , Pascal Thubert (pthubert) <pthubert=[email-masked]> wrote:
> 
> From: v6ops <[email-masked] <mailto:[email-masked]>> On Behalf Of Lorenzo Colitti
> To: Ted Lemon <[email-masked] <mailto:[email-masked]>>
> Cc: v6ops list <[email-masked] <mailto:[email-masked]>>
> On Tue, Oct 12, 2021 at 1:14 AM Ted Lemon <[email-masked] <mailto:[email-masked]>> wrote:

---

From: Gert Doering <[email-masked]>
Date: Tue, 12 Oct 2021 18:19:14 +0200

Hi,

On Tue, Oct 12, 2021 at 08:29:18AM -0700, Owen DeLong wrote:
> What???s the advantage to this vs. delegating /64s?
> 
> If you???ve got a subnet that???s a /64 and you???re using it to route discrete /118s within the subnet, that???s just going
> to create net mask confusion among the peers. I suppose if you???re looking to make it difficult for peer to peer
> traffic between the delegated subnets, that???s one possible way to do it, but it???s unlikely to be reliable at
> don???t know the unique characteristics of your particular network in this regard.

Right.  My mental model would not us "the same /64 that the wifi is
attached to" but "a chunk of addresses from a second /64".

I strongly dislike the implications of "any larger site that has a wifi
network needs to have a /52 provisioned, so thousands of wifi clients
can have a /64 *each*" on address space management on all layers.

Gert Doering
        -- NetMaster

---

From: Philip Homburg <[email-masked]>
Date: Tue, 12 Oct 2021 18:40:15 +0200

>can have a /64 *each*" on address space management on all layers.

I wonder why this is an issue.

By and large wifi devices have MAC addresses from an 48-bit space. So
we should have enough /64s to give every physical wifi device its own
/64.

Another way of looking at it, the traditional allocation plan is a /48
per site. This gives 64k worth of /64s. So with the exception of
particularly big offices, this is enough for almost everybody.

If we go down to a /56 for home use. You have to quite a collector to
have 256 ethernet devices connected to a home network.

Obviously, sites that are big enough that they have more than 64k 
eithernet devices can get shorter prefixes.

I don't think we should allocate a /64 to every host if the host 
doesn't need one. But it seems that we do have enough space to do so.

As a mental model, provide hosts with unique 64-bit addresses using
DHCP. Then a /48 is equivalent to an IPv4 /16 and a /56 is an IPv4 /24.
Even in a datacenter, it takes quite a bit of space and power to 
exhaust a /48 with 64k devices.

---

From: Gert Doering <[email-masked]>
Date: Tue, 12 Oct 2021 18:47:16 +0200

Hi,

> I wonder why this is an issue.

Because of hierarchy in routing.  Address space allocated is usually
not "flat" as in "you can just use /64s one after another" but there is
routing hierarchy built in - like, "this company has a /48, and needs
to number a few buildings with it" (forming a "site" in whatever 
definition of "site").  Thousands of devices is not a problem with
"part of a /48", but thousands of *subnets* can easily become one.

Yes, you can always construct plans that work for that specific case,
but being wastive with *subnets* is actually not something we can 
trivially afford without wrecking lots of people's existing address
plans, and ruining the ease of building hierarchy with enough wiggle
room on each level.

(ceterum censeo, /64 was not a very smart decision)

Gert Doering
        -- NetMaster

---

From: Owen DeLong <[email-masked]>
Date: Tue, 12 Oct 2021 10:00:19 -0700

> DHCPv6 but not simultaneously.

I’m not sure how this is possible.

The data necessary for SLAAC is in the RA that includes the M bit to tell
the host to go ask the DHCPv6 server for an address, so how would your
CPE prevent the android from doing SLAAC without authorization?

Does it really implement the necessary NAC-like behavior to block the
SLAAC address from the android or are you just guessing here?

Owen

---

From: Philip Homburg <[email-masked]>
Date: Tue, 12 Oct 2021 19:01:45 +0200

>to number a few buildings with it" (forming a "site" in whatever=20

Somehow people managed to number universities with tens of thousands
of students out a single /16 IPv4.

Obviously, if you have an existing network, it is not going to be fun if
suddenly you would have to provide a /64 per device.

That said. Most wifi networks in the world are tiny, and do not benefit at
all from a /64 per device. It would be nice if devices could request
additional /64s for downstream networks. But we have homenet for that.

For big wifi networks, it might make sense to get rid of multicast and
run them as a collection of point-to-point links. In that case, lets make it
an optional feature that can be enabled by the operator.

---

From: Philip Homburg <[email-masked]>
Date: Tue, 12 Oct 2021 19:05:24 +0200

> The data necessary for SLAAC is in the RA that includes the M bit
> to tell the host to go ask the DHCPv6 server for an address, so
> how would your CPE prevent the android from doing SLAAC without
> authorization?

I didn't verify it. But I assume clearing that 'A' bit in the PIO should
prevent android from doing SLAAC. It is not as if rogue android devices
are creating address from every prefix they see.

---

From: David Farmer <[email-masked]>
Date: Tue, 12 Oct 2021 12:24:28 -0500

> SLAAC address from the android or are you just guessing here?

I think the CPE will only set either the A-flag or M-flag but not both at
the same time in the RA and only start up the DHCPv6 process if the M-flag
is set.

However, most CPE I know the Flags are independent, you can set one or the
other or both.

Some, don't let you turn off the A-flag to turn off SLAAC. My
XFINITY(Comcast) Gateway is that way, you can only configure DHCPv6 off or
on, SLAAC is always on. Probably so you can accidentally break IPv6 for
Android.

Thanks

---

From: Gert Doering <[email-masked]>
Date: Tue, 12 Oct 2021 19:41:48 +0200

Hi,

> of students out a single /16 IPv4.

Standard univerisity WiFi deployment today seems to be "RFC1918 space
and a huge NAT box"...

Gert Doering
        -- NetMaster

---

From: David Farmer <[email-masked]>
Date: Tue, 12 Oct 2021 13:38:47 -0500

> Standard univerisity WiFi deployment today seems to be "RFC1918 space

I can tell you why we do this; We have light rail tracks and several major
roads that go through our campus. As a result, several hundred to
thousands, some hours many thousands, of devices, attach to our public WiFI
every hour and never do anything other than getting a DHCPv4 address from
us and maybe probing an aliveness sight of their choice. These devices
usually come and go in a matter of minutes. We would either need
unreasonably short DHCP lease times or use large RFC1918 pools so we don't
have to worry about recovering addresses very quickly.

We intentionally have good WiFi coverage around the three train stations on
campus and for the many bus stops and sidewalks across campus to provide
coverage while people wait for public transportation.

Even for our 802.1x network, we have a very large number of users, +50,000
and they move around campus significantly, and between our mobility
addressing domains, consumption of address varies significantly across the
day in the various parts of campus, up to 10s of thousands in
hourly transitions. For IPv6 addresses, these consumption patterns really
aren’t an issue. However, for IPv4 if we used globally unique addresses we
would need several times the overall usage to compensate for the variation
in consumption patterns.

Hope that helps.

---

From: Owen DeLong <[email-masked]>
Date: Tue, 12 Oct 2021 12:16:50 -0700

> On Oct 12, 2021, at 01:45 , Gert Doering <[email-masked]> wrote:
> 
> Hi,
> 
> office building

Will it? Let’s consider giving a /64 to every device in an office building.

Let’s consider that there are 1,000 other LAN segments for various purposes
in the building. Let’s further suppose that there are 1,000 LAN segments just
for point to point infrastructure, etc.

Now, let’s add 5,000 devices, each of which gets its own subnet. That brings
us to a building total of 7,000 /64s needed.

Assuming the office building gets the recommended /48, you still have
58,636 subnets left over.

> - where a /56 might be sufficient before, with plenty of

You should have gotten a /48 in the first place, so I’m not seeing any
harm here.

> 4 billion devices - would definitely be something nice to have.

I’m really not seeing the benefit here.

There are more than enough /48s to give a few to each building on the
planet and still have plenty left over for Mars, Alpha Centauri, the Moon,
and anywhere else you can foresee us extending the internet.

> not desired in Enterprise context.

I think we are discussing both scenarios and perhaps that makes
it more confusing.

I would propose that generically, it makes almost as much or more
sense to route a prefix to the loopback inside the device as it does
to issue multiple addresses on the LAN segment to the device.

In the former case (routed to loopback), it takes up one slot in
a routing table. In the latter case, each address the device is holding
takes up a slot in the ND Table of each L3 device on the LAN segment.

So the better way to handle this leaves the in-device scenario being
identical to tethering from the LAN perspective, which as you point
out may be undesirable in some enterprises. Personally, I think that
eventually, enterprises are going to have to recognize that the
LAN extensions ship has sailed and that it’s a purely policy and
political issue which cannot be adequately or effectively controlled
through technical means.

Owen

---

From: Owen DeLong <[email-masked]>
Date: Tue, 12 Oct 2021 12:28:54 -0700

> can have a /64 *each*" on address space management on all layers.

Agreed… A /48 is a much better choice than a /52.

Owen

---

From: Owen DeLong <[email-masked]>
Date: Tue, 12 Oct 2021 12:39:43 -0700

> On Oct 12, 2021, at 09:47 , Gert Doering <[email-masked]> wrote:
> 
> Hi,
> 

That company made a mistake and should go back to whatever source
they obtained that /48 from and say “we’ve got X buildings, so we’re
going to need at least X /48s, ideally rounded up to a nibble boundary.”

(e.g. if you’ve got 7 buildings, you really ought to just get a /44, if you’ve
got more than 12 buildings, you ought to get a /40, etc.)

ARIN policy supports this. (I know, in part because I authored the policy).

> plans, and ruining the ease of building hierarchy with enough wiggle

Disagree thoroughly. If you built your addressing plan badly, it probably
needs wrecking and sooner is better than later. The good news is that
you probably don’t have to return the addresses you’ve already deployed
in that way, but the bad news is continuing to use them that way will
tie up a few slots in your routing tables as long as you do.

> (ceterum censeo, /64 was not a very smart decision)

We can agree to disagree. So far, I’ve seen no data to support that.

Owen

---

From: Gert Doering <[email-masked]>
Date: Wed, 13 Oct 2021 18:55:55 +0200

Hi,

On Tue, Oct 12, 2021 at 12:28:54PM -0700, Owen DeLong wrote:
> Agreed??? A /48 is a much better choice than a /52.

For most deployments it is plain not possible to reserve a /48 for "WiFi",
if all they have is a /48 for a whole "site".

Thinking we have arbitrary number of /64s to burn will have a hard landing
when reality comes along.

Gert Doering
        -- NetMaster

---

From: Gert Doering <[email-masked]>
Date: Wed, 13 Oct 2021 18:58:19 +0200

Hi,

On Tue, Oct 12, 2021 at 12:39:43PM -0700, Owen DeLong wrote:
> We can agree to disagree. So far, I???ve seen no data to support that.

Indeed.

So far I have not seen any data that supports "/64 was a good idea" :-)

Gert Doering
        -- NetMaster

---

From: Owen DeLong <[email-masked]>
Date: Wed, 13 Oct 2021 10:23:28 -0700

> On Oct 13, 2021, at 09:55 , Gert Doering <[email-masked]> wrote:
> 
> Hi,
> 

I didn’t propose that. I proposed reserving a /48 for a building, structure,
or tenant within a multi-tenant building or structure, which is the definition
of a site.

Nothing says that all of the Wifi prefixes have to aggregate under a single
prefix within a building or site. It’s not like that will save a significant number
of table slots on a significant number of routers, as the wifi routing probably
doesn’t align that way within the building anyway.

Nonetheless, even if you do allocate a /52 to wifi, that leaves you with
15 other /52s in that /48 to use for everything else. Are you saying that
you can’t number the wired devices in a modern building with 15 /52s?

> when reality comes along.

Will it? Here’s reality…

More than enough /48s in 2000::/3 (1/8th of the total space) to hand out a few
hundred to every building now in existence or likely to ever exist.

A /48 can cover 10,000 wifi users (more than the population of the vast majority
of single-tenant buildings) each getting a /64 spread across 5,000 WiFi
SSIDs/VLANs and still have 50,000+ /64 subnets left over for whatever else
you want to do with them.

We don’t have an arbitrary number of them, but we do have 2+ quintillion
of them just in 2000::/3.

Owen

---

From: Owen DeLong <[email-masked]>
Date: Wed, 13 Oct 2021 10:25:36 -0700

> On Oct 13, 2021, at 09:58 , Gert Doering <[email-masked]> wrote:
> 
> Hi,
> 

It’s working quite well in a number of networks I’ve deployed.

It’s convenient for EUI-64 addressing.

Reviewing the record, it seems we were destined for something like 64-bit
addressing overall before IETF decided to consider EUI-64 addressing and
added 64-bits to the plan, so one can argue that without the idea of
universal /64 addressing we’d have a whole lot fewer network numbers
available.

So now you have seen data to suggest that /64 was a good idea.

Do you have any data support your claim that /64 was not?

Owen

---

From: Gert Doering <[email-masked]>
Date: Wed, 13 Oct 2021 19:34:17 +0200

Hi,

On Wed, Oct 13, 2021 at 10:23:28AM -0700, Owen DeLong wrote:
> Will it? Here???s reality???
> 

You're overlooking intermediate hierarchies, and loss involved with that.

Can it be made to work?  Of course.

Can we have another quintillion for everybody's k8s clusters, and another
one for every desktop PC with VMs on it?  Of course.

Will we wake up to see that the start of this plan wasn't the best of ideas?

So, no, assigning whole /64s to large-numbered device types (unless they 
serve as routers for one or more subnets, in which case I *do* support 
delegating at least one standard-subnet-size per subnet) is not something
I think we should do.  Balance needs to be found.

Gert Doering
        -- NetMaster

---

From: Gert Doering <[email-masked]>
Date: Wed, 13 Oct 2021 19:37:46 +0200

Hi,

On Wed, Oct 13, 2021 at 10:25:36AM -0700, Owen DeLong wrote:
> It???s working quite well in a number of networks I???ve deployed.
> 
> It???s convenient for EUI-64 addressing.
> 
> universal /64 addressing we???d have a whole lot fewer network numbers
> available.
> 

What part of "yeah, it works for me" makes it a *good* idea?

So did /80s, when they were the latest fashion.

What part of "EUI-64" is a *good* idea, now that everyone is actually
moving away from EUI-64, because it has more undesirable properties than
"oh, yeah, it was there and is convenient"?

Nah.  8+8 was a brilliant idea that did not happen - and nothing else
in a /64 is more than "we can't find consensus to change that".

On the downside:

 - it creates pressure on the number of subnets in reasonably structured
   deployments (think of the number of subnets you can have with a /96
   standard subnet size...)

 - ND exhaustion attacks (which arguably would happen in a /96 just as well)

Gert Doering
        -- NetMaster

---

From: Gert Doering <[email-masked]>
Date: Wed, 13 Oct 2021 19:40:01 +0200

Hi,

> to need more active management than the typical phone.

And this is a typical role for an Android mobile device?

And this is so important that a general purpose mobile device can not do
IA_NA/IA_TA, because some special-purpose IoT hub would need something
else?

Not convincing,

Gert Doering
        -- NetMaster

---

From: Owen DeLong <[email-masked]>
Date: Wed, 13 Oct 2021 10:50:33 -0700

> On Oct 13, 2021, at 10:34 , Gert Doering <[email-masked]> wrote:
> 
> Hi,
> 

Nope… Not really…

Let’s divide ISPs into three categories — Small-ish, under 1M subscribers,
probably well served by a /28. Large (between 1M and 5M subscribers,
probably need a /24), and Huge — The Comcast/Verizon/etc. of the world,
who likely need a /12.

I’ll assert that there are probably 2-5 million, so let’s call it 5 million ISPs in the
small-ish category, a million or so in the large category, and maybe 200 world-
wide in the Huge category.

So that’s 5M /28s + 1M /24s + 200 /12s.

5M rounded up to a nibble boundary works out to 24 bits (16.7M), so 
subtracting from a /28, that gets us to a /4 which is 1/2 of 2000::/3.

Issuing a million (20 bits) /24s is another /4, so we’ve burned the other
half of 2000::/3.

Now we need to cover 200 /12s, which we can do from 4000::/3 and
still have 312 /12s to deal with any additional needs that may arise
and even if we burn through all of that, we’ve only used 25% of the
total address space.

> Can it be made to work?  Of course.

Easily.

> one for every desktop PC with VMs on it?  Of course.

Quintillion addresses? Sure, 18 per. That’s a /64.

However, unless you expect an average building to exceed 50,000 such
combinations of devices, that still aggregates to a /48 for the building.

> Will we wake up to see that the start of this plan wasn't the best of ideas?

I doubt it. So far, the math seems to work.

> I think we should do.  Balance needs to be found.

I think so far, there’s no evidence to suggest that /64 is not a good balance point.

The devices in question are, effectively routers, so it seems we agree.

Owen

---

From: Owen DeLong <[email-masked]>
Date: Wed, 13 Oct 2021 10:56:09 -0700

> On Oct 13, 2021, at 10:37 , Gert Doering <[email-masked]> wrote:
> 
> Hi,
> 

Actually, /80s never worked well for me, YMMV.

> "oh, yeah, it was there and is convenient"?

I guess it depends on your idea of undesirable. EUI-64 is working fine if
you don’t consider it a tracking issue (which there are far more effective
trackers these days).

Further, even if you like privacy addressing (frankly, I’m not a fan, but I don’t
care too much), a 64-bit random number is a reasonable size space to make
searching relatively difficult, so it’s still a good idea.

> in a /64 is more than "we can't find consensus to change that".

If it was so brilliant, why was it rejected?

>   deployments (think of the number of subnets you can have with a /96

I’m really not worried about running out of /64s with any rational addressing plan.
See previous messages.

> - ND exhaustion attacks (which arguably would happen in a /96 just as well)

ND exhaustion attacks are a reality the moment you move away from having too
few addresses for the hosts in a decent size subnet to be able to do anything
like meaningful privacy addressing, so I think you lose on that one no matter
what.

The reality is that ND exhaustion attacks will find alternative mitigations, including
rapid garbage collection of unknown ND entries when resources get constrained
and other mechanisms that have larger tradeoffs. Nothing is perfect.

Owen

---

From: Owen DeLong <[email-masked]>
Date: Wed, 13 Oct 2021 10:58:44 -0700

> On Oct 13, 2021, at 10:40 , Gert Doering <[email-masked]> wrote:
> 
> Hi,
> 

A lot of IOT development is using android as a base OS, yes.

Mobile device? Not necessarily, but lots of IoT with WiFi or Ethernet only interfaces
do use android as a base OS.

> IA_NA/IA_TA, because some special-purpose IoT hub would need something

I think he’s arguing that android should do IA_NA/IA_TA not only because of the
situations that desire it for general purpose mobile devices, but also because
it’s even more important for IOT things that are being built on the android platform.

I could be wrong, Clark can certainly correct me if I misunderstood his concern.

Owen

---

From: David Farmer <[email-masked]>
Date: Wed, 13 Oct 2021 14:34:14 -0500

> I could be wrong, Clark can certainly correct me if I misunderstood his

I can speak for Clark, but IOT and other things that are not general
purpose mobile devices are what I'm thinking about.

---

From: "STARK, BARBARA H" <[email-masked]>
Date: Wed, 13 Oct 2021 20:00:50 +0000

> IA_NA/IA_TA, because some special-purpose IoT hub would need something

I think he's arguing that android should do IA_NA/IA_TA not only because of the
situations that desire it for general purpose mobile devices, but also because
it's even more important for IOT things that are being built on the android platform.

Owen

I can speak for Clark, but IOT and other things that are not general purpose mobile devices are what I'm thinking about.

<bhs> When I look at the Nook eReader that uses the Android OS, I notice that it just references a bunch of Open Source Apache 2.0 licenses for the Android OS components they use. To me, this says IoT devices are in no way beholden to a Google app store or Google restrictions around what goes into an Android smartphone. I see on https://source.android.com/devices/architecture/modular-system/networking that it says Android 10 included a DhcpClient component that "obtains IP addresses from DHCP servers so they can be assigned to interfaces". So it sounds like IoT devices that use Android already have the ability (if the manufacturer wants) to support IA_NA?

---

From: Simon <[email-masked]>
Date: Wed, 13 Oct 2021 21:03:23 +0100

Owen DeLong <owen=[email-masked]> wrote:

> Most enterprises expect this feature to be built into the OS.

Indeed, the days of having to install pieces of software to get BASIC network functions is so ... last century. Brings back not so fond memories of having to pick an IP implementation (actually, pick a protocol and implementation), and then juggle with your load order to maximise hi-mem in DOS, and all that stuff.

How long is it now since anything without IPv4 built in would be considered “broken” - and yet we’re still considering (or at least, some people are suggesting) that IPv6 should be held back to how networking was several decades ago !

Not to put too fine a point on it, but I have seen no argument against Android including standards compliance and a working DHCPv6 client other than : “it’s not how we want people to be using the devices they have bought AND SUPPOSEDLY OWN and we’re big enough to force our rules on the world”.

Sorry Lorenzo, but basically the arguments put forward against allowing DHCPv6 client on Android come down to “but we want people to use them THIS way regardless of how they actually want to use it”. Dressed up a bit in the name of “protecting users” which is rich given that Google’s primary business is in amassing and profitting from people’s personal information - so perhaps it’s a more a case of “can’t have others abusing users’ privacy - that’s our job”.

Just saying how it looks.

Simon

---

From: "Pascal Thubert (pthubert)" <[email-masked]>
Date: Wed, 13 Oct 2021 20:08:32 +0000

Hello Owen 

The thing of the past is probably still perfect in some unmanaged networks but I understand that your focus is not those.

/64 came with neatly with EUI 64 as you point out, and we are deprecating that for privacy. 

Switching better than routing in the domain we call a subnet is also becoming obsolete since even when we think we switch we probably route at L2 or in an underlay.

Bottom line is that /64 is still an interesting boundary for backward compatibility and old habits to form a group we call a subnet. But I agree with Gert that we do not need to give that much to every host just to be able to route inside the subnet at L2. 

We can easily route to /112 or even to /128. I’m used to the latter because we build subnets of thousands of nodes in IoT and we know the nodes from a registrar, typically DHCPv6. But I see benefits of giving a prefix to the phone or the PC and let it distribute the addresses to stuff like VMs and tethered nodes.

Why insist on /64 per host? Seems to me that the properties that we want do not depend much on where we cut.

What’s really interesting is to decouple the domain we decide is a subnet from a L2 broadcast domain and from what we see as an IP link. For that you need L3 routing inside the subnet. The /(>100) per host gives you all that.

Regards,

Pascal

> Le 13 oct. 2021 à 19:26, Owen DeLong <owen=[email-masked]> a écrit :
> 
> 
>

---

From: Mark Smith <[email-masked]>
Date: Thu, 14 Oct 2021 08:16:26 +1100

On Thu, 14 Oct 2021, 07:04 Simon, <[email-masked]> wrote:

> >> An enterprise network might deploy its own DHCPv6 .apk's into
> employee's Android smartphones, for that particular enterprise network.
> >
> Indeed, the days of having to install pieces of software to get BASIC
> network functions is so ... last century. Brings back not so fond memories
> of having to pick an IP implementation (actually, pick a protocol and
> implementation), and then juggle with your load order to maximise hi-mem in
> DOS, and all that stuff.
>
> How long is it now since anything without IPv4 built in would be
> considered “broken” - and yet we’re still considering (or at least, some
> people are suggesting) that IPv6 should be held back to how networking was
> several decades ago !
>
> Not to put too fine a point on it, but I have seen no argument against
> Android including standards compliance

DHCPv6 is not required. See BCP 220.

 and a working DHCPv6 client other than : “it’s not how we want people to
> be using the devices they have bought AND SUPPOSEDLY OWN and we’re big
> enough to force our rules on the world”.
>
> Sorry Lorenzo, but basically the arguments put forward against allowing
> DHCPv6 client on Android come down to “but we want people to use them THIS
> way regardless of how they actually want to use it”. Dressed up a bit in
> the name of “protecting users” which is rich given that Google’s primary
> business is in amassing and profitting from people’s personal information -
> so perhaps it’s a more a case of “can’t have others abusing users’ privacy
> - that’s our job”.
>

---

From: Owen DeLong <[email-masked]>
Date: Wed, 13 Oct 2021 15:19:49 -0700

> On Oct 13, 2021, at 13:08 , Pascal Thubert (pthubert) <pthubert=[email-masked]> wrote:
> 
> Hello Owen 
> 

Yes, but we’re choosing a new form of 64-bit random number to take its place, so from my perspective, it’s still basically
a form of EUI-64 addressing even though not based on the actual MAC address.

> Switching better than routing in the domain we call a subnet is also becoming obsolete since even when we think we switch we probably route at L2 or in an underlay.

I guess that depends on how you define “L2 routing”. My definition is of routing involves deprecating the hop count (TTL in v4) and replacing the L2 headers. Forwarding
at L2 is (mostly) one of repeating or bridging (which usually called switching due to differences in hardware between modern switches and traditional bridges). Repeating
is what happened in old UTP hubs and even older DELNI boxes.

> Bottom line is that /64 is still an interesting boundary for backward compatibility and old habits to form a group we call a subnet. But I agree with Gert that we do not need to give that much to e…

Need is an interesting thing, but I don’t think it’s particularly relevant. I think the true question is what is useful to do and doesn’t pose an undue threat to addressing in the process. I think /64 meets that test.

Depending on your definition of “need”, we could claim that each device only needs one address behind which it can nat everything else on the device or behind the device and use ULA there. That’s not the model of IPv6 I want to see deployed, but if you push the bare-bones need argument far enough, that’s where you end up.

I’d much rather see us do reasonable addressing, issuing reasonable subnets (/64 seems perfectly fine to me) and one on.

> We can easily route to /112 or even to /128. I’m used to the latter because we build subnets of thousands of nodes in IoT and we know the nodes from a registrar, typically DHCPv6. But I see benefit…

Meh. If that works for you in your environment, more power to you.

> Why insist on /64 per host? Seems to me that the properties that we want do not depend much on where we cut.

I’m not insisting on any particular size in any given network’s implementation. I am insisting that we don’t put silly limits on what people can do because someone has a misguided fear of running out of prefixes.

> What’s really interesting is to decouple the domain we decide is a subnet from a L2 broadcast domain and from what we see as an IP link. For that you need L3 routing inside the subnet. The /(>100)…

Why would we want it?

Owen

---

From: David Farmer <[email-masked]>
Date: Wed, 13 Oct 2021 19:04:51 -0500

> DHCPv6 is not required. See BCP 220.

Yes, DHCPv6 is not required for hosts to implement, but it is recommended
by RFC8504/BCP220

But then again, networks providing general propose hosts with more than one
IPv6 address is not required and is also only recommended by RFC7934/BCP204.

So I think we have a standoff or deadlock, can we find a way to break it?
How about we all agree to implement the IETF's recommendations in both
cases?

Personally, I think they are both very good recommendations.

Thanks.

---

From: "Pascal Thubert (pthubert)" <[email-masked]>
Date: Thu, 14 Oct 2021 06:55:47 +0000

Hello Owen

> is what happened in old UTP hubs and even older DELNI boxes.

Yes terminology… for your points above routing is preferable and that’s exactly what I m getting at. Then there’s the major hassle of the broadcast domain. I take it that we agree and move on.

> 
>> Bottom line is that /64 is still an interesting boundary for backward compatibility and old habits to form a group we call a subnet. But I agree with Gert that we do not need to give that much to that’s exactly my pevery host just to be able to route inside the subnet at L2. 
> 

I’m totally happy with /64 subnet. Then there’s the terminology again and old concepts that make little sense. What do we call a subnet today ?  I like to consider it as an administrative group with the main property that you do not need to renumber as long as your mobility is between routers that serve that group. Other property is that it is the final aggregation that the infrastructure serves. 

With a definition like this it is possible to assign any portion of the address space to the nodes, as long as we prevent overlap. E.g. assign one or more /96 to Calico to map IPv4 10.0.0.0/8 Private Spaces in a cloud server.

 To partition a subnet in any fashion we like we need routing inside the subnet. And DHCP PD could be a tool to get there.

> I’m not insisting on any particular size in any given network’s implementation. I am insisting that we don’t put silly limits on what people can do because someone has a misguided fear of running o…

I guess we agree. I wish to give more power to netops to do what they want inside their subnet. Forcing a single broadcast domain and only /128 is incredibly restrictive and totally decoupled from modern needs.

>> What’s really interesting is to decouple the domain we decide is a subnet from a L2 broadcast domain and from what we see as an IP link. For that you need L3 routing inside the subnet. The /(>100)…

Real world exemple: 

Say I have a large campus, with WiFi coverage throughout. Say I want to move around with no renumbering. Say that when I print I want the printer to be the one in my room wherever I am in the campus.

The traditional IPv4 approach is the get an address from the subnet that is served by the AP that you connected to when you entered the campus and tunnel there when you move beyond the small area covered by the subnet. Meaning that your broadcast domain remains that small area and your prints will always get there.

With IPv6 a subnet could easily span the campus, but the broadcast domain could not. Ideally the node would see:

- a broadcast domain with mDNS devices such as the printer down the corridor. This means limited to one open space or a few smaller rooms

- an IP link to the routers that serve the broadcast domain. The box that we call an AP could easily serve as router and/or ND routing proxy (RFC 8929) within the subnet (call it a L3 AP just like your switch is probably an L3 switch).

- An IP subnet that has enough capacity to serve the whole campus.

We could easily be providing all this to our customers but we’re not. We prefer sterile discussions at 6MAN or NANOG and the consequence of our inaction is that they keep deploying  IPv6 as if it was IPv4 with little to no evolution/ benefit. And we complain for the lack of adoption!

Please, peace: we have 20 years of experience that a discussion for the sake of discussing does not get us anywhere. Could we for once work on an acceptable trade off?

Your point: our common customers want one state per device because state is expensive. They do not want uncontrolled address allocation and silent nodes that come with it. They have that with IPv4 do not want to loose that going v6. I share that view and observe the same thing.

Also: They do not want broadcast storms that clog their bandwidth, waste energy and spectrum. They want to scale to a campus or a factory without renumbering.  They want simple (flat) networks as opposed to the tunnels above. They want service for the end users, e.g., the nearest printer.

Looking for a consensus:

You want to assign/128 to the host and defend the case of the use of DHCP in the managed subnet.

Lorenzo does not want /128 to the host but agrees with DHCP PD.

Gert wants to avoid the waste of address space just because we can. 

A prefix to the host gives Lorenzo the addresses he needs for his devices.  It gives your customers the single state per logical node that they want. It allows to separate what netops manage (down to /64 and direct assignment within) and devops (whatever they do with the longer prefix they get for their node). It does not impose any size for what’s assigned, could be a different thing for each host. It means routing inside the subnet which removes the dreadful broadcast domain.

I see an opportunity for consensus. Can we work that out together and bring a real IPv6 value?

Pascal

---

From: Vasilenko Eduard <[email-masked]>
Date: Thu, 14 Oct 2021 08:48:14 +0000

Ø  Why insist on /64 per host?

Well, it depends on what is the host? If it has 300 containers inside then maybe it is less wastage of address space than to give /64 to a household.

Ø  Seems to me that the properties that we want do not depend much on where we cut.

Yes, /64 boundary for any subnet look artificial.

Ed/

-----Original Message-----
From: v6ops [mailto:[email-masked]] On Behalf Of Pascal Thubert (pthubert)
Sent: Wednesday, October 13, 2021 11:09 PM
To: Owen DeLong <owen=[email-masked]>
Cc: [email-masked]
Subject: Re: [v6ops] Implementation Status of PREF64

Hello Owen

Regards,

Pascal

> Le 13 oct. 2021 à 19:26, Owen DeLong <owen=[email-masked]<mailto:owen=[email-masked]>> a écrit :

>> On Oct 13, 2021, at 09:58 , Gert Doering <[email-masked]<mailto:[email-masked]>> wrote:

>> So far I have not seen any data that supports "/64 was a good idea"

>> :-)

> Reviewing the record, it seems we were destined for something like

> 64-bit addressing overall before IETF decided to consider EUI-64

> addressing and added 64-bits to the plan, so one can argue that

> without the idea of universal /64 addressing we’d have a whole lot

> fewer network numbers available.

> [email-masked]<mailto:[email-masked]>

v6ops mailing list

[email-masked]<mailto:[email-masked]>

---

From: Alexandre Petrescu <[email-masked]>
Date: Thu, 14 Oct 2021 13:09:55 +0200

Le 13/10/2021 à 22:00, STARK, BARBARA H a écrit :
> <bhs> When I look at the Nook eReader that uses the Android OS, I notice 
> that it just references a bunch of Open Source Apache 2.0 licenses for 
> the Android OS components they use. To me, this says IoT devices are in 
> no way beholden to a Google app store or Google restrictions around what 
> goes into an Android smartphone. I see on 
> https://source.android.com/devices/architecture/modular-system/networking <https://source.android.com/devices/architecture/modular-system/networking> 
> that it says Android 10 included a DhcpClient component that “obtains IP 
> addresses from DHCP servers so they can be assigned to interfaces”. So 
> it sounds like IoT devices that use Android already have the ability (if 
> the manufacturer wants) to support IA_NA?

Supposedly that DHCP in Android is v4, not v6.

The use of that v4 feature has several implications:

- IoT on IPv4 is a widespread reality, even though IoT at IETF is a
   completely different thing.  It  might be that when computers move to
   IPv6 at that scale 'IoT' itself will no longer be a buzzword, long
   replaced by something else that uses IPv6.

- IoT Android routers with IPv4 necessarily use NAT, this NAT being a
   feature one would not like to see propagated in IPv6.  I think Lorenzo
   says that NAT66 might come to IPv6 IoT if DHCPv6 was used, so he
   advises to not use DHCPv6.  To that, I would say that NAT66 comes to
   IPv6 IoT already and it is because of the '/64' limit, or because of
   lack of the DHCPv6 feature in Android.

To bring IPv6 to Android to IoT routers one necessarily needs to get
away from the '/64' limit or to use DHCPv6 on Android.  Until then IoT
Android is IPv4, and IoT Android routers are NATs.

Alex

---

From: Alexandre Petrescu <[email-masked]>
Date: Thu, 14 Oct 2021 13:14:49 +0200

Le 13/10/2021 à 23:16, Mark Smith a écrit :
> 
> 
> On Thu, 14 Oct 2021, 07:04 Simon, <[email-masked] 
> <mailto:[email-masked]>> wrote:
> 
> Owen DeLong <owen=[email-masked] 
> network functions is so ... last century. Brings back not so fond
> memories of having to pick an IP implementation (actually, pick a
> protocol and implementation), and then juggle with your load order to
> maximise hi-mem in DOS, and all that stuff.
> 
> considered “broken” - and yet we’re still considering (or at least, 
> some people are suggesting) that IPv6 should be held back to how 
> networking was several decades ago !
> 
> Not to put too fine a point on it, but I have seen no argument 
> against Android including standards compliance
> 
> 

BCP 220 RFC 8504 "IPv6 nodes reqs" is a huge list of protocols with many
intermingled 'may's and MAYs, but without any 'NOT RECOMMENDED' DHCPv6
even though there are a few 'not recommended's.

So I do not quite understand when it is said that BCP 220 makes it that
DHCPv6 is not required.

I can say that BCP 220 says that DHCPv6 is a 'may' because it says
"Hosts may be configured with [...] DHCPv6 [among others]' but that has
as much validity as saying that BCP 220 says that DHCPv6 is not required.

What did you mean?

Alex

> 
> 
> 
> 
> and a working DHCPv6 client other than : “it’s not how we want people
> to be using the devices they have bought AND SUPPOSEDLY OWN and we’re
> big enough to force our rules on the world”.
> 
> Sorry Lorenzo, but basically the arguments put forward against 
> allowing DHCPv6 client on Android come down to “but we want people to
> use them THIS way regardless of how they actually want to use it”.
> Dressed up a bit in the name of “protecting users” which is rich
> given that Google’s primary business is in amassing and profitting
> from people’s personal information - so perhaps it’s a more a case of
> “can’t have others abusing users’ privacy - that’s our job”.
>

---

From: "Pascal Thubert (pthubert)" <[email-masked]>
Date: Thu, 14 Oct 2021 12:09:16 +0000

Yes I’m with you here.

 IPE can document things that could be done with IPv6 as a defense against the temptation to define something all new.

Being not IETF it leaves more time for ASICs to prepare. Which takes at best a couple years. But compared to the wasted last 20 years that’s short term!

Regards,

Pascal

> Le 14 oct. 2021 à 13:15, Alexandre Petrescu <[email-masked]> a écrit :
> 
> 
> 
>> On Thu, 14 Oct 2021, 07:04 Simon, <[email-masked] <mailto:[email-masked]>> wrote:
>> Owen DeLong <owen=[email-masked] <mailto:[email-masked]>> wrote:
>> Not to put too fine a point on it, but I have seen no argument against Android including standards compliance
>> Sorry Lorenzo, but basically the arguments put forward against allowing DHCPv6 client on Android come down to “but we want people to
>> _______________________________________________ v6ops mailing list [email-masked] <mailto:[email-masked]> https://www.ietf.org/mailman/listinfo/v6ops <https://www.ietf.org/mailman/listinfo/v6ops>
>> _______________________________________________ v6ops mailing list [email-masked] https://www.ietf.org/mailman/listinfo/v6ops
>

---

From: "Dale W. Carder" <[email-masked]>
Date: Thu, 14 Oct 2021 08:58:19 -0500

> Bottom line is that /64 is still an interesting boundary for backward compatibility and old habits to form a group we call a subnet. But I agree with Gert that we do not need to give that much to e…

It should not be lost that there are nice properties as well, for example 
the probability of duplicate address collision.  (See RFC4429 appendix A)

Dale

---

From: Ted Lemon <[email-masked]>
Date: Thu, 14 Oct 2021 13:09:59 -0400

On Thu, Oct 14, 2021 at 2:56 AM Pascal Thubert (pthubert) <pthubert=
[email-masked]> wrote:

> A prefix to the host gives Lorenzo the addresses he needs for his
> devices.  It gives your customers the single state per logical node that
> they want. It allows to separate what netops manage (down to /64 and direct
> assignment within) and devops (whatever they do with the longer prefix they
> get for their node). It does not impose any size for what’s assigned, could
> be a different thing for each host. It means routing inside the subnet
> which removes the dreadful broadcast domain.
>

If your proposal is that we use a /64 per host as a way to meet these
needs, I agree. This solves everybody's actual problems. There is the issue
that some people have expressed a preference for prefixes wider than 64
bits, but this is a preference—there's no technical reason to do this. It's
not wrong to have preferences, but it would be nice if we could somehow
finally put this discussion to bed.

---

From: Ole Troan <[email-masked]>
Date: Thu, 14 Oct 2021 21:07:46 +0200

> On 14 Oct 2021, at 19:11, Ted Lemon <[email-masked]> wrote:
> 
> 
>> On Thu, Oct 14, 2021 at 2:56 AM Pascal Thubert (pthubert) <pthubert=[email-masked]> wrote:
> 
> If your proposal is that we use a /64 per host as a way to meet these needs, I agree. This solves everybody's actual problems. There is the issue that some people have expressed a preference for prefixes wider than 64 bits, but this is a preference—there's no technical reason to do this. It's not wrong to have preferences, but it would be nice if we could somehow finally put this discussion to bed.

Limiting networks that are assigned a /56 to only 256 logical nodes is a non starter. 

O.

---

From: Owen DeLong <[email-masked]>
Date: Thu, 14 Oct 2021 12:37:03 -0700

> On Oct 14, 2021, at 12:07 , Ole Troan <[email-masked]> wrote:
> 
> 
> 
>> On Thu, Oct 14, 2021 at 2:56 AM Pascal Thubert (pthubert) <pthubert=[email-masked] <mailto:[email-masked]>> wrote:

Shouldn’t assigning /56s be the non-starter in that question?

Owen

---

From: Brian E Carpenter <[email-masked]>
Date: Fri, 15 Oct 2021 09:29:55 +1300

I hadn't realised that this thread was now about something entirely different. If one doesn't change the Subject when the subject changes, one cannot be be surprised if people ignore the thread...

On 14-Oct-21 19:55, Pascal Thubert (pthubert) wrote:
<snip>

> 
> Real world exemple: 
> 
> Say I have a large campus, with WiFi coverage throughout. Say I want to 
move around with no renumbering. Say that when I print I want the printer 
to be the one in my room wherever I am in the campus.
> The traditional IPv4 approach is the get an address from the subnet that is served by the AP that you connected to when you entered the campus and tunnel there when you move beyond the small area c…

Actually, no. What large campuses tend to do today is have a centralised print queue and a feature whereby the user releases their print jobs *at the printer itself*. Fiddling around with a mechanism that relies on the printer's IP address is not the future.
 
> - a broadcast domain with mDNS devices such as the printer down the corridor. This means limited to one open space or a few smaller rooms

I think DNS-SD will do better than that. mDNS is not the future.
 
> - an IP link to the routers that serve the broadcast domain. The box that we call an AP could easily serve as router and/or ND routing proxy (RFC 8929) within the subnet (call it a L3 AP just like…

How does that work with on-link determination? 

> We could easily be providing all this to our customers but we’re not. We prefer sterile discussions at 6MAN or NANOG and the consequence 
of our inaction is that they keep deploying  IPv6 as if it was IPv4 with little to no evolution/ benefit. And we complain for the lack of adoption!
> 
> Please, peace: we have 20 years of experience that a discussion for the 
sake of discussing does not get us anywhere. Could we for once work on an 
acceptable trade off?
> 
> Your point: our common customers want one state per device because state is expensive. They do not want uncontrolled address allocation and silent nodes that come with it. They have that with IPv4 do not want to loose 
that going v6. I share that view and observe the same thing.

There's a tussle here between the desire for privacy and the desire for management control. While enterprise network managers might not want uncontrolled address allocation, their users might want it. The IETF has to respect that tussle and make its resolution a deployment issue, not a standards issue. In other words the trade off doesn't happen here.

> Also: They do not want broadcast storms that clog their bandwidth, waste energy and spectrum. They want to scale to a campus or a factory without renumbering.  They want simple (flat) networks as o…

If you fix the printing (and other app layer) problems at the app layer, as noted
above, and use DNS-SD rather than mDNS to find services, who cares any more which subnet you are on?

   Brian

> A prefix to the host gives Lorenzo the addresses he needs for his devices.  It gives your customers the single state per logical node that they want. It allows to separate what netops manage (down to /64 and direct assignment within) and devops (whatever they do with the longer prefix they 
get for their node). It does not impose any size for what’s assigned, could be a different thing for each host. It means routing inside the subnet which removes the dreadful broadcast domain.

---

From: Simon <[email-masked]>
Date: Fri, 15 Oct 2021 15:17:30 +0100

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

I actually had in mind a comment made some way up the thread that Android ignores the A bit in RAs. If so then that’s a blatant violation, not just of the standard, but also of the wishes/policies of network operators who may be fully within both the letter and spirit of RFCs/BCPs.

> Yes, DHCPv6 is not required for hosts to implement, but it is recommended by RFC8504/BCP220

"Consequently, all hosts SHOULD implement address configuration via DHCPv6”
This, and the text leading up to it is very clear - if you value interoperability at all then implement DHCPv6 client on your devices.

> But then again, networks providing general propose hosts with more than one IPv6 address is not required and is also only recommended by RFC7934/BCP204.
> 
> So I think we have a standoff or deadlock, can we find a way to break it? How about we all agree to implement the IETF's recommendations in both cases? 
> 

Agreed. It does seem quite simple really. So why is it so hard ?

Simon

---

From: Ted Lemon <[email-masked]>
Date: Fri, 15 Oct 2021 14:03:30 -0400

I could successfully number all the devices in the network each with a /64
if I had a /59. This doesn't count IoT devices on IoT networks, I will
admit, but even then a /58 would do. What would not work would be to number
every device out of a /64.

That said, we're comparing apples to oranges here. On a home network, the
operator is /never/ going to configure DHCPv6. Sure, there are people here
who would, but they don't have a home network—they have a managed network
that is in their home. So yes, they would need a /56 or maybe even a /48
(but probably not).

On my home network, I just use SLAAC, and there's no problem. My Thread
network also does SLAAC (or whatever the Thread mesh does—I don't really
know, but definitely not DHCPv6).

So what other networks besides home networks are limited to a /56?

---

From: Gert Doering <[email-masked]>
Date: Fri, 15 Oct 2021 20:12:28 +0200

Hi,

On Fri, Oct 15, 2021 at 02:03:30PM -0400, Ted Lemon wrote:
> operator is /never/ going to configure DHCPv6. 

DHCPv6-PD, for sure.

Why shouldn't he?  IETF told operators and vendors that this is a good
thing if you have router-behind-router in the home.

If you are speaking about "subnet per device", this is not IA_NA/TA but PD.

Gert Doering
        -- NetMaster

---

From: Ted Lemon <[email-masked]>
Date: Fri, 15 Oct 2021 14:16:52 -0400

Oh, yeah, sure. I was referring to individual address allocations, not
/64s. But even then, it would be better not to consume a /64 per host if
your ISP sucks and is just giving you a /60. In my home network, I'd want
to reserve the /56s for things like IoT networks (assuming I wanted my IoT
devices to be able to connect to the Internet, which I don't).

---

From: Owen DeLong <[email-masked]>
Date: Sat, 16 Oct 2021 00:31:46 -0700

> That said, we're comparing apples to oranges here. On a home network, the operator is /never/ going to configure DHCPv6. Sure, there are people here who would, but they don't have a home network—they have a managed network that is in their home. So yes, they would need a /56 or maybe even a /48 (but probably not).

I wouldn’t say “never” here. The average home operator may not configure, but commonly uses and many home operators do configure DHCPv4. I see no reason to expect that there won’t eventually be home IPv6 CPE with extended capabilities that don’t fit in SLAAC and require at least the O bit DHCPv6 if not full M-bit implementation.

> On my home network, I just use SLAAC, and there's no problem. My Thread network also does SLAAC (or whatever the Thread mesh does—I don't really know, but definitely not DHCPv6).

I use SLAAC for some of the subnets in my home and it works fine for those purposes. I have some subnets where I want t assign persistent, predictable, memorable addresses to some devices. I have some devices that need information like boot files, NTP servers, etc. For those cases, I do use DHCPv6 on those subnets and they are running without A and with M+O bits.

> So what other networks besides home networks are limited to a /56?

Some (really annoying, are you listening Comcast) Cable MSOs provide a /60 to residential and /56 to SMB.

Owen

> 
> On Thu, Oct 14, 2021 at 3:07 PM Ole Troan <[email-masked] <mailto:[email-masked]>> wrote:
> 
> 
>> On 14 Oct 2021, at 19:11, Ted Lemon <[email-masked] <mailto:[email-masked]>> wrote:
>> 
>>

---

From: Owen DeLong <[email-masked]>
Date: Sat, 16 Oct 2021 00:33:25 -0700

> On Oct 15, 2021, at 11:16 AM, Ted Lemon <[email-masked]> wrote:
> 
> Oh, yeah, sure. I was referring to individual address allocations, not /64s. But even then, it would be better not to consume a /64 per host if your ISP sucks and is just giving you a /60. In my home network, I'd want to reserve the /56s for things like IoT networks (assuming I wanted my IoT devices to be able to connect to the Internet, which I don't).

I’d argue it would be better to demand that your ISP stop sucking and failing that, choose a better ISP if possible.

Owen

> 
> On Fri, Oct 15, 2021 at 2:12 PM Gert Doering <[email-masked] <mailto:[email-masked]>> wrote:
> Hi,
>

---

From: Alexandre Petrescu <[email-masked]>
Date: Sat, 16 Oct 2021 21:51:15 +0200

Le 12/10/2021 à 19:05, Philip Homburg a écrit :
> I didn't verify it. But I assume clearing that 'A' bit in the PIO 
> should prevent android from doing SLAAC. It is not as if rogue 
> android devices are creating address from every prefix they see.

The ISP CPE I use has the A bit reset in the PIO, and the M bit set in
RA header, when the user selects 'DHCPv6' in the GUI of the ISP CPE.

Also, when checking that DHCPv6 option in the GUI, there is a warning:
in French: "Attention si vous activez le serveur DHCPv6, certains
périphériques Android risquent de ne plus avoir de connectivité IPv6".
In English it means: "Warning, if you activate the DHCPv6 server, then
certain Android devices are at risk of no longer having IPv6 connectivity".

The day I switch off completely IPv4 in my setting and continue with
DHCPv6 the Android will be fully disconnected from the Internet.  It is
not easy to completely turn off IPv4 in my setting, but it is not
impossible.

Alex

---

From: Alexandre Petrescu <[email-masked]>
Date: Sat, 16 Oct 2021 21:54:45 +0200

Le 12/10/2021 à 19:24, David Farmer a écrit :
> 
> On Tue, Oct 12, 2021 at 12:00 PM Owen DeLong 
> The data necessary for SLAAC is in the RA that includes the M bit to
>  tell the host to go ask the DHCPv6 server for an address, so how 
> would your CPE prevent the android from doing SLAAC without 
> authorization?
> 
> I think the CPE will only set either the A-flag or M-flag but not 
> both at the same time in the RA and only start up the DHCPv6 process 
> if the M-flag is set.
> 
> However, most CPE I know the Flags are independent, you can set one 
> or the other or both.
> 
> XFINITY(Comcast) Gateway is that way, you can only configure DHCPv6 
> off or on, SLAAC is always on. Probably so you can accidentally
> break IPv6 for Android.

A version of Free ISP CPE that I have is also in a similar situation: if
DHCPv6 is on then M is set and A reset; I guess that by specificationn
it is possible to have both M and A set.

I suspect people dont set both M and A in RA because of conflicts that
might appear in parameters of Hosts.

Alex

> 
> Thanks
> 
> -- =============================================== David Farmer

---

From: Alexandre Petrescu <[email-masked]>
Date: Sat, 16 Oct 2021 21:59:54 +0200

Le 15/10/2021 à 16:17, Simon a écrit :
> I actually had in mind a comment made some way up the thread that
> Android ignores the A bit in RAs. If so then that’s a blatant
> violation, not just of the standard, but also of the wishes/policies
> of network operators who may be fully within both the letter and
> spirit of RFCs/BCPs.
> 
> "Consequently, all hosts SHOULD implement address configuration via
> DHCPv6” This, and the text leading up to it is very clear

Thanks for pointing to that text in BCP220 RFC 8504 "IPv6 Node Reas", 
because I missed it somehow.

Alex

  - if you
> value interoperability at all then implement DHCPv6 client on your
> devices.
> 
>> But then again, networks providing general propose hosts with more
>> than one IPv6 address is not required and is also only recommended
>> by RFC7934/BCP204.
>> 
>> So I think we have a standoff or deadlock, can we find a way to
>> break it? How about we all agree to implement the IETF's
>> recommendations in both cases?
>>

---

From: Fred Baker <[email-masked]>
Date: Wed, 20 Oct 2021 11:30:51 -0700

> 1. The IETF hasn't picked a value of  N, but it has, through RFC7934, said that N<1.

A host may not have any IPv6 addresses?

I think RFC 7934 requires that N>=1...