draft-ietf-roll-useofrplinfo-11.txt   draft-ietf-roll-useofrplinfo-12.txt 
ROLL Working Group M. Robles ROLL Working Group M. Robles
Internet-Draft Ericsson Internet-Draft Ericsson
Updates: 6550 (if approved) M. Richardson Updates: 6550 (if approved) M. Richardson
Intended status: Standards Track SSW Intended status: Standards Track SSW
Expires: September 4, 2017 P. Thubert Expires: September 14, 2017 P. Thubert
Cisco Cisco
March 3, 2017 March 13, 2017
When to use RFC 6553, 6554 and IPv6-in-IPv6 When to use RFC 6553, 6554 and IPv6-in-IPv6
draft-ietf-roll-useofrplinfo-11 draft-ietf-roll-useofrplinfo-12
Abstract Abstract
This document looks at different data flows through LLN (Low-Power This document looks at different data flows through LLN (Low-Power
and Lossy Networks) where RPL (IPv6 Routing Protocol for Low-Power and Lossy Networks) where RPL (IPv6 Routing Protocol for Low-Power
and Lossy Networks) is used to establish routing. The document and Lossy Networks) is used to establish routing. The document
enumerates the cases where RFC 6553, RFC 6554 and IPv6-in-IPv6 enumerates the cases where RFC 6553, RFC 6554 and IPv6-in-IPv6
encapsulation is required. This analysis provides the basis on which encapsulation is required. This analysis provides the basis on which
to design efficient compression of these headers. to design efficient compression of these headers.
skipping to change at page 1, line 38 skipping to change at page 1, line 38
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 4, 2017. This Internet-Draft will expire on September 14, 2017.
Copyright Notice Copyright Notice
Copyright (c) 2017 IETF Trust and the persons identified as the Copyright (c) 2017 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 49 skipping to change at page 2, line 49
6.9. Example of Flow from RPL-aware-leaf to RPL-aware-leaf . . 27 6.9. Example of Flow from RPL-aware-leaf to RPL-aware-leaf . . 27
6.10. Example of Flow from RPL-aware-leaf to not-RPL-aware-leaf 28 6.10. Example of Flow from RPL-aware-leaf to not-RPL-aware-leaf 28
6.11. Example of Flow from not-RPL-aware-leaf to RPL-aware-leaf 29 6.11. Example of Flow from not-RPL-aware-leaf to RPL-aware-leaf 29
6.12. Example of Flow from not-RPL-aware-leaf to not-RPL-aware- 6.12. Example of Flow from not-RPL-aware-leaf to not-RPL-aware-
leaf . . . . . . . . . . . . . . . . . . . . . . . . . . 30 leaf . . . . . . . . . . . . . . . . . . . . . . . . . . 30
7. Observations about the cases . . . . . . . . . . . . . . . . 31 7. Observations about the cases . . . . . . . . . . . . . . . . 31
7.1. Storing mode . . . . . . . . . . . . . . . . . . . . . . 31 7.1. Storing mode . . . . . . . . . . . . . . . . . . . . . . 31
7.2. Non-Storing mode . . . . . . . . . . . . . . . . . . . . 32 7.2. Non-Storing mode . . . . . . . . . . . . . . . . . . . . 32
8. 6LoRH Compression cases . . . . . . . . . . . . . . . . . . . 32 8. 6LoRH Compression cases . . . . . . . . . . . . . . . . . . . 32
9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 32 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 32
10. Security Considerations . . . . . . . . . . . . . . . . . . . 33 10. Security Considerations . . . . . . . . . . . . . . . . . . . 32
11. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 35 11. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 35
12. References . . . . . . . . . . . . . . . . . . . . . . . . . 35 12. References . . . . . . . . . . . . . . . . . . . . . . . . . 35
12.1. Normative References . . . . . . . . . . . . . . . . . . 35 12.1. Normative References . . . . . . . . . . . . . . . . . . 35
12.2. Informative References . . . . . . . . . . . . . . . . . 36 12.2. Informative References . . . . . . . . . . . . . . . . . 36
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 38 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 38
1. Introduction 1. Introduction
RPL (IPv6 Routing Protocol for Low-Power and Lossy Networks) RPL (IPv6 Routing Protocol for Low-Power and Lossy Networks)
[RFC6550] is a routing protocol for constrained networks. RFC 6553 [RFC6550] is a routing protocol for constrained networks. RFC 6553
skipping to change at page 13, line 48 skipping to change at page 13, line 48
Note: In this use case we use a node as leaf, but this use case can Note: In this use case we use a node as leaf, but this use case can
be also applicable to any RPL-node type (e.g. 6LR) be also applicable to any RPL-node type (e.g. 6LR)
+-------------------+------+-------+------+----------------+ +-------------------+------+-------+------+----------------+
| Header | 6LN | 6LR_i | 6LBR | Internet | | Header | 6LN | 6LR_i | 6LBR | Internet |
+-------------------+------+-------+------+----------------+ +-------------------+------+-------+------+----------------+
| Inserted headers | RPI | -- | -- | -- | | Inserted headers | RPI | -- | -- | -- |
| Removed headers | -- | -- | -- | -- | | Removed headers | -- | -- | -- | -- |
| Re-added headers | -- | -- | -- | -- | | Re-added headers | -- | -- | -- | -- |
| Modified headers | -- | RPI | -- | -- | | Modified headers | -- | RPI | -- | -- |
| Untouched headers | -- | -- | -- | RPI (Ignored) | | Untouched headers | -- | -- | RPI | RPI (Ignored) |
+-------------------+------+-------+------+----------------+ +-------------------+------+-------+------+----------------+
Storing: Summary of the use of headers from RPL-aware-leaf to Storing: Summary of the use of headers from RPL-aware-leaf to
Internet Internet
5.6. Example of Flow from Internet to RPL-aware-leaf 5.6. Example of Flow from Internet to RPL-aware-leaf
In this case the flow comprises: In this case the flow comprises:
Internet --> root (6LBR) --> 6LR_i --> RPL-aware-leaf (6LN) Internet --> root (6LBR) --> 6LR_i --> RPL-aware-leaf (6LN)
skipping to change at page 15, line 45 skipping to change at page 15, line 45
Internet Internet
5.8. Example of Flow from Internet to non-RPL-aware-leaf 5.8. Example of Flow from Internet to non-RPL-aware-leaf
In this case the flow comprises: In this case the flow comprises:
Internet --> root (6LBR) --> 6LR_i --> not-RPL-aware-leaf (IPv6) Internet --> root (6LBR) --> 6LR_i --> not-RPL-aware-leaf (IPv6)
6LR_i are the intermediate routers from source to destination. In 6LR_i are the intermediate routers from source to destination. In
this case, "1 < i >= n", n is the number of routers (6LR) that the this case, "1 < i >= n", n is the number of routers (6LR) that the
packet go through from 6LBR to not-RPL-aware-leaf (IPv6). packet go through from 6LBR to not-RPL-aware-leaf (IPv6). 6LR_i
updates the rank in the RPI.
The 6LBR will have to add an RPI header within an IP-in-IP header. The 6LBR will have to add an RPI header within an IP-in-IP header.
The IP-in-IP can be addressed to the not-RPL-aware-leaf, leaving the The IP-in-IP can be addressed to the not-RPL-aware-leaf, leaving the
RPI inside. RPI inside.
The 6LBR MAY set the flow label on the inner IP-in-IP header to zero The 6LBR MAY set the flow label on the inner IP-in-IP header to zero
in order to aid in compression. in order to aid in compression.
+-----------+----------+---------------+---------------+------------+ +-----------+----------+---------------+---------------+------------+
| Header | Internet | 6LBR | 6LR_i | IPv6 | | Header | Internet | 6LBR | 6LR_i | IPv6 |
+-----------+----------+---------------+---------------+------------+ +-----------+----------+---------------+---------------+------------+
| Inserted | -- | IP-in-IP(RPI) | -- | -- | | Inserted | -- | IP-in-IP(RPI) | -- | -- |
| headers | | | | | | headers | | | | |
| Removed | -- | -- | IP-in-IP(RPI) | -- | | Removed | -- | -- | -- | -- |
| headers | | | | | | headers | | | | |
| Re-added | -- | -- | -- | -- | | Re-added | -- | -- | -- | -- |
| headers | | | | | | headers | | | | |
| Modified | -- | -- | IP-in-IP(RPI) | -- | | Modified | -- | -- | IP-in-IP(RPI) | -- |
| headers | | | | | | headers | | | | |
| Untouched | -- | -- | -- | RPI | | Untouched | -- | -- | -- | RPI |
| headers | | | | (Ignored) | | headers | | | | (Ignored) |
+-----------+----------+---------------+---------------+------------+ +-----------+----------+---------------+---------------+------------+
Storing: Summary of the use of headers from Internet to non-RPL- Storing: Summary of the use of headers from Internet to non-RPL-
skipping to change at page 20, line 7 skipping to change at page 20, line 7
dst). dst).
This flow is identical to Section 5.11 This flow is identical to Section 5.11
The 6LR_1 receives the packet from the the IPv6 node and inserts the The 6LR_1 receives the packet from the the IPv6 node and inserts the
RPI header (RPIa) encapsulated in IPv6-in-IPv6 header. The IPv6-in- RPI header (RPIa) encapsulated in IPv6-in-IPv6 header. The IPv6-in-
IPv6 header is addressed to the 6LBR. The 6LBR remove the IPv6-in- IPv6 header is addressed to the 6LBR. The 6LBR remove the IPv6-in-
IPv6 header and insert another one (RPIb) with destination to 6LR_m IPv6 header and insert another one (RPIb) with destination to 6LR_m
node. node.
One of the side-effects of inserting IP-in-IP RPI header at 6LR_1, is
that now all the packets will go through the 6LBR, even though there
exists a shorter P2P path to the destination 6LN in storing mode.
One possible solution is given by the work in
[I-D.ietf-roll-dao-projection]. Once we have route projection, the
root can find that this traffic deserves optimization (based on
volume and path length, or additional knowledge on that particular
flow) and project a DAO into 6LR_1.
+-------+-----+-----------+-----------+-----------+-----------+-----+ +-------+-----+-----------+-----------+-----------+-----------+-----+
| Heade | IPv | 6LR_1 | 6LR_ia | 6LBR | 6LR_m | IPv | | Heade | IPv | 6LR_1 | 6LR_ia | 6LBR | 6LR_m | IPv |
| r | 6 | | | | | 6 | | r | 6 | | | | | 6 |
| | src | | | | | dst | | | src | | | | | dst |
+-------+-----+-----------+-----------+-----------+-----------+-----+ +-------+-----+-----------+-----------+-----------+-----------+-----+
| Inser | -- | IP-in- | -- | IP-in- | -- | -- | | Inser | -- | IP-in- | -- | IP-in- | -- | -- |
| ted h | | IP(RPI_a) | | IP(RPI_b) | | | | ted h | | IP(RPI_a) | | IP(RPI_b) | | |
| eader | | | | | | | | eader | | | | | | |
| s | | | | | | | | s | | | | | | |
| Remov | -- | -- | -- | -- | -- | -- | | Remov | -- | -- | -- | -- | -- | -- |
skipping to change at page 24, line 14 skipping to change at page 24, line 14
+------------+------+---------------+---------------+---------------+ +------------+------+---------------+---------------+---------------+
| Header | IPv6 | 6LR_1 | 6LR_i | 6LBR | | Header | IPv6 | 6LR_1 | 6LR_i | 6LBR |
+------------+------+---------------+---------------+---------------+ +------------+------+---------------+---------------+---------------+
| Inserted | -- | IP-in-IP(RPI) | -- | -- | | Inserted | -- | IP-in-IP(RPI) | -- | -- |
| headers | | | | | | headers | | | | |
| Removed | -- | -- | -- | IP-in-IP(RPI) | | Removed | -- | -- | -- | IP-in-IP(RPI) |
| headers | | | | | | headers | | | | |
| Re-added | -- | -- | -- | -- | | Re-added | -- | -- | -- | -- |
| headers | | | | | | headers | | | | |
| Modified | -- | IP-in-IP(RPI) | IP-in-IP(RPI) | -- | | Modified | -- | -- | IP-in-IP(RPI) | -- |
| headers | | | | | | headers | | | | |
| Untouched | -- | -- | -- | -- | | Untouched | -- | -- | -- | -- |
| headers | | | | | | headers | | | | |
+------------+------+---------------+---------------+---------------+ +------------+------+---------------+---------------+---------------+
Non Storing: Summary of the use of headers from not-RPL-aware-leaf to Non Storing: Summary of the use of headers from not-RPL-aware-leaf to
root root
6.5. Example of Flow from RPL-aware-leaf to Internet 6.5. Example of Flow from RPL-aware-leaf to Internet
skipping to change at page 24, line 46 skipping to change at page 24, line 46
the 6LBR will set it to a non-zero value when sending towards the the 6LBR will set it to a non-zero value when sending towards the
Internet. Internet.
+-------------------+------+-------+------+----------------+ +-------------------+------+-------+------+----------------+
| Header | 6LN | 6LR_i | 6LBR | Internet | | Header | 6LN | 6LR_i | 6LBR | Internet |
+-------------------+------+-------+------+----------------+ +-------------------+------+-------+------+----------------+
| Inserted headers | RPI | -- | -- | -- | | Inserted headers | RPI | -- | -- | -- |
| Removed headers | -- | -- | -- | -- | | Removed headers | -- | -- | -- | -- |
| Re-added headers | -- | -- | -- | -- | | Re-added headers | -- | -- | -- | -- |
| Modified headers | -- | RPI | -- | -- | | Modified headers | -- | RPI | -- | -- |
| Untouched headers | -- | -- | -- | RPI (Ignored) | | Untouched headers | -- | -- | RPI | RPI (Ignored) |
+-------------------+------+-------+------+----------------+ +-------------------+------+-------+------+----------------+
Non Storing: Summary of the use of headers from RPL-aware-leaf to Non Storing: Summary of the use of headers from RPL-aware-leaf to
Internet Internet
6.6. Example of Flow from Internet to RPL-aware-leaf 6.6. Example of Flow from Internet to RPL-aware-leaf
In this case the flow comprises: In this case the flow comprises:
Internet --> root (6LBR) --> 6LR_i --> RPL-aware-leaf (6LN) Internet --> root (6LBR) --> 6LR_i --> RPL-aware-leaf (6LN)
skipping to change at page 28, line 30 skipping to change at page 28, line 30
+---------+-------------+------+--------------+-------+-------------+ +---------+-------------+------+--------------+-------+-------------+
| Inserte | IP-in- | -- | IP-in-IP(RH3 | -- | -- | | Inserte | IP-in- | -- | IP-in-IP(RH3 | -- | -- |
| d | IP(RPI1) | | to 6LN, opt | | | | d | IP(RPI1) | | to 6LN, opt | | |
| headers | | | RPI2) | | | | headers | | | RPI2) | | |
| Removed | -- | -- | IP-in- | -- | IP-in- | | Removed | -- | -- | IP-in- | -- | IP-in- |
| headers | | | IP(RPI1) | | IP(RH3, opt | | headers | | | IP(RPI1) | | IP(RH3, opt |
| | | | | | RPI2) | | | | | | | RPI2) |
| Re- | -- | -- | -- | -- | -- | | Re- | -- | -- | -- | -- | -- |
| added | | | | | | | added | | | | | |
| headers | | | | | | | headers | | | | | |
| Modifie | -- | -- | -- | -- | -- | | Modifie | -- | RPI1 | -- | RPI2 | -- |
| d | | | | | | | d | | | | | |
| headers | | | | | | | headers | | | | | |
| Untouch | -- | -- | -- | -- | -- | | Untouch | -- | -- | -- | -- | -- |
| ed | | | | | | | ed | | | | | |
| headers | | | | | | | headers | | | | | |
+---------+-------------+------+--------------+-------+-------------+ +---------+-------------+------+--------------+-------+-------------+
Non Storing: Summary of the use of headers for RPL-aware-leaf to RPL- Non Storing: Summary of the use of headers for RPL-aware-leaf to RPL-
aware-leaf aware-leaf
skipping to change at page 31, line 41 skipping to change at page 31, line 41
7.1. Storing mode 7.1. Storing mode
[I-D.ietf-roll-routing-dispatch] shows that the hop-by-hop IP-in-IP [I-D.ietf-roll-routing-dispatch] shows that the hop-by-hop IP-in-IP
header can be compressed using IP-in-IP 6LoRH (IP-in-IP-6LoRH) header header can be compressed using IP-in-IP 6LoRH (IP-in-IP-6LoRH) header
as described in Section 7 of the document. as described in Section 7 of the document.
There are potential significant advantages to having a single code There are potential significant advantages to having a single code
path that always processes IP-in-IP headers with no options. path that always processes IP-in-IP headers with no options.
Thanks to the relaxation of the RFC2406 rule about discarding unknown Thanks to the relaxation of the RFC2460 rule about discarding unknown
Hop-by-Hop options, there is no longer any uncertainty about when to Hop-by-Hop options, there is no longer any uncertainty about when to
use an IPIP header in the storing mode case. The RPI header SHOULD use an IPIP header in the storing mode case. The RPI header SHOULD
always be added when 6LRs originate packets (without IPIP headers), always be added when 6LRs originate packets (without IPIP headers),
and IPIP headers should always be added (addressed to the root when and IPIP headers should always be added (addressed to the root when
on the way up, to the end-host when on the way down) when a 6LR finds on the way up, to the end-host when on the way down) when a 6LR finds
it needs to insert an RPI header. it needs to insert an RPI header.
In order to support the above two cases with full generality, the In order to support the above two cases with full generality, the
different situations (always do IP-in-IP vs never use IP-in-IP) different situations (always do IP-in-IP vs never use IP-in-IP)
should be signaled in the RPL protocol itself. should be signaled in the RPL protocol itself.
skipping to change at page 32, line 17 skipping to change at page 32, line 17
In the non-storing case, dealing with non-RPL aware leaf nodes is In the non-storing case, dealing with non-RPL aware leaf nodes is
much easier as the 6LBR (DODAG root) has complete knowledge about the much easier as the 6LBR (DODAG root) has complete knowledge about the
connectivity of all DODAG nodes, and all traffic flows through the connectivity of all DODAG nodes, and all traffic flows through the
root node. root node.
The 6LBR can recognize non-RPL aware leaf nodes because it will The 6LBR can recognize non-RPL aware leaf nodes because it will
receive a DAO about that node from the 6LN immediately above that receive a DAO about that node from the 6LN immediately above that
node. This means that the non-storing mode case can avoid ever using node. This means that the non-storing mode case can avoid ever using
hop-by-hop IP-in-IP headers. hop-by-hop IP-in-IP headers.
[I-D.ietf-roll-routing-dispatch] shows how the destination=root, and
destination=6LN IP-in-IP header can be compressed down to {TBD}
bytes.
Unlike in the storing mode case, there is no need for all nodes to Unlike in the storing mode case, there is no need for all nodes to
know about the existence of non-RPL aware nodes. Only the 6LBR needs know about the existence of non-RPL aware nodes. Only the 6LBR needs
to change when there are non-RPL aware nodes. Further, in the non- to change when there are non-RPL aware nodes. Further, in the non-
storing case, the 6LBR is informed by the DAOs when there are non-RPL storing case, the 6LBR is informed by the DAOs when there are non-RPL
aware nodes. aware nodes.
8. 6LoRH Compression cases 8. 6LoRH Compression cases
The [I-D.ietf-roll-routing-dispatch] proposes a compression method The [I-D.ietf-roll-routing-dispatch] proposes a compression method
for RPI, RH3 and IPv6-in-IPv6. for RPI, RH3 and IPv6-in-IPv6.
skipping to change at page 35, line 31 skipping to change at page 35, line 23
[RFC7416] deals with many other threats to LLNs not directly related [RFC7416] deals with many other threats to LLNs not directly related
to the use of IPIP headers, and this document does not change that to the use of IPIP headers, and this document does not change that
analysis. analysis.
11. Acknowledgments 11. Acknowledgments
This work is partially funded by the FP7 Marie Curie Initial Training This work is partially funded by the FP7 Marie Curie Initial Training
Network (ITN) METRICS project (grant agreement No. 607728). Network (ITN) METRICS project (grant agreement No. 607728).
The authors would like to acknowledge the review, feedback, and The authors would like to acknowledge the review, feedback, and
comments of Robert Cragie, Simon Duquennoy, Cenk Guendogan, Peter van comments of (alphabetical order): Robert Cragie, Simon Duquennoy,
der Stok, Xavier Vilajosana and Thomas Watteyne. Cenk Guendogan, Rahul Jadhav, Peter van der Stok, Xavier Vilajosana
and Thomas Watteyne.
12. References 12. References
12.1. Normative References 12.1. Normative References
[I-D.ietf-6man-rfc2460bis] [I-D.ietf-6man-rfc2460bis]
Deering, S. and R. Hinden, "Internet Protocol, Version 6 Deering, S. and R. Hinden, "Internet Protocol, Version 6
(IPv6) Specification", draft-ietf-6man-rfc2460bis-08 (work (IPv6) Specification", draft-ietf-6man-rfc2460bis-08 (work
in progress), November 2016. in progress), November 2016.
skipping to change at page 37, line 32 skipping to change at page 37, line 26
Behringer, M., Eckert, T., and S. Bjarnason, "An Autonomic Behringer, M., Eckert, T., and S. Bjarnason, "An Autonomic
Control Plane", draft-ietf-anima-autonomic-control- Control Plane", draft-ietf-anima-autonomic-control-
plane-05 (work in progress), January 2017. plane-05 (work in progress), January 2017.
[I-D.ietf-anima-bootstrapping-keyinfra] [I-D.ietf-anima-bootstrapping-keyinfra]
Pritikin, M., Richardson, M., Behringer, M., Bjarnason, Pritikin, M., Richardson, M., Behringer, M., Bjarnason,
S., and K. Watsen, "Bootstrapping Remote Secure Key S., and K. Watsen, "Bootstrapping Remote Secure Key
Infrastructures (BRSKI)", draft-ietf-anima-bootstrapping- Infrastructures (BRSKI)", draft-ietf-anima-bootstrapping-
keyinfra-04 (work in progress), October 2016. keyinfra-04 (work in progress), October 2016.
[I-D.ietf-roll-dao-projection]
Thubert, P. and J. Pylakutty, "Root initiated routing
state in RPL", draft-ietf-roll-dao-projection-01 (work in
progress), March 2017.
[I-D.ietf-roll-routing-dispatch] [I-D.ietf-roll-routing-dispatch]
Thubert, P., Bormann, C., Toutain, L., and R. Cragie, Thubert, P., Bormann, C., Toutain, L., and R. Cragie,
"6LoWPAN Routing Header", draft-ietf-roll-routing- "6LoWPAN Routing Header", draft-ietf-roll-routing-
dispatch-05 (work in progress), October 2016. dispatch-05 (work in progress), October 2016.
[RFC4443] Conta, A., Deering, S., and M. Gupta, Ed., "Internet [RFC4443] Conta, A., Deering, S., and M. Gupta, Ed., "Internet
Control Message Protocol (ICMPv6) for the Internet Control Message Protocol (ICMPv6) for the Internet
Protocol Version 6 (IPv6) Specification", RFC 4443, Protocol Version 6 (IPv6) Specification", RFC 4443,
DOI 10.17487/RFC4443, March 2006, DOI 10.17487/RFC4443, March 2006,
<http://www.rfc-editor.org/info/rfc4443>. <http://www.rfc-editor.org/info/rfc4443>.
 End of changes. 16 change blocks. 
18 lines changed or deleted 30 lines changed or added

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