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

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

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

Yes, and the mipv6 spec should point this out.

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

Using 'ICMPv6 parameter problem' with 'unknown next header value'
from a MIPv6 CN just because it doesn't understand a new MH type
seems wrong.
And we want to allow future MIPv6 security schemes to define new MH type
values should they need to do so.

  Erik

---

From: Keiichi SHIMA / 島慶一 <[email-masked]>
Date: Wed, 17 Apr 2002 12:18:49 +0900 (JST)

> from a MIPv6 CN just because it doesn't understand a new MH type

Sorry, my wording were not clear enough...  I suggest that all MN must
use bi-directional tunneling when they receive an ICMPv6 Parameter
Problem for a mobility header from *legacy IPv6 nodes which don't
understand MIP6*.  (I guess many implementors do this, though the spec
doesn't say anything about this behavior.)

> values should they need to do so.

As I have said in another mail, I prefer a new MH type which indicates
an error.  When a *new* MIP6 MN/CN receives such a MH indicates an
error from *old* MIP6 MN/CN, they can easily fall back to the old
spec.  I think the ICMPv6 parameter problem with type 0 seems too
generic for this purpose.

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