Mailing List Archive: NANOG: users

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

1 2

View All

Index | Next | Previous | View Threaded

jra at baylink

Aug 18, 2008, 10:09 AM

Post #1 of 41 (456 views)
Permalink

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

http://arstechnica.com/news.ars/post/20080817-were-running-out-of-ipv4-addresses-time-for-ipv6-really.html

Well, on reading it, it's more an "IPv6: It's great -- ask for
it by name!" piece.

Cheers,
-- jra
--
Jay R. Ashworth Baylink jra[at]baylink.com
Designer The Things I Think RFC 2100
Ashworth & Associates http://baylink.pitas.com '87 e24
St Petersburg FL USA http://photo.imageinc.us +1 727 647 1274

Those who cast the vote decide nothing.
Those who count the vote decide everything.
-- (Josef Stalin)

james at jdfogg

Aug 18, 2008, 11:09 AM

Post #2 of 41 (440 views)
Permalink

Re: It's Ars Tech's turn to bang the IPv4 exhaustion drum [In reply to]

http://arstechnica.com/news.ars/post/20080817-were-running-out-of-ipv4-addresses-time-for-ipv6-really.html
>
> Well, on reading it, it's more an "IPv6: It's great -- ask
> for it by name!" piece.

IPv6 gives me brain ache. I hear I'm not alone in that. I'd
v6 tomorrow if I didn't have to think about it so hard.

deepak at ai

Aug 18, 2008, 11:19 AM

Post #3 of 41 (441 views)
Permalink

Re: It's Ars Tech's turn to bang the IPv4 exhaustion drum [In reply to]

james wrote:
> http://arstechnica.com/news.ars/post/20080817-were-running-out-of-ipv4-addresses-time-for-ipv6-really.html
>> Well, on reading it, it's more an "IPv6: It's great -- ask
>> for it by name!" piece.
>
>
> IPv6 gives me brain ache. I hear I'm not alone in that. I'd
> v6 tomorrow if I didn't have to think about it so hard.

You just need 96 more bits in your head everywhere you store IPv4
techniques. Yes, lots of us have a brain ache with it, but I'm sure IPv4
gave us brain ache when it was new to us too.

I'm sure there are already folks in environs that are mostly IPv6 that
can spit off binary to hex to decimal IPv6 addresses. The US tends not
to be one of those environs.

It'll come.

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).

I know we aren't use auto-config on critical server architecture and
instead nailing in addressing like we would in IPv4. (an address hopping
firewall is not necessarily a good thing ;) ).

Deepak

trejrco at gmail

Aug 18, 2008, 11:42 AM

Post #4 of 41 (441 views)
Permalink

RE: It's Ars Tech's turn to bang the IPv4 exhaustion drum [In reply to]

>-----Original Message-----
>From: Deepak Jain [mailto:deepak[at]ai.net]
>Sent: Monday, August 18, 2008 2:19 PM
>To: james
>Cc: nanog[at]nanog.org
>Subject: Re: It's Ars Tech's turn to bang the IPv4 exhaustion drum
>
>
>
>james wrote:
>> http://arstechnica.com/news.ars/post/20080817-were-running-out-of-ipv4
>> -addresses-time-for-ipv6-really.html
>>> Well, on reading it, it's more an "IPv6: It's great -- ask for it by
>>> name!" piece.
>>
>>
>> IPv6 gives me brain ache. I hear I'm not alone in that. I'd
>> v6 tomorrow if I didn't have to think about it so hard.
>
>You just need 96 more bits in your head everywhere you store IPv4
>techniques. Yes, lots of us have a brain ache with it, but I'm sure IPv4
>gave us brain ache when it was new to us too.

A little software and/or memory upgrade to support dual-stack?

>
>I'm sure there are already folks in environs that are mostly IPv6 that can
>spit off binary to hex to decimal IPv6 addresses. The US tends not to be
one
>of those environs.

Indeed, we do exist! And it does become natural, given enough time &
practice.
(And yes, some of us are even in the US ... but not that many, yet (...
which is good for business ...))

>
>It'll come.
>
>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).

>From what I have seen, no.
I have seen no interest what-so-ever in redesigning the networks; most see
it as enough work to get IPv6 into their environment and don't want to
complicate the project with any "above and beyond" work. Additionally, most
are keeping IPv4 for just a bit longer so would be hampered in redoing their
architecture by that little factor.

