Subject: [MEXT] [mext] #11: De-registration when returning home [Vijay Devarapalli <[email-masked]>]

From: "mext" <[email-masked]>
Date: Tue, 08 Jul 2008 22:00:19 -0000

Ticket #11: De-registration when returning home  [Vijay Devarapalli
<[email-masked]>]

 RFC 3775 currently says the mobile node "SHOULD" send a de-registration
 BU when it returns home. This is kind of odd because, without the
 de-registration BU, the home agent continues defending the mobile node's
 home address and keeps tunneling the packets to the last known care-of
 address. The BCE must be deleted for the mobile node to be able to send/
 receive packets from the home link. I am not sure why we went with
 "SHOULD" in the first place.

 From the interop events I have attended, I know that all mobile node
 implementations send a de-registration BU as soon as they detect they
 are on the home link. The use of "SHOULD" instead of "MUST" caused some
 confusion during the PMIPv6-MIPv6 interactions discussion. So we need to
 fix this.

 Here is the proposed change.

 OLD:

     A mobile node detects that it has returned to its home link through
     the movement detection algorithm in use (Section 11.5.1), 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.

 NEW:

     A mobile node detects that it has returned to its home link through
     the movement detection algorithm in use (Section 11.5.1), when the
     mobile node detects that its home subnet prefix is again on-link.
     The mobile node MUST then send a Binding Update to its home agent,
     to instruct its home agent to no longer intercept or tunnel packets
     for it.

 ---------------------------------------------------------------------

 Gerardo Giaretta <[email-masked]>

 This was discussed also in Philadelphia and in general I agree a
 MUST is more appropriate.

 However we should make clear that the MN MUST send the deregistration
 BU only when it wants the HA to stop intercepting packets and
 forwarding them to the CoA.

 Let's assume for example the MN has two active interfaces, it is using
 interface with CoA1 registered at the HA. Then it switches interface2
 on and detects interfaces2 is connected to the home link. This should
 not immediately trigger the MN to send the BU, unless the MN wants all
 traffic destined to the HoA routed to interface2 (the MN may still
 want to have the traffic destined to interface1).

 ---------------------------------------------------------------------

 Sri Gundavelli <[email-masked]>

 We discussed this issue in the last meeting and I thought
 the conclusion there was, if the mobile node attaches to
 the home link and *if* it decides to use the home address
 i.e., defend the home address on the home link, then it
 MUST send a dereg BU. This will avoid the Proxy ND contention.
 Note that it is possible the MN is attached to the home,
 but may choose to send the dereg bit later. So, the wording
 has to reflect this aspect.

 ---------------------------------------------------------------------

 Ahmad Muhanna  <[email-masked]>

 IMO, the best for RFC3775 and RFC3775bis is to maintain "SHOULD" because
 my understanding of "SHOULD" is that the MN MUST send de-registration
 UNLESS there is a condition that makes it impossible on the MN to send
 de-registration, e.g. MN lost coverage, or lost power, etc.

 The usefulness of SHOULD in base RFC3775 that it can be become "MUST"
 in a specific scenario where that is possibly described in a different
 doc, like the case that Gerardo mentioned. IMO, that "MUST" should be
 captured in the Multi-CoA doc not in RFC3775bis.

 On the other hand, the latest change defeats the original purpose of
 RFC3775, because RFC3775 mandates on the MN to send de-registration,
 however, the last change, proposed here, makes it based on the MN
 discretion and that is very dangerous.

 I disagree with this change and I favor maintaining "SHOULD" in
 the base document and if "MUST" is needed in a specific scenarios
 let us capture that in the respected document.

 ---------------------------------------------------------------------

 George Tsirtsis  <[email-masked]>

 ... it does not make sense to require
 that the MN sends a dereg BU when it connects to its home link.
 Instead this is a MIPv6 layer decision that has nothing to do with
 whether the MN has connection only to the home link or to one or more
 other links at the same time.

 ---------------------------------------------------------------------

 Sri Gundavelli <[email-masked]>

 ...I'm ok leaving the initial SHOULD
 wording, however, the technical issue that I see and as I
 said before is that we should clearly document and state
 that the MN MUST send a dereg message before it can start
 using its hoa on the home link and that will avoid any ND
 contentions between the HA and the MN. This is not implicit
 and cannot be left to the reader and so must be documented.

 Generally, it can be stated the MN must send a dereg. But,
 the issue related to power down ...etc. ..etc are probably
 valid and there may be valid reasons as why MN may not be
 able to send a dereg message. So, we can always qualify
 that requirement and state that the MN must send a dereg
 before it can start using its home address on the home link
 and also leave the option for it not to send any dereg
 message in some situations and when it has no need to use
 its HoA.

 Bottom line:

 - Leave the SHOULD as a strong recommendation for the MN
 to send dereg, as it is currently written.

 - Add additional text and state the MN MUST send a dereg
 before it can use its hoa on the home link.

 ---------------------------------------------------------------------

 George Tsirtsis  <[email-masked]>

 Sri/Ben, IMHO combining SHOULDs/MAYs and MUSTs with "if" statements
 does not result in good specs. For example, the MUST in Ben's proposal
 is to be followed only if the MN *intends* to  get its traffic to flow
 on the home link and, not following the MUST does not really break the
 protocol. In any case, *intentions* are not easy to evaluate during
 interoperability testing.  So, maybe we should simply try to clarify
 the SHOULD. Here is a proposal:

 OLD Text:

    A mobile node detects that it has returned to its home link through
    the movement detection algorithm in use (Section 11.5.1), 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.

 NEW Text:

    A mobile node detects that it has returned to its home link through
    the movement detection algorithm in use (Section 11.5.1), 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. Until the mobile node sends a de-registration Binding Update,
    it will not be able to send and receive packets using its home
    address from the home link. The home agent will continue to intercept
    all packets sent to the mobile's home address and tunnel to the
    previously registered care-of address.

