[180444] in North American Network Operators' Group
Re: AWS Elastic IP architecture
daemon@ATHENA.MIT.EDU (Owen DeLong)
Wed Jun 3 07:59:58 2015
X-Original-To: nanog@nanog.org
From: Owen DeLong <owen@delong.com>
In-Reply-To: <556DC705.2090406@matthew.at>
Date: Wed, 3 Jun 2015 12:56:12 +0100
To: Matthew Kaufman <matthew@matthew.at>
Cc: nanog@nanog.org
Errors-To: nanog-bounces@nanog.org
> On Jun 2, 2015, at 4:08 PM, Matthew Kaufman <matthew@matthew.at> =
wrote:
>=20
>=20
> On 6/2/15 2:35 AM, Owen DeLong wrote:
>>> On Jun 2, 2015, at 5:49 AM, Matthew Kaufman <matthew@matthew.at> =
wrote:
>>>=20
>>> On 6/1/2015 6:32 PM, Mark Andrews wrote:
>>>> In message =
<CAL9jLaaQUP1UzoKag3Kuq8a5bMcB2q6Yg=3DB_=3D1fFWxRN6K-bNA@mail.gmail.com
>>>>> , Christopher Morrow writes:
>>>>> On Mon, Jun 1, 2015 at 9:02 PM, Ca By <cb.list6@gmail.com> wrote:
>>>>>> On Monday, June 1, 2015, Mark Andrews <marka@isc.org> wrote:
>>>>>>> In message
>>>>>>> =
<CAL9jLaYXCdfViHbUPx-=3Drs4vSx5mFECpfuE8b7VQ+Au2hCXpMQ@mail.gmail.com>
>>>>>>> , Christopher Morrow writes:
>>>>>>>> So... I don't really see any of the above arguments for v6 in a =
vm
>>>>>>>> setup to really hold water in the short term at least. I think =
for
>>>>>>>> sure you'll want v6 for public services 'soon' (arguably like =
10 yrs
>>>>>>>> ago so you'd get practice and operational experience and ...) =
but for
>>>>>>>> the rest sure it's 'nice', and 'cute', but really not required =
for
>>>>>>>> operations (unless you have v6 only customers)
>>>>>>> Everyone has effectively IPv6-only customers today. IPv6 native =
+
>>>>>>> CGN only works for services. Similarly DS-Lite and 464XLAT.
>>>>> ok, and for the example of 'put my service in the cloud' ... the
>>>>> service is still accessible over ipv4 right?
>>>> It depends on what you are trying to do. Having something in the
>>>> cloud manage something at home. You can't reach the home over IPv4
>>>> more and more these days as. IPv6 is the escape path for that but
>>>> you need both ends to be able to speak IPv6.
>>> ...and for firewalls to not exist. Since they do, absolutely all the =
techniques required to "reach something at home" over IPv4 are required =
for IPv6. This is on the "great myths of the advantages of IPv6" list.
>> IPv4 with NAT, you can open one host at home to remote access, or, in =
some cases, you can select different hosts by using the port number in =
lieu of the host name/address.
>=20
> IPv4 with NAT, standard NAT/firewall traversal techniques are used so =
that things inside your house are reachable as necessary. Almost nobody =
configures their firewall to open up anything.
HuH?
How do I SSH into my host behind my home NAT firewall without =
configuration of the firewall?
You are making no sense here. NAT Traversal techniques provide for =
outbound connections and/or a way that a pseudo-service can create an =
inbound connection that looks like an outbound connection to the =
firewall.
It does not in any way provide for generic inbound access to ordinary =
services without configuration.
>> IPv6 =97 I add a permit statement to the firewall to allow the =
traffic in to each host/group of hosts that I want and I am done.
>=20
> IPv6, standard NAT?firewall traversal techniques are used so that =
things inside your house are reachable as necessary. Still almost nobody =
configures their firewall to open up anything.
Why would one use NAT with IPv6=85 You=92re making no sense there.
> For those who do, the work needed to open up a few host/port mappings =
in IPv4 is basically identical to opening up a few hosts and ports for =
IPv6.
Not really=85
For example, let=92s say you have 20 machines for whom you want to allow =
inbound SSH access. In the IPv4 world, with NAT, you have to configure =
an individual port mapping for each machine and you have to either =
configure all of the SSH clients, or, specify the particular port for =
the machine you want to get to on the command line.
On the other hand, with IPv6, let=92s say the machines are all on =
2001:db8::/64. Further, let=92s say that I group machines for which I =
want to provide SSH access within 2001:db8::22:0:0:0/80. I can add a =
single firewall entry which covers this /80 and I=92m done. I can put =
many millions of hosts within that range and they all are accessible =
directly for SSH from the outside world.
Takes about 20 seconds to configure my firewall once and then I never =
really need to worry about it again.
Further, in the IPv4 case, I need special client configuration or client =
invocation effort every time, while with the IPv6 case, I can simply put =
the hostname in DNS and then use the name thereafter.
>> I do not see the above as being equal effort or as yielding equal =
results.
>=20
> For the automatic traversal cases, the end-user effort is identical.
Sure, but automatic traversal is the exception not the rule when =
considering internet services.
> For the incredibly rare case of manual configuration (which as NANOG =
participants we often forget, since we're adjusting our routers all the =
time) there is almost no difference for most use cases.
Not true as noted above.
> Yes, the results are marginally superior in the IPv6 case. Nobody =
cares.
I would argue that it=92s more than marginal.
>> As such, I=92d say that your statement gets added to the great myths =
of Matthew Kauffman rather than there being any myth about this being an =
IPv6 advantage.
>>=20
>> I can assure you that it is MUCH easier for me to remote-manage my =
mother=92s machines over their IPv6 addresses than to get to them over =
IPv4.
>=20
> Only because you've insisted on doing it the hard way, instead of =
using something like teamviewer or logmein which "just works=94.
So does vmc://hostname (if I have IPv6 or non-NAT IPv4).
>> I live in California and have native dual-stack without NAT. She =
lives in Texas and has native dual-stack with NAT for her IPv4.
>=20
> And I assume your mother opened up her IPv6 firewall all on her own?
As a matter of fact, she did open up the first connection which then =
provided me the necessary access to configure the rest for her.
> Most people won't have the technical skills to adjust the IPv6 =
firewall that comes with their CPE and/or "Wireless Router" any more =
than they have the skills to set up IPv4 port mapping.
My mother is about as non-technical as you would imagine the typical =
grandmother portrayed in most such examples. Technically, she=92s a =
great grandmother these days.
>=20
>>> IPv6 has exactly one benefit... there's more addresses. It comes =
with a whole lot of new pain points, and probably a bunch of security =
nightmare still waiting to be discovered. And it for sure isn't free.
>> IPv6 comes with at least one design-advantage =97 More addresses.
>>=20
>> However, more addresses, especially on the scale IPv6 delivers them =
comes with MANY benefits:
>>=20
>> 1. Simplified addressing
>> 2. Better aggregation
>> 3. Direct access where permitted
>> 4. Elimination of NAT and its security flaws and =
disadvantages
>> 5. Simplified topologies
>> 6. Better subnetting
>> 7. Better network planning with sparse allocations
>=20
> All of those are benefits for the network operator, not the end user.
I can see that all of those benefit the network operator.
However, with the exception of 2 and 7, I would argue that all of them =
are also of benefit to at least some fraction of end-users.
I am an end user and I am seeing benefits from all but 2. I use sparse =
address allocation to allow me to classify hosts for convenience, for =
example.
Note, the original item 6 (corrected above) was autocorrected from =
subnetting to sunbathing. I have restored it to subnetting.
>=20
>> 8. Simpler application code
>=20
> Might be true *if* there was only IPv6. If there's also the need to =
support IPv4 then supporting *both* is harder than supporting just one.
Only because the need to support NAT traversal comes as overhead in =
supporting IPv4.
Otherwise, most applications can be written for IPv6 and set the socket =
option IPV6_V6ONLY=3DFALSE (which should be the default) and on a =
dual-stack host, the application will simply work and deal with both =
protocols without ever caring about IPv4. (IPv4 connections are =
presented to the application as an IPv6 connection from a host with =
address ::ffff:IP:v4 (where IP:v4 is the 32-bit IPv4 address of the =
source host).
>=20
>> 9. Reduced complexity in:
>> Proxies
>> Applications
>> Firewalls
>> Logging
>> Monitoring
>> Audit
>> Intrusion Detection
>> Intrusion Prevention
>> DDoS mitigation
>=20
> Matters not to most home users.
Until it does. I=92ve had lots of complaints from end users where they =
didn=92t know that the issue was a proxy problem, application coding =
error with NAT traversal, Firewall problem, etc., but upon =
investigation, these were exactly the source of said end-user=92s =
problem.
> Doesn't help corporate users because they also need all that for IPv4 =
indefinitely.
See above. The more traffic that corporate users can get off of IPv4, =
the less trouble these things will cause for them. As such, your =
argument falls flat.
>> 10. The ability to write software with hope of your codebase =
working for the next 10 years or more.
> I'll bet that there's IPv4 devices running happily 10 years from now.
Maybe, but I bet within 10 years, there=92s very little, if any, IPv4 =
running across the backbone of the internet.
>> I=92m sure there are other benefits as well, but this gives you at =
least 10.
>>=20
>> There are those that would argue that other design advantages =
include:
>>=20
>> 1. Fixed length simplified header
>=20
> Maybe.
>=20
>> 2. Stateless Address Autoconfiguration
>=20
> Disaster, given that I'm still stuck needing DHCPv6 to configure =
everything that SLAAC won't. Or things that SLAAC only picked up =
recently (like setting your DNS server) and so are still unsupported in =
all sorts of gear.
Not a disaster, but perhaps slightly less convenient for your particular =
situation.
In my situation, most hosts don=92t need anything more than an IP =
address, default gateway, and Recursive Nameserver. RAs provide all of =
that and my hosts just work fine with SLAAC out of the box.
>> 3. Mobile IP
>=20
> Remains to be seen if this matters.
I=92ve found it quite useful as have several other people I know.
>> 4. A much cleaner implementation of IPSEC
>=20
> Sure, but the IPv4 IPSEC seems to work just fine everywhere I've =
deployed it.
For some definition of work. The additional overhead, increased =
complexity of configuring it, incompatible implementations, and other =
nightmares I have encountered in IPv4 IPSEC vs. the relative ease and =
convenience of using it in IPv6 strikes me as quite worth while.
A treadle sewing machine works if you choose to use one. That doesn=92t =
mean that an electric sewing machine with CNC stitching capabilities for =
embroidery, etc. is not a better alternative.
>> I=92m sure there are more, but this is a quick list off the top of my =
head.
>=20
> There's a bunch of myths too... and "every device will be directly =
reachable from the entire Internet" is on there.
That=92s not a myth, it=92s just an incomplete statement that people =
like you love to truncate for the sake of claiming it is a myth.
The complete statement is =93Every device can be directly reachable from =
the entire internet to the extent allowed by policy.=94
The complete statement is quite true. The incomplete statement is false =
only because it contains a scope which is beyond the ability of what a =
protocol can deliver, due to the missing words.
Owen
