- address-policy-wg - mailman.ripe.net

Correction: Call for Comments on Revised ICANN Strategic Plan
by Axel Pawlik 10 May '05

10 May '05

Dear Colleagues, Some of you may have noticed two URLs in our last announcement. The correct URL is: http://www.icann.org/strategic-plan/strategic-plan-v7_3.pdf Apologies for the confusion. Regards, Axel Pawlik Managing Director RIPE NCC

1 0

Call for Comments on Revised ICANN Strategic Plan
by Axel Pawlik 10 May '05

10 May '05

Dear Colleagues, The ICANN Strategic Plan has been revised. The comment period will be open until 13 May 2005 at 23:59 UTC. The revised Strategic Plan is available as a draft for public comment at: <http://www.icann.org/strategic-plan/strategic-plan-16nov04.pdf>http://www.icann.org/strategic-plan/strategic-plan-v7_3.pdf We encourage you to review the ICANN Strategic Plan document and send any comments you have to: <stratplan-revision(a)icann.org>. Regards, Axel Pawlik Managing Director RIPE NCC

1 0

infected e mails
by freeram 06 May '05

06 May '05

I receive infected e mails of these addresses is it possible to ascend has the author of its mails: or have I to address to send complaints thank you of well will to reply me Alain Bruneteau ---------------------------------------------------------------------------------------------------- 62.48.149.242 Return-Path: <info(a)sivaonline.pt> Delivered-To: online.fr-freeram(a)free.fr Received: (qmail 9962 invoked from network); 6 May 2005 10:41:25 -0000 Received: from adsl-62-48-149-242.ptprime.net (HELO tetfob.pt) (62.48.149.242) by mrelay2-2.free.fr with SMTP; 6 May 2005 10:41:25 -0000 From: info(a)sivaonline.pt To: Recipient(a)free.fr Date: Fri, 06 May 2005 09:52:45 UTC Subject: [avast! - INFECTED] Your email was blocked Importance: Normal X-Priority: 3 (Normal) Message-ID: <56cd.70f8e0dab9d7ee0(a)sivaonline.pt> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===79bce1635598.2ceab3bf964" Content-Transfer-Encoding: 7bit This is a multi-part message in MIME format. X-Antivirus: avast! (VPS 0518-4, 06/05/2005), Inbound message X-Antivirus-Status: Infected Attachment: \error-mail_info.zip#1997431942 Virus: Win32:Sober-N [Wrm] Deleted ------------------------------------------------------------------------------------------------- 82.64.236.212 X-x: TimeOut+OK 73580 octets Return-Path: <hostmaster(a)yahoo.fr> Delivered-To: online.fr-freeram(a)free.fr Received: (qmail 12725 invoked from network); 5 May 2005 06:17:15 -0000 Received: from lns-th2-15-poi-82-64-236-212.adsl.proxad.net (HELO butqay.fr) (82.64.236.212) by mrelay3-2.free.fr with SMTP; 5 May 2005 06:17:15 -0000 From: hostmaster(a)yahoo.fr To: mailhost(a)free.fr Date: Thu, 05 May 2005 06:09:40 UTC Subject: [avast! - INFECTED] mailing error Importance: Normal X-Priority: 3 (Normal) Message-ID: <74d8c001e683ef48(a)yahoo.fr> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="6653bc9b707531bc.8" Content-Transfer-Encoding: 7bit This is a multi-part message in MIME format. X-Antivirus: avast! (VPS 0518-3, 04/05/2005), Inbound message X-Antivirus-Status: Infected Attachment: \mail_info.zip#1997431942 Virus: Win32:Sober-N [Wrm] Deleted --------------------------------------------------------------------------------------------------- 82-64-238-162 Return-Path: <Admin(a)ac-corse.fr> Delivered-To: online.fr-freeram(a)free.fr Received: (qmail 17762 invoked from network); 4 May 2005 05:53:29 -0000 Received: from lns-th2-15-poi-82-64-238-162.adsl.proxad.net (HELO hnmuwxt.fr) (82.64.238.162) by mrelay1-2.free.fr with SMTP; 4 May 2005 05:53:29 -0000 From: Admin(a)ac-corse.fr To: fe2e2ec0(a)free.fr Date: Wed, 04 May 2005 05:45:09 GMT Subject: [avast! - INFECTED] mailing error Importance: Normal X-Priority: 3 (Normal) X-MSMail-Priority: Normal Message-ID: <db2da62ab.587e8a2c9(a)ac-corse.fr> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="=====8389c8.dea2bff67" Content-Transfer-Encoding: 7bit This is a multi-part message in MIME format. X-Antivirus: avast! (VPS 0518-2, 04/05/2005), Inbound message X-Antivirus-Status: Infected Attachment: \error-mail_info.zip#1997431942 Virus: Win32:Sober-N [Wrm] Deleted ---------------------------------------------------------------------------------------------------- 82.64.226.163 Return-Path: <service(a)ac-reims.fr> Delivered-To: online.fr-freeram(a)free.fr Received: (qmail 7819 invoked from network); 4 May 2005 23:00:38 -0000 Received: from lns-th2-15-poi-82-64-226-163.adsl.proxad.net (HELO osymwmxh.fr) (82.64.226.163) by mrelay2-1.free.fr with SMTP; 4 May 2005 23:00:38 -0000 From: service(a)ac-reims.fr To: oel(a)free.fr Date: Wed, 04 May 2005 23:00:06 GMT Subject: FwD: Registration Confirmation Importance: Normal X-Priority: 3 (Normal) X-MSMail-Priority: Normal Message-ID: <f24f8b.dc6bb7cddd(a)ac-reims.fr> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="==eb445d.b2cfb65" Content-Transfer-Encoding: 7bit This is a multi-part message in MIME format.

