< draft-bonica-6man-comp-rtg-hdr-03.txt   draft-bonica-6man-comp-rtg-hdr-04.txt >
6man R. Bonica 6man R. Bonica
Internet-Draft Juniper Networks Internet-Draft Juniper Networks
Intended status: Standards Track N. So Intended status: Standards Track Y. Kamite
Expires: September 24, 2019 F. Xu Expires: November 7, 2019 NTT Communications Corporation
T. Niwa
KDDI
A. Alston
D. Henriques
Liquid Telecom
N. So
F. Xu
Reliance Jio Reliance Jio
G. Chen G. Chen
Baidu Baidu
Y. Zhu Y. Zhu
G. Yang G. Yang
China Telecom China Telecom
Y. Zhou Y. Zhou
ByteDance ByteDance
March 23, 2019 May 6, 2019
The IPv6 Compressed Routing Header (CRH) The IPv6 Compressed Routing Header (CRH)
draft-bonica-6man-comp-rtg-hdr-03 draft-bonica-6man-comp-rtg-hdr-04
Abstract Abstract
This document defines the Compressed Routing Header (CRH). The CRH, This document defines the Compressed Routing Header (CRH). The CRH,
like any other Routing header, contains a list of segment identifiers like any other Routing header, contains a list of segment identifiers
(SID). The CRH differs from other Routing headers in that its (SID). The CRH differs from other Routing headers in that its
segment identifiers can be 8, 16 or 32 bits long. segment identifiers can be 8, 16 or 32 bits long.
Status of This Memo Status of This Memo
skipping to change at page 1, line 42 skipping to change at page 1, line 49
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 https://datatracker.ietf.org/drafts/current/. Drafts is at https://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 24, 2019. This Internet-Draft will expire on November 7, 2019.
Copyright Notice Copyright Notice
Copyright (c) 2019 IETF Trust and the persons identified as the Copyright (c) 2019 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
(https://trustee.ietf.org/license-info) in effect on the date of (https://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 20 skipping to change at page 2, line 25
to this document. Code Components extracted from this document must to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License. described in the Simplified BSD License.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Requirements Language . . . . . . . . . . . . . . . . . . . . 4 2. Requirements Language . . . . . . . . . . . . . . . . . . . . 4
3. The Compressed Routing Header (CRH) . . . . . . . . . . . . . 4 3. The Compressed Routing Header (CRH) . . . . . . . . . . . . . 4
4. Segment Identifiers (SID) . . . . . . . . . . . . . . . . . . 6 4. The CRH Domain . . . . . . . . . . . . . . . . . . . . . . . 6
5. Processing Rules . . . . . . . . . . . . . . . . . . . . . . 7 5. Segment Identifiers (SID) . . . . . . . . . . . . . . . . . . 6
5.1. General . . . . . . . . . . . . . . . . . . . . . . . . . 7 6. Processing Rules . . . . . . . . . . . . . . . . . . . . . . 7
5.2. CRH Specific . . . . . . . . . . . . . . . . . . . . . . 7 6.1. General . . . . . . . . . . . . . . . . . . . . . . . . . 7
5.2.1. Computing Minimum CRH Length . . . . . . . . . . . . 9 6.2. CRH Specific . . . . . . . . . . . . . . . . . . . . . . 8
6. Mutability . . . . . . . . . . . . . . . . . . . . . . . . . 9 6.2.1. Computing Minimum CRH Length . . . . . . . . . . . . 9
7. Management Considerationsinclude . . . . . . . . . . . . . . 10 7. Mutability . . . . . . . . . . . . . . . . . . . . . . . . . 10
8. Security Considerations . . . . . . . . . . . . . . . . . . . 10 8. Management Considerations . . . . . . . . . . . . . . . . . . 10
9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10 9. Security Considerations . . . . . . . . . . . . . . . . . . . 10
10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 10 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11
11. References . . . . . . . . . . . . . . . . . . . . . . . . . 10 11. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 11
11.1. Normative References . . . . . . . . . . . . . . . . . . 10 12. References . . . . . . . . . . . . . . . . . . . . . . . . . 11
11.2. Informative References . . . . . . . . . . . . . . . . . 11 12.1. Normative References . . . . . . . . . . . . . . . . . . 11
12.2. Informative References . . . . . . . . . . . . . . . . . 12
Appendix A. CRH Processing Examples . . . . . . . . . . . . . . 12 Appendix A. CRH Processing Examples . . . . . . . . . . . . . . 12
A.1. Loose Source Routing . . . . . . . . . . . . . . . . . . 13 A.1. Loose Source Routing . . . . . . . . . . . . . . . . . . 14
A.2. Loose Source Routing Preserving The First SID . . . . . . 14 A.2. Loose Source Routing Preserving The First SID . . . . . . 14
A.3. Strict Source Routing . . . . . . . . . . . . . . . . . . 14 A.3. Strict Source Routing . . . . . . . . . . . . . . . . . . 15
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 15 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 16
1. Introduction 1. Introduction
An IPv6 [RFC8200] source node can steer a packet through a specific An IPv6 [RFC8200] source node can steer a packet through a specific
path to its destination. The source node defines the path as an path to its destination. The source node defines the path as an
ordered list of segments and encodes the path in an IPv6 Routing ordered list of segments and encodes the path in an IPv6 Routing
header. As per [RFC8200], all Routing headers includes the following header. As per [RFC8200], all Routing headers includes the following
fields: fields:
o Next Header - Identifies the header immediately following the o Next Header - Identifies the header immediately following the
skipping to change at page 4, line 36 skipping to change at page 4, line 41
Figure 1: Compressed Routing Header (CRH) Figure 1: Compressed Routing Header (CRH)
The CRH contains the following fields: The CRH contains the following fields:
o Next Header - Defined in [RFC8200]. o Next Header - Defined in [RFC8200].
o Hdr Ext Len - Defined in [RFC8200]. o Hdr Ext Len - Defined in [RFC8200].
o Routing Type - Defined in [RFC8200]. Value TBD by IANA. o Routing Type - Defined in [RFC8200]. Value TBD by IANA.
(Suggested value: 5)
o Segments Left (SL) - Defined in [RFC8200]. o Segments Left (SL) - Defined in [RFC8200].
o Last Entry - 8 bits. Represents the index (zero based), in the o Last Entry - 8 bits. Represents the index (zero based), in the
Segment List, of the last element of the Segment List.. Segment List, of the last element of the Segment List..
o Com (Compression) - 2 bits. Represents the length of each entry o Com (Compression) - 2 bits. Represents the length of each entry
in the SID List. Values are eight bits (0), sixteen bits (1), in the SID List. Values are eight bits (0), sixteen bits (1),
thirty-two bits (2), and reserved (3). thirty-two bits (2), and reserved (3).
o Reserved - SHOULD be set to zero by the sender. MUST be ignored o Reserved - SHOULD be set to zero by the sender. MUST be ignored
by the receiver. by the receiver.
o SID List - An zero-indexed list of SIDs. SIDs are listed in o SID List - A zero-indexed list of SIDs. SIDs are listed in
reverse order, with SID[0] representing the packet's ultimate reverse order, with SID[0] representing the packet's ultimate
destination, SID[1] representing the previous segment endpoint and destination, SID[1] representing the segment endpoint prior to the
so forth. See Section 4 for SID details. ultimate destination, and so forth. SIDs are listed in reverse
order so that Segments Left can be used as an index to the SID
List. See Section 5 for SID details.
Figure 2 through Figure 4 illustrate CRH encodings with Com equal to Figure 2 through Figure 4 illustrate CRH encodings with Com equal to
0, 1 and 2. In all cases, the CRH MUST end on a 64-bit boundary. 0, 1 and 2. In all cases, the CRH MUST end on a 64-bit boundary.
Therefore, the CRH MAY be padded with zeros. Therefore, the CRH MAY be padded with zeros.
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 | Segments Left | | Next Header | Hdr Ext Len | Routing Type | Segments Left |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
skipping to change at page 6, line 23 skipping to change at page 6, line 23
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ SID[1] + + SID[1] +
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
// // // //
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ SID[n] + + SID[n] +
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 4: Thirty-two bit Encoding (Com equals 2) Figure 4: Thirty-two bit Encoding (Com equals 2)
4. Segment Identifiers (SID) 4. The CRH Domain
A CRH domain is a collection of IPv6 devices. On the control plane,
CRH domain members exchange SID information with one another. On the
forwarding plane, CRH domain members accept packets containing the
CRH from one another.
Section 9 of this document requires the CRH domain to be contained
within an operator's trust domain.
5. Segment Identifiers (SID)
This document defines the following SID types: This document defines the following SID types:
o Loosely routed o Loosely routed
o Strictly routed o Strictly routed
All SIDs, regardless of type, map to exactly one IPv6 address. The All SIDs, regardless of type, map to exactly one IPv6 address. The
mapped address identifies an interface or set of interfaces (in the mapped address identifies an interface or set of interfaces (in the
case of multicast) that terminate the segment. The address MUST be case of multicast) that terminate the segment. The address MUST be
skipping to change at page 6, line 46 skipping to change at page 7, line 9
o A globally scoped IPv6 unicast address [RFC4291]. o A globally scoped IPv6 unicast address [RFC4291].
o A Unique Local IPv6 Unicast Address (ULA) [RFC4193]. o A Unique Local IPv6 Unicast Address (ULA) [RFC4193].
o A Multicast address [RFC4291]. o A Multicast address [RFC4291].
A strictly routed SID also maps to a link interface. Nodes send A strictly routed SID also maps to a link interface. Nodes send
packets through that interface in order to access the segment packets through that interface in order to access the segment
endpoint. endpoint.
SIDs are instantiated on nodes and their significance is limited to Loosely routed SIDs have domain-wide significance. This means that
the node upon which they are instantiated. For example, assume that within a CRH domain, a loosely routed SID MUST map to exactly one
a SID is instantiated on multiple nodes. It can be loosely routed on IPv6 address. By contrast, strictly routed SIDs have node-local
one node and strictly routed on another. Likewise, it can map to a significance. This means that within a CRH domain, one node can map
different globally scoped address on each node. See Appendix A for a strictly routed SID to one address while another node maps the same
an example. strictly routed SID to a different address. See Appendix A for an
example.
Forwarding nodes can learn the above-mentioned mappings from a Forwarding nodes can learn the above-mentioned mappings from a
central controller, from a distributed routing protocol or using any central controller, from a distributed routing protocol or using any
other means. The mechanisms that forwarding nodes use to learn the other means. The mechanisms that forwarding nodes use to learn the
above-mentioned mappings are beyond the scope of this document. above-mentioned mappings are beyond the scope of this document.
5. Processing Rules 6. Processing Rules
5.1. General 6.1. General
[RFC8200] defines rules that apply to IPv6 extension headers, in [RFC8200] defines rules that apply to IPv6 extension headers, in
general, and IPv6 Routing headers, in particular. All of these rules general, and IPv6 Routing headers, in particular. All of these rules
apply to the CRH. apply to the CRH.
For example: For example:
o Extension headers (except for the Hop-by-Hop Options header) are o Extension headers (except for the Hop-by-Hop Options header) are
not processed, inserted, or deleted by any node along a packet's not processed, inserted, or deleted by any node along a packet's
delivery path, until the packet reaches the node (or each of the delivery path, until the packet reaches the node (or each of the
skipping to change at page 7, line 43 skipping to change at page 8, line 7
discard the packet and send an ICMP [RFC4443] Parameter Problem, discard the packet and send an ICMP [RFC4443] Parameter Problem,
Code 0, message to the packet's Source Address, pointing to the Code 0, message to the packet's Source Address, pointing to the
unrecognized Routing Type. unrecognized Routing Type.
o If, after processing a Routing header of a received packet, an o If, after processing a Routing header of a received packet, an
intermediate node determines that the packet is to be forwarded intermediate node determines that the packet is to be forwarded
onto a link whose link MTU is less than the size of the packet, onto a link whose link MTU is less than the size of the packet,
the node must discard the packet and send an ICMP Packet Too Big the node must discard the packet and send an ICMP Packet Too Big
message to the packet's Source Address. message to the packet's Source Address.
5.2. CRH Specific 6.2. CRH Specific
When a node recognizes and processes a CRH, it executes the following When a node recognizes and processes a CRH, it executes the following
procedure: procedure:
o If the IPv6 Source Address is a link-local address, discard the o If the IPv6 Source Address is a link-local address, discard the
packet. packet.
o If the IPv6 Source Address is a multicast address, discard the o If the IPv6 Source Address is a multicast address, discard the
packet. packet.
skipping to change at page 8, line 20 skipping to change at page 8, line 33
to the Segments Left field, and discard the packet. to the Segments Left field, and discard the packet.
o If Com is equal to (3) Reserved, send an ICMP Parameter Problem, o If Com is equal to (3) Reserved, send an ICMP Parameter Problem,
Code 0, message to the Source Address, pointing to the Com field, Code 0, message to the Source Address, pointing to the Com field,
and discard the packet. and discard the packet.
o If the IPv6 Hop Limit is less than or equal to 1, send an ICMP o 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 Time Exceeded -- Hop Limit Exceeded in Transit message to the
Source Address and discard the packet. Source Address and discard the packet.
o Compute L, the minimum CRH length (See Section 5.2.1) o Compute L, the minimum CRH length (See Section 6.2.1)
o If L is greater than Hdr Ext Len, send an ICMP Parameter Problem, o If L is greater than Hdr Ext Len, send an ICMP Parameter Problem,
Code 0, message to the Source Address, pointing to the Last Entry Code 0, message to the Source Address, pointing to the Last Entry
field, and discard the packet. field, and discard the packet.
o Decrement Segments Left (i.e., SL). o Decrement Segments Left (i.e., SL).
o Search for SID[SL] in the table that maps SID's to IPv6 addresses o Search for SID[SL] in the table that maps SID's to IPv6 addresses
and interfaces. If SID[SL] cannot be found in that table, send an and interfaces. If SID[SL] cannot be found in that table, send an
ICMP Parameter Problem, Code 0, message to the Source Address, ICMP Parameter Problem, Code 0, message to the Source Address,
skipping to change at page 9, line 5 skipping to change at page 9, line 17
o Decrement the IPv6 Hop Limit. o Decrement the IPv6 Hop Limit.
o If SID[SL] is a loosely routed segment, resubmit the packet to the o If SID[SL] is a loosely routed segment, resubmit the packet to the
IPv6 module for transmission to the new destination. IPv6 module for transmission to the new destination.
o If SID[SL] is a strictly routed segment, forward the packet o If SID[SL] is a strictly routed segment, forward the packet
through the interface that is associated with SID[SL]. through the interface that is associated with SID[SL].
The above stated rules are demonstrated in Appendix A. The above stated rules are demonstrated in Appendix A.
5.2.1. Computing Minimum CRH Length 6.2.1. Computing Minimum CRH Length
The algorithm described in this section accepts the following CRH The algorithm described in this section accepts the following CRH
fields as its input parameters: fields as its input parameters:
o Compression (Com). o Compression (Com).
o Last Entry. o Last Entry.
It yields L, the minimum CRH length. The minimum CRH length is It yields L, the minimum CRH length. The minimum CRH length is
measured in 8-octet units, not including the first 8 octets. measured in 8-octet units, not including the first 8 octets.
skipping to change at page 9, line 43 skipping to change at page 10, line 31
} }
else { /* Invalid Com */ else { /* Invalid Com */
L = 0xFF L = 0xFF
} }
return(L) return(L)
<CODE ENDS> <CODE ENDS>
6. Mutability 7. Mutability
The Segments Left field is mutable and MAY be decremented by The Segments Left field is mutable and MAY be decremented by
processing nodes. All remaining fields are immutable. processing nodes. All remaining fields are immutable.
7. Management Considerationsinclude 8. Management Considerations
PING and TRACEROUTE [RFC2151] both operate correctly in the presence PING and TRACEROUTE [RFC2151] both operate correctly in the presence
of the CRH. of the CRH.
8. Security Considerations 9. Security Considerations
The CRH can be used within trusted domains only. In order to enforce The CRH can be used within trusted domains only. In order to enforce
this requirement, domain edge routers MUST do one of the following: this requirement, domain edge routers MUST do one of the following:
o Discard all inbound packets that contain a CRH o Discard all inbound packets that contain a CRH
o Authenticate [RFC4302] [RFC4303] all inbound packets that contain o Authenticate [RFC4302] [RFC4303] all inbound packets that contain
a CRH a CRH
9. IANA Considerations 10. IANA Considerations
This document makes the following registration in the Internet This document makes the following registration in the Internet
Protocol Version 6 (IPv6) Parameters "Routing Type" registry Protocol Version 6 (IPv6) Parameters "Routing Type" registry
maintained by IANA: maintained by IANA:
Suggested
Value Description Reference Value Description Reference
------------------------------------------------------------ ------------------------------------------------------------
TBD Compressed Routing Header (CRH) This document 5 Compressed Routing Header (CRH) This document
10. Acknowledgements 11. Acknowledgements
Thanks to Joel Halpern, Gerald Schmidt, Nancy Shaw and Chandra Thanks to Joel Halpern, Tony Li, Gerald Schmidt, Nancy Shaw and
Venkatraman for their comments. Chandra Venkatraman for their comments.
11. References 12. References
11.1. Normative References 12.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997, DOI 10.17487/RFC2119, March 1997,
<https://www.rfc-editor.org/info/rfc2119>. <https://www.rfc-editor.org/info/rfc2119>.
[RFC4291] Hinden, R. and S. Deering, "IP Version 6 Addressing [RFC4291] Hinden, R. and S. Deering, "IP Version 6 Addressing
Architecture", RFC 4291, DOI 10.17487/RFC4291, February Architecture", RFC 4291, DOI 10.17487/RFC4291, February
2006, <https://www.rfc-editor.org/info/rfc4291>. 2006, <https://www.rfc-editor.org/info/rfc4291>.
skipping to change at page 11, line 29 skipping to change at page 12, line 15
[RFC8200] Deering, S. and R. Hinden, "Internet Protocol, Version 6 [RFC8200] Deering, S. and R. Hinden, "Internet Protocol, Version 6
(IPv6) Specification", STD 86, RFC 8200, (IPv6) Specification", STD 86, RFC 8200,
DOI 10.17487/RFC8200, July 2017, DOI 10.17487/RFC8200, July 2017,
<https://www.rfc-editor.org/info/rfc8200>. <https://www.rfc-editor.org/info/rfc8200>.
[RFC8201] McCann, J., Deering, S., Mogul, J., and R. Hinden, Ed., [RFC8201] McCann, J., Deering, S., Mogul, J., and R. Hinden, Ed.,
"Path MTU Discovery for IP version 6", STD 87, RFC 8201, "Path MTU Discovery for IP version 6", STD 87, RFC 8201,
DOI 10.17487/RFC8201, July 2017, DOI 10.17487/RFC8201, July 2017,
<https://www.rfc-editor.org/info/rfc8201>. <https://www.rfc-editor.org/info/rfc8201>.
11.2. Informative References 12.2. Informative References
[I-D.ietf-6man-segment-routing-header] [I-D.ietf-6man-segment-routing-header]
Filsfils, C., Previdi, S., Leddy, J., Matsushima, S., and Filsfils, C., Previdi, S., Leddy, J., Matsushima, S., and
d. daniel.voyer@bell.ca, "IPv6 Segment Routing Header d. daniel.voyer@bell.ca, "IPv6 Segment Routing Header
(SRH)", draft-ietf-6man-segment-routing-header-16 (work in (SRH)", draft-ietf-6man-segment-routing-header-18 (work in
progress), February 2019. progress), April 2019.
[RFC2151] Kessler, G. and S. Shepard, "A Primer On Internet and TCP/ [RFC2151] Kessler, G. and S. Shepard, "A Primer On Internet and TCP/
IP Tools and Utilities", FYI 30, RFC 2151, IP Tools and Utilities", FYI 30, RFC 2151,
DOI 10.17487/RFC2151, June 1997, DOI 10.17487/RFC2151, June 1997,
<https://www.rfc-editor.org/info/rfc2151>. <https://www.rfc-editor.org/info/rfc2151>.
[RFC4193] Hinden, R. and B. Haberman, "Unique Local IPv6 Unicast [RFC4193] Hinden, R. and B. Haberman, "Unique Local IPv6 Unicast
Addresses", RFC 4193, DOI 10.17487/RFC4193, October 2005, Addresses", RFC 4193, DOI 10.17487/RFC4193, October 2005,
<https://www.rfc-editor.org/info/rfc4193>. <https://www.rfc-editor.org/info/rfc4193>.
skipping to change at page 15, line 32 skipping to change at page 16, line 23
Authors' Addresses Authors' Addresses
Ron Bonica Ron Bonica
Juniper Networks Juniper Networks
2251 Corporate Park Drive 2251 Corporate Park Drive
Herndon, Virginia 20171 Herndon, Virginia 20171
USA USA
Email: rbonica@juniper.net Email: rbonica@juniper.net
Yuji Kamite
NTT Communications Corporation
3-4-1 Shibaura, Minato-ku
Tokyo 108-8118
Japan
Email: : y.kamite@ntt.com
Tomonobu Niwa
KDDI
3-22-7, Yoyogi, Shibuya-ku
Tokyo 151-0053
Japan
Email: to-niwa@kddi.com
Andrew Alston
Liquid Telecom
Nairobi
Kenya
Email: Andrew.Alston@liquidtelecom.com
Daniam Henriques
Liquid Telecom
Johannesburg
South Africa
Email: daniam.henriques@liquidtelecom.com
Ning So Ning So
Reliance Jio Reliance Jio
3010 Gaylord PKWY, Suite 150 3010 Gaylord PKWY, Suite 150
Frisco, Texas 75034 Frisco, Texas 75034
USA USA
Email: Ning.So@ril.com Email: Ning.So@ril.com
Fengman Xu Fengman Xu
Reliance Jio Reliance Jio
 End of changes. 30 change blocks. 
49 lines changed or deleted 101 lines changed or added

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