Re: [v6ops] draft-wbeebee-v6ops-ipv6-cpe-router-bis - where to go from here

[Fred Baker <[e-mail]>]

On Jan 31, 2011, at 9:36 PM, Jack Bates wrote:

> On 1/31/2011 3:29 PM, Ole Troan wrote:
>> one where there is no administrative boundary between the customer
>> and the provider you mean? this solution should also handle the case
>> where the end user network is connected to multiple providers.
>> 
> 
> To be honest, there is no administrative boundary in zeroconf CPEs today. Boundaries only form when a customer starts to actually manage their CPE. My only issue is that the current model forces the ISP to do one of two things:
> 
> 1) Restrict all customers to a single routed CPE interfacing with the ISP (here's your /48, /56, etc but only one)
> 
> 2) Issue longer prefixes and more of them to the CPE in an on-demand scenario (okay, you've issued 6 /64 requests, and I'll answer those up to 20, then I say you're done).
> 
> The first is the better option of the 2, but it continues to restrict the provider/customer interface in ways that are not desirable.

I find this statement really surprising. It conflates allocation with routing.

It seems to me that if a downstream network had N>1 interfaces to a given upstream and got a prefix (/44, /63, whatever) from it, the upstream would normally consider that it could route the entire prefix to each of the N interfaces according to whatever rules it chose, and the downstream could allocate /64s within the prefix as it chose.  In other words, it would operate the same way that it would operate if the downstream had PI space with the exception that the upstream wouldn't advertise the more specific route - it would merely announce its own much-shorter prefix.