[v6ops] What ie a site? (was: WGLC: draft-ietf-v6ops-dhcp-pd-per-device-02)

[David Farmer <[e-mail]>]

I contend a site is a physical location within an organization's network.
It's not an organization's entire network, as some seem to be claiming.

Let's look at a medium-sized enterprise with 13 locations, in this first
case, served by 13 different providers. In this case, each provider could
assign a /48 to each of the organization's locations and still be within
RIR policy. The organization would then have 13 separate /48 PA allocations.

If this organization, instead, purchased all 13 locations from a
single provider, why should it be limited to a single /48?  Furthermore, if
this organization qualified and wanted to go to its RIR for a direct
allocation, why should it be limited to a single /48 allocation?

This is an issue of RIR policy and should not be a direct consideration of
the IPv6 architecture. However, the argument has been raised as an
objection to this draft that an organization can only get a single /48 from
RIPE. This is bad policy on RIPE's part and not a valid reason to keep this
Draft from moving forward.

Whare as in ARIN's policy, the organization in this example would qualify
for a /40 assignment from its provider or for a /40 direct allocation from
ARIN. Further, once an organization qualifies for and decides it wants a
direct allocation from an RIR, there is no advantage to limiting it to a
single /48. They will use a routing slot whether they have a /48, a /40, or
a shorter prefix. RIR policy should ensure they have sufficient sized
prefix for the foreseeable future.

IPv6 addressing policy does need to consider conservation, but arbitrarily
limiting organization to a single /48 isn't conservation.

Thanks

On Fri, Oct 13, 2023 at 6:17 PM Martin Huněk <[e-mail]> wrote:

> Hi Folks,
>
> I'm sorry to come late to the discussion. I'll be commenting on version
> -03, as it seems to be a current one.
>
> 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.
>
> Section 7, second point from top:
> This implies /64 or bigger. There are several problems with it:
> 1) This is wasteful for Hosts (not routers as defined in I-D), as not
> every Client needs to extend a network.
> 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.
> 3) Not every network policy allows the extension of the network, so MUST
> is contra-productive for such networks.
> 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 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.
>
> 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.
>
> 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.
>
> Also, one editorial thing: there is a typo at the beginning of section 7.
>
> Best Regards,
> Martin
>
> 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
>


-- 
===============================================
David Farmer               Email:[e-mail]
Networking & Telecommunication Services
Office of Information Technology
University of Minnesota
2218 University Ave SE        Phone: [phone]
Minneapolis, MN 55414-3029   Cell: 612-812-9952
===============================================