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

From: "Charles E. Perkins" <[email-masked]>
Date: Tue, 26 May 2009 10:19:30 -0700

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.

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.

=============================================

Please submit comments on the above discussion and proposal.
If consensus is reached soon, I will incorporate the consensus
text in a revision of rfc3775bis to be released before the next
IETF.

Regards,
Charlie P.

---

From: Brian Haley <[email-masked]>
Date: Tue, 26 May 2009 23:37:35 -0400

Hi Charlie,

I might as well comment on all three of these :)

> discussion about the third of the three points.

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.

> 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

---

From: Fabian Mauchle <[email-masked]>
Date: Wed, 27 May 2009 10:37:37 +0200

-----Ursprüngliche Nachricht-----
Von: [email-masked] [mailto:[email-masked]] 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,

> discussion about the third of the three points.

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.

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

Fabian

---

From: Brian Haley <[email-masked]>
Date: Wed, 27 May 2009 14:23:27 -0400

> reporter can explain this issue better?

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?

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

> - According to 11.3.6, the MN should now use the Tunnel, which is still

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

-Brian

---

From: Fabian Mauchle <[email-masked]>
Date: Thu, 28 May 2009 09:07:52 +0200

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

> reporter can explain this issue better?

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.

> - According to 11.3.6, the MN should now use the Tunnel, which is still

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

---

From: Brian Haley <[email-masked]>
Date: Thu, 28 May 2009 11:10:55 -0400

> attempt this direct communication?

Yes, I almost forgot about that paragraph in Section 10.4.2, direct
communication between the MN and HA doesn't seem to be explained in the same
manner, it's kind-of just inferred from Section 11.1.

I would guess that no forward progress is being made would be the way?

Either way, I didn't have any problem inserting this text, I was just curious
about the details.  Section 10.4.2 provides the reason.

Thanks,

-Brian