Getting /56 prefix but WAN uses another one?
-
I don't use PE because there is no SLAAC in my network. I prefer DHCPv6. I captured the incoming traffic and it shows me that this is definately not my traffic what is coming "back".
Netgate 6100 MAX
-
@mrsunfire said in Getting /56 prefix but WAN uses another one?:
But the /128 should be in the same deligated subnet? It's clearly not. I don't get it why.
No it shouldn't. It has absolutely nothing to do with the assigned prefix. It's not even used in routing. It's sole purpose is to provide an address for the WAN port, so that you can connect to it with a VPN, SSH, etc., or use ping & traceroute. Your routing is over the link local address, not the public address.
-
@netblues said in Getting /56 prefix but WAN uses another one?:
And if you don't have a static delegation, hiding ipv6 addreses isn't worth the trouble.
It will change soon.The prefix should not normally change. In fact, there's a setting to keep it from changing.
-
@JKnott Do not allow PD/Address releasedhcp6c will send a release to the ISP on exit, some ISPs then release the allocated address or prefix. This option prevents that signal ever being sent
This one?
-
@mrsunfire said in Getting /56 prefix but WAN uses another one?:
OK thanks for the clearup. But it's still strange that I get so many responses to addresses that doesn't exist on my network.
My prefix is the same since over a year. So I stay with that to hide what is not needed to show :)
What prefix do those addresses have? If it's your assigned prefix, then those devices likely exist on your network somewhere. Privacy addresses were mentioned above. These addresses use random numbers for the suffix and you get a new one every day. After a week they expire. This is in addition to the consistent address (often MAC based). So, each device could have up to 8 global addresses.
As for hiding your prefix, you do understand that each /64 contains 18.4 billion, billion addresses, which means it would be somewhat difficult for anyone to find a working address in that space. That address space is more than 4 billion times the entire IPv4 address space.
-
@netblues said in Getting /56 prefix but WAN uses another one?:
Temporary addresses are not connectable/pingable
They most certainly are. Any address that has your network's prefix is reachable. However, your firewall will block any access, unless specifically allowed. So, if you wanted to run a server that could be reached from elsewhere, you'd use the consistent IPv6 address and open the ports for that address only. All outgoing connections normally use the privacy addresses, so even if someone collects the address, they'd still be up against the firewall not letting them in.
-
-
@JKnott said in Getting /56 prefix but WAN uses another one?:
@mrsunfire said in Getting /56 prefix but WAN uses another one?:
OK thanks for the clearup. But it's still strange that I get so many responses to addresses that doesn't exist on my network.
My prefix is the same since over a year. So I stay with that to hide what is not needed to show :)
What prefix do those addresses have? If it's your assigned prefix, then those devices likely exist on your network somewhere. Privacy addresses were mentioned above. These addresses use random numbers for the suffix and you get a new one every day. After a week they expire. This is in addition to the consistent address (often MAC based). So, each device could have up to 8 global addresses.
As for hiding your prefix, you do understand that each /64 contains 18.4 billion, billion addresses, which means it would be somewhat difficult for anyone to find a working address in that space. That address space is more than 4 billion times the entire IPv4 address space.
No they're not inside my Prefix. But they are in the same format as the WAN address. I captures my WAN traffic and there is nothing going out from my network to those destinations from where I get replies. Maybe something at my ISP is misconfigured?
-
Run packet capture on DNS to see if there's any pattern to this. If you're seeing DNS replies back to your network, then something on your network is causing them.
-
There are coming back but there are no going out. Even the hosts I‘ve never heared.
