This relates to: draft-augustyn-intarea-ipref
The draft describes how IPREF works. This email describes how IPREF may
be used.
1. Background, original motivation.
The original motivation was to develop a reliable method of providing
peer-to-peer communication for private hosts with the ability to publish
their addresses in the DNS. One major problem to overcome was traversing
NAT in a scalable manner. Another major problem was to find a way for
publishing host addresses located on local networks. Once an innovative way
to accomplish these objectives was found, it became clear that traversing
protocol domain. specifically IPv4/IPv6, posed substantially the same
problems,
hence the same solution was applied. In this way, IPREF was created with the
ability to traverse not only NAT in the native protocol domains but also
across
protocol domains. Similarly, the ability to publish end point addresses was
extended to hosts within any protocol domain and which could be understood
across different protocol domains.
2. IPREF capabilities.
2.1 Traversing private address domains.
IPREF can traverse private, local address domains, such as those typically
created behind NAT gateways. In case of IPv6, they may exist behind NAT6 but
also behind filters. IPREF can reach those hosts. Local admins decide which
local hosts may or may not be reachable via IPREF.
2.2 Traversing protocol domains.
IPREF can traverse protocol domains, such as IPv4 or IPv6 but also any
custom
protocols that are compatible with IPREF. This ability involves address
translation and payload repackaging. Each end point may reside in a
different
protocol domain. For example one end point may be located in an IPv4 local
network behind NAT while the other may be located in an IPv6 local network
behind a filter.
2.3 Opaque addresses.
IPREF operates using special addresses, called "IPREF addresses". These
addresses consist of native protocol addresses and references. The
references
are opaque entities, unsigned integers, which effectively make the end point
addresses opaque. This means, the communicating peers do not know each
others
real addresses nor network protocols. It may be surprising at first, but
communicating hosts don't have to know their peers' addresses. It
suffices that
they can refer to them in a manner understood by both ends. That's the
role of
the references. Each end point interprets them differently, according to the
rules of the local network protocols, eventually resolving them to local
native
addresses. This is the essence of IPREF addressing.
2.4 No negotiations.
In the situation where address spaces may overlap, it would seem some
form of
negotiations is necessary. This turns out not to be true. IPREF does not
negotiate, instead it uses late binding. It takes advantage of the
references
which allow resolution of the addresses at the last moment, in the
context of
target networks, where there are no conflicts hence there is nothing to
negotiate. Each peer interprets references independently and each produces
different results for the same references.
Late binding also proves useful for crossing protocol domains. Communicating
peers do not need to know what network protocols run in the respective local
networks. Gateways perform proper payload repackaging and address
translations
at the last moment in the context of local networks.
In this way, IPREF can traverse not only NAT, NAT6, or networks behind
filters
but also networks employing different protocols. The protocols need to be
reasonably compatible for the gateways to repackage payloads properly
and for
the upper layers to function. Fortunately, sufficient compatibility exists
between IPv4 and IPv6.
2.5 High scalability
IPREF is highly scalable chiefly because it does not negotiate. It does not
need external gateways, it does not need external brokers, it does not need
global registries, or anything of that kind.
IPREF is suitable for large scale deployments.
2.6 No time base dependency
One important effect of no negotiations is that IPREF does not rely on
common
time domain. This makes it suitable for applications with fuzzy or disparate
time characteristics such as satellite networks, space networks, or networks
with long delays.
Of course, other components may be vulnerable such as TCP or
cryptography but
at least the base network protocols with IPREF are not affected.
2.7 Addresses publishable in DNS.
IPREF addresses are publishable in DNS. These addresses are normally
understood
only by IPREF gateways. To make them usable by standard hosts, local
resolvers
encode them into addresses from the local protocol space. The gateways
must be
informed of the mapping. In practice, the gateways provide the mapping
to the
resolvers. The gateways are able to map encoded addresses to their original
IPREF form when forwarding packets originating from local networks.
Similarly,
the gateways replace IPREF addresses with encoded addresses when injecting
packets back to the local networks.
Local hosts never see references or IPREF addresses. Local hosts only see
addresses from their protocol domain, including encoded addresses. For
example,
an IPv4 host would see an address like 10.192.5.5 which would be an encoded
address of some IPREF address such as 2001:db8::abc:4 + 2848. The gateways
swap the addresses as they encounter them.
The result of this mappings is that local hosts can obtain addresses
(in the
encoded form) of their peers by querying DNS. This works across protocol
domains. Local hosts may obtain addresses of peers located in different
protocol domains. For example, an IPv4 host may obtain an address of an IPv6
host (in an encoded form) and successfully establish communication with it.
In addition to publishing IPREF addresses in DNS, IPREF supports literal
addresses. IPREF address literals can be passed in the email, texted
over the
phone, posted in a chat, or placed in a spreadsheet. These are different
forms
of publishing.
2.8 No need for mapping to public addresses.
One important characteristics of publishing IPREF addresses in DNS is that
there is no need to map to public IP addresses. For example a private
network
behind NAT may want to publish addresses of 20 hosts. It can do that without
allocating 20 public IP addresses for these hosts. IPREF addresses are all
that's needed. These hosts will be reachable from any peer network. Note
that
IPREF operates purely in the network layer. There is no port mapping. All of
these 20 hosts may use any ports they desire. For example, they can all use
port 443 without causing any conflicts.
This is a very useful feature on IPv4 networks. But it is useful even with
IPv6 networks. For example, in a case of multiplayer games, the players
might
prefer to list their IPREF address for short term purpose, like a day of
playing
or even for different sessions on the same day. IPREF addresses are
opaque, the
players might prefer them over disclosing real IPv6 addresses.
2.9 Full local network administration
The administration of all aspects of IPREF communication is fully vested
with
local network admins. There is no need for any kind of coordination between
peer admins and there is no need for any sort of global authority. This
is the
result of no negotiations and late binding. All configuration,
authorization,
and operation decision are made locally.
Of course, in the local context, there may be more than one admin in
which case
some method of conflict avoidance could be employed. For example, each admin
may be allocated a different pool of references.
2.10 Path for developing custom network protocols
For practical purpose, the draft discusses IPv4 and IPv6 but IPREF works
with
any reasonably IP-like protocol. This paves a way for innovation in the
network protocol space for special applications. Some that come to mind are
space networks, high security networks, low power IoT networks, unreliable
networks and the likes. For any such custom protocol, IPREF would give
instantaneous compatibility with well established networks such as IPv4/IPv6
private networks, or IPv6 Internet.
3. Effect on adoption of IPv6 Internet
IPREF will speed up adoption of IPv6 Internet. The factors that play a role
are: high scalability, cross protocol traversal, DNS publishing.
IPREF greatly reduces risks associated with the transition and allows to
make
it gradual, whenever convenient.
For example, most corporate networks consists of a collection of private
networks. It is substantially easier to convert only one, or a few of them,
while leaving the rest in the IPv4 domain. The services on the converted
networks would first be offered through IPREF. This could be done by
publishing
them in local DNS or by using IPREF literals. With key services
reachable via
IPREF, the network can be converted to IPv6 while maintaining
availability of
those services from IPv4 networks. The process can then continue in a less
disruptive manner.
Similarly, well known public services will be able to contribute to easier
transition by offering their services via IPREF. This would decouple
switching
to IPv6 Internet from switching protocols in the internal networks.
Special case networks, perhaps employing modified, or brand new protocols,
would have very little issue with IPv6 as they would rely on IPREF anyway.
4. Not a replacement
IPREF does not replace IPv4 or IPv6. Standard networking should be used
whenever possible, except in cases such as these:
- peer networks with hosts behind NAT/NAT6/filters
- peer networks crossing protocol domains IPv4/IPv6
- transition strategies
- reaching custom networks
- making private hosts DNS visible across protocol domains
- making private hosts DNS visible without consuming public IP
addresses
_______________________________________________
Int-area mailing list
Int-area@ietf.org
https://www.ietf.org/mailman/listinfo/int-area
