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.
Me too!
>> 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.
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?
>> 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.
I agree.
>> 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.
Sure, the EIDs/IIDs can be generated that way, but I don't know what prefix
I'd put them into.
>> 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).
I'm not arguing that ISPs are bad or non-essential. Just the opposite.
Of course, we still need locators!
>> 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.
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.
>> 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'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 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)
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 protected]> . o O ( IPv6 IøT consulting )
Sandelman Software Works Inc, Ottawa and Worldwide
signature.asc
Description: PGP signature
_______________________________________________ Int-area mailing list [email protected] https://www.ietf.org/mailman/listinfo/int-area
