Stumped by IPv6 (LAN/WAN)
-
If we have more that 65k devices on the network I think we'll have other problems than IP allocation ;D
Edit: misread, but even better with 18,446,744,073,709,551,616 addresses available in a single /64 :D and we don't use/need a guest network currently so we should be ok.
-
Here all my ISP gives me:
IPv6 LAN prefix 2a02:578:4a08::/48
IPv6 WAN prefix 2a02:578:8401:8400::/64I'm curious about this, because I find it interesting how much difference there is in the ipv6 support that's provided by ISPs. When you say your ISP "gives" you the above WAN and LAN prefixes, how did they "give" them to you? Did they provide these prefixes in an email or in your account on their website or what? As far as I know, there is no way to use use a WAN prefix with pfSense or even a purpose for one, even though residential gateways typically do have a WAN prefix and a global WAN address.
-
Honestly I'm still a bit lost as of how IPv6 allocation/nat/… works.
Regarding this /48 | /64, those ranges are in my account online. The thing is, at home I have the same provider but with a "consumer" SLA and when I activated IPv6 I only got a /56 LAN range and no WAN range.
For the purpose of having outbound IPv6 connectivity both work fine but I don't know what I can do with the "/64 WAN". Maybe I should contact them for explanations but currently it works fine for my needs.
-
Here all my ISP gives me:
IPv6 LAN prefix 2a02:578:4a08::/48
IPv6 WAN prefix 2a02:578:8401:8400::/64I'm curious about this, because I find it interesting how much difference there is in the ipv6 support that's provided by ISPs. When you say your ISP "gives" you the above WAN and LAN prefixes, how did they "give" them to you? Did they provide these prefixes in an email or in your account on their website or what? As far as I know, there is no way to use use a WAN prefix with pfSense or even a purpose for one, even though residential gateways typically do have a WAN prefix and a global WAN address.
When I worked for an ISP and I deployed IPv6 on the network and for some beta customers, this was how I allocated the prefixes for them. It's most to record the information and to setup any PTP interfaces and static routes.
Usually I would tell my customers to use the /64 for their router/fw. I would take ::1 and that they could use anything else from there but typically ::2 would make most sense. The /48 they could carve out as they wished and configure their LAN. I would simply point this /48 as a static route to their ::2 which is why we typically needed to know what their numbering scheme was going to be on the WAN interface of their router/fw. We did not use DHCP or any kind of NAT. It was all manual but then we only offered to business customers and not residential.
LoboTiger
-
The thing is, at home I have the same provider but with a "consumer" SLA and when I activated IPv6 I only got a /56 LAN range and no WAN range.
I'm not sure what you mean by "WAN range". I have a single WAN IPv6 address, which is part of a /64 prefix. Other customers would also have an address within that prefix. On the LAN side, I also have a /64 all to myself. Since you have a /56, you have 256 /64s, to use as you wish.
You may want to read up on how routers work in general. You generally have a block of addresses for the local LAN and a single address on a WAN link to elsewhere. You generally don't get a block on the WAN side, as you only need a single link to carry your traffic. It makes no difference whether IPv4 or IPv6, routers work the same way on both.
-
I'm not sure what you mean by "WAN range". I have a single WAN IPv6 address, which is part of a /64 prefix. Other customers would also have an address within that prefix. On the LAN side, I also have a /64 all to myself. Since you have a /56, you have 256 /64s, to use as you wish.
You may want to read up on how routers work in general. You generally have a block of addresses for the local LAN and a single address on a WAN link to elsewhere. You generally don't get a block on the WAN side, as you only need a single link to carry your traffic. It makes no difference whether IPv4 or IPv6, routers work the same way on both.
I know (mostly) how routers works… what I described is literally what I get in my account...
And at home a /56 "LAN prefix" and nothing for "WAN prefix".
-
I don't know why you don't have a WAN prefix. How are you connected? If you have a cable modem, you'd likely have the same prefix as everyone else. If a PPPoE, then you wouldn't necessarily see a /64, as a point to point link needs only 2 addresses or a /127 prefix. Regardless, you'd still have only one address on the WAN side. As I mentioned, I have a /64 prefix on the WAN side and my router would appear as just a single device to the ISP, just like every other of the 2^64 customers on the prefix. ;)
Either at work or home, you have and need only one IPv6 WAN address (at work you might have more than one link, each of which would have it's own address). You just have a different size prefix at the 2 locations.
-
JKnott, most WAN assigned /64s are given entirely to a single point to point connection/customer (pppoe, ethernet, fiber, etc). That /64 is not shared amongst other users.
LoboTiger
-
That /64 is not shared amongst other users.
If you're on a cable modem, as I am, you might want to fire up Wireshark to take a look at what's coming through the modem, as I have done. You will see IPv4 ARPs and IPv6 ICMP6 for other customers. This shows the cable modem is part of a common network. In addition to the /64 IPv6 prefix, my firewall also has a /23 subnet mask for IPv4. So, my segment is shared by up to 509 other customers. As I mentioned, I can see the broadcast & multicast traffic to/from them.
To save you the trouble, I just did several seconds of TCPDUMP on my firewall. Notice all the other systems, mostly IPv4 but also some IPv6. BTW, I see there are a few different IPv4 subnets, so I have no idea how many customers might be out there.
Here it is:
20:22:15.668389 ARP, Request who-has 99.250.226.186 tell 99.250.224.1, length 46
20:22:15.673804 ARP, Request who-has 104.158.238.35 tell 104.158.238.1, length 46
20:22:15.692207 ARP, Request who-has 24.246.68.250 tell 24.246.68.225, length 46
20:22:15.709360 ARP, Request who-has 99.250.249.208 tell 99.250.240.1, length 46
20:22:15.775872 ARP, Request who-has 72.53.68.54 tell 72.53.68.33, length 46
20:22:15.784347 ARP, Request who-has 72.53.68.55 tell 72.53.68.33, length 46
20:22:15.786823 ARP, Request who-has 99.250.231.40 tell 99.250.224.1, length 46
20:22:15.797424 ARP, Request who-has 99.250.249.11 tell 99.250.240.1, length 46
20:22:15.805900 ARP, Request who-has 209.141.139.214 tell 209.141.139.193, length 46
20:22:15.820629 ARP, Request who-has 107.150.253.174 tell 107.150.253.129, length 46
20:22:15.828705 ARP, Request who-has 24.212.169.13 tell 24.212.169.1, length 46
20:22:15.845483 ARP, Request who-has 99.250.255.159 tell 99.250.240.1, length 46
20:22:15.874611 ARP, Request who-has 99.250.245.223 tell 99.250.240.1, length 46
20:22:15.881412 ARP, Request who-has 99.250.226.186 tell 99.250.224.1, length 46
20:22:15.890539 ARP, Request who-has 99.250.246.41 tell 99.250.240.1, length 46
20:22:15.895715 ARP, Request who-has 72.53.76.216 tell 72.53.76.193, length 46
20:22:15.898090 ARP, Request who-has 99.250.236.181 tell 99.250.224.1, length 46
20:22:15.944073 ARP, Request who-has 72.53.68.149 tell 72.53.68.129, length 46
20:22:15.945572 ARP, Request who-has 104.158.236.139 tell 104.158.236.129, length 46
20:22:15.946874 ARP, Request who-has 209.141.165.155 tell 209.141.165.129, length 46
20:22:15.954499 ARP, Request who-has 104.234.120.127 tell 104.234.120.1, length 46
20:22:15.979658 IP6 2607:f8b0:4001:c05::bd.443 > 2607:fea8:4cdf:feed:3d59:db8d:58ba:2584.53248: UDP, length 43
20:22:15.990629 ARP, Request who-has 104.158.238.122 tell 104.158.238.1, length 46
20:22:15.991734 IP6 2607:fea8:4cdf:feed:a0f1:9449:fd3f:db6a.50267 > 2607:f8b0:400b:806::200e.443: UDP, length 163
20:22:15.991746 IP6 2607:fea8:4cdf:feed:a0f1:9449:fd3f:db6a.50267 > 2607:f8b0:400b:806::200e.443: UDP, length 293
20:22:15.993905 ARP, Request who-has 99.250.252.55 tell 99.250.240.1, length 46
20:22:16.004504 IP6 fe80::214:d1ff:fe2b:edea > fe80::217:10ff:fe91:41f: ICMP6, echo request, seq 38209, length 8
20:22:16.004536 IP 174.112.12.127 > 174.112.12.1: ICMP echo request, id 51882, seq 38209, length 8
20:22:16.004990 IP6 2607:fea8:4cdf:feed:3d59:db8d:58ba:2584.53248 > 2607:f8b0:4001:c05::bd.443: UDP, length 40
20:22:16.009861 IP6 2607:f8b0:400b:806::200e.443 > 2607:fea8:4cdf:feed:a0f1:9449:fd3f:db6a.50267: UDP, length 32
20:22:16.013964 IP6 fe80::217:10ff:fe91:402 > fe80::214:d1ff:fe2b:edea: ICMP6, time exceeded in-transit for fe80::217:10ff:fe91:41f, length 56
20:22:16.026136 ARP, Request who-has 45.2.73.238 tell 45.2.73.129, length 46
20:22:16.061267 ARP, Request who-has 99.250.245.238 tell 99.250.240.1, length 46
20:22:16.066041 ARP, Request who-has 72.53.68.57 tell 72.53.68.33, length 46
20:22:16.074777 IP6 2607:f8b0:400b:806::200e.443 > 2607:fea8:4cdf:feed:a0f1:9449:fd3f:db6a.50267: UDP, length 70
20:22:16.074810 IP6 2607:f8b0:400b:806::200e.443 > 2607:fea8:4cdf:feed:a0f1:9449:fd3f:db6a.50267: UDP, length 279
20:22:16.075310 IP6 2607:fea8:4cdf:feed:a0f1:9449:fd3f:db6a.50267 > 2607:f8b0:400b:806::200e.443: UDP, length 46
20:22:16.098522 ARP, Request who-has 99.250.226.186 tell 99.250.224.1, length 46
20:22:16.100021 ARP, Request who-has 99.250.226.186 tell 99.250.224.1, length 46
20:22:16.101597 ARP, Request who-has 99.250.226.186 tell 99.250.224.1, length 46
20:22:16.114625 ARP, Request who-has 209.141.139.214 tell 209.141.139.193, length 46
20:22:16.128377 ARP, Request who-has 104.158.236.135 tell 104.158.236.129, length 46
20:22:16.133477 ARP, Request who-has 107.150.250.190 tell 107.150.250.129, length 46
20:22:16.153831 ARP, Request who-has 99.250.246.129 tell 99.250.240.1, length 46
20:22:16.205989 ARP, Request who-has 209.141.139.215 tell 209.141.139.193, length 46
20:22:16.212741 ARP, Request who-has 107.150.250.209 tell 107.150.250.129, length 46
20:22:16.240894 ARP, Request who-has 99.250.236.127 tell 99.250.224.1, length 46
20:22:16.242394 ARP, Request who-has 99.250.226.186 tell 99.250.224.1, length 46
20:22:16.244495 ARP, Request who-has 99.250.250.235 tell 99.250.240.1, length 46
20:22:16.247946 ARP, Request who-has 209.141.165.149 tell 209.141.165.129, length 46
20:22:16.252546 ARP, Request who-has 99.250.237.239 tell 99.250.224.1, length 46
20:22:16.256348 ARP, Request who-has 107.150.250.139 tell 107.150.250.129, length 46
20:22:16.257972 ARP, Request who-has 99.250.243.237 tell 99.250.240.1, length 46
20:22:16.266299 ARP, Request who-has 99.250.233.7 tell 99.250.224.1, length 46
20:22:16.308955 ARP, Request who-has 104.158.236.216 tell 104.158.236.129, length 46
20:22:16.341135 ARP, Request who-has 107.150.250.133 tell 107.150.250.129, length 46
20:22:16.381667 ARP, Request who-has 104.204.120.146 tell 104.204.120.129, length 46
20:22:16.386667 ARP, Request who-has 104.234.121.168 tell 104.234.121.129, length 46
20:22:16.419473 ARP, Request who-has 72.53.68.55 tell 72.53.68.33, length 46
20:22:16.442351 ARP, Request who-has 216.181.152.38 tell 216.181.152.1, length 46
20:22:16.470631 ARP, Request who-has 72.53.68.53 tell 72.53.68.33, length 46
20:22:16.493385 ARP, Request who-has 192.0.213.83 tell 192.0.213.65, length 46
20:22:16.508476 IP 174.112.12.127 > 174.112.12.1: ICMP echo request, id 51882, seq 38210, length 8
20:22:16.508507 IP6 fe80::214:d1ff:fe2b:edea > fe80::217:10ff:fe91:41f: ICMP6, echo request, seq 38210, length 8
20:22:16.525665 ARP, Request who-has 24.246.67.223 tell 24.246.67.193, length 46
20:22:16.532915 ARP, Request who-has 104.204.117.193 tell 104.204.117.129, length 46
20:22:16.581823 ARP, Request who-has 99.250.238.201 tell 99.250.224.1, length 46
20:22:16.673538 ARP, Request who-has 104.234.120.49 tell 104.234.120.1, length 46
20:22:16.712769 ARP, Request who-has 209.141.139.214 tell 209.141.139.193, length 46
20:22:16.728421 ARP, Request who-has 104.204.120.245 tell 104.204.120.129, length 46
20:22:16.747374 ARP, Request who-has 99.250.230.140 tell 99.250.224.1, length 46
20:22:16.750075 ARP, Request who-has 99.250.226.186 tell 99.250.224.1, length 46
20:22:16.771054 ARP, Request who-has 99.250.225.245 tell 99.250.224.1, length 46
20:22:16.772752 ARP, Request who-has 99.250.250.248 tell 99.250.240.1, length 46
20:22:16.781256 ARP, Request who-has 99.250.235.143 tell 99.250.224.1, length 46
20:22:16.791781 ARP, Request who-has 72.53.67.238 tell 72.53.67.225, length 46
20:22:16.813009 ARP, Request who-has 72.53.68.159 tell 72.53.68.129, length 46
20:22:16.824061 ARP, Request who-has 45.2.75.63 tell 45.2.75.1, length 46
20:22:16.844090 ARP, Request who-has 209.141.139.214 tell 209.141.139.193, length 46
20:22:16.845965 ARP, Request who-has 99.250.238.209 tell 99.250.224.1, length 46
20:22:16.847865 ARP, Request who-has 72.53.68.55 tell 72.53.68.33, length 46
20:22:16.906025 ARP, Request who-has 209.141.139.214 tell 209.141.139.193, length 46
20:22:16.946031 ARP, Request who-has 99.250.226.55 tell 99.250.224.1, length 46
20:22:17.001716 ARP, Request who-has 99.250.249.3 tell 99.250.240.1, length 46
20:22:17.004840 ARP, Request who-has 72.53.68.174 tell 72.53.68.161, length 46
20:22:17.010497 IP6 fe80::214:d1ff:fe2b:edea > fe80::217:10ff:fe91:41f: ICMP6, echo request, seq 38211, length 8
20:22:17.010524 IP 174.112.12.127 > 174.112.12.1: ICMP echo request, id 51882, seq 38211, length 8
20:22:17.022298 IP6 fe80::217:10ff:fe91:402 > fe80::214:d1ff:fe2b:edea: ICMP6, time exceeded in-transit for fe80::217:10ff:fe91:41f, length 56
20:22:17.068859 IP6 2607:fea8:4cdf:feed:a0f1:9449:fd3f:db6a.55838 > 2607:f8b0:4001:c1e::bc.5228: tcp 0
20:22:17.071726 ARP, Request who-has 99.250.231.88 tell 99.250.224.1, length 46
20:22:17.075752 ARP, Request who-has 107.150.250.222 tell 107.150.250.129, length 46
20:22:17.086354 ARP, Request who-has 104.234.121.186 tell 104.234.121.129, length 46
20:22:17.091053 ARP, Request who-has 99.250.246.142 tell 99.250.240.1, length 46
20:22:17.095979 ARP, Request who-has 72.53.68.76 tell 72.53.68.65, length 46
20:22:17.100382 IP6 2607:f8b0:4001:c1e::bc.5228 > 2607:fea8:4cdf:feed:a0f1:9449:fd3f:db6a.55838: tcp 0
20:22:17.110983 ARP, Request who-has 104.204.117.160 tell 104.204.117.129, length 46
20:22:17.135786 ARP, Request who-has 99.250.247.45 tell 99.250.240.1, length 46
20:22:17.155914 ARP, Request who-has 99.250.237.60 tell 99.250.224.1, length 46
20:22:17.166392 ARP, Request who-has 99.250.230.234 tell 99.250.224.1, length 46
20:22:17.172592 ARP, Request who-has 104.204.120.243 tell 104.204.120.129, length 46 -
My gateway has a /56. Out of the /56, one /64 is used for LAN addresses and one /64 is used for the WAN address. This is done by the ISP and the gateway. OP's ISP apparently provides a /48 for LAN addresses and a /64 for a WAN address. I find it somewhat silly that a /64 is delegated for one address, but I guess OP's ISP doesn't see it that way. Presumably the WAN address is used by the ISP for managing the gateway.
-
JKnott, wow that's pretty interesting. I guess a cable modem setup is different than other point to point solutions. Very interesting. Thanks for the capture btw.
bimmerdriver, the /64 assignment has probably more to do with how legacy support for ipv6 was implemented long ago. From what I've been told and read, there are a lot of devices that don't work well when you go beyond the /64 CIDR notation. Even at the ISP level of discussions at NANOG and such, some places still recommended going with /64s for router to router connections simply to keep things in line. Others decided that a /126 (equivalent of a /30) was still good enough. Nonetheless, it is rather wasteful but I do believe that even with this much waste, we'll still not likely exhaust all of the IPv6 addressing within our lifetimes.
LoboTiger
-
I guess a cable modem setup is different than other point to point solutions.
Cable is a broadcast domain type network, not point to point. On the other hand, PPPoE, as used on ADSL is a point to point connection. So only packets intended for the customer appear on the link. In fact, point to point links have to be specifically configured to properly handle broadcast and multicast traffic, unlike broadcast domains.
and a /64 for a WAN address.
If you're on a cable modem, run TCPDUMP for a several seconds and see what turns up. I wouldn't be surprised if you're just one customer of many on that prefix, as I am.
From what I've been told and read, there are a lot of devices that don't work well when you go beyond the /64 CIDR notation
The specs require a /64 for the local LAN and SLAAC won't work without it.
Others decided that a /126 (equivalent of a /30) was still good enough.
There are certainly enough addresses so that it doesn't hurt to be so wasteful. On the other hand, it opens up the possibility of some DoS attacks. Also, a point to point link requires only 2 addresses or /127 prefix. This is covered in RFC 6547.
-
Well, both home and office lines are VSDL2 but I assume the home connection could still be on a shared /64 wan. I'll have a look at what's provided to the modem tonight (if it's available). From what I see here, the WAN interface got an IP in the /64, the LAN in the /48 and everyone inside gets an IP in the first /64 of the /48 so everything seems correct.
Quick question, I assume I can assign multiple "public" IPv6 in the WAN range and create NAT rules on them like I would for IPv4?
Thanks a lot to everyone for your answers, I've learned a lot about IPv6!
-
Why on earth would you want to run NAT??? It's a hack to get around the IPv4 address shortage. You said you had a /56 at home. That's 256 /64s. Why would you need to worry about those on the WAN side, with all those available?
BTW, a good reference for IPv6 is a book from O'Reilly called IPv6 Essentals.
http://shop.oreilly.com/product/0636920023432.do -
One other thing to consider. On broadcast type networks, such as Ethernet, routing is done via the link local address, not the assigned IPv6 address. So, on my pfSense router/firewall, the /64 applies to the link local address. The assigned IPv6 address is a /128, which refers only to an interface, not a network. With PPPoE, as you'd have with DSL, there is normally no MAC address and so no link local address, unless one is specifically created. You'll have to keep this in mind when talking about prefixes etc..
-
Why on earth would you want to run NAT??? It's a hack to get around the IPv4 address shortage. You said you had a /56 at home. That's 256 /64s. Why would you need to worry about those on the WAN side, with all those available?
BTW, a good reference for IPv6 is a book from O'Reilly called IPv6 Essentals.
http://shop.oreilly.com/product/0636920023432.dook maybe not nat but what's the point of giving me two "network" for the office connexion (on my home /56 lan I don't need to open anything I just wanted to compare)? Hopefully the given IPv6 on the lan are not actually public/open by default otherwise that will be a problem.
I'll probably get that book, hopefully it will shed some light on all this.
-
Actually, they are real, public addresses, every one of them. It's up to your firewall to keep them "private". Any IPv6 address that starts with a 2 or 3, in the first digit, is a public (global) address.
