Locator/ID Separation Protocol (LISP) Map-Versioning
draft-ietf-lisp-map-versioning-09

[Ballot discuss]
Updated for rev -08, 2/14/2012


These Discuss points all related to the methods in section 5.1

1. What does an ITR do with a received datagram that contains a map
version number that is older than the current map entry?  Section 5.1
describes how the ITR sends Map-Request messages and discards the
received packet if the TTL has expired for the received version
number.  However, I don't see an explicit rule for discarding or
processing an otherwise valid datagram for which has been delivered to
an ITR that is willing to route the datagram to the destination EID.

2. Does the ITR need to keep TTL information for all previous map
versions to be able to determine if the TTL for those early map
versions have expired?

3. I don't recall the rule in the base LISP spec (if there is one)
that describes how an ITR responds to a received datagram with a
destination EID that the ITR is unwilling to forward.  If the ITR
discards such a datagram, does it first check the map version number?

[Ballot comment]
Sorry for the confusion. I have cleared my Discuss on the basis of the ext and reference to draft-ietf-list, and the new text in draft-ietf-lisp

[Ballot discuss]
We are almost there.

draft-ief-lisp-20 now contains sufficient caveats to satisfy my issue on that document.

My remaining point on this draft can be addressed wih a short piece of text and a pointer.

Please consider the text recently added to http://www.ietf.org/id/draft-ietf-lisp-map-versioning-07.txt

  Issues and concerns about the deployment of LISP for Internet traffic
  are discussed in [I-D.ietf-lisp].  Section 12 provides additional
  issues and concerns raised by this document.  In particular,
  Section 12.1 provides details about the ETRs' synchronization issue
  in the context of Map-Versioning.

- - - -

I am holding this Discuss until the resolution of my Discuss on the main LISP specification that is a normative reference.

depending on how that is resolved, this document will need a pointer to the disclaimer text added to the base LISP spec.

All other issues I raised on this document have been resolved.

[Ballot comment]
There are many abbreviations that are used without expansion in the Introduction.

Appendix A is  confusing firstly because it is unclear as as to whether the 12 bits is right on the edge of acceptability, or is a realistic number that will be useful for the foreseeable future. Secondly it explains how wonderful it would be to have between 16 and 32 bits of version without providing any information on whether this is realistic to retrofit into the protocol.

[Ballot discuss]
This document should have an up front (Introduction) statement recording the issues stated in section 12, since without that statement the reader has the impression for most of the document that this is a fully baked solution.

In particular the document seems to be saying that without the synchronization problem being solved their are significant issues with this mechanism. That would suggest that we ought to solve the synchronization mechanism at least in some rudimentary way before publishing this element of the LISP specification series.

[Ballot discuss]
In my opinion, draft-ietf-lisp-interworking should
be a normative reference in this document.  All
of section 8.3 seems to depend on the details
of the interworking mechanisms in draft-ietf-lisp-interworking.

I've reviewed this document to the extent possible
without reviewing draft-ietf-lisp-interworking, which
has not yet come up for IESG review.  This document
will require additional review once draft-ietf-lisp-interworking
has been reviewed, to ensure any changes in
draft-ietf-lisp-interworking are reflected in this document.

[Ballot discuss]
I hope I am missing something, but I spent a fair amount of time
  trying to figure this out.  So, if I missed something, I am sure
  other readers will miss it too.

  The document uses a fixed-length version number.  When a received
  number is smaller than the stored one, the conclusion is that the
  sender has an older version.  See for example the the 3rd numbered
  paragraph in Section 5.2.  However, Section 4 defines a more complex
  algorithm that I believe is intended to recognize that a version
  number of 0x001 might be newer than a version number of 0xFFE.

  I found the use of "smaller" confusing in the face of wrap around.

  Further, I think the formula in Section 4 is incorrect.  In my
  example above, 0x001 is newer than 0xFFE, so if I understand the
  document correctly, 0x001 should be "greater than" 0xFFE, and 0xFFE
  should be "less than" 0x001.  The formula says:
 
    V1 < V2 :  True if and only if V1 < V2 < (V1 + 2**(N-1)).

  This translates to: 0xFFE < 0x001 < (0xFFE + 2**11), which fails.

[Ballot discuss]
---------------------------------------------------------------------------------

Section 5.1, Bullet 2: Do you really want to drop this packet? Won't this condition occur whenever the following are true:

- multiple ETRs serve the site
- a mapping update is in progress
- the ETR receiving the packet has not yet been updated
- another ETR has been updated
- the ITR received its mapping from the ETR that has been updated.

----------------------------------------------------------------------------------

Section 5.3, Bullet 3: Do you really want to drop this packet. Same argument as above, but viewed from the other side of the tunnel.

-----------------------------------------------------------------------------------

[Ballot discuss]
I am holding this Discuss until the resolution of my Discuss on the main LISP specification that is a normative reference.

depending on how that is resolved, this document will need a pointer to the disclaimer text added to the base LISP spec.

All other issues I raised on this document have been resolved.

[Ballot discuss]
I have updated my Discuss for the new revision. Thanks for working to address my concerns.

I will hold the Discuss until the review of the main LISP specification that is a normative reference.

[Ballot comment]
I find it very regrettable that this document was brough forward for
IESG review before the architecture and protocol on which it depends.

The very first paragraph of the body of the document is a normative
reference to the base specification which is currently in AD Review
with a new revision required and a good dolop of questions from the
AD for the authors to resolve.

This means that any review of this document is necessarily moot. I am
very sorry, but I may have to come back and extend my Discuss after
we have reviewed the base spec.

I recognise that this issue is not actionable by the authors, and simply
supply it as a comment for the record. However, I strongly encourage the
authors to keep a tight track of this document since it contains
statements of protocol behavior that are lifted from the base LISP spec
and which may be subject to change.

[Ballot discuss]
The LISP Charter says (of the WG)...
Its
specifications are Experimental and labeled with accurate disclaimers
about their limitations and not fully understood implications for
Internet traffic.

I do not find such disclaimers in this document.

---

The Abstract says...

  The mechanism is transparent to legacy implementations

which is a bit weird for the first version of an experimental RFC for
which no base protocol spec has been published.

---

I do not understand how synchronisation is achieved when multiple ETRs
can advertise to one MS, or when there are multiple MSes in the network
and "relaying" goes on.

[Ballot comment]
It's hard to imagine that anyone would treat values as other than big endian, but it might be worth being explicit in the document.

[Ballot discuss]
I hope I am missing something, but I spent a fair amount of time
  trying to figure this out.  So, if I missed something, I am sure
  other readers will miss it too.

  The document uses a fixed-length version number.  When a received
  number is smaller than the stored one, the conclusion is that the
  sender has an older version.  See for example the the 3rd numbered
  paragraph in Section 5.2.  However, Section 4 defines a more complex
  algorithm that I believe is intended to recognize that a version
  number of 0x001 might be newer than a version number of 0xFFE.

  I found the use of "smaller" confusing in the face of wrap around.

  Further, I think the formula in Section 4 is incorrect.  In my
  example above, 0x001 is newer than 0xFFE, so if I understand the
  document correctly, 0x001 should be "greater than" 0xFFE, and 0xFFE
  should be "less than" 0x001.  The formula says:
 
    V1 < V2 :  True if and only if V1 < V2 < (V1 + 2**(N-1)).

  This translates to: 0xFFE < 0x001 < (0xFFE + 2**11), which fails.

[Ballot discuss]
General:

This document cannot be reviewed in a meaningful way before:

- the LISP base document is reviewed
- my DISCUSS against section 4.2 of the LISP Map Server document is resolved

------------------------------------------------------------------------------------------
Section 5.1

In Bullet 2, you say:

"2.  The packet arrives with a Destination Map-Version number greater
      (i.e., newer) than the one stored in the EID-to-RLOC Database.
      Since the ETR is authoritative on the mapping, meaning that the
      Map-Version number of its mapping is the correct one, this
      implies that someone is not behaving correctly with respect to
      the specifications.  In this case the packet carries a version
      number that is not valid, otherwise the ETR would have the same,
      and SHOULD be silently dropped."

This reaction might be too strong, especially in a case where ETRs are temporarily out of sync (e.g., during a configuration change).

---------------------------------------------------------------------------------------------
In Section  5.2 you say:

"3.  The packet arrives with a Source Map-Version number smaller
      (i.e., older) than the one stored in the local EID-to-RLOC Cache.
      Such a case is not valid with respect to the specifications.
      Indeed, if the mapping is already present in the EID-to-RLOC
      Cache, this means that an explicit Map-Request has been sent and
      a Map-Reply has been received from an authoritative source.
      Assuming that the mapping system is not corrupted anyhow, the
      Map-Version in the EID-to-RLOC Cache is the correct one, while
      the one carried by the packet is stale.  In this situation the
      packet MAY be silently dropped."

