December 2005 - address-policy-wg

200 customer requirements for IPv6
by Marc van Selm 18 Jan '06

18 Jan '06

Following up on the discussion during RIPE-51, I have not heard much discussion on "200 customer requirement for IPv6" rule. So I would like to hear your views on this. During RIPE-51 the proposal to remove the rule caught serious objections. I can sympathise with those but I do have an issue that I'd like feedback on. I am investigating how NATO should acquire IPv6 address space. NATO will use multiple transmission providers, NATO owned transmission and national networks. Also transmission contracts will have to be opened for bidding every few years. That makes requesting IP space from an ISP a non starter. So we explore the LIR route. Note that NATO has a service provider under its umbrella that provides service towards the other NATO organisations. They operate independently and are like an ISP (and more) for that matter. They are just not selling outside NATO. At this time it is reasonably hard to specify the 200 /48 that will be given out for the "IPv6 Initial Allocation Request". Having reached about 130 or so on my list (not finished yet) I can't help wondering why RIPE-NCC should care about a list of sites that they only a vague clue of what they are and have no means of verification if the list is correct. Having said that, I get the feeling that the 200 rule only ads admin overhead and has limited actual power. Now NATO could include a summarised version in the Initial Allocation and do something like: Subnet: /48 1 year 5 regional sites (/48 per site = 5x /48) Subnet: /48 1 year 20 subordinate sites to the 5 regional sites (/48 per site = 5x 20x /48 = 100 /48) Subnet: /48 2 year 40 deployed elements (/48 per site = 40x /48) Subnet: /48 2 year 70 Crisis Response Operation locations (/48 per location = 70 x /48) Total: 215x /48 Note that the numbers are fiction but they are not very unrealistic as we also need to include standby elements that are ready to go (power up, aim dish and run) systems. Although close to the truth, RIPE-NCC would have no way of verifying this and providing a detailed list would bury RIPE-NCC in details that they don't care about and also cannot verify. I can't help feeling this rule is written for ISPs but will be counter productive for NATO and organisations with a very large privately operated enterprice network. I also can't help the feeling that its a paper tiger. So isn't there another way to achieve the same result as this rule was intended for? Any views? Marc -- Marc van Selm NATO C3 Agency CIS Division E-mail: marc.van.selm(a)nc3a.nato.int (PGP capable)

23 75

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