- ipv6-wg - mailman.ripe.net

RE: [ipv6-wg@ripe.net] IPv6 TLAs for mobile operators
by Michel Py 31 Oct '02

31 Oct '02

> Matthew Ford wrote: > Please let's not have this debate *again*. Mobile devices > will in many cases be used as gateways for personal area > networks and as such require *at least* a /64 allocation. Thank you. Michel.

1 0

[ipv6-wg@ripe.net] New Document available: RIPE-261
by RIPE NCC Document Announcement Service 31 Oct '02

31 Oct '02

[Apologies for duplicate mails] New RIPE Document Announcement -------------------------------------- A new document is available from the RIPE document store. Ref: ripe-261 Title: IPv6 Address Space Management Author: Paul Wilson, Raymond Plzak, Axel Pawlik Date: 31 October 2002 Format: PS=27246 TXT=13567 Obsoletes: Obsoleted by: Updates: Updated by: Short content description ------------------------- The "IPv6 Address Space Management" document provides the management process for IPv6 global unicast address space whereby address allocations are made from a single global pool according to a "sparse allocation" algorithm. This allocation process will maximise aggregation of address space, ensuring that most ISPs retain a single prefix as they grow, and avoiding the address space fragmentation which results from the current IPv4 allocation technique. This document also describes the registration process and the administration of the IP6.ARPA domain. Accessing the RIPE document store --------------------------------- You can access the RIPE documents in HTML format via our website. "IPv6 Address Space Management" is available at the following URL: http://www.ripe.net/ripe/docs/ipv6-sparse.html The RIPE document store is also available via anonymous FTP to ftp.ripe.net, in the directory ripe/docs. The URLs for the new documents on the FTP-server are: ftp://ftp.ripe.net/ripe/docs/ripe-261.ps PostScript version ftp://ftp.ripe.net/ripe/docs/ripe-261.txt plain text version

1 0

[ipv6-wg@ripe.net] IPv6 TLAs for mobile operators
by Andreas.Schmid1＠swisscom.com 31 Oct '02

31 Oct '02

