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