- ipv6-wg - mailman.ripe.net

FYI: Personal invitation to attend the Conference: "Convergence: New Opportunities for Accelerating the IPv6 Momentum"
by Martin Vyskocil 04 May '06

04 May '06

Dear All, please find below the inventation to the Converence "Convergence: New Opportunities for Accelerating the IPv6 Momentum" on 1-2 June, 2006 in Vienna, Austria > The Event is organised by the European Commission and is sponsored and hosted > by Telekom Austria under the auspices of the Austrian Presidency and with the > support of the European IPv6 Task Force. Aganda and registration is on the conference webpage regards Martin Vyskocil ---------------------------- Martin VYSKOCIL Telekom Austria AG PTM/DW/TRADAT VM404-RIPE Von: Susannah.SOCHALL(a)ext.cec.eu.int Gesendet: Dienstag, 02. Mai 2006 11:16 An: INFSO-RI-IPV6PRESIDENCYCONFERENCE(a)cec.eu.int Cc: Jean-Luc.DOREL(a)cec.eu.int Betreff: Personal invitation to attend the Conference: "Convergence: New Opportunities for Accelerating the IPv6 Momentum" Dear Colleague I am writing to you to invite you to attend a Conference on 1-2 June, 2006 in Vienna, Austria - entitled "Convergence: New Opportunities for Accelerating the IPv6 Momentum". The Event is organised by the European Commission and is sponsored and hosted by Telekom Austria under the auspices of the Austrian Presidency and with the support of the European IPv6 Task Force. After years of investment in the technology of IPv6 it is time to consider business aspects of its deployment. One of the highlights of the event will be the presentation of concrete IPv6 applications in various sectors, such as Automotive, Aeronautics, Defence, Research Networks, Media, and Consumer. At a time where Convergence is occurring both in the fix-mobile domain and in the Voice/Data/Video domain, this event will be the place where experts from industry will comment on the impact of this movement on IPv6 deployments. This conference will also be an occasion to learn about successful experiences in IPv6 convergence in China, Japan, South Africa, South Korea and the US. The event will be honoured by two keynote speakers: Brian Carpenter, Chairman of the IETF and Hiroshi Esaki, a pionneer of the Internet in Japan. A Gala dinner will take place at the prestigious Hofburg Palace on Thursday, June 1. We would very much welcome your participation and your contribution to the discussions during the event. Attendance to this event as well as to the Gala dinner is by invitation only. Please consider this as an official invitation from the IPv6 Convergence Organisation Committee. The Event has a limited number of seats, therefore the Organisation Committee kindly asks you to confirm you participation via the web site: http://www.ipv6-convergence-vienna.net/ Also, due to the high tourist season, it is important that you book your hotel in advance. A hotel list is available on the web, you are kindly invited to register by yourself. For further information, please contact me. Yours sincerely, Jean-Luc Dorel On behalf of the IPv6 Convergence Event Organisation Committee

1 0

The Pope gets IPv6 PA space (not PI :)
by Jeroen Massar 04 May '06

04 May '06

inet6num: 2a01:b8::/32 netname: VA-VATICAN-20060418 descr: Holy See - Vatican City State country: VA So now that IPv6 is officially blessed go deploy it :) Greets, Jeroen Reply-To explicitly set to myself so that people don't reply to this silly post to all the lists... override to the one you like if you want </back to your normal schedule>

7 10

Agenda for ipv6 wg RIPE52
by David Kessens 27 Apr '06

27 Apr '06

Please see below for the final version of the agenda for the ipv6 working group session at RIPE 52. Thanks! David Kessens --- Agenda for the IPv6 Working Group Meeting RIPE52 When: Thu Apr 27 2006, 17:00-18:00 Where: Room Dolmabahce, Ceylan Intercontinental Hotel, Istanbul Turkey A. Administrative stuff - appointment of scribe - agenda bashing - Action items: 51.1 - Ask the RIPE NCC to revise the acronym list in the registration package to remove obsolete terms as TLA & NLA. (David Kessens) Status: Completed 51.2 - Create a link from the IPv6 WG page to the APNIC events page: http://apnic.net/info/calendar/index.html (RIPE NCC) Status: To be done 51.3 - Provide traffic reports on ipv6 usage during the RIPE meetings. If available, data from earlier meetings will be made available as well. (RIPE NCC) Status: Completed (David Kessens) B. Quick update from the RIPE NCC regarding ipv6 services (James Aldridge) C. Report(s) about *actual* v6 traffic volume as compared to v4? *what's real* out there, not what's on powerpoint? - ipv6 traffic during the RIPE meetings (James Aldridge) - ... D. Global IPv6 routing table status (discussion) (Gert Doering) E. ip6.int deprecation (Andrei Robachevsky) F. 6bone adresses about to expire (discussion) G. IPv6 allocation policies, anything we need to do ? (Input from the audience) H. Future of the working group (David Kessens) I. Developments/initiatives regarding IPv6 in the RIPE region and beyond (input from the audience, Jordi Palet Martinez) Y. Input for the RIPE NCC Activity Plan (input from the audience) Z. AOB ---

1 0

Call for agenda topics & draft agenda (v1) for ipv6 wg RIPE52
by David Kessens 23 Apr '06

23 Apr '06

During next RIPE meeting, our working group is scheduled to meet: Thu Apr 27, 17:00-18:00, room Dolmabahce I have prepared a draft agenda with all our standard items. However, the meeting will only be a success if we get a lot of active participation from all our participants. To achieve this goal, I would like to invite everybody to bring up their own topics on the list, or directly to me. Topics should be relevant to the operational issues regarding ipv6 deployment. Note that we don't require you to bring powerpoint slides or whatever, neither does a topic need to be of a particular predefined length. We are more interested in the content of the topic! Obviously, you are also very welcome to volunteer somebody else than yourself to give a presentation and to lead a discussion on a topic that is of interest for our working group. Thanks! David Kessens --- Draft Agenda (v1) for the IPv6 Working Group Meeting RIPE52 When: Thu Apr 27 2006, 17:00-18:00 Where: Room Dolmabahce, Ceylan Intercontinental Hotel, Istanbul Turkey A. Administrative stuff - appointment of scribe - agenda bashing - approval of the minutes (David Kessens) B. Quick update from the RIPE NCC regarding ipv6 services (RIPE NCC) C. Global IPv6 routing table status (discussion) (Gert Doering) D. Report(s) about *actual* v6 traffic volume as compared to v4? *what's real* out there, not what's on powerpoint? (input from the audience) E. Developments/initiatives regarding IPv6 in the RIPE region and beyond (input from the audience) Y. Input for the RIPE NCC Activity Plan (input from the audience) Z. AOB ---

2 3

New Document available: RIPE-376
by RIPE NCC Document Announcement Service 20 Apr '06

20 Apr '06

<<< our apologies for duplicate e-mails >>> New RIPE Document Announcement -------------------------------------- A new document is available from the RIPE document store. Ref: ripe-376 Title: Assigned Numbers Authority (IANA) Policy for Allocation of IPv6 Blocks to Regional Internet Registries Author: AfriNIC APNIC ARIN LACNIC RIPE NCC Date: 19 April 2006 Format: PDF=10551 TXT=4280 Obsoletes: Obsoleted by: Updates: Updated by: Short content description ------------------------- This document describes the policy governing the allocation of IPv6 address space from the IANA to the Regional Internet Registries (RIRs). This document does not stipulate performance requirements in the provision of services by IANA to an RIR in accordance with this policy. Such requirements will be specified by appropriate agreements between ICANN and the NRO. Accessing the RIPE document store --------------------------------- You can access the RIPE documents in HTML format via our website at the following URL: http://www.ripe.net/ripe/docs/ripe-376.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-376.pdf PDF version ftp://ftp.ripe.net/ripe/docs/ripe-376.txt plain text version Kind Regards, Jeroen Bet RIPE NCC Content Webmaster

1 0

Re: [ppml] PI addressing in IPv6 advances in ARIN
by JORDI PALET MARTINEZ 18 Apr '06

18 Apr '06

Hi all, My first idea was submitting a PI IPv6 policy proposal next Monday to RIPE and the rest of the regions, trying to get a consensus for a "global" policy on this, but as this thread is being followed up in several mail exploders, to avoid a long cross-posting, I think it will be better to start some discussion already in a mailing list which is global, and actually I think we have the right one ... global-v6(a)lists.apnic.net So, if you aren't subscribed in the global-v6(a)lists.apnic.net, and you're interested in this thread, please subscribe at http://mailman.apnic.net/mailman/listinfo/global-v6 If you're late because the Eastern, the archives are also available at http://www.apnic.net/mailing-lists/global-v6/ Regards, Jordi > De: JORDI PALET MARTINEZ <jordi.palet(a)consulintel.es> > Responder a: <jordi.palet(a)consulintel.es> > Fecha: Fri, 14 Apr 2006 13:39:07 +0200 > Para: "v6ops(a)ops.ietf.org" <v6ops(a)ops.ietf.org>, "ppml(a)arin.net" > <ppml(a)arin.net>, "shim6(a)psg.com" <shim6(a)psg.com> > Conversación: [ppml] PI addressing in IPv6 advances in ARIN > Asunto: Re: [ppml] PI addressing in IPv6 advances in ARIN > > Hi Owen, > > You said it: If somebody find the good solution, it will be attractive to > the people to go for it. Otherwise, you always have the chance to become an > LIR. My proposal actually is already considering this point and a way to > avoid a need for renumbering if that happens. > > I just want to make sure that we have a way-out if it becomes necessary, but > avoid a showstopper now. I think is it possible. > > I don't have a technical solution yet (and agree with your views on this in > the email below in general), but I'm confident we will have. If it will take > 4 years from now, or just 2, who knows, so my proposal is ensuring that we > have those 4 years+3 for allowing the people either to return the block, or > become an LIR and avoid renumbering an any changes in their network. > > By the way, it may happen, and I'm hoping so, that the technical solution > don't make necessary to return the PI block anymore, and in that case, we > will be even able to remove at that time the "temporarily" point in the > policy (if it becomes accepted). > > Regards, > Jordi > > > > >> De: Owen DeLong <owen(a)delong.com> >> Responder a: <owen(a)delong.com> >> Fecha: Fri, 14 Apr 2006 03:48:34 -0700 >> Para: <jordi.palet(a)consulintel.es>, "v6ops(a)ops.ietf.org" >> <v6ops(a)ops.ietf.org>, >> "ppml(a)arin.net" <ppml(a)arin.net>, "shim6(a)psg.com" <shim6(a)psg.com> >> Asunto: Re: [ppml] PI addressing in IPv6 advances in ARIN >> >> >> >> --On April 14, 2006 12:20:06 PM +0200 JORDI PALET MARTINEZ >> <jordi.palet(a)consulintel.es> wrote: >> >> [snip] >>> However, I want to balance this with the medium-long term implications >>> created in the routing table and with the time needed to build and deploy >>> a better technical solution (or several) which is accepted by the >>> community. >>> >> I think we first need to define what we consider a solution... See below. >> >>> So my proposal basically is about having PI now everywhere (once ARIN >>> adopt it, is unfair not having it in other regions), but those PI >>> allocations for multihoming should be temporary and those address blocks >>> returned to the RIRs some time (lets say 3 years) after the new technical >>> solution is declared as a valid one. >>> >> I would not actually support this idea. The whole point of having PI >> space is to have the addresses for a long-term. Having a timeframe for >> return would simply restore the same barrier to entry that existed >> prior to passing the policy. >> >> Other RIRs are free to implement whatever v6 PI policy they feel is >> appropriate for their region. I would support a globally standardized >> v6 PI policy along the lines of ARIN 2005-1. >> >> However, I would like to argue that if the new technical solution will >> benefit from the return of this address space, it is most likely not >> truly a solution, but, instead, another clever hack piled on top of >> the existing set of hacks. >> >> I suppose if someone found the magic bullet to make geotopological >> addressing really work, that might qualify. However, I have very low >> expectations in that area. >> >> Absent that, any true solution will involve making the size of the routing >> table independent of the number of PI (or even PA) blocks issued by >> the RIRs or will make the size of the routing table practically >> irrelevant. >> >> I know this isn't the easy solution, but, we need to look long and >> hard at the way we do things. I think that solving these problems >> is going to require a significant paradigm shift. Assuming that we >> can use IP addresses for both end system identification and for >> routing topology indicators is how we created this problem. I don't >> see solving it without breaking that assumption, at least at the >> interdomain level. >> >> >>> At this way, on the long-run, we will not have routing table implications, >>> but we allow now the people that want to move ahead only if they have a >>> multihoming solution doing so. >>> >> If you think there is a possible solution (a real solution, not just >> a hack that postpones the inevitable at the expense of usability >> like CIDR did), then I'd like to hear what you are thinking. >> >>> This 3-years time for getting a multihoming network back to the new >>> technical solution (once adopted) is enough time, I think (it could be >>> changed to 5 years if needed, or whatever), so nobody today see the >>> temporarily of the proposal as a showstopper to go for it now. >>> >> I think you underestimate the momentum and requirements of the modern >> enterprise if you believe that to be true. Any capability available >> in v4 that is not available on at least equal or better terms in v6 >> is a deterrent to v6 deployment. >> >> The ability to get permanent addresses which do not have to be returned >> when you switch providers or renumbered on a schedule determined by >> some external organization is a major example of such a capability. >> >> Owen >> >> >> -- >> If it wasn't crypto-signed, it probably didn't come from me. > > > > > ********************************************** > The IPv6 Portal: http://www.ipv6tf.org > > Barcelona 2005 Global IPv6 Summit > Slides available at: > http://www.ipv6-es.com > > This electronic message contains information which may be privileged or > confidential. The information is intended to be for the use of the > individual(s) named above. If you are not the intended recipient be aware that > any disclosure, copying, distribution or use of the contents of this > information, including attached files, is prohibited. > > > > > > > ********************************************** > The IPv6 Portal: http://www.ipv6tf.org > > Barcelona 2005 Global IPv6 Summit > Slides available at: > http://www.ipv6-es.com > > This electronic message contains information which may be privileged or > confidential. The information is intended to be for the use of the > individual(s) named above. If you are not the intended recipient be aware that > any disclosure, copying, distribution or use of the contents of this > information, including attached files, is prohibited. > > ********************************************** The IPv6 Portal: http://www.ipv6tf.org Barcelona 2005 Global IPv6 Summit Slides available at: http://www.ipv6-es.com This electronic message contains information which may be privileged or confidential. The information is intended to be for the use of the individual(s) named above. If you are not the intended recipient be aware that any disclosure, copying, distribution or use of the contents of this information, including attached files, is prohibited.

2 1

Thank you -->- Request information: black fiber !
by brian forgrave 17 Apr '06

17 Apr '06

1 0

Problems with ipv6 router
by Andrei Robachevsky 13 Apr '06

13 Apr '06

