Hello!
> and receiving; the same thing for forwarding would result in an "always
> defragment" option, which would be somewhat "un-ip6-ish" :-)
It is anti-ip4-ish with the same success. 8)
Well, I am glad to hear that someone, who is interested in mobile IPv6
understood main obstacle on the way. It is crucial progress. 8)
Honestly, I do not know any answer. Adding variable options to TCP
(and UDP etc) packets is solvable task and current pmtu discovery
can be modified to handle this. But I would prefer not to see this
inside stack though.
What's about UDP, you have to defrag on output, if you are in hurry.
In 2.5 netfilter will receive full frames, I hope, and problem will disappear.
What's about TCP, add maximal size of mobile options to ext_header_len,
when it can be mobile _potentially_. Doing MSS varying in flight is
possible (we do this with SACKs on bidirectional connections),
but I do not see much of sense to make this.
My personal opinion is that current mobile IPv6 is one big piece
of shit yet. 8)8) Piggibacking such options to data packets
introduces no advantages, but lots of troubles.
Alexey
|