Subject: [MEXT] [RFC3775 changes] De-registration when returning home

From: Vijay Devarapalli <[email-masked]>
Date: Thu, 20 Mar 2008 09:44:54 -0700

Hi,

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.

Vijay
_______________________________________________
MEXT mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/mext

---

From: Alexandru Petrescu <[email-masked]>
Date: Thu, 20 Mar 2008 18:21:16 +0100

Vijay Devarapalli wrote:
> Hi,
> 
> 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.
> 
>  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.

I'd agree make that SHOULD a MUST, it's implemented that way in a
implementation.  However, I'd try to identify better why was that a
SHOULD at the time of writing.  Maybe asking some of the authors and
commenters of rfc3775.

Alex

> 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:
> 
> 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.
> 
> Vijay _______________________________________________ MEXT mailing
> list [email-masked] https://www.ietf.org/mailman/listinfo/mext
> 

______________________________________________________________________
This email has been scanned by the MessageLabs Email Security System.
For more information please visit http://www.messagelabs.com/email 
______________________________________________________________________
_______________________________________________
MEXT mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/mext

---

From: "Giaretta, Gerardo" <[email-masked]>
Date: Thu, 20 Mar 2008 10:23:21 -0700

Hi Vijay,

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). 

Can we improve the text to take this into account? 

Cheers
Gerardo

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On Behalf
Of
> Vijay Devarapalli
> Sent: Thursday, March 20, 2008 9:45 AM
> To: [email-masked]
> Subject: [MEXT] [RFC3775 changes] De-registration when returning home
> 
> Hi,
> 
de-registration

---

From: Vijay Devarapalli <[email-masked]>
Date: Thu, 20 Mar 2008 10:32:31 -0700

> Can we improve the text to take this into account? 

Agree.

How about the following?

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.  In this home registration, the mobile node MUST set the
    Acknowledge (A) and Home Registration (H) bits, set the Lifetime
    field to zero, and set the care-of address for the binding to the
    mobile node's own home address.  The mobile node MUST use its home
    address as the source address in the Binding Updat

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.
    If the mobile node wants the home agent to stop intercepting the
    packets meant for its home address, the mobile node MUST send a
    de-registration Binding Update to its home agent. In this
    Binding Update, the mobile node MUST set the Acknowledge (A) and Home
    Registration (H) bits, set the Lifetime field to zero, and set the
    care-of address for the binding to the mobile node's own home
    address.  The mobile node MUST use its home address as the source
    address in the Binding Update.

Please feel free to modify the text.

Vijay

---

From: "Giaretta, Gerardo" <[email-masked]>
Date: Thu, 20 Mar 2008 10:37:26 -0700

I think the text looks good.

Thanks
Gerardo

> From: Vijay Devarapalli [mailto:[email-masked]]
> Sent: Thursday, March 20, 2008 10:33 AM
> To: Giaretta, Gerardo
> Cc: [email-masked]
> Subject: Re: [MEXT] [RFC3775 changes] De-registration when returning
home

---

From: Alexandru Petrescu <[email-masked]>
Date: Thu, 20 Mar 2008 18:40:05 +0100

Giaretta, Gerardo wrote:
> Hi Vijay,
> 
> 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.

Just a note: MN having two interfaces can be accomodated by 3775 by 
assigning a different HoA to each interface, and still have MN MUST (not 
SHOULD) send the BU-0 when a interface comes back home.

I'm not sure why would one want to not have a distinct HoA per interface.

Alex

> 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).
> 
> Cheers Gerardo
>> -----Original Message----- From: [email-masked] 
>> [mailto:[email-masked]] On Behalf
> Of
>> Vijay Devarapalli Sent: Thursday, March 20, 2008 9:45 AM To: 
>> [email-masked] Subject: [MEXT] [RFC3775 changes] De-registration 
>> when returning home
>> 
>> Hi,
>> 
>> 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/
>> 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.
>> 
> _______________________________________________ MEXT mailing list 
> [email-masked] https://www.ietf.org/mailman/listinfo/mext
>

---

From: "Giaretta, Gerardo" <[email-masked]>
Date: Thu, 20 Mar 2008 10:41:56 -0700

> From: Alexandru Petrescu [mailto:[email-masked]]
> Sent: Thursday, March 20, 2008 10:40 AM
> To: Giaretta, Gerardo
> Cc: Vijay Devarapalli; [email-masked]
home
> I'm not sure why would one want to not have a distinct HoA per
interface.

To enable vertical handovers for example.

Gerardo

---

From: Alexandru Petrescu <[email-masked]>
Date: Thu, 20 Mar 2008 18:46:04 +0100

> To enable vertical handovers for example.

Right.

So in the above case if the mobile switches interface2 on while 
interface1 is away from home it will perform a vertical handover towards 
home and de-register.  I don't see a problem with that.

Alex

---

From: "Giaretta, Gerardo" <[email-masked]>
Date: Thu, 20 Mar 2008 10:49:06 -0700

> Sent: Thursday, March 20, 2008 10:46 AM
> To: Giaretta, Gerardo
home
> home and de-register.  I don't see a problem with that.

I don't see a problem either. It's just that it is up to the MN to
signal the HA when the actual handover takes place and this is
independent of when the interface2 attaches to the home link. The MN may
wait minutes before sending the deregistration BU. 

Gerardo

---

From: Alexandru Petrescu <[email-masked]>
Date: Thu, 20 Mar 2008 18:58:44 +0100

Giaretta, Gerardo wrote:
> 
>> -----Original Message----- From: Alexandru Petrescu
>> [mailto:[email-masked]] Sent: Thursday, March 20,
>> 2008 10:46 AM To: Giaretta, Gerardo Cc: Vijay Devarapalli;
>> [email-masked] Subject: Re: [MEXT] [RFC3775 changes] De-registration
>> when returning
> home
>> Giaretta, Gerardo wrote:
>>>> -----Original Message----- From: Alexandru Petrescu
>>>> [mailto:[email-masked]] Sent: Thursday, March 20,
>>>> 2008 10:40 AM To: Giaretta, Gerardo Cc: Vijay Devarapalli;
>>>> [email-masked] Subject: Re: [MEXT] [RFC3775 changes]
>>>> De-registration when
> returning
>>> home
>>>> Giaretta, Gerardo wrote:
>>>>> Hi Vijay,
>>>>> 
>>>>> This was discussed also in Philadelphia and in general I
>>>>> agree a
>>> MUST
>>>>> is more appropriate.
>>>>> 
>>>>> Let's assume for example the MN has two active interfaces, it
>>>>> is using interface with CoA1 registered at the HA.
>>>> Just a note: MN having two interfaces can be accomodated by
>>>> 3775 by assigning a different HoA to each interface, and still
>>>> have MN MUST
>>> (not
> independent of when the interface2 attaches to the home link. The MN
> may wait minutes before sending the deregistration BU.

So if I add a sysctl with the number of additional minutes forced prior
to sending BU it would do the trick... but it will still be a MUST,
maybe a delayed MUST.

Alex

---

From: "Giaretta, Gerardo" <[email-masked]>
Date: Thu, 20 Mar 2008 11:03:25 -0700

> Sent: Thursday, March 20, 2008 10:59 AM
> To: Giaretta, Gerardo
home
> to sending BU it would do the trick... but it will still be a MUST,

Yes, the new text from Vijay covers the issue very well I think. It is a
MUST when the MN wants the HA to stop intercepting the packets. I think
this is all we need to say.

Gerardo

---

From: Vijay Devarapalli <[email-masked]>
Date: Thu, 20 Mar 2008 12:26:28 -0700

Hi Gerardo,

I changed my mind. Please see below.

>> Can we improve the text to take this into account? 

I think the above scenario, "the MN with two active interfaces"
does not belong in 3775bis. The multiple CoA draft already deals
with scenarios involving more than one active interface. It
includes scenarios where the mobile node might want to keep
either the interface attached with the visited link or the
interface attached to the home link active or even both active.
It is perfectly ok for the multiple CoA draft to specify the
mobile node behavior when there are multiple interfaces involved
that might override some behavior described in RFC 3775.

In 3775bis, we should continue to assume that only one CoA (and
therefore one active interface) can be registered with the home
agent. Anything else would amount to a significant change.

So lets go back to my original proposal.

OLD:

NEW:

Vijay

---

From: "Ahmad Muhanna" <[email-masked]>
Date: Thu, 20 Mar 2008 14:32:00 -0500

> Please feel free to modify the text.

[Ahmad]
Hi Vijay,

Let me understand the proposed change here.

It seems to me that we just went from "SHOULD" to "MUST" and now back to
"OPTIONAL".

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.

One final note: Any where we mandate that the MN "MUST" send
de-registration, we probably need to have a clause that "whenever it is
possible for the MN to do so" i.e. if the MN moves to an area without
coverage, then the MN wont comply anyway.

---

From: "Sri Gundavelli" <[email-masked]>
Date: Thu, 20 Mar 2008 12:37:25 -0700

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.

Sri

> From: [email-masked] [mailto:[email-masked]] On 
> Behalf Of Vijay Devarapalli
> Sent: Thursday, March 20, 2008 12:26 PM
> To: Giaretta, Gerardo
> Cc: [email-masked]
> Subject: Re: [MEXT] [RFC3775 changes] De-registration when 
> returning home
> 
> Hi Gerardo,
> 
> agree a MUST is

---

From: "Ahmad Muhanna" <[email-masked]>
Date: Thu, 20 Mar 2008 15:34:21 -0500

I just would like to make one thing clear here. So far everyone said
that from IOT, etc. MN always sends de-registration when returns home.
IMO, "SHOULD" is working as it should:)

