June 2004 - address-policy-wg

IPv6 Policy Clarification - Initial allocation criteria "c)"
by Laura Cobley 19 Jul '05

19 Jul '05

Dear Colleagues, As explained in the email sent on Mon, 14 Jun 2004: http://www.ripe.net/ripe/mail-archives/address-policy-wg/2004/msg00240.html This is the second mail request for clarification of the IPv6 Address Allocation and Assignment Policy. Below is an excerpt from the IPv6 Address Allocation and Assignment Policy: 5.1.1. Initial allocation criteria "c)" "To qualify for an initial allocation of IPv6 address space, an organisation must [...] plan to provide IPv6 connectivity to organisations to which it will assign /48s by advertising that connectivity through its single aggregated address allocation" LIRs who operate closed/private networks appear not to qualify because the address space in these networks will not be advertised. Was this the community's intention? Best Regards, Laura Cobley Registration Services RIPE NCC

9 12

IPv6 Policy Clarification - Initial allocation criteria "d)"
by Laura Cobley 06 Jul '04

06 Jul '04

Dear Colleagues, We have received many comments that the text of the current IPv6 Allocation and Assignment Policy document can be difficult to read and understand. Some of these difficulties were presented at RIPE 48 by Leo Vegoda: http://www.ripe.net/ripe/meetings/ripe-48/presentations/ripe48-ap-ipv6-poli… During the following discussions, the RIPE NCC was asked to co-ordinate work on clarifying the text. Please note that we do not intend to propose any policy changes. In order to assist with rewriting the IPv6 Policy document, we would like to have some input from the community on the issues needing clarification. We will send each issue for discussion in a separate mail. This is the first of these mails. Below is an excerpt from the IPv6 Address Allocation and Assignment Policy: 5.1.1. Initial allocation criteria "d)" "To qualify for an initial allocation of IPv6 address space, an organisation must [...] have a plan for making at least 200 /48 assignments to other organisations within two years." 1. According to this criterion, LIRs who are operators planning to only make /64 assignments appear not to qualify. Was this the community's intention? 2. There are a number of interpretations of requirement "d)": - NUMBER OF ASSIGNMENTS -- The LIR has to have a plan to make at least 200 separate /48 assignments. Possible scenario: LIR must make 200 assignments and the size of each must be a /48. -- The LIR has to have a plan to make at least the equivalent of 200 /48 assignments. Possible scenario: LIR can assign one /41 and seventy-two /48s. Which interpretation was intended regarding the number of assignments? - RECIPIENT OF ASSIGNMENTS -- The LIR has to have a plan to make these 200 assignments to 200 separate organisations (regardless of which organisation). Possible scenario: LIR can make 1 assignment to its own organisation and 199 assignments to 199 "different" organisations. -- The LIR has to have a plan to make these 200 assignments to 200 separate organisations outside of its own infrastructure. Possible scenario: LIR must make 200 assignments to 200 "different" organisations. Assignments to its own organisation will not be counted. -- The LIR has to have a plan to make these assignments to 200 separate networks (regardless of which organisation these networks belong to). Possible scenario: LIR makes 200 assignments to 200 networks. 100 can be for its own infrastructure and 100 can be for another single organisation. -- The LIR has to have a plan to make these assignments to 200 separate networks outside of its own infrastructure. Possible scenario: LIR makes 200 assignments to 200 networks "outside of its own infrastructure". Which interpretation was intended regarding the recipient of assignments? We look forward to receiving the community's input on this. Best Regards, Laura Cobley Registration Services RIPE NCC

36 176

New AS Number Block allocated to RIPE NCC
by Filiz Yilmaz 30 Jun '04

30 Jun '04

Dear Colleagues, The RIPE NCC received the AS Number Block 33792 - 34815 from the IANA in June 2004. You may want to update your records accordingly. Kind regards, -- Filiz Yilmaz RIPE NCC

1 0

Reminder - RIPE NCC Regional Meeting, Nairobi, Kenya 28-30 July 2004
by Membership Liaison Officer 30 Jun '04

30 Jun '04

