IPV6

[billion_fan]

Does any of this really matter?

Does IPV6 give any performance (ie speed) improvements?

No speed improvement, just IPv6 connectivity

[billion_fan]

I have just enabled Ipv6 on my Bipac 8900AX-2400, (on BT Infinity 2)

The suffix is showing as /64

Everything is working correctly, so not sure why I'm getting /64 and everyone else on BT is getting /56

[Morgaine]

@billion_fan: I expect that what you've noticed is just an over-simplification by developers of the information presented.

To be accurately informative, the IPv6 information should be presented in two or more separate lines: eg.

• IPv6 prefix delegated by ISP to the CPE: 2607:c000:812f:6f00::/56
• IPv6 prefix assigned to CPE switch VLAN P1: 2607:c000:812f:6f00::/64
• IPv6 prefix assigned to CPE switch VLAN P2: 2607:c000:812f:6f01::/64

and so on. All the major UK ISPs delegate /56 blocks, and several like AAISP delegate /48. The /64 available at the CPE switch is typically just the base /64 block of the ISP-delegated space. Typically this base block is made available through the CPE's switch just to keep life simple for beginners, but the rest of the ISP delegation is still there ready and waiting to be used.

If the switch is not segmented into VLANs then the CPE would normally assign only the base _:_:_: xx00::/64 block of a /56 to all ports by default, although this could be changed to a larger block by the user if desired. In general though, the switch would typically give direct access only to the base /64 block of a larger ISP-delegated prefix, and if the residence uses multiple /64 blocks (which is recommended in an IETF Best Practice RFC) then this is accomplished by linking appropriate routers for those other blocks into the base /64 block. Inexpensive IPv6 routers like Billion 6300NX make this domestically viable.

It would probably be worthwhile suggesting to Billion developers to make the information provided in IPv6 screens much more informative. As IPv6 becomes ever more common in UK, it might become thought that Billion only gives access to /64, which would of course be incorrect and would harm Billion's good reputation in the UK market. Just a few more lines in the screens would combat this.

[Morgaine]

My ISP is BT. How do I enable IPV6 - BT use a "PD of 56" if that helps.

did this work for you ?

because router is expecting a /64 suffix

but BT are using /56 suffix

Although @Garyy20's post was from Dec 2016, the following might help others who make the same observation, as the situation hasn't changed over the past 6 months.

All of the "Big Three" UK residential ISPs (Sky, BT and Virgin, in current order of size) already delegate or will delegate /56 blocks, in accordance with current IETF advice which replaced the original /48 recommendation with a variable /56 to /48 range of sizes as Best Practice. Presumably the Big Three considered the smallest block in this range, ie. /56, to be adequate for residential customers, which is not too unreasonable. 2^(64-56) = 2^8 = 256 blocks of /64 will suffice for fairly large residences. (It needs to be said that we ignore the precedent of "640k will be enough for anybody" at our peril, but it seems to be the human condition to ignore it anyway.)

IPv6 prefix delegation is not a size negotiation protocol AFAIK, but a simple grant: if it succeeds then the CPE has been delegated the address block that was offered, nothing more and nothing less. An incorrectly implemented router might not realize what size block it was given and assume it was just a /64, but Billion has been in the IPv6 game for a long time and this is very unlikely. My interpretation is that the /64 reported on Billion management screens refers only to the size of the base /64 segment which is accessible through the router's switch. That is totally normal practice in IPv6 CPEs.

The rest of a delegated IPv6 address range is still there to be used, but you'd either have to increase the CPE's LAN size manually to make it accessible on the CPE's switch or else you'd have to configure other routers for higher /64 blocks and link them to the CPE. The replacement of IPv4 broadcast addresses by IPv6 link-local addresses and router solicitation/advertisement makes this an awful lot more user-friendly than in IPv4, in practice quite plug'n'play.

With Sky providing full IPv6 service for a year now, BT having completed full IPv6 network rollout in Oct 2016 as well as halfhearted IPv6 CPE deployment on HH6 only, and with Virgin claiming that IPv6 will become available in mid-2017, now is clearly the right time for IPv6 CPE manufacturers to be highlighting their wares in the UK.

It was a pretty slow start, but I think we're getting there now.

[Morgaine]

I have just enabled Ipv6 on my Bipac 8900AX-2400, (on BT Infinity 2)

The suffix is showing as /64