1 0

Revised Agenda v2 for Address Policy WG @ RIPE 50 Thursday 5th May
by Hans Petter Holen 05 May '05

05 May '05

Time: 1400- 15:30 Date: Tursday May 5th Place: Main room, RIPE 50 A. Administrative Matters - Welcome - Select a scribe - Distribute participants list - Finalise agenda - Approve minutes from RIPE 49: http://www.ripe.net/ripe/wg/address-policy/r49-minutes.html B. Policy overview - Regional policy overview -- presentation of the status of the current regional proposals under the "beta test of the PDP" -- status of the PDP and transition to the PDP --- PDP last call posted to ripe-list with closing date May 10th. C. Policy proposal: #alpha: TLD Anycast Allocation Policy Discussion phase until: May 6th D. Policy proposal: #beta: IPv4-HD-Ratio Discussion phase until: April 4th E. Policy proposal: #gamma: IPv6 remove 200 customer requirement Discussion phase until May: 9th F. Policy Proposal: #epsilon: Removal of Africa Special Policy Discussion phase until May: 1st G. Policy Proposal: #zeta: Adding Regional Boundaries to Policy Documents Discussion phase until May: 1st H. Discussion: (IPv6) HD ratio consequences (Geoff Huston: http://www.ripe.net/ripe/meetings/ripe-50/presentations/ripe50-plenary-wed-… There is also a related agenda item in the IPv6 WG on friday: http://www.ripe.net/ripe/maillists/archives/ipv6-wg/2005/msg00042.html " D. Revisiting the /48 recommendation (Thomas Narten) Discussion, read rfc3177 as preparation ftp://ftp.rfc-editor.org/in-notes/rfc3177.txt" J. Report from the Address Council - Hans Petter Holen K. Any other Business

1 1

New Draft Document: RIPE Whois Registration in 2005: What should be in Whois and Why?
by leo vegoda 02 May '05

02 May '05

