That's why we have the safety valve... 2000::/3 is the total address space being issued currently. So, if we discover that there aren't enough /64s like we currently think there are, then, before we start issuing from 4000::/3, we can have a new address plan for that address space while leaving the 2000::/3 in it's current state of 1, or, ideally, 2.
Owen On Jan 23, 2010, at 7:06 PM, Mark Smith wrote: > On Sat, 23 Jan 2010 20:55:52 -0600 > Brandon Galbraith <brandon.galbra...@gmail.com> wrote: > >> Sometimes good enough > perfect >> >> Never know what is going to come along to turn your addressing plan on its >> head. >> > > > It seems to me that what this really is about is trying to be in the > best position in the future. I think mainly it's about trying to avoid > unexpected and future renumbering/change of prefix length costs. > > Possible positions or situations are : > > 1. you use a variety of node address lengths across your network, and > there are no future consequences - everything works and continues to > work > > 2. you use a single node address length (i.e. /64) across your network, > and there are no future consequences - everything works and continues > to work > > 3. you use a variety of node address lengths, and you'll have to > renumber to /64s, because you encounter unacceptable issues e.g. > device performance issues, inability to use features you'd find useful > e.g. SEND. > > 4. you use a single node address length, and you'll have to move to > variable length node addresses, because the IPv6 address space ends up > not being as big as it was designed and calculated to be. > > > Ideally, situations one 1. or 2. will occur, as they're the least > costly. 1. is both initially and operationally slightly more costly than > 2. as you'll also have to also accurately manage prefix lengths, and > consider and/or address other non-/64 issues identified in RFC3627, > which I think makes 2. the better choice. > > The question is, which of those two has the least risk of > devolving into the corresponding 3. or 4? As the addressing > architecture documents for IPv6 currently state that for other than > addresses that start with binary 000, the interface ID are required to > be 64 bits in length, it seems to me that situation 2. is the least > risky and least likely to devolve into situation 4. Vendors/developers > using RFCs as authoritative IPV6 documents are going to assume /64s, as > are future protocol developers. > > >> -brandon >> >> On 1/23/10, Larry Sheldon <larryshel...@cox.net> wrote: >>> On 1/23/2010 8:24 PM, Owen DeLong wrote: >>>> On Jan 23, 2010, at 4:52 AM, Mathias Seiler wrote: >>>>> In reference to the discussion about /31 for router links, I d'like >>>>> to know what is your experience with IPv6 in this regard. >>>>> >>>>> I use a /126 if possible but have also configured one /64 just for >>>>> the link between two routers. This works great but when I think >>>>> that I'm wasting 2^64 - 2 addresses here it feels plain wrong. >>>>> >>>>> So what do you think? Good? Bad? Ugly? /127 ? ;) >>>>> >>>> Use the /64... It's OK... IPv6 was designed with that in mind. >>>> >>>> 64 bits is enough networks that if each network was an almond M&M, >>>> you would be able to fill all of the great lakes with M&Ms before you >>>> ran out of /64s. >>> >>> Did somebody once say something like that about Class C addresses? >>> >>> >>> -- >>> "Government big enough to supply everything you need is big enough to >>> take everything you have." >>> >>> Remember: The Ark was built by amateurs, the Titanic by professionals. >>> >>> Requiescas in pace o email >>> Ex turpi causa non oritur actio >>> Eppure si rinfresca >>> >>> ICBM Targeting Information: http://tinyurl.com/4sqczs >>> http://tinyurl.com/7tp8ml >>> >>> >>> >> >> >> -- >> Brandon Galbraith >> Mobile: 630.400.6992 >> FNAL: 630.840.2141 >>