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

Re: [address-policy-wg] Policy proposal: #alpha: TLD Anycast Allocation Policy
by Wilfried Woeber, UniVie/ACOnet 25 Mar '05

25 Mar '05

>If even they don't push their routers hard, then even with phenomenal growth >over the next 5 years or so then what ever the current routers are then will >probably be able to cope. >If the routers can cope then the size of the routing table becomes a non issue >- that's what I'm trying to say. Looking at the fact that for a couple of years already the majority no longer cares (or even reads? much less acts on) the weekly routing table reports suggests that you are right. >Jon Wilfried.

1 0

Re: [address-policy-wg] Policy proposal: #alpha: TLD Anycast Allocation Policy
by Wilfried Woeber, UniVie/ACOnet 24 Mar '05

24 Mar '05

>personally, i have no answer. We seem to be coming to the bottom of the pit :-) > sorry to make you read all this rubbish to find that. Fine with me. > why not show a bit of wimsey and block out >42 /32 chunks for this and have a three month bidding period to see >how much money the rirs can collect to donate to heal some of the >horrifying wounds of the latest natural disaster or unnatural us >imperialism? Aah, so this time at least we don't want to raise money for poor routers, but for victims of some sort of disaster or another. And why 42? (other than being "this" universal number) Wouldn't we be able to raise more money if we would give away more prefixes ;-) Or maybe just 32 x /32? Funny times, Wilfried.

2 1

Re: [address-policy-wg] Policy proposal: #alpha: TLD Anycast Allocation Policy
by Joao Damas 24 Mar '05

24 Mar '05

OK, so I guess my point altogether is that I dislike special-ness. There seems to be agreement that DNS anycasting is here to stay so the only point of contention is the size of the prefix. Using longer prefixes does not add much to the conservation and introduces more exceptions. Even if other RIRs are doing /48s already why would introducing an additional chunk of swamp space with the potential for more likely large scale failure be of any benefit? If people agree with assigning the addresses for this purpose, which seems to be the case, just issue a standard allocation and be done. Regarding the issue of flap damp(en)ing parameters, I think we should really revisit the flap damp(en)ing recommendations again at RIPE 50. Joao PS: regarding entries in the routing table and the pollution it causes, keep an eye on RFCs coming soon. PS: regarding the use of "wrong DNS software", the TLD operator is running *SERVERS* and providing services to resolvers/users. The best they can do is provide as good a service as they can to their consumers, not preach to them about them running the wrong client side software.

3 7

Re: [address-policy-wg] Policy proposal: #alpha: TLD Anycast Allocation Policy
by Wilfried Woeber, UniVie/ACOnet 24 Mar '05

24 Mar '05

>I would also be very happy if RIPE would charge enough money to people >wanting to do this to make them consider whether they really need it. ...this is just a fuzzy wording for: "Make the RIRs sell address space at different (and maximum) premiums, depending on how dearly the applicant needs the addresses at that particular point in time." I would not support such a proposal. Wilfried.

2 1

Re: [address-policy-wg] Policy proposal: #alpha: TLD Anycast Allocation Policy
by Wilfried Woeber, UniVie/ACOnet 23 Mar '05

23 Mar '05

Kurtis, >> Howeverm, the "out of a single block" is the part that really bothers >> me. Putting supposedly "critical infrastructure" as it is called >> elsewhere in a block that makes them all share fate in the event of >> network "optimisations" is still a bad idea. > >Well, this can be argued the otherway around as well. We know that ISPs >filter out previously unused space, and that they are not very active >in updating those filters when IANA starts allocating out of new >blocks. Having all in well-known block would limit that. ...wouldn't we/you/they/all have to do some filtering the "other way 'round" if all of those prefixes are contained in _one_ superblock to guard against someone/something announcing (and potentially black- holeing(sp?)) a route for that /32? >- - kurtis - Wilfried.

2 1

Registration Policy
by Thomas Thorne 11 Mar '05

11 Mar '05

