* 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
On Tue, Nov 29, 2011 at 1:43 AM, valdis.kletni...@vt.edu 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
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
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
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
* 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 increasing
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
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 tore.ander...@redpill-linpro.com:
* Dmitry Cherkasov
I am determining
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)
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
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
On Tue, 29 Nov 2011 15:06:15 +0200, Denys Fedoryshchenko
de...@visp.net.lb 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
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,
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 victor.kuarsi...@gmail.com:
Dmitry et al,
I found Jeff's following comments to be quite
On Tue, 29 Nov 2011 03:23:04 EST, Jeff Wheeler said:
On Tue, Nov 29, 2011 at 1:43 AM, valdis.kletni...@vt.edu 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
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 a
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 of
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
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
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:
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.
...
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
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
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,
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 keegan.hol...@sungard.com
To: NANOG nanog@nanog.org
Sent: Tuesday, 29 November, 2011 4:47:37 PM
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 violates
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
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 o...@delong.com wrote:
On Nov 29, 2011, at 4:58 AM, Dmitry Cherkasov wrote:
Thanks to everybody
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 in
We lost several of our GigE links to ATT for 6 hours on 11/19, anyone else see
this and get a root cause from ATT? All I can get is that they believe a
change caused the issue.
On Nov 28, 2011, at 9:15 PM, Jeff Wheeler wrote:
On Mon, Nov 28, 2011 at 4:51 PM, Owen DeLong o...@delong.com 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
On Tue, Nov 29, 2011 at 12:42 AM, Owen DeLong o...@delong.com 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
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 you
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
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::
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 using
On Tue, Nov 29, 2011 at 10:31 PM, Owen DeLong o...@delong.com 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.
Does anyone know a good Bandwidth Prediction tool?.
yes. times 1.5-2.0 every year
38 matches
Mail list logo
