Forum - ip6table and icmpv6 type2 (packet too big) :: SixXS

ip6table and icmpv6 type2 (packet too big)

Carmen Sandiego on Monday, 07 February 2011 19:23:54

Hello, This message is just to double check I can now post to forum and ticket. My post were not beeing accepted (just a blank screen) Seems to be related to firewall rejecting "icmpv6-type Packet-Too-Big" lets check. If you see this, this means accepting Packet-Too-Big could be crucial to post.

ip6table and icmpv6 type2 (packet too big)

Jeroen Massar SixXS Staff

on Monday, 07 February 2011 19:28:38

And you have discovered why people should not block ICMP. Especially Packet-Too-Big is crucial due to Path MTU discovery. Don't worry though, a lot of people think that blocking ICMP is their total and finaly line of security. As a great example, bugs.debian.org is also unreachable from links which have a non-1500 MTU, this as they (or somebody in their network path) also block out ICMPv6 Packet Too Big...

ip6table and icmpv6 type2 (packet too big)

Shadow Hawkins on Thursday, 03 March 2011 18:58:17

Any idea of how one could efficiently convince hosters, providers and all the others that dropping ICMPv6 Packet to Big (as well as a good deal of other ICMP(v6)) is a bad idea and prevents people from accessing services on their network? I think waiting for IPv6 world day on 8 June will certainly not help (it would probably delay IPv6 on content provider side even more). It seems like some providers are setting an arbitrary TCP-MSS on their IPv6 links in the hope to be small enough to pass over tunnels so they can drop ICMPv6 (though fail miserably with SIXXS's default MTU of 1280) but contacting them doesn't change anything and often does not result in any (valuable) reply. I fear that information is too technical for most customer-targeted helpdesks and thus not passed on.

ip6table and icmpv6 type2 (packet too big)

Jeroen Massar SixXS Staff

on Thursday, 03 March 2011 20:27:34

You can't solve the problem of stupid people unfortunately. There is a way that always works though in those cases: name and shame. Thus provide details (tracepath6 <destination>) here and we'll see if we can get to them through other methods. The default of 1280 for tunnels is btw the default for protocol 41 (and thus 6to4 and 6rd) and it is the default as it theoretically always works on the IPv4 path between the two endpoints. Indeed, if the people on the IPv6 level are so silly to drop ICMP Too Big, or for that matter any ICMP, that is their problem.

ip6table and icmpv6 type2 (packet too big)

Shadow Hawkins on Thursday, 03 March 2011 20:40:50

bugs.debian.org is also unreachable from links which have a non-1500 MTU,

Could you provide examples, please? I'd like to try to get that fixed, but it seems to work fine from here.

ip6table and icmpv6 type2 (packet too big)

Jeroen Massar SixXS Staff

on Friday, 04 March 2011 08:41:58

Seems somebody stopped dropping ICMP on that path as tracepath + traceroute both come through clean now and it seems that it works now again.

ip6table and icmpv6 type2 (packet too big)

Carmen Sandiego on Tuesday, 08 February 2011 20:16:59

Packet to big was reject within my internal network between my front end router and hosts (hosting openvz virtual). I usually (IPV4) keep a set of ICMP type open, tracing everything rejected and adding if really needed (and understood)... The main problem was SIXX.net was responding no problem, only post was ending in bizarre way (not getting feedback), it took me a while to understand post and request where indeed not seen by SIXXS and find a correlation with one small ICMPV6 reject entry within logs each time I was trying to post. So yes, packet-too-big, is mandatory to be accepted...

Please note Posting is only allowed when you are logged in.