> -----Original Message----- > From: Henrik Levkowetz [mailto:[EMAIL PROTECTED] > Sent: Tuesday, February 20, 2007 3:57 PM > To: Narayanan, Vidya > Cc: Pekka Savola; Internet Area > Subject: Re: [Int-area] Lifting up a filter discussion from Monami6 > > > > on 2007-02-20 23:56 Narayanan, Vidya said the following: > ... > >> 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. > >> > > > > Maybe I am missing something here, but, how does UDP help with > > fragmentation? The alternative proposed at the transport > layer seems > > to be UDP-based. > > No. Jari raised the question of whether a more general > filter definition language would be a good idea (my > paraphrasing), and you proposed that IPv6 extension headers > should be used as transport for it. Nobody else has proposed > a specific transport yet in this discussion. >
Okay. I was going with Jari's original email on this thread, in which he talked about one existing proposal of doing this over UDP. > Personally I'd support something which uses an existing > generic transport protocol, such as UDP or SCTP; with DTLS > security for instance; but I'm not too concerned with the > exact pick of such a protocol. What I'm very concerned about > is the idea of moving something which can both easily and > reasonably be carried by an existing generic transport > protocol down into IPv6 extension headers, when there's no > evidence or arguments that doing so would be particularly > sensible or beneficial. > > (Now, if somebody here had indeed proposed UDP as transport > in this discussion, I'd like to repeat something which Magnus > already hinted at, which is that it's still quite a > difference between what you can fit into a UDP package, and > what you can add in an IP header to a package which already > carries a payload, before fragmentation of that package occurs.) > > >> 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. > >> > > > > In a mobile environment, the mobile node is in the best position to > > determine the mapping of filter rules to addresses based on > currently > > available interfaces and connection conditions. This could > be fairly > > dynamic and I can see a need to exchange this upon handoff to > > communicating devices (such as the HA or VPN GW or even a CN). > > You keep ignoring the information that an analysis of the > origins of filter rule changes show them to be uncorrelated > with handover events. > I was only referring to the mapping of filter rules to addresses here, not the exchange of filter rules themselves. Vidya > > Henrik > > _______________________________________________ Int-area mailing list [email protected] https://www1.ietf.org/mailman/listinfo/int-area
