Re: Level 3 Communications Issues Statement Concerning Comcast's Actions

On Mon, Nov 29, 2010 at 11:20 PM, Leo Bicknell wrote: > I will be the first to advocate the government use minimal to no > regulation where there is active competition and consumer choice, > and thus folks can "vote with their dollars". > > Broadband in the US is not in that boat.  Too many consum

TWT - Comcast congestion

On Tue, Nov 30, 2010 at 9:12 PM, Richard A Steenbergen wrote: > uncongested access. This is the kind of action that virtually BEGS for > government involvement, which will probably end badly for all networks. This depends on the eventual regulatory mechanism and the goals it intends to promote.

Re: The scale of streaming video on the Internet.

On Thu, Dec 2, 2010 at 3:38 PM, Seth Mattinen wrote: > On 12/2/10 12:28 PM, Owen DeLong wrote: >> You are assuming the absence of any of the following optimizations: >> >> 1.    Multicast > > Multicast is great for simulating old school broadcasting, but I don't > see how it can apply to Netflix/A

Start accepting longer prefixes as IPv4 depletes?

How many networks already leak numerous unnecessary /24s to their transit providers, who accept them (not having been asked to do anything else), and contribute to table bloat?  Quite a lot of networks do this. Imagine if there are many possible inter-domain routes that are being filtered by trans

Videotron contact

Could someone from Videotron contact me off-list? -- Jeff S Wheeler Sr Network Operator  /  Innovative Network Concepts

peering, derivatives, and big brother

A read through this New York Times article on derivatives clearing, and the exclusivity that big banks seek to maintain, would look very much like an article on large-scale peering, to someone who is not expert in both topics. The transit-free club and the "derivatives dealers club" may have other

Re: peering, derivatives, and big brother

Invisible Hand Networks was really meant to be a spot market. The same problem exists with bandwidth spot markets that always has existed, the cost of ports to maintain sufficient capacity to the exchange, and the lack of critical mass, meaning that the spot bandwidth is either pretty expensive, o

Re: Some truth about Comcast - WikiLeaks style

On Wed, Dec 15, 2010 at 5:47 PM, Adam Rothschild wrote: > I don't see how this point, however valid, should factor into the > discussion.  Missing from this thread is that Comcast's topology and > economics for hauling bits between a neutral collocation facility and > broadband subscriber are the

Re: Some truth about Comcast - WikiLeaks style

On Thu, Dec 16, 2010 at 12:15 PM, Dave Temkin wrote: > I disagree.  Even at $1/Mbit and 6Tbit of traffic (they do more), that's > still $72M/year in revenue that they weren't recognizing before.  Given that > that traffic was actually *costing* them money to absorb before, turning the > balance an

Re: Some truth about Comcast - WikiLeaks style

On Thu, Dec 16, 2010 at 1:53 PM, Dave Temkin wrote: > I do.  And yes, they are happy to "fuck with a billion dollar a month > revenue stream" (that happens to be low margin) in order to set a precedent > so that when traffic is 60Tbit instead of 6Tbit, across the *same* customer We disagree on th

Re: Alacarte Cable and Geeks

On Fri, Dec 17, 2010 at 12:26 AM, Jay Ashworth wrote: > the 80s when that practice got started -- having to account for each > individual subscriber pushed the complexity up, in much the same way > that flat rate telecom services are popular equally because customers > prefer them, and because the

Re: "potential new and different architectural approach" to solve the Comcast - L3 dispute

On Fri, Dec 17, 2010 at 12:15 PM, Benson Schliesser wrote: > I have no direct knowledge of the situation, but my guess:  I suspect the > proposal was along the lines of longest-path / best-exit routing by Level(3). >  In other words, if L(3) carries the traffic (most of the way) to the > custom

Re: "potential new and different architectural approach" to solve the Comcast - L3 dispute

On Fri, Dec 17, 2010 at 12:48 PM, Richard A Steenbergen wrote: > advertising MEDs, or by sending inconsistent routes. The fact that the > existing Level3/Comcast routing DOESN'T make Level 3 haul all of the > bits to the best exit mean it's highly likely that Comcast agreeing to > haul the bits wa

