- ipv6-wg - mailman.ripe.net

IPv6 Deployment in Access Networks, CFP
by Aleksi Suhonen 09 Apr '14

09 Apr '14

Hello, The Finnish Communications Regulatory Authority (ficora.fi) recently published recommendations for IPv6 adoption in consumer grade Internet connections. TREX hosts an annual seminar for ISPs. We're putting together the programme for this year's seminar[1] and we're trying to help Ficora in their push to get IPv6 on the map in Finland. [1] http://www.trex.fi/2014/seminar.html So I'm looking for presentations from ISPs that have already deployed IPv6 in their Internet access products. The presentations should be rather technical, but there should also be a section on lessons learnt and on future plans, if there are any. Another aspect that the presentations should highlight is what prompted the network wide upgrade and what benefits have been achieved. Yours filled with hope, -- +358 4567 02048 / http://www.trex.fi/ Aleksi Suhonen / TREX Regional Exchanges Oy You say "potato", I say "closest-exit."

2 1

[training] RIPE NCC Webinars - new dates
by Training Services 08 Apr '14

08 Apr '14

Dear colleagues, We are pleased to announce the launch of new dates for our Webinars. The RIPE NCC Webinars are live and take only one hour. You can interact with our trainers without leaving your desk. We focus on the topics and issues most important for LIRs. Register now at https://www.ripe.net/lir-services/training/e-learning/webinars Participation is limited to 20 people, so don't hesitate if you want to take part! If you have questions, please email <training(a)ripe.net>. We look forward to seeing you online. Kind regards, RIPE NCC Training Services

1 0

[training] RIPE NCC Webinars - new dates
by Training Services 25 Mar '14

25 Mar '14

Dear colleagues, We are pleased to announce the launch of new dates for our Webinars. The RIPE NCC Webinars are live and take only one hour. You can interact with our trainers without leaving your desk. We focus on the topics and issues most important for LIRs. Register now at https://www.ripe.net/lir-services/training/e-learning/webinars Participation is limited to 20 people, so don't hesitate if you want to take part! If you have questions, please email <training(a)ripe.net>. We look forward to seeing you online. Kind regards, RIPE NCC Training Services

1 0

[training] RIPE NCC Courses in Sofia, Bulgaria 16-17 April 2014
by Training Services 14 Mar '14

14 Mar '14

Dear Colleagues, The RIPE NCC Training Services Department invites you to register for our upcoming Training Courses in Sofia, Bulgaria: Course type: RIPE Database Training Course Date: Wednesday, 16 April 2014 Time: 09:00-17:30 Course type: IPv6 for LIRs Training Course Date: Thursday, 17 April 2014 Time: 09:00-17:30 How to register: ---------------- You can register up to two people from your LIR for each course by using the LIR Portal at: https://lirportal.ripe.net/training/courses Registration will close when maximum capacity is reached, so please register soon to ensure your attendance. The course is free of charge. We provide lunch and printed training materials. We do not cover any of your travel expenses or accommodation. We give all of our training courses in English. RIPE Database Training Course: ------------------------------ You should attend this training course if you are part of the staff of a Local Internet Registry (LIR) in the RIPE NCC Service Region. You can find more information about the course at: https://www.ripe.net/lir-services/training/courses/rdb IPv6 for LIRs Training Course: ------------------------------ You should attend this training course if you are part of the staff of a Local Internet Registry (LIR) in the RIPE NCC Service Region and if you: * Are thinking about deploying IPv6 in your organisation * Have been told you need to deploy IPv6 * Need to convince your manager that IPv6 needs to be deployed * Looked at an IPv6 address and thought it was too complicated to deploy in your network You can find more information about the course at: http://www.ripe.net/lir-services/training/courses/ipv6 If you have any questions, send an e-mail to <training(a)ripe.net>. Kind regards, RIPE NCC Training Services

1 0

[training] RIPE NCC Webinars - new dates
by Training Services 11 Mar '14

11 Mar '14

Dear colleagues, We are pleased to announce the launch of new dates for our Webinars. The RIPE NCC Webinars are live and take only one hour. You can interact with our trainers without leaving your desk. We focus on the topics and issues most important for LIRs. Register now at https://www.ripe.net/lir-services/training/e-learning/webinars Participation is limited to 20 people, so don't hesitate if you want to take part! If you have questions, please email <training(a)ripe.net>. We look forward to seeing you online. Kind regards, RIPE NCC Training Services

1 0

Call for topics/ideas for RIPE 68 (Warsaw)
by Marco Hogewoning 06 Mar '14

06 Mar '14

Dear colleagues, It is that time of the year again that we need to start thinking about the agenda for our meeting. The 68th RIPE Meeting will be held in Warsaw from 12 to 16 May. The draft meeting plan has the IPv6 Working Group scheduled for 2 sessions on the morning of Thursday 15 May. Please let us know asap if you which to present something, discuss something or have any other things you would like to see included on the agenda. We especially would like to encourage people with operational experience in running IPv6 towards customers to consider sharing their experience and knowledge for the benefit of those operators who are still facing the challenges of IPv6 deployment. Submissions can be made to ipv6-wg-chair [at] ripe [dot] net Thank you and hope to meet you all in Warsaw, Marco, David and Shane The co-Chairs of the IPv6 Working Group

1 0

Fwd: [address-policy-wg] IPv6 PA/PI - restarting discussion after failed 2013-06 proposal
by Elvis Velea 04 Mar '14

04 Mar '14

