9 ms·

Loose coupling and no second system effect. IPv6 should have been extended address space and extended address space only, in a manner backwards-compatible with

by geofft 8y ago

Loose coupling and no second system effect. IPv6 should have been extended address space and extended address space only, in a manner backwards-compatible with IPv4. You think ARP is broken? Great, implement a fixed version of ARP for both IPv4 and IPv6, meanwhile we'll spec IPv6 to use ARP. Don't design IPv6 to use your new thing called NDP that layers completely differently. You think everyone using NAT is wrong? Great, go convince them. Don't tell those people "I don't care what you think, I'm right, and you better agree with me in order to deploy the new thing." They're going to - entirely justifiably - not deploy your new thing.

AnIdiotOnTheNet 8y ago
> Don't tell those people "I don't care what you think, I'm right, and you better agree with me in order to deploy the new thing." They're going to - entirely justifiably - not deploy your new thing. Pay attention developers. This attitude is all too common in our industry.
- protomyth 8y ago
  Pay attention to the system admins, because someone has to deploy and use the new code everyday.
magila 8y ago
The thing about NAT that for network operators it is a negative externality. For them it often simplifies their job. They do not feel the searing pain it inflicts on network application developers. It's hard to come up with a carrot to convince operators that NAT is wrong because from their perspective it isn't, even if it harms the internet as a whole.
- geofft 8y ago
  As a network application developer I haven't felt much pain from NAT - I need to run a central server to relay connections, but that's about it. And oftentimes I need to run a central server anyway for discovery or authentication. (A few years ago I worked at a startup that enabled secure remote access to corporate networks, as in you could connect from a roaming laptop or mobile app into the network, browse the web, access network file shares, etc. We had a straightforward and uncomplicated proxy server with access control that we asked people to install and forward a port on their NAT for; it worked fine. We prototyped a relay server that customers could run in AWS, where our proxy server would connect outbound. I don't think any customers absolutely needed it. And we definitely preferred having one of our servers involved somehow as an intermediary so that customers weren't exposing Windows file shares to the public internet and hoping Windows authentication was enough....) What do you find as searing pain?
  - magila 8y ago
    You're right some some applications are more effected than others. It sounds like you were dealing with business customers, "asked people to...forward a port on their NAT" is not a viable strategy when dealing with consumers. I work on P2P applications, so NAT is the bane of my existence.
    - Gibbon1 8y ago
      I've always thought that facebook wouldn't exist if you had workable P2P for consumers.
  - vvanders 8y ago
    If you use UDP for anything you'll run into a bunch of fun issues. We hit it all the time back when I did networking in gamedev.
  - pixl97 8y ago
    >we asked people to install and forward a port on their NAT for At this point I no longer believe you. Having worked in the ISP industry for quite some time, only a very small portion of the more technically advanced users can do this successfully. Most users dont remember their passwords to even get in their device. Just because windows firewall security is balls doesn't justify writing a nat helper or proxy for every protocol their is. You have just accepted the abuse that nat doles out as a norm.
    - vetinari 8y ago
      Increasingly, even those who know how to do it are unable to do so, because they are behind CGNAT and the PCP doesn't work or is not implemented at all.
- AnIdiotOnTheNet 8y ago
  If NAT is wrong, then firewalls that block incoming connections by default are also wrong. I think you'll have a hard time making that argument.
  - jdblair 8y ago
    You're mixing up NAT and ingress blocking. A stateful firewall doesn't depend on NAT, we're just used to ingress blocking as a side effect of NAT.
    - AnIdiotOnTheNet 8y ago
      If a firewall isn't doing ingress blocking then it doesn't really serve much of a purpose now does it? Ingress blocking being a side effect of NAT is the whole point of equating it to a firewall. It's roughly similar for all intents and purposes except that it also provides socket translation, and socket translation is really useful so every firewall worth mentioning also provides NAT. That ipv6 initially did not address the usecases for socket translation outside of multiplexing addresses is probably one of the reasons it hasn't gained much ground in the decades it has been around. Anyway, the point is that most of the headache that NAT causes application developers is also true of firewalls that block inbound connections by default. Removing NAT from the equation doesn't save you.
      - spookthesunset 8y ago
        It’s late to the party but it is a shame you are getting down votes. Firewalls will still be all sealed up to where inbound connections are strictly limited. You’ll still need something like upnp to request a hole punched through the firewall.
    - geofft 8y ago
      No, I think that argument makes perfect sense. A stateful firewall doesn't depend on NAT but you get all the downsides of NAT from a working stateful firewall in default-deny mode: you still have to talk the firewall into allowing the relevant traffic through, and without that you still have connections that work in one direction and not the other. The only thing that's different is address discovery, but you can solve that by just asking the firewall what public address to use at the same time that you ask it to open the port. (Or curl whatismyip.akamai.com or something.) So if NAT is a problem for your application, so are the stateful firewalls implicitly envisioned by those who advocate for assigning unNATted public addresses to devices on home networks.
