In message <4d4eb93e.6000...@brightok.net>, Jack Bates writes:
> On 2/5/2011 11:57 PM, Mark Andrews wrote:
> >
> > Rationalising to power of 2 allocations shouldn't result in requiring
> > 256 times the space you were claiming with the 8 bits of shift on
> > average. A couple of bits will allow t
On 2/5/2011 11:57 PM, Mark Andrews wrote:
Rationalising to power of 2 allocations shouldn't result in requiring
256 times the space you were claiming with the 8 bits of shift on
average. A couple of bits will allow that.
I didn't claim 8 bit average (if I accidentally did, my apologies). I
cl
In message <4d4e1c5d.20...@brightok.net>, Jack Bates writes:
> On 2/5/2011 8:40 PM, Mark Andrews wrote:
> > A IPv4 /16 supports 64000 potential customers. A IPv6 /32 supports
> > 64000 potential customers. Either you have changed the customer
> > estimates or changed the growth space allowances o
On 2/5/2011 9:44 PM, Owen DeLong wrote:
In IPv6, we should be looking to do 5 or 10 year allocations. We can
afford to be fairly speculative in
our allocations in order to preserve greater aggregation.
And even if networks were only getting an 8 bit slide, that's 256 trips
back to the RIR to
On 2/5/2011 8:40 PM, Mark Andrews wrote:
A IPv4 /16 supports 64000 potential customers. A IPv6 /32 supports
64000 potential customers. Either you have changed the customer
estimates or changed the growth space allowances or were using NAT
or
You don't suddenly need 256 times the amount of
On Feb 5, 2011, at 6:38 PM, Nathan Eisenberg wrote:
>> Still, that is a considerable number of bits we'll have left when the dust
>> settles and the RIR allocation rate drastically slows.
>
> Like it did for IPv4? ;)
>
> -Nathan
>
It long since would have if ISPs didn't have to come back annu
On Feb 5, 2011, at 5:20 PM, Jack Bates wrote:
> On 2/5/2011 7:01 PM, Mark Andrews wrote:
>> And did you change the amount of growth space you allowed for each pop?
>> Were you already constrained in your IPv4 growth space and just restored
>> your desired growth margins?
>>
> Growth rate has not
In message <4d4df75e.1040...@brightok.net>, Jack Bates writes:
> On 2/5/2011 7:01 PM, Mark Andrews wrote:
> > And did you change the amount of growth space you allowed for each pop?
> > Were you already constrained in your IPv4 growth space and just restored
> > your desired growth margins?
> >
>
> Still, that is a considerable number of bits we'll have left when the dust
> settles and the RIR allocation rate drastically slows.
Like it did for IPv4? ;)
-Nathan
On 2/5/2011 7:01 PM, Mark Andrews wrote:
And did you change the amount of growth space you allowed for each pop?
Were you already constrained in your IPv4 growth space and just restored
your desired growth margins?
Growth rate has nothing to do with it. ARIN doesn't allow for growth in
initial
In message <4d4d5ffc.6020...@brightok.net>, Jack Bates writes:
> On 2/5/2011 6:47 AM, Mark Andrews wrote:
> > So why the ~!#! are you insisting on comparing IPv4 allocations with IPv6
> > alocations.
> >
> Because that is where the comparison must be made, at the RIR allocation
> size/rate level.
On Sat, Feb 05, 2011 at 11:47:10PM +1100, Mark Andrews wrote:
>
> In message <4d4ca1b1.5060...@brightok.net>, Jack Bates writes:
> > On 2/4/2011 6:45 PM, Mark Andrews wrote:
> > >
> > > I used to work for CSIRO. Their /16's which were got back in the
> > > late 80's will now be /48's.
> >
> > Th
On 2/5/2011 6:47 AM, Mark Andrews wrote:
So why the ~!#! are you insisting on comparing IPv4 allocations with IPv6
alocations.
Because that is where the comparison must be made, at the RIR allocation
size/rate level.
There are two sizes. Those that fit into a /32 and those that don't.
The la
In message <4d4ca1b1.5060...@brightok.net>, Jack Bates writes:
> On 2/4/2011 6:45 PM, Mark Andrews wrote:
> >
> > I used to work for CSIRO. Their /16's which were got back in the
> > late 80's will now be /48's.
>
> That's why I didn't try doing any adjustments of X is the new /32. The
> whole
On 2/4/2011 6:45 PM, Mark Andrews wrote:
I used to work for CSIRO. Their /16's which were got back in the
late 80's will now be /48's.
That's why I didn't try doing any adjustments of X is the new /32. The
whole paradigm changes. Many ISPs devote large amounts of space to
single corporate
In message <4d4c8af8.1030...@brightok.net>, Jack Bates writes:
> On 2/4/2011 5:11 PM, Mark Andrews wrote:
> > No, a /48 is equivalent to a single IP.
> >
> > You loose a little bit with small ISPs as their minimum is a /32
> > and supports up to 64000 customers. The bigger ISPs don't get to
> > w
On Feb 4, 2011, at 8:50 AM, bmann...@vacation.karoshi.com wrote:
> On Fri, Feb 04, 2011 at 08:28:53AM -0600, Jack Bates wrote:
>>
>>
>> On 2/4/2011 5:03 AM, Eugen Leitl wrote:
>>
>>> Given
>>> http://weblog.chrisgrundemann.com/index.php/2009/how-much-ipv6-is-there/
>>> it is pretty clear the
On 2/4/2011 5:11 PM, Mark Andrews wrote:
No, a /48 is equivalent to a single IP.
You loose a little bit with small ISPs as their minimum is a /32
and supports up to 64000 customers. The bigger ISPs don't get to
waste addresses space. And if a small ISP is getting space from
a big ISP it also n
In message <4d4c0d25.70...@brightok.net>, Jack Bates writes:
>
>
> On 2/4/2011 5:03 AM, Eugen Leitl wrote:
>
> > Given http://weblog.chrisgrundemann.com/index.php/2009/how-much-ipv6-is-the
> re/
> > it is pretty clear the allocation algorithms have to change, or the resourc
> e
> > is just as f
On 2/4/2011 10:50 AM, bmann...@vacation.karoshi.com wrote:
I suspect that many people will do stupid things in managing their
bits - presuming that there is virtually infinate 'greenfield' and
when they have "pissed in the pool" they can just move on to a new
poo
On Fri, Feb 04, 2011 at 08:28:53AM -0600, Jack Bates wrote:
>
>
> On 2/4/2011 5:03 AM, Eugen Leitl wrote:
>
> >Given
> >http://weblog.chrisgrundemann.com/index.php/2009/how-much-ipv6-is-there/
> >it is pretty clear the allocation algorithms have to change, or the
> >resource
> >is just as fini
On 2/4/2011 5:03 AM, Eugen Leitl wrote:
Given http://weblog.chrisgrundemann.com/index.php/2009/how-much-ipv6-is-there/
it is pretty clear the allocation algorithms have to change, or the resource
is just as finite as the one we ran out yesterday.
That's not what the author says. It says, IPv
On Thu, Feb 03, 2011 at 08:17:11PM -0300, Fernando Gont wrote:
> > I'm mildly surprised if you think we're going to be done with *this*
> > mess in a few decades.
>
> I fully agree. But planning/expecting to go through this mess *again* is
> insane. -- I hope the lesson has been learned, and we
On Thu, Feb 3, 2011 at 3:17 PM, Fernando Gont wrote:
> On 03/02/2011 10:07 a.m., Rob Evans wrote:
>
>>> You must be kiddin'... You're considering going through this mess
>>> again in a few decades?
>>
>> I'm mildly surprised if you think we're going to be done with *this*
>> mess in a few decades.
On 03/02/2011 10:07 a.m., Rob Evans wrote:
>> You must be kiddin'... You're considering going through this mess
>> again in a few decades?
>
> I'm mildly surprised if you think we're going to be done with *this*
> mess in a few decades.
I fully agree. But planning/expecting to go through this m
On Thursday, February 03, 2011 10:39:28 am TJ wrote:
> Correct me if I am wrong, but won't Classified networks will get their
> addresses IAW the DoD IPv6 Addressing Plan (using globals)?
'Classified' networks are not all governmental. HIPPA requirements can be met
with SCIFs, and those need 'cl
Sent: Thursday, February 03, 2011 10:39 AM
To: NANOG
Subject: Re: Using IPv6 with prefixes shorter than a /64 on a LAN
On Wed, Feb 2, 2011 at 08:11, Jamie Bowden wrote:
> Our classified networks aren't ever going to be connected to anything
> but themselves either, and they need sane
On Wed, Feb 2, 2011 at 08:11, Jamie Bowden wrote:
> Our classified networks aren't ever going to be connected to anything
> but themselves either, and they need sane local addressing. Some of
> them are a single room with a few machines, some of them are entire
> facilities with hundreds of mach
> > The subject says it all... anyone with experience with a setup like
> > this ?
>
> Unicast addresses must be located in at least a /64 subnet. No doubt
> there are vendors which enforce this (perhaps even in the ASICs), so
> deviating from this rule will result in some lock-in.
The Juniper a
> You must be kiddin'... You're considering going through this mess again
> in a few decades?
I'm mildly surprised if you think we're going to be done with *this*
mess in a few decades.
Rob
* Ray Soucy:
> Every time I see this question it' usually related to a fundamental
> misunderstanding of IPv6 and the attempt to apply v4 logic to v6.
True, you have to ignore more than a decade of IPv4 protocol
development and resort to things like pre-VLSM networking.
> That said. Any size pr
* Carlos Martinez-Cagnazzo:
> The subject says it all... anyone with experience with a setup like
> this ?
Unicast addresses must be located in at least a /64 subnet. No doubt
there are vendors which enforce this (perhaps even in the ASICs), so
deviating from this rule will result in some lock-i
On 26/01/2011 09:44 p.m., Karl Auer wrote:
> So let's get rid of the limitation in our minds. IPv6 provides
> *effectively* unlimited address space, even if it's only "for now". So
> let's USE it that way. Let's unlearn our limited thinking patterns.
> Let's go colonise infinity. And if we need to
On Wed, Feb 2, 2011 at 5:07 PM, Carlos Martinez-Cagnazzo
wrote:
> Disconnected networks have a bothersome tendency to get connected at
> some point ( I have been severely bitten by this in the past ), so
> while I agree that there is no need to coordinate anything globally,
> then a RFC 1918-like
Disconnected networks have a bothersome tendency to get connected at
some point ( I have been severely bitten by this in the past ), so
while I agree that there is no need to coordinate anything globally,
then a RFC 1918-like definition would be nice (if we are not going to
use ULAs, that is)
chee
outer or anything upstream, as neither of those exist on
said networks.
Jamie
-Original Message-
From: Chuck Anderson [mailto:c...@wpi.edu]
Sent: Tuesday, February 01, 2011 6:39 PM
To: nanog@nanog.org
Subject: Re: Using IPv6 with prefixes shorter than a /64 on a LAN
On Tue, Feb 01, 2011
On Tue, 01 Feb 2011 17:37:55 PST, Bill Stewart said:
> A typical home user will have a /56 of GUA, or maybe a /48 with some
> ISPs. Anybody who knows enough to figure out how to set a ULA can
> figure out a /64 from their GUA space that's not being auto-assigned
> by one of their various home rout
On Feb 1, 2011, at 5:37 PM, Bill Stewart wrote:
> On 2/1/11, Chuck Anderson wrote:
>> What would your recommended solution be then for disconnected
>> networks? Every home user and enterprise user requests GUA directly
>> from their RIR/NIR/LIR at a cost of hunderds of dollars per year or
>> mo
On Feb 1, 2011, at 3:38 PM, Chuck Anderson wrote:
> On Tue, Feb 01, 2011 at 03:14:57PM -0800, Owen DeLong wrote:
>> On Feb 1, 2011, at 2:58 PM, Jack Bates wrote:
>>> There are many cases where ULA is a perfect fit, and to work
>>> around it seems silly and reduces the full capabilities of IPv6.
On Feb 1, 2011, at 3:25 PM, Jack Bates wrote:
> On 2/1/2011 5:14 PM, Owen DeLong wrote:
>> I guess we can agree to disagree about this. I haven't seen one yet.
>
> If my coffee maker did have an IP address, I expect it to get all it's
> updates from a central house store, not directly from the
On 2/1/11, Chuck Anderson wrote:
> What would your recommended solution be then for disconnected
> networks? Every home user and enterprise user requests GUA directly
> from their RIR/NIR/LIR at a cost of hunderds of dollars per year or
> more?
A typical home user will have a /56 of GUA, or mayb
On Tue, Feb 1, 2011 at 3:38 PM, Chuck Anderson wrote:
> On Tue, Feb 01, 2011 at 03:14:57PM -0800, Owen DeLong wrote:
>> On Feb 1, 2011, at 2:58 PM, Jack Bates wrote:
>> > There are many cases where ULA is a perfect fit, and to work
>> > around it seems silly and reduces the full capabilities of IP
On Tue, Feb 01, 2011 at 03:14:57PM -0800, Owen DeLong wrote:
> On Feb 1, 2011, at 2:58 PM, Jack Bates wrote:
> > There are many cases where ULA is a perfect fit, and to work
> > around it seems silly and reduces the full capabilities of IPv6. I
> > fully expect to see protocols and networks withi
On 2/1/2011 5:14 PM, Owen DeLong wrote:
I guess we can agree to disagree about this. I haven't seen one yet.
If my coffee maker did have an IP address, I expect it to get all it's
updates from a central house store, not directly from the manufacturer
over the net. I see no reason my appliance
On Feb 1, 2011, at 2:58 PM, Jack Bates wrote:
> On 2/1/2011 3:23 PM, Owen DeLong wrote:
>> Given the vast probability for abuse of ULA becoming de facto GUA later, I
>> don't support ULA existing as the benefits are vastly overwhelmed by the
>> potential for abouse.
> If the world wants ULA to
On 2/1/2011 3:23 PM, Owen DeLong wrote:
Given the vast probability for abuse of ULA becoming de facto GUA later, I
don't support ULA existing as the benefits are vastly overwhelmed by the
potential for abouse.
If the world wants ULA to become the de facto GUA, no amount of arm
twisting and bul
On Feb 1, 2011, at 9:39 AM, Jack Bates wrote:
> On 2/1/2011 11:29 AM, Owen DeLong wrote:
>>
>> I prefer persistent GUA over ULA for that.
>>
>
> I do too, though for simple zeroconf devices, I'd prefer ULA over link local.
> Given that it's not an either or situation, I fully support ULA exis
On Feb 1, 2011, at 7:43 AM, Jack Bates wrote:
>
>
> On 2/1/2011 9:23 AM, Tim Franklin wrote:
>> I really,*really* expect my CPE router*not* to remove global
>> addresses from the LAN interface(s) when the link to the Internet
>> goes down. My internal services should go on working with their
On 2/1/2011 11:29 AM, Owen DeLong wrote:
I prefer persistent GUA over ULA for that.
I do too, though for simple zeroconf devices, I'd prefer ULA over link
local. Given that it's not an either or situation, I fully support ULA
existing.
Jack
On Feb 1, 2011, at 7:04 AM, Jack Bates wrote:
>
>
> On 2/1/2011 12:03 AM, Owen DeLong wrote:
>> The rest... All those TiVOs, Laptops, Desktops, iPads, etc. all need
>> public addresses anyway, so, why bother with the ULA?
>>
>
> I think ULA is still useful for home networks. If the home route
On 2/1/2011 9:23 AM, Tim Franklin wrote:
I really,*really* expect my CPE router*not* to remove global
addresses from the LAN interface(s) when the link to the Internet
goes down. My internal services should go on working with their
global addresses. This is how my tunneled IPv6 works today.
> I think ULA is still useful for home networks. If the home router guys
> properly generate the ULA dynamically, it should stop conflicts within
> home networking. There's something to be said for internal services
> which ULA can be useful for, even when you do fall off the net.
I really, *re
On 2/1/2011 12:03 AM, Owen DeLong wrote:
The rest... All those TiVOs, Laptops, Desktops, iPads, etc. all need
public addresses anyway, so, why bother with the ULA?
I think ULA is still useful for home networks. If the home router guys
properly generate the ULA dynamically, it should stop co
On 1/31/2011 11:02 PM, Mikael Abrahamsson wrote:
Guess XR is the way to go if one wants to keep it for a few more years...
Or XE (lower end ASR uses XE I believe).
Jack
On Sun, Jan 30, 2011 at 6:24 PM, Fernando Gont wrote:
> Hi, Matthew,
>
> On 30/01/2011 08:17 p.m., Matthew Petach wrote:
The problem I see is the opening of a new, simple, DoS/DDoS scenario.
By repetitively sweeping a targets /64 you can cause EVERYTHING in
that /64 to stop working
On Jan 31, 2011, at 10:26 PM, Michael Dillon wrote:
>> In my opinion, RFC 4193 is just a bad idea and there's no benefit to it vs.
>> GUA. Just put a good stateful firewall in front of your GUA.
>>
>> I mean, really, how many things do you have that don't need access
>> to/from the internet. May
> In my opinion, RFC 4193 is just a bad idea and there's no benefit to it vs.
> GUA. Just put a good stateful firewall in front of your GUA.
>
> I mean, really, how many things do you have that don't need access
> to/from the internet. Maybe your printers and a couple of appliances.
>
> The rest...
On Jan 31, 2011, at 9:35 PM, eric clark wrote:
> Figure I'll throw my 2 cents into this.
>
> The way I read the RFCs, IPv6 is not IP space. Its network space. Unless I
> missed it last time I read through them, the RFCs do not REQUIRE
> hardware/software manufacturers to support VLSM beyond /64.
Figure I'll throw my 2 cents into this.
The way I read the RFCs, IPv6 is not IP space. Its network space. Unless I
missed it last time I read through them, the RFCs do not REQUIRE
hardware/software manufacturers to support VLSM beyond /64. Autoconfigure
the is the name of the game for the IPv6 guy
On Mon, 31 Jan 2011, Per Carlson wrote:
Really? I've tried to duplicate the results in our lab, but I can't
provoke any problems at those numbers. Is it the "other" multicast
traffic that's interfering with ND?
It's a hold-queue problem. Normally IPv6 input is around 0.5% CPU on the
RP, but
> At AMSIX, a Cisco 12000 running IOS will get into trouble with the 170pps of
> ND seen there. AMSIX doesn't do MLD snooping so everybody gets everything
> and on IOS 12000 ND is punted to RP and when it's busy with calculating BGP,
> it'll start dropping BGP sessions.
Really? I've tried to dupli
On Sun, 30 Jan 2011, Matthew Petach wrote:
Even without completely overflowing the ND cache, informal lab testing
shows that a single laptop on a well-connected network link can send
sufficient packets at a very-large-scale backbone router's connected /64
subnet to keep the router CPU at 90%,
Hi, Matthew,
On 30/01/2011 08:17 p.m., Matthew Petach wrote:
>>> The problem I see is the opening of a new, simple, DoS/DDoS scenario.
>>> By repetitively sweeping a targets /64 you can cause EVERYTHING in
>>> that /64 to stop working by overflowing the ND/ND cache, depending on
>>> the specific N
On Tue, Jan 25, 2011 at 10:26 PM, Fernando Gont wrote:
> On 24/01/2011 07:41 p.m., Michael Loftis wrote:
>
>>> Many cite concerns of potential DoS attacks by doing sweeps of IPv6
>>> networks. I don't think this will be a common or wide-spread problem.
>>> The general feeling is that there is si
>
> In any case, the fact you can stick a terabyte of RAM into a 4U Dell
> rack mount that sucks a whole lot of power doesn't mean we're anywhere
> near being able to do it for consumer-class hardware. Remember, much
> of the growth is going to be in the embedded and special purpose
> systems - t
On Sun, 30 Jan 2011 17:39:45 +0100, Leen Besselink said:
> On 01/25/2011 11:06 PM, Owen DeLong wrote:
> >
> >
> >> "640k ought to be enough for anyone."
Remember that when this apocryphal statement was allegedly made in 1981, IBM
mainframes and Crays and the like were already well in to the 64-256
On Jan 30, 2011, at 8:39 AM, Leen Besselink wrote:
> On 01/25/2011 11:06 PM, Owen DeLong wrote:
>>
>>
>>> "640k ought to be enough for anyone."
>>>
>> If IPv4 is like 640k, then, IPv6 is like having
>> 47,223,664,828,696,452,136,959
>> terabytes of RAM. I'd argue that while 640k was short sig
On Sun, 2011-01-30 at 17:39 +0100, Leen Besselink wrote:
> On 01/25/2011 11:06 PM, Owen DeLong wrote:
> > If IPv4 is like 640k, then, IPv6 is like having
> > 47,223,664,828,696,452,136,959
> > terabytes of RAM. I'd argue that while 640k was short sighted, I think it is
> > unlikely we will see mac
On 01/25/2011 11:06 PM, Owen DeLong wrote:
>
>
>> "640k ought to be enough for anyone."
>>
> If IPv4 is like 640k, then, IPv6 is like having 47,223,664,828,696,452,136,959
> terabytes of RAM. I'd argue that while 640k was short sighted, I think it is
> unlikely we will see machines with much more t
On 26/01/2011 06:14 a.m., Owen DeLong wrote:
>>> That said. Any size prefix will likely work and is even permitted by
>>> the RFC. You do run the risk of encountering applications that assume
>>> a 64-bit prefix length, though. And you're often crippling the
>>> advantages of IPv6.
>>
>> Just cu
On 26/01/2011 11:36 p.m., Douglas Otis wrote:
>>> Discovery implemented at layer 2 fully mitigate these issues? I too
>>> would be interested in hearing from Radia and Fred.
>> It need not. Also, think about actual deployment of SEND: for instance,
>> last time I checked Windows Vista didn't supp
On 1/25/11 6:00 PM, Fernando Gont wrote:
On 24/01/2011 08:42 p.m., Douglas Otis wrote:
It seems efforts related to IP address specific policies are likely
doomed by the sheer size of the address space, and to be pedantic, ARP
has been replaced with multicast neighbor discovery which dramatically
On Wed, 2011-01-26 at 11:53 +0700, Roland Dobbins wrote:
> On Jan 26, 2011, at 11:37 AM, Adrian Chadd wrote:
> The supreme irony of this situation is that folks who're convinced
> that there's no way we can even run out of addresses often accuse
> those of us who're plentitude-skeptics of old-fashi
On Jan 25, 2011, at 2:07 PM, valdis.kletni...@vt.edu wrote:
> On Tue, 25 Jan 2011 16:17:59 EST, Ricky Beam said:
>> On Mon, 24 Jan 2011 19:46:19 -0500, Owen DeLong wrote:
>>> Dude... In IPv6, there are 18,446,744,073,709,551,616 /64s.
>>
>> Those who don't learn from history are doomed to repea
I think we're losing focus on the discussion here.
The core issue here is that ND tables have a finite size, just like
ARP tables. Making an unsolicited request to a subnet will cause ND
on the router to try and reach find the host.
This can be a problem with subnets as small as 1024 (I constant
On Jan 26, 2011, at 6:29 PM, Eugen Leitl wrote:
> In practice you'd aim for ~um resolution for all major gravity wells in this
> system (DTN is already flying, there's a Cisco box in Earth orbit, Moon and
> Mars are next).
Don't forget the asteroid belt, that's where the real money is.
--
On Wed, Jan 26, 2011 at 01:33:05AM +, Nathan Eisenberg wrote:
> > Even if every RIR gets to 3 /12s in 50 years, that's still only 15/512ths
> > of the
> > initial /3 delegated to unicast space by IETF. There are 6+ more /3s
> > remaining
> > in the IETF pool.
>
> That's good news - we need t
On Jan 25, 2011, at 10:30 PM, Fernando Gont wrote:
> On 24/01/2011 05:53 p.m., Ray Soucy wrote:
>> Every time I see this question it' usually related to a fundamental
>> misunderstanding of IPv6 and the attempt to apply v4 logic to v6.
>>
>> That said. Any size prefix will likely work and is ev
On Jan 25, 2011, at 9:49 PM, Roland Dobbins wrote:
>
> On Jan 26, 2011, at 12:33 PM, Mark Smith wrote:
>
>> The correct assumption is that most people will try and usually succeed at
>> follow the specifications, as that is what is required to
>> successfully participate in a protocol (any pro
On 25/01/2011 11:29 p.m., Roland Dobbins wrote:
> On Jan 26, 2011, at 8:12 AM, Fernando Gont wrote:
>
>> Also, the claim that "IPv6 address scanning is impossible" is
>> generally based on the (incorrect) assumption that host addresses
>> are spread (randomly) over the 64-bit IID. -- But they usua
On 24/01/2011 05:53 p.m., Ray Soucy wrote:
> Every time I see this question it' usually related to a fundamental
> misunderstanding of IPv6 and the attempt to apply v4 logic to v6.
>
> That said. Any size prefix will likely work and is even permitted by
> the RFC. You do run the risk of encounte
On 24/01/2011 07:41 p.m., Michael Loftis wrote:
>> Many cite concerns of potential DoS attacks by doing sweeps of IPv6
>> networks. I don't think this will be a common or wide-spread problem.
>> The general feeling is that there is simply too much address space
>> for it to be done in any reason
On Wed, 26 Jan 2011 12:49:13 +0700
Roland Dobbins wrote:
>
> On Jan 26, 2011, at 12:33 PM, Mark Smith wrote:
>
> > The correct assumption is that most people will try and usually succeed at
> > follow the specifications, as that is what is required to
> > successfully participate in a protocol
On Tue, 25 Jan 2011, Tony Hain wrote:
Every organization with a *real* customer base should have significantly
shorter than a /32. In particular every organization that says "I can't
give my customers prefix length X because I only have a /32" needs to go
back to ARIN today and trade that in f
On Jan 26, 2011, at 12:33 PM, Mark Smith wrote:
> The correct assumption is that most people will try and usually succeed at
> follow the specifications, as that is what is required to
> successfully participate in a protocol (any protocol, not just networking
> ones). IPv4 history has shown th
On Wed, 26 Jan 2011 11:53:23 +0700
Roland Dobbins wrote:
>
> On Jan 26, 2011, at 11:37 AM, Adrian Chadd wrote:
>
> > But simply assuming that the IPv6 address space will forever remain that -
> > only unique host identifiers - I think is disingenious at best. :-)
>
> I think 'disingenuous' is
> ...
>
> What did that just do to your per-site /64? That you have
> no hope of ever seeing a user use up? It just turned
> that /64 into a /112 (16 bits of port space, 32 bits
> of cloud identifier space.) What's the next killer app
> that'll chew up more of your IPv6 space?
>
Dude... You miss
On Jan 25, 2011, at 8:47 PM, George Bonser wrote:
>
>
>> From: Adrian Chadd
>> Sent: Tuesday, January 25, 2011 8:37 PM
>> To: Owen DeLong
>> Cc: nanog@nanog.org
>> Subject: Re: Using IPv6 with prefixes shorter than a /64 on a LAN
>>
>> (Top-
On Jan 26, 2011, at 11:37 AM, Adrian Chadd wrote:
> But simply assuming that the IPv6 address space will forever remain that -
> only unique host identifiers - I think is disingenious at best. :-)
I think 'disingenuous' is too strong a word - 'overly optimistic' better
reflects the position, I
> From: Adrian Chadd
> Sent: Tuesday, January 25, 2011 8:37 PM
> To: Owen DeLong
> Cc: nanog@nanog.org
> Subject: Re: Using IPv6 with prefixes shorter than a /64 on a LAN
>
> (Top-posting because the whole message is context. Oh, and I'm lazy.)
>
> I do inde
(Top-posting because the whole message is context. Oh, and I'm lazy.)
I do indeed love it when people break out IPv6 addressing as
"there's so many addresses, we'll never ever go through them!"
Sure, if they're only used as end-point identifiers.
Say you want to crack out that 64k-port space int
On Jan 26, 2011, at 11:17 AM, Jimmy Hess wrote:
> There are other methods of discovery as well, but they are not close in
> scale or 'ease of use' to what brute-force address space scanning
> could easily accomplish with IPv4.
Most botted hosts today are compromised in the first place via laye
On Tue, Jan 25, 2011 at 8:29 PM, Roland Dobbins wrote:
> On Jan 26, 2011, at 8:12 AM, Fernando Gont wrote:
>> Also, the claim that "IPv6 address scanning is impossible" is generally
>> based on the (incorrect) assumption that host addresses are spread
>> (randomly) over the 64-bit IID. -- But the
On Jan 26, 2011, at 8:12 AM, Fernando Gont wrote:
> Also, the claim that "IPv6 address scanning is impossible" is generally based
> on the (incorrect) assumption that host addresses are spread
> (randomly) over the 64-bit IID. -- But they usually aren't.
It also doesn't take into account hinted
On Jan 25, 2011, at 5:33 PM, Nathan Eisenberg wrote:
>> Even if every RIR gets to 3 /12s in 50 years, that's still only 15/512ths of
>> the
>> initial /3 delegated to unicast space by IETF. There are 6+ more /3s
>> remaining
>> in the IETF pool.
>
> That's good news - we need to make sure we h
On 24/01/2011 08:42 p.m., Douglas Otis wrote:
> It seems efforts related to IP address specific policies are likely
> doomed by the sheer size of the address space, and to be pedantic, ARP
> has been replaced with multicast neighbor discovery which dramatically
> reduces the overall traffic involv
> Even if every RIR gets to 3 /12s in 50 years, that's still only 15/512ths of
> the
> initial /3 delegated to unicast space by IETF. There are 6+ more /3s remaining
> in the IETF pool.
That's good news - we need to make sure we have a /3 for both the Moon and Mars
colonies. ;)
Nathan
On 25/01/2011 11:44 a.m., Ray Soucy wrote:
> The argument can also be made that using smaller prefixes with
> sequential host numbering will lead to making network sweeps and port
> scanning viable in IPv6 where it would otherwise be useless. At that
> point you just need evidence of one IPv6 add
On 24/01/2011 09:46 p.m., Owen DeLong wrote:
>>> Many cite concerns of potential DoS attacks by doing sweeps of
>>> IPv6 networks. I don't think this will be a common or
>>> wide-spread problem.
>>
>> Myopia doesn't make the problem go away. The point of such an
>> attack is not to "find things
On Jan 25, 2011, at 4:20 PM, Tony Hain wrote:
> Owen DeLong wrote:
>> ..
>> I suspect that there are probably somewhere between 30,000
>> and 120,000 ISPs world wide that are likely to end up with a /32
>> or shorter prefix.
>
> A /32 is the value that a start-up ISP would have. Assuming tha
1 - 100 of 131 matches
Mail list logo
