From jan at go6.si Mon Jan 2 11:00:53 2012 From: jan at go6.si (Jan Zorz @ go6.si) Date: Mon, 02 Jan 2012 11:00:53 +0100 Subject: [ipv6-wg] Latest 6::gle phone Nexus supports IPv6 on 3G Message-ID: <4F018055.2080102@go6.si> All good in new year, the year of IPv6 :) In Go6Lab we tested new 6::gle phone with Android 4 and good news is, that it supports IPv6 PDP context over 3G. With Cameron from T-Mobile USA we are compiling list of apps, that are not working in IPv6-only environment, but for now we can live with it in everyday life :) The list will be published and compiled later. Short first report with snapshots: http://go6.si/en/2011/12/samsung-galaxy-nexus-nov-google-phone-podpira-tudi-ipv6-na-mobilnem-omreju/ Good news for start of new year. Cheers, Jan Zorz Go6 Institute Slovenia, CEO From evyncke at cisco.com Mon Jan 2 14:26:42 2012 From: evyncke at cisco.com (Eric Vyncke (evyncke)) Date: Mon, 2 Jan 2012 14:26:42 +0100 Subject: [ipv6-wg] RIPE-501 replacement document - IPsec question tocommunity - we need your input. In-Reply-To: References: <4EF43F92.4000403@go6.si> <82y5u3bqt7.fsf@mid.bfk.de><00568AC9-DA18-4243-B030-72843FD11A05@doubleshotsecurity.com><82y5ty1iku.fsf@mid.bfk.de> <4EF9A06F.40107@go6.si> <82d3ba192h.fsf@mid.bfk.de> <317616CE96204D49B5A1811098BA89500625B89F@XMB-AMS-110.cisco.com> <4DAD20CE-3948-44BF-9720-850482F18A62@icann.org> Message-ID: <317616CE96204D49B5A1811098BA89500625BA8D@XMB-AMS-110.cisco.com> Merike and others, When I wrote before Christmas 'AH for OSPFv3', I actually wanted to say 'IPsec authentication for OSPFv3'. After reading RFC 4552, it is obvious that 'ESP-null in transport mode is mandatory for routers supporting OSPFv3' Sorry for the confusion And I wish an IPv6-enabled year 2012 to you and all your devices -?ric > -----Original Message----- > From: Merike Kaeo [mailto:merike at doubleshotsecurity.com] > Sent: vendredi 30 d?cembre 2011 19:33 > To: Leo Vegoda > Cc: Eric Vyncke (evyncke); ipv6-wg at ripe.net; Jan Zorz @ go6.si; Florian > Weimer > Subject: Re: [ipv6-wg] RIPE-501 replacement document - IPsec question > tocommunity - we need your input. > > > On Dec 27, 2011, at 8:44 AM, Leo Vegoda wrote: > > > Hi, > > > > On Dec 27, 2011, at 8:08 am, Merike Kaeo wrote: > >> On Dec 27, 2011, at 7:43 AM, Eric Vyncke (evyncke) wrote: > >> > >>> I think that we should keep IPsec/IKEv2 only for firewall and mention to > any place where OSPFv3 is mentioned that the support of AH is required. > >> > >> Is there an RFC that now states that IPsec AH for OSPFv3 is a 'MUST' or > 'SHOULD' and not a 'MAY'? Last I recall the specifics for how to implement > IPsec for OSPFv3 are in RFC4552 and states that ESP is a 'MUST' and AH is a > 'MAY'. > > > > There is an unverified errata report that reverses those key words: > > > > http://www.rfc-editor.org/errata_search.php?rfc=4552 > > > > It'll be interesting to see if its status is ever changed to verified. > > There are no details in the errata that are useful. I find it amusing that > yesterday there started a discussion in the IETF IPsec wg about writing a > draft to move AH to historic. 3 years ago I had started writing a doc to > enumerate why ESP-Null is good enough and detailed the fields that were > getting protected using AH and why even with OSPFv3 there wasn't a clear > advantage. There are nuances with SPD that you implicitly get protection of > the SRC and DST IP addresses. > > I think I need to finish that paper as it's 90% done. I'll send out to a > few folks early next week.....something I was doing in some spare time a few > years ago. > > Note also that this argument has come up a few times since eventhough you > can use ESP for only integrity protection it has been difficult for vendors > to make a quick distinction whether an ESP packet is integrity only or also > encrypted. So, some vendors prefer to use AH since in some ways it is > 'simpler' and doesn't affect their performance. > > AH is the least tested protocol in any interoperability test. I have > attended a few and if that has changed, OK. Not from my experience. > > - merike > > > > > > Regards, > > > > Leo > > From evyncke at cisco.com Mon Jan 2 15:08:49 2012 From: evyncke at cisco.com (Eric Vyncke (evyncke)) Date: Mon, 2 Jan 2012 15:08:49 +0100 Subject: [ipv6-wg] RIPE-501 replacement document - IPsec question to community - we need your input. In-Reply-To: <4EFAE4BA.2060505@pragma.si> References: <4EF43F92.4000403@go6.si> <82y5u3bqt7.fsf@mid.bfk.de><00568AC9-DA18-4243-B030-72843FD11A05@doubleshotsecurity.com><82y5ty1iku.fsf@mid.bfk.de> <4EF9A06F.40107@go6.si><82d3ba192h.fsf@mid.bfk.de> <20111227191149.GO27877@serpens.de><47BEAF0E-D6CC-44E8-822A-4DF7B947085F@steffann.nl> <4EFAE4BA.2060505@pragma.si> Message-ID: <317616CE96204D49B5A1811098BA89500625BA9B@XMB-AMS-110.cisco.com> Here is my voice: remove IPsec mandatory to all devices EXCEPT for router supporting OSPFv3 (ESP-null in transport mode being mandatory) and for firewall (where IKEv3 and IPsecv3 are mandatory) -?ric > -----Original Message----- > From: ipv6-wg-bounces at ripe.net [mailto:ipv6-wg-bounces at ripe.net] On Behalf > Of Jan Zorz > Sent: mercredi 28 d?cembre 2011 10:43 > To: ipv6-wg at ripe.net > Subject: Re: [ipv6-wg] RIPE-501 replacement document - IPsec question to > community - we need your input. > > On 12/27/11 11:36 PM, Sander Steffann wrote: > > I agree. We are writing a template for tender initiators for > > enterprises. I think we should state that IPSec is mandatory, because > > enterprises should have the possibility to set up IPSec site-to-site > > tunnels as a minimum. I think we should write it in such a way that > > enterprises require IPSec support when writing a request for tender, > > unless they consciously decide that they don't need it. So I think we > > should put IPSec in the 'required' section. If an enterprise knows it > > will not need it then they can move it to 'optional' themselves. > > RIPE-501 and its successor are templates to be used and adapted as > > necessary. We should provide a sane default, and they might (will > > probably?) need IPSec at some point in time. > > Hi, > > I somehow agree... > > Disclaimer: RIPE community explicitly expressed the "wish" not to write > anything radical into RIPE-501 bis/replacement document - I think Joao > did that also publicly at Amsterdam meeting, and we received this > suggestion a lot on and off-line. > > Being said that, we might disregard all "radical" suggestions, such as > "remove IPsec completely from the document" unless they are proven > non-radical and that community (majority) feels in that way. > > So, for that suggestion there is much more support needed from community > than we can see it now. Supporters for "remove IPsec requirements > completely", make yourself heard, otherwise be quiet for the rest of the > time :) (we need to get this document out of the door ASAP, many > governments (not joking) are waiting for replacement to take it as basis > for their national IPv6 profile ;) ) > > We received many strong suggestions also off-list to go with the flow > and follow IETF way - make it all optional for all devices (maybe with > this option we could leave it out for mobile devices). Supporters for > this option, make yourself heard, otherwise be quiet for the rest of the > time :) > > Security and IPv6 advocate mind tells us to leave IPSec (at least v2) > mandatory for all sections (not valid for mobile devices) and IPsec v3 > optional. This would make sense from many points of view, but I > (personally) cannot make up my mind if this is not too harsh > prerequisite for this moment. Again, supporters for this option, make > yourself heard, otherwise be quiet for the rest of the time :) > > Sanders proposal above adds additional section for all devices (minus > mobile), so we expand to "Mandatory", "Required" and "Optional". If I > may repeat myself, supporters for this option, make yourself heard, > otherwise be quiet for the rest of the time :) > > So, if WG chairs allow, I would propose a "show of hands" and see, how > we can proceed. (anyone who express clear support fo one of the options > gets a candy at RIPE64 meeting in Ljubljana :) :) :) ) > > > > > I am leaving for vacation now, so I'll eave it up to this WG to > > decide what to do with my input :-) Sander > > Sander, have a good time and rest a bit :) V6 work for this year is done :) > > Cheers, Jan Zorz > From merike at doubleshotsecurity.com Tue Jan 3 01:47:43 2012 From: merike at doubleshotsecurity.com (Merike Kaeo) Date: Mon, 2 Jan 2012 16:47:43 -0800 Subject: [ipv6-wg] RIPE-501 replacement document - IPsec question to community - we need your input. In-Reply-To: <317616CE96204D49B5A1811098BA89500625BA9B@XMB-AMS-110.cisco.com> References: <4EF43F92.4000403@go6.si> <82y5u3bqt7.fsf@mid.bfk.de><00568AC9-DA18-4243-B030-72843FD11A05@doubleshotsecurity.com><82y5ty1iku.fsf@mid.bfk.de> <4EF9A06F.40107@go6.si><82d3ba192h.fsf@mid.bfk.de> <20111227191149.GO27877@serpens.de><47BEAF0E-D6CC-44E8-822A-4DF7B947085F@steffann.nl> <4EFAE4BA.2060505@pragma.si> <317616CE96204D49B5A1811098BA89500625BA9B@XMB-AMS-110.cisco.com> Message-ID: Bottom posting will probably make this reply confusing so for now I'll just say that I tend to agree with my co-authors but we would like to hear more input from the RIPE community, especially the operators who are using IPsec in their IPv6 deployments (or plan to). six or seven voices seems like a small sampling. Our hope is the get the final document done and back to last call in next few weeks so replies by the end of this week would be very much appreciated. - merike On Jan 2, 2012, at 6:08 AM, Eric Vyncke (evyncke) wrote: > Here is my voice: remove IPsec mandatory to all devices EXCEPT for router supporting OSPFv3 (ESP-null in transport mode being mandatory) and for firewall (where IKEv3 and IPsecv3 are mandatory) > > -?ric > >> -----Original Message----- >> From: ipv6-wg-bounces at ripe.net [mailto:ipv6-wg-bounces at ripe.net] On Behalf >> Of Jan Zorz >> Sent: mercredi 28 d?cembre 2011 10:43 >> To: ipv6-wg at ripe.net >> Subject: Re: [ipv6-wg] RIPE-501 replacement document - IPsec question to >> community - we need your input. >> >> On 12/27/11 11:36 PM, Sander Steffann wrote: >>> I agree. We are writing a template for tender initiators for >>> enterprises. I think we should state that IPSec is mandatory, because >>> enterprises should have the possibility to set up IPSec site-to-site >>> tunnels as a minimum. I think we should write it in such a way that >>> enterprises require IPSec support when writing a request for tender, >>> unless they consciously decide that they don't need it. So I think we >>> should put IPSec in the 'required' section. If an enterprise knows it >>> will not need it then they can move it to 'optional' themselves. >>> RIPE-501 and its successor are templates to be used and adapted as >>> necessary. We should provide a sane default, and they might (will >>> probably?) need IPSec at some point in time. >> >> Hi, >> >> I somehow agree... >> >> Disclaimer: RIPE community explicitly expressed the "wish" not to write >> anything radical into RIPE-501 bis/replacement document - I think Joao >> did that also publicly at Amsterdam meeting, and we received this >> suggestion a lot on and off-line. >> >> Being said that, we might disregard all "radical" suggestions, such as >> "remove IPsec completely from the document" unless they are proven >> non-radical and that community (majority) feels in that way. >> >> So, for that suggestion there is much more support needed from community >> than we can see it now. Supporters for "remove IPsec requirements >> completely", make yourself heard, otherwise be quiet for the rest of the >> time :) (we need to get this document out of the door ASAP, many >> governments (not joking) are waiting for replacement to take it as basis >> for their national IPv6 profile ;) ) >> >> We received many strong suggestions also off-list to go with the flow >> and follow IETF way - make it all optional for all devices (maybe with >> this option we could leave it out for mobile devices). Supporters for >> this option, make yourself heard, otherwise be quiet for the rest of the >> time :) >> >> Security and IPv6 advocate mind tells us to leave IPSec (at least v2) >> mandatory for all sections (not valid for mobile devices) and IPsec v3 >> optional. This would make sense from many points of view, but I >> (personally) cannot make up my mind if this is not too harsh >> prerequisite for this moment. Again, supporters for this option, make >> yourself heard, otherwise be quiet for the rest of the time :) >> >> Sanders proposal above adds additional section for all devices (minus >> mobile), so we expand to "Mandatory", "Required" and "Optional". If I >> may repeat myself, supporters for this option, make yourself heard, >> otherwise be quiet for the rest of the time :) >> >> So, if WG chairs allow, I would propose a "show of hands" and see, how >> we can proceed. (anyone who express clear support fo one of the options >> gets a candy at RIPE64 meeting in Ljubljana :) :) :) ) >> >>> >>> I am leaving for vacation now, so I'll eave it up to this WG to >>> decide what to do with my input :-) Sander >> >> Sander, have a good time and rest a bit :) V6 work for this year is done :) >> >> Cheers, Jan Zorz >> > > > From evyncke at cisco.com Tue Jan 3 08:23:10 2012 From: evyncke at cisco.com (Eric Vyncke (evyncke)) Date: Tue, 3 Jan 2012 08:23:10 +0100 Subject: [ipv6-wg] RIPE-501 replacement document - IPsec question to community - we need your input. In-Reply-To: References: <4EF43F92.4000403@go6.si> <82y5u3bqt7.fsf@mid.bfk.de><00568AC9-DA18-4243-B030-72843FD11A05@doubleshotsecurity.com><82y5ty1iku.fsf@mid.bfk.de> <4EF9A06F.40107@go6.si><82d3ba192h.fsf@mid.bfk.de> <20111227191149.GO27877@serpens.de><47BEAF0E-D6CC-44E8-822A-4DF7B947085F@steffann.nl> <4EFAE4BA.2060505@pragma.si> <317616CE96204D49B5A1811098BA89500625BA9B@XMB-AMS-110.cisco.com> Message-ID: <317616CE96204D49B5A1811098BA89500625BB43@XMB-AMS-110.cisco.com> Merike, 5 or 6 voices is indeed a too small sampling to be taken into account (even if I was one of those voices). No argument. But, I am a little less comfortable with your sentence about 'operators who are using IPsec' because my understanding was that RIPE-501bis is for 'tender initiators' which are more likely to be enterprises, public sector organizations rather than operators. Else, thanks for the job on RIPE-501: very much needed but do not shoot for the stars -?ric > -----Original Message----- > From: Merike Kaeo [mailto:merike at doubleshotsecurity.com] > Sent: mardi 3 janvier 2012 01:48 > To: Eric Vyncke (evyncke) > Cc: Jan Zorz; ipv6-wg at ripe.net > Subject: Re: [ipv6-wg] RIPE-501 replacement document - IPsec question to > community - we need your input. > > Bottom posting will probably make this reply confusing so for now I'll just > say that I tend to agree with my co-authors but we would like to hear more > input from the RIPE community, especially the operators who are using IPsec > in their IPv6 deployments (or plan to). six or seven voices seems like a > small sampling. > > Our hope is the get the final document done and back to last call in next > few weeks so replies by the end of this week would be very much appreciated. > > - merike > > On Jan 2, 2012, at 6:08 AM, Eric Vyncke (evyncke) wrote: > > > Here is my voice: remove IPsec mandatory to all devices EXCEPT for router > supporting OSPFv3 (ESP-null in transport mode being mandatory) and for > firewall (where IKEv3 and IPsecv3 are mandatory) > > > > -?ric > > > >> -----Original Message----- > >> From: ipv6-wg-bounces at ripe.net [mailto:ipv6-wg-bounces at ripe.net] On > Behalf > >> Of Jan Zorz > >> Sent: mercredi 28 d?cembre 2011 10:43 > >> To: ipv6-wg at ripe.net > >> Subject: Re: [ipv6-wg] RIPE-501 replacement document - IPsec question to > >> community - we need your input. > >> > >> On 12/27/11 11:36 PM, Sander Steffann wrote: > >>> I agree. We are writing a template for tender initiators for > >>> enterprises. I think we should state that IPSec is mandatory, because > >>> enterprises should have the possibility to set up IPSec site-to-site > >>> tunnels as a minimum. I think we should write it in such a way that > >>> enterprises require IPSec support when writing a request for tender, > >>> unless they consciously decide that they don't need it. So I think we > >>> should put IPSec in the 'required' section. If an enterprise knows it > >>> will not need it then they can move it to 'optional' themselves. > >>> RIPE-501 and its successor are templates to be used and adapted as > >>> necessary. We should provide a sane default, and they might (will > >>> probably?) need IPSec at some point in time. > >> > >> Hi, > >> > >> I somehow agree... > >> > >> Disclaimer: RIPE community explicitly expressed the "wish" not to write > >> anything radical into RIPE-501 bis/replacement document - I think Joao > >> did that also publicly at Amsterdam meeting, and we received this > >> suggestion a lot on and off-line. > >> > >> Being said that, we might disregard all "radical" suggestions, such as > >> "remove IPsec completely from the document" unless they are proven > >> non-radical and that community (majority) feels in that way. > >> > >> So, for that suggestion there is much more support needed from community > >> than we can see it now. Supporters for "remove IPsec requirements > >> completely", make yourself heard, otherwise be quiet for the rest of the > >> time :) (we need to get this document out of the door ASAP, many > >> governments (not joking) are waiting for replacement to take it as basis > >> for their national IPv6 profile ;) ) > >> > >> We received many strong suggestions also off-list to go with the flow > >> and follow IETF way - make it all optional for all devices (maybe with > >> this option we could leave it out for mobile devices). Supporters for > >> this option, make yourself heard, otherwise be quiet for the rest of the > >> time :) > >> > >> Security and IPv6 advocate mind tells us to leave IPSec (at least v2) > >> mandatory for all sections (not valid for mobile devices) and IPsec v3 > >> optional. This would make sense from many points of view, but I > >> (personally) cannot make up my mind if this is not too harsh > >> prerequisite for this moment. Again, supporters for this option, make > >> yourself heard, otherwise be quiet for the rest of the time :) > >> > >> Sanders proposal above adds additional section for all devices (minus > >> mobile), so we expand to "Mandatory", "Required" and "Optional". If I > >> may repeat myself, supporters for this option, make yourself heard, > >> otherwise be quiet for the rest of the time :) > >> > >> So, if WG chairs allow, I would propose a "show of hands" and see, how > >> we can proceed. (anyone who express clear support fo one of the options > >> gets a candy at RIPE64 meeting in Ljubljana :) :) :) ) > >> > >>> > >>> I am leaving for vacation now, so I'll eave it up to this WG to > >>> decide what to do with my input :-) Sander > >> > >> Sander, have a good time and rest a bit :) V6 work for this year is done > :) > >> > >> Cheers, Jan Zorz > >> > > > > > > From merike at doubleshotsecurity.com Tue Jan 3 16:40:58 2012 From: merike at doubleshotsecurity.com (Merike Kaeo) Date: Tue, 3 Jan 2012 07:40:58 -0800 Subject: [ipv6-wg] RIPE-501 replacement document - IPsec question to community - we need your input. In-Reply-To: <317616CE96204D49B5A1811098BA89500625BB43@XMB-AMS-110.cisco.com> References: <4EF43F92.4000403@go6.si> <82y5u3bqt7.fsf@mid.bfk.de><00568AC9-DA18-4243-B030-72843FD11A05@doubleshotsecurity.com><82y5ty1iku.fsf@mid.bfk.de> <4EF9A06F.40107@go6.si><82d3ba192h.fsf@mid.bfk.de> <20111227191149.GO27877@serpens.de><47BEAF0E-D6CC-44E8-822A-4DF7B947085F@steffann.nl> <4EFAE4BA.2060505@pragma.si> <317616CE96204D49B5A1811098BA89500625BA9B@XMB-AMS-110.cisco.com> <317616CE96204D49B5A1811098BA89500625BB43@XMB-AMS-110.cisco.com> Message-ID: <14B67369-6D0C-4ADB-89BE-0D858C1D8DC5@doubleshotsecurity.com> Hello... On Jan 2, 2012, at 11:23 PM, Eric Vyncke (evyncke) wrote: > Merike, > > 5 or 6 voices is indeed a too small sampling to be taken into account (even if I was one of those voices). No argument. > > But, I am a little less comfortable with your sentence about 'operators who are using IPsec' because my understanding was that RIPE-501bis is for 'tender initiators' which are more likely to be enterprises, public sector organizations rather than operators. Bad choice of words on my part. We would just like more input if possible to make sure we reflect the community consensus. > Else, thanks for the job on RIPE-501: very much needed but do not shoot for the stars :) Yes, it does have to be based on reality. - merike > > -?ric > >> -----Original Message----- >> From: Merike Kaeo [mailto:merike at doubleshotsecurity.com] >> Sent: mardi 3 janvier 2012 01:48 >> To: Eric Vyncke (evyncke) >> Cc: Jan Zorz; ipv6-wg at ripe.net >> Subject: Re: [ipv6-wg] RIPE-501 replacement document - IPsec question to >> community - we need your input. >> >> Bottom posting will probably make this reply confusing so for now I'll just >> say that I tend to agree with my co-authors but we would like to hear more >> input from the RIPE community, especially the operators who are using IPsec >> in their IPv6 deployments (or plan to). six or seven voices seems like a >> small sampling. >> >> Our hope is the get the final document done and back to last call in next >> few weeks so replies by the end of this week would be very much appreciated. >> >> - merike >> >> On Jan 2, 2012, at 6:08 AM, Eric Vyncke (evyncke) wrote: >> >>> Here is my voice: remove IPsec mandatory to all devices EXCEPT for router >> supporting OSPFv3 (ESP-null in transport mode being mandatory) and for >> firewall (where IKEv3 and IPsecv3 are mandatory) >>> >>> -?ric >>> >>>> -----Original Message----- >>>> From: ipv6-wg-bounces at ripe.net [mailto:ipv6-wg-bounces at ripe.net] On >> Behalf >>>> Of Jan Zorz >>>> Sent: mercredi 28 d?cembre 2011 10:43 >>>> To: ipv6-wg at ripe.net >>>> Subject: Re: [ipv6-wg] RIPE-501 replacement document - IPsec question to >>>> community - we need your input. >>>> >>>> On 12/27/11 11:36 PM, Sander Steffann wrote: >>>>> I agree. We are writing a template for tender initiators for >>>>> enterprises. I think we should state that IPSec is mandatory, because >>>>> enterprises should have the possibility to set up IPSec site-to-site >>>>> tunnels as a minimum. I think we should write it in such a way that >>>>> enterprises require IPSec support when writing a request for tender, >>>>> unless they consciously decide that they don't need it. So I think we >>>>> should put IPSec in the 'required' section. If an enterprise knows it >>>>> will not need it then they can move it to 'optional' themselves. >>>>> RIPE-501 and its successor are templates to be used and adapted as >>>>> necessary. We should provide a sane default, and they might (will >>>>> probably?) need IPSec at some point in time. >>>> >>>> Hi, >>>> >>>> I somehow agree... >>>> >>>> Disclaimer: RIPE community explicitly expressed the "wish" not to write >>>> anything radical into RIPE-501 bis/replacement document - I think Joao >>>> did that also publicly at Amsterdam meeting, and we received this >>>> suggestion a lot on and off-line. >>>> >>>> Being said that, we might disregard all "radical" suggestions, such as >>>> "remove IPsec completely from the document" unless they are proven >>>> non-radical and that community (majority) feels in that way. >>>> >>>> So, for that suggestion there is much more support needed from community >>>> than we can see it now. Supporters for "remove IPsec requirements >>>> completely", make yourself heard, otherwise be quiet for the rest of the >>>> time :) (we need to get this document out of the door ASAP, many >>>> governments (not joking) are waiting for replacement to take it as basis >>>> for their national IPv6 profile ;) ) >>>> >>>> We received many strong suggestions also off-list to go with the flow >>>> and follow IETF way - make it all optional for all devices (maybe with >>>> this option we could leave it out for mobile devices). Supporters for >>>> this option, make yourself heard, otherwise be quiet for the rest of the >>>> time :) >>>> >>>> Security and IPv6 advocate mind tells us to leave IPSec (at least v2) >>>> mandatory for all sections (not valid for mobile devices) and IPsec v3 >>>> optional. This would make sense from many points of view, but I >>>> (personally) cannot make up my mind if this is not too harsh >>>> prerequisite for this moment. Again, supporters for this option, make >>>> yourself heard, otherwise be quiet for the rest of the time :) >>>> >>>> Sanders proposal above adds additional section for all devices (minus >>>> mobile), so we expand to "Mandatory", "Required" and "Optional". If I >>>> may repeat myself, supporters for this option, make yourself heard, >>>> otherwise be quiet for the rest of the time :) >>>> >>>> So, if WG chairs allow, I would propose a "show of hands" and see, how >>>> we can proceed. (anyone who express clear support fo one of the options >>>> gets a candy at RIPE64 meeting in Ljubljana :) :) :) ) >>>> >>>>> >>>>> I am leaving for vacation now, so I'll eave it up to this WG to >>>>> decide what to do with my input :-) Sander >>>> >>>> Sander, have a good time and rest a bit :) V6 work for this year is done >> :) >>>> >>>> Cheers, Jan Zorz >>>> >>> >>> >>> > > From jan at go6.si Thu Jan 12 09:16:03 2012 From: jan at go6.si (Jan Zorz @ go6.si) Date: Thu, 12 Jan 2012 09:16:03 +0100 Subject: [ipv6-wg] More IPv6 on mobile networks testing... Message-ID: <4F0E96C3.2030207@go6.si> Hi, I suspect some of you could find this interesting. Excuse to others for filling their mailboxes ;) http://go6.si/en/2012/01/nokia-usb-modem-21m02-ii/ Nokia USB "Internet stick" with PDPv4, PDPv6 and PDPv4v6 capability test. Cheers, Jan From sander at steffann.nl Thu Jan 12 12:36:27 2012 From: sander at steffann.nl (Sander Steffann) Date: Thu, 12 Jan 2012 12:36:27 +0100 Subject: [ipv6-wg] More IPv6 on mobile networks testing... In-Reply-To: <4F0E96C3.2030207@go6.si> References: <4F0E96C3.2030207@go6.si> Message-ID: <9F1122F6-215E-4484-913E-E21FA0D6E9BC@steffann.nl> Hi, > I suspect some of you could find this interesting. Excuse to others for filling their mailboxes ;) > > http://go6.si/en/2012/01/nokia-usb-modem-21m02-ii/ > > Nokia USB "Internet stick" with PDPv4, PDPv6 and PDPv4v6 capability test. Cool! I thought that they decided not to take this stick into production. Good to hear that it is available after all :-) Sander -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 2084 bytes Desc: not available URL: From marcoh at marcoh.net Fri Jan 13 11:56:57 2012 From: marcoh at marcoh.net (Marco Hogewoning) Date: Fri, 13 Jan 2012 11:56:57 +0100 Subject: [ipv6-wg] Draft minutes of RIPE63 Message-ID: <90C6B566-633B-4443-8CB2-0A777A49129D@marcoh.net> Dear colleagues, Attached are the draft minutes of our working group session in Vienna at the RIPE63 Meeting. Please review them and if you have any corrections or comments, please post them to this list before Friday the 27th of January COB. If we haven't received any comments or corrections by that date, we will assume consensus and will ask the RIPE NCC to publish these as final. Again many thanks to the RIPE NCC for their support in scribing the session. Marco Hogewoning RIPE 63 Scribe: Mirjam Kuehne WG chairs: David Kessens, Shane Kerr, Marco Hogewoning Date: 1 November 2011, 16:00 - 17:30 IPv6 WG meeting (first session) Marco Hogewoning opens the IPv6-WG 1. Administrivia: - Minutes of RIPE 61 have been circulated - There was no IPv6-WG session at RIPE 62 - Thanks to the RIPE NCC for taking minutes at RIPE 63 2. Renumbering IPv6 - IETF 6RENUM WG (Tim Chown, Wes George; presented by Shane Kerr) The Address Policy WG asked the IPv6-WG for some advice about renumbering. Trying to avoid renumbering could be a reason for organisations to request PI space. Renumbering is considered to be difficult. But if renumbering would be very easy, then this wouldn't be a good reason for PI space (there might be others however). The IETF 6RENUM WG is working on this topic. It was formed after a BoF at IETF 81. There was some previous work done on IPv6 renumbering (see RFC 4192, RFC 5887 and draft-chown-v6ops-renumber-thinkabout-05). The current work of the 6RENUM WG is focused on renumbering for enterprise networks, not ISP networks. But enterprises all get their Internet connectivity from somewhere - from ISPs. Many of them are in the RIPE community. Tim Chown is looking for feedback from this community. The first 6RENUM WG draft documents internal triggers to renumber. There is also a document providing a gap analysis. Q&A: James Blessing commented that IF you design your network properly in the first place, renumbering is fairly straightforward - it is still work, but it's straightforward. Marco was wondering if it would help if this group would come up with a BCP about network design. Shane thought this would be a good idea (people usually appreciate RIPE BCPs). Gert Doering (Spacenet and IPv6 user for many years) agreed with James: A large part of the pain can be avoided with a good network design. Don't hardcode IP addresses etc. A BCP document listing the dos and don'ts would be useful. On the other hand, we don't want to overlap with the IETF WG (would have to check that this is not part of their charter). Marco emphasised that the IETF 6RENUM WG is mostly focused on enterprise networks. He suggested that the RIPE IPv6-WG could fill the gap and provide some documentation for ISPs. Gert said he obviously thought about this also, because it is related to address policy. Gert said he spent some thought on that as well, because obviously touches on Address Policy. Like I if he?s a small ISP and not multi?homed yet but wants independent addresses and why not just renumber if you change upstream and? One of the really painful things about renumbering an ISP network is you have to renumber your customers and that works for end users that are fully automated provisioned, like prefix delegation and stuff so there is no boxes to be touched and the box auto configures everything on connection anyway but it doesn't work at all for business ISPs where you have many configured firewalls and everything, so renumbering an ISP with business customers is nearly impossible. Gert said he?s done it two times and that it's nearly impossible. So this might be the reason why they have excluded ISPs from this scope. On the other hand, some parts of the ISPs are just an enterprise network, like server housing, DNS servers, firewalls and stuff, so there is overlap again. Shane said there was a couple of different things going on, one being able to provide recommendations to people who are doing network design, maybe even in the case where you have customers perhaps recommending prefix delegation or whatever. But the other issue is the recommendations on the policy space, maybe clarifying in which cases PI space makes sense, for instance a small ISP with downstream customers or something like that. Gert said that better defining the problem space, would certainly help making appropriate policy. Documenting different use cases could be helpful. James commented that according to current policy, having PI IPv6 address space stops you from giving addresses to customers. Gert said that this is correct and that it's an artefact of the history of PI address space policy. This will be discussed more in the Address Policy WG. Maksym Tulyuk (AMS-IX) reported that at AMS-IX they renumbered from PI to PA IPv6 space and that this was not a big problem. Marco clarified that this was a migration of a service network, not a customer network. Benedikt Stockebrand said that when it comes to renumbering, the biggest problem is all the legacy equipment and configurations. You need to figure out first what the network is supposed to be doing before you renumber it. Shane asked the audience if IPv6 provides any benefits at all when it comes to renumbering? Benedikt said it is important that people realise how to pay for this in the long run. Aaron Hughes (6connect) reported that in the ARIN region, a best current operational practices track was started. The first document described subnetting IPv6 for ISPs. We also said that they'd be happy to work on documentation for enterprises as well. These topics are discussed on the following mailing list: bcp-discuss at bind.com Aaron said he?d send more information to the RIPE IPv6-WG mailing list. Jan Zorz wondered why the IETF created the 6RENUM WG. Shane responded that it might be a little early to present their work since the WG has just started. Gert responded to Shane's earlier question that renumbering in IPv6 is easier, because all stacks know how to handle multiple addresses at the same time. But from a planning point of view, it is the same. ACTION WG chair: to send mail to the mailing list asking if there are volunteers to start on a renumbering BCP for ISPs and if people know if there is already work being done in this area. 3. Replacing ripe-501 (Jan Zorz, Sander Steffann) See "Requirements for IPv6 in ICT Equipment": http://www.ripe.net/ripe/docs/ripe-501 ripe-501 was published a year ago and has already been translated into ten languages.Since then many requests for changes were received. The document was a great success, but of course things can always be improved. New devices were added to the document. Specifications about load balancers were added. The compliance criteria were also simplified. There was a good discussion on the mailing list. The document is currently in last call. Note that the document is meant as a template, don't just cut and paste bits and pieces. Jan and Sander thanked Merike Kaeo for providing a lot of useful input. Randy Bush (IIJ) had a question about the CPE diagram in the document. Jan explained that the RFC written by Ole Troan was included as a mandatory requirement. The idea was not to duplicate Ole's work. If a CPE does not support this RFC, it should not be taken into account in the process. Sander asked people to send comments to the mailing lists to specify if this comment should be included right now (which means extending the last call) or if it is OK to include it in the next version. The Last Call for the current version of the document ends next week, 10 November 2011. Tahar Schaa (consultant supporting German government) asked what their plans were to include source address validation improvements. Sander confirmed that it would be included in the document. But it is up to the tender initiator to ask for this requirement or not. 4. Horses for courses - like IPv6 profiles for German Administration (Constanze Buerger, Bundesministerium des Inneren, Germany) The prepsentation is available at: http://ripe63.ripe.net/presentations/74-2011_RIPE_63_de.government_Constanze_Buerger.pdf Maksym asked if the files Constanze mentioned in her presentation are publicly available. Constance said this has not yet been decided. Alexander Isavnin from Russia wondered how much this process is costing the German taxpayers? Constance responded that they are just coordinating the IPv6 address space allocated to them and the deployment to all federal governments and institutions. But it will take a long time until this is finished. Alexander asked if each department has its own budget. Constance confirmed that this is the case. She also explained that it is not so easy to convince people to cooperate. Every municipality can do their own thing. That means she and her team have to do a lot of convincing, but they cannot force the others to cooperate. Jan Zorz thanked Constanze for considering ripe-501 as a basis for her work and mentioned that there will be a new version (and a new number). He asked that Constanze and Tahar make their own adjustments in their documentation when the new version comes out. Tahar clarified that ripe-501 goes into the same direction as their work is going already anyway. So yes, a few adjustments will have to be made, but it's not that difficult, because they are aware of the changes. Jan asked if Constanze or Tahar are aware of any other governments following the German example. Tahar said he believed that Spain is following a similar process. Martin Levy (Hurricane Electric) thought it would be better to rephrase the earlier question: ?What would this cost if you were to ignore IPv6??. Constance explained that they tried to analyse the costs so that they can put some pressure on the leadership. But it turned out to be very difficult, because the government and the network is so heterogeneous. In the end they had to stop the process analysing the costs. Tahar added that Germany, due to its constitution, is a complex country. The costs are held and managed in each state and each municipality. All that can be done really is to provide the first steps and some supporting documentation. He saw two main motivations to deploy IPv6: 1. Address renumbering (there is a long history of using IPv4 address, mostly private, which means that there is now a horrible network of cascading NAT layers. Some of the networks have been renumbered up to four times and this is very costly. Deploying IPv6 will solve these problems. 2. If one wants to set up a telephone infrastructure in Germany today, it is only possible to buy VoIP telephony. What about one office wants to call another and the addresses clash? You can better start using public (IPv6) addresses. In conclusion, the question is not: What does it cost to do it, but what does it cost not to do it? Constance said yes, just do it. 4. Status of ADSL Deployment in the XS4All network (Timo Hilbrink, XS4All) The presentation is available at: http://ripe63.ripe.net/presentations/75-th-ipv6-ripe63-20111101.pdf Maksym asked why the MTU on one of the slides was set to 1452, why it was so low and whether it was part of his implementation. Timo said yes. Gert applaud Timo and XS4All on this. He said it was great to see one mass-market provider go forward with this. He said he hopes that there will also be more users in Germany any time soon. Andy Davidson (Hurricane Electric) asked if Timo knew the retail prices of the new CPEs that include IPv6. Timo said they were around EUR 100. Andy concluded that that price is coming down all the time, which is great. 5. Lightning Talks 5.1. Results of the 2011 Global IPv6 Deployment Monitoring Survey (Chris Buckridge for Maarten Botemann) The presentation is available at: http://ripe63.ripe.net/presentations/114-ipv6-survey-BUCKRIDGE.pdf 5.2. Effects of Capacity Building on IPv6 Adoption and Deployment (Marco Hogewoning, RIPE NCC) The presentation is available at: http://ripe63.ripe.net/presentations/66-MH-RIPE63-Capacity-LT.pdf 5.3. Stateless IPv4 over IPv6 in 5 minutes (Ole Troan, Cisco) The presentation is available at: http://ripe63.ripe.net/presentations/40-RIPE63-MAP-lightning.pdf Jan, as a member of the MAP (A+P) architecture team, asked attendees if they felt that well-known ports must never be allocated to a user or if the user should have the opportunity to use well-known ports. Ole responded that you could give users that are not happy with the default setting a full IPv4 address. Benedikt explained that users shouldn't need low ports. He wondered if prolonging IPv4 is really worth the effort. The majority of people don't want to run a server at home. For those who want to, they will switch to IPv6 shortly. Those who use an IPv4 server at home will get some IPv4 addresses from somewhere. It's not something you want to provision for mass customer products. Jan said he believed stateless A+P is worthwhile because we don't want CGNs. Benedikt disagreed and said he wants CGN and wants it to hurt that much that people will use native IPv6 in the end. Jari Arkko (Eriksson) pointed out that there are trade-offs: If you are doing port division per customer on an static basis for customers, the power user and a small user get the same service, which neither of them will be happy with; we will pay in any case. 6. IANA Reserved IPv4 prefixes for shared CGN space (David Kessens) The presentation is available at: http://ripe63.ripe.net/presentations/84-201111012011-ripe63-vienna-sharedaddresspace.pdf < http://ripe63.ripe.net/presentations/84-201111012011-ripe63-vienna-sharedaddresspace.pdf > Gert wondered which address space they were going to use. David agreed that this is of course an issue. However, since this proposal was well received in the ARIN region, it was suggested to use a /10 out of ARINs' address space. Jari reported that he was one of the IESG members who reviewed this document and said he had a couple of concerns. Apart from the policy issues that are down to the RIR communities to decide, there are some issues with this particular proposal. What's the affect on the ISP ("My device works well now, but does it have negative affects on other parts of the network?"). He urged people to participate in this discussion and check if this would break anything. Kurtis Lindquist commented that this whole process seemed a little weird (between one RIR and the IAB and the IESG). Martin Levy said it is interesting that they were talking about IPv4 and CGNs a lot instead of about IPv6. ACTION: It was decided to defer the topic of draft-weil-shared-transition-space-request to the mailing list. 7. IPv6 Speed Dating Marco asked the audience how many people in the room have deployed IPv6 (about half of the room). The other half is busy deploying it. He further asked those who are busy deploying it, what the biggest challenge is they face in the process? A speaker from the audience said that the biggest challenge is to convince the management. The management thinks it is too expensive. Marco asked those who deployed IPv6 how they passed that hurdle. Andy said to just do it anyways. Jan Zorz responded that he gave a 45 minute presentation earlier explaining how to convince the management. Benedikt suggested to ask the management: "What's the business case of an earth quake?" The same applies to IPv6: by trying to safe money, you might lose customers and money in the end. Timo suggested to explain to the management what they would lose if they didn't do it. Jen Linkova (Google) explained that from an operational perspective they are still discovering bugs now and that they have to test almost everything again for IPv6. Therefore her advice is to test everything twice from the start, don't expect things to works out of the box. Marco pointed out that this community and especially this IPv6 WG is a great pool of resources on IPv6 deployment. Dave Wilson (HEAnet) responded to the question of what problem he had to solve and how he convinced his boss. He said he solved this in his case by providing a business case. But that might be different in other environments. A speaker from the audience said that after convincing your boss, the main problem is organisational: all departments in your company (networks, IT, service, marketing etc.) have to work together. That is not always easy. Andy added to his earlier comment that even if people don't have official mandate, he would advise them to skill-up anyways, so they can be prepared for the deployment phase. The working group co-chairs thanked attendees and closed the session. Summary of Action Points ? IPv6 WG RIPE 63 ACTION WG chair: to send mail to the mailing list asking if there are volunteers to start on a renumbering BCP for ISPs and if people know if there is already work being done in this area. ACTION: It was decided to defer the topic of draft-weil-shared-transition-space-request to the mailing list. From matthew at walster.org Sat Jan 14 04:25:06 2012 From: matthew at walster.org (Matthew Walster) Date: Sat, 14 Jan 2012 03:25:06 +0000 Subject: [ipv6-wg] v6 World Connectivity To v4 World Message-ID: Apologies if this would be more suitable for IETF v6ops rather than IPv6-WG, I'm not overly familiar with the v6 development community. As is painfully apparent, most of the world if v4 only at the moment - and the various DNS ALGs etc for getting v4 connectivity onto v6 only connections seem "hackish" at best, and have real problems when it comes to things such as 1500-byte v4 packets needing fragmenting to travel over v6 nets. While playing with my local ssh daemon, I was reminded that inside my ssh client is a SOCKS5 server - I can connect to it by just setting my global SOCKS setting to use the localhost and all the traffic is forwarded down the tunnel to the remote host for processing. I was wondering whether anyone had any experience in setting a SOCKS proxy on a v6-only host, where the DNS/SOCKS proxies have both v4 and v6 addressing, and whether they can then access v4 services like web sites, mail servers, gaming applications etc. The basic idea is that you would use the v6 internet where possible, and go through your ISPs v4 SOCKS gateway for anything that didn't return a AAAA record. Is that idea right, and if so, is it sustainable? Assuming for the moment that I've made a correct assumption, is there a way we can make the process easier? Back in v4 world, there's DHCP option 252 which allows you to configure a WPAD file that would be downloaded and parsed by your web browser, setting HTTP proxies etc for certain classes of service - non-local traffic etc. Is it feasible to add an option to DHCPv6 so that a "v4 compatibility" string could be set, whereby a fall-back SOCKS server is used for non-v6 connections? Thinking off the top of my head, it would work as follows for the "no-clue" home user: User's router talks to ISP via DHCPv6: gets response detailing address to use also gets prefix delegation for local LAN usage also gets v4 compatibility string, which it stores for relaying to clients User's router listens for DHCPv6 requests, issues clients on local LAN public v6 addresses: sets option for v4-compatibility for clients User's computer turns on, asks for addressing information: gets v6 address via DHCPv6 gets v4-compatibility string and sets global SOCKS proxy variable, if not manually configured gets other string - DNS servers, routes etc. I stress that this idea is for v6/v4 co-existence, and isn't designed for "islands of v4" or "islands of v6", it would of course assume that v4 availability is restricted and a real effort to move to v6 was made. It's a transition mechanism that should be easy to turn off once most of the services have been migrated (hopefully transparently to the end customer). If there is a major flaw in my idea, I'd greatly appreciate constructive criticism and feedback! Matthew Walster From marcoh at marcoh.net Tue Jan 17 16:01:55 2012 From: marcoh at marcoh.net (Marco Hogewoning) Date: Tue, 17 Jan 2012 16:01:55 +0100 Subject: [ipv6-wg] IPv6 Launch Day Message-ID: The follow up on World IPv6 Day has just been announced. Marco http://www.worldipv6launch.org/press/20120117-2/ World IPv6 Launch Solidifies Global Support for New Internet Protocol Top websites, Internet service providers, and home networking equipment manufacturers commit to largest transition in the Internet?s history [Washington, D.C., USA and Geneva, Switzerland] ? 17 January 2012 ? Major Internet service providers (ISPs), home networking equipment manufacturers, and web companies around the world are coming together to permanently enable IPv6 for their products and services by 6 June 2012. Organized by the Internet Society, and building on the successful one-day World IPv6 Day event held on 8 June 2011, World IPv6 Launch represents a major milestone in the global deployment of IPv6. As the successor to the current Internet Protocol, IPv4, IPv6 is critical to the Internet?s continued growth as a platform for innovation and economic development. ?The fact that leading companies across several industries are making significant commitments to participate in World IPv6 Launch is yet another indication that IPv6 is no longer a lab experiment; it?s here and is an important next step in the Internet?s evolution,? commented Leslie Daigle, the Internet Society?s Chief Internet Technology Officer. ?And, as there are more IPv6 services, it becomes increasingly important for companies to accelerate their own deployment plans.? ISPs participating in World IPv6 Launch will enable IPv6 for enough users so that at least 1% of their wireline residential subscribers who visit participating websites will do so using IPv6 by 6 June 2012. These ISPs have committed that IPv6 will be available automatically as the normal course of business for a significant portion of their subscribers. Committed ISPs are: ? AT&T ? Comcast ? Free Telecom ? Internode ? KDDI ? Time Warner Cable ? XS4ALL Participating home networking equipment manufacturers will enable IPv6 by default through the range of their home router products by 6 June 2012. Committed equipment manufacturers are: ? Cisco ? D-Link Web companies participating in World IPv6 Launch will enable IPv6 on their main websites permanently beginning 6 June 2012. Inaugural participants are: ? Facebook (www.facebook.com) ? Google (www.google.com) ? Microsoft Bing (www.bing.com) ? Yahoo! (www.yahoo.com) Content delivery network providers Akamai and Limelight will be enabling their customers to join this list of participating websites by enabling IPv6 throughout their infrastructure. As IPv4 addresses become increasingly scarce, every segment of the industry must act quickly to accelerate full IPv6 adoption or risk increased costs and limited functionality online for Internet users everywhere. World IPv6 Launch participants are leading the way in this effort. For more information about World IPv6 Launch, products, and services covered, as well as links to useful information for users and information about how other companies may participate, visit: http://www.worldipv6launch.org About the need for IPv6 IPv4 has approximately four billion IP addresses (the sequence of numbers assigned to each Internet-connected device). The explosion in the number of people, devices, and web services on the Internet means that IPv4 is running out of space. IPv6, the next-generation Internet protocol which provides more than 340 trillion, trillion, trillion addresses, will connect the billions of people not connected today and will help ensure the Internet can continue its current growth rate indefinitely. About the Internet Society The Internet Society is the world?s trusted independent source of leadership for Internet policy, technology standards and future development. Based on its principled vision and substantial technological foundation, the Internet Society works with its members and Chapters around the world to promote the continued evolution and growth of the open Internet through dialog among companies, governments, and other organizations around the world. For more information, see: www.internetsociety.org Akamai Technologies, Inc. Jeff Young AT&T Jenny Bridges Cisco Marc Musgrove Comcast Jorge Alberni D-Link Denise Keddy Facebook Nisha Gulati Google Inc. Internet Society Wende Cover Internode John Harris Limelight Networks Microsoft Bing Bill Hankes Time Warner Cable Justin Venech Yahoo! Christina Scharrenberg From jouni.nospam at gmail.com Wed Jan 18 12:29:52 2012 From: jouni.nospam at gmail.com (jouni korhonen) Date: Wed, 18 Jan 2012 13:29:52 +0200 Subject: [ipv6-wg] More IPv6 on mobile networks testing... In-Reply-To: <4F0E96C3.2030207@go6.si> References: <4F0E96C3.2030207@go6.si> Message-ID: Jan, I tested this stick against Rel-9 network a while ago. With "IP Version Dual" the PDP Type IPv4v6 works just fine from the network and bearer set up point of view i.e. you get both IPv4 & IPv6 over one bearer. However, the current software in these sticks fail to configure the host side interface properly, thus your host stack sees only one address. Just as a FYI when you get there you won't be surprised.. Of course if you have access to SGSN or GGSN logs you can find out addressing information and configure missing pieces manually :) - Jouni On Jan 12, 2012, at 10:16 AM, Jan Zorz @ go6.si wrote: > Hi, > > I suspect some of you could find this interesting. Excuse to others for filling their mailboxes ;) > > http://go6.si/en/2012/01/nokia-usb-modem-21m02-ii/ > > Nokia USB "Internet stick" with PDPv4, PDPv6 and PDPv4v6 capability test. > > Cheers, Jan > From jan at go6.si Thu Jan 26 09:50:29 2012 From: jan at go6.si (Jan Zorz @ go6.si) Date: Thu, 26 Jan 2012 09:50:29 +0100 Subject: [ipv6-wg] RIPE-501 replacement document - IPsec question to community - we need your input. In-Reply-To: <317616CE96204D49B5A1811098BA89500625BA9B@XMB-AMS-110.cisco.com> References: <4EF43F92.4000403@go6.si> <82y5u3bqt7.fsf@mid.bfk.de><00568AC9-DA18-4243-B030-72843FD11A05@doubleshotsecurity.com><82y5ty1iku.fsf@mid.bfk.de> <4EF9A06F.40107@go6.si><82d3ba192h.fsf@mid.bfk.de> <20111227191149.GO27877@serpens.de><47BEAF0E-D6CC-44E8-822A-4DF7B947085F@steffann.nl> <4EFAE4BA.2060505@pragma.si> <317616CE96204D49B5A1811098BA89500625BA9B@XMB-AMS-110.cisco.com> Message-ID: <4F2113D5.4050608@go6.si> On 1/2/12 3:08 PM, Eric Vyncke (evyncke) wrote: > Here is my voice: remove IPsec mandatory to all devices EXCEPT for > router supporting OSPFv3 (ESP-null in transport mode being mandatory) > and for firewall (where IKEv3 and IPsecv3 are mandatory) Eric, @all This question is now preventing the new draft to be published, as we think it's very important so solve it in a way, that makes sense and at the same time not to go against IETF and RFC specs. Sometimes this two clashes :) Community: Please, give us more input, so we can decide and write down something, that is what community thinks - otherwise we'll have to listen to sample of 6 voices. It's time to replace RIPE-501. Cheers, Jan From tjc at ecs.soton.ac.uk Thu Jan 26 15:22:07 2012 From: tjc at ecs.soton.ac.uk (Tim Chown) Date: Thu, 26 Jan 2012 14:22:07 +0000 Subject: [ipv6-wg] RIPE-501 replacement document - IPsec question to community - we need your input. In-Reply-To: <4F2113D5.4050608@go6.si> References: <4EF43F92.4000403@go6.si> <82y5u3bqt7.fsf@mid.bfk.de><00568AC9-DA18-4243-B030-72843FD11A05@doubleshotsecurity.com><82y5ty1iku.fsf@mid.bfk.de> <4EF9A06F.40107@go6.si><82d3ba192h.fsf@mid.bfk.de> <20111227191149.GO27877@serpens.de><47BEAF0E-D6CC-44E8-822A-4DF7B947085F@steffann.nl> <4EFAE4BA.2060505@pragma.si> <317616CE96204D49B5A1811098BA89500625BA9B@XMB-AMS-110.cisco.com> <4F2113D5.4050608@go6.si> <205724FC-76EE-4DCA-9A8F-ECA2F7901B2A@ecs.soton.ac.uk> Message-ID: On 26 Jan 2012, at 08:50, Jan Zorz @ go6.si wrote: > On 1/2/12 3:08 PM, Eric Vyncke (evyncke) wrote: >> Here is my voice: remove IPsec mandatory to all devices EXCEPT for >> router supporting OSPFv3 (ESP-null in transport mode being mandatory) >> and for firewall (where IKEv3 and IPsecv3 are mandatory) > > Eric, @all > > This question is now preventing the new draft to be published, as we think it's very important so solve it in a way, that makes sense and at the same time not to go against IETF and RFC specs. Sometimes this two clashes :) > > Community: Please, give us more input, so we can decide and write down something, that is what community thinks - otherwise we'll have to listen to sample of 6 voices. Jan, I agree pushing 501-bis asap should be a priority. Is there a pointer to the diffs between 501-bis and specific RFCs? Obviously I could go and look it up, just wondered if a list of differences already existed in a previous post or article. Tim From ip at ioshints.info Thu Jan 26 16:05:09 2012 From: ip at ioshints.info (Ivan Pepelnjak) Date: Thu, 26 Jan 2012 16:05:09 +0100 Subject: [ipv6-wg] RIPE-501 replacement document - IPsec question to community - we need your input. In-Reply-To: <4F2113D5.4050608@go6.si> References: <4EF43F92.4000403@go6.si> <82y5u3bqt7.fsf@mid.bfk.de><00568AC9-DA18-4243-B030-72843FD11A05@doubleshotsecurity.com><82y5ty1iku.fsf@mid.bfk.de> <4EF9A06F.40107@go6.si><82d3ba192h.fsf@mid.bfk.de> <20111227191149.GO27877@serpens.de><47BEAF0E-D6CC-44E8-822A-4DF7B947085F@steffann.nl> <4EFAE4BA.2060505@pragma.si> <317616CE96204D49B5A1811098BA89500625BA9B@XMB-AMS-110.cisco.com> <4F2113D5.4050608@go6.si> Message-ID: <00c801ccdc3b$e95b2eb0$bc118c10$@info> > > Here is my voice: remove IPsec mandatory to all devices EXCEPT for > > router supporting OSPFv3 (ESP-null in transport mode being mandatory) > > and for firewall (where IKEv3 and IPsecv3 are mandatory) +1 Ivan From merike at doubleshotsecurity.com Thu Jan 26 17:18:32 2012 From: merike at doubleshotsecurity.com (Merike Kaeo) Date: Thu, 26 Jan 2012 08:18:32 -0800 Subject: [ipv6-wg] RIPE-501 replacement document - IPsec question to community - we need your input. In-Reply-To: References: <4EF43F92.4000403@go6.si> <82y5u3bqt7.fsf@mid.bfk.de><00568AC9-DA18-4243-B030-72843FD11A05@doubleshotsecurity.com><82y5ty1iku.fsf@mid.bfk.de> <4EF9A06F.40107@go6.si><82d3ba192h.fsf@mid.bfk.de> <20111227191149.GO27877@serpens.de><47BEAF0E-D6CC-44E8-822A-4DF7B947085F@steffann.nl> <4EFAE4BA.2060505@pragma.si> <317616CE96204D49B5A1811098BA89500625BA9B@XMB-AMS-110.cisco.com> <4F2113D5.4050608@go6.si> <205724FC-76EE-4DCA-9A8F-ECA2F7901B2A@ecs.soton.ac.uk> Message-ID: <2EF113D4-BA47-419D-9BE0-1BB06096DEC1@doubleshotsecurity.com> On Jan 26, 2012, at 6:22 AM, Tim Chown wrote: > On 26 Jan 2012, at 08:50, Jan Zorz @ go6.si wrote: > >> On 1/2/12 3:08 PM, Eric Vyncke (evyncke) wrote: >>> Here is my voice: remove IPsec mandatory to all devices EXCEPT for >>> router supporting OSPFv3 (ESP-null in transport mode being mandatory) >>> and for firewall (where IKEv3 and IPsecv3 are mandatory) >> >> Eric, @all >> >> This question is now preventing the new draft to be published, as we think it's very important so solve it in a way, that makes sense and at the same time not to go against IETF and RFC specs. Sometimes this two clashes :) >> >> Community: Please, give us more input, so we can decide and write down something, that is what community thinks - otherwise we'll have to listen to sample of 6 voices. > > Jan, > > I agree pushing 501-bis asap should be a priority. > > Is there a pointer to the diffs between 501-bis and specific RFCs? Obviously I could go and look it up, just wondered if a list of differences already existed in a previous post or article. The issue right now is mostly only around IPsec and whether to have it be designated as mandatory or optional. The new IPv6 Node Requirements (RFC 6434) has the following language: "Security Architecture for the Internet Protocol" [RFC4301] SHOULD be supported by all IPv6 nodes. Note that the IPsec Architecture requires (e.g., Section 4.5 of [RFC4301]) the implementation of both manual and automatic key management. Currently, the default automated key management protocol to implement is IKEv2. As required in [RFC4301], IPv6 nodes implementing the IPsec Architecture MUST implement ESP [RFC4303] and MAY implement AH [RFC4302]." I am starting to think that he language given by Eric above may be what gives us most consensus (and least controversy) :) - merike From jan at go6.si Thu Jan 26 17:37:08 2012 From: jan at go6.si (Jan Zorz @ go6.si) Date: Thu, 26 Jan 2012 17:37:08 +0100 Subject: [ipv6-wg] RIPE-501 replacement document - IPsec question to community - we need your input. In-Reply-To: <2EF113D4-BA47-419D-9BE0-1BB06096DEC1@doubleshotsecurity.com> References: <4EF43F92.4000403@go6.si> <82y5u3bqt7.fsf@mid.bfk.de><00568AC9-DA18-4243-B030-72843FD11A05@doubleshotsecurity.com><82y5ty1iku.fsf@mid.bfk.de> <4EF9A06F.40107@go6.si><82d3ba192h.fsf@mid.bfk.de> <20111227191149.GO27877@serpens.de><47BEAF0E-D6CC-44E8-822A-4DF7B947085F@steffann.nl> <4EFAE4BA.2060505@pragma.si> <317616CE96204D49B5A1811098BA89500625BA9B@XMB-AMS-110.cisco.com> <4F2113D5.4050608@go6.si> <205724FC-76EE-4DCA-9A8F-ECA2F7901B2A@ecs.soton.ac.uk> <2EF113D4-BA47-419D-9BE0-1BB06096DEC1@doubleshotsecurity.com> Message-ID: <4F218134.1000506@go6.si> On 1/26/12 5:18 PM, Merike Kaeo wrote: > >>> On 1/2/12 3:08 PM, Eric Vyncke (evyncke) wrote: >>>> Here is my voice: remove IPsec mandatory to all devices EXCEPT >>>> for router supporting OSPFv3 (ESP-null in transport mode being >>>> mandatory) and for firewall (where IKEv3 and IPsecv3 are >>>> mandatory) > I am starting to think that he language given by Eric above may be > what gives us most consensus (and least controversy) :) > > - merike Me too... Jan From marco.sommani at cnr.it Fri Jan 27 08:51:27 2012 From: marco.sommani at cnr.it (Marco Sommani) Date: Fri, 27 Jan 2012 08:51:27 +0100 Subject: [ipv6-wg] RIPE-501 replacement document - IPsec question to community - we need your input. In-Reply-To: <4F2113D5.4050608@go6.si> References: <4EF43F92.4000403@go6.si> <82y5u3bqt7.fsf@mid.bfk.de><00568AC9-DA18-4243-B030-72843FD11A05@doubleshotsecurity.com><82y5ty1iku.fsf@mid.bfk.de> <4EF9A06F.40107@go6.si><82d3ba192h.fsf@mid.bfk.de> <20111227191149.GO27877@serpens.de><47BEAF0E-D6CC-44E8-822A-4DF7B947085F@steffann.nl> <4EFAE4BA.2060505@pragma.si> <317616CE96204D49B5A1811098BA89500625BA9B@XMB-AMS-110.cisco.com> <4F2113D5.4050608@go6.si> Message-ID: <0168532D-B056-4EC8-9715-60D2963C0896@cnr.it> >> Here is my voice: remove IPsec mandatory to all devices EXCEPT for >> router supporting OSPFv3 (ESP-null in transport mode being mandatory) >> and for firewall (where IKEv3 and IPsecv3 are mandatory) +1 Marco -- Marco Sommani Consiglio Nazionale delle Ricerche Istituto di Informatica e Telematica Via Giuseppe Moruzzi 1 56124 Pisa - Italia work: +390503152127 (PSTN and nrenum.net) mobile: +393487981019 (PSTN and e164.org) fax: +390503158327 mailto:marco.sommani at cnr.it -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 1806 bytes Desc: not available URL: From fweimer at bfk.de Fri Jan 27 11:05:03 2012 From: fweimer at bfk.de (Florian Weimer) Date: Fri, 27 Jan 2012 10:05:03 +0000 Subject: [ipv6-wg] RIPE-501 replacement document - IPsec question to community - we need your input. In-Reply-To: <317616CE96204D49B5A1811098BA89500625BA9B@XMB-AMS-110.cisco.com> (Eric Vyncke's message of "Mon, 2 Jan 2012 15:08:49 +0100") References: <4EF43F92.4000403@go6.si> <82y5u3bqt7.fsf@mid.bfk.de> <00568AC9-DA18-4243-B030-72843FD11A05@doubleshotsecurity.com> <82y5ty1iku.fsf@mid.bfk.de> <4EF9A06F.40107@go6.si> <82d3ba192h.fsf@mid.bfk.de> <20111227191149.GO27877@serpens.de> <47BEAF0E-D6CC-44E8-822A-4DF7B947085F@steffann.nl> <4EFAE4BA.2060505@pragma.si> <317616CE96204D49B5A1811098BA89500625BA9B@XMB-AMS-110.cisco.com> Message-ID: <82hazhsbow.fsf@mid.bfk.de> * Eric Vyncke: > Here is my voice: remove IPsec mandatory to all devices EXCEPT for > router supporting OSPFv3 (ESP-null in transport mode being mandatory) > and for firewall (where IKEv3 and IPsecv3 are mandatory) This change seems fine. -- Florian Weimer BFK edv-consulting GmbH http://www.bfk.de/ Kriegsstra?e 100 tel: +49-721-96201-1 D-76133 Karlsruhe fax: +49-721-96201-99 From marcoh at marcoh.net Tue Jan 31 13:53:29 2012 From: marcoh at marcoh.net (Marco Hogewoning) Date: Tue, 31 Jan 2012 13:53:29 +0100 Subject: [ipv6-wg] Draft minutes of RIPE63 In-Reply-To: <90C6B566-633B-4443-8CB2-0A777A49129D@marcoh.net> References: <90C6B566-633B-4443-8CB2-0A777A49129D@marcoh.net> Message-ID: <033AB53E-1DC7-43E7-9E74-E6A4F7C26965@marcoh.net> > Dear colleagues, > > Attached are the draft minutes of our working group session in Vienna at the RIPE63 Meeting. Please review them and if you have any corrections or comments, please post them to this list before Friday the 27th of January COB. If we haven't received any comments or corrections by that date, we will assume consensus and will ask the RIPE NCC to publish these as final. Dear colleagues, We have not received any comments or additions and we hereby declare consensus. The minutes are now final and we will ask the RIPE NCC to publish them to the website. Thank you and hope to see you at RIPE 64, The IPv6 working group chairs, Marco Hogewoning Shane Kerr David Kessens