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

From: "Charles E. Perkins" <[email-masked]>
Date: Mon, 12 Jul 2010 13:55:43 -0700

Hello folks,

I have produced a revision for rfc3775bis:
www.psg.com/~charliep/txt/ietf78/draft-ietf-mext-rfc3775bis-06.txt

I wondered if the following point was
fully resolved...

On 6/2/2010 2:23 PM, Charles E. Perkins wrote:
> On 6/2/2010 2:02 PM, Ahmad Muhanna wrote:
>
>>> 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?
>>
>> 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.

After the discussion about new rejection codes
in the Binding Acknowledgement, I searched through
the specification to see whether or not there
was any instruction about how a mobile node
should handle unrecognized status.  There might
seem to be three choices:
1. "update", and retransmit with new Sequence Number
2. silently discard (which implicitly allows retransmission)
3. fail, and do not retransmit to the same home agent

However, since the status is "unrecognized",
no corrective action is available and so the first
option seems wrong.  Likewise, the second option
also seems wrong because retransmission would almost
certainly produce the same result.

So, I think that the specification should explicitly
prohibit retransmission when an unrecognized rejection
code is received in the Binding Acknowledgement.

Here is the existing relevant text:

>    o  If the Status field indicates that the Binding Update was rejected
>       (the Status field is greater than or equal to 128), then the
>       mobile node can take steps to correct the cause of the error and
>       retransmit the Binding Update (with a new Sequence Number value),
>       subject to the rate limiting restriction specified in
>       Section 11.8.  If this is not done or it fails, then the mobile
>       node SHOULD record in its Binding Update List that future Binding
>       Updates SHOULD NOT be sent to this destination.

The last sentence is key.  According to this, in
the case of an unrecognized status, the mobile node
SHOULD NOT resend to the same home agent.

I'd be happier with MUST NOT, for the specific
case of unrecognized status codes.  But, for now,
I will send the document without revision on this
point to the IETF directories.

If needed, I can make the additional constraint
before publication.

Comments?

Regards,
Charlie P.