From mir at ripe.net Tue Oct 4 14:48:09 2011 From: mir at ripe.net (Mirjam Kuehne) Date: Tue, 04 Oct 2011 14:48:09 +0200 Subject: [ipv6-wg] Global IPv6 Routing Table 2011 In-Reply-To: <4E808D70.2050704@ripe.net> References: <4E808D70.2050704@ripe.net> Message-ID: <4E8B0089.8050602@ripe.net> Dear colleagues, As a follow-up to his recent article "Routing 2011", Geoff Huston is now looking at the IPv6 routing table in 2011. Read on RIPE Labs: http://labs.ripe.net/Members/gih/routing-ipv6-in-2011 Kind regards, Mirjam Kuehne RIPE NCC From cris.pascual.gonzalez at gmail.com Fri Oct 7 15:09:34 2011 From: cris.pascual.gonzalez at gmail.com (Cristina Pascual) Date: Fri, 7 Oct 2011 15:09:34 +0200 Subject: [ipv6-wg] 2nd CfP: ICIW 2012 || May 27 - June 1, 2012 - Stuttgart, Germany Message-ID: <201110071309.p97D9X8c016046@smtp.upv.es> INVITATION: ================= Please, consider to contribute to and/or forward to the appropriate groups the following opportunity to submit and publish original scientific results to ICIW 2012. The submission deadline is set to January 5, 2012. In addition, authors of selected papers will be invited to submit extended article versions to one of the IARIA Journals: http://www.iariajournals.org ================= ============== ICIW 2012 | Call for Papers =============== CALL FOR PAPERS, TUTORIALS, PANELS ICIW 2012, The Seventh International Conference on Internet and Web Applications and Services May 27 - June 1, 2012 - Stuttgart, Germany General page: http://www.iaria.org/conferences2012/ICIW12.html Call for Papers: http://www.iaria.org/conferences2012/CfPICIW12.html - regular papers - short papers (work in progress) - posters - ideas Submission page: http://www.iaria.org/conferences2012/SubmitICIW12.html Submission deadline: January 5, 2012 Sponsored by IARIA, www.iaria.org Extended versions of selected papers will be published in IARIA Journals: http://www.iariajournals.org Please note the Poster and Work in Progress options. The topics suggested by the conference can be discussed in term of concepts, state of the art, research, standards, implementations, running experiments, applications, and industrial case studies. Authors are invited to submit complete unpublished papers, which are not under review in any other conference or journal in the following, but not limited to, topic areas. All tracks are open to both research and industry contributions, in terms of Regular papers, Posters, Work in progress, Technical/marketing/business presentations, Demos, Tutorials, and Panels. Before submission, please check and comply with the Editorial rules: http://www.iaria.org/editorialrules.html ICIW 2012 Topics (topics and submission details: see CfP on the site) IWAS : Internet and Web-based Applications and Services Web technologies, frameworks, languages, mechanisms; Web applications design and development; Interaction with/from Web-based applications; Web-based applications? features; Management of Web-based applications; Evaluation of Web applications; Specialized Web applications; Aggregating multimedia documents; E-business, appliances, and services; IP Grid Management and Grid Services; IP-based convergent solutions and next generation networks; Standards, case studies and special groups on web-based applications; E-business system design, development, and management for SMEs WSSA : Web Services-based Systems and Applications Service Innovations; Service Architectures; Model-driven development of context-aware services; Context-aware service models, architectures and frameworks; Model-driven development of semantic Web services; Web services foundation, architectures, frameworks, languages; Web services architecture and business continuity; Special Web services mechanisms; Semantic Web, Ontology, and Web services; Web service applications ; Data Management aspects in Web Services; Autonomic e-Business integration and collaboration; Web service based Grid computing and P2P computing; Web services based applications for e-Commerce; Multimedia applications using Web Services; Automatic computing for Web services; Web services challenges on trust, security, performance, scalability; Enterprise Web services; Web services discovery, announcing, monitoring and management; Platforms, technologies, mechanisms and case studies; Grid architectures, middleware and toolkits ENSYS: Entertainment Systems Developing entertainment systems and applications; Platforms for entertainment systems; Speech technology & its usability for entertainment systems; Networking requirements for entertainment systems; Traffic generated by entertainment applications; QoS/SLA on entertainment systems; Reliability and high availability of entertainment systems; Identify aspects in entertainment systems; Real-time access to entertainment systems; Customized access entertainment systems; Navigation and entertainment systems; Integration and interoperability aspects in entertainment systems; Entertainment systems and applications; Networking and system support for entertainment systems; Wireless and mobile technologies for entertainment; Wireless multimedia for entertainment; Systems for music and movie distribution; Games on mobile and resource-constrained devices; Mobile video entertainment systems; Car/flight/train entertainment systems; Ubiquitous entertainment systems; Interactive television; Technologies for sport and entertainment; WiFi wireless home entertainment systems; Wearable technologies for entertainment P2PSA: P2P Systems and Applications P2P architectures, techniques, paradigms; P2P programming and data handling; P2P security features; Data and compute intensive applications; P2P networks and protocols; P2P management; P2P Trust and reputation management; Fault tolerance in P2P, quality of availability, accounting in P2P; Self-adaptiveness in P2P overlay networks; Self-configurable P2P systems; Case studies, benchmarking; Copyright and intellectual property; Electronic marketplace, Digital asset management and trading systems; Platforms, environments, testbeds ONLINE: Online Communications, Collaborative Systems, and Social Networks Theory, frameworks, mechanisms, and tools for online communication; Methodologies and languages for on-line communications; Web services and XML use for online communications; Tools for assessing online work, distributed workload; Shared business processes; Collaborative groups and systems; Theory and formalisms of group interactions; Group synergy in cooperative networks; Online gambling, gaming, children groups; Identity features, risks, jurisdiction for online communications; Specifics emergency and e-coaching on online communications; B2B and B2E cooperation; Privacy, identify, security on online communications; Individual anonymity, group trust, and confidentiality on online groups; Conflict, delegation, group selection; Community costs in collaborative groups; Building online social networks with popularity contexts, persuasion, etc.; Technology support for collaborative systems; Techniques, mechanisms, and platforms for remote cooperation SERCOMP: Service computing Adaptive Architecture; Business process integration and management; Cloud Computing; Collective Intelligence for Service Computing; Computational Intelligence; Data Mining of Actual Services; Decision Science; Digital EcoSystems Infrastructure; Economic Clusters; Economics and Economic Experiments; Game Theory; Human Modeling in Services; Intelligent Agents and Multi-Agent Systems; Intra- and Inter-enterprise services; Knowledge Discovery for Service Computing; Nature Inspired Computing Techniques for Service Computing; Optimization of Service Processes; Psychological Approaches to Services; Self Organizing Infrastructure; Sensing of Human Behaviors; Service-centric business models and their economics; Service discovery, repository and registry; Service Engineering; Service evaluation, measurements and delivery audit; Service interaction, service ontologies and service composition; Service Marketing; Service-Oriented Architecture; Service Oriented computing; Soft Computing; Society and business services (public, utility, business, healthcare, consulting, etc.); Sustainable Frameworks; Swarm Intelligence; Ubiquitous and pervasive services (technology, context, security); Value Creation in Services; Web-based basics on service modeling, deployment and maintenance SLAECE: Social and Legal Aspect of Internet Computing Principles, theories, and challenges of legal and social aspects; Strategies, modeling, and requirements engineering of legal and social aspects; Architectures, implementations, and deployment consideration of legal and social aspects; Cyber threats, emerging risks, systemic concerns, and emergency preparedness; Social computing and lifestyle computing; Service marketing and customer relationship management; Market structures and emerging business models; Emerging legal issues due to new computing environment; File / information sharing networks and user behavior; Knowledge modeling, management, and application; Negotiation and contracting as well as contract monitoring and enforcement; E-democracy, e-policy, and governance; Legal and social ontologies; Privacy and copyright in collaborative environments and social networks; Intellectual property rights; Trust, security, and privacy; Counterfeit forensic; Identity management and access control; Security and privacy in location-based services VEWAeL: Virtual Environments and Web Applications for eLearning E-Learning; Web Technologies and Tools for Educational Purposes; Services for E-Learning Platforms; Virtual Learning Environments (VLE); Course Management Systems; Web applications for Teaching; Social Implications of E-Learning; Lifelong E-learning; Teaching-Learning Experiences using the Internet for Educational Purposes; E-learning in the European Higher Education Area (EHEA) and other HE contexts; Web protocols for VLE; Security for VLE; QoS for VLE; Storage management in VLE ECC: Enterprise cloud computing Architectures for enterprise clouds; Principles, concepts and methodologies of enterprise cloud computing; Tools, technologies, methodologies and frameworks for enterprise cloud computing; Enterprise IS architectures such as application, information and technology architectures; Synergies between SOA, Grid Computing and Cloud Infrastructures; Quality of Service (QoS) models; 'Elastic' and on-demand allocation and management of resources to meet business needs; Benefits, issues and limitations of enterprise clouds; Security, data integrity, legal and governance issues for enterprise clouds; Management, monitoring an governance issues; Portability of architectures, applications and data between cloud providers; Reliability and maintenance of cloud-based business architectures; Architectures for Software as a Service, Platform as a Service and Infrastructure as a Service; Network architecture using Storage Clouds; Experience reports with designing, building and using Cloud infrastructure; Novel application architectures, best practices, case studies and surveys ------------------------------ Technical Program Committee: http://www.iaria.org/conferences2012/ComICIW12.html ==================== From ahmed at tamkien.com Mon Oct 10 19:16:52 2011 From: ahmed at tamkien.com (Ahmed Abu-Abed) Date: Mon, 10 Oct 2011 20:16:52 +0300 Subject: [ipv6-wg] /64 vs /127 for Point-to-Point links Message-ID: <195B17A7D62F4B2B82B39B034EBBBB1E@mTOSH> For those contemplating the use of /127 on point-to-point links, Jeff Doyle has a good article arguing the benefits of using /64 subnets with solutions to perceived /64 shortcomings (ping-pong and neighbor cache depletion attacks). http://www.networkcomputing.com/ipv6-tech-center/231700160 Regards, -Ahmed -------------- next part -------------- An HTML attachment was scrubbed... URL: From mir at ripe.net Tue Oct 11 09:50:18 2011 From: mir at ripe.net (Mirjam Kuehne) Date: Tue, 11 Oct 2011 09:50:18 +0200 Subject: [ipv6-wg] New article on RIPE Labs: Visibility of Prefix Lengths Message-ID: <4E93F53A.50708@ripe.net> [apologies for duplicates] Dear colleagues, You might find this new RIPE Labs article interesting: "Visibility of Prefix Lengths in IPv4 and IPv6" http://labs.ripe.net/Members/dbayer/visibility-of-prefix-lengths Kind regards, Mirjam Kuehne RIPE NCC From marcoh at marcoh.net Wed Oct 12 16:29:42 2011 From: marcoh at marcoh.net (Marco Hogewoning) Date: Wed, 12 Oct 2011 16:29:42 +0200 Subject: [ipv6-wg] RIPE 63 draft agenda Message-ID: Dear colleagues, We have just published the first draft of the agenda for the IPv6 Working Group during RIPE 63 Meeting in Vienna. We are scheduled to meet on Tuesday 1 November, starting at 16:00 local time (CET) in the Park Congress rooms 2 + 3. The draft agenda can be viewed online via http://ripe63.ripe.net/programme/meeting-plan/ipv6-wg/ the exact contents and the order of things are likely to change. We are still waiting answers from a couple of speakers, which will be added as soon as they confirm they can make it. As usual, for those who can't be physically present, the session will be broadcasted with the option of remote participation. We would like to thank you all for your contributions and suggestions for content. If you have any questions do not hesitate to ask here on the list or contact us via ipv6-wg-chair at ripe dot net. Hope to see you all in Vienna, The chairs of the IPv6 Working Group, Marco Hogewoning David Kessens Shane Kerr From marcoh at marcoh.net Thu Oct 13 11:15:38 2011 From: marcoh at marcoh.net (Marco Hogewoning) Date: Thu, 13 Oct 2011 11:15:38 +0200 Subject: [ipv6-wg] Last call on the replacement of ripe-501 "Requirements for IPv6 in ICT equipment" Message-ID: <939ADC18-F12C-4C3F-849B-2A7E19943C79@marcoh.net> Dear colleagues, Following up on feedback received from the community during and after the publication of the ripe-501. The authors have worked on a replacement document, incorporating suggestions made by the community and clarifying some of the requirements. Prior draft versions of this document have been posted to this mailing list in the past months. The resulting final draft document is now published on the website and reachable via https://www.ripe.net/ripe/docs/other-documents/requirements-for-ipv6-in-ict-equipment We would like the community to review this document. Although this is not a formal policy proposal, we would like to issue a 4 week working group last call on this draft before publication. Minor changes like typos or formatting can be sent to the authors or to me directly. Please raise any questions or comments on the content to this list. Unless blocking issues are found on this text, it is our intent to publish this draft as a RIPE Document and to change the status of the current document ripe-501 to obsolete, with a reference to the new document. The authors will also present on this draft during the IPv6 working group session at the Vienna meeting. Please send any comments before Thursday November 10 2011, which is 4 weeks from now. Regards, Marco Hogewoning on behalf of the IPv6 Working Group chairs From achatz at forthnetgroup.gr Thu Oct 20 20:22:14 2011 From: achatz at forthnetgroup.gr (Tassos Chatzithomaoglou) Date: Thu, 20 Oct 2011 21:22:14 +0300 Subject: [ipv6-wg] Last call on the replacement of ripe-501 "Requirements for IPv6 in ICT equipment" In-Reply-To: <939ADC18-F12C-4C3F-849B-2A7E19943C79@marcoh.net> References: <939ADC18-F12C-4C3F-849B-2A7E19943C79@marcoh.net> Message-ID: <4EA066D6.80202@forthnetgroup.gr> Hi all, I noticed [I-D.ymbk-aplusp] on the list, which recently became RFC 6346. Besides updating the list, do you find it appropriate to include RFCs with experimental status? Also 3484bis is still in draft. If we include drafts, then 6204 should also be changed to 6204bis. Although i would prefer to have the final RFCs in. -- Tassos Marco Hogewoning wrote on 13/10/2011 12:15: > Dear colleagues, > > Following up on feedback received from the community during and after the publication of the ripe-501. The authors have worked on a replacement document, incorporating suggestions made by the community and clarifying some of the requirements. Prior draft versions of this document have been posted to this mailing list in the past months. > > The resulting final draft document is now published on the website and reachable via https://www.ripe.net/ripe/docs/other-documents/requirements-for-ipv6-in-ict-equipment > > We would like the community to review this document. Although this is not a formal policy proposal, we would like to issue a 4 week working group last call on this draft before publication. > > Minor changes like typos or formatting can be sent to the authors or to me directly. Please raise any questions or comments on the content to this list. Unless blocking issues are found on this text, it is our intent to publish this draft as a RIPE Document and to change the status of the current document ripe-501 to obsolete, with a reference to the new document. > > The authors will also present on this draft during the IPv6 working group session at the Vienna meeting. > > Please send any comments before Thursday November 10 2011, which is 4 weeks from now. > > Regards, > > Marco Hogewoning > on behalf of the IPv6 Working Group chairs > > From ot at cisco.com Fri Oct 21 10:01:35 2011 From: ot at cisco.com (Ole Troan) Date: Fri, 21 Oct 2011 10:01:35 +0200 Subject: [ipv6-wg] Last call on the replacement of ripe-501 "Requirements for IPv6 in ICT equipment" In-Reply-To: <4EA066D6.80202@forthnetgroup.gr> References: <939ADC18-F12C-4C3F-849B-2A7E19943C79@marcoh.net> <4EA066D6.80202@forthnetgroup.gr> Message-ID: <1FE0870B-0C3D-43A2-BDCA-B1D9D5A70BF0@cisco.com> Tassos, > I noticed [I-D.ymbk-aplusp] on the list, which recently became RFC 6346. > Besides updating the list, do you find it appropriate to include RFCs with experimental status? I think we should apply reasonable judgement. with regards to A+P, that's an architecture document. I don't understand how an implementation could support that. there are a number of A+P-ish solutions being worked on in the softwire wg. 4rd, dIVI and ds-lite + A+P. plus a general stateless address mapping document and DHCP option. these are the A+P solutions, but way too early to include any of this work. I do not think 6346 belongs in RIPE-501. > Also 3484bis is still in draft. 3484bis fixes some real problems. hopefully it will be RFC before 501 is out. > If we include drafts, then 6204 should also be changed to 6204bis. > Although i would prefer to have the final RFCs in. I have suggested to just shelf 6204bis until we have something to put in it. 501 already has the references to 6rd and ds-lite that 6204bis adds. so not needed. cheers, Ole From marcoh at marcoh.net Fri Oct 21 10:21:21 2011 From: marcoh at marcoh.net (Marco Hogewoning) Date: Fri, 21 Oct 2011 10:21:21 +0200 Subject: [ipv6-wg] Last call on the replacement of ripe-501 "Requirements for IPv6 in ICT equipment" In-Reply-To: <4EA066D6.80202@forthnetgroup.gr> References: <939ADC18-F12C-4C3F-849B-2A7E19943C79@marcoh.net> <4EA066D6.80202@forthnetgroup.gr> Message-ID: <828CCFEA-BC23-4950-99D0-B70C80CF823E@marcoh.net> > I noticed [I-D.ymbk-aplusp] on the list, which recently became RFC 6346. I think that is an easy fix when we publish it. Unless somebody has big objections against this change, we'll change the reference to point to the RFC instead of the draft. Marco From ip at ioshints.info Fri Oct 21 10:32:11 2011 From: ip at ioshints.info (Ivan Pepelnjak) Date: Fri, 21 Oct 2011 10:32:11 +0200 Subject: [ipv6-wg] Last call on the replacement of ripe-501 "Requirements for IPv6 in ICT equipment" In-Reply-To: <1FE0870B-0C3D-43A2-BDCA-B1D9D5A70BF0@cisco.com> References: <939ADC18-F12C-4C3F-849B-2A7E19943C79@marcoh.net> <4EA066D6.80202@forthnetgroup.gr> <1FE0870B-0C3D-43A2-BDCA-B1D9D5A70BF0@cisco.com> Message-ID: <004101cc8fcb$f0b15bb0$d2141310$@info> Also keep in mind that RIPE-501(bis) addresses a very specific need: helping IT managers select the best real-life IPv6-capable equipment. We could put together the best list of RFCs and drafts, but if nobody supports them (and thus an IT manager using RIPE-501bis cannot buy the boxes he needs), we've just shot ourselves in the foot ... unless you word the document in a way that says RFC-xxxx is mandatory, but RFC-yyyy is highly recommended as its replacement and brings you bonus points. Just my ?0.0002 Ivan > -----Original Message----- > From: ipv6-wg-bounces at ripe.net [mailto:ipv6-wg-bounces at ripe.net] On Behalf > Of Ole Troan > Sent: Friday, October 21, 2011 10:02 AM > To: Tassos Chatzithomaoglou > Cc: Marco Hogewoning; ipv6-wg at ripe.net > Subject: Re: [ipv6-wg] Last call on the replacement of ripe-501 > "Requirements for IPv6 in ICT equipment" [...] > > Also 3484bis is still in draft. > > 3484bis fixes some real problems. hopefully it will be RFC before 501 is > out. From marcoh at marcoh.net Fri Oct 21 14:04:34 2011 From: marcoh at marcoh.net (Marco Hogewoning) Date: Fri, 21 Oct 2011 14:04:34 +0200 Subject: [ipv6-wg] Updated agenda for RIPE63 Message-ID: <96FDFDE7-25FC-4937-B259-3FDAB9465742@marcoh.net> Sorry about not informing you guys any earlier. Yesterday we published an updated agenda for the working group session in Vienna. Additions are a presentation by the German government, a discussion about renumbering and some lightning talks. The full agenda is available at http://ripe63.ripe.net/programme/agendas/ipv6-wg/ The meeting plan shows our slot to be from 16:00 until 17:30. Due to the amount of content we will most probably extend the session until 18:00. Grtx, MarcoH From jan at go6.si Fri Oct 21 22:49:28 2011 From: jan at go6.si (Jan Zorz @ go6.si) Date: Fri, 21 Oct 2011 22:49:28 +0200 Subject: [ipv6-wg] Last call on the replacement of ripe-501 "Requirements for IPv6 in ICT equipment" In-Reply-To: <4EA066D6.80202@forthnetgroup.gr> References: <939ADC18-F12C-4C3F-849B-2A7E19943C79@marcoh.net> <4EA066D6.80202@forthnetgroup.gr> Message-ID: <4EA1DAD8.6080503@go6.si> On 10/20/11 8:22 PM, Tassos Chatzithomaoglou wrote: > Hi all, > > I noticed [I-D.ymbk-aplusp] on the list, which recently became RFC 6346. Hi, Sorry for late response. I thought I updated that (as co-author of that RFC it is expected to be aware of that change :) ) but it looks like it got lost between the versions somewhere. I suggest we corect that in final version. > Besides updating the list, do you find it appropriate to include RFCs > with experimental status? Why not? I agree not putting it into mandatory, but it could stay as optional, specially because it's architecture RFC and covers many flavors of A+P :) > > Also 3484bis is still in draft. > If we include drafts, then 6204 should also be changed to 6204bis. > Although i would prefer to have the final RFCs in. No, drafts are probably not ok. /jan From jan at go6.si Fri Oct 21 22:51:04 2011 From: jan at go6.si (Jan Zorz @ go6.si) Date: Fri, 21 Oct 2011 22:51:04 +0200 Subject: [ipv6-wg] Last call on the replacement of ripe-501 "Requirements for IPv6 in ICT equipment" In-Reply-To: <1FE0870B-0C3D-43A2-BDCA-B1D9D5A70BF0@cisco.com> References: <939ADC18-F12C-4C3F-849B-2A7E19943C79@marcoh.net> <4EA066D6.80202@forthnetgroup.gr> <1FE0870B-0C3D-43A2-BDCA-B1D9D5A70BF0@cisco.com> Message-ID: <4EA1DB38.7070508@go6.si> On 10/21/11 10:01 AM, Ole Troan wrote: > Tassos, > >> I noticed [I-D.ymbk-aplusp] on the list, which recently became RFC >> 6346. Besides updating the list, do you find it appropriate to >> include RFCs with experimental status? > > I think we should apply reasonable judgement. > > with regards to A+P, that's an architecture document. I don't > understand how an implementation could support that. there are a > number of A+P-ish solutions being worked on in the softwire wg. 4rd, > dIVI and ds-lite + A+P. plus a general stateless address mapping > document and DHCP option. these are the A+P solutions, but way too > early to include any of this work. I do not think 6346 belongs in > RIPE-501. hey, it's optional and covers everything you just said. Cool, is it? :) > >> Also 3484bis is still in draft. > > 3484bis fixes some real problems. hopefully it will be RFC before 501 > is out. early november? > >> If we include drafts, then 6204 should also be changed to 6204bis. >> Although i would prefer to have the final RFCs in. > > I have suggested to just shelf 6204bis until we have something to put > in it. 501 already has the references to 6rd and ds-lite that 6204bis > adds. so not needed. +1 /jan From jan at go6.si Fri Oct 21 22:52:45 2011 From: jan at go6.si (Jan Zorz @ go6.si) Date: Fri, 21 Oct 2011 22:52:45 +0200 Subject: [ipv6-wg] Last call on the replacement of ripe-501 "Requirements for IPv6 in ICT equipment" In-Reply-To: <004101cc8fcb$f0b15bb0$d2141310$@info> References: <939ADC18-F12C-4C3F-849B-2A7E19943C79@marcoh.net> <4EA066D6.80202@forthnetgroup.gr> <1FE0870B-0C3D-43A2-BDCA-B1D9D5A70BF0@cisco.com> <004101cc8fcb$f0b15bb0$d2141310$@info> Message-ID: <4EA1DB9D.9080406@go6.si> On 10/21/11 10:32 AM, Ivan Pepelnjak wrote: > Also keep in mind that RIPE-501(bis) addresses a very specific need: > helping IT managers select the best real-life IPv6-capable > equipment. Hi, Indeed. That's the intention :) > > We could put together the best list of RFCs and drafts, but if nobody > supports them (and thus an IT manager using RIPE-501bis cannot buy > the boxes he needs), we've just shot ourselves in the foot ... unless > you word the document in a way that says RFC-xxxx is mandatory, but > RFC-yyyy is highly recommended as its replacement and brings you > bonus points. I think it is that way (as we already had this discussion in the past)... Well established RFC is mandatory, "upgrade" optional - so I like to think :) /jan From evyncke at cisco.com Tue Oct 25 15:45:14 2011 From: evyncke at cisco.com (Eric Vyncke (evyncke)) Date: Tue, 25 Oct 2011 15:45:14 +0200 Subject: [ipv6-wg] Last call on the replacement of ripe-501 "Requirementsfor IPv6 in ICT equipment" In-Reply-To: <939ADC18-F12C-4C3F-849B-2A7E19943C79@marcoh.net> References: <939ADC18-F12C-4C3F-849B-2A7E19943C79@marcoh.net> Message-ID: <317616CE96204D49B5A1811098BA8950059A7238@XMB-AMS-110.cisco.com> A couple of late comments: - for host: I am not sure whether IKE/IPsec should be mandatory, this is not always the case NOW and the IETF intends to move this requirement to SHOULD rather than MUST - for host: I would add 'support ingress traffic filters if ingress traffic filters exist for IPv4' - consumer grade switches: AFAIK, those cheap switches do not support IGMP snooping, so, why mandating MLD snooping? - router and RFC 4213, only the dual-stack part should be supported (as none of us (?) loves tunnels), then the point after (IPsec for tunnels) becomes irrelevant as well as RFC 2473 - router: I would regroup MLD related in one line RFC 4541 (only when switching is implemented as it has no sense for a pure layer-3) and RFC 3810 - router: do we want to have privacy extension for routers as well? Even as an option? - router: I would move the /127 to the mandatory part - router: can we mandate the uRPF function (anti-spoofing?) - firewall & co: I would not mandate (optional is ok of course) to inspect protocol-41 packets for tunnels (because what about teredo? Or any other covert channels) - firewall & co: support of RFC 4213 should be mandatory for the dual-stack part, I cannot imagine having a firewall doing encapsulation (option ok of course) - firewall: mandatory stateful inspection of application traffic transported above IPv6 is the same application is inspected over IPv4 - load balancers: I would put perhaps a gradation in the different 4-6 6-4 load-balancing - load balancers: I fail to see why ISAKMP should be mandatory esp. when IPsec is optional :-) Hope this helps even if a little late... -?ric > -----Original Message----- > From: ipv6-wg-bounces at ripe.net [mailto:ipv6-wg-bounces at ripe.net] On Behalf > Of Marco Hogewoning > Sent: jeudi 13 octobre 2011 11:16 > To: ipv6-wg at ripe.net > Subject: [ipv6-wg] Last call on the replacement of ripe-501 "Requirementsfor > IPv6 in ICT equipment" > > Dear colleagues, > > Following up on feedback received from the community during and after the > publication of the ripe-501. The authors have worked on a replacement > document, incorporating suggestions made by the community and clarifying > some of the requirements. Prior draft versions of this document have been > posted to this mailing list in the past months. > > The resulting final draft document is now published on the website and > reachable via https://www.ripe.net/ripe/docs/other-documents/requirements- > for-ipv6-in-ict-equipment > > We would like the community to review this document. Although this is not a > formal policy proposal, we would like to issue a 4 week working group last > call on this draft before publication. > > Minor changes like typos or formatting can be sent to the authors or to me > directly. Please raise any questions or comments on the content to this > list. Unless blocking issues are found on this text, it is our intent to > publish this draft as a RIPE Document and to change the status of the > current document ripe-501 to obsolete, with a reference to the new document. > > The authors will also present on this draft during the IPv6 working group > session at the Vienna meeting. > > Please send any comments before Thursday November 10 2011, which is 4 weeks > from now. > > Regards, > > Marco Hogewoning > on behalf of the IPv6 Working Group chairs From sander at steffann.nl Tue Oct 25 16:38:27 2011 From: sander at steffann.nl (Sander Steffann) Date: Tue, 25 Oct 2011 16:38:27 +0200 Subject: [ipv6-wg] Last call on the replacement of ripe-501 "Requirementsfor IPv6 in ICT equipment" In-Reply-To: <317616CE96204D49B5A1811098BA8950059A7238@XMB-AMS-110.cisco.com> References: <939ADC18-F12C-4C3F-849B-2A7E19943C79@marcoh.net> <317616CE96204D49B5A1811098BA8950059A7238@XMB-AMS-110.cisco.com> Message-ID: <67E5ADD3-941C-4AD5-A0FC-FA7471933607@steffann.nl> Hi Eric, > - for host: I am not sure whether IKE/IPsec should be mandatory, this is not always the case NOW and the IETF intends to move this requirement to SHOULD rather than MUST I agree that we should follow the IETF in this. > - for host: I would add 'support ingress traffic filters if ingress traffic filters exist for IPv4' +1 > - consumer grade switches: AFAIK, those cheap switches do not support IGMP snooping, so, why mandating MLD snooping? I agree. A switch that doesn't do IGMP snooping should not have to do MLD snooping... > - router and RFC 4213, only the dual-stack part should be supported (as none of us (?) loves tunnels), then the point after (IPsec for tunnels) becomes irrelevant as well as RFC 2473 > - router: I would regroup MLD related in one line RFC 4541 (only when switching is implemented as it has no sense for a pure layer-3) and RFC 3810 Ok > - router: do we want to have privacy extension for routers as well? Even as an option? > - router: I would move the /127 to the mandatory part > - router: can we mandate the uRPF function (anti-spoofing?) > > - firewall & co: I would not mandate (optional is ok of course) to inspect protocol-41 packets for tunnels (because what about teredo? Or any other covert channels) I think it is wise to inspect everything that they can inspect. Protecting against covert channels is orthogonal to proto-41 inspection IMHO. > - firewall & co: support of RFC 4213 should be mandatory for the dual-stack part, I cannot imagine having a firewall doing encapsulation (option ok of course) My Juniper SSG and SRX boxes do encapsulation... > - firewall: mandatory stateful inspection of application traffic transported above IPv6 is the same application is inspected over IPv4 +1 > - load balancers: I would put perhaps a gradation in the different 4-6 6-4 load-balancing > - load balancers: I fail to see why ISAKMP should be mandatory esp. when IPsec is optional :-) Ack. > Hope this helps even if a little late... Thanks for your feedback Eric :-) Sander From jlloret at dcom.upv.es Mon Oct 31 16:16:05 2011 From: jlloret at dcom.upv.es (Jaime Lloret Mauri) Date: Mon, 31 Oct 2011 16:16:05 +0100 Subject: [ipv6-wg] Deadline Extension: ICNS 2012 || March 25-29, 2012 - St. Maarten, The Netherlands Antilles Message-ID: <201110311516.p9VFG4lw023282@smtp.upv.es> INVITATION: ================= Please, consider to contribute to and/or forward to the appropriate groups the following opportunity to submit and publish original scientific results to ICNS 2012. The submission deadline is extended to November 16, 2011. In addition, authors of selected papers will be invited to submit extended article versions to one of the IARIA Journals: http://www.iariajournals.org ================= ============== ICNS 2012 | Call for Papers =============== CALL FOR PAPERS, TUTORIALS, PANELS ICNS 2012, The Eighth International Conference on Networking and Services March 25-29, 2012 - St. Maarten, The Netherlands Antilles General page: http://www.iaria.org/conferences2012/ICNS12.html Call for Papers: http://www.iaria.org/conferences2012/CfPICNS12.html - regular papers - short papers (work in progress) - posters - ideas Submission page: http://www.iaria.org/conferences2012/SubmitICNS12.html Submission deadline: November 16, 2011 Sponsored by IARIA, www.iaria.org Extended versions of selected papers will be published in IARIA Journals: http://www.iariajournals.org Please, note the Poster and Work in Progress options. The topics suggested by the conference can be discussed in term of concepts, state of the art, research, standards, implementations, running experiments, applications, and industrial case studies. Authors are invited to submit complete unpublished papers, which are not under review in any other conference or journal in the following, but not limited to, topic areas. All tracks are open to both research and industry contributions, in terms of Regular papers, Posters, Work in progress, Technical/marketing/business presentations, Demos, Tutorials, and Panels. Before submission, please check and conform with the Editorial rules: http://www.iaria.org/editorialrules.html ICNS 2012 Topics (topics and submission details: see CfP on the site) ENCOT: Emerging Network Communications and Technologies Access and home networks; Ad hoc networks; Application-specific networks (e.g. SANs); Autonomic Networks; Delay-tolerant Networking; Distributed communications systems & applications; Energy-efficient networking; High-speed & optical networks; Mobile networking and systems; MPLS-VPN & IPSec-VPN networks; Multimedia and multicast communications; Networking Communication theory; Network modeling & simulation; Network monitoring techniques; Network security; Next Generation Networks (NGN); Overlay networks; Peer-to-peer networking; Programmable and Active Networks; Sensor networks; Switching and routing; Wireless and Satellite Networks COMAN: Network Control and Management Network, control and service architectures; Network signaling, pricing and billing; Network middleware; Network management, monitoring and control; Network resource scheduling; Networks policy-based management; Management of autonomic networks and systems; Telecommunication networks architectures; On-demand networks, utility computing architectures; Applications and case studies SERVI: Multi-technology service deployment and assurance Service-oriented architectures; Service definition, creation, bundling, deployment; Service reuse, composition and service feature interaction; Service orchestration and federation; Inter-provider service dependency; Intra-provider service dependency and service interaction; Service middleware and service development platforms (SDPs); Service open architecture (SOA); Profiling and service adaptation; Service privacy and security; Quality of service, service level agreement [QoS/SLA]; Service agreement violations; Mobile services and service migration; Reliability, availability, serviceability [RAS]; Service performance metrics; Traffic engineering, metering, monitoring; Voice over IP services; IP Multimedia services; Real-time/not-real-rime services; real-time services over IP/IPv6; Service performance evaluation, tools, simulation NGNUS: Next Generation Networks and Ubiquitous Services Methodologies, development support, and tools for NGN and converging services; NGN and convergence of ubiquitous services; NGN frameworks, architectures, and concepts; NGN technologies and mechanisms; QoS/SLA, traffic in NGN; NGN transport/service layered capabilities and operations; NGN concepts for active, ad hoc, mobile, and wireless networks; 3G and 4G Mobile networks; Fixed/mobile networks integration and internetworking; Services and service differentiation over NGN; Managing ubiquitous services in NGN; NGN interworking, non-NGN interoperability, migration; Regulatory services in NGN and standard activities; NGN device instrumentation; NGN policy-based control; Next Generation Internet MPQSI: Multi Provider QoS/SLA Internetworking Architectures, frameworks, mechanisms for admission control and measurement; QoS in multi-provider and multi-technology networks; Service classes and multi-provider service class discovery; Service level agreement and service assurance in multi-provider environments; Carrier-class end-to-end SLA and QoS monitoring and management; Multi provider accounting/billing/cost sharing; Management, monitoring, and measurements in multi-provider networks; End-to-end QoS/SLA advanced network services in multi-provider networks; End-to-end QoS/SLA for multimedia applications and services in multi-provider networks; Security issues in multi-service provider networks; Business models for multi-providers under QoS/SLA constraints; Standards and fora activities GRIDNS: Grid Networks and Services GRID theory, frameworks, methodologies, architecture, ontology; GRID infrastructure and technologies; GRID middleware; GRID protocols and networking; GRID computing, utility computing, autonomic computing, metacomputing; Programmable GRID; Data GRID; Context ontology and management in GRIDs; Distributed decisions in GRID networks; GRID services and applications; Virtualization, modeling, and metadata in GRID; Resource management, scheduling, and scalability in GRID; GRID monitoring, control, and management; Traffic and load balancing in GRID; User profiles and priorities in GRID; Performance and security in GRID systems; Fault tolerance, resilience, survivability, robustness in GRID; QoS/SLA in GRID networks; GRID fora, standards, development, evolution; GRID case studies, validation testbeds, prototypes, and lessons learned EDNA: Emergency Services and Disaster Recovery of Networks and Applications Theory on disaster-tolerant robust networks; Recovery by disruption resource procedures; Security issues with emergency services and disaster recovery; Networks resiliency methods; Formal methods for safety-critical systems; Networks emergency services; Public safety, reliable emergency communications, and applications; Response to the networks emergency services; Disaster prevention and recovery; Fighting mechanisms for disaster of networks and applications; Notifications and recovery in various network technologies; Customer protection and serviceability perception; Cost models and business impact; Cultural and legal aspects; Future advanced network development and evolution; Standards and guidelines; Lawful interception and defense strategies; IPv6DFI: Deploying the Future Infrastructure IP Upgrade - An Engineering Exercise or a Necessity?; Worldwide IPv6 Adoption - Trends and Policies; National Strategies in Stimulating IPv6 Adoption; IPv6 in Government Infrastructures - Specific Requirements; IPv6 Infrastructures for Emergency Response and Law Enforcement - MetroNet6; Communications Equipment Certification for IPv6 Support; IPv6 in Broadband Networks; IPv6 Programs, from Research to Knowledge Dissemination; IPv6 Technology - Practical Information; Advanced Topics and Latest Developments in IPv6; IPv6 Deployment Experiences and Case Studies; IPv6 Enabled Applications and Devices IPDy: Internet Packet Dynamics Measurement of stream characteristics (reordering, delay, losses, jitter, etc.); Measurement and estimation of network characteristics; Tools, metrics and benchmarks; End-to-end packet dynamics; Timing aspects in packet dynamics; Impact of load balancing, parallelism within nodes, etc. on packet dynamics; QoS mechanisms and their impact on packet dynamics; Models (e.g., relating protocols, resources and architectures to packet dynamics); Mitigation of adverse effects of reordering, jitter, etc.; Traffic engineering; Impact of packet dynamics on application performance GOBS: GRID over Optical Burst Switching Networks Terabit burst switching; Burst assembly for IP DiffServ over optical burst switching networks; Optical network infrastructure for Grid; Synchronous stream optical burst switching; Optical burst switching based GRID architecture; Reliable optical burst switching for next-generation Grid networks; Throughput for Grid optical burst switching Grid networks; Resiliency paths over the optical Grid networks; Consumer oriented Grids using optical burst switching; Protocols for optical burst switched Grid networks; Hybrid optical switching for data-intensive media Grid; Anycast routing in optical burst switched Grid networks; Optical burst switching for IP-over-WDM/DWDM; Customizable Grid-to-optical network; Ultra high capacity optical networks; Hybrid optical burst/circuit switched for Grid-enabled optical networks; Job scheduling in optical burst switching Grid networks; Architecture and middleware for Grid-Over-OBS ---------------------------------- Committee: http://www.iaria.org/conferences2012/ComICNS12.html ====================