Subject: [Monami6] Re: Modified text for new MCoA draft

From: RYUJI WAKIKAWA <[email-masked]>
Date: Mon, 23 Oct 2006 08:20:58 +0900

Hi Keigo and all,

At Fri, 13 Oct 2006 18:06:52 +0900,
Keigo Aso wrote:

>
> Dear Monami6 MCoA-draft Editors,
>
> Let me ask some question on the current status of MCoA draft.
>
> (1)Do you have a plan to submit MCoA draft-01 to next San Diego  
> meeting ?
>

yes!

> (2)If you have it, could I hear your opinion for our modified text ?
> #I believe this text is available for the purpose of adding
> the description to "Figure 7" of MCoA draft-00, which is the agreement
> in Montreal meeting.
>

I did not agree to add this changes to the draft. I asked to propose
some texts and discuss the text on the ML. (Which I failed to do
before the deadline, I apologize this)

Since the proposed text still saying that MN creates CoA at the home
network. If you really want this text in the draft, you must extend
the definition of HoA and CoA. If you assume that multiple prefixes
(one home prefix and the other prefix) are advertised on the "home
link", it can be treated as the scenario 2. You still need "tunnel"
between MN and HA. It is exact same as the second scenario. Thus, this
situation falls back to the second situation. It is tricky to say that
a MN creates CoA when it returns its home link.

I want to explain the reason of my disagreement again.

The address which is obtained from the home prefix must be always
treated as a home address. According to MIP6 terminology, the CoA you
referred in your text is "HoA". see the below definition.

    home address
       A unicast routable address assigned to a mobile node, used as the
       permanent address of the mobile node.  This address is within the
       mobile node's home link.  Standard IP routing mechanisms will
       deliver packets destined for a mobile node's home address to its
       home link.  Mobile nodes can have multiple home addresses, for
       instance when there are multiple home prefixes on the home link.

    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.  Among the multiple care-of addresses that
       a mobile node may have at any given time (e.g., with different
       subnet prefixes), the one registered with the mobile node's home
       agent for a given home address is called its "primary" care-of
       address.

In addition to that, what you are proposing is what the MIP6 spec
claims recursive binding search problem in Section 6.1.7.

    Similarly, the Binding Update MUST be silently discarded if the
    care-of address appears as a home address in an existing Binding
    Cache entry, with its current location creating a circular
    reference back to the home address specified in the Binding Update
    (possibly through additional entries).

I would like to hear the opinion from other WG members.	
If no one agree on Keigo's proposal, I will reject the third scenario.

regards,
ryuji

