Greenfield IPv4 + IPv6 broadband deployment

[Mark Smith]

Hi Martin,

On Sat, 26 Feb 2011 15:57:22 -0500
Martin Millnert <martin at millnert.se> wrote:

> On Sat, 2011-02-26 at 20:23 +0000, Adam Armstrong wrote:
> > Different access medium. I'm specifically looking for experience with 
> > large scale ethernet dhcpv6+v4 deployments :)
> 
> The proper way to do v4+v6 *from scratch* (from scratch implies you can
> buy equipment compatible with your requirements) on ethernet, to me,
> seems to be along the following lines:
>   1) L2 separation of each customer,
>   2) Statically mapped address spaces per customer, both v4 and v6
>   3) DHCPv4 with Option 82 to deliver v4-addresses to the customer,
>   4) Baseline DHCPv6 RA:ed /64 on the cust ethernet. /64 taken from a
> reserved /56 or shorter for the customer in question,

How are you preventing the CPE's from using this prefix DHCPv6-PD
server from using this prefix? Does your CPE recognise that the /64 it
has received for SLAAC is from within it's DHCPv6-PD prefix, and avoid
using it on it's other interfaces? I'm aware that there is an Internet
Draft proposing how to officially facilitate this, but it's a draft at
this stage, and I'm not sure I'd want to be confident of the small
variety of IPv6 CPE available always working correctly - or are you
also managing/owning the CPE and therefore can dictate/control the
feature support such as this?

What benefits are there of taking a /64 from the delegated prefix for
this purpose? I generally like the idea of saying to the customer (via
DHCPv6-PD), "here's your delegated prefix, use it how you want, I'll
use this different separate /64 that I choose and manage for the link
between us." Is it that you reduce the number of per-customer routes
that you're exporting from your customer aggregation router e.g. from 2
(/56 PD, /64 cust link) to 1 (/56 PD, cust link /64 inclusive)?

>   5) DHCPv6 PD delivering more prefixes from that same /56 (minus the 1
> link /64 done with RA, obviously), 
>   6) Option 82 equivalence for DHCPv6 allows for having a DHCPv6 PD
> server not running on the PE itself, but further away (dhcp-helper
> functionality to assist getting packets there)
> 
> That's the way to do the access IMO.  Interface/link separation of users
> lets you map addresses more easily and forget entirely about customer
> device mappings, which to me seems like such an ease of administrative
> overhead/burden that it is absolutely worth investing extra to get.
> 
> Above based on experiences running a 2400-ports Ethernet access network,
> that fork-lift morphed into the above. Have no operational scaling
> experiences with larger networks than above, but with routed access
> interfaces and IGP on the inside, it ought to scale pretty far.
> 

If I understand you, you're using an IGP to push these per customer
routes around. I think BGP would make this scale a lot further if
necessary. Depending on the sorts of possible outages you have, and how
many customer connections are impacted by them, BGP might be worth
using anyway, as because it uses TCP, if a BGP peer is struggling
with temporary processing load, it can use TCP windows to tell it's
peers to back off for a while.

Regards,
Mark.