Everything is working correctly, so not sure why I'm getting /64 and everyone else on BT is getting /56

@billion_fan: Did you get a chance to confirm the size of your delegated prefix? It's easily done with just a handful of tests, by setting the address of a computer (or a spare router) to various addresses throughout the /56 block that has as its base the /64 block reported on your 8900 CPE, and then attempting to route IPv6 packets out through the CPE.

For example, if the 8900 reports that it has a LAN address with a prefix of:

• 2607:c000:812f:6f00::/64

then to test the hypothesis that the CPE has been delegated a prefix of:

• 2607:c000:812f:6f00::/56

you would need to test that the CPE will successfully route out through BT all IPv6 packets with source addresses in the prefix range from:

• 2607:c000:812f:6f00::/64

to:

• 2607:c000:812f:6fff::/64

in other words that it will route the whole /56 prefix range comprising 2^8 = 256 x /64 blocks.

Obviously it's not necessary to test that all 256 /64 blocks are being routed: even just a single test from an address in the top /64 block of the /56 will provide very strong evidence that a /56 prefix has been delegated to the CPE and is being routed properly. For example, giving the test client an IPv6 address of:

• 2607:c000:812f:6fff::1/64

and then using this client to ping an upstream IPv6 address routed through the CPE would provide a minimal yet still highly informative test. If a /56 prefix was not delegated to you then outgoing packets with a source address of .....ff::1/64 would be blocked by the ISP's IPv6 anti-spoofing rules since that source address is in the final (256th) /64 block of a /56, not in the base /64 block.

Morgaine.

[billion_fan]

I have just enabled Ipv6 on my Bipac 8900AX-2400, (on BT Infinity 2)

The suffix is showing as /64

Everything is working correctly, so not sure why I'm getting /64 and everyone else on BT is getting /56

@billion_fan: Did you get a chance to confirm the size of your delegated prefix? It's easily done with just a handful of tests, by setting the address of a computer (or a spare router) to various addresses throughout the /56 block that has as its base the /64 block reported on your 8900 CPE, and then attempting to route IPv6 packets out through the CPE.

For example, if the 8900 reports that it has a LAN address with a prefix of:

• 2607:c000:812f:6f00::/64

then to test the hypothesis that the CPE has been delegated a prefix of:

• 2607:c000:812f:6f00::/56

you would need to test that the CPE will successfully route out through BT all IPv6 packets with source addresses in the prefix range from:

• 2607:c000:812f:6f00::/64

to:

• 2607:c000:812f:6fff::/64

in other words that it will route the whole /56 prefix range comprising 2^8 = 256 x /64 blocks.

Obviously it's not necessary to test that all 256 /64 blocks are being routed: even just a single test from an address in the top /64 block of the /56 will provide very strong evidence that a /56 prefix has been delegated to the CPE and is being routed properly. For example, giving the test client an IPv6 address of:

• 2607:c000:812f:6fff::1/64

and then using this client to ping an upstream IPv6 address routed through the CPE would provide a minimal yet still highly informative test. If a /56 prefix was not delegated to you then outgoing packets with a source address of .....ff::1/64 would be blocked by the ISP's IPv6 anti-spoofing rules since that source address is in the final (256th) /64 block of a /56, not in the base /64 block.

Morgaine.

I haven't yet, as I'm running other tests at the moment with other models, from my last test everything is working fine regarding IPv6

[Morgaine]

@billion_fan writes:

I haven't yet, as I'm running other tests at the moment with other models

If the models that you're currently testing display only the router's own /64 LAN assignment and don't report the delegeted prefix then exactly the same applies to them --- it would be very useful for UK customers to have it confirmed that the router is aware that it has been delegated more than just the base /64, despite not showing it, and that it is actually routing the full /56. It would then be just a minor display limitation and not a router fault.

from my last test everything is working fine regarding IPv6

Did that test include checking that upper blocks in the /56 are being routed?

If received prefix delegation of /56 is not being reported on the router screens, and testing has involved only source addresses within the base /64 block assigned to the router's switch, then "everything is working fine regarding IPv6" hasn't actually tested that the router is working properly with the 255 upper /64 blocks of the /56. It needs official confirmation.

Unofficial testing of this by users with Billion routers would of course be extremely valuable too.

[mickod]

This is a point of interest for me.

