Subject: Re: [MEXT] CoA==HoA test (Was: Re: Document Shepherd review of draft-ietf-mext-rfc3775bis-05)

From: "Laganier, Julien" <[email-masked]>
Date: Tue, 1 Jun 2010 14:42:03 -0700

Thanks Sri and Vijay;

Charlie, please go ahead and make the change.

--julien

> -----Original Message-----
> From: Sri Gundavelli [mailto:[email-masked]]
> Sent: Thursday, May 27, 2010 4:16 PM
> To: Laganier, Julien; Devarapalli, Vijay; Perkins, Charles
> Cc: [email-masked]; [email-masked];
> [email-masked]; [email-masked]
> Subject: Re: [MEXT] CoA==HoA test (Was: Re: Document Shepherd review of
> draft-ietf-mext-rfc3775bis-05)
> 
> Agree with the below proposed text.
> 
> 
> Sri
> 
> 
> On 5/25/10 3:48 PM, "Laganier, Julien" <[email-masked]> wrote:
> 
> > Thanks Vijay -
> >
> > Folks, please comment whether or not you agree with the proposal from
> Vijay
> > ASAP -- we need to move forward with publication of RFC3775 bis.
> >
> > --julien
> >
> >> -----Original Message-----
> >> From: Devarapalli, Vijay [mailto:[email-masked]]
> >> Sent: Wednesday, May 12, 2010 12:05 PM
> >> To: Laganier, Julien; Perkins, Charles
> >> Cc: [email-masked]; [email-masked]; draft-ietf-
> >> [email-masked]; [email-masked]; [email-masked]
> >> Subject: Re: [MEXT] CoA==HoA test (Was: Re: Document Shepherd review
> of
> >> draft-ietf-mext-rfc3775bis-05)
> >>
> >> Hello,
> >>
> >> Here are the text changes. In section 9.5.1, replace
> >>
> >>    o  If the Lifetime specified in the Binding Update is zero or the
> >>       specified care-of address matches the home address for the
> >>       binding, then this is a request to delete the cached binding
> for
> >>       the home address.
> >>
> >> with
> >>
> >>    o  If the Lifetime specified in the Binding Update is zero, then
> >>       this is a request to delete the cached binding for the home
> >>       address.
> >>
> >> Add the following text to section 9.5.1.
> >>
> >>   If the Lifetime specified in the Binding Update is not zero and if
> >>   the home address in the Home Address Destination Option is the
> same
> >>   as the Care-of Address in the Binding Update, then the receiving
> node
> >>   MUST treat this Binding Update as invalid and respond with a
> Binding
> >>   Acknowledgement with status code TBA (Invalid Care-of Address).
> >>
> >> And add the following to the IANA considerations section under
> "Status
> >> Code".
> >>
> >>   TBA Invalid Care-of Address.
> >>
> >> I couldn't map this error condition to any of the existing status
> codes.
> >> So I defined a new one.
> >> FYI, this change is not backward compatible.
> >>
> >> Vijay
> >>
> >>
> >> On May 11, 2010, at 12:59 PM, Laganier, Julien wrote:
> >>
> >>> [email-masked]
> >>>>
> >>>> Inline:
> >>>>
> >>>> On 5/4/10 10:38 AM, "ext Laganier, Julien" <[email-masked]>
> >>>> wrote:
> >>>>
> >>>>> Folks,
> >>>>>
> >>>>> Laganier, Julien wrote:
> >>>>>>
> >>>>>> Devarapalli, Vijay wrote:
> >>>>>>>
> >>>>>>> Laganier, Julien wrote:
> >>>>>>>
> >>>>>>>> [...]
> >>>>>>>>
> >>>>>>>> - Remove the HoA == CoA test as sufficient condition for
> >> deregistration.
> >>>>>>>> If we go this way, we also have to specify what to do when the
> >> HA
> >>>>>>>> receives a binding with HoA == CoA, we can't just remove the
> >> test alone.
> >>>>>>>> Since you're in favor of removing this test, what would you
> >> suggest the HA
> >>>>>>>> does when it receives a BU with non-zero lifetime and set CoA
> ==
> >>>>>>>> HoA? Send an  error? Deregister the binding?
> >>>>>>>
> >>>>>>> We had discussed this too. The HA is supposed to send a binding
> >> ack
> >>>>>>> with error status if the HoA is set to CoA and the lifetime is
> >> not zero.
> >>>>
> >>>>
> >>>> From 3775 only perspective:
> >>>> Isnt the case of an MN sending a BU with HoA==CoA and lifetime!=0
> an
> >>>> anomaly?
> >>>> However it would help if the MN received an error response from
> the
> >> HA
> >>>> as Vijay suggested. So if Vijay can propose the error code and
> >> associated
> >>>> text you could close the issue.
> >>>
> >>> Indeed.
> >>>
> >>> Vijay, can you send text to the list?
> >>>
> >>> --julien
> > _______________________________________________
> > MEXT mailing list
> > [email-masked]
> > https://www.ietf.org/mailman/listinfo/mext

