Re: AWS Elastic IP architecture

[Owen DeLong <owen () delong com>]

> On Jun 2, 2015, at 4:08 PM, Matthew Kaufman <matthew () matthew at> wrote:
>
>
> On 6/2/15 2:35 AM, Owen DeLong wrote:
> > > On Jun 2, 2015, at 5:49 AM, Matthew Kaufman <matthew () matthew at> wrote:
> > >
> > > On 6/1/2015 6:32 PM, Mark Andrews wrote:
> > > > In message <CAL9jLaaQUP1UzoKag3Kuq8a5bMcB2q6Yg=B_=1fFWxRN6K-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-=rs4vSx5mFECpfuE8b7VQ+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.
>
> 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 — 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.
>
> 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… You’re 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…

For example, let’s 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’s say the machines are all on 2001:db8::/64. Further, let’s 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’m 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.
>
> 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’s more than marginal.

> > As such, I’d 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.
> >
> > I can assure you that it is MUCH easier for me to remote-manage my mother’s machines over their IPv6 addresses than 
> > to get to them over IPv4.
>
> Only because you've insisted on doing it the hard way, instead of using something like teamviewer or logmein which 
> "just works”.

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.
>
> 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’s a great grandmother these days.

> > > 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 — More addresses.
> >
> > However, more addresses, especially on the scale IPv6 delivers them comes with MANY benefits:
> >
> >      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
>
> 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.

> >      8.      Simpler application code
>
> 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=FALSE (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).

> >      9.      Reduced complexity in:
> >                      Proxies
> >                      Applications
> >                      Firewalls
> >                      Logging
> >                      Monitoring
> >                      Audit
> >                      Intrusion Detection
> >                      Intrusion Prevention
> >                      DDoS mitigation
>
> Matters not to most home users.

Until it does. I’ve had lots of complaints from end users where they didn’t 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’s 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’s very little, if any, IPv4 running across the backbone of the internet.

> > I’m sure there are other benefits as well, but this gives you at least 10.
> >
> > There are those that would argue that other design advantages include:
> >
> >      1.      Fixed length simplified header
>
> Maybe.
>
> >      2.      Stateless Address Autoconfiguration
>
> 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’t 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
>
> Remains to be seen if this matters.

I’ve found it quite useful as have several other people I know.

> >      4.      A much cleaner implementation of IPSEC
>
> 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’t mean that an electric sewing machine with CNC 
stitching capabilities for embroidery, etc. is not a better alternative.

> > I’m sure there are more, but this is a quick list off the top of my head.
>
> There's a bunch of myths too... and "every device will be directly reachable from the entire Internet" is on there.

That’s not a myth, it’s just an incomplete statement that people like you love to truncate for the sake of claiming it 
is a myth.

The complete statement is “Every device can be directly reachable from the entire internet to the extent allowed by 
policy.”

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