Invitation to supply feedback on ITU draft Recommendation on IPv6 address planning for IoT
Dear colleagues, RIPE 76 is coming closer and as you may have seen on the agenda, the date of the IPv6 WG has changed from Wednesday to Thursday. The reason for the date change you can read below and in the subject. If you want to present or have a topic that would be of great interest to the IPv6wg, send your presentation or explain the contents to ipv6-wg-chairs@ripe.net<mailto:ipv6-wg-chairs@ripe.net> and mention also how much time you would need. The session which will be on Thursday 17 may 2018, in Palais du Pharo, Marseille, France. Now back to the subject: During RIPE 74, Marco Hogewoning of the RIPE NCC, presented about ongoing work in ITU Study Group 20, which includes development of a Recommendation on an IPv6 address plan for IoT networks. In his presentation he also mentioned a Liaison Statement send by the ITU asking the RIPE NCC for feedback, to which they suggested that this work would be done in a more appropriate venue such as the RIPE community or at least that such a document would be developed in close coordination with the operational community. We, the chairs, have been following this discussion and after talking to RIPE NCC and some community members, we have understood that there has not been any operational feedback on this particular draft and ITU is still seeking input, for instance also by sending a Liaison Statement to IETF. In response to all this, we have decided to invite a representative of ITU, to join us in Marseille for RIPE 76 and present this work to us, for the purpose of collecting and incorporating feedback from IPv6 experts and network operators on their draft recommendation. 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
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
Hi,
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.
Oh, and I obviously volunteer to help the authors to improve the document! My criticism only aims to make it better :) Cheers, Sander
Page 8, 2 Definitions There are other address generating mechanisms in use apart from "base it on
Hi, Thank you, Sander. I support your comments, which cover most of my points. However, I would like to add a few minor remarks: the MAC address".
Page 10, 6 Introduction to IPv6 RFC8200 does obsolete (not update) RFC2460.
So, in summary: [...] It looks like an academic exercise without operational experience. It does not feel right to me to publish this as a recommendation Solely based on this draft I would have to conclude that IPv6 (addressing) is probably not the ITUs area of expertise. Other venues/bodies, e.g. this WG, might be more suitable for giving guidance.
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
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
Regards, Markus __________ ursprüngliche Nachricht __________ Von: Sander Steffann <sander@steffann.nl> Datum: Donnerstag, 22. März 2018, 12:50:38 An: "ipv6-wg@ripe.net" <ipv6-wg@ripe.net> Kopie: Betr.: Re: [ipv6-wg] Invitation to supply feedback on ITU draft Recommendation on IPv6 address planning for IoT the purpose of review and for RIPE community to provide feedback. 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
-- Markus de Brün Bundesamt für Sicherheit in der Informationstechnik (BSI) Federal Office for Information Security, Germany Mail: markus.debruen@bsi.bund.de
On 07/03/2018 08:19, Jetten Raymond wrote:
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.
Dear RIPE Community and Document Proposer, First of all, for a full disclosure - I'm writing this review in my own personal capacity as a long time IPv6 advocate and member of the RIPE community. My views and comments do not necessarily represent the views of my employer. Reading through this document raised a few points in my minds, which are elaborated below: - Absence of problem statement. Technical documents normally identify the problem they're trying to address. Do we really have a problem, what is that problem, and what are we trying to solve? Is the addressing of IoT devices an actual issue anyone has? - No clear requirements If a problem is defined, what are the requirements for any solution? What is the scope of the document, and what is the framework under discussion. - Lack of documented operational experience or good practice What is the best current operational practice for this problem, or has an experimental environment involving many hundreds of devices identified a need for this solution? If neither is the case, what is the evidence that a prescribed solution with neither operational nor experimental experience would work as planned? - Factual errors There are several errors in the document, some of them were already pointed out and explained by Sander Steffann in his review. - Misunderstanding of how IPv6 addressing policy works A general reality is that network operators determine their IPv6 addressing plans depending on the type of network they are building and the purpose. Whilst it's possible to define certain best practices that can apply, these are invariably based on operational experience and are not prescriptive (i.e. 'bottom up' rather than 'top down'). IoT devices will be utilised in many different ways and in different types of networks, and whilst there may be merit in starting to think about IPv6 addressing plans for IoT, these should be formulated based on the collective experience of multiple diverse network operators. - What is the ITU's motivation for doing this? Internet standards were developed by organisations involved with its operation, and best practices evolved out of their direct operational experience. The network operator communities (e.g. RIPE) are therefore best placed to understand, define and implement IPv6 addressing plans for IoT devices. Other interested organisations including the ITU are of course encouraged to participate in this process, raise issues of concern to their communities, and contribute to the best current operational practice, but should not seek to prescribe solutions unilaterally. Personally, I feel the purpose of this proposal is unclear, and there is limited value in further discussion of this document for the various reasons described above. I would be open to review a future version of this document from SG20 that will take into account all the above concerns. Best regards, Jan Žorž
Hi, I basically agree with Jan. I will say that the ITU friends contributing to this document need to come to the IETF and the RIR meetings to openly discuss and learn about the reality about operating IPv6 and IoT networks. In short the document makes no sense at all and is plenty of errors even in the way some notation, protocol names and references are used. Regards, Jordi -----Mensaje original----- De: ipv6-wg <ipv6-wg-bounces@ripe.net> en nombre de Jan Zorz - Go6 <jan@go6.si> Fecha: martes, 15 de mayo de 2018, 13:55 Para: <ipv6-wg@ripe.net> Asunto: Re: [ipv6-wg] Invitation to supply feedback on ITU draft Recommendation on IPv6 address planning for IoT On 07/03/2018 08:19, Jetten Raymond wrote: > 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. Dear RIPE Community and Document Proposer, First of all, for a full disclosure - I'm writing this review in my own personal capacity as a long time IPv6 advocate and member of the RIPE community. My views and comments do not necessarily represent the views of my employer. Reading through this document raised a few points in my minds, which are elaborated below: - Absence of problem statement. Technical documents normally identify the problem they're trying to address. Do we really have a problem, what is that problem, and what are we trying to solve? Is the addressing of IoT devices an actual issue anyone has? - No clear requirements If a problem is defined, what are the requirements for any solution? What is the scope of the document, and what is the framework under discussion. - Lack of documented operational experience or good practice What is the best current operational practice for this problem, or has an experimental environment involving many hundreds of devices identified a need for this solution? If neither is the case, what is the evidence that a prescribed solution with neither operational nor experimental experience would work as planned? - Factual errors There are several errors in the document, some of them were already pointed out and explained by Sander Steffann in his review. - Misunderstanding of how IPv6 addressing policy works A general reality is that network operators determine their IPv6 addressing plans depending on the type of network they are building and the purpose. Whilst it's possible to define certain best practices that can apply, these are invariably based on operational experience and are not prescriptive (i.e. 'bottom up' rather than 'top down'). IoT devices will be utilised in many different ways and in different types of networks, and whilst there may be merit in starting to think about IPv6 addressing plans for IoT, these should be formulated based on the collective experience of multiple diverse network operators. - What is the ITU's motivation for doing this? Internet standards were developed by organisations involved with its operation, and best practices evolved out of their direct operational experience. The network operator communities (e.g. RIPE) are therefore best placed to understand, define and implement IPv6 addressing plans for IoT devices. Other interested organisations including the ITU are of course encouraged to participate in this process, raise issues of concern to their communities, and contribute to the best current operational practice, but should not seek to prescribe solutions unilaterally. Personally, I feel the purpose of this proposal is unclear, and there is limited value in further discussion of this document for the various reasons described above. I would be open to review a future version of this document from SG20 that will take into account all the above concerns. Best regards, Jan Žorž ********************************************** IPv4 is over Are you ready for the new Internet ? http://www.consulintel.es The IPv6 Company This electronic message contains information which may be privileged or confidential. The information is intended to be for the exclusive use of the individual(s) named above and further non-explicilty authorized disclosure, copying, distribution or use of the contents of this information, even if partially, including attached files, is strictly prohibited and will be considered a criminal offense. If you are not the intended recipient be aware that any disclosure, copying, distribution or use of the contents of this information, even if partially, including attached files, is strictly prohibited, will be considered a criminal offense, so you must reply to the original sender to inform about this communication and delete it.
Hello everyone, as promised during the WG session in Marseille, here is the result of my analysis of the draft ITU Recommendation Y.IPv6RefModel “Reference model of IPv6 subnet addressing plan for Internet of things deployment”. It's not exactly a scientific masterpiece, but right now I have only limited time to get this out... Upon another closer look at the document I realized that in *all* relevant cases not 8 but 16 bits of each address are re-purposed. This leads to an even more dramatic reduction of the expected usable life time of IPv6, as explained in point 5. If I manage to turn this into a video blog session (no promises, but I'll try to find the time somehow) I'll let you know. And yes, I've already recorded a session on this topic in late 2013 at https://www.stepladder-it.com/bivblog/2/, so this problem has been around for at least a good four years. Enjoy the read. Cheers, Benedikt ---8<--- In One Sentence =============== The entire document is flawed beyond repair due to its underlying approach; if applied as a "reference model" it will critically endanger the future of the IPv6 based Internet. Some Core Problems ================== 1. The model is inapplicable to real-world networks. 2. The model will dramatically hinder any further evolution of all IP based networking. 3. The model carries all legacy problems from IPv4 into the IPv6 era. 4. The model precludes the application of several of the most basic security measures considered best practice by todays standards. 5. The model shortens the expected usable life time of IPv6 by at least 25%, or 42+ years at the current Internet growth Analysis and Explanations ========================= 1. The model is inapplicable to real-world networks --------------------------------------------------- Real world networks are split into subnets based on a number of fundamental criteria. These usually include - real-time behaviour (e.g. low latency for VoIP vs. high bandwidth for SAN) - security considerations (e.g. splitting networks into adequate security zones) - service level considerations and many more. The document defines a categorization that ignores all of these criteria but for some reason considers "IoT"---without any consideration of the normal criteria applied to the particular IoT application---as special. As a result, when designing networks according to the proposed model, there are two possible results: If the commonly used criteria are ignored, then the result is a network that is an ill fit to the purposes and security requirements it should be designed for. If the commonly used criteria are applied, then the encoding of the categories required by the model will lead to a fragmentation of the network that causes a tremendous increase in the number of routes needed throughout the network. In sufficiently large networks, e.g. at an enterprise level, this will make it impossible to apply the commonly used criteria for network design. 2. The model will dramatically hinder any further evolution of all IP --------------------------------------------------------------------- based networking ---------------- The proposed model doesn't cater for future development of IP based networks. (Having a category "Reserved & Others" in obviously doesn't do, since a "reserved" subnet range can't be possibly used for "other" applications.) But even if this was somehow fixed in the document, this wouldn't help any. Reserving a sufficiently large part of the address space for future specifications would seriously aggravate the other problems in this analysis to the point that the entire model becomes impossible to implement. Not reserving a sufficiently large part of the address space however will quickly lead to the situation that the Internet outgrows the model proposed. Considering that it took IPv6 approximately 30 years to get to where it is right now, then even if we started on a successor IP protocol today---which to my knowledge is nowhere in sight---then we have to assume that IPv6 will by around for another 30+ years until it can be replaced. Considering the speed at which the Internet, and IP networking in general, have evolved in the last 30 years there is no chance that the proposed model can be used throughout such a period in an evolutionary way. 3. The model carries all legacy problems from IPv4 into the IPv6 era -------------------------------------------------------------------- Attempting to map IPv4 and IPv6 in a 1:1 fashion carries all the legacy issues we have with IPv4, like broadcast-based applications leading to undesirable network topologies, over into the IPv6 world. Once IPv4 gets obsolete in parts of a network, this approach either forces yet another redesign of the then-productive IPv6 network, or it carries the IPv6-related problems even after IPv4 has otherwise been removed from the network into the IPv6-only period. 4. The model precludes the application of several of the most basic ------------------------------------------------------------------- security measures considered best practice by todays standards -------------------------------------------------------------- In enterprise and other data center environments, microsegmentation and hierarchical security zones as well as a number of other, more specific designs, are used to reach a sufficient level of security. All of these measures however require a network design that can't be implemented within the constraints of the proposed model except through an excessive bloat of the routing tables, firewall configurations and application based access control lists involved. Depending on the security requirements of the given network environment, this is unacceptable at best and violating various legal requirements at worst. 5. The model shortens the expected usable life time of IPv6 by at least ----------------------------------------------------------------------- 25%, or 42+ years at the current Internet growth ------------------------------------------------ IP addresses by their very design are supposed to hold all the information needed to route IP packets from their source to their destination. As such IP addresses must be assigned in a way that matches the chosen network topology, and nothing else. The proposed model however effectively re-purposes two octets of data for purposes unrelated to routing. Applying the HD ratio concept (as used for IPv6 subnets in general), or basic information theory (Shannon 1948/1949), this can be worked into more palatable numbers: The proposed model - reduces the number of usable subnet prefixes to 1/65536 = 0.00153% of the address space, - at a continued exponential growth of the Internet reduces the expected usable life time of IPv6 by (64-48)/64 or 25% and - at a continued exponential growth of the Internet by the commonly measured/estimated factor of 1.3/year, reduces the effective life time by log_1.3(2**16)=42.27 years. This doesn't even take into account the impact it has on the size of routing tables, access control lists and such, which may or may not reduce the usable life time of IPv6 at the Internet level even further. Only when the network topology correlates, or is made to correlate, the encoding of the categorization data in the addresses could this effect be slightly reduced. Trying to make use of this fact will however make network design decidedly more complex while at the same time only generating a marginal effect. Conclusion ========== Following from the results of this analysis---which is by no means meant to be complete---the proposed reference model is ill-conceived and critically endangers the future of the Internet. ---8<--- -- Benedikt Stockebrand, Stepladder IT Training+Consulting Dipl.-Inform. http://www.stepladder-it.com/ Business Grade IPv6 --- Consulting, Training, Projects BIVBlog---Benedikt's IT Video Blog: http://www.stepladder-it.com/bivblog/
Dear WG,
https://www.ripe.net/participate/ripe/wg/ipv6/documents/itu-ipv6refmodel
I would like to thank SG20 for the liaison statement and the opportunity to comment on Draft Recommendation Y.IPv6RefModel "Reference model of IPv6 subnet addressing plan for Internet of things deployment" from Q3/20 e-meeting December 2017. The document suggests an "optional reference model of an IPv6 addressing plan for Internet of things (IoT) deployment by smart cities, public administrations and companies". However, I am missing any identification of the special needs of these target audiences, any explanation of specific needs of "IoT" (with that being resollved per ITU-T Y.2060 as a "global infrastructure"), or the benefits of a unified addressing plan at all. The draft document lacks precision in terminology (e.g., it talks about "routing prefixes" rather than "address space"). The document refers to IETF "standards" dealing with "IoT", but fails to give an explanation for a need for an addressing plan arising from the use or deployment of those standards/protocols. In addition, there is no reason given why SG20 would be the appropriate venue for this activity, rather than the IETF or the RIRs and their attached operator communities. Section 7 "Preventing a New Digital Divide" suggests that the lack of a reference model for an addressing plan was detrimental to IPv6 deployment, probably based on region - without giving supporting facts. Also, the plans proposed later would not be sufficient to justify address assignments (or allocations) beyond those sizes easily available today, nor is there any support for an argument that "shortage of v6 addresses" would be an obstacle for deployment. The plans also do not help in utilizing the address space and deploying real v6 networks (see below). Section 8 adds "smart buildings" to the target audience without further explanation. The section then lists a number of IPv6 deployments, criteria for inclusion in the list being unclear. There is also no link the the draft document, neither by those examples having informed the proposed plans, nor by the the proposed plans having been instrumental in the operational reality of any of the examples. Section 9 does not correctly represent the role of RIRs and LIRs (or NIRs, where applicable). The plans in section 11, finally, deal far more with the "non IoT" parts of the network (DMZ, servers, regular LAN) without justifying the recommendations based on operational experience. Also, while there is a postulated size for the address space for "IoT", the size and need is not justified, nor is there any inner differentiation for systems or objects in the "IoT" category. Assigning addresses per building or floor is already outdated in today's networks. In my view, the document clearly fails to motivate the need for a reference model for an addressing plan and any special role for "IoT" in any such plan (read: there is no problem statement). Therefore, it is impossible to evaluate the proposed solutions. That said, the proposed plans are heavily encumbered by an unmotivated "consistency" with IPv4 addressing. -Peter -- Peter Koch | | pk@DENIC.DE DENIC eG | | +49 69 27235-0 Kaiserstraße 75-77 | | 60329 Frankfurt am Main | | https://www.DENIC.DE ------------------------------------------------------------------------- Eingetr. Nr. 770 im Genossenschaftsregister Amtsgericht Frankfurt am Main Vorstand: Helga Krüger, Martin Küchenthal, Andreas Musielak, Dr. Jörg Schweiger Vorsitzender des Aufsichtsrats: Thomas Keller
* Jetten Raymond:
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
I think this looks at the problem from literally the wrong end. Even under the most restrictive assignment regimes, end users still have 64 address bits to play with, and each address resulting in a globally unique address.
participants (8)
-
Benedikt Stockebrand -
de Brün, Markus -
Florian Weimer -
Jan Zorz - Go6 -
Jetten Raymond -
JORDI PALET MARTINEZ -
Peter Koch -
Sander Steffann