Internet DRAFT - draft-ietf-6man-rpl-routing-header
draft-ietf-6man-rpl-routing-header
6MAN J. Hui
Internet-Draft JP. Vasseur
Intended status: Standards Track Cisco Systems, Inc
Expires: June 18, 2012 D. Culler
UC Berkeley
V. Manral
Hewlett Packard Co.
December 16, 2011
An IPv6 Routing Header for Source Routes with RPL
draft-ietf-6man-rpl-routing-header-07
Abstract
In Low power and Lossy Networks (LLNs), memory constraints on routers
may limit them to maintaining at most a few routes. In some
configurations, it is necessary to use these memory constrained
routers to deliver datagrams to nodes within the LLN. The Routing
for Low Power and Lossy Networks (RPL) protocol can be used in some
deployments to store most, if not all, routes on one (e.g. the
Directed Acyclic Graph (DAG) root) or few routers and forward the
IPv6 datagram using a source routing technique to avoid large routing
tables on memory constrained routers. This document specifies a new
IPv6 Routing header type for delivering datagrams within a RPL
Instance.
Status of this Memo
This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/.
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."
This Internet-Draft will expire on June 18, 2012.
Copyright Notice
Copyright (c) 2011 IETF Trust and the persons identified as the
document authors. All rights reserved.
Hui, et al. Expires June 18, 2012 [Page 1]
Internet-Draft RPL Source Route Header December 2011
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
1.1. Requirements Language . . . . . . . . . . . . . . . . . . 3
2. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . 4
3. Format of the RPL Routing Header . . . . . . . . . . . . . . . 7
4. RPL Router Behavior . . . . . . . . . . . . . . . . . . . . . 10
4.1. Generating Source Routing Headers . . . . . . . . . . . . 10
4.2. Processing Source Routing Headers . . . . . . . . . . . . 10
5. Security Considerations . . . . . . . . . . . . . . . . . . . 14
5.1. Source Routing Attacks . . . . . . . . . . . . . . . . . . 14
5.2. ICMPv6 Attacks . . . . . . . . . . . . . . . . . . . . . . 14
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 15
7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 16
8. Changes . . . . . . . . . . . . . . . . . . . . . . . . . . . 17
9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 19
9.1. Normative References . . . . . . . . . . . . . . . . . . . 19
9.2. Informative References . . . . . . . . . . . . . . . . . . 19
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 20
Hui, et al. Expires June 18, 2012 [Page 2]
Internet-Draft RPL Source Route Header December 2011
1. Introduction
Routing for Low Power and Lossy Networks (RPL) is a distance vector
IPv6 routing protocol designed for Low Power and Lossy networks (LLN)
[I-D.ietf-roll-rpl]. Such networks are typically constrained in
resources (limited communication data rate, processing power, energy
capacity, memory). In particular, some LLN configurations may
utilize LLN routers where memory constraints limit nodes to
maintaining only a small number of default routes and no other
destinations. However, it may be necessary to utilize such memory-
constrained routers to forward datagrams and maintain reachability to
destinations within the LLN.
To utilize paths that include memory-constrained routers, RPL relies
on source routing. In one deployment model of RPL, more capable
routers collect routing information and form paths to arbitrary
destinations within a RPL Instance. However, a source routing
mechanism supported by IPv6 is needed to deliver datagrams.
This document specifies the Source Routing Header (SRH) for use
strictly between RPL routers in the same RPL Instance.
1.1. Requirements Language
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in [RFC2119].
Hui, et al. Expires June 18, 2012 [Page 3]
Internet-Draft RPL Source Route Header December 2011
2. Overview
The format of SRH draws from that of the Type 0 Routing header (RH0)
[RFC2460]. However, SRH introduces mechanisms to compact the source
route entries when all entries share the same prefix with the IPv6
Destination Address of a packet carrying a SRH, a typical scenario in
LLNs using source routing. The compaction mechanism reduces
consumption of scarce resources such as channel capacity.
SRH also differs from RH0 in the processing rules to alleviate
security concerns that led to the deprecation of RH0 [RFC5095].
First, RPL routers implement a strict source route policy where each
and every IPv6 hop between the source and destination of the source
route is specified within the SRH. Note that the source route may be
a subset of the path between the actual source and destination and is
discussed further below. Second, a SRH is only used between RPL
routers within a RPL Instance. RPL Border Routers, responsible for
connecting other RPL Instances and IP domains that use other routing
protocols, do not allow datagrams already carrying a SRH header to
enter or exit a RPL Instance. Third, a RPL router drops datagrams
that includes multiple addresses assigned to any interfaces on that
router to avoid forwarding loops.
There are two cases that determine how to include a SRH when a RPL
router requires the use of a SRH to deliver a datagram to its
destination.
1. If the SRH specifies the complete path from source to
destination, the router places the SRH directly in the datagram
itself.
2. If the SRH only specifies a subset of the path from source to
destination, the router uses IPv6-in-IPv6 tunneling [RFC2473] and
places the SRH in the outer IPv6 header. Use of tunneling
ensures that the datagram is delivered unmodified and that ICMP
errors return to the source of the SRH rather than the source of
the original datagram.
In a RPL network, Case 1 occurs when both source and destinations are
within a RPL Instance and a single SRH is used to specify the entire
path from source to destination, as shown in the following figure:
+--------------------+
| |
| (S) -------> (D) |
| |
+--------------------+
Hui, et al. Expires June 18, 2012 [Page 4]
Internet-Draft RPL Source Route Header December 2011
RPL Instance
In the above scenario, datagrams traveling from source, S, to
destination, D, have the following packet structure:
+--------+---------+-------------//-+
| IPv6 | Source | IPv6 |
| Header | Routing | Payload |
| | Header | |
+--------+---------+-------------//-+
S's address is carried in the IPv6 Header's Source Address field.
D's address is carried in the last entry of SRH for all but the last
hop, when D's address is carried in the IPv6 Header's Destination
Address field of the packet carrying the SRH.
In a RPL network, Case 2 occurs for all datagrams that have source
and/or destination outside the RPL Instance, as shown in the
following diagram:
+-----------------+
| |
| (S) --------> (R) --------> (D)
| |
+-----------------+
RPL Instance
+-----------------+
| |
(S) --------> (R) --------> (D) |
| |
+-----------------+
RPL Instance
+-----------------+
| |
(S) --------> (R) ------------> (R) --------> (D)
| |
+-----------------+
RPL Instance
In the scenarios above, R may indicate a RPL Border Router (when
connecting to other routing domains) or a RPL Router (when connecting
Hui, et al. Expires June 18, 2012 [Page 5]
Internet-Draft RPL Source Route Header December 2011
to hosts). The datagrams have the following structure when traveling
within the RPL Instance:
+--------+---------+--------+-------------//-+
| Outer | Source | Inner | IPv6 |
| IPv6 | Routing | IPv6 | Payload |
| Header | Header | Header | |
+--------+---------+--------+-------------//-+
<--- Original Packet --->
<--- Tunneled Packet --->
Note that the outer header (including the SRH) is added and removed
by the RPL router.
Case 2 also occurs whenever a RPL router needs to insert a source
route when forwarding datagram. One such use case with RPL is to
have all RPL traffic flow through a Border Router and have the Border
Router use source routes to deliver datagrams to their final
destination. When including the SRH using tunneled mode, the Border
Router would encapsulate the received datagram unmodified using IPv6-
in-IPv6 and include a SRH in the outer IPv6 header.
+-----------------+
| |
| (S) -------\ |
| \ |
| (LBR)
| / |
| (D) <------/ |
| |
+-----------------+
RPL Instance
In the above scenario, datagrams travel from S to D through LBR.
Between S and LBR, the datagrams are routed using the DAG built by
RPL and do not contain a SRH. LBR encapsulates received datagrams
unmodified using IPv6-in-IPv6 and the SRH is included in the outer
IPv6 header.
Hui, et al. Expires June 18, 2012 [Page 6]
Internet-Draft RPL Source Route Header December 2011
3. Format of the RPL Routing Header
The Source Routing Header has the following format:
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 | Hdr Ext Len | Routing Type | Segments Left |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| CmprI | CmprE | Pad | Reserved | RPLInstanceID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
. .
. Addresses[1..n] .
. .
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Next Header 8-bit selector. Identifies the type of header
immediately following the Routing header. Uses
the same values as the IPv6 Next Header field
[RFC2460].
Hdr Ext Len 8-bit unsigned integer. Length of the Routing
header in 8-octet units, not including the first
8 octets. Note that when Addresses[1..n] are
compressed (i.e. value of CmprI or CmprE is not
0), Hdr Ext Len does not equal twice the number
of Addresses.
Routing Type 8-bit selector. Identifies the particular
Routing header variant. A SRH should set the
Routing Type to TBD by IANA.
Segments Left 8-bit unsigned integer. Number of route segments
remaining, i.e., number of explicitly listed
intermediate nodes still to be visited before
reaching the final destination. The originator
of a SRH sets this field to n, the number of
addresses contained in Addresses[1..n].
CmprI 4-bit unsigned integer. Number of prefix octets
from each segment, except than the last segment,
(i.e. segments 1 through n-1) that are elided.
For example, a SRH carrying full IPv6 addresses
in Addresses[1..n-1] sets CmprI to 0.
Hui, et al. Expires June 18, 2012 [Page 7]
Internet-Draft RPL Source Route Header December 2011
CmprE 4-bit unsigned integer. Number of prefix octets
from the last segment (i.e. segment n) that are
elided. For example, a SRH carrying a full IPv6
address in Addresses[n] sets CmprE to 0.
Pad 4-bit unsigned integer. Number of octets that
are used for padding after Address[n] at the end
of the SRH.
Reserved This field is unused. It MUST be initialized to
zero by the sender and MUST be ignored by the
receiver.
RPLInstanceID 8-bit unsigned integer. Indicates the RPL
Instance along which the packet is sent.
Address[1..n] Vector of addresses, numbered 1 to n. Each
vector element in [1..n-1] has size (16 - CmprI)
and element [n] has size (16-CmprE). The
originator of a SRH places the next-hop's IPv6
address as the first address in Address[1..n]
(i.e. Address[1]).
The SRH shares the same basic format as the Type 0 Routing header
[RFC2460]. When carrying full IPv6 addresses, the CmprI, CmprE, and
Pad fields are set to 0 and the only difference between the SRH and
Type 0 encodings is the value of the Routing Type field.
A common network configuration for a RPL Instance is that all routers
within a RPL Instance share a common prefix. The SRH introduces the
CmprI, CmprE, and Pad fields to allow compaction of the Address[1..n]
vector when all entries share the same prefix as the IPv6 Destination
Address field of the packet carrying the SRH. The CmprI and CmprE
field indicates the number of prefix octets that are shared with the
IPv6 Destination Address of the packet carrying the SRH. The shared
prefix octets are not carried within the Routing header and each
entry in Address[1..n-1] has size (16 - CmprI) octets and Address[n]
has size (16 - CmprE) octets. When CmprI or CmprE is non-zero, there
may exist unused octets between the last entry, Address[n], and the
end of the Routing header. The Pad field indicates the number of
unused octets that are used for padding. Note that when CmprI and
CmprE are both 0, Pad MUST carry a value of 0.
The SRH MUST NOT specify a path that visits a node more than once.
When generating a SRH, the source may not know the mapping between
IPv6 addresses and nodes. Minimally, the source MUST ensure that
IPv6 Addresses do not appear more than once and the IPv6 Source and
Destination addresses of the encapsulating datagram do not appear in
Hui, et al. Expires June 18, 2012 [Page 8]
Internet-Draft RPL Source Route Header December 2011
the SRH.
Multicast addresses MUST NOT appear in a SRH, or in the IPv6
Destination Address field of a datagram carrying a SRH.
Hui, et al. Expires June 18, 2012 [Page 9]
Internet-Draft RPL Source Route Header December 2011
4. RPL Router Behavior
4.1. Generating Source Routing Headers
To deliver an IPv6 datagram to its destination, a router may need to
generate a new SRH and specify a strict source route. When the
router is the source of the original packet and the destination is
known to be within the same RPL Instance, the router SHOULD include
the SRH directly within the original packet. Otherwise, the router
MUST use IPv6-in-IPv6 tunneling [RFC2473] and place the SRH in the
tunnel header. Using IPv6-in-IPv6 tunneling ensures that the
delivered datagram remains unmodified and that ICMPv6 errors
generated by a SRH are sent back to the router that generated the
SRH.
In order to respect the IPv6 Hop Limit value of the original
datagram, a RPL router generating an SRH MUST set the Segments Left
to no greater than the original datagram's IPv6 Hop Limit value upon
forwarding. In the case that the source route is longer than the
original datagram's IPv6 Hop Limit, only the initial hops (determined
by the original datagram's IPv6 Hop Limit) should be included in the
SRH. If the RPL router is not the source of the original datagram,
the original datagram's IPv6 Hop Limit field is decremented before
generating the SRH. After generating the SRH, the RPL router
decrements the original datagram's IPv6 Hop Limit value by the SRH
Segments Left value. Processing the SRH Segments Left and original
datagram's IPv6 Hop Limit fields in this way ensures that ICMPv6 Time
Exceeded errors occur as would be expected on more traditional IPv6
networks that forward datagrams without tunneling.
To avoid fragmentation, it is desirable to employ MTU sizes that
allow for the header expansion (i.e. at least 1280 + 40 (outer IP
header) + SRH_MAX_SIZE), where SRH_MAX_SIZE is the maximum path
length for a given RPL network. To take advantage of this, however,
the communicating endpoints need to be aware of the MTU along the
path (i.e. through Path MTU Discovery). Unfortunately, the larger
MTU size may not be available on all links (e.g. 1280 octets on
6LoWPAN links). However, it is expected that much of the traffic on
these types of networks consists of much smaller messages than the
MTU, so performance degradation through fragmentation would be
limited.
4.2. Processing Source Routing Headers
As specified in [RFC2460], a routing header is not examined or
processed until it reaches the node identified in the Destination
Address field of the IPv6 header. In that node, dispatching on the
Next Header field of the immediately preceding header causes the
Hui, et al. Expires June 18, 2012 [Page 10]
Internet-Draft RPL Source Route Header December 2011
Routing header module to be invoked.
The function of SRH is intended to be very similar to the Type 0
Routing Header defined in [RFC2460]. After the routing header has
been processed and the IPv6 datagram resubmitted to the IPv6 module
for processing, the IPv6 Destination Address contains the next hop's
address. When forwarding an IPv6 datagram that contains a SRH with a
non-zero Segments Left value, if the IPv6 Destination Address is not
on-link, a router MUST drop the datagram and SHOULD send an ICMP
Destination Unreachable (ICMPv6 Type 1) message with ICMPv6 Code set
to (TBD by IANA) to the packet's Source Address. This ICMPv6 Code
indicates that the IPv6 Destination Address is not on-link and the
router cannot satisfy the strict source route requirement. When
generating ICMPv6 error messages, the rules in Section 2.4 of
[RFC4443] must be observed.
To detect loops in the SRH, a router MUST determine if the SRH
includes multiple addresses assigned to any interface on that router.
If such addresses appear more than once and are separated by at least
one address not assigned to that router, the router MUST drop the
packet and SHOULD send an ICMP Parameter Problem, Code 0, to the
Source Address. While this loop check does add significant per-
packet processing overhead, it is required to mitigate bandwidth
exhaustion attacks that led to the deprecation of RH0 [RFC5095].
The following describes the algorithm performed when processing a
SRH:
Hui, et al. Expires June 18, 2012 [Page 11]
Internet-Draft RPL Source Route Header December 2011
if Segments Left = 0 {
proceed to process the next header in the packet, whose type is
identified by the Next Header field in the Routing header
}
else {
compute n, the number of addresses in the Routing header, by
n = (((Hdr Ext Len * 8) - Pad - (16 - CmprE)) / (16 - CmprI)) + 1
if Segments Left is greater than n {
send an ICMP Parameter Problem, Code 0, message to the Source
Address, pointing to the Segments Left field, and discard the
packet
}
else {
decrement Segments Left by 1
compute i, the index of the next address to be visited in
the address vector, by subtracting Segments Left from n
if Address[i] or the IPv6 Destination Address is multicast {
discard the packet
}
else if 2 or more entries in Address[1..n] are assigned to
local interface and are separated by at least one
address not assigned to local interface {
send an ICMP Parameter Problem (Code 0) and discard the
packet
}
else {
swap the IPv6 Destination Address and Address[i]
if the IPv6 Hop Limit is less than or equal to 1 {
send an ICMP Time Exceeded -- Hop Limit Exceeded in
Transit message to the Source Address and discard the
packet
}
else {
decrement the Hop Limit by 1
resubmit the packet to the IPv6 module for transmission
to the new destination
}
}
}
}
RPL routers are responsible for ensuring that a SRH is only used
Hui, et al. Expires June 18, 2012 [Page 12]
Internet-Draft RPL Source Route Header December 2011
between RPL routers:
1. For datagrams destined to a RPL router, the router processes the
packet in the usual way. For instance, if the SRH was included
using tunneled mode and the RPL router serves as the tunnel
endpoint, the router removes the outer IPv6 header, at the same
time removing the SRH as well.
2. Datagrams destined elsewhere within the same RPL Instance are
forwarded to the correct interface.
3. Datagrams destined to nodes outside the RPL Instance are dropped
if the outer-most IPv6 header contains a SRH not generated by the
RPL router forwarding the datagram.
Hui, et al. Expires June 18, 2012 [Page 13]
Internet-Draft RPL Source Route Header December 2011
5. Security Considerations
5.1. Source Routing Attacks
The RPL message security mechanisms defined in [I-D.ietf-roll-rpl] do
not apply to the RPL Source Route Header. This specification does
not provide any confidentiality, integrity, or authenticity
mechanisms to protect the SRH.
[RFC5095] deprecates the Type 0 Routing header due to a number of
significant attacks that are referenced in that document. Such
attacks include bypassing filtering devices, reaching otherwise
unreachable Internet systems, network topology discovery, bandwidth
exhaustion, and defeating anycast.
Because this document specifies that SRH is only for use within a RPL
Instance, such attacks cannot be mounted from outside a RPL Instance.
As specified in this document, RPL routers MUST drop datagrams
entering or exiting a RPL Instance that contain a SRH in the IPv6
Extension headers.
Such attacks, however, can be mounted from within a RPL Instance. To
mitigate bandwidth exhaustion attacks, this specification requires
RPL routers to check for loops in the SRH and drop datagrams that
contain such loops. Attacks that include bypassing filtering devices
and reaching otherwise unreachable Internet systems are not as
relevant in mesh networks since the topologies are, by their very
nature, highly dynamic. The RPL routing protocol is designed to
provide reachability to all devices within a RPL Instance and may
utilize routes that traverse any number of devices in any order.
Even so, these attacks and others (e.g. defeating anycast and routing
topology discovery) can occur within a RPL Instance when using this
specification.
5.2. ICMPv6 Attacks
The generation of ICMPv6 error messages may be used to attempt
denial-of-service attacks by sending error-causing SRH in back-to-
back datagrams. An implementation that correctly follows Section 2.4
of [RFC4443] would be protected by the ICMPv6 rate limiting
mechanism.
Hui, et al. Expires June 18, 2012 [Page 14]
Internet-Draft RPL Source Route Header December 2011
6. IANA Considerations
This document defines a new IPv6 Routing Type, the "RPL Source Route
Header", and has been assigned assigned number TBD by IANA.
This document defines a new ICMPv6 Destination Unreachable Code, the
"strict source route failed" error, and has been assigned number TBD
by IANA.
Hui, et al. Expires June 18, 2012 [Page 15]
Internet-Draft RPL Source Route Header December 2011
7. Acknowledgements
The authors thank Jari Arkko, Ralph Droms, Adrian Farrel, Stephen
Farrell, Richard Kelsey, Suresh Krishnan, Erik Nordmark, Pascal
Thubert, Sean Turner, and Tim Winter for their comments and
suggestions that helped shape this document.
Hui, et al. Expires June 18, 2012 [Page 16]
Internet-Draft RPL Source Route Header December 2011
8. Changes
(This section to be removed by the RFC editor.)
Draft 06:
- Address IESG comments.
Draft 05:
- Address LC comments.
Draft 04:
- Updated text on recommendations for avoiding fragmentation.
- Clarify definition of CmprE where it is first mentioned.
- Change use of IPv6-in-IPv6 tunneling from SHOULD to MUST.
- Update packet processing pseudocode to match the text on sending
back a parameter problem error.
- Recommend that non-RPL devices drop packets with SRH by default.
- Clarify packet structure figures.
- State that checking for cycles represents significant per-packet
processing.
Draft 03:
- Removed any presumed values that are TBD by IANA.
Draft 02:
- Updated to send ICMP Destination Unreachable error only after
the SRH has been processed.
- Updated pseudocode to reflect encoding changes in draft-01.
- Allow multiple addresses assigned to same node as long as they
are not separated by other addresses.
Draft 01:
Hui, et al. Expires June 18, 2012 [Page 17]
Internet-Draft RPL Source Route Header December 2011
- Allow Addresses[1..n-1] and Addresses[n] to have a different
number of bytes elided.
Hui, et al. Expires June 18, 2012 [Page 18]
Internet-Draft RPL Source Route Header December 2011
9. References
9.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2460] Deering, S. and R. Hinden, "Internet Protocol, Version 6
(IPv6) Specification", RFC 2460, December 1998.
[RFC2473] Conta, A. and S. Deering, "Generic Packet Tunneling in
IPv6 Specification", RFC 2473, December 1998.
[RFC4443] Conta, A., Deering, S., and M. Gupta, "Internet Control
Message Protocol (ICMPv6) for the Internet Protocol
Version 6 (IPv6) Specification", RFC 4443, March 2006.
[RFC5095] Abley, J., Savola, P., and G. Neville-Neil, "Deprecation
of Type 0 Routing Headers in IPv6", RFC 5095,
December 2007.
9.2. Informative References
[I-D.ietf-roll-rpl]
Winter, T., Thubert, P., Brandt, A., Clausen, T., Hui, J.,
Kelsey, R., Levis, P., Pister, K., Struik, R., and J.
Vasseur, "RPL: IPv6 Routing Protocol for Low power and
Lossy Networks", draft-ietf-roll-rpl-19 (work in
progress), March 2011.
Hui, et al. Expires June 18, 2012 [Page 19]
Internet-Draft RPL Source Route Header December 2011
Authors' Addresses
Jonathan W. Hui
Cisco Systems, Inc
170 West Tasman Drive
San Jose, California 95134
USA
Phone: +408 424 1547
Email: jonhui@cisco.com
JP Vasseur
Cisco Systems, Inc
11, Rue Camille Desmoulins
Issy Les Moulineaux, 92782
France
Email: jpv@cisco.com
David E. Culler
UC Berkeley
465 Soda Hall
Berkeley, California 94720
USA
Phone: +510 643 7572
Email: culler@cs.berkeley.edu
Vishwas Manral
Hewlett Packard Co.
19111 Pruneridge Ave.
Cupertino, California 95014
USA
Email: vishwas.manral@hp.com
Hui, et al. Expires June 18, 2012 [Page 20]
