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.galbraith@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 <LarrySheldon@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