- Section 1.5 discusses renumbering and its implications to shim. I agree that there is a serious concern with regard to the ownership of ULID. A host may intentionally/unintentionally claim invalid ULID which isactually owned by different node. CGA would solve this.It is actually more subtle than that. Neither HBA nor CGA can prove ownership of the prefix part of the address.You are right. The problem was not that simple... In HBA, secure binding between the set of prefixes and the HBAs is assured. With CGA, a node can verify if the received packet was actually sent by the right peer.
well, thee proposed usage for cgas in shim is to sign alternative locators that are dynamic
With HBA/CGA, we can have both. But the issue we are discussing here is how one can verify if the ULID is owned by the node which actually resides on the location (from network topology perspective) indicated by the ULID.
yes
Instead the shim uses a "probe" to verify that the ULID is indeed present at the locator before sending packets to it.I believe you are referring to Reachability Probe message in shim6 ? As far as I understand it, the message is for checking if the peer can be reachable with claimed locator. Hence seems to me it's for solving a different issue.
above you mention that the issue being discussed is
how one can verify if the ULID is owned by the
node which actually resides on the location (from
network topology perspective) indicated by the ULID.
through the reachability test, the sender includes in the reachability
test the ULID and sends the probe to the new locator.
The receiver, will then verify if he owns the ulid before replying.So through the reachability test, we are verifying that the owner of the ulid is located in the tested locator, right?
But the issue with renumbering is slightly different. If A and B start communication using ULID pair <A1, B1>, this startsusing locators <A1, B1>. If there is a failure, the shim will switch tousing a different locator pair, say <A2, B1>. Now things might continue to work forever, using <A2, B1> as locators and the ULP (e.g., TCP and the application> having ULID <A1, B1>.What happens if the site that A belongs to renumbers, so that A switchesfrom having {A1, A2}, to {A2, A3} as IP addresses? The shim doesn't have to disrupt the traffic, since it is doing fine using <A2, B1> as locators. But could the ULP on B be confused when it sees packets from the new "owner" of A1? The fact that another host can now use ULID A1 could be a potential issue, which would worst case suggest that the shim break the communication when the ULID is removed from the host.I see it's difficult to handle a situation like above. During the renumbering process, the old IP addresses should be deprecated, including ULID, IMHO.
deprecated means that the address should not be used for newer communications, but that can be used for ongoing communications, right? So, a shim session that is using an address as ulid and that address is deprecated, the address can still be used as ulid for that ongoing session imho
So probably shim6 should follow the direction of the lower layer in determining continuation of given ULID. I didn't find any description about the ULID availability in protocol document. For instance what would be expected behavior of shim6 when ULID is become unavailable (i.e. preferred lifetime of the IPv6 address (=ULID) has been expired) ?
preferred lifetime is not really the problem, imho, because the address can still be available. I guess the problem is what happens if the address is no longer valid (valid lifetime=0). We shouldn't use this address as a locator, but should we keep on using it as a ulid? here is where colision through renumbering may occur (with a very low probability)
if preferred lifetime = 0, then i guess that we could affect the preferences for that address within the shim, and if the address becomes invalid, then
regards, marcelo
- Section 5 provides details of the message formats. Very basic questionbut why shim6 control message is designed as IPv6 extension header?So that the payload message fits. I'll add this as an explanation in -02.Ok. [snip] Regards, Shinta