[address-policy-wg] IPv6 allocations for 6RD

Le 30 nov. 2009 à 22:15, <michael.dillon at bt.com> <michael.dillon at bt.com> a écrit :

> 
>> - Since RIRs allocate /32s and recommend to assign /48s to 
>> customers, each ISP having more than 64K customers should get 
>> at least a /28. With such a /28, any ISP that has several 
>> IPv4 prefixes can deploy 6rd with /60s assigned to all its 
>> customers (typically more than 64K).
> 
> Wait a minute. If a /28 allocation is enough to assign /60
> blocks, then by giving the ISP 4 more subnetting bits, i.e.
> a /24 allocation, they should be able to give /56 assignments
> to all their customers. That is the way to do this properly.

No objection to /24s being allocated, just the opposite: /24 is better than /28 and should IMHO be provided, but each RIR makes its own decisions, and ISPs have to adapt best to what they get. 
(If an ISP obtains only a /28, whatever the reason, offering /60s to its customers is better than /64s, and much better than no no IPv6 at all.)

>> - A /60 per customer site is largely enough to start using 
>> IPv6, even for sophisticated users that configure several 
>> LANs in their sites.
> 
> That's not the point. A /60 assignment is wrong.

See the note above.

> If software
> developers and equipment vendors get the idea that /60 is
> normal, then they will embed that assumption in their products
> and it will make the transition from 6RD to native v6 more
> difficult.

They have no reason to do this.
Equipment vendors don't have in general such poor designers.

> There is no need to make customer assignments smaller 
> than /56.

True if /24s are always available, which should be the goal.

> 
>> - For an ISPs that initially gets only as /32 and has several 
>> IPv4 prefixes, assigning /64s to its customers is much better 
>> than no IPv6 at all (as Free has demonstrated, and because 
>> most sites don't support several LANs anyway).  
> 
> No, assigning /64s is far worse because their people will not
> be properly trained, and when the word gets out, nobody will
> want to work there because it will be a black mark on their
> CV.

Different view here.
Free customers were happy to have native IPv6 as early as in December 2007, and many of them were proud to be among the first ones to use Google with native IPv6 addresses.
I don't believe that my CV has been black marked for having pioneered IPv6 actual usage.

> It is better to go back to RIPE, explain the situation, 
> and get a /24 or /21.

That is doing both, depending on the case, which is better.

>> o ISPs that don't obtain more generous IPv6 prefixes than 
>> /32s can at least start with /64s assigned to customers.
> 
> This is called compounding your mistakes. Do not do this.

Sorry: no regret for what you call a mistake, and what has been a great step in favor of IPv6.

>> o RIRs should allocate at least /28s to ISPs that have 
>> several IPv4 prefixes and plan to deploy 6rd.
> 
> Wrong.

At least /28 includes /24 (and /24 is clearly better than /28).

> RIRs should evaluate the size of allocation needed to
> properly deploy 6RD using /56 assignments for customers, and
> then allocate a block big enough to handle this deployment.

Again, this seems fine to me.

>> o These ISPs should return these prefixes if, for any reason, 
>> they become more generous than needed.
> 
> That has always been part of the RIR rules.
> And that is a major reason why people should be given huge
> allocations to deploy 6RD, if they have decided that 6RD
> is the best way to go. We do not want ISPs to get locked
> into 6RD because of bad architectural decisions, so we
> must ensure that they have enough address space to assign
> /56 or /48 to all customer sites.

Full agreement on this point ;-).

Regards,
RD


> 
> --Michael Dillon
>