Dan Lanciani wrote: > | ... > |There is an important difference between pushing all the way > to the end > |system, vs. the edge router. While architecturally there is little > |difference, when the mapping function is in the end system > the level of > |churn on the registration infrastructure is substantially higher. > > Why? The level of churn is determined by how often you > renumber, not by where you translate the identifier to the locator.
Ok, that was not well worded. Any node that renumers will have to update some mapping server in the network. That function will require some authenticity, therefore a scalable trust model. If we put the identified/locator mapping function on the consumer side of the existing routing trust boundary, the authentication tools we have today will scale (ie: ISP cert in edge router, shared secret for consumer devices). If my devices show up at different networks and registers their new addresses with my edge router at home, the scaling impact is substantially lower than if they all try to update some central store in the ISP. > > |Moving > |that to the consumer edge/set top provides both a platform that is > |generally more stable in its availablity, as well as an aggregation > |point for the bulk of the device churn. > > My proposal works equally well in end nodes or in edge > routers. Obviously you get somewhat more benefit from a > shared cache on the edge router, but you seem to be saying > something more significant is going on. I am sure we can make mechanisms work either way, but there is a trust boundary here and the more often we cross it the more complex the tools become. > > Is existing code a reasonable argument for sticking with the > current system? Inertia seems to be the justification for > much of what we have. Any new system that required wholesale > changes in higher layers would be shot down for just that > reason. You can't have it both ways. I am not arguing that we can't change the higher layers. All I was pointing out was that using something that exists to justify defining something completely new is broken. If we are really talking about a completely new architecture we should not assume that any existing code will meet the yet to be defined requirements. It might work out that way, but we can't base the decision on it. > ... > |Unless the application was trying to associate the source address of > |the packet with something it knows about. > > This doesn't make any sense. The applications never see > anything but the portable identifiers. Consider the SMTP server that wants to reject connections from a group of servers. If there is no indication of topological grouping, that server would have to look up all the portable identifiers to find out what to filter. > > |If there is a 'transparent' > |mapping function in the system, apps that expect that service will > |break. > > Applications won't "expect" anything. If this system were > implemented it would simply replace what we currently call > addresses with portable identifiers. No, it is very different. Current portable identifiers include some degree of topology information. > > |If such a mapping service is to work with said apps, there > needs to be > |a mechanism to distribute the mapping table with some level of > |authenticity. > > Not the table, just the entries that are of interest to > particular consumers. Why do you believe that this is any > more difficult than what DNS is currently expected to do? Scale. If every device on the net today were registered in DNS & could change that registration at will for topology changes, they I would agree. Reality is that the current DNS handles a very small subset of nodes, and the vast majority of those are static entries. The reasons for this are lack of a trust infrastructure to allow arbitrary updates, coupled with the lack of distribution appropriate to accommodate the scale. We can't give DNS servers to the consumer because the existing system is too arcane, and we can't support DDNS for every network enabled device in the ISP servers because we don't have a trust model that scales. > > |If you are talking about essentially in-line encaps like > |8+8, every routing edge would need to map the source locator > as well as > |destination. > > Yes, of course the source has to be mapped as well. There > are different ways to handle this, perhaps avoiding the > overhead of explicitly carrying around both values. See my > original notes in the Sep. 99 archives for some possibilities. Optimizing in one place just moves the problem somewhere else. > > |> The problem of tcp connections > |> (not) surviving renumbering would disappear. The DNS would > |> work just the way it is, so no duplicate effort would be > |> required. > | > |Wait, a string to string translation happens in the DNS, > then you claim > |another string to string translation is not a duplicate effort !?!?! > > No, you are completely missing the point. If the > fast-changing mappings are handled in a separate 128b->128b > transformation (one perhaps optimized just for this purpose) > then there is no need to fix the existing DNS to deal with > fast-changing mappings. The DNS would continue to hold > long-term mappings (from name to portable identifier) which > could continue to be updated with the existing semi-manual > process. The duplicate effort that is avoided is that of > enhancing the DNS to deal with fast-changing dymanic mappings. At the expense of having to do two mappings for every connection. The proposal is to make the whole system slower rather than fix the problem at the source. > > |The request/response is not the problem. Explain how it handles a > |scalable, secure update as nodes move between 802.11 hotspots of > |different providers. > > You are introducing a different problem. No, that is the core of the DNS problem. DNS can already handle the request/response load. What it doesn't do is provide a scalable way to update the changes. > I proposed only to > fix the aggregation/allocation/renumbering mess. I said it > would likely make mobile IP easier; I didn't say it would > make it free. How exactly do you think the use of arbitrary > strings will solve the new problem that you have introduced? It is not a new problem, and I am just pointing out that inserting a new name system doesn't do any good unless it solves the authentication issues. If it does that, there is no reason to limit it to fixed length strings. > > |If that problem is solved, there is no reason for > |such a mapping system be limited to 16B fixed length strings. > > There is no correlation between solving that problem and > selecting a 128->128 mapping. The latter is purely a matter > of convenience for existing code. If you want to scrap the > entire existing v6 suite and start over then I'd be happy to > help, but I don't think that is going to happen. If we did > do this then we could just start with an explicit > source-route model and avoid the trap from the beginning. If one only looks at the resolution part of the problem, then existing code and fixed lengths are a natural draw. The reason this exercise is even being undertaken is that we don't have the authentication infrastructure to update mappings to begin with. If we create that infrastructure it would apply just as well to DNS, so why would we need multiple layers of name to address translation. > > |> The latter final response is assumed to come from a server > |> under the control of the owner of the identifier. > | > |Basically what I was suggesting by pushing the service to > the customer > |edge. > > We seem to be confusing two different things. The actual > transformation of addresses in packets can happen at end > nodes or in edge routers. The servers that provide the > information necessary to perform those mappings can exist > anywhere, much as DNS servers do today. I would not be > inclined to make the latter servers resident within the edge > routers, but it is not out of the question. It is a convinent aggregation point that aligns with the routing trust boundary. > > |> Obviously, > |> responses would also include the usual TTL values and such > |> much as a DNS response does. The mapping service actually > |> scales a lot better than the DNS because it can increase the > |> depth of the tree as necessary by splitting on arbitrary bit > |> fields in the identifier. This should be transparent (think > |> unix DBM). > | > |The only thing that limits DNS is the assumption that the > branching is > |limited. If name strings were device.customer.aol.cc... there is no > |real difference to parsing on a bit boundary. > > Are you kidding? Yes, sure, if you made domain allocation > hierarchical and forced people to change their names when > they changed providers then there would be more opportunity > for deepening the tree. This would make names almost as > useless as addresses. Talk about a step in the wrong direction... We are only moving the problems around here. People already deal with updating email addresses when they change providers, or employers, so it is within some degree of reason. For those that multi-home or want to mask their provider from the name, they can always register for a name in cc, then work out the authentication process with the providers. Tony > > Dan Lanciani > ddl@danlan.*com > -------------------------------------------------------------------- > 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] > -------------------------------------------------------------------- > -------------------------------------------------------------------- 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] --------------------------------------------------------------------
