Michael Hallgren <m.hallgren@free.fr>:
> Really really LARGE scalability testing that needs more addresses than
> RFC1918 gives you.Use IPv6.
For an IPv4 scalability test? Interesting idea...
Apart from the basic incompability here, my opinion of IPv6 is that it
just gives you 2^96 more addresses to repeat all the old mistakes with.
--Johnny
Might wanna consider that if you're doing a scalability *test* that burns over
a /8 of IPv4, how do you intend to *deploy* the sucker? Gonna be a bear
trying to get a /8 or 3 allocated when The Final Days are upon us already...
Michael Hallgren <m.hallgren@free.fr>:
> > Really really LARGE scalability testing that needs more addresses than
> > RFC1918 gives you.
>
> Use IPv6.For an IPv4 scalability test? Interesting idea...
Plaisanterie of sorts... But off "plaisanterie," I ref. the statement
above.
Apart from the basic incompability here, my opinion of IPv6 is that it
just gives you 2^96 more addresses to repeat all the old mistakes with.
Some mistakes, sure; not all. Keep the multihoming game in mind, for
instance. Sure is that misuse is much possible also in the IPv6 space!
Cheers,
mh
Not quite..
2^96 = 79228162514264337593543950336
2^128-2^32 = 340282366920938463463374607427473244160
Apart from the basic incompability here, my opinion of IPv6 is that it
just gives you 2^96 more addresses to repeat all the old mistakes
with.Not quite..
2^96 = 79228162514264337593543950336
2^128-2^32 = 340282366920938463463374607427473244160
not quite. let's posit 42 devices on the average lan segment
(ymmv).
42*(2^64) = 774763251095801167872
randy
Let's face it - they're going to have to come up with much more creative
$200/hour chucklehead consultants to burn through that much anytime soon.
Of course, I've long suspected that the 90% of the universe that's "dark
matter" is all contained inside the craniums of all those chucklehead
consultants (which is why they're so resistant to interactions with cluons from
the rest of reality), so there's unfortunately a definite growth potential
there...
Anybody feel like starting a pool for when we'll see a posting to NANOG
about somebody who's managed to burn through a /32?
Let's face it - they're going to have to come up with much more creative
$200/hour chucklehead consultants to burn through that much anytime soon.
It has been my experience that when you give someone a huge address space
to play with (eg 10/8), they start doing things like using bits in the
address as flags for things. Suddenly you find yourself using a prefix
that should enough for a decent sized country in a half-rack.
It's only slightly harder to imagine a /48 being wasted like that.
-Anthony
Except the RIRs won't give you another /48 when you have only used one trillion IP addresses.
Patrick W. Gilmore wrote:
Except the RIRs won't give you another /48 when you have only used one trillion IP addresses.
Are you sure? According to ARIN staff, current implementation of policy is that all requests are approved since there are no defined criteria that would allow them to deny any. So far, nobody's shown interest in plugging that hole in the policy because it'd be a major step forward if IPv6 were popular enough for anyone to bother wasting it...
S
Touché. I assumed if you had an allocation and came back for a second, they would say no.
Hrmm, time for me to go get another (or another 1000?) v6 allocations. 
Thanks all for the input.
Cheers,
--Trey
Stephen Sprunk wrote:
Patrick W. Gilmore wrote:
Except the RIRs won't give you another /48 when you have only used one trillion IP addresses.
Keyword: *Another*
Are you sure? According to ARIN staff, current implementation of policy is that all requests are approved since there are no defined criteria that would allow them to deny any. So far, nobody's shown interest in plugging that hole in the policy because it'd be a major step forward if IPv6 were popular enough for anyone to bother wasting it...
S
I believe Stephen is thinking of initial allocation policy - because a subsequent allocation policy in the ARIN region exists: (and it's been modified atleast once in the last few years)
Justification to obtain another netblock is .94 HD-Ratio in the current allocation
Endusers (minimum allocation is a /48)
For a /48 that's about 72% utilization or 184 /56's assigned/used
ISP's (minimum allocation is a /32)
For a /32 that's about 37% utilization or 6,183,533 /56's assigned
ARIN provides a handy chart:
It has been my experience that when you give someone a huge address space
to play with (eg 10/8), they start doing things like using bits in the
address as flags for things. Suddenly you find yourself using a prefix
that should enough for a decent sized country in a half-rack.
Which is, of course, a core design philosophy for IPv6. Stateless autoconfig
relies on the fact that each network will be allocated 2^64 address.
Except the RIRs won't give you another /48 when you have only used one
trillion IP addresses.
Of course they will! A /48 is only the equivalent of 65536 "networks" (each
network being a /64). Presuming that ISPs allocate /64 networks to each
connected subscriber, then a /48 is only 65k subscribers, or say around a
maximum of 200k IP addresses in use at any one time (presuming no NAT and an
average of 3-4 IP-based devices per subscriber)
IPv4-style utilization ratios do make some sense under IPv6, but not at the
address level - only at the network level.
Scott.
First, it was (mostly) a joke.
Second, where did you get 4 users per /64? Are you planning to hand each cable modem a /64?
Patrick W. Gilmore wrote:
I Am Not An ISP either.
I guess I was thinking about v4 modems which do not get a subnet, just an IP address. If we really are handing out a /64 to each DSL & Cable modem, then we may very well be recreating the same problem.
And before anyone says "there are 281474976710656 /48s!", just remember your history. I was not there when v4 was spec'ed out, but I bet when someone said "four-point-two BILLION addresses", someone else said "no $@#%'ing way we will EVER use THAT many...."
> IPv4-style utilization ratios do make some sense under IPv6, but not
> at the
> address level - only at the network level.First, it was (mostly) a joke.
Second, where did you get 4 users per /64? Are you planning to hand
each cable modem a /64?
At the least. Some would say a /56 is more appropriate. So, one /64 for your desktop and one /64 for your open wireless. 
Mike
Patrick W. Gilmore wrote:
Patrick W. Gilmore wrote:
And before anyone says "there are 281474976710656 /48s!", just remember your history. I was not there when v4 was spec'ed out, but I bet when someone said "four-point-two BILLION addresses", someone else said "no $@#%'ing way we will EVER use THAT many...."
Let's face it - the current v6 assignment rules are to solve a 1990s set of problems. A /64 isn't needed now that we have DHCP(v6). Setting the idea in people's heads that a /64 IS going to be their own statically is insane and will blow out provider's own routing tables more than is rational. (Think of the processing overhead of all the DSL/Cable customers going up and down). This is going to be far more of an issue and drive network design than a minor blow out in the v6 routing table.
As Neil Finn of Split Enz fame once wrote:
History never repeats,
I tell myself before I go to sleep.
Followed on the same album by a song called "My Mistake".
MMC
(Who's trying to implement v6 native for DSL customers but finds that the world doesn't
have useable solutions yet for DSL CPE, BRAS, IPv6 allocation etc and doesn't look like it will for a while).
It has been my experience that when you give someone a huge address
space
to play with (eg 10/8), they start doing things like using bits in the
address as flags for things. Suddenly you find yourself using a prefix
that should enough for a decent sized country in a half-rack.Which is, of course, a core design philosophy for IPv6. Stateless
autoconfig
relies on the fact that each network will be allocated 2^64 address.
I'm actually pretty happy about /64's, they take away all the hand-wringing
over how big a network should be, and they make manually configured server
addresses easier to remember through the use of big regions of 0s. I was
thinking more about wasting prefix bits.
-Anthony