Who drops IPv6 fragments in their network, under what circumstances?
Tom Taylor
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
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.
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).
For iACLs, just filter non-initial fragments directed to infrastructure IPs. Cisco & Juniper ACLs have ACL matching criteria for non-initial fragments.
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.
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: draft-ietf-opsec-v6-00
Feedback on mailing list would be great: OPSEC Info Page 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
Hi, Joel,
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,
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
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
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
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.pdf.
Best,
-- Benno