Subject: Non routable IPv6 registry proposal

From: Phillip Hallam-Baker <[email-masked]>
Date: Wed, 20 Jan 2021 15:06:39 -0500

First off, before I start, can I please ask that nobody respond with 'that
is stupid, that is not how it works'. One of the reasons people avoid this
list is precisely the fact that they see proposals regularly shot down in
those terms. And especially so with proposals like this one which go
against positions some people hold which I consider 'ideological'. In
short, people who respond that something is wrong without taking the time
to explain or justify their position are disrespecting us all.

This idea comes from a discussion with Bob Frankston on Facebook, the idea
here is mine though, and not endorsed by anyone else. But it is my
experience that putting together a clear description of the problem is
usually the biggest obstacle in discovering a solution.

The proposal is to reserve a significant block of IPv6 space (e.g.
2002::/16) as non routable address space to be allocated in Class A/B/C
sized chunks on a permanent basis either through random assignment or by a
new registrar TBD for a negligible one-time fee ($0.10 or less). This would
provide significant operational benefits for large enterprises managing
complex networks.

The background to this proposal is as follows:

0) Nowhere does the 'end to end' principle demand that the source and
destination addresses on an IP packet remain constant.

1) NAT is here to stay. IPv6 does not eliminate the need for NAT except for
enterprises which 'own' their IPv6 address blocks.

I have IPv6 service from Verizon but I obviously can't use it on my
internal network because my IPv6 address changes every few months. This is
certain to be the case for virtually every residential Internet drop and
the vast majority of business customers.

The logical and widely adopted solution to this problem right now is to use
IPv4 internally within sites and to perform NAT at the network boundary.
Which works fine when you only have one site.

2) NAT multiplexing will become an increasing problem

Current NAT conflates two functions. The function of translating IP
addresses at the network boundary will continue to be motivated by
operational and security concerns that are not going to go away.

The function of multiplexing multiple hosts onto a single IPv4 Internet
address is never going to go away but only for the limited number of
Internet hosts that require that access. I have a very large number of IP
connected devices in the house but I really don't want the coffee pot
talking to the open Internet.

As people end up with thousands of devices inside their home, port
exhaustion at the NAT box and the ridiculous complexity of it all is going
to become a major headache. Sharing one IP address between 100 hosts works,
its not ideal but it works right up to the point where you decide that you
need fault tolerance and you are going to need two NAT boxes and the
mapping data has to be synchronized.

3) 10.x.x.x is not enough

Even today, there are very few enterprises that have 16 million active
hosts. But every enterprise of any size has multiple net 10 address spaces
and multiple conflicts between them.

Consider what happens when Alice's Bank buys Bob's bank. Even though Alice
and Bob diligently ensured that every machine in their separate networks
had a different IP address in their separate spaces, they both started
assigning subnets to branches starting with 10.0.0.x

Solution

The solution is to provide a non-routable space where address block
collisions are unlikely. Each enterprise that uses this space is assured
that the probability of collisions is small. This can also be used within
existing enterprises to regularlize mapping of the typical horrorshow of
hundreds of overlapping 10.x.x.x etc. spaces onto a different private range.

The only ways to avoid collisions are either to (1) randomly assign spaces
in a sufficiently large space or (2) have a registrar whose function is to
guarantee uniqueness.

The largest IPv6 space we could assign is a /16 giving us 2^112 addresses.
If we set the allocation chunk to 2^24 (cf net 10) we have 2^88 assignable
blocks. Which means that if these are assigned at random, there should be
less than a 50% probability of collisions until 2^44 assignments have been
claimed and are in use.

This is probably sufficient. But a registry model would make for more
efficient allocation of the space and allow the allocation to be bound to a
public key whose private part is held by the registrant.

The obvious model to use for this approach is an append only log (c.f.
Certificate Transparency, Blockchain) whose apex value is attested by the
registrar (no, proof of work is not acceptable).

The part I like about this model is that it provides quite a bit of
leverage when we look at questions of how to address DDoS attack and mobile
IP addresses. It allows us to effectively create the effect of a bump in
the stack without imposing a cost.

The Internet model is that routing happens in the network. But what if
that's not the only place we can route to advantage? This approach gives us
two separate IP address spaces. The public internet routing space and the
private space that gives a unique assignment to each device. It's a bit
like a MAC address but expressed as an IP address.

So this allows traffic patterns where as far as Alice's mobile and Bob's
desktop are concerned, a communication is established on the 2002://16 net
and is constant the entire time. But behind the scenes, those addresses are
being mapped to/from Internet routable addresses at the network boundary
and those mappings are changed dynamically as Alice moves about from her
home IP network, to her wireless provider, to her company provider. If she
is at home and a tree takes out her Fios (like happened to me), her mobile
provider simply kicks in without a pause.

[Yes, I know there are similar ideas. But having an assigned private
address space that is globally unique but not used for Internet routing
helps simplify those as well]

---

From: Joe Touch <[email-masked]>
Date: Wed, 20 Jan 2021 12:25:46 -0800

> On Jan 20, 2021, at 12:07 PM, Phillip Hallam-Baker <[email-masked]> wrote:
> 
> 0) Nowhere does the 'end to end' principle demand that the source and destination addresses on an IP packet remain constant

IP addresses is the only means for identifying an Internet endpoint per RFC 1122. While I agree that there may be utility of having proxied endpoints (e.g. NATs) with effectively internal addresses behind them, it doesn’t help the case to begin with this inaccurate assertion. 

I’d encourage just removing it and getting on with the rest of the issues. 

Joe

---

From: Nick Hilliard <[email-masked]>
Date: Wed, 20 Jan 2021 20:58:41 +0000

Phillip Hallam-Baker wrote on 20/01/2021 20:06:
> sized chunks on a permanent basis either through random assignment or by 
> a new registrar TBD for a negligible one-time fee ($0.10 or less).

this idea was the subject of a recent discussion on 6man, subject 
thread: "Re-Launching the IPv6 ULA registry".  The original email was here:

https://mailarchive.ietf.org/arch/msg/ipv6/fFpPHY55pwKlEopyyAZyZI8azg0/

There were several aspects which cropped up, but the core issues seem to 
be whether the end user needs both address permanence and the 
requirement for interconnection to third parties.  If you need both of 
these, then registered addresses are a good idea; if you don't need 
both, then ULA should work fine.

There are options out there for getting formally registered address 
space at modest cost.  It's not 10c once off, but it's not going to 
break the bank either.

The economics you're proposing may need a bit more consideration, 
especially given that registries need long term stability, both 
financial and from the point of view of governance.

Nick

---

From: "John Levine" <[email-masked]>
Date: 20 Jan 2021 16:10:46 -0500

>provide significant operational benefits for large enterprises managing

This sounds a lot like ULAs. You generate a 40 bit random number,
prefix it with FD and that's your own /48. If you have a decent random
number genarator the chances of your 40 bit number colliding with
anyone else's are insignificant.  See RFC 4193.

I gather the problem in practice is that rather than a 40 bit random
number, too many people use one that spells something cute or
memorable in hex.

R's,
John

PS: The ULAs on my network are in fde3:783e:127d::/48.

---

From: Brian E Carpenter <[email-masked]>
Date: Thu, 21 Jan 2021 10:32:26 +1300

> if you don't need 

More completely: if you don't need both, *or* if you are willing to risk the unlikely inconvenience of renumbering if your ULA network ever merges with, or directly interconnects with, another ULA network that by chance has the same pseudo-random prefix, then ULA should work fine. The birthday paradox part of this is discussed in section 3.2.3 of RFC 4193.

RFC 4193 also reserves, but does not specify, a range of such addresses (usually known as ULA-C) that could in theory be centrally registered, if people don't accept the birthday paradox risk. That was the topic of the recent discussion that Nick mentioned. So there is no need to assign anything new. The only issue is how to fund such a registry and guarantee it indefinitely.

As for NAT, it remains totally unnecessary for IPv6 (see RFC 4864). We do have a half-acceptable solution (i.e. it mitigates some of the damage done by NAT) as an *Experimental* RFC 6296.

