Re: comments on draft-ietf-shim6-proto-01.txt

[Shinta Sugimoto <shinta@sfc.wide.ad.jp>]

Hello Erik,

Thank you for your comments. Please find my responses inline.

On Sun, 16 Oct 2005 15:59:43 -0700
Erik Nordmark <erik.nordmark@sun.com> wrote:

> Shinta Sugimoto wrote:
> > Hello,
> > 
> > I've read draft-ietf-shim6-proto-01.txt.  I found the document very
> > helpful to figure out how shim6 would work.  Please find my comments and
> > questions below:
> 
> Thanks for your comments.
> 
> >>   This implies that the ULID selection is performed as today's default
> >>   address  selection as specified in [11].  
> > 
> > 
> >   To me, what is stated in the last sentence does not seem to be an
> >   ideal case.  I believe it should be up to application whether to facilitate
> >   shim for a particular flow.  Current protocol document seems to be taking
> >   very flexible stance on how ULID is selected from the locators.
> >   However, from application standpoint, ULID selection is significant in
> >   a sense that IP transaction should be based on ULID if the application
> >   wants to preserve established communication taking advantage of shim.
> >   IMHO, upper layer protocol should be able to get involved in ULID selection,
> >   or at least, it should be able to distinguish ULID from the locators.
> 
> In the simple approach the ULID set is the same as the locator set, so 
> I'm not sure I understand what "distinguish" means in this case.
> [Some have argued for a mode where a host could create additional 
> locators that must never be used as ULIDs, but that isn't really simple.]
> 
> In any case, the DNS (in the AAAA records) contain addresses that can be 
> used as both ULIDs and locators.
> Once the the shim6 context is established between a pair of ULIDs, each 
> one of them will discover the set of locators of the peer (which might 
> be different than what was in the DNS.)
> 
> Does that make things more clear?

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 ?

> > - 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 is
> >   actually 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.  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.

> 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.

> But the issue with renumbering is slightly different.
> If A and B start communication using ULID pair <A1, B1>, this starts 
> using locators <A1, B1>. If there is a failure, the shim will switch to 
> using 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 switches 
> from 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.  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) ?

> 
> > - Section 5 provides details of the message formats.  Very basic question
> >   but 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