AWS Elastic IP architecture

Christopher Morrow morrowc.lists at gmail.com
Thu Jun 4 18:18:24 UTC 2015


On Thu, Jun 4, 2015 at 1:44 PM, Måns Nilsson <mansaxel at besserwisser.org> wrote:
> You have successfully demonstrated that users will need some locating
> service. More so with the cure-all IPv6; because remembering hex is hard
> for People(tm).

but it's not just hex. Even today you (if given a bare ipv4 address)
would need some naming/locating service I suspect. Folk can barely
remember their email address, nevermind the hostname of their
printer/etc for remote use.

Today we 'win' because there's some third-party aggregating 'your
device' and 'you' and connecting them together 'properly'.

> You have, however, not shown that all the possible ways of building a
> locating service that become available once the end-points are uniquely
> reachable (and thus, as long as we're OK with finding just the right host,
> identifyable) present an equal level of suckage.
>

sure, I wasn't really trying to accomplish that, just to point out
that: you still have to find me in the haystack! and 'well then put
dns records in your domain' isn't an answer for 99.99+% of users. Even
if Owen's swag of 'thousands' of users 'use ssh' is on target there
are ~100m users in the US on cable/dsl plant... (so with 10 ssh users
~.01%) that will basically never 'get it'.

> I believe that while the work indeed can be daunting for a sufficiently
> pessimal selection of users, the situation so improves (if we look at
> simplicity of protocol design and resulting fragility) when the end-points
> can ignore any middleboxes that the net result, measured as inconvenicence
> imposed on a standard End User, will improve.

I bet we end up with the same rendezvous services though... perhaps we
wont have to worry about the 'printer' making a long-term (or even
periodic?) connection to that service, but I imagine there'll still be
some service complexity.

It may be better than the current situation, but that's still to be seen.



More information about the NANOG mailing list