Re: [v6ops] New Version Notification for draft-ietf-v6ops-dhcp-pd-per-device-05.txt

["[e-mail]" <[e-mail]>]

I can only think that you’re reading an older version of the policy manual. IPv6 PI has been there for many years, and it was updated with some of my policy proposals to be closer to other regions and allow any case that I can figure out:

6.8  PI Assignments

This policy is aimed at providing IPv6 address space to end-user organizations.
6.8.1 Introduction
This policy allows 'end-sites' of end-user organizations to be assigned IPv6 provider independent (PI) addresses. These include critical Infrastructure providers such as TLD root server operators and public Internet exchange Points (IXP's).
6.8.2 Assignment Criteria
Assignment target - End-user organizations which provide services for their administrative organizations’ network, regardless of their size.
Assignment criteria:
The organization must not be an LIR.
The organization must be or become an AFRINIC End User Member.
The organization must justify the number of end-sites and the need for the IPv6 PI address space.
The organization must deploy the IPv6 provider-independent address space at each of the end-sites, for which addresses are obtained, within twelve (12) months.
If the addressing space issued under this policy is to be announced, to the extent practicable, the organization should aggregate any announcements of prefixes so as to minimize global routing table growth.
6.8.3 Provider Independent (PI) address space:
The provider-independent (PI) assignment should be made from a specific block.
The initial provider-independent assignment size for each organization shall be at least a /48 per end site. If multiple end sites are requested and will be connected to each other, a nibble-aligned prefix shall be issued sufficient to allow at least one /48 per end-site. Valid justification for a shorter prefix for any end sites shall be accommodated.
The organization assignment will be calculated on the basis of the number of end-sites and adjusted to the nearest nibble-boundary.
Subsequent assignments must be documented and justified. Where possible, such assignments will be made from a contiguous address block (i.e., extending the existing assignment "n" bits to the left).
AFRINIC shall use a sparse allocation algorithm when issuing space to maximize the likelihood of success for the mechanism defined in the preceding paragraph.
6.8.4 Rectifying the size of an initial assignment
An organization may submit a new addressing plan to AFRINIC if the plan initially submitted to justify the initial assignment no longer satisfies their current needs.
The new assignment will be consistent with the new plan and comply with 6.8.2 and 6.8.3.
If possible, the same address block will be “upgraded” to the new required prefix size. However, if the adjacent prefixes are already being used by other organizations or if such assignment would not leave sufficient space for subsequent assignments, AFRINIC will inform to the requesting organization, which will have the following options:
Receive a new block with the new requested prefix size, with the agreement to utilize the new block for all future deployment and deprecate the old block through attrition, returning when empty. There is no deadline for return at this time;
Receive a new block which, together with the block that has already been assigned, covers the new justified need, and keep both blocks.
This procedure can only be used once by each organization.
6.8.5 “Sub-Assignments” not allowed.
It is allowed to use the assigned addresses for:
the assignment holder network
third party devices operating within that infrastructure
interconnections 
It will be considered a sub-assignment and consequently, it is not allowed to use the assigned addresses for providing services to customers (such an ISP), data-centre or similar cases.

Regards,
Jordi

@jordipalet


> El 7 nov 2023, a las 21:02, Owen DeLong <owen=[e-mail]> escribió:
> 
> Disagree.
> 
> First, the level of restrictiveness in the policy is more restrictive (for one thing, there is no provision for IPv6 PI to end sites in AFRINIC).
> Second, the AFRINIC staff implementation of policies doesn’t tend to align very well with the written policies and they can be very
> discriminatory about it based on undocumented and unpublished criteria. There is no consistency of customer experience in trying
> to obtain addresses from AFRINIC.
> 
> Hopefully once AFRINIC has a new board, they will appoint new management and start to fix some of these issues, bu until then,
> the fact remains that AFRINIC is the most difficult registry to deal with and the least prone to processing requests in any reasonable
> time frame or equitable manner.
> 
> Owen
> 
> 
>> On Nov 7, 2023, at 01:31, [e-mail] <jordi.palet=[e-mail]> wrote:
>> 
>> Since the last policy changes that I proposed in AFRINIC, I don’t think we can say they are more restrictive than in the other regions. Basically, from a practical point of view, all the regions look almost the same now.
>> 
>> Regards,
>> Jordi
>> 
>> @jordipalet
>> 
>> 
>>> El 6 nov 2023, a las 22:51, Delong.com <owen=[e-mail]> escribió:
>>> 
>>> 
>>> 
>>>> On Nov 6, 2023, at 11:46, Martin Huněk <[e-mail]> wrote:
>>>> 
>>>> Hi,
>>>> 
>>>> Dne pondělí 6. listopadu 2023 10:00:14 CET, Lorenzo Colitti napsal(a):
>>>>> On Mon, Nov 6, 2023 at 2:41 AM Martin Huněk <[e-mail]> wrote:
>>>>> 
>>>>>> If you have at least X+32 of IPv6, you can be in the same situation with
>>>>>> IPv6 as you are in IPv4. Now, do we want to be in the same situation? Why
>>>>>> migrate to IPv6, then?
>>>>>> 
>>>>> 
>>>>> It's not the same situation. As the draft explains, x+32 is 32 times better
>>>>> than IPv4 if we never move beyond 2000::/3. If we move beyond 2000::/3,
>>>>> it's 256 times better than IPv4. Whether any given network has enough space
>>>>> for that is up to the operators and the RIRs. Based on your comments, it's
>>>>> clearly not enough for your network. That's OK - whether a network uses
>>>>> this model is up to the network, and it's pretty clear that there are some
>>>>> networks, like home networks with only a /64 or a /60, that will never be
>>>>> able to run this model due to lack of space.
>>>> 
>>>> I do have /16 of IPv4 and /48 of IPv6. By the formula presented in the draft I get the exact result:
>>>> X = 16
>>>> 16 + 32 = 48
>>>> So I'm in precisely the same situation as I'm with IPv4. How is it any better than the address-space constraints of IPv4? I do not necessarily care who is to blame. I just know what I have, and even if I'm allowed to expand the address space, I would be forced to renumber. There would be almost zero gain for clients having /64 compared to /80 (when we do not allow network extension), so for me personally, having a strict /64 barrier is just a complication and a poor design choice, especially when a host is not informing how big a prefix it really needs.
>>> 
>>> Well… In IPv4, you have 65,536 unique addresses and can number (up to) 65,534 unique hosts (assuming a flat network with no subnetting) and each host gets exactly one address.
>>> 
>>> With this proposal, you can (theoretically) number 65,536 unique hosts each of which can either provide a downstream subnet to attached hosts (acting as a router) or unique additional address to containers/VMs/services/whatever on the actual host (or presumably with some creative allocation policy and bridging some combination of both).
>>> 
>>> So I wouldn’t call that “exactly the same situation”. Further, not every host has to ask for or receive a /64, presumably this is being done through PD on request, so you could have entire networks that don’t make use of this draft or parts of networks or…
>>> 
>>> There’s a lot more flexibility here than with IPv4 even in the worst case scenario that you focus on, and the reality is that very few implementations will actually represent the kinds of absolutism being discussed here.
>>> 
>>>>> FWIW, I think you said that in order to use this you'd need to assign a /49
>>>>> to your Wi-Fi network? That doesn't seem unreasonable to me, or to other
>>>>> operators that are part of this discussion.
>>>> 
>>>> It doesn't seem reasonable to me. It is half of my address space, and I won't be getting more; it is without reserves to expand, and I had to move several networks to clear it. If a host would have been fine with /80, I would be just fine with one /64 or /63 (or /60). I could manage just fine with what I have. It makes even more sense as we do not allow a network extension.
>>> 
>>> OK, since you don’t allow network extension, and you don’t want to support SLAAC in your environment, presumably you can implement outside of the recommendations contained in this draft. AIUI, this is an informational / best practice draft and not a standards-track document. As such, I think we should document the case that covers the majority of use situations and accept that some corner cases (such as yours) may not fit.
>>> 
>>>>> 
>>>>> Remember, what we are trying to do here is a compromise: provide to network
>>>>> operators the control and tracking that they like to have via DHCPv6, while
>>>>> ensuring that connected devices can support pretty much any use case,
>>>>> including hosts forming unlimited addresses, plugging in routers, and doing
>>>>> a moderate amount of network extension with end-to-end connectivity and
>>>>> without NAT. We think this model has a lot of advantages, but it's
>>>>> definitely not the only one.
>>>> 
>>>> If any user is allowed to extend the network, how do I know who is the end user? Unsupported, not allowed things should be hard to get working. If someone tries to extend the network (while not allowed to do so), I want his/her attempt to fail. Then, the broken connectivity is desired.
>>>> 
>>>> Btw: Do you have any data about how big a share of a company allows the "bring your own router" policy in their corporate network? Network extension in corporate networks is not a common use case, in my opinion.
>>> 
>>> Network extension within policy is not a common use case.
>>> 
>>> As someone whose job has regularly included tracking such extensions down and extinguishing them due to policy != user intent, I can absolutely guarantee you that it is a much more common use case than you’d like to believe. I’ll also guarantee you that users will go to impressive and bizarre lengths to do so.  In the IPv4 world, the common solution is just more layers of NAT which (IMHO) is even worse because now the extension is virtually transparent, nearly undetectable, and a major pain to identify and resolve.
>>> 
>>> At least if the host is asking for a /64 and extending the network, you have some visibility into what is happening, even if the exact topology isn’t 100% transparent.
>>> 
>>> Bottom line, today, what you don’t want to allow is already super easy in IPv4.
>>> 
>>>>> I agree with Gert. You can have /80s all you want, but you are not getting
>>>>>> /64s from me. If your implementation requires it, then it is NAT66 for you,
>>>>>> ND proxy, or IPv4 only. You choose.
>>>>>> 
>>>>> 
>>>>> I hate to say it, but... network operators saying, "my network, my rules"
>>>>> and insisting that devices will only have the amount of address space that
>>>>> they think they need is precisely why host implementers don't trust
>>>>> networks to do the right thing.
>>>> 
>>>> The implementers know less about the network the device is connected to than the admins running it. Quite frankly, you would not be able to know local restrictions, nor would you care.
>>>> 
>>>> Yes, we can make this mutual distrust basis to reconsider BYOD policies.
>>> 
>>> This is a religious issue that isn’t (and probably shouldn’t) going to get resolved in the IETF, IMHO.
>>> 
>>> Each network operator and the hosts administrators using said network ends up having to find some balance they can both accept on a case-by-case basis.
>>> 
>>> In environments where there are professionals on both sides of the equation able to work as a team, this can go fairly smoothly. In environments where host administration is the Wild West of software developers doing whatever they think they need without regard to network or corporate policy, this can be a much bigger adventure. In environments where the networking team went to the BOFH school of network management, this can also be a much bigger adventure.
>>> 
>>> I’ve seen examples of all three of these scenarios. The obvious worst case is Wild West developers + a BOFH trained network team (and I’ve seen that too).
>>> 
>>>>> This is why we need a fixed boundary - otherwise we end up with a race to
>>>>> the bottom that ends at /128. At the moment, the only possible fixed
>>>>> boundary is /64, because once the device gets a /64, it can do whatever it
>>>>> wants, and extend the network all it wants, using SLAAC. If we make SLAAC
>>>>> run on longer prefixes, then maybe we'll all agree on one size. But who
>>>>> knows if that will work. Just like you say, "you can have all the /80s you
>>>>> want, but you're not getting /64s", some other operators saying, "you can
>>>>> have all the /128s you want, but you're not getting /80s". One thing at a
>>>>> time. If we make this model work with /64s, maybe it's possible to imagine
>>>>> changing SLAAC.
>>>>> 
>>>> Do you really think that? Yes, there will be some networks that will use IPv4 principles and try to conserve IP space so much that they try to give too little to clients. However, many more are adhering to recommendations made by IETF or RIR. At ISP, I give /56 to residential clients, /48 to companies (or upon request). I could give just /64 or /60, but I know what I would like to have at home and how many I can assign to maintain a reasonable addressing plan. It is up to me as a Network administrator to make the plan and configure my routers accordingly.
>>> 
>>> Last I looked, the largest US Cable MSO is giving out /64 to residential end users unless they request up to a /60. The won’t give anything shorter than /60 to a residential customer.
>>> 
>>> I believe their business customers can get up to a /56.
>>> 
>>> There’s a guy running around most of the WISP conferences in the US that unfortunately has the ear of lots of WISPs and preaches /60 for customer end sites. 
>>> 
>>> As such, I think your statement about “most” might hold water, but in terms of most customers impacted, no, it does not.
>>> 
>>>> I'm not really in the camp of let's change an SLAAC prefix size as we would not see practical results in years to come. However, if it provides me with additional tools to manage my networks, then why not?
>>> 
>>> I could care less about changing the SLAAC prefix size, but I wouldn’t oppose a draft requiring support for greater prefix size flexibility in SLAAC. My concern is that if we manage to make SLAAC with /80 (for example) default working configuration across a wide variety of residential gateways, you’ll see MSOs treat that as an excuse to start handing out /76 instead of /60.
>>> 
>>>> This draft is a bit different. If every device required a /64 and it would like to extend the network, I would be pushed around, and I hate that. Clients would push me to give them /64, SCO would push me on network security front, and RIPE policy and upstream addressing plan are constraining me with address space. Having an OS vendor pushing me with the substantial number of devices is the thing I need the least.
>>> 
>>> Actually, RIPE policy isn’t constraining you here. RIPE policy would allow you to request additional space.
>>> 
>>> RIPE already defaults to /29 and virtually any half-way believable justification for a shorter prefix is acceptable under their policy. Similarly, ARIN policy provides a great deal of flexibility here with pretty generous nibble-boundary round-ups. I believe the most restrictive IPv6 policy remains AFRINIC and even it provides relatively easy ways to get enough address space to accommodate this draft.
>>> 
>>> Owen
>>> 
>>> _______________________________________________
>>> v6ops mailing list
>>> [e-mail]
>>> https://www.ietf.org/mailman/listinfo/v6ops
>> 
>> 
>> **********************************************
>> IPv4 is over
>> Are you ready for the new Internet ?
>> http://www.theipv6company.com
>> The IPv6 Company
>> 
>> This electronic message contains information which may be privileged or confidential. The information is intended to be for the exclusive use of the individual(s) named above and further non-explicilty authorized disclosure, copying, distribution or use of the contents of this information, even if partially, including attached files, is strictly prohibited and will be considered a criminal offense. If you are not the intended recipient be aware that any disclosure, copying, distribution or use of the contents of this information, even if partially, including attached files, is strictly prohibited, will be considered a criminal offense, so you must reply to the original sender to inform about this communication and delete it.
>> 
>> _______________________________________________
>> v6ops mailing list
>> [e-mail]
>> https://www.ietf.org/mailman/listinfo/v6ops
> 
> _______________________________________________
> v6ops mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/v6ops



**********************************************
IPv4 is over
Are you ready for the new Internet ?
http://www.theipv6company.com
The IPv6 Company

This electronic message contains information which may be privileged or confidential. The information is intended to be for the exclusive use of the individual(s) named above and further non-explicilty authorized disclosure, copying, distribution or use of the contents of this information, even if partially, including attached files, is strictly prohibited and will be considered a criminal offense. If you are not the intended recipient be aware that any disclosure, copying, distribution or use of the contents of this information, even if partially, including attached files, is strictly prohibited, will be considered a criminal offense, so you must reply to the original sender to inform about this communication and delete it.