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
