IPv6 and the Importance of the ICMPv6 – Packet Too Big Message

I’ve been reading a lot about IPv6. Is it or isn’t it? Will it be or won’t it be? When it will be and just get ready for it. So here I go. This is by no means an in-depth look into IPv6 or ICMPv6, and I still have a lot more to learn. But this is my start, and maybe it will help somebody else get started also.

I’m studying for my CCIE R&S written again, as my 2 lab attempts have not gone so well. I came across a question with the answer being “Packet Too Big” message is sent back to the source. This “Packet Too Big message” is part of the Path MTU Discovery mechanism, and is vital to IPv6 sending packets now that fragmentation happens at the IPv6 host and is not done by the router.

“As in IPv4, path MTU discovery in IPv6 allows a host to dynamically discover and adjust to differences in the MTU size of every link along a given data path. In IPv6, however, fragmentation is handled by the source of a packet when the path MTU of one link along a given data path is not large enough to accommodate the size of the packets. Having IPv6 hosts handle packet fragmentation saves IPv6 router processing resources and helps IPv6 networks run more efficiently.” (To see where the quote is from and more information about PMTUD, click here.)

The journey begins to see this packet in Wireshark.

This is an easy setup; I think this lab (configs at the end of the post) will show me what I want to see.

  • Get a little help from an ipv6 access-list and ipv6 traffic-filter on R1 to block the packet-too-big messages.
  • Connect as R1 <-> R2 <-> R3.
  • Set the ‘R2(config-if)# ipv6 mtu 1280’ on the interface between R2 <-> R3.
  • Start a ping on R1 destined for R3 with size set to 1510 for good measure ‘R1#ping 2323:2222::3 size 1510’.

R1#ping 2323:2222::3 size 1510

Type escape sequence to abort.

Sending 5, 1510-byte ICMP Echos to 2323:2222::3, timeout is 2 seconds:

…..

Success rate is 0 percent (0/5)

You can see the icmpv3 packet-too-big messages being blocked with the ipv6 acl:

R1#sh ipv6 access-list

IPv6 access list ICMP_DENY

deny icmp any any packet-too-big (9 matches) sequence 10

permit icmp any any (10 matches) sequence 20

permit ipv6 any any sequence 30

Great, so now we need to let those ICMP ‘packet-too-big’ messages flow, or we are not going to get any traffic across our new and better-than-sliced-bread IPv6 network…

Let’s change up that ipv6 access-list to let them through and see the difference:

R1#ping 2323:2222::3 size 1510

Type escape sequence to abort.

Sending 5, 1510-byte ICMP Echos to 2323:2222::3, timeout is 2 seconds:

B.!!!

Success rate is 60 percent (3/5), round-trip min/avg/max = 28/46/64 ms

R1#sh ipv6 access-list

IPv6 access list ICMP_DENY

permit icmp any any packet-too-big (5 matches) sequence 10

permit icmp any any (14 matches) sequence 20

permit ipv6 any any sequence 30

Bonus – we even got a new character in that ping output above. That is new-to-me the letter ‘B’. I assume that stands for packet-too-big, and so let’s take a look at the Wireshark now:

Now run the test again, and see what is on Wireshark:

R1#ping 2323:2222::3 size 1510

Type escape sequence to abort.

Sending 5, 1510-byte ICMP Echos to 2323:2222::3, timeout is 2 seconds:

!!!!!

Success rate is 100 percent (5/5), round-trip min/avg/max = 24/46/96 ms

There’s no ‘packet-too-big’ packet anymore because R1 knows that the MTU is only 1280 via the first ‘packet-too-big’ message.

On a final note, if the ‘packet-too-big’ messages are blocked, this would still allow smaller packets to go through just fine, but your larger packets would not make it. I can see this being a troubleshooting nightmare if IPv6 and ICMPv6 is not understood.

Back to denying the ‘packet-too-big’ messages:

R1#sh ipv6 access-list

IPv6 access list ICMP_DENY

deny icmp any any packet-too-big (10 matches) sequence 10

permit icmp any any (28 matches) sequence 20

