[121663] in North American Network Operators' Group
Re: Using /126 for IPv6 router links
daemon@ATHENA.MIT.EDU (Owen DeLong)
Sat Jan 23 22:56:45 2010
From: Owen DeLong <owen@delong.com>
In-Reply-To: <20100124133650.6575360a@opy.nosense.org>
Date: Sat, 23 Jan 2010 19:51:05 -0800
To: Mark Smith <nanog@85d5b20a518b8f6864949bd940457dc124746ddc.nosense.org>
Cc: "nanog@nanog.org" <nanog@nanog.org>
Errors-To: nanog-bounces+nanog.discuss=bloom-picayune.mit.edu@nanog.org
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:
>=20
>> Sometimes good enough > perfect
>>=20
>> Never know what is going to come along to turn your addressing plan =
on its head.
>>=20
>=20
>=20
> 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.
>=20
> Possible positions or situations are :
>=20
> 1. you use a variety of node address lengths across your network, and
> there are no future consequences - everything works and continues to
> work
>=20
> 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
>=20
> 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.
>=20
> 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.
>=20
>=20
> 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.
>=20
> 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.
>=20
>=20
>> -brandon
>>=20
>> 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.
>>>>>=20
>>>>> 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.
>>>>>=20
>>>>> So what do you think? Good? Bad? Ugly? /127 ? ;)
>>>>>=20
>>>> Use the /64... It's OK... IPv6 was designed with that in mind.
>>>>=20
>>>> 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.
>>>=20
>>> Did somebody once say something like that about Class C addresses?
>>>=20
>>>=20
>>> --
>>> "Government big enough to supply everything you need is big enough =
to
>>> take everything you have."
>>>=20
>>> Remember: The Ark was built by amateurs, the Titanic by =
professionals.
>>>=20
>>> Requiescas in pace o email
>>> Ex turpi causa non oritur actio
>>> Eppure si rinfresca
>>>=20
>>> ICBM Targeting Information: http://tinyurl.com/4sqczs
>>> http://tinyurl.com/7tp8ml
>>> =09
>>>=20
>>>=20
>>=20
>>=20
>> --=20
>> Brandon Galbraith
>> Mobile: 630.400.6992
>> FNAL: 630.840.2141
>>=20
