Subject: Happy St Nicholas Day: Re-Launching the IPv6 ULA registry

From: Nico Schottelius <[email-masked]>
Date: Sun, 06 Dec 2020 00:19:45 +0100

Good morning,

we have just launched a ULA registry [0] as part of our IPv6 advent
calander [1]. While the reception, openness and opinions of whether or
not there should be a ULA registry at all differ, a ULA registry has
been requested multiple times from our customers in the past.

The source code of the ULA registry is fully Open Source and can be
found on [2]. It currently operates using the fd00::/8 subnet, whereas
draft-hain-ipv6-ulac-02 [3] suggests that RFC4193 should be followed for
that subnet and fc00::/8 should have been taken for a ULA registry.

However the original SixXS database records [4] on which we based our
work operatios in fd00::/8 and according to wikipedia [5] there is no
consensus over fc00::/8 in the IETF.

Speaking for ungleich, we do not use ULA ourselves, however our users
do. In this regard our position is somewhat neutral with the focus of
"enable users to move forward with IPv6".

However in the spirit of collaboration and finding a consensus for a ULA
registration, we could imagine phasing in fc00::/8 as the default prefix
for generating new prefixes while keeping the historic information of
the previously registered prefixes that originally came from SixXS.

Looking forward to your feedback.

Best regards from the snowy mountains in Switzerland,

Nico

[0] https://ula.ungleich.ch/
[1] https://ungleich.ch/u/advent-calendar/06/
[2] https://code.ungleich.ch/ungleich-public/ipv6ula
[3] https://tools.ietf.org/html/draft-hain-ipv6-ulac-02
[4] https://www.sixxs.net/tools/grh/ula/list/
[5] https://en.wikipedia.org/wiki/Unique_local_address

--
Modern, affordable, Swiss Virtual Machines. Visit www.datacenterlight.ch

---

From: Lorenzo Colitti <[email-masked]>
Date: Mon, 7 Dec 2020 09:42:28 +0900

Nico,

This seems a bit misguided for several reasons.

First, registries are supposed to be authoritative databases, but the RFC
specifies that ULA addresses are generated pseudo-randomly. Therefore, if a
pseudo-randomly allocated address conflicts with something in the registry,
the registry should be deemed incorrect.

Another problem is: the prefixes in the registry have to be unique because
that's what ULAs are. But I bet there are duplicates right now. For
example, I'm pretty sure more than one network in the world is using
fd00::/48 right now. In fact, I just configured it on my network, so if
there was no duplicate before, there is one now. :-)

Lots of other problems, of course, such as: what happens if someone else
launches a similar registry? And so on.

Regards,
Lorenzo

On Sun, Dec 6, 2020 at 8:20 AM Nico Schottelius <
[email-masked]> wrote:

> --------------------------------------------------------------------
> IETF IPv6 working group mailing list
> [email-masked]
> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
> --------------------------------------------------------------------
>

---

From: Fernando Gont <[email-masked]>
Date: Mon, 7 Dec 2020 05:28:13 -0300

Hi, Lorenzo,

On 6/12/20 21:42, Lorenzo Colitti wrote:
> First, registries are supposed to be authoritative databases, but the 
> RFC specifies that ULA addresses are generated pseudo-randomly.

Strictly speaking, there exist registries that are not authoritative -- 
e.g., think of the registered ports in the port number registry.

> Therefore, if a pseudo-randomly allocated address conflicts with 
> something in the registry, the registry should be deemed incorrect.

Following the logic of the port number registry, if two organizations 
use the same prefix, the registry could simply note that.

That said, I'm not sure:

1) Whether folks would be compelled to register their blocks.

2) (Partly as a result of #1), the extent to which a registry would be 
of any use.

That aside, in a way the whole point of randomizing the ULA prefix is 
that results statistically unique. So, provided folks do follow the 
advice in the ULA spec (I for one have *not :-) in a number of 
occasions), there shouldn't be much of a need to actually register ULA 
prefixes... (if the prefixes are unique... who cares who uses what?)

Thanks,
-- 
Fernando Gont
SI6 Networks
e-mail: [email-masked]
PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492

---

From: Brian E Carpenter <[email-masked]>
Date: Tue, 8 Dec 2020 09:20:29 +1300

> e.g., think of the registered ports in the port number registry.

That's not a useful analogy. Those ports need to be registered because
they are potentially used across the open Internet. ULAs are by
definition not used across the open Internet. Therefore, they don't
need a registry.

(That's why we've never reached any kind of consensus about ULA-C:
by definition, they don't need to exist.)

(Nico: but thanks anyway. I was a bit sorry when that aspect of sixxs
went away.)

>> something in the registry, the registry should be deemed incorrect.

Not even incorrect (to echo "not even wrong" [1]).
 
> use the same prefix, the registry could simply note that.

It could. As Lorenzo hinted, the most frequent entry would be zero.

Any arbitrary string of digits occurs an infinite number of times
in the expansion of π. That means that your ULA prefix also occurs
an infinite number of times in the (hexadecimal) expansion of π.
That fact is as much use as a ULA registry (a list of random numbers).

> 1) Whether folks would be compelled to register their blocks.

I'm sure: no.
 