---

From: Alexandru Petrescu <[email-masked]>
Date: Wed, 02 Jun 2010 11:27:30 +0200

Vijay says the change is not backward compatible... so is this still a 
bis draft?

Alex

Le 26/05/2010 00:48, Laganier, Julien a écrit :
> Thanks Vijay -
>
> Folks, please comment whether or not you agree with the proposal from Vijay ASAP -- we need to move forward with publication of RFC3775 bis.
>
> --julien
>
>>        binding, then this is a request to delete the cached binding for
>>        the home address.
>>
>> with
>>
>>    the home address in the Home Address Destination Option is the same
>>    as the Care-of Address in the Binding Update, then the receiving node
>>    MUST treat this Binding Update as invalid and respond with a Binding
>> And add the following to the IANA considerations section under "Status
>> Code".
>>
>> I couldn't map this error condition to any of the existing status codes.
>> So I defined a new one.
>>>> On 5/4/10 10:38 AM, "ext Laganier, Julien"<[email-masked]>
>>>> wrote:
>>>>
>>>>> Folks,
>>>>>
>>>>> Laganier, Julien wrote:
>>>>>>
>>>>>>>> does when it receives a BU with non-zero lifetime and set CoA ==
>>>> Isnt the case of an MN sending a BU with HoA==CoA and lifetime!=0 an
>>>> anomaly?
>>>> However it would help if the MN received an error response from the
>> HA

---

From: "Laganier, Julien" <[email-masked]>
Date: Wed, 2 Jun 2010 08:42:31 -0700

Alex, all,

I am not sure why Vijay's change would be backward incompatible. There are two cases:

1) 3775 MN against RFC3775bis/Vijay HA
--------------------------------------

The 3775 MN would set the lifetime to zero as per 3775:

           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.

To which the 3775bis/Vijay HA would deregister the binding as per the text proposed by Vijay:

2) 3775bis/Vijay MN against 3775 HA
-----------------------------------

The 3775bis/Vijay MN would set the lifetime to zero as per 3775bis unmodified compared to 3775:

           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.

To which the 3775 HA would deregister the binding as per 3775:

   o  If the Lifetime specified in the Binding Update is nonzero and the
      specified care-of address is not equal to the home address for the
      binding, then this is a request to cache a binding for the home
      address.  If the Home Registration (H) bit is set in the Binding
      Update, the Binding Update is processed according to the procedure
      specified in Section 10.3.1; otherwise, it is processed according
      to the procedure specified in Section 9.5.2.

So it seems we do not have backward incompatible changes.

In any case this is the only issue that holds 3775bis in the WG, were it closed we could ship it to IESG. Vijay proposed text about 3 weeks ago, and this issue has been discussed many, many times. 

Everybody: if you have opinions, please speak up, now is the time to conclude!

--julien

> From: [email-masked] [mailto:[email-masked]] On Behalf Of
> Alexandru Petrescu
> Sent: Wednesday, June 02, 2010 2:28 AM
> To: [email-masked]
> Vijay ASAP -- we need to move forward with publication of RFC3775 bis.
> >
> > --julien
> >

---

From: Ahmad Muhanna <[email-masked]>
Date: Wed, 2 Jun 2010 14:54:23 -0400

Hi, Julien,

I believe Vijay meant to say the following text is NOT backward compatible; NO? 

"

"

Currently, if RFC3775 compliant receiving node receives a BU with the specified care-of address matches the home address for the binding, RFC3775 compliant node will delete the binding while RFC3775bis compliant receiving node will REJECT the BU with a new code "Invalid Care-of Address"   

Regards,
Ahmad

