IPv6 fc00::/7 - Unique local addresses

George Bonser gbonser at seven.com
Thu Oct 21 17:36:29 UTC 2010



> -----Original Message-----
> From: Ray Soucy > Sent: Thursday, October 21, 2010 5:00 AM
> To: Jeroen van Aart
> Cc: NANOG list
> Subject: Re: IPv6 fc00::/7 - Unique local addresses


> The mindset of using RFC1918 space, throwing everything behind a NAT
> box, and not having to re-configure systems when you change ISP
> doesn't exist in IPv6.  There is no IPv6 NAT (yet).

And that is one of the real challenges here.  An office that is not
multihomed and has only a short commit to a provider may be reluctant to
number their network in that provider's PA space if they really do not
want to remain "sticky" to that provider.  I can understand that
position as I tend not to want to be "sticky" to a provider either.
Things change quickly in the world and market rates for connectivity can
change rapidly. Short term agreements that give the user the flexibility
to move easily to a different provider can be desirable but it might
also be impossible to convince the CFO that they need to obtain two
providers in order to get their own address block.

The issue driving many small networks to multihome isn't really so much
that they NEED to multihome, it is because they really want to be able
to change providers without renumbering their network/services.
RFC-1918 with NAT gave them that flexibility with v4.  LUA doesn't
really give them that as it currently stands.  You can number your
networks with both, but that can lead to some interesting RA
configurations and can be fun to watch depending on what gear is in
place.

> 
> If you wanted to setup an "island" of IPv6 that would never talk to
> the Internet, then you could use ULA, but that would only be needed if
> you plan on routing between LANs.  Remember that by default every IPv6
> host has a link-local address allowing it to talk to any directly
> connected hosts without configuration.  So if you're simply looking
> for some sort of ad-hoc network, it's likely already there.

The problem is in putting such link local addresses into the local DNS
so hosts can find each other.  I generally consider link local IPs in
DNS to be a "bad idea" unless it is in a subdomain dedicated that that
specific subnet. Given a flat network that isn't routed and is used for
clustering machines together, it is a "flat" layer 2 net with no layer3
interfaces except for the hosts themselves (no router interfaces on the
network) then having a subdomain just for the hosts on that specific
subnet that include the link local IPs on that specific subnet might
work.  But that is the right application of ULA.  That subnet will never
get routed off the site so what the heck.  In fact, it will never get
routed at all.


> As much as I hate NAT and want to see it go away.  I think the biggest
> transition mechanism for people to get online with IPv6 will be some
> sort of appliance that does NAT of global IPv6 addresses to private
> IPv4 addresses to keep all the people living in the NAT world from
> having to redesign their networks.  It's ugly, but its the path of
> least resistance and that's likely what will happen when we see IPv6
> become required to do business... at least as a stepping stone.

That is going to be a tough sell to the network operators. The
enterprise guys are all going to say "we need stable addressing that is
not tied to a provider" the network operators are going to say
"multihome and get your own block" and the enterprise guys are going to
say "we already have two connections to our primary provider and can
tolerate an outage, this isn't a business killing critical network and
it would take a major failure of our current provider or the TELCO to
cause us to be completely unreachable, we can't make the business case
to justify two transit provider contracts but we DO need stable address
space because there are just so many problems with autoconfiguration
that we can't make that work in a reliable way".

And maybe fixing autoconfiguration is where the key lies to this
problem.  Having RA announce multiple prefixes is a challenge, though,
and as far as I know there is no standard way of saying: "get all
available prefixes from the router and use that prefix to mask this host
address".  For example, say I have configured the host with a "static
host mask", for lack of a better name, that uses a ULA address as the
mask.  Say the mask is fdf7:77d7:b935:123:1b

The router is announcing  fd11:d148:570f:aaaa:/64 (a ULA subnet), and
2001:200:c000:f473::/64 (some random thing I pulled out of BGP plus some
randomness representing some assigned space).

So I overlay those prefixes onto the "default" host IP mask.  I end up
configuring fd11:d148:570f:aaaa:123:1b/64 2001:200:c000:f473:123:1b/64.
As I am applying a unique local mask to either a unique local or unique
global prefix, I should end up with a unique address either way and can
then configure my interface in several subnets in a stable manner that
doesn't change over time no matter what provider prefixes I might have
and it won't care what the mask is of the subnet prefix being announced
by the router as long as it is longer than a /8, I am ok. I route
f700::/7 via fd11:d148:570f:aaaa::/64 net gateway and ::/0 via the
2001:200:c000:f473::/64 gateway and I am all set.  If my provider
changes in the future, I change the prefixes announced from the router
and up/down the interface and I am done.  The problem is in getting
autoconfiguration and RA to do all that exactly the same way with all
hosts and all routers of all vendors.  Having autoconfig on the host
with an option to use a "default address mask" in addition to being able
to calculate an EUI-64 can provide a network with some stability and
predictability. 


As for the other problem with trying to use two separate PA blocks,
forget it.  If you are multihomed, get your own block.  That is the only
good way forward.





More information about the NANOG mailing list