- ipv6-wg - mailman.ripe.net

"Requirements For IPv6 in ICT Equipment" comment
by Nash, Steve 18 Jan '11

18 Jan '11

Regarding: http://www.ripe.net/ripe/docs/ripe-501.html I find no mention of flow instrumentation in the November 2010 document. I suggest that "router and layer 3 switch" Mandatory support should include maintenance and export of flow records , ideally compliant with rfc 3917, with sampling rate capability of at least 1 per 1000 packets, at the maximum packet rate of the device. Regards Steve Nash ________________________ Steve Nash CEng MIET Consulting Engineer Arbor Networks office +44 118 967 4917 mobile +44 772 029 1359 www.arbornetworks.com<http://www.arbornetworks.com/> How networks grow(tm) ________________________

13 31

[annoucement] changing jobs
by Marco Hogewoning 09 Jan '11

09 Jan '11

Hi All, As some of you may already know, I will be changing jobs. As of January 1st, I will join the RIPE NCC training department. This of course raises the question wether I should stay as co-chair of this working group. After talking with various people, including the NCC management, the RIPE chair and the other WG co-chairs, we concluded that I can stay on as a co-chair. However as the NCC has to remain neutral I will pull out of any discussions regarding address policy or other proposals directly related to the operations of the RIPE NCC. I will leave decisions regarding these proposals up to David and Shane, the other two co-chairs of this working group. If you have any questions or objections to this situation, please post to the IPv6 WG list or to me directly. I would like to thank my former employer, XS4ALL Internet, for the time and money they allowed me to spent on this working group over the past years. Happy new year and hope to see you in 2011, Marco Hogewoning IPv6 working group co-chair

9 8

RE: [address-policy-wg] 2010-06 is going to Last Call
by kpn-ip-office＠kpn.com 07 Jan '11

07 Jan '11

I support the proposal. With kind regards, ir. A.W. (Andries) Hettema KPN OZM KS&O B&I Internet +31 70 34 38290 andries.hettema(a)kpn.com -----Oorspronkelijk bericht----- Van: address-policy-wg-admin(a)ripe.net [mailto:address-policy-wg-admin@ripe.net] Namens Shane Kerr Verzonden: donderdag 6 januari 2011 14:20 Aan: db-wg(a)ripe.net; 'address-policy-wg(a)ripe.net' Onderwerp: [address-policy-wg] 2010-06 is going to Last Call Hello, [ Courtesy copy sent to address policy and database working groups. Please follow up on the ipv6-wg list. ] The Review Phase for the RIPE policy proposal 2010-06 ended on 2010-12-27 (Monday, 27 December 2010). You can see the policy proposal here: http://ripe.net/ripe/policies/proposals/2010-06.html There were some clarifications during the Review Phase, but nothing indicating changes needed. David and I have decided that the proposal is ready for a Last Call. (As co-author of the proposal, Marco has recused himself from any consensus judgments.) The last call period is four weeks, so will end 2010-02-03 (Thursday, 3 February 2011). Please e-mail any final comments to ipv6-wg(a)ripe.net before then. Thanks, -- Shane

1 0

AUTO: Nicht erreichbar bis 11.1.2011 / Out of Office until 11.1.2011
by Joachim Strohbach 06 Jan '11

06 Jan '11

