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

From: RYUJI WAKIKAWA <[email-masked]>
Date: Mon, 20 Nov 2006 04:00:47 +0900

Dear all

* Issue-2

When a MN returns home, it must select to attach either home or
foreign link.  It cannot utilize both interfaces attached to home and
foreign links. This is because HA uses proxy NDP to intercept packets.
If the MN activates its HoA to the interface attached to the home
link, address duplication is occurred. Then MN may shutdown the
interface as RFC2942 specified.

* Proposal:

- Proposal-1
    Use of Home CoA. When MN returns home, it generates a Home-CoA from
    its home network prefix. MN registers its Home-CoA to its HA and
    creates tunnel at the interface attached to the home link so that
    it can utilize both of interface attached to home and foreign link.

- Proposal-2

    Operational Solution. If HA has several links or advertise multiple
    prefixes on its home link, MN can generates a CoA from one of non
    home prefixes advertised by its HA. Therefore, it can registers the
    CoA to its HA and creates a tunnel. Although MN never returns home,
    the distance to HA is just one-hop. This is same overhead as the
    home-CoA.

* pros & cons

The Home-CoA requires the definition of HoA and CoA. RFC3775 does not
say the CoA can be generated from its home prefix. The home prefix is
used to generate HoA for each MN. Any extensions and protocols based
on RFC3775 inherits this definition, some side effects may be observed
and caused later. In addition to this, the processing of MN and HA is
complicated. The HA needs to register CoA generated from the home
prefix. The MN must decide whether it deregisters its binding or
registers the Home-CoA when it returns home.
Moreover, if a destination of the MN is located on the home link, the
MN may bypass the bidirectional tunnel. 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.

Operational solution may cause some limitation in deployment scenario.

* Conclusion - PENDING
1. DO NOT support simultaneous use of foreign and home when MN returns
    home. (REJECT)
2. Support the scenario of the simultaneous use by the Home-CoA  
Solution. (ACCEPT)
3. Support the scenario of the simultaneous use by the Operational  
Solution. (ACCEPT)

Any comments?
There were several discussions with Keigo on Monami6 ML

regards,
ryuji

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

---

From: Keigo Aso <[email-masked]>
Date: Mon, 20 Nov 2006 11:51:04 +0900

Hello all and Ryuji,

