On Mar 4, 2011, at 4:24 PM, Fred Baker wrote: > I'm not going to try, at least in this email, to address each of your points. > Here are a few comments, however. > > On Mar 4, 2011, at 1:00 PM, Keith Moore wrote: >>> 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. > > That wasn't my intention. My intention was to say that it's what we have on > the table. Another solution would be equally acceptable to me.
I don't think it's an either-or. I want DNS to work well. I also want IP addressing to work well. But if we're going to have NATs in IPv6, it strikes me as much easier to do NAT right this time and provide support _in the NAT_ that applications need to deal with the loss of e2e address transparency, than to try to retrofit a vast DNS deployment and change an immense amount of DNS-related mindshare in order to get DNS to do what apps need. But DNS needs to be cleaned up anyway. It's just that it will take 20 years to do it, if we can do it. >>> 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. > > let me try again to tease apart the bits I was trying to tease apart. > > Consider my laptop or my telephone. Unless I happen to have Skype running, it > is purely a client; I could offer services (a peer-to-peer service is a > service; it's just that client and server are interchangeable and may be > doing both jobs simultaneously on different sessions), but I don't. From that > perspective, the only reason my laptop needs a name is because other > applications use reverse DNS to determine what that name is. As it happens, I regularly ssh into my laptop from elsewhere using IPv6. Soon I expect to be doing it from my phone. Especially given that the vast majority of Internet hosts will soon be mobile hosts of some kind or another, I don't see why such hosts should be limited to running apps that don't need to accept inbound traffic. There are too many apps for which some form of asynchronous inbound notification is useful. Polling a central server for such notifications is expensive, both in terms of power requirements for mobile hosts and the cost to run those central servers. >> 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. > > Actually, no. But any system I want to send a SYN to does, because otherwise > I need some other way of determining its address. When we go that route - > well, please read RFC 4192. That's what makes renumbering hard. Doesn't follow. There are lots of ways to determine a host's address other than a DNS lookup. (though I certainly agree that renumbering is hard.) Keith _______________________________________________ nat66 mailing list [email protected] https://www.ietf.org/mailman/listinfo/nat66
