Subject: Re: [Monami6] (Issue-2 MCoA) Should MN returns Home with both interfaces attached to home and foreign?

From: Romain KUNTZ <[email-masked]>
Date: Mon, 04 Dec 2006 20:52:10 +0900

Hi Ben,

Benjamin Koh Tien-Ming wrote:
> I fail to understand how implementing proposal-2 keeps the solution
> simple? Maybe I'm missing something here.

Some of the issues raised by Ryuji for proposal-1 in its original mail, 
as well as the ones I sent on the ML few weeks not being solved, 
proposal-2 remains IMO the easiest one to deploy at this time.

Specific operations for returning home are define not only in RFC3775, 
but also in RFC3963, and maybe in other extensions to MIPv6. Modifying 
the returning home procedure may bring side effects to those specs. 
Also, the home-CoA autoconfiguration may become tricky if the MN's HoA 
is already built from autoconfiguration. For those reasons, I would tend 
to prefer proposal-2.

Regards,

-- 
Romain KUNTZ
[email-masked]

_______________________________________________
Monami6 mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/monami6

---

From: Benjamin Koh Tien-Ming <[email-masked]>
Date: Fri, 08 Dec 2006 15:48:45 +0800

Hi Romain!

Romain KUNTZ wrote:
>>>> >> > > Some of the issues raised by Ryuji for proposal-1 in its
original
mail,
>>>> >> > > proposal-2 remains IMO the easiest one to deploy at this time.

[BK]
AFAIK, Ryuji raised 4 issues for consideration in his original mail.

1. Change in definition of HoA and CoA in 3775
Keigo has addressed this in a previous email. To summarise, Proposal-1
uses a prefix advertised in home network as both home prefix and foreign
prefix whereas Proposal-2 is also in the same situation because it uses
a physical link as both home link and foreign link.

2. Processing is complicated in MN, needs to decide whether to
deregister binding or register Home-CoA.
For Proposal-2, MN also needs to decide whether to ignore the received
Home Prefix RA. If  does not advertise the Home Prefix, the implications
are even greater as even legacy MNs can never perform the returning home
procedure!

3. Processing is complicated in HA, needs to register CoA generated from
home prefix.
Registration is handled as per Section 10.3.1 of RFC 3775. I do not see
any changes required that arises from the use of Home-CoA. Perhaps
someone can point me in the right direction.

4. MN may bypass bi-directional tunnel if destination node is located on
home link.
This may be a common behaviorial problem faced by both proposals. From
RFC 3775,
"home link
      The link on which a mobile node's home subnet prefix is defined."
Hence, even if the mobile configures a CoA via a foreign prefix, it
should still be aware that it is on its home link as long as it receives
a Home Prefix RA. For Operational solutions that do not advertise Home
Prefixes, see (3.) above.

>>>> >> > > the returning home procedure may bring side effects to those
specs.

[BK]
According to RFC 3775, "A mobile node detects that it has returned to
its home link through the movement detection algorithm in use, when the
mobile node detects that its home subnet prefix is again on-link. The
mobile node SHOULD then send a Binding Update to its home agent, to
instruct its home agent to no longer intercept or tunnel packets for it."

Proposal 1 requires that when an interface returns to home link, if the
mobile node has other interfaces attached to foreign links that it wants
to continue to use, it should then NOT deregister but rather create a
HomeCoA and update its home agent.

Proposal 2 requires that when an interface returns to home link if the
mobile node has other interfaces attached to foreign links that it wants
to continue to use, it should then ignore its home subnet prefix but
instead create a CoA using a foreign prefix and update its home agent

Both proposal 1 and 2 require a slight modification on the behaviour of
the mobile node as specified in RFC 3775.

>>>> >> > > is already built from autoconfiguration. For those reasons, I
would tend

