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

[Owen DeLong <[e-mail]>]

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