Re: For whom is IPv6? [was: Happy St Nicholas Day: Re-Launching the IPv6 ULA registry]

[Mark Andrews <[e-mail]>]

One of the problems with ULA addresses is that they leak.  They leak in packet
headers.  They leak in DNS AAAA records.  They leak in SMTP Received lines.
And the list goes on.  This is nothing new.

For packet headers we have rules for site border gateways and transit routers.

For DNS AAAA records people deploy split horizon DNS which really is a pain in
the butt.  We can and should be able to do better.  AAAA records lack the ability
to specify the context in which they are valid.  This is something that can be
corrected and would be useful for ULA, IPv6 Link-Local, Mapped RFC 1918, Mapped
IPv4 Linked-Local addresses.

For SMTP Received lines we mostly ignore the issue.

Mark

> On 11 Dec 2020, at 06:04, Brian E Carpenter <[e-mail]> wrote:
> 
> I think David has it right. The confusing aspect of Nico's argument, to me,
> is that ULAs can never be of any use for wider connectivity outside the 
> organisation that "owns" the ULA prefix, *by the very definition of ULAs*.
> It doesn't matter in the slightest if "Hamburg" and "Berlin" use (by
> pure chance) the same ULA prefix, because there is no connection
> between both of them via various ISPs, and then *by definition* they
> cannot communicate using ULAs. So a collision doesn't matter, as well
> as being amazingly unlikely. If they find the money to interconnect,
> that's a different matter, but then they simply renumber to ISP-based
> prefixes. It isn't the address that costs money:
> 
> What costs money with a routeable prefix is not the prefix, it's the
> routeability and the connectivity. If that's a problem, it can only be
> solved by some such RIR policy approach as David describes. Has RIPE
> never considered this?
> 
> Regards
>   Brian Carpenter
> 
> On 11-Dec-20 02:50, David Farmer wrote:
>> So, I think your issue regarding Community Networks, while very important, is a question of RIR Policy and Fees, and not an issue for the IETF to solve. In the ARIN region, there are policies to deal with Community Networks. Please see;
>> 
>> https://www.arin.net/participate/policy/nrpm/#2-11-community-network
>> https://www.arin.net/participate/policy/nrpm/#6-5-9-community-network-allocations
>> https://www.arin.net/resources/fees/fee_schedule/
>> 
>> Based on those policies and the fee schedule, within the ARIN region, Community Networks can obtain a /40 allocation of IPv6 for a $250 annual fee. Please note that part of the reason for the definition ARIN has for a Comunity Network is to create the basis for a fee reduction or waiver in the future. However, there is no fee waiver or reduction at this time, nevertheless, this is far more affordable than creating a full LIR in the RIPE region, and even within the means of many individual persons to be a community benefactor by paying the ARIN Fees for a Community Network. Further note, that fees are a business issue, not a policy issue, within the RIR community, so policies don't set fees, but sometimes policies interact with or enable separate business discussions around fees.
>> 
>> So, I think a much better course of action is for you to start a discussion of this Community Networks issue within the RIPE Policy community, probably referencing the ARIN Policies above as a possible example and a separate but related fee discussion with the RIPE membership. 
>> 
>> Disclosure, I'm a former member of the ARIN Advisory Council.
>> https://www.arin.net/about/welcome/ac/
>> https://www.arin.net/about/welcome/ac/former/
>> 
>> Thanks.
>> 
>> On Thu, Dec 10, 2020 at 3:03 AM Nico Schottelius <[e-mail] <mailto:[e-mail]>> wrote:
>> 
>> 
>>    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?
>> 
>>    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?
>> 
>>    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
>>    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?
>> 
>>    Best regards,
>> 
>>    Nico
>> 
>>    Brian E Carpenter <[e-mail] <mailto:[e-mail]>> writes:
>> 
>>> On 09-Dec-20 23:42, Nico Schottelius wrote:
>>>> 
>>>> Hey Ted,
>>>> 
>>>> Ted Hardie <[e-mail] <mailto:[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 <http://www.datacenterlight.ch>
>>>> 
>>>> --------------------------------------------------------------------
>>>> IETF IPv6 working group mailing list
>>>> [e-mail] <mailto:[e-mail]>
>>>> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
>>>> --------------------------------------------------------------------
>>>> .
>>>> 
>> 
>> 
>>    --
>>    Modern, affordable, Swiss Virtual Machines. Visit www.datacenterlight.ch <http://www.datacenterlight.ch>
>> 
>>    --------------------------------------------------------------------
>>    IETF IPv6 working group mailing list
>>    [e-mail] <mailto:[e-mail]>
>>    Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
>>    --------------------------------------------------------------------
>> 
>> 
>> 
>> -- 
>> ===============================================
>> David Farmer               Email:[e-mail] <mailto:[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
>> ===============================================
> 
> --------------------------------------------------------------------
> IETF IPv6 working group mailing list
> [e-mail]
> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
> --------------------------------------------------------------------

-- 
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: [phone]              INTERNET: [e-mail]