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

[jouni korhonen <[e-mail]>]

Hi,

Just few questions for my education and some comments inline.

On Sep 24, 2012, at 10:31 PM, Ralph Loader wrote:

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

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


> 
> 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 
>> 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
>> [e-mail]
>> https://www.ietf.org/mailman/listinfo/dime
> _______________________________________________
> DiME mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/dime