Subject: Re: [MOBILE-IP] Combination of binding update and home address op tion in mobile IPv6

From: Thomas Eklund <[email-masked]>
Date: Wed, 15 Mar 2000 10:37:35 +0100

> -----Original Message-----
> From: NMM van der Vlugt [mailto:[email-masked]]
> Sent: Wednesday, March 15, 2000 9:50 AM
> To: [email-masked]
> Subject: [MOBILE-IP] Combination of binding update and home address
> option in mobile IPv6
>
>
> Hi all,
>
> The binding update and de home address option are separated in mobile
> IPv6. But the handling of a binding update requires a home address
> option.
Yes and it is required by all IPv6 node to support home address option.
That means that every IPv6 node can at least receive and process the home
address option.
And every node should support binding update processing and return a binding
ack and the should also have a binding cache for all the accepted binding
updates (i.e. route optimazation..)

The above can be seen as what is required by a Correspondent node to support
so this SHOULD be the minimal every IPv6 node support...

> I see some implementation difficulties here.
Why?

> When a node is processing
> all options, it has to store the home address and the contents of the
> binding update options somewhere.
It stores them in its binding cache..

> It's not possible to process the
> binding update option immediate because its processing depends on the
> data in the home address option.
No,
You have to verify possible AH headers in the binding update option, check
the option length and the seq. no after that you proccess the home address
options which is the home address of the mobile node sending the binding
update and there is no sub otions defines today...

This is how it looks in the header because the home addrss option is send in
a destination option header and it is a separate extension header... And how
you process the order of extension header and espescially if you have a AH
included has been clearified in the latest mobile ipv6 draft (mobileipv6
version 10)...

> There is now also an extra error
> situation possibe: packet with a binding update option and no home
> address option.
This is when the binding update is not send from the mobile node, i.e it can
be sent from the correspondent nodes, routers (home agent). For instance it
could be in a reply to a binding update to ack it, or simply a refresh of
the cache...

>
> I think that it's more efficient to combine these two options. Or am I
If you combine them you have to change the router requirements... Which
might not be want you want to do...

> missing something here? It's possible to keep the definition
> of the home
> address option the same. The data that's now in a binding
> update option
> can be defined as a sub option of the home address option. This
> sub-option indicates that this is a binding update. This makes the
> processing of the "binding update option" more efficient. The binding
> cache can be updated immediate when the node processes this
> option. This
> setup also eleminates one possible error situation in the protocol.
>
> Marco
>

Regards
 Thomas Eklund

---

From: Guilhem Tardy <[email-masked]>
Date: Wed, 15 Mar 2000 11:26:57 -0500

> included has been clearified in the latest mobile ipv6 draft (mobileipv6

Although I agree mostly with your comments, I would like to add that a
correspondent node or Home Agent processing a Binding Update Option
needs to screen the whole Destination Option for a Home Address Option,
which I find ugly.
I didn't see any better explanation for the processing and order of the
options in rev. 10 compared to previous revisions, and I would
appreciate if you commented further. For instance, what if there's
several Home Address Options in the same Destination Option? And is
there any order assumed (e.g. Home Address Options located *before* a
Binding Update Option), or should a correspondent node or Home Agent
handle any of the possible situations (and therefore do the ugly thing)?

These are basic implementation consideration, and as I believe IPv6
requires the extension headers (e.g. Hop-by-Hop, Destination) to be
processed in order, I assume the same requirement applies to the options
within each of those extension headers, which is impossible here.

Best regards,
Guilhem Tardy.

--
                                    phone: (613) 993-8232
Network Systems and Technologies    fax:   (613) 998-9648
Communications Research Center      email: [email-masked]
3701 Carling Ave. #28/2B            web:   http://www.crc.ca/
Ottawa (Ontario) K2H 8S2