- paulddraper 8y ago
  Okay, NAT hurts network application developers. But do you really want to stake the adoption of IPv6 on convincing the world of that? Or should that be a separate battle?
- gregmac 8y ago
  NAT is only painful for applications that implement arbitrary inbound connections, such as peer-to-peer connections, and applications that use separate control/data connections. The former is understandable because it's necessary, the latter is arguably lazy application developers. Peer-to-peer is largely solved with UPnP port forwarding, but most of these apps can also at least be configured to use a specific port range, education can then be configured on the router to forward. Then the are the badly designed protocols. That's perhaps a bit harsh, they have their reasons, but using multiple ports is a bit lazy vs using encapsulated packets (eg where you can send either a control or data packet over a single connection, or even send multiple data streams concurrently, in both directions). FTP is one example, where a separate port is used for data transfers. This is "simple" from the perspective that the data port just contains the raw file contents, no extra encoding, but very painful from a network point of view. I used to support web hosting customers around 2000, when ftp was commonly used for maintaining site content, and people didn't understand when to use PASV mode, server operators didn't always setup the firewall to allow inbound data ports, and occasionally you'd run into the worst case of both client and server behind NAT. SIP is another example. It uses multiple streams, but is built assuming everything has a public IP. The message it uses to setup this stream includes the system's IP address, which is the private non-routable IP when behind NAT. Contrast these to a multiplexing protocol like HTTP/2, where it's basically transparent to network operators (still just a single TCP connection on 80 or 443). There's many other examples of multiplex use in more proprietary systems: online gaming, for example, sends different packet types over a single connection -- it doesn't require a separate "movement" and "shoot" port for each connected player. Most sites/apps using web sockets also work like this, with each piece of data encapsulated inside a message wrapper (usually JSON). I'm being a bit unfair, because FTP predates NAT, and SIP was being created around the same time -- though I'd argue SIP's assumptions about the network environment (and seeming compete ignorance of NAT) were both poor and unnecessary.
  - icebraining 8y ago
    UPnP only works for small-scale NAT, not carrier-grade, which is what ISPs are using when they can't afford to give everyone their own IPv4.
  - 8y ago
apple4ever 8y ago
You hit on the problem with IPv6 designers- they took a solution (bigger address space) to a problem (not enough addresses) and they added a bunch of other changes (No NAT, No DHCP, ARP vs NDP, weird address scheme, etc) that arguably made things worse. Then they wonder why people aren’t adopting it. (Its the same complaint I have against Let’s Encrypt. They shoved down a policy which is antithetical to helping their mission.)
- lwf 8y ago
  > (Its the same complaint I have against Let’s Encrypt. They shoved down a policy which is antithetical to helping their mission.) Can you expand what you mean by this? I'm drawing a blank.
  - geofft 8y ago
    I assume they're referring to the 3-month certificate lifetimes, which all but force you to automate certificate renewal, whereas the 1+-year certificates of the past let you treat it as manual sysadmin work. This was based on a belief that automating certificate renewals is the right thing to do. Still, LE seems to be wildly more successful than IPv6. I suspect in part that's because they were more technically right - or at least it's more feasible to add the automation than to rearchitect an IPv4 network - and in part because you can do manual certificate updates. (For complicated and entirely uninteresting reasons, I do manual certificate updates on my personal website every three months using certbot certonly --manual and scp, and it works.) I'm also way more personally sympathetic to LE because they're pushing the change for security reasons (revocation doesn't work, so we need to move to very short-lived certs) and not mere elegance ones. Rolling out IPv6 as designed brings no security benefits either to the user or to the ecosystem, and carries quite a few potential security risks.
    - saurik 8y ago
      I think another big thing with Let's Encrypt is that they are free while their legacy competitors cost money, which is on the brutal end of incentives.