> We are willing to revise it at any time based on your advice.
>
> Thank you in advance.
> Sorry for sending email frequently.
>
> Best Regards,
> Keigo
>
> ######Please see the following our modified text.######
>
> ---<draft-ietf-monami6-multiplecoa-00.txt>----------------------------
> ---<<Section 3.3>>----------------------------------------------------
>
>> 3.3.  Returning Home
>>
>>    When the mobile node returns home, there are two situations, since
>>    the Home Agent defends the mobile node's Home Address by using the
>>    proxy neighbor advertisement.  It is impossible to utilize all the
>>    interfaces when one interface is attached to the home link and the
>>    others are attached to foreign links.  If the proxy Neighbor
>>    Advertisement for the Home Address is stopped, packets are always
>>    routed to the interface attached to the home link.  If proxy is  
>> not
>>    stopped, packets are never routed to the interface attached to the
>>    home link.  The decision whether a mobile node returns home or  
>> not is
>>    up to implementors.
>>
> [Proposed(to "replace" above with the following)]
> When the mobile node returns home, there are three possible situations
> depending on the choice of interface a mobile node wants to utilise.
> According to Mobile IPv6 RFC3775, when a interface is attached to the
> home link, it MUST de-register the relevant bindings in order to  
> use the
> interface as the home agent defends the mobile node's Home Address  
> using
> the proxy neighbor advertisement. On the other hand, a mobile node  
> with
> multiple interfaces should always be able to use all of its interfaces
> regardless of location.
> [/Proposed]
>
>
>>    The first situation is when a mobile node wants to return home  
>> with
>>    interface attached to the home link.  In this case, the mobile  
>> node
>>    MUST de-register all the bindings by sending a Binding Update with
>>    lifetime set to zero.  The mobile node MAY NOT put any Binding  
>> Unique
>>    Identifier sub-option in this packet.  Then, the receiver  
>> deletes all
>>    the bindings from its binding cache database.
>>
> [Proposed(to "replace" above with the following)]
> The first situation is when a mobile node wants to use only the  
> interface
> attached to the home link.  In this case, the mobile node MUST
> de-register all the bindings by sending a Binding Update which  
> lifetime
> set to zero.  The mobile node MAY NOT put any Binding Unique  
> Identifier
> sub-option in this packet.  Then, the receiver deletes all the  
> bindings
> from its binding cache database.
> [/Proposed]
>
>
>>    The second situation is when a mobile node does not want to return
>>    home, though one of its interfaces is attached to its home  
>> link.  The
>>    mobile node disables the interface attached to the home link and
>>    keeps using the rest of interfaces attached to foreign links.  In
>>    this case, the mobile node sends a de-registration Binding  
>> Update for
>>    the interface attached to the home link with the Binding Unique
>>    Identifier sub-option.  The receiver of the de-registration  
>> Binding
>>    Update deletes only the correspondent binding entry from the  
>> binding
>>    cache database.  The Home Agent does not stop proxying neighbor
>>    advertisement unless there are still bindings for the other
>>    interfaces.
>>
> [Proposed(to "replace" above with the following)]
> The second situation is when a mobile node wants to use only the  
> interfaces
> attached to the foreign links, when one or more of its interfaces is
> attached to its home link. The mobile node disables the interface
> attached to the home link and keeps using the rest of the interfaces
> attached to foreign links.  In this case, the mobile node sends a
> de-registration Binding Update for the interface attached to the home
> link with the Binding Unique Identifier sub-option.  The receiver  
> of the
> de-registration Binding Update deletes only the correspondent binding
> entry from the binding cache database.  The home agent does not stop
> proxying neighbor advertisement while there are still bindings for the
> other interfaces.
> [/Proposed]
>
>
> [Proposed(to "add" the following after above)]
> The third situation is when a mobile node wants to simultaneously use
> interfaces attached to both home and foreign links.  In this case, the
> mobile node MUST create a Care-of Address in the home network which is
> different from its Home Address and send a Binding Update to
> register it. The receiver of the Binding Update creates a new binding
> in its binding cache database. The home agent continues performing  
> proxy
> Neighbor Advertisement for the Home Address of the mobile node.
> [/Proposed]
>
>
>
>>    In the above two cases, a mobile node cannot use interfaces  
>> attached
>>    to both home and foreign links simultaneously.  If this is what a
>>    mobile node wants, a home agent can set up another link other than
>>    home link and uses the link for the mobile node to return  
>> virtually
>>    to home network.  The detail can be found in Figure 7
>>
> [Proposed] (This paragraph should be deleted.) [/Proposed]
> ----------------------------------------------------------------------
>
>
> ---<<Section 5.5>>----------------------------------------------------
>
>> 5.5.  Returning Home
>>
>>    When a mobile node returns home, it MUST de-register all bindings
>>    with the Home Agent.
>>
> [Proposed(to "replace" above with the following)]
> When a mobile node returns home, it can select a interface to use
> even though the other interface is attached to a foreign link.  
> Based on
> the selection of interface to use, the action for the Home Agent of  
> the
> mobile node changes.
> If the mobile node selects to use only the interface attached
> to home link, it MUST de-register all bindings with the Home Agent. If
> the mobile node selects to use only the interface attached to foreign
> link, it MUST keep or register the binding with the Home Agent. If the
> mobile node selects to use both the interface attached to home link  
> and
> the interface attached to foreign link, it MUST use a CoA created  
> using
> the home prefix and register both home and foreign CoAs with the Home
> Agent. In such a case, the mobile node continues to receive packets  
> from
> both interfaces.
> [/Proposed]
>
>
>>    Although the mobile node MUST delete the bindings with  
>> Correspondent
>>    Nodes as well, the node can still keep the binding of the other
>>    interface active attached to foreign links at the Correspondent
>>    Nodes.  In such case, the mobile node still receives packets at  
>> the
>>    other interface attached to a foreign link thanks to route
>>    optimization.  The mobile node also receives packets at the  
>> interface
>>    attached to the home link when Correspondent Nodes does not use  
>> route
>>    optimization.
>>
> [Proposed(to "replace" above with the following)]
> For the Correspondent Nodes, regardless of the mobile node's selection
> of interface to use at the Home Agent, it can still keep the  
> binding of
> the other interface attached to foreign links active. In such a case,
> the mobile node still receives packets at the interface attached to a
> foreign link thanks to route optimization.  The mobile node also
> receives packets at the interface attached to the home link when
> Correspondent Nodes does not use route optimization. The mobile  
> node may
> optionally register it's home-prefixed CoA at the Correspondent Nodes.
> [/Proposed]
>
>
>>    Note that when the mobile node does not want to return home  
>> even if
>>    one of interfaces is attached to the home link, the mobile node  
>> MUST
>>    disable the interface.  Otherwise, address duplication will be
>>    observed because the Home Agent still defend the Home Address  
>> by the
>>    proxy neighbor advertisement and the mobile node also enables the
>>    same Home Address on the home link.  After disabling the interface
>>    attached to the home link, the mobile node MUST delete the binding
>>    for the interface by sending a de-registration binding update.   
>> The
>>    de-registration binding update must be sent from one of active
>>    interfaces attached to foreign links.  As a result, the mobile  
>> node
>>    no longer receives packets at the interface attached to the home
>>    link.  All packets are routed to other interfaces attached to a
>>    foreign link.
>>
> [Proposed] (This paragraph should be deleted.) [/Proposed]
> ----------------------------------------------------------------------
>
>
> ---<<Section 6.1>>----------------------------------------------------
>
>> 6.1.  Searching Binding Cache with Binding Unique Identifier
>>
>>    If either a Correspondent Node or a Home Agent has multiple  
>> bindings
>>    for a mobile node in their binding cache database, it can use  
>> any of
>>    the bindings to communicate with the mobile node.  How to  
>> select the
>>    most suitable binding from the binding cache database is out of  
>> scope
>>    in this document.
>>
>>    Whenever a Correspondent Node searches a binding cache for a home
>>    address, it SHOULD uses both the Home Address and the BID as the
>>    search key if it knows the corresponding BID.  If the priority is
>>    available for a binding cache entry, the priority can be used as
>>    additional key to search a binding.
>>
> [Proposed(to "add" the following after above)]
> Moreover, when a Home Agent has the entries of the CoAs both
> at home and foreign, if it can distinguish between the entry for at  
> home
> and at foreign, the distinction can be used as further additional
> information to search a binding.
> [/Proposed]
>
>
>>    In the example below, if a
>>    Correspondent Node searches the binding with the Home Address and
>>    BID2, it gets binding2 for this mobile node.
>>
>
> ----------------------------------------------------------------------
>
>
>
>
>
>
>
> On Thu, 05 Oct 2006 18:37:56 +0900
> Keigo Aso <[email-masked]> wrote:
>
>
>> Hello Monami6 MCoA-draft Editors,
>>
>> Let me dare to resend the following email including our modified text
>> for next MCoA draft-01. We would really like to hear your opinion and
>> advance our contribution more.
>> These modified text is made based on the previous session in Montreal
>> and needed for updating current MCoA draft-00.
>>
>> We would appreciate any comments.
>>
>>
>> Best Regards,
>> Keigo & Benjamin Koh
>>
>>
>> Forwarded by Keigo Aso <[email-masked]>
>> ----------------------- Original Message -----------------------
>>  From:    Keigo Aso <[email-masked]>
>>  To:      Thierry Ernst <[email-masked]>,
>>           Ken Nagami <[email-masked]>,
>>           Ryuji Wakikawa <[email-masked]>
>>  Cc:      Benjamin Koh Tien-Ming <[email-masked]>
>>  Date:    Wed, 27 Sep 2006 14:36:48 +0900
>>  Subject: Modified text for new MCoA draft
>> ----
>>
>> Hello MCoA-draft Editors,
>>
>>
>> In our presentation(draft-aso-monami6-multiple-forwarding-01)
>> at the previous Monami6 session in Montreal,
>> there was the agreement from Ryuji as Editor to add some description
>> on using both interfaces simultaneously for returning home.
>> So, after that, we have considered the available description
>> for new MCoA draft in order to advance our contribution more.
>> As a result of that, let me dare to show the modified text
>> for some sections(3.3, 5.5, 6.1) in the current MCoA draft.
>>
>> I think the following text is useful for you to understand
>> our thinking more in detail.
>> We hope you look at the following and then additionally we hope
>> it is used as the text for the new MCoA draft.
>>
>> We would appreciate any comments.
>>
>> #We sent the following description to Ryuji before, but no response
>> from him yet. Sorry for duplicated email.
>>
>>
>> Best Regards,
>> Keigo & Benjamin Koh
>>
>>
>>
>> ---<draft-ietf-monami6- 
>> multiplecoa-00.txt>----------------------------
>> ---<<Section  
>> 3.3>>----------------------------------------------------
>>
>>> 3.3.  Returning Home
>>>
>>>    When the mobile node returns home, there are two situations,  
>>> since
>>>    the Home Agent defends the mobile node's Home Address by using  
>>> the
>>>    proxy neighbor advertisement.  It is impossible to utilize all  
>>> the
>>>    interfaces when one interface is attached to the home link and  
>>> the
>>>    others are attached to foreign links.  If the proxy Neighbor
>>>    Advertisement for the Home Address is stopped, packets are always
>>>    routed to the interface attached to the home link.  If proxy  
>>> is not
>>>    stopped, packets are never routed to the interface attached to  
>>> the
>>>    home link.  The decision whether a mobile node returns home or  
>>> not is
>>>    up to implementors.
>>>
>> [Proposed(to "replace" above with the following)]
>> When the mobile node returns home, there are three possible  
>> situations
>> depending on the choice of interface a mobile node wants to utilise.
>> According to Mobile IPv6 RFC3775, when a interface is attached to the
>> home link, it MUST de-register the relevant bindings in order to  
>> use the
>> interface as the home agent defends the mobile node's Home Address  
>> using
>> the proxy neighbor advertisement. On the other hand, a mobile node  
>> with
>> multiple interfaces should always be able to use all of its  
>> interfaces
>> regardless of location.
>> [/Proposed]
>>
>>
>>>    The first situation is when a mobile node wants to return home  
>>> with
>>>    interface attached to the home link.  In this case, the mobile  
>>> node
>>>    MUST de-register all the bindings by sending a Binding Update  
>>> with
>>>    lifetime set to zero.  The mobile node MAY NOT put any Binding  
>>> Unique
>>>    Identifier sub-option in this packet.  Then, the receiver  
>>> deletes all
>>>    the bindings from its binding cache database.
>>>
>> [Proposed(to "replace" above with the following)]
>> The first situation is when a mobile node wants to use only the  
>> interface
>> attached to the home link.  In this case, the mobile node MUST
>> de-register all the bindings by sending a Binding Update which  
>> lifetime
>> set to zero.  The mobile node MAY NOT put any Binding Unique  
>> Identifier
>> sub-option in this packet.  Then, the receiver deletes all the  
>> bindings
>> from its binding cache database.
>> [/Proposed]
>>
>>
>>>    The second situation is when a mobile node does not want to  
>>> return
>>>    home, though one of its interfaces is attached to its home  
>>> link.  The
>>>    mobile node disables the interface attached to the home link and
>>>    keeps using the rest of interfaces attached to foreign links.  In
>>>    this case, the mobile node sends a de-registration Binding  
>>> Update for
>>>    the interface attached to the home link with the Binding Unique
>>>    Identifier sub-option.  The receiver of the de-registration  
>>> Binding
>>>    Update deletes only the correspondent binding entry from the  
>>> binding
>>>    cache database.  The Home Agent does not stop proxying neighbor
>>>    advertisement unless there are still bindings for the other
>>>    interfaces.
>>>
>> [Proposed(to "replace" above with the following)]
>> The second situation is when a mobile node wants to use only the  
>> interfaces
>> attached to the foreign links, when one or more of its interfaces is
>> attached to its home link. The mobile node disables the interface
>> attached to the home link and keeps using the rest of the interfaces
>> attached to foreign links.  In this case, the mobile node sends a
>> de-registration Binding Update for the interface attached to the home
>> link with the Binding Unique Identifier sub-option.  The receiver  
>> of the
>> de-registration Binding Update deletes only the correspondent binding
>> entry from the binding cache database.  The home agent does not stop
>> proxying neighbor advertisement while there are still bindings for  
>> the
>> other interfaces.
>> [/Proposed]
>>
>>
>> [Proposed(to "add" the following after above)]
>> The third situation is when a mobile node wants to simultaneously use
>> interfaces attached to both home and foreign links.  In this case,  
>> the
>> mobile node MUST create a Care-of Address in the home network  
>> which is
>> different from its Home Address and send a Binding Update to
>> register it. The receiver of the Binding Update creates a new binding
>> in its binding cache database. The home agent continues performing  
>> proxy
>> Neighbor Advertisement for the Home Address of the mobile node.
>> [/Proposed]
>>
>>
>>
>>>    In the above two cases, a mobile node cannot use interfaces  
>>> attached
>>>    to both home and foreign links simultaneously.  If this is what a
>>>    mobile node wants, a home agent can set up another link other  
>>> than
>>>    home link and uses the link for the mobile node to return  
>>> virtually
>>>    to home network.  The detail can be found in Figure 7
>>>
>> [Proposed] (This paragraph should be deleted.) [/Proposed]
>> --------------------------------------------------------------------- 
>> -
>>
>>
>> ---<<Section  
>> 5.5>>----------------------------------------------------
>>
>>> 5.5.  Returning Home
>>>
>>>    When a mobile node returns home, it MUST de-register all bindings
>>>    with the Home Agent.
>>>
>> [Proposed(to "replace" above with the following)]
>> When a mobile node returns home, it can select a interface to use
>> even though the other interface is attached to a foreign link.  
>> Based on
>> the selection of interface to use, the action for the Home Agent  
>> of the
>> mobile node changes.
>> If the mobile node selects to use only the interface attached
>> to home link, it MUST de-register all bindings with the Home  
>> Agent. If
>> the mobile node selects to use only the interface attached to foreign
>> link, it MUST keep or register the binding with the Home Agent. If  
>> the
>> mobile node selects to use both the interface attached to home  
>> link and
>> the interface attached to foreign link, it MUST use a CoA created  
>> using
>> the home prefix and register both home and foreign CoAs with the Home
>> Agent. In such a case, the mobile node continues to receive  
>> packets from
>> both interfaces.
>> [/Proposed]
>>
>>
>>>    Although the mobile node MUST delete the bindings with  
>>> Correspondent
>>>    Nodes as well, the node can still keep the binding of the other
>>>    interface active attached to foreign links at the Correspondent
>>>    Nodes.  In such case, the mobile node still receives packets  
>>> at the
>>>    other interface attached to a foreign link thanks to route
>>>    optimization.  The mobile node also receives packets at the  
>>> interface
>>>    attached to the home link when Correspondent Nodes does not  
>>> use route
>>>    optimization.
>>>
>> [Proposed(to "replace" above with the following)]
>> For the Correspondent Nodes, regardless of the mobile node's  
>> selection
>> of interface to use at the Home Agent, it can still keep the  
>> binding of
>> the other interface attached to foreign links active. In such a case,
>> the mobile node still receives packets at the interface attached to a
>> foreign link thanks to route optimization.  The mobile node also
>> receives packets at the interface attached to the home link when
>> Correspondent Nodes does not use route optimization. The mobile  
>> node may
>> optionally register it's home-prefixed CoA at the Correspondent  
>> Nodes.
>> [/Proposed]
>>
>>
>>>    Note that when the mobile node does not want to return home  
>>> even if
>>>    one of interfaces is attached to the home link, the mobile  
>>> node MUST
>>>    disable the interface.  Otherwise, address duplication will be
>>>    observed because the Home Agent still defend the Home Address  
>>> by the
>>>    proxy neighbor advertisement and the mobile node also enables the
>>>    same Home Address on the home link.  After disabling the  
>>> interface
>>>    attached to the home link, the mobile node MUST delete the  
>>> binding
>>>    for the interface by sending a de-registration binding  
>>> update.  The
>>>    de-registration binding update must be sent from one of active
>>>    interfaces attached to foreign links.  As a result, the mobile  
>>> node
>>>    no longer receives packets at the interface attached to the home
>>>    link.  All packets are routed to other interfaces attached to a
>>>    foreign link.
>>>
>> [Proposed] (This paragraph should be deleted.) [/Proposed]
>> --------------------------------------------------------------------- 
>> -
>>
>>
>> ---<<Section  
>> 6.1>>----------------------------------------------------
>>
>>> 6.1.  Searching Binding Cache with Binding Unique Identifier
>>>
>>>    If either a Correspondent Node or a Home Agent has multiple  
>>> bindings
>>>    for a mobile node in their binding cache database, it can use  
>>> any of
>>>    the bindings to communicate with the mobile node.  How to  
>>> select the
>>>    most suitable binding from the binding cache database is out  
>>> of scope
>>>    in this document.
>>>
>>>    Whenever a Correspondent Node searches a binding cache for a home
>>>    address, it SHOULD uses both the Home Address and the BID as the
>>>    search key if it knows the corresponding BID.  If the priority is
>>>    available for a binding cache entry, the priority can be used as
>>>    additional key to search a binding.
>>>
>> [Proposed(to "add" the following after above)]
>> Moreover, when a Home Agent has the entries of the CoAs both
>> at home and foreign, if it can distinguish between the entry for  
>> at home
>> and at foreign, the distinction can be used as further additional
>> information to search a binding.
>> [/Proposed]
>>
>>
>>>    In the example below, if a
>>>    Correspondent Node searches the binding with the Home Address and
>>>    BID2, it gets binding2 for this mobile node.
>>>
>>
>> --------------------------------------------------------------------- 
>> -
>>
>>
>>
>> --------------------- Original Message Ends --------------------
>>
>>
>
>
>

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

