This archive is retained to ensure existing URLs remain functional. It will not contain any emails sent to this mailing list after July 1, 2024. For all messages, including those sent before and after this date, please visit the new location of the archive at https://mailman.ripe.net/archives/list/ipv6-wg@ripe.net/
[ipv6-wg] End-host IPv6 address allocation on Carrier Ethernet
- Previous message (by thread): [ipv6-wg] End-host IPv6 address allocation on Carrier Ethernet
- Next message (by thread): [ipv6-wg] End-host IPv6 address allocation on Carrier Ethernet
Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
Tero Toikkanen
Tero.Toikkanen at nebula.fi
Thu Sep 29 14:36:23 CEST 2011
> You can't extract MAC from SLAACed IPv6 due to privacy extensions (RFC > 4941). Ah, I had already forgotten about that. > I like one-VLAN-per customer idea, but it doesn't always scale (in some > environments you'd run out of VLANs). Q-in-Q helps with the scaling, but admittedly only up to a certain point. As mentioned, we also have to come up with an alternative solution for the group-VLANs. So far DHCPv6 seems like the way to go in that case, but vendor support is still lacking. DHCPv6 IA_PD would be nice, but in 98% of the time we don't have control over the CPE. As Ivan mentioned, DHCPv6 Option37/38 would enable the same for IPv6, but the support just isn't there yet. Also, it's one thing to get vendor support and another thing to get bitstream operators to support it as well. ____________________________________ Tero Toikkanen Network Engineer Nebula Oy
- Previous message (by thread): [ipv6-wg] End-host IPv6 address allocation on Carrier Ethernet
- Next message (by thread): [ipv6-wg] End-host IPv6 address allocation on Carrier Ethernet
Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
[ ipv6-wg Archives ]