----------------------------------------+-----------------------------------
 Reporter:  [email-masked]       |       Owner:  [email-masked]
     Type:  defect                      |      Status:  new                  
 Priority:  minor                       |   Milestone:                       
Component:  draft-ietf-mext-rfc3775bis  |     Version:                       
 Severity:  Active WG Document          |    Keywords:                       
----------------------------------------+-----------------------------------
-- 
Ticket URL: <http://www3.tools.ietf.org/wg/mext/trac/ticket/11>
mext <http://tools.ietf.org/wg/mext/>
_______________________________________________
MEXT mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/mext

---

From: "Charles E. Perkins" <[email-masked]>
Date: Tue, 08 Jul 2008 15:12:21 -0700

Hello folks,

As noted, I have posted issue #11 to the [mext] issue tracker.

There were well over 50 messages on this topic, and I plowed
through every single one of them.  I tried to extract the major
thoughts and collect them for the issue background, but if I
managed to miss something please let me know.

I'm satisfied that the proposal as shown after the other
discussion in the issue description is a reasonable consensus
resolution for the issue, but I'll wait to see if there is
any dissent first.

Regards,
Charlie P.

---

From: "Vijay Devarapalli" <[email-masked]>
Date: Tue, 8 Jul 2008 21:04:25 -0400

Hi Charlie,

I am going to try addressing this issue once more. First lets look at
the requirements.

1. Allow a mobile node with one home address and one care-of address to
be able to send/receive packets when it attaches to the home link

2. Allow a mobile node with one home address and multiple care-of
addresses to decide whether it wants to send/receive packets from the
home or the visited link.

IMO, RFC 3775 addresses the first case. The second one is addressed by
the multiple CoA draft. The multiple CoA draft infact describes the
mobile node and the home agent behavior for three cases when the mobile
node is simultaneously attached to the home and visited links. See
section 5.6 of draft-ietf-monami6-multiplecoa-08.txt. It allows the
mobile node to use the home link, the visited link or both and indicate
the same to the home agent.

So here is my proposal for the text.

OLD:

NEW:

   A mobile node detects that it has returned to its home link through
   the movement detection algorithm in use (Section 11.5.1), when the
   mobile node detects that its home subnet prefix is again on-link.
   In case the mobile node has only one care-of address associated with
   the home address, it MUST send a Binding Update to its home agent,
   to instruct its home agent to no longer intercept or tunnel packets
   for it.  In case the mobile node has more than one interface and
   can bind more than one care-of address to the home address, the 
   mobile MAY send a Binding Update to its home agent, to instruct its 
   home agent to no longer intercept or tunnel packets for it. For more
   information on the mobile node returning home procedure when there 
   are multiple care-of addresses, see [MCOA].

In the Informative references add,

   [MCOA] Wakikawa, S., Devarapalli, V., Ernst, T., and K. Nagami, 
          "Multiple Care-of Addresses Registration", Work in 
          Progress, May 2008.
   
Hope this acceptable to all.

Vijay

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On 
> Behalf Of Charles E. Perkins
> Sent: Tuesday, July 08, 2008 3:12 PM
> To: [email-masked]
> Subject: Re: [MEXT] [mext] #11: De-registration when 
> returning home [Vijay Devarapalli <[email-masked]>]
> 
> 
> Hello folks,
>

---

From: "Benjamin Lim" <[email-masked]>
Date: Wed, 9 Jul 2008 10:27:40 +0800

Hi Vijay, 

One comment on the new proposed text.

>    to instruct its home agent to no longer intercept or tunnel packets
[Ben] This part I agree. When the MN returns home, MN must send a BU to HA
to remove its CoA entry from the HA.

> In case the mobile node has more than one interface and
>    home agent to no longer intercept or tunnel packets for 
> it. 
[Ben] IMHO, this should also be a MUST. Base on the same logic as above.
This is irrespective to whether MN is trying to achieve simultaneous home
and away or not.  Regardless on whether if MN has one CoA or multiple CoAs,
when MN returns home, it would need to remove its associated CoA entry from
the HA.  Hence, I do not see a reason why for one CoA MN MUST send BU, but
for multiple CoAs MN MAY send BU.

Regards,
Benjamin Lim

> For more

---

From: Vijay Devarapalli <[email-masked]>
Date: Tue, 08 Jul 2008 22:53:58 -0700

> for multiple CoAs MN MAY send BU.

The second part is intended to support the case where the MN may want to
continue using the interface with which it is attached to the visited link.
The binding stays active, while the MN is attaching to the home link with
one of the interfaces. It may decide at a later time if wants to use only
the interface with which it is attached to the home link.

Any suggestions to improve the text to indicate the above is welcome.

Vijay

---

From: "Vijay Devarapalli" <[email-masked]>
Date: Wed, 9 Jul 2008 02:54:02 -0400

One more thing...

> for multiple CoAs MN MAY send BU.

