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
Tomohiro Fujisaki
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 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 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. 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>:
>> 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> 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
>>> 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
>
* 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