Let me add some comments as pros & cons based on the previous 
discussion and presentation
(http://www3.ietf.org/proceedings/06nov/slides/monami6-8.pdf).
Thank you for this email from you, Ryuji.

On Mon, 20 Nov 2006 04:00:47 +0900

> on RFC3775 inherits this definition, some side effects may be observed

** About the definition of HoA and CoA:
Proposal-1 does not change the definition because it uses
one prefix as both home prefix and foreign prefix. Whether a prefix 
is a home prefix or a foreign prefix depends on what the mobile node 
use it for. Originally a prefix advertised in a home link is 
_a prefix_ for "creating IP address".
[Proposal-1]
- Not affected
[Proposal-2]
- Not affected

> complicated. The HA needs to register CoA generated from the home

** About HA operation:
According to RFC3775 section 9.5.1, HA does not determine if the address
is home address or not by checking only prefix. Determining the address
must be based on the whole address, not prefix only.
[Proposal-1]
- Not affected
[Proposal-2]
- Affected
 - HA has to prepare and manage the foreign prefix other than home prefix.
   The network has to be multihomed.

> registers the Home-CoA when it returns home.

** About MCoA-MN operation:
[Proposal-1]
MCoA-MN can choose the interface to use from following scenarios.
There are three scenarios. 
 - Scenario1: MN wants to use home attached interface by returning home.
 - Scenario2: MN wants to use foreign attached interface.
 - Scenario3: MN wants to use both interfaces.
[Proposal-2]
MCoA-MN can use both interfaces but never return home, so, scenario1 never
happen.

** About Legacy-MN operation:
[Proposal-1]
- Not affected
[Proposal-2]
- Affected
 - Legacy-MN also never return home.

> 1. DO NOT support simultaneous use of foreign and home when MN returns
According to the charter, one of the objectives of Monami6 is 
to produce the solution allowing MN to utilize multiple interfaces simultaneously. 
Accordingly, MN should be able to obtain this effect in any case. 
I think this is not the alternative.

Regards,
Keigo

---

From: Keiichi SHIMA <[email-masked]>
Date: Mon, 20 Nov 2006 14:47:04 +0900

Hello Ryuji and all,

Before commenting to the question, let me ask one clarification  
question.

When a mobile node returns home, why do we need to use Mobile IPv6?   
It can act just as  a multi-interfaced node while it is at home.  I  
wonder why the node just de-register and use normal multi-interface  
utilization technologies when returning to home.

> There were several discussions with Keigo on Monami6 ML

---
Keiichi SHIMA
IIJ Research Laboratory <[email-masked]>
WIDE Project <[email-masked]>

---

From: "Tsirtsis, George" <[email-masked]>
Date: Mon, 20 Nov 2006 13:34:07 -0800

Keiichi,

I think the problem is that the mobile can be in a situation where one
of its interfaces is at home and one or more of its other interfaces
maybe connected to foreign links. In this case the mobile is supposed to
deregister, since it has returned home, which would mean that the
interfaces connected to foreign links can not be utilized.

George
> -----Original Message-----
> From: Keiichi SHIMA [mailto:[email-masked]]
> Sent: Monday, November 20, 2006 12:47 AM
> To: Monami6 WG
> Subject: Re: [Monami6] (Issue-2 MCoA) Should MN returns Home with
> bothinterfaces attached to home and foreign?
> 
> Hello Ryuji and all,
> 
>

---

From: Keiichi SHIMA <[email-masked]>
Date: Tue, 21 Nov 2006 12:13:11 +0900

Hello George,

> interfaces connected to foreign links can not be utilized.

Ah, OK, we are trying to utilize the other link (that is not attached  
to the home link of a mobile node) using the home address of the  
mobile node, while it is at home.

Well, since the traffic sent via the foreign link will go to the home  
agent eventually, I am not sure such use is really useful or not.   
Maybe it is useful in the RO case, but currently we are not talking  
about the RO case.

If I have to choose one from the two proposals, then I choose the  
proposal-1.

---
Keiichi SHIMA

---

From: Alexandru Petrescu <[email-masked]>
Date: Tue, 21 Nov 2006 10:31:08 +0100

Tsirtsis, George wrote:
> Keiichi,
> 
> I think the problem is that the mobile can be in a situation where
> one of its interfaces is at home and one or more of its other
> interfaces maybe connected to foreign links. In this case the
> mobile is supposed to deregister, since it has returned home, which
> would mean that the interfaces connected to foreign links can not
> be utilized.

It wouldn't mean so if each interface used a different Home Address -
de-register the interface on home link but leave the roaming interface
registered.  IMHO.

Alex

> 
> George
>> -----Original Message----- From: Keiichi SHIMA
>> [mailto:[email-masked]] Sent: Monday, November 20, 2006 12:47
>> AM To: Monami6 WG Subject: Re: [Monami6] (Issue-2 MCoA) Should MN
>> returns Home with bothinterfaces attached to home and foreign?
>> 
>> Hello Ryuji and all,
>> 
>> 
>> When a mobile node returns home, why do we need to use Mobile
>> IPv6? It can act just as  a multi-interfaced node while it is at
>> home.  I wonder why the node just de-register and use normal
>> multi-interface utilization technologies when returning to home.
>> 
>> 
>>>  foreign link.  It cannot utilize both interfaces attached to
>>> home
> and
>>> If the MN activates its HoA to the interface attached to the
>>> home link, address duplication is occurred. Then MN may
>>> shutdown the interface as RFC2942 specified.
>>> 
>>> * Proposal:
>>> 
>>> - Proposal-1 Use of Home CoA. When MN returns home, it
>>> generates a Home-CoA
> from
>>> its home network prefix. MN registers its Home-CoA to its HA
>>> and creates tunnel at the interface attached to the home link
>>> so that it can utilize both of interface attached to home and
>>> foreign
> link.
>>> - Proposal-2
>>> 
>>> prefixes on its home link, MN can generates a CoA from one of
>>> non home prefixes advertised by its HA. Therefore, it can
>>> registers
> the
>>> the distance to HA is just one-hop. This is same overhead as
>>> the home-CoA.
>>> 
>>> * pros & cons
>>> 
>>> The Home-CoA requires the definition of HoA and CoA. RFC3775
>>> does
> not
>>> say the CoA can be generated from its home prefix. The home
>>> prefix
> is
>>> used to generate HoA for each MN. Any extensions and protocols
>>> based on RFC3775 inherits this definition, some side effects
>>> may be
> observed
>>> and caused later. In addition to this, the processing of MN and
>>> HA
> is
>>> complicated. The HA needs to register CoA generated from the
>>> home prefix. The MN must decide whether it deregisters its
>>> binding or registers the Home-CoA when it returns home. 
>>> Moreover, if a destination of the MN is located on the home
>>> link,
> the
>>> MN may bypass the bidirectional tunnel. 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.
>>> 
>>> * Conclusion - PENDING 1. DO NOT support simultaneous use of
>>> foreign and home when MN
> returns
>>> home. (REJECT) 2. Support the scenario of the simultaneous use
>>> by the Home-CoA Solution. (ACCEPT) 3. Support the scenario of
>>> the simultaneous use by the Operational Solution. (ACCEPT)
>>> 
>>> Any comments? There were several discussions with Keigo on
>>> Monami6 ML
>>> 
>>> regards, ryuji
>>> 
>>> 
>>> _______________________________________________ Monami6 mailing
>>> list [email-masked] 
>> --- Keiichi SHIMA IIJ Research Laboratory <[email-masked]> 
>> _______________________________________________ Monami6 mailing
>> list [email-masked] 
> _______________________________________________ Monami6 mailing
> list [email-masked]

---

From: "Benjamin Lim" <[email-masked]>
Date: Tue, 21 Nov 2006 17:45:57 +0800

Hi, 

> From: Alexandru Petrescu [mailto:[email-masked]] 
> Sent: Tuesday, November 21, 2006 5:31 PM
> To: Monami6 WG
> Subject: Re: [Monami6] (Issue-2 MCoA) Should MN returns 
> Homewith bothinterfaces attached to home and foreign?
> 
> Tsirtsis, George wrote:
> > Keiichi,
> > 
> > maybe connected to foreign links. In this case the mobile 
> is supposed 
> > to deregister, since it has returned home, which would mean 
> that the 
> It wouldn't mean so if each interface used a different Home 
> Address - de-register the interface on home link but leave 
> the roaming interface registered.  IMHO.
> 
[Ben] I agree to the above if multiple HoAs are used. However, that defeat
the purpose of MN using MCoA as MCoA allows binding of multiple CoAs to a
single HoA. So in the case of MN having CoA on each interface bound to a
single HoA, MN can't de-register interface on home link as this means that
it will lose the binding for the roaming interface. With this, I would
support proposal 1, the use of Home CoA to handle this issue of
simultaneously attaching to home and foreign.

Regards,
Benjamin Lim
> >> [mailto:[email-masked]] Sent: Monday, November 20, 
> 2006 12:47 AM 
> >> To: Monami6 WG Subject: Re: [Monami6] (Issue-2 MCoA) Should MN 
> generates a 
> >>> Home-CoA
> >>> creates tunnel at the interface attached to the home link 
> so that it 
> >>> can utilize both of interface attached to home and foreign
> > link.
> >>> - Proposal-2
> >>> 
> >>> * Conclusion - PENDING 1. DO NOT support simultaneous use 
> of foreign 
> >>> and home when MN
> > returns
> >>> home. (REJECT) 2. Support the scenario of the simultaneous use by 
> >>> the Home-CoA Solution. (ACCEPT) 3. Support the scenario of the 
> >>> simultaneous use by the Operational Solution. (ACCEPT)
> >>> 
> >>> _______________________________________________ Monami6 
> mailing list 
> >>> [email-masked]
> >> --- Keiichi SHIMA IIJ Research Laboratory 
> <[email-masked]> WIDE 
> >> Project <[email-masked]>
> >> 
> >> 
> >> 
> >> 
> >> _______________________________________________ Monami6 
> mailing list 
> >> [email-masked]
> > _______________________________________________ Monami6 
> mailing list 
> > [email-masked]

---

From: Alexandru Petrescu <[email-masked]>
Date: Tue, 21 Nov 2006 11:11:57 +0100

Benjamin Lim wrote:
> Hi,
> 
>> -----Original Message----- From: Alexandru Petrescu 
>> [mailto:[email-masked]] Sent: Tuesday, November
>>  21, 2006 5:31 PM To: Monami6 WG Subject: Re: [Monami6] (Issue-2
>>  MCoA) Should MN returns Homewith bothinterfaces attached to home
>>  and foreign?
>> 
>> Tsirtsis, George wrote:
>>> Keiichi,
>>> 
>> Address - de-register the interface on home link but leave the 
>> roaming interface registered.  IMHO.
>> 
> [Ben] I agree to the above if multiple HoAs are used. However, that
>  defeat the purpose of MN using MCoA as MCoA allows binding of 
> multiple CoAs to a single HoA.

I agree.

> So in the case of MN having CoA on each interface bound to a single
>  HoA, MN can't de-register interface on home link as this means
> that it will lose the binding for the roaming interface. With this,
> I would support proposal 1, the use of Home CoA to handle this
> issue of simultaneously attaching to home and foreign.

A 3rd option, as suggested by Keiichi (if I understand correctly),
would be to not use Mobile IPv6 at all if one of the interfaces is
connected to its home link.  Doing so would not defeat the goal of
using MCoA, but restrict its scope to only when there's no interface
connected to its home link.

A 4th option is to still send a 1-CoA BU for the roaming interface,
different BID, a 1-CoA deregister BU for the homed interface old BID.

A 5th option is to have a home-CoA as already suggested by Ryuji, so a
binding cache entry while at home, but not use tunnelling for that
binding cache entry.

Alex

---

From: "Benjamin Lim" <[email-masked]>
Date: Wed, 22 Nov 2006 09:57:19 +0800

Hi, 

> Sent: Tuesday, November 21, 2006 6:12 PM
> To: [email-masked]; Monami6 WG
> >> [mailto:[email-masked]] Sent: Tuesday, 
> November  21, 
> >> 2006 5:31 PM To: Monami6 WG Subject: Re: [Monami6] (Issue-2
> >> de-register the interface on home link but leave the roaming 
> >> interface registered.  IMHO.
> >> 
> > defeat the purpose of MN using MCoA as MCoA allows binding 
> of multiple 
> > CoAs to a single HoA.
> 
> I agree.
> 
> > HoA, MN can't de-register interface on home link as this 
> means that it 
> > will lose the binding for the roaming interface. With this, I would 
> A 3rd option, as suggested by Keiichi (if I understand 
> correctly), would be to not use Mobile IPv6 at all if one of 
> the interfaces is connected to its home link.  Doing so would 
> not defeat the goal of using MCoA, but restrict its scope to 
> only when there's no interface connected to its home link.
> 
> A 4th option is to still send a 1-CoA BU for the roaming 
> interface, different BID, a 1-CoA deregister BU for the homed 
> interface old BID.
[Ben] How is this different from the second situation specified in section
3.3 of the  MCoA draft?

> 
> A 5th option is to have a home-CoA as already suggested by 
> Ryuji, so a binding cache entry while at home, but not use 
> tunnelling for that binding cache entry.
[Ben] This can be implementation but not sure if telling HA not to tunnel
will create other issues.

Regards,
Benjamin Lim

---

From: Romain KUNTZ <[email-masked]>
Date: Wed, 29 Nov 2006 11:40:57 +0700

Hi Ryuji,

For the reasons stated in the previous discussion related to this topic, 
I would be in favor of proposal-2, ie:

We can thus keep the solution simple: if the node wants to fallback in a 
single-homed node, it just deregisters all its bindings to the HA and 
uses its interface connected to the home link with its HoA. If it wants 
to go on using its multiple interface, it can configure a CoA from 
another prefix advertised by the HA.

regards,

Romain

-- 
Romain KUNTZ
[email-masked]

---

From: Benjamin Koh Tien-Ming <[email-masked]>
Date: Wed, 29 Nov 2006 13:07:46 +0800

Hi Romain!

Romain KUNTZ wrote:
> uses its interface connected to the home link with its HoA. 

[BK]
This option is also available under proposal-1. For both proposals,
deregistering all its bindings to the HA and using just the interface
connected to the home link with its HoA is available and the steps
required similar.

> If it wants to go on using its multiple interface, it can configure a 
> CoA from another prefix advertised by the HA.

[BK]
Configuring a CoA generated from its home network prefix is not that
much more different from generating one from another prefix advertised
by the HA. In both cases, both the HA and node should be aware of the
significance of the home network CoA.

I fail to understand how implementing proposal-2 keeps the solution
simple? Maybe I'm missing something here.

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]  |
\>>>>>>>>>>>>>>>>>>>>--<<<<<<<<<<<<<<<<<<<</