Subject: [mobile-ip] parameters in draft v16

From: George Tsirtsis <[email-masked]>
Date: Wed, 3 Apr 2002 17:12:20 -0500

All,

During a review of the MIPv6 draft v16 we noticed the following issue with
the Parameters defined for various messages like BR and BU. The spec states
that:
                             "...The receiver [of a Parameter] MUST
         ignore and skip any parameters which it does not understand..."
and this is repeated for every instance of the field "Parameter".

Given the hope that MIPv6 will be with us for considerable time :-) we were
wondering if something better can be done for future compatibility. The
current spec only allows for skippable parameters. Wouldn't be useful to
also allow for non-skippable parameters? Since "parameters" are TLVs, one
could set aside 'Type' space for non-skippable parameters. If one of the
non-skippable parameters is received but not recognized the receiver should
send an error code indicating "unknown parameter".

Is this something that has been considered before ...and maybe rejected?
reasons?

Thanks
George (and Matt, Vince, Scott)

---

From: Jari Arkko <[email-masked]>
Date: Thu, 04 Apr 2002 00:33:27 +0300

> send an error code indicating "unknown parameter".

Ah, the 'M' bit familiar to us from a number of other protocols ;-)

It's possible. I'm not sure if it's worth it though. Exactly what
will we lose if we don't have that possibility?

On a related note, I have been wondering whether the flag field
rules are correct. The receiver MUST ignore unknown flags. This
might be fine on [HC]oT{,} if we assume that at that stage the
peers learn about the capabilities of the other side, but what
about the Binding Update? What if, say, a new algorithm needed
to be implemented instead of SHA1, how can we ensure the other
side uses it. At [HC]oT{,} stage, the peers would presumably learn
that the other side supports this new algorithm, and then they
would just use it on the BU, and set the corresponding bit. The
other side would be sure to understand the bit since it set the bit
itself earlier in another message. However, what about BUs to the
home?

Anyway, the 'M' bit approach for parameters has also some
concerns, one of them being the possibility that vendors
"lock in" peers to use the same vendors since a vendor-specific
parameter would have the 'M' bit on. But perhaps this can be
handled by the IETF not allocating any parameter type codes
with the 'M' bit on without a very general purpose use.

Jari