< draft-ietf-bier-ipv6-requirements-01.txt   draft-ietf-bier-ipv6-requirements-02.txt >
Network Working Group M. McBride Network Working Group M. McBride
Internet-Draft Futurewei Internet-Draft Futurewei
Intended status: Standards Track J. Xie Intended status: Standards Track J. Xie
Expires: January 2, 2020 S. Dhanaraj Expires: May 4, 2020 S. Dhanaraj
Huawei Huawei
R. Asati R. Asati
Cisco Cisco
July 1, 2019 November 1, 2019
BIER IPv6 Requirements BIER IPv6 Requirements
draft-ietf-bier-ipv6-requirements-01 draft-ietf-bier-ipv6-requirements-02
Abstract Abstract
The BIER WG has a charter item to work on mechanisms which use BIER The BIER WG includes, in it's charter, work on developing mechanisms
natively in IPv6. This document is intended to help the WG with this to transport BIER natively in IPv6. This document is intended to
effort by specifying requirements for transporting packets, with Bit help the WG with this effort by specifying requirements for
Index Explicit Replication (BIER) headers, in an IPv6 environment. transporting packets, with Bit Index Explicit Replication (BIER)
There will be a need to send IPv6 payloads, to multiple IPv6 headers, in an IPv6 environment. There will be a need to send IPv6
destinations, using BIER. There have been several proposed solutions payloads, to multiple IPv6 destinations, using BIER. There have been
in this area. But there hasn't been a document which describes the several proposed solutions in this area. But there hasn't been a
problem and lists the requirements. The goal of this document is to document which describes the problem and lists the requirements. The
describe the BIER IPv6 requirements and summarize the pro's and con's goal of this document is to describe the BIER IPv6 requirements,
of the proposed solutions. summarize the proposed solutions, and guide the working group in
understanding the benefits, and drawbacks, of the various solutions
and to help in the development of acceptable solutions.
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 January 2, 2020. This Internet-Draft will expire on May 4, 2020.
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
carefully, as they describe your rights and restrictions with respect carefully, as they describe your rights and restrictions with respect
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 . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1. Requirements Language . . . . . . . . . . . . . . . . . . 3 1.1. Requirements Language . . . . . . . . . . . . . . . . . . 3
1.2. Terminology . . . . . . . . . . . . . . . . . . . . . . . 3 1.2. Terminology . . . . . . . . . . . . . . . . . . . . . . . 3
2. Problem Statement . . . . . . . . . . . . . . . . . . . . . . 3 2. Problem Statement . . . . . . . . . . . . . . . . . . . . . . 3
3. BIER IPv6 Scenario's . . . . . . . . . . . . . . . . . . . . 3 3. BIER IPv6 Scenario's . . . . . . . . . . . . . . . . . . . . 4
3.1. BIERv6 for Access Network . . . . . . . . . . . . . . . . 4 3.1. BIERv6 for Access Network . . . . . . . . . . . . . . . . 4
3.2. BIERv6 for Data Center . . . . . . . . . . . . . . . . . 4 3.2. BIERv6 for Data Center . . . . . . . . . . . . . . . . . 4
3.3. BIERv6 for Core Networks . . . . . . . . . . . . . . . . 5 3.3. BIERv6 for Core Networks . . . . . . . . . . . . . . . . 5
3.4. Implications for BIER in SRv6 . . . . . . . . . . . . . . 5 3.4. Implications for BIER in SRv6 . . . . . . . . . . . . . . 5
4. Requirements . . . . . . . . . . . . . . . . . . . . . . . . 5 4. Requirements . . . . . . . . . . . . . . . . . . . . . . . . 5
4.1. L2 Agnostic . . . . . . . . . . . . . . . . . . . . . . . 5 4.1. L2 Agnostic . . . . . . . . . . . . . . . . . . . . . . . 5
4.2. Hop by hop DA modification . . . . . . . . . . . . . . . 5 4.2. Hop by hop SA modification . . . . . . . . . . . . . . . 5
4.3. L4 Inspection . . . . . . . . . . . . . . . . . . . . . . 6 4.3. L4 Inspection . . . . . . . . . . . . . . . . . . . . . . 6
4.4. Multicast address in SA field . . . . . . . . . . . . . . 6 4.4. Multicast address in SA field . . . . . . . . . . . . . . 6
4.5. Incorrect bits . . . . . . . . . . . . . . . . . . . . . 6 4.5. Incorrect bits . . . . . . . . . . . . . . . . . . . . . 7
4.6. SA filtering . . . . . . . . . . . . . . . . . . . . . . 6 4.6. SA filtering . . . . . . . . . . . . . . . . . . . . . . 7
4.7. BIER architecture support . . . . . . . . . . . . . . . . 6 4.7. BIER architecture support . . . . . . . . . . . . . . . . 7
4.8. Keep it simple . . . . . . . . . . . . . . . . . . . . . 7 4.8. Simple Encapsulation . . . . . . . . . . . . . . . . . . 7
4.9. Hardware fast path . . . . . . . . . . . . . . . . . . . 7 4.9. Hardware fast path . . . . . . . . . . . . . . . . . . . 7
5. Solutions Evaluation . . . . . . . . . . . . . . . . . . . . 7 4.10. Conform to existing IPv6 Spec . . . . . . . . . . . . . . 8
5.1. BIER-ETH encapsulation in IPv6 networks . . . . . . . . . 7 4.11. Support Fragmentation . . . . . . . . . . . . . . . . . . 8
5.2. Encode Bitstring in IPv6 destination address . . . . . . 8 4.12. Support IPv6 Security . . . . . . . . . . . . . . . . . . 8
5.3. Add BIER header into IPv6 Extension Header . . . . . . . 9 5. Solutions Evaluation . . . . . . . . . . . . . . . . . . . . 8
5.4. Transport BIER as IPv6 payload . . . . . . . . . . . . . 10 5.1. BIER-ETH encapsulation in IPv6 networks . . . . . . . . . 8
5.5. Tunneling BIER in a IPv6 tunnel . . . . . . . . . . . . . 10 5.2. Encode Bitstring in IPv6 destination address . . . . . . 10
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11 5.3. Add BIER header into IPv6 Extension Header . . . . . . . 10
7. Security Considerations . . . . . . . . . . . . . . . . . . . 11 5.4. Transport BIER as IPv6 payload . . . . . . . . . . . . . 11
8. Acknowledgement . . . . . . . . . . . . . . . . . . . . . . . 11 5.5. Tunneling BIER in a IPv6 tunnel . . . . . . . . . . . . . 12
9. Normative References . . . . . . . . . . . . . . . . . . . . 12 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 13 7. Security Considerations . . . . . . . . . . . . . . . . . . . 12
8. Acknowledgement . . . . . . . . . . . . . . . . . . . . . . . 13
9. Normative References . . . . . . . . . . . . . . . . . . . . 13
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 14
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 per-flow state, through the use of a intermediate routers to maintain per-flow state, through the use of a
multicast-specific BIER header. [RFC8296] defines two types of BIER multicast-specific BIER header. [RFC8296] defines two types of BIER
encapsulation to run on physical links: one is BIER MPLS encapsulation to run on physical links: one is BIER MPLS
encapsulation to run on various physical links that support MPLS, the encapsulation to run on various physical links that support MPLS, the
other is non-MPLS BIER Ethernet encapsulation to run on ethernet other is non-MPLS BIER Ethernet encapsulation to run on ethernet
links, with an ethertype 0xAB37. This document describes using BIER links, with an ethertype 0xAB37. This document describes using BIER
in non-MPLS IPv6 environments. We explain the requirements of in non-MPLS IPv6 environments. We explain the requirements of
transporting IPv4/IPv6 multicast payloads, from an IPv6 router (BFIR) transporting IPv4/IPv6 multicast payloads, from an IPv6 router (BFIR)
to multicast IPv6 destinations (BFERs), using BIER. This can include to multicast IPv6 destinations (BFERs), using BIER. This can include
native IPv6 encapsulation and generic tunneling. The goal of this native IPv6 encapsulation and generic tunneling. Native IPv6, in
document is to help the BIER WG evaluate the BIER v6 requirements and this document, is defined as BIER not encapsulated in mpls or
solutions. ethernet. The goal of this document is to help the BIER WG evaluate
the BIER v6 requirements and solutions in order to begin adopting
solution drafts.
1.1. Requirements Language 1.1. Requirements Language
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", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in RFC 2119 [RFC2119]. document are to be interpreted as described in RFC 2119 [RFC2119].
1.2. Terminology 1.2. Terminology
o BIER: Bit Index Explicit Replication. Provides optimal multicast o BIER: Bit Index Explicit Replication. Provides optimal multicast
forwarding through adding a BIER header and removing state in forwarding through adding a BIER header and removing state in
intermediate routers. intermediate routers.
o BUM: Broadcast, Unknown Unicast, Multicast. Term used to describe o BUM: Broadcast, Unknown Unicast, Multicast. Term used to describe
the three types of Ethernet modes that will be forwarded to the three types of Ethernet modes that will be forwarded to
multiple destinations multiple destinations
2. Problem Statement 2. Problem Statement
The problem is the ability of the network to transport BUM packets, The problem is the ability of the network to transport BUM packets,
with BIER headers, in an IPv6 environment. In an IPv6 network, many with BIER headers, in an IPv6 environment. In IPv6 networks, many
deployments consider using a non-MPLS encapsulation for unicast as deployments use non-MPLS encapsulation for unicast as the data-plane.
the data-plane. In such case, it may be expected to have a BIER IPv6 In such case, it may be expected to have a BIER IPv6 encapsulation
encapsulation which is compliant with various kinds of physical which is compliant with various kinds of physical links, perhaps in a
links, perhaps in a hop-by-hop manner, and maintain the benefit of hop-by-hop manner, and maintain the benefit of "fast reroute" of an
"fast reroute" of an IPv6 tunnel. Evaluating the BIER IPv6 IPv6 tunnel. Evaluating the BIER IPv6 requirements will help
requirements will help determine the best solutions to address these determine the best solutions to address these problems.
problems.
3. BIER IPv6 Scenario's 3. BIER IPv6 Scenario's
+--------------------------------------------+ +--------------------------------------------+
| | | |
| +------+ | +------+
| | BFER | | | BFER |
+------+ IPv6 +------+ +------+ IPv6 +------+
| BFIR | | | BFIR | |
+------+ Network +------+ +------+ Network +------+
| | BFER | | | BFER |
| +------+ | +------+
| | | |
skipping to change at page 5, line 30 skipping to change at page 5, line 30
The Source Packet Routing in Networking (SPRING) architecture The Source Packet Routing in Networking (SPRING) architecture
describes how Segment Routing can be used to steer packets through an describes how Segment Routing can be used to steer packets through an
IPv6 or MPLS network using the source routing paradigm. [RFC8354] IPv6 or MPLS network using the source routing paradigm. [RFC8354]
focuses on use cases for Segment Routing in an IPv6 only environment, focuses on use cases for Segment Routing in an IPv6 only environment,
something which is equially important for BIER in an IPv6 only something which is equially important for BIER in an IPv6 only
environment. environment.
4. Requirements 4. Requirements
There have been several suggested requirements, on the BIER email There have been several suggested requirements, on the BIER email
list, which we will use to form the BIER IPv6 requirements and to list and in meetings, which have been used to form BIER IPv6
help evaluate the proposed solutions: requirements used to help the wg evaluate against the proposed
solutions:
4.1. L2 Agnostic 4.1. L2 Agnostic
The solution should be agnostic to the underlying L2 data link type. The solution should be agnostic to the underlying L2 data link type.
4.2. Hop by hop DA modification 4.2. Hop by hop SA modification
The solution should not require hop-by-hop modification of the IP The solution should not require hop-by-hop modification of the IP
destination address field. source address field.
A multicast packet whose DA is multicast address does not require DA
modification hop by hop when replicating the packet to the nexthop
BFR.
An anycast packet whose DA is an anycast address configured on each Solutions that do not require Hop-by-hop SA modification are
BFRs in the domain may be another option does not require DA preferred. Solutions which maintain the SA will help fast-path
modification when replicating the packet to the nexthop BFR. forwarding (req 4.9 in this doc), are beneficial for receiving
notices from the BFIR for functions like BIER PING, TRACE and MTU
notification, are beneficial for identifying an MVPN instance to help
remove more encapsulation such as Service Label (such as MPLS VPN
Label or VNI in the SRv6 network), and are beneficial for SA
filtering (req 4.6 in this doc).
It is common to get the impression that BIERv6 could use multicast It is commonly thought that BIERv6 could use a multicast address, as
address, as BIER is kind of one-hop replication on each BFR in normal BIER is one-hop replication on each BFR in normal cases. However, as
cases. However, as described in section 6.9 of [RFC8279], it is described in section 6.9 of [RFC8279], it is useful to support non-
useful to support Non-BIER routers within a BIER domain. From the BIER routers within a BIER domain. From the wg discussion about this
discussion about this document on IETF104, focus is on the advantages document, focus is on the advantages of using unicast addresses that
of using unicast address that otherwise could not possible by using otherwise could not be possible by using a multicast address or
multicast address or anycast address for the two cases: replication anycast address for two cases: replication from a BFR to other BFR(s)
from a BFR to other BFR(s) connected by Layer-3 Non-BFR router(s) connected by Layer-3 Non-BFR router(s) without using tunneling
without using tunneling techniques, and replication from a BFR to techniques, and replication from a BFR to other BFR(s) connected by
other BFR(s) connected by Layer-2 switch(es) without broadcasting or Layer-2 switch(es) without broadcasting or snooping on Layer-2
snooping on Layer-2 switch(es) in between. Based on the natural switch(es) in between. Based on the natural reachability of an IPv6
reachability of an IPv6 unicast address, it can support the multi-hop unicast address, it can support the multi-hop replication cases as
replication cases as well as the one-hop replication case. well as the one-hop replication case.
This requirement may be deprecated if unicast address is prefered as This requirement may be deprecated if unicast address is prefered as
a solution for both multi-hop replication and one-hop replication a solution for both multi-hop replication and one-hop replication
without using two different encapsulations. without using two different encapsulations.
4.3. L4 Inspection 4.3. L4 Inspection
The solution should not require the BFRs to inspect layer 4 or The solution should not require the BFRs to inspect layer 4 or
require any changes to layer 4. require any changes to layer 4.
In fragmentation events, BIER is payload and will be fragmented. For
instance (BIER-header + payload-1-to-1xxx bytes) in one packet, and
(payload-1xxx-to-2xxx) in another packet. Thus, when BFR B receives
a packet from BFR A, BFR B has to assemble the fragmented packets
before sending to BFR C and BFR D.
In IPSEC, the BIER header is part of the payload for confidentiality
or integrity. The need to change the BitString in the BIER Header,
when forwarding BIER packets, makes it incompatible with IPSEC.
In SRH, BIER is the payload, and will be reached only after the SRH
is processed. Thus, when BFR B receive a packet with SRH from BFR A,
BFR B has to process the SRH first, and then the Upper-layer BIER
header last. SRH needs to be integrated for two reasons, first is
that the solution is targetted to work well in SRv6 networks as a use
case in section 3.4 of this doc, second reason is that a few of the
proposed solutions agree to consider SRH integration.
4.4. Multicast address in SA field 4.4. Multicast address in SA field
The solution should not allow a multicast address to be put in the IP The solution should not allow a multicast address to be put in the IP
source address field. source address field. According to [RFC1112] "A host group address
must never be placed in the source address field or anywhere in a
source route or record route option of an outgoing IP datagram."
4.5. Incorrect bits 4.5. Incorrect bits
The solution should not assume that bits never get set incorrectly. The solution should not assume that bits never get set incorrectly.
If a packet with incorrect bits set, it should not damage the If a packet with incorrect bits is set, it should not damage BIERv6
functions like Unicast Reverse Path Forwarding (URPF), or cause loops functionality or any other functions such as Unicast Reverse Path
or duplicates as described in section 6.8 of [RFC8279]. Forwarding (URPF), nor should it cause loops or duplicates as
described in section 6.8 of [RFC8279].
4.6. SA filtering 4.6. SA filtering
The solution should not require changes in source address filtering The solution should not require changes in source address filtering
procedures. procedures. For instance if a host uses a "BIER address" as its
source address in a given packet, and the packet doesn't get dropped
according to existing SA filtering procedures, the packet may elicit
responses that put the BIER address in their destination address
fields. This could be a security issue, as it creates an attack
vector that can create 64 responses to a single probe.
4.7. BIER architecture support 4.7. BIER architecture support
The solution should be possible to be used to support the entire BIER It should be possible to use the solution to support the entire BIER
architecture. architecture. The ability to bypass Non-BIER routers and L2 switches
is part of the BIER architecture and having this ability is a
mandatory requirement.
Multiple sub-domains bound to one or many topologies or algorithms, Multiple sub-domains bound to one or many topologies or algorithms,
multiple sets for more BFERs, multiple BIFTs for ECMP should be multiple sets for more BFERs, BS multiple BIFTs for ECMP should be
supported. supported.
4.8. Keep it simple 4.8. Simple Encapsulation
The solution should avoid having to use different encapsulation The solution should avoid requiring different encapsulation types, or
types, or use complex tunneling techniques, to support BIER as a E2E complex tunneling techniques, to support BIER as an E2E multicast
multicast transport. transport.
A single encapsulation should support Layer-2 switch within BFRs, or A single encapsulation should support Layer-2 switches within BFRs,
non-BFR within a BIER domain, or inter-domain deployment of BIER. or non-BFR within a BIER domain, or inter-domain deployment of BIER.
4.9. Hardware fast path 4.9. Hardware fast path
The solution should enable the processing and forwarding of BIER The solution should enable the processing and forwarding of BIER
packets in hardware fast path. packets in hardware fast path.
4.10. Conform to existing IPv6 Spec
The proposed encapsulation must conform to the IPv6 specification and
guidelines as described in RFC8200. It should not require any new
modifications to the IPv6 specification aside from extensions to
existing mechanisms such as IPv6 Options.
4.11. Support Fragmentation
The proposed encapsulation must support fragmentation. It shouldn't
require fragmentation and re-assembly at each hop.
4.12. Support IPv6 Security
The proposed encapsulation should support IPv6 security including AH/
ESP extension headers. It shouldn't require hop-by-hop encryption/
decryption.
5. Solutions Evaluation 5. Solutions Evaluation
The following are solutions that have been proposed to solve BIER in The following are solutions that have been proposed to solve BIER in
IPv6 environments. IPv6 environments. Some solutions propose encoding while others
propose encapsulation. It is recommended for the wg to evaluate
these solutions against the requirements listed previously in order
to make informed decisions on solution readiness.
As illustrated in these examples, the BIER header, or the BitString, As illustrated in these examples, the BIER header, or the BitString,
may appear in the IPv6 Header, IPv6 Extension Header, IPv6 Payload, may appear in the IPv6 Header, IPv6 Extension Header, IPv6 Payload,
or IPv6 Tunnel Packet: or IPv6 Tunnel Packet:
5.1. BIER-ETH encapsulation in IPv6 networks 5.1. BIER-ETH encapsulation in IPv6 networks
+---------------+-----------------+------------------- +---------------+-----------------+-------------------
| Ethernet | BIER header | payload | Ethernet | BIER header | payload
| (ethType = | (BIFT-id, ...) | | (ethType = | (BIFT-id, ...) |
skipping to change at page 12, line 13 skipping to change at page 13, line 18
bier wg list. bier wg list.
9. Normative References 9. Normative References
[I-D.pfister-bier-over-ipv6] [I-D.pfister-bier-over-ipv6]
Pfister, P. and I. Wijnands, "An IPv6 based BIER Pfister, P. and I. Wijnands, "An IPv6 based BIER
Encapsulation and Encoding", draft-pfister-bier-over- Encapsulation and Encoding", draft-pfister-bier-over-
ipv6-01 (work in progress), October 2016. ipv6-01 (work in progress), October 2016.
[I-D.xie-bier-ipv6-encapsulation] [I-D.xie-bier-ipv6-encapsulation]
Xie, J., Geng, L., McBride, M., Dhanaraj, S., Yan, G., and Xie, J., Geng, L., McBride, M., Asati, R., and S.
Y. Xia, "Encapsulation for BIER in Non-MPLS IPv6 Dhanaraj, "Encapsulation for BIER in Non-MPLS IPv6
Networks", draft-xie-bier-ipv6-encapsulation-01 (work in Networks", draft-xie-bier-ipv6-encapsulation-03 (work in
progress), June 2019. progress), July 2019.
[I-D.xu-bier-encapsulation] [I-D.xu-bier-encapsulation]
Xu, X., somasundaram.s@alcatel-lucent.com, s., Jacquenet, Xu, X., somasundaram.s@alcatel-lucent.com, s., Jacquenet,
C., Raszuk, R., and Z. Zhang, "A Transport-Independent Bit C., Raszuk, R., and Z. Zhang, "A Transport-Independent Bit
Index Explicit Replication (BIER) Encapsulation Header", Index Explicit Replication (BIER) Encapsulation Header",
draft-xu-bier-encapsulation-06 (work in progress), draft-xu-bier-encapsulation-06 (work in progress),
September 2016. September 2016.
[I-D.zhang-bier-bierin6] [I-D.zhang-bier-bierin6]
Zhang, Z. and T. Przygienda, "BIER in IPv6", draft-zhang- Zhang, Z., Przygienda, T., Wijnands, I., Bidgoli, H., and
bier-bierin6-02 (work in progress), October 2018. M. McBride, "BIER in IPv6 (BIERin6)", draft-zhang-bier-
bierin6-03 (work in progress), July 2019.
[RFC1112] Deering, S., "Host extensions for IP multicasting", STD 5,
RFC 1112, DOI 10.17487/RFC1112, August 1989,
<https://www.rfc-editor.org/info/rfc1112>.
[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>.
[RFC2473] Conta, A. and S. Deering, "Generic Packet Tunneling in [RFC2473] Conta, A. and S. Deering, "Generic Packet Tunneling in
IPv6 Specification", RFC 2473, DOI 10.17487/RFC2473, IPv6 Specification", RFC 2473, DOI 10.17487/RFC2473,
December 1998, <https://www.rfc-editor.org/info/rfc2473>. December 1998, <https://www.rfc-editor.org/info/rfc2473>.
 End of changes. 31 change blocks. 
88 lines changed or deleted 151 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/