IPv6 Comcast Business Beta

gadams999

I recently received my new firewall hardware for testing Comcast IPv6 and am having challenges understanding their nomenclature along with how pfSense deals with IPv6 configuration. North Atlanta area.

Right now I have a physical port dedicated just for the IPv6 test router and have VLANed by LAN interface for a couple internal networks. The Netgear modem has two different areas that I haven't been able to figure out exactly what they mean.

By default it came as shown, but I've tried configs with the User Define Prefix enabled or disabled. My "assumption" is that the IPv6 Prefix is what is presented for prefix delegations, at it matches Comcast's announcement that BCI users get a /56.

So, the way I've setup my pfSense (2.1-RELEASE) device is as follows:

WAN:

IPv6 Configuration Type: DHCP6
Use IPv4 Connectivity - unchecked (I don't use this connection for IPv4)
Request only a IPv6 prefix - checked (have tried unchecked too)
DHCPv6 Prefix Delegation size - /56 to match what Comcast presents
Send IPv6 prefix hint - checked
Block bogons - unchecked

LAN:

IPv6 Address: Track interface
IPv6 Prefix ID: 0 or something different (10, F0, etc)
Block bogons - unchecked

(have to select track interface then save for the 0 - FF prefix option, then save//apply to take effect)

When setup like this and interfaces saved and changed, what I get for an IPv6 address on interfaces is:

WAN: 2601:0:9280:xxxx:(MAC address of pfSense) prefixlen 64 autoconf (ifconfig only – not on GUI)
WAN: fe80::macaddress%em2

LAN: fe80::1:1%em0_vlan_name

So with the /56, the WAN does get an IPv6 address in the 2601:: range and default gateway points to Comcast modem. Ping6 to ipv6.google.com works fine.

The LAN has that weird fe80:: address (not using the full MAC address) and no delegation.

My log file starts showing these messages (unsure if this is normal or not):

Oct 21 18:03:58 patti php: rc.newwanipv6: rc.newwanipv6: on (IP address: fe80::200:xxxx:fed0:38a6%em2) (interface: opt3) (real interface: em2).
Oct 21 18:03:59 patti php: rc.newwanipv6: ROUTING: setting IPv6 default route to 2601:0:xxxx:800:22e5:xxxx:feb7:f94f
Oct 21 18:03:59 patti check_reload_status: Reloading filter
Oct 21 18:04:13 patti php: rc.newwanipv6: rc.newwanipv6: Informational is starting em2.
Oct 21 18:04:13 patti php: rc.newwanipv6: rc.newwanipv6: on (IP address: fe80::200:xxxx:fed0:38a6%em2) (interface: opt3) (real interface: em2).
Oct 21 18:04:14 patti php: rc.newwanipv6: ROUTING: setting IPv6 default route to 2601:0:xxxx:800:22e5:xxxx:feb7:f94f
Oct 21 18:04:14 patti check_reload_status: Reloading filter
Oct 21 18:04:28 patti php: rc.newwanipv6: rc.newwanipv6: Informational is starting em2.
Oct 21 18:04:28 patti php: rc.newwanipv6: rc.newwanipv6: on (IP address: fe80::200:xxxx:fed0:38a6%em2) (interface: opt3) (real interface: em2).

Which ping-pongs between link-local and the valid IP address.

Now, if I change the WAN to an /64 prefix, save and apply, without modifying the "track interface" on the LAN, the LAN interface picks up an address inside the /56 range (2601:0:9280:yyyy where yyy is the next /57 up - 0400 to 0480)

inet6 2601:0:9280:yyyy:200:xxxx:fed0:38a4 prefixlen 64
inet6 fe80::1:1%em0_vlan10 prefixlen 64 scopeid 0x9

radv starts up but the local Windows client has the fe80::1:1 as the default gateway.

There are no XID mismatches or other indications of things going wrong, so my guess is I don't understand all the nuances of IPv6; there is some errors between pfSense 2.1 and Comcast; removing and readding IPv6 addresses to my interfaces is causing old config data to come back.

Is there a way to remove all IPv6 configs from my firewall so I can start from a clean slate?

I know that Comcast is issuing the /56's via DHCP, but when I tried to slice up the /56 and statically assign a /64 to the LAN interface, that didn't seem to work.

Any guidance on this would be helpful. Trying to figure out if it's a pfSense error or some craziness with Comcast.

razzfazz

@gadams999:

By default it came as shown, but I've tried configs with the User Define Prefix enabled or disabled. My "assumption" is that the IPv6 Prefix is what is presented for prefix delegations, at it matches Comcast's announcement that BCI users get a /56.

No, it's the "system delegated prefix" (as the name suggests). The "IPv6 prefix" field lists the prefix on the WAN side of the business gateway; i.e., the prefix that "IPv6 address" belongs to.

@gadams999:

So, the way I've setup my pfSense (2.1-RELEASE) device is as follows:
(…)

When setup like this and interfaces saved and changed, what I get for an IPv6 address on interfaces is:

WAN: 2601:0:9280:xxxx:(MAC address of pfSense) prefixlen 64 autoconf (ifconfig only -- not on GUI)
WAN: fe80::macaddress%em2

I assume this is an address that falls into the "system delegated prefix" in your screenshot. If the WAN interface on your pfSense box is indeed getting an IPv6 address from the delegated prefix, that implies that the Comcast business gateway functions as a router, and you're basically trying to operate a second router (pfSense) behind that. If you use the full /56 on the segment between the Comcast gateway and the pfSense box, you don't have anything left to delegate, so that's why your LAN side is not getting a valid IPv6 address in that case.

@gadams999:

Now, if I change the WAN to an /64 prefix, save and apply, without modifying the "track interface" on the LAN, the LAN interface picks up an address inside the /56 range (2601:0:9280:yyyy where yyy is the next /57 up - 0400 to 0480)

inet6 2601:0:9280:yyyy:200:xxxx:fed0:38a4 prefixlen 64
inet6 fe80::1:1%em0_vlan10 prefixlen 64 scopeid 0x9

I haven't worked with a setup like this before, but in theory, if you only use a /64 for the segment between the Comcast box and the pfSense box, you have 255 other /64's that are part of the /56 left to delegate downstream; apparently pfSense is smart enough to figure this out.

@gadams999:

radv starts up but the local Windows client has the fe80::1:1 as the default gateway.

fe80::1:1 as gateway is what you should expect to see for LAN clients.

@gadams999:

There are no XID mismatches or other indications of things going wrong, so my guess is I don't understand all the nuances of IPv6; there is some errors between pfSense 2.1 and Comcast; removing and readding IPv6 addresses to my interfaces is causing old config data to come back.

Are you actually having problems with this, or are you just concerned about these errors?

gadams999

@razzfazz:

@gadams999:

By default it came as shown, but I've tried configs with the User Define Prefix enabled or disabled. My "assumption" is that the IPv6 Prefix is what is presented for prefix delegations, at it matches Comcast's announcement that BCI users get a /56.

No, it's the "system delegated prefix" (as the name suggests). The "IPv6 prefix" field lists the prefix on the WAN side of the business gateway; i.e., the prefix that "IPv6 address" belongs to.

In my attempt to obfuscate info, I didn't describe what was in the two fields. The IPv6 address is the same for both the IP Address/Prefix (first two fields) and the same in the unselected user defined prefix. I wish there was more (any) information on that screen, but nothing back from Comcast yet.

@razzfazz:

@gadams999:

When setup like this and interfaces saved and changed, what I get for an IPv6 address on interfaces is:

WAN: 2601:0:9280:xxxx:(MAC address of pfSense) prefixlen 64 autoconf (ifconfig only – not on GUI)
WAN: fe80::macaddress%em2

I assume this is an address that falls into the "system delegated prefix" in your screenshot. If the WAN interface on your pfSense box is indeed getting an IPv6 address from the delegated prefix, that implies that the Comcast business gateway functions as a router, and you're basically trying to operate a second router (pfSense) behind that. If you use the full /56 on the segment between the Comcast gateway and the pfSense box, you don't have anything left to delegate, so that's why your LAN side is not getting a valid IPv6 address in that case.

Yes, when the prefix delegation size is set on the WAN interface to /56, pfSense gets back a /64 for the Comcast WAN router to the WAN interface on the pfSense box. By setting this, it looks like that provides pfSense with the ability to delegate to other interfaces via track interface.

Comcast says that the IA-PD can be used to grab delegations, but I wonder if there is something wrong with the way their DHCPv6 server or the RA's are being presented/negotiated to pfSense.

@razzfazz:

@gadams999:

Now, if I change the WAN to an /64 prefix, save and apply, without modifying the "track interface" on the LAN, the LAN interface picks up an address inside the /56 range (2601:0:9280:yyyy where yyy is the next /57 up - 0400 to 0480)

inet6 2601:0:9280:yyyy:200:xxxx:fed0:38a4 prefixlen 64
inet6 fe80::1:1%em0_vlan10 prefixlen 64 scopeid 0x9

I haven't worked with a setup like this before, but in theory, if you only use a /64 for the segment between the Comcast box and the pfSense box, you have 255 other /64's that are part of the /56 left to delegate downstream; apparently pfSense is smart enough to figure this out.

This is the weird part. If the WAN is set to delegation of /56, I have the ability to select 00-ff on the tracked interface segment. But in that mode, the LAN never gets a 2006:: address, radv doesn't run, etc. However, if I change the WAN delegation back to a /64 and don't change the prefix on the LAN segment, the above addressing is set and radv starts. The reason I cannot modify the LAN interface at this point is that there are not PD's open, only 0-0 available, which also makes sense since the WAN asked for a /64 which it used.

If the Comcast router is presenting a /56, can the pfSense box take that full delegation for it's own use while they both still use the negotiated /64. For instance, if the prefix is:

2601:0:9280:800::/56
and pfSense is setup with a PD of /56

Could it look like this and be valid?

Internet – Comcast router <-- 2601:0:9:800::/64 --> (WAN) pfsense (LAN) --> 2601:0:9:880/64

@razzfazz:

@gadams999:

radv starts up but the local Windows client has the fe80::1:1 as the default gateway.

fe80::1:1 as gateway is what you should expect to see for LAN clients.

What concerns me about this one is that the fe80::1:1 is the only link-local address on the LAN. the EUI-64 link-local address is no longer there. Is it okay that the EUI-64 address has been replaced with just the fe80::1:1 address?

Appreciate the time on this razzfazz, hopefully once I understand the moving parts, all will become clear. :)

@gadams999:

There are no XID mismatches or other indications of things going wrong, so my guess is I don't understand all the nuances of IPv6; there is some errors between pfSense 2.1 and Comcast; removing and readding IPv6 addresses to my interfaces is causing old config data to come back.

Are you actually having problems with this, or are you just concerned about these errors?

razzfazz

@gadams999:

In my attempt to obfuscate info, I didn't describe what was in the two fields. The IPv6 address is the same for both the IP Address/Prefix (first two fields) and the same in the unselected user defined prefix. I wish there was more (any) information on that screen, but nothing back from Comcast yet.

Oops, my bad; I see now that the "IPv6 address/prefix" fields all refer to the LAN interface on the gateway device.

@gadams999:

This is the weird part. If the WAN is set to delegation of /56, I have the ability to select 00-ff on the tracked interface segment. But in that mode, the LAN never gets a 2006:: address, radv doesn't run, etc.

As I was trying to say earlier, that makes perfect sense: you will use at least part of that /56 on the segment between the Comcast gateway and the pfSense box, so pfSense wouldn't be able to re-delegate the entire /56, and the code doesn't deal well with getting a different prefix size than what's indicated in the prefix delegation size field.

@gadams999:

However, if I change the WAN delegation back to a /64 and don't change the prefix on the LAN segment, the above addressing is set and radv starts. The reason I cannot modify the LAN interface at this point is that there are not PD's open, only 0-0 available, which also makes sense since the WAN asked for a /64 which it used.

If it does actually pick up a valid prefix on the LAN side in this case, I guess I'm not quite sure what the problem is?!

@gadams999:

If the Comcast router is presenting a /56, can the pfSense box take that full delegation for it's own use while they both still use the negotiated /64. For instance, if the prefix is:

The segment between the two is going to use part of the /56, so pfSense will at most be able to further delegate whatever's left after that.

@gadams999:

Could it look like this and be valid?

Internet – Comcast router <-- 2601:0:9:800::/64 --> (WAN) pfsense (LAN) --> 2601:0:9:880/64

Yes, this looks fine. In theory, pfSense could re-delegate up to 2601:0:9:880/57 (the largest sub-prefix of 2601:0:9:800/56 that does not include 2601:0:9:800::/64), any of the sub-prefixes contained therein, or any other sub-prefix of 2601:0:9:800/56 that does not overlap with 2601:0:9:800::/64.

@gadams999:

What concerns me about this one is that the fe80::1:1 is the only link-local address on the LAN. the EUI-64 link-local address is no longer there. Is it okay that the EUI-64 address has been replaced with just the fe80::1:1 address?

Yes; at least that's what I see on my (working) setup.