Date: Fri, 2 Jun 2017 17:00:44 +0100 From: Matthew Seaman <matthew@FreeBSD.org> To: freebsd-questions@freebsd.org Subject: Re: IPv4 to IPv6 Message-ID: <0c5727a2-05ea-51e0-21bd-ded1c2b831b5@FreeBSD.org> In-Reply-To: <74b7b58aa45cc01585338ef2270ccc57.squirrel@webmail.harte-lyne.ca> References: <74b7b58aa45cc01585338ef2270ccc57.squirrel@webmail.harte-lyne.ca>
next in thread | previous in thread | raw e-mail | index | archive | help
This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --jxOOvFxSlRdL8fwic9Mk3aQn9G2dewdcM Content-Type: multipart/mixed; boundary="kn3VCakPK3d8tLb7ej1TgTifruoR10wmG"; protected-headers="v1" From: Matthew Seaman <matthew@FreeBSD.org> To: freebsd-questions@freebsd.org Message-ID: <0c5727a2-05ea-51e0-21bd-ded1c2b831b5@FreeBSD.org> Subject: Re: IPv4 to IPv6 References: <74b7b58aa45cc01585338ef2270ccc57.squirrel@webmail.harte-lyne.ca> In-Reply-To: <74b7b58aa45cc01585338ef2270ccc57.squirrel@webmail.harte-lyne.ca> --kn3VCakPK3d8tLb7ej1TgTifruoR10wmG Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable 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. >=20 > We will be using FreeBSD-11 as the platform for our Internet > connectivity. The main services we provide publicly are SMTP and DNS.=20 > 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 =3D=3D 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. --kn3VCakPK3d8tLb7ej1TgTifruoR10wmG-- --jxOOvFxSlRdL8fwic9Mk3aQn9G2dewdcM Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Comment: GPGTools - https://gpgtools.org iQJ8BAEBCgBmBQJZMYuxXxSAAAAAAC4AKGlzc3Vlci1mcHJAbm90YXRpb25zLm9w ZW5wZ3AuZmlmdGhob3JzZW1hbi5uZXQxOUYxNTRFQ0JGMTEyRTUwNTQ0RTNGMzAw MDUxM0YxMEUwQTlFNEU3AAoJEABRPxDgqeTnmb4QAJBUi3kPT71ExmxY731PeeZi K6aiZQdZVz6nMHpcPyapEkGlq0nZgGHWKPW3/ZEdsqUmDL3J6c3lsKxuLO9vh41G OJM8QmBl2RtYbw+/aa93mrtBrFAoUw1x6OsI5rw6kzkT7vqpT5sonfqb9YK6qz70 +sh+frB12vVy+TRR3E9o699kRvwqX/31JmohOWP9FeYtSL+oMKEdrA1X65vGKrLW UFpGCF0l5S79rL9OGhClkk4LiGFHIyf57TZbt9abs/2R1+JCaac+KzOkpe31+asi w0P66k5ujahmn+s8oBY4GTTiz4EwMYEyefZPmueimVb5/tiHg0wdz67RmeU2s1FA DP9TYlsKd2eLww4pRx/ixKWUBBgGj4KKYui0ZrLwNbgJ+4fKiLdHx+7XSUJlBXaU VhB4vPZmyrQQxaqpb5C2oL3EDQV7V4MJ/GyAB9O9OPqXli/CR1IrQi9NNjX1h0v+ Mx1xTEMQMoF4ie+nO5altxV/khJt9/a8gOI5S31HVWf07GRQ5xtFUytvBAtixWlD TX2xTe2QzBvR9px9G2IVsNF/yENMYyJDYtDWA0+mGuc4QfykQ0fP77QMAtZcrxd4 XG0Svsk5JPht3QnAJU0nm+w9wFwRS8X33Kg4lLbZHwgrRTLk87XK1hWvmzS19SM2 l7lg3lLN7Ue8/CNSN81N =552k -----END PGP SIGNATURE----- --jxOOvFxSlRdL8fwic9Mk3aQn9G2dewdcM--
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?0c5727a2-05ea-51e0-21bd-ded1c2b831b5>