Ich bin abwesend und kehre am 12.01.2011 zurück. Danke für Ihre E-Mail-Nachricht. Ich bin bis 11. Januar 2011 nicht im Büro. In dringenden Angelegenheiten kontaktieren Sie bitte DENIC IT-Services (E-Mail: its(a)denic.de, Tel: (069) 27235-160 oder -250). ----- Thank you for your email message. I am not in the office until 11 January 2011. In urgent cases please contact DENIC IT-Services (e-mail: its(a)denic.de, Tel: +49 69 27235-160 or -250). -- Joachim Strohbach Leiter IT-Services / Head of IT-Services DENIC eG Kaiserstraße 75-77 60329 Frankfurt am Main GERMANY E-Mail: strohbach(a)denic.de Fon: +49 69 27235-123 Fon: +49 69 27235-160 (Assistance) Fon: +49 69 27235-250 (IT-Services) Fax: +49 69 27235-239 SIP-URI: sip:123@denic.de http://www.denic.de PGP-KeyID: 0x7A8A00FF, Fingerprint: 30AB 0F15 17D3 995F CA50 F0A8 EA30 B915 7A8A 00FF Angaben nach § 25a Absatz 1 GenG: DENIC Domain Verwaltungs- und Betriebsgesellschaft eG (Sitz: Frankfurt am Main) Vorstand: Sabine Dolderer, Helga Krüger, Carsten Schiefner, Dr. Jörg Schweiger Vorsitzender des Aufsichtsrats: Elmar Knipp Eingetragen unter Nr. 770 im Genossenschaftsregister, Amtsgericht Frankfurt am Main Hinweis: Dies ist eine automatische Antwort auf Ihre Nachricht "[db-wg] 2010-06 is going to Last Call" gesendet am 6.1.11 14:20:25. Diese ist die einzige Benachrichtigung, die Sie empfangen werden, während diese Person abwesend ist.

1 0

2010-06 is going to Last Call
by Shane Kerr 06 Jan '11

06 Jan '11

Hello, The Review Phase for the RIPE policy proposal 2010-06 ended on 2010-12-27 (Monday, 27 December 2010). You can see the policy proposal here: http://ripe.net/ripe/policies/proposals/2010-06.html There were some clarifications during the Review Phase, but nothing indicating changes needed. David and I have decided that the proposal is ready for a Last Call. (As co-author of the proposal, Marco has recused himself from any consensus judgments.) The last call period is four weeks, so will end 2010-02-03 (Thursday, 3 February 2011). Please e-mail any final comments to ipv6-wg(a)ripe.net before then. Thanks, -- Shane

1 0

2010 IPv4 (and IPv6) Address Use Report
by Iljitsch van Beijnum 04 Jan '11

04 Jan '11

