David Conrad wrote: > ... > Assume at the end point an address consists of a 64 bit value stuffed > into the lower 8 bytes of an IPv6 address with the upper 64 bits 0. > > The lower 64 bits of the destination would be put into an > in-addr.arpa-like tree, mapping that end point into multiple AAAAs > (which have their lower 64 bits set to 0) that correspond to the edge > routers associated with the multiple paths to the destination.
The problem that needs to be solved is how this is done in a secure, scalable way as said node moves between something like 802.11 hotspots. > > Packet hits the source edge router for the first time, a DNS lookup > occurs fetching the multiple locators and caching them. The edge > router then bitwise ORs one of the locators (how the locator > is chosen > is left to the reader as an exercise) with the end point address, > forming a full 128 bit address. Obviously, you'd want to have the > source edge router keep the cache entry up to date as long as packets > are flowing to the destination (e.g., re-fetch at TTL/2 or whatever). I don't follow these steps. How does the origin get from AAAA records with only locators for the provider edge router, to a 128 bit entry? The only way I can figure this out is for 1) src looks up AAAA for name string, receives low 64 bits; 2) looks up in-addr of low 64 bits, receives name strings for current service provider edge routers; 3) looks up name strings of current service provider edge routers, receives set of upper 64 bit values that could be appended. All those steps only minimize churn on the forward tree. There is still a need to churn the reverse tree as the node moves. > > On the receiving end, the destination edge router receives > the packet, > zeros out the top 64 bits of the destination address (thereby > avoiding > NAT nightmares) and forwards the packet on to the destination. This would not really be necessary as the dst could just as easily ignore the upper 64 bits. The real question is where such a system ends up pushing the complexity to. Take the example of simple spam filtering in a mail server (since I happened to be working on that this morning). A simple filter might look like 66.154.0.0/18 because I know I have no valid reason to receive mail from CONEPUPPY-COM or its customers. If we change the system to remove any indication of routing infrastructure from the bits an application sees, there will be an increase in traffic that is trying to figure out where a random 64 bit identifier string came from. > > Renumbering thereby becomes merely an exercise in modifying the end > point 64 bit in-addr.arpa-like entry and waiting for the > cache entry to > time out. For mobile devices those cache entries will need to be on the order of minutes, and there is a missing discussion of how the update is authenticated, and its impact on overall network traffic. > > End point identifiers would be non-topologically sensitive > and could be > permanently assigned with absolutely no hierarchy (if desired). > Locators would still be topologically sensitive, but end users would > never see them or know about them, thus topology changes can be done > transparently. We are squeezing a balloon here. The more we optimize the routing infrastructure, the more we will end up complicating another area (see above discussion about spam filters). > > Even more fun: assume that the first four bytes of the end point > address aren't used during a transition period and the last > four bytes > encodes (say) an IPv4 address.... > > > I suspect that mobile IP would be a lot easier as well. > > Mobility is a bit trickier due to the DNS security and > caching model. > However, I believe it may be possible with the use of SIG(0) > and having > destination edge routers act as forwarding agents for a TTL. > This bit > needs more thought... > > > In contrast, if we fix the DNS to track the topology, names > would have > > to replace addresses in tcp control blocks (and packets and > many other > > places) > > before we would start to see the aforementioned benefits. This depends on the frequency of topology change. If the topology change period is significantly longer than the duration of an application stream, no change is necessary. On the other hand, we know that mobile devices exist (specifically consider a suspended laptop) so from the application perspective topology changes happen much more frequently than they are ready to deal with. In terms of return on investment, I would argue that we should be insisting that apps start using name strings in control blocks, and that all the arcane cruft that we now call DNS get replaced by a distributed database with minimal replication, and strong authentication of dynamic bindings. Tony > > Ick. > > Rgds, > -drc > > -------------------------------------------------------------------- > 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] --------------------------------------------------------------------
