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

Final Reminder: RIPE NCC Regional Meeting Qatar, 17-18 January 2006
by Paul Rendek 03 Jan '06

03 Jan '06

[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: <contact(a)ripe.net> Regards, Paul Rendek Head of Member Services & Communications RIPE NCC

1 0

2005 IPv4 Address Use Report
by Iljitsch van Beijnum 01 Jan '06

01 Jan '06

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

1 0

Re: [ipv6-wg] IPv6 PI
by Roger Jorgensen 31 Dec '05

31 Dec '05

On Mon, 21 Nov 2005, Lea Roberts wrote: <snip> > the problem with using ASNs is that when you think over the projected > lifetime of IPv6, there will be *lots* of ASNs. Note that the 4-byte ASN > draft is entering the standards track in IETF. Don't think that tying PI > to ASNs is anything more that passing the problem to the next generation > (if that long... :-) > > It would seem obvious that as network connectivity becomes essential for > doing business, it must be reliable. It is unwise to carry forward the > IPv4 multi-homing model for network resilience with just faith that the > system will be able to scale to an ever larger number of routes. IPv6 has > so far failed to deliver on its original promise of seamless renumbering > and multi-homing using multiple prefixes. The hard problems still need to > be solved in a way that can scale for decades to come. Can't we all just drop using the word multihoming and IPv6 PI? They all reflect back to how thing was done with IPv4 and those ways are doomed to fail with IPv6 simply due to the size of the IP space. Last I checked around there were some promissing new proposal on the way for how to solve this very basic problem. And in the meantime, drop the thought about multihoming and PI space, start to think about other ways to use the possibility IPv6 give us. Just to mention maybe the biggest advantage, we have that extended header part of IPv6, it give us endless possibilities. and yes I do have some idea about how it can be done but no one really bother to consider geo-based IP's either so... :) Not to forget it quite likely will undermine the entire business case for how ISP's today operate. -- ------------------------------ Roger Jorgensen | rogerj(a)stud.cs.uit.no | - IPv6 is The Key! http://www.jorgensen.no | roger(a)jorgensen.no -------------------------------------------------------

28 123

New IPv6 Address Block Allocated to the RIPE NCC
by filiz＠ripe.net 31 Dec '05

31 Dec '05

[Apologies for Duplicates] Dear Colleagues The RIPE NCC received the IPv6 address range 2A01:0000::/16 from the IANA in December 2005. 2A01:0000::/23 was allocated to the RIPE NCC in July 2005. This latest range includes that previous allocation. You may wish to adjust any filters you have in place accordingly. You can find more information about the IP space administered by the RIPE NCC on our web site at: https://www.ripe.net/ripe/docs/ripe-ncc-managed-address-space.html Regards, Filiz Yilmaz RIPE NCC

5 5

2005-01 New Draft Document Published (HD-ratio proposal)
by RIPE NCC Policy Coordinator 30 Dec '05

30 Dec '05

PDP Number: 2005-01 HD-ratio proposal Dear Colleagues We have published a draft document that proposes a change to RIPE Document ripe-324. You can find the full proposal at: http://www.ripe.net/ripe/policies/proposals/2005-1.html We encourage you to read the draft document text and send any comments to address-policy-wg(a)ripe.net before 27 January 2006. If you have not yet signed up for the Policy Announcement Mailing List, you can do this by going to: http://www.ripe.net/mailman/listinfo/policy-announce Regards Adrian Bedford RIPE NCC Policy Coordinator

1 0

2005-12 New Policy Proposal (4-Byte AS Number Policy Proposal)
by RIPE NCC Policy Coordinator 29 Dec '05

29 Dec '05

PDP Number: 2005-12 4-Byte AS Number Policy Proposal Dear Colleagues A new RIPE policy has been proposed and is now available for discussion. You can find the full proposal at: http://www.ripe.net/ripe/policies/proposals/2005-12.html We encourage you to review this proposal and send your comments to <address-policy-wg(a)ripe.net> before 22 January 2006. After this date, we will prepare a draft RIPE Document. We will let you know when this is available. Kind regards, -- leo vegoda RIPE NCC Registration Services Manager

3 4

Updated Information: RIPE NCC Regional Meeting Qatar, 17-18 January 2006
by Paul Rendek 20 Dec '05

20 Dec '05

[Apologies for duplicate e-mails] Dear Colleagues, There is still time to register for the RIPE NCC Regional Meeting taking place in Doha, Qatar, on 17-18 January 2006. This Regional Meeting is specifically designed to provide participants with a forum to discuss topics related to IP networking in the Middle East region. The draft meeting agenda is available at: http://www.ripe.net/meetings/regional/qatar-2006/agenda.html RIPE NCC IP RESOURCE ANALYSTS During the meeting, RIPE NCC IP Resource Analysts will be available for members to discuss issues relating to their business face-to-face with RIPE NCC staff. For more information, or to schedule an appointment with one of the RIPE NCC IP Resource Analysts, please see: http://www.ripe.net/meetings/regional/qatar-2006/ip-resource-analysts.html SEMINARS All meeting attendees are also invited to attend the two RIPE NCC seminars, the DNSSEC Seminar and the Routing Registry Seminar. Both seminars will take place on Tuesday 18 January, from 14:00. - The DNSSEC Seminar outlines the features of DNSSEC and related tools and to introduce 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). REGISTRATION If you have not yet registered for the RIPE NCC Regional Meeting in Doha, Qatar, please register at: www.ripe.net/qatar2006/register 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 will close on Friday, 13 January 2006. MORE INFORMATION More information about the RIPE NCC Regional Meeting in Qatar is available at: http://www.ripe.net/qatar2006 Any questions can be sent to: <contact(a)ripe.net> Regards, Paul Rendek Head of Member Services & Communications RIPE NCC

1 0

Draft minutes: RIPE 51 Address Policy WG session
by leo vegoda 20 Dec '05

20 Dec '05

Dear Colleagues, Draft minutes from the Address Policy Working Group session at RIPE 51 can be found at: http://www.ripe.net/ripe/wg/address-policy/r51-minutes.html Please check the minutes for errors or omissions. Comments and corrections can be sent directly to this list or to one of the WG chairs personally. Additionally, archives of the webcast can be found at: mms://webcast.ripe.net/ripe-51/ap.wmv http://www.ripe.net/ripe/meetings/ripe-51/webcast-files/ap.wmv There is also a copy of the Jabber/IRC session available at: http://www.ripe.net/ripe/meetings/ripe-51/feedback/ap.txt Kind regards, -- leo vegoda RIPE NCC Registration Services Manager

1 0

HD ratio - 2005-01
by BOURASSEAU Maryline ROSI/DAS 15 Dec '05

15 Dec '05

I confirm that France Telecom supports the IPV4 HD-Ratio proposal (Policy proposal 2005-01) Regards. Maryline Bourasseau LIR - fr.telecom ******************************** Ce message et toutes les pieces jointes (ci-apres le "message") sont confidentiels et etablis a l'intention exclusive de ses destinataires. Toute utilisation ou diffusion non autorisee est interdite. Tout message electronique est susceptible d'alteration. Le Groupe France Telecom decline toute responsabilite au titre de ce message s'il a ete altere, deforme ou falsifie. Si vous n'etes pas destinataire de ce message, merci de le detruire immediatement et d'avertir l'expediteur. ********************************* This message and any attachments (the "message") are confidential and intended solely for the addressees. Any unauthorised use or dissemination is prohibited. Messages are susceptible to alteration. France Telecom Group shall not be liable for the message if altered, changed or falsified. If you are not the intended addressee of this message, please cancel it immediately and inform the sender. ********************************

1 0

ETNO and ETNO Member participation in RIPE Address Policy WG
by Debecker J.L. 07 Dec '05

07 Dec '05

Hans Petter Holen Chairman RIPE Address Policy WG Dear Mr. Holen, Thank you for your e-mail dated 7 November seeking clarification about ETNO's input by means of our Expert Contribution EC064 on IPv4 address space allocation. Attached and below you will find a reply message from Michael Bartholomew, ETNO Director. In summary our views are that: - individual ETNO Members contribute substantially to RIPE and they are encouraged by the Association to do so - ETNO fully recognises and supports RIPE, its committees and decisions - ETNO actively participates in RIPE activities and contributes among others by inputting the collective, formally approved views of 41 operator companies - which would probably be difficult to match by means of direct participation. Best regards, Leo Debecker Executive Manager, Operations ------------ Hans Petter Holen, Chairman RIPE Address Policy WG Dear Sir, Thank you for the e-mail you sent to the RIPE Address Policy WG mailing list on 7 November and the concerns you expressed as RIPE Address Policy WG Chairman. ETNO (1) believes it would be of use to explain the rationale behind the IPv4 address space allocation contribution that you refer to. As you are aware, ETNO represents 41 major telecommunications operators from 34 European countries. Its Members participate in about 20 ETNO working groups addressing common areas of specific interest. One of these deals with Naming, Numbering and Addressing Issues (NANI WG) from a policy perspective. Its participants have recognised expertise in relevant policy issues, but are not necessarily involved in the day-to-day management of IP Addresses. The NANI WG is an important forum to discuss common E164 and IP related policy areas of specific interest to ETNO's membership. ETNO views are expressed in position papers, which are approved by its Members using formal processes and documented rules. These position papers are publicly available on ETNO's web site. It should be stressed that ETNO Members represent a significant share of large and extra large registries in Europe. These registries follow all the processes and policies issued by RIPE. In addition, ETNO Members rely on commonly and formally agreed ETNO position papers to provide input into the RIPE community. There is thus two-way interaction between RIPE and individual ETNO Members. As for ETNO itself: the Association and its Members are committed to contribute to the RIPE community, with the participation of an ETNO representative in RIPE meetings who disseminates feedback to ETNO Members. As mentioned, some ETNO Members participate at RIPE meetings as company representatives. ETNO encourages its Members to actively participate in RIPE. RIPE is the forum dealing with Address Policy issues for the RIPE region that includes Europe, and ETNO supports this through its contributions and participation. IP Addressing has become a major issue in recent years as all ETNO Members have established ISPs. IP addressing will increase in importance in the future as operators move towards the introduction of Next Generation Networks (NGN). In the past ETNO has adopted a number of positions on IP addressing policy issues, the last one being on the IPv4 HD ratio issue, which was unanimously approved. ETNO's position was communicated to the RIPE community through the RIPE Address Policy WG mailing list. This shouldn't be thought of as challenge to RIPE and it's working methods but as a supportive input. ETNO is of the opinion that by engaging within the RIPE community, delivering the joint concerns of its 41 Members and assisting in the development of an appropriate IP address policy, we act to the benefit all interested stakeholders - a role which ETNO is happy to fulfil. Yours sincerely, Michael Bartholomew, ETNO Director (1) ETNO (European Telecommunications Networks Operators' Association) is the recognised voice of the European Telecommunications network operators with over a decade of experience in shaping EU telecoms policy. The association represents 41 companies from 34 European countries. They account for an aggregate turnover of more than 210 billion Euros within Europe and employ more than one million people. The association is widely recognised for its expertise on various topics including technical and regulatory matters, but also issues such as network naming and addressing, environmental protection, sustainability and network security. An indication of the scope of issues and the work undertaken by ETNO can be demonstrated by the information on its web site (www.etno.be).

1 0

Re: [ipv6-wg] a consensus, about what?
by peter.sherbin＠bell.ca 06 Dec '05

06 Dec '05

>Date: Tue, 6 Dec 2005 09:43:56 +0100 (CET) >From <rogerj(a)jorgensen.no> >To: Gert Doering <gert(a)space.net> > cc: address-policy-wg(a)ripe.net, ipv6-wg(a)ripe.net > Subject: [ipv6-wg] a consensus, about what? <snip> >so what sort of consensus are we aiming for...? A new policy >for AS, a net block, routing policy, multihoming, or just IPv6 in general? >...quite a lot of topics have been discussed ... but what are our goal with all this? Get rid of the current hierarchy which requires ISP in order to connect to the network. The Internet is an aggregation of interconnected networks. We want to replicate what the Mother Nature has already given us, i.e. a brain like structure where neurons (individual networks) have multiple direct connections with each other. As brain cells networks should have about the same size. Network prefix determines the size. Peter Sherbin Bell Canada

2 1

AW: [ipv6-wg] Re: Re: [address-policy-wg] Re: Andre's guide to fi x IPv6
by Bonness, Olaf 06 Dec '05

06 Dec '05

Hi Gerd, > -----Ursprungliche Nachricht----- > Von: Gert Doering [mailto:gert@space.net] > Gesendet: Montag, 5. Dezember 2005 18:07 > An: Kurt Erik Lindqvist > Cc: Cameron C. Gray; Per Heldal; address-policy-wg(a)ripe.net; > ipv6-wg(a)ripe.net > Betreff: Re: [ipv6-wg] Re: Re: [address-policy-wg] Re: > Andre's guide to > fix IPv6 > > > Hi, > > On Mon, Dec 05, 2005 at 02:17:25PM +0100, Kurt Erik Lindqvist wrote: > > I think each LIR should get a /32 and we should drop the 200 > > "customer" rule. But that is just me... > > Actually I like the "every AS should get a <network>" approach (with > a yearly recurring fee for AS and network, to guarantee return of the > resources as soon as the importance of having a slot in the global > routing table doesn't outweigh the costs anymore). > > "Every LIR gets a /32 (upon request), no questions asked" is a concept > that I'm also happy with - as I have said before. For those that are > afraid of the landrush: limit that policy to 5.000 LIRs per region. Not sure if that works. Kind of "First come - first serve" thing. Regards Olaf > Gert Doering > -- NetMaster > -- > Total number of prefixes smaller than registry allocations: 81421 > > SpaceNet AG Mail: netmaster(a)Space.Net > Joseph-Dollinger-Bogen 14 Tel : +49-89-32356-0 > D- 80807 Muenchen Fax : +49-89-32356-234 >

4 7

RIPE NCC Regional Meeting, Qatar, 17 - 18 January 2006: Updates to Agenda
by Paul Rendek 06 Dec '05

06 Dec '05

[Apologies for duplicate e-mails] Dear Colleagues, A revised agenda for the RIPE NCC Regional Meeting in Doha, Qatar (17 - 18 January 2006), is now available at: http://www.ripe.net/meetings/regional/qatar-2006/agenda.html This meeting is specifically designed to provide participants with a forum to discuss topics related to IP networking in the region. Topics on the agenda include: - A review of the World Summit on the Information Society (WSIS) and the way forward - IPv4 exhaustion and IPv6 consumption - Site Multihoming by IPv6 Intermediation (Shim6) - Internet security and new developments in Internet routing - The RIPE Policy Development Process (PDP) - RIPE NCC training seminars on Routing Registry and DNSSEC. The meeting will also feature demonstrations of services such as the Routing Information Service (RIS), BGPlay and Test Traffic Measurements (TTM) that help users analyse network behaviour. More information about these demonstrations is available at: http://www.ripe.net/meetings/regional/qatar-2006/demos/index.html In addition, RIPE NCC IP Resource Analysts will be at the meeting to answer any questions about IPv4 / IPv6 allocations and assignments. REGISTRATION 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 now open. Registration will close on Friday, 13 January 2006. To register, please see: http://www.ripe.net/qatar2006/register PRESENTATIONS FROM THE LOCAL COMMUNITY We have reserved space in the agenda for presentations from the local community on current issues affecting the region. If there is a particular presentation or topic you would like included in the agenda, please send your suggestion to: <contact(a)ripe.net> MORE INFORMATION More information about the RIPE NCC Regional Meeting in Qatar is available from: http://www.ripe.net/qatar2006 Any further questions can be sent directly to: <contact(a)ripe.net> Regards, Paul Rendek Head of Member Services & Communications RIPE NCC

1 0

De-aggregation of assigned IPv6 prefixes?
by Jeroen Massar 06 Dec '05

06 Dec '05

Hi, http://www.ripe.net/ripe/docs/ipv6policy.html#initial_criteria reads amongst others: 8<------------------- c) plan to provide IPv6 connectivity to organisations to which it will assign /48s by advertising that connectivity through its single aggregated address allocation -------------------->8 According to the above, after the /48, can one announce more specifics or should/must one not do this? (*) The RIPE Registry allows registering more specific route6 objects. If this is allowed, then why is the above parrt, after '/48', then included in the policy? What is the exact intention of the sentence? Greets, Jeroen *= of course one is lord of their own network and thus can announce whatever one wants and just hope/agree that others accept it.

4 3

Dynamic or
by Olav Noergaard 05 Dec '05

05 Dec '05

Are there a difference between what IP-addresses can be uset for, like some are only for dynamic addresses and some are for stationary addresses, and if there are a difference, where can I see that? -- Olav

2 1

Re: [ipv6-wg] Re: Re: [address-policy-wg] Re: Andre's guide to fix IPv6
by Max Tulyev 02 Dec '05

02 Dec '05

> Last time I was a hosting proivider I signed up as a LIR and built my > own network infrastructure to the nearest IX points. > This time I have outrourced the lot and my 300 server serverfarm is > behind a firewall on a handfull of IP addresses > > Changing ISP is really easy? > Yes. Stop. You have 10000 domains. You have IP address(es) from ISP A . You are moving to ISP B with OTHER address(es). And you don't need to send 10000 modify requests for these 10000 domains to change A (NS, MX) records. Where is the magic? ;-) > > To be a LIR and grab /20 if really need only /28? > Depends. Today I manage with a /23 PI or PA? Your own or upstream's? -- WBR, Max Tulyev (MT6561-RIPE, 2:463/253@FIDO)

2 1

Re: [ipv6-wg] Re: Re: [address-policy-wg] Re: Andre's guide tofix IPv6
by Randy Bush 01 Dec '05

01 Dec '05

[ something did some horrifying things to the header of your mail as i received it, in particular the references: line, see appended. so i had to chop the refs off my reply. apologies to those who thread based on it. ] > I might totaly missunderstand you, but I get the feeling you want > us to go back to the root of the IPv6 discussion when it all was > started and use some of the stuff that was done before instead of > trying to figure it all out again? yep. though, since i come from the perspective of living it all these years, the "go back" part is a recent view :-). i.e. sane operational folk have been sining this song for years. there has been an amazing lack of ears listening to it. randy --- line breaks are not from here! References: <Pine.LNX.4.56.0511211704050.10258(a)chandra.student.uit.no><87slt m3p3n.fsf(a)mid.deneb.enyo.de><Pine.LNX.4.56.0511251013060.10258(a)chandra.stud ent.uit.no><4386E053.73B661B3(a)networx.ch><43886509.6060600(a)unfix.org><87acf r1mjl.fsf(a)mid.deneb.enyo.de><002f01c5f43a$12631110$44eea2d5@l><6.2.0.14.2.2 0051129101355.02919160(a)kahuna.telstra.net><87fypfpm1e.fsf(a)mid.deneb.enyo.de ><6.2.0.14.2.20051130053430.02d015d0(a)kahuna.telstra.net><20051130161647.GA1 2947(a)srv01.cluenet.de><08D2E092-8FB3-4C5D-9837-4433C77F0B46(a)kurtis.pp.se><1 7294.55288.858722.708230(a)roam.psg.com><6.2.0.14.2.20051202045722.02de10b0@k ahuna.telstra.net> <17295.18210.797714.378814(a)roam.psg.com>