However, I do not mind if the original text is changed by replacing the
respected "SHOULD" by a "MUST" as per Vijay's initial proposal.

Regards,
Ahmad

> It seems to me that we just went from "SHOULD" to "MUST" and 
> now back to "OPTIONAL".
> 
> 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.
> 
> de-registration, we probably need to have a clause that 
> "whenever it is possible for the MN to do so" i.e. if the MN 
> moves to an area without coverage, then the MN wont comply anyway.
> 
> 
> > 
> > Vijay

---

From: "Giaretta, Gerardo" <[email-masked]>
Date: Thu, 20 Mar 2008 13:41:00 -0700

Fully agree.

Gerardo

> From: Sri Gundavelli [mailto:[email-masked]]
> Sent: Thursday, March 20, 2008 12:37 PM
> To: 'Vijay Devarapalli'; Giaretta, Gerardo
> Cc: [email-masked]
> Subject: RE: [MEXT] [RFC3775 changes] De-registration when returning
home

---

From: "Giaretta, Gerardo" <[email-masked]>
Date: Thu, 20 Mar 2008 13:43:40 -0700

Hi Vijay,

This has nothing to do with MCoA. The MN always has one CoA in the
scenario I described. Vertical handovers are definitely in the scope of
rfc3775 and the MN has one primary CoA at the time and only one CoA is
registered at the HA. 

I think the discussion in Philadelphia and Sri's email clarified that.

Therefore I would stick to your previous text (second proposal).

Gerardo

home
> is
> BU
using
> >> interface with CoA1 registered at the HA. Then it switches
interface2
> on

---

From: Vijay Devarapalli <[email-masked]>
Date: Thu, 20 Mar 2008 13:49:46 -0700

> rfc3775 and the MN has one primary CoA at the time and only one CoA is

I am confused. In the scenario you quoted, you said the MN has
two active interfaces. It has CoA1 on one interface and the other
interface is attached to the home link.

You wrote

> to have the traffic destined to interface1). 

This exact scenario is described in the Multiple CoA draft.

> I think the discussion in Philadelphia and Sri's email clarified that.

Nothing can be concluded in the Philadelphia meeting unless
confirmed on the mailing list.

> Therefore I would stick to your previous text (second proposal).

Ok, but needs consensus though, because it is a much bigger
change than just fixing the issue we have.

Vijay

---

From: "Giaretta, Gerardo" <[email-masked]>
Date: Thu, 20 Mar 2008 13:54:32 -0700

using
> > interface with CoA1 registered at the HA. Then it switches
interface2 on
> This exact scenario is described in the Multiple CoA draft.

The interface2 will be active but not using the HoA even though in the
home link. Basically, until the deregistration BU is sent to the HA, the
HA will still defend the HoA and forward the packets to the registered
CoA. For example in a point to point home link the MN could pick another
IPv6 address from the HNP not using the HoA.

Again, there are no multiple CoAs, and there is no HoA active in more
than one interface

Gerardo

returning
> >>>> and detects interfaces2 is connected to the home link. This
should
> > not
> >>>> traffic destined to the HoA routed to interface2 (the MN may
still
> > want

---

From: "Ahmad Muhanna" <[email-masked]>
Date: Thu, 20 Mar 2008 16:06:03 -0500

> The interface2 will be active but not using the HoA even 
> though in the home link. Basically, until the deregistration 
> BU is sent to the HA, the HA will still defend the HoA and 
> forward the packets to the registered CoA. For example in a 
> point to point home link the MN could pick another
> Again, there are no multiple CoAs, and there is no HoA active 
> in more than one interface

[Ahmad]
May be I am missing something. Why this scenario needs to be captured
and addressed in RFC775bis? 

> > Ok, but needs consensus though, because it is a much bigger change 
> > than just fixing the issue we have.
> > 
> > Vijay
> > 
> > >
> > > Gerardo
> > >
> > >>>> This was discussed also in Philadelphia and in general 
> I agree a
> > > MUST
> > >> is
> > >>>> more appropriate.
> > >>>>
> > >> includes scenarios where the mobile node might want to 
> keep either 
> > >> the interface attached with the visited link or the interface 
> > >> attached to the home link active or even both active.
> > >> It is perfectly ok for the multiple CoA draft to specify 
> the mobile 
> > >> node behavior when there are multiple interfaces involved that 
> > >> might override some behavior described in RFC 3775.
> > >>
> > >>      the movement detection algorithm in use (Section 
> 11.5.1), when
> > > the
> > >>      The mobile node SHOULD then send a Binding Update 
> to its home
> > > agent,
> > >>      the movement detection algorithm in use (Section 
> 11.5.1), when
> > > the

---

From: Vijay Devarapalli <[email-masked]>
Date: Thu, 20 Mar 2008 14:08:21 -0700

Giaretta, Gerardo wrote:

> CoA. 

I don't see why the mobile node's interface2 is active, attached
to the home link, but does not have the HoA configured on it.

> For example in a point to point home link the MN could pick another

If interface2 is going to be configured with another home
address from the same home prefix, you have a multi-homed
mobile node that has two separate home addresses from the same
home prefix - one home address configured on interface2 and
another on a virtual interface or on the interface1.

> Again, there are no multiple CoAs, and there is no HoA active in more

Might be better to open a separate issue to address this
scenario, rather than accommodate this in the issue meant for
fixing an ambiguity (on whether the mobile node can skip
sending a de-registration BU when it returns home).

Vijay

---

From: "Ahmad Muhanna" <[email-masked]>
Date: Thu, 20 Mar 2008 16:14:17 -0500

> sending a de-registration BU when it returns home).

[Ahmad]
Agree fully! 

I strongly believe that this issue is out of the scope of RFC3775bis. It
needs to be addressed in the respected document. i.e. multi-CoA.
 
> >> Nothing can be concluded in the Philadelphia meeting 
> unless confirmed 
> >> on the mailing list.
> >>

---

From: "Giaretta, Gerardo" <[email-masked]>
Date: Thu, 20 Mar 2008 14:18:21 -0700

> From: Ahmad Muhanna [mailto:[email-masked]]
> Sent: Thursday, March 20, 2008 2:14 PM
> To: Vijay Devarapalli; Giaretta, Gerardo
> Cc: [email-masked]
home
> needs to be addressed in the respected document. i.e. multi-CoA.