To Whom It May Concern: How does a company or individual "own" the .biz, .info or similar URL suffix? Is it possible to register a new one? If so, at what cost? And do you allow someone to then own and profit from it? Thank you, Tom Thorne __________________________________ Do you Yahoo!? Take Yahoo! Mail with you! Get it on your mobile phone. http://mobile.yahoo.com/maildemo

3 2

Status of open actions
by Hans Petter Holen 04 Mar '05

04 Mar '05

Dear all, the next RIPE meeting is approaching in a couple months - It is time to review the action list. I have added the status as far as I know. http://www.ripe.net/ripe/wg/address-policy/action-list.html 47.3 Andreas Bäß Anycast for ccTLD: Complete discussion through Mailing List to draft formal proposal. Ongoing - published as policy proposal #alpha 47.4 Chair AfriNIC proposal for /22 minimum allocation size: Seek final consensus through the Mailing List. completed 47.5 Chair Changing the 80% rule for IPv4 allocations: Start discussion through the Mailing List. 48.1 Chair HD Ratio for IPv4: Take discussion to the mailing list policy proposal #beta 48.2 Chair Issues seen in IPv6 Allocation requests: circulate input on the mailing list. 48.3 NCC Issues seen in IPv6 Allocation requests: Propose re-write following mailing list discussion. 49.1 Andy Furnel Draft formal proposal on removing the 200 customer requirements for IPv6 49.2 Rob Blokzijl Publish draft Policy Development process published http://www.ripe.net/ripe/maillists/archives/ripe-list/2004/msg00058.html 22 Dec 2004 49.3 Working Group Continue discussion on the list of the IANA-RIR IPv6 policy 49.4 Eva Ericsson-Rabete Take discussion on Whois to the list 49.5 Alain Bidron Make a formal proposal on use of HD ratio for IPv4 policy proposal #beta

1 0

Beta test of new PDP
by Hans Petter Holen 04 Mar '05

04 Mar '05

As the new policy process proposed by Rob http://www.ripe.net/ripe/maillists/archives/ripe-list/2004/msg00058.html has not been finalized yet I have deceided to "beta test" the new process on new proposals received after today. The new process is a bit more structured that the previous one, and the previous one is open enough in its definition to fit the new one in this framework. Until the new process is approved and fully implmenented I'll maintain the list of proposals myself. Please let me know if you have any concerns with this approach Best Regards, Hans Petter Holen Address POlicy WG Chair

1 0

New AS Number Block allocated to the RIPE NCC
by Filiz Yilmaz 03 Mar '05

03 Mar '05

Dear Colleagues, The RIPE NCC received the AS Number Block 34816 - 35839 from the IANA in February 2005. You may want to update your records accordingly. Kind regards, -- Filiz Yilmaz RIPE NCC

1 0

Re: [address-policy-wg] IPv6 access to K-root
by Tim Streater 02 Mar '05

02 Mar '05

On Fri, 25 Feb 2005 21:00:05 +0100, Jeroen Massar wrote: >If you say they are lying, then complain to RIPE NCC that they are doing >their jobs wrongly. Apparently everybody who has gotten an allocation up >to now have been able to reason that they need the allocation under the >current policies. If you are not able to do so, though luck, you most >likely don't need it in the first place then. Sure they lie. I went on a BGP course a couple of years ago, and the instructor said that in his experience most people did because that's the only way to get what you need from RIPE. Current policies certainly don't fit us, for example. Looking in ripe-267, I see that in 5.1.1 there are four criteria for getting v6 space: 1) be an LIR - OK fine, we're an LIR. 2) not be an End Site - OK we're not. 3) plan to provide IPv6 connectivity to organisations - yes, we will certainly do that - to which it will assign /48s etc etc - no, we will never do that as all our customers are LIRs. 4) have a plan for making at least 200 /48 assignments to other organisations etc etc - no, we will never assign such space as all our customers have their own already. We manage one network (GEANT) for which we have a /32. There is another network (EUMEDCONNECT) which we manage at present, but in two years we are expecting that the connected NRENs will set up their own managing entity, and the infrastructure (including address space) will be handed over to them. I managed to get PI v4 space last year for this but it seems there is no such thing as PI v6 space so unless I fib and say that we have connected 50k end users to GEANT, I don't see how I can obtain separate, routeable v6 space for EUMEDCONNECT. We're an LIR, and an ISP, but we don't fit into the nice hierarchical tree that everyone assumes exists. For v4 we have an essentially similar problem. When GEANT's predecessor network, TEN-155, was being replaced we had to argue with RIPE about getting another /21 for GEANT. Well, now we have handed back the old /21 that we used for TEN-155. But the process should be easier than that. In short, I would advocate relaxing the rules about PI space. -- Tim

