- ipv6-wg - mailman.ripe.net

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