Re: Some truth about Comcast - WikiLeaks style

On Sun, Dec 19, 2010 at 8:48 PM, Richard A Steenbergen wrote: > Running a wire to everyone's house is a natural monopoly. It just > doesn't make sense, financially or technically, to try and manage 50 > different companies all trying to install 50 different wires into every > house just to have c

Re: IPv6 BGP table size comparisons

I could not find this information on any Wikis, but this is the sort of thing that would be nice to be able to find out without posting on the list or asking around (obviously.) I have quickly made a couple of entries with simple enough formatting that anyone can go onto Wikipedia, click Edit, and

Re: IPv6 BGP table size comparisons

On Wed, Dec 22, 2010 at 2:24 AM, Pekka Savola wrote: > 'Maximum Prefix Length' may be an over-simplifying metric. FWIW, we're > certainly not a major transit provider, but we do allow /48 in the > designated PI ranges but not in the PA ranges.  So the question is not > necessarily just about the p

Re: NIST IPv6 document

On Tue, Jan 4, 2011 at 11:35 PM, Kevin Oberman wrote: > The PDF is available at: I notice that this document, in its nearly 200 pages, makes only casual mention of ARP/NDP table overflow attacks, which may be among the first real DoS challenges production IPv6 networks, and equipment vendors, hav

Re: NIST IPv6 document

On Wed, Jan 5, 2011 at 3:31 AM, Mohacsi Janos wrote: >        Do you have some methods in your mind to resolve ARP/ND overflow > problem? I think limiting mac address per port on switches both efficient on > IPv4 and IPv6. Equivalent of DHCP snooping and Dynamic ARP Inspection should > be implemen

Re: NIST IPv6 document

On Wed, Jan 5, 2011 at 9:39 AM, Iljitsch van Beijnum wrote: >> that a lot of smart people agree is a serious design flaw in any IPv6 >> network where /64 LANs are used > > It's not a design flaw, it's an implementation flaw. The same one that's in > ARP (or maybe RFC 894 wasn't published on april

Re: AltDB?

On Wed, Jan 5, 2011 at 11:26 AM, Jon Lewis wrote: >> Anyone here use AltDB? It seems their servers have been down for two days. > Can anyone from Level3 say how this will impact customer BGP filters. Will > L3 keep working with the last data sync they got from altdb?  I'm guessing Since Level3 up

Re: NIST IPv6 document

On Wed, Jan 5, 2011 at 12:04 PM, Joel Jaeggli wrote: > no it isn't, if you've ever had your juniper router become unavailable > because the arp policer caused it to start ignoring updates, or seen > systems become unavailable due to an arp storm you'd know that you can > abuse arp on a rather smal

Re: NIST IPv6 document

On Wed, Jan 5, 2011 at 12:26 PM, Phil Regnauld wrote: > Jeff Wheeler (jsw) writes: >> Not good, but also does not affect any other interfaces on the router. >        You're assuming that all routing devices have per-interface ARP tables. No, Phil, I am assuming that the rou

Re: NIST IPv6 document

On Wed, Jan 5, 2011 at 1:02 PM, TJ wrote: > Many would argue that the version of IP is irrelevant, if you are permitting > external hosts the ability to scan your internal network in an unrestricted > fashion (no stateful filtering or rate limiting) you have already lost, you How do you propose t

Re: NIST IPv6 document

On Wed, Jan 5, 2011 at 8:57 PM, Joe Greco wrote: >> > This is a much smaller issue with IPv4 ARP, because routers generally >> > have very generous hardware ARP tables in comparison to the typical >> > size of an IPv4 subnet. >> >> no it isn't, if you've ever had your juniper router become unavail

NIST IPv6 document

On Thu, Jan 6, 2011 at 12:17 AM, Joe Greco wrote: > However, that's not the only potential use!  A client that initiates > each new outbound connection from a different IP address is doing > something Really Good. No, Joe, it is not doing anything Good.  This would require the software being writ

Re: NIST IPv6 document

