draft-kompella-mpls-larp-04.txt   draft-kompella-mpls-larp-05.txt 
MPLS WG K. Kompella MPLS WG K. Kompella
Internet-Draft Juniper Networks Internet-Draft Juniper Networks
Intended status: Standards Track R. Balaji Intended status: Standards Track R. Balaji
Expires: March 11, 2016 Juniper Networks, Inc. Expires: September 11, 2016 Juniper Networks, Inc.
G. Swallow G. Swallow
Cisco Systems Cisco Systems
September 8, 2015 March 10, 2016
Label Distribution Using ARP Label Distribution Using ARP
draft-kompella-mpls-larp-04 draft-kompella-mpls-larp-05
Abstract Abstract
This document describes extensions to the Address Resolution Protocol This document describes extensions to the Address Resolution Protocol
to distribute MPLS labels for IPv4 and IPv6 host addresses. to distribute MPLS labels for IPv4 and IPv6 host addresses.
Distribution of labels via ARP enables simple plug-and-play operation Distribution of labels via ARP enables simple plug-and-play operation
of MPLS, which is a key goal of the MPLS Fabric architecture. of MPLS.
Requirements Language Requirements Language
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].
The term "server" will be used in this document to refer to an ARP/ The term "server" will be used in this document to refer to an ARP/
L-ARP server; the term "host" will be used to refer to a compute L-ARP server; the term "host" will be used to refer to a compute
server or other device acting as an ARP/L-ARP client. server or other device acting as an ARP/L-ARP client.
skipping to change at page 1, line 46 skipping to change at page 1, line 46
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 11, 2016. This Internet-Draft will expire on September 11, 2016.
Copyright Notice Copyright Notice
Copyright (c) 2015 IETF Trust and the persons identified as the Copyright (c) 2016 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
described in the Simplified BSD License. described in the Simplified BSD License.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1. Approach . . . . . . . . . . . . . . . . . . . . . . . . 3 1.1. Approach . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Overview of Ethernet ARP . . . . . . . . . . . . . . . . . . 3 2. Overview of Ethernet ARP . . . . . . . . . . . . . . . . . . 4
3. L-ARP Protocol Operation . . . . . . . . . . . . . . . . . . 4 3. L-ARP Protocol Operation . . . . . . . . . . . . . . . . . . 4
3.1. Setup . . . . . . . . . . . . . . . . . . . . . . . . . . 5 3.1. Setup . . . . . . . . . . . . . . . . . . . . . . . . . . 5
3.2. Egress Operation . . . . . . . . . . . . . . . . . . . . 5 3.2. Egress Operation . . . . . . . . . . . . . . . . . . . . 5
3.3. Ingress Operation . . . . . . . . . . . . . . . . . . . . 5 3.3. Ingress Operation . . . . . . . . . . . . . . . . . . . . 5
4. Attributes . . . . . . . . . . . . . . . . . . . . . . . . . 5 4. Attributes . . . . . . . . . . . . . . . . . . . . . . . . . 6
5. Client-Server Synchronization . . . . . . . . . . . . . . . . 6 5. Client-Server Synchronization . . . . . . . . . . . . . . . . 7
6. Applicability . . . . . . . . . . . . . . . . . . . . . . . . 7 5.1. Restart Handling . . . . . . . . . . . . . . . . . . . . 7
7. Backward Compatibility . . . . . . . . . . . . . . . . . . . 7 5.1.1. Server Restart . . . . . . . . . . . . . . . . . . . 7
8. For Future Study . . . . . . . . . . . . . . . . . . . . . . 7 5.1.2. Client Restart . . . . . . . . . . . . . . . . . . . 8
9. L-ARP Message Format . . . . . . . . . . . . . . . . . . . . 8 5.2. Expedited Reachability Determination . . . . . . . . . . 8
10. Security Considerations . . . . . . . . . . . . . . . . . . . 10 6. Applicability . . . . . . . . . . . . . . . . . . . . . . . . 8
11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11 7. Backward Compatibility . . . . . . . . . . . . . . . . . . . 9
12. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 11 8. OAM . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9
13. References . . . . . . . . . . . . . . . . . . . . . . . . . 11 8.1. L-ARP IPv4 FEC . . . . . . . . . . . . . . . . . . . . . 9
13.1. Normative References . . . . . . . . . . . . . . . . . . 11 8.2. L-ARP IPv6 FEC . . . . . . . . . . . . . . . . . . . . . 9
13.2. Informative References . . . . . . . . . . . . . . . . . 12 9. For Future Study . . . . . . . . . . . . . . . . . . . . . . 10
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 12 10. L-ARP Message Format . . . . . . . . . . . . . . . . . . . . 11
11. Security Considerations . . . . . . . . . . . . . . . . . . . 13
12. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 14
13. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 14
14. References . . . . . . . . . . . . . . . . . . . . . . . . . 14
14.1. Normative References . . . . . . . . . . . . . . . . . . 14
14.2. Informative References . . . . . . . . . . . . . . . . . 15
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 15
1. Introduction 1. Introduction
This document describes extensions to the Address Resolution Protocol This document describes extensions to the Address Resolution Protocol
(ARP) [RFC0826] to advertise label bindings for IP host addresses. (ARP) [RFC0826] to advertise label bindings for IP host addresses.
While there are well-established protocols, such as LDP, RSVP and While there are well-established protocols, such as LDP, RSVP and
BGP, that provide robust mechanisms for label distribution, these BGP, that provide robust mechanisms for label distribution, these
protocols tend to be relatively complex, and often require detailed protocols tend to be relatively complex, and often require detailed
configuration for proper operation. There are situations where a configuration for proper operation. There are situations where a
simpler protocol may be more suitable from an operational standpoint. simpler protocol may be more suitable from an operational standpoint.
skipping to change at page 2, line 52 skipping to change at page 3, line 14
1. Introduction 1. Introduction
This document describes extensions to the Address Resolution Protocol This document describes extensions to the Address Resolution Protocol
(ARP) [RFC0826] to advertise label bindings for IP host addresses. (ARP) [RFC0826] to advertise label bindings for IP host addresses.
While there are well-established protocols, such as LDP, RSVP and While there are well-established protocols, such as LDP, RSVP and
BGP, that provide robust mechanisms for label distribution, these BGP, that provide robust mechanisms for label distribution, these
protocols tend to be relatively complex, and often require detailed protocols tend to be relatively complex, and often require detailed
configuration for proper operation. There are situations where a configuration for proper operation. There are situations where a
simpler protocol may be more suitable from an operational standpoint. simpler protocol may be more suitable from an operational standpoint.
An example is the case where an MPLS Fabric is the underlay An example is the case where an MPLS Fabric is the underlay
technology in a Data Center; here, MPLS tunnels originate from host technology in a Data Center; here, MPLS tunnels originate from host
machines. The host thus needs a mechanism to acquire label bindings machines. The host thus needs a mechanism to acquire label bindings
to participate in the MPLS Fabric, but in a simple, plug-and-play to participate in the MPLS Fabric. [TODO-MPLS-FABRIC] describes the
manner. Existing signaling/routing protocols do not always meet this motivation for using MPLS as the fabric technology.
need. Labeled ARP (L-ARP) is a proposal to fill that gap.
[TODO-MPLS-FABRIC] describes the motivation for using MPLS as the Another use-case is Egress Peer Traffic-Engineering (EPE)
fabric technology. [I-D.gredler-idr-bgplu-epe]. In EPE, if the host makes the decision
to direct packets towards a specific link using MPLS tunneling
techniques, there needs to a suitable protocol for the host to
acquire MPLS labels from the network.
In both the cases, the mechanism that the host uses to partcipate in
label exchange with the network needs to be simple, and plug-and-
play. Existing signaling/routing protocols do not always meet this
need. Labeled ARP (L-ARP) is a proposal to fill that gap.
1.1. Approach 1.1. Approach
ARP is a nearly ubiquitous protocol; every device with an Ethernet ARP is a nearly ubiquitous protocol; every device with an Ethernet
interface, from hand-helds to hosts, have an implementation of ARP. interface, from hand-helds to hosts, have an implementation of ARP.
ARP is plug-and-play; ARP clients do not need configuration to use ARP is plug-and-play; ARP clients do not need configuration to use
ARP. That suggests that ARP may be a good fit for devices that want ARP. That suggests that ARP may be a good fit for devices that want
to source and sink MPLS tunnels, but do so in a zero-config, plug- to source and sink MPLS tunnels, but do so in a zero-config, plug-
and-play manner, with minimal impact to their code. and-play manner, with minimal impact to their code.
skipping to change at page 3, line 35 skipping to change at page 4, line 9
and L-ARP can coexist; a device, as an ARP client, can choose to send and L-ARP can coexist; a device, as an ARP client, can choose to send
out an E-ARP or an L-ARP request, depending on whether it needs out an E-ARP or an L-ARP request, depending on whether it needs
Ethernet or MPLS connectivity. Another device may choose to function Ethernet or MPLS connectivity. Another device may choose to function
as an E-ARP server and/or an L-ARP server, depending on its ability as an E-ARP server and/or an L-ARP server, depending on its ability
to provide an IP-to-Ethernet and/or IP-to-MPLS mapping. to provide an IP-to-Ethernet and/or IP-to-MPLS mapping.
2. Overview of Ethernet ARP 2. Overview of Ethernet ARP
In the most straightforward mode of operation [RFC0826], ARP queries In the most straightforward mode of operation [RFC0826], ARP queries
are sent to resolve "directly connected" IP addresses. The ARP query are sent to resolve "directly connected" IP addresses. The ARP query
is broadcast, with the Target Protocol Address field (see Section 9 is broadcast, with the Target Protocol Address field (see Section 10
for a description of the fields in an ARP message) carrying the IP for a description of the fields in an ARP message) carrying the IP
address of another node in the same subnet. All the nodes in the LAN address of another node in the same subnet. All the nodes in the LAN
receive this ARP query. All the nodes, except the node that owns the receive this ARP query. All the nodes, except the node that owns the
IP address, ignore the ARP query. The IP address owner learns the IP address, ignore the ARP query. The IP address owner learns the
MAC address of the sender from the Source Hardware Address field in MAC address of the sender from the Source Hardware Address field in
the ARP request, and unicasts an ARP reply to the sender. The ARP the ARP request, and unicasts an ARP reply to the sender. The ARP
reply carries the replying node's MAC address in the Source Hardware reply carries the replying node's MAC address in the Source Hardware
Address field, thus enabling two-way communication between the two Address field, thus enabling two-way communication between the two
nodes. nodes.
skipping to change at page 4, line 28 skipping to change at page 4, line 50
a gratuitous ARP reply, the Target Hardware Address is also set to a gratuitous ARP reply, the Target Hardware Address is also set to
the sender's address. the sender's address.
3. L-ARP Protocol Operation 3. L-ARP Protocol Operation
The L-ARP protocol builds on the proxy ARP model, and also leverages The L-ARP protocol builds on the proxy ARP model, and also leverages
gratuitous ARP model for asynchronous updates. gratuitous ARP model for asynchronous updates.
In this memo, we will refer to L-ARP clients (that make L-ARP In this memo, we will refer to L-ARP clients (that make L-ARP
requests) and L-ARP servers (that send L-ARP responses). In requests) and L-ARP servers (that send L-ARP responses). In
Figure 1, H1, H2 and H3 are L-ARP clients, and T1, T2 and T3 are Figure 1, H1, H2 and H3 are L-ARP clients, and T1, T2 and T3 are IP
L-ARP servers. T4 is a member of the MPLS Fabric that may not be an routers playing the role of L-ARP server. T4 is a member of the MPLS
L-ARP server. Within the MPLS Fabric, the usual MPLS protocols (IGP, Fabric that may not be an L-ARP server. Within the MPLS Fabric, the
LDP, RSVP-TE) are run. Say H1, H2 and H3 want to establish MPLS usual MPLS protocols (IGP, LDP, RSVP-TE) are run. Say H1, H2 and H3
tunnels to each other (for example, they are using BGP MPLS VPNs as want to establish MPLS tunnels to each other (for example, they are
the overlay virtual network technology). H1 might also want to talk using BGP MPLS VPNs as the overlay virtual network technology). H1
to a member of the MPLS Fabric, say T. might also want to talk to a member of the MPLS Fabric, say T (not
depicted in the diagram).
. . . . . . . . . . . .
. . . .
H1 --- T1 T4 H1 --- T1 T4
\ . MPLS . \ . MPLS .
\ . . \ . .
\ . Fabric . \ . Fabric .
H2 --- T2 T3 --- H3 H2 --- T2 T3 --- H3
. . . .
. . . . . . . . . . . . . .
skipping to change at page 5, line 40 skipping to change at page 6, line 9
Hardware Address set to its Ethernet MAC address M1, with a new TLV Hardware Address set to its Ethernet MAC address M1, with a new TLV
containing a label L1. To send a packet to H3 over an MPLS tunnel, containing a label L1. To send a packet to H3 over an MPLS tunnel,
H1 pushes L1 onto the packet, sets the destination MAC address to M1 H1 pushes L1 onto the packet, sets the destination MAC address to M1
and sends it to T1. On receiving this packet, T1 swaps the top label and sends it to T1. On receiving this packet, T1 swaps the top label
with the label(s) for its MPLS tunnel to H3. with the label(s) for its MPLS tunnel to H3.
Note that H1 broadcasts its L-ARP request over its attached Note that H1 broadcasts its L-ARP request over its attached
interfaces. H1 may receive several L-ARP replies; in that case, H1 interfaces. H1 may receive several L-ARP replies; in that case, H1
can select any subset of these to send MPLS packets destined to H3. can select any subset of these to send MPLS packets destined to H3.
As described later, the L-ARP response may contain certain parameters As described later, the L-ARP response may contain certain parameters
that enable the client to make an informed choice. If the target H3 that enable the client to make an informed choice. However, it is
belongs to one of the subnets that H1 participates in, and H3 is completely a matter of local policy on H1 which of the many responses
capable of sending L-ARP replies, H1 can use H3's response to send are used. Some possibilites include, but not limited to,
MPLS packets to H3.
o Use the first reply that arrives, and ignore the rest
o Wait for a certain amount of time, and choose the response
carrying the least metric
o If there is more than one response carrying the least metric,
perform load-balancing among them
o Consult local configuration to select a gateway
If the target H3 belongs to one of the subnets that H1 participates
in, and H3 is capable of sending L-ARP replies, H1 can use H3's
response to send MPLS packets to H3.
4. Attributes 4. Attributes
In addition to carrying a label stack to be used in the data plane, In addition to carrying a label stack to be used in the data plane,
an L-ARP reply carries some attributes that are typically used in the an L-ARP reply carries some attributes that are typically used in the
control plane. One of these is a metric. The metric is the distance control plane. One of these is a metric. The metric is the distance
from the L-ARP server to the destination. This allows an L-ARP from the L-ARP server to the destination. This allows an L-ARP
client that receives multiple responses to decide which ones to use, client that receives multiple responses to decide which ones to use,
and whether to load-balance across some of them. The metric and whether to load-balance across some of them. The metric
typically will be the IGP shortest path distance from server to the typically will be the IGP shortest path distance from server to the
skipping to change at page 7, line 4 skipping to change at page 7, line 39
suboptimally routed. This may be the most benign consequence of loss suboptimally routed. This may be the most benign consequence of loss
of synchronization. of synchronization.
Standard ARP has similar issues. These are dealt with in two ways: Standard ARP has similar issues. These are dealt with in two ways:
a) ARP bindings are time-bound; and b) an ARP server, recognizing a) ARP bindings are time-bound; and b) an ARP server, recognizing
that a change has occurred, can send unsolicited ARP messages that a change has occurred, can send unsolicited ARP messages
([RFC2002]). Both these techniques are used in L-ARP: the validity ([RFC2002]). Both these techniques are used in L-ARP: the validity
of the MPLS label obtained using L-ARP is time-bound; an L-ARP client of the MPLS label obtained using L-ARP is time-bound; an L-ARP client
should periodically resend L-ARP requests to obtain the latest should periodically resend L-ARP requests to obtain the latest
information, and time out entries in its ARP cache if such an update information, and time out entries in its ARP cache if such an update
is not forthcoming. Furthermore, an L-ARP server may update an is not forthcoming.
advertised label binding by sending an unsolicited L-ARP message if
any of the parameters mentioned above change. Furthermore, an L-ARP server may update an advertised label binding
by sending an unsolicited L-ARP message if any of the parameters
mentioned above change. Likewise, an L-ARP server may withdraw its
earlier advertisement by sending an unsolicited LARP-NAK message.
5.1. Restart Handling
5.1.1. Server Restart
In order to support graceful restart, the L-ARP server must remember
the advertised bindings across restarts. The mechanism that the
L-ARP server uses to accomplish this is outside the scope of this
document. Some possible mechanisms are, usage of shared memory or
non-volatile storage to store bindings. Upon restart, the L-ARP
server waits until the LSPs advertised in the previous incarnation
are restored. Then, it reconciles the L-ARP bindings with the
current state of the LSPs, updating the clients with unsolicted L-ARP
replies & NAK for bindings that have undergone changes.
During the above procedure, the client does not really know that the
server has restarted. If there were no changes to the LSPs during
restart, the client receives no updates. If there were changes, then
the client would receive unsolicited updates to the bindings, as it
would on a normal change. If the server does not successfully
restart, the client's periodic refresh will detect the loss of
connectivity and purge out the bindings.
If the L-ARP server does not support graceful restart, it SHOULD
withdraw the advertised bindings before shutting down. Unplanned
restarts rely on the slower perioidc refresh mechanism for re-
synchronization.
5.1.2. Client Restart
If the client restarts gracefully, it re-acquires the bindings
immediately after restart to learn about any changes.
If the client does not support graceful restart, it leaves the
bindings to age out.
5.2. Expedited Reachability Determination
As with other control protocols, the client and server may use data
plane liveness detection mechanisms, such as Loss of Signal (LOS)
and/or BFD, to expedite detection of loss of connectivity. However,
usage of these mechanisms are outside the scope of this document.
6. Applicability 6. Applicability
L-ARP can be used between a host and its Top-of-Rack switch in a Data L-ARP can be used between a host and its Top-of-Rack switch in a Data
Center. L-ARP can also be used between a DSLAM and its aggregation Center. L-ARP can also be used between a DSLAM and its aggregation
switch going to the B-RAS. More generally, L-ARP can be used between switch going to the B-RAS. In seamless MPLS terms, L-ARP can be used
an "Access Node" (AN) (e.g., the DSLAM) and its first hop MPLS- between an "Access Node" (AN) (e.g., the DSLAM) and its first hop
enabled device in the context of Seamless MPLS MPLS-enabled device in the context of Seamless MPLS
[I-D.ietf-mpls-seamless-mpls]. The first-hop device is part of the [I-D.ietf-mpls-seamless-mpls]. The first-hop device is part of the
MPLS Fabric, as is the Service Node (SN) (e.g., the B-RAS). L-ARP MPLS Fabric, as is the Service Node (SN) (e.g., the B-RAS). L-ARP
helps create an MPLS tunnel from the AN to the SN, without requiring helps create an MPLS tunnel from the AN to the SN, without requiring
that the AN be part of the MPLS Fabric. In all these cases, L-ARP that the AN be part of the MPLS Fabric. In all these cases, L-ARP
can handle the presence of multiple connections between the access can handle the presence of multiple connections between the access
device and its first hop devices. device and its first hop devices.
ARP is not a routing protocol. The use of L-ARP should be limited to ARP is not a routing protocol. The use of L-ARP should be limited to
cases where an L-ARP client has Ethernet connectivity to its L-ARP cases where an L-ARP client has Ethernet connectivity to its L-ARP
servers. servers.
skipping to change at page 7, line 38 skipping to change at page 9, line 21
Since L-ARP uses a new hardware type, it is backward compatible with Since L-ARP uses a new hardware type, it is backward compatible with
"regular" ARP. ARP servers and clients MUST be able to send out, "regular" ARP. ARP servers and clients MUST be able to send out,
receive and process ARP messages based on hardware type. They MAY receive and process ARP messages based on hardware type. They MAY
choose to ignore requests and replies of some hardware types; they choose to ignore requests and replies of some hardware types; they
MAY choose to log errors if they encounter hardware types they do not MAY choose to log errors if they encounter hardware types they do not
recognize; however, they MUST handle all hardware types gracefully. recognize; however, they MUST handle all hardware types gracefully.
For hardware types that they do understand, ARP servers and clients For hardware types that they do understand, ARP servers and clients
MUST handle operation codes gracefully, processing those they MUST handle operation codes gracefully, processing those they
understand, and ignoring (and possibly logging) others. understand, and ignoring (and possibly logging) others.
8. For Future Study 8. OAM
L-ARP uses standard MPLS OAM procedures defined in [RFC4379] &
[RFC6424]. Extending the definitions in section 3.2 of RFC 4379, we
use a sub-type of [TO-BE-ASSIGNED-BY-IANA-1] to represent L-ARP IPv4
FEC, and [TO-BE-ASSIGNED-BY-IANA-2] to represent L-ARP IPv6 FEC. The
following sub-sections define the format of L-ARP FEC's.
8.1. L-ARP IPv4 FEC
The L-ARP IPv4 FEC is defined as follows:
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 address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
IPv4 address is the tunnel destination address.
Figure 2: ARP IPv4 FEC
The length of the L-ARP IPv4 FEC is 4 bytes.
8.2. L-ARP IPv6 FEC
The L-ARP IPv6 FEC is defined as follows:
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| IPv6 address |
| (16 octets) |
| |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
IPv6 address is the tunnel destination address.
Figure 3: ARP IPv6 FEC
The length of the L-ARP IPv6 FEC is 16 bytes.
9. For Future Study
The L-ARP specification is quite simple, and the goal is to keep it The L-ARP specification is quite simple, and the goal is to keep it
that way. However, inevitably, there will be questions and features that way. However, inevitably, there will be questions and features
that will be requested. Some of these are: that will be requested. Some of these are:
1. Keeping L-ARP clients and servers in sync. In particular, 1. Keeping L-ARP clients and servers in sync. In particular,
dealing with: dealing with:
A. client and/or server control plane restart A. client and/or server control plane restart
B. lost packets B. lost packets
C. timeouts C. timeouts
2. Withdrawing a response. 2. Dealing with scale.
3. Dealing with scale.
4. If there are many servers, which one to pick? 3. If there are many servers, which one to pick?
5. How can a client make best use of underlying ECMP paths? 4. How can a client make best use of underlying ECMP paths?
6. and probably many more. 5. and probably many more.
In all of these, it is important to realize that, whenever possible, In all of these, it is important to realize that, whenever possible,
a solution that places most of the burden on the server rather than a solution that places most of the burden on the server rather than
on the client is preferable. on the client is preferable.
These questions (and others that come up during discussions) will be These questions (and others that come up during discussions) will be
dealt with in future versions of this draft. dealt with in future versions of this draft.
9. L-ARP Message Format 10. L-ARP Message Format
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ar$hrd | ar$pro | | ar$hrd | ar$pro |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ar$hln | ar$pln | ar$op | | ar$hln | ar$pln | ar$op |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
// ar$sha (ar$hln octets) // // ar$sha (ar$hln octets) //
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
// ar$spa (ar$pln octets) // // ar$spa (ar$pln octets) //
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
// ar$tha (ar$hln octets) // // ar$tha (ar$hln octets) //
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
// ar$tpa (ar$pln octets) // // ar$tpa (ar$pln octets) //
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
// ar$lst (variable...) // // ar$lst (variable...) //
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
// ar$att (variable...) // // ar$att (variable...) //
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 2: L-ARP Packet Format Figure 4: L-ARP Packet Format
ar$hrd Hardware Type: MPLS-over-Ethernet. The value of the field ar$hrd Hardware Type: MPLS-over-Ethernet. The value of the field
used here is [HTYPE-MPLS]. To start with, we will use the used here is [HTYPE-MPLS]. To start with, we will use the
experimental value HW_EXP2 (256) experimental value HW_EXP2 (256)
ar$pro Protocol Type: IPv4/IPv6. The value of the field used here ar$pro Protocol Type: IPv4/IPv6. The value of the field used here
is 0x0800 to resolve an IPv4 address and 0x86DD to resolve an is 0x0800 to resolve an IPv4 address and 0x86DD to resolve an
IPv6 address. IPv6 address.
ar$hln Hardware Length: 6. ar$hln Hardware Length: 6.
skipping to change at page 9, line 36 skipping to change at page 12, line 22
ar$lst Label Stack: In an L-ARP request, this field is empty. In an ar$lst Label Stack: In an L-ARP request, this field is empty. In an
L-ARP reply, this field carries the MPLS label stack as an ARP L-ARP reply, this field carries the MPLS label stack as an ARP
TLV in the format below. TLV in the format below.
ar$att Attributes: In an L-ARP request, this field is empty. In an ar$att Attributes: In an L-ARP request, this field is empty. In an
L-ARP reply, this field carries attributes for the MPLS label L-ARP reply, this field carries attributes for the MPLS label
stack as an ARP TLV in the format below. stack as an ARP TLV in the format below.
This document introduces the notion of ARP TLVs. These take the form This document introduces the notion of ARP TLVs. These take the form
as in Figure 3. Figure 4 describes the format of Label Stack TLV as in Figure 5. Figure 6 describes the format of Label Stack TLV
carried in L-ARP. Figure 5 describes the format of Attributes TLV carried in L-ARP. Figure 7 describes the format of Attributes TLV
carried in L-ARP. carried in L-ARP.
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 | Length | Value (Length octets) ... | | Type | Length | Value (Length octets) ... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ... | | ... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Type is the type of the TLV; Length is the length of the value field Type is the type of the TLV; Length is the length of the value field
in octets; Value is the value field. in octets; Value is the value field.
Figure 3: ARP TLVs Figure 5: ARP TLVs
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 | Length | MPLS Label (20 bits) | | Type | Length | MPLS Label (20 bits) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |E|Z|Z|Z| MPLS Label (20 bits) |E|Z|Z|Z| | |E|Z|Z|Z| MPLS Label (20 bits) |E|Z|Z|Z|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ... | ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 4: MPLS Label Stack Format Figure 6: MPLS Label Stack Format
Label Stack: Type = TLV-LST; Length = n*3 octets, where n is the Label Stack: Type = TLV-LST; Length = n*3 octets, where n is the
number of labels. The Value field contains the MPLS label stack number of labels. The Value field contains the MPLS label stack
for the client to use to get to the target. Each label is 3 for the client to use to get to the target. Each label is 3
octets. This field is valid only in an L-ARP reply message. octets. This field is valid only in an L-ARP reply message.
E-bit: Entropy Label Capable: this flag indicates whether the E-bit: Entropy Label Capable: this flag indicates whether the
corresponding label in the label stack can be followd by an corresponding label in the label stack can be followd by an
Entropy Label. If this flag is set, the client has the option of Entropy Label. If this flag is set, the client has the option of
inserting ELI and EL as specified in [RFC6790]. The client can inserting ELI and EL as specified in [RFC6790]. The client can
choose not to insert ELI/EL pair. If this flag is clear, the choose not to insert ELI/EL pair. If this flag is clear, the
client must not insert ELI/EL after the corresponding label. client MUST NOT insert ELI/EL after the corresponding label.
Z These bits are not used, and SHOULD be set to zero on sending and Z These bits are not used, and SHOULD be set to zero on sending and
ignored on receipt. ignored on receipt.
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 | Length | Metric (4 octets) ... | | Type | Length | Metric (4 octets) ... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ... Metric | | ... Metric |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 5: Attribute TLV Figure 7: Attribute TLV
Attributes TLV: Type = TLV-ATT; Length = 4 octets. The Value field Attributes TLV: Type = TLV-ATT; Length = 4 octets. The Value field
contains the metric (typically, IGP distance) from the responder contains the metric (typically, IGP distance) from the responder
to the destination (device with the requested IP address). This to the destination (device with the requested IP address). If the
responder is the destination, then the metric value is zero. This
field is valid only in an L-ARP reply message. field is valid only in an L-ARP reply message.
If other parameters are deemed useful in the ATT TLV, they will be If other parameters are deemed useful in the ATT TLV, they will be
added as needed. added as needed.
10. Security Considerations 11. Security Considerations
There are many possible attacks on ARP: ARP spoofing, ARP cache There are many possible attacks on ARP: ARP spoofing, ARP cache
poisoning and ARP poison routing, to name a few. These attacks use poisoning and ARP poison routing, to name a few. These attacks use
gratuitous ARP as the underlying mechanism, a mechanism used by gratuitous ARP as the underlying mechanism, a mechanism used by
L-ARP. Thus, these types of attacks are applicable to L-ARP. L-ARP. Thus, these types of attacks are applicable to L-ARP.
Furthermore, ARP does not have built-in security mechanisms; defenses Furthermore, ARP does not have built-in security mechanisms; defenses
rely on means external to the protocol. rely on means external to the protocol.
It is well outside the scope of this document to present a general It is well outside the scope of this document to present a general
solution to the ARP security problem. One simple answer is to add a solution to the ARP security problem. One simple answer is to add a
TLV that contains a digital signature of the contents of the ARP TLV that contains a digital signature of the contents of the ARP
message. This TLV would be defined for use only in L-ARP messages, message. This TLV would be defined for use only in L-ARP messages,
although in principle, other ARP messages could use it as well. Such although in principle, other ARP messages could use it as well. Such
an approach would, of course, need a review and approval by the an approach would, of course, need a review and approval by the
Security Directorate. If approved, the type of this TLV and its Security Directorate. If approved, the type of this TLV and its
procedures would be defined in this document. If some other procedures would be defined in this document. If some other
technique is suggested, the authors would be happy to include the technique is suggested, the authors would be happy to include the
relevant text in this document, and refer to some other document for relevant text in this document, and refer to some other document for
the full solution. the full solution.
11. IANA Considerations 12. IANA Considerations
IANA is requested to allocate a new ARP hardware type (from the IANA is requested to allocate a new ARP hardware type (from the
registry hrd) for HTYPE-MPLS. registry hrd) for HTYPE-MPLS.
IANA is also requested to create a new registry ARP-TLV ("tlv"). IANA is also requested to create a new registry ARP-TLV ("tlv").
This is a registry of one octet numbers. Allocation policies: 0 is This is a registry of one octet numbers. Allocation policies: 0 is
not to be allocated; the range 1-127 is Standards Action; the values not to be allocated; the range 1-127 is Standards Action; the values
128-251 are FCFS; and the values 252-255 are Experimental. 128-251 are FCFS; and the values 252-255 are Experimental.
Finally, IANA is requested to allocate two values in the ARP-TLV Finally, IANA is requested to allocate two values in the ARP-TLV
registry, one for TLV-LST and another for TLV-ATT. registry, one for TLV-LST and another for TLV-ATT.
12. Acknowledgments 13. Acknowledgments
Many thanks to Shane Amante for his detailed comments and Many thanks to Shane Amante for his detailed comments and
suggestions. Many thanks to the team in Juniper prototyping this suggestions. Many thanks to the team in Juniper prototyping this
work for their suggestions on making this variant workable in the work for their suggestions on making this variant workable in the
context of existing ARP implementations. Thanks too to Luyuan Fang, context of existing ARP implementations. Thanks too to Luyuan Fang,
Alex Semenyaka and Dmitry Afanasiev for their comments and Alex Semenyaka and Dmitry Afanasiev for their comments and
encouragement. encouragement.
13. References 14. References
13.1. Normative References 14.1. Normative References
[RFC0826] Plummer, D., "Ethernet Address Resolution Protocol: Or [RFC0826] Plummer, D., "Ethernet Address Resolution Protocol: Or
Converting Network Protocol Addresses to 48.bit Ethernet Converting Network Protocol Addresses to 48.bit Ethernet
Address for Transmission on Ethernet Hardware", STD 37, Address for Transmission on Ethernet Hardware", STD 37,
RFC 826, DOI 10.17487/RFC0826, November 1982, RFC 826, DOI 10.17487/RFC0826, November 1982,
<http://www.rfc-editor.org/info/rfc826>. <http://www.rfc-editor.org/info/rfc826>.
[RFC2002] Perkins, C., Ed., "IP Mobility Support", RFC 2002, [RFC2002] Perkins, C., Ed., "IP Mobility Support", RFC 2002,
DOI 10.17487/RFC2002, October 1996, DOI 10.17487/RFC2002, October 1996,
<http://www.rfc-editor.org/info/rfc2002>. <http://www.rfc-editor.org/info/rfc2002>.
[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, Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997, DOI 10.17487/RFC2119, March 1997,
<http://www.rfc-editor.org/info/rfc2119>. <http://www.rfc-editor.org/info/rfc2119>.
[RFC4379] Kompella, K. and G. Swallow, "Detecting Multi-Protocol
Label Switched (MPLS) Data Plane Failures", RFC 4379,
DOI 10.17487/RFC4379, February 2006,
<http://www.rfc-editor.org/info/rfc4379>.
[RFC6424] Bahadur, N., Kompella, K., and G. Swallow, "Mechanism for
Performing Label Switched Path Ping (LSP Ping) over MPLS
Tunnels", RFC 6424, DOI 10.17487/RFC6424, November 2011,
<http://www.rfc-editor.org/info/rfc6424>.
[RFC6790] Kompella, K., Drake, J., Amante, S., Henderickx, W., and [RFC6790] Kompella, K., Drake, J., Amante, S., Henderickx, W., and
L. Yong, "The Use of Entropy Labels in MPLS Forwarding", L. Yong, "The Use of Entropy Labels in MPLS Forwarding",
RFC 6790, DOI 10.17487/RFC6790, November 2012, RFC 6790, DOI 10.17487/RFC6790, November 2012,
<http://www.rfc-editor.org/info/rfc6790>. <http://www.rfc-editor.org/info/rfc6790>.
13.2. Informative References 14.2. Informative References
[I-D.gredler-idr-bgplu-epe]
Gredler, H., Vairavakkalai, K., R, C., Rajagopalan, B.,
and L. Fang, "Egress Peer Engineering using BGP-LU",
draft-gredler-idr-bgplu-epe-04 (work in progress),
September 2015.
[I-D.ietf-mpls-seamless-mpls] [I-D.ietf-mpls-seamless-mpls]
Leymann, N., Decraene, B., Filsfils, C., Konstantynowicz, Leymann, N., Decraene, B., Filsfils, C., Konstantynowicz,
M., and D. Steinberg, "Seamless MPLS Architecture", draft- M., and D. Steinberg, "Seamless MPLS Architecture", draft-
ietf-mpls-seamless-mpls-07 (work in progress), June 2014. ietf-mpls-seamless-mpls-07 (work in progress), June 2014.
Authors' Addresses Authors' Addresses
Kireeti Kompella Kireeti Kompella
Juniper Networks Juniper Networks
 End of changes. 37 change blocks. 
66 lines changed or deleted 196 lines changed or added

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