On 15-May-2015 02:25 am, Benedikt Stockebrand <[email protected]> wrote: > > Hi folks, > > this is admittedly a pet peeve of mine, so apologies right in advance > to anybody getting offended by this, but I'd like to rephrase > > "Marc Blanchet" <[email protected]> writes: > >> I think the technology (v6only-nat64-dns64) is mature enough. The >> problem is that various applications and services are not compatible >> with it (usually IPv4 addresses negotiated in the payload) > > as this: > > I think the technology (v6only-nat64-dns64) is inherently broken by > design. By design it doesn't support a range of important and > widely used existing applications and services that it should be > compatible with to be considered "working". > > With NAT, NAT64 or whatever other application unaware translation hack > being around, a lot of extra complexity is pushed towards the > application layer. NAT* doesn't solve any problems, it just puts the > burden on others who is unlikely in a situation to defend themselves > (the app. developers) ; the overall effect is counterproductive. > > Aside from that, once we talk not full-blown computers but embedded > devices, adding support for NAT penetration (STUN or whatever) is a > major problem. The original Arduino uses a microcontroller with 32KB > of flash (for program code) and 2KB of RAM, and that's already a fairly > big one. Adding STUN support there is a serious problem. > > > Again, this isn't meant as a flame or anything, but to show that > these technologies have serious implications for others.
To avoid some of that, they can go IPv6-only, including their servers and all peers they communicate with, then there doesn't need to be NAT64 for their traffic. But even IPv6-only they will need firewall traversal support, as firewalls by default will block unsolicited incoming traffic (RFC6092). -d
