Subject: Re: [mobile-ip] Binding Error Message and HAO

From: Samita Chakrabarti <[email-masked]>
Date: Fri, 7 Jun 2002 19:00:33 -0700 (PDT)

> 
> I'm trying figure out if we have already closed this issue.
> (http://www.piuha.net./~jarkko/publications/mipv6/issues/issue33.txt)
> 
> The original question was what to fill in when there is no HAO.
> In another discussion on the list we have noted that the HAO
> can be included in BUs to the CN. We then discussed whether we
> could simply drop packets that don't have a HAO, and not even
> respond with a BE. Arvind noted that if the MH type is unrecognized,
> it is hard to know if a HAO should have been present or not. He
> proposed that the home address be placed in an option that could
> be carried by the BE when necessary.
> 

If the CN is an old CN and does not understand MIPv6 RO, it should generate
ICMP PARAM problem (section 11.5.2)

Both HOTI/COTI messages don't have HAO option. 

So, if the MH type is unknown, 
it makes sense to either drop them or send rate limited ICMP PARAM
problems in case of HOTI/COTI error messages.

If MH type is known (HOTI/COTI) and there is other problem in the 
option, then CN can send BE with home-addr=0. 

> Note that the HoT message goes via the home agent and
> does not have a home address option. The source of the
> packet is the home address. So, what happens if the CN does
> not support this message, or some similar future message? If
> we are strict about the no-BE-if-no-HAO rule then we can't
> send an error.
> 

This rule may make sense for BUs only, but not for HOTI/COTI message, I think.

> My suggestions is therefore that a new mobility option should
> be created, the "Home Address mobility option" (can this be
> mistaken for the HAO -- any ideas for a better name?). This
> new mobility option would be included when the BE is sent
> with Status 1.
> 

There is not much strong reason to add yet another new mobility
option for this cause.

> Another alternative is to allow the home address field to be
> zero in the BE message, if HAO was not present in the offending
> message.

This seems to be a reasonable solution, if the offending message does not
contain HAO and we know it's a mobility message.

-Samita

---

From: Jari Arkko <[email-masked]>
Date: Sat, 08 Jun 2002 10:08:19 +0300

> contain HAO and we know it's a mobility message.

Seems like folks prefer this approach. Let's do it.

Jari