4 ms·

NAT is an acronym for "Network Address Translation" so that's the right term to use. NAT approaches to bridge IPv6 and IPv4 exist and work as well as IPv4-to-I

NAT is an acronym for "Network Address Translation" so that's the right term to use. NAT approaches to bridge IPv6 and IPv4 exist and work as well as IPv4-to-IPv4 NATs, that is to say pretty poorly: but we've long since adjusted the architecture of Internet-enabled software to cope with the flaws, so practically speaking they work just fine. We've been down a road for a while now of funnelling all of the Internet's services into something-over-HTTP, so running a server might need a public IPv4 address, but as the supplies already assigned to LIRs by the RIPE NCC (and other RIRs) start to dwindle I expect we'll see more services offered whereby you can share an HTTP front end with a bunch of other people, proxied to an IPv6 (or private space) server you run.

mercora 7y ago
I don't think that the use of NAT at that level is really feasible to bridge IPv4 networks to IPv6 ones. While you can easily map the entire IPv4 address space into an IPv6 subnet of your choosing this is obviously not possible the other way around. Address mapping would have to be highly dynamic to work at all and there would be no real guarantee addresses stay the same that way. Additionally in order to make this work more or less transparently DNS responses have to be modified breaking in presence of DNSSEC validation (the same as DNS64 in reverse). One could probably avoid this by using something like reverse DS-Lite which is more or less NAT with tunneling combined. A more common approach to reach IPv6 networks from IPv4 ones is tunneling the traffic on top of your existing IPv4 network. This way you become fully addressable and able to reach both networks almost like you would have been able to with a dual stack setup except that the tunnel reduces your MTU because of the tunneling and that you need an remote endpoint with support for both networks that routes packets to your tunnel accordingly. Using IPv6 only makes it impossible to reach you from an IPv4 only node while still making it easy to reach other IPv4 host from your side using only NAT techniques. Using IPv4 only its unfeasible to reach arbitrary IPv6 hosts using NAT only and a tunnel setup is more or less required to make it work properly.
- jsjohnst 7y ago
  > I don't think that the use of NAT at that level is really feasible to bridge IPv4 networks to IPv6 ones. Not only has CGNAT existed doing this at scale for many years in SE Asia, it commonly happens on cell networks in the US now even, so yes, it’s feasible.
  - mercora 7y ago
    that would be quite uncommon. what happens often though is the reverse. maybe you misread my point?
- tptacek 7y ago
  One more reason to reconsider the design of DNSSEC and take it back to the drawing board, since it has virtually no meaningful deployment today anyways, and is already badly flawed.
  - nybble41 7y ago
    There's nothing wrong with the design of DNSSEC. It's just doing its job, making sure that the addresses in the DNS replies match the RRs configured by the domain owner and preventing MitM attacks against the DNS system. The issue is DNS64, which for all intents and purposes is a form of MitM attack: If you can run a transparent DNS64 service you can redirect traffic however you want. You're not limited to faking "equivalent" AAAA records which send traffic to the correct IPv4 server. This is incompatible not only with DNSSEC in particular but with any attempt to ensure the end-to-end integrity of domain resolution. Anyway, we already have a solution to the problem of IPv6-only networks connecting to IPv4 servers which doesn't depend on manipulating DNS entries: DS-Lite.
    - tptacek 7y ago
      The job it does has very little operational value, and it breaks things we care about. In just a few months of deployment, DoH has done more to protect DNS queries than DNSSEC has in almost 25 years of work. Any time you look at something that DNSSEC makes harder, your first thought should be, "is the real problem here that we're trying to do tree-PKI DNSSEC in the first place"? I'd content that's always the case.
      - nybble41 7y ago
        DoH and DNSSEC are orthogonal systems. DoH protects the connection from the client to the resolver from eavesdropping or tampering, but doesn't do anything to ensure the integrity of the records reported to the resolver (which still uses regular DNS) and doesn't prevent the resolver itself from tampering with the data. The aim of DNSSEC is to provide for the end-to-end integrity of the RRs so that a client can be sure that the reported data matches the data entered by owner of the domain. This is essential for protocols such as DANE. The introduction of DoH does not eliminate the need for DNSSEC and the two protocols can be used together.

mercora 7y ago

I don't think that the use of NAT at that level is really feasible to bridge IPv4 networks to IPv6 ones. While you can easily map the entire IPv4 address space into an IPv6 subnet of your choosing this is obviously not possible the other way around. Address mapping would have to be highly dynamic to work at all and there would be no real guarantee addresses stay the same that way. Additionally in order to make this work more or less transparently DNS responses have to be modified breaking in presence of DNSSEC validation (the same as DNS64 in reverse). One could probably avoid this by using something like reverse DS-Lite which is more or less NAT with tunneling combined. A more common approach to reach IPv6 networks from IPv4 ones is tunneling the traffic on top of your existing IPv4 network. This way you become fully addressable and able to reach both networks almost like you would have been able to with a dual stack setup except that the tunnel reduces your MTU because of the tunneling and that you need an remote endpoint with support for both networks that routes packets to your tunnel accordingly. Using IPv6 only makes it impossible to reach you from an IPv4 only node while still making it easy to reach other IPv4 host from your side using only NAT techniques. Using IPv4 only its unfeasible to reach arbitrary IPv6 hosts using NAT only and a tunnel setup is more or less required to make it work properly.

jsjohnst 7y ago
> I don't think that the use of NAT at that level is really feasible to bridge IPv4 networks to IPv6 ones. Not only has CGNAT existed doing this at scale for many years in SE Asia, it commonly happens on cell networks in the US now even, so yes, it’s feasible.
- mercora 7y ago
  that would be quite uncommon. what happens often though is the reverse. maybe you misread my point?
tptacek 7y ago
One more reason to reconsider the design of DNSSEC and take it back to the drawing board, since it has virtually no meaningful deployment today anyways, and is already badly flawed.
- nybble41 7y ago
  There's nothing wrong with the design of DNSSEC. It's just doing its job, making sure that the addresses in the DNS replies match the RRs configured by the domain owner and preventing MitM attacks against the DNS system. The issue is DNS64, which for all intents and purposes is a form of MitM attack: If you can run a transparent DNS64 service you can redirect traffic however you want. You're not limited to faking "equivalent" AAAA records which send traffic to the correct IPv4 server. This is incompatible not only with DNSSEC in particular but with any attempt to ensure the end-to-end integrity of domain resolution. Anyway, we already have a solution to the problem of IPv6-only networks connecting to IPv4 servers which doesn't depend on manipulating DNS entries: DS-Lite.
  - tptacek 7y ago
    The job it does has very little operational value, and it breaks things we care about. In just a few months of deployment, DoH has done more to protect DNS queries than DNSSEC has in almost 25 years of work. Any time you look at something that DNSSEC makes harder, your first thought should be, "is the real problem here that we're trying to do tree-PKI DNSSEC in the first place"? I'd content that's always the case.
    - nybble41 7y ago
      DoH and DNSSEC are orthogonal systems. DoH protects the connection from the client to the resolver from eavesdropping or tampering, but doesn't do anything to ensure the integrity of the records reported to the resolver (which still uses regular DNS) and doesn't prevent the resolver itself from tampering with the data. The aim of DNSSEC is to provide for the end-to-end integrity of the RRs so that a client can be sure that the reported data matches the data entered by owner of the domain. This is essential for protocols such as DANE. The introduction of DoH does not eliminate the need for DNSSEC and the two protocols can be used together.