Using /126 for IPv6 router links
Owen DeLong
owen at delong.com
Sun Jan 24 03:51:05 UTC 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