[BK]
Let me make a stab in the dark on why autoconfiguration of Home-CoA may
be tricky.    :)    From RFC 2462, "A link-local address is formed by
appending the interface's identifier to the well-known link-local
prefix." and "If a node determines that its tentative link-local address
is not unique, autoconfiguration stops and manual configuration of the
interface is required." Since the original interface identifier was used
to generate the HoA, when autoconfiguring the Home-CoA using the same
interface may yield HoA again. Performing DAD for HoA would then fail as
HA is doing Neighbour Proxy for HoA.

However, RFC 2462 continues, "To simplify recovery in this case, it
should be possible for an administrator to supply an alternate interface
identifier that overrides the default identifier in such a way that the
autoconfiguration mechanism can then be applied using the new
(presumably unique) interface identifier." Hence to allow
autoconfiguration of Home-CoA, one simple method may be to allow the
Home-CoA function to supply an alternate interface identifier before
autoconfiguration occurs.  No additional changes needs be added to RFC2462.

Another point to consider for Proposal-2 may be how do mobile nodes
differentiate between a home prefix and a home foreign prefix? I'm
thinking perhaps additional considerations may be needed in the
autoconfiguration or bootstrapping procedures.

In a sense, Proposal-1 requires only terminal-side operations
whereas Proposal-2 predominantly requires network-side operations in
addition to some terminal-side operations/configuration.

Regards,
Ben

-- 

/<<<<<<<<<<<<<<<<<<<<++>>>>>>>>>>>>>>>>>>>>\
| Benjamin Koh Tien-Ming                   |
| R & D Engineer                           |
| Panasonic Singapore Laboratories Pte Ltd |
| Tel: (65)6550 5481 Fax: (65)6550 5459    |
| E-mail: [email-masked]  |
\>>>>>>>>>>>>>>>>>>>>--<<<<<<<<<<<<<<<<<<<</

---

From: Romain KUNTZ <[email-masked]>
Date: Wed, 20 Dec 2006 18:16:04 +0900

Hi Benjamin,

> a physical link as both home link and foreign link.

I agree that your "Home-coa" concept does not conflicts with the 
definition of HoA in RFC3775.

But, From RFC3775:

care-of address

       A unicast routable address associated with a mobile node while
       visiting a foreign link; the subnet prefix of this IP address is a
       foreign subnet prefix. [...]

So at least a new term should be defined ("Home-CoA" as you mentioned) 
to define an address derived from the home prefix that is not a HoA.

> Home Prefix RA. 

On that point, both proposals are a matter of preferences on the MN, I 
think.

> If does not advertise the Home Prefix, the implications

Well, you can never prevent the admin to misconfigure its home agent :-)

> someone can point me in the right direction.

I must admit that I do not see any conflict with RFC3775 neither.

> a Home Prefix RA.

So? I did not understand what is the conclusion of your statement.

But anyway, I do not agree with Ryuji's original statement ("The MN can 
solve neighbor cache and may directly send packets to the destination. 
This is because the prefix of the destination node is on-link for the 
MN."): when a MN is in a foreign link with a CoA configured from the 
foreign prefix, it does not sends packets directly to a destination that 
would be located on the same foreign link, even though the prefix of the 
destination node is on-link. So why would this be different when the MN 
configures a Home-CoA?

> the mobile node as specified in RFC 3775.

Ok, but my point here was that another specifications based on MIP6 
(NEMO BS, FMIPv6, ...) also have specific operations when returning 
home. To adopt proposal-1, we have either to be sure that it is 
compatible not only with RFC3775, but also all other specs based on it, 
or to list all modifications to perform for each spec.

For example, NEMO Basic Support (RFC3963) says:

5.6.  Neighbor Discovery for Mobile Router

    When the Mobile Router is at home, it MAY be configured to send
    Router Advertisements and to reply to Router Solicitations on the
    interface attached to the home link.

