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/address-policy-wg@ripe.net/
[address-policy-wg] IPv6 allocations for 6RD
- Previous message (by thread): [address-policy-wg] IPv6 allocations for 6RD
- Next message (by thread): [address-policy-wg] IPv6 allocations for 6RD
Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
michael.dillon at bt.com
michael.dillon at bt.com
Tue Dec 1 11:00:47 CET 2009
> > 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. What you say is true about major equipment vendors and maybe true about major software vendors. But for IPv6 to replace IPv4 as the Internet Protocol, we need thousands of minor vendors to provide products, including new products that were not possible with IPv4. For instance a home video system that runs on its own /64 subnet within the home. > 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. Pioneers get special benefits but if ISPs start to copy Free and use /60 blocks, the people at those ISPs aren't pioneering and their CVs will not look as pretty as yours. > Sorry: no regret for what you call a mistake, and what has > been a great step in favor of IPv6. Here in RIPE we have the opportunity to correct the situation that led to this mistake. Whether that means educating people that they can get big allocations and use /56 assignment blocks or whether that means changing policy, here we can do something about it. > At least /28 includes /24 (and /24 is clearly better than /28). I disagree in using arbitrary numbers here. The policy for allocations to ISPs is an area where IPv6 allocation rules are still based on justified need, like in IPv4. So the right way to do this is to recognize that 6RD is a new technology which creates a justified need for larger allocations than native IPv6. The only place for a specific number would be to have a maximum allocation size such as /24 or /21 in which case we would say "up to /21". > >> 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 ;-). --Michael Dillon
- Previous message (by thread): [address-policy-wg] IPv6 allocations for 6RD
- Next message (by thread): [address-policy-wg] IPv6 allocations for 6RD
Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]