< draft-ietf-sidrops-roa-considerations-01.txt   draft-ietf-sidrops-roa-considerations-02.txt >
SIDR Operations Z. Yan SIDR Operations Z. Yan
Internet-Draft CNNIC Internet-Draft CNNIC
Intended status: Informational R. Bush Intended status: Informational R. Bush
Expires: April 28, 2022 Internet Initiative Japan Expires: 29 October 2022 Internet Initiative Japan
G. Geng G.G. Geng
Jinan University Jinan University
J. Yao J. Yao
CNNIC CNNIC
October 25, 2021 April 2022
Problem Statement and Considerations for ROA containing Multiple Avoidance for ROA Containing Multiple IP Prefixes
Prefixes draft-ietf-sidrops-roa-considerations-02
draft-ietf-sidrops-roa-considerations-01
Abstract Abstract
The address space holder needs to issue an ROA object when it In RPKI, the address space holder needs to issue an ROA object when
authorizes one or more ASes to originate routes to IP prefix(es). authorizing one or more ASes to originate routes to IP prefix(es).
During the process of ROA issuance, the address space holder may need During ROA issurance process, the address space holder may need to
to specify an origin AS for a list of IP prefixes. Besides, the specify an origin AS for a list of IP prefixes. Additionally, the
address space holder has a free choice to put multiple prefixes into address space holder is free to choose to put multiple prefixes into
a single ROA or issue separate ROAs for each prefix based on the a single ROA or issue separate ROAs for each prefix according to the
current specification. This memo analyzes and presents some current specification. This memo analyzes some operational problems
operational problems which may be caused by the ROAs containing which may arise from ROAs containing multiple IP prefixes and
multiple IP prefixes. Some suggestions and considerations also have recommends avoiding placing multiple IP prefixes in one ROA.
been proposed.
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 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 April 28, 2022. This Internet-Draft will expire on 3 October 2022.
Copyright Notice Copyright Notice
Copyright (c) 2021 IETF Trust and the persons identified as the Copyright (c) 2022 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/
(https://trustee.ietf.org/license-info) in effect on the date of license-info) in effect on the date of publication of this document.
publication of this document. Please review these documents Please review these documents carefully, as they describe your rights
carefully, as they describe your rights and restrictions with respect and restrictions with respect to this document. Code Components
to this document. Code Components extracted from this document must extracted from this document must include Revised BSD License text as
include Simplified BSD License text as described in Section 4.e of described in Section 4.e of the Trust Legal Provisions and are
the Trust Legal Provisions and are provided without warranty as provided without warranty as described in the Revised BSD License.
described in the Simplified BSD License.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3
3. Problem statement and Analysis . . . . . . . . . . . . . . . 3 3. Problem statement and Analysis . . . . . . . . . . . . . . . 3
4. Suggestions and Considerations . . . . . . . . . . . . . . . 6 4. Suggestions . . . . . . . . . . . . . . . . . . . . . . . . . 3
5. Security Considerations . . . . . . . . . . . . . . . . . . . 7 5. Security Considerations . . . . . . . . . . . . . . . . . . . 4
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 7 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 4
7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 7 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 4
8. References . . . . . . . . . . . . . . . . . . . . . . . . . 7 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 4
8.1. Normative References . . . . . . . . . . . . . . . . . . 7 8.1. Normative References . . . . . . . . . . . . . . . . . . 4
8.2. Informative References . . . . . . . . . . . . . . . . . 8 8.2. Informative References . . . . . . . . . . . . . . . . . 4
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 8 Appendix A. ROA Analysis . . . . . . . . . . . . . . . . . . . . 5
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 6
1. Introduction 1. Introduction
Route Origin Authorization (ROA) is a digitally signed object which In Resource Public Key Infrastructure (RPKI), Route Origin
is used to identify that a single AS has been authorized by the Authorization (ROA) is a digitally signed object which identifies
address space holder to originate routes to one or more prefixes that a single AS has been authorized by the address space holder to
within the address space[RFC6482].If the address space holder needs originate routes to one or more prefixes within the address
to authorize more than one ASes to advertise the same set of address space[RFC6482].
prefixes, the holder must issue multiple ROAs, one per AS number.
However, at present there are no mandatory requirements in any RFCs
describing that the address space holders must issue a separate ROA
for each prefix or a ROA containing multiple prefixes.
Each ROA contains an "asID" field and an "ipAddrBlocks" field. The Each ROA contains an "asID" field and an "ipAddrBlocks" field. The
"asID" field contains one single AS number which is authorized to "asID" field contains one single AS number which is authorized to
originate routes to the given IP address prefixes. The originate routes to the given IP address prefixes. The
"ipAddrBlocks" field contains one or more IP address prefixes to "ipAddrBlocks" field contains one or more IP address prefixes to
which the AS is authorized to originate the routes. The ROAs with which the AS is authorized to originate the routes. If the address
multiple prefixes is a common case that each ROA contains exactly one space holder needs to authorize more than one ASes to advertise the
AS number but may contain multiple IP address prefixes in the same set of address prefixes, the holder must issue multiple ROAs,
operational process of ROA issuance. one for each AS number. However, at present there are no mandatory
requirements describing that the address space holders must issue a
separate ROA for each prefix or a ROA containing multiple prefixes.
2. Terminology 2. Terminology
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", "NOT RECOMMENDED", "MAY", and
document are to be interpreted as described in [RFC2119]. "OPTIONAL" in this document are to be interpreted as described in BCP
14 [RFC2119] [RFC8174] when, and only when, they appear in all
capitals, as shown here.
3. Problem statement and Analysis 3. Problem statement and Analysis
As mentioned above, the address space holder needs to issue an ROA Currently, there are about 24% ROAs containing two or more prefixes.
object when it authorizes one or more ASes to originate routes to Among them, the average number of prefixes per ROA exceeds 10.
multiple prefixes. During the process of ROA issuance, the address
space holder always needs to specify an origin AS for a list of IP For ROAs containing multiple prefixes, adding or deleting one <AS,
prefixes. Besides, the address space holder has a free choice to put ip_prefix> pair, the entire ROA must be withdrawn and reissued, or
multiple prefixes into a single ROA or issue separate ROAs for each covered by a new ROA. That is, although aggregating multiple IP
prefix based on the current specification. prefixes can reduce the number of issued ROA, updating an ROA
containing multiple IP address prefixes will result in redundant
transmission between RP and BGP routers because in reality just the
changed IP prefix needs to be updated by the new ROA. Updating these
ROAs frequently will increase the convergence time of BGP routers and
reduce the stability of RPKI and BGP system.
In addition, ROAs have a long validity period in default, during
which the prefix ownership is more likely to change (of course,
resource shrink may happen at any time), which will lead to the
withdrawal or reissue of the whole set of prefixes aggregated within
the same ROA. This will increase the mis-configuration possibility
and operational complexity [RFC8211]. If one prefix is included in
the list by mistake, the whole ROA will not be generated
successfully.
4. Suggestions
The following suggestions should be considered during the process of
ROA issurance:
1) It's the most important to guarantee the stability and security of
RPKI and BGP system, and it is recommended to include a single IP
prefix in each ROA in default.
2) In some special scenarios, where the resource is very stable or a
CA has operational problems producing increased number of individual
ROAs, multiple IP prefixes may be aggregated in one ROA.
5. Security Considerations
This memo does not give rise to additional security risks.
6. IANA Considerations
This document does not request any IANA action.
7. Acknowledgements
The authors would like to thanks the valuable comments made by
members of sidrops WG and the list will be updated later.
This work was supported by the Beijing Nova Program of Science and
Technology under grant Z191100001119113.
This document was produced using the xml2rfc tool [RFC2629].
8. References
8.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997,
<https://www.rfc-editor.org/info/rfc2119>.
[RFC2629] Rose, M., "Writing I-Ds and RFCs using XML", RFC 2629,
DOI 10.17487/RFC2629, June 1999,
<https://www.rfc-editor.org/info/rfc2629>.
[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
May 2017, <https://www.rfc-editor.org/info/rfc8174>.
8.2. Informative References
[RFC6482] Lepinski, M., Kent, S., and D. Kong, "A Profile for Route
Origin Authorizations (ROAs)", RFC 6482,
DOI 10.17487/RFC6482, February 2012,
<https://www.rfc-editor.org/info/rfc6482>.
[RFC8211] Kent, S. and D. Ma, "Adverse Actions by a Certification
Authority (CA) or Repository Manager in the Resource
Public Key Infrastructure (RPKI)", RFC 8211,
DOI 10.17487/RFC8211, September 2017,
<https://www.rfc-editor.org/info/rfc8211>.
Appendix A. ROA Analysis
In order to illustrate the situations of the current ROA database, In order to illustrate the situations of the current ROA database,
the following analysis is made. the following analysis is made.
+-------------- -+----------------------+-------------------------+ +-------------- -+----------------------+-------------------------+
| The total | The number of ROAs | The number of ROAs with | | The total | The number of ROAs | The number of ROAs with |
| number of ROAs | with a single prefix | multiple prefixes | | number of ROAs | with a single prefix | multiple prefixes |
+----------------+----------------------+-------------------------+ +----------------+----------------------+-------------------------+
| 87334 | 66379 | 20955 | | 105542 | 81759 | 23783 |
+----------------+----------------------+-------------------------+ +----------------+----------------------+-------------------------+
Figure 1: Statistical results of global ROAs Figure 1: Statistical results of global ROAs
As shown in Figure. 1, by October 18th 2021, the total number of ROA As shown in Figure. 1, by April 24th 2022, the total number of ROA
objects issued around the world is about 87334. The result is in objects issued is about 105542. Based on the further analysis on
accordance with the statistics provided by RIPE NCC and Internet these ROA objects, it is found that the number of ROAs containing
Multifeed Co. (MF). Based on the further analysis on these ROA only one prefix is about 81759 (77.47% of all ROA objects), and the
objects, it is found that the number of ROAs containing only one number of ROAs containing two or more prefixes is about 23783 (22.53%
prefix is about 66379 (76.01% of all ROA objects), and the number of of all ROA objects).
ROAs containing two or more prefixes is about 20955 (23.99% of all
ROA objects).
In the 20955 ROA objects which each one contains two or more In the 23783 ROA objects which each one contains two or more
prefixes, the number of IP address prefixes are calculated and prefixes, the number of IP address prefixes are calculated and
analyzed. The statistical results are shown in Figure. 2. analyzed. The statistical results are shown in Figure. 2.
+----------------+----------------+--------------------------------+ +----------------+----------------+--------------------------------+
| The number of | The number of | The average number of prefixes | | The number of | The number of | The average number of prefixes |
| prefixes | ROAs | in each ROA | | prefixes | ROAs | in each ROA |
+----------------+----------------+--------------------------------+ +----------------+----------------+--------------------------------+
| 215425 | 20955 | 10.28 | | 248693 | 23783 | 10.46 |
+----------------+----------------+--------------------------------+ +----------------+----------------+--------------------------------+
Figure 2: Statistical results of the ROAs with multiple prefixes Figure 2: Statistical results of the ROAs with multiple prefixes
As described in Figure. 2, there are 215425 IP address prefixes in As described in Figure. 2, there are 248693 IP address prefixes in
the 20955 ROA objects. And the average number of prefixes in each the 23783 ROA objects. And the average number of prefixes in each
ROA is 10.28 (215425/20955). In addition, four types of ROAs are ROA is 10.46 (248693/23783). In addition, four types of ROAs are
analyzed and calculated within the 20955 ROAs: ROAs each contains analyzed and calculated within the 23783 ROAs: ROAs each contains
2-10/11-50/51-100/>100 IP address prefixes. The statistical results 2-10/11-50/51-100/>100 IP address prefixes. The statistical results
are presented in Figure. 3. are presented in Figure. 3.
+----------+----------+----------+----------+----------+-------+ +----------+----------+----------+----------+----------+-------+
| ROA | ROA with | ROA with | ROA with | ROA with | Total | | ROA | ROA with | ROA with | ROA with | ROA with | Total |
| types | 2-10 | 11-50 | 51-100 | >100 | number| | types | 2-10 | 11-50 | 51-100 | >100 | number|
| | prefixes | prefixes | prefixes | prefixes | | | | prefixes | prefixes | prefixes | prefixes | |
+----------+----------+----------+----------+----------+-------+ +----------+----------+----------+----------+----------+-------+
| The | 17918 | 2508 | 272 | 257 | 20955 | | The | 20286 | 2880 | 322 | 295 | 23783 |
| number | | | | | | | number | | | | | |
| of ROAs | | | | | | | of ROAs | | | | | |
+----------+----------+----------+----------+----------+-------+ +----------+----------+----------+----------+----------+-------+
| The | 85.51% | 11.97% | 1.30% | 1.22% | 100% | | The | 85.30% | 12.11% | 1.35% | 1.24% | 100% |
| ratio of | | | | | | | ratio of | | | | | |
| ROAs | | | | | | | ROAs | | | | | |
+----------+----------+----------+----------+----------+-------+ +----------+----------+----------+----------+----------+-------+
| The | 65744 | 51904 | 18475 | 79302 |215425 | | The | 74504 | 59015 | 22244 | 92930 |248693 |
| number | | | | | | | number | | | | | |
| of | | | | | | | of | | | | | |
| prefixes | | | | | | | prefixes | | | | | |
+----------+----------+----------+----------+----------+-------+ +----------+----------+----------+----------+----------+-------+
| The | 30.52% | 24.09% | 8.58% | 36.81% | 100% | | The | 29.96% | 23.73% | 8.94% | 37.37% | 100% |
| ratio of | | | | | | | ratio of | | | | | |
| prefixes | | | | | | | prefixes | | | | | |
+----------+----------+----------+----------+----------+-------+ +----------+----------+----------+----------+----------+-------+
Figure 3: Statistical results of four types of ROAs Figure 3: Statistical results of four types of ROAs
As shown in Figure. 3, taking the first type of ROA as an example, As shown in Figure. 3, taking the first type of ROA as an example,
there are 17918 ROAs (85.51% of the 20955 ROA objects) which each there are 20286 ROAs (85.3% of the 23783 ROA objects) which each
contains 2-10 IP address prefixes, and the total number of IP contains 2-10 IP address prefixes, and the total number of IP
prefixes in these 17918 ROAs is 65744 (30.52% of the 215425 prefixes in these 20286 ROAs is 74504 (29.96% of the 248693
prefixes). prefixes).
It shows that the address space holders tend to issue each ROA object It shows that the address space holders tend to issue each ROA object
with fewer IP prefixes (more than 95% of ROAs containing less than 50 with fewer IP prefixes (more than 95% of ROAs containing less than 50
prefixes), but they still tend to put multiple prefixes into one prefixes), but they still tend to put multiple prefixes into one
single ROA. single ROA.
Furthermore, the ROA data of different RIR CAs are analyzed in The longest and shortest validity periods of a single ROA is 28854
Figure. 4. days and 2 days. In addition, the average validity period of each
ROA is 707.83 days.
+---------------+-------+--------+--------+------+--------+------+
| | ARIN | AfriNIC| LACNIC | APNIC| RIPENCC| Total|
+---------------+-------+--------+--------+------+--------+------+
| The number of | 3388 | 486 | 2825 | 6439 | 14163 |25688 |
| active ASNs | | | | | | |
+---------------+-------+--------+--------+------+--------+------+
| The number of | 43156 | 3437 | 16974 | 78325| 139912 |281804|
| prefixes | | | | | | |
+---------------+-------+--------+--------+------+--------+------+
| The number of | 34871 | 2626 | 9581 | 14240| 26016 |87334 |
| ROAs | | | | | | |
+---------------+-------+--------+--------+------+--------+------+
| The average | 1.24 | 1.31 | 1.77 | 5.50 | 5.38 | 3.23 |
| number of | | | | | | |
| prefixes | | | | | | |
| in each ROA | | | | | | |
+---------------+-------+--------+--------+------+--------+------+
| The maximum | 608 | 64 | 292 | 3512 | 4088 | 4088 |
| number of | | | | | | |
| prefixes in | | | | | | |
| a single ROA | | | | | | |
+---------------+-------+--------+--------+------+--------+------+
| The longest | 3653 | 10588 | 28854 | 6373 | 546 |28854 |
| validity time | | | | | | |
| of a single | | | | | | |
| ROA | | | | | | |
+---------------+-------+--------+--------+------+--------+------+
| The shortest | 24 | 45 | 56 | 73 | 255 | 24 |
| validity time | | | | | | |
| of a single | | | | | | |
| ROA | | | | | | |
+---------------+-------+--------+--------+------+--------+------+
| The average |1656.91|1811.59 |1253.17 |353.87| 426.64 |661.50|
| validity time | | | | | | |
| in each ROA | | | | | | |
+---------------+-------+--------+--------+------+--------+------+
Figure 4: Statistical results of RIR CAs
As shown in Figure 4, the total number of active ASNs on that day (
October 18th, 2021) has reached 25,688. Taking RIPENCC as an
example, it has the highest number of active ASNs and prefixes. And
the average number of prefixes in each ROA is 5.38 (139912 /26016 ).
According to the Figure 4, there are currently a maximum of 4088
prefixes used in a single ROA, while AfriNIC is more conservative,
and the maximum number of prefixes is only 64.
Still taking RIPENCC as an example, the longest and shortest validity
periods of a single ROA in RIPENCC is 546 days and 255 days. In
addition, the average validity period of each ROA in Ripencc is
426.64 days.
The potential influence of operations of ROAs containing multiple IP
prefixes on BGP routers must be considered. For the ROA containing
multiple prefixes, once increase or delete one <AS, ip_prefix> pair
in it, this whole ROA must be withdrawn and reissued. Through
sychronization with repository, Relying Party (RP) fetches a new ROA
object and then notify and send all the <AS, ip_prefix> pairs in this
ROA to BGP routers. That is to say, the update of the ROA containing
multiple IP address prefixes will lead to redundant transmission
between RP and BGP routers. So frequent update of these ROAs will
increase the convergency time of BGP routers and reduce their
performance obviously.
In addition, the validity period of ROA is a long time in default,
the prefix ownership change is more possible during this period, this
will cause the withdraw or re-issurance of the whole set of prefixes
containing within the same ROA. This will increase the mis-
configuration possibility and operational complexity. If one prefix
is contained in the list by mistake, the whole ROA will not be
generated successfully.
4. Suggestions and Considerations
The following suggestions should be considered during the process of
ROA issuance:
1) The issuance of ROAs containing a large number of IP prefixes may
lead to instability of BGP routing more easily than ROAs with fewer
IP prefixes even without mis-configurations.
A ROA which contains a large number of IP prefixes is more instable
and vulnerable to mis-configurations, because any update of these
prefixes may cause the issued ROA to be withdrawn. Besides, since
the misconfigurations of ROAs containing a larger number of IP
address prefixes may lead to much more serious consequences (a large-
scale network interruption) than ROAs with fewer IP address prefixes,
it is suggested to avoid issuing ROAs with a large number of IP
address prefixes.
2) The number of ROAs containing multiple IP prefixes should be
limited and the number of IP prefixes in each ROA should also be
limited.
The extreme case (a single ROA can only contain one IP address
prefix) may lead to too many ROA objects globally, which may in turn
become a burden for RPs to synchronize and validate all these ROA
objects with the fully deployment of RPKI. So it seems that a
tradeoff between the number of ROAs and the number of IP prefixes in
a single ROA should be considered. However, considering the
stability and security of RPKI and BGP routing system is the most
important target, containing one IP address prefix in a single ROA is
recommended if the CA wants to avoids the potential instability and
risks.
5. Security Considerations
A safeguard scheme to protect and monitor the process of ROA issuance
should be considered. At least, when a ROA should be updated by the
address space holder because of the change of IP address prefix, the
CA GUI should warn the user that the ROA which is being created will
invalidate the current BGP announcement in the global BGP.
6. IANA Considerations
This document does not request any IANA action.
7. Acknowledgements
The authors would like to thanks the valuable comments made by
members of sidrops WG and the list will be updated later.
This work was supported by the Beijing Nova Program of Science and
Technology under grant Z191100001119113.
This document was produced using the xml2rfc tool [RFC2629].
8. References
8.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997,
<https://www.rfc-editor.org/info/rfc2119>.
[RFC6482] Lepinski, M., Kent, S., and D. Kong, "A Profile for Route
Origin Authorizations (ROAs)", RFC 6482,
DOI 10.17487/RFC6482, February 2012,
<https://www.rfc-editor.org/info/rfc6482>.
8.2. Informative References
[RFC2629] Rose, M., "Writing I-Ds and RFCs using XML", RFC 2629,
DOI 10.17487/RFC2629, June 1999,
<https://www.rfc-editor.org/info/rfc2629>.
Authors' Addresses Authors' Addresses
Zhiwei Yan Zhiwei Yan
CNNIC CNNIC
No.4 South 4th Street, Zhongguancun No.4 South 4th Street, Zhongguancun
Beijing, 100190 Beijing, 100190
P.R. China P.R. China
Email: yanzhiwei@cnnic.cn Email: yanzhiwei@cnnic.cn
Randy Bush Randy Bush
Internet Initiative Japan Internet Initiative Japan
Email: randy@psg.com Email: randy@psg.com
Guanggang Geng Guanggang Geng
Jinan University Jinan University
No.601, West Huangpu Avenue No.601, West Huangpu Avenue
Guangzhou 510632 Guangzhou
510632
China China
Email: gggeng@jnu.edu.cn Email: gggeng@jnu.edu.cn
Jiankang Yao Jiankang Yao
CNNIC CNNIC
No.4 South 4th Street, Zhongguancun No.4 South 4th Street, Zhongguancun
Beijing, 100190 Beijing, 100190
P.R. China P.R. China
Email: yaojk@cnnic.cn Email: yaojk@cnnic.cn
 End of changes. 33 change blocks. 
235 lines changed or deleted 158 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/