[180475] in North American Network Operators' Group
Re: AWS Elastic IP architecture
daemon@ATHENA.MIT.EDU (=?utf-8?B?TcOlbnM=?= Nilsson)
Thu Jun 4 13:44:33 2015
X-Original-To: nanog@nanog.org
Date: Thu, 4 Jun 2015 19:44:29 +0200
From: =?utf-8?B?TcOlbnM=?= Nilsson <mansaxel@besserwisser.org>
To: Christopher Morrow <morrowc.lists@gmail.com>
In-Reply-To: <CAL9jLaYEBZfBJaY59n8=so6SyVRQYUtj5sGgK9TmCYtDMR0u0A@mail.gmail.com>
Cc: nanog list <nanog@nanog.org>
Errors-To: nanog-bounces@nanog.org
--XsQoSWH+UP9D9v3l
Content-Type: text/plain; charset=utf-8
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable
Subject: Re: AWS Elastic IP architecture Date: Thu, Jun 04, 2015 at 01:16:0=
3PM -0400 Quoting Christopher Morrow (morrowc.lists@gmail.com):
> On Thu, Jun 4, 2015 at 5:11 AM, Owen DeLong <owen@delong.com> wrote:
> > I=E2=80=99d argue that SSH is several thousand, not a few hundred. In a=
ny case, I suppose you can make the argument that only a few people are try=
ing to access their home network resources remotely other than via some sor=
t of proxy/rendezvous service. However, I would argue that such services ex=
ist solely to provide a workaround for the deficiencies in the network intr=
oduced by NAT. Get rid of the stupid NAT and you no longer need such servic=
es.
>=20
> This is an interesting argument/point, but if you remove the rendevous
> service then how do you find the thing in your house? now the user has
> to manage DNS, or the service in question has to manage a dns entry
> for the customer, right?
Or something.
=20
> you'll be moving the (some of the) pain from 'nat' to 'dns' (or more
> generally naming and identification). I think though that in a better
> world, a service related to the thing you want to prod from outside
> would manage this stuff for you.
Possibly.=20
> It's important (I think) to not simplify the discussion as: "Oh, with
> ipv6 magic happens!" because there are still problems and design
> things to overcome even with unhindered end-to-end connectivity.
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).
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.
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.
--=20
M=C3=A5ns Nilsson primary/secondary/besserwisser/machina
MN-1334-RIPE +46 705 989668
Why is everything made of Lycra Spandex?
--XsQoSWH+UP9D9v3l
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: Digital signature
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.12 (GNU/Linux)
iEYEARECAAYFAlVwjn0ACgkQ02/pMZDM1cVKVgCgieYp1fESbJfLkStUH4c2m5ps
UfQAoJ+GC7cszqjbA70ScWAaE/yR93oz
=wvrk
-----END PGP SIGNATURE-----
--XsQoSWH+UP9D9v3l--
