RE: Thinking differently about names and addresses

["Tony Hain" <[e-mail]>]

John,

I am not going to comment on each point, but your general perspective
highlights the problem at hand. The discussions on the multi6 mail list
have basically been about how the routing community believes the address
is the topology locator, while your & Dave's comments show the app
community believes it is an identifier. Where the two communities agree
is that the DNS as currently deployed and operated is not up to the task
of handling the identifier role. My point is that this is due more to
implementation & operation than architecture. Also I believe the multi6
discussion about creating a new identifier, to get the app community to
stop camping on the topology locator, will end up creating a distributed
database infrastructure almost identical to DNS. We don't need two of
those, so we should fix DNS.

I disagree with the perspective that subnetting or CIDR changed the
character of the address. It continues to indicate on the local network
or not, and anything not is handed to a node tasked to figure out the
next hop. I think what has changed since RFC 791 is the geographic scope
of the local network, not the architectural concepts.

Tony


> -----Original Message-----
> From: John C Klensin [mailto:[e-mail]] 
> Sent: Monday, March 31, 2003 10:13 PM
> To: Dave Crocker; Tony Hain
> Cc: 'Margaret Wasserman'; [e-mail]
> Subject: Re: Thinking differently about names and addresses
> 
> 
> --On Monday, 31 March, 2003 16:44 -0800 Dave Crocker 
> <[e-mail]> wrote:
> 
> > Tony,
> >
> >>> Let's assume that there is a FooBar server in SiteA.  If another 
> >>> node in SiteA (NodeA) is communicating via a multi-party 
> application 
> >>> to a node in SiteB (NodeB), and wants  to refer NodeB to 
> the FooBar 
> >>> server in SiteA, what does it do?
> >
> > TH> Send a name.
> >...
> > In any event, please note that the suggestion that  
> applications are 
> >required to use names, rather than IP  addresses, is new.
> >
> > Completely new.
> >
> > As in, it has not been part of the Internet architecture 
> for the past 
> > 25 years.
> >
> > So we all should be a tad careful about claiming that 
> failure to use 
> > that enhancement represents a failure.  A new idea that is good is 
> > good, but failure to use that idea previously is not "broken".
> 
> Hmm.  Maybe some clarification is in order, since at least three 
> different, and contradictory, claims have been made about this 
> principle.
> 
> The "use names and not addresses to facilitate the transition to 
> IPv6" principle was articulated some years ago, I'm pretty sure 
> back when I was still Apps AD.   It was discussed at the time, 
> and should not now come as a surprise to anyone.   However, my 
> understanding --then and now-- was that what we agreed to was to 
> try to move away from the presentation form of IP addresses on 
> the user interface side of applications.  For example, we wanted 
> to strongly discourage the use of addresses in URLs, we wanted 
> to see an address in a telnet command or in setting up an FTP 
> command channel only for debugging (if that) and so on.
> 
> Today's implied claim that the principle extends to use of names 
> within and between applications is new to me.  There are all 
> sorts of reasons why I think it is impractical. Certainly it is 
> not something I would have consciously agreed to at any time in 
> the last decade or so.  In addition to the reasons that have 
> been given, there is the small matter that DNS resolvers use 
> timeout logic that is measured in seconds -- tolerable for 
> one-time use when an application starts up, and maybe every 
> half-hour or so thereafter, but almost inconceivable each time 
> an application needs to look at an address or pass an address 
> reference to a machine with which it is already conducting a 
> dialogue.  Worse, some applications are likely to get very 
> confused if they go back to the DNS a second time and get very 
> different address information (or even a different ordering of a 
> set of addresses) to be used in conjunction with connections 
> that are already open.
> 
> Now, this may suggest that we need new facilities.  Or perhaps 
> we just need a way to say "use this address, but the same prefix 
> you already have for me" or "look the name up again, and pick 
> the address you get back that matches the prefix you see for 
> me".  I don't know.  I am pretty sure that no one has discussed 
> those issues with the applications area at any time since IPv6 
> started to gell.
> 
> I'm equally concerned about statements like:
> 
> TH> Any app that sends topology locator information without
> understanding
> TH> the topology is broken.
> 
> and
> 
> > That is not clear, but in any case the deployed Internet is not the 
> > same as it was 25 years ago. From RFC 791;
> 
> > 	A distinction is made between names, addresses, and
> > 	routes [4].   A name indicates what we seek.  An address
> > 	indicates where it is.  A route indicates how to get
> > 	there.  The internet protocol deals primarily with
> > 	addresses.  It is the task of higher level (i.e.,
> > 	host-to-host or application) protocols to make the
> > 	mapping from names to addresses.   The internet module
> > 	maps internet addresses to local net addresses.  It is
> > 	the task of lower level (i.e., local net or gateways)
> > 	procedures to make the mapping from local net addresses
> > 	to routes.
> 
> > Mapping names to addresses is a simple task. One could 
> argue that it 
> > was so simple that apps took the shortcut of using the 
> 'where' to also 
> > define the 'what'. That does not mean the requirement for 
> apps to keep 
> > a clear context for 'what' is a new requirement.
> 
> Tony, I agree with the first statement.  I'd almost suggest that 
> it is self-evidently true, which may be the point you are trying 
> to make. But we get different meanings from the RFC 791 quote, 
> and that may be a lot of the difference in perspective here.  At 
> the time 791 was written, addresses were not routes, or bound to 
> routes.  Consequently, it would have been inappropriate to refer 
> to them as "topology locators".  They were just addresses. 
> Routes, and hence topology and topology locators, were 
> invisible, not only to the applications, but even to TCP.  An 
> application that uses addresses in the 791 sense isn't involved 
> with topology at all and has no clue about network topology. 
> Even the "here" and "not here" implied by testing whether an 
> address was on the same network was, and remains, invisible to 
> most applications.
> 
> When we introduced subnetting and then CIDR and, more 
> specifically, route aggregation, we changed the character of 
> that name/ address/ route separation.  For the first time, an 
> address manifestly implied more about topology than "same 
> network or not".  In the process, we effectively introduced the 
> notions of PI and PD space, and made multihoming nearly 
> impossible for anyone but very large enterprises plus those with 
> the financial resources to bully their way in.  But, even then, 
> I suggest that calling an address a "topology locator" is 
> something of a stretch, so, while your statement is true about 
> "topology locators", it is not clear to me that it applies to IP 
> addresses, at least in IPv4.
> 
> The IPng effort started off with a number of problems to be 
> solved.   More address space was one.  My recollection is that 
> getting multihoming back was another and that we knew that we 
> had a route-scaling problem as well as an address-scaling one. 
> This multiple-prefix-per-host stuff is dandy in theory, but 
> we've yet to see it work to permit widespread multihoming 
> without exploding the routing tables.  My own sense is that it 
> will not work unless we end up dividing the world up into a 
> handful of super-ISPs with local ISPs organized in strict 
> hierarchy.  To overdramatize things a bit (I hope), if the IPv6 
> architecture requires that business model in order to keep 
> routing working, IPv6 will fail and, probably, so will the 
> Internet.
> 
> My hope continues to be that we will eventually devise, and 
> evolve to, a routing architecture with much better scaling 
> properties than full-knowledge link state models and Dijkstra, 
> or Dijkstra-equivalent, calculations performed on each state 
> change.  While there hasn't been much visible motion, I don't 
> believe the IETF community has given up on that class of change. 
> To decide that IPv6 addresses are locators that are bound to the 
> topology of the network, and doing applications design on that 
> basis, runs the risk of precluding such routing options.    I 
> haven't seen where or when the community has agreed that "IPv6 
> Address == topological locator" as a matter of architecture and 
> I'm fairly relieved by that.
> 
> And, as Dave Crocker pointed out (if I interpret his remarks 
> correctly), if IPv6 addresses are topology locators, then we are 
> going to need identifiers that have the appropriate binding 
> properties to those addresses.  The DNS won't do it: it is too 
> slow, updates take too long, inconsistent responses from 
> different servers while updates propagate are the norm, and it 
> isn't tightly enough bound to the addressing mechanism to be 
> able to yield "best address for purpose" information.
> 
> My own guess is that the principle behind the statement you 
> quote from 791 is correct, but the terminology may need to be 
> adjusted.  Today, I would say that there is an important 
> separation between name, address-identifier, and 
> topology-locator.  If IPv6 addresses are the topology-locators 
> of the IPv6 universe, then there isn't going to be much real 
> progress on application upgrading and deployment until we invent 
> address-identifiers.  On the other hand, if IPv6 addresses are 
> to serve as address-identifiers (as IPv4 addresses have done 
> since the 70s), then we shouldn't expect applications to either 
> understand any hidden topology semantics they might have or to 
> refrain from using the addresses because those topology 
> semantics exist.
> 
>   regards,
>     john
> 
>