draft-ietf-6man-rpl-option-03.txt   draft-ietf-6man-rpl-option-04.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: September 30, 2011 Cisco Systems, Inc Expires: April 14, 2012 Cisco Systems, Inc
March 29, 2011 October 12, 2011
RPL Option for Carrying RPL Information in Data-Plane Datagrams RPL Option for Carrying RPL Information in Data-Plane Datagrams
draft-ietf-6man-rpl-option-03 draft-ietf-6man-rpl-option-04
Abstract Abstract
The RPL protocol requires data-plane datagrams to carry RPL routing The RPL protocol requires data-plane datagrams to carry RPL routing
information that is processed by RPL routers when forwarding those information that is processed by RPL routers when forwarding those
datagrams. This document describes the RPL option for use within a datagrams. This document describes the RPL Option for use within a
RPL domain. RPL domain.
Status of this Memo Status of this Memo
This Internet-Draft is submitted in full conformance with the This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79. provisions of BCP 78 and BCP 79.
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 September 30, 2011. This Internet-Draft will expire on April 14, 2012.
Copyright Notice Copyright Notice
Copyright (c) 2011 IETF Trust and the persons identified as the Copyright (c) 2011 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 11 skipping to change at page 2, line 11
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 . . . . . . . . . . . . . . . . . . . . . . . . . 3 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1. Requirements Language . . . . . . . . . . . . . . . . . . 3 1.1. Requirements Language . . . . . . . . . . . . . . . . . . 3
2. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . 4 2. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . 4
3. Format of the RPL Option . . . . . . . . . . . . . . . . . . . 5 3. Format of the RPL Option . . . . . . . . . . . . . . . . . . . 5
4. RPL Router Behavior . . . . . . . . . . . . . . . . . . . . . 6 4. RPL Router Behavior . . . . . . . . . . . . . . . . . . . . . 7
5. RPL Border Router Behavior . . . . . . . . . . . . . . . . . . 7 5. RPL Border Router Behavior . . . . . . . . . . . . . . . . . . 8
6. Usage of the RPL Option . . . . . . . . . . . . . . . . . . . 8 6. Security Considerations . . . . . . . . . . . . . . . . . . . 9
7. Protocol Constants . . . . . . . . . . . . . . . . . . . . . . 9 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10
8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 10 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 11
9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11 9. Changes . . . . . . . . . . . . . . . . . . . . . . . . . . . 12
10. Security Considerations . . . . . . . . . . . . . . . . . . . 12 10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 13
11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 13 10.1. Normative References . . . . . . . . . . . . . . . . . . . 13
11.1. Normative References . . . . . . . . . . . . . . . . . . . 13 10.2. Informative References . . . . . . . . . . . . . . . . . . 13
11.2. Informative References . . . . . . . . . . . . . . . . . . 13
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 14 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 14
1. Introduction 1. Introduction
RPL is a distance vector IPv6 routing protocol designed for low power RPL is a distance vector IPv6 routing protocol designed for Low power
and lossy networks [I-D.ietf-roll-rpl]. Such networks are typically and Lossy Networks (LLNs) [I-D.ietf-roll-rpl]. Such networks are
constrained in energy and/or channel capacity. To conserve precious typically constrained in energy and/or channel capacity. To conserve
resources, a routing protocol must generate control traffic precious resources, a routing protocol must generate control traffic
sparingly. However, this is at odds with the need to quickly sparingly. However, this is at odds with the need to quickly
propagate any new routing information to resolve routing propagate any new routing information to resolve routing
inconsistencies quickly. inconsistencies quickly.
To help minimize resource consumption, RPL uses a slow proactive To help minimize resource consumption, RPL uses a slow proactive
process to construct and maintain a routing topology but a reactive process to construct and maintain a routing topology but a reactive
and dynamic process to resolving routing inconsistencies. In the and dynamic process to resolving routing inconsistencies. In the
steady state, RPL maintains the routing topology using a low-rate steady state, RPL maintains the routing topology using a low-rate
beaconing process. However, when RPL detects inconsistencies that beaconing process. However, when RPL detects inconsistencies that
may prevent proper datagram delivery, RPL temporarily increases the may prevent proper datagram delivery, RPL temporarily increases the
beacon rate to quickly resolve those inconsistencies. This dynamic beacon rate to quickly resolve those inconsistencies. This dynamic
rate control operation is governed by the use of dynamic timers also rate control operation is governed by the use of dynamic timers also
referred to as "Trickle" timers and defined in referred to as "Trickle" timers and defined in
[I-D.ietf-roll-trickle]. In contrast to other routing protocols (e.g [I-D.ietf-roll-trickle]. In contrast to other routing protocols (e.g
OSPF [RFC2328]), RPL detects routing inconsistencies using data-path OSPF [RFC2328]), RPL detects routing inconsistencies using data-path
verification, by including routing information within the datagram verification, by including routing information within the datagram
itself. In doing so, repair mechanisms operate only as needed, itself. In doing so, repair mechanisms operate only as needed,
allowing the control and data planes to operate on similar time allowing the control and data planes to operate on similar time
scales. The main motivation for data path verification in Low power scales. The main motivation for data path verification in LLNs is
and Lossy Networks (LLNs) is that control plane traffic should be that control plane traffic should be carefully bounded with respect
carefully bounded with respect to the data traffic. Intuitively, to the data traffic. Intuitively, there is no need to solve routing
there is no need to solve routing issues (which may be temporary) in issues (which may be temporary) in the absence of data traffic.
the absence of data traffic.
The RPL protocol constructs a Directed Acyclic Graph (DAG) that The RPL protocol constructs a Directed Acyclic Graph (DAG) that
attempts to minimize path costs to the DAG root according to a set of attempts to minimize path costs to the DAG root according to a set of
metric and objective functions. There are circumstances where loops metric and objective functions. There are circumstances where loops
may occur, and RPL is designed to use a data-path loop detection may occur, and RPL is designed to use a data-path loop detection
method. This is one of the known requirements of RPL and other data- method. This is one of the known requirements of RPL and other data-
path usage might be defined in the future. path usage might be defined in the future.
To that end, this document proposes a new IPv6 option, called the RPL To that end, this document proposes a new IPv6 option, called the RPL
Option, to be carried within the IPv6 Hop-by-Hop header. The RPL Option, to be carried within the IPv6 Hop-by-Hop header. The RPL
Option is only for use within a RPL domain. Option is only for use within a RPL domain.
1.1. Requirements Language 1.1. 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 RFC 2119 [RFC2119]. document are to be interpreted as described in RFC 2119 [RFC2119].
2. Overview 2. Overview
Datagrams being forwarded within a RPL domain MUST include a RPL Datagrams sent between nodes within a RPL domain MUST include a RPL
Option. For datagrams sourced within a RPL domain, the RPL Option Option or RPL Source Route Header (SRH) and MAY include both. When a
MAY be included in the datagram itself. For datagrams sourced RPL Border Router inserts a RPL Option, it MUST do so by using IPv6-
outside a RPL domain, IPv6-in-IPv6 tunneling, as specified in in-IPv6 tunneling, as specified in [RFC2473]. Use of tunneling
[RFC2473] SHOULD be used to include a RPL Option. When tunneling, ensures that the datagram is delivered unmodified and that ICMP
the router MUST prepend a new IPv6 header and IPv6 Hop-by-Hop Options errors return to the RPL Option source rather than the source of the
header containing the RPL Option to the existing datagram. Use of original datagram.
tunneling ensures that the datagram is delivered unmodified and that
ICMP errors return to the RPL Option source rather than the source of
the original datagram.
To help avoid IP-layer fragmentation, the RPL Option has a maximum
size of RPL_OPTION_MAX_SIZE octets and links within a RPL domain
SHOULD have a MTU of at least 1280 + 44 (outer IP header, Hop-by-Hop
Option header, Option header) + RPL_OPTION_MAX_SIZE + (additional
extension headers or options needed within RPL domain).
3. Format of the RPL Option 3. Format of the RPL Option
The RPL Option is carried in an IPv6 Hop-by-Hop Options header, The RPL Option is carried in an IPv6 Hop-by-Hop Options header,
immediately following the IPv6 header. This option has an alignment immediately following the IPv6 header. This option has an alignment
requirement of 2n. The option has the following format: requirement of 2n. The option 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
skipping to change at page 5, line 28 skipping to change at page 5, line 28
| (sub-TLVs) | | (sub-TLVs) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 1: RPL Option Figure 1: RPL Option
Option Type: TBD by IANA. Option Type: TBD by IANA.
Opt Data Len: 8-bit field indicating the length of the option, in Opt Data Len: 8-bit field indicating the length of the option, in
octets, excluding the Option Type and Opt Data Len fields. octets, excluding the Option Type and Opt Data Len fields.
Down 'O': 1-bit flag as defined in Section 11 of Down 'O': 1-bit flag as defined in Section 11.2 of
[I-D.ietf-roll-rpl]. [I-D.ietf-roll-rpl]. The processing shall follow the rules
described in Section 11.2 of [I-D.ietf-roll-rpl].
Rank-Error 'R': 1-bit flag as defined in Section 11 of Rank-Error 'R': 1-bit flag as defined in Section 11.2 of
[I-D.ietf-roll-rpl]. [I-D.ietf-roll-rpl]. The processing shall follow the rules
described in Section 11.2 of [I-D.ietf-roll-rpl].
Forwarding-Error 'F': 1-bit flag as defined in Section 11 of Forwarding-Error 'F': 1-bit flag as defined in Section 11.2 of
[I-D.ietf-roll-rpl]. [I-D.ietf-roll-rpl]. The processing shall follow the rules
described in Section 11.2 of [I-D.ietf-roll-rpl].
RPLInstanceID: 8-bit field as defined in Section 11 of RPLInstanceID: 8-bit field as defined in Section 11.2 of
[I-D.ietf-roll-rpl]. [I-D.ietf-roll-rpl]. The processing shall follow the rules
described in Section 11.2 of [I-D.ietf-roll-rpl].
SenderRank: 16-bit field as defined in Section 11 of SenderRank: 16-bit field as defined in Section 11.2 of
[I-D.ietf-roll-rpl]. [I-D.ietf-roll-rpl]. The processing shall follow the rules
described in Section 11.2 of [I-D.ietf-roll-rpl].
Values within the RPL Option are expected to change en-route. Nodes Values within the RPL Option are expected to change en-route. Nodes
that do not understand the RPL Option MUST discard the packet. Thus, that do not understand the RPL Option MUST discard the packet. Thus,
according to [RFC2460] the two high order bits of the Option Type according to [RFC2460] the two high order bits of the Option Type
must be equal set to '01' and the third bit is equal to '1'. The RPL must be equal set to '01' and the third bit is equal to '1'. The RPL
Option Data Length is variable. Option Data Length is variable.
The action taken by using the RPL Option and the potential set of The action taken by using the RPL Option and the potential set of
sub-TLVs carried within the RPL Option MUST be specified by the RFC sub-TLVs carried within the RPL Option MUST be specified by the RFC
of the protocol that use that option. No TLVs are defined in this of the protocol that use that option. No TLVs are defined in this
document. document. A RPL device MUST skip over any unrecognized sub-TLVs and
attempt to process any additional sub-TLVs that may appear after.
4. RPL Router Behavior 4. RPL Router Behavior
RPL controls when and what information is to be placed in a packet. To deliver an IPv6 datagram to its destination, a router may need to
If RPL requires a router to include a RPL Option where one does not insert a new RPL Option. Routers MUST use IPv6-in-IPv6 tunneling, as
already exist, routers SHOULD use IPv6-in-IPv6 tunneling, as specified in [RFC2473] to include a new RPL Option in datagrams that
specified in [RFC2473] to include a RPL Option in datagrams that are are sourced by other nodes. Using IPv6-in-IPv6 tunneling ensures
sourced by other nodes. Using IPv6-in-IPv6 tunneling ensures that that the delivered datagram remains unmodified and that ICMPv6 errors
the original datagram is delivered unmodified. generated by inserting the RPL Option are sent back to the router
that generated the routing header.
Performing IP-in-IP encapsulation may grow the datagram to a size
larger than the IPv6 min MTU of 1280 octets. To help avoid IP-layer
fragmentation caused by IP-in-IP encapsulation, links within a RPL
domain SHOULD be configured with a MTU of at least 1280 + 44 (outer
IP header, Hop-by-Hop Option header, Option header) +
RPL_OPTION_MAX_SIZE + (additional extension headers or options needed
within RPL domain).
In very specific cases, IPv6-in-IPv6 tunneling may be undesirable due To avoid fragmentation, it is desirable to employ MTU sizes that
to the added cost and complexity required to process and carry a allow for the header expansion (i.e. at least 1280 + 40 (outer IP
datagram with two IPv6 headers. [I-D.hui-6man-rpl-headers] describes header) + RPL_OPTION_MAX_SIZE), where RPL_OPTION_MAX_SIZE is the
how to avoid using IPv6-in-IPv6 tunneling in such specific cases and maximum RPL Option header size for a given RPL network. To take
the risks involved. 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.
5. RPL Border Router Behavior 5. RPL Border Router Behavior
RPL Border Routers (referred to as LBRs in RPL Border Routers (referred to as LBRs in
[I-D.ietf-roll-terminology]) are responsible for ensuring that a RPL [I-D.ietf-roll-terminology]) are responsible for ensuring that a RPL
Option is only used within a RPL domain. Option is only used within a RPL domain.
For datagrams entering the RPL domain, RPL Border Routers MUST drop For datagrams destined to the RPL Border Router, the router processes
received datagrams that contain a RPL Option in the IPv6 Extension the packet in the usual way. For instance, if the RPL Option was
headers. included using tunneled mode and the RPL Border Router serves as the
tunnel endpoint, the router removes the outer IPv6 header, at the
For datagrams exiting the RPL domain, RPL Border Routers MUST remove same time removing the RPL Option as well.
the RPL Option from the datagram. If the RPL Option was included
using tunneled mode and the RPL Border Router serves as the tunnel
end-point, removing the outer IPv6 header serves to remove the RPL
Option as well. Otherwise, the RPL Border Router assumes that the
RPL Option was included using transport mode and MUST remove the RPL
Option from the IPv6 Hop-by-Hop Option header.
6. Usage of the RPL Option
The RPL Option is only for use within a RPL domain. RPL routers MUST Datagrams destined elsewhere within the same RPL domain are forwarded
process and include the RPL Option when forwarding datagrams to other to the correct interface.
nodes within the RPL domain. Routers on the edge of a RPL domain
MUST remove the RPL Option when forwarding datagrams to nodes outside
the RPL domain.
7. Protocol Constants Datagrams destined to nodes outside the RPL domain are dropped if the
outer-most IPv6 header contains a RPL Option.
RPL_OPTION_MAX_SIZE 128 6. Security Considerations
8. Acknowledgements This option may be used to mount several potential attacks since
routers may be flooded by bogus datagrams containing the RPL Option.
In particular, an inconsistent Rank value can cause a RPL router to
reset its DIO Trickle timer.
The authors thank Richard Kelsey, Suresh Krishnan, Vishwas Manral, In order to avoid any unacceptable impact on network operations, an
Erik Nordmark, Pascal Thubert, and Tim Winter, for their comments and implementation MAY limit the number of triggers caused by receiving a
suggestions that helped shape this document. RPL Option to no greater than MAX_RPL_OPTION_TRIGGERS per hour. A
RECOMMENDED value for MAX_RPL_OPTION_TRIGGERS is 20.
9. IANA Considerations 7. IANA Considerations
IANA is requested to reserve a new value in the Destination Options IANA is requested to reserve a new value in the Destination Options
and Hop-by-Hop Options registry. The proposed value to be confirmed and Hop-by-Hop Options registry. The proposed value to be confirmed
by IANA is: by IANA is:
Hex Value Binary Value Hex Value Binary Value
act chg rest Description Reference act chg rest Description Reference
--------- --- --- ------- ----------------- ---------- --------- --- --- ------- ----------------- ----------
TBD 01 1 TBD RPL Option [RFCthis] TBD 01 1 TBD RPL Option [RFCthis]
As specified in [RFC2460], the first two bits indicate that the IPv6 As specified in [RFC2460], the first two bits indicate that the IPv6
node MUST discard the packet if it doesn't recognize the option type, node MUST discard the packet if it doesn't recognize the option type,
and the third bit indicates that the Option Data may change en-route. and the third bit indicates that the Option Data may change en-route.
The remaining bits serve as the option type and are TBD by IANA. The remaining bits serve as the option type and are TBD by IANA.
IANA is requested to create a registry called RPL-option-TLV, for the IANA is requested to create a registry called RPL-option-TLV, for the
TLVs carried in the RPL Option header. New codes may be allocated TLVs carried in the RPL Option header. New codes may be allocated
only by IETF Review [RFC5226]. The type field is an 8-bit field only by IETF Review [RFC5226]. The type field is an 8-bit field
whose value be between 0 and 255, inclusive. whose value be between 0 and 255, inclusive.
10. Security Considerations 8. Acknowledgements
This option may be used to mount several potential attacks since The authors thank Jari Arkko, Richard Kelsey, Suresh Krishnan,
routers may be flooded by bogus datagram containing the RPL option. Vishwas Manral, Erik Nordmark, Pascal Thubert, and Tim Winter, for
It is thus RECOMMENDED for routers to implement a rate limiter for their comments and suggestions that helped shape this document.
datagrams using the RPL Option.
11. References 9. Changes
11.1. Normative References (This section to be removed by the RFC editor.)
Draft 04:
- Clarify when the RPL Option is used.
- Updated text on recommendations for avoiding fragmentation.
- Specify skip-over-and-continue policy for unrecognized sub-TLVs.
- Change use of IPv6-in-IPv6 tunneling from SHOULD to MUST.
- Specify RPL Border Router operations in terms of forwarding
decision outcomes.
- Expand security section.
Draft 03:
- Removed any presumed values that are TBD by IANA.
10. References
10.1. Normative References
[I-D.ietf-roll-rpl] [I-D.ietf-roll-rpl]
Winter, T., Thubert, P., Brandt, A., Clausen, T., Hui, J., Winter, T., Thubert, P., Brandt, A., Clausen, T., Hui, J.,
Kelsey, R., Levis, P., Pister, K., Struik, R., and J. Kelsey, R., Levis, P., Pister, K., Struik, R., and J.
Vasseur, "RPL: IPv6 Routing Protocol for Low power and Vasseur, "RPL: IPv6 Routing Protocol for Low power and
Lossy Networks", draft-ietf-roll-rpl-19 (work in Lossy Networks", draft-ietf-roll-rpl-19 (work in
progress), March 2011. progress), March 2011.
[I-D.ietf-roll-trickle] [I-D.ietf-roll-trickle]
Levis, P., Clausen, T., Hui, J., Gnawali, O., and J. Ko, Levis, P., Clausen, T., Hui, J., Gnawali, O., and J. Ko,
skipping to change at page 13, line 36 skipping to change at page 13, line 36
[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.
[RFC2473] Conta, A. and S. Deering, "Generic Packet Tunneling in [RFC2473] Conta, A. and S. Deering, "Generic Packet Tunneling in
IPv6 Specification", RFC 2473, December 1998. IPv6 Specification", RFC 2473, December 1998.
[RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an
IANA Considerations Section in RFCs", BCP 26, RFC 5226, IANA Considerations Section in RFCs", BCP 26, RFC 5226,
May 2008. May 2008.
11.2. Informative References 10.2. Informative References
[I-D.hui-6man-rpl-headers] [I-D.hui-6man-rpl-headers]
Hui, J., Thubert, P., and J. Vasseur, "Using RPL Headers Hui, J., Thubert, P., and J. Vasseur, "Using RPL Headers
Without IP-in-IP", draft-hui-6man-rpl-headers-00 (work in Without IP-in-IP", draft-hui-6man-rpl-headers-00 (work in
progress), July 2010. progress), July 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-05 (work in Networks", draft-ietf-roll-terminology-06 (work in
progress), March 2011. progress), September 2011.
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
USA USA
Phone: +415 692 0828 Phone: +415 692 0828
 End of changes. 29 change blocks. 
105 lines changed or deleted 115 lines changed or added

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