permit ipv6 any any sequence 30

R1#ping  2323:2222::3

Type escape sequence to abort.

Sending 5, 100-byte ICMP Echos to 2323:2222::3, timeout is 2 seconds:

!!!!!

Success rate is 100 percent (5/5), round-trip min/avg/max = 16/44/120 ms

R1#ping  2323:2222::3 size 1500

Type escape sequence to abort.

Sending 5, 1500-byte ICMP Echos to 2323:2222::3, timeout is 2 seconds:

…..

Success rate is 0 percent (0/5)

R1#ping  2323:2222::3 size 1200

Type escape sequence to abort.

Sending 5, 1200-byte ICMP Echos to 2323:2222::3, timeout is 2 seconds:

!!!!!

Success rate is 100 percent (5/5), round-trip min/avg/max = 16/34/84 ms

R1#ping  2323:2222::3 size 1280

Type escape sequence to abort.

Sending 5, 1280-byte ICMP Echos to 2323:2222::3, timeout is 2 seconds:

!!!!!

Success rate is 100 percent (5/5), round-trip min/avg/max = 16/32/64 ms

R1#ping  2323:2222::3 size 1281

Type escape sequence to abort.

Sending 5, 1281-byte ICMP Echos to 2323:2222::3, timeout is 2 seconds:

…..

Success rate is 0 percent (0/5)

So, that is my start with a lab that breaks IPv6 and takes a look at the problem on the wire using Wireshark. I am hoping to get a chance to dig deeper into IPv6 and other issues as I go with my studies. If I ever work on a real world IPv6 network and real world problems, I’ll cover them too. I haven’t yet, but we will see. IPv6 is coming, or so “they” keep telling me.

LAB ROUTER CONFIGURATIONS

hostname R1

ipv6 unicast-routing

!

interface FastEthernet0/0

no ip address

duplex auto

speed auto

ipv6 address 1212:2222::1/64

ipv6 traffic-filter ICMP_DENY in

!

ipv6 route ::/0 1212:2222::2

!

ipv6 access-list ICMP_DENY

deny icmp any any packet-too-big

permit icmp any any

permit ipv6 any any

hostname R2

ipv6 unicast-routing

!

interface FastEthernet0/0

no ip address

duplex auto

speed auto

ipv6 address 1212:2222::2/64

!

interface FastEthernet0/1

no ip address

duplex auto

speed auto

ipv6 address 2323:2222::2/64

ipv6 mtu 1280

hostname R3

ipv6 unicast-routing

!

interface FastEthernet0/1

no ip address

duplex auto

speed auto

ipv6 address 2323:2222::3/64

!

ipv6 route ::/0 2323:2222::2

Garry Baker
"Keep it simple. When in doubt during design, choose the simplest solution." - RFC1958 On Twitter @networkbaker
Garry Baker
  • http://twitter.com/Mierdin Mierdin

    Good post. Path MTU discovery is a little-known concept in IPv6 and it’s good to see a technical post about it.

    By the way, IPv6 *is* here now, the question is “where”. I hear Asia has a lot of real-world IPv6 experience to offer…. :-)

  • Anonymous

    This works a lot like PTB messages with ICMP v4.  Most operating systems were operating with
    the DF bit set to 1 anyway so routers in the middle were not fragmenting packets
    anyway.  Black hole detection with DF=1
    is described in RFC 1191.  I agree, fragmentation
    is not the router’s job and just chews up CPU time.

     

    But ICMP PTB messages are still not the best solution.  We need to push the OS vendors to support Packetization
    Layer Path MTU Discovery (RFC 4821).  In
    PLPMT the end-stations “sense” the proper MTU by monitoring what packets never arrive
    at the destination.  The routers don’t
    need to do anything; the end-stations do all the hard work of carving up their
    payloads to fit the proper MTU. 

     

    With PLPMD us network nerds could deploy jumbo gram links
    incrementally over time and the end-stations would take advantage of the new
    capacity automagically.  Wouldn’t it be
    nice to get out of the 1500-byte hole!

7ads6x98y