I have a topology I'm testing currently where by $My_ISP is providing me a /56 via DHCP-PD. Downstream of my billion is a another wifi device that needs to receive IPv6 addressing via DHCPv6. My billion is setup as a DHCPv6 server and when I access the busybox shell I see that there is a dhcp6s.conf there and that the dhcp6s service is running. My Billion logs this as follows;

Jan 1 00:02:08 (none) daemon.info syslog: Hop limit : 64
Jan 1 00:02:08 (none) daemon.info syslog: Stateful address conf. : No
Jan 1 00:02:08 (none) daemon.info syslog: Stateful other conf. : Yes
Jan 1 00:02:08 (none) daemon.info syslog: Router preference : medium
Jan 1 00:02:08 (none) daemon.info syslog: Router lifetime : 1800 seconds
Jan 1 00:02:08 (none) daemon.info syslog: Reachable time : 0 milliseconds
Jan 1 00:02:08 (none) daemon.info syslog: Retransmit time : 0 milliseconds
Jan 1 00:02:08 (none) daemon.info syslog: Prefix : <removed>::/56
Jan 1 00:02:08 (none) daemon.info syslog: Valid time : 2592000 seconds
Jan 1 00:02:08 (none) daemon.info syslog: Pref. time : 604800 seconds
Jan 1 00:02:08 (none) daemon.info syslog: dhcp6c restart..
Aug 16 12:40:22 (none) daemon.err syslog: dhcpd:udhcp server (v0.9.6) started
Aug 16 12:40:22 (none) daemon.err syslog: dhcpd:unable to open config file: /etc/udhcpd.conf
Aug 16 12:40:25 (none) daemon.debug kernel: IPv6 addrconf: prefix with wrong length 56

The last line being of particular importance.

I do NOT receive an IPv6 addressing via wifi from the downstream wifi device nor do I see DHCPv6 packets in wireshark captures.

I suspect my billion is therefore unable to process IPv6 packets properly as the prefix is a /56. Is this something that anyone can confirm?

[billion_fan]

This is a point of interest for me.

I have a topology I'm testing currently where by $My_ISP is providing me a /56 via DHCP-PD. Downstream of my billion is a another wifi device that needs to receive IPv6 addressing via DHCPv6. My billion is setup as a DHCPv6 server and when I access the busybox shell I see that there is a dhcp6s.conf there and that the dhcp6s service is running. My Billion logs this as follows;

Jan 1 00:02:08 (none) daemon.info syslog: Hop limit : 64
Jan 1 00:02:08 (none) daemon.info syslog: Stateful address conf. : No
Jan 1 00:02:08 (none) daemon.info syslog: Stateful other conf. : Yes
Jan 1 00:02:08 (none) daemon.info syslog: Router preference : medium
Jan 1 00:02:08 (none) daemon.info syslog: Router lifetime : 1800 seconds
Jan 1 00:02:08 (none) daemon.info syslog: Reachable time : 0 milliseconds
Jan 1 00:02:08 (none) daemon.info syslog: Retransmit time : 0 milliseconds
Jan 1 00:02:08 (none) daemon.info syslog: Prefix : <removed>::/56
Jan 1 00:02:08 (none) daemon.info syslog: Valid time : 2592000 seconds
Jan 1 00:02:08 (none) daemon.info syslog: Pref. time : 604800 seconds
Jan 1 00:02:08 (none) daemon.info syslog: dhcp6c restart..
Aug 16 12:40:22 (none) daemon.err syslog: dhcpd:udhcp server (v0.9.6) started
Aug 16 12:40:22 (none) daemon.err syslog: dhcpd:unable to open config file: /etc/udhcpd.conf
Aug 16 12:40:25 (none) daemon.debug kernel: IPv6 addrconf: prefix with wrong length 56

The last line being of particular importance.

I do NOT receive an IPv6 addressing via wifi from the downstream wifi device nor do I see DHCPv6 packets in wireshark captures.

I suspect my billion is therefore unable to process IPv6 packets properly as the prefix is a /56. Is this something that anyone can confirm?

Have you tried to connect a PC directly to the Billion to see if obtains a IPv6 address??

Attached is some screen shot examples of my setup (all clients receive a IPv6 address, and pass 10/10 with http://test-ipv6.com/)

[mickod]

Yes I can attach clients directly to the Billion ethernet ports and they get an IPv6 address and work without issue - however, not via dhcpv6.

They seem to get their IP address via SLAAC (ICMPv6) according to wireshark pcap files I've checked.

Thanks,
mick