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 "address gaps". 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 protected]] On Behalf Of Dino Farinacci Sent: 08 November 2021 21:40 To: Michael Richardson <[email protected]> Cc: [email protected] Subject: Re: [Int-area] overlay networks and the democratizing of address allocations 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 protected]> 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 > > _______________________________________________ Int-area mailing list [email protected] https://www.ietf.org/mailman/listinfo/int-area _______________________________________________ Int-area mailing list [email protected] https://www.ietf.org/mailman/listinfo/int-area
