Re: IPv6 fc00::/7 — Unique local addresses

Owen DeLong owen at delong.com
Thu Oct 21 12:26:13 UTC 2010


On Oct 21, 2010, at 4:59 AM, Ray Soucy wrote:

> Sorry for the double post.  From re-reading the thread it doesn't
> sound like you might want ULA at all.
> 
> 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 hopefully there never will be...

> 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.
> 
You may want non-LL space even if you aren't routing, since for LL,
the destination address has to include the outbound interface name
or it doesn't work.

> 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.
> 
NAT64 already exists, although generally not for that application.

I'm not convinced it is the path of least resistance, technically. If
you mean politically, then, yes, but, making engineering decisions
based on the political path of least resistance tends to cause more
damage than it resolves.

You don't actually have to redesign your IPv4 NAT network to
put IPv6 on it in parallel. You just need to recognize that the
IPv6 stateful firewall now provides your IPv6 security without
needing to mangle the packet header in the process. You should
be able to put all the same exact policies in place, without the
nasty address translation bits.

> The idea to use multiple PA IPv6 allocations and have multiple GUAs
> for each host wasn't a bad one.  It would certainly make the Internet

If it worked, it would be a great one, but...

> routing table a lot more stable to not have everyone touching BGP...
> But they failed to fix DNS in a way that would make it possible.  We

Not just DNS... It would have impacted TCP, to some extent, UDP,
applications, etc.

> already have priority for MX records.  If we had priority for all
> records, and resolvers would remember when one was unreachable for a
> short time, then yes, you could have www.yourdomain.com point to

The resolver doesn't have any way to know the reachability status of
a given address from the resolver client. The information simply isn't
available to the resolver. I suppose you could design a mechanism for
the client to send feedback to the resolver, but, that's pretty hokey.