10 15

Re: [ipv6-wg@ripe.net] IPv6 access to K-root
by Iljitsch van Beijnum 02 Mar '05

02 Mar '05

On 2-aug-04, at 19:42, Andrei Robachevsky wrote: > K-root server has now IPv6 transport enabled. > k.root-servers.net. AAAA 2001:7fd::1 > A 193.0.14.129 > This information is also available from www.root-servers.org webiste. Since the ARIN micro allocation policy creates some problems, I was curious what kind of address space RIPE uses for k-root. A /32 "macro allocation", it turns out: inet6num: 2001:07FD::/32 netname: K-rootserver-net-20030829 descr: This assignment given to k-root.server.net I believe this ASSIGNment is in violation of existing IPv6 ALLOCATION policies. I would be very interested in learning any information to the contrary. Iljitsch van Beijnum

14 70

Re: [address-policy-wg] Re: [ipv6-wg@ripe.net] IPv6 access to K-root
by Iljitsch van Beijnum 28 Feb '05

28 Feb '05

On 28-feb-05, at 9:45, Marco Davids (SARA) wrote: >> There is no special case policy for (unicast) ccTLD name servers, for >> major search engines, big software vendor download sites, etc. -> find >> an upstream provider, get an IPv6 address block, and enter that in the >> relevant DNS zones. >> Of course the underlying question returns to "how to do IPv6 >> multihoming >> for A Special End Site". > I think gTLD's and ccTLD's would certainly qualify for their own IPv6 > space (for the purpose of being able to do proper multihoming). I strongly disagree. The DNS protocol has its own built-in redundancy, and changing addresses for TLD servers is not prohibitively difficult. So I see no reason why they should have PI addresses, especially since there is a significant number of TLDs and they all use several addresses. If those addresses would all become PI this would probably double the IPv6 routing table size at this point. (Granted, it's very small now, but still.) If TLD servers are anycast that _could_ be a reason for giving them PI space, but I think the TLD community first has to come up with coordinated plan for this, rather than just start giving out PI blocks and play "voldongen feit" game. (Sorry, it's monday morning, can't think of the English translation. In French it's "fait accompli".)

1 0

Re: [ipv6-wg@ripe.net] IPv6 access to K-root
by Wilfried Woeber, UniVie/ACOnet 25 Feb '05

25 Feb '05

>At the time the policy was written, people thought that this way would >be better. On the subject of root servers, people tend to be conservative. ...and I think this is a very reasonable approch. >OTOH, no policy that can't be changed if people think otherwise today. Yes, this is what we have this forum for. <AC hat on> Otoh, I think we (the community, not the registry) should take care of providing some stability in address distribution policy. Starting to play "channel hopping" on the management plane is not going to be funny for those who provide these services for us. </AC hat on> Let me add that I think the same holds true by and large for ccTLD operators... >Gert Doering > -- NetMaster Wilfried.

1 0

Re: [address-policy-wg] IPv6 access to K-root
by Wilfried Woeber, UniVie/ACOnet 25 Feb '05

25 Feb '05

>As I said above, the roots are a special case - end of story - we cannot live >without them (slight exaggeration). Why can't a /48 be set a side for the >root servers in each region (or even a global /32). 1st answer that springs to my mind: SPOF. >Jon DoSing the whole gang would only require me to break or target 1 prefix... Wilfried.

