June 2016 - ipv6-wg - mailman.ripe.net

Re: [ipv6-wg] ipv6-wg Digest, Vol 55, Issue 2
by christian bretterhofer 03 Oct '16

03 Oct '16

1. Re: RIPE72 IPv6 WG: call for presentations (Benedikt Stockebrand) Hello to all I think the basic work for ISPs in concern to IPv6 is covered. But i miss the topics to be addressed if you want to migrate from a IPv4 Microsoft Active domain using company to an system where most server in an enterprise could by just IPv6 only and use technologies like NAT46 ( SIIT-DC ) or similar to still make IPv4 only windows clients happy. Switching an enterprise with location around the global from a "we donot route any IPv6 traffic across our WAN Links" "most servers have IPv6 disabled" to We start IPv6 routing partially and enable partial IPv6 support on servers in a Microsoft ADS environment seems not covered in most IPv6 covering websites and presentations. Maintaining dual stack for the datacenters is just painfull and there should be a "single" device in the form of NAT46/SIIT/SIIT-DC in front of each server area. I am not sure that Active directory is ready for that. We are currently moving a complete test ads domain into a Testlab with locations in AT/CN/FI/US into dualstack and here we accept a "not working" during migration and i also hope we can move some servers into a IPv6 only area of those networks. But for a production move we need to be shure that a partial enabling of Dualstack and IPv6 only networking for servers does not break things. Any ideas or links which could help us here? best regards Christian Bretterhofer https://andritz.me ( one Testlab DMZ)

13 32

Fwd: [v6ops] RFC 7872 on Observations on the Dropping of Packets with IPv6 Extension Headers in the Real World
by Fernando Gont 28 Jun '16

28 Jun '16

FYI -------- Forwarded Message -------- Subject: [v6ops] RFC 7872 on Observations on the Dropping of Packets with IPv6 Extension Headers in the Real World Date: Tue, 21 Jun 2016 16:57:35 -0700 (PDT) From: rfc-editor(a)rfc-editor.org To: ietf-announce(a)ietf.org, rfc-dist(a)rfc-editor.org CC: v6ops(a)ietf.org, rfc-editor(a)rfc-editor.org A new Request for Comments is now available in online RFC libraries. RFC 7872 Title: Observations on the Dropping of Packets with IPv6 Extension Headers in the Real World Author: F. Gont, J. Linkova, T. Chown, W. Liu Status: Informational Stream: IETF Date: June 2016 Mailbox: fgont(a)si6networks.com, furry(a)google.com, tim.chown(a)jisc.ac.uk, liushucheng(a)huawei.com Pages: 15 Characters: 30924 Updates/Obsoletes/SeeAlso: None I-D Tag: draft-ietf-v6ops-ipv6-ehs-in-real-world-02.txt URL: https://www.rfc-editor.org/info/rfc7872 DOI: http://dx.doi.org/10.17487/RFC7872 This document presents real-world data regarding the extent to which packets with IPv6 Extension Headers (EHs) are dropped in the Internet (as originally measured in August 2014 and later in June 2015, with similar results) and where in the network such dropping occurs. The aforementioned results serve as a problem statement that is expected to trigger operational advice on the filtering of IPv6 packets carrying IPv6 EHs so that the situation improves over time. This document also explains how the results were obtained, such that the corresponding measurements can be reproduced by other members of the community and repeated over time to observe changes in the handling of packets with IPv6 EHs. This document is a product of the IPv6 Operations Working Group of the IETF. INFORMATIONAL: This memo provides information for the Internet community. It does not specify an Internet standard of any kind. Distribution of this memo is unlimited. This announcement is sent to the IETF-Announce and rfc-dist lists. To subscribe or unsubscribe, see https://www.ietf.org/mailman/listinfo/ietf-announce https://mailman.rfc-editor.org/mailman/listinfo/rfc-dist For searching the RFC series, see https://www.rfc-editor.org/search For downloading RFCs, see https://www.rfc-editor.org/retrieve/bulk Requests for special distribution should be addressed to either the author of the RFC in question, or to rfc-editor(a)rfc-editor.org. Unless specifically noted otherwise on the RFC itself, all RFCs are for unlimited distribution. The RFC Editor Team Association Management Solutions, LLC _______________________________________________ v6ops mailing list v6ops(a)ietf.org https://www.ietf.org/mailman/listinfo/v6ops -- Fernando Gont e-mail: fernando(a)gont.com.ar || fgont(a)si6networks.com PGP Fingerprint: 7809 84F5 322E 45C7 F1C9 3945 96EE A9EF D076 FFF1 -- Fernando Gont SI6 Networks e-mail: fgont(a)si6networks.com PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492

