- ipv6-wg - mailman.ripe.net

New on RIPE Labs: An Overview on IPv6 Security
by Mirjam Kuehne 18 Jun '13

18 Jun '13

Dear colleagues, Please see a new article on RIPE Labs, contributed by Johannes Weber who wrote his master's thesis on IPv6 Security: IPv6 Security - An Overview https://labs.ripe.net/Members/johannes_weber/ipv6-security-an-overview Kind regards, Mirjam Kuehne RIPE NCC

1 0

IPv6 addressing for broadband-connected remote sites
by stuart.dale＠ba.com 13 Jun '13

13 Jun '13

Is anyone aware of any thinking that has been done on how IPv6 addressing would work for enterprises with remote sites that are broadband connected? In the IPv4 we would deploy a router terminating a VPN tunnel back to our datacentres, with selected traffic being broken out locally to the internet, reliant on NAT'ing the client source addresses. In an IPv6 world how would this work? Since there's no capability of NAT'ing an IPv6 address to another IPv6 address, would it be better to address the clients within sites using PA addressing from the local ISP? This would lose the benefits of having sites allocated from a contiguous (summarisable) address space within the enterprise . On the other hand, if we addressed the sites from our PA address block, then unless I'm missing something, local ISP's would be unlikely to want to route to it as the addresssing wouldn't be in their block, would by definition almost certainly be a small subnet (probably single /64), and wouldn't fit into their standard provisioning model. Any comments / suggestions would be most welcome. ------------------------------------------------------------------------------------------------------------ Get the best from British Airways at ba.com http://www.ba.com -- This message is private and confidential and may also be legally privileged. If you have received this message in error, please email it back to the sender and immediately permanently delete it from your computer system. Please do not read, print, re-transmit, store or act in reliance on it or any attachments. British Airways may monitor email traffic data and also the content of emails, where permitted by law, for the purposes of security and staff training and in order to prevent or detect unauthorised use of the British Airways email system. Virus checking of emails (including attachments) is the responsibility of the recipient. British Airways Plc is a public limited company registered in England and Wales. Registered number: 1777777. Registered office: Waterside, PO Box 365, Harmondsworth, West Drayton, Middlesex, England, UB7 0GB. Additional terms and conditions are available on our website: www.ba.com

4 3

New on RIPE Labs: Evaluating the Effectiveness of Happy Eyeballs
by Mirjam Kuehne 13 Jun '13

13 Jun '13

Dear colleagues, We just published this new article by Vaibhav Baijpai on RIPE Labs: Evaluating the Effectiveness of Happy Eyeballs https://labs.ripe.net/Members/vaibhav_bajpai/evaluating-the-effectiveness-o… Vaibhav presented this at the recent RIPE 66 meeting during the IPv6-WG session. Kind regards, Mirjam Kuehne RIPE NCC

1 0

New on RIPE Labs: Measuring IPv6 Capability of RIPE Atlas Probes
by Mirjam Kuehne 12 Jun '13

12 Jun '13

Dear colleagues, Please see a new article on RIPE Labs contributed by Stephane Bortzmeyer: How Many RIPE Atlas Probes Believe They Have IPv6 (But Are Wrong)? https://labs.ripe.net/Members/stephane_bortzmeyer/how-many-atlas-probes-bel… Kind regards, Mirjam Kuehne RIPE NCC

5 4

Request to verify ipv6 addressing scheme in my diagram
by Maninder Singh 12 Jun '13

12 Jun '13

Hi Team, I have created a small IPv6 based corporate network diagram and want an expert to validate if the addressing scheme used is fine or not. I am attaching the diagram where I have created the network. Can you please assist me with validation of the address scheme and the network. If need be, I can speak to you on telephone or Skype too. But request you to help me by checking the diagram. Thanks Maninder Singh

3 3

Policy Proposal 2012-10 "Extension of IPv6 /32 to /29 on a per-allocation vs per-LIR basis" implemented
by Kjell Leknes 11 Jun '13

11 Jun '13

[Apologies for duplicate emails] Dear colleagues, We are pleased to announce that RIPE Policy Proposal 2012-10, "Extension of IPv6 /32 to /29 on a per-allocation vs per-LIR basis", has been implemented. The full policy proposal can be found at: http://www.ripe.net/ripe/policies/proposals/2012-10 [Open URL] The updated RIPE Document 589, "IPv6 Address Allocation and Assignment Policy", can be found at: http://www.ripe.net/ripe/docs/ripe-589 [Open URL] You can request this extension by submitting the IPv6 Additional Allocation Request Form through the LIR Portal, or by emailing it to hostmaster(a)ripe.net If you have any questions, please contact ncc(a)ripe.net Regards, Kjell Leknes Registration Services RIPE NCC

1 0

Call for Papers: RIPE 67
by Shane Kerr 07 Jun '13

07 Jun '13

