draft-ietf-lisp-lcaf-03.txt   draft-ietf-lisp-lcaf-04.txt 
Network Working Group D. Farinacci Network Working Group D. Farinacci
Internet-Draft lispers.net Internet-Draft lispers.net
Intended status: Experimental D. Meyer Intended status: Experimental D. Meyer
Expires: March 20, 2014 Brocade Expires: July 31, 2014 Brocade
J. Snijders J. Snijders
Hibernia Networks Hibernia Networks
September 16, 2013 January 27, 2014
LISP Canonical Address Format (LCAF) LISP Canonical Address Format (LCAF)
draft-ietf-lisp-lcaf-03 draft-ietf-lisp-lcaf-04
Abstract Abstract
This draft defines a canonical address format encoding used in LISP This draft defines a canonical address format encoding used in LISP
control messages and in the encoding of lookup keys for the LISP control messages and in the encoding of lookup keys for the LISP
Mapping Database System. Mapping Database System.
Status of this Memo Status of this Memo
This Internet-Draft is submitted in full conformance with the This Internet-Draft is submitted in full conformance with the
skipping to change at page 1, line 35 skipping to change at page 1, line 35
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/. Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
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."
This Internet-Draft will expire on March 20, 2014. This Internet-Draft will expire on July 31, 2014.
Copyright Notice Copyright Notice
Copyright (c) 2013 IETF Trust and the persons identified as the Copyright (c) 2014 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 Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of (http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
skipping to change at page 2, line 39 skipping to change at page 2, line 39
4.15.3. ASCII Names in the Mapping Database . . . . . . . . . 25 4.15.3. ASCII Names in the Mapping Database . . . . . . . . . 25
4.15.4. Using Recursive LISP Canonical Address Encodings . . 26 4.15.4. Using Recursive LISP Canonical Address Encodings . . 26
4.15.5. Compatibility Mode Use Case . . . . . . . . . . . . . 27 4.15.5. Compatibility Mode Use Case . . . . . . . . . . . . . 27
5. Security Considerations . . . . . . . . . . . . . . . . . . . 28 5. Security Considerations . . . . . . . . . . . . . . . . . . . 28
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 29 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 29
7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 30 7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 30
7.1. Normative References . . . . . . . . . . . . . . . . . . . 30 7.1. Normative References . . . . . . . . . . . . . . . . . . . 30
7.2. Informative References . . . . . . . . . . . . . . . . . . 30 7.2. Informative References . . . . . . . . . . . . . . . . . . 30
Appendix A. Acknowledgments . . . . . . . . . . . . . . . . . . . 32 Appendix A. Acknowledgments . . . . . . . . . . . . . . . . . . . 32
Appendix B. Document Change Log . . . . . . . . . . . . . . . . . 33 Appendix B. Document Change Log . . . . . . . . . . . . . . . . . 33
B.1. Changes to draft-ietf-lisp-lcaf-03.txt . . . . . . . . . . 33 B.1. Changes to draft-ietf-lisp-lcaf-04.txt . . . . . . . . . . 33
B.2. Changes to draft-ietf-lisp-lcaf-02.txt . . . . . . . . . . 33 B.2. Changes to draft-ietf-lisp-lcaf-03.txt . . . . . . . . . . 33
B.3. Changes to draft-ietf-lisp-lcaf-01.txt . . . . . . . . . . 33 B.3. Changes to draft-ietf-lisp-lcaf-02.txt . . . . . . . . . . 33
B.4. Changes to draft-ietf-lisp-lcaf-00.txt . . . . . . . . . . 33 B.4. Changes to draft-ietf-lisp-lcaf-01.txt . . . . . . . . . . 33
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 34 B.5. Changes to draft-ietf-lisp-lcaf-00.txt . . . . . . . . . . 33
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 35
1. Introduction 1. Introduction
The LISP architecture and protocols [RFC6830] introduces two new The LISP architecture and protocols [RFC6830] introduces two new
numbering spaces, Endpoint Identifiers (EIDs) and Routing Locators numbering spaces, Endpoint Identifiers (EIDs) and Routing Locators
(RLOCs) which are intended to replace most use of IP addresses on the (RLOCs) which are intended to replace most use of IP addresses on the
Internet. To provide flexibility for current and future Internet. To provide flexibility for current and future
applications, these values can be encoded in LISP control messages applications, these values can be encoded in LISP control messages
using a general syntax that includes Address Family Identifier (AFI), using a general syntax that includes Address Family Identifier (AFI),
length, and value fields. length, and value fields.
skipping to change at page 18, line 20 skipping to change at page 18, line 20
Explicit Locator Path (ELP) Canonical Address Format: Explicit Locator Path (ELP) Canonical Address 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| AFI = 16387 | Rsvd1 | Flags | | AFI = 16387 | Rsvd1 | Flags |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type = 10 | Rsvd2 | n | | Type = 10 | Rsvd2 | n |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| AFI = x | Rsvd3 |L|P|S| | Rsvd3 |L|P|S| AFI = x |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Reencap Hop 1 ... | | Reencap Hop 1 ... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| AFI = x | Rsvd3 |L|P|S| | Rsvd3 |L|P|S| AFI = x |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Reencap Hop k ... | | Reencap Hop k ... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Length value n: length in bytes of fields that follow. Length value n: length in bytes of fields that follow.
AFI = x: x can be any AFI value from [AFI]. When a specific AFI has
its own encoding of a multicast address, this field must be either
a group address or a broadcast address.
Lookup bit (L): this is the Lookup bit used to indicate to the user Lookup bit (L): this is the Lookup bit used to indicate to the user
of the ELP to not use this address for encapsulation but to look of the ELP to not use this address for encapsulation but to look
it up in the mapping database system to obtain an encapsulating it up in the mapping database system to obtain an encapsulating
RLOC address. RLOC address.
RLOC-Probe bit (P): this is the RLOC-probe bit which means the RLOC-Probe bit (P): this is the RLOC-probe bit which means the
Reencap Hop allows RLOC-probe messages to be sent to it. When the Reencap Hop allows RLOC-probe messages to be sent to it. When the
R-bit is set to 0, RLOC-probes must not be sent. When a Reencap R-bit is set to 0, RLOC-probes must not be sent. When a Reencap
Hop is an anycast address then multiple physical Reencap Hops are Hop is an anycast address then multiple physical Reencap Hops are
using the same RLOC address. In this case, RLOC-probes are not using the same RLOC address. In this case, RLOC-probes are not
needed because when the closest RLOC address is not reachable needed because when the closest RLOC address is not reachable
another RLOC address can reachable. another RLOC address can reachable.
Strict bit (S): this the strict bit which means the associated Strict bit (S): this the strict bit which means the associated
Rencap Hop is required to be used. If this bit is 0, the Rencap Hop is required to be used. If this bit is 0, the
reencapsulator can skip this Reencap Hop and go to the next one in reencapsulator can skip this Reencap Hop and go to the next one in
the list. the list.
AFI = x: x can be any AFI value from [AFI]. When a specific AFI has
its own encoding of a multicast address, this field must be either
a group address or a broadcast address.
4.10. Storing Security Data in the Mapping Database 4.10. Storing Security Data in the Mapping Database
When a locator in a locator-set has a security key associated with When a locator in a locator-set has a security key associated with
it, this LCAF format will be used to encode key material. See it, this LCAF format will be used to encode key material. See
[LISP-DDT] for details. [LISP-DDT] for details.
Security Key Canonical Address Format: Security Key Canonical Address 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
skipping to change at page 33, line 7 skipping to change at page 33, line 7
List Entry LCAF type. List Entry LCAF type.
Thanks goes to Michiel Blokzijl and Alberto Rodriguez-Natal for Thanks goes to Michiel Blokzijl and Alberto Rodriguez-Natal for
suggesting new LCAF types. suggesting new LCAF types.
Thanks also goes to Terry Manderson for assistance obtaining a LISP Thanks also goes to Terry Manderson for assistance obtaining a LISP
AFI value from IANA. AFI value from IANA.
Appendix B. Document Change Log Appendix B. Document Change Log
B.1. Changes to draft-ietf-lisp-lcaf-03.txt B.1. Changes to draft-ietf-lisp-lcaf-04.txt
o Submitted January 2014.
o Agreement among ELP implementors to have the AFI 16-bit field
adjacent to the address. This will make the encoding consistent
with all other LCAF type address encodings.
B.2. Changes to draft-ietf-lisp-lcaf-03.txt
o Submitted September 2013. o Submitted September 2013.
o Updated references and author's affilations. o Updated references and author's affilations.
o Added Instance-ID to the Multicast Info Type so there is relative o Added Instance-ID to the Multicast Info Type so there is relative
ease in parsing (S,G) entries within a VPN. ease in parsing (S,G) entries within a VPN.
o Add port range encodings to the Application Data LCAF Type. o Add port range encodings to the Application Data LCAF Type.
o Add a new JSON LCAF Type. o Add a new JSON LCAF Type.
o Add Address Key/Value LCAF Type to allow attributes to be attached o Add Address Key/Value LCAF Type to allow attributes to be attached
to an address. to an address.
B.2. Changes to draft-ietf-lisp-lcaf-02.txt B.3. Changes to draft-ietf-lisp-lcaf-02.txt
o Submitted March 2013. o Submitted March 2013.
o Added new LCAF Type "Replication List Entry" to support LISP o Added new LCAF Type "Replication List Entry" to support LISP
replication engineering use-cases. replication engineering use-cases.
o Changed references to new LISP RFCs. o Changed references to new LISP RFCs.
B.3. Changes to draft-ietf-lisp-lcaf-01.txt B.4. Changes to draft-ietf-lisp-lcaf-01.txt
o Submitted January 2013. o Submitted January 2013.
o Change longitude range from 0-90 to 0-180 in section 4.4. o Change longitude range from 0-90 to 0-180 in section 4.4.
o Added reference to WGS-84 in section 4.4. o Added reference to WGS-84 in section 4.4.
B.4. Changes to draft-ietf-lisp-lcaf-00.txt B.5. Changes to draft-ietf-lisp-lcaf-00.txt
o Posted first working group draft August 2012. o Posted first working group draft August 2012.
o This draft was renamed from draft-farinacci-lisp-lcaf-10.txt. o This draft was renamed from draft-farinacci-lisp-lcaf-10.txt.
Authors' Addresses Authors' Addresses
Dino Farinacci Dino Farinacci
lispers.net lispers.net
San Jose, CA San Jose, CA
 End of changes. 14 change blocks. 
20 lines changed or deleted 29 lines changed or added

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