I agree 100% with the observations Wes makes and his recommendation that text be added to the document to the effect that IPv6 is strongly recommended for use in Smart Objects - Ralph On Aug 27, 2014, at 3:55 PM 8/27/14, George, Wes <wesley.george@xxxxxxxxxxx> wrote: > 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.