contents: On list bandwidth and message volume On the "need" for "local addressing" On use of link-local addresses by IPv6 applications On address selection policy On "solving the right problems" and the layer of indirection On "The IETF doesn't tell people how to run their networks"
---------------------------------------------------------------------- I. On list bandwidth and message volume: This message is an experiment. Some people have expressed concerns about the number of messages being sent to this list. Personally I think we have a tremendous amount of work to do here, and I don't see how we can accomplish that much work without a high-bandwidth discussion. However I am sure that there are better ways to make use of the bandwidth we have than to have very long threads where we argue about minute details of each other's musings. (On the other hand, if we make independent statements rather than following up to each other's statements, this imposes its own barriers to closure.) For now I've decided to try to respond to several points in a single message to be sent out approximately once per day (for the days I read mail, which isn't every day). I might also send out some individual messages or replies, but presumably fewer than before. I'll probably also put a few of these summaries on web pages so that in the future I can refer to them by URL and not have to repeat them. I'm interested in hearing (via private mail) how well this works for people. I will probably vary the format a bit depending on the feedback I get. One request: if you do choose to respond to the list about something in this message, please pick a meaningful subject rather than the global subject of this message. ---------------------------------------------------------------------- II. On the "need" for "local addressing" Several people maintain that network admins will insist on local addressing. A few have countered that network admins are quite aware of the problems associated with local addressing and NATs in IPv4. I'm wondering if this is essentially a tools and/or a marketing problem. That is, maybe we need to a. standardize the addressing solution that makes the most sense for support of applications and actual operations, b. provide tools that make it easy and foolproof to restrict access and/or hide networks that aren't supposed to be externally visible, and c. market these addresses and tools in such a way that they'll sound like "the right thing" to network admins, and especially, their bosses. Of course, IETF is not a marketing organization, but that doesn't mean we have to ignore human nature. So if we need to slap the words "local addresses" in some document title, and then explain how GUPIs or PUPIs or whatever serve that need, for the sake of appearances, let's do so. And if we can find a way to make it easy to get the configuration right at the borders of a network beyond which PUPIs aren't supposed to be visible, fine - as long as we're not placing a huge burden on hosts or apps. But when we're talking among ourselves, it seems (on a technical level) better to avoid the complexity that comes with firmly associating a single specific and fairly arbitrary network boundary with an address format. And it seems clearer if we use a less-loaded term than "local addresses" when talking among ourselves - even while we acknowledge that blocks of these addresses will sometimes (perhaps often) be confined to enclaves. (Personally I suspect the idea of the "site" with definite boundaries is something of an anachronism - since I'm increasingly hearing of cases where people are pulling their hair out trying to glue together separate "sites" with NATs and make the result look seamless. But I don't want to overlook the hazards of poor marketing.) ---------------------------------------------------------------------- III. On use of link-local addresses by IPv6 applications I think I've said most of this before, but a summary might help. I see several general problems with the use of link-local addresses by apps: 1. By design, they won't route outside a single link, but even for small ad hoc networks or home networks we're seeing a mixture of link technologies in use. Yes, you can sometimes bridge them, but not always, and bridging introduces its own set of problems. 2. Not all apps can use them, and many of those that can use LLs cannot use them in all conditions, depending on (to users) obscure details of the way the network is organized. It would be better if small networks behaved in ways that ordinary users could understand and predict. 3. Of the apps that can use them, sometimes you have to configure the app to behave differently depending on the network configuration. For instance, under normal circumstances you might want the app to ignore LL addresses, but if it's running on an isolated single-link network then you might have to configure the app to use them. And in general you can't expect the app to detect this. 4. A network that is initially single-link might acquire some external connections and routing capability, and transitioning apps from LL to another kind of address (so that other nodes can participate in existing apps) is disruptive. That, and we need a solution for self-organizing networks anyway, and there seem to be good reasons to treat a single-link network as just a component of (or a trivial case of) a self-organizing network. Granted, we don't have the technology for self-organizing networks yet. In the meantime, people will have to cope with whatever is already there. But think our efforts are better directed toward making self-organizing networks function well than to try to make LLs be the solution for such networks. ---------------------------------------------------------------------- IV. On address selection policy I don't think making the policy settable on a per-stack basis is a good idea because different apps have different needs, and a policy that is appropriate for one app will prevent the operation of another app on the same host. Also, it's another knob that users have to understand and that tech support has to deal with. I don't think letting each link specify policy is a good idea, partially because a reliance on address solution (at least, as it's currently envisioned) makes referrals more difficult for apps, but also because a host might quite reasonably be connected to more than one network through more than one interface, and the policies of the various networks can conflict. And again, different apps need different policies - some need to favor stability over response time, some vice versa. It gets very complex to sort all of this out. Besides, I think we can develop better mechanisms than either of these. "Chirayu Patel" <[EMAIL PROTECTED]> wrote: > If you are using an automated mechanism, as I had suggested, getting > conflicting policy from different interfaces implies that something > wrong with the network engineering. I don't think so, because of the liklihood for a host to connect to different networks. Chirayu also asked for a clarification on this bit that I wrote: > per-link policy is the wrong way to think about this. what you want > is for each network to be able to say "here's the best way to get > here from there given a variety of conditions"... and then minimize > the number of conditions. I admit this is a bit vague, and it's not fully developed. I have been looking at various scenarios for connecting networks - some of them core-connected with PA addresses, some of them not core-connected but with interconnections to other networks; some of them self-organizing, others with managed routing and assignments; some of them fixed, some of them mobile; etc. The possible interconnections in between them are almost arbitrary (and these interconnections might or might not allow transit through the network). The interconnections will change over time and the networks will sometimes have to transition from one kind of address to another, and sometimes they'll have to deal with multiple kinds of addresses, but you want this to work as smoothly as possible. Then you have to consider what the world looks like to apps running on these networks that are using a variety of kinds of address space. And finally you have to decide at what point the app's responsibility ends and the network's responsibility begins (or the other way around if you're used to looking at things from layer 3). Anyway, by "minimizing the number of conditions" I really meant minimizing the number of prefixes, and types of prefixes, that a host or app or network has to deal with, to the minimum required to do the job. The more prefixes we have to choose from, the harder it is to make the right choice, and the more ways we have for things to fail. By "here's the best way to get there from here" what I meant was that the problem of host A figuring out how to send to attachment point B looks a lot more like a routing problem than an address selection problem. And once again, routing is a lot less confusing if you have a (more-or-less) uniform way of naming points in the network. (years of struggling with trying to weave uucp and DECnet and BITNET and Internet mail together into a coherent whole convinced me of that) Sorry, that's still vague. I'm working on a better explanation. ---------------------------------------------------------------------- V. On "solving the right problems" and the layer of indirection This is another attempt to summarize, that may end up on a web page. One reason that I maintain that the layer of indirection to support mobility has to go between layer 3 and 4 is that if a TCP connection breaks due to a prefix change, the app has no way of knowing how much data got to the other end. It doesn't see the TCP-level acks, and even if it did, those acks only mean the data got to the destination host - it doesn't mean the data got to the app. So you really need the indirection layer to go below TCP so that TCP's error recovery can handle the case where you lose data due to a prefix change. However I don't see lump prefix changes that happen due to your network changing connectivity in the category of "mobility", and I don't think of address selection or prefix substitution as examples of mobility either. If you had a layer that tried to hide the details of which address to use from apps, IMHO it would be just below layer 7. (Though as far as I can tell, it's more confusing and disruptive to try to hide those details from apps than to give them good APIs to deal with them explicitly.) So to me it seems to make sense to treat "mobility" (where your network disconnects from one point of the network and reconnects to another, probably because it's moved through physical space) very differently than changes in network connectivity or policy that might require migrating to a new kind of prefix but don't necessarily break existing signal paths. At any rate, it might be that this is the crux of this particular disagreement between me and Tony. ---------------------------------------------------------------------- VI. On "The IETF doesn't tell people how to run their networks" Tony says that "The IETF is not in the business of telling people how to run their networks" but of course that's wrong - the very purpose of IETF is to specify how networks are to be operated, at various levels of detail. There's little point to TCP or IP if higher-level protocols can't make any expectations about what services the network will provide; and none of our widely-deployed apps would be nearly so successful if apps couldn't make such expectations. Both email and the web, for instance, depend heavily on the expectation that there's a large "core" Internet that looks flat to the periphery; this is the fundamental assumption that allows for the exchange of email and the ability to access web pages between domains with no prior arrangement. Of course IETF doesn't demand, for instance, that you permit a certain kind of traffic on your network, or that you provide transit for third party traffic across your network. But neither can you expect your apps to work if you organize it in an arbitrary way or impose arbitrary constraints on what your network does. One way to describe IETF's job (relative to IPv6) is to define the behavior of the network such that apps will work well. Of course, we have to be realistic about what we expect of the network, and this necessarily involves a compromise. ---------------------------------------------------------------------- -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to [EMAIL PROTECTED] --------------------------------------------------------------------
