From marcoh at marcoh.net Fri Oct 1 10:23:28 2010 From: marcoh at marcoh.net (Marco Hogewoning) Date: Fri, 1 Oct 2010 10:23:28 +0200 Subject: [ipv6-wg] New draft document available: Requirements For IPv6 in ICT Equipment Message-ID: <8DD85FED-FF25-4441-B8E7-05EA89A37E4F@marcoh.net> (apologies for any duplicate emails) Dear Colleagues, Jan Zorz and Sander Steffan have prepared a document to serve as a guide what the requirements should be when asking for IPv6 in a tender or contract. It is our intention to publish this document as a RIPE document BCP so people can use this as an external reference. The draft version of this document is available at http://www.ripe.net/ripe/draft-documents/ipv6-ict-requirements.html Your comments and feedback can be sent to the IPv6 working group mailing-list on ipv6-wg at ripe.net. Regards, Marco Hogewoning IPv6 WG co-chair From strohbach at denic.de Fri Oct 1 16:01:27 2010 From: strohbach at denic.de (Joachim Strohbach) Date: Fri, 1 Oct 2010 16:01:27 +0200 Subject: [ipv6-wg] AUTO: Nicht erreichbar bis 4.10.2010 / Out of Office until 4.10.2010 Message-ID: Ich bin bis 04.10.2010 abwesend. Danke f?r Ihre E-Mail-Nachricht. Ich bin bis 4. Oktober 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 4 October 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 "[ipv6-wg] New draft document available: Requirements For IPv6 in ICT Equipment" gesendet am 1.10.10 10:23:28. Diese ist die einzige Benachrichtigung, die Sie empfangen werden, w?hrend diese Person abwesend ist. From joao at bondis.org Fri Oct 1 18:18:20 2010 From: joao at bondis.org (=?iso-8859-1?Q?Jo=E3o_Damas?=) Date: Fri, 1 Oct 2010 18:18:20 +0200 Subject: [ipv6-wg] more on IPv6 CPEs Message-ID: <65FFEE1E-7416-4F02-A07F-DBF0051439DA@bondis.org> http://blog.comcast.com/2010/10/comcast-donates-additional-ipv6-open-source-software.html Posted by Richard Woundy, SVP, Software and Applications, in Broadband "Comcast has now released additional free open source software that may help facilitate the industry's and end users' transition to IPv6. We are releasing home gateway device (a.k.a. home router) software, which is available here as open source, developed in conjunction with Xavient Information Systems. While it is very important that home gateway devices to support native IPv6, devices may still need to handle situations where tunnel-based IPv6 transition technology would be used. Thus, this software release supports cases where either IPv6 is tunneled over IPv4 using 6RD, or IPv4 is tunneled over IPv6 using Dual-Stack Lite. More information is available on the Comcast IPv6 Information Center." From jan at go6.si Mon Oct 4 10:40:28 2010 From: jan at go6.si (Jan Zorz @ go6.si) Date: Mon, 04 Oct 2010 10:40:28 +0200 Subject: [ipv6-wg] New draft document available: Requirements For IPv6 in ICT Equipment In-Reply-To: <8DD85FED-FF25-4441-B8E7-05EA89A37E4F@marcoh.net> References: <8DD85FED-FF25-4441-B8E7-05EA89A37E4F@marcoh.net> Message-ID: <4CA992FC.6020607@go6.si> On 1.10.10 10:23, Marco Hogewoning wrote: > (apologies for any duplicate emails) > > Dear Colleagues, > > Jan Zorz and Sander Steffan have prepared a document to serve as a guide what > the requirements should be when asking for IPv6 in a tender or contract. It > is our intention to publish this document as a RIPE document BCP so people > can use this as an external reference. > > The draft version of this document is available at > http://www.ripe.net/ripe/draft-documents/ipv6-ict-requirements.html > > Your comments and feedback can be sent to the IPv6 working group mailing-list > on ipv6-wg at ripe.net. Hi @all. Can't believe we did it right first time :) Maybe nobody read it and nobody cares. Recommandation for "what to demand in terms of IPv6 when buying ICT equipment" is badly needed for further deployment of IPv6 in all sectors and communities, can somebody please read that and give us feedback - we need to publish a document that makes sense. Thank you all for your time and efforts, Jan Zorz go6.si From shane at time-travellers.org Mon Oct 4 12:33:39 2010 From: shane at time-travellers.org (Shane Kerr) Date: Mon, 04 Oct 2010 12:33:39 +0200 Subject: [ipv6-wg] US government IPv6 mandate Message-ID: <1286188419.4832.3761.camel@shane-asus-laptop> All, Old-ish news, but I only saw this just now: http://news.techworld.com/networking/3241574/obama-administration-issues-ipv6-directive/ I look forward to success stories of people trying to get US visas using IPv6. ;) -- Shane From president at ukraine.su Mon Oct 4 13:28:39 2010 From: president at ukraine.su (Max Tulyev) Date: Mon, 04 Oct 2010 14:28:39 +0300 Subject: [ipv6-wg] US government IPv6 mandate In-Reply-To: <1286188419.4832.3761.camel@shane-asus-laptop> References: <1286188419.4832.3761.camel@shane-asus-laptop> Message-ID: <4CA9BA67.7070604@ukraine.su> "to upgrade their public-facing Web sites and services by 30 September, 2012, to support IPv6," So, the first try will be on 2012. And the date X is the middle of 2011 ;) Shane Kerr ???????(??): > All, > > Old-ish news, but I only saw this just now: > > http://news.techworld.com/networking/3241574/obama-administration-issues-ipv6-directive/ > > I look forward to success stories of people trying to get US visas using > IPv6. ;) > > -- > Shane > -- WBR, Max Tulyev (MT6561-RIPE, 2:463/253 at FIDO) From mir at ripe.net Mon Oct 4 20:36:49 2010 From: mir at ripe.net (Mirjam Kuehne) Date: Mon, 04 Oct 2010 20:36:49 +0200 Subject: [ipv6-wg] New on RIPE Labs: Study on IPv6 Background Radiation Message-ID: <4CAA1EC1.8030709@ripe.net> [apologies for duplicates] Dear colleagues, Geoff Huston has done an interesting study on "Background Radiation in IPv6". The results are published on RIPE Labs: https://labs.ripe.net/Members/mirjam/background-radiation-in-ipv6 Kind Regards, Mirjam Kuehne RIPE NCC From jan at go6.si Thu Oct 7 10:41:28 2010 From: jan at go6.si (Jan Zorz @ go6.si) Date: Thu, 07 Oct 2010 10:41:28 +0200 Subject: [ipv6-wg] New draft document available: Requirements For IPv6 in ICT Equipment In-Reply-To: <4CA992FC.6020607@go6.si> References: <8DD85FED-FF25-4441-B8E7-05EA89A37E4F@marcoh.net> <4CA992FC.6020607@go6.si> Message-ID: <4CAD87B8.2050005@go6.si> >> Jan Zorz and Sander Steffan have prepared a document to serve as a guide what >> the requirements should be when asking for IPv6 in a tender or contract. It >> is our intention to publish this document as a RIPE document BCP so people >> can use this as an external reference. >> >> The draft version of this document is available at >> http://www.ripe.net/ripe/draft-documents/ipv6-ict-requirements.html >> >> Your comments and feedback can be sent to the IPv6 working group mailing-list >> on ipv6-wg at ripe.net. List, chairs... I received some feedback and comments offlist, I thought to share them with the list, maybe to encourage a bit the discussion. I'm leaving out names, as I presume if this people would like to be exposed they would send response to the list and not to me directly. You know who you are, so please come forward if you like :) First comment was: >> Maybe because people do not like the idea that they will not be able >> to buy/use OSX? >> >> >> Requirements for "host" equipment >> >> Mandatory support: >> >> DHCPv6 client [RFC3315] I agree. I use Mac OSX regularly as my primary OS and can't understand what went wrong at Apple still lacking the DHCPv6 client. Do we have any mechanism to remind them about this issue? > Yes I do like the document and it's clear and simple layout. Somebody likes the document :) > Hi Jan, I have been extremly busy for some days so i havn't have time > to respond or answer but the draft where looking good I think! Another one (a bit in hurry I presume). > Ok, since you're asking for it :-) Ok, let's discuss. > > Host: > - IKEv2 mandatory: why? > You are aware that IKEv2 systems won't play with IKEv1 systems and that > IKEv2 is not very popular at present, too? I suggest that one at least > should ask for ISAKMP too, this keeps all options open what will > be used. Not sure. We could move that to optional, but can't decide. Suggestions? > - ULA optional: I don't exactly see how a host could support IPv6 at all > and not do ULA. It's just Yet Another Prefix. Agree. Moving to mandatory. > > Enterprise switch: > - RA-guard: your enemy is not -unsolicited- RA, your enemy is > -unauthorized- RA. As in, the laptop your sales guy brought in > announcing itself as the gateway to the world, even if RA was solicited. AFAIK RA-guard prevents RA packets being sent from ports, that are "declared" as "hosts" ports and connected hosts not authorized to send RA as such. > entire section: > to snoop means "to listen secretly". You don't want to listen > to those packets, you want to block them, selectively. That is called > filtering. Half the section wants s/snoop/filter/ This was also Ole Troan's comment: "Would change snooping to inspection in some cases. Or use SAVI terminology" Looks like we need to change this somehow, but not sure where to use "snooping", where "inspection" and where "filter" > - optional IPv6 basic, SNMP > How do you plan to admin that switch in a v6-only network? walk by and > use a serial cable? Enterprise class equipment also really should do > SNMP We thought of putting in mandatory requirements stuff that is already imlemented, so we are not necessarily eliminating too much equipment and put some stuff in optional for vendors implementing optional requirements to get more points on tenders - encouraging them to deploy more optional requirements. When this gets implemented we can move that to mandatory. Do we have any info, what percentage of "enterprise/ISP" grade switches supports IPv6 for management/SNMP now, today? If we have a solid percentage, then I'm happy to move that requirement to mandatory section. > > Router: > - ULA optional doesn't make a lot of sense here either, except perhaps as > requiring the ability to set routes into the bitbucket. Agree. Moving to mandatory. > > Firewall (etc): > - an application firewall that speaks BGP? at all? usefully? > I've seen (D)DoS blackholing devices that speak BGP, otherwise that > part of routing is not really best run on firewalls. That's why it says "if requested". I agree that BGP is not best run on firewall, but some people practice that idea, mainly because of cutting-costs and for small-mid companies it might work out well ofr most of the time. > > Skill requirements: much as a certificate does not guarantee skill, its > absence doesn't guarantee the absence of skill either. Do you have any > IPv6 certificates that have any meaning? No. Not at all. That's why I took a declaration from one government tender and modified it to include also IPv6. This is self-regulation, if systems integrator is sure, that his staff is good-to-go for the job that needs to be done, they will sign that declaration. Rmember, it says "declares, under criminal and material responsibility". That's not a joke, if you sign that and have no competent people to do the job properly. Thank you all for your comments, hope that we can trigger a bit more discussion on that before Rome meeting. Jan Zorz go6.si From joao at bondis.org Thu Oct 7 11:11:17 2010 From: joao at bondis.org (=?iso-8859-1?Q?Jo=E3o_Damas?=) Date: Thu, 7 Oct 2010 11:11:17 +0200 Subject: [ipv6-wg] New draft document available: Requirements For IPv6 in ICT Equipment In-Reply-To: <4CAD87B8.2050005@go6.si> References: <8DD85FED-FF25-4441-B8E7-05EA89A37E4F@marcoh.net> <4CA992FC.6020607@go6.si> <4CAD87B8.2050005@go6.si> Message-ID: <8F61AD98-F55D-4DF3-9264-970ED564B107@bondis.org> On 7 Oct 2010, at 10:41, Jan Zorz @ go6.si wrote: > >> Mandatory support: > >> > >> DHCPv6 client [RFC3315] > > I agree. I use Mac OSX regularly as my primary OS and can't understand what went wrong at Apple still lacking the DHCPv6 client. Do we have any mechanism to remind them about this issue? > Apple is an organisation. It does not take decisions. People at Apple do. In this case, you need to talk to Stuart Cheshire. > > > - ULA optional: I don't exactly see how a host could support IPv6 at all > > and not do ULA. It's just Yet Another Prefix. > > Agree. Moving to mandatory. > +1 > > > > Enterprise switch: > > - RA-guard: your enemy is not -unsolicited- RA, your enemy is > > -unauthorized- RA. As in, the laptop your sales guy brought in > > announcing itself as the gateway to the world, even if RA was solicited. > > AFAIK RA-guard prevents RA packets being sent from ports, that are "declared" as "hosts" ports and connected hosts not authorized to send RA as such. > how is a host-based mechanism based on prevention of outgoing packets ever going to work? I mean, it can prevent accidents (perhaps, it is not a guarantee, look at usual list of ad-hoc Wifi SSIDs at any event) but it sure won't prevent intentional unauthorised RAs. Distinguishing authorised from non-authorised is of course no simple matter, probably needing pre-auth, which kind of takes the automation out of the equation. It's almost like the IPv6 designers didn't have access to real networks during protocol development (no DHCP initially, silly TLA/SLA crap...) > > > > > Firewall (etc): > > - an application firewall that speaks BGP? at all? usefully? > > I've seen (D)DoS blackholing devices that speak BGP, otherwise that > > part of routing is not really best run on firewalls. > > That's why it says "if requested". I agree that BGP is not best run on firewall, but some people practice that idea, mainly because of cutting-costs and for small-mid companies it might work out well ofr most of the time. > is this one v6 specific? Joao From gert at space.net Thu Oct 7 16:30:54 2010 From: gert at space.net (Gert Doering) Date: Thu, 7 Oct 2010 16:30:54 +0200 Subject: [ipv6-wg] New draft document available: Requirements For IPv6 in ICT Equipment In-Reply-To: <8F61AD98-F55D-4DF3-9264-970ED564B107@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> Message-ID: <20101007143054.GE32268@Space.Net> Hi, On Thu, Oct 07, 2010 at 11:11:17AM +0200, Jo?o Damas wrote: > > > Enterprise switch: > > > - RA-guard: your enemy is not -unsolicited- RA, your enemy is > > > -unauthorized- RA. As in, the laptop your sales guy brought in > > > announcing itself as the gateway to the world, even if RA was solicited. > > > > AFAIK RA-guard prevents RA packets being sent from ports, that are "declared" as "hosts" ports and connected hosts not authorized to send RA as such. > > > > how is a host-based mechanism based on prevention of outgoing > packets ever going to work? I mean, it can prevent accidents (perhaps, > it is not a guarantee, look at usual list of ad-hoc Wifi SSIDs at > any event) but it sure won't prevent intentional unauthorised RAs. RA-guard is not host-based but switch-based. You configure the switch "*this* is the port where the router lives" and RAs on all other ports are filtered. See draft-ietf-v6ops-ra-guard-*.txt Gert Doering -- 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 spz at serpens.de Thu Oct 7 23:16:06 2010 From: spz at serpens.de (S.P.Zeidler) Date: Thu, 7 Oct 2010 23:16:06 +0200 Subject: [ipv6-wg] New draft document available: Requirements For IPv6 in ICT Equipment In-Reply-To: <4CAD87B8.2050005@go6.si> References: <8DD85FED-FF25-4441-B8E7-05EA89A37E4F@marcoh.net> <4CA992FC.6020607@go6.si> <4CAD87B8.2050005@go6.si> Message-ID: <20101007211604.GD27830@serpens.de> Thus wrote Jan Zorz @ go6.si (jan at go6.si): > > Host: > > - IKEv2 mandatory: why? > > You are aware that IKEv2 systems won't play with IKEv1 systems and that > > IKEv2 is not very popular at present, too? I suggest that one at least > > should ask for ISAKMP too, this keeps all options open what will > > be used. > > Not sure. We could move that to optional, but can't decide. Suggestions? On second thought, require both IKEv2 (some of its features are rather useful) and ISAKMP; thus you're very likely to be able to talk to your counterpart. To clarify: > > Enterprise switch: > > - RA-guard: your enemy is not -unsolicited- RA, your enemy is > > -unauthorized- RA. As in, the laptop your sales guy brought in > > announcing itself as the gateway to the world, even if RA was solicited. > > AFAIK RA-guard prevents RA packets being sent from ports, that are > "declared" as "hosts" ports and connected hosts not authorized to > send RA as such. Now it is: - RA snooping must be used in the network to block unsolicited RA messages I think it should read: - RA filtering must be used in the network to block unauthorized RA messages i.e. I assume you are thinking of the right thing, but using the wrong words. > > entire section: > > to snoop means "to listen secretly". You don't want to listen > > to those packets, you want to block them, selectively. That is called > > filtering. Half the section wants s/snoop/filter/ > > This was also Ole Troan's comment: > > "Would change snooping to inspection in some cases. Or use SAVI terminology" > > Looks like we need to change this somehow, but not sure where to use > "snooping", where "inspection" and where "filter" enterprise/ISP grade switch, mandatory support: - DHCPv6 filtering (port based suppression of origination of DHCPv6 messages is ok) - Router Advertisement (RA) snooping - RA filtering to block unauthorized RA messages (port based RA origination supression ok) - Dynamic "IPv6 neighbour solicitation/advertisement" inspection (note the typo, it's RFC2461 not RFC24611) - IPv6 neighbour solicitation/advertisement filtering similar to "Dynamic ARP inspection". ... - Neighbour Unreachability Detection [NUD, RFC2461] snooping - NUD filtering - Duplicate Address Detection [DAD, RFC4429] snooping and filtering. It must be possible to restrict DAD message source addresses originating on a port. (note the typo, DUD -> DAD) optional support: [...] - IPv6 Routing Header [RFC2460, Next Header value 43] snooping - IPv6 Routing Header filtering (port based suppression ok) - UPNP filtering (I'm assuming this is Universal Plug & Play UPnP) 'customer ports' does not have sufficient meaning. In an enterprise none of your ports is populated by a customer. We need an expression for "neither router nor DHCP server nor trunk". Also, why would you specifically try to avoid UPnP to do something useful, but allow useless messages to pass? > > - optional IPv6 basic, SNMP > > How do you plan to admin that switch in a v6-only network? walk by and > > use a serial cable? Enterprise class equipment also really should do > > SNMP > > We thought of putting in mandatory requirements stuff that is > already imlemented, so we are not necessarily eliminating too much > equipment and put some stuff in optional for vendors implementing > optional requirements to get more points on tenders - encouraging > them to deploy more optional requirements. > > When this gets implemented we can move that to mandatory. You expect a switch to actually support filtering on RA and -not- be able to support logging in via IPv6?! All new switches on the small side I met recently supported adding v6 addresses for management if they supported v6 at all, but I haven't had a device that supported RA filtering in my fingers yet. [BGP on firewalls] > That's why it says "if requested". I agree that BGP is not best run > on firewall, but some people practice that idea, mainly because of > cutting-costs and for small-mid companies it might work out well ofr > most of the time. eeeewyuck. Well, it'll not be my funeral :-P > > Skill requirements: much as a certificate does not guarantee skill, its > > absence doesn't guarantee the absence of skill either. Do you have any > > IPv6 certificates that have any meaning? > > No. Not at all. That's why I took a declaration from one government > tender and modified it to include also IPv6. This is > self-regulation, if systems integrator is sure, that his staff is > good-to-go for the job that needs to be done, they will sign that > declaration. But if someone signs your text they sign that I have at least three staff that have CERTIFICATION by a vendor on general knowledge of the IPv6 protocol, IPv6 network planning and IPv6 security. It does not say "certification or knowledge". It says "they need to have a certificate". It also says that they need to know their stuff, but that is an AND, not an OR. > Rmember, it says "declares, under criminal and material > responsibility". That's not a joke, if you sign that and have no > competent people to do the job properly. But they also have to have a piece of paper. I.e. -you- would currently be disqualified, since you don't have certification on IPv6 if I read your no correctly. Being an expert is not enough if you keep that wording. regards, spz -- spz at serpens.de (S.P.Zeidler) From jan at go6.si Fri Oct 8 10:11:36 2010 From: jan at go6.si (Jan Zorz @ go6.si) Date: Fri, 08 Oct 2010 10:11:36 +0200 Subject: [ipv6-wg] New draft document available: Requirements For IPv6 in ICT Equipment In-Reply-To: <8F61AD98-F55D-4DF3-9264-970ED564B107@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> Message-ID: <4CAED238.3000403@go6.si> Joao hi, Thnx for comments. Please see my thoughts inline. On 7.10.10 11:11, Jo?o Damas 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? >> >>> - ULA optional: I don't exactly see how a host could support IPv6 at all >>> and not do ULA. It's just Yet Another Prefix. >> >> Agree. Moving to mandatory. >> > > +1 ack. >>> Enterprise switch: - RA-guard: your enemy is not -unsolicited- RA, your >>> enemy is -unauthorized- RA. As in, the laptop your sales guy brought in >>> announcing itself as the gateway to the world, even if RA was solicited. >> >> AFAIK RA-guard prevents RA packets being sent from ports, that are >> "declared" as "hosts" ports and connected hosts not authorized to send RA >> as such. >> > > how is a host-based mechanism based on prevention of outgoing packets ever > going to work? I mean, it can prevent accidents (perhaps, it is not a > guarantee, look at usual list of ad-hoc Wifi SSIDs at any event) but it sure > won't prevent intentional unauthorised RAs. Distinguishing authorised from > non-authorised is of course no simple matter, probably needing pre-auth, > which kind of takes the automation out of the equation. It's almost like the > IPv6 designers didn't have access to real networks during protocol > development (no DHCP initially, silly TLA/SLA crap...) This is meant to work on switch ports level. You declare "router" port and let RA packets go through only on that physical port, "snooping" for RA pachets in the switch and blocking RA packets on all ather ports... >>> Firewall (etc): - an application firewall that speaks BGP? at all? >>> usefully? I've seen (D)DoS blackholing devices that speak BGP, otherwise >>> that part of routing is not really best run on firewalls. >> >> That's why it says "if requested". I agree that BGP is not best run on >> firewall, but some people practice that idea, mainly because of >> cutting-costs and for small-mid companies it might work out well ofr most >> of the time. >> > > is this one v6 specific? No. Same story on v4. Thnx, /jan From jan at go6.si Fri Oct 8 10:12:17 2010 From: jan at go6.si (Jan Zorz @ go6.si) Date: Fri, 08 Oct 2010 10:12:17 +0200 Subject: [ipv6-wg] New draft document available: Requirements For IPv6 in ICT Equipment In-Reply-To: <20101007143054.GE32268@Space.Net> References: <8DD85FED-FF25-4441-B8E7-05EA89A37E4F@marcoh.net> <4CA992FC.6020607@go6.si> <4CAD87B8.2050005@go6.si> <8F61AD98-F55D-4DF3-9264-970ED564B107@bondis.org> <20101007143054.GE32268@Space.Net> Message-ID: <4CAED261.4080901@go6.si> On 7.10.10 16:30, Gert Doering wrote: >> how is a host-based mechanism based on prevention of outgoing >> packets ever going to work? I mean, it can prevent accidents (perhaps, >> it is not a guarantee, look at usual list of ad-hoc Wifi SSIDs at >> any event) but it sure won't prevent intentional unauthorised RAs. > > RA-guard is not host-based but switch-based. You configure the switch > "*this* is the port where the router lives" and RAs on all other ports > are filtered. > > See draft-ietf-v6ops-ra-guard-*.txt > > Gert Doering Exacty :) +1 /jan From joao at bondis.org Fri Oct 8 10:41:32 2010 From: joao at bondis.org (=?iso-8859-1?Q?Jo=E3o_Damas?=) Date: Fri, 8 Oct 2010 10:41:32 +0200 Subject: [ipv6-wg] New draft document available: Requirements For IPv6 in ICT Equipment In-Reply-To: <4CAED238.3000403@go6.si> 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> Message-ID: <8E29CE63-5470-4CCA-83D5-6C13940805BA@bondis.org> On 8 Oct 2010, at 10:11, Jan Zorz @ go6.si wrote: > Joao hi, > > Thnx for comments. Please see my thoughts inline. > > On 7.10.10 11:11, Jo?o Damas 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. > > This is meant to work on switch ports level. You declare "router" port and let RA packets go through only on that physical port, "snooping" for RA pachets in the switch and blocking RA packets on all ather ports... > yep, I was tricked by the wording in the original text. Perhaps that is the part that need a bit of work? Joao From jan at go6.si Fri Oct 8 10:54:13 2010 From: jan at go6.si (Jan Zorz @ go6.si) Date: Fri, 08 Oct 2010 10:54:13 +0200 Subject: [ipv6-wg] New draft document available: Requirements For IPv6 in ICT Equipment In-Reply-To: <20101007211604.GD27830@serpens.de> References: <8DD85FED-FF25-4441-B8E7-05EA89A37E4F@marcoh.net> <4CA992FC.6020607@go6.si> <4CAD87B8.2050005@go6.si> <20101007211604.GD27830@serpens.de> Message-ID: <4CAEDC35.2010705@go6.si> Petra, hi Thnx for comments, please see my thoughts inline :) On 7.10.10 23:16, S.P.Zeidler wrote: > Thus wrote Jan Zorz @ go6.si (jan at go6.si): > >>> Host: >>> - IKEv2 mandatory: why? >>> You are aware that IKEv2 systems won't play with IKEv1 systems and that >>> IKEv2 is not very popular at present, too? I suggest that one at least >>> should ask for ISAKMP too, this keeps all options open what will >>> be used. >> >> Not sure. We could move that to optional, but can't decide. Suggestions? > > On second thought, require both IKEv2 (some of its features are rather > useful) and ISAKMP; thus you're very likely to be able to talk to your > counterpart. OK. So where IKEv2 is required I add ISAKMP. Which RFCs you suggest to reference? @list: do we agree on that? > > To clarify: > >>> Enterprise switch: >>> - RA-guard: your enemy is not -unsolicited- RA, your enemy is >>> -unauthorized- RA. As in, the laptop your sales guy brought in >>> announcing itself as the gateway to the world, even if RA was solicited. >> >> AFAIK RA-guard prevents RA packets being sent from ports, that are >> "declared" as "hosts" ports and connected hosts not authorized to >> send RA as such. > > Now it is: > - RA snooping must be used in the network to block unsolicited RA messages > I think it should read: > - RA filtering must be used in the network to block unauthorized RA messages > > i.e. I assume you are thinking of the right thing, but using the wrong > words. Ok, changing "unsolicited" to "unauthorized" > enterprise/ISP grade switch, mandatory support: > - DHCPv6 filtering (port based suppression of origination of DHCPv6 > messages is ok) > - Router Advertisement (RA) snooping > - RA filtering to block unauthorized RA messages (port based RA > origination supression ok) > - Dynamic "IPv6 neighbour solicitation/advertisement" inspection > (note the typo, it's RFC2461 not RFC24611) > - IPv6 neighbour solicitation/advertisement filtering similar to > "Dynamic ARP inspection". ... > - Neighbour Unreachability Detection [NUD, RFC2461] snooping > - NUD filtering > - Duplicate Address Detection [DAD, RFC4429] snooping and filtering. > It must be possible to restrict DAD message source addresses originating > on a port. (note the typo, DUD -> DAD) > > optional support: > [...] > - IPv6 Routing Header [RFC2460, Next Header value 43] snooping > - IPv6 Routing Header filtering (port based suppression ok) > - UPNP filtering (I'm assuming this is Universal Plug& Play UPnP) > > 'customer ports' does not have sufficient meaning. In an enterprise none > of your ports is populated by a customer. We need an expression for > "neither router nor DHCP server nor trunk". Well, I would remove word "customer". Just "ports". > Also, why would you specifically try to avoid UPnP to do something > useful, but allow useless messages to pass? This part is suggested by Torbjorn, he's on the list. I suggest we change "must" to "should". Changed L2 enterprise grade list: Mandatory support: - MLDv2 snooping [RFC4541] - DHCPv6 filtering [RFC3315] DHCPv6 messages must be blocked between subscribers and the network so no false DHCPv6 servers can distribute addresses - Router Advertisement (RA) filtering [RFC2462, RFC5006] RA filtering must be used in the network to block unauthorized RA messages - Dynamic "IPv6 neighbour solicitation/advertisement" inspection [RFC2461] There must be an IPv6 neighbour solicitation/advertisement inspection as in IPv4 ?Dynamic ARP inspection?. The table with MAC-address and link-local and other assigned IPv6-addresses must be dynamically created by SLAAC or DHCPv6 messages. - Neighbour Unreachability Detection [NUD, RFC2461] filtering There must be a NUD filtering function so false NUD messages cannot be sent. - Duplicate Address Detection [DAD, RFC4429] snooping and filtering. Only allowed addresses must be allowed as source IPv6-addresses in DAD messages from each port. Optional support (management) - IPv6 Basic specification [RFC2460] - IPv6 Addressing Architecture basic [RFC4291] - Default Address Selection [RFC3484(bis)] - ICMPv6 [RFC4443] - SLAAC [RFC4862] - SNMP protocol [RFC3411] - SNMP capabilities [RFC3412, RFC3413, RFC3414] - IPv6 Routing Header [RFC2460, Next Header value 43] filtering IPv6 Routing Header messages must not be allowed between subscriber ports and subscriber and uplink to prevent routing loops [See also RFC5095, Deprecation of Type 0 Routing Headers in IPv6] -UPNP filtering UPNP messages must always be blocked between customer ports. There may be a possibility to filter different Ether types to allow only 0x86dd between subscriber ports. And most probably you must also permit 0?800 and 0?806 for IPv4. > >>> - optional IPv6 basic, SNMP >>> How do you plan to admin that switch in a v6-only network? walk by and >>> use a serial cable? Enterprise class equipment also really should do >>> SNMP >> >> We thought of putting in mandatory requirements stuff that is >> already imlemented, so we are not necessarily eliminating too much >> equipment and put some stuff in optional for vendors implementing >> optional requirements to get more points on tenders - encouraging >> them to deploy more optional requirements. >> >> When this gets implemented we can move that to mandatory. > > You expect a switch to actually support filtering on RA and -not- be able > to support logging in via IPv6?! All new switches on the small side I met > recently supported adding v6 addresses for management if they supported > v6 at all, but I haven't had a device that supported RA filtering in my > fingers yet. Ok. Since this comment came up many times, I'm moving IPv6 on management to mandatory section. > > [BGP on firewalls] >> That's why it says "if requested". I agree that BGP is not best run >> on firewall, but some people practice that idea, mainly because of >> cutting-costs and for small-mid companies it might work out well ofr >> most of the time. > > eeeewyuck. Well, it'll not be my funeral :-P Well, this "if requested" moves the decision on customer side. I presume discussion on BGP-and-firewall-on-same-box is not the case in this document, but I suggest we make one and say "don't do that". > >>> Skill requirements: much as a certificate does not guarantee skill, its >>> absence doesn't guarantee the absence of skill either. Do you have any >>> IPv6 certificates that have any meaning? >> >> No. Not at all. That's why I took a declaration from one government >> tender and modified it to include also IPv6. This is >> self-regulation, if systems integrator is sure, that his staff is >> good-to-go for the job that needs to be done, they will sign that >> declaration. > > But if someone signs your text they sign that I have at least three > staff that have CERTIFICATION by a vendor on general knowledge of > the IPv6 protocol, IPv6 network planning and IPv6 security. > > It does not say "certification or knowledge". > > It says "they need to have a certificate". > > It also says that they need to know their stuff, but that is an AND, > not an OR. Good point. You suggest "certification or knowledge". How can we measure "knowledge"? We need to describe that, if we use above wording. Do we want to include "years of experience"? Cert, knowledge and experience are sometimes very different animals. > >> Rmember, it says "declares, under criminal and material >> responsibility". That's not a joke, if you sign that and have no >> competent people to do the job properly. > > But they also have to have a piece of paper. I.e. -you- would currently be > disqualified, since you don't have certification on IPv6 if I read your no > correctly. Being an expert is not enough if you keep that wording. Agree. /jan From jan at go6.si Tue Oct 12 22:04:59 2010 From: jan at go6.si (Jan Zorz @ go6.si) Date: Tue, 12 Oct 2010 22:04:59 +0200 Subject: [ipv6-wg] New draft document available: Requirements For IPv6 in ICT Equipment In-Reply-To: <20101012185936.GE6745@serpens.de> References: <8DD85FED-FF25-4441-B8E7-05EA89A37E4F@marcoh.net> <4CA992FC.6020607@go6.si> <4CAD87B8.2050005@go6.si> <20101007211604.GD27830@serpens.de> <4CAEDC35.2010705@go6.si> <20101012185936.GE6745@serpens.de> Message-ID: <4CB4BF6B.5040204@go6.si> On 12.10.10 20:59, S.P.Zeidler wrote: > Hi Jan, > > Thus wrote Jan Zorz @ go6.si (jan at go6.si): > >> OK. So where IKEv2 is required I add ISAKMP. Which RFCs you suggest to reference? > > RFC2407, RFC2408, RFC2409 (Internet DOI, ISAKMP, IKEv1) > > [...] Hi, Thank you very much for your comments, appreciated... I think we are somehow heading in a sensible direction... Added ISAKMP to the list. - ISAKMP [RFC2407, RFC2408, RFC2409] > --- snip --- > Vendors and reseller that offer system integration services must have at > least three employees who have valid certificates of competency from the > equipment manufacturers for the equipment that is sold as part of the > tender. These employees additionally must have general knowledge of > the IPv6 protocol, IPv6 network planning and IPv6 security (as eg > indicated by certification for these skills also). If it becomes obvious > during ... > --- snip --- Agree. I like this wording. I propose to generate new version of the draft, so please @everybody - if you have any thoughts or suggestions - tell them now, before Chris generates new version on the RIPE-NCC document store. Thnx, /jan From spz at serpens.de Tue Oct 12 20:59:37 2010 From: spz at serpens.de (S.P.Zeidler) Date: Tue, 12 Oct 2010 20:59:37 +0200 Subject: [ipv6-wg] New draft document available: Requirements For IPv6 in ICT Equipment In-Reply-To: <4CAEDC35.2010705@go6.si> References: <8DD85FED-FF25-4441-B8E7-05EA89A37E4F@marcoh.net> <4CA992FC.6020607@go6.si> <4CAD87B8.2050005@go6.si> <20101007211604.GD27830@serpens.de> <4CAEDC35.2010705@go6.si> Message-ID: <20101012185936.GE6745@serpens.de> Hi Jan, Thus wrote Jan Zorz @ go6.si (jan at go6.si): > OK. So where IKEv2 is required I add ISAKMP. Which RFCs you suggest to reference? RFC2407, RFC2408, RFC2409 (Internet DOI, ISAKMP, IKEv1) [...] > Good point. You suggest "certification or knowledge". How can we > measure "knowledge"? We need to describe that, if we use above > wording. Do we want to include "years of experience"? In fact I'd ask for 'knowledge' (because that's what matters if the contract is supposed to get served well). A certification without knowledge exists, but doesn't help the customer a lot. But with good certification (it exists! :), you get a cue that the skills are likely to be there: --- snip --- Vendors and reseller that offer system integration services must have at least three employees who have valid certificates of competency from the equipment manufacturers for the equipment that is sold as part of the tender. These employees additionally must have general knowledge of the IPv6 protocol, IPv6 network planning and IPv6 security (as eg indicated by certification for these skills also). If it becomes obvious during ... --- snip --- First sentence stays the same, second asks for knowledge of IPv6 and uses certification as a possible hint that the skillset is there. If it shouldn't be, with or without certificates, the tender initiator can boot the system integrator. regards, spz -- spz at serpens.de (S.P.Zeidler) From jan at go6.si Mon Oct 18 21:45:44 2010 From: jan at go6.si (Jan Zorz @ go6.si) Date: Mon, 18 Oct 2010 21:45:44 +0200 Subject: [ipv6-wg] New draft document available: Requirements For IPv6 in ICT Equipment In-Reply-To: <4CB4BF6B.5040204@go6.si> References: <8DD85FED-FF25-4441-B8E7-05EA89A37E4F@marcoh.net> <4CA992FC.6020607@go6.si> <4CAD87B8.2050005@go6.si> <20101007211604.GD27830@serpens.de> <4CAEDC35.2010705@go6.si> <20101012185936.GE6745@serpens.de> <4CB4BF6B.5040204@go6.si> Message-ID: <4CBCA3E8.6000104@go6.si> Dear list, chairs... There is new version of the draft "Requirements For IPv6 in ICT Equipment" in RIPE Document Store: http://www.ripe.net/ripe/draft-documents/ipv6-ict-requirements.html This version reflects comments and changes proposed in discussion here, please see if this version fits more in where we want to go with the document and possibly publish it as BCP. Thank you, Jan Zorz P.S: See you all in Rome, can't wait :) From mohacsi at niif.hu Tue Oct 19 11:37:31 2010 From: mohacsi at niif.hu (Mohacsi Janos) Date: Tue, 19 Oct 2010 11:37:31 +0200 (CEST) Subject: [ipv6-wg] more on IPv6 CPEs In-Reply-To: <65FFEE1E-7416-4F02-A07F-DBF0051439DA@bondis.org> References: <65FFEE1E-7416-4F02-A07F-DBF0051439DA@bondis.org> Message-ID: Dear All, The source code is only available only svn from sourceforge. The patch would be nice too.... Janos Mohacsi Head of HBONE+ project Network Engineer, Deputy Director of Network Planning and Projects NIIF/HUNGARNET, HUNGARY Key 70EF9882: DEC2 C685 1ED4 C95A 145F 4300 6F64 7B00 70EF 9882 On Fri, 1 Oct 2010, Jo?o Damas wrote: > http://blog.comcast.com/2010/10/comcast-donates-additional-ipv6-open-source-software.html > Posted by Richard Woundy, SVP, Software and Applications, in Broadband > > "Comcast has now released additional free open source software that may > help facilitate the industry's and end users' transition to IPv6. We are > releasing home gateway device (a.k.a. home router) software, which is > available here as open source, developed in conjunction with Xavient > Information Systems. While it is very important that home gateway > devices to support native IPv6, devices may still need to handle > situations where tunnel-based IPv6 transition technology would be used. > Thus, this software release supports cases where either IPv6 is tunneled > over IPv4 using 6RD, or IPv4 is tunneled over IPv6 using Dual-Stack > Lite. More information is available on the Comcast IPv6 Information Center." > > From mir at ripe.net Wed Oct 20 10:53:31 2010 From: mir at ripe.net (Mirjam Kuehne) Date: Wed, 20 Oct 2010 10:53:31 +0200 Subject: [ipv6-wg] IPv6 Crawler and Matrix now on RIPE Labs Message-ID: <4CBEAE0B.8090101@ripe.net> Dear colleagues, The UK ISOC chapter together with the Nile University in Egypt have developed an IPv6 crawler and matrix. You can now find the description including a pointer to the tool and the maps showing the results on RIPE Labs: http://labs.ripe.net/Members/mirjam/ipv6-crawler-and-matrix Kind Regards, Mirjam Kuehne RIPE Labs