Why Operators Filter Fragments and What It Implies
draft-taylor-v6ops-fragdrop-00
| Document | Type |
This is an older version of an Internet-Draft whose latest revision state is "Expired".
Expired & archived
|
|
|---|---|---|---|
| Authors | Joel Jaeggli , Lorenzo Colitti , Warren "Ace" Kumari , Éric Vyncke , Merike Kaeo , Tom Taylor | ||
| Last updated | 2013-04-18 (Latest revision 2012-10-15) | ||
| RFC stream | (None) | ||
| Formats | |||
| Stream | Stream state | (No stream defined) | |
| Consensus boilerplate | Unknown | ||
| RFC Editor Note | (None) | ||
| IESG | IESG state | Expired | |
| Telechat date | (None) | ||
| Responsible AD | (None) | ||
| Send notices to | (None) |
This Internet-Draft is no longer active. A copy of the expired Internet-Draft is available in these formats:
Abstract
This memo is written to make application developers and network operators aware of the significant probability that IPv6 packets containing fragmentation extension headers will fail to reach their destination. Some assumptions about the ability to use TCP or UDP datagrams larger than a single packet may accordingly need adjustment. This memo provides observational evidence for the dropping of IPv6 fragments along a significant number of paths, explores the operational impact of fragmentation and the reasons why dropping occurs, and considers the effect of fragment dropping on applications particularly including DNS.
Authors
Joel Jaeggli
Lorenzo Colitti
Warren "Ace" Kumari
Éric Vyncke
Merike Kaeo
Tom Taylor
(Note: The e-mail addresses provided for the authors of this Internet-Draft may no longer be valid.)