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

From: "VITON HORCAJO, Pedro (Pedro)" <[email-masked]>
Date: Mon, 17 Sep 2012 11:02:26 +0200

Hi:

After reviewing original RFC3588 and the lastest draft for 3588bis-34, I have a couple of comments/questions related to the Host-IP-Address AVP

1.- I don't have clear the behavior of a diameter peer when SENDING the Host-IP-Address AVP in the CER/CEA messages, if using TCP to transport Diameter.

In sections 5.3.1 (CER), 5.3.2(CEA) and 5.3.5 (Host-IP-Address AVP), it indicates the behavior with respect to that AVP when using SCTP or DTLS/SCTP as transport mechanism.

   The Host-IP-Address AVP (AVP Code 257) is of type Address and is used
   to inform a Diameter peer of the sender's IP address.  All source
   addresses that a Diameter node expects to use with SCTP [RFC4960] or
   DTLS/SCTP [RFC6083] MUST be advertised in the CER and CEA messages by
   including a Host-IP-Address AVP for each address.

   When Diameter is run over SCTP [RFC4960] or DTLS/SCTP [RFC6083],
   which allow connections to span multiple interfaces, hence, multiple
   IP addresses, the Capabilities-Exchange-Answer message MUST contain
   one Host-IP-Address AVP for each potential IP address that MAY be
   locally used when transmitting Diameter messages.

That might lead to think that if using TCP, that AVP might/needs not be sent.

However, not sending it would be a contradiction with the CER/CEA ABNF message format, that states that the Host-IP-Address AVP is a mandatory AVP with at least 1 ocurrence :
         <CER> ::= < Diameter Header: 257, REQ >
                   { Origin-Host }
                   { Origin-Realm }
                1* { Host-IP-Address } <------------
...

I think it would be a good idea to clarify:
A.- whether Host-IP-Address MUST/SHOULD/MAY included in CER/CEA messages if using TCP
B.- if it is not needed, indicate that AVP as opcional 1*[Host-IP-Address] in the CER/CEA ABNF. However, leaving it as optional, might lead to interoperability issues between an implementation not sending it, and another implementation expecting it as mandatory (as per current RFC 3588)

--------------------
2.- On the other side, I haven't been able to find anywhere the behavior a Diameter implementation should have when RECEIVING that AVP, both with TCP and SCTP as transport methods.

A.- Should it check the source IP address of the received CER/CEA message belongs to the values of the Host-IP-Address AVP?
But what would be the purpose of that? Prevent NAT traversal?

And what to do then if the Source IP Address doesn't match?

B.- With SCTP, I thought initially the Diameter implementation could interface with a SCTP layer primitive to add the rest of the advertised IP addresses in Host-IP-Address, as possible addresses for this endpoint in the already established SCTP association.

However, after glancing over SCTP RFC 4960 (sections 3.3.2.1 & 5.1.2), it seems that the remote IP addresses of an association may be exchanged/learnt only during the association establishment by using the Options in the INIT chunk.

Therefore, if my assumption is right that it is not possible to add/remove a remote endpoint  IP address to an already established association,
what's the point in having a Host-IP-Address AVP in the CER/CEA message?

Just for historical reasons?

In any case, I think it would be nice to clarify the utility of Host-IP-Address AVP, as well as a diameter implementation expected behavior, both when sending it and receiving it, when using TCP and SCTP.

Thanks,
  Pedro

      \\\|///
     \\ ~ ~ //
     (/ @ @ /)
___oOOo-(_)-OOo_________________________
Pedro Viton         Tlf:+(34) 690 96 4740

[email-masked]<mailto:[email-masked]>