1 0

measuring the effects of happy eyeballs
by Bajpai, Vaibhav 22 Jun '16

22 Jun '16

Dear v6 WG, Measuring the Effects of Happy Eyeballs --------------------------------------- A paper on measuring the effects of happy eyeballs [RFC 6555] just got accepted last week. This uses a 3-years long ('13 - '16) dataset of TCP connect times towards ALEXA top 10K websites collected from 80 dual-stacked SamKnows probes. We just released [a] the paper. Thought to share it along: [a] http://goo.gl/JmKEax Feedback most welcome! You may recall preliminary versions of this work at RIPE 66 [b] and IETF 87 [c]. [b] https://ripe66.ripe.net/archives/video/1208 [c] https://vimeo.com/71407427 Abstract -------- The IETF has developed protocols that promote a healthy IPv4 and IPv6 co-existence. The Happy Eyeballs (HE) algorithm, for instance, prevents bad user experience in situations where IPv6 connectivity is broken. Using an active test (happy) that measures TCP connection establishment times, we evaluate the effects of the HE algorithm. The happy test measures against ALEXA top 10K websites from 80 SamKnows probes connected to dual-stacked networks representing 58 different ASes. Using a 3-years long (2013 - 2016) dataset, we show that TCP connect times to popular websites over IPv6 have considerably improved over time. As of May 2016, 18% of these websites are faster over IPv6 with 91% of the rest at most 1 ms slower. The historical trend shows that only around 1% of the TCP connect times over IPv6 were ever above the HE timer value (300 ms), which leaves around 2% chance for IPv4 to win a HE race towards these websites. As such, 99% of these websites prefer IPv6 connections more than 98% of the time. We show that although absolute TCP connect times (in ms) are not that far apart in both address families, HE with a 300 ms timer value tends to prefer slower IPv6 connections in around 90% of the cases. We show that lowering the HE timer value to 150 ms gives us a margin benefit of 10% while retaining same preference levels over IPv6. Best, Vaibhav =================================== Vaibhav Bajpai www.vaibhavbajpai.com Room 91, Research I School of Engineering and Sciences Jacobs University Bremen, Germany ===================================

1 0

Fwd: [Bp_ipv6] Starting IPv6 BPF 2016: Next call on 23rd June
by Michael Oghia 22 Jun '16

22 Jun '16

FYI. The IGF's Best Practice Forums provide tangible and useful outputs, and this year's IPv6 BPF aims to build on last year's momentum. I encourage anyone working with IPv6 to participate and spread this around your networks. Best, -Michael Oghia __________________ Independent #netgov consultant & editor 2015 ISOC IGF Ambassador Istanbul, Turkey Skype: mikeoghia Twitter <https://www.twitter.com/MikeOghia> *|* LinkedIn <https://www.linkedin.com/in/mikeoghia> ---------- Forwarded message ---------- From: Izumi Okutani <izumi(a)nic.ad.jp> Date: Tue, Jun 21, 2016 at 6:06 PM Subject: [Bp_ipv6] Starting IPv6 BPF 2016: Next call on 23rd June To: "bp_ipv6(a)intgovforum.org" <bp_ipv6(a)intgovforum.org> Dear Colleagues, We are starting work on IPv6 BPF 2016 and I am serving as a MAG Coordinator this year, with my colleague Sumon Ahmed Sabir. You can see our profiles at: http://www.intgovforum.org/cms/mag/45-mag-membership/3030-mag-2016-membersh… To start work for the BPF this year. we would like to invite you to: 1) Share your feedback on the attached Scope and Goals document for IPv6 BPF 2016 Close comments by: Fri 1st July 2) Join us in the call at UTC1600 Thu 23rd June *Register* < https://intgovforum.webex.com/intgovforum/j.php?RGID=ra8e66724ded8a366ee621… > After your request has been approved, you'll receive instructions for joining the meeting. To share some background, last year’s BPF on IPv6 focused on creating capacity building platforms and awareness raising, in the form of national and regional IPv6 taskforces and other initiatives. Building upon the conclusions of last year, the BPF on IPv6 organizers now suggest a focus on the economic decisions and commercial drivers behind the decision to adopt IPv6. Therefore, the target is non-technical people who can share economic/business perspectives. As we did last year, we would like to start with fixing the Scope and Goals document, to be the basis of our work for the output document to be produced as our BFP. Best Regards, Izumi Okutani _______________________________________________ Bp_ipv6 mailing list Bp_ipv6(a)intgovforum.org http://intgovforum.org/mailman/listinfo/bp_ipv6_intgovforum.org

