March 2018 - iot-wg - mailman.ripe.net

Agenda items for RIPE76
by Jim Reid 26 Mar '18

26 Mar '18

RIPE 76 is 6-7 weeks away. Yikes! Plese send your suggestions for speakers or agenda items for the WG to iot-wg-chairs(a)ripe.net.

1 0

Fwd: [ipv6-wg] Invitation to supply feedback on ITU draft Recommendation on IPv6 address planning for IoT
by Michael J. Oghia 26 Mar '18

26 Mar '18

This might be relevant to this list as well. Best, -Michael ---------- Forwarded message --------- From: Sander Steffann <sander(a)steffann.nl> Date: Thu, Mar 22, 2018, 12:52 PM Subject: Re: [ipv6-wg] Invitation to supply feedback on ITU draft Recommendation on IPv6 address planning for IoT To: ipv6-wg(a)ripe.net <ipv6-wg(a)ripe.net> Hi, > 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. Thanks! As the document is indeed quite long I will give feedback by mentioning the page number, section and quote the particular bit I'm commenting on. I assume, as there are still editorial notes in the document, that minor issues such as grammatical errors don't need comments and will be fixed in a future updates. > Page 3, Introduction: "The current ISPs practice tend to allocate /48 or /64 prefixes to regular customers (e.g., homes) and up to /29 for companies registered at RIRs." There are two issues with this text. The practice of assigning only a /64 goes against the best practice documented in RIPE-690. While I agree that it happens, this should be noted. Also, the "up to /29" text is plain wrong. There are plenty of examples of larger-than-/29 allocations. I guess it means to talk to enterprises that become an LIR, and I don't know any examples for that specific subset. (I'm explicitly NOT going into the difference between allocations and assignments. That doesn't bother me in documents like this) Suggested text: "The current ISPs best current operational practice advises to allocate /48 or /56 prefixes to regular customers (e.g., homes) and up to /29 for enterprises that become LIRs themselves." I think this also better aligns with the scope defined later in the document. > Page 9, 4 Abbreviations and acronyms Might want to add LIR here as well. > Page 13, 9 IPv6 address structure, "Larger networks owners, such as large companies, can get up to /32 global routing prefixes." This contradict the text on page 3. Suggested: "Larger networks owners, such as large companies, can commonly get up to a /29 global routing prefixes." > Page 14, 10 Subnet address requirements, "a smooth transition from IPv4, to dual stack environment (IPv4 and IPv6) and finally to IPv6 only deployments" It might be noted here that IPv4 -> dual-stack -> IPv6 is often no longer the preferred transition path. Technologies like SIIT-DC and NAT64 make it increasingly preferable to skip the dual-stack step. Both to save the cost of an extra transition step and to reduce the complexity caused by the dual-stack phase. > Pages 15&16, 11 Reference model for IPv6 subnet addressing plan I'm not mentioning specific sentences here because I don't agree with the concept behind the whole section. I understand the incentive to map IPv4 prefixes to IPv6 prefixes in the short term. The problem with that strategy is that the given approach results in a very bad IPv6 addressing plan. And it won't be applicable unless the IPv4 addressing plan already conforms to a whole set of conditions. If the IPv4 plan deviates even slightly from the proposed plan then it can't be used. That realistically only makes it deployable in greenfield, in which case there are much better addressing plan possible. Some unrealistic constraints on the IPv4 plan: - the organisation uses a /16 split into /24s - the "categories" subnets have to be kind of hex-aligned (DMZ=0-31, Servers=32-63 etc) And then it creates a suboptimal IPv6 addressing plan: - it is aggregated by building - but the "IPv4-mapping" part is completely unaggregatable - which causes overly complex routing topologies - which causes overly complex firewall rules Without the IPv4 mapping the addressing plan would be close to what the SURFnet addressing plan document recommends (note: I'm one of the authors of that document). In short: this suggested plan is likely not deployable on existing networks, and greenfield networks could do much better. I therefore think this is not a good recommendation at all. > Later sections While there is some sense in the general structure of section 11 (except for the IPv4 mapping), the whole concept is wrangled to pieces in the subsequent sections. For the /56 it's still understandable, but applying this to a /36 is really not even close to a best practice anymore. Networks of that scale just aren't organised in the way that this paper assumes. Furthermore, it also is assigning more than a /44 to a single site, which would violate RIPE policy unless explicitly approved by the RIPE NCC IPRAs. And with a badly structured plan like the recommended one I just can't see that happening. That makes the plan undeployable. So, in summary: it is great that the ITU is helping organisations with deploying IPv6. This plan however seems too far removed from operational reality to be really usable. It looks like an academic exercise without operational experience. It does not feel right to me to publish this as a recommendation unless the shortcomings of the /48 plan section are addressed, and the sections that talk about larger address blocks take common architectures of larger networks into account. Cheers, Sander

3 5

Save the date & call for sponsors: RIOT Summit 2018
by Matthias Waehlisch 14 Mar '18

14 Mar '18

Hi, for those who don't know: RIOT is a modern open source operating system for low-end IoT devices, https://riot-os.org/. Initially developed by folks from academia, the RIOT community now consists of companies, makers, and hobbyist, distributed all around the world. The RIOT community meets annually f2f at the RIOT Summit. The next RIOT Summit is scheduled for September 13-14, 2018 in Amsterdam, locally supported by RIPE NCC. The RIOT Summit aims for bringing together RIOTers, beginners and experts, as well as people interested in the IoT in general and decision makers who plan to deploy RIOT in the future. The event combines plenary talks, hands-on tutorials, and demos. All details are available at https://summit.riot-os.org/2018/. To make the RIOT Summit 2018 a successful event, we need your help! Please consider the following calls: * https://summit.riot-os.org/2018/blog/call-for-sponsors/ * https://summit.riot-os.org/2018/blog/call-for-contributions/ If you have questions, feel free to contact me directly or via summit(a)riot-os.org. Thanks matthias -- Matthias Waehlisch . Freie Universitaet Berlin, Computer Science .. http://www.cs.fu-berlin.de/~waehl

1 0

Fwd: Call for new ENISA Expert Group on Transport Security
by Marco Hogewoning 13 Mar '18

13 Mar '18

Dear Colleagues, Please find below a message received from ENISA regarding the creation of an expert group on transport security and resilience. Although quite far away from RIPE’s mission and mandate, with the ever increasing importance of Internet technology and the IP transport layer, it might be of benefit to bring expertise on these areas into that dialogue. At this stage RIPE NCC does not envision to take part in this group directly, although we will try and keep track of progress and any outcomes that might relate to the interests of the RIPE community. Regards, Marco Hogewoning Senior External Relations Officer RIPE NCC Begin forwarded message: > > Dear Experts, > > I trust this email finds you well. > > We would like to bring to your attention a call for applications for a new ENISA Experts Group on Transport Security and Resilience. > The focus of the group will be air, rail and water transport and you can find more information here: https://www.enisa.europa.eu/news/enisa-news/call-for-experts-for-transsec-t… > > Please feel free to share with your networks. > > Best regards, > -Apostolos > > ------------------------------------------------------------------------------------------------------ > Dr Apostolos Malatras > > Network and Information Security Expert > European Union Agency for Network & Information Security > > Address: 1 Vass Sofias Str, Marousi 151 24, Attica, Greece > E- mail: Apostolos.Malatras(a)enisa.europa.eu<mailto:Apostolos.Malatras@enisa.europa.eu> > Office: +30 2814 409 630 > Mobile: +30 6985 051 401

2 1