C/ Maria Tubau 9 (28050) Madrid SPAIN
___________Oooo.____________________________
    .oooO  (   )
    (   )   ) /
     \ (   (_/
      \_)

---

From: Glen Zorn <[email-masked]>
Date: Mon, 17 Sep 2012 18:05:52 +0700

On 09/17/2012 04:02 PM, VITON HORCAJO, Pedro (Pedro) wrote:
> Hi:
> After reviewing original RFC3588 and the lastest draft for 3588bis-34, 
> I have a couple of comments/questions related to the Host-IP-Address AVP
> 1.- I don't have clear the behavior of a diameter peer when SENDING 
> the Host-IP-Address AVP in the CER/CEA messages, if using TCP to 
> transport Diameter.
> In sections 5.3.1 (CER), 5.3.2(CEA) and 5.3.5 (Host-IP-Address AVP), 
> it indicates the behavior with respect to that AVP when using SCTP or 
> DTLS/SCTP as transport mechanism.
> However, not sending it would be a contradiction with the CER/CEA ABNF 
> message format, that states that the Host-IP-Address AVP is a 
> mandatory AVP with at least 1 ocurrence :

As you point out, the command definition for the CER requires at least 
on instance of the AVP.  What is unclear?

...

---

From: "VITON HORCAJO, Pedro (Pedro)" <[email-masked]>
Date: Mon, 17 Sep 2012 14:09:07 +0200

Glen,

 Thanks for answering.
Maybe my original mail was too long, and I  might have not have been clear enough.

Let me rephase my questions, in a shorter way:

1.- The current text for Host-IP-Address AVP indicates the value to send when transporting over SCTP.
But which value should be sent when transporting over TCP?

2.- What should a Diameter implementation do when receiving the Host-IP-Address AVP?

Best Regards,
  Pedro

>> -----Original Message-----
>> From: Glen Zorn [mailto:[email-masked]] 
>> Sent: Monday, September 17, 2012 1:06 PM
>> To: VITON HORCAJO, Pedro (Pedro)
>> Cc: [email-masked]; [email-masked]
>> Subject: Re: [Dime] [RFC3588bis-34] - Host-IP-Address AVP
>> 
>> 
>> > That might lead to think that if using TCP, that AVP 
>> might/needs not 
>> > be sent.

---

From: jouni korhonen <[email-masked]>
Date: Mon, 17 Sep 2012 23:06:51 +0300

Hi,

Few quick comments inline.

> But which value should be sent when transporting over TCP?

RFC3588bis says:

   The Host-IP-Address AVP (AVP Code 257) is of type Address and is used
   to inform a Diameter peer of the sender's IP address. 

This part is not SCTP specific. So at minimum you include the address the
very TCP connection comes from. Repetition but acceptable. Also, Diameter
host's DiameterIdentity may resolve to one or more IP addresses but not
necessarily to all of those. It is a DNS provisioning matter. The Diameter
node would know all its addresses it can use, so those additional addresses
would be included.

> 2.- What should a Diameter implementation do when receiving the Host-IP-Address AVP?

In case of TCP.. that is more like FYI (unless someone plans to hack MPTCP into
Diameter some day). Or in case of transport failure, the peer can select other
IP for retrying the transport connection.

With SCTP, there is always RFC5061. Addresses can be added to and deleted from
an existing association. So for the responder it is good to know that some IP 
address maps to a DiameterIdentity of the initiator as those might be added
later on.

- JOuni

> _______________________________________________
> DiME mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/dime

---

From: "VITON HORCAJO, Pedro (Pedro)" <[email-masked]>
Date: Tue, 18 Sep 2012 08:43:09 +0200

Thanks for your replies,

These questions came due to some interoperability small issue found with another vendor Diameter implementation.

I fully agree with your answers and interpretation, but sometimes in IOT's between different vendors, I think these little details are important.

Extra comments inline:

Thanks,
  Pedro

>> From: jouni korhonen [mailto:[email-masked]] 
>> Sent: Monday, September 17, 2012 10:07 PM
>> Cc: Glen Zorn; [email-masked]
>> > 1.- The current text for Host-IP-Address AVP indicates the 
>> value to send when transporting over SCTP.

>> node would know all its addresses it can use, so those 

I agree with this point, and all the possible addresses should also be sent with TCP, as well as with SCTP.
But then, 
what's the difference with respect to SCTP?
Why does the RFC explicitely indicates SCTP for sending all possible IP addresses?

>> IP for retrying the transport connection.

This retrying of the transport connection to the other advertised Host-IP-Address(es) sounds really interesting.
But the current RFC text, doesn't even say that a peer MAY retry the transport connection to any of the other advertised Host-IP-Addresses.

>> address maps to a DiameterIdentity of the initiator as those 

Sounds reasonable. 
But as 3588bis doesn't say anything of doing any of this, an implementation doing nothing with the received Host-IP-Address values would be perfectly valid and compliant, I suppose.

Thanks,
  Pedro

>> >>> All source

---

From: jouni korhonen <[email-masked]>
Date: Tue, 18 Sep 2012 11:41:43 +0300

Hi,

> Why does the RFC explicitely indicates SCTP for sending all possible IP addresses?

Because current TCP has no use of multiple addresses (except for failure
recovery.. maybe). On the other hand, SCTP is made for multi-addressing/homing.
And as I said, whether or not all IP addresses are provisioned e.g. into
DNS or statically is an operational issue. The less you provision the
easier. Let the underlying protocol take care of multiple addressing if
it is able to do that.

> But the current RFC text, doesn't even say that a peer MAY retry the transport connection to any of the other advertised Host-IP-Addresses.

The RFC says a DiameterIdentity may resolve to multiple IP
addresses of the peer. There is no restriction why a peer
would not try to connect to any of those.. just an implementation
detail allowed by the protocol.

If a peer is willing to reveal multiple IP addresses that it can
be reachable at, it must have a reason for it, specifically in a
case of TCP.

> But as 3588bis doesn't say anything of doing any of this, an implementation doing nothing with the received Host-IP-Address values would be perfectly valid and compliant, I suppose.

Yes. Slightly dumb implementation but valid and compliant. There are a
lot of things that are unsaid regarding transport. For example, RFC3588(bis)
only refers to RFC793/5461 regarding the TCP protocol itself. However, for
a proper TCP implementation something +20 RFCs are needed (see RFC4614).

- Jouni

---

From: Glen Zorn <[email-masked]>
Date: Tue, 18 Sep 2012 18:32:13 +0700

> But which value should be sent when transporting over TCP?

I think that a TCP pseudo-connection can only have two end-points, so 
the value should probably be the IP address of the sender.  I suppose 
that it could be different, though, in some load balancing scheme: "I'm 
sending this from address 'A', but from now on I'll be using address 
'B'"; of course, the connection w/that address would need to be 
authenticated, etc.

> 2.- What should a Diameter implementation do when receiving the Host-IP-Address AVP?

Any thing it likes, I suppose ;-).

