mapping public to private IPv6 networks when firewalling

Ted Mittelstaedt tedm at ipinc.net
Wed Nov 30 08:12:15 CET 2011


On 11/29/2011 2:32 AM, Johan REMY wrote:
>
>> Johan,
>>
>> On 2011-11-29 06:01, Johan REMY wrote:
>>> *Tore Anderson
>>>
>>>> * Phil Mayers
>>>
>>>>> On 11/28/2011 06:10 AM, Erik Kline wrote:
>>>>>> Much more interesting I think is ULA + global prefix on the
>>>>>> same link. When all "internal-only" services have ULAs in
>>>>>> DNS then internal communication remains via stable ULA
>>>>>> addressing.  External communication can be via the global
>>>>>> prefix addresses, and as long as these aren't in internal
>>>>>> DNS then renumbering is less of a problem than it otherwise
>>>>>> would be.
>>>>> AIUI, that won't work well (yet). Current RFC 3484 tables
>>>>> don't "know" ULA, so will assume it's a normal prefix and try
>>>>> to use it for global traffic.
>>>> Actually global addresses + ULAs on the same link is likely to
>>>> work well, due to the longest matching prefix rule in RFC 3484
>>>> (fc00::/7 and 2000::/3) has a common prefix length of 0). The
>>>> ULA dualstack brokenness problem occurs when there's only ULAs
>>>> on the link plus a default IPv6 route, as most operating
>>>> systems will then unsuccessfully attempt to use the ULAs,
>>>> timeout, before eventually falling back on IPv4.
>>>
>>> I have already try this but it is really broken. ULA IPv6 +
>>> Global IPv6 , both via RA on win7. Default route learned via RA
>>> too, no static config (the point is to be automatic). It tries to
>>> use ULA addresses to surf the internet and makes that
>>> configuration impossible for production environment. DHCPv6
>>> currently doesn't help. ULA + global is for me the real good
>>> solution (way better than NAT) but a lot a thing needs to be
>>> fixed before it can be used.
>>
>> draft-ietf-6man-rfc3484-revise is supposed to fix this. Not sure
>> when Windows will get it though.
>
> Thanks, I didn't know about that draft. However, I fear it will reach
> standard and be integrated in OS too late. IPv6 NAT might be ready
> before and we'll be forced to use it as it doesn't change IPv4
> usages.
>
> Now is the time people starts to feel concern and they design there
> networks (or at least think about it). Ends customers are asking for
> advice to their operator and we currently cannot give them a good
> solution.

Wrong, there is a good solution.  The good solution is to tell the
end users that if they want to run IPv6 that using DNS in their
configuration files is mandatory as IPv6 does not have any provision
for NAT, and thus they cannot assume that it is safe to hard-code
IP addresses in their config and .ini files.

90% of the customers I tell this to accept it.  The 10% that don't
accept it are intelligent and savvy enough to already know that it
is a very bad thing to scatter actual IP addresses throughout config
files in their network, and they aren't doing it now.  Renumbering
doesn't scare them because they already setup their network properly
from the beginning so that all of the hard-coded ugliness is
confined in their DNS servers where it's supposed to be, and
they dynamically assign just about everything.  Renumbering an
IPv6 prefix would be an hour of work in their routers and touching
a few servers networking configs and then they are done.

The 90% that accept the first argument are the ones that don't 
understand networking.  They accepted NAT in the IPv4 world because
that is what the vendors and their betters told them to use.  NAT
allowed them to make sloppy assumptions like assuming that they
could build networks that had static IP addresses in them that would
never ever change.  Then some software vendors (who mostly don't know
anything about networking) made those same sloppy assumptions and
that is why you have software programs out there that will even
allow people to put actual IPv4 digits into fields that should have
DNS hostnames in them.

In the Windows world I have seen many admins who have memorized
their server IP addresses.  I seem them use these numbers all of the
time - they use them when defining VPN icons on desktops, they
use them when they want to RDP into servers, they use them when
they want to test with pings, the list goes on and on.  I have
taken it upon myself to try to train these people in how to do
things the Right Way and it makes a difference.  Recently for example
I had a customer thank me for getting anal on him years earlier
and always insisting that he use actual hostnames when he defined
VPN icons on his road warriors desktops - because sure enough
he had to renumber and he had a few hundred road warriors out
there.  If he had done it the thick-headed way it would have been
weeks getting to all of them to change things.

This is just a paradigm shift and it really is a lot easier to
make than you think.  A surprising amount of software that
used to allow dotted-quad in places where hostnames are supposed
to go, will blow chunks when you try to stick in actual IPv6
numbers in places where IPv6 hostnames are supposed to go.
Apache does this for example.  IPv6 numbers are different enough
from dotted-quad that the admins who don't know any better are
generally easy enough to push into using DNS when dealing with
IPv6.

> It is between "you will have to renumber", or "take PI
> space", or "do some tricky nat/specific routing/..". Considering they
> don't want to renumber and that PI is too hard/expensive for them,
> they just don't do IPv6, or in a few months, they'll do some NAT.
>

They will do what they are told.  You seem to think that people
who are pro-NAT and want to use NAT in IPv6 are the rational,
thoughtful, intelligent people who have spent many hours
researching and learning about networking, and have carefully
weighed all of the arguments and arrived at the notion that
it's an absolute requirement to infest their networks with
static IP addresses in configuration files buried everywhere,
and thus they must avoid renumbering at all cost.

In reality, the people who are pro-NAT in IPv6 are mostly not
like this at all.  What they are like is ignorant and they
don't know anything at all about IPv6.  They barely know what
NAT is much less the implications of using it in their IPv4
networks.  They aren't going to do IPv6 in a few months because
they can do some NAT, they will resist and avoid IPv6 for as
long as possible, simply because they have an arsenal of
excuses as to why they can't spend the time after the workday
is over, educating themselves more in their trade of administering
networks.

There are a few smart guys running around out there in the IPv6
world who are trying desperately to make NAT de rigueur in the
IPv6 world.  Most of them have ulterior motives, and those are
mainly trying to get a standard in place so they can design and
sell complicated boxes that do IPv6 NAT, and make a lot of
money off of poor saps who know nothing about IPv6 and are
just starting to play with it.  If you are one of these people
then I can't say anything that will get you to abandon your
golden NAT-calf.  But if you were merely influenced by one
of these people then I urge you to drop your preconceptions and
look at IPv6 the way it was intended to be deployed.  It really
is a better way to network.

Ted


More information about the ipv6-ops mailing list