Subject: Re: [mobile-ip] issues 92, 94, 95 and text for sending BAs with RH

From: Samita Chakrabarti <[email-masked]>
Date: Mon, 19 Aug 2002 11:58:08 -0700 (PDT)

Hi Jari,

As noted earlier, the third paragraph in both sections seems to be incorrect.
Please see the comments below.

> I have updated the text proposals to fix issues
> #92, #94 and #95 based on comments I received. Namely, we do not
> want to prevent site-local addresses from using mobility. Also,
> the text becomes simpler if the condition for using RH is the presense
> of HAO in the BU.
> 
> New text for 9.4.4:
> 
>    The acknowledgement is sent to the Source Address of the IPv6 header
>    that carried the Binding Update. Note that this procedure is
>    independent from the treatment of regular packets and does not use
>    information from the Binding Cache.
> 
>    If the Source Address field does not contain a site-local or global
>    unicast address, the Binding Acknowledgement MUST NOT be sent.
> 

... and the binding update packet is dropped.
(please add this for clarification). 

>    Otherwise, further processing depends on whether or not the Binding
>    Update contains a Home Address destination option. If it does, the
>    source address is the home address of the mobile node and the
>    Binding Acknowledgement MUST be sent directly to this address.
>    Otherwise, the Binding Acknowledgement MUST still be sent to the
>    source address but a Type 2 Routing Header MUST be added to the
>    packet to carry the home address.
> 

Perhaps you mean to say the following:

If the source address of the Binding Update is equal to the home address of
the mobile node in the binding cache (i.e. mobile node is back at home) or
the home-address in the HAO, then also it sends the BA to it's source addr
(in this case, home-addr)-- so we are already covered by the first 
paragraph.  Also 9.4.4 also specifies in the beginning that:

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

So, I think the third paragraph is incorrect and unnecessary in section 9.4.4.

For section 10.2, situation is a little different that BU may not contain a
HAO ( as per 6.1.7), but even in that case your first and second paragraph
are okay. The third paragraph should write the following:

  ( as discussed and agreed at Cthon2002, Brian H. already mentioned) 
  
  If the Source Address field in the IPv6 header of the Binding Update is
  equal to the home address of mobile node, then it indicates that the
  mobile node is back at home. In this case, Binding Acknowledgement does
  (MUST?) not include Type 2 Routing Header.

BTW, I kind of liked the list of illegal addresses for the RH Type 2 header
for clarification in spec.

> And for 10.2:
> 
>    The acknowledgement is sent to the Source Address of the IPv6 header
>    that carried the Binding Update. Note that this procedure is
>    independent from the treatment of regular packets and does not use
>    information from the Binding Cache.
> 
>    If the Source Address field does not contain a unicast address, the
                                              ^^^^^^^^^^^^^^^^^
  Unicast address alone is not enough. Did you mean to say site-local and
  global unicast address ?
                                              
>    Binding Acknowledgement MUST NOT be sent.
> 
>    Otherwise, further processing depends on whether or not the Binding
>    Update contains a Home Address destination option. If it does, the
>    source address is the home address of the mobile node and the
>    Binding Acknowledgement MUST be sent directly to this address.
>    Otherwise, the Binding Acknowledgement MUST still be sent to the
>    source address but a Type 2 Routing Header MUST be added to the
>    packet to carry the home address.
> 

BTW, why do we need to include RH Type 2 in BA when src-addr != home-addr,
is this because of authentication verification at the MN end ?  May be
we should clarify that in the draft.

Thanks,
-Samita

---

From: Brian Haley <[email-masked]>
Date: Mon, 19 Aug 2002 16:49:27 -0400

> are okay. The third paragraph should write the following:

Well, I completely missed that comment in section 6.1.7 about the HAO,
especially since section 10.2 says:

"-  A Home Address destination option MUST be present in the message."

There's been so many changes to all sections of the draft it's getting hard
to remember if this is already fixed, but if an HAO isn't necessary for
home bindings, then please copy the text from 6.1.7 to 10.2.

That said, why have this optimization?  Do the byte-savings outweigh the
added complexity?

-Brian

---

From: Jari Arkko <[email-masked]>
Date: Tue, 20 Aug 2002 01:16:54 +0300

Samita Chakrabarti wrote:

>>   unicast address, the Binding Acknowledgement MUST NOT be sen
> 

=> ... the Binding Update MUST be silently discarded, and the Binding
Acknowledgement MUST NOT be sent.

 > So, I think the third paragraph is incorrect and unnecessary in section 9.4.4.

This was a part of the old text that the new text is expected to replace.
So, we need to keep this part of the old text... just that it could perhaps
be more exact so that it would say exactly when are we not sending to the home
address and what type of RH to use. Feel free to propose text ;-)

> are okay. The third paragraph should write the following:

According to Brian, all BUs contain a HAO.

>   (MUST?) not include Type 2 Routing Header.

Couldn't we use this text in both 9.4.4 and 10.2?

>>   If the Source Address field does not contain a unicast address, the

Global unicast addresses are obviously allowed. I think link-locals can also
be used for dereg to the HA. And, wouldn't it be bad if made it illegal
to use MIPv6 within a site that uses only site-local addresses? So that
was the justification for allowing all unicast addresses. However, on
second look this covers also NSAP addresss, the unspecified address etc.
So perhaps we should stick with "link-local, site-local, or global unicast
addresses".

Jari

---

From: Jari Arkko <[email-masked]>
Date: Tue, 20 Aug 2002 11:04:35 +0300

> That said, why have this optimization?  Do the byte-savings outweigh the

The HAO could be omitted only in the de-registration case, which may not
be frequent enough to talk about big savings.

One argument for making HAO optional in BUs is that then it would follow
the use of HAO in other traffic, i.e. if you are at home you don't include
it.

However, it seems that getting this described in text is going to take
some amount of words; it would be specification-wise simpler to just
say that all BUs must have a HAO. So I'm leaning towards that now...

Jari