on 2007-02-15 04:57 Narayanan, Vidya said the following:
> Hi Henrik,
> Sorry, due to some intermittent connectivity issues, it turned out that
> even though my application had sent the email before receiving the other
> responses, it was actually only sent out later.
>
>> -----Original Message-----
>> From: Henrik Levkowetz [mailto:[EMAIL PROTECTED]
>> Sent: Wednesday, February 14, 2007 3:09 PM
>> To: Internet Area
>> Subject: Re: [Int-area] Lifting up a filter discussion from Monami6
>>
>>
>> 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 went through your other email. I see that there may be little
> correlation between filter rule updates and the time of handover in one
> model of doing this. In other words, I think you are referring to a
> model where there a bunch of rules set up in advance, say, with an ID
> that maps to each rule and upon handoffs, it is the mapping of those IDs
> to interfaces or IP addresses that needs to happen and not the actual
> setting up or update of the rules itself. The rules could be updated at
> any time (and perhaps somewhat infrequently), while the
> rule-to-interface mapping is rather dynamic.
Yes.
> I can subscribe to that
> notion, although, the question I then have is whether we need to have a
> certain protocol to set up the rules and other protocols to do the
> rule-to-interface mapping. Having a separate protocol that sets up the
> filter rules and updates the mapping would lead to the problem of having
> to run that protocol separately at the time of handoff to update the
> mapping. More notes below.
This isn't a problem, it's what you want to do. You want to de-couple
these two actions in time. And that does not force you to define two
different protocols for it, although if there is some advantage to doing
so, as seems to be the case for monami6/mip6, you certainly can do so.
You probably should read the monami6 documents covering this if you're
not familiar with them, to show an example both of how and why this
could be the case.
>> > 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.
>>
>
> No, that was a terminology issue - I was still referring to filter rules
> exchange as well.
>
>> 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.
>>
>
> We have to scope the problem here. As to what Monami6 is chartered to
> solve, it is only the flow/binding policies exchange to/from the MN/MR
> to the HA, very much in the context of MIP6 (and its variants) and NEMO.
> Strictly from this perspective, tying this exchange to MIP6 signaling
> should be acceptable. However, it seems fair to see if this can be done
> a bit more generically in a way that allows this work to be useful for
> something like MOBIKE, where the same kind of end hosts may be
> participating in the exchange and the requirements and scope are quite
> similar.
?? I see no argument for placing this in an extension header here.
> However, if this were to be extended to an any-to-any policies/rules
> exchange protocol, the scope and requirements become quite different.
> That seems to fall under the scope of something that NSIS might be
> doing. For instance, if this exchange is between two routers, the
> information involved in this exchange and the timing and binding of the
> information to interfaces or addresses become very different. Handoffs
> are no longer a topic for consideration, for e.g. OTOH, batching of
> information/rules, granularity of that and even the security models are
> quite different.
?? I still don't see any argument for placing this in and extension
header here.
> I don't think it is good to solve the router-to-router and
> host-to-router/server/agent exchanges with the same approach.
Oh? Not that anyone has argued that either way, but as a general statement,
that would lead you to separate IP protocols, UDP protocols, TCP, etc.,
etc., for these exchanges. I don't thing this statement is valid or
fruitful.
>> 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 ...
>>
>
> It depends on whether this is viewed as a layer violation or cross-layer
> optimization :)
No, it doesn't.
> I'm typically not a fan of layer violation. However, in
> this case, I see the filter rules and policies as something that permits
> QoS-aware IP routing. So, I don't particularly see a problem with this,
> although I would like to hear more thoughts on this.
Even if there may be a relationship between filter rules and QoS, they
aren't the same thing, and mixing them together won't aid clear thinking.
>> 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.
>>
>
>>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.
In that case, I'd like to point out, again, that the assumption that the
filter rules would consistently be communicated to the final destination
node at the other end of your regular traffic doesn't generally hold, and
also wonder why you feel the need to use the IP extension headers as a
replacement for UDP (or TCP/SCTP/DCCP). What's the motivation?
This is a bad idea, not only from the viewpoint of layer violations, but
also from the viewpoint of not having any of the services built on top
of the transport protocols available, and from the point of view of the
implementor who can't then use the regular socket mechanism to handle
the communication of filters from one node to another.
Henrik.
_______________________________________________
Int-area mailing list
[email protected]
https://www1.ietf.org/mailman/listinfo/int-area