>
>I know we aren't use auto-config on critical server architecture and
instead
>nailing in addressing like we would in IPv4. (an address hopping firewall
is
>not necessarily a good thing ;) ).

As a general rule, most clients are following the "If we gave them static
IPv4 addresses we will give them static IPv6 addresses" (infrastructure,
servers, etc). The whole SLAAC(autoconfig) vs DHCPv6 is a separate (albeit
related) conversation ...

>
>Deepak

/TJ

swmike at swm

Aug 18, 2008, 11:57 AM

Post #5 of 41 (441 views)
Permalink

Re: It's Ars Tech's turn to bang the IPv4 exhaustion drum [In reply to]

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).

Yes, there are those of us who want to save number of routes and
"spending" IPv6 addresses to save on TCAM and convergence time.

Using /112 for link networks to make the last octet ::1 and ::2 for links
also makes sense from the human perspective.

Also, I try to involve myself in IETF ipv6ops-wg via their mailing list,
and they're definitely interested in getting more people involved. Doing
IPv6 in the core is easy, it's in the access that there is much work to be
done for all access methods. If you're doing PPPoE you're probably home
free, most of the rest just isn't operationally sane yet for ISP
environment (stop customers doing rouge RA, man in the middle, spoofing).

For instance, I (and a few others) have been advocating that ISP core IPv6
space and customer IPv6 space should be separate, with link-local in
between (so core can be "protected" at borders, and also to save on TCAM
in the access devices (doing routing+antispoofing if there is only single
/48 to the customer uses less router resources than doing /48 + link
network)). Other people have other opinions.

A lot of this is happening now, so if you want something down the road,
please put in the effort now.

--
Mikael Abrahamsson email: swmike[at]swm.pp.se

streiner at cluebyfour

Aug 18, 2008, 12:18 PM

Post #6 of 41 (441 views)
Permalink

Re: It's Ars Tech's turn to bang the IPv4 exhaustion drum [In reply to]

trejrco at gmail

Aug 18, 2008, 1:28 PM

Post #7 of 41 (428 views)
Permalink

RE: It's Ars Tech's turn to bang the IPv4 exhaustion drum [In reply to]

>-----Original Message-----
>From: Justin M. Streiner [mailto:streiner[at]cluebyfour.org]
>Sent: Monday, August 18, 2008 3:18 PM
>To: nanog[at]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

iljitsch at muada

Aug 18, 2008, 2:01 PM

Post #8 of 41 (426 views)
Permalink

Re: It's Ars Tech's turn to bang the IPv4 exhaustion drum [In reply to]

On 18 aug 2008, at 21:18, Justin M. Streiner wrote:

> Just because IPv6 provides boatloads more space doesn't mean that I
> like wasting addresses :)

That kind of thinking can easily lead you in the wrong direction.

For instance, hosting businesses that cater to small customers
generally have a lot of problems with their IPv4 address provisioning:
for a customer that only needs one or a few IPv4 addresses, it's not
feasible to create a separate subnet, because that wastes a lot of
addresses. But invariably, these customers on shared subnets grow, so
over time the logical subnet gathers more and more IPv4 address blocks
that are shared by a relatively large number of customers, and because
of resistance to renumbering, it's impossible to fix this later on.

With IPv6 on the other hand, you can easily give each customer their
own prefix which they'll pretty much never grow out of, and not be
forced to artificially keep lots of customers in the same VLAN.

The extra 96 bits do make a difference.

tony at lava

Aug 18, 2008, 2:08 PM

Post #9 of 41 (428 views)
Permalink

RE: It's Ars Tech's turn to bang the IPv4 exhaustion drum [In reply to]

On Mon, 18 Aug 2008, TJ wrote:

> 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

Depends on who you consider 'official' :)

Antonio Querubin
whois: AQ7-ARIN

streiner at cluebyfour

Aug 18, 2008, 2:28 PM

Post #10 of 41 (422 views)
Permalink

Re: It's Ars Tech's turn to bang the IPv4 exhaustion drum [In reply to]

On Mon, 18 Aug 2008, Iljitsch van Beijnum wrote:

> On 18 aug 2008, at 21:18, Justin M. Streiner wrote:
>
>> Just because IPv6 provides boatloads more space doesn't mean that I like
>> wasting addresses :)
>
> That kind of thinking can easily lead you in the wrong direction.
>
> For instance, hosting businesses that cater to small customers generally have
> a lot of problems with their IPv4 address provisioning: for a customer that
> only needs one or a few IPv4 addresses, it's not feasible to create a
> separate subnet, because that wastes a lot of addresses. But invariably,
> these customers on shared subnets grow, so over time the logical subnet
> gathers more and more IPv4 address blocks that are shared by a relatively
> large number of customers, and because of resistance to renumbering, it's
> impossible to fix this later on.

I don't have a problem with assigning customers a /64 of v6 space. My
earlier comments were focused on network infrastructure comprised of mainly
point-to-point links with statically assigned interface addresses. In
that case, provisioning point-to-point links much larger than a /126, or
at the maximum a /120 seems rather wasteful and doesn't make much sense.

jms

iljitsch at muada

Aug 18, 2008, 2:35 PM

Post #11 of 41 (423 views)
Permalink

Re: It's Ars Tech's turn to bang the IPv4 exhaustion drum [In reply to]

On 18 aug 2008, at 23:28, Justin M. Streiner wrote:

> I don't have a problem with assigning customers a /64 of v6 space. My
> earlier comments were focused on network infrastructure comprised of
> mainly
> point-to-point links with statically assigned interface addresses.
> In that case, provisioning point-to-point links much larger than a /
> 126, or at the maximum a /120 seems rather wasteful and doesn't make
> much sense.

Well, the choice is really between /64 or not-/64. If the latter, you
can number all your point-to-point links from a single /64 whether you
give them a /96 or a /127. I recommend /112 because that way the
subnet boundary falls on a colon. /120 or longer has some potential
issues that are too boring to explain for the 50th time.

But since IPv6 routing protocols work on link locals, you really don't
need _any_ global addresses on your point-to-point links...

trejrco at gmail

Aug 18, 2008, 2:43 PM

Post #12 of 41 (422 views)
Permalink

RE: It's Ars Tech's turn to bang the IPv4 exhaustion drum [In reply to]

>-----Original Message-----
>From: Justin M. Streiner [mailto:streiner[at]cluebyfour.org]
>Sent: Monday, August 18, 2008 5:29 PM
>To: Iljitsch van Beijnum
>Cc: nanog[at]nanog.org
>Subject: Re: It's Ars Tech's turn to bang the IPv4 exhaustion drum
>
>On Mon, 18 Aug 2008, Iljitsch van Beijnum wrote:
>
>> On 18 aug 2008, at 21:18, Justin M. Streiner wrote:
>>
>>> Just because IPv6 provides boatloads more space doesn't mean that I
>>> like wasting addresses :)
>>
>> That kind of thinking can easily lead you in the wrong direction.
>>
>> For instance, hosting businesses that cater to small customers
>> generally have a lot of problems with their IPv4 address provisioning:
>> for a customer that only needs one or a few IPv4 addresses, it's not
>> feasible to create a separate subnet, because that wastes a lot of
>> addresses. But invariably, these customers on shared subnets grow, so
>> over time the logical subnet gathers more and more IPv4 address blocks
>> that are shared by a relatively large number of customers, and because
>> of resistance to renumbering, it's impossible to fix this later on.
>
>I don't have a problem with assigning customers a /64 of v6 space. My
>earlier comments were focused on network infrastructure comprised of mainly
>point-to-point links with statically assigned interface addresses. In that
>case, provisioning point-to-point links much larger than a /126, or at the
>maximum a /120 seems rather wasteful and doesn't make much sense.

Actually, in most cases - you would assign customers more than a /64.
*Hopefully* a /56 as the smallest ... ~/48 for enterprises ...

>
>jms

/TJ

jra at baylink

Aug 18, 2008, 4:47 PM

Post #13 of 41 (421 views)
Permalink

Re: It's Ars Tech's turn to bang the IPv4 exhaustion drum [In reply to]

On Mon, Aug 18, 2008 at 08:57:27PM +0200, Mikael Abrahamsson 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).
>
> Yes, there are those of us who want to save number of routes and
> "spending" IPv6 addresses to save on TCAM and convergence time.
>
> Using /112 for link networks to make the last octet ::1 and ::2 for links
> also makes sense from the human perspective.

Well, if y'all want a place to put this hints, I got a whole IPv6y
section over here:

http://bestpractices.wikia.com

Cheers,
-- jra
--
Jay R. Ashworth jra[at]baylink.com
Designer +-Internetworking------+---------+ RFC 2100
Ashworth & Associates | Best Practices Wiki | | '87 e24
St Petersburg FL USA +-http://bestpractices.wikia.com-+ +1 727 647 1274