1 0

Icon with IPv6
by Alexey Galaev 21 Jun '16

21 Jun '16

Hi all. Do anyone have isometric icon with IPv6 logo? We are creating animated form to order servers with IPv6. Now that looks like http://storage2.static.itmages.com/i/16/0621/h_1466530601_3472813_28e93c8b0… Thanks. Sent via RIPE Forum -- https://www.ripe.net/participate/mail/forum

1 0

New on RIPE Labs: Reducing the BGP Table Size - A Fairy Tale
by Mirjam Kuehne 20 Jun '16

20 Jun '16

Dear colleagues, Please find a new article on RIPE Labs: George Michaelson is discussing the issue of the relative sizes of the IPv4 and IPv6 Internet in BGP.: https://labs.ripe.net/Members/ggm/reducing-the-bgp-table-size-a-fairy-tale?… Kind regards, Mirjam Kuehne RIPE NCC

1 0

Maximum acceptable IPv6 prefix in BGP table?
by Sergey 16 Jun '16

16 Jun '16

Hi, Looking at the BGP table I see stuff like this, not even /64: 2001:218:2000:5000::3a0/126 *[BGP/170] 2d 08:02:02, localpref 180 AS path: 12714 31133 3491 10026 I, validation-state: unverified > to 2a00:d18:fe03:fefe:a76d::1 via ae2.3386 As we can see this wasn't rejected by 3 AS-es. AFAIK, the minimum allocated space from RIRs is /48. Should we filter prefixes longer than this? -- Kind regards, CTO at *Foton Telecom CJSC (ru.fotontelecom)* Tel.: +7 (499) 679-99-99 AS42861 on PeeringDB <http://as42861.peeringdb.com/>, Qrator <https://radar.qrator.net/as42861>, BGP.HE.NET <http://bgp.he.net/AS42861> http://ipv6actnow.org/

9 14

Re: [ipv6-wg] Maximum acceptable IPv6 prefix in BGP table?
by Mark Tinka 15 Jun '16

15 Jun '16

On 15/Jun/16 11:39, Colin Petrie wrote: > We tried this out last year: > https://labs.ripe.net/Members/emileaben/has-the-routability-of-longer-than-… > > TL;DR - global usefulness of longer-than-/24 is still pretty low. Thanks, Colin. On my side, I'm not immediately keen to fill FIB slots with >/24 or >/48. But I'll keep an eye on what the rest of the community does and adjust accordingly if it makes sense. Mark.

1 0

RIPE Policy vs IETF RFC
by Nathalie Trenaman 14 Jun '16

14 Jun '16

Dear colleagues, As you might know, the current IPv6 policy states very clear that assignments to customers must be a minimum of a /64. 5.4.1. Assignment address space size End Users are assigned an End Site assignment from their LIR or ISP. The size of the assignment is a local decision for the LIR or ISP to make, using a minimum value of a /64 (only one subnet is anticipated for the End Site). https://www.ripe.net/publications/docs/ripe-655 On the other hand, a while ago, RFC7608 (BCP198) was published, stating: 2. Recommendation IPv6 implementations MUST conform to the rules specified in Section 5.1 of [RFC4632]. Decision-making processes for forwarding MUST NOT restrict the length of IPv6 prefixes by design. In particular, forwarding processes MUST be designed to process prefixes of any length up to /128, by increments of 1. In practice, this means that the RFC suggests that a customer can get an IPv6 assignment of any size, while the RIPE policy says the minimum should be a /64. I’m interested to know what the community thinks about this and if alignment between this RFC and the RIPE policy is needed. Nathalie Künneke-Trenaman IPv6 Program Manager RIPE NCC

9 9