Subject: [Mip6] Re: [Mipshop] larger options

From: Christian Vogt <[email-masked]>
Date: Wed, 19 Oct 2005 15:41:53 +0200

>> PS: a way to fix it: mark size 255 as oversized option: the real 
>> length is in the two next octets.
>> 
> I don't like this very much, because current code would be unable to
> skip it.

All Mobile IPv6 variants should have incorporated mechanisms to
determine that all parties involved do in fact support the variant.

Furthermore, it would be possible to require in the variant's
specification that oversize options must be supported.

These things said, and given that standard Mobile IPv6 does not use
options of size 255, defining option length 255 to indicate oversize
would be possible, too, existing implementations notwithstanding.

Nonetheless, I do like option concatenation.  It seems to be the only
feasible approach for Mobile IPv6 variants which are unable to determine
in advance that both peers provide the required support.

If I was asked to give a statement on this, I'd say:  Write a document
for oversize options, but leave it to the discretion of Mobile IPv6
variants whether they depend on that oversize document or use option
concatenation instead.

- Christian

-- 
Christian Vogt, Institute of Telematics, University of Karlsruhe
www.tm.uka.de/~chvogt/pubkey/

Jari Arkko wrote:
> Francis Dupont wrote:
> 
>> PS: a way to fix it: mark size 255 as oversized option: the real 
>> length is in the two next octets.
>> 
>> 
> I don't like this very much, because current code would be unable to
> skip it.
> 
>> Another way: use the first bit (length > 127) as oversized option: 
>> length field is extended to two octets and the real length is taken
>> from them with the first bit masked...
>> 
>> 
> See above. And Greg Daley wrote:
> 
>> How about the length in the IPv6 header describes the length of the
>>  entire packet including extended options.  Mobility header length
>> value describes the length of the mobility header with the original
>> option sizes and format.  This aggregated length defined in the MH
>> may be smaller than the total packet size (even counting preceding
>> headers).
>> 
>> An identifier would have to be carried in the mobility header
>> indicating that following the exlicit length in the MH are
>> "extended" mobility options.
> 
> 
> This seems a bit complicated, but I got one idea from this (more
> below).
> 
>> For example the next header=[MH|None], length =residual length of
>> the message.
>> 
>> The second MH could only have Extended length options (except pad?)
>> 
>> 
>> I'm not sure if overloading the MH protocol number is too evil.  In
>> that case, there would have to be an allocation of a new protocol
>> number, and an admission of the problem to IANA...
> 
> 
> Overloading is usually not so good.
> 
> Additional ideas:
> 
> o    The truly long options are rare, there's likely just one (cga). 
> Having a rule in the spec that needs this to concatenate the option
> in question if it appears multiple times would be possible. That is,
> you add, say, four options to carry the lengthy data: 
> optionX(...)optionX(...)optionX(...)optionX(...)
> 
> o    Negotiation. The things are likely to need this are probably 
> going to exchange some other packets prior to this, so you might send
> a negotiation option and get another back to confirm that the peer
> supports an extended format. Then you could send your real data by
> setting a flag in the header, and all options would use a new format
> that uses two byte length field for all options.
> 
> Not sure how good these are either. My current gut feeling is that 
> I'd go for the option concatenation.
> 
> --Jari

_______________________________________________
Mip6 mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/mip6

---

From: Francis Dupont <[email-masked]>
Date: Sat, 22 Oct 2005 10:51:21 +0200

In your previous mail you wrote:

   > optionX(...)optionX(...)optionX(...)optionX(...)
   
I can't see a good reason to reopen the issue as the solution works
and needs no new document.

Regards

[email-masked]