Regards
   Brian Carpenter

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Wed, 20 Jan 2021 16:33:08 -0500

> both, then ULA should work fine.

Random addresses are almost certainly going to be fine.

Registering an address is low value, registering a binding of an address to
a public key is much more useful.

> financial and from the point of view of governance.

Governance is much less of a concern for numbers with no semantics. My
other proposal in this space, the Mesh callsign registry for names of the
form @alice etc. is a lot more complex. Obviously @microsoft has to go to
the place everyone expects and not just because Microsoft can afford the
lawyers. It is a security concern because there is an expectation that goes
to the 'right place'. I have spent 20 years on those issues at VRSN and
Comodo.

Governance in the numbers space comes down to denial of service attacks.
What happens if we have a US administration which tries to kick Iran off
the net by denying them the right to register numbers? Well right now what
would happen is they would just make up their own numbers and continue.
Start imposing PKI based verification of addresses and that type of attack
can become real.

It is very important to understand the impact of the technology on the
business model. Servicing DNS names is expensive and will always be
expensive because the registry is required to provide a resolution service
with low latency, 99.999% uptime, etc. etc. The RPKI is expensive because
it is based on PKIX and the assumption certificates expire every time the
earth circles the sun a given number of times.

The business model for my proposed registry is essentially the exact same
thing as that for the 'million dollar home page': Charge a small fee for a
one time registration, let other folk worry about providing hosting in
perpetuity.

I have done a lot of thinking on the callsigns and will be able to offer
them for $0.10 each for names of 9 characters or more. The surplus funds
going to a not-for profit to fund development of open source code and
specifications. Why do I expect there to be a significant surplus? Because
shorter names will attract an exponentially increasing premium. You can
be @nick_hillard for $0.10 or you can demonstrate your commitment to the
project by being the first to buy @hillard at $10 or you can be a really
good patron and pay $10,000 for @nick.

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Wed, 20 Jan 2021 16:58:20 -0500

On Wed, Jan 20, 2021 at 4:32 PM Brian E Carpenter <
[email-masked]> wrote:

> More completely: if you don't need both, *or* if you are willing to risk
> the unlikely inconvenience of renumbering if your ULA network ever merges
> with, or directly interconnects with, another ULA network that by chance
> has the same pseudo-random prefix, then ULA should work fine. The birthday
> paradox part of this is discussed in section 3.2.3 of RFC 4193.
>
> RFC 4193 also reserves, but does not specify, a range of such addresses
> (usually known as ULA-C) that could in theory be centrally registered, if
> people don't accept the birthday paradox risk. That was the topic of the
> recent discussion that Nick mentioned. So there is no need to assign
> anything new. The only issue is how to fund such a registry and guarantee
> it indefinitely.

Following the IPv6 practice, we wouldn't declare 'a registry'. We would
instead create a meta-registry and allocate a unique address range to each
provider that meets some threshold of apparent competence.

So lets say I decide to start up a registry. I write up an RFC describing
the answers to the issues you raise and I get FC00::0000/32 to allocate on
an experimental basis. Worst that can happen is I screw up and lose track
of who was allocated what. I can now issue 4 billion /64s before I have to
come and ask for more space. And there is still room for 32 million other
registries like mine doing the same.

As for the business model, I was thinking I would bundle this service with
the callsign service I am already working on because it provides another
little part of the puzzle to provide end users with autonomy. So for $0.10
someone can get a unique callsign of 9 characters or more plus a unique /64
in IPv6.

Why only a /64? Thats because I expect people who need more IP address
space to also want more callsign space. If I have a property at 64 Zoo
Lane, I register @64_zoo_lane and get a chunk of IPv6 space for that
property to use internally as permanent allocation to the devices at that
location. Its big enough to map a MAC-48 or EUI-64 address inside on a 1:1
basis.

When the property is sold, the callsign and ULA IP space move with the
property.

The only time a registration would ever be updated in my model is to bind
it to a different public key. And that transition would be signed by the
previous authorized key. If the key is lost, the new owner of the building
just burns the IP address space and allocate a new chunk and tell the local
routers to make the necessary mappings.

---

From: Nick Hilliard <[email-masked]>
Date: Wed, 20 Jan 2021 23:25:37 +0000

Phillip Hallam-Baker wrote on 20/01/2021 21:58:
> So lets say I decide to start up a registry. I write up an RFC 
> describing the answers to the issues you raise and I get FC00::0000/32 
> to allocate on an experimental basis. Worst that can happen is I screw 
> up and lose track of who was allocated what. I can now issue 4 billion 
> /64s before I have to come and ask for more space.
whoa, wait up there!  Either you have a registry or you don't.  If your 
model is ok with long term inaccuracy due to data loss, data rot, or 
cruft accumulation, then the question needs to be asked whether you 
ought to be running a registry to start with.  The whole point of a 
registry is that it provides some level of comfort about resource 
registration accuracy.

Nick

---

From: Fernando Gont <[email-masked]>
Date: Wed, 20 Jan 2021 20:25:52 -0300

Philip,

On 20/1/21 17:06, Phillip Hallam-Baker wrote:
[...]
> destination addresses on an IP packet remain constant.

The end-to-end principle are guideliness, rather than specific mandates.

IPv6 is (was?) supposed o be end-to-end, and address translation (which 
you seem to be implying) goes against simplicity and robustness.

> 1) NAT is here to stay. IPv6 does not eliminate the need for NAT except 
> for enterprises which 'own' their IPv6 address blocks.

I won't challenge this.

> internal network because my IPv6 address changes every few months. This 
> is certain to be the case for virtually every residential Internet drop 
> and the vast majority of business customers.

Depends on what you're implying. You could certainly use them, and the 
network would eventually gracefully renumber..  -- whether this would be 
practical, is a different question.

> Internet hosts that require that access. 

These two are essentially variants of the same thing.

> I have a very large number of 
> IP connected devices in the house but I really don't want the coffee pot 

You do not need a NAT for that: you can deploy a firewall.

> exhaustion at the NAT box and the ridiculous complexity of it all is 
> going to become a major headache. Sharing one IP address between 100 
> hosts works, its not ideal but it works right up to the point where you 
> decide that you need fault tolerance and you are going to need two NAT 
> boxes and the mapping data has to be synchronized.

You don't need this for IPv6. i.e., even if you translated (NPT) , you 
don't need to multiplex all hosts into the same address -- this is/was 
done in IPv4 because IPv4 addresses are scarce. BUt that's not the case 
with IPv6.

> collisions are unlikely. 

Welcome to ULAs: RFC4193

> The only ways to avoid collisions are either to (1) randomly assign 
> spaces in a sufficiently large space or (2) have a registrar whose 
> function is to guarantee uniqueness.

FWIW, ULAs do (1).

[...]
> efficient allocation of the space and allow the allocation to be bound 
> to a public key whose private part is held by the registrant.

That comes at the price of running the registry. And I'm curios: if 
you're going to pay, why not get a routable prefix, and simply not 
announce it via BGP?

[...]
> desktop are concerned, a communication is established on the 2002://16 
> net and is constant the entire time. But behind the scenes, those 
> addresses are being mapped to/from Internet routable addresses at the 
> network boundary and those mappings are changed dynamically as Alice 
> moves about from her home IP network, to her wireless provider, to her 
> company provider. If she is at home and a tree takes out her Fios (like 
> happened to me), her mobile provider simply kicks in without a pause.

You don't need a registry for this. You can achive the same thing with 
ULS  + NPT.

Or even worse, we should fix IPv6's support for multi-prefix/multi-link 
networks, which is known to be broken.

> helps simplify those as well]

Regarding globally-uniqueness, you may want to check the ULA spec 
(RFC4193) and this: 
https://tools.ietf.org/html/draft-gont-6man-ipv6-ula-scop

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

---

From: Fernando Gont <[email-masked]>
Date: Wed, 20 Jan 2021 20:27:53 -0300