> From: [email-masked] [mailto:[email-masked]] On 
> Behalf Of Laganier, Julien
> Sent: Wednesday, June 02, 2010 10:43 AM
> To: Alexandru Petrescu; [email-masked]
> Subject: Re: [MEXT] CoA==HoA test (Was: Re: Document Shepherd 
> review of draft-ietf-mext-rfc3775bis-05)
> 
> Alex, all,
> 
> In any case this is the only issue that holds 3775bis in the 
> WG, were it closed we could ship it to IESG. Vijay proposed 
> text about 3 weeks ago, and this issue has been discussed 
> many, many times. 
> 
> > From: [email-masked] [mailto:[email-masked]] 
> On Behalf 
> > Of Alexandru Petrescu
> > >> Cc: [email-masked]; [email-masked]; 
> > >> draft-ietf- [email-masked]; 
> [email-masked]; 
> > >> [email-masked]
> > >>    If the Lifetime specified in the Binding Update is 
> not zero and
> > if

---

From: Alexandru Petrescu <[email-masked]>
Date: Wed, 02 Jun 2010 21:43:27 +0200

Le 02/06/2010 17:42, Laganier, Julien a écrit :
> Alex, all,
>
> I am not sure why Vijay's change would be backward incompatible.

Julien - as I read Vijay it says a new Status Code is TBA in a BAck.
It's this Status Code bothering me a bit.

It's partly in your case (1) described below, but with MN sending BU
HoA==CoA and lifetime nonzero.

What would a 3775 MN do upon reception of the 3775bis Status Code from a
3775bis HA?

Moreover 3775bis suggested text seem to say "receiving node" and not HA
explicitly - so what happens when 3775 MN and 3775bis MN talk this new
Status Code?

3775 doesn't seem to say what happens when MN receives an unknown Status
Code in BAck... in my reading of section 11.7.3 of 3775... which may
mean MN 3775 implementations deal strangely with unknown Status Codes...
some things may break.

It's just a question, I haven't tried, and I may read something wrong.
And yes, I haven't followed the CoA==HoA discussion closely.  Just to
say that the backward compatibility issue may be important.

Alex

