> On Tue, 20 Feb 2007, Narayanan, Vidya wrote: > > The real problem here seems to be that MIP6 (and > associated protocols > > such as NEMO), for good or bad, has chosen the path of > being part of the > > IP layer rather than running at the transport layer. Since > the mapping > > of filter rules to addresses (not defining or exchanging the rules > > itself, but, the mapping) is very much part of a handoff > problem, it > > needs to be integrated with the protocol for optimal > operation during > > handoffs. One option on the table is the use of mobility > options (which > > is an option to the Mobility Header, which is also an IPv6 > extension > > header) - that would make this applicable only to the MIP6 class of > > protocols. If we want MOBIKE or Shim6 to be able to use it, I was > > suggesting looking into defining its own IPv6 extension > header, since > > that can be carried in any of these protocols (except > MOBIKE over IPv4). > > If I recall correctly, the issue of piggybacking arbitrary data on > signalling messages was deferred from MIPv6 specifications, > and hasn't > been solved in later extensions or other protocols either.
=> Correct, it was actually deliberately removed from the spec for good reasons IMO. This is > likely to bring up issues with different application PDU > sizes, PMTUD, > etc. > > Maybe filter signalling is sufficiently more restricted case of > piggybacking arbitrary data that devising framing, PMTUD, => It's not actually piggybacking in the case of MIPv6, it's part of the mobility header itself. Hesham > etc. for it > is simpler. I might agree with that if the filters were > restricted to > be (say) less than 500 bytes so that no fragmentation was never > needed. > > While solving the more general problem might be useful, it's > not clear > to me yet whether the requirements in this mobility space are strong > enough to preclude using a more generic transport protocol. > > -- > Pekka Savola "You each name yourselves king, yet the > Netcore Oy kingdom bleeds." > Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings > > _______________________________________________ > Int-area mailing list > [email protected] > https://www1.ietf.org/mailman/listinfo/int-area > _______________________________________________ Int-area mailing list [email protected] https://www1.ietf.org/mailman/listinfo/int-area
