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

jouni korhonen <> Tue, 25 September 2012 10:25 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id A44E121F888A for <>; Tue, 25 Sep 2012 03:25:22 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -3.561
X-Spam-Status: No, score=-3.561 tagged_above=-999 required=5 tests=[AWL=0.038, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id NOGMfgtUvQiX for <>; Tue, 25 Sep 2012 03:25:21 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id 9BFE421F887C for <>; Tue, 25 Sep 2012 03:25:21 -0700 (PDT)
Received: by eekd4 with SMTP id d4so874678eek.31 for <>; Tue, 25 Sep 2012 03:25:20 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20120113; h=subject:mime-version:content-type:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to:x-mailer; bh=06oWsanQ/4Cl9yH9PonyLxQuj6nNHtP3iF6ZBt8gNwA=; b=bniUxNJR/lXPrH5Plu49TjFugxZPPPwU1B9l4pfQHPF06+93e2ZtRnMjmbWQ054PhP Rf5/OD6JYR7gAr6vlHdcCTHawJIf0pE2L0SgYCFY1C0ySTtY+RyO2MUSENw18kSN//Pc 2eV+ExKnqoKq6iRkvhyY+LYGFF1tqW80mu/s0ur861gW5dzqWAfnq/TUStYMfOZLIyQU vC0kWhbDeH93CeIfON7FlIv6ThZCi3NUzMb65OhnGolaGNxyN95thlJygDTaFIi8pPQV d+PunFy8Zarj3cdLew0MAfJ1QH3BBVy/32MAKEUKdIXEMEQ6qAzQGO3pDNurqNgD4fuI f7wQ==
Received: by with SMTP id w49mr18570757eep.37.1348568720797; Tue, 25 Sep 2012 03:25:20 -0700 (PDT)
Received: from ?IPv6:2001:67c:64:42:226:bbff:fe18:6e9c? ([2001:67c:64:42:226:bbff:fe18:6e9c]) by with ESMTPS id n5sm12186124bkv.14.2012. (version=TLSv1/SSLv3 cipher=OTHER); Tue, 25 Sep 2012 03:25:17 -0700 (PDT)
Mime-Version: 1.0 (Apple Message framework v1084)
Content-Type: text/plain; charset=us-ascii
From: jouni korhonen <>
In-Reply-To: <>
Date: Tue, 25 Sep 2012 13:25:14 +0300
Content-Transfer-Encoding: quoted-printable
Message-Id: <>
References: <979805090.1858135.1348211373193.JavaMail.root@rdmail01> <> <> <> <>
To: Ralph Loader <>
X-Mailer: Apple Mail (2.1084)
Subject: Re: [Dime] [RFC3588bis-34] - Host-IP-Address AVP
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Diameter Maintanence and Extentions Working Group <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Tue, 25 Sep 2012 10:25:22 -0000

On Sep 25, 2012, at 12:19 PM, Ralph Loader wrote:

>>>> Yes for the first part and no for the second part.. you are not supposed to send
>>>> addresses that you cannot be connected at.
>>> But in general, a Diameter implementation can't reasonably be expected to know which of its IP addresses will be usable by a particular peer.
>> A Diameter node is supposed to know which addresses it can bind and
>> did bind to. The addresses it might put into host-ip-address do
>> not come out of blue.
> That is irrelevant.  The problem is that just because the Diameter node has bound to an address, does not imply that it's possible for a specific peer to try and connect to.  
> E.g., node A, node B are both behind different firewalls, node A binds to, on node B's network, is assigned to a completely different machine.

Right, private addresses + NAT -> you know you will hit your head to wall.
It is not worth putting any energy to solve NATted environment related

> Do you have a specific suggestion for the algorithm a node should use in selecting which of the nodes addresses are put in the Host-IP-Address field?

Not any specific algorithm than the normals:
 o At startup the node scans for the interfaces and addresses in those
   it can bind to.
 o the selection of interfaces can be controlled by many means like
   config file, and the selection of the "main" IP address can also
   come from a config file etc.

Now there is an obvious question what happens if some addresses on
some interfaces are just not reachable e.g. from outside. I would
argue that every permutation of a deployment can be _made_ to break
with some effort regardless of the protocols you got.

>>> Best just to treat the field as informational.
>> Don't fully agree. In case of TCP I could. In case of SCTP I don't.
> For SCTP Host-IP-Address is utterly redundant.  SCTP already supports multi-homing and telling peers of additional addresses (although in practice, I've seen that go hilariously wrong).

- Jouni

> Ralph.
>> - Jouni
>>> Ralph.
>>>> - Jouni
>>>>> Ankur Garg
>>>> _______________________________________________
>>>> DiME mailing list