El 21/03/2007, a las 10:50, Erik Nordmark escribió:
marcelo bagnulo braun wrote:In this case, it seems that the host will send a packet with destination address the cmula and the P-shim won't have the locator information associated to the CMULa. In this case, the P-shim6 will perform a reverse lookup for the CMULA and retrieve the locator information from the DNS. (This can be handled in the same way the case where there is a failure in the primary P-shim6 and the backup P-him6 is used)I agree with everything but the parenthesis.Even if you have a primary and backup pshim which share state, then wold be likely to time out the state, for instance based on the DNS ttl. But there are applications that remember the IP address independent of the DNS TTL. Thus to the extent that the document says that the reverse DNS tree is optional there is a problem; the reverse tree information must be present for it to be robust.
i seein other words, if you want to handle the call-back or referral situation when you are using non routable identifiers, you need a stable repository from where to obtain the ULID to locator mapping, since hosts (or thier upper layers) can have sotred the ULID for longer than the shim6 context in the proxy
The DNS is an option (you could have a local repository with a really long expiration information that stores the ULID to locator mapping that have been used (as opposed to store the whole shim6 context)
the order of preference would be 1- an locator ID mapping verified using HBA/CGA 2- a locator ID mapping verified through reverse DNS3- a locator ID mapping obtained through direct DNS (ULID RR and AAAA RR for the same FQDN)In case of conflict, the one with higher preference winsIf two with the lower preference are obtained, then the P-shim must use a higher preference method to determine which one is the correct onemakes sense?OK.But does or does this not mean that an implementation has to track multiple mappings for the same ID while it is trying to verify them?An example is that suppose the pshim has a preference 3 mapping for ID A and it starts doing verification for ID A for a higher preference, does it need to keep the preference 3 mapping around until the other verification has completed (or failed) and only then replace the existing mapping.
i think so... is this a problem? regards, marcelo
Erik