% whois -h whois.ripe.net AS1712 aut-num: AS1712 as-name: FR-RENATER-ENST descr: Ecole Nationale Superieure des Telecommunications, descr: Paris, France. descr: FR % whois -h whois.arin.net AS1712 OrgName: Twilight Communications City: Wallis StateProv: TX Country: US And, yes, AS 1712 is actually used by both and announced :-(
Looks like FR-RENATER-ENST is in the wrong: 1708-1728 Assigned by ARIN whois.arin.net (source: http://www.iana.org/assignments/as-numbers/ ) Jeff On Mon, Nov 23, 2009 at 10:10 AM, Stephane Bortzmeyer <bortzmeyer@nic.fr> wrote:
% whois -h whois.ripe.net AS1712
aut-num: AS1712 as-name: FR-RENATER-ENST descr: Ecole Nationale Superieure des Telecommunications, descr: Paris, France. descr: FR
% whois -h whois.arin.net AS1712
OrgName: Twilight Communications City: Wallis StateProv: TX Country: US
And, yes, AS 1712 is actually used by both and announced :-(
-- Jeffrey Lyon, Leadership Team jeffrey.lyon@blacklotus.net | http://www.blacklotus.net Black Lotus Communications of The IRC Company, Inc. Follow us on Twitter at http://twitter.com/ddosprotection to find out about news, promotions, and (gasp!) system outages which are updated in real time. Platinum sponsor of HostingCon 2010. Come to Austin, TX on July 19 - 21 to find out how to "protect your booty."
On Mon, Nov 23, 2009 at 10:13:58AM -0500, Jeffrey Lyon <jeffrey.lyon@blacklotus.net> wrote a message of 42 lines which said:
Looks like FR-RENATER-ENST is in the wrong:
You mean RIPE-NCC is wrong? Because this AS is used by ENST for many years and is registered in the RIPE database...
* Jeffrey Lyon:
Looks like FR-RENATER-ENST is in the wrong:
1708-1728 Assigned by ARIN whois.arin.net (source: http://www.iana.org/assignments/as-numbers/ )
It could have been ERXed (or whatever the process is called for AS numbers). -- Florian Weimer <fweimer@bfk.de> BFK edv-consulting GmbH http://www.bfk.de/ Kriegsstraße 100 tel: +49-721-96201-1 D-76133 Karlsruhe fax: +49-721-96201-99
On Mon, 23 Nov 2009, Stephane Bortzmeyer wrote: > % whois -h whois.ripe.net AS1712 > as-name: FR-RENATER-ENST > > % whois -h whois.arin.net AS1712 > OrgName: Twilight Communications That would be ARIN, rather than RIPE: http://www.iana.org/assignments/as-numbers/as-numbers.xml "1708-1728 Assigned by ARIN whois.arin.net" > And, yes, AS 1712 is actually used by both and announced :-( Ouch, that's unfortunate. -Bill
On Mon, Nov 23, 2009 at 10:41 AM, Bill Woodcock <woody@pch.net> wrote:
On Mon, 23 Nov 2009, Stephane Bortzmeyer wrote: > % whois -h whois.ripe.net AS1712 > as-name: FR-RENATER-ENST > > % whois -h whois.arin.net AS1712 > OrgName: Twilight Communications
That would be ARIN, rather than RIPE:
http://www.iana.org/assignments/as-numbers/as-numbers.xml "1708-1728 Assigned by ARIN whois.arin.net"
> And, yes, AS 1712 is actually used by both and announced :-(
Ouch, that's unfortunate.
at least they are protected from eachother... In all seriousness though, how does this get fixed? and... who has to renumber? :)
On Nov 23, 2009, at 10:50 03AM, Christopher Morrow wrote:
On Mon, Nov 23, 2009 at 10:41 AM, Bill Woodcock <woody@pch.net> wrote:
On Mon, 23 Nov 2009, Stephane Bortzmeyer wrote:
% whois -h whois.ripe.net AS1712 as-name: FR-RENATER-ENST
% whois -h whois.arin.net AS1712 OrgName: Twilight Communications
That would be ARIN, rather than RIPE:
http://www.iana.org/assignments/as-numbers/as-numbers.xml "1708-1728 Assigned by ARIN whois.arin.net"
And, yes, AS 1712 is actually used by both and announced :-(
Ouch, that's unfortunate.
at least they are protected from eachother...
So much so that they probably can't even email each other to discuss it... --Steve Bellovin, http://www.cs.columbia.edu/~smb
Ouch, that's unfortunate.
at least they are protected from eachother...
So much so that they probably can't even email each other to discuss it...
--Steve Bellovin, http://www.cs.columbia.edu/~smb<http://www.cs.columbia.edu/%7Esmb>
Well, unless they have default routes... :)
In all seriousness though, how does this get fixed? and... who has to renumber? :)
luckily, it's not a renumber in the ip address sense. but some router jock[ette]s are gonna be even more overworked than usual. how to detect if there are more instances? how to prevent new instances, both asn and ip? randy
On 11/23/09 7:25 PM, "Randy Bush" <randy@psg.com> wrote:
how to prevent new instances, both asn and ip?
The whole value of the RIR is to guarantee this uniqueness. This problem should not have happened. The fact that it has is troublesome. I¹ll make a guess that this is a result of a clerical error somewhere in the chain... The answer to the above question seems to be stricter process. - Alain.
On Mon, 23 Nov 2009, Durand, Alain wrote:
On 11/23/09 7:25 PM, "Randy Bush" <randy@psg.com> wrote:
how to prevent new instances, both asn and ip?
The whole value of the RIR is to guarantee this uniqueness. This problem should not have happened. The fact that it has is troublesome. I¹ll make a guess that this is a result of a clerical error somewhere in the chain... The answer to the above question seems to be stricter process.
Even after that clerical error happened, the subsequent error of assigning an ASN that's already assigned should never have happened. It seems someone (probably multiple someones) never considered this possibility. When assigning a subnet of our IP space to a customer or internal network, first I look for a suitably sized block marked as "open" in our IP space. Then I check our IGP to make sure that block isn't currently routed somewhere. It's a little disappointing that I ever find it is...but it happens. It just happened yesterday in fact. A customer who had some servers turned down had their subnet marked as available for re-use, but it looks like they still have a few servers online in that VLAN and the space obviously isn't ready for re-use. Is it too much to ask that the RIRs query each other's whois servers for an ASN before assigning that ASN?...just to make sure an ASN they think they're responsible for and about to assign hasn't already been assigned by another RIR? That should have been an item on the RIR ASN assignment checklist from the beginning. ---------------------------------------------------------------------- Jon Lewis | I route Senior Network Engineer | therefore you are Atlantic Net | _________ http://www.lewis.org/~jlewis/pgp for PGP public key_________
On Mon, Nov 23, 2009 at 08:25:33PM -0500, Jon Lewis <jlewis@lewis.org> wrote a message of 44 lines which said:
Is it too much to ask that the RIRs query each other's whois servers for an ASN before assigning that ASN?...
Yes, very good idea. And to check the BGP public routing table also (belts and suspenders...)
On Mon, Nov 23, 2009 at 07:42:34PM -0500, Durand, Alain <alain_durand@cable.comcast.com> wrote a message of 14 lines which said:
The whole value of the RIR is to guarantee this uniqueness. This problem should not have happened.
Indeed. It is a big blunder from the RIR system. I have reported it to RIPE-NCC (ticket NCC#2009116087) but not to ARIN (I'm not used to interact with them, if someone wants to relay the information...)
On Mon, Nov 23, 2009 at 7:25 PM, Randy Bush <randy@psg.com> wrote:
In all seriousness though, how does this get fixed? and... who has to renumber? :)
luckily, it's not a renumber in the ip address sense. but some router jock[ette]s are gonna be even more overworked than usual.
hope for their sake it's just 1 router :) and 2 transits ... if they have internal bgp setup (more than one router in their peering/transit edge) it's going to cause them some pain :( (at least with only 1 router and 2 bgp peers you could hope to static route around the maintenance event)
how to detect if there are more instances?
o Should some form of 'scrape routeviews before assignment' happen at the RIR? (if you don't like o RV, pick another 2-3 sources of data) o How do you make sure each RIR does this act? o Should the customer check public data sources before acceptance? o Is there a 30 day revoke/return dance for Number Resources?
how to prevent new instances, both asn and ip?
See above ... It seems sensible to check existing data sources, if that can be automated easily enough? -chris
On Mon, 23 Nov 2009, Christopher Morrow wrote:
how to detect if there are more instances?
o Should some form of 'scrape routeviews before assignment' happen at the RIR? (if you don't like o RV, pick another 2-3 sources of data) o How do you make sure each RIR does this act? o Should the customer check public data sources before acceptance? o Is there a 30 day revoke/return dance for Number Resources?
Checking "global BGP" only works if the ASN is being announced at that instant. That ought to be one of the due diligence steps, but so should checking the various RIR whois servers. Lots of ASNs have been assigned but aren't visible in the global table. ---------------------------------------------------------------------- Jon Lewis | I route Senior Network Engineer | therefore you are Atlantic Net | _________ http://www.lewis.org/~jlewis/pgp for PGP public key_________
On Tue, Nov 24, 2009 at 12:32 AM, Jon Lewis <jlewis@lewis.org> wrote:
On Mon, 23 Nov 2009, Christopher Morrow wrote:
how to detect if there are more instances?
o Should some form of 'scrape routeviews before assignment' happen at the RIR? (if you don't like o RV, pick another 2-3 sources of data) o How do you make sure each RIR does this act? o Should the customer check public data sources before acceptance? o Is there a 30 day revoke/return dance for Number Resources?
Checking "global BGP" only works if the ASN is being announced at that instant. That ought to be one of the due diligence steps, but so should checking the various RIR whois servers. Lots of ASNs have been assigned but aren't visible in the global table.
sure, pick 2-3 ways to check was my point... I ain't writin' RIR policy in nanog maillist traffic :) I presume also there's some '80% check is good enough' standard that's applied along the way because I doubt you'll ever get 100% certainty in this sort of thing, sadly. -Chris
---------------------------------------------------------------------- Jon Lewis | I route Senior Network Engineer | therefore you are Atlantic Net | _________ http://www.lewis.org/~jlewis/pgp for PGP public key_________
At 0:32 -0500 11/24/09, Jon Lewis wrote:
Lots of ASNs have been assigned but aren't visible in the global table.
And not all global networks (needing unique numbering) connect to the global "public" internet. At 8:36 +0100 11/24/09, Stephane Bortzmeyer wrote:
Yes, very good idea. And to check the BGP public routing table also (belts and suspenders...)
That's a good check, but not sufficient. When last we fixed an ASN registration, the check showed that other ASN's we had were not seen in that table. We just mentioned "they are used on another inter-network" and passed. Kinda like "belts and suspenders" but let's make sure the fly is shut too. ;) At 15:58 +0900 11/24/09, Randy Bush wrote:
owned resources may not be announced or visible universally.
Right...or maybe in a different universe.
existing data sources deeply suck. rir source data are in different formats, owner identies are not even unique in one rir (how many names does goog have in arin?), let alone coordinated across rirs, much historical data is missing, ...
This is why an inter-registry database inspection tool is needed. The traditional one is WhoIs - which as Randy mentions is too vague in content. (The WhoIs spec only says something about TCP to port 43...and nothing about the query/response formats.) A tool like IRIS is on the shelf that could be a platform from which to build something better. Checking the global public internet tables is a good first step, but that's not all that is needed. Such a step only gives credence to uniqueness, but it doesn't guarantee it. -- -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Edward Lewis NeuStar You can leave a voice message at +1-571-434-5468 As with IPv6, the problem with the deployment of frictionless surfaces is that they're not getting traction.
On 2009-11-23, at 21:32, Jon Lewis wrote:
Checking "global BGP" only works if the ASN is being announced at that instant.
How do you announce an ASN? Are you suggesting that I should be able to block the assignment of particular ASNs by simply including them in an AS_PATH attribute on a route I originate, and making sure that route shows up in route-views? Cool. :-) Joe
On 2009-11-24, at 20:02, Randy Bush wrote:
Checking "global BGP" only works if the ASN is being announced at that instant. How do you announce an ASN?
read a basic bgp primer and look at as-path attribute
Right. You can't advertise an ASN; you can only advertise a route and include an AS_PATH attribute on it which makes mention of a particular AS number. My point is that in the absence of any mechanism for announcing an ASN, a plan to gate assignment of numbers based on an announcement doesn't make any sense. Even in the loose sense of the phrase that you seem to prefer it's trivial (and arguably legitimate, although I appreciate that not everybody shares my libertarian views on AS_PATH attribute construction) for anybody at all to insert an AS number into an AS_PATH, and for the route bearing that AS_PATH attribute to propagate globally, whatever that means. So automated checking of "the BGP tables" for "existing announcements of an ASN" doesn't seem very helpful.
frackin' intentionally silly questions
Apologies for expecting anybody to read beyond the first line of my reply. Joe
Right. You can't advertise an ASN you can only advertise a route and include an AS_PATH attribute on it which makes mention of a particular AS number.
that bit of biff-like pedantry quickly leads to you can't advertise a prefix. a bgp announcement has, in the case of ip unicast, an nlri and, among other things, an as-path. see rfc 1771 4.3 on Path Attributes. as to what is being announced and what is merely loitering waiting for a hot pick-up, you can work that out with your mullah, priest, rabbi, spouse, ... for unusual utility of intentionally announcing a particular asn, see as-path poisoning, e.g. lorenzo's thesis [0], the talk which was banned at nanog [1], or the full paper [2].
My point is that in the absence of any mechanism for announcing an ASN, a plan to gate assignment of numbers based on an announcement doesn't make any sense.
seeing if an asn is in a currently-announced as-path is useful, as has been pointed out in this discussion. and it very well might have caught the problem at hand. the problem is that it is far from definitive as bgp presents a highly biased view (see [1] and [2]), and an asn may be held but not announced. but, as chris morrow said, every little bit helps. randy -- [0] - http://www.colitti.com/lorenzo/publications/phdthesis/thesis.pdf [1] - http:archive.psg.com/091006.nag-default.pdf [2] - http://portal.acm.org/citation.cfm?id=1644893.1644923&coll=portal&dl=ACM&type=series&idx=SERIES10693&part=series&WantType=Proceedings&title=IMC acm member portal, sorry. those really interested, email me for a copy
On 2009-11-24, at 20:58, Randy Bush wrote:
Right. You can't advertise an ASN you can only advertise a route and include an AS_PATH attribute on it which makes mention of a particular AS number.
that bit of biff-like pedantry quickly leads to you can't advertise a prefix.
Apologies if the pedantry seems unnecessary. I think the parallel between the announcement of a route (which has inherent reachability information contained within it) and use of an ASN in an AS_PATH attribute (which doesn't always) are different with respect to identifying use of a resource. Overloading "advertise" for both suggests you can identify use of a resource elsewhere using the same measurement technique, which I think is broken logic.
a bgp announcement has, in the case of ip unicast, an nlri and, among other things, an as-path. see rfc 1771 4.3 on Path Attributes.
I used the word "route" in the sense that it's defined in 4271.
as to what is being announced and what is merely loitering waiting for a hot pick-up, you can work that out with your mullah, priest, rabbi, spouse, ...
As a divorced atheist I guess I'll just read RFCs :-)
for unusual utility of intentionally announcing a particular asn, see as-path poisoning, e.g. lorenzo's thesis [0], the talk which was banned at nanog [1], or the full paper [2].
Josh and I also talked about it at NANOG 24. I remember using it to poison routes advertised through certain edges of AS 1221 a decade ago after the idea was suggested to me by Geoff Huston, and I'm sure it was probably old news then.
My point is that in the absence of any mechanism for announcing an ASN, a plan to gate assignment of numbers based on an announcement doesn't make any sense.
seeing if an asn is in a currently-announced as-path is useful, as has been pointed out in this discussion.
I don't think it's as simple as people have suggested. The fact that nobody has ever seen a particular number present in an AS_PATH attribute might mean that the ASN has never been configured on a router, or it might mean that nobody has ever taken a measurement from a router who has seen such a route. The fact that someone has seen a particular number present in an AS_PATH attribute might mean that that number has been used for a particular autonomous system, or it might mean that someone is doing something (intentional or otherwise) with AS_PATHs for their own personal reasons. The topic of this thread is really concerned with database hygiene in a distributed system which, as you have pointed out repeatedly, lacks procedural or mathematical rigour. Checking whether or not a particular AS_PATH regex matches anything in one or more RIBs might tell you something, or it might give you clues as to who to call to find out more, but it can never tell you anything definitively. Definitive knowledge sure seems like it's what you want if your job is to guarantee uniqueness. It seems to me that at some point we need to stop trying to put dresses on the pig. Joe
On Wed, Nov 25, 2009 at 1:34 AM, Joe Abley <jabley@hopcount.ca> wrote:
It seems to me that at some point we need to stop trying to put dresses on the pig.
how, given where we are today, do you do that? I agree that presence of an ASN in routing data (in as_paths really) isn't proof of existence/use/abuse but not checking is not helping. 100% perfect would be awesome, today we have less than 100%, we could be doing a job closer to 100% by acting on some low-hanging fruit. To really move forward and get to 100% (or as near as we can hope for) what steps/actions/changes do you propose? It seems that at least RIPE/ARIN have their attentioned aimed this way now :) -Chris
On 2009-11-24, at 23:14, Christopher Morrow wrote:
To really move forward and get to 100% (or as near as we can hope for) what steps/actions/changes do you propose? It seems that at least RIPE/ARIN have their attentioned aimed this way now :)
Apparently I have accidentally climbed a soapbox whilst trying to explain what I thought was a fairly simple point. I'll get down. I am fairly sure the RIRs don't need my help in cleaning their databases or figuring out clever ways to keep them consistent in the future. Given the experience with ERX presumably there is enthusiasm for future transfers to be handled more rigourously. Joe
On Tue, 24 Nov 2009, Joe Abley wrote:
On 2009-11-23, at 21:32, Jon Lewis wrote:
Checking "global BGP" only works if the ASN is being announced at that instant.
How do you announce an ASN?
Ok...bad wording. s/announced/used to announce or propagate one or more routes/
Are you suggesting that I should be able to block the assignment of particular ASNs by simply including them in an AS_PATH attribute on a route I originate, and making sure that route shows up in route-views?
No...but that would hopefully be cause for further investigation before an ASN is assigned. With multiple orgs assigning from the same small pool of numbers, and an early history of, shall we say, incomplete record keeping, a little extra caution could avoid a lot of pain. I would hope the number of orgs that would pollute the global table with bogus AS Paths for the purpose of making more work for ARIN/RIPE/APNIC/etc. is not very large. If you want to announce certain routes with "bogus" AS Paths to keep certain networks from seeing them, that's one thing, but why would you do this with ASNs not currently assigned? ---------------------------------------------------------------------- Jon Lewis | I route Senior Network Engineer | therefore you are Atlantic Net | _________ http://www.lewis.org/~jlewis/pgp for PGP public key_________
On Tue, Nov 24, 2009 at 07:54:08PM -0800, Joe Abley <jabley@hopcount.ca> wrote a message of 13 lines which said:
Are you suggesting that I should be able to block the assignment of particular ASNs by simply including them in an AS_PATH attribute on a route I originate, and making sure that route shows up in route-views?
No one suggested a complete, blind and automatic blocking of the assignment. Just a suggestion to RIRs to check if the AS number they are ready to assign is used in an AS path somewhere and, if so, to raise a flag, to assign a physical person on the matter, to investigate, to check the databases, etc. This would have catched the AS 1712 issue.
how to detect if there are more instances?
o Should some form of 'scrape routeviews before assignment' happen at the RIR? (if you don't like o RV, pick another 2-3 sources of data) o How do you make sure each RIR does this act? o Should the customer check public data sources before acceptance? o Is there a 30 day revoke/return dance for Number Resources?
how to prevent new instances, both asn and ip?
See above ... It seems sensible to check existing data sources, if that can be automated easily enough?
owned resources may not be announced or visible universally. existing data sources deeply suck. rir source data are in different formats, owner identies are not even unique in one rir (how many names does goog have in arin?), let alone coordinated across rirs, much historical data is missing, ... dual ownership is needed for transfer. so i am thinking along the lines of an aged report of cert conflicts. maybe "bob and alice have both owned 42.666.0.0/15 for 77 days." of course this begs the issue of irs not having unique single IDs for bob and alice. randy
* Christopher Morrow:
In all seriousness though, how does this get fixed?
AS number translation, perhaps? But more seriously, in general, it is impossible to tell if a conflict between RIPE and ARIN is real, or is the result of lack of updates after mergers and acquisitions on one of the sides. A good example in this area is 53.0.0.0/8, which has a rather interesting history. Another one is AS702. -- Florian Weimer <fweimer@bfk.de> BFK edv-consulting GmbH http://www.bfk.de/ Kriegsstraße 100 tel: +49-721-96201-1 D-76133 Karlsruhe fax: +49-721-96201-99
On Nov 23, 2009, at 10:50 AM, Christopher Morrow wrote:
In all seriousness though, how does this get fixed?
It's being addressed now, but requires both RIPE and ARIN to work with the respective ASN holders. Standby for an update once that step has been completed. The more interesting question is how this could happen, and we're busy looking into that at present. The AS 1707 assignment goes back to Internic days (i.e. pre-1997) but the remainder of the ASN block (AS 1708 to AS 1728) is marked "assigned by ARIN" at the IANA but had not actually been assigned until very recently. (ARIN did a reconciliation in July 2009 of all ASNs marked as “assigned by ARIN” with our own internal records to find out whether any holes existed, and began assigning such ASNs in August 2009, including AS numbers in the range 1708 thru 1726). We're working with RIPE to determine how these numbers were put into usage via the RIPE DB, and will come up with appropriate steps to prevent recurrence once we fully understand the root cause. /John John Curran President and CEO ARIN
John Curran wrote:
On Nov 23, 2009, at 10:50 AM, Christopher Morrow wrote:
In all seriousness though, how does this get fixed?
It's being addressed now, but requires both RIPE and ARIN to work with the respective ASN holders. Standby for an update once that step has been completed. The more interesting question is how this could happen, and we're busy looking into that at present.
The AS 1707 assignment goes back to Internic days (i.e. pre-1997) but the remainder of the ASN block (AS 1708 to AS 1728) is marked "assigned by ARIN" at the IANA but had not actually been assigned until very recently. (ARIN did a reconciliation in July 2009 of all ASNs marked as “assigned by ARIN” with our own internal records to find out whether any holes existed, and began assigning such ASNs in August 2009, including AS numbers in the range 1708 thru 1726).
We're working with RIPE to determine how these numbers were put into usage via the RIPE DB, and will come up with appropriate steps to prevent recurrence once we fully understand the root cause.
/John
John Curran President and CEO ARIN
FWIW, I searched for any historical registrations from this block in the RADB and found a number of routes with an origin of AS1717. They date from 1995 and were registered for the Université Pierre et Marie Curie by Renater. They have long since been removed from the RADB. Here's an example -- route: 132.166.0.0/15 descr: RENATER_CIDR descr: Universite Pierre et Marie Curie descr: 4 place Jussieu 75252 PARIS CEDEX 05 descr: FRANCE origin: AS1717 advisory: AS690 1:1800 2:1239(144) 3:1133 4:1674 comm-list: COMM_NSFNET mnt-by: MAINT-AS1717 changed: rensvp@renater.fr 950510 source: RADB -Larry Blunk Merit
Bill Woodcock wrote:
On Mon, 23 Nov 2009, Stephane Bortzmeyer wrote: > % whois -h whois.ripe.net AS1712 > as-name: FR-RENATER-ENST > > % whois -h whois.arin.net AS1712 > OrgName: Twilight Communications
That would be ARIN, rather than RIPE:
http://www.iana.org/assignments/as-numbers/as-numbers.xml "1708-1728 Assigned by ARIN whois.arin.net"
> And, yes, AS 1712 is actually used by both and announced :-(
Ouch, that's unfortunate.
-Bill
It's not just AS1712. AS1707 - AS1726 appear to all have been allocated to Renater. AS1707 was ERX'd to RIPE on Sep 9, 2002, but it appears that AS1708-AS1726 were missed and have subsequently been reallocated by ARIN (between Aug 18 and Aug 21, 2009) -Larry
On Mon, Nov 23, 2009 at 11:06:31AM -0500, Larry Blunk <ljb@merit.edu> wrote a message of 29 lines which said:
it appears that AS1708-AS1726 were missed and have subsequently been reallocated by ARIN (between Aug 18 and Aug 21, 2009)
Now, interesting question: what can we do to solve the problem? Who should act? I am quite surprised that it is possible to have the same AS number in two different RIRs, to different organizations :-( IP resources certificates will be difficult to deploy here.
On Mon, Nov 23, 2009 at 11:37 AM, Stephane Bortzmeyer <bortzmeyer@nic.fr> wrote:
On Mon, Nov 23, 2009 at 11:06:31AM -0500, Larry Blunk <ljb@merit.edu> wrote a message of 29 lines which said:
it appears that AS1708-AS1726 were missed and have subsequently been reallocated by ARIN (between Aug 18 and Aug 21, 2009)
Now, interesting question: what can we do to solve the problem? Who should act?
I am quite surprised that it is possible to have the same AS number in two different RIRs, to different organizations :-( IP resources certificates will be difficult to deploy here.
oh! we can test out that 'transfer' policy now! :) lookie it's the ip-resources grey market arriving early (or on-time, depending upon which of Geoff's presentations you read over the years) -Chris
It's not just AS1712. AS1707 - AS1726 appear to all have been allocated to Renater. AS1707 was ERX'd to RIPE on Sep 9, 2002, but it appears that AS1708-AS1726 were missed and have subsequently been reallocated by ARIN (between Aug 18 and Aug 21, 2009)
this failure is one of the joys of per-rir trust anchors randy
On Tue, Nov 24, 2009 at 07:58:00AM +0900, Randy Bush wrote:
It's not just AS1712. AS1707 - AS1726 appear to all have been allocated to Renater. AS1707 was ERX'd to RIPE on Sep 9, 2002, but it appears that AS1708-AS1726 were missed and have subsequently been reallocated by ARIN (between Aug 18 and Aug 21, 2009)
this failure is one of the joys of per-rir trust anchors
I don't see operators jumping at the idea of central trust anchor myself, no more than I see everyone ready to sign the root zone. I see some gTLD and ccTLD operators ready, but not all gTLD and ccTLD operators want it signed. There is perhaps the same issue here. Then again, ARIN doesn't say that an allocated resource is actually usable, they've specifically ducked that one in the past with address space on blacklists or bogon filters... I am curious to see their response now. - Jared -- Jared Mauch | pgp key available via finger from jared@puck.nether.net clue++; | http://puck.nether.net/~jared/ My statements are only mine.
Jared Mauch wrote:
On Tue, Nov 24, 2009 at 07:58:00AM +0900, Randy Bush wrote:
It's not just AS1712. AS1707 - AS1726 appear to all have been allocated to Renater. AS1707 was ERX'd to RIPE on Sep 9, 2002, but it appears that AS1708-AS1726 were missed and have subsequently been reallocated by ARIN (between Aug 18 and Aug 21, 2009)
this failure is one of the joys of per-rir trust anchors
I don't see operators jumping at the idea of central trust anchor myself, no more than I see everyone ready to sign the root zone.
Not everyone gets to sign the IANA root zone.
I see some gTLD and ccTLD operators ready, but not all gTLD and ccTLD operators want it signed. There is perhaps the same issue here.
I'm looking at the registry service requests for .museum, .org, .com/.net/.name, .biz, and writing .cat's. What gTLD operators are you looking at? What ccTLD operators are you looking at?
Then again, ARIN doesn't say that an allocated resource is actually usable, they've specifically ducked that one in the past with address space on blacklists or bogon filters... I am curious to see their response now.
- Jared
On Mon, 23 Nov 2009, Jared Mauch wrote:
I don't see operators jumping at the idea of central trust anchor myself, no more than I see everyone ready to sign the root zone.
You know the root zone is supposed to be signed next week? http://www.ripe.net/ripe/meetings/ripe-59/presentations/uploads//presentatio... Tony. -- f.anthony.n.finch <dot@dotat.at> http://dotat.at/ GERMAN BIGHT HUMBER: SOUTHWEST 5 TO 7. MODERATE OR ROUGH. SQUALLY SHOWERS. MODERATE OR GOOD.
On Nov 24, 2009, at 1:57 PM, Tony Finch wrote:
On Mon, 23 Nov 2009, Jared Mauch wrote:
I don't see operators jumping at the idea of central trust anchor myself, no more than I see everyone ready to sign the root zone.
You know the root zone is supposed to be signed next week?
http://www.ripe.net/ripe/meetings/ripe-59/presentations/uploads//presentatio...
Yes. I also saw the presentation at IETF in Hiroshima on this. The issue of zone signing is going to be interesting as some nation-states (ccTLD) have been known to speak-up about their issues with the signing of the zone. I'm not saying these things will never happen, just they won't happen on a timescale that some would prefer (or would have preferred, eg: last summer or earlier). - Jared
* Jared Mauch:
The issue of zone signing is going to be interesting as some nation-states (ccTLD) have been known to speak-up about their issues with the signing of the zone.
Which ones? In most cases, ccTLDs don't represent nation states, and vice versa. -- Florian Weimer <fweimer@bfk.de> BFK edv-consulting GmbH http://www.bfk.de/ Kriegsstraße 100 tel: +49-721-96201-1 D-76133 Karlsruhe fax: +49-721-96201-99
The RENATER I'm peering with is AS2200. From my PoV, AS1712 is announced by as174 and as701, with all the respect do to them I doubt their announcing RENATER. From what I receive from as2200: * 137.194.0.0 194.68.129.102 0 2200 2200 2422 1712 i And from bgp table (sniped): sh ip bgp path 1712$ Address Hash Refcount Metric Path 0x52D8F878 352 2 1001 174 1712 i 0x575A9088 1320 1 0 6453 174 1712 i 0x2274494C 1849 2 0 6453 701 1712 ? 0x52CF7AD0 1986 1 0 2200 2200 2422 1712 i 0x66B90AD0 3421 1 0 2200 2422 1712 i Indeed: WTF. Stephane Bortzmeyer a écrit :
% whois -h whois.ripe.net AS1712
aut-num: AS1712 as-name: FR-RENATER-ENST descr: Ecole Nationale Superieure des Telecommunications, descr: Paris, France. descr: FR
% whois -h whois.arin.net AS1712
OrgName: Twilight Communications City: Wallis StateProv: TX Country: US
And, yes, AS 1712 is actually used by both and announced :-(
On Mon, Nov 23, 2009 at 05:29:59PM +0100, Benjamin BILLON <bbillon-ml@splio.fr> wrote a message of 36 lines which said:
The RENATER I'm peering with is AS2200.
The AS number was allocated (ten years ago, as noticed by Frédéric) through the LIR Renater to the customer ENST (now Télécom Paris Tech). It does not mean it is today announced by Renater.
Arin CREATE DATE: 2009-08-19 RIPE CREATE DATE: 1999-10-14 well, we all know the serious of these compagny.... @+ Le lundi 23 novembre 2009 à 16:10 +0100, Stephane Bortzmeyer a écrit :
% whois -h whois.ripe.net AS1712
aut-num: AS1712 as-name: FR-RENATER-ENST descr: Ecole Nationale Superieure des Telecommunications, descr: Paris, France. descr: FR
% whois -h whois.arin.net AS1712
OrgName: Twilight Communications City: Wallis StateProv: TX Country: US
And, yes, AS 1712 is actually used by both and announced :-(
RIS Routing History for AS1712 since 2001: AS From To avg #peers 12.196.66.0/23 AS1712 20091026 08:00Z 20091026 16:00Z 88 137.194.0.0/16 AS1712 20011220 16:00Z 20031231 16:00Z 39 20040101 00:00Z 20040312 16:00Z 54 20040315 08:00Z 20040402 16:00Z 44 20040405 08:00Z 20061231 16:00Z 63 20070101 00:00Z 20091122 00:00Z 101 74.118.148.0/22 AS1712 20091026 08:00Z 20091122 00:00Z 88 74.118.148.0/24 AS1712 20091018 00:00Z 20091026 00:00Z 83 74.118.149.0/24 AS1712 20091019 16:00Z 20091026 00:00Z 86 74.118.150.0/24 AS1712 20091020 00:00Z 20091026 00:00Z 87 74.118.151.0/24 AS1712 20091020 00:00Z 20091026 00:00Z 87 See also colorful graph attached. Interpretation: 137.194.0.0/16 is assigned to ENST and has been announced by AS1712 since 2001. See also: http://albatross.ripe.net/cgi-bin/rex.pl?type=all&res=137.194.0.0/16&stime=2001-01-01&etime=2009-11-23&page=routing&cf=1&af=1 Other announcements from AS1712 have appeared on 20091018 imost ceased on 20091026, about a month ago. 74.118.148.0/22 is still there and needs to be addressed. http://albatross.ripe.net/cgi-bin/rex.pl?res=74.118.148.0%2F22&type=all&stime=2008-11-23&etime=2009-11-23&cf=1&af=1&page=routing I am sure the RIRs concerned will learn from this and this thread already contains good suggestions about what/how to learn. Daniel PS: And yes we are going to make the REX tool for querying ASes available soon. Keep watching labs.ripe.net.
On 24.11 08:48, Daniel Karrenberg wrote:
RIS Routing History for AS1712 since 2001:
...
PS: And yes we are going to make the REX tool for querying ASes available soon. Keep watching labs.ripe.net.
OK, by popular demand: Before we release the nicely presented version, here is a direct link to some of the RIS data which can be queried by AS: http://albatross.ripe.net/cgi-bin/inrdb-risribl.cgi?res=1712&rrc=aggr&match=x There are links at the bottom for explanations and a link at the top for asking different questions. Note again that this is not a production service, it is raw data that needs interpretation and a nicer presentation is coming soon. Daniel
At 18:29 24/11/2009 +0900, Randy Bush wrote:
RIS Routing History for AS1712 since 2001:
on what date was AS1712 assigned to the current RIPE holder?
Based on: ftp://ftp.ripe.net/pub/stats/ripencc/delegated-ripencc-latest it doesn't show AS1712 ever being allocated to Renater (probably why the inter-RIR mistake happened) but the surrounding ASNs give you an idea of the timeframe: ripencc|IL|asn|1680|1|19930901|allocated ripencc|EU|asn|1707|1|19930901|allocated ripencc|EU|asn|1729|1|19930901|allocated ripencc|EU|asn|1732|1|19930901|allocated -Hank
randy
Hank Nussbacher wrote:
At 18:29 24/11/2009 +0900, Randy Bush wrote:
RIS Routing History for AS1712 since 2001:
on what date was AS1712 assigned to the current RIPE holder?
Based on: ftp://ftp.ripe.net/pub/stats/ripencc/delegated-ripencc-latest it doesn't show AS1712 ever being allocated to Renater (probably why the inter-RIR mistake happened) but the surrounding ASNs give you an idea of the timeframe:
ripencc|IL|asn|1680|1|19930901|allocated ripencc|EU|asn|1707|1|19930901|allocated ripencc|EU|asn|1729|1|19930901|allocated ripencc|EU|asn|1732|1|19930901|allocated
Since IANA says that the ASN is ARIN's to assign wouldn't that preclude another RIR from assigning it? http://www.iana.org/assignments/as-numbers/ Of course if it was already assigned when IANA said that (no dates on the link above) then maybe the fault is more IANA's for telling another RIR that they could allocate an ASN that another RIR already allocated. Who knows. It should be an interesting one to watch play out though. Justin
Justin Shore wrote:
Hank Nussbacher wrote:
At 18:29 24/11/2009 +0900, Randy Bush wrote:
RIS Routing History for AS1712 since 2001:
on what date was AS1712 assigned to the current RIPE holder?
Based on: ftp://ftp.ripe.net/pub/stats/ripencc/delegated-ripencc-latest it doesn't show AS1712 ever being allocated to Renater (probably why the inter-RIR mistake happened) but the surrounding ASNs give you an idea of the timeframe:
ripencc|IL|asn|1680|1|19930901|allocated ripencc|EU|asn|1707|1|19930901|allocated ripencc|EU|asn|1729|1|19930901|allocated ripencc|EU|asn|1732|1|19930901|allocated
Since IANA says that the ASN is ARIN's to assign wouldn't that preclude another RIR from assigning it?
ARIN didn't exist when those ASN's were assigned, RIPE NCC did.
http://www.iana.org/assignments/as-numbers/
Of course if it was already assigned when IANA said that (no dates on the link above) then maybe the fault is more IANA's for telling another RIR that they could allocate an ASN that another RIR already allocated. Who knows. It should be an interesting one to watch play out though.
Justin
Of course if it was already assigned when IANA said that (no dates on the link above) then maybe the fault is more IANA's for telling another RIR that they could allocate an ASN that another RIR already allocated.
i suspect that, in the erx project, there may have been more than one case of the iana saying "ok, X now manages this block, excpet of course for those pieces already allocated by Y and Z." and the latter were not always well defined or easily learnable, and were not registered directly with the iana, but other rirs. <rant> and the data are all buried in whois, which is not well-defined, stats files, which are not defined, etc. the rirs, in the thrall of nih (you did know that ripe/ncc invented the bicycle), spent decades not agreeing on common formats, protocols, or code. this is one result thereof. testosterone kills, and the community gets the collateral damage. randy
the joys of non-uniqueness. ULAs are (going to be) your friends. :) back in the day, the IANA was pretty careful. the contractors less so. SRI had the "connected" and "unconnected" databases - duplications abounded and when interconnection occured... renumbering ensued. this is not a new or even recent problem. It is certainly compounded by multiple actors and lack of clean slate. Yet, I beleive that there will be a desire to "do the right thing" and this will get fixed. It might even lead to better tools and inter-actor releationships. Or it could melt into a pile of goo... --bill On Wed, Nov 25, 2009 at 06:21:00AM +0900, Randy Bush wrote:
Of course if it was already assigned when IANA said that (no dates on the link above) then maybe the fault is more IANA's for telling another RIR that they could allocate an ASN that another RIR already allocated.
i suspect that, in the erx project, there may have been more than one case of the iana saying "ok, X now manages this block, excpet of course for those pieces already allocated by Y and Z." and the latter were not always well defined or easily learnable, and were not registered directly with the iana, but other rirs.
<rant>
and the data are all buried in whois, which is not well-defined, stats files, which are not defined, etc. the rirs, in the thrall of nih (you did know that ripe/ncc invented the bicycle), spent decades not agreeing on common formats, protocols, or code. this is one result thereof. testosterone kills, and the community gets the collateral damage.
randy
On 25.11 06:21, Randy Bush wrote:
Of course if it was already assigned when IANA said that (no dates on the link above) then maybe the fault is more IANA's for telling another RIR that they could allocate an ASN that another RIR already allocated.
i suspect that, in the erx project, there may have been more than one case of the iana saying "ok, X now manages this block, excpet of course for those pieces already allocated by Y and Z." and the latter were not always well defined or easily learnable, and were not registered directly with the iana, but other rirs.
<rant>
and the data are all buried in whois, which is not well-defined, stats files, which are not defined, etc. the rirs, in the thrall of nih (you did know that ripe/ncc invented the bicycle), spent decades not agreeing on common formats, protocols, or code. this is one result thereof. testosterone kills, and the community gets the collateral damage.
[Excuse the length of this. Randy just overloaded my patience circuit and I need to dissipate some testosterone induced energy. If you are only interested in details about the issue at hand, skip this message. If you are interested in a different view on (history of) the RIRs, read on.] Randy, it is absolutely unfair to shout at the RIRs and particularly at the RIPE NCC in this context and I take offence. This particular problem is caused by a record keeping error back in the days when RIRs did not even exist! So these resources never went through the hands of the RIPE NCC and were not conisdered by ERX at all. I'll leave it to ARIN to publish the detailed analysis once it is complete, but this is the essence of it. Back when I was responsible for the RIPE NCC in the 1990s, I personally spent considerable time developing and proposing exchange formats and database synchronisation tools. The RIPE NCC proposed close synchronisation of Internet number resource databases several times. This never got done because InterNIC and later ARIN resisted. It was quite frustrating. You can find polite expressions of my frustration in early RIPE NCC quarterly and annual reports if you look carefully. When APNIC was established, the RIPE NCC had close database synchroninsation with them from the start; the same occurred with AfriNIC later; both of these were achieved by definite *lack* of NIH and 'testosterone'. So if you cannot resist the urge to shout, please re-direct your shouting. This is all water under the bridge of course and we are moving on; but blaming the RIPE NCC in particular for NIH and 'testosterone' is just unfair! And no, we did not invent the bicycle, but in moments of hybris I do claim that we did in fact invent the RIR as such. ;-) I do not say everything is ideal now. However the RIRs are actively working to publish a complete set of stats files which also includes unallocated resources. This is the next best thing to full database synchronisation. APNIC and the RIPE NCC are driving this effort. In fact the track record of the RIRs is excellent so far, given the number of different resource blocks and the number of resource users. Yes, errors in historical records from two decades ago *should* be caught and all RIRs will certainly learn from this unfortunate episode. But the blanket shouting of the kind you did here is unfair, offensive and unwarranted. Respectfully Daniel
At 08:57 25/11/2009 +0100, Daniel Karrenberg wrote:
shouting. This is all water under the bridge of course and we are moving on; I do not say everything is ideal now. However the RIRs are actively working to publish a complete set of stats files which also includes unallocated resources. This is the next best thing to full database synchronisation. APNIC and the RIPE NCC are driving this effort.
Perhaps the RIRs could get together and agree on a common whois syntax so that when I check one RIR with one syntax - it would work on others as well? This issue has been around for over 7 years and I can't understand why the RIRs can't find common ground for the sake of the end users? Even if ARIN or APNIC won't accept "-B -G", then at least let their whois engine just ignore those extra parameters it doesn't understand. To me it looks like minor software changes. -Hank
Perhaps the RIRs could get together and agree on a common whois syntax so that when I check one RIR with one syntax - it would work on others as well? This issue has been around for over 7 years and I can't understand why the RIRs can't find common ground for the sake of the end users?
s/7/15/ it was already feeling like brickmarks on my forhead at the first s'holm ietf in '95 randy
On Wed, Nov 25, 2009 at 06:36:13PM +0900, Randy Bush wrote:
Perhaps the RIRs could get together and agree on a common whois syntax so that when I check one RIR with one syntax - it would work on others as well? This issue has been around for over 7 years and I can't understand why the RIRs can't find common ground for the sake of the end users?
s/7/15/ it was already feeling like brickmarks on my forhead at the first s'holm ietf in '95
randy
there are solutions, rwhois, iris, etc. some require changed behaviours from the actors, (why RIPE decided unilaterally to change the flags/syntax of whois escapes me at the mo), and some do not. basically we are stuck w/ things like whois, swip, ad-nausea, due to simple intertia. and here is a saving grace... IPv6. once, abt 8/9 years ago, I was talking w/ Richard Jimmerson about the wonderful opportunity the RIRs had to build a scalable, extensable resource tracking system that could be easily deployed by the RIR clients and seamlessly integrated into a heirarchy of resource management segments. the rational was/is that the RIRs are handing out functionally the entire IPv4 address pool to any and all comers. Thats the size of a /32, presuming one buys into the /64 chastity belt the IETF has wrapped around the lower 64 bits. How is a lowly ISP expected to track/manage address assignments over such a huge space w/o decent toolage? so we can let our collective interia drag us down into increasing chaos or we can use this one time chance to pull our collective bacon out of the fire. After SIDR - I think development and deployment of this type of thing would be a worthwhile use of my RIR fees. YMMV of course. --bill
* Hank Nussbacher:
Perhaps the RIRs could get together and agree on a common whois syntax so that when I check one RIR with one syntax - it would work on others as well? This issue has been around for over 7 years and I can't understand why the RIRs can't find common ground for the sake of the end users? Even if ARIN or APNIC won't accept "-B -G", then at least let their whois engine just ignore those extra parameters it doesn't understand. To me it looks like minor software changes.
There's also the little-known issue that the correct syntax for querying ARIN's WHOIS for AS number is "23456", and not the "AS23456" syntax encoded in multiple tools. *sigh* -- Florian Weimer <fweimer@bfk.de> BFK edv-consulting GmbH http://www.bfk.de/ Kriegsstraße 100 tel: +49-721-96201-1 D-76133 Karlsruhe fax: +49-721-96201-99
At 09:52 25/11/2009 +0000, Florian Weimer wrote:
* Hank Nussbacher:
Perhaps the RIRs could get together and agree on a common whois syntax so that when I check one RIR with one syntax - it would work on others as well? This issue has been around for over 7 years and I can't understand why the RIRs can't find common ground for the sake of the end users? Even if ARIN or APNIC won't accept "-B -G", then at least let their whois engine just ignore those extra parameters it doesn't understand. To me it looks like minor software changes.
There's also the little-known issue that the correct syntax for querying ARIN's WHOIS for AS number is "23456", and not the "AS23456" syntax encoded in multiple tools.
That used to be true. Don't know when they fixed it - but it was recently that AS12345 now works at ARIN. -Hank
*sigh*
-- Florian Weimer <fweimer@bfk.de> BFK edv-consulting GmbH http://www.bfk.de/ Kriegsstraße 100 tel: +49-721-96201-1 D-76133 Karlsruhe fax: +49-721-96201-99
On Nov 25, 2009, at 1:33 AM, Hank Nussbacher wrote:
At 08:57 25/11/2009 +0100, Daniel Karrenberg wrote:
shouting. This is all water under the bridge of course and we are moving on; I do not say everything is ideal now. However the RIRs are actively working to publish a complete set of stats files which also includes unallocated resources.
I would've thought IANA would be responsible for unallocated resources.
This is the next best thing to full database synchronisation. APNIC and the RIPE NCC are driving this effort.
Perhaps the RIRs could get together and agree on a common whois syntax so that when I check one RIR with one syntax - it would work on others as well?
http://www.rfc-editor.org/rfc/rfc4698.txt More seriously, the theory is that the RIRs are bottom-up driven. If you think a unified whois schema across all RIRs (or even IRIS deployment) would be a good thing to have, there are likely better venues to raise the issue than NANOG. Regards, -drc
I do not say everything is ideal now. However the RIRs are actively working to publish a complete set of stats files which also includes unallocated resources. I would've thought IANA would be responsible for unallocated resources.
history shows that rirs would rather fight the iana and among themselves than be equals in the internet community. how they do not see that this leads to the itu is beyond me.
More seriously, the theory is that the RIRs are bottom-up driven. If you think a unified whois schema across all RIRs (or even IRIS deployment) would be a good thing to have, there are likely better venues to raise the issue than NANOG.
have the tee shirt. did not work. nih is not just a us govt agency. why we needed to regionalize irs in the first place is lost on me. fiefdoms. randy
participants (26)
-
Benjamin BILLON -
Bill Woodcock -
bmanning＠vacation.karoshi.com -
Christopher Morrow -
Daniel Karrenberg -
David Conrad -
Dorn Hetzel -
Durand, Alain -
Edward Lewis -
Eric Brunner-Williams -
Florian Weimer -
Frédéric -
Hank Nussbacher -
Jared Mauch -
Jeffrey Lyon -
Joe Abley -
Joel Jaeggli -
John Curran -
Jon Lewis -
Justin Shore -
Larry Blunk -
Michael Dillon -
Randy Bush -
Stephane Bortzmeyer -
Steven Bellovin -
Tony Finch