Hi I am new to this list - hope I do not touch a topic that has been discussed different times in here.... I wonder how mobile operators receive IPv6 address allocations from RIPE NCC? The IPv6 policy paper (http://www.ripe.net/ripe/docs/ipv6policy.html) includes 4 conditions: a) be an LIR; b) not be an end site; c) plan to provide IPv6 connectivity to organisations to which it will assign /48s, by advertising that connectivity through its single aggregated address allocation; and d) have a plan for making at least 200 /48 assignments to other organisations within two years. Mobile operators fulfill a) and b). But since mobile operators will probably give /64 addresses to their users (a single mobile terminal), they don't fulfill c) and d) - if they are not a traditional ISP in parallel. -> how does RIPE treat IPv6 TLA requests from pure mobile operators? thanks for any answer Andreas PS: one might argue that the mobile operators will give a /48 for each mobile terminal. But this would mean that a /32 gives them only 65k mobile terminals to address! A large mobile operator haveing more than 10 Mio customers would need 2^24 addresses resulting in a /24! Is this what is intended to be given to a mobile operator from RIPE? I don't think so....

4 3

RE: [ipv6-wg@ripe.net] IPv6 TLAs for mobile operators
by matthew.ford＠bt.com 31 Oct '02

31 Oct '02

> A single terminal or mobile device should get /127 and not /64 ! > /64 is for 1 network. If the customer need more than 1 > Network, he may get /48. Please let's not have this debate *again*. Mobile devices will in many cases be used as gateways for personal area networks and as such require *at least* a /64 allocation. Mat.

2 1

RE: [ipv6-wg@ripe.net] IPv6 TLAs for mobile operators
by Andreas.Schmid1＠swisscom.com 31 Oct '02

31 Oct '02

Hi Arash True - but this changes if a mobile terminal is used as modem by a PC. In this case, a /64 will be given to the PC, right? My question was whether RIPE NCC would allocate a IPv6 TLA to a mobile operator who is not acting as ISP (only having subscribers for this GPRS/UMTS and evt. WLAN service). -> would this operator get the TLA (although conditions c) and d) are not fulfilled)? best regards andreas > -----Original Message----- > From: Arash Ashouriha [mailto:arash.ashouriha@vodafone.com] > Sent: Donnerstag, 31. Oktober 2002 10:08 > To: Schmid Andreas, INO-ITA > Cc: ipv6-wg(a)ripe.net > Subject: Re: [ipv6-wg(a)ripe.net] IPv6 TLAs for mobile operators > > > Hi there, > > A single terminal or mobile device should get /127 and not /64 ! > /64 is for 1 network. If the customer need more than 1 > Network, he may get /48. > > Best regards > > Arash Ashouriha > > > Andreas.Schmid1(a)swisscom.com schrieb: > > > Hi > > > > I am new to this list - hope I do not touch a topic that > has been discussed different times in here.... > > > > I wonder how mobile operators receive IPv6 address > allocations from RIPE NCC? The IPv6 policy paper > (http://www.ripe.net/ripe/docs/ipv6policy.html) includes 4 conditions: > > a) be an LIR; > > b) not be an end site; > > c) plan to provide IPv6 connectivity to > organisations to which it will assign /48s, by advertising > that connectivity through its single aggregated address > allocation; and > > d) have a plan for making at least 200 /48 > assignments to other organisations within two years. > > > > Mobile operators fulfill a) and b). But since mobile > operators will probably give /64 addresses to their users (a > single mobile terminal), they don't fulfill c) and d) - if > they are not a traditional ISP in parallel. > > > -> how does RIPE treat IPv6 TLA requests from pure mobile operators? > > > > > > > thanks for any answer > > Andreas > > > > PS: one might argue that the mobile operators will give a > /48 for each mobile terminal. But this would mean that a /32 > gives them only 65k mobile terminals to address! A large > mobile operator haveing more than 10 Mio customers would need > 2^24 addresses resulting in a /24! Is this what is intended > to be given to a mobile operator from RIPE? I don't think so.... > > > >

1 0

[ipv6-wg@ripe.net][6bone] Re: sTLA alloc policies (fwd)
by Pekka Savola 25 Oct '02

25 Oct '02

I wonder what interpretation of "other organizations" is used when RIPE NCC evaluates the applications..? -- Pekka Savola "Tell me of difficulties surmounted, Netcore Oy not those you stumble over and fall" Systems. Networks. Security. -- Robert Jordan: A Crown of Swords ---------- Forwarded message ---------- Date: Thu, 24 Oct 2002 00:12:29 +0300 (EEST) From: Pekka Savola <pekkas(a)netcore.fi> To: David Kessens <david(a)iprg.nokia.com> Cc: 6bone(a)ISI.EDU Subject: [6bone] Re: sTLA alloc policies On Tue, 22 Oct 2002, David Kessens wrote: > On Sun, Oct 20, 2002 at 05:36:10PM +0300, Pekka Savola wrote: > > > > Oh, Nokia must also have colored the truth slightly.. > > What are you trying to insinuate here ?!? > Please refrain from such comments if you don't know the details. Indeed, the applications are not public so I do not, unfortunately, know details :-( > We got our address space under the old rules. Ah, I didn't notice this. > Despite this, it really > shouldn't be too hard for any large multinational company to show > plans for assigning address space to 200 other organizations. No need > to color the truth at all. You must be using some other definition of other organizations than I do. Further, I don't believe there are even 200 countries out there. :-) Let's see. Extending your interpretation any company with 200 employees could be entitled to a block: they _do_ want to provide xDSL service and proper addresses to their employees (who are private users) using the recommended /48 assignment! Right.. -- Pekka Savola "Tell me of difficulties surmounted, Netcore Oy not those you stumble over and fall" Systems. Networks. Security. -- Robert Jordan: A Crown of Swords _______________________________________________ 6bone mailing list 6bone(a)mailman.isi.edu http://mailman.isi.edu/mailman/listinfo/6bone

3 4

Re: Getting addresses
by Wilfried Woeber, UniVie/ACOnet 25 Oct '02

25 Oct '02

