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

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

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:

- From Section 1.3:

>    Central to this approach is to not introduce a new identifier name
>    space but instead use one of the locators as the upper-layer ID,
>    while allowing the locators used in the address fields to change over
>    time in response to failures of using the original locator.
> 
>    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.

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

- Section 5 provides details of the message formats.  Very basic question
  but why shim6 control message is designed as IPv6 extension header?
  I think the choice is reasonable.  Just curious about the motivation
  behind the design choice (piggyback?).  As for payload message,
  there is no doubt that extension header is suitable to carry the
  context tag (better than using flowlabel).  Another comment about
  wording:  Current texts in Section 5, especially in the first paragraph,
  the design choice to use IPv6 extension header is not explicitly
  mentioned.  IMHO, it should be mentioned.

- Section 5.1 gives description about payload message format.

>    2), there is a choice whether the shim applies inside the tunnel or
>    outside the tunnel, which effects the location of the shim6 header.
> 
>     0                   1                   2                   3
>     0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
>    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>    |  Next Header  |       0       |1|       Reserved              |
>    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>    |                      Receiver Context Tag                     |
>    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
> 

  Why a bit followed by the Hdr Ext Len is set as "1" ? Is it for making
  distinction between the payload message header and control header?
  I think a description about this bit would be helpful for readers.

- (This is rather editorial comment though) Section 14 and 15 provides
  process of packet before/after the locator switch.  But I would
  prefer to descriptions separated in terms of direction of the traffic
  (inbound/outbound) rather than splitting before/after the locator
  switch.


Regards,
Shinta