draft-augustyn-intarea-ipref-02.txt   draft-augustyn-intarea-ipref-03.txt 
Internet Engineering Task Force W. Augustyn, Ed. Internet Engineering Task Force W. Augustyn, Ed.
Internet-Draft 25 September 2023 Internet-Draft 23 March 2024
Intended status: Standards Track Intended status: Standards Track
Expires: 28 March 2024 Expires: 24 September 2024
IP Addressing with References (IPREF) IP Addressing with References (IPREF)
draft-augustyn-intarea-ipref-02 draft-augustyn-intarea-ipref-03
Abstract Abstract
IP addressing with references, or IPREF for short, is a method for IP addressing with references, or IPREF for short, is a method for
end-to-end communication across different address spaces normally not end-to-end communication across different address spaces normally not
reachable through native means. IPREF uses references to addresses reachable through native means. IPREF uses references to addresses
instead of real addresses. It allows to reach across NAT/NAT6 and instead of real addresses. It allows to reach across NAT/NAT6 and
across protocols IPv4/IPv6. It is a pure layer 3 addressing feature across protocols IPv4/IPv6. It is a pure layer 3 addressing feature
that works with existing network protocols. that works with existing network protocols.
IPREF forms addresses made of context addresses and references. IPREF forms addresses (IPREF addresses) made of context addresses and
These addresses are publishable in Domain Name System (DNS). Any references. These IPREF addresses are publishable in Domain Name
host in any address space, including behind NAT/NAT6 or employing System (DNS). Any host in any address space, including behind NAT/
different protocol IPv4/IPv6, may publish its services in DNS. These NAT6 or employing different protocol IPv4/IPv6, may publish IPREF
services will be reachable from any address space, including those addresses of its services in DNS. These services will be reachable
running different protocol IPv4/IPv6 or behind NAT/NAT6, provided from any address space, including those running different protocol
both ends support IPREF. IPv4/IPv6 or behind NAT/NAT6, provided both ends support IPREF.
IPREF is especially useful for transitioning to IPv6. IPREF is especially useful for transitioning to IPv6 or for operating
networks with a mix of IPv4/IPv6.
Status of This Memo Status of This Memo
This Internet-Draft is submitted in full conformance with the This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79. provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at https://datatracker.ietf.org/drafts/current/. Drafts is at https://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on 28 March 2024. This Internet-Draft will expire on 24 September 2024.
Copyright Notice Copyright Notice
Copyright (c) 2023 IETF Trust and the persons identified as the Copyright (c) 2024 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents (https://trustee.ietf.org/ Provisions Relating to IETF Documents (https://trustee.ietf.org/
license-info) in effect on the date of publication of this document. license-info) in effect on the date of publication of this document.
Please review these documents carefully, as they describe your rights Please review these documents carefully, as they describe your rights
and restrictions with respect to this document. Code Components and restrictions with respect to this document. Code Components
extracted from this document must include Revised BSD License text as extracted from this document must include Revised BSD License text as
described in Section 4.e of the Trust Legal Provisions and are described in Section 4.e of the Trust Legal Provisions and are
provided without warranty as described in the Revised BSD License. provided without warranty as described in the Revised BSD License.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1. Requirements Language . . . . . . . . . . . . . . . . . . 4 1.1. Requirements Language . . . . . . . . . . . . . . . . . . 5
1.2. IPREF Terminology . . . . . . . . . . . . . . . . . . . . 5 1.2. IPREF Terminology . . . . . . . . . . . . . . . . . . . . 5
2. IPREF Overview . . . . . . . . . . . . . . . . . . . . . . . 5 2. IPREF Overview . . . . . . . . . . . . . . . . . . . . . . . 5
2.1. References . . . . . . . . . . . . . . . . . . . . . . . 5 2.1. References . . . . . . . . . . . . . . . . . . . . . . . 6
2.2. IPREF Addresses . . . . . . . . . . . . . . . . . . . . . 6 2.2. IPREF Addresses . . . . . . . . . . . . . . . . . . . . . 6
2.3. Gateways and Encoding Networks . . . . . . . . . . . . . 7 2.3. Gateways and Encoding Networks . . . . . . . . . . . . . 7
2.4. Traversing Address Spaces . . . . . . . . . . . . . . . . 7 2.4. Traversing Address Spaces . . . . . . . . . . . . . . . . 7
2.5. Traversing Address Spaces in Detail . . . . . . . . . . . 9 2.5. Traversing Address Spaces in Detail . . . . . . . . . . . 9
2.6. Embedding References in IP Packets . . . . . . . . . . . 12 2.6. Embedding References in IP Packets . . . . . . . . . . . 12
2.6.1. IPv4 Option . . . . . . . . . . . . . . . . . . . . . 12 2.6.1. IPv4 Option . . . . . . . . . . . . . . . . . . . . . 12
2.6.2. IPv6 Extension Header . . . . . . . . . . . . . . . . 12 2.6.2. IPv6 Extension Header . . . . . . . . . . . . . . . . 12
2.6.3. UDP Tunnel . . . . . . . . . . . . . . . . . . . . . 13 2.6.3. UDP Tunnel . . . . . . . . . . . . . . . . . . . . . 13
2.7. Name Resolution Support . . . . . . . . . . . . . . . . . 13 2.7. Name Resolution Support . . . . . . . . . . . . . . . . . 13
3. DNS with IPREF . . . . . . . . . . . . . . . . . . . . . . . 13 3. DNS with IPREF . . . . . . . . . . . . . . . . . . . . . . . 13
3.1. DNS Records . . . . . . . . . . . . . . . . . . . . . . . 14 3.1. DNS Records . . . . . . . . . . . . . . . . . . . . . . . 14
3.2. Local Network Resolvers . . . . . . . . . . . . . . . . . 15 3.2. Local Network Resolvers . . . . . . . . . . . . . . . . . 15
3.3. Detecting Published IPREF Addresses . . . . . . . . . . . 15 3.3. Detecting Published IPREF Addresses . . . . . . . . . . . 15
3.4. DNSSEC compatibility . . . . . . . . . . . . . . . . . . 15 3.4. DNSSEC compatibility . . . . . . . . . . . . . . . . . . 15
3.5. IPREF Address Literals . . . . . . . . . . . . . . . . . 15 3.5. IPREF Address Literals . . . . . . . . . . . . . . . . . 15
4. Using IPREF for Transitioning to IPv6 . . . . . . . . . . . . 15 4. Using IPREF for Transitioning to IPv6 . . . . . . . . . . . . 15
4.1. Transitioning Process . . . . . . . . . . . . . . . . . . 17 4.1. Transitioning Process . . . . . . . . . . . . . . . . . . 17
5. Related Technologies . . . . . . . . . . . . . . . . . . . . 20 5. General Purpose Technology . . . . . . . . . . . . . . . . . 20
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 21 6. Related Technologies . . . . . . . . . . . . . . . . . . . . 21
7. Security Considerations . . . . . . . . . . . . . . . . . . . 21 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 22
8. References . . . . . . . . . . . . . . . . . . . . . . . . . 21 8. Security Considerations . . . . . . . . . . . . . . . . . . . 22
8.1. Normative References . . . . . . . . . . . . . . . . . . 21 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 22
8.2. Informative References . . . . . . . . . . . . . . . . . 22 9.1. Normative References . . . . . . . . . . . . . . . . . . 22
9.2. Informative References . . . . . . . . . . . . . . . . . 22
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 22 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 22
1. Introduction 1. Introduction
Some 25 years ago, it became clear that the 32 bit address space of Some 25 years ago, it became clear that the 32 bit address space of
the IP protocol was too small for the growing Internet. An effort to the IP protocol was too small for the growing Internet. An effort to
avert the impending 'shortage of IP addressees', as the problem was avert the impending 'shortage of IP addressees', as the problem was
referred to at the time, led to development of a new IP protocol referred to at the time, led to development of a new IP protocol
named version 6. That protocol, referred to as IPv6, had a larger named version 6. That protocol, referred to as IPv6, had a larger
address space thus instantaneously solving the problem. address space thus instantaneously solving the problem.
skipping to change at page 3, line 30 skipping to change at page 3, line 30
compatible with existing IPv4 protocol. IPv4 address space was compatible with existing IPv4 protocol. IPv4 address space was
extended by rewriting network addresses. That technique, since extended by rewriting network addresses. That technique, since
widely known as NAT, effectively created an address space hierarchy. widely known as NAT, effectively created an address space hierarchy.
At the top of the hierarchy, there was the original 32 bit address At the top of the hierarchy, there was the original 32 bit address
space. These addresses, at the edge of hierarchy, were translated space. These addresses, at the edge of hierarchy, were translated
into and from another set of addresses belonging to so called into and from another set of addresses belonging to so called
'private ranges'. These addresses formed new address spaces. They 'private ranges'. These addresses formed new address spaces. They
were 32 bit wide but only 24 bit subsets were used in practice. were 32 bit wide but only 24 bit subsets were used in practice.
Together with the top hierarchy, they produced a 56 bit address space Together with the top hierarchy, they produced a 56 bit address space
for IPv4. Another variant, known as 'carrier grade NAT', added for IPv4. Another variant, known as 'carrier grade NAT', added
another level of hierarchy which extend total address space to 72 another level of hierarchy which extended total address space to 72
bits. This approach averted the shortage of IP addresses, but it bits. This approach averted the shortage of IP addresses, but it
achieved it at a cost of creating another problem. Namely, it achieved it at a cost of creating another problem. Namely, it
created millions of address spaces inaccessible to one another. created millions of address spaces inaccessible from one another.
These new address spaces were not equal value, they were mostly These new address spaces were not equal value, they were mostly
useful for clients accessing servers within their own address spaces useful for clients accessing servers within their own address spaces
or within the space at the top of the hierarchy, commonly referred to or within the space at the top of the hierarchy, commonly referred to
as 'global IP addresses'. as 'global IP addresses'.
As a result, the Internet evolved into a collection of a large number As a result, the Internet evolved into a collection of a large number
of generally inaccessible address spaces with two incompatible of generally inaccessible address spaces with two incompatible
network protocols. network protocols.
There were attempts at improving the situation which went in two There were attempts at improving the situation which went in two
skipping to change at page 4, line 20 skipping to change at page 4, line 20
different address spaces still generally inaccessible to one another. different address spaces still generally inaccessible to one another.
A closer analysis of these different solutions reveals they suffer A closer analysis of these different solutions reveals they suffer
great difficulties primarily because they try to render necessary great difficulties primarily because they try to render necessary
address transformations too early. IPREF takes a different approach. address transformations too early. IPREF takes a different approach.
It is based on the observation that the originating hosts do not have It is based on the observation that the originating hosts do not have
to know what the destination addresses are, or what protocol they to know what the destination addresses are, or what protocol they
belong to. Thus, IPREF uses references to addresses rather than real belong to. Thus, IPREF uses references to addresses rather than real
addresses. This approach works for both NAT traversal as well as for addresses. This approach works for both NAT traversal as well as for
protocol traversal since both problems are substantially the same. protocol traversal since both problems are substantially the same.
The one difference being having to repackage packets on the IPv4/IPv6 The one difference between them being having to repackage packets on
boundary. Such repackaging requires sufficient compatibility between the IPv4/IPv6 boundary. Such repackaging requires sufficient
the protocols which fortunately exists. compatibility between the protocols which fortunately exists.
With this approach, IPREF does not need to negotiate anything. It With this approach, IPREF does not need to negotiate anything. It
does not need any external devices, any shared configurations. It does not need any external devices, any shared configurations. It
does not require allocating of any global IP addresses. The result does not require allocating of any global IP addresses. It does not
is a highly scalable solution that works over NAT, NAT6, filters, and create any new address spaces, it always refers to existing ones.
across IPv4/IPv6. All of the millions of different address spaces, The result is a highly scalable solution that works over NAT, NAT6,
whether behind NAT/NAT6, or across IPv4/IPv6 may now communicate with filters, and across IPv4/IPv6. All of the millions of different
one another using IPREF. address spaces, whether behind NAT/NAT6, or across IPv4/IPv6 may now
communicate with one another using IPREF.
In the background to all the above, there is an ongoing effort to In the background to all the above, there is an ongoing effort to
covert every IPv4 network out there to IPv6. The idea is to run only convert every IPv4 network out there to IPv6. The idea is to run
one protocol everywhere which would simplify many issues including only one protocol everywhere which would simplify many issues
address space accessibility. This is a long term effort, decades including address space accessibility. This is a long term effort,
away. IPREF does not conflict with it. Rather, it provides an decades away. IPREF does not conflict with it. Rather, it provides
excellent tool in achieving the objective. It does this in a least an excellent tool in achieving the objective. It does this in a
expensive, least risky manner which also shortens the conversion time least expensive, least risky manner which also shortens the
substantially. Compared to traditional strategies, which use dual conversion time substantially. Compared to traditional strategies,
stacks and translator devices all requiring allocation of IPv4 which use dual stacks and translator devices all requiring allocation
addresses, IPREF allows very clean strategies without IPv4 pollution. of IPv4 addresses, IPREF allows very clean strategies without IPv4
It relies only on pure IPv6 Internet, allows to drop IPv4 Internet pollution. It relies only on pure IPv6 Internet, allows to drop IPv4
early, and transitions to pure IPv6 networks in a single step. Internet early, and transitions to pure IPv6 networks in a single
step.
1.1. Requirements Language 1.1. Requirements Language
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
"OPTIONAL" in this document are to be interpreted as described in BCP "OPTIONAL" in this document are to be interpreted as described in BCP
14 [RFC2119] [RFC8174] when, and only when, they appear in all 14 [RFC2119] [RFC8174] when, and only when, they appear in all
capitals, as shown here. capitals, as shown here.
1.2. IPREF Terminology 1.2. IPREF Terminology
skipping to change at page 7, line 34 skipping to change at page 7, line 38
network while IPv6 networks could use an fd::/64 network for the network while IPv6 networks could use an fd::/64 network for the
purpose. For local hosts, these encoded addresses represent peers purpose. For local hosts, these encoded addresses represent peers
they communicate with. The peers appear as if on the local network. they communicate with. The peers appear as if on the local network.
This is common with cross protocol communication or more generally This is common with cross protocol communication or more generally
with cross address space communication. The gateways replace these with cross address space communication. The gateways replace these
encoded addresses with IPREF addresses when sending packets outside encoded addresses with IPREF addresses when sending packets outside
local networks. local networks.
2.4. Traversing Address Spaces 2.4. Traversing Address Spaces
Conceptually, packets travel through address spaces based on source Similarly to standard IP protocols, IPREF packets travel through
and destination IPREF addresses. This is analogous to IP protocols. address spaces based on source and destination IPREF addresses.
The IPREF addresses are interpreted at each address space to render After all, they utilize existing protocols for transport thus they
native addresses for forwarding. must obey the same rules. The IPREF addresses are interpreted at
each address space to render native addresses for forwarding.
Network A │ Internet │ Network B Network A │ Internet │ Network B
src: 2001:db8::9 + 1579 2001:db8::9 + 1579 2001:db8::9 + 1579 src: 2001:db8::9 + 1579 2001:db8::9 + 1579 2001:db8::9 + 1579
dst: 2001:db8::8 + 2466 2001:db8::8 + 2466 2001:db8::8 + 2466 dst: 2001:db8::8 + 2466 2001:db8::8 + 2466 2001:db8::8 + 2466
🡳 🡳 🡳 🡳 🡳 🡳
src: 172.17.1.75 2001:db8::9 fdee:eeee::5951 src: 172.17.1.75 2001:db8::9 fdee:eeee::5951
dst: 10.128.48.62 2001:db8::8 2001:db8:b::28 dst: 10.128.48.62 2001:db8::8 2001:db8:b::28
skipping to change at page 13, line 8 skipping to change at page 13, line 8
octets of padding to 8 octet boundary. Padding octets would not be octets of padding to 8 octet boundary. Padding octets would not be
intended for any future use. The source and destination references intended for any future use. The source and destination references
would then follow. would then follow.
A new protocol type would be registered with IANA. Until then, A new protocol type would be registered with IANA. Until then,
experimental protocol, 254, could be used. experimental protocol, 254, could be used.
2.6.3. UDP Tunnel 2.6.3. UDP Tunnel
Placing references in a UDP tunnel works for both IPv4 and IPv6. In Placing references in a UDP tunnel works for both IPv4 and IPv6. In
both cases, the references are embedded in the form of respective both cases, the references would be embedded in the form of
options or extension headers. In addition, a tunnel encapsulation respective options or extension headers. In addition, a tunnel
record is added. The order of items is as follows: encapsulation record would be added. The order of items would be as
follows:
UDP header UDP header
Tunnel encapsulation record Tunnel encapsulation record
IPREF option IPREF option
Packet payload Packet payload
The encapsulation record would consist of four octets. First octet The encapsulation record would consist of four octets. First octet
would contain the value of TTL copied from the original IP header. would contain the value of TTL copied from the original IP header.
The second octet would contain protocol number copied from the The second octet would contain protocol number copied from the
original IPv4 header or next header value form an IPv6 extension original IPv4 header or next header value form an IPv6 extension
skipping to change at page 13, line 44 skipping to change at page 13, line 45
local network protocol. Typically, a subnet on a private network is local network protocol. Typically, a subnet on a private network is
dedicated for the purpose. That subnet is used just for encoding, dedicated for the purpose. That subnet is used just for encoding,
there are no real hosts with these addresses. There may be a need to there are no real hosts with these addresses. There may be a need to
standardize on how resolvers communicate with gateways to obtain such standardize on how resolvers communicate with gateways to obtain such
mappings. mappings.
3. DNS with IPREF 3. DNS with IPREF
IPREF takes full advantage of DNS [RFC1035]. Local networks may IPREF takes full advantage of DNS [RFC1035]. Local networks may
publish IPREF addresses of any services hosted on local networks. publish IPREF addresses of any services hosted on local networks.
Standard DNS servers may be used for the purpose. Standard unmodified DNS servers may be used for the purpose.
Network A │ Network A │
╔═══════╗ ╔═══════╗
┌──────┐ │ ║ publc ║ ┌──────┐ │ ║ publc ║
│ host │.75┃ ┌────────────╢ DNS ║ A3 AA 2001:db8::9 + 1733 │ host │.75┃ ┌────────────╢ DNS ║ A3 AA 2001:db8::9 + 1733
│ A1 ├───┨ ┏━━━┷━━━┓ │ ║ servr ║ ────────> │ A1 ├───┨ ┏━━━┷━━━┓ │ ║ servr ║ ────────>
└──────┘ ┃ ┃ IPREF ┃:9 ╚═══════╝ └──────┘ ┃ ┃ IPREF ┃:9 ╚═══════╝
┠──┨ g-way ┠───── ┠──┨ g-way ┠─────
┌──────┐ ┃ ┃ GWA ┃ ┌──────┐ ┃ ┃ GWA ┃
│ host ├───┨ ┗━━━┯━━━┛ │ Internet │ host ├───┨ ┗━━━┯━━━┛ │ Internet
skipping to change at page 14, line 26 skipping to change at page 14, line 26
│ ║ ╔═══════╗ │ ║ ╔═══════╗
▲ ╔═══╧═══╗ │ ║ ║ other ║ ▲ ╔═══╧═══╗ │ ║ ║ other ║
│ ║ local ║ <─────── ╚═║ ╔═══════╗ │ ║ local ║ <─────── ╚═║ ╔═══════╗
╰──── ║ DNS ║ B6 AA 2001:db8::8 + 2466 ║ ║ other ║ ╰──── ║ DNS ║ B6 AA 2001:db8::8 + 2466 ║ ║ other ║
║ rslvr ║ ╚═║ DNS ║ ║ rslvr ║ ╚═║ DNS ║
╚═══════╝ │ ║ servr ║ ╚═══════╝ │ ║ servr ║
╚═══════╝ ╚═══════╝
Figure 4: DNS with IPREF Figure 4: DNS with IPREF
For resolution of DNS names, a modified recursive resolver is For the resolution of DNS names, a modified recursive resolver is
required because IPREF addresses are different from IPv4 and IPv6 required because IPREF addresses are different from IPv4 and IPv6
addresses. The resolver must recognize them in addition to native IP addresses. The resolver must recognize them in addition to native IP
addresses. addresses.
3.1. DNS Records 3.1. DNS Records
IPREF addresses are unlike well known IPv4 addresses or IPv6 IPREF addresses are unlike well known IPv4 addresses or IPv6
addresses. These addresses consist of two components which must be addresses. These addresses consist of two components which must be
considered as a single address entity. It is not possible to considered as a single address entity. It is not possible to
separate references from their companion context addresses. For that separate references from their companion context addresses. For that
skipping to change at page 16, line 40 skipping to change at page 16, line 40
Relying on only pure IPv6 Internet and transitioning to pure IPv6 Relying on only pure IPv6 Internet and transitioning to pure IPv6
greatly simplifies network designs and operations. Transition based greatly simplifies network designs and operations. Transition based
on IPREF produces cleaner, simpler networks and a cleaner, simpler on IPREF produces cleaner, simpler networks and a cleaner, simpler
Internet. Internet.
The ability to transition at own pace, service by service, subnet by The ability to transition at own pace, service by service, subnet by
subnet results in huge reduction in costs and risks. subnet results in huge reduction in costs and risks.
Traditional transition strategies have a structural deficiency. They Traditional transition strategies have a structural deficiency. They
perpetuate IPv4 addressing. Thus they extend the life of IPv4 perpetuate IPv4 addressing. Thus they extend the life of IPv4
Internet endlessly, to the point it may not be possible to take it Internet endlessly to the point it may not be possible to take it
down. This is caused by the use of dual stacks and a collection of down. This is caused by the use of dual stacks and a collection of
translation devices such as NAT64/SIIT/464XLAT which all require translation devices such as NAT64/SIIT/464XLAT which all require
allocation of IPv4 addresses. They are set up first, before allocation of IPv4 addresses. They are set up first, before
transition takes place, and cannot be taken down until AFTER all transition takes place, and cannot be taken down until AFTER all
networks out there transition to IPv6. This may take decades to networks out there transition to IPv6. This may take decades to
happen if ever. happen if ever.
IPREF does not have such deficiencies. It does not use dual stacks IPREF does not have such deficiencies. It does not use dual stacks
and it does not use any translator devices that rely on IPv4 and it does not use any translator devices that rely on IPv4
addresses. IPREF gateways are set up first which makes it possible addresses. IPREF gateways are set up first which makes it possible
skipping to change at page 20, line 37 skipping to change at page 20, line 37
┗━━━━━━━┛ │ │ ┗━━━━━━━┛ ┗━━━━━━━┛ │ │ ┗━━━━━━━┛
│ │ │ │
Transition is completed when each side switches its internal Transition is completed when each side switches its internal
network to IPv6. All internal networks are pure IPv6. The network to IPv6. All internal networks are pure IPv6. The
Internet is also pure IPv6. IPREF gateways may be removed, or Internet is also pure IPv6. IPREF gateways may be removed, or
they may remain in place to allow communication with third party they may remain in place to allow communication with third party
sites that have not transitioned. sites that have not transitioned.
5. Related Technologies 5. General Purpose Technology
IPREF is a general purpose technology. While it can be used for
transition purpose, it is not a transition technology. It was
created to bridge a divide between incompatible protocols and between
unreachable address spaces. This is a networking world that we are
facing now. We have two public Internets and millions of address
spaces. It will stay like this in the foreseeable future, likely for
decades to come. IPREF addresses this situation. New protocols are
being developed as well, for example such as those presented in
various IRTF groups. Some are specialized, some are intended for
wider use. Each of them create their own address spaces with a need
to exist within wider networking system. IPREF can bridge these new
technologies with existing IPv4 and IPv6 Internets and allow them to
strive. These are important projects which address new issues not
encountered before. IPREF dovetails with these efforts, thus
enabling and enhancing innovation in networking.
6. Related Technologies
IPREF works well with related technologies. It does not create IPREF works well with related technologies. It does not create
conflicts and it does not attempt to step on their functionality. conflicts and it does not attempt to step on their functionality.
* IPv4 - IPREF does not replace IPv4, it is an optional add-on to * IPv4 - IPREF does not replace IPv4, it is an optional add-on to
enhance IPv4 capabilities in the area of address rewriting. It enhance IPv4 capabilities in the area of address rewriting. It
relies on IPv4 in all other functions of a network protocol. relies on IPv4 in all other functions of a network protocol.
* IPv6 - IPREF does not replace IPv6, it is an optional add-on to * IPv6 - IPREF does not replace IPv6, it is an optional add-on to
enhance IPv6 capabilities in the area of address rewriting. It enhance IPv6 capabilities in the area of address rewriting. It
skipping to change at page 21, line 36 skipping to change at page 22, line 5
VPNs. A VPN might use IPREF to establish a VPN connection. VPNs. A VPN might use IPREF to establish a VPN connection.
* Firewall - IPREF is not a firewall. While allocation or lack of * Firewall - IPREF is not a firewall. While allocation or lack of
allocation of references has the effect of blocking or allowing allocation of references has the effect of blocking or allowing
access, blocking policy is best vested with firewalls. IPREF access, blocking policy is best vested with firewalls. IPREF
mappers deal with address rewriting, they are not packet filters. mappers deal with address rewriting, they are not packet filters.
There is no conflict between firewalls and IPREF. Firewalls might There is no conflict between firewalls and IPREF. Firewalls might
benefit from IPREF specific features to simplify management and benefit from IPREF specific features to simplify management and
configuration. configuration.
6. IANA Considerations 7. IANA Considerations
This memo includes no requests to IANA. This memo includes no requests to IANA.
7. Security Considerations 8. Security Considerations
This document should not affect the security of the Internet. This document should not affect the security of the Internet.
Documents describing particular pieces of IPREF might. Proper Documents describing particular pieces of IPREF might. Proper
security consideration statements would be included in those security consideration statements would be included in those
documents. documents.
8. References 9. References
8.1. Normative References 9.1. Normative References
[RFC791] Postel, J., "Internet Protocol", RFC 791, September 1981, [RFC791] Postel, J., "Internet Protocol", RFC 791, September 1981,
<https://www.rfc-editor.org/info/rfc791>. <https://www.rfc-editor.org/info/rfc791>.
[RFC1035] Mockapetris, P., "Domain names - implementation and [RFC1035] Mockapetris, P., "Domain names - implementation and
specification", STD 13, RFC 1035, DOI 10.17487/RFC1035, specification", STD 13, RFC 1035, DOI 10.17487/RFC1035,
November 1987, <https://www.rfc-editor.org/info/rfc1035>. November 1987, <https://www.rfc-editor.org/info/rfc1035>.
[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
May 2017, <https://www.rfc-editor.org/info/rfc8174>. May 2017, <https://www.rfc-editor.org/info/rfc8174>.
[RFC8200] Deering, S. and R. Hinden, "Internet Protocol, Version 6 [RFC8200] Deering, S. and R. Hinden, "Internet Protocol, Version 6
(IPv6) Specification", STD 86, RFC 8200, (IPv6) Specification", STD 86, RFC 8200,
DOI 10.17487/RFC8200, July 2017, DOI 10.17487/RFC8200, July 2017,
<https://www.rfc-editor.org/info/rfc8200>. <https://www.rfc-editor.org/info/rfc8200>.
8.2. Informative References 9.2. Informative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997, DOI 10.17487/RFC2119, March 1997,
<https://www.rfc-editor.org/info/rfc2119>. <https://www.rfc-editor.org/info/rfc2119>.
Author's Address Author's Address
Waldemar Augustyn (editor) Waldemar Augustyn (editor)
Email: waldemar@wdmsys.com Email: waldemar@wdmsys.com
 End of changes. 26 change blocks. 
58 lines changed or deleted 82 lines changed or added

This html diff was produced by rfcdiff 1.45. The latest version is available from http://tools.ietf.org/tools/rfcdiff/