draft-ietf-v6ops-ipv6-ehs-packet-drops-07.txt   draft-ietf-v6ops-ipv6-ehs-packet-drops-08.txt 
IPv6 Operations Working Group (v6ops) F. Gont IPv6 Operations Working Group (v6ops) F. Gont
Internet-Draft SI6 Networks Internet-Draft SI6 Networks
Intended status: Informational N. Hilliard Intended status: Informational N. Hilliard
Expires: December 11, 2021 INEX Expires: December 13, 2021 INEX
G. Doering G. Doering
SpaceNet AG SpaceNet AG
W. Kumari W. Kumari
Google Google
G. Huston G. Huston
APNIC APNIC
W. Liu W. Liu
Huawei Technologies Huawei Technologies
June 9, 2021 June 11, 2021
Operational Implications of IPv6 Packets with Extension Headers Operational Implications of IPv6 Packets with Extension Headers
draft-ietf-v6ops-ipv6-ehs-packet-drops-07 draft-ietf-v6ops-ipv6-ehs-packet-drops-08
Abstract Abstract
This document summarizes the operational implications of IPv6 This document summarizes the operational implications of IPv6
extension headers specified in the IPv6 protocol specification extension headers specified in the IPv6 protocol specification
(RFC8200), and attempts to analyze reasons why packets with IPv6 (RFC8200), and attempts to analyze reasons why packets with IPv6
extension headers are often dropped in the public Internet. extension headers are often dropped in the public Internet.
Status of This Memo Status of This Memo
skipping to change at page 1, line 42 skipping to change at page 1, line 42
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 December 11, 2021. This Internet-Draft will expire on December 13, 2021.
Copyright Notice Copyright Notice
Copyright (c) 2021 IETF Trust and the persons identified as the Copyright (c) 2021 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(https://trustee.ietf.org/license-info) in effect on the date of (https://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
skipping to change at page 10, line 17 skipping to change at page 10, line 17
vectors open. vectors open.
7.3. DDoS Management and Customer Requests for Filtering 7.3. DDoS Management and Customer Requests for Filtering
The case of customer DDoS protection and edge-to-core customer The case of customer DDoS protection and edge-to-core customer
protection filters is similar in nature to the iACL protection. protection filters is similar in nature to the iACL protection.
Similar to iACL protection, layer-4 ACLs generally need to be applied Similar to iACL protection, layer-4 ACLs generally need to be applied
as close to the edge of the network as possible, even though the as close to the edge of the network as possible, even though the
intent is usually to protect the customer edge rather than the intent is usually to protect the customer edge rather than the
provider core. Application of layer-4 DDoS protection to a network provider core. Application of layer-4 DDoS protection to a network
edge is often automated using Flowspec [RFC5575]. edge is often automated using Flowspec [RFC8955] [RFC8956].
For example, a web site that normally only handled traffic on TCP For example, a web site that normally only handled traffic on TCP
ports 80 and 443 could be subject to a volumetric DDoS attack using ports 80 and 443 could be subject to a volumetric DDoS attack using
NTP and DNS packets with randomised source IP address, thereby NTP and DNS packets with randomised source IP address, thereby
rendering traditional [RFC5635] source-based real-time black hole rendering traditional [RFC5635] source-based real-time black hole
mechanisms useless. In this situation, DDoS protection ACLs could be mechanisms useless. In this situation, DDoS protection ACLs could be
configured to block all UDP traffic at the network edge without configured to block all UDP traffic at the network edge without
impairing the web server functionality in any way. Thus, being able impairing the web server functionality in any way. Thus, being able
to block arbitrary protocols at the network edge can avoid DDoS- to block arbitrary protocols at the network edge can avoid DDoS-
related problems both in the provider network and on the customer related problems both in the provider network and on the customer
skipping to change at page 18, line 25 skipping to change at page 18, line 25
[PMTUD-Blackholes] [PMTUD-Blackholes]
De Boer, M. and J. Bosma, "Discovering Path MTU black De Boer, M. and J. Bosma, "Discovering Path MTU black
holes on the Internet using RIPE Atlas", July 2012, holes on the Internet using RIPE Atlas", July 2012,
<http://www.nlnetlabs.nl/downloads/publications/pmtu- <http://www.nlnetlabs.nl/downloads/publications/pmtu-
black-holes-msc-thesis.pdf>. black-holes-msc-thesis.pdf>.
[RFC2460] Deering, S. and R. Hinden, "Internet Protocol, Version 6 [RFC2460] Deering, S. and R. Hinden, "Internet Protocol, Version 6
(IPv6) Specification", RFC 2460, DOI 10.17487/RFC2460, (IPv6) Specification", RFC 2460, DOI 10.17487/RFC2460,
December 1998, <https://www.rfc-editor.org/info/rfc2460>. December 1998, <https://www.rfc-editor.org/info/rfc2460>.
[RFC5575] Marques, P., Sheth, N., Raszuk, R., Greene, B., Mauch, J.,
and D. McPherson, "Dissemination of Flow Specification
Rules", RFC 5575, DOI 10.17487/RFC5575, August 2009,
<https://www.rfc-editor.org/info/rfc5575>.
[RFC5635] Kumari, W. and D. McPherson, "Remote Triggered Black Hole [RFC5635] Kumari, W. and D. McPherson, "Remote Triggered Black Hole
Filtering with Unicast Reverse Path Forwarding (uRPF)", Filtering with Unicast Reverse Path Forwarding (uRPF)",
RFC 5635, DOI 10.17487/RFC5635, August 2009, RFC 5635, DOI 10.17487/RFC5635, August 2009,
<https://www.rfc-editor.org/info/rfc5635>. <https://www.rfc-editor.org/info/rfc5635>.
[RFC6192] Dugal, D., Pignataro, C., and R. Dunn, "Protecting the [RFC6192] Dugal, D., Pignataro, C., and R. Dunn, "Protecting the
Router Control Plane", RFC 6192, DOI 10.17487/RFC6192, Router Control Plane", RFC 6192, DOI 10.17487/RFC6192,
March 2011, <https://www.rfc-editor.org/info/rfc6192>. March 2011, <https://www.rfc-editor.org/info/rfc6192>.
[RFC6437] Amante, S., Carpenter, B., Jiang, S., and J. Rajahalme, [RFC6437] Amante, S., Carpenter, B., Jiang, S., and J. Rajahalme,
skipping to change at page 19, line 30 skipping to change at page 19, line 25
"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/info/rfc7872>. <https://www.rfc-editor.org/info/rfc7872>.
[RFC8900] Bonica, R., Baker, F., Huston, G., Hinden, R., Troan, O., [RFC8900] Bonica, R., Baker, F., Huston, G., Hinden, R., Troan, O.,
and F. Gont, "IP Fragmentation Considered Fragile", and F. Gont, "IP Fragmentation Considered Fragile",
BCP 230, RFC 8900, DOI 10.17487/RFC8900, September 2020, BCP 230, RFC 8900, DOI 10.17487/RFC8900, September 2020,
<https://www.rfc-editor.org/info/rfc8900>. <https://www.rfc-editor.org/info/rfc8900>.
[RFC8955] Loibl, C., Hares, S., Raszuk, R., McPherson, D., and M.
Bacher, "Dissemination of Flow Specification Rules",
RFC 8955, DOI 10.17487/RFC8955, December 2020,
<https://www.rfc-editor.org/info/rfc8955>.
[RFC8956] Loibl, C., Ed., Raszuk, R., Ed., and S. Hares, Ed.,
"Dissemination of Flow Specification Rules for IPv6",
RFC 8956, DOI 10.17487/RFC8956, December 2020,
<https://www.rfc-editor.org/info/rfc8956>.
[Zack-FW-Benchmark] [Zack-FW-Benchmark]
Zack, E., "Firewall Security Assessment and Benchmarking Zack, E., "Firewall Security Assessment and Benchmarking
IPv6 Firewall Load Tests", IPv6 Hackers Meeting #1, IPv6 Firewall Load Tests", IPv6 Hackers Meeting #1,
Berlin, Germany. June 30, 2013, Berlin, Germany. June 30, 2013,
<https://www.ipv6hackers.org/files/meetings/ipv6-hackers- <https://www.ipv6hackers.org/files/meetings/ipv6-hackers-
1/zack-ipv6hackers1-firewall-security-assessment-and- 1/zack-ipv6hackers1-firewall-security-assessment-and-
benchmarking.pdf>. benchmarking.pdf>.
Authors' Addresses Authors' Addresses
 End of changes. 7 change blocks. 
10 lines changed or deleted 15 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/