< draft-ietf-6man-rpl-routing-header-00.txt   draft-ietf-6man-rpl-routing-header-01.txt >
6MAN J. Hui 6MAN J. Hui
Internet-Draft Arch Rock Corporation Internet-Draft Arch Rock Corporation
Intended status: Standards Track JP. Vasseur Intended status: Standards Track JP. Vasseur
Expires: January 27, 2011 Cisco Systems, Inc Expires: April 26, 2011 Cisco Systems, Inc
D. Culler D. Culler
UC Berkeley UC Berkeley
July 26, 2010 V. Manral
IP Infusion
October 23, 2010
An IPv6 Routing Header for Source Routes with RPL An IPv6 Routing Header for Source Routes with RPL
draft-ietf-6man-rpl-routing-header-00 draft-ietf-6man-rpl-routing-header-01
Abstract Abstract
In Low power and Lossy Networks (LLNs), memory constraints on routers In Low power and Lossy Networks (LLNs), memory constraints on routers
may limit them to maintaining at most a few routes. In some may limit them to maintaining at most a few routes. In some
configurations, it is necessary to use these memory constrained configurations, it is necessary to use these memory constrained
routers to deliver datagrams to nodes within the LLN. The Routing routers to deliver datagrams to nodes within the LLN. The Routing
for Low Power and Lossy Networks (RPL) protocol can be used in some 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 deployments to store most, if not all, routes on one (e.g. the
Directed Acyclic Graph (DAG) root) or few routers and forward the Directed Acyclic Graph (DAG) root) or few routers and forward the
skipping to change at page 1, line 43 skipping to change at page 1, line 45
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 January 27, 2011. This Internet-Draft will expire on April 26, 2011.
Copyright Notice Copyright Notice
Copyright (c) 2010 IETF Trust and the persons identified as the Copyright (c) 2010 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
skipping to change at page 2, line 31 skipping to change at page 2, line 32
4. RPL Router Behavior . . . . . . . . . . . . . . . . . . . . . 9 4. RPL Router Behavior . . . . . . . . . . . . . . . . . . . . . 9
4.1. Generating Type 4 Routing Headers . . . . . . . . . . . . 9 4.1. Generating Type 4 Routing Headers . . . . . . . . . . . . 9
4.2. Processing Type 4 Routing Headers . . . . . . . . . . . . 9 4.2. Processing Type 4 Routing Headers . . . . . . . . . . . . 9
5. RPL Border Router Behavior . . . . . . . . . . . . . . . . . . 11 5. RPL Border Router Behavior . . . . . . . . . . . . . . . . . . 11
6. Security Considerations . . . . . . . . . . . . . . . . . . . 12 6. Security Considerations . . . . . . . . . . . . . . . . . . . 12
6.1. Source Routing Attacks . . . . . . . . . . . . . . . . . . 12 6.1. Source Routing Attacks . . . . . . . . . . . . . . . . . . 12
6.2. ICMPv6 Attacks . . . . . . . . . . . . . . . . . . . . . . 12 6.2. ICMPv6 Attacks . . . . . . . . . . . . . . . . . . . . . . 12
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13
8. Protocol Constants . . . . . . . . . . . . . . . . . . . . . . 14 8. Protocol Constants . . . . . . . . . . . . . . . . . . . . . . 14
9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 15 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 15
10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 16 10. Changes . . . . . . . . . . . . . . . . . . . . . . . . . . . 16
10.1. Normative References . . . . . . . . . . . . . . . . . . . 16 11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 17
10.2. Informative References . . . . . . . . . . . . . . . . . . 16 11.1. Normative References . . . . . . . . . . . . . . . . . . . 17
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 17 11.2. Informative References . . . . . . . . . . . . . . . . . . 17
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 18
1. Introduction 1. Introduction
Routing for Low Power and Lossy Networks (RPL) is a distance vector Routing for Low Power and Lossy Networks (RPL) is a distance vector
IPv6 routing protocol designed for Low Power and Lossy networks (LLN) IPv6 routing protocol designed for Low Power and Lossy networks (LLN)
[I-D.ietf-roll-rpl]. Such networks are typically constrained in [I-D.ietf-roll-rpl]. Such networks are typically constrained in
resources (limited communication data rate, processing power, energy resources (limited communication data rate, processing power, energy
capacity, memory). In particular, some LLN configurations may capacity, memory). In particular, some LLN configurations may
utilize LLN routers where memory constraints limit nodes to utilize LLN routers where memory constraints limit nodes to
maintaining only a small number of default routes and no other maintaining only a small number of default routes and no other
skipping to change at page 7, line 14 skipping to change at page 7, line 14
3. Format of the RPL Routing Header 3. Format of the RPL Routing Header
The Type 4 Routing header has the following format: The Type 4 Routing header has the following format:
0 1 2 3 0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Next Header | Hdr Ext Len | Routing Type=4| Segments Left | | Next Header | Hdr Ext Len | Routing Type=4| Segments Left |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Compr | Pad | Reserved | | CmprI | CmprE | Pad | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | | |
. . . .
. Addresses[1..n] . . Addresses[1..n] .
. . . .
| | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Next Header 8-bit selector. Identifies the type of header Next Header 8-bit selector. Identifies the type of header
immediately following the Routing header. Uses immediately following the Routing header. Uses
the same values as the IPv4 Protocol field the same values as the IPv4 Protocol field
[RFC3232]. [RFC3232].
Hdr Ext Len 8-bit unsigned integer. Length of the Routing Hdr Ext Len 8-bit unsigned integer. Length of the Routing
header in 8-octet units, not including the first header in 8-octet units, not including the first
8 octets. Hdr Ext Len MUST NOT exceed 8 octets. Hdr Ext Len MUST NOT exceed
RH4_MAX_SIZE / 8. Note that when Addresses[1..n] RH4_MAX_SIZE / 8. Note that when Addresses[1..n]
are compressed (i.e. value of Compr is not 0), are compressed (i.e. value of CmprI or CmprE is
Hdr Ext Len does not equal twice the number of not 0), Hdr Ext Len does not equal twice the
Addresses. number of Addresses.
Routing Type 8-bit selector. Set to 4 (to be confirmed by Routing Type 8-bit selector. Set to 4 (to be confirmed by
IANA). IANA).
Segments Left 8-bit unsigned integer. Number of route segments Segments Left 8-bit unsigned integer. Number of route segments
remaining, i.e., number of explicitly listed remaining, i.e., number of explicitly listed
intermediate nodes still to be visited before intermediate nodes still to be visited before
reaching the final destination. Value MUST be reaching the final destination. Value MUST be
between 0 and Segments, inclusive. between 0 and Segments, inclusive.
Compr 4-bit unsigned integer. Number of prefix octets CmprI 4-bit unsigned integer. Number of prefix octets
from each segment that is elided. For example, a from each segment, except than the last segment,
Type 4 Routing header carrying full IPv6 that are elided. For example, a Type 4 Routing
addresses sets Compr to 0. header carrying full IPv6 addresses in
Addresses[1..n-1] sets CmprI to 0.
CmprE 4-bit unsigned integer. Number of prefix octets
from the segment that are elided. For example, a
Type 4 Routing header carrying a full IPv6
address in Addresses[n] sets CmprE to 0.
Pad 4-bit unsigned integer. Number of octets that Pad 4-bit unsigned integer. Number of octets that
are used to for padding after Address[n] and the are used to for padding after Address[n] and the
end of the Type 4 Routing header. end of the Type 4 Routing header.
Address[1..n] Vector of addresses, numbered 1 to n. Each Address[1..n] Vector of addresses, numbered 1 to n. Each
vector element has size (16 - Compr). vector element in [1..n-1] has size (16 - CmprI)
and element [n] has size (16-CmprE).
The Type 4 Routing header shares the same basic format as the Type 0 The Type 4 Routing header shares the same basic format as the Type 0
Routing header [RFC2460]. When carrying full IPv6 addresses, the Routing header [RFC2460]. When carrying full IPv6 addresses, the
Compr and Pad fields are set to 0 and the only difference between the CmprI, CmprE, and Pad fields are set to 0 and the only difference
Type 4 and Type 0 encodings is the value of the Routing Type field. between the Type 4 and Type 0 encodings is the value of the Routing
Type field.
A common network configuration for a RPL domain is that all nodes A common network configuration for a RPL domain is that all nodes
within a LLN share a common prefix. Type 4 Routing header introduces within a LLN share a common prefix. Type 4 Routing header introduces
the Compr and Pad fields to allow compaction of the Address[1..n] the CmprI, CmprE, and Pad fields to allow compaction of the
vector when all entries share the same prefix as the IPv6 Destination Address[1..n] vector when all entries share the same prefix as the
Address field of the encapsulating datagram. The Compr field IPv6 Destination Address field of the encapsulating datagram. The
indicates the number of prefix octets that are shared with the IPv6 CmprI and CmprE field indicates the number of prefix octets that are
Destination Address of the encapsulating header. The shared prefix shared with the IPv6 Destination Address of the encapsulating header.
octets are not carried within the Routing header and each entry in The shared prefix octets are not carried within the Routing header
Address[1..n] has size (16 - Compr) octets. When Compr is non-zero, and each entry in Address[1..n-1] has size (16 - CmprI) octets and
there may exists unused octets between the last entry, Address[n], Address[n] has size (16 - CmprE) octets. When CmprI or CmprE is non-
and the end of the Routing header. The Pad field indicates the zero, there may exist unused octets between the last entry,
number of unused octets that are used for padding. Note that when Address[n], and the end of the Routing header. The Pad field
Compr is 0, Pad MUST be null and carry a value of 0. indicates the number of unused octets that are used for padding.
Note that when CmprI and CmprE are both 0, Pad MUST be null and carry
a value of 0.
The Type 4 Routing header MUST NOT specify a path that visits a node The Type 4 Routing header MUST NOT specify a path that visits a node
more than once. When generating a Type 4 Routing header, the source more than once. When generating a Type 4 Routing header, the source
may not know the mapping between IPv6 addresses and nodes. may not know the mapping between IPv6 addresses and nodes.
Minimally, the source MUST ensure that IPv6 Addresses do not appear Minimally, the source MUST ensure that IPv6 Addresses do not appear
more than once and the IPv6 Source and Destination addresses of the more than once and the IPv6 Source and Destination addresses of the
encapsulating datagram do not appear in the Type 4 Routing header. encapsulating datagram do not appear in the Type 4 Routing header.
Multicast addresses MUST NOT appear in a Type 4 Routing header, or in Multicast addresses MUST NOT appear in a Type 4 Routing header, or in
the IPv6 Destination Address field of a datagram carrying a Type 4 the IPv6 Destination Address field of a datagram carrying a Type 4
skipping to change at page 15, line 7 skipping to change at page 15, line 7
8. Protocol Constants 8. Protocol Constants
RH4_MAX_SIZE 136 RH4_MAX_SIZE 136
With a base header size of 8 octets, 136 octets will allow for up to With a base header size of 8 octets, 136 octets will allow for up to
8 16-octet address entries in the Type 4 Routing header. More 8 16-octet address entries in the Type 4 Routing header. More
entries are possible within 136 octets when compression is used. entries are possible within 136 octets when compression is used.
9. Acknowledgements 9. Acknowledgements
The authors thank Vishwas Manral and Erik Nordmark for their comments The authors thank Richard Kelsey, Erik Nordmark, Pascal Thubert, and
and suggestions that helped shape this document. Tim Winter for their comments and suggestions that helped shape this
document.
10. References 10. Changes
10.1. Normative References (This section to be removed by the RFC editor.)
Draft 01:
- Allow Addresses[1..n-1] and Addresses[n] to have a different
number of bytes elided.
11. References
11.1. Normative References
[RFC0791] Postel, J., "Internet Protocol", STD 5, RFC 791, [RFC0791] Postel, J., "Internet Protocol", STD 5, RFC 791,
September 1981. September 1981.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997. Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2460] Deering, S. and R. Hinden, "Internet Protocol, Version 6 [RFC2460] Deering, S. and R. Hinden, "Internet Protocol, Version 6
(IPv6) Specification", RFC 2460, December 1998. (IPv6) Specification", RFC 2460, December 1998.
skipping to change at page 16, line 29 skipping to change at page 17, line 29
IPv6 Specification", RFC 2473, December 1998. IPv6 Specification", RFC 2473, December 1998.
[RFC4443] Conta, A., Deering, S., and M. Gupta, "Internet Control [RFC4443] Conta, A., Deering, S., and M. Gupta, "Internet Control
Message Protocol (ICMPv6) for the Internet Protocol Message Protocol (ICMPv6) for the Internet Protocol
Version 6 (IPv6) Specification", RFC 4443, March 2006. Version 6 (IPv6) Specification", RFC 4443, March 2006.
[RFC5095] Abley, J., Savola, P., and G. Neville-Neil, "Deprecation [RFC5095] Abley, J., Savola, P., and G. Neville-Neil, "Deprecation
of Type 0 Routing Headers in IPv6", RFC 5095, of Type 0 Routing Headers in IPv6", RFC 5095,
December 2007. December 2007.
10.2. Informative References 11.2. Informative References
[I-D.ietf-roll-rpl] [I-D.ietf-roll-rpl]
Winter, T., Thubert, P., and R. Team, "RPL: IPv6 Routing Winter, T., Thubert, P., Brandt, A., Clausen, T., Hui, J.,
Protocol for Low power and Lossy Networks", Kelsey, R., Levis, P., Networks, D., Struik, R., and J.
draft-ietf-roll-rpl-10 (work in progress), June 2010. Vasseur, "RPL: IPv6 Routing Protocol for Low power and
Lossy Networks", draft-ietf-roll-rpl-13 (work in
progress), October 2010.
[I-D.ietf-roll-terminology] [I-D.ietf-roll-terminology]
Vasseur, J., "Terminology in Low power And Lossy Vasseur, J., "Terminology in Low power And Lossy
Networks", draft-ietf-roll-terminology-03 (work in Networks", draft-ietf-roll-terminology-04 (work in
progress), March 2010. progress), September 2010.
[RFC3232] Reynolds, J., "Assigned Numbers: RFC 1700 is Replaced by [RFC3232] Reynolds, J., "Assigned Numbers: RFC 1700 is Replaced by
an On-line Database", RFC 3232, January 2002. an On-line Database", RFC 3232, January 2002.
Authors' Addresses Authors' Addresses
Jonathan W. Hui Jonathan W. Hui
Arch Rock Corporation Arch Rock Corporation
501 2nd St. Ste. 410 501 2nd St. Ste. 410
San Francisco, California 94107 San Francisco, California 94107
skipping to change at line 535 skipping to change at page 18, line 32
Email: jpv@cisco.com Email: jpv@cisco.com
David E. Culler David E. Culler
UC Berkeley UC Berkeley
465 Soda Hall 465 Soda Hall
Berkeley, California 94720 Berkeley, California 94720
USA USA
Phone: +510 643 7572 Phone: +510 643 7572
Email: culler@cs.berkeley.edu Email: culler@cs.berkeley.edu
Vishwas Manral
IP Infusion
Bamankhola, Bansgali
Almora, Uttarakhand 263601
India
Phone: +91-98456-61911
Email: vishwas@ipinfusion.com
 End of changes. 18 change blocks. 
40 lines changed or deleted 65 lines changed or added

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