> 2) (Partly as a result of #1), the extent to which a registry would be 

I'm sure: no use at all.

> prefixes... (if the prefixes are unique... who cares who uses what?)

Sorry, but I don't think "statistically unique" is a well-defined term.
The property of a ULA prefix is that there is a very low probability
of collision if two ULA networks are merged. (For the details, see
https://tools.ietf.org/html/rfc4193#section-3.2.3).

If I was writing a script to merge two networks I'd have to test for
that case, but despite the birthday paradox, I don't think I'd put
more effort into it than throwing an exception.

BTW, what I found useful in the old sixxs tool was the ULA prefix
generator. Not sure why ungleich wants me to log in to use that feature.

Regards
   Brian

[1] https://en.wikipedia.org/wiki/Not_even_wrong

---

From: Nico Schottelius <[email-masked]>
Date: Mon, 07 Dec 2020 23:30:34 +0100

Good evening Lorenzo,

> the registry should be deemed incorrect.

In this regard I somewhat disagree: From my point of view no ULA
registry will ever be fully authoritative, because the networks are not
intended to be used on the Internet.

Indeed, we are even considering to intentionally allow double
registration. The motivation behind this is that due to its
non-authoritative state any ULA database can only have indicative
character. As such a registration (from my point of view says):

   "Hey, I am using xx/48. It would be great if you don't intentionally
   start using it."

> fd00::/48 right now.

fd00::/48 is actually an example entry created during the Hackathon,
which led us to implement the random generation instead as the primary
option instead of focussing on submission of existing prefixes.

> In fact, I just configured it on my network, so if

With that argument even GUA is not GUA - I can also configure 2600::/32
or even 2001:db8::/32 in my network, it does not make me "own" 2600::/32
nor remove the documentation character from 2001:db8::/32.

> launches a similar registry? And so on.

If someone else launches a similar registry, we are open for (automatic)
exchanges. As a matter of fact: if anyone else is interested in, I would
recommend to use our source code so it will be an easier basis to
exchanges data later.

Best regards,

Nico

---

From: Nico Schottelius <[email-masked]>
Date: Tue, 08 Dec 2020 00:05:47 +0100

Hey Brian,

Brian E Carpenter <[email-masked]> writes:>
> It could. As Lorenzo hinted, the most frequent entry would be zero.

Both arguments speak for allowing double registration, so that people
are actually aware who is using what. If nobody has a good motivation to
disallow multiple registrations for the same prefix, we will implement
this the next days.

> generator. Not sure why ungleich wants me to log in to use that

Because we did not think about anybody using it without wanting to
register it, but it's a good idea. And it has just been implemented and
published on https://ula.ungleich.ch/random/.

Best regards,

Nico

---

From: "Manfredi (US), Albert E" <[email-masked]>
Date: Mon, 7 Dec 2020 23:48:04 +0000

-----Original Message-----
From: ipv6 <[email-masked]> On Behalf Of Nico Schottelius

As long as opinions are being solicited, we are using ULAs much as we use RFC 1918 addresses in IPv4. And, I use a specific PRNG to generate the random Global ID bytes in the prefix, same PRNG used for all of the ULAs in all of these various intra-platform networks. So that among these platforms, there won't be any address conflicts.

But we have no intention to make these addresses available to the public. Even though these nets are isolated and firewalled, one of the main attractions of ULAs is that they are not globally reachable, administered, or even globally known.

Not saying you should not pursue this ULA registry idea. Just pointing out, it may be almost guaranteed to be incomplete. Unless I'm the only person to use ULAs this way, which I doubt.

Bert

---

From: Fernando Gont <[email-masked]>
Date: Mon, 7 Dec 2020 21:50:03 -0300

Hello, Brian,

On 7/12/20 17:20, Brian E Carpenter wrote:
> they are potentially used across the open Internet.

I'm not sure that's the case (i.e., that all registerd ports are used in 
the open Internet).  That said, I was simply pointing out that such 
registry does have "conflicts" -- i.e., same port used by multiple 
protocols/apps.

> ULAs are by

Agreed on this one.

>> 1) Whether folks would be compelled to register their blocks.

I, for one, wouldn't :-)

> https://tools.ietf.org/html/rfc4193#section-3.2.3).

Thanks for pointing this --. I stand corrected.

(Must say, anyway, that things like " Globally unique prefix (with high 
probability of uniqueness)." leads to some confusion).

Possibly dumb question, since I wasn't there: what was the reason for 
carving ULAs out of the GUA space?  -- i.e., not updating the addressing 
architecture, and marking the ULA block as something other than GUA.

Thanks!

Regards,

---

From: Fernando Gont <[email-masked]>
Date: Mon, 7 Dec 2020 22:07:50 -0300

On 7/12/20 19:30, Nico Schottelius wrote:
[....]
> nor remove the documentation character from 2001:db8::/32.

FWIW, for all practical purposes, ULAs are non-global-scope addresses -- 
the only reason (?) they are considered global is that RFC4291 still 
marks the ULA "space" as GUA, and RFC4193 hasn't updated that.

So, an ULA is not meant to be globally usable, and only make sense 
within an organization (whatever that means) -- and the same ULA prefix 
being re-used is just fine.

OTOH, GUAs are globally-meaningful -- and while you can indeed configure 
any GUA prefix you want, you will not get the return traffic (which you 
*would* if you really owned the prefix).

Thanks,

---

From: Brian E Carpenter <[email-masked]>
Date: Tue, 8 Dec 2020 14:58:46 +1300

> marks the ULA "space" as GUA, and RFC4193 hasn't updated that.

It's also a bit of a historical accident, too. ULAs were invented at
the same time that site-local was deprecated [1]. They are routeable
(unlike link-locals) so RAs, PIOs and routing protocols treat them
exactly like any other routeable address. So, given that site-local
scope was abolished, they could only be called global-scope.
They are only special in domain boundary routers, which should
block them.

Yes, this has led to confusion in the terminology, only partly
resolved by https://tools.ietf.org/html/rfc8190#section-2.1 
 
> being re-used is just fine.

There were two arguments for making re-use highly unlikely. Merging two
ULA networks, as I already mentioned, or VPNs interconnecting two ULA
networks. We were told that both of those were real, active operational
problems with RFC1918 addresses.

> *would* if you really owned the prefix).

Right. In that sense a ULA prefix really is a GUA subset - it should never
be advertised in transit networks or the mythical DFZ.

Regards
    Brian

[1] https://tools.ietf.org/html/rfc3879

---

From: Fernando Gont <[email-masked]>
Date: Tue, 8 Dec 2020 00:39:07 -0300

Hi, Brian,

> scope was abolished, they could only be called global-scope.

"IPv6 private-use address space"?

FWIW, this might seem overly pedantic to some, but I found myself 
reviewing some of the associated definitions.

For "scope", RFC4007 says:

---- cut here ----
     Every IPv6 address other than the unspecified address has a specific
     scope; that is, a topological span within which the address may be
     used as a unique identifier for an interface or set of interfaces.
     The scope of an address is encoded as part of the address, as
     specified in [1].

     For unicast addresses, this document discusses two defined scopes:

     o  Link-local scope, for uniquely identifying interfaces within
        (i.e., attached to) a single link only.

     o  Global scope, for uniquely identifying interfaces anywhere in the
        Internet.
---- cut here ----

Clearly, from this definition, ULAs are not really "global scope":

