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

From: Samita Chakrabarti <[email-masked]>
Date: Thu, 11 Apr 2002 16:32:22 -0700 (PDT)

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

Although I agree that we are overloading BA if we are to use BA to
send the error message: unknown MH type, but using ICMP Param problem
with code = 0 , does not quite carry the proper semantics of "Unknown
MH Type". 

So, the question is how important it is to know by the recepient
that it is indeed an unknown MH type  or does ICMP PARAM with code=0,
(with a pointer to the nextheader field) is enough for this purpose ?

In this context, we have a new issue to clarify here.

Question: Should a CN  implementation MUST support route optimization  ?

          (now that by default, route optimization is not mandatory
            for mobile nodes )
            
      a)  If by any chance, we decide that a CN may optionally support
          route optimization for MobileIP, then a CN which does not
          support route optimization,  MUST handle HoTI/CoTI
          messages and BU by sending an appropriate error message to MN.
          So, if we consider sending ICMP param in this case, the code 
          should be 1 (unrecognized next header) to indicate that it does
          not support RO.
          
      b) If a CN MUST support route optimization, then the spec should
         clarify that. How about adding a subsection in section 7 to
         clarify  "Requirements for IPv6 Correspondent nodes" ?

I think, it's hard for a CN to distinguish when to send 'unrecognized next
header' or 'erroneous header field' in the above cases.

Thanks,
-Samita

---

From: Samita Chakrabarti <[email-masked]>
Date: Thu, 11 Apr 2002 16:32:22 -0700 (PDT)

Thanks,
-Samita

--Shrewdness_of_Apes_839_000--

---

From: Erik Nordmark <[email-masked]>
Date: Wed, 17 Apr 2002 04:50:43 +0200 (CEST)

> 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

While this works I think it might be a source of confusion when
BA messages are sent in response to "random" MH packets.
What would the authenticator be in such a BA? Don't
implementations need to handle packets with this error code differently
than other 

Perhaps we should rename Binding Missing to be "Mobility Header Error"
and have a code for the "binding missing" as well as "unknown MH type" cases?
I think they both have similar issue in the sense that, unlike a BA,
there isn't an authenticator etc.

  Erik