Re: [v6ops] WG call for adoption: draft-collink-v6ops-ent64pd-03

> *the system which requests the prefix is NOT necessary the system which assigns the addresses*
For this case, /64 would be indeed more valuable. It is true.
But router-to-router DHCP-PD lease does not need any additional draft, it works fine already.
Ed/
-----Original Message-----
From: v6ops [mailto:v6ops-bounces@ietf.org] On Behalf Of Jen Linkova
Sent: Tuesday, April 25, 2023 10:19 PM
To: Martin Huněk <martin.hunek@tul.cz>
Cc: IPv6 Ops WG <v6ops@ietf.org>
Subject: Re: [v6ops] WG call for adoption: draft-collink-v6ops-ent64pd-03

On Wed, Apr 26, 2023 at 4:18 AM Martin Huněk <martin.hunek@tul.cz> wrote:
> It depends on the use case. If I'm an ISP, I do expect that connected devices are (could be) routers. If I'm an enterprise network with a network policy banning routers connected by users without explicit approval, then I would not expect routers to be connected to the network - if so, I'll give /{48-64} to routers with approved routers (DUIDs).

My point is: in the IPv4 world, you do not and can not know if a device connected to your network is a host or a router.
The endpoint gets an IPv4 address and uses it for NAT and for extending the network behind it. The network administrator has absolutely no way to prevent it in case of a generic host.
The only way you can guarantee the device does not act as a router is to have *full* control over every single endpoint. In that case you do not need this draft - you can control hosts behavior, right?
So that draft would not pose any threads to you, as devices which shall not send PD requests if you don't want them.

Let's forget about this draft for a second. Tell me, what do you think we shall do with those devices (ones extending the network) in the
IPv6 world? Do we want to end up with NAT66?

> > Could you please clarify: are you suggesting that to make the model 
> > described in this draft deployable, we'd need to either make SLAAC 
> > to work with /80 or invent a new form of address assignment, which 
> > would use /80?
> > If it's the former, what would change in this particular draft?
>
> Do not depend on SLAAC. This is a new method for host addressing anyway. It had to be implemented anyway.

This is a very important point which I want to emphasise again: *the system which requests the prefix is NOT necessary the system which assigns the addresses*. ChromeOS is an example. Even if the host OS which requests the prefix can implement the new method, it would mean that *all* guest OSes (which are currently behind the ND proxy of the host OS) need to support that new method.

>So the host SHOULD generate random IID to fill the rest of 128b of IPv6 address. How it is done should be implementation specific, and as the host is managing its own prefix, it really doesn't matter how.

Such a method doesn't exist today. The only method we have today which is guaranteed to work, is SLAAC.

> >> For me personally, I can accommodate both /80 and /96 per host in my addressing plans, but I cannot and will not be able to do so with /64 - this is unrealistic for me as well as for any "big" non-LIR organization in the RIPE region.
> >
> > Am I right that you'd like to deploy a prefix per host and you think 
> > your network would benefit from it, but you wouldn't be able to 
> > because you do not have enough address space?
>
> I may choose this way in the future, yes. In both ISPs, I do use PD for routers to distribute /56s to clients (routers). But I don't want to be pushed by clients that they won't fit in /56 and that they need /48 for residential. I did my addressing plan in one situation, and hosts needing /64 is an entirely different one.

But why do you think *residential* clients would even want to do this?? The whole idea of introducing a P-flag is to ensure that PD-capable devices do not request the prefix in residential networks.
If your customers realize they need /64 per device (because their devices are actually routers), they would ask for more addresses and that would be a legitimate case with or without this draft.

> Network SHOULD honor the hint, not MUST. Or better, the network MAY provide a prefix of the requested size (or not at all). In my opinion, it is OK for the network not to provide prefixes. In my case: connecting hosts is OK, so the /{80-127} is OK too. But as we do not generally allow routers/houters, we would not provide /{48-64} or even /{48-79} for unknown DUID (if /80 is the $MAX_PREF_FOR_HOST). So yes, the client should know how big a prefix it needs, but no is the legitimate answer from the network operator.

