> Does anyone know a good Bandwidth Prediction tool?.
yes. times 1.5-2.0 every year
On Tue, Nov 29, 2011 at 10:31 PM, Owen DeLong wrote:
> On Nov 29, 2011, at 10:11 AM, Joel jaeggli wrote:
>> On 11/29/11 09:30 , Owen DeLong wrote:
>>> I believe those have been obsoleted, but, /64 remains the best choice, IMHO.
>> operational practice has moved on.
>> http://tools.ietf.org/html/rf
On Nov 29, 2011, at 10:11 AM, Joel jaeggli wrote:
> On 11/29/11 09:30 , Owen DeLong wrote:
>> I believe those have been obsoleted, but, /64 remains the best choice, IMHO.
>
> operational practice has moved on.
>
> http://tools.ietf.org/html/rfc6164
>
RFC 6164 does not say anything bad about u
On Nov 29, 2011, at 9:46 AM, Ray Soucy wrote:
> Could you provide an example of such an ACL that can prevent neighbor
> table exhaustion while maintaining a usable 64-bit prefix? I am
> intrigued.
>
For a point-to-point link... Sure...
Router A: 2001:db8:0:0:1::
Router B: 2001:db8:0:0:2::
pe
A /112 is almost as bad for the ND attacks as a /64, so, I don't see any reason
to use a /112 at all.
IMHO, the preferred link network sizes for IPv6 are, in order, /64, /127, /126,
/112.
Since there's no downside to the first one so long as you take proper
precautions about ND attacks,
most e
> That said; neighbor table exhaustion is a real problem. A few lines
> of C can kill IPv6 on enterprise- and carrier-grade routers. It's a
> problem that has gone largely ignored because people are still in a
> private address space mindset.
>
Only if you don't have rational ACLs in place or y
On Tue, Nov 29, 2011 at 12:42 AM, Owen DeLong wrote:
> That's _NOT_ a fair characterization of what I said above, nor is it
> a fair characterization of my approach to dealing with neighbor table
> attacks.
Here are some direct quotes from our discussion:
> Since we have relatively few customers
On Nov 28, 2011, at 9:15 PM, Jeff Wheeler wrote:
> On Mon, Nov 28, 2011 at 4:51 PM, Owen DeLong wrote:
>> Technically, absent buggy {firm,soft}ware, you can use a /127. There's no
>> actual benefit to doing anything longer than a /64 unless you have
>> buggy *ware (ping pong attacks only work ag
We lost several of our GigE links to AT&T for 6 hours on 11/19, anyone else see
this and get a root cause from AT&T? All I can get is that they believe a
change caused the issue.
On 11/29/11 09:30 , Owen DeLong wrote:
> I believe those have been obsoleted, but, /64 remains the best choice, IMHO.
operational practice has moved on.
http://tools.ietf.org/html/rfc6164
> Owen
>
> On Nov 29, 2011, at 9:00 AM, McCall, Gabriel wrote:
>
>> Note that /127 is strongly discouraged
Could you provide an example of such an ACL that can prevent neighbor
table exhaustion while maintaining a usable 64-bit prefix? I am
intrigued.
On Tue, Nov 29, 2011 at 12:21 PM, Owen DeLong wrote:
>
> On Nov 29, 2011, at 4:58 AM, Dmitry Cherkasov wrote:
>
>> Thanks to everybody participating in
I believe those have been obsoleted, but, /64 remains the best choice, IMHO.
Owen
On Nov 29, 2011, at 9:00 AM, McCall, Gabriel wrote:
> Note that /127 is strongly discouraged in RFC5375 and RFC3627. 3627 suggests
> using /112 for router links, or /126 at the very most.
>
> -Original Messag
On Nov 29, 2011, at 4:58 AM, Dmitry Cherkasov wrote:
> Thanks to everybody participating in the discussion.
> I try to summarize.
>
> 1) There is no any obvious benefit of using longer prefixes then /64
> in DOCSIS networks yet there are no definite objections to use them
> except that it violat
Is Equinix Denver the old Switch and Data site at 9706 East Easter Avenue,
Suite 160, Englewood, Colorado, 80112?
Edward Dore
Freethought Internet
- Original Message -
From: "Keegan Holley"
To: "NANOG"
Sent: Tuesday, 29 November, 2011 4:47:37 PM
Subject: Equinix
Assuming it's not own
Yes and no; RFC6164 is attempting to make that more acceptable.
Although; the only thing that pushed us from /30 to /31 in IPv4 was
the address space crunch; that doesn't exist in the IPv6 world; so
using /127 instead of /126 really doesn't seem to buy us much.
On Tue, Nov 29, 2011 at 12:00 PM, M
We have an in-house IPAM system that's built on top of ISC DHCPd.
As far as DHCPd configuration is concerned we only ever hand out
static assignments; we have a different process that monitors
un-responded requests coming in; allocates an address from the
database (if permitted by the logic), and
> Note that /127 is strongly discouraged in RFC5375 and RFC3627. 3627
> suggests using /112 for router links, or /126 at the very most.
Of potential interest, since you bring up RFC3627, is the following draft, and
RFC6164:
http://tools.ietf.org/html/draft-george-6man-3627-historic-01
http://too
Note that /127 is strongly discouraged in RFC5375 and RFC3627. 3627 suggests
using /112 for router links, or /126 at the very most.
-Original Message-
From: Fred Baker [mailto:f...@cisco.com]
...
I see no reason you couldn't use a /127 prefix if the link was point to point.
...
They have been real slow to respond to me in the past 14 days. They say it's a
24 hour turn around after calling their marketing line, I'm still waiting a
call back and I've left 3 messages.
I guess they don't want to lease a cab in TX…
On Nov 29, 2011, at 9:47 AM, Keegan Holley wrote:
> Assumi
Assuming it's not owned by the NSA does anyone know the address of the
equnix colo in the Denver area? I'm working on pricing access circuits
into it. A contact from equinix would be helpful as well. We haven't
gotten a response to our queries.
Regards,
Keegan
In a message written on Tue, Nov 29, 2011 at 11:39:06AM -0500, Ray Soucy wrote:
> We run both systems, in production, using DHCPv6 on prefixes much
> smaller than 64-bit (typically 120 or 119; we mirror whatever the IPv4
> prefix length is).
Can you explain a bit more about how this works? My und
Windows (Vista and later) and OS X (as of Lion) now have mature IPv6
implementations and support DHCPv6 for address allocation.
Furthermore, they correctly let the network decide which method is
used and only provide the user with the option of "Manual" or
"Automatic", where Automatic will make use
CFP: Special Issue of COMPUTER NETWORS (ELSEVIER) on "Botnet Activity:
Analysis, Detection and Shutdown"
Apologies for multiple copies of this announcement.
-
Dear Colleagues,
Please consider the following opportunity to submit and publish original
scientific results to
On Tue, 29 Nov 2011 03:23:04 EST, Jeff Wheeler said:
> On Tue, Nov 29, 2011 at 1:43 AM, wrote:
> > It's worked for us since 1997. We've had bigger problems with IPv4 worms
>
> That's not a reason to deny that the problem exists. It's even
> fixable. I'd prefer that vendors fixed it *before* the
And here is another useful resource:
http://csrc.nist.gov/publications/nistpubs/800-119/sp800-119.pdf,
particularly chapter 6.1.3 Vulnerabilities in IPv6.
Dmitry Cherkasov
2011/11/29 Victor Kuarsingh :
> Dmitry et al,
>
> I found Jeff's following comments to be quite insightful for general
> p
Dmitry et al,
I found Jeff's following comments to be quite insightful for general
practices.
http://www.networkcomputing.com/ipv6-tech-center/231600717
http://www.networkcomputing.com/ipv6-tech-center/231700160
As for using 127s on P2P links
He discussed reasoning behind using /64s, conce
On Tue, 29 Nov 2011 15:06:15 +0200, Denys Fedoryshchenko
wrote:
Google DNS was down few minutes, at least for few European locations
Here is sample traceroute:
4 213.242.116.25 (213.242.116.25) 39.692 ms 39.776 ms 39.774 ms
5 ae-7-7.ebr1.Paris1.Level3.net (4.69.143.238) 50.933 ms 50
We also observed this issue...
# traceroute 8.8.8.8
traceroute to 8.8.8.8 (8.8.8.8), 30 hops max, 40 byte packets
1 r1.ldn.uk.sharedband.net (109.68.192.1) 0.480 ms 0.515 ms 0.523 ms
2 195.66.224.125 (195.66.224.125) 0.451 ms 0.453 ms 0.445 ms
3 64.233.175.27 (64.233.175.27) 0.708 ms
Google DNS was down few minutes, at least for few European locations
Here is sample traceroute:
4 213.242.116.25 (213.242.116.25) 39.692 ms 39.776 ms 39.774 ms
5 ae-7-7.ebr1.Paris1.Level3.net (4.69.143.238) 50.933 ms 50.792 ms
50.793 ms
6 ae-47-47.ebr1.London1.Level3.net (4.69.143.1
Thanks to everybody participating in the discussion.
I try to summarize.
1) There is no any obvious benefit of using longer prefixes then /64
in DOCSIS networks yet there are no definite objections to use them
except that it violates best practices and may lead to some problems
in the future
2) D
Tore,
To comply with this policy we delegate at least /64 to end-users
gateways. But this policy does not cover the network between WAN
interfaces of CPE and ISP access gateway.
Dmitry Cherkasov
2011/11/29 Tore Anderson :
> * Dmitry Cherkasov
>
>> I am determining technical requirements to IPv
I suppose router operating as proxy ND (similarly to local proxy ARP
in IPv4) can mitigate the threat as well. it is mentioned in 'DOCSIS
3.0 Requirements for IPv6 support'
(http://tools.ietf.org/html/draft-mule-cablelabs-docsis3-ipv6-00).
Dmitry Cherkasov
2011/11/29 Jonathan Lassoff :
> On M
* Dmitry Cherkasov
> I am determining technical requirements to IPv6 provisioning system
> for DOCSIS networks and I am deciding if it is worth to restrict user
> to use not less then /64 networks on cable interface. It is obvious
> that no true economy of IP addresses can be achieved with increas
Steven,
SLAAC is prohibited for using in DOCSIS networks, router
advertisements that allow SLAAC must be ignored by end-devices,
therefore DHCPv6 is the only way of configuring (if not talking about
statical assignment). I have seen at least Windows7 handling this
properly in its default configura
John,
I am determining technical requirements to IPv6 provisioning system
for DOCSIS networks and I am deciding if it is worth to restrict user
to use not less then /64 networks on cable interface. It is obvious
that no true economy of IP addresses can be achieved with increasing
prefix length abo
Owen,
Currently I research on IPv6 provisioning systems and I need to decide
whether the ability to use longer then /64 prefixes should be
supported in them or not. If we restrict user to using /64 per network
we need to have convincing reasons for this. Best practice and common
sense stand for us
On Tue, Nov 29, 2011 at 1:43 AM, wrote:
> It's worked for us since 1997. We've had bigger problems with IPv4 worms
That's not a reason to deny that the problem exists. It's even
fixable. I'd prefer that vendors fixed it *before* there were massive
botnet armies with IPv6 connectivity, but in
* Dmitry Cherkasov:
> It is commonly agreed that /64 is maximal length for LANs because if
> we use longer prefix we introduce conflict with stateless address
> autoconfiguration (SLAAC) based on EUI-64 spec. But SLAAC is not used
> in DOCSIS networks. So there seems to be no objections to use sm
38 matches
Mail list logo
