Re: Wacky Weekend: The '.secure' gTLD
I think this is an interesting concept, but i don't know how well it will hold up in the long run. All the initial verification and continuous scanning will no doubtingly give the .secure TLD a high cost relative to other TLD's. Right. But your high cost is relative to dime-a-dozen vanity domains and/or domains for small/tiny businesses. That's not their target market. How much would it be worth to a bank if they could keep a few of their customers from being scammed? How much would it be worth to an ISP if they could keep a few of their customers from being phished? For starters, just consider the support costs. Here is a note from a different context that says it only costs $99 for Verisign to certify you to sign secure-boot stuff for Windows 8, so I think that's the right ballpark. http://mjg59.dreamwidth.org/12368.html I'm assuming that the hard part is the initial verification, not the ongoing monitoring that can be automated. YMMV. I might be all wet. ... -- These are my opinions. I hate spam.
Re: HE.net BGP origin attribute rewriting
On 05/31/2012 07:06 PM, Saku Ytti wrote: On (2012-05-31 08:46 -0700), David Barak wrote: On what precisely do you base the idea that a mandatory transitive attribute of a BGP prefix is a purely advisory flag which has no real meaning? I encourage you to reconsider that opinion - it's actually a useful attribute, much the way that MED is a useful attribute. Many providers re-write MED, and apparently some re-write ORIGIN. Neither of those is network abuse - it's more accurately described as network routing policy. As has been stated here before: your network, your rules. When provider rewrites MED, they do it, because they don't want peer to cause them to cold-potato, to which they may have compelling reason. Then some clever people realise they forgot to rewrite origin, working around the implicit agreement you had with them. You CAN rewrite MED, as stated in RFC 4271, section 5.1.4 - but you SHOULD NOT change origin attribute, as stated in section 5.1.1. So, in terms of rewriting, MED is not comparable to origin. I think RFC 4271 (http://tools.ietf.org/html/rfc4271) is very clear here. Back to the standard, why condone it's violation? Yes, statement about origin is here since January 2006 - older RFC 1771 didn't contain similar rule. But 6 years after publishing I think everyone had enough time to implement this correctly. I still think, that professionals shoult follow RFC and not insert their own creativity to places, where's not expected - just because they decide that as a cool idea. For local routing policy - there're still lot of knobs, which can be used internally (typically MED, LOCPREF) to enforce expected policy and there's technically no reason to change origin. -- Daniel
Re: HE.net BGP origin attribute rewriting
On (2012-06-01 10:19 +0200), Daniel Suchy wrote: I think RFC 4271 (http://tools.ietf.org/html/rfc4271) is very clear here. Back to the standard, why condone it's violation? Yes, statement It's extremely hard to find RFC which does not contain incorrect information or practically undeployable data. Many things if reading RFC anally are not standard compliant, like no one does IPv6 in the world and no one does MPLS VPNs etc. I'm repeating myself, but if you reset MED, you do it because you have reason why you do not allow peer to force you to cold-potato. There is little point in resetting MED and not resetting origin, as what you tried to stop from occurring still occurs. -- ++ytti
Re: The Tubes
for those who want to read or download, here are some easier links non mobile link: http://www.npr.org/2012/05/31/153701673/the-internet-a-series-of-tubes-and-then-some direct mp3: http://npr.vo.llnwd.net/kip0/kip0/_pxn=0+_pxK=17273+_pxE=mp3/anon.npr-mp3/npr/fa/2012/05/20120531_fa_01.mp3?orgId=1topicId=1033dl=1 On Fri, Jun 1, 2012 at 1:44 AM, Anton Kapela tkap...@gmail.com wrote: All, Andrew Blum was interviewed on NPR's Fresh Air this week -- and gets a lot right about the Tubes we built. FYI, because your boss will be asking you about it: http://m.npr.org/story/153701673?url=/2012/05/31/153701673/the-internet-a-series-of-tubes-and-then-some -Tk
Accuracy of RFCs (was: Re: HE.net BGP origin attribute rewriting)
On Jun 1, 2012, at 4:28 AM, Saku Ytti wrote: It's extremely hard to find RFC which does not contain incorrect information or practically undeployable data. Actual errors in RFC's (typos, incorrect references, etc.) - http://www.rfc-editor.org/errata.php Differing views regarding RFC subject material; feel free to work with others of similar to write up your perspective - http://www.rfc-editor.org/rfc/rfc2223.txt The RFC series is an Internet-wide community effort. Thanks! /John
Re: Wacky Weekend: The '.secure' gTLD
On 5/31/12 10:52 PM, John Levine wrote: What will drive the price up is the lawsuits that come out of the woodwork when they start trying to enforce their provisions. What? I have already printed my letterhead! What do you mean my busted DKIM service is a problem? History suggests that the problem will be the opposite. They will find that the number of registrations is an order of magnitude less than their worst case estimate (a problem that every domain added in the past decade has had), and they will make the rules ever looser to try to gather more registrations and appease their financial backers until it's yet another meaningless generic TLD. agree. For concrete examples, see what happened to .AERO, .TRAVEL, .PRO, and start with .biz as its re-purposing occurred first. of course the race to the bottom of first regular SSL certificates, and now green bar certificates. What might be useful would be .BANK, with both security rules and limited registrations to actual banks. Identifying banks is relatively* easy, since you can use the lists of entities that national bank regulators regulate. agree. proposed by core. opposed by aba. R's, John * - I said relatively, not absolutely. even within the financial services industry, useful taxonomies exist, e.g., ethical banks, islamic banks, depositor owned cooperative banks, ... again, proposed by core. opposed by aba. and you _were_ on the high security generic top-level domain working group where you pushed for anti-spamdom and i for forms of more secure banking. -e
RE: Comcast IPv6 Update
Jason, I remembered this post and decided to check on the status of this for World Ipv6 day coming up in on the 5th of this month and so I called Comcast bussiness support... what a nightmare... the first guy told me that I already have static IP address so why do I need Ipv6 addresses? Then he told me that I can still surf the Internet with Ipv4 addresses and I don't need Ipv6 addresses. I asked to speak to someone who knows more about the Ipv6 rollout he then told me that there is nothing to know. I tried to get him to escalate it as you suggested below but he refused telling me that a request for Ipv6 addresses is not a valid technical reason to escalate. He did offer to let me speak to his supervisor. His supervisor wasn't much better. I explained to him how I have been following things on comcast6.net and with Ipv6 day coming up I thought maybe there had been somekind of forward progress on deployment and could he at least point me in the right direction for someone to talk to about it. He then told me that there is no such person and that if there was such a person that Comcast's Ipv6 rollout plans and locations are proprietary information not to revealed to customers like me. I referenced NANOG and the below post and was told first that how do I know that person is actually a Comcast employee? I guess besides the addresses from you guys @cable.comcast.com I don't know for sure that you guys are actually Comcast employees I just asume that you are who you say you are. For the record I don't doubt that you guys work for Comcast but then the supervisor tells me that even IF the people I referenced DO work for Comcast that they are in violation of company policy for speaking in a public forum and claiming to work for Comcast... Wow... I just wanted some info on deployment scheduling and possilbe timelines for getting Ipv6 and I get all that. Gotta say they could really do better in the customer service dept. I wonder if you guys have any more info on this or can at least point me in the right direction... like I said I already tried Comcast Business Support with the above results... so I guess if you can help find out this before World Ipv6 day so that I could participate that would be ideal... I wonder if anyone else has tried getting this info on the list with better results? - Jimmy -Original Message- From: Livingood, Jason [mailto:jason_living...@cable.comcast.com] Sent: Wednesday, November 09, 2011 8:58 AM To: Blake T. Pfankuch; Brzozowski, John; NANOG Subject: Re: Comcast IPv6 Update On 11/9/11 11:54 AM, Blake T. Pfankuch bl...@pfankuch.me wrote: This appears directed at the Home market. Any word on the Business Class market even as a /128? Business Class is coming later. It won't hurt to contact the Business Class sales number and ask about IPv6 (and tell them to escalate it) - it all helps get us internal support and buy in. It is definitely on our radar though. - Jason
Re: Comcast IPv6 Update
My understanding is that Comcast only does IPv6 on business customers that are on their backbone network, not those on their docsis network. If you have BGP or fiber with 7922 you should be able to get IPv6. - Jared On Jun 1, 2012, at 9:51 AM, Jimmy Sadri wrote: Wow... I just wanted some info on deployment scheduling and possilbe timelines for getting Ipv6 and I get all that. Gotta say they could really do better in the customer service dept. I wonder if you guys have any more info on this or can at least point me in the right direction... like I said I already tried Comcast Business Support with the above results... so I guess if you can help find out this before World Ipv6 day so that I could participate that would be ideal... I wonder if anyone else has tried getting this info on the list with better results?
Re: BGP ORF in practice
On Thu, May 31, 2012 at 10:59 AM, Rob Shakir r...@rob.sh wrote: It has some potential to be difficult to manage where implementations begin to experience complexities in building UPDATE message replication groups (where peers have a dynamic advertisement (egress) policy due to ORF, then this may mean that the number of peers with common UPDATE policies reduces, and hence concepts like policy-driven UPDATE groups become less efficient). This may impact the scaling of your BGP speakers in ways that are not easy to model - and hence may be undesirable on PE/border devices where control-plane CPU is a concern. Makes sense - ORF would reduce the net amount of processing required, but puts more of it on the advertising side. In an inter-domain context, I have seen some discussion of ORF as a means by which an L3VPN customer may choose to receive only a subset of their routing information at particular low feature sites - but the inter-operability issues mentioned above resulted in this not being deployed. Do you have a similar deployment case? My deployment case is as an end user of multiple ISPs. At previous jobs (at service providers) I got used to the flexibility provided by multiple full tables, but at this job I don't have the budget for hardware that's really designed to handle that. Without ORF, my choices are: 1.) default prefixes only Way too little control for my taste. I'm stuck either letting it pick one best 0/0 to use or tweaking the config so that I can do ECMP (which freaks out support staff when their traceroute bounces around). 2.) default + subset (such as customer routes) Better than #1, but less flexible if I want to steer a prefix anywhere other than to a service provider which is advertising it to me. 3.) default + full Flexible in that I can filter what I accept and still rely on the 0/0 prefix for full reachability. The control plane on my routers can handle that many prefixes in memory, but it bogs them down a bit and I have to be careful of how many prefixes I let into the forwarding table. Thanks for the input. It sounds like ORF could be viable, but only if the service provider is amenable and the equipment is compatible. :w
Re: Comcast IPv6 Update
Jimmy, Trust me, I work for Comcast and run the IPv6 program. This has been the case for nearly 7 years. We can take some of the items below off list. We have launched IPv6 for residential broadband at this time. Commercial DOCSIS support is later this year. We can do two things. Get you a residential trial kit so you can have IPv6 for W6L and make sure I have your information for when we start trials for commercial DOCSIS support for IPv6. John = John Jason Brzozowski Comcast Cable m) +1-609-377-6594 e) mailto:john_brzozow...@cable.comcast.com o) +1-484-962-0060 w) http://www.comcast6.net = -Original Message- From: Jimmy Sadri jim...@myesn.com Date: Friday, June 1, 2012 9:51 AM To: Jason Livingood jason_living...@cable.comcast.com, 'Blake T. Pfankuch' bl...@pfankuch.me, John Jason Brzozowski john_brzozow...@cable.comcast.com, NANOG nanog@nanog.org Subject: RE: Comcast IPv6 Update Jason, I remembered this post and decided to check on the status of this for World Ipv6 day coming up in on the 5th of this month and so I called Comcast bussiness support... what a nightmare... the first guy told me that I already have static IP address so why do I need Ipv6 addresses? Then he told me that I can still surf the Internet with Ipv4 addresses and I don't need Ipv6 addresses. I asked to speak to someone who knows more about the Ipv6 rollout he then told me that there is nothing to know. I tried to get him to escalate it as you suggested below but he refused telling me that a request for Ipv6 addresses is not a valid technical reason to escalate. He did offer to let me speak to his supervisor. His supervisor wasn't much better. I explained to him how I have been following things on comcast6.net and with Ipv6 day coming up I thought maybe there had been somekind of forward progress on deployment and could he at least point me in the right direction for someone to talk to about it. He then told me that there is no such person and that if there was such a person that Comcast's Ipv6 rollout plans and locations are proprietary information not to revealed to customers like me. I referenced NANOG and the below post and was told first that how do I know that person is actually a Comcast employee? I guess besides the addresses from you guys @cable.comcast.com I don't know for sure that you guys are actually Comcast employees I just asume that you are who you say you are. For the record I don't doubt that you guys work for Comcast but then the supervisor tells me that even IF the people I referenced DO work for Comcast that they are in violation of company policy for speaking in a public forum and claiming to work for Comcast... Wow... I just wanted some info on deployment scheduling and possilbe timelines for getting Ipv6 and I get all that. Gotta say they could really do better in the customer service dept. I wonder if you guys have any more info on this or can at least point me in the right direction... like I said I already tried Comcast Business Support with the above results... so I guess if you can help find out this before World Ipv6 day so that I could participate that would be ideal... I wonder if anyone else has tried getting this info on the list with better results? - Jimmy -Original Message- From: Livingood, Jason [mailto:jason_living...@cable.comcast.com] Sent: Wednesday, November 09, 2011 8:58 AM To: Blake T. Pfankuch; Brzozowski, John; NANOG Subject: Re: Comcast IPv6 Update On 11/9/11 11:54 AM, Blake T. Pfankuch bl...@pfankuch.me wrote: This appears directed at the Home market. Any word on the Business Class market even as a /128? Business Class is coming later. It won't hurt to contact the Business Class sales number and ask about IPv6 (and tell them to escalate it) - it all helps get us internal support and buy in. It is definitely on our radar though. - Jason
Re: Comcast IPv6 Update
Commercial DOCSIS is later this year. Commercial fiber can be supported now. John = John Jason Brzozowski Comcast Cable m) +1-609-377-6594 e) mailto:john_brzozow...@cable.comcast.com o) +1-484-962-0060 w) http://www.comcast6.net = -Original Message- From: Jared Mauch ja...@puck.nether.net Date: Friday, June 1, 2012 9:56 AM To: Jimmy Sadri jim...@myesn.com Cc: Jason Livingood jason_living...@cable.comcast.com, 'Blake T. Pfankuch' bl...@pfankuch.me, John Jason Brzozowski john_brzozow...@cable.comcast.com, NANOG nanog@nanog.org Subject: Re: Comcast IPv6 Update My understanding is that Comcast only does IPv6 on business customers that are on their backbone network, not those on their docsis network. If you have BGP or fiber with 7922 you should be able to get IPv6. - Jared On Jun 1, 2012, at 9:51 AM, Jimmy Sadri wrote: Wow... I just wanted some info on deployment scheduling and possilbe timelines for getting Ipv6 and I get all that. Gotta say they could really do better in the customer service dept. I wonder if you guys have any more info on this or can at least point me in the right direction... like I said I already tried Comcast Business Support with the above results... so I guess if you can help find out this before World Ipv6 day so that I could participate that would be ideal... I wonder if anyone else has tried getting this info on the list with better results?
Number of providers
Based on feedback we have received at http://as-rank.caida.org/ we are in the process of updating our AS relationship inference algorithm. We're interested to know how many providers different ASes have based on their size. We assume that it changes with size of the AS, e.g. Tier-1 have zero. We would appreciate it if anyone who is willing to provide us with their AS number and the number of their providers, would email this information to m...@caida.org. Matthew Luckie CAIDA. p.s. It would be great if you could also tell us who your providers are.
Re: HE.net BGP origin attribute rewriting
On Fri, Jun 01, 2012 at 10:19:16AM +0200, Daniel Suchy wrote: On 05/31/2012 07:06 PM, Saku Ytti wrote: On (2012-05-31 08:46 -0700), David Barak wrote: On what precisely do you base the idea that a mandatory transitive attribute of a BGP prefix is a purely advisory flag which has no real meaning? I encourage you to reconsider that opinion - it's actually a useful attribute, much the way that MED is a useful attribute. Many providers re-write MED, and apparently some re-write ORIGIN. Neither of those is network abuse - it's more accurately described as network routing policy. As has been stated here before: your network, your rules. When provider rewrites MED, they do it, because they don't want peer to cause them to cold-potato, to which they may have compelling reason. Then some clever people realize they forgot to rewrite origin, working around the implicit agreement you had with them. You CAN rewrite MED, as stated in RFC 4271, section 5.1.4 - but you SHOULD NOT change origin attribute, as stated in section 5.1.1. So, in terms of rewriting, MED is not comparable to origin. I think RFC 4271 (http://tools.ietf.org/html/rfc4271) is very clear here. Back to the standard, why condone it's violation? Yes, statement about origin is here since January 2006 - older RFC 1771 didn't contain similar rule. But 6 years after publishing I think everyone had enough time to implement this correctly. Please remind yourself the standard language from rfc 2119. SHOULD NOT is not in the same ball park as MUST NOT: 4. SHOULD NOT This phrase, or the phrase NOT RECOMMENDED mean that there may exist valid reasons in particular circumstances when the particular behavior is acceptable or even useful, but the full implications should be understood and the case carefully weighed before implementing any behavior described with this label. I still think, that professionals shoult follow RFC and not insert their own creativity to places, where's not expected - just because they decide that as a cool idea. For local routing policy - there're still lot of knobs, which can be used internally (typically MED, LOCPREF) to enforce expected policy and there's technically no reason to change origin. You clearly did not read the previous posts involving actual historical evidence [and apparently ongoing] of remote networks attempting action at a distance knowing that many overlook this part of the decision tree. Preventing your company from bleeding money or degrading performance at whim of remote parties certainly is cool but also just good business and proper network hygiene. Cheers, Joe -- RSUC / GweepNet / Spunk / FnB / Usenix / SAGE / NewNOG
Re: HE.net BGP origin attribute rewriting
On 06/01/2012 07:38 PM, Joe Provo wrote: You clearly did not read the previous posts involving actual historical evidence [and apparently ongoing] of remote networks attempting action at a distance knowing that many overlook this part of the decision tree. Preventing your company from bleeding money or degrading performance at whim of remote parties certainly is cool but also just good business and proper network hygiene. By overwriting origin field, there's no warranty that someone improves performance at all - it's just imagination. In extreme cases, performance can be degraded when someone in the middle plays with origin field and doesn't know reasons, why originating network uses something else than IGP origin. In RFC 2119 words, full implications were not understanded - when this overwriting is done generally. Also, there must be some historical reason, why origin should not be rewritten (this changed in January 2006). For internal reasons within the network operator still haves enough knobs to enforce own policy (by setting localpref, med on his network). Daniel
Re: Comcast IPv6 Update
On 6/1/12 7:04 AM, Brzozowski, John wrote: Jimmy, Trust me, I work for Comcast and run the IPv6 program. This has been the case for nearly 7 years. We can take some of the items below off list. We have launched IPv6 for residential broadband at this time. Commercial DOCSIS support is later this year. We can do two things. Get you a residential trial kit so you can have IPv6 for W6L and make sure I have your information for when we start trials for commercial DOCSIS support for IPv6. Forgive me if this is a stupid question since I've never been a cable guy, but what's physical difference between residential and commercial coax? ~Seth
1310nm optics over Corning LEAF G.655?
Anyone run 1000BASE-LX/10GBASE-LR 1310nm optics over a ~10km Corning LEAF G.655 span? I understand this fiber is not optimized for such usage, but what is the real-world behaviour? I'm having a hard time finding hard data. (Normal optics will be 1550nm and DWDM over ~40-100km spans.) -- Tim:
RE: 1310nm optics over Corning LEAF G.655?
Tim Yes we have built several links with the 1310nm devices on Corning LEAF. One span distance was 14 KM. Can we offer you a quote on optics and installation support? Thanks, Kevin L. Karch Network Specialist Direct: 847-833-8810 Fax: 847-985-5550 Email: kevinka...@vackinc.com Web: www.vackinc.com The Optical Network Specialists -Original Message- From: Tim Durack [mailto:tdur...@gmail.com] Sent: Friday, June 01, 2012 1:19 PM To: nanog@nanog.org Subject: 1310nm optics over Corning LEAF G.655? Anyone run 1000BASE-LX/10GBASE-LR 1310nm optics over a ~10km Corning LEAF G.655 span? I understand this fiber is not optimized for such usage, but what is the real-world behaviour? I'm having a hard time finding hard data. (Normal optics will be 1550nm and DWDM over ~40-100km spans.) -- Tim: - No virus found in this message. Checked by AVG - www.avg.com Version: 2012.0.2178 / Virus Database: 2425/5038 - Release Date: 06/01/12
Re: 1310nm optics over Corning LEAF G.655?
On Fri, Jun 1, 2012 at 2:30 PM, Kevin L. Karch kevinka...@vackinc.com wrote: Tim Yes we have built several links with the 1310nm devices on Corning LEAF. One span distance was 14 KM. Can we offer you a quote on optics and installation support? That's a kind offer, but we are quite well setup :-) Just looking for field experience. 14km with standard 1310nm optics? No issues with the cutoff wavelength being 1310nm? GigE or 10GigE? -- Tim:
Re: Comcast IPv6 Update
On Fri, Jun 1, 2012 at 2:06 PM, Seth Mattinen se...@rollernet.us wrote: Forgive me if this is a stupid question since I've never been a cable guy, but what's physical difference between residential and commercial coax? Not much, as far as I can tell. I'm a commercial (Business Class in Comcast's terminology) coax customer; the CPE is just plugged into the cable outlet in my apartment. Comcast requires you to use the CPE they supply if you want a static IP up through a /28 on commercial coax, which is kind of a shame. (Also, a /28 seems to be the largest block they will give you over commercial coax.) Their CPE announces your address space into Comcast's network with RIPv2, and presumably they don't wish to share the RIP credentials with small customers. In the past, the admin (mso) passwords were the same on all of their commercial coax CPE so you could tinker if desired, but that is no longer the case. Some people have speculated that there are different QAMs (frequencies) for commercial vs residential customers, but I have not seen any indication that that is the case. Finally, there is no 250 GB cap on commercial coax service, for now. (Not that that's a physical difference.) -Rusty
Re: rpki vs. secure dns?
Another difference between RPKI and ROVER which hasn't come up much: RPKI incorporates a lot of pre-existing machinery from X.509 et al. This drags in some tedious detail which makes people's eyes cross, but it gives us some tools which simply aren't available in DNS at present. In particular, X.509's CRL mechanism combined with the way that RPKI uses CMS messages with single-use EE certificates means that in RPKI we have a way to revoke individual objects (eg, ROAs) at will. DNSSEC only just barely has revocation at all, and that only for DNSKEYs. The nearest equivalent to per-object revocation one could do in DNSSEC would be either: - generate a new ZSK, re-sign everything in the zone with the new ZSK except for the RRsets you want to get rid of, and revoke the old ZSK, or - keep as many distinct ZSKs in the zone as you intend to have distinctly revocable groups of objects in the zone, and make sure you sign the right objects with the right ZSKs. Neither of these solutions is very good: the first may involve re-signing a lot of data every time you change anything, while the latter is complex and tends to bloat the zone's apex DNSKEY RRset. I suppose a third option would be to make every DNS owner name in the reverse tree be a separate zone. Doesn't seem like an improvement. Summarizing a few other things other people have mentioned: - The normal operating mode with RPKI is to fetch everything rather than do a point query. We've spent the last decade or so making that harder to do with DNS (blocking AXFR/IXFR, using NSEC3 instead of NSEC, etc). This makes it fairly difficult to know in advance what queries one should be asking ROVER (as Paul Vixie puts it, ROVER isn't a catalogue). When I pressed the ROVER folks about this at the Paris IETF meeting, they mumbled something about maybe walking the IRR or other external databases as a way of knowing what DNS queries to issue. - Circular dependencies are a problem. Helical dependencies can be made to work, but this says that one probably should not be depending on routing to make a point query to make decisions about routing. If you look at the architecture of the existing RPKI validators (well, mine and BBN's, anyway, not sure about RIPE's but suspect they took the same approach), we've gone to some trouble to make sure that the validator will continue to work across network outages as long as the collected data haven't expired or been revoked. In theory one could do the same thing with bulk transfers of DNS (whether AXFR/IXFR or NSEC walking, if they worked) but it would not work well with point queries. - ROVER gives us no traction on path validation (BGPSEC), it's limited to origin validation. RPKI can certify both prefixes and ASNs, which gives it the basics needed to support path validation as well as origin validation. ASNs have no hierarchical structure, thus would be a very poor match for encoding as DNS names. - Some of the DNS aspects of ROVER are a little strange. In particular, as currently specified ROVER requires the relying party to pay attention to DNS zone cuts, which is not normal in DNS (the basic DNS model since RFC 883 has been that zones are something for the zone administrator to worry about, resolvers mostly just see a tree of RRsets). ROVER requires the relying party to check for the same data in multiple zones and pay close attention to zone cuts. While it is certainly possible to do all this, it is not a matter of issuing a simple DNS query and you're done. DNS caching effects can also complicate matters here if the zone structure is changing: think about what happens if you have cached responses to some (but not all) of the queries you need to make to figure out whether to allow a more specific route punched out of a larger prefix block. - The reuse of existing infrastructure argument for ROVER is somewhat disingenuous -- it's only partial reuse of existing infrastructure. ROVER's new encoding of prefixes as DNS names means that a lot of new stuff would need to be deployed, and attempting to be backwards compatible with the existing DNS reverse tree adds some complexity to ROVER's architecture (conflicting data for same prefix can appear in multiple zones, relying party has to sort this out, yum). As far as I can tell, ROVER doesn't solve any of the hard problems in RPKI. It's a different encoding of a partial subset of the data, with some of the features removed.
Re: Comcast IPv6 Update
On Fri, Jun 01, 2012 at 11:06:24AM -0700, Seth Mattinen wrote: On 6/1/12 7:04 AM, Brzozowski, John wrote: Jimmy, Trust me, I work for Comcast and run the IPv6 program. This has been the case for nearly 7 years. We can take some of the items below off list. We have launched IPv6 for residential broadband at this time. Commercial DOCSIS support is later this year. We can do two things. Get you a residential trial kit so you can have IPv6 for W6L and make sure I have your information for when we start trials for commercial DOCSIS support for IPv6. Forgive me if this is a stupid question since I've never been a cable guy, but what's physical difference between residential and commercial coax? Usually these are terminated on a different CMTS and may use different frequencies allocated. From a business side, there is a higher SLA afforded to the users, including phone notification of planned outages, etc that would happen. - Jared -- Jared Mauch | pgp key available via finger from ja...@puck.nether.net clue++; | http://puck.nether.net/~jared/ My statements are only mine.
Re: Comcast IPv6 Update
On 6/1/2012 11:06, Seth Mattinen wrote: On 6/1/12 7:04 AM, Brzozowski, John wrote: Jimmy, Trust me, I work for Comcast and run the IPv6 program. This has been the case for nearly 7 years. We can take some of the items below off list. We have launched IPv6 for residential broadband at this time. Commercial DOCSIS support is later this year. We can do two things. Get you a residential trial kit so you can have IPv6 for W6L and make sure I have your information for when we start trials for commercial DOCSIS support for IPv6. Forgive me if this is a stupid question since I've never been a cable guy, but what's physical difference between residential and commercial coax? ~Seth I'm a Comcast biz customer, mostly so I can have static IPs. I believe the main differences are that biz class has a different group of people supporting it and provisioning it. They also use different CPE. Probably also use different VLANs and such past the head end. But for biz class customers on cable, it uses the same underlying infrastructure as residential. I'm mostly speculating here, but I'd think a big hurdle for getting IPv6 service on biz class is in coming up with the support/provisioning/logistics infrastructure to support biz customers with IPv6. The residential customers have less control over the CPE than business class, likely making it easier for comcast to make changes for residential service. Comcast can update the CPE image, start running DHCPv6, and voila. But biz customers routers are somewhat configurable, and many biz class customers run their own routers/firewalls behind the comcast CPE (as do some residential customers also, of course), likely making things more complicated. I'd speculate that all the technical pieces are there to do it, but the logistical/support/management pieces probably aren't ready yet. Obviously, only the Comcast guys on here (John and Jason) know the whole story. But I'm patiently waiting for my native v6! It'll happen eventually. :-)
Re: Comcast IPv6 Update
On 6/1/2012 12:21, Jared Mauch wrote: On Fri, Jun 01, 2012 at 11:06:24AM -0700, Seth Mattinen wrote: On 6/1/12 7:04 AM, Brzozowski, John wrote: Jimmy, Trust me, I work for Comcast and run the IPv6 program. This has been the case for nearly 7 years. We can take some of the items below off list. We have launched IPv6 for residential broadband at this time. Commercial DOCSIS support is later this year. We can do two things. Get you a residential trial kit so you can have IPv6 for W6L and make sure I have your information for when we start trials for commercial DOCSIS support for IPv6. Forgive me if this is a stupid question since I've never been a cable guy, but what's physical difference between residential and commercial coax? Usually these are terminated on a different CMTS and may use different frequencies allocated. From a business side, there is a higher SLA afforded to the users, including phone notification of planned outages, etc that would happen. - Jared Ah I didn't know they even used separate CMTS for the biz customers.
NYC World IPv6 Launch event
As for IPv6 Day last year, when it went amazingly well, ISOC-NY is organizing a chat + booze-up to mark the IPv6 Launch next Wednesday Jun 6 2012. Hopefully by 7pm initial kinks will have been well ironed out and everyone will be free to attend.. *What*: World IPv6 Launch Discussion and Celebration. *When*: Wed. June 6, 2012 - 7pm-8.30pm *Where*: Courant Institute NYU, Rm 201, 251 Mercer St. NYC *Who*: Free. Public welcome, especially network admins! *Hashtags*: #v6launch http://twitter.com/#!/search?q=%23v6launch ; #ipv6http://twitter.com/#!/search?q=%23ipv6 *RSVP*: emailhttps://mail.google.com/mail/?view=cmfs=1tf=1to=ad...@isoc-ny.orgsu=IPv6Launch | facebook https://www.facebook.com/events/309316619152539/ | meetuphttp://www.meetup.com/isoc-ny/events/67318542/ More info: http://isoc-ny.org/p2/?p=3526 -- --- Joly MacFie 218 565 9365 Skype:punkcast WWWhatsup NYC - http://wwwhatsup.com http://pinstand.com - http://punkcast.com VP (Admin) - ISOC-NY - http://isoc-ny.org -- -
BGP Update Report
BGP Update Report Interval: 24-May-12 -to- 31-May-12 (7 days) Observation Point: BGP Peering with AS131072 TOP 20 Unstable Origin AS Rank ASNUpds % Upds/PfxAS-Name 1 - AS383192192 8.5%1779.6 -- AFCONC-BLOCK1-AS - 754th Electronic Systems Group 2 - AS845291007 4.0% 89.9 -- TE-AS TE-AS 3 - AS840260332 2.6% 47.7 -- CORBINA-AS OJSC Vimpelcom 4 - AS982954914 2.4% 62.4 -- BSNL-NIB National Internet Backbone 5 - AS19647 47156 2.1%9431.2 -- HPOD20001 - Hewlett-Packard Operation Division 6 - AS38142 33384 1.5%2086.5 -- UNAIR-AS-ID Universitas Airlangga 7 - AS12479 27393 1.2% 351.2 -- UNI2-AS France Telecom Espana SA 8 - AS35994 26629 1.2% 951.0 -- AKAMAI-AS - Akamai Technologies, Inc. 9 - AS790825800 1.1% 344.0 -- Comsat Argentina S.A. 10 - AS580023102 1.0% 86.2 -- DNIC-ASBLK-05800-06055 - DoD Network Information Center 11 - AS41661 21899 1.0% 61.7 -- ERTH-CHEL-AS CJSC ER-Telecom Holding 12 - AS125720680 0.9% 108.8 -- TELE2 13 - AS13118 20040 0.9% 417.5 -- ASN-YARTELECOM OJSC Rostelecom 14 - AS28306 19103 0.8%2122.6 -- TC Net Informática e Telecomunicações LTDA 15 - AS10455 18155 0.8%2017.2 -- LUCENT-CIO - Lucent Technologies Inc. 16 - AS17813 17513 0.8% 142.4 -- MTNL-AP Mahanagar Telephone Nigam Ltd. 17 - AS354916826 0.7% 168.3 -- GBLX Global Crossing Ltd. 18 - AS36856 16593 0.7%8296.5 -- MOZILLA-CORP - Mozilla Corporation 19 - AS25543 15053 0.7% 273.7 -- FasoNet-AS 20 - AS24560 13716 0.6% 19.8 -- AIRTELBROADBAND-AS-AP Bharti Airtel Ltd., Telemedia Services TOP 20 Unstable Origin AS (Updates per announced prefix) Rank ASNUpds % Upds/PfxAS-Name 1 - AS19647 47156 2.1%9431.2 -- HPOD20001 - Hewlett-Packard Operation Division 2 - AS36856 16593 0.7%8296.5 -- MOZILLA-CORP - Mozilla Corporation 3 - AS447987750 0.3%7750.0 -- PERVOMAYSK-AS PP SKS-Pervomaysk 4 - AS32638 0.1% 683.0 -- PRED-AS PRED-Telecom OOO 5 - AS32528 12095 0.5%2419.0 -- ABBOTT Abbot Labs 6 - AS28306 19103 0.8%2122.6 -- TC Net Informática e Telecomunicações LTDA 7 - AS38142 33384 1.5%2086.5 -- UNAIR-AS-ID Universitas Airlangga 8 - AS10455 18155 0.8%2017.2 -- LUCENT-CIO - Lucent Technologies Inc. 9 - AS383192192 8.5%1779.6 -- AFCONC-BLOCK1-AS - 754th Electronic Systems Group 10 - AS556651043 0.1%1043.0 -- STMI-AS-ID PT Sampoerna Telemedia Indonesia 11 - AS35994 26629 1.2% 951.0 -- AKAMAI-AS - Akamai Technologies, Inc. 12 - AS29126 918 0.0% 918.0 -- DATIQ-AS Datiq B.V. 13 - AS16535 890 0.0% 890.0 -- ECHOS-3 - Echostar Holding Purchasing Corporation 14 - AS19318 12159 0.5% 715.2 -- NJIIX-AS-1 - NEW JERSEY INTERNATIONAL INTERNET EXCHANGE LLC 15 - AS53531 672 0.0% 672.0 -- MIDWEST-CARECENTER - Midwest Palliative Hospice CareCenter 16 - AS38857 950 0.0% 475.0 -- ESOFT-TRANSIT-AS-AP e.Soft Technologies Ltd. 17 - AS56616 451 0.0% 451.0 -- SHARIF-AS Tarahan Shabake Sharif LTD 18 - AS25821 450 0.0% 450.0 -- NET-SCNB - Suffolk County National Bank 19 - AS295122199 0.1% 439.8 -- TVK-WROC-AS TVK Tel-Ka Wroclaw 20 - AS48068 435 0.0% 435.0 -- VISONIC Visonic Ltd TOP 20 Unstable Prefixes Rank Prefix Upds % Origin AS -- AS Name 1 - 109.161.64.0/19 19671 0.8% AS13118 -- ASN-YARTELECOM OJSC Rostelecom 2 - 63.245.221.0/24 16573 0.7% AS36856 -- MOZILLA-CORP - Mozilla Corporation 3 - 168.87.176.0/24 14222 0.6% AS19647 -- HPOD20001 - Hewlett-Packard Operation Division 4 - 168.87.128.0/21 14171 0.6% AS19647 -- HPOD20001 - Hewlett-Packard Operation Division 5 - 130.36.34.0/2410737 0.4% AS32528 -- ABBOTT Abbot Labs 6 - 69.31.106.0/23 9520 0.4% AS35994 -- AKAMAI-AS - Akamai Technologies, Inc. 7 - 155.72.152.0/219383 0.4% AS19647 -- HPOD20001 - Hewlett-Packard Operation Division 8 - 155.72.158.0/249376 0.4% AS19647 -- HPOD20001 - Hewlett-Packard Operation Division 9 - 41.43.147.0/24 9035 0.4% AS8452 -- TE-AS TE-AS 10 - 23.2.6.0/238522 0.3% AS35994 -- AKAMAI-AS - Akamai Technologies, Inc. 11 - 23.65.27.0/24 8520 0.3% AS35994 -- AKAMAI-AS - Akamai Technologies, Inc. 12 - 62.36.252.0/22 8022 0.3% AS12479 -- UNI2-AS France Telecom Espana SA 13 - 91.202.212.0/227750 0.3% AS44798 -- PERVOMAYSK-AS PP SKS-Pervomaysk 14 - 62.36.249.0/24 6535 0.3% AS12479 -- UNI2-AS France Telecom Espana SA 15 - 62.36.241.0/24 6218 0.2%
The Cidr Report
This report has been generated at Fri Jun 1 21:12:54 2012 AEST.
The report analyses the BGP Routing Table of AS2.0 router
and generates a report on aggregation potential within the table.
Check http://www.cidr-report.org for a current version of this report.
Recent Table History
Date PrefixesCIDR Agg
25-05-12414357 242094
26-05-1241 242009
27-05-12414372 242171
28-05-12414483 242396
29-05-12414855 242346
30-05-12415000 242304
31-05-12414797 242308
01-06-12415005 242253
AS Summary
41293 Number of ASes in routing system
17231 Number of ASes announcing only one prefix
3411 Largest number of prefixes announced by an AS
AS6389 : BELLSOUTH-NET-BLK - BellSouth.net Inc.
112706016 Largest address span announced by an AS (/32s)
AS4134 : CHINANET-BACKBONE No.31,Jin-rong Street
Aggregation Summary
The algorithm used in this report proposes aggregation only
when there is a precise match using the AS path, so as
to preserve traffic transit policies. Aggregation is also
proposed across non-advertised address space ('holes').
--- 01Jun12 ---
ASnumNetsNow NetsAggr NetGain % Gain Description
Table 415012 242341 17267141.6% All ASes
AS6389 3411 196 321594.3% BELLSOUTH-NET-BLK -
BellSouth.net Inc.
AS7029 3353 1843 151045.0% WINDSTREAM - Windstream
Communications Inc
AS22773 1638 135 150391.8% ASN-CXA-ALL-CCI-22773-RDC -
Cox Communications Inc.
AS4766 2643 1176 146755.5% KIXS-AS-KR Korea Telecom
AS18566 2092 706 138666.3% COVAD - Covad Communications
Co.
AS28573 1896 521 137572.5% NET Servicos de Comunicao S.A.
AS2118 1301 14 128798.9% RELCOM-AS OOO NPO Relcom
AS4323 1575 387 118875.4% TWTC - tw telecom holdings,
inc.
AS10620 1926 760 116660.5% Telmex Colombia S.A.
AS1785 1912 806 110657.8% AS-PAETEC-NET - PaeTec
Communications, Inc.
AS4755 1577 542 103565.6% TATACOMM-AS TATA
Communications formerly VSNL
is Leading ISP
AS7303 1435 448 98768.8% Telecom Argentina S.A.
AS7552 1097 188 90982.9% VIETEL-AS-AP Vietel
Corporation
AS26615 901 32 86996.4% Tim Celular S.A.
AS8151 1490 684 80654.1% Uninet S.A. de C.V.
AS18101 948 159 78983.2% RELIANCE-COMMUNICATIONS-IN
Reliance Communications
Ltd.DAKC MUMBAI
AS17974 1927 1161 76639.8% TELKOMNET-AS2-AP PT
Telekomunikasi Indonesia
AS4808 1105 349 75668.4% CHINA169-BJ CNCGROUP IP
network China169 Beijing
Province Network
AS9394 839 159 68081.0% CRNET CHINA RAILWAY
Internet(CRNET)
AS13977 772 122 65084.2% CTELCO - FAIRPOINT
COMMUNICATIONS, INC.
AS3356 1099 463 63657.9% LEVEL3 Level 3 Communications
AS30036 1420 792 62844.2% MEDIACOM-ENTERPRISE-BUSINESS -
Mediacom Communications Corp
AS17676 692 75 61789.2% GIGAINFRA Softbank BB Corp.
AS22561 1020 419 60158.9% DIGITAL-TELEPORT - Digital
Teleport Inc.
AS19262 997 398 59960.1% VZGNI-TRANSIT - Verizon Online
LLC
AS8452 1369 779 59043.1% TE-AS TE-AS
AS24560 1027 447 58056.5% AIRTELBROADBAND-AS-AP Bharti
Airtel Ltd., Telemedia
Services
AS3549 1002 443 55955.8% GBLX Global Crossing Ltd.
AS22047 583 31 55294.7% VTR BANDA ANCHA S.A.
AS4780 831 283 54865.9% SEEDNET Digital United Inc.
Total 43878145182936066.9% Top 30 total
Possible Bogus Routes
10.86.64.32/30 AS65530 -Private Use AS-
Re: HE.net BGP origin attribute rewriting
On Fri, Jun 01, 2012 at 08:03:50PM +0200, Daniel Suchy wrote: By overwriting origin field, there's no warranty that someone improves performance at all - it's just imagination. In extreme cases, performance can be degraded when someone in the middle plays with origin field and doesn't know reasons, why originating network uses something else than IGP origin. In RFC 2119 words, full implications were not understanded - when this overwriting is done generally. Uh, what part of to prevent remote networks from improperly forcing a cold potato routing behavior on you sounds imaginary? Also, there must be some historical reason, why origin should not be rewritten (this changed in January 2006). For internal reasons within the network operator still haves enough knobs to enforce own policy (by setting localpref, med on his network). Not really, no. Not every RFC is 100% correct, and they're often written by people who are not operators (because operators are too busy running real networks :P). Besides, SHOULD NOT means you probably don't want to do this, unless you have a really good reason, and enforcing such an important point in a peering policy is a pretty good reason. You also clearly don't understand the practical use of localpref. When you're trying to implement a simple and relatively common policy like closest exit routing to a peer with multiple exits, you set the localprefs the same (localpref is usually used to determine WHICH peer you'll be sending to), you set the MEDs the same (if you don't want to artifically select which EXIT to use), AS-PATH lengths are obviously the same if you have multiple exits, and then the next one down is origin code. If you can't reset origin code, you run the risk of a remote network being able to force your network to do something you probably don't want to do (or at least probably wouldn't want to do, if you had any idea what you were doing :P). Please see the previous commentary from Joe Provo, Saku Ytti, etc, they are quite correct. -- Richard A Steenbergen r...@e-gerbil.net http://www.e-gerbil.net/ras GPG Key ID: 0xF8B12CBC (7535 7F59 8204 ED1F CC1C 53AF 4C41 5ECA F8B1 2CBC)
Re: HE.net BGP origin attribute rewriting
On Fri, Jun 01, 2012 at 08:03:50PM +0200, Daniel Suchy wrote: On 06/01/2012 07:38 PM, Joe Provo wrote: You clearly did not read the previous posts involving actual historical evidence [and apparently ongoing] of remote networks attempting action at a distance knowing that many overlook this part of the decision tree. Preventing your company from bleeding money or degrading performance at whim of remote parties certainly is cool but also just good business and proper network hygiene. By overwriting origin field, there's no warranty that someone improves performance at all - it's just imagination. Cost and performance were merely two reasons someone may wish to prevent remote parties from using origin to influence outbound traffic from my network. I can state it is not imagination when I encountered networks doing this in the past for prefixes they were sourcing. To be clear - these were prefixes being sourced by a neighbor who was providing different origin codes on different sessions. Either they were [to Nick Hilliard's point] using different kit and unaware of the differnt implementations or [as evidence bore out] purposefully shifting traffic without arrangement on links that were worse for me and in violation of the agreement we entered into when peering. In extreme cases, performance can be degraded when someone in the middle plays with origin field and doesn't know reasons, why originating network uses something else than IGP origin. The issues that were repeatedly mentioned were not not 'use something other than origin IGP'. Rather, two clear examples were: - a party in the middle adjusting prefixes not of their origin with the express intent of attracting traffic [from paying downstreams] - a directly connected party cost-shifting long-haul carriage for their sourced prefixes without prior arrangement In RFC 2119 words, full implications were not understanded - when this overwriting is done generally. I think you're trying to make sense here but it isn't coming through. You are saying that dealing with someone shifting costs to my network *after8 asking them what they were doing and getting no useful reply is not thinking it through? Also, there must be some historical reason, why origin should not be rewritten (this changed in January 2006). For internal reasons within the network operator still haves enough knobs to enforce own policy (by setting localpref, med on his network). There certainly were historical reasons for treating origin as sacrosanct. Time has marched on and those reasons are now *historical*, hence the quite reasonable updat eto the RFC. You seem to fail to understand that MED comes after origin on the decision tree, and therefore someone can influence traffic carriage without agreement. Cheers, Joe -- RSUC / GweepNet / Spunk / FnB / Usenix / SAGE / NewNOG
