RE: Why do some providers require IPv6 /64 PA space to have public whois?
Actually, requiring a public whois record is the way it always has been, that's only recently changed. I think most folks would agree that, IPv4 /32 :: IPv6 /128 as IPv4 /29 :: IPv6 /64 So, while you are right, that swip'ing a v4 /32 has never been required, I think your analogy of a v6 /64 to a v4 /32 is off. The minimum assignment requiring a swip is also ensconced in RIR policy. If you don't like it, may I suggest you propose policy to change it? RIPE's policy: When an End User has a network using public address space this must be registered separately with the contact details of the End User. Where the End User is an individual rather than an organisation, the contact information of the service provider may be substituted for the End Users. Note the *may* -- ISP's aren't required to support it. More RIPE policy.. When an organisation holding an IPv6 address allocation makes IPv6 address assignments, it must register these assignments in the appropriate RIR database. These registrations can either be made as individual assignments or by inserting a object with a status value of 'AGGREGATED-BY-LIR' where the assignment-size attribute contains the size of the individual assignments made to End Users.When more than a /48 is assigned to an organisation, it must be registered in the database as a separate object with status 'ASSIGNED'. So they have to register it, and they get a choice about how they do it.. Your provider has chosen a way you don't like. Talk to them about it, rather than complaining on NANOG? It's pretty similar in the ARIN region. In 2004, the ARIN community passed the residential customer privacy policy - specifically allowing ISP's to designate a record private. Again, it's optional. https://www.arin.net/policy/nrpm.html Min assignment swip 6.5.5.1. Reassignment information Each static IPv6 assignment containing a /64 or more addresses shall be registered in the WHOIS directory via SWIP or a distributed service which meets the standards set forth in section 3.2. Reassignment registrations shall include each client's organizational information, except where specifically exempted by this policy. IPv4 4.2.3.7.3.2. Residential Customer Privacy To maintain the privacy of their residential customers, an organization with downstream residential customers holding /29 and larger blocks may substitute that organization's name for the customer's name, e.g. 'Private Customer - XYZ Network', and the customer's street address may read 'Private Residence'. Each private downstream residential reassignment must have accurate upstream Abuse and Technical POCs visible on the WHOIS directory record for that block. IPv6 6.5.5.3. Residential Subscribers 6.5.5.3.1. Residential Customer Privacy To maintain the privacy of their residential customers, an organization with downstream residential customers holding /64 and larger blocks may substitute that organization's name for the customer's name, e.g. 'Private Customer - XYZ Network', and the customer's street address may read 'Private Residence'. Each private downstream residential reassignment must have accurate upstream Abuse and Technical POCs visible on the WHOIS record for that block. --Heather -Original Message- From: Constantine A. Murenin [mailto:muren...@gmail.com] Sent: Saturday, December 08, 2012 12:46 AM To: nanog@nanog.org Subject: Why do some providers require IPv6 /64 PA space to have public whois? Hello, I personally don't understand this policy. I've signed up with hetzner.de, and I'm trying to get IPv6; however, on the supplementary page where the complementary IPv6 /64 subnet can be requested (notice that it's not even a /48, and not even the second, routed, /64), after I change the selection from requesting one additional IPv4 address to requesting the IPv6 /64 subnet (they offer no other IPv6 options in that menu), they use DOM to remove the IP address justification field (Purpose of use), and instead statically show my name, physical street address (including the apartment number), email address and phone number, and ask to confirm that all of this information can be submitted to RIPE. They offer no option of modifying any of this; they also offer no option of hiding the street address and showing it as Private Address instead; they also offer no option of providing contact information different from the contact details for the main profile or keeping a separate set of contact details in the main profile specifically for RIPE; they also offer no option of providing a RIPE handle instead (dunno if one can be registered with a Private Address address, showing only city/state/country and postal code; I do know that with ARIN and PA IPv4 subnets you can do Private Address in the Address field); they also don't let you submit the form unless you agree for the information shown to be passed along to RIPE for getting IPv6 connectivity (again,
RE: authority to route?
..for some blocks I've taken over admin for. Make sure you are visibly listed as a Point of Contact on those records in the appropriate RIR, so that folks who get your request can verify you. Even better, register in your RIR's RPKI program and generate a ROA for it. Info about ARIN's here: https://www.arin.net/resources/rpki/index.html Then yes, notify their upstreams/peers if needed and post here if things get really desperate - have your records in order first. --Heather -Original Message- From: Jim Mercer [mailto:j...@reptiles.org] Sent: Monday, November 12, 2012 2:44 PM To: nanog@nanog.org Subject: authority to route? Hi, Is there a common practice of providers to vet / validate requests to advertise blocks? Who is the authority when it comes to determining if a request for routing is valid? Is it the WHOIS data maintained by the various RIR? It seems I'm playing whack-a-mole to get some routes shut down for some blocks I've taken over admin for. If I email the contacts for the AS in WHOIS, and get no response, or a negative response, should I start going to their peers? Some practical advice would be appreciated. -- Jim Mercer Reptilian Research j...@reptiles.org+1 416 410-5633 He who dies with the most toys is nonetheless dead
RE: RIRs give out unique addresses (Was: something has a /8! ...)
There is no such thing as Internet routers there are my routers, your routers, and that guy over there's routers. Even if you get your ISP to route it for you - that does not guarantee that any other network anywhere else on the internet will accept the route. Getting your ISP to accept your prefix is arguably, only a small part of being reachable/routable. --Heather -Original Message- From: Naslund, Steve [mailto:snasl...@medline.com] Sent: Thursday, September 20, 2012 10:56 AM To: nanog@nanog.org Subject: RE: RIRs give out unique addresses (Was: something has a /8! ...) I suppose that ARIN would say that they do not guarantee routability because they do not have operational control of Internet routers. However, Wouldn't you say that there is a very real expectation that when you request address space through ARIN or RIPE that it would be routable? I would think that what ARIN and RIPE are really saying is that they issue unique addresses and you need to get your service provider to route them. FWIW, the discussion of the military having addresses pulled back is pretty much a non-starter unless they want to give them back. When the management of IP address space was moved from the US DoD, there were memorandums of understanding that the military controlled their assigned address space and nothing would change that. I know this for a fact because I was around this discussion in the US Air Force. Steven Naslund -Original Message- From: John Curran [mailto:jcur...@arin.net] Sent: Thursday, September 20, 2012 9:40 AM To: Jeroen Massar Cc: NANOG list Subject: Re: RIRs give out unique addresses (Was: something has a /8! ...) On Sep 20, 2012, at 10:10 AM, Jeroen Massar jer...@unfix.org wrote: On 2012-09-20 16:01 , John Curran wrote: It's very clear in the ARIN region as well. From the ARIN Number Resource Policy Manual (NRPM), https://www.arin.net/policy/nrpm.html#four11 - 4.1. General Principles 4.1.1. Routability Provider independent (portable) addresses issued directly from ARIN or other Regional Registries are not guaranteed to be globally routable. While close, that is not the same. The RIPE variant solely guarantees uniqueness of the addresses. The ARIN variant states we don't guarantee that you can route it everywhere, which is on top of the uniqueness portion. Agreed - I called it out because ARIN, like RIPE, does not assert that the address blocks issued are publicly routable address space (i.e. which was Tim Franklin's original statement, but he did not have on hand the comparable ARIN reference for that point.) FYI, /John
RE: 91.201.64.0/22 hijacked?
It does not sound as though the original holders of the space know/care - if they are out of business, they probably don't care. If they are actively involved in it, then it's not a hijack. If they haven't updated their company name/website, then it's not a hijack, just poor record keeping. If you suspect the address space is abandoned, or hijacked, report it to RIPE. It may not get deallocated and reassinged until a few months after the bill stops getting paid. --Heather -Original Message- From: Jeroen van Aart [mailto:jer...@mompl.net] Sent: Friday, August 31, 2012 2:39 PM To: NANOG list Subject: 91.201.64.0/22 hijacked? The below email exchange may be of interest to some of you. The practical upshot is that it appears the 91.201.64.0/22 range was hijacked and should be included into the DROP list. As an interesting aside, quoting a friend: the original company (that performed dangerous waste utilization) may have been a shady thing in and of itself (..) what most companies calling themselves ecoservice (with variations) do is take money for safe utilisation of hazardous waste, and then dump it in some old quarry out in the remote (or not so remote) corner of a forest or other natural area (..) they always have criminal links and protection from corrupts officials (often co-owners) and security/law enforcement services From: Jeroen van Aart there is nothing but crap coming from 91.201.64.0/24. Amongst other things attempts to spam (through) wordpress sites. inetnum: 91.201.64.0 - 91.201.67.255 netname: Donekoserv descr: DonEkoService Ltd Don - name of the nearby large river. EkoService means ecological service. country: RU org: ORG-DS41-RIPE person: Haralevich Piotr address:novocherkassk, ul stremyannaya d.6 mnt-by: MNT-DONECO phone: +7495100 nic-hdl: HP2220-RIPE changed: ad...@donecoserv.ru 20101117 The company performed dangerous waste utilization: http://donekoservis.alloy.ru/contacts/ http://www.idbo.ru/view/72321/ But domains donecoserv.ru and donekoservis.ru don't exist anymore. traceroute 91.201.64.14 ... 11 router02.spbbm18.ru.edpnet.net (212.71.11.26) 65.979 ms 65.971 ms 66.182 ms 12 77.109.110.62.static.edpnet.net (77.109.110.62) 88.868 ms 47.809 ms 47.715ms 13 195.2.240.234 (195.2.240.234) 48.235 ms 48.546 ms 48.664 ms 14 ajursrv.parohod.biz (95.215.0.206) 47.957 ms 47.752 ms 47.606 ms 15 mail.rx-helps.com (91.201.64.14) 48.206 ms 48.302 ms 48.237 ms SPb (Sankt-Peterburg) is 1500 km from Novocherkassk. parohod.biz also is in Sankt-Peterburg, they offer SEO (which I consider fraud, spamming websites and search engines). Also, see http://support.clean-mx.de/clean-mx/viruses.php?email=ad...@donecoserv.ruresponse= http://www.spambotsecurity.com/forum/viewtopic.php?f=7t=795 http://unapprovedpharmacy.wordpress.com/2011/01/03/whois-www-canadianmedsshop-com/ | January 3, 2011 ... | inetnum: 91.201.64.0 91.201.67.255 | netname: Donekoserv | descr: DonEkoService Ltd | country: RU | org: ORG-DS41-RIPE ... | organisation: ORG-DS41-RIPE | org-name: DonEko Service | org-type: OTHER | address: novocherkassk, ul stremyannaya d.6 | e-mail: ad...@bulletproof-web.com Note bulletproof. Therefore, the 91.201.64.0/22 range was hijacked and should be included into the DROP list.
RE: Verizon FiOS - is BGP an option?
Actually, it's a choice. You just tell them you want to keep your POTS when you sign up for service. They can definitely bundle Fios TV POTS. The VOIP package might be cheaper. I suspect that's where most people wind up, not realizing the difference in service until there is a power outage. --Heather -Original Message- From: William Herrin [mailto:b...@herrin.us] Sent: Friday, August 03, 2012 5:18 PM To: Owen DeLong Cc: nanog@nanog.org Subject: Re: Verizon FiOS - is BGP an option? On Fri, Aug 3, 2012 at 10:01 AM, Owen DeLong o...@delong.com wrote: On Aug 3, 2012, at 12:31 , William Herrin b...@herrin.us wrote: Could be worse. I could have Pepco instead of Dominion. But it could be better. And 20 years ago the reliability was. 20 years ago you didn't have a megabit to your home let alone many megabits. 20 years ago, POTS was much simpler than the converged networks we have today. There is something to be said for the simplicity of POTS. If you're that concerned about calling 911 for a heat stroke, why don't you maintain a POTS line? When Verizon installed FIOS in the neighborhood they removed the copper lines to each house. It was understood and accepted that if the household fiber adapters did not receive power the battery would fail in a few hours. That the upstream would fail, even for folks who took measures to continue to power the fiber adapter, was unexpected and very unfortunate. If they can run a copper pair back to a powerable location then it escapes me why they can't do the same with a single strand of fiber. 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: Requesting off-list contact from a verizon.net mail admin
Replied off list.. --Heather -Original Message- From: Andrew Jones [mailto:a...@jonesy.com.au] Sent: Tuesday, July 10, 2012 10:45 PM To: nanog@nanog.org Subject: Requesting off-list contact from a verizon.net mail admin If someone who looks after verizon.net mail is listening, I would appreciate them contacting me regarding some issues we are having getting email through from our IP range. We've tried all the usual email channels (no response), and the online form insists that reverse DNS is missing (it's not) or the address is dynamic (it's not). Thanks, Andrew Jones Daraco Services
RE: Reachability issue 193.56.43.0/24AS25186 from AS701
Sent response offlist. --heather -Original Message- From: Jérôme Nicolle [mailto:jer...@ceriz.fr] Sent: Monday, April 02, 2012 11:55 AM To: nanog@nanog.org Subject: Reachability issue 193.56.43.0/24AS25186 from AS701 Hi, Just changed the upstream for this network and a few customers can't reach our services anymore. According to RIPE stats, reachability, is not optimal on the north american zone, but is perfect everywhere else (see https://stat.ripe.net/193.56.43.124) One of the complaining customer is on AS1660 and the route breaks within AS701. Could anyone confirm the reachability for this prefix from the US ? Anyone at Verizon to check and fix if necessary ? Thanks ! -- Jérôme Nicolle +33 6 19 31 27 14
AS8300 - Swisscom hijacking.. Just what are you testing?
AS8300 started announcing one of the Rove Digital dns changer IP ranges. (The IP ranges the FBI is sending 'you are infected' letters about) Swisscom's announcement is less specific than the prefixes being announced by ISC during the remediation effort, so it's not impacting traffic... But AS8300 seems to announce less specifics a lot. Last fall they announced 63/8 and half of that is allocated to 701. AFAIK, we weren't notified they were going to announce a less specific of our space. As long as folks have pullup routes, and don't have an outage that withdraws their announcements, then Swisscom should only be getting darknet traffic. The record for AS8300 says 'Test' and the entry for it in CIDR report says This AS is not currently used to announce prefixes in the global routing table, nor is it used as a visible transit AS. .. But their announcements certainly do show up in the global routing table, whether they are transiting for someone or not, they could get traffic for anything that doesn't have a more specific. Given the recent YAHT (yet another hijack thread) it's worth pointing out that hijacking more specifics is bad, but less specifics can be bad as well. (Not suggesting that is the case here..) I searched around and couldn't find any mention of what they might be testing. Anyone know? route-viewssh ip bgp 85.255.112.0/20 BGP routing table entry for 85.255.112.0/20, version 2177063753 Paths: (11 available, no best path) Not advertised to any peer 6079 3303 8300 (history entry) 207.172.6.20 from 207.172.6.20 (207.172.6.20) Origin IGP, metric 85, localpref 100, external Dampinfo: penalty 495, flapped 2 times in 00:24:37 3277 3267 174 3303 8300 (history entry) 194.85.102.33 from 194.85.102.33 (194.85.4.4) Origin IGP, localpref 100, external Community: 3277:3267 3277:65321 3277:65323 3277:65330 Dampinfo: penalty 501, flapped 2 times in 00:24:22 --Heather
RE: Hijacked Network Ranges - paging Cogent and GBLX/L3
Or roll it up hill: 33611 looks like they get transit from 19181, who's only upstream appears to be 12189. 12189 gets connectivity from 174 and 3549. 174 = Cogent 3549 = GBLX/L3 --Heather -Original Message- From: Kelvin Williams [mailto:kwilli...@altuscgi.com] Sent: Tuesday, January 31, 2012 1:01 PM To: nanog@nanog.org Subject: Hijacked Network Ranges Greetings all. We've been in a 12+ hour ordeal requesting that AS19181 (Cavecreek Internet Exchange) immediately filter out network blocks that are being advertised by ASAS33611 (SBJ Media, LLC) who provided to them a forged LOA. The routes for networks: 208.110.48.0/20, 63.246.112.0/20, and 68.66.112.0/20 are registered in various IRRs all as having an origin AS 11325 (ours), and are directly allocated to us. The malicious hijacking is being announced as /24s therefore making route selection pick them. Our customers and services have been impaired. Does anyone have any contacts for anyone at Cavecreek that would actually take a look at ARINs WHOIS, and IRRs so the networks can be restored and our services back in operation? Additionally, does anyone have any suggestion for mitigating in the interim? Since we can't announce as /25s and IRRs are apparently a pipe dream. -- Kelvin Williams Sr. Service Delivery Engineer Broadband Carrier Services Altus Communications Group, Inc. If you only have a hammer, you tend to see every problem as a nail. -- Abraham Maslow
RE: Hijacked Network Ranges - paging Cogent and GBLX/L3
Looks fixed now.. --heather -Original Message- From: Keegan Holley [mailto:keegan.hol...@sungard.com] Sent: Tuesday, January 31, 2012 2:50 PM To: Schiller, Heather A Cc: Kelvin Williams; nanog@nanog.org Subject: Re: Hijacked Network Ranges - paging Cogent and GBLX/L3 To be honest I haven't had much success it convincing a tier 1 to modify someone else's routes on my behalf for whatever reason. I also have had limited success in getting them to do anything quickly. I'd first look to modify your advertisements as much as possible to mitigate the issue and then work with the other guys upstreams second. 2012/1/31 Schiller, Heather A heather.schil...@verizon.com: Or roll it up hill: 33611 looks like they get transit from 19181, who's only upstream appears to be 12189. 12189 gets connectivity from 174 and 3549. 174 = Cogent 3549 = GBLX/L3 --Heather -Original Message- From: Kelvin Williams [mailto:kwilli...@altuscgi.com] Sent: Tuesday, January 31, 2012 1:01 PM To: nanog@nanog.org Subject: Hijacked Network Ranges Greetings all. We've been in a 12+ hour ordeal requesting that AS19181 (Cavecreek Internet Exchange) immediately filter out network blocks that are being advertised by ASAS33611 (SBJ Media, LLC) who provided to them a forged LOA. The routes for networks: 208.110.48.0/20, 63.246.112.0/20, and 68.66.112.0/20 are registered in various IRRs all as having an origin AS 11325 (ours), and are directly allocated to us. The malicious hijacking is being announced as /24s therefore making route selection pick them. Our customers and services have been impaired. Does anyone have any contacts for anyone at Cavecreek that would actually take a look at ARINs WHOIS, and IRRs so the networks can be restored and our services back in operation? Additionally, does anyone have any suggestion for mitigating in the interim? Since we can't announce as /25s and IRRs are apparently a pipe dream. -- Kelvin Williams Sr. Service Delivery Engineer Broadband Carrier Services Altus Communications Group, Inc. If you only have a hammer, you tend to see every problem as a nail. -- Abraham Maslow
RE: Hijacked Network Ranges - paging Cogent and GBLX/L3
Sorry -- was looking at the wrong thing. Doh! --heather -Original Message- From: Schiller, Heather A Sent: Tuesday, January 31, 2012 3:05 PM To: 'Keegan Holley' Cc: Kelvin Williams; nanog@nanog.org Subject: RE: Hijacked Network Ranges - paging Cogent and GBLX/L3 Looks fixed now.. --heather -Original Message- From: Keegan Holley [mailto:keegan.hol...@sungard.com] Sent: Tuesday, January 31, 2012 2:50 PM To: Schiller, Heather A Cc: Kelvin Williams; nanog@nanog.org Subject: Re: Hijacked Network Ranges - paging Cogent and GBLX/L3 To be honest I haven't had much success it convincing a tier 1 to modify someone else's routes on my behalf for whatever reason. I also have had limited success in getting them to do anything quickly. I'd first look to modify your advertisements as much as possible to mitigate the issue and then work with the other guys upstreams second. 2012/1/31 Schiller, Heather A heather.schil...@verizon.com: Or roll it up hill: 33611 looks like they get transit from 19181, who's only upstream appears to be 12189. 12189 gets connectivity from 174 and 3549. 174 = Cogent 3549 = GBLX/L3 --Heather -Original Message- From: Kelvin Williams [mailto:kwilli...@altuscgi.com] Sent: Tuesday, January 31, 2012 1:01 PM To: nanog@nanog.org Subject: Hijacked Network Ranges Greetings all. We've been in a 12+ hour ordeal requesting that AS19181 (Cavecreek Internet Exchange) immediately filter out network blocks that are being advertised by ASAS33611 (SBJ Media, LLC) who provided to them a forged LOA. The routes for networks: 208.110.48.0/20, 63.246.112.0/20, and 68.66.112.0/20 are registered in various IRRs all as having an origin AS 11325 (ours), and are directly allocated to us. The malicious hijacking is being announced as /24s therefore making route selection pick them. Our customers and services have been impaired. Does anyone have any contacts for anyone at Cavecreek that would actually take a look at ARINs WHOIS, and IRRs so the networks can be restored and our services back in operation? Additionally, does anyone have any suggestion for mitigating in the interim? Since we can't announce as /25s and IRRs are apparently a pipe dream. -- Kelvin Williams Sr. Service Delivery Engineer Broadband Carrier Services Altus Communications Group, Inc. If you only have a hammer, you tend to see every problem as a nail. -- Abraham Maslow
RE: OT -- seeking a knowledgable AS 701 technical contact.
Hi! Now that you have my email address, ping me offline and I'll see if I can help. --Heather ~*~*~*~*~*~*~*~*~*~*~*~*~*~*~*~*~*~*~*~*~*~*~* Heather Schiller Network Security - Verizon Business 1.800.900.0241secur...@verizonbusiness.com -Original Message- From: Robert Bonomi [mailto:bon...@mail.r-bonomi.com] Sent: Wednesday, November 16, 2011 5:36 PM To: nanog@nanog.org Subject: OT -- seeking a knowledgable AS 701 technical contact. Apologies for the noise, but I have been absolutely unable -- despite literally *hours* of trying --to contact anyone at _any_ of the published Verizon Business phone numbers who has any comprehension of what I am talking about -- to wit: I am looking for someone with _any_ awareness/knowledge of Verizon Business's public-access anonymous FTP server, with the hostname 'ftp.uu.net'. The published Verizon Business technical contact number -- both in 'whois' for uu.net, and Jared's NOC contact list is only the 'ticket center', and won't open a ticket for someone who is not Verizon customer. Customer service doesn't know what 'ftp' is, and vacillates between thinking it is a circuit problem, or that I am having a problem with -my- domain. Call-transfer to 'technical support' was answered by someone handling 'delinquent payments'. Another transfer attempt ended up on somebody's cell phone.
RE: Nxdomain redirect revenue
Paxfire gets sued: http://www.newscientist.com/article/dn20768-us-internet-providers-hijacking-users-search-queries.html http://www.courthousenews.com/2011/08/08/38796.htm http://www.pcmag.com/article2/0,2817,2390529,00.asp Paxfire files counter suit: http://www.techdirt.com/articles/20110809/17305215460/paxfire-responds-says-it-doesnt-hijack-searches-will-seek-sanctions-against-lawyers.shtml http://www.techdirt.com/articles/20110906/03371515808/paxfire-sues-lawyers-individual-who-filed-class-action-lawsuit-over-its-search-redirects.shtml http://www.prweb.com/releases/2011/9/prweb8765163.htm -Original Message- From: William Allen Simpson [mailto:william.allen.simp...@gmail.com] Sent: Tuesday, September 27, 2011 4:58 AM To: nanog@nanog.org Subject: Re: Nxdomain redirect revenue On 9/26/11 4:29 AM, Florian Weimer wrote: Is this with strict NXDOMAIN rewriting, or were existing names redirected as well? (AFAIK, most platforms do the latter, hijacking bfk.de, for example.) Has anybody tried bringing a criminal complaint for interference with computer (network) data? Certainly, hijacking google.com NS records to JOMAX.NET would be a criminal interference. After all, that's all DNSsec signed now, isn't it? Arguably, substituting a false reply for NXDOMAIN would be, too. It's time to find a champion to lead the charge. Maybe Google?
RE: Saudi Telecom sending route with invalid attributes 212.118.142.0/24 - Redux
Seeing it again here too.. Has anyone contacted them? ..and for folks who are choosing to blackhole the prefix in order to supress the route, please remember not to export it! AS25019 SAUDINETSTC-AS Autonomus System Number for SaudiNet 2011-09-08 18:23:53 UTC 2011-09-19 19:16:27 UTC AS8866 BTC-AS Bulgarian Telecommunication Company Plc. 2011-09-08 18:35:14 UTC 2011-09-19 19:15:42 UTC AS10026 PACNET Pacnet Global Ltd2011-09-11 02:41:40 UTC 2011-09-19 16:00:00 UTC AS8767 MNET-AS M-net AS2011-09-14 12:13:01 UTC 2011-09-14 12:14:00 UTC AS3561 SAVVIS - Savvis 2011-09-09 19:42:15 UTC 2011-09-10 16:27:18 UTC AS3549 GBLX Global Crossing Ltd. 2011-09-09 16:13:15 UTC 2011-09-09 17:05:38 UTC AS1239 SPRINTLINK - Sprint 2011-09-09 03:18:28 UTC 2011-09-09 15:56:41 UTC AS65000 -Private Use AS-2011-09-08 18:34:28 UTC 2011-09-08 18:34:29 UTC --heather -Original Message- From: Ryan Gray [mailto:r...@longlines.com] Sent: Monday, September 19, 2011 3:09 PM To: Schiller, Heather A Cc: Aftab Siddiqui; Richard Barnes; Jonas Frey (Probe Networks); nanog@nanog.org Subject: Re: Saudi Telecom sending route with invalid attributes 212.118.142.0/24 Actually just started seeing these problems again today. Is anyone else seeing this today from something other than 212.118.142.0/24? Looks like it started about two hours ago. Regards, Ryan Gray Long Lines www.longlines.com On Sep 12, 2011, at 8:18 PM, Schiller, Heather A wrote: Could be this..? http://www.juniper.net/techpubs/en_US/junos11.2/topics/reference/confi guration-statement/independent-domain-edit-routing-options.html unrecognized transitive attributes depend on whatever code version you are running... What's more important is how the unrecoginized attribute is handled. Ideally you accept and pass the route and log it. The problem is with devices that aren't so graceful.. dropping sessions and wreaking havoc: http://www.cisco.com/warp/public/707/cisco-sa-20100827-bgp.shtml --Heather -Original Message- From: Aftab Siddiqui [mailto:aftab.siddi...@gmail.com] Sent: Saturday, September 10, 2011 6:49 PM To: Richard Barnes Cc: Jonas Frey (Probe Networks); nanog@nanog.org Subject: Re: Saudi Telecom sending route with invalid attributes 212.118.142.0/24 with in the span of couple of hours this prefix was originated from 3 ASN i.e. AS3561 (Savvis), AS8866 (BTC) and AS25019 (STC original custodians). As per the STC it was orginated by one of their customer having Juniper router. but I still don't understand why/how they are adv this prefix with unrecog transitive attributes. Can any one suggest. Regards, Aftab A. Siddiqui On Sun, Sep 11, 2011 at 3:26 AM, Richard Barnes richard.bar...@gmail.comwrote: Looks like the RIS collectors are seeing it originating mostly from STC and KACST ASNs: http://stat.ripe.net/212.118.142.0/24 Some of the show ip bgp reports on that screen are also showing AS8866 BTC-AS Bulgarian Telecommunication Company. Not sure what's up with that. --Richard On Sat, Sep 10, 2011 at 2:01 PM, Christopher Morrow morrowc.li...@gmail.com wrote: On Fri, Sep 9, 2011 at 9:26 PM, Kyle Duren pixitha.k...@gmail.com wrote: Is this announcement still showing up this way (no easy way to check myself). ripe ris? -Kyle On Thu, Sep 8, 2011 at 4:20 PM, Clay Haynes chay...@centracomm.net wrote: On Thu, Sep 8, 2011 at 7:11 PM, Jonas Frey (Probe Networks) j...@probe-networks.de wrote: Hello, anyone else getting a route for 212.118.142.0/24 with invalid attributes? Seems this is (again) causing problems with some (older) routers/software. Announcement bits (4): 0-KRT 3-KRT 5-Resolve tree 1 6-Resolve tree 2 AS path: 6453 39386 25019 I Unrecognized Attributes: 39 bytes AS path: Attr flags e0 code 80: 00 00 fd 88 40 01 01 02 40 02 04 02 01 5b a0 c0 11 04 02 01 fc da 80 04 04 00 00 00 01 40 05 04 00 00 00 64 Accepted Multipath -Jonas Yup! We're seeing the same thing too, and we're filtering it out. Originating AS is 25019 -Clay
RE: The Cidr Report - 4byte ASN handling
I thought AS-plain notation was the standard for 4-byte ASN's? Also to cidr
report folks, in the web version, clicking on the ASN for these takes you to
the page for AS3 (MIT)
46.18.104.0/21AS3.746
195.54.52.0/23 AS3.523
195.54.52.0/24 AS3.523
195.54.53.0/24 AS3.523
route-viewssh ip bgp 195.54.52.0
BGP routing table entry for 195.54.52.0/24, version 218523
Paths: (34 available, best #34, table Default-IP-Routing-Table)
Not advertised to any peer
3257 3356 3255 3.523 3.523 3.523
89.149.178.10 from 89.149.178.10 (213.200.87.91)
Origin IGP, metric 10, localpref 100, valid, external
Community: 3257:8091 3257:30042 3257:50001 3257:54900 3257:54901
-Original Message-
From: cidr-rep...@potaroo.net [mailto:cidr-rep...@potaroo.net]
Sent: Friday, September 09, 2011 6:00 PM
To: cidr-rep...@potaroo.net
Cc: ap...@apops.net; af...@afnog.org; nanog@nanog.org; eof-l...@ripe.net;
routing...@ripe.net
Subject: The Cidr Report
This report has been generated at Fri Sep 9 21:12:28 2011 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
02-09-11373096 219901
03-09-11373636 219796
04-09-11373666 219877
05-09-11373566 219844
06-09-11373748 219894
07-09-11373965 219992
08-09-11373797 219481
09-09-11373405 220098
AS Summary
38831 Number of ASes in routing system
16392 Number of ASes announcing only one prefix
3564 Largest number of prefixes announced by an AS
AS6389 : BELLSOUTH-NET-BLK - BellSouth.net Inc.
108360672 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').
--- 09Sep11 ---
ASnumNetsNow NetsAggr NetGain % Gain Description
Table 374093 219958 15413541.2% All ASes
AS6389 3564 229 333593.6% BELLSOUTH-NET-BLK -
BellSouth.net Inc.
AS4766 2508 974 153461.2% KIXS-AS-KR Korea Telecom
AS18566 1912 378 153480.2% COVAD - Covad Communications
Co.
AS22773 1451 108 134392.6% ASN-CXA-ALL-CCI-22773-RDC -
Cox Communications Inc.
AS4755 1547 228 131985.3% TATACOMM-AS TATA
Communications formerly VSNL
is Leading ISP
AS4323 1627 397 123075.6% TWTC - tw telecom holdings,
inc.
AS10620 1661 591 107064.4% Telmex Colombia S.A.
AS1785 1825 778 104757.4% AS-PAETEC-NET - PaeTec
Communications, Inc.
AS19262 1394 400 99471.3% VZGNI-TRANSIT - Verizon Online
LLC
AS7552 1415 431 98469.5% VIETEL-AS-AP Vietel
Corporation
AS28573 1302 344 95873.6% NET Servicos de Comunicao S.A.
AS18101 950 144 80684.8% RELIANCE-COMMUNICATIONS-IN
Reliance Communications
Ltd.DAKC MUMBAI
AS24560 1177 386 79167.2% AIRTELBROADBAND-AS-AP Bharti
Airtel Ltd., Telemedia
Services
AS8151 1411 659 75253.3% Uninet S.A. de C.V.
AS4808 1077 339 73868.5% CHINA169-BJ CNCGROUP IP
network China169 Beijing
Province Network
AS7303 1051 316 73569.9% Telecom Argentina S.A.
AS7545 1581 860 72145.6% TPG-INTERNET-AP TPG Internet
Pty Ltd
AS3356 1103 449 65459.3% LEVEL3 Level 3 Communications
AS30036 1327 692 63547.9% MEDIACOM-ENTERPRISE-BUSINESS -
Mediacom Communications Corp
AS3549 1080 449 63158.4% GBLX Global Crossing Ltd.
AS14420 715 92 62387.1% CORPORACION
RE: Saudi Telecom sending route with invalid attributes 212.118.142.0/24
Could be this..? http://www.juniper.net/techpubs/en_US/junos11.2/topics/reference/configuration-statement/independent-domain-edit-routing-options.html unrecognized transitive attributes depend on whatever code version you are running... What's more important is how the unrecoginized attribute is handled. Ideally you accept and pass the route and log it. The problem is with devices that aren't so graceful.. dropping sessions and wreaking havoc: http://www.cisco.com/warp/public/707/cisco-sa-20100827-bgp.shtml --Heather -Original Message- From: Aftab Siddiqui [mailto:aftab.siddi...@gmail.com] Sent: Saturday, September 10, 2011 6:49 PM To: Richard Barnes Cc: Jonas Frey (Probe Networks); nanog@nanog.org Subject: Re: Saudi Telecom sending route with invalid attributes 212.118.142.0/24 with in the span of couple of hours this prefix was originated from 3 ASN i.e. AS3561 (Savvis), AS8866 (BTC) and AS25019 (STC original custodians). As per the STC it was orginated by one of their customer having Juniper router. but I still don't understand why/how they are adv this prefix with unrecog transitive attributes. Can any one suggest. Regards, Aftab A. Siddiqui On Sun, Sep 11, 2011 at 3:26 AM, Richard Barnes richard.bar...@gmail.comwrote: Looks like the RIS collectors are seeing it originating mostly from STC and KACST ASNs: http://stat.ripe.net/212.118.142.0/24 Some of the show ip bgp reports on that screen are also showing AS8866 BTC-AS Bulgarian Telecommunication Company. Not sure what's up with that. --Richard On Sat, Sep 10, 2011 at 2:01 PM, Christopher Morrow morrowc.li...@gmail.com wrote: On Fri, Sep 9, 2011 at 9:26 PM, Kyle Duren pixitha.k...@gmail.com wrote: Is this announcement still showing up this way (no easy way to check myself). ripe ris? -Kyle On Thu, Sep 8, 2011 at 4:20 PM, Clay Haynes chay...@centracomm.net wrote: On Thu, Sep 8, 2011 at 7:11 PM, Jonas Frey (Probe Networks) j...@probe-networks.de wrote: Hello, anyone else getting a route for 212.118.142.0/24 with invalid attributes? Seems this is (again) causing problems with some (older) routers/software. Announcement bits (4): 0-KRT 3-KRT 5-Resolve tree 1 6-Resolve tree 2 AS path: 6453 39386 25019 I Unrecognized Attributes: 39 bytes AS path: Attr flags e0 code 80: 00 00 fd 88 40 01 01 02 40 02 04 02 01 5b a0 c0 11 04 02 01 fc da 80 04 04 00 00 00 01 40 05 04 00 00 00 64 Accepted Multipath -Jonas Yup! We're seeing the same thing too, and we're filtering it out. Originating AS is 25019 -Clay
RE: NANOG 52 Stream Archives?
Eventually they will be posted here: http://nanog.org/presentations/archive/index.php With a few exceptions -- the FCC presentation was not recorded. The breakout sessions aren't typically recorded either. --heather -Original Message- From: Krembs, Jesse [mailto:jkre...@fairpoint.com] Sent: Friday, June 17, 2011 9:07 AM To: nanog@nanog.org Subject: NANOG 52 Stream Archives? Dear All For those of us that missed the show, is it possible to view the NANOG 52 streams anywhere? Jesse Krembs - Data Network Architecture Planning FairPoint Communications | 800 Hinesburg Rd, South Burlington, VT 05403 | jkre...@fairpoint.com mailto:jkre...@fairpoint.com www.FairPoint.com http://www.fairpoint.com/ | 802.951.1519 office | 802.735.4886 cell ___ This e-mail message and its attachments are for the sole use of the intended recipients. They may contain confidential information, legally privileged information or other information subject to legal restrictions. If you are not the intended recipient of this message, please do not read, copy, use or disclose this message or its attachments, notify the sender by replying to this message and delete or destroy all copies of this message and attachments in all media.
RE: IPv6 day non-participants
They are probably referring to this: http://support.microsoft.com/kb/2533454/ The following Fix it solution will resolve the issue by configuring your computer to prefer IPv4, instead of IPv6. By default, Windows prefers IPv6 over IPv4. This Fix it solution is temporary, to resolve issues on World IPv6 Day for affected Internet users. On June 10, 2011 at 12:00AM, your computer will be configured to prefer IPv6 again after your next reboot. --h -Original Message- From: Joly MacFie [mailto:j...@punkcast.com] Sent: Thursday, June 09, 2011 3:03 PM To: Wes Hardaker Cc: nanog Subject: Re: IPv6 day non-participants Someone has told me that Microsoft switched off IPv6 for the day. Is that true? To what extent? j -- --- 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 -- -
RE: AAAA on various websites, but they all forgot to enable them on their nameservers....
-Original Message- From: Jorge Amodio [mailto:jmamo...@gmail.com] Sent: Wednesday, June 08, 2011 1:01 PM To: Lucy Lynch Cc: nanog@nanog.org Subject: Re: on various websites, but they all forgot to enable them on their nameservers http://www.mrp.net/IPv6Day.html The web access column reflects access to internal content or just the home page ? Mark's notes explain what he tested and clicking on any link shows the result of his diagnostics: http://www.mrp.net//IPv6Day_files/diagnostics/aol.com.html guessing he didn't do depth probes. Maybe you want to set something up? Thanks for the follow up. I noticed that the test only looks for the html survey file. Just curious since other folks reported that some content providers are serving the home page via IPv6 but other content goes via IPv4. Still surprised that Akamai's numbers feel very low, 300+ hits per sec (worldwide) for one of the major CDN is not that much IHMO, we really need more IPv6 eye-balls connecting. -J ...yes, there is a serious lack of v6 enabled eyeballs. But it's also not clear to me from Akamai's stats just how many of the sites they host are v6 enabled. 2? 12? 500? --heather
RE: Creating an IPv6 addressing plan for end users
For those who don't like clicking on random bit.ly links: http://www.ripe.net/training/material/IPv6-for-LIRs-Training-Course/IPv6 _addr_plan4.pdf --Heather -Original Message- From: Nathalie Trenaman [mailto:natha...@ripe.net] Sent: Wednesday, March 16, 2011 5:05 AM To: nanog@nanog.org Subject: Creating an IPv6 addressing plan for end users Hi all, In our IPv6 courses, we often get the question: I give my customers a /48 (or a /56 or a /52) but they have no idea how to distribute that space in their network. In December Sander Steffann and Surfnet wrote a manual explaining exactly that, in clear language with nice graphics. A very useful document but it was in Dutch, so RIPE NCC decided to translate that document to English. Yesterday, we have published that document on our website and we hope this document is able to take away some of the fear that end users seem to have for these huge blocks. You can find this document here: http://bit.ly/IPv6addrplan (PDF) I look forward to your feedback, tips and comments. With kind regards, Nathalie Trenaman RIPE NCC Trainer
Geolocation Info Correction Needed at Apple, Yahoo, MSN
If anyone is listening, would you be so kind as to update geolocation info for the following-- they are in Mexico, not Argentina. inetnum: 186.64.16.176/29 status: reallocated owner: Infor Global Solutions Mexico SA de CV ownerid: MX-IGSM-LACNIC responsible: Hector Garcia Bernal address: Montes Urales 505 Lomas de Chapultepec, , address: - mexico city - country: MX I couldn't find information on how to get geolocation errors corrected for Apple, Yahoo or MSN on their websites. It would be nice if folks would also update http://nanog.cluepon.net/index.php/GeoIP which details the process for several large sites. Thanks, --Heather ~*~*~*~*~*~*~*~*~*~*~*~*~*~*~*~*~*~*~*~*~*~*~* Heather Schiller Network Security - Verizon Business 1.800.900.0241secur...@verizonbusiness.com
RE: Anyone has a contact with IP clue at VerizonBusiness?
Hi :) I don't manage IP space day to day anymore.. But can get you in touch w/ the folks who do. No promises, as I don't know what the issue is - but I can try to help clear up any problem as well. ..and there really isn't a panic over here, we've known it was coming for years. --Heather -Original Message- From: Alex Yuriev [mailto:alex-lists-na...@yuriev.com] Sent: Thursday, March 03, 2011 10:18 AM To: nanog@nanog.org Subject: Anyone has a contact with IP clue at VerizonBusiness? I know it may be a stretch but is there a remote possibility that someone knows anyone inside Verizon Business who has an ounce of clue about IPv4 address allocation and routing? It seems the panic over IPv4 scarcity is resulting in the most peculiar ideas bubbling up in the IP provisioning side which must be stomped out of existence before such ideas create signigicant connectivity issues. Thanks, Alex
RE: verizon (as701/mci/worldcom/alternet/uunet) ipv6 contact needed
Hey - send me what info you do have about your account and I will try to point you in the right direction. (Same goes for anyone else having similar v6 probs) --Heather -Original Message- From: jason jeffries [mailto:jjeffr...@labs.net] Sent: Wednesday, February 09, 2011 12:57 PM To: nanog@nanog.org Subject: verizon (as701/mci/worldcom/alternet/uunet) ipv6 contact needed I hate to do this to ya'll again... but I need to talk to someone in as701/Verizon-land that can get us IPv6 connectivity on our existing circuit. The unfailingly awesome technical persons behind the help email addresses at 701 told us to take it to our account rep, and therein lies the problem. Verizon _used to be_ the ILEC here, and we ordered this circuit in some CLECy way that apparently means we don't have any of the usual credentials or account managers and blahblahlblah other things that I don't care about. What it comes down to is: Multiple attempts by our suited idiots to contact your suited idiots have failed. If a technical-type person can point me in the right direction, it'd be much appreciated. thanks! jason jeffries - jjeffries at labs.net labyrinth solutions - as26097
Agenda for Miami
Hopefully posted soonish? Less than 3 weeks to the meeting, the early registration window has passed and there is still no agenda. Thanks, --h ~*~*~*~*~*~*~*~*~*~*~*~*~*~*~*~*~*~*~*~*~*~*~* Heather Schiller Network Security - Verizon Business 1.800.900.0241secur...@verizonbusiness.com
RE: Definitive Guide to IPv6 adoption
-Original Message- From: Jack Bates [mailto:jba...@brightok.net] Sent: Monday, October 18, 2010 5:12 PM To: Franck Martin Cc: nanog@nanog.org Subject: Re: Definitive Guide to IPv6 adoption On 10/18/2010 3:51 PM, Franck Martin wrote: So they can't run their own services from home and have to request premium connectivity from you? Beside the IPv4 scarcity mentality we have the Telco mentality to fight... Happy days still ahead... Of course they can run their own services at home. How does renumber effect that (outside of poor v6 implementations at this late stage)? v6 is designed to support multiple prefixes and the ability to change from one prefix to another with limited disruption, especially if I give 24 hours to complete the transition. If servers and services can't handle this, I'd say they need to improve, or the customer will need a static allocation, which we may or may not charge for (depending on how automated we make it). A sane default of rotation is appropriate for us, though, and no amount of fighting by anyone will make the Telco think that google or others have the right to track their users. It's unfair for our users who block cookies, do due diligence to not be tracked, and then we throw them to the wolves with a constant trackable prefix. HS: Where customers = spammers? The only folks I have seen ask to do 'address rotation' have either been spammers or copyright monitoring services. I have never seen a request for 'address rotation' to protect a customer from Google. Wouldn't you just tell them not to use Google's services? The *typical* residential user doesn't know and probably doesn't care whether their prefix is dynamic or static. Dynamic allocation of address space was, in part, meant to help conserve space - if the prefix was only needed for a couple hours, it could in theory be released and reused... allowing more efficient utilization of space. Now though, with always-on connections and folks wanting to access their content remotely - it makes sense to statically allocate prefixes... and the availability of addresses in IPv6 gives us the room to do this. Jack (knew this would start an argument. *sigh*)
RE: v6 bgp peer costs?
We do not charge v4 customers anything to turn up an IPv6 tunnel. If you hear otherwise, please feel free to drop me a line. Native v6 is available in atleast 31 markets, on over 210 edge devices in 701. There is a good chance that native v6 is available for most, or close enough to rehome to a v6 capable device. If native isn't available you should be offered a tunnel for free. I'm happy to try to help anyone with VZ (701/702/703/14551) with their IPv6 issues. --Heather ~*~*~*~*~*~*~*~*~*~*~*~*~*~*~*~*~*~*~*~*~*~*~* Heather Schiller Network Security - Verizon Business 1.800.900.0241secur...@verizonbusiness.com -Original Message- From: Zaid Ali [mailto:z...@zaidali.com] Sent: Wednesday, July 21, 2010 3:08 PM To: NANOG list Subject: v6 bgp peer costs? I currently have a v4 BGP session with AS 701 and recently requested a v6 BGP session to which I was told a tunnel session will be provided (Same circuit would be better but whatever!). Towards the final stage in discussions I was told that it will cost $1500. I find this quite ridiculous and it will certainly not motivate people to move to v6 if providers put a direct price tag on it. I am going through a bandwidth reseller though so I am not sure who is trying to jack me here. Has anyone here gone through a similar experience? Thanks, Zaid
RE: Inquiries to Acquire IPs
+2 so far here.. Same email, same guy, different netblocks. Spamming for IP's to spam with? --heather ~*~*~*~*~*~*~*~*~*~*~*~*~*~*~*~*~*~*~*~*~*~*~* Heather Schiller Network Security - Verizon Business 1.800.900.0241secur...@verizonbusiness.com -Original Message- From: Crist Clark [mailto:crist.cl...@globalstar.com] Sent: Friday, July 02, 2010 2:47 PM To: Nanog Subject: Inquiries to Acquire IPs We got a strange and out of the blue inquiry from someone wishing to pay us for a chunk of our ARIN allocation, Hello, According to Whois data, you company owns the following IP address space: 206.220.220.0/24 We would like to get this block of IP addresses for our business needs. Is it possible to assign this block for our company with PI (Provider Independent) or PA (Provider Assigned) status? We ready to pay about $5,000 for the net block itself and all related procedures. Would you be interested in such an offer? The amount of compensation is subject to negotiation. We're not interested, mostly because we use our allocation, but also because I think this is not allowed by our agreement with ARIN. Seems a bit fishy. I should add the sender identified himself and his company clearly. It wasn't from some free mail account. (Although it could of course be spoofed.) Is this a new thing? IP speculation as we come upon free pool depletion? A front for spammers?
Geolocation contact for Bing/Microsoft?
Can someone from Bing/MS contact me about correcting Geolocation info for some IP's. Folks are erroneously getting redirected - and I can't find any info about how to get it fixed. Thanks, --Heather ~*~*~*~*~*~*~*~*~*~*~*~*~*~*~*~*~*~*~*~*~*~*~* Heather Schiller Network Security - Verizon Business 1.800.900.0241secur...@verizonbusiness.com
RE: ARIN IP6 policy for those with legacy IP4 Space
-Original Message- From: Joe Greco [mailto:jgr...@ns.sol.net] Sent: Thursday, April 08, 2010 4:14 PM To: John Payne Cc: NANOG list Subject: Re: ARIN IP6 policy for those with legacy IP4 Space On Apr 8, 2010, at 11:36 AM, Joe Greco wrote: IPv6-only content won't be meaningful for years yet, and IPv6-only eyeballs will necessarily be given ways to reach v4 for many years to come. So again, why do WE have to encourage YOU to adopt IPv6? Why should WE care what you do to the point of creating new rules so YOU don't have to pay like everyone else? Flip it around: Why should WE care about IPv6? WE would have to sign an onerous RSA with ARIN, giving up some of our rights in the process. WE have sufficient IP space to sit it out awhile; by doing that, WE save cash in a tight economy. WE are not so large that we spend four figures without batting an eyelash, so that's attractive. You don't. No one is going to make you set up IPv6. If you don't ever want or need to reach v6 enabled hosts, that's fine... Depending on your business, you may never need to change. But maybe someday you will want to, and you can set up v6 then. For a lot of folks, especially ISP's and content providers, there is much to be gained by deploying early: operational experience, and competitive advantage. It may not all go smoothly, so the sooner folks who know they will need IPv6, get started, the more time they have to work out any kinks. I think that is one of the interesting things about this problem. Unlike y2k, the deadline is different for everyone - and depends a lot on what your business is. Seriously? an onerous RSA What, specifically, do you consider so onerous? Are there no other situations where you willingly give up certain rights in order to obtain a service, or for the betterment or stability of your community/society? When you purchase internet transit, you surely sign a contract that has some terms of service, including an Acceptable Use Policy. You likely give up the right to spam, host copyrighted works, the right to intentionally disrupt networks, etc. It's likely that your provider can terminate services for violations. Do you consider this onerous? Even if you did, it didn't stop you from purchasing service. Further, anyone who is providing IPv6-only content has cut off most of the Internet, so basically no significant content is available on IPv6- only. That means there is no motivation for US to jump on the IPv6 bandwagon. Even more, anyone who is on an IPv6-only eyeball network is cut off from most of the content of the Internet; this means that ISP's will be having to provide IPv6-to-v4 services. Either they'll be good, or if customers complain, WE will be telling them how badly their ISP sucks. *I* am personally convinced that IPv6 is great, but on the other hand, I do not see so much value in v6 that I am prepared to compel the budgeting for ARIN v6 fees, especially since someone from ARIN just described all the ways in which they fritter away money. You can get IPv6 addresses from your upstream provider, often times free of charge, you don't ever have to deal with ARIN if you don't want to. You won't ever have tosign and agreement with ARIN if you don't want to. But, if you want to get a direct allocation, you got to pay to play - and also, agree to play by the same rules that everyone else is - it's a social contract of sorts- give up some rights in order to gain some benefits. As a result, the state of affairs simply retards the uptake and adoption of v6 among networks that would otherwise be agreeable to the idea; so, tell me, do you see that as being beneficial to the Internet community at large, or not? Note that I'm taking a strongly opposing stance for the sake of debate, the reality is a bit softer. Given a moderately good offer, we'd almost certainly adopt IPv6. Moderately good offer Like getting a prefix from your provider? Probably for free, without signing anything from ARIN. Have you talked to your provider? Or a certain well known tunnel broker will give you a /48 along w/ a free tunnel. http://nlayer.net/ipv6 route-views6.routeviews.org sh bgp ipv6 2001:0590::::::/32 BGP routing table entry for 2001:590::/32 Paths: (15 available, best #6, table Default-IP-Routing-Table) Not advertised to any peer 33437 6939 4436 2001:4810::1 from 2001:4810::1 (66.117.34.140) Origin IGP, localpref 100, valid, external Last update: Thu Apr 8 20:43:30 2010 ... JG -- Joe Greco - sol.net Network Services - Milwaukee, WI - http://www.sol.net We call it the 'one bite at the apple' rule. Give me one chance [and] then I won't contact you again. - Direct Marketing Ass'n position on e-mail spam(CNN) With 24 million small businesses in the US alone, that's way too many apples.
RE: interop show network (was: legacy /8)
Might want to double check you aren't filtering, as parts of 1/8 and 2/8 have been intermittently announced by RIR's in debogonizing efforts over the last few months. Routing wise, this really isn't different from the space being assigned - better to clear up any filtering and identify routing problems or renumbering efforts you may need now before the space gets allocated, probably later this year. In fact, parts of 2/8 are being announced right now for debogon-izing: route-viewssh ip bgp 2.0.0.0/8 longer-prefixes BGP table version is 2323163774, local router ID is 128.223.51.103 Status codes: s suppressed, d damped, h history, * valid, best, i - internal, r RIB-failure, S Stale Origin codes: i - IGP, e - EGP, ? - incomplete Network Next HopMetric LocPrf Weight Path * 2.0.0.0/16 194.85.102.33 0 3277 3267 30132 12654 I --Heather -Original Message- From: John Palmer (NANOG Acct) [mailto:nan...@adns.net] Sent: Tuesday, April 06, 2010 7:37 PM To: nanog@nanog.org Subject: Re: interop show network (was: legacy /8) When do you think that 1/8, 2/8 and 50/8 will start showing up as live, assigned addresses. I don't see any of them coming in on my core routers yet. - Original Message - From: Leo Vegoda leo.veg...@icann.org To: Jon Lewis jle...@lewis.org Cc: nanog@nanog.org Sent: Monday, April 05, 2010 1:04 PM Subject: Re: interop show network (was: legacy /8) On 5 Apr 2010, at 9:13, Jon Lewis wrote: On Sun, 4 Apr 2010, Christopher Morrow wrote: [...] If we could recover them all, how many more years of IPv4 allocations would that buy us? We allocate RIRs approximately one /8 per month. So you'd have to reclaim 12 /8s to extend the allocation pool by one year. Regards, Leo
RE: ARIN IP6 policy for those with legacy IP4 Space
ARIN Region IPv6 fee waiver: https://www.arin.net/fees/fee_schedule.html#waivers In Jan 2008, the Board of Trustees decided to reduce the fee waiver incrementally over a period of 4 years. Full fees will be in effect in 2012. Can you provide rationalization why anyone should automatically get any kind of allocation? Or why legacy holders should have equivalent [IPv6] space under the same terms You can read through past iterations of this discussion over in the PPML archives. --Heather -Original Message- From: John Palmer (NANOG Acct) [mailto:nan...@adns.net] Sent: Wednesday, April 07, 2010 12:10 PM To: NANOG list Subject: ARIN IP6 policy for those with legacy IP4 Space Was looking at the ARIN IP6 policy and cannot find any reference to those who have IP4 legacy space. Isn't there an automatic allocation for those of us who have legacy IP space. If not, is ARIN saying we have to pay them a fee to use IP6? Isn't this a disincentive for us to move up to IP6? Those with legacy IP4 space should have the equivalent IP6 space under the same terms. Or am I missing something?
RE: How polluted is 1/8?
14/8 isn't all they are using internally.. 1,4,5,42 and that's just the stuff that hasn't been delegated out by IANA yet. I am sure this practice is pervasive.. and it's an issue that doesn't typically come up in talks about prepping for IPv4 depletion. Maybe it will now.. FWIW, I don't believe these netblocks are completely unusable. If RIR policies permit you to get address space for private networks, it could be allocated to an organization that understands and accepts the pollution issue because they will never intend to route the space publicly. (Such a thing does exist..) +1 volunteering to sink traffic for 1.1.1.0/24 --heather -Original Message- From: Joel Jaeggli [mailto:joe...@bogus.com] Sent: Wednesday, February 03, 2010 11:09 AM To: Mirjam Kuehne Cc: nanog@nanog.org Subject: Re: How polluted is 1/8? It should be of no surprise to anyone that a number of the remaining prefixes are something of a mess(somebody ask t-mobile how they're using 14/8 internally for example). One's new ipv4 assignments are going to be of significantly lower quality than the one received a decade ago, The property is probably transitive in that the overall quality of the ipv4 unicast space is declining... The way to reduce the entropy in a system is to pump more energy in, there's always the question however of whether that's even worth it or not. joel Mirjam Kuehne wrote: Hello, After 1/8 was allocated to APNIC last week, the RIPE NCC did some measurements to find out how polluted this block really is. See some surprising results on RIPE Labs: http://labs.ripe.net/content/pollution-18 Please also note the call for feedback at the bottom of the article. Kind Regards, Mirjam Kuehne RIPE NCC