> IP addresses is the only means for identifying an Internet endpoint per RFC 1122. While I agree that there may be utility of having proxied endpoints (e.g. NATs) with effectively internal addresses…

I'd have agreed with you. BUt since 
draft-ietf-spring-srv6-network-programming has been approved by the 
IESG, you probably cannot make such assertion anymore.

Thanks,

---

From: Fernando Gont <[email-masked]>
Date: Wed, 20 Jan 2021 20:31:24 -0300

> anyone else's are insignificant.  See RFC 4193.

No. Collissions are actually almost guaranteed (birthday paradox).

What the spec says is that *if you grab a handful of ULA networks* they 
(not the entire ULA universe) are quite unlikely to collide.

> number, too many people use one that spells something cute or

That's correct -- non-compliant with RFC4193, but still correct.

Thanks,

---

From: "John R Levine" <[email-masked]>
Date: 20 Jan 2021 19:16:30 -0500

> No. Collissions are actually almost guaranteed (birthday paradox).

When I do the birthday paradox calculation, I find that the chances that 
100,000 random numbers each 40 bits long are all different is about 95%. 
I'll take those odds.

Regards,
John Levine, [email-masked], Taughannock Networks, Trumansburg NY
Please consider the environment before reading this e-mail. https://jl.ly

---

From: Christopher Morrow <[email-masked]>
Date: Wed, 20 Jan 2021 20:38:52 -0500

(I'm not a ULA fan, it's going to cause problems.. but)

> 100,000 random numbers each 40 bits long are all different is about 95%.

Warren made this website/application/etc:
  http://mac-collision-probability.appspot.com/calculate

which was used for privacy address problems/discussions, but... if you
make it 40 bits and 100,000 stations
apparently you'll get a collision 1 out of 220 times. I think that
means that ULA network selections COULD overlap at about the same
rate.

There are ~1.4m small businesses in the US, if they all chose ULA
that's more than a few collisions.
Collisions matter because when 2 networks that collide come together
it's messy :( to untangle and decide whom is going to do what :(
it's also not always obvious that it's happening :( until something crashes :(

---

From: George Michaelson <[email-masked]>
Date: Thu, 21 Jan 2021 11:41:32 +1000

MAC addresses are on a shared medium.

ULA are disjoint. The risk is that 1 in 220 networks in a field of
100,000 things pick the same value of NON ROUTABLE

and then.. decide to join. Now, tell me the risk of 1 in 220 things,
both picking the same ULA, *AND* seeking to join their private
networks.

-G

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Wed, 20 Jan 2021 20:57:20 -0500

> registry is that it provides some level of comfort about resource

I said worst case.

People make waaaay too much out of the risks of running registries. There
are an infinite number of petty bureaucratic objections that can be raised.
That is how PEM was killed. Oh whatabout this, whatabout that. oh nobody
knows, oh! oh!

These are private addresses. The only thing that the registry is
undertaking that matters at IETF level is that there won't be duplicates.
And every registry customer is going to be able to verify that their
assignment is unique at the time it is assigned just by checking the
registry. So I have it all covered.

The whole log is going to be public. In fact that is a big part of my plan
to offload cost.

We really need to get over the worry about allowing people to start stuff.
And especially when it comes to registries. If people have issues they can
state, fine. But we saw what happened when folk decided to get precious
about the SRV prefix registry - people just gave up waiting and made them
up. That is what I did for SAML and will do again if necessary.

People need to understand that 'I am starting a project, what code point
can I use' is a request for a code point. It is not a request for
permission to start the project. The Internet is all about permissionless
innovation.

---

From: Michael Richardson <[email-masked]>
Date: Wed, 20 Jan 2021 21:08:39 -0500

There is a different argument, other than collision rate, for having a
registry.  Whois and reverse DNS.

I have debugged numerous networks where there are leaks of RFC1918 addresses
from other places.  Given a flat multi-city L2 "WAN", it's very difficult to
debug unless you have homogenous equipent with all of that vendor's
management stuff.  Yes, SNMP ought to work, and sometimes it does.

The first time that I was called to debug this, it was because we had just
put one institution on the internet (I'm talking 1994 here).  The default
route injected into the WAN attracted all sorts of packets with wrong source
addresses.  But, it was early, and RFC1918^WRFC1597 wasn't as ubiquitous,
and whois identified the other class Bs that we were seeing.
{how did this happen back in 1994?  common subcontractor ran all those networks on the
same set of T1s, charging each customer for the full fare.   Yes, there was
a lot of embarassed people}

While ULAs and privacy enhanced addresses have important uses for individual
privacy, when it comes to non-moving business/enterprise infrastructure,
audit and accountability is much more important, and ULA-R does not satisfy
that.

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

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Wed, 20 Jan 2021 21:10:33 -0500

> practical, is a different question.

Nah, thats not going to work.

People complain about NAT being complex. But it is ubiquitous and it just
works because it is something used every day.

Any code path that runs only once every three years... its just not going
to work reliably enough not to be a PITA.

> done in IPv4 because IPv4 addresses are scarce. BUt that's not the case

Precisely the point I was making when identifying the precise features of
IPv6 NAT we are going to need on an ongoing basis.

> you're going to pay, why not get a routable prefix, and simply not

Ah that is a very important point: Because these are not going to be
aggregated addresses. The idea here is that people use these address blocks
on a fine grain basis. So a Fios drop with 256 customers might have over a
thousand of these private address spaces being used inside it but only one
AS number for that whole set.

The point of using non routable addresses is precisely so we can break the
rules that are required to make routing work. We are not going to have
routing tables with 2^50 AS numbers in them. That wouldn't work.

---

From: Brian E Carpenter <[email-masked]>
Date: Thu, 21 Jan 2021 15:54:12 +1300

> 100,000 things pick the same value of NON ROUTABLE

The probability of a collision among 100,000 ULAs is 4.54*10^-03, according
to RFC4193. So most likely there is no collision at all, but let's
continue...
 
> both picking the same ULA, *AND* seeking to join their private

It's unknowable, because there is no calculus for how likely network A is
to interconnect with network Q, where A and Q are arbitrary choices.
What is knowable, and is worked out for you in RFC4193, is that the
probability of A and Q both having picked the same pseudo-random 40 bits
is 1.81*10^-12.

Of course, if we assume that 10 billion sites around the world each pick
a pseudo-random 40 bit number, the probability that collisions exist is
effectively 1. But that doesn't matter; for any two sites that happen to
interconnect, the probability remains at 1.81*10^-12. Even for a set of
10 sites that happen to interconnect, the probability of collision is
only 4.54*10^-11.

Somewhere above 1000 sites, the probability of a collision gets as high
as one per million. So if you run a very large corporate network, assign a
separate ULA /48 prefix to each site, and merge two sites, you are looking
at a 1 per million chance of a problem, unless you make a trivial check
before doing the merge. (However, why a corporate network would do that
is a mystery. They could simply use one ULA /48 for the whole network.)

I have never lost any sleep over this issue, which has been well understood
and documented for 15 years.

    Brian

---

From: Brian E Carpenter <[email-masked]>
Date: Thu, 21 Jan 2021 15:57:17 +1300

Michael,

> audit and accountability is much more important, and ULA-R does not satisfy

How is that problem solved today for RFC 1918 addresses?

Regards
   Brian

---

From: "John R Levine" <[email-masked]>
Date: 20 Jan 2021 21:57:34 -0500

> both picking the same ULA, *AND* seeking to join their private

That's much simpler -- that's the probability that two random 40 bit 
numbers are the same, which is one in 2^40.

For any plausible applications, the chances of two randomly chosen ULAs 
colliding in a way that matters, i.e., being routed on the same network, 
really is remote.

Regards,

---

From: Nick Hilliard <[email-masked]>
Date: Thu, 21 Jan 2021 10:14:16 +0000

Phillip Hallam-Baker wrote on 21/01/2021 01:57:
> People make waaaay too much out of the risks of running registries

Yep they certainly do, until there's a registry failure, or even the 
threat of one. At that point, people often execute dramatic u-turns in 
their opinion, depending on how important the registry's function was to 
them.

Nick

---

From: Masataka Ohta <[email-masked]>
Date: Thu, 21 Jan 2021 20:57:59 +0900

Phillip Hallam-Baker wrote:

> is stupid, that is not how it works'.

Not stupid.

Your point that NAT is fine is not stupid but it means IPv4 with
NAT is fine obsoleting IPv6, which, though, makes your proposal
insisting on IPv6 meaningless.

> destination addresses on an IP packet remain constant.

Correct. As long as both ends can restore the original IP addresses,
modifying them between the ends is fine.

See:

	https://tools.ietf.org/html/draft-ohta-e2e-nat-00

for details.

> to become a major headache.

Feel free to pay more to your ISP if you want to enjoy using more ports
of an address, just as when you want to enjoy more addresses.

> 3) 10.x.x.x is not enough

For private use, I don't think so.

> hundreds of overlapping 10.x.x.x etc. spaces onto a different private range.

You are saying 24bit address range of 10.x.x.x is enough for all the
large organizations have unique addresses.

Then, x.x.x.x should be enough for all the people and organizations
have unique addresses, which is obviously wrong.

						Masataka Ohta

---

From: Michael Richardson <[email-masked]>
Date: Thu, 21 Jan 2021 07:20:31 -0500

Brian E Carpenter <[email-masked]> wrote:
    >> While ULAs and privacy enhanced addresses have important uses for
    >> individual privacy, when it comes to non-moving business/enterprise
    >> infrastructure, audit and accountability is much more important, and
    >> ULA-R does not satisfy that.

    > How is that problem solved today for RFC 1918 addresses?

It's not.

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Thu, 21 Jan 2021 11:00:15 -0500

> their opinion, depending on how important the registry's function was to

Has there ever been a proper consideration of the abstract security
concerns for a registry?

I rather suspect the closest we get is Warwick Ford et. al. writing the
Certificate Policy Statement RFC in PKIX which was largely based on Michael
Baum's practice statement for VRSN class 3. That is rather heavily PKI
focused and it is all based on a Kohnfelder PKI architecture and 1980s PKI
technology.

Perhaps we should ask how registries can go wrong. Or maybe we should ask
the IAB to consider this.I can think of a few problems:

Integrity
* Duplicate registrations
* Unauthorized registration modification
* Unpublished registrations
* Inappropriate semantic mapping

Availability
* Rent seeking
* Denial of service
* Coercion by government

What gets wrapped round the axle in DNS space is of course the semantic
mapping issues. DNS names have an obvious interpretation. There is the
natural assumption microsoft.com arrives at Microsoft Inc. Failure to
achieve that mapping correctly is actually a serious safety and security
issue as they provide the most popular desktop operating system. That is a
very complex issue and I am not in the least impressed by the way ICANN has
approached it.

ULAs are free of semantic binding, or at least the ones I propose to issue
will be.

OK so there is one 'risk' that perhaps should be mentioned openly because
it is likely the one of most concern to people, 'what are the unexpected
uses of these addresses' or 'what else is PHB planning he is not telling us
about'.

Well I really wished I knew myself because I can see several possibilities
but they are still a bit on the fuzzy side. I think I am going to have to
build a prototype before I can start to get a handle on those. But it is my
experience that getting the addressing right is the key to solving any
network protocol issue. URIs made the Web.

The registry concern that is rarely considered in IETF is what happens if
there is no registry? There are two possibilities:

1) Innovation is put on hold until the registry is created.
2) People just create their own code points

The second has occurred on countless occasions and sometimes between really
big companies. Every hard drive has a unique identifier which is actually
in the MAC address space. After asking nicely and getting the run-around,
the drive makers just allocated themselves 1/16th of the total MAC address
space.

---

From: Joseph Touch <[email-masked]>
Date: Thu, 21 Jan 2021 09:17:25 -0800

> On Jan 20, 2021, at 3:27 PM, Fernando Gont <[email-masked]> wrote:
> 
> I'd have agreed with you. BUt since draft-ietf-spring-srv6-network-programming has been approved by the IESG, you probably cannot make such assertion anymore.

One draft that doesn’t update or obsolete numerous others does not undermine 40 yrs of E2E.

Esp. when (AFAICT) that doc series never mentions how transport protocols are supposed to deal with indeterminate endpoint addresses in their pseudo headers or the impact to security protocols at the transport (not transport content) layer.

Joe

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Thu, 21 Jan 2021 13:57:24 -0500

This post and various others have helped me clarify the proposal a bit. I
think there is (potentially) something very useful here that makes it
easier to solve a lot of 'niggling administration' type issues.

The payoff for IETF is that I think the combination provides the right
level of incentive to drive IPv6 adoption. And that is one of the major
reasons I want to incorporate it into my Mesh callsigns registry. As folk
know, I have a really low tolerance for administration/configuration cruft
and especially so when it is my wife asking me to do the IT support her
work IT support should be doing for her.

OK so what do I mean by the right level of incentive? Well, simply saying
IPv4 addresses will run out doesn't provide me with a personal incentive to
go to IPv6 as my ISP will simply pay whatever it takes to get me a one and
the bulk of their customers won't notice if they are shoved behind a
carrier grade NAT. Nor does making use of IPv6 a requirement to use some
new application help because getting critical mass for an application is
also a hard problem and I am not going to handicap myself by making IPv6 a
requirement until deployment has reached a minimum of 98%.

A ULA->Public key registry provides exactly the right degree of incentive.
It allows us to take an area that is currently flaky as heck and make it
'just work'. That area is VPN access.

The original idea of IPSEC was that we were going to encrypt the whole net.
And that didn't really happen because there is no PKI for IP addresses (and
no, the RPKI doesn't really count in that regard). And PKIX is a really
really bad match for that problem because certs expire.

Nor is it really possible to solve the problem of VPN access in IPv4 space
because you inevitably end up with collisions. My wife's machine was
10.0.1.42 on our home net. It was trying to reach the file server which is
10.0.1.42 on the work net. And that doesn't work for the combination of VPN
client/server software that was in use. And why would we expect that? Nor
is this really a corner case, its actually going to be a situation that
occurs to some users with approaching 100% certainty.

Map this all out onto disjoint ULA IPv6 addresses and we can guarantee that
the addresses are unique at each end. That is our first win.

Our second win comes when we have a registry that maps public keys to the
ULA address ranges like the one I am planning to add to my existing
callsign registry. This is based on a DARE sequence.

Mathematical Mesh 3.0 Part III : Data At Rest Encryption (DARE) (ietf.org)
<https://tools.ietf.org/id/draft-hallambaker-mesh-dare-11.html>

So to receive an allocation Alice:

1) Generates a new key pair {public, private}
2) Submits the request for an allocation.
3) Receives notification of the allocated address range
4) Waits for the sequence apex to be signed and sufficiently notarized.

For purposes of exposition, the registry consists of a Haber-Stornetta
One-way Sequence:

S0 = { A, FC00:0001:0000:0000::/62 , 0}
S1 = { B, FC00:0001:0000:0004::/62 , SHA2(S0)}
S2 = { C, FC00:0001:0000:0008::/62 , SHA2(S1)}
S3 = { D, FC00:0001:0000:000C::/62 , SHA2(S2)}
S4 = { E, FC00:0001:0000:0010::/62 , SHA2(S3)}
S5 = SHA2(S4) + Na(t) + Nb(t)
S6 = Sign (S5)

Where Na(t), Nb(t) are the notary tokens issued by notaries A, B at time t.