Why? The HA will only have one Binding Cache Entry with one CoA and the
MN will use only one interface in a given time for a given HoA. This has
nothing to do with MCoA, but it's a scenario already covered by standard
MIPv6. 

I also think this is the reason why the SHOULD is there in RFC 3775. The
specification shall not mandate that the MN sends the deregistration BU
as soon as he connects to the home link.

Gerardo

> > >> Ok, but needs consensus though, because it is a much bigger
change
> > >>>>>> immediately trigger the MN to send the BU, unless the MN
wants
> > > all
> > >>>>      A mobile node detects that it has returned to its home
link
> > >>> through
> > >>>>      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 mobile node MUST then send a Binding Update to its
home
> > >>> agent,
> > >>>>      to instruct its home agent to no longer intercept or
tunnel
> > >>> packets

---

From: "Ahmad Muhanna" <[email-masked]>
Date: Thu, 20 Mar 2008 16:31:58 -0500

Gerardo,

Multi-CoA is initially to address multi-homing. I believe that belongs
there.
On the other hand, if you believe it does not belong to MCoA draft, you
still did not answer the other question, why you think it belong to
RFC3775?

Regards,
Ahmad

> From: Giaretta, Gerardo [mailto:[email-masked]] 
> Sent: Thursday, March 20, 2008 4:18 PM
> To: Muhanna, Ahmad (RICH1:2H10); Vijay Devarapalli
> Cc: [email-masked]
> Subject: RE: [MEXT] [RFC3775 changes] De-registration when 
> returning home
> 
> 
> 
> scenario, 
> > > rather than accommodate this in the issue meant for fixing an 
> > > ambiguity (on whether the mobile node can skip sending a 
> > > de-registration BU when it returns home).
> > 
> > [Ahmad]
> > Agree fully!
> > 
> > I strongly believe that this issue is out of the scope of 
> RFC3775bis.
> It
> Why? The HA will only have one Binding Cache Entry with one 
> CoA and the MN will use only one interface in a given time 
> for a given HoA. This has nothing to do with MCoA, but it's a 
> scenario already covered by standard MIPv6. 
> 
> I also think this is the reason why the SHOULD is there in 
> RFC 3775. The specification shall not mandate that the MN 
> sends the deregistration BU as soon as he connects to the home link.
> 
> Gerardo
> 
> > > Vijay
> > >
> > > >
> > > > Gerardo
> > > >
> > > >
> > > >>> I think the discussion in Philadelphia and Sri's 
> email clarified
> > > > that.

---

From: "Ahmad Muhanna" <[email-masked]>
Date: Thu, 20 Mar 2008 17:49:55 -0500

Hi All,

I hope that you view this as an attempt to resolve the issue rather than
I am changing my mind. But here the details. I may be repeating myself
here but please bear with me:

My understanding of "SHOULD" STILL did not change which in this specific
case means the following:

"The MN MUST send de-registration UNLESS the MN has a valid reason NOT
to send de-registration"

Initially when we discussed this sometimes back offline, I only gave two
examples why this has to stay "SHOULD":

A. What happens if the MN as soon as it moves to the home link lost
coverage, MN will not be able to send de-registration.

B. What happens if the MN as soon as it moves to the home link, the MN
lost power.

I guess these two examples were probably NOT enough for people to
believe in the above definition and my stand for keeping "SHOULD" vs.
changing it to "MUST". However, the scenario which Gerardo and Sri are
referring to makes me believe more strongly that the base RFC3775 need
to keep "SHOULD" and NOT to be replaced with "MUST"

Here is why?
============
My understanding of the scenario at hand, is the following (Gerardo's
and Sri's)

1. Let us assume that the MN has two interfaces, if1 connected to WLAN
and if2 to something else.
2. MN is connected to WLAN via if1 and have a BCE with its HA as , CoA1
and HoA1.

3. MN for a reason or another starts if2 and finds out that if2 is on
its home link where HoA1 belongs.
4. However, the MN probably still would like to use if1 for whatever
reason.
5. The MN does not want to use its HoA1 on if2 YET.

6. IMO, at this point, the MN has a valid reason NOT to send
de-registration yet to the HA. Then the rule of "SHOULD" give the MN the
choice of doing so.

7. After a certain period of time, the MN decides to use its if2 and
probably HoA1 on if2.
8. Therefore, the MN has no longer has a valid REASON NOT to send
de-registration to its HA.
9. In this case the MN and according to the rule of "SHOULD" MUST send a
de-registration message to the HA to stop defending the HoA.

NOW: The above scenario constitute example NO. C on my list to support
"SHOULD" rather than "MUST" list above.

The fact that we now know of this scenario proves one thing, we probably
will have another scenario in the future where Client MIPv6 protocol
will be better served by keeping "SHOULD" rather than "MUST"

Finally:
========
I strongly believe that we need to keep the base Client MIP6 protocol,
RFC3775, RFC3775bis, as generic and general and valid to any future
scenario that we are not aware of at this time. Adding a clause and
coupling that with a "MUST" is restricting the base protocol behavior to
a very limited and specific case. On the other hand, whenever, we
identify another scenario like the above, we can always specify the
respected behavior in the respective document where that scenario is
captured without contradicting nor overruling the base Client MIP6
protocol.

Hope this helps. Cheers to you ALL!

Regards,
Ahmad

> From: Muhanna, Ahmad (RICH1:2H10) 
> Sent: Thursday, March 20, 2008 3:34 PM
> To: Muhanna, Ahmad (RICH1:2H10); 'Vijay Devarapalli'; 
> 'Giaretta, Gerardo'
> Cc: [email-masked]'
> I just would like to make one thing clear here. So far 
> everyone said that from IOT, etc. MN always sends 
> de-registration when returns home. IMO, "SHOULD" is working 
> as it should:)
> 
> However, I do not mind if the original text is changed by 
> replacing the respected "SHOULD" by a "MUST" as per Vijay's 
> initial proposal.
> 
> Regards,
> Ahmad
> 
> 
> > 11.5.1), when the
> > 11.5.1), when the
> > It seems to me that we just went from "SHOULD" to "MUST" 
> and now back 
> > to "OPTIONAL".
> > 
> > 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.
> 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 
> purpose of 
> scenarios 
> > let us capture that in the respected document.
> > 
> "whenever it 
> > is possible for the MN to do so" i.e. if the MN moves to an area 
> > without coverage, then the MN wont comply anyway.
> > 
> > 
> > > 
> > > Vijay

---

From: Vijay Devarapalli <[email-masked]>
Date: Thu, 20 Mar 2008 15:56:29 -0700

> to keep "SHOULD" and NOT to be replaced with "MUST"

This scenario is addressed in the Multiple CoA draft. Section 5.6.2
describes how the mobile node can continue using the interface
attached to the visited link even though it is attached to the home
link using another interface.

> de-registration message to the HA to stop defending the HoA.

The MN now just needs to delete the binding associated with the
interface which is still attached to the visited link.

> "SHOULD" rather than "MUST" list above.

To support the above scenario, the multiple CoA draft already
updates/modifies the mobile node behavior from what is specified
in RFC 3775.

> will be better served by keeping "SHOULD" rather than "MUST"

RFC 3775 does not have support all possible scenarios. Documents
that extend RFC 3775 (for example the multiple CoA draft) describe
what the mobile node's behavior needs to be for these scenarios.

Vijay

---

From: "Ahmad Muhanna" <[email-masked]>
Date: Thu, 20 Mar 2008 18:07:51 -0500

> > 2. MN is connected to WLAN via if1 and have a BCE with its HA as , 
> > CoA1 and HoA1.
> > 
> This scenario is addressed in the Multiple CoA draft. Section 
> 5.6.2 describes how the mobile node can continue using the 
> interface attached to the visited link even though it is 
> attached to the home link using another interface.