---

From: Chan-Wah NG <[email-masked]>
Date: Mon, 23 Oct 2006 11:12:47 +0800

Hello, Ryuji,

> before the deadline, I apologize this)

Given the deadline is today, are you still planning on submitting
one? ;)

> If no one agree on Keigo's proposal, I will reject the third scenario.

As far I can I see, your disagreement is only based on the definition of
a Home Address and Care-of Address.  While I do agree that confusion
with definitions may lead to catastophic mistakes in implementation, I
feel that the benefits of Keigo's proposal is too good to be discarded
away merely because of simple terminology issues.

An easy way to resolve this is to create a new terminology for the
Care-of Address configured from the Home Prefix, and state in the
definition of this new term that "It MUST NOT be regsitered as a Home
Address".  That will ensure your worry of Recursive binding search
problem never to occur.

/rgds
/cwng

-- 
Chan-Wah NG <[email-masked]>
Panasonic Singapore Labs

---

From: Keigo Aso <[email-masked]>
Date: Mon, 23 Oct 2006 13:15:58 +0900

Hi Ryuji,

Thank you for your response.
Please see my comments inline.
> a MN creates CoA when it returns its home link.
I think that the case multiple prefixes are advertised on the "home link" 
is not the scenario 2(== "the second situation" in the draft). 
The scenario 2 is the case that "a mobile node wants to use only 
the interfaces attached to the foreign links", that's why, 
   "the mobile node sends a de-registration Binding Update for 
    the interface attached to the home link with the Binding Unique
    Identifier sub-option."(in section 3.3 of MCoA draft-00)

