This archive is retained to ensure existing URLs remain functional. It will not contain any emails sent to this mailing list after July 1, 2024. For all messages, including those sent before and after this date, please visit the new location of the archive at https://mailman.ripe.net/archives/list/[email protected]/
[address-policy-wg] [External] Re: FW: ASNs of organizations in reported IPv4 transfers
- Previous message (by thread): [address-policy-wg] FW: ASNs of organizations in reported IPv4 transfers
- Next message (by thread): [address-policy-wg] 2019-06 Review Phase Extended (Multiple Editorial Changes in IPv6 Policy)
Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
Giotsas, Vasileios
v.giotsas at lancaster.ac.uk
Wed Jan 8 02:08:35 CET 2020
Thank you both for your responses! > There's no reason to assume that there's a static, unchanging binding between address space and an ASN. That's a good point, but I didn't assume there's a static unchanged binding but a binding at the moment of the transfer. If an organization with an ASN acquires an address block I assumed that in case they want to change ASN and keep using the same addresses they need to transfer the addresses (many of the transfers appear to be between "sibling" organizations). > It's possible the recipients of some of the transfers you found might not have multi-homed networks. Which would mean there was no relevant ASN for these to include in the transfer database. I guess that explains why often the origin ASN in BGP doesn't change after the transfer. > Use ripestat. This will probably have answers for all/most of the research data you are looking for. I'll definitely try the RIPE stat API, I assumed for my organization names it just provided a layer over WHOIS > further, there is no actual _routing_ binding of an AS to a member LIR identity. i.e. an LIR may have no ASs, or multiple ASs. Maybe using the extended RIR delegation reports can help me find such LIRs > [ personally, i would not go down this capybara hole ] Too late for me :) -----Original Message----- From: Randy Bush <randy at psg.com> Sent: 07 January 2020 06:39 To: Jim Reid <jim at rfc1035.com> Cc: Giotsas, Vasileios <v.giotsas at lancaster.ac.uk>; address-policy-wg at ripe.net Subject: [External] Re: [address-policy-wg] FW: ASNs of organizations in reported IPv4 transfers This email originated outside the University. Check before clicking links or attachments. > Because it's not rational or meaningful to do that. There's no reason > to assume that there's a static, unchanging binding between address > space and an ASN. if there was, we would not need routing :) further, there is no actual _routing_ binding of an AS to a member LIR identity. i.e. an LIR may have no ASs, or multiple ASs. address space 'belonging' to an LIR might be legitimately announced by an AS belonging to a different LIR. from a research point of view, one might ask whether these confounding complications are sufficiently prevalent to obscure the signal which vasileios seeks. [ persoanlly, i would not go down this capybara hole ] randy
- Previous message (by thread): [address-policy-wg] FW: ASNs of organizations in reported IPv4 transfers
- Next message (by thread): [address-policy-wg] 2019-06 Review Phase Extended (Multiple Editorial Changes in IPv6 Policy)
Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]