Maybe I was missing a bet. You would have to direct all the packets
from the host back to user space to be processed, since it is only the
LISP logic that can decide whether the packet should be tunneled or not.
But if they support that concept, then it can be done.
And yes, that does seem to mean that if we could use the UDP stack right
out of the box, then this would require no kernel modifications to add
it. Which is a nice benefit.
Given what has been discussed, this leads me to looking more closely at
using the IPv6 flowID to enable load balacning, and not using UDP at
all. However, I do not know how to make this work with the deployed
boxes that do hardware ECMP / LAG in the field already for IPv6.
Yours,
Joel
Sam Hartman wrote:
Joel> Given that LISP ITRs work by intercepting packets that are
Joel> not addressed to them, a host implementation would need to
Joel> be able to intercept packets "in the stack". That is going
Joel> to need some ability to modify kernel behavior.
I'm trying to figure out how an ITR does anything different than a
router with a tunneled interface.
Every host I'm aware of has a facility for setting up an interface
that routes some set of packets--including potentially the default
route--through a tunnel interface that then passes the packet to
userspace for processing.
--------------------------------------------------------------------
IETF IPv6 working group mailing list
[email protected]
Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------