> There are two cases:
> 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.
>
> this is a request to delete the cached binding for the home address.
>
> 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.
>
> specified in Section 10.3.1; otherwise, it is processed according to
> the procedure specified in Section 9.5.2.
>
> In any case this is the only issue that holds 3775bis in the WG,
> were it closed we could ship it to IESG. Vijay proposed text about 3
> weeks ago, and this issue has been discussed many, many times.
>
>> -----Original Message----- From: [email-masked]
>> [mailto:[email-masked]] On Behalf Of Alexandru Petrescu
>> Sent: Wednesday, June 02, 2010 2:28 AM To: [email-masked] Subject:
>> Re: [MEXT] CoA==HoA test (Was: Re: Document Shepherd review of
>> Vijay says the change is not backward compatible... so is this
>> still a bis draft?
>>
>> Alex
>>
>>>> -----Original Message----- From: Devarapalli, Vijay
>>>> [mailto:[email-masked]] Sent: Wednesday, May 12, 2010
>>>> 12:05 PM To: Laganier, Julien; Perkins, Charles Cc:
>>>> [email-masked]; [email-masked];
>>>> [email-masked]; [email-masked] Subject: Re: [MEXT]
>>>> CoA==HoA test (Was: Re: Document Shepherd review
>> of
>>>> o  If the Lifetime specified in the Binding Update is zero,
>>>> then this is a request to delete the cached binding for the
>>>> home address.
>>>>
>>>> If the Lifetime specified in the Binding Update is not zero
>>>> and
>> if
>>>> So I defined a new one. FYI, this change is not backward
>>>> compatible.
>>>>
>>>> Vijay
>>>>
>>>>
>>>>>> On 5/4/10 10:38 AM, "ext Laganier,
>>>>>> Julien"<[email-masked]> wrote:
>>>>>>
>>>>>>> Folks,
>>>>>>>
>>>>>>> Laganier, Julien wrote:
>>>>>>>>
>>>>>> From 3775 only perspective: Isnt the case of an MN sending
>>>>>> a BU with HoA==CoA and lifetime!=0
>> an
>>>>>> anomaly? However it would help if the MN received an error
>>>>>> response from
>> the
>>>> HA
>>> _______________________________________________ MEXT mailing list
>>> [email-masked] https://www.ietf.org/mailman/listinfo/mext
>>>
>>
>>
>> _______________________________________________ MEXT mailing list
>> [email-masked] https://www.ietf.org/mailman/listinfo/mext
>

---

From: "Charles E. Perkins" <[email-masked]>
Date: Wed, 02 Jun 2010 13:48:52 -0700

Hello Vijay,

I'm basically O.K. with this, but...

>        this is a request to delete the cached binding for the home

O.K.

>    Acknowledgement with status code TBA (Invalid Care-of Address).

I'd rather have "SHOULD" instead of "MUST".  In case the receiving
node is the home agent, and if it is more efficient to have a binding
where the care-of address is the same as the home address, then
we should not mandate that an implementation is prohibited from
taking advantage of the extra efficiency.

> And add the following to the IANA considerations section under "Status Code".
>
> So I defined a new one.  FYI, this change is not backward compatible.

Since it's greater than 128, the mobile node has to take
action appropriate for rejection of its Binding Update.
To that extent, it is backward compatible.  And it seems to
me that we couldn't expect much more from mobile nodes
that would be unaware of the meaning of the rejection.

Regards,
Charlie P.

---

From: Ahmad Muhanna <[email-masked]>
Date: Wed, 2 Jun 2010 17:02:39 -0400

Hello Charlie,
Please see one comment below.

Regards,
Ahmad
> me that we couldn't expect much more from mobile nodes that 
> would be unaware of the meaning of the rejection.
[Ahmad]

Another way of looking at it: the mobile node sends the BU to de-register its binding and instead of getting a successful BA it receives an indication of rejection; fine. The mobile node should understand that is a rejection but, IMO, there is still an outstanding valid question: what the MN should consider that has happened at this time? 

Its binding has been deregistered and the HA (for example) stopped defending its Home address? Or should the mobile node keep trying until it gets a successful BA?

I personally have no problem with the proposal, but IMO, I agree with Vijay; it is still not a backward compatible one.

Regards,
Ahmad

---

From: "Devarapalli, Vijay" <[email-masked]>
Date: Wed, 2 Jun 2010 16:06:02 -0500

Hi Charlie,

> taking advantage of the extra efficiency.

A home binding is invalid as far as 3775 is concerned. So I believe "MUST" is the right keyword. If a home binding needs to be created, it would be better if there is something (a flag for example) in the Binding Update that indicates it is a home binding. And this would be an extension to Mobile IPv6 and override the MUST in 3775bis. 

Vijay

---

From: "Charles E. Perkins" <[email-masked]>
Date: Wed, 02 Jun 2010 14:18:15 -0700

Hello Vijay,

On 6/2/2010 2:06 PM, Devarapalli, Vijay wrote:

>A home binding is invalid as far as 3775 is concerned. So I believe
> "MUST" is the right keyword. If a home binding needs to be created,
> it would be better if there is something (a flag for example) in the
> Binding Update that indicates it is a home binding. And this would
> be an extension to Mobile IPv6 and override the MUST in 3775bis.

As I understand it, "MUST" means "required for interoperability
or correct protocol operation".  This isn't measured by whether
or not exactly the same thing happens.  In the case that I described,
the design of the system would insure correctness of course in the
presence of such a binding cache entry.

Making a new Internet Draft to change a "MUST" to a "SHOULD"
seems wrong to me, especially in this case where there isn't
any concern for interoperability.

Regards,
Charlie P.

---

From: "Charles E. Perkins" <[email-masked]>
Date: Wed, 02 Jun 2010 14:23:39 -0700

> [Ahmad]
> Another way of looking at it: the mobile node sends the BU to de-register
> its binding and instead of getting a successful BA it receives an indication
> of rejection; fine. The mobile node should understand that is a rejection
> but, IMO, there is still an outstanding valid question: what the MN should
> consider that has happened at this time?
>
> Its binding has been deregistered and the HA (for example) stopped
> defending its Home address? Or should the mobile node keep trying
> until it gets a successful BA?

This is a good point. Looked at in the larger scheme of things,
it means that we do not have a way of adding new status codes
without breaking backward compatibility.  That seems wrong to me.
Shouldn't we have some language that tells mobile nodes how to
react when receiving an with unrecognized error code?  For instance,
we might specify that the mobile node cannot retransmit the Binding
Update in response to an unrecognized code.

Regards,
Charlie P.

---

From: Ahmad Muhanna <[email-masked]>
Date: Wed, 2 Jun 2010 17:50:19 -0400

> From: Charles E. Perkins [mailto:[email-masked]] 
> Sent: Wednesday, June 02, 2010 4:24 PM
> To: Ahmad Muhanna
> Cc: Devarapalli, Vijay; [email-masked]
> review ofdraft-ietf-mext-rfc3775bis-05)
> 
> >> Since it's greater than 128, the mobile node has to take action 
> >> appropriate for rejection of its Binding Update.
> >> To that extent, it is backward compatible.  And it seems 
> to me that 
> >> we couldn't expect much more from mobile nodes that would 
> be unaware 
> >> of the meaning of the rejection.
> 
> > [Ahmad]
> > Another way of looking at it: the mobile node sends the BU to 
> > de-register its binding and instead of getting a successful BA it 
> > receives an indication of rejection; fine. The mobile node should 
> > understand that is a rejection but, IMO, there is still an 
> outstanding 
> > valid question: what the MN should consider that has 
> happened at this time?
> >
> This is a good point. Looked at in the larger scheme of 
> things, it means that we do not have a way of adding new 
> status codes without breaking backward compatibility.  That 
> seems wrong to me.
> Shouldn't we have some language that tells mobile nodes how 
> to react when receiving an with unrecognized error code?  

[Ahmad]
I do not think the problem here is adding a new error code. IMO, the problem is in changing the logic.

RFC3775 considers and assumes if the mobile node is able to send a BU with the source IP address is identical to its HoA and for the HA to receive this BU, the mobile node MUST be on its home link and the HA CAN de-register the mobile node binding and stop defending the HoA.

However, now, we are trying to change that logic and make it not acceptable. 

Regards,
Ahmad

> For 
> instance, we might specify that the mobile node cannot 
> retransmit the Binding Update in response to an unrecognized code.
> 
> Regards,
> Charlie P.
>

---

From: "Laganier, Julien" <[email-masked]>
Date: Thu, 3 Jun 2010 14:44:05 -0700

Hello Ahmad,

> Ahmad Muhanna
> Sent: Wednesday, June 02, 2010 2:50 PM
> To: Charles E. Perkins
> Cc: [email-masked]
> ofdraft-ietf-mext-rfc3775bis-05)
> 
> RFC3775 considers and assumes if the mobile node is able to send a BU
> with the source IP address is identical to its HoA and for the HA to
> receive this BU, the mobile node MUST be on its home link and the HA
> CAN de-register the mobile node binding and stop defending the HoA.
> 