* ULAs can be used to uniquely identify an interface or set of interface 
within a site/organization -- there can certainly be collisions (and 
that's okay)

* It would seem to me that there's not really any difference between 
"global scope" and "globally reachable" (although I'd probably say 
"globally forwardable", as e.g. middleboxes such as firewalls can 
certainly affect actual reachability)

> problems with RFC1918 addresses.

Making the re-use unlikely is indeed sensible (might avoid problems, 
so.. why not?). Still, that still sounds to me like "non-global 
addresses, with high chance of uniqueness", so to speak.

(I found myself trying to explain why ULAs are "global scope", and let's 
say I didn't buy my own argument :-) )

Thanks,

---

From: Nick Hilliard <[email-masked]>
Date: Tue, 8 Dec 2020 10:26:50 +0000

Nico,

Nico Schottelius wrote on 07/12/2020 22:30:
> registry will ever be fully authoritative

No ULA registry will ever be authoritative in any way.

As a separate concern, without a garbage-collection mechanism, any 
registry will end up being full of garbage in the longer term.

Nick

---

From: Nico Schottelius <[email-masked]>
Date: Tue, 08 Dec 2020 11:39:47 +0100

Hey Nick,

> registry will end up being full of garbage in the longer term.

It's another very good point. I think we could solve this by adding a
timestamp to the record, when the prefix was last verified. If it has
not been verified for a certain time (maybe 2-3 years?) it could be
dropped from the database.

Thanks everyone for raising your concerns so constructively, it's a
pleasure to improve the registry with your input.

Best regards,

Nico

---

From: Ted Hardie <[email-masked]>
Date: Tue, 8 Dec 2020 15:07:19 -0800

Hi Nico,

While it is nice of you to note the efforts folks have made to point out
the problems, you still seem to miss their major point.  Boiled down, a
registry is an authoritative list of one kind of information.  Because of
how they are created, ULAs do not admit of such an authoritative list.
Telling people you have a registry of ULAs is very dangerous, because it
amounts to tempting them to believe that their choice being absent from the
list means it is available.  Only mischief can result.

If you want to describe your list as "ULAs seen in the wild" or "ULAs known
to have been in use, along with some dates", that would be less harmful.
But the real state of play is that someone creating a ULA cannot know it is
not in use elsewhere and therefore must maintain the administrative
boundary the system contemplates.   Please don't encourage them to believe
otherwise.

best regards,

Ted Hardie

---

From: Nico Schottelius <[email-masked]>
Date: Wed, 09 Dec 2020 11:42:44 +0100

Hey Ted,

Ted Hardie <[email-masked]> 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.

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.

---

From: Fernando Gont <[email-masked]>
Date: Wed, 9 Dec 2020 09:47:10 -0300

On 9/12/20 07:42, Nico Schottelius wrote:
[...]
> IETF/IANA/any-of-the-five-RIRs/$other_org wants to take over.

FWIW, I know of at least some people that have not only generated 
non-randomized ULA prefixes, but that have also generated them from 
fc00::/8 rather than fd00::/8.  So there could still be conflict with 
the "centralized" ULAs.

-- Me (culprit ;-) ), just providing a data-point :-)

Thanks,

---

From: Philip Homburg <[email-masked]>
Date: Wed, 09 Dec 2020 13:51:06 +0100

>fc00::/8 prefix that has been discussed before as centrally managed.

Deciding on how to set up a registry is more something for the RIR
communities.

---

From: Nick Hilliard <[email-masked]>
Date: Wed, 9 Dec 2020 13:48:46 +0000

Nico,

To paraphrase what Ted said: "This is fundamentally harmful.  Please 
don't do it."

Nick

---

From: Ted Hardie <[email-masked]>
Date: Wed, 9 Dec 2020 08:17:52 -0800

Hi Nico,

The argument to have a central registry assigned has been made before (
https://www.ietf.org/archive/id/draft-ietf-ipv6-ula-central-02.txt for
example).  It has not found consensus, for reasons which mailing list
searches would be more informative than I can be.

If the community does someday decide to take that route, an effort to
determine who should run the service will be needed, because the query
interface, database integrity, and data management practices will need to
be well sorted.   (The problem is, after all, approximately as complex as
running an RIR).  I am not sure, once those have been sorted, that it is
practical for the service to be free; "free" would mean "subsidized by
someone", basically, and that has a variety of potential issues that would
also need to be considered.

regards,

Ted Hardie

---

From: David Farmer <[email-masked]>
Date: Wed, 9 Dec 2020 11:20:37 -0600

First, please don't do this. As has been said, it is unnecessary and will,
unfortunately, lead some people to make erroneous conclusions. You are
trying to coordinate something that was intended to be uncoordinated, and
therefore you are trying to make ULA into something it wasn't intended to
be.

If you insist on doing this, please don't call it a Registry; that will
imply it is something akin to the RIRs and that will lead people to make
the erroneous conclusions I referred to. Furthermore, calling it a
Registry raises the questions like; Is it mandatory to register your ULA
prefix? Does the registry represent all ULA prefixes?

Possible words to use for this; Diary, Catalog, Journal, Ledger, Log, just
don't call it a Registry. Furthermore, clearly, statie use is optional and
by definition it is incomplete,

Thanks

-- 
===============================================
David Farmer               Email:[email-masked]
Networking & Telecommunication Services
Office of Information Technology
University of Minnesota
2218 University Ave SE        Phone: 612-626-0815
Minneapolis, MN 55414-3029   Cell: 612-812-9952
===============================================

---

From: Mark Smith <[email-masked]>
Date: Thu, 10 Dec 2020 05:23:21 +1100

> prefix? Does the registry represent all ULA prefixes?

It cannot.

Per RFC 7084, SOHO/residential CPE are to automatically generate ULA-Ls for
local use by default for internal use, regardless of if global IPv6
connectivity isn't available.

So unless CPE were updated to register their ULA-Ls with this service, it
will never record all ULA-Ls, and actually will only be a record of a tiny
number of them.

I think ANIMA networks do the same sort of thing, so it will be missing
those ULA-Ls too.

Regards,
Mark.

---

From: Brian E Carpenter <[email-masked]>
Date: Thu, 10 Dec 2020 07:50:42 +1300

> Deciding on how to set up a registry is more something for the RIR

That's only true for address space that IANA has released to the RIRs.
That is not the case for fc00::/7, which remains under IETF control.

    Brian

---

From: Philip Homburg <[email-masked]>
Date: Wed, 09 Dec 2020 21:31:30 +0100

> That's only true for address space that IANA has released to the
> RIRs.  That is not the case for fc00::/7, which remains under IETF
> control.

Yes, but it would be weird for the IETF to decide on an address registry
without involving the RIRs.

Of course, the current situation where there is no registry from ULA is
also perfectly fine.

---

From: "Manfredi (US), Albert E" <[email-masked]>
Date: Wed, 9 Dec 2020 21:33:21 +0000

-----Original Message-----
From: ipv6 <[email-masked]> On Behalf Of Brian E Carpenter

Yes, but in complete fairness, in principle, this could happen, and would be in compliance with RFC 4193:

----------------
3.1.  Format

   The Local IPv6 addresses are created using a pseudo-randomly
   allocated global ID.  They have the following format:

      | 7 bits |1|  40 bits   |  16 bits  |          64 bits           |
      +--------+-+------------+-----------+----------------------------+
      | Prefix |L| Global ID  | Subnet ID |        Interface ID        |
      +--------+-+------------+-----------+----------------------------+

   Where:

      Prefix            FC00::/7 prefix to identify Local IPv6 unicast
                        addresses.

      L                 Set to 1 if the prefix is locally assigned.
                        Set to 0 may be defined in the future.  See
                        Section 3.2 for additional information.
------------------

What most people, myself included, have been talking about is ULAs in which the L bit is set to 1. Which is, fd00::/8. Aside from Fernando's admission of having set the L bit to 0 (tsk tsk), Nico and Ungleich are talking about this "future use" of not-locally-assigned ULAs, fc00::/8. Presumably, not-locally-assigned would mean, globally assigned?