[Apologies for duplicate emails] Dear Colleague, We would like to remind you that the RIPE NCC Regional Meeting in Nairobi will be held 28 - 30 July 2004 at the Norfolk Hotel, Nairobi, Kenya. Attendance to the RIPE NCC Regional Meeting is open and free of charge. However, attendees are responsible to cover their own travel and accommodation costs. Conference attendees will include RIPE NCC members, industry partners, government representatives and regulators with particular interest in wide area IP networking. If your organisation wishes to provide a presentation or suggest a relevant topic, or if you have any questions, please send an email to: <contact(a)ripe.net> REGISTRATION To register, please see: http://www.ripe.net/cgi-bin/nairobi-reg Please note that registration closes on 19 July 2004. AGENDA The Regional Meeting draft agenda has been updated and can be found at: http://www.ripe.net/ripencc/regional-meetings/nairobi-2004/agenda.html Agenda points and discussion topics include: * AfriNIC - The emerging RIR; * Peering and Exchange Points; * Are we running out of IPv4 address space?; * An update on IPv6; * The industry self-regulatory open structures and processes used by the RIPE NCC and the global Internet community; * How to participate in and influence IP address management policy-making; * Domain Name management on the Internet; * Root Server Operations. MORE INFORMATION More information about the RIPE NCC Regional Meeting, Nairobi is available from: http://www.ripe.net/ripencc/regional-meetings/nairobi-2004/index.html I trust you will find the discussions and tutorials on Internet Resource allocation and management relevant to your work. Regards, Nathalie Dougall Membership Liaison Officer RIPE NCC http://www.ripe.net

1 0

Re: [address-policy-wg] IPv6 Policy Clarification - Initial allocation criteria "d)"
by David Kessens 29 Jun '04

29 Jun '04

Laura, On Mon, Jun 14, 2004 at 10:36:40AM +0200, Laura Cobley wrote: > > During the following discussions, the RIPE NCC was asked to co-ordinate > work on clarifying the text. Please note that we do not intend to > propose any policy changes. During the meeting, I asked you not to waste your time on this. Since the policy is already changing in the other regions, our time would be better spend to move forwards, instead of stalling the policy development process by spending time on 'clarifications'. I would like to ask the working group whether we can ask the RIPE NCC to summarize the different changes made to the policy in the other regions, so that we can have a discussion on which changes are appropriate. Thanks, David Kessens ---

7 7

Re: Fallacy by Kurt (was Re: IPv6 Policy Clarification - Initial allocation criteria "d)")
by Masataka Ohta 24 Jun '04

24 Jun '04

Jeff Williams wrote: > Open to some does not mean "all the way open" to others. So restrictions > for the sake of how far "Open" discussion is, is dependent sometimes on > whom is discussing what aspect of relevant issues on a topic area... So true. > That said, I liked your draft. I still must study it more however. Thank you. However, such statement without technical reasoning is no better than the emotional postings by Brian Carpenter. So, let's have discussions on technical points with verifiable reasons. Note, for example, that I oppose any proposal trying to import *THE* swamp of v4. Masataka Ohta

1 0

RE: [address-policy-wg] Re: Fallacy by Kurt
by Potapov Vladislav 24 Jun '04

24 Jun '04

>And, I happened to be a technologist who know how to build a >fast (Pbps or more) router even before no one have the needs. >So, the only problem on fast routers is their prices. >Limiting the number of global routing table entries helps a lot. Dear Masataka, It may help to optimize only ONE and not very IMPORTANT part of the router. You knew how to build fast (in mean of PPS OR MORE) routers, but didn't say about importance of the routing table. Please, give me an example of multigigabit routers without support of large routing table (or even switches, which don't have any routing table at all) which is cheaper than Cisco 2511 or so? The price of the multigigabit-per-second routers is high itself and not because of need to support routing tables. Please DO NOT turn fact. >So, you can still insist that my theory is incorrect and ATM is >8192 or more times faster than IP, while I can keep saying ATM >is about 10 times slower than IP with reasons. It seems that you have only your old theories in mind. Your previous heroic prophecies maid be right but it doesn't prove that your current prophecy is right, just because it IS prophecy without ANY facts in mind. Vladislav Potapov

1 0