If you can read this... thank a system administrator. Or two. --me

michael.dillon at bt

Aug 19, 2008, 12:10 AM

Post #14 of 41 (415 views)
Permalink

RE: It's Ars Tech's turn to bang the IPv4 exhaustion drum [In reply to]

> I don't have a problem with assigning customers a /64 of v6
> space.

Why so little? Normally customers get a /48 except for residential
customers who can be given a /56 if you want to keep track of
different block sizes. If ARIN will give you a /48 for every
customer, then why be miserly with addresses?

--Michael Dillon

streiner at cluebyfour

Aug 19, 2008, 8:47 AM

Post #15 of 41 (386 views)
Permalink

RE: It's Ars Tech's turn to bang the IPv4 exhaustion drum [In reply to]

On Tue, 19 Aug 2008, michael.dillon[at]bt.com wrote:

>> I don't have a problem with assigning customers a /64 of v6
>> space.
>
> Why so little? Normally customers get a /48 except for residential
> customers who can be given a /56 if you want to keep track of
> different block sizes. If ARIN will give you a /48 for every
> customer, then why be miserly with addresses?

I don't operate an ISP network (not anymore, anyway...). My customers are
departments within my organization, so a /64 per department/VLAN is more
sane/reasonable for my environment.

jms

mike at mtcc

Aug 19, 2008, 10:25 AM

Post #16 of 41 (381 views)
Permalink

Re: It's Ars Tech's turn to bang the IPv4 exhaustion drum [In reply to]

Justin M. Streiner wrote:
> On Tue, 19 Aug 2008, michael.dillon[at]bt.com wrote:
>
>>> I don't have a problem with assigning customers a /64 of v6
>>> space.
>>
>> Why so little? Normally customers get a /48 except for residential
>> customers who can be given a /56 if you want to keep track of
>> different block sizes. If ARIN will give you a /48 for every
>> customer, then why be miserly with addresses?
>
> I don't operate an ISP network (not anymore, anyway...). My customers
> are departments within my organization, so a /64 per department/VLAN is
> more sane/reasonable for my environment.

Uh, the lower 64 bits of an IP6 address aren't used for routing you
know? They're essentially the mac address, or some other sort of
autoconf'd host identifier. Last I heard, the smallest allocation is
supposed to be a /48 -- I hadn't heard of the /56 thing that Michael
was speaking of, though I'm not surprised. There's 64 bits for
routing... no need to be so stingy :)

Mike

randy at psg

Aug 19, 2008, 10:33 AM

Post #17 of 41 (379 views)
Permalink

Re: It's Ars Tech's turn to bang the IPv4 exhaustion drum [In reply to]

> Uh, the lower 64 bits of an IP6 address aren't used for routing

they are. the /64 boundary is not in harwhere

randy

nanog at daork

Aug 19, 2008, 10:36 AM

Post #18 of 41 (380 views)
Permalink

Re: It's Ars Tech's turn to bang the IPv4 exhaustion drum [In reply to]

On 20/08/2008, at 5:25 AM, Michael Thomas wrote:
> Justin M. Streiner wrote:
>> On Tue, 19 Aug 2008, michael.dillon[at]bt.com wrote:
>>>> I don't have a problem with assigning customers a /64 of v6
>>>> space.
>>>
>>> Why so little? Normally customers get a /48 except for residential
>>> customers who can be given a /56 if you want to keep track of
>>> different block sizes. If ARIN will give you a /48 for every
>>> customer, then why be miserly with addresses?
>> I don't operate an ISP network (not anymore, anyway...). My
>> customers are departments within my organization, so a /64 per
>> department/VLAN is more sane/reasonable for my environment.
>
> Uh, the lower 64 bits of an IP6 address aren't used for routing you
> know? They're essentially the mac address, or some other sort of
> autoconf'd host identifier. Last I heard, the smallest allocation is
> supposed to be a /48 -- I hadn't heard of the /56 thing that Michael
> was speaking of, though I'm not surprised. There's 64 bits for
> routing... no need to be so stingy :)

64 bits is not a magical boundary.

112 bits is widely recommended for linknets, for example.

64 bits is common, because of EUI-64 and friends. That's it.
There is nothing, anywhere, that says that the first 64 bits is for
routing.

--
Nathan Ward

sethm at rollernet

