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
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).
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.
Propose to provide the same service for IPv6 allocations.
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 mailing list
sig-policy@lists.apnic.net
http://mailman.apnic.net/mailman/listinfo/sig-policy
