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

[Mark Elkins <[e-mail]>]

Hu?

I was the author of the /48 IPv6 policy years back. This lead to 
2001:43f8::/48's being given out as PI. The primary opponent to this was 
Randy Bush.

I explicitly did this for the ZACR / UniForum SA - the South African 
Registry for CO.ZA - etc.

This gave the organisation:

2001:43f8:30::/48 	2007-07-30 	PI6 	UNIFORUM-V6-AFRICA

Now, if you are asking for PI space for the likes of anything associated 
with Lu Heng - I wouldn't be surprised if the AfriNIC Staff played hard 
ball and refused. As you are also associated, perhaps that is why you 
may find it difficult as well?

No offence intended - I don't work for AfriNIC.

On 2023/11/07 22:02, Owen DeLong wrote:
> 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
-- 

Mark James ELKINS  -  Posix Systems - (South) Africa
[e-mail]       Tel: [phone] <tel:[phone]>
For fast, reliable, low cost Internet in ZA: https://ftth.posix.co.za 
<https://ftth.posix.co.za>

Posix SystemsVCARD for MJ Elkins