Subject: Re: [mobile-ip] Unresolved issue #16: unrecognized MH

From: Samita Chakrabarti <[email-masked]>
Date: Thu, 11 Apr 2002 17:23:29 -0700 (PDT)

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

The draft should also clarify that OLD IPv6 nodes (without Mobility support)
should send  'mobility header unknown' message as an indication that they don't
support CN functionality for MIPv6.

Thanks,
-Samita

---

From: Keiichi SHIMA / 島慶一 <[email-masked]>
Date: Mon, 15 Apr 2002 21:32:31 +0900 (JST)

> support CN functionality for MIPv6.

What is 'mobility header unknown'?

I think the old IPv6 node need not to be modified.  They will send
'ICMPv6 parameter problem' with 'unknown next header value' type.  We
can easily detect the node can't understand MIP6.

# modifing all old ipv6 nodes is unrealistic to me.

Instead, I propose to specify that the MN must use the bi-directional
tunneling when it receives the above error (ICMPv6 paramprob, NH)
against any of the mobility header.

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

---

From: Jari Arkko <[email-masked]>
Date: Mon, 15 Apr 2002 15:51:39 +0300

> What is 'mobility header unknown'?

One, the MH protocol could be unknown to the recipient. This
is clearly a job for ICMP.

Two, the message type field (MH Type) inside the MH could
be unknown to the recipient, perhaps due to an extension that
the recipient doesn't support. We've been discussing whether
that can be reported by ICMP, BA, or a special MH Error message.
It seems that most people think ICMP Parameter Problem can be
used. The only thing in this solution is that the receiver of the
error message must take care in looking at what octet is being
pointed to as the error.

Jari