drewg123 8y ago
I agree with you 100% The other thing that V6 does that it should never have done is the extension header nonsense. That makes it possible to layer protocol inside protocol essentially forever. Hardware designers just love this feature. In practice, a lot of hardware vendors do not support it and just punt to exception cases when they hit an extension header. I'm a little surprised that that there isn't some widespread DOS that involves extension header handling botches.

by geofft 8y ago

AnIdiotOnTheNet 8y ago

> Don't tell those people "I don't care what you think, I'm right, and you better agree with me in order to deploy the new thing." They're going to - entirely justifiably - not deploy your new thing. Pay attention developers. This attitude is all too common in our industry.

protomyth 8y ago
Pay attention to the system admins, because someone has to deploy and use the new code everyday.

magila 8y ago

The thing about NAT that for network operators it is a negative externality. For them it often simplifies their job. They do not feel the searing pain it inflicts on network application developers. It's hard to come up with a carrot to convince operators that NAT is wrong because from their perspective it isn't, even if it harms the internet as a whole.

geofft 8y ago
As a network application developer I haven't felt much pain from NAT - I need to run a central server to relay connections, but that's about it. And oftentimes I need to run a central server anyway for discovery or authentication. (A few years ago I worked at a startup that enabled secure remote access to corporate networks, as in you could connect from a roaming laptop or mobile app into the network, browse the web, access network file shares, etc. We had a straightforward and uncomplicated proxy server with access control that we asked people to install and forward a port on their NAT for; it worked fine. We prototyped a relay server that customers could run in AWS, where our proxy server would connect outbound. I don't think any customers absolutely needed it. And we definitely preferred having one of our servers involved somehow as an intermediary so that customers weren't exposing Windows file shares to the public internet and hoping Windows authentication was enough....) What do you find as searing pain?
- magila 8y ago
  You're right some some applications are more effected than others. It sounds like you were dealing with business customers, "asked people to...forward a port on their NAT" is not a viable strategy when dealing with consumers. I work on P2P applications, so NAT is the bane of my existence.
  - Gibbon1 8y ago
    I've always thought that facebook wouldn't exist if you had workable P2P for consumers.
- vvanders 8y ago
  If you use UDP for anything you'll run into a bunch of fun issues. We hit it all the time back when I did networking in gamedev.
- pixl97 8y ago
  >we asked people to install and forward a port on their NAT for At this point I no longer believe you. Having worked in the ISP industry for quite some time, only a very small portion of the more technically advanced users can do this successfully. Most users dont remember their passwords to even get in their device. Just because windows firewall security is balls doesn't justify writing a nat helper or proxy for every protocol their is. You have just accepted the abuse that nat doles out as a norm.
  - vetinari 8y ago
    Increasingly, even those who know how to do it are unable to do so, because they are behind CGNAT and the PCP doesn't work or is not implemented at all.
AnIdiotOnTheNet 8y ago
If NAT is wrong, then firewalls that block incoming connections by default are also wrong. I think you'll have a hard time making that argument.
- jdblair 8y ago
  You're mixing up NAT and ingress blocking. A stateful firewall doesn't depend on NAT, we're just used to ingress blocking as a side effect of NAT.
  - AnIdiotOnTheNet 8y ago
    If a firewall isn't doing ingress blocking then it doesn't really serve much of a purpose now does it? Ingress blocking being a side effect of NAT is the whole point of equating it to a firewall. It's roughly similar for all intents and purposes except that it also provides socket translation, and socket translation is really useful so every firewall worth mentioning also provides NAT. That ipv6 initially did not address the usecases for socket translation outside of multiplexing addresses is probably one of the reasons it hasn't gained much ground in the decades it has been around. Anyway, the point is that most of the headache that NAT causes application developers is also true of firewalls that block inbound connections by default. Removing NAT from the equation doesn't save you.
    - spookthesunset 8y ago
      It’s late to the party but it is a shame you are getting down votes. Firewalls will still be all sealed up to where inbound connections are strictly limited. You’ll still need something like upnp to request a hole punched through the firewall.
  - geofft 8y ago
    No, I think that argument makes perfect sense. A stateful firewall doesn't depend on NAT but you get all the downsides of NAT from a working stateful firewall in default-deny mode: you still have to talk the firewall into allowing the relevant traffic through, and without that you still have connections that work in one direction and not the other. The only thing that's different is address discovery, but you can solve that by just asking the firewall what public address to use at the same time that you ask it to open the port. (Or curl whatismyip.akamai.com or something.) So if NAT is a problem for your application, so are the stateful firewalls implicitly envisioned by those who advocate for assigning unNATted public addresses to devices on home networks.
