From: Hugo Santos <redacted>
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.