Subject: [mobile-ip] MIPv6 Draft-15 general issues from Connectathon-2002

From: Samita Chakrabarti <[email-masked]>
Date: Sat, 16 Mar 2002 17:38:34 -0800 (PST)

The following issues were discussed (some cases solutions were
suggested) at the Connectathon 2002 discussion session on MIPv6
spec issues. MIPv6 participants at Connectathon would like to
see these issues resolved/clarified  at draft-16 version of MIPv6 draft.

1) The correspondent node section should specify what status code the CN
   would return if it receives a de-registration BU for which there is no
   matching binding exists. Currently, it can only specify status (128- reason
   unspecified), but it's better to have a specific status code to indicate
   to MN that there is no BCE to delete. Otherwise, MN would not know whether
   the BACK status code is for some other reason or non-existent BCE. A new
   status code is perhaps a better choice for security concerned MNs which want
   to delete it's BCE from the CN before going away.

2)  When neighbor solicitation is sent to the global address of the MN at it's 
   home network, should HA tunnel this to MN ? At Connectathon discussion, the 
   rough consensus was that NS should be filtered out. The draft should specify 
   the behavior in this case. 
 
3) Should the implementation drop the piggybacked data if the BY sequence number 
   is out of order (if piggybacking is adopted)  ?  

4) Apparently the draft-15 (section 5.2) is not quite clear on benefit of setting
   refresh value of BACK.  The draft describes home-agent node and non-homeagent 
   cases and specifies that the refresh value SHOULD be equal to the lifetime for
   non-home-agent nodes. Question was raised in the discussion on usage of refresh
   field as it is a 32 bit quantity. If it's not that useful, removing the refresh
   field would save bits where bandwitdth is limited or expensive.

5) section 9.4 of draft-15 says that HA uses routing header when it communicates
   to the MN while it's not home and HA has a BCE for the MN.
   The de-registration section is not clear (section 9.2), whether HA would use
   routing header or not with the BACK when MN is back home. It does not make
   sense to have routing header with the BACK while MN is back home. The draft
   should specify the steps in this case whether HA would delete the BCE first
   and then send BACK to the MN without routing header. This clarification is
   highly needed in the draft, as it causes interoperability problem due to
   different interpretation of the meaning of the draft.

-Samita

---

From: Brian Haley <[email-masked]>
Date: Mon, 25 Mar 2002 16:56:40 -0500

>    different interpretation of the meaning of the draft.

I'd like to add one more clarification regarding the CN behavior in this case -
Section 8.5,
Sending Binding Acknowledgements, second paragraph says: "Furthermore, if the packet
is to be sent to the mobile node at any address other than the mobile node's home
address,
it MUST be sent using a Routing header (even if the binding was rejected)."

This obviously means the CN shouldn't use a Routing Header when the MN
moves back home and deletes the binding, but I think that subtlety was missed
by a few implementations because it's not in the bulleted list of items on how
to construct the BAck.

-Brian