Re: [MEXT] Issue #18 ["Home Address Option & ICMP / Binding errors"], part 3 of 3: "Receiving Binding Errors"

[Fabian Mauchle <f1mauchl at hsr.ch>]

-----Ursprüngliche Nachricht-----
Von: mext-bounces at ietf.org [mailto:mext-bounces at ietf.org] Im Auftrag von
Brian Haley
Gesendet: Mittwoch, 27. Mai 2009 20:23
An: Mauchle Fabian (f1mauchl at hsr.ch)
Cc: 'mext'
Betreff: Re: [MEXT] Issue #18 ["Home Address Option & ICMP / Binding
errors"], part 3 of 3: "Receiving Binding Errors"



Fabian Mauchle wrote:
> -----Ursprüngliche Nachricht-----
> Von: mext-bounces at ietf.org [mailto:mext-bounces at ietf.org] Im Auftrag von
> Brian Haley
> Gesendet: Mittwoch, 27. Mai 2009 05:38
> An: Charles E. Perkins
> Cc: mext
> Betreff: Re: [MEXT] Issue #18 ["Home Address Option & ICMP / Binding
> errors"], part 3 of 3: "Receiving Binding Errors"
> 
> Hi Charlie,
> 
> I might as well comment on all three of these :)
> 
> Charles E. Perkins wrote:
>> Hello folks,
>>
>> Last month, issue #18 showed up without any fanfare on the
>> issues tracker list:
>>    http://trac.tools.ietf.org/wg/mext/trac/ticket/18
>> I'd like to initiate discussion on the points raised as part
>> of issue #18.  There are three main points, which can be
>> discussed separately.  In this note, I transcribe the
>> discussion about the third of the three points.
>>
>> =============================================
>>
>> Receiving Binding Errors
>>
>> In Section 11.3.6. Receiving Binding Error Messages, it is not
>> considered that Binding Error Messages can also come from Home
>> Agents when acting as a Correspondent Node to its Mobile Nodes
>> [see also issue #12]. It is only defined that:
>>    "If the mobile node has no upper layer progress information,
>>    it MUST remove the (Binding Update List) entry (from the
>>    Correspondent Node) and route further communications through
>>    the home agent. It MAY also optionally start a return
>>    routability procedure (see Section 5.2)."
>>
>> If the Correspondent Node is the Home Agent, it is likely that
>> there is also no tunnel to route communications through. This
>> case may happen if the Home Agent reboots without a persistent
>> storage of its Binding Cache.
> 
> Will this actually ever happen?  A MN should only ever get a Binding Error
> from
> it's HA in response to a BU, which might have Status set to 2.  Otherwise,
> packets are being sent in the MN-HA tunnel, which doesn't use a HAO, which
> is
> what Status value 1 is for, which is what Section 11.3.6 is referring to.
> 
>> Proposal: If the Binding Error Message was sent by the Home Agent,
>> the Mobile Node SHOULD send a Binding Update to the Home Agent
>> according to Section 11.7.1.
> 
> I *guess* that's ok, depending on how it's inserted in this section, maybe
> the
> reporter can explain this issue better?
> 
> -Brian
> ------------------------------------------
> 
> I will try to:
> 
> - Suppose the MN has successfully bound to its HA.
> - Now the HA crashes, losing all of its Binding Cache and Tunnel
> information. This means that the Tunnel to the MN is now invalid. Any
> further packets sent thru the tunnel will be dropped at the HA.
> - The MN now starts a direct communication with the HA. (e.g. the user
pings
> the HA to check if it's alive). As the MN still has a Binding Update List
> entry with the corresponding addresses, it will add a HAO to the packet
and
> send it directly to the HA.

But wouldn't the BUL entry show that it's communicating with its HA, so it
would
use the tunnel?  There wouldn't be a HAO inserted in that case.  How will it
attempt this direct communication?
-------------------------------------------

According to Section 10.4.2 the HA acts as a correspondent node when
directly communicating with the MN. I suppose the opposite (MN sending
directly to HA) should also apply. Also the conditions for Route
Optimization (sending packets directly to the correspondent node, which is
the HA in this case) on p.109 are true for the HA BUL entry. Or is there a
rule I have overseen?




-------------------------------------------
If the MN somehow disables mobility and removes it's home binding, then it
won't
be inserting a HAO, just using basic IPv6.

> - Upon reception, the HA checks the HAO and will not find a matching
Binding
> Cache entry and return a Binding Error.
> - According to 11.3.6, the MN should now use the Tunnel, which is still
> invalid.

If the MN knows the tunnel is invalid, it should update it's binding at the
HA.

-Brian
-------------------------------------------

IF it knows. I'm not sure if the MN will recognize that the other tunnel
endpoint has failed.

Fabian