IPv6 strangeness
-
You have 2 distinctly different networks, one on each interface, LAN and WAN.
Despite the fact that they are cut from the same larger block, they are in fact totally separate and distinct. Sometimes I find it helps to think about this problem from an IPv4 perspective with no NAT. How would you make it work for instance if you had 198.51.100.0/24 on WAN and 203.0.113.0/24 on LAN side?The issue you need to resolve is how the router on WAN interface is going to know how to reach the LAN subnet, it doesn't know about the ba01 subnet, only ba00.
You would need a route on WAN side router to route ...ba01::/64 to ...ba00::2 -
Are you saying you have a static config from your ISP? That's unusual, as DHCP & DHCPv6-PD are normally used. With DHCPv6-PD, both a WAN address and LAN prefix are provided. PfSense will set up routing with the info provided by the ISP. If you in fact have a static config, with addresses provided by the ISP, then you will have to configure routing manually.
Also, with IPv6, the link local addresses are often used for routing, not the global address.
-
Thank you @awebster and @JKnott for your comments. I will attempt setting a static route on the WAN side like @awebster suggests; regarding @JKnott's comment I must say that while in theory ipv6 should work how you describe it, my ISP (in its infinite knowledge) wants customers to use GPON boxes and the issue i have is, the GPON box as provided by the ISP has a slight issue, it is hardcoded to be limited to a class C IPv4 wise (groan) and IPv6 wise the prefix they assign me (a /56) is the endpoint, meaning, no further subdelegation is possible. Between that and the fact that the GPON's manufacturer's firmware (Huawei, heavily customized and locked down by the ISP) as implemented has some issues where the IPv6 GUA is lost periodically I feel that there should be a better way -- hence why I choose to use static addresses. I know, bad design; I know, bad of the ISP; but my choices in this are, shall we say, limited (meaning practically nil). So faced with the choice between enabling the ISP's bad behavior by using, say, ndproxy, and having to work extra... i choose the extra work. I will set up the static routing; or perhaps OSPF. Something to mull over some coffee.
Cheers and thank you for the feedback. Will report back with progress.
-
If your ISP uses DHCP, you must also use it. You can't just use static configuration. With some systems, they won't even talk to a device that doesn't use DHCP. As for using a /56, that's nonsense. You can only use a /64 on the LAN. That /56 is intended to be used for up to 256 /64s. I suspect there's some miscommunication between you and your ISP.
-
Well, this is a familiar theme... ISP assigns large block to end customer without any way of subnetting and routing it further downstream. Somehow they assume the customer is going to stick all their devices downstream from the ONT without there being any routers or further subnetting. Here's another one: large hosting provider assigns larger than /64 block to customer without any way of controlling downstream routing, and logically the customer wants to protect their VMs from the nasties on the Internet.
In both cases the providers assume that the customer's device(s) have enough smarts to figure things out, the problem is that some don't, at least out of the box, namely pfSense.
While it is true that this is technically a broken implementation of IPv6, the industry has pretty much assumed that their clients will be using some sort of IPv6 ND Proxy to make things work. For what appear to be purely ideological reasons, pfSense has chosen not to drink the ND Proxy cool-aid, while noble as it may be, does cause this issue to rear its head over and over again. Just my observation. -
-
My personal opinion is if the internet community does not resist ISPs rolling out unsound IPv6 provisioning, and make them pay by reducing their profits by using providers that properly provision their networks, the installed base will gain more and more inertia and we will be stuck with this garbage forever.
Nothing has changed. The proper way to deploy is to route a subnet to the user. This is just as true in IPv4 as it is when routing a prefix to a user in IPv6.
Chattanooga, Tennessee, USA
A comprehensive network diagram is worth 10,000 words and 15 conference calls.
DO NOT set a source address/port in a port forward or firewall rule unless you KNOW you need it!
Do Not Chat For Help! NO_WAN_EGRESS(TM) -
@Derelict I agree; however I still have a problem and I need a solution. Philosophically, I feel that this routing nonsense on part of ISPs is due to them still thinking of IPv6 in terms of addresses instead of subnets. Part of the IPv4 legacy, I suppose; and one that should wane, hopefully, as the correct routing philosophy and best practices get implemented. Practically, though, when I ran my tests with the new configuration shown in previous post I got the following:
ping6 -I igb1 www.google,com
ping6: sendmsg: No route to host
ping6: wrote www.google.com 16 chars, ret=-1I'm open to ideas / suggestions.
TIA.
-
We haven't been told anything about how your network is actually provisioned.
What is in the setup document provided by your ISP?
-
Provisioning is as follows:
Prefix is 2001:818.d9d9:ba00::/56 provisioned through DHCPv6. No further subdelegation possible from it. I've tried. The silences I get from technical support at my ISP are eloquent as to their level of preparedness.
ISP responds, when queried, that IPv6 should "just work" if I plug my computers directly to the ONT. And it does, except that it doesn't because the IPv6 lease disappears when I power anything down, when the laptops go to sleep, whenever the wireless signal gets a little weak, and won't reprovision until I've reset the network adapter. It gets old, fast. They won't give any other technical details as to routing, prefixes, &c. I am in utter darkness and working by trial and error here.
-
@Derelict, I too agree that IPv6 networks should be provisioned properly.
My observation is that the problem at its root is not one of technology, but one of human nature, namely the path of least resistance. Consider these two juxtaposed statements:- If the provider can save time and money by rolling out their IPv6 addressing in a way that removes the need for them to have to configure additional routing in their devices, surely they will choose that path.
- Similarly, if the pfSense developers choose to save time and effort by not including an ND Proxy functionality because the problem affects a tiny subset of their installed base, surely they will also choose that path.
I am unaware of any RFC document that clearly states that one MUST NOT use an ND Proxy in their network, consequently, the provider is free to choose to use that methodology of reaching their downstream clients.
Furthermore, the official reference to ND Proxy, RFC 4389 "Neighbor Discovery Proxies (ND Proxy)" section 1.3, states that the ND Proxy is inapplicable "when configuration of the router can (emphasis mine) be done". Notice that the RFC itself doesn't use the terminology from BPC 14, RFC 2119 to which it refers in the very next section.
By using the word "can", it leads to confusion as to the applicability of that very statement. The provider could argue they "can't" make configuration changes to their router for any number of operational reasons, thus justifying the requirement for use of an ND Proxy.
Additionally, if the Modem/ONT/box the providers typically install have a working ND Proxy solution, it's a pretty sure bet that they aren't going to lift a finger to do it "the right way".
In all honesty, the provider doesn't care if the customer has to go look elsewhere for "proper" connectivity, sadly there isn't a critical mass of pfSense users to make a difference.On this topic, I'm having déjà vu, but aside from it being an ideological issue, does it really hurt anyone to implement the functionality?
–A.
-
@cmpsalvestrini said in IPv6 strangeness:
Philosophically, I feel that this routing nonsense on part of ISPs is due to them still thinking of IPv6 in terms of addresses instead of subnets.
Philosophically, nothing. Factually, they're clueless. They can't expect anyone to put a /56 directly on a LAN. That might work with a /64, but not /56.
If they provide a /56, they have to be able to route to it and leave it to you to split it into /64s.
-
I had an epiphany of storts. What if I use ULA and NPT? I've never looked at that option seriously, but I might consider it now. Of course there is the ultimate irony: That I -- having native IPv6 from my ISP -- be forced to use HE.net's tunnel broker (drumroll).
Will test & report back.
-
That wouldn't work either. There's be no way for packets to be routed to your LANs.
I'm on an ISP called Rogers. They provide a /56 via DHCPv6-PD, which provides everything pfSense needs to work with up to 256 /64s. If they receive a packet for one of my /64s, then they forward it to pfSense, which in turn forwards it as appropriate. Without the ISP forwarding traffic, that won't work.
-
@awebster Putting a /56 on an interface is complete nonsense and they should be laughed out of existence and ridiculed at every opportunity.
What ISP/Hosting/colo is this, anyway?
@cmpsalvestrini said in IPv6 strangeness:
Prefix is 2001:818.d9d9:ba00::/56 provisioned through DHCPv6.
Do this:
Pick an address from some random /64 there like 2001:818.d9d9:bafe::1
Start a packet capture on your WAN for all IPv6 with 2001:818.d9d9:bafe::1 as the host.
Find an outside way to ping6 it and ping6 it. (http://www.ipv6now.com.au/pingme.php)
Stop and examine the packet capture. Do you see ND for that address or ICMP6 arriving to that address as the destination?
Please also show us the resulting WAN configuration in Status > Interfaces
-
@Derelict the ISP is Vodafone Portugal - I may be switching ISPs because of this nonsense. Will do as you ask, & post results.
Edit - Got the packet capture, I find exactly zero ND on the first run. Doing a second run now, to confirm, with another address.
Edit #2 - Packet capture done. here are the results.
°fa-info°(23:08:07.944717 IP6 2001:818:d9d9:ba00:a940:4aec:d1aa:a207.63919 > 2001:818:d9d9:ba00:6eb3:11ff:fe1b:5402.53: UDP, length 46
23:08:07.944760 IP6 2001:818:d9d9:ba00:6eb3:11ff:fe1b:5402.53 > 2001:818:d9d9:ba00:a940:4aec:d1aa:a207.63919: UDP, length 12
23:08:12.698103 IP6 2001:818:d9d9:ba00:a940:4aec:d1aa:a207 > 2001:818:d9d9:ba00:6eb3:11ff:fe1b:5402: ICMP6, neighbor solicitation, who has 2001:818:d9d9:ba00:6eb3:11ff:fe1b:5402, length 32
23:08:12.698120 IP6 2001:818:d9d9:ba00:6eb3:11ff:fe1b:5402 > 2001:818:d9d9:ba00:a940:4aec:d1aa:a207: ICMP6, neighbor advertisement, tgt is 2001:818:d9d9:ba00:6eb3:11ff:fe1b:5402, length 24
23:08:17.580837 IP6 2001:818:d9d9:ba00:6eb3:11ff:fe1b:5402 > 2001:818:d9d9:ba00:a940:4aec:d1aa:a207: ICMP6, neighbor solicitation, who has 2001:818:d9d9:ba00:a940:4aec:d1aa:a207, length 32
23:08:17.582350 IP6 2001:818:d9d9:ba00:a940:4aec:d1aa:a207 > 2001:818:d9d9:ba00:6eb3:11ff:fe1b:5402: ICMP6, neighbor advertisement, tgt is 2001:818:d9d9:ba00:a940:4aec:d1aa:a207, length 32
23:08:19.840689 IP6 2001:818:d9d9:ba00:a940:4aec:d1aa:a207.60675 > 2001:818:d9d9:ba00:6eb3:11ff:fe1b:5402.53: UDP, length 55
23:08:19.840732 IP6 2001:818:d9d9:ba00:6eb3:11ff:fe1b:5402.53 > 2001:818:d9d9:ba00:a940:4aec:d1aa:a207.60675: UDP, length 12
23:08:19.842781 IP6 2001:818:d9d9:ba00:a940:4aec:d1aa:a207.60675 > 2606:4700:4700::1001.53: UDP, length 55
23:08:19.842796 IP6 2001:818:d9d9:ba00:a940:4aec:d1aa:a207.60675 > 2606:4700:4700::1001.53: UDP, length 55
23:08:19.842803 IP6 fe80::6eb3:11ff:fe1b:5402 > 2001:818:d9d9:ba00:a940:4aec:d1aa:a207: ICMP6, redirect, 2606:4700:4700::1001 to fe80::6eb3:11ff:fe1b:5402, length 152
23:08:29.781571 IP6 2001:818:d9d9:ba00:6eb3:11ff:fe1b:5402.47585 > 2001:4860:4860::8844.53: UDP, length 56
23:08:29.781910 IP6 2001:818:d9d9:ba00:6eb3:11ff:fe1b:5402.17408 > 2606:4700:4700::1111.53: UDP, length 56
23:08:29.785855 IP6 2606:4700:4700::1111.53 > 2001:818:d9d9:ba00:6eb3:11ff:fe1b:5402.17408: UDP, length 220
23:08:29.822875 IP6 2001:4860:4860::8844.53 > 2001:818:d9d9:ba00:6eb3:11ff:fe1b:5402.47585: UDP, length 220
23:08:29.823033 IP6 2001:818:d9d9:ba00:6eb3:11ff:fe1b:5402.60656 > 2001:4860:4860::8844.53: UDP, length 51
23:08:29.856275 IP6 2001:4860:4860::8844.53 > 2001:818:d9d9:ba00:6eb3:11ff:fe1b:5402.60656: UDP, length 136
23:08:31.983364 IP6 2001:818:d9d9:ba00:265e:beff:fe1e:8b45.37127 > 2001:818:d9d9:ba01::1.53: UDP, length 42
23:08:31.983406 IP6 2001:818:d9d9:ba00:6eb3:11ff:fe1b:5402.53 > 2001:818:d9d9:ba00:265e:beff:fe1e:8b45.37127: UDP, length 12
23:08:31.983415 IP6 2001:818:d9d9:ba02:265e:beff:fe1e:8b45.37127 > 2606:4700:4700::1111.53: UDP, length 42
23:08:31.983427 IP6 2001:818:d9d9:ba02:265e:beff:fe1e:8b45.37127 > 2606:4700:4700::1001.53: UDP, length 42
23:08:31.983427 IP6 2001:818:d9d9:ba02:265e:beff:fe1e:8b45.37127 > 2606:4700:4700::1111.53: UDP, length 42
23:08:31.983438 IP6 2001:818:d9d9:ba02:265e:beff:fe1e:8b45.37127 > 2606:4700:4700::1001.53: UDP, length 42
23:08:31.983444 IP6 2001:818:d9d9:ba00:265e:beff:fe1e:8b45.37127 > 2001:818:d9d9:ba00:6eb3:11ff:fe1b:5402.53: UDP, length 42
23:08:31.983458 IP6 2001:818:d9d9:ba00:6eb3:11ff:fe1b:5402.53 > 2001:818:d9d9:ba00:265e:beff:fe1e:8b45.37127: UDP, length 12
23:08:36.920056 IP6 2001:818:d9d9:ba00:6eb3:11ff:fe1b:5402 > 2001:818:d9d9:ba00:265e:beff:fe1e:8b45: ICMP6, neighbor solicitation, who has 2001:818:d9d9:ba00:265e:beff:fe1e:8b45, length 32
23:08:36.920151 IP6 2001:818:d9d9:ba00:265e:beff:fe1e:8b45 > 2001:818:d9d9:ba00:6eb3:11ff:fe1b:5402: ICMP6, neighbor advertisement, tgt is 2001:818:d9d9:ba00:265e:beff:fe1e:8b45, length 24
23:08:36.993102 IP6 fe80::265e:beff:fe1e:8b45 > 2001:818:d9d9:ba00:6eb3:11ff:fe1b:5402: ICMP6, neighbor solicitation, who has 2001:818:d9d9:ba00:6eb3:11ff:fe1b:5402, length 32
23:08:50.089195 IP6 2001:818:d9d9:ba00:2158:328a:6bd:e98c.51647 > 2001:818:d9d9:ba00:6eb3:11ff:fe1b:5402.53: UDP, length 34
23:08:50.089233 IP6 2001:818:d9d9:ba00:6eb3:11ff:fe1b:5402.53 > 2001:818:d9d9:ba00:2158:328a:6bd:e98c.51647: UDP, length 12
23:08:50.089293 IP6 2001:818:d9d9:ba00:2158:328a:6bd:e98c.62184 > 2001:818:d9d9:ba00:6eb3:11ff:fe1b:5402.53: UDP, length 34
23:08:50.089308 IP6 2001:818:d9d9:ba00:6eb3:11ff:fe1b:5402.53 > 2001:818:d9d9:ba00:2158:328a:6bd:e98c.62184: UDP, length 12
23:08:50.089401 IP6 2001:818:d9d9:ba00:2158:328a:6bd:e98c.59579 > 2001:818:d9d9:ba00:6eb3:11ff:fe1b:5402.53: UDP, length 39
23:08:50.089410 IP6 2001:818:d9d9:ba00:6eb3:11ff:fe1b:5402.53 > 2001:818:d9d9:ba00:2158:328a:6bd:e98c.59579: UDP, length 12
23:08:50.089515 IP6 2001:818:d9d9:ba00:2158:328a:6bd:e98c.65012 > 2001:818:d9d9:ba00:6eb3:11ff:fe1b:5402.53: UDP, length 39
23:08:50.089533 IP6 2001:818:d9d9:ba00:6eb3:11ff:fe1b:5402.53 > 2001:818:d9d9:ba00:2158:328a:6bd:e98c.65012: UDP, length 12
23:08:50.107520 IP6 2001:818:d9d9:ba00:2158:328a:6bd:e98c.54771 > 2001:818:d9d9:ba00:6eb3:11ff:fe1b:5402.53: UDP, length 32
23:08:50.107531 IP6 2001:818:d9d9:ba00:6eb3:11ff:fe1b:5402.53 > 2001:818:d9d9:ba00:2158:328a:6bd:e98c.54771: UDP, length 12
23:08:50.108276 IP6 2001:818:d9d9:ba00:2158:328a:6bd:e98c.49608 > 2001:818:d9d9:ba00:6eb3:11ff:fe1b:5402.53: UDP, length 32
23:08:50.108289 IP6 2001:818:d9d9:ba00:6eb3:11ff:fe1b:5402.53 > 2001:818:d9d9:ba00:2158:328a:6bd:e98c.49608: UDP, length 12
23:08:50.117670 IP6 2001:818:d9d9:ba00:2158:328a:6bd:e98c.58438 > 2001:818:d9d9:ba00:6eb3:11ff:fe1b:5402.53: UDP, length 42
23:08:50.117682 IP6 2001:818:d9d9:ba00:6eb3:11ff:fe1b:5402.53 > 2001:818:d9d9:ba00:2158:328a:6bd:e98c.58438: UDP, length 12
23:08:50.118107 IP6 2001:818:d9d9:ba00:2158:328a:6bd:e98c.55657 > 2001:818:d9d9:ba00:6eb3:11ff:fe1b:5402.53: UDP, length 42
23:08:50.118116 IP6 2001:818:d9d9:ba00:6eb3:11ff:fe1b:5402.53 > 2001:818:d9d9:ba00:2158:328a:6bd:e98c.55657: UDP, length 12
23:08:50.120082 IP6 2001:818:d9d9:ba00:2158:328a:6bd:e98c > 2001:818:d9d9:ba00:6eb3:11ff:fe1b:5402: ICMP6, destination unreachable, unreachable port, 2001:818:d9d9:ba00:2158:328a:6bd:e98c udp port 58438, length 68
23:08:50.120087 IP6 2001:818:d9d9:ba00:2158:328a:6bd:e98c > 2001:818:d9d9:ba00:6eb3:11ff:fe1b:5402: ICMP6, destination unreachable, unreachable port, 2001:818:d9d9:ba00:2158:328a:6bd:e98c udp port 55657, length 68
23:08:50.178559 IP6 2001:818:d9d9:ba00:2158:328a:6bd:e98c.59034 > 2001:818:d9d9:ba00:6eb3:11ff:fe1b:5402.53: UDP, length 34
23:08:50.178571 IP6 2001:818:d9d9:ba00:6eb3:11ff:fe1b:5402.53 > 2001:818:d9d9:ba00:2158:328a:6bd:e98c.59034: UDP, length 12
23:08:50.179713 IP6 2001:818:d9d9:ba00:2158:328a:6bd:e98c.63271 > 2001:818:d9d9:ba00:6eb3:11ff:fe1b:5402.53: UDP, length 34
23:08:50.179724 IP6 2001:818:d9d9:ba00:6eb3:11ff:fe1b:5402.53 > 2001:818:d9d9:ba00:2158:328a:6bd:e98c.63271: UDP, length 12
23:08:50.733725 IP6 2001:818:d9d9:ba00:2158:328a:6bd:e98c.53185 > 2001:818:d9d9:ba00:6eb3:11ff:fe1b:5402.53: UDP, length 42
23:08:50.733765 IP6 2001:818:d9d9:ba00:6eb3:11ff:fe1b:5402.53 > 2001:818:d9d9:ba00:2158:328a:6bd:e98c.53185: UDP, length 12
23:08:50.734117 IP6 2001:818:d9d9:ba00:2158:328a:6bd:e98c.58430 > 2001:818:d9d9:ba00:6eb3:11ff:fe1b:5402.53: UDP, length 42
23:08:50.734133 IP6 2001:818:d9d9:ba00:6eb3:11ff:fe1b:5402.53 > 2001:818:d9d9:ba00:2158:328a:6bd:e98c.58430: UDP, length 12
23:08:51.179880 IP6 2001:818:d9d9:ba00:2158:328a:6bd:e98c.59034 > 2001:818:d9d9:ba00:6eb3:11ff:fe1b:5402.53: UDP, length 34
23:08:51.179897 IP6 2001:818:d9d9:ba00:6eb3:11ff:fe1b:5402.53 > 2001:818:d9d9:ba00:2158:328a:6bd:e98c.59034: UDP, length 12
23:08:51.179908 IP6 2001:818:d9d9:ba00:2158:328a:6bd:e98c.63271 > 2001:818:d9d9:ba00:6eb3:11ff:fe1b:5402.53: UDP, length 34
23:08:51.179919 IP6 2001:818:d9d9:ba00:6eb3:11ff:fe1b:5402.53 > 2001:818:d9d9:ba00:2158:328a:6bd:e98c.63271: UDP, length 12
23:08:51.741577 IP6 2001:818:d9d9:ba00:2158:328a:6bd:e98c.53185 > 2001:818:d9d9:ba00:6eb3:11ff:fe1b:5402.53: UDP, length 42
23:08:51.741588 IP6 2001:818:d9d9:ba00:6eb3:11ff:fe1b:5402.53 > 2001:818:d9d9:ba00:2158:328a:6bd:e98c.53185: UDP, length 12
23:08:51.741685 IP6 2001:818:d9d9:ba00:2158:328a:6bd:e98c.58430 > 2001:818:d9d9:ba00:6eb3:11ff:fe1b:5402.53: UDP, length 42
23:08:51.741696 IP6 2001:818:d9d9:ba00:6eb3:11ff:fe1b:5402.53 > 2001:818:d9d9:ba00:2158:328a:6bd:e98c.58430: UDP, length 12
23:08:52.686759 IP6 2001:818:d9d9:ba00:265e:beff:fe1e:8b45.37127 > 2001:818:d9d9:ba01::1.53: UDP, length 42
23:08:52.686782 IP6 2001:818:d9d9:ba00:6eb3:11ff:fe1b:5402.53 > 2001:818:d9d9:ba00:265e:beff:fe1e:8b45.37127: UDP, length 12
23:08:52.686805 IP6 2001:818:d9d9:ba02:265e:beff:fe1e:8b45.37127 > 2606:4700:4700::1111.53: UDP, length 42
23:08:52.686810 IP6 2001:818:d9d9:ba02:265e:beff:fe1e:8b45.37127 > 2606:4700:4700::1111.53: UDP, length 42
23:08:52.686817 IP6 2001:818:d9d9:ba02:265e:beff:fe1e:8b45.37127 > 2606:4700:4700::1001.53: UDP, length 42
23:08:52.686823 IP6 2001:818:d9d9:ba02:265e:beff:fe1e:8b45.37127 > 2606:4700:4700::1001.53: UDP, length 42
23:08:52.686857 IP6 2001:818:d9d9:ba00:265e:beff:fe1e:8b45.37127 > 2001:818:d9d9:ba00:6eb3:11ff:fe1b:5402.53: UDP, length 42
23:08:52.686870 IP6 2001:818:d9d9:ba00:6eb3:11ff:fe1b:5402.53 > 2001:818:d9d9:ba00:265e:beff:fe1e:8b45.37127: UDP, length 12
23:08:53.015682 IP6 2001:818:d9d9:ba00:2158:328a:6bd:e98c.52059 > 2a01:b740:a41:401::a.443: tcp 0
23:08:53.015698 IP6 2001:818:d9d9:ba00:2158:328a:6bd:e98c.52059 > 2a01:b740:a41:401::a.443: tcp 0
23:08:53.015705 IP6 fe80::6eb3:11ff:fe1b:5402 > 2001:818:d9d9:ba00:2158:328a:6bd:e98c: ICMP6, redirect, 2a01:b740:a41:401::a to fe80::6eb3:11ff:fe1b:5402, length 136
23:08:53.278807 IP6 2001:818:d9d9:ba00:2158:328a:6bd:e98c.52060 > 2a01:b740:a41:409::5.443: tcp 0
23:08:53.278817 IP6 2001:818:d9d9:ba00:2158:328a:6bd:e98c.52060 > 2a01:b740:a41:409::5.443: tcp 0
23:08:53.278821 IP6 fe80::6eb3:11ff:fe1b:5402 > 2001:818:d9d9:ba00:2158:328a:6bd:e98c: ICMP6, redirect, 2a01:b740:a41:409::5 to fe80::6eb3:11ff:fe1b:5402, length 136
23:08:53.531285 IP6 2001:818:d9d9:ba00:2158:328a:6bd:e98c.52061 > 2a01:b740:a41:401::7.443: tcp 0
23:08:53.531307 IP6 2001:818:d9d9:ba00:2158:328a:6bd:e98c.52061 > 2a01:b740:a41:401::7.443: tcp 0
23:08:53.531314 IP6 fe80::6eb3:11ff:fe1b:5402 > 2001:818:d9d9:ba00:2158:328a:6bd:e98c: ICMP6, redirect, 2a01:b740:a41:401::7 to fe80::6eb3:11ff:fe1b:5402, length 136
23:08:53.763758 IP6 2001:818:d9d9:ba00:2158:328a:6bd:e98c > 2001:818:d9d9:ba00:6eb3:11ff:fe1b:5402: ICMP6, neighbor solicitation, who has 2001:818:d9d9:ba00:6eb3:11ff:fe1b:5402, length 32
23:08:53.763772 IP6 2001:818:d9d9:ba00:6eb3:11ff:fe1b:5402 > 2001:818:d9d9:ba00:2158:328a:6bd:e98c: ICMP6, neighbor advertisement, tgt is 2001:818:d9d9:ba00:6eb3:11ff:fe1b:5402, length 24
23:08:54.396038 IP6 2001:818:d9d9:ba00:2158:328a:6bd:e98c.52062 > 2a01:b740:a41:102::4.443: tcp 0
23:08:54.396049 IP6 2001:818:d9d9:ba00:2158:328a:6bd:e98c.52062 > 2a01:b740:a41:102::4.443: tcp 0
23:08:54.396053 IP6 fe80::6eb3:11ff:fe1b:5402 > 2001:818:d9d9:ba00:2158:328a:6bd:e98c: ICMP6, redirect, 2a01:b740:a41:102::4 to fe80::6eb3:11ff:fe1b:5402, length 136
23:08:54.653744 IP6 2001:818:d9d9:ba00:2158:328a:6bd:e98c.52063 > 2a01:b740:a41:107::d.443: tcp 0
23:08:54.653753 IP6 2001:818:d9d9:ba00:2158:328a:6bd:e98c.52063 > 2a01:b740:a41:107::d.443: tcp 0
23:08:54.653756 IP6 fe80::6eb3:11ff:fe1b:5402 > 2001:818:d9d9:ba00:2158:328a:6bd:e98c: ICMP6, redirect, 2a01:b740:a41:107::d to fe80::6eb3:11ff:fe1b:5402, length 136
23:08:54.791802 IP6 2001:818:d9d9:ba00:6eb3:11ff:fe1b:5402 > 2001:818:d9d9:ba00:2158:328a:6bd:e98c: ICMP6, neighbor solicitation, who has 2001:818:d9d9:ba00:2158:328a:6bd:e98c, length 32
23:08:54.794227 IP6 2001:818:d9d9:ba00:2158:328a:6bd:e98c > 2001:818:d9d9:ba00:6eb3:11ff:fe1b:5402: ICMP6, neighbor advertisement, tgt is 2001:818:d9d9:ba00:2158:328a:6bd:e98c, length 24
23:08:54.911315 IP6 2001:818:d9d9:ba00:2158:328a:6bd:e98c.52064 > 2a01:b740:a41:107::15.443: tcp 0
23:08:54.911320 IP6 2001:818:d9d9:ba00:2158:328a:6bd:e98c.52064 > 2a01:b740:a41:107::15.443: tcp 0
23:08:54.911322 IP6 fe80::6eb3:11ff:fe1b:5402 > 2001:818:d9d9:ba00:2158:328a:6bd:e98c: ICMP6, redirect, 2a01:b740:a41:107::15 to fe80::6eb3:11ff:fe1b:5402, length 136
23:08:56.262095 IP6 2001:818:d9d9:ba00:2158:328a:6bd:e98c.52065 > 2a00:1450:400c:c00::6c.993: tcp 0
23:08:56.262108 IP6 2001:818:d9d9:ba00:2158:328a:6bd:e98c.52065 > 2a00:1450:400c:c00::6c.993: tcp 0
23:08:56.262112 IP6 fe80::6eb3:11ff:fe1b:5402 > 2001:818:d9d9:ba00:2158:328a:6bd:e98c: ICMP6, redirect, 2a00:1450:400c:c00::6c to fe80::6eb3:11ff:fe1b:5402, length 136
23:08:56.292762 IP6 2001:818:d9d9:ba00:2158:328a:6bd:e98c.52066 > 2a00:1450:400c:c07::6c.993: tcp 0
23:08:56.292771 IP6 2001:818:d9d9:ba00:2158:328a:6bd:e98c.52066 > 2a00:1450:400c:c07::6c.993: tcp 0
23:08:56.292775 IP6 fe80::6eb3:11ff:fe1b:5402 > 2001:818:d9d9:ba00:2158:328a:6bd:e98c: ICMP6, redirect, 2a00:1450:400c:c07::6c to fe80::6eb3:11ff:fe1b:5402, length 136
23:08:56.584227 IP6 2001:818:d9d9:ba00:2158:328a:6bd:e98c.52067 > 2a00:1450:400c:c07::6c.993: tcp 0
23:08:56.584250 IP6 2001:818:d9d9:ba00:2158:328a:6bd:e98c.52067 > 2a00:1450:400c:c07::6c.993: tcp 0) -
You didn't filter on the specific host so I have no idea what I'm looking at there.
-
Attempted to, packet capture returned blank when I did.
-
@cmpsalvestrini said in IPv6 strangeness:
I find exactly zero ND on the first run.
I see several. ND stands for Neighbor Discovery. It's the IPv6 equivalent of ARP. I see both Neighbor Solicitation and Neigbor Advertisement in your capture. Those are the equivalent of ARP request and reply. Do any of those contain the address you pinged? Also, it's easier to download the capture and use Wireshark to read it.
-
@cmpsalvestrini You need to be specifically looking for ICMP6 neighbor solicitation messages, simply trying to capture while filtering for the host won't show anything because it hasn't been found yet (ie: it doesn't exist), consequently the capture will show nothing.
You are basically looking for the IPv6 equivalent of an ARP WHO-HAS message.
Here is an example of what that actually looks like IRL, but let me set the stage...Host xxxx:yyyy:zzzz:e001::4:9, MAC address: 00:0c:29:cb:fd:01
Host xxxx:yyyy:zzzz:e001::4:61, MAC address: 00:0c:29:d7:c8:44
::4:9 has not talked to ::4:61 recently, so needs to figure out how to do that.
All Ethernet communication is ultimately Layer 2 based, Layer 3 stuff comes after the hosts have figured out how to reach each other.08:38:22.234952 00:0c:29:cb:fd:01 > 33:33:ff:04:00:61, ethertype IPv6 (0x86dd), length 86: xxxx:yyyy:zzzz:e001::4:9 > ff02::1:ff04:61: ICMP6, neighbor solicitation, who has xxxx:yyyy:zzzz:e001::4:61, length 32 08:38:22.234973 00:0c:29:d7:c8:44 > 00:0c:29:cb:fd:01, ethertype IPv6 (0x86dd), length 86: xxxx:yyyy:zzzz:e001::4:61 > xxxx:yyyy:zzzz:e001::4:9: ICMP6, neighbor advertisement, tgt is xxxx:yyyy:zzzz:e001::4:61, length 32In the above capture, you can see host xxxx:yyyy:zzzz:e001::4:9 wanting to communicate with xxxx:yyyy:zzzz:e001::4:61, but it doesn't yet know where to send the packets, so it asks...
Since ..::4:9 doesn't know the Layer 2 MAC address to which to send the packets to, it starts off with a multicast packet to a special IPv6 multicast address composed of the last 24 bits of the IPv6 address (ff02::1:ff00/104 which maps to a Layer 2 multicast address 33:33:ff:xx:xx:xx) - see RFC4291. All devices on the same broadcast domain will hear this message, but presumably there are very few that will actually act on it, and only one will match exactly and trigger a response.
The response packet is an ICMP6 neighbor advertisement back to the sender, thus the sender learns the MAC address to which to direct further traffic.If there is no response to an ICMP6 neighbor solicitation message, traffic shall not pass!
Edit - What the ND Proxy will do in cases where the desired destination is not on the same subnet is respond to that ICMP6 neighbor solicitation message on behalf of devices on the other side of the router, so that the traffic is actually delivered.