On Thu, Jan 6, 2011 at 12:54 AM, Joe Greco wrote: > I'm starting off with the assumption that knowledge of the host > address *might* be something of value.  If it isn't, no harm done. > If it is, and the address becomes virtually impossible to find, then > we've just defeated an attack, and it's

Re: NIST IPv6 document

On Thu, Jan 6, 2011 at 2:42 AM, Joel Jaeggli wrote: > icmp6 rate limiting both reciept and origination is not rocket science. > The attack that's being described wasn't exactly dreamed up last week, > is as observed not unique to ipv6, and can be mitigated. That does not solve the problem. Your

Re: NIST IPv6 document

On Thu, Jan 6, 2011 at 4:32 AM, Joel Jaeggli wrote: > Which at a minimum is why you want to police the number of nd messages > that the device sends and unreachable entries do not simply fill up the > nd cache, such that new mappings in fact can be learned because there Your solution is to break

Re: NIST IPv6 document

On Thu, Jan 6, 2011 at 7:34 AM, Robert E. Seastrom wrote: > I continue to believe that the "allocate the /64, configure the /127 > as a workaround for the router vendors' unevolved designs" approach, As a point of information, I notice that Level3 has deployed without doing this, e.g. they have d

Re: IPv6 - real vs theoretical problems

On Thu, Jan 6, 2011 at 5:00 PM, Deepak Jain wrote: > As far as I can tell, this "crippling" of the address space is completely > reversible, it's a reasonable step forward and the only "operational" loss is > you can't do all the address jumping and obfuscation people like to talk > about... wh

Re: NIST IPv6 document

On Thu, Jan 6, 2011 at 6:46 PM, Owen DeLong wrote: > On Jan 5, 2011, at 9:17 PM, Joe Greco wrote: >> However, that's not the only potential use!  A client that initiates >> each new outbound connection from a different IP address is doing >> something Really Good. > If hosts start cycling their ad

Re: IPv6 - real vs theoretical problems

On Thu, Jan 6, 2011 at 8:04 PM, Jimmy Hess wrote: > It is advisable to look for much stronger reasons than "With > IPv4 we did it"  or   With IPv4 we ran into such and such > problem"   due to unique characteristics of IPv4 addressing > or other IPv4 conventions that had to continue to exist for >

Re: NIST IPv6 document

On Thu, Jan 6, 2011 at 8:47 PM, Owen DeLong wrote: > 1.      Block packets destined for your point-to-point links at your >        borders. There's no legitimate reason someone should be Most networks do not do this today. Whether or not that is wise is questionable, but I don't think those netw

Re: NIST IPv6 document

On Thu, Jan 6, 2011 at 9:31 PM, Owen DeLong wrote: >> You must understand that policing will not stop the NDCache from >> becoming full almost instantly under an attack.  Since the largest >> existing routers have about 100k entries at most, an attack can fill >> that up in *one second.* >> > If t

Re: NIST IPv6 document

On Thu, Jan 6, 2011 at 9:24 PM, Joe Greco wrote: > With today's implementations of things?  Perhaps.  However, you > show yourself equally incapable of grasping the real problem by > looking at the broader picture, and recognizing that problematic > issues such as finding hosts on a network are ve

Re: AltDB?

On Sat, Jan 8, 2011 at 2:47 PM, Christopher Morrow wrote: > I don't think rr.arin.net and RPKI have anything to do with each > other. I think the direction the RPKI should/is taking is to have the I at least think that whatever future and time-table is planned for RPKI, this should not stand in t

Re: AltDB?

On Sat, Jan 8, 2011 at 10:23 PM, Randy Bush wrote: > but, unlike the other regions, the arin.irr is not confuddled with the > arin.whois.  i.e. it is kind of irrelevant to the authority on resource > ownership, arin's real responsibility. I certainly agree with this, and I am admittedly ignorant

Re: AltDB?

On Sun, Jan 9, 2011 at 1:09 PM, John Curran wrote: >  Please suggest your preferred means of IRR authentication to the ARIN >  suggestion process: >  Alternatively, point to a best practice document from the operator >  community for what should b