1 0

unsubscribe jkuijer@dds.nl
by jkuijer＠dds.nl 29 Nov '05

29 Nov '05

Citeren address-policy-wg-request(a)ripe.net: > Send address-policy-wg mailing list submissions to > address-policy-wg(a)ripe.net > > To subscribe or unsubscribe via the World Wide Web, visit > http://www.ripe.net/mailman/listinfo/address-policy-wg > or, via email, send a message with subject or body 'help' to > address-policy-wg-request(a)ripe.net > > You can reach the person managing the list at > address-policy-wg-admin(a)ripe.net > > When replying, please edit your Subject line so it is more specific > than "Re: Contents of address-policy-wg digest..." > > > Today's Topics: > > 1. Re: Re: [ipv6-wg] IPv6 PI (Randy Bush) > 2. Re: Re: [ipv6-wg] IPv6 PI (Andre Oppermann) > > --__--__-- > > Message: 1 > From: Randy Bush <randy(a)psg.com> > Date: Mon, 28 Nov 2005 21:49:17 -1000 > To: Salman Asadullah <sasad(a)cisco.com> > Cc: Roger Jorgensen <rogerj(a)jorgensen.no>, > Oliver Bartels <oliver(a)bartels.de>, > "ipv6-wg(a)ripe.net" <ipv6-wg(a)ripe.net>, > "address-policy-wg(a)ripe.net" <address-policy-wg(a)ripe.net>, > roger(a)jorgensen.no > Subject: Re: [address-policy-wg] Re: [ipv6-wg] IPv6 PI > > > Lots of efforts (Multi6, SHIM6, etc.) are being made to solve these real > > issues for a good reason. > > i gather that the message that leslie daigle was given at the > last nanog was not well-transmitted to the ietf. no big > surprise. > > you may want to look at http://nanog.org/mtg-0510/real/ipv6-bof.ram > > randy > > > --__--__-- > > Message: 2 > Date: Tue, 29 Nov 2005 10:13:39 +0100 > From: Andre Oppermann <oppermann(a)networx.ch> > To: Salman Asadullah <sasad(a)cisco.com> > CC: Roger Jorgensen <rogerj(a)jorgensen.no>, > Oliver Bartels <oliver(a)bartels.de>, > "ipv6-wg(a)ripe.net" <ipv6-wg(a)ripe.net>, > "address-policy-wg(a)ripe.net" <address-policy-wg(a)ripe.net>, > roger(a)jorgensen.no > Subject: Re: [address-policy-wg] Re: [ipv6-wg] IPv6 PI > > Salman Asadullah wrote: > > > > You seem to be far away from the ground realities. > > > > Lots of efforts (Multi6, SHIM6, etc.) are being made to solve these real > > issues for a good reason. > > Neither Multi6 nor SHIM6 are even in an draft RFC state yet and to be > workable they'd have to be implemented on every end-host out there. > That is every operating system in sufficient existence. That puts IPv6 > even further in the already distant future considering common OS upgrade > and replacement cycles. > > Second this doesn't solve the renumbering problem. Renumbering is not > just giving hosts new IP addresses but alost managing DNS and Firewalls. > No even remotely workable and scaleable solution has been presented yet. > > So nice try but no cookie. > > -- > Andre > > > > Regards, > > Salman > > > > At 10:55 AM 11/25/2005 +0100, Roger Jorgensen wrote: > > > > > On Thu, 24 Nov 2005, Oliver Bartels wrote: > > > > On Mon, 21 Nov 2005 17:10:10 +0100 (CET), Roger Jorgensen wrote: > > > <snip> > > > > If IPv4 offers PI = provider _independence_ and multihoming > > > > and IPv6 doesn't, then IPv4 is obviously the better solution for > > > > those who requires this functionallity. > > > > > > > > Thus they won't use IPv6. > > > > > > > > Please keep in mind: The _customer_ votes, not you, not me. > > > > > > > > And as the majority of the large and a significant portion of medium > > > > size businesses are obviously not willing to accept an IP protocol not > > > > providing this functionallity, IPv6 will remain at it's current status: > > > > > > > > A technical playground for technically interested people. > > > > > > a very true point in one way but that is again as I see it, we're still > > > thinking IPv4 when talking IPv6. > > > > > > Why do they need multihoming and PI? They don't trust the ISP and vendors > > > to deliver them uptime and freedom... isn't this a problem the ISP and > > > vendors should try to solve? Of course, the idea of easy renumbering was > > > suppose to solve this but again, we're thinking IPv4 so it's not easy to > > > understand. > > > > > > Again, we don't need PI space and multihoming, what we need are a way to > > > give the users and GOOD connectivity (uptime, speed etc) and make it easy > > > for them to switch providers as they see fit. > > > > > > > > > > > > <snip> > > > > > > > > Hmm, please let me translate: > > > > "Even if the car doesn't drive and the engine doesn't deliver a single > > > > horse power at the wheels, drop the thought about driving, > > > > start to think about other way to use the possibility this great car > > > > gives us." > > > > > > > > Sound like newspeak: > > > > If we _think_ we can't solve the problem, drop discussing the problem. > > > > > > for several years this discussion have been going on, still no real > > > solution. IPv6 give us the freedom todo ALOT of things, USE those > > > possibilities, if we have to change how IP are done, some TCP headers > etc, > > > then do it... propose a good idea and prove it. That could give us > > > multihoming. Actually there is a master thesis about howto create > > > connectivity for TCP session even if one of the links went down, the > > > session just used another IP (1)... the user don't notice anything > > > either and it have zero problem working with standard tcp-stacks since it > > > use the extended header of IPv6. > > > > > > That's just ONE of many possible ways... > > > > > > > > > > > > (1) it's a master thesis writting by a student related to University of > > > TromsÃ¸ as part of the Pasta project, www.pasta.cs.uit.no > > > > > > -- > > > > > > ------------------------------ > > > Roger Jorgensen | > > > rogerj(a)stud.cs.uit.no | - IPv6 is The Key! > > > http://www.jorgensen.no | roger(a)jorgensen.no > > > ------------------------------------------------------- > > > > > End of address-policy-wg Digest >

