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