Re: AltDB? (IRR support & direction at ARIN)

On Sun, Jan 9, 2011 at 6:27 PM, Randy Bush wrote: >>   Do you: 1) want IRR services, and if so, with what features? >>           2) believe IRR services should be provided by ARIN? > > the irr is slightly useful today.  so, iff it is cheap and easy, arin > providing an open and free instance is a

Re: AltDB? (IRR support & direction at ARIN)

On Sun, Jan 9, 2011 at 6:48 PM, Randy Bush wrote: > jeff, i do not disagree that running an irr instance with only mail-from > is s 1980s.  and, as mans points out, there is free software out > there to do it (i recommend irrd).  but i do not see good cause for arin > to spend anything non-tri

Re: AltDB?

On Sun, Jan 9, 2011 at 7:33 PM, John Curran wrote: > My reason for responding is simply to make sure that ARIN is doing > what the community wants.  I won't deny that this may take some time > depending on exactly what is involved, but in my mind that is far > better than not fixing the situation.

Re: AltDB?

On Sun, Jan 9, 2011 at 10:47 PM, John Curran wrote: > Jeff - ARIN does indeed have folks who worry about whether the policy > development process is being followed.  We also have folks who actually > implement the policy and issue number resources. And we all agree that this is ARIN's primary rol

Re: AltDB? (IRR support & direction at ARIN)

On Sun, Jan 9, 2011 at 11:00 PM, Charles N Wyble wrote: > So why hasn't this happened already? If it's so easy, then all the > normal actors that like to cause us late nights would have struck already. As most of us in the net ops community know, there are many vulnerabilities that are very much

Re: AltDB? (IRR support & direction at ARIN)

On Mon, Jan 10, 2011 at 12:37 PM, Jon Lewis wrote: > On Sun, 9 Jan 2011, Charles N Wyble wrote: > >>> I am simply suggesting it is dangerous and irresponsible to run an IRR >>> with only MAIL-FROM authentication, and quite easy to also support >>> CRYPT-PW.  ARIN should either support passwords or

Re: IPv6 prefix lengths

Richard's employer is exactly the kind of organization that has not been able to effectively multi-home their discrete branch-offices on the IPv4 Internet, because RIR allocation policy set the bar for receiving IPv4 addresses for those small locations just high enough to steer us away from that "f

Re: ARIN IRR Authentication (was: Re: AltDB?)

On Thu, Jan 27, 2011 at 10:00 PM, John Curran wrote: > Based on the ARIN's IRR authentication thread a couple of weeks ago, there > were suggestions placed into ARIN's ACSP process for changes to ARIN's IRR > system. ARIN has looked at the integration issues involved and has scheduled > an upgrade

Re: Level 3's IRR Database

On Sun, Jan 30, 2011 at 3:23 AM, Andrew Alston wrote: > I've just noticed that Level 3 is allowing people to register space in its > IRR database that A.) is not assigned to the people registering it and B.) is > not assigned via/to Level 3. This is not unique to Level3 -- it is the industry st

Re: [arin-announce] ARIN Resource Certification Update

On Sun, Jan 30, 2011 at 12:40 PM, Owen DeLong wrote: > Because they publish data you have signed. They don't have the ability > to modify the data and then sign that modification as if they were you if > they aren't holding the private key. If they are holding the private key, > then, you have, in

Re: IPv6 Address allocation best practises for sites.

On Mon, Sep 24, 2012 at 6:52 PM, John Mitchell wrote: > Does the best practise switch to now using one IPv6 per site, or still the > same one IPv6 for multi-sites? Certainly it would be nice to have IPv6 address per vhost. In many cases, this will be practical. It also sometimes will NOT be pra

Re: Flood affecting US east coast communication facilities?

On Tue, Oct 30, 2012 at 3:46 AM, Kauto Huopio wrote: > Any reports on damage to communications facilities on US east coast? Yes. The outages list is a better place to look for this information. https://puck.nether.net/pipermail/outages/2012-October/date.html -- Jeff S Wheeler Sr Network Oper

Re: Looking for recommendation on 10G Ethernet switch

