Subject: [mobile-ip] Updated unresolved issue #16: Unrecognized MH Type

From: Jari Arkko <[email-masked]>
Date: Fri, 19 Apr 2002 08:52:35 +0300

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.

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? Or should
we define the BM message as a general error message for mobility, and
define an error code for wrong MH Type? Or should we use ICMP
Parameter Problem Code 0 (erroneous header field encountered) and
pointer to MH Type to indicate problems.

Proposal: Use of the Binding Ack message does not seem appropriate as
it would be then be used in a quite different role than originally
intended. The ICMP Parameter Problem Code 0 approach is possible, but
involves a complicated decision based on looking at the reported
pointer and original packet. Such actions are typically not done
based on these messages. A new error message might be appropriate,
but then we would have two error-reporting messages, Binding Error
and Binding Missing. The proposal is therefore that the Binding
Missing message be renamed to Mobility Error, and added an error
code to indicate (1) unsupported MH Type, (2) missing binding, and
(3) any new error perhaps needed in future extensions.

---

From: Keiichi SHIMA / 島慶一 <[email-masked]>
Date: Fri, 19 Apr 2002 15:13:59 +0900 (JST)

I agree.

From: Jari Arkko <[email-masked]>
> (3) any new error perhaps needed in future extensions.

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