Aug 19, 2008, 10:37 AM

Post #19 of 41 (379 views)
Permalink

Re: It's Ars Tech's turn to bang the IPv4 exhaustion drum [In reply to]

Michael Thomas wrote:
> Justin M. Streiner wrote:
>> On Tue, 19 Aug 2008, michael.dillon[at]bt.com wrote:
>>
>>>> I don't have a problem with assigning customers a /64 of v6
>>>> space.
>>>
>>> Why so little? Normally customers get a /48 except for residential
>>> customers who can be given a /56 if you want to keep track of
>>> different block sizes. If ARIN will give you a /48 for every
>>> customer, then why be miserly with addresses?
>>
>> I don't operate an ISP network (not anymore, anyway...). My customers
>> are departments within my organization, so a /64 per department/VLAN
>> is more sane/reasonable for my environment.
>
> Uh, the lower 64 bits of an IP6 address aren't used for routing you
> know? They're essentially the mac address, or some other sort of
> autoconf'd host identifier. Last I heard, the smallest allocation is
> supposed to be a /48 -- I hadn't heard of the /56 thing that Michael
> was speaking of, though I'm not surprised. There's 64 bits for
> routing... no need to be so stingy :)
>

Last time I asked about this on the ipv6 list I got smacked for thinking
about using anything other than a /64 for subnets, even on point to
point links.

~Seth

alain_durand at cable

Aug 19, 2008, 10:45 AM

Post #20 of 41 (380 views)
Permalink

Re: It's Ars Tech's turn to bang the IPv4 exhaustion drum [In reply to]

On 8/19/08 1:36 PM, "Nathan Ward" <nanog[at]daork.net> wrote:

> 64 bits is not a magical boundary.
>
> 112 bits is widely recommended for linknets, for example.
>
> 64 bits is common, because of EUI-64 and friends. That's it.
> There is nothing, anywhere, that says that the first 64 bits is for
> routing.

Actually, there is text that says so:
RFC4291: IPv6 Addressing Architecture, section 2.5.1

" For all unicast addresses, except those that start with the binary
value 000, Interface IDs are required to be 64 bits long and to be
constructed in Modified EUI-64 format."

The fact that most implementations ignore this is a different story.

In practice, many routers require the packet to go twice in the hardware if
the prefix length is > 64 bits, so even though it is a total waste of space,
it is not stupid to use /64 for point-to-point links and even for loopbacks!

- Alain.

randy at psg

Aug 19, 2008, 10:50 AM

Post #21 of 41 (379 views)
Permalink

Re: It's Ars Tech's turn to bang the IPv4 exhaustion drum [In reply to]

> In practice, many routers require the packet to go twice in the hardware if
> the prefix length is > 64 bits, so even though it is a total waste of space,
> it is not stupid to use /64 for point-to-point links and even for loopbacks!

some of us remember when we thought similarly for /24s for p2p links,
especially when using rip.

and consider matsuzaki-san's dos vulnerability on a /64 p2p link. the
prudent operational advice today is to use a /127.

randy

dot at dotat

Aug 19, 2008, 11:05 AM

Post #22 of 41 (378 views)
Permalink

Re: It's Ars Tech's turn to bang the IPv4 exhaustion drum [In reply to]

On Tue, 19 Aug 2008, Michael Thomas wrote:
> Justin M. Streiner wrote:
> >
> > I don't operate an ISP network (not anymore, anyway...). My customers
> > are departments within my organization, so a /64 per department/VLAN
> > is more sane/reasonable for my environment.
>
> Uh, the lower 64 bits of an IP6 address aren't used for routing you
> know? They're essentially the mac address, or some other sort of
> autoconf'd host identifier. Last I heard, the smallest allocation is
> supposed to be a /48 -- I hadn't heard of the /56 thing that Michael was
> speaking of, though I'm not surprised. There's 64 bits for routing... no
> need to be so stingy :)

It doesn't make sense to allocate a /48 to a (V)LAN. Address
autoconfiguration is based on the assumption that the only
reason for having more than one global /64 prefix on a LAN
is during renumbering.

Tony.
--
f.anthony.n.finch <dot[at]dotat.at> http://dotat.at/
HEBRIDES BAILEY FAIR ISLE FAEROES: NORTH OR NORTHEAST 5 OR 6 DECREASING 4 OR
5, BECOMING VARIABLE 3 IN NORTH BAILEY AND WEST FAEROES LATER. MODERATE OR
ROUGH. MAINLY FAIR. MODERATE OR GOOD.

