[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: comments on draft-ietf-shim6-proto-01.txt
Shinta Sugimoto wrote:
Yes. Thank you for the clarification. But I still have unclear point.
My question is, in short, how the shim6 can be switched on/off
by ULP. Such idea might be silly but let me try to explain that:
Suppose that a node A has address {A1,A2 and A3} and A1 is anyhow
selected as ULID. In such case, app1 may want take advantage of shim6
and specify A1 as the source address for its flow. OTOH, app2 may not
be requesting shim6 support at all. How would the system allow app2 not
to use shim6 ? Maybe app2 may avoid its flow to be shimmed by
specifying A2 or A3 as the source address. But how come app2 know that
A1 is served as shim6 as ULID ? Or is there any other mechanism which
allows ULP to switch on/off shim6 ?
To do this we just need to define a new API, for instance an
IPV6_DONTSHIM socket option.
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. 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.
Need to do a return routability check i.e. send a packet and get a
response in order to verify that the ULID is indeed present at that locator.
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.
It has two purposes.
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. 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) ?
This is an open issue. I'll add it to -02.
Erik