If the other prefix is advertised on the home link, it is different
from scenario 1 and 2. Because it means the case that "a mobile
node wants to simultaneously use interfaces attached to both home and
foreign links." At least, the scenario 2 does not need the other prefix
on the home link.

Currently the discussion point is not either adding the scenario 3 
or not, the point we should focus on is what prefix should be used 
for the mobile node creating a address in the home link for 
the scenario 3.

And technically if the other prefix is advertised on the home link for 
the scenario 3, it causes some disadvantages for MIPv6-only mobile node.
So, using a home prefix for forming a care-of address and creating 
a new definition for the address is a effective method.

>        agent for a given home address is called its "primary" care-of
Whether a link is a home link or not depends on the mobile node which
connects to it. A prefix in the home link for the mobile node can become
a foreign prefix for other mobile node whose home network is different.
So, I agree on that "the home address must be always the address 
which is obtained from the home prefix" but I don't think "The address
which is obtained from the home prefix must be always treated as 
a home address." 

Regards,
Keigo

---

From: RYUJI WAKIKAWA <[email-masked]>
Date: Thu, 26 Oct 2006 02:30:33 +0900

Hello Chan-Wah

> Given the deadline is today, are you still planning on submitting

I was and submitted the draft, but the deadline was already passed:-<
I will send the updated document before the meeting.

