poeml / mirrorbrain

MirrorBrain
http://mirrorbrain.org/
Other
75 stars 37 forks source link

IPv6 support for mod_asn (Patch included) #154

Open poeml opened 9 years ago

poeml commented 9 years ago
                                                                               [          ]

Issue migrated (2015-06-05) from old issue tracker http://mirrorbrain.org/issues/issue154

Title    IPv6 support for mod_asn (Patch included)
 Priority   feature   Status   chatting
Superseder          Nosy List  crohmann, poempelfox
Assigned To          Keywords  mod_asn
                                   Files
      File name                  Uploaded               Type      Edit Remove

mod_asn__1_6__patches.zip crohmann, application/ 2014-06-14.08:12:19 zip

msg554 (view) Author: crohmann Date: 2014-06-14.08:12:19

As sent to the mailinglist (where the message strangely did not yet appear) ....

With the adoption of IPv6 for more and more end user connections I believe it's necessary that mod_asn is also able to match IPv6 addresses to their AS and get the users to the closest IPv6-enabled mirror possible. While mirrorbrain itself is quite capable IPv6-wise and even does IPv6 geo-ip, mod_asn lacks a bit in looking up the AS for IPv6 addresses.

So I took a look at the PostgreSQL extention data type "ip4r" you are already using to do the prefix lookups. Back in the days it was not supporting IPv6 well, as you stated on http://mirrorbrain.org/mod_asn/development-status/. But as I found out this has changed dramatically towards the now current 2.0.2. Not only does ip4r support IPv6, you can even put IPv4 and IPv6 prefixes together in one column using the type iprange (they describe it with "an arbitrary range of IPv4 or IPv6 addresses").

So I changed the pfx2asn table to use this type instead of just "ip4r" via: ALTER TABLE pfx2asn ALTER pfx TYPE iprange;

I put in a few prefixes to test ...

INSERT INTO pfx2asn VALUES('2001:4dd0::/32', 8422); INSERT INTO pfx2asn VALUES('2001:4dd0::/29', 8422); INSERT INTO pfx2asn VALUES('2001:4dd1::/32', 8422); INSERT INTO pfx2asn VALUES('2001:4dd2::/32', 8422); INSERT INTO pfx2asn VALUES('2001:4dd3::/32', 8422);

I then played with it a bit querying the table for the AS for a given IPv6 prefix. I changed the query just a bit to make it flexible in taking IPv4 as well as IPv6 addresses for the matching and uses the "@" operator to do the ordering:

mirrorbrain=# SELECT pfx, asn FROM pfx2asn WHERE pfx >>= ipaddress('2001:4dd0::1') ORDER BY @ pfx; pfx | asn ----------------+------ 2001:4dd0::/32 | 8422 2001:4dd0::/29 | 8422 (2 rows)

mirrorbrain=# SELECT pfx, asn FROM pfx2asn WHERE pfx >>= ipaddress('2001:4dd1::1') ORDER BY @ pfx; pfx | asn ----------------+------ 2001:4dd1::/32 | 8422 2001:4dd0::/29 | 8422 (2 rows)

mirrorbrain=# SELECT pfx, asn FROM pfx2asn WHERE pfx >>= ipaddress('194.8.197.22') ORDER BY @ pfx; pfx | asn ----------------+------ 194.8.192.0/19 | 8422 (1 row)

as you can see it works just as it should, giving back the correct order, IPv4 and IPv6 prefixes in harmony !

As for the operator "@" vs "@@" I am not yet sure if it really makes a difference in practice. The documentation of ip4r says: @ a | approximate size of a (returns double) @@ a | exact size of a (returns numeric)

Given the ability to now also look up AS numbers for IPv6 addresses with a single query, mod_asn itself needs very little code change. I put in a new default query, and of course did remove the IPv6 check that avoided even looking up IPv6 addresses in the first place. Attached you find a patch against the current 1.6 of mod_asn.c which does exactly those changes and also a changed asn.sql file which uses the iprange data type.

With those changes mod_asn now returns X-Prefix and X-AS headers for IPv6 prefixes ...

curl --head

http://[2001:4dd3:1234:1234:1234:1234:1234:1234]/download/testfile.txt HTTP/1.1 200 OK Date: Sat, 14 Jun 2014 00:10:24 GMT Server: Apache/2.4.9 (Debian) X-Prefix: 2001:4dd3::/32 X-AS: 8422

The only piece to the IPv6 puzzle that is missing to me at least, is a good source for the IPv6 prefixes <-> AS list in plain just like there is with http://www.routeviews.org/ for IPv4. If someone has BGP full-table running on maybe a looking glass router one can simply get it from there, but that is of course not something for everyone. So this needs some thought and then the appropriate addition to the provided script to gather the data and put it into the database.

So what are your thoughts on this? Did I miss anything here?

msg560 (view) Author: crohmann Date: 2015-05-06.09:24:14

Is there any chance this patch makes it into mod_asn?

msg561 (view) Author: poempelfox Date: 2015-05-09.08:21:03

As I posted on the mailinglist yesterday, I think this is a patch worth including. It significantly improves the current situation/featureset.

However I think there is some more to do to make this "perfect". mod_mirrorbrain currently does only IPv4 prefix matching, and it would need to store IPv6 prefixes and match those as well. However, that is a problem with a very low priority, because the AS matching does work properly, and with IPv6 the announced prefixes usually are very large, because reducing the number of prefixes that need to be in the routing-tables of internet backbone routers was one of the goals with IPv6. For example, on IPv4 every german university has its own prefix, and that prefix can be found in the routing tables. On IPv6 there is only one very big prefix (/32) visible that covers all german universities and the whole AS. So there is often little to be gained by matching on the prefix that isn't already coming out of the AS matching.

History
         Date            User    Action            Args
2015-05-09 08:21:04 poempelfox set    nosy: + poempelfox
                                        messages: + msg561
2015-05-06 09:24:14 crohmann   set    status: unread -> chatting
                                        messages: + msg560
2014-06-14 08:12:19 crohmann   create
(end of migrated issue)
frittentheke commented 8 years ago

I am the author of this issue and provided the little "patch" for the DB query. @frittentheke on GitHub.

DimStar77 commented 7 years ago

As far as I can see, mod_asn has been corrected for this part? so this issue should be closeable (mod_asn 1.7 - unreleased)