1 0

New Document available: RIPE-343
by RIPE NCC Document Announcement Service 23 Feb '05

23 Feb '05

[apologies for duplicate e-mails] New RIPE Document Announcement -------------------------------------- A revised document is available from the RIPE document store. Ref: ripe-343 Title: IPv6 Address Space Management Author: Paul Wilson, Raymond Plzak, Axel Pawlik Date: 22 February 2005 Format: PS=53986 TXT=13567 Obsoletes: ripe-261 Short content description ------------------------- This document provides the management process for IPv6 global unicast address space whereby address allocations are made from a single global pool according to a "sparse allocation" algorithm. In this version, previously published as ripe-261, we fixed an error in the 6-bit address space table. Accessing the RIPE document store --------------------------------- You can access the RIPE documents in HTML format via our website at the following URL:. http://www.ripe.net/docs/ipv6-sparse.html The RIPE Document Store is also available via anonymous FTP to ftp.ripe.net, in the directory ripe/docs. The URLs for the new documents on the FTP-server are: ftp://ftp.ripe.net/ripe/docs/ripe-343.pdf PDF version ftp://ftp.ripe.net/ripe/docs/ripe-343.txt plain text version Kind Regards, RIPE NCC Document Announcement Service

3 2

IPv4 assignment to resident user
by Jaka Erjavec 07 Feb '05

07 Feb '05

Dear colleagues, I was searching www.ripe.net website for a document where it says that IPv4 block can NOT be allocated to resident user (not company). Can you, guys, please point me to appropriate url? Thank you! Jaka

6 8

[Fwd: [apops] APNIC new IPv4 addresses]
by leo vegoda 07 Feb '05

07 Feb '05

Dear Colleagues, I'm forwarding this announcement, on request. Kind regards, -- leo vegoda RIPE NCC Registration Services Manager

1 0

Call for Comments on the WGIG Draft Working Papers
by Axel Pawlik 04 Feb '05

04 Feb '05

>Dear Colleagues, > >As you may be aware the <http://www.itu.int/wsis/>World Summit on the >Information Society (WSIS) requested the United Nations Secretary-General >to establish a Working Group on Internet Governance (WGIG). > >A series of 'draft working papers' prepared by WGIG members can be found at: > >http://www.wgig.org/working-papers.html > >A template to submit comments on the draft papers can be found at: > >http://www.wgig.org/docs/comment-template.doc > >As stated on the WGIG website: > >"Governments and all stakeholders are invited to comment on these papers, >preferably by making use of this template. Due consideration will be given >to all comments, but use of the template will facilitate processing >feedback. All comments received from governments and WSIS accredited >entities by 11 February 1200 hours GMT will be posted on this website. >Comments by other entities or individuals will also be posted, provided >they are relevant to the issues under discussion." > >Regards, > >Axel Pawlik >Managing Director >RIPE NCC

1 0

Final call for comments on ICANN Strategic Plan 2004 - 2007
by Axel Pawlik 27 Jan '05

27 Jan '05

Dear Colleagues, This is a reminder that the call for comments on the ICANN Strategic Plan will close on the 10 February 2005. The ICANN Strategic Plan is available as a draft for public comment at: http://www.icann.org/strategic-plan/strategic-plan-16nov04.pdf The Regional Internet Registries (RIRs) will gather comments on this document from each of their regional communities before making a joint statement through the Number Resource Organization (NRO) in February 2005. We encourage you to review the ICANN Strategic Plan document and send any comments you have to:<icann-plan(a)ripe.net>. An archive of comments sent to this mailing list will be available from: http://www.ripe.net/maillists/ncc-archives/icann-plan/ Please send your comments by 10 February 2005. Regards, Axel Pawlik Managing Director RIPE NCC

1 0

New IPv6 Address Block Allocated to RIPE NCC
by leo vegoda 17 Jan '05

17 Jan '05

