[ARIN-consult] NEW Consultation: Available Methods of Reporting Network Sub-Delegation Information
Owen DeLong
owen at delong.com
Mon Oct 16 13:06:54 EDT 2017
> On Oct 13, 2017, at 12:22 , Jason Schiller <jschiller at google.com> wrote:
>
> Comments in line.
>
>
> Question (general):
>
> Of the three sub-delegation reporting methods listed (SWIP, RWhois, RDAP), which
> should ARIN support in the future?
>
> Answer: ARIN should support all three in the future.
>
>
> Question (SWIP/RESTful API specific):
>
> The existing RESTful API allows users to report (SWIP) one sub-delegation at a time
> to be added to ARIN Whois. Should ARIN add bulk-upload features to the RESTful API?
>
> Answer: 1. Bulk removal is more important that bulk additions.
> e.g. can you remove all SWIPs for prefixes within 1.2.0.0/18 <http://1.2.0.0/18>.
The concern I have if we support this kind of bulk removal is that we must somehow validate that
the removal comes from an entity allowed to remove all of 1.2.0.0/18 and its subordinates. We
wouldn’t want, for example, the owner of 1.2.2.0/24 to be able to use their authority there to
remove all of their fellow customers of the owner of 1.2.0.0/18. Obviously this is an implementation
detail, but it’s an important one.
> 2. If we offer bulk additions, it should be supported for all update types
> (template, RESTful API)
I disagree. As much as Mark likes to point out that I am the leading defender of templates,
I don’t think adding bulk addition to templates really makes much sense.
> 3. Sure, but I don't think the priority is very high.
>
> Question (RWhois specific):
>
> As noted, RWhois servers are not referred to in an automated fashion when users query
> ARIN Whois. Should ARIN automate referrals to RWhois servers from ARIN's Whois service?
>
> Answer: Yes.
> This seems to work for my whois client (whois Version 5.1.1. Report bugs to <md+whois at linux.it <mailto:md%2Bwhois at linux.it>> ).
> (example below)
>
> When somoene does a "SEARCH WhoisRWS" on the ARIN website, it should likewise chase
> the rwhois referral, and display it on the ARIN web site.
>
> Furthermore, ARIN should keep stats on when these referrals time out, and when they work.
>
> If there is not a requirement for all whois clients to follow the referral, and this can be addressed on
> the server side, then lets address this on the server side. Double especially if this addresses an issue
> where providers publish rwhois data, but make it only accessible to the RIRs.
>
> Question: How will this interact with a whois client that currently follows the referral?
While I agree with the original design being cleaner (the server does not recurse and recursion is left
to the client), the simple reality is that for whatever reason(s), most people are using whois clients
that don’t support recursion and therefore don’t recurse. Since it is easy and within ARIN’s capability
to mitigate the situation by modifying the server and outside of ARIN’s control and much more difficult
to get everyone’s client software updated, I think that this is a case where pragmatism should rule over
cleanliness and correctness and we should implement recursion in the server.
The server should provide notices to the client that recursion is being attempted, the name of the
server being recursed, etc. without any delay introduced by response time (or timeout) of the remote
server.
>
>
> Question (RDAP specific):
>
> If ARIN was to allow the reporting of network sub-delegation information using RDAP, associated
> enabling software would be required. Should ARIN enable this method by creating an RDAP
> software suite that would allow ARIN registrants to run RDAP service locally?
>
> Answer: Yes. It should be fairly easy to just open (part of) the source of your RDAP service.
> People can crib of that, and integrate with their IPAM / radius logs etc.
> Surely someone will voluntarily provide a packed binary, and the source for it.
> If not ARIN should fill this gap.
If RDAP is to become an IETF standard, then IIRC, at least two implementations are required. I’m all for
ARIN being the ones to develop one of these implementations for the community if that is necessary,
but I’m not in favor of ARIN unnecessarily reinventing the wheel if someone else has already provided
an open-source implementation of RDAP server and/or client, etc.
>
>
> If ARIN supports RDAP referrals, should it sunset rwhois? No.
> Is RDAP referrals better than rwhois referrals? I suspect mileage varies by organization.
I also suspect that this depends on perspective (familiarity with RDAP, familiarity with whois/rwhois,
existing installed base, publisher vs. consumer of data, etc.)
Owen
>
>
> Whois example
> ===============
> whois -h whois.arin.net <http://whois.arin.net/> 23.228.169.1
>
> #
> # ARIN WHOIS data and services are subject to the Terms of Use
> # available at: https://www.arin.net/whois_tou.html <https://www.arin.net/whois_tou.html>
> #
> # If you see inaccuracies in the results, please report at
> # https://www.arin.net/public/whoisinaccuracy/index.xhtml <https://www.arin.net/public/whoisinaccuracy/index.xhtml>
> #
>
>
> #
> # The following results may also be obtained via:
> # https://whois.arin.net/rest/nets;q=23.228.169.1?showDetails=true&showARIN=false&showNonArinTopLevelNet=false&ext=netref2 <https://whois.arin.net/rest/nets;q=23.228.169.1?showDetails=true&showARIN=false&showNonArinTopLevelNet=false&ext=netref2>
> #
>
> NetRange: 23.228.128.0 - 23.228.191.255
> CIDR: 23.228.128.0/18 <http://23.228.128.0/18>
> NetName: GOOGLE-FIBER
> NetHandle: NET-23-228-128-0-1
> Parent: NET23 (NET-23-0-0-0-0)
> NetType: Direct Allocation
> OriginAS: AS16591
> Organization: Google Fiber Inc. (GF)
> RegDate: 2013-09-13
> Updated: 2014-03-26
> Ref: https://whois.arin.net/rest/net/NET-23-228-128-0-1 <https://whois.arin.net/rest/net/NET-23-228-128-0-1>
>
>
> OrgName: Google Fiber Inc.
> OrgId: GF
> Address: 1600 Amphitheatre Parkway
> City: Mountain ViewNeither does WHOIS for records stored in the ARIN database (SWIP), so why should ISPs face an increased burden here if you are not also planning to eliminate whois?
>
> StateProv: CA
> PostalCode: 94043
> Country: US
> RegDate: 2010-10-08
> Updated: 2017-01-28
> Ref: https://whois.arin.net/rest/org/GF <https://whois.arin.net/rest/org/GF>
>
> ReferralServer: rwhois://rwhois.googlefiber.net:8987 <http://rwhois.googlefiber.net:8987/>
>
> OrgAbuseHandle: GFA32-ARIN
> OrgAbuseName: Google Fiber Abuse
> OrgAbusePhone: +1-650-253-0000
> OrgAbuseEmail: abuse at googlefiber.net <mailto:abuse at googlefiber.net>
> OrgAbuseRef: https://whois.arin.net/rest/poc/GFA32-ARIN <https://whois.arin.net/rest/poc/GFA32-ARIN>
>
> OrgTechHandle: ZG39-ARIN
> OrgTechName: Google Inc
> OrgTechPhone: +1-650-253-0000
> OrgTechEmail: arin-contact at google.com <mailto:arin-contact at google.com>
> OrgTechRef: https://whois.arin.net/rest/poc/ZG39-ARIN <https://whois.arin.net/rest/poc/ZG39-ARIN>
>
>
> #
> # ARIN WHOIS data and services are subject to the Terms of Use
> # available at: https://www.arin.net/whois_tou.html <https://www.arin.net/whois_tou.html>
> #
> # If you see inaccuracies in the results, please report at
> # https://www.arin.net/public/whoisinaccuracy/index.xhtml <https://www.arin.net/public/whoisinaccuracy/index.xhtml>
> #
>
>
>
> Found a referral to rwhois.googlefiber.net:8987 <http://rwhois.googlefiber.net:8987/>.
>
> %rwhois V-1.5:000090:00 rwhois.googlefiber.net <http://rwhois.googlefiber.net/>
> network:ID:NET-GF-V4-23-228-169-0
> network:IP-Network:23.228.169.0/29 <http://23.228.169.0/29>
> network:Org-Name:Wasatch Mental Health
> network:Street-Address:750 N 200 W
> network:Unit-Number:
> network:City:Provo
> network:State:UT
> network:Postal-Code:84601
> network:Country-Code:US
>
> %ok
>
> ===============
> end Whois example
>
>
>
> What problem are we trying to solve?
> If it is having
>
>
>
>
>
> On Thu, Oct 12, 2017 at 4:33 PM, Andrew Dul <andrew.dul at quark.net <mailto:andrew.dul at quark.net>> wrote:
> I'm writing to support the sunsetting of the rwhois protocol as a method for ARIN members to document reallocation and reassignment records.
>
> That doesn't mean this year or next year, but I believe we should set a timeline for deprecating this protocol. Perhaps a date of 2022 would be reasonable. (Yes, some organizations will not do the work despite the 4 years of time to do it, but a shorter time frame would also be unacceptable to some)
>
> I have seen those who have posted on this consultation noting that "rwhois works and isn't broken so don't fix it." While I will agree that it is "technically" not broken, I believe that it is operationally broken.
>
> These are some of the reasons why I believe we should move on to something better. Any by better, I mean moving to records stored in the ARIN database (SWIP) or RDAP.
>
> -Rwhois doesn't support encryption or data-integrity during transport
>
> As Owen points out, neither does WHOIS for records stored in the ARIN database (SWIP),
> so why should ISPs face an increased burden here if you are not also planning to eliminate whois?
>
>
> -There is no automatic referral, so when most people query ARIN whois they don't know there is potentially another more specific record and even if they are aware, how to do rwhois is not "easy" for many users. Yes its easy for engineers and some operators, but there are many users of "whois" data for whom this is a barrier too high. Could we invest in lots of training for rwhois, yes, but we will always be behind on this as long as its not a click away for most users.
>
> as stated above whois to rwhois automatic referrals needs to work everywhere.
>
> whois -h whois.arin.net <http://whois.arin.net/> 23.228.169.1
>
> #
> # ARIN WHOIS data and services are subject to the Terms of Use
> # available at: https://www.arin.net/whois_tou.html <https://www.arin.net/whois_tou.html>
> #
> # If you see inaccuracies in the results, please report at
> # https://www.arin.net/public/whoisinaccuracy/index.xhtml <https://www.arin.net/public/whoisinaccuracy/index.xhtml>
> #
>
>
> #
> # The following results may also be obtained via:
> # https://whois.arin.net/rest/nets;q=23.228.169.1?showDetails=true&showARIN=false&showNonArinTopLevelNet=false&ext=netref2 <https://whois.arin.net/rest/nets;q=23.228.169.1?showDetails=true&showARIN=false&showNonArinTopLevelNet=false&ext=netref2>
> #
>
> NetRange: 23.228.128.0 - 23.228.191.255
> CIDR: 23.228.128.0/18 <http://23.228.128.0/18>
> NetName: GOOGLE-FIBER
> NetHandle: NET-23-228-128-0-1
> Parent: NET23 (NET-23-0-0-0-0)
> NetType: Direct Allocation
> OriginAS: AS16591
> Organization: Google Fiber Inc. (GF)
> RegDate: 2013-09-13
> Updated: 2014-03-26
> Ref: https://whois.arin.net/rest/net/NET-23-228-128-0-1 <https://whois.arin.net/rest/net/NET-23-228-128-0-1>
>
>
> OrgName: Google Fiber Inc.
> OrgId: GF
> Address: 1600 Amphitheatre Parkway
> City: Mountain View
> StateProv: CA
> PostalCode: 94043
> Country: US
> RegDate: 2010-10-08
> Updated: 2017-01-28
> Ref: https://whois.arin.net/rest/org/GF <https://whois.arin.net/rest/org/GF>
>
> ReferralServer: rwhois://rwhois.googlefiber.net:8987 <http://rwhois.googlefiber.net:8987/>
>
> OrgAbuseHandle: GFA32-ARIN
> OrgAbuseName: Google Fiber Abuse
> OrgAbusePhone: +1-650-253-0000
> OrgAbuseEmail: abuse at googlefiber.net <mailto:abuse at googlefiber.net>
> OrgAbuseRef: https://whois.arin.net/rest/poc/GFA32-ARIN <https://whois.arin.net/rest/poc/GFA32-ARIN>
>
> OrgTechHandle: ZG39-ARIN
> OrgTechName: Google Inc
> OrgTechPhone: +1-650-253-0000
> OrgTechEmail: arin-contact at google.com <mailto:arin-contact at google.com>
> OrgTechRef: https://whois.arin.net/rest/poc/ZG39-ARIN <https://whois.arin.net/rest/poc/ZG39-ARIN>
>
>
> #
> # ARIN WHOIS data and services are subject to the Terms of Use
> # available at: https://www.arin.net/whois_tou.html <https://www.arin.net/whois_tou.html>
> #
> # If you see inaccuracies in the results, please report at
> # https://www.arin.net/public/whoisinaccuracy/index.xhtml <https://www.arin.net/public/whoisinaccuracy/index.xhtml>
> #
>
>
>
> Found a referral to rwhois.googlefiber.net:8987 <http://rwhois.googlefiber.net:8987/>.
>
> %rwhois V-1.5:000090:00 rwhois.googlefiber.net <http://rwhois.googlefiber.net/>
> network:ID:NET-GF-V4-23-228-169-0
> network:IP-Network:23.228.169.0/29 <http://23.228.169.0/29>
> network:Org-Name:Wasatch Mental Health
> network:Street-Address:750 N 200 W
> network:Unit-Number:
> network:City:Provo
> network:State:UT
> network:Postal-Code:84601
> network:Country-Code:US
>
> %ok
>
>
> -As was noted in the most recent ARIN meeting, law enforcement agencies use whois data as a source for their investigations and other work, and having accurate records available on a timely basis is very important to them. I don't believe that rwhois data is as accessible and available as data in the ARIN database.
>
> If this is a problem, then we should get support procedures for all who run an rwhois server,
> publish them publicly, and see if that doesn't solve the problem.
>
> If that doesn't solve it, maybe go as far as naming and shaming, or even considering if the organization
> is in compliance the ARIN policy if the rwhois data is not generally reachable, and the data in SWIP is
> not sufficient for ARIN policy compliance on its own.
>
> John Sweeting, can ARIN staff reach out to the 372 orgs with an unresponsive rwhois server and ask them to fix it and run another test?
>
> -RDAP was designed with referral in mind from the ground up, so that you get all the records no matter where they are located with a single query.
> That seems to just work for my whois client. I don't see why it shouldn't work for all whois clients.
>
> -ARIN (in possible collaboration with other RIRS) should develop an RDAP package for those who like to host their own, distributed database. The new package should support bulk retrieval of records to assist in data collection and analysis. (Also it was noted in the most recent ARIN meeting that there are differences today in how the different RIRs are reporting fields/data via RDAP. It would be good for the RIRs in collaboration with each other and other organizations that want to run RDAP servers for IP number resources to work to create a standard met of fields which are required for IP number resource records, along with other optional fields for additional data)
>
> It has been noted casually that there are many rwhois servers which are down or aren't available. I believe this also contributes to this data set being operationally unavailable.
>
> I do not believe the problem space is any different with running a local RDAP server (at least at my organization).
> I suspect it is not good for the community if I update whois data with the frequency I update my rwhois data whether that be RESTful, template, RESTful bulk, or template bulk.
>
>
> I'd like to ask if ARIN staff can confirm some of these details with data from the ARIN's database and operational practices. Specifically if ARIN could provide the following details about how rwhois is being operated today I believe it would inform the community in this consultation process.
>
> 1) Number of orgs which have IPv4 or IPv6 resources and a rwhois record on their org-id.
>
> 2) Number of IPv4 and IPv6 blocks with a rwhois server under the org-id records
>
> 3) Number of /24 IPv4 equivalents covered by the above records
>
> 4) Number of /32 IPv6 equivalents covered by the above records
>
> 5) Total number of unique rwhois servers
>
> 6) Percent of rwhois servers which are online (complete a tcp connection
> accept a string and respond with some text)
>
> 7) Percent of rwhois server who appear to respond with a valid record
> for an address within each allocated block
>
>
> Thanks,
> Andrew
>
>
>
>
> On 10/2/2017 8:19 AM, ARIN wrote:
>> ARIN was previously requested via the ARIN Consultation and Suggestion Process (ACSP) to open a consultation to generate discussion about the possibility of sun-setting RWhois support by the ARIN organization. ARIN's initial response to the ACSP indicated we would open a consultation following the completion of the Registration Data Access Protocol (RDAP) specification inside the IETF processes. This work has been completed and the RFC has been published. ARIN took the additional step of implementing RDAP inside its own directory services offering with referral support to the other Regional Internet Registries (RIRs). With this work complete, we are following through with the formalized request to open a consultation on this topic.
>>
>> https://www.arin.net/participate/acsp/suggestions/2013-22.html <https://www.arin.net/participate/acsp/suggestions/2013-22.html>
>>
>> In accordance with ARIN's Number Resource Policy Manual (NRPM), Organizations are required to report certain types of customer network sub-delegation information (reassignments and reallocations) to ARIN. Currently there are two reporting methods available. Both are delineated in the NRPM and supported by ARIN's production services. There is also a third possible method of reporting sub-delegation information that could be made available, but is not yet offered.
>> Method 1:
>>
>> SWIP (currently available): The reporting of sub-delegation information using ARIN's database. This can be done either by submitting a SWIP template, interfacing with ARIN's RESTful API, or by creating a sub-delegation inside ARIN Online using ARIN's SWIP-EZ functionality.
>>
>> https://www.arin.net/resources/request/reassignments.html <https://www.arin.net/resources/request/reassignments.html>
>> Method 2:
>>
>> RWhois (currently available): The reporting of sub-delegation information on your own hosted and operated RWhois server with referral link information provided in ARIN Whois as part of your own organization's Whois records. In order for a user of ARIN's directory services to view sub-delegation information hosted by an RWhois server, they would have to submit a separate query to that RWhois server, and are not referred in an automated fashion.
>>
>> https://www.arin.net/resources/request/reassignments_rwhois.html <https://www.arin.net/resources/request/reassignments_rwhois.html>
>> Method 3:
>>
>> RDAP: The five RIRs currently use RDAP for referrals to each other's Whois data. Although the specification language of the RDAP could allow it to be used as a third method for the reporting of sub-delegation information to ARIN, it is not currently offered as an option. In order to make this option available, associated registry software would need to be created. This possible method would allow users of ARIN's directory services to view sub-delegation information available on customer hosted RDAP servers in an automated fashion. This RDAP method may also be viewed as redundant to RWhois.
>>
>> https://tools.ietf.org/html/rfc7482 <https://tools.ietf.org/html/rfc7482>
>> https://www.arin.net/resources/rdap.html <https://www.arin.net/resources/rdap.html>
>> Options Going Forward
>>
>> ARIN expects to continue offering Method 1 (SWIP) into the foreseeable future. As previously described, we are acting on a formal suggestion to consult with the community about the future of RWhois support, and also have potential options with RDAP.
>> Question (general):
>>
>> Of the three sub-delegation reporting methods listed (SWIP, RWhois, RDAP), which should ARIN support in the future?
>> Question (SWIP/RESTful API specific):
>>
>> The existing RESTful API allows users to report (SWIP) one sub-delegation at a time to be added to ARIN Whois. Should ARIN add bulk-upload features to the RESTful API?
>> Question (RWhois specific):
>>
>> As noted, RWhois servers are not referred to in an automated fashion when users query ARIN Whois. Should ARIN automate referrals to RWhois servers from ARIN's Whois service?
>> Question (RDAP specific):
>>
>> If ARIN was to allow the reporting of network sub-delegation information using RDAP, associated enabling software would be required. Should ARIN enable this method by creating an RDAP software suite that would allow ARIN registrants to run RDAP service locally?
>>
>> The feedback you provide during this consultation will help inform decisions about software tools and support for the reporting of network sub-delegation information to ARIN in the future. Thank you for your participation in the ARIN Consultation and Suggestion Process.
>>
>> Discussion on arin-consult at arin.net <mailto:arin-consult at arin.net> will close on 27 October 2017. If you have any questions, please contact us at info at arin.net <mailto:info at arin.net>.
>>
>> Regards,
>>
>>
>> John Curran
>> President and CEO
>> American Registry for Internet Numbers (ARIN)
>>
>>
>>
>>
>>
>> _______________________________________________
>> ARIN-Consult
>> You are receiving this message because you are subscribed to the ARIN Consult Mailing
>> List (ARIN-consult at arin.net <mailto:ARIN-consult at arin.net>).
>> Unsubscribe or manage your mailing list subscription at:
>> http://lists.arin.net/mailman/listinfo/arin-consult <http://lists.arin.net/mailman/listinfo/arin-consult> Please contact the ARIN Member Services
>> Help Desk at info at arin.net <mailto:info at arin.net> if you experience any issues.
>
>
> _______________________________________________
> ARIN-Consult
> You are receiving this message because you are subscribed to the ARIN Consult Mailing
> List (ARIN-consult at arin.net <mailto:ARIN-consult at arin.net>).
> Unsubscribe or manage your mailing list subscription at:
> http://lists.arin.net/mailman/listinfo/arin-consult <http://lists.arin.net/mailman/listinfo/arin-consult> Please contact the ARIN Member Services
> Help Desk at info at arin.net <mailto:info at arin.net> if you experience any issues.
>
>
>
> --
> _______________________________________________________
> Jason Schiller|NetOps|jschiller at google.com <mailto:jschiller at google.com>|571-266-0006
>
> _______________________________________________
> ARIN-Consult
> You are receiving this message because you are subscribed to the ARIN Consult Mailing
> List (ARIN-consult at arin.net).
> Unsubscribe or manage your mailing list subscription at:
> http://lists.arin.net/mailman/listinfo/arin-consult Please contact the ARIN Member Services
> Help Desk at info at arin.net if you experience any issues.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.arin.net/pipermail/arin-consult/attachments/20171016/6d15f8c6/attachment.html>
More information about the ARIN-consult
mailing list