All, This call for papers was sent to the RIPE list yesterday, and thought it might be of interest to participants in this working group. IPv6 is of interest to everyone, so a lot of IPv6-related topics are appropriate for the plenary... don't be afraid! :) Cheers, -- Shane Begin forwarded message: Date: Thu, 6 Jun 2013 10:42:39 +0200 From: Filiz Yilmaz <koalafil(a)gmail.com> To: "ripe-list(a)ripe.net" <ripe-list(a)ripe.net> Subject: Call for Papers: RIPE 67 Dear colleagues, Please find the CFP for RIPE 67 below. Note that the deadline for submissions is 4 August 2013 Kind regards Filiz Yilmaz for the RIPE Programme Committee http://www.ripe.net/ripe/meetings/ripe-meetings/pc --------------------------------------------------- Call for Papers: RIPE 67 A RIPE Meeting is an open event where Internet Service Providers, network operators and other interested parties get together. Although the meeting is mostly technical, it is also a chance for people to meet and network with others in their field. RIPE 67 will take place on 14-18 October 2013 in Athens, Greece. The RIPE Programme Committee (PC) is now seeking content proposals from the RIPE community for the Plenary, BoF and Tutorial sessions at RIPE 67. The PC is looking for presentations covering topics of network engineering and operations, including but not limited to: - IPv6 deployment - Managing IPv4 scarcity in operations - Commercial transactions of IPv4 addresses - Data center technologies - Network and DNS operations - Internet governance and regulatory practices - Network and routing security - Content delivery - Internet peering and mobile data exchange Submissions Attendees of the RIPE meetings are quite sensitive to keeping presentations non-commercial, and product marketing talks are strongly discouraged. Repeated audience feedback shows that the most successful talks focus on operational experience, research results, or case studies. For example, presenters wishing to describe a commercial solution should focus on the underlying technology and not attempt a product demonstration. Presenters who are proposing a panel or BoF are encouraged to include speakers from several (perhaps even competing) companies and/or a neutral facilitator. In addition to presentations selected in advance for the Plenary, the RIPE PC also offers several time slots for “Lightning Talks” which are selected immediately before or during the conference. The following requirements apply: - Proposals for Plenary talks, BoFs, Panels and Tutorials must be submitted for full consideration no later than 4 August 2013, using the meeting submission system at: https://ripe67.ripe.net/submit-topic/ Proposals submitted after this date will be considered on a space-available basis. - Presenters should indicate how much time they will require (30 minutes for Plenary talks is a common maximum duration, although some talks can be longer). - Proposals for talks will only be considered by the PC if they contain at least draft presentation slides (slides may be updated later on). For panels, proposals must contain a clear description as well as names of invited panelists, presenters and moderators. - Due to potential technical issues, it is expected that most if not all presenters/panelists will be physically present at the RIPE meeting. - Tutorials are sessions with educational content and are alotted about 2 hours. - BOFs (Birds of a Feather sessions) are informal gatherings on topics of shared interest among RIPE Meeting attendees. Technical facilities and logistical support are limited and provided based on best effort and availability. - Lightning talks should also be submitted using the meeting submission system. They must be short (10 minutes maximum) and often involve more timely topics. They can be submitted at any time. The allocation of lightning talk slots will be announced one day prior to the relevant session. If you have any questions or requests concerning content submissions, please email pc [at] ripe [dot] net. ------------------------------------------------------------

1 0

New on RIPE Labs: One Year Later - Who's Doing What With IPv6?
by Mirjam Kuehne 06 Jun '13

06 Jun '13

Dear colleagues, On the anniversary of the World IPv6 Launch, this new article takes a look at the readiness of networks to deploy IPv6, using statistics from the RIPE NCC service region and beyond: https://labs.ripe.net/Members/antony_gollan/one-year-later-whos-doing-what-… Kind regards, Mirjam Kuehne RIPE NCC

1 0

Re: [ipv6-wg] RIPE 554 Errata Page
by Merike Kaeo 28 May '13

28 May '13

OK, just got caught up on thread... On Tue 28/05/13 5:13 AM , Tim Chown <tjc(a)ecs.soton.ac.uk> wrote: > On 28 May 2013, at 13:00, "Jan Zorz @ go6.si" wrote: > > > On 5/28/13 1:12 PM, MarcoH wrote: > >> As was just discussing with Jan here in St Petersburg, I'm getting a > bit confused about where we are heading. > >> > >> Do we still want to compile a list of errors and find a way to "attach" > this to the 554 document as an errata? > >> > >> Or are we now gaining momentum to do a full revision and release a new > document superseding 554? Which of course should incorporate all the fixes > as well (and probably introduce some new mistakes) > >> > > This is a complex question now ;) > > > > I suggest that I make two lists - one with mistakes and errata material > in another one with significant changes suggestions. > > > > For a quick fix we could process "errata" small changes and when the > other list with bigger changes grows enough that we collectively decide we > need a new version of the document - we go and change it. > > > > Would that work? > > That sounds good. Works for me too. The one known issue for RIPE 554 is (and has been for a long time as Sander pointed out), the fact that we should have had RFC6105 instead of RFC 4862 since the intent was to make RA filtering mandatory. Jan has approached me a few times to see about helping edit a newer version and I am OK with that as long as there are enough changes to warrant a completely new document. We don't want to turn out a new RIPE doc every time one new v6 related RFC is published but certainly we should keep track of enhancements and modifications on best practices as deployments continue and then turn out a new document (and obsolete previous one(s)). - merike

2 1

Reminder:Cosmetic Surgery Project, new revised RIPE Policy, document for IPv6 database objects
by Emilio Madaio 28 May '13

28 May '13

Dear colleagues, As part of the Cosmetic Surgery Project, the RIPE NCC is moving forward with a review of the policy document ripe-513, "Value of the "status:" and "assignment-size:" attributes in INET6NUM objects for sub-assigned PA space". At the request of the proposers of the original policy proposal that produced ripe-513, we’re sending a reminder about the document review and inviting the IPv6 Working Group Mailing List and Database Working Group Mailing List subscribers to participate in the review process. A draft of the policy document is now online and ready for community review at: https://www.ripe.net/ripe/readability/improving-the-readability-of-ripe-doc… We encourage you to read the edited draft of ripe-513 and send any comments to <address-policy-wg at ripe.net> by 10 June 2013. Kind Regards, Emilio Madaio Policy Development Officer RIPE NCC

2 1