• Date Prev
• Date Next
• Thread Prev
• Thread Next
• Date Index
• Thread Index

Re: [ATTN JLB CC] Re: [sig-policy] Forwarded reply from Gordon Bader

• To: Joe Baptista <baptista at dot-god dot com>
• Subject: Re: [ATTN JLB CC] Re: [sig-policy] Forwarded reply from Gordon Bader
• From: GB <gbader at cox dot net>
• Date: Mon, 16 Aug 2004 06:11:02 -0700
• Cc: APNIC Secretariat <secretariat at apnic dot net>,Jeff Williams <jwkckid1 at ix dot netcom dot com>, sig-policy at apnic dot net
• In-reply-to: <Pine.LNX.4.33.0408102040470.3801-100000 at dot-god dot com>
• List-archive: <http://www.apnic.net/mailing-lists/sig-policy>
• List-help: <mailto:sig-policy-request@lists.apnic.net?subject=help>
• List-id: APNIC SIG on resource management policy <sig-policy.lists.apnic.net>
• List-post: <mailto:sig-policy@lists.apnic.net>
• List-subscribe: <http://mailman.apnic.net/mailman/listinfo/sig-policy>,<mailto:sig-policy-request@lists.apnic.net?subject=subscribe>
• List-unsubscribe: <http://mailman.apnic.net/mailman/listinfo/sig-policy>,<mailto:sig-policy-request@lists.apnic.net?subject=unsubscribe>
• References: <Pine.LNX.4.33.0408102040470.3801-100000@dot-god.com>
• User-agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US;rv:1.4) Gecko/20030624 Netscape/7.1 (ax)
Good Day Everyone,

I absolutely agree with the comments of Mr. Baptista. This proposal is legally explosive, and it is a backwater area that has been overlooked. Additionally, there probably are no contracts on various areas of IP space.

However, that being said and agreed to, just because something is hard, does it make it not worth doing? The reason why this is a problem is because of these conditions. The reason the dark IP address space is being used, is because it is not being controlled as it should be. In a perfect system this would not happen. Some service carriers are filtering out dark space. Some are keeping their routing tables as clean as possible, while others are not.

Let me return to my original argument. APNIC's primary function is to help bring control to the internet and to allocate IP space. If it does not control various areas of the IP address space it has been allocated then APNIC is not doing it's job. The problem will only get worse. Is this the proper proposal? I do not know, that is your call. I do know that if nothing is done, specifically due to the problems you cite, the problem will get worse and it will be more difficult to regain control in the end.

As we all know the people who are using the unallocated IP address space, are using it for purposes that would cause them to loose their Internet access with a normal ISP due to their APUs. So they set up shop in "no-man's land", thus thinking that their access can not be denied. So far it appears that they are correct. APNIC has not allocated them access. The carriers who's routing tables route to the dark space are allocating them the space, the service, and essentially recognizing their "right" to use the space. Essentially "squatter's rights". The carriers who are providing them access through compromised routing tables are essentially for all purposes ceding ownership to their Internet access on behalf of everyone. That returns us to APNIC's charter providing for control and IP allocation. That also leaves us with the question of what can and will be done?

In the early days, UseNet administrators reserved the death penalty for users who did not comply with some basic standards. You cause no problems, you stay connected. A number of years ago, I remember the @home service nearly receiving the "death penalty" for their lack of actions on behalf of their users. This proposal operates along the same lines. There was no UseNet contracts that were available to enforce.
Again I know that this is uncharted. However, I again ask, how will APNIC regain control and how will carriers (at all levels) be forced to stop providing access to users who have "claimed" various segments of unallocated IP address space?

With regards,
Gordon

Joe Baptista wrote:



On Mon, 9 Aug 2004, Jeff Williams wrote:




APNIC has the ability to grant IP space. Given that ability, it also
has the inherent ability to remove what was granted. The implicit
grant of IP space, carries with it the ability to route, and route
in a "legal" manner. When "illegal" (dark address space) routing is
detected, then the price should be loss of the initial grant - in this
case the ability to operate which carries with it economic measures.



Your gettin into legally explosive backwaters here. I know of many who
have address space outside the control of the RIR - in many cases no
legal agreements exists.

Much of this no mans land is in North America and a few other countries.

The RIR in fact control nothing but the reverse arpa. Routing is between
the provider and the IP administrator.




Routing tables should be configured for non routing (filtering) of
unallocated IP address space as well as allocated IP address space.
Traffic to and from unallocated (or allocated but unused) IP address
space should be dropped as soon as recognized, thus saving bandwidth up
channel.



???




Employ the basic law - what can be given, can be taken away. APNIC
should issue a warning first, followed by removal of IP space from the
offending ISP or entity at what ever level. IP addresses are provided
under a contract, thus using contract law, removal is possible.



Again I clearly point out - alot of IP address space is not under contract.




I don't quite understand how APNIC can be invloved in this, and how
effective it would be in addressing the problem. I hope you can
clarify this a little bit more.



You can't - it's not your business to act as judge nor jury.

regards
joe baptista





• Date Prev
• Date Next
• Thread Prev
• Thread Next
• Date Index
• Thread Index
• Prev by Date: [sig-policy] APNIC Policy implementation update
• Next by Date: Re: [sig-policy] Forwarded reply from Gordon Bader
• Previous by thread: [sig-policy] APNIC Policy implementation update
• Next by thread: Re: [ATTN JLB CC] Re: [sig-policy] Forwarded reply from Gordon Bader
• Index(es):
  • Date
  • Thread