- ipv6-wg - mailman.ripe.net

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

The trouble with 6to4
by Mirjam Kuehne 06 Dec '10

06 Dec '10

Dear colleagues, We (thanks to Emile Aben) measured how broken 6to4 really is and found that it is pretty bad! Read more on RIPE Labs: http://labs.ripe.net/Members/emileaben/6to4-how-bad-is-it-really Kind Regards, Mirjam Kuehne RIPE NCC

1 0

New document available: RIPE-501 Requirements For IPv6 in ICT Equipment
by Marco Hogewoning 25 Nov '10

25 Nov '10

Dear community, A new ripe document, RIPE-501, has been published "Requirements For IPv6 in ICT Equipment". This document aims to be a guide of what to ask for exactly when IPv6 is a requirement in a tender or some contract and lists the various applicable RFCs for specific kinds of ICT equipment. The document is available on http://www.ripe.net/ripe/docs/ripe-501.html Please note that when using this document as a reference, as with any RIPE document, it might get superseded by new versions in the future. Many thanks to the authors and everybody who helped with proof reading, translation and feedback. Marco, David & Shane, co-chairs of the IPv6 working group

2 1

AUTO: Nicht erreichbar bis 29.11.2010 / Out of Office until 29.11.2010
by Joachim Strohbach 25 Nov '10

25 Nov '10

Ich bin abwesend und kehre am 29.11.2010 zurück. Danke für Ihre E-Mail-Nachricht. Ich bin bis 29. November 2010 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 29 November 2010. 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 "New document available: RIPE-501 Requirements For IPv6 in ICT Equipment" gesendet am 24.11.10 20:48:45. Diese ist die einzige Benachrichtigung, die Sie empfangen werden, während diese Person abwesend ist.

1 0

Last Call (20101117): Requirements For IPv6 in ICT Equipment
by David Kessens 24 Nov '10

24 Nov '10

Working Group, The "Requirements For IPv6 in ICT Equipment" draft seems to have reached a level of maturity that is enough to issue a formal Last Call to determine whether it is ready for publication as a RIPE document. The latest version is available here: http://www.ripe.net/ripe/draft-documents/ipv6-ict-requirements.html We would appreciate if you let us know by the end of November 17, 2010 if you have read the document and whether you support the publication of the document. As long as we get at least 8 statements of support and no significant issues are raised, we will ask the RIPE NCC to publish the document after fixing minor editorial issues (if found). David, Marco & Shane ---

11 30

Re: [ipv6-wg] Last Call (20101117): Requirements For IPv6 in ICT Equipment
by Marco Hogewoning 23 Nov '10

23 Nov '10

Please for the process, as this is a last call, be very clear wether you are making comments about future versions or if you are objecting against publication of the current document. So far I consider this future improvements and we will go forward with publishing the current text as final. If anybody objects, please state this clearly and we will back out. The authors already agreed to do a second version together with some help from others, at the same time we have stakeholders who would like to get this draft label removed. Groet, MarcoH ----- Reply message ----- From: "Isacco Fontana" <isacco.fontana(a)trentinonetwork.it> Date: Tue, Nov 23, 2010 18:18 Subject: [ipv6-wg] Last Call (20101117): Requirements For IPv6 in ICT Equipment To: <mtinka(a)globaltransit.net> Cc: <ipv6-wg(a)ripe.net>, "Ivan Pepelnjak" <ipepelnjak(a)gmail.com>

2 1

Re: [ipv6-wg] Last Call (20101117): Requirements For IPv6 in ICT Equipment
by Ivan Pepelnjak 23 Nov '10

23 Nov '10

Dear all, As I'm one of the original authors of this document (now nicely hidden behind the "Slovenian IPv6 working group" blob ;) and had a bit to do with MPLS in the past, please allow me to comment on the MPLS-related requirements. 6PE/6VPE ========= Unfortunately, the only way to combine IPv6 with MPLS features like MPLS-TE or FRR today (and in the next few years) is to run IPv4 MPLS core and 6PE/6VPE. The requirement to support 6PE/6VPE is thus MANDATORY, but has to be conditioned the same way mobile IPv6 is. I would therefore suggest that we add the following two bullets to the "Mandatory support" part of the "Router or Layer 3 switch" equipment: * If MPLS functionality (for example, BGP-free core, MPLS TE, MPLS FRR) is requested, the PE-routers and route reflectors MUST support "Connecting IPv6 Islands over IPv4 MPLS Using IPv6 Provider Edge Routers (6PE)" [RFC 4798] * If layer-3 VPN functionality is requested, the PE-routers and route reflectors MUST support "BGP-MPLS IP Virtual Private Network (VPN) Extension for IPv6 VPN" [RFC 4659] MT IS-IS & MPLS =============== There's another gotcha that we totally missed: MT for IS-IS (RFC 5120) should be mentioned and it should be MANDATORY in combination with MPLS (otherwise you might experience some weird symptoms if you decide to run some IPv6 natively). The "Router or Layer 3 switch" equipment section thus needs two more items: MANDATORY --------- * If MPLS Traffic Engineering is used in combination with IS-IS routing protocol, the equipment MUST support "M-ISIS: Multi Topology (MT) Routing in Intermediate System to Intermediate Systems (IS-ISs)" [RFC 5120] OPTIONAL -------- * When IS-IS routing protocol is requested, the equipment SHOULD support "M-ISIS: Multi Topology (MT) Routing in Intermediate System to Intermediate Systems (IS-ISs)" [RFC 5120] (this support is highly recommended) Best, Ivan Pepelnjak www.ioshints.info

4 4