Are we saying that RFC 4193 needs an update, and that the meaning of the L bit has changed?

Bert

---

From: "Templin (US), Fred L" <[email-masked]>
Date: Wed, 9 Dec 2020 22:21:19 +0000

Bert, fd00::/8 followed by a 40-bit (random) Global ID followed by a 16-bit Subnet ID
followed by a 64-bit Interface ID is plenty good for what I need; I don't see any need
to change RFC4193 at least to satisfy my use case.

Thanks - Fred

> From: ipv6 [mailto:[email-masked]] On Behalf Of Manfredi (US), Albert E
> Sent: Wednesday, December 09, 2020 1:33 PM
> To: Brian E Carpenter <[email-masked]>; [email-masked]
> Subject: RE: [EXTERNAL] Re: Happy St Nicholas Day: Re-Launching the IPv6 ULA registry
> 
> What most people, myself included, have been talking about is ULAs in which the L bit is set to 1. Which is, fd00::/8. Aside from
> Fernando's admission of having set the L bit to 0 (tsk tsk), Nico and Ungleich are talking about this "future use" of not-locally-assigned
> ULAs, fc00::/8. Presumably, not-locally-assigned would mean, globally assigned?
>

---

From: "Manfredi (US), Albert E" <[email-masked]>
Date: Wed, 9 Dec 2020 22:27:24 +0000

-----Original Message-----
From: Templin (US), Fred L 

Fred,

Sure. Me too. Not the point. I'm just saying that what Nico is talking about is actually entirely legit, from the viewpoint of RFC 4193. The IETF could indeed go down this path, setting up a registry of some sort, or handing that task off to the IANA and the RIRs, as long as the work involves exclusively the fc00::/8 address space.

Part of the confusion exists because ULAs are defined in RFC 4193 as fc00::/7. In fact, there should be no major disconnect here.

Bert

---

From: Brian E Carpenter <[email-masked]>
Date: Thu, 10 Dec 2020 14:32:42 +1300

Bert,
> Yes, but in complete fairness, in principle, this could happen, and would be in compliance with RFC 4193:

Yes, the IETF could decide to standardise some form of ULA-C, and if so
could decide to ask IANA to create a registry, which would very likely
be done in consultation with the RIRs. But none of that has happened,
and I haven't seen a convincing case that the IETF, and the IANA, and
the RIRs, should spend resources on it.

Meanwhile, if there's a pro bono, voluntary and non-authoritative
ULA registry I have no problem with that, but it doesn't require
any IETF action, any more than the old sixxs registry did.

Regards
    Brian

---

From: Brian E Carpenter <[email-masked]>
Date: Thu, 10 Dec 2020 14:37:53 +1300

> 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

> .

---

From: Nico Schottelius <[email-masked]>
Date: Thu, 10 Dec 2020 10:03:55 +0100

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

---

From: Alexandre Petrescu <[email-masked]>
Date: Thu, 10 Dec 2020 11:09:03 +0100

>            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.

> And this brings me to the topic of this email:

For everyone and everything.

> 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.

> addresses is expensive, I have nothing but to ask:

For those who want it.

Alex

---

From: Ted Lemon <[email-masked]>
Date: Thu, 10 Dec 2020 08:12:22 -0500

Are these community networks not connected to the internet, then?

> On Dec 10, 2020, at 04:04, Nico Schottelius <[email-masked]> wrote:
> 
> 
> Good morning,
>

---

From: Michael Richardson <[email-masked]>
Date: Thu, 10 Dec 2020 08:49:45 -0500

> take, the more likely you can actually solve the original problems that

The question of what address can networks not-intended to be connected to the
public Default Free Zone can use is one that I have brought up repeatedly
over the last decade.

I have argued over and over again that we need an allocation mechanism that
is fee-free (or at least, no-recurring fee), and is free from significant
efforts for justification.

Unroutable /48s should be freely available in my opinion.
IPv6 space is large enough for this.
{I was also a fan of Tony Li's geo-ip (IPv6 assigned by Long/Latt)}

While it seems that ULA-R suits, it is lacking of two important things:
  1) accountability/audibility (whois)
  2) reverse DNS.

(Yes, Ted: Community Networks do not necessarily connect over the
ISP-controlled DFZ.  Usually, they are based upon a variety of radio mesh
technologies.  Where successful, they often span across many cities.  BABEL,
BATMAN, ... are common protocols)

(1) matters if there are ever issues of who did what at the legal level.
    Some countries have specific legislation that matters.

(2) reverse DNS is a nice courtesy, as it makes for much cleaner logs
    and IPv6 is remarkably easy to confuse two digits...

The discussions among the ARIN lists is distinctly IPv4-think.
If we allow people to have address space that is marked "unroutable" without
justification, that it will be used as a loophole by some really rich, but
nepharious ISPs/Enterprises who will then *DEMAND* their space get routed.
The "unroutable" mark will be meaningless.

I would like to bring the ULA-C concept back to life, but it seems like it's
such a hard push against people who would not be harmed, yet have very loud
opinions.

    > this is not an easy task to do.

...

    > For whom is IPv6?

I agree with all your points.

    > with automated alive checks

I assume you mean an email, not an ICMP Echo ping :-)

    > the Internet at some point in the future.

I agree.

--
]               Never tell me the odds!                 | ipv6 mesh networks [
]   Michael Richardson, Sandelman Software Works        |    IoT architect   [
]     [email-masked]  http://www.sandelman.ca/        |   ruby on rails    [

---

From: David Farmer <[email-masked]>
Date: Thu, 10 Dec 2020 07:50:02 -0600

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.

---

From: Brian E Carpenter <[email-masked]>
Date: Fri, 11 Dec 2020 08:04:34 +1300

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;
> 
> 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. 
> 
> On Thu, Dec 10, 2020 at 3:03 AM Nico Schottelius <[email-masked] <mailto:[email-masked]>> wrote:
> 
> 
>     Good morning,
> 
>     Brian E Carpenter <[email-masked] <mailto:[email-masked]>> writes:
> 
>     >> Ted Hardie <[email-masked] <mailto:[email-masked]>> writes:
>     >>> [...]
>     >> Modern, affordable, Swiss Virtual Machines. Visit www.datacenterlight.ch <http://www.datacenterlight.ch>
>     >>
>     >> [email-masked] <mailto:[email-masked]>
>     Modern, affordable, Swiss Virtual Machines. Visit www.datacenterlight.ch <http://www.datacenterlight.ch>
> 
>     [email-masked] <mailto:[email-masked]>
> David Farmer               Email:[email-masked] <mailto:[email-masked]>

---

From: Michael Richardson <[email-masked]>
Date: Thu, 10 Dec 2020 15:36:34 -0500

Brian E Carpenter <[email-masked]> 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

That's not correct.  That's very much capital-Internet bias.
It's IPv4 scarcity think.  IP is for all sorts of uses that might not involve the *I*nternet.

