Subject: [mobile-ip] Unresolved issue #16: Error message from an unknown MH Type

From: Jari Arkko <[email-masked]>
Date: Thu, 11 Apr 2002 21:21:18 +0300

(By the way: If there are any issues that aren't listed on the page
on the web site, please submit them to the mailing list. Solutions/text
is good to have in addition to the problem description, but not necessary.)

Background: Draft 16 states that an error should be given if an
unknown MH Type is received. This error may be necessary in terms of
diagnosing implementation problems, but it's main use is the ability
to determine that the peer does not support some new extension that
requires a new MH Type. However, draft 16 does not describe what kind
of error can be given. It isn't clear that a Binding Acknowledgement
can be used for this purpose as the error may not be given as a
response to Binding Update and there isn't an appropriate error code
yet. Furthermore, ICMP Parameter Problem does not have an error code
that matches the semantics of this error.

Question: Is this an important error to give? Should we define
a new MH Type and message called Error that would contain an
error code? Or should we use the Binding Ack message with a
new error code?

Proposal: We should just define a new error code under the Binding Ack
message, and include the reception of this message in the state
machines even when it is not a response to a Binding Update.

Text:
- 146 Unknown MH Type

---

From: Vijay Devarapalli <[email-masked]>
Date: Thu, 11 Apr 2002 13:18:37 -0700

I dont think it is a good idea overloading the Binding 
Ack. So far Binding Ack has always been sent in response 
to a BU. Now you are changing it such that, it is also 
sent when the receiving side does not recognize a 
particular MH type.

I would prefer going with the ICMP parameter prob (this
has been the normal practice whenever you dont recognize
something in the packet). Maybe define a new error code.
Or live with it, since the ICMP parameter prob also points
to the corresponding offending octet in the original packet.

Vijay

---

From: Jari Arkko <[email-masked]>
Date: Thu, 11 Apr 2002 22:46:48 +0300

> to the corresponding offending octet in the original packet.

I'd be fine with this also. RFC 2463 lists the Parameter Problem
codes:

         0 - erroneous header field encountere
         1 - unrecognized Next Header type encountered
         2 - unrecognized IPv6 option encountered

1 and 2 seem to be inappropriate. What about 0? A quick
look at the usage of code 0 on e.g. wrong routing header
type seems to match the usage here. So go for ICMP Parameter
Problem and Code 0 instead?

Jari

---

From: Vijay Devarapalli <[email-masked]>
Date: Thu, 11 Apr 2002 15:39:35 -0700

> Problem and Code 0 instead?

I wonder how much of an effort it is to define a new error code.
If it is a big pain, I am fine with what you are suggesting 
(ICMP Parameter Problem with code 0).

Vijay

---

From: Keiichi SHIMA / 島慶一 <[email-masked]>
Date: Tue, 16 Apr 2002 20:49:11 +0900 (JST)

> Problem and Code 0 instead?

I understand that returning an ICMPv6 parameter problem with type 0 is
the most generic way.  But if we do that, the MN side must chase an IP
packet included in the ICMPv6 packet to check if the parameter problem
error is caused by an unknown MH type or by some other header errors.

If we define a new MH type which indicates an error, it's very easy to
handle the error.  We need not chase the contents of the IP packet
which has caused the error.

So, I perfer all MIP6 nodes must return a MH with type X (X indicates
an error) and error code if they receive an unknown MH type.

---
Keiichi SHIMA
IIJ Research Laboratory <[email-masked]>
KAME Project <[email-masked]>