---

From: Glen Zorn <[email-masked]>
Date: Tue, 18 Sep 2012 18:40:47 +0700

> node would know all its addresses it can use, so those additional addresses

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).

> IP for retrying the transport connection.

Surely it makes more sense just to start over, doesn't it?  That 
behavior also seems to be prescribed by the state machine...

...

---

From: jouni korhonen <[email-masked]>
Date: Tue, 18 Sep 2012 15:06:42 +0300

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.

- Jouni

---

From: Ben Campbell <[email-masked]>
Date: Tue, 18 Sep 2012 09:15:35 -0500

> 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.

I'm do not propose we fix this in 3588bis--it's too late in the process for that. But it might be worth a follow-on effort down the road.

Thanks!

Ben.

---

From: jouni korhonen <[email-masked]>
Date: Tue, 18 Sep 2012 18:14:33 +0300

Ben,

> 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 t…

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?

- Jouni

---

From: Ben Campbell <[email-masked]>
Date: Thu, 20 Sep 2012 13:24:15 -0500

> 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.

---

From: Glen Zorn <[email-masked]>
Date: Fri, 21 Sep 2012 13:54:08 +0700

On 09/21/2012 01:24 AM, Ben Campbell 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
 >>>> 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?

The draft says:

Suppose that I send, instead of one address, three (assuming the use of 
TCP).  Which one do you use?  What if the list doesn't contain the 
address from which the CEr/CEA command was sent?  If my solution to 
transport failure is to send you three addresses assuming that you'll 
try them sequentially and you don't understand that, my scheme fails and 
since you only have one registered address for me, this could cause a 
much longer outage than if my network admins just did their job and 
registered all the available addresses in the DNS.