You also have to address the case where the mobile node might not have
had a CoA on the interface with which it attached to the home link. Even
if it had an address confitured on that interface, it might have not
bound the address to the home address either.

Vijay

---

From: "Giaretta, Gerardo" <[email-masked]>
Date: Wed, 9 Jul 2008 11:03:01 -0700

Hi Vijay,

What do you mean by: "the MN can bind more than one care-of address to
the home address"? Is it about MCoAs? If it is so, I think this is not
correct. The MN can still be dual-radio, connect to the home link with
if1 but keep the CoA of if2 in the binding. Obviously this implies that
the if1 cannot be used with the HoA (as the HA is still defending the
HoA), but the MN will send the dereg BU as soon as it wants to traffic
to be redirected to if1. 

What is wrong with the following text which was proposed to the list
some time ago?

    for it. Until the mobile node sends a de-registration Binding
Update,
    address from the home link. The home agent will continue to
intercept

Gerardo

> From: [email-masked] [mailto:[email-masked]] On Behalf
Of
> Vijay Devarapalli
> Sent: Tuesday, July 08, 2008 10:54 PM
> To: Benjamin Lim
> Cc: [email-masked]; [email-masked]
> Subject: Re: [MEXT] [mext] #11: De-registration when returning home
> [VijayDevarapalli <[email-masked]>]
> 
> > and away or not.  Regardless on whether if MN has one CoA or
multiple
> CoAs,
> > when MN returns home, it would need to remove its associated CoA
entry
> from
> > the HA.  Hence, I do not see a reason why for one CoA MN MUST send
BU,
> but

---

From: "Vijay Devarapalli" <[email-masked]>
Date: Wed, 9 Jul 2008 14:11:50 -0400

Hi Gerardo,

> correct. 

I clarified later on in an email to Benjamin. It does not have to be
about multiple care-of address registration. 

> The MN can still be dual-radio, connect to the home link with

I agree with this. 

> What is wrong with the following text which was proposed to the list

The text does not resolve the issue. It just describes what happens if
the mobile node does not send a de-registration BU. IMO, that is not
sufficient.

Consider a mobile node with a single interface or a mobile node that is
only capable of "single-radio" handover. This mobile node MUST send a
de-registration BU as soon as it attaches to the home link. It does not
have an option to delay sending the de-registration BU.

I am trying to separate out the two and have two separate sentences.

How about the following?

   A mobile node detects that it has returned to its home link through
   the movement detection algorithm in use (Section 11.5.1), when the
   mobile node detects that its home subnet prefix is again on-link.
   In case the mobile node has only one interface active at any time, 
   it MUST send a Binding Update to its home agent, to instruct its home

   agent to no longer intercept or tunnel packets for it.  In case the 
   mobile node has more than one interface active at a time, it MAY 
   send a Binding Update to its home agent, to instruct its home agent 
   to no longer intercept or tunnel packets for it. For more information

   on the mobile node returning home procedure when there are multiple 
   care-of addresses, see [MCOA].

Vijay

> > > This is irrespective to whether MN is trying to achieve 
> simultaneous
> > home
> > The second part is intended to support the case where the 
> MN may want
> to
> > continue using the interface with which it is attached to 
> the visited
> link.

---

From: "Giaretta, Gerardo" <[email-masked]>
Date: Wed, 9 Jul 2008 11:18:23 -0700

This sounds better to me. I'd like still to clarify what happens when
the UE does not send the BU. What about this:

   A mobile node detects that it has returned to its home link through
   the movement detection algorithm in use (Section 11.5.1), when the
   mobile node detects that its home subnet prefix is again on-link.
   In case the mobile node has only one interface active at any time, 
   it MUST send a Binding Update to its home agent, to instruct its home
   agent to no longer intercept or tunnel packets for it.  In case the 
   mobile node has more than one interface active at a time, it MAY 
   send a Binding Update to its home agent, to instruct its home agent 
   to no longer intercept or tunnel packets for it. Until the mobile
node    
   sends a de-registration Binding Update, it will not be able to send
and 
   receive packets using its home address from the home link. The home
agent 
   will continue to intercept all packets sent to the mobile's home
address 
   and tunnel to the previously registered care-of address.

Gerardo

> From: Vijay Devarapalli [mailto:[email-masked]]
> Sent: Wednesday, July 09, 2008 11:12 AM
> To: Giaretta, Gerardo; Benjamin Lim
> Subject: RE: [MEXT] [mext] #11: De-registration when returning home
Behalf
> > > On 7/8/08 7:27 PM, "Benjamin Lim"
<[email-masked]>
> > wrote:
> > > > [Ben] IMHO, this should also be a MUST. Base on the same logic
as
> > above.
> > > The binding stays active, while the MN is attaching to the home
link
> > with
> > > one of the interfaces. It may decide at a later time if wants to
use
> > only

---

From: "Vijay Devarapalli" <[email-masked]>
Date: Wed, 9 Jul 2008 14:25:04 -0400

Fine with me.

Vijay 

> From: Giaretta, Gerardo [mailto:[email-masked]] 
> Sent: Wednesday, July 09, 2008 11:18 AM
> To: Vijay Devarapalli; Benjamin Lim
> Subject: RE: [MEXT] [mext] #11: De-registration when 
> returning home [VijayDevarapalli <[email-masked]>]
> 
> > > What do you mean by: "the MN can bind more than one 
> care-of address
> to
> > > > >>    information on the mobile node returning home 
> procedure when
> > > there