Dear Colleagues, At RIPE 49, Eva Ericsson Rabete (TeliaSonera) made a presentation to the Address Policy Working Group in which she asked some questions about the state of the RIPE Whois Database. Following the discussion at the meeting, Eva was asked to take the discussion onto this list (Action Point 49.4). A draft document discussing the uses of the RIPE Whois Database, and detailing questions to consider, has been published in the "Latest Draft Documents" section of the RIPE Document Store. The purpose of this draft document is to encourage discussion about what elements should be in the Whois Database and why they should be there. This draft document is available at: http://www.ripe.net/ripe/draft-documents/whois2005.html Regards, -- leo vegoda Registration Services Manager RIPE NCC

2 1

Summary TLD Anycast Allocation Policy
by Patrick Arkley 28 Apr '05

28 Apr '05

Hi WG. We at MCI are requesting a /24 PI-range to use for an anycast service (DNS) but the request has been rejected in accordance to the current assignment policy. We need PI-space belonging to a separate AS so we can't use existing MCI space. The need for this range is if course routing reasons which is prohibited by the policy. I've been reading Andreas Baess e-mail on this issue and I hope this issue will be addressed on the RIPE 50 and rule in favour of changing the policy. I don't judge on the routability aspects but more on the fact that we need a change in the policy to accomodate a setup for anycast services. Myself I can't attend the WG meeting on Thursday 5/5 due to other engagements so this e-mail is my support for the proposal. Best regards Patrick Arkley Supervisor IP/DNS-team SKSC/SKRC MCI - Powered by UUNET Armégatan 38 S-171 04 Solna, Sweden Web: www.se.mci.com <http://www.se.mci.com/> Phone direct: +46 (0)8 5661 7075 Fax: +46 (0)8 5661 7236 Mobile: +46 (0)733 11 20 75 VNET: 915-7075 E-mail: patrick.arkley(a)se.mci.com <mailto:patrick.arkley@se.mci.com>

1 0

Policy proposal: #beta: IPv4-HD-Ratio
by Guido Roeskens 28 Apr '05

28 Apr '05

Hello, we from Bluewin fully support the proposal Policy proposal: #beta: IPv4-HD-Ratio LIR: ch.bluewindow Vote: YES Comment: ISP's providing access services to many customers face several problems - Usage in different PoP's changes; at one time you have many customers in one PoP, at another time in others. You need to supply enough adresses to all PoPs even though they aren't needed all the time. - Assymetric usage of pools and redundancy To provide redundancy you overallocate some IP addresses to be able to handle the failure of single devices The pool usage on the devices and device groups are not balanced - RFC 3194 is as true for IPv4 as for IPv6 - consistency between IPv4 and IPv6 policies Kind regards, Guido Roeskens Swisscom Fixnet AG Bluewin

6 8

Mega-allocations
by Iljitsch van Beijnum 25 Apr '05

25 Apr '05

Hi, It seems there is a new trend in RIR-land: mega-allocations. This year APNIC, ARIN and the RIPE NCC have made the following allocations: # whois -h whois 126.0.0.0 whois.apnic.net inetnum: 126.0.0.0 - 126.255.255.255 netname: BBTEC descr: Japan Nation-wide Network of Softbank BB Corp. country: JP status: ALLOCATED PORTABLE # whois -h whois.arin.net 73.0.0.0 NetRange: 73.0.0.0 - 73.191.255.255 CIDR: 73.0.0.0/9, 73.128.0.0/10 NetName: CABLE-1 NetType: Direct Allocation # whois -h whois.ripe.net 86.192.0.0 inetnum: 86.192.0.0 - 86.255.255.255 netname: FR-TELECOM-20050302 descr: France Telecom status: ALLOCATED PA That's a total of 33 million IP addresses in 3 allocations (and as many months). The total population for these three countries is 127 + 293 + 60 = 480 million, so that's an IP address for nearly 7% of those country's inhabitants. If I were a conspiracy theorist I would think that IPv6 proponents are trying to burn up the remaining IPv4 space as fast as they can so we'll all be running IPv6 at the end of the decade. If that's the case: good job! :-) Seriously: what's going on here?

