IPv4 to IPv6

[Matthew Seaman]

On 2017/06/02 15:26, James B. Byrne via freebsd-questions wrote:
> We are beginning the process of transitioning to IPv6.  I have read a
> great deal respecting the difficulty of moving from IPv4 to IPv6 and
> maintaining general Internet connectivity.  If any reading this have
> gone through the process upon which we are embarking then I would be
> grateful if you share your experience. Particularly any 'gotchas' that
> cropped up.
> 
> We will be using FreeBSD-11 as the platform for our Internet
> connectivity. The main services we provide publicly are SMTP and DNS. 
> We will maintain IPv4 addresses for these together with IPv6.

I've /added/ IPv6 capability to an existing network -- there's no way
we're going to be dropping IPv4 any time soon.  It is really quite
straightforward.

Exactly how you get an IPv6 address allocation and get that routed to
your hosts depends very much on where in the world you are and what your
ISP is prepared to provide.  Most ISPs nowadays should be able to set up
IPv6 routing into your systems for you as a standard service offering.
Failing that, there are IPv6 "tunnel brokers" who will happily sell you
a service.

Now, assuming you've got to the stage where you have IPv6 being routed
to your network gateway, it is mostly plain sailing.

In general, it just works.  You configure your IPv6 addressing in
parallel to your IPv4 addressing scheme.  There are a number of, well,
not gotchas per se, but ways of thinking you will need to adjust.

First of all, you have to re-educate yourself from the mindset of IP
numbers being a scarce resource.

Forget about NAT.  Everything gets its own address.  In fact, you have
so many addresses to play with you can allocate an address to each host
chassis (the SLAAC address works well for this) plus a separate address
for each different network service you're running on it -- that way,
moving a service onto different hardware is mostly a matter of syncing
the data and moving one IPv6 address.

Without NAT you will need to write an effective firewall ruleset to
block unwanted traffic.  This isn't particularly difficult and a
correctly configured firewall is just as secure, if not more so than
what you'ld get from a NAT gateway.

It is true that IPv6 addresses are a bit of a pain to type, compared to
IPv4.  So allocate "short" addresses -- mostly runs of zeroes -- to your
DNS servers and possibly your default router, as those are the addresses
you get to type most frequently.   Otherwise rely on the DNS to turn
hostnames into addresses.

If you want to make it impossible for people to nmap your network range,
scatter your allocated addresses across the whole range available to
you.  If you're allocating a few hundred addresses out of a /64 you can
just generate addresses randomly without fear of collisions.   Note
there are some bits in an IPv6 address that flag certain different
address usages which you should be aware of -- see RFC 4291.

If nmap is not a concern, then fill up most of the host part of each
address with zeroes to make the typing a bit easier.

Second of all, the smallest sub-net prefix you should consider using is
a /64.  A typical IPv6 allocation to a company would be a /48, possibly
going up to a /32 for a really big installation[*].  If your allocation
is a /48, that means you have 2^16 == 65536 possible different /64
subnets available to you.  Considering that a /64 network gives you
about 18446744073709551615 different possible host addresses, it is not
really intrinsically more wasteful to allocate a /64 for a hand-off
network with only two active addresses as it is to allocate a /64 to a
LAN segment full of servers using a hundred or so addresses.

Forget about NAT.  Everything gets its own address.  In fact, you have
*so* many addresses to play with you can allocate an address to each
host chassis (the SLAAC address works well for this) plus a separate
address for each different network service you're running on it -- that
way, moving a service onto different hardware is mostly a matter of
syncing the data and moving one IPv6 address.

Without NAT you will need to write an effective firewall ruleset to
block unwanted traffic.  This isn't particularly difficult and a
correctly configured firewall offers just as much security, if not more
so, than you'ld get through a NAT gateway.

It is true that IPv6 addresses are a bit of a pain to type, compared to
IPv4.  So allocate "short" addresses -- mostly runs of zeroes -- to your
DNS servers and possibly your default router, as those are the addresses
you get to type most frequently.   Otherwise rely on the DNS to turn
hostnames into addresses.

If you want to make it impossible for people to nmap your network range,
scatter your allocated addresses across the whole range available to
you.  If you're allocating a few hundred addresses out of a /64 you can
just generate addresses randomly without fear of collisions.   If nmap
is not a concern, then fill up most of the host part of each address
with zeroes to make the typing a bit easier.

You will find that FreeBSD defaults to preferring IPv6 over IPv4 when
both are available.  This is mostly a good thing -- IPv6 typically
offers ping times a few milliseconds faster than IPv4 across the
Internet nowadays -- but if you need to be particularly cautious while
you are introducing IPv6, then look at ip6addrctrl(8) and
/etc/rc.d/ip6addrctl which will let you prioritize IPv4 over IPv6 during
the transitional period.

On the whole though setting up IPv6 networks is really no harder than
setting up IPv4 networks.

	Cheers,

	Matthew

[*] At least, this is the case in the RIPE region.  I don't think the
other regional bodies do things significantly differently.  If you're
getting a sub-allocation from an ISP, then they really should be
prepared to be similarly generous.

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 972 bytes
Desc: OpenPGP digital signature
URL: <http://lists.freebsd.org/pipermail/freebsd-questions/attachments/20170602/3093913d/attachment.sig>