Given that LISP ITRs work by intercepting packets that are not
addressed to them, a host implementation would need to be able to
intercept packets "in the stack". That is going to need some
ability to modify kernel behavior.
(1) ITRs don't receive packets. They encapsulate packets.
(2) ETRs receive encapsulated packets addressed to one of their RLOC
addresses.
(3) For Map-Requests, there are 3 forms:
i. Encapsulated Map-Requests which are originated by the map-
server the ETR is registered to
and is addressed to the ETR.
ii. Map-Requests which are addressed to EIDs but are traveled
over the ALT. Only when an ETR is
attached to the ALT (not a standard configuration
recommendation), that it must process a
packet that is not addressed to it. But this is a packet
destined to port 4342 and not 4341.
UDP port 4342 is the control port.
iii. Data Probes (which is not default and probably will be
deprecated behavior) are addressed
to EIDs which ETRs must intercept. They are addressed to UDP
port 4341. Data Probes can
be sent on the underlying network (LISP variant 1) or sent
on the ALT which means the
requirements in ii must be adhered to.
(Yes, I think we will see LISP enabled hosts. I don't think
mobility is the only case where this will happen. But it will mean
someone has modified the kernel to do so.)
I would not recommend it and I believe won't be accepted for the same
reasons that shim6 wasn't accepted. You will use locator
aggregatability for EID-prefixes if you do. The mapping database will
be unnecessarily large. IMHO, a non-starter.
Where you can aggregate EIDs, you should. In a roaming case where you
may not be able to, then you don't.
Dino
Yours,
Joel
Dino Farinacci wrote:
Hi Dino,
On Aug 11, 2009, at 11:37 AM, Dino Farinacci wrote:
On Aug 8, 2009, at 8:34 PM, Dino Farinacci wrote:
The spec says ETRs MUST ignore the UDP checksum field. This is
what the LISP authors intended and has been implemented this way.
The spec says ITRs MUST set the UDP checksum field to 0.
Could you tell us how to achieve this on commonly deployed
desktop software/hardware that has two properties:
We don't want this rule on commonly deployed desktop hosts.
I am not sure what you are saying here. I can think of two
possibilities:
(1) You don't want LISP to be implemented on commonly deployed
desktop hosts.
Right, it is a network based solution.
(2) You want to change the document to state a different rule, so
that LISP can be implemented in a compliant manner on desktop hosts.
That is not what I am suggesting.
Dino
Could you elaborate?
Margaret
_______________________________________________
lisp mailing list
l...@ietf.org
https://www.ietf.org/mailman/listinfo/lisp
--------------------------------------------------------------------
IETF IPv6 working group mailing list
ipv6@ietf.org
Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------
