Problem with IPv6 subnet assignments/ RFC 4193 issue. (RFC 1918 blocking)
-
Hello all:
This is sort of a feature request, and I'm not sure where the post belongs. Please relocate it if need be.
It has been my experience that it is common practice to block IPv4 RFC 1918 private addresses on the WAN interface, where the WAN connection is expected to have a proper world routable IPv4 address.
Under 2.3.3, the toggle for this blocking also invokes blocking for IPv6 RFC 4193 LINK-LOCAL addresses. IPv6 LINK-LOCAL addresses are different from RFC 1918 "private" addresses, and blocking the RFC 4193 addresses can break basic IPv6 functionality.
In my specific use case, blocking RFC 4193 LINK-LOCAL addresses on the WAN breaks IPv6 prefix delegation by my ISP when I request a /56 address block. I can still get a WAN IPv6 address, and the first tracking subnet can get its /64 delegation, but if RFC 4193 addresses are blocked, successive subnets will not get their unique /64 delegations.
I think there really should be two check boxes available on each interface so that RFC 1918, and RFC 4193 addresses may be blocked or admitted independently of each other.
I would like to be able to block RFC 1918, yet admit RFC 4193 addresses, but cannot because of the way the two have been conjoined in the GUI interface.
Cheers,
Bennett -
RFC 4193 addresses are unique local, not link local and are the IPv6 equivalent of RFC 1918 IPv4 addresses. Unique local, like RFC 1918 addresses are not supposed to be passed over the Internet, but are routeable locally. If you've got those from your modem, there's a problem somewhere. Link local addresses (FE80::/64) are often used by routers and other devices.
-
Link local addresses (FE80::/64) are often used by routers and other devices.
Correction, link-local addresses are a mandatory part of IPv6 operation.
-
Yep, I know they're mandatory, but not typically used. However, routers certainly use them, as does Windows Home Group network. Most other traffic is via unicast or multicast addresses. In fact, for most things to use a link local address, you have to specify the interface, yet that's something browsers don't like to support. So, a router will advertise itself to the all nodes multicast address from it's link local address. Also, the router link local address is generally not based on the MAC address. For example, pfSense uses fe80::1:1.
-
Yep, I know they're mandatory, but not typically used. However, routers certainly use them, as does Windows Home Group network. Most other traffic is via unicast or multicast addresses. In fact, for most things to use a link local address, you have to specify the interface, yet that's something browsers don't like to support. So, a router will advertise itself to the all nodes multicast address from it's link local address. Also, the router link local address is generally not based on the MAC address. For example, pfSense uses fe80::1:1.
According to interface status on my systems, the addresses pfsense has for the ISP edge router and for pfsense itself are link local. My systems are configured to block reserved addresses on the wan but not the lan.
-
So your ISP is broken? Why would they be using ULA address space in such a manner??
"but if RFC 4193 addresses are blocked, successive subnets will not get their unique /64 delegations. "
This makes zero sense!!
-
According to interface status on my systems, the addresses pfsense has for the ISP edge router and for pfsense itself are link local.
As is mine. As I mentioned, routers normally use link local addresses. However, a link local address is not an RFC 4193 address.
-
According to interface status on my systems, the addresses pfsense has for the ISP edge router and for pfsense itself are link local.
As is mine. As I mentioned, routers normally use link local addresses. However, a link local address is not an RFC 4193 address.
When you said, "Yep, I know they're mandatory, but not typically used", I thought you were referring to link-local addresses. If that's not what you meant, then disregard my comment.
-
I was referring to link local addresses. While they're commonly used for routers and Windows Home Group networks, they tend not to be used for other purposes, as they are more difficult to use, due to the need to specify the interface, than with other addresses. With browsers, for example, you can't even specify the interface, as you could on a command line. Normally, the destination unicast address contains enough info to determine which interface is used.
-
I was referring to link local addresses. While they're commonly used for routers and Windows Home Group networks, they tend not to be used for other purposes, as they are more difficult to use, due to the need to specify the interface, than with other addresses. With browsers, for example, you can't even specify the interface, as you could on a command line. Normally, the destination unicast address contains enough info to determine which interface is used.
Well, if that's what you think, you are incorrect. Every interface connected to an ipv6 network has an associated link local address, so it's more correct to say that link local addresses are the most common type of ipv6 address. They are set up automatically when a node initially connects to an ipv6 network.
-
Yes, I know every interface has a link local address. No doubt about it. My point is that it's not used for most things. Routers advertise the link local address and other devices use that link local address for the default route. But you can't use browsers with a link local address and you have to specify the interface for everything else, as a given link local address could be on any interface, as there is nothing in the link local address to indicate which interface is used. For example, I just pinged my firewall. When I used the global unicast address, I could just ping it. But to ping the link local address, I had to specify the interface that connected to the firewall, even though there is only one network interface in this computer. i.e. ping6 -I eth0…
So, yes, you could do something like use ssh to connect to a link local address, but why bother, if you have another unicast address, where you don't have to specify the interface?
Regardless, this has gone beyond the original question, where the OP confused link local addresses with unique local addresses.
