On Mar 4, 2011, at 2:23 PM, Fred Baker wrote: > On Mar 4, 2011, at 10:21 AM, Keith Moore wrote: > >> On Mar 4, 2011, at 12:58 PM, Christian Huitema wrote: >> >>> There is actually much to be said for the idea of "let the applications >>> figure out what they're going to do as a result." Something like the >>> end-to-end argument. We don't want to force the network to do heroic feats >>> if the problem could be solved simply in an end-to-end manner. It seems >>> that "PI everywhere" belongs in the "heroic feats" category. >> >> I'm sort of all right with that idea, provided (a) you give the applications >> enough information so that they can figure it out without having to have >> their own dedicated infrastructure, and (b) the solution for the application >> isn't overly complex, and doesn't significantly impair performance or >> reliability. >> >> nptv6 by itself, as currently defined, falls a bit short of that. At least >> one missing piece is the lack of a built-in mechanism to allow an >> application on the "inside" of the NPTv6 to discover its "outside" address. > > There I agree and disagree. I agree that NPTv6 does not itself provide that > information; I think it is out of scope for the draft. There are a couple of > ways that the function could be created, and you have dismissed each of my > suggestions. So from my perspective, the ball is in your court to suggest a > solution that is acceptable for applications and works in the context.
I agree, in a sense, that it's out of scope for the NPTv6 specification - because such a mechanism needs to be applicable to all NATs (not just NPTv6) that find their way in between any application using IPv6 and its peer. However, it's not out of scope for the box that implements NPTv6. IMO it's an absolute requirement for such a box. A detailed proposal will take time, not only to write the proposal but also to compare with other, similar ongoing work (such as PCP). >> Though I agree with Fred about many of the cost-benefit tradeoffs (and will >> reply to his recent message in more detail when I have a bit of time). >> >>> There is indeed evidence that the problem can be solved end-to-end. This is >>> why we developed STUN, TURN, ICE. These solutions are not perfect, and they >>> don't cover TCP very well. (I know TURN does cover TCP, but at the cost of >>> a TCP relay, i.e., not very well.) If the end to end groups knew for sure >>> that "this is the deal," applications and transport protocols would surely >>> evolve. >> >> STUN, TURN, ICE are not e2e solutions. They require support from the >> "middle". Any solution that requires a 3rd party server to sit in public >> address space and mediate between the endpoints (even if just to establish a >> connection) imposes a high barrier to deployment of new applications. > > Maybe we're not solving the same problem. Help me out here. > > When you talk about an "end to end solution", the picture that comes to my > mind is that a peer in a random other part of the network tells me what my > address is. The question that immediately comes to my mind is "how did I find > his address?" Chicken, meet egg. He needs a solution that will enable me to > find him without my first knowing his address. If that's not what you mean, I > need to understand what you mean. The general case is that A wishes to inform B, that B can reach some potential peer C using some address or set of addresses. They wish to do so without external assistance - without needing to involve a 4th party that is known to be in a non-NATted realm. Assume that A and B already know how to talk to each other, and A knows a way to talk to C. Note that each of A, B, and C can potentially be in its own realm distinct from the others. So there are at least 5 different cases against which any potential solution must be analyzed: A, B, and C are all in the same realm A is in one realm; B and C are both in a different realm B is in one realm; A and C are both in a different realm C is in one realm; A and B are both in a different realm each of A, B, and C is in its own realm (Actually it can get a bit more complicated than that as one realm can encompass another. But this only matters if the proposed solution depends on realms either being the same or disjoint.) The simple solution looks like this: each of A, B, and C has a public, globally scoped address they always include those addresses in referrals (perhaps in addition to ULIAs) when trying to reach a peer, applications always try using the public, globally scoped address of a peer (perhaps while also trying to use a "better" address for some meaning of "better") This implies that applications have to have a way to find out their external addresses. That doesn't seem like it should be such a big deal, but it often is. (The above statement are also true if you substitute "DNS name(s)" for "address(es)". I don't actually think of one of these solutions as being right and the other wrong - I think that the choice of whether to use addresses vs. DNS names in referrals is essentially a question of whether you prefer to use a token that's fast but perhaps has an ephemeral binding to the destination, vs. a token that's slower and more prone to misconfiguration but perhaps less ephemeral. And of course you can always try both, perhaps concurrently.) > I know you don't like DNS. I don't either; I think we need a directory-based > solution. Until you or someone else proposes a DNS replacement, DNS is what > we have. So for name translation to addresses, I think in terms of DNS. Saying "you don't like DNS" makes it sound like my personal preference. I'd be happy to use it if it worked well. The truth is that (even without having to deal with multiple realms) DNS doesn't work well enough in practice for applications to rely on it. It works if you're trying to look up the address of a public server, because those servers are relatively few in number, they often support essential services like email and/or web presence, and network administrators tend to find out fairly quickly if the DNS isn't set up well enough to suit that small number of essential applications. (Though it's amazing how often enterprise network administrators can be blissfully unaware that they don't have their MX records set up correctly.... because nobody outside their enterprise can send them mail to tell them.) But DNS doesn't work well enough to allow arbitrary hosts to communicate with one another, even if they have permission to do so. Even if DNS were perfectly maintained, always in sync with reality, servers always up and reachable, etc., DNS would not solve the referral problem. It would just move it, and add complexity. Just like application instances don't have a reliable way of knowing what IP address(es) can be used to reach them from anywhere, they don't have a reliable way of knowing what DNS name can be used to reach them either. PTR lookup does not work, not only because the host might be behind some sort of NAT (and using address space for which ip6.arpa and/or in-addr.arpa are not populated), but more importantly, because it's very frequently the case that a host moves from one ISP to another and doesn't have a stable DNS name.) > NPTv6 presumes that the DNS somehow knows what prefixes are in use in a > domain. That might be human: when the network administrator adds an AAAA > record to DNS, he includes such a record for each of the addresses that the > interface might have. That's equally true for shim6 and other solutions; if I > have N addresses, I need N AAAA records associated with my name, one for each > prefix. That's ok, I'm not a big fan of shim6 either :) > There are several possible ways to do this, but I would expect that the > simplest and most reliable mechanism is a tool; the administrator supplies > the name, one of the addresses, and whatever other information is required, > the DNS management tool looks up the various prefixes, and creates AAAA > records for each address. In a static world (IPv6 address derives from MAC > address or is manually assigned), job done. Yes, that's what I anticipated when I argued, back in the late 1990s, to get rid of A6 records and associated cruft. Let the DNS server essentially implement prefix macros that can expand to multiple AAAA and/or PTR records, just don't make those macros explicit DNS records. (This does, however, beg the question of how a host should use Dynamic DNS to update its own RRs if it doesn't know all of its own addresses.) > Now, not all systems need names. This is a digression, but an important one > given the opening sentence of the next paragraph. On Cisco's network, my > laptop has a name right now that is associated with its address - > stealth-10-32-244-219.cisco.com. The derivation is obvious - they gave me a > /29 for my office and statically built a name for the purposes of reverse > DNS. Reverse DNS in an IPv6 world that contains laptops is an "interesting" > proposition; I would suggest that the DNS server ping the host in question > and respond in one of two ways depending on the reply; it can reply "no such > address" if there is no reply, or respond with a name if there is. If it has > a name in its database (www.example.com), it should reply with that; if not, > it should generate some temporary name and respond with it. Not that anyone > would ever use that name to access my laptop (if they're going to, they need > a more permanent name), but it serves reverse DNS's purposes. It's true that not all systems need to be reachable by other hosts, but the vast majority do under at least some circumstances. If you want to insist that "reaching" a system should always start with a DNS lookup, this implies that (nearly) all systems do need DNS names. Of course it's quite often the case that they don't have them, and if they do, the names are often meaningless and not actually bound to the host at all, but only to an IP address. That's a big part of the problem with relying on DNS names for referrals. (DNS results should NEVER depend on whether a host is reachable by ping from the DNS server, and a DNS server should NEVER respond with NXDOMAIN when the domain normally exists but there don't happen to be any valid records matching QTYPE. The proper response in the latter case is to return no error, with zero records.) > If you are using privacy addressing or moving a laptop around, AND the > interface in question has a permanent name (not a bad idea for ddos > protection, for example), I think the solution is Dynamic DNS. A host > announces to DNS that it now has a new address to associate with its name > (and says a DNS lifetime later that DNS should forget its old address), DNS > applies the same transform to the record it was given, and now knows all of > the relevant addresses. Not only do I use Dynamic DNS myself, I actually implemented my own client for it. When I did, I noticed that my ISP at the time had imposed a DNS interception proxy that kept the update records from getting to the server specified in the IP destination address header. The interception proxy would reply but the request never got to the authoritative server for the zone. Eventually I reconfigured the DNS server and the client to use a different port. That worked fine for me but I'm not sure how well that will work in general. Before I wrote my own Dynamic DNS client, I looked around at existing DNS update service providers and didn't find a single one that used the Dynamic DNS protocol. They all used HTTP, and from what I recall, they were mostly pretty lame. E.g. they had a way to update your A record but not other records - maybe not even AAAA. Another problem is that a lot of people think that it's the job of the DHCP server to update the DNS, so you get situations where the DHCP server and the host argue about what the host's resource records should be. So yeah, Dynamic DNS nice if/when you finally get it working. But I think there might be some significant barriers to widespread adoption of Dynamic DNS for this purpose. Also I'll note that Dynamic DNS rarely helps you get the "reverse DNS" lookup right. In the very common case where you get your address from your ISP, you generally don't get the ability to update the PTR records associated with that address. So whatever name results from a PTR lookup won't help a peer get back to your host in the future after your laptop has moved and/or your ISP has assigned a different address. I don't see that as a huge loss, but it does mean that doing a PTR lookup on your own IP address doesn't reliably give you a DNS name that's useful in referrals. > If an application on one host wants to refer to an application on a different > host, it could include the DNS name of the other system in its referral > record; I'm told that CERNET did a detailed study to see how many referrals > did that, and found that the number that didn't was a vanishingly small > percentage. I can believe that most referrals include some DNS name, because applications doing referrals have a strong incentive to provide every name or address that might conceivably work. A more relevant question is how many of those DNS names would actually work if/when used. Of course the particulars matter - what applications they were looking at, and what environments they were looking in. > If they really want to include an address, the referring host can look up the > DNS record itself and as a result know the addresses. No it can't. Because the host doesn't reliably know its own name. Or more precisely, the host doesn't know which name(s) in DNS can reliably be depended on to reflect its current addresses, and there's no reliable way of finding out. Neither DHCP nor PPP nor host APIs (e.g. gethostname()) can be trusted to return suitable DNS names. Ideally, a host's DNS name(s) should be properties of the host to which they're assigned, and the host should know its own name(s) except for those cases where the hosts really are intended to be anonymous. But in many cases cases, hosts are given names which have only a vague relationship with their DNS names, or which aren't reflected in DNS at all. > There is a question of the lifetime, but it's not impossible to deal with. > Similarly if a host needs to know all of its own addresses; if DNS knows > them, it can ask DNS a few milliseconds after it has sent the DDNS update. see above. > If a host needs to know all of its external addresses and doesn't want to use > DNS, or would like to know among the possible options which addresses to > recommend, I would suggest something akin to STUN but a little different. > Have the NPTv6 translators join a site-local multicast group "All NPTv6 > Translators", and enable the translator to reply to an appropriate ICMP > message "what's my address" with a list of zero or more translated addresses > - if one system embodies translation into two ISPs, it would respond with one > ICMP that contains two external addresses, for example. If a system is trying > to make a recommendation, it might send the request and collect the first N > responses or the responses that arrive within a stated interval, and inform > Dynamic DNS of those addresses. Something like that is worth investigating. One potential problem is that "site" boundaries can be fuzzy. But in general, I think that such a facility is needed, and this seems like something that would be a good fit for ICMPv6/ND/RD. > As to how DNS knows what addresses to give in a response, I can think of > three algorithms quickly: > - There is one DNS database containing both internal and external > addresses. When asked about a name, it gives all the addresses > it has; the application decides which of them it will use. > - There are two DNS databases, one containing both internal > addresses and one containing external addresses. DHCP tells > local systems to access the internal server; all others ask > the external server. The servers, however, are identical to > the first case; when asked a question, they give the answer > they know. > - Whether there are one or two databases is irrelevant; the DNS > server looks at the source address on a DNS request and either > by filtering records or by inspecting the right database > replies to any request that comes to it in a manner > indistinguishable from the second case. > > The first two are well-known and widely-deployed - simple DNS, and a split > DNS. I have no idea whether the third exists or whether there is a market for > it. Bottom line, I don't see a problem between internal and external > addresses that we don't already know how to solve. We may not like the > solution, but that doesn't mean a solution doesn't exist. I've always been dubious of split DNS. DNS wasn't designed to be used in that way, and there's nothing about the DNS protocol or DNS implementations that constrains DNS queries to be made from the same locations that are using the results of those queries - quite the contrary, actually. I realize that split DNS works fine for many enterprise networks that impose a lot of control over their hosts and the applications that they happen to run, but that doesn't mean that it works well in general. IMO, DNS servers should always return the same response to any particular query, regardless of where the query is coming from. More generally, I don't think that it's DNS's job to try to second guess what the host or application needs. Something like happy eyeballs is better suited for letting applications figure out which addresses to use. )Though there are plenty of problems with that too if the number of addresses associated with a host gets very large, and there are several reasons why this might happen.) Still, I won't pretend that we can eradicate Split DNS. I just don't think that the network architecture should depend on it. Keith
_______________________________________________ nat66 mailing list [email protected] https://www.ietf.org/mailman/listinfo/nat66
