On Sunday 16 October 2005 23:25, Erik Nordmark wrote: > > The issue I have with your description is that you assume that the > "mapping layers" are actually of similar complexity, and AFAICT > they are quite different; the shim uses a "re-mapping" layer (which > remaps the ULIDs to alternative locators it has exchanged with the > peer). But for a generalized identifier/locator split you need a > mechanism to *lookup* an identifier to find some working locators. > > The complexities of defining such a lookup mechanism is nothing > that the shim needs; the complexity is closely tied to what the > identifier name space looks like (hierarchical allocation, and > HIP-style hashes are two examples). > > A complete identifier/locator split would also need to redefine > what information goes in the DNS (e.g., should we have some form of > ID RRs or not?).
FWIW, there is a HIP WG I-D proposing to define a new RR to store HIP identifiers. > If and when we have workable solutions for those pieces, we can > still reuse the shim as the mechanism for providing failover > between different locator pairs. So I don't see how *technically* > doing the shim prevents people from working on the above, hard > problems. > We already have HIP exploring one way to do this (based on a flat > ID space). If folks want to explore doing it based on a > hierarchical ID name space as well. HIP had, some revisions ago, two types of identifiers: flat (public key hash) and hierarchical (concatenation of prefix and public key hash). We chose to drop the hierarchical flavor because at that time there was no strong support to keep them. If there is now interest one can try to revive them. --julien -- julien -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 --------------------------------------------------------------------
