on 2007-02-14 23:20 Narayanan, Vidya said the following:
> I would be sympathetic to developing something generic that works for
> multiple protocols instead of just Mobile IP, while also keeping in mind
> the issue of mobility and latency concerns associated with that. One
> thing to take into account is that this exchange is not necessarily a
> one-time exchange and policies and filters may change over time, based
> on the current connection capabilities of an end host. In such cases,
> some of this signaling may potentially be bound to handoffs and in the
> context of Mobile IP or MOBIKE-like protocols, if this means separate
> signaling exchanges before the flow changes can happen, it could be less
> than useful.
I don't know if you read my recent post, but we've analysed this and found
that there is very little correlation (basically none) between the time
when a filter rule update is needed, and the time of handover.
> I had briefly discussed this with Dave Thaler in San Diego and we had
> talked about defining the flow information in a generic format, perhaps
> as an IPv6 extension header or as a Destination Option. If such an
> approach were to be taken, this information could then be carried in any
> protocol, which would get rid of additional signaling and latency
> concerns associated with it. So, from this point of view, a couple of
> different things would need to happen - an independent specification
> needs to define such an extension header or destination option and the
> fields that go into it; a different specification would then describe
> how this is carried in a given protocol (say, Mobile IP) and how the
> information is secured within that context.
>
> Thoughts on something like this?
First, this cannot simply be described as 'flow information', so if
that was the context of your discussion, I don't think it is quite
relevant for this discussion.
Secondly, this assumes that the filter rules would consistently be
communicated to the end host at the other end of your regular traffic,
which is an assumption that doesn't generally hold for filter rules.
Thirdly, extension headers are for optional internet-layer information
(RFC 2460), and I'm not sure this is a fair categorization of such
filter rules as we're discussing here. I don't know how much people
care about proper layering these days, though ...
Finally, although filter rules wouldn't necessarily be very large in
size, I doubt that the size constraints associated with extension
headers make it appropriate to put filter rules in an extension header.
Remember that extension headers belong to the unfragmentable part of
an IPv6 packet, so there's a variable maximum size for such a header,
(depending on the presence of other extension extension headers); it
seems as if it would create a silly size constraint for filter rules
to define their default transport to be an IPv6 extension header.
Henrik
_______________________________________________
Int-area mailing list
[email protected]
https://www1.ietf.org/mailman/listinfo/int-area
