< draft-xie-bier-ipv6-encapsulation-05.txt   draft-xie-bier-ipv6-encapsulation-06.txt >
Network Working Group J. Xie Network Working Group J. Xie
Internet-Draft Huawei Technologies Internet-Draft Huawei Technologies
Intended status: Standards Track L. Geng Intended status: Standards Track L. Geng
Expires: July 17, 2020 China Mobile Expires: September 10, 2020 China Mobile
M. McBride M. McBride
Futurewei Futurewei
R. Asati R. Asati
Cisco Cisco
S. Dhanaraj S. Dhanaraj
Huawei Huawei
January 14, 2020 March 9, 2020
Encapsulation for BIER in Non-MPLS IPv6 Networks Encapsulation for BIER in Non-MPLS IPv6 Networks
draft-xie-bier-ipv6-encapsulation-05 draft-xie-bier-ipv6-encapsulation-06
Abstract Abstract
This document proposes a BIER IPv6 (BIERv6) encapsulation for Non- This document proposes a BIER IPv6 (BIERv6) encapsulation for Non-
MPLS IPv6 Networks using the IPv6 Destination Option extension MPLS IPv6 Networks using the IPv6 Destination Option extension
header. This document updates [RFC8296]. header. This document updates [RFC8296].
Requirements Language Requirements Language
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
skipping to change at page 1, line 46 skipping to change at page 1, line 46
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 July 17, 2020. This Internet-Draft will expire on September 10, 2020.
Copyright Notice Copyright Notice
Copyright (c) 2020 IETF Trust and the persons identified as the Copyright (c) 2020 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 29 skipping to change at page 2, line 29
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3
3. BIER IPv6 Encapsulation . . . . . . . . . . . . . . . . . . . 3 3. BIER IPv6 Encapsulation . . . . . . . . . . . . . . . . . . . 3
3.1. BIER Option in IPv6 Destination Options Header . . . . . 3 3.1. BIER Option in IPv6 Destination Options Header . . . . . 3
3.2. Multicast and Unicast Destination Address . . . . . . . . 6 3.2. Multicast and Unicast Destination Address . . . . . . . . 6
3.3. BIERv6 Packet Format . . . . . . . . . . . . . . . . . . 8 3.3. BIERv6 Packet Format . . . . . . . . . . . . . . . . . . 8
4. BIERv6 Packet Processing . . . . . . . . . . . . . . . . . . 9 4. BIERv6 Packet Processing . . . . . . . . . . . . . . . . . . 9
5. Security Considerations . . . . . . . . . . . . . . . . . . . 11 5. Security Considerations . . . . . . . . . . . . . . . . . . . 10
5.1. Intra Domain Deployment . . . . . . . . . . . . . . . . . 12 5.1. Intra Domain Deployment . . . . . . . . . . . . . . . . . 11
5.2. Inter Domain Deployment . . . . . . . . . . . . . . . . . 13 5.2. ICMP Error Processing . . . . . . . . . . . . . . . . . . 12
5.3. ICMP Error Processing . . . . . . . . . . . . . . . . . . 13 5.3. Security caused by BIER option . . . . . . . . . . . . . 13
5.4. Security caused by BIER option . . . . . . . . . . . . . 14 5.4. Applicability of IPsec . . . . . . . . . . . . . . . . . 13
5.5. Applicability of IPsec . . . . . . . . . . . . . . . . . 14 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 14
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 15 6.1. BIER Option Type . . . . . . . . . . . . . . . . . . . . 14
6.1. BIER Option Type . . . . . . . . . . . . . . . . . . . . 15
6.2. End.BIER Function . . . . . . . . . . . . . . . . . . . . 15 6.2. End.BIER Function . . . . . . . . . . . . . . . . . . . . 15
6.3. BIER Next Protocol Identifiers . . . . . . . . . . . . . 16 6.3. BIER Next Protocol Identifiers . . . . . . . . . . . . . 15
7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 16 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 15
8. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 16 8. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 15
9. References . . . . . . . . . . . . . . . . . . . . . . . . . 17 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 16
9.1. Normative References . . . . . . . . . . . . . . . . . . 17 9.1. Normative References . . . . . . . . . . . . . . . . . . 16
9.2. Informative References . . . . . . . . . . . . . . . . . 18 9.2. Informative References . . . . . . . . . . . . . . . . . 17
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 18 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 17
1. Introduction 1. Introduction
Bit Index Explicit Replication (BIER) [RFC8279] is an architecture Bit Index Explicit Replication (BIER) [RFC8279] is an architecture
that provides optimal multicast forwarding without requiring that provides optimal multicast forwarding without requiring
intermediate routers to maintain any per-flow state by using a intermediate routers to maintain any per-flow state by using a
multicast-specific BIER header. multicast-specific BIER header.
[RFC8296] defines a common BIER Header format for MPLS and Non-MPLS [RFC8296] defines a common BIER Header format for MPLS and Non-MPLS
networks. It has defined two types of encapsulation methods using networks. It has defined two types of encapsulation methods using
skipping to change at page 5, line 47 skipping to change at page 5, line 47
second is to deliver the packet to a proper overlay module by second is to deliver the packet to a proper overlay module by
BIER layer, with VRF lookup in case of BIER data process, or BIER layer, with VRF lookup in case of BIER data process, or
without VRF lookup in case of BIER OAM process. In BIER IPv6 without VRF lookup in case of BIER OAM process. In BIER IPv6
encapsulation, the first function of Proto is compromised by a encapsulation, the first function of Proto is compromised by a
proper Next Header value combination, and the second function of proper Next Header value combination, and the second function of
Proto should be kept with the semantic unique and consistent for Proto should be kept with the semantic unique and consistent for
BIER demultiplexing. This updates section 2.1.2 of [RFC8296] BIER demultiplexing. This updates section 2.1.2 of [RFC8296]
about Proto defination. This document support the following about Proto defination. This document support the following
combination of BIER Proto and Next Header: combination of BIER Proto and Next Header:
Use Next Header value 4, 41 and TBD0 for IPv4 packet, IPv6 Use Next Header value 4, 41 and 143 for IPv4 packet, IPv6
packet and Ethernet packet respectively, and use Proto value packet and Ethernet packet respectively, and use Proto value
TBD1 indicating "Delivering the data packet with VRF lookup TBD1 indicating "Delivering the data packet with VRF lookup
in IPv6 source address". in IPv6 source address".
Use Next Header value 59 for private packet format, and use Use Next Header value 59 for private packet format, and use
Proto value 5 indicating "Delivering the BIER OAM packet Proto value 5 indicating "Delivering the BIER OAM packet
without VRF lookup". The BIER-PING [I-D.ietf-bier-ping] without VRF lookup". The BIER-PING [I-D.ietf-bier-ping]
works equally in BIER IPv6 encapsulation as well as in BIER works equally in BIER IPv6 encapsulation as well as in BIER
MPLS or BIER Ethernet encapsulation. MPLS or BIER Ethernet encapsulation.
Allocation of Next Header value TBD0 for Ethernet packet is
applying in [I-D.ietf-spring-srv6-network-programming] and
will not be listed in the IANA considerations section of this
document.
Allocation of BIER Proto value TBD1 is listed in the IANA Allocation of BIER Proto value TBD1 is listed in the IANA
considerations section of this document. considerations section of this document.
BFIR-id: See Section 2.1.2 of RFC 8296. BFIR-id: See Section 2.1.2 of RFC 8296.
BitString: See Section 2.1.2 of RFC 8296. BitString: See Section 2.1.2 of RFC 8296.
3.2. Multicast and Unicast Destination Address 3.2. Multicast and Unicast Destination Address
BIER is generally a hop-by-hop and one-to-many architecture, and thus BIER is generally a hop-by-hop and one-to-many architecture, and thus
skipping to change at page 11, line 15 skipping to change at page 10, line 49
The Fragment Header, AH Header or ESP Header, if exists after the The Fragment Header, AH Header or ESP Header, if exists after the
BIER options header, can be processed on BFER only as part of the BIER options header, can be processed on BFER only as part of the
multicast flow overlay process. multicast flow overlay process.
5. Security Considerations 5. Security Considerations
BIER IPv6 encapsulation provides a new encapsulation based on IPv6 BIER IPv6 encapsulation provides a new encapsulation based on IPv6
and BIER to transport multicast data packet in a BIER domain. The and BIER to transport multicast data packet in a BIER domain. The
BIER domain can be a single IGP area, an anonymous system (AS) with BIER domain can be a single IGP area, an anonymous system (AS) with
multiple IGP areas, or multiple anonymous systems (ASes) operated by multiple IGP areas, or multiple anonymous systems (ASes) operated by
a network operator. This section reviews security considerations a network operator. A single BIER Sub-domain may be deployed through
related to the BIER IPv6 encapsulation, based on security the whole BIER Domain, as illustrated in
considerations of [RFC8279], [RFC8296], and other documents related [I-D.geng-bier-ipv6-inter-domain].
to IPv6 extension.
BIER-encapsulated packets should generally not be accepted from This section reviews security considerations related to the BIER IPv6
untrusted interfaces or tunnels. For example, an operator may wish encapsulation, based on security considerations of [RFC8279],
to have a policy of accepting BIER-encapsulated packets only from [RFC8296], and other documents related to IPv6 extension.
interfaces to trusted routers, and not from customer-facing
interfaces. See section 5.1 for normal Intra domain deployment.
There may be applications that require a BFR to accept a BIER- It is expected that all nodes in a BIER IPv6 domain are managed by
encapsulated packet from an interface to a system that is not the same administrative entity. BIER-encapsulated packets should
controlled by the network operator. See section 5.2 for inter domain generally not be accepted from untrusted interfaces or tunnels. For
deployment. example, an operator may wish to have a policy of accepting BIER-
encapsulated packets only from interfaces to trusted routers, and not
from customer-facing interfaces. See section 5.1 for normal Intra
domain deployment.
For applications that require a BFR to accept a BIER-encapsulated
packet from an interface to a system that is not controlled by the
network operator, the security considerations of [RFC8296] apply.
BIER IPv6 encapsulation may cause ICMP packet sent to BFIR and cause BIER IPv6 encapsulation may cause ICMP packet sent to BFIR and cause
security problems. See section 5.3 for ICMP related problems. security problems. See section 5.2 for ICMP related problems.
This document introduces a new option used in IPv6 Destination This document introduces a new option used in IPv6 Destination
Options Header, together with the special-use IPv6 address called Options Header, together with the special-use IPv6 address called
End.BIER in IPv6 destination address for BIER IPv6 forwarding. End.BIER in IPv6 destination address for BIER IPv6 forwarding.
However the option newly introduced may be wrongly used with normal However the option newly introduced may be wrongly used with normal
IPv6 destination address. See section 5.4 for problems introduced by IPv6 destination address. See section 5.3 for problems introduced by
the new IPv6 option with normal IPv6 destination address. the new IPv6 option with normal IPv6 destination address.
If a BIER packet is altered, either the BIER header, or the multicast If a BIER packet is altered, either the BIER header, or the multicast
data packet, by an intermediate router, packets may be lost, stolen, data packet, by an intermediate router, packets may be lost, stolen,
or otherwise misdelivered. BIER IPv6 encapsulation provides the or otherwise misdelivered. BIER IPv6 encapsulation provides the
ability of IPsec to ensure the confidentiality or integrity. See ability of IPsec to ensure the confidentiality or integrity. See
section 5.5 for this security problem. section 5.4 for this security problem.
A BIER router accepts and uses the End.BIER IPv6 address to construct A BIER router accepts and uses the End.BIER IPv6 address to construct
BIFT only when the IPv6 address is configured explicitly, or received BIFT only when the IPv6 address is configured explicitly, or received
from a router via control-plane protocols. The received information from a router via control-plane protocols. The received information
is validated using existing authentication and security mechanisms of is validated using existing authentication and security mechanisms of
the control-plane protocols. BIER IPv6 encapsulation does not define the control-plane protocols. BIER IPv6 encapsulation does not define
any additional security mechanism in existing control-plane any additional security mechanism in existing control-plane
protocols, and it inherits any security considerations that apply to protocols, and it inherits any security considerations that apply to
the control-plane protocols. the control-plane protocols.
skipping to change at page 12, line 51 skipping to change at page 12, line 43
* configure each internal interface of each BIER node k in the BIER * configure each internal interface of each BIER node k in the BIER
Domain with an inbound IACL which drops any incoming packet with a Domain with an inbound IACL which drops any incoming packet with a
destination address in Sk/sk if the source address is not in A/a or destination address in Sk/sk if the source address is not in A/a or
B/b. B/b.
For simplicity of deployment, a configuration of IACL effective for For simplicity of deployment, a configuration of IACL effective for
all interfaces can be provided by a router. Such IACL can be all interfaces can be provided by a router. Such IACL can be
referred to as global IACL(GIACL) .Each BIER node k then simply referred to as global IACL(GIACL) .Each BIER node k then simply
configs a GIACL which drops any incoming packet with a destination configs a GIACL which drops any incoming packet with a destination
address in Sk/sk if the source address is not in A/a or B/b for the address in Sk/sk if the source address is not in A/a or B/b for the
inter-domain deployment mode. intra-domain deployment mode.
5.2. Inter Domain Deployment
There may be applications that require a BFR to accept a BIER-
encapsulated packet from an interface to a system that is not
controlled by the network operator. For instance, there may be an
application in which a virtual machine in a data center submits BIER-
encapsulated packets to a router. In such a case, it is desirable to
verify that the packet is from a legitimate source and that its
BitString denotes only systems to which that source is allowed to
send. Using BIER IPv6 encapsulation, IACL can be configured on each
internal interface of each BIER node k to allow packet with a
destination address in Sk/sk and the source address is in an allowed
list of IPv6 address. However, the BIER IPv6 encapsulation itself
does not provide a way to verify that the source is legitimate or the
source is allowed to set any particular set of bits in the BitString.
The IACL allowing specific IPv6 address outside the domain of a
network operator can be more strict by the following method:
* configure one sub-domain using only one bit string length, and a
seperate End.BIER for this sub-domain as a service opened to agreed
source(s) outside the domain of the operator's network.
* configure on BIER node to check if the End.BIER address of a packet
is the correct one bound to the sub-domain of a packet.
* configure IACL on each interface of each BIER node k (or simply
configure GIACL on each BIER node k) to allow packet with an End.BIER
as destination address and the allowed source(s) as source address.
This provides a way to ensure that the inter-domain source is allowed
to access only the BIER IPv6 transport service bound to a sub-domain
with a specific bit string length.
5.3. ICMP Error Processing 5.2. ICMP Error Processing
ICMP error packets generated within the BIER Domain are sent to ICMP error packets generated within the BIER Domain are sent to
source nodes within the BIER Domain. source nodes within the BIER Domain.
A large number of ICMP may be elicited and sent to a BFIR router, in A large number of ICMP may be elicited and sent to a BFIR router, in
case when a BIER IPv6 packet is filled with wrong TTL, either error case when a BIER IPv6 packet is filled with wrong TTL, either error
or malfeasance. A rate-limiting of ICMP packet should be implemented or malfeasance. A rate-limiting of ICMP packet should be implemented
on each BFR. on each BFR.
The ingress node can take note of the fact that it is getting, in The ingress node can take note of the fact that it is getting, in
skipping to change at page 14, line 14 skipping to change at page 13, line 21
positives" that generate a lot of "noise" in the log; therefore, positives" that generate a lot of "noise" in the log; therefore,
implementations SHOULD have a knob to disable this logging. implementations SHOULD have a knob to disable this logging.
OAM functions of PING and TRACE for BIER IPv6 encapsulation may also OAM functions of PING and TRACE for BIER IPv6 encapsulation may also
need ICMP based on BIER IPv6 encapsulation and cause ICMP response need ICMP based on BIER IPv6 encapsulation and cause ICMP response
message containing BIER option. The ability of seperating such OAM message containing BIER option. The ability of seperating such OAM
ICMP packets from error ICMP packets caused by error is necessary for ICMP packets from error ICMP packets caused by error is necessary for
the availability of OAM, otherwise the OAM function may fail due to the availability of OAM, otherwise the OAM function may fail due to
the rate-limiting of ICMP error packets. the rate-limiting of ICMP error packets.
5.4. Security caused by BIER option 5.3. Security caused by BIER option
This document introduces a new option used in IPv6 Destination This document introduces a new option used in IPv6 Destination
Options Header. An IPv6 packet with a normal IPv6 address of a Options Header. An IPv6 packet with a normal IPv6 address of a
router (e.g. loopback IPv6 address of the router) as destination router (e.g. loopback IPv6 address of the router) as destination
address will possibly carry a BIER option. address will possibly carry a BIER option.
For a router incapable of BIERv6, such BIERv6 packet will not be For a router incapable of BIERv6, such BIERv6 packet will not be
processed by the procedure described in this document, but be processed by the procedure described in this document, but be
processed as normal IPv6 packet with unknown option, and the existing processed as normal IPv6 packet with unknown option, and the existing
security considerations for handling IPv6 options apply. Possible security considerations for handling IPv6 options apply. Possible
way of handling IPv6 packets with BIER option may be send to CPU for way of handling IPv6 packets with BIER option may be send to CPU for
slow path processing, with rate-limiting, or be discarded according slow path processing, with rate-limiting, or be discarded according
to the local policy. to the local policy.
For a router capable of BIERv6, such BIERv6 packet MUST NOT be For a router capable of BIERv6, such BIERv6 packet MUST NOT be
forwarded, but should be processed as a normal IPv6 packet with forwarded, but should be processed as a normal IPv6 packet with
unknown option, or additionally and optionally be countered and unknown option, or additionally and optionally be countered and
logged if the router is capable of doing so. logged if the router is capable of doing so.
5.5. Applicability of IPsec 5.4. Applicability of IPsec
IPsec [RFC4301] uses two protocols to provide traffic security IPsec [RFC4301] uses two protocols to provide traffic security
services -- Authentication Header (AH) [RFC4302] and Encapsulating services -- Authentication Header (AH) [RFC4302] and Encapsulating
Security Payload (ESP) [RFC4303]. Each protocol supports two modes Security Payload (ESP) [RFC4303]. Each protocol supports two modes
of use: transport mode and tunnel mode. IPsec support both unicast of use: transport mode and tunnel mode. IPsec support both unicast
and multicast. IPsec implementations MUST support ESP and MAY and multicast. IPsec implementations MUST support ESP and MAY
support AH. support AH.
This document assume IPsec working in tunnel mode with inner IPv4 or This document assume IPsec working in tunnel mode with inner IPv4 or
IPv6 multicast packet encapsulated in outer BIERv6 header and IPsec IPv6 multicast packet encapsulated in outer BIERv6 header and IPsec
skipping to change at page 18, line 12 skipping to change at page 17, line 18
MPLS Networks", RFC 8296, DOI 10.17487/RFC8296, January MPLS Networks", RFC 8296, DOI 10.17487/RFC8296, January
2018, <https://www.rfc-editor.org/info/rfc8296>. 2018, <https://www.rfc-editor.org/info/rfc8296>.
[RFC8556] Rosen, E., Ed., Sivakumar, M., Przygienda, T., Aldrin, S., [RFC8556] Rosen, E., Ed., Sivakumar, M., Przygienda, T., Aldrin, S.,
and A. Dolganow, "Multicast VPN Using Bit Index Explicit and A. Dolganow, "Multicast VPN Using Bit Index Explicit
Replication (BIER)", RFC 8556, DOI 10.17487/RFC8556, April Replication (BIER)", RFC 8556, DOI 10.17487/RFC8556, April
2019, <https://www.rfc-editor.org/info/rfc8556>. 2019, <https://www.rfc-editor.org/info/rfc8556>.
9.2. Informative References 9.2. Informative References
[I-D.geng-bier-ipv6-inter-domain]
Geng, L., Xie, J., McBride, M., and G. Yan, "Inter-Domain
Multicast Deployment using BIERv6", draft-geng-bier-ipv6-
inter-domain-01 (work in progress), January 2020.
[I-D.ietf-bier-ipv6-requirements] [I-D.ietf-bier-ipv6-requirements]
McBride, M., Xie, J., Dhanaraj, S., and R. Asati, "BIER McBride, M., Xie, J., Dhanaraj, S., Asati, R., and Y. Zhu,
IPv6 Requirements", draft-ietf-bier-ipv6-requirements-03 "BIER IPv6 Requirements", draft-ietf-bier-
(work in progress), November 2019. ipv6-requirements-04 (work in progress), January 2020.
[I-D.ietf-bier-ping] [I-D.ietf-bier-ping]
Kumar, N., Pignataro, C., Akiya, N., Zheng, L., Chen, M., Kumar, N., Pignataro, C., Akiya, N., Zheng, L., Chen, M.,
and G. Mirsky, "BIER Ping and Trace", draft-ietf-bier- and G. Mirsky, "BIER Ping and Trace", draft-ietf-bier-
ping-06 (work in progress), October 2019. ping-06 (work in progress), October 2019.
[I-D.ietf-spring-srv6-network-programming] [I-D.ietf-spring-srv6-network-programming]
Filsfils, C., Camarillo, P., Leddy, J., Voyer, D., Filsfils, C., Camarillo, P., Leddy, J., Voyer, D.,
Matsushima, S., and Z. Li, "SRv6 Network Programming", Matsushima, S., and Z. Li, "SRv6 Network Programming",
draft-ietf-spring-srv6-network-programming-07 (work in draft-ietf-spring-srv6-network-programming-10 (work in
progress), December 2019. progress), February 2020.
[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>.
[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
May 2017, <https://www.rfc-editor.org/info/rfc8174>. May 2017, <https://www.rfc-editor.org/info/rfc8174>.
 End of changes. 21 change blocks. 
84 lines changed or deleted 53 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/