[Ahmad]
Agree. It was listed as another example for using SHOULD.
> > de-registration yet to the HA. Then the rule of "SHOULD" 
> give the MN 
> > the choice of doing so.
> > 
> > 9. In this case the MN and according to the rule of 
> "SHOULD" MUST send 
> > a de-registration message to the HA to stop defending the HoA.
> 
> The MN now just needs to delete the binding associated with 
> the interface which is still attached to the visited link.

[Ahmad]
You are assuming that it follows M-CoA draft solution. Right? If that
the case, then Agree.

> updates/modifies the mobile node behavior from what is 
> specified in RFC 3775.

[Ahmad]
Then why do we need to have a MUST in the base protocol then?
Is there anything wrong in having the base protocol generic enough not
to contradict future behavior nor being overruled while serving the
intended functionality.

> 
> > The fact that we now know of this scenario proves one thing, we 
> > probably will have another scenario in the future where 
> Client MIPv6 
> > protocol will be better served by keeping "SHOULD" rather 
> than "MUST"
> 
> RFC 3775 does not have support all possible scenarios. 

[Ahmad]
Of course, Did I say it has?

> Documents that extend RFC 3775 (for example the multiple CoA 
> draft) describe what the mobile node's behavior needs to be 
> for these scenarios.

[Ahmad]
My argument exactly! Why do we need the change then?

> > coupling that with a "MUST" is restricting the base 
> protocol behavior 
> > to a very limited and specific case. On the other hand, 
> whenever, we 
> >> To: Muhanna, Ahmad (RICH1:2H10); 'Vijay Devarapalli'; 'Giaretta, 
> >> Gerardo'
> >> Cc: [email-masked]'
> everyone said 
> >> that from IOT, etc. MN always sends de-registration when returns 
> >> home. IMO, "SHOULD" is working as it should:)
> >>
> replacing 
> >> the respected "SHOULD" by a "MUST" as per Vijay's initial proposal.
> >>
> >> Regards,
> >> Ahmad
> >>
> >>
> >>>>     The mobile node SHOULD then send a Binding Update to 
> its home 
> >>>> agent,

---

From: Vijay Devarapalli <[email-masked]>
Date: Thu, 20 Mar 2008 16:13:05 -0700

> to contradict future behavior nor being overruled while serving the

If the mobile node does not send a de-registration BU, then it
cannot send/receive packets from the home link. The home agent
continues to intercept and tunnel the packets to the old CoA.
I am talking about the basic case here - a mobile node with a
single interface. Changing the 'SHOULD' to 'MUST' is supposed
to fix this.

Vijay

---

From: "Ahmad Muhanna" <[email-masked]>
Date: Thu, 20 Mar 2008 19:05:06 -0500

> If the mobile node does not send a de-registration BU, then 
> it cannot send/receive packets from the home link. The home 
> agent continues to intercept and tunnel the packets to the old CoA.
[Ahmad]
Vijay,

I guess we went through this discussion before. Please understand that I
have no hidden AGENDA what so ever here:)
But according to "SHOULD" rule the MN MUST send de-registration UNLESS
there is a valid reason not to do so. My understanding any handset
vendor who claims support for RFC3775 MUST have their handset send
de-registration when returning home, otherwise, they can NOT claim
compliance and they will be in trouble during IOT:)

> >> draft) describe what the mobile node's behavior needs to 
> be for these 
> >> scenarios.
> > 
> > [Ahmad]
> >>>>>>     A mobile node detects that it has returned to its 
> home link 
> >>>>>> through
> >>>>>>     to instruct its home agent to no longer intercept 
> or tunnel 
> >>>>>> packets
> >>>>>>     A mobile node detects that it has returned to its 
> home link 
> >>>>>> through
> "SHOULD"

---

From: Alexandru Petrescu <[email-masked]>
Date: Fri, 21 Mar 2008 10:50:01 +0100

Hi Ahmad, at first read I agreed with you but then I thought hmmm... see 
below.

> B. What happens if the MN as soon as it moves to the home link, the MN

But this two cases are accidental cases.  I think the spec should say 
what MN is about to do when links are deterministic, the spec shouldn't 
describe observed behaviours in accidental cases but rather suggest how 
we'd like MN to act.

Just some observation,

Alex

---

From: "Ahmad Muhanna" <[email-masked]>
Date: Fri, 21 Mar 2008 09:37:29 -0500

> But this two cases are accidental cases.  I think the spec 
> should say what MN is about to do when links are 
> deterministic, the spec shouldn't describe observed 
> behaviours in accidental cases but rather suggest how we'd 
> like MN to act.
> 
> Just some observation,

[Ahmad]
Thanks Alex. 
Agree that these are accidental. That probably why people were not
convinced!

But let me try the following:
If a MN goes out of coverage for a very short period of time right after
coming home but before sending de-registration. Let us also assume that
before the MN was able to release its BCE with its HA it gets coverage.
What do you expect the MN should do?

IMO, the MN MUST send de-registration.
So my argument is that "SHOULD" serves all of these possible scenarios
that we identified and did not identify much better than having a very
strict not realistic "MUST". Finally, let us remember that the MN knows
very well, that in order to be able to use the same HoA when it goes
home, it "MUST" send a de-registration UNLESS there is a valid reason
for the MN NOT to do so.

Hope this add a little clarification.

---

From: "Sri Gundavelli" <[email-masked]>
Date: Sun, 23 Mar 2008 14:12:42 -0700

My thoughts on this ...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.

This will avoid any new discussions on who is in control,
network ...client ...., multi-homing ...etc, just fix
the technical issue and move forward. My 2c.

Sri 

> Behalf Of Alexandru Petrescu
> Sent: Friday, March 21, 2008 2:50 AM
> To: Ahmad Muhanna
> Cc: [email-masked]
> give the MN the
> "SHOULD" MUST send a
> protocol behavior to

---

From: "Benjamin Lim" <[email-masked]>
Date: Mon, 24 Mar 2008 11:56:21 +0800

Hi, 

Replies inline.

> Behalf Of Sri Gundavelli
> Sent: Monday, March 24, 2008 5:13 AM
> To: 'Alexandru Petrescu'; 'Ahmad Muhanna'
> Cc: [email-masked]
> 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 
[Ben] I agree here that such action must be documented.

> 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.
> 
[Ben] How about the following text?

</start of new text>
In the event when the mobile node wants to use the interface attached to the
home link for packet sending or receiving, the mobile node MUST send the 
Binding Update to its home agent. This is to prevent the case when the
mobile 
node and its home agent will both be defending the same home address, 
which might result in the mobile node losing its capabilites to utilize the
home 
address for communiation on the home link.
</end of new text> 

In this home registration, the mobile node MUST set the
Acknowledge (A) and Home Registration (H) bits, set the Lifetime
field to zero, and set the care-of address for the binding to the
mobile node's own home address.  The mobile node MUST use its home
address as the source address in the Binding Update.

Regards,
Benjamin Lim

> network ...client ...., multi-homing ...etc, just fix the 
> technical issue and move forward. My 2c.
> 
> 
> Sri

---

From: "George Tsirtsis" <[email-masked]>
Date: Mon, 24 Mar 2008 11:43:08 +0000

I reviewed RFC3775 for this and the text in 11.5.4 is not bad; in fact
the section describes very well exactly what happens when the dereg-BU
is sent. What is not indicated (which should be rather obvious) is
what happens when the dereg-BU is not sent.

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:

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. If the mobile node decides not to send such a Binding Update over
   the home link, the home agent will continue to intercept all packets sent
   to the mobile's home address. Intercepted packets will be tunnel as
   normal to the mobile's registered care-of address according to the existing
   binding cache entry for this mobile node.

I think this makes clear that: Implementor swho do not want to think
too much, they can just implement the SHOULD. Implementors who
actually think about whether to implement SHOULDs, can see clearly
what the expected behavior of the HA will be i.e., packets will still
flow to the foreign link. they can then decide if/when that makes
sense in their implementation.