IPv6 Policy - Initial Allocation Criteria in other regions
by Filiz Yilmaz 23 Jun '04

23 Jun '04

Dear Colleagues, As requested by the working group, please find below a summary of the variations in the Initial Allocation Criteria for IPv6 Policy from each of the other regions. For all regions, the following criteria apply: a) Requester must be an LIR b) Requester must not be an end site The other criteria vary. They are summarised below by region: ARIN region: Requesters must: c) plan to provide IPv6 connectivity to organisations to which it will assign /48s, by advertising that connectivity through its single aggregated address allocation; d) have a plan for making at least 200 /48 assignments to other organisations within two years. There is a policy proposal in last call review currently which states: - to change the timeframe above in 'd)' from "two years" to "five years" and - to have 'd)' prepended "be an existing, known ISP in the ARIN region or..." (http://www.arin.net/policy/2003_4.html) APNIC region: Requesters must: c) plan to provide IPv6 connectivity to organisations to which it will assign /48s, by advertising that connectivity through its single aggregated address allocation; d) have a plan for making at least 200 /48 assignments to other organisations within two years. In addition, APNIC will make allocations to closed networks if they meet all other criteria. LACNIC region: Requesters must: c) document a detailed plan for the services and IPv6 connectivity to be offered to other organisations (clients); d) announce a single block in the Internet inter-domain routing system, aggregating the total IPv6 address allocation received, within a period not longer than 12 months; e) offer IPv6 services to clients physically located within the region covered by LACNIC within a period not longer than 24 months. Regarding your comments on the RIR Comparative Policy Overview document, http://www.ripe.net/ripencc/mem-services/registration/rir-comp-matrix-rev.h… I realise that it is currently out of date. This document is currently being reviewed. I expect the document to be published in July. It will include the above points along with any other policy related matters. Kind regards, -- Filiz Yilmaz RIPE NCC

1 0

[ncc-co@ripe.net] ASO AC - Call for Nominations 2004 - RIPE NCC Service Region
by Paul Rendek 23 Jun '04

23 Jun '04

Call for Nominations: RIPE Representative to the ASO Address Council ___________________________________________________________ This is a call for nominations of individuals from the RIPE NCC service region to serve on the ASO Address Council. On 31 December 2004, one RIPE Address Council seat will become vacant and will be filled for the next three years by an individual nominated through this open call. The selection process will involve an open election to be held during the RIPE 49 Meeting in Manchester, UK, being held from 20 - 24 September 2004. * Deadline for nominations: Tuesday, 24 August 2004 * Election scheduled for: Thursday, 23 September 2004 For full details on the Address Council position and how to submit a nomination, please refer to: http://www.ripe.net/ripencc/about/regional/aso2004/ and http://www.ripe.net/ripe/wg/lir/adress_council-election.html The Number Resource Organization (NRO) and ICANN have signed a letter of intent to form a new ASO MoU, which is expected to finalised sometime in the next few months. Should this contract be signed prior to the selection for the Address Council seat, the process will be replaced by the new structure outlined in the NRO MoU. Best regards, Paul Rendek Head of Member Services and Communications RIPE NCC

1 0

[local-ir@ripe.net]ASO AC - Call for Nominations 2004 - RIPE NCC Service Region
by Paul Rendek 23 Jun '04

23 Jun '04

Call for Nominations: RIPE Representative to the ASO Address Council ___________________________________________________________ This is a call for nominations of individuals from the RIPE NCC service region to serve on the ASO Address Council. On 31 December 2004, one RIPE Address Council seat will become vacant and will be filled for the next three years by an individual nominated through this open call. The selection process will involve an open election to be held during the RIPE 49 Meeting in Manchester, UK, being held from 20 - 24 September 2004. * Deadline for nominations: Tuesday, 24 August 2004 * Election scheduled for: Thursday, 23 September 2004 For full details on the Address Council position and how to submit a nomination, please refer to: http://www.ripe.net/ripencc/about/regional/aso2004/ and http://www.ripe.net/ripe/wg/lir/adress_council-election.html The Number Resource Organization (NRO) and ICANN have signed a letter of intent to form a new ASO MoU, which is expected to finalised sometime in the next few months. Should this contract be signed prior to the selection for the Address Council seat, the process will be replaced by the new structure outlined in the NRO MoU. Best regards, Paul Rendek Head of Member Services and Communications RIPE NCC

1 0

ASO AC - Call for Nominations 2004 - RIPE NCC Service Region
by Paul Rendek 22 Jun '04

22 Jun '04

Call for Nominations: RIPE Representative to the ASO Address Council ___________________________________________________________ This is a call for nominations of individuals from the RIPE NCC service region to serve on the ASO Address Council. On 31 December 2004, one RIPE Address Council seat will become vacant and will be filled for the next three years by an individual nominated through this open call. The selection process will involve an open election to be held during the RIPE 49 Meeting in Manchester, UK, being held from 20 - 24 September 2004. * Deadline for nominations: Tuesday, 24 August 2004 * Election scheduled for: Thursday, 23 September 2004 For full details on the Address Council position and how to submit a nomination, please refer to: http://www.ripe.net/ripencc/about/regional/aso2004/ and http://www.ripe.net/ripe/wg/lir/adress_council-election.html The Number Resource Organization (NRO) and ICANN have signed a letter of intent to form a new ASO MoU, which is expected to finalised sometime in the next few months. Should this contract be signed prior to the selection for the Address Council seat, the process will be replaced by the new structure outlined in the NRO MoU. Best regards, Paul Rendek Head of Member Services and Communications RIPE NCC

1 0

Re: [address-policy-wg] IPv6 Policy Clarification - Initial allocation criteria "d)"
by Sascha Luck 22 Jun '04

22 Jun '04

Hi Carlos, all, On Tuesday 22 June 2004 12:16, Carlos Friacas wrote: > I cant really support the idea RIPE/NCC is a monopoly. It works in an > open and well-known fashion, cooperating with the community it > serves... > The real danger to internet governance is ICANN, and having Internet > Addressing and other stuff decisions depend on a US Government Department. I would also not much fancy if Internet governance/IP allocation policy/etc fell into the hands of the likes of the European Commission or such... rgds, Sascha Luck -- DDO Eirconnect

1 0

Fw: [GLOBAL-V6] [address-policy-wg] IPv6 Policy Clarification - Initial allocation criteria "d)" (fwd)
by Toshiyuki Hosaka 22 Jun '04

22 Jun '04

Dear all, Please allow me to forward global-ipv6 ML post by Kosuke Ito, who has not subscribed ripe-policy-wg ML. Also I would suggest you can ask original IPv6 policy intention to v6-edit team(v6-edit(a)ripe.net) that knows it very well, if you still need that. best regards, Toshi -- Toshiyuki Hosaka <hosaka(a)nic.ad.jp> IP Department, Japan Network Information Center (JPNIC) tel: +81-(0)3-5297-2311 fax: +81-(0)3-5297-2312

1 0

Re: [address-policy-wg] IPv6 Policy Clarification - Initial allocation criteria "d)"
by Sascha Luck 21 Jun '04

21 Jun '04

Hi Marcus, On Monday 21 June 2004 20:46, Marcus Gerdon wrote: > I had *no* trouble with the policy. > Currently (!) nobody asks for IPv6 directly, but those customers, > espicially bussiness customers, we offered routing ipv6 space to get them > accustomed to v6 were mostly quite happy with this service. And that > although they're informed it's still run in a test network (regarding our > infrastructure). We've actually been asked (with the understanding that it wasn't going to be a production rollout anytime soon. There is an actual drive towards ipv6 underway in Ireland - largely owing to heanet's efforts) > There's /16's spliit up to an endless number of /23,/24 ... Tkae a look at > Gert's email footer ... THAT's a problem. Not to say we're perfect - no > way. We ourselves have announced smaller prefixes out of space assigned to > other lir's each for many months only for customers UNWILLING to renumber > in appropriate time or to keep their old link long enough. Now this is hardly the fault of the allocation/assignment policies. If you are allocated a /16 and then announce it as /24s what can the RIR do about it? > So if you're going to deploy IPv6, just write a request. If it's serious > and understandable, I'd be surprised if a hostmaster reject it when you > count a /40 for your infrastructre or only get a sum of 180 /48. If the > plan itself is a thing to understand. The best laid plans of mice and men... As others here have pointed out, we can't yet say where the market is going with ipv6. Most plans we make today are likely to be rubbish tomorrow... > ehhmm... sorry Sascha .... not meant to be rude, just wondered ... > > A LIR without own network and ONE uplink / provider ? What services do you > provide ? Your RIPE data (as far as I found on-the-fly- look like a company > paying membership fee for their PI. Now, *that* i could consider rude ;) Where do you get the uplink from, we're not even announcing the route yet (still waiting for upstream #1 to connect their end) We're only just starting and suffered some delays. Look again towards the end of the year and things will look much different. > Before answering it: I'm not going to offend you ... but with this, you > *really* should take IPv6 from your upstream. For various reasons, this is not *really* an option. rgds, Sascha Luck -- DDO Eirconnect

1 0

Re: [address-policy-wg] IPv6 Policy Clarification - Initial allocation criteria "d)"
by Wilfried Woeber, UniVie/ACOnet 17 Jun '04

17 Jun '04

> We do not want to assign a /48 to all >our customers only to meet RIPE's criteria. > >We prefer using only a /32 for each of our broadband access server, and /48 >only for customers asking for it (ie : customers who have a router, several >subnets, ...). First of all, I think you got the prefix length stuff mixed up altogether (/32 for each access server?! :-) But more importantly, why do you intend to continue with the "address space scarcity" paradigm towards your customers? This sounds very much like an attempt to carry over the (broken) v4-business model for services into the v6 world, like - "you want a permanent address?" - well, this i not available in this package because the NCC forces us to do dynamic address management" or - "more than one permanent address?" - well, unfortunately this is not possible for this end-user package, you have to go for a business service which gives you 4/8/16 addresses, but unfortunately you _also_ have to subscribe to a bigger bandwith" at the same time,... >Bertrand Maujean Wilfried.

1 0

Re: [dns-wg] Re: [address-policy-wg] Policy Change Request - Allow address allocations for anycast DNS operation
by Jim Reid 16 Jun '04

16 Jun '04

Not having seen the whole discussion thread, it's a bit hard to make sense of what's been said. However it appears to be that someone is saying that the need for anycasting (and more specifically special address allocations for anycast name servers) can be discounted if ENDS0 was more widely used. This is a flawed argument IMO. As Peter has said, resolvers that aren't EDNS0-aware will still be pounding on the parent zone's name servers. [They're also much more likely to be the resolvers that are misconfigured to go to the root to reverse lookup RFC1918 addresses, don't implement negative caching and so on....] Simply adding more NS records and glue in the parent zone's delegation for a child zone is no help. For one thing, most name server implementations have a limit on the number of name servers they can handle for a delegation. Adding extra NS records is even less help when those servers have IPv6 addresses => yet bigger DNS payloads. In fact adding extra servers and/or IPv6 addresses may be worse because there's an increased likelihood of truncated responses getting sent to these non-EDNS0 resolvers, resulting in retried queries over TCP. Nasty. Aside from these DNS protocol issues, there are plenty of other good reasons for deploying anycasting for important DNS infrastructure. That's why lots of the root and TLD name server operators are doing this already. Ironically, these include the NCC's root name server. Anycasting provides increased robustness, extra redundancy, improved performance, better scalability, extra capacity/throughput, defence in depth from DDoS attacks, etc, etc. Anycasting isn't going to go away even if all the world's DNS software implemented EDNS0. Anycasting is a fact of life. And it will become more prominent in future. So if the address policy WG is reluctant to endorse special address allocations for DNS anycasting, I'd ask them to reconsider. If it helps, we could ask the DNS WG to discuss the issue and perhaps make a recommendation to the address policy WG.

2 1

Policy Change Request - Allow address allocations for anycast DNS operation
by Andreas Bäß/Denic 16 Jun '04

16 Jun '04

In the background I had some discussions with several people what is the best wording for the policy to reflect the discussions that we had on RIPE 47. I think the outcome of these discussions reflect pretty well what I can recall. So I would like to ask the workinggroup what you think. "Operators providing DNS for a zone that is approaching the UDP packet size limit due to the number of authoritative servers may be assigned PI network prefixes: a /24 IPv4 prefix and/or a /32 IPv6 prefix. These prefixes will allow them to anycast the DNS server, as described in RFC 3258." Have a nice day Andreas Baess -- DENIC e.G. Phone :+49 69 27235 120 Wiesenhuettenplatz 26 Fax :+49 69 27235 235 D-60329 Frankfurt Mail : baess(a)denic.de

10 28

Re: [address-policy-wg] Policy Change Request - Allow address allocations for anycast DNS operation
by Wilfried Woeber, UniVie/ACOnet 15 Jun '04

15 Jun '04

Hi Gert! >> If you qualify for at least /24 of v4 address space, there shouldn't >> be a problem with current v4 policy? > >There is. People don't want to use part of their PA block for the >anycast announcement (due to "allocation boundary" filters) and you >won't qualify for a /24 PI with just a single IP address used inside >the block. This, together with the fact that (if I remeber correctly!) there is no longer a minimum usage restriction for becoming an LIR should help to solve this problem?! Wilfried.

2 1

Re: [address-policy-wg] Policy Change Request - Allow address allocations for anycast DNS operation
by Wilfried Woeber, UniVie/ACOnet 15 Jun '04

15 Jun '04

>> There has been some confusion on whether this is "PI". It is not, it's >> "anycast space", and should be tagged as such in the database, to help >> people recognizing these special blocks immediately as such. The usual >> rules apply: "if the criteria for allocations do no longer apply, the >> address block should be returned" (even if that is unlikely to happen >> very often in practice). >> > >Don;t know if there is a real need to tag things like this in the DB, >but I am not going to argue either way. If there is a "real" difference as compared to PI (which I'm still not convinced :-), _and_ a "special" provision for reclaiming those addresses, then I think the answer should be YES. Wilfried.

1 0

Re: [address-policy-wg] Policy Change Request - Allow address allocations for anycast DNS operation
by Wilfried Woeber, UniVie/ACOnet 15 Jun '04

15 Jun '04

Hi Pekka! The next paragraph is where I strongly start to disagree: > (2) this proposal takes no stance on who can request a block of >addresses like this for his DNS servers? Correct, and this is the way it should be! If someone wants to start deploying a particular _technology_ for her service, then there should be NO discussion about size, "importance", level in a hierarchy and similar things. > People could add up servers >and addresses for them just for the purposes of getting nice PI >prefix(es) for their DNS servers. Just like they can buy/rent cheap end systems today to be configured on a particular network to get IPv4 addresses ;-) > Wouldn't it be nice, never having >to renumber your DNS server addresses in different registries etc. Sure :-) And? >This is short-sighted. We should restrict this approach to specific >class of DNS servers, like ccTLDs or the like -- if that's the class >of DNS servers where we'd intend do something like this. This would get us (i.e. the NCC) into deep trouble: without intending to pick at a particular Zone - just to make a point - why would eg. VT. or MD. be eligible, but AC.UK. (or AC.AT. for that matter) or google.com or 3.4.E164.ARPA. would not?! >-- >Pekka Savola "You each name yourselves king, yet the >Netcore Oy kingdom bleeds." >Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings We just made this mistake too often already (looking at a particular application, at a particular transmission technology[1], and the like, and hard-wiring that into resource distribution policy). The only aspect that I would accept here is characteristics or rather limitations of the DNS _technology_ and _protocols_ (and maybe others), but NOT what type of service it is used for! Wilfried. [1] like 24/8 and DSL being treated as "dial-up" when in reality (for a certain period in time) the _business model_ would have been interesting to look at, and not the technology or application...

