Re: [v6ops] Fwd: New Version Notification for draft-collink-v6ops-ent64pd-01.txt

[Jen Linkova <[e-mail]>]

On Wed, Dec 21, 2022 at 10:43 AM Martin Huněk <[e-mail]> wrote:
> > > Even though this proposal has some merit, and it might be useful for some applications (tethering, virtualization, docker, ...), it is certainly not suitable for most devices. For this reason, I think it should not aim for "Best Current Practise" but, at the most, for "Informational" status.
> >
> > Oh sorry, it's a leftover from the template I used. Will be fixed in
> > the next version. Good catch, thanks.
>
> I'm glad that it is just left over. This is actually one of my main issues with this document. It scared me that every device on my network should be recommended to ask for /64 PD as it is the "best" way (BCP). :-)

Glad to hear I've addressed one of the main issues so easily ;)

> > > In the RIPE region, a customer should be given at most /48 - if you want to assign more than that, it has to be authorized. The maximum /48 is less than your requirement of /32 or even /29 stated in chapter 4.
> >
> > /32 or /29 was for ~8k sites with 64 segments per site (so ~500K
> > segments). I doubt a customer of that size would get a single /48.
>
> However, this is the current policy in the RIPE region (I do not know the others). If we are talking about large corporations that are non-LIR with either a single ISP in their PA space or multi ISP with their own PI prefix. It is not so easy for LIR to do the allocation or ask for PI space. If it does PA larger than /48 assignment without asking, it would be a RIPE policy violation. If it asks for either PA or PI, it has to go through an evaluation process. This means paperwork.

I'd rather prefer the option to be here - so some companies might
rather do some paperwork than upgrading their infrastructure as it
needs to handle 10 times more addresses.
Again, I'd expect that not every segment might need design. For
example, an imaginary enterprise might want to enable this for their
Guest WiFi network but not for workstations.

> In my opinion, the draft should not expect every corporation to have /32 or /29. It is common only for LIRs.

Not every corporation is running out of 10/8, right? Remember that the
calculations in the draft are for a rather large network, jst to
illustrate tte math and prove that we are not going to run out of IPv6
addresses.

> *The biggest prefix any end user/subject can use (even LIR) is /48* - in RIPE DB terminology, ASSIGNED, ALLOCATED-BY-LIR, or AGGREGATED-BY-LIR objects are limited to /48 right now. So even if an LIR used for itself more than /48, it would be in violation of RIPE policy - there are some tricks on how to hide that, but this should not be recommended.

I still think that RIR policy is outside of the scope of this doc. It
describes a design option which may be useful for enterprises or
conference WiFi networks.
(Besides that I do not read ripe-738 as it would be a violation. It
just needs to be justified - and this document works towards
justification).

> If you want LIRs to use their assigned PA in such a matter, you will need to convince RIRs to relax their policy. Otherwise, this draft would have limited use cases to networks that are owned by LIRs and either violate RIR policy or have an exception.

Not every design needs to be applicable to every network. Mobile
networks have been allocating /64 per host for a very long time, if we
can make it useful for large enterprises, public WiFi networks etc -
I'd consider it a progress.
This WG already published RFC8273 which proposes more or less the same
as this draft but would require completely different behaviour on
routers.

Discussion with RIR should happen naturally, if/when more LIRs or end
customers consider it useful (and if they realize they need more
addresses, because smaller networks might be fine with what they
have).

> Sure, but then the LIR had to ask its RIR for an exception from /48 rule. Also, we would end up either with two /48s or we would need to renumber to aggregate to single /47.

