File 3261-Decode-encode-Address-types-other-than-IP-and-IP6.patch of Package erlang

From 8a0d1eedf1313fac25dceeaac964d806843ecb95 Mon Sep 17 00:00:00 2001
From: Anders Svensson <anders@erlang.org>
Date: Mon, 14 Mar 2022 19:00:28 +0100
Subject: [PATCH 1/2] Decode/encode Address types other than IP and IP6

RFC 6733 defines the Diameter Address type as follows.

  4.3.1.  Common Derived AVP Data Formats

     Address

        The Address format is derived from the OctetString Basic AVP
        Format.  It is a discriminated union representing, for example, a
        32-bit (IPv4) [RFC0791] or 128-bit (IPv6) [RFC4291] address, most
        significant octet first.  The first two octets of the Address AVP
        represent the AddressType, which contains an Address Family,
        defined in [IANAADFAM].  The AddressType is used to discriminate
        the content and format of the remaining octets.

IP and IP6 are AddressType 1 and 2 respectively, but there are many more
defined in IANAADFAM, here:

  http://www.iana.org/assignments/address-family-numbers/address-family-numbers.xhtml

None of these additional values were decoded/encoded in module
diameter_types. All were treated as errors.

The definition of other address families is spread across many different
documents, not all of which are easily accessible or even identified by
IANAADFAM, and the list can change. Given that the current decode has
been in place for over 10 years now (ie. this has clearly not been a big
problem), only provide a minimal decode of non-IP address families,
splitting them into a 2-tuple of unreserved 16-bit family and remaining
binary with no family-specific decode. Encode maps the 2-tuples back to
binary, and accepts address families 1 and 2 as well.

Note that even currently unassigned address families are decoded: only
the reserved values (0 and 65535) are treated as errors.

Decoding the binary to a 2-tuple at all is debatable since there's
hardly anything to gain over simply treating Address like OctetString,
with only validation that it contains an unreserved 2-octet AddressType,
but choose the tuple for consistency with the IP address decodes. It's
still possible to add family-specific decodes in the future with a
decode option, similar to the existing {string_decode, boolean()}.
---
 lib/diameter/src/base/diameter_types.erl | 12 +++++++++++-
 1 file changed, 11 insertions(+), 1 deletion(-)

diff --git a/lib/diameter/src/base/diameter_types.erl b/lib/diameter/src/base/diameter_types.erl
index 86b674dd48..79312dfe13 100644
--- a/lib/diameter/src/base/diameter_types.erl
+++ b/lib/diameter/src/base/diameter_types.erl
@@ -1,7 +1,7 @@
 %%
 %% %CopyrightBegin%
 %%
-%% Copyright Ericsson AB 2010-2017. All Rights Reserved.
+%% Copyright Ericsson AB 2010-2022. All Rights Reserved.
 %%
 %% Licensed under the Apache License, Version 2.0 (the "License");
 %% you may not use this file except in compliance with the License.
@@ -247,9 +247,19 @@
        2 == A, 16 == byte_size(B) ->
     list_to_tuple([N || <<N:A/unit:8>> <= B]);
 
+%% Bytes for non-IP address types are left for the user to interpret.
+'Address'(decode, <<A:16, B/binary>>, _)
+  when 2 < A, A < 65535 ->
+    {A, B};
+
 'Address'(decode, B, _) ->
     ?INVALID_LENGTH(B);
 
+%% Allow IP address types as both 2- and 4/8-tuples.
+'Address'(encode, {A, B}, _)
+  when 0 < A, A < 65535 ->
+    <<A:16, B/binary>>;
+
 'Address'(encode, T, _) ->
     Ns = tuple_to_list(diameter_lib:ipaddr(T)),  %% length 4 or 8
     A = length(Ns) div 4,                        %% 1 or 2
-- 
2.34.1