Hi Philip,

Thank you for your comment and support.

|If the policy proposal talked about greater ISP education on the |problems of bogon filtering as part of *all* the RIR member outreach, |then it would make more sense. Fix the cause of the problem, not add |ever more complexity and bureaucracy to existing proposed solutions.

Yes, that's my point.

My fundamental motivation of this proposal is for education of *all* the RIR member, and making more relationship between RIRs and ISPs not only annoucing the information of new IANA allocations.

I believe that this helps ISPs for checking their bogon filtering by automatic check from RIR site using sample test prefix of new IANA allocatoins, also it could be useful information in case of some rechability trouble.

By introducing this mechanism by all RIRs in the case of all future assignment of /8, I think that it helps to eradicate the omission in filter update.

Regards,

-tomoya

Philip Smith pfs@cisco.com wrote: (2006/08/09 16:07)

|I fail to see how this policy proposal helps at all. | |The fundamental problem is that ISPs use historical "bogon" filters, and |they ignore frequent messaging that these filters are dynamic and need |frequent updating: | |- Frequent postings by the RIRs on all the NOG lists don't help. | |- Project Cymru have an accurate BGP bogon feed which more ISPs should |be using, but most have never heard of: |http://www.cymru.com/Bogons/index.html and |http://www.cymru.com/BGP/bogon-rs.html | |- The RIRs have the debogon project at |http://www.ris.ripe.net/debogon/debogon.html but that's ignored | |It's not the lack of info out there, so simply adding more overhead and |more expense seems a waste of time to me. | |If the policy proposal talked about greater ISP education on the |problems of bogon filtering as part of *all* the RIR member outreach, |then it would make more sense. Fix the cause of the problem, not add |ever more complexity and bureaucracy to existing proposed solutions. | |philip |-- | |Toshiyuki Hosaka said the following on 7/8/06 17:14: |> Dear SIG members |> |> The proposal "A proposal to improve reachability of new IANA blocks" has |> been sent to the Policy SIG for review. It will be presented at the |> Policy SIG at APNIC 22 in Kaohsiung, Taiwan, 4-8 September 2006. You are |> invited to review and comment on the proposal on the mailing list before |> the meeting. |> |> The proposal's history can be found at: |> |> http://www.apnic.net/docs/policy/proposals/prop-039-v001.html |> |> Regards, |> |> Toshiyuki Hosaka |> Policy SIG |> hosaka@nic.ad.jp |> |> ________________________________________________________________________ |> |> prop-039-v001: A proposal to improve reachability of new IANA blocks |> ________________________________________________________________________ |> |> |> |> Author: Tomoya Yoshida |> yoshida@ocn.ad.jp |> |> Version: 1 |> |> Date: 7 August 2006 |> |> |> Introduction |> ------------ |> |> The objective of this proposal is to establish basis of cooperation |> between RIRs/ISPs to test and ensure routability of new IANA |> allocations to RIRs. |> |> |> Summary of the current problem |> ------------------------------ |> |> APNIC and some of the RIRs provide a trial service for testing |> reachability and routability of new IANA allocations. |> |> http://www.ris.ripe.net/debogon/debogon.html |> |> However, problems still remains for ISPs that almost all such |> allocations are unreachable and unable to use immediately after |> allocations. There are a number of cases which an allocated block |> remain unreachable upto one year after the allocation is made. |> |> Situation in other RIRs |> ----------------------- |> |> RIPE and AfriNIC conduct a trial service jointly with APNIC, however |> there are same situation in other RIRs. |> |> (*) Needs confirmation with RIPE and AfriNIC |> |> Details of this proposal |> ------------------------ |> |> 1) Propose a full scale service for de-bogonizing new IANA allocations |> instead of a trial service currently conducted for 121/8,122/8,123/8 |> (Provide an enviroment where multiple reachability can be secured for |> a single /8 as much as possible). |> |> 2) Propose RIRs to estabilish a site for ISPs to confirm reachability |> e.g. Enable automatic notification of theicmp/traceroute from RIRs to |> ISP's site by registering ISP's own icmp/traceroute testing servers |> to RIRs. Details of the implementation will be left up to APNIC. |> |> 3) Propose to provide the same service for IPv6 allocations. |> |> 4) Propose the service by all RIRs and not be restricted within the AP |> region. |> |> |> Pros/Cons |> --------- |> |> Advantages: |> |> + LIRs will be able to use the address space more quicker than |> before after an allocation as a result of de-bogonization |> |> + Will be able to determine the cause of unreachability and other |> network problems |> |> + LIRs also will be able to check whether their bogon filtering is |> updated or not |> |> + RIRs will be able to understand or confirm situation of |> reachability or routability of new IANA allocations |> |> Disadvantages: |> |> + May need to consider whether its benefits scale the expenses |> |> Additional note: |> |> May able to convert the use of the address ranges reserved for |> reachability testing for assignments to critical networks at the |> time of IPv4 address exhaustion. |> |> |> Effect on APNIC |> --------------- |> Will improve reachability or routability of new IANA blocks for members. |> |> |> Effect on NIRs |> -------------- |> Will improve reachability or routability of new IANA blocks for members. |> |> |> |> * 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