draft-ietf-lisp-04.txt   draft-ietf-lisp-05.txt 
Network Working Group D. Farinacci Network Working Group D. Farinacci
Internet-Draft V. Fuller Internet-Draft V. Fuller
Intended status: Experimental D. Meyer Intended status: Experimental D. Meyer
Expires: March 20, 2010 D. Lewis Expires: April 2, 2010 D. Lewis
cisco Systems cisco Systems
September 16, 2009 September 29, 2009
Locator/ID Separation Protocol (LISP) Locator/ID Separation Protocol (LISP)
draft-ietf-lisp-04.txt draft-ietf-lisp-05.txt
Status of this Memo Status of this Memo
This Internet-Draft is submitted to IETF in full conformance with the This Internet-Draft is submitted to IETF in full conformance with the
provisions of BCP 78 and BCP 79. provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as Internet- other groups may also distribute working documents as Internet-
Drafts. Drafts.
skipping to change at page 1, line 34 skipping to change at page 1, line 34
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt. http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html. http://www.ietf.org/shadow.html.
This Internet-Draft will expire on March 20, 2010. This Internet-Draft will expire on April 2, 2010.
Copyright Notice Copyright Notice
Copyright (c) 2009 IETF Trust and the persons identified as the Copyright (c) 2009 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents in effect on the date of Provisions Relating to IETF Documents in effect on the date of
publication of this document (http://trustee.ietf.org/license-info). publication of this document (http://trustee.ietf.org/license-info).
Please review these documents carefully, as they describe your rights Please review these documents carefully, as they describe your rights
skipping to change at page 2, line 37 skipping to change at page 2, line 37
5.2. LISP IPv6-in-IPv6 Header Format . . . . . . . . . . . . . 18 5.2. LISP IPv6-in-IPv6 Header Format . . . . . . . . . . . . . 18
5.3. Tunnel Header Field Descriptions . . . . . . . . . . . . . 19 5.3. Tunnel Header Field Descriptions . . . . . . . . . . . . . 19
5.4. Dealing with Large Encapsulated Packets . . . . . . . . . 21 5.4. Dealing with Large Encapsulated Packets . . . . . . . . . 21
5.4.1. A Stateless Solution to MTU Handling . . . . . . . . . 22 5.4.1. A Stateless Solution to MTU Handling . . . . . . . . . 22
5.4.2. A Stateful Solution to MTU Handling . . . . . . . . . 22 5.4.2. A Stateful Solution to MTU Handling . . . . . . . . . 22
6. EID-to-RLOC Mapping . . . . . . . . . . . . . . . . . . . . . 24 6. EID-to-RLOC Mapping . . . . . . . . . . . . . . . . . . . . . 24
6.1. LISP IPv4 and IPv6 Control Plane Packet Formats . . . . . 24 6.1. LISP IPv4 and IPv6 Control Plane Packet Formats . . . . . 24
6.1.1. LISP Packet Type Allocations . . . . . . . . . . . . . 26 6.1.1. LISP Packet Type Allocations . . . . . . . . . . . . . 26
6.1.2. Map-Request Message Format . . . . . . . . . . . . . . 26 6.1.2. Map-Request Message Format . . . . . . . . . . . . . . 26
6.1.3. EID-to-RLOC UDP Map-Request Message . . . . . . . . . 28 6.1.3. EID-to-RLOC UDP Map-Request Message . . . . . . . . . 28
6.1.4. Map-Reply Message Format . . . . . . . . . . . . . . . 29 6.1.4. Map-Reply Message Format . . . . . . . . . . . . . . . 30
6.1.5. EID-to-RLOC UDP Map-Reply Message . . . . . . . . . . 32 6.1.5. EID-to-RLOC UDP Map-Reply Message . . . . . . . . . . 33
6.1.6. Map-Register Message Format . . . . . . . . . . . . . 33 6.1.6. Map-Register Message Format . . . . . . . . . . . . . 34
6.2. Routing Locator Selection . . . . . . . . . . . . . . . . 36 6.1.7. Encapsualted Control Message Format . . . . . . . . . 36
6.3. Routing Locator Reachability . . . . . . . . . . . . . . . 37 6.2. Routing Locator Selection . . . . . . . . . . . . . . . . 38
6.3.1. Echo Nonce Algorithm . . . . . . . . . . . . . . . . . 39 6.3. Routing Locator Reachability . . . . . . . . . . . . . . . 39
6.3.2. RLOC Probing Algorithm . . . . . . . . . . . . . . . . 41 6.3.1. Echo Nonce Algorithm . . . . . . . . . . . . . . . . . 42
6.4. Routing Locator Hashing . . . . . . . . . . . . . . . . . 41 6.3.2. RLOC Probing Algorithm . . . . . . . . . . . . . . . . 43
6.5. Changing the Contents of EID-to-RLOC Mappings . . . . . . 42 6.4. Routing Locator Hashing . . . . . . . . . . . . . . . . . 44
6.5.1. Clock Sweep . . . . . . . . . . . . . . . . . . . . . 43 6.5. Changing the Contents of EID-to-RLOC Mappings . . . . . . 45
6.5.2. Solicit-Map-Request (SMR) . . . . . . . . . . . . . . 44 6.5.1. Clock Sweep . . . . . . . . . . . . . . . . . . . . . 45
7. Router Performance Considerations . . . . . . . . . . . . . . 46 6.5.2. Solicit-Map-Request (SMR) . . . . . . . . . . . . . . 46
8. Deployment Scenarios . . . . . . . . . . . . . . . . . . . . . 47 7. Router Performance Considerations . . . . . . . . . . . . . . 48
8.1. First-hop/Last-hop Tunnel Routers . . . . . . . . . . . . 48 8. Deployment Scenarios . . . . . . . . . . . . . . . . . . . . . 49
8.2. Border/Edge Tunnel Routers . . . . . . . . . . . . . . . . 48 8.1. First-hop/Last-hop Tunnel Routers . . . . . . . . . . . . 50
8.3. ISP Provider-Edge (PE) Tunnel Routers . . . . . . . . . . 49 8.2. Border/Edge Tunnel Routers . . . . . . . . . . . . . . . . 50
9. Traceroute Considerations . . . . . . . . . . . . . . . . . . 50 8.3. ISP Provider-Edge (PE) Tunnel Routers . . . . . . . . . . 51
9.1. IPv6 Traceroute . . . . . . . . . . . . . . . . . . . . . 51 9. Traceroute Considerations . . . . . . . . . . . . . . . . . . 52
9.2. IPv4 Traceroute . . . . . . . . . . . . . . . . . . . . . 51 9.1. IPv6 Traceroute . . . . . . . . . . . . . . . . . . . . . 53
9.3. Traceroute using Mixed Locators . . . . . . . . . . . . . 51 9.2. IPv4 Traceroute . . . . . . . . . . . . . . . . . . . . . 53
10. Mobility Considerations . . . . . . . . . . . . . . . . . . . 53 9.3. Traceroute using Mixed Locators . . . . . . . . . . . . . 53
10.1. Site Mobility . . . . . . . . . . . . . . . . . . . . . . 53 10. Mobility Considerations . . . . . . . . . . . . . . . . . . . 55
10.2. Slow Endpoint Mobility . . . . . . . . . . . . . . . . . . 53 10.1. Site Mobility . . . . . . . . . . . . . . . . . . . . . . 55
10.3. Fast Endpoint Mobility . . . . . . . . . . . . . . . . . . 53 10.2. Slow Endpoint Mobility . . . . . . . . . . . . . . . . . . 55
10.4. Fast Network Mobility . . . . . . . . . . . . . . . . . . 55 10.3. Fast Endpoint Mobility . . . . . . . . . . . . . . . . . . 55
10.5. LISP Mobile Node Mobility . . . . . . . . . . . . . . . . 55 10.4. Fast Network Mobility . . . . . . . . . . . . . . . . . . 57
11. Multicast Considerations . . . . . . . . . . . . . . . . . . . 57 10.5. LISP Mobile Node Mobility . . . . . . . . . . . . . . . . 57
12. Security Considerations . . . . . . . . . . . . . . . . . . . 58 11. Multicast Considerations . . . . . . . . . . . . . . . . . . . 59
13. Prototype Plans and Status . . . . . . . . . . . . . . . . . . 59 12. Security Considerations . . . . . . . . . . . . . . . . . . . 60
14. References . . . . . . . . . . . . . . . . . . . . . . . . . . 62 13. Prototype Plans and Status . . . . . . . . . . . . . . . . . . 61
14.1. Normative References . . . . . . . . . . . . . . . . . . . 62 14. References . . . . . . . . . . . . . . . . . . . . . . . . . . 64
14.2. Informative References . . . . . . . . . . . . . . . . . . 63 14.1. Normative References . . . . . . . . . . . . . . . . . . . 64
Appendix A. Acknowledgments . . . . . . . . . . . . . . . . . . . 66 14.2. Informative References . . . . . . . . . . . . . . . . . . 65
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 67 Appendix A. Acknowledgments . . . . . . . . . . . . . . . . . . . 68
Appendix B. Document Change Log . . . . . . . . . . . . . . . . . 69
B.1. Changes to draft-ietf-lisp-05.txt . . . . . . . . . . . . 69
B.2. Changes to draft-ietf-lisp-04.txt . . . . . . . . . . . . 69
B.3. Changes to draft-ietf-lisp-03.txt . . . . . . . . . . . . 71
B.4. Changes to draft-ietf-lisp-02.txt . . . . . . . . . . . . 71
B.5. Changes to draft-ietf-lisp-01.txt . . . . . . . . . . . . 72
B.6. Changes to draft-ietf-lisp-00.txt . . . . . . . . . . . . 72
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 73
1. Requirements Notation 1. Requirements Notation
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in [RFC2119]. document are to be interpreted as described in [RFC2119].
2. Introduction 2. Introduction
Many years of discussion about the current IP routing and addressing Many years of discussion about the current IP routing and addressing
skipping to change at page 26, line 10 skipping to change at page 26, line 10
length fields can be used to protect and delimit message boundaries. length fields can be used to protect and delimit message boundaries.
This main LISP specification is the authoritative source for message This main LISP specification is the authoritative source for message
format definitions for the Map-Request and Map-Reply messages. format definitions for the Map-Request and Map-Reply messages.
6.1.1. LISP Packet Type Allocations 6.1.1. LISP Packet Type Allocations
This section will be the authoritative source for allocating LISP This section will be the authoritative source for allocating LISP
Type values. Current allocations are: Type values. Current allocations are:
Reserved: 0 b'0000' Reserved: 0 b'0000'
LISP Map-Request: 1 b'0001' LISP Map-Request: 1 b'0001'
LISP Map-Reply: 2 b'0010' LISP Map-Reply: 2 b'0010'
LISP Map-Register: 3 b'0011' LISP Map-Register: 3 b'0011'
LISP-CONS Open Message: 8 b'1000' LISP Encapsulated Control Message: 8 b'1000'
LISP-CONS Push-Add Message: 9 b'1001'
LISP-CONS Push-Delete Message: 10 b'1010'
LISP-CONS Unreachable Message 11 b'1011'
6.1.2. Map-Request Message Format 6.1.2. Map-Request Message Format
0 1 2 3 0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|Type=1 |A|M|P|S| Reserved | Record Count | |Type=1 |A|M|P|S| Reserved | Record Count |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Nonce . . . | | Nonce . . . |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
skipping to change at page 27, line 44 skipping to change at page 27, line 44
strength of the nonce in the Map-Request message. The nonce strength of the nonce in the Map-Request message. The nonce
SHOULD be generated by a properly seeded pseudo-random (or strong SHOULD be generated by a properly seeded pseudo-random (or strong
random) source. See [RFC4086] for advice on generating security- random) source. See [RFC4086] for advice on generating security-
sensitive random data. sensitive random data.
Source-EID-AFI: Address family of the "Source EID Address" field. Source-EID-AFI: Address family of the "Source EID Address" field.
ITR-AFI: Address family of the "Originating ITR RLOC Address" field. ITR-AFI: Address family of the "Originating ITR RLOC Address" field.
Source EID Address: This is the EID of the source host which Source EID Address: This is the EID of the source host which
originated the packet which is invoking this Map-Request. originated the packet which is invoking this Map-Request. When
Map-Requests are used for refreshing a map-cache entry or for
RLOC-probing, the value 0 is used.
Originating ITR RLOC Address: Used to give the ETR the option of Originating ITR RLOC Address: Used to give the ETR the option of
returning a Map-Reply in the address-family of this locator. returning a Map-Reply in the address-family of this locator.
EID mask-len: Mask length for EID prefix. EID mask-len: Mask length for EID prefix.
EID-AFI: Address family of EID-prefix according to [RFC2434] EID-AFI: Address family of EID-prefix according to [RFC2434]
EID-prefix: 4 bytes if an IPv4 address-family, 16 bytes if an IPv6 EID-prefix: 4 bytes if an IPv4 address-family, 16 bytes if an IPv6
address-family. When a Map-Request is sent by an ITR because a address-family. When a Map-Request is sent by an ITR because a
skipping to change at page 28, line 36 skipping to change at page 28, line 38
enough space in the packet to include it. enough space in the packet to include it.
6.1.3. EID-to-RLOC UDP Map-Request Message 6.1.3. EID-to-RLOC UDP Map-Request Message
A Map-Request is sent from an ITR when it needs a mapping for an EID, A Map-Request is sent from an ITR when it needs a mapping for an EID,
wants to test an RLOC for reachability, or wants to refresh a mapping wants to test an RLOC for reachability, or wants to refresh a mapping
before TTL expiration. For the initial case, the destination IP before TTL expiration. For the initial case, the destination IP
address used for the Map-Request is the destination-EID from the address used for the Map-Request is the destination-EID from the
packet which had a mapping cache lookup failure. For the later 2 packet which had a mapping cache lookup failure. For the later 2
cases, the destination IP address used for the Map-Request is one of cases, the destination IP address used for the Map-Request is one of
the RLOC addresses from the locator-set of the map cache entry. In the RLOC addresses from the locator-set of the map cache entry. The
all cases, the UDP source port number for the Map-Request message is source address is either an IPv4 or IPv6 RLOC address depending if
a randomly allocated 16-bit value and the UDP destination port number the Map-Request is using an IPv4 versus IPv6 header, respectively.
is set to the well-known destination port number 4342. A successful In all cases, the UDP source port number for the Map-Request message
Map-Reply updates the cached set of RLOCs associated with the EID is a randomly allocated 16-bit value and the UDP destination port
prefix range. number is set to the well-known destination port number 4342. A
successful Map-Reply updates the cached set of RLOCs associated with
the EID prefix range.
Map-Requests can also be LISP encapsulated using UDP destination port Map-Requests can also be LISP encapsulated using UDP destination port
4341 when sent from an ITR to a Map-Resolver. Likewise, Map-Requests 4342 with a LISP type value set to "Encapsulated Control Message",
are LISP encapsulated the same way from a Map-Server to an ETR. when sent from an ITR to a Map-Resolver. Likewise, Map-Requests are
Details on encapsulated Map-Requests and Map-Resolvers can be found LISP encapsulated the same way from a Map-Server to an ETR. Details
in [LISP-MS]. on encapsulated Map-Requests and Map-Resolvers can be found in
[LISP-MS].
Map-Requests MUST be rate-limited. It is recommended that a Map- Map-Requests MUST be rate-limited. It is recommended that a Map-
Request for the same EID-prefix be sent no more than once per second. Request for the same EID-prefix be sent no more than once per second.
An ITR that is configured with mapping database information (i.e. it An ITR that is configured with mapping database information (i.e. it
is also an ETR) may optionally include those mappings in a Map- is also an ETR) may optionally include those mappings in a Map-
Request. When an ETR configured to accept and verify such Request. When an ETR configured to accept and verify such
"piggybacked" mapping data receives such a Map-Request, it may "piggybacked" mapping data receives such a Map-Request, it may
originate a "verifying Map-Request", addressed to the original ITR. originate a "verifying Map-Request", addressed to the original ITR.
If the ETR has a map-cache entry that matches the "piggybacked" EID If the ETR has a map-cache entry that matches the "piggybacked" EID
skipping to change at page 30, line 41 skipping to change at page 31, line 28
Locator Count: The number of Locator entries. A locator entry Locator Count: The number of Locator entries. A locator entry
comprises what is labeled above as 'Loc'. The locator count can comprises what is labeled above as 'Loc'. The locator count can
be 0 indicating there are no locators for the EID-prefix. be 0 indicating there are no locators for the EID-prefix.
EID mask-len: Mask length for EID prefix. EID mask-len: Mask length for EID prefix.
ACT: This 3-bit field describes negative Map-Reply actions. These ACT: This 3-bit field describes negative Map-Reply actions. These
bits are used only when the 'Locator Count' field is set to 0. bits are used only when the 'Locator Count' field is set to 0.
The action bits are encoded only in Map-Reply messages. The The action bits are encoded only in Map-Reply messages. The
actions defined are used by an ITR or PTR when a destination EID actions defined are used by an ITR or PTR when a destination EID
matches a negative mapping cache entry. The current assigned matches a negative mapping cache entry. Unassigned values should
cause a map-cache entry to be created and, when packets match this
negative cache entry, they will be dropped. The current assigned
values are: values are:
(0) No action: No action is being conveyed by the sender of the (0) Drop: The packet is dropped silently.
Map-Reply message.
(1) Natively-Forward: The packet is not encapsulated or dropped (1) Natively-Forward: The packet is not encapsulated or dropped
but natively forwarded. but natively forwarded.
(2) Drop: The packet is dropped silently. (2) Send-Map-Request: The packet invokes sending a Map-Request.
(3) Send-Map-Request: The packet invokes sending a Map-Request.
A: The Authoritative bit, when sent by a UDP-based message is always A: The Authoritative bit, when sent by a UDP-based message is always
set by the ETR. See [CONS] for TCP-based Map-Replies. set by the ETR. See [CONS] for TCP-based Map-Replies.
EID-AFI: Address family of EID-prefix according to [RFC2434]. EID-AFI: Address family of EID-prefix according to [RFC2434].
EID-prefix: 4 bytes if an IPv4 address-family, 16 bytes if an IPv6 EID-prefix: 4 bytes if an IPv4 address-family, 16 bytes if an IPv6
address-family. address-family.
Priority: each RLOC is assigned a unicast priority. Lower values Priority: each RLOC is assigned a unicast priority. Lower values
skipping to change at page 33, line 32 skipping to change at page 34, line 18
message. The locator-set MUST be sorted in order of ascending IP message. The locator-set MUST be sorted in order of ascending IP
address where an IPv4 locator address is considered numerically 'less address where an IPv4 locator address is considered numerically 'less
than' an IPv6 locator address. than' an IPv6 locator address.
6.1.6. Map-Register Message Format 6.1.6. Map-Register Message Format
The usage details of the Map-Register message can be found in The usage details of the Map-Register message can be found in
specification [LISP-MS]. This section solely defines the message specification [LISP-MS]. This section solely defines the message
format. format.
The message is sent in a UDP with a destination UDP port 4342 and a The message is sent in UDP with a destination UDP port of 4342 and a
randomly selected UDP port number. Before an IPv4 or IPv6 network randomly selected UDP source port number.
layer header is prepended, an AH header is prepended to carry
authentication information. The format conforms to the IPsec
specification [RFC4302]. The Map-Register message will use transport
mode by setting the IP protocol number field or the IPv6 next-header
field to 51.
The AH header from [RFC4302] is:
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Next Header | Payload Len | RESERVED |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Security Parameters Index (SPI) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Sequence Number Field |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+ Authentication Data (variable) |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The Next Header field is set to UDP. The SPI field is set to 0
(since no Security Association or Key Exchange protocol is being
used). The Sequence Number is a randomly chosen value by the sender.
The Authentication Data is 16 bytes and holds a SHA-1 or SHA-128
HMAC.
The Map-Register message format is: The Map-Register message format is:
0 1 2 3 0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|Type=3 |P| Reserved | Record Count | |Type=3 |P| Reserved | Record Count |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Nonce . . . | | Nonce . . . |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| . . . Nonce | | . . . Nonce |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Key ID | Authentication Data Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~ Authentication Data ~
+-> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | Record TTL | | | Record TTL |
| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
R | Locator Count | EID mask-len | ACT |A| Reserved | R | Locator Count | EID mask-len | ACT |A| Reserved |
e +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ e +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
c | Reserved | EID-AFI | c | Reserved | EID-AFI |
o +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ o +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
r | EID-prefix | r | EID-prefix |
d +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ d +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| /| Priority | Weight | M Priority | M Weight | | /| Priority | Weight | M Priority | M Weight |
skipping to change at page 35, line 46 skipping to change at page 36, line 5
this usage will be provided in a future version of this draft. this usage will be provided in a future version of this draft.
Reserved: Set to 0 on transmission and ignored on receipt. Reserved: Set to 0 on transmission and ignored on receipt.
Record Count: The number of records in this Map-Register message. A Record Count: The number of records in this Map-Register message. A
record is comprised of that portion of the packet labeled 'Record' record is comprised of that portion of the packet labeled 'Record'
above and occurs the number of times equal to Record count. above and occurs the number of times equal to Record count.
Nonce: This 8-byte Nonce field is set to 0 in Map-Register messages. Nonce: This 8-byte Nonce field is set to 0 in Map-Register messages.
Key ID: A configured ID to find the configured Message
Authentication Code (MAC) algorithm and key value used for the
authentication function.
Authentication Data Length: The length in bytes of the
Authentication Data field that follows this field. The length of
the the Authentication Data field is dependent on the Message
Authentication Code (MAC) algorithm used. The length field allows
a device that doesn't know the MAC algorithm to correctly parse
the packet.
Authentication Data: The message digest used from the output of the
Message Authentication Code (MAC) algorithm. The entire Map-
Register payload is authenticated with this field preset to 0.
After the MAC is computed, it is placed in this field.
Implementations of this specification MUST include support for
HMAC-SHA-1-96 [RFC2404] and support for HMAC-SHA-128-256 [RFC4634]
is recommended.
The definition of the rest of the Map-Register can be found in the The definition of the rest of the Map-Register can be found in the
Map-Reply section. Map-Reply section.
6.1.7. Encapsualted Control Message Format
An Encapsulated Control Message is used to encapsulate control
packets sent between xTRs and the mapping database system described
in [LISP-MS].
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
/ | IPv4 or IPv6 Header |
OH | (uses RLOC addresses) |
\ | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
/ | Source Port = xxxx | Dest Port = 4342 |
UDP +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
\ | UDP Length | UDP Checksum |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
LH |Type=8 | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
/ | IPv4 or IPv6 Header |
IH | (uses RLOC or EID addresses) |
\ | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
/ | Source Port = xxxx | Dest Port = yyyy |
UDP +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
\ | UDP Length | UDP Checksum |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
LCM | LISP Control Message |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Packet header descriptions:
OH: The outer IPv4 or IPv6 header which uses RLOC addresses in the
source and destination header address fields.
UDP: The outer UDP header with destination port 4342. The source
port is randomly allocated. The checksum field MUST be non-zero.
LH: Type 8 is defined to be a "LISP Encapsulated Control Message"
and what follows is either an IPv4 or IPv6 header as encoded by
the first 4 bits after the reserved field.
IH: The inner IPv4 or IPv6 header which can use either RLOC or EID
addresses in the header address fields. When a Map-Request is
encapsulated in this packet format the destination address in this
header is an EID.
UDP: The inner UDP header where the port assignments depends on the
control packet being encapsulated. When the control packet is a
Map-Request or Map-Register, the source port is randomly assigned
and the destination port is 4342. When the control packet is a
Map-Reply, the source port is 4342 and the destination port is
assigned from the source port of the invoking Map-Request. Port
number 4341 MUST NOT be assigned to either port. The checksum
field MUST be non-zero.
LCM: The format is one of the control message formats described in
this section. At this time, only Map-Request messages and PIM
Join-Prune messages [MLISP] are allowed to be encapsulated.
Encapsulating other types of LISP control messages are for further
study.
6.2. Routing Locator Selection 6.2. Routing Locator Selection
Both client-side and server-side may need control over the selection Both client-side and server-side may need control over the selection
of RLOCs for conversations between them. This control is achieved by of RLOCs for conversations between them. This control is achieved by
manipulating the Priority and Weight fields in EID-to-RLOC Map-Reply manipulating the Priority and Weight fields in EID-to-RLOC Map-Reply
messages. Alternatively, RLOC information may be gleaned from messages. Alternatively, RLOC information may be gleaned from
received tunneled packets or EID-to-RLOC Map-Request messages. received tunneled packets or EID-to-RLOC Map-Request messages.
The following enumerates different scenarios for choosing RLOCs and The following enumerates different scenarios for choosing RLOCs and
the controls that are available: the controls that are available:
skipping to change at page 62, line 24 skipping to change at page 64, line 24
[RFC1498] Saltzer, J., "On the Naming and Binding of Network [RFC1498] Saltzer, J., "On the Naming and Binding of Network
Destinations", RFC 1498, August 1993. Destinations", RFC 1498, August 1993.
[RFC1955] Hinden, R., "New Scheme for Internet Routing and [RFC1955] Hinden, R., "New Scheme for Internet Routing and
Addressing (ENCAPS) for IPNG", RFC 1955, June 1996. Addressing (ENCAPS) for IPNG", RFC 1955, June 1996.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997. Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2404] Madson, C. and R. Glenn, "The Use of HMAC-SHA-1-96 within
ESP and AH", RFC 2404, November 1998.
[RFC2434] Narten, T. and H. Alvestrand, "Guidelines for Writing an [RFC2434] Narten, T. and H. Alvestrand, "Guidelines for Writing an
IANA Considerations Section in RFCs", BCP 26, RFC 2434, IANA Considerations Section in RFCs", BCP 26, RFC 2434,
October 1998. October 1998.
[RFC2784] Farinacci, D., Li, T., Hanks, S., Meyer, D., and P. [RFC2784] Farinacci, D., Li, T., Hanks, S., Meyer, D., and P.
Traina, "Generic Routing Encapsulation (GRE)", RFC 2784, Traina, "Generic Routing Encapsulation (GRE)", RFC 2784,
March 2000. March 2000.
[RFC3056] Carpenter, B. and K. Moore, "Connection of IPv6 Domains [RFC3056] Carpenter, B. and K. Moore, "Connection of IPv6 Domains
via IPv4 Clouds", RFC 3056, February 2001. via IPv4 Clouds", RFC 3056, February 2001.
skipping to change at page 62, line 45 skipping to change at page 64, line 48
[RFC3168] Ramakrishnan, K., Floyd, S., and D. Black, "The Addition [RFC3168] Ramakrishnan, K., Floyd, S., and D. Black, "The Addition
of Explicit Congestion Notification (ECN) to IP", of Explicit Congestion Notification (ECN) to IP",
RFC 3168, September 2001. RFC 3168, September 2001.
[RFC3775] Johnson, D., Perkins, C., and J. Arkko, "Mobility Support [RFC3775] Johnson, D., Perkins, C., and J. Arkko, "Mobility Support
in IPv6", RFC 3775, June 2004. in IPv6", RFC 3775, June 2004.
[RFC4086] Eastlake, D., Schiller, J., and S. Crocker, "Randomness [RFC4086] Eastlake, D., Schiller, J., and S. Crocker, "Randomness
Requirements for Security", BCP 106, RFC 4086, June 2005. Requirements for Security", BCP 106, RFC 4086, June 2005.
[RFC4302] Kent, S., "IP Authentication Header", RFC 4302,
December 2005.
[RFC4423] Moskowitz, R. and P. Nikander, "Host Identity Protocol [RFC4423] Moskowitz, R. and P. Nikander, "Host Identity Protocol
(HIP) Architecture", RFC 4423, May 2006. (HIP) Architecture", RFC 4423, May 2006.
[RFC4634] Eastlake, D. and T. Hansen, "US Secure Hash Algorithms
(SHA and HMAC-SHA)", RFC 4634, July 2006.
[RFC4866] Arkko, J., Vogt, C., and W. Haddad, "Enhanced Route [RFC4866] Arkko, J., Vogt, C., and W. Haddad, "Enhanced Route
Optimization for Mobile IPv6", RFC 4866, May 2007. Optimization for Mobile IPv6", RFC 4866, May 2007.
[RFC4984] Meyer, D., Zhang, L., and K. Fall, "Report from the IAB [RFC4984] Meyer, D., Zhang, L., and K. Fall, "Report from the IAB
Workshop on Routing and Addressing", RFC 4984, Workshop on Routing and Addressing", RFC 4984,
September 2007. September 2007.
[UDP-TUNNELS] [UDP-TUNNELS]
Eubanks, M. and P. Chimento, "UDP Checksums for Tunneled Eubanks, M. and P. Chimento, "UDP Checksums for Tunneled
Packets"", draft-eubanks-chimento-6man-00.txt (work in Packets"", draft-eubanks-chimento-6man-00.txt (work in
skipping to change at page 64, line 24 skipping to change at page 66, line 27
Farinacci, D., Fuller, V., Meyer, D., and D. Lewis, Farinacci, D., Fuller, V., Meyer, D., and D. Lewis,
"Locator/ID Separation Protocol (LISP)", "Locator/ID Separation Protocol (LISP)",
draft-farinacci-lisp-12.txt (work in progress), draft-farinacci-lisp-12.txt (work in progress),
March 2009. March 2009.
[LISP-MN] Farinacci, D., Fuller, V., Lewis, D., and D. Meyer, "LISP [LISP-MN] Farinacci, D., Fuller, V., Lewis, D., and D. Meyer, "LISP
Mobility Architecture", draft-meyer-lisp-mn-00.txt (work Mobility Architecture", draft-meyer-lisp-mn-00.txt (work
in progress), July 2009. in progress), July 2009.
[LISP-MS] Farinacci, D. and V. Fuller, "LISP Map Server", [LISP-MS] Farinacci, D. and V. Fuller, "LISP Map Server",
draft-ietf-lisp-ms-02.txt (work in progress), draft-ietf-lisp-ms-03.txt (work in progress),
September 2009. September 2009.
[LISP1] Farinacci, D., Oran, D., Fuller, V., and J. Schiller, [LISP1] Farinacci, D., Oran, D., Fuller, V., and J. Schiller,
"Locator/ID Separation Protocol (LISP1) [Routable ID "Locator/ID Separation Protocol (LISP1) [Routable ID
Version]", Version]",
Slide-set http://www.dinof.net/~dino/ietf/lisp1.ppt, Slide-set http://www.dinof.net/~dino/ietf/lisp1.ppt,
October 2006. October 2006.
[LISP2] Farinacci, D., Oran, D., Fuller, V., and J. Schiller, [LISP2] Farinacci, D., Oran, D., Fuller, V., and J. Schiller,
"Locator/ID Separation Protocol (LISP2) [DNS-based "Locator/ID Separation Protocol (LISP2) [DNS-based
skipping to change at page 65, line 4 skipping to change at page 67, line 7
February 2008. February 2008.
[LOC-ID-ARCH] [LOC-ID-ARCH]
Meyer, D. and D. Lewis, "Architectural Implications of Meyer, D. and D. Lewis, "Architectural Implications of
Locator/ID Separation", Locator/ID Separation",
draft-meyer-loc-id-implications-01.txt (work in progress), draft-meyer-loc-id-implications-01.txt (work in progress),
Januaryr 2009. Januaryr 2009.
[MLISP] Farinacci, D., Meyer, D., Zwiebel, J., and S. Venaas, [MLISP] Farinacci, D., Meyer, D., Zwiebel, J., and S. Venaas,
"LISP for Multicast Environments", "LISP for Multicast Environments",
draft-ietf-lisp-multicast-01.txt (work in progress), draft-ietf-lisp-multicast-02.txt (work in progress),
May 2009. September 2009.
[NERD] Lear, E., "NERD: A Not-so-novel EID to RLOC Database", [NERD] Lear, E., "NERD: A Not-so-novel EID to RLOC Database",
draft-lear-lisp-nerd-04.txt (work in progress), draft-lear-lisp-nerd-04.txt (work in progress),
April 2008. April 2008.
[OPENLISP] [OPENLISP]
Iannone, L. and O. Bonaventure, "OpenLISP Implementation Iannone, L. and O. Bonaventure, "OpenLISP Implementation
Report", draft-iannone-openlisp-implementation-01.txt Report", draft-iannone-openlisp-implementation-01.txt
(work in progress), July 2008. (work in progress), July 2008.
skipping to change at page 66, line 29 skipping to change at page 68, line 29
They include Scott Brim, Andrew Partan, John Zwiebel, Jason Schiller, They include Scott Brim, Andrew Partan, John Zwiebel, Jason Schiller,
Lixia Zhang, Dorian Kim, Peter Schoenmaker, Vijay Gill, Geoff Huston, Lixia Zhang, Dorian Kim, Peter Schoenmaker, Vijay Gill, Geoff Huston,
David Conrad, Mark Handley, Ron Bonica, Ted Seely, Mark Townsley, David Conrad, Mark Handley, Ron Bonica, Ted Seely, Mark Townsley,
Chris Morrow, Brian Weis, Dave McGrew, Peter Lothberg, Dave Thaler, Chris Morrow, Brian Weis, Dave McGrew, Peter Lothberg, Dave Thaler,
Eliot Lear, Shane Amante, Ved Kafle, Olivier Bonaventure, Luigi Eliot Lear, Shane Amante, Ved Kafle, Olivier Bonaventure, Luigi
Iannone, Robin Whittle, Brian Carpenter, Joel Halpern, Roger Iannone, Robin Whittle, Brian Carpenter, Joel Halpern, Roger
Jorgensen, Ran Atkinson, Stig Venaas, Iljitsch van Beijnum, Roland Jorgensen, Ran Atkinson, Stig Venaas, Iljitsch van Beijnum, Roland
Bless, Dana Blair, Bill Lynch, Marc Woolward, Damien Saucez, Damian Bless, Dana Blair, Bill Lynch, Marc Woolward, Damien Saucez, Damian
Lezama, Attilla De Groot, Parantap Lahiri, David Black, Roque Lezama, Attilla De Groot, Parantap Lahiri, David Black, Roque
Gagliano, Isidor Kouvelas, Jesper Skriver, Fred Templin, Margaret Gagliano, Isidor Kouvelas, Jesper Skriver, Fred Templin, Margaret
Wasserman, Sam Hartman, Michael Hofling, and Pedro Marques. Wasserman, Sam Hartman, Michael Hofling, Pedro Marques, and Jari
Arkko.
In particular, we would like to thank Dave Meyer for his clever In particular, we would like to thank Dave Meyer for his clever
suggestion for the name "LISP". ;-) suggestion for the name "LISP". ;-)
This work originated in the Routing Research Group (RRG) of the IRTF. This work originated in the Routing Research Group (RRG) of the IRTF.
The individual submission [LISP-MAIN] was converted into this IETF The individual submission [LISP-MAIN] was converted into this IETF
LISP working group draft. LISP working group draft.
Appendix B. Document Change Log
B.1. Changes to draft-ietf-lisp-05.txt
o Posted September 2009.
o Added this Document Change Log appendix.
o Added section indicating that encapsulated Map-Requests must use
destination UDP port 4342.
o Don't use AH in Map-Registers. Put key-id, auth-length, and auth-
data in Map-Register payload.
o Added Jari to acknowledgment section.
o State the source-EID is set to 0 when using Map-Requests to
refresh or RLOC-probe.
o Make more clear what source-RLOC should be for a Map-Request.
o The LISP-CONS authors thought that the Type definitions for CONS
should be removed from this specification.
o Removed nonce from Map-Register message, it wasn't used so no need
for it.
o Clarify what to do for unspecified Action bits for negative Map-
Replies. Since No Action is a drop, make value 0 Drop.
B.2. Changes to draft-ietf-lisp-04.txt
o Posted September 2009.
o How do deal with record count greater than 1 for a Map-Request.
Damien and Joel comment. Joel suggests: 1) Specify that senders
compliant with the current document will always set the count to
1, and note that the count is included for future extensibility.
2) Specify what a receiver compliant with the draft should do if
it receives a request with a count greater than 1. Presumably, it
should send some error back?
o Add Fred Templin in ack section.
o Add Margaret and Sam to the ack section for their great comments.
o Say more about LAGs in the UDP section per Sam Hartman's comment.
o Sam wants to use MAY instead of SHOULD for ignoring checksums on
ETR. From the mailing list: "You'd need to word it as an ITR MAY
send a zero checksum, an ETR MUST accept a 0 checksum and MAY
ignore the checksum completely. And of course we'd need to
confirm that can actually be implemented. In particular, hardware
that verifies UDP checksums on receive needs to be checked to make
sure it permits 0 checksums."
o Margaret wants a reference to
http://www.ietf.org/id/draft-eubanks-chimento-6man-00.txt.
o Fix description in Map-Request section. Where we describe Map-
Reply Record, change "R-bit" to "M-bit".
o Add the mobility bit to Map-Replies. So PTRs don't probe so often
for MNs but often enough to get mapping updates.
o Indicate SHA1 can be used as well for Map-Registers.
o More Fred comments on MTU handling.
o Isidor comment about specing better periodic Map-Registers. Will
be fixed in draft-ietf-lisp-ms-02.txt.
o Margaret's comment on gleaning: "The current specification does
not make it clear how long gleaned map entries should be retained
in the cache, nor does it make it clear how/ when they will be
validated. The LISP spec should, at the very least, include a
(short) default lifetime for gleaned entries, require that they be
validated within a short period of time, and state that a new
gleaned entry should never overwrite an entry that was obtained
from the mapping system. The security implications of storing
"gleaned" entries should also be explored in detail."
o Add section on RLOC-probing per working group feedback.
o Change "loc-reach-bits" to "loc-status-bits" per comment from
Noel.
o Remove SMR-bit from data-plane. Dino prefers to have it in the
control plane only.
o Change LISP header to allow a "Research Bit" so the Nonce and LSB
fields can be turned off and used for another future purpose. For
Luigi et al versioning convergence.
o Add a N-bit to the data header suggested by Noel. Then the nonce
field could be used when N is not 1.
o Clarify that when E-bit is 0, the nonce field can be an echoed
nonce or a random nonce. Comment from Jesper.
o Indicate when doing data-gleaning that a verifying Map-Request is
sent to the source-EID of the gleaned data packet so we can avoid
map-cache corruption by a 3rd party. Comment from Pedro.
o Indicate that a verifying Map-Request, for accepting mapping data,
should be sent over the the ALT (or to the EID).
o Reference IPsec RFC 4302. Comment from Sam and Brian Weis.
o Put E-bit in Map-Reply to tell ITRs that the ETR supports echo-
noncing. Comment by Pedro and Dino.
o Jesper made a comment to loosen the language about requiring the
copy of inner TTL to outer TTL since the text to get mixed-AF
traceroute to work would violate the "MUST" clause. Changed from
MUST to SHOULD in section 5.3.
B.3. Changes to draft-ietf-lisp-03.txt
o Posted July 2009.
o Removed loc-reach-bits longword from control packets per Damien
comment.
o Clarifications in MTU text from Roque.
o Added text to indicate that the locator-set be sorted by locator
address from Isidor.
o Clarification text from JohnZ in Echo-Nonce section.
B.4. Changes to draft-ietf-lisp-02.txt
o Posted July 2009.
o Encapsulation packet format change to add E-bit and make loc-
reach-bits 32-bits in length.
o Added Echo-Nonce Algorithm section.
o Clarification how ECN bits are copied.
o Moved S-bit in Map-Request.
o Added P-bit in Map-Request and Map-Reply messages to anticipate
RLOC-Probe Algorithm.
o Added to Mobility section to reference draft-meyer-lisp-mn-00.txt.
B.5. Changes to draft-ietf-lisp-01.txt
o Posted 2 days after draft-ietf-lisp-00.txt in May 2009.
o Defined LEID to be a "LISP EID".
o Indicate encapsulation use IPv4 DF=0.
o Added negative Map-Reply messages with drop, native-forward, and
send-map-request actions.
o Added Proxy-Map-Reply bit to Map-Register.
B.6. Changes to draft-ietf-lisp-00.txt
o Posted May 2009.
o Rename of draft-farinacci-lisp-12.txt.
o Acknowledgment to RRG.
Authors' Addresses Authors' Addresses
Dino Farinacci Dino Farinacci
cisco Systems cisco Systems
Tasman Drive Tasman Drive
San Jose, CA 95134 San Jose, CA 95134
USA USA
Email: dino@cisco.com Email: dino@cisco.com
 End of changes. 23 change blocks. 
99 lines changed or deleted 340 lines changed or added

This html diff was produced by rfcdiff 1.37a. The latest version is available from http://tools.ietf.org/tools/rfcdiff/