---

From: Sri Gundavelli <[email-masked]>
Date: Wed, 9 Jul 2008 11:26:09 -0700 (PDT)

Just one comment.

> Until the mobile node sends a de-registration Binding Update, it will 
> not 
> be able to send and receive packets using its home address from the home 
> link.

I have a problem with this. As Pascal and Rajiv pointed out, nothing
really stops the MN, which is the legitimate address owner to reclaim
and start using its home address on the home link and without sending
a BU with life=0. This has to confirm to the override flag purpose in
ND.

Sri

---

From: "Vijay Devarapalli" <[email-masked]>
Date: Wed, 9 Jul 2008 14:32:20 -0400

Hi Sri,

We need to have a discussion on whether a neighbor advertisement with
the override flag set can convince the home agent to remove the proxy
neighbor cache entry for the home address. The proxy neighbor cache
entry was created as a result for processing a binding update. I think
only another binding update should remove it. But that is a separate
discussion.

Perhaps, a minor fix will satisfy you. How about the following?

   A mobile node detects that it has returned to its home link through
   the movement detection algorithm in use (Section 11.5.1), when the
   mobile node detects that its home subnet prefix is again on-link.
   In case the mobile node has only one interface active at any time, 
   it MUST send a Binding Update to its home agent, to instruct its home
   agent to no longer intercept or tunnel packets for it.  In case the 
   mobile node has more than one interface active at a time, it MAY 
   send a Binding Update to its home agent, to instruct its home agent 
   to no longer intercept or tunnel packets for it. Until the mobile
   node sends a de-registration Binding Update, it may not be able to 
   send and receive packets using its home address from the home link. 
   The home agent will continue to intercept all packets sent to the 
   mobile node's home address, as long as the home agent is proxying 
   for the home address.

Two modifications. Replaced "..it will not be able to.." with "..it may
not be able to.." and re-wrote the last sentence.

Vijay

> From: Sri Gundavelli [mailto:[email-masked]] 
> Sent: Wednesday, July 09, 2008 11:26 AM
> To: Giaretta, Gerardo
> Cc: Vijay Devarapalli; Benjamin Lim; [email-masked]; 
> [email-masked]

---

From: "Giaretta, Gerardo" <[email-masked]>
Date: Wed, 9 Jul 2008 11:54:24 -0700

This is also fine with me. 

I also agree with Vijay that only another binding update should remove
the state at the HA about intercepting packets. But this may be another
issue

For me we can close this issue

Thanks
Gerardo

> Sent: Wednesday, July 09, 2008 11:32 AM
> To: Sri Gundavelli; Giaretta, Gerardo
> Cc: Benjamin Lim; [email-masked]; [email-masked]

---

From: Sri Gundavelli <[email-masked]>
Date: Wed, 9 Jul 2008 12:11:47 -0700 (PDT)

> only another binding update should remove it. But that is a separate

I generally agree to the point that a state that was created by a BU,
should be again removed using the same BU. I agree in principle. But,
if the HA cannot defend the address any more, the BU should be removed.
If ND is allowing the MN to reclaim the address, the state that is
left on the HA is an inconsistent state and it needs to be cleaned up.
Yes, this requires more discussion.

Below text seems ok to me, except the new concept of multiple interface
MN in the context of 3775. I'd simply state, "if the MN wants to use
the HoA on the home link, it MUST send a dereg" ...., from the
MIP perspective we can require that. From HA perspective in the context
of ND, what HA should do if the address is taken over, we need to
discuss further, as say above.

Sri

---

From: "Giaretta, Gerardo" <[email-masked]>
Date: Thu, 10 Jul 2008 11:45:56 -0700

I would add the following sentence for the sake of clarity at the end of
your text:

    Until the mobile node sends a de-registration Binding Update,

Note that this text does not contain any normative text, just clarifies
what happens.

Gerardo

> Sent: Thursday, July 10, 2008 11:42 AM
> To: Sri Gundavelli
> Cc: Giaretta, Gerardo; Benjamin Lim; [email-masked];
[email-masked]
> Is this what you are looking for?
> 
>    To be able to send and receive packets using its home address from
>    the home link, the mobile node MUST send a Binding Update to its
>    home agent to instruct its home agent to no longer intercept or
>    tunnel packets for it.
> 
> I am fine with this as well, since it avoids talking about multiple
> interfaces. Gerardo?
> 
> Vijay

---

From: Sri Gundavelli <[email-masked]>
Date: Thu, 10 Jul 2008 11:49:49 -0700 (PDT)

I'm  Ok with this text.

Sri

---

From: Sri Gundavelli <[email-masked]>
Date: Thu, 10 Jul 2008 11:53:44 -0700 (PDT)

Hi Gerardo,

> Note that this text does not contain any normative text, just clarifies

But, nothing stops the mobile node from reclaiming that address and
start using it. HA cannot stop it. From MIP perspective, we can
madate the DeReg and if it does not do that, its a violation, but, we
cannot say MN wont be able to use that address without sending a dereg,
that modifies 4861.

Also, we need to discuss what the HA should do, if the mobile reclaims
its address, but does not send a dereg.

Sri

---

From: "Charles E. Perkins" <[email-masked]>
Date: Thu, 10 Jul 2008 11:55:44 -0700

Hello Vijay,

Looks good to me!

Regards,
Charlie P.