Dear Colleagues, [We are sorry for any duplicate mails you might receive] This afternoon we experienced a problem with our IPv6 router. Problems started at 13:50, and we are still facing problem. None of our IPv4 services are affected, as these are dealt with by other routers. Affected services, which we offer on IPv6 are: - FTP: ftp.ripe.net - WWW: www.ripe.net - DNS: ns*.ripe.net - Whois: whois.ripe.net We suspect that an interfacecard of our dedicated IPv6 router is faulty, and at the moment an engineer is working on it. The long term solution is that we will replace this router. We apologise for any disruption or delay this may have caused. If you have any further questions about this matter, please send an e-mail to ops(a)ripe.net. Kind regards Andrei Robachevsky CTO, RIPE NCC

2 1

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

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 6

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

28 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 -------------------------------------------------------

29 109

Real-world IPv6 SMTP experience
by Florian Weimer 27 Dec '05

27 Dec '05

Hi, is there any document that contrasts RFC 3974 with the real world? I try to create a set of MX RRs which includes an IPv6 MX host, does not negatively impact reachability from v4-only hosts (or v6-enabled hosts without v6 connectivity), prefers v6 over v4 when possible, and does not waste any IPv4 addresses. This is what I've come up with so far: deneb.enyo.de. 172800 IN MX 9 v6.mail.enyo.de. deneb.enyo.de. 172800 IN MX 10 v4.mail.enyo.de. v6.mail.enyo.de. 172800 IN A 212.9.189.167 v6.mail.enyo.de. 172800 IN AAAA 2001:14b0:202:1::a7 v4.mail.enyo.de. 172800 IN A 212.9.189.167 The A RR of v6.mail is necessary because some broken anti-spam checks reject mail from deneb.enyo.de if they cannot find an A record for the primary MX. The v4.mail MX host is needed because some MTAs suppress A record lookup if they discover an AAAA record (even if there's no v6 connectivity available). I wouldn't be too surprised when this setup leads to bouncing mail, too. 8-> Florian

8 14

IPv6 database service
by Thu Thuy 07 Dec '05

07 Dec '05

Hi, all folk I would like to ask for your advise in IPv6 - support in database service. I don't know what kind of database now support IPv6. Could you pls advise me your knowleadge related to this matter. For IPv6 web service which require database, i don't know how is database service deployed. Do they used IPv6-supported database or they still use IPv4 database and the web server is dual-stack (IPv6 to handle user request and IPv4 to connect to database server). Thanks much for your help. Thu Thuy.

1 0

Re: 200 customer requirements for IPv6
by Daniel Roesen 06 Dec '05

06 Dec '05