There may be no connection via the *DFZ*.
You might never be able to reach these networks from NZ.

That doesn't mean there is no connection.
It could be a hundred 100m 802.15.4 radios running on solar power.

    > solved by some such RIR policy approach as David describes. Has RIPE

Routeability has never been promises by RIRs.
Connectivity is and has always been by 1:1 contract.

What the RIRs promise are:
  1) uniqueness.
  2) whois and reverse DNS
  3) RPSL and RPKI [added this decade]

---

From: Nick Hilliard <[email-masked]>
Date: Thu, 10 Dec 2020 20:53:34 +0000

> solved by some such RIR policy approach as David describes. Has RIPE

provider independent addressing has been discussed to death at RIPE over 
the years, but most of the discussion has centered around publicly 
routeable address blocks: ULA has come up from time to time, but no-one 
ever really felt there was a need for a separate registry for it.

Unique addressing is only of interest in situations where you're 
interconnecting networks together.

What makes registered addresses relevant is the combination of 
interconnection + address permanence.  If you have no need for 
interconnection, then you can use private addressing or ULAs.  If you 
don't need permanence, then you can use your service provider's 
addresses.  It's only if you need both that public registration becomes 
an issue.

If you want registered addresses, they're cheap and readily available: a 
LIR is charged €50/y per block, where there's a demonstrated need for 
the holder to multihome (the LIR will usually mark this charge up).  So 
if there's already an option to register GUAs, what added advantage is 
there to maintain a ULA registry?  It would be less functional for no 
less cost or effort.

Nick

---

From: Mark Andrews <[email-masked]>
Date: Fri, 11 Dec 2020 10:47:18 +1100

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 <[email-masked]> wrote:
> 

-- 
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742              INTERNET: [email-masked]

---

From: David Farmer <[email-masked]>
Date: Thu, 10 Dec 2020 18:46:24 -0600

On Thu, Dec 10, 2020 at 1:04 PM Brian E Carpenter <
[email-masked]> wrote:

> solved by some such RIR policy approach as David describes.
>

Actually, it is not the prefix, the size of it, or even the routability of
it that cost money. It is the administrative and technical
coordination that makes it routable, secure, and the operation of services
like reverse DNS, RPKI, Whois, etc... that make a prefix usable that costs
money. Including convening the community of stakeholders to create and
maintain the necessary registry policies, through the consensus of the
various community stakeholders, and the staff necessary to implement
and administer the registry using those policies and operated the technical
services needed by the community.

Many of the services provided by the RIRs are useful even for users and
prefixes not in the DFZ. Could some of these services be provided
independently of the RIRs, sure, but you will still need to replicate much,
if not most, of what the RIRs do, which seems inefficient.

The thing that make ULA effectively free is the lack of any coordination
and any services, change the dial on either of those, and you will
effectively rebuild the RIRs to one extent or another.

Thanks

---

From: Brian E Carpenter <[email-masked]>
Date: Fri, 11 Dec 2020 14:06:39 +1300

> It's IPv4 scarcity think.  IP is for all sorts of uses that might not involve the *I*nternet.

Indeed, I was not thinking about address *scarcity* as an issue. I was
trying to figure out how a CB-radio like group in "Hamburg", using ULA
space, would connect to another similar group in "Berlin", using Nico's
examples. Unless they're willing to lease their own line (like we did
in the early days of the IPv4nternet), the only solution would be to
use an incumbent ISP, who certainly won't route ULAs without €€€.

> It could be a hundred 100m 802.15.4 radios running on solar power.

Right, that's an entirely different situation and I hope it
will be a frequent one. We have several /3s spare. Should we
dedicate a /3 to that class of usage, and figure out (with IANA
and the RIRs) how to make such prefixes available for admin
cost only, or even self-service free of charge along the lines
Nico suggested?

(Because I'm thinking that for the full power of such mesh
networking to be available, ULA-C would not be enough.)

   Brian

---

From: Fernando Gont <[email-masked]>
Date: Thu, 10 Dec 2020 22:55:53 -0300

Hi, Richard,

> public Default Free Zone can use is one that I have brought up repeatedly

Wel... that's ULA, isn't it?

>    1) accountability/audibility (whois)

But these requirements seem to be broken. If the space is to be 
unroutable, that really means non-global scope. As such, addresses are 
not globally meaningful, and hence it doesn't make much sense to 
register something that, at the end of the day, is not globally meaningful.

If you do what something that is globally unique, but that it's not 
routable, then you want GUAs, and some policy enforced somewhere such 
that packets are not routed.

Note:
Having a registry is something that can, potentially, require resources 
of difference sorts. And I guess in a capitalist world that means that 
somebody would need to pay for it?

Thanks,

---

From: Fernando Gont <[email-masked]>
Date: Thu, 10 Dec 2020 22:59:26 -0300

> organisation that "owns" the ULA prefix, *by the very definition of ULAs*.

It would seem to me that if ULAs were marked in the addressing 
architecture as "private address space", some of the confusion would go 
away.

At least, I don't seem to remember anybody trying to register e.g. the 
10.0.0.0/8 space usage.

Thanks,

---

From: Fernando Gont <[email-masked]>
Date: Thu, 10 Dec 2020 23:06:35 -0300

On 10/12/20 22:06, Brian E Carpenter wrote:
> examples.

I guess they could be a large "overlay" network.

> Unless they're willing to lease their own line (like we did

.... or tunneling.

> cost only, or even self-service free of charge along the lines

Just trying to understand myself:
Is the issue that the ULA space is deemed to be not large enough?

Or is the thing that they want GUAs that are free of the charges RIRs 
normally charge for them?

Thanks,

---

From: Nick Hilliard <[email-masked]>
Date: Fri, 11 Dec 2020 11:10:21 +0000

> I guess they could be a large "overlay" network.

in a minor sort of way there are quite a lot of these using various 
encapsulation mechanisms (openvpn, ipsec, gre, etc).  ULA works fine for 
this, but if you want publicly registered PI address space, that would 
obviously work even better.

Incidentally, the RIPE address policies deliberately do not specify 
whether the multihoming requirement is public or private, so 
interconnecting over one of these private networks should be sufficient 
justification, as long as you can provide some evidence.

Nick

---

From: Michael Richardson <[email-masked]>
Date: Sun, 13 Dec 2020 17:22:05 -0500

Brian E Carpenter <[email-masked]> wrote:
    > Right, that's an entirely different situation and I hope it will be a
    > frequent one. We have several /3s spare. Should we dedicate a /3 to
    > that class of usage, and figure out (with IANA and the RIRs) how to
    > make such prefixes available for admin cost only, or even self-service
    > free of charge along the lines Nico suggested?

    > (Because I'm thinking that for the full power of such mesh networking
    > to be available, ULA-C would not be enough.)

Gosh, that would really be a good problem to have, wouldn't it?
That's 2^40  /48s, right?
1,099,511,627,776, approximately 100 /48s per human.

