Re: [sig-policy] Prop-115 revised.
Thanks for your comment.
Your thoughts in the mail is just we want to describe as policy proposal.
Someone in the meeting place said that is not "policy issue" but I
think it should be going with policy decision among policy-SIG members
if implemented in the whois DB.
We also had a comment that this is related to privacy issue.
As Mr.Mark also pointed out in his mail, it is nothing to do with
privacy of users because LIR/ISP just add their "standard size of
assignment for customers" and does not specify who has the address. But
Am I missing some points?
Which is the best choice of implementation?
I also think whois DB is the best one, which is useful and reasonable.
Any comments and questions are welcomed, thank you.
Regards,
On 2016/02/25 6:41, Mark Foster wrote:
> Hello,
> I would like to thank Ruri Hiromi for presenting during the Policy-SIG
> today at APRICOT.
> I confess to having only limited time to review this discussion group
> and as such, the presentation as made to the SIG was the first that I
> was aware of this discussion.
> The discussion and result of the meeting caused me to search my email
> for this discussion and I found this email, which helped me understand
> the intent.
>
> As I understand it, the level of detail that is being suggested for
> addition to 'whois', is simply a generic statement as regards to the
> 'standard' size of an allocation from within an IPv^ supernet? And that
> the purpose for this, is to allow third parties wish to filter traffic
> at a level which limits 'collateral damage' when applying that filter,
> perhaps with a view to blocking traffic from insecure or poorly
> configured IoT devices that may receive an IPv6 address from within a
> customer allocation?
>
> If this is the case, then I would suggest the 'path of least resistance'
> would be to have this documented as an optional standard, that service
> providers may choose to adopt.
> Important for the understanding of the community is that (if my
> understanding is correct) this is simply a two-line type addition to the
> supernet whois entry - 'The standard allocation size in this network is
> /56' (or similar) - so that a third party wishing to apply a filter to
> only a single customer of said service provider, may apply it to the /56
> from which the offending /132 (or /64) originates and ensure then that
> other customers of said service provider are not inadvertantly filtered.
>
> Am I right?
> If this is the extent, then I would revise my position and endorse this
> proposal as an optional recommendation to service providers in the
> initial stages, perhaps to measure the usefulness of the change and
> determine if it should become something more compelling down-track?
>
> Thanks,
> Mark.
>
> PS: I believe that 'whois' is the right place for this information; it
> was already noted that this can be done in 'remarks' right now. Any
> service provider looking to implement a filter against malicious
> traffic, etc, is likely going to need to use whois to determine the
> source (and scope) of the problem they are addressing in any case. It
> would seem to be a low-noise, low-drama way of imparting a potentially
> useful piece of information. As such I support only the 'whois' option
> presented below at this point.
>
>
> On Mon, Feb 15, 2016 at 9:32 PM, Ruri Hiromi <hiromi at inetcore dot com
> <mailto:hiromi at inetcore dot com>> wrote:
>
> Hello all,
>
> I as one of authors of prop-115, am posting here our new text for
> discussion. At this time, we focused on expanding IoT over IPv6.
>
> Please see section 4, and send your opinion what would be the best
> practice.
> After discussing about the possible solution of providing detailed
> information, we will send a proposal.
>
> ------------------------------------------------------------------------
> prop-nnn-v00n: Registration of detailed assignment information in public
> accessible DB
> ------------------------------------------------------------------------
>
> Proposer: Ruri Hiromi
> hiromi at inetcore dot com <mailto:hiromi at inetcore dot com>
>
> Tomohiro Fujisaki
> fujisaki at syce dot net <mailto:fujisaki at syce dot net>
>
> 1. Problem statement
> --------------------
>
> Now the usage of Internet of Things(IoT) is expanding worldwide.
> Devices are connecting over IPv6 network internally or globally.
>
> Along with this, there are some cases where we need to get IP address
> assignment information in more detail to specify its address range.
>
> Without 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, IPv6 address assignment size to end users
> may differ from ISPs (e.g. ISP A assigns /56 to their consumer users
> and ISP B assigns /48), and also even in one ISP, from their customers
> (e.g. /56 to consumer users and /48 to enterprise users).
> For IoT networks, IoT devices may have own /128 IPv6 addresses.
>
>
> 2. Objective of policy change
> -----------------------------
>
> Many operators look a record when harmful behavior coming to their
> network to identify its IP address for 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
> ---------------------------
>
> (Need to specify the solution)
>
> A. Use whois database
>
> - Use whois DB to provide 'assignment prefix size' information
> for specific IPv6 address ranges.
>
> Example:
> inet6num: 2001:db8:0100::/40
> netname: EXAMPLE-0100
> descr: INFRASTRUCTURE-CUSTOMER-ASSIGNMENT-BLOCK
> country: JP
> admin-c: JP00001017
> tech-c: JP00000593
> Assignment-size: /56 <-- * this is able to use for above purpose
> remarks: This information has been partially mirrored by
> APNIC from
> remarks: JPNIC. To obtain more specific information, please
> use the
> remarks: JPNIC WHOIS Gateway at
> remarks: http://www.nic.ad.jp/en/db/whois/en-gateway.html or
> remarks: whois.nic.ad.jp <http://whois.nic.ad.jp> for
> WHOIS client. (The WHOIS client
> remarks: defaults to Japanese output, use the /e switch for
> English
> remarks: output)
> changed: apnic-ftp at nic dot ad dot jp <mailto:apnic-ftp at nic dot ad dot jp>
> 20050809
> source: JPNIC
>
> - Possible to use 'remarks:' field for this purpose.
>
> Example:
> remarks: </AssignmentSize /56> <-- * this, too.
>
>
> B. Use Domain Name System
>
> - Adding new resource record or using the TXT field.
> - Reverse delegation tree might be used to provide this information.
> But not of all the PTR records for IPv6 registered.
> An operator should act look up its PTR record for the domain name then
> AAAA record to see TXT field.
> - It would be better PTR record returns its assignment size.
> - Need to discuss with DNS experts.
>
> Example:
> mydomain.com <http://mydomain.com>. TXT "assignment-size=/56"
>
> C. Use IRR to provide assignment size information
>
> - Adding new object, or modifying object attribute.
> - Need to discuss with RPSL experts.
>
> Example:
> (reuse of descr/remarks attribute)
> route6: 2001:db8:0100::/40
> descr: assignment size = /56
> or
> remarks: assignment size = /56
>
> Example:
> (add a new attribute)
> route6: 2001:db8:0100::/40
> size: /56
>
> D. Use another database
>
> - Use organizations' web page, another registration DB, etc. to
> provide assignment size information.
>
>
> E. Use routing system
>
> - Use routing protocol to provide assignment size information.
> - Need to decide the target protocol then consider new filed or modify
> existing filed. Proposal to IETF and implementation by vendors.
> This might be the hardest solution.
> - Need to discuss Routing Protocol experts.
>
>
> 5. Advantages / Disadvantages
> -----------------------------
>
> Advantages:
>
> - operators can set filters by IPv6 address based on correct assignment
> information base.
>
> Disadvantages:
>
> - Registration rule will move to more strict manner.
>
> - Strict watch and control in registration of database records.
>
> - Additional record or option needs to be considered (depend on the
> mechanizm).
>
>
> 6. Impact on APNIC
> ------------------
>
> TBD (depend on the mechanisms)
>
>
> References
> ----------
>
> TBD
> -------------------------------------------------------------------
>
>
> On 2016/02/11 12:34, 藤崎智宏 wrote:
> > Hi Dean,
> >
> > Thank you so much for your suggestion, and sorry for replying late.
> >
> > Your suggestion is quite reasonable.
> >
> > We, authors have asked sig chairs to withdraw our current proposal
> > and time slot for informational discussion on this issue.
> >
> > It will be announced formally soon.
> >
> > We'll post our proposed text and ask for discussion here later.
> >
> > Yours Sincerely,
> > ---
> > Tomohiro Fujisaki
> >
> >
> > 2016-02-10 4:29 GMT+09:00 Dean Pemberton <dean at internetnz dot net dot nz
> <mailto:dean at internetnz dot net dot nz>>:
> >> Fujisaki-San.
> >>
> >> Thank you for this updated submission.
> >>
> >> I would like to address one point you make in your email.
> >> You seem to be suggesting that this proposal is not yet complete
> and the
> >> authors are in fact seeking community feedback at this time.
> >>
> >> "At this time, in the next sig meeting, we would like to discuss
> more about
> >> the methods and find a conclusion."
> >>
> >> While this is understandable, I believe that there are some
> aspects of this
> >> situation which need to be addressed.
> >>
> >> a) if there is an acknowledgement by the authors that the
> proposal is as yet
> >> incomplete, then it should be withdrawn and an 'informational'
> session held
> >> at the policy sig in its place.
> >>
> >> b) there may be a feeling by the authors that a proposal is the only
> >> mechanism available to them. They may feel that the community
> provides
> >> inadequate feedback unless there is a proposal being discussed.
> I have
> >> some sympathy for this point of view, but I believe that it sets
> a dangerous
> >> precedent where proposals are brought to the community where a more
> >> informal method of engagement would be more appropriate.
> >>
> >> c) InternetNZ has a number of policy principles which guide its
> response to
> >> issues. One of them is:
> >>
> >> "Internet governance should be determined by open, multi-stakeholder
> >> processes."
> >>
> >> Even with the advances in Policy SIG remote participation, care
> must be
> >> taken before points discussed at the policy sig meeting could be
> claimed to
> >> be supported by a multi-stakeholder process.
> >> If for example we find ourselves at a Policy SIG meeting making
> substantive
> >> changes to a policy before calling for consensus, it could be
> argued that
> >> this excludes a significant proportion of the Internet community
> who may be
> >> effected by these changes.
> >> Ensuring that policy wording is essentially complete, and
> presented to the
> >> mailing list by the time the meeting starts ensures that the largest
> >> possible community has had an opportunity for engagement and
> therefore can
> >> be considered a true multi-stakeholder process.
> >>
> >> Therefore I suggest the following ways forward
> >>
> >> 1) If the authors feel that the proposal will not be complete by
> the time
> >> of the Policy SIG meeting, that the proposal be reframed as an
> Informational
> >> Session for community discussion during the meeting
> >>
> >> or
> >>
> >> 2) That the authors lead an open discussion of the methods on
> the mailing
> >> list with a view to presenting a single finished version before
> the Policy
> >> SIG meeting. This will ensure that substantive changes are not
> required
> >> during the meeting. If such a version is not ready, then as per
> 1) it
> >> should be changed to an Informational Session.
> >>
> >>
> >> Kind Regards
> >>
> >> Dean Pemberton
> >>
> >>
> >>
> >>
> >>
> >>
> >> On Wednesday, 10 February 2016, 藤崎智宏 <fujisaki at syce dot net
> <mailto:fujisaki at syce dot net>> wrote:
> >>>
> >>> Dear all,
> >>>
> >>> We've posted new version of prop-115, and it will appear on the
> web soon.
> >>>
> >>> Main modification points are:
> >>> - remove IPv4 text
> >>> - propose several methods to register and distribute IPv6
> assignment
> >>> information (thank you for your suggestion in the previous sig
> >>> meeting)
> >>>
> >>> Authors discussed about methods, but could not reach a decision
> which to
> >>> be used. At this time, in the next sig meeting, we would like
> to discuss
> >>> more
> >>> about the methods and find a conclusion.
> >>>
> >>> We appreciate if you give us any comments or suggestions.
> >>>
> >>> Yours Sincerely,
> >>> --
> >>> Ruri Hiromi
> >>> Tomohiro Fujisaki
> >>> * sig-policy: APNIC SIG on resource management policy
> >>> *
> >>> _______________________________________________
> >>> sig-policy mailing list
> >>> sig-policy at lists dot apnic dot net <mailto: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 <mailto: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 <mailto:sig-policy at lists dot apnic dot net>
> http://mailman.apnic.net/mailman/listinfo/sig-policy
>
>
--
===================================
株式会社インテック
先端技術開発本部 先端技術研究所
廣海(ひろみ)緑里