How to send arbitrary IPv6 ICMP packets, or am I using npingincorrectly?

Discussion in 'Linux Networking' started by Andrew Gideon, Feb 12, 2014.

  1. I've concluded that one of my upstreams is filtering certain types of IPv6
    ICMP packets even when the source and destination are not within its network.
    Specifically, I don't see the "ttl exceeded" ICMP packets triggered by a
    traceroute when those packets would pass though the upstream's network.

    When I direct these packets to reach my network through another upstream,
    they appear w/o a problem.

    I'm finding it tough to convince the upstream of the problem. They keep
    making assertions about what their routers send, apparently missing the
    point that the issue is not what their devices are sending but what their
    devices are forwarding.

    To help explain the situation, and also to better test the situation, I'd
    like to be able to explicitly send ICMP packets of all types - including
    "ttl exceeded" - from the command line. Unfortunately, I'm having
    difficulty finding a tool for this in IPv6.

    I have found tools hping and sing, for example, but they don't seem to support

    I've also found nping within nmap. It appeared to support IPv6 from the
    documentation, but when I try it:

    # nping --ipv6 --traceroute 2607:f8b0:4006:803::1008

    Starting Nping 0.5.51 ( ) at 2014-02-12 13:21 EST
    sendto in send_packet: sendto(3, packet, 20, 0,, 28) => Network is unreachable
    Offending packet: BOGUS! IP Version in packet is not 4
    Sleeping 15 seconds then retrying

    What's more odd is that pinging a link-local address works:

    # nping --ipv6 --traceroute fe80::230:48ff:fe81:5b77

    Starting Nping 0.5.51 ( ) at 2014-02-12 13:22 EST
    SENT (0.1078s) TCP :::1288 > fe80::230:48ff:fe81:5b77:80 S seq=4095443278 win=1480
    SENT (1.1081s) TCP :::1288 > fe80::230:48ff:fe81:5b77:80 S seq=4095443278 win=1480
    SENT (2.1093s) TCP :::1288 > fe80::230:48ff:fe81:5b77:80 S seq=4095443278 win=1480

    Am I doing something wrong with nping? Is there some other tool I'm missing that
    will do this?


    Andrew Gideon, Feb 12, 2014
    1. Advertisements

  2. Andrew Gideon

    Rick Jones Guest

    Could they be doing some varaiation on the theme of BCP 38 and
    filtering traffic with a source IP arriving at their network from an
    unexpected place? Or does this happen only with ICMPv6 traffic?
    That makes it sound like it is only the ICMPv6 traffic, but I'll leave
    the question out there just for posterity and to plug BCP 38 a bit :)

    rick jones
    Rick Jones, Feb 12, 2014
    1. Advertisements

  3. Andrew Gideon

    Jorgen Grahn Guest

    As a last resort, you could send raw Ethernet frames (assuming you're
    on Ethernet).

    You'll probably want to use tcpdump to verify that what's sent is what
    you think it is (and to prove to the upstream that the hex dumps you
    show them are really valid ICMPv6). Also I suppose you may have
    difficulties generating the right checksums, if it matters ...

    Despite its name, this Git repo of mine contains (among other things)
    an 'ethercat' utility to do that, by using the fairly recent libpcap
    addition pcap_inject():


    Disclaimer: I wrote that one for my own use, at home and at work.
    No doubt there are other, better raw link-layer senders out there.
    I didn't check very carefully.

    Jorgen Grahn, Feb 12, 2014
  4. I've only seen this with ICMP IPv6 traffic, but that doesn't mean that I
    haven't missed something else.

    They could be doing some form of reverse path filtering (RPF) (which I
    believe is what you mean; correct me if not). However, even if that is
    the case then they're doing it wrong and it needs to be fixed.

    I imagine an argument could be made whether they should be doing loose RPF
    for packets neither to nor from one of their devices, but only passing
    through their network. The argument from them would be interesting, in
    that their internal devices are in address space allocated to them but
    for which they don't announce routes. So any other network applying
    strict RPF would fail to see packets from their devices, including ICMP

    As I understand it, this becomes a problem because any one of those
    routers might need to send an ICMP packet of type 2 ("packet too big")
    back to the source of the original packet. If loose RPF is applied, that
    ICMP packet will never get to the sender of the original packet.

    I admit that I am concerned about this issue. Unless I am
    misinterpreting things, this upstream's desire to "protect" their
    infrastructure by leaving their address space unannounced is going to
    cause problems in IPv6 that may be tough to diagnose.

    In this case I am testing, though, the packets are from (and to) devices
    with IPs that are properly announced.

    As for strict RPF, this makes sense for edge or near-edge networks. The
    packets being filtered our by my upstream are coming from some peering
    point. I'm not familiar with their various settlement agreements, of
    course, but I would imagine that they could legitimately receive packets
    with any routable sources at these peering points.

    Put more simply: I'd expect the upstream to filter packets they receive
    from my network for a valid source. I'd not expect to see packets
    filtered this way from various peering points to my network.

    - Andrew
    Andrew Gideon, Feb 12, 2014
  5. I'm hoping to avoid that, but...

    Thanks. So far, I've not found much else - at least in the IPv6 space -
    either. I did get nping closer to working, only to receive a message
    about a lack of complete IPv6 ICMP support.


    Andrew Gideon, Feb 14, 2014
    1. Advertisements

Ask a Question

Want to reply to this thread or ask your own question?

You'll need to choose a username for the site, which only take a couple of moments (here). After that, you can post your question and our members will help you out.