[Yes, the actual implementation will use a Merkle Tree for efficiency]
[Yes, bumped the allocation up to a /62 as per Michael's suggestion]

This approach is not completely foolproof. But the idea here is that the
notaries are independent parties doing something of the sort (e.g. CT logs)
with a reciprocal relationship, I include the output of your notary chain
and you include mine. The result is more robust than blockchain without the
criminality, proof of work or environmental harm.

So Alice can verify that her allocation is unique as soon as she can get
confirmation of the ULA registry output value from one of the other
notaries she trusts.

These logs are not going to be all that big. Its 1KB per entry at most. So
10K entries per day is only 10MB appended to the end of the chain. That's
less than the size of a single photograph with the camera I use these days.
Even at Internet scale of 10 billion entries we are talking about 10TB of
data. That is just not a lot of data these days.

All an IPSEC gateway would need to verify a public key chain to this
registry would be the mapping of IP address range to hash of public key.
Which is ~50 bytes. So 0.5 TB for a complete dump. These are practical
values we can use in current tech.

Worst cases are 1) that I give up and stop allocating new addresses, 2) I
mess up and allocate space I am not allowed to or double allocate. Both of
these are externally visible. The choice of incremental allocation is
deliberate as it makes it easier to verify that my allocations are within
policy (and yes, I would have to modify things a little bit so I can
allocate larger chunks without making spaces, but details)

Alice is only going to start using her block after I publish it. So I
really have little scope to attack her.

I can make a report once a year to state where I am at. But anyone starting
a similar registry is going to get FC00:0002::/96 to allocate.

We have burned far more address space with far less to show for it. Either
this works in which case my non profit gets a revenue stream that can
support work for the whole community or it doesn't and we maybe learn
something from the experience.

On Thu, Jan 21, 2021 at 12:17 PM Joseph Touch <[email-masked]> wrote:

> destination addresses on an IP packet remain constant
> >> IP addresses is the only means for identifying an Internet endpoint per
> RFC 1122. While I agree that there may be utility of having proxied
> endpoints (e.g. NATs) with effectively internal addresses behind them, it
> doesn’t help the case to begin with this inaccurate assertion.
> >
> draft-ietf-spring-srv6-network-programming has been approved by the IESG,
> you probably cannot make such assertion anymore.
>
> Esp. when (AFAICT) that doc series never mentions how transport protocols
> are supposed to deal with indeterminate endpoint addresses in their pseudo
> headers or the impact to security protocols at the transport (not transport
> content) layer.
>
> Joe

---

From: Nick Hilliard <[email-masked]>
Date: Thu, 21 Jan 2021 19:32:54 +0000

Phillip Hallam-Baker wrote on 21/01/2021 18:57:
> level of incentive to drive IPv6 adoption.

being brutally honest here: most people will never know and will care 
even less what their ipv6 address block is.  What they want to do is to 
walk into their home / office / the shop / etc and to be able to browse 
cat videos, send selfies on groups and upload pics to social media. 
Issues relating to ip addressing are so far away from their field of 
interest or even awareness that it's a bit bizarre for us to have to 
remind ourselves yet again that bringing IP address portability and 
guaranteed uniqueness to the masses is a vanishingly small niche.

There is a market for this, for sure, in the same way that there's also 
a market for consumer availability of everything from generic 
transistors to coffee machine pumps.  But it is not, and never will be a 
mass market phenomenon.

I spent two happy hours last weekend upgrading my coffee machine pump 
with a quieter model (invensys cp4/sp) purchased at low cost from ebay. 
No matter how much fun it was, it didn't cause higher adoption of home 
coffee machines in the marketplace.

Nick

---

From: Brian E Carpenter <[email-masked]>
Date: Fri, 22 Jan 2021 08:56:01 +1300

Putting two things together:
On 22-Jan-21 07:57, Phillip Hallam-Baker wrote:
...
> A ULA->Public key registry provides exactly the right degree of incentive. It allows us to take an area that is currently flaky as heck and make it 'just work'. That area is VPN access.

Yes, but afaik you (or I) can't claim ownership of random numbers. So if my ULA prefix is fd63:45eb:dc14::/48 and I provide a public key for it, what's to stop you using the same prefix and providing your own public key for it?

>     > How is that problem solved today for RFC 1918 addresses?

If ULA usage is validated by a public key, that might appear to support audit and accountability, but only if there's a third-party guarantee of uniqueness. I think Michael has an important point here. A self-assigned ULA prefix has no more legal significance than a Net 10 address.

Regards
    Brian

---

From: Nick Hilliard <[email-masked]>
Date: Thu, 21 Jan 2021 22:39:45 +0000

Phillip Hallam-Baker wrote on 21/01/2021 16:00:
> Perhaps we should ask how registries can go wrong. Or maybe we should 
> ask the IAB to consider this.I can think of a few problems:
> 
> Integrity

+ practical issues: insolvency, mismanagement, internal fraud, graft, 
liabilities therefrom, corruption, threat of legal action due to 
deregistration, threats from stakeholders / owners, etc.

> OK so there is one 'risk' that perhaps should be mentioned openly 
> because it is likely the one of most concern to people, 'what are the 
> unexpected uses of these addresses' or 'what else is PHB planning he is 
> not telling us about'.

obviously raising prices 10x after lock-in has been achieved 👀

There's no shortage of failure modes.

> The registry concern that is rarely considered in IETF is what happens 
> if there is no registry? There are two possibilities:
> 
> The second has occurred on countless occasions and sometimes between 
> really big companies. Every hard drive has a unique identifier which is 
> actually in the MAC address space. After asking nicely and getting the 
> run-around, the drive makers just allocated themselves 1/16th of the 
> total MAC address space.

does this matter to the IEEE?  I.e. is this a MAC?

Nick

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Thu, 21 Jan 2021 20:02:19 -0500

On Thu, Jan 21, 2021 at 2:56 PM Brian E Carpenter <
[email-masked]> wrote:

> > A ULA->Public key registry provides exactly the right degree of
> incentive. It allows us to take an area that is currently flaky as heck and
> make it 'just work'. That area is VPN access.
>
> Yes, but afaik you (or I) can't claim ownership of random numbers. So if
> my ULA prefix is fd63:45eb:dc14::/48 and I provide a public key for it,
> what's to stop you using the same prefix and providing your own public key
> for it?
>

The registry undertakes to only issue each prefix once and bind it to a
public key specified by the holder.

The registry publishes the allocation in an append only log which is
attested by a blockchain type technique. So there is (almost) no scope for
the registry to defect.

> If ULA usage is validated by a public key, that might appear to support
> audit and accountability, but only if there's a third-party guarantee of
> uniqueness. I think Michael has an important point here. A self-assigned
> ULA prefix has no more legal significance than a Net 10 address.
>

Haber and Stornetta's hash chain notary concept, now known as blockchain
allow the degree of trust in the third party to be very very small.

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Thu, 21 Jan 2021 20:13:42 -0500

> obviously raising prices 10x after lock-in has been achieved 👀

I wasn't asking for an exclusive. As with the WebPKI, anyone else can start
up a registry allocating from a different prefix. I am only asking for 1
out of 16 million registry prefixes in that space.

Deregistration cannot take place in my technology model.

> does this matter to the IEEE?  I.e. is this a MAC?

The IEEE didn't like it but they ended up having to make a big hole in
their MAC allocation space to make room for it.

---

From: Christian Huitema <[email-masked]>
Date: Thu, 21 Jan 2021 21:44:50 -0800

On 1/21/2021 5:02 PM, Phillip Hallam-Baker wrote:

> On Thu, Jan 21, 2021 at 2:56 PM Brian E Carpenter 
> <[email-masked] <mailto:[email-masked]>> wrote:
>
>     incentive. It allows us to take an area that is currently flaky as
>     heck and make it 'just work'. That area is VPN access.
>
>     Yes, but afaik you (or I) can't claim ownership of random numbers.
>     So if my ULA prefix is fd63:45eb:dc14::/48 and I provide a public
>     key for it, what's to stop you using the same prefix and providing
>     your own public key for it?
>
>
> The registry undertakes to only issue each prefix once and bind it to 
> a public key specified by the holder.
>
> attested by a blockchain type technique. So there is (almost) no scope 
> for the registry to defect.

How do you protect the registry against a Sybil attack?

-- Christian Huitema

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Fri, 22 Jan 2021 00:57:15 -0500

> How do you protect the registry against a Sybil attack?
There is a one-time charge of $0.10 per registration. No renewal fees.