1 0

RIPE NCC Reappoints Wilfried Woeber as NRO NC Member
by Axel Pawlik 28 Nov '05

28 Nov '05

Dear Colleagues, The RIPE NCC Executive Board has reappointed Wilfried Woeber to the Number Resource Organization (NRO) Number Council as a representative of the RIPE NCC region. Under the terms of the Memorandum of Understanding (MoU) signed between ICANN and the Regional Internet Registries (RIRs) in October 2004, the NRO Number Council (NRO NC) now performs the role of the Address Supporting Organization Address Council (ASO AC). The term of Mr. Woeber's appointment is from 1 January 2006 to 31 December 2008. Mr. Woeber has previously served on the NRO NC as an interim member during 2005 and on the Address Council under the previous ASO structure, from January 2003 to December 2004. More information about the NRO Number Council is available at: http://www.nro.net/about/number-council.html Regards, Axel Pawlik Managing Director RIPE NCC

1 0

RE: [address-policy-wg] Re: [ipv6-wg] IPv6 micro allocation or so mething else?
by Koepp, Karsten 23 Nov '05

23 Nov '05

Hi all, I also followed the discussion, not stepping in here because of no background in TLD operations. Getting a bit frustrated as I see NO movement here. Unlike others, I do see dns being _critical_ to the infrastructure. No other protocol is that much subject of political discussions. As an operator being dependent on TLD operations I want to see a stable operations of the dns tree. Consequently I support giving the TLD operators the tools they need to make it a stable service. I have read an _expressed need_ of the tld community for anycast where I have not seen any constructive proposal against. Hence I have to ACCEPT that large TLDs need it. It brings us no step further towards a stable dns chain if we deny this. What is the impact onto my network if I accept to grant special resources to this need? I can see hardly any besides at most 200 prefixes polluting the DFZ. I can question whether the anycast allocations should be /32 or /48 or something else. It doesn't make a difference in terms of resources stressing my network provided I have a finite number of objects here. Operationally I believe /32 assignments are more stable, so I tend handing out /32 to TLD operators. Current policy does not allow to allocate routeable blocks to TLDs, so we have to change the policy. Before you start flaming I do not regard this opening the flooding gates, as I don't see the flood. TLD operators are being defined as critical infrastructure. It can be decided case by case to allow further infrastructure - by the RIPE members, but I haven't seen such case yet. Let it be xyz.com, have they ever claimed a need for themselves? regards Karsten > -----Original Message----- > From: Mohsen Souissi [mailto:Mohsen.Souissi@nic.fr] > Sent: Thursday, November 17, 2005 11:51 AM > To: Florian Weimer > Cc: address-policy-wg(a)ripe.net; ipv6-wg(a)ripe.net > Subject: Re: [address-policy-wg] Re: [ipv6-wg] IPv6 micro > allocation or > something else? > > > Florian & all, > > On 16 Nov, Florian Weimer wrote: > [...] > | It depends on the PI criteria. If slots in the global > routing tables > | are kept in short supply *and* you get at most one if you aren't an > | ISP *and* you need to do IPv6 anycast, you might have a problem > | because you need two globally visible prefixes (one for your > | production network, one for anycast). > | > | But I think you are right that it makes sense to resolve > the PI first, > | either negatively or positively. > > ==> This is just amazing! I have been follwing this topic for more > than two years and I have the feeling that we are making again and > again the history! I remember that when the IPv6 "PI" issue was first > raised in the IPv6/LIR wgs ("LIR" was the old name for "AP" at that > time), the answer was "PI is out of scope of this wg". Then came the > first draft proposel of Andreas in the AP wg asking for a /32 for > ccTLDs wishing to deploy anycast. At that time, the wg said "let's not > talk about "PI", which is still out of scope of this wg. Let's rather > talk about specific needs of TLDs wishing to do anycast and see what > we can do for them in termes of (micro-)allocation." > > Now, I'm surprised that we are going back to the original issue and > asking to first solve the PI problem... > > If that's to be done and while we ar at it, we can see again how RIPE > is the only RIR not considering TLD networks as "critical > infrastructure" while an appropriate policy has been already > implemented in all other existing RIRs for a long while (please > revisit the comparative matrix of RIR policies at > http://www.ripe.net/info/resource-admin/rir-comp-matrix-rev.html and > see how RIPE is lagging behind in this matter. Some of this > mailing-list member would say: "that was our choice!"). Isn't it a > European speciality to discuss over again and again issues without > coming to any solution? Some people on RIPE mailing-lists are now > used to coming after a consensus is almost reached and try to break > everything just for the sake of building CLEAN solutions... > > (cc)TLD need an allocation (whether it is a /32 or whatever "routable > prefix") because they need to do anycast, full stop. To recall only a > few of the arguments for deploying anycast for a TLD, I would say: > Redundance & Resilience against DDoS attacks, better global time > response, a greater flexibility in adding and removing name servers > without notifying IANA! > > Btw, I'd like to remind some of this mailing-list readers that the > request of DENIC is not isolated since AFNIC asked even before > Adndreas first draft for a constency between all RIRs in the way IPv6 > allocation were made for "critical infrastructure". AFNIC has then > strongly supported Andreas proposal from the beginning and hoped that > the solution would come rapidly because AFNIC is still needing such a > solution to start deploying anycast in IPv4 AND in IPv6 in a > consistent way! > > I still hope this debate will lead to a concrete solution within the > coming 3 years! > > Good luck :-) > > Mohsen. > >

6 7

IPv6 micro allocation or something else?
by Mohacsi Janos 22 Nov '05

22 Nov '05

Dear All, I have a question regarding the IPv6 address assignment to cc level DNS server. If you don't have answer to this question please forward it to an appropriate working group - sorry for cross-posting this mail to two wg. We have here in Hungary a dilemma: - Traditionally, the IPv4 address of the primary cc level DNS server in of belonged to NIIF/HUNGARNET. - The DNS registration service a while ago was delegated to Council of Hungarian Internet Providers (ISZT) who is also operating the biggest Internet Exchange of Hungary (BIX). All big ISPs in Hungary (including NIIF/HUNGARNET) has right to do the registration via a special interface. - The IPv4 address of the primary cc level DNS server announced by NIIF/HUNGARNET. But ISZT is reorganizing its infrastructure to allocate address from a new PI type IPv4 address space to DNS servers. - The primary hu DNS server is connected to BIX - to be well connected. What IPv6 address space should we allocate to hu primary DNS server? 1. Assign IPv6 address from /32 address space of NIIF/HUNGARNET? - not very optimal since the only transit to hu primary will be NIIF/HUNGARNET - not ISP neutral - easy, no problem from point of view of NIIF/HUNGARNET 2. Assign IPv6 address space from /48 allocated to BIX (based on ripe-256 and ripe-310)? - According to the RIPE documents: "Networks assigned under this policy may not be globally routable" - which problematical since primary DNS servers should be globally reachable. 3. Allocate multiple /48 from IPv6 providers in HUNGARY to primary hu DNS server? - This can be problematical since the answers to DNS queries might be quite big. 4. Allocate /48 to primary hu DNS server that is globally routable? Are there similar to /48 from 2001:0500::/30 in RIPE region? - I think this is the cleanest solution. Can we discuss this issue on the working group or mailing lists? I saw a proposal: http://www.ripe.net/ripe/policies/proposals/2005-2.html In my opinion this can solve the problem.... Best Regards, Janos Mohacsi Network Engineer, Research Associate NIIF/HUNGARNET, HUNGARY Key 00F9AF98: 8645 1312 D249 471B DBAE 21A2 9F52 0D1F 00F9 AF98

19 59

Re: [address-policy-wg] 200 customer requirements for IPv6
by Thomas Narten 18 Nov '05

18 Nov '05

> To all the nay-sayers and ignorants in the die-hard IPv6 camp I can only > recommend that they put yourself into the shoes of a large coporation > with 10,000 employees for a day. How many 10K employee organizations exist in the world today (or in ten years)? How many routing prefixes would be required in the DFZ to support this? Can the routing infrastructure handle that? If there were consensus that the answer to the above questions was "yes, it's manageable", I'm sure folk would support a modified policy to that effect in a heartbeat. But in the absence of some real data showing the implication of loosening the policy to allow the above, many (myself include) will be very concerned about the consequences of doing this. Thomas

2 1

Re: [ipv6-wg] Re: 200 customer requirements for IPv6
by Thomas Narten 18 Nov '05

18 Nov '05

Daniel Roesen <dr(a)cluenet.de> writes: > The folks all having their own /32 already allocated to them and > trying to limit independent address space to "service providers" (or > those who manage to pretend being it, which seems to be easy) are > still arguing for "not for them!" paradigm - easy position with > having their own dishes already done. With all due respect, these sorts of comments are not helpful. They imply bad motivations on some, that IMO, are simply false. There are (IMO) valid reasons for not giving out /32s to everyone. The original (and still compelling, IMO) rational behind the current policy is to ensure good aggregation for the long term, in order to keep the number of distinct prefixes in the DFZ manageable. Hence, the current policy is oriented not towards _all_ ISPs, but those who will (hopefully) have _many_ customers that they assign addresses too. That is, they aggregate addresses for _many_ customers. That is where the "plan for 200 customers" wording originally came from. The presumption is that an ISP/LIR that realistically expects to have 200 customers will be aggregating _many_ customer addresses. If an ISP will have (say) only 100 customers long term, its not at all clear that they will be aggregating significant amounts of address space. Note, I'm not defending the the "200 customer" rule per se; I understand that it is viewed as problematic. But I think the motivation that led to it is still valid, and when folk say "get rid of this requirement," I object to "forgetting" about the original concern when coming up with a replacement policy. > Until we have a clear full replacement (that means a solution which does > NOT ignore real requirements like shim6 does) there should be a very > simple PI policy which issues a /48 or whatever to end sites at a > nominal small fee, paid directly to the RIR. An initial setup fee and a > yearly renewal fee, paid by credit card or something equally simple. > No payment => assignment withdrawn. The initial fee covering the cost of > evaluation of the request, doing the assignment and setting up the > billing account and DNS reverse. The yearly fee covering the maintenance > of the entries in the database and DNS rev NS RRset and the yearly > recurring fee invoicing/billing. Done. Note that ARIN has been and continues to have discussions about how to give out PI space to end sites, but in a way that doesn't explode the routing tables going forward. I think there is (very strong) support for the idea of giving out more PI space, the difficulty has been in coming up with details that people are comfortable won't explode the routing tables going forward. I.e., that in five years we look back and say "oops, we should not have done that, now what do we do" > Setting aside my disbelieve in the FUD about the scalability problem of > real BGP multihoming (noone yet has shown that the relative amount of > multihomers does or will explode), Um, do the math. How many end sites do you think will want to multihome ten years from now? Can you honestly/realistically say it won't be a million? Can the routing infrastructure handle that? (Enough people say "not sure" that IMO it would be foolish to just assume we can do this). Thomas

3 2

Fwd: 2005-01 One Week to End of Discussion Pe riod: HD Ratio for IPv4
by Erics 18 Nov '05

18 Nov '05

Hi all, i confirm that Deutsche Telekom still supports the FT proposal to establish the IPv4-HD-Ratio, because this is a good instrument for LIRs to manage the demand of address space. Especially in view of their internal topologies. kind regards Eric Schmidt - for LIR de.telekom

1 0

Re: [address-policy-wg] 200 customer requirements for IPv6
by Thomas Narten 18 Nov '05

18 Nov '05

> On Thu, 17 Nov 2005, Tim Streater wrote: > > The other network is one we are *currently* managing, EUMEDCONNECT. > > It is for the Middle-eastern and North African NRENs. The intention > > here is that we expect these NRENs to set up their own entity to > > manage it, and go their own way, in which case we gift them the > > infrastructure, which in this case has to include the address space. > > We can do that for v4 as I got PI space for that. Its v6 that is the > > problem. > Did you actually *try* getting a separate /32 for this? > RIPE NCC is known to be very reasonable towards transit networks, and > I could bet good money you could get an allocation without a hitch. I don't think the Right Answer is always to say "did you try and did you get rejected"? I believe the current IPv6 policies are aimed at LIRs that delegate address space to other users/isps/customers (i.e., that is the group the are the main focus). It is not immediately clear to me what the policies are (or should be) for an ISP doing transit. Clearly, the don't need a full /32, since they aren't really assigning (directly, or via delegation) lots of addresses. But shouldn't they be able to get space? Seems like that is a valid policy discussion to have. Thomas

2 1