The text Vijay sent only applies when a BU is sent with HoA==CoA and lifetime !=0. However an RFC 3775 MUST set the lifetime to zero when sending a de-registration BU, thus the text that Vijay sent does not impact an RFC 3775 MN sending a de-registration BU.

--julien

---

From: Ahmad Muhanna <[email-masked]>
Date: Thu, 3 Jun 2010 18:28:09 -0400

Hi, Julien,
I am not very eager to keep arguing this point :-)

Regards,
Ahmad
> > I do not think the problem here is adding a new error code. 
> IMO, the 
> > problem is in changing the logic.
> > 
> The text Vijay sent only applies when a BU is sent with 
> HoA==CoA and lifetime !=0. However an RFC 3775 MUST set the 
> lifetime to zero when sending a de-registration BU, thus the 
> text that Vijay sent does not impact an RFC 3775 MN sending a 
> de-registration BU.
[Ahmad]
Is there any text in RFC3775 which mandates the mobile node to set the lifetime to zero when it would like to delete its HoA binding?

The closest I came across is the following:
"
(Note that while the senders are required to set both the
   Lifetime field to 0 and the care-of address equal to the home
   address, Section 9.5.1 rules for receivers are more liberal, and
   interpret either condition as a deletion.)
"

If the above can be interpreted as a requirement on RFC3775 mobile node, i.e., RFC3775 mobile node "MUST" set the lifetime to zero, then that is fine.

Regards,
Ahmad

---

From: "Laganier, Julien" <[email-masked]>
Date: Thu, 3 Jun 2010 16:14:48 -0700

Hi Ahmad,

> I am not very eager to keep arguing this point :-)

Me neither, actually :-) Just trying to reach closure and ship 3775bis.
 
> Please see one comment below.

Please see my comment below as well.

> Is there any text in RFC3775 which mandates the mobile node to set the
> lifetime to zero when it would like to delete its HoA binding?
> 
> If the above can be interpreted as a requirement on RFC3775 mobile node,
> i.e., RFC3775 mobile node "MUST" set the lifetime to zero, then that is
> fine.

