On Mar 4, 2011, at 11:35 AM, Brian E Carpenter wrote: > 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.
I have no problem with moving the discussion there. Understand, however, that this is not limited to referrals, and is Keith's primary concern with NPTv6. It's relevant here because for Keith it is a requirement on 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