Most of the specs says "When the node is at home, ...".
I think Proposal-1 requires to redefine what is "at home", as the the 
definition from RFC3775 ("when the mobile node detects that its home 
subnet prefix is again on-link") is not clear enough anymore for the 
above statement.

> autoconfiguration occurs.  No additional changes needs be added to RFC2462.

So you would need to configure all of your multihomed-MN with another 
unique interface ID for each of their interfaces, and to perform all the 
   necessary operation on the MN to check if your Home-CoA is still not 
duplicated with another node? This looks like a tedious work to me.

> autoconfiguration or bootstrapping procedures.

I think the MN can learn the Home Prefixes managed by its HA through 
MPS/MPA.

> addition to some terminal-side operations/configuration.

The only network side application I see for proposal-2 is advertising 
one more (foreign) prefix from the HA. And as it does not requires to 
change the HA spec., I do not see why this would be a restrictive factor 
against proposal-2.

Regards,

-- 
Romain KUNTZ
[email-masked]

---

From: Benjamin Koh Tien-Ming <[email-masked]>
Date: Thu, 21 Dec 2006 16:32:12 +0800

Hi Romain!

> > to define an address derived from the home prefix that is not a HoA.

[BK]
The definition of Home-CoA, if required, should be in a Monami6 WG draft
rather changing RFC3775. In the same vein, a definition for
"Home-Foreign network" may be required for Proposal 2.

> > On that point, both proposals are a matter of preferences on the MN, I

[BK]
I agree that both proposals require some MN action.

> > Well, you can never prevent the admin to misconfigure its home agent
 :-)

[BK]
All too true, perhaps another I-D...  ;-)

> > So? I did not understand what is the conclusion of your statement.

[BK]
I meant to say that both proposals face the possibility of MN choosing
to bypass the bi-directional tunnel. With Proposal 2, as long as the HA
also advertises the Home Prefix, MN would assume that that particular
interface is on its home link.

> > destination node is on-link. So why would this be different when the MN

[BK]
Agreed. See above.

>>>>>>>>>> >>>>>>>>>> Specific operations for returning home are define
not only in
>> >> RFC3775,
>>>>>>>>>> >>>>>>>>>> but also in RFC3963, and maybe in other extensions
to MIPv6.
>> >> Modifying
>>>>>>>>>> >>>>>>>>>> the returning home procedure may bring side
effects to those
> > subnet prefix is again on-link") is not clear enough anymore for the

[BK]
Ok, I understand where you are coming from now. AFAIK, even when
utilising Home-CoA, the MN should still be considered "away" and not
"home". Hence the BUs and the "CoA" term. Clarifying that usage of
Home-CoA does not imply the MN is "home" in the definition of Home-CoA
should be sufficient I believe.

>>>>>>>>>> >>>>>>>>>> Also, the home-CoA autoconfiguration may become
tricky if the
>> >> MN's HoA
>>>>>>>>>> >>>>>>>>>> is already built from autoconfiguration. For those
reasons, I
> > duplicated with another node? This looks like a tedious work to me.

[BK]
That may be one straightforward way to implement it. The MN can also
choose to use one of the identifiers of its other interfaces that is
different from that used to configure the HoA. It is basically an
algorithm implementation issue that may be encountered whenever a
duplicate address is detected, not only due to Proposal 1. Another thing
to keep in mind is that such an implementation may only be necessary for
MNs that require simultaneous use of home and away interfaces.

> > I think the MN can learn the Home Prefixes managed by its HA through

[BK]
Agreed, in any case the operation of the MN in Proposal 2 becomes
non-trivial as well.

> > change the HA spec., I do not see why this would be a restrictive factor

[BK]
Proposal 2 has the "side-effect" that all nodes, including single
interfaced MNs and MNs which do not want to do simultaneous home and
away, suffers from needless prefix advertisements. Kind of like spam.
Costs may be higher if the last hop is wireless. Also, visiting MNs may
configure both prefixes (home and foreign) and register to their HAs to
no good purpose that I can see.

Regards,
Ben