[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [sig-policy] Forwarded reply from Gordon Bader
hi Gordon,
To obtain authoritative information for the APNIC databse you will need
to check the APNIC whois database. The information in the various outputs
you quote below do in fact point to the APNIC database for the source of
authoritative information. (As a note, APNIC has a number of NIRs in
the region, and the NIR databases are mirrored by APNIC).
This FAQ on the APNIC database may be useful:
http://www.apnic.net/info/faq/abuse/using_whois.html#1
The information in this paragraph of the APNIC faq on spamming and
hacking complaints may also be useful:
'So why does my software say APNIC is responsible?'
http://www.apnic.net/info/faq/abuse/index.html#3
Queries to the APNIC database are rate limited. If your query came
from Spam Spade it is likely that the rate limit had been exceeded. I
think this is the most likely explanation.
I hope this helps,
Anne
--
> 08/17/04 05:29:23 IP block 210.180.97.21
> Trying 210.180.97.21 at ARIN
> Trying 210.180.97 at ARIN
>
> OrgName: Asia Pacific Network Information Centre
> OrgID: APNIC
> Address: PO Box 2131
> City: Milton
> StateProv: QLD
> PostalCode: 4064
> Country: AU
>
> ReferralServer: whois://whois.apnic.net
>
> NetRange: 210.0.0.0 - 211.255.255.255
> CIDR: 210.0.0.0/7
> NetName: APNIC-CIDR-BLK2
> NetHandle: NET-210-0-0-0-1
> Parent:
> NetType: Allocated to APNIC
> NameServer: NS1.APNIC.NET
> NameServer: NS3.APNIC.NET
> NameServer: NS4.APNIC.NET
> NameServer: NS.RIPE.NET
> NameServer: TINNIE.ARIN.NET
> NameServer: DNS1.TELSTRA.NET
> Comment: This IP address range is not registered in the ARIN
> database.
> Comment: For details, refer to the APNIC Whois Database via
> Comment: WHOIS.APNIC.NET or http://www.apnic.net/apnic-bin/whois2.pl
> Comment: ** IMPORTANT NOTE: APNIC is the Regional Internet Registry
> Comment: for the Asia Pacific region. APNIC does not operate
> networks
> Comment: using this IP address range and is not able to investigate
> Comment: spam or abuse reports relating to these addresses. For more
> Comment: help, refer to http://www.apnic.net/info/faq/abuse
> Comment:
> RegDate: 1996-07-01
> Updated: 2004-03-30
>
> OrgTechHandle: AWC12-ARIN
> OrgTechName: APNIC Whois Contact
> OrgTechPhone: +61 7 3858 3100
> OrgTechEmail: search-apnic-not-arin@apnic.net
>
> # ARIN WHOIS database, last updated 2004-08-16 19:10
> # Enter ? for additional hints on searching ARIN's WHOIS database.
>
> I also used the following list of whois servers (all of them), each
> of which returned the same information as above:
>
> Magic
> whois.internic.net
> whois.arin.net
> whois.ripe.net
> whois.nic.net
> whois.aunic.net
> whois.cdnnet.ca
> whois.nic.ch
> whois.crsnic
> whois.eunet.es
> whois.nic.fr
> whois.nic.gov
> whois.apnic.net
> whois.nis.garr.it
> whois.nic.ad.jp
> whois.nic.nm.kr
> whois.nic.li
> whois.ddn.mil
> whois.nic.mx
> whois.domain-registry.nl
> whois.ripn.net
> whois.internic.se
> whois.grnes.si
> whois.thnic.net
> whois.nic.tj
> whois.nic.uk
> whois.ja.net
> nii-server.isi.edu
> rhwois.exodus.net
> rwhois.digex.net
> rwhois.geektools.com
>
> Prior to writing and inserting the table, I checked and I just
> checked again all of these whois servers. They all come up with the
> same information that hops 15 through 19 inclusive are allocated to
> APNIC and as indicated by the comment "This IP address range is not
> registered in the ARIN database." So if I have made a mistake I
> appologize - especially to ATT. However the information that I obtained
> pointed to these addresses as being unallocated.
>
> In using the ARIN WHOIS database at
> http://ws.arin.net/cgi-bin/whois.pl and
> Network Solutions database at
> http://www.networksolutions.com/en_US/whois/index.jhtml
> one receives back the following:
> Search results for: 210.180.97.21
>
> OrgName: Asia Pacific Network Information Centre
> OrgID: APNIC <http://ws.arin.net/cgi-bin/whois.pl?queryinput=O%20%21%20APNIC>
> Address: PO Box 2131
> City: Milton
> StateProv: QLD
> PostalCode: 4064
> Country: AU
>
> ReferralServer: whois://whois.apnic.net
>
> NetRange: 210.0.0.0 <http://ws.arin.net/cgi-bin/whois.pl?queryinput=210.0.0.0> - 211.255.255.255 <http://ws.arin.net/cgi-bin/whois.pl?queryinput=211.255.255.255>
> CIDR: 210.0.0.0/7
> NetName: APNIC-CIDR-BLK2 <http://ws.arin.net/cgi-bin/whois.pl?queryinput=N%20.%20APNIC-CIDR-BLK2>
> NetHandle: NET-210-0-0-0-1 <http://ws.arin.net/cgi-bin/whois.pl?queryinput=N%20%21%20NET-210-0-0-0-1>
> Parent:
> NetType: Allocated to APNIC
> NameServer: NS1.APNIC.NET
> NameServer: NS3.APNIC.NET
> NameServer: NS4.APNIC.NET
> NameServer: NS.RIPE.NET
> NameServer: TINNIE.ARIN.NET
> NameServer: DNS1.TELSTRA.NET
> Comment: This IP address range is not registered in the ARIN database.
> Comment: For details, refer to the APNIC Whois Database via
> Comment: WHOIS.APNIC.NET or http://www.apnic.net/apnic-bin/whois2.pl
> Comment: ** IMPORTANT NOTE: APNIC is the Regional Internet Registry
> Comment: for the Asia Pacific region. APNIC does not operate networks
> Comment: using this IP address range and is not able to investigate
> Comment: spam or abuse reports relating to these addresses. For more
> Comment: help, refer to http://www.apnic.net/info/faq/abuse
> Comment:
> RegDate: 1996-07-01
> Updated: 2004-03-30
>
> OrgTechHandle: AWC12-ARIN <http://ws.arin.net/cgi-bin/whois.pl?queryinput=P%20%21%20AWC12-ARIN>
> OrgTechName: APNIC Whois Contact
> OrgTechPhone: +61 7 3858 3100
> OrgTechEmail: search-apnic-not-arin@apnic.net
>
> # ARIN WHOIS database, last updated 2004-08-16 19:10
> # Enter ? for additional hints on searching ARIN's WHOIS database.
>
>
>
> However, when I go to your website
> http://www.apnic.net/apnic-bin/whois.pl/ I do receive the information
> you cite with respect to Korea Network Information Center. I am not
> clear as to why Sam Spade when pointed to your server - whois.apnic.net
> does not return the same information as your website returns. Was this
> a recent change?
>
> Thank you very much for the correction,
> Gordon
>
> Anne Lord wrote:
>
> >
> > Hi Gordon,
> >
> > I know you are including your traceroute as an example, but the
> > example given is not correct. The address space you refer to as "dark"
> > below from hop 15 onwards is in fact legitimately allocated.
> >
> > > 15 210.180.97.21 1091ms 1219ms 828ms TTL: 0 (No rDNS)
> > > 16 210.220.73.2 105ms 86ms 50ms TTL: 0 (No rDNS)
> > > 17 211.108.63.146 96ms 96ms 76ms TTL: 0 (No rDNS)
> > > 18 221.139.106.58 93ms 63ms 67ms TTL: 0 (No rDNS)
> > > 19 222.233.52.27 75ms 94ms 76ms TTL: 49 (No rDNS)
> >
> > > It is also interesting to note the infrastructure this has from hop
> > #15 through hop #19. They are >all dark address space, all APNIC IP
> > addresses. I have published this before several weeks >ago and
> > nothing has happened.
> >
> > All address space in the hops 15-19 has been allocated to the National
> > Internet Registry (NIR) for Korea - KRNIC and further allocated by
> > them to an LIR in KR. In this case, Hanaro Telecom is the LIR.
> >
> > Appended below is the 'whois' output from 'whois.apnic.net' for this
> > address space hop 15:
> >
> > inetnum: 210.180.32.0 - 210.180.223.255
> > netname: KRNIC-KR
> > descr: KRNIC
> > descr: Korea Network Information Center
> > country: KR
> > admin-c: HM127-AP
> > tech-c: HM127-AP
> > remarks: ******************************************
> > remarks: KRNIC is the National Internet Registry
> > remarks: in Korea under APNIC. If you would like to
> > remarks: find assignment information in detail
> > remarks: please refer to the KRNIC Whois DB
> > remarks: http://whois.nic.or.kr/english/index.html
> > remarks: ******************************************
> > mnt-by: APNIC-HM
> > mnt-lower: MNT-KRNIC-AP
> > changed: hm-changed@apnic.net 19981124
> > changed: hm-changed@apnic.net 20010606
> > changed: hm-changed@apnic.net 20040319
> > status: ALLOCATED PORTABLE
> > source: APNIC
> >
> > person: Host Master
> > address: 11F, KTF B/D, 1321-11, Seocho2-Dong, Seocho-Gu,
> > address: Seoul, Korea, 137-857
> > country: KR
> > phone: +82-2-2186-4500
> > fax-no: +82-2-2186-4496
> > e-mail: hostmaster@nic.or.kr
> > nic-hdl: HM127-AP
> > mnt-by: MNT-KRNIC-AP
> > changed: hostmaster@nic.or.kr 20020507
> > source: APNIC
> >
> > inetnum: 210.180.97.0 - 210.180.98.255
> > netname: HANANET-INFRA-KR
> > descr: Hanaro Telecom Inc.
> > descr: Shindongah Bldg., 43 Taepyeongno2-Ga Jung-Gu
> > descr: SEOUL
> > descr: 100-733
> > country: KR
> > admin-c: IA11935-KR
> > tech-c: IM11881-KR
> > remarks: This IP address space has been allocated to KRNIC.
> > remarks: For more information, using KRNIC Whois Database
> > remarks: whois -h whois.nic.or.kr
> > mnt-by: MNT-KRNIC-AP
> > remarks: This information has been partially mirrored by APNIC from
> > remarks: KRNIC. To obtain more specific information, please use the
> > remarks: KRNIC whois server at whois.krnic.net.
> > changed: hostmaster@nic.or.kr 20040802
> > source: KRNIC
> >
> > person: IP Administrator
> > descr: Hanaro Telecom Inc.
> > descr: Shindongah Bldg., 43 Taepyeongno2-Ga Jung-Gu
> > descr: SEOUL
> > descr: 100-733
> > country: KR
> > phone: +82-2-106-2
> > fax-no: +82-2-6266-6483
> > e-mail: ip-adm@hanaro.com
> > nic-hdl: IA11935-KR
> > mnt-by: MNT-KRNIC-AP
> > remarks: This information has been partially mirrored by APNIC from
> > remarks: KRNIC. To obtain more specific information, please use the
> > remarks: KRNIC whois server at whois.krnic.net.
> > changed: hostmaster@nic.or.kr 20040802
> > source: KRNIC
> >
> > person: IP Manager
> > descr: Hanaro Telecom Inc.
> > descr: Shindongah Bldg., 43 Taepyeongno2-Ga Jung-Gu
> > descr: SEOUL
> > descr: 100-733
> > country: KR
> > phone: +82-2-106-2
> > fax-no: +82-2-6266-6483
> > e-mail: ip-adm@hanaro.com
> > nic-hdl: IM11881-KR
> > mnt-by: MNT-KRNIC-AP
> > remarks: This information has been partially mirrored by APNIC from
> > remarks: KRNIC. To obtain more specific information, please use the
> > remarks: KRNIC whois server at whois.krnic.net.
> > changed: hostmaster@nic.or.kr 20040802
> > source: KRNIC
> >
> > Hope this clarifies things,
> >
> > cheers,
> > Anne
> > --
> >
> >> =========
> >> 08/16/04 07:07:39 Fast traceroute 222.233.52.27
> >> Trace 222.233.52.27 ...
> >> 1 10.84.224.1 19ms 12ms 13ms TTL: 0 (No rDNS)
> >> 2 68.2.4.73 12ms 11ms 10ms TTL: 0
> >> (ip68-2-4-73.ph.ph.cox.net ok)
> >> 3 68.2.0.37 12ms 12ms 14ms TTL: 0
> >> (ip68-2-0-37.ph.ph.cox.net ok)
> >> 4 68.2.0.113 14ms 14ms 15ms TTL: 0
> >> (ip68-2-0-113.ph.ph.cox.net ok)
> >> 5 68.2.14.13 48ms 15ms 14ms TTL: 0
> >> (chnddsrc02-gew0303.rd.ph.cox.net ok)
> >> 6 68.1.0.168 17ms 28ms 16ms TTL: 0
> >> (chndbbrc02-pos0101.rd.ph.cox.net ok)
> >> 7 64.154.128.29 14ms 17ms 28ms TTL: 0
> >> (p1-0.hsa1.phx1.bbnplanet.net ok)
> >> 8 4.68.113.253 17ms 14ms 18ms TTL: 0
> >> (so-6-2-0.mp2.Phoenix1.Level3.net ok)
> >> 9 64.159.1.30 4ms 26ms 24ms TTL: 0
> >> (as-0-0.bbr1.LosAngeles1.Level3.net ok)
> >> 10 209.247.9.214 25ms 27ms 26ms TTL: 0
> >> (so-7-0-0.gar1.LosAngeles1.Level3.net ok)
> >> 11 4.68.127.138 26ms 23ms 25ms TTL: 0
> >> (att-level3-oc48.LosAngeles1.Level3.net ok)
> >> 12 12.123.29.6 24ms 27ms 27ms TTL: 0
> >> (tbr2-p012101.la2ca.ip.att.net probable bogus rDNS: No DNS)
> >> 13 12.123.199.229 26ms 25ms 22ms TTL: 0
> >> (gar1-p3100.lsnca.ip.att.net probable bogus rDNS: No DNS)
> >> 14 12.119.138.38 25ms 24ms 25ms TTL: 0 (No rDNS)
> >> 15 210.180.97.21 1091ms 1219ms 828ms TTL: 0 (No rDNS)
> >> 16 210.220.73.2 105ms 86ms 50ms TTL: 0 (No rDNS)
> >> 17 211.108.63.146 96ms 96ms 76ms TTL: 0 (No rDNS)
> >> 18 221.139.106.58 93ms 63ms 67ms TTL: 0 (No rDNS)
> >> 19 222.233.52.27 75ms 94ms 76ms TTL: 49 (No rDNS)
> >> ======
> >>
> >>
> >> Consider this traceroute that I took several minutes ago, Hop #14
> >> is ATT, Hop #15 is dark space. Please check the date (against the
> >> date of the traceroute later in this email trail), ATT has been
> >> routing dark space for about 3 weeks now, and they have been
> >> notified. Is this an isolated instance? Maybe (hopefully). But they
> >> have not been very proactive on this one particular address.
> >>
> >> It is also interesting to note the infrastructure this has from
> >> hop #15 through hop #19. They are all dark address space, all APNIC
> >> IP addresses. I have published this before several weeks ago and
> >> nothing has happened.
> >>
> >> It has been estimated by various studies that dark space accounts
> >> for upwards of 15% of Internet traffic. Some one is routing this
> >> traffic - it has an Internet presence. 15% is not insignificant.
> >> Apparently people have found it useful to allocate to themselves
> >> whatever space they feel they need. In finding a way to have it
> >> routed, essentially provides them with a web presence that does not
> >> violate any ISP's APU, since they are not connected in the normal
> >> fashion.
> >>
> >> I submit that ATT is routing dark address space, nothing is being
> >> done about it, it is probably being treated as a cost of doing
> >> business, and ATT has been around for a very long time. I do not
> >> know the particulars in this specific instance, all I can do is look
> >> at the traceroute and the period of time this instance has been
> >> active and come to the obvious conclusions. What recourse does APNIC
> >> have in regaining control of their unallocated IP address that is
> >> currently being used?
> >> ATT is essentially providing value to the people using this dark
> >> address space, at the expense of everyone.
> >>
> >> It might be interesting to find out the following:
> >>
> >> - Through a random survey of unallocated APNIC addresses, how many
> >> are being used?
> >> - Who is routing them?
> >> - How did they become to be routed?
> >> - What process can be created to have the addresses returned to
> >> APNIC's control?
> >> - What can be done to prevent their routing in the first place?
> >>
> >> Regards,
> >> Gordon
> >>
> >>
> >> Jeff Williams wrote:
> >>
> >>> Phillip and all,
> >>>
> >>> I don't for a moment believe that many ISP's are going to implement
> >>> any routing policy they did not feel was in their customers best
> >>> interests
> >>> as well as had a hand in determining. If they do and it becomes known
> >>> they will not be in business very long.
> >>>
> >>> Philip Smith wrote:
> >>>
> >>>
> >>>
> >>>> Hi Izumi,
> >>>>
> >>>> At 16:02 10/08/2004 +0900, Izumi Okutani wrote:
> >>>>
> >>>>
> >>>>
> >>>>> I have one additional question, which may be more appropriate to ask
> >>>>> APNIC Secretariat - would NIRs be expected to implement the same
> >>>>> policy once this reaches consensus? I am asking this since we have
> >>>>> our
> >>>>> own policy making process within JP, and our process differs
> >>>>> depending
> >>>>> on what is expected on NIRs.
> >>>>>
> >>>> I think everyone has to implement this policy if it reaches
> >>>> consensus. It
> >>>> will only work if the RIRs & NIRs basically decide what the ISPs
> >>>> can and
> >>>> cannot route.
> >>>>
> >>>> And if it is approved in the AP region, it has to be approved in
> >>>> the other
> >>>> three RIR regions to have any impact at all; unless the proposed
> >>>> policy is
> >>>> intended to be binding on all routes the member ISPs provide
> >>>> transit to.
> >>>> Otherwise the miscreants which this policy proposal seeks to freeze
> >>>> out of
> >>>> the Internet will simply go outside of the region.
> >>>>
> >>>> As I see it, it will change the membership agreement each LIR has with
> >>>> APNIC, and the membership of the NIR have with the NIR. Basically
> >>>> giving
> >>>> the RIRs and NIRs internationally binding legal powers to influence
> >>>> their
> >>>> members' businesses. A pretty fundamental change in APNIC's existing
> >>>> address assignment policy, never mind uncharted waters for
> >>>> international
> >>>> law enforcement wrt the Internet. Which laws does APNIC as an
> >>>> Australian
> >>>> organisation use to stop an ISP in another country from "illegally
> >>>> announcing address space"? I'm no lawyer, but seeing the ICC being
> >>>> ignored
> >>>> by some countries doesn't give me much reason for optimism.
> >>>>
> >>>> philip
> >>>> --
> >>>>
> >>>>
> >>>>
> >>>>> Izumi
> >>>>> JPNIC
> >>>>>
> >>>>> From: APNIC Secretariat <secretariat@apnic.net>
> >>>>> Subject: [sig-policy] Forwarded reply from Gordon Bader
> >>>>> Date: Mon, 09 Aug 2004 10:16:57 +1000
> >>>>>
> >>>>>
> >>>>>
> >>>>>> The email below is forwarded to the list on behalf of Gordon
> >>>>>> Bader. He is
> >>>>>> now subscribed to the list.
> >>>>>>
> >>>>>> regards,
> >>>>>>
> >>>>>> APNIC Secretariat.
> >>>>>>
> >>>>>>
> >>>>>>
> >>>>>>> Date: Fri, 06 Aug 2004 07:15:16 -0700
> >>>>>>> From: GB <gbader@cox.net>
> >>>>>>> To: Izumi Okutani <izumi@nic.ad.jp>
> >>>>>>> CC: secretariat@apnic.net, sig-policy@apnic.net,
> >>>>>>>
> >>>>> sig-policy-chair@apnic.net
> >>>>>
> >>>>>
> >>>>>>> Subject: Re: [sig-policy] SIG Policy Proposal 'Preventing the
> >>>>>>> routing of
> >>>>>>> 'dark' address space
> >>>>>>>
> >>>>>>> Good Morning Mr. Okutani and APNIC Secretariat,
> >>>>>>>
> >>>>>>> Thank you for reading the proposal and your associated
> >>>>>>> questions on
> >>>>>>> the sig-policy proposal
> >>>>>>> 'Preventing the routing of 'dark' address space'. I have
> >>>>>>> responded in
> >>>>>>> line using the tag [Response]
> >>>>>>> below for each one of your concerns. I have also included an
> >>>>>>> example.
> >>>>>>>
> >>>>>>> Izumi Okutani wrote:
> >>>>>>>
> >>>>>>>
> >>>>>>>
> >>>>>>>> Dear Gordon/APNIC secretariat,
> >>>>>>>>
> >>>>>>>>
> >>>>>>>> I understand the issue you have raised, but I still can't quite
> >>>>>>>> understand your proposal.
> >>>>>>>>
> >>>>>>>> Could you please clarify what specific actions you expect APNIC
> >>>>>>>> and
> >>>>>>>> possibily, the community members to take?
> >>>>>>>>
> >>>>>>>> I've also added my comments inline.
> >>>>>>>>
> >>>>>>>> From: APNIC Secretariat <secretariat@apnic.net>
> >>>>>>>> Subject: [sig-policy] SIG Policy Proposal 'Preventing the
> >>>>>>>> routing of
> >>>>>>>>
> >>>>>>> 'dark' address
> >>>>>>> space
> >>>>>>>
> >>>>>>>
> >>>>>>>> Date: Wed, 04 Aug 2004 17:39:27 +1000
> >>>>>>>>
> >>>>>>>>
> >>>>>>>>
> >>>>>>>>
> >>>>>>>>
> >>>>>>>>> This proposal is being sent to the mailing list on behalf of
> >>>>>>>>> Gordon
> >>>>>>>>>
> >>>>> Bader
> >>>>>
> >>>>>
> >>>>>>>>> <gbader@cox.net>. Feedback and comments about this proposal are
> >>>>>>>>>
> >>>>> welcome on
> >>>>>
> >>>>>
> >>>>>>>>> this mailing list.
> >>>>>>>>>
> >>>>>>>>> regards,
> >>>>>>>>> APNIC Secretariat.
> >>>>>>>>> ---
> >>>>>>>>>
> >>>>>>>>>
> >>>>>>>>> ______________________________________________________________________
> >>>>>>>>>
> >>>>>>>>>
> >>>>>>>>> prop-023-v001: A proposal to prevent the routing of "dark"
> >>>>>>>>> address
> >>>>>>>>> space
> >>>>>>>>> ______________________________________________________________________
> >>>>>>>>>
> >>>>>>>>>
> >>>>>>>>>
> >>>>>>>>> Proposed by: Gordon Bader
> >>>>>>>>> <gbader@cox.net>
> >>>>>>>>> Version: 1.0
> >>>>>>>>> Date: 4 August 2004
> >>>>>>>>>
> >>>>>>>>>
> >>>>>>>>> Introduction:
> >>>>>>>>>
> >>>>>>>>> "Dark" address space is unallocated IP address space. Bandwidth
> >>>>>>>>> originating from "dark" address space should not be routed at any
> >>>>>>>>>
> >>>>> level.
> >>>>>
> >>>>>
> >>>>>>>>> Summary:
> >>>>>>>>>
> >>>>>>>>> Bandwidth originating from unallocated IP address space is being
> >>>>>>>>> used for SPAM. In addition, unallocated IP address space is being
> >>>>>>>>> used to host websites that support SPAM.
> >>>>>>>>>
> >>>>>>>>> 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.
> >>>>>>>>>
> >>>>>>>>> Details:
> >>>>>>>>>
> >>>>>>>>> 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.
> >>>>>>>>>
> >>>>>>>>>
> >>>>>>>>>
> >>>>>>>> Are you proposing ISPs in the community to apply the above
> >>>>>>>> policy, or
> >>>>>>>> is this simply an explanation of something which should be
> >>>>>>>> done, and
> >>>>>>>> not a part of the proposal?
> >>>>>>>>
> >>>>>>>> If it's the first, I think it is out of scope of the address
> >>>>>>>> policy.
> >>>>>>>>
> >>>>>>>>
> >>>>>>> [Response] - Yes, I am essentially proposing the first at ALL
> >>>>>>> levels of
> >>>>>>> routing. I do understand that
> >>>>>>> this would be larger than APNIC's reach and would need to be
> >>>>>>> applied
> >>>>>>> Internet wide. I am proposing
> >>>>>>> this be applied to ALL who receive their IP address allocations
> >>>>>>> from
> >>>>>>> APNIC directly or indirectly.
> >>>>>>> Included within the proposal are the Tier 1 backbone providers
> >>>>>>> as well
> >>>>>>> as individual ISP. I have
> >>>>>>> attached an example of what I am proposing below.
> >>>>>>>
> >>>>>>> However I do believe that it would be within APNIC's address policy
> >>>>>>> because if APNIC
> >>>>>>> was able to initially assign the IP address space to begin with,
> >>>>>>> APNIC
> >>>>>>> should be able to
> >>>>>>> remove the address space it originally assigned.
> >>>>>>>
> >>>>>>>
> >>>>>>>
> >>>>>>>>
> >>>>>>>>
> >>>>>>>>
> >>>>>>>>> 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.
> >>>>>>>>>
> >>>>>>>>>
> >>>>>>>>>
> >>>>>>>> If the offending entities are using unallocated address blocks,
> >>>>>>>> I'm
> >>>>>>>> not sure what you mean by "removal". Would there be anything to
> >>>>>>>> remove
> >>>>>>>> if allocations were not made in the first place?
> >>>>>>>>
> >>>>>>>> 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.
> >>>>>>>>
> >>>>>>>>
> >>>>>>> [Response] - The proposal I have submitted proposes the loss of IP
> >>>>>>> address space at the point
> >>>>>>> where routing "drops off" in to "dark space". Let me provide
> >>>>>>> an actual
> >>>>>>> traceroute. As of a couple
> >>>>>>> of minutes ago, node 19 222.233.52.27 was still active. That is
> >>>>>>> 6 days
> >>>>>>> after this traceroute was
> >>>>>>> taken.
> >>>>>>>
> >>>>>>> I received an "Failure to Delivery Notice" for an email that I
> >>>>>>> had not
> >>>>>>> sent, that was a item of SPAM
> >>>>>>> that directed the reader to the IP address 222.233.52.27.
> >>>>>>>
> >>>>>>> ===============
> >>>>>>> 07/31/04 16:12:27 Fast traceroute 222.233.52.27
> >>>>>>> Trace 222.233.52.27 ...
> >>>>>>> 1 10.84.224.1 12ms 13ms 17ms TTL: 0 (No rDNS)
> >>>>>>> 2 68.2.4.73 11ms 13ms 13ms TTL: 0
> >>>>>>> (ip68-2-4-73.ph.ph.cox.net ok)
> >>>>>>> 3 68.2.0.37 14ms 11ms 12ms TTL: 0
> >>>>>>> (ip68-2-0-37.ph.ph.cox.net ok)
> >>>>>>> 4 68.2.0.113 12ms 14ms 15ms TTL: 0
> >>>>>>> (ip68-2-0-113.ph.ph.cox.net ok)
> >>>>>>> 5 68.2.14.13 14ms 16ms 14ms TTL: 0
> >>>>>>> (chnddsrc02-gew0303.rd.ph.cox.net ok)
> >>>>>>> 6 68.1.0.168 14ms 15ms 13ms TTL: 0
> >>>>>>> (chndbbrc02-pos0101.rd.ph.cox.net ok)
> >>>>>>> 7 64.154.128.29 17ms 15ms 16ms TTL: 0
> >>>>>>> (p1-0.hsa1.phx1.bbnplanet.net ok)
> >>>>>>> 8 4.68.113.253 14ms 17ms 23ms TTL: 0
> >>>>>>> (so-6-2-0.mp2.Phoenix1.Level3.net ok)
> >>>>>>> 9 64.159.1.30 25ms 25ms 22ms TTL: 0
> >>>>>>> (as-0-0.bbr1.LosAngeles1.Level3.net ok)
> >>>>>>> 10 209.247.9.214 28ms * 25ms TTL: 0
> >>>>>>> (so-7-0-0.gar1.LosAngeles1.Level3.net ok)
> >>>>>>> 11 4.68.127.134 25ms 25ms 31ms TTL: 0
> >>>>>>> (att-level3-oc48.LosAngeles1.Level3.net ok)
> >>>>>>> 12 12.123.29.2 28ms 27ms 23ms TTL: 0
> >>>>>>> (tbr1-p014001.la2ca.ip.att.net probable bogus rDNS: No DNS)
> >>>>>>> 13 12.123.199.185 25ms 23ms 26ms TTL: 0 (No rDNS)
> >>>>>>> 14 12.119.138.38 25ms 25ms 24ms TTL: 0 (No rDNS)
> >>>>>>> 15 210.180.97.21 181ms 105ms 161ms TTL: 0 (No rDNS)
> >>>>>>> 16 211.108.90.2 107ms 162ms 140ms TTL: 0 (No rDNS)
> >>>>>>> 17 211.108.63.138 145ms 171ms 146ms TTL: 0 (No rDNS)
> >>>>>>> 18 221.139.106.66 130ms 146ms 145ms TTL: 0 (No rDNS)
> >>>>>>> 19 222.233.52.27 141ms 145ms 94ms TTL: 49 (No rDNS)
> >>>>>>> =================
> >>>>>>>
> >>>>>>> You will notice that starting with node 15 the address space is un
> >>>>>>> allocated. Thus the last
> >>>>>>> legal space rests with node 14 which now has a problem with their
> >>>>>>> routing tables.
> >>>>>>> I am proposing that notification be given (in this case) to
> >>>>>>> 12.119.138.38 "holder" to repair their
> >>>>>>> routing tables. If not acted upon within a reasonable period of
> >>>>>>> time
> >>>>>>> and possibly a number
> >>>>>>> of similiar instances, then the "holder" of the 12.0.0.0 -
> >>>>>>> 12.255.255.255 address space loose
> >>>>>>> their IP assignment. Yes, I am proposing that in this example, the
> >>>>>>> POSSIBLY that after 7 days of
> >>>>>>> inaction after being notified, AT&T WorldNet Services would
> >>>>>>> loose their
> >>>>>>> IP allocation,
> >>>>>>> if they received their IP allocation from APNIC. In this case
> >>>>>>> they did
> >>>>>>> not, and that is why I
> >>>>>>> do understand that this would need to be adopted Internet wide.
> >>>>>>> I am
> >>>>>>> also interested to see how
> >>>>>>> long 222.233.52.27 remains active after this email is sent.
> >>>>>>>
> >>>>>>> How might this work. There are a number of SPAM services that
> >>>>>>> receive
> >>>>>>> spam from their users.
> >>>>>>> They parse the spam extracting the possible originating IP
> >>>>>>> addresses of
> >>>>>>> the spam, AND the IP addresses
> >>>>>>> the SPAM is directing the reader to. I am proposing to take the
> >>>>>>> extracted address the SPAM reader
> >>>>>>> is sent to, traceroute it, determine the last legal IP address
> >>>>>>> on the
> >>>>>>> route and send an automated
> >>>>>>> notification to that service provider, whom ever that may be.
> >>>>>>>
> >>>>>>> With respect to the question of "removal" of IP address space, I
> >>>>>>> would
> >>>>>>> propose the logical loss
> >>>>>>> of routing to the IP address space in question.
> >>>>>>>
> >>>>>>> I hope I have answered your questions.
> >>>>>>>
> >>>>>>> Thank you very much,
> >>>>>>> Gordon
> >>>>>>>
> >>>>>>>
> >>>>>>>
> >>>>>>>> Izumi
> >>>>>>>> JPNIC
> >>>>>>>>
> >>>>>>>>
> >>>>>>>>
> >>>>>>>>
> >>>>>>>>
> >>>>>>>>
> >>>>>>>>> Pros/Cons:
> >>>>>>>>>
> >>>>>>>>> Pros:
> >>>>>>>>> By adopting this policy, bandwidth utilization will be reduced.
> >>>>>>>>>
> >>>>>>> Criminal
> >>>>>>>
> >>>>>>>
> >>>>>>>>> enterprises will no longer be served.
> >>>>>>>>>
> >>>>>>>>> Cons:
> >>>>>>>>> Disadvantages include new routing tables of increasing complexity
> >>>>>>>>> to handle the non routing issues associated with dark address
> >>>>>>>>> space
> >>>>>>>>> activities and the associated traffic generated.
> >>>>>>>>>
> >>>>>>>>> Effect on APNIC:
> >>>>>>>>>
> >>>>>>>>> Reduction in bandwidth handled and in it's associated rate of
> >>>>>>>>> growth.
> >>>>>>>>>
> >>>>>>>>> * 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
> >>>>>>>>>
> >>>>>>>>>
> >>>>>>>>>
> >>>>>>>>>
> >>>>>>>>>
> >>>>>>>>
> >>>>>>>>
> >>>>>>>>
> >>>>>>>
> >>>>>>> ______________________________________________________________________
> >>>>>>>
> >>>>>>>
> >>>>>>> Samantha Dickinson, Technical Editor <sam@apnic.net>
> >>>>>>> Asia Pacific Network Information Centre ph +61 7
> >>>>>>> 3858 3100
> >>>>>>> http://www.apnic.net fx +61 7 3858
> >>>>>>> 3199
> >>>>>>> ______________________________________________________________________
> >>>>>>>
> >>>>>>>
> >>>>>> * 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
> >>>>>
> >>>> * 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
> >>>>
> >>>
> >>> Regards,
> >>>
> >>> --
> >>> Jeffrey A. Williams
> >>> Spokesman for INEGroup LLA. - (Over 134k members/stakeholders strong!)
> >>> "Be precise in the use of words and expect precision from others" -
> >>> Pierre Abelard
> >>>
> >>> "If the probability be called P; the injury, L; and the burden, B;
> >>> liability depends upon whether B is less than L multiplied by
> >>> P: i.e., whether B is less than PL."
> >>> United States v. Carroll Towing (159 F.2d 169 [2d Cir. 1947]
> >>> ===============================================================
> >>> Updated 1/26/04
> >>> CSO/DIR. Internet Network Eng. SR. Eng. Network data security
> >>> IDNS. div. of Information Network Eng. INEG. INC.
> >>> E-Mail jwkckid1@ix.netcom.com
> >>> Registered Email addr with the USPS
> >>> Contact Number: 214-244-4827
> >>>
> >>>
> >>> * 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
> >
> >
> >
>
