Some very nice IPv6 growth as measured by Google

Bjørn Mork bjorn.mork at
Tue Nov 4 13:27:03 CET 2014

"Eric Vyncke (evyncke)" <evyncke at> writes:

>      *   Norway:
> If you are behind those growths, I would love to hear more details: technology  used, issues, …

As others have stated, the growth in Norway is caused by an increase in
the number of Telenor retail ADSL, VDSL and GPON customers with native
dual stack access.

Erik has already provided some details on the CPE side.  So I will try
to add a bit of network details.

The L2 access network is as stated: a mix of xDSL and GPON.

We do use PPPoE for some IPv4 xDSL accesses, but for IPv6 it has been
decided to only support IPoE.  So the PPPoE support remains IPv4 only
(for now at least - I'm not going to predict the future here).

The IP "sessions" are terminated on Juniper MX access servers (BNGs or
whatever), which also function as DHCP and DHCPv6 servers.  The DHCPv6
server will hand out a single IA_NA address dynamically allocated [1]
from a pool local to the access server, and a single IA_PD prefix
statically allocated to the user.  The local DHCPv6 server use a RADIUS
backend for the per-user static configuration.  The users are identified
by an DHCPv6 Relay Agent Remote-ID being added by the DSLAM or OLT,
functioning as an RFC6221 Lightweight DHCPv6 Relay Agent.

We have not committed to any fixed policy for the retail user IA_PD
prefixes. They are currently /48s, aggregated on /36 boundaries [2] on
the access servers. Which means that the prefix is changed if the user
switches to another access server. Typically only when physically
moving, but might also happen due to changes in the access network
topology.  For most users the prefix will remain the same "forever".
It's just not guaranteed anywhere.  Note that this also goes for the
prefix length, although I don't currently see any valid reason to change

Business users use the exact same infrastructure, but their prefixes are
not aggregated by the access servers.  This allows them to be truly
static from a technical point of view.  The actual policy will probably
depend on the specific product/agreement.  I don't know anything about

A default IPv6 route is announced by the MXes using RAs with no prefix
option.  I.e. there are no on-link prefixes on the WAN link.  Which is
logical for an ISP access network. Users on different links are not
supposed to talk to each other on L2.

We do not support reverse DNS for retail users at the moment.

There have of course been a gazillion minor issues.  I don't even
remember a fraction of them. Some of it has been related IPv6 multicast,
filtering and DHCPv6 relaying support in the L2 access network. This is
still a grey area, requiring hardware replacements to be 100% complete.

There are lots of details, so please ask if you are missing some
specific information...

 [1] The IA_NA address is mainly intended for CPE management purposes,
     which is why it doesn't matter that it changes for each DHCPv6

 [2] access servers with more than 4096 users aggregate on multiple /36s
     Using as few prefix lengths as possible and cutting on nibble
     boundaries are deliberate strategies to simplify address management
     Thanks to lazy developers :-)

Bjørn (lazy Telenor developer)

More information about the ipv6-ops mailing list