Still open for discussion: Invitation to supply feedback on ITU draft Recommendation on IPv6 address planning for IoT
Hello All, We are happy to announce that ITU Study Group 20 has responded positively to our offer and have decided to share the current working draft with us, for the purpose of review and for RIPE community to provide feedback. As it is quite big, the text of this draft Recommendation Y.IPv6RefModel "Reference model of IPv6 subnet addressing plan for Internet of things deployment" has been made available on the IPv6 WG pages: https://www.ripe.net/participate/ripe/wg/ipv6/documents/itu-ipv6refmodel We kindly invite you to provide feedback and comments on the contents of this document via this mailing list or of course the RIPE Forum web interface. The RIPE NCC has agreed to ensure that the comments will be collected and made available to the ITU via response to the Liaison Statement below. We of course also hope to discuss the feedback with the editor of the document during our second session at RIPE 76. Regards, Benedikt, Jen, Raymond Liaison Statement we received from ITU Study Group 20 in response to our invite:
ITU-T Study Group 20 Q3/20 thanks the RIPE NCC for their contribution that contained the invitation from the RIPE IPv6 Working Group. We thank the RIPE IPv6 Working Group for the invitation to present Draft Recommendation ITU-T Y.IPv6RefModel at the May 2018 RIPE meeting for the purpose of obtaining operational feedback and input. We are delighted to recognize the invitation from RIPE and confirm it is the intention of the editor of the Draft Recommendation ITU-T Y.IPv6RefModel to participate in the RIPE meeting in May 2018.
Attached is a copy of the draft Recommendation. We look forward to the feedback and comments from the RIPE community.
For Internal Use Only
Dear Raymond, Colleagues, Thanks for that kind reminder and of course, also a thank you to those who have already submitted comments or approached us with feedback directly. Just to explain where we are, process wise, from the perspective of the RIPE NCC. We have been tracking this work item in ITU Study Group 20 for a while now. People might also still remember our first response to the Liaison we received from the ITU back in 2016, in which we already highlighted the need for this kind of document to be based on operational experience and have it be subject to review by the RIR communities. In a more recent note, following the Liaison that we forwarded to you, which included the draft Recommendation, we have welcomed the Study Group’s decision to accept your invite to come and present at RIPE 76. Further we have committed ourselves to provide a report after this meeting, containing an aggregate of all of the commented received on this list an during the session next week. Once submitted as a reply to the Liaison Statement, we will continue our work in Study Group 20 and follow up in their meetings regarding the input from the RIPE community and how to best reflect that feedback in the ongoing Work Item and the drat Recommendation. As such, we would very much appreciate your collective expertise in reviewing this draft, especially comparing it to existing deployment scenarios and past experience in designing and building IPv6 networks. We are happy to take those comments and feedback back into ITU’s Study Group 20 and the discussions around this draft recommendation. But for the process, it would be beneficial if we can refer to those comments with reference to a public record, such as the archives of this mailing list. In relation to deadlines, the original Liaison mentioned a deadline of 1 June 2018. We still plan on honouring that date and submit a record of the feedback back to ITU no later than May 31st. Regards, Marco Hogewoning -- External Relations - RIPE NCC
Some comments: "Editor notes: there are a large number of ipv4-ipv6 transition and migration strategies: Teredo, 6to4, etc. " I'd just like to point out that Teredo and 6to4 aren't migration strategies, they were basically a way to beta-test the technology. Please do not mention them, we're way past beta testing of IPv6. Mention things like 6RD, MAP, NAT64, ds.lite etc. I still see people thinking 6to4 is something that should be deployed today. RFC3068 is already obsoleted by RFC7526 (a 2015 RFC). I also have to mirror Patrik Fältströms concerns regarding bringing in all the limitations of IPv4 into the IPv6 addressing plan. With ethertype based vlans, one doesn't even have to have IPv6 networks in the same broadcast domain as IPv4, while still providing dual stack to end devices. I have run into people who have done the 1:1 mapping of IPv4 and IPv6 networks, and they resist doing new things with "oh, that doesn't fit my IPv6 adressing plan, I don't have enough IPv6 addresses to do that". This makes me worry about the long term. This document seems to have been written with a world view from 2012-2014, and not taking into account things that have happened since, operational experience from deployment, etc. 6to4 and teredo is nowadays default off in all operating systems (from having being default on in Windows for instance). Writings such as "/56 allocations are likely to become a mainstream practice for individual end-users (homes)", BBF TR-101 from 2010 already recommends /56 for DHCPv6-PD size to residential customers. I think my summary of the document is "I would like to see much less IPv4 thinking in it". -- Mikael Abrahamsson email: swmike@swm.pp.se
Am 24.05.2018 um 09:18 schrieb Mikael Abrahamsson:
Some comments:
"Editor notes: there are a large number of ipv4-ipv6 transition and migration strategies: Teredo, 6to4, etc. "
I'd just like to point out that Teredo and 6to4 aren't migration strategies, they were basically a way to beta-test the technology. Please do not mention them, we're way past beta testing of IPv6. Mention things like 6RD, MAP, NAT64, ds.lite etc. I still see people thinking 6to4 is something that should be deployed today. RFC3068 is already obsoleted by RFC7526 (a 2015 RFC).
So far so good. But in my humble opinion 6rd plays in the same class as all other ipv4-based tunnels are doing. Of course isatap and 6rd may better monitored but they still depending on ipv4. Please exclude 6rd in your recommendation. Regards, Thomas
participants (4)
-
Jetten Raymond -
Marco Hogewoning -
Mikael Abrahamsson -
Thomas Schäfer