[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [lisp-interest] Re: [RRG] Publicly available LISP and shim6 implementations

I would like to give a bit more detail as to what I mean by
integrating LISP with SEAL. My proposal is that the LISP header
be modified to provide sufficient function for adapting to the
tunnel path MTU without consuming extra bytes. The way forward
is to replace the 32-bit LISP Nonce with a 32-bit field that
looks very much like the SEAL header. In fact, only 3 bytes are
needed such that you get an extra byte to encode more Locator
Reach Bits - thus extending that field to 38 bits.


But we need the nonce and we can't increase the header by 4
bytes. And
why put fragmentation stuff in the packet for those packets you are
not fragmenting?


No; there is no increase in the header length. I think you
picked this up after reading ahead further, but you still
get a 4byte nonce with no increase in the header length.
What I'm saying is that I want the nonce easily acceptable, and if you do that, you'll need to add the header length.
Now we have to get 2 16-bit numbers of different places in the packet 
and put it together. Not worth it Fred.


Combining the 2 16-bit numbers is trival; arithmetic shift
the high-order bits then or them with the low order bits
into a 32 bit register. Plus, it makes meaningful use of
the 16-bit IPv4 ip_id where the current LISP proposal
does not.
No, it's not trivial. And where do I get the other 16-bits in the IPv6 case? There is no ID field in the IPv6 header.
The point I'm making is that you are putting extra mechanism in for really no gain. So why would an implementor want to do this. 


Sorry, I don't get why we are doing all this?


Because you can never 100% guarantee that you won't trip
over a restricting link in the path. There is legacy 1500
gear in the Internet that will be very difficult to
eradicate, and you can never tell when an operator is
going to mis-configure a link MTU to make it appear
smaller than it actually is.


I am not arguing this point anymore. We've been over this before.


SEAL also determines the correct MTU when the path only
contains links with large MTUs. Let's say that the
restricting link has an MTU of 6KB. If the ITR initially
thinks the path to the ETR has an MTU of 8KB, it will
get back a nonce-protected MTU discovery message from the
ETR itself (not from a network middlebox or an attacker)
and adjust its path MTU estimate to 6KB. Plus, the 8KB
packet will still make it through.
We need to find out when paths have small MTUs and not large ones. If they are large and we default to thinking they are large we don't need to do anything.
The only value of a new mechanism is to tell us when the path MTU is 1500 bytes. 

Dino