Opened 10 years ago

Closed 9 years ago

#22 closed technical (fixed)

An ETR MUST consume UDP port 4342 packets not addressed to it

Reported by: hartmans-ietf@… Owned by:
Priority: major Component: alt
Severity: - Keywords:


Two aspects of the MS protocol require that an ETR consume packets not
addressed to it. (There are also cases where an ETR or LISP+alt
router consumes alt packets not addressed to it; those cases seem fine
to me. If desired I can explain my reasoning.)

# an ITR sends an encapsulated map request to a map resolver
# an map server sends an encapsulated request to an ETR

An encapsulated map request typically has the source RLOC of the ITR
for both the inner and outer header, and has the EID of the
destination of the map request for the inner IP header. The outer
destination UDP port is 4341 (the LISP data port). The inner
destination UDP port is 4342.

The problem here is that the box doing LISP decapsulation needs to do
special processing on packets not destined for it. This complicates
the data plane implementation. Also, this violates the end-to-end
principle and the IP service model. There are very few situations
when a router is expected to consume a packet not destined for it;
none of them apply here as far as I can tell.

I think the architecture is bad enough that this should change. But the practical effects are also problematic:

  • The data plane stack on the router needs to handle IP options, hop-by-hop options, and destination options the same way as the UDP stack in the control plane in order to avoid inconsistent behavior.
  • Whether you reach port 4342 on the end-system named by an EID or whether your packet is consumed by an intermediate router depends on where you are in the topology.

Instead, I propose that:

An ITR should send a UDP packet with source IP address of one of its
RLOCs, destination IP address of the map resolver's RLOC, and
destination UDP port 4342. The map resolver should receive this
packet and generate a similar map request over the alt with source IP
address of the ITR's RLOC, destination address of the EID within the
map request to UDP port 4342. We need to decide how to handle the
situation where the source RLOC and destination EID are in different
address families. I don't think this case is fully specified with the
existing mechanism, and I can think of some ways to make this work
without encapsulation but need to think more about it.

A map server should receive a packet on UDP port 4342 over an alt
interface. (Receive is kind of a stretch here as huge chunks of the
EID space may be "routed" to the map server.) If the EID is in a
prefix registered with this map server, then the map server should
generate a packet to UDP port 4342 on the RLOC registered with the
prefix, source IP address copied from the packet received or the ALT
and destination address of the RLOC of the prefix.

One way to handle the cross-address-family complexity would be to have
a way to specify the reply source locator in a mapping request.
Really, unless you can include a locator of each address family you
support in a mapping request, you cannot be sure that the other side
will be able to reply to you.

An alternative solution that would address my architectural concerns
would be to send encapsulated map requests to some port other than
4341--perhaps even 4342. I don't prefer that solution and would like
to explore all the options that avoid map request encapsulation before
we go down that route, but it is an option of last resort to make it
possible to unambiguously implement an ETR.

Change History (5)

comment:1 follow-up: Changed 10 years ago by hartmans-ietf@…

See #23

comment:2 in reply to: ↑ 1 Changed 10 years ago by hartmans-ietf@…

Replying to hartmans-ietf@…:

See #23

Actually, make that see #24.

comment:3 Changed 9 years ago by luigi@…

Reply sent by Vince Fuller:

  • My reading of email records indicates that this issue was folded-in to #24 which was according to an email update sent on 8 December 2009.

Cited email concerning #24:

Note: ticket will be closed Friday 25th March unless the responses noted here do not address the concern. If the concern is still not addressed substantive reasoning would be appreciated.

comment:4 Changed 9 years ago by luigi@…

  • Resolution set to fixed
  • Status changed from new to resolved

On Decision of the WG Chairs this issue is closed.

comment:5 Changed 9 years ago by luigi@…

  • Status changed from resolved to closed
Note: See TracTickets for help on using tickets.