On Fri, Nov 2, 2012 at 11:13 AM, Eric Germann wrote: > I'm looking for a recommendation on a smallish 10G Ethernet switch for a > small virtualization/SAN implementation (4-5 hosts, 2 SAN boxes) over > iSCSI with some legacy boxes on GigE. > 1Gbps. Assessing whether it is better to go 10G now v

OpenBGPd problems relating to misuse of RESERVED bits in BGP Attribute Flags field

I had two downstream BGP customers experience problem with an OpenBGPd bug tonight. Before diving into detail, I would like to link this mailing list thread, because this is not a new issue and a patch is available: http://www.mail-archive.com/misc@openbsd.org/msg115071.html For the following DFZ

Re: 32-bit ASes at routeviews

On Mon, Dec 17, 2012 at 6:14 AM, Claudio Jeker wrote: > This can happen when a old 2-byte only routers are doing prepends with the > neighbor address (4-byte). Then the magic in the 4-byte AS RFC to fix up > ASPATH has no chance to work and you will see 23456. After a careful re-read of RFC4893 s

Re: Cloudflare is down

On Mon, Mar 4, 2013 at 9:51 AM, Leo Bicknell wrote: > will fix the problem. It won't. Next time the issue will be > different, and the same undertrained person who missed the packet > size this time will miss the next issue as well. They should all be > sitting around saying, "how can we hire c

Re: Verisign deep-hacked. For months.

On Thu, Feb 2, 2012 at 7:26 PM, Suresh Ramasubramanian wrote: > So what part of VRSN got broken into?  They do a lot more than just DNS. Indeed, VeriSign owns Illuminet, who are mission-critical for POTS. Illuminet is also in the business of recording telephone calls, SMS messages, etc. for law e

Re: UDP port 80 DDoS attack

On Sun, Feb 5, 2012 at 10:08 PM, Steve Bertrand wrote: > This is so very easily automated. Even if you don't actually want to trigger > the routes automatically, finding the sources you want to blackhole is as What transit providers are doing flow-spec, or otherwise, to allow their downstreams to

Re: UDP port 80 DDoS attack

On Mon, Feb 6, 2012 at 8:43 PM, Sven Olaf Kamphuis wrote: > there is a fix for it, it's called "putting a fuckton of ram in -most- > routers on the internet" and keeping statistics for each destination > ip:destination port:outgoing interface so that none of them individually can > (entirely/proce

Re: Common operational misconceptions

On Wed, Feb 15, 2012 at 3:47 PM, John Kristoff wrote: > I have a handful of common misconceptions that I'd put on a top 10 list, By your classful addressing example, it sounds like these students are what most nanog posters would consider to be entry-level. RFC1918 is misused a lot by entry-leve

common time-management mistake: rack & stack

Randy's P-Touch thread brings up an issue I think is worth some discussion. I have noticed that a lot of very well-paid, sometimes well-qualified, networking folks spend some of their time on "rack & stack" tasks, which I feel is a very unwise use of time and talent. Imagine if the CFO of a bank

Re: common time-management mistake: rack & stack

On Fri, Feb 17, 2012 at 3:34 AM, Nathan Eisenberg wrote: > No, your CTO shouldn't  be racking and stacking routers all the time.  The > fundamental concept of an organizational hierarchy dictates that.  But a CTO > who has lost touch with the challenges inherent in racking and stacking a > rout

Re: L3 VPN Management

On Wed, Mar 7, 2012 at 2:07 AM, Leigh Porter wrote: > What's the nicest way of allowing the ops servers all talk to each VPN > instance? At the moment I just us pretty normal L3VPN techniques so that > every VPN sees routes tagged with the ops VPN target community and so that > the ops VPN sees

filtering /48 is going to be necessary

On Fri, Mar 9, 2012 at 3:23 AM, Mehmet Akcin wrote: > if you know anyone who is filtering /48 , you can start telling them to STOP > doing so as a good citizen of internet6. I had a bit of off-list discussion about this topic, and I was not going to bring it up today on-list, but since the other

Re: POTS Ending (Re: Operation Ghost Click)

