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. 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. > > 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. 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 don't think it is good to solve the router-to-router and host-to-router/server/agent exchanges with the same approach. > 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 :) 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. > 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. Regards, Vidya > Henrik > > _______________________________________________ > Int-area mailing list > [email protected] > https://www1.ietf.org/mailman/listinfo/int-area > _______________________________________________ Int-area mailing list [email protected] https://www1.ietf.org/mailman/listinfo/int-area