It would be up to them to decide, right? If they see the value they
might be fine with that. Even if this particular network would not,
maybe some greenfield deployments consider this useful (and they
wouldn't need to renumber).

> > OK, I think we need to add more text on this topic to the next version
> > of the draft, as it's not the first time readers miss it.
> > The proposed design is suitable for the large networks, where ND
> > scalability is an issue. The home networks with /56 delegated to CPEs
> > is out of scope, and indeed the device shouldn't request a prefix in
> > this case.
> > That's why a new flag is proposed, so the network can signal to hosts
> > if they should be using SLAAC or PD.  Section 8 explicitly states but
> > I assume we should make it more clear.
>
> Then you cannot obsolete SLAAC by it (as some seem to suggest). Also, what if the network operator sets both flags?

That will be described in more details in the corresponding 6man draft
but in a nutshell:
- the operator is supposed to set both flags.
- devices which do no support it, would keep using SLAAC (as A=1)
- devices which support PD, would ignore A flag and use PD.

So only devices which do not support PD, would be using SLAAC.
Eventually it might be even possible to get rid of SLAAC whatsoever,
who knows - depends on how much control the operator has over the
devices (so it might be completely different for an enterprise
internal network with managed devices vs a guest WiFi).

> I understand that it is easier on host implementation to do SLAAC internally. However, what is the problem with doing DHCPv6 or something DHCPv6-like internally? Inside a single Node, there are no artificial/external limitations on how many IPv6 addresses one service can get. The different situation is when the device is a Router (like in tethering mode) when there are other devices connected to it. However, then already existing DHCPv6-PD RFCs apply. Then the /64 is the easiest and the cleanest thing to do, but no new document is also needed for such a case - the device is a Router.

Well, below you said that this proposal has a cost of making the
device a router. Adding *stateful* DHCPv6 server on the device would
increase the cost, wouldn't it?
Compare two scenarios:
- your laptop, which runs a number of virtual instances internally,
gets /64 which is used to assign addresses to guest systems via SLAAC
- your laptop gets /64 and needs to run a *statuful* DHCPv6 server in
addition to SLAAC (at the very least, unless rapid commit is used,
it's more packets).

> Not every node needs multiple global unicast addresses.

My Android phone has 3.
ChromeOS needs 7-9.
My Ubuntu has 4 addresses which are actively used, my MacOS has 3 -
and those two do not (yet) have 464XLAT enabled.

I do not have any iPhone or Windows to test.

Well, my printer has only one, but I do not want to build a network
where only printers work.

>CPEs are doing quite well with just one, and then they are using the PD only for their down-facing interfaces - this seems like the best solution to me. I think that your requirement is only relevant when the device needs more than one unicast global unique address, and it should be written there.

Introduction section is discussing this. Do you think it needs to be
clarified? Happy to add more text there if you think it's not clear
enough.

> > > If the device is, for example, a phone doing tethering, it would have two interfaces: up-facing rmnet0 and down-facing wlan0. What is wrong about the rmnet0 having SLAAC configured or DHCPv6 configured address on it, while routed network segment or wlan0 having DHCPv6-PD obtained prefix? How does it differ from what are routers doing nowadays? The same goes for virtualization or containers. If the device is routing, it is a router, so it should act like one. If it is not routing and it is bridging, then it is a bridge and should act like one. Furthermore, if it is a bridge, it should just act as transparent and forward ND packets and DHCPv6 packets like any other bridge. There is no need for anything in between.
> >
> > Then we are back to having the problem we are trying to solve (also
> > described in https://www.ietf.org/archive/id/draft-linkova-v6ops-ipmaclimi-00.html):
> > multiple addresses per host are 1)expensive for the network 2)are not
> > guaranteed to work.
>
> Isn't this situation comparable with connecting a physical switch to an Ethernet port configured and limited for a single device? I mean, this is known even in IPv4, isn't it? At our university, if someone wants to connect a switch, they have to ask first to have that limitation lifted. Same in IPv6, if you need to have 10 global unicast addresses per device, it is not standard behavior,  so you should ask first.

As an administrator, I do not want to have a network where every time
a user needs to connect a ChomeOS or Linux or Android to the network
they need to ask first.

My goal is to find a common ground where devices just work and the
network is not negatively impacted.

Also I'd disagree that it's 'not standard behaviour':
- even w/o any virtualization, 4 addresses is pretty normal
(link-local, stable, privacy, 464xlat).
- during a renumbing  event, or in multi-prefix envinronment, you'd add 3 more.
- if the device has long-lived sessions, there will be deprecated
addresses as well. 10 is normal - and now add virtual machines on top
of this.

> As I understand, it is a protection against a malicious device that would ask for an infinite number of addresses or obsoleted privacy extensions that had a similar property.

Exactly!  ;) So with this draft it's not a risk for the network
anymore. If the host is willing to generate  an infinite number of
addresses, it wouldn't impact the network, only the host itself.
For the network it's still one route pointing to the host's link-local address.

> > > In chapter 9, it is stated:
> > >
> > > "The network needs to scale to the number of devices" with /64 per device; it scales worse than with /128 per device. This is the fact as it is limited by prefix length.
> >
> > Sorry, I'm not sure I understand this statement.
>
>  meant that number of connected devices is limited by the number of available prefixes. In the second example, I mentioned it would be 32 devices per segment. This would scale better if /96 were allowed.

Ah sorry, in this section by the 'network' I do not mean the address
space, I mean more device resources (ND cache, IP/MAC mapping tables
etc). I'll clarify it in -02.

> > > "The cost of having multiple addresses is offloaded to the endpoint. Devices are free to create and use as many addresses as they need" for the cost that every device becomes a router.

That's the device decision. Not all devices would do this (as not all
need it). Printers, for example, are unlikely to use that feature. But
devices which are already, to some degree, routers - like phones,
devices running virtual environments -
the benefits of having infinite number of IPv6 addresses and share the
network connectivity might be worth it,

> I must say that you do have quite an untypical workstation. I've checked my computers and servers, and all of them seem to have just one link-local address and one global unicast address (stable privacy or EUI-64) per interface. Only one of them also has a ULA. What OS vendor/version do you use (just curious)?

Ubuntu. I've checked right now:
- one link-local
- 1 stable address
- 1 preferred privacy address
- 5 deprecated privacy addresses which still have sessions to them
opened (so they are consuming network resources).
...and I'm planning to add 464XLAT one there, so let's say 1
link-local + 7 global addresses which are seen on the network
and and 1 deprecated address which doesn't have any sessions to it,
but still present on the switch table (I guess because switch keeps
trying to verify if the address is still here..)

> > >This draft actually scares me as a network administrator of the large non-LIR network and also as a netadmin of the small ISP. In both cases, either organization or customers would run out of IPv6 addresses. It is effectively dividing address length by 2.
> >
> > Please keep in mind that those organizations do not need to enable PD
> > if they don't need/want to (e.g. if they do not have any scalability
> > issues with 10 addresses per device).
> > However if they see the benefits and believe that it's worth it - they could.
> > We are describing a design which has some merits for some networks.
> > Maybe later the networks which do not need it now change their minds..
>
> But when they see how big the prefix demand would be, they could also be scared to touch the appropriate flag in RA. I don't think that there are so many that can afford to turn it on an organization-wide scale. :-)

I'm quite sure each organization is capable of figuring out the
network change policy and how to do global rollouts, the draft
shouldn't be covering this.

> >
> > > Dne čtvrtek 15. prosince 2022 4:59:33 CET, Jen Linkova napsal(a):
> > > > Hello,
> > > >
> > > > We've just submitted -01 version of draft-collink-v6ops-ent64pd, which
> > > > proposes using DHCPv6-PD to delete /64 per host (the draft was very
> > > > briefly presented at the last IETF).
> > > >
> > > > Comments and suggestions are welcome!
> > > >
> > > >
> > > > ---------- Forwarded message ---------
> > > > From: <[e-mail]>
> > > > Date: Thu, Dec 15, 2022 at 2:39 PM
> > > > Subject: New Version Notification for draft-collink-v6ops-ent64pd-01.txt
> > > > To: Jen Linkova <[e-mail]>, Lorenzo Colitti
> > > > <[e-mail]>, Xiao Ma <[e-mail]>
> > > >
> > > >
> > > >
> > > > A new version of I-D, draft-collink-v6ops-ent64pd-01.txt
> > > > has been successfully submitted by Jen Linkova and posted to the
> > > > IETF repository.
> > > >
> > > > Name:           draft-collink-v6ops-ent64pd
> > > > Revision:       01
> > > > Title:          Using DHCP-PD to Allocate /64 per Host in Broadcast Networks
> > > > Document date:  2022-12-14
> > > > Group:          Individual Submission
> > > > Pages:          11
> > > > URL:
> > > > https://www.ietf.org/archive/id/draft-collink-v6ops-ent64pd-01.txt
> > > > Status:         https://datatracker.ietf.org/doc/draft-collink-v6ops-ent64pd/
> > > > Html:
> > > > https://www.ietf.org/archive/id/draft-collink-v6ops-ent64pd-01.html
> > > > Htmlized:
> > > > https://datatracker.ietf.org/doc/html/draft-collink-v6ops-ent64pd
> > > > Diff:
> > > > https://author-tools.ietf.org/iddiff?url2=draft-collink-v6ops-ent64pd-01
> > > >
> > > > Abstract:
> > > >    This document discusses the IPv6 deployment scenario when individual
> > > >    hosts connected to broadcast networks (like WiFi hotspots or
> > > >    enterprise networks) are allocated /64 subnets via DHCP-PD.
> > > >
> > > >
> > > >
> > > >
> > > > The IETF Secretariat
> > > >
> > > >
> > > >
> > > >
> > > >
> > >
> >
> >
> > --
> > SY, Jen Linkova aka Furry
> >
>


-- 
SY, Jen Linkova aka Furry