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

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