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: Consequences of BGP Peering with Private Addresses

On Wed, Jun 15, 2011 at 12:47 PM, James Grace wrote: > So we're running out of peering space in our /24 and we were considering > using private /30's for new peerings.  Are there any horrific consequences to > picking up this practice? I agree with other posters that this is not a good practice

Re: ICANN to allow commercial gTLDs

On Sat, Jun 18, 2011 at 12:04 AM, George B. wrote: > I think I will get .payme  and make sure coke.payme, pepsi.payme, > comcast.payme, etc. all get registered at the low-low price of > $10/year.  All I would need is 100,000 registrations to provide me > with a million dollar a year income stream

Re: Wacky Weekend: NERC to relax power grid frequency strictures

On Sun, Jun 26, 2011 at 12:23 AM, Alex Rubenstein wrote: > At least here in JCPL territory (northern NJ), closed transition is frowned > upon. Too much risk, they think. They are correct, really, but the risk is > mostly yours. If you lock to the utility out-of-phase, you will surely lose > and

Re: Why is IPv6 broken?

On Sat, Jul 9, 2011 at 5:25 PM, Bob Network wrote: > Why is IPv6 broken? You should have titled your thread, "my own personal rant about Hurricane Electric's IPv6 strategy." You may also have left out the dodgy explanation of peering policies and technicalities, since these issues have been rema

Re: Anybody can participate in the IETF (Was: Why is IPv6 broken?)

On Sun, Jul 10, 2011 at 3:45 PM, Owen DeLong wrote: > Number two: While anyone can participate, approaching IETF as an > operator requires a rather thick skin, or, at least it did the last couple > of times I attempted to participate. I've watched a few times where I am subscribed to the IDR (BGP

Re: Why is IPv6 broken?

On Mon, Jul 11, 2011 at 3:25 AM, Tom Hill wrote: > On Sun, 2011-07-10 at 10:14 -0400, Jeff Wheeler wrote: >> Cogent's policy of requiring a new contract, and from what I am still >> being told by some European customers, new money, from customers in >> exchange for pro

Re: Anybody can participate in the IETF (Was: Why is IPv6 broken?)

On Mon, Jul 11, 2011 at 3:18 PM, William Herrin wrote: > On the other hand, calling out ops issues in RFCs is a modest reform > that at worst shouldn't hurt anything. That beats my next best idea: I think if this were done, some guy like me would spend endless hours arguing with others about what

Re: Anybody can participate in the IETF (Was: Why is IPv6 broken?)

On Mon, Jul 11, 2011 at 3:35 PM, Leo Bicknell wrote: > The IETF does not want operators in many steps of the process.  If > you try to bring up operational concerns in early protocol development > for example you'll often get a "we'll look at that later" response, > which in many cases is right.  

Re: Anybody can participate in the IETF (Was: Why is IPv6 broken?)

On Mon, Jul 11, 2011 at 5:12 PM, Owen DeLong wrote: > No... I like SLAAC and find it useful in a number of places. What's wrong > with /64? Yes, we need better DOS protection in switches and routers See my slides http://inconcepts.biz/~jsw/IPv6_NDP_Exhaustion.pdf for why no vendor's implementatio

Re: Anybody can participate in the IETF (Was: Why is IPv6 broken?)

On Mon, Jul 11, 2011 at 7:48 PM, Jimmy Hess wrote: > If every vendor's implementation is vulnerable to a NDP Exhaustion > vulnerability, > how come the behavior of specific routers has not been documented > specifically? Well, I am in the business of knowing the behavior of kit being considered

Re: Anybody can participate in the IETF (Was: Why is IPv6 broken?)

On Tue, Jul 12, 2011 at 11:42 AM, Leo Bicknell wrote: > I'll pick on LISP as an example, since many operators are at least > aware of it.  Some operators have said we need a locator and identifier > split.  Interesting feedback.  The IETF has gone off and started > playing in the sandbox, trying t

Re: in defense of lisp (was: Anybody can participate in the IETF)

On Wed, Jul 13, 2011 at 2:27 AM, Randy Bush wrote: >> I fear that at its worst and most successful, LISP ensures ipv4 is the >> backbone transport media to the detriment of ipv6 and at its best, it >> is a distraction for folks that need to be making ipv6 work, for real. > > i suspect that a numbe

Re: Anybody can participate in the IETF (Was: Why is IPv6 broken?)

Luigi, you have mis-understood quite a bit of the content of my message. I'm not sure if this is of any further interest to NANOG readers, but as it is basically what seems to go on a lot, from my observations of IETF list activity, I'll copy my reply to the list as you have done. On Wed, Jul 13,

Re: NDP DoS attack (was Re: Anybody can participate in the IETF (Was: Why is IPv6 broken?))

On Sun, Jul 17, 2011 at 11:42 AM, William Herrin wrote: > My off-the-cuff naive solution to this problem would be to discard the > oldest incomplete solicitation to fit the new one and, upon receiving > an apparently unsolicited response to a discarded solicitation, > restart the process flagging

Re: Anybody can participate in the IETF (Was: Why is IPv6 broken?)

On Sun, Jul 17, 2011 at 11:07 AM, Eliot Lear wrote: > We all make mistakes in not questioning our own positions, from time to > time.  You, Jeff, seem to be making that very same mistake. > Rome wasn't built in a day.  The current system didn't come ready-made > pre-built with all the bells and w

Re: NDP DoS attack (was Re: Anybody can participate in the IETF (Was: Why is IPv6 broken?))

On Sun, Jul 17, 2011 at 3:40 PM, Owen DeLong wrote: > Basically an ND entry would have the following states and timers: I've discussed what you have described with some colleagues in the past. The idea has merit and I would certainly not complain if vendors included it (as a knob) on their boxes

Re: [lisp] Anybody can participate in the IETF (Was: Why is IPv6 broken?)

On Mon, Jul 18, 2011 at 12:15 PM, Noel Chiappa wrote: > Let me make sure I understand your point here. You don't seem to be > disagreeing with the assertion that for most sites (even things like very > large universities, etc), their 'working set' (of nodes they communicate) > with will be much sm

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

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: Mitigating DNS amplification attacks

On Tue, Apr 30, 2013 at 8:35 PM, Jared Mauch wrote: > Please provide advice and insights as well as directing customers to the > openresolverproject.org website. We want to close these down, if you need an > accurate list of IPs in your ASN, please email me and I can give you very > accurate da

NANOG58 parking

I noticed that some folks were unhappy with the parking fee in Orlando. The Roosevelt New Orleans, for NANOG 58, tells me that the only on-site parking is valet for $42/day. Anyone planning to drive or stay at a different hotel may want to consider that in advance. -- Jeff S Wheeler Sr Network

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

  1   2   >