Internet DRAFT - draft-herbert-ila-messages
draft-herbert-ila-messages
INTERNET-DRAFT T. Herbert
Intended Status: Informational Facebook
Expires: September 22, 2016
March 21, 2016
ILA Control Messages
draft-herbert-ila-messages-00
Abstract
This specification defines control messages for Identifier Locator
Addressing. These control messages are sent between ILA hosts or from
ILA routers to ILA hosts to notify a sending host to change its entry
for an identifier in its ILA mapping table. Messages indicate that no
mapping was found for a destination identifier or indicate a redirect
to use a different locator for an identifier.
Status of this Memo
This Internet-Draft is submitted to IETF in full conformance with the
provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as
Internet-Drafts.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at
http://www.ietf.org/1id-abstracts.html
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html
Copyright and License Notice
Copyright (c) 2016 IETF Trust and the persons identified as the
document authors. All rights reserved.
Herbert Expires September 22, 2016 [Page 1]
INTERNET DRAFT ILA Control Messages March 21, 2016
This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License.
Table of Contents
1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2 ILA control message format . . . . . . . . . . . . . . . . . . . 4
2.1 Host No Identifier . . . . . . . . . . . . . . . . . . . . . 5
2.2 Router No Mapping . . . . . . . . . . . . . . . . . . . . . 6
2.3 Host redirect . . . . . . . . . . . . . . . . . . . . . . . 7
2.4 Router redirect . . . . . . . . . . . . . . . . . . . . . . 7
3. Operation . . . . . . . . . . . . . . . . . . . . . . . . . . . 8
3.1 Host control message generation . . . . . . . . . . . . . . 8
3.2 ILA router processing . . . . . . . . . . . . . . . . . . . 10
3.3 Host processing of received ILA messages . . . . . . . . . . 11
3.4 Other properties . . . . . . . . . . . . . . . . . . . . . . 12
4 Security Considerations . . . . . . . . . . . . . . . . . . . . 12
4.1 HMAC authentication and integrity . . . . . . . . . . . . . 12
4.1.1 Security fields in ILA control messages . . . . . . . . 13
4.1.2 Selecting a hash algorithm . . . . . . . . . . . . . . 13
4.1.3 Pre-shared key management . . . . . . . . . . . . . . . 14
4.2 DTLS . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14
5 IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 14
6 References . . . . . . . . . . . . . . . . . . . . . . . . . . 14
6.1 Normative References . . . . . . . . . . . . . . . . . . . 14
6.2 Informative References . . . . . . . . . . . . . . . . . . 15
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 15
Herbert Expires September 22, 2016 [Page 2]
INTERNET DRAFT ILA Control Messages March 21, 2016
1 Introduction
Identifier locator addressing is described in [I-D.herbert-nvo3-ila]
and an architecture for ILA deployment is described in [I-D.lapukhov-
ila-deployment]. In this specification we describe ILA control
messages. These are messages concerning the state of ILA mappings and
are sent between ILA hosts or between ILA routers and ILA hosts.
These messages are sent in response to data plane packets in order to
notify a sender about status of the ILA mapping for the identifier in
a destination address. There are four different types of
notifications:
o "Host No Identifier" is sent by an ILA host if it receives a
packet addressed with its local locator but cannot match the
identifier.
o "Router No Mapping" is sent by an ILA router when it receives a
SIR addressed packet however does not have a mapping for the
identifier. In this case the destination identifier is
unreachable
o "Host redirect" is sent by an ILA host when it receives a packet
addressed with its local locator and the identifier has a
forwarding mapping entry. This is used to redirect senders to a
new location after an identifier has been moved to a different
host.
o "Router redirect" is sent by an ILA router when it receives a
SIR addressed packet and the locator for the identifier is in
the mapping table. Upon receiving this message a host is able to
send packets directly using the locator instead of the SIR
address.
Herbert Expires September 22, 2016 [Page 3]
INTERNET DRAFT ILA Control Messages March 21, 2016
2 ILA control message format
ILA messages are sent in the payload of UDPv6 packets. The general
format 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|Version| Traffic Class | Flow Label |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Payload Length | NxtHdr=17(UDP)| Hop Limit |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+ +
| |
+ Source Address +
| |
+ +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+ +
| |
+ Destination Address +
| |
+ +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Source port | Destination port |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Length | Checksum |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|H| Reserved | Code | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
~ Data ~
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
| |
~ HMAC (256 bits) (optional) ~
| |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
o Source address is the common locator address (CLA) of the device
Herbert Expires September 22, 2016 [Page 4]
INTERNET DRAFT ILA Control Messages March 21, 2016
sending the message. (the common locator address has the form:
<locator>::1).
o Destination address is the common locator address derived from
the source address of the received packet. The source address of
the received packet is a SIR address, so to send an ILA control
message the SIR address must be reverse mapped to a locator
which is set in the CLA.
o Source port: set to ILA control message port number (assignment
TDB).
o Destination UDP port: set to ILA control message port number
(assignment TBD).
o H: Indicates the HMAC field is present.
o Code indicates the type of the ILA message. Defined codes are:
o 0x1: Host No Identifier
o 0x2: Router No Mapping
o 0x3: Host Redirect
o 0x4: Router Redirect
o Data: The data portion of the control messages.
o HMAC: HMAC Key ID and HMAC field, and their use are defined in
Section 4.
2.1 Host No Identifier
The Host No Identifier message is sent by an ILA host if it
receives a packet addressed with its local locator but cannot
match the identifier. The format of this message is:
Herbert Expires September 22, 2016 [Page 5]
INTERNET DRAFT ILA Control Messages March 21, 2016
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|H| Reserved | 0x1 | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| SIR prefix |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Identifier |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Original locator |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
o SIR prefix: the SIR prefix associated with the locator of the
sending host (i.e. the locator in the original packet)
o Identifier: The identifier received in the packet. The host
sending the ILA message has no mapping for this identifier.
o Original locator: The locator that was in the destination
address of the received packet. If there is a only one locator
assigned per host this will be the same as the locator used in
the source address of the ILA message (see above).
2.2 Router No Mapping
Router No Mapping is sent by an ILA router when it receives a
SIR addressed packet however does not have a mapping for the
identifier. The format of this message 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|H| Reserved | 0x2 | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| SIR prefix |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Identifier |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
o SIR prefix: the SIR prefix associated with the locator of the
sending host (i.e. the locator in the original packet)
o Identifier: The identifier received in the packet. The ILA
Herbert Expires September 22, 2016 [Page 6]
INTERNET DRAFT ILA Control Messages March 21, 2016
router sending the ILA message has no mapping for this
identifier.
2.3 Host redirect
A Host Redirect is sent by an ILA host when receives a packet
addressed with its local locator and the identifier has a forwarding
mapping entry. The format of this message 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|H| Reserved | 0x3 | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| SIR prefix |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Identifier |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Old locator |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| New Locator |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
o SIR prefix: the SIR prefix associated with the locator of the
sending host (i.e. the locator in the original packet)
o Identifier: The identifier received in the packet. The host
sending the ILA message is suggesting a new locator for this
identifier.
o Old locator: The locator that was set in destination of the
received packet.
o New Locator: The locator that the a sending host is being
redirected to use.
2.4 Router redirect
A Router Redirect is sent by an ILA router when it receives a SIR
addressed packet and the locator for the identifier in the
destination address is in the mapping table. The format of this
message is:
Herbert Expires September 22, 2016 [Page 7]
INTERNET DRAFT ILA Control Messages March 21, 2016
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|H| Reserved | 0x4 | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| SIR prefix |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Identifier |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Locator |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
o SIR prefix: the SIR prefix associated with the locator of the
sending host (i.e. the locator in the original packet)
o Identifier: The identifier received in the packet. The router
sending the ILA message is suggesting a new locator for this
identifier.
o Locator: The locator that the a sending host is being redirected
to use.
3. Operation
ILA messages can only be sent in response to packets whose source
address is a SIR address in the same domain as the host or router
sending the control messages. ILA messages must not be sent to non-
ILA hosts or ILA hosts in a different domain (i.e. use a different
SIR prefix).
ILA messages must be verified for authenticity (see Section 4).
3.1 Host control message generation
An ILA host may send control messages in response to packets received
that have its local locator in the destination address.
The steps in receive processing of an ILA host are:
1) Receive packets where the destination locator matches the local
locator of the host.
2) Lookup the identifier in the destination address in the ILA
locator mapping database.
Herbert Expires September 22, 2016 [Page 8]
INTERNET DRAFT ILA Control Messages March 21, 2016
3) If the identifier is found and it is marked as a local
identifier (i.e. this is the location for the identifier), then
overwrite the locator in the destination address with the SIR
prefix and receive the packet in the local stack as per ILA
processing.
4) Else, if the source address is not a SIR address in the same
ILA domain as the host, then drop the packet and take no
further action.
5) Lookup the identifier in the source address in the ILA mapping
table. If no entry is found or there is no locator associated
with the entry, then drop the packet and take no further
action.
6) If the identifier in the destination address was found in the
mapping database and there is a forwarding address set in the
mapping entry, then send a Host Redirect message:
a) The destination address of the control message is set to the
common locator address which is comprised of the locator
associated with the identifier in the source address and ::1
in the low order 64 bits.
b) The source address of the control message packet is set to
the common locator address of the host sending the message.
c) The SIR prefix in the control message is set to that
associated with the locator the packet was received on.
d) The identifier in the control message is set to the
identifier in the destination address of the received packet.
e) The Old Locator in the control message is set to the locator
in the destination address of the received packet (should be
a local locator).
f) The New locator in the control message data is set to the
corresponding value in the mapping table.
7) Else, send a Host No Identifier. The host has no information
regarding the received identifier:
a) The destination address of the control message is set to the
common locator address which is comprised of the locator
associated with the identifier in the source address and ::1
in the low order 64 bits.
b) The source address of the control message packet is set to
the common locator address of the host sending the message.
c) The SIR prefix in the control message is set to that
associated with the locator the packet was received on.
d) The identifier in the control message is set to the
identifier in the destination address of the received packet.
Herbert Expires September 22, 2016 [Page 9]
INTERNET DRAFT ILA Control Messages March 21, 2016
e) The Original Locator in the control message is set to the
locator in the destination address of the received packet
(should be a local locator).
3.2 ILA router processing
An ILA router should send control messages in response to packets
received whose destination address is a SIR address.
The steps in receive processing of an ILA router are:
1) Receive anycast SIR addressed packets that are routed to the
router.
2) Lookup the identifier in the destionation address in the ILA
locator database.
3) If an entry for the identifier is found and there is an
associated locator, then overwrite the SIR prefix in the
destination address with the found locator and forward the
packet per ILA processing.
4) Else, if the source address is not a SIR address in the same
ILA domain as the host, then drop the packet and take no
further action.
5) Lookup the identifier in the source address in the ILA mapping
table. If no entry is found or there is no locator associated
with the entry, then take no further action.
6) If the locator was found in the mapping table then send a
Router Redirect message:
a) The destination address of the control message is set to the
common locator address which is comprised of the locator
associated with the identifier in the source address and ::1
in the low order 64 bits.
b) The source address of the control message packet is set to
the common locator address of the ILA router sending the
message.
c) The SIR prefix in the control message is set to that
associated with the locator the packet was received on.
d) The identifier in the control message is set to the
identifier in the destination address of the received packet.
f) The Locator in the control message data is set to the
corresponding value in the mapping table.
7) Else, send a Router No Mapping messages
Herbert Expires September 22, 2016 [Page 10]
INTERNET DRAFT ILA Control Messages March 21, 2016
a) The destination address of the control message is set to the
common locator address which is comprised of the locator
associated with the identifier in the source address and ::1
in the low order 64 bits.
b) The source address of the control message packet is set to
the common locator address of the ILA router sending the
message.
c) The SIR prefix in the control message is set to that
associated with the locator the packet was received on.
d) The identifier in the control message is set to the
identifier in the destination address of the received packet.
3.3 Host processing of received ILA messages
Hosts listen on the appropriate UDP port for ILA control messages.
The steps in processing control messages are:
1) Control messages are received on the common locator address for
the host.
2) If the message code is Host No Mapping
a) Lookup the specified identifier in the ILA mapping cache. If
an entry is found, there is a locator in the mapping, and the
locator matches that in the Original Locator in the control
message-- then invalidate the locator. The next packet that
is sent to that identifier will not be translated and so will
be sent with a destination SIR address.
b) If the mapping entry has no locator set or a different
locator than what is reported in the Host No mapping, then
disregard the message
3) If the message code is Router No Mapping
a) Lookup the specified identifier in the ILA mapping cache. If
a match is found, then mark the entry is unreachable (subject
to a timer)
b) If an entry is not found then disregard the message.
4) If the message code is Host redirect
a) Lookup the specified identifier in the ILA mapping cache. If
an entry is found, there is a locator in the mapping, and the
locator matches that in the Old Locator in the control
message-- then set the locator to the value of New Locator.
The next packet that is sent to that identifier will use the
new locator.
b) If the mapping entry has no locator set or a different
Herbert Expires September 22, 2016 [Page 11]
INTERNET DRAFT ILA Control Messages March 21, 2016
locator than what is reported in the Host Redirect then
disregard the message
5) If the message is Router Redirect
a) Lookup the specified identifier in the ILA mapping cache. If
an entry is found then set the locator to the value of
Locator in the control message. The next packet that is sent
to that identifier will use the new locator.
b) If no mapping entry is found for the identifier then
disregard the message or, optionally, create a new cache
entry for the redirected identifier (this permits a mechanism
for ILA routers to push mappings).
3.4 Other properties
Host No Mapping and Host Redirect are considered optional messages
for hosts to send. If they are sent, then rate limiting should be a
applied to avoid sending more than 100 control messages per second.
If control messages are not generated, then a sender that has an out
of date mapping should eventually timeout and stop sending packets to
an incorrect locator. A host should not forward ILA addressed packets
even in the case that it has the forwarding address for an
identifier.
Router No Mapping and Router Redirect must be sent in order to keep
hosts synchronized with mapping state. The number of messages sent to
particular host should be rate limited so that no more than 100
messages per second are sent. An ILA router may proactively send
Router No Mapping and Router Redirect messages upon a mapping state
change to those hosts that are known to possess a mapping (the list
of hosts that have sent packets through the router using a mapping
could be kept in the mapping database). Conceivably, an ILA router
could also multicast messages to inform hosts of a state (the details
for this are outside the scope of this document).
4 Security Considerations
ILA control messages convey sensitive control information so they
need to be protected against spoofing. ILA control messages should be
authenticated and may be encrypted.
4.1 HMAC authentication and integrity
ILA control messages may optionally use HMAC authentication. The use
of HMAC in a message is indicated by the H bit being set.
Herbert Expires September 22, 2016 [Page 12]
INTERNET DRAFT ILA Control Messages March 21, 2016
4.1.1 Security fields in ILA control messages
This section summarizes the use of specific fields in the ILA
messages. They are based on a key-hashed message authentication code
(HMAC).
The security-related fields in ILA messages are:
o HMAC Key-id, 8 bits wide;
o HMAC, 256 bits wide (optional, exists only if HMAC Key-id is not
0).
The HMAC field is the output of the HMAC computation (per RFC 2104
[RFC2104]) using a pre-shared key and hashing algorithm identified by
HMAC Key-id and of the text which consists of the concatenation of:
o the source IPv6 address;
o the ILA control message header and data
The purpose of the HMAC field is to verify the validity, the
integrity and the authorization of the ILA control messages itself.
If an outsider of the ILA domain does not have access to a current
pre-shared secret, then it cannot compute the right HMAC so when the
receiver of a control messages checks the validity of the HMAC it
will simply reject the packet.
The HMAC Key-id field allows for the simultaneous existence of
several hash algorithms (SHA-256, SHA3-256 ... or future ones) as
well as pre-shared keys. This allows for pre-shared key roll-over
when two pre-shared keys are supported for a while when all ILA nodes
converged to a fresher pre-shared key. The HMAC Key-id field is
opaque, i.e., it has neither syntax not semantic except as an index
to the right combination of pre-shared key and hash algorithm and
except that a value of 0 means that there is no HMAC field. It could
also allow for interoperation among different ILA domains if allowed
by local policy and assuming a collision-free Key Id allocation which
is out of scope of this memo.
4.1.2 Selecting a hash algorithm
The HMAC field in the ILA control messages is 256 bits wide.
Therefore, the HMAC MUST be based on a hash function whose output is
at least 256 bits. If the output of the hash function is 256, then
this output is simply inserted in the HMAC field. If the output of
the hash function is larger than 256 bits, then the output value is
truncated to 256 by taking the least-significant 256 bits and
Herbert Expires September 22, 2016 [Page 13]
INTERNET DRAFT ILA Control Messages March 21, 2016
inserting them in the HMAC field.
ILA implementations can support multiple hash functions but MUST
implement SHA-2 [FIPS180-4] in its SHA-256 variant.
4.1.3 Pre-shared key management
The field HMAC Key-id allows for:
o key roll-over: when there is a need to change the key (the hash
pre-shared secret), then multiple pre-shared keys can be used
simultaneously. The validating routing can have a table of
<HMAC Key-id, pre-shared secret, hash algorithm> for the
currently active and future keys.
o different algorithm: by extending the previous table to <HMAC
Key-id, hash function, pre-shared secret>, the validating router
can also support simultaneously several hash algorithms (see
section Section 4.1.2)
The pre-shared secret distribution can be done:
o in the configuration of the validating nodes, either by static
configuration or any SDN oriented approach;
o dynamically using a trusted key distribution such as [RFC6407]
The intent of this document is NOT to define yet-another-key-
distribution-protocol.
4.2 DTLS
For stronger security, including encryption of ILA control
messages, DTLS may be used. The use of DTLS necessitates a
separate UDP port.
5 IANA Considerations
IANA will be requested to assign one UDP port number for ILA
control messages, and one for ILA control messages with DTLS.
6 References
6.1 Normative References
[I-D.herbert-nvo3-ila] Herbert, T., "Identifier-locator addressing
for network virtualization", draft-herbert-nvo3-ila-02
(work in progress), March 2016.
Herbert Expires September 22, 2016 [Page 14]
INTERNET DRAFT ILA Control Messages March 21, 2016
6.2 Informative References
[I-D.lapukhov-ila-deployment] Lapukhov, P., "Deploying Identifier-
Locator Addressing (ILA) in datacenter", draft-lapukhov-
ila-deployment-00 (work in progress), March 2016.
[RFC2104] Krawczyk, H., Bellare, M., and R. Canetti, "HMAC: Keyed-
Hashing for Message Authentication", RFC 2104, DOI
10.17487/RFC2104, February 1997, <http://www.rfc-
editor.org/info/rfc2104>.
[RFC6407] Weis, B., Rowles, S., and T. Hardjono, "The Group Domain of
Interpretation", RFC 6407, DOI 10.17487/RFC6407, October
2011, <http://www.rfc-editor.org/info/rfc6407>.
Authors' Addresses
Tom Herbert
Facebook
1 Hacker Way
Menlo Park, CA
US
EMail: tom@herbertland.com
Herbert Expires September 22, 2016 [Page 15]