[ (Non-cross)posted to NANOG, PPML, RIPE IPv6 wg, Dutch IPv6 TF. ] On the web: IPv4: http://www.bgpexpert.com/addrspace2010.php IPv6: http://www.bgpexpert.com/addrspace-ipv6-2010.php The IPv4 one is included below: 2010 IPv4 Address Use Report As of January 1, 2011, the number of unused IPv4 addresses is 495.66 million. Exactly a year earlier, the number of available addresses was 721.06 million. So we collectively used up 225.4 million addresses in 2010. 35 of the 256 the /8s that make up the IPv4 address space have the status "reserved". 0 and 127 have special meaning and can't be used for normal purposes. 224 - 239 are used for multicast and 240 - 255 are "reserved for future use". With only about two years worth of IPv4 addresses remaining on the shelves, it would seem that that future is here now, but unfortunately, pretty much all operating systems balk at using a "reserved" address. So unreserving those addresses means upgrading EVERY system connected to the Internet. If we're going to do that, we may as well skip those reserved IPv4 addresses and upgrade to IPv6. Last but not least, there's block 10, which is the largest of the three address blocks set aside for private use. The others, 172.16.0.0/12 and 192.168.0.0/16, don't show up as reserved, but are obviously not available for regular use. This makes the total number of usable IPv4 addresses is (256 - 35) * 2^24 - 2^20 - 2^16 = 3706.65 million addresses. The "IANA global pool" consists of 7 /8s (117.44 million) are still unused (unallocated): 39/8, 102/8, 103/8, 104/8, 106/8, 179/8 and 185/8. But there's also a lot of unused space hiding in the "allocated" and "legacy" categories. Each RIR publishes a list of address blocks further delegated to ISPs or end users every day on their FTP servers. If we add up all those blocks, this comes out to 3210.99 million addresses. So the total number of usable-but-unused IPv4 addresses is 3706.65 - 3210.99 = 495.66 million. Going back to the IANA global pool, these are the changes over the past year: Delegated Blocks +/- 2010 to/status AfriNIC 3 +1 APNIC 42 +8 ARIN 35 +4 LACNIC 8 +2 RIPE NCC 34 +4 LEGACY 92 UNALLOCATED 7 -19 There is an agreement between IANA and the RIRs that each RIR will get one of the last five /8s. APNIC has been getting two /8s every three months like clockwork in 2010. If this continues, they'll be getting numbers 7 and 6 later this month, and then the final distribution will look like this: Delegated Blocks +/- 2010 to/status AfriNIC 4 APNIC 45 ARIN 36 LACNIC 9 RIPE NCC 35 LEGACY 92 UNALLOCATED - At this point, it becomes very interesting what the status of the legacy space is, exactly. The legacy blocks are each "administered" by one of the RIRs, but does that mean that that RIR is free to further delegate that space to ISPs and end users? There are 146.92 million unused addresses in legacy space, including 16.65 million returned by Interop a few months ago. This is the used versus unused address space administered by each RIR: Legacy Allocated total unused total unused AfriNIC 33.55 24.85 50.33 27.06 APNIC 100.66 22.32 704.64 44.38 ARIN 654.31 60.55 587.20 56.21 LACNIC - - 134.22 37.39 RIPE NCC 67.11 5.77 570.43 67.38 IANA 671.09 16.65 - - AfriNIC used up 8.95 million addresses last year. So their current unused allocated space is good for another three years (if nothing changes) and their final /8 is worth another almost two years. If they get to use their legacy space, that buys them another 2.5 years. So unless IPv4 address use <em>really</em> takes off in Africa, AfriNIC will be handing out addresses for at least three or four years. APNIC is at the opposite end of the spectrum, using up no less than 126.22 million new IPv4 addresses last year. Even if they get to use the legacy space they administer on top of three of the last seven /8s and, it's hard to see how APNIC can avoid having to tell people "no" before the year is out. However, there is a caveat: in the 2010 APNIC records, there is 6.65 million addresses worth of space that isn't in the 2011 records. Part of this is address space returned to APNIC. In other cases, an address block delegated in a previous year expands or shrinks retroactively. Depending on what the underlying reason for these changes is, the actual rate at which APNIC and the other RIRs are giving out address space may be different from what it seems to be at first glance. ARIN, LACNIC, and the RIPE NCC used up 54.55, 17.29, and 75.45 million addresses, respectively, in 2010. However, ARIN saw 27.24 million addresses returned, including the 16.65 million from Interop, which is administered in the ARIN records even though the IANA list doesn't reflect this. For AfriNIC, LACNIC and the RIPE NCC the numbers of addresses that came back were 0.31, 0.22, and 22.62 million, respectively. With respect to running out of addresses, it's important to realize that the Pareto principle (the 80/20 rule) applies: out of the 7686 address blocks given out last year, only 392 (5 percent) were blocks larger than 100,000 addresses, but those were responsible for 82 percent of the address <em>space</em> given out. Even when the RIRs are no longer able to give out those large blocks, they may still be able to fulfill the requests for address blocks smaller than 10,000 addresses. Last year, 6425 such blocks were given out, totaling 14.03 million addresses. It really only takes a single address to be in the content business; it's the ISPs that need a continuous supply of new addresses to connect new customers. So the address shortages looming beyond the summer will hit ISPs and their broadband/mobile customers first and foremost, and the content industry to a much lesser degree. The top 15 IPv4 address holding countries: 2011-01-01 2010-01-01 Increase Country 1 - US 1519.53 M 1495.13 M 1.6% United States 2 - CN 277.64 M 232.45 M 19.4% China 3 - JP 186.82 M 177.15 M 5.5% Japan 4 - EU 151.80 M 149.48 M 1.6% Multi-country in Europe 5 (6) KR 103.50 M 77.77 M 33.1% Korea 6 (5) DE 91.61 M 86.51 M 5.9% Germany 7 (9) GB 82.25 M 74.18 M 10.9% United Kingdom 8 - CA 79.53 M 76.96 M 3.3% Canada 9 - FR 79.29 M 75.54 M 5.0% France 10 - AU 49.10 M 39.77 M 23.5% Australia 11 - BR 40.24 M 33.95 M 18.5% Brazil 12 - IT 37.14 M 33.50 M 10.9% Italy 13 - RU 34.66 M 28.47 M 21.7% Russia 14 - TW 31.93 M 27.10 M 17.8% Taiwan 15 (19) IN 28.70 M 19.42 M 47.8% India Because the US holds so much space, the increase of 25 million addresses seems small, but that's still more than 10% of the address space given out in 2010. China's growth is slowing down a little at 45 million addresses last year compared to 50 million in 2009. But other countries in Asia are picking up the slack and then some: Korea keeps using up large amounts of address space, and India is now also picking up the pace. The US now has 47.3% of the address space in use, down from 50.1% a year ago. The other countries in the top 15 collectively hold 39.7%, up from 38%. That leaves 13% for the rest of the world, up from 12%. Note that I slightly changed the way addresses are counted: previously, all the legacy blocks that didn't have an RIR listed were assumed to be used 100%. But with the return of most of the Interop block this is no longer the case: although ARIN isn't listed as administering the 45/8 block, they actually are and only have 45.0.0.0/15 listed as in use.

