Using /126 for IPv6 router links

Owen DeLong owen at delong.com
Sat Jan 23 21:51:05 CST 2010


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 at 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 at 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
>> 





More information about the NANOG mailing list