1 0

Re: [address-policy-wg] Policy Change Request - Allow address allocations for anycast DNS operation
by Wilfried Woeber, UniVie/ACOnet 15 Jun '04

15 Jun '04

>==> While discussing this issue, IPv6 Policy (especially "Initial > allocation criteria" section ) is being clarified (see current > discussion on global-v6(a)lists.apnic.net) Even though, it is said > that the intention of this discussion is to clarify the IPv6 > Policy and not to change it, does it make sense to consider adding > explicitely the criterion above ("DNS ANYCASTING") as a new > criterion to qualifiy for a /32 ? > >Regards, > >Mohsen. I don't think that mixing this would be a good idea, for the following reasons: - I expect the IPv6-clarification exercise to take "quite a while" to converge (across the 4+ RIR constituencies) and I get the feeling that the DNS operators would really like to see a decision reasonably soon now :-) - it is not obvious to me that this special "rucksack"-provision has to go into a globally coordinated text - and for the formal reason that the mandate right now is to provide clarifications or improved wording for the existing v6 policiy. If and when during that exercise it turnes out that we should actually start revising the v6 policy (which would not surprise me :-), then we can reconsider... Wilfried.

1 0

Re: [address-policy-wg] Policy Change Request - Allow address allocations for anycast DNS operation
by Wilfried Woeber, UniVie/ACOnet 14 Jun '04

