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

[Vasilenko Eduard <[e-mail]>]

+1

-----Original Message-----
From: v6ops [mailto:[e-mail]] On Behalf Of Pascal Thubert (pthubert)
Sent: Tuesday, April 25, 2023 10:49 PM
To: Martin Huněk <[e-mail]>
Cc: IPv6 Ops WG <[e-mail]>
Subject: Re: [v6ops] WG call for adoption: draft-collink-v6ops-ent64pd-03

Thanks, Martin. You got it exactly right.

Regards,

Pascal

> Le 25 avr. 2023 à 20:18, Martin Huněk <[e-mail]> a écrit :
> 
> Hi Jen, see inline.
> 
>> On 21. 04. 23 18:39, Jen Linkova wrote:
>>> On Fri, Apr 21, 2023 at 1:31 AM Martin Huněk <[e-mail]> wrote:
>>> I agree with Pascal on this. I think that this document should concentrate on the host scenario only. Routers already work.
>> Which means that when I deploy PD for my, for example, Guest network 
>> segment, I have to expect that devices would request at least /64 - 
>> as some of them are hosts and some of them are routers.
> 
> 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).
>>> Even for the host case, you do not need to specify the exact length of the prefix (if you worry about the consensus). It is about the host implementation, how many addresses it needs, and how many bits for IID randomization it uses. From what I can see in the list, the general consensus seems to be between /80 and /96. So saying that: the biggest prefix requested by the host SHOULD NOT be shorter/larger than /80, and that host SHOULD use a long/small enough prefix to satisfy *its* addressing needs with sufficient IID randomization should be acceptable.
>> 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. 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.
>>> 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.
> 
> At the university, I'm looking more at IA_NA than PD. We do not allow user-managed routers, so they cannot extend our network by WiFi or whatever means. We do have contractual responsibilities to our upstream to allow connection of only authorized users, so the "Bring Your Own Router" policy is out of the question. However, the PD would give us a little more control over the mobile clients that do not support IA_NA but not with /64s.
>>> IMHO, if the option of having longer/smaller prefixes than /64 is not mentioned explicitly, then we end up with pure hosts eating up address space by /64 without any reasonable need. This would mean that admins would either need to disable PD even for legitimate routers or allow only known DUIDs to get a PD. Otherwise, they can easily run out of addresses.
>> [skip]
>>> I think that there is no need to reinvent the wheel. Routers would 
>>> use DHCPv6-PD regardless of this draft (or some "PD flag"),
>> So it would mean that routers (or any node which needs to extend the 
>> network behind its upstream interface) ask for $SLAAC_PREF_LENGTH or 
>> shorter, while "hosts" ask for whatever the new address assignment 
>> method supports (/80, /96 whatever).
>> Practically it means that the network shall be able to provide 
>> $SLAAC_PREF_LENGTH, otherwise some devices would not be able to get 
>> the network connectivity.
>> Would the following  summarize what you are suggesting?
>> - the node (the PD client) is "in charge" of making the decision what 
>> prefix length it's needed (based on the purpose of the PD prefix - 
>> network extension or smth else).
>> - the network must honour the hint sent by the client.
>> ?
> 
> Basically, yes, but with a small detail: 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.
>>> so they [JL: routers] should be out of its scope as there is nothing really new specifically for them.
>> 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). The first one should do what they are doing even now. Regardless of the "PD flag," they should ask for a prefix big enough to address its downstream interfaces. The behavior of the second ones (hosts) is to be modified by this draft (and the 6man one). They are the ones that should react on the "PD flag" and do a new address autoconfiguration method using delegated prefixes. So, in my opinion, these cases are entirely different, and mixing them won't do much good. I would not be happy if, because of some mixing of host-router scenarios, pure hosts would ask for /64.
> 
> Regards,
> 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
> _______________________________________________
> v6ops mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/v6ops
_______________________________________________
v6ops mailing list
[e-mail]
https://www.ietf.org/mailman/listinfo/v6ops