Why would you want to drop a packet if your return route to the source is potentially corrupt?

[Ballot discuss]
General:

This document cannot be reviewed in a meaningful way before the review of the LISP base document.

------------------------------------------------------------------------------------------
Section 5.1

In Bullet 2, you say:

"2.  The packet arrives with a Destination Map-Version number greater
      (i.e., newer) than the one stored in the EID-to-RLOC Database.
      Since the ETR is authoritative on the mapping, meaning that the
      Map-Version number of its mapping is the correct one, this
      implies that someone is not behaving correctly with respect to
      the specifications.  In this case the packet carries a version
      number that is not valid, otherwise the ETR would have the same,
      and SHOULD be silently dropped."

This reaction might be too strong, especially in a case where ETRs are temporarily out of sync (e.g., during a configuration change).

---------------------------------------------------------------------------------------------
In Section  5.2 you say:

"3.  The packet arrives with a Source Map-Version number smaller
      (i.e., older) than the one stored in the local EID-to-RLOC Cache.
      Such a case is not valid with respect to the specifications.
      Indeed, if the mapping is already present in the EID-to-RLOC
      Cache, this means that an explicit Map-Request has been sent and
      a Map-Reply has been received from an authoritative source.
      Assuming that the mapping system is not corrupted anyhow, the
      Map-Version in the EID-to-RLOC Cache is the correct one, while
      the one carried by the packet is stale.  In this situation the
      packet MAY be silently dropped."

Why would you want to drop a packet if your return route to the source is potentially corrupt?

[Ballot discuss]
General:

This document cannot be reviewed in a meaningful way before the review of the LISP base document.

------------------------------------------------------------------------------------------
Section 5.1

In Bullet 2, you say:

"2.  The packet arrives with a Destination Map-Version number greater
      (i.e., newer) than the one stored in the EID-to-RLOC Database.
      Since the ETR is authoritative on the mapping, meaning that the
      Map-Version number of its mapping is the correct one, this
      implies that someone is not behaving correctly with respect to
      the specifications.  In this case the packet carries a version
      number that is not valid, otherwise the ETR would have the same,
      and SHOULD be silently dropped."

This reaction might be too strong, especially in a case where ETRs are temporarily out of sync (e.g., during a configuration change).

[Ballot discuss]
General:

This document cannot be reviewed in a meaningful way before the review of the LISP base document.

---------------------------------------------------------------------------------------------------

Section 1:

In the last paragraph, you say:

"This operation is two-fold.  On the one hand, it enables the ETR receiving the packet to know if the ITR has the latest version number that any ETR at the destination EID site has provided to the ITR in a Map-Reply."

This sentence probably doesn't say what you mean. In order to make that determination, wouldn't the ETR have to see all of the Map-Replies that other ETR serving the EID have sent to the ITR?

-------------------------------------------------------------------------------------------------------

Section 5:

In paragraph 2, you say:

"Indeed, ETRs belonging to the same LISP site must return for a specific EID-prefix the same mapping, including the same Map-Version number.  In principle this is orthogonal to whether or not map-versioning is used.  The synchronization problem is out of the scope of this document."

I wish that this statement were in the Map Server document and I hope to see it in the base lisp document.

Is there some mechanism within the LISP site that synchronizes this data across advertising ETRs? Or is this left to manual operations?

When this data changes, how is the change coordinated across ETRs. What happens when one ETR is not available during the change? How does it sync up later?

What happens when ETRs get out of sync with each other?

[Ballot discuss]
General:

This document cannot be reviewed in a meaningful way before the review of the LISP base document.

---------------------------------------------------------------------------------------------------

Section 1:

In the last paragraph, you say:

"This operation is two-fold.  On the one hand, it enables the ETR receiving the packet to know if the ITR has the latest version number that any ETR at the destination EID site has provided to the ITR in a Map-Reply."

This sentence probably doesn't say what you mean. In order to make that determination, wouldn't the ETR have to see all of the Map-Replies that other ETR serving the EID have sent to the ITR?

-------------------------------------------------------------------------------------------------------

Section 5:

In paragraph 2, you say:

"Indeed, ETRs belonging to the same LISP site must return for a specific EID-prefix the same mapping, including the same Map-Version number.  In principle this is orthogonal to whether or not map-versioning is used.  The synchronization problem is out of the scope of this document."

I wish that this statement were in the Map Server document and I hope to see it in the base lisp document.

Is there some mechanism within the LISP site that synchronizes this data across advertising ETRs? Or is this left to manual operations?

When this data changes, how is the change coordinated across ETRs. What happens when one ETR is not available during the change? How does it sync up later?

[Ballot discuss]
General:

This document cannot be reviewed in a meaningful way before the review of the LISP base document.

---------------------------------------------------------------------------------------------------

Section 1:

In the last paragraph, you say:

"This operation is two-fold.  On the one hand, it enables the ETR receiving the packet to know if the ITR has the latest version number that any ETR at the destination EID site has provided to the ITR in a Map-Reply."

This sentence probably doesn't say what you mean. In order to make that determination, wouldn't the ETR have to see all of the Map-Replies that other ETR serving the EID have sent to the ITR?

-------------------------------------------------------------------------------------------------------

[Ballot comment]
The comparison operator on the circular range of version numbers currently is not well defined when comparing against the value that's exactly half-way around the buffer (for example, if N were 3, it is not defined whether 1 is less than or greater than 5 (1<5<5 isn't true, nor is 5>1>1)).

[Ballot discuss]
Related to the questions Richard Barnes asked in his 2Sep GenArt review (which afaict has not seen a response) - what keeps an ETR that has restarted from discarding traffic from ITRs that still have a map version cached from before the ETRs restart that happened fall in the half of the buffer the ETR would now consider "too new"?

[Ballot discuss]
I think that this may be elevating Stephen's comment to a DISCUSS.

Without a systems view of LISP mapping information, it is impossible to comment meaningfully on draft-ietfl-lisp-map-versioning. I trust that this systems view is provided by the LISP base document, but that document has not yet been brought to the IESG.

[Ballot comment]
If there's conflict in normative text between this and base,
which takes precedence? I think you need to say, even if
you believe there is no such conflict, just in case it turns out
that there's some hidden conflict or the base draft changes
after this one is done.

[Ballot comment]
If there's conflict in normative text between this and base,
which takes precedence? I think you need to say, (unless you change
as per point 1.b above).

[Ballot comment]
- section 1: "...but rather to complete them providing new
functionalities" is an odd phrase that seems to imply that LISP is
finished now that this version field is defined.

- section 4: "assigned in a per-mapping fashion" is not clear to me
- is it clear to LISP experts?

- section 4, typo: s/"consist in incrementing"/"consists in
incrementing" there're a bunch more English language glitches
like that btw

- section 5: Does "ISP" mean Internet service provider? Seems odd to
imply that only ISPs can update versions? Would "LISP-site" be a
better term?

- section 5.1, rule 2 says the packet SHOULD be dropped but 5.2,
rule 3 says the packet MAY be silently dropped. Since the same thing
seems wrong in both case, I guess I'm wondering why one is SHOULD
and one is MAY (and why neither is MUST:-) It might be good to
explain those decisions.

- I note that this creates a potentially bad DoS if the map-request
stuff is not secure, e.g. convince an ITR to bump the version and then
its stuff will be dropped by the related ETR. You do note that
dependency but I'm just writing it down so's I'm more likely to
recall this when the base document comes up:-)

- An additional security consideration - if I can prevent an xTR
from seeing map updates for long enough then its version numbers
will be considered bad since they will appear to be greater than the
current real version number and its packets SHOULD or MAY be
dropped. I think you should note that since it means you depend on
the availability of the map updates as well as their authenticity.
With Appendix A that implies O(30) minutes of no map updates might
be enough for this to work. If the attacker can also trigger version
numbers to be updated (e.g. by constantly rebooting a machine?) then
the time required might be much less.

[Ballot discuss]
Mostly, this is discuss-discuss stuff rather than asking for changes
so it should be easily sorted.

(1) draft-ietf-lisp-15 overlaps with some of this (esp 6.6.3).  The
base document does mention "greater" version numbers but those are
only defined here, as (I assume) are the error cases when versions
don't match.  Two things: a) I think [VERSIONING] needs to be a
normative ref for the base doc, or b) why not move the normative
stuff from here to base and make this an informational document?

