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

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" <glenzorn@gmail.com> 
To: "Ben Campbell" <ben@nostrum.com> 
Cc: dime@ietf.org 
Sent: Friday, September 21, 2012 12:24:08 PM 
Subject: Re: [Dime] [RFC3588bis-34] - Host-IP-Address AVP 

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 
 > ___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: 

    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. 

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. 

... 

_______________________________________________ 
DiME mailing list 
DiME@ietf.org 
https://www.ietf.org/mailman/listinfo/dime 