Subject: Re: [Int-area] overlay networks and the democratizing of address allocations

From: Dino Farinacci <[email-masked]>
Date: Mon, 8 Nov 2021 12:40:12 -0800

Micahel, the was a mis-spelling of the intarea mailing list in your post. Correcing it with this reply.

Dino

> On Nov 8, 2021, at 12:34 PM, Dino Farinacci <[email-masked]> wrote:
> 
>> Hi Dino, that an interesting discussion today.
>> But too short, and not really resulting in anything specific.
> 
> Yeah, maybe so Michael but I hope it fosters discussion, new ideas, and brings people together.
> 
>> I am a LISP enthusiast (both the language and the protocol.. haha).
>> I don't know that much about how LISP is deployed, operationally.
> 
> It is deployed in many niche application use-cases in "limited domains". The biggest success currently is in cisco's SDA product. Maybe someone on the list can talk a bit about it.
> 
>> I frankly think that the 44 bytes of the IPv6 header is pretty close to
>> perfect.   We have this HBH and extension problem at that layer, but maybe
>> we'll work it out on Friday.
> 
> Not sure perfet is the word. Less is always better but we don't need to argue this point. As Colin, said bits are quite cheap these days except in some limited cases on the edge.
> 
> What is important is to try and not change either the IPv6 or the IPv4 header format. If we want to bring new application features to the network that the network layer needs to provide so they can run more optimally, then we figure out solutions with those constraints (and we have done this since the inception of IPv4 and IPv6).
> 
>> As I said, where I think that we(%) have been remiss is in making IPv6
>> addresses available to everyone.
>> ULA-Random is a thing, but it's not for everyone/everything.
> 
> If you run the nodes on an overlay than the IPv6 EIDs can be cryptographically generated. So the hosts and the users and the apps that run on such hosts don't even know or care about address allocation or format.
> 
>> I believe that we(%) have allowed the revenue models of RIRs and big ISPs to
>> squash attempts to make IPv6 more available.  Yes, The Community Network
>> provision can help in very small places, but still not enough.
> 
> They will still need to exist because they supply attachment point addresses to large network providers. What we have called locators. And they MUST be required to be Provider Dependent/assigned. What we have called in the past "PA addresses" versus "PI addresses" (provider independent). 
> 
>> We are still lacking an RFC1918 equivalent that Enterprises (particularly
>> small to medium sized ones) to have address space that they feel that they
>> own.  Doesn't have to be externally routable, but does have to trackable. (whois)
> 
> I don't think this is a problem anymore. Anyone uses whatever addresses they want to in a limited domain. There is no problem to solve here anymore.
> 
>> As I mentioned, we don't have to NAT66 with this address space, we can have
>> many addresses on each interface, and hosts/applications can/need to ask for
>> an address suitable for some destination.  Yeah, in some cases that a proxied
>> TCP connection into a Onion router numbered by raw public keys.  But at lot
>> of the time, it's an internal address that can reach to that internal server
>> across the company VPN, while at other times, it's a routable address to talk
>> to Facebook or even a low-latency/high-bandwidth private peering address to
>> talk to dropbox.
> 
> Solving such problems have moderate importance but focusing on them takes our eye off what is important.
> 
>> I think that we need to do something with getaddrinfo().
>> It was an improvement, but we need to take it just a bit further.
>> What do you think?
> 
> I think what is imported is to ask what new network layer features we need to support so apps work better and are simpler to interface with the network. The two main features I see we need is:
> 
> o IP mobility (with shortest paths between the endpoints)
> o Low latency (which implies shortest paths between endpoints)
> 
> And we ask app providers and high-level service providers if they think these are important. Once you identified the high-level features, we then talk about how to solve them.
> 
> The side meeting was focus on bottom-up and that always results in no one wanting the solution. I think Luigi/Dirk wanted this discussion to be of larger scope and just coined the side meeting as "address gaps".
> 
> We have to talk about how we, not as netowrk engineers, but network users, want from our Internet. And we have to sanity check the feature list with non network engineers.
> 
> Dino
> 
>

---

From: Dirk Trossen <[email-masked]>
Date: Tue, 9 Nov 2021 13:13:03 +0000

Hi Dino & Michael,

Thanks for kicking off the discussion. We showed our main points and take-away at the INT area WG meeting just now. 

On your point of 
> The side meeting was focus on bottom-up and that always results in no one wanting the solution. I think Luigi/Dirk wanted this discussion to be of larger scope and just coined the side meeting as "…
we will follow up with discussion threads, including those on wider architectural aspects, while also continuing on the specific addressing scope. Your question on "what do we want from our Internet" is a key one to ask in this wider discussion, so stay tuned.

Best,

Dirk

-----Original Message-----
From: Int-area [mailto:[email-masked]] On Behalf Of Dino Farinacci
Sent: 08 November 2021 21:40
To: Michael Richardson <[email-masked]>
Cc: [email-masked]
Subject: Re: [Int-area] overlay networks and the democratizing of address allocations

