Re: For whom is IPv6?

[Alexandre Petrescu <[e-mail]>]

Le 10/12/2020 à 10:03, Nico Schottelius a écrit :
> 
> Good morning,
> 
> thanks a lot for the various comments and feedback. I might need to
> take step a back and explain a bit more about the motivation to spin up
> a "for free ULA registry" (actually rhymes, doesn't it?).
> 
> I am rather young compared to some people here on the list. But what I
> learned when I was young is "you cannot buy an IP address" with the
> notion of "addresses are always free, you might pay for the service to
> give it to you, though".
> 
> So my understanding is that basic thought beyond building the Internet
> is to enable communication between different parties. I do not claim
> that there is no cost involved in this, as building (physical)
> connections does cost actual money.
> 
> Being active in the IPv6 community I see on a daily basis how users or
> potential users are struggling with a very basic need: the question of
> 
>            Which IPv6 addresses can I use?

Those that the IPv6 ISP provides.

If they dont provide the kind and quantity of IPv6 addresses that one 
needs then:
- one needs to ask the ISP for more GUA space
- one needs to ask a regulator to ask ISP to give more GUA space
- one needs to ask a Registry to ask ISP to give more GUA space
- one can ask the IETF if IETF would like to suggest the regulator (via
   a more weighted 'liaison') to ask the regulator to ask the ISP to give
   such space.
   In particular, in this area, I find that there is a discrepancy
   between what many contributors in 6MAN think the address availability
   should be and how much that message is relayed outside IETF.
   To be more precise: people routinely say here that an ISP should give
   a /48 to an end user;  but there is such a discrepancy between that
   belief and reality.
- one can write BCP documents at IETF, for informational purposes, about
   these needs.  These documents are freely and easily available, but it
   does not mean they are read, because there are so many other documents
   to read.

If all these fails then one can go to ULA registry.  Such a thing must 
exist.

One can also build new worlds on top of the existing network by using 
tunnelling.  In these new worlds anything is possible:  GUAs colliding 
with the real world, non-unique ULAs, non-IANA - absolutely anything; 
but they might be too slow.

> For many personal and non-profit organisations the answer at the moment
> is ULA. Why? Because there is no cost involved. No cost directly means
> that communities can act and innovations on their own. And as a long
> time Open Source hacker I can only say that the less hurdles you have to
> take, the more likely you can actually solve the original problems that
> you were tackling.
> 
> That said, users like community networks, do need some guarantee on
> non-collision of their networks. If Berlin uses 2001:db8:aa::/48, it
> would be good if Hamburg used something else. You can argue that within
> one community there is likely going to be a "local" database (i.e. a
> wiki or similar) of assigned networks.
> 
> But what if they merge with a different community? A lot of work needs
> to be done for something that is already been done on volunteer basis,
> this is not an easy task to do.
> 
> This can be solved by a ULA registry such as the one we
> provide. However, you might argue that these organisations should
> instead use GUA. I would personally even open to use an assigned block
> from ungleich to give it to the community. However, this will bind users
> to ungleich without an explicit need. And how is the space handled in
> case we are out of business? It's not the most secure option.
> 
> Then you could argue people should get PI space. That is a great idea,
> until you actually try to get PI space. The conditions set for the LIR
> to keep track of their sponsored parties and the formal requirements are
> neither easy for the user nor for the LIR. It is understandable from an
> RIR perspective that you do not want to have zombie address space, like
> we had in the IPv4 world, but where does it leave the users?
> 
> And this brings me to the topic of this email:
> 
>      For whom is IPv6?

For everyone and everything.

> 
> If global space is too cumbersome and/or expensive for non-profit
> organisations and if ULA space is fully random without a registry, what
> are users supposed to do?
> 
>>From my point of view I see a big shift towards IPv6 in the communities
> (open source, networking, even developers) at the moment. And I think it
> is crucial in this moment to give people who are interested in IPv6 the
> right tools. Today and not in a year or two.
> 
> I am by far not insisting on running a ULA registry. As a matter of
> fact, there are very, very rare cases I ever use ULA
> myself. However I do insist that we need to have a very easy entrypoint
> when it comes to the question of
> 
>       Which IPv6 address space can I use (without colliding in the future)?
> 
> There are many answers to this question, some sketches from my side:
> 
>        - Using the proposed ULA registry (fd00::/8)
>        - Defining fc00::/8 as "officiall registered, unroutable networks"
>        - Defining a totally different [GUA?] space for free usage, but
>          with automated alive checks
> 
> The first two options have been discussed to some extent, let me
> ellaborate a bit on the third option: As mentioned above, I am not
> deploying ULA much. With the main reason being that it prevents me in
> practice to use the space on the Internet.
> 
> What if we had a space that users can acquire directly ("register") and
> that requires (automated) alive checks from the user ("I am still using
> this network"). It could also require users to setup appropriate

I would love to be able to invent my own IP space and push it into a 
registry so no-one else uses it.  And then securely push it into the 
routing system too so everybody else sees it and routes to it.

This is the route-update concept that does work in some settings.

> security measures, like RPKI, MANRS, etc. if they wanted to connect to
> the Internet at some point in the future.
> 
> While slightly diverging from the original topic, the IPv6 ULA registry,
> I hope this email illustrates a bit more the motivation of why we do
> what we do and also that there is a need for a low barrier access to
> unique, assigned IPv6 address space. Because if access to IPv6
> addresses is expensive, I have nothing but to ask:
> 
>      For whom is IPv6?

For those who want it.

Alex

> 
> Best regards,
> 
> Nico
> 
> Brian E Carpenter <[e-mail]> writes:
> 
>> On 09-Dec-20 23:42, Nico Schottelius wrote:
>>>
>>> Hey Ted,
>>>
>>> Ted Hardie <[e-mail]> writes:
>>>> [...]
>>>> Because of how they [ULAs] are created, ULAs do not admit of such an
>>>> authoritative list.
>>>> [...]
>>>
>>> I understand your point and I think the whole ULA discussion could
>>> instantly be stopped, iif everyone had easy access to free IPv6 address
>>> space. As far as I can see PI space is not an option because of the
>>> current high administrative challenges (both as LIR and as a requestor).
>>>
>>> On the danger of going down the rabbit hole, I propose that ungleich
>>> provides an open source, open data, for-free ULA registry (*) using the
>>> fc00::/8 prefix that has been discussed before as centrally managed.
>>
>> That would trample on space that both the IETF and IANA have marked
>> as Reserved, so no, that would be a Bad Idea, IMHO. Who knows what
>> structure the IETF might decide for that space 10, 20 or 30 years
>> from now?
>>
>> fd00::/8 is a space full of pseudo-random numbers, so a registry
>> is certainly harmless.
>>
>>      Brian
>>
>>>
>>> This way there is no conflict with self assignment / self managed
>>> fd00::/8 range and neither the data nor the implementation is locked to
>>> stay with ungleich in the future in case
>>> IETF/IANA/any-of-the-five-RIRs/$other_org wants to take over.
>>>
>>> Best regards,
>>>
>>> Nico
>>>
>>> (*) The source code is already open source, usage is for free already,
>>> however so far there is no automated data export, which we could
>>> implement on a CSV basis and automatically update once per day.
>>>
>>> --
>>> Modern, affordable, Swiss Virtual Machines. Visit www.datacenterlight.ch
>>>
>>> --------------------------------------------------------------------
>>> IETF IPv6 working group mailing list
>>> [e-mail]
>>> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
>>> --------------------------------------------------------------------
>>> .
>>>
> 
> 
> --
> Modern, affordable, Swiss Virtual Machines. Visit www.datacenterlight.ch
> 
> --------------------------------------------------------------------
> IETF IPv6 working group mailing list
> [e-mail]
> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
> --------------------------------------------------------------------
>