> away merely because of simple terminology issues.

Keigo's proposal can be achieved without expanding Home Prefix  
Definition.
We've already introduced texts for the other possible operation.
Here is the updated text for the related part (copy from 01).
--- start ---
    Figure 7 depicts the scenario where interfaces of MN are attached to
    the foreign links.  One of foreign link is managed by the home  
agent.
    The HA and CN have the binding entries listed in Figure 7 in their
    binding cache database.  The home agent advertises a prefix which is
    other than home prefix.  The mobile node will generate a care-of
    address from the prefix and registers it to the home agent.  Even if
    the mobile node attaches to a foreign link, the link is managed by
    its home agent.  It will tunnel the packets to the home agent, but
    the home agent is one-hop neighbor.  The cost of tunnel is
    negligible.  If the mobile node wants to utilize not only an
    interface attached to home but also interfaces attached to foreign
    link, it can use this foreign link of the home agent to return home.
    This is different from the general returning home, but this enable
    the capability of using interfaces attached to both home and foreign
    link without any modifications to Mobile IPv6 and NEMO basic  
support.

                     +----+
                     | CN |
                     +--+-+
                        |
                    +---+------+          +----+
             +------+ Internet |----------+ HA |
             |      +----+-----+          ++-+-+
         CoA2|           |                 | |   Home Link
          +--+--+        |             ----|-+------
          |  MN +========+                 |
          +--+--+ CoA1                ---+-+------
        CoA3 |                           |  Foreign Link
             +---------------------------+

      Binding Cache Database:
         Home Agent's binding (Proxy neighbor advertisement is active)
               binding [a:b:c:d::EUI  Care-of Address1  BID1]
               binding [a:b:c:d::EUI  Care-of Address2  BID2]
               binding [a:b:c:d::EUI  Care-of Address3  BID3]
         Correspondent Node's binding
               binding [a:b:c:d::EUI  Care-of Address1  BID1]
               binding [a:b:c:d::EUI  Care-of Address2  BID2]
               binding [a:b:c:d::EUI  Care-of Address3  BID3]

