Isn't this discussion getting out of scope here and into scope for draft-carpenter-referral-ps?
The [email protected] list is alive and well for discussion of the referral problem, which is common to many scenarios, not just NPTv6. Regards Brian On 2011-03-05 08:23, 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. > >> 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. > > 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. > > 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. 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. > > 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. > > 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. > > 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. 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. 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. > > 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. > > 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. > > > _______________________________________________ > nat66 mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/nat66 > _______________________________________________ nat66 mailing list [email protected] https://www.ietf.org/mailman/listinfo/nat66