So a DoS attack would merely swell the coffers of the not-for-profit Mesh
foundation which will pay for development of code, etc.

I am not sure that a Sybil attack is relevant as there is absolutely no
accreditation going on here except between the registry and the small set
of chosen peer notaries. And they are merely cross notarising. There are no
subjective or unconstrained inputs here. Every input is deterministic, the
only non determinism comes from timing.

---

From: Christian Huitema <[email-masked]>
Date: Thu, 21 Jan 2021 22:23:58 -0800

On 1/21/2021 9:57 PM, Phillip Hallam-Baker wrote:
> On Fri, Jan 22, 2021 at 12:45 AM Christian Huitema 
> <[email-masked] <mailto:[email-masked]>> wrote:
>
>>     <[email-masked]
>>     <mailto:[email-masked]>> wrote:
>>
>>         > A ULA->Public key registry provides exactly the right
>>         degree of incentive. It allows us to take an area that is
>>         currently flaky as heck and make it 'just work'. That area is
>>         VPN access.
>>
>>         Yes, but afaik you (or I) can't claim ownership of random
>>         numbers. So if my ULA prefix is fd63:45eb:dc14::/48 and I
>>         provide a public key for it, what's to stop you using the
>>         same prefix and providing your own public key for it?
>>
>>
>>     The registry undertakes to only issue each prefix once and bind
>>     it to a public key specified by the holder.
>>
>>     The registry publishes the allocation in an append only log which
>>     is attested by a blockchain type technique. So there is (almost)
>>     no scope for the registry to defect.
>
That should work if the "block chain" signatures can only be appended by 
the organization maintaining the registry. I wonder why just $0.10, 
given that for the normal user just learning the process will cost way 
more than that. Also, just the credit card fees are larger than that. 
Plus, if you want to guarantee the ownership "forever", you probably 
need sustained revenues in the long term.
>
> So a DoS attack would merely swell the coffers of the not-for-profit 
> Mesh foundation which will pay for development of code, etc.
>
> I am not sure that a Sybil attack is relevant as there is absolutely 
> no accreditation going on here except between the registry and the 
> small set of chosen peer notaries. And they are merely cross 
> notarising. There are no subjective or unconstrained inputs here. 
> Every input is deterministic, the only non determinism comes from timing.

There are variants of the Sybil attack that concentrate on fractions of 
the address space. Also, if the space is just 40 bit wide, the attacker 
will start causing random collisions after registering 1 million entries.

Speaking of collisions, is there a way for registrants to test for 
collisions before registering? Is it correct to assume a publicly 
available blockchain?

-- Christian Huitema

---

From: Nick Hilliard <[email-masked]>
Date: Fri, 22 Jan 2021 14:18:27 +0000

> Deregistration cannot take place in my technology model.

this wasn't fully clear either from your previous descriptions.  There's 
plenty of address space to be able to do this sort of thing, but 
building a registry on this basis is a design choice which commits to 
ensuring long-term registry inaccuracy due to inability to perform 
garbage collection.

A traditional registry would normally be designed on the basis of 
providing an accurate mapping between resource and resource holder.  If 
that mapping is broken, then one of the core components of the registry 
function is no longer present.  The ietf would want some fairly 
unambiguous and clearly articulated reasons to justify why this was a 
wise long-term approach to finite resource allocation, and whether the 
term "registry" was applicable.

Nick

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Fri, 22 Jan 2021 11:13:04 -0500

On Fri, Jan 22, 2021 at 1:24 AM Christian Huitema <[email-masked]>
wrote:

> the organization maintaining the registry. I wonder why just $0.10, given
> that for the normal user just learning the process will cost way more than
> that. Also, just the credit card fees are larger than that. Plus, if you
> want to guarantee the ownership "forever", you probably need sustained
> revenues in the long term
>

I was in that business for a decade. I know exactly where the costs are and
I am planning to configure my businesses accordingly.

The IPv6 part is just a bolton to the Mesh callsign registry I am already
building. I can throw a /62 at every registrant with no hassle.

1) The Mesh Foundation, a not-for-profit runs the registry as public goods.
Sells blocks of 10,000 Mesh registrations for $100 each to anyone who wants
to set up a Mesh Service Provider (MSP) or just issue registrations.

2) Threshold Secrets, a for profit MSP that provides customer service,
account hosting etc. at commercial rates.

The big difference between my model and the traditional Internet account
model is that accounts are portable. You own your account, it is bound to
the public keys you own. So you can register with my MSP, use it for a
year, decide you don't like the service I provide and switch to Fred's.
That change is advertised through the registry.

All the costs of the registry are offloaded onto the MSPs. VeriSign sheds
the cost of customer service to the registrars. I am proposing to shed the
cost of resolution service as well.

So if I want to contact you on Signal, SMTP, etc. via your Mesh callsign
(@christian), my client goes to my MSP, and finds the location of your
current MSP servicing the account and presents an authenticated request for
your current contact info. If authorised, your client gets my current
contact info (or the contact info you are allowed, if I don't know you, its
probably just info on how to request a contact exchange).

I expect the operating expenses of the registry to be in the low seven
figures operating at scale. If I am incorrect, we raise the rates. If we
raise the rates higher than people find acceptable, we will get competition.

> will start causing random collisions after registering 1 million entries.
I am proposing to issue in the registered space FC00::/8, not the random
space FD00:/8. And I am asking* for a /32 from which I will allocate /62s
so, I have room for 2^30 registrations in my initial allocation. If I start
to run out, I ask for an extra /32. There are 16 million /32s in that
space. So we don't run out till we have allocated a trillion registrations.
And these are densely packed.

[*] Asking for advice, not necessarily permission.

> collisions before registering? Is it correct to assume a publicly available
> blockchain?
>
> -- Christian Huitema
>
I don't see the random approach being feasible for the reasons you raise.
Since my plan is to add this to a registration service, I will be
allocating in dense blocks with a transparent allocation rubric.

---

From: Fernando Gont <[email-masked]>
Date: Sat, 23 Jan 2021 04:36:22 -0300

Hi, Joe,

On 21/1/21 14:17, Joseph Touch wrote:
>>>> 0) Nowhere does the 'end to end' principle demand that the 
>>>> source and destination addresses on an IP packet remain 
>>>> constant
>>> IP addresses is the only means for identifying an Internet 
>>> endpoint per RFC 1122. While I agree that there may be utility of
>>> having proxied endpoints (e.g. NATs) with effectively internal
>>> addresses behind them, it doesn’t help the case to begin with
>>> this inaccurate assertion.
>> 
> Esp. when (AFAICT) that doc series never mentions how transport 
> protocols are supposed to deal with indeterminate endpoint addresses
>  in their pseudo headers or the impact to security protocols at the 
> transport (not transport content) layer.

One *internet-draft* certainly doesn't undermine E2E. However, I guess
that an *RFC* published as a "Proposed Standard" probably does 
(undermine) E2E? -- (draft-ietf-spring-srv6-network-programming has been 
approved by the IESG).

At the end of the day, I guess we cannot publish a PS that clearly
breaks E2E, while at the same time claim or pretend that we keep/have 
E2E....

