Internet Engineering Task Force W. Augustyn, Ed. Internet-Draft 12 February 2023 Intended status: Standards Track Expires: 16 August 2023 IP Addressing with References (IPREF) draft-augustyn-intarea-ipref-00 Abstract This document describes IP addressing with references (referred to as IPREF) and how it can be used with IPv4 and IPv6. IPREF is a private-to-private technology where hosts on private networks communicate with hosts on other private networks directly. Special addresses, called IPREF addresses, are used for the purpose. It also describes how hosts on private networks may publish their IPREF addresses via Domain Name System (DNS). Status of This Memo This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at https://datatracker.ietf.org/drafts/current/. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." This Internet-Draft will expire on 16 August 2023. Copyright Notice Copyright (c) 2023 IETF Trust and the persons identified as the document authors. All rights reserved. Augustyn Expires 16 August 2023 [Page 1] Internet-Draft IP Addressing with References (IPREF) February 2023 This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/ license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Revised BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Revised BSD License. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 1.1. Requirements Language . . . . . . . . . . . . . . . . . . 3 1.2. IPREF Terminology . . . . . . . . . . . . . . . . . . . . 3 2. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . 3 2.1. IPREF Addresses . . . . . . . . . . . . . . . . . . . . . 4 2.2. Packet Exchange . . . . . . . . . . . . . . . . . . . . . 5 2.3. DNS with IPREF . . . . . . . . . . . . . . . . . . . . . 8 3. IPREF Reference . . . . . . . . . . . . . . . . . . . . . . . 10 4. IPREF Address . . . . . . . . . . . . . . . . . . . . . . . . 10 5. Embedding References in IP Packets . . . . . . . . . . . . . 11 5.1. IPv4 Option . . . . . . . . . . . . . . . . . . . . . . . 11 5.2. IPv6 Extension Header . . . . . . . . . . . . . . . . . . 11 5.3. UDP Tunnel . . . . . . . . . . . . . . . . . . . . . . . 11 6. Distributing IPREF Addresses . . . . . . . . . . . . . . . . 12 6.1. DNS Records . . . . . . . . . . . . . . . . . . . . . . . 12 6.2. Local Network Resolver . . . . . . . . . . . . . . . . . 13 6.3. DNS Agent . . . . . . . . . . . . . . . . . . . . . . . . 13 7. Related Technologies . . . . . . . . . . . . . . . . . . . . 13 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 14 9. Security Considerations . . . . . . . . . . . . . . . . . . . 14 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 14 10.1. Normative References . . . . . . . . . . . . . . . . . . 14 10.2. Informative References . . . . . . . . . . . . . . . . . 14 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 15 1. Introduction Normally, hosts on private networks are only reachable by other hosts on the same private networks. To make them visible to hosts on other networks, techniques such as Network Address Translation (NAT), popular with IPv4 private networks, or filtering, more likely found with IPv6 private networks, are used to make them appear on the public Internet. In most cases, only selected services, determined by their layer 4 port numbers, are made available through these methods. Services from different private hosts may share a single public address. Augustyn Expires 16 August 2023 [Page 2] Internet-Draft IP Addressing with References (IPREF) February 2023 This document describes a different way of accessing hosts on private networks. It is done by enhancing capabilities of existing layer 3 protocols. The enhancement provides for addressing with references where the source and destination is specified by means of references rather than concrete addresses. The respective private networks, communicating in this manner, use these references to render actual addresses on their local networks. Reference are single values, unsigned integers, which are carried in addition to the existing addresses by the layer 3 protocols. In theory, any layer 3 protocol can operate in the manner described. For practical purpose, this document discusses only the case of IPv4 and IPv6. 1.1. Requirements Language The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here. 1.2. IPREF Terminology IPREF - short name referring to the technology described in this document, pronounced I-P-REF _third_ network - network connecting communicating private networks, e.g.: the Internet _encoding_ network - network representing hosts on peer private networks 2. Overview IP addressing with references (IPREF) is intended for communication between private networks connected via a _third_ network, typically the Internet. The references are opaque integers that factor in calculating of actual addresses at the respective private networks. References are not direct IP addresses. Each private network makes their calculations independently irrespective of how their peers might be interpreting the same references. The resulting addresses are normally different (they may be the same by chance) and are not known to the peers. IPREF deals with private networks, there is no intention to communicate directly with 'public' hosts, i.e. hosts with addresses on the _third_ network. There is no need to. These 'public' hosts Augustyn Expires 16 August 2023 [Page 3] Internet-Draft IP Addressing with References (IPREF) February 2023 normally reside on private networks anyway. They are made available on the 'public' network using techniques such as NAT or filtering. Since they reside on private networks, they can be reached through IPREF directly without NAT mapping or creating special filters. In case of IPv6 private networks, local addresses may be globally routable. In spite of that, they may or may not be reachable from peer private networks. IPREF is not concerned with it, it works the same way regardless. Similarly, IPv4 private networks may include hosts with globally routable addresses, it's immaterial. With IPREF, peer networks still don't know, and don't need to know, what those addresses are and to which protocol they belong. IPREF is a form of network address translation but it is never referred to it by this term to avoid confusion with well known NAT. It is always referred to as IPREF. It is an evolution of address rewriting technology. 2.1. IPREF Addresses The references are used in conjunction with standard IP addresses from the _third_ network. These are typically addresses of gateway interfaces where the packets arrive at or where they are being sent from. A combination of a _third_ network IP address and the reference is called an IPREF address, Figure 1. ┌───────────────────┬───────────────────┐ │ IP address │ reference │ └───────────────────┴───────────────────┘ 198.51.100.11+700 2001:db8::abc:11+700 Figure 1: IPREF address In the notation, a plus sign '+' is used to separate the IP address from the reference. In a packet exchange, there is a source IPREF address and a destination IPREF address, thus two references. The destination reference is allocated by the destination private network while the source reference is allocated by the source private network. There are no negotiations. Each peer defines their own references and accepts peer references as opaque values. Augustyn Expires 16 August 2023 [Page 4] Internet-Draft IP Addressing with References (IPREF) February 2023 2.2. Packet Exchange Figure 2 depicts how two local networks communicate with one another. Local network A has two standard hosts A5, A7, and a gateway GWA. The gateway connects to the _third_ network, the Internet. Local network B has hosts B4, B6, and a gateway GWB. The gateway connects to the same _third_ network as gateway GWA. Only the gateways are aware of, and implement, IPREF processing. The hosts on both local networks, as well as any hosts or routers on the _third_ network are standard network devices, unaware of IPREF. For simplicity, the examples shows the case of IPv4 running on all three networks. The IP addresses on local networks may overlap but for simplicity are shown as distinct. Further, for ease of following the example, addresses related to local network A are odd while addresses related to local network B are even. Hosts on local network A communicate with hosts on other local networks, such as local network B, without knowing IP addresses on the peer networks or even without knowing network protocols employed by the peer networks. An _encoding_ network is used in lieu of the peer private network addresses. The peer hosts appear as if they were hosted on the _encoding_ network. This is a compatibility feature. It is possible to avoid such mapping at the cost of making local hosts IPREF aware. That case is not described here as it is dramatically simpler to use _encoding_ networks and leave existing hosts as-is, without any modifications. Augustyn Expires 16 August 2023 [Page 5] Internet-Draft IP Addressing with References (IPREF) February 2023 ╲ ╲ Encoding Network B: 10.192.0.0/10 Local Network B: 172.18.2.0/24 ╲ ╲ ┌──────┐ ╲ ╲ ┃ .66│ │ ┏━━━━━━━┓ ┠────┤ host │ ╲ 198.51.100.22 ┃ IPREF ┃.2 ┃ │ B6 │ ╭─┨ g-way ┠───────────┨ └──────┘ ┌──────┐ ╲ ╎ ┃ GWB ┃ ┃ │ │.75 ┃ ╎ ┗━━━━━━━┛ ┃ │ host ├────┨ ╲ ╲ ┃ ┌──────┐ │ A5 │ ┃ Third Network ┃ .64│ │ └──────┘ ┃ ╲ ╲ ┠────┤ host │ ┃ ┏━━━━━━━┓ ╎ ┃ │ B4 │ ┃ .1 ┃ IPREF ┃ ╎ ╲ └──────┘ ┌──────┐ ┠───────────┨ g-way ┠─╯ │ │.77 ┃ ┃ GWA ┃ 198.51.100.11 ╲ │ host ├────┨ ┗━━━━━━━┛ │ A7 │ ┃ ╲ ╲ └──────┘ ╲ ╲ Local Network A: 172.17.1.0/24 Encoding Network A: 10.128.0.0/10 ╲ ╲ Figure 2: private networks Let's assume host A5 wants to send a packet to host B4 and receive a response. Prior to the packet exchange, an administrator from local network B informs an administrator of local network A that host B can be reached at an IPREF address 198.151.100.22+400. Local administrator enters that information on gateway GWA which in turn allocates an _encoded_ address of 10.128.0.40 to represent host B. This information is further passed to host A5 so that it can send packets to host B by using 10.128.0.40 as the destination. In step (1) host A5 places its own address as source, 172.17.1.75 and the provided address of host B 10.128.0.40 as destination. As the packet traverses the network, both source and destination addresses will be rewritten. It is illustrated in Figure 3. In step (2), the packet arrives at gateway GWA. The gateway realizes the destination is an _encoded_ address. It finds that the address corresponds to an IPREF address 198.51.100.22+400. It places this IPREF address in the packet as the new destination address. It also finds that the source address 172.17.1.75 does not correspond to any IPREF address so it allocates one through some algorithm, perhaps randomly, as 198.51.100.11+500. It places this IPREF address in the packet as the new source address. It then sends the packet into the _third_ network. This is the common network, the Internet, that both local Augustyn Expires 16 August 2023 [Page 6] Internet-Draft IP Addressing with References (IPREF) February 2023 networks A and B connect to. In step (3) the packet arrives at gateway GWB. The gateway recognizes the destination IPREF address as representation of the internal host's B address 172.18.2.64. It places this address in the packet as new destination address. The gateway does not recognize the source IPREF address so it allocates an _encoded_ address for it 10.192.0.70. It places this address in the packet as the new source address. It, then, sends the packet to the local host B4. In step (4), local host B4 receives the packet and recognizes the destination address as its own. It consumes the packet and processes it according to the payload. Host B4 has IPREF address: 198.51.100.22+400 encoded at GWA as: 10.128.0.40 Host A5 is allocated IPREF address: 198.51.100.11+500 encoded at GWB as: 10.192.0.70 Sending a packet from A5 to B4 and receiving a response back at A5: ┌───────────────────┬───────────────────┬─────────┐ 1 A5: │ 172.17.1.75 │ 10.128.0.40 │ payload │ └───────────────────┴───────────────────┴─────────┘ ┌───────────────────┬───────────────────┬─────────┐ 2 GWA: │ 198.51.100.11+500 │ 198.51.100.22+400 │ payload │ └───────────────────┴───────────────────┴─────────┘ ┌───────────────────┬───────────────────┬─────────┐ 3 GWB: │ 10.192.0.70 │ 172.18.2.64 │ payload │ └───────────────────┴───────────────────┴─────────┘ ┌───────────────────┬───────────────────┬─────────┐ 4 B4: │ 10.192.0.70 │ 172.18.2.64 │ payload │ └───────────────────┴───────────────────┴─────────┘ ┌───────────────────┬───────────────────┬─────────┐ 5 B4: │ 172.18.2.64 │ 10.192.0.70 │ payload │ └───────────────────┴───────────────────┴─────────┘ ┌───────────────────┬───────────────────┬─────────┐ 6 GWB: │ 198.51.100.22+400 │ 198.51.100.11+500 │ payload │ └───────────────────┴───────────────────┴─────────┘ ┌───────────────────┬───────────────────┬─────────┐ 7 GWA: │ 10.128.0.40 │ 172.17.1.75 │ payload │ └───────────────────┴───────────────────┴─────────┘ ┌───────────────────┬───────────────────┬─────────┐ 8 A5: │ 10.128.0.40 │ 172.17.1.75 │ payload │ └───────────────────┴───────────────────┴─────────┘ Figure 3: address rewriting Augustyn Expires 16 August 2023 [Page 7] Internet-Draft IP Addressing with References (IPREF) February 2023 In step (5), host B4 sends a response back to host A5. It reverses source and destination addresses and sends a packet to gateway GWB. In step (6), the packet arrives at gateway GWB. The gateway recognizes the destination address as an _encoded_ address previously created to represent IPREF address 198.51.100.11+500. It places this IPREF address in the packet as the new destination address. The gateway also recognizes the source address as corresponding to a preset IPREF address 198.51.100.22+400. It places this IPREF address as the new source address. It then sends the packet to the _third_ network. In step (7), the packet arrives at gateway GWA. The gateway recognizes the destination IPREF address as corresponding to the local host A5 172.17.1.75. It places this address in the packet as the new destination address. It also recognizes the source IPREF address as one represented by an _encoded_ address 10.128.0.40. It places that address in the packet as the new source address. It then sends the packet to the local host A5. in step (8), local host A5 recognizes the destination address 172.17.1.75 as its own and consumes the packet for processing. This concludes packet exchange. In general case, networks may have overlapping addresses, they may have several local subnets, they may have more than one gateway to the _third_ network. They may also run different network protocols. For example one private network may run IPv4 while its peer may run IPv6. The communicating networks do not need to know their peers' actual IP addresses or network protocols. The references are the stand ins representing those addresses in their native network protocol domains. The references are interpreted independently by both communicating networks. In the example above, network B allocates reference '400' to represent host B4. At network B, that reference is interpreted as 172.18.2.64 whereas that same reference is interpreted as 10.128.0.4 at network A. Neither network knows, or is concerned with, how the references are interpreted outside of their own administrative domains. In cases where interpretation involves changing network protocols, the local gateway must run dual stacks and perform proper repackaging of the payload. Of course, higher level protocols such as TCP/UDP, must be compatible for this to be practical. 2.3. DNS with IPREF Similarly to standard IP, IPREF can operate with or without DNS. IPREF addresses may be entered and distributed manually. For example, an /etc/hosts file could be used for the purpose. Such use makes sense in certain cases. Especially on private networks, the practice of using direct addresses is common even if local DNS names are allocated to the hosts. Augustyn Expires 16 August 2023 [Page 8] Internet-Draft IP Addressing with References (IPREF) February 2023 IPREF can also take full advantage of DNS. IPREF addresses are publishable. When resolving names that render IPREF addresses, local resolvers must obtain translation into _encoded_ addresses for standard hosts on local networks. This is the normal case, only IPREF gateways understand IPREF addresses, the vast majority of hosts are standard hosts which are unaware of IPREF. The necessary mapping to _encoded_ addresses is typically made by IPREF gateways and presented back to resolvers which pass them to the querying hosts. In addition, IPREF gateways must be aware of all local hosts whose IPREF addresses are published through DNS. This is illustrated in Figure 4. ╲ ┏━━━━━━━━┓ ╲ ┃ public ┃ ┃ DNS ┃ <╌╌ public DNS queries ┌──────┐ ╲ ┃ server ┃ │ │.75 ┃ ┗━━┯━━━━━┛ │ host ├────┨ ╲ ╎ │ A5 │ ┃ ╎ └──────┘ ┃ ╲ ╎ ┃ ┏━━━━┷━━┓ ┃ .1 ┃ IPREF ┃ ┌──────┐ ┠────────────┨ g-way ┠─ │ │.77 ┃ ┃ GWA ┃ │ host ├────┨ ┗━━┯━━━━┛ │ A7 │ ┃ ╎ ╲ └──────┘ ╎ ╎ ╲ ┏━━━━━━┷━━━┓ ┃ local ┃ ╲ local DNS queries <╌╌ ┃ DNS ┃ <╌╌ DNS query responses ┃ resolver ┃ ╲ Local Network A ┗━━━━━━━━━━┛ ╲ Figure 4: DNS with IPREF Local hosts A5 and A7 resolve DNS names via a local resolver. The resolver queries DNS servers on their behalf. A query may return a standard IPv4 or IPv6 address, or it may return an IPREF address. In the former cases, the IP addresses are simply returned to the querying hosts. In case of IPREF addresses, the resolvers consults related IPREF gateway for a mapping to an _encoded_ network. The gateway may allocate one on the fly if mapping is not available. The resulting _encoded_ IP address is then returned to the querying hosts. Augustyn Expires 16 August 2023 [Page 9] Internet-Draft IP Addressing with References (IPREF) February 2023 Local network administrator may decide to publish IPREF addresses of some internal hosts via DNS. The IPREF gateway must be aware which hosts have been made available externally and what IPREF addresses have been assigned to them. Typically, this is a semi-static configuration which remains stable for long periods of time. The gateways may query those DNS servers for information periodically or some other mechanism may be employed to pass that information to the IPREF gateways. Returning to the packet exchange example shown in Figure 3, the IPREF address of host B4 may be published via a public DNS server maintained by the administrator of local network B. In that case, host A5 may simply use a DNS name of that host and ask local resolver to provide the corresponding IP address. The resolver would query the DNS server, recognize the response as an IPREF address and consult local IPREF gateway for proper mapping to an _encoded_ IP address. That IP address would then be returned to host A5 which in turn would use it as the destination IP address. 3. IPREF Reference An IPREF reference is an unsigned integer 16 octets in size. Values 0-255 are reserved. Of the reserved values, only one is defined. The value of 0 indicates a null reference, i.e. a reference which is not subject to mapping, rather, it indicates the related IP address should be used directly. The registry of reserved reference values should be vested with IANA. For now, these values are listed here until a suitable request to establish such registry is made with IANA. References are meaningful only in the context of their local networks. Local administrators may divide them into fields for any purpose they deem useful. For example, the fields may reflect different sources of allocations, or provide extra security bits, or provide load balancing options, or provide A/B address ranges etc. The definition of these fields, their values, their use are fully under local administration control. The peers are unaware of these fields and treat the references as single opaque values. 4. IPREF Address An IPREF address is a combination of a layer 3 network address and a reference carried in the same packet. In notation, a plus sign '+' separates the two components. For example: 198.51.100.11+700 or 2001:db8::abc:11+700. Augustyn Expires 16 August 2023 [Page 10] Internet-Draft IP Addressing with References (IPREF) February 2023 5. Embedding References in IP Packets A reference is a network layer entity and the most natural place for embedding it would be a network layer header, such as an IPv4 option or an IPv6 extension header. Unfortunately, many Internet Service Providers drop options and extensions headers for various reasons. Even if they don't, network devices tend to put them on a slow processing path resulting in poor performance. For that reason, the most reliable way to embed references is to place them in the payload. One such common technique is tunneling where a reference could be placed in the payload along with the network packet being tunneled. 5.1. IPv4 Option With IPv4, references may be embedded in an IPv4 header option [RFC791]. It would be a new option type. It would contain an octet with option type and option number, an octet with length, and two octets reserved for possible future use while padding to four octet boundary. The source and destination references would then follow. A new option number would be registered with IANA. Until then, experimental option, 30, could be used. A separate document should describe it in detail. 5.2. IPv6 Extension Header With IPv6, references may be embedded in an IPv6 extension header [RFC8200]. It would be a new header type. It would contain an octet with next header type value, an octet with length, and two octets reserved for possible future use. This would be followed by four octets of padding to 8 octet boundary. Padding octets would not be intended for any future use. The source and destination references would then follow. A new protocol type would be registered with IANA. Until then, experimental protocol, 254, could be used. A separate document should describe it in detail. 5.3. UDP Tunnel Placing references in a UDP tunnel works for both IPv4 and IPv6. In both cases, the references are embedded in the form of respective option or extension header. In addition, a tunnel encapsulation record is added. The order of items is as follows: UDP header Augustyn Expires 16 August 2023 [Page 11] Internet-Draft IP Addressing with References (IPREF) February 2023 Tunnel encapsulation record IPREF option Packet payload The encapsulation record would consist of four octets. First octet would contain the value of TTL copied from the original IP header. The second octet would contain protocol number copied from the original IPv4 header or next header value form an IPv6 extension header. The third octet would report number of hops detected for incoming packets. The fourth octet would be reserved for possible future use while padding to 4 octet boundary. The IPREF option would follow in the format matching respective IP protocol, IPv4 or IPv6. The tunnel would operate at port 1045. This value would be registered with IANA. A separate document should describe the tunnel in detail. 6. Distributing IPREF Addresses IPREF addresses can be distributed via DNS [RFC1035] or possibly via other name resolution systems. In this document only the case of DNS is described. IPREF addresses are unlike well known IPv4 addresses or IPv6 addresses. These addresses consist of two components which must be considered as a single address entity. It is not possibly to separate references from their related _third_ network IP addresses. For that reason, there is a need for a new type of a resource record. 6.1. DNS Records IPREF addresses are published using new resource record tentatively called AA. This record type has not been registered yet. Until such time, a TXT record may be used. The TXT record simply holds a textual representation of an AA record. Here are some examples of what the records might look like: Host-B4 AA 198.51.100.22 + 400 Host-A5 AA net-A + 500 Host-A5 AA 2001:db8::abc:11 + 700 Host-A5 TXT "AA net-A + 500" The IP portion may be provided numerically or as a domain name. The format for the reference would allow unsigned decimal integers as well as unsigned hex integers. Other formats maybe be defined as well. Augustyn Expires 16 August 2023 [Page 12] Internet-Draft IP Addressing with References (IPREF) February 2023 The definition of the new resource record, its use, notation, and registration with IANA should be described in a separate document. 6.2. Local Network Resolver Local network resolver must provide capability to replace IPREF addresses with IP addresses from _encoded_ network in consultation with IPREF mappers. It's not clear if the details may be left to implementations or whether some sort of an exchange protocol needs to be defined. If so, a separate document would describe it. 6.3. DNS Agent A DNS Agent is a component of IPREF mappers that detects if any local hosts are advertised as reachable via IPREF addresses. There is a number of existing mechanisms to accomplish this. There is probably no need to define another one. In case, there is some reason for doing so, it would be described in a separate document. 7. Related Technologies IPREF works well with related technologies. It does not create conflicts and it does not attempt to step on their functionality. * IPv4 - IPREF does not replace IPv4, it is an optional add-on to enhance IPv4 capabilities in the area of address rewriting. It relies on IPv4 in all other functions of a network protocol. * IPv6 - IPREF does not replace IPv6, it is an optional add-on to enhance IPv6 capabilities in the area of address rewriting. It relies on IPv6 in all other functions of a network protocol. * NAT - IPREF is an address rewriting technology but operates differently than NAT. It operates exclusively at the network layer. It does not reach to upper layer protocols or lower layer protocols. For example, there is no manipulation of TCP/UDP ports. All layer 4 ports are carried transparently as-is. IPREF does not conflict with NAT. In a common configuration, a NAT gateway connects to the _third_ network without any changes. IPREF may operate in parallel to NAT on the same gateway, or it may operate on another gateway within the local network 'behind NAT'. * VPN - IPREF deals mostly with addressing. It does not perform typical functions of a VPN and it does not replace it. It behaves differently. A typical VPN makes hosts of a local network appear as if members of some other local network. Hosts subjected to a VPN are managed by that other private networks. This involves a Augustyn Expires 16 August 2023 [Page 13] Internet-Draft IP Addressing with References (IPREF) February 2023 substantial level of trust between the two private networks. IPREF does not do any of that. Hosts reachable through IPREF are firmly in their respective private networks and remain managed by their respective administrators. There may be cases where IPREF may be deemed sufficient for a particular purpose but in general IPREF is not a substitute for a VPN. IPREF does not conflict with VPNs. A VPN might use IPREF to establish a VPN connection. * Firewall - IPREF is not a firewall. While allocation or lack of allocation of references to local hosts has the effect of blocking or allowing access to them, blocking policy is best vested with a firewall. IPREF mappers deal with address rewriting, they are not packet filters. There is no conflict between firewalls and IPREF. Firewalls might need to be made aware of IPREF to be effective in their mission. 8. IANA Considerations This memo includes no requests to IANA. 9. Security Considerations This document should not affect the security of the Internet. Documents describing particular pieces of IPREF might. Proper security consideration statements would be included in those documents. 10. References 10.1. Normative References [RFC791] Postel, J., "Internet Protocol", RFC 791, September 1981, . [RFC1035] Mockapetris, P., "Domain names - implementation and specification", STD 13, RFC 1035, DOI 10.17487/RFC1035, November 1987, . [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 2017, . [RFC8200] Deering, S. and R. Hinden, "Internet Protocol, Version 6 (IPv6) Specification", STD 86, RFC 8200, DOI 10.17487/RFC8200, July 2017, . 10.2. Informative References Augustyn Expires 16 August 2023 [Page 14] Internet-Draft IP Addressing with References (IPREF) February 2023 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, . Author's Address Waldemar Augustyn (editor) Email: waldemar@wdmsys.com Augustyn Expires 16 August 2023 [Page 15]