Dear Colleagues, The RIPE NCC received the IPv6 address range 2003:0000::/18 from the IANA in January 2005. You may wish to adjust any filters you have in place accordingly. More information on the IP space administered by the RIPE NCC can be found on our web site at: <https://www.ripe.net/ripe/docs/smallest-alloc-sizes.html> Regards, -- leo vegoda Registration Services Manager RIPE NCC

3 2

LIR Camtel - Cameroon
by Local Internet Register 17 Jan '05

17 Jan '05

Hello, This is the LIR of Cameroon telecommunications (CAMTEL), There is an ISP which have a space address allocated to him by RIPE, at the beginning he was a customer of another ISP (LIR). Now this ISP is not fonctionnal and want to become our customer, conserving his address space. I want to know if it can be possible and how to do this. Best regards. TONYE, LIR Camtel - Cameroon. ------------- Fin message réacheminé ------------- ------------- Fin message réacheminé -------------

3 2

ISPs selling IP address space
by Pekka Savola 11 Jan '05

11 Jan '05

Hi, Let's assume an organization would qualify for e.g., /25 address allocation. When obtaining Internet connectivity, the ISP gives two offers, for example: - 100 EUR/mo for a /27 - 200 EUR/mo for a /25 (otherwise the terms are same, and the technical implementation is the same.) I recall this is not allowed. Are there any recourses in this kind situations? Threaten the ISP with LIR audit? ;-) The last RIPE document which seems to say that IP address must not be sold is RIPE-185 (AFAIR), which has been obsoleted -- the newer address policy documents seem to be quiet about this. RIPE-185 said: [under Publishing Local IR Policy] 2) Charging Policies A Local IR must publish its charging policy. The policy is defined in ripe-152 [Norris96a]: "Address space is a finite resource with no intrinsic value and direct costs cannot be ascribed to it. While they may not charge for address space as such, registries may charge for their administrative and technical ser- vices. Registries must publish their operating procedures and details of the services they offer and the conditions and terms that apply, including scales of tariffs if applicable." -- Pekka Savola "You each name yourselves king, yet the Netcore Oy kingdom bleeds." Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings

7 11

Announcement: Policy Development Process in RIPE
by Rob Blokzijl 22 Dec '04

22 Dec '04

To the RIPE Community, later today I will publish a draft document that describes the policy making process in RIPE. It is draft, so your input is requested in order to come to a generally accepted final document. Logistics: - deadline for comments on the first draft: 1 Februari 2005 - discussion takes place on ripe-list(a)ripe.net - if you are not subscribed to ripe-list(a)ripe.net yet, go to http://www.ripe.net/mailman/listinfo/ripe-list#subscribers - for any questions, don't hesitate to contact chair(a)ripe.net As always, apologies for receiving multiple copies of this announcement. Best regards, Rob Blokzijl RIPE Chairman

1 0

Re: [eix-wg] Announcement: Policy Development Process in RIPE
by Randy Bush 21 Dec '04

21 Dec '04

> later today I will publish a draft document that describes the policy > making process in RIPE. this is the product of the small working group on the subject? randy

1 0

RIPE NCC Appoints Wilfried Woeber as Interim ASO AC Member
by Axel Pawlik 16 Dec '04

16 Dec '04

Dear Colleagues, The RIPE NCC Executive Board has appointed Wilfried Woeber as an interim member of the Address Supporting Organization (ASO) Address Council for the RIPE NCC region. He will serve a one-year term beginning 1 January 2005. When this term has finished, the RIPE NCC Executive Board will appoint a person to the ASO Address Council for a full three-year term. This appointment is part of the transition of the Address Council as described in the Memorandum of Understanding (MoU) between the Internet Corporation for Assigned Names and Numbers (ICANN) and the Number Resource Organization (NRO). Full details of this MoU, signed by ICANN and the NRO in October 2004, are available at: http://www.nro.net/documents/aso-mou.html Regards, Axel Pawlik Managing Director RIPE NCC

1 0