Regards
George

---

From: "Ahmad Muhanna" <[email-masked]>
Date: Mon, 24 Mar 2008 09:33:47 -0500

Unfortunately, we sometimes look at these RFCs as a list of requirement
that can be directly extracted and shipped to a new grad in a
development shop some where around the world without any intelligent
thinking. I would categorized that as "Narrow and very rigid vision" and
very much hazardous!". IMO, that is not what standard is all about!

The line at hand and under discussion, does not come out of the blue. It
is part of the whole RFC. I believe many of us will be insulted if we
downgrade these RFCs to a list of "DO" and "DO NOT" Bullets!. It is
assumed that the reader has some intelligence, not only that but is
capable of understanding the whole RFC functionality, not only that but
understand its interaction with other protocols and RFCs. I hope that we
are not looking at turning these RFCs to a list of requirements that can
be directly implemented by a developer without thinking!:) They are
supposed to be written to a higher level more intelligent folks who are
capable of extracting these requirements while making sure that they fit
in the whole system.

Finally, what I want to emphasize here is the following:

1. So far, no one on this list disagree with what would happen if the MN
did not send a de-registration and at the same time it tries to use its
HoA when comes home. May I ask where that came from?

2. So far all people who posted on this ml, mentioned that they never
had any IOT problem. May I ask why do we need to change anything.

3. If a clarification is needed which is NOT captured in this RFC or in
a specific scenario that needs to be addressed and specified, it should
be captured where it belongs as a clarification not a narrow "MUST" or
"MUST NOT" requirement! 

Cheers!

Regards,
Ahmad

> Sent: Sunday, March 23, 2008 4:13 PM
> To: 'Alexandru Petrescu'; Muhanna, Ahmad (RICH1:2H10)
> Cc: [email-masked]
> > Of Alexandru Petrescu
> > Hi Ahmad, at first read I agreed with you but then I 
> thought hmmm... 
> > see below.
> > 
> > Ahmad Muhanna wrote:
> > > Hi All,
> > > 
> should say 
> > what MN is about to do when links are deterministic, the spec 
> > shouldn't describe observed behaviours in accidental cases 
> but rather 
> > suggest how we'd like MN to act.
> > 
> > Just some observation,
> > 
> > Alex
> > 
> > 
> > >> I just would like to make one thing clear here. So far everyone 
> > >> said that from IOT, etc. MN always sends de-registration when 
> > >> returns home. IMO, "SHOULD" is working as it should:)
> > >>
> > >> However, I do not mind if the original text is changed 
> by replacing

---

From: "Ahmad Muhanna" <[email-masked]>
Date: Mon, 24 Mar 2008 09:59:04 -0500

Hi George, 
I agree with you, the text in section 11.5.4. is detailed enough. 
But I still disagree with the proposed text and consider it not needed.
I believe the following texts are more than enough!

Text extract No. 1:
===================
"

   When sending this Binding Update to its home agent, the mobile node
   must be careful in how it uses Neighbor Solicitation [12] (if needed)
   to learn the home agent's link-layer address, since the home agent
   will be currently configured to intercept packets to the mobile
   node's home address using Duplicate Address Detection (DAD).  In
   particular, the mobile node is unable to use its home address as the
   Source Address in the Neighbor Solicitation until the home agent
   stops defending the home address.
"

Text extract No. 2:
===================
"
   .................. In this special case of the mobile node returning
   home, the mobile node MUST multicast the packet, and in addition set
   the Source Address of this Neighbor Solicitation to the unspecified
   address (0:0:0:0:0:0:0:0).  The target of the Neighbor Solicitation
   MUST be set to the mobile node's home address.  The destination IP
   address MUST be set to the Solicited-Node multicast address [3].  
"

Text extract No. 3:
===================
What about the following:
"
   The mobile node then sends its Binding Update to the home agent's
   link-layer address, instructing its home agent to no longer serve as
   a home agent for it.  By processing this Binding Update, the home
   agent will cease defending the mobile node's home address for
   Duplicate Address Detection and will no longer respond to Neighbor
   Solicitations for the mobile node's home address.  
"

Text extract No. 4:
===================
What about the following:
" 
  ........................ In addition, when returning home prior to the
   expiration of a current binding for its home address, and configuring
   its home address on its network interface on its home link, the
   mobile node MUST NOT perform Duplicate Address Detection on its own
   home address, in order to avoid confusion or conflict with its home
   agent's use of the same address.  This rule also applies to the
   derived link-local address of the mobile node, if the Link Local
   Address Compatibility (L) bit was set when the binding was created.
   If the mobile node returns home after the bindings for all of its
   care-of addresses have expired, then it SHOULD perform DAD.
"

Text extract No. 5:
===================
One more:
"
   After the Mobile Node sends the Binding Update, it MUST be prepared
   to reply to Neighbor Solicitations for its home address.  Such
   replies MUST be sent using a unicast Neighbor Advertisement to the
   sender's link-layer address.  It is necessary to reply, since sending
   the Binding Acknowledgement from the home agent may require
   performing Neighbor Discovery, and the mobile node may not be able to
   distinguish Neighbor Solicitations coming from the home agent from
   other Neighbor Solicitations.  Note that a race condition exists
   where both the mobile node and the home agent respond to the same
   solicitations sent by other nodes; this will be only temporary,
   however, until the Binding Update is accepted.
"

Finally, I understand that you mentioned the following text is added for
implementers who do not want to think too much! I would rather say "who
do not want to read". I disagree with adding this text.

"
   If the mobile node decides not to send such a Binding Update over
   the home link, the home agent will continue to intercept all packets
sent
   to the mobile's home address. Intercepted packets will be tunnel as
   normal to the mobile's registered care-of address according to the
existing
   binding cache entry for this mobile node.
"

Cheers!

Regards,
Ahmad

> Behalf Of George Tsirtsis
> Sent: Monday, March 24, 2008 6:43 AM
> To: Benjamin Lim
> Cc: [email-masked]
> I reviewed RFC3775 for this and the text in 11.5.4 is not 
> bad; in fact the section describes very well exactly what 
> happens when the dereg-BU is sent. What is not indicated 
> (which should be rather obvious) is what happens when the 
> dereg-BU is not sent.
> 
> 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:
> I think this makes clear that: Implementor swho do not want 
> to think too much, they can just implement the SHOULD. 
> Implementors who actually think about whether to implement 
> SHOULDs, can see clearly what the expected behavior of the HA 
> will be i.e., packets will still flow to the foreign link. 
> they can then decide if/when that makes sense in their implementation.
> 
> Regards
> George
> 
> >  > Sent: Monday, March 24, 2008 5:13 AM  > To: 'Alexandru 
> Petrescu'; 
> > 'Ahmad Muhanna'
> >  > Cc: [email-masked]
> >  > Subject: Re: [MEXT] [RFC3775 changes] De-registration when  > 
> > returning home  >
> >
> >  > 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:
> >  >
> to  > send 
> > dereg, as it is currently written.
> >  >
> link through  
> >  In the event when the mobile node wants to use the 
> interface attached 
> > to the  home link for packet sending or receiving, the mobile node 
> > MUST send the  Binding Update to its home agent. This is to prevent 
> > the case when the  mobile  node and its home agent will both be 
> > defending the same home address,  which might result in the mobile 
> > node losing its capabilites to utilize the  home  address for 
> > communiation on the home link.
> >  </end of new text>
> >
> >
> Acknowledge 
> > (A) and Home Registration (H) bits, set the Lifetime  field 
> to zero, 
> > and set the care-of address for the binding to the  mobile 
> node's own 
> > home address.  The mobile node MUST use its home  address as the 
> > source address in the Binding Update.
> >
> >  Regards,
> >  Benjamin Lim
> >
> >
> >  >
> >  > This will avoid any new discussions on who is in control,  >

---

From: Sri Gundavelli <[email-masked]>
Date: Mon, 24 Mar 2008 14:01:02 -0700 (PDT)