Vijay Devarapalli wrote:
> Fine with me. So the new text is
> 
>    tunnel packets for it. Until the mobile node sends a de-registration 
>    Binding Update, it will not be able to send and receive packets 
>    using its home address from the home link. The home agent will 
>    continue to intercept all packets sent to the mobile's home address 
> Is everyone ok with this?
> 
> Vijay
> 
> 
>> Sent: Thursday, July 10, 2008 11:46 AM
>> To: Vijay Devarapalli; Sri Gundavelli

---

From: Sri Gundavelli <[email-masked]>
Date: Thu, 10 Jul 2008 12:04:46 -0700 (PDT)

On Thu, 10 Jul 2008, Vijay Devarapalli wrote:

>> start using it. HA cannot stop it.
>

Sorry, do not mean to beat this thread to death ...

So, who gets the packets, if HA does not stop proxying and MN
starts defending its address ?

Sri

---

From: Sri Gundavelli <[email-masked]>
Date: Thu, 10 Jul 2008 12:18:47 -0700 (PDT)

Hi Vijay,

On Thu, 10 Jul 2008, Vijay Devarapalli wrote:

> This shouldn't happen. According to RFC 3775, a Mobile IPv6 mobile node
> should not claim the address (send a neighbor advertisement for it),
> until it gets a Binding Ack from the home agent in response to its
> de-registration Binding Update. This is clearly specified in RFC 3775.
>

There are three things here:

1.) MIP requirement of what the MN should do when is back home

- which is send a dereg before it uses its hoA.
I'm fine with this, lets mandate that and ok with this.

2.) Second part: can the MN use its HoA with out sending the BU.

- This may be a MIP violation
- But, a MN can very well do so and nothing can stop it, its
   the legitimate owner, who owns that address and I'm not
   even talking about SEND assertion on that address.

3.) What the HA should do in such error case, to be discussed.

I'm saying,  #2 and #3 needs discussion. Lets simply state
the requirement from MIP persective on "returning home". Now
the error case, lets discuss further. I think, MN will be able
to use its HoA with out sending a dereg. If you can stick to you
original text, that will be fine, assuming Gerardo is ok with it.

Thanks
Sri

---

From: "Charles E. Perkins" <[email-masked]>
Date: Thu, 10 Jul 2008 13:17:36 -0700

Hello Sri,

>   even talking about SEND assertion on that address.

A "disobedient" mobile node can do a lot of things to
screw up the protocol.  It would take a long (err... I
mean, "a lot longer") document to include all cases.

> 3.) What the HA should do in such error case, to be discussed.

It is not clear to me that this has to be discussed,
especially in the absence of any evidence that there
exists a problem that needs to be solved.  So, I would
somehow expect that discussion on this point should not
impede consensus on the rest of the issue.

However, if there is a simple way to reword the text
to take your concerns into account without losing the
consensus, I'd be happy to go along.

Regards,
Charlie P.

---

From: Sri Gundavelli <[email-masked]>
Date: Thu, 10 Jul 2008 13:48:33 -0700 (PDT)

Hi Charlie,

> impede consensus on the rest of the issue.

There were some discussions on this error case and the text where it
might require some minor corrections. But, ignoring this error
scenario, I'm ok with the text proposed by Vijay earlier today. Its
better if we dont speculate on if the MN will be able to use its home
address without sending the BU or not. That is a general ND issue and
offcourse has some bearing on the HA, for that error case.

The key point of this issue on MN's operation on the home-link, we can
just state that the "MN MUST send a dereg if its intends to use its HoA
on the home-link" and leave it there. That should close this specific
issue and without loosing the consensus.

Regards
Sri

---

From: "Giaretta, Gerardo" <[email-masked]>
Date: Thu, 10 Jul 2008 14:03:00 -0700

Sri,

This MN would violate RFC3775. A dereg BU must be sent and a BA received
before claiming the address. Therefore I am not sure we should document
this in RFC3775bis

Gerardo

> Sent: Thursday, July 10, 2008 12:05 PM
> To: Vijay Devarapalli
[email-masked]

---

From: Sri Gundavelli <[email-masked]>
Date: Thu, 10 Jul 2008 14:37:39 -0700 (PDT)

Hi Gerardo,

I agree its a violation of 3775. But, it is incorrect to state that
the mobile node will not be able to reclaim the address without the
consent from the home agent, when there is clearly no support from ND
for controlling that aspect. Its my home home address and in the
presence of SEND and in all other cases, I can assert ownership on
that address and the link model will allow me to use that address. The
requirement that HA should approve the MN to take over its address on
the home link and if it does not recv a BA, it cannot reclaim the
address is debatable.

Sri

---

From: "Giaretta, Gerardo" <[email-masked]>
Date: Thu, 10 Jul 2008 15:45:45 -0700

Hi Sri,

I'm trying to address the issue less philosophically :-)

The MN will be a MIPv6 MN and knows that to claim the address it will
need to send a deregistration BU and a NA instead of only sending a NA.
This should be part of the MIPv6 stack in the MN. 

Does it make sense?

Gerardo

> Sent: Thursday, July 10, 2008 2:38 PM
> To: Giaretta, Gerardo
[email-masked]

---

From: "Vijay Devarapalli" <[email-masked]>
Date: Thu, 10 Jul 2008 14:41:37 -0400

Hi Sri,

Vijay

---

From: "Vijay Devarapalli" <[email-masked]>
Date: Thu, 10 Jul 2008 14:53:28 -0400

