Hi Dean,
Hiromi-san will reply soon, but as you wrote, we think using 'remarks' field
will be one option to achieve our goals.
Yours Sincerely,
--
Tomohiro Fujisaki
From: Dean Pemberton dean@internetnz.net.nz
Subject: Re: [sig-policy] New Version of prop-115-v001: Registration of detailed assignment information in whois DB
Date: Sun, 1 Mar 2015 07:04:20 +0900
| 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@ripe.net 20000101
| source: RIPE
| --
| Dean Pemberton
|
| Technical Policy Advisor
| InternetNZ
| +64 21 920 363 (mob)
| dean@internetnz.net.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@gmail.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@inetcore.com
| >
| > Tomohiro Fujisaki
| > fujisaki@syce.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@lists.apnic.net
| > http://mailman.apnic.net/mailman/listinfo/sig-policy
| >
| * sig-policy: APNIC SIG on resource management policy *
| _______________________________________________
| sig-policy mailing list
| sig-policy@lists.apnic.net
| http://mailman.apnic.net/mailman/listinfo/sig-policy
|
