draft-ietf-pim-sm-bsr-08.txt   draft-ietf-pim-sm-bsr-09.txt 
Internet Engineering Task Force PIM WG Internet Engineering Task Force PIM WG
INTERNET-DRAFT Nidhi Bhaskar/Cisco INTERNET-DRAFT Nidhi Bhaskar/Cisco
draft-ietf-pim-sm-bsr-08.txt Alexander Gall/SWITCH draft-ietf-pim-sm-bsr-09.txt Alexander Gall/SWITCH
James Lingard James Lingard/Arastra
Stig Venaas/UNINETT Stig Venaas/UNINETT
Expires: November 2006 Expires: December 2006
Bootstrap Router (BSR) Mechanism for PIM Bootstrap Router (BSR) Mechanism for PIM
Status of this Document Status of this Document
By submitting this Internet-Draft, each author represents that any By submitting this Internet-Draft, each author represents that any
applicable patent or other IPR claims of which he or she is aware have applicable patent or other IPR claims of which he or she is aware have
been or will be disclosed, and any of which he or she becomes aware will been or will be disclosed, and any of which he or she becomes aware will
be disclosed, in accordance with Section 6 of BCP 79. be disclosed, in accordance with Section 6 of BCP 79.
skipping to change at page 3, line 11 skipping to change at page 3, line 11
mappings required in order to function. The mechanism is mappings required in order to function. The mechanism is
dynamic, largely self-configuring, and robust to router dynamic, largely self-configuring, and robust to router
failure. failure.
Table of Contents Table of Contents
1. Introduction. . . . . . . . . . . . . . . . . . . . . . 4 1. Introduction. . . . . . . . . . . . . . . . . . . . . . 4
1.1. Background . . . . . . . . . . . . . . . . . . . . . 4 1.1. Background . . . . . . . . . . . . . . . . . . . . . 4
1.2. Protocol Overview. . . . . . . . . . . . . . . . . . 6 1.2. Protocol Overview. . . . . . . . . . . . . . . . . . 6
1.3. Administrative Scoping and BSR . . . . . . . . . . . 7 1.3. Administrative Scoping and BSR . . . . . . . . . . . 7
2. BSR State and Timers. . . . . . . . . . . . . . . . . . 9 2. BSR State and Timers. . . . . . . . . . . . . . . . . . 8
3. Bootstrap Router Election and RP-Set 3. Bootstrap Router Election and RP-Set
Distribution. . . . . . . . . . . . . . . . . . . . . . 9 Distribution. . . . . . . . . . . . . . . . . . . . . . 9
3.1. Bootstrap Router Election. . . . . . . . . . . . . . 9 3.1. Bootstrap Router Election. . . . . . . . . . . . . . 9
3.1.1. Per-Scope-Zone Candidate-BSR State 3.1.1. Per-Scope-Zone Candidate-BSR State
Machine . . . . . . . . . . . . . . . . . . . . . 10 Machine . . . . . . . . . . . . . . . . . . . . . 10
3.1.2. Per-Scope-Zone State Machine for Non- 3.1.2. Per-Scope-Zone State Machine for Non-
Candidate-BSR Routers . . . . . . . . . . . . . . 12 Candidate-BSR Routers . . . . . . . . . . . . . . 12
3.1.3. Bootstrap Message Processing Checks . . . . . . . 14 3.1.3. Bootstrap Message Processing Checks . . . . . . . 14
3.1.4. State Machine Transition Events . . . . . . . . . 15 3.1.4. State Machine Transition Events . . . . . . . . . 15
3.1.5. State Machine Actions . . . . . . . . . . . . . . 16 3.1.5. State Machine Actions . . . . . . . . . . . . . . 16
skipping to change at page 3, line 35 skipping to change at page 3, line 35
3.5. Bootstrap Messages to New and Rebooting 3.5. Bootstrap Messages to New and Rebooting
Routers. . . . . . . . . . . . . . . . . . . . . . . 22 Routers. . . . . . . . . . . . . . . . . . . . . . . 22
3.5.1. No-Forward Bootstrap Messages . . . . . . . . . . 22 3.5.1. No-Forward Bootstrap Messages . . . . . . . . . . 22
3.5.2. Unicasting Bootstrap Messages . . . . . . . . . . 23 3.5.2. Unicasting Bootstrap Messages . . . . . . . . . . 23
3.6. Receiving and Using the RP-Set . . . . . . . . . . . 23 3.6. Receiving and Using the RP-Set . . . . . . . . . . . 23
4. Message Formats . . . . . . . . . . . . . . . . . . . . 23 4. Message Formats . . . . . . . . . . . . . . . . . . . . 23
4.1. Bootstrap Message Format . . . . . . . . . . . . . . 25 4.1. Bootstrap Message Format . . . . . . . . . . . . . . 25
4.1.1. Semantic Fragmentation of BSMs. . . . . . . . . . 29 4.1.1. Semantic Fragmentation of BSMs. . . . . . . . . . 29
4.2. Candidate-RP-Advertisement Message Format. . . . . . 30 4.2. Candidate-RP-Advertisement Message Format. . . . . . 30
5. Timers and Timer Values . . . . . . . . . . . . . . . . 32 5. Timers and Timer Values . . . . . . . . . . . . . . . . 32
6. Security Considerations . . . . . . . . . . . . . . . . 35 6. Security Considerations . . . . . . . . . . . . . . . . 36
6.1. Possible Threats . . . . . . . . . . . . . . . . . . 35 6.1. Possible Threats . . . . . . . . . . . . . . . . . . 36
6.2. Limiting Third-Party DoS Attacks . . . . . . . . . . 35 6.2. Limiting Third-Party DoS Attacks . . . . . . . . . . 37
6.3. Bootstrap Message Security . . . . . . . . . . . . . 36 6.3. Bootstrap Message Security . . . . . . . . . . . . . 37
6.3.1. Rejecting Bootstrap Messages from Invalid 6.3.1. Rejecting Bootstrap Messages from Invalid
Neighbors . . . . . . . . . . . . . . . . . . . . 36 Neighbors . . . . . . . . . . . . . . . . . . . . 38
6.4. Candidate-RP-Advertisement Message Security. . . . . 37 6.4. Candidate-RP-Advertisement Message Security. . . . . 38
6.4.1. Non-Cryptographic Security of C-RP-Adv 6.4.1. Non-Cryptographic Security of C-RP-Adv
Messages. . . . . . . . . . . . . . . . . . . . . 37 Messages. . . . . . . . . . . . . . . . . . . . . 38
6.4.2. Cryptographic Security of C-RP-Adv 6.4.2. Cryptographic Security of C-RP-Adv
Messages. . . . . . . . . . . . . . . . . . . . . 37 Messages. . . . . . . . . . . . . . . . . . . . . 39
6.5. Denial of Service using IPsec. . . . . . . . . . . . 38 6.5. Denial of Service using IPsec. . . . . . . . . . . . 39
7. Contributors. . . . . . . . . . . . . . . . . . . . . . 38 7. Contributors. . . . . . . . . . . . . . . . . . . . . . 40
8. Acknowledgments . . . . . . . . . . . . . . . . . . . . 38 8. Acknowledgments . . . . . . . . . . . . . . . . . . . . 40
9. IANA Considerations . . . . . . . . . . . . . . . . . . 39 9. IANA Considerations . . . . . . . . . . . . . . . . . . 40
10. Normative References . . . . . . . . . . . . . . . . . 39 10. Normative References . . . . . . . . . . . . . . . . . 40
11. Informative References . . . . . . . . . . . . . . . . 39 11. Informative References . . . . . . . . . . . . . . . . 41
1. Introduction 1. Introduction
This document assumes some familiarity with the concepts of Protocol This document assumes some familiarity with the concepts of Protocol
Independent Multicast - Sparse Mode (PIM-SM), as defined in [1], and Bi- Independent Multicast - Sparse Mode (PIM-SM), as defined in [1], and Bi-
directional Protocol Independent Multicast (BIDIR-PIM), as defined in directional Protocol Independent Multicast (BIDIR-PIM), as defined in
[2], as well as with Administratively Scoped IP Multicast, as described [2], as well as with Administratively Scoped IP Multicast, as described
in [3], and the IPv6 Scoped Address Architecture, described in [4]. in [3], and the IPv6 Scoped Address Architecture, described in [4].
For correct operation, every multicast router within a PIM domain must For correct operation, every multicast router within a PIM domain must
skipping to change at page 7, line 45 skipping to change at page 7, line 45
important to note that a given scope boundary always creates at least important to note that a given scope boundary always creates at least
two scoped regions: one on either side of the boundary. two scoped regions: one on either side of the boundary.
In IPv4, administratively scoped regions are associated with a set of In IPv4, administratively scoped regions are associated with a set of
addresses given by an address and a prefix length. In IPv6, addresses given by an address and a prefix length. In IPv6,
administratively scoped regions are associated with a set of addresses administratively scoped regions are associated with a set of addresses
given by a single scope ID value. The set of addresses corresponding to given by a single scope ID value. The set of addresses corresponding to
a given scope ID value is defined in [5]. For example, a scope ID of 5 a given scope ID value is defined in [5]. For example, a scope ID of 5
maps to the 16 IPv6 address ranges ff[0-f]5::/16. maps to the 16 IPv6 address ranges ff[0-f]5::/16.
There are certain topological restrictions on admin-scope regions. There are certain topological restrictions on admin-scope regions. The
Firstly, the scope zone border must be complete and convex. By this we scope zone border must be complete and convex. By this we mean that
mean that there must be no path from inside the scoped zone to outside there must be no path from inside the scoped zone to outside it that
it that does not pass through a configured scope border router, and that does not pass through a configured scope border router, and that the
the multicast capable path between any arbitrary pair of multicast multicast capable path between any arbitrary pair of multicast routers
routers in the scope zone must remain in the zone. In addition, a in the scope zone must remain in the zone.
boundary for one scope must always be a boundary for all smaller scopes,
where a smaller scope for IPv4 is one whose address range is contained
within the other address range, and for IPv6 is one whose scope ID is
less than the other scope ID.
Administrative scoping complicates BSR because we do not want a PIM Administrative scoping complicates BSR because we do not want a PIM
router within the scoped region to use an RP outside the scoped region. router within the scoped region to use an RP outside the scoped region.
Thus we need to modify the basic mechanism to ensure that this doesn't Thus we need to modify the basic mechanism to ensure that this doesn't
happen. happen.
This is done by running a separate copy of the basic BSR mechanism, as This is done by running a separate copy of the basic BSR mechanism, as
described in the previous section, within each admin scope region of a described in the previous section, within each admin scope region of a
PIM domain. Thus a separate BSR election takes place for each admin- PIM domain. Thus a separate BSR election takes place for each admin-
scope region, a C-RP typically registers to the BSR of every admin scope scope region, a C-RP typically registers to the BSR of every admin scope
skipping to change at page 12, line 11 skipping to change at page 12, line 11
Elected-BSR (E-BSR) Elected-BSR (E-BSR)
The router is the elected BSR for the scope zone and it must The router is the elected BSR for the scope zone and it must
perform all the BSR functions. perform all the BSR functions.
In addition to the three states, there is one timer: In addition to the three states, there is one timer:
o The Bootstrap Timer (BST) - used to time out old bootstrap router o The Bootstrap Timer (BST) - used to time out old bootstrap router
information, and used in the election process to terminate P-BSR information, and used in the election process to terminate P-BSR
state. state.
On startup, the initial state for this configured scope zone is The initial state for this configured scope zone is "Pending-BSR"; the
"Pending-BSR"; the Bootstrap Timer is initialized to BS_Rand_Override. Bootstrap Timer is initialized to BS_Rand_Override. This is the case
both if the router is a Candidate BSR at startup, and if reconfigured to
become one later.
3.1.2. Per-Scope-Zone State Machine for Non-Candidate-BSR Routers 3.1.2. Per-Scope-Zone State Machine for Non-Candidate-BSR Routers
+-----------------------------------------------------------------------+ +-----------------------------------------------------------------------+
| When in NoInfo state | | When in NoInfo state |
+---------------------+-------------------------------------------------+ +---------------------+-------------------------------------------------+
| Event | Receive BSM | | Event | Receive BSM |
+---------------------+-------------------------------------------------+ +---------------------+-------------------------------------------------+
| | -> AP state | | | -> AP state |
| Action | Forward BSM; Store RP-Set; | | Action | Forward BSM; Store RP-Set; |
skipping to change at page 17, line 36 skipping to change at page 17, line 36
3.2. Sending Candidate-RP-Advertisement Messages 3.2. Sending Candidate-RP-Advertisement Messages
Every C-RP periodically unicasts a C-RP-Adv message to the BSR for each Every C-RP periodically unicasts a C-RP-Adv message to the BSR for each
scope zone for which it has state, to inform the BSR of the C-RP's scope zone for which it has state, to inform the BSR of the C-RP's
willingness to function as an RP. These messages are sent with an willingness to function as an RP. These messages are sent with an
interval of C_RP_Adv_Period, except when a new BSR is elected, see interval of C_RP_Adv_Period, except when a new BSR is elected, see
below. below.
When a new BSR is elected, the C-RP MUST send one to three C-RP-Adv When a new BSR is elected, the C-RP MUST send one to three C-RP-Adv
messages, waiting a randomized amount of 0-3 seconds before sending each messages, waiting a small randomized period C_RP_Adv_Backoff before
message. We recommend sending three messages because it is important sending each message. We recommend sending three messages because it is
that the BSR quickly learns which RPs are active, and some packet loss important that the BSR quickly learns which RPs are active, and some
may occur when a new BSR is elected due to changes in the network. One packet loss may occur when a new BSR is elected due to changes in the
way of implementing this is to set the CRPT to 0-3 seconds when the new network. One way of implementing this is to set the CRPT to
BSR is elected, as well as setting a counter to 2. Whenever the CRPT C_RP_Adv_Backoff when the new BSR is elected, as well as setting a
expires, we first send a C-RP-Adv message as usual. Next, if the counter to 2. Whenever the CRPT expires, we first send a C-RP-Adv
counter is non-zero, it is decremented and the CRPT is again set to 0-3 message as usual. Next, if the counter is non-zero, it is decremented
seconds instead of C_RP_Adv_Period. and the CRPT is again set to C_RP_Adv_Backoff instead of
C_RP_Adv_Period.
The Priority field in these messages is used by the BSR to select which The Priority field in these messages is used by the BSR to select which
C-RPs to include in the RP-Set. Note that lower values of this field C-RPs to include in the RP-Set. Note that lower values of this field
indicate higher priorities, so that a value of zero is the highest indicate higher priorities, so that a value of zero is the highest
possible priority. C-RPs should by default send C-RP-Adv messages with possible priority. C-RPs should by default send C-RP-Adv messages with
the Priority field set to 192. the Priority field set to 192.
When a C-RP is being shut down, it SHOULD immediately send a C-RP-Adv When a C-RP is being shut down, it SHOULD immediately send a C-RP-Adv
message to the BSR for each scope zone for which it is currently serving message to the BSR for each scope zone for which it is currently serving
as an RP; the Holdtime in this C-RP-Adv message should be zero. The BSR as an RP; the Holdtime in this C-RP-Adv message should be zero. The BSR
skipping to change at page 19, line 51 skipping to change at page 19, line 51
only if the router is elected as the non-scoped BSR. only if the router is elected as the non-scoped BSR.
When a CGET expires, the corresponding group-to-C-RP mapping is removed When a CGET expires, the corresponding group-to-C-RP mapping is removed
from the C-RP-Set. from the C-RP-Set.
The BSR constructs the RP-Set from the C-RP-Set. It may apply a local The BSR constructs the RP-Set from the C-RP-Set. It may apply a local
policy to limit the number of Candidate-RPs included in the RP-Set. The policy to limit the number of Candidate-RPs included in the RP-Set. The
BSR may override the prefix indicated in a C-RP-Adv message unless the BSR may override the prefix indicated in a C-RP-Adv message unless the
`Priority' field from the C-RP-Adv message is less than 128. `Priority' field from the C-RP-Adv message is less than 128.
If the BSR learns of both BIDIR and PIM-SM Candidate-RPs for the same
group range, the BSR MUST only include RPs for one of the protocols in
the BSMs. The default behavior SHOULD be to prefer BIDIR.
For inclusion in a BSM, the RP-Set is subdivided into sets of {group- For inclusion in a BSM, the RP-Set is subdivided into sets of {group-
prefix, RP-Count, RP-addresses}. For each RP-address, the "RP-Holdtime" prefix, RP-Count, RP-addresses}. For each RP-address, the "RP-Holdtime"
field is set to the Holdtime from the C-RP-Set, subject to the field is set to the Holdtime from the C-RP-Set, subject to the
constraint that it MUST be larger than BS_Period and SHOULD be larger constraint that it MUST be larger than BS_Period and SHOULD be larger
than 2.5 times BS_Period to allow for some Bootstrap messages getting than 2.5 times BS_Period to allow for some Bootstrap messages getting
lost. If some holdtimes from the C-RP-Sets do not satisfy this lost. If some holdtimes from the C-RP-Sets do not satisfy this
constraint, the BSR MUST replace those holdtimes with a value satisfying constraint, the BSR MUST replace those holdtimes with a value satisfying
the constraint. An exception to this is the holdtime of zero which is the constraint. An exception to this is the holdtime of zero which is
used to immediately withdraw mappings. used to immediately withdraw mappings.
The format of the Bootstrap message allows `semantic fragmentation', if The format of the Bootstrap message allows `semantic fragmentation', if
the length of the original Bootstrap message exceeds the packet maximum the length of the original Bootstrap message exceeds the packet maximum
skipping to change at page 20, line 23 skipping to change at page 20, line 27
The format of the Bootstrap message allows `semantic fragmentation', if The format of the Bootstrap message allows `semantic fragmentation', if
the length of the original Bootstrap message exceeds the packet maximum the length of the original Bootstrap message exceeds the packet maximum
boundaries. However, we recommend against configuring a large number of boundaries. However, we recommend against configuring a large number of
routers as C-RPs, to reduce the semantic fragmentation required. routers as C-RPs, to reduce the semantic fragmentation required.
In general BSMs are originated at regular intervals according to the In general BSMs are originated at regular intervals according to the
BS_Period timer. We do recommend that a BSM is also originated whenever BS_Period timer. We do recommend that a BSM is also originated whenever
the RP-set to be announced in the BSMs changes. This will usually the RP-set to be announced in the BSMs changes. This will usually
happen when receiving C-RP advertisements from a new C-RP, or when a C- happen when receiving C-RP advertisements from a new C-RP, or when a C-
RP is shut down (C-RP advertisement with a holdtime of zero). There RP is shut down (C-RP advertisement with a holdtime of zero). There
MUST however be a minimum of 10 seconds between each time a BSM is sent. MUST however be a minimum of BS_Min_Interval between each time a BSM is
In particular, when a new BSR is elected, it will first send one BSM sent. In particular, when a new BSR is elected, it will first send one
(which is likely to be empty since it has not yet received any C-RP BSM (which is likely to be empty since it has not yet received any C-RP
advertisements), and then wait at least 10 seconds before sending a new advertisements), and then wait at least BS_Min_Interval before sending a
one. During those 10 seconds, it is likely to have received C-RP new one. During that time, it is likely to have received C-RP
advertisements from all usable C-RPs (since we say that a C-RP should advertisements from all usable C-RPs (since we say that a C-RP should
send one or more advertisements with small random delays of 0-3 seconds send one or more advertisements with small random delays of
when a new BSR is elected). For this case in particular, where routers C_RP_Adv_Backoff when a new BSR is elected). For this case in
may not have a usable RP-set, we recommend originating a BSM as soon as particular, where routers may not have a usable RP-set, we recommend
those 10 seconds have passed. We suggest though that a BSR can do this originating a BSM as soon as BS_Min_Interval has passed. We suggest
in general. One way of implementing this, is to decrease the Bootstrap though that a BSR can do this in general. One way of implementing this,
Timer to 10 seconds whenever the RP-set changes, while not changing the is to decrease the Bootstrap Timer to BS_Min_Interval whenever the RP-
timer if it is less or equal to 10. set changes, while not changing the timer if it is less or equal to
BS_Min_Interval.
A BSR originates separate scoped BSMs for each scope zone for which it A BSR originates separate scoped BSMs for each scope zone for which it
is the elected BSR, as well as originating non-scoped BSMs if it is the is the elected BSR, as well as originating non-scoped BSMs if it is the
elected non-scoped BSR. elected non-scoped BSR.
Each group-to-C-RP mapping is included in precisely one of these BSM, Each group-to-C-RP mapping is included in precisely one of these BSM,
namely the scoped BSM for the narrowest scope containing the group range namely the scoped BSM for the narrowest scope containing the group range
of the mapping, if any, or the non-scoped BSM otherwise. of the mapping, if any, or the non-scoped BSM otherwise.
A scoped BSM MUST have at least one group range, and the first group A scoped BSM MUST have at least one group range, and the first group
skipping to change at page 32, line 38 skipping to change at page 33, line 23
| | | with which BSMs | | | | with which BSMs |
| | | are normally | | | | are normally |
| | | originated | | | | originated |
+---------------------+--------------------------+----------------------+ +---------------------+--------------------------+----------------------+
| BS_Timeout | Default: 130 seconds | Interval after | | BS_Timeout | Default: 130 seconds | Interval after |
| | | which a BSR is | | | | which a BSR is |
| | | timed out if no | | | | timed out if no |
| | | BSM is received | | | | BSM is received |
| | | from that BSR | | | | from that BSR |
+---------------------+--------------------------+----------------------+ +---------------------+--------------------------+----------------------+
| BS_Min_Interval | Default: 10 seconds | Minimum interval |
| | | with which BSMs |
| | | may be originated |
+---------------------+--------------------------+----------------------+
| BS_Rand_Override | see below | Randomized | | BS_Rand_Override | see below | Randomized |
| | | interval used to | | | | interval used to |
| | | reduce control | | | | reduce control |
| | | message overhead | | | | message overhead |
| | | during BSR | | | | during BSR |
| | | election | | | | election |
+---------------------+--------------------------+----------------------+ +---------------------+--------------------------+----------------------+
Note that BS_Timeout MUST be larger than BS_Period, even if their values Note that BS_Timeout MUST be larger than BS_Period, even if their values
are changed from the defaults. We recommend that BS_Timeout is set to 2 are changed from the defaults. We recommend that BS_Timeout is set to 2
skipping to change at page 35, line 4 skipping to change at page 36, line 15
Timer Name: C-RP Advertisement Timer (CRPT) Timer Name: C-RP Advertisement Timer (CRPT)
+---------------------+-------------------------+-----------------------+ +---------------------+-------------------------+-----------------------+
| Value Name | Value | Explanation | | Value Name | Value | Explanation |
+---------------------+-------------------------+-----------------------+ +---------------------+-------------------------+-----------------------+
| C_RP_Adv_Period | Default: 60 seconds | Periodic interval | | C_RP_Adv_Period | Default: 60 seconds | Periodic interval |
| | | with which C-RP- | | | | with which C-RP- |
| | | Adv messages are | | | | Adv messages are |
| | | sent to a BSR | | | | sent to a BSR |
+---------------------+-------------------------+-----------------------+ +---------------------+-------------------------+-----------------------+
| C_RP_Adv_Backoff | Default: 0-3 seconds | Whenever a |
| | | triggered C_RP_Adv |
| | | is sent, a new |
| | | randomized value |
| | | between 0 and 3s |
| | | is used |
+---------------------+-------------------------+-----------------------+
6. Security Considerations 6. Security Considerations
6.1. Possible Threats 6.1. Possible Threats
Threats affecting the PIM BSR mechanism are primarily of two forms: Threats affecting the PIM BSR mechanism are primarily of two forms:
denial of service attacks, and traffic diversion attacks. An attacker denial of service attacks, and traffic diversion attacks. An attacker
that subverts the BSR mechanism can prevent multicast traffic from that subverts the BSR mechanism can prevent multicast traffic from
reaching the intended recipients, can divert multicast traffic to a reaching the intended recipients, can divert multicast traffic to a
place where they can monitor it, and can potentially flood third parties place where they can monitor it, and can potentially flood third parties
skipping to change at page 40, line 20 skipping to change at page 41, line 39
Alexander Gall Alexander Gall
SWITCH SWITCH
Limmatquai 138 Limmatquai 138
P.O. Box P.O. Box
CH-8021 Zurich CH-8021 Zurich
Switzerland Switzerland
gall@switch.ch gall@switch.ch
James Lingard James Lingard
james@lingard.com Arastra, Inc.
P.O. Box 10905
Palo Alto, CA 94303
USA
jchl@arastra.com
Stig Venaas Stig Venaas
UNINETT UNINETT
NO-7465 Trondheim NO-7465 Trondheim
Norway Norway
venaas@uninett.no venaas@uninett.no
Copyright Statement Copyright Statement
Copyright (C) The Internet Society (2006). This document is subject to Copyright (C) The Internet Society (2006). This document is subject to
the rights, licenses and restrictions contained in BCP 78, and except as the rights, licenses and restrictions contained in BCP 78, and except as
 End of changes. 17 change blocks. 
55 lines changed or deleted 72 lines changed or added

This html diff was produced by rfcdiff 1.32. The latest version is available from http://www.levkowetz.com/ietf/tools/rfcdiff/