I'm not sure, why there is so much of discussion on this thread. To
restate my view, couple of points:

- When the MN returns home, how the MN can de-registers and can start
   using its HoA on the home link is a basic operation. This must be
   specified. Else, the protocol will not work.

- Also, I just looked at RFC 3344 and it clearly specified this and they
   did not leave this to the intelligence of the implementor. Sec 4.6:

   "Before transmitting the (de)Registration
    Request message to its home agent, the mobile node MUST transmit this
    gratuitous ARP on its home network as a local broadcast on this link."

- Also, knowing that this discussion may lead to multi-homing,
   network-based mobility or CMIP-PMIP interactions, I've consciously
   said, lets only fix the technical issue and leave the SHOULD as it
   is and not attempt to open that issue, as it will never converge in
   the light of new protocols,  extensions and new goals.

- The argument that no one had interop issues and so we dont need to
   clarify, may not be the right approach. We should note that we have
   very few MIP6 implementations and practically zero deployments. So,
   if we are fixing the draft, we rather fix all the issues.

- Finally, if we there is no disagreement on the fact that the MN
   MUST send a dereg when it returns home, else it cant even send a
   dereg, I dont see why there will be any issue in stating the same
   and in very clear terms and with mandatory language, as it is a
   basic operation when the MN returns home.

- If the protocol is implemented by college grads or experts is a
   different issue, there is nothing wrong in adding that extra note
   and specifying the operation clearly.

Finally, I will leave this to the chairs and the AD to review and
put a closer to this thread.

Sri

---

From: Sri Gundavelli <[email-masked]>
Date: Mon, 24 Mar 2008 14:02:13 -0700 (PDT)

Hi Ben,

I agree with the text. But, looks like others have some other
thoughts. We can leave this to the chairs to the resolve the
issue and then finalize the text.

Sri

---

From: Sri Gundavelli <[email-masked]>
Date: Mon, 24 Mar 2008 14:10:27 -0700 (PDT)

Hi George,

> does not result in good specs. For example, the MUST in Ben's proposal

Generally, true. I agree. But, in this case, how ever we state, directly
or in a indirect way (the issue if MN does not send that message), but
at the end of the day, we require that De-Reg message to be sent. Its
better if we state the same in direct and explicit terms and qualify it
for that specific case and still leave the original intent of the draft
as it is and what ever it was for ...

Regards
Sri

---

From: "Ahmad Muhanna" <[email-masked]>
Date: Mon, 24 Mar 2008 19:19:05 -0500

> I'm not sure, why there is so much of discussion on this thread. 
> To restate my view, couple of points:
> 
> - Also, I just looked at RFC 3344 and it clearly specified 
> this and they did not leave this to the intelligence of the
>     gratuitous ARP on its home network as a local broadcast on this
link."

[Ahmad]
And some are wondering why there is discussion on this thread! :(

Well, I thought the issue at hand is to mandate the MN (for clarity) to
send de-registration when coming home!
The above text has no normative text related to the MN sending
de-registration when returns home! or I am missing something!

On the other hand, if the discussion is all about how to update the ARP
Cache before sending de-registration as in RFC3344 section 4.6, then in
Client MIP6/IPv6 we should be talking about ND/PND, which I believe
related text is clearly captured in section 11.5.4 [11.5.4.  Returning
Home] of RFC3775 or MAY be , in comparison to section 4.6 in RFC3344,
someone tell us what is missing in section 11.5.4 of RFC3775!! 

> Finally, I will leave this to the chairs and the AD to review 
> and put a closer to this thread.

[Ahmad]
Interesting! 
I did not realize that this is the way consensus achieved on this ml,
IMO, it takes a lot of courage for making such a call!

> > Unfortunately, we sometimes look at these RFCs as a list of 
> > requirement that can be directly extracted and shipped to a 
> new grad 
> > in a development shop some where around the world without any 
> > intelligent thinking. I would categorized that as "Narrow and very 
> > rigid vision" and very much hazardous!". IMO, that is not 
> what standard is all about!
> >
> > The line at hand and under discussion, does not come out of 
> the blue. 
> > It is part of the whole RFC. I believe many of us will be 
> insulted if 
> > we downgrade these RFCs to a list of "DO" and "DO NOT" 
> Bullets!. It is 
> > capable of understanding the whole RFC functionality, not only that 
> > but understand its interaction with other protocols and 
> RFCs. I hope 
> > that we are not looking at turning these RFCs to a list of 
> > requirements that can be directly implemented by a 
> developer without 
> > thinking!:) They are supposed to be written to a higher level more 
> > intelligent folks who are capable of extracting these requirements 
> > while making sure that they fit in the whole system.
> >
> > 1. So far, no one on this list disagree with what would 
> happen if the 
> > MN did not send a de-registration and at the same time it 
> tries to use 
> > its HoA when comes home. May I ask where that came from?
> >
> > 3. If a clarification is needed which is NOT captured in 
> this RFC or 
> > in a specific scenario that needs to be addressed and specified, it 
> > should be captured where it belongs as a clarification not a narrow 
> > "MUST" or "MUST NOT" requirement!
> >
> >
> > Cheers!
> >
> > Regards,
> > Ahmad
> >
> >
> >> My thoughts on this ...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.
> >>
> 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 
> >> - Add additional text and state the MN MUST send a dereg before it 
> >> can use its hoa on the home link.
> >>
> >> This will avoid any new discussions on who is in control, network 
> >> ...client ...., multi-homing ...etc, just fix the 
> technical issue and 
> >> move forward. My 2c.
> >>
> >>
> >> Sri
> >>
> >>
> >>
> >>
> >>
> 'Giaretta,

---

From: "George Tsirtsis" <[email-masked]>
Date: Tue, 25 Mar 2008 10:06:21 +0000

Ahmad,

Just to make sure I understand, your opinion is that the dereg
procedure is sufficiently documented and thus we should not modify
this section at all, right?

I am actually fine with that. What I proposed I think simply added
clarification text without altering the expected behavior of the
protocol, but I am ok with not adding anything, if this is OK with the
rest of the group..

Regards
George

---

From: "George Tsirtsis" <[email-masked]>
Date: Tue, 25 Mar 2008 10:17:27 +0000

Hi Sri,

As you well know, "SHOULD" in IETF specification language means "do
this, unless you have a good reason not to". The text I proposed
(without needing to use "if" statements and MUSTs), clarified what the
expected behavior is when the SHOULD is not followed, which I think is
what you are asking for below. Are you sure the proposed text does not
satisfy your needs?

If you are sure, would you be ok with just leaving the spec as is with
no additions on this section?

Throwing the ball to the chairs and the AD is not going to help much
unless we have a relatively coherent opinion in the group.

Regards
George

---

From: "Ahmad Muhanna" <[email-masked]>
Date: Tue, 25 Mar 2008 08:30:32 -0500

Hi George, 

> Just to make sure I understand, your opinion is that the 
> dereg procedure is sufficiently documented and thus we should 
> not modify this section at all, right?

[Ahmad]
Yes. Thanks.

