On Oct 27, 2010, at 10:45, Fred Baker wrote: > On Oct 27, 2010, at 10:04 AM, Chris Engel wrote: >> >> I actually wouldn't have any objection to some mechanism built into NAT that >> allowed for a requesting host/application to be informed of the Public >> Address it would be assigned by the NAT device. > > I don't object to that either. I do question the requirement apart from > Dynamic DNS. [...]
I can offer an answer to that question. The DNS, assuming it's extended by <http://tools.ietf.org/html/draft-cheshire-dnsext-dns-sd>, is only one of many available service directory protocols, and it may not be the most appropriate for all applications. Some applications may very well prefer to trade the federated administration for more responsive service availability signaling. Applications that incorporate different or integrated service directories must themselves be allowed to perform self-address fixing by communicating directly with any translators in all the paths between any hosts. On the other hand, there is another cross-cutting concern, i.e. applications that rely on their hosts using Dynamic DNS but need to be made transparent in the face of NAT66. The B2B usage scenario for NAT66 implies that exterior source addresses correspond to destinations in private enclaves. Those source addresses may be unique-local [RFC 4193], and in any case not publicly reachable. Therefore, they should not be published in the public DNS horizon. This means we probably need something like DNS66 alongside NAT66, so that when a host advertises its interior address with Dynamic DNS, there is a DNS66 process that transfers that registration into any private DNS horizons as required. -- james woodyatt <[email protected]> member of technical staff, communications engineering _______________________________________________ nat66 mailing list [email protected] https://www.ietf.org/mailman/listinfo/nat66
