On Oct 27, 2010, at 8:28 AM, Fred Baker wrote: > On Oct 27, 2010, at 5:14 AM, Keith Moore wrote: > >> IMO, a minimum requirement for any v6 NAT approved by IETF is that >> hosts/apps MUST have a way to determine the external/global addresses >> associated with a connection without needing an external server in global >> address space for ICE or similar tricks. >> This mechanism MUST be the same mechanism for all standard NATs. > > I can think of ways to do that, for example for populating your Dynamic DNS > entry, but it also has issues.
yeah, including that some ISPs (like mine) intercept traffic to port 53. and the fact that not all sites maintain DNS records for all of their hosts, or want to. also, DNS works on a per-host basis but NATs in general (not NAT66) work on a per-binding basis, so a general mechanism for letting hosts/apps know what address is associated with a connection can't use DNS .. at least not in the way we currently use DNS. > Depending on the source address you choose (for example if you are in a > multihomed host for which the default route in the network differs in the > various subnets), you may take different exit gateways in routing, and > therefore may have different addresses as seen by your peer. Ideally, ILNP or > NAT66 minimizes that, but it is still a possibility in the local network. > Hence, in order to accomplish that, you will have to in some way ask the > routing system. why not put the burden on the part that's causing the problem? i.e. why not build the functionality into the NAT? > ICE accomplishes it by routing a packet to a remote peer that can report your > address as it perceived it. At minimum, I should think you would have to > communicate with the DMZ that updates your prefix. As a result, I doubt that > it will be a procedure you can execute autonomously, or that could be done > by, say, your DNS server. > >> People need to stop insisting that hosts and apps don't need to know their >> addresses. > > People are not insisting that applications don't need to know their own > addresses. What people (I) are pointing out is that the assumption that your > address is meaningful to someone *else* is a problem. This is the root cause > of the issues raised in RFC 2993. the address is only (okay, mostly) meaningful because it's the only way to contact a process that's already using the address. Keith _______________________________________________ nat66 mailing list [email protected] https://www.ietf.org/mailman/listinfo/nat66
