Subject: [mobile-ip] Mipv6 issue #177: ICMP error vs. silently drop

From: Jari Arkko <[email-masked]>
Date: Tue, 17 Dec 2002 15:25:43 +0200

In this issue we decided to use ICMP Parameter Problem to signal
low-level errors. We also decided to silently discard if the BAD
is bad ;-)

Here are the text changes:

Throughout the document, delete the 'Header Len field MUST be no less
than the length specified in Section 6.1.x' texts. Replace them with
the following text in 9.2:

     4. The Header Len field in the Mobility Header MUST NOT be less
        than the length specified for this particular type of message
        in Section 6.1. Otherwise, the node MUST discard the message
        and SHOULD send ICMP Parameter Problem, Code 0, to the Source
        Address of the packet [rfc 2463].

I also think that we should deal with the MH Payload Proto field in
the similar manner. So, in Section 9.2, change:

     2. The Payload Proto field MUST be IPPROTO_NONE (59 decimal).
        Otherwise, the node MUST silently discard the message.

=>

     2. The Payload Proto field MUST be IPPROTO_NONE (59 decimal).
        Otherwise, the node MUST discard the message and SHOULD send
        ICMP Parameter Problem, Code 0, to the Source Address of the
        packet [rfc 2463].

In Section 9.5.4, change

     -  If the Binding Update was silently discarded as described in
        Sections 9.5.1, a Binding Acknowledgement MUST NOT be sent.

=>

     -  If the Binding Update was discarded as described in Sections 9.2
        and 9.5.1, a Binding Acknowledgement MUST NOT be sent.

I didn't specify a rule that says 'MUST send ICMP if BAD is at
a wrong location', because (a) implementors can still do that
and (b) smart implementors will be liberal in what they accept.

Jari

---

From: Brian Haley <[email-masked]>
Date: Tue, 17 Dec 2002 10:49:39 -0500

>         ICMP Parameter Problem, Code 0, to the Source Address of the

Not to split hairs here, but should this be a Binding Error instead?
That way a MN can tell a HA/CN understands Mobility, but doesn't
support some future draft where Payload Proto can be something else.
Just a thought.

-Brian

---

From: Jari Arkko <[email-masked]>
Date: Tue, 17 Dec 2002 18:04:50 +0200

> support some future draft where Payload Proto can be something else.

Hmmm... why not. This appears to be different from the other error
cases in that it is something that might be useful to track these
errors. Whereas a bad length is just a bad length, good for debugging
to get an ICMP error but it isn't really needed for the software
itself.

Jari

---

From: Vladislav Yasevich <[email-masked]>
Date: Tue, 17 Dec 2002 11:25:18 -0500

Brian

How is this different from the unrecognized/disallowed next
header?

-vlad

-- 
++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
Vladislav Yasevich		Tru64 UNIX - IPv6 Project Lead
Hewlett Packard 		Tel: (603) 884-1079
Nashua, NH 03062		ZKO3-3/T07

---

From: Brian Haley <[email-masked]>
Date: Tue, 17 Dec 2002 15:36:09 -0500

> How is this different from the unrecognized/disallowed next

Yes, you're right, there's actually an example of this in 2463.
My mistake.

-Brian