Under Communism, man exploits man, and they censor the Internet.
I think that is not communism but rather corruption. I suspect communism might be so prone to get corrupted, that many people cannot tell the difference between communism and corruption.
"utilizing multiple IPv6 addresses per interface inside your LAN"
Have you ever actually tried that
Not on my own LAN. But I have been using my laptop on LANs which were configured like that.
with increasing numbers of per-interface addresses?
Who says the number has to increase? Each interface should only have one static and a handful of temporary addresses. The temporary addresses are removed at the same rate at which they are added.
increasing numbers of AAAA RRs?
You don't put temporary addresses in your AAAA records. If something need a AAAA record, you use a static address for that. So it is static address on the server side and temporary address on the client side.
NAT66, adjusting only the high order ("prefix") bytes at the external gateway is vastly more simple
Sure that is the simplest form of NAT, which you can possibly do. However it does not give you any of the anonymity or topology hiding, which is often given as motivations for using NAT in the first place.
Yes, you can avoid renumbering that way. But there are drawbacks as well. You will break any protocol, which is not strictly a client-server protocol. And you will break any algorithm, which looks at assigned addresses and behaves differently depending on whether you have a routable IP address or not. Is this breakage of protocols you may be using on a daily basis really worth it, in order to avoid a bit of extra work in the rare case, where you may have to renumber your network?
the only requirement for NAT-friendliness is that the host implementations do not tell higher layer protocols the truth about what's in the high order bytes.
How would you make anything but a strictly client-server protocol work with that requirement? Let's keep it simple and consider just the following scenario. Two clients (which could be both on the same LAN or on separate LANs far from each other) each resolve the IP address of a single server. Each client contact the server and indicate they want to communicate with each other. The server informs each client about the address of the other, such that a direct communication channel can be established between the clients.
Linux IP Tables has all kinds of cool stuff to overcome that issue.
With lots of configuration, you can overcome some of the problems. But you'll never get it working as smooth as it would without NAT.
B/c neither device can host a server
And the reason for that is NAT. Also, the definition of a server is unclear in the first place. Not all protocols are client-server protocols. Do you call every listening end of a TCP connection a server? Historically some protocols including FTP and X11 have been listening for connections on the client device. And peer-to-peer protocols need to transfer data between two devices, neither of which would be considered a server. In many cases UDP has been used in scenarios, where TCP would have been better suited. The only reason being, that it is easier to punch holes in a NAT, if you are using UDP than if you are using TCP.
You obviously do not understand NAT very well.
I have written a NAT implementation from scratch. What background do you have, which gives you more knowledge about NAT than writing a NAT implementation from scratch?
A correct design would be to use a service that you can query quickly using disparate network connections
Such a design is never going to work. What are you going to do once you face the requirement of notifying the user about an incoming message within a five second deadline, while your power budget does not allow you to send packets more frequently than once every 30 seconds during idle time?
that is all handled transparently by the network, and the software should be able to manage keeping itself going even as its IP address changes
With current network design, changing the IP address is not going to be transparent to the application. Change of IP address will cause ongoing communication to break (or even worse - stall). The best you can do is for the application to notice the IP change and establish a new connection. That will however only work reliably in the absence of NAT. You can do it more transparently to the application, if you are using MPTCP. But that doesn't change any of my points, it just moves some of the logic one layer down the stack.
NAT also has a lot of benefits - including privacy.
Another common misconception. All of the perceived privacy you would get from using NAT can be achieved from IPv6 privacy addresses. You get additional privacy that way, because moving from IPv4 to IPv6 eliminates the leaks you'd otherwise get from the IPID field in the IPv4 header.
You seem to believe that everyone shares your opinion about the "good"ness of the results of the current extremely widespread adoption of NAT44.
No. I am perfectly aware that lots of people disagree. However so far none of the people who disagree with my view have shown me a technically sound reasoning for their position. Generally you can do better by simply using a firewall, that passes or rejects packets without mangling them, combined with utilizing multiple IPv6 addresses per interface inside your LAN. Those two methods cover all of the perceived advantages of NAT44, which I remember having heard about.
Except of course for the problems of getting legacy IPv4 hosts to talk to each
I was explaining why leaving NAT out of the IPv6 specification was a sensible decision. The question was whether native IPv6 without NAT or NAT66 was a better choice. Now you bring up the challenge of getting two legacy IPv4 hosts to talk to communicate with each other. Which technology is better for that purpose NAT66 or IPv6 without NAT? The answer is, neither will do that particular job. So that is by no means an argument in favor of NAT66.
Except of course for the problems of getting legacy IPv4 hosts to talk to each other in the presence of site renumbering or deliberate site-local topology information hiding.
As a matter of fact, I have developed a system, which does all of that. On the edge between the LAN and the internet backbone, there is one or more gateways translating between IPv4 and IPv6. Whether the other end of the connection is using translation as well is transparent to the hosts. With this system it is possible to communicate between two LANs using IPv4 only through an IPv6 backbone. Topology hiding is achieved through an optional encryption of addresses on the edge. Using IPv6 across the backbone eliminates a bunch of the scaling issues a traditional NAT44 suffers from. Finally I support automatic fallback to tunnelling in case the native IPv6 link goes down.
I really do not get your point and suspect you are merely looking for an argument.
You are the one who hasn't made any constructive suggestions on how to solve the problem.
The polling interval or other way of checking if the connection is still alive
First of all, keepalive checks is not the goal. It is merely a means to workaround obstacles getting in the way of solving the real problem. The goal is to get a notification to the phone, when it needs attention. The deadline to get the notification there is on the order of five seconds, possibly less. At the same time there is no power budget to send packets every five seconds, even sending a packet every minute may be too power consuming.
How do you propose solving that problem? It is quite clear that it can only be achieve by having the phone passively listening for traffic.
should obviously depend on what the application needs instead of some arbitrary number imposed from elsewhere.
And which polling interval do you suggest using if the needs are: 1: Application must get notified no later than five seconds after a certain event happening in the cloud. 2: While the application is idle, the radio transmitter on the phone must not be activated more frequently than once every five minutes, to preserve battery power.
If you choose to use polling to solve that problem, you must choose an interval which is shorter than five seconds and longer than five minutes. That is impossible. Opening a TCP connection and waiting for a reply will however work.
Open connections without a way to check if the other end is still there are a bad idea on networks that frequently drop out.
That is not a problem. If the network connection disappears temporarily, then notifications cannot be received while the connection is gone. Users can understand, that they cannot receive notifications while the connection is gone, and that no protocol changes can make that happen. Once the network connection has been re-established, there are two possibilities. Either the device still has the same IP address, in which case the TCP connection is still open. Or the device got a new IP address, in which case the application can get notified about the IP change and take necessary actions to establish a new connection.
The only problem left to consider in case of temporary loss of network connection is the following: The phone may lose network connection temporarily and not realize this, while the connection is gone the server decides the TCP connection needs to be closed and sends a FIN. Due to the FIN getting lost, the FIN gets retransmitted a few times. Eventually the server gives up discards state and stops sending further FIN packets.
This is the situation TCP keepalive is mainly designed to deal with. Additionally there is the possibility that the server crashed and got rebooted and thereby lost all TCP connections without having a chance to send a FIN. Use TCP keepalive to ensure both of those situations are noticed by the application. If you just use keepalives for this, you don't need frequent keepalives, because this is not in the critical path for receiving notifications about events in the cloud.
The IPng selection process that the IETF used ultimately *deliberately* chose to be incompatible with NAT for architectural reasons
That is utter bullshit. If you look at the actual IPv4 protocol versus the actual IPv6 protocol, you'll find IPv4 to be slightly more hostile towards NAT than IPv6 is.
The mandatory IPID field in the IPv4 header is almost impossible to handle in an IPv4 NAT without violating the IPv4 spec. And RFC1918 addresses are prone to have collisions.
It was deliberately chosen not to make NAT part of the IPv6 standard. But NAT was not part of the IPv4 standard either. Some later RFCs standardize various aspects of NAT44, but as far as I can tell actual implementations of NAT44 predate the standards, and implementations made after the standards don't follow the standards anyway.
Nothing in the RFCs was stopping IPv6 implementations from including NAT66. What stopped them from including it was common sense. People who actually know how the networks work realized that nothing good came from NAT44, and that's why it wasn't implemented for IPv6. For every problem that people have applied NAT44 to, IPv6 offers a better solution, which does not involve NAT.
Polling is even worse than keepalives. Polling is a waste of resources. Let's say I have a chat client, and need to get notified about incoming chat messages in a timely fashion. A reasonable polling frequency for that would probably be around once every five seconds. For each poll I will exchange three packets for a TCP handshake, two packets for application level query, and four packets to tear down the TCP connection. That is a total of nine packets every five seconds.
There could be hours between the time where I receive a chat message. But that does not mean I can wait hours to be notified about one arriving.
If instead the client open a connection and tell the server to notify me, once a message arrives, the connection could exchange the following packets. Three packets for TCP handshake, three packets for application level request, application level ACK and TCP level ACK of the application level ACK. A total of six packets after which the connection goes idle. Once a chat message arrives there could be an application level notification followed by four packets to tear down the connection. That is a total of eleven packets for the entire duration of this connection, which could last for hours.
Eleven packets in the span of hours seem a lot more efficient than nine packets every five seconds. And the open connection can even give me a notification in less than a second compared to the average delay of 2½ second I'd get from polling every five seconds.
makes me think migrating to IPv6 will require legislative mandate.
I have had that feeling for more than a decade. Unfortunately, legislators don't understand how the internet works. I guess the majority of legislators have never seen an internet connection without NAT.
There's plenty of ipv4 addresses around, maybe time for operator change?
No other operator could deliver connectivity at my address. Besides I have no guarantee another operator would do any better. And none of them are offering IPv6, which would otherwise be sufficient reason for me to switch right away.
Can you shorten more than one block in an address?
Nope. That is not permitted (for exactly the reason you mentioned).
For example, "fe80:0000:0000:0000:0025:0000:0000:0001". Would that become "fe80::0025::0001"? Wouldn't this be a problem then if you try to shorten "fe80:0000:0000:0025:0000:0000:0000:0001" and get the same result "fe80::0025::0001"?
That's why you can't shorten two blocks. One might argue that as long as each shortened group was shortened by the same amount, it could be expanded unambiguously. But that would have added complexity, for very little gain. So instead the standard says you can only shorten one block.
Some interpretations go further and says you must shorten the longest run of zeros, and only if it contains at least two zero blocks. And if there are two blocks of identical length you must shorten a particular one. Those more strict rules are relevant if you absolutely need a canonical representation of an IPv6 address. But some implementations have taken this a step too far and reject IP addresses, if the shorting does not follow these rules exactly. For example IPv6 addresses has been rejected due to having used shorting when there was only a single block of zeros.
What was the rationale for making the IPV6 address space so huge in the first place? Seems like simply going to 40 or 48 bits would have been sufficient for decades if not longer.
The rationale was roughly this. We want to get rid of the complexity by having variable length network prefixes. So the address would consist of a fixed length field to address a network and another fixed length field to address a device on that network.
For the first part we knew 32 bits was insufficient, and we don't want the administrative overhead of an extremely large HD-ratio, so go for a more relaxed HD-ratio of 80%. If we have 45 bits and assume an HD-ratio of 80% we get the equivalent of 36 bits efficiently used.
For the second part we wanted to be able to embed a full MAC address, so we need at least 48 bits.
To keep things simple, each part was rounded up to 64 bits.
We already now see situations, where the size of IPv6 addresses is a shortcoming. First case is in tunnel protocols. First there was 6to4, which embed an IPv4 address right in the middle of the upper 64 bits (the network part). This worked great from an addressing perspective. A/16 of IPv6 address space allocated for a transition mechanism isn't bad. And 16 bits for subnetting is sufficient for the size of network you typically have behind an IPv4 address. But then people realized that somebody has been deploying NAT on the IPv4 network. So another tunnelling protocol is needed. Along comes Teredo. Teredo embeds two IPv4 addresses and a port number into the IPv6 address. That's 80 bits. There is no way you are going to embed all of that into the top 64 bits of an IPv6 address and still have room to spare. In fact Teredo would probably have benefited from having the server port number embedded in the IPv6 address as well, but there just wasn't room for that. If you would have wanted to combine the benefits of 6to4 with those of Teredo into a single protocol, you would have needed 64 bits more in the IPv6 address, that is 192 bits total.
There is also the desire to put cryptographic information inside an IP address. With IPv4 this idea was more or less unthinkable, because 32 bits of security is just not enough for anything. With IPv6 it starts to become possible. But you can't use the entire IPv6 address for only cryptographic data, you absolutely need some bits at the start to identify the class of address. And some bits left over to identify network and device would be nice. You can meaningfully embed cryptographic information inside an IPv6 address. But you don't get to do much else. If you wanted to embed say a SHA1 hash plus some other information in an IP address, you are soon going to need 256 bits.
Consider all the things I mentioned and you might find a use for even 512 address bits. But at this time it is too late to change the size of the IPv6 address. Anybody who want to propose an alternative to IPv6 have to remember that in order to prove that a solution does solve all the shortcomings of IPv6, you have to get it standardized, implemented and deployed before February 2011.
But actually, the users of those services pay more to avoid converting the infrastructure. (Although, rather than a direct monetary cost, it often comes in the form of things like bugs or missing features that could've been developed/fixed if developer time wasn't being spent dealing with NAT.)
Plus the developer has to spend time fixing bugs in the code working around the NAT induced problems. I think the Skype outage a few years back is the most spectacular example of how bad it can go.
(proper) CGNAT uses 100.64.0.0/10, so it doesn't collide with RFC1918 reserved addresses.
That introduces other problems. Lots of software will look at the assigned address to figure out if it has a public address or is located behind a NAT. If it is behind a NAT it will make certain workarounds, if it has a public address it can ignore most of that and do things in a simpler way, which works more reliably as long as no NAT is involved.
Any such software written before the introduction of RFC6598 will of course consider addresses from 100.64.0.0/10 to be public addresses and use them as such. This is going to cause breakage.
If you know for sure that there is going to be another layer of NAT behind the addresses you hand out, you might avoid some application layer problems, and thus think assigning RFC6598 addresses won't cause such problems. However if those NAT devices are some of those that enable 6to4 by default, if they get a public IPv4 address, you are going to see addresses from 2002:6440::/26 being assigned, which is not going to work.
The intention of RFC6598 may be good. But the problems you avoid may very well be replaced by some new and poorly understood problems.
My understanding was that cell phones all already use IPv6 via 6-to-4 NAT on the backend.
I'm pretty sure they are not using 6to4. Some carriers use DNS64+NAT64 for cell phones, and thus the phones themselves are IPv6-only. But NAT64 is still a NAT with connection tracking and all that. Additionally since the phone doesn't even know, that it is really IPv4 on the other side of the NAT, it may actually cause some software to have more problems with that.
An advantage of DNS64+NAT64 is that you can migrate clients between NAT64 devices without affecting established connections. The address seen by the client has plenty of bits that it can contain both an identification of the NAT64 device in use and the IPv4 address of the server on the other side of the internet. And by handing the client multiple IPv6 addresses using different NAT64 devices, you can let the client perform failover between them.
Well, that is easy - just make every tower a separate subnet and force a dhcp negotiation each time the tower changes.
That would increase the number of IP addresses needed on your network, as each tower would need enough addresses to cover peak usage. Additionally, the DHCP server wouldn't know that a client had left, so the addresses would be occupied long after no longer being in use. That means if you try to do this with IPv4 there would be absolutely no way to avoid NAT.
If you tried to go for a similar approach with IPv6, it would work slightly better. First of all using router solicitations has a bit less overhead than DHCP. Additionally you have enough addresses, that you don't need to worry about the extra consumption caused by this approach. And you avoid the NAT layer. You still get the problem with the IP address of the device changing too frequently. Possibly IPv6 mobility or MPTCP could help with that. Things may work out even better, if you could do a proper handoff between towers where you can have some overlap time during which both addresses work.
Such a handoff could either be done by a device being able to communicate with two towers simultaneously, or by each tower knowing about devices on neighbouring towers. Then as you moved the tower you used previously would know where you had moved and route your packets that way.
But frankly I guess the carrier has a more intelligent network, which can actually centrally keep track of where each device is and route traffic for that device to the proper tower without having to change the addressing. Your phone number doesn't change as you are moving around either.
If you wanted the phone IP to remain constant then routing that is no easier or harder than NAT.
They are two orthogonal problems. One you need to solve if you decide to use IPv4, the other you need to solve regardless of which IP protocol you choose. Which of the two problems is easier or harder to solve is not entirely clear to me. I do think the routing part sounds a bit easier. But it is clear that having to solve both problems is harder than having to solve just one of them.
The packets are still going to go into the provider's network at the same point, since the phone isn't moving as far as the rest of the world is concerned.
Where the packets enter the provider's network does indeed not depend on where inside the provider's network, the device is located. But networks have a concept called redundancy. There are multiple points through which the packets could enter the network. As soon as the packet is inside the provider's network, it is possible to do more fine grained routing than the outside world would have done. So at that point you could route the packet to the most efficient path to the device.
If NAT is involved, it gets more complicated. You don't want the NAT to become a single point of failure, so you have to have multiple geographically distributed NAT devices. Consistent replication of connection tracking information between geographically distributed NAT devices is impractical. So you'd need all packets for a connection to go through the same NAT. But routing only considers the IP address of one endpoint, not both, so routing based on connection is not going to be trivial either. You can cut back a bit on the consistency requirement for the replication and then actually replicate connection tracking information. But no matter how you do it, the NAT is going to impose a lot of complexity as soon as you require that it cannot be a single point of failure.
It is most likely to happen if you change ISP, or your ISP is taken over by another company that already serves your area.
Agreed. And for those reasons you should avoid being dependent on the assignment from the ISP being static forever.
There was an attempt at building some renumbering logic into the DNS records (with the A6 records). But A6 records were eventually dropped with the reasoning that AAAA records were simpler and using proven methodology (due to their similarity to A records), and that the renumbering logic could be done in tools for generating zone files without needing complicated standards to be applied at lookup time, and finally that looking up an AAAA record required fewer roundtrips than looking up A6 records.
The tools that should have emerged to help in renumbering AAAA records haven't shown up at any of the DNS providers I have been working with, but the lack of such tools have certainly not given me any reason to prefer IPv4 over IPv6.
So all in all, it is a solved problem. One just need to pick the preferred solution among those that exist.
Given a choice between an artificial scarcity of IP addresses that allows them to change extra, and an investment in a solution that will eventually make the scarcity go away, it's fairly obvious which the ISPs are going to choose.
I'd say it ought to be easier to get customers to move among the ISPs rather than making them pay more for the same service.
In other words, if you are trying to make your existing customers pay more for the same service, they are more likely to switch to another ISP. If OTOH you are giving customers more for the same price, you are more likely to attract customers from another ISP.
As long as enough IP addresses are effectively free for the ISP (which they are with IPv6), there should be little reason for ISPs not to give customers enough IP addresses, assuming there is real competition between ISPs.
From then end user perspective, you should see what happens to Skype and games when both end-users are behind a double NAT, it's hilarious.
I have seen what happens to Skype when both endpoints are behind a single NAT. Try doing a conference call with all parties behind separate NATs... And a few years back Skype had a major outage, which was in part caused by the fraction of users behind NAT.
For the hosting providers then fun really starts when you can't get a public IPv4 for your new webserver, that'll be fun. There's no NAT workaround for that
Actually, there are ways around that. I have been working on a frontend for that sort of scenario. I'd be happy if sites would deploy as IPv6 only and let frontends such as ours deal with the IPv4 only clients.
The appealing thing about carrier grade NAT is most consumers won't even notice.
Some people might claim that ipv6 could be done transparent to the end user, but personally I think that's a load of BS, and I suspect so do ISPs.
Either approach will cause problems for the end users. In both cases the users will have no clue what is the root cause of the problem, and they will believe whatever bullshit their ISP tells them. My ISP ran out of IPv4 addresses, thus some of my devices got no reply from the DHCP server. The ISP tried to convince me that it was due to a defective network interface on my end.
How to transition from ipv4 to ipv6 would to me seem the most important consideration when designing ipv6, but form appearances it seems like it was an afterthought, which is probably why we'll have ipv4 for quite some time.
That is true. I saw this coming more than a decade ago, unfortunately I was not in a position to do anything about it. Why didn't any of the people who were in a position to do something about it see it coming?
Last year I did some calculations on how fast the transition should have been going to complete on time (i.e. before IPv4 addresses ran out). For the past year the transitioning has been going at the speed, which I calculated. Meaning at the start of 2013 we were 13 years behind schedule and at the start of 2014 we were still 13 years behind schedule. I'd say my calculations would have been realistic, if only people had started soon enough rather than waiting.
The core problem was the lack of incentive to get started. A good incentive would have been rationing of IPv4 addresses much earlier. Instead of handing out 98% of the addresses before rationing IPv4 addresses, it might have been a good idea to only hand out 50% and then start rationing. The rule could then have been that you could get more IPv4 addresses if you were rolling out native dual stack. With such a rule the amount of IPv4 only deployments could have been kept static while dual stack was growing. By the time IPv4 ran out, we would have had 50% dual stack already.
But looking back and pointing out what should have been done 15 years ago isn't going to solve the problem we have today. And IPv6 deployment is still not large enough for market forces alone to give incentive to upgrade. There are ISPs rolling out CGN solutions with no plan about deploying native IPv6. How do we give those ISPs a strong incentive to start upgrading?
I have been trying to produce some incentive to move in the right direction. I am open to more ideas on what I personally can do to give ISPs the right incentive.
Which means everything still breaks just as if NAT was present.
That is not correct. A properly configured firewall does not cause nearly the same level of breakage as a NAT does.
And finally, the biggest hurdle for IPv6 is NAT.
That is true. NAT is hurting IPv6 deployment in many ways. Had NAT never been invented, we could all have been running IPv6 years ago, and the transition would have gone smoother. For example a large part of the difficulties in using IPv6 through tunnels is entirely due to the IPv4 connections being infested with NATs.
With IPv6, you lose this handy feature - your ISP decides to change your prefix?
With IPv6 there are enough addresses, that this should happen very rarely.
Well, damn, they haven't done that in 5 years and now everything has been hardcoded with the old prefix in it - all your internal services used it.
Slashdot Mirror
I see your point.
I think that is not communism but rather corruption. I suspect communism might be so prone to get corrupted, that many people cannot tell the difference between communism and corruption.
I more or less agree with everything you just said. This blog by Bruce Schneier gives another nice perspective on it.
Why doesn't he just suicide-bomb the TSA line? Wouldn't that cause enough terror?
In Russia suicide terrorists bomb airports.
Not on my own LAN. But I have been using my laptop on LANs which were configured like that.
Who says the number has to increase? Each interface should only have one static and a handful of temporary addresses. The temporary addresses are removed at the same rate at which they are added.
You don't put temporary addresses in your AAAA records. If something need a AAAA record, you use a static address for that. So it is static address on the server side and temporary address on the client side.
Sure that is the simplest form of NAT, which you can possibly do. However it does not give you any of the anonymity or topology hiding, which is often given as motivations for using NAT in the first place.
Yes, you can avoid renumbering that way. But there are drawbacks as well. You will break any protocol, which is not strictly a client-server protocol. And you will break any algorithm, which looks at assigned addresses and behaves differently depending on whether you have a routable IP address or not. Is this breakage of protocols you may be using on a daily basis really worth it, in order to avoid a bit of extra work in the rare case, where you may have to renumber your network?
How would you make anything but a strictly client-server protocol work with that requirement? Let's keep it simple and consider just the following scenario. Two clients (which could be both on the same LAN or on separate LANs far from each other) each resolve the IP address of a single server. Each client contact the server and indicate they want to communicate with each other. The server informs each client about the address of the other, such that a direct communication channel can be established between the clients.
With lots of configuration, you can overcome some of the problems. But you'll never get it working as smooth as it would without NAT.
And the reason for that is NAT. Also, the definition of a server is unclear in the first place. Not all protocols are client-server protocols. Do you call every listening end of a TCP connection a server? Historically some protocols including FTP and X11 have been listening for connections on the client device. And peer-to-peer protocols need to transfer data between two devices, neither of which would be considered a server. In many cases UDP has been used in scenarios, where TCP would have been better suited. The only reason being, that it is easier to punch holes in a NAT, if you are using UDP than if you are using TCP.
I have written a NAT implementation from scratch. What background do you have, which gives you more knowledge about NAT than writing a NAT implementation from scratch?
Such a design is never going to work. What are you going to do once you face the requirement of notifying the user about an incoming message within a five second deadline, while your power budget does not allow you to send packets more frequently than once every 30 seconds during idle time?
With current network design, changing the IP address is not going to be transparent to the application. Change of IP address will cause ongoing communication to break (or even worse - stall). The best you can do is for the application to notice the IP change and establish a new connection. That will however only work reliably in the absence of NAT. You can do it more transparently to the application, if you are using MPTCP. But that doesn't change any of my points, it just moves some of the logic one layer down the stack.
Another common misconception. All of the perceived privacy you would get from using NAT can be achieved from IPv6 privacy addresses. You get additional privacy that way, because moving from IPv4 to IPv6 eliminates the leaks you'd otherwise get from the IPID field in the IPv4 header.
No. I am perfectly aware that lots of people disagree. However so far none of the people who disagree with my view have shown me a technically sound reasoning for their position. Generally you can do better by simply using a firewall, that passes or rejects packets without mangling them, combined with utilizing multiple IPv6 addresses per interface inside your LAN. Those two methods cover all of the perceived advantages of NAT44, which I remember having heard about.
I was explaining why leaving NAT out of the IPv6 specification was a sensible decision. The question was whether native IPv6 without NAT or NAT66 was a better choice. Now you bring up the challenge of getting two legacy IPv4 hosts to talk to communicate with each other. Which technology is better for that purpose NAT66 or IPv6 without NAT? The answer is, neither will do that particular job. So that is by no means an argument in favor of NAT66.
As a matter of fact, I have developed a system, which does all of that. On the edge between the LAN and the internet backbone, there is one or more gateways translating between IPv4 and IPv6. Whether the other end of the connection is using translation as well is transparent to the hosts. With this system it is possible to communicate between two LANs using IPv4 only through an IPv6 backbone. Topology hiding is achieved through an optional encryption of addresses on the edge. Using IPv6 across the backbone eliminates a bunch of the scaling issues a traditional NAT44 suffers from. Finally I support automatic fallback to tunnelling in case the native IPv6 link goes down.
You are the one who hasn't made any constructive suggestions on how to solve the problem.
First of all, keepalive checks is not the goal. It is merely a means to workaround obstacles getting in the way of solving the real problem. The goal is to get a notification to the phone, when it needs attention. The deadline to get the notification there is on the order of five seconds, possibly less. At the same time there is no power budget to send packets every five seconds, even sending a packet every minute may be too power consuming.
How do you propose solving that problem? It is quite clear that it can only be achieve by having the phone passively listening for traffic.
And which polling interval do you suggest using if the needs are: 1: Application must get notified no later than five seconds after a certain event happening in the cloud. 2: While the application is idle, the radio transmitter on the phone must not be activated more frequently than once every five minutes, to preserve battery power.
If you choose to use polling to solve that problem, you must choose an interval which is shorter than five seconds and longer than five minutes. That is impossible. Opening a TCP connection and waiting for a reply will however work.
That is not a problem. If the network connection disappears temporarily, then notifications cannot be received while the connection is gone. Users can understand, that they cannot receive notifications while the connection is gone, and that no protocol changes can make that happen. Once the network connection has been re-established, there are two possibilities. Either the device still has the same IP address, in which case the TCP connection is still open. Or the device got a new IP address, in which case the application can get notified about the IP change and take necessary actions to establish a new connection.
The only problem left to consider in case of temporary loss of network connection is the following: The phone may lose network connection temporarily and not realize this, while the connection is gone the server decides the TCP connection needs to be closed and sends a FIN. Due to the FIN getting lost, the FIN gets retransmitted a few times. Eventually the server gives up discards state and stops sending further FIN packets.
This is the situation TCP keepalive is mainly designed to deal with. Additionally there is the possibility that the server crashed and got rebooted and thereby lost all TCP connections without having a chance to send a FIN. Use TCP keepalive to ensure both of those situations are noticed by the application. If you just use keepalives for this, you don't need frequent keepalives, because this is not in the critical path for receiving notifications about events in the cloud.
That is utter bullshit. If you look at the actual IPv4 protocol versus the actual IPv6 protocol, you'll find IPv4 to be slightly more hostile towards NAT than IPv6 is.
The mandatory IPID field in the IPv4 header is almost impossible to handle in an IPv4 NAT without violating the IPv4 spec. And RFC1918 addresses are prone to have collisions.
It was deliberately chosen not to make NAT part of the IPv6 standard. But NAT was not part of the IPv4 standard either. Some later RFCs standardize various aspects of NAT44, but as far as I can tell actual implementations of NAT44 predate the standards, and implementations made after the standards don't follow the standards anyway.
Nothing in the RFCs was stopping IPv6 implementations from including NAT66. What stopped them from including it was common sense. People who actually know how the networks work realized that nothing good came from NAT44, and that's why it wasn't implemented for IPv6. For every problem that people have applied NAT44 to, IPv6 offers a better solution, which does not involve NAT.
Polling is even worse than keepalives. Polling is a waste of resources. Let's say I have a chat client, and need to get notified about incoming chat messages in a timely fashion. A reasonable polling frequency for that would probably be around once every five seconds. For each poll I will exchange three packets for a TCP handshake, two packets for application level query, and four packets to tear down the TCP connection. That is a total of nine packets every five seconds.
There could be hours between the time where I receive a chat message. But that does not mean I can wait hours to be notified about one arriving.
If instead the client open a connection and tell the server to notify me, once a message arrives, the connection could exchange the following packets. Three packets for TCP handshake, three packets for application level request, application level ACK and TCP level ACK of the application level ACK. A total of six packets after which the connection goes idle. Once a chat message arrives there could be an application level notification followed by four packets to tear down the connection. That is a total of eleven packets for the entire duration of this connection, which could last for hours.
Eleven packets in the span of hours seem a lot more efficient than nine packets every five seconds. And the open connection can even give me a notification in less than a second compared to the average delay of 2½ second I'd get from polling every five seconds.
How do you expect to get notified once an email or a chat message arrives?
I have had that feeling for more than a decade. Unfortunately, legislators don't understand how the internet works. I guess the majority of legislators have never seen an internet connection without NAT.
No other operator could deliver connectivity at my address. Besides I have no guarantee another operator would do any better. And none of them are offering IPv6, which would otherwise be sufficient reason for me to switch right away.
Nope. That is not permitted (for exactly the reason you mentioned).
For example, "fe80:0000:0000:0000:0025:0000:0000:0001". Would that become "fe80::0025::0001"? Wouldn't this be a problem then if you try to shorten "fe80:0000:0000:0025:0000:0000:0000:0001" and get the same result "fe80::0025::0001"?
That's why you can't shorten two blocks. One might argue that as long as each shortened group was shortened by the same amount, it could be expanded unambiguously. But that would have added complexity, for very little gain. So instead the standard says you can only shorten one block.
Some interpretations go further and says you must shorten the longest run of zeros, and only if it contains at least two zero blocks. And if there are two blocks of identical length you must shorten a particular one. Those more strict rules are relevant if you absolutely need a canonical representation of an IPv6 address. But some implementations have taken this a step too far and reject IP addresses, if the shorting does not follow these rules exactly. For example IPv6 addresses has been rejected due to having used shorting when there was only a single block of zeros.
The rationale was roughly this. We want to get rid of the complexity by having variable length network prefixes. So the address would consist of a fixed length field to address a network and another fixed length field to address a device on that network.
/16 of IPv6 address space allocated for a transition mechanism isn't bad. And 16 bits for subnetting is sufficient for the size of network you typically have behind an IPv4 address. But then people realized that somebody has been deploying NAT on the IPv4 network. So another tunnelling protocol is needed. Along comes Teredo. Teredo embeds two IPv4 addresses and a port number into the IPv6 address. That's 80 bits. There is no way you are going to embed all of that into the top 64 bits of an IPv6 address and still have room to spare. In fact Teredo would probably have benefited from having the server port number embedded in the IPv6 address as well, but there just wasn't room for that. If you would have wanted to combine the benefits of 6to4 with those of Teredo into a single protocol, you would have needed 64 bits more in the IPv6 address, that is 192 bits total.
For the first part we knew 32 bits was insufficient, and we don't want the administrative overhead of an extremely large HD-ratio, so go for a more relaxed HD-ratio of 80%. If we have 45 bits and assume an HD-ratio of 80% we get the equivalent of 36 bits efficiently used.
For the second part we wanted to be able to embed a full MAC address, so we need at least 48 bits.
To keep things simple, each part was rounded up to 64 bits.
We already now see situations, where the size of IPv6 addresses is a shortcoming. First case is in tunnel protocols. First there was 6to4, which embed an IPv4 address right in the middle of the upper 64 bits (the network part). This worked great from an addressing perspective. A
There is also the desire to put cryptographic information inside an IP address. With IPv4 this idea was more or less unthinkable, because 32 bits of security is just not enough for anything. With IPv6 it starts to become possible. But you can't use the entire IPv6 address for only cryptographic data, you absolutely need some bits at the start to identify the class of address. And some bits left over to identify network and device would be nice. You can meaningfully embed cryptographic information inside an IPv6 address. But you don't get to do much else. If you wanted to embed say a SHA1 hash plus some other information in an IP address, you are soon going to need 256 bits.
Consider all the things I mentioned and you might find a use for even 512 address bits. But at this time it is too late to change the size of the IPv6 address. Anybody who want to propose an alternative to IPv6 have to remember that in order to prove that a solution does solve all the shortcomings of IPv6, you have to get it standardized, implemented and deployed before February 2011.
Plus the developer has to spend time fixing bugs in the code working around the NAT induced problems. I think the Skype outage a few years back is the most spectacular example of how bad it can go.
That introduces other problems. Lots of software will look at the assigned address to figure out if it has a public address or is located behind a NAT. If it is behind a NAT it will make certain workarounds, if it has a public address it can ignore most of that and do things in a simpler way, which works more reliably as long as no NAT is involved.
Any such software written before the introduction of RFC6598 will of course consider addresses from 100.64.0.0/10 to be public addresses and use them as such. This is going to cause breakage.
If you know for sure that there is going to be another layer of NAT behind the addresses you hand out, you might avoid some application layer problems, and thus think assigning RFC6598 addresses won't cause such problems. However if those NAT devices are some of those that enable 6to4 by default, if they get a public IPv4 address, you are going to see addresses from 2002:6440::/26 being assigned, which is not going to work.
The intention of RFC6598 may be good. But the problems you avoid may very well be replaced by some new and poorly understood problems.
I'm pretty sure they are not using 6to4. Some carriers use DNS64+NAT64 for cell phones, and thus the phones themselves are IPv6-only. But NAT64 is still a NAT with connection tracking and all that. Additionally since the phone doesn't even know, that it is really IPv4 on the other side of the NAT, it may actually cause some software to have more problems with that.
An advantage of DNS64+NAT64 is that you can migrate clients between NAT64 devices without affecting established connections. The address seen by the client has plenty of bits that it can contain both an identification of the NAT64 device in use and the IPv4 address of the server on the other side of the internet. And by handing the client multiple IPv6 addresses using different NAT64 devices, you can let the client perform failover between them.
I think most people gave up on PIP already.
That would increase the number of IP addresses needed on your network, as each tower would need enough addresses to cover peak usage. Additionally, the DHCP server wouldn't know that a client had left, so the addresses would be occupied long after no longer being in use. That means if you try to do this with IPv4 there would be absolutely no way to avoid NAT.
If you tried to go for a similar approach with IPv6, it would work slightly better. First of all using router solicitations has a bit less overhead than DHCP. Additionally you have enough addresses, that you don't need to worry about the extra consumption caused by this approach. And you avoid the NAT layer. You still get the problem with the IP address of the device changing too frequently. Possibly IPv6 mobility or MPTCP could help with that. Things may work out even better, if you could do a proper handoff between towers where you can have some overlap time during which both addresses work.
Such a handoff could either be done by a device being able to communicate with two towers simultaneously, or by each tower knowing about devices on neighbouring towers. Then as you moved the tower you used previously would know where you had moved and route your packets that way.
But frankly I guess the carrier has a more intelligent network, which can actually centrally keep track of where each device is and route traffic for that device to the proper tower without having to change the addressing. Your phone number doesn't change as you are moving around either.
They are two orthogonal problems. One you need to solve if you decide to use IPv4, the other you need to solve regardless of which IP protocol you choose. Which of the two problems is easier or harder to solve is not entirely clear to me. I do think the routing part sounds a bit easier. But it is clear that having to solve both problems is harder than having to solve just one of them.
Where the packets enter the provider's network does indeed not depend on where inside the provider's network, the device is located. But networks have a concept called redundancy. There are multiple points through which the packets could enter the network. As soon as the packet is inside the provider's network, it is possible to do more fine grained routing than the outside world would have done. So at that point you could route the packet to the most efficient path to the device.
If NAT is involved, it gets more complicated. You don't want the NAT to become a single point of failure, so you have to have multiple geographically distributed NAT devices. Consistent replication of connection tracking information between geographically distributed NAT devices is impractical. So you'd need all packets for a connection to go through the same NAT. But routing only considers the IP address of one endpoint, not both, so routing based on connection is not going to be trivial either. You can cut back a bit on the consistency requirement for the replication and then actually replicate connection tracking information. But no matter how you do it, the NAT is going to impose a lot of complexity as soon as you require that it cannot be a single point of failure.
Agreed. And for those reasons you should avoid being dependent on the assignment from the ISP being static forever.
There was an attempt at building some renumbering logic into the DNS records (with the A6 records). But A6 records were eventually dropped with the reasoning that AAAA records were simpler and using proven methodology (due to their similarity to A records), and that the renumbering logic could be done in tools for generating zone files without needing complicated standards to be applied at lookup time, and finally that looking up an AAAA record required fewer roundtrips than looking up A6 records.
The tools that should have emerged to help in renumbering AAAA records haven't shown up at any of the DNS providers I have been working with, but the lack of such tools have certainly not given me any reason to prefer IPv4 over IPv6.
So all in all, it is a solved problem. One just need to pick the preferred solution among those that exist.
I'd say it ought to be easier to get customers to move among the ISPs rather than making them pay more for the same service.
In other words, if you are trying to make your existing customers pay more for the same service, they are more likely to switch to another ISP. If OTOH you are giving customers more for the same price, you are more likely to attract customers from another ISP.
As long as enough IP addresses are effectively free for the ISP (which they are with IPv6), there should be little reason for ISPs not to give customers enough IP addresses, assuming there is real competition between ISPs.
I have seen what happens to Skype when both endpoints are behind a single NAT. Try doing a conference call with all parties behind separate NATs... And a few years back Skype had a major outage, which was in part caused by the fraction of users behind NAT.
Actually, there are ways around that. I have been working on a frontend for that sort of scenario. I'd be happy if sites would deploy as IPv6 only and let frontends such as ours deal with the IPv4 only clients.
The appealing thing about carrier grade NAT is most consumers won't even notice.
Some people might claim that ipv6 could be done transparent to the end user, but personally I think that's a load of BS, and I suspect so do ISPs.
Either approach will cause problems for the end users. In both cases the users will have no clue what is the root cause of the problem, and they will believe whatever bullshit their ISP tells them. My ISP ran out of IPv4 addresses, thus some of my devices got no reply from the DHCP server. The ISP tried to convince me that it was due to a defective network interface on my end.
That is true. I saw this coming more than a decade ago, unfortunately I was not in a position to do anything about it. Why didn't any of the people who were in a position to do something about it see it coming?
Last year I did some calculations on how fast the transition should have been going to complete on time (i.e. before IPv4 addresses ran out). For the past year the transitioning has been going at the speed, which I calculated. Meaning at the start of 2013 we were 13 years behind schedule and at the start of 2014 we were still 13 years behind schedule. I'd say my calculations would have been realistic, if only people had started soon enough rather than waiting.
The core problem was the lack of incentive to get started. A good incentive would have been rationing of IPv4 addresses much earlier. Instead of handing out 98% of the addresses before rationing IPv4 addresses, it might have been a good idea to only hand out 50% and then start rationing. The rule could then have been that you could get more IPv4 addresses if you were rolling out native dual stack. With such a rule the amount of IPv4 only deployments could have been kept static while dual stack was growing. By the time IPv4 ran out, we would have had 50% dual stack already.
But looking back and pointing out what should have been done 15 years ago isn't going to solve the problem we have today. And IPv6 deployment is still not large enough for market forces alone to give incentive to upgrade. There are ISPs rolling out CGN solutions with no plan about deploying native IPv6. How do we give those ISPs a strong incentive to start upgrading?
I have been trying to produce some incentive to move in the right direction. I am open to more ideas on what I personally can do to give ISPs the right incentive.
That is not correct. A properly configured firewall does not cause nearly the same level of breakage as a NAT does.
That is true. NAT is hurting IPv6 deployment in many ways. Had NAT never been invented, we could all have been running IPv6 years ago, and the transition would have gone smoother. For example a large part of the difficulties in using IPv6 through tunnels is entirely due to the IPv4 connections being infested with NATs.
With IPv6 there are enough addresses, that this should happen very rarely.
Then use DNS and/or RFC 4193.