Dino

>> As I said, where I think that we(%) have been remiss is in making 
>> IPv6 addresses available to everyone.
>> I believe that we(%) have allowed the revenue models of RIRs and big 
>> ISPs to squash attempts to make IPv6 more available.  Yes, The 
>> Community Network provision can help in very small places, but still not enough.
> 
>> We are still lacking an RFC1918 equivalent that Enterprises 
>> (particularly small to medium sized ones) to have address space that 
>> they feel that they own.  Doesn't have to be externally routable, but 
>> does have to trackable. (whois)
> 
>> As I mentioned, we don't have to NAT66 with this address space, we 
>> can have many addresses on each interface, and hosts/applications 
>> can/need to ask for an address suitable for some destination.  Yeah, 
>> in some cases that a proxied TCP connection into a Onion router 
>> numbered by raw public keys.  But at lot of the time, it's an 
>> internal address that can reach to that internal server across the 
>> company VPN, while at other times, it's a routable address to talk to 
>> Facebook or even a low-latency/high-bandwidth private peering address to talk to dropbox.
> 
> o IP mobility (with shortest paths between the endpoints) o Low 
> latency (which implies shortest paths between endpoints)
> 

_______________________________________________
Int-area mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/int-area

---

From: Michael Richardson <[email-masked]>
Date: Sun, 14 Nov 2021 18:31:00 -0500

> Yeah, maybe so Michael but I hope it fosters discussion, new ideas, and

Me too!

    > It is deployed in many niche application use-cases in "limited
    > domains". The biggest success currently is in cisco's SDA
    > product. Maybe someone on the list can talk a bit about it.

If I wanted to deploy it among a few cooperating entities, I think that I
would need address space for the overlay.  Where would I get that?

    > Not sure perfet is the word. Less is always better but we don't need to
    > argue this point. As Colin, said bits are quite cheap these days except
    > in some limited cases on the edge.

I agree.

    > If you run the nodes on an overlay than the IPv6 EIDs can be
    > cryptographically generated. So the hosts and the users and the apps
    > that run on such hosts don't even know or care about address allocation
    > or format.

Sure, the EIDs/IIDs can be generated that way, but I don't know what prefix
I'd put them into.

    > They will still need to exist because they supply attachment point
    > addresses to large network providers. What we have called locators. And
    > they MUST be required to be Provider Dependent/assigned. What we have
    > called in the past "PA addresses" versus "PI addresses" (provider
    > independent).

I'm not arguing that ISPs are bad or non-essential.  Just the opposite.
Of course, we still need locators!

    > I don't think this is a problem anymore. Anyone uses whatever addresses
    > they want to in a limited domain. There is no problem to solve here
    > anymore.

No, I disagree completely.
Leaks happen.  We need to be able to account. ULA-R is terrible this way.
It happens regularly with RFC1918 space, and IPv6 space is so
large we should generously be able to provide people with address space that
they can use in their limited domains.

    > takes our eye off what is important.

I'm not sure what is important.
I care about universal deployment of IPv6, and what I see is that Enterprises
are way behind on this, and one of the pain points they see is that there
isn't address space that they easily get.

    > I think what is imported is to ask what new network layer features we
    > need to support so apps work better and are simpler to interface with
    > the network. The two main features I see we need is:

    > o Low latency (which implies shortest paths between endpoints)

I agree.   Important.
But, to get this, we need apps to be able to learn what EID/IID/etc. to use
in order to get the service they need.

    > We have to talk about how we, not as netowrk engineers, but network
    > users, want from our Internet. And we have to sanity check the feature
    > list with non network engineers.

+1

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

---

From: Dino Farinacci <[email-masked]>
Date: Sun, 14 Nov 2021 16:55:05 -0800

> would need address space for the overlay.  Where would I get that?

You would get a random address allocated out of 240.0.0.0/4 and so would I. We would register those EIDs to the mapping system so the dynamic RLOCs are bound to those EIDs. I would have to tell you my EID, so you can ping it and the system would connect us (even through NATs).

It is much more plug-and-play than existing Kubernetes based systems. Don't get me wrong KB is great, but it is heavyweight, maybe more heavy weight than most people need.

> isn't address space that they easily get.

Okay, then the example above uses fe::/8 and allocates random bits in the rest of the 120 bits. Or … those 120 bits can be a hash of your public key. Everything else stays the same. The mapping system maps IPv4 EIDs to NAT-translated RLOCs.

> I think that we need to do something with getaddrinfo().

Your DNS names map to fe::/8 addresses. Apps only know about EIDs, nothing else. Then they can move and keep running. They don't even know they are moving.

> in order to get the service they need.

The way they learn about addresses today is the same they would with an overlay. All an EID is in IPv4 is a 32-bit value. There is NO new semantic meaning to the app about such an address.

Dino