Re: [v6ops] WGLC: draft-ietf-v6ops-dhcp-pd-per-device-02

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

Hi Jen,

Dne úterý 17. října 2023 10:17:15 CEST, Jen Linkova napsal(a):
> On Fri, Oct 13, 2023 at 4:18 PM Martin Huněk <[e-mail]> wrote:
> > First of all, in section 8, paragraph 2:
> > At least in the RIPE region, it is based on FALSE assumption. Maximum ASSIGNMENT (without approval from RIPE) is /48, not /29 - this is default ALLOCATION. By the book, any organization is allowed to use ASSIGNED addresses, not ALLOCATED ones. So even as LIR with /29, I cannot use whole /29 for myself / my network. I can only use /48.
> >Rest I'm allowed to use for further ASSIGNMENTS to other subjects/organizations. The whole paragraph makes no sense, at least in the RIPE region.
> 
> I do not think we are making any assumptions. You are talking about a
> default assignment but it doesn't have to be a default one. Also, an
> LIR doesn't have to be an ISP - a large enterprise will be using
> assignments from its allocation to address its network, so the whole
> allocation will eventually be used for the network.

Regardless of whether the enterprise is a LIR or not, it is still allowed to make a maximum ASSIGNMENT of /48. So:
ALLOCATED-BY-RIR is /29
ASSIGNED is max. /48 (rule without using any exceptions)
You can use only ASSIGNED addresses (or AGGREGATED-BY-LIR, also max. /48). Even as a non-ISP LIR, you are not allowed to use more than /48 without RIPE approval or well-documented justification for future audit. See RIPE-738 5.4.2. I tried to persuade RIPE that I needed more address space without any luck.
> 
> > Section 7, second point from top:
> > This implies /64 or bigger. There are several problems with it:
> 
> We are actually trying to avoid implying. That section describes what
> shall be taken into account when configuring the *network*, and those
> considerations are to ensure the maximum applicability of the solution
> (increasing number of endpoints and scenarios it would support). We
> can say that the network is expected to provide /120 only, but if we
> do that currently it would break nit just devices w/o DHCPv6 support,
> but also all 7084-compliant routers, most of IPv6-only endpoints and
> also - as per current SNAC document - stub routers.
> I do not think we shall narrow the scope/applicability so much.

Extending the network by SLAAC is what implies /64 or more. Not every client is extending the network at every moment, so it is up to the client to indicate its need to extend the network.

IMHO, forcing the client to indicate its *current* needs is the proper way to not imply anything.
> 
> > 1) This is wasteful for Hosts (not routers as defined in I-D), as not every Client needs to extend a network.
> 
> If the host doesn't extend the network and doesn't run virtual systems
> behind it - no reason for it to request a SLAAC prefix. Please note
> that this document focuses on the network, not on the host.

Sure, but in the I-D, there is nothing that would even suggest that it SHOULD NOT / MUST NOT.
> 
> > 2) It should not be a MUST as a Host COULD set prefix-length hint to a bigger number, and then the second point is in direct opposition to the first one.
> 
> Ah I see where the confusion is coming from. The intention here is to
> ensure that the network MUST give the client a SLAAC-suitable prefix
> to clients which ask for such prefix.
> it's about the least common denominator, about the network is
> guaranteed to provide upon request.

But what is written there is to every client - regardless of client asking less.
> 
> The client may choose a longer prefix - or not to use PD at all.
> The idea is that this draft needs to define *what can be expected from
> the network*. So, to ensure that clients can:
> - extend the network connectivity to at least one interface (physical
> or virtual)
> or
> - use 464XLAT
> or
> - use SLAAC-only to address its interfaces
This is the point. The client SHOULD NOT (/MUST NOT) use it just to use SLAAC on its interface - this is wasteful, and there is no point in doing that apart from saving a few hours of programmer's time for generating shorter IID.
> 
> the network MUST provide a SLAAC-suitable prefix to such clients.
> 
> If I may, I'd like to use an analogy. The local regulations say that
> my company MUST provide me with 4 weeks of holidays per year. Some
> people decide that they do not need 4 weeks, and only take two. They
> don't have to request 4 weeks, but the company MUST still provide
> them. It's more or less the same here.

I don't know about that. I had one time a serious chat with my boss about me not using my holiday time ... :-)
> 
> So how about changing the second bullet point to:
> 
> "If the client does not include a prefix-length hint value into the
> request, the serverMUST provide a prefix short enough for the client
> to extend the network to at least one interface, and allow nodes on
> that interface to obtain addresses via SLAAC. The server MAY provide a
> longer prefix if the client hints for that."

Better, but why not mandate prefix-hint to be set for the smallest prefix the client would need to perform its function? If the server has more space to give, it can. Opting for a bigger prefix increases the likelihood of the server saying "No.". The default value of /64 (as any other value) is just more "implying".
> 
> > 3) Not every network policy allows the extension of the network, so MUST is contra-productive for such networks.
> 
> It's an informational document, such networks are not obliged to
> deploy the proposed solutions. They can continue to do what they  are
> doing now, or do smth completely different.
> If they have full control of the clients, they can make the clients
> hinting for the longer prefix.

