Mark Andrews wrote:
[...]
> And if you stop thinking IPv6 == IPv4 + big addresses and
> start thinking multiple IPv6 addresses including a ULA IPv6
> address + RFC 3484 you get local address stability without
> needing a NAT. You use ULAs for internal communication and
> global addresses for external communication.
>
> This isn't future stuff, you can do this today. You can
> renumber your external addresses daily and keep internal
> sessions up for weeks.
Yes, I think using ULAs is a much better approach. Using ULAs also
has some drawbacks though. Attached is some text I wrote a long time
ago on using ULAs for intra-site stability when changing providers.
You may want to jump directly to section 3 rather than reading it all.
There are issues like split DNS and address selection.
Stig
Using ULAs for intra-site stability
1. Introduction
When deploying IPv6 most organisations/sites have to use
provider assigned (PA) addresses. This allows for good
aggregation in the global routing tables since the number
of routes in the global routing table can be on the order
of the number of providers rather than the number of
organisations or sites. The downside of this, is that
an organisations/site need to renumber (change the IPv6
addresses of their hosts) when changing providers. Renumbering
has a significant cost, which again means that buying
connectivity from a provider is a long term investment, and
that changing to a slightly cheaper provider may indeed cost
more than staying.
>From an end-user perspective the optimal solution would be
to own a set of addresses that are provider independent (PI),
where one could keep using the same addresses independent of
the provider. However, due to the impact this would have on
routing, there are limitations on who can get such addresses.
For IPv4 it is pretty common to make use of NAT. While NAT
has several problems, one major benefit is that one can change
providers (and possibly be multi-homed) and only alter the
external addressing. The internal addressing can be completely
independent of the external and need not be altered.
For IPv6 there are enough addresses for all hosts to get
globally unique routable addresses, which means that no NAT
is required and one can get full end-to-end connectivity.
We will here look at how one can without the use of NAT,
have relatively stable addressing for internal communications,
and how that reduces the cost of changing providers.
One obvious way to try to solve this problem, is the use of
Unique Local Addresses (ULA) for internal communications,
and that is the focus of this document. There is some
on-going work, in e.g. the IRTF, on new routing and
addressing solutions, including various so-called locator
identifier split solutions. These solutions may allow hosts and
sites to have stable addresses that are used as identifiers.
It remains to be seen whether such solutions eventually get
deployed. It is clear that such solutions are many years
ahead.
2. Unique Local Addresses (ULA)
Unique Local IPv6 Unicast Addresses are specified in RFC
4193 from 2005. These are intended to be globally unique,
used for local communications, and not to be routable on
the global Internet.
2.1. ULA Format
The format of the ULA addresses is defined as follows:
| 7 bits |1| 40 bits | 16 bits | 64 bits |
+--------+-+------------+-----------+----------------------------+
| Prefix |L| Global ID | Subnet ID | Interface ID |
+--------+-+------------+-----------+----------------------------+
where the prefix is FC00::/7, Global ID is a more or less
globally unique identifier, and L is set to 1 meaning the
identifier is locally assigned. We will discuss that below. The
Subnet ID is used for addressing subnets. This ID is 16 bits, so
a site may use a some Global ID, and for that value, have up to
65536 subnets.
2.2 ULA Global ID
RFC 4193 specifies how Global ID can be locally assigned. In this
case the L-bit is set to 1. For local assignment one must use a
pseudo-random algorithm, one is suggested in the RFC. They key is
that by using such an algorithm, one is unlikely to have the ID
clash with another network with the same ID. There may be two sites
in the world with the same Global ID, but given that they should be
for local used and not on the global Internet, it is unlikely that
two sites with the same ID come in conflict with eachother. The
use of this pseudo-random ID means that if networks using these
addresses merge, or a host moves between two networks, etc., the
two networks are very unlikely to have the same Global ID. These
addresses can be regarded mostly like the IPv4 privat address
space in RFC 1918, but the pseudo-random ID means that one is
unlikely to have the clashes experienced between sites using the
same IPv4 private address space.
There is an on-going discussion whether one should also specify
centrally assigned Global IDs, where the L-bit would be 0. One
could then guarantee global uniqueness. This is an interesting
discussion, but not all that relevant to our discussion in this
document. It would reduce the risks of conflicts where two sites
are using the same Global ID, but we believe the risk is already
sufficiently small.
2.3 Routing of ULAs
The ULA addresses are not to be routable on the global Internet.
The main reasons for that is that they would generally not be
aggregated, resulting in a large number of /48 prefixes in global
routing; also this would cause problems if two sites connected
to the Internet happened to choose the same Global ID. However,
the ULAs can be routed between small groups of of cooperating
sites. An attempt to use it between large groups increases the
risk of conflicting IDs.
2.4 Scope and reachability
ULA addresses are by default to be treated as globally scoped
addresses. However, they are only locally reachable. This may
cause problems for some applications. There may be a need to
give ULAs preference over other types of global unicast
addresses. One way of doing that is by controlling what
addresses can be looked up in the DNS, see next section. There
are also address selection mechanisms that we will discuss
later.
2.5 ULAs and DNS
The use of ULAs may have a significant impact on the use of
DNS in a site. Generally speaking one would typically
register all the addresses of all the hosts in the DNS, where
anyone from anywhere could look up the host in the DNS and
find the exact same set of addresses. However, the use of
ULAs changes this (as with the use of private IPv4 addresses).
First of all, one should not put ULA addresses in the global
DNS. Since ULA addresses are not globally reachable, but is
of global scope, an application anywhere on the Internet
looking up the host's addresses, may try to contact the host
using the ULA address. If the address is not reachable, it
may take a long time before the application times out and
tries another address; some applications may indeed never try
another address. In the worst case, the same ULA Global ID
may be used in the site where the application resides, and
the application may contact the wrong host. Hence hosts
should only be registered with their globally reachable
unicast addresses in the global DNS. Hosts never are to be
reached from the global Internet, may not even need to be
in the global DNS.
Inside a site using ULAs, one would obviously like to be
able to look up ULA addresses of a host in the DNS; perhaps
all addresses of the host. We will discuss this later in the
document.
The wish to find ULAs when looking up some FQDN in the DNS
internally, but not externally, leads to the deployment of
so-called split DNS. The use of split DNS is likely to make
DNS harder to manage and increase management cost. It may
also be tricky to make a host always get the right information.
E.g. a mobile host visiting an external network should normally
get only the external view, while if it gets a VPN connection
to its home site, one may want it to look up ULA addresses and
reach those through the tunnel.
3. ULAs for intra-site stability
We will consider how one may use ULAs for intra-site stability.
The idea is that one can use ULAs for internal communications,
so that when one changes providers and the Provider Assigned
addresses changes, not only on-going internal communications,
but also configuration files and applications that deal with
internal communications, remains unaffected. We will
discuss how this might be done, to what degree it can provide
stability and simplify management while changing external
addressing, and also possible issues, including increased
complexity and management. We will see that there are benefits,
but there is also a cost.
The main problem with renumbering (change of addressing) are
perhaps various configuration files that have hardcoded
addresses, application clients and servers that need to be
restarted due to long time caching of addresses, and sessions
both at the transport layer (like TCP), and the application
layer that may be reset. By using stable addressing internally
one can hopefully keep things more stable, and also limit the
amount of configuration changes.
For end-to-end connectivity all hosts in the site that are
to communicate with the outside world, will need to have a
global address. These are the PA addresses that may need to
change. In our case, we also assume that all hosts in the
site has a ULA address from a given ULA /48 prefix that the
site is using (based on some ULA Global ID). Note that it
is not a strict requirement that all hosts in the site has
a ULA, some may and some may not, but we assume all to
simplify our discussion. Note that when using stateless
address autoconfiguration all hosts on a given link will
get addresses with the same prefixes. In general the
easiest is probably to give all hosts both global and
private addresses. This includes having internal routing
for both ULA and PA addresses, and announcing both on
all (most) links.
The site will probably need to add ULA addresses in the
DNS for FQDNs of internal hosts. As discussed in 2.5 the
site will then need to deploy split DNS since the ULAs
should not be visible externally. As discussed, this adds
some complexity. There are however several DNS server
implementations supporting this, and the amount of management
work may not increase, depending on the management systems
used.
3.1 Address selection
If we now consider that the internal hosts in the site both
have ULAs (internal addressing) and one or more PA addresses
(external addressing). How can one we ensure that internal
addresses are used for internal communications, while external
addresses for external communications? Basically we would like
to use internal addressing if both hosts have addresses from
the same /48 ULA prefix, otherwise external. One might want to
do this for ULA more generally if there are multiple
cooperating sites using ULA.
IPv6 implementations should do address selection according to
RFC 3484. The RFC defines a default behaviour, but allows for
this to be modified. Whether this behaviour can be modified
varies between the different implementations. RFC 3484
distinguishes between IPv4 and IPv6, 6to4 vs native, and also
takes scoping into account. However, it has no knowledge of
ULAs, and ULAs are treated as being of global scope. That is,
the mechanism doesn't treat ULAs any different from the PA
addresses.
If say a client tries to reach a server, it may look up the
server's FQDN in the DNS and obtain both a ULA and a PA
address. The client will need to choose which address to
try to connect to (in which order to try them). Assuming
both the addresses are valid, not deprecated etc, the rules
that come into play for choosing ULA vs PA will be "longest
matching prefix" and if that makes no difference, the order
the addresses were returned from the DNS. Longest prefix
match ensures that if the client has only a ULA address,
then it will prefer the server's ULA address. If the client
only has a PA address, then it's fairly certain that the
server's PA address will get a better match. But what does
happen if the client and the server, both got ULA and PA
addresses?
If we look at two hosts using stateless address autoconfig
that both reside on the same link, where there are two /64
prefixes on the link, one ULA and one PA, then the longest
prefix match rule will not make a distinction, between
using ULA for both destination and source, or PA for both
destination and source. Also, many sites are likely to use
say a /48 prefix for the PA addresses, matching the ULA
prefix length. For ease of maintenance, the site may then
use the exact same bits for the remaining bits of the
addresses. Then longest prefix match will not give a
preference for ULA vs PA for any pair of hosts in the
site.
This means that when deploying both ULA and PA, the
order returned by the DNS is likely to be the deciding
factor. Hence one may be able to prefer ULA over PA for
internal communications if the DNS sorts ULAs first.
Perhaps an easier method is to only have ULAs in the
internal DNS.
Note that some implementations allows the policy table
in RFC 3484 to be customised. This means that the host
administrator may be able to add a rule for preference
of the site's ULA prefix (and possibly for ULA prefixes
of cooperating sites that also are known to be reachable).
However, not all implementations do this, and it's also
implementation specific how exactly to change this
table. There is some on-going work for using e.g. DHCPv6
to configure the policy table and also for changing the
default table. At the moment it is basically left to the
administrator to figure out whether and how the default
table may be changed on the different platforms. Provided
that the table is updated to prefer ULAs, one can safely
also put PA addresses in the internal DNS.
Address selection can get complicated for some applications.
If for instance the site is streaming some video, the source
address need to be PA if the stream is to go outside the
site, while if internal one probably would prefer ULA. This
can not be determined automatically. Also, a user in the
site wants to receive the stream needs to know which
address to use (although this could be via SDP or a URL
etc). The user cannot necessarily just use the FQDN of the
streaming host. This could lead the client to expect data
from the wrong address; in particularly if a PA address is
used for the stream and only ULAs are in the internal DNS.
4. IPv4 addresses for intra-site stability
Sites deploying IPv6 will generally do it alongside IPv4,
so that both protocols can be used. This may change in
the long term. One common scenario will probably be to
use IPv4 NAT with private addresses internally, and IPv6
with end-to-end connectivity and PA addresses. Using the
private IPv4 addresses for internal connectivity would
provide stable addressing.
Address selection would get difficult in this case. For
external hosts one would like to prefer IPv6 over IPv4
(at least in the case with IPv4 NAT), while for internal
hosts one would like IPv4 over IPv6. In this scenario
one would also end up using split DNS (to have the
private IPv4 addresses only visible in internal DNS),
and one could consider solving this by only having IPv4
addresses for hosts in internal DNS.
To only use IPv4 for intra-site connectivity would be
a bad idea in the long term though. The site may at
some point in the future get some IPv6-only devices
or prefer to make some part of the site IPv6-only.
But this could be a possible path for a site that is
currently using IPv4 NAT and private addressing
internally.
5. Conclusions
We have discussed how one may use stable addressing
like ULA, or perhaps even private IPv4 address space,
to provide intra-site addressing to be independent of
the PA addresses used for external connectivity. This
means that internal addresses can remain fixed and be
independent of any renumbering caused by a change of
providers. The benefits are that internal connections
are not reset at the time of renumbering, but perhaps
more importantly that configuration of internal
services need not be changed. On the other hand, the
use of the internal addressing adds complexity like
split DNS and possible problems with address selection.
Whether these techniques are useful, depends on how
often one changes providers, on the number of services
deployed in the site, and how much internal communication
there is. They add complexity in day-to-day operations,
but make it easier to change providers, in particular if
there are many internal services deployed.
_______________________________________________
Ietf@xxxxxxxx
https://www.ietf.org/mailman/listinfo/ietf