Re: [sig-policy] New Version of prop-115-v001: Registration of detailed
I don't want to add more implementation to the whois DB.
Currently I thought remarks field as you mentioned.
But at this case, to using remarks field for detailed information,
guidelines and help message/warning/alert would be changed.
To inform this among member Registries(and its users), APNIC will
announce a lot and it will bring them additional work.
For security reason, set privilege to show will cost much to implement,
I suppose.
I hope making only a little change of policy would be better to do this.
I would like to make consensus on the problem statement then discuss
more about its detail on execution/implementation.
Regards,
On 2015/03/01 7:04, Dean Pemberton wrote:
> I am currently neither in favour or opposed to this proposal, but I
> would like to ask for a point of clarification...
>
> Is the author suggesting that new fields in the whois be added to
> allow this funtionality?
>
> It would seem that this is something which operators could choose to
> implement today using the 'remarks' field as they do for BGP community
> information as shown below.
>
> $ whois -h rr.Level3.net as702
>
> % RIPEdb(3.0.0a13) with ISI RPSL extensions
>
> aut-num: AS702
> as-name: AS702
> descr: Verizon Business EMEA - Commercial IP service provider in Europe
> admin-c: DUMY-RIPE
> tech-c: DUMY-RIPE
> remarks: --------------------------------------------------------------
> Verizon Business filters out inbound prefixes longer than /24.
> We also filter any networks within AS702:RS-INBOUND-FILTER.
> --------------------------------------------------------------
> VzBi uses the following communities with its customers:
> 702:80 Set Local Pref 80 within AS702
> 702:120 Set Local Pref 120 within AS702
> 702:20 Announce only to VzBi AS'es and VzBi customers
> 702:30 Keep within Europe, don't announce to other VzBi AS's
> 702:1 Prepend AS702 once at edges of VzBi to Peers
> 702:2 Prepend AS702 twice at edges of VzBi to Peers
> 702:3 Prepend AS702 thrice at edges of VzBi to Peers
> --------------------------------------------------------------
> Advanced communities for customers
> 702:7020 Do not announce to AS702 peers with a scope of
> National but advertise to Global Peers, European
> Peers and VzBi customers.
> 702:7001 Prepend AS702 once at edges of VzBi to AS702
> peers with a scope of National.
> 702:7002 Prepend AS702 twice at edges of VzBi to AS702
> peers with a scope of National.
> 702:7003 Prepend AS702 thrice at edges of VzBi to AS702
> peers with a scope of National.
> 702:8020 Do not announce to AS702 peers with a scope of
> European but advertise to Global Peers, National
> Peers and VzBi customers.
> 702:8001 Prepend AS702 once at edges of VzBi to AS702
> peers with a scope of European.
> 702:8002 Prepend AS702 twice at edges of VzBi to AS702
> peers with a scope of European.
> 702:8003 Prepend AS702 thrice at edges of VzBi to AS702
> peers with a scope of European.
> --------------------------------------------------------------
> Additional details of the VzBi communities are located at:
> http://www.verizonbusiness.com/uk/customer/bgp/
> --------------------------------------------------------------
> Details of VzBi's peering policy and how to get in touch with
> VzBi regarding peering policy matters can be found at:
> http://www.verizonbusiness.com/uunet/peering/
> --------------------------------------------------------------
> remarks: ****************************
> remarks: * THIS OBJECT IS MODIFIED
> remarks: * Please note that all data that is generally regarded
> as personal
> remarks: * data has been removed from this object.
> remarks: * To view the original object, please query the RIPE Database at:
> remarks: * http://www.ripe.net/whois
> remarks: ****************************
> mnt-by: WCOM-EMEA-RICE-MNT
> changed: unread at ripe dot net 20000101
> source: RIPE
> --
> Dean Pemberton
>
> Technical Policy Advisor
> InternetNZ
> +64 21 920 363 (mob)
> dean at internetnz dot net dot nz
>
> To promote the Internet's benefits and uses, and protect its potential.
>
>
> On Thu, Feb 5, 2015 at 5:52 AM, Masato Yamanishi <myamanis at gmail dot com> wrote:
>> Dear SIG members
>>
>> The Problem statement "Registration of detailed assignment information
>> in whois DB" has been assigned a Policy Proposal number following the
>> submission of a new version sent to the Policy SIG for consideration.
>>
>> The proposal, "prop-115-v001: Registration of detailed assignment
>> information in whois DB" now includes an objective and proposed solution.
>>
>> Information about this and earlier versions is available from:
>>
>> http://www.apnic.net/policy/proposals/prop-115
>>
>> You are encouraged you to express your views on the proposal:
>>
>> - Do you support or oppose this proposal?
>> - Does this proposal solve a problem you are experiencing? If so,
>> tell the community about your situation.
>> - Do you see any disadvantages in this proposal?
>> - Is there anything in the proposal that is not clear?
>> - What changes could be made to this proposal to make it more
>> effective?
>>
>>
>>
>> Regards,
>>
>> Masato
>>
>>
>>
>> ------------------------------------------------------------------------
>> prop-115-v001: Registration of detailed assignment information in
>> whois DB
>> ------------------------------------------------------------------------
>>
>> Proposer: Ruri Hiromi
>> hiromi at inetcore dot com
>>
>> Tomohiro Fujisaki
>> fujisaki at syce dot net
>>
>>
>> 1. Problem statement
>> --------------------
>>
>> Recently, there are some cases need to get IP address assignment
>> information in more detail to specify user IP address.
>>
>> With out this information, operators cannot filter out specific
>> address range, and it might lead to 'over-filter' (i.e. filtering
>> whole ISP's address range).
>>
>> For example:
>>
>> 1) 'Port' range information in IPv4
>>
>> ISPs are using 'CGN' or other kinds of IPv4 address sharing
>> technology with assignment of IP address and specified port
>> range to their users.
>>
>> In this case, port information is necessary to specify one user.
>>
>> ex) 192.0.2.24/32 1-256 is for HomeA
>> 192.0.2.24/32 257-511 is for HomeB
>>
>> or 192.0.2.0/24 1-65536 is shared address of ISP-X
>> minimum size is /32
>>
>> 2) address assignment size information in IPv6
>>
>> The IPv6 address assignment size may be different from ISP to
>> ISP, and address ranges in one ISP. Address assignment prefix
>> size will be necessary.
>>
>> ex) 2001:db8:1::0/56 is for HomeA
>> 2001:db8:1:1::0/48 is for HomeB
>>
>> or 2001:db8:1::/36's minimum size is /56
>>
>>
>> 2. Objective of policy change
>> -----------------------------
>>
>> Lots of operators look a record when harmful behavior coming to
>> their network to identify its IP address confirming it can be
>> filtered or not.
>>
>> The goal is providing more specific information to support these
>> actions.
>>
>>
>> 3. Situation in other regions
>> -----------------------------
>>
>> No same regulation/discussion can be seen in other regions.
>>
>>
>> 4. Proposed policy solution
>> ---------------------------
>>
>> Provide accurate filtering information generated from whois DB.
>>
>> For IPv4, propose to add 'port range' information to IP address
>> entry.
>>
>> For IPv6, propose to provide 'assignment prefix size' information
>> for specific IPv6 address.
>>
>>
>> 5. Advantages / Disadvantages
>> -----------------------------
>>
>> Advantages:
>>
>> - operators can set filtering by IP address based on correct assignment
>> information base.
>>
>> - users who share same address space can be avoid to be including bulk
>> filtering.
>>
>> Disadvantages:
>>
>> - registration rule will move to more strict manner.
>>
>> - strict watch and control in registration of database records.
>>
>> - additional record or option will be considered.
>>
>> - privilege for withdrawing detailed information will be set for these
>> records.
>>
>>
>> 6. Impact on APNIC
>> ------------------
>>
>> This might be beyond the scope of using whois DB.
>>
>>
>> 7. Other Consideration
>> ----------------------
>>
>> For the security reason, this detailed records may be able to see
>> only by operators.(some kind of user control/privilege setting is
>> needed)
>>
>> For hosting services, /32 in IPv4 and /128 in IPv6 registration
>> should be discussed based on its operability and possibility. But a
>> harmful activities to filter by IP addresses are coming from hosting
>> services as well. Here it seemed to be some demands.
>>
>>
>> References
>> ----------
>>
>> TBD
>>
>>
>> * sig-policy: APNIC SIG on resource management policy
>> *
>> _______________________________________________
>> sig-policy mailing list
>> sig-policy at lists dot apnic dot net
>> http://mailman.apnic.net/mailman/listinfo/sig-policy
>>
> * sig-policy: APNIC SIG on resource management policy *
> _______________________________________________
> sig-policy mailing list
> sig-policy at lists dot apnic dot net
> http://mailman.apnic.net/mailman/listinfo/sig-policy
>
--
===================================
株式会社インテック
先端技術研究所 研究開発部
廣海（ひろみ）緑里