Vijay

---

From: "Vijay Devarapalli" <[email-masked]>
Date: Thu, 10 Jul 2008 14:58:33 -0400

> start using it. HA cannot stop it. 

The HA does not stop proxying for the home address, until the
de-registration happens. So according the current procedure in RFC3775,
the mobile node MUST send a de-registration BU before it can start using
the home address.

> From MIP perspective, we can

This is not allowed today.

Vijay

---

From: "Vijay Devarapalli" <[email-masked]>
Date: Thu, 10 Jul 2008 15:07:53 -0400

Vijay

---

From: Sri Gundavelli <[email-masked]>
Date: Thu, 10 Jul 2008 16:01:23 -0700 (PDT)

Gerardo,

I'm ok with the text proposed by Vijay. We require the mobile
to send a dereg message to the HA, if it intends to use its
HoA on its home link, lets leave it there and not add that
additional text related to the error case. Lets leave that
additional text, as it is not correct.

Sri

---

From: "Benjamin Lim" <[email-masked]>
Date: Fri, 11 Jul 2008 09:45:32 +0800

Hi,

No objection from me on the below text.

Regards,
Benjamin Lim 

> Sent: Friday, July 11, 2008 2:53 AM
> To: Giaretta, Gerardo; Sri Gundavelli
> > I would add the following sentence for the sake of clarity 
> at the end 
> > of your text:
> > 
> > Note that this text does not contain any normative text, just 
> > clarifies what happens.
> > 
> > Gerardo
> > 
> > > > Below text seems ok to me, except the new concept of multiple 
> > > > interface MN in the context of 3775. I'd simply state, 
> "if the MN
> > wants to use
> > > > the HoA on the home link, it MUST send a dereg" ...., 
> from the MIP 
> > > > perspective we can require that. From HA perspective in the 
> > > > context of ND, what HA should do if the address is 
> taken over, we 
> > > > need to discuss further, as say above.
> > >

---

From: "Pascal Thubert (pthubert)" <[email-masked]>
Date: Fri, 11 Jul 2008 18:40:20 +0200

Hi Sri, 

I won't reply to all your mails but I'm 100 % with you all the way
through. 

In particular, you're very right that it would just be nonsense for a HA
to try and reclaim SeND based addresses when a MN proves ownership on
link. We need to prepare for the coming changes and adapt the spec. In
short the HA is a proxy and it should behave as such.

RFC3775bis might live in its bubble and expect that all MN will act
proper. But there are a number of scenarios, including reboot with loss
of state, where the MN might not. And the real attacks against the MN
home address might not come from nodes that behave proper, whether
that's voluntary or not.

When the MN comes back home and does not have the right states to
unbind, 

- if the MN is a good citizen, it should DAD its address and the HA
should defend it. I'm asking that upon DAD, the HA do not set the
Override bit; that change to the spec would allow the MN to
differentiate a real collision from a proxy collision. I would call that
a proxy-success for the DAD flow.

- but to avoid trouble when coming home, I'd expect that implementations
that do not wish to get angry customer calls in the middle of the night
would send RA (Override) right away. I know, that's bad. But that's damn
quick and efficent. That's how we do hot standby...

What happens next?

- A node should get its address back if only proxies are defending it. 
In MIP case, whether the MN can clean up the binding properly or fails
for some reason, it should NA(override) its address. At least that
should be rightful if DAD proxy-succeeds. 

- Upon NA override, a proxy should yield silently. 
The HA should remove its binding. This flow would also enables a HA that
gets a new BU to take over the binding from the old HA. 

Proxy or not proxy? That is the question...

Pascal