(2) If there's conflict in normative text between this and base,
which takes precedence? I think you need to say, (unless you change
as per point 1.b above).

(3) section 6: "usually contain the nonce"? What is the consequence
of not sending a nonce? (If that's what's meant?) The security
considerations of the base draft say that the nonce "goes a long way
toward providing decent authentication" so replacing it I guess
needs to be done carefully. I'd just like to hear the argument
for why this is ok.

(4) section 7 - the ascii art here is from base, 6.1.4, right?  why
does that say "EID-prefix-AFI" and this says "EID-AFI" - is that a
typo or meaningful?

(5) - section 8.1, 1st para: the argument is only correct if the version
fields are equally protected compared to all other fields in the
protocol, i.e. if any crypto usable covers these as well as it covers
other fields. If somehow, other fields could be cryptographically
protected, but the versions could not, then this would introduce
new vulnerabilities. Can you confirm that this is not the case?

State changed to In Last Call from Last Call Requested.

The following Last Call Announcement was sent out:

From: The IESG
To: IETF-Announce
CC:
Reply-To: ietf@ietf.org
Subject: Last Call:  (LISP Map-Versioning) to Experimental RFC


The IESG has received a request from the Locator/ID Separation Protocol
WG (lisp) to consider the following document:
- 'LISP Map-Versioning'
  as an Experimental RFC

The IESG plans to make a decision in the next few weeks, and solicits
final comments on this action. Please send substantive comments to the
ietf@ietf.org mailing lists by 2011-09-12. Exceptionally, comments may be
sent to iesg@ietf.org instead. In either case, please retain the
beginning of the Subject line to allow automated sorting.

Abstract


  This document describes the LISP Map-Versioning mechanism, which
  provides in-packet information about EID-to-RLOC mappings used to
  encapsulate LISP data packets.  The proposed approach is based on
  associating a version number to EID-to-RLOC mappings and transport
  such a version number in the LISP specific header of LISP-
  encapsulated packets.  LISP Map-Versioning is particularly useful to
  inform communicating xTRs about modifications of the mappings used to
  encapsulate packets.  The mechanism is transparent to legacy
  implementations, since in the LISP-specific header and in the Map
  Records, bits used for Map-Versioning can be safely ignored by xTRs
  that do not support the mechanism.




The file can be obtained via
http://datatracker.ietf.org/doc/draft-ietf-lisp-map-versioning/

IESG discussion can be tracked via
http://datatracker.ietf.org/doc/draft-ietf-lisp-map-versioning/


No IPR declarations have been submitted directly on this I-D.

I have reviewed this draft. This is another well written and easy to understand document. Thank you for that.

I only found minor editorial issues, one security aspect that you should document, and couple of small technical comments. I have sent the document forward to IETF Last Call anyway. Please revise the draft as soon as you can (even during Last Call). Ask me if something was unclear or I missed something.

Technical:

> The feature
> introduced by Map-Version numbers is the possibility of blocking
> traffic from ITRs not using the latest mapping.  Indeed, after a
> certain number of retries, if the Destination Map-Version number
> in the packets is not updated, the ETR MAY silently drop packets
> with a stale Map-Version number.  This because either the ITR is
> refusing to use the mapping for which the ETR is authoritative or
> (worse) it might be some form of attack.

I have two small comments about this. First, since an attack could spoof the source address, it is important to restrict the blocking to the offending traffic, not all traffic from a given ITR address. And this is your intention, as can be seen from the second sentence. Could you make the following change to make this even clearer in the first sentence as well: s/blocking traffic from ITRs not using the latest mapping/blocking traffic not using the latest mapping/.

Second, I'm not sure I understand the different failure cases here. What if there's a network issue that causes unidirectional connectivity? We'd receive lisp encapsulated packets, but our attempts to send commands to update the mapping would be unsuccessful, as the traffic does not get through. In light of this, is the right action to start dropping packets on our side? Or maybe there is something else in Lisp that prevents us from getting into this situation. Please explain. And if you are not sure what the implications are, please indicate that in the text.


