What's new

IPv6 icmp6 permitted by default from WAN to LAN

  • SNBForums Code of Conduct

    SNBForums is a community for everyone, no matter what their level of experience.

    Please be tolerant and patient of others, especially newcomers. We are all here to share and learn!

    The rules are simple: Be patient, be nice, be helpful or be gone!

foodog

New Around Here
By default, it looks like IPv6 ICMP traffic is permitted from any source external to any destination internally. I am not seeing a method to disable this. This permits any Internet source to trace into an internal network, and perform a ping scan. Is there a suggested method to disable this?

Running 386.7_2 native ipv6 stateless.

Foodog
 
By default, it looks like IPv6 ICMP traffic is permitted from any source external to any destination internally.
This is by design, as RFCs explicitly state that ICMPv6 nodes need to reply to ICMP requests. Asus has been following the RFCs to the letter there as to which ICMPv6 types to allow and which to filter.
 
Dos Protection is enabled. Here is the output from THC-ipv6 implementation6 executed from a system using v6 from another network sending packets via the internet to a system located on the Lan behind a RT-AC3100. The app implementation6 performs various ipv6 icmp and packet mod attempts to ping an ipv6 addr.

[tester@home1] implementation6 eth0 2605:59c8:31be:xxxx:xxxx:xxxx:xxxx:xxxx

Performing implementation checks on 22605:59c8:31be:xxxx:xxxx:xxxx:xxxx:xxxx via eth0:
Test 0: normal ping6 PASSED - we got a reply
Test 1: hop-by-hop ignore option FAILED - no reply
Test 2: hop-by-hop ignore option 2kb size FAILED - no reply
Test 3: 2 hop-by-hop headers FAILED - no reply
Test 4: 128 hop-by-hop headers FAILED - no reply
Test 5: destination ignore option PASSED - we got a reply
Test 6: destination ignore option 2kb size FAILED - no reply
Test 7: 2 destination headers PASSED - we got a reply
Test 8: 128 destination headers FAILED - no reply
Test 9: 2000 destination headers FAILED - no reply
Test 10: 8172 destination headers FAILED - no reply
Test 11: correct fragmentation PASSED - we got a reply
Test 12: one-shot fragmentation PASSED - we got a reply
Test 13: too large fragmentation EH FAILED - no reply
Test 14: overlap-first-zero fragmentation FAILED - no reply
Test 15: overlap-last-zero fragmentation FAILED - no reply
Test 16: overlap-first-dst fragmentation FAILED - no reply
Test 17: overlap-last-dst fragmentation FAILED - no reply
Test 18: source-routing (done) PASSED - we got a reply
Test 19: source-routing (todo) FAILED - no reply
Test 20: unauth mobile source-route FAILED - no reply
Test 21: mobile+source-routing (done) FAILED - error reply [4:0]
Test 22: fragmentation source-route (done) PASSED - we got a reply
Test 23: fragmentation source-route (todo) FAILED - no reply
Test 24: hop-by-hop fragmentation source-route FAILED - error reply [2:0]
Test 25: destination fragmentation source-route PASSED - we got a reply
Test 26: fragmentation hop-by-hop source-route FAILED - no reply
Test 27: fragmentation destination source-route PASSED - we got a reply
Test 28: node information FAILED - no reply
Test 29: inverse neighbor solicitation FAILED - no reply
Test 30: mobile prefix solicitation FAILED - no reply
Test 31: certificate solicitation FAILED - no reply
Test 32: ping6 with a zero AH extension header FAILED - no reply
Test 33: TCP-SYN(1) with a zero AH extension header FAILED - no reply
Test 34: extension header with two bytes of ping6 FAILED - no reply
Test 35: ping6 with a zero ESP extension header FAILED - no reply
Test 36: ping from multicast (local!) FAILED - no reply
Test 37: frag+source-route to link local FAILED - no reply
Test 38: frag+source-route to multicast FAILED - no reply
Test 39: frag+srcroute from link local (local!) FAILED - no reply
Test 40: frag+srcroute from multicast (local!) FAILED - no reply
Test 41: direct neighbor solicitation FAILED - no reply
Test 42: direct neighbor solicitation ttl<255 FAILED - no reply
Test 43: filled ignore hop-by-hop option FAILED - no reply
Test 44: filled padding hop-by-hop option FAILED - no reply
Test 45: filled ignore destination option PASSED - we got a reply
Test 46: filled padding destination option PASSED - we got a reply
Test 47: jumbo option size < 64k FAILED - error reply [4:0]
Test 48: jumbo option size < 64k, length 0 FAILED - error reply [4:0]
Test 49: error option in hop-by-hop FAILED - error reply [4:2]
Test 50: error option in dsthdr FAILED - error reply [4:2]
Test 51: 0 length field FAILED - no reply
Test 52: too large length field FAILED - no reply
Test 53: too small length field FAILED - no reply
Test 54: ping6 with bad checksum FAILED - no reply
Test 55: ping6 with zero checksum FAILED - no reply
Test 56: ping with hop count 0 FAILED - no reply
Test 57: fragment missing FAILED - no reply
Test 58: normal ping6 (still alive?) PASSED - we got a reply

Foodog
 
This is by design, as RFCs explicitly state that ICMPv6 nodes need to reply to ICMP requests. Asus has been following the RFCs to the letter there as to which ICMPv6 types to allow and which to filter.
Yes - Nodes do, however a router or security device is required to respond with a reason for not passing a packet. RFC4443 section 3.1 response type 1 code 1 represents communications with destination administratively prohibited. Administratively prohibited can be due to a firewall or filter. Also, a code 5 could be sent if there is an egress or ingress filter.

Is there a different RFC which states a router must pass icmp6?
 
Yes - Nodes do, however a router or security device is required to respond with a reason for not passing a packet. RFC4443 section 3.1 response type 1 code 1 represents communications with destination administratively prohibited. Administratively prohibited can be due to a firewall or filter. Also, a code 5 could be sent if there is an egress or ingress filter.

Is there a different RFC which states a router must pass icmp6?

ICMP is much more important with IPv6. For example PMTUD is now required and critical with IPv6 where IPv4 could live without it. Several other functions use it too. Ping itself probably isn't needed, if those are allowed through it probably is due to IPv6 still not being fully hashed out in home routers. One of the reasons I and many others don't enable it.
 
Is there a different RFC which states a router must pass icmp6?
The firmware makes a distinction between routed and local traffic. From the source code, here are the allowed types, and the RFC 4890 section that mentions it:

Code:
// RFC-4890, sec. 4.3.1
const int allowed_icmpv6[] = { 1, 2, 3, 4, /*128,*/ 129 };
// RFC-4890, sec. 4.4.1
const int allowed_local_icmpv6[] =
        { 130, 131, 132, 133, 134, 135, 136,
          141, 142, 143,
          148, 149, 151, 152, 153 };
 
I see a potential new student at ipv6.he.net/certification in @foodog ...
 
Give it a rest with these certification posts.
you've a problem with people gaining knowledge and/or food for thought rather than just getting their problems solved??
 
@heysoundude got great knowledge by keeping it enabled for no reason. ;)
I got enough from that same link to be inspired to dig deeper and make a decision on my own, for my own purposes. That's all I hope for others
 
And after you got the theoretical knowledge (and perhaps got certified) from a tunnel broker company you have enabled it on a home router with known hardware/software issues and almost EOL? Brave, but this is not what I would advice the others.
 
Folks, enough with the bickering, this is off topic.
 

Similar threads

Latest threads

Sign Up For SNBForums Daily Digest

Get an update of what's new every day delivered to your mailbox. Sign up here!
Top