trejrco at gmail

Aug 19, 2008, 11:28 AM

Post #23 of 41 (380 views)
Permalink

RE: It's Ars Tech's turn to bang the IPv4 exhaustion drum [In reply to]

>-----Original Message-----
>>> On Tue, 19 Aug 2008, michael.dillon[at]bt.com wrote:
>>>>> I don't have a problem with assigning customers a /64 of v6 space.
>>>>
>>>> Why so little? Normally customers get a /48 except for residential
>>>> customers who can be given a /56 if you want to keep track of
>>>> different block sizes. If ARIN will give you a /48 for every
>>>> customer, then why be miserly with addresses?
>>> I don't operate an ISP network (not anymore, anyway...). My
>>> customers are departments within my organization, so a /64 per
>>> department/VLAN is more sane/reasonable for my environment.
>>
>> Uh, the lower 64 bits of an IP6 address aren't used for routing you
>> know? They're essentially the mac address, or some other sort of
>> autoconf'd host identifier. Last I heard, the smallest allocation is
>> supposed to be a /48 -- I hadn't heard of the /56 thing that Michael
>> was speaking of, though I'm not surprised. There's 64 bits for
>> routing... no need to be so stingy :)
>
>
>64 bits is not a magical boundary.
>
>112 bits is widely recommended for linknets, for example.
>
>64 bits is common, because of EUI-64 and friends. That's it.
>There is nothing, anywhere, that says that the first 64 bits is for
routing.

Just to be clear - this http://tools.ietf.org/html/rfc4291#section-2.5.4
does say:
" All Global Unicast addresses other than those that start with binary
000 have a 64-bit interface ID field (i.e., n + m = 64), formatted as
described in Section 2.5.1. Global Unicast addresses that start with
binary 000 have no such constraint on the size or structure of the
interface ID field."

(And again - this is a case where the real world and the IETF may not agree
100% ...)

/TJ

alain_durand at cable

Aug 19, 2008, 11:30 AM

Post #24 of 41 (378 views)
Permalink

Re: It's Ars Tech's turn to bang the IPv4 exhaustion drum [In reply to]

On 8/19/08 1:50 PM, "sthaug[at]nethelp.no" <sthaug[at]nethelp.no> wrote:

>> In practice, many routers require the packet to go twice in the hardware if
>> the prefix length is > 64 bits, so even though it is a total waste of space,
>> it is not stupid to use /64 for point-to-point links and even for loopbacks!
>
> Could you provide some documentation on this? First I've heard about it.

Ask your favorite router vendor. This has been confirmed to me by at least 3
major one we use.

- Alain.

oberman at es

Aug 19, 2008, 1:22 PM

Post #25 of 41 (366 views)
Permalink

Re: It's Ars Tech's turn to bang the IPv4 exhaustion drum [In reply to]

> Date: Tue, 19 Aug 2008 14:30:38 -0400
> From: Alain Durand <alain_durand[at]cable.comcast.com>
>
> On 8/19/08 1:50 PM, "sthaug[at]nethelp.no" <sthaug[at]nethelp.no> wrote:
>
> >> In practice, many routers require the packet to go twice in the hardware if
> >> the prefix length is > 64 bits, so even though it is a total waste of space,
> >> it is not stupid to use /64 for point-to-point links and even for loopbacks!
> >
> > Could you provide some documentation on this? First I've heard about it.
>
> Ask your favorite router vendor. This has been confirmed to me by at least 3
> major one we use.

Odd. I have asked both of our router vendors and they have confirmed
that they route in the ASIC based on the full address, not just the
first 64 bits. (I believe one of them based on actual testing. I am
suspicious of the other.)

That said, one does use a few bits for something else (port) and does
not load them into the FIB, so I believe they route on 120 bits, not
128.

I'd love to get complete verification of the real facts of this.
--
R. Kevin Oberman, Network Engineer
Energy Sciences Network (ESnet)
Ernest O. Lawrence Berkeley National Laboratory (Berkeley Lab)
E-mail: oberman[at]es.net Phone: +1 510 486-8634
Key fingerprint:059B 2DDF 031C 9BA3 14A4 EADA 927D EBB3 987B 3751

1 2

View All

Index | Next | Previous | View Threaded

Interested in having your list archived? Contact lists@gossamer-threads.com