3 3

Re: [address-policy-wg] Policy proposal: #gamma IPv6 InitialAllocation Criteria
by Cameron Gray (RIPE Address Policy WG) 24 Apr '05

24 Apr '05

Collective, This originated from a thread I started on ipv6-ops... As the archives seem to bear out shim6/mhap/multi6 or whatever the new *thing* will be is not ready. We (uk.netegral) have a /32 already (2001:4bf0::) however many of the recipients of sub-allocations will be using the resources in conjunction with their other providers. My, now somewhat aging, e-mail to lir-help asked what happens to LIRs that cannot get/justify/plan for 200 /48s their reply was simple: get it off another LIR. This now leads into a problem with routing policies: if /32s are only to be allowed in the backbone, how doe these sub-lir allocations get announced. My idea is to simply allow internetwork /48 to be announced to the backbone, or aggregates thereof (i.e. to adjacent /48s for the same ASN as a /47 and so on...). I know the first response will be that this will grow the routing table infinitely and I agree, however with 629-ish from my view there isn't much of a table to speak of. Are there any considerations I'm missing, why can't IPv6 prefixes be treated in the same way as IPv4? I'm not advocating announcing every /64 from here to timbuktu but otherwise I can't see anything to allow the "little guys" from actually benefitting therefore deploying IPv6. One of our customers has a /48 allocation and is now refusing to issue to customers as he can't announce this to the second upstream (they refuse to pass it on as it isn't a /32), they have also hit peers that refused the prefix as it hit their "this route is internal" prefix filter. I assume the end goal here is to encourage the uptake of v6 not hinder it... Can this disparity in policies not be addressed using current protocols and technologies simply by increasing the allowable boundary for the backbone? This has a neat side effect of not having to alter the issuing policy for /32s :) .

6 10

Re: [address-policy-wg] Policy proposal: #gamma IPv6 InitialAllocation Criteria
by Gert Doering 23 Apr '05

23 Apr '05

Hi, On Thu, Apr 21, 2005 at 11:33:46PM +0100, Cameron Gray wrote: > First a little background, recently in the London Webhosting world, a > big drive has occured to become multi-homed and isolated from any one > providers screwups, downtime, incompetence, etc. The problem with this > is that very few of them have any of the necessary skills to liase with > the NCC to do requests or even understand why its necessary [tangent: > the number of times I see "because ARIN gave us a /24 per box" as a > justification from the same group is silly]. I firmly believe in > leaving the important things to those who know what they are doing, > present company (I hope ;)). > > The small providers can have either IPv6 PI (currently disallowed and > frowned upon) or become a LIR and wreak havoc on the hostmasters. This is something that I really don't understand. The hostmasters are here to help educate LIRs that don't know what they are doing - and it will be for the better of everyone. If they are so clueless, then they shouldn't be allowed to do BGP, and possible "wreak havoc" on everybody else's routing tables. > I'm against dishing out /32s to Joe Blogs because I believe the subnet > recommendation/guidelines as published are a good balance. In theory a > /48 for any customer site should be several orders of magnitude to many > for most customers in two years. > > But the ongoing problem is that of what should be allowed into the > public v6 Internet. Indeed. The idea behind the proposed change is (sort of) "those who can be bothered to understand the system and become a LIR are allowed". What you are asking for ("those people are clueless but so important that they need to be visible in everyones routing table") is a different proposal. Gert Doering -- NetMaster -- Total number of prefixes smaller than registry allocations: 71007 (66629) SpaceNet AG Mail: netmaster(a)Space.Net Joseph-Dollinger-Bogen 14 Tel : +49-89-32356-0 D- 80807 Muenchen Fax : +49-89-32356-234

4 3