Re: [Dime] [RFC3588bis-34] - Host-IP-Address AVP

Ben Campbell <ben@nostrum.com> Thu, 20 September 2012 18:24 UTC

Return-Path: <ben@nostrum.com>
X-Original-To: dime@ietfa.amsl.com
Delivered-To: dime@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BB76421F86A2 for <dime@ietfa.amsl.com>; Thu, 20 Sep 2012 11:24:15 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.596
X-Spam-Level:
X-Spam-Status: No, score=-102.596 tagged_above=-999 required=5 tests=[AWL=0.004, BAYES_00=-2.599, SPF_PASS=-0.001, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vOpRe5xIHQkG for <dime@ietfa.amsl.com>; Thu, 20 Sep 2012 11:24:15 -0700 (PDT)
Received: from shaman.nostrum.com (nostrum-pt.tunnel.tserv2.fmt.ipv6.he.net [IPv6:2001:470:1f03:267::2]) by ietfa.amsl.com (Postfix) with ESMTP id D2FF621F84F9 for <dime@ietf.org>; Thu, 20 Sep 2012 11:24:14 -0700 (PDT)
Received: from [10.0.1.3] (cpe-76-187-92-156.tx.res.rr.com [76.187.92.156]) (authenticated bits=0) by shaman.nostrum.com (8.14.3/8.14.3) with ESMTP id q8KIOBns043313 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Thu, 20 Sep 2012 13:24:12 -0500 (CDT) (envelope-from ben@nostrum.com)
Content-Type: text/plain; charset=us-ascii
Mime-Version: 1.0 (Mac OS X Mail 6.1 \(1498\))
From: Ben Campbell <ben@nostrum.com>
In-Reply-To: <99463A4A-9840-43B2-B29F-D942FD7AB757@gmail.com>
Date: Thu, 20 Sep 2012 13:24:15 -0500
Content-Transfer-Encoding: quoted-printable
Message-Id: <B5943A55-6A2A-4977-A06C-B9DA9FDABF1E@nostrum.com>
References: <5F42DFF905CBA544A7BBB0909003E1A3148F14F7C6@FRMRSSXCHMBSC1.dc-m.alcatel-lucent.com> <50570410.9000708@gmail.com> <5F42DFF905CBA544A7BBB0909003E1A3148F14F987@FRMRSSXCHMBSC1.dc-m.alcatel-lucent.com> <E4A11012-4F89-455F-AC98-57F188456D91@gmail.com> <50585DBF.20502@gmail.com> <593C8CD1-DAAC-4E39-BE6F-0FA754C706B1@gmail.com> <8BAB668F-5B65-4FBE-B49B-833EAFE47D49@nostrum.com> <99463A4A-9840-43B2-B29F-D942FD7AB757@gmail.com>
To: jouni korhonen <jouni.nospam@gmail.com>
X-Mailer: Apple Mail (2.1498)
Received-SPF: pass (nostrum.com: 76.187.92.156 is authenticated by a trusted mechanism)
Cc: "dime@ietf.org" <dime@ietf.org>
Subject: Re: [Dime] [RFC3588bis-34] - Host-IP-Address AVP
X-BeenThere: dime@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Diameter Maintanence and Extentions Working Group <dime.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/dime>, <mailto:dime-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/dime>
List-Post: <mailto:dime@ietf.org>
List-Help: <mailto:dime-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dime>, <mailto:dime-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 20 Sep 2012 18:24:15 -0000

On Sep 18, 2012, at 10:14 AM, jouni korhonen <jouni.nospam@gmail.com>; wrote:

> Ben,
> 
> On Sep 18, 2012, at 5:15 PM, Ben Campbell wrote:
> 
>> 
>> On Sep 18, 2012, at 7:06 AM, jouni korhonen <jouni.nospam@gmail.com>; wrote:
>> 
>>> 
>>> On Sep 18, 2012, at 2:40 PM, Glen Zorn wrote:
>>>> 
>> 
>>>> This doesn't really make sense to me: I was under the impression that a TCP connection was between two unique addresses.  Yes, a box might ___have_ a whole bunch of addresses it _could_ use, but that seems irrelevant in the case of TCP (but not SCTP).
>>> 
>>> Sure TCP is between just two IPs. I never claimed otherwise. What I mean
>>> that say a Diameter node has IP1 to IP5. Only IP1 has a A/AAAA record or
>>> given out to other parties for static configuration. During the CER/CEA
>>> (and the TCP connection established to IP1) it tell in CEA that
>>> "I btw also have IP2 to IP5". A clever implementation can make use of
>>> this e.g. for the transport failure case I described.
>>> 
>> 
>> This actually leads me to agree with the original poster that the behavior surrounding Host-IP-Address is underspecified. The problem is, "clever implementations" are bad for interoperability. If that (or other) behavior is desired, it should be documented. Otherwise any behavior beyond "use it for informational purposes only" is not likely to work across implementations.
> 
> First, we all agree that having more than one Host-IP-Address in case of
> TCP is unnecessary. However, I am interested what possible (error) case
> you have in mind that could cause interoperability issue?

I don't have a specific error in mind. My intent was to point out that while there may be interesting things you can do with Host-IP-Address (like the example you gave), anything that requires a mutual understanding between the client and server aren't going to work unless the understanding exists. In you example, using Host-IP-Address to tell the peer about other available addresses to be used for load balancing and/or failover won't work across implementations unless it's documented somewhere.

The original poster pointed out that they were seeing real IOT issues because different implementors interpreted the spec differently in regards to Host-IP-Address. Assuming that these differences were due to reasonable interpretations of the spec, rather than simple misunderstandings, that's a pretty big indicator that there's a problem.

> 
> - Jouni
>