On Oct 27, 2010, at 9:08 AM, Keith Moore wrote: >> I still don't understand the reason you need your *external* addresses apart >> from populating DDNS. > > That app still needs an address that functions as a referral address for any > host to which it might need to make a referral. And the app has no way of > knowing which realms those hosts are in. So basically it needs a global > address.
Well, and it needs to supply both IPv4 and IPv6 addresses when appropriate, and there may be multiple of each that might be relevant. To me, that translates to "DNS Name". If it really has to be a literal, which I already pointed out has some brain-deadness related to IPv4 and IPv6 routing (the fact that you and I both have an IPv[46] address doesn't mean that the network has a route that connects them, even if the addresses are global). But that is not is not its *own* address; it is the address of a neighbor. > There are lots of problems with relying on DNS to do referrals which have > been reiterated several times. The bottom line is that DNS is one way of > doing referrals which is suitable in many cases, but far from suitable for > every case. If you are adamant that the web/sip/whatever referral can't be a DNS name, will you allow the referring host to look it up in DNS? As noted, DNS will have the external addresses of any system it has a name for. >> In private email to someone else that was requesting that hosts implement >> the expired SAF virtual interface functionality, I said the following. Tell >> me, if you would, where I'm wrong? > > You cannot impose NAT In several statements here you make the statement "you...impose NAT". Note that I am, and Margaret is, doing nothing of the kind. Network operators are trying to solve a very real problem, one that has been articulated in detail, and Margaret and I are providing a tool to enable them to do that. Absent the problem, the solution isn't needed and won't be deployed. The folks on this list that have been telling you that they plan to deploy something are telling you they have a problem that needs to be solved. > of any kind without breaking apps, and therefore, without requiring changes > to hosts. The objective of NAT66 might have been to not impact host > implementations, but that was unrealistic. Or maybe you defined "host" in > such a way as to not include apps, but the bottom line is that either way the > contents of files on hosts have to change in order to cope with the NAT. > (Assuming approximately the same barrier to deployment in both cases, it > makes MORE sense to require only host operating systems to upgrade than to > require apps to upgrade - though in practice the latter might be easier > because (a) most apps probably don't need to be upgraded, so there's less > initial pain, and (b) it aids deployment immensely if host/app upgrades can > be decoupled from network upgrades.) > > If you're going to impose NAT, it makes more sense to define NAT in such a > way that apps and hosts can reliably find out how to function in that world, > than to expect apps and hosts to use heuristics in the hope that they can > function in that world. > > I need to look more at ILNP - but I think what is needed is a solution that > doesn't immediately require host upgrades to work. On the other hand, if a > non-upgraded host would still work but an upgraded host got better > performance, that would provide an incentive to upgrade the hosts. I agree that host upgrades should not be required. That is the reason that Margaret and I are proposing a solution that doesn't require host upgrades that we know of. > Ideally, the application doesn't want to fool with address selection. But > unless the host stack and/or network do a good job of getting packets from > the source to the destination, via an effective route and without corrupting > those packets, some applications are forced to deal with such things. "Happy Eyeballs". http://tools.ietf.org/html/draft-wing-v6ops-happy-eyeballs-ipv6. If the socket API were rationally designed, what it is saying would be buried in a connect_to_name() call that was handed a name and returned a connected socket or an error. I agree that the OS should supply this. The socket API isn't designed that way; the application is forced to supply the missing code. Sorry, not my choice. I believe that this is being discussed in apparea. > So there are definitely hazards associated with virtual interfaces that try > to do address selection - unless those virtual interfaces have access to > reliable information that lets them make good choices. (Note also that > address selection is in some sense a quality-of-service issue - one pair of > addresses might work well for one application, and a different pair work > better for a different application.) > > Also note that putting "all relevant addresses" in DNS doesn't remove the > burden of address selection - it just moves the problem around. But again, > DNS is simply not suitable as a general-purpose referral mechanism. > > Keith Thanks for answering my question regarding the text following. It implies to me that my analysis is correct. >> On Oct 27, 2010, at 7:31 AM, Fred Baker wrote: >>> Personally, I think the expired SAF draft is lacking in some important ways. >>> >>> The notion of a virtual interface on which the host knows its external >>> addresses is intriguing. However, I don't know of any such implementation >>> on Windows, Apple, Solaris, Linux, FreeBSD, or other platform. One of the >>> objectives of NAT66 is to enable the deployment of scalable routing in the >>> transit backbone without impacting host implementations; if I were willing >>> to require changes to host implementations, I would be pushing ILNP. That >>> is IMHO a technically superior solution (the host identifier is the same >>> regardless of exit gateway, while with NAT66 EID checksum adjustments the >>> host identifier changes), but requires all TCP and UDP implementations be >>> simultaneously updated. So requiring a host change seems to me an >>> ill-considered - and untested - poison pill. >>> >>> Also, routing can be highly variable depending on the route chosen. A case >>> in point was tested by Geoff Huston at my request for the IAB in perhaps >>> 1999 or 2000. My point was to demonstrate that the choice of source and >>> destination address pair affected a session's experience of the network. >>> Geoff, from his host in Canberra, pinged two hosts in Singapore that were >>> physically under a kilometer apart but had different routing due to >>> difference in contract. One route followed a cable directly from Australia >>> to Singapore and was under 100 ms RTT; the other went to Singapore via San >>> Francisco and was over 600 ms RTT. Presumably, if they had been the same >>> multihomed host with addresses from two providers, the user experience >>> would be at the mercy of the vagaries of address selection. Putting those >>> conflicting addresses on the same virtual interface gives the application >>> very little guidance and less control over that experience. >>> >>> The latter point comes back to the "happy eyeballs" draft; I think that >>> applications should not be in the business of choosing their addresses, and >>> the underlying operating systems should take on the task of opening >>> sessions that have something that approximates the best RTT available; the >>> specific algorithm proposed in the "happy eyeballs" draft may not work on >>> all operating systems, but the results it achieves should be achievable, >>> and are important to users. >>> >>> As to the value of an application knowing its external addresses, to my way >>> of thinking that is debatable. It is necessary for DNS to advertise all of >>> the relevant addresses, and in the case of Dynamic DNS the host will need >>> to be able to determine what those addresses are. Once that is done, the >>> only reason an application has for knowing its own address is if it will do >>> something different based on its own address in a session; other than that, >>> it may express curiosity, but sessions that get to it obviously used one of >>> its addresses. I know of applications that do something different based on >>> peer addresses (mail MTAs, for example, often do a reverse DNS lookup on >>> the peer's address and applies an anti-spam policy based on it), but can't >>> say I know of applications that do something different depending on which >>> address of their own is used. And in any event, in a network that places >>> NAT66 between itself and its upstream, the datagram would never arrive at >>> the end system u sing the external address - it would always be the internal address. So such discrimination would be difficult. _______________________________________________ nat66 mailing list [email protected] https://www.ietf.org/mailman/listinfo/nat66
