A Generic Referral Object for Internet Entities
Department of Computer Science
University of Auckland
PB 92019
Auckland
1142
New Zealand
brian.e.carpenter@gmail.com
France Telecom
3, Avenue François Châteaux
Rennes
35000
France
mohamed.boucadair@orange-ftgroup.com
Cisco
146 Honness Lane
Ithaca
NY
14850
US
swb@employees.org
Ericsson
P. O. Box 6049
Leesburg
VA
20178
US
jhalpern@redback.com
Huawei Technologies Co., Ltd
KuiKe Building, No.9 Xinxi Rd.,
Shang-Di Information Industry Base, Hai-Dian District, Beijing
P.R. China
shengjiang@huawei.com
Network Heretics
moore@network-heretics.com
Transport
BEHAVE
The purpose of a referral is to enable a given entity in a multiparty application to pass information to another party. This memo specifies a Generic Referral Object (GRO) to be used in the context of referrals. The proposed object is compact and is application-independent. Both IPv4 and IPv6 schemes are supported, as well as upper layer identifiers. Additional information to characterise an enclosed reference is also described. To allow proper interpretation of referrals,
a new notion of scope identifiers is introduced.
A frequently occurring situation is that one entity A connected to the Internet (or to some private network
using the Internet protocol suite) needs to inform another entity B how to reach either A itself or some third-party entity C. This is known as a referral.
In the original design of the Internet, IP addresses were global, unique, and quasi-permanent.
Also any differentiation beyond that provided by an IP address was done by protocol and port numbers. Referrals
were therefore performed simply by passing an IP address and possibly protocol and port numbers.
In fact simple referrals (the first case above,
sometimes called first-party referrals) were never
needed since B could simply use A's address. Third-party referrals were trivial: A would tell B about C's address.
Thus, it became common practice to pass raw addresses between entities. A classical example is the FTP
PORT command .
Unfortunately, this simple approach to referrals often fails in today's Internet. As has been
known for some time , addresses no longer all have global scope, and
may have limited lifetime. Both addresses and port numbers may be different on either side of a
NAT or some other middlebox , and firewalls may block them.
Also, the Internet now has two coexisting address formats for IPv4
and IPv6. Sending an out-of-scope or expired address, or one of the wrong format, as a referral
will fail.
In some cases, this problem may be readily solved by passing a Fully Qualified Domain Name (FQDN)
instead of an address. Indeed, that is an architecturally preferred solution .
However, it is not sufficient in many cases of dynamic referrals.
Experience shows that an application cannot use a
domain name in order to reliably find the address(es) of an arbitrary
peer. Domain names work fairly well to find the addresses of servers,
as in web servers or SMTP servers, because operators of public servers
take pains to make sure that their domain names work. But DNS records
are not as reliably maintained for arbitrary hosts such as might need to
be contacted in peer-to-peer applications. Many small networks do not even
maintain DNS entries for their hosts, and for some networks that do list
local hosts in DNS, the listings may well be unusable from a remote
location (say because of two-faced DNS, or because the A record contains
a private address). Furthermore, an FQDN may not be sufficient to establish successful communications involving heterogeneous peers (i.e. IPv4 and IPv6) since A and AAAA records may not be correctly provisioned.
Another problem is that an application does not have a reliable way of
knowing its own domain name - or to be more precise, a way of knowing a
domain name that will allow the application to be reached from another
environment.
For these reasons, the problem of address referrals cannot be solved just
by recommending the use of FQDNs instead.
The first motivation for this draft is the observation that unless the
parties involved have reached an understanding about the scope,
lifetime, and format of the elements in a referral through some other
means, that information must be passed with the referral. This is
required so that the receiving entity can determine whether or not the
referral is useful.
When a referral fails, good design suggests that the receiving entity should attempt
to correct the situation. For example, if communication fails to be established using an
IP address, it would often be appropriate to attempt a DNS lookup.
The second motivation for this draft is that it may be helpful to the
entity receiving a referral to also receive information about the source of the referral,
such as an FQDN, if that is known to the sender of the referral.
The receiving entity can then attempt to recover a valid address (and possibly port number)
for the referred entity.
It should be noted that partial or application-specific solutions to this problem
abound. A non-normative Appendix gives examples, in the form of use cases.
The objective of this specification is to define a generic and extensible
solution, to allow more robust application design. It is an open question whether
existing applications will benefit from retro-fitting GROs, or whether they will
mainly be of use for new applications.
This document makes use of the following terms:
"Generic Referral Object (GRO)": the data object defined by this specification.
"Entity": we use this rather than "application" to describe any software component embedded in
a host, not just a specific application, that sends, receives or makes use of GROs. Also,
in case of dynamic load sharing or failover, an entity might even migrate between hosts.
"Referral": the act of one entity informing another entity how to contact a specific entity.
"Reference": the actual data (name, address, identitifier, locator, pointer, etc.) that is
the basis of a referral.
"Scope Identifier (ScopeID): an identifier for the scope of validity of a reference.
"Qualifier": a data item that gives additional information about a Reference.
"Referring entity": the entity that sends a referral.
"Receiving entity": the entity that receives a referral.
"Referenced entity": the entity described in a GRO.
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in .
A GRO should be self-describing; that is to say, even if it is forwarded several
times across the network, the ultimate receiving entity should be able to extract
and interpret all the information inserted by the original referring entity.
A GRO should be compact (i.e., binary encoded) and designed for efficient processing.
The GRO format must not be specific to a given IP version and
must not be application-specific.
A GRO should contain information that the
referring entity can provide about the scope, lifetime, format
and source of the referral, encoded in a universal format.
The GRO format should be extensible with well-defined backwards compatibility.
A damaged GRO would be useless. However,
to maintain efficiency, intrinsic error detection or correction for GROs should not be mandatory.
Therefore, GROs SHOULD be sent over a channel supporting error detection or correction.
A forged GRO would be at least as dangerous as a forged IP address. However,
to maintain efficiency, intrinsic cryptographic authentication of GROs should not be mandatory.
The use of an authenticated channel to transmit GROs is RECOMMENDED.
An intercepted GRO would be at least as revelatory as an intercepted IP address.
However, to maintain efficiency, intrinsic encryption of GROs should not be mandatory.
The use of an encrypted channel to transmit GROs is RECOMMENDED.
The principal purpose of a referral is to enable one entity in a multi-party
application to pass information to another party involved in the same application.
This specification makes no assumptions about whether the entities are acting
as clients, servers, peers, super-nodes, relays, proxies, etc., as far as the
application is concerned. Neither
does it take a position as to how the various entities become aware of the need to
send a referral; this depends entirely on the structure of the application.
It is the
responsibility of the referring entity to construct a GRO on the basis of information
in its possession.
It is the responsibility of the receiving entity to interpret
and check this information. Due to the fluidity of connectivity in today's Internet,
the referring entity cannot guarantee that the referenced entity can be reached. This
can only be checked by the receiving entity. In the event of a reachability problem,
information in the GRO may assist the receiving entity to find an alternative path.
Since the most fundamental quantity likely to be conveyed in a GRO is an IP address,
(and possibly a port number) its scope is a key question.
Address scope is not a simple concept, as shown by the discussion in
and the practical difficulties caused by . Even the concept of link-local
scope is complicated by the existence of multi-link subnets . For the purpose
of referrals, it seems that previous formalisations of the concept of scope
are inadequate. Assuming that a GRO is trustworthy, one question that a receiving entity
must answer is: can the address in this GRO be reached from here? That question is not answered by knowing only
the scope (in the sense of RFC4007) as defined at the location of the referring entity.
For that reason, scope is represented in a new way in GROs. Firstly, the scope is qualified
(to the best of the referring entity's knowledge) as follows:
Null. The address is known not to be applicable outside the referring host (e.g., a loopback
address). This option is provided mainly for completeness. There is no value in such a GRO,
and for privacy reasons it should not be communicated anyway.
Link. Apart
from the standard Ethernet-like view of link locality, this scope would also apply
to point-to-point links and to fragments of a multi-link subnet. Although on-link referrals
should be trivial, this case is included to allow for uniform design of applications
utilising GROs, so that link-local does not become a special case.
Limited. The address has applicability beyond the link, but it is known not to have global
applicability. Examples include IPv4 private addresses and
IPv6 Unique Local Addresses . Other cases include addresses on subnets
which the referring entity knows to be obstructed by firewalls, network address translators,
or other barriers to transparency .
Global. The address has applicability beyond the link, and is believed to have global
applicability within its address family.
However, particularly in the case of limited scope, this is insufficient for the receiving entity
to decide whether the address is applicable in the receiving entity's context. The scopes above
are described as if they were a set of concentric circles, but reality is more complex, and limited
scopes might overlap each other in an arbitrary way, for example when multiple VPNs are formed.
Indeed, a referring entity may or may not be aware that the receiving entity and the referenced entity
are within a link scope or limited scope that does not contain the referring entity. Therefore, a GRO may
also include a scope identifier (ScopeID), which is an arbitrary label for a region of the network within
which certain link or limited scope addresses are applicable.
There needs to be a high level of assurance that ScopeIDs are unique, or at least
that a GRO will never be forwarded outside a region in which ScopeIDs are unique.
Also, all referring and receiving entities need to be aware of the ScopeID(s)
that apply to them. However, it is clearly undesirable to create a new global registration
scheme for ScopeIDs.
The delimiter of a limited scope will in many cases be the device
(firewall or NAT) that obstructs transparency. A tempting solution would be to use
some unique identifier of that device as the unique ScopeID. Unfortunately, this
cannot be an IP address of the device, since in the case of nested NATs, all its addresses
may be ambiguous. Neither can we rely on such a device having its own FQDN, or on that
FQDN being known to all entities within the scope concerned. Finally, some limited scopes
may not be hidden behind a single such device; for example, a limited scope might
consist of a company's network and selected VPN connections to subsets of several business
partners' networks. Alternatively, multiple limited scopes might be hidden behind the
same device. Device addresses are therefore not suitable as ScopeIDs.
Therefore, a limited scope can best be defined as whatever set of referring and receiving
entities have been configured (statically or dynamically) to accept a given ScopeID
in some unambiguous namespace (see ).
Methods for configuring, advertising and discovering ScopeIDs are not defined in this document.
However, in their absence, it is extremely hard for receiving entities to interpret
and use information about limited scopes.
To the extent possible, all entities involved in referrals should
determine what scope is shared between the referred entity and the
receiving entity, by any means. Those means are not covered in this
document, but may include use of external services, agreement on scope
identifiers, or direct negotiation.
If shared scope (or set of scopes) is determined, a referral should ideally only include
information useful in that scope or set of scopes.
If shared scope is uncertain, a referral should include all
information that might be useful, taking privacy considerations into
account.
In general, the referring entity cannot know the scope in which
the GRO will be interpreted. For example, the initial receiving entity may itself be
behind a NAT, unknown to the referring entity, or the receiving entity
may send the GRO onwards to another host in yet another scope. In practice,
we have to leave the receiver to decide whether certain information is useful
or not. In the case of a ScopeID in particular, the referring entity
is not required to know which ScopeIDs apply to the receiving entity.
Discovery or negotiation of ScopeIDs between referring, referenced and
receiving entities is certainly a possibility, but may be expensive, and is
not assumed by this specification.
A referring entity may obtain the address and port number for the referenced entity
in various ways, and knowledge about this may help the receiving
entity when combined with scope information. For example,
if the receiving entity is aware that the address has been translated, and that it has global
scope, it may choose to use it without further checks. If it is not marked as translated,
and has limited scope, the receiving entity may then verify whether it has a suitable ScopeID.
To enable such logic, a GRO may describe the source of an address or port number. How knowledge
of this source is obtained is outside the scope of the present specification, but ICE
is an example method. It is also out of scope here
to describe exactly how the receiving entity uses the information; for example GRO semantics do
not include or imply preferences or priorities when multiple addresses are provided.
The receiving entity may choose to use a predefined policy, apply general logic as sketched in the
previous paragraph, or follow application-specific logic, all based on the data provided
in a GRO.
Obviously, a GRO is no use unless it contains at least one item that can be used to
find a path to the referred entry. One option would be to make the presence of at least one IP address
mandatory. However, there are alternatives, the most obvious one being an FQDN. Any form of identifier-locator
separation, with HIP as an example, may also offer an alternative. Therefore, we
do not require a GRO to include an IP address, even though its inclusion is a very likely case.
A GRO is composed of a sequence of binary-encoded type-length-value fields (TLVs)
transmitted in network byte order. The TLV format is as follows:
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+..
| GRType |Q| GRLength | GRValue ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+..
A GRO MUST include at least one reference that allows a receiving entity to attempt to
establish a path to the referred entity. A typical case is an IPv4_address or IPv6_address TLV. Multiple
references may be present, and their order is not significant.
Apart from this, all TLVs are OPTIONAL.
[[ Discusssion invited: At the moment, there is no total length field or end flag for the whole GRO, assuming
that GROs will be sent in some kind of container. Opinions among the authors vary about whether
this is OK. ]]
GRType: Specifies the type of the current TLV. GRType is encoded in 7 bits.
The initially specified types are, in decimal:
0: EOQ.
1: IPv4_address.
2: IPv6_address.
3: FQDN.
4: HIT.
5: HI.
65: IPv4_mask.
66: IPv6_mask.
67: Ref_lifetime.
68: Ref_source.
69: Ref_scope.
70: ScopeID.
71: Port_number.
72: Transport_protocol.
73: Port_source.
127: reserved.
A receiving entity MUST silently ignore any TLV with an unknown or reserved GRType.
Each TLV is classified semantically as a reference or as a qualifier. A qualifier
provides extra information about a reference or another qualifier..
[[ Discusssion invited: Do we need a syntactic method of distinguishing references
from qualifiers? Since unknown TLVs are always discarded, why would that be needed? ]]
Q bit: If this bit is set to 1, the current TLV is followed by one or more TLVs
that qualify it.
GRLength: The length in bytes of the GRValue field. Thus, the total length of the
TLV is GRLength+2 bytes.
GRValue: The content and encoding depend on GRType. Any padding required to fill
an integral number of bytes MUST consist of a sequence of zero bits at the end of the content.
This TLV follows the last TLV that qualifies a TLV whose Q bit is set to 1.
Its GRLength must be set to 0.
The Q bit and EOQ MAY be used recursively, so that qualifiers may themselves be qualified if that
proves to be useful.
Example (GT=GRType):
GT Q|GT Q|GT Q|GT Q|GT Q|GT Q|GT Q|GT Q
A 1|xx 0|xx 0|B 1|xx 0|xx 0|EOQ 0|EOQ 0
<-------> Qualifiers of B
<----------------------------> Qualifiers of A
The Q bit MUST NOT be set in an EOQ TLV.
IPv4 and IPv6 addresses are encoded in their normal binary form,
with GRLength being 4 and 16 respectively.
When multiple addresses are provided, their order does not imply an order of preference.
The receiving entity SHOULD apply a local policy and mechanism to choose between alternative addresses,
using other information included in the GRO appropriately.
This document does not describe such policies and mechanisms, which could be
application specific.
The Fully Qualified Domain Name of the referenced entity in ASCII format according to .
The GRLength is variable (maximum 63).
[[ Discussion invited: Is there also value in a generic URI item?
See section on Extensibility below for a related discussion point. ]]
The Host Identity Tag of the referenced entity .
The GRLength must be set to 16.
The Host Identifier of the referenced entity .
The GRLength is variable.
[[ Discussion invited: Is this necessary in order to run the HIP base exchange?
The HI is a large object to include in a GRO. Also, do we need a more precise
definition of what the HI is (see section 5.2.8 of RFC5201)? ]]
IPv4 and IPv6 masks are encoded in their normal binary form,
with GRLength being 4 and 16 respectively.
Remaining lifetime in seconds of the reference that it qualifies, encoded as a 32 bit binary
number in the format of an IPv6 Valid Lifetime .
GRLength must be set to 4.
If the lifetime is absent, or if it indicates an infinite lifetime ,
the receiving
entity MUST assign a lifetime of one day to the corresponding reference.
The receiving entity MUST count down a received lifetime appropriately.
If the GRO is forwarded to an additional receiving entity, the lifetime
MUST be updated appropriately.
[[ Discussion invited: would it be better to specify an expiry timestamp? ]]
[[ Discussion invited: is the default of one day reasonable? ]]
This is a single byte indicating the source of the reference that it qualifies. GRLength must be set to 1.
The following values may be used:
0: source was static configuration
1: source was DNS lookup
2: source was DHCP or DHCPv6
3: source was SLAAC
4: relayed address (e.g. from TURN
or SOCKS)
5: translated address. ("server reflexive" in ICE
terminology.)
A receiving entity MUST silently ignore unknown values.
This is a single byte indicating the scope of the reference that it qualifies. GRLength must be set to 1.
The scopes are explained in . The currently defined values are as follows:
0: Null
1: Link
2: Limited
7: Global. Note that some unused values precede this value, in case of future changes.
A receiving entity MUST silently ignore unknown values.
References qualified with the Null value SHOULD NOT be sent and MUST be silently
ignored by a receiving entity.
When a receiving entity receives a reference qualified with a Link or Limited Ref_scope,
and without a ScopeID, it should take locally defined steps to check whether the reference is in fact
within a reachable scope.
A ScopeID, if present, is a label for the scope of the reference that it qualifies.
When a receiving entity receives a reference qualified with a Ref_scope
and a ScopeID, it should verify the ScopeID against a list of ScopeIDs known to be reachable
and if not, take other locally defined steps to check whether the reference is in fact
within a reachable scope.
ScopeIDs should be reasonably certain
to be unique, yet require no new system for central administration.
[[ Discusssion invited: It isn't clear to the authors that a single syntax for
ScopeID is sufficient. Should we allow for subtypes, so that (e.g.) ULA format
and FQDN format would both be possible? The following proposal is tentative. ]]
The proposed method is that
each organisation that needs to define a ScopeID will first generate a ULA prefix
as defined in , and then form a specific IPv6 address using
that ULA prefix. It is RECOMMENDED to form an address using a valid universal
EUI-64 interface identifier according to , and this EUI-64
identifier MAY be the same one as used in the RFC4193 procedure.
The GRLength must be set to 16. The GRValue is the ScopeID in the format of an
IPv6 address, although it will be treated entirely as an opaque binary value in
the GRO referring and receiving entities.
The inbound TCP/UDP/SCTP/DCCP port number associated with the reference that it qualifies.
The port number may be bound to a specific transport protocol (see next item).
The GRLength must be set to 2.
This TLV MAY be qualified by Transport_protocol or Port_source TLVs.
An IP address may be qualified by zero, one or several Port_number TLVs.
This is a single byte indicating the IPv4 protocol number or IPv6 Next Header value used with the reference or Port_number that it qualifies. GRLength must be set to 1.
A receiving entity MUST silently ignore unknown values.
This is a single byte indicating the source of the Port_number that it qualifies. GRLength must be set to 1.
Accepted values are:
0: direct (i.e. known to be the original port number used by the referenced entity)
4: relayed port (e.g. from TURN
or SOCKS)
5: translated port. ("server reflexive" in ICE
terminology.)
[[ Discussion invited: Is this distinction usfeul? ]]
The assigned values were chosen to align with those for Ref_source.
A receiving entity MUST silently ignore unknown values.
Additional GRTypes may be assigned in the range up to 126 by IANA action as defined in
. The documentation of a new GRType must specify its name, define its
GRLength, and describe the contents and meaning of its GRValue, including whether it is
a reference or a qualifier.
This extensibility is not intended to allow a GRO to grow enough to
contain every possible kind of application-layer identifier
that could ever be used in a referral, because then it would be too hard
to write a generic "please connect me to the peer at this GRO" function. Thus, additional
GRTypes SHOULD NOT be assigned except for generic purposes that will apply to multiple
applications. Similarly, additional sub-types for Address_source, Address_scope,
Transport_protocol, and Port_source SHOULD NOT be assigned except for generic purposes.
[[ Discussion invited: Sheng Jiang suggested that there should be a generic 'Application-specific
ID' GRType, for example in URI format. A problem with this is that it might end up
as a catch-all like a DNS TXT record, and threaten interoperability as a result. ]]
The reserved GRType value 127 is intended to be used to define an extended
range of GRTypes in the highly unlikely event that this becomes necessary.
Forged or intercepted GROs would enable a wide variety of attacks.
Although not fundamentally different from attacks based on forged or observed IP addresses or FQDNs, no doubt
GROs would allow such attacks to be more ingenious, simply because they provide more information than
an address or FQDN alone. As noted in , GROs SHOULD be transmitted through authenticated and encrypted channels. Since this is a requirement of the channel and not of the GRO, and the channel used
depends on a specific use case, it is not further elaborated here.
GROs are variable length objects with no defined maximum length. It is possible that a malicious GRO
could be constructed, with harmful code masquerading as legitimate or unknown GRType items.
All implementations of receiving entities MUST guard against buffer overflows, as well as obeying
the rules about ignoring unknown values in .
Unknown TLVs in GROs are to be ignored by the receiving entity. However, GROs may be forwarded
to additional receiving entities, in which case the unknown TLVs will be forwarded too. A
receiving entity MAY remove unknown TLVs before forwarding a GRO, as a precaution
against malicious use.
GROs raise potential privacy issues, which are not explored in this document. For example,
in the SIP context, mechanisms such as and
are available to hide information that might identify end-points. Usage scenarios for GROs MUST ensure
that they do not unintentionally defeat privacy solutions.
IANA is requested to established a Generic Referral Object (GRO) registry, containing sub-registries
for GRType, Ref_source, Ref_scope, and Port_source. The range and initial assignments
are defined in .
New values in this registry are to be assigned according to the Specification Required policy
defined in , which implies review by a Designated Expert according
to .
[[ Discussion invited: It has been suggested to define a (small) registry for Global ScopeIDs,
instead of assuming that "global" for IPv4 and IPv6 is unambiguous. ]]
This document originated from a Thai Lunch BOF (a variant of a Bar BOF) at IETF74.
Valuable comments and contributions were made by Dan Wing, ...
This document was produced using the xml2rfc tool
.
draft-carpenter-referral-object-00: original version, 2009-05-11
&RFC2119;
&RFC4861;
&RFC4193;
&RFC4291;
&RFC1035;
&RFC5226;
&RFC2629;
&RFC2101;
&RFC0959;
&RFC3484;
&RFC4903;
&RFC4007;
&RFC2775;
&RFC1918;
&RFC1958;
&RFC5201;
&RFC3234;
&RFC4091;
&RFC4092;
&RFC3323;
&DRAFT-sipriv;
&DRAFT-ice;
&DRAFT-turn;
&DRAFT-atypes;
[[ This appendix is incomplete and preliminary. ]]
Referrals may be used to add an entity to a multi-party conversation, or they may be used
(in applications such as telephony) as the first step of transferring one end of
a conversation from the referring entity to the receiving entity. [[ Say more? ]]
TBD: FTP/PORT, HTTP referrals... text needed
BitTorrent is a distributed file sharing infrastructure. It is based on P2P techniques for exchanging files between connected users. Three parties are involved in a BitTorrent architecture: (1) The server into which, has been uploaded the torrent file. (2) The Tracker which maintains a list of clients which have the file or some portions of that file. (3) Entities which are downloading and/or uploading portions of the file. In order to download a given file, a BitTorrent client needs to obtain the corresponding torrent file (i.e. a file which includes the meta-data information of the file to be shared: the file name, its length, a hash and the URL of the tracker.). Then, it connects to the tracker to retrieve a list of lechers (clients which are currently downloading the file but do not yet detain all the portions of the file) and seeders (clients which detain all the portions of the file and are uploading them to other requesting clients). The client connects to those machines and downloads the available portions of the requested file.
In a GRO for Skype purposes, if the address fails, you'd have to fall back to the Skype ID
instead of an FQDN. This is a case where allowing an application-specific ID might be valuable.
Another case would be Lotus Domino databases - if both IP address and FQDN fail to find the relevant server,
the server name and the database name could be used as fallback identifiers.
In SIP environments, a SIP Proxy Server intervenes in the placement of SIP sessions between two UAs. Particularly, the SDP part of relayed SIP messages includes required information for establishment of RTP sessions (particularly IP address and port number). A media description may be unidirectional or symmetric. ICE and ANAT allow listing several network types and addresses in the same SDP offer.
ANAT: ANAT , is a procedure used by Dual Stack UAs to provide both IPv4 and IPv6 addresses in the context of a single logical media stream. This helps interworking as, whatever the distant UA version is (IPv4/IPv6-only or Dual-Stack) provided that this latter is able to understand at least one of the offers. ANAT semantic does not allow to characterize the IP address(es) it carries. For instance, no indication if the UA is behind a translator or not is supported by ANAT (or even ICE). ICE deprecates ANAT attribute.
Atypes : atypes is a SIP media feature tag which indicates the IP address type capabilities of the UA (User Agent) and can aid the routing process and ease the invocation of required functions (e.g. SIP-ALG, NAT64, NAT46) when heterogeneous (i.e. IPv4 and IPv6) parties are involved in a given SIP session. Atypes can be used jointly with GRO (also with ICE and ANAT) to optimise the media path as experienced between involved parties (especially when Dual-stacks UAs are involved).