--- end ---

> Address".  That will ensure your worry of Recursive binding search

Actually, this is not only definition problem.
This also requires to change HA and MN operation.
 From HA, it is impossible to determine whether an address generated
from a home network prefix is HoA or home-CoA.
MN needs certain indication of home-CoA.

regards
ryuji

---

From: RYUJI WAKIKAWA <[email-masked]>
Date: Thu, 26 Oct 2006 02:39:00 +0900

Hello Keio

> for the mobile node creating a address in the home link for

See my previous mail. The proposed modification has a problem.
I cannot accept this issue unless it gets clear.

> a new definition for the address is a effective method.

IPv6 support multiple prefix advertisement on a link.
RFC3775 does not prohibit advertising multiple prefixes on a link.
If I remember correctly, 3775 also mentions that HA may advertise  
multiple home prefix to it.

How MN handles this is up to movement detection algorithm and  
implementations.

> which is obtained from the home prefix must be always treated as

It is not the problem of your disagreement.
There is clear definition of HoA and CoA in 3775.

regards,
ryuji

---

From: Benjamin Koh Tien-Ming <[email-masked]>
Date: Thu, 26 Oct 2006 09:55:00 +0800

Hi all!

RYUJI WAKIKAWA wrote:

[snip]
> I cannot accept this issue unless it gets clear.

[BK]
I assume that you mean the recursive binding search problem (S6.1.7, RFC 
3775).  This particular problem only occurs if a care-of address appears 
as a home address in an existing Binding Cache entry. However we are 
proposing that a new unique address (different from any other HoAs) 
created using the home prefix be registered as a CoA under MNs original 
HoA. This CoA created using the home prefix should under normal 
operation NEVER BEEN USED as a HoA. Hence, HA should never encounter the 
binding search problem (unless some other MN uses that address as its 
own HoA in which the address auto-configuration of that network is 
highly suspect... ;)

[snip]
> There is clear definition of HoA and CoA in 3775.

[BK]
I believe Keigo is saying that although the definition mandates the HoA 
to come from a home link, it does not mean that the opposite is true 
(ie. that all addresses from a home link is a HoA) Since RFC 3775 never 
dictates that the HA treats all addresses from its home link as HoAs, 
there should be no confusion of whether a home link address is a CoA or 
a HoA. RFC 3775 states that the HA uses the Home Address Destination 
Option if available (Source Address field otherwise) to decide if an MN 
is using a particular address as a HoA.

Regards,
Ben

---

From: Benjamin Koh Tien-Ming <[email-masked]>
Date: Thu, 26 Oct 2006 10:11:25 +0800

Hi All!

RYUJI WAKIKAWA wrote:

[snip]
> Keigo's proposal can be achieved without expanding Home Prefix Definition.
>    the foreign links.  One of foreign link is managed by the home agent.
>    link without any modifications to Mobile IPv6 and NEMO basic support.
> 
>                     +----+
>                     | CN |
>                     +--+-+
>                        |
>                    +---+------+          +----+

[BK]
This is certainly a good addition to the current draft. An additional 
caveat may be for CN or HA to know that this route via the home "foreign 
link" is via a 1-hop tunnel to aid in decision making (optimisation 
problem?).

However, this configuration should not be the only solution to this 
problem.  This method has the following disadvantages:-
1. HA must maintain information on which of its prefixes are home links 
and which are foreign.
2. MNs must know which is the correct home link to configure. Legacy MNs 
may select the home "foreign link" prefix to configure as its HoA which 
introduces a whole lot of other issues.
3. HA spamming all kinds of RAs for home and foreign links sound kinda 
messy to me... ;)

A simpler method would be for MNs wanting the capability of using 
interfaces attached to home and foreign links to configure a new CoA 
using the home link prefix advertised by the HA.  The MN then sends a BU 
to the HA a la RFC 3775 (either [Src Addr: HoA, Alt CoA Opt: HomeCoA] or 
[Src Addr: HomeCoA, Home Address Dst Opt: HoA]).  This method has the 
benefits of:-
1. HA needs only maintain home link prefixes
2. No changes or additional information needs to be given to legacy MNs
3. Home network nodes get some peace and quiet... ;)

> MN needs certain indication of home-CoA.

[BK]
See above.

Regards,
Ben

---

