Subject: Re: [lisp] proposed fix issue #22 - processing of Encapsulated Map Requests

From: [email-masked] (Noel Chiappa)
Date: Tue, 22 Sep 2009 10:48:43 -0400 (EDT)

> From: Margaret Wasserman <[email-masked]>

    > include everything that is needed by the mapping system in the
    > control message itself.

This is just a guess (I tend to tune out these sorts of detailed low-level
issues, since they cause my eyes to glaze over), but one possible reason
for going the other way is that if you do that, you have one more packet
type to write code for. If you just encapsulate the whole thing, you only
need a couple of lines of code - strip the wrapper, and process the packet
as normal.

>From Sam's comments, it sounds like maybe the issue is that reprocessing
that inner packet is easy on some machine (just feed it back into
ip_handle_packet(), or whatever it's called), whereas on others that
doesn't work, so on those machines, instead of being less work, it's more.
At least, that's the impression I'm getting.

	Noel

---

From: Margaret Wasserman <[email-masked]>
Date: Tue, 22 Sep 2009 10:59:42 -0400

Hi Noel,

> At least, that's the impression I'm getting.

Logically, this is pretty simple on all of the systems I'm aware  
of...  However, it always takes more processing to process an  
encapsulated packet, as you pass the packet through the IP receive  
logic twice, once for the outer header, and again for the inner  
header.  Also, there can be a bunch of security complexity, because  
tunneling allows you to get packets where they shouldn't be.  So, you  
either need to do a bunch of checks to make sure that the addresses in  
the outer header match the ones in the inner header, or you need to be  
very careful that the packets are properly filtered/firewalled _after_  
they are decapsulated.

In general, encapsulating (AKA tunneling) packets can be very useful  
when you are trying to achieve some sort of overlay topology (like  
LISP), but they seem unnecessary for communication between xTRs and  
Map Servers/Resolvers, because those systems all have RLOCs and can  
use them to talk to each other without the need for tunneling, etc.

There has been some discussion of whether encapsulation is needed to  
support mixed IPv4/IPv6 address cases, but I don't understand why that  
would be.  Take DNS for example -- a host communicates with a DNS  
server using whatever DNS server address it has configured.  The  
requesting host chooses its own source address and the version of IP  
to match the DNS server address.  That doesn't stop the requesting  
host from being able to receive both A (IPv4) records and AAAA (IPv6)  
records in response to a query, or even from doing a reverse lookup on  
both IPv4 and IPv6 addresses.  The transport is just a transport.

Margaret