| < draft-vyncke-v6ops-james-00.txt | draft-vyncke-v6ops-james-01.txt > | |||
|---|---|---|---|---|
| IPv6 Operations E. Vyncke | IPv6 Operations É. Vyncke | |||
| Internet-Draft Cisco | Internet-Draft Cisco | |||
| Intended status: Informational R. Léas | Intended status: Informational R. Léas | |||
| Expires: 5 September 2022 J. Iurman | Expires: 21 September 2022 J. Iurman | |||
| Université de Liège | Université de Liège | |||
| 4 March 2022 | 20 March 2022 | |||
| Just Another Measurement of Extension header Survivability (JAMES) | Just Another Measurement of Extension header Survivability (JAMES) | |||
| draft-vyncke-v6ops-james-00 | draft-vyncke-v6ops-james-01 | |||
| Abstract | Abstract | |||
| In 2016, [RFC7872] has measured the drop of packets with IPv6 | In 2016, RFC7872 has measured the drop of packets with IPv6 extension | |||
| extension headers. This document presents a slightly different | headers. This document presents a slightly different methodology | |||
| methodology with more recent results. It is still work in progress. | with more recent results. It is still work in progress. | |||
| About This Document | About This Document | |||
| This note is to be removed before publishing as an RFC. | This note is to be removed before publishing as an RFC. | |||
| The latest revision of this draft can be found at | The latest revision of this draft can be found at | |||
| https://evyncke.github.io/v6ops-james/draft-vyncke-v6ops-james.html. | https://evyncke.github.io/v6ops-james/draft-vyncke-v6ops-james.html. | |||
| Status information for this document may be found at | Status information for this document may be found at | |||
| https://datatracker.ietf.org/doc/draft-vyncke-v6ops-james/. | https://datatracker.ietf.org/doc/draft-vyncke-v6ops-james/. | |||
| skipping to change at page 2, line 4 ¶ | skipping to change at page 2, line 4 ¶ | |||
| 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 5 September 2022. | This Internet-Draft will expire on 21 September 2022. | |||
| Copyright Notice | Copyright Notice | |||
| Copyright (c) 2022 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 (https://trustee.ietf.org/ | Provisions Relating to IETF Documents (https://trustee.ietf.org/ | |||
| license-info) in effect on the date of publication of this document. | license-info) in effect on the date of publication of this document. | |||
| Please review these documents carefully, as they describe your rights | Please review these documents carefully, as they describe your rights | |||
| and restrictions with respect to this document. Code Components | and restrictions with respect to this document. Code Components | |||
| extracted from this document must include Revised BSD License text as | extracted from this document must include Revised BSD License text as | |||
| described in Section 4.e of the Trust Legal Provisions and are | described in Section 4.e of the Trust Legal Provisions and are | |||
| provided without warranty as described in the Revised BSD License. | provided without warranty as described in the Revised BSD License. | |||
| Table of Contents | Table of Contents | |||
| 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 | 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 | |||
| 2. Methodology . . . . . . . . . . . . . . . . . . . . . . . . . 3 | 2. Methodology . . . . . . . . . . . . . . . . . . . . . . . . . 3 | |||
| 3. Measurements . . . . . . . . . . . . . . . . . . . . . . . . 3 | 3. Measurements . . . . . . . . . . . . . . . . . . . . . . . . 3 | |||
| 3.1. Vantage Points . . . . . . . . . . . . . . . . . . . . . 3 | 3.1. Vantage Points . . . . . . . . . . . . . . . . . . . . . 3 | |||
| 3.1.1. Tested Autonomous Systems . . . . . . . . . . . . . . 4 | 3.2. Tested Autonomous Systems . . . . . . . . . . . . . . . . 4 | |||
| 3.1.2. Tested Extension Headers . . . . . . . . . . . . . . 6 | 3.2.1. Drop attribution to AS . . . . . . . . . . . . . . . 6 | |||
| 3.1.3. Drop attribution to AS . . . . . . . . . . . . . . . 7 | 3.3. Tested Extension Headers . . . . . . . . . . . . . . . . 7 | |||
| 3.2. Results . . . . . . . . . . . . . . . . . . . . . . . . . 8 | 4. Results . . . . . . . . . . . . . . . . . . . . . . . . . . . 8 | |||
| 3.2.1. Routing Header . . . . . . . . . . . . . . . . . . . 8 | 4.1. Routing Header . . . . . . . . . . . . . . . . . . . . . 8 | |||
| 3.2.2. Hop-by-Hop Options Headers . . . . . . . . . . . . . 9 | 4.2. Hop-by-Hop Options Header . . . . . . . . . . . . . . . . 9 | |||
| 3.2.3. Destination Options Headers . . . . . . . . . . . . . 10 | 4.3. Destination Options Header . . . . . . . . . . . . . . . 10 | |||
| 3.2.4. Fragmentation Header . . . . . . . . . . . . . . . . 11 | 4.4. Fragmentation Header . . . . . . . . . . . . . . . . . . 11 | |||
| 3.2.5. No drop at all . . . . . . . . . . . . . . . . . . . 11 | 4.5. No extension headers drop at all . . . . . . . . . . . . 12 | |||
| 3.3. Summary of the collaborating parties measurements . . . . 12 | 4.6. Special Next Headers . . . . . . . . . . . . . . . . . . 13 | |||
| 4. Security Considerations . . . . . . . . . . . . . . . . . . . 12 | 5. Summary of the collaborating parties measurements . . . . . . 13 | |||
| 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13 | 6. Security Considerations . . . . . . . . . . . . . . . . . . . 14 | |||
| 6. References . . . . . . . . . . . . . . . . . . . . . . . . . 13 | 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 14 | |||
| 6.1. Normative References . . . . . . . . . . . . . . . . . . 13 | 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 14 | |||
| 6.2. Informative References . . . . . . . . . . . . . . . . . 13 | 8.1. Normative References . . . . . . . . . . . . . . . . . . 14 | |||
| Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 15 | 8.2. Informative References . . . . . . . . . . . . . . . . . 14 | |||
| Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 15 | Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 16 | |||
| Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 16 | ||||
| 1. Introduction | 1. Introduction | |||
| In 2016, [RFC7872] has measured the drop of packets with IPv6 | In 2016, [RFC7872] has measured the drop of packets with IPv6 | |||
| extension headers on their transit over the global Internet. This | extension headers on their transit over the global Internet. This | |||
| document presents a slightly different methodology with more recent | document presents a slightly different methodology with more recent | |||
| results. Since then, [I-D.draft-ietf-opsec-ipv6-eh-filtering] has | results. Since then, [I-D.draft-ietf-opsec-ipv6-eh-filtering] has | |||
| provided some recommendations for filtering transit traffic, there | provided some recommendations for filtering transit traffic, so there | |||
| may be some changes in providers policies. | may be some changes in providers policies. | |||
| It is still work in progress, but the authors wanted to present some | It is still work in progress, but the authors wanted to present some | |||
| results at IETF-113 (March 2022). | results at IETF-113 (March 2022). The code is open source and is | |||
| available at [GITHUB]. | ||||
| 2. Methodology | 2. Methodology | |||
| In a first phase, the measurement is done between collaborating IPv6 | In a first phase, the measurement is done between collaborating IPv6 | |||
| nodes, a.k.a. vantage points, spread over the Internet and multiple | nodes, a.k.a. vantage points, spread over the Internet and multiple | |||
| Autonomous Systems (ASs). As seen in Section 3.1.1, the | Autonomous Systems (ASs). As seen in Section 3.2, the | |||
| source/destination/transit ASs include some "tier-1" providers per | source/destination/transit ASs include some "tier-1" providers per | |||
| [TIER1], so, they are probably representative of the global Internet | [TIER1], so, they are probably representative of the global Internet | |||
| core. | core. | |||
| Relying on collaborating nodes has some benefits: | Relying on collaborating nodes has some benefits: | |||
| * propagation can be measured even in the absence of any ICMP | * propagation can be measured even in the absence of any ICMP | |||
| message or reply generated by the destination; | message or reply generated by the destination; | |||
| * traffic timing can be measured accurately to answer whether | * traffic timing can be measured accurately to answer whether | |||
| skipping to change at page 3, line 39 ¶ | skipping to change at page 3, line 49 ¶ | |||
| reduced probing speed. The destination will include [ALEXA] top-n | reduced probing speed. The destination will include [ALEXA] top-n | |||
| websites, popular CDN, as well as random prefix from the IPv6 global | websites, popular CDN, as well as random prefix from the IPv6 global | |||
| routing table. A revision of this IETF draft will describe those | routing table. A revision of this IETF draft will describe those | |||
| experiments. | experiments. | |||
| 3. Measurements | 3. Measurements | |||
| 3.1. Vantage Points | 3.1. Vantage Points | |||
| Several servers were used worldwide (albeit missing Africa and China | Several servers were used worldwide (albeit missing Africa and China | |||
| as authors were unable to find IPv6 servers in these regions). | as the authors were unable to find IPv6 servers in these regions). | |||
| Table 1 lists all the vantage points together with their AS number | Table 1 lists all the vantage points together with their AS number | |||
| and country. | and country. | |||
| +========+===================+==============+===================+ | +========+===================+==============+===================+ | |||
| | ASN | AS Name | Country code | Location | | | ASN | AS Name | Country code | Location | | |||
| +========+===================+==============+===================+ | +========+===================+==============+===================+ | |||
| | 7195 | Edge Uno | AG | Buenos Aires | | | 7195 | Edge Uno | AG | Buenos Aires | | |||
| +--------+-------------------+--------------+-------------------+ | +--------+-------------------+--------------+-------------------+ | |||
| | 12414 | NL-SOLCON SOLCON | NL | Amsterdam | | | 12414 | NL-SOLCON SOLCON | NL | Amsterdam | | |||
| +--------+-------------------+--------------+-------------------+ | +--------+-------------------+--------------+-------------------+ | |||
| skipping to change at page 4, line 37 ¶ | skipping to change at page 4, line 37 ¶ | |||
| +--------+-------------------+--------------+-------------------+ | +--------+-------------------+--------------+-------------------+ | |||
| | 47853 | Hostinger | US | Ashville, NC | | | 47853 | Hostinger | US | Ashville, NC | | |||
| +--------+-------------------+--------------+-------------------+ | +--------+-------------------+--------------+-------------------+ | |||
| | 60011 | MYTHIC-BEASTS-USA | US | Fremont, CA | | | 60011 | MYTHIC-BEASTS-USA | US | Fremont, CA | | |||
| +--------+-------------------+--------------+-------------------+ | +--------+-------------------+--------------+-------------------+ | |||
| | 198644 | GO6 | SI | Ljubljana | | | 198644 | GO6 | SI | Ljubljana | | |||
| +--------+-------------------+--------------+-------------------+ | +--------+-------------------+--------------+-------------------+ | |||
| Table 1: All vantage AS | Table 1: All vantage AS | |||
| 3.1.1. Tested Autonomous Systems | 3.2. Tested Autonomous Systems | |||
| During first phase (traffic among fully meshed collaborative nodes), | During first phase (traffic among fully-meshed collaborative nodes), | |||
| our probes have collected data on the following ASs: | Table 2 show the ASs for which our probes have collected data. | |||
| +===========+======================================+==========+ | +===========+======================================+==========+ | |||
| | AS Number | AS Description | Comment | | | AS Number | AS Description | Comment | | |||
| +===========+======================================+==========+ | +===========+======================================+==========+ | |||
| | 174 | COGENT-174, US | Tier-1 | | | 174 | COGENT-174, US | Tier-1 | | |||
| +-----------+--------------------------------------+----------+ | +-----------+--------------------------------------+----------+ | |||
| | 1299 | TWELVE99 Twelve99, Telia Carrier, SE | Tier-1 | | | 1299 | TWELVE99 Twelve99, Telia Carrier, SE | Tier-1 | | |||
| +-----------+--------------------------------------+----------+ | +-----------+--------------------------------------+----------+ | |||
| | 2914 | NTT-COMMUNICATIONS-2914, US | Tier-1 | | | 2914 | NTT-COMMUNICATIONS-2914, US | Tier-1 | | |||
| +-----------+--------------------------------------+----------+ | +-----------+--------------------------------------+----------+ | |||
| skipping to change at page 6, line 16 ¶ | skipping to change at page 6, line 16 ¶ | |||
| Wikipedia page [TIER1], but there is no common way to decide who is a | Wikipedia page [TIER1], but there is no common way to decide who is a | |||
| tier-1. Based on some CAIDA research, all the above (except GO6, | tier-1. Based on some CAIDA research, all the above (except GO6, | |||
| which is a stub network) are transit providers. | which is a stub network) are transit providers. | |||
| While this document lists some operators, the intent is not to build | While this document lists some operators, the intent is not to build | |||
| a wall of fame or a wall of shame but more to get an idea about which | a wall of fame or a wall of shame but more to get an idea about which | |||
| kind of providers drop packets with extension headers and how | kind of providers drop packets with extension headers and how | |||
| widespread the drop policy is enforced and where, i.e., in the access | widespread the drop policy is enforced and where, i.e., in the access | |||
| provider or in the core of the Internet. | provider or in the core of the Internet. | |||
| 3.1.2. Tested Extension Headers | 3.2.1. Drop attribution to AS | |||
| Comparing the traceroutes with and without extension headers allows | ||||
| the attribution of a packet drop to one AS. But, this is not an easy | ||||
| task as inter-AS links often use IPv6 address of only one AS (if not | ||||
| using link-local per [RFC7704]). This document uses the following | ||||
| algorithm to attribute the drop to one AS for packet sourced in one | ||||
| AS and then having a path traversing AS#foo just before AS#bar: | ||||
| * if the packet drop happens at the first router (i.e., hop limit == | ||||
| 1 does not trigger an ICMP hop-limit exceeded), then the drop is | ||||
| assumed to this AS as it is probably an ingress filter on the | ||||
| first router (i.e., the hosting provider in most of the cases - | ||||
| except if collocated with an IXP). | ||||
| * if the packet drop happens in AS#foo after one or more hop(s) in | ||||
| AS#bar, then the drop is assumed to be in AS#foo ingress filter on | ||||
| a router with an interface address in AS#foo | ||||
| * if the packet drop happens in AS#bar after one or more hop(s) in | ||||
| AS#bar before going to AS#foo, then the drop is assumed to be in | ||||
| AS#foo ingress filter on a router with an interface address in | ||||
| AS#bar | ||||
| In several cases, the above algorithm was not possible (e.g., some | ||||
| intermediate routers do not generate an ICMP unreachable hop limit | ||||
| exceeded even in the absence of any extension headers), then the drop | ||||
| is not attributed. Please also note that the goal of this document | ||||
| is not to 'point fingers to operators' but more to evaluate the | ||||
| potential impact. I.e., a tier-1 provider dropping packets with | ||||
| extension headers has a much bigger impact on the Internet traffic | ||||
| than an access provider. | ||||
| Future revision of this document will use the work of [MLAT_PEERING]. | ||||
| 3.3. Tested Extension Headers | ||||
| In the first phase among collaborating vantage points, packets always | In the first phase among collaborating vantage points, packets always | |||
| contained either a UDP payload or a TCP payload, the latter is sent | contained either a UDP payload or a TCP payload, the latter is sent | |||
| with only the SYN flag set and with data as permitted by section 3.4 | with only the SYN flag set and with data as permitted by section 3.4 | |||
| of [RFC793] (2nd paragraph). A usual traceroute is done with only | of [RFC793] (2nd paragraph). A usual traceroute is done with only | |||
| the UDP/TCP payload without any extension header with varying hop- | the UDP/TCP payload without any extension header with varying hop- | |||
| limit in order to learn the traversed routers and ASs. Then, several | limit in order to learn the traversed routers and ASs. Then, several | |||
| UDP/TCP probes are sent with a set of extension headers: | UDP/TCP probes are sent with a set of extension headers: | |||
| * hop-by-hop and destination options header containing: | * hop-by-hop and destination options header containing: | |||
| - one PadN option for an extension header length of 8 octets, | - one PadN option for an extension header length of 8 octets, | |||
| - one unknown option with the "discard" bits for an extension | - one unknown option with the "discard" bits for an extension | |||
| header length of 8 octets, | header length of 8 octets, | |||
| - several PaDN options for an extension header length of 256 | - multiple PadN options for an extension header length of 256 | |||
| octets, | octets, | |||
| - one unknown option (two sets with "discard" and "skip" bits) | - one unknown option (two sets with "discard" and "skip" bits) | |||
| for an extension header length of 256 octets, | for the destination options header length of 16, 32, 64, and | |||
| 128 octets, | ||||
| - one unknown option (two sets with "discard" and "skip" bits) | - one unknown option (two sets with "discard" and "skip" bits) | |||
| for an extension header length of 512 octets. | for an extension header length of 256 and 512 octets. | |||
| * routing header with routing types from 0 to 6 inclusive (except | * routing header with routing types from 0 to 6 inclusive; | |||
| for type 3); | ||||
| * atomic fragment header (i.e., M-flag = 0 and offset = 0) of | * atomic fragment header (i.e., M-flag = 0 and offset = 0) of | |||
| varying frame length 512, 1280, and 1500 octets; | varying frame length 512, 1280, and 1500 octets; | |||
| * non-atomic first fragment header (i.e., M-flag = 1 and offset = 0) | * non-atomic first fragment header (i.e., M-flag = 1 and offset = 0) | |||
| of varying frame length 512, 1280, and 1500 octets; | of varying frame length 512, 1280, and 1500 octets; | |||
| * authentication header with dummy SPI followed by UDP/TCP header | * authentication header with dummy SPI followed by UDP/TCP header | |||
| and a 38 octets payload. | and a 38 octets payload. | |||
| In the above, length is the length of the extension header itself | In the above, length is the length of the extension header itself | |||
| except for the fragmentation header where the length is the IP packet | except for the fragmentation header where the length is the IP packet | |||
| length (i.e., including the IPv6, and TCP/UDP headers + payload). | length (i.e., including the IPv6, and TCP/UDP headers + payload). | |||
| For hop-by-hop and destination options headers, when required | For hop-by-hop and destination options headers, when required | |||
| multiple PadN options were used in order to bypass some Linux kernels | multiple PadN options were used in order to bypass some Linux kernels | |||
| that consider a PadN larger than 8 bytes is an attack, see section | that consider a PadN larger than 8 bytes is an attack, see section | |||
| 5.3 of [BCP220], even if multiple PadN options violates section | 5.3 of [BCP220], even if multiple PadN options violates section | |||
| 2.1.9.5 of [RFC4942]. | 2.1.9.5 of [RFC4942]. | |||
| Next phases will also include packets without UDP/TCP transport | In addition to the above extension headers, other probes were sent | |||
| header but with Next-Header being: | with next header field of IPv6 header set to: | |||
| * 59, "no next header" see section 4.7 of [RFC8200]; | ||||
| * 143, "ethernet" see section 4.9 of [RFC8986]. | ||||
| 3.1.3. Drop attribution to AS | ||||
| Comparing the traceroutes with and without extension headers allows | ||||
| the attribution of a packet drop to one AS. But, this is not an easy | ||||
| task as inter-AS links often use IPv6 address of only one AS (if not | ||||
| using link-local per [RFC7704]). This document uses the following | ||||
| algorithm to attribute the drop to one AS for packet sourced in one | ||||
| AS and then having a path traversing AS#foo just before AS#bar: | ||||
| * if the packet drop happens at the first router (i.e., hop limit == | ||||
| 1 does not trigger an ICMP hop-limit exceeded), then the drop is | ||||
| assumed to this AS as it is probably an ingress filter on the | ||||
| first router (i.e., the hosting provider in most of the cases - | ||||
| except if collocated with an IXP). | ||||
| * if the packet drop happens in AS#foo after one or more hop(s) in | ||||
| AS#bar, then the drop is assumed to be in AS#foo ingress filter on | ||||
| a router with an interface address in AS#foo | ||||
| * if the packet drop happens in AS#bar after one or more hop(s) in | ||||
| AS#bar before going to AS#foo, then the drop is assumed to be in | ||||
| AS#foo ingress filter on a router with an interface address in | ||||
| AS#bar | ||||
| In several cases, the above algorithm was not possible (e.g., some | * 59, which is "no next header", especially whether extra octets | |||
| intermediate routers do not generate an ICMP unreachable hop limit | after the no next header as section 4.7 [RFC8200] requires that | |||
| exceeded even in the absence of any extension headers), then the drop | "those octets must be ignored and passed on unchanged if the | |||
| is not attributed. Please also note that the goal of this document | packet is forwarded"; | |||
| is not to 'point fingers to operators' but more to evaluate the | ||||
| potential impact. I.e., a tier-1 provider dropping packets with | ||||
| extension headers has a much bigger impact on the Internet traffic | ||||
| than an access provider. | ||||
| Future revision of this document will use the work of [MLAT_PEERING]. | * 143, which is Ethernet payload (see section 10.1 of [RFC8986]). | |||
| 3.2. Results | 4. Results | |||
| This section presents the current results out of phase 1 | This section presents the current results out of phase 1 | |||
| (collaborating vantage points) testing. About 4860 experiments were | (collaborating vantage points) testing. About 4860 experiments were | |||
| run, one experiment being defined by sending packets between 2 | run, one experiment being defined by sending packets between 2 | |||
| vantage points with hop-limit varying from 1 to the number of hops | vantage points with hop-limit varying from 1 to the number of hops | |||
| between the two vantage points and for all the extension headers | between the two vantage points and for all the extension headers | |||
| described in Section 3.1.2. | described in Section 3.3. | |||
| 3.2.1. Routing Header | 4.1. Routing Header | |||
| The following table lists all routing header types and the percentage | Table 3 lists all routing header types and the percentage of | |||
| of experiments that were successful, i.e., packets with routing | experiments that were successful, i.e., packets with routing header | |||
| header reaching their destination: | reaching their destination: | |||
| +=====================+===========================================+ | +=====================+=======================================+ | |||
| | Routing Header Type | %-age of experiments reaching destination | | | Routing Header Type | %-age of packets reaching destination | | |||
| +=====================+===========================================+ | +=====================+=======================================+ | |||
| | 0 | 80.9% | | | 0 | 80.9% | | |||
| +---------------------+-------------------------------------------+ | +---------------------+---------------------------------------+ | |||
| | 1 | 99.5% | | | 1 | 99.5% | | |||
| +---------------------+-------------------------------------------+ | +---------------------+---------------------------------------+ | |||
| | 2 | 99.5% | | | 2 | 99.5% | | |||
| +---------------------+-------------------------------------------+ | +---------------------+---------------------------------------+ | |||
| | 3 | not tested | | | 3 | 99.5% | | |||
| +---------------------+-------------------------------------------+ | +---------------------+---------------------------------------+ | |||
| | 4 | 69.0% | | | 4 | 69.0% | | |||
| +---------------------+-------------------------------------------+ | +---------------------+---------------------------------------+ | |||
| | 5 | 99.5% | | | 5 | 99.5% | | |||
| +---------------------+-------------------------------------------+ | +---------------------+---------------------------------------+ | |||
| | 6 | 99.3% | | | 6 | 99.3% | | |||
| +---------------------+-------------------------------------------+ | +---------------------+---------------------------------------+ | |||
| Table 3 | Table 3: Per Routing Header Types Transmission | |||
| The table below lists the few ASs that drop packets with the routing | Table 4 lists the few ASs that drop packets with the routing header | |||
| header type 0 (the original source routing header, which is now | type 0 (the original source routing header, which is now deprecated). | |||
| deprecated). | ||||
| +===========+================+ | +===========+================+ | |||
| | AS Number | AS description | | | AS Number | AS description | | |||
| +===========+================+ | +===========+================+ | |||
| | 6939 | HURRICANE, US | | | 6939 | HURRICANE, US | | |||
| +-----------+----------------+ | +-----------+----------------+ | |||
| Table 4 | Table 4: AS Dropping | |||
| Routing Header Type 0 | ||||
| It is possibly due to a strict implementation of [RFC5095] but it is | It is possibly due to a strict implementation of [RFC5095] but it is | |||
| expected that no packet with routing header type 0 would be | expected that no packet with routing header type 0 would be | |||
| transmitted anymore. So, this is not surprising. | transmitted anymore. So, this is not surprising. | |||
| The table below lists the few ASs that drop packets with the routing | Table 5 lists the few ASs that drop packets with the routing header | |||
| header type 4 (Segment Routing Header [RFC8754]). | type 4 (Segment Routing Header [RFC8754]). | |||
| +===========+================+ | +===========+================+ | |||
| | AS Number | AS description | | | AS Number | AS description | | |||
| +===========+================+ | +===========+================+ | |||
| | 16276 | OVH, FR | | | 16276 | OVH, FR | | |||
| +-----------+----------------+ | +-----------+----------------+ | |||
| Table 5 | Table 5: AS Dropping | |||
| Routing Header Type 0 | ||||
| This drop of SRH was to be expected as SRv6 is specified to run only | This drop of SRH was to be expected as SRv6 is specified to run only | |||
| in a limited domain. | in a limited domain. | |||
| Other routing header types (1 == deprecated NIMROD [RFC1753], 2 == | Other routing header types (1 == deprecated NIMROD [RFC1753], 2 == | |||
| mobile IPv6 [RFC6275], and even 5 == CRH-16 and 6 == CRH- | mobile IPv6 [RFC6275], 3 == RPL [RFC6554], and even 5 == CRH-16 and 6 | |||
| 32[I-D.draft-bonica-6man-comp-rtg-hdr]) can be transmitted over the | == CRH-32[I-D.draft-bonica-6man-comp-rtg-hdr]) can be transmitted | |||
| global Internet without being dropped (assuming that the 0.5% of | over the global Internet without being dropped (assuming that the | |||
| dropped packets are within the measurement error). | 0.5% of dropped packets are within the measurement error). | |||
| 3.2.2. Hop-by-Hop Options Headers | 4.2. Hop-by-Hop Options Header | |||
| Many ASs drop packets containing either hop-by-hop options headers | Many ASs drop packets containing either hop-by-hop options headers | |||
| per table below: | per Table 6 below: | |||
| +===============+========+======================+ | +===============+========+=======================================+ | |||
| | Option Type | Length | %-age of experiments | | | Option Type | Length | %-age of packets reaching destination | | |||
| | | | reaching destination | | +===============+========+=======================================+ | |||
| +===============+========+======================+ | | Skip | 8 | 5.8% | | |||
| | Skip | 8 | 5.8% | | +---------------+--------+---------------------------------------+ | |||
| +---------------+--------+----------------------+ | | Discard | 8 | 0.0% | | |||
| | Discard | 8 | 0.0% | | +---------------+--------+---------------------------------------+ | |||
| +---------------+--------+----------------------+ | | Skip one | 256 | 1.9% | | |||
| | Skip one | 256 | 1.9% | | | large PadN | | | | |||
| | large PadN | | | | +---------------+--------+---------------------------------------+ | |||
| +---------------+--------+----------------------+ | | Skip multiple | 256 | 0.0% | | |||
| | Skip multiple | 256 | 0.0% | | | PadN | | | | |||
| | PadN | | | | +---------------+--------+---------------------------------------+ | |||
| +---------------+--------+----------------------+ | | Discard | 256 | 0.0% | | |||
| | Discard | 256 | 0.0% | | +---------------+--------+---------------------------------------+ | |||
| +---------------+--------+----------------------+ | | Skip | 512 | 1.9% | | |||
| | Skip | 512 | 1.9% | | +---------------+--------+---------------------------------------+ | |||
| +---------------+--------+----------------------+ | | Discard | 512 | 0.0% | | |||
| | Discard | 512 | 0.0% | | +---------------+--------+---------------------------------------+ | |||
| +---------------+--------+----------------------+ | ||||
| Table 6 | Table 6: Hop-by-hop Transmission | |||
| It appears that hop-by-hop options headers cannot reliably traverse | It appears that hop-by-hop options headers cannot reliably traverse | |||
| the global Internet; only small headers with 'skippable' options have | the global Internet; only small headers with 'skipable' options have | |||
| some chances. If the hop-by-hop option has the 'discard' bits, it is | some chances. If the unknown hop-by-hop option has the 'discard' | |||
| dropped per specification. | bits, it is dropped per specification. | |||
| 3.2.3. Destination Options Headers | 4.3. Destination Options Header | |||
| Many ASs drop packets containing destination options headers per | Many ASs drop packets containing destination options headers per | |||
| table below: | Table 7: | |||
| +========+===============+======================+ | +========+===============+=======================================+ | |||
| | Length | Multiple PadN | %-age of experiments | | | Length | Multiple PadN | %-age of packets reaching destination | | |||
| | | | reaching destination | | +========+===============+=======================================+ | |||
| +========+===============+======================+ | | 8 | No | 99.3% | | |||
| | 8 | No | 99.2% | | +--------+---------------+---------------------------------------+ | |||
| +--------+---------------+----------------------+ | | 16 | No | 99.3% | | |||
| | 256 | No | 2.6% | | +--------+---------------+---------------------------------------+ | |||
| +--------+---------------+----------------------+ | | 32 | No | 93.3% | | |||
| | 256 | Yes | 2.6% | | +--------+---------------+---------------------------------------+ | |||
| +--------+---------------+----------------------+ | | 64 | No | 41.6% | | |||
| | 512 | No | 2.6% | | +--------+---------------+---------------------------------------+ | |||
| +--------+---------------+----------------------+ | | 128 | No | 4.5% | | |||
| +--------+---------------+---------------------------------------+ | ||||
| | 256 | No | 2.6% | | ||||
| +--------+---------------+---------------------------------------+ | ||||
| | 256 | Yes | 2.6% | | ||||
| +--------+---------------+---------------------------------------+ | ||||
| | 512 | No | 2.6% | | ||||
| +--------+---------------+---------------------------------------+ | ||||
| Table 7 | Table 7: Hop-by-hop Transmission | |||
| The measurement did not find any impact of the discard/skip bits in | The measurement did not find any impact of the discard/skip bits in | |||
| the destination headers options, probably because the routers do not | the destination headers options, probably because the routers do not | |||
| look inside the extension headers into the options. The use of a | look inside the extension headers into the options. The use of a | |||
| single large PadN or multiple 8-octet PadN options does not influence | single large PadN or multiple 8-octet PadN options does not influence | |||
| the result. | the result. | |||
| 3.2.4. Fragmentation Header | The size of the destination options header has a major impact on the | |||
| drop probability. It appears that extension header larger than 16 | ||||
| octets already causes major drops. It may be because the 40 octets | ||||
| of the IPv6 header + the 16 octets of the extension header (total 56 | ||||
| octets) is still below some router hardware lookup mechanisms while | ||||
| the next measured size (extension header size of 64 octets for a | ||||
| total of 104 octets) is beyond the hardware limit and some AS has a | ||||
| policy to drop packets where the TCP/UDP ports are unknown... | ||||
| 4.4. Fragmentation Header | ||||
| The propagation of two kinds of fragmentation headers was analysed: | The propagation of two kinds of fragmentation headers was analysed: | |||
| atomic fragment (offset == 0 and M-flag == 0) and plain first | atomic fragment (offset == 0 and M-flag == 0) and plain first | |||
| fragment (offset == 0 and M-flag == 1). The table below displays the | fragment (offset == 0 and M-flag == 1). The Table 8 displays the | |||
| propagation differences. | propagation differences. | |||
| +============+===========================================+ | +============+=======================================+ | |||
| | M-flag | %-age of experiments reaching destination | | | M-flag | %-age of packets reaching destination | | |||
| +============+===========================================+ | +============+=======================================+ | |||
| | 0 (atomic) | 70.2% | | | 0 (atomic) | 70.2% | | |||
| +------------+-------------------------------------------+ | +------------+---------------------------------------+ | |||
| | 1 | 99.0% | | | 1 | 99.0% | | |||
| +------------+-------------------------------------------+ | +------------+---------------------------------------+ | |||
| Table 8 | Table 8: IPv6 Fragments Transmission | |||
| The size of the overall IP packets (512, 1280, and 1500 octets) does | The size of the overall IP packets (512, 1280, and 1500 octets) does | |||
| not have any impact on the propagation. | not have any impact on the propagation. | |||
| 3.2.5. No drop at all | 4.5. No extension headers drop at all | |||
| Finally, some ASs do not drop transit traffic (except for routing | Table 9 lists some ASs that do not drop transit traffic (except for | |||
| header type 0) and follow the recommendations of | routing header type 0) and follow the recommendations of | |||
| [I-D.draft-ietf-opsec-ipv6-eh-filtering]. This list includes tier-1 | [I-D.draft-ietf-opsec-ipv6-eh-filtering]. This list includes tier-1 | |||
| transit providers (using the "regional" tag per [TIER1]): | transit providers (using the "regional" tag per [TIER1]): | |||
| +===========+=======================================+===============+ | +===========+=======================================+===============+ | |||
| | AS Number | AS Description | Comment | | | AS Number | AS Description | Comment | | |||
| +===========+=======================================+===============+ | +===========+=======================================+===============+ | |||
| | 4637 | ASN-TELSTRA-GLOBAL Telstra Global, HK | Regional | | | 4637 | ASN-TELSTRA-GLOBAL Telstra Global, HK | Regional | | |||
| | | | Tier | | | | | Tier | | |||
| +-----------+---------------------------------------+---------------+ | +-----------+---------------------------------------+---------------+ | |||
| | 4755 | TATACOMM-AS TATA Communications | | | | 4755 | TATACOMM-AS TATA Communications | | | |||
| | | formerly VSNL is Leading ISP, IN | | | | | formerly VSNL is Leading ISP, IN | | | |||
| +-----------+---------------------------------------+---------------+ | +-----------+---------------------------------------+---------------+ | |||
| | 6762 | SEABONE-NET TELECOM ITALIA SPARKLE | Tier-1 | | ||||
| | | S.p.A., IT | | | ||||
| +-----------+---------------------------------------+---------------+ | ||||
| | 14061 | DIGITALOCEAN-ASN, US | | | ||||
| +-----------+---------------------------------------+---------------+ | ||||
| | 21283 | A1SI-AS A1 Slovenija, SI | | | | 21283 | A1SI-AS A1 Slovenija, SI | | | |||
| +-----------+---------------------------------------+---------------+ | +-----------+---------------------------------------+---------------+ | |||
| | 60011 | MYTHIC-BEASTS-USA, GB | | | | 60011 | MYTHIC-BEASTS-USA, GB | | | |||
| +-----------+---------------------------------------+---------------+ | +-----------+---------------------------------------+---------------+ | |||
| Table 9 | Table 9: ASs Not Dropping Packets with Extension Headers | |||
| 3.3. Summary of the collaborating parties measurements | Some ASs also drop only large (more than 8 octets) destination | |||
| options headers, see Table 10: | ||||
| +===========+====================+===================+ | ||||
| | AS Number | AS Description | Largest Forwarded | | ||||
| | | | Dest.Opt. Size | | ||||
| +===========+====================+===================+ | ||||
| | 6453 | Tata | 8 | | ||||
| | | Communication | | | ||||
| +-----------+--------------------+-------------------+ | ||||
| | 1299 | TWELVE99 Twelve99, | 8 | | ||||
| | | Telia Carrier, SE | | | ||||
| +-----------+--------------------+-------------------+ | ||||
| | 174 | COGENT-174, US | 8 | | ||||
| +-----------+--------------------+-------------------+ | ||||
| Table 10: ASs Only Dropping Packets with Large | ||||
| Destination Options Headers | ||||
| 4.6. Special Next Headers | ||||
| Measurements also include two protocol numbers that are mainly new | ||||
| use of IPv6. Table 11 indicates the percentage of packets reaching | ||||
| the destination. | ||||
| +===================+=======================================+ | ||||
| | Next Header | %-age of packets reaching destination | | ||||
| +===================+=======================================+ | ||||
| | NoNextHeader (59) | 99.7% | | ||||
| +-------------------+---------------------------------------+ | ||||
| | Ethernet (143) | 99.2% | | ||||
| +-------------------+---------------------------------------+ | ||||
| Table 11: Transmission of Special IP Protocols | ||||
| The above indicates that those IP protocols can be transmitted over | ||||
| the global Internet without being dropped (assuming that the 0.3-0.8% | ||||
| of dropped packets are within the measurement error). | ||||
| 5. Summary of the collaborating parties measurements | ||||
| While the analysis has areas of improvement (geographical | While the analysis has areas of improvement (geographical | |||
| distribution and impact on latency), it appears that: | distribution and impact on latency), it appears that: | |||
| * authentication and non-atomic fragmentation headers can traverse | * authentication and non-atomic fragmentation headers can traverse | |||
| the Internet; | the Internet; | |||
| * only routing headers types 0 and 4 experiment problems over the | * only routing headers types 0 and 4 experiment problems over the | |||
| Internet, other types have no problems; | Internet, other types have no problems; | |||
| * hop-by-hop options headers do not traverse the Internet; | * hop-by-hop options headers do not traverse the Internet; | |||
| * destination options headers are not reliable enough when it | ||||
| * destination options headers are not reliable enough especially | exceeds 16 octets. | |||
| large size ones. | ||||
| Of course, the next phase of measurement with non-collaborating | Of course, the next phase of measurement with non-collaborating | |||
| parties will probably give another view. | parties will probably give another view. | |||
| 4. Security Considerations | 6. Security Considerations | |||
| While active probing of the Internet may be considered as an attack, | While active probing of the Internet may be considered as an attack, | |||
| this measurement was done among collaborating parties and using the | this measurement was done among collaborating parties and using the | |||
| probe attribution technique described in | probe attribution technique described in | |||
| [I-D.draft-vyncke-opsec-probe-attribution]. | [I-D.draft-vyncke-opsec-probe-attribution] to allow external parties | |||
| to identify the source of the probes if required. | ||||
| 5. IANA Considerations | 7. IANA Considerations | |||
| This document has no IANA actions. | This document has no IANA actions. | |||
| 6. References | 8. References | |||
| 6.1. Normative References | 8.1. Normative References | |||
| [RFC793] Postel, J., "Transmission Control Protocol", STD 7, | [RFC793] Postel, J., "Transmission Control Protocol", STD 7, | |||
| RFC 793, DOI 10.17487/RFC0793, September 1981, | RFC 793, DOI 10.17487/RFC0793, September 1981, | |||
| <https://www.rfc-editor.org/rfc/rfc793>. | <https://www.rfc-editor.org/rfc/rfc793>. | |||
| [RFC8200] Deering, S. and R. Hinden, "Internet Protocol, Version 6 | [RFC8200] Deering, S. and R. Hinden, "Internet Protocol, Version 6 | |||
| (IPv6) Specification", STD 86, RFC 8200, | (IPv6) Specification", STD 86, RFC 8200, | |||
| DOI 10.17487/RFC8200, July 2017, | DOI 10.17487/RFC8200, July 2017, | |||
| <https://www.rfc-editor.org/rfc/rfc8200>. | <https://www.rfc-editor.org/rfc/rfc8200>. | |||
| [RFC8986] Filsfils, C., Ed., Camarillo, P., Ed., Leddy, J., Voyer, | 8.2. Informative References | |||
| D., Matsushima, S., and Z. Li, "Segment Routing over IPv6 | ||||
| (SRv6) Network Programming", RFC 8986, | ||||
| DOI 10.17487/RFC8986, February 2021, | ||||
| <https://www.rfc-editor.org/rfc/rfc8986>. | ||||
| 6.2. Informative References | ||||
| [ALEXA] "The top 500 sites on the web", n.d., | [ALEXA] "The top 500 sites on the web", n.d., | |||
| <https://www.alexa.com/topsites>. | <https://www.alexa.com/topsites>. | |||
| [BCP220] Chown, T., Loughney, J., and T. Winters, "IPv6 Node | [BCP220] Chown, T., Loughney, J., and T. Winters, "IPv6 Node | |||
| Requirements", BCP 220, RFC 8504, January 2019. | Requirements", BCP 220, RFC 8504, January 2019. | |||
| <https://www.rfc-editor.org/info/bcp220> | <https://www.rfc-editor.org/info/bcp220> | |||
| [GITHUB] Léas, R., "james", n.d., | ||||
| <https://gitlab.uliege.be/Benoit.Donnet/james>. | ||||
| [I-D.draft-bonica-6man-comp-rtg-hdr] | [I-D.draft-bonica-6man-comp-rtg-hdr] | |||
| Bonica, R., Kamite, Y., Alston, A., Henriques, D., and L. | Bonica, R., Kamite, Y., Alston, A., Henriques, D., and L. | |||
| Jalil, "The IPv6 Compact Routing Header (CRH)", Work in | Jalil, "The IPv6 Compact Routing Header (CRH)", Work in | |||
| Progress, Internet-Draft, draft-bonica-6man-comp-rtg-hdr- | Progress, Internet-Draft, draft-bonica-6man-comp-rtg-hdr- | |||
| 27, 15 November 2021, | 27, 15 November 2021, | |||
| <https://datatracker.ietf.org/doc/html/draft-bonica-6man- | <https://datatracker.ietf.org/doc/html/draft-bonica-6man- | |||
| comp-rtg-hdr-27>. | comp-rtg-hdr-27>. | |||
| [I-D.draft-ietf-opsawg-pcap] | [I-D.draft-ietf-opsawg-pcap] | |||
| Harris, G. and M. C. Richardson, "PCAP Capture File | Harris, G. and M. C. Richardson, "PCAP Capture File | |||
| skipping to change at page 14, line 46 ¶ | skipping to change at page 16, line 9 ¶ | |||
| [RFC5095] Abley, J., Savola, P., and G. Neville-Neil, "Deprecation | [RFC5095] Abley, J., Savola, P., and G. Neville-Neil, "Deprecation | |||
| of Type 0 Routing Headers in IPv6", RFC 5095, | of Type 0 Routing Headers in IPv6", RFC 5095, | |||
| DOI 10.17487/RFC5095, December 2007, | DOI 10.17487/RFC5095, December 2007, | |||
| <https://www.rfc-editor.org/rfc/rfc5095>. | <https://www.rfc-editor.org/rfc/rfc5095>. | |||
| [RFC6275] Perkins, C., Ed., Johnson, D., and J. Arkko, "Mobility | [RFC6275] Perkins, C., Ed., Johnson, D., and J. Arkko, "Mobility | |||
| Support in IPv6", RFC 6275, DOI 10.17487/RFC6275, July | Support in IPv6", RFC 6275, DOI 10.17487/RFC6275, July | |||
| 2011, <https://www.rfc-editor.org/rfc/rfc6275>. | 2011, <https://www.rfc-editor.org/rfc/rfc6275>. | |||
| [RFC6554] Hui, J., Vasseur, JP., Culler, D., and V. Manral, "An IPv6 | ||||
| Routing Header for Source Routes with the Routing Protocol | ||||
| for Low-Power and Lossy Networks (RPL)", RFC 6554, | ||||
| DOI 10.17487/RFC6554, March 2012, | ||||
| <https://www.rfc-editor.org/rfc/rfc6554>. | ||||
| [RFC7704] Crocker, D. and N. Clark, "An IETF with Much Diversity and | [RFC7704] Crocker, D. and N. Clark, "An IETF with Much Diversity and | |||
| Professional Conduct", RFC 7704, DOI 10.17487/RFC7704, | Professional Conduct", RFC 7704, DOI 10.17487/RFC7704, | |||
| November 2015, <https://www.rfc-editor.org/rfc/rfc7704>. | November 2015, <https://www.rfc-editor.org/rfc/rfc7704>. | |||
| [RFC7872] Gont, F., Linkova, J., Chown, T., and W. Liu, | [RFC7872] Gont, F., Linkova, J., Chown, T., and W. Liu, | |||
| "Observations on the Dropping of Packets with IPv6 | "Observations on the Dropping of Packets with IPv6 | |||
| Extension Headers in the Real World", RFC 7872, | Extension Headers in the Real World", RFC 7872, | |||
| DOI 10.17487/RFC7872, June 2016, | DOI 10.17487/RFC7872, June 2016, | |||
| <https://www.rfc-editor.org/rfc/rfc7872>. | <https://www.rfc-editor.org/rfc/rfc7872>. | |||
| [RFC8754] Filsfils, C., Ed., Dukes, D., Ed., Previdi, S., Leddy, J., | [RFC8754] Filsfils, C., Ed., Dukes, D., Ed., Previdi, S., Leddy, J., | |||
| Matsushima, S., and D. Voyer, "IPv6 Segment Routing Header | Matsushima, S., and D. Voyer, "IPv6 Segment Routing Header | |||
| (SRH)", RFC 8754, DOI 10.17487/RFC8754, March 2020, | (SRH)", RFC 8754, DOI 10.17487/RFC8754, March 2020, | |||
| <https://www.rfc-editor.org/rfc/rfc8754>. | <https://www.rfc-editor.org/rfc/rfc8754>. | |||
| [RFC8986] Filsfils, C., Ed., Camarillo, P., Ed., Leddy, J., Voyer, | ||||
| D., Matsushima, S., and Z. Li, "Segment Routing over IPv6 | ||||
| (SRv6) Network Programming", RFC 8986, | ||||
| DOI 10.17487/RFC8986, February 2021, | ||||
| <https://www.rfc-editor.org/rfc/rfc8986>. | ||||
| [TIER1] "Tier 1 network", n.d., | [TIER1] "Tier 1 network", n.d., | |||
| <https://en.wikipedia.org/wiki/Tier_1_network>. | <https://en.wikipedia.org/wiki/Tier_1_network>. | |||
| Acknowledgments | Acknowledgments | |||
| The authors want to thank Sander Steffann and Jan Zorz for allowing | The authors want to thank Sander Steffann and Jan Zorz for allowing | |||
| the free use of their labs. Other thanks to Fernando Gont who | the free use of their labs. Other thanks to Fernando Gont who | |||
| indicated a nice IPv6 hosting provider in South America. | indicated a nice IPv6 hosting provider in South America. | |||
| Special thanks as well to Professor Benoit Donnet for his support and | Special thanks as well to Professor Benoit Donnet for his support and | |||
| skipping to change at page 15, line 29 ¶ | skipping to change at page 17, line 4 ¶ | |||
| Acknowledgments | Acknowledgments | |||
| The authors want to thank Sander Steffann and Jan Zorz for allowing | The authors want to thank Sander Steffann and Jan Zorz for allowing | |||
| the free use of their labs. Other thanks to Fernando Gont who | the free use of their labs. Other thanks to Fernando Gont who | |||
| indicated a nice IPv6 hosting provider in South America. | indicated a nice IPv6 hosting provider in South America. | |||
| Special thanks as well to Professor Benoit Donnet for his support and | Special thanks as well to Professor Benoit Donnet for his support and | |||
| advices. This document would not have existed without his support. | advices. This document would not have existed without his support. | |||
| Authors' Addresses | Authors' Addresses | |||
| Éric Vyncke | Éric Vyncke | |||
| Cisco | Cisco | |||
| De Kleetlaan 64 | De Kleetlaan 64 | |||
| 1831 Diegem | 1831 Diegem | |||
| Belgium | Belgium | |||
| Email: evyncke@cisco.com | Email: evyncke@cisco.com | |||
| Raphaël Léas | Raphaël Léas | |||
| Université de Liège | Université de Liège | |||
| Liège | Liège | |||
| Belgium | Belgium | |||
| Email: raphael.leas@student.uliege.be | Email: raphael.leas@student.uliege.be | |||
| Justin Iurman | Justin Iurman | |||
| Université de Liège | Université de Liège | |||
| Institut Montefiore B28 | ||||
| Allée de la Découverte 10 | ||||
| 4000 Liège | ||||
| Belgium | Belgium | |||
| Email: justin.iurman@uliege.be | Email: justin.iurman@uliege.be | |||
| End of changes. 63 change blocks. | ||||
| 190 lines changed or deleted | 256 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/ | ||||