[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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

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?


- 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. Instead the shim uses a "probe" to verify that the ULID is indeed present at the locator before sending packets to it. 

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. 


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


  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.


ok


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.


ok, I'll add that.


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


Good suggestion.

   Erik