I would like to suggest a way to address mutiprotocol support in
RFC6830bis, that may address what was discussed in Singapore.
This is based on using the last reserved bit in the LISP header as P bit
to indicate support for multiprotocol encapsulation, as specified in the
LISP-GPE draft (https://tools.ietf.org/html/draft-lewis-lisp-gpe).
The header, as specified in section 5.1, would look like:
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
L|N|L|E|V|I|P|K|K|Nonce/Map-Version/Next-Protocol|
I \ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
S / |Instance ID/Locator-Status-Bits|
P+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
and the text in section 5.3 that reserves the 6th bit would be replaced by:
P: The P-bit is the Next Protocol bit. When this bit is set to
1, the V-bit MUST be set to 0 and the Nonce length, when used, is
limited to 16 bits. Refer to[draft-lewis-lisp-gpe] for more details.
The P-bit is set to 1to indicate the presence of the 8 bit Next
Protocol field encoded as:
x x x 0 x 1 x x
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|N|L|E|V|I|P|K|K| Nonce | Next-Protocol |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|Instance ID/Locator-Status-Bits|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
I will have to refresh the LISP-GPE draft, and reflect the allocations
of the KK bits according to RFC8061 and Nonce. One of the K bits was
used by LISP-GPE to indicate OAM packets, but that same functionality
can be done using the Next-Protocol field.
The use of the P-bit is not compatible with the Map-Versioning feature,
but an equivalent function can be specified (if needed) with a
Next-Protocol shim header. I can add text to the LISP-GPE draft to
reflect that.
This would address the multiprotocol working item included in the
current charter.
I can very quickly update the LISP-GPE draft to reflect this, but I
wanted to hear what the group thinks first.
Thanks,
Fabio
_______________________________________________
lisp mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/lisp
