October 2002 - ipv6-wg - mailman.ripe.net

[ipv6-wg@ripe.net] Action points from the RIPE 43 meeting
by Andrei Robachevsky 03 Jan '03

03 Jan '03

Dear Colleagues, Please find below a report regarding the status of the action point from the RIPE 43 ipv6-wg meeting. Regards, Andrei Robachevsky RIPE NCC E. IPv6 capable RR DNS servers ============================== RIPE NCC will provide IPv6 access to the ns.ripe.net by the end of November. D. Action point 42.1: ===================== Investigate the CNAME and other solutions for v6-reverse delegation. This action point came up from the request for support a smooth transition from ip6.int to ip6.arpa. To be done in consistent manner this is being coordinated with other RIRs. Also a technical discussion is planned at the IETF-55 in November. We'll let the community know about the outcome of these discussions. F. Action point 42.2: ===================== Give an overview of 6-to-4 reverse delegation issues This issue requires coordination between the RIRs and is being discussed. More information can be available after the IETF-55 meeting in November.

8 23

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

15 Nov '02

> > On Thu, 31 Oct 2002, Arash Ashouriha wrote: > > 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. > > Where did you get that idea? > > Please have a look at RFC3314 (Recommendations for IPv6 in Third > Generation Partnership Project (3GPP) Standards) and RFC3177 > (IAB/IESG > Recommendations on IPv6 Address Allocations to Sites). RFC3314 says on page 14: "Because multiple IPv6 hosts may attach through a 3GPP handset, the IPv6 WG recommends that one or more /64 prefixes should be assigned to each primary PDP context." But I really don't want to concentrate on that discussion. I want to know if RIPE NCC accepts IPv6 TLA requests from mobile operators only having GPRS/UMTS/WLAN customers - and therefore not providing connectivity to organisations with a /48. -> if anybody can clarify this, I would be very happy! > > Of course, anyone can build the networks as they want, but > assigning /64's > to mobile customers is something that must be supported by RIR's. > > > > 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.... > > > > > > > > -- > 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 > >

7 6

RE: [6bone] RIPE and IPv6 ASN
by Weinberger Andreas 04 Nov '02

04 Nov '02

hi nicolas, hi 6bone ml and ripe stuff, > Hello, [snipp] > 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) well, - is ndsoftware a multihomes isp? - is ndsoftware a ripe member? - does ndsoftware has a lir status? - does ndsoftware have production, 2001:: ipv6 space? i dont know why you are crying around, but it seems that ndsoftware isnt any kind of an isp. and for just playing around with ipv6 (3ffe::) there is no reason for a public asn. use your current private asn. its enough. > Thanks > > Best Regards, > > Nicolas DEFFAYET my 2 (euro) cents, bye, :::: :: andreas 'randy' weinberger :: networking group :: ebv elektronik gmbh&co. kg :: mail: a.weinberger(a)ebv.com :: phone: +49 (0)8121 774-508

5 4

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: [ipv6-wg@ripe.net][6bone] Re: sTLA alloc policies (fwd)
by Gert Doering 25 Oct '02

25 Oct '02

Hi, On Thu, Oct 24, 2002 at 10:27:07AM +0300, Pekka Savola wrote: > On Thu, 24 Oct 2002, Gert Doering wrote: > > On Thu, Oct 24, 2002 at 09:24:13AM +0300, Pekka Savola wrote: > > > I wonder what interpretation of "other organizations" is used when RIPE > > > NCC evaluates the applications..? > > > > I always understood it to be "a different legal entity". > > > > Using 200 employees for that sounds a bit borderline to me, though. > > Right.. Employees, as any other people, different legal entities, > though... Yes, of course. It's valid to the letter of the policy, but it's not really in the spirit of it. The idea was to catch "companies that manage IP allocations for third parties as part of their core business" (to avoid the term "ISP"). A company with 200 employees - and a university with 10.000 students - are interesting problems, though. Shall each "home site" get a /48? Or is it "one /48 for the whole company/university, and each home site only gets a /64"? I can't answer that. The "one /48 fits all" policy sucks. Gert Doering -- NetMaster -- Total number of prefixes smaller than registry allocations: 48282 (47686) SpaceNet AG Mail: netmaster(a)Space.Net Joseph-Dollinger-Bogen 14 Tel : +49-89-32356-0 80807 Muenchen Fax : +49-89-32356-299

6 6