>From: [email-masked] [mailto:[email-masked]] On Behalf Of
Sri Gundavelli (sgundave)
>Sent: mercredi 9 juillet 2008 20:26
>To: Giaretta, Gerardo
[VijayDevarapalli

---

From: "Vijay Devarapalli" <[email-masked]>
Date: Fri, 11 Jul 2008 13:52:25 -0400

Sri, Pascal, Rajeev,

I suggest you guys open a separate issue on whether a mobile node can
claim its address without first sending a de-registration BU when it
returns to the home link.

RFC 3775 does not allow this. It is clearly a violation of RFC 3775. An
RFC 3775-compliant mobile node is supposed to behave as described in RFC
3775 when it returns home. Not according to what RFC 4861 might allow an
IPv6 host to do.

For the issue we were discussing, lets go with the following text.

We need to close this issue.

Based on what we decide later on whether the mobile node can claim its
address without first sending a de-registration BU, we can revisit the
above text. 

Vijay

> Behalf Of Pascal Thubert (pthubert)
> Sent: Friday, July 11, 2008 9:40 AM
> To: Sri Gundavelli (sgundave)
> returning home[VijayDevarapalli <[email-masked]>]
> 
> Hi Sri, 
>

---

From: "Sri Gundavelli (sgundave)" <[email-masked]>
Date: Fri, 11 Jul 2008 10:57:21 -0700

Vijay,
 
But the below text makes the assumption that the MN will not be able to reclaim the address and that
has the implication on the new issue to be discussed. The root of this issue, was the change from
SHOULD to MUST on requiring the MN to send a BU. Lets resolve the issue with clearly stating the
requirement from MIP perspective, "if the MN wants to use HoA on the home-link, it MUST send the
dereg message". The other text implying that the MN will not able to use the HoA on its home link is
not required and this issue is not about that.
 
Thanks
Sri

________________________________

From: Vijay Devarapalli [mailto:[email-masked]]
Sent: Fri 7/11/2008 10:52 AM
To: Pascal Thubert (pthubert); Sri Gundavelli (sgundave); Koodli, Rajeev
Cc: [email-masked]; [email-masked]
Subject: RE: [MEXT] [mext] #11: De-registration when returning home[VijayDevarapalli <[email-masked]>]

Sri, Pascal, Rajeev,

Vijay

---

From: "Vijay Devarapalli" <[email-masked]>
Date: Fri, 11 Jul 2008 14:07:57 -0400

Hi Sri,

> SHOULD to MUST on requiring the MN to send a BU. 

The change from 'SHOULD' to 'MUST' is irrelevant. RFC 3775 already says
that the mobile node sends a neighbor advertisement *only after*
receiving the Binding Ack from the home agent. Whether we use 'SHOULD'
or 'MUST' for the de-registration BU, the fact is that the mobile node
still cannot send a neighbor advertisement before receiving the binding
ack.

Vijay

Lets resolve 
> the issue with clearly stating the
> > >> be able to send and receive packets using its home 
> address from the
> > home
> > >> link.
> > >

---

From: "Sri Gundavelli (sgundave)" <[email-masked]>
Date: Fri, 11 Jul 2008 11:08:54 -0700

HI Vijay,
 
How are the two issues different then ? This issue and the new issue that you suggested we open.
 
Sri

From: Vijay Devarapalli [mailto:[email-masked]]
Sent: Fri 7/11/2008 11:07 AM
To: Sri Gundavelli (sgundave); Pascal Thubert (pthubert); Koodli, Rajeev
Cc: [email-masked]; [email-masked]
Subject: RE: RE: [MEXT] [mext] #11: De-registration when returning home[VijayDevarapalli <[email-masked]>]

Hi Sri,

Vijay

Lets resolve

---

From: "Kilian Weniger" <[email-masked]>
Date: Mon, 14 Jul 2008 10:20:48 +0200

Hi Vijay,

I'm ok with this text proposal. 

Kilian

> Behalf Of Vijay Devarapalli
> Sent: Donnerstag, 10. Juli 2008 20:53
> > clarifies
> > > > interface

Panasonic R&D Center Germany GmbH
63225 Langen, Hessen, Germany
Reg: AG Offenbach (Hessen) HRB 33974
Managing Director: Thomas Micke

---

From: "Pascal Thubert (pthubert)" <[email-masked]>
Date: Wed, 16 Jul 2008 13:51:26 +0200

Hello Vijay

I'm with Sri and Rajeev (and against Gerardo (sorry Gerardo :-) ) ) on
the fact that we do not need to add text that might be misleading in
what the node can or can not do at home with its home address until it
is done with the deregistration BU. What does '"if the MN wants to use
HoA " mean anyway?

It might be somewhat unlawful and it might partially work anyway for the
MN to start using the Home Addressright away. In particular, the MN
could apply oDAD without hurting anyone. 

So I'd rather remove speculations and stick to normative:

Starting with your original text

   tunnel packets for it.

I'd change this part slightly:

   tunnel packets for it.

Like this:

   The mobile node MUST send a Binding Update to its home agent to
instruct 

   it to no longer intercept or tunnel packets for it. Until then the MN

   SHOULD NOT advertize its Home Address on the Home Link.

Does not mean I agree that this is the right this to do; I still think
the MN should be able to force the ownership back.

But I agree that this can be processed as another issue.

Pascal

From: Sri Gundavelli (sgundave) 
Sent: vendredi 11 juillet 2008 19:57
To: Vijay Devarapalli; Pascal Thubert (pthubert); Koodli, Rajeev
Cc: [email-masked]; [email-masked]
Subject: RE: RE: [MEXT] [mext] #11: De-registration when returning
home[VijayDevarapalli <[email-masked]>]

Vijay,

But the below text makes the assumption that the MN will not be able to
reclaim the address and that

has the implication on the new issue to be discussed. The root of this
issue, was the change from

SHOULD to MUST on requiring the MN to send a BU. Lets resolve the issue
with clearly stating the

requirement from MIP perspective, "if the MN wants to use HoA on the
home-link, it MUST send the

dereg message". The other text implying that the MN will not able to use
the HoA on its home link is

Thanks

Sri

From: Vijay Devarapalli [mailto:[email-masked]]
Sent: Fri 7/11/2008 10:52 AM
To: Pascal Thubert (pthubert); Sri Gundavelli (sgundave); Koodli, Rajeev
Cc: [email-masked]; [email-masked]
Subject: RE: [MEXT] [mext] #11: De-registration when returning
home[VijayDevarapalli <[email-masked]>]

Sri, Pascal, Rajeev,

Vijay

---

From: "Pascal Thubert (pthubert)" <[email-masked]>
Date: Wed, 16 Jul 2008 14:37:12 +0200

Charlie and Vijay:

Following Vijay's advice, I'd wish to open a new issue on the behaviour
of the HA on the Home Link.

Issue
-----
With both the original RFC 3775 and the current rework, a HA that has a
binding to a Home Address owns that Home Adddress over the Home Link
till either the node unbinds or the binding times out. Until then the HA
will defend that Home Address using the Override bit in the NA messages
over the Home Link, and until then it is unlawful for the node to use
its Home Address if it is at Home or switch to another HA if it is not
at Home.

There are multiple issues with this behaviour:

- service: Whether it is at Home or not, a node that looses the states
about its current binding might be unreachable until the end of its
binding lifetime. It will take a manual operation to recover from that
situation when the lifetime is too long. And it will cause excess
traffic or load on the HAs if the lifetime is too short. In any case
there will be a service disruption that the user might perceive.

- security: The HA defends an address that it does not own so it can not
prove it owns it. With SeND, it would just be nonsense for a HA to try
and reclaim SeND based addresses when a MN proves ownership on link.

- compatibility with other proxies: The HA performs a form of ND
proxying for the Mobile Node. We can expect that there will be new forms
of ND proxies coming up - see for instance
http://tools.ietf.org/html/draft-thubert-6lowpan-backbone-router-01 -,
and there should be a common behaviour over a shared link for proxies,
regardless of the registration mechanism; in particular a proxy should
yield in the face of the object it proxies for.

- speed: A Mobile Node reaching Home should be able to use its Home
Address as optimistic (RFC 4429) right away like it could do on any
visited link with any CoA.

Proposed resolution
-------------------

The proposal to fix this issue is to let the MN use DAD/oDAD over the
Home Link with its Home Address. A proxy would defend the address
without the O bit, and the MN would ignore it, and upon DAD completion,
NA(Override) its address. The HA would be allowed to set the override
bit only within a binding flow, when it knows synchronously that it
represents the live MN. That would enable new HA to take over old HA
when the MN looses states away from home. That would also enable MN to
make before break a tunnel with new HA. 

Still it would still be beneficial to clear the binding properly so we
can still SHOULD or MUST it, but whether that flow works properly or
not, the MN would get its address back.

What do you think?

Pascal

---

From: Vijay Devarapalli <[email-masked]>
Date: Wed, 16 Jul 2008 11:50:36 -0700

Hi Pascal,

Fixed the subject, since the chairs wanted new issues to carry the 
"RFC3775 changes" tag.

> there will be a service disruption that the user might perceive.

I agree this needs to be fixed.

> and reclaim SeND based addresses when a MN proves ownership on link.

Well, if SeND is not being used, does it make sense for the home agent 
to allow the mobile node to claim its address, until the mobile node 
de-registers with a secure binding update? What if a misbehaving mobile 
node on the home link tries to claim the legitimate mobile node's home 
address while the home agent is defending the address?

> without the O bit, 

This would modify the existing behavior. For unsolicited neighbor 
advertisements, the Home Agent sets the 'O' bit. See section 10.4.1.

 > and the MN would ignore it, and upon DAD completion,
> represents the live MN. 

I lost you. What does "within a binding flow" mean?

Vijay

> That would enable new HA to take over old HA

---

From: "Pascal Thubert (pthubert)" <[email-masked]>
Date: Thu, 17 Jul 2008 09:52:28 +0200

Hi Vijay:

Let me rephrase the proposed resolution in more details:

For me there are 2 phases in the HA proxy operation. Sync, and async.
Sync is upon a communication with the MN. For instance the MN sends a
BU, the HA completes DAD, sends NA and BA (success) back to the MN.
Async is upon communication with another node (solicited) or upon a
timer (unsolicited).

What I'm asking to change on the HA side is that in the async case, the
HA does not set the override because its binding might be stale. I'm
also asking that the HA marks a binding as stale upon a NA (override),
stops intercepting packets and stops defending the address in ND flows.

What I'm asking to change on the MN side is to allow it to perform
(optimistic) DAD for its Home Address when it returns home regardless of
the known state of the binding. I'm also asking that both the MN and the
HA may ignore a NA without the override bit and consider DAD a success
if no NA (Override) is heard.

I'm not asking to change that the MN MUST clean up the binding. That's a
good thing to remove the stale BCE in the HA before end of lifetime. But
if we do it to early there might be packets lost before the MN gets its
address back.

The way things would work with the change is that upon DAD completion,
the MN returning home would send NA (Override) and get its address back
regardless of the state of the HAs. The coup (the NA(override)) on the
home address would trigger the stale HA to stop intercepting so there
would be (almost) no packet loss during the transition.

Also, a MN that is away from home may bind with a new HA without
cleaning a binding with an old HA first; the new HA will complete DAD,
send NA(override) at which point old HA will yield and new HA will start
forwarding with (almost) no packet loss during the transition. In that
case the MN would clean up the old BCE after the successful BA from the
new HA.

If the initial binding is with a backlevel HA on the home link, that HA
will defend the address with the O bit as prescribed by RFC 3775 and the
MN or new HA will not complete DAD. The RFC 3775 operation will thus
happen unchanged.

A backlevel MN binding with a HA with the proposed behaviour will clean
up the old binding before it attempts anything so then again things
happen prescribed as by RFC 3775. 

A MN that looses its states about an existing binding, regardless of
whether it implements the original or the new behaviour, will always be
able to bind again if the HA implements the new behaviour, and will not
be able to bind till end of lifetime if the HA implements the old
behaviour.

Seems to me that the new proposal is compatible with the existing
standard.

Pascal

>Sent: mercredi 16 juillet 2008 20:51
>To: Pascal Thubert (pthubert):
>Cc: [email-masked]; [email-masked]; Koodli, Rajeev; Sri
Gundavelli (sgundave)
>Subject: Re: [RFC3775 changes] New Issue on HA behaviour upon MN
returning Home