paulddraper 8y ago
Okay, NAT hurts network application developers. But do you really want to stake the adoption of IPv6 on convincing the world of that? Or should that be a separate battle?
gregmac 8y ago
NAT is only painful for applications that implement arbitrary inbound connections, such as peer-to-peer connections, and applications that use separate control/data connections. The former is understandable because it's necessary, the latter is arguably lazy application developers. Peer-to-peer is largely solved with UPnP port forwarding, but most of these apps can also at least be configured to use a specific port range, education can then be configured on the router to forward. Then the are the badly designed protocols. That's perhaps a bit harsh, they have their reasons, but using multiple ports is a bit lazy vs using encapsulated packets (eg where you can send either a control or data packet over a single connection, or even send multiple data streams concurrently, in both directions). FTP is one example, where a separate port is used for data transfers. This is "simple" from the perspective that the data port just contains the raw file contents, no extra encoding, but very painful from a network point of view. I used to support web hosting customers around 2000, when ftp was commonly used for maintaining site content, and people didn't understand when to use PASV mode, server operators didn't always setup the firewall to allow inbound data ports, and occasionally you'd run into the worst case of both client and server behind NAT. SIP is another example. It uses multiple streams, but is built assuming everything has a public IP. The message it uses to setup this stream includes the system's IP address, which is the private non-routable IP when behind NAT. Contrast these to a multiplexing protocol like HTTP/2, where it's basically transparent to network operators (still just a single TCP connection on 80 or 443). There's many other examples of multiplex use in more proprietary systems: online gaming, for example, sends different packet types over a single connection -- it doesn't require a separate "movement" and "shoot" port for each connected player. Most sites/apps using web sockets also work like this, with each piece of data encapsulated inside a message wrapper (usually JSON). I'm being a bit unfair, because FTP predates NAT, and SIP was being created around the same time -- though I'd argue SIP's assumptions about the network environment (and seeming compete ignorance of NAT) were both poor and unnecessary.
- icebraining 8y ago
  UPnP only works for small-scale NAT, not carrier-grade, which is what ISPs are using when they can't afford to give everyone their own IPv4.
- 8y ago

apple4ever 8y ago

You hit on the problem with IPv6 designers- they took a solution (bigger address space) to a problem (not enough addresses) and they added a bunch of other changes (No NAT, No DHCP, ARP vs NDP, weird address scheme, etc) that arguably made things worse. Then they wonder why people aren’t adopting it. (Its the same complaint I have against Let’s Encrypt. They shoved down a policy which is antithetical to helping their mission.)

lwf 8y ago
> (Its the same complaint I have against Let’s Encrypt. They shoved down a policy which is antithetical to helping their mission.) Can you expand what you mean by this? I'm drawing a blank.
- geofft 8y ago
  I assume they're referring to the 3-month certificate lifetimes, which all but force you to automate certificate renewal, whereas the 1+-year certificates of the past let you treat it as manual sysadmin work. This was based on a belief that automating certificate renewals is the right thing to do. Still, LE seems to be wildly more successful than IPv6. I suspect in part that's because they were more technically right - or at least it's more feasible to add the automation than to rearchitect an IPv4 network - and in part because you can do manual certificate updates. (For complicated and entirely uninteresting reasons, I do manual certificate updates on my personal website every three months using certbot certonly --manual and scp, and it works.) I'm also way more personally sympathetic to LE because they're pushing the change for security reasons (revocation doesn't work, so we need to move to very short-lived certs) and not mere elegance ones. Rolling out IPv6 as designed brings no security benefits either to the user or to the ecosystem, and carries quite a few potential security risks.
  - saurik 8y ago
    I think another big thing with Let's Encrypt is that they are free while their legacy competitors cost money, which is on the brutal end of incentives.

drewg123 8y ago

I agree with you 100% The other thing that V6 does that it should never have done is the extension header nonsense. That makes it possible to layer protocol inside protocol essentially forever. Hardware designers just love this feature. In practice, a lot of hardware vendors do not support it and just punt to exception cases when they hit an extension header. I'm a little surprised that that there isn't some widespread DOS that involves extension header handling botches.