> multiple PA GUAs and if one was down users would nicely fail-over to
> the other.  Unfortunately, if you have a host record with multiple
> AAAAs and one of them is unreachable, it will just mean that for some
> users the request will time out (as its just doing a round-robin and
> not trying others when things don't respond).
> 
Actually, unless the client software is exceptionally poorly written, it
won't time out, but, the delay before trying the next host is exceedingly
long (30 seconds) if you don't get an unreachable message back about
the first attempt(s).

> In theory, you could try to get around the limitation by having a TTL
> of 30 seconds or something on your records, and have a system that
> would update DNS records when a connection dropped, but that's
> assuming people aren't deciding to set minimum cache times of their
> own.
> 
We already know that M$ absolutely breaks this across the board.

> I think the best model possible with existing technology that's
> available is to separate L2 and L3 and use provider redundancy at L2
> (multiple ME transport providers to your single, redundant, L3 transit
> provider).  If you need more redundancy that that, you're likely using
> BGP for IPv4 already, anyway.
> 
You can get exactly the same reliability from IPv6 as you have in IPv4
using pretty much exactly the same tactics.

If you're using IPv4 with multiple providers giving you different NAT
pools, then, you're looking at outbound, not inbound resiliency and
the DNS stuff you described is irrelevant. As long as your outbound
gateway(s) have some way to detect provider down-ness (all the
same tactics that work for IPv4 here work for IPv6 with pretty much
the same flaws), you can do the same thing. The difference is that
in IPv6, you have to tell the hosts which IPv6 source prefix to use.
The easy way to do that is to alter the desired/valid lifetimes in
your internal RAs accordingly. This isn't hard to script.

If you're using IPv4 with BGP and advertising the same prefix(es)
to multiple providers, the same thing works in IPv6 with nearly
identical processes.

If you've got meaningful in-bound resiliency in IPv4, then, you're
using IPv4 with BGP and advertising the same prefix(es) to
multiple providers anyway. If you're doing something else in IPv4,
then, you're pretending to have resiliency and it will work just
as poorly in IPv6, most likely.

> The real problem never goes away, though.  People like the operational
> control and simplicity that they get with NAT.  If the provider goes

Huh?

I don't see what NAT gives you for EITHER of those things.

> down, they still work internally, if they have multiple providers, the

There's no reason that can't be true with IPv6. NOTHING says
your IPv6 prefix use internally has to be affected by your provider
going down.

> internal network doesn't care which is active, and if they need to
> host services, they usually go with a hosting company off-site.  I

This is achievable in IPv6, too. If you have multiple providers, that's
sufficient justification to obtain an IPv6 prefix from most RIRs. Once
you do that, your internal network doesn't care which provider is active.

> really don't think it will be long before we see some magic IPv6 NAT
> boxes start to pop up, whether or not standards exist for them, and it
> will be and ugly nightmare.
> 
I really really really hope you are wrong about that.

> IPv6 is simple enough for larger networks (like universities and
> governments) but very little attention has been giving to the SMB
> community and their needs with IPv6.
> 
I disagree... Please let me know where you think IPv6 falls short for
SMB and I will be happy to show you feasible solutions.

Owen
2620:0:930::/48	ARIN direct assignment, multihomed through (relatively)
	cheap connectivity at my house.

> On Thu, Oct 21, 2010 at 7:33 AM, Ray Soucy <rps at maine.edu> wrote:
>> For for all intents and purposes if you're looking for RFC1918 style
>> space in IPv6 you should consider the block FD00::/8 not FC00::/7 as
>> the FC00::/8 space is reserved in ULA for assignment by a central
>> authority (who knows why, but with that much address space nobody
>> really cares).
>> 
>> People may throw a fit at this, but as far as I'm concerned FD00::/8
>> will never leave the edge of our network (we null route ULA space
>> before it can leak out, just like you would with RFC1918 space).  So
>> you can pretty much use it has you see fit.  If you want to keep your
>> ULA space short there is nothing stopping you from using something
>> like FD00::1 as a valid address.
>> 
>> You could embed your ASN into it or some other identifier if you want
>> to avoid conflicts with other non-routed address space which should
>> never enter or leave your network from the outside, but I'm just not
>> seeing the practical application for this.
>> 
>> On Wed, Oct 20, 2010 at 5:48 PM, Jeroen van Aart <jeroen at mompl.net> wrote:
>>> <IPv6 newbie>
>>> 
>>> According to http://en.wikipedia.org/wiki/IPv6_address#Special_addresses an
>>> fc00::/7 address includes a 40-bit pseudo random number:
>>> 
>>> "fc00::/7 — Unique local addresses (ULA's) are intended for local
>>> communication. They are routable only within a set of cooperating sites
>>> (analogous to the private address ranges 10/8, 172.16/12, and 192.168/16 of
>>> IPv4).[12] The addresses include a 40-bit pseudorandom number in the routing
>>> prefix intended to minimize the risk of conflicts if sites merge or packets
>>> are misrouted into the Internet. Despite the restricted, local usage of
>>> these addresses, their address scope is global, i.e. they are expected to be
>>> globally unique."
>>> 
>>> I am trying to set up a local IPv6 network and am curious why all the
>>> examples I come accross do not seem to use the 40-bit pseudorandom number?
>>> What should I do? Use something like fd00::1234, or incorporate something
>>> like the interface's MAC address into the address? It'd make the address
>>> quite unreadable though.
>>> 
>>> Thanks,
>>> Jeroen
>>> 
>>> --
>>> http://goldmark.org/jeff/stupid-disclaimers/
>>> http://linuxmafia.com/~rick/faq/plural-of-virus.html
>>> 
>>> 
>> 
>> 
>> 
>> --
>> Ray Soucy
>> 
>> Epic Communications Specialist
>> 
>> Phone: +1 (207) 561-3526
>> 
>> Networkmaine, a Unit of the University of Maine System
>> http://www.networkmaine.net/
>> 
> 
> 
> 
> -- 
> Ray Soucy
> 
> Epic Communications Specialist
> 
> Phone: +1 (207) 561-3526
> 
> Networkmaine, a Unit of the University of Maine System
> http://www.networkmaine.net/





More information about the NANOG mailing list