How is NAT, which requires an intermediary (the NAT router/device) be configured and put in place in addition to the router, easier than IPv6 privacy addresses, where you just turn your computer on and let the router route?
IMHO this is caused more by broken protocols than NAT in general. There's no reason to have the VoIP packets delivered directly instead of them being routed (on the protocol level, not IP-routing) over a central VoIP gateway.
If the singalling protocols would allow for something like 'hi - my client $foo wants to talk to your client $bar. Please direct your response to me' and the other end would then send the packets with 'this is a packet from my client $bar to your client $foo - as you told me, I'm sending it to you', then there wouldn't be an issue - aside of a very small bit of additional latency and higher complexity of the gateway software.
If these client IDs are opaque, then the network topology stays hidden, but NAT would be completely irrelevant in between.
Now, personally, I'm really looking forward to having a /64 at the end of my cable modem. I will make splendid use of it and I will highly enjoy the additional uses I get from having my machines freely accessible to the internet.
On the other hand, people got good at understanding the feature set NAT provides and, thus, at configuring NAT gateways which also don't allow incoming connections per default.
That way, if I'm just a "normal user" and I buy myself a WiFi printer, I don't have to concern myself with configuring a firewall in order to ensure that it doesn't turn into an involuntary fax machine for example.
This could of course be solved by correctly configured firewalls on these crappy blue box routers, but how many years will it take them to reach "correctly"? Will they actually be configurable enough? Or would they just drop anything with a SYN bit set? How would these crappy firewalls deal with incoming UDP? Block it unconditionally (thus breaking VoIP even more)? Add "connection" tracking? In that case, why not just NAT?
I believe it's a good thing to have NAT back. Will I use it at home? Probably not. Will my parents use it at home? Likely. Would they be affected? Likely not as we already are used to deal with NATed clients.
Consumer routers have included a statefull firewall for years. The only difference for the end user will be instead of configuring port forwarding you'll modify a firewall rule. The interface would be exactly the same.
> If the singalling protocols would allow for something like 'hi - my client $foo wants to talk to your client $bar. Please direct your response to me' and the other end would then send the packets with 'this is a packet from my client $bar to your client $foo - as you told me, I'm sending it to you'
That's called routing, and routers are perfectly able to do that already, much better than some possibly whacky custom application level implementation. By your reasoning, there's no reason not to have HTTP proxies everywhere.
> I don't have to concern myself with configuring a firewall in order to ensure that it doesn't turn into an involuntary fax machine for example
This has to be the most ludicrous example I keep hearing again and again. I don't see what's different from the end-user point of view between "my gateway does NAT" vs "my gateway refuses unrelated incoming packets". Seriously, take your random Airport Extreme and it's one freaking checkbox in the IPv6 tab (which should and will, in the forecoming wide availability case, be on by default, just like current NAT).
Can we stop conflating NAT with the no-incoming filtering rule already, please? Let's look at the "hello, world" of Linux NATs example:
/sbin/iptables -t nat -A POSTROUTING -o eth0 -j MASQUERADE
/sbin/iptables -A FORWARD -i eth0 -o eth1 -m state --state RELATED,ESTABLISHED -j ACCEPT
/sbin/iptables -A FORWARD -i eth1 -o eth0 -j ACCEPT
First line is NAT and protects you from nothing by itself. It only happens that usually, the WAN side can't access the LAN side because LAN is on a non-wide routable IP range so packets may simply not be routed. And guess what, second and third line which do filtering, do not require NAT, and are perfectly available features on IPv6.
Protocol-wise, I always recommend IAX2 over SIP whenever possible. You can get phones, analog adapters and gateways in the iax variety, although the "serious business" (enterprise) manufacturers still sell SIP-only devices.
Watch out - almost no hardware got updated to randomise the callids or use the call tokens. That means if your phone can accept traffic from the internet, it's quite possible that anyone can hijack your connections, or at least ddos you.
Also it works with asterisk only, so it's not that useful in practice.
IPv6 privacy addresses are even more effective at this than NAT would be. Once the address is done being used, it goes away. You can still be tracked by your NAT'd address, as it will remain (relatively) static.
I don't know if this qualifies as legitimate, but Comcast has already decided to allocate /128 to customers with "directly connected CPE", which sounds like people who have just a cable modem and didn't pay for a "home gateway device". NAT could be useful if you plug that cable modem into a Linux box.
/64 is almost as bad and will lead to IPv6 NATing. What if you want multiple subnets (for example, a separate guest network, which some high-end consumer access points already tout as a selling point)? You don't want to sub-divide your /64 because then stateless auto configuration won't work. You could bridge multiple subnets with the same /64 prefix and use a layer 2 firewall (ebtables in Linux), but that's ugly. NAT is the only other option.
That said, Comcast did leave open the possibility for shorter prefixes, possibly as early as 2012, and they have already received quite a thrashing on their IPv6 beta tester forums for using /64 prefixes. So they might eventually do the right thing. I'm optimistic :-).
My opinion is that when you're dependent upon a (possibly recalcitrant) upstream provider, it's best to have means of dealing with whatever they give you.
If in some circumstance someone hands you only one address (or, one address too few, perhaps), you can still hang your own network behind it.
I think you're reading that wrong. The CPE (the cable modem itself) gets a /128, similar to the 10.0.0.0/8 address that it currently gets (that is not visible to the end user). They then go on to say that the home gateway gets a /64.
1. Topology hiding: the outside world only sees one interface not potentially the rest of your network. Though I doubt this offers and security worth speaking of, some people might want to keep that part of their arrangement when they migrate from IPv4 to IPv6.
2. Selective address forwarding: your router could send packets for a particular IPv6 address to different machines LAN-side depending on various things like where the packets came from WAN-side.
Of course there might be better ways to implement these things in the IPv6 spec already, I'm very behind the times in that respect and really must find time to read up on the subject (I purposely chose an ISP that fully supports IPv6 when I switched a few months ago, so I could try it all out when I have some time to play)
In the case of splitting traffic between two hosts depending on some factor, what if you want outgoing requests from those services to appear to come from the same place (so the two machine appear to be one interface for outgoing connections as well as incoming ones)?
You could use some sort of proxy services the the machines make the requests through (and the passes incoming requests back - you can avoid NAT in both directions that way) of course, but NAT seems (to me) to be a lighter solution for that use case.
I suspect that there will still exist some situations where you only have a /128 but need to run a network behind it. I realize I'm in a tiny minority here, but when I travel I bring a WRT54GL, plug it into the hotel's Internet connection, and then plug my devices into it on my own private subnet. I kinda doubt hotels will be routing /64 to their guests, so NAT will be the only option.
I hope that IPv6 NAT will be used rarely, but I'm grateful that I will have it in my toolbox for atypical situations where there are no other options.
Noob question: what exactly are a /128 and a /64 ? How many public IPs do they provide? Do you have a link so I can learn how to interpret those /xx?
Originally, I was under the impression that /n subnets have 2^n public IPs at there disposal. Could it be 2^(128-n) instead?
But either way, a /64 should be plenty. However, you suggest here http://news.ycombinator.com/item?id=3261500 that /64 are not so great. I wonder why. Is there something special going on?
A /64 is a 64-bit network mask on the 128bit ipv6 address, effectively leaving you with 64 bits for host addresses on that subnet. A /128 is a 128bit mask, leaving you with 0 extra bits (ie: a single host address).
2^(128-n) is the way it works for HOST addresses (no '-1', as in ipv4, as there is no broadcast address in ipv6, and 128-128=0, so 2^0=1, a single host address). 2^n is the way it works for networks/subnets, so a /128 leaves 2^128 possible networks, each with 2^0 hosts on them, while a /127 leaves 2^127 networks, each with 2^1 hosts on them.
A /64 is equal to the square of the entire existent ipv4 space (/32), and should be more than enough for any subnet anywhere, ever (it's roughly 18,446,744,073,709,551,615 IPs).
The issue is that many of the 'fundamental' protocols are built on assumptions that the smallest network will be a /64, and if your ISP gives you 1 /64, you can't have more than one 'network' on your end of the connection - even if you can have 18 quintillion addresses, they all have to be on the same subnet, so no fire-walling/etc. within your network.
This is a good explanation. To elaborate on the /64 network assumption, it has to do with stateless autoconfiguration, which is the way of configuring IPv6 addresses. An IPv6 address is comprised of a 64 bit prefix followed by a 64 bit "interface ID." The interface ID is inherent to an interface, and is derived from the MAC address, since it is guaranteed to be globally unique. When you bring up an interface, the OS listens for router advertisements which contain the 64 bit prefix. It takes this prefix and appends the interface ID to generate a full IPv6 address which is unique.
This is really cool because it means your computer will always have the same lower 64 bits no matter where you take it, and it can auto-discover the prefix without the complexities of DHCP. (Note that there were some concerns about tracking computers using the lower 64 bits, which led to the optional privacy extensions, under which the interface ID is randomly generated.)
However, the standard requires that the interface ID be 64 bits, so if you only have a /64 from your ISP you are, practically speaking, limited to 1 subnet. For this reason, I like to measure prefix lengths in terms of subnets rather than IPv6 addresses.
This makes me sad. People claiming that NAT provides some sort of privacy are misguided. There's also the option of the privacy extensions described in RFC 4941. This is even easier to enable in Linux, just add "net.ipv6.conf.<if>.use_tempaddr = 2" to /etc/sysctl.conf.
it is not about privacy, but more to do with providing one (of the many possible) path towards ipv6 migration. although a dual-stacking would be much better imho...
As for uses, how about: I live in a crappy country with a crappy monopolistic ISP that provides a crappy /128. No amount of purist theoretical pontification can fix this reality, which is guaranteed to happen for someone, regardless of the size of address space (say, because a business guy at $ISP thinks that will somehow force users to pay for extra subscriptions for their devices).
I for one am glad to see that if the time should arrive for me, Linux will support this out of the box, and that the greater madness by far, is to ignore a problem simply because you'd prefer that it not exist.
Besides all that, there is simple hacker value in having this kind of translation available. Great ideas are often borne of insanity.
And now every protocol needs to add NAT66 traversal to work around you. The lack of NAT66 is not ignoring a problem, it's trying to prevent a massive externality.
Omitting support for something that's technically possible is a dumb approach to fighting this (actually it's exactly equivalent to ignoring the problem). Instead the focus should be on making it less economical for protocol developers to violate layering and embed layer 3 addresses at layer 5, which is the reason "every protocol" needs special casing in the first place.
Accomplishing that could happen in various ways, e.g. promoting SCTP (which allows establishing new channels over the same initial connection), or introduction of an abstract naming service that would preserve layering (I'd be very surprised if something like this didn't already exist).
If your ISP gives you a single address and requires you to pay for more equipment, and you 'hide' with NAT, you're violating your terms of service and contract with that ISP.
Are you really suggesting that NAT66 be developed and deployed in order to help you violate your contract? Should the IETF find some way to help you get out of paying your bill too, or maybe stealing somebodies WiFi?
Can unthinking contract fundamentalism please die out already?
Sorry, contracts that ignore Schelling points are invalid. Concretely, it's called a demarcation point and everything past it is none of your business.
It's not unthinking fundamentalism, it's an understanding of the reality of the consumer internet market.
What does a focal point have to do with this? There's no absence of information on either side, unless you just chose to ignore what you signed.
The ISP is providing you connectivity to their network, generally through a heavily subsidized connection, for you to get 'Internet' access. Discriminating between business customers and home users is something that occurs in many industries (see wholesale/retail). You get a significantly reduced price as a home user for reduced connectivity options/flexibility.
If you want or need the flexibility, you pay more and get a neutral connection, where they will (generally) happily route you whatever you need and can justify.
It's not an invalid contract, and what was suggested is fraud at it's most basic level. I don't see how it's different from using a vehicle as a business vehicle, but claiming it's a personal use vehicle to your insurance company to get a cheaper rate.
The concept of a demarcation point is a focal point across all telcom contracts, akin to the concept of a property lines. Unless MA Bell is going to own all the equipment in your house, their responsibilities need to end at a clear point. To see the physical manifestation, open up the first layer (yours) of the phone box on the outside of a residence (and note that the second layer requires a different kind of screwdriver!)
Wholesale is cheaper because the overhead per unit is reduced. Business class connections give you a static IP and hopefully service commitments. These things have differences in what is actually being provided, not just a contract which says 'for business'. People work from home on consumer connections all the time, and there's probably a vestigal clause in those service contracts about 'not for business use'. And people declare business vehicles because they're cheaper as tax writeoffs (and then do use them personally as a perk of the business).
Telling the providers that I have one device hooked to their network (even though I have more devices hooked to that one) is separation of concerns, not fraud. Should they be able to bill me more based on my yearly income? That surely is every businesses dream - the ultimate in price descrimination. The only thing the carrier should be concerned about is the quantity and size of packets I send through them. If anything is fraud, it's the carriers advertising 'unlimited internet', then hassling you for using it too much, and mangling your packets in direct contradiction of the seminal End-to-End paper.
I completely agree with you on the false advertising.
That said, I think it's disingenuous to compare a residential network connection with a commercial telecom contract, as they provide fundamentally different things. The cross connect or peering contract you sign at Equinix is radically different in every way from the service agreement you establish with a residential vendor.
I disagree with residential connections having a separation of concerns. Cox, Comcast, et. al. ALL provide desktop technical support to get PCs, laptops, ipads, etc. on the Internets. In many cases, exactly like Ma Bell, they own everything but your PC, and provide configuration assistance and technical support for even that.
Now, I'm not arguing this is a positive thing, just that it is the reality of the situation in the vast majority of cases.
You do NOT have a contract that says 'the demarc is X, with a commit of N Mbps' or the like, you have a contract which says 'you can use this connection and our equipment, and we'll support you, for one device, for this type of usage'. Like it or not, you're not buying a neutral communication line - hell, in many cases, the cable or fiber plant isn't even required to be open to competing service like a LEC has to be.
You're conflating the internet access that ISPs sell with the PC technical support they're forced to provide so granny doesn't cancel when her ethernet cable gets unplugged. Of course the bundled PC support won't troubleshoot your 20 device home network. For technical users, PC technical support is just an annoying hurdle to clear in order to fix a connectivity problem.
I was comparing residential connections to small business connections, which only differ in static IPs and contractual guarantees. Most people engaged in home business activities do not have these connections.
You're engaging in 'contract fundamentalism' because you're bringing up all these vestigial clauses inserted by the ISP's legal compiler into their document-that-nobody-reads while ignoring the actual contract, which is determined by the understanding between parties. As far as any user is concerned, the only actions of theirs that matter are whether they pay their bill and whether they set off the ISP's hassle-this-user system. I'm sure many ISPs have clauses about multiple devices, running "servers", piracy, business use, wifi, swearing/offending people, etc. But the only time they even come close to mattering is when the ISP is the target of a legal attack.
What you call fundamentalism, I call 'rule of law'. Nobody cares about you doing 65 in a 55 either, until you either get pulled over or hit somebody. Then all of a sudden that 'understanding' becomes critical.
We'll agree to disagree - enjoy your frustration and lack of understanding of how these things work.
I think you've got the lack of understanding - people adopted internet gateways long before ISPs 'allowed' them to.
Contract fundamentalism is orthogonal to the rule of law. Fundamentalism presumes that following the base rules of the system (unbounded contracts) is more important than following the behavioral rules (actual contract law).
Without looking at the code to see what's going on, I'm wondering if this patch is actually about IPv6 NAPT, ie. protocol translation between IPv4 and IPv6. If it's really NAT, like IPv4 NAT, then has there been an RFC on this? I can't seem to find it.
There wasn't an RFC for NAT44 either, because the IETF didn't want to encourage it. Realizing how that worked out last time, the debate is raging about NAT66 specification.
Well, even if NAT went away, you would still have to contend with stateful firewalls (i.e. those that only allow inbound packets from established connections).
This article explains it pretty well (mainly on the second page):
It depends where firewalls are implemented in x years time. (In the context of the home) At the moment, people rely on their routers to provide a decent firewall rather than configuring their computers properly.
That being said... if firewalls "move" onto computers, it is "easy" to open ports.
Yeah, good point. Personally, I'm torn on whether I would ever want to give up my whole-network firewall, especially when there's a wireless network in the mix. My servers' ssh logs are choke full of brute force attempts. I would hate to waste my wireless bandwidth and battery life on such attack attempts. On the other hand, IPv6 address space will be so sparse that maybe such attacks won't be practical...
What makes solutions like NAT* and IPv6 necessary is the concept of the "backbone". In spite of all its benefits, it also has tradeoffs too.
When everything has to pass through centralised "core" routers for enormous segments of the network, it limits how we can work with addresses.
It forces us to allocate addresses in blocks (the larger ones within which most of the individual addresses remain unused). And it creates problematically large routing tables for those "core' routers.
As with everything, there are both costs and benefits to doing things this way. There are always tradeoffs with any approach, whether it is centralised or decentralised. So arguments can go on to infinity about the "best" way. There is no such thing. There are just different alternatives, each with their own costs and benefits. And there's human consensus.
And there are the inevitable workarounds, some of them pure "hacks".
NAT* and IPv6 are a natural result of having a "backbone", "core routers", gigantic ever-growing routing tables and large address allocation minimums.
The more I hear about IPv6 (these comments in particular), the more it seems like it contains many solutions to non-problems. Yes, IPv4's 32 bit address space is basically full, and upgrading that is a good thing.
But honestly, burning 64 bits of address space for a redundant global identifier just so "nat+dhcp" are only half as complicated? And then needing privacy extensions to keep the uuid from leaking out? All while doing nothing to solve the problem that caused NAT to spring up in the first place.
On the surface, "no NAT" sounds like a reasonable goal, but ignores the realities of what NAT is actually used for - keeping your network your business. How long until consumer providers offer different tiers of plans based on number of devices that can be connected, and smart users are back to NAT anyway? The proper solution to NAT problems is at layer 4 - a standard way of making connections from the outside to a device inside based on some kind of onion address, where the upstream can only see the outer part.
62 comments
[ 2.4 ms ] story [ 89.2 ms ] threadNo, please don't tell me about socks or other proxy solutions.
And yes, NAT is bad, ugly and from hell.
== making VoIP deployment hard/impossible depending on your router and phone model. :(
If the singalling protocols would allow for something like 'hi - my client $foo wants to talk to your client $bar. Please direct your response to me' and the other end would then send the packets with 'this is a packet from my client $bar to your client $foo - as you told me, I'm sending it to you', then there wouldn't be an issue - aside of a very small bit of additional latency and higher complexity of the gateway software.
If these client IDs are opaque, then the network topology stays hidden, but NAT would be completely irrelevant in between.
Now, personally, I'm really looking forward to having a /64 at the end of my cable modem. I will make splendid use of it and I will highly enjoy the additional uses I get from having my machines freely accessible to the internet.
On the other hand, people got good at understanding the feature set NAT provides and, thus, at configuring NAT gateways which also don't allow incoming connections per default.
That way, if I'm just a "normal user" and I buy myself a WiFi printer, I don't have to concern myself with configuring a firewall in order to ensure that it doesn't turn into an involuntary fax machine for example.
This could of course be solved by correctly configured firewalls on these crappy blue box routers, but how many years will it take them to reach "correctly"? Will they actually be configurable enough? Or would they just drop anything with a SYN bit set? How would these crappy firewalls deal with incoming UDP? Block it unconditionally (thus breaking VoIP even more)? Add "connection" tracking? In that case, why not just NAT?
I believe it's a good thing to have NAT back. Will I use it at home? Probably not. Will my parents use it at home? Likely. Would they be affected? Likely not as we already are used to deal with NATed clients.
That's called routing, and routers are perfectly able to do that already, much better than some possibly whacky custom application level implementation. By your reasoning, there's no reason not to have HTTP proxies everywhere.
> I don't have to concern myself with configuring a firewall in order to ensure that it doesn't turn into an involuntary fax machine for example
This has to be the most ludicrous example I keep hearing again and again. I don't see what's different from the end-user point of view between "my gateway does NAT" vs "my gateway refuses unrelated incoming packets". Seriously, take your random Airport Extreme and it's one freaking checkbox in the IPv6 tab (which should and will, in the forecoming wide availability case, be on by default, just like current NAT).
Can we stop conflating NAT with the no-incoming filtering rule already, please? Let's look at the "hello, world" of Linux NATs example:
First line is NAT and protects you from nothing by itself. It only happens that usually, the WAN side can't access the LAN side because LAN is on a non-wide routable IP range so packets may simply not be routed. And guess what, second and third line which do filtering, do not require NAT, and are perfectly available features on IPv6.Also it works with asterisk only, so it's not that useful in practice.
http://blog.comcast.com/2011/11/ipv6-deployment-technology.h...
That said, Comcast did leave open the possibility for shorter prefixes, possibly as early as 2012, and they have already received quite a thrashing on their IPv6 beta tester forums for using /64 prefixes. So they might eventually do the right thing. I'm optimistic :-).
If in some circumstance someone hands you only one address (or, one address too few, perhaps), you can still hang your own network behind it.
"we're used to the false sense of security from NAT and we like it"
"we feel like NAT protects our privacy ('but we use gmail')"
"its easier to setup than ndp proxying ('because i never heard of ndp before')"
yada yada :-)
1. Topology hiding: the outside world only sees one interface not potentially the rest of your network. Though I doubt this offers and security worth speaking of, some people might want to keep that part of their arrangement when they migrate from IPv4 to IPv6.
2. Selective address forwarding: your router could send packets for a particular IPv6 address to different machines LAN-side depending on various things like where the packets came from WAN-side.
Of course there might be better ways to implement these things in the IPv6 spec already, I'm very behind the times in that respect and really must find time to read up on the subject (I purposely chose an ISP that fully supports IPv6 when I switched a few months ago, so I could try it all out when I have some time to play)
You could use some sort of proxy services the the machines make the requests through (and the passes incoming requests back - you can avoid NAT in both directions that way) of course, but NAT seems (to me) to be a lighter solution for that use case.
I hope that IPv6 NAT will be used rarely, but I'm grateful that I will have it in my toolbox for atypical situations where there are no other options.
Originally, I was under the impression that /n subnets have 2^n public IPs at there disposal. Could it be 2^(128-n) instead?
But either way, a /64 should be plenty. However, you suggest here http://news.ycombinator.com/item?id=3261500 that /64 are not so great. I wonder why. Is there something special going on?
2^(128-n) is the way it works for HOST addresses (no '-1', as in ipv4, as there is no broadcast address in ipv6, and 128-128=0, so 2^0=1, a single host address). 2^n is the way it works for networks/subnets, so a /128 leaves 2^128 possible networks, each with 2^0 hosts on them, while a /127 leaves 2^127 networks, each with 2^1 hosts on them.
A /64 is equal to the square of the entire existent ipv4 space (/32), and should be more than enough for any subnet anywhere, ever (it's roughly 18,446,744,073,709,551,615 IPs).
The issue is that many of the 'fundamental' protocols are built on assumptions that the smallest network will be a /64, and if your ISP gives you 1 /64, you can't have more than one 'network' on your end of the connection - even if you can have 18 quintillion addresses, they all have to be on the same subnet, so no fire-walling/etc. within your network.
This is really cool because it means your computer will always have the same lower 64 bits no matter where you take it, and it can auto-discover the prefix without the complexities of DHCP. (Note that there were some concerns about tracking computers using the lower 64 bits, which led to the optional privacy extensions, under which the interface ID is randomly generated.)
However, the standard requires that the interface ID be 64 bits, so if you only have a /64 from your ISP you are, practically speaking, limited to 1 subnet. For this reason, I like to measure prefix lengths in terms of subnets rather than IPv6 addresses.
What a horrible assumption to tack on though - it should have been codified in the v6 RFC if that's how it's going to work.
I for one am glad to see that if the time should arrive for me, Linux will support this out of the box, and that the greater madness by far, is to ignore a problem simply because you'd prefer that it not exist.
Besides all that, there is simple hacker value in having this kind of translation available. Great ideas are often borne of insanity.
Accomplishing that could happen in various ways, e.g. promoting SCTP (which allows establishing new channels over the same initial connection), or introduction of an abstract naming service that would preserve layering (I'd be very surprised if something like this didn't already exist).
Are you really suggesting that NAT66 be developed and deployed in order to help you violate your contract? Should the IETF find some way to help you get out of paying your bill too, or maybe stealing somebodies WiFi?
Sorry, contracts that ignore Schelling points are invalid. Concretely, it's called a demarcation point and everything past it is none of your business.
What does a focal point have to do with this? There's no absence of information on either side, unless you just chose to ignore what you signed.
The ISP is providing you connectivity to their network, generally through a heavily subsidized connection, for you to get 'Internet' access. Discriminating between business customers and home users is something that occurs in many industries (see wholesale/retail). You get a significantly reduced price as a home user for reduced connectivity options/flexibility.
If you want or need the flexibility, you pay more and get a neutral connection, where they will (generally) happily route you whatever you need and can justify.
It's not an invalid contract, and what was suggested is fraud at it's most basic level. I don't see how it's different from using a vehicle as a business vehicle, but claiming it's a personal use vehicle to your insurance company to get a cheaper rate.
Wholesale is cheaper because the overhead per unit is reduced. Business class connections give you a static IP and hopefully service commitments. These things have differences in what is actually being provided, not just a contract which says 'for business'. People work from home on consumer connections all the time, and there's probably a vestigal clause in those service contracts about 'not for business use'. And people declare business vehicles because they're cheaper as tax writeoffs (and then do use them personally as a perk of the business).
Telling the providers that I have one device hooked to their network (even though I have more devices hooked to that one) is separation of concerns, not fraud. Should they be able to bill me more based on my yearly income? That surely is every businesses dream - the ultimate in price descrimination. The only thing the carrier should be concerned about is the quantity and size of packets I send through them. If anything is fraud, it's the carriers advertising 'unlimited internet', then hassling you for using it too much, and mangling your packets in direct contradiction of the seminal End-to-End paper.
That said, I think it's disingenuous to compare a residential network connection with a commercial telecom contract, as they provide fundamentally different things. The cross connect or peering contract you sign at Equinix is radically different in every way from the service agreement you establish with a residential vendor.
I disagree with residential connections having a separation of concerns. Cox, Comcast, et. al. ALL provide desktop technical support to get PCs, laptops, ipads, etc. on the Internets. In many cases, exactly like Ma Bell, they own everything but your PC, and provide configuration assistance and technical support for even that.
Now, I'm not arguing this is a positive thing, just that it is the reality of the situation in the vast majority of cases.
You do NOT have a contract that says 'the demarc is X, with a commit of N Mbps' or the like, you have a contract which says 'you can use this connection and our equipment, and we'll support you, for one device, for this type of usage'. Like it or not, you're not buying a neutral communication line - hell, in many cases, the cable or fiber plant isn't even required to be open to competing service like a LEC has to be.
I was comparing residential connections to small business connections, which only differ in static IPs and contractual guarantees. Most people engaged in home business activities do not have these connections.
You're engaging in 'contract fundamentalism' because you're bringing up all these vestigial clauses inserted by the ISP's legal compiler into their document-that-nobody-reads while ignoring the actual contract, which is determined by the understanding between parties. As far as any user is concerned, the only actions of theirs that matter are whether they pay their bill and whether they set off the ISP's hassle-this-user system. I'm sure many ISPs have clauses about multiple devices, running "servers", piracy, business use, wifi, swearing/offending people, etc. But the only time they even come close to mattering is when the ISP is the target of a legal attack.
We'll agree to disagree - enjoy your frustration and lack of understanding of how these things work.
Contract fundamentalism is orthogonal to the rule of law. Fundamentalism presumes that following the base rules of the system (unbounded contracts) is more important than following the behavioral rules (actual contract law).
http://en.wikipedia.org/wiki/Teredo_tunneling
This article explains it pretty well (mainly on the second page):
http://arstechnica.com/hardware/news/2007/05/ipv6-firewall-m...
That being said... if firewalls "move" onto computers, it is "easy" to open ports.
When everything has to pass through centralised "core" routers for enormous segments of the network, it limits how we can work with addresses.
It forces us to allocate addresses in blocks (the larger ones within which most of the individual addresses remain unused). And it creates problematically large routing tables for those "core' routers.
As with everything, there are both costs and benefits to doing things this way. There are always tradeoffs with any approach, whether it is centralised or decentralised. So arguments can go on to infinity about the "best" way. There is no such thing. There are just different alternatives, each with their own costs and benefits. And there's human consensus.
And there are the inevitable workarounds, some of them pure "hacks".
NAT* and IPv6 are a natural result of having a "backbone", "core routers", gigantic ever-growing routing tables and large address allocation minimums.
But honestly, burning 64 bits of address space for a redundant global identifier just so "nat+dhcp" are only half as complicated? And then needing privacy extensions to keep the uuid from leaking out? All while doing nothing to solve the problem that caused NAT to spring up in the first place.
On the surface, "no NAT" sounds like a reasonable goal, but ignores the realities of what NAT is actually used for - keeping your network your business. How long until consumer providers offer different tiers of plans based on number of devices that can be connected, and smart users are back to NAT anyway? The proper solution to NAT problems is at layer 4 - a standard way of making connections from the outside to a device inside based on some kind of onion address, where the upstream can only see the outer part.