> 3. The packet arrives with a Source Map-Version number smaller
>    (i.e., older) than the one stored in the local EID-to-RLOC Cache.
>    Such a case is not valid w.r.t. the specifications.  Indeed, if
>    the mapping is already present in the EID-to-RLOC Cache, this
>    means that an explicit Map-Request has been sent and a Map-Reply
>    has been received from an authoritative source.  Assuming that
>    the mapping system is not corrupted anyhow, the Map-Version in
>    the EID-to-RLOC Cache is the correct one and the packet MAY be
>    silently dropped.
>

I worry that there's a dependency on something which cannot be fully secured in the real-world, and if someone starts to drop packets due to an inconsistency there is no easy way to recover. I would suggest adding something to the security considerations section about reliance on the security of the mapping system and aggressive drop policies leading to the possibility of difficult recovery from a temporary mapping system issue.

>  Once no more traffic is received by the RLOC, because all sites have
>  updated the mapping, it can be shut down safely.

Technically, there might be a mapping on some other site that has not had a reason to send a packet yet. But if it then sends a packet, it might use a locally cached copy of the mapping and the packet goes to the wrong place.

Perhaps you should clarify this. E.g. " ... received by the RLOC, it can be shut down in relatively safety, because at least all sites actively using the mapping have updated it."


Editorial:

>  This document describes the LISP Map-Versioning mechanism, which
>  provides in-packet information about EID-to-RLOC mappings used to
>  encapsulate LISP data packets.  The proposed approach is based on
>  associating a version number to EID-to-RLOC mappings and transport
>  such a version number in the LISP specific header of LISP-
>  encapsulated packets.  LISP Map-Versioning is particularly useful to
>  inform communicating xTRs about modifications of the mappings used to
>  encapsulate packets.  The mechanism is transparent to legacy
>  implementations, since in the LISP-specific header and in the Map
>  Records, bits used for Map-Versioning can be safely ignored by xTRs
>  that do not support the mechanism.

You should expand EID, RLOC, and xTR, as this is the abstract (it can be read by someone without seeing the rest of the document).

>  When Map-Versioning is used, LISP-encapsulated data packets contain
>  the version number of the two mappings used to select the RLOCs in
>  the outer header (i.e., both source and destination).  These version
>  numbers are encoded in the 24 low-order bits of the first longword of
>  the LISP header and indicated by a specific bit in the flags (first 8
>  high-order bits of the first longword of the LISP header).  Note that
>  not all packets need to carry version numbers.

I'd prefer seeing a reference to draft-ietf-lisp and section number that defines the Lisp header.

> The Map-Request will either trigger a Map-Request back
> using the SMR bit or it will piggyback the newer mapping.  These
> are not new mechanisms; how to SMR or piggyback mappings in Map-
> Request messages is already described in [I-D.ietf-lisp],

Expand SMR.


> A Proxy-ETR does not have any mapping, since it just decapsulate
> packets arriving from LISP site.

s/decapsulate/decapsulates/

Jari

(1.a) Terry Manderson is the Shepherd and has reviewed this version
and believes it is ready to be forwarded to the IESG.

(1.b) The document has had adequate review. The shepherd has no concerns
regarding the reviews which have been performed.

(1.c) The document shepherd does not have concerns that the document
requires a broader review.

(1.d) The document shepherd has no specific concerns, No IPR disclosures
have been raised.

(1.e) The WG consensus reflects active agreement among about about 10
participants, with the bulk of the WG being silent.

(1.f) No threats of appeal or discontent on this document have manifested.

(1.g) IDNITs responded with no concerning issues

(1.h) References have been split. No downward normative references exist.
One document (draft-ietf-lisp) exists as a WIP normative reference.
It will be submitted to the IESG at the same time as this document.

(1.i) The document makes no request of the IANA

(1.j) Formal language has been verified.

(1.k)
Technical Summary

This document describes the LISP Map-Versioning mechanism, which
provides in-packet information about EID-to-RLOC mappings used to
encapsulate LISP data packets. The proposed approach is based on
associating a version number to EID-to-RLOC mappings and transport
such a version number in the LISP specific header of LISP-
encapsulated packets. LISP Map-Versioning is particularly useful to
inform communicating xTRs about modifications of the mappings used to
encapsulate packets. The mechanism is transparent to legacy
implementations, since in the LISP-specific header and in the Map
Records, bits used for Map-Versioning can be safely ignored by xTRs
that do not support the mechanism.

Working Group Summary

The WG process for this document was uneventful.

Document Quality

This document is a companion document and provides an important
function in LISP. It has been well reviewed and this document
is in good form.