June 2004 - address-policy-wg

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