I don't think we need to dedicate a /3 to this problem.
It would, as David Farmer said, be dumb to replicate the
RIPE/ARIN/etc. databases and whois systems, and the like just for this.
David points out that Community Network allocation (a /40) is available
for $250/year from ARIN.

That's still a bit painful and the definition is a bit unclear.

here is an industrial/IT case that I know of:
The backplane of an IXIA testing chassis uses IPv4, 11.0.0.0/8.
It could use ULA, but:
a) it sometimes leaks packets and confuses people, especially IT.
   (They need whois to diagnose what is happening.
   11.0.0.0/8 also confuses them.... WTF is DNIC doing inside our firewall?)
b) sometimes you want to link the chassis together across labs or even VPNs.

This is a case where a ULA-C allocation per-customer would make sense, if
it could be done for a non-recurring fee.

--
Michael Richardson <[email-masked]>   . o O ( IPv6 IøT consulting )
           Sandelman Software Works Inc, Ottawa and Worldwide

---

From: Michael Richardson <[email-masked]>
Date: Sun, 13 Dec 2020 17:24:32 -0500

Fernando Gont <[email-masked]> wrote:
    >>> There may be no connection via the *DFZ*.  You might never be able to
    >>> reach these networks from NZ.
    >>>
    >>> That doesn't mean there is no connection.  It could be a hundred 100m
    >>> 802.15.4 radios running on solar power.
    >>

    > Just trying to understand myself: Is the issue that the ULA space is
    > deemed to be not large enough?

No, it's that ULA space provides no diagnostics: no whois, no reverse DNS, no RPSL.

    > normally charge for them?

Globally routable space is exactly what is not wanted.
Having it go dead due to BCP38-like filtering is desirable.

It lets us do things with IPv6 which where painful, annoying or just gross
with IPv4 RFC1918.

---

From: Michael Richardson <[email-masked]>
Date: Sun, 13 Dec 2020 17:27:24 -0500

Fernando Gont <[email-masked]> wrote:
    >> The question of what address can networks not-intended to be connected
    >> to the public Default Free Zone can use is one that I have brought up
    >> repeatedly over the last decade.

    > Wel... that's ULA, isn't it?

Well, no.

    >> I have argued over and over again that we need an allocation mechanism
    >> that is fee-free (or at least, no-recurring fee), and is free from
    >> significant efforts for justification.
    >>
    >> Unroutable /48s should be freely available in my opinion.  IPv6 space
    >> is large enough for this.  {I was also a fan of Tony Li's geo-ip (IPv6
    >> assigned by Long/Latt)}
    >>
    >> While it seems that ULA-R suits, it is lacking of two important
    >> things: 1) accountability/audibility (whois) 2) reverse DNS.

    > unroutable, that really means non-global scope.

This is the *I*nternet problem.
You think that globally unique means routable on the DFZ.
But, that's because so many people think that IP implies Internet.

    > As such, addresses are

But, we want meaning, just not routing.

    > Note: Having a registry is something that can, potentially, require
    > resources of difference sorts. And I guess in a capitalist world that
    > means that somebody would need to pay for it?

A one-time fee would be annoying, but doable for many.
A recurring fee would be a problem.

---

From: Brian E Carpenter <[email-masked]>
Date: Mon, 14 Dec 2020 13:20:15 +1300

> it could be done for a non-recurring fee.

I see a challenge there. As sixxs and other examples have showed us, a
pro bono service will not live for ever. How can a ULA-C registry, even a
strictly non-profit one, live for ever if there is no annual fee?

Regards
   Brian

---

From: David Farmer <[email-masked]>
Date: Sun, 13 Dec 2020 21:13:53 -0600

> strictly non-profit one, live for ever if there is no annual fee?

Not to mention that an annual fee and termination for the lack of payment
is an extremely efficient mechanism for maintaining the accuracy of the
registry over long periods of time.  Without it or a similar periodic
mechanism for garbage collection, information in the registry will rot over
time and we will just rebuild the swamp.  Furthermore, making that
mechanism an annual fee nicely aligns with the need to fund the registry.

So, if there isn’t an annual fee, not only do you need a different funding
mechanism but a different garbage collection mechanism too. While not
impossible, this seems like a very tall order to me.

Thanks

Regards
> networking

---

From: Fred Baker <[email-masked]>
Date: Sun, 13 Dec 2020 19:57:38 -0800

What is your budget, personally, for IANA services? Yes, there needs to be money, but my understanding is as a permanent ULA registry would be nothing more than “a registry”, of which they operate hundreds.

Sent from my iPad

> On Dec 13, 2020, at 4:20 PM, Brian E Carpenter <[email-masked]> wrote:
>

---

From: Brian E Carpenter <[email-masked]>
Date: Mon, 14 Dec 2020 17:42:46 +1300

> What is your budget, personally, for IANA services? Yes, there needs to be money, but my understanding is as a permanent ULA registry would be nothing more than “a registry”, of which they operate…

Yes, if a suitably rich organization would agree to take this on as a permanent
& free service. That is something that would need a policy decision, not just
a technical decision, which is why I called it a challenge, not a problem.

   Brian

---

From: Brian E Carpenter <[email-masked]>
Date: Mon, 14 Dec 2020 17:46:20 +1300

On 14-Dec-20 16:13, David Farmer wrote:
> 
> 
> On Sun, Dec 13, 2020 at 18:20 Brian E Carpenter <[email-masked] <mailto:[email-masked]>> wrote:
> 
> Not to mention that an annual fee and termination for the lack of payment is an extremely efficient mechanism for maintaining the accuracy of the registry over long periods of time.  Without it or a similar periodic mechanism for garbage collection, information in the registry will rot over time and we will just rebuild the swamp.  

But does that matter? The only property requested is uniqueness. These prefixes would never be in the mythical DFZ anyway, unless I've greatly misunderstood the use case.

    Brian

> Furthermore, making that mechanism an annual fee nicely aligns with the need to fund the registry. 
> 
> So, if there isn’t an annual fee, not only do you need a different funding mechanism but a different garbage collection mechanism too. While not impossible, this seems like a very tall order to me. 
> 
> Thanks
> 
>     Regards
>        Brian
> 
>     > Brian E Carpenter <[email-masked] <mailto:[email-masked]>> wrote:
>     >     > Right, that's an entirely different situation and I hope it will be a
>     >     > frequent one. We have several /3s spare. Should we dedicate a /3 to
>     >     > that class of usage, and figure out (with IANA and the RIRs) how to
>     >     > make such prefixes available for admin cost only, or even self-service
>     >     > free of charge along the lines Nico suggested?
>     >
>     >     > (Because I'm thinking that for the full power of such mesh networking
>     >     > to be available, ULA-C would not be enough.)
>     >
>     > The backplane of an IXIA testing chassis uses IPv4, 11.0.0.0/8 <http://11.0.0.0/8>.
>     > It could use ULA, but:
>     >    11.0.0.0/8 <http://11.0.0.0/8> also confuses them.... WTF is DNIC doing inside our firewall?)
>     > Michael Richardson <[email-masked] <mailto:[email-masked]>>   . o O ( IPv6 IøT consulting )

