I made the following comment (in part) on -03. I'm making it again, because it still applies to -04. "It seems odd to me that this document is silent on the architectural considerations that IPv4 exhaustion may have on Smart Object networking. RFC 6272 discusses support for both protocols, but partially because it was written in 2011, it treats them equally (no recommendation to support one protocol over another). I think we’re doing smart object implementers a disservice by not discussing the increasing likelihood that access to IPv4 addresses will be challenging and costly, especially for something at the scale of Smart Object networking." At the time, the feedback from Hannes was that discussing a specific protocol was too low-level for this document, but I argued that the lack of IPv4 address availability, the potential order of magnitude of the deployment of devices in applications like this, and their limitations (power, etc) make IPv4 vs IPv6 very much an interoperability consideration and an architectural consideration. If your architecture doesn't take into account the fact that we're out of IPv4 addresses, then it's not much of an architecture. Adding a discussion about IPv4's limitations and a recommendation for IPv6 isn't a discussion of a protocol for the sake of compare and contrast, as much as it is acknowledging the reality of the situation. I don't believe that smart object networking is viable at any real scale without IPv6. There simply aren't enough addresses, even taking into account RFC1918. I see this *today* in my own network with deployments like large-scale WiFi and cell tower deployment, set-top-boxes, etc. I think that's the right sort of scale to observe as an analog for smart object networks -- they could potentially be orders of magnitude bigger. The more clearly we say that smart object networks and their supporting systems should assume IPv6, and possibly IPv6-only because of IPv4's inherent scaling limitation, the better off we're going to be. So in terms of smart objects, especially those that are severely resource constrained, I think the recommendations are- First support IPv6, whether it's full IPv6, or something like 6LoPAN. Any interworking or other issues that arise from that choice can be addressed on the far side where there isn't such a resource constraint or scaling issue, eg placing an ALG or NAT64 in front of the IPv6-only devices to make them reachable by legacy IPv4 clients and management systems. Even if you assume that smart object deployments aren't going to be largely greenfield (which in a lot of cases they are, because the infrastructure doesn't exist today), it's almost always going to be easier to make changes to the network and other systems to get those to support IPv6 than it is to add transition technologies, support dual-stack, or retrofit smart object networks from IPv4 to IPv6 later. This is due to the scale of deployment and the resource constraints of the device class. That's an architectural consideration that drives toward a recommendation of single-stack whenever possible. Several IAB folks, including two of the authors agreed that this is something that should be added, but it has not been addressed in this version. In fact, section 2.1 presents IP version as if it is still open for discussion on each design, and the other mention of single stack vs dual stack in section 4.2 appears to have been removed. I'm hoping that this was merely an oversight rather than a conscious decision. Thanks, Wes George On 8/27/14, 2:18 PM, "IAB Chair" <iab-chair@xxxxxxx> wrote: >This is a call for review of "Architectural Considerations in Smart >Object Networking" prior to potential approval as an IAB stream RFC. > >The document is available for inspection here: >https://datatracker.ietf.org/doc/draft-iab-smart-object-architecture/ > >The Call for Review will last until 24 September 2014. Please send >comments to iab@xxxxxxx. > >On behalf of the IAB, > Russ Housley > IAB Chair > This E-mail and any of its attachments may contain Time Warner Cable proprietary information, which is privileged, confidential, or subject to copyright belonging to Time Warner Cable. This E-mail is intended solely for the use of the individual or entity to which it is addressed. If you are not the intended recipient of this E-mail, you are hereby notified that any dissemination, distribution, copying, or action taken in relation to the contents of and attachments to this E-mail is strictly prohibited and may be unlawful. If you have received this E-mail in error, please notify the sender immediately and permanently delete the original and any copy of this E-mail and any printout.