![]() ![]() RFC states that no router may fragment a packet, so breaking PMTUD in v6 is going to be a much more severe issue. This is not an option in IPv6 by the way. If you do this, then a router will fragment the packet in stead of discarding it with a "please limit your packets to MTU-bytes" message. (Ping, for instance, does not by default, which is why you can ping with "100kilobyte packets"). Of course, your application could simply not set DF-bit to yes. If a host has an MTU of 1200, for instance, it's going to stamp every TCP handshake with a mark (MSS) which says "by the way, my MTU is 1200, so let's start there." Of course, some link in the path might be using a smaller MTU, in which case TCP would still have to shrink the max packet size anyway, but at least it tried. TCP even has a feature to try to start off on the right foot with an appropriate MTU. Applications that use UDP must handle this on their own. If you're using TCP, then TCP is smart enough to drop down to 1460 MTU for this one session, and resend the discarded packet. "Hey, you don't know me, but I'm router #8, and I had to discard a packet from you that was going to host x.x.x.x because the packet exceeded the MTU of the next hop, which is 1460 by the way." However, to be nice and help make things work better, router 8 sends a message: Since you marked it do-not-fragment, the router must discard the packet, as it can't fit in the hole, basically. Router 8 has the packet, and decides to forward the packet to router 9, but then finds that the DF (don't fragment) bit is set YES, and that the packet is larger than the MTU of the next hop (pkt=1500, mtu=1460). The packet gets through routers 1-7 just fine. (this is an IP header field, not TCP or UDP, by the way) Suppose the link between router 8-9 has MTU of 1460.Ī 1500-byte packet leaves client (guinnea pig packet if its a tool or otherwise deliberate MTU test) with the df-bit set to yes. Suppose you have a path with 12 routers between the client and server. ![]() This kind of situation is exactly what ICMP protocol is for - general-purpose messaging between nodes of the inter-network. If a test application or a live application sends a don't-fragment packet that is too large for a particular hop along the path to its destination, then the discarding router is going to reply with an ICMP message. PMTU discovery is supposed to happen on every actual connection a host makes. It could even be a padded TCP/SYN packet - it really doesn't matter what the test packet is. They send them somewhere to see if they make it or not. These are basically "guinnea pig" packets. UDP/5678 -> Neighbor Discovery Protocol, according to that page.Īnyway, some tools might send such packets. I would like to do the following -ġ) Allow ICMP requests originating from any host on my LAN to any other host on my LAN.Ģ) Allow ICMP requests originating from any host on my LAN out to the internet and back.ģ) Drop all ICMP requests not originating from my LAN (for example entering through the gateway)Ġ chain=input action=accept protocol=icmp src-address-list=LAN log=noĬhain=input action=drop connection-state=invalid log=no log-prefix=""Ĭhain=forward action=drop connection-state=invalid log=no log-prefix=""Ĭhain=input action=accept src-address-list=LAN log=no log-prefix=""Ĭhain=input action=accept connection-state=established log=noĬhain=input action=drop log=no log-prefix=""Ĭhain=forward action=accept connection-state=new src-address-list=LANĬhain=forward action=accept connection-state=related log=no log-prefix=""Ĭhain=forward action=accept connection-state=established log=noĬhain=forward action=drop log=no log-prefix=""ġ) Given the firewall rules I have in place does this seem like the best way to implement my ICMP rule?Ģ) Should any of my firewall rules be placed in a different order? I think I have this firewall ICMP rule configured correctly but want to ask others before I deploy it. ![]()
0 Comments
Leave a Reply. |
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |