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

[Ray Soucy <rps () maine edu>]

See... You're falling into the same elitist mindset that I was trapped
in a year ago.

Perception is a powerful thing.  And Joe IT guy at Mom and Pop dot com
(who's network experience involves setting up a Linksys at home) loves
his magical NAT box firewall appliance.  Over the last year I've been
trying to fight the NAT war and have gotten pretty beat down.  It
doesn't matter if *we* know NAT is wrong, undesirable, and breaks the
Internet... we all live in the large scale, multi-homed, BGP, mega
Internet land.

Start working with smaller shops, and you'll find the typical setup is
a bunch of switches and a "VPN Firewall" picked up from Best Buy, or
maybe a Sonicwall or something.  These guys couldn't manage public
IPv4 let alone public IPv6, because the term "private" gives them that
warm and fuzzy false sense of security and lets them change their ISP
without reconfiguring a single thing (they often wouldn't know where
to start anyway).

They *will* fight you, and tell you to your face that if you want to
take NAT away from them it will be from their cold dead hands.

Why? Because we've had 10 years of "consultants" selling NAT as the
best thing for security since sliced bread.

Maybe we could get them to do it the right way if they had some sort
of IPv6 appliance that dumbed things down, but it simply doesn't exist
yet.  When it is created, it will be created by the people with the
NAT mindset wishing to maintain the status quo.

At least that's my prediction...

We need to keep in mind that most on this list is likely at a
completely different level than anything you'd find in the SMB
community.  They can't afford to hire "networking" people, they hire
"IT" people who are tasked with anything related to technology and
usually completely understaffed.  Thus they want the quick, painless,
easy solution.

On Thu, Oct 21, 2010 at 8:26 AM, Owen DeLong <owen () delong com> wrote:
> 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 () 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 () 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/



-- 
Ray Soucy

Epic Communications Specialist

Phone: +1 (207) 561-3526

Networkmaine, a Unit of the University of Maine System
http://www.networkmaine.net/