From: RYUJI WAKIKAWA <[email-masked]>
Date: Thu, 26 Oct 2006 13:13:07 +0900

Hello

On 2006/10/26, at 11:11, Benjamin Koh Tien-Ming wrote:

> This is certainly a good addition to the current draft. An  
> additional caveat may be for CN or HA to know that this route via  
> the home "foreign link" is via a 1-hop tunnel to aid in decision  
> making (optimisation problem?).
>
> 1. HA must maintain information on which of its prefixes are home  
> links and which are foreign.

This is general configuration of RFC3775.

> 2. MNs must know which is the correct home link to configure.  
> Legacy MNs may select the home "foreign link" prefix to configure  
> as its HoA which introduces a whole lot of other issues.

Well, HA can turn down the home link. I.e. setting up  a virtual home  
link.

> 3. HA spamming all kinds of RAs for home and foreign links sound  
> kinda messy to me... ;)

can you elaborate??

> interfaces attached to home and foreign links to configure a new  
> CoA using the home link prefix advertised by the HA.  The MN then  
> sends a BU to the HA a la RFC 3775 (either [Src Addr: HoA, Alt CoA  
> Opt: HomeCoA] or [Src Addr: HomeCoA, Home Address Dst Opt: HoA]).   
> This method has the benefits of:-

You have to modify MN.
MN needs to support some trick
1. No NDP for active address (HoA), this is big change. MN has to  
ignore NS for its hoa, too.
2. No returning home even at the home.

> 3. Home network nodes get some peace and quiet... ;)

Why??

>> MN needs certain indication of home-CoA.

I cannot see youranswer in the above text.
How to distinguish HoA and Home-CoA?

regards,
ryuji

---

From: Chan-Wah Ng <[email-masked]>
Date: Fri, 27 Oct 2006 11:53:27 +0800

Hello Ryuji,

> This also requires to change HA and MN operation.

By default, MCoA support already changes the operations of HA and MN.

> from a home network prefix is HoA or home-CoA.

Ah, I see.  So it is your opinion that HA assumes an address is a HoA
when it contains the home prefix?  Is this a specified behaviour in any
standard tracks document? 

If this is not an RFC-specified operation, then I disagree with your
statement that HA's operation needs to be changed.

HA could determine if an address is a home address or not through
various other means.  (eg, HoA in 3G may be tied to the SIM, through a
configuration file, etc, etc).

IMHO, to avoid the recursive binding problem, the HA needs to look up
the current BCE to check if a BU specifies CoA is currently a HoA.  By
rejecting a CoA simply because the CoA is configured from a home prefix
is "sloppy" at best and wrong in certain situations.

Consider the following situation where HA takes cares of multiple home
links.  If HA rejects BU because CoA is configured from a home prefix,
then a MN from home-link-1 cannot roams to home-link-2.

> MN needs certain indication of home-CoA.

Why?  MN knows it own HoA.  MN knows its home prefix.  MN simply
configured another address from its home prefix.  The only indication it
needs is whether it wants to be simultaneously at home & foreign or
wants to return to home and forget abt the foreign link.  That is a
configuration problem.

/rgds
/cwng

---

From: Romain KUNTZ <[email-masked]>
Date: Fri, 27 Oct 2006 16:12:22 +0900

Hello,

I would support Ryuji's proposals because Keigo's one will bring many 
side-effects: specific operations for returning home are define not only 
in RFC3775, but also in RFC3963 (for mobile routers, about sending RAs, 
joining all router multicast address group and routing protocol 
messages), and maybe in other extensions to MIPv6. Also, the home-CoA 
autoconfiguration may become tricky if the MN's HoA is already built 
from autoconfiguration.

I think that by modifying the returning home behaviour, you have to 
redefine what is home and what is not. It would not bring more benefits 
than Ryuji's proposal (either having a separate foreign link connected 
to the home agent, or multiple prefixes advertised on the home link - 
one for the home link prefix, and another foreign one -), that are less 
complex on both the protocol and implementation sides.

Regards,
romain

RYUJI WAKIKAWA wrote:
>> caveat may be for CN or HA to know that this route via the home 
>> "foreign link" is via a 1-hop tunnel to aid in decision making 
>> (optimisation problem?).
>>
>> 2. MNs must know which is the correct home link to configure. Legacy 
>> MNs may select the home "foreign link" prefix to configure as its HoA 
>> which introduces a whole lot of other issues.
> 
> Well, HA can turn down the home link. I.e. setting up  a virtual home link.
> 
>> using the home link prefix advertised by the HA.  The MN then sends a 
>> BU to the HA a la RFC 3775 (either [Src Addr: HoA, Alt CoA Opt: 
>> HomeCoA] or [Src Addr: HomeCoA, Home Address Dst Opt: HoA]).  This 
>> method has the benefits of:-
> 1. No NDP for active address (HoA), this is big change. MN has to ignore 
> NS for its hoa, too.

-- 
Romain KUNTZ
[email-masked]

---

From: Benjamin Koh Tien-Ming <[email-masked]>
Date: Mon, 30 Oct 2006 13:42:31 +0800

Hi!

> Well, HA can turn down the home link. I.e. setting up  a virtual home link.

[BK]
By turning off the home link, ALL MNs will never be able to return home
i.e. even legacy MNs in the home network must communicate (when using
its HoA) via the HA-MN tunnel.

