From: Hugo Santos <[EMAIL PROTECTED]> Date: Sat, 29 Jul 2006 15:12:44 +0100
> - In general, lot's of places in the IPv6 stack don't take the source > address into consideration and generically only use destination as > key, i think this is a major setback that should be approached > individually. This is partly why the multiple routing table code is being added as the initial infrastrucutre, so that source based things are possible. > support), or instead introducing a new datagram control message > that would enable the control application to retrieve the original > network headers (although possibly modified) and send the ICMPv6 > message itself (which was my choice). Such a scheme would need provisions for handling the case where the user eats the message, but never tells us what to do. In such a case we'd need to emit some kind of ICMPv6 message, even if it would be just a timeout generated parameter problem. > - Maybe others disagree, but i don't like having a "Route > optimization" mode in XFRM. From my POV, "Route optimization" is > one kind of transformation specific to MIPv6. Other protocols > require other kind of transformations. I think XFRM should be > instead extended to support generic transformations, where the > Mobile IPv6-specific one would implement a RO transform in order to > support it's binding cache. Also, these new modes are not > "advanced" but instead "Mobile IPv6 specific". Such a layer would be needed if we ever put some kernel level components of Mobile IPv4 into the tree, which I see no reason not to, since it has this route optimization as well. - To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