1 0

RIPE-501bis
by Patrik Fältström 03 Jan '11

03 Jan '11

Hi, I hear that there are some discussions about a new version of RIPE 501 in other forums than this mailing list for this wg. More precisely in some LinkedIn Forum. Let me in a few words say that side discussions makes me somewhat nervous. This document do have a large impact on the market and although of course its existence should be announced widely, I do not want to see actual discussions that lead to new versions anywhere else than here on this mailing list. If for example editors do get feedback privately or elsewhere than here on the list, I expect I will see at least summaries of that discussion here. We at Cisco have read RIPE-501 in detail, we have compared the document with other similar requirements documents, and yes, we will come shortly with some suggestions for changes. Both based on our experience with other such documents (it would be good if they are somewhat similar), and feedback we already have got from customers of ours that tries to use RIPE-501. I.e. pure editorial changes on how the document is composed. Patrik Fältström

2 1

IPv6 address representation RFC
by Seiichi Kawamura 20 Dec '10

20 Dec '10

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hi My first time posting to this list... A discussion came up on the IETF v6ops list and I was suggested that I should do an FYI post to this list about RFC5952. http://tools.ietf.org/html/rfc5952 The RFC defines a canonical IPv6 representation format. It also describes problems that happen without canonical representation. If you are just starting to deploy IPv6, this maybe of some help in avoiding problems. Many implementations have been fixed since the RFC was published, and I hope future implementations will follow this RFC as well. Log parsing and grepping can get very painful without this... Tools are also available to help with correct representation. http://intermapper.com/ipv6validator http://www.deepspace6.net/projects/ipv6calc.html http://hackage.haskell.org/package/ip6addr http://tools.bgp4.jp/IPv6canonical/IPv6canonical.txt I hope this will be of some help to the operators on this list. Regards, Seiichi -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (MingW32) iEYEARECAAYFAk0PASMACgkQcrhTYfxyMkL0iwCfYn7mCb6qilrXY0mlf6zr3M3W DhMAn0IAvLdZ2HFaFPiFdK7Y9AGvmFdC =Qqhf -----END PGP SIGNATURE-----

1 0

2010-06 New Policy Proposal (Registration Requirements for IPv6 End User Assignments)
by Emilio Madaio 14 Dec '10

14 Dec '10

Dear Colleagues, The IPv6 WG Chairs have decided that the proposal 2010-06 is ready for a 2 week Review Phase. Marco Hogewoning did not participate to the decision as he is a co-proposer. Following the feedback received, the draft documents for this proposal have been published. The impact analysis that was conducted for this proposal has also been published. You can find the full proposal at: http://ripe.net/ripe/policies/proposals/2010-06.html and the draft documents at: http://ripe.net/ripe/draft-documents/ripe-481-draft2010-06.html http://ripe.net/ripe/draft-documents/ripe-new-draft2010-06.html We encourage you to read the draft document text and send any comments to ipv6-wg(a)ripe.net before 27 December 2010. Regards Emilio Madaio Policy Development Officer RIPE NCC

5 4

Re: [address-policy-wg] 2010-06 New Policy Proposal (Registration Requirements for IPv6 End User Assignments)
by James Blessing 13 Dec '10

13 Dec '10

On 13 December 2010 14:44, Emilio Madaio <emadaio(a)ripe.net> wrote: > http://ripe.net/ripe/policies/proposals/2010-06.html Two questions Is 'assignment-size' going to be limited to a number in the db? Could I put a 'stupid' number in? J -- James Blessing 07989 039 476

1 0