On Wed, May 2, 2012 at 11:29 PM, Jared Mauch wrote: > http://www.usatoday.com/news/nation/story/2012-04-16/landline-service-becoming-obsolete/54321184/1 Indiana is doing away with its requirement that the incumbent LECs supply voice service to rural areas. Indiana also used to require a telephon

Re: Bell Canada outage?

On Wed, Aug 8, 2012 at 2:35 PM, Chris Stone wrote: > Outages mailing list is reporting that Tata is having problems in Montreal > affecting 'many routers'...maybe this is related? I am a transit customer of both TATA and Bell Canada. We saw route churn and heavy packet loss via both Bell and

Re: Bell Canada outage?

We have been advised that TATA/6453 is back to normal, and re-activated our BGP to them. Everything seems okay on this front. No update from Bell Canada yet. On Wed, Aug 8, 2012 at 4:11 PM, Harald Koch wrote: > On 8 August 2012 16:10, Zachary McGibbon >> Thanks for the info, looks like Bell nee

Re: IPv6 end user addressing

On Sat, Aug 6, 2011 at 5:21 AM, Owen DeLong wrote: >> At least don't make your life miserable by experimenting with too many >> different assignment sizes, >> or advocate /64s or something, that's considered a design fault which will >> come back to you some day. >> Read the RfCs and RIR policy

Re: IPv6 end user addressing

On Sat, Aug 6, 2011 at 12:36 PM, Owen DeLong wrote: > On Aug 6, 2011, at 3:15 AM, Jeff Wheeler wrote: >> Note that in this thread, you advocate three things that are a little >> tough to make work together: >> * hierarchical addressing plan / routing >> * nib

Re: IPv6 end user addressing

On Sat, Aug 6, 2011 at 7:26 PM, Owen DeLong wrote: >> Well, you aren't actually doing this on your network today.  If you >> practiced what you are preaching, you would not be carrying aggregate >> routes to your tunnel broker gateways across your whole backbone. > > Yes we would. No, if you actu

Re: IPv6 end user addressing

On Sun, Aug 7, 2011 at 6:58 PM, Mark Andrews wrote: > So you want HE to force all their clients to renumber. No. I am simply pointing out that Owen exaggerated when he stated that he implements the following three practices together on his own networks: * hierarchical addressing * nibble-aligned

Re: IPv6 end user addressing

On Wed, Aug 10, 2011 at 6:55 AM, Alexander Harrowell wrote: > Thinking about the CPE thread, isn't this a case for bridging as a > feature in end-user devices? If Joe's media-centre box etc would bridge > its downstream ports to the upstream port, the devices on them could > just get an address, w

Re: IPv6 end user addressing

On Wed, Aug 10, 2011 at 2:03 PM, Owen DeLong wrote: > That said, /48 to the home should be what is happening, and /56 is > a better compromise than anything smaller. Is hierarchical routing within the SOHO network the reason you believe /48 is useful? You don't really imagine that end-users will

Re: IPv6 end user addressing

On Wed, Aug 10, 2011 at 7:12 PM, Owen DeLong wrote: >> Is it true that there is no existing work on this?  If that is the >> case, why would we not try to steer any such future work in such a way >> that it can manage to do what the end-user wants without requiring a >> /48 in their home? > > No,

Re: IPv6 end user addressing

On Wed, Aug 10, 2011 at 8:40 PM, Mark Andrews wrote: > No.  A typical user has 10 to 20 addresses NAT'd to one public address. I'd say this is fair. Amazingly enough, it all basically works right with one IP address today. It will certainly be nice to have the option to give all these devices p

Re: OSPF vs IS-IS

I thought I'd chime in from my perspective, being the head router jockey for a bunch of relatively small networks. I still find that many routers have support for OSPF but not IS-IS. That, plus the fact that most of these networks were based on OSPF before I took charge of them, in the absence of

Deploying IPv6 Responsibly

On Fri, Aug 19, 2011 at 12:59 PM, Frank Bulk wrote: > I just noticed that the quad-A records for both those two hosts are now > gone.  DNS being what it is, I'm not sure when that happened, but our > monitoring system couldn't get the for www.qwest.com about half an hour > ago. > > Hopefully

