On Oct 28, 2010, at 9:29 PM, Christian Huitema wrote: >> As Keith points out, to maintain Dynamic DNS AAAA records, the device has to >> be able to determine its own >> external addresses. If a static DNS configuration is maintained and privacy >> addresses do not periodically >> change (which kind of calls for Dynamic DNS), the DNS service can be >> maintained centrally >> without the collusion of the addressed systems. > > Another possibility is for the internal system to consider the "external" > address provided by NAT-66 as a "virtual interface", similar to what would be > obtained for example by a tunnel to the external gateway. That means the > internal systems could learn the available address through some configuration > function. Centralized DHCP servers come to mind, e.g. a DHCPv6 option > providing the translation value.
Considering only the NAT66 case, I would think an RA extension would be a far preferable way to advertise such things to hosts. Define a way to associate external prefixes with internal prefixes advertised by routers, in the same packets that advertise the internal prefixes to hosts in the first place. Though again, I don't think a mechanism that only works for NAT66 would be sufficient. I think we need a mechanism that works for NAT46 and NAT64 as well. And therefore it has to be able to handle port translation. DNS falls apart here because (among many other reasons) it was never intended to advertise transport addresses (i.e address/port pairs). Keith _______________________________________________ nat66 mailing list [email protected] https://www.ietf.org/mailman/listinfo/nat66