14 Jun '04

>And with regards, to Wilfried's question about whether this policy >proposal should require the requester to be an LIR, the reply is "why >should it?". To be more precise: not "to be an LIR" but to submit by way of an LIR" - much like the distribution of AS numbers. > Unlike Daniel, I have trouble seeing bureaucracy as a beautiful >clockwork mechanism. This is not to feed any bloated organisational overhead (no implication that there is one in this case!), but rather to avoid digging administrative bypass tunnels :-) >Cheers, >Joao Wilfried.

4 3

New IPv6 Address Block Allocated to RIPE NCC
by leo vegoda 14 Jun '04

14 Jun '04

Dear Colleagues, The RIPE NCC received the IPv6 address range 2001:4000::/23 from the IANA in June 2004. 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

1 0

Re: [address-policy-wg] Policy Change Request - Allow address allocations for anycast DNS operation
by Wilfried Woeber, UniVie/ACOnet 11 Jun '04

11 Jun '04

Hi Andreas! >I have don't think that this should be an imperative. Do you really think >that LIRs should not be able to request such an allocation on behalf of >a customer that would like to do that? Sorry, my question was meant "the-other-way-'round": that a request has to come by way of an established LIR "in good standing" (this of course includes "friendly" existing LIRs offering the service for the project :-). I just wanted to be sure that we don't open a by-pass channel to the LIR structure. >If someone finds it cumbersome to renumber because he has to return the >resources granted to do dns anycasting he probably should not apply for >this resource ;-) Well, the picture might be a bit more complex, in particular for TLDs, when they have to "please" the IANA and/or ICANN to get a re-delegation at a certain point in time ;-) And I haven't yet thought to the bottom of how thing would look like if this becomes a service for supporting many zones, and all of them have to be renumbered because of an interaction with this "special assignment requirement"... >Cheers >Andreas Cheers/Servus, Wilfried. PS: and slightly off-topic: I honestly dislike special arrangements in general - when they are meant to punch holes into too restrictive general resource management rules. We have built too many cans of worms in the past doing so...