> 
> I am actually fine with that. What I proposed I think simply 
> added clarification text without altering the expected 
> behavior of the protocol, but I am ok with not adding 
> anything, if this is OK with the rest of the group..
> 
> Regards
> George
> 
> 
> >  Finally, I understand that you mentioned the following 
> text is added 
> > for  implementers who do not want to think too much! I would rather 
> > say "who  do not want to read". I disagree with adding this text.
> >
> >
> >  "
> >  > Sent: Monday, March 24, 2008 6:43 AM  > To: Benjamin Lim  > Cc: 
> > [email-masked]  > Subject: Re: [MEXT] [RFC3775 changes] 
> De-registration 
> > when  > returning home  >  > I reviewed RFC3775 for this 
> and the text 
> > in 11.5.4 is not  > bad; in fact the section describes very well 
> > exactly what  > happens when the dereg-BU is sent. What is not 
> > indicated  > (which should be rather obvious) is what 
> happens when the  
> > > dereg-BU is not sent.
> >  >
> >  > 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:
> home link through
> tunnel packets
> home link through
> tunnel packets
> >  > I think this makes clear that: Implementor swho do not 
> want  > to 
> > think too much, they can just implement the SHOULD.
> >  > Implementors who actually think about whether to implement  > 
> > SHOULDs, can see clearly what the expected behavior of the 
> HA  > will 
> > be i.e., packets will still flow to the foreign link.
> >  > On Mon, Mar 24, 2008 at 3:56 AM, Benjamin Lim  > 
> > > >  > > > Behalf Of Sri Gundavelli  > >  > Sent: Monday, March 24, 
> > 2008 5:13 AM  > To: 'Alexandru  > Petrescu';  > > 'Ahmad Muhanna'
> >  > >  > Cc: [email-masked]
> > > > returning home  >  > >  > > > My thoughts on this ...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.
> >  > > 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.
> 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.
> its  > home 
> > agent,  > > to instruct its home agent to no longer intercept or 
> > tunnel  > packets  > > for it.
> >  > >
> >  > >  </start of new text>
> >  > >  In the event when the mobile node wants to use the  > 
> interface 
> > attached  > > to the  home link for packet sending or 
> receiving, the 
> > mobile node  > > MUST send the  Binding Update to its home 
> agent. This 
> > is to prevent  > > the case when the  mobile  node and its 
> home agent 
> > will both be  > > defending the same home address,  which 
> might result 
> > in the mobile  > > node losing its capabilites to utilize 
> the  home  
> > address for  > > communiation on the home link.
> >  > >  </end of new text>
> >  > >
> >  > >
> >  > >  In this home registration, the mobile node MUST set the  > 
> > Acknowledge  > > (A) and Home Registration (H) bits, set 
> the Lifetime  
> > field  > to zero,  > > and set the care-of address for the 
> binding to 
> > the  mobile  > node's own  > > home address.  The mobile 
> node MUST use 
> > its home  address as the  > > source address in the Binding Update.
> >  > >
> >  > >  Regards,
> >  > >  Benjamin Lim
> >  > >
> >  > >
> >  > >  >
> > > > network ...client ...., multi-homing ...etc, just fix the  > > 
> > technical  > > issue and move forward. My 2c.
> >  > >  >
> >  > >  >
> >  > >  > Sri
> >  > >
> >  > >
> >  > >
> >  > >

---

From: Vijay Devarapalli <[email-masked]>
Date: Tue, 25 Mar 2008 15:11:06 -0700

> what happens when the dereg-BU is not sent.

For a mobile node with a single interface, I still think it makes
sense to say that the mobile node MUST send a de-registration BU
when it detects the home link. We are after all specifying what the
Mobile IPv6 stack on the mobile node needs to do.

>    binding cache entry for this mobile node.

There is an implicit assumption here that the mobile node has more
than one interface and can continue receiving packets at its
registered care-of address. Suggest re-wording

   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.

Vijay

---

From: "Ahmad Muhanna" <[email-masked]>
Date: Tue, 25 Mar 2008 17:19:02 -0500

> There is an implicit assumption here that the mobile node has 
> more than one interface and can continue receiving packets at 
> its registered care-of address. Suggest re-wording
> 

[Ahmad]
Vijay,

I am ok with this clarification text! but a very minor clarification
below to connect the dots!

   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 as 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.

---

From: Vijay Devarapalli <[email-masked]>
Date: Tue, 25 Mar 2008 15:35:49 -0700

> Mobile IPv6 stack on the mobile node needs to do.

(responding to my own post)

One option might be to have separate paragraphs on the behavior
for a mobile node with a single interface and for a mobile node
with multiple interfaces.

Vijay

---

From: Sri Gundavelli <[email-masked]>
Date: Tue, 25 Mar 2008 16:23:30 -0700 (PDT)

Hi George,

> this, unless you have a good reason not to". The text I proposed

Sure, I understand. I'm with you guys on the MN not being able to
send a De-Reg message in some situations, it may be  a conscious
decision of the MN, it may have lost power or it got hijacked after
it attached to the home link ....etc .. etc .. and for some strange
reasons. Fine.

We can also certainly use the SHOULD and also document the issue on
what if the same De-Reg message was not sent, how that leads to a
conflicting state ..etc. However, I'm not clear why we cannot mandate
the MN to send a De-Reg message before it starts using its HoA on
the home link (not when it just attached, when it decides to use the
HoA). What is that "good reason" that allows the MN to use its HoA
and  without having to send a De-Reg message. Why is it not logical
to mandate the MN that created the binding state at the HA, asked the
HA to defend its address, asked the HA to setup the routing state,
cannot be mandated to clear that state before it takes over ?

> Throwing the ball to the chairs and the AD is not going to help much

We can take this thread further. But, I did not sense any change in
opinions. Its the same comments that are getting repeated again and
again (may be just me). Vijay, Ben and myself seem to agree on this
requirement and vs others ..., I was leaving this to the moderator
to set the direction. But, I've no issue, we can ask others to jump
in and express there views and based on that we can determine the
consensus.

Regards
Sri

---

From: "Ahmad Muhanna" <[email-masked]>
Date: Tue, 25 Mar 2008 21:03:23 -0500

HI Sri,

Please see inline.

Regards,
Ahmad

> Sure, I understand. I'm with you guys on the MN not being 
> able to send a De-Reg message in some situations, it may be  
> a conscious decision of the MN, it may have lost power or it 
> got hijacked after it attached to the home link ....etc .. 
> etc .. and for some strange reasons. Fine.
> 
> We can also certainly use the SHOULD and also document the 
> issue on what if the same De-Reg message was not sent, how 
> that leads to a conflicting state ..etc. However, I'm not 
> clear why we cannot mandate the MN to send a De-Reg message 
> before it starts using its HoA on the home link (not when it 
> just attached, when it decides to use the HoA). 

[Ahmad]

This is a reverse logic! 
Moreover and to some extent, it is taking some precious time that can be
invested in a more useful way somewhere else!

However, I would like to say the following hoping that would help.

1. The burden of proof is on those who propose the change and adding the
new bumper sticker to give the valid reason why an "out-of-the-blue"
"MUST" is needed there.

2. Setting point 1 a side for a minute and assuming that the link is not
hijacked :), could you please explain to us what do you mean by "when
the MN starts using its HoA on the home link?"

Cheers! 
 
