Who drops IPv6 fragments in their network, under what circumstances? Tom Taylor
On (2012-10-04 10:16 -0400), Tom Taylor wrote:
Who drops IPv6 fragments in their network, under what circumstances?
No one who offers working IP connections. Dropping IPv6 fragments against your control-plane, that is another discussion, but dropping them in transit would be short-lived exercise. -- ++ytti
On 04/10/2012 10:20 AM, Saku Ytti wrote:
On (2012-10-04 10:16 -0400), Tom Taylor wrote:
Who drops IPv6 fragments in their network, under what circumstances?
No one who offers working IP connections.
Dropping IPv6 fragments against your control-plane, that is another discussion, but dropping them in transit would be short-lived exercise.
Let's talk control plane, then. Under what circumstances do fragments get dropped?
Hi,
Who drops IPv6 fragments in their network, under what circumstances?
No one who offers working IP connections.
Dropping IPv6 fragments against your control-plane, that is another discussion, but dropping them in transit would be short-lived exercise.
Depends on where you are looking. In the core network dropping fragments is not that common AFAIK. The closer you get to the edge the more common it might become... - Sander
On Oct 4, 2012, at 9:26 PM, Sander Steffann wrote:
The closer you get to the edge the more common it might become...
iACLs should be implemented at the network edge to drop all IPv4 and IPv6 traffic - including non-initial fragments - directed towards point-to-point links, loopbacks, and other internal infrastructure with exceptions made for cases where there's a legitimate need for sources outside your network to be able to communicate with your infrastructure. As mentioned previously on the thread, this has nothing to do with transit data-plane traffic, which should be left untouched unless it's specifically classified as attack traffic or other undesirable traffic. There's an apparently common misperception that fragmented traffic is somehow bad. It isn't. It's normal, under most circumstances. Protect your infrastructure proactively, deal with anything else on a case-by-case basis. ----------------------------------------------------------------------- Roland Dobbins <rdobbins@arbor.net> // <http://www.arbornetworks.com> Luck is the residue of opportunity and design. -- John Milton
On 10/4/12 7:36 AM, Dobbins, Roland wrote:
On Oct 4, 2012, at 9:26 PM, Sander Steffann wrote:
The closer you get to the edge the more common it might become... iACLs should be implemented at the network edge to drop all IPv4 and IPv6 traffic - including non-initial fragments - directed towards point-to-point links, loopbacks, and other internal infrastructure with exceptions made for cases where there's a legitimate need for sources outside your network to be able to communicate with your infrastructure.
As mentioned previously on the thread, this has nothing to do with transit data-plane traffic, which should be left untouched unless it's specifically classified as attack traffic or other undesirable traffic.
There's an apparently common misperception that fragmented traffic is somehow bad. It isn't. It's normal, under most circumstances. Protect your infrastructure proactively, deal with anything else on a case-by-case basis.
So the thing I'd note is that stateless IPV6 ACLs or load balancing provide you with an interesting problem since a fragment does not contain the headers beyond the required unfragmentable headers. it is possible but unlikely that the fragment will hash into the same bucket in a stateless load balancer (using what's left of 5-tuple). Likewise with the acl I have the property that the initial packet has all the info in it while the fragment does not. I would have to reassemble the packet (which isn't going to happen in the place where the stateless acl is applied) prior to being able to decide to pass it or not (or just pass fragments through that acl).
----------------------------------------------------------------------- Roland Dobbins <rdobbins@arbor.net> // <http://www.arbornetworks.com>
Luck is the residue of opportunity and design.
-- John Milton
On Oct 4, 2012, at 9:58 PM, joel jaeggli wrote:
Likewise with the acl I have the property that the initial packet has all the info in it while the fragment does not.
For iACLs, just filter non-initial fragments directed to infrastructure IPs. Cisco & Juniper ACLs have ACL matching criteria for non-initial fragments. ----------------------------------------------------------------------- Roland Dobbins <rdobbins@arbor.net> // <http://www.arbornetworks.com> Luck is the residue of opportunity and design. -- John Milton
On 10/4/12 8:15 AM, Dobbins, Roland wrote:
On Oct 4, 2012, at 9:58 PM, joel jaeggli wrote:
Likewise with the acl I have the property that the initial packet has all the info in it while the fragment does not. For iACLs, just filter non-initial fragments directed to infrastructure IPs. Cisco & Juniper ACLs have ACL matching criteria for non-initial fragments.
Yeah, that's more or less what we said in RFC 6192. That said as the network operator of a content provider I have more devices in my portfolio than just backbone routers.
----------------------------------------------------------------------- Roland Dobbins <rdobbins@arbor.net> // <http://www.arbornetworks.com>
Luck is the residue of opportunity and design.
-- John Milton
Hi, Joel, On 10/04/2012 10:58 AM, joel jaeggli wrote:
So the thing I'd note is that stateless IPV6 ACLs or load balancing provide you with an interesting problem since a fragment does not contain the headers beyond the required unfragmentable headers.
In the real world, such packets are not legitimate, so feel free to drop them. draft-ietf-6man-oversized-header-chain formally addresses this issue.
Likewise with the acl I have the property that the initial packet has all the info in it while the fragment does not.
You're talking about initial-fragment vs non-initial fragments? -- If so, in theory *both* might be missing the upper layer information. IN practice, the first-fragment won't. If it does, feel free to drop it. Cheers, -- Fernando Gont e-mail: fernando@gont.com.ar || fgont@si6networks.com PGP Fingerprint: 7809 84F5 322E 45C7 F1C9 3945 96EE A9EF D076 FFF1
Fernando Gont wrote:
In the real world, such packets are not legitimate, so feel free to drop them. draft-ietf-6man-oversized-header-chain formally addresses this issue.
The ID misses the problem of 4->6 translator. That is, though the ID state: Entire IPv6 header chain: All protocol headers starting from the fixed IPv6 header till (and including) the upper layer protocol header (TCP, UDP, etc. -- assuming there is one of those), the translator may not have any knowledge on how long "the upper layer protocol header" is. Thus, the requirement of the ID is impossible to enforce. Moreover, a 68B IPv4 fragment of some packet with 60B upper layer protocol header can not be translated to IPv6. In theory, with 60B IPv4 header, a 68B IPv4 fragment can't even contain an entire TCP header. So, the requirement of the ID should be to require only the first 8B of the upper layer protocol header. All the (pseudo) transport protocols working over IPv4 is designed to identify transport identity with the first 8B of transport headers.
Likewise with the acl I have the property that the initial packet has all the info in it while the fragment does not.
You're talking about initial-fragment vs non-initial fragments? -- If so, in theory *both* might be missing the upper layer information.
Yes, that is one of an annoying point of IPv6. Masataka Ohta
On Oct 4, 2012, at 7:36 AM, Dobbins, Roland wrote:
On Oct 4, 2012, at 9:26 PM, Sander Steffann wrote:
The closer you get to the edge the more common it might become...
iACLs should be implemented at the network edge to drop all IPv4 and IPv6 traffic - including non-initial fragments - directed towards point-to-point links, loopbacks, and other internal infrastructure with exceptions made for cases where there's a legitimate need for sources outside your network to be able to communicate with your infrastructure.
As mentioned previously on the thread, this has nothing to do with transit data-plane traffic, which should be left untouched unless it's specifically classified as attack traffic or other undesirable traffic.
+1
There's an apparently common misperception that fragmented traffic is somehow bad. It isn't. It's normal, under most circumstances. Protect your infrastructure proactively, deal with anything else on a case-by-case basis.
Same misconception as ICMP is bad....historical artifact from attacks in early 90's that just perpetuate in mythical best practice. I was just investigating with varying folks whether they also log v6 fragment filtering exceptions and whether anyone has seen anything 'interesting' :) Nothing interesting yet. I'm co-authoring a doc in IETF which consolidates v6 security practices and looks to provide info for what current BCP is as folks are more actively deploying v6. Was just at RIPE to get input from that operator community and want to solicit input here as well. Doc is at: http://tools.ietf.org/html/draft-ietf-opsec-v6-00 Feedback on mailing list would be great: https://www.ietf.org/mailman/listinfo/opsec but, if easier to send email to authors just do so directly and we'll incorporate and vet appropriately. All 3 authors follow quite a few *NOG lists and have been involved in deployments so hopefully this can help educate the less informed. - merike
----------------------------------------------------------------------- Roland Dobbins <rdobbins@arbor.net> // <http://www.arbornetworks.com>
Luck is the residue of opportunity and design.
-- John Milton
In message <C7E7DE67-F668-45B4-9D64-2058400DC161@doubleshotsecurity.com>, Merik e Kaeo writes:
On Oct 4, 2012, at 7:36 AM, Dobbins, Roland wrote:
The closer you get to the edge the more common it might become... =20 iACLs should be implemented at the network edge to drop all IPv4 and = IPv6 traffic - including non-initial fragments - directed towards =
=20 On Oct 4, 2012, at 9:26 PM, Sander Steffann wrote: =20 point-to-point links, loopbacks, and other internal infrastructure with = exceptions made for cases where there's a legitimate need for sources = outside your network to be able to communicate with your infrastructure. =20 As mentioned previously on the thread, this has nothing to do with = transit data-plane traffic, which should be left untouched unless it's = specifically classified as attack traffic or other undesirable traffic.
+1
There's an apparently common misperception that fragmented traffic is = somehow bad. It isn't. It's normal, under most circumstances. Protect = your infrastructure proactively, deal with anything else on a = case-by-case basis.
Same misconception as ICMP is bad....historical artifact from attacks in = early 90's that just perpetuate in mythical best practice. =20
And it really hurts modern DNS where UDP responses often exceed Ethernet MTU. For IPv6 UDP DNS responses are often fragmented at 1280 to prevent PMTUD being needed. For IPv4 PMTUD should be off if your vendor followed the RFC's (know exception are Linux and Solaris boxes). Mark -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka@isc.org
On 10/04/2012 04:36 PM, Dobbins, Roland wrote:
On Oct 4, 2012, at 9:26 PM, Sander Steffann wrote:
The closer you get to the edge the more common it might become...
iACLs should be implemented at the network edge to drop all IPv4 and IPv6 traffic - including non-initial fragments - directed towards point-to-point links, loopbacks, and other internal infrastructure with exceptions made for cases where there's a legitimate need for sources outside your network to be able to communicate with your infrastructure.
As mentioned previously on the thread, this has nothing to do with transit data-plane traffic, which should be left untouched unless it's specifically classified as attack traffic or other undesirable traffic.
There's an apparently common misperception that fragmented traffic is somehow bad. It isn't. It's normal, under most circumstances. Protect your infrastructure proactively, deal with anything else on a case-by-case basis.
Two students worked on a project in June to measure fragment dropping in IPv6 (and IPv4) using the RIPE Atlas probe infrastructure. Their findings are consistent with Sander's remark. The core seems to do fine, but at the edges it is observed that some middleboxes/CPEs do drop IPv6 fragments. I think this is consistent with the remarks of Joel and Roland earlier on Cisco/Juniper iACL vs. simpler boxes in your network. You can find the report at http://www.nlnetlabs.nl/downloads/publications/pmtu-black-holes-msc-thesis.p.... Best, -- Benno -- Benno J. Overeinder NLnet Labs http://www.nlnetlabs.nl/
On Thu, 4 Oct 2012, Tom Taylor wrote:
Who drops IPv6 fragments in their network, under what circumstances?
People who run 7600 with SUP720 and who hasn't turned on a certain command. <http://mailman.nanog.org/pipermail/nanog/2011-September/040653.html> #platform ipv6 acl fragment hardware ? drop Drop IPv6 fragments at hardware forward Forward IPv6 fragments at hardware -- Mikael Abrahamsson email: swmike@swm.pp.se
participants (11)
-
Benno Overeinder -
Dobbins, Roland -
Fernando Gont -
joel jaeggli -
Mark Andrews -
Masataka Ohta -
Merike Kaeo -
Mikael Abrahamsson -
Saku Ytti -
Sander Steffann -
Tom Taylor