AWS Elastic IP architecture

Matthew Kaufman matthew at matthew.at
Tue Jun 2 15:08:53 UTC 2015


On 6/2/15 2:35 AM, Owen DeLong wrote:
>> On Jun 2, 2015, at 5:49 AM, Matthew Kaufman <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
>>>> , Christopher Morrow writes:
>>>> On Mon, Jun 1, 2015 at 9:02 PM, Ca By <cb.list6 at gmail.com> wrote:
>>>>> On Monday, June 1, 2015, Mark Andrews <marka at isc.org> wrote:
>>>>>> In message
>>>>>> <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.

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

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.

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

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.

Yes, the results are marginally superior in the IPv6 case. Nobody cares.

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

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

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.

>> 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 sunbathing
> 	7.	Better network planning with sparse allocations

All of those are benefits for the network operator, not the end user.

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

> 	9.	Reduced complexity in:
> 			Proxies
> 			Applications
> 			Firewalls
> 			Logging
> 			Monitoring
> 			Audit
> 			Intrusion Detection
> 			Intrusion Prevention
> 			DDoS mitigation

Matters not to most home users.

Doesn't help corporate users because they also need all that for IPv4 
indefinitely.

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

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

> 	3.	Mobile IP

Remains to be seen if this matters.

> 	4.	A much cleaner implementation of IPSEC

Sure, but the IPv4 IPSEC seems to work just fine everywhere I've 
deployed it.

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

Matthew Kaufman




More information about the NANOG mailing list