Keyboard Shortcuts
Thread View
j: Next unread messagek: Previous unread messagej a: Jump to all threadsj l: Jump to MailingList overview
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
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@gmail.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-115You 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
- 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
- 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.
- Situation in other regions
No same regulation/discussion can be seen in other regions.
- 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.
- 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.
- Impact on APNIC
This might be beyond the scope of using whois DB.
- 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
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@gmail.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@gmail.com mailto:myamanis@gmail.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 <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 mailto:hiromi@inetcore.com
Tomohiro Fujisaki fujisaki@syce.net <mailto:fujisaki@syce.net>
- 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 <http://192.0.2.24/32> 1-256 is for HomeA 192.0.2.24/32 <http://192.0.2.24/32> 257-511 is for HomeB or 192.0.2.0/24 <http://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
- 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.
- Situation in other regions
No same regulation/discussion can be seen in other regions.
- 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.
- 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.
- Impact on APNIC
This might be beyond the scope of using whois DB.
- 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
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@internetnz.net.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@delong.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@gmail.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@gmail.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-115You 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
- 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
- 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.
- Situation in other regions
No same regulation/discussion can be seen in other regions.
- 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.
- 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.
- Impact on APNIC
This might be beyond the scope of using whois DB.
- 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
Dean,
I totally agree that we should focus on the problem statement itself in Fukuoka since this problem statement has something new concept for Policy SIG and Fukuoka will be first meeting.
However, I don't think this proposal needs to be withdrawn to focus on the problem statement in Fukuoka.
Certainly, in past meeting, we made it clear that we can discuss "problem statement only presentation" first, but that is optional.
Regards, Masato
2015-02-24 14:41 GMT-06:00 Dean Pemberton dean@internetnz.net.nz:
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@internetnz.net.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@delong.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@gmail.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@gmail.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-115You 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
- 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
- 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.
- Situation in other regions
No same regulation/discussion can be seen in other regions.
- 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.
- 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.
- Impact on APNIC
This might be beyond the scope of using whois DB.
- 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
I look forward to hearing more from the author.
At present I do not support this proposal.
On Wednesday, 25 February 2015, Masato Yamanishi myamanis@gmail.com wrote:
Dean,
I totally agree that we should focus on the problem statement itself in Fukuoka since this problem statement has something new concept for Policy SIG and Fukuoka will be first meeting.
However, I don't think this proposal needs to be withdrawn to focus on the problem statement in Fukuoka.
Certainly, in past meeting, we made it clear that we can discuss "problem statement only presentation" first, but that is optional.
Regards, Masato
2015-02-24 14:41 GMT-06:00 Dean Pemberton <dean@internetnz.net.nz javascript:_e(%7B%7D,'cvml','dean@internetnz.net.nz');>:
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@internetnz.net.nz javascript:_e(%7B%7D,'cvml','dean@internetnz.net.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@delong.com javascript:_e(%7B%7D,'cvml','owen@delong.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@gmail.com
javascript:_e(%7B%7D,'cvml','myamanis@gmail.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@gmail.com
javascript:_e(%7B%7D,'cvml','myamanis@gmail.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-115You 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
javascript:_e(%7B%7D,'cvml','hiromi@inetcore.com');
Tomohiro Fujisaki fujisaki@syce.netjavascript:_e(%7B%7D,'cvml','fujisaki@syce.net');
- 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 oneuser.
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
- 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.
- Situation in other regions
No same regulation/discussion can be seen in other regions.
- 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.
- 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.
- Impact on APNIC
This might be beyond the scope of using whois DB.
- 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 fromhosting
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
javascript:_e(%7B%7D,'cvml','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
javascript:_e(%7B%7D,'cvml','sig-policy@lists.apnic.net');
Personally,I don't see any benefit,which community may be getting after accepting this proposal. I don't support this proposal. Regards, Ajai Kumar
On 24 February 2015 at 22:41, Owen DeLong owen@delong.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@gmail.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@gmail.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-115You 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
- 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
- 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.
- Situation in other regions
No same regulation/discussion can be seen in other regions.
- 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.
- 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.
- Impact on APNIC
This might be beyond the scope of using whois DB.
- 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
I do not support this proposal, on the basis that it seems its intent is to extend the scope of the APNIC whois database well beyond its traditional scope.
I believe the purpose of the APNIC database is to assert the authorisation of an assignee to use specified IP addresses, for purposes such as route validations or route dispute resolutions. The database only relates to the network layer identifiers that APNIC is chartered to administrate (i.e. IP addresses and AS numbers).
APNIC does not administrate or register the use of transport-layer identifiers (TCP or UDP ports); APNIC does not have the charter to state that certain TCP/UDP ports have been duly assigned and provide any authority for their use. Also, standard Internet routing does not function on the basis of TCP/UDP ports.
I therefore feel that any recording of any TCP/UDP port assignments would be outside of the scope of APNIC's business.
Regards,
David Woodgate
On 1/03/2015 11:30 PM, Ajay Kumar wrote:
Personally,I don't see any benefit,which community may be getting after accepting this proposal. I don't support this proposal. Regards, Ajai Kumar
On 24 February 2015 at 22:41, Owen DeLong <owen@delong.com mailto:owen@delong.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. OwenOn Feb 23, 2015, at 10:53 , Masato Yamanishi <myamanis@gmail.com <mailto:myamanis@gmail.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@gmail.com <mailto:myamanis@gmail.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@inetcore.com <mailto:hiromi@inetcore.com> Tomohiro Fujisaki fujisaki@syce.net <mailto: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 <http://192.0.2.24/32> 1-256 is for HomeA 192.0.2.24/32 <http://192.0.2.24/32> 257-511 is for HomeB or 192.0.2.0/24 <http://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 <mailto: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 <mailto: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
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-115You 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
- 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
- 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.
- Situation in other regions
No same regulation/discussion can be seen in other regions.
- 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.
- 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.
- Impact on APNIC
This might be beyond the scope of using whois DB.
- 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
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 |
Activity Summary
- 3134 days inactive
- 3134 days old
- sig-policy@lists.apnic.net
- 6 participants
- 9 comments