From david.kessens at nsn.com Sun Nov 7 10:17:10 2010 From: david.kessens at nsn.com (David Kessens) Date: Sun, 7 Nov 2010 01:17:10 -0800 Subject: [ipv6-wg] Last Call (20101117): Requirements For IPv6 in ICT Equipment Message-ID: <20101107091709.GG2401@nsn.com> 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 --- From jan at go6.si Sun Nov 7 11:48:33 2010 From: jan at go6.si (Jan Zorz @ go6.si) Date: Sun, 07 Nov 2010 11:48:33 +0100 Subject: [ipv6-wg] Last Call (20101117): Requirements For IPv6 in ICT Equipment In-Reply-To: <20101107091709.GG2401@nsn.com> References: <20101107091709.GG2401@nsn.com> Message-ID: <4CD68401.2010406@go6.si> On 7.11.10 10:17, David Kessens wrote: > 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). My statement of support doesn't count, does it? :) :) :) Please, if anyone thinks this document might be usefull as a guide for requirements, when buying new equipment, pleade do tell. "+1" does the trick :) Thnx and see you in Rome, Jan Zorz go6.si From Jasper.Jans at espritxb.nl Mon Nov 8 08:36:28 2010 From: Jasper.Jans at espritxb.nl (Jasper Jans) Date: Mon, 8 Nov 2010 08:36:28 +0100 Subject: [ipv6-wg] Last Call (20101117): Requirements For IPv6 in ICT Equipment In-Reply-To: <4CD68401.2010406@go6.si> References: <20101107091709.GG2401@nsn.com> <4CD68401.2010406@go6.si> Message-ID: <55557D0EBE9495428BFE94EF8BC5EBD2EE00B4EA79@EXCH01.campus.local> +1 -----Original Message----- From: ipv6-wg-admin at ripe.net [mailto:ipv6-wg-admin at ripe.net] On Behalf Of Jan Zorz @ go6.si Sent: Sunday, November 07, 2010 11:49 AM To: ipv6-wg at ripe.net Subject: Re: [ipv6-wg] Last Call (20101117): Requirements For IPv6 in ICT Equipment On 7.11.10 10:17, David Kessens wrote: > 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). My statement of support doesn't count, does it? :) :) :) Please, if anyone thinks this document might be usefull as a guide for requirements, when buying new equipment, pleade do tell. "+1" does the trick :) Thnx and see you in Rome, Jan Zorz go6.si Op dit e-mailbericht is een disclaimer van toepassing, welke te vinden is op http://www.espritxb.nl/disclaimer From us at sweet-sorrow.com Mon Nov 8 09:00:24 2010 From: us at sweet-sorrow.com (Us) Date: Mon, 08 Nov 2010 09:00:24 +0100 Subject: [ipv6-wg] Last Call (20101117): Requirements For IPv6 in ICT Equipment In-Reply-To: <55557D0EBE9495428BFE94EF8BC5EBD2EE00B4EA79@EXCH01.campus.local> References: <20101107091709.GG2401@nsn.com> <4CD68401.2010406@go6.si> <55557D0EBE9495428BFE94EF8BC5EBD2EE00B4EA79@EXCH01.campus.local> Message-ID: <4CD7AE18.30109@sweet-sorrow.com> +2 (hey, I'm fat :) ) Us On 11/08/2010 08:36 AM, Jasper Jans wrote: > +1 > > -----Original Message----- > From: ipv6-wg-admin at ripe.net [mailto:ipv6-wg-admin at ripe.net] On Behalf Of Jan Zorz @ go6.si > Sent: Sunday, November 07, 2010 11:49 AM > To: ipv6-wg at ripe.net > Subject: Re: [ipv6-wg] Last Call (20101117): Requirements For IPv6 in ICT Equipment > > On 7.11.10 10:17, David Kessens wrote: >> 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). > > My statement of support doesn't count, does it? :) :) :) > > Please, if anyone thinks this document might be usefull as a guide for > requirements, when buying new equipment, pleade do tell. > > "+1" does the trick :) > > Thnx and see you in Rome, Jan Zorz > go6.si > > > > > Op dit e-mailbericht is een disclaimer van toepassing, welke te vinden is op http://www.espritxb.nl/disclaimer > > > From isacco.fontana at trentinonetwork.it Mon Nov 8 09:10:57 2010 From: isacco.fontana at trentinonetwork.it (Isacco Fontana) Date: Mon, 08 Nov 2010 09:10:57 +0100 Subject: [ipv6-wg] Last Call (20101117): Requirements For IPv6 in ICT Equipment In-Reply-To: <20101107091709.GG2401@nsn.com> References: <20101107091709.GG2401@nsn.com> Message-ID: <4CD7B091.3020506@trentinonetwork.it> Hi, I suggest to add for *"Requirements for "router or layer 3 switch equipment "* section the support to 6VPE for VPN MPLS environment... Isacco David Kessens ha scritto: > 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 > --- > > > -- Ing. Isacco Fontana Trentino Network s.r.l. A socio Unico Direzione Servizi Responsabile Area Ingegneria di Rete Via Gilli, 2 - 38100 TRENTO Tel (+39) 0461.020200 Fax (+39) 0461.020201 http://as12835.peeringdb.com/ -------------------------------------------------------------------------------------------------------------------------------- Cap. Soc. sottoscritto EUR 7.573.248,00 i.v. - REG. IMP. C.F. e P. IVA 01904880224 E-mail: sede at trentinonetwork.it Societ? soggetta a direzione e controllo da parte della Provincia Autonoma di Trento. C.F. e P. IVA 00337460224 -------------------------------------------------------------------------------------------------------------------------------- -------------- next part -------------- An HTML attachment was scrubbed... URL: From isacco.fontana at trentinonetwork.it Mon Nov 8 09:06:16 2010 From: isacco.fontana at trentinonetwork.it (Isacco Fontana) Date: Mon, 08 Nov 2010 09:06:16 +0100 Subject: [ipv6-wg] Last Call (20101117): Requirements For IPv6 in ICT Equipment In-Reply-To: <20101107091709.GG2401@nsn.com> References: <20101107091709.GG2401@nsn.com> Message-ID: <4CD7AF78.9000700@trentinonetwork.it> +1 Isacco David Kessens ha scritto: > 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 > --- > > > -- Ing. Isacco Fontana Trentino Network s.r.l. A socio Unico Direzione Servizi Responsabile Area Ingegneria di Rete Via Gilli, 2 - 38100 TRENTO Tel (+39) 0461.020200 Fax (+39) 0461.020201 http://as12835.peeringdb.com/ -------------------------------------------------------------------------------------------------------------------------------- Cap. Soc. sottoscritto ? 7.573.248,00 i.v. - REG. IMP. C.F. e P. IVA 01904880224 E-mail: sede at trentinonetwork.it Societ? soggetta a direzione e controllo da parte della Provincia Autonoma di Trento. C.F. e P. IVA 00337460224 -------------------------------------------------------------------------------------------------------------------------------- From jan at go6.si Mon Nov 8 09:49:16 2010 From: jan at go6.si (Jan Zorz @ go6.si) Date: Mon, 08 Nov 2010 09:49:16 +0100 Subject: [ipv6-wg] Last Call (20101117): Requirements For IPv6 in ICT Equipment In-Reply-To: <4CD7B091.3020506@trentinonetwork.it> References: <20101107091709.GG2401@nsn.com> <4CD7B091.3020506@trentinonetwork.it> Message-ID: <4CD7B98C.7090005@go6.si> On 8.11.10 9:10, Isacco Fontana wrote: > Hi, > I suggest to add for *"Requirements for "router or layer 3 switch equipment "* > section the support to 6VPE for VPN MPLS environment... > > Isacco Hey, Thnx for comment. You suggest to add it to optional requirements or to mandatory? Would you be happy with this wording: - BGP-MPLS IP VPN Extension for IPv6 VPN [RFC4659] What about RFC4798 (6PE)? Thnx, /jan From isacco.fontana at trentinonetwork.it Mon Nov 8 10:00:05 2010 From: isacco.fontana at trentinonetwork.it (Isacco Fontana) Date: Mon, 08 Nov 2010 10:00:05 +0100 Subject: [ipv6-wg] Last Call (20101117): Requirements For IPv6 in ICT Equipment In-Reply-To: <4CD7B98C.7090005@go6.si> References: <20101107091709.GG2401@nsn.com> <4CD7B091.3020506@trentinonetwork.it> <4CD7B98C.7090005@go6.si> Message-ID: <4CD7BC15.3010306@trentinonetwork.it> 6VPE (RFC 4659) 6PE (RFC 4798) These RFC are related to MPLS environment so I think 6PE and 6VPE should be mandatory for ISP that are using MPLS and offer ipv6 for direct internet connections and 6VPE for ipv6 over vpn mpls services. Isacco Jan Zorz @ go6.si ha scritto: > On 8.11.10 9:10, Isacco Fontana wrote: >> Hi, >> I suggest to add for *"Requirements for "router or layer 3 switch >> equipment "* >> section the support to 6VPE for VPN MPLS environment... >> >> Isacco > > Hey, > > Thnx for comment. You suggest to add it to optional requirements or to > mandatory? > > Would you be happy with this wording: > > - BGP-MPLS IP VPN Extension for IPv6 VPN [RFC4659] > > What about RFC4798 (6PE)? > > Thnx, /jan > > -- Ing. Isacco Fontana Trentino Network s.r.l. A socio Unico Direzione Servizi Responsabile Area Ingegneria di Rete Via Gilli, 2 - 38100 TRENTO Tel (+39) 0461.020200 Fax (+39) 0461.020201 http://as12835.peeringdb.com/ -------------------------------------------------------------------------------------------------------------------------------- Cap. Soc. sottoscritto ? 7.573.248,00 i.v. - REG. IMP. C.F. e P. IVA 01904880224 E-mail: sede at trentinonetwork.it Societ? soggetta a direzione e controllo da parte della Provincia Autonoma di Trento. C.F. e P. IVA 00337460224 -------------------------------------------------------------------------------------------------------------------------------- From jan at go6.si Mon Nov 8 11:15:55 2010 From: jan at go6.si (Jan Zorz @ go6.si) Date: Mon, 08 Nov 2010 11:15:55 +0100 Subject: [ipv6-wg] Last Call (20101117): Requirements For IPv6 in ICT Equipment In-Reply-To: <4CD7BC15.3010306@trentinonetwork.it> References: <20101107091709.GG2401@nsn.com> <4CD7B091.3020506@trentinonetwork.it> <4CD7B98C.7090005@go6.si> <4CD7BC15.3010306@trentinonetwork.it> Message-ID: <4CD7CDDB.4030908@go6.si> On 8.11.10 10:00, Isacco Fontana wrote: > 6VPE (RFC 4659) > 6PE (RFC 4798) > > These RFC are related to MPLS environment so I think 6PE and 6VPE should be > mandatory for ISP that are using MPLS and offer ipv6 for direct internet > connections and 6VPE for ipv6 over vpn mpls services. So, the correct wording inside mandatory section would be: - if IPv6 over MPLS and IPv6 over VPN MPLS features are requested, 6PE or 6VPE must be supported [RFC4798, RFC4659] The contracting authority shall specify the required protocol. Is this acceptable? Thnx, Jan Zorz From isacco.fontana at trentinonetwork.it Mon Nov 8 11:24:33 2010 From: isacco.fontana at trentinonetwork.it (Isacco Fontana) Date: Mon, 08 Nov 2010 11:24:33 +0100 Subject: [ipv6-wg] Last Call (20101117): Requirements For IPv6 in ICT Equipment In-Reply-To: <4CD7CDDB.4030908@go6.si> References: <20101107091709.GG2401@nsn.com> <4CD7B091.3020506@trentinonetwork.it> <4CD7B98C.7090005@go6.si> <4CD7BC15.3010306@trentinonetwork.it> <4CD7CDDB.4030908@go6.si> Message-ID: <4CD7CFE1.2080904@trentinonetwork.it> I think this is acceptable: - if IPv6 over IPv4 MPLS and IPv6 over VPN MPLS features are requested, 6PE or 6VPE must be supported [RFC4798, RFC4659] The contracting authority shall specify the required protocol. Today every ISP with MPLS Backbone should be support 6PE and 6VPE standards. Isacco Jan Zorz @ go6.si ha scritto: > On 8.11.10 10:00, Isacco Fontana wrote: >> 6VPE (RFC 4659) >> 6PE (RFC 4798) >> >> These RFC are related to MPLS environment so I think 6PE and 6VPE >> should be >> mandatory for ISP that are using MPLS and offer ipv6 for direct internet >> connections and 6VPE for ipv6 over vpn mpls services. > > So, the correct wording inside mandatory section would be: > > - if IPv6 over MPLS and IPv6 over VPN MPLS features are requested, 6PE > or 6VPE must be supported [RFC4798, RFC4659] The contracting authority > shall specify the required protocol. > > Is this acceptable? > > Thnx, Jan Zorz > > -- Ing. Isacco Fontana Trentino Network s.r.l. A socio Unico Direzione Servizi Responsabile Area Ingegneria di Rete Via Gilli, 2 - 38100 TRENTO Tel (+39) 0461.020200 Fax (+39) 0461.020201 http://as12835.peeringdb.com/ -------------------------------------------------------------------------------------------------------------------------------- Cap. Soc. sottoscritto ? 7.573.248,00 i.v. - REG. IMP. C.F. e P. IVA 01904880224 E-mail: sede at trentinonetwork.it Societ? soggetta a direzione e controllo da parte della Provincia Autonoma di Trento. C.F. e P. IVA 00337460224 -------------------------------------------------------------------------------------------------------------------------------- From marc.blanchet at viagenie.ca Mon Nov 8 11:31:32 2010 From: marc.blanchet at viagenie.ca (Marc Blanchet) Date: Mon, 08 Nov 2010 18:31:32 +0800 Subject: [ipv6-wg] Last Call (20101117): Requirements For IPv6 in ICT Equipment In-Reply-To: <4CD7CDDB.4030908@go6.si> References: <20101107091709.GG2401@nsn.com> <4CD7B091.3020506@trentinonetwork.it> <4CD7B98C.7090005@go6.si> <4CD7BC15.3010306@trentinonetwork.it> <4CD7CDDB.4030908@go6.si> Message-ID: <4CD7D184.3090405@viagenie.ca> Le 10-11-08 18:15, Jan Zorz @ go6.si a ?crit : > On 8.11.10 10:00, Isacco Fontana wrote: >> 6VPE (RFC 4659) >> 6PE (RFC 4798) >> >> These RFC are related to MPLS environment so I think 6PE and 6VPE >> should be >> mandatory for ISP that are using MPLS and offer ipv6 for direct internet >> connections and 6VPE for ipv6 over vpn mpls services. > > So, the correct wording inside mandatory section would be: > > - if IPv6 over MPLS and IPv6 over VPN MPLS features are requested, 6PE > or 6VPE must be supported [RFC4798, RFC4659] The contracting authority > shall specify the required protocol. does not make sense to me. 6PE and 6VPE are two ways to run IPv6 over MPLS network, but are not the only ones. Therefore, it can not be mandatory. Marc. > > Is this acceptable? > > Thnx, Jan Zorz -- ========= IPv6 book: Migrating to IPv6, Wiley. http://www.ipv6book.ca Stun/Turn server for VoIP NAT-FW traversal: http://numb.viagenie.ca DTN Implementation: http://postellation.viagenie.ca NAT64-DNS64 Opensource: http://ecdysis.viagenie.ca From jan at go6.si Mon Nov 8 19:02:29 2010 From: jan at go6.si (Jan Zorz @ go6.si) Date: Mon, 08 Nov 2010 19:02:29 +0100 Subject: [ipv6-wg] Last Call (20101117): Requirements For IPv6 in ICT Equipment In-Reply-To: <4CD7D184.3090405@viagenie.ca> References: <20101107091709.GG2401@nsn.com> <4CD7B091.3020506@trentinonetwork.it> <4CD7B98C.7090005@go6.si> <4CD7BC15.3010306@trentinonetwork.it> <4CD7CDDB.4030908@go6.si> <4CD7D184.3090405@viagenie.ca> Message-ID: <4CD83B35.5010102@go6.si> On 8.11.10 11:31, Marc Blanchet wrote: > does not make sense to me. > > 6PE and 6VPE are two ways to run IPv6 over MPLS network, but are not the only > ones. Therefore, it can not be mandatory. Marc, hi :) Did not know you are on this list :) :) What do you suggest? Re-wording, add additional mechanisms or move it to optional section? Basically it is written "If requested by tender initiator...", that makes it as a choice... /jan From isacco.fontana at trentinonetwork.it Mon Nov 8 19:44:54 2010 From: isacco.fontana at trentinonetwork.it (Isacco Fontana) Date: Mon, 08 Nov 2010 19:44:54 +0100 Subject: [ipv6-wg] Last Call (20101117): Requirements For IPv6 in ICT Equipment In-Reply-To: <4CD7D184.3090405@viagenie.ca> References: <20101107091709.GG2401@nsn.com> <4CD7B091.3020506@trentinonetwork.it> <4CD7B98C.7090005@go6.si> <4CD7BC15.3010306@trentinonetwork.it> <4CD7CDDB.4030908@go6.si> <4CD7D184.3090405@viagenie.ca> Message-ID: <4CD84526.9010108@trentinonetwork.it> Hi Marc, your issue is true about IPv4 only backbone....but today for ISP with MPLS backbone the 6PE and 6VPE are used to deploy ipv6 on MPLS backbone. Isacco Marc Blanchet ha scritto: > Le 10-11-08 18:15, Jan Zorz @ go6.si a ?crit : >> On 8.11.10 10:00, Isacco Fontana wrote: >>> 6VPE (RFC 4659) >>> 6PE (RFC 4798) >>> >>> These RFC are related to MPLS environment so I think 6PE and 6VPE >>> should be >>> mandatory for ISP that are using MPLS and offer ipv6 for direct >>> internet >>> connections and 6VPE for ipv6 over vpn mpls services. >> >> So, the correct wording inside mandatory section would be: >> >> - if IPv6 over MPLS and IPv6 over VPN MPLS features are requested, 6PE >> or 6VPE must be supported [RFC4798, RFC4659] The contracting authority >> shall specify the required protocol. > > does not make sense to me. > > 6PE and 6VPE are two ways to run IPv6 over MPLS network, but are not > the only ones. Therefore, it can not be mandatory. > > Marc. > >> >> Is this acceptable? >> >> Thnx, Jan Zorz > > -- Ing. Isacco Fontana Trentino Network s.r.l. A socio Unico Direzione Servizi Responsabile Area Ingegneria di Rete Via Gilli, 2 - 38100 TRENTO Tel (+39) 0461.020200 Fax (+39) 0461.020201 http://as12835.peeringdb.com/ -------------------------------------------------------------------------------------------------------------------------------- Cap. Soc. sottoscritto ? 7.573.248,00 i.v. - REG. IMP. C.F. e P. IVA 01904880224 E-mail: sede at trentinonetwork.it Societ? soggetta a direzione e controllo da parte della Provincia Autonoma di Trento. C.F. e P. IVA 00337460224 -------------------------------------------------------------------------------------------------------------------------------- From michael.schneider at calispera.com Mon Nov 8 19:51:09 2010 From: michael.schneider at calispera.com (Michael Schneider/calispera.com) Date: Mon, 8 Nov 2010 19:51:09 +0100 Subject: [ipv6-wg] Last Call (20101117): Requirements For IPv6 in ICT Equipment In-Reply-To: <4CD83B35.5010102@go6.si> References: <20101107091709.GG2401@nsn.com> <4CD7B091.3020506@trentinonetwork.it> <4CD7B98C.7090005@go6.si> <4CD7BC15.3010306@trentinonetwork.it> <4CD7CDDB.4030908@go6.si> <4CD7D184.3090405@viagenie.ca> <4CD83B35.5010102@go6.si> Message-ID: Jan Zorz @ go6.si wrote on 08.11.2010 19:02:29: > On 8.11.10 11:31, Marc Blanchet wrote: > > does not make sense to me. > > > > 6PE and 6VPE are two ways to run IPv6 over MPLS network, but are not the only > > ones. Therefore, it can not be mandatory. > What do you suggest? Re-wording, add additional mechanisms or move it to > optional section? > Basically it is written "If requested by tender initiator...", that makes it as > a choice... Hi, LDPv6 was a dream, but only in draft status [1] this time. So i don`t know where is a right place for it. [1] http://tools.ietf.org/html/draft-manral-mpls-ldp-ipv6-04 Regards Michael From marc.blanchet at viagenie.ca Tue Nov 9 02:29:15 2010 From: marc.blanchet at viagenie.ca (Marc Blanchet) Date: Tue, 09 Nov 2010 09:29:15 +0800 Subject: [ipv6-wg] Last Call (20101117): Requirements For IPv6 in ICT Equipment In-Reply-To: <4CD84526.9010108@trentinonetwork.it> References: <20101107091709.GG2401@nsn.com> <4CD7B091.3020506@trentinonetwork.it> <4CD7B98C.7090005@go6.si> <4CD7BC15.3010306@trentinonetwork.it> <4CD7CDDB.4030908@go6.si> <4CD7D184.3090405@viagenie.ca> <4CD84526.9010108@trentinonetwork.it> Message-ID: <4CD8A3EB.2060006@viagenie.ca> Le 10-11-09 02:44, Isacco Fontana a ?crit : > Hi Marc, > your issue is true about IPv4 only backbone....but today for ISP with > MPLS backbone the 6PE and 6VPE are used to deploy ipv6 on MPLS backbone. I know (and have been helping providers to deploy 6PE and 6VPE). My point is to make it "mandatory" is the issue. Marc. > > Isacco > > > Marc Blanchet ha scritto: >> Le 10-11-08 18:15, Jan Zorz @ go6.si a ?crit : >>> On 8.11.10 10:00, Isacco Fontana wrote: >>>> 6VPE (RFC 4659) >>>> 6PE (RFC 4798) >>>> >>>> These RFC are related to MPLS environment so I think 6PE and 6VPE >>>> should be >>>> mandatory for ISP that are using MPLS and offer ipv6 for direct >>>> internet >>>> connections and 6VPE for ipv6 over vpn mpls services. >>> >>> So, the correct wording inside mandatory section would be: >>> >>> - if IPv6 over MPLS and IPv6 over VPN MPLS features are requested, 6PE >>> or 6VPE must be supported [RFC4798, RFC4659] The contracting authority >>> shall specify the required protocol. >> >> does not make sense to me. >> >> 6PE and 6VPE are two ways to run IPv6 over MPLS network, but are not >> the only ones. Therefore, it can not be mandatory. >> >> Marc. >> >>> >>> Is this acceptable? >>> >>> Thnx, Jan Zorz >> >> > > -- ========= IPv6 book: Migrating to IPv6, Wiley. http://www.ipv6book.ca Stun/Turn server for VoIP NAT-FW traversal: http://numb.viagenie.ca DTN Implementation: http://postellation.viagenie.ca NAT64-DNS64 Opensource: http://ecdysis.viagenie.ca From marc.blanchet at viagenie.ca Tue Nov 9 03:25:17 2010 From: marc.blanchet at viagenie.ca (Marc Blanchet) Date: Tue, 09 Nov 2010 10:25:17 +0800 Subject: [ipv6-wg] Last Call (20101117): Requirements For IPv6 in ICT Equipment In-Reply-To: <4CD83B35.5010102@go6.si> References: <20101107091709.GG2401@nsn.com> <4CD7B091.3020506@trentinonetwork.it> <4CD7B98C.7090005@go6.si> <4CD7BC15.3010306@trentinonetwork.it> <4CD7CDDB.4030908@go6.si> <4CD7D184.3090405@viagenie.ca> <4CD83B35.5010102@go6.si> Message-ID: <4CD8B10D.8000405@viagenie.ca> Le 10-11-09 02:02, Jan Zorz @ go6.si a ?crit : > On 8.11.10 11:31, Marc Blanchet wrote: >> does not make sense to me. >> >> 6PE and 6VPE are two ways to run IPv6 over MPLS network, but are not >> the only >> ones. Therefore, it can not be mandatory. > > Marc, hi :) > > Did not know you are on this list :) :) well, I've been here probably since the existence of the ripe ipv6 wg... We have been more active when we were working on the update of the RPSL (RPSLng) since we started that work a while ago and RPSLng was mostly discussed in RIPE... > > What do you suggest? Re-wording, add additional mechanisms or move it to > optional section? my only point is the "mandatory" part. s/must/may|should consider/... Marc. > > Basically it is written "If requested by tender initiator...", that > makes it as a choice... > > /jan -- ========= IPv6 book: Migrating to IPv6, Wiley. http://www.ipv6book.ca Stun/Turn server for VoIP NAT-FW traversal: http://numb.viagenie.ca DTN Implementation: http://postellation.viagenie.ca NAT64-DNS64 Opensource: http://ecdysis.viagenie.ca From mohsen.souissi at nic.fr Tue Nov 9 03:56:06 2010 From: mohsen.souissi at nic.fr (Mohsen Souissi) Date: Tue, 9 Nov 2010 03:56:06 +0100 Subject: [ipv6-wg] Last Call (20101117): Requirements For IPv6 in ICT Equipment In-Reply-To: <20101107091709.GG2401@nsn.com> References: <20101107091709.GG2401@nsn.com> Message-ID: <20101109025606.GD21625@kerkenna.nic.fr> I support this document to be published. Good work, well done. Some suggestions: - RFC 2461 (2 occurrences) to be replaced by RFC 4861? - RFC 2462 (1 occurrence) to be replaced by RFC 4862 What about load balancers, these types of equipment can hardly fit in the categories defined (if I'm correct). Yet they might be a pain in termes ov v6-v4 functional and performance parity. Is that implicitly included somewhere (I might overlooked) or just omitted/forgotten? Mohsen. On 07 Nov, David Kessens wrote: | | 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 From Francis.Dupont at fdupont.fr Tue Nov 9 04:29:31 2010 From: Francis.Dupont at fdupont.fr (Francis Dupont) Date: Tue, 09 Nov 2010 04:29:31 +0100 Subject: [ipv6-wg] Last Call (20101117): Requirements For IPv6 in ICT Equipment In-Reply-To: Your message of Sun, 07 Nov 2010 01:17:10 PST. <20101107091709.GG2401@nsn.com> Message-ID: <201011090329.oA93TVUa030492@givry.fdupont.fr> In your previous mail you wrote: 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. => yes 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). => there is at least one error: IKEv2 relies on IPsec-v3 so it is not possible to require IPsec-v2 and IKEv2 with IPsec-v3 optional. There are two ways to solve this: make IKEv2 optional or IMHO far better swap IPsec-v2 and IPsec-v3. BTW I think the correct spelling for UPNP is UPnP (lower case 'n'). Thanks Francis.Dupont at fdupont.fr From isacco.fontana at trentinonetwork.it Tue Nov 9 05:23:27 2010 From: isacco.fontana at trentinonetwork.it (Isacco Fontana) Date: Tue, 09 Nov 2010 05:23:27 +0100 Subject: [ipv6-wg] Last Call (20101117): Requirements For IPv6 in ICT Equipment In-Reply-To: <4CD8A3EB.2060006@viagenie.ca> References: <20101107091709.GG2401@nsn.com> <4CD7B091.3020506@trentinonetwork.it> <4CD7B98C.7090005@go6.si> <4CD7BC15.3010306@trentinonetwork.it> <4CD7CDDB.4030908@go6.si> <4CD7D184.3090405@viagenie.ca> <4CD84526.9010108@trentinonetwork.it> <4CD8A3EB.2060006@viagenie.ca> Message-ID: <4CD8CCBF.9010809@trentinonetwork.it> Yes Marc, but if they are optional... some will be mandatory. What will be mandatory for Ipv4 Mpls backbone ? ;) If we use as mandatory dual stack the ipv6 vpn mpls not work. We must use 6VPE that is over ipv4. Today as you know LDPv6 is under developement by ietf and vendors will wait 1-2 years to deploy the protocol inside os. I think today and when ipv4 addresses will finsh the ipv4 mpls backbones remains the same ($$) and the 6PE and 6VPE will be used. Isacco Marc Blanchet ha scritto: > Le 10-11-09 02:44, Isacco Fontana a ?crit : >> Hi Marc, >> your issue is true about IPv4 only backbone....but today for ISP with >> MPLS backbone the 6PE and 6VPE are used to deploy ipv6 on MPLS backbone. > > I know (and have been helping providers to deploy 6PE and 6VPE). My > point is to make it "mandatory" is the issue. > > Marc. > >> >> Isacco >> >> >> Marc Blanchet ha scritto: >>> Le 10-11-08 18:15, Jan Zorz @ go6.si a ?crit : >>>> On 8.11.10 10:00, Isacco Fontana wrote: >>>>> 6VPE (RFC 4659) >>>>> 6PE (RFC 4798) >>>>> >>>>> These RFC are related to MPLS environment so I think 6PE and 6VPE >>>>> should be >>>>> mandatory for ISP that are using MPLS and offer ipv6 for direct >>>>> internet >>>>> connections and 6VPE for ipv6 over vpn mpls services. >>>> >>>> So, the correct wording inside mandatory section would be: >>>> >>>> - if IPv6 over MPLS and IPv6 over VPN MPLS features are requested, 6PE >>>> or 6VPE must be supported [RFC4798, RFC4659] The contracting authority >>>> shall specify the required protocol. >>> >>> does not make sense to me. >>> >>> 6PE and 6VPE are two ways to run IPv6 over MPLS network, but are not >>> the only ones. Therefore, it can not be mandatory. >>> >>> Marc. >>> >>>> >>>> Is this acceptable? >>>> >>>> Thnx, Jan Zorz >>> >>> >> >> > > -- Ing. Isacco Fontana Trentino Network s.r.l. A socio Unico Direzione Servizi Responsabile Area Ingegneria di Rete Via Gilli, 2 - 38100 TRENTO Tel (+39) 0461.020200 Fax (+39) 0461.020201 http://as12835.peeringdb.com/ -------------------------------------------------------------------------------------------------------------------------------- Cap. Soc. sottoscritto ? 7.573.248,00 i.v. - REG. IMP. C.F. e P. IVA 01904880224 E-mail: sede at trentinonetwork.it Societ? soggetta a direzione e controllo da parte della Provincia Autonoma di Trento. C.F. e P. IVA 00337460224 -------------------------------------------------------------------------------------------------------------------------------- From mohsen.souissi at nic.fr Tue Nov 9 05:46:33 2010 From: mohsen.souissi at nic.fr (Mohsen Souissi) Date: Tue, 9 Nov 2010 05:46:33 +0100 Subject: [ipv6-wg] Last Call (20101117): Requirements For IPv6 in ICT Equipment In-Reply-To: <201011090329.oA93TVUa030492@givry.fdupont.fr> References: <20101107091709.GG2401@nsn.com> <201011090329.oA93TVUa030492@givry.fdupont.fr> Message-ID: <20101109044633.GA23099@kerkenna.nic.fr> Following Francis's messages, some references updates below: On 09 Nov, Francis Dupont wrote: [...] | | 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). | | => there is at least one error: IKEv2 relies on IPsec-v3 so it is not | possible to require IPsec-v2 and IKEv2 with IPsec-v3 optional. | There are two ways to solve this: make IKEv2 optional or IMHO far better | swap IPsec-v2 and IPsec-v3. For IKEv2: s/[RFC4306, RFC4718]/[RFC5996] For IPsec-v3: s/[RFC2401]/[RFC4301] s/[RFC2402]/[RFC4302, RFC4835] s/[RFC2406]/[RFC4303, RFC4835] Btw, to monitor which RFC obsoletes/is obsoloted by/updates/is updated by which RFC(s), I would recommend this very good reference: http://www.rfc-editor.org/cgi-bin/rfcsearch.pl Mohsen. From jan at go6.si Tue Nov 9 09:34:24 2010 From: jan at go6.si (Jan Zorz @ go6.si) Date: Tue, 09 Nov 2010 09:34:24 +0100 Subject: [ipv6-wg] Last Call (20101117): Requirements For IPv6 in ICT Equipment In-Reply-To: <4CD8A3EB.2060006@viagenie.ca> References: <20101107091709.GG2401@nsn.com> <4CD7B091.3020506@trentinonetwork.it> <4CD7B98C.7090005@go6.si> <4CD7BC15.3010306@trentinonetwork.it> <4CD7CDDB.4030908@go6.si> <4CD7D184.3090405@viagenie.ca> <4CD84526.9010108@trentinonetwork.it> <4CD8A3EB.2060006@viagenie.ca> Message-ID: <4CD90790.2040401@go6.si> On 9.11.10 2:29, Marc Blanchet wrote: > I know (and have been helping providers to deploy 6PE and 6VPE). My point is to > make it "mandatory" is the issue. The correct interpretation is "mandatory if functionality required" :) If you want to run 6PE or 6VPE, then it's mandatory that equipment supports it. Unconditionally mandatory are RFC lines, that does not contain "if required by". Does this make sense? /jan From us at sweet-sorrow.com Tue Nov 9 09:39:20 2010 From: us at sweet-sorrow.com (Us) Date: Tue, 09 Nov 2010 09:39:20 +0100 Subject: [ipv6-wg] Last Call (20101117): Requirements For IPv6 in ICT Equipment In-Reply-To: <4CD90790.2040401@go6.si> References: <20101107091709.GG2401@nsn.com> <4CD7B091.3020506@trentinonetwork.it> <4CD7B98C.7090005@go6.si> <4CD7BC15.3010306@trentinonetwork.it> <4CD7CDDB.4030908@go6.si> <4CD7D184.3090405@viagenie.ca> <4CD84526.9010108@trentinonetwork.it> <4CD8A3EB.2060006@viagenie.ca> <4CD90790.2040401@go6.si> Message-ID: <4CD908B8.3050003@sweet-sorrow.com> On 11/09/2010 09:34 AM, Jan Zorz @ go6.si wrote: > On 9.11.10 2:29, Marc Blanchet wrote: > >> I know (and have been helping providers to deploy 6PE and 6VPE). My >> point is to >> make it "mandatory" is the issue. > > The correct interpretation is "mandatory if functionality required" :) > > If you want to run 6PE or 6VPE, then it's mandatory that equipment > supports it. > > Unconditionally mandatory are RFC lines, that does not contain "if > required by". > > Does this make sense? > > /jan > > I think this is a bit redundant. It reads as "if you need, you must have it". Us From jan at go6.si Tue Nov 9 09:49:28 2010 From: jan at go6.si (Jan Zorz @ go6.si) Date: Tue, 09 Nov 2010 09:49:28 +0100 Subject: [ipv6-wg] Last Call (20101117): Requirements For IPv6 in ICT Equipment In-Reply-To: <4CD908B8.3050003@sweet-sorrow.com> References: <20101107091709.GG2401@nsn.com> <4CD7B091.3020506@trentinonetwork.it> <4CD7B98C.7090005@go6.si> <4CD7BC15.3010306@trentinonetwork.it> <4CD7CDDB.4030908@go6.si> <4CD7D184.3090405@viagenie.ca> <4CD84526.9010108@trentinonetwork.it> <4CD8A3EB.2060006@viagenie.ca> <4CD90790.2040401@go6.si> <4CD908B8.3050003@sweet-sorrow.com> Message-ID: <4CD90B18.5020005@go6.si> On 9.11.10 9:39, Us wrote: > I think this is a bit redundant. It reads as "if you need, you must have > it". Yes. For example a car. Car must have some basic functionality, that is mandatory. Now, if you want to do some additional stuff with your car, you need to require that and when you require that it becomes mandatory. It's mandatory, that car moves on the road. If you need to carry bigger load, then you require the car to be a bit different. Still a car, but with mandatory functions that you need for your job, like a big booth or something. If you don't require a functionality it is not mandatory. /jan From jan at go6.si Tue Nov 9 10:23:48 2010 From: jan at go6.si (Jan Zorz @ go6.si) Date: Tue, 09 Nov 2010 10:23:48 +0100 Subject: [ipv6-wg] Last Call (20101117): Requirements For IPv6 in ICT Equipment In-Reply-To: <20101109025606.GD21625@kerkenna.nic.fr> References: <20101107091709.GG2401@nsn.com> <20101109025606.GD21625@kerkenna.nic.fr> Message-ID: <4CD91324.40500@go6.si> On 9.11.10 3:56, Mohsen Souissi wrote: > I support this document to be published. Good work, well done. > > Some suggestions: > > - RFC 2461 (2 occurrences) to be replaced by RFC 4861? > - RFC 2462 (1 occurrence) to be replaced by RFC 4862 Hi, fixed, thnx for head up. Will be visible in next version of the draft. > What about load balancers, these types of equipment can hardly fit in > the categories defined (if I'm correct). Yet they might be a pain in > termes ov v6-v4 functional and performance parity. This document is intended to be published as BCP and we can add/change things also later, after publication. I agree load balancers hardly fit in any category, but we had to stop expanding the complexity at some point :) If we find approach how to specify that without adding more complexity, we can add that later, if community will agree on that. thnx, /jan From jan at go6.si Tue Nov 9 10:26:32 2010 From: jan at go6.si (Jan Zorz @ go6.si) Date: Tue, 09 Nov 2010 10:26:32 +0100 Subject: [ipv6-wg] Last Call (20101117): Requirements For IPv6 in ICT Equipment In-Reply-To: <201011090329.oA93TVUa030492@givry.fdupont.fr> References: <201011090329.oA93TVUa030492@givry.fdupont.fr> Message-ID: <4CD913C8.9030501@go6.si> On 9.11.10 4:29, Francis Dupont wrote: > 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. > > => yes Hi, Thnx for your support (for support from all of you :) ) > > 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). > > => there is at least one error: IKEv2 relies on IPsec-v3 so it is not > possible to require IPsec-v2 and IKEv2 with IPsec-v3 optional. > There are two ways to solve this: make IKEv2 optional or IMHO far better > swap IPsec-v2 and IPsec-v3. Theoretically I agree with you. But we try not to currently exclude too much hardware. What percentage of current equipment you can buy supports IPsec-v3 ? > > BTW I think the correct spelling for UPNP is UPnP (lower case 'n'). Will fix, thnx. /jan From marcoh at marcoh.net Tue Nov 9 11:53:47 2010 From: marcoh at marcoh.net (Marco Hogewoning) Date: Tue, 9 Nov 2010 11:53:47 +0100 Subject: [ipv6-wg] Draft agenda RIPE-61: Tuesday November 16th 16:00 - 18:00 CET Message-ID: Hello, Sorry for beng a bit late. This is the draft agenda for the IPv6 WG sesison in Rome. We have a pretty full programme with lots of interesting examples of what happens when you deploy IPv6 in the real world. 1 opening/administrativa 2 "Experiences from an IPv6-only world" - Jari Arkko/Ari Keranen 3 "Detecting (and fixing!), IPv6 dualstack brokenness" - Tore Aderson 4 "The results on introducing native IPv6 at XS4ALL - Marco Hogewoning 5 "RIPE NCC stats" - Emile Aben 6 "Native IPv6 via xDSL - How to tweak your LNS" - Emanuel Kleindienst 7 "Requirements For IPv6 in ICT Equipment" - Jan Zorz/Sander Steffan 8 "Update on policy proposal 2010-06" - Marco Hogewoning/Remco van Mook See you all in Rome and for those of you who can't make it, this session will be live broadcasted. See http://ripe61.ripe.net/programme/remote-participation/ for more information. On behalf of the IPv6 WG chairs, Marco Hogewoning From kuenzler at init7.net Tue Nov 9 13:26:53 2010 From: kuenzler at init7.net (Fredy Kuenzler) Date: Tue, 09 Nov 2010 13:26:53 +0100 Subject: [ipv6-wg] Draft agenda RIPE-61: Tuesday November 16th 16:00 - 18:00 CET In-Reply-To: References: Message-ID: <4CD93E0D.6020601@init7.net> Dear all, Am 09.11.2010 11:53, schrieb Marco Hogewoning: > 6 "Native IPv6 via xDSL - How to tweak your LNS" - Emanuel Kleindienst Thanks for the notification, small correction it will not be my colleague Emanuel Kleindienst, but myself presenting (Emanuel will not attend RIPE #61). Best regards, Fredy K?nzler Init7 / AS13030 From ipepelnjak at gmail.com Wed Nov 10 09:08:42 2010 From: ipepelnjak at gmail.com (Ivan Pepelnjak) Date: Wed, 10 Nov 2010 09:08:42 +0100 Subject: [ipv6-wg] Last Call (20101117): Requirements For IPv6 in ICT Equipment Message-ID: <005a01cb80ae$7e9b4180$7bd1c480$@com> 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 From ipepelnjak at gmail.com Wed Nov 10 09:26:43 2010 From: ipepelnjak at gmail.com (Ivan Pepelnjak) Date: Wed, 10 Nov 2010 09:26:43 +0100 Subject: [ipv6-wg] Last Call (20101117): Requirements For IPv6 in ICT Equipment Message-ID: <005e01cb80b1$0338ec60$09aac520$@com> 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 From jan at go6.si Wed Nov 10 14:22:06 2010 From: jan at go6.si (Jan Zorz @ go6.si) Date: Wed, 10 Nov 2010 14:22:06 +0100 Subject: [ipv6-wg] Last Call (20101117): Requirements For IPv6 in ICT Equipment In-Reply-To: <005a01cb80ae$7e9b4180$7bd1c480$@com> References: <005a01cb80ae$7e9b4180$7bd1c480$@com> Message-ID: <4CDA9C7E.7060109@go6.si> On 10.11.10 9:08, Ivan Pepelnjak wrote: > Dear all, > > As I'm one of the original authors of this document (now nicely hidden behind > the "Slovenian IPv6 working group" blob ;) ;) > * 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] Agree. > > * 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] Agree. > 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) What can I say? Agree :) You are the MPLS man (as you wrote a Cisco book about that), so I trust you with this :) Cheers, /jan From isacco.fontana at trentinonetwork.it Wed Nov 10 14:24:56 2010 From: isacco.fontana at trentinonetwork.it (Isacco Fontana) Date: Wed, 10 Nov 2010 14:24:56 +0100 Subject: [ipv6-wg] Last Call (20101117): Requirements For IPv6 in ICT Equipment In-Reply-To: <4CDA9C7E.7060109@go6.si> References: <005a01cb80ae$7e9b4180$7bd1c480$@com> <4CDA9C7E.7060109@go6.si> Message-ID: <4CDA9D28.5010104@trentinonetwork.it> agree ;) Jan Zorz @ go6.si ha scritto: > On 10.11.10 9:08, Ivan Pepelnjak wrote: >> Dear all, >> >> As I'm one of the original authors of this document (now nicely >> hidden behind >> the "Slovenian IPv6 working group" blob ;) > > ;) > >> * 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] > > Agree. > >> >> * 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] > > Agree. > >> 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) > > What can I say? Agree :) > > You are the MPLS man (as you wrote a Cisco book about that), so I > trust you with this :) > > Cheers, /jan > > -- Ing. Isacco Fontana Trentino Network s.r.l. A socio Unico Direzione Servizi Responsabile Area Ingegneria di Rete Via Gilli, 2 - 38100 TRENTO Tel (+39) 0461.020200 Fax (+39) 0461.020201 http://as12835.peeringdb.com/ -------------------------------------------------------------------------------------------------------------------------------- Cap. Soc. sottoscritto ? 7.573.248,00 i.v. - REG. IMP. C.F. e P. IVA 01904880224 E-mail: sede at trentinonetwork.it Societ? soggetta a direzione e controllo da parte della Provincia Autonoma di Trento. C.F. e P. IVA 00337460224 -------------------------------------------------------------------------------------------------------------------------------- From mir at ripe.net Fri Nov 12 14:50:18 2010 From: mir at ripe.net (Mirjam Kuehne) Date: Fri, 12 Nov 2010 14:50:18 +0100 Subject: [ipv6-wg] Interactive Graph on RIPE Labs: Networks with IPv6 over Time Message-ID: <4CDD461A.4090203@ripe.net> Dear colleagues, On RIPE Labs you can now find an interactive graph (provided by Emile Aben) that shows the percentage of networks (ASes) that announce one or more IPv6 prefixes in the global routing table. You can specify countries and compare the IPv6 deployment by region: https://labs.ripe.net/Members/emileaben/interesting-graph-networks-with-ipv6-over-time Kind Regards, Mirjam Kuehne RIPE NCC From pettai at nordu.net Mon Nov 15 15:37:24 2010 From: pettai at nordu.net (Fredrik Pettai) Date: Mon, 15 Nov 2010 15:37:24 +0100 Subject: Lack of DHCPv6 (was: Re: [ipv6-wg] New draft document available: ... ) In-Reply-To: <8E29CE63-5470-4CCA-83D5-6C13940805BA@bondis.org> References: <8DD85FED-FF25-4441-B8E7-05EA89A37E4F@marcoh.net> <4CA992FC.6020607@go6.si> <4CAD87B8.2050005@go6.si> <8F61AD98-F55D-4DF3-9264-970ED564B107@bondis.org> <4CAED238.3000403@go6.si> <8E29CE63-5470-4CCA-83D5-6C13940805BA@bondis.org> Message-ID: On Oct 8, 2010, at 10:41 AM, Jo?o Damas wrote: > On 8 Oct 2010, at 10:11, Jan Zorz @ go6.si wrote: >>> Apple is an organisation. It does not take decisions. People at Apple do. In >>> this case, you need to talk to Stuart Cheshire. >> >> Anyone knows or have contact with Stuart Cheshire @Apple? > > Stuart Cheshire is his public address. Sorry for late reply. I also dislike the lack of DHCPv6 in MacOSX, but trying to contact an engineer is not the way to go (unless you're lucky to hit one that I actually can influence that decision at all...) (Shane also told me that Apple are supporters of the zeroconf philosophy, so they are of a different opinion of how things should be solved. Share: correct me if I interpreted you wrong) I also know an engineer at Apple, and according to him, the only way of influencing decisions of what should be fixed / added etc. is to bugreport it (@ https://bugreport.apple.com). The more people that do this, the better, and more likelier that it will be implemented. So, spread the word... let Apple know what you think about (the lack of) DHCPv6. I thought I sent this to this list long time ago, but it must have been in my own virtual reality... Regards, /P From michael.schneider at calispera.com Mon Nov 15 21:07:05 2010 From: michael.schneider at calispera.com (Michael Schneider/calispera.com) Date: Mon, 15 Nov 2010 21:07:05 +0100 Subject: Lack of DHCPv6 (was: Re: [ipv6-wg] New draft document available: ... ) In-Reply-To: References: <8DD85FED-FF25-4441-B8E7-05EA89A37E4F@marcoh.net> <4CA992FC.6020607@go6.si> <4CAD87B8.2050005@go6.si> <8F61AD98-F55D-4DF3-9264-970ED564B107@bondis.org> <4CAED238.3000403@go6.si> <8E29CE63-5470-4CCA-83D5-6C13940805BA@bondis.org> Message-ID: Fredrik Pettai wrote on 15.11.2010 15:37:24: > (Shane also told me that Apple are supporters of the zeroconf philosophy, > so they are of a different opinion of how things should be solved. Share: > correct me if I interpreted you wrong) Hi Fredrik, yes you are right, Apples zeroconf initiative called Bonjour ( www.apple.com/bonjour). > I also know an engineer at Apple, and according to him, the only way of > influencing decisions of what should be fixed / added etc. is to bugreport it (@ > https://bugreport.apple.com). The more people that do this, the better, > and more likelier that it will be implemented. > So, spread the word... let Apple know what you think about (the lack of) DHCPv6. But, what is the need for dhcpv6 if you have technologys like IPv6 SAC mechanism with (for example) MulticastDNS ( draft-cheshire-dnsext-multicastdns.txt) support. IMHO at least 80% of standard (office) environments don`t need any dhcpv6 support. Let me know what you are think about it. Regards Michael From mir at ripe.net Tue Nov 16 10:24:36 2010 From: mir at ripe.net (Mirjam Kuehne) Date: Tue, 16 Nov 2010 10:24:36 +0100 Subject: [ipv6-wg] IPv6 RIPEness - all 4-star LIRs listed publicly now In-Reply-To: <4CDD461A.4090203@ripe.net> References: <4CDD461A.4090203@ripe.net> Message-ID: <4CE24DD4.4090806@ripe.net> Dear colleagues, As a next step in the IPv6 RIPEness study, we published a list of LIRs that fulfill all four criteria (as described in the definition of IPv6 RIPEness) - thanks to Emile Aben and Vesna Manojlovic: https://labs.ripe.net/Members/emileaben/ipv6-ripeness-the-list-of-4-star-lirs We also created a page that lists all IPv6 RIPEness related information including the 4 criteria and a link to the live data: http://labs.ripe.net/topics/ipv6ripeness Kind Regards, Mirjam Kuehne RIPE NCC From marcoh at marcoh.net Tue Nov 16 10:43:20 2010 From: marcoh at marcoh.net (Marco Hogewoning) Date: Tue, 16 Nov 2010 10:43:20 +0100 Subject: [ipv6-wg] Draft agenda RIPE-61: Tuesday November 16th 16:00 - 18:00 CET In-Reply-To: References: Message-ID: <3926CFCB-6BB3-4E13-9B0C-CB8DE93B9870@marcoh.net> It has been pointed out to me my previous message contained a few mistakes > 3 "Detecting (and fixing!), IPv6 dualstack brokenness" - Tore Aderson This should have said Tore Anderson > 7 "Requirements For IPv6 in ICT Equipment" - Jan Zorz/Sander Steffan And another typo, it's Steffann Sorry for spelling your names wrong. Hope to see you all this afternoon, session starts at 16:00 localtime in the main room. Marco From training at ripe.net Tue Nov 16 13:26:30 2010 From: training at ripe.net (Training Mailbox) Date: Tue, 16 Nov 2010 13:26:30 +0100 Subject: [ipv6-wg] Announcement: RIPE NCC Training Courses Message-ID: <4CE27876.5090804@ripe.net> [Apologies for duplicate e-mails] Dear Colleagues, The RIPE NCC invites you to register for one of our upcoming training courses: - The LIR Training Course This course teaches LIRs how to request Internet number resources and interact with the RIPE NCC. A course outline is available at: http://www.ripe.net/training/lir/outline.html - The Routing Registry Training Course This course teaches LIRs how to use the RIPE Database for routing. A course outline is available at: http://www.ripe.net/training/rr/outline.html - The IPv6 Training Course This course teaches LIRs about the need for IPv6 and includes basic information on how to plan your deployment. A course outline is available at: http://www.ripe.net/training/ipv6/outline.html To see the location of upcoming courses and to register, please use the LIR Portal or complete the registration form on our website at: RIPE NCC Upcoming Courses List & Registration https://lirportal.ripe.net/lirportal/training/course-list.html If you have any questions, please do not hesitate to contact us at . Kind regards, Rumy Kanis Training Services Manager RIPE NCC From gert at space.net Tue Nov 16 15:07:22 2010 From: gert at space.net (Gert Doering) Date: Tue, 16 Nov 2010 15:07:22 +0100 Subject: [ipv6-wg] IPv6 RIPEness - all 4-star LIRs listed publicly now In-Reply-To: <4CE24DD4.4090806@ripe.net> References: <4CDD461A.4090203@ripe.net> <4CE24DD4.4090806@ripe.net> Message-ID: <20101116140722.GJ86316@Space.Net> Hi, On Tue, Nov 16, 2010 at 10:24:36AM +0100, Mirjam Kuehne wrote: > We also created a page that lists all IPv6 RIPEness related information > including the 4 criteria and a link to the live data: > > http://labs.ripe.net/topics/ipv6ripeness So what happened to the "5 star" criteria thoughts? We need more stars! Gert Doering -- NetMaster -- did you enable IPv6 on something today...? SpaceNet AG Vorstand: Sebastian v. Bomhard Joseph-Dollinger-Bogen 14 Aufsichtsratsvors.: A. Grundner-Culemann D-80807 Muenchen HRB: 136055 (AG Muenchen) Tel: +49 (89) 32356-444 USt-IdNr.: DE813185279 From slz at baycix.de Tue Nov 16 15:21:02 2010 From: slz at baycix.de (Sascha Lenz) Date: Tue, 16 Nov 2010 15:21:02 +0100 Subject: [ipv6-wg] IPv6 RIPEness - all 4-star LIRs listed publicly now In-Reply-To: <20101116140722.GJ86316@Space.Net> References: <4CDD461A.4090203@ripe.net> <4CE24DD4.4090806@ripe.net> <20101116140722.GJ86316@Space.Net> Message-ID: <857F4A18-E36A-40C5-A5E0-E2FF6ED7BE4F@baycix.de> Hi, Am 16.11.2010 um 15:07 schrieb Gert Doering: > Hi, > > On Tue, Nov 16, 2010 at 10:24:36AM +0100, Mirjam Kuehne wrote: >> We also created a page that lists all IPv6 RIPEness related information >> including the 4 criteria and a link to the live data: >> >> http://labs.ripe.net/topics/ipv6ripeness > > So what happened to the "5 star" criteria thoughts? We need more stars! ...and more free T-Shirts! :-) But i second that - wannahavemorestars!!1one!!eleven!! -- bye -slz From kuenzler at init7.net Tue Nov 16 15:34:45 2010 From: kuenzler at init7.net (Fredy Kuenzler) Date: Tue, 16 Nov 2010 15:34:45 +0100 Subject: [ipv6-wg] IPv6 RIPEness - all 4-star LIRs listed publicly now In-Reply-To: <20101116140722.GJ86316@Space.Net> References: <4CDD461A.4090203@ripe.net> <4CE24DD4.4090806@ripe.net> <20101116140722.GJ86316@Space.Net> Message-ID: <4CE29685.80301@init7.net> Am 16.11.2010 15:07, schrieb Gert Doering: > On Tue, Nov 16, 2010 at 10:24:36AM +0100, Mirjam Kuehne wrote: >> We also created a page that lists all IPv6 RIPEness related information >> including the 4 criteria and a link to the live data: >> >> http://labs.ripe.net/topics/ipv6ripeness > > So what happened to the "5 star" criteria thoughts? We need more stars! I want 7 stars! ;-) Fredy / Init7 From gert at space.net Tue Nov 16 15:35:52 2010 From: gert at space.net (Gert Doering) Date: Tue, 16 Nov 2010 15:35:52 +0100 Subject: [ipv6-wg] IPv6 RIPEness - all 4-star LIRs listed publicly now In-Reply-To: <4CE29685.80301@init7.net> References: <4CDD461A.4090203@ripe.net> <4CE24DD4.4090806@ripe.net> <20101116140722.GJ86316@Space.Net> <4CE29685.80301@init7.net> Message-ID: <20101116143552.GK86316@Space.Net> Hi, On Tue, Nov 16, 2010 at 03:34:45PM +0100, Fredy Kuenzler wrote: > I want 7 stars! ;-) I think "offering free IPv6 connectivity on 100 Mbit links in .ch" qualifies for that! /me hands a bunch of stars to Fredy :-) (can't compete with *that* :)) ) Gert Doering -- NetMaster -- did you enable IPv6 on something today...? SpaceNet AG Vorstand: Sebastian v. Bomhard Joseph-Dollinger-Bogen 14 Aufsichtsratsvors.: A. Grundner-Culemann D-80807 Muenchen HRB: 136055 (AG Muenchen) Tel: +49 (89) 32356-444 USt-IdNr.: DE813185279 -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 306 bytes Desc: not available URL: From pettai at nordu.net Tue Nov 16 16:02:09 2010 From: pettai at nordu.net (Fredrik Pettai) Date: Tue, 16 Nov 2010 16:02:09 +0100 Subject: Lack of DHCPv6 (was: Re: [ipv6-wg] New draft document available: ... ) In-Reply-To: References: <8DD85FED-FF25-4441-B8E7-05EA89A37E4F@marcoh.net> <4CA992FC.6020607@go6.si> <4CAD87B8.2050005@go6.si> <8F61AD98-F55D-4DF3-9264-970ED564B107@bondis.org> <4CAED238.3000403@go6.si> <8E29CE63-5470-4CCA-83D5-6C13940805BA@bondis.org> Message-ID: <43142D3D-7D06-4D3D-A47D-6AD6B6EEC111@nordu.net> On Nov 15, 2010, at 9:07 PM, Michael Schneider/calispera.com wrote: > Fredrik Pettai wrote on 15.11.2010 15:37:24: >> (Shane also told me that Apple are supporters of the zeroconf > philosophy, >> so they are of a different opinion of how things should be solved. > Share: >> correct me if I interpreted you wrong) > > Hi Fredrik, > yes you are right, Apples zeroconf initiative called Bonjour ( > www.apple.com/bonjour). > >> I also know an engineer at Apple, and according to him, the only way of >> influencing decisions of what should be fixed / added etc. is to > bugreport it (@ >> https://bugreport.apple.com). The more people that do this, the better, >> and more likelier that it will be implemented. > >> So, spread the word... let Apple know what you think about (the lack of) > DHCPv6. > > But, what is the need for dhcpv6 if you have technologys like IPv6 SAC > mechanism with (for example) MulticastDNS ( > draft-cheshire-dnsext-multicastdns.txt) support. > > IMHO at least 80% of standard (office) environments don`t need any dhcpv6 > support. > Let me know what you are think about it. For the home user that's fine, but maybe not for a enterprise network. It's not just about provisioning DNS/resolver configuration to clients. It's about access control, e.g. to be able to centrally manage which client that are connected/assigned an IP. Traceability e.g. which client where connect a specific time etc. to name a few of the common things you do with a centralized DHCP(v4) solution today. (I do confess that I'm not up to speed on the IPv6 development since ~1 year back) Regards, /P From lutz at iks-jena.de Tue Nov 16 15:41:25 2010 From: lutz at iks-jena.de (Lutz Donnerhacke) Date: Tue, 16 Nov 2010 14:41:25 +0000 (UTC) Subject: [ipv6-wg] IPv6 RIPEness - all 4-star LIRs listed publicly now References: <20101116140722.GJ86316@Space.Net> Message-ID: * Gert Doering wrote: > So what happened to the "5 star" criteria thoughts? We need more stars! We need an aleph metrics: - Aleph 1 is an ISP which use IPv6 productivly itself. - Aleph x is an ISP which has 2^x downsteams with at least aleph (x-1) From michael.schneider at calispera.com Tue Nov 16 18:13:48 2010 From: michael.schneider at calispera.com (Michael Schneider/calispera.com) Date: Tue, 16 Nov 2010 18:13:48 +0100 Subject: Lack of DHCPv6 (was: Re: [ipv6-wg] New draft document available: ... ) In-Reply-To: <43142D3D-7D06-4D3D-A47D-6AD6B6EEC111@nordu.net> References: <8DD85FED-FF25-4441-B8E7-05EA89A37E4F@marcoh.net> <4CA992FC.6020607@go6.si> <4CAD87B8.2050005@go6.si> <8F61AD98-F55D-4DF3-9264-970ED564B107@bondis.org> <4CAED238.3000403@go6.si> <8E29CE63-5470-4CCA-83D5-6C13940805BA@bondis.org> <43142D3D-7D06-4D3D-A47D-6AD6B6EEC111@nordu.net> Message-ID: Fredrik Pettai wrote on 16.11.2010 16:02:09: > For the home user that's fine, but maybe not for a enterprise network. ack. > It's not just about provisioning DNS/resolver configuration to clients. > It's about access control, e.g. to be able to centrally manage which > client that are connected/assigned an IP. DHCP is IMHO not the right way to implement access control. What is your security credential in this solution? I understand what you mean, but i think this is not a primary requirement for dhcp. In my view the use of dhcp for access control in your example is only a workaround and can`t be the solution for security. > Traceability e.g. which client > where connect a specific time etc. to name a few of the common things you > do with a centralized DHCP(v4) solution today. Please understand me right, i think we must have a look from the requirements side. IMHO we must consider the IPv4 solutions for IPv6 and perhaps can`t use it 1to1 in the IPv6-world. Regards Michael From pettai at nordu.net Wed Nov 17 00:01:35 2010 From: pettai at nordu.net (Fredrik Pettai) Date: Wed, 17 Nov 2010 00:01:35 +0100 Subject: Lack of DHCPv6 (was: Re: [ipv6-wg] New draft document available: ... ) In-Reply-To: References: <8DD85FED-FF25-4441-B8E7-05EA89A37E4F@marcoh.net> <4CA992FC.6020607@go6.si> <4CAD87B8.2050005@go6.si> <8F61AD98-F55D-4DF3-9264-970ED564B107@bondis.org> <4CAED238.3000403@go6.si> <8E29CE63-5470-4CCA-83D5-6C13940805BA@bondis.org> <43142D3D-7D06-4D3D-A47D-6AD6B6EEC111@nordu.net> Message-ID: <4F052743-FFA4-44E1-921F-87AC02100CB2@nordu.net> On Nov 16, 2010, at 6:13 PM, Michael Schneider/calispera.com wrote: > Fredrik Pettai wrote on 16.11.2010 16:02:09: >> For the home user that's fine, but maybe not for a enterprise network. > ack. > >> It's not just about provisioning DNS/resolver configuration to clients. >> It's about access control, e.g. to be able to centrally manage which >> client that are connected/assigned an IP. > DHCP is IMHO not the right way to implement access control. What is your > security credential in this solution? Maybe I used the wrong wording here, maybe "inventory/provisioning system" is describing it better. Sorry. > I understand what you mean, but i think this is not a primary requirement > for dhcp. In my view the use of dhcp for access control in your example is > only a workaround and can`t be the solution for security. > >> Traceability e.g. which client >> where connect a specific time etc. to name a few of the common things > you >> do with a centralized DHCP(v4) solution today. > Please understand me right, i think we must have a look from the > requirements side. IMHO we must consider the IPv4 solutions for IPv6 and > perhaps can`t use it 1to1 in the IPv6-world. No, I can agree with that. But what other alternatives do we have today (even counting drafts)? /P From david.kessens at nsn.com Fri Nov 19 11:56:26 2010 From: david.kessens at nsn.com (David Kessens) Date: Fri, 19 Nov 2010 02:56:26 -0800 Subject: [ipv6-wg] Last Call (20101123) on changes: Requirements For IPv6 in ICT Equipment In-Reply-To: <20101107091709.GG2401@nsn.com> References: <20101107091709.GG2401@nsn.com> Message-ID: <20101119105626.GB16329@nsn.com> Working Group, The Last Call on "Requirements For IPv6 in ICT Equipment" draft was completed on 20101117. We received 5 statements of support (not counting one of the authors) on the mailing list and various verbal statements of support during the RIPE meeting. We feel that this is close enough to the 8 statements of support that we requested in order to move ahead with publication. In addition, there was also some discussion on the mailing list regarding a few editorial changes and some discussion regarding MPLS requirements. Jan has produced a new version of the document that reflects the discussion. The document is available on the RIPE website: http://www.ripe.net/ripe/draft-documents/ipv6-ict-requirements.html We would like to issue a brief Last Call to make sure that the changes accurately reflect the discussion on the mailing list. Please let us know by the end of November 23, 2010 if you don't agree with the changes. As the number of formal statements of support was a little at the low side we would also like to encourage you to state your support for the document if you haven't done so already. David, Marco & Shane Co-chairs of the IPv6 working group --- From ip at ioshints.info Fri Nov 19 14:59:19 2010 From: ip at ioshints.info (Ivan Pepelnjak) Date: Fri, 19 Nov 2010 14:59:19 +0100 Subject: [ipv6-wg] Last Call (20101123) on changes: Requirements For IPv6 in ICT Equipment In-Reply-To: <20101119105626.GB16329@nsn.com> References: <20101107091709.GG2401@nsn.com> <20101119105626.GB16329@nsn.com> Message-ID: <001401cb87f1$fad21090$f07631b0$@info> Editorial comment: the bullet ... "If 6PE is requested, the equipment must comply with "Connecting IPv6 Islands over IPv4 MPLS Using IPv6 Provider Edge Routers (6PE)? [RFC4798]" ... in the "router or layer-3 switch" section is rephrased somewhat more generically in the bullet ... "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]" ... in the same section. I would suggest we remove the first one. Ivan Pepelnjak www.ioshints.info/about > -----Original Message----- > From: ipv6-wg-admin at ripe.net [mailto:ipv6-wg-admin at ripe.net] On Behalf Of > David Kessens > Sent: Friday, November 19, 2010 11:56 AM > To: ipv6-wg at ripe.net > Subject: [ipv6-wg] Last Call (20101123) on changes: Requirements For IPv6 > in ICT Equipment > > > Working Group, > > The Last Call on "Requirements For IPv6 in ICT Equipment" draft was > completed on 20101117. > > We received 5 statements of support (not counting one of the authors) on > the > mailing list and various verbal statements of support during the RIPE > meeting. We feel that this is close enough to the 8 statements of support > that we requested in order to move ahead with publication. > > In addition, there was also some discussion on the mailing list regarding > a > few editorial changes and some discussion regarding MPLS requirements. > > Jan has produced a new version of the document that reflects the > discussion. > The document is available on the RIPE website: > > http://www.ripe.net/ripe/draft-documents/ipv6-ict-requirements.html > > We would like to issue a brief Last Call to make sure that the changes > accurately reflect the discussion on the mailing list. > > Please let us know by the end of November 23, 2010 if you don't agree with > the changes. As the number of formal statements of support was a little at > the low side we would also like to encourage you to state your support for > the document if you haven't done so already. > > David, Marco & Shane > Co-chairs of the IPv6 working group > --- From jan at go6.si Sat Nov 20 12:32:24 2010 From: jan at go6.si (Jan Zorz @ go6.si) Date: Sat, 20 Nov 2010 12:32:24 +0100 Subject: [ipv6-wg] Last Call (20101123) on changes: Requirements For IPv6 in ICT Equipment In-Reply-To: <001401cb87f1$fad21090$f07631b0$@info> References: <20101107091709.GG2401@nsn.com> <20101119105626.GB16329@nsn.com> <001401cb87f1$fad21090$f07631b0$@info> Message-ID: <4CE7B1C8.8060907@go6.si> On 19.11.2010 14:59, Ivan Pepelnjak wrote: > Editorial comment: the bullet ... > > "If 6PE is requested, the equipment must comply with "Connecting IPv6 Islands over IPv4 MPLS Using IPv6 Provider Edge Routers (6PE)? [RFC4798]" > > ... in the "router or layer-3 switch" section is rephrased somewhat more generically in the bullet ... > > "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]" > > ... in the same section. I would suggest we remove the first one. > > Ivan Pepelnjak > www.ioshints.info/about Pipi hi, thnx for comment. Chairs, can we include this as a minor editorial change in final document, if there are no other comments? I suggest we publish this document as v.1 and then start accumulating proposed ideas for v.2. Thnx to community again for all your expressed support, all the discussion and great RIPE61 meeting we had in Rome! ;) Best, Jan Zorz go6.si From marcoh at marcoh.net Sat Nov 20 17:28:25 2010 From: marcoh at marcoh.net (Marco Hogewoning) Date: Sat, 20 Nov 2010 17:28:25 +0100 Subject: [ipv6-wg] Last Call (20101123) on changes: Requirements For IPv6 in ICT Equipment In-Reply-To: <4CE7B1C8.8060907@go6.si> References: <20101107091709.GG2401@nsn.com> <20101119105626.GB16329@nsn.com> <001401cb87f1$fad21090$f07631b0$@info> <4CE7B1C8.8060907@go6.si> Message-ID: <491ED093-7C2D-4A0C-8234-6C2177EBA659@marcoh.net> On 20 nov 2010, at 12:32, Jan Zorz @ go6.si wrote: > On 19.11.2010 14:59, Ivan Pepelnjak wrote: >> Editorial comment: the bullet ... >> >> "If 6PE is requested, the equipment must comply with "Connecting IPv6 Islands over IPv4 MPLS Using IPv6 Provider Edge Routers (6PE)? [RFC4798]" >> >> ... in the "router or layer-3 switch" section is rephrased somewhat more generically in the bullet ... >> >> "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]" >> >> ... in the same section. I would suggest we remove the first one. >> >> Ivan Pepelnjak >> www.ioshints.info/about > > Pipi hi, thnx for comment. > > Chairs, can we include this as a minor editorial change in final document, if there are no other comments? > > I suggest we publish this document as v.1 and then start accumulating proposed ideas for v.2. [Puts on his chair hat, as David is on vacation] Thanks for commenting. Looking at the tekst you are right that there is some redundancy in the text, but it's not a conflict and it does not create ambiguity. The underlying message stays the same "If you need MPLS, you need RFC 4798". Procedural I would like to publish as is instead of going into another cycle of editing and last call. No doubt in this next cycle there will be something else and the story will continue forever. At the meeting last week I spoke to various people who really want this to become official and get the draft label removed from it, so they can refer to it in their procedures. If there is anybody who has objections to publish the text as it's currently is, please state this clearly. I suggest we collect the editorial comments and fix them in a future version. Ivan, are you ok with this ? MarcoH IPv6 WG co-chair From ip at ioshints.info Sat Nov 20 19:21:38 2010 From: ip at ioshints.info (Ivan Pepelnjak) Date: Sat, 20 Nov 2010 19:21:38 +0100 Subject: [ipv6-wg] Last Call (20101123) on changes: Requirements For IPv6 in ICT Equipment In-Reply-To: <491ED093-7C2D-4A0C-8234-6C2177EBA659@marcoh.net> References: <20101107091709.GG2401@nsn.com> <20101119105626.GB16329@nsn.com> <001401cb87f1$fad21090$f07631b0$@info> <4CE7B1C8.8060907@go6.si> <491ED093-7C2D-4A0C-8234-6C2177EBA659@marcoh.net> Message-ID: <00a401cb88df$c7072590$551570b0$@info> > Thanks for commenting. Looking at the tekst you are right that there is > some redundancy in the text, but it's not a conflict and it does not > create ambiguity. The underlying message stays the same "If you need MPLS, > you need RFC 4798". > > Procedural I would like to publish as is instead of going into another > cycle of editing and last call [...] > > [...] I suggest we collect the > editorial comments and fix them in a future version. > > Ivan, are you ok with this ? Absolutely (and I totally agree with & support your reasons). Although the two bullets overlap, they do not contradict each other and having them both is not harmful. Let's get this done. Ivan From mtinka at globaltransit.net Tue Nov 23 12:08:40 2010 From: mtinka at globaltransit.net (Mark Tinka) Date: Tue, 23 Nov 2010 19:08:40 +0800 Subject: [ipv6-wg] Last Call (20101117): Requirements For IPv6 in ICT Equipment In-Reply-To: <005a01cb80ae$7e9b4180$7bd1c480$@com> References: <005a01cb80ae$7e9b4180$7bd1c480$@com> Message-ID: <201011231908.45169.mtinka@globaltransit.net> On Wednesday, November 10, 2010 04:08:42 pm Ivan Pepelnjak wrote: > 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). Apologies for the late reply: I think it would be a good idea to recommend MT regardless of whether MPLS is in use or not. Some systems, by default, will enable IS-IS for both v4 and v6 when turned on, e.g., JUNOS. Others won't and require either v4 or v6 support to be enabled explicitly, e.g., IOS. I think recommending MT be supported in all implementations of IS-IS is useful, so that native/dual-stack deployments of v6 don't cause network outages due to lack of topology congruency during turn-up. Cheers, Mark. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 836 bytes Desc: This is a digitally signed message part. URL: From isacco.fontana at trentinonetwork.it Tue Nov 23 18:18:37 2010 From: isacco.fontana at trentinonetwork.it (Isacco Fontana) Date: Tue, 23 Nov 2010 18:18:37 +0100 Subject: [ipv6-wg] Last Call (20101117): Requirements For IPv6 in ICT Equipment In-Reply-To: <201011231908.45169.mtinka@globaltransit.net> References: <005a01cb80ae$7e9b4180$7bd1c480$@com> <201011231908.45169.mtinka@globaltransit.net> Message-ID: <4CEBF76D.7040705@trentinonetwork.it> Yes. I think Multitopology is needed with IPv6 and ISIS. Mark Tinka ha scritto: > On Wednesday, November 10, 2010 04:08:42 pm Ivan Pepelnjak > wrote: > > >> 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). >> > > Apologies for the late reply: > > I think it would be a good idea to recommend MT regardless > of whether MPLS is in use or not. > > Some systems, by default, will enable IS-IS for both v4 and > v6 when turned on, e.g., JUNOS. Others won't and require > either v4 or v6 support to be enabled explicitly, e.g., IOS. > > I think recommending MT be supported in all implementations > of IS-IS is useful, so that native/dual-stack deployments of > v6 don't cause network outages due to lack of topology > congruency during turn-up. > > Cheers, > > Mark. > -- Ing. Isacco Fontana Trentino Network s.r.l. A socio Unico Direzione Servizi Responsabile Area Ingegneria di Rete Via Gilli, 2 - 38100 TRENTO Tel (+39) 0461.020200 Fax (+39) 0461.020201 http://as12835.peeringdb.com/ -------------------------------------------------------------------------------------------------------------------------------- Cap. Soc. sottoscritto EUR 7.573.248,00 i.v. - REG. IMP. C.F. e P. IVA 01904880224 E-mail: sede at trentinonetwork.it Societ? soggetta a direzione e controllo da parte della Provincia Autonoma di Trento. C.F. e P. IVA 00337460224 -------------------------------------------------------------------------------------------------------------------------------- -------------- next part -------------- An HTML attachment was scrubbed... URL: From marcoh at marcoh.net Tue Nov 23 18:48:59 2010 From: marcoh at marcoh.net (=?utf-8?B?TWFyY28gSG9nZXdvbmluZw==?=) Date: Tue, 23 Nov 2010 18:48:59 +0100 Subject: [ipv6-wg] =?utf-8?B?UmU6IFtpcHY2LXdnXSBMYXN0IENhbGwgKDIwMTAxMTE3KTogUmVxdWlyZW1lbnRzIEZvciBJUHY2IGluIElDVCBFcXVpcG1lbnQ=?= Message-ID: <201011231748.oANHms2M090786@smtp-vbr5.xs4all.nl> 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" Date: Tue, Nov 23, 2010 18:18 Subject: [ipv6-wg] Last Call (20101117): Requirements For IPv6 in ICT Equipment To: Cc: , "Ivan Pepelnjak" -------------- next part -------------- An HTML attachment was scrubbed... URL: From mtinka at globaltransit.net Tue Nov 23 19:27:27 2010 From: mtinka at globaltransit.net (Mark Tinka) Date: Wed, 24 Nov 2010 02:27:27 +0800 Subject: [ipv6-wg] Last Call (20101117): Requirements For IPv6 in ICT Equipment In-Reply-To: <201011231748.oANHms2M090786@smtp-vbr5.xs4all.nl> References: <201011231748.oANHms2M090786@smtp-vbr5.xs4all.nl> Message-ID: <201011240227.31975.mtinka@globaltransit.net> On Wednesday, November 24, 2010 01:48:59 am Marco Hogewoning wrote: > 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. My bad - I joined the discussion quite late. These are just comments, and can be added to future versions text if accepted. I support the current text as it is and should proceed with publication. Cheers, Mark. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 836 bytes Desc: This is a digitally signed message part. URL: From marcoh at marcoh.net Wed Nov 24 06:56:45 2010 From: marcoh at marcoh.net (Marco Hogewoning) Date: Wed, 24 Nov 2010 06:56:45 +0100 Subject: [ipv6-wg] Last Call (20101123) ended In-Reply-To: <20101119105626.GB16329@nsn.com> References: <20101107091709.GG2401@nsn.com> <20101119105626.GB16329@nsn.com> Message-ID: <44D8405E-E384-4007-84F8-D372724A0297@marcoh.net> Working group, The Last Call on "Requirements For IPv6 in ICT Equipment" draft was completed on 20101123. We have received some small suggestions for future improvements, but no objections to publishing the text as it currently is. We asked the NCC to move forward and give this doucment official status by adding it to the document repository. This will happen in the coming days. Off list we received one comment about the document referring to RFC 4310 where it should say 4301, the authors confirmed this is indeed a typo and this will be corrected upon publication. Please not that when using this document as a reference it might get superseded by a newer version in the future, you might want to put a disclaimer next to the reference. Marco, David & Shane IPv6 working group co-chairs From marcoh at marcoh.net Wed Nov 24 20:48:45 2010 From: marcoh at marcoh.net (Marco Hogewoning) Date: Wed, 24 Nov 2010 20:48:45 +0100 Subject: [ipv6-wg] New document available: RIPE-501 Requirements For IPv6 in ICT Equipment Message-ID: <7055010C-9E18-40A1-929A-F4C116B923DE@marcoh.net> 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 From strohbach at denic.de Thu Nov 25 10:01:25 2010 From: strohbach at denic.de (Joachim Strohbach) Date: Thu, 25 Nov 2010 10:01:25 +0100 Subject: [ipv6-wg] AUTO: Nicht erreichbar bis 29.11.2010 / Out of Office until 29.11.2010 Message-ID: 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 at 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 at 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 at 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 at 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. From jan at go6.si Thu Nov 25 12:22:01 2010 From: jan at go6.si (Jan Zorz @ go6.si) Date: Thu, 25 Nov 2010 12:22:01 +0100 Subject: [ipv6-wg] New document available: RIPE-501 Requirements For IPv6 in ICT Equipment In-Reply-To: <7055010C-9E18-40A1-929A-F4C116B923DE@marcoh.net> References: <7055010C-9E18-40A1-929A-F4C116B923DE@marcoh.net> Message-ID: <4CEE46D9.1020307@go6.si> On 24.11.2010 20:48, Marco Hogewoning wrote: > Dear community, > > A new ripe document, RIPE-501, has been published "Requirements For IPv6 in ICT Equipment". @all, Thanks to everybody that helped with doc development, sent comments/suggestions and to chairs for recognizing the consensus in the community and publishing this document. I believe we will continue the work in January, we already have some good suggestions and ideas for v.2 of the doc (and also new co-author for future versions). Thnx again and cheers, Jan Zorz go6.si