Hi Rudolf! >I am new to these discussions on the list, so if I am saying something >stupid, please tell me so. Not at all! The worst thing that is happening here is that we re-iterate things. So what.... >>I don't have a point of view. A lot of people are telling me they will >>choose the /48 road. Without a detailed definition of site, almost >>everyone's view will have to be accepted. That's what I am seeing in all >>these discussions. > >That is what has been bothering me the most in the whole discussion about >who gets a /32 assignment and who doesn't. This is one thing that is so surprising for me in these discussions: There seems to be an implicit assumption that we SHOULD come up with all sorts of criteria to BLOCK distributing IPv6 addresses, rather than getting the technology rolled out :-(). As an aside, I still see IPv6 address space as a *global resource*, not something which a (roughly) self-defined group of entities partitions amongst them (tier-X ISPs). Becoming an LIR is possible for (almost) every type and shape and size of organisations (at least in the RIPE region) - but it is not for free. There are quite some good reasons for distributing globally unique IPv6 addresses to entities which would not fit the "classical" ISP (or even tier-X ISP) definition. And those amongst us who worry about end-to-restoration, making things simple(r), looking into the future, should recognize that there is no "rfc1918" space in v6-land. (Yes, I know about the site-local address concept. But why should we plant time-bombs ticking when there are plenty of those magic bit combinations around?). >Both the number of /48 >assignments as well as the determination of what an end-site is, are >completely arbitrary I agree. It's the same level of "arbitray-ness" that is wired into "200 sites", trying to define an ISP, and the like. It's better than nothing at all (i.e. no consensus) - at least for now. >and therefore in the long run unworkable. We'll see. We havent tried yet. And by the way, we have tried to define "ISP" in v4-land for years, and we failed. > Almost >everyone that is an LIR now, is able through one trick or another to >justify an allocation of a /32 Actually, this was the point of view that had emerged in the RIPE region during the Jan'02 meeting. "Every LIR should get an allocation" if they can document the need for 1 address. The "tricking" started to come into the game when we again tried to impose (artificial) criteria/ limits/ restrictions/... Btw, I still do remember the days (around '93) when a LIR was allowed to give away a /23 to every "site", no questions asked. And it didn't *break* the Internet, it made it *succeed*! In the end every policy is a compromise. Some of us don't like the version we do have on the table right now because we think it is too restrictive. Some of us dislike the thing because we perceive it as too liberal. Such is life. > and as Joao points out, the RIR's won't be >able to do anything against it. The RIRs should not act *against* "something"! They are supposed to execute a consensus, written down in a document and agreed by the community! It took a loong time, and many discussions, to arrive at the doc we do have on the table right now. And there are things in it which are "fuzzy". That was done deliberately, after trying (and failing) to come to more precise (and sometimes restrictive) definitions that would still be acceptable to all the 3(4) regions. On the other hand quite a few things were straightend out (like the exclusive reference to a /48 holder), and I'd really urge all of you to *completely read* the final doc. > And then I wonder if in the long run we >won't see a global routing mess, because many more organisations will be >able to register as LIR and justify a /32 in the same way. This is exactly >what the requirement for 200 potential sites tries to achieve, but fails to >do. Well, again one of those "assumptions" that this is bad :-) I still think that we can accommodate a *lot* of IPv6 routing with the slack from the (predicted) growth in v4 that did NOT happen in v4-land.... >The community should be able to come up with a better definition of who >should be allowed to get a /32 and who is condemned to go to an upstream >provider. This should be more objective than the current rule and not >result in the problems that we see now for RIR's and IXP's and smaller >NREN's and ISP's, . Welcome to the show. I hope you would be around to help when we have to re-work the thing to adapt it to the evolving Internet :-) Just one comment on the use of "smaller" here: we couldn't come up with a good set of criteria to define a "smaller" "whatever". What are the criteria? Real estate? Gigabit/sec? Terabit storage? number of contracts? number of web pages? annual turnover? annual profit (or loss :-)? The tier-1 ISP of yesterday is the chapter 11 case of today and a department of another ISP tomorrow. As I said during the discussion, (given the IETF recommendation) a SOHO customer of a "commercial" ISP s/would qualify for a site .eq. a /48. Probably a handful of physical subnets would be used. And it is easy to have a few hundred of those, eventually (probably). A university, or a regional edu-network could be structured alongside a single /48 as well. Such a "site" could happen to serve some 5000..10000 ..50000 users in quite some hundred physical subnets (LAN, ISDN, ADSL, wire-less). Which of those network would be the "smaller" one?? Is it really "cheating" if we start to treat a primary and secondary school as a site with their own /48? Or the other way 'round, why is the "commercial ISP" not treated as a site with *1* /48? I am stretching things here just a little bit, on purpose... >I think we can evade a global routing slump if we allow the RIR's to >continue the excellent work they have done in the last couple of years. >They have conserved adresses well. In one of the doc.s there is that famous statement that conservation and routing aggregation can, or tend to, be conflicting goals. >But we should provide them with adequate >rules to work with, so that they can aggregate well in the IPv6 future too. > >>The problem is the lack of arguments for an RIR on what is the right thing >>to do. >> >>Joao > >Let us provide them with the right arguments to do the right thing. Fair enough, but - >Maybe we should take that discussion back to the global v6 list. wouldn't it be prudent to try to *implement* the new policy, learn by doing so, and *then* go back to the drafting table?! I do not believe anybody claiming that we/he/she can find out *now* what the best solution is in a few year's time. The 'net is constantly evolving.... >Greetings, > >Rudolf van der Berg >Dutch German Internet Exchange >http://www.ndix.net OK, I think I'll leave it at that for this discussion :-) Thanks for your good questions and observations! Cheers, Wilfried. _________________________________:_____________________________________ Wilfried Woeber : e-mail: Woeber(a)CC.UniVie.ac.at UniVie Computer Center - ACOnet : Tel: +43 1 4277 - 140 33 Universitaetsstrasse 7 : Fax: +43 1 4277 - 9 140 A-1010 Vienna, Austria, Europe : RIPE-DB: WW144, PGP keyID 0xF0ACB369 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~:~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