>From my reading of RFC 2119, "MUST" and "REQUIRED" are the same, thus I believe we are fine:

    1. MUST   This word, or the terms "REQUIRED" or "SHALL", mean that the
       definition is an absolute requirement of the specification.

Best,

--julien

---

From: Alexandru Petrescu <[email-masked]>
Date: Fri, 04 Jun 2010 16:38:47 +0200

Le 04/06/2010 01:14, Laganier, Julien a écrit :
> Hi Ahmad,
>
> Ahmad Muhanna wrote:
>>
>> Hi, Julien, I am not very eager to keep arguing this point :-)
>

Additional useful thing before shipping - was there some implementation
echo of this particular Status Code?

Alex

>>>> [Ahmad] I do not think the problem here is adding a new error
>>>> code.
>>> IMO, the
>>> The text Vijay sent only applies when a BU is sent with HoA==CoA
>>> and lifetime !=0. However an RFC 3775 MUST set the lifetime to
>>> zero when sending a de-registration BU, thus the text that Vijay
>>> sent does not impact an RFC 3775 MN sending a de-registration
>>> BU.
>> [Ahmad] Is there any text in RFC3775 which mandates the mobile node
>> to set the lifetime to zero when it would like to delete its HoA
>> binding?
>>
>> The closest I came across is the following: " (Note that while the
>> senders are required to set both the Lifetime field to 0 and the
>> care-of address equal to the home address, Section 9.5.1 rules for
>> receivers are more liberal, and interpret either condition as a
>> deletion.) "
>>
>> If the above can be interpreted as a requirement on RFC3775 mobile
>> node, i.e., RFC3775 mobile node "MUST" set the lifetime to zero,
>> then that is fine.
>
> 1. MUST   This word, or the terms "REQUIRED" or "SHALL", mean that
> the definition is an absolute requirement of the specification.
>
> Best,
>
> --julien _______________________________________________ MEXT mailing
> list [email-masked] https://www.ietf.org/mailman/listinfo/mext
>

---

From: "Laganier, Julien" <[email-masked]>
Date: Thu, 10 Jun 2010 14:41:42 -0700

Folks,

Regarding the CoA == HoA discussion so far we've reached the following two conclusions:

1- BU lifetime set to zero is the only condition for the HA to delete a binding.

2- BU lifetime != 0 and CoA == HoA is treated as an error by the HA and new status code is sent back as a result -- it does not introduce backwards compatibility as we discussed earlier with Ahmad and others.

Now -- Ahmad's quote of Section 6.1.7. "Binding Update Message" (copied below for convenience) triggered me to look at it in more details. I've found out that a BU  requesting deletion of a binding MUST have lifetime set to zero AND CoA set equals to HoA. That seems to be disconnected with what we've decided above. It seems to me that reference to CoA being set equal to HoA for the purpose of deregistration should be removed from Section 6.1.7. (and from the rest of 3775bis if there are others.) 

What do people think?

Excerpt of 6.1.7 below:

   Lifetime

      16-bit unsigned integer.  The number of time units remaining
>     before the binding MUST be considered expired.  A value of zero
>     indicates that the Binding Cache entry for the mobile node MUST be
>     deleted.  (In this case the specified care-of address MUST also be
>     set equal to the home address.)  One time unit is 4 seconds.

[...]

   The care-of address is specified either by the Source Address field
   in the IPv6 header or by the Alternate Care-of Address option, if
   present.  The care-of address MUST be a unicast routable address.
   IPv6 Source Address MUST be a topologically correct source address.
   Binding Updates for a care-of address which is not a unicast routable
   address MUST be silently discarded.  Similarly, the Binding Update
   MUST be silently discarded if the care-of address appears as a home
   address in an existing Binding Cache entry, with its current location
   creating a circular reference back to the home address specified in
   the Binding Update (possibly through additional entries).

