Subject: [Monami6] Re: Scenario 3 of returning home in MCoA (was Re: Modified text for new MCoA draft)

From: Keigo Aso <[email-masked]>
Date: Wed, 01 Nov 2006 15:54:49 +0900

Hello Ryuji,

Thank you for your comments.
Please see my comments inline.

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

> Hello Keigo
> 
> On 2006/10/30, at 19:38, Keigo Aso wrote:
> 
> > Hello Ryuji,
> >
> > Thank you for your comments to our contribution.
> > Please see my comments inline.
> >
> >>>> 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.
> >>> 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."
> >>
> >> It is not the problem of your disagreement.
> >> 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.
> 
> This is wrong. NW2 is not home prefix of MN1...
> NW2 is just a foreign link of MN1.
> 
> > 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 ?
> 
> see above. MN1 can use CoA generated from HP2. Again HP2 is not home  
> prefix for MN1.
What I wanted to say here is "A prefix advertised in a home network
is _a prefix_ for creating IP address and whether the prefix is 
a home prefix or a foreign prefix depends on what the mobile node use it for".
If a MN2 use HP2 for creating home address, the address is home address,
if a MN1 use HP2 for creating care-of address, the address is care-of address.
Even if MN2 and MN1 is a same entity, it comes to the same thing.

For example, the care-of address MN1 creates from HP2 could become
MN1's new home address after HA2 is assigned as MN1's new home agent.
In your proposal case, if MN1 creates care-of address from the other prefix,
the address could not become MN1's new home address because the prefix is not
home preifx 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.
> 
> It's same as above.
In that case, the other preifx advertised by HA2 is needless for MN1 ?
unless the purpose of advertising the other prefix is "site-multihoming".

> 
> > 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.
> 
> HA1 does not need to stop home prefix. That scenario was an example.
OK. If HA1 turns off the home prefix, it causes above side-effects.

> 
> > 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."
> 
> 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".
Please see above.

> 
> 
> > 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.
> 
> Ok, so in both proposals, HoA is never assigned to the interface  
> attached to the home link?
Which is your proposal in this case ?
(1) HA advertises home and foreign prefixes or
(2) HA advertises only foreign prefix

In our proposal, it depends on the scenario.
MN can select from scenario 1, 2 and 3.
Actually draft-mcoa-00 already has scenario 1 and 2.
 - Scenario 1: when a mobile node wants to use only the interface attached to
the home link. 
 - Scenario 2: when a mobile node wants to use only the interfaces attached to
the foreign links,

Scenario1 is solved by normal returning home.
Sceanrio2 is solved by sending de-reg BU for the home attached interface.
So, in this scenario, HoA is not assigned to the interface.

These are still existing after our proposal is introduced.
Because it is for the scenario 3 which should be included
in section 3.3.
 - Scenario 3: when a mobile node wants to simultaneously use interfaces 
attached to both foreign and home links.

Regards,
Keigo

> 
> regards,
> ryuji
> 
> > 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
> >
> >>
> >> regards,
> >
> >> ryuji
> >>
> >>> Regards,
> >>> Keigo
> >>>
> >>>>
> >>>> 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
> >>>>
> >>>>
> >>>>>
> >>>>> ######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.
> >>>>>>
> >>>>>
> >>>>> ------------------------------------------------------------------ 
> >>>>> --
> >>>>> --
> >>>>>
> >>>>>
> >>>>>
> >>>>>
> >>>>>
> >>>>>
> >
> >

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