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(_at_)iab(_dot_)org> 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(_at_)iab(_dot_)org.
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.