• How to send arbitrary IPv6 ICMP packets, or am I using nping incorrect

    From Andrew Gideon@110:110/2002 to All on Wed Feb 12 18:25:52 2014
    Subject: How to send arbitrary IPv6 ICMP packets, or am I using nping
    incorrectly?


    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 IPv6.

    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 ( http://nmap.org/nping ) at 2014-02-12 13:21 EST
    sendto in send_packet: sendto(3, packet, 20, 0, 0.0.0.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 ( http://nmap.org/nping ) 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?

    Thanks...

    Andrew

    --- MBSE BBS v1.0.1 (GNU/Linux-i386)
    * Origin: UsenetServer - www.usenetserver.com (110:110/2002@linuxnet)
  • From Rick Jones@110:110/2002 to All on Wed Feb 12 18:59:47 2014
    Subject: Re: How to send arbitrary IPv6 ICMP packets, or am I using nping incorrectly?

    Andrew Gideon <c182driver9@gideon.org> wrote:
    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.

    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?

    Specifically, I don't see the "ttl exceeded" ICMP packets triggered
    by a traceroute when those packets would pass though the upstream's
    network.

    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
    --
    Wisdom Teeth are impacted, people are affected by the effects of events.
    these opinions are mine, all mine; HP might not want them anyway... :)
    feel free to post, OR email to rick.jones2 in hp.com but NOT BOTH...

    --- MBSE BBS v1.0.1 (GNU/Linux-i386)
    * Origin: the Unofficial HP (110:110/2002@linuxnet)
  • From Jorgen Grahn@1:0/0 to All on Wed Feb 12 19:09:52 2014
    Subject: Re: How to send arbitrary IPv6 ICMP packets, or am I using nping
    incorrectly?

    On Wed, 2014-02-12, Andrew Gideon wrote:

    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.
    ....
    Is there some other tool I'm missing that
    will do this?

    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():

    git://snipabacken.se/udptools

    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

    --
    // Jorgen Grahn <grahn@ Oo o. . .
    \X/ snipabacken.se> O o .

    --- MBSE BBS v1.0.1 (GNU/Linux-i386)
    * Origin: The Kofo System II BBS telnet://fido2.kofobb
  • From Andrew Gideon@110:110/2002 to All on Wed Feb 12 19:31:17 2014
    Subject: Re: How to send arbitrary IPv6 ICMP packets, or am I using nping
    incorrectly?

    On Wed, 12 Feb 2014 18:59:47 +0000, Rick Jones wrote:

    Andrew Gideon <c182driver9@gideon.org> wrote:
    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.

    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?

    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 packets.

    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

    --- MBSE BBS v1.0.1 (GNU/Linux-i386)
    * Origin: UsenetServer - www.usenetserver.com (110:110/2002@linuxnet)
  • From Andrew Gideon@110:110/2002 to All on Fri Feb 14 16:50:40 2014
    Subject: Re: How to send arbitrary IPv6 ICMP packets, or am I using nping
    incorrectly?

    On Wed, 12 Feb 2014 19:09:52 +0000, Jorgen Grahn wrote:

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

    I'm hoping to avoid that, but...

    [...]

    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.

    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.

    Thanks...

    Andrew

    --- MBSE BBS v1.0.1 (GNU/Linux-i386)
    * Origin: UsenetServer - www.usenetserver.com (110:110/2002@linuxnet)