If the host needs X bits to do what it needs to do (provide connectivity to physical or virtual systems or form addresses) and the network says 'no',  the device doesn't have network connectivity.
Hence I still believe we need to agree on some recommendations on what the device shall expect and what the network MUST provide, if the P flag is set (if P flag is not set, it's OK, no PD then).
Otherwise this is not deployable: I can't guarantee that 3rd party devices connected to my network would work.

The point is: we can not recommend an approach which, if deployed, works for *some* devices only.
If I deploy this, I need this to work.
it's OK if some networks do not want/can not deploy this.

> > The draft is not just about host behaviour, it provides guidance for 
> > the network operator as well. As it's been mentioned in this thread 
> > already, most large BYOD networks would inevitably contain endpoints 
> > which are actually routers. Therefore I think it would be reasonable 
> > to include them.
>
> But then the scope would be too large. Routers and hosts require a different approach (even when both are using PD).

I think we shall stop differentiating between hosts and routers.
If we say in the draft "this deployment scenario is ONLY suitable for networks which meet the following criteria:
1) have enough address space
2) do not differentiate between hosts and routers." - would it address your concerns?

> >
> >> On 20. 04. 23 10:28, Pascal Thubert (pthubert) wrote:
> >>> Trouble is, a host needs /64 or longer. A router needs /64 or 
> >>> shorter. If we do not differentiate the scenarios, the only 
> >>> intersection is /64. Sadly it is a really bad trade-off in both 
> >>> cases…
> >>>
> >>> Now if you wish to discuss routing within the subnet (defined as the /64), I’m all for it. This is where things are going anyway, even if we hide it in underlays for the time being. But for that, we need to start with a solid architecture, and that is what 6MAN is doing with https://datatracker.ietf.org/doc/draft-ietf-6man-ipv6-over-wireless/.
> >>>
> >>> These are a total of 3 very different scenarios.  And a lot of confusion in the debates when all this gets mixed up in arguments.
> >>>
> >>> For this adoption, I suggest we us divide and conquer. The draft must discuss at least the host case. I’m good to discuss the router case if folks want that too in the traditional router operation (a /64 on each interface). For the MLTG piece, I suggest we conclude the architecture work at 6MAN first, and keep it out of scope in this  document.
> >>>
> >>> All the best
> >>>
> >>> Pascal
> >>>
> >>>
> >>>
> >>> From: v6ops <v6ops-bounces@ietf.org> On Behalf Of Lorenzo Colitti
> >>> Sent: mercredi 19 avril 2023 2:25
> >>> To: Martin Huněk <martin.hunek@tul.cz>
> >>> Cc: IPv6 Ops WG <v6ops@ietf.org>
> >>> Subject: Re: [v6ops] WG call for adoption: 
> >>> draft-collink-v6ops-ent64pd-03
> >>>
> >>> On Tue, Apr 18, 2023 at 10:31 PM Martin Huněk <martin.hunek@tul.cz<mailto:martin.hunek@tul.cz>> wrote:
> >>> So what is the scope of this draft? If it is for hosts, then the host doesn't need /64 and SLAAC. If it is for routers, then why are we trying to solve something that already works quite well? The document abstract suggests the first case - the host.
> >>>
> >>> You're correct that DHCPv6 PD works reasonably well. This draft describes an operational model and guidelines to make DHCPv6 PD work well on certain types of networks, like some enterprise networks. No protocol changes are needed, but there is still useful information in the draft. For example, it explains why bulk leasequery is needed when there are multiple default routers, it describes how the model impacts ACLs/filtering, etc.
> >>>
> >>> I don't think it's necessarily useful to try to distinguish between hosts and routers, because the distinction is very blurry. There are routers, then there are devices that users and operators think of as "hosts" which are actually routers in the sense that they forward packets not addressed to themselves, and then there are hosts that need multiple IPv6 addresses (see RFC 7934 for examples of why). This proposal supports all of them.
> >> _______________________________________________
> >> v6ops mailing list
> >> v6ops@ietf.org
> >> https://www.ietf.org/mailman/listinfo/v6ops
> >
> >
> >

--
SY, Jen Linkova aka Furry

_______________________________________________
v6ops mailing list
v6ops@ietf.org
https://www.ietf.org/mailman/listinfo/v6ops