Hi Magnus, > -----Original Message----- > From: Magnus Westerlund [mailto:[EMAIL PROTECTED] > Sent: Tuesday, February 20, 2007 2:41 AM > To: Narayanan, Vidya > Cc: Henrik Levkowetz; Internet Area > Subject: Re: [Int-area] Lifting up a filter discussion from Monami6 > > Narayanan, Vidya skrev: > >> > > > >>From RFC2460: > > > > " The Unfragmentable Part consists of the IPv6 header plus any > > extension headers that must be processed by nodes en > route to the > > destination, that is, all headers up to and including > the Routing > > header if present, else the Hop-by-Hop Options header > if present, > > else no extension headers. > > > > The Fragmentable Part consists of the rest of the > packet, that is, > > any extension headers that need be processed only by the final > > destination node(s), plus the upper-layer header and data." > > > > > > The extension header under discussion here is only to be > processed by > > the final destination node and hence, falls under the Fragmentable > > Part > > - so, size is not an issue. > > > > From a transport perspective I don't like seeing such > sweeping statements that "size is not an issue". If you cause > fragmentation of the packets by adding an extension header > then you do effect the packet loss probabilities for the > packet to reach the destination in a complete form. > > Also if you know what the destination is, why not use a real > transport protocol instead of reinventing the transport > functionality you need inside the extension header. As I > don't fully understand the requirements here I will not be to > specific. But unless there is some real hard requirement why > you need to place this exchange in the extension header, I > would recommend using a transport protocol for the transport. > It probably also makes the development of the security > solution easier as there are more ready to use options on the > transport layer. >
There are a couple of problems here. First, if UDP is going to be the choice of transport protocol, reliability is still an issue. Next, the following are additional considerations: * While it is feasible to decouple the filter rule exchange from handoff times, in a mobile environment, the mapping of a particular filter rule to an IP address or interface must be communicated during handoff. Even if a standalone protocol is used to exchange filter rules, this mapping must be conveyed in each specific protocol to minimize handoff signaling and delay. * The above leads to the fact that different security solutions are then needed to secure the filter exchange and the actual mappings - the latter can use the security solution in place for the mobility management protocol, while the former needs its own solution. 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). Regards, Vidya > Cheers > > Magnus Westerlund > > IETF Transport Area Director & TSVWG Chair > ---------------------------------------------------------------------- > Multimedia Technologies, Ericsson Research EAB/TVA/A > ---------------------------------------------------------------------- > Ericsson AB | Phone +46 8 4048287 > Torshamsgatan 23 | Fax +46 8 7575550 > S-164 80 Stockholm, Sweden | mailto: [EMAIL PROTECTED] > ---------------------------------------------------------------------- > _______________________________________________ Int-area mailing list [email protected] https://www1.ietf.org/mailman/listinfo/int-area