>  The deletion of a binding can be indicated by setting the Lifetime
>  field to 0 and by setting the care-of address equal to the home
>  address.  In deletion, the generation of the binding management key
>  depends exclusively on the home keygen token, as explained in
>  Section 5.2.5.  (Note that while the senders are required to set both
>  the Lifetime field to 0 and the care-of address equal to the home

--julien

> > > > IMO, the problem is in changing the logic.
> > > >
> > > > RFC3775 considers and assumes if the mobile node is able to
> > > > send a BU with the source IP address is identical to its HoA and for
> > > > the HA to receive this BU, the mobile node MUST be on its home link
> > > > and the HA CAN de-register the mobile node binding and stop defending the
> > > > HoA.
> > > >
> > Is there any text in RFC3775 which mandates the mobile node to set
> > the lifetime to zero when it would like to delete its HoA binding?
> >
> > node, i.e., RFC3775 mobile node "MUST" set the lifetime to zero, then that
> > is fine.
>

---

From: "Charles E. Perkins" <[email-masked]>
Date: Mon, 14 Jun 2010 12:31:33 -0700

Hello Ahmad,

Microscopic point below:

On 6/3/2010 3:28 PM, Ahmad Muhanna wrote:

> If the above can be interpreted as a requirement on
> RFC3775 mobile node, i.e., RFC3775 mobile node "MUST"
> set the lifetime to zero, then that is fine.

I reckon this means I should change "required"
to be "REQUIRED".

Regards,
Charlie P.

---

From: "Charles E. Perkins" <[email-masked]>
Date: Mon, 14 Jun 2010 13:09:38 -0700

On 6/10/2010 2:41 PM, Laganier, Julien wrote:

> 2- BU lifetime != 0 and CoA == HoA is treated as an error by the HA
>    and new status code is sent back as a result -- it does not introduce
>    backwards compatibility as we discussed earlier with Ahmad and others.

O.K.  Do you want to specify whether or not receiving a BAck
with an unrecognized error code requires the mobile node to
terminate its registration and NOT re-send the same
deregistration message again?

> Now -- Ahmad's quote of Section 6.1.7. "Binding Update Message"
> (copied below for convenience) triggered me to look at it in more
> details. I've found out that a BU  requesting deletion of a binding
> MUST have lifetime set to zero AND CoA set equals to HoA. That
> seems to be disconnected with what we've decided above. It seems
> to me that reference to CoA being set equal to HoA for the purpose
> of deregistration should be removed from Section 6.1.7. (and from
> the rest of 3775bis if there are others.)
>
> What do people think?

This is fine with me.

>>      set equal to the home address.)  One time unit is 4 seconds.

This would become:

     16-bit unsigned integer.  The number of time units remaining
     before the binding MUST be considered expired.  A value of zero
     indicates that the Binding Cache entry for the mobile node MUST be
     deleted.  One time unit is 4 seconds.

>    the Binding Update (possibly through additional entries).

This would become:

    address MUST be silently discarded.

>   interpret either condition as a deletion.)

This would become:

    The deletion of a binding MUST be indicated by setting the Lifetime
    field to 0.  In deletion, the generation of the binding management
    key depends exclusively on the home keygen token, as explained in
    Section 5.2.5.

Regards,
Charlie P.

---

From: Ahmad Muhanna <[email-masked]>
Date: Mon, 14 Jun 2010 19:54:57 -0400

Thanks Charlie.
That should be good.

Regards,
Ahmad 
> Sent: Monday, June 14, 2010 2:32 PM
> To: Ahmad Muhanna
> Cc: [email-masked]
> >     interpret either condition as a deletion.) "
> >

---

From: "Laganier, Julien" <[email-masked]>
Date: Tue, 15 Jun 2010 16:48:55 -0700

Hi Charlie,

Charles E. Perkins wrote:
> >    and new status code is sent back as a result -- it does not
> >    introduce backwards compatibility as we discussed earlier with 
> >    Ahmad and others.
> 

In general if sending a message results in an error, presumably resending the same message will also result in an error so there's seem to be little point in doing so.

In this specific case, if what you're concerned with is backward compatibility I am not sure there's much we can/need to do... A pre-rfc3775bis that wanted to deregister was supposed to set both the lifetime to zero and the CoA equals to the HoA, so it wouldn't trigger this error code. If we were to add new text to 3775bis to cover the unknown error code case, this still wouldn't be implemented by pre-rfc3775bis and wouldn't help. But maybe I'm missing your concern?

> > the rest of 3775bis if there are others.)

Ok.
 
>      deleted.  One time unit is 4 seconds.

Looks good.
 
> >    creating a circular reference back to the home address specified
> >    in the Binding Update (possibly through additional entries).
> 
> This would become:
> 
>     Binding Updates for a care-of address which is not a unicast
>     routable address MUST be silently discarded.

Looks good.
 
> >   Section 5.2.5.  (Note that while the senders are required to set
> >   both the Lifetime field to 0 and the care-of address equal to the home

Looks good.

Thanks,

--julien