Hello Erik,
Erik Nordmark wrote: > > The same care is going to be required for routing headers as would be > > for more general encapsulation in this regard. > > > > For routing headers, all that is required is to check that the home address > > is the next intermediate routing point after the care-of address. If these > > addresses were inserted into a longer sequence of intermediate routing > > points, the same check would be sufficient _for the purposes of Mobile IPv6_! > > The other parts of the routing path in the routing header would have to be > > checked according to the rules of whatever policy was used to build up the > > other parts of the routing path. > > I missing something: My assumed use case is that folks > want to use routing headers so that > nodes can express a routing header with R1, R2, R3, Dest > while limiting certain traffic to only express "MIPv6 routing headers" > i.e. where there is a single hop on the final destination. > In such a case which filter rules would apply on the various nodes. My understanding is that the Mobile IPv6 use of routing headers SHOULD NOT be managed in such a way as to preclude other uses. There was some discussion on the mailing list about this a couple of months ago, and consequently some revisions were made to draft ...-15 to enable more general use of the routing header. Before, there wasn't much discussion about it, but every time that the topic came up I think that the sense was to avoid usurping the use of the routing header. Compatible co-existence was more the intention. > But those checks will not disable some other general facility like routing > headers. And, neither should Mobile IPv6, according to my understanding. > Having a decapsulating node have a mechanism for various protocols > that use tunneling to specify what is acceptable to decapsulate > (so that MIPv6, configured IPv6-in-IPv6 tunnels, etc can all specify > what is acceptable) would make a lot of sense. Indeed, we could have a separate encapsulation for every application. Or, as I hope, we can carefully specify the use of the existing tools in a way to maintain their generality while still getting the particular function we need. > > In this way, no crippling of the utility of the routing header would result. > > On the other hand, I hope that my point can be understood that all such > > I missing the point. Is it clearer now? Regards, Charlie P. -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to [EMAIL PROTECTED] --------------------------------------------------------------------