>>
 >
 > 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.

I would be inclined to write a short draft clarifying that, in the case 
of TCP, exactly one instance of the Host-IP-Address MUST be included in 
the CER/CEA messages.

...

---

From: Ankur Garg <[email-masked]>
Date: Fri, 21 Sep 2012 12:39:33 +0530 (IST)

Hello, 

Is it possible to have two Host-IP-Address AVPs; one containing IPv4 and other is IPv6 address while stack working on dual mode(IPv4 and IPv6) and Configured Peer listening on IPv4 only? It would be correct to send both IPv4 and IPv6 address in such case? 

Ankur Garg ----- Original Message -----

From: "Glen Zorn" <[email-masked]> 
To: "Ben Campbell" <[email-masked]> 
Cc: [email-masked] 
Sent: Friday, September 21, 2012 12:24:08 PM 
Subject: Re: [Dime] [RFC3588bis-34] - Host-IP-Address AVP 

> 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? 

The draft says: 

 > 
 > 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. 

...

---

From: jouni korhonen <[email-masked]>
Date: Fri, 21 Sep 2012 10:24:40 +0300

Glen,

On Sep 21, 2012, at 9:54 AM, Glen Zorn wrote:

> Suppose that I send, instead of one address, three (assuming the use of TCP).  Which one do you use?  What if the list doesn't contain the address from which the CEr/CEA command was sent?  If my solution to transport failure is to send you three addresses 

Obviously you use the address you received CER/CEA from.. and if that address is not included in the
list of Host-IP-Addresses then the other end is on weeds.

> assuming that you'll try them sequentially and you don't understand that, my scheme fails and since you only have one registered address for me, this could cause a much longer outage than if my network admins just did their job and registered all the available addresses in the DNS.
> 
>>> 
> >
> I would be inclined to write a short draft clarifying that, in the case of TCP, exactly one instance of the Host-IP-Address MUST be included in the CER/CEA messages.

Might be a good thing.

- Jouni

---

From: jouni korhonen <[email-masked]>
Date: Fri, 21 Sep 2012 10:41:29 +0300

> Is it possible to have two Host-IP-Address AVPs; one containing IPv4 and other is IPv6 address while stack working on dual mode(IPv4 and IPv6) and Configured Peer listening on IPv4 only? It would b…

Yes for the first part and no for the second part.. you are not supposed to send addresses that you cannot be connected at.

- Jouni

> Ankur Garg

---

From: "VITON HORCAJO, Pedro (Pedro)" <[email-masked]>
Date: Fri, 21 Sep 2012 11:24:13 +0200

Let me step in again:

I've read you're making references to DNS and that valid IP addresses to receive/send Diameter messages should be registerd in DNS.
In that case, what extra information does the Host-IP-Address AVP add with respecto to DNS?

If it provides duplicate information, it can be a source of conflict between DNS A/AAAA records and the advertised Host-IP-Address(es).
I think it would be better to use only 1 source of information between Origin-Host and IP address(es): either DNS or Host-IP-Address

But I suppose that at this stage, removing Host-IP-Address would create more interoperability issues that leaving it, and indicating which value(s) to send with TCP and specifying what a receiver should do with that information.

Let me put an example, where it might be interesting to have 2 Host-IP-Addresses with TCP, which I don't know if it would be feasable (and desirable) or not (or is a "mischievious" interpretation of the RFC's)

