Yeah I think this is a bit of a radical proposal to accept at present.
I'm not convinced we should be supporting CGN in this way, nor am I a
fan of seeing more and more information make it into Whois which might
not be the best place.
I would like to hear more from Hiromi-san about the problem statement
and how this might be solved, but I'm not at all sure I would support
the current proposal.
Would it be possible to withdraw the proposal and use the scheduled
time during the Policy Sig for an informational session to allow
Hiromi-san to present to the community the problem here?
Dean
--
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 Wed, Feb 25, 2015 at 6:11 AM, Owen DeLong <owen at delong dot com> wrote:
> I don’t believe the proposal offers enough benefit to be worth what
> implementation would likely
> cost.
>
> First, I am sincerely hoping that CGN is an extremely temporary situation.
> I’m not sure
> it should be worth the effort to recode the registry to support it.
>
> Second, I’m wondering if there’s any real advantage to having this level of
> detail on
> residential subscribers that don’t even get full addresses, since we don’t
> really tend
> to have it for single-address subscribers now.
>
> IMHO, best to just let each ISP keep this information for themselves as the
> relevant contact
> for abuse and such is usually the ISP and not the residential user anyway.
>
> Owen
>
> On Feb 23, 2015, at 10:53 , Masato Yamanishi <myamanis at gmail dot com> wrote:
>
> Dear Colleagues,
>
> And, here is prop-115. No comment has not been made for this proposal.
>
> If reached consensus, it may needs significant change for whois database.
> I just reviewed implementation impact assessment by the Secretariat,
> and it says it might take more than 6 months.
> I think same thing will happen for whois database of each NIRs.
> And if your company have a system linked with APNIC/NIR whois database, it
> will be impacted also.
>
> As Chair, I'm always very neutral for each proposal, including prop-115.
> However, I would like to emphasis prop-115 should be discussed more widely
> as it has wide impact.
> It is very appreciated if you will express your views.
>
> Regards,
> Masato Yamanishi, Policy SIG Chair (Acting)
>
>
> 2015-02-04 14:52 GMT-06:00 Masato Yamanishi <myamanis at gmail dot com>:
>>
>> 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
>