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