Hi everyone, I am forwarding this message to the IPv6-WG as well as it involves changes that I/we may propose to make to the IPv6 Policy. Please join the discussion and comment; however, I would like to kindly ask you to send your replies to the AP-WG for the ease of collecting the feedback. cheers, elvis -------- Original Message -------- Subject: [address-policy-wg] IPv6 PA/PI - restarting discussion after failed 2013-06 proposal Date: Tue, 04 Mar 2014 02:50:52 +0100 From: Elvis Daniel Velea <elvis(a)v4escrow.net> Organization: V4Escrow, LLC To: Address Policy Working Group <address-policy-wg(a)ripe.net> Hi everyone, 2013-06 has failed to become policy and we all understand that it presented such big changes that it became too complex. I would like to restart that discussion and see what are the problems/failures of the IPv6 policies (both PI and PA) and come up with a proposal to fix these problems. I'd like to start with the first 4 problems that I have noticed: #1. In IPv4 a PI user can connect a customer to it's network or allow a customer to use a dedicated server using one IP address. This limitation had been extended to up to a /29 (in case redundant connections were offered - ie:VRRP) but most of the cases I have encountered were using either a /32 or a /30. Currently, the IPv6 policy states that the minimum a customer should use is a /64. And because the minimum per customer is a /64, when someone would actually use IPv6 PI for a customer, it would make an assignment of a subnet and violate the policy. I've heard of people using /128s for the servers of their customers and sharing the same vlan amongst multiple customers in the same /64. Others are just requesting a/48 PI and expect never to come back for more (therefore, could not care less about policies). Others just know that the RIPE NCC has no way to see if they sub-assign parts of the /48 PI, so they just request a /48 PI, promise never to sub-assign and later on, forget about the promise. Therefore, I propose that the first change we make to the IPv6 PI policy is that where a /64 could be used per customer (regardless of the service offered to that customer) only if it is registered properly in the RIPE Database. The change would allow PI users to sub-assign in IPv6, but only small (?) amounts of space and only if they actually register the assignment. #2. Second problem I've noticed is the fact that LIRs can receive /32s (and up to /29s) only by asking. On the other hand, if you do not want to become a RIPE NCC member or just can not, you are forced to use IPv6 - a /48. Additionally, this IPv6 PI can only be used for your own infrastructure and not to provide any service (other than SaaS) to your customers without violating the policy (see problem statement #1). One could request more than a /48 but it would need to demonstrate that it has two or more sites that have different routing policies or demonstrate that it has a need for more than 65K subnets. I would like to introduce the IPv6 PI ALLOCATION. This time, the PI allocation could be made to the PI user and the user could actually make assignments from it. The PI allocation would be just as large as the PA Allocation and the price for it would be no less than 50% of the membership fee (Off course, the fees can only be voted upon at the GM and the example is just purely theoretical). This would introduce that 'additional registry' which we never knew how to name during the discussions of 2013-06 and would allow PI users to request/receive a /29 from which they could make assignments. Everyone will say that /32 or /29 will become the new /48. Well, that may be true, on the other hand, it may be the price that could keep the number of large PI Allocations low. Additionally, we could add an arbitrary limit. For example, say that you can request an IPv6 PI Allocation only if you already have x hundred customers that will receive an assignment from you immediately. #3. Minimum assignment size The policy says that the minimum assignment size is a /64. However, the RIPE Database does not enforce this rule and I have seen /128s registered. for example: inet6num: 2001:b70:f000::/112 inet6num: 2001:820:0:1:1::1000/116 inet6num: 2a01:2f0f:ffff:ffff:100:1000::1/128 There are over 700 inet6num objects registered which are below a /64. If we take the policy literally, all these assignments currently violate the policy. Therefore, I think we should either change/remove the minimum assignment size or have the RIPE Database block the creation of any IPv6 assignment smaller than a /64. #4. fix utilisation and hd-ratio vs assignment size While the HD-ratio is being calculated in terms of /56s, the policy says (at point 5.4.1.) that the minimum assignment that can be made is a /64. Furthermore, as you can see above, /128s can be registered in the RIPE Database as well. If we will continue allowing the registration of less than /56 assignments, it will be difficult to almost impossible to the IPRAs to actually calculate what is the HD-ratio of an IPv6 allocation. While now it is too early to see additional IPv6 allocation requests, if we keep doing things as we've been doing for the past years, we will end up in a few years with a huge mess in the registry and the impossibility to calculate the HD-ratio without applying random procedures. A very simple and quick fix would be to say that if any prefix is registered, the whole /56 that includes the prefix is in use. But then, we may see people registering/using /128s from different /56s just to reach the HD-ratio for an additional allocation. Would that still be considered an efficient usage? An other option would be to change the HD-ratio calculation to the actual number of IP addresses used and consider all the IP addresses from an assignment used if correctly registered in the RIPE Database. Once we have worked out whether these 4 issues are indeed flaws in the policy or not and whether we want them fixed or not, I would like to hear your opinion in what else should be modified in the IPv6 policies. I will then collect all the feedback, probably present it at the next RIPE Meeting, and start to discuss an other approach/policy proposal to achieve what 2013-06 failed to achieve. cheers, elvis -- <http://v4escrow.net> Elvis Daniel Velea Chief Business Analyst Email: elvis(a)V4Escrow.net <mailto:elvis@v4escrow.net> US Phone: +1 (702) 475 5914 EU Phone: +3 (161) 458 1914 Recognised IPv4 Broker/Facilitator in: This message is for the designated recipient only and may contain privileged, proprietary, or otherwise private information. If you have received this email in error, please notify the sender immediately and delete the original.Any other use of this email is strictly prohibited.

1 0

[training] RIPE NCC Webinars - new dates
by Training Services 25 Feb '14

25 Feb '14

Dear colleagues, We are pleased to announce the launch of new dates for our Webinars. The RIPE NCC Webinars are live and take only one hour. You can interact with our trainers without leaving your desk. We focus on the topics and issues most important for LIRs. Register now at https://www.ripe.net/lir-services/training/e-learning/webinars Participation is limited to 20 people, so don't hesitate if you want to take part! If you have questions, please email <training(a)ripe.net>. We look forward to seeing you online. Kind regards, RIPE NCC Training Services

1 0

[training] RIPE NCC Training Courses April-June 2014
by Training Services 18 Feb '14

18 Feb '14

Dear Colleagues, Our training team travels the RIPE NCC service region to deliver training courses to our members without any additional cost. Over the next few months, we'll be in St. Julian's, Zagreb, Sofia, Brussels, Edinburgh, Tehran, Helsinki, Moscow, Kiel, Almaty, Reykjavik, Geneva. Visit the following page to register and to check which training courses we are giving in your area: https://lirportal.ripe.net/training/courses The RIPE NCC delivers the following training courses: - LIR Training Course - Database Training Course - IPv6 for LIRs Training Course - Routing Security Training Course - 3 day Deploying IPv6 Training Course (New) - DNSSec Training Course (New) For more information visit: https://www.ripe.net/lir-services/training/courses With kind regards, Rumy Spratley-Kanis Training Services Manager

1 0

[training] RIPE NCC Webinars - new dates
by Training Services 11 Feb '14

11 Feb '14

Dear colleagues, We are pleased to announce the launch of new dates for our Webinars. The RIPE NCC Webinars are live and take only one hour. You can interact with our trainers without leaving your desk. We focus on the topics and issues most important for LIRs. Register now at https://www.ripe.net/lir-services/training/e-learning/webinars Participation is limited to 20 people, so don't hesitate if you want to take part! If you have questions, please email <training(a)ripe.net>. We look forward to seeing you online. Kind regards, RIPE NCC Training Services

1 0

Fwd: RACI @ RIPE 68 - Opportunity for Students and Researchers
by Marco Hogewoning 23 Jan '14

23 Jan '14

If you are or know somebody doing research that is somewhat Internet related (doesn’t have to be IPv6 :). RIPE NCC has again put a call out for applicants to the RACI programme. And I am sure that I can speak for my fellow chair that we are happy to consider any IPv6 related material for inclusion in our work group. MarcoH (in his role as co-chair of this working group) > Dear colleagues, > > The RIPE Academic Cooperation Initiative (RACI) is providing a number of > students and researchers the opportunity to participate at RIPE 68 in > Warsaw from 12-16 May. We are offering packages that include meeting > registration and paid travel and accommodation, and we are currently > seeking applications from across the RIPE NCC service region. > > We would like to ask for your assistance to raise awareness of the RACI > program. Many in the RIPE community have strong connections with > academic institutions, and we are keen to make those institutions and > their students aware of this great opportunity. > > RACI gives students and researchers the opportunity to present their > work in front of some the leading technical figures in the Internet > world, receive feedback on their research from experts and have their > work published on the RIPE Labs website for community feedback. The RACI > program also benefits the RIPE community by introducing newer members to > the community who can give interesting presentations at RIPE Meetings > that might not otherwise be seen. > > The initiative is coordinated with the RIPE Programme Committee to allow > the RACI participants to present their research, either during > plenary/working group sessions, or in lightning talks at other > designated sessions. > > Students and researchers may wish to present on any topic relevant to > the RIPE community, including (but not limited to): > > - Network measurement and analysis > - IPv6 deployment > - BGP routing > - Network security > - Internet governance > > Students and researchers who are interested in RACI sponsorship can fill > out the application form on the RIPE 68 webpages: > https://ripe68.ripe.net/programme/raci/application/ > > All applications must be received by Friday, 25 April 2014. Applicants > will be informed about the status of their application by Friday, 2 May > 2014. Any applications received after 25 April 2014 will be considered > for RACI at RIPE 69, to be held in London from 3-7 November 2014. > > More information on RACI is available at: > https://ripe68.ripe.net/programme/raci/ > > Best regards, > > The RACI Coordination Team > RIPE NCC

1 0

[training] RIPE NCC Webinars - new dates
by Training Services 20 Jan '14

20 Jan '14

Dear colleagues, We are pleased to announce the launch of new dates for our Webinars. The RIPE NCC Webinars are live and take only one hour. You can interact with our trainers without leaving your desk. We focus on the topics and issues most important for LIRs. Register now at https://www.ripe.net/lir-services/training/e-learning/webinars Participation is limited to 20 people, so don't hesitate if you want to take part! If you have questions, please email <training(a)ripe.net>. We look forward to seeing you online. Kind regards, RIPE NCC Training Services

1 0

RIPE 554 Errata Page
by Wilhelm Boeddinghaus 17 Jan '14

17 Jan '14

Dear colleagues, as shortly discussed in Dublin I suggest to set up an errata page for the RIPE 554 document. Errors have been found, and we cannot change anything in the document without getting a new RIPE document number. But having to many different versions of the document confuses our audience. A errata page would make it possible to document minor but important changes of the content of the document. If the group says "yes" we could ask RIPE to help with a page like this. It should be easily reachable from the download page of RIPE554. Kind regards, Wilhelm Boeddinghaus

15 33

New on RIPE Labs: How Many RIPE Atlas Probes Can Resolve IPv6-only Domain Names?
by Mirjam Kuehne 13 Jan '14

13 Jan '14

Dear colleagues, Please find a new article on RIPE Labs submitted by Stéphane Bortzmeyer: How Many RIPE Atlas Probes Can Resolve IPv6-only Domain Names? https://labs.ripe.net/Members/stephane_bortzmeyer/how-many-ripe-atlas-probe… Kind regards, Mirjm Kuehne RIPE NCC

1 0

Follow up on RIPE67 IPv6 Only experiment
by Marco Hogewoning 10 Jan '14

10 Jan '14

Dear colleagues, Just to let you know that, based on experience in Athens, I put up a blogpost on Circle-ID about running IPv6 only. http://www.circleid.com/posts/20131212_are_we_ready_to_switch_off_ipv4/ Would also love to hear from you wether we should aim to repeat this experiment in Warsaw. Or maybe you have an idea of something else that you think is worth trying, please let us know. Best, MarcoH -- "Life is like riding a bicycle. To keep your balance you must keep moving" -- Albert Einstein

8 9

[training] RIPE NCC Webinars - new dates
by Training Services 06 Jan '14

06 Jan '14

Dear colleagues, We are pleased to announce the launch of new dates for our Webinars. The RIPE NCC Webinars are live and take only one hour. You can interact with our trainers without leaving your desk. We focus on the topics and issues most important for LIRs. Register now at https://www.ripe.net/lir-services/training/e-learning/webinars Participation is limited to 20 people, so don't hesitate if you want to take part! If you have questions, please email <training(a)ripe.net>. We look forward to seeing you online. Kind regards, RIPE NCC Training Services

1 0

Re: [ipv6-wg] ipv6-wg Digest, Vol 27, Issue 4
by behroz abbaszadeh 20 Nov '13

20 Nov '13

Dear Marco thank you very much, Is it possible to upload some documents of this meeting like PDF format of presentations and ... Cheers Behrouz ________________________________ From: "ipv6-wg-request(a)ripe.net" <ipv6-wg-request(a)ripe.net> To: ipv6-wg(a)ripe.net Sent: Wednesday, November 13, 2013 2:30 PM Subject: ipv6-wg Digest, Vol 27, Issue 4 Send ipv6-wg mailing list submissions to ipv6-wg(a)ripe.net To subscribe or unsubscribe via the World Wide Web, visit https://www.ripe.net/mailman/listinfo/ipv6-wg or, via email, send a message with subject or body 'help' to ipv6-wg-request(a)ripe.net You can reach the person managing the list at ipv6-wg-owner(a)ripe.net When replying, please edit your Subject line so it is more specific than "Re: Contents of ipv6-wg digest..." Today's Topics: 1. Re: 14th Saudi Arabian Task Force Meeting (Erika.Hersaeus(a)pts.se) ---------------------------------------------------------------------- Message: 1 Date: Tue, 12 Nov 2013 17:53:08 +0000 From: <Erika.Hersaeus(a)pts.se> Subject: Re: [ipv6-wg] 14th Saudi Arabian Task Force Meeting To: <marcoh(a)ripe.net>, <ipv6-wg(a)ripe.net> Message-ID: <F9B35F1FF22AED4B9198995E2F969B801D2F6596@maildb01> Content-Type: text/plain; charset="iso-8859-1" Marco, Thank you very much for the report! Greetings, Erika -----Ursprungligt meddelande----- Fr?n: ipv6-wg-bounces(a)ripe.net [mailto:ipv6-wg-bounces@ripe.net] F?r Marco Hogewoning Skickat: den 11 november 2013 14:13 Till: ipv6-wg(a)ripe.net IPv6 ?mne: [ipv6-wg] 14th Saudi Arabian Task Force Meeting [a copy of this report will also be made available on http://labs.ripe.net/] Dear Colleagues, The RIPE NCC recently participated in a meeting of the Saudi Arabian Task Force. A well-attended event, it included presentations and discussions about IPv6 deployment strategies, as well as presentations by operators reporting back on their successful IPv6 pilot projects and plans to roll out IPv6 in the first half of 2014. The 14th Saudi Arabian Task Force Meeting, was held on November 7th, 2014 in Riyadh. This successful event, hosted by the Communication and Information Technology Commission (CITC), had over 40 participants from the Saudi Arabian Internet Industry as well as representatives from government institutions and enterprises, discussing the deployment of IPv6. The meeting was preceded by a three-day MENOG IPv6 Roadshow. 21 participants took part in this technical training, learning how to configure and deploy IPv6 in their networks. Dr Ibraheem Al Furaih (CITC), in his presentation, highlighted the fact that the number of Internet users in Saudi Arabia is still rapidly growing, surpassing 16.5 million in the first half of 2013. With the global and regional IPv4 address pool depleted, a rapid deployment of IPv6 is necessary in sustaining future growth and to enable the remaining 45% of the population to also connect to the Internet. He also announced that, following the decision of the Task Force to put more focus on enterprise networks, CITC will run a pilot in which four enterprises will be supported in enabling IPv6 on all their customer-facing services. Ashraf Sattar (STC) reported back on a successful pilot project in enabling IPv6 on their DSL network. With the tests completed, they expect to begin rolling out IPv6 as a production service in the first quarter of 2014, followed by a planned deployment of IPv6 in the FTTH network in the second quarter. He also highlighted some of the design challenges that mobile operators are facing, concluding that a single stack approach, in which an IPv6-only service is complemented by an IPv6 to IPv4 translation service, is the most promising solution. However, as he remarked, such a solution would put limits on the peer-to-peer communication in between hosts. Motaz Alturayef (Mobily) provided the attendees with an overview of some of the security challenges in deploying IPv6. But as he mentioned, the fact that a lot of devices and software now have IPv6 capabilities, also poses a threat in that IPv6 traffic might escape to the attention of the security teams and intrusion detection systems. Amer Mustafa (GAMA) presented on the successful projects they did with several of their customers. Their segmented approach that focusses on different parts of the organisation allows for the deployment of IPv6 in only 90 days. He stated that convincing the business executives and decision makers was the biggest challenge in the fast deployment IPv6. A presentation by Marco Hogewoning (RIPE NCC) showed statistics about the deployment of IPv6 in Saudi Arabia taken from the various measurement programs, comparing them to those of other countries in the Middle East region, as well as to the global deployment statistics. He also highlighted that, while the IPv4 pool is depleted, there is still an ongoing need in maintaining the registration data of IPv4 resources to be accurate and complete. Gert Doering in his role as IPv6 Consultant explained the various options available within the RIPE NCC Service Region for obtaining IPv6 resources. Using several examples, he highlighted some of the drawbacks and benefits of those options for companies of various sizes. He invited the participants to take part in discussions in the RIPE Address Policy Working Group, which have been addressing several potential changes to IPv6 and IPv4 address policy. In conjunction with the IPv6 events, the RIPE NCC also invited its Saudi Arabian members, together with other stakeholders, for an informal dinner to discuss ongoing issues and the needs of the membership. The attendees expressed the need for further activities in IPv6 training, not only on a technical level but also for executive-level employees. They also welcomed the continued efforts made by the RIPE NCC to increase its presence in the Middle East, noting the expansion of the Dubai office to include more staff. All the presentations, as well as more information about the Saudi Arabian IPv6 Task Force, are available on their website, via http://www.ipv6.sa./The next meeting of the Task Force is planned to take place in April or May 2014. If you have any questions regarding this event or would like RIPE NCC staff to contribute to your IPv6 events please contact us via ipv6actnow [at] ripe [dot] net On behalf of the RIPE NCC External Relations Team, Marco Hogewoning End of ipv6-wg Digest, Vol 27, Issue 4 **************************************

2 1

[training] RIPE NCC Training Courses January-March 2014
by Training Team 19 Nov '13

19 Nov '13

Dear Colleagues, Our training team travels the RIPE NCC service region to deliver training courses to our members without any additional cost. Over the next few months, we'll be in Lisbon, Frankfurt, Busto Arsizio, Manamah, St. Petersburg, Tallinn, London, Warsaw, Copenhagen, Amsterdam, Bucharest. Visit the following page to register and to check which training courses we are giving in your area: https://lirportal.ripe.net/training/courses The RIPE NCC delivers the following training courses: - LIR Training Course - RIPE Database Training Course - IPv6 for LIRs Training Course - Routing Security Training Course For more information visit: http://www.ripe.net/lir-services/training/courses With kind regards, Rumy Spratley-Kanis Training Services Manager

1 0

14th Saudi Arabian Task Force Meeting
by Marco Hogewoning 12 Nov '13

12 Nov '13

[a copy of this report will also be made available on http://labs.ripe.net] Dear Colleagues, The RIPE NCC recently participated in a meeting of the Saudi Arabian Task Force. A well-attended event, it included presentations and discussions about IPv6 deployment strategies, as well as presentations by operators reporting back on their successful IPv6 pilot projects and plans to roll out IPv6 in the first half of 2014. The 14th Saudi Arabian Task Force Meeting, was held on November 7th, 2014 in Riyadh. This successful event, hosted by the Communication and Information Technology Commission (CITC), had over 40 participants from the Saudi Arabian Internet Industry as well as representatives from government institutions and enterprises, discussing the deployment of IPv6. The meeting was preceded by a three-day MENOG IPv6 Roadshow. 21 participants took part in this technical training, learning how to configure and deploy IPv6 in their networks. Dr Ibraheem Al Furaih (CITC), in his presentation, highlighted the fact that the number of Internet users in Saudi Arabia is still rapidly growing, surpassing 16.5 million in the first half of 2013. With the global and regional IPv4 address pool depleted, a rapid deployment of IPv6 is necessary in sustaining future growth and to enable the remaining 45% of the population to also connect to the Internet. He also announced that, following the decision of the Task Force to put more focus on enterprise networks, CITC will run a pilot in which four enterprises will be supported in enabling IPv6 on all their customer-facing services. Ashraf Sattar (STC) reported back on a successful pilot project in enabling IPv6 on their DSL network. With the tests completed, they expect to begin rolling out IPv6 as a production service in the first quarter of 2014, followed by a planned deployment of IPv6 in the FTTH network in the second quarter. He also highlighted some of the design challenges that mobile operators are facing, concluding that a single stack approach, in which an IPv6-only service is complemented by an IPv6 to IPv4 translation service, is the most promising solution. However, as he remarked, such a solution would put limits on the peer-to-peer communication in between hosts. Motaz Alturayef (Mobily) provided the attendees with an overview of some of the security challenges in deploying IPv6. But as he mentioned, the fact that a lot of devices and software now have IPv6 capabilities, also poses a threat in that IPv6 traffic might escape to the attention of the security teams and intrusion detection systems. Amer Mustafa (GAMA) presented on the successful projects they did with several of their customers. Their segmented approach that focusses on different parts of the organisation allows for the deployment of IPv6 in only 90 days. He stated that convincing the business executives and decision makers was the biggest challenge in the fast deployment IPv6. A presentation by Marco Hogewoning (RIPE NCC) showed statistics about the deployment of IPv6 in Saudi Arabia taken from the various measurement programs, comparing them to those of other countries in the Middle East region, as well as to the global deployment statistics. He also highlighted that, while the IPv4 pool is depleted, there is still an ongoing need in maintaining the registration data of IPv4 resources to be accurate and complete. Gert Doering in his role as IPv6 Consultant explained the various options available within the RIPE NCC Service Region for obtaining IPv6 resources. Using several examples, he highlighted some of the drawbacks and benefits of those options for companies of various sizes. He invited the participants to take part in discussions in the RIPE Address Policy Working Group, which have been addressing several potential changes to IPv6 and IPv4 address policy. In conjunction with the IPv6 events, the RIPE NCC also invited its Saudi Arabian members, together with other stakeholders, for an informal dinner to discuss ongoing issues and the needs of the membership. The attendees expressed the need for further activities in IPv6 training, not only on a technical level but also for executive-level employees. They also welcomed the continued efforts made by the RIPE NCC to increase its presence in the Middle East, noting the expansion of the Dubai office to include more staff. All the presentations, as well as more information about the Saudi Arabian IPv6 Task Force, are available on their website, via http://www.ipv6.sa. The next meeting of the Task Force is planned to take place in April or May 2014. If you have any questions regarding this event or would like RIPE NCC staff to contribute to your IPv6 events please contact us via ipv6actnow [at] ripe [dot] net On behalf of the RIPE NCC External Relations Team, Marco Hogewoning

2 1

Re: [ipv6-wg] ipv6-wg Digest, Vol 26, Issue 13
by behroz abbaszadeh 05 Nov '13

05 Nov '13

I read the presentation; It has some benefits and some problems. This kind of IPv6 addressing maybe decrease network security and it will give opportunity to hackers to access to the special networks by special IPv6 address scanning. Thank you Behrouz ________________________________ From: "ipv6-wg-request(a)ripe.net" <ipv6-wg-request(a)ripe.net> To: ipv6-wg(a)ripe.net Sent: Sunday, October 27, 2013 2:30 PM Subject: ipv6-wg Digest, Vol 26, Issue 13 Send ipv6-wg mailing list submissions to ipv6-wg(a)ripe.net To subscribe or unsubscribe via the World Wide Web, visit https://www.ripe.net/mailman/listinfo/ipv6-wg or, via email, send a message with subject or body 'help' to ipv6-wg-request(a)ripe.net You can reach the person managing the list at ipv6-wg-owner(a)ripe.net When replying, please edit your Subject line so it is more specific than "Re: Contents of ipv6-wg digest..." Today's Topics: 1. Re: 96 more bits... time for some magic after all? (Yannis Nikolopoulos) 2. Re: 96 more bits... time for some magic after all? (Benedikt Stockebrand) 3. Re: 96 more bits... time for some magic after all? (Yannis Nikolopoulos) ---------------------------------------------------------------------- Message: 1 Date: Sat, 26 Oct 2013 15:52:34 +0300 From: Yannis Nikolopoulos <dez(a)otenet.gr> Subject: Re: [ipv6-wg] 96 more bits... time for some magic after all? To: ipv6-wg(a)ripe.net Message-ID: <526BBB12.1090705(a)otenet.gr> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Hello, On 10/25/2013 06:53 PM, S.P.Zeidler wrote: > Thus wrote Shane Kerr (shane(a)time-travellers.org): > >> We saw two presentations by network architects at the RIPE meeting that >> used bits in their IPv6 addressing plan to carry meaning beyond simple >> network topology and packet routing. >> >> For example, declaring a specific bit in the address to be 1 for voice >> traffic or 0 otherwise. > [...] > >> What should we do about it? > As a RIR, nothing. what about as one of RIPE's WGs? Should we go on and produce a BCP document of some kind? As the author of this addressing plan (https://ripe67.ripe.net/presentations/222-ripe67-yanodd-ipv6-addressing.pdf) , my main motivation for presenting it was to show that it is possible to encode basic information in an addressing plan (without wasting too much space) and still keep it simple . For example, even IPv4 addressing plans were location-aware, that's nothing new. Well, its even easier and more effective in IPv6 addressing, because of the number of bits available. As far as encoding service type, no space is wasted because it is encoded after the /56 boundary ;) , even making it possible for QOS. As I mentioned in the presentation, this is our 3rd or 4th try over the past ~10 years. So far, with the help of some basic heuristics, it seems to be working out fine cheers, Yannis > > Otherwise: violations of the KISS principle are rarely a good idea. > In this case, you might find out that you snuck yourself into a > straightjacket a few years down the line. > > regards, > spz ------------------------------ Message: 2 Date: Sun, 27 Oct 2013 07:54:42 +0000 From: Benedikt Stockebrand <bs(a)stepladder-it.com> Subject: Re: [ipv6-wg] 96 more bits... time for some magic after all? To: Roger J?rgensen <rogerj(a)gmail.com> Cc: "ipv6-wg(a)ripe.net IPv6" <ipv6-wg(a)ripe.net> Message-ID: <87ob6bkv25.fsf(a)stepladder-it.com> Content-Type: text/plain; charset=utf-8 Hi Roger and list, On Fri, Roger J?rgensen <rogerj(a)gmail.com> writes: > Oct 25, 2013 at 5:24 PM, Benedikt Stockebrand > <bs(a)stepladder-it.com> wrote: >> [...] >> More important however is the question how to deal with them if /when >> they show up because they have unnecessarily "depleted" their address >> assignment thanks to encoding stuff in it. >> [...] > If they run out due to size and growth, and they haven't wasted space, > used their available /29 wisely by every advice given...give them > another prefix. That's what I meant by "unnecessarily 'depleted'". If they actually grow beyond their /29 or whatever, let them have another prefix. What I wouldn't want to see however is that some big player gets some extra address space because they wasted their existing one. Once that happens, everyone will demand the same. And yes, I've had these discussions. In particular, the idea to bit-encode the services (i.e. significant port numbers) somewhere in the subnet prefix. Eventually these people decided "well, we have a /12 for IPv4, so it's only fair we also get a /12 for IPv6". At that point I pretty much gave up and told them to request that from their RIR... > One way to waste is to give every single customer a /48 when you are > really really big. /56 work just fine really, even for techies like me :) Sorry, but I disagree on that. A /56 is fine for today's requirements, but if this hype about the "Internet of Things" really takes off and you want to put things into different subnets, a /56 may occasionally be a problem even for consumer households. Not today, but think anything from ten to fourty years. > However IPv6 is big enough that most people will not feel any pain with > it, some however will start to get into trouble in 5-10years time, guess > more like around in 7 years. The reason? They made a too static model > on how they wanted to use their available space. Agreed, but... > But you have to be big to get into that trouble. I don't see any reason why size has to do with it. The problem is more of a ratio between size and allocated address space---and the technical knowledge around. (And no, unlike somebody else on this list I don't believe it feasible for a consumer to call in a CCIE every time they need some networked deviced hooked up.) > There was major discussion just to get that /56 into the documents. > Upto that point there was /64 pr.LAN, /48 for the rest. Now we're relaxing > it even more. Are discussion on moving away from /64's on the wire to... If /64 is given up, all sorts of shit will happen. It has been part of the specs for long enough that a number of implementations will rely on it. It's not just autoconfiguration, but when it comes to embedded system/microcontroller implementations, changing that is rather difficult. Additionally, anything that can be (mis-)configured exponentially adds (or rather, multiplies) to the frustration potential for end users. > Doesn't this sound like A/B/C-class network vs CIDR? You mean VLSM, I assume? > * For one server running in the cloud I got a /112, that work just fine really. ...until you do an upgrade on the server that relies on RFC 4291. > * Somewhere else I'm using a /50 on the wire, that also work just fine. Same issue. Yes, at least some implementations support that right now, but you shouldn't rely on that. Additionally, for whoever may have to run that system further later on you set up some ugly surprise that way. > * I have tried to use an entire /48 but failed. I tried to build my > own network with VPN, routings and everything across the different > servers and routers I have spread around. That /48 was big enough for > me:) Oha. So you have too many machines to fit into a /64 in a single subnet? > * I tried to build a big routed, multisite network using a /56, that > also worked upto a certain size :) Sorry, I don't get what you want to say there. Cheers, Benedikt -- Business Grade IPv6 Consulting, Training, Projects Benedikt Stockebrand, Dipl.-Inform. http://www.stepladder-it.com/ ------------------------------ Message: 3 Date: Sun, 27 Oct 2013 12:02:46 +0200 From: Yannis Nikolopoulos <dez(a)otenet.gr> Subject: Re: [ipv6-wg] 96 more bits... time for some magic after all? To: Benedikt Stockebrand <bs(a)stepladder-it.com> Cc: "ipv6-wg(a)ripe.net IPv6" <ipv6-wg(a)ripe.net> Message-ID: <526CE4C6.9060003(a)otenet.gr> Content-Type: text/plain; charset=UTF-8; format=flowed On 10/27/2013 09:54 AM, Benedikt Stockebrand wrote: > Hi Roger and list, > > On Fri, Roger J?rgensen <rogerj(a)gmail.com> writes: > >> Oct 25, 2013 at 5:24 PM, Benedikt Stockebrand >> <bs(a)stepladder-it.com> wrote: >> What I wouldn't want to see however is that some big player gets some >> extra address space because they wasted their existing one. Once that >> happens, everyone will demand the same. that's the second time I read this in this thread. Why would this happen? All allocations are subject to RIR policy >> One way to waste is to give every single customer a /48 when you are >> really really big. /56 work just fine really, even for techies like me :) > Sorry, but I disagree on that. A /56 is fine for today's requirements, > but if this hype about the "Internet of Things" really takes off and you > want to put things into different subnets, a /56 may occasionally be a > problem even for consumer households. Not today, but think anything > from ten to fourty years. 40 years from now? Many, more significant changes will probably overshadow this. Otherwise, 256 different policies in a home sound just fine > >> There was major discussion just to get that /56 into the documents. >> Upto that point there was /64 pr.LAN, /48 for the rest. Now we're relaxing >> it even more. Are discussion on moving away from /64's on the wire to... > It's not just autoconfiguration, but when it comes to embedded > system/microcontroller implementations, changing that is rather > difficult. care to elaborate on that? >> * For one server running in the cloud I got a /112, that work just fine really. > ...until you do an upgrade on the server that relies on RFC 4291. > >> * Somewhere else I'm using a /50 on the wire, that also work just fine. > Same issue. Yes, at least some implementations support that right now, > but you shouldn't rely on that. Additionally, for whoever may have to > run that system further later on you set up some ugly surprise that way. again, care to elaborate a bit? How's a /50 not compliant with RFC 4291? > Cheers, Benedikt cheers, Yannis End of ipv6-wg Digest, Vol 26, Issue 13 ***************************************

1 0

96 more bits... time for some magic after all?
by Shane Kerr 31 Oct '13

31 Oct '13

All, [ gah... hit the wrong key and sent this unfinished ] We saw two presentations by network architects at the RIPE meeting that used bits in their IPv6 addressing plan to carry meaning beyond simple network topology and packet routing. For example, declaring a specific bit in the address to be 1 for voice traffic or 0 otherwise. There are motivations for doing this, which may or may not be valid in any particular case. There are ways to lessen the amount of addresses consumed by this (for example by assigning /56 instead of /48 to end users). But I think that the important thing is that we have historically not considered this sort of use with address allocation policy. In face, RFC 2050bis was *just* published as RFC 7020: http://datatracker.ietf.org/doc/rfc7020/ This includes the long-standing historical goals of conservation, aggregation, and accuracy. Using bits in IPv6 networks for other purposes is orthogonal to those goals. What should we do about it? Cheers, -- Shane

11 22

[training] RIPE NCC Webinars - new dates
by Training Team 29 Oct '13

29 Oct '13

Dear colleagues, We are pleased to announce the launch of new dates for our Webinars. The RIPE NCC Webinars are live and take only one hour. You can interact with our trainers without leaving your desk. We focus on the topics and issues most important for LIRs. Register now at https://www.ripe.net/lir-services/training/e-learning/webinars Participation is limited to 20 people, so don't hesitate if you want to take part! If you have questions, please email <training(a)ripe.net>. We look forward to seeing you online. Kind regards, RIPE NCC Training Services

1 0

96 more bits... time for some magic after all?
by Shane Kerr 26 Oct '13

26 Oct '13

All, We saw two presentations by network architects at the RIPE meeting that used bits in their IPv6 addressing plan to carry meaning beyond simple network topology and packet routing. For example, declaring a specific bit in the address to be 1 for voice traffic or 0 otherwise. There are motivations for doing this, which may or may not be valid in any particular case. There are ways to lessen the amount of addresses consumed by this (for example by assigning /56 instead of /48 to end users). But I think that the important thing is that we have historically not considered this sort of use with address allocation policy. In face, RFC 2050bis was *just* published as RFC 7050: Cheers, -- Shane

2 1

Request for feedback on IETF I-D draft-v6ops-vyncke-balanced-ipv6-security
by Anfinsen, Ragnar 22 Oct '13

22 Oct '13

Dear all, The authors would like to invite the community to review and comment on IETF I-D draft-v6ops-vyncke-balanced-ipv6-security. <snip> Abstract This document describes how an IPv6 residential Customer Premise Equipment (CPE) can have a balanced security policy that allows for a mostly end-to-end connectivity while keeping the major threats outside of the home. It is based on an actual IPv6 deployment by Swisscom and proposes to allow all packets inbound/outbound EXCEPT for some layer-4 ports where attacks and vulnerabilities (such as weak passwords) are well-known. </snip> http://tools.ietf.org/html/draft-v6ops-vyncke-balanced-ipv6-security We have received feedback from the IETF community that there should not be any explicit list of ports to be blocked in the document. The authors feels that this list should be maintained by a neutral internet body, however we need suggestions from the community on who this could be solved. So basically there are a few options on who the list could be managed; * Let the ISP/Vendor define and maintain the list by them selves. * Let the community maintain such list using consensus. * Ask a neutral internet body (insert favorite here) to manage the list based on the actual threat picture. Please keep in mind that this draft is not meant to define an IDS/IPS style of functionality. We are only looking for how to solve the IPv6 firewall default on/off problem. This draft only covers the default list provided when the customer is begin connected. The customer can, depending on the ISP's policy, fully administer the firewall rules. Best Regards The authors; Eric Vyncke, Cisco Martin Gysi, Swisscom Guillaume Leclanche, Swisscom Ragnar Anfinsen, Altibox

2 1

IPv6 Only Network at RIPE 67
by Marco Hogewoning 21 Oct '13

21 Oct '13

"It's an IPv6 Working Group Initiative!" Dear Colleagues, Following the discussion at RIPE 66, the IPv6 Working Group is happy to provide you with an experimental network that is configured to offer only IPv6. This experimental network is not supported by the RIPE NCC or RIPE 67 Technical Team. We encourage everybody to connect to this network and test any websites, applications, hardware and software, and verify that they operate when an IPv4 address is no longer available. Important: This network is an experiment and is offered on a best-effort basis. We will try to maintain sufficient service levels and are happy to look into and help troubleshoot any issues you may encounter. If you rely on network connectivity for important business, we recommend you connect to the regular RIPE Meeting network. How to connect: - Make sure IPv6 is enabled on your device - Connect to SSID: IPV6ONLYEXP - Enter the password: iknowbesteffort The network provides NAT64 translation to connect to legacy services – please use the name server provided by the network to make use of this feature. We suggest you leave IPv4 enabled as this will be the scenario for most end users. Feedback: Please see Marco Hogewoning or Andrew Yourtchenko for any issues. We invite you to attend the IPv6 Working Group session on Thursday from 9:00-10:30 to discuss the results of this experiment. And of course you are welcome to follow up on this mailing list. Greetings, Marco Hogewoning Andrew Yourtchenko

12 34