On Thu, Nov 17, 2005 at 05:26:20PM +0100, JORDI PALET MARTINEZ wrote: > There are lots of similar examples as the NATO one. It make no sense > at all Not issueing PI for multihomed entities makes no sense at all, in face of the complete lack of a full replacement. I'm still waiting for the heads to come out of the sand, but I'm waiting since long and don't see _any_ light at the end of the tunnel (don't anybody dare to say "shim6" if he/she doesn't want to disqualify her/himself immediately). 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. 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. Too simple, too scary, too much independence again to the endsites, eh? I think it's ridiculous to have folks become LIR (and pretend/lie being ISPish) just to get the PI space they need and having them pay the same money every *real* LIR (you remember what LIR means? Local Internet REGISTRY) which happens to open tickets with the hostmasters every now and then (or much more often). 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), I'm quite sure that we'd need a real locator/ID split which is NOT shim6 but something going farther than that. And we won't have it soon, if at all for IPv6. But keeping on ignoring user's needs for further years and waiting for the magically appearing 100% ideal solution is not the way forward. My 0.02EUR Regards, Daniel (having renumbered his IPv6 network already three times completely and hoping not having to do it a fourth time anytime soon, and not being able to properly multihome like I can do in IPv4 because I'm not a commercial ISP, nor can afford the thousands of EUR for LIR which usually finance MUCH more than just a one-time PI assignment and some DB slots) -- CLUE-RIPE -- Jabber: dr(a)cluenet.de -- dr@IRCnet -- PGP: 0xA85C8AA0

4 8

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

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

IPv6 micro allocation or something else?
by Mohacsi Janos 02 Dec '05

02 Dec '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

21 60

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

2001:4200::/32, 2001:4308::/32, 2001:4310::/32 AFRINIC, ARIN or RIPE?
by Jeroen Massar 01 Dec '05

01 Dec '05

According to IANA: http://www.iana.org/assignments/ipv6-unicast-address-assignments They are ARIN space. According to ARIN(*1) it is RIPE space. According to RIPE, it is AFRINIC. What needs to be fixed here? The IANA allocs or something else? Also it would be nice of course if ARIN directly pointed to AFRINIC instead of making AFRINIC the little sister of RIPE. 2001:970::/32 and 2001:4300::/32 are also AFRINIC now, before they where from the RIPE region, but the IANA file doesn't reflect this. The delegated-afrinic-latest indicates AFRINIC now, which is a bit odd. Greets, Jeroen *1 = 8<--------------------------------------------------------- OrgName: RIPE Network Coordination Centre OrgID: RIPE Address: P.O. Box 10096 City: Amsterdam StateProv: PostalCode: 1001EB Country: NL ReferralServer: whois://whois.ripe.net:43 NetRange: 2001:4300:0000:0000:0000:0000:0000:0000 - 2001:430F:FFFF:FFFF:FFFF:FFFF:FFFF:FFFF CIDR: 2001:4300:0000:0000:0000:0000:0000:0000/28 NetName: RIPE1 NetHandle: NET6-2001-4300-1 Parent: NET6-2001-4200-0 NetType: Direct Allocation NameServer: NS-PRI.RIPE.NET NameServer: SEC1.APNIC.NET NameServer: SEC3.APNIC.NET NameServer: TINNIE.ARIN.NET NameServer: NS.LACNIC.NET Comment: RegDate: 2004-08-24 Updated: 2004-08-24 RTechHandle: RIPE-NCC-ARIN RTechName: RIPE NCC Hostmaster RTechPhone: +31 20 535 4444 RTechEmail: search-ripe-ncc-not-arin(a)ripe.net <SNIP> inet6num: 2001:4300::/25 netname: EU-ZZ-2001-4300 descr: RIPE NCC (AFRINIC) descr: European Regional Registry country: EU --------------------------------------------------------->8

2 1

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

30 Nov '05

Citeren ipv6-wg-request(a)ripe.net: > Send ipv6-wg mailing list submissions to > ipv6-wg(a)ripe.net > > To subscribe or unsubscribe via the World Wide Web, visit > http://www.ripe.net/mailman/listinfo/ipv6-wg > or, via email, send a message with subject or body 'help' to > ipv6-wg-request(a)ripe.net > > You can reach the person managing the list at > ipv6-wg-admin(a)ripe.net > > When replying, please edit your Subject line so it is more specific > than "Re: Contents of ipv6-wg digest..." > > > Today's Topics: > > 1. Re: [address-policy-wg] Re: [ipv6-wg] IPv6 PI (Per Heldal) > 2. unsubscibe jkuijer(a)dds.nl (jkuijer(a)dds.nl) > 3. Re: Re: [address-policy-wg] Re: Andre's guide to fix IPv6 (Florian > Weimer) > 4. Re: [address-policy-wg] Re: [ipv6-wg] IPv6 PI (Randy Bush) > 5. Re: [address-policy-wg] Re: [ipv6-wg] IPv6 PI (Geoff Huston) > 6. Re: Re: [address-policy-wg] Re: Andre's guide to fix > IPv6 (Geoff Huston) > 7. Re: [address-policy-wg] Re: [ipv6-wg] IPv6 PI (Geoff Huston) > 8. Re: [address-policy-wg] Re: [ipv6-wg] IPv6 PI (william(at)elan.net) > 9. Re: Re: [address-policy-wg] Re: Andre's guide to fix IPv6 (Max Tulyev) > > --__--__-- > > Message: 1 > From: "Per Heldal" <heldal(a)eml.cc> > To: "Salman Asadullah" <sasad(a)cisco.com> > Cc: "ipv6-wg(a)ripe.net" <ipv6-wg(a)ripe.net>, "address-policy-wg(a)ripe.net" > <address-policy-wg(a)ripe.net> > Subject: Re: [address-policy-wg] Re: [ipv6-wg] IPv6 PI > Date: Tue, 29 Nov 2005 12:21:52 +0100 > > > On Mon, 28 Nov 2005 15:55:16 -0800, "Salman Asadullah" <sasad(a)cisco.com> > said: > > 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. > > > > Regardless of the efforts, from a provider POV it's only "work in > progress". Make sure your preferred technology is implemented across all > platforms and accompanied by solutions for traffic-engineering, > filtering and other issues. Then you may have a viable alternative to > present to the operators community. Don't expect anybody to adopt new > technologies unless they represent some progress. > > I'm not saying that shim6 is DOA. It *may become* an alternative, but it > *is not*. Unless you can convince content-providers to trust their > upstream to provide redundancy and thus eliminate the need for end-site > multihoming you have the following realistic short-term alternatives: > > * Keep ipv6 experimental and postpone operational > deployment until there's a good technical solution > to the multi-homing problem or a way to eliminate > the DFZ and the related concerns about routing- > table size. > > * Adopt a PI policy for v6 similar to the current > v4-policy, and hope that moore can keep up with > the growth of the routing-table. > > From there policies will have to evolve, along with the development of > new technology. Evolution is a perpetual process, not a project with a > finite deadline. > > PS! am I missing something, or is IETF/IAB trying to copy the ITU in the > way they produce paper-standards? Is that really such a good idea? > > //per > -- > Per Heldal > heldal(a)eml.cc > > > --__--__-- > > Message: 2 > Date: Tue, 29 Nov 2005 12:25:08 +0100 > From: jkuijer(a)dds.nl > To: ipv6-wg(a)ripe.net > Subject: [ipv6-wg] unsubscibe jkuijer(a)dds.nl > > Citeren ipv6-wg-request(a)ripe.net: > > > Send ipv6-wg mailing list submissions to > > ipv6-wg(a)ripe.net > > > > To subscribe or unsubscribe via the World Wide Web, visit > > http://www.ripe.net/mailman/listinfo/ipv6-wg > > or, via email, send a message with subject or body 'help' to > > ipv6-wg-request(a)ripe.net > > > > You can reach the person managing the list at > > ipv6-wg-admin(a)ripe.net > > > > When replying, please edit your Subject line so it is more specific > > than "Re: Contents of ipv6-wg digest..." > > > > > > Today's Topics: > > > > 1. Re: Re: [address-policy-wg] Re: Andre's guide to fix IPv6 (McTim) > > 2. Re: [address-policy-wg] Re: Andre's guide to fix IPv6 (Geoff Huston) > > 3. Re: [address-policy-wg] Re: [ipv6-wg] IPv6 PI (Randy Bush) > > 4. Re: [address-policy-wg] Re: [ipv6-wg] IPv6 PI (Andre Oppermann) > > > > -- __--__-- > > > > Message: 1 > > Date: Tue, 29 Nov 2005 07:19:49 +0300 > > From: McTim <dogwallah(a)gmail.com> > > To: =?ISO-8859-1?Q?J=F8rgen_Hovland?= <jorgen(a)hovland.cx> > > Subject: Re: [ipv6-wg] Re: [address-policy-wg] Re: Andre's guide to fix > IPv6 > > Cc: ipv6-wg(a)ripe.net > > > > hiya, > > > > (removed address-policy-wg from the cc:) > > > > On 11/28/05, J=F8rgen Hovland <jorgen(a)hovland.cx> wrote: > > > > > > -----Original Message----- > > > From: McTim [mailto:dogwallah@gmail.com] > > > > > > > >#2 sounds like PI to me. What have I missed? > > > > > > Hello McTim, > > > You are correct. That's why I wrote PI in the email:-). > > > > I guess I misread the below wrong then ;-) > > > > J=F8rgen Hovland wrote: > > > > >> - > > >> 1. No PI. _Only_ network operators get a prefix. > > > > > It is an attempt to suggest an alternative idea to the PI discussion. > > > Don't get me wrong. I am for PI. This idea is perhaps a bit more > > > hierarchical instead of the standard flat one. Just making sure we have > > > thought of everything before we reach consensus > > > > I am sure thiat consensus will take a very long tiime on this one! We > > will probably have to talk about grotopological v6 adressing (as they > > are doing on the ARIN ppml) and a host of other issues. I reckon we > > ought to wait for shim6 to do their work as well. > > > > > because this PI discussion > > > is very important to ipv6. > > > > v. true. > > > > -- > > Cheers, > > > > McTim > > $ whois -h whois.afrinic.net mctim > > > > > > -- __--__-- > > > > Message: 2 > > Date: Tue, 29 Nov 2005 10:15:27 +1100 > > To: =?iso-8859-1?Q?J=F8rgen?= Hovland <jorgen(a)hovland.cx>, > > <address-policy-wg(a)ripe.net>, <ipv6-wg(a)ripe.net> > > From: Geoff Huston <gih(a)apnic.net> > > Subject: [ipv6-wg] Re: [address-policy-wg] Re: Andre's guide to fix IPv6 > > > > At 03:37 AM 29/11/2005, J=F8rgen Hovland wrote: > > >----- Original Message ----- From: "Florian Weimer" <fw(a)deneb.enyo.de> > > >Sent: Saturday, November 26, 2005 4:00 PM > > > > > > > > >>* Jeroen Massar: > > >> > > >>>>1. Make /32 the only routable entity so we can use perfect match in > > >>>> the DFZ instead of longest-prefix match. > > >>> > > >>>What about the organizations that have say a /19, want them to inject > > >>>all their more specific /32's? > > >> > > >>You can inject a /19 as 8192 /32s. Shouldn't make a difference if the > > >>/19 is really used. > > >> > > >>At this stage, it's probably not too wise to embed the /32--/48--/64 > > >>in silicon, but vendors will undoubtedly do this if they can save a > > >>few bucks and current policies remain as inflexible as they are. > > > > > >Hi, > > >Perfect match is faster but far from better. What I think perhaps would > be= > > =20 > > >interesting to see in the future with regards to IPv6 and PI is the= > > following: > > > > > >1. No PI. _Only_ network operators get a prefix. > > >2. Customers of network operators can at any time change provider and > take= > > =20 > > >their assigned prefix with them. The new provider will announce it as a=20 > > >more specific overriding the aggregate. If the customer decides to get=20 > > >multiple providers, then the network operator with the /32 could also=20 > > >announce a more specific. > > > > > >In the country I live in I can change telecom provider and take my > phone=20 > > >number with me to the new provider. Why shouldn't I be able to do that=20 > > >with internet providers? > > >Yes, it will somehow create millions/billions of prefixes (atleasat > with=20 > > >todays routing technology/protocols). Network operators should be able to= > > =20 > > >handle that hence rule #1. > > > > > > Interesting - it will work for a while, and then you will get to the limit= > > =20 > > of deployed capability of routing. > > > > Then what? > > > > Geoff > > > > > > > > > > > > -- __--__-- > > > > Message: 3 > > 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: 4 > > 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 ipv6-wg Digest > > > > > > > --__--__-- > > Message: 3 > From: Florian Weimer <fw(a)deneb.enyo.de> > To: Geoff Huston <gih(a)apnic.net> > Cc: =?iso-8859-1?Q?J=F8rgen?= Hovland <jorgen(a)hovland.cx>, > <address-policy-wg(a)ripe.net>, <ipv6-wg(a)ripe.net> > Subject: Re: [ipv6-wg] Re: [address-policy-wg] Re: Andre's guide to fix IPv6 > Date: Tue, 29 Nov 2005 15:26:53 +0100 > > * Geoff Huston: > > > Interesting - it will work for a while, and then you will get to the limit > > of deployed capability of routing. > > > > Then what? > > You buy new routers. > > What's next? Do you plan to lobby Hollywood to reduce the number of > movies create per year, so that your customers have fewer of them to > download, and the capacity of your pipes is not exceeded? > > > --__--__-- > > Message: 4 > From: Randy Bush <randy(a)psg.com> > Date: Tue, 29 Nov 2005 06:17:54 -1000 > To: Per Heldal <heldal(a)eml.cc> > Cc: Salman Asadullah <sasad(a)cisco.com>, > ipv6-wg(a)ripe.net, > address-policy-wg(a)ripe.net > 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. > > Regardless of the efforts, from a provider POV it's only "work in > > progress". > > one of the key points from the nanog session was that shim6 is the > *wrong* work in progress. what is needed is _site_ multi-homing, > not host multi-homing. > > randy > > > --__--__-- > > Message: 5 > Date: Wed, 30 Nov 2005 05:34:05 +1100 > To: Randy Bush <randy(a)psg.com>, Per Heldal <heldal(a)eml.cc> > From: Geoff Huston <gih(a)apnic.net> > Subject: Re: [address-policy-wg] Re: [ipv6-wg] IPv6 PI > Cc: Salman Asadullah <sasad(a)cisco.com>, ipv6-wg(a)ripe.net, > address-policy-wg(a)ripe.net > > At 03:17 AM 30/11/2005, Randy Bush wrote: > > >> Lots of efforts (Multi6, SHIM6, etc.) are being made to solve these real > > >> issues for a good reason. > > > Regardless of the efforts, from a provider POV it's only "work in > > > progress". > > > >one of the key points from the nanog session was that shim6 is the > >*wrong* work in progress. what is needed is _site_ multi-homing, > >not host multi-homing. > > "wrong"? "right"? > > Usual response - if you believe that there is a better way of doing this > work through the issues here, then write up an approach, gather support, > get peer review etc etc. > > As I said at NANOG, part of the problem with distributed models where there > is action at a distance is to understand and clearly identify instances of > gratuitous packet header rewriting by hostile agents as compared to packet > rewriting by agents who believe that they are doing this in a friendly and > helpful fashion. This becomes a challenging problem,of course. > > I don't think any single approach today is the one true right approach at > this point, but unless we explore this space with some diligence, allow for > experimentation and keep an open mind on this work then you are going to > get intractably wedged between the desire for greater flexibility in the > use of addresses as a form of semi-persistent endpoint identifiers and the > desire for reduced flexibility in the use of addresses as forwarding tokens > in order to keep the routing space confined to readily computable dimensions. > > But of course _all_ this will be solved in MPLS - right? :-) > > Geoff > > > > > > --__--__-- > > Message: 6 > Date: Wed, 30 Nov 2005 05:36:11 +1100 > To: Florian Weimer <fw(a)deneb.enyo.de> > From: Geoff Huston <gih(a)apnic.net> > Subject: Re: [ipv6-wg] Re: [address-policy-wg] Re: Andre's guide to fix > IPv6 > Cc: =?iso-8859-1?Q?J=F8rgen?= Hovland <jorgen(a)hovland.cx>, > <address-policy-wg(a)ripe.net>, <ipv6-wg(a)ripe.net> > > At 01:26 AM 30/11/2005, Florian Weimer wrote: > >* Geoff Huston: > > > > > Interesting - it will work for a while, and then you will get to the > limit > > > of deployed capability of routing. > > > > > > Then what? > > > >You buy new routers. > > > So what you are saying is that _I_ want address portability and _you_ have > to buy new routers. > > > Well that sure works for me! How's the chequebook feeling on your side? > > (I'm not convinced that you've selected the best of business models, as > there does appear to be a significant inconsistency going on in your model > in that cost and benefit are not related all that well.) > > Geoff > > > > --__--__-- > > Message: 7 > Date: Wed, 30 Nov 2005 06:01:56 +1100 > To: Andre Oppermann <oppermann(a)networx.ch>, Salman Asadullah > <sasad(a)cisco.com> > From: Geoff Huston <gih(a)apnic.net> > Subject: Re: [address-policy-wg] Re: [ipv6-wg] IPv6 PI > 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 > > At 08:13 PM 29/11/2005, Andre Oppermann wrote: > >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 > > Multi6 produced 5 WG drafts, all of which have been published as RFCs You > can (and probably should) read through RFCs 3582, 4116, 4177, 4219, and 4218 > > SHIM6 is working on the following drafts - again I would recommend that you > read though all of them:... > draft-ietf-shim6-app-refer, draft-ietf-shim6-applicability, > draft-ietf-shim6-arch, draft-ietf-shim6-failure-detection, > draft-ietf-shim6-hba, draft-ietf-shim6-proto, > and draft-ietf-shim6-reach-detect. > > > > 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. > > yep - any form of locator / identity split is such a basic shift in the > architectural model used by IP that changes to the stack are required. This > is the case in mobility, nomadism, ad-hoc networking and this form of > multi-homing. If you want agile locators and any form of persistence in > endpoint identifiers then you are not going to get that without changes to > the stack. Now if you are arguing that the deployed base of IPv6 is so > large that further changes are impossible in this particular technology due > to the inertia of the deployed IPv6 base, then that's certainly an > interesting perspective, and not one I've heard all that often so far. If > you are saying that this will take time to develop and deploy, then you are > probably right, and a model that can use incremental deployment using a > conventional initial context followed by a capability exchange to explore > if there is mutual support for this form of communication capability, then > you may well be onto something interesting. Although I'd hasten to add that > this is the approach being taken within the SHIM6 architecture. > > >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. > > I'm not sure I agree with you about the DNS and renumbering - its not a > clearly defined space, and the implications relating to the DNS are not > clearly understood in communication models where feasible locator sets are > dynamically exchanged rather than always loaded into third party rendezvous > points, as in the DNS model. > > > >So nice try but no cookie. > > Thank you, > > Geoff > > > > > > --__--__-- > > Message: 8 > Date: Wed, 30 Nov 2005 01:53:49 -0800 (PST) > From: "william(at)elan.net" <william(a)elan.net> > To: Geoff Huston <gih(a)apnic.net> > cc: Randy Bush <randy(a)psg.com>, Per Heldal <heldal(a)eml.cc>, > Salman Asadullah <sasad(a)cisco.com>, ipv6-wg(a)ripe.net, > address-policy-wg(a)ripe.net > Subject: Re: [address-policy-wg] Re: [ipv6-wg] IPv6 PI > > > On Wed, 30 Nov 2005, Geoff Huston wrote: > > > At 03:17 AM 30/11/2005, Randy Bush wrote: > >> >> Lots of efforts (Multi6, SHIM6, etc.) are being made to solve these > >> real > >> >> issues for a good reason. > >> > Regardless of the efforts, from a provider POV it's only "work in > >> > progress". > >> > >> one of the key points from the nanog session was that shim6 is the > >> *wrong* work in progress. what is needed is _site_ multi-homing, > >> not host multi-homing. > > Yes, well if it goes forward, it may well end up being used for setting > up site-multihoming: > > http://www.ietf.org/mail-archive/web/architecture- discuss/current/msg00095.html > and will be seen as friendly and right solution (on what "friendly" and > "right" can mean seen below). > > > "wrong"? "right"? > > > > Usual response - if you believe that there is a better way of doing this > > work through the issues here, then write up an approach, gather support, > get > > peer review etc etc. > > > > As I said at NANOG, part of the problem with distributed models where there > > is action at a distance is to understand and clearly identify instances of > > gratuitous packet header rewriting by hostile agents as compared to packet > > rewriting by agents who believe that they are doing this in a friendly and > > helpful fashion. This becomes a challenging problem,of course. > > If its hostile or friendly behavior is in the eye of the beholder - but > in fact it may not even be only one side or the other for the same person. > > If I sit under a NAT and it prevents my application from running, I'm > hostile to that behavior. But same NAT box may well be protecting my > home network from intrusion and allowing me to have multiple computers > connected through the same dsl/cable/wireless connection, so I'd view > it as a friendly. Since most people don't notice its hostile behavior > (due to kind of applications they run) and all notice its friendly > behavior it will overall be seen as a friend and "right" solution. > > So is there better way to do it and without NAT? Of course there is - > have real firewall and have block of ips - but NAT is winning as a > business case because it can do those several friendly things well for > almost everyone and without dependence on network provider and those > few users who are inconvenienced and their application are viewed as > minor percentage and not a problem in the overall business case. > So business case won but IETF end-end tcp/ip architecture broken ... > > > I don't think any single approach today is the one true right approach at > > this point, but unless we explore this space with some diligence, > > Diligence is the right word. But is it really the size of the routing > table that we're being most concerned (considering #of routes in ipv6 > will most definitely be smaller then with ipv4 because of less > fragmentation - generally one ip block per ASN) or business case of > users who do not want to be dependent on IP provider and RIR to be > able to multihome? > > And should due diligence be applied so that proposed solution both > makes sense to do for those who will use it (i.e. small businesses > in case of shim6) an does not break applications when that is done? > > -- > William Leibzon > Elan Networks > william(a)elan.net > > > --__--__-- > > Message: 9 > From: Max Tulyev <president(a)ukraine.su> > To: ipv6-wg(a)ripe.net > Subject: Re: [ipv6-wg] Re: [address-policy-wg] Re: Andre's guide to fix IPv6 > Date: Wed, 30 Nov 2005 13:33:52 +0300 > > Hi! > > > > 1. No PI. _Only_ network operators get a prefix. > > > > I am an operator of a network - do I get a prefix ? (we have lots of > > computers and need lots of IP addresses: currently the 5 PCs, 2 > > printers, a phone and some PDA and a server online) > > > > I guess you need to define the criteria in some other way. Perhaps > > beeing registered with the national regulator > > I'm looking at all of that and begin to think that all this discussion about > PI vs PA (and only [large] operators can get a prefix) is just for > implementing some unfair rules in ISP market. > > Wise customers wants to have PI because of to be multihoming and have stable > and really _provider_independent_ (i.e. not depending on upstream's faults) > connection. > Small operators wants to have PI because of LIR is often too expensive for > them. > > Large operators do NOT want PI because of they can hold a client with their > address space ("if you are going to change ISP - you will have a large > trouble with renumbering your network and changing domains" or even "if you > do not do ... - we will immediately shut down your connection"). Large > operators (can pay for LIR) do NOT want PI because of it makes the extra > money barrier to be an operator (LIR cost). > > See more on. Imagine there is no PI. If somebody really-really-really needs > to > be multihoming - he will be a LIR and do the LIR initial request (/20 PA for > IPv4 instead of /24 PI he really need for years). So in this case we do not > conserve one row of route table, but slightly loss in conserving space (/20 > instead of /24). > > Even more. Who is making the most noise about no PI? As I can see, large > operators. People who have enough powerful routers to not to think about > extra routes there. > > P.S. And please do not compare IP connectivity with global dynamic routing > (it > is a really BIG achievement of the Internet!) with PSTN and global static > routing where switching routes to certain number plan can take several > monthes. Of course, in PSTN we can't ever think about hot backup and upstream > reservation (multihoming). > > -- > WBR, > Max Tulyev (MT6561-RIPE, 2:463/253@FIDO) > > > > > End of ipv6-wg Digest >

1 0

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

29 Nov '05

Citeren ipv6-wg-request(a)ripe.net: > Send ipv6-wg mailing list submissions to > ipv6-wg(a)ripe.net > > To subscribe or unsubscribe via the World Wide Web, visit > http://www.ripe.net/mailman/listinfo/ipv6-wg > or, via email, send a message with subject or body 'help' to > ipv6-wg-request(a)ripe.net > > You can reach the person managing the list at > ipv6-wg-admin(a)ripe.net > > When replying, please edit your Subject line so it is more specific > than "Re: Contents of ipv6-wg digest..." > > > Today's Topics: > > 1. Re: Re: [address-policy-wg] Re: Andre's guide to fix IPv6 (McTim) > 2. Re: [address-policy-wg] Re: Andre's guide to fix IPv6 (Geoff Huston) > 3. Re: [address-policy-wg] Re: [ipv6-wg] IPv6 PI (Randy Bush) > 4. Re: [address-policy-wg] Re: [ipv6-wg] IPv6 PI (Andre Oppermann) > > --__--__-- > > Message: 1 > Date: Tue, 29 Nov 2005 07:19:49 +0300 > From: McTim <dogwallah(a)gmail.com> > To: =?ISO-8859-1?Q?J=F8rgen_Hovland?= <jorgen(a)hovland.cx> > Subject: Re: [ipv6-wg] Re: [address-policy-wg] Re: Andre's guide to fix IPv6 > Cc: ipv6-wg(a)ripe.net > > hiya, > > (removed address-policy-wg from the cc:) > > On 11/28/05, J=F8rgen Hovland <jorgen(a)hovland.cx> wrote: > > > > -----Original Message----- > > From: McTim [mailto:dogwallah@gmail.com] > > > > > >#2 sounds like PI to me. What have I missed? > > > > Hello McTim, > > You are correct. That's why I wrote PI in the email:-). > > I guess I misread the below wrong then ;-) > > J=F8rgen Hovland wrote: > > >> - > >> 1. No PI. _Only_ network operators get a prefix. > > > It is an attempt to suggest an alternative idea to the PI discussion. > > Don't get me wrong. I am for PI. This idea is perhaps a bit more > > hierarchical instead of the standard flat one. Just making sure we have > > thought of everything before we reach consensus > > I am sure thiat consensus will take a very long tiime on this one! We > will probably have to talk about grotopological v6 adressing (as they > are doing on the ARIN ppml) and a host of other issues. I reckon we > ought to wait for shim6 to do their work as well. > > > because this PI discussion > > is very important to ipv6. > > v. true. > > -- > Cheers, > > McTim > $ whois -h whois.afrinic.net mctim > > > --__--__-- > > Message: 2 > Date: Tue, 29 Nov 2005 10:15:27 +1100 > To: =?iso-8859-1?Q?J=F8rgen?= Hovland <jorgen(a)hovland.cx>, > <address-policy-wg(a)ripe.net>, <ipv6-wg(a)ripe.net> > From: Geoff Huston <gih(a)apnic.net> > Subject: [ipv6-wg] Re: [address-policy-wg] Re: Andre's guide to fix IPv6 > > At 03:37 AM 29/11/2005, J=F8rgen Hovland wrote: > >----- Original Message ----- From: "Florian Weimer" <fw(a)deneb.enyo.de> > >Sent: Saturday, November 26, 2005 4:00 PM > > > > > >>* Jeroen Massar: > >> > >>>>1. Make /32 the only routable entity so we can use perfect match in > >>>> the DFZ instead of longest-prefix match. > >>> > >>>What about the organizations that have say a /19, want them to inject > >>>all their more specific /32's? > >> > >>You can inject a /19 as 8192 /32s. Shouldn't make a difference if the > >>/19 is really used. > >> > >>At this stage, it's probably not too wise to embed the /32--/48--/64 > >>in silicon, but vendors will undoubtedly do this if they can save a > >>few bucks and current policies remain as inflexible as they are. > > > >Hi, > >Perfect match is faster but far from better. What I think perhaps would be= > =20 > >interesting to see in the future with regards to IPv6 and PI is the= > following: > > > >1. No PI. _Only_ network operators get a prefix. > >2. Customers of network operators can at any time change provider and take= > =20 > >their assigned prefix with them. The new provider will announce it as a=20 > >more specific overriding the aggregate. If the customer decides to get=20 > >multiple providers, then the network operator with the /32 could also=20 > >announce a more specific. > > > >In the country I live in I can change telecom provider and take my phone=20 > >number with me to the new provider. Why shouldn't I be able to do that=20 > >with internet providers? > >Yes, it will somehow create millions/billions of prefixes (atleasat with=20 > >todays routing technology/protocols). Network operators should be able to= > =20 > >handle that hence rule #1. > > > Interesting - it will work for a while, and then you will get to the limit= > =20 > of deployed capability of routing. > > Then what? > > Geoff > > > > > > --__--__-- > > Message: 3 > 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: 4 > 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 ipv6-wg Digest >

1 0

Re: "Special Application Addresses" (Was: Re: [ipv6-wg] RE: address-policy-wg (ipv6-wg digest, Vol 1 #271 - 11 msgs))
by Jeroen Massar 26 Nov '05

26 Nov '05

peter.sherbin(a)bell.ca wrote: > Jeroen, thanks for your response. > >>> The application has to: >>> 1. avoid renumbering of the network >> Why? Your application should be able to use renumber easily using a form >> of management interface. > > I am using addresses to monitor my devices all the way through their > life cycle. In some cases it could be a physical life cycle from a few > weeks to a few years. I may also aggregate individual items to larger > sub groups. That is why I do not want any changes to static addresses > for unspecified time. The solution for the above can easily be solved by using DNS or a myriad of other solutions. Either you give all those devices a DNS label where they can contact their 'report server' or you give those devices the ability to register to that server. There are many possibilities here and none of these require any specific address space. I suggest you check out mail spam bots and viruses. They implement this all too perfectly well. <SNIP> >> PS: You might want to delete unused parts of emails, sending 27kb of >> quoted email which you don't reference is useless. Also changing the >> subject helps identifying what you are actually mailing about. > > It is a learning curve. will do next time. thanks for pointing this out. I suggest you also read the following article: http://www.xs4all.nl/~hanb/documents/quotingguide.html (Lines 80 chars and more are not very readable either) Greets, Jeroen

1 0

RE: address-policy-wg (ipv6-wg digest, Vol 1 #271 - 11 msgs)
by peter.sherbin＠bell.ca 25 Nov '05

25 Nov '05

>Oliver Bartels: >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. My project requires a few millions of IPv6 addresses. The application has to: 1. avoid renumbering of the network 2. keep allocated addresses for an extended period of time Current ARIN allocation schema: ARIN -> LIR -> End User does not make much sence because to get addresses I: - either have to become a LIR, which I may not necessarily want, or - the entire application depends on fortunes of a third party (LIR), which is a prohibitive risk factor for the investment On the other side I am willing to "rent" addresses from a registry (ARIN) and return the allocation when it is no longer needed. Now, how do we change the current address allocation policy which kills IPv6 in its cradle? Thank you, Peter Sherbin 416 353-5917 >-----Original Message----- >From: ipv6-wg-admin(a)ripe.net [mailto:ipv6-wg-admin@ripe.net] On Behalf Of ipv6- >wg-request(a)ripe.net >Sent: November/25/ 2005 06:00 >To: ipv6-wg(a)ripe.net >Subject: ipv6-wg digest, Vol 1 #271 - 11 msgs > >Send ipv6-wg mailing list submissions to > ipv6-wg(a)ripe.net > >To subscribe or unsubscribe via the World Wide Web, visit > http://www.ripe.net/mailman/listinfo/ipv6-wg >or, via email, send a message with subject or body 'help' to > ipv6-wg-request(a)ripe.net > >You can reach the person managing the list at > ipv6-wg-admin(a)ripe.net > >When replying, please edit your Subject line so it is more specific >than "Re: Contents of ipv6-wg digest..." > > >Today's Topics: > > 1. Re: [address-policy-wg] Re: [ipv6-wg] IPv6 PI (Florian Weimer) > 2. Re: [address-policy-wg] Re: [ipv6-wg] IPv6 PI (Oliver Bartels) > 3. closed network and need for global uniqe IP space (Roger Jorgensen) > 4. Re: [address-policy-wg] Re: [ipv6-wg] IPv6 PI (Roger Jorgensen) > 5. Re: [address-policy-wg] Re: [ipv6-wg] IPv6 PI (Roger Jorgensen) > 6. Re: [address-policy-wg] Re: [ipv6-wg] IPv6 PI (Andre Oppermann) > 7. Re: [address-policy-wg] Re: [ipv6-wg] IPv6 PI (Andre Oppermann) > 8. Re: closed network and need for global uniqe IP space (Gert Doering) > 9. Re: [address-policy-wg] Re: [ipv6-wg] closed network and need for > globa l uniqe IP space (Roger Jorgensen) > 10. Re: [address-policy-wg] Re: [ipv6-wg] closed network and need for globa l >uniqe IP space (Gert Doering) > >--__--__-- > >Message: 1 >From: Florian Weimer <fw(a)deneb.enyo.de> >To: Roger Jorgensen <rogerj(a)jorgensen.no> >Cc: Lea Roberts <lea.roberts(a)stanford.edu>, address-policy-wg(a)ripe.net, ipv6- >wg(a)ripe.net, roger(a)jorgensen.no >Subject: Re: [address-policy-wg] Re: [ipv6-wg] IPv6 PI >Date: Thu, 24 Nov 2005 18:58:04 +0100 > >* Roger Jorgensen: > >> 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. > >I'm a relative newcomer to this area. Could you give a pointer to >some explanation *why* the IPv6 address space size causes this >problem? > > >--__--__-- > >Message: 2 >From: "Oliver Bartels" <oliver(a)bartels.de> >To: "ipv6-wg(a)ripe.net" <ipv6-wg(a)ripe.net>, > "address-policy-wg(a)ripe.net" <address-policy-wg(a)ripe.net>, > "Roger Jorgensen" <rogerj(a)jorgensen.no> >Date: Thu, 24 Nov 2005 19:22:24 +0100 >Reply-To: "Oliver Bartels" <oliver(a)bartels.de> >Subject: Re: [address-policy-wg] Re: [ipv6-wg] IPv6 PI > >On Mon, 21 Nov 2005 17:10:10 +0100 (CET), Roger Jorgensen wrote: >>Can't we all just drop using the word multihoming and IPv6 PI? > >The better solution is the enemy of the good solution. > >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. > >>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. > >Could you please explain this a bit more in detail ? >To me this sounds like "engines will never fly". > >>Last I checked around there were some promissing new proposal on the >>way for how to solve this very basic problem. > >Could you please be a bit more verbose. > >>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. > >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. > >Best Regards >Oliver > > > >Oliver Bartels F+E + Bartels System GmbH + 85435 Erding, Germany >oliver(a)bartels.de + http://www.bartels.de + Tel. +49-8122-9729-0 > > > > > >--__--__-- > >Message: 3 >Date: Fri, 25 Nov 2005 10:12:35 +0100 (CET) >From: Roger Jorgensen <rogerj(a)jorgensen.no> >To: ipv6-wg(a)ripe.net, address-policy-wg(a)ripe.net >cc: roger(a)jorgensen.no >Subject: [ipv6-wg] closed network and need for global uniqe IP space > >Sorry for cross-posting but not sure where it really belong... >----------- > >Hi, > >First, the question is more, what is the correct way of dealing with >situation like this? > > > > >I work for a entity with a big and closed network where security and >being closed came first. We're not governement but we have our mandate >defined by them. >Our only connection to Internet are through several uplinks with few >public IP where we run proxy solution for the little traffic that are >allowed to hit internet. Are in reality no incoming routes to us, and none >out. >Internal we use RFC1918 IP space,(private IP) and we for now have enough >IP space but we are experience conflicts between IP space when connecting >to other big closed network. Not to forget the size, we will probably run >out of IP space to... (and I know others have run out of RFC1918 space on >their internal network) > > >Most would suggest request a /48 or bigger from your uplink right now and >that's not going to work for several reasons: >* size, just one of bigger sites connected probably need more than a /48 >just for themself, and we have several of them, and alot of smaller >sites/network. We're probably talking /32 or more if I have to guess. > >* scalability, we could of course get /48 and break the /64 boundary, >a thought I seriously hate. But that will give us other kind of problems, >sites needing a /64 or more due to some equipment or so... > >* there are other BIGGER network of the same type. > >* control over who is using what IP and where etc... as said above, >security and being closed are probably the two most important factors for >us. > >* need global unique IP's since we're connecting to other network of the >same type, and NAT are not really the way we want to go with IPv6 > >... and probably more I can't remember right now. > > >The solutions aren't really that tricky but let me mention a few >options... >* Site local would have solved our problem BUT it's obsolite, quite >stupid really. > >* just take a prefix and use it... this will give us problem in the future >due to not being unique. > >* extensiv usage of NAT, eh do we really want to even consider THAT for >IPv6? > >* become LIR and request the needed IP space. > >* let one of our uplinks request the IP space for us. > > > >I'm in favour of the last two options, any of them... and they are as I >see it the really two options as things are now. Any thoughts? comments? > > > >-- > >------------------------------ >Roger Jorgensen | >rogerj(a)stud.cs.uit.no | - IPv6 is The Key! >http://www.jorgensen.no | roger(a)jorgensen.no >------------------------------------------------------- > > >--__--__-- > >Message: 4 >Date: Fri, 25 Nov 2005 10:36:25 +0100 (CET) >From: Roger Jorgensen <rogerj(a)jorgensen.no> >To: Florian Weimer <fw(a)deneb.enyo.de> >cc: address-policy-wg(a)ripe.net, ipv6-wg(a)ripe.net, roger(a)jorgensen.no >Subject: Re: [address-policy-wg] Re: [ipv6-wg] IPv6 PI > >On Thu, 24 Nov 2005, Florian Weimer wrote: >> * Roger Jorgensen: >> >> > 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. >> >> I'm a relative newcomer to this area. Could you give a pointer to >> some explanation *why* the IPv6 address space size causes this >> problem? > >Just do the math yourself and consider all possibilities and how the IPv4 >space are used... but some numbers > >- the address space is 128bit. >- we have a 64bits host prefix at the lower end. >- the above give us 64bits of network numbers, that's quite a few billions >of networks. BUT >- the /48 boundary leaving us with a usable globaly network space of 48bit >- from the 48bits only a /8 are usable as it is now, the other 7 /8 are >reserved for the future. > >The absolute max global routing table would by this be 40bits, of >course the real one are alot smaller. That one is closer to 32bits, and >that is STILL A huge number, probably more close to 20bits of entries. > > > >a last comment: the entire idea behind /64 and /48 will cause IPv6 to fail >as it is now. Odd as it is, we don't have enough IP space in IPv6. Sure it >will last 10, maybe 15-20 years, but that did IPv4 to...... > > > >-- > >------------------------------ >Roger Jorgensen | >rogerj(a)stud.cs.uit.no | - IPv6 is The Key! >http://www.jorgensen.no | roger(a)jorgensen.no >------------------------------------------------------- > > >--__--__-- > >Message: 5 >Date: Fri, 25 Nov 2005 10:55:54 +0100 (CET) >From: Roger Jorgensen <rogerj(a)jorgensen.no> >To: Oliver Bartels <oliver(a)bartels.de> >cc: "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 > >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 >------------------------------------------------------- > > >--__--__-- > >Message: 6 >Date: Fri, 25 Nov 2005 10:58:43 +0100 >From: Andre Oppermann <oppermann(a)networx.ch> >To: Roger Jorgensen <rogerj(a)jorgensen.no> >CC: Florian Weimer <fw(a)deneb.enyo.de>, address-policy-wg(a)ripe.net, > ipv6-wg(a)ripe.net, roger(a)jorgensen.no >Subject: Re: [address-policy-wg] Re: [ipv6-wg] IPv6 PI > >Roger Jorgensen wrote: >> >> On Thu, 24 Nov 2005, Florian Weimer wrote: >> > * Roger Jorgensen: >> > >> > > 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. >> > >> > I'm a relative newcomer to this area. Could you give a pointer to >> > some explanation *why* the IPv6 address space size causes this >> > problem? >> >> Just do the math yourself and consider all possibilities and how the IPv4 >> space are used... but some numbers >> >> - the address space is 128bit. >> - we have a 64bits host prefix at the lower end. >> - the above give us 64bits of network numbers, that's quite a few billions >> of networks. BUT >> - the /48 boundary leaving us with a usable globaly network space of 48bit >> - from the 48bits only a /8 are usable as it is now, the other 7 /8 are >> reserved for the future. >> >> The absolute max global routing table would by this be 40bits, of >> course the real one are alot smaller. That one is closer to 32bits, and >> that is STILL A huge number, probably more close to 20bits of entries. >> >> a last comment: the entire idea behind /64 and /48 will cause IPv6 to fail >> as it is now. Odd as it is, we don't have enough IP space in IPv6. Sure it >> will last 10, maybe 15-20 years, but that did IPv4 to...... > >You post is still pretty content-free. You're waving with your hand >but what do you propose exactly? I've posted my proposals under "Andre's >guide to fix IPv6". When do you with yours? > >-- >Andre > > >--__--__-- > >Message: 7 >Date: Fri, 25 Nov 2005 11:02:45 +0100 >From: Andre Oppermann <oppermann(a)networx.ch> >To: Roger Jorgensen <rogerj(a)jorgensen.no> >CC: 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 > >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. > >We're thinking Real World(TM). > >> 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. > >That's only part of the reasoning. Customers don't want to be locked >in to any one ISP. They want to have bargaining power which only comes >with the ability to switch ISPs at will. > >> <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. > >Yea, that's known as SCTP. > >> That's just ONE of many possible ways... > >You're only handwaiving and saying "no". We are looking for ways to fit >IPv6 to the reality of how millions of people and corporations use and >want to use the Internet, technically and commercially. > >-- >Andre > > >--__--__-- > >Message: 8 >Date: Fri, 25 Nov 2005 11:18:46 +0100 >From: Gert Doering <gert(a)space.net> >To: Roger Jorgensen <rogerj(a)jorgensen.no> >Cc: ipv6-wg(a)ripe.net, address-policy-wg(a)ripe.net, roger(a)jorgensen.no >Subject: Re: [ipv6-wg] closed network and need for global uniqe IP space > >Hi, > >On Fri, Nov 25, 2005 at 10:12:35AM +0100, Roger Jorgensen wrote: >> The solutions aren't really that tricky but let me mention a few >> options... >> * Site local would have solved our problem BUT it's obsolite, quite >> stupid really. > >That's why there are ULA ("unique local addresses") now. They should >fit your needs pretty well - as much addresses as you want, and the >guarantee to be not officially assigned to anyone. > >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 > > >--__--__-- > >Message: 9 >Date: Fri, 25 Nov 2005 11:25:07 +0100 (CET) >From: Roger Jorgensen <rogerj(a)jorgensen.no> >To: Gert Doering <gert(a)space.net> >cc: ipv6-wg(a)ripe.net, address-policy-wg(a)ripe.net, roger(a)jorgensen.no >Subject: Re: [address-policy-wg] Re: [ipv6-wg] closed network and need for > globa l uniqe IP space > >On Fri, 25 Nov 2005, Gert Doering wrote: >> Hi, >> >> On Fri, Nov 25, 2005 at 10:12:35AM +0100, Roger Jorgensen wrote: >> > The solutions aren't really that tricky but let me mention a few >> > options... >> > * Site local would have solved our problem BUT it's obsolite, quite >> > stupid really. >> >> That's why there are ULA ("unique local addresses") now. They should >> fit your needs pretty well - as much addresses as you want, and the >> guarantee to be not officially assigned to anyone. > >what about the other part about globaly unique when we connect to other >network of the same type? > > > >-- > > >------------------------------ >Roger Jorgensen | >rogerj(a)stud.cs.uit.no | - IPv6 is The Key! >http://www.jorgensen.no | roger(a)jorgensen.no >------------------------------------------------------- > > >--__--__-- > >Message: 10 >Date: Fri, 25 Nov 2005 11:38:44 +0100 >From: Gert Doering <gert(a)space.net> >To: Roger Jorgensen <rogerj(a)jorgensen.no> >Cc: Gert Doering <gert(a)space.net>, ipv6-wg(a)ripe.net, > address-policy-wg(a)ripe.net, roger(a)jorgensen.no >Subject: Re: [address-policy-wg] Re: [ipv6-wg] closed network and need for globa > l uniqe IP space > >Hi, > >On Fri, Nov 25, 2005 at 11:25:07AM +0100, Roger Jorgensen wrote: >> > On Fri, Nov 25, 2005 at 10:12:35AM +0100, Roger Jorgensen wrote: >> > > The solutions aren't really that tricky but let me mention a few >> > > options... >> > > * Site local would have solved our problem BUT it's obsolite, quite >> > > stupid really. >> > >> > That's why there are ULA ("unique local addresses") now. They should >> > fit your needs pretty well - as much addresses as you want, and the >> > guarantee to be not officially assigned to anyone. >> >> what about the other part about globaly unique when we connect to other >> network of the same type? > >The idea is that ULAs are random-generated in a way that makes it "fairly >unlikely" that you end up in an address collision. But there is no >guarantee, of course. > >There is also a second sort of ULAs that are globally unique but still >private, but as far as I know, there is no registry yet that will hand >them out. So these can't be used yet. > >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 > > > > >End of ipv6-wg Digest

2 1

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 5

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

Draft Minutes (v1) of IPv6 WG session RIPE51
by David Kessens 22 Oct '05

22 Oct '05

Please see enclosed the first version of the minutes of our session at RIPE51. I plan to declare the minutes final if I don't receive any comments for significant changes by November 4th 2005. I would like to thank Timothy Lowe from the RIPE NCC for taking the minutes. David Kessens --- Minutes IPv6 Working Group session Amsterdam, 12 Oct, 2005 Chair: David Kessens Scribe: Timothy Lowe # of attendees: 95 ACTION 51.1 - Ask the RIPE NCC to revise the acronym list in the registration package to remove obsolete terms as TLA & NLA (David Kessens) Status: Completed ACTION 51.2 - Create a link from the IPv6 WG page to the APNIC events page: http://apnic.net/info/calendar/index.html (RIPE NCC) Status: To be done ACTION 51.3 - Provide traffic reports on ipv6 usage during the RIPE meetings. If available, data from earlier meetings will be made available as well. (RIPE NCC) A. Administrative stuff Appointment of scribe: Timothy Lowe Agenda bashing: No additions to agenda Action point 51.1 was decided. B. Quick update from the RIPE NCC regarding ipv6 services (RIPE NCC) No news from the RIPE NCC C. IPv6 events calendar on the ipv6 working group page (proposed by Timothy Lowe) It was decided that similar event pages already exist and that we can simply provide a link to the APNIC event pages. (See action point D. Discussion on: Global IPv6 routing table status (Gert Doering, Spacenet) Discussion on filtering: Gert Doering: The RIPE Whois database is the only one allowing route6 object creation. Iljitsch Van Beijnum: What is the gain of filtering less specific ? Geoff Huston: What problem are you trying to solve ? Gert Doering: Trying to prevent accident, less maintenance if the documentation is in the database then it will be more stable. Conclusion: as we cannot force people to filter, we will see more specifics anyways (David Kessens) E. Report(s) about *actual* v6 traffic volume as compared to v4? *what's real* out there, not what's on powerpoint? - http://www.sixxs.net/misc/traffic/ (Jeroen Massar) Pointer to Jeroen's website was provided, but content was not discussed. Pim van Pelt offered to do some work to provide more data on his Sixxs ipv6 service but it was decided that the amount of work was probably not worth the effort. Discussed whether any ipv6 usage data from the RIPE meetings itself was available. This discussion resulted in a request and an action point for the RIPE NCC to provide us such data in the future (Action point 51.3) F. The end of the 6bone address space is in sight (Jeroen Massar) Discussion: - what are people going to do with 6bone address space as - per 6/6/6 ? - filter it? - keep it going? - warn people? - what to do with the 6bone registry ? Iljisch v B.: DNS is not auto-configurable in IPv6 like it is in IPv4 so I would like to use 6bone to get an ipv6 assignment for an experiment for well-known ipv6 DNS resolver addresses. Geoff H. : IANA has released a statment that 6bone dies on 06/06/2006. Gerd D.: exactly, what will people do when this happens? No uniform policy on what to do with 6bone prefixes. Some people will start filtering while others won't bother. In general, people advised David Kessens who maintains the 6bone registry to stop accepting registry changes by the close date but to keep the data online for some time to come with proper warning message when information is accessed. G. Developments/initiatives regarding IPv6 in the RIPE region and beyond - 6DISS (Bernard Tuy) Presentation will be available on the RIPE website as soon as Bernard Tuy provides the slides No questions. H. Input for the RIPE NCC Activity Plan (no input from the audience) Z. AOB Peter Koch drew attention to a presentation in the DNS working group regarding the deprecation of IP6.int. ----

2 1

Re: [6bone] RIPE and IPv6 ASN
by marko ramljak 07 Oct '05

07 Oct '05

On Tue, 15 Oct 2002, Arien Vijn wrote: > On 15-10-2002 17:00PM, "Nicolas DEFFAYET" <nicolas.deffayet@localhost > wrote: > > > On Tue, 2002-10-15 at 16:33, Bill Manning wrote: > >> % 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. > >> > >> this is not the first v6 enabled exchange in France. > >> there are three other exchanges which are v6 enabled. > >> > > > > This other Internet Exchange in France are IPv4 and IPv6 Internet > > Exchange (dualstack). > > IPv6 Internet Exchange = IPv6 only > > Why? Is what we are doing not IPv6? > > Arien IPv6 only = Purely IPv6 (no IPv4 legacy stuff!) I've understood it as a marketing issue... :-) Nicolas, about the problem: If you get LIR Status you'll probably get your ASN quickly. Regards, ./Carlos "Networking is fun!"

2 1

Draft Agenda (v2) for ipv6 wg RIPE51
by David Kessens 05 Oct '05

05 Oct '05

Please see below for the draft agenda (v2) of the ipv6 working group. We still have some room in the agenda so let me know if there is anything that you would like to discuss. As mentioned before, I would also like to draw your attention to the plenary part of the meeting that has various interesting ipv6 presentations on the agenda (see below). David Kessens --- Draft Agenda (v2) for the IPv6 Working Group Meeting RIPE51 When: Wednesday, October 12, 2005, 17:00-18:00 Where: Grand Ballroom, Hotel Krasnapolsky, Amsterdam A. Administrative stuff - appointment of scribe - agenda bashing (David Kessens) B. Quick update from the RIPE NCC regarding ipv6 services (RIPE NCC) C. IPv6 events calendar on the ipv6 working group page (proposed by Timothy Lowe) D. Discussion on: Global IPv6 routing table status (Gert Doering) routing policy: - is it mandatory to register route6's and inet6num's or is it just 'being nice' ? - is the trend going to be that >/32's will be announced as separate /32's? what is the correct plan for shorter than /32 prefixes ? E. Report(s) about *actual* v6 traffic volume as compared to v4? *what's real* out there, not what's on powerpoint? - http://www.sixxs.net/misc/traffic/ (Jeroen Massar) - ... (input from the audience) F. The end of the 6bone address space is in sight (Jeroen Massar) Discussion: - what are people going to do with 6bone address space as per 6/6/6 ? - filter it? - keep it going? - warn people? - what to do with the 6bone registry ? G. Developments/initiatives regarding IPv6 in the RIPE region and beyond - 6DISS (Bernard Tuy) - ... (input from the audience) H. Input for the RIPE NCC Activity Plan (input from the audience) Z. AOB --- Interesting topics in the plenary section: TUESDAY 09:00 - 10:30 6. IPv6 Routing Update. Gert Doering. Spacenet (20 min) Update on observations on the state of the IPv6 default free routing table. 7. IPv6 Multihoming Status. Kurtis Lindqvist. Netnod (30 min) An up-to-date status report on the progress towards scalable IPv6 multihoming. 8. IPv6 Address Allocation --An Alternative Algorithm for the Sparse Allocation Process. Mae Wang (30 min) IP address allocation policies significantly impact the Internet infrastructure, affecting many parties such as router manufacturers, ISPs, and end users. An address allocation policy can also directly affect the performance of the Internet. For example, address fragmentation, a key problem in IPv4, degrades address lookup performance in routers. Thus, a well-designed address allocation policy needs to minimise fragmentation while using the address space efficiently. This paper attempts to quantify the performance of address allocation policies by modelling key features that lead to fragmentation and inefficient address space usage. Our main contributions are: (i) we identify a drawback of the current IPv6 address allocation policy, which treats all entities uniformly, (ii) we propose a scheme that takes future growth rate into account for allocations, and (iii) an analytical model for measuring the efficiency of allocation schemes, allowing us to quantify the improvement our proposal offers over the current scheme. We believe that a quantitative study of allocation policies is timely since IPv6 address allocation is just beginning in earnest.

1 0

RE: [ipv6-wg] Draft Agenda (v1) for ipv6 wg RIPE51
by Mattias.Lignell＠teliasonera.com 03 Oct '05

03 Oct '05

Hello again, I will have a second look at this and discuss the issue internally. I sure hope we can remove the /32's. /// Mattias > -----Original Message----- > From: Jeroen Massar [mailto:jeroen@unfix.org] > Sent: Monday, October 03, 2005 7:15 PM > To: Lignell, Mattias E. > Cc: gert(a)space.net; david.kessens(a)nokia.com; eva(a)telia.net; > Lind, Mikael E.; amar(a)telia.net; ipv6-wg(a)ripe.net > Subject: RE: [ipv6-wg] Draft Agenda (v1) for ipv6 wg RIPE51 > > On Mon, 2005-10-03 at 18:59 +0200, Mattias.Lignell(a)teliasonera.com > wrote: > > Hello all, > > > > About the /32's; they are announced on purpose. The reason > is that we > > have had problems with some ISP's BGP filters that are set to a > > maximum size of /32. As a result did not our IPv6 customers get > > connectivity via ISP's using the /32 size filters. Maybe this is a > > problem only we run in to being one of the first using a very large > > prefix. However, the BGP filters may be updated by now so > we can stop announcing the /32's. > > Thanks for the response, the prefix filtering is not too good > to hear and has been seen before; I know that Daniel Roesen > has been very busy trying to get C&W's /20 available to ISP's > using, amongst others, the output from: > http://www.sixxs.net/tools/grh/compare/?a=2001:5000::/21&b=200 > 1:650::/32 > At the moment apparently Cisco doesn't see the /21... > > This can be easily applied to Telia's /20: > http://www.sixxs.net/tools/grh/compare/?a=2001:2000::/20&b=200 > 1:2040::/32 > > This compares 2001:2000::/20 with 2001:2040::/32. > Taking a quick look it looks quite good, ignoring the light > orange which is there because of the added ASN. There are > only few ISP's who report different paths: > AS 6435 - LavaNet (us / Hawaii) > AS 9264 - Academic Services Network (tw) > AS21155 - Proserve (nl) > AS28788 - Unilogic (nl) {using same upstreams as AS21155) > > You might want to contact these ISP's to ask them + upstreams > to fix their filtering, clearly something is being filtered, > otherwise the paths where the same. > > Greets, > Jeroen > >

1 0

RE: [ipv6-wg] Draft Agenda (v1) for ipv6 wg RIPE51
by Mattias.Lignell＠teliasonera.com 03 Oct '05

03 Oct '05

Hello all, About the /32's; they are announced on purpose. The reason is that we have had problems with some ISP's BGP filters that are set to a maximum size of /32. As a result did not our IPv6 customers get connectivity via ISP's using the /32 size filters. Maybe this is a problem only we run in to being one of the first using a very large prefix. However, the BGP filters may be updated by now so we can stop announcing the /32's. Please note that this has been a temporary work around to maintain connectivity for our customers. We also have old prefixes that we are about to return to RIPE (2001:06C0::/35), but not yet had time to shout down (affects many customers and links). It is of-cause the policy of the TeliaSonera group to normally only announce one prefix. Any comments to this are most welcome. Best regards /// Mattias Lignell -------------------------------------------------------------- Mattias Lignell TeliaSonera Sweden, IP-Networks Phone: +46 8 713 3706 Mobile: +46 70 595 9068 Fax: +46 70 615 6245 Email: mattias.lignell(a)teliasonera.com Address: Vitsandsgatan 9, House-D, 123 86 Farsta, SWEDEN ICQ UIN: 18690075 -------------------------------------------------------------- > ------------------------------------------------------------- > ----- Original Message ----- > From: "Jeroen Massar" <jeroen(a)unfix.org> > To: "Gert Doering" <gert(a)space.net>; "David Kessens" > <david.kessens(a)nokia.com> > Cc: "Amar Andersson" <amar(a)telia.net>; <ipv6-wg(a)ripe.net> > Sent: Friday, September 30, 2005 3:06 PM > Subject: Re: [ipv6-wg] Draft Agenda (v1) for ipv6 wg RIPE51 > > On Thu, 2005-09-29 at 20:46 -0700, David Kessens wrote: One discussion point you might want to raise: - what are people going to do with 6bone address space as per 6/6/6 ? - filter it? - keep it going? - warn people? In january I will send out a note to all the folks still announcing 6bone prefixes to remind them that they should be shutting it down per 6/6/6. There doesn't seem to be a large movement in doing so yet... > C. Discussion on: > Global IPv6 routing table status > (Gert Doering) Maybe something related might be noted here, in the global routing tables I've seen for instance, just a 'random' targetted pick. http://www.sixxs.net/tools/grh/lg/?find=2001:2000::/20 [Notez bien: the question here is about what is going to become the common policy and what is going to happen to the ipv6 routing, it is not to 'attack' or critize an ISP on what they are doing] 2001:2000::/20 announced by AS1299 (TELIANET) 2001:2040::/32 AS3301 (TELIA-SWEDEN) 2001:2060::/32 AS1759 (SONERA-TRANSIT-AS) No route6 for these 3 prefixes and no inet6nums exist for the the two /32's. Which leads me to a couple of questions: - is it mandatory to register route6's and inet6num's or is it just 'being nice' - is the trend going to be that >/32's will be announced as separate /32's? This of course means that the ISP can be found under one block but still affects the number of routes in the routing table. One could filter the smaller ones if the parent route is present. The idea of minimizing routing table size (yes that is not an issue now, but behold the future) is totally gone when ISP's will do this. I do understand why: to make the branches independant and attract the traffic as local as possible. On the otherside there are also ISP's simply requesting multiple separate /32's from the various RIR's. eg UUNet: 2001:0600::/32 - Europe 2001:4440::/32 - Hongkong 2001:4441::/32 - Australia 2001:4442::/32 - Japan 2001:0588::/32 - South Africa (I am ignoring the 6bone block they still have, with 1 other already returned, as that one will disappear anyway) The question in case of this setup is, why didn't they get 1 block? The generic question: what is the correct plan for these setups? > D. Report(s) about *actual* v6 traffic volume as compared to v4? > *what's real* out there, not what's on powerpoint? > (input from the audience) http://www.sixxs.net/misc/traffic/ :) Not much, but it is a bit and for the moment declining a bit weirdly enough. <SNIP> > For example, address fragmentation, a key problem in IPv4, degrades > address lookup performance in routers. Thus, a well-designed > address allocation policy needs to minimise fragmentation while > using the address space efficiently. See my related note above. Greets, Jeroen

2 1

Draft Agenda (v1) for ipv6 wg RIPE51
by David Kessens 30 Sep '05

30 Sep '05

Hi, Please see below for the draft agenda (v1) of the ipv6 working group. This is the first version of the agenda so we are still looking for agenda topics and contributions for the various standard sections of the agenda. Please let me know if there is anything that you would like to discuss. I would also like to draw your attention to the plenary part of the meeting that has various interesting ipv6 presentations on the agenda (see below). David Kessens --- Draft Agenda (v1) for the IPv6 Working Group Meeting RIPE51 When: Wednesday, October 12, 2005, 17:00-18:00 Where: Grand Ballroom, Hotel Krasnapolsky, Amsterdam A. Administrative stuff - appointment of scribe - agenda bashing (David Kessens) B. Quick update from the RIPE NCC regarding ipv6 services (RIPE NCC) C. Discussion on: Global IPv6 routing table status (Gert Doering) D. Report(s) about *actual* v6 traffic volume as compared to v4? *what's real* out there, not what's on powerpoint? (input from the audience) E. Developments/initiatives regarding IPv6 in the RIPE region and beyond (input from the audience) F. Input for the RIPE NCC Activity Plan (input from the audience) Z. AOB --- Interesting topics in the plenary section: TUESDAY 09:00 - 10:30 6. IPv6 Routing Update. Gert Doering. Spacenet (20 min) Update on observations on the state of the IPv6 default free routing table. 7. IPv6 Multihoming Status. Kurtis Lindqvist. Netnod (30 min) An up-to-date status report on the progress towards scalable IPv6 multihoming. 8. IPv6 Address Allocation --An Alternative Algorithm for the Sparse Allocation Process. Mae Wang (30 min) IP address allocation policies significantly impact the Internet infrastructure, affecting many parties such as router manufacturers, ISPs, and end users. An address allocation policy can also directly affect the performance of the Internet. For example, address fragmentation, a key problem in IPv4, degrades address lookup performance in routers. Thus, a well-designed address allocation policy needs to minimise fragmentation while using the address space efficiently. This paper attempts to quantify the performance of address allocation policies by modelling key features that lead to fragmentation and inefficient address space usage. Our main contributions are: (i) we identify a drawback of the current IPv6 address allocation policy, which treats all entities uniformly, (ii) we propose a scheme that takes future growth rate into account for allocations, and (iii) an analytical model for measuring the efficiency of allocation schemes, allowing us to quantify the improvement our proposal offers over the current scheme. We believe that a quantitative study of allocation policies is timely since IPv6 address allocation is just beginning in earnest. ------

3 2

RIPE Policy Development Process
by Paul Rendek 01 Sep '05

01 Sep '05

Dear Colleagues We are pleased to announce that Rob Blokzijl, RIPE Chair, has published a new RIPE Document, "Policy Development Process in RIPE", (ripe-350). This document formally describes the policy development process. The updated process is operational from today, 1 September 2005. A new RIPE web page describes all the active policy proposals and their status. Each proposal has a page showing its history, status and all supporting documentation. This page can be found at: http://www.ripe.net/ripe/policies/proposals/index.html A new mailing list <policy-announce(a)ripe.net> has been created for announcing policy proposals and tracking them through the policy development process. This is not a discussion list; discussions will continue to take place on relevant RIPE Working Group lists and at RIPE Meetings. You can subscribe to the policy-announce list at: http://www.ripe.net/mailman/listinfo/policy-announce List archives are available at: http://www.ripe.net/ripe/maillists/archives/policy-announce/ Kind regards Paul Rendek Head of Member Services and Communications RIPE NCC

1 0

New Document available: RIPE-349
by RIPE NCC Document Announcement Service 27 Jul '05

27 Jul '05

New RIPE Document Announcement -------------------------------------- A new document is available from the RIPE Document store. Ref: ripe-349 Title: Address Space Managed by the RIPE NCC Author: Leo Vegoda RIPE NCC Date: 27 July 2005 Format: PDF=31257 TXT=2986 Obsoletes: ripe-348 Short content description ------------------------- This document details the address space managed by the RIPE NCC and the longest prefixes allocated or assigned from different address ranges. The new version was needed to correct errors in the previous document. Accessing the RIPE Document store --------------------------------- You can access this RIPE Documents in HTML format at: http://www.ripe.net/docs/ripe-349.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 document on the FTP-server are: ftp://ftp.ripe.net/ripe/docs/ripe-349.pdf PDF version ftp://ftp.ripe.net/ripe/docs/ripe-349.txt plain text version

1 0

Re: raw ipv6 sockets - sin6_scope_id field
by Aviraj Saha 25 Jul '05

25 Jul '05

Hi This value needs to be set to the interface index which is returned by the "ip link" command if you are using link local address, and if the 3 rd and 4 th byte is zero. Otherwise the value which is set in the third and fourth byte of the in6_addr structure. Hope this answers your question. With Regards Aviraj Saha

1 0

[ipv6-wg@ripe.net] New IPv6 Address Block Allocated to RIPE NCC
by leo vegoda 22 Jul '05

22 Jul '05

Dear Colleagues, The RIPE NCC received the IPv6 address range 2A01:0000::/23 from the IANA in July 2005. We will begin making allocations from this block in the near future. You may wish to adjust any filters you have in place accordingly. More information on the IP space administered by the RIPE NCC can be found on our web site at: https://www.ripe.net/ripe/docs/ripe-ncc-managed-address-space.html This document has been updated to to provide extra information about the IPv6 address space we manage, following some requests we received. I hope people find the new format useful. Regards, -- leo vegoda Registration Services Manager RIPE NCC

2 3

[ipv6-wg@ripe.net] Allocation behaviour (organisations getting multiple /32's)]
by John Tran 19 Jul '05

19 Jul '05

Hi Jeroen, It is great to know that you are paying attention to allocations that are being made in other region. I would like to clarify the reason why APNIC made muliple allocations to UUNET. UUNET have multiple memberships with APNIC based on the networks in the region. As each economy, membership, managing their own address space therefore they also requesting for IP address separately. For aggregation purpose APNIC normally make allocations from contiguous block, as you can see from these allocations. This is similar to making a large allocation to an organisation then they further splitting between network for each economy. I hope the above explanation answered some of your queries if you need further information please feel free to contact us. Regards Son APNIC > > -------- Original Message -------- > Subject: [ipv6-wg(a)ripe.net] Allocation behaviour (organisations getting > multiple /32's) > Date: Sat, 09 Jul 2005 12:52:33 +0200 > From: Jeroen Massar <jeroen(a)unfix.org> > Organization: Unfix > To: ipv6-wg(a)ripe.net > > I just noticed that UUNET/MCI got an additional 3 /32's: > > inet6num: 2001:4441::/32 > netname: UUNET-AU-NETBLOCK-20050708 > descr: UUNET Australia Limited > descr: UUNET Network > country: AU > > inet6num: 2001:4440::/32 > netname: UUNET-HK-NETBLOCK-20050708 > descr: UUNET Worldcom Hong Kong Ltd > descr: UUNET Network > country: HK > > inet6num: 2001:4442::/32 > netname: UUNET-JP-NETBLOCK-20050708 > descr: UUNET Japan, Ltd > descr: UUNET Network > country: JP > > They where all assigned to 1 person, who apparently works for UUNET/MCI > in the US, not even the APNIC region, not even a role. > > Did somebody say goodbye to aggregation? > > Btw UUNET also has: > 2001:600::/32 (Europe) > > Apparently nothing in the US, in total 4x /32. 4 slots gone away. > Are all global companies going to request separate /32's ? > > Greets, > Jeroen > > > > -- > > _____________________________________________________________________ > Anne Lord, Communications Director <anne(a)apnic.net> > Asia Pacific Network Information Centre (APNIC) Tel: +61-7-3858-3100 > PO Box 2131 Milton, QLD 4064 Australia Fax: +61-7-3858-3199 > --------------------------------------------------------------------- >

3 3

[ipv6-wg@ripe.net] ipv6-enabled webserver
by Thu Thuy 18 Jul '05

18 Jul '05

Hi, all I'm in my way to investigate on ipv6 trial and implementation. Now i'm stucking with a quite big question on ipv6-enabled software. As i saw, ipv6 web services is entirely implemented in almost such large ipv6 research projects as KAME, WIDE, GEANT... In Japan, some ISPs offer ipv6 web hosting to their customers. Many websites support native ipv6 such as RIPE, APNIC... Could you pls show me what kind of webserver software be used in above-mentioned projects and organisations to fully implement ipv6 web service to users. Thanks.

6 9

[ipv6-wg@ripe.net] Allocation behaviour (organisations getting multiple /32's)
by Jeroen Massar 09 Jul '05

09 Jul '05

I just noticed that UUNET/MCI got an additional 3 /32's: inet6num: 2001:4441::/32 netname: UUNET-AU-NETBLOCK-20050708 descr: UUNET Australia Limited descr: UUNET Network country: AU inet6num: 2001:4440::/32 netname: UUNET-HK-NETBLOCK-20050708 descr: UUNET Worldcom Hong Kong Ltd descr: UUNET Network country: HK inet6num: 2001:4442::/32 netname: UUNET-JP-NETBLOCK-20050708 descr: UUNET Japan, Ltd descr: UUNET Network country: JP They where all assigned to 1 person, who apparently works for UUNET/MCI in the US, not even the APNIC region, not even a role. Did somebody say goodbye to aggregation? Btw UUNET also has: 2001:600::/32 (Europe) Apparently nothing in the US, in total 4x /32. 4 slots gone away. Are all global companies going to request separate /32's ? Greets, Jeroen

1 0

[ipv6-wg@ripe.net] Minutes IPv6 WG RIPE 50
by David Kessens 18 Jun '05

18 Jun '05

I did not receive any comments on the draft minutes (v1) by June 10. Therefore, the draft minutes (v1) are now the official minutes of our session during RIPE 50 except for one typo that I found myself, in the last sentence, please replace 'exepected' by 'expected'. Thanks, David Kessens --- ----- Forwarded message from David Kessens <david.kessens(a)nokia.com> ----- Date: Tue, 31 May 2005 20:42:40 -0700 From: David Kessens <david.kessens(a)nokia.com> To: ipv6-wg(a)ripe.net Cc: meeting(a)ripe.net Please see below for our first cut of the minutes for our working group session during RIPE 50. Please let me know if you have any comments or corrections. The minutes will be declared final by Friday, June 10, 2005 if no significant changes (other than typo fixes and minor editorial issues) are found. David Kessens --- Draft Minutes (v1) IPv6 WG RIPE 50 When: Friday, 6 May 2005, 09:00 - 10:30 Where: C58, Clarion Hotel, Stockholm, SE Minute Taker: Adrian Bedford Quick Update from the RIPE NCC Regarding IPv6 Services (Ruud de Kooter - RIPE NCC) After the presentation, Ruud was asked if there were plans to integrate the IPv6 whois interface with the main whois. Currently the proxy cannot talk to the interface and this hampers some functionality (such as rate limiting). Ruud asked Shane Kerr to answer this. Shane explained that the RIPE NCC has a v6 proxy running over a v4 database backend. The RIPE NCC has been looking at how people use the database for two years and patterns suggest that now would be a good time to integrate native IPv6 into the server using /48 as a client identifier. Discussion on: Global IPv6 Routing Table Status (Gert Doering, Spacenet) Gert indicated that the Routing Working Group was discussing best practices for BGP filters. The overall thrust of the presentation was that v6 is growing smoothly with no big disasters so far. A question was asked about ratio comparison between the numbers of Autonomous Systems (AS) announced by IPv6 networks as opposed to v4. The current data suggests that there are 1.419 announced entries per originating AS for v6 and 10.308 for v4. A point was made that Deutsche Telecom (DT), who have one of the largest v6 allocations made to date would not announce their block as one AS, they would be more likely to split this and allocate blocks to different service providers for political reasons. Someone from DT commented that the company has the right to do this, though denied that the move was in any way politically motivated. Renumbering IPv6 Networks (Stig Venaas, Uninett & Tim Chown, University of Southampton) After the presentation, it was mentioned that we are assuming that customers of service providers will keep their space, yet ten years ago major providers did force renumbering onto customers. It was agreed that renumbering of IPv6 is, at least in principal, no different to what happened with v4. Developments/Initiatives Regarding IPv6 in the RIPE Region and Beyond - Francis Dupont: Point6 (http://www.point6.net/ - Gert Doering: A new maillist for discussion of ipv6 operational issues was started: http://lists.cluenet.de/mailman/listinfo/ipv6-ops/ After the announcement of the list, it was agreed that having a publicly available archive of this new list would be a good idea. Although it exists on the site that hosts the list, this is a personal website and for stability purposes, maybe a copy of the archive should be placed elsewhere. It was felt that the RIPE website was unsuitable for this. - Carlos Friacas: o IPv6 - Advanced Network Developments's first year in Portugal o 9K IPv6 Schools' Network Initiative o About the IPv6 Steering Committee Revisiting the /48 recommendation There was a lengthy discussion around RFC 3177. It was made clear that the discussion was not intended to reach final consensus on all the issues involved, but merely to serve as a way to get an idea about the general direction on where the community would like to go to make it possible to write up an initial proposal. Many agreed that the /48 is too much for many users for now and in the future. A discussion followed about how we should define a site with the suggestion that we need to accept that this can remain a grey area, which is not at all well defined right now. Discussion is needed around this topic, though the group tended to accept that it might not be easy to put down limits in black and white. Most people in the room felt that RFC3177 needs a revision. Most people felt that the /48 limit itself doesn't need to be changed, but most agreed that there is a need for a new category that falls somewhere between /48 and /64 for users that have a need for subnetting but for which a /48 seems excessive. This category would fit the mass consumermarket or (very) small office market, however, it was noted that we should base the category on technical needs of the user, not in economic terms like mass consumer market. It is exepected that an Internet Draft will be written that can be discussed at RIPE 51. ----- End forwarded message -----

1 0

[ipv6-wg@ripe.net] documenting RIPE critical infrastructure/micro allocations
by Bjoern A. Zeeb 02 Jun '05

02 Jun '05

Hi, while updating some prefix filters I started a link collection documenting the entries. I have found that other RIRs (ARIN, APNIC) have neat documentation about the critical infrastructure/micro allocations assigned but I only found two references of the Block RIPE uses for v6 IXP assignments. | ARIN Critical infrastructure, micro allocations | http://www.arin.net/reference/micro_allocations.html | APNIC Critical infrastructure, micro allocations | http://www.apnic.net/db/ranges.html For LACNIC I haven't found any assignments but following documentation: | LACNIC Critical infrastructure, micro allocations | http://lacnic.net/en/politicas/ipv6.html 5.5. IPv6 micro allocations | http://lacnic.net/documentos/politicas/micro-asignaciones_ipv6-sp.pdf For RIPE Gert's page is talking about 2001:7F8::/29 and the DB entry. | http://www.ripe.net/whois?searchtext=EU-ZZ-2001-07F8 | http://www.ripe.net/ripe/docs/ipv6-policy-ixp.html Could someone add documentation/web page stating that RIPE is doing /48 assignments from this Block for critical infrastructure (read: IXPs)? Perhaps also giving a list of which prefixes got assigned already as these won't show up in delegated-ripencc-latest. Greetings Bjoern A. Zeeb -- Bjoern A. Zeeb bzeeb at Zabbadoz dot NeT bz @ FreeBSD dot org

6 8

[ipv6-wg@ripe.net] Draft Minutes (v1) IPv6 WG RIPE 50
by David Kessens 01 Jun '05

01 Jun '05

Please see below for our first cut of the minutes for our working group session during RIPE 50. Please let me know if you have any comments or corrections. The minutes will be declared final by Friday, June 10, 2005 if no significant changes (other than typo fixes and minor editorial issues) are found. David Kessens --- Draft Minutes (v1) IPv6 WG RIPE 50 When: Friday, 6 May 2005, 09:00 - 10:30 Where: C58, Clarion Hotel, Stockholm, SE Minute Taker: Adrian Bedford Quick Update from the RIPE NCC Regarding IPv6 Services (Ruud de Kooter - RIPE NCC) After the presentation, Ruud was asked if there were plans to integrate the IPv6 whois interface with the main whois. Currently the proxy cannot talk to the interface and this hampers some functionality (such as rate limiting). Ruud asked Shane Kerr to answer this. Shane explained that the RIPE NCC has a v6 proxy running over a v4 database backend. The RIPE NCC has been looking at how people use the database for two years and patterns suggest that now would be a good time to integrate native IPv6 into the server using /48 as a client identifier. Discussion on: Global IPv6 Routing Table Status (Gert Doering, Spacenet) Gert indicated that the Routing Working Group was discussing best practices for BGP filters. The overall thrust of the presentation was that v6 is growing smoothly with no big disasters so far. A question was asked about ratio comparison between the numbers of Autonomous Systems (AS) announced by IPv6 networks as opposed to v4. The current data suggests that there are 1.419 announced entries per originating AS for v6 and 10.308 for v4. A point was made that Deutsche Telecom (DT), who have one of the largest v6 allocations made to date would not announce their block as one AS, they would be more likely to split this and allocate blocks to different service providers for political reasons. Someone from DT commented that the company has the right to do this, though denied that the move was in any way politically motivated. Renumbering IPv6 Networks (Stig Venaas, Uninett & Tim Chown, University of Southampton) After the presentation, it was mentioned that we are assuming that customers of service providers will keep their space, yet ten years ago major providers did force renumbering onto customers. It was agreed that renumbering of IPv6 is, at least in principal, no different to what happened with v4. Developments/Initiatives Regarding IPv6 in the RIPE Region and Beyond - Francis Dupont: Point6 (http://www.point6.net/ - Gert Doering: A new maillist for discussion of ipv6 operational issues was started: http://lists.cluenet.de/mailman/listinfo/ipv6-ops/ After the announcement of the list, it was agreed that having a publicly available archive of this new list would be a good idea. Although it exists on the site that hosts the list, this is a personal website and for stability purposes, maybe a copy of the archive should be placed elsewhere. It was felt that the RIPE website was unsuitable for this. - Carlos Friacas: o IPv6 - Advanced Network Developments's first year in Portugal o 9K IPv6 Schools' Network Initiative o About the IPv6 Steering Committee Revisiting the /48 recommendation There was a lengthy discussion around RFC 3177. It was made clear that the discussion was not intended to reach final consensus on all the issues involved, but merely to serve as a way to get an idea about the general direction on where the community would like to go to make it possible to write up an initial proposal. Many agreed that the /48 is too much for many users for now and in the future. A discussion followed about how we should define a site with the suggestion that we need to accept that this can remain a grey area, which is not at all well defined right now. Discussion is needed around this topic, though the group tended to accept that it might not be easy to put down limits in black and white. Most people in the room felt that RFC3177 needs a revision. Most people felt that the /48 limit itself doesn't need to be changed, but most agreed that there is a need for a new category that falls somewhere between /48 and /64 for users that have a need for subnetting but for which a /48 seems excessive. This category would fit the mass consumermarket or (very) small office market, however, it was noted that we should base the category on technical needs of the user, not in economic terms like mass consumer market. It is exepected that an Internet Draft will be written that can be discussed at RIPE 51.

1 0

[ipv6-wg@ripe.net] Minutes from IPv6 WG - RIPE 49
by David Kessens 01 Jun '05

01 Jun '05

Please see below for the final minutes of our session during RIPE 49. The minutes are mostly the same as the v1 draft minutes that were posted earlier. Only differences are a typo fix and an improved summary of Jordi's presentation on 'Guidelines for ISPs on IPv6 Assignments to Customers'. I will sent out the draft minutes for our meeting during RIPE 50 in a couple of minutes. David Kessens --- Minutes from IPv6 WG - RIPE 49 RIPE 49 Manchester IPv6 Working Group Wednesday 22 September 2004 WG Chair David Kessens Scribe Adrian Bedford (RIPE NCC) Attendees: 121 Administration and Agenda Presented by David Kessens Adrian Bedford of the RIPE NCC was appointed scribe. Agenda was agreed Minutes from both RIPE 47 and 48 were approved. Update from the RIPE NCC Presented by Andrei Robachevsky, RIPE NCC As of August, k-root is IPv6 enabled The new version of the RIPE website (to be launched shortly) will also be IPv6 enabled. An Overview of the Global IPv6 Routing Table Presented by Gert Doering (Spacenet) A number of anomalies have been observed in the Global IPv6 Routing table, though in most cases these could be explained by traffic engineering, internal transitions and in one case a prefix leak. One person used the Jabber Remote Feedback system to ask why IXPs are announcing /48s with no export. It was explained that, for example, AMSIX doesn't want it's neighbors to make it's prefix globally visible. It remains a contentious issue as to whether something should be globally visible. What are the Deployment Plans Behind the Larger IPv6 Allocations? Presented by: Mikael Lind (TeliaSonera) David Kessens asked whether there were plans to allocate /64s for mobile use. Mikael confirmed that this was likely and that TeliaSonera was also looking at /48s for this use. Kurtis Lindqvist asked whether TeliaSonera has been talking with vendors to co-ordinate hardware and equipment. Mikael explained that this has not yet happened, as they feel right now there is little incentive to do so. David asked if Mikael would consider returning to a future RIPE Meeting to provide an update when TeliaSonera is further along in the development and deployment process, Mikael indicated that he would be happy to do so. Deployment Plans Behind Larger IPv6 Allocations Presented by Jordi Palet (Consulintel) Jordi will continue to keep the Working Group posted on feedback. He will also encourage non-respondents to contribute. Geant IPv6 Presented by Jordi Palet (Consulintel) Guidelines for ISPs on IPv6 Assignments to Customers Presented by Jordi Palet (Consulintel) This presentation provided an initial attempt on creating guidelines on how to interpret the official ipv6 assignment policy in practical terms. < BREAK > IPv6 Glue for the Root Nameservers Presented by Johan Ihrén (Autonomica) Iljitsch van Beijnum asked how long the process is likely to take. Johan commented that it would depend on who was prepared to take on the task, Johan is willing to do this, though added that nothing is root server specific, if people argue that we need v6 glue now, then they should step up and offer to help out. There is no specific target date for this to happen, since testing needs to be completed. Randy Bush asked that since we tend to assume that we should upgrade when something breaks, how is he to know when something has in fact broken. How, as an operator will he actually know there is something wrong? Johan agreed with Randy, there needs to be an agreed process. This could mean that things may not happen universally at the same time. Much will depend on the level of ambition of those involved - the tasks could be more or less complex. Gert Doering commented that as we see ccTLDs adding v6 glue, they might already know some of the issues that could arise. He suggested that someone speak to the ccTLD Operators and find someone who is willing to help with testing. It was also suggested that prudence might be a good idea. If a ccTLD Operator decides to deploy v6 transitions to their nameservers, in the end it will be their own decision. A question was asked about whether anything could be done to improve I-root connectivity to Europe. Johan commented that this would fall into his domain and promised to provide more feedback on this by RIPE 50. Bill Manning commented that the group appeared to be talking as if testing had not in fact started, whereas people are doing tests, ccTLD Operators at already looking at the impacts of these tests. A timeframe was agreed at the last ISOC meeting to finish testing before their next report at the end of the year, enabling a report to made to ICANN. One obstacle here is that the last report to the ICANN board took six months to have approved. Doug Barton of ICANN commented that the process has been streamlined and lessons learned, it is felt that any such future report would receive a far quicker response. David Kessens asked if all root servers planned to have IPv6 connectivity at the same time. Johan replied that he thought it unlikely that everyone would approach this in the same way, adding that he felt diversity was not a bad thing. It would, he said, be likely that we would see some TLDs using basic glue with others holding off during the early phases. The day when we will see the v6 glue globally is still somewhere in the distant future as there are no specific plans at this point to co-ordinate such a deployment. To date eight have basic glue in place. David asked if this community could help and Johan said he felt it certainly could. There was discussion about asking the RIPE NCC for help, though Johan this was not necessary at this stage. From his point of view he did not feel the issue was who did this, rather thought needed to be given to identifying which tests are relevant. Time would need to be taken over inventory to find out what code is already out there. David rounded up the discussion by saying that volunteers would be welcomed, though this was not be taken as a specific action point. An Update on Multihoming in IPv6 Presented by Geoff Huston (APNIC) A comment was made that the slide detailing issues appeared to not consider the update rates for bindings and third party referrals. Geoff said that design decisions should avoid relying on DNS. Randy Bush commented that there had been some mission drift from multi-homing to mobility. A comment was made that if an opportunistic solution does not meet all the needs in the architecture, you are forced to use a structured identifier. Such an identifier would have to be unique to avoid collisions. This could give rise to a very complex registration infrastructure, which might be painful to administer. Geoff replied that uniqueness never comes cheap and needs enormous effort at a global level. This lead to a suggestion that it may be preferable to choose opportunistic styles. Geoff felt that this was down to personal taste; there were certainly benefits in avoiding global costs if set up problems could be avoided. A suggestion was made that we should consider developing a whole new protocol that could handle routing table growth, Geoff replied that it would be ideal to think that we could do both, groups do exist with experience in both fields. The IETF have working groups that work together to engineer solutions and ensure routing tables do not become too complex. Geoff agreed that many people do feel routing could provide a better answer Kuris Lindqvist pointed to work that had been done during an interim meeting in Santa Monica in June 2004, this looked at the architectural work done by Geoff and the 30-40 drafts submitted. The drafts were split into four or five categories and based upon these; a simple poll was carried out. In some categories, the authors withdrew their proposals and in others, there was little support. The consensus was that the architecture proposed by Geoff was the way the group wished to move forward at the moment. A speaker announced that he had prepared a draft on the use of PI to reduce pressures on routing tables, intended as a compromise and is accepting comments on this. A speaker added that during his presentation Geoff dismissed mobile IP for security and state management reasons. The IETF has already addressed security and state management could throw up more problems. He felt that having two solutions for these issues problem was unwise and we need to work towards a single solution for what seem like related problems. He felt that using security, as a reason to reject the architecture draft was a red herring. Geoff pointed out that this is not yet in the draft, though will be in the next version. Geoff agreed that some of the assumptions we made previously in mobile IPv6 now seem less secure. Security locators assume a stable home base - if it fails, everything else fails. Multi6 looks at the ‘homeless vagrants’ of the world that do not have a home all of the time and the home is not reachable. It then assumes that there is not a home locator that can always be contacted. The Multi6 team looked at the other approaches and aimed to learn from them. He remains unsure if this kind of binding works in mobile environments, it is far too early to make this assessment. David Kessens asked whether the group found updates from Multi6 useful, Kurtis suggested that it would be nice to have Geoff make a similar presentation in future Address Policy Working Group Sessions too. Gert Doering suggested that as co-chair of the Address Policy Working Group, he would like to see the drafts on PI Addressing discussed through the Address Policy Mailing List. Moonv6 Update Presented by Jim Bound Kurtis Lindqvist asked whether security testing had been carried out in an isolated test environment. Jim clarified that filters had only been tested on IPv6 ports, addresses and protocols. He added that it showed there was confusion. Just because dual stack is not a security problem, IPv6 in itself is not an insecure protocol. Intrusion detection needs to be included into work. Kurtis asked what stage of the evolution process the project had reached. Jim replied that in this respect, research was still quite basic. Deploying 5,000 IPv6 Sites - XTEC Presented by Jordi Palet (Consulintel) Input to RIPE NCC Activity Plan Presented by David Kessens David asked if the group had any items to include in the 2005 RIPE NCC Activity Plan. There was no response.

1 0

[ipv6-wg@ripe.net] Re: [ncc-services-wg] RIPE 50 Report
by Daniel Roesen 25 May '05

25 May '05

On Tue, May 24, 2005 at 02:09:07PM +0200, Nick Hyrka wrote: > IPV6 WORKING GROUP > > - It was decided that the RIPE Whois Database will continue to include more > services that run in native IPv6. Hm? > - It was noted that the IPv6 Working Group needs to decide where it wishes > to house the new, operational IPv6 mailing list. What are you talking about here? What "new, operational IPv6 mailing list" are you referring to? What has the RIPE IPv6 Working Group to do with it? I have some suspicion that this is a reference to Ulrich Kiermayr's comment? Please clarify. Regards, Daniel -- CLUE-RIPE -- Jabber: dr(a)cluenet.de -- dr@IRCnet -- PGP: 0xA85C8AA0

4 5

[ipv6-wg@ripe.net] Fwd: [apops] APNIC New IPv6 address block(s)
by leo vegoda 24 May '05

24 May '05

Begin forwarded message: > From: John Tran <john(a)apnic.net> > Date: May 24, 2005 9:29:05 am GMT+02:00 > To: apnic-announce(a)lists.apnic.net > Cc: apops(a)apops.net > Subject: [apops] APNIC New IPv6 address block(s) > Message-Id: <Pine.LNX.4.61.0505231059340.10511(a)durian.apnic.net> > > > > Dear colleagues > > APNIC received the following IPv6 address block from IANA recently > and will be making allocations from this range in the near future. > > 2400:0000::/19 > > This announcement is being made for the information of the Internet > community, and so that network configurations such as routing filters > may be updated as appropriate. > > For more information on the resources administered by APNIC, see: > > http://www.apnic.net/db/ranges.html > > For information on the minimum allocation sizes within address ranges > administered by APNIC, see: > > http://www.apnic.net/db/min-alloc.html > > > Kind regards > > Son > > ____________________________________________________________________ > Resources Services Manager <Son(a)apnic.net> > Asia Pacific Network Information Centre phone: +61 7 3858 3100 > http://www.apnic.net fax: +61 7 3858 3199 > Helpdesk phone: +61 7 3858 3188 > email: > helpdesk(a)apnic.net > Please send Internet Resource Requests to <hostmaster(a)apnic.net> > _____________________________________________________________________ > > _______________________________________________ > apops mailing list > apops(a)apops.net > http://mailman.apnic.net/mailman/listinfo/apops > Website: www.apops.net > -- leo vegoda Registration Services Manager RIPE NCC

1 0

[ipv6-wg@ripe.net] Who provides v6 uplink via tunnel ?
by Kurt Jaeger 22 May '05

22 May '05

Hello, As none of our uplinks currently provides v6 support, I'm looking for some site that would be willing to route our /32 and tunnel it to some endpoint via v4. We're located in southern germany (Stuttgart). -- MfG/Best regards, Kurt Jaeger 15 years to go ! LF.net GmbH fon +49 711 90074-23 pi(a)LF.net Ruppmannstr. 27 fax +49 711 90074-33 D-70565 Stuttgart mob +49 171 3101372

5 8

[ipv6-wg@ripe.net] What is a site?
by ＠UUNET SE Ip 11 May '05

11 May '05

Hi. Following the discussion about /48 boundaries I'd like a better definition of what a site is. My definition of an end-user site is the office where we (MCI/UUNET) install a circuit. This could be a large office or a small bransch office or anything in between. Each office is handled separately and they request IPv4 addresses per office. Adopting this to IPv6 it would mean that each office would get a /48. This is too much for many of them. Approx. 80-90% of our sites request 32 IP-addresses or less and most likely only subnet it 2 or 4 times if they ever subnet it. Furthermore we never get a complete network design for all branch offices if the customer is transnational or even national so we can't really assign a /48 to the customer for him to subnet among his offices. We can of course change our procedures to accomomodate thisbut this will make things a lot more difficult for us as a LIR and also the customer. We can't decide how many addresses to assign to a customer based on size or revenue. What I want is a clear definition of what a site is by having more catagories. but I don't want a floating boundary as catagories do simplyfies things. I also include my suggestions based on where I'm coming from :-) /60 for home networks (16 networks) /56 for enterprises (small/medium) (256 networks) /48 for large enterprises (65000 networks) /47 or more for "very large subscribers" /64 for mobile phones (w/ bluetooth or 802.11b) /128 for dialup PC Please note that I'm not a routing expert nor am I a experienced in the complete IPv6 concept with mobil users and consumers goods etc. My main area is IP-address administration. I administrate IP-networks for MCI/UUNET in almost all of Europe except DE, AT and CH. I haven't read the RFC's related to this so my mind is wide open ;-) Best regards Patrick Arkley Supervisor IP/DNS-team SKSC/SKRC MCI - Powered by UUNET Armégatan 38 S-171 04 Solna, Sweden Web: www.se.mci.com <http://www.se.mci.com/> Phone direct: +46 (0)8 5661 7075 Fax: +46 (0)8 5661 7236 Mobile: +46 (0)733 11 20 75 VNET: 915-7075 E-mail: patrick.arkley(a)se.mci.com <mailto:patrick.arkley@se.mci.com> Initial Call team [VPN]: +46 (0)8 5661 7899 or emea-ip-vpn-initial-call(a)se.mci.com <mailto:emea-ip-vpn-initial-call@se.mci.com> Registry: +46 (0)8 5661 7454 or registry(a)se.uu.net <mailto:registry@se.uu.net> <mailto:registry@se.uu.net> IP-team: +46 (0)8 5661 7629 or ip(a)se.uu.net <mailto:ip@se.uu.net>

13 44

[ipv6-wg@ripe.net] Re: [ipv6-wg@localhost] Re: What is a site?
by Erics 10 May '05

10 May '05

Hi all, please, let´s get back to the main question - what is a site ? I think we need a definition for this, because we find a lot of different means (eg. endsite, single network, customer, subscriber) in the IPv6 allocation and assignment policy and the RFC3177. Lets view a concrete example : A customer of us, a shipping company has ten brances at ten different locations. And he is running a seperated network behind our acces router on each loctaion. >From our point of view and understanding the RFC3177 each location is a site and we assign a /XX to each branch. Do you agree on this, or are there different opinions ? Kind regards Eric Schmidt LIR de.telekom

2 1

RE: [ipv6-wg@ripe.net] Re: [ipv6-wg@localhost] Re: What is a site ?
by Patrick Arkley 10 May '05

10 May '05

That was indeed the original question. In my scenario, the same as yours, I would assign a /48 to each branch office. Too many subnets I would say. However, if the customer from a central point asked for a range for all his branch offices I wouldn't hesitate in assigning one /48 for him/her to use wherever appropriate. The problem from an adminitrative side is that we rarely get the customer to fill out a network request for all sites but rather request ranges per site as they are up for installation. Rgds Patrick Arkley Supervisor IP/DNS SKSC/SKRC Phone direct: +46 (0)8 5661 7075 Fax: +46 (0)8 5661 7236 Mobile: +46 (0)733 11 20 75 VNET: 915-7075 E-mail: patrick.arkley(a)se.mci.com Initial Call team [VPN]: +46 (0)8 5661 7899 or emea-ip-vpn-inital-call(a)se.mci.com Registry: +46 (0)8 5661 7454 or registry(a)se.uu.net IP-team: +46 (0)8 5661 7629 or ip(a)se.uu.net -----Original Message----- From: Erics [mailto:EricS@t-com.net] Sent: den 10 maj 2005 11:37 To: ipv6-wg(a)ripe.net Subject: [ipv6-wg(a)ripe.net] Re: [ipv6-wg@localhost] Re: What is a site? Hi all, please, let´s get back to the main question - what is a site ? I think we need a definition for this, because we find a lot of different means (eg. endsite, single network, customer, subscriber) in the IPv6 allocation and assignment policy and the RFC3177. Lets view a concrete example : A customer of us, a shipping company has ten brances at ten different locations. And he is running a seperated network behind our acces router on each loctaion. >From our point of view and understanding the RFC3177 each location is a site and we assign a /XX to each branch. Do you agree on this, or are there different opinions ? Kind regards Eric Schmidt LIR de.telekom

1 0

[ipv6-wg@ripe.net] HD ratio issues and revisiting /48
by Iljitsch van Beijnum 05 May '05

05 May '05

Consider this my input for tomorrow's discussion. I'm far away but I'll be with you guys in spirit. (And watching!) Ok, this message is becoming rather long. Skip to the end for the practical stuff if necessary. I believe Geoff's point with the presentation yesterday was "with only 45 bits to play with and considering the HD ratio IPv6 address space isn't as unlimited as it once seemed". The whole idea behind the HD ratio is that the more you have, the more you waste. And "more" isn't just more in absolute terms, but also in relative terms. Essentially an HD ratio of X percent says you'll waste X percent of your address bits. To some degree, this makes sense. If you have a flat numbering plan you need N numbers plus some wiggle room. But if you introduce a strictly hierarchical addressing plan, you need more wiggle room. For instance phone numbers we have in most European countries have area codes for cities and then subscriber numbers within each city. When phone numbers in Amsterdam run out, they can't borrow numbers from The Hague. So not only do we need wiggle room for both aggregation levels (national and city), but in phone numbers we also lose some serious number capacity because the boundary isn't very flexible. In the Netherlands even the smallest area codes hold 6 digit subscriber numbers. This eats up more numbers than when you can give the smallest area codes 5 digit numbers, or better yet, use 4.5 - 7 digit as needed. Now the interesting thing is that the HD ratio RFC (RFC 3194) is for a large part based on experiences with French phone numbers. It's easy to see that even though Alain Durand and Christian Huitema are obviously on to something, there must be a problem somewhere, as they write that the practical maximum (= HD ratio of 87%) utilization for IPv4 is 240 million addresses. (Actually that would be 211 million, they didn't compensate for class D and E and other unusable address space.) However, according to the most recent ISC host count were now at 317 million (= hosts present in the reverse DNS) while only 2.5 billion out of 3.7 billion usable IPv4 addresses have been allocated by IANA. So the current HD ratio for usable non-reserved IPv4 space is 90.5%, and this includes legacy space, so if we were to look at RIR space only, this would certainly be even higher. If we apply the same HD ratio to the remaining 1.2 billion addresses, we should be able to grow to 480 million IPv4 addresses in use without even taking legacy space issues into account. The HD ratio also doesn't account for the nature of the number hierarchy. In phone numbers or classful IPv4, you can't move the aggregation boundaries around. But with CIDR and VLSM (variable length subnet masks, at one point a great innovation), this is not a problem. So if you have 8 locations that need 100 - 800 addresses respectively, you don't need 8 x 1024 = 8192 addresses, but 128 + 256 + 3 x 512 + 3 x 1024 = 4992 addresses, or even 1, 2, 3, 4, 4, 5, 6, 7 * 128 = 4096 addresses. This will of course push some of the pain up the next aggregation level, as rather than a single route there will be 8 to 32 individual routes. When we cross over to inter-domain routing, this is clearly harmful since we are currently unable to aggregate in the interdomain routing space unless aggregation was already done (or at least possible) at the source AS. But for interior routing, this really isn't much of a problem. Even when routing a billion (2^30) /48s, that would boil down to: 2 levels, strict hierarchy: 2 * 2^15 routes 3 levels, strict hierarchy: 3 * 2^10 routes This is all very doable with today's hardware. Even if we assume a size difference of a factor 64 between the largest and the smallest entities in a loose hierarchy (ie. if Mexico City is your largest entity, the smallest would be a city with less than half a million people) that's 2^15 + 2^21 with two levels and 2^10 + 2^16 with three levels. Conclusion: you don't _have_ to lose one bit out of five as the allocated address space gets bigger. This also applies to interdomain routing. If you want to number 4 billion end-sites, Geoff's presentation lists a /8 as the prefix length of choice. But 4 billion also happens to be 256 * 16 million, and for 16 million we only need a /18. So 256 of those would be a / 10. We just saved 2 bits but now we have 256 /18s in the global routing table rather than one /8. But even someone who gets as much flack for not trusting the router vendors to come up with bigger boxes as me can appreciate that routing a larger number of /18s isn't going to kill BGP (there can only be 32 - 256 thousand /18 routes anyway). (With apologies for the thousand = 2^10 and million = 2^20.) !-!-!-! So where does this land us in the "create more wiggle room" debate? I think it's pretty clear that there is no immediate danger if we don't. On the other hand, if we can save some bits without real pain, why not do it? Going from /48 to /56 as a general recommendation would be one way to do that. Another way would be to keep the /48 for people who want it, but move the /64 to /60. It's practically impossible to utilize /128s in IPv6 (it can be done but it's just too painful and awkward). So: Now: /64 or /48 /56 idea: /64 or /56 /60 idea: /60 or /48 Giving everyone who needs address space a /60 rather than a /64 has the advantage that there is always room for a router. If my cell phone gets a /64, that's nice, but it means the phone has to bridge or proxy ND or some such. With a /60 I can have a subnet of my own for the bluetooth link, and another for the GPRS/UMTS link. Obviously this will increase the address consumption for people who would otherwise have gotten a /64, but even if there are many of those, that doesn't add up too badly. However, 95% of the people who would have gotten a /48 and 99% of the people who would have taken a / 56 would also be happy with a /60, and this would save a lot of address space. I also believe /60 vs /48 will make ISPs happier, as they're used to making SOHO/BigCu$tomer distinctions today and /60 vs /48 would pretty naturally fall into this. However, I stronly believe that EVERYONE who wants one and has an ISP who is reasonable should get a /48 no questions asked for the exact reasons that we have the "let them eat /48s" rule today. I would also suggest that all individual /48s would be registered in RIR databases.

1 0