(Full-disclosure: I was on the side of keeping E2E
(https://www6.ietf.org/iesg/appeal/gont-2020-04-22.txt))

Thanks,

---

From: Eliot Lear <[email-masked]>
Date: Sat, 23 Jan 2021 11:02:38 +0100

Hi everyone,

As Nick Hillard pointed out, this came up in December on the IPv6 list.  The registry is managed by Nico Schottelius and Ungleich[1].  Does that make this registry The Registry?  Perhaps not.  Does it address the Sybil attack?  No.

There is clearly demand for such registration, given that there is already a registry of over 5,000 networks, and it is clear that Ungleich is satisfying that demand.  This raises some questions.  It may be the case that a listing may lead to people believing that they are somehow guaranteed that their use is indeed unique, when in fact no such guarantee can be made or kept under the current scheme.  Also I think there are some tough questions that may need to be resolved around points of contact and relevant laws.  These are things that both ICANN and the various RIRs have paid considerable attention to.

One might ask: why aren’t people just going through the RIR system to get globally routable space?  I am sure there are varying answers to that question.  One question I have is whether a Regional Internet Registry is appropriator a global allocation.  Another question I have is whether such ULA allocations will realistically remain local.  However, that the demand exists and is being satisfied is something that I encourage the IAB and this community to consider.  One of the key principles of stewardship of the address space in the past as been efficiency.  Another has been aggregation.  Here are some considerations the IAB, RIRs Nico, Phil, you Fernando, and other interest parties, might reasonably discuss:

Are those principles are still being observed at the RIRs and how they have evolved,
What are the blockers to using an RIR block?
What should the applicable principles be?
Are there risks to the Internet ecosystem of which ungleich (and similar) registry uses should be aware?
What are the relevant policies that need to be incorporated into any new registry?
What prefix should be used?
Were there to be a more “official” registry, what are the roles of the various players, including this community, ICANN, the RIRs, ungleich, etc? And
And who gets to decide these questions?
If that sounds like an IAB workshop or a program or a BoF… well… It could be that the IAB and the RIRs have crisp answers to all of these questions.  In which case, I’m talking about an email or perhaps a statement that satisfies at least my curiosity and apparently those of others ;-)

One aspect with which I take great issue is that this should even be considered for IPv4.  IMHO, that would be getting blood from a stone.

Eliot
[1] https://ula.ungleich.ch/

---

From: Masataka Ohta <[email-masked]>
Date: Sat, 23 Jan 2021 22:04:27 +0900

> (undermine) E2E? -- (draft-ietf-spring-srv6-network-programming has been 

Wrong.

That the draft state "any complex user-defined behavior" means
it is subject to incompleteness theorem applicable to any
system complex enough to be able to handle natural numbers, which
means its behavior can not be fully reversed by external systems
to restore the E2E transparency even though its behavior is
formally fully described, which means the E2E principle can
not be kept regardless of whatever random things IESG might
have stated.

It is *VERY* well known that powerful formal description can not
fully analyzed mechanically, which is the incompleteness theorem.

So, the draft or PS or whatever is totally broken. Just ignore
it along with people who are working for it.

The only formal system fully analyzed mechanically is finite
state systems.

So, if there is similar draft but only applicable to "behavior
only as complex as to be represented by finite state automaton",
the draft may be valid, but, such representation is so poor to
be useful.

						Masataka Ohta

PS

The situation has been obvious when deoccifying was mentioned by
IAB, which means most, if not all, of them do not understand the 
incompleteness theorem.

PPS

E2E transparency can be fully restored by end systems, even if it
is disturbed by intermediate systems, if, and only if, the end
systems not merely have formal description of the intermediate
systems but can actively and properly interact with the intermediate
systems to control actively their internal activities.

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Sat, 23 Jan 2021 11:49:05 -0500

On Sat, Jan 23, 2021 at 5:02 AM Eliot Lear <[email-masked]> wrote:

> Hi everyone,
>
> As Nick Hillard pointed out, this came up in December on the IPv6 list.
> The registry is managed by Nico Schottelius and Ungleich[1].  Does that
> make this registry The Registry?  Perhaps not.  Does it address the Sybil
> attack?  No.
>

Registries cost money to run. The only advantage of the random allocation
is that you don't need a registry. Once you decide that you need a
registry, random allocation makes no sense.

> There is clearly demand for such registration, given that there is already
> a registry of over 5,000 networks, and it is clear that Ungleich is
> satisfying that demand.  This raises some questions.  It may be the case
> that a listing may lead to people believing that they are somehow
> guaranteed that their use is indeed unique, when in fact no such guarantee
> can be made or kept under the current scheme.  Also I think there are some
> tough questions that may need to be resolved around points of contact and
> relevant laws.  These are things that both ICANN and the various RIRs have
> paid considerable attention to
>

It is non routable space. So a point of contact isn't very useful. What are
the laws that you think might apply? We haven't taken much notice of
international communications laws in the past. And ICANN only started
paying attention to EU privacy law when they realised that they were about
to be whacked with a very expensive lawsuit.

One might ask: why aren’t people just going through the RIR system to get
> globally routable space?

Because that is a registration that only exists on sufferance of the RIR.
Case in point, Parler is about to be kicked off the net again as their IPv4
and IPv6 assignments are pulled.

The RIRs already have too much power. We should not extent their monopoly
into non-routable space.

  One of the key principles of stewardship of the address space in the past
> as been efficiency.  Another has been aggregation.
>

Aggregation is precisely the thing that distinguishes routable from
non-routable allocation and it shows the reason why the random allocation
approach to ULAs is bjorked. For purposes of routing, IPv6 is really a 64
bit space, not a 128 bit space and the lower 64 bits are intended for
'local' use. So you want aggregation, you certainly want allocations to be
significantly larger than a /64. A /48 looks like the right size.
Particularly since the routing address space is a 32 bit AS number

Allocating in /48 blocks for non routable space where aggregation is
irrelevant makes very little sense to me.

Here are some considerations the IAB, RIRs Nico, Phil, you Fernando, and
> other interest parties, might reasonably discuss:
>
>    1. Are those principles are still being observed at the RIRs and how
>    they have evolved,
>    2. What are the blockers to using an RIR block?
>
> They can be taken away and the RPKI is based on a completely inappropriate
technology for the task.

3) What should the applicable principles be?

Personal autonomy of Internet users.

> 4) Are there risks to the Internet ecosystem of which ungleich (and
> similar) registry uses should be aware?
>

> 5) What are the relevant policies that need to be incorporated into any
> new registry?
>

> 6) What prefix should be used?
>

Set up an IANA registry and allocate /32s (or less) in FC00::/8. The first
256 registries that come and ask for allocations get a /32. The next 1024
get a /30 and so on.

If any registry can show they have allocated 75% of their initial
allocation, they get an allocation four times larger.

> 7) Were there to be a more “official” registry, what are the roles of the
> various players, including this community, ICANN, the RIRs, ungleich, etc?
> And
>

The WebPKI has never had an official registry. But it worked because
instead of asking for permission, we went ahead and did it. Over numerous
objections from IETF community.

> 8) And who gets to decide these questions?
>

Well not the incumbent providers. And especially not when Big Tech is in
the crosshairs on capitol hill and there are multiple Federal and civil
anti-Trust suits being thrown about. The EFF's blatant lying about the PIR
allowed them to fill their coffers bilking the rubes but left ISOC and
therefore IETF with the conflict of interest.

> If that sounds like an IAB workshop or a program or a BoF… well… It could
> be that the IAB and the RIRs have crisp answers to all of these questions.
> In which case, I’m talking about an email or perhaps a statement that
> satisfies at least my curiosity and apparently those of others ;-)
>

Or we could do an experiment and then walk back the cat on lessons learned.

The current status of my code is that the Mesh now passes all its unit
tests, I am just working on coding a robust server with sufficient
instrumentation etc. I will be adding the callsign registry in another
couple of months. Once that code is ready, I launch. Adding the IPv6 ULA
allocation to the callsign registry is 4 hours coding and 20 testing.

> One aspect with which I take great issue is that this should even be
> considered for IPv4.  IMHO, that would be getting blood from a stone.
>

At the very start of this thread, I pointed out that the motivation for all
this is precisely the fact that 10.0.0.0 simply isn't big enough. It is
worth considering but only to know why it can't work.

---

From: Joe Touch <[email-masked]>
Date: Sat, 23 Jan 2021 09:12:44 -0800

> On Jan 22, 2021, at 11:37 PM, Fernando Gont <[email-masked]> wrote:
> 
> that an *RFC* published as a "Proposed Standard" probably does (undermine) E2E?

Not when it doesn’t update the hundreds of other standards that don’t.

I also didn’t see it discuss transport pseudoheaders, but maybe it’s buried somewhere in related docs.

Joe

---

From: Fernando Gont <[email-masked]>
Date: Sat, 23 Jan 2021 10:52:51 -0300