Re: iCloud - Is it going to hurt access providers?

On Sun, Sep 4, 2011 at 4:45 PM, Wayne E Bouchard wrote: > Okay, so to state the obvious for those who missed the point... > > The congestion will either be directly in front of user because > they're flooding their uplink or towards the destination (beit a > single central network or a set of stor

Re: BGP conf

On Tue, Nov 1, 2011 at 9:01 PM, Edward avanti wrote: > many example seem > insecure no prefix list so on. ... > I am not ignorant with cisco 7201, but am total newby to BGP. Your concern about a lack of any prefix-lists in the documentation / examples you have read is justified. If you are conne

Re: BGP conf

On Wed, Nov 2, 2011 at 7:50 PM, Edward avanti wrote: > sorry, my english not so perfect, at no time I mean send to IX what Verizon > send me, I'm not THAT stupid hehe > I mean if destination/origin is via IX, then send THAT traffic only by IX > and not Verizon. I understood what you mean. The re

Re: BGP conf

On Wed, Nov 2, 2011 at 8:44 PM, Jack Bates wrote: > Now I have the mile long monstrosity that uses BGP communities for > everything, and of route-maps/policies with prefix-lists for downstream > customers. You have to start somewhere. > > cymru secure bgp templates is probably a good beginning. I

Re: BGP conf

On Wed, Nov 2, 2011 at 10:04 PM, Jack Bates wrote: > Have to read the current cymru bgp templates? > > ! manner. Why not consider peering with our globally distributed bogon > ! route-server project? Alternately you can obtain a current and well I'm not telling you something you don't already kno

Re: Anyone seen this kind of problem? SIP traffic not getting to destination but traceroute does

On Wed, Nov 9, 2011 at 1:47 PM, Jay Nakamura wrote: > So my questions is, is it possible there is some kind of filter at > Qwest or Level 3 that is dropping traffic only for udp 5060 for select > few IPs?  That's the only explanation I can come up with other than I ran into exactly this problem l

Re: IPv6 prefixes longer then /64: are they possible in DOCSIS networks?

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 against buggy *ware), > and there can be some advantages t

Re: IPv6 prefixes longer then /64: are they possible in DOCSIS networks?

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

Re: IPv6 prefixes longer then /64: are they possible in DOCSIS networks?

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

Re: IPv6 prefixes longer then /64: are they possible in DOCSIS networks?

On Wed, Nov 30, 2011 at 9:48 AM, Ray Soucy wrote: > 1. Using a stateful firewall (not an ACL) outside the router > responsible for the 64-bit prefix.  This doesn't scale, and is not a > design many would find acceptable (it has almost all the problems of > an ISP running NAT) Owen has suggested "

Re: IPv6 prefixes longer then /64: are they possible in DOCSIS networks?

On Wed, Nov 30, 2011 at 3:13 PM, Owen DeLong wrote: > As such, I prefer to deploy IPv6 as it is today and resolve the bugs > and the security issues along the way (much like we did with IPv4). Why is the Hurricane Electric backbone using /126 link-nets, not /64? You used to regularly claim there

Re: Link local for P-t-P links? (Was: IPv6 prefixes longer then /64: are they possible in DOCSIS networks?)

On Wed, Nov 30, 2011 at 9:15 PM, Mike Jones wrote: > Link-Local? > > For "true" P-t-P links I guess you don't need any addresses on the Point-to-point links in your backbone are by far the easiest thing to defend against this attack. I wish we would steer the discussion away from point-to-point

Re: IPv6 prefixes longer then /64: are they possible in DOCSIS networks?

On Thu, Dec 1, 2011 at 9:42 AM, Chuck Anderson wrote: > Jumping in here, how about static ND entries?  Then you can use the > /64 for P-t-P, but set the few static ND entries you need, and turn > off dynamic ND.  An out-of-band provisioning system could add static > ND entries as needed. > > Anoth

Re: Writable SNMP