---

From: David Farmer <[email-masked]>
Date: Sun, 13 Dec 2020 23:44:06 -0600

On Sun, Dec 13, 2020 at 22:46 Brian E Carpenter <[email-masked]>
wrote:

> > On Sun, Dec 13, 2020 at 18:20 Brian E Carpenter <
> [email-masked] <mailto:[email-masked]>> wrote:
> >
> > Not to mention that an annual fee and termination for the lack of
> payment is an extremely efficient mechanism for maintaining the accuracy of
> the registry over long periods of time.  Without it or a similar periodic
> time and we will just rebuild the swamp.
>
> But does that matter? The only property requested is uniqueness. These
> prefixes would never be in the mythical DFZ anyway, unless I've greatly
> misunderstood the use case.

For several reasons registry accuracy is still important;

1. Someone mention leakage to the DFZ, accurate operational contact
information allows for notice of this situation.

2. The registry itself needs operational contact information for services
like reverse DNS and RPKI. I thought services were requested in addition to
uniqueness.

3. While not intended to be part of the DFZ, that doesn’t mean there is no
intent to coordinate with other networks. The registry is an effective
mechanism for this coordination, inaccurate information hinders this
coordination.

4. A large number of unused entries will distort any evaluation of the
usefulness of ULA-C, and could raise operational costs especially over
time.  Even if this is funded by an external agency, they will want to know
their money is being spent effectively and know the impact they are having.

Furthermore, nothing lasts forever, someday we will have to evaluate the
effectiveness of this and decide if it should continue, even if that is 20
or 30 years from now. A lot of cruft can build up in that kind of
timeframe, if it is not managed well from the beginning.

Don’t discount what it will take to turn the dials off of zero for
coordination and services for ULA. Also, IANA doesn’t serve the general
public, don’t discount how this would change the nature of IANA and what it
would take to accomplish it.

Thanks

    Brian
> > So, if there isn’t an annual fee, not only do you need a different
> funding mechanism but a different garbage collection mechanism too. While
> not impossible, this seems like a very tall order to me.
> >
> > Thanks
> >
> >     Regards
> >        Brian
> >
> will be a
> >     > Michael Richardson <[email-masked] <mailto:
> [email-masked]>>   . o O ( IPv6 IøT consulting )

---

From: Philip Homburg <[email-masked]>
Date: Mon, 14 Dec 2020 12:00:53 +0100

>it could be done for a non-recurring fee.

It seems to me that in this case the manufacturer could absorb the cost.
I.e., give every device a /48 plus reverse DNS. Create and maintain RPKI
entries, etc. And either not announce the prefix, or do anounce and blackhole.

The vendor would pay yearly RIR fees, but I guess that for any kind of 
industrial equipment, even for one device, the RIR fees would be left
in the noise.

---

From: Nico Schottelius <[email-masked]>
Date: Mon, 14 Dec 2020 13:28:32 +0100

Hey Brian,

> strictly non-profit one, live for ever if there is no annual fee?

I think the obvious and most easy answer here is "sponsoring".

I believe there are enough parties interested in providing good IPv6
services and from my point of view probably the biggest cost item will
be technical support for users. Running the registry, even allowing
reverse DNS and whois entries to be made would be on the lower side of
expense.

Best regards,

Nico

---

From: Nico Schottelius <[email-masked]>
Date: Mon, 14 Dec 2020 13:38:37 +0100

Hey David,

> impossible, this seems like a very tall order to me.

I think there is one point that most of us agree on:

- There should be a regular check/cleanup/confirmation of use

One thing that we do not agree on is yet what type of confirmation that
is. A $250 annually fee might not sound much, unless you put into
context of a community that is fully volunteer driven and/or located in
an economny where $250 might actually represent a monthly salary.

I think maybe a call for sponsors (and ungleich would certainly be one
of them) could show who would be interested in this role.

Cheers,

Nico

---

From: Nico Schottelius <[email-masked]>
Date: Mon, 14 Dec 2020 14:23:05 +0100

> What is your budget, personally, for IANA services? Yes, there needs to be money, but my understanding is as a permanent ULA registry would be nothing more than “a registry”, of which they operate…

I think defining a possible "budget" with maybe "sponsoring" in the mind
is a good idea.

The ULA registry that we provide was created in 3 days of work, because
it could be based on the existing open source project ubookmark[0] that
we already use for https://ipv6.blog.

Creating a whois and reverse DNS service are probably something like 3+3
additional days of work. Support requests (if the registry was
authoritative) take around 5-15m, depending on the depth / amount of
questions. Assuming that you including hosting costs (less than 50
USD/month on our infra), we can try to get an estimate on the budget,
based on an hourly rate of 120$. Let's further assume that you'll need
to give support for every 64 prefixes that are allocated.

- 2*(3+3) (times two to avoid underestimate) = 12h inital work = 1440 USD
- 2*50 USD (times two for stuff that comes up)  = 100 USD/month
- 10m average/support request

Thus as a rough estimate of the costs of the registry wil be around:

     ~ 2'000 USD initial investment
     - 384 (64*6) prefixes: ~ 220 USD/month
     - 7680 (64*20) prefixes: ~7680 USD/month

With this model we could even ask sponsors to sponsor a certain amount
of prefixes (i.e. company x sponsors 384 prefixes for the registry).

I assume that the RIRs have already even more statistics to reason about
how much support is actually coming in and we could take that as a basis
to refine the model.

Best regards,

Nico

---

From: Nico Schottelius <[email-masked]>
Date: Mon, 14 Dec 2020 14:28:33 +0100

> a technical decision, which is why I called it a challenge, not a problem.

Out of curiosity: how are policy decisions taken and what is the process
for initiating one?

Nico

---

From: Nico Schottelius <[email-masked]>
Date: Mon, 14 Dec 2020 14:34:11 +0100

>> use an incumbent ISP, who certainly won't route ULAs without €€€.

This is actually seen in quite a lot of community networks: you use "the
Internet" as a backbone to connect other sites. But you still stay
inside your ULA network for the services.

To name a few networks I am aware of that use ULA and have their own
registries:

- DN42 (https://dn42.eu/home)
- Freifunk (https://freifunk.net/)
- Anonet (http://anonet.org/)

If either of these networks would join the others, there would be ULA
collisions today.

> normally charge for them?

The requirement is mainly uniqueness. Services like whois and rDNS are
very welcome from an operational point of view as well. Internet routing
is not required - for this we can use GUA.

Nico

---

From: Jens Link <[email-masked]>
Date: Mon, 14 Dec 2020 14:55:00 +0100

Nick Hilliard <[email-masked]> writes:

> LIR is charged €50/y per block,

And can charge a customer some fee for the administrative overhead. I've
seen something around 5.000€ in one project. Maybe that was just
guesswork by the customer or ISP don't want their customers to use PI
space.
 
> So if there's already an option to register GUAs, what added advantage
> is there to maintain a ULA registry?  It would be less functional for
> no less cost or effort.

Don't forget that many (security) people are strong believers in security
by NAT^W obscurity.

Jens
-- 
----------------------------------------------------------------------------
| Delbrueckstr. 41    | 12051 Berlin, Germany           | +49-151-18721264 |
| http://blog.quux.de | jabber: [email-masked]        | ---------------  | 
----------------------------------------------------------------------------

---

From: David Farmer <[email-masked]>
Date: Mon, 14 Dec 2020 08:15:49 -0600

On Mon, Dec 14, 2020 at 06:38 Nico Schottelius <[email-masked]>
wrote:

> funding

I don’t think $250 is the right number for this, it is the current minimum
number for ARIN region. Should it be less, yes it should be, at least for
community networks, in my opinion, but who qualifies and under what terms.

Community networks aren’t the only ones that want something like ULA-C, and
plenty of the others that want ULA-C can and should pay their freight.
Plenty of corporations want address space that is filtered by default in
the DFZ but they can associate and secure communication with their business
partners, and know for sure it is a particular business partner.

I’m not sure all users should get ULA-C for free because one class of user
needs it to be free and is probably justified to receive it for free.

Thanks

Cheers,

---

From: Philip Homburg <[email-masked]>
Date: Mon, 14 Dec 2020 15:31:04 +0100

> To name a few networks I am aware of that use ULA and have their
> own registries:
> 
> - DN42 (https://dn42.eu/home) - Freifunk (https://freifunk.net/)
> If either of these networks would join the others, there would be
> ULA collisions today.
> 
> The requirement is mainly uniqueness. Services like whois and rDNS
> are very welcome from an operational point of view as well. Internet
> routing is not required - for this we can use GUA.

Why not collect some funds and become an LIR in the RIPE region? 

Then you can have reverse DNS. And if you put it in an independent non-profit
it can also outlive the people who started it.

---

From: Nick Hilliard <[email-masked]>
Date: Mon, 14 Dec 2020 14:57:56 +0000

> guesswork by the customer or ISP don't want their customers to use PI

There are ~2000 sponsoring LIRs in the RIPE NCC service region, so if 
someone paid 100x over the odds for a PI block, that's not a smart move.

As far as I'm aware, the open market rate is around €150/y, -ish.

Nick

---

From: Brian E Carpenter <[email-masked]>
Date: Tue, 15 Dec 2020 09:07:17 +1300

> Out of curiosity: how are policy decisions taken and what is the process

IMHO that is a non-trivial question, compared to how technical decisions
are taken (which is basically defined by RFC2026). But for this case, if
we are talking about ULA space (which is what RFC2860 calls a "specialised
address block") the answer seems to be that the IESG can give instructions
to IANA. That is quite different from regular IP address space, where
policy is set by ICANN under RFC2860. However, unless ICANN itself was
willing to provide a free registry for ULA-C, I suppose the IETF/IESG
would have to find someone willing to do so and negotiate an agreement.

    Brian

---

From: Brian E Carpenter <[email-masked]>
Date: Tue, 15 Dec 2020 09:12:23 +1300

> If either of these networks would join the others, there would be ULA

Why? Have they been unusually unlucky in their use of random number
generators?

     Brian

---

From: Mark Andrews <[email-masked]>
Date: Tue, 15 Dec 2020 07:32:49 +1100

And the real advantage of ULA is that you have something to renumber into. If you are unlucky to have a collision both sides generate new ULA prefixes advertise them via RAs deprecating the old ones.

If you have been managing you network properly every host should re-register itself in the DNS. 

Hard coded addresses really shouldn’t be used. But any that have can be tracked dow by looking for traffic using the deprecated prefixes. 

Mark
-- 
Mark Andrews

> On 15 Dec 2020, at 07:12, Brian E Carpenter <[email-masked]> wrote:
>

---

From: David Farmer <[email-masked]>
Date: Mon, 14 Dec 2020 15:03:33 -0600

On Mon, Dec 14, 2020 at 14:07 Brian E Carpenter <[email-masked]>
wrote:

> >>> What is your budget, personally, for IANA services? Yes, there needs
> to be money, but my understanding is as a permanent ULA registry would be
> nothing more than “a registry”, of which they operate hundreds.
> >>

Let be clear registry services have never been performed for free, for a
long time they weren’t paid for by the users of the registry entries and
were paid for by the US Government. We have evolved away from that, for
good and bad, and finally cut the vestigial ties to the US Government not
that long ago. I think my preferred solution to this is, have the RIRs
operate the ULA-C registry, they already have the technical and customer
service staff necessary. Then provide heave discounts or sponsorships for
Community Networks provided by the RIRs themselves, ICANN, ISOC, or some
combination of those entities. Also, recognize it may not be legal for what
most of us think of as Community Networks to even operate in some
jurisdictions, probably even some of the jurisdictions that most need them.
This could make it challenging to find the proper definition for what a
Community Network really is and what makes it deserving of the discounts or
sponsorship that is proposed. I think figuring the funding for Community
Networks to get free or virtually free resources is a challenge worthy of
the collaboration of the I*organizations and I think they all should have a
role in making it happen.

Thanks

---

From: Michael Richardson <[email-masked]>
Date: Mon, 14 Dec 2020 16:41:40 -0500

> I don’t think $250 is the right number for this, it is the current
    > minimum number for ARIN region. Should it be less, yes it should be, at
    > least for community networks, in my opinion, but who qualifies and
    > under what terms.

    > Community networks aren’t the only ones that want something like ULA-C,
    > and plenty of the others that want ULA-C can and should pay their
    > freight.  Plenty of corporations want address space that is filtered by
    > default in the DFZ but they can associate and secure communication with
    > their business partners, and know for sure it is a particular business
    > partner.

Agreed.

    > I’m not sure all users should get ULA-C for free because one class of
    > user needs it to be free and is probably justified to receive it for
    > free.

It's not the dollar amount that matters in this case, but rather, the
bureaucracy required to raise the PO.

---

From: Brian E Carpenter <[email-masked]>
Date: Tue, 15 Dec 2020 11:55:16 +1300

> bureaucracy required to raise the PO.

It turns out that we have running code of a solution to that: the fee
waiver for on-line IETF meetings. I could imagine something like that
for a ULA-C registry. Commercial use: issue a PO. Non-commercial use:
request a waiver.

     Brian

---

From: Nico Schottelius <[email-masked]>
Date: Mon, 14 Dec 2020 23:59:50 +0100

> it can also outlive the people who started it.

You have a point. Maybe it's worth exploring this direction a bit
more.