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

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

RIPE 48 Meeting Report
by Nick Hyrka 27 May '04

27 May '04

[Apologies for any duplicate mailings.] RIPE 48 Meeting Report Dear Colleagues, The RIPE 48 Meeting was held from 3 - 7 May 2004 at the Grand Hotel Krasnapolsky, Amsterdam, the Netherlands. There were a total of 267 attendees comprised of the RIPE NCC membership, the RIPE community and government representatives. Attendees also included representatives from APNIC, ARIN, AfriNIC, LACNIC and ICANN. HIGHLIGHTS Highlights of RIPE 48 included an update on the Number Resource Organization from Axel Pawlik, Managing Director, RIPE NCC; an open discussion on the proposed Memorandum of Understanding (MoU) between the Number Resource Organization and ICANN; the community consensus to create an ENUM Working Group. J. Scott Marcus, Transatlantic Fellow, The German Marshall Fund of the United States, gave a presentation on the deployment challenges involved with evolving the core of the Internet. This presentation can be viewed at: http://www.ripe.net/ripe/meetings/ripe-48/presentations/ripe48-plenary-marc… The European Operators Forum (EOF) featured presentations on lawful interception of IP traffic, managing a DoS attack, stable BGP routing, strategies for IP traffic engineering, analysing the Internet Routing Registries, IP Address Space and AS Number hijacking and applications of Bidirectional Forwarding Detection (BFD). EOF presentations can be viewed at: http://www.ripe.net/ripe/meetings/ripe-48/presentations/index.html#eof The RIPE NCC, FLAG Telecom, Amsterdam Internet Exchange and Interoute are thanked for the support they provided to the meeting. Global Voice Networks are thanked for the provision of the meeting Internet connectivity. SUMMARY ADDRESS POLICY WORKING GROUP - It was agreed that the issue of worldwide "shopping" for address space needs to be carefully considered before adopting different IPv4 additional allocation procedures (i.e. HD Ratio) in each region. - There were calls for the clarification and review of the initial allocation criteria for IPv6 allocations. The RIPE NCC will propose a rewrite of the IPv6 policy after the issue has been discussed in more detail on the mailing list. Address Policy Working Group presentations can be viewed at: http://www.ripe.net/ripe/meetings/ripe-48/presentations/index.html#ap DATABASE WORKING GROUP - It was agreed that the 'country:' attribute should be either removed or be optional. - It was decided that the default behaviour of the RIPE Database will be changed to return the Incident Response Team (IRT) object if available, in order to make it easier for users to find relevant security contact information. Database Working Group presentations can be viewed at: http://www.ripe.net/ripe/meetings/ripe-48/presentations/index.html#db TEST TRAFFIC MEASUREMENT (TTM) WORKING GROUP - Three presentations were given by Test Box users that offered useful tutorial information for all Test Box owners. - The Working Group Chair encouraged the RIPE NCC to investigate moving measurements into the O/S kernel and/or to hardware. - It was noted that the RIPE NCC has lowered the annual TTM service fee to 1000 euro/year for the first box, 500 euro/year for the second to ninth boxes and that a large company has offered to sponsor hardware for non-profit, research institutes. Test Traffic Working Group presentations can be viewed at: http://www.ripe.net/ripe/meetings/ripe-48/presentations/index.html#tt ANTI-SPAM WORKING GROUP - The community was asked to look at the Anti-Spam Working Group charter and to suggest how it should be changed. - Fearghas McKay reported on the sender-pays stream and specifically on the 'camram' proposal which uses a well-documented system for generating cryptographic signatures ('hashcash'). - There was a proposal to establish a top level domain 'mail.' to be used as a type of DNS white-listing service. IPv6 WORKING GROUP - It was agreed that the Working Group Chair will seek consensus from the Working Group on whether the Minimum Technical IPv6 Peering Requirements (MIPP) document should become a RIPE document. - The community was asked to provide feedback on larger than default IPv6 allocations. - Pim van Pelt asked for members of the community who would like to run public 6to4 relays. IPv6 Working Group presentations can be viewed at: http://www.ripe.net/ripe/meetings/ripe-48/presentations/index.html#ipv6 EIX WORKING GROUP - Kurtis Lindqvist presented his view from the IXP Customer View workshop. - Bijal Sanghani gave a presentation on the expectation an ISP has for an IXP. - European IXPs gave an update about the latest developments, including a presentation on the shared experience of engineers when they migrated their customers from one switch to another. EIX Working Group presentations can be viewed at: http://www.ripe.net/ripe/meetings/ripe-48/presentations/index.html#eix DNS WORKING GROUP - It was agreed that the RIPE NCC will review the zone checks done by the reverse delegation robot. - DNS MODA was proposed by Jim Reid as a not-for-profit body to work on DNS protocol issues. - It was noted that the expansion of IPv6 makes the streamlining of IPv6 direct and reverse DNS even more necessary. DNS Working Group presentations can be viewed at: http://www.ripe.net/ripe/meetings/ripe-48/presentations/index.html#dns ROUTING WORKING GROUP - It was agreed that the RIPE NCC should publish an IRR Toolset maintenance schedule. - There was a presentation on some of the technical issues of high-speed global roaming (flying an 802.11b wireless hot-spot at around 900 km/hr at altitudes around 10km). - There was a presentation on BGPlay, a tool that visualises Internet routing activity. Routing Working Group presentations can be viewed at: http://www.ripe.net/ripe/meetings/ripe-48/presentations/index.html#routing RIPE NCC SERVICES WORKING GROUP - The RIPE NCC was asked to make a more detailed presentation on PGP encryption. - It was agreed that the RIPE NCC should start implementing the key-signing proposal. RIPE NCC Services Working Group presentations can be viewed at: http://www.ripe.net/ripe/meetings/ripe-48/presentations/index.html#ncc-serv… TECHNICAL SECURITY WORKING GROUP - There was a presentation on security aware resolvers and discussion on the requirements for them. - There was discussion on 'server-side' protocol bits and the feeling that they are solid and ready for deployment; it was noted that validator/application communication and key-management issues need work. Technical Security Working Group presentations can be viewed at: http://www.ripe.net/ripe/meetings/ripe-48/presentations/index.html#techsec TUTORIALS The RIPE NCC Training Team presented the RIPE NCC IP Request Tutorial. It explained address space assignment and allocation procedures in the RIPE NCC region: http://www.ripe.net/ripe/meetings/ripe-48/tutorials/ip-request/index.html RIPE 48 WEBCASTING AND ARCHIVES During RIPE 48, the RIPE NCC held trials in collecting feedback from participants watching the webcast. The mediums used for this were IRC and Jabber. Archives of presentations, webcasts and IRC/Jabber feedback from RIPE 48 are available at: http://www.ripe.net/ripe/meetings/ripe-48/sessions-archive.html HOSTMASTER CONSULTATION CENTRE (HCC) The RIPE NCC Hostmaster Consultation Centre was open at RIPE 48, allowing RIPE NCC Members to discuss issues relating to their business directly with RIPE NCC Hostmasters. RIPE 48 REFERENCE PAGE A complete list of RIPE 48 sessions, tutorials and presentations can be found at: http://www.ripe.net/ripe/meetings/ripe-48/index.html "MEET & GREET" The RIPE NCC's "Meet & Greet" was available for first-time RIPE Meeting attendees at RIPE 48. "Meet & Greet" introduces newcomers to the meetings, to key attendees from the RIPE community and to social events throughout the week. More information can be obtained by contacting: <meet-greet(a)ripe.net>. RIPE 49 RIPE 49 will be held in Manchester, the United Kingdom, from 20 - 24 September 2004. Information on RIPE 49 will soon be made available at: http://www.ripe.net/ripe/meetings/ripe-49/ NEW LOCAL INTERNET REGISTRIES (LIRs) Please note: New LIRs are entitled to two (2) free tickets to attend a RIPE Meeting. The tickets cover the meeting fee only and do not apply to the RIPE dinner, travel or hotel accommodation. More information on the new LIR tickets can be found at: http://www.ripe.net/ripe/meetings/new-lir.html For more information, contact <meeting(a)ripe.net>.

1 0