Imagine we have 2 servers (for Acct application for instance), each one configured with its own IP address (named IP1 & IP2).
But configured to be the backup of the other, sharing state between them, and sharing the same Origin-Host !!!
Server1 could advertise  in Host-IP-Address 2 IP's: IP1 (its own) & IP2 (its mated server) in its CEA messages.
And similarly for server2, also advertising the 2 IP's-

If the Diameter client (for Accounting I'm supposing that the client is the one always trying to establish the TCP connection) loses connectivity with IP1, and that IP1 is no longer reachable (or its Diameter server is temporarily down), then the Diameter client could try to contact IP2.
As the 2 servers are sharing state & Origin-Host, the Diameter client wouldn't be able to distinguish if IP1 & IP2 are 2 interfaces of the same server, or not.
But that would be a way for the Diameter server to have High Availability, without the need for 3rd party software to configure a Cluster sharing a virtual IP address.
And that redundancy could even be geographical, as IP1 & IP2 need not be in the same subnet.

But for that:
1.- Several Host-IP-Address ocurrences should be allowed to be sent in the CER/CEA messages, both with TCP & SCTP (or alternatively configured in the DNS servers)
2.- It should be specified somewhere in a RFC that the Diameter peers establishing a Diameter transport connection should retry secuentially to the advertised Host-IP-Addresses in the last received CER/CEA message (or configured addresses in DNS)

Best Regards,
  Pedro

________________________________
From: [email-masked] [mailto:[email-masked]] On Behalf Of Ankur Garg
Sent: Friday, September 21, 2012 9:10 AM
To: Glen Zorn
Cc: [email-masked]
Subject: Re: [Dime] [RFC3588bis-34] - Host-IP-Address AVP

Hello,

Ankur Garg
________________________________

The draft says:

...

---

From: Ralph Loader <[email-masked]>
Date: Tue, 25 Sep 2012 07:31:50 +1200

> address from which the CEr/CEA command was sent?

There are other problems with using the AVP to obtain IP addresses:

1.  The set of IP addresses assigned to a machine can change.  Unlike proper protocols for distributing IP addresses, the capabilities exchange has no mechanism for handling that.

2.  There is no guarentee that a particular IP address of a machine is accessable from a peer (address scoping, firewalling, NAT...).

I don't see any reason for Diameter to reinvent the wheel in distributing IP addresses.

Just leave the field as advisory for logging / debugging purposes (ditto all the other underspecified fields in the capabilities exchange, for that matter).

Cheers,
Ralph.

>  If my solution to

---

From: Ralph Loader <[email-masked]>
Date: Tue, 25 Sep 2012 07:42:40 +1200

> 
> 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.

Best just to treat the field as informational.

Ralph.

---

From: jouni korhonen <[email-masked]>
Date: Tue, 25 Sep 2012 10:18:28 +0300

> 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.

> 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.

- Jouni

---

From: jouni korhonen <[email-masked]>
Date: Tue, 25 Sep 2012 10:32:47 +0300

Hi,

Just few questions for my education and some comments inline.

> 1.  The set of IP addresses assigned to a machine can change.  Unlike proper protocols for distributing IP addresses, the capabilities exchange has no mechanism for handling that.

RFC6737.

> 2.  There is no guarentee that a particular IP address of a machine is accessable from a peer (address scoping, firewalling, NAT...).

How would the situation be any different if "proper protocols" were used?

> I don't see any reason for Diameter to reinvent the wheel in distributing IP addresses.

There is a clear use case for SCTP.

- Jouni

---

From: Ralph Loader <[email-masked]>
Date: Tue, 25 Sep 2012 21:19:11 +1200

> did bind to. The addresses it might put into host-ip-address do

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 192.168.1.1, on node B's network, 192.168.1.1 is assigned to a completely different machine.

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?

> 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).

Ralph.

---

From: jouni korhonen <[email-masked]>
Date: Tue, 25 Sep 2012 13:25:14 +0300

> E.g., node A, node B are both behind different firewalls, node A binds to 192.168.1.1, on node B's network, 192.168.1.1 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
problems.

> 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.

- Jouni