cc v6ops where there is discussion on draft-chen-v6ops-nat64-experience 2012/7/6, Aleksi Suhonen <[email protected]>: > Hi, > > We've been running a NAT64/DNS64 setup at TREX Tampere Region Exchange > for over a year now and I'd like to submit the following experience for > your draft:
Your inputs are welcome. > IPv6 Privacy Extensions are a big problem with stateless NAT64. A single > device with priv exts enabled will use up several IPv4 addresses from > the NAT64 pool. And since the IPv4 Internet is full of malware probing > for vulnerabilities, the whole IPv4 address pool for the stateless NAT64 > will periodically get random traffic from the Internet. > > Even if the priv ext addresses have expired, the network will generate > an ICMPv6 unreachable message which will travel through the NAT64 device > and thus refresh timers for the IPv4 mapping. Some firewalls will also > generate TCP RST messages for such probes to non-existent IPv6 addresses. > > In fact, our worst experience has been with an Apple iPad which was left > alone in an IPv6 only WLAN which was using our DNS64 service. The iPad > thought that the WLAN was broken because it only got an IPv6 address and > no DHCPv4 response. It had time to send some packets using IPv6 through > the NAT64 which created the mapping. Then it reset its WLAN and tried to > associate with the same SSID again. Every time it created a new privacy > extension based IPv6 address and a new mapping in the stateless NAT64 > device. > > Within an hour, all the IPv4 addresses in the pool for our NAT64 were > registered to this one device. =>I may hardly understand that is a problem with stateless NAT64. RFC6145 doesn't require creating a mapping state because it's *stateless*. The package forwarding is based on mapping rules, which is nothing to do with *lifetime*. Therefore, above statement of IPv4 pool exhaustion may not apply to stateless NAT64. I suspect this problem may occur in a stateful NAT64 context. The frequent reclaiming behavior would consume unnecessary resource by creating overwhelming states on NAT64 box. Your further check is expected. > It would be my recommendation that there was either a Router > Advertisement Flags Option for "do not use privacy extensions here" and > that this was used in all setups that use DNS64 name servers, or that > all such setups should use Managed Address Configuration aka DHCPv6 > address configuration. Those potential solutions are worth to be discussed further. Especially, new added RA flags option would require additional specification efforts. Many thanks Gang > -- > Aleksi Suhonen, Researcher > Department of Communications Engineering > Tampere University of Technology > -------------------------------------------------------------------- > IETF IPv6 working group mailing list > [email protected] > Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 > -------------------------------------------------------------------- > -------------------------------------------------------------------- IETF IPv6 working group mailing list [email protected] Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 --------------------------------------------------------------------
