[ARIN-consult] NEW Consultation: Available Methods of Reporting Network Sub-Delegation Information
Jason Schiller
jschiller at google.com
Fri Oct 13 15:22:17 EDT 2017
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.
2. If we offer bulk additions, it should be supported for
all update types
(template, RESTful API)
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> ).
(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?
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 ARIN supports RDAP referrals, should it sunset rwhois? No.
Is RDAP referrals better than rwhois referrals? I suspect mileage varies
by organization.
Whois example
===============
whois -h 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
#
# If you see inaccuracies in the results, please report at
# 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
#
NetRange: 23.228.128.0 - 23.228.191.255
CIDR: 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
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
ReferralServer: rwhois://rwhois.googlefiber.net:8987
OrgAbuseHandle: GFA32-ARIN
OrgAbuseName: Google Fiber Abuse
OrgAbusePhone: +1-650-253-0000
OrgAbuseEmail: abuse at googlefiber.net
OrgAbuseRef: 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
OrgTechRef: 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
#
# If you see inaccuracies in the results, please report at
# https://www.arin.net/public/whoisinaccuracy/index.xhtml
#
Found a referral to rwhois.googlefiber.net:8987.
%rwhois V-1.5:000090:00 rwhois.googlefiber.net
network:ID:NET-GF-V4-23-228-169-0
network:IP-Network: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> 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 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
#
# If you see inaccuracies in the results, please report at
# 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
#
NetRange: 23.228.128.0 - 23.228.191.255
CIDR: 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
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
ReferralServer: rwhois://rwhois.googlefiber.net:8987
OrgAbuseHandle: GFA32-ARIN
OrgAbuseName: Google Fiber Abuse
OrgAbusePhone: +1-650-253-0000
OrgAbuseEmail: abuse at googlefiber.net
OrgAbuseRef: 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
OrgTechRef: 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
#
# If you see inaccuracies in the results, please report at
# https://www.arin.net/public/whoisinaccuracy/index.xhtml
#
Found a referral to rwhois.googlefiber.net:8987.
%rwhois V-1.5:000090:00 rwhois.googlefiber.net
network:ID:NET-GF-V4-23-228-169-0
network:IP-Network: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
>
> 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
>
> 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
>
>
> 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://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 will close on 27 October 2017. If you
> have any questions, please contact us at 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).
> 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.
>
>
>
> _______________________________________________
> 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.
>
--
_______________________________________________________
Jason Schiller|NetOps|jschiller at google.com|571-266-0006
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.arin.net/pipermail/arin-consult/attachments/20171013/d75ea405/attachment.html>
More information about the ARIN-consult
mailing list