AWS Elastic IP architecture

Wed Jun 3 15:55:46 UTC 2015

On 6/3/2015 4:56 AM, Owen DeLong wrote:
>
>> On Jun 2, 2015, at 4:08 PM, Matthew Kaufman <matthew at matthew.at 
>> <mailto:matthew at matthew.at>> wrote:
>>
>>
>> On 6/2/15 2:35 AM, Owen DeLong wrote:
>>>> On Jun 2, 2015, at 5:49 AM, Matthew Kaufman <matthew at matthew.at 
>>>> <mailto:matthew at matthew.at>> wrote:
>>>>
>>>> On 6/1/2015 6:32 PM, Mark Andrews wrote:
>>>>> In message 
>>>>> <CAL9jLaaQUP1UzoKag3Kuq8a5bMcB2q6Yg=B_=1fFWxRN6K-bNA at mail.gmail.com <mailto:CAL9jLaaQUP1UzoKag3Kuq8a5bMcB2q6Yg=B_=1fFWxRN6K-bNA at mail.gmail.com>
>>>>>> , Christopher Morrow writes:
>>>>>> On Mon, Jun 1, 2015 at 9:02 PM, Ca By <cb.list6 at gmail.com 
>>>>>> <mailto:cb.list6 at gmail.com>> wrote:
>>>>>>> On Monday, June 1, 2015, Mark Andrews <marka at isc.org 
>>>>>>> <mailto:marka at isc.org>> wrote:
>>>>>>>> In message
>>>>>>>> <CAL9jLaYXCdfViHbUPx-=rs4vSx5mFECpfuE8b7VQ+Au2hCXpMQ at mail.gmail.com 
>>>>>>>> <mailto:CAL9jLaYXCdfViHbUPx-=rs4vSx5mFECpfuE8b7VQ+Au2hCXpMQ at 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?

Nobody but you and a few hundred other people on this mailing list SSH 
into hosts at your home.

Everyone else in the entire world reaches hosts at their house through 
their firewall just fine because those hosts are their Nest thermostat, 
or their Dropcam, or their PC running Skype, or maybe (in rare cases) 
something like LogMeIn.

None of those people ever touch the settings of the device they had 
delivered by their ISP and/or purchased at Best Buy. Not ever.

>
> 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.

So what?

Nobody (to several levels of statistical significance) needs "generic 
inbound access to ordinary services". Heck, the only "ordinary services" 
that exist any more are HTTP/HTTPS.

>
>>> 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.

I didn't say you would... but you need firewall traversal, and the 
"standard NAT and firewall traversal techniques" are how you traverse 
your IPv6 firewall.

>
>> 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.

Ok, you go find me 1000 households where nobody in the house is on the 
NANOG list but where there are 20 machines running SSH already installed.

>
> 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.
>

Yeah, so there you are manually configuring your firewall again. Which 
isn't surprising, because you also want to have 20 hosts offering SSH to 
the world... which makes you an outlier.

> 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.

Sure... because like most homeowners, you're proficient at editing BIND 
config files.

>
>>> 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.
>

I don't know what world you're living in, but every single person I know 
is a user of one or more software or hardware devices that work just 
fine behind a firewall, either because they're just uploading things to 
a service, or periodically checking in with a service, or using 
automatic traversal techniques.

>> 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.

Most people never configure.

Most of the people who do configure need exactly one address and port to 
work, in which case the work is about the same.

You have 20 SSH hosts. You're an outlier, and so yes, in IPv6 there's 
less typing.

I'm an outlier too... my house has a Juniper SRX-240 that I configure 
from the command line at its border. That's not normal. I'm not normal. 
And that's ok.

>
>> Yes, the results are marginally superior in the IPv6 case. Nobody cares.
>
> I would argue that it’s more than marginal.

You are free to argue that.

>
>>> 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).

With default out-of-the-box firewall settings as your device arrives 
from Best Buy?

>
>>> 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.

So it isn't actually that hard. Just like it isn't that hard for one 
address and port for the user of a Slingbox or whatever other random 
product you can find that doesn't have full traversal capabilities in it.

>
>> 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.
>

Congratulations to her.

>>
>>>> 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.
>

Some fraction, sure. But since that fraction is well under 0.1%, I'm 
sticking with my position.

> 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.

Outlier.

>
> Note, the original item 6 (corrected above) was autocorrected from 
> subnetting to sunbathing. I have restored it to subnetting.
>

I preferred sunbathing.

>>
>>> 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.

The same code is needed to do IPv6 firewall traversal.

>
> 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).

For an operating system and TCP/IP stack where that is true, sure. When 
you're trying to squeeze things into a Cortex M4 that you want to hang 
on someone's wall, dual-stack takes more Flash.

>
>>
>>> 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.

Define "lots". Most users are having great luck with their current 
IPv4-only connection and the devices they're buying to use with it.

>
>> 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.

If I'm still getting support tickets due to IPv4 issues, the problems 
haven't gone away. Again, tell me when I can switch IPv4 off entirely.

>
>>> 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'd take that bet.

>
>>> 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.

Not too many WinXP machines at your house I guess.

>
>>> 3.Mobile IP
>>
>> Remains to be seen if this matters.
>
> I’ve found it quite useful as have several other people I know.
>

Outlier.

>>> 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.
>

Given that the security provided by both is identical, I'm not sure 
that's a good example, but it was creative.

>>> 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.
>

Yes. But those extra words mean that I need to carry around exactly the 
same tricks I use to get through IPv4 NAT/firewall cases.

Matthew Kaufman