1 0

Re: [address-policy-wg] Policy Change Request - Allow address allocations for anycast DNS operation
by Wilfried Woeber, UniVie/ACOnet 09 Jun '04

09 Jun '04

>> I would suggest a slight re-phrase: > >> "Operators providing DNS for a zone served by a number of name servers >> such that the total response size when including the list of >> nameservers for the zone is close to the UDP packet >> size limit may be assigned PI network prefixes for the purpose of >> anycasting name servers, as described on RFC 3258. These shall be: a >> /24 IPv4 prefix and/or a /32 IPv6 prefix." > >> Given that the issue is the will to anycast due to the operational >> impact of adding more servers to the list, not just the size of the NS >> RRSET itself. > >I see your point and it's the same thing I had in mind when I wrote the >policy down. I don't think that it makes sense to work to hard on an exact >definition when someone classifies for an allocation. It depends on how tight we want to knit the mesh (and emphasise conservation et.al. :-) > As well it is >impractical to say you have to cross the limits first (and prove that >your clients are suffering from it) before you can get your allocation. Agreed. >I thought that those who are attracted by the policy will have no problem >justifying it and RIPE would have no problem to ask people returning the >networks if they do not use them as stated in the policy. But maybe >my thinking is too positive here. I guess everything which essentially gives you easy access to a PI /24 (/32 for that matter in the long run) is going to attract interest, at least eventually. Thus here are my questions for double-checking my own mental picture and assumptions: - the applicant has to be an established LIR - correct? - as setting up a server and finding slaves, plus anycast in general is not really rocket science: is there any closer definiton of "Operators providing DNS for a zone served by a number of name servers..." - would my own domain (say - netcraft.at) qualify as well? - and trying to reclaim that address space would be pretty cumbersome for both parties, I guess, unless the zone (all zones on those servers?) go(es) away _completely_ ?! Cheers, Wilfried.

