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

[Martin Huněk <[e-mail]>]

Dne úterý 25. dubna 2023 21:19:02 CEST, Jen Linkova napsal(a):
> On Wed, Apr 26, 2023 at 4:18 AM Martin Huněk <[e-mail]> 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.

Do we have to take inspiration from IPv4? Yes, in IPv4, we would not know that, but in IPv6, we can be reasonably sure. If it asks for PD now, it is a router. After the implementation of this draft, does it makes the situation better for me? How do I differentiate them then? We do have other tools like monitoring WLANs and their SSIDs (we can even send rogue DEAUTHs), but this is harder than looking in the DHCP log.
> 
> 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?

In general, the DHCPv6-PD is the way to go. No doubt about that. But if the network policy forbids connecting them and you still do that, then it is OK that such a device should not get access, isn't it?
> 
> > > 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.

If it does have downstream interfaces, it is a router (even by RFC 8200 definition). The question is, is it a reasonable architecture to have a routed segment inside a VM host? Usually, you would have a bridge for virtualization. Also, the VM host can deploy DHCPv6. It is also a widely supported option that does not require /64 for an interface to run.

BTW this is why we have to differentiate between hosts and routers/houters and define "itself".
> 
> >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.

If you are defining a new method for a host autoconfiguration, you can easily add a method for IID generation to come with it, or you can just reuse RFC 7217 code, as it should allow any length of the IID.
> 
> > >> 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.

Why not? If some thinks that this has the potential to replace SLAAC or even IA_NA ... But you are right that if the devices are routers, then they will ask for prefix one way or the other - another point for differentiation.
> 
> > 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.

Sure, we must, and once again, we had to differentiate between host and router/houter. Saying (example only): The "PD flag" is for "pure" hosts only, indicating that they can address *themselves* from the PD prefix. The host can expect a minimum of /96, and the network MAY provide, by default, up to /80 per host. Then the host knows that it may try to get up to /80 but will be ready to fall back to /96.

If the device is a router/houter then it will ask for PD regardless of the "PD flag". It should ask for sufficient prefix length, but it is not guaranteed to receive it (it is not even now). No need to connect it to the host case.
> 
> 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.

I agree. There has to be a minimum and maximum prefix length that a device can expect to receive when a "PD flag" is set. But also, can we recommend an approach that works just for *some* networks?
> 
> > > 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 the contrary, we MUST differentiate between them as they do so even now. The router is not interested in the "PD flag". It will ask for PD anyway. One of its responsibilities in IPv6 is to provide addressing for its downstream interfaces for standard clients, so it depends on SLAAC/DHCPv6 support for its clients.

Conversely, the host is currently using either SLAAC or the DHCPv6 IA_NA, not PD. It would react to the "PD flag" to try a PD. It does not have downstream interfaces, needs a very limited number of addresses, and as it is addressing just "itself" it can deploy any IID generation method.

If you set these criteria, you would limit applicability to networks that are:
1) LIR-only, or
2) Are small but hold /48, or
3) Are bad actors or exceptions to the /48 per subject RIR rule.

As mentioned before, routers and hosts behave differently even now, and this draft doesn't change that. If it would, you would not need that "PD flag," would you?

So obviously, no, that would not address my concerns; it would somehow magnify them.

Martin
> 
> > >
> > >> 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 <[e-mail]> On Behalf Of Lorenzo Colitti
> > >>> Sent: mercredi 19 avril 2023 2:25
> > >>> To: Martin Huněk <[e-mail]>
> > >>> Cc: IPv6 Ops WG <[e-mail]>
> > >>> Subject: Re: [v6ops] WG call for adoption: draft-collink-v6ops-ent64pd-03
> > >>>
> > >>> On Tue, Apr 18, 2023 at 10:31 PM Martin Huněk <[e-mail]<mailto:[e-mail]>> 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
> > >> [e-mail]
> > >> https://www.ietf.org/mailman/listinfo/v6ops
> > >
> > >
> > >
> 
> 
> 
>