5 4

[ipv6-wg@ripe.net]IPv6 deployment in Tunisia
by Lamia Chaffai 24 Oct '02

24 Oct '02

Dear list members, My name is Lamia Chaffai and I'm working on the IPv6 deployment project in the Tunisian Internet Agency ( the NIC and LIR for the TN domain). We have recently obtained our IPv6 address block from RIPE ( 2001:0970::/32) and we'll be very grateful to you if you could possibly help us identify a partner with which we can establish an IPv6 tunnel to start deploying our IPv6 network until we succeed to establish a native IPv6 link. Thank you in advance for your help and collaboration. Kind Regards Lamia Chaffai Tunisian Internet Agency http://www.ati.tn http://www.ipv6net.tn 13, Rue Jugurtha Mutuelleville 1002 Tunis Tunisia phone: +216 71 846100 fax: +216 846600

2 1

RIPE and IPv6 ASN
by Nicolas DEFFAYET 16 Oct '02

16 Oct '02

Hello, Disclaimer: I hide sensitive information (ASN, company name,...). Flames & co > /dev/null RIPE are welcome to contact me because i don't find contact except the registration contact for members only. My company have an operational ipv6-site since 17 january 2001 on 6bone (http://whois.6bone.net/cgi-bin/whois?NDSOFTWARE) We made a lot of tests with our IPv6 experimental network and we provide IPv6 connectivity to many IPv6 projects. We do BGP peering with a private ASN (we announce only our routes with community no-export if the peer accept it and use correct filter) because we don't have our ASN. Now, we will build a real IPv6 network (native peering, peering with other ISP on Internet Exchange,...). My company created the first french IPv6 Internet Exchange, FNIX6 (http://www.fnix6.net) but my company can't peer on FNIX6 becase we don't have public ASN. Yesterday, i sent my ASN request to the RIPE by my LIR (peer1): ---------------------------------------------------------------------> X-NCC-RegID: <obscured-regid> #[ANNOUNCED ADDRESS RANGES]# <obscured-ipv6-/32> #[PEERING CONTACTS]# <obscured-peer1-email> <obscured-peer2-email> #[AUT-NUM TEMPLATE]# aut-num: NEW as-name: NDSOFTWARE-AS descr: NDSoftware IP Network import: from AS<obscured-peer1-as> action pref=100; accept ANY import: from AS<obscured-peer2-as> action pref=100; accept ANY export: to AS<obscured-peer1-as> announce NEW export: to AS<obscured-peer2-as> announce NEW remarks: Network problems to: noc(a)ndsoftwarenet.com remarks: Peering requests to: peering(a)ndsoftwarenet.com remarks: Abuse notifications to: abuse(a)ndsoftwarenet.com remarks: NDSoftware have an open peering policy. admin-c: AUTO-1 tech-c: AUTO-1 notify: notify(a)ndsoftwarenet.com mnt-by: NDSOFTWARE-MNT changed: hostmaster(a)ripe.net source: RIPE #[MAINTAINER TEMPLATE]# mntner: NDSOFTWARE-MNT descr: NDSoftware IP Network admin-c: AUTO-1 tech-c: AUTO-1 upd-to: ipmaster(a)ndsoftwarenet.com mnt-nfy: notify(a)ndsoftwarenet.com auth: MD5-PW $1$uAUWFve7$aPxYj8kqY4sCqr7g7fL6J/ notify: notify(a)ndsoftwarenet.com mnt-by: NDSOFTWARE-MNT referral-by: RIPE-DBM-MNT changed: hostmaster(a)ripe.net source: RIPE #[PERSON TEMPLATE]# person: Nicolas DEFFAYET address: NDSoftware address: 57 rue du president Wilson address: 92300 Levallois-Perret address: France phone: +33 671887502 e-mail: nicolas.deffayet(a)ndsoftware.net nic-hdl: AUTO-1 notify: notify(a)ndsoftwarenet.com mnt-by: NDSOFTWARE-MNT changed: nicolas.deffayet(a)ndsoftware.net source: RIPE #[ADDITIONAL INFORMATION]#. We request a pTLA to 6bone as soon we get our ASN. We are the founder of FNIX6 (French National Internet Exchange IPv6). We provide IPv6 transit to many projects. #[TEMPLATE END]# ---------------------------------------------------------------------> Reply of RIPE: ---------------------------------------------------------------------> Thank you for your request for an AS number, but with IPv6 you do not need to use any AS numbers nor route objects. Please have a look at the IPv6 documentation at the following link: http://www.ripe.net/ripe/docs/ipv6.html ---------------------------------------------------------------------> Very stupid reply, for do BGP peering, request a pTLA to 6bone and peer on FNIX6, we need a public ASN. There isn't IPv6 documentation for ASN on http://www.ripe.net/ripe/docs/ipv6.html => How get an ASN for our new IPv6 network ? (we don't want do IPv4 network) Thanks Best Regards, Nicolas DEFFAYET

8 12

Mailing List Software Migration
by RIPE NCC WebMaster 10 Oct '02

10 Oct '02

Dear Mailing List Subscriber, The RIPE NCC will change its mailing list software from "majordomo" to "mailman" on 17 October 2002. The new mailing list software will give users more options to manage their subscriptions to the RIPE and RIPE NCC mailing lists. Additionally, this change is being made to ensure stability and continuity of mailing list management and archiving. The new mailing list software will give users a number of options using a web interface: - Subscribing and Unsubscribing to mailing lists - Reviewing general information about the mailing lists - Viewing subscriptions to mailing lists - Temporarily disabling mail delivery - Choosing between regular and digests of mailing list postings - Acknowledgements to postings The web interface will be located at the following URL: http://www.ripe.net/mailman/ As well as using the web interface, mailing list users can manage their subscription and retrieve information by using an e-mail client. Further details on this are available at the above URL. Please note that if mailing list users are already subscribed to one or more mailing lists, they do not have to take any action. Messages can still be sent to the regular mailing lists addresses and subscriptions will not have to be re-confirmed. If you have any questions about this migration, please feel free to send an e-mail to <webmaster(a)ripe.net> Kind Regards, Jeroen Bet RIPE NCC Mailing List Moderation

1 0