>> 3. HA spamming all kinds of RAs for home and foreign links sound kinda

[BK]
I was assuming for efficiency purposes that the HA maintains both the
'real' home prefix and the home 'foreign link' prefix.  In order to
differentiate between the two prefixs, I would assume some additional
information needs to be carried in the RA. These new options would also
need to be understood by MNs utilising the home 'foreign link' prefix
solution and disregarded by other MNs.

> 1. No NDP for active address (HoA), this is big change. MN has to ignore

[BK]
We are changing the MN and HA for MCoA support in any case...

> 2. No returning home even at the home.

[BK]
This would apply for all nodes if HA only advertises the home 'foreign
link' prefix as previously suggested.  If the MN chooses not to utilise
the 'away' interface and expires all its binding updates (as per MCoA
ID) it will be returned home at home. :)

>> 3. Home network nodes get some peace and quiet... ;)

[BK]
By the simple fact that if the HA does not advertise bloated RAs with
both home link and home foreign link prefixes and information, home
network nodes can do less processing of unnecessary information and
conserve some bandwidth as well. :)

> How to distinguish HoA and Home-CoA?

[BK]
Hmm... I'm having difficulting understanding your statement. Let's use
an example.

The HA advertises home prefix: HAP/64
MN creates and registers a HoA: HAP.MNHoA/128
MN creates a different IPv6 address using the home prefix and registers
it as the Home-CoA: HAP.HCoA/128

Are you saying that HAP.MNHoA = HAP.HCoA? (Which is not our intention.)

Regards,
Ben

---

From: Keigo Aso <[email-masked]>
Date: Mon, 30 Oct 2006 19:38:13 +0900

Hello Ryuji,

Thank you for your comments to our contribution.
Please see my comments inline.

> There is clear definition of HoA and CoA in 3775.
The definition of "The address which is obtained from the home prefix
must be always treated as a home address" could not be found in RFC3775.
Even if it was introduced for your implementation. RFC3775 does not say it. 
It should check the whole address for confirming if a address
is home address or not.

Let me show the scenario example for describing that your definition
is not always correct.

[Example]
There are two MN(MN1,MN2).
A network(NW1) is MN1's home network and HA1 is advertising HP1 as the home
prefix.
A network(NW2) is MN2's home network and HA2 is advertising HP2 as the home
prefix.
As far as I know,
If MN1 connects to NW2, it creates CoA1 as care-of address from HP2.
If MN2 connects to NW1, it creates CoA2 as care-of address from HP1.

This scenario shows that whether a prefix is a home prefix or a foreign prefix 
depends on the mobile node which uses it (as I said before).
If your definition is correct, MN1 can not create CoA1 from HP2
because CoA1 is a home address.

If HA2 advertises the other prefix in the home network according to your
proposal, is it used by MN1 in order to create care-of address in NW2 ? 
In that case, how does MN1 distinguish between HP2 and the other prefix ? 
I think it can not be solved by implementation. This is side-effects for 
the Regacy-MN(RFC3775) in protocol side.

If HA1 turns off the home prefix in order to avoid the above side-effects,
it causes another side-effects which is that all MN(Regacy-MN and MCoA-MN)
can never retrun home.

Hence I think advertising the other prefix is needless operation because 
allowing MN to create care-of address from home prefix is sufficient for
the scenario 3. 
Please not that this is not expanding home prefix definition, 
"This is just using a Prefix not only as a home prefix but also as 
a foreign prefix."

Following is for your concern from the viewpoint of the operation 
of MCoA-MN and HA.

When MCoA-MN connects to the home network and then decide to use both the 
interfaces attaching to the home network and the interface attaching to
the foreign network, it does not do NDP for HoA as you indicated in other 
your mail. But this occurs in your proposal also.

And MCoA-MN can select to return home or not. That's why our proposal is for
the scenario 3. The scenario 2(normal returning home) is still existing. 

Regards,
Keigo

---

From: RYUJI WAKIKAWA <[email-masked]>
Date: Tue, 31 Oct 2006 23:53:08 +0900

Hello Keigo

> because CoA1 is a home address.

This is wrong. NW2 is not home prefix of MN1...
NW2 is just a foreign link of MN1.

> proposal, is it used by MN1 in order to create care-of address in  

see above. MN1 can use CoA generated from HP2. Again HP2 is not home  
prefix for MN1.

> the Regacy-MN(RFC3775) in protocol side.

It's same as above.

> it causes another side-effects which is that all MN(Regacy-MN and  

HA1 does not need to stop home prefix. That scenario was an example.

> "This is just using a Prefix not only as a home prefix but also as

No, I think you confuse the definition of home prefix here.
A MN's home prefix is not all the prefixes advertised by any HA.
It is the prefixes advertised by "MN's HA".

> your mail. But this occurs in your proposal also.

Ok, so in both proposals, HoA is never assigned to the interface  
attached to the home link?

regards,
ryuji

>>>>> ------------------------------------------------------------------ 
>>>>> --
>>>>> --
>>>>>
>>>>>
>>>>> ---<<Section
>>>>> link
>>>>> packets
>>>>>> use
>>>>> ------------------------------------------------------------------ 
>>>>> --
>>>>> --
>>>>>
>>>>>
>>>>> ---<<Section
>>>>> ------------------------------------------------------------------ 
>>>>> --
>>>>> --
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>
>