Not if the vendor of those clients forces them to ask for /64, then you are out of luck. If the vendor in the future decides that it will not support any other method of autoconfiguration, then what?
> 
> However I have a question: Let's say I connect my phone (or my laptop)
> to your network. If the network provides IPv4, how do you know if my
> device extends the network, or not?

I can just guess that by device vendor. It is not the point. We are not discussing IPv4 here. With IPv6 DHCPv6-PD, I currently know that the device is, in fact, a router. Nothing else is doing PD now. If the usual host will ask, let's say, /120 or /96, I'm OK with it too. If everyone will ask /64, I just lost a valuable hint. It doesn't make my life easier.
> 
> > 4) Responsibility for a prefix-length hint lies on the Client, not on the server. The server does not know the intent of a client to extend the network or not. It does not know what type of device a client is (router/rhouter/host), if it needs to address other routed interfaces, needs to run VMs, and so on. This lies solely on the Client.
> 
> I think we are in the violent agreement here - the network/server
> doesn't know. So, the person configuring the network/server needs some
> guidance on what to configure to minimize the number of "broken"
> clients (it's not possible, as I've said before, to support a client
> with an arbitrary number of interfaces, and with an arbitrary levels
> of hierarchy/subtended routers) - so this draft claims that it
> supports at least one interface behind the client. To achieve that,
> the solution must guarantee that the client can ask for a
> slaac-suitable prefix. The client doesn't have to - the draft doesn't
> say "the client MUST always ask for /64".

If the client MUST set a prefix-hint to a meaningful number, a network administrator will see what is needed by them in PD. I would set the available pool based on what I'm expecting to be connected to my network (and what is allowed to connect) and based on the address space available. If the network policy forbids extending the network, it is fine to limit prefix size to less than /64. A client SHOULD NOT expect to get at least /64 every time in every network. This way, it would never ask for less. In other words, the real minimum is /64, and we have just divided address length by 2 - address space by 2^64. Not good.
> 
> > I would suggest to replace the second point in section 7 with something like:
> >
> > * The Client MUST set the prefix-length hint to a minimum value that would guarantee a sufficient address space for performing its function in the foreseeable future. The Client MUST follow [RFC8168] recommendations for processing the Advertise message. If the address space requirements of the Client change, the Client MAY request a new prefix of a different size.
> 
> This draft is not about the client, it's about what the network provides.

The client is an integral part of the autoconfiguration process, isn't it? The network should accommodate reasonable requests made by a client, not every request.
> 
> > It is up to the Client to know if it needs just a few addresses like /120 if it has one routed interface, so it needs /63 (one /64 for itself and one for its interface/VMs etc.), or if it is a router with let's say 8 routed interfaces. For some clients, /64 is simply too many; for some, it is too little, and it just cannot function with a single /64. It is up to the Client to request the right size of a prefix, and it is up to the server to honor such request (if its policy and resources allow it). Saying the prefix length MUST be /X simply limits use cases in which this approach can be used.
> 
> We need to agree on some common denominator. Some guidance for an operator.

And for client vendors, too. Do not ask for /64 or more when you do not need it. There is a risk that the network operator would not be able to accommodate that, and you might not get anything. If it happens, try to get less, and you may succeed in getting at least something.

What is better for a pure host (not extending the network in any way)? To get even just /120. Or to not get any IPv6 prefix?

Guidance for the operator should be: If you give less than /64, the clients will not be able to extend the network. This may impact their functionality. However, if you do not need that, it is OK to give less.

Martin
> 
> > Just a remark on the first point in section 6.2:
> > It is not explicitly written in RFC8987, but expiring prefixes in persistent storage could be solved by saving validity in absolute times. That is why RFC8987 calls for a synchronized clock.
> 
> I do not think the biggest problem is expiring prefixes, it's more
> like a device coming back up online w/o any state at all, so even
> existing prefixes would stop working, if the device doesn't do bulk
> lease query or active leasequery.
> 
> > Also, one editorial thing: there is a typo at the beginning of section 7.
> 
> Thanks, will be fixed!
> 
> > On 30. 09. 23 22:42, Xipengxiao wrote:
> > >
> > > Hi Folks,
> > >
> > > This message initiates a WGLC for draft-ietf-v6ops-dhcp-pd-per-device-02<https://datatracker.ietf.org/doc/draft-ietf-v6ops-dhcp-pd-per-device/>. The call will end on Oct 14, 2023.  Your opinion will be valued.
> > >
> > > Ron & XiPeng
> > >
> > >
> > >
> > > _______________________________________________
> > > v6ops mailing list
> > > [e-mail]
> > > https://www.ietf.org/mailman/listinfo/v6ops
> > _______________________________________________
> > v6ops mailing list
> > [e-mail]
> > https://www.ietf.org/mailman/listinfo/v6ops
> --
> SY, Jen Linkova aka Furry
>