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/ |