Orbit

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
 |