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

[Vasilenko Eduard <[e-mail]>]

+1
Its very bad that draft still mislead for "/64 only for any type of sub-allocation (including DHCP or local algorithm)".
Ed/
> -----Original Message-----
> From: v6ops [mailto:[e-mail]] On Behalf Of Pascal Thubert
> Sent: Monday, October 23, 2023 10:29 AM
> To: Martin Huněk <[e-mail]>
> Cc: [e-mail]
> Subject: Re: [v6ops] WGLC: draft-ietf-v6ops-dhcp-pd-per-device-02
> 
> 
> 
> 
> > Le 21 oct. 2023 à 00:27, Martin Huněk <[e-mail]> a écrit :
> >
> > 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
> 
> There are limitations to the current Pd interface like the needs to:
> - associate a provable identity to the delegated prefix
> - provide the requested prefix length and expected lease duration
> 
> The idea that any network MUST delegate /64s is a fair way to kill IPv6 in
> enterprises. I MUST object.
> 
> The draft also highlights without saying that there’s a need to interface the
> delegation and routing.
> 
> Bottom line is that at the moment we are in requirement space not solution.
> This draft works and is applicable to certain areas. The danger is that as
> written it claims to be generally applicable and pushes for methods that are
> not applicable / acceptable in networks where we want IPv6 to thrive.
> 
> All the best,
> 
> Pascal
> 
> 
> >>
> >>> 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
> >>
> >
> > _______________________________________________
> > v6ops mailing list
> > [e-mail]
> > https://www.ietf.org/mailman/listinfo/v6ops
> 
> _______________________________________________
> v6ops mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/v6ops