> .............................................. What is that 
> "good reason" that allows the MN to use its HoA and  without 
> having to send a De-Reg message. Why is it not logical to 
> mandate the MN that created the binding state at the HA, 
> asked the HA to defend its address, asked the HA to setup the 
> routing state, cannot be mandated to clear that state before 
> it takes over ?
> 
> We can take this thread further. But, I did not sense any 
> change in opinions. Its the same comments that are getting 
> repeated again and again (may be just me). Vijay, Ben and 
> myself seem to agree on this requirement and vs others ..., I 
> was leaving this to the moderator to set the direction. But, 
> I've no issue, we can ask others to jump in and express there 
> views and based on that we can determine the consensus.
> 
> Regards
> Sri
> 
> 
> 
> 
> 
> >> > requirement that can be directly extracted and shipped to a new 
> >> > grad in a development shop some where around the world 
> without any 
> >> > rigid vision" and very much hazardous!". IMO, that is 
> not what standard is all about!
> >> >
> >> > The line at hand and under discussion, does not come out of the 
> >> > blue. It is part of the whole RFC. I believe many of us will be 
> >> > insulted if we downgrade these RFCs to a list of "DO" 
> and "DO NOT" 
> >> > Bullets!. It is assumed that the reader has some 
> intelligence, not 
> >> > only that but is capable of understanding the whole RFC 
> >> > functionality, not only that but understand its interaction with 
> >> > other protocols and RFCs. I hope that we are not looking 
> at turning 
> >> > these RFCs to a list of requirements that can be directly 
> >> > implemented by a developer without thinking!:) They are 
> supposed to 
> >> > be written to a higher level more intelligent folks who 
> are capable 
> >> > of extracting these requirements while making sure that 
> they fit in the whole system.
> >> >
> happen if 
> >> > the MN did not send a de-registration and at the same 
> time it tries 
> >> > to use its HoA when comes home. May I ask where that came from?
> >> >
> >> > 2. So far all people who posted on this ml, mentioned that they 
> >> > never had any IOT problem. May I ask why do we need to 
> change anything.
> >> >
> this RFC 
> >> > or in a specific scenario that needs to be addressed and 
> specified, 
> >> > it should be captured where it belongs as a clarification not a 
> >> > narrow "MUST" or "MUST NOT" requirement!
> >> >
> >> >
> >> > Cheers!
> >> >
> >> > Regards,
> >> > Ahmad
> >> >
> >> >
> >> >> 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 
> 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:
> >> >>
> dereg before it 
> >> >>>> I guess these two examples were probably NOT enough 
> for people 
> >> >>>> to believe in the above definition and my stand for keeping
> >> >>> "SHOULD" vs.
> >> >>>> 8. Therefore, the MN has no longer has a valid REASON NOT to 
> >> >>>> send de-registration to its HA.
> >> >>>> a very limited and specific case. On the other hand, 
> whenever, 
> >> >>>> we identify another scenario like the above, we can always
> >> >> specify the
> >> >>>>>>>     Binding Update, the mobile node MUST set the 
> Acknowledge
> >> >>>>>>> (A) and Home

---

From: Sri Gundavelli <[email-masked]>
Date: Tue, 25 Mar 2008 20:48:13 -0700 (PDT)

Hi Ahmad,

inline ...

>> just attached, when it decides to use the HoA).

We can state the De-reg requirement in two ways:

"before using the home network using HoA, MN MUST send a dereg"

or

"if the MN does not send a de-reg, the folllowing bad things will
happen"

Which out of the above two is reverse logic ? To me for the MN to use
its HoA on the home link, it MUST send a de-reg. The requirement can
be stated in explicit, clear and direct terms.

> invested in a more useful way somewhere else!

Indeed ! Always ...

> new bumper sticker to give the valid reason why an "out-of-the-blue"

With out that bumper sticker, the HA and MN will both have the state.
So, we need that bumper sticker and require the MN to graciously
send a dereg message.

> the MN starts using its HoA on the home link?"

When the MN operates as a normal IP node and starts defending its
address on the home link. The MN still needs to remove the state
from the HA and disable the Proxy ND function on the HA.

I'll be more than happy to agree, if I can get a clue on why we
want to leave that little room for skipping dereg. We all seem
to agree on the requirement, we are ready state the affects if
the requirement is not met, but why we cant mandate that. On
whom ever the burden is, its good to understand the bad implications
when we put that MUST there.

Sri

---

From: Sri Gundavelli <[email-masked]>
Date: Tue, 25 Mar 2008 21:12:02 -0700 (PDT)

All involved in the discussion,

Also, I'd like to add ...

I dont want to go on a endless argument. To me the point is not
clear on why we cant mandate that. Some one please explain me the
bad affects of stating such a requirement, I'll rest my case
and agree to the suggested text. No more emails on this thread
from me. I'm trying to be really objective here and not trying to
see in the lines of "who wins approach". As it is, I'm not bothered
about this issue, just that I strongly think we should mandate
that and is the right approach in my view.

If there are good reasons not to mandate that, fine. If the goal
is to support some other scenario, please enlighten me and I will
support it, if its the right goal.

Regards
Sri

---

From: "Benjamin Lim" <[email-masked]>
Date: Wed, 26 Mar 2008 13:56:14 +0800

Hi,

I echo Sri's point below. Preferably if the authors/contributors of 3775 can
provide some info on this matter, we might be able to move/conclude this
discussion.

Regards,
Benjamin Lim

> Sent: Wednesday, March 26, 2008 12:12 PM
> To: Ahmad Muhanna
> Cc: [email-masked]
> I dont want to go on a endless argument. To me the point is 
> not clear on why we cant mandate that. Some one please 
> explain me the bad affects of stating such a requirement, 
> I'll rest my case and agree to the suggested text. No more 
> emails on this thread from me. I'm trying to be really 
> objective here and not trying to see in the lines of "who 
> wins approach". As it is, I'm not bothered about this issue, 
> just that I strongly think we should mandate that and is the 
> right approach in my view.
> 
> If there are good reasons not to mandate that, fine. If the 
> goal is to support some other scenario, please enlighten me 
> and I will support it, if its the right goal.
> 
> Regards
> Sri
> 
> 
> 
> 
> >>> it attached to the home link ....etc ..
> >>> conflicting state ..etc. However, I'm not clear why we cannot 
> >>> mandate the MN to send a De-Reg message before it starts 
> using its 
> >>> HoA on the home link (not when it just attached, when it 
> decides to 
> >>> use the HoA).
> >>
> >> [Ahmad]
> >>
> >> This is a reverse logic!
> >
> >> Moreover and to some extent, it is taking some precious 
> time that can 
> >> be invested in a more useful way somewhere else!
> >
> > Indeed ! Always ...
> >
> >
> >>
> >> 1. The burden of proof is on those who propose the change 
> and adding 
> >> the new bumper sticker to give the valid reason why an 
> "out-of-the-blue"
> >> "MUST" is needed there.
> >>
> >
> > So, we need that bumper sticker and require the MN to 
> graciously send 
> > a dereg message.
> >
> >
> >> 2. Setting point 1 a side for a minute and assuming that 
> the link is 
> >> not hijacked :), could you please explain to us what do 
> you mean by 
> >> "when the MN starts using its HoA on the home link?"
> >>
> >
> > address on the home link. The MN still needs to remove the 
> state from 
> > the HA and disable the Proxy ND function on the HA.
> >
> > I'll be more than happy to agree, if I can get a clue on 
> why we want 
> > to leave that little room for skipping dereg. We all seem 
> to agree on 
> > the requirement, we are ready state the affects if the 
> requirement is 
> > not met, but why we cant mandate that. On whom ever the 
> burden is, its 
> > good to understand the bad implications when we put that MUST there.
> >
> > Sri
> >
> >
> >
> >
> >
> >
> >> Cheers!
> >>
> >>> .............................................. What is that "good 
> >>> reason" that allows the MN to use its HoA and  without having to 
> >>> send a De-Reg message. Why is it not logical to mandate 
> the MN that 
> >>> created the binding state at the HA, asked the HA to defend its 
> >>> address, asked the HA to setup the routing state, cannot 
> be mandated 
> >>> to clear that state before it takes over ?
> >>>
> change in 
> before is 
> But, the 
> >>>>>>>>>>>>     Registration (H) bits, set the Lifetime 
> field to zero,
> >>>>>>>>>>> and set the
> >>>>>>>>>>>>     address.  The mobile node MUST use its home 
> address as
> >>>>>>>>>>> the source

---

From: "Yoshi Tsuda (yotsuda)" <[email-masked]>
Date: Wed, 26 Mar 2008 14:12:47 +0800

Hi those who support "should",

 I have a security concern; if we change the spec to "should",
 and if some HAs take such a case without de-registration
 into consideration, a malicious host in home network could
 try using some HoAs as a service denial attack, I'm afraid.
 Thus, for now, I personally support Sri, an MN "must"
 deregister by itself before using its HoA.

 I haven't followed all emails in this thread, but has anyone
 already considered such a service denial attack?

 In MIPv4 days, I'm afraid, such a consideration mightn't be
 there in MIPv4, although I like MIPv4. :)  Is MIPv6 ok without
 such a consideration?

Regards.
-Yoshi

> Behalf Of Sri Gundavelli (sgundave)
> Sent: Tuesday, March 25, 2008 9:12 PM
> To: Ahmad Muhanna
> Cc: [email-masked]