From iljitsch at muada.com Sun Jan 1 20:58:34 2006 From: iljitsch at muada.com (Iljitsch van Beijnum) Date: Sun, 1 Jan 2006 20:58:34 +0100 Subject: [address-policy-wg] 2005 IPv4 Address Use Report Message-ID: According to AfriNIC, APNIC, ARIN, LACNIC and RIPE NCC statistics as published on their respective FTP servers, they gave out 165.45 million IPv4 addresses in 2005. Out of 3706.65 million usable IPv4 addresses, 1468.61 million are still available as of januari 1, 2006. Breakdown by Regional Internet Registry over the past few years: 2000 2001 2002 2003 2004 2005 AfriNIC 0.56 0.38 0.25 0.21 0.51 1.89 APNIC 21.08 28.84 27.08 33.08 42.92 53.97 ARIN 30.96 32.76 21.02 22.14 33.51 36.30 LACNIC 0.88 1.57 0.65 2.62 3.77 11.04 RIPE NCC 24.88 25.39 19.94 29.72 47.75 62.25 Total 78.35 88.95 68.93 87.77 128.45 165.45 AfriNIC gives out address space in Africa, APNIC in the Asia-Pacific region, ARIN in North America, LACNIC in Latin American and the Caribbean and the RIPE NCC in Europe, the former Soviet Union and the Middle East. Note that the RIRs tend to change their records retroactively from time to time. For instance, the januari 1, 2005 records show that only 117.3 million addresses were given out in 2004. Also, reclaimed address space isn't listed explicitly. From the fact that the 1-1-2005 records show 1939 million addresses given out before 2004 but the 1-1-2006 records show 1928.48 million addresses for the same period, we can conclude that 11.15 million addresses given out before 2004 have been reclaimed in 2005. The Internet Assigned Numbers Authority (IANA, part of ICANN) keeps an overview of the IPv4 address space at http://www.iana.org/ assignments/ipv4-address-space. The list consists of 256 blocks of 16.78 million addresses. Breakdown: Delegated to Blocks Addresses (millions) AfriNIC 1 16.78 APNIC 16 268.44 ARIN 23 385.88 LACNIC 4 67.11 RIPE NCC 19 318.77 Various 50 838.86 End-user 43 721.42 Available 65 1090.52 Of the 1895.83 million addresses delegated to the five Regional Internet Registries, 1517.74 million have been delegated to end-users or ISPs by the RIRs, and 378.09 million are still available. Along with the 1090.52 million addresses still available in the IANA global pool this makes the total number of available addresses 1468.61 million. The size of address blocks given follows an interesting trend. The table below shows the number of requests for a certain range of block sizes (equal or higher than the first, lower than the second value). 2000 2001 2002 2003 2004 2005 < 1000 326 474 547 745 1022 1309 1000 - 8000 652 1176 897 1009 1516 1891 8000 - 64k 1440 868 822 1014 1100 1039 64k - 500k 354 262 163 215 404 309 500k - 2M 19 39 29 46 61 60 > 2M 3 5 5 6 7 18 The number of blocks in the two smallest categories have increased rapidly, but not as fast as the number of blocks in the largest category, in relative numbers at least. However, the increase in large blocks has a very dramatic effect while the small blocks are insignificant, when looking at the millions of addresses involved: 2000 2001 2002 2003 2004 2005 < 1000 0.10 0.16 0.18 0.25 0.35 0.44 1000 - 8000 2.42 4.47 3.23 3.45 4.49 5.07 8000 - 64k 18.79 12.81 11.35 14.00 15.99 15.46 64k - 500k 35.98 32.19 20.28 25.51 42.01 34.23 500k - 2M 12.68 24.64 21.30 31.98 44.63 41.63 > 2M 8.39 14.68 12.58 12.58 20.97 68.62 The medium-sized blocks seem most affected by the burst of the internet bubble. Another way to look at the same data: Year Blocks Addresses (M) Average block size 2000 2794 78.35 28043 2001 2824 88.95 31497 2002 2463 68.93 27985 2003 3035 87.77 28921 2004 4110 128.45 31252 2005 4626 165.45 35765 The 2222.38 million addresses currently in use aren't very evenly distributed over the countries in the world. The current top 15 is: Country Addresses US 1324.93 M United States JP 143.00 M Japan EU 113.87 M Multi-country in Europe CN 74.39 M China CA 67.43 M Canada DE 51.13 M Germany FR 45.16 M France KR 41.91 M Korea UK 40.18 M United Kingdom GB 33.63 M Great Britain AU 26.87 M Australia IT 18.39 M Italy BR 17.17 M Brazil NL 16.40 M Netherlands ES 16.29 M Spain The US holds 60% of the IPv4 address space. The other countries in the list together hold another 32%. A copy of this information and a tool to perform queries on the base data is available at http://www.bgpexpert.com/addrspace2005.php From contact at ripe.net Tue Jan 3 14:50:06 2006 From: contact at ripe.net (Paul Rendek) Date: Tue, 03 Jan 2006 14:50:06 +0100 Subject: [address-policy-wg] Final Reminder: RIPE NCC Regional Meeting Qatar, 17-18 January 2006 Message-ID: <43BA810E.6000706@ripe.net> [Apologies for duplicate e-mails] Dear Colleagues, Registration will soon close for the RIPE NCC Regional Meeting, taking place at the Doha Marriott Hotel, Qatar, 17-18 January 2006. Registration will close on Friday, 13 January 2006. If you have not yet registered, please register today at: www.ripe.net/qatar2006/register MEETING AGENDA This RIPE NCC Regional Meeting is specifically designed to provide participants with a forum to discuss topics related to IP networking in the Middle East region. The latest draft meeting agenda is available at: http://www.ripe.net/meetings/regional/qatar-2006/agenda.html SEMINARS All meeting attendees are invited to attend the RIPE NCC seminars taking place on Wednesday 18 January, from 14:00. - The DNSSEC Seminar aims to outline the features of DNSSEC and related tools and introduces the relevant RIPE NCC services. - The Routing Registry (RR) Seminar aims to teach the features of Routing Registry and related tools, introduce the relevant RIPE NCC services and explain the basics of Routing Policy Specification Language (RPSL). SCHEDULE AN APPOINTMENT WITH RIPE NCC IP RESOURCE ANALYSTS During the meeting, attendees can schedule an appointment with RIPE NCC IP Resource Analysts to discuss issues relating to their business. For more information, or to schedule an appointment, please see: http://www.ripe.net/meetings/regional/qatar-2006/ip-resource-analysts.html MORE INFORMATION Attendance to RIPE NCC Regional Meetings is open and free of charge. However, attendees are responsible for covering their own travel and accommodation costs. More details about the RIPE NCC Regional Meeting in Qatar are available at: http://www.ripe.net/qatar2006 Please send any questions to: Regards, Paul Rendek Head of Member Services & Communications RIPE NCC From marc.van.selm at nc3a.nato.int Wed Jan 4 11:12:19 2006 From: marc.van.selm at nc3a.nato.int (Marc van Selm) Date: Wed, 4 Jan 2006 11:12:19 +0100 Subject: [address-policy-wg] Re: 200 customer requirements for IPv6 In-Reply-To: <4396F737.3000400@unfix.org> References: <4396F737.3000400@unfix.org> Message-ID: <200601041112.19341.marc.van.selm@nc3a.nato.int> On Wednesday 07 December 2005 15:52, Jeroen Massar wrote: > Michael.Dillon at btradianz.com wrote: > > > > > Non-attributed person wrote: > >> There may however be places where such cooperation is appropriate, in > >> which case RIR-policies should accomodate such a construct. ISP's who > >> want such cooperation should probably establish an independent > >> organisation that would act as the LIR for their region. There's nothing > >> (exept possibly the 200 customer limit) in the current RIR-policy that > >> prevents such a construct. > > > > As has been repeatedly pointed out by others, the 200 customer > > limit is a REAL block to deployment of IPv6 by many companies. > > Which companies? According to the stats* Leo gave only 6 requests where > ever denied based on this. Can these companies please come forward and > explain what they exactly want? NATO is one org that could impacted. We plan to work around it but it depends on the definition of an "organization" and "customers". If one considers NATO as an organization (and not a alliance of organizations and nations), then NATO will not have any customers. But NATO has a large privately operated network that uses many ISPs and telcos for transmission services. Contracts have to be rebid on a regular basis. So requesting IP space from an ISP is a configuration stability issue that we don't like. Only for that reason allone, NATO "needs" to "own" a block of IP space not "owned" by a ISP. Now NATO can work around the 200-rule because NATO has its own service provider and we decided to consider NATO as an alliance of organizations. That is actually how NATO works so it is not bending the truth at all. So there are 200+ customers. But it is a bit artificial. I don't expect RIPE will reject a request but it illustrates the hoops that a large org with a large network that is part of their strategic assets will have to go through. OK one can just get space from an ISP but that effectively gives ISP lock-in as one does not want to reconfigure the core assets just for a contract rebid. Again, I think we have a solid work around but looking at the controversy that this discussion has caused, a non ISP-centric policy would be useful. Best regards, Marc -- Marc van Selm NATO C3 Agency CIS Division E-mail: marc.van.selm at nc3a.nato.int (PGP capable) This mail is not stating NATO policy but must be considered as informal exchange of views. From jeroen at unfix.org Wed Jan 4 11:59:18 2006 From: jeroen at unfix.org (Jeroen Massar) Date: Wed, 04 Jan 2006 11:59:18 +0100 Subject: [address-policy-wg] Re: 200 customer requirements for IPv6 In-Reply-To: <200601041112.19341.marc.van.selm@nc3a.nato.int> References: <4396F737.3000400@unfix.org> <200601041112.19341.marc.van.selm@nc3a.nato.int> Message-ID: <43BBAA86.9040308@unfix.org> Marc van Selm wrote: > On Wednesday 07 December 2005 15:52, Jeroen Massar wrote: [..] >> Which companies? According to the stats* Leo gave only 6 requests where >> ever denied based on this. Can these companies please come forward and >> explain what they exactly want? [..] > Now NATO can work around the 200-rule because NATO has its own service > provider and we decided to consider NATO as an alliance of organizations. > That is actually how NATO works so it is not bending the truth at all. So > there are 200+ customers. Larger companies and organizations have an IT department, which most of the times even is an officially registered separate branch of such an organization. Branches of larger organization are also separately registered organizations, especially when crossing country borders this becomes very obvious for tax reasons and country law. The IT department or even special Networking department is effectively the "ISP" for the organization. That they only service customers of their mother company is not the question here: they service 200 customers. Another point with the 200 rule is that any employee making a vpn connection towards the network can already be consider to be a different endsite. > But it is a bit artificial. I don't expect RIPE > will reject a request but it illustrates the hoops that a large org with a > large network that is part of their strategic assets will have to go through. Which hoop? Any construct of the above will have no problem in getting address space from any of the RIR's. If they do try and get rejected they should explain their situation here, if possible, and explain what they are missing so that the policy can be amended or a special policy be created for these cases. > Again, I think we have a solid work around but looking at the controversy that > this discussion has caused, a non ISP-centric policy would be useful. The only complains I have seen so far, from people who don't fit the magic 200 rule, is from sites that are real end-sites, sites that don't have any/much infrastructure except towards the IX or interconnect point with their upstream(s) and appear to not provide any/much connectivity to other organizations. For those sites a /32 would also be way too much address space, they would suffice with either a /40 or /48 already. For these sites there should come a separate policy so that they can request this address space, preferably allocated from a single global prefix for filtering reasons. Note very well that RIR's provide "Address Space", not "Routability", the latter is what you and your upstreams agree on. As a side note, any large organization using multiple access providers to connect to the Internet will budge into a hard problem, though this is mostly a routing issue: One has a /32, say 2001:db8::/32, which is the allocation for your organization. 2001:db8:1000::/48 is Amsterdam, 2001:db8:f000::/48 is Singapore. An employee from Singapore accesses a website in London. Traffic thus flows Singapore -> .sg ISP -> $inet -> London, the return traffic though flows London -> .nl ISP -> Amsterdam... oops. Indeed even though one gets a /32 allocated one will have to announce the /48's separately, or use some weird VPN tricks, when one doesn't have their own internal transit network. The problem here is again the filtering of >/32 which is taking place, though getting less in most places it still can cause a problem. Another more policy-wise issue with the above is that the idea and advantage of "Provider Aggregated" and thus less routes in the routing tables is mostly gone as most sites, the ones who effectively don't have their own transit networks, will have to announce the more specifics anyway. When the routing tables become $too_large there will have to be something to solve this issue and IMHO the PA idea will be great then, but will require that end-sites do some a double-NAT trick ala shim6 to/from the /48 which they got from their provider, that is the one with a global network.... Greets, Jeroen BTW: Everybody can of course use their IPv4 space to create IPv6 space: 2002::::/48 or even bigger if you use your /24. Traffic engineering and everything works for that, one will have to rely on having working 6to4 relays though. But that is the same as having to rely on a working transit provider at the other end. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 238 bytes Desc: OpenPGP digital signature URL: From marc.van.selm at nc3a.nato.int Wed Jan 4 12:32:10 2006 From: marc.van.selm at nc3a.nato.int (Marc van Selm) Date: Wed, 4 Jan 2006 12:32:10 +0100 Subject: [address-policy-wg] Re: 200 customer requirements for IPv6 In-Reply-To: <43BBAA86.9040308@unfix.org> References: <200601041112.19341.marc.van.selm@nc3a.nato.int> <43BBAA86.9040308@unfix.org> Message-ID: <200601041232.10484.marc.van.selm@nc3a.nato.int> On Wednesday 04 January 2006 11:59, Jeroen Massar wrote: [...] > The IT department or even special Networking department is effectively > the "ISP" for the organization. That they only service customers of > their mother company is not the question here: they service 200 customers. [...] > > But it is a bit artificial. I don't expect RIPE > > will reject a request but it illustrates the hoops that a large org with > > a large network that is part of their strategic assets will have to go > > through. > > Which hoop? Any construct of the above will have no problem in getting > address space from any of the RIR's. If they do try and get rejected > they should explain their situation here, if possible, and explain what > they are missing so that the policy can be amended or a special policy > be created for these cases. Yes you are right and that's how I'd like to treat it for NATO. The definition of an organization and customer is sufficiently flexible. So if flexibility of definitions is acceptable (non of us wants to be a lawyer I presume) than we should (should?) close the thread and move on. Best regards, Marc -- Marc van Selm NATO C3 Agency CIS Division E-mail: marc.van.selm at nc3a.nato.int (PGP capable) This mail is not stating NATO policy but must be considered as informal exchange of views. From jeroen at unfix.org Wed Jan 4 13:24:07 2006 From: jeroen at unfix.org (Jeroen Massar) Date: Wed, 04 Jan 2006 13:24:07 +0100 Subject: [address-policy-wg] Re: 200 customer requirements for IPv6 In-Reply-To: <200601041232.10484.marc.van.selm@nc3a.nato.int> References: <200601041112.19341.marc.van.selm@nc3a.nato.int> <43BBAA86.9040308@unfix.org> <200601041232.10484.marc.van.selm@nc3a.nato.int> Message-ID: <43BBBE67.40000@unfix.org> Marc van Selm wrote: > On Wednesday 04 January 2006 11:59, Jeroen Massar wrote: > > [...] >> The IT department or even special Networking department is effectively >> the "ISP" for the organization. That they only service customers of >> their mother company is not the question here: they service 200 customers. > [...] [..] > Yes you are right and that's how I'd like to treat it for NATO. > The definition of an organization and customer is sufficiently flexible. > So if flexibility of definitions is acceptable (non of us wants to be a > lawyer I presume) than we should (should?) close the thread and move on. Thus indeed for you (NATO) the thread is closed. The flexibility of the policy was put in place to allow various setups to be meant for this policy. But there are apparently other organizations who do not fulfill the current policies requirements but do need address space. These folks *DO* need to come forward and raise their voices and specify how they don't fit in the current policy and how much address space they need. Greets, Jeroen -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 238 bytes Desc: OpenPGP digital signature URL: From tim.streater at dante.org.uk Thu Jan 5 15:13:43 2006 From: tim.streater at dante.org.uk (Tim Streater) Date: Thu, 05 Jan 2006 14:13:43 +0000 Subject: [address-policy-wg] Re: 200 customer requirements for IPv6 In-Reply-To: <43BBBE67.40000@unfix.org> References: <200601041112.19341.marc.van.selm@nc3a.nato.int> <43BBAA86.9040308@unfix.org> <200601041232.10484.marc.van.selm@nc3a.nato.int> <43BBBE67.40000@unfix.org> Message-ID: <6.2.3.4.2.20060105141317.030d6bd0@mail.dante.org.uk> At 12:24 04/01/2006, Jeroen Massar wrote: >*** PGP Signature Status: good >*** Signer: Jeroen Massar (Invalid) >*** Signed: 04/01/2006 12:24:07 >*** Verified: 05/01/2006 14:12:53 >*** BEGIN PGP VERIFIED MESSAGE *** > >Marc van Selm wrote: >> On Wednesday 04 January 2006 11:59, Jeroen Massar wrote: >> >> [...] >>> The IT department or even special Networking department is effectively >>> the "ISP" for the organization. That they only service customers of >>> their mother company is not the question here: they service 200 customers. >> [...] >[..] >> Yes you are right and that's how I'd like to treat it for NATO. >> The definition of an organization and customer is sufficiently flexible. >> So if flexibility of definitions is acceptable (non of us wants to be a >> lawyer I presume) than we should (should?) close the thread and move on. > >Thus indeed for you (NATO) the thread is closed. > >The flexibility of the policy was put in place to allow various setups >to be meant for this policy. But there are apparently other >organizations who do not fulfill the current policies requirements but >do need address space. These folks *DO* need to come forward and raise >their voices and specify how they don't fit in the current policy and >how much address space they need. I thought I already did this. -- Tim From ncc at ripe.net Thu Jan 5 18:42:28 2006 From: ncc at ripe.net (Nick Hyrka) Date: Thu, 05 Jan 2006 18:42:28 +0100 Subject: [address-policy-wg] RIPE 51 Report Message-ID: <5.2.1.1.2.20060105174049.02e38bc0@mailhost.ripe.net> [Apologies for duplicate e-mails.] RIPE 51 REPORT The RIPE 51 Meeting took place from 10 - 14 October 2005 at the Hotel Krasnapolsky, Amsterdam, the Netherlands. There were 320 attendees at the meeting. Attendees also included government representatives and representatives from AfriNIC, APNIC, ARIN, LACNIC and ICANN. Highlights of RIPE 51 included the announcement of the RIPE NCC E-learning Centre, a free online resource available to both members of the RIPE NCC and non-members. More information about the E-Learning Centre is available at: http://e-learning.ripe.net Global Crossing, the Amsterdam Internet Exchange, Force10 Networks and the RIPE NCC are thanked for the support they provided to the meeting. Global Voice Networks are thanked for the provision of the meeting Internet connectivity. PRESENTATIONS All the Plenary and Working Group presentations from RIPE 51 can be viewed at: http://www.ripe.net/ripe/meetings/ripe-51/presentations/index.html SUMMARY OF WORKING GROUP SESSIONS ADDRESS POLICY WORKING GROUP Action Points: The text for the policy proposals below will be reviewed by the following people, after concerns were raised by the working group: - #2005-02: TLD anycast allocation policy (Andreas Baess); - #2005-03: Removal of the 200 customer assignments requirement and referral to /48 assignments from the IPv6 initial allocation criteria (Andy Furnell); - #2005-04: IPv6 Address Allocation and Assignment Policy definition for end site (Eric Schmidt); - #2005-08: Proposal to Amend the IPv6 Assignment and Utilisation Requirement Policy (Geoff Huston and Kurtis Lindqvist). The working group chairs will set deadlines for discussion after these reviews. Highlights: The working group discussed the six policy proposals that are currently ongoing. The list of current proposals can be seen at: http://www.ripe.net/ripe/policies/proposals/ The working group agreed that a session should be scheduled at a future RIPE Meeting to discuss what mechanisms the community needs for a working Internet after the exhaustion of IPv4 address space. ANTI-SPAM WORKING GROUP Action Points: - Rodney Tillotson: Submit LINX BCP as a revised ripe-206 using the Policy Development Process (PDP). Highlights: - The document on which ripe-206 is based has been updated, and ripe-206 will be revised. - Greylisting discussion showed some consider it harmful, and some use it. - DKIM is an up-and-coming authentication technique. DATABASE WORKING GROUP Action Points: - RIPE NCC: Change the behaviour of the RIPE Whois Database server to return IRT objects by default. - RIPE NCC: Contact anti-spam tool writers to make them aware of the default behaviour change regarding IRT objects. - Peter Koch: Start a Policy Development Process to deprecate CRYPT-PW authorisation in the RIPE Whois Database. - RIPE NCC: Write a document describing the use of the IRT object in the RIPE Whois Database. - Wilfried Woeber: Start a Policy Development Process proposal to make the "country:" attribute in inet(6)num object optional and multiple. - RIPE NCC: Check Gnu Privacy Guard (GnuPG) compatibility before implementing changes to the RIPE Whois Database to prevent replay attacks. - RIPE NCC: Check if contacts can be properly mapped in IRIS (admin-c and tech-c). - RIPE NCC: Check what are other missing attributes in IRIS that are needed for the RIPE community. - Matt Rowley (ARIN): Check if other Routing Registries support RPSLng. - RIPE NCC: Implement the proposed DNSSEC changes. Highlights: - It was noted that there is an ongoing effort for improving documentation regarding the RIPE Whois Database. - It was noted that IRIS prototype server is now implemented and run by the RIPE NCC. DNS WORKING GROUP Action Points: - 51.1 RIPE NCC/Andrei Robachevsky: Agree with RIRs on a date for decommissioning of IP6.INT reverse mapping services. Outline and communicate procedure to be followed based on the presentation made during the working group session. - 51.2 Lars-Johan Liman: Draft a proposal on the future of the RIPE NCC Secondary DNS Service. To be dealt with in co-operation with the RIPE NCC Services Working Group. - 51.3 Peter Koch: Draft text and initiate discussion on the mailing list towards an update of ripe-203 along the lines of the presentation brought to the working group. - 51.4 Carsten Schiefner: Provide text for a proposal for the RIPE NCC to implement ENUM DNS predelegation checks. Also explore the field of regular post delegation sanity checks in the e164.arpa tree. Highlights: - Peter Koch announced that the Policy Proposal 2005-07, "Introducing DNSSEC Service to Reverse DNS Trees" had now completed its run through the formal Policy Proposal Process. As the DNS Working Group Chairs had received no formal objections to it, they declared consensus had been reached. The policy is now published as a RIPE Document: http://www.ripe.net/ripe/docs/ripe-359.html EIX WORKING GROUP Action Points: There were no actions from this working group. Highlights: - The minutes of the RIPE 50 EIX Working Group were approved. - There were 13 short IXP update presentations from EURO-IX, AMS-IX, DE-CIX, INEX, LINX, NDIX, LONAP, Netnod, NIX, NIX.CZ, SFINX, Terremark, VIX. - It was agreed that the as-set object is the appropriate object for showing members of internet exchanges on the RIPE Database. - There was a presentation by Mike Hughes from LINX about Voice over Internet Protocol (VoIP) peering. The presentation questioned people's assertions about the subject, and pointed out how the term had become somewhat overloaded. The presentation showed how VoIP peering affects IXPs, and what IXPs may want or not want to do in this area. ENUM WORKING GROUP Action Points: - RIPE NCC: Publish statistics from all e164.arpa servers. - Carsten Schiefner: Let the RIPE NCC know the details of missing links related to the indexation of requests. - RIPE NCC: Check whether the quarterly reports to the Internet Architecture Board (IAB) on ENUM operations are still necessary. - Peter Koch: Continue counting the reverse delegations in the 9.4.e164.arpa tree and report the results at RIPE 52. - Jim Reid: Stimulate discussion on testbed numbers/ranges. - Carsten Schiefner: Work with the RIPE NCC on ways to help improve the quality of DNS within the e164.arpa tree. - All: Help test Austria's ENUM reachability (see the message on the list). Highlights: - Work on ENUM-related IETF standards continues. - New deployment and operations statistics are being published. - Test activities are expanding. IPv6 WORKING GROUP Action Points: - 51.1 David Kessens: Ask the RIPE NCC to revise the acronym list in the registration package to remove obsolete terms as TLA & NLA Status: Completed - 51.2 RIPE NCC: Create a link from the IPv6 Working Group page to the APNIC events page: http://apnic.net/info/calendar/index.html Status: To be done - 51.3 RIPE NCC: Provide traffic reports on IPv6 usage during the RIPE meetings. If available, data from earlier meetings will be made available as well. Status: To be done RIPE NCC SERVICES WORKING GROUP There were no actions and highlights from this working group. ROUTING WORKING GROUP Action Points: - Philip Smith/Geoff Huston: Produce a document describing why route flap damping is harmful, and why ripe-229 no longer applies. Highlights: - There was discussion on route flap damping. It was agreed that ripe-229 on this subject is obsolete and should be replaced by a new document. It was agreed that this new document should describe why ISPs should not switch on flap damping in their routers, as well as explaining why and noting if there are any exceptions. - There was discussion on a possible Route Aggregation Policy. Joao will evaluate the feasibility of such a document together with some volunteers, including Mike Hughes and Philip Smith. - Arife Vural (RIPE NCC) presented an update on the status of the Routing Information Service (RIS) project. TEST TRAFFIC WORKING GROUP Action points: - RIPE NCC: Research the Multicast connectivity of the test-boxes. - All: Think about how to get more measurement nodes in TTM. Highlights: - Proposal to measure Multicast using TTM. - Consumer Broadband Measurements draft sent to the list and shortly discussed in the working group. - Discussion on how to measure DNSMON from more nodes worldwide. RIPE 51 WEBCASTING AND ARCHIVES During RIPE 51, the RIPE NCC collected feedback from participants watching the webcast and listening to the audiocasts. The mediums used for this were IRC and Jabber. Archives of presentations, webcasts and IRC/Jabber feedback from RIPE 51 are available at: http://www.ripe.net/ripe/meetings/ripe-51/sessions-archive.html RIPE NCC MEMBER SERVICES CENTRE The RIPE NCC Member Services Centre was introduced at RIPE 51 as a replacement to the Hostmaster Consultation Centre and enabled attendees to talk face-to-face with representatives from the RIPE NCC Registration Services, Finance, Training, Software Engineering and Technical Departments. "MEET & GREET" The RIPE NCC's "Meet & Greet" was available for first-time RIPE Meeting attendees at RIPE 51. "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 . RIPE 51 REFERENCE PAGE A complete list of RIPE 51 sessions and presentations can be found at: http://www.ripe.net/ripe/meetings/ripe-51 RIPE 52 RIPE 52 will be held in Istanbul, Turkey from 24 - 28 April 2006. More information on RIPE 52 will soon be available at: http://www.ripe.net/ripe/meetings/ripe-52/index.html If you have any questions about RIPE Meetings, please contact . From contact at ripe.net Fri Jan 6 16:16:14 2006 From: contact at ripe.net (Paul Rendek) Date: Fri, 06 Jan 2006 16:16:14 +0100 Subject: [address-policy-wg] ASO Call for Nominations for ICANN Board Seat Message-ID: <43BE89BE.5050501@ripe.net> [Apologies for duplicate e-mails] This message is sent on behalf of the Address Supporting Organization: Dear Colleagues, In compliance with the ASO MoU and ICANN bylaws the Address Council hereby calls for nominations to the ICANN Board to fill the ASO seat currently held by Mouhamet Diop, whose term expires in June of 2006. This nomination period will close on April 4, 2006. Nominations may be submitted by anyone by sending email to: nominations at aso.icann.org. Nominations must include the following information: ? Full name of person being nominated ? Contact email address for person being nominated ? Contact telephone number (if available) of the person being nominated ? Full name of the person making the nomination ? Contact email address for the person making the nomination ? Contact telephone number of the person making the nomination Nominations will be reviewed in accordance with the ASO Board of Directors selection procedures, as documented on the ASO website. ASO Secretariat http://www.aso.icann.org From heldal at eml.cc Mon Jan 16 14:38:35 2006 From: heldal at eml.cc (Per Heldal) Date: Mon, 16 Jan 2006 14:38:35 +0100 Subject: [address-policy-wg] Re: 200 customer requirements for IPv6 In-Reply-To: <200601041112.19341.marc.van.selm@nc3a.nato.int> References: <4396F737.3000400@unfix.org> <200601041112.19341.marc.van.selm@nc3a.nato.int> Message-ID: <1137418715.32453.251951920@webmail.messagingengine.com> On Wed, 4 Jan 2006 11:12:19 +0100, "Marc van Selm" said: [snip] > > Again, I think we have a solid work around but looking at the controversy > that > this discussion has caused, a non ISP-centric policy would be useful. > The policy might seem ISP-centric, but that's just a coincidence. It reflects the opinion of many in the ops-community that it doesn't make sense to migrate to IPv6 until it is able to provide more than just an extended address-space. At least not as long as there is no *real* shortage of v4-addresses. Unfortunately, very few seem willing to admit that in public. The current policy will work in a future that has mechanisms to separate identifiers from locators. Maybe some people should revise their short-term expectations wrt IPv6. //per -- Per Heldal http://heldal.eml.cc/ From tim.streater at dante.org.uk Mon Jan 16 15:26:50 2006 From: tim.streater at dante.org.uk (Tim Streater) Date: Mon, 16 Jan 2006 14:26:50 +0000 Subject: [address-policy-wg] Re: 200 customer requirements for IPv6 In-Reply-To: <1137418715.32453.251951920@webmail.messagingengine.com> References: <4396F737.3000400@unfix.org> <200601041112.19341.marc.van.selm@nc3a.nato.int> <1137418715.32453.251951920@webmail.messagingengine.com> Message-ID: <6.2.3.4.2.20060116141211.04d583d8@mail.dante.org.uk> At 13:38 16/01/2006, Per Heldal wrote: >On Wed, 4 Jan 2006 11:12:19 +0100, "Marc van Selm" > said: >[snip] >> >> Again, I think we have a solid work around but looking at the controversy >> that >> this discussion has caused, a non ISP-centric policy would be useful. >> > >The policy might seem ISP-centric, but that's just a coincidence. It >reflects the opinion of many in the ops-community that it doesn't make >sense to migrate to IPv6 until it is able to provide more than just an >extended address-space. At least not as long as there is >no *real* shortage of v4-addresses. Unfortunately, very few seem willing >to admit that in public. The current policy will work in a future that >has mechanisms to separate identifiers from locators. Maybe some people >should revise their short-term expectations wrt IPv6. Notwithstanding this, there is some pressure in the research community for v6 to be available. And this translates downwards, at least for me, into a requirement to get some PI v6 space for a transit network. IPv6 is supposed to be an available and operational service, in which case the policy should cover all reasonable requirements. If it is not the case (i.e., not an operational or available service), but is still considered to be under development, not yet needed to be deployed, might need to be changed to introduce geographical addressing, or whatever else, then presumably this needs to be made evident and debated in a different forum. -- Tim From pekkas at netcore.fi Mon Jan 16 17:20:11 2006 From: pekkas at netcore.fi (Pekka Savola) Date: Mon, 16 Jan 2006 18:20:11 +0200 (EET) Subject: [address-policy-wg] Re: 200 customer requirements for IPv6 In-Reply-To: <6.2.3.4.2.20060116141211.04d583d8@mail.dante.org.uk> References: <4396F737.3000400@unfix.org> <200601041112.19341.marc.van.selm@nc3a.nato.int> <1137418715.32453.251951920@webmail.messagingengine.com> <6.2.3.4.2.20060116141211.04d583d8@mail.dante.org.uk> Message-ID: On Mon, 16 Jan 2006, Tim Streater wrote: [...] > Notwithstanding this, there is some pressure in the research > community for v6 to be available. And this translates downwards, at > least for me, into a requirement to get some PI v6 space for a > transit network. > > IPv6 is supposed to be an available and operational service, in > which case the policy should cover all reasonable requirements. If > it is not the case (i.e., not an operational or available service), > but is still considered to be under development, not yet needed to > be deployed, might need to be changed to introduce geographical > addressing, or whatever else, then presumably this needs to be made > evident and debated in a different forum. I'm not sure how constructive this particular thread is. Transit networks are a simple case to deal in the policy. You could, for example, specify that if an ISP provides transit to other organizations which qualify (or have already qualified) for an allocation of their own, the transit network could also get an allocation. This has de-facto way the policy has been implemented already. It's the other parts of the policy that are trickier to address in an acceptable manner. Either we should focus the discussion on them (oh no, not again! :) or create a very specific policy amendment proposal that addresses the specific transit-only ISP case only. -- Pekka Savola "You each name yourselves king, yet the Netcore Oy kingdom bleeds." Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings From heldal at eml.cc Mon Jan 16 17:46:22 2006 From: heldal at eml.cc (Per Heldal) Date: Mon, 16 Jan 2006 17:46:22 +0100 Subject: [address-policy-wg] Re: 200 customer requirements for IPv6 In-Reply-To: <6.2.3.4.2.20060116141211.04d583d8@mail.dante.org.uk> References: <4396F737.3000400@unfix.org> <200601041112.19341.marc.van.selm@nc3a.nato.int> <1137418715.32453.251951920@webmail.messagingengine.com> <6.2.3.4.2.20060116141211.04d583d8@mail.dante.org.uk> Message-ID: <1137429982.21955.251966941@webmail.messagingengine.com> On Mon, 16 Jan 2006 14:26:50 +0000, "Tim Streater" > Notwithstanding this, there is some pressure in the research community > for v6 to be available. And this translates downwards, at least for me, > into a requirement to get some PI v6 space for a transit network. Your organisation shouldn't have a problem getting adsress-space It is in everyone's best interest to get as many people as possible from the research community involved. > > IPv6 is supposed to be an available and operational service, really? > in which > case the policy should cover all reasonable requirements. If it is not > the case (i.e., not an operational or available service), but is still > considered to be under development, not yet needed to be deployed, might > need to be changed to introduce geographical addressing, or whatever > else, then presumably this needs to be made evident and debated in a > different forum. I don't disagree, but: * The current policy will work just fine combined with a production-quality shim6 implementation, complete with full support for traffic-engineering and load-balancing from all vendors. I believe that still is a few years down the road. * Current policies and current v6 technology does not meet requirements from important groups like content providers wrt multi-homing and provider-independence. V6 could make a great p2p network if v6 can help eliminate NAT though ;) To me this mean there's a conflict here. Not only do people disagree wrt how things should be done, but also about what they want to achieve. //per -- Per Heldal http://heldal.eml.cc/ From dr at cluenet.de Wed Jan 18 15:20:25 2006 From: dr at cluenet.de (Daniel Roesen) Date: Wed, 18 Jan 2006 15:20:25 +0100 Subject: [address-policy-wg] Re: Re: 200 customer requirements for IPv6 In-Reply-To: <1137429982.21955.251966941@webmail.messagingengine.com> References: <4396F737.3000400@unfix.org> <200601041112.19341.marc.van.selm@nc3a.nato.int> <1137418715.32453.251951920@webmail.messagingengine.com> <6.2.3.4.2.20060116141211.04d583d8@mail.dante.org.uk> <1137429982.21955.251966941@webmail.messagingengine.com> Message-ID: <20060118142025.GA11398@srv01.cluenet.de> On Mon, Jan 16, 2006 at 05:46:22PM +0100, Per Heldal wrote: > * The current policy will work just fine combined with a > production-quality shim6 implementation, complete with full support for > traffic-engineering and load-balancing from all vendors. Sorry, but please inform yourself about the technical details of shim6 first. There is no provision for traffic engineering in shim6 as we know, use and need it today. As a completely host-centric thing this ain't doable anyway, as a host has no faint clue about how the network is interconnected with others. And the idea of retrofitting such stuff into shim6 outright scares me (and many others). Let the network do it's job. > I believe that still is a few years down the road. No, it's not even on shim6' radar. shim6 is not the droid we're looking for. And we don't even need Obi-Wan to make us believe that. Regards, Daniel -- CLUE-RIPE -- Jabber: dr at cluenet.de -- dr at IRCnet -- PGP: 0xA85C8AA0 From leo at ripe.net Wed Jan 18 15:47:00 2006 From: leo at ripe.net (leo vegoda) Date: Wed, 18 Jan 2006 15:47:00 +0100 Subject: [address-policy-wg] FW: AfriNIC to start allocating from 41/8 Message-ID: <000d01c61c3e$0a099cb0$1d0200c1@FluffyBunny> Dear Colleagues, The announcement below is should be of interest. Regards, -- leo vegoda RIPE NCC Registration Services Manager -----Original Message----- From: afrinic-discuss-bounces at afrinic.net [mailto:afrinic-discuss-bounces at afrinic.net] On Behalf Of Ernest, B.M (AfriNIC - ZA) Sent: 16 January 2006 12:59 To: afrinic-discuss at afrinic.net Cc: ioz at internet.org.za; afnog at afnog.org Subject: [afrinic-discuss] AfriNIC to start allocating from 41/8 Dear Colleagues, As you may be aware, AfriNIC received a 41/8 block from IANA in April 2005. With effect from February 2006, all IPv4 address space allocated within the AfriNIC service region will be made from 41/8. The 196/8 block previously used for allocations in AfriNIC service region will now be used only for direct end-user (PI) assignments. This is therefore a notice that any filters you have may need appropriate adjustments. Kind regards, Ernest, AfriNIC. _______________________________________________ afrinic-discuss mailing list afrinic-discuss at afrinic.net http://lists.afrinic.net/mailman/listinfo.cgi/afrinic-discuss From heldal at eml.cc Wed Jan 18 16:20:10 2006 From: heldal at eml.cc (Per Heldal) Date: Wed, 18 Jan 2006 16:20:10 +0100 Subject: [address-policy-wg] Re: Re: 200 customer requirements for IPv6 In-Reply-To: <20060118142025.GA11398@srv01.cluenet.de> References: <4396F737.3000400@unfix.org> <200601041112.19341.marc.van.selm@nc3a.nato.int> <1137418715.32453.251951920@webmail.messagingengine.com> <6.2.3.4.2.20060116141211.04d583d8@mail.dante.org.uk> <1137429982.21955.251966941@webmail.messagingengine.com> <20060118142025.GA11398@srv01.cluenet.de> Message-ID: <1137597610.26299.252146368@webmail.messagingengine.com> On Wed, 18 Jan 2006 15:20:25 +0100, "Daniel Roesen" said: > Sorry, but please inform yourself about the technical details of shim6 > first. There is no provision for traffic engineering in shim6 as we > know, use and need it today. As a completely host-centric thing this > ain't doable anyway, as a host has no faint clue about how the network > is interconnected with others. And the idea of retrofitting such stuff > into shim6 outright scares me (and many others). Let the network do it's > job. I've read all proposals wrt shim6, mobile-v6 and other intiatives, and I'm not saying any of these is a solution on its own. At the same time there are hooks available for those with the right engineering-spirit to do something about it. If this flies, be sure there will be somone making something to syncronise locator-pair selection-mechanisms among large numbers of hosts in a network. Did session-handling end with TCP? Ever heard about products utilising TCP-functionality? Load-balancers? Firewalls? Any reason to belive that incremental improvements and development doesn't apply to other technologies. However, I did say that this will take years. The current V6 policy needs somthing like this, it's useless without. The polic has to be changed if you want to use V6 just as V4 is used today. Then the principle is simple; anybody that qualify for an assignment in v4 that is globally routable within RIR's prefix-filter-recommendations have to qualify for similar with v6. > > No, it's not even on shim6' radar. Not true. Potential "hooks" for traffic engineering are discussed in current proposals. [tech stuff really belong in the appropriate ietf-groups] > > shim6 is not the droid we're looking for. And we don't even need Obi-Wan > to make us believe that. Agree, if you expect v6 to be immediately ready for general use. //per -- Per Heldal http://heldal.eml.cc/ From gih at apnic.net Wed Jan 18 21:58:10 2006 From: gih at apnic.net (Geoff Huston) Date: Thu, 19 Jan 2006 07:58:10 +1100 Subject: [address-policy-wg] Re: Re: 200 customer requirements for IPv6 In-Reply-To: <20060118142025.GA11398@srv01.cluenet.de> References: <4396F737.3000400@unfix.org> <200601041112.19341.marc.van.selm@nc3a.nato.int> <1137418715.32453.251951920@webmail.messagingengine.com> <6.2.3.4.2.20060116141211.04d583d8@mail.dante.org.uk> <1137429982.21955.251966941@webmail.messagingengine.com> <20060118142025.GA11398@srv01.cluenet.de> Message-ID: <6.2.0.14.2.20060119074754.04543998@localhost> At 01:20 AM 19/01/2006, Daniel Roesen wrote: >On Mon, Jan 16, 2006 at 05:46:22PM +0100, Per Heldal wrote: > > * The current policy will work just fine combined with a > > production-quality shim6 implementation, complete with full support for > > traffic-engineering and load-balancing from all vendors. > >Sorry, but please inform yourself about the technical details of shim6 >first. There is no provision for traffic engineering in shim6 as we >know, use and need it today. You are referring to various forms of routing table abuse of course. > As a completely host-centric thing this >ain't doable anyway, as a host has no faint clue about how the network >is interconnected with others. And yet once you draw further away from the host you run into the issues that we all know and love with NATS and other forms of packet header rewriting at a distance. So as a completely network-centric thing the problem you run into very quickly is how to distinguish assistance from attack. The network has no clue about intentions and all you achieve is a lowered attack threshold. Very useful indeed. > And the idea of retrofitting such stuff >into shim6 outright scares me (and many others). Let the network do it's >job. Depends on your architectural vision - if the network's job is simple lossy connectionless packet forwarding along paths identified by working scaleable routing protocols, then precisely how does TE and other forms of architecture and routing abuse fit into this "job"? :-) > > I believe that still is a few years down the road. > >No, it's not even on shim6' radar. Sorry, but please inform yourself about the details of shim6's agenda first. It is on the radar, and if you wish to contribute then put fingers to the keyboard and send in a draft as to _how_ it could be done. >shim6 is not the droid we're looking for. And we don't even need Obi-Wan >to make us believe that. Usual response: propose an approach, gather interest, call a BOF, formulate a plan, adopt a charter and get to work. Geoff From adrian at ripe.net Tue Jan 24 15:07:28 2006 From: adrian at ripe.net (RIPE NCC Policy Coordinator) Date: Tue, 24 Jan 2006 15:07:28 +0100 Subject: [address-policy-wg] Policy Proposal Withdrawn - 2005-04 Message-ID: <20060124140728.1E5052F583@herring.ripe.net> Dear Colleagues PDP Number: 2005-04 IPv6 Address Allocation and Assignment Policy - Definition for "End-Site" The proposed change to RIPE Document ripe-267 has been withdrawn. You can find the full proposal at: http://www.ripe.net/ripe/policies/proposals/2005-4.html Regards Adrian Bedford RIPE NCC From adrian at ripe.net Thu Jan 26 10:35:11 2006 From: adrian at ripe.net (RIPE NCC Policy Coordinator) Date: Thu, 26 Jan 2006 10:35:11 +0100 Subject: [address-policy-wg] 2005-02 Draft Document will be produced (IP Assignments for anycasting DNS) Message-ID: <20060126093511.65F062F596@herring.ripe.net> PDP Number: 2005-02 IP Assignments for anycasting DNS Dear Colleagues The discussion period for the new RIPE Document described in 2005-02 has ended. A draft document will now be prepared for review. We will publish the document shortly. You can find the full proposal at: http://www.ripe.net/ripe/policies/proposals/2005-2.html Regards Adrian Bedford RIPE NCC From adrian at ripe.net Mon Jan 30 11:59:03 2006 From: adrian at ripe.net (RIPE NCC Policy Coordinator) Date: Mon, 30 Jan 2006 11:59:03 +0100 Subject: [address-policy-wg] 2005-09 New Draft Document Published (IANA Policy for Allocation of IPv6 Blocks to RIRs) Message-ID: <20060130105903.252F72F583@herring.ripe.net> PDP Number: 2005-09 Internet Assigned Numbers Authority (IANA) Policy for Allocation of IPv6 Blocks to Regional Internet Registries Dear Colleagues We have published a draft document for the proposal described in 2005-09. You can find the full proposal at: http://www.ripe.net/ripe/policies/proposals/2005-09.html We encourage you to read the draft document text and send any comments to address-policy-wg at ripe.net before 27 February 2006. Regards Adrian Bedford RIPE NCC From leo at ripe.net Mon Jan 30 14:16:54 2006 From: leo at ripe.net (leo vegoda) Date: Mon, 30 Jan 2006 14:16:54 +0100 Subject: [address-policy-wg] (2005-01) HD-ratio proposal Message-ID: <000701c6259f$70cba5a0$1d0200c1@FluffyBunny> Dear Colleagues, Proposal 2005-01 has been in discussion for a while. The RIPE NCC's Ren? Wilhelm has done an analysis of its possible impact on the consumption of IPv4 address space. The analysis shows an increase in the number of IPv4 addresses allocated. Details of the analysis are available on our web site at: http://www.ripe.net/ripe/policies/proposals/comments/impact_of_hd.html Kind regards, -- leo vegoda RIPE NCC Registration Services Manager From Michael.Dillon at btradianz.com Mon Jan 30 16:22:18 2006 From: Michael.Dillon at btradianz.com (Michael.Dillon at btradianz.com) Date: Mon, 30 Jan 2006 15:22:18 +0000 Subject: [address-policy-wg] (2005-01) HD-ratio proposal In-Reply-To: <000701c6259f$70cba5a0$1d0200c1@FluffyBunny> Message-ID: > Details of the analysis are available on our > web site at: > http://www.ripe.net/ripe/policies/proposals/comments/impact_of_hd.html I think you gave out the wrong URL. All I can find at that address is a brief summary. Where is the detailed analysis? --Michael Dillon