On 23/1/21 10:04, Masataka Ohta wrote:
>> (undermine) E2E? -- (draft-ietf-spring-srv6-network-programming has 
>> been approved by the IESG).
> 
> Wrong.
> 

The problem here is not how things were specified, but rather *what* was 
specified.

> systems to control actively their internal activities.

In this case, they can't.

Thanks,

---

From: Brian E Carpenter <[email-masked]>
Date: Sun, 24 Jan 2021 10:47:56 +1300

> breaks E2E, while at the same time claim or pretend that we keep/have 

Much as I had concerns about draft-ietf-spring-srv6-network-programming,
I think we should be clear about what e2e is about. It *isn't* about
idealised transparency or even about forbidding packet mangling.
For example, what we said in RFC1958 is:
"The basic argument is that, as a first principle, certain required end-
to-end functions can only be performed correctly by the end-systems
themselves."
That wasn't the last word, of course: see RFC3724, for example.

Of course, that version of e2e does mean that any kind of packet
mangling needs to be checked to see if it harms the e2e principle.
For example, the e2e principle tells us that the decision to
retransmit a damaged or lost packet needs to be taken at the
originating host (which is why performance enhancing proxies are
obnoxious). And it tells us that decryption keys must only be
available at the final destination. But IMHO it *doesn't* tell us
that a routing header must not be deleted by the penultimate
hop, because it's of no value to the final destination anyway.

(Logically, it's also a no-op, because the final destination
ignores routing headers. Go figure.)

   Birian

---

From: Fernando Gont <[email-masked]>
Date: Sat, 23 Jan 2021 21:54:08 -0300

> Not when it doesn’t update the hundreds of other standards that don’t.

It doesn't formally update them, true. But it is a de-facto update: 
behavior that goes against such other standards has been approved as PS.

---

From: Joe Touch <[email-masked]>
Date: Sat, 23 Jan 2021 20:52:01 -0800

> On Jan 23, 2021, at 8:37 PM, Fernando Gont <[email-masked]> wrote:
> 
> It doesn't formally update them, true. But it is a de-facto update: behavior that goes against such other standards has been approved as PS.

There is no such thing as de facto updates.

You’re confusing the “let a thousand flowers bloom” approach with a change in architecture.

---

From: Fernando Gont <[email-masked]>
Date: Sun, 24 Jan 2021 02:18:35 -0300

> There is no such thing as de facto updates.

defacto update = a document that is doing something that goes against 
existing specs and documents. It fails to formally update existing 
documents, as well as having existing "Update" tags -- still, it changes 
the assumtions and behaviors of said specs.

(Do I like that? -- Of course not)

> You’re confusing the “let a thousand flowers bloom” approach with a change in architecture.

"Let a thousand flowers bloom" would possible for *internet-drafts*, 
*or* for standards that can exist without harming harming each other.
When the "mangling EHs on the fly" flower blooms, the IPv6 flower fades.

I could ask the question: can IPv6 routers remove EHs on the fly?
The IPv6 architecture implies that it doesn't. But there's a PS (not 
just Info or Experimental) about that -- so yes, they do.

The whole point of having an architecture is that it guides the 
development of specs. When it doesn't, the "architecture" is just words 
on paper.

---

From: Fernando Gont <[email-masked]>
Date: Sun, 24 Jan 2021 02:51:20 -0300

Hi, Brian,

On 23/1/21 18:47, Brian E Carpenter wrote:
[...]
> That wasn't the last word, of course: see RFC3724, for example.

Well, header removal is one of those. At least at the time of this 
writing, it breaks, at least:

* ICMPv6-based error reporting
* IPsec

[...]
> ignores routing headers. Go figure.)

Which gives even more the impression that we ended up screwing-up the 
architecture because folks want to use RH, and their own boxes fail to 
comply with even the most basic requirements for RH handling...

Regards,

---

From: "Joel M. Halpern" <[email-masked]>
Date: Sun, 24 Jan 2021 11:22:05 -0500

Fernando, I understand you do no think the PSP behavior of the network 
programming draft is compliant with other IPv6 RFCs.
Please stop asserting that non-compliance as fact.  The IESG (the body 
the IETF has agreed rules on such things) determined that PSP did not 
violate RFC 8200.
While I do not like PSP, I understand the reasoning they used, and 
respect that it is their job to make such decisions.

Yours,
Joel

On 1/23/2021 7:54 PM, Fernando Gont wrote:
>>> (undermine) E2E?

---

From: Joseph Touch <[email-masked]>
Date: Sun, 24 Jan 2021 08:24:22 -0800

> On Jan 23, 2021, at 1:47 PM, Brian E Carpenter <[email-masked]> wrote:
> 

Speaking of errors… this is a subtle one. Just because some functions can be performed correctly ONLY at the end systems, that does NOT mean the end is the ONLY performer of such functions (a good example of why the word “only” needs to be placed carefully).

> obnoxious). …

Agreed that the end is the only place that can ensure all lost packets are replaced. But it is incorrect that it is the only place where lost packets *can* or *should* be replaced.

ARQ and FEC at L2 can have significant benefit and are widely used. Though I agree that some PEPs are obnoxious, this kind can not only be useful, they provide a necessary ability to at least partly mitigate loss over shorter feedback loops.

Joe

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Sun, 24 Jan 2021 18:18:23 -0500

I will accept that end to end is absolutely the only valid way to move
packets when someone shows me how to defeat DoS attacks with an endpoint
approach.

People should read the paper. It is not the dogmatic, ideological statement
some folk seem to imagine. And even if it were, it isn't holy scripture.
And even if it were, when did this become a religion?

E2E is simply a pragmatic argument that keeping complexity out of the
center of the inter-network has certain advantages. But Internet protocols
have never been pure E2E. Anyone who thinks that hasn't been paying
attention.

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Mon, 25 Jan 2021 12:46:57 -0500

So I just got a response back on this from someone who doesn't want to be
identified that changed my thinking.

"So you are going to give me the ability to assign up to 2^66 identifiers
locally that are guaranteed[*] to be globally unique in a 128 bit space. I
can use them in my QR codes"

Which makes perfect sense. If I was going to stick a QR code on every bag
of stuff I put in the freezer, I would want those to be globally unique.
Then I can avoid thinking about the cases where this occurs by accident.

And that got me thinking that the mapping should go both ways. EPC codes
are 96 bit codes used in RFID tags. We should reserve a chunk of IPv6
address space for EPC codes. We have a whole /8 for registered ULAs, this
would burn one out of 16 million code points.

What is a non-routable IP address? It is a name. It is a signifier with the
characteristic thirdness. The signifier bears no intrinsic relationship to
the signified. It is a purely conventional relationship.

So lets see how this might be applied in a real life situation:

A can of beans is produced in a factory, it has a unique EPC code X printed
on the side of the tin.

Alice places an online shopping order for some beans, the can with unique
code X is delivered.

It is discovered there was a defective batch of cans and the beans have
botulism. There is a recall. The online shopping company comes round with
the replacement and collects the precise can of beans that was defective.

That might not look like routing, but it is a form of routing. Its just not
a form of IP routing. There are many variants: tracking stolen goods,
counterfeit drugs, etc. etc.

Why would Alice need to mint her own codes? Well she probably has a digital
camera or six and they produce digital assets by the thousand.

So I am going to go ahead and write up a draft describing how I intend to
allocate /65 chunks within a 128 bit address space which all begin with a
/32 prefix in FC00::/8 . If IETF wants to avoid creating unnecessary
ambiguity, they will accept my proposal to create an IANA registry and
allocate me a number. Otherwise, I will create my own prefix[*].

If someone else comes along asking for an assignment, you just give them
the next prefix. If my registry fails, there is no real consequence. If it
succeeds its because the IETF mission has advanced a little bit.

[*] People who propose schemes for ubiquitous use of end to end encryption
after 30 years or periodic harassment by various intelligence agencies
concerned at the loss of their SIGINT capabilities are not likely to be the
sort of people who take notice of officials saying 'no'. People who have
spent two years developing such a scheme at their own personal expense are
even less likely to.