On Tue, Dec 6, 2011 at 11:07 AM, Keegan Holley wrote: > For a few years now I been wondering why more networks do not use writable > SNMP.  Most automation solutions actually script a login to the various I've spent enough time writing code to deal with SNMP (our own stack, not using Net-SNMP or

Re: De-bogon not possible via arin policy.

On Wed, Dec 14, 2011 at 4:15 PM, Cameron Byrne wrote: > Fyi, I just was rejected from arin for an ipv4 allocation. I demonstrated I > own ~100k ipv4 addresses today. > > My customers use over 10 million bogon / squat space ip addresses today, > and I have good attested data on that. Cameron, I h

Re: local_preference for transit traffic?

On Thu, Dec 15, 2011 at 1:07 AM, Keegan Holley wrote: > Had in interesting conversation with a transit AS on behalf of a customer > where I found out they are using communities to raise the local preference That sounds like a disreputable practice. While not quite as obvious, some large transit

Re: local_preference for transit traffic?

On Thu, Dec 15, 2011 at 2:24 AM, Keegan Holley wrote: > I always assumed that taking in more traffic was a bad thing.  I've heard > about one sided peering agreements where one side is sending more traffic > than the other needs them to transport. Am I missing something?  Would this > cause a shif

Re: De-bogon not possible via arin policy.

On Thu, Dec 15, 2011 at 4:54 PM, Joel jaeggli wrote: > We know rather alot about the original posters' business, it has ~34 > million wireless subscribers in north america. I think it's safe to > assume that adequate docuementation could be provided. I missed the post where he supplied this infor

Re: IPv6 RA vs DHCPv6 - The chosen one?

On Fri, Dec 23, 2011 at 4:13 PM, Mohacsi Janos wrote: > If you can limit number of ARP/NDP entries per interfaces and you complement > RAGuard and DHCPv4 snooping your are done. That depends on how ARP/ND gleaning works on the box. In short, Cisco already has a knob to limit the number of ND ent

Re: subnet prefix length > 64 breaks IPv6?

On Wed, Dec 28, 2011 at 10:19 AM, Ray Soucy wrote: > There are a few solutions that vendors will hopefully look into.  One > being to implement neighbor discovery in hardware (at which point > table exhaustion also becomes a legitimate concern, so the logic > should be such that known associations

Re: subnet prefix length > 64 breaks IPv6?

On Wed, Dec 28, 2011 at 5:07 PM, Ray Soucy wrote: > The suggestion of disabling ND outright is a bit extreme.  We don't > need to disable ARP outright to have functional networks with a > reasonable level of stability and security.  The important thing is I don't think it's at all extreme. If yo

Re: MD5 considered harmful

On Fri, Jan 27, 2012 at 6:35 PM, Keegan Holley wrote: > realizes that it's ok to let gig-e auto-negotiate.  I've never really > seen MD5 cause issues. I have run into plenty of problems caused by MD5-related bugs. 6500/7600 can still figure the MSS incorrectly when using it. It used to be possi

Re: [arin-ppml] NAT444 rumors (was Re: Looking for an IPv6 naysayer...)

On Fri, Feb 18, 2011 at 10:34 AM, Zed Usser wrote: >  Reduce, yes. Remove, no. Without a global cutoff date for the IPv6 > transition, it's not like IPv4 is going to disappear overnight. Furthermore, > without any IPv4/IPv6 translation, the first IPv6 only networks are going to > be awfully lon

Re: [arin-ppml] NAT444 rumors (was Re: Looking for an IPv6naysayer...)

On Fri, Feb 18, 2011 at 1:14 PM, George Bonser wrote: > One thing they can do, and I would live to see some popular destination > site do this, is to say something like: > > "we have this really cool new thing we are rolling out but, sorry, it is > available only via IPv6" or "we will continue sup

Re: Howto for BGP black holing/null routing

On Tue, Feb 22, 2011 at 4:55 PM, Jack Carrozzo wrote: > Maybe I read your question wrong, but null-routing things at your border is > often not very useful if the traffic is flooding your transit links. Most > transits publish their community lists - you just need to tag the prefix you > want to b

  1   2   >