Re: The internet architecture
On Dec 22, 2008, at 10:51 PM, macbroadcast wrote: IP does not presume hierarchical addresses and worked quite well without it for nearly 20 years. IP addresses are topologically independent. Although since CIDR, there has been an attempt to make them align with aspects of the graph. Ford's paper does not really get to the fundamentals of the problem. I would suggest that deeper thought is required. would like to know bryans opinion I think I missed some intermediate messages in this discussion thread, but I'll try. :) IP addresses are just an address format (two, actually, one for IPv4 and another for IPv6); their usefulness and effectiveness depends on exactly how they are assigned and used. CIDR prescribes a way to assign and use IP addresses that in theory facilitates aggregation of route table entries to make the network scalable, _IF_ those addresses are assigned in a hierarchical fashion that directly corresponds to the network's topology, which must also be strictly hierarchical in order for that aggregation to be possible. That is, if an edge network has only one upstream provider and uses in its network only IP addresses handed out from that provider's block, then nobody else in the Internet needs to have a routing table entry for that particular edge network; only for the provider. But that whole model breaks down as soon as that edge network wants (god forbid!) a bit of reliability by having two redundant links to two different upstream providers - i.e., "the multihoming problem", and hence all the concern over the fact that BGP routing tables are ballooning out of control because _everybody_ wants to be multihomed and thus wants their own public, non-aggregable IP address range, thus completely defeating the scalability goals of CIDR. For some nice theoretical and practical analysis indicating that any hierarchical CIDR-like addressing scheme is fundamentally a poor match to a well-connected network topology like that of the Internet, see Krioukov et al., "On Compact Routing for the Internet", CCR '07. They also cast some pretty dark clouds over some alternative schemes as well, but that's another story. :) But to get back to the original issue, CIDR-based IP addressing isn't scalable unless the network topology is hierarchical and address assignment is done according to network topology: i.e., IP addresses MUST be dependent on topology in order for CIDR-based addressing to scale. But in practice, at least up to this point, other concerns have substantially trumped this scalability concern: edge networks want fault tolerance via multihoming and administrative independence from their upstream ISPs, so they get their own provider-independent IP address blocks for their edge networks, which are indeed topology- independent (at least in terms of the assignment of the whole block), meaning practically every core router in the world will subsequently have to have a separate routing table entry for that edge network. But this only works for edge networks whose owners have sufficient size and clout and financial resources; we're long past the time when an individual could easily get his own private Class C address block for his own home network, like I remember doing a long time ago. :) So small edge networks and individual devices still have to use IP addresses assigned to them topologically out of some upstream provider's block, which means they have to change whenever the device moves to a different attachment point. So in effect we've gotten ourselves in a situation where IP addresses are too topology-independent to provide good scalability, but too topology-dependent to provide real location-independence at least for individual devices, because of equally strong forces pulling the IP assignment process in both directions at once. Hence the reason we desperately need locator/identity separation: so that "locators" can be assigned topologically so as to make routing scalable without having to cater to conflicting concerns about stability or location- independence, and so that "identifiers" can be stable and location- independent without having to cater to conflicting concerns about routing efficiency. As far as specific forms these "locators" or "identifiers" should take, or specific routing protocols for the "locator" layer, or specific resolution or overlay routing protocols for the "identity" layer, I think there are a lot of pretty reasonable options; my paper suggested one, but there are others. Cheers, Bryan merry christmas Marc i believe that "Kademlia " [ 1 ] for example and the technologies mentioned in the linked paper [ 2 ] would fit the needs and requirements for a future proof internet. [ 1 ] http://en.wikipedia.org/wiki/Kademlia [ 2 ] http://pdos.csail.mit.edu/papers/uip:hotnets03.pdf -- _
The Great Naming Debate (was Re: The internet architecture)
So, after being distracted by OSDI last week, I'm now trying to catch up on the raging debates on TAE that are already exceeding all the wildest dreams I had before setting up the list... :) On the issue of weaning applications (and potentially transports) away from IP addresses in favor of names of some kind, I feel that a lot of the disagreement results from a misunderstanding of exactly what I (and perhaps others who have made similar proposals) was proposing... On Dec 4, 2008, at 10:29 PM, Keith Moore wrote: Hallam-Baker, Phillip wrote: I am trying to parse this claim. Are you saying that the DNS is fragile and raw IP relatively robust? DNS is layered on top of IP. So for a large class of IP failures, DNS won't work either. And if IP routing fails, DNS is likely to be irrelevant because the application using DNS won't work anyway. And in practice, DNS is quite likely to fail due to configuration errors, inadequate provisioning, outdated cache entries due to unanticipated changes, brain-damaged DNS caches built into NATs, failure of registries to transfer a DNS name in a timely fashion, etc. So it's not a question of whether DNS is less reliable than IP (it is), or even whether the reliability of DNS + IP is less than that of IP alone (it is). It's a question of whether increasing reliance on DNS by trying to get apps and other things to use DNS names exclusively, makes those apps and other things less reliable. And I'd argue that it does, except perhaps in a world where renumbering happened frequently, at irregular intervals, and without notice. And I don't think that's a realistic scenario. I entirely agree in principle with your concerns about reliability: if everything has to work correctly in two layers (DNS and IP), then that's strictly less likely to happen than hoping everything will work correctly in only one layer (just IP) - unless DNS can somehow make up for unreliability in the IP layer, which it occasionally might be able to do with some effort (e.g., via DNS-based load balancers that take end-to-end IP reachability information as input), but it usually doesn't because that's not the purpose of DNS. And I agree that some applications (and some users) sometimes need to deal with IP addresses directly, and probably still will need to for a long time, maybe forever. You seem to be assuming that my proposal was to disallow such "visibility into the network" entirely, but that wasn't my intent at all. I just would like it to become no longer _mandatory_ for every application to know about the structure IP addresses in order to accomplish anything. To be specific, there are (at least) three positions we might be in: 1. ALL applications MUST know about IP addresses, in each IP address format that exists, in order to operate at all. This is the current state of the world for applications that use the sockets API, because apps have to call gethostbyname etc. and copy the resulting IP address(es) into sockaddr_in or sockaddr_in6 structs to pass to connect() et al. Even though the sockets API is "generic" in that it supports multiple address families, its design forces the application to have code specific to each family in order to support that family at all, which is the key problem. 2. ALL applications MUST use only DNS names for all operations, and never provide or see IP addresses for any reason. This seems to be what you're assuming I'm suggesting (i.e., where you say "...by trying to get apps and other things to use DNS names >>exclusively<<"). That's a world we might hold up as an ideal to strive for eventually, but it's indeed not realistic in the short term, and it's not what I'm pushing for. Besides, there may be many different naming or host identity schemes we might eventually want to support besides DNS names - e.g., UIA personal names, HIP cryptographic host identities, ... 3. Applications MAY be aware of IP addresses if they need to be for whatever reason, but aren't ALWAYS forced to have hard-coded dependencies on the existence and structure of IP addresses by the API's design. Applications see IP addresses as variable-length string blobs of some kind - e.g., along the lines Florian Weimer suggested in another message. Applications can parse/interpret or create these blobs if they want/need to, but don't necessarily have to if they're just passing the blob through from the GUI or URL parser to the OS's protocol stack. This is the position I think we need to be pushing for. In short, I don't think either the current fascist extreme of an "IP- address-only API" or the opposite fascist extreme of a "DNS-name-only protocol stack" is very appealing; we need an environment in which different kinds of names/addresses/identities can coexist. You'll still be able to enter an IPv4 or IPv6 address instead of a host name when you need to, and applicat
Re: The internet architecture
I know this follow-up is a bit late, but on the topic of transitioning upper-layer protocols such as transports and applications toward being "IP address oblivious" - either by using DNS names instead, or location-independent crytpographic identifiers as in HIP, or personal names as in UIA, or something else - I just wanted to suggest that the new "Transport Architecture Evolution" ([EMAIL PROTECTED])) mailing list that I set up just after the IETF meeting might be a good place to discuss such architectural issues, especially in terms of the way they affect application<->transport and transport<->network layer interfaces. To throw in my quick $.02 (and perhaps invite more discussion :) ), I think we absolutely need to migrate both networking APIs and transport layer protocols themselves toward a model where an "endpoint" is an opaque (to the transport/application) variable-length string of some kind, and the transport/application shouldn't even care much if any what exactly the string is. The string could potentially be a DNS name, a dotted IPv4 address, a colonificated IPv6 address, a hex- encoded HIP cryptographic host identifier, a UIA personal name, ... And sure, the semantics of these different kinds of "endpoint strings" will vary depending on what they actually are, and for network management purposes they won't all be equivalent or interchangeable, but for purposes of normal transport and application protocol operation - i.e., "gimme a TCP-like connection to the endpoint named 'X'", why should transports and applications need to care? Just think how much easier the IPv4 to IPv6 transition would have been if nothing above the IP layer cared exactly what an IP address looks like or how big it is. Cheers, Bryan ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
