Re: Suggestion on Fiber tester
On Thu, 26 Sep 2013, Blake Pfankuch - Mailing List wrote: (snip) $1000 You might get a JDSU OLP meter for that sort of money... http://www.jdsu.com/en-us/test-and-measurement/products/a-z-product-list/Pages/olp-smart.aspx I've used one of theirs (and a matching source) for buzzing out links at work. Simple enough to use, and can withstand my colleague dropping it off the top of a rack. -- Steven Hill I'm not a goth, I just can't afford the colour license
Re: minimum IPv6 announcement size
sounds just like folks in 1985, talking about IPv4... /bill On Wed, Sep 25, 2013 at 06:45:02AM -0700, Owen DeLong wrote: Each site should get at least a /48. Stop worrying about dense-packing the IP space in IPv6. This is IPv4-think. IPv6 is intended to be sparsely allocated. Owen On Sep 24, 2013, at 8:10 PM, Nathanael C. Cariaga nccari...@stluke.com.ph wrote: Hi, I raised actually this concern during our IP resource application. On a personal note, I think /48 IPv6 allocation is more than enough for our organization to use for at least the next 5-10 years assuming that this can be farmed out to our multiple sites. What makes this complicated for us is that we are operating on a multiple sites (geographically) with each site is doing multi-homing and having a /48 in each site would be very big waste of IP resources. -nathan On 9/25/2013 2:36 AM, Bryan Socha wrote: Everyone is following the same policies. a /48 PER SITE.did you request enough addresses from your RIR? Bryan Socha
Re: minimum IPv6 announcement size
On 2013-09-26 08:52, bmann...@vacation.karoshi.com wrote: sounds just like folks in 1985, talking about IPv4... Yeah, but who doesn't run CIDR now? Get everyone in the IPv6 pool now; we'll inevitably add hacks later
Re: Sudan disconnected from the Internet
On 26/09/2013 03:04, Patrick W. Gilmore wrote: It's not a fiber cut. It did come back for a while at least. https://twitter.com/akamai_soti/status/382872513761398785/photo/1 This is data from RIPEstat / RIPE Atlas: https://labs.ripe.net/Members/emileaben/sudan-internet-disruptions near-realtime stats of visibility of Sudanese prefixes and ASNs: https://stat.ripe.net/SD#tabId=routing Looks like the number of prefixes went up to about normal again the last hour or so. best regards, Emile Aben RIPE NCC
Re: Sudan disconnected from the Internet
On 26/09/2013 12:23, Emile Aben wrote: On 26/09/2013 03:04, Patrick W. Gilmore wrote: It's not a fiber cut. It did come back for a while at least. https://twitter.com/akamai_soti/status/382872513761398785/photo/1 This is data from RIPEstat / RIPE Atlas: https://labs.ripe.net/Members/emileaben/sudan-internet-disruptions near-realtime stats of visibility of Sudanese prefixes and ASNs: https://stat.ripe.net/SD#tabId=routing Looks like the number of prefixes went up to about normal again the last hour or so. You'll need to zoom to actually see this, here's the zoomed view: https://stat.ripe.net/widget/country-routing-stats#w.resource=sdw.zoom_start=1380078150593w.zoom_end=138019170w.comparison=no best regards, Emile Aben RIPE NCC
RE: Sudan disconnected from the Internet
Of course it is entirely possible that it was the rioters simply because they wanted people to notice. And I guess it worked. -Original Message- From: Warren Bailey [mailto:wbai...@satelliteintelligencegroup.com] Sent: Wednesday, 25 September, 2013 18:43 To: Tammy Firefly Cc: nanog@nanog.org Subject: Re: Sudan disconnected from the Internet We make Ku-band backpacks for this type of scenario. I would give it 12- 18 hours before you see CNN light up with live feeds.. I didn't even KNOW this was happening prior to them doing this. Seems like cutting off access would alert a lot more folks than some people wrecking Sudan over fuel subsidies?? Doesn't look like it's been picked up by CNN substantially yet, but I imagine we'll get breaking news soon enough. Would be interesting to see if it was a forced drop or did they actually just take a pair of scissors and murder the internets? On 9/25/13 5:40 PM, Tammy Firefly tammy-li...@wiztech.biz wrote: On 9/25/13 18:38:09, Warren Bailey wrote: http://abcnews.go.com/International/wireStory/sudan-security-clashes- subs id y-protesters-20360418 On 9/25/13 5:34 PM, Tammy Firefly tammy-li...@wiztech.biz wrote: On 9/25/13 18:29:58, Jeff Kell wrote: On 9/25/2013 8:25 PM, Tammy Firefly wrote: with the old fashioned pair of diagonal cutters applied to fiber? Yes, interesting to know if it was cut fiber, pressure on the inside providers (or their feeds), or pressure on the outside providers. Traceroutes lend any clue? Jeff If the government did it, I guarantee it was cut fiber. That makes it difficult to quickly restore. One has to wonder whats going on there right now that they dont want the world to know about? Then its quite likely the government cut the fiber to cover that up :) wouldnt surprise me if they cut it in multiple places as well.
gmail.com contact
Hi list, We had a user account compromised a couple of days ago, spam naturally, and now the IP is blocked for delivering to gmail.com. We've completed the delivery problem form at support.google.com but if there is any way to speed up the process our customer and we would appreciate it. Could anyone put me in touch with a gmail.com contact? Thanks! Markus
Re: gmail.com contact
: -Original Message- From: Markus [mailto:unive...@truemetal.org] Sent: 26 septembre 2013 07:37 To: nanog@nanog.org Subject: gmail.com contact Hi list, We had a user account compromised a couple of days ago, spam naturally, and now the IP is blocked for delivering to gmail.com. We've completed the delivery problem form at support.google.com but if there is any way to speed up the process our customer and we would appreciate it. Could anyone put me in touch with a gmail.com contact? Hi, Good luck. I have been going through the regular channels for over a month, to try and de-list a server that has not sent an email for over a month to Google or anyone for that matter, and no such luck. If you get a hold of somebody, pls forward me contact info. I am trying again this morning, I will do the same for you. Cheers, Chris
Filter-based routing table management (was: Re: minimum IPv6 announcement size)
On Sep 26, 2013, at 4:52 AM, bmann...@vacation.karoshi.com wrote: sounds just like folks in 1985, talking about IPv4... If there were ever were a need for an market/settlement model, it is with respect to routing table slots. As it is, we have no real feedback mechanism in the present system, just conventions that are variably enforced depending on relative stature of the parties having the discussion. Externalizing the true cost of having a prefix routed would create a more equitable and fair environment (i.e. knowledge that you could have any prefix globally routed for a fairly predictable cost, and ability to weigh the benefits of that versus taking a prefix from your ISP.) It might even spur research into various interesting alternatives such routing costs for smaller scopes (regional, geographic, etc.) and cost implications and technical tradeoffs from various alternative mobility schemes. That's not to say that establishing a framework for externalizing routing costs would be easy; it's a complicated and twisted matter, and also fraught with various legal competitive aspects. However, it would at least be doing something more than crossing our fingers and just hoping for the best out of today's IPv6 prefixes for all... Another benefit of such a system (for those fans of market-based approaches) is that we could better utilize IPv4, rather than the currently implied /24 is routable, /25 is not filter-based approach which may not survive the market pressures associated with IPv4 depletion in any case... FYI, /John Disclaimer: My views alone. Feel free to ignore this message as desired.
Re: Suggestion on Fiber tester
* blake.mailingl...@pfankuch.me (Blake Pfankuch - Mailing List) [Thu 26 Sep 2013, 05:28 CEST]: To follow up, all of this fiber is mm and all light is sx to sfp. Currently all 1gbit, but it will be repulled as 10gbit capable soon... I guess I'm going to have to be a little less cheap and shoot for something under $1000. I'm not aware of testers in your price range that will tell you This fiber will/will not work for 10GbE but can second the recommendation for an OTDR, especially if you have metro fibers. If you're repulling (I'm unfamiliar with the word but assume you mean taking out current infrastructure and putting in new fiber through existing ducts), why not go singlemode? That will save you so much headaches with 10G, and SFP optics are only slightly more expensive. -- Niels.
RE: minimum IPv6 announcement size
There are many ways to mediate this. No matter what one is chosen a balance between market, Networks and policy will need to be met. And in the end Networks will do what is best for their network. However if there is a norm of some kind, then at least there will be a target to hover around. Market Networks- Pro- Entities managing the health of their network would be less willing to route what would result in overload. Con- The more financially healthy Entities can afford faster turn over and burn to new routers and circuit upgrades. The upper hand of growth goes to them since overload wouldn't be as much as an internal issue as it would be to other smaller networks. The global scheme gets lost in the eye of the mighty dollar. This is not anything new market pattern wise but Larger/Financially healthy entities would survive better than any smaller provider. Policy Pro- there would be a set standard to target Con- policy is managed by the community and not always supporting every business model equally. Plus policy can become a moving target as we have witnessed with IPv4. List Publishing-Policy Pro- qualified ASN's are approved a range of subnet size of route advertisements and any too specific/smaller advertisements are ignored if not on the list. Con- this is policy. No one tells a network what to do. Set Boundary policy Pro- something exists as a target to help manage the issue Con- policy is very likely to become a moving target. No one tells a network what to do. Keep Head in Sand Pro- Happy Con- Calamity...but when? Or will there be a new option...the next best thing. Hope in one hand and @#$$ in the other. One usually fills up faster. Somehow the community needs to choose one of these paths. My 2 cents Marla -Original Message- From: Patrick [mailto:na...@haller.ws] Sent: Thursday, September 26, 2013 2:23 AM To: bmann...@vacation.karoshi.com Cc: nanog@nanog.org Subject: Re: minimum IPv6 announcement size On 2013-09-26 08:52, bmann...@vacation.karoshi.com wrote: sounds just like folks in 1985, talking about IPv4... Yeah, but who doesn't run CIDR now? Get everyone in the IPv6 pool now; we'll inevitably add hacks later
Re: Suggestion on Fiber tester
Welp. Not my duplicate (Received: headers show it happened inside the nanog mailing list server). Already asked them to investigate. -- Niels.
Re: Filter-based routing table management (was: Re: minimum IPv6 announcement size)
On Thu, Sep 26, 2013 at 11:07 AM, John Curran jcur...@istaff.org wrote: On Sep 26, 2013, at 4:52 AM, bmann...@vacation.karoshi.com wrote: sounds just like folks in 1985, talking about IPv4... If there were ever were a need for an market/settlement model, it is with respect to routing table slots. That's not to say that establishing a framework for externalizing routing costs would be easy; it's a complicated and twisted matter, and also fraught with various legal competitive aspects. Hi John, That's putting it mildly. Establishing such a framework would be an immense challenge. Here are some ideas I've heard: 1. The International Clearinghouse Every BGP participant files with a clearinghouse, specifying: a. How much they charge to carry 1 route b. Whether or not they are a leaf node c. Whether or not they are a transit-free network. Any network which is not transit free must implement a default route which leads to a big transit-free network in order to maintain full connectivity. The BGP participants then publish the exact routes they intend to announce to the clearinghouse and for each one select which networks they'll pay to carry the route. The route must still reach each network via BGP; payment just means that the network won't filter the route out. The clearinghouse then collects payments from everybody and makes payments to everybody, as well as providing each participant a list of the routes that are paid for. Sellers are expected to promptly incorporate new paid routes into their BGP filters. From my research a few years ago, a reasonable rate would be around 3 to 4 cents per year per advertised route per BGP-carrying router in the organization. A couple billion dollars per year if the routing table maintained its current size. 2. The partial routing scenario Large service providers put bids in to the RIRs for the right to announce /8 covering routes for each /8 delegated to the RIR. Each /8 matches exactly one service provider. Smaller BGP system participants make private arrangements with a small (20 to 30) set of networks (including their direct ISPs) to carry their advertised routes through a reasonably redundant number of pathways to (and including) the winning bidder for the /8 they inhabit. For the sake of performance, they may also pay additional large networks to shortcut the traffic towards them rather than let it dump at the /8 advertiser. For the folks you don't pay via the clearinghouse, many end-user systems and the majority of transit systems simply don't carry your route unless yours is among the handful of systems critically important to their customers. Instead, traffic to your network follows the /8 advertisement until it reaches a network which carries your specific route. With the routing costs suitably reduced, settlement for the remaining routes becomes moot. This is usually within a few percent of the routing efficiency that would have been achieved with total route propagation. 3. The routing overlay Establish a semi-stateless tunneling system. Each BGP participant sets up a tunnel ingress node and links a default route to it. Packets for a destination not found in the routing table follow the default route to the tunnel ingress. The tunnel device then looks up an tunnel exit node via a mapping protocol. Both the map server and the exit node have to be hosted on IP addresses reachable via the normal routing table. Having found an exit node, the original packet is encapsulated into a tunnel packet and sent to the exit node. The exit node is in a part of the network that carries an explicit route to the destination. Then, move the definition of threshold size. Except for whitelisted critical infrastructure, /24 advertisements would no longer carry an expectation of universal distribution. To maintain connectivity, folks at the bottom of the chain would need to establish or subscribe to tunnel exit nodes that have a route back to them. With the routing costs suitably reduced, settlement for the remaining routes becomes moot. The IRTF Routing Research Group studied such protocols a few years ago and have pretty well fleshed out how to make one work with all the tangled issues involving path mtu, dead path detection and so on. Multiple designs sit on a shelf waiting for a promise that the technology will be purchased if built. Regards, Bill Herrin -- William D. Herrin her...@dirtside.com b...@herrin.us 3005 Crane Dr. .. Web: http://bill.herrin.us/ Falls Church, VA 22042-3004
Re: Sudan disconnected from the Internet
My recollection is that Renesys classified Sudan as a country vulnerable to disconnection due to low diversification of international transit; the old authoritarian preference on monopolizing the gateways has its advantages. I have been monitoring responsive hosts using ZMap every 15 minutes or so since afternoon. However, it seems probable from the incremental disconnect that this was a legal compliance situation (a fax to the ISP), rather than flipping a switch or cutting a wire? cda.io/r/sudan_1380162900_ICMP.png On Wed, Sep 25, 2013 at 8:43 PM, Warren Bailey wbai...@satelliteintelligencegroup.com wrote: We make Ku-band backpacks for this type of scenario. I would give it 12-18 hours before you see CNN light up with live feeds.. I didn't even KNOW this was happening prior to them doing this. Seems like cutting off access would alert a lot more folks than some people wrecking Sudan over fuel subsidies?? Doesn't look like it's been picked up by CNN substantially yet, but I imagine we'll get breaking news soon enough. Would be interesting to see if it was a forced drop or did they actually just take a pair of scissors and murder the internets? On 9/25/13 5:40 PM, Tammy Firefly tammy-li...@wiztech.biz wrote: On 9/25/13 18:38:09, Warren Bailey wrote: http://abcnews.go.com/International/wireStory/sudan-security-clashes-subs id y-protesters-20360418 On 9/25/13 5:34 PM, Tammy Firefly tammy-li...@wiztech.biz wrote: On 9/25/13 18:29:58, Jeff Kell wrote: On 9/25/2013 8:25 PM, Tammy Firefly wrote: with the old fashioned pair of diagonal cutters applied to fiber? Yes, interesting to know if it was cut fiber, pressure on the inside providers (or their feeds), or pressure on the outside providers. Traceroutes lend any clue? Jeff If the government did it, I guarantee it was cut fiber. That makes it difficult to quickly restore. One has to wonder whats going on there right now that they dont want the world to know about? Then its quite likely the government cut the fiber to cover that up :) wouldnt surprise me if they cut it in multiple places as well. -- *Collin David Anderson* averysmallbird.com | @cda | Washington, D.C.
Radware vs Arbor
Doing a bunch of research, and I can't find a meaningful comparison of these two products. Work for a carrier, and I am looking at implementing a DDoS mitigation service that we can sell to our customers. Radware is cheaper, but I am seeing a lot of noise in various forums that makes me question their viability for what we need. Arbor has most of the market, and I assume there is good reason for it. Both companies seem to be very deceptive about how they compare to the other. Anyone out there with good hands on experience that can compare? Not interested in input from either company, we get plenty of that already. Good experience, or links to good write ups would be excellent... Davis B.
RE: Suggestion on Fiber tester
If you're looking for cheap then go for a RY3200C, it retails for around $140. Kate
RE: Sudan disconnected from the Internet
Or the country as a whole had WAY too many iPhones in need of a 7.0 upgrade. Chuck -Original Message- From: Keith Medcalf [mailto:kmedc...@dessus.com] Sent: Thursday, September 26, 2013 7:23 AM To: nanog@nanog.org Subject: RE: Sudan disconnected from the Internet Of course it is entirely possible that it was the rioters simply because they wanted people to notice. And I guess it worked. -Original Message- From: Warren Bailey [mailto:wbai...@satelliteintelligencegroup.com] Sent: Wednesday, 25 September, 2013 18:43 To: Tammy Firefly Cc: nanog@nanog.org Subject: Re: Sudan disconnected from the Internet We make Ku-band backpacks for this type of scenario. I would give it 12- 18 hours before you see CNN light up with live feeds.. I didn't even KNOW this was happening prior to them doing this. Seems like cutting off access would alert a lot more folks than some people wrecking Sudan over fuel subsidies?? Doesn't look like it's been picked up by CNN substantially yet, but I imagine we'll get breaking news soon enough. Would be interesting to see if it was a forced drop or did they actually just take a pair of scissors and murder the internets? On 9/25/13 5:40 PM, Tammy Firefly tammy-li...@wiztech.biz wrote: On 9/25/13 18:38:09, Warren Bailey wrote: http://abcnews.go.com/International/wireStory/sudan-security-clashes - subs id y-protesters-20360418 On 9/25/13 5:34 PM, Tammy Firefly tammy-li...@wiztech.biz wrote: On 9/25/13 18:29:58, Jeff Kell wrote: On 9/25/2013 8:25 PM, Tammy Firefly wrote: with the old fashioned pair of diagonal cutters applied to fiber? Yes, interesting to know if it was cut fiber, pressure on the inside providers (or their feeds), or pressure on the outside providers. Traceroutes lend any clue? Jeff If the government did it, I guarantee it was cut fiber. That makes it difficult to quickly restore. One has to wonder whats going on there right now that they dont want the world to know about? Then its quite likely the government cut the fiber to cover that up :) wouldnt surprise me if they cut it in multiple places as well.
Re: Filter-based routing table management (was: Re: minimum IPv6 announcement size)
y'know, it's funny. there is a market in ipv4 space. there is no market in routing table slots. perhaps this is not conspiracy but rather the market is speaking. of course, we can use the idea of a market in routing table slots, rack space, or coffee to distract from the artificial problems in the only actual market, ipv4 address space. randy
Re: Suggestion on Fiber tester
On Thu, Sep 26, 2013 at 02:23:37AM +, Blake Pfankuch - Mailing List wrote: I am in the market for a simple fiber tester. I have about 80 pairs running through my complex and we are running into some possible issues with some of the really old ones. The pen light to confirm that it's the right strand is going to require a little bit more insight to determine if there is an issue with fiber in conduit or patch. I don't need something super fancy, just need something that gives a good, bad or holy crap is that concrete you are testing on for starters. I am also shooting for about $150-250 tops. Any suggestions? How about using the built-in Digital Optcis Monitoring (DOM/DDM) in modern SFPs? Assuming your switches/routers and SFPs support it, you can read the received power level right from your switches/routers. The cost might be zero if you already have capabile equipment... Combine that with a flashlight for identifying strands, and it might be all you need...
RE: Sudan disconnected from the Internet
We learned last week that iPhone updates cripple no network as they are regional and magical, simultaneously. ;) Sent from my Mobile Device. Original message From: Chuck Church chuckchu...@gmail.com Date: 09/26/2013 10:44 AM (GMT-08:00) To: nanog@nanog.org Subject: RE: Sudan disconnected from the Internet Or the country as a whole had WAY too many iPhones in need of a 7.0 upgrade. Chuck -Original Message- From: Keith Medcalf [mailto:kmedc...@dessus.com] Sent: Thursday, September 26, 2013 7:23 AM To: nanog@nanog.org Subject: RE: Sudan disconnected from the Internet Of course it is entirely possible that it was the rioters simply because they wanted people to notice. And I guess it worked. -Original Message- From: Warren Bailey [mailto:wbai...@satelliteintelligencegroup.com] Sent: Wednesday, 25 September, 2013 18:43 To: Tammy Firefly Cc: nanog@nanog.org Subject: Re: Sudan disconnected from the Internet We make Ku-band backpacks for this type of scenario. I would give it 12- 18 hours before you see CNN light up with live feeds.. I didn't even KNOW this was happening prior to them doing this. Seems like cutting off access would alert a lot more folks than some people wrecking Sudan over fuel subsidies?? Doesn't look like it's been picked up by CNN substantially yet, but I imagine we'll get breaking news soon enough. Would be interesting to see if it was a forced drop or did they actually just take a pair of scissors and murder the internets? On 9/25/13 5:40 PM, Tammy Firefly tammy-li...@wiztech.biz wrote: On 9/25/13 18:38:09, Warren Bailey wrote: http://abcnews.go.com/International/wireStory/sudan-security-clashes - subs id y-protesters-20360418 On 9/25/13 5:34 PM, Tammy Firefly tammy-li...@wiztech.biz wrote: On 9/25/13 18:29:58, Jeff Kell wrote: On 9/25/2013 8:25 PM, Tammy Firefly wrote: with the old fashioned pair of diagonal cutters applied to fiber? Yes, interesting to know if it was cut fiber, pressure on the inside providers (or their feeds), or pressure on the outside providers. Traceroutes lend any clue? Jeff If the government did it, I guarantee it was cut fiber. That makes it difficult to quickly restore. One has to wonder whats going on there right now that they dont want the world to know about? Then its quite likely the government cut the fiber to cover that up :) wouldnt surprise me if they cut it in multiple places as well.
Re: Sudan disconnected from the Internet
On Thu, Sep 26, 2013 at 1:39 PM, Chuck Church chuckchu...@gmail.com wrote: Or the country as a whole had WAY too many iPhones in need of a 7.0 upgrade. Chuck Man, they should really install some Akamai servers! ducks -Steve
Re: minimum IPv6 announcement size
On 9/26/2013 1:52 AM, bmann...@vacation.karoshi.com wrote: sounds just like folks in 1985, talking about IPv4... The foundation of that, though, was ignorance of address space exhaustion. IPv4's address space was too small for such large thinking. IPv6 is far beyond enough to use such allocation policies.
Re: Radware vs Arbor
For a DDoS solution; my experience leans on arbor's peakflow and their partnership with other upstream carrier's (Level3, Peer1, etc.) which makes sense since most of the attacks are distributed having recon work done by an organization like arbor makes you only worry about the attack types that come into your network and not much the top part complexities of it. I am in no relationship with arbor or any of it's employees. this is solely based on my knowledge of the product. regards, -Beavis On Thu, Sep 26, 2013 at 10:47 AM, Tempest tempestter...@gmail.com wrote: Doing a bunch of research, and I can't find a meaningful comparison of these two products. Work for a carrier, and I am looking at implementing a DDoS mitigation service that we can sell to our customers. Radware is cheaper, but I am seeing a lot of noise in various forums that makes me question their viability for what we need. Arbor has most of the market, and I assume there is good reason for it. Both companies seem to be very deceptive about how they compare to the other. Anyone out there with good hands on experience that can compare? Not interested in input from either company, we get plenty of that already. Good experience, or links to good write ups would be excellent... Davis B. -- () ascii ribbon campaign - against html e-mail /\ www.asciiribbon.org - against proprietary attachments Disclaimer: http://goldmark.org/jeff/stupid-disclaimers/
Re: minimum IPv6 announcement size
On Sep 26, 2013, at 12:29 PM, Darren Pilgrim na...@bitfreak.org wrote: On 9/26/2013 1:52 AM, bmann...@vacation.karoshi.com wrote: sounds just like folks in 1985, talking about IPv4... The foundation of that, though, was ignorance of address space exhaustion. IPv4's address space was too small for such large thinking. The first dicussion I could find about ipv4 runnout in email archives is circa 1983 IPv6 is far beyond enough to use such allocation policies. There are certain tendencies towards profligacy that might prematurely influence the question of ipv6 exhaustion and we should be on guard against them… allocating enough /48s as part of direct assignments is probably not one of them. signature.asc Description: Message signed with OpenPGP using GPGMail
Re: minimum IPv6 announcement size
On 9/26/2013 1:07 PM, joel jaeggli wrote: On Sep 26, 2013, at 12:29 PM, Darren Pilgrim na...@bitfreak.org wrote: On 9/26/2013 1:52 AM, bmann...@vacation.karoshi.com wrote: sounds just like folks in 1985, talking about IPv4... The foundation of that, though, was ignorance of address space exhaustion. IPv4's address space was too small for such large thinking. The first dicussion I could find about ipv4 runnout in email archives is circa 1983 IPv6 is far beyond enough to use such allocation policies. There are certain tendencies towards profligacy that might prematurely influence the question of ipv6 exhaustion and we should be on guard against them… allocating enough /48s as part of direct assignments is probably not one of them. That's just it, I really don't think we actually have an exhaustion risk with IPv6. IPv6 is massive beyond massive. Let me explain. We have this idea of the /64 boundary. All those nifty automatic addressing things rely on it. We now have two generations of hardware and software that would more or less break if we did away with it. In essence, we've translated an IPv4 /32 into an IPv6 /64. Not great, but still quite large. Current science says Earth can support ten billion humans. If we let the humans proliferate to three times the theoretical upper limit for Earth's population, a /64 for each human would be at about a /35's worth of /64's. If we're generous with Earth's carrying capacity, a /36. If we handed out /48's instead so each human could give a /64 to each of their devices, it would all fit in a single /52. Those /48's would number existance at a rate of one /64 per human, one /64 per device, and a 65535:1 device:human ratio. That means we could allocate 4000::/3 just for Earth humans and devices and never need another block for that purpose. That's assuming a very high utilisation ratio, of course, but really no worse than IPv4 is currently. The problem isn't allocation density, but router hardware. We need room for route aggregation and other means of compartmentalisation. Is a 10% utilisation rate sparse enough? At 10% utilisation, keeping the allocations to just 4000::/3, we'd need less than a single /60 for all those /48's. If 10% isn't enough, we can go quite a bit farther: - 1% utilisation would fit all those /48's into a /62. - A full /64 of those /48's would be 0.2% utilisation. - 0.1%? We'd have to steal a bit and hand out /47's instead. - /47 is ugly. At /52, we'd get .024% (one per 4096). That's while maintaining a practice of one /64 per human or device with 65535 devices per human. Introduce one /64 per subnet and sub-ppm utilisation is possible. That would be giving a site a /44 and them only ever using the ::/64 of it. Even with sloppy, sparse allocation policies and allowing limitless human and device population growth, we very likely can not exhaust IPv6.
Re: minimum IPv6 announcement size
On Thu, Sep 26, 2013 at 4:18 PM, Darren Pilgrim na...@bitfreak.org wrote: That's just it, I really don't think we actually have an exhaustion risk with IPv6. IPv6 is massive beyond massive. Hi Darren, At one point, I saw a proposal to allocate IPv6 /15's to ISPs. One /16 so they could overlay 32 bits of IPv4 using 6rd and deliver a /48 per ipv4 address and the other /16 for their native IPv6 operation, packaged as a /15 so they wouldn't need multiple routes. Yeah. So if we let ourselves assign addresses carelessly we could run out in the first half of this century. And while the plan above didn't fly, IPv6 /19's and /22's have been allocated already. Regards, Bill Herrin -- William D. Herrin her...@dirtside.com b...@herrin.us 3005 Crane Dr. .. Web: http://bill.herrin.us/ Falls Church, VA 22042-3004
Re: Radware vs Arbor
Surely both vendors have gear in many of the Tier1 carriers whether it be for layered security or dual vendor approach. When it comes down to deciding between the two you need to consider the deployment models and techniques in use. These two vendors strong points are in two separate areas. Arbor Peakflow is a very good traffic analysis tool which leverages netflow from your existing routers for probes providing good l3-l4 volumetric flood detection. Once a pps/bw anomaly is detected you can decide whether to reroute traffic into a scrubbing device (TMS/Radware, etc). Arbor common deployment is OOP netflow collection with redirection to scrubbing center. On the other hand Radware is a full packet inspection and mitigation (Layers 3-7) appliance. Radware is a transparent device with it's most common deployments inline, scrubbing center and out of path TAP modes. -- From: Beavis pfu...@gmail.com Sent: Thursday, September 26, 2013 3:57 PM To: Tempest tempestter...@gmail.com Cc: nanog@nanog.org Subject: Re: Radware vs Arbor For a DDoS solution; my experience leans on arbor's peakflow and their partnership with other upstream carrier's (Level3, Peer1, etc.) which makes sense since most of the attacks are distributed having recon work done by an organization like arbor makes you only worry about the attack types that come into your network and not much the top part complexities of it. I am in no relationship with arbor or any of it's employees. this is solely based on my knowledge of the product. regards, -Beavis On Thu, Sep 26, 2013 at 10:47 AM, Tempest tempestter...@gmail.com wrote: Doing a bunch of research, and I can't find a meaningful comparison of these two products. Work for a carrier, and I am looking at implementing a DDoS mitigation service that we can sell to our customers. Radware is cheaper, but I am seeing a lot of noise in various forums that makes me question their viability for what we need. Arbor has most of the market, and I assume there is good reason for it. Both companies seem to be very deceptive about how they compare to the other. Anyone out there with good hands on experience that can compare? Not interested in input from either company, we get plenty of that already. Good experience, or links to good write ups would be excellent... Davis B. -- () ascii ribbon campaign - against html e-mail /\ www.asciiribbon.org - against proprietary attachments Disclaimer: http://goldmark.org/jeff/stupid-disclaimers/
Re: minimum IPv6 announcement size
On Sep 26, 2013, at 1:18 PM, Darren Pilgrim na...@bitfreak.org wrote: On 9/26/2013 1:07 PM, joel jaeggli wrote: On Sep 26, 2013, at 12:29 PM, Darren Pilgrim na...@bitfreak.org wrote: On 9/26/2013 1:52 AM, bmann...@vacation.karoshi.com wrote: sounds just like folks in 1985, talking about IPv4... The foundation of that, though, was ignorance of address space exhaustion. IPv4's address space was too small for such large thinking. The first dicussion I could find about ipv4 runnout in email archives is circa 1983 IPv6 is far beyond enough to use such allocation policies. There are certain tendencies towards profligacy that might prematurely influence the question of ipv6 exhaustion and we should be on guard against them… allocating enough /48s as part of direct assignments is probably not one of them. That's just it, I really don't think we actually have an exhaustion risk with IPv6. IPv6 is massive beyond massive. Let me explain. Instead of explaining to me how awesomely big ipv6 is you might figure out who you're talking to, or maybe consider the problem a bit more. Semantic addressing schemes can soak up as many bits as you're willing to give them. ISP(s) using (for example) 6rd or other automatic prefix mapping mechanisms can potentially use rather large prefixes. 128 bits is not so many that we can't trivially soak them all up and we should not pretend otherwise. We are stewards of the resource and we should manage it with care that reflect's long term thinking, both so that allocations we make now are not inappropriately small in the future and such that we are not again confronting the shortcomings of our decision-making again in 20 years. We have this idea of the /64 boundary. All those nifty automatic addressing things rely on it. We now have two generations of hardware and software that would more or less break if we did away with it. In essence, we've translated an IPv4 /32 into an IPv6 /64. Not great, but still quite large. Current science says Earth can support ten billion humans. If we let the humans proliferate to three times the theoretical upper limit for Earth's population, a /64 for each human would be at about a /35's worth of /64's. If we're generous with Earth's carrying capacity, a /36. If we handed out /48's instead so each human could give a /64 to each of their devices, it would all fit in a single /52. Those /48's would number existance at a rate of one /64 per human, one /64 per device, and a 65535:1 device:human ratio. That means we could allocate 4000::/3 just for Earth humans and devices and never need another block for that purpose. That's assuming a very high utilisation ratio, of course, but really no worse than IPv4 is currently. The problem isn't allocation density, but router hardware. We need room for route aggregation and other means of compartmentalisation. Is a 10% utilisation rate sparse enough? At 10% utilisation, keeping the allocations to just 4000::/3, we'd need less than a single /60 for all those /48's. If 10% isn't enough, we can go quite a bit farther: - 1% utilisation would fit all those /48's into a /62. - A full /64 of those /48's would be 0.2% utilisation. - 0.1%? We'd have to steal a bit and hand out /47's instead. - /47 is ugly. At /52, we'd get .024% (one per 4096). That's while maintaining a practice of one /64 per human or device with 65535 devices per human. Introduce one /64 per subnet and sub-ppm utilisation is possible. That would be giving a site a /44 and them only ever using the ::/64 of it. Even with sloppy, sparse allocation policies and allowing limitless human and device population growth, we very likely can not exhaust IPv6. signature.asc Description: Message signed with OpenPGP using GPGMail
Re: minimum IPv6 announcement size
sounds just like folks in 1985, talking about IPv4... The foundation of that, though, was ignorance of address space exhaustion. no. ipv4 was the second time, not the first randy
Re: Filter-based routing table management (was: Re: minimum IPv6 announcement size)
Oh this sure will be fun. For a good time, see how GSMA handles connectivity with IPXs. On Sep 26, 2013 1:28 PM, William Herrin b...@herrin.us wrote: On Thu, Sep 26, 2013 at 11:07 AM, John Curran jcur...@istaff.org wrote: On Sep 26, 2013, at 4:52 AM, bmann...@vacation.karoshi.com wrote: sounds just like folks in 1985, talking about IPv4... If there were ever were a need for an market/settlement model, it is with respect to routing table slots. That's not to say that establishing a framework for externalizing routing costs would be easy; it's a complicated and twisted matter, and also fraught with various legal competitive aspects. Hi John, That's putting it mildly. Establishing such a framework would be an immense challenge. Here are some ideas I've heard: 1. The International Clearinghouse Every BGP participant files with a clearinghouse, specifying: a. How much they charge to carry 1 route b. Whether or not they are a leaf node c. Whether or not they are a transit-free network. Any network which is not transit free must implement a default route which leads to a big transit-free network in order to maintain full connectivity. The BGP participants then publish the exact routes they intend to announce to the clearinghouse and for each one select which networks they'll pay to carry the route. The route must still reach each network via BGP; payment just means that the network won't filter the route out. The clearinghouse then collects payments from everybody and makes payments to everybody, as well as providing each participant a list of the routes that are paid for. Sellers are expected to promptly incorporate new paid routes into their BGP filters. From my research a few years ago, a reasonable rate would be around 3 to 4 cents per year per advertised route per BGP-carrying router in the organization. A couple billion dollars per year if the routing table maintained its current size. 2. The partial routing scenario Large service providers put bids in to the RIRs for the right to announce /8 covering routes for each /8 delegated to the RIR. Each /8 matches exactly one service provider. Smaller BGP system participants make private arrangements with a small (20 to 30) set of networks (including their direct ISPs) to carry their advertised routes through a reasonably redundant number of pathways to (and including) the winning bidder for the /8 they inhabit. For the sake of performance, they may also pay additional large networks to shortcut the traffic towards them rather than let it dump at the /8 advertiser. For the folks you don't pay via the clearinghouse, many end-user systems and the majority of transit systems simply don't carry your route unless yours is among the handful of systems critically important to their customers. Instead, traffic to your network follows the /8 advertisement until it reaches a network which carries your specific route. With the routing costs suitably reduced, settlement for the remaining routes becomes moot. This is usually within a few percent of the routing efficiency that would have been achieved with total route propagation. 3. The routing overlay Establish a semi-stateless tunneling system. Each BGP participant sets up a tunnel ingress node and links a default route to it. Packets for a destination not found in the routing table follow the default route to the tunnel ingress. The tunnel device then looks up an tunnel exit node via a mapping protocol. Both the map server and the exit node have to be hosted on IP addresses reachable via the normal routing table. Having found an exit node, the original packet is encapsulated into a tunnel packet and sent to the exit node. The exit node is in a part of the network that carries an explicit route to the destination. Then, move the definition of threshold size. Except for whitelisted critical infrastructure, /24 advertisements would no longer carry an expectation of universal distribution. To maintain connectivity, folks at the bottom of the chain would need to establish or subscribe to tunnel exit nodes that have a route back to them. With the routing costs suitably reduced, settlement for the remaining routes becomes moot. The IRTF Routing Research Group studied such protocols a few years ago and have pretty well fleshed out how to make one work with all the tangled issues involving path mtu, dead path detection and so on. Multiple designs sit on a shelf waiting for a promise that the technology will be purchased if built. Regards, Bill Herrin -- William D. Herrin her...@dirtside.com b...@herrin.us 3005 Crane Dr. .. Web: http://bill.herrin.us/ Falls Church, VA 22042-3004
Re: Suggestion on Fiber tester
I would also suggest you use a ferrule cleaner every single time you touch an end http://www.fiberoptics4sale.com/p/Fiber_Optic_Connector_Reel_Cleaners/SFM25 0.html Carlos Alcantar Race Communications / Race Team Member 1325 Howard Ave. #604, Burlingame, CA. 94010 Phone: +1 415 376 3314 / car...@race.com / http://www.race.com -Original Message- From: Chuck Anderson c...@wpi.edu Date: Thursday, September 26, 2013 10:52 AM To: nanog@nanog.org nanog@nanog.org Subject: Re: Suggestion on Fiber tester On Thu, Sep 26, 2013 at 02:23:37AM +, Blake Pfankuch - Mailing List wrote: I am in the market for a simple fiber tester. I have about 80 pairs running through my complex and we are running into some possible issues with some of the really old ones. The pen light to confirm that it's the right strand is going to require a little bit more insight to determine if there is an issue with fiber in conduit or patch. I don't need something super fancy, just need something that gives a good, bad or holy crap is that concrete you are testing on for starters. I am also shooting for about $150-250 tops. Any suggestions? How about using the built-in Digital Optcis Monitoring (DOM/DDM) in modern SFPs? Assuming your switches/routers and SFPs support it, you can read the received power level right from your switches/routers. The cost might be zero if you already have capabile equipment... Combine that with a flashlight for identifying strands, and it might be all you need...
Re: iOS 7 update traffic
I have heard a lot of questions and debate about whether the iOS updates download automatically: “Available updates download automatically if your device is connected to Wi-Fi and a power source.” http://support.apple.com/kb/HT4623 http://support.apple.com/kb/HT4623 /mark http://support.apple.com/kb/HT4623 http://support.apple.com/kb/HT4623
Re: BGP Attribute 128
On (2013-09-25 11:35 -0400), Jared Mauch wrote: Hi, I'm not really in favor of the features vendors have provided, such as this to just drop the attribute or routes. I would encourage customers to require in their transit agreements that bgp updates are not mangled by provider. It would help internally if you have customer backing. I think it's overraction to kill useful features because sometime on some platform there has been NLRI parsing bug which caused issues. Once those filters are deployed there will be strong resistance to remove them. -- ++ytti
Re: iOS 7 update traffic
On Sep 26, 2013, at 5:22 PM, Mark Lancaster markl...@gmail.com wrote: I have heard a lot of questions and debate about whether the iOS updates download automatically: “Available updates download automatically if your device is connected to Wi-Fi and a power source.” http://support.apple.com/kb/HT4623 http://support.apple.com/kb/HT4623 /mark The wording in step 2 is poorly done. The availability of updates is what is downloaded. Step 3 indicates an active user input to begin download is required.
Re: BGP Attribute 128
I certainly agree. There is a very narrow case for filtering 128 as it's a VPN attribute that should not be in the big-I Internet. Jared Mauch On Sep 26, 2013, at 4:28 PM, Saku Ytti s...@ytti.fi wrote: Once those filters are deployed there will be strong resistance to remove them.
Re: iOS 7 update traffic
Cutler James R james.cut...@consultant.com writes: On Sep 26, 2013, at 5:22 PM, Mark Lancaster markl...@gmail.com wrote: I have heard a lot of questions and debate about whether the iOS updates download automatically: Available updates download automatically if your device is connected to Wi-Fi and a power source. http://support.apple.com/kb/HT4623 http://support.apple.com/kb/HT4623 /mark The wording in step 2 is poorly done. The availability of updates is what is downloaded. Step 3 indicates an active user input to begin download is required. The updates do download automatically, but only if the device is on wifi and power at the same time. For iOS 6, a check for available updates will be attempted at a randomly chosen time on a randomly chosen day of the week. If one is found, an automatic download may follow if/when on power and wifi. Opening the Software Update pane will cause an immediate check for available updates. If one is found it will be displayed to the user, who may touch the button, which will complete the download (even if not on power or not on wifi, although there are minimum battery charge requirements and some updates can't be downloaded over cell) as necessary, and then perform the install. So, an ISP will see initial traffic when an update is released, as people manually install it, and some continuing traffic spread over at least the next week as the automatic downloads occur. Then, of course, once people have updated their device, they'll want to use it: update their apps, download a new Siri voice, buy music...
Re: minimum IPv6 announcement size
On Thu, Sep 26, 2013 at 12:29:17PM -0700, Darren Pilgrim wrote: On 9/26/2013 1:52 AM, bmann...@vacation.karoshi.com wrote: sounds just like folks in 1985, talking about IPv4... The foundation of that, though, was ignorance of address space exhaustion. IPv4's address space was too small for such large thinking. IPv6 is far beyond enough to use such allocation policies. when concevied, IPv4 was unimaginably large ... /8's were handed out to networks with fewer than 10 devices.Hindsight is 20/20. those who ignore teh past are doomed to repeat it /bill
Re: minimum IPv6 announcement size
Yup. Seen/Heard all that. Even tooted that horn for a while. /64 is an artifical boundary - many/most IANA/RIR delegations are in the top /32 which is functionally the same as handing out traditional /16s. Some RIR client are bigger and demand more, so they get the v6 equvalent of /14s or smaller. Its the _exact_ same model as v4 in the previous decade. With the entire waste in the bottom /64. Its tilting at windmills, but most of the community has drunk the koolaide on wasteful /v6 assignment. What a horrific legacy to hand to our children (and yes, it will hit that soon) /bill On Thu, Sep 26, 2013 at 01:18:50PM -0700, Darren Pilgrim wrote: On 9/26/2013 1:07 PM, joel jaeggli wrote: On Sep 26, 2013, at 12:29 PM, Darren Pilgrim na...@bitfreak.org wrote: On 9/26/2013 1:52 AM, bmann...@vacation.karoshi.com wrote: sounds just like folks in 1985, talking about IPv4... The foundation of that, though, was ignorance of address space exhaustion. IPv4's address space was too small for such large thinking. The first dicussion I could find about ipv4 runnout in email archives is circa 1983 IPv6 is far beyond enough to use such allocation policies. There are certain tendencies towards profligacy that might prematurely influence the question of ipv6 exhaustion and we should be on guard against them allocating enough /48s as part of direct assignments is probably not one of them. That's just it, I really don't think we actually have an exhaustion risk with IPv6. IPv6 is massive beyond massive. Let me explain. We have this idea of the /64 boundary. All those nifty automatic addressing things rely on it. We now have two generations of hardware and software that would more or less break if we did away with it. In essence, we've translated an IPv4 /32 into an IPv6 /64. Not great, but still quite large. Current science says Earth can support ten billion humans. If we let the humans proliferate to three times the theoretical upper limit for Earth's population, a /64 for each human would be at about a /35's worth of /64's. If we're generous with Earth's carrying capacity, a /36. If we handed out /48's instead so each human could give a /64 to each of their devices, it would all fit in a single /52. Those /48's would number existance at a rate of one /64 per human, one /64 per device, and a 65535:1 device:human ratio. That means we could allocate 4000::/3 just for Earth humans and devices and never need another block for that purpose. That's assuming a very high utilisation ratio, of course, but really no worse than IPv4 is currently. The problem isn't allocation density, but router hardware. We need room for route aggregation and other means of compartmentalisation. Is a 10% utilisation rate sparse enough? At 10% utilisation, keeping the allocations to just 4000::/3, we'd need less than a single /60 for all those /48's. If 10% isn't enough, we can go quite a bit farther: - 1% utilisation would fit all those /48's into a /62. - A full /64 of those /48's would be 0.2% utilisation. - 0.1%? We'd have to steal a bit and hand out /47's instead. - /47 is ugly. At /52, we'd get .024% (one per 4096). That's while maintaining a practice of one /64 per human or device with 65535 devices per human. Introduce one /64 per subnet and sub-ppm utilisation is possible. That would be giving a site a /44 and them only ever using the ::/64 of it. Even with sloppy, sparse allocation policies and allowing limitless human and device population growth, we very likely can not exhaust IPv6.
