IPv6 Subscriber Access Deployments

I'm reading that the recommended method for assigning IPv6 addresses to end-users is to do this via a dedicated VLAN and /64. Some broadband access methods utilize a shared VLAN model with additional security mechanisms in place such as DHCP snooping, source-verify etc. Why wouldn't it be ideal to share the same /64 amongst all subscribers for simplicity?

Joshua Moore
Network Engineer
ATC Broadband
912.632.3161 - O | 912.218.3720 - M

Important question - are you talking about the IPv6 address supplied to
the CPE router itself, or a /48 or /56 delegated to the CPE router to
allocate to subnets and devices behind it?

We are talking a purely bridged environment. However, I have been wondering how in the world end-to-end IPv6 connectivity is supposed to work if a customer hooks up their own router. That is one of the points of IPv6...

Joshua Moore
Network Engineer
ATC Broadband
912.632.3161 - O | 912.218.3720 - M

Short answer to that is “DHCPv6-PD”

Longer answer:

Customer’s router should get an address on the external interface through one of SLAAC, DHCP-PD, Static Assignment, depending on how the ISP prefers to do this.

If the ISPs equipment supports IPv6 on shared VLANs with DHCP snooping and other security, you can implement it with a single /64 giving each router a unique address within that segment, but it’s not really ideal. This was mainly done in IPv4 to conserve addresses. Separate point to point VLANs are a cleaner solution and since there are enough addresses in IPv6 to do this, that is how most providers implement. I prefer using /64s (or at least assigning /64s) to these VLANs, but there are those who argue for /127, some equipment is broken and requires a /126, and yet others argue for other nonsensical prefixes.

Once the router has an external address communicating point to point with the ISP router, it should then send an DHCPv6-PD request asking for a prefix that it can manage. The ISPs DHCP server should then send back a /48 (or if you want to be silly, a /56 or a /60, and if you want to be insane, a /64).

The reality is that if you send a smaller prefix back, you risk having difficulty with your future ARIN applications as your Provider Allocation Unit is based on the smallest prefix you delegate to end-users. So if you, for example, assign /48 to business customers and /60 to residential customers, you’re going to have to justify why each of your business customers needed 4096 /60s when you claim that you need more IPv6 space.

OTOH, if you simply issue /48s to everyone, you can just go back and say “Each end site got a /48 and there are N end-sites” and you’re good, no questions asked about the size of any of those end-sites.

Owen

The question becomes manageability. Unique VLAN per customer is not always scalable. For example, only ~4000 VLAN tags. What happens when you have more than that many customers? Also, provisioning. Who is going to provision thousands of unique prefixes and VLANs, trunk them through relevant equipment and ensure they are secured as well?

We are talking very, very, small customers here. SOHO to say the most. /64 should be more than sufficient for their CPE router.

Joshua Moore
Network Engineer
ATC Broadband
912.632.3161 - O | 912.218.3720 - M

If you use separate VLANs for each customer then the CPE router doesn't
even require an external IPV6 address for DHCPv6-PD. IPV6 link-local
addresses can be used between your BRAS and customer CPE router. Some
CPEs can even allocate a WAN/mgmt IPV6 address out of the delegated
subnet via DHCPv6-PD.

The question becomes manageability. Unique VLAN per customer is not always
scalable. For example, only ~4000 VLAN tags. What happens when you have more
than that many customers?

If you're hanging 4K customers off the same switch, you probably have bigger
issues than running out of VLAN tags...

We are talking very, very, small customers here. SOHO to say the most.
/64 should be more than sufficient for their CPE router.

A Linksys WNDR3800 running CeroWRT (and probably OpenWRT by now) will prefer to
create multiple /64's - one for the 4 wired ports, one for private access on the
2.4G radio, one for guest access on the 2.4, and another private/guest pair
on the 5G radio. So there is CPE gear out there now that can blow through 5 /64s
by default, and more if you enable VLANs.

A /56 allocated via DHCPv6-PD would be a *minimum*. And prefixes are cheap,
so you may as well hand them a /48, just in case they have a second WNDR3800
at the other end of the building for coverage - because that one will then ask
the upstream one for a -PD allocation. So if you give the CPE a /48, it can
keep a /56 for itself, and hand the downstream a /56, and they can each
allocate /64s as needed.

And remember - prefixes are cheap and plentiful, so don't bother with /52
or /60, just split on 8-bit boundaries to make life easier for yourself...

That makes sense now understanding how CPE equipment has evolved into segmenting layer 2 services like that. /48 it is.

Most GPON networks are composed of large layer 2 rings. No way to break that up without adding additional equipment and that can get costly. With IPv4 we got around the need to configure discrete VLANs/subnets by putting all customers in the same VLAN and turning on the DHCP snooping/source-guard features. My remaining question is why isn't this desired with IPv6? What security concerns are there with turning up SLAAC / DHCPv6 within the same /64 for everyone that are different from IPv4?

Joshua Moore
Network Engineer
ATC Broadband
912.632.3161 - O | 912.218.3720 - M

If you can't hang 4k customers off a switch, why does IPv6 need so many bits for the host portion?

Matthew Kaufman

VLAN tags can be stacked (QinQ). This allows 4096*4096 VLANs. Also it
allows you to group them and use wildcard VLAN forwarding (ie. outer vlan
100 innervlan ANY). Or you can stuff the whole thing into a MPLS L2VPN
tunnel.

We are forced to use this scheme by the incumbent telco. It is simply the
way they hand off customer links to us. One end user per VLAN, each
"areacode" has an assigned outer tag and users within an area are assigned
inner tags sequentially starting with vlan 2. Ie. user #1 is 100.2, user #2
is 100.3, user #3 living in a different area is 101.2.

However we still want to preserve IPv4, so users will be sharing the same
IPv4 subnet even though they are on different VLANs. This is done by vlan
ranges on a layer 3 interface. As a consequence we are more or less forced
to do the same for the IPv6 setup. Every user that shares a IPv4 subnet
will also share a IPv6 /64 prefix on their uplinks.

We use DHCPv6-PD to allocate a /48 prefix to each user, so the shared
prefix is only used by the CPE on the uplink. Users will normally only see
the shared prefix if they do a traceroute. Their computer will have an
address from the /48 prefix.

Regards,

Baldur

Oh, it doesn't *need* that many. You can go ahead and run your IPv6 subnets
with a /96 or /112. Just remember that will piss off any hardware that tries
to do SLAAC. or a few other things.... :slight_smile:

Depends if your customer is a home user, a business or an ISP.

Mark.

With Private VLAN's, one could share a single /64 per VLAN without
providing Layer 2 reachability between customers on the broadcast domain.

However, agree that this is a non-issue for IPv6, so a cleaner method is
a lot better.

Mark.

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

Oh, it doesn't *need* that many. You can go ahead and run your IPv6

subnets

with a /96 or /112. Just remember that will piss off any hardware that

tries

to do SLAAC. or a few other things.... :slight_smile:

Well, if you use DHCPv6 IA_NA for the CPE WAN link, you can go down as
low as /128 per CPE device.

And then you use DHCP-PD for the onward assignment to the customer's
network.

Mark.

VLAN tags aren’t global and 4096 is only a limitation on ethernet.

VPI/VCI is many more.

Yes, if you need more than 4096 customers on a single switch, you’ve got an issue, but there are many potential issues in that scenario beyond VLAN tagging (like customers choosing not to use routers and filling up your MAC tables).

Owen

Sure, but this is a useless savings that comes at the cost of awkward traceroute output
that will initially confuse your new employees and consistently confuse your customers.

Owen

It's not just the tag though... You have the /64 that has to be provisioned, the helper addresses for DHCP, ACLs/security policy, etc.

Thanks,

Joshua Moore
Network Engineer
ATC Broadband
912.632.3161

Because the designers of IPv6 didn’t want to bake the hardware constraints of equipment available
10+ years ago (20?) into the addressing plan for the future.

Hanging 4k customers off a switch is a current hardware limitation which has almost nothing to do with
IPv6 other than not being possible in IPv4 due to limitations in IPv4 whereas IPv6 does not impose
such limitations in the L3 protocol.

Think of it like consecutive apertures… If you are looking through a pinhole, you can’t see that your
entire view is through the center hole of a washer 1/2” behind the pinhole. (IPv4 is the pinhole in this
case, modern hardware is the washer).

If you open up the pinhole, suddenly the washer becomes visible.

IPv6 is everything beyond the washer visible and obscured.

Owen

The ACLs/Security policy can actually be fairly generic or automated, so I don’t see that as an issue.

The DHCP forwarder configuration is usually global, so the helper address statement demonstrates your lack of IPv6 understanding.

The /64 is pretty much nothing, but yeah, so what?

Owen

Granted that having the CPE request both a IA_NA and IA_PD is a more
common configuration. Some of the CPEs using only DHCPv6 PD can
allocate a /64 out of the delegated /48 for WAN address & management.
The IPV6 traceroute is not broken with the DHCPv6 PD only configuration.