>>> >>> 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.
SSH, VNC, HTTP, HTTPs, LPD, whatever… Pick your service. SSH was just an example. > 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. I’d argue that SSH is several thousand, not a few hundred. In any case, I suppose you can make the argument that only a few people are trying to access their home network resources remotely other than via some sort of proxy/rendezvous service. However, I would argue that such services exist solely to provide a workaround for the deficiencies in the network introduced by NAT. Get rid of the stupid NAT and you no longer need such services. Even if you want to consider all of those services, the reality is that their codebases could be substantially improved and simplified as well as their security posture improved by eliminating NAT. > 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. Sure… They all live like sheeple not even realizing that they’ve been handed a deficient and limited internet incapable of living up to its potential. They remain blissfully ignorant that they are a rat in a digital cage because they are unaware of life outside the cage. What’s your point? Are you claiming this makes cages a good thing? Are you claiming that since the rats are not demanding to be let out of their cages, we shouldn’t seek to create an environment where cages are not needed? >> 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. This simply isn’t true. To the limited extent that it is true, the reality is that it is a consequence of the limitations of IPv4 and NAT rather than a state that anyone other than you ever really considered desirable. >>>> 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. That’s an awful lot of icky overhead vs. the simple clean solution of permitting desired traffic. I suspect that in the IPv6 world, eventually, rather than silly hacks like UPnP, STUN, etc., we will see, instead, standardized APIs for authenticating with the firewall and automated mechanisms for adding permission after authentication. >>> 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. OK, half a dozen Video Game consoles or whatever other service you want to imagine. Just because the standard way to do things today is with silly workarounds required by the lack of address transparency created by NAT, that doesn’t mean we have to continue to do things so badly in the future. >> 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. Right… Once per service or once per host per service worst case. Eventually, there will be APIs for this, but today, it’s manual. It’s manual today because being able to make use of it makes me an outlier. In the future, with address transparency, being able to deploy services will not make you a 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. Who needs to edit BIND config file to put something in DNS? Sure, you can, and I do, but there are at least a dozen web-based DNS providers where you can host a zone file for free and manage it through a web GUI. >>>> 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. I’m living in a world where at least some people want to be peers rather than mere consumers. A world where the thought of being able to make phone calls without a phone company has appeal to at least some people. A world where peer to peer information and communication is considered a good and healthy thing. Sure, if you want to live in the ABC/DIsney/Comcast/NBC/Micr0$0ft fantasy world where people are mindless subjects of their corporate overlords, strictly consuming information and only that which has the approval of said corporate overlords, then the path you advocate makes perfect sense. >>> 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. Try configuring port forwarding for a household where there is an Xbox One and a PS/3. Not all that uncommon a scenario. Common enough that both Micr0$0ft and Sony technical support have stock scripts for telling you which home gateways you can buy that will work and how to configure them. > You have 20 SSH hosts. You're an outlier, and so yes, in IPv6 there's less > typing. Picking apart the specifics of a random example doesn’t actually make the general situation less relevant. > 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. On this, we can agree. >>>> 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 <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? If I were to answer strictly the question as asked, yes. However, no, but let’s compare the costs… Assuming a 3 year life-cycle on that piece of shit you bought at Best Buy... Logmein Pro for Users (cheapest alternative I could find) $99/year One-time configuration of firewall: $PIZZA for local computer whiz kid every 3 years. I’d argue that the need to configure the firewall is a very cost effective alternative with a less than one month break even. Over a 20 year timeframe, you’ve gone from $1980 (Logmein) to $105 (assuming you pay as much as $15 per pizza which is high). >>>> 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. It wasn’t hard because there was address transparency via IPv6 and a simple permit was all that was needed. No port forwarding, no mapping, just a “Allow inbound packets to port XX TCP”. >>> 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 disagree. I think 3, especially, will be a growing fraction of users as address transparency becomes the norm and developers start to make use of it. >> 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. Today. We’re talking about the future. I’m talking about the advantages of moving forward. You’re making excuses for remaining mired in the past. >> Note, the original item 6 (corrected above) was autocorrected from >> subnetting to sunbathing. I have restored it to subnetting. >> > > I preferred sunbathing. Please, go make yourself as crispy as you desire. Fortunately, for you, the sun is not behind a NAT firewall. >>>> 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. But IPv6 firewall traversal isn’t necessary. >> 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. Yes, having two stacks in the box takes marginally more flash than one. According to http://www.ipso-alliance.org/wp-content/media/lightweight_os.pdf <http://www.ipso-alliance.org/wp-content/media/lightweight_os.pdf>, an IPv6 stack shouldn’t require more than about 15k of flash. These days, that ’s not a lot even in a small ARM Cortex M4. >>>> 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. No, most users are suffering in silence because they have no idea where to go to get their problems solved. Most users haven’t experienced a working internet, so the current level of dysfunction is normal to them and they tolerate it because they have no idea that there are better alternatives available. >>> 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. Sure… I didn’t say reducing IPv4 utilization would eliminate IPv4 issues. I said it would reduce them. However, i’m confused… If nobody has problems with IPv4 as you describe above, why are you now complaining about the number of IPv4 tickets you get. Seems you want to have your cake and eat it too here. >>>> 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’ll put $100 on it. >>>> 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. Nope… I’m very proud to say that there are NO Micr0$0ft boxes in my house. >>>> 3. Mobile IP >>> >>> Remains to be seen if this matters. >> >> I’ve found it quite useful as have several other people I know. >> > > Outlier. This seems be your answer to anything that you don’t like. Outlier or not, the protocol is useful. >>>> 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. The security provided by IPv4 IPSEC and IPv6 IPSEC is nearly identical as well. The difference is the difficulty of use. >>>> 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. Not really… If policy permits you to pass the firewall, then you can pass without tricks. If policy doesn’t allow it, you may be able to traverse the firewall with tricks, but then the question becomes should you? True, if you are the one determining the policy, there is that pesky step of expressing the policy to the firewall. In your preferred world, this is done by adding substantial overhead to each and every piece of software and creating profound limitations on how you can use your software. In my preferred world, this is done by configuring the policy in the firewall once and simplifying the application code and increasing the probability that the security policy enforced is the security policy intended. I guess to each their own. Owen
