Re: [smartobjectdir] Call for Review of draft-iab-smart-object-architecture-04.txt, "Architectural Considerations in Smart Object Networking"

Ralph Droms <> Fri, 29 August 2014 11:08 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id 014331A00E1; Fri, 29 Aug 2014 04:08:01 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2
X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id kX0VNwYIcbId; Fri, 29 Aug 2014 04:07:58 -0700 (PDT)
Received: from ( [IPv6:2607:f8b0:400d:c00::229]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 99A151A00BA; Fri, 29 Aug 2014 04:07:58 -0700 (PDT)
Received: by with SMTP id m5so1985919qaj.14 for <multiple recipients>; Fri, 29 Aug 2014 04:07:57 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20120113; h=content-type:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=4O73DcisL7VBmQY0BsOMNxr8y/REZvRwPw0hhttEKSc=; b=NLqtdntQz58tnRcTn4WDY+s7e3VDlpe69PvNS37ZP56vhh9GkUQujLaSxEUtSwedMx NgPblq54cCbFstsDHjnxL/ILp/zTxBzoxpGbpP9nKc4fuvWWGULK2GqziSJeLKk3yaDD Y+H8EiA2Y+v6xNd1cbbJDaTIn/4jfOIzo35T5eVfxP4fqmAcwcHW38FKMWkp3TkSQiK2 /Pp7ka2COfMRcvxkh85q/OjvkXKo4wTp+C1vRidFP4kIOZu47eRik0SKodyp3fGPGujL YQBXQsLBCpfbOqPNaQmn0qIVBsFNMhDBOhFuAUQHTf35YxJg16JideKKljgW7VL8dQ/j OhBw==
X-Received: by with SMTP id m1mr16782060qas.0.1409310477525; Fri, 29 Aug 2014 04:07:57 -0700 (PDT)
Received: from ( []) by with ESMTPSA id v111sm9985713qge.7.2014. for <multiple recipients> (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Fri, 29 Aug 2014 04:07:56 -0700 (PDT)
Content-Type: text/plain; charset=windows-1252
Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\))
From: Ralph Droms <>
In-Reply-To: <>
Date: Fri, 29 Aug 2014 07:07:53 -0400
Content-Transfer-Encoding: quoted-printable
Message-Id: <>
References: <> <>
To: IAB <>
X-Mailer: Apple Mail (2.1878.6)
Cc: IAB Chair <>, IETF SmartObjectDir <>, IETF <>, "George, Wes" <>
Subject: Re: [smartobjectdir] Call for Review of draft-iab-smart-object-architecture-04.txt, "Architectural Considerations in Smart Object Networking"
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Fri, 29 Aug 2014 11:08:01 -0000

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 <> 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" <> 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:
>> The Call for Review will last until 24 September 2014.  Please send
>> comments to
>> 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.