Part #2 of 3 Guide to Copper business static IPv6 setup from Comcast and DHCP-PD on the Comcast CBR-T.

Note that both these behaviors ARE compliant with the rfc3633 standard which says:

   "If the requesting router includes an IA_PD Prefix option in the IA_PD
   option in its Solicit message, the delegating router MAY choose to
   use the information in that option to select the prefix(es) or prefix
   size to be delegated to the requesting router."

In other words you can ask the CBR-T all you want to slice up the IPv6 subnets how you want but it is going to ignore your requests.  The CBR-T will only hand out /59 subnets and that is allowed under standard.

As for changing the prefix it hands out when sent a blank DUID, this is also per the standard which says:

"If the delegating router will not assign any prefixes to any IA_PDs
   in a subsequent Request from the requesting router, the delegating
   router MUST send an Advertise message to the requesting router that
   includes the IA_PD with no prefixes in the IA_PD and a Status Code
   option in the IA_PD containing status code NoPrefixAvail and a status
   message for the user, a Server Identifier option with the delegating
   router's DUID and a Client Identifier option with the requesting
   router's DUID."

In other words, if you don't like the /59 prefix the CBR-T gives you, you can request a different one with a DHCP-PD request using a blank DUID.  You will then get the next available /59 in the /56 subnet.  If you keep doing this and the CBR-T runs out of available /59's then it loops back to the beginning and starts over with the first available one in the /56 subnet.

The problem with this trick is once the DHCP-PD allocation expires on the requesting router, a DHCP-PD renew with a blank DUID will change the prefix.  So every time the allocation expires you have to start banging away at the CBR-T until you get back to your original prefix.

The User Router I am using, (the Cisco 2800) has no option for sending a blank DUID in the DHCP-PD request.  It always sends a filled-out DUID and will always get back the same prefix assigned initially.

On the Cisco 2800 the command:

show ipv6 dhcp

will print out

This device's DHCPv6 unique identifier(DUID): blahblahblahblahblah

With Cisco IOS, DHCPv6 forms the DUID using MAC  address from the lowest-numbered interface by assuming that the network interface is permanently attached to the device.

All of that is per standard implementation even if you don't like it or other DHCP-PD routers don't work that way.  Some of the complaints in the forum are complaints that the CBR-T won't honor DHCP-PD hints but doing that is compliant with the standard.

What IS possibly a bug in the CBR-T is as I mentioned above it is capable of handing out /59 subnets that it won't route.  This is where it gets annoying.

It APPEARS to me that when the CBR-T is rebooted that it "selects" on boot the /59 that it is going to hand out on a DHCP-PD request.  Each time the CBR-T is restarted this seems to change even though the global prefix does not change.  For example the CBR-T may be handing out

2603:3004:273:f900::/59

then it is power cycled, and hands out

2603:3004:273:f920::/59

So on initial setup you may need to power cycle it a few times to get it to work around to a "usable" subnet

As I said, get the device on a good UPS so a momentary power blip won't scotch your routing configuration.

I cannot do further testing on this because I do not have a router that can send a blank DUID and I don't want to spend the time building one.  I would appreciate someone else testing this further.

One last thing about the CBR-T is the issue with ICMP redirect routes.  RFC1009 states:

A gateway will generate an ICMP Redirect if and only if the
destination IP address is reachable from the gateway (as
determined by the routing algorithm) and the next-hop gateway is
on the same (sub-)network as the source host."

So if the CBR-T gets an IPv6 packet with a destination of the Cisco 2800 by standard it will not issue a redirect to the sending host.

When looking at the IPv6 routing table on my webservers that are in the Public LAN, it only shows a default IPv6 route pointing to the link local interface of the CBR-T.  If I send an ICMPv6 ping to them from an IPv6 host on the Private LAN, then even though the ping packet makes it to the host and returns, it is not symmectrical.   The packet originates from the Private LAN host, goes to my Cisco 2800, is then sent to the webserver, but the return packet does not go back to the Cisco 2800.  Instead it is sent to the CBR-T which sees that it's destination is part of the DHCP-PD route that it handed out to the User Router, and sends it back across the LAN to that, which then forwards it back to the Private LAN host.  The CBR-T router COULD be issuing an ICMPv6 redirect pointing to the DHCP-PD prefix it handed out earlier but it does not.  As a result traffic from Private LAN hosts to the webservers travels the Public LAN twice, and also increases the load on the CBR-T's CPU.

Of course, if the traffic is light, it probably is less work to just ignore this problem since the IPv6 traffic will make it from the Private LAN to the Public LAN and back.  But since I sometimes do large file copies I have added static IPv6 routes for the DHCP-PD /59 route into my webservers.

Note that by default the route command in Linux DOES NOT print out learned ICMP redirects that are in the Linux cache.  You must add the -C modifier if you want to view these.

Another way to fix this is for the upstream router to advertise back the /59 to the Public LAN but I cannot seem to get my Cisco 2800 to advertise the /59 it obtained via DHCP-PD out the Public LAN interface.  (there's a command for doing this but it just seems to create an empty route in the webservers)

Instructions

The next part of this guide is a set of step by step instructions on setup of IPv6, starting from when you have the CBR-T router online, passing IPv4 traffic, and you are able to surf the web using IPv4 from a PC plugged into the CBR-T.