[106946] in North American Network Operators' Group

home help back first fref pref prev next nref lref last post

RE: It's Ars Tech's turn to bang the IPv4 exhaustion drum

daemon@ATHENA.MIT.EDU (TJ)
Mon Aug 18 16:28:35 2008

From: "TJ" <trejrco@gmail.com>
To: <nanog@nanog.org>
In-Reply-To: <Pine.LNX.4.64.0808181429550.12939@whammy.cluebyfour.org>
Date: Mon, 18 Aug 2008 16:28:20 -0400
Errors-To: nanog-bounces@nanog.org

>-----Original Message-----
>From: Justin M. Streiner [mailto:streiner@cluebyfour.org]
>Sent: Monday, August 18, 2008 3:18 PM
>To: nanog@nanog.org
>Subject: Re: It's Ars Tech's turn to bang the IPv4 exhaustion drum
>
>On Mon, 18 Aug 2008, Deepak Jain wrote:
>
>> operational content: Is anyone significantly redesigning the way they
>> route/etc to take advantage of any hooks that IPv6 provides-for (even
>> if its a proprietary implementation)? As far as I can tell, most
>> people are just implementing it as IPv4 with a lot of bits (i.e. /126s
>> for link interfaces, etc).
>
>There seem to be differing schools of thought on this, but personally I'm
>leaning in this direction at least for network infrastructure.  Just
because
>IPv6 provides boatloads more space doesn't mean that I like wasting
>addresses :)

Another side of that argument is operational complexity ... /126's do make
the addresses harder (as a previous poster mentioned) as well as inducing
other potential headaches (reserved address to watch out for, requiring
another route to get to a client's network, etc).  That is why the official
answer is to always use /64s, even on PtP links.  This is one area where the
real world and the IETF don't always agree, and in this case that can be OK.


>
>jms


/TJ



home help back first fref pref prev next nref lref last post