Re: anyone from netnames / ascio on list?
On 9/4/2011 5:34 PM, Andrew Mulholland wrote: I'm not seeing the problem here? Registrant: Gateway, Inc. (GATEW95532) 7565 Irvine Center Drive Irvine, CA, 92618-2930 US Domain name: acer.com Technical contact: Administrator, Domain (DA73355) NetNames Hostmaster 3rd Floor Prospero House 241 Borough High Street Borough, London, SE1 1GA GB corporate-servi...@netnames.com +44.2070159370 Fax: +44.2070159375 Administrative contact: Wagner, Michael (MW47730) Gateway, Inc. 7565 Irvine Center Drive Irvine, CA, 92618-2930 US hostad...@gateway.com +1.8008462042 Fax: +1.00 Record created: 2010-10-04 17:54:28 Record last updated: 2011-09-04 22:24:04 Record expires: 2019-05-17 01:00:00 Domain servers in listed order: ns1.acer.com (NS1ACERC38319) ns2.acer.com (NS2ACERC59089) ns3.acer.com (NS3ACERC70649) ns4.acer.com (NS4ACERC28541) ns5.acer.com (NS5ACERC49101) ns6.acer.com (NS6ACERC86343)
Re: anyone from netnames / ascio on list?
It was resolved last night. http://www.guardian.co.uk/technology/2011/sep/05/dns-hackers-telegraph-interview Andrew On Mon, Sep 5, 2011 at 7:15 AM, Andrew Kirch trel...@trelane.net wrote: On 9/4/2011 5:34 PM, Andrew Mulholland wrote: I'm not seeing the problem here? Registrant: Gateway, Inc. (GATEW95532) 7565 Irvine Center Drive Irvine, CA, 92618-2930 US Domain name: acer.com Technical contact: Administrator, Domain (DA73355) NetNames Hostmaster 3rd Floor Prospero House 241 Borough High Street Borough, London, SE1 1GA GB corporate-servi...@netnames.com +44.2070159370 Fax: +44.2070159375 Administrative contact: Wagner, Michael (MW47730) Gateway, Inc. 7565 Irvine Center Drive Irvine, CA, 92618-2930 US hostad...@gateway.com +1.8008462042 Fax: +1.00 Record created: 2010-10-04 17:54:28 Record last updated: 2011-09-04 22:24:04 Record expires: 2019-05-17 01:00:00 Domain servers in listed order: ns1.acer.com (NS1ACERC38319) ns2.acer.com (NS2ACERC59089) ns3.acer.com (NS3ACERC70649) ns4.acer.com (NS4ACERC28541) ns5.acer.com (NS5ACERC49101) ns6.acer.com (NS6ACERC86343)
Re: Do Not Complicate Routing Security with Voodoo Economics
Hi Jen, Thanks for the suggestion! Yes, I would encourage interested people to contact me. We won't be able to put everyone on the working group (in the interest of having a small enough group to make progress), but we are very interested in having people who can offer their expertise, feedback, and advice throughout the process... Well, Why not everyone? What would be the criteria to add people into the working group? IETF or any RIR doesn't stop anyone from joining any WG. Every member of the WG should be treated as potential contributor. Regards, Aftab A. Siddiqui.
Re: Do Not Complicate Routing Security with Voodoo Economics
In a message written on Sun, Sep 04, 2011 at 04:16:45PM -0400, Sharon Goldberg wrote: An ISP might deploy S*BGP in order to increase the volume of traffic that it transits for its customers. I think this phrase summarizes the problem with this argument nicely. If, as an ISP, deploying a secure routing protocol changes my traffic positively or negatively something is wrong. Securing the routing system should not alter the routing system. I'm afraid as long as it does this work has an uphill battle. -- Leo Bicknell - bickn...@ufp.org - CCIE 3440 PGP keys at http://www.ufp.org/~bicknell/ pgpl2huz3upMg.pgp Description: PGP signature
Re: Do Not Complicate Routing Security with Voodoo Economics
On Sep 5, 2011, at 5:47 AM, Leo Bicknell wrote: In a message written on Sun, Sep 04, 2011 at 04:16:45PM -0400, Sharon Goldberg wrote: An ISP might deploy S*BGP in order to increase the volume of traffic that it transits for its customers. I think this phrase summarizes the problem with this argument nicely. If, as an ISP, deploying a secure routing protocol changes my traffic positively or negatively something is wrong. Securing the routing system should not alter the routing system. I'm afraid as long as it does this work has an uphill battle. One could argue that rejecting routes which you previously had no way to know you should reject will inherently alter the routing system and that this is probably a good thing. Owen
Re: Do Not Complicate Routing Security with Voodoo Economics
One could argue that rejecting routes which you previously had no way to know you should reject will inherently alter the routing system and that this is probably a good thing. Good point. Also, tie breaking in favor of signed-and-verified routes over not-signed-and-verified routes does not necessarily affect your traffic positively or negatively -- rather, if you are letting an arbitrary final tie break make the decision anyway, you are arguably *neutral* about the outcome... -- Jen
RE: Do Not Complicate Routing Security with Voodoo Economics
On Sep 5, 2011, at 11:55 AM, Dobbins, Roland wrote: The idea of origin validation is a simple one. The idea of path validation isn't to determine the 'correctness' or 'desirability' of a particular AS-path, but rather to determine the *validity* (or at least the *feasability*) of a given AS-path. Sorry, I was misunderstood. To clarify, I was referring only to our work (http://www.cs.utoronto.ca/~phillipa/sbgpTrans.html), where security does play a small role in the route selection process (after LocalPref and AS-PATH length), and not to the BGPsec spec. The reason why we assume that security affects the route selection process is because otherwise, even an AS that deploys S*BGP, remains vulnerable to attacks. To see why, take a look at slides 10-13 of our NANOG presentation (http://www.cs.bu.edu/~goldbe/papers/Goldberg-TransitionToSBGP-NANOG.pdf, video available at http://www.cs.utoronto.ca/~phillipa/sbgpTrans.html). The basic idea is: if an AS prefers short paths over secure paths they'll be just as vulnerable to path-shortening attacks with and without S*BGP.
Re: Preferring peers over customers [was: Do Not Complicate Routing Security with Voodoo Economics]
On Sep 4, 2011, at 9:18 PM, Patrick W. Gilmore wrote: I would like the large networks of the world to state whether they prefer their customer routes over peer routes, and how. For instance, does $NETWORK prefer customers only when the AS path is the same, or all the time no matter what? Let's leave out corner cases - e.g. If a customer asks you, via communities or otherwise, to do something different. This is a poll of default, vanilla configurations. Please send them to me, or the list, with this subject line. I shall compile the results and post them somewhere public. If you cannot speak for your company, I will keep your name private. The NTT network has a well documented local-pref policy that shows what is done. You can review it on the website, including showing that the default local-preference is 120. http://www.us.ntt.net/support/policy/routing.cfm Having worked for small players that peered with other partners/networks in the past, not following a model of customer - peer - transit order of preference, you can create situations where someone unexpectedly is creating a traffic black hole. It's not saying you can't build a better model, but this is fairly straightforward and provides expected results. Your customer routes will always be propagated to your peers. Having communities to allow the customer to change how their routes are propagated is valuable so they can 'choose their own adventure'. If someone wants to not announce to another provider, that is their fault when traffic breaks. - Jared
Re: Do Not Complicate Routing Security with Voodoo Economics
On Sep 5, 2011, at 7:24 AM, Jennifer Rexford wrote: One could argue that rejecting routes which you previously had no way to know you should reject will inherently alter the routing system and that this is probably a good thing. Good point. Also, tie breaking in favor of signed-and-verified routes over not-signed-and-verified routes does not necessarily affect your traffic positively or negatively -- rather, if you are letting an arbitrary final tie break make the decision anyway, you are arguably *neutral* about the outcome... -- Jen This is true in terms of whether you care or not, but, if one just looks at whether it changes the content of the FIB or not, changing which arbitrary tie breaker you use likely changes the contents of the FIB in at least some cases. The key point is that if you are to secure a previously unsecured database such as the routing table, you will inherently be changing the contents of said database, or, your security isn't actually accomplishing anything. Owen
Re: Do Not Complicate Routing Security with Voodoo Economics
Owen DeLong wrote: On Sep 5, 2011, at 7:24 AM, Jennifer Rexford wrote: One could argue that rejecting routes which you previously had no way to know you should reject will inherently alter the routing system and that this is probably a good thing. Good point. Also, tie breaking in favor of signed-and-verified routes over not-signed-and-verified routes does not necessarily affect your traffic positively or negatively -- rather, if you are letting an arbitrary final tie break make the decision anyway, you are arguably *neutral* about the outcome... -- Jen This is true in terms of whether you care or not, but, if one just looks at whether it changes the content of the FIB or not, changing which arbitrary tie breaker you use likely changes the contents of the FIB in at least some cases. The key point is that if you are to secure a previously unsecured database such as the routing table, you will inherently be changing the contents of said database, or, your security isn't actually accomplishing anything. Owen Except if you believe we have been lucky until now and security is all about the future where we may be less lucky. What I would be interested in seeing is a discussion on whether any anti-competitive market distortion incentives exist for large providers in adopting secured BGP. We might be lucky there too. Perhaps this will finally help solve the routing slot scalability problem. Might also jumpstart LISP. Which may put some more steam into v6. Welcome to the brave new internet. Good for everyone, right? Are you feeling lucky? Joe
Re: Do Not Complicate Routing Security with Voodoo Economics
Three thoughts on the thread so far. 1. I think Randy raises an interesting point about the complexity of contracts. We had a paper in SIGCOMM this year on the increasing use of more complicated interconnection contracts (and, in particular, tiered pricing). See Section 2 of our paper [1]: http://www.gtnoise.net/papers/library/valancius-tiers.pdf Some of us academics are trying to get more clued up on what providers actually do. :-) [I may start a discussion on the pricing models in this paper in a separate thread later] 2. I question what fraction of routing decisions come down to a blind tiebreak---nearly all of them are likely to be driven by some other consideration (reliability, cost, etc.). Our paper details a richer economic model by which ASes actually select paths, for example, but it's still unclear to me how coarse or fine-grained route selection really is in practice, and to what extent more complicated contracts have evolved. I wonder how common blind tiebreaking is in BGP, in real networks; the approach in Sharon's paper definitely may overstate how common that is if route selection considerations commonly involve things that are not visible in the AS graph (e.g., traffic ratios, congestion, performance), but academics could really benefit from some more insight into how rich these decisions are in practice. 3. I think the discussion on the list so far misses what I see as the central question about the economic assumptions in that paper. The paper assumes that all destinations are equally valuable, which we know is not the case. This implicitly (and perhaps mistakenly?) shifts the balance of power to tier-1 ISPs, whereas in practice, it may be with other ASes (e.g., Google). In practice, ISPs may be willing to spend significant amounts of money to reach certain destinations or content (some destinations are more valuable than others... e.g., Google). If the most valuable destinations deployed S-BGP and made everyone who wanted to connect to them deploy it, that would be more likely to succeed than the approach taken in the paper, I think. Conclusion: All of these questions above make me wonder about two more general assumptions that it would be good to get some more insight into: * Who holds the cards, in terms of dictating the terms of interconnection? Content providers? Access networks/eyeballs? Tier-1s? (many of the recent peering spats recently seem to indicate that various ASes are trying to shake the current balance(s) of power, it seems) * How complicated are interconnection contracts today, and how have they evolved? (i.e., how common is a random tiebreak, and how does that differ by network?) -Nick - [1] Valancius, V. and Lumezanu, C. and Feamster, N. and Johari, R. and Vazirani, V.V. How Many Tiers? Pricing in the Internet Transit Market In ACM SIGCOMM, 2011 On Sep 5, 2011, at 11:36 AM, Joe Maimon wrote: Owen DeLong wrote: On Sep 5, 2011, at 7:24 AM, Jennifer Rexford wrote: One could argue that rejecting routes which you previously had no way to know you should reject will inherently alter the routing system and that this is probably a good thing. Good point. Also, tie breaking in favor of signed-and-verified routes over not-signed-and-verified routes does not necessarily affect your traffic positively or negatively -- rather, if you are letting an arbitrary final tie break make the decision anyway, you are arguably *neutral* about the outcome... -- Jen This is true in terms of whether you care or not, but, if one just looks at whether it changes the content of the FIB or not, changing which arbitrary tie breaker you use likely changes the contents of the FIB in at least some cases. The key point is that if you are to secure a previously unsecured database such as the routing table, you will inherently be changing the contents of said database, or, your security isn't actually accomplishing anything. Owen Except if you believe we have been lucky until now and security is all about the future where we may be less lucky. What I would be interested in seeing is a discussion on whether any anti-competitive market distortion incentives exist for large providers in adopting secured BGP. We might be lucky there too. Perhaps this will finally help solve the routing slot scalability problem. Might also jumpstart LISP. Which may put some more steam into v6. Welcome to the brave new internet. Good for everyone, right? Are you feeling lucky? Joe
Re: Do Not Complicate Routing Security with Voodoo Economics
On Sep 5, 2011, at 11:51 PM, Nick Feamster wrote: If the most valuable destinations 'Most valuable', 'least expensive', 'least congested', 'most reliable', 'most responsive', 'least contractually onerous', 'most generous ratio', 'most lucrative', et. al. - all these criteria and more come into play in the context of traffic engineering, and they're all relative to who you are and where you are and where you want your traffic/their traffic/someone else's traffic to go. And all the above vary depending upon your business type, business model, geographical reach, topological diversity, etc. So, as you imply, one set of economic parameters and weights for one SP will be completely different for the economic parameters and weights for another SP. It's possible to roughly generalize based upon SP type, but there are many, many variables which will affect routing selection complexity. --- Roland Dobbins rdobb...@arbor.net // http://www.arbornetworks.com The basis of optimism is sheer terror. -- Oscar Wilde
Re: Tampa small colo recs?
Hivelocity has a facility in Tampa. I have a virtual private server there with someone colo'd there and it's great. Email me off list and I'll give you the IP address for tracerouting or whatever you need to do. -C
Re: Do Not Complicate Routing Security with Voodoo Economics
On Sep 5, 2011, at 8:36 AM, Joe Maimon wrote: Owen DeLong wrote: On Sep 5, 2011, at 7:24 AM, Jennifer Rexford wrote: One could argue that rejecting routes which you previously had no way to know you should reject will inherently alter the routing system and that this is probably a good thing. Good point. Also, tie breaking in favor of signed-and-verified routes over not-signed-and-verified routes does not necessarily affect your traffic positively or negatively -- rather, if you are letting an arbitrary final tie break make the decision anyway, you are arguably *neutral* about the outcome... -- Jen This is true in terms of whether you care or not, but, if one just looks at whether it changes the content of the FIB or not, changing which arbitrary tie breaker you use likely changes the contents of the FIB in at least some cases. The key point is that if you are to secure a previously unsecured database such as the routing table, you will inherently be changing the contents of said database, or, your security isn't actually accomplishing anything. Owen Except if you believe we have been lucky until now and security is all about the future where we may be less lucky. I'm pretty sure that there is actually a fair amount of pollution in the routing table today and that it will only get worse until we have some form of security. I believe that most spammers operate by advertising hijacked prefixes for short periods of time and then going away before people can react. Since there have been multiple instances of proof of my above belief, I would find it very hard to believe we have been lucky until now. What I would be interested in seeing is a discussion on whether any anti-competitive market distortion incentives exist for large providers in adopting secured BGP. We might be lucky there too. Of course they do. We probably won't get particularly lucky there, either. Perhaps this will finally help solve the routing slot scalability problem. Might also jumpstart LISP. Which may put some more steam into v6. Welcome to the brave new internet. Probably not. I really doubt it will do much to help LISP. Contrary to many people's opinions, I think that IPv4 address shortage and the coming costs of attempting to maintain IPv4 on life support will put more steam into IPv6 than any artificial move we could make in this area. Good for everyone, right? IPv6 is good for everyone whether they realize it or not. LISP I'm not as convinced. Are you feeling lucky? No, not really. Owen
Re: Do Not Complicate Routing Security with Voodoo Economics
Nick Feamster wrote: 2. I question what fraction of routing decisions come down to a blind tiebreak---nearly all of them are likely to be driven by some other consideration (reliability, cost, etc.). Our paper details a richer economic model by which ASes actually select paths, for example, but it's still unclear to me how coarse or fine-grained route selection really is in practice, and to what extent more complicated contracts have evolved. I wonder how common blind tiebreaking is in BGP, in real networks; the approach in Sharon's paper definitely may overstate how common that is if route selection considerations commonly involve things that are not visible in the AS graph (e.g., traffic ratios, congestion, performance), but academics could really benefit from some more insight into how rich these decisions are in practice. We think a key point is getting lost here. Routing policies affect our result in the following crucial way -- they determine the size of ASes' tiebreak sets (section 6.6). A tiebreak set is a set of equally good routes that an source AS has to a destination AS; in our model, an AS should prefer to route along the _secure_ routes in its tiebreak set. Simply put, with a larger tiebreak set, there should be more competition over customer traffic, and thus more widespread S*BGP deployment. In our simulations we assumed that tiebreak sets were determined by Local-Pref (economic considerations) and AS-Path considerations. In practice, tiebreak sets could be larger (e.g., if ASes prefer shorter paths over customer paths) or smaller (e.g., if intradomain considerations, like hot potato routing, affect tiebreak sets) than those in our simulations. Like Nick said, this is a place where more data from the ops community would be helpful to help us figure out how big tiebreak sets really are. However, the key point we want to emphasize is that in the simulations we ran, the tiebreak sets are actually quite small: 1) The size of the average AS tiebreak set in our simulations is only 1.18; which mean that 80% of tiebreak sets have only one path, see also Figure 8. 2) Security does not play a role in the vast majority (96%) of routing decisions made in our simulations (Section 6.7). In other words, S*BGP deployment can be driven even by a fairly small amount of competition for customer traffic. 3. I think the discussion on the list so far misses what I see as the central question about the economic assumptions in that paper. The paper assumes that all destinations are equally valuable, which we know is not the case. This implicitly (and perhaps mistakenly?) shifts the balance of power to tier-1 ISPs, whereas in practice, it may be with other ASes (e.g., Google). In practice, ISPs may be willing to spend significant amounts of money to reach certain destinations or content (some destinations are more valuable than others... e.g., Google). If the most valuable destinations deployed S-BGP and made everyone who wanted to connect to them deploy it, that would be more likely to succeed than the approach taken in the paper, I think. Our paper does not assume all destinations are equally valuable. 1) As mentioned in our response to Randy, we weight content providers more heavily (see Section 6.8.1; we ran experiments where the content providers collectively source 10%, 20%, 33% or 50% of Internet traffic). 2) From Section 6.8.1: We test the robustness of our results... by modeling traffic locality [the idea that ASes are likely to send more traffic to ASes that are closer to them]... Section 6.8.2 shows our results are insensitive to this assumption. Sincerely, Phillipa Gill, Michael Schapira, and Sharon Goldberg On Sep 5, 2011, at 11:36 AM, Joe Maimon wrote: Owen DeLong wrote: On Sep 5, 2011, at 7:24 AM, Jennifer Rexford wrote: One could argue that rejecting routes which you previously had no way to know you should reject will inherently alter the routing system and that this is probably a good thing. Good point. Also, tie breaking in favor of signed-and-verified routes over not-signed-and-verified routes does not necessarily affect your traffic positively or negatively -- rather, if you are letting an arbitrary final tie break make the decision anyway, you are arguably *neutral* about the outcome... -- Jen This is true in terms of whether you care or not, but, if one just looks at whether it changes the content of the FIB or not, changing which arbitrary tie breaker you use likely changes the contents of the FIB in at least some cases. The key point is that if you are to secure a previously unsecured database such as the routing table, you will inherently be changing the contents of said database, or, your security isn't actually accomplishing anything. Owen Except if you believe we have been lucky until now and security is all about the future where we may be less lucky. What I would be
Re: iCloud - Is it going to hurt access providers?
On 9/3/11 04:20 , Skeeve Stevens wrote: Hey all, I've been thinking about the impact that iCloud (by Apple) will have on the Internet. My guess is that 99% of consumer internet access is Asymmetrical (DSL, Cable, wireless, etc) and iCloud when launched will 'upload' obscene amounts of gigs of music, tv, backups, email, photos, documents/data and so on to their data centres. It won't been obscene amounts, the free tier's quota is only 10GB. the music which is probably the thing that moves into the the cloud the fashion you described isn't moved into the cloud by uploading. I'd expect the reads to dominate over writes so your traffic pattern asymmetry is preserved. Now, don't misunderstand me, I love the concept of iCloud, as I do DropBox, but from an Access Providers perspective, I'm thinking this might be a 'bad thing'. having customers that want to use your service is rarely a bad thing. One of the things that this discussion point misses is that when you operate at a distance from your data, you become rather sensitive to latency. while apple is rather good about caching data locally, that doesn't eliminate it from consideration. From what I can see there are some key issues: * Users with plans that count upload and download together. * The speed of Asymmetric tail technology such as DSL * The design of access provider backhaul (from DSLAM to core) metrics * The design of some transit metrics So basically the potential issue is that a large residential provider could have thousands of users connect to iCloud, their connections slowed because of uploading data, burning their included bandwidth caps, slowing down the backhaul segment of the network, and as residential providers are mostly download, some purchase transit from their upstreams in an symmetric fashion. This post is really just to prompt discussion if people think there is anything to actually worry about, or there are other implications that I've not really thought of yet. …Skeeve -- Skeeve Stevens, CEO - eintellego Pty Ltd - The Networking Specialists ske...@eintellego.netmailto:ske...@eintellego.net ; www.eintellego.net Phone: 1300 753 383 ; Fax: (+612) 8572 9954 Cell +61 (0)414 753 383 ; skype://skeeve facebook.com/eintellego or eintell...@facebook.commailto:eintell...@facebook.com twitter.com/networkceoau ; www.linkedin.com/in/skeeve PO Box 7726, Baulkham Hills, NSW 1755 Australia -- eintellego - The Experts that the Experts call - Juniper - HP Networking - Cisco - Brocade
Re: Do Not Complicate Routing Security with Voodoo Economics
3. I think the discussion on the list so far misses what I see as the central question about the economic assumptions in that paper. The paper assumes that all destinations are equally valuable, which we know is not the case. This implicitly (and perhaps mistakenly?) shifts the balance of power to tier-1 ISPs, whereas in practice, it may be with other ASes (e.g., Google). In practice, ISPs may be willing to spend significant amounts of money to reach certain destinations or content (some destinations are more valuable than others... e.g., Google). If the most valuable destinations deployed S-BGP and made everyone who wanted to connect to them deploy it, that would be more likely to succeed than the approach taken in the paper, I think. Our paper does not assume all destinations are equally valuable. 1) As mentioned in our response to Randy, we weight content providers more heavily (see Section 6.8.1; we ran experiments where the content providers collectively source 10%, 20%, 33% or 50% of Internet traffic). The point here, however, is that the value is subjective. Not all content providers are equally valuable. An access provider will get many complaints from users if they are unable to reach some content providers (e.g. google) while they will get relatively few complaints if they are unable to access others (e.g. hasthelargehadroncolliderdestroyedtheworldyet.com). Owen
RE: IPv6 version of www.qwest.com/www.centurylink.com has been down for 10 days
A Chrome plugin alerted me to the fact that savvis.com has an for www.savvis.com. Unfortunately access to that host over IPv6 is down, too. Frank -Original Message- From: Frank Bulk [mailto:frnk...@iname.com] Sent: Thursday, September 01, 2011 5:03 PM To: nanog@nanog.org Subject: RE: IPv6 version of www.qwest.com/www.centurylink.com has been down for 10 days Charter.com has also remove the quad-A's for www.charter.com. My monitoring system alerted me this afternoon that it couldn't get to the v6 version of their website. Because of DNS caching, I don't know how many hours or days ago it was removed. Frank -Original Message- From: Frank Bulk [mailto:frnk...@iname.com] Sent: Friday, August 19, 2011 11:59 AM To: nanog@nanog.org Subject: RE: IPv6 version of www.qwest.com/www.centurylink.com has been down for 10 days 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 CenturyLink is actively working towards IPv6-enabling their sites again. Frank -Original Message- From: Frank Bulk [mailto:frnk...@iname.com] Sent: Thursday, August 18, 2011 11:14 PM To: nanog@nanog.org Subject: RE: IPv6 version of www.qwest.com/www.centurylink.com has been down for 10 days FYI, the issue is not resolved and I've not heard from either of the companies suggesting that they're working on it. Note their commitment to IPv6 in these releases: http://www.prnewswire.com/news-releases/centurylink-joins-internet-community -in-world-ipv6-day-123089908.html http://news.centurylink.com/index.php?s=43item=2129 Frank -Original Message- From: Matthew Moyle-Croft [mailto:m...@internode.com.au] Sent: Thursday, August 18, 2011 7:08 PM To: Owen DeLong Cc: nanog@nanog.org Subject: Re: IPv6 version of www.qwest.com/www.centurylink.com has been down for 10 days On 19/08/2011, at 4:18 AM, Owen DeLong wrote: It'd really suck for end users to start actively avoiding IPv6 connectivity because it keeps breaking and for organisations that have active records to break peoples connectivity to their resources. +1 -- I'm all for publishing records as everyone knows, but, if you publish records for a consumer facing service, please support and monitor that service with a similar level to what you do for your IPv4 versions of the service. The coming years are going to be difficult enough for end-users without adding unnecessary anti-IPv6 sentiments to the mix. Owen +1 to Owen's comment. I'd also add some more comments: A lot of eyeballs that have v6 right now are the people with a lot of clue. Do you want these people, who'll often be buying or recommending your services to rate your ability to deliver as a fail? Our experience with IPv6 consumer broadband has been that the early adopters are the people who, well, goto IETF meetings, follow standards and ask the bloody hard questions. Even given the Happy Eyeballs (Did Hurricane PAY for it to be abbrievated as HE?? :-) ) most end users prefer IPv6 over IPv4. Deeply this means there is a tendency for v6 traffic to grow and be more important to connectivity than you may imagine. The tipping point for IPv6 traffic being dominant I suspect is going to be a lower threshold of take up than people might expect. Consider this when thinking about the level of thought you give to IPv6 infrastructure and PPS rates. MMC
Re: IPv6 version of www.qwest.com/www.centurylink.com has been down for 10 days
In message 007f01cc6c37$0f4ac060$2de04120$@iname.com, Frank Bulk writes: A Chrome plugin alerted me to the fact that savvis.com has an for www.savvis.com. Unfortunately access to that host over IPv6 is down, too. Frank The fault must be local to you. Works fine from here. Mark -Original Message- From: Frank Bulk [mailto:frnk...@iname.com] Sent: Thursday, September 01, 2011 5:03 PM To: nanog@nanog.org Subject: RE: IPv6 version of www.qwest.com/www.centurylink.com has been down for 10 days Charter.com has also remove the quad-A's for www.charter.com. My monitoring system alerted me this afternoon that it couldn't get to the v6 version of their website. Because of DNS caching, I don't know how many hours or days ago it was removed. Frank -Original Message- From: Frank Bulk [mailto:frnk...@iname.com] Sent: Friday, August 19, 2011 11:59 AM To: nanog@nanog.org Subject: RE: IPv6 version of www.qwest.com/www.centurylink.com has been down for 10 days 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 CenturyLink is actively working towards IPv6-enabling their sites again. Frank -Original Message- From: Frank Bulk [mailto:frnk...@iname.com] Sent: Thursday, August 18, 2011 11:14 PM To: nanog@nanog.org Subject: RE: IPv6 version of www.qwest.com/www.centurylink.com has been down for 10 days FYI, the issue is not resolved and I've not heard from either of the companies suggesting that they're working on it. Note their commitment to IPv6 in these releases: http://www.prnewswire.com/news-releases/centurylink-joins-internet-community -in-world-ipv6-day-123089908.html http://news.centurylink.com/index.php?s=43item=2129 Frank -Original Message- From: Matthew Moyle-Croft [mailto:m...@internode.com.au] Sent: Thursday, August 18, 2011 7:08 PM To: Owen DeLong Cc: nanog@nanog.org Subject: Re: IPv6 version of www.qwest.com/www.centurylink.com has been down for 10 days On 19/08/2011, at 4:18 AM, Owen DeLong wrote: It'd really suck for end users to start actively avoiding IPv6 connectivity because it keeps breaking and for organisations that have active records to break peoples connectivity to their resources. +1 -- I'm all for publishing records as everyone knows, but, if you publish records for a consumer facing service, please support and monitor that service with a similar level to what you do for your IPv4 versions of the service. The coming years are going to be difficult enough for end-users without adding unnecessary anti-IPv6 sentiments to the mix. Owen +1 to Owen's comment. I'd also add some more comments: A lot of eyeballs that have v6 right now are the people with a lot of clue. Do you want these people, who'll often be buying or recommending your services to rate your ability to deliver as a fail? Our experience with IPv6 consumer broadband has been that the early adopters are the people who, well, goto IETF meetings, follow standards and ask the bloody hard questions. Even given the Happy Eyeballs (Did Hurricane PAY for it to be abbrievated as HE?? :-) ) most end users prefer IPv6 over IPv4. Deeply this means there is a tendency for v6 traffic to grow and be more important to connectivity than you may imagine. The tipping point for IPv6 traffic being dominant I suspect is going to be a lower threshold of take up than people might expect. Consider this when thinking about the level of thought you give to IPv6 infrastructure and PPS rates. MMC -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: ma...@isc.org
Re: iCloud - Is it going to hurt access providers?
- Original Message - From: Joel jaeggli joe...@bogus.com having customers that want to use your service is rarely a bad thing. Ask a chief engineer at a national wireless carrier who told his administrative bosses that selling unlimited wireless data was a Pretty Neat Idea if he thinks that's a good generalization to make, Joel. :-) Cheers, -- jra -- Jay R. Ashworth Baylink j...@baylink.com Designer The Things I Think RFC 2100 Ashworth Associates http://baylink.pitas.com 2000 Land Rover DII St Petersburg FL USA http://photo.imageinc.us +1 727 647 1274
Re: IPv6 version of www.qwest.com/www.centurylink.com has been down for 10 days
I'm with Frank on this one: ICMP yes, HTTP/HTTPS no, via native IPv6 (multiple locations). No, wait -- it shows as open from a couple tunnels (both HE SixXS). So it's not consistent. Lovely. Closed from: 2607:ff50::/32 (native) 2607:fcd0::/32 (native) Open from: 2001:1938::/32 (SixXS tunnel) 2001:4978::/32 (SixXS tunnel) 2001:470::/32 (HE tunnel) That gives me a really bad feeling of what might be wrong, but I'll leave it to the professionals. Jima On 2011-09-05 19:57, Frank Bulk wrote: Strange, not for me. nagios:/etc/nagios3# ping6 www.savvis.com PING www.savvis.com(2001:460:100:1000::37) 56 data bytes 64 bytes from 2001:460:100:1000::37: icmp_seq=1 ttl=239 time=55.5 ms 64 bytes from 2001:460:100:1000::37: icmp_seq=2 ttl=239 time=55.4 ms 64 bytes from 2001:460:100:1000::37: icmp_seq=3 ttl=239 time=55.6 ms 64 bytes from 2001:460:100:1000::37: icmp_seq=4 ttl=239 time=55.4 ms ^C --- www.savvis.com ping statistics --- 4 packets transmitted, 4 received, 0% packet loss, time 2999ms rtt min/avg/max/mdev = 55.465/55.517/55.608/0.176 ms nagios:/etc/nagios3# wget -6 www.savvis.com --2011-09-05 20:57:08-- http://www.savvis.com/ Resolving www.savvis.com... 2001:460:100:1000::37 Connecting to www.savvis.com|2001:460:100:1000::37|:80... failed: Connection refused. nagios:/etc/nagios3# Frank -Original Message- From: Mark Andrews [mailto:ma...@isc.org] Sent: Monday, September 05, 2011 8:55 PM To: frnk...@iname.com Cc: nanog@nanog.org Subject: Re: IPv6 version of www.qwest.com/www.centurylink.com has been down for 10 days In message007f01cc6c37$0f4ac060$2de04120$@iname.com, Frank Bulk writes: A Chrome plugin alerted me to the fact that savvis.com has an for www.savvis.com. Unfortunately access to that host over IPv6 is down, too. Frank The fault must be local to you. Works fine from here. Mark -Original Message- From: Frank Bulk [mailto:frnk...@iname.com] Sent: Thursday, September 01, 2011 5:03 PM To: nanog@nanog.org Subject: RE: IPv6 version of www.qwest.com/www.centurylink.com has been down for 10 days Charter.com has also remove the quad-A's for www.charter.com. My monitoring system alerted me this afternoon that it couldn't get to the v6 version of their website. Because of DNS caching, I don't know how many hours or days ago it was removed. Frank -Original Message- From: Frank Bulk [mailto:frnk...@iname.com] Sent: Friday, August 19, 2011 11:59 AM To: nanog@nanog.org Subject: RE: IPv6 version of www.qwest.com/www.centurylink.com has been down for 10 days 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 CenturyLink is actively working towards IPv6-enabling their sites again. Frank -Original Message- From: Frank Bulk [mailto:frnk...@iname.com] Sent: Thursday, August 18, 2011 11:14 PM To: nanog@nanog.org Subject: RE: IPv6 version of www.qwest.com/www.centurylink.com has been down for 10 days FYI, the issue is not resolved and I've not heard from either of the companies suggesting that they're working on it. Note their commitment to IPv6 in these releases: http://www.prnewswire.com/news-releases/centurylink-joins-internet-community -in-world-ipv6-day-123089908.html http://news.centurylink.com/index.php?s=43item=2129 Frank -Original Message- From: Matthew Moyle-Croft [mailto:m...@internode.com.au] Sent: Thursday, August 18, 2011 7:08 PM To: Owen DeLong Cc: nanog@nanog.org Subject: Re: IPv6 version of www.qwest.com/www.centurylink.com has been down for 10 days On 19/08/2011, at 4:18 AM, Owen DeLong wrote: It'd really suck for end users to start actively avoiding IPv6 connectivity because it keeps breaking and for organisations that have active records to break peoples connectivity to their resources. +1 -- I'm all for publishing records as everyone knows, but, if you publish records for a consumer facing service, please support and monitor that service with a similar level to what you do for your IPv4 versions of the service. The coming years are going to be difficult enough for end-users without adding unnecessary anti-IPv6 sentiments to the mix. Owen +1 to Owen's comment. I'd also add some more comments: A lot of eyeballs that have v6 right now are the people with a lot of clue. Do you want these people, who'll often be buying or recommending your services to rate your ability to deliver as a fail? Our experience with IPv6 consumer broadband has been that the early adopters are the people who, well, goto IETF meetings, follow standards and ask the bloody hard questions. Even given the Happy Eyeballs (Did Hurricane PAY for it to be abbrievated as HE?? :-) ) most end users prefer IPv6 over IPv4. Deeply this means there is a tendency for v6 traffic to grow and be more important to
Re: IPv6 version of www.qwest.com/www.centurylink.com has been down for 10 days
On Mon, 5 Sep 2011, Jima wrote: I'm with Frank on this one: ICMP yes, HTTP/HTTPS no, via native IPv6 (multiple locations). No, wait -- it shows as open from a couple tunnels (both HE SixXS). So it's not consistent. Lovely. $ telnet -6 www.savvis.com 80 Trying 2001:460:100:1000::37... telnet: Unable to connect to remote host: Connection refused I checked, it's a TCP RST packet, not ICMP unreachable. This is from native IPv6. -- Mikael Abrahamssonemail: swm...@swm.pp.se