3 2

RIPE NCC Regional Meeting, Nairobi 28-30 July 2004
by Membership Liaison Officer 07 Jun '04

07 Jun '04

Dear Colleagues, The RIPE NCC is pleased to announce the RIPE NCC Regional Meeting in Nairobi, to be held 28-30 July 2004. Details of the venue will follow shortly. Attendance to the RIPE NCC Regional Meeting is open and free of charge. However, attendees are responsible for covering their own travel and accommodation costs. Registration for the Regional Meeting is open. To register, please see: http://www.ripe.net/cgi-bin/nairobi-reg The RIPE NCC Regional Meeting will focus on Internet resource allocation and Internet management issues including: - The industry self-regulatory open structures and processes used by the RIPE NCC and the global Internet community; - How to participate in and influence IP address management policy-making; - AfriNIC - The emerging RIR; - Peering and Exchange Points; - Are we running out of IPv4 address space?; - An update on IPv6; - Domain Name management on the Internet; - Root Server Operations. The Regional Meeting draft agenda can be found at: http://www.ripe.net/ripencc/regional-meetings/nairobi-2004/agenda.html RIPE and the RIPE NCC will explain their roles in the administration of the Internet infrastructure as well as specific aspects in managing and operating the Internet infrastructure. The discussions will be directly related to the particular needs and concerns surrounding these issues in the region. The current draft meeting agenda reflects our intentions. However, it requires active participation from the local community to discuss specific issues of the region. If your organisation wishes to provide a presentation or suggest a relevant topic, please send your proposal by e-mail to: <contact(a)ripe.net> The RIPE NCC is one of four Regional Internet Registries (RIRs) that provide Internet resource allocation, registration services and co-ordination activities that support the operation of the Internet globally. The RIPE NCC is an independent, not-for-profit membership organisation that provides services to members in its service region currently covering Europe, the Middle East, Central Asia and African countries located north of the equator. Further information about the RIPE NCC and RIPE can be found at: http://www.ripe.net More information about the RIPE NCC Regional Meeting, Nairobi is available from: http://www.ripe.net/ripencc/regional-meetings/nairobi-2004/ Any further questions can be sent directly to: <contact(a)ripe.net>. Regards, Nathalie Dougall Membership Liaison Officer RIPE NCC

1 0

Registration Deadline - RIPE NCC Regional Meeting, Moscow 16-18 June 2004
by Membership Liaison Officer 07 Jun '04

07 Jun '04

[Apologies for duplicate mails] Dear Colleagues, This is a final reminder that the RIPE NCC Regional Meeting in Moscow will be held 16-18 June 2004 at the Hotel Metropol, Moscow, Russia. Attendance to the RIPE NCC Regional Meeting is free of charge. However, attendees are responsible for covering their own travel and accommodation costs. REGISTRATION Please note that registration for the Regional Meeting closes on 9 June 2004. To register, please see: http://www.ripe.net/cgi-bin/moscow-reg AGENDA The agenda has been recently updated with more information about speakers and presentations. For the full agenda, please see: http://www.ripe.net/ripencc/regional-meetings/moscow-2004/agenda.html MORE INFORMATION More information about the RIPE NCC Regional Meeting, Moscow is available from: http://www.ripe.net/ripencc/regional-meetings/moscow-2004/ Any further questions can be sent directly to: <contact(a)ripe.net>. Regards, Nathalie Dougall Membership Liaison Officer RIPE NCC

1 0