Use of unique local IPv6 addressing rfc4193
Hi, We're looking at rolling out IPv6 to our internal DC infrastructure. Those systems support only our internal network and in the IPv4 world they all live in 'private' space of 10.0.0.0/8. I was wondering if anyone uses the fc00::/7 space for these sort of things or do ppl use a bit of their public IPv6 allocation and manage the security for those ranges? I realise I'd have to use a proxy or NAT66 for the regular outbound connectivity (but we do it already for IPv4 anyway). The truth is that even if we do use something out of our public allocation we're likely to do the same thing (just to be sure that nothing spills out accidentally). So what do you do in this space? kind regards Pshem
In message <CAEaZiRU+wgQ0GDzxcmtqKO=_SASAVsNX31Q_70Q+uDM1oeoHrQ@mail.gmail.com>, Pshem Kowalczyk writes:
Hi,
We're looking at rolling out IPv6 to our internal DC infrastructure. Those systems support only our internal network and in the IPv4 world they all live in 'private' space of 10.0.0.0/8. I was wondering if anyone uses the fc00::/7 space for these sort of things or do ppl use a bit of their public IPv6 allocation and manage the security for those ranges? I realise I'd have to use a proxy or NAT66 for the regular outbound connectivity (but we do it already for IPv4 anyway). The truth is that even if we do use something out of our public allocation we're likely to do the same thing (just to be sure that nothing spills out accidentally).
So what do you do in this space?
kind regards Pshem
If you have a NAT you can't prevent things spilling out. The ONLY way to prevent things spilling out is to not connect the network in any shape or form. All NAT does is make it harder to run your network and increases the cost of software development. Mark -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka@isc.org
With NAT I have a single entry/exit point to those infrastructure subnets which can be easily policed. If I give them public IPs then they're routable and potentially can reach the internet via devices that don't police the traffic. My real question is does anyone bother with the fc00::/7 addressing or do you use your public space (and police that)? kind regards Pshem On Fri, 9 Sep 2016 at 10:27 Mark Andrews <marka@isc.org> wrote:
Hi,
We're looking at rolling out IPv6 to our internal DC infrastructure. Those systems support only our internal network and in the IPv4 world they all live in 'private' space of 10.0.0.0/8. I was wondering if anyone uses
fc00::/7 space for these sort of things or do ppl use a bit of their
IPv6 allocation and manage the security for those ranges? I realise I'd have to use a proxy or NAT66 for the regular outbound connectivity (but we do it already for IPv4 anyway). The truth is that even if we do use something out of our public allocation we're likely to do
In message <CAEaZiRU+wgQ0GDzxcmtqKO=_ SASAVsNX31Q_70Q+uDM1oeoHrQ@mail.gmail.com>, Pshem Kowalczyk writes: the public the
same thing (just to be sure that nothing spills out accidentally).
So what do you do in this space?
kind regards Pshem
If you have a NAT you can't prevent things spilling out. The ONLY way to prevent things spilling out is to not connect the network in any shape or form.
All NAT does is make it harder to run your network and increases the cost of software development.
Mark -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka@isc.org
You can also easily police a subnet. On Sep 8, 2016 6:11 PM, "Pshem Kowalczyk" <pshem.k@gmail.com> wrote:
With NAT I have a single entry/exit point to those infrastructure subnets which can be easily policed. If I give them public IPs then they're routable and potentially can reach the internet via devices that don't police the traffic.
My real question is does anyone bother with the fc00::/7 addressing or do you use your public space (and police that)?
kind regards Pshem
On Fri, 9 Sep 2016 at 10:27 Mark Andrews <marka@isc.org> wrote:
In message <CAEaZiRU+wgQ0GDzxcmtqKO=_ SASAVsNX31Q_70Q+uDM1oeoHrQ@mail.gmail.com>, Pshem Kowalczyk writes:
Hi,
We're looking at rolling out IPv6 to our internal DC infrastructure. Those systems support only our internal network and in the IPv4 world they
all
live in 'private' space of 10.0.0.0/8. I was wondering if anyone uses the fc00::/7 space for these sort of things or do ppl use a bit of their public IPv6 allocation and manage the security for those ranges? I realise I'd have to use a proxy or NAT66 for the regular outbound connectivity (but we do it already for IPv4 anyway). The truth is that even if we do use something out of our public allocation we're likely to do the same thing (just to be sure that nothing spills out accidentally).
So what do you do in this space?
kind regards Pshem
If you have a NAT you can't prevent things spilling out. The ONLY way to prevent things spilling out is to not connect the network in any shape or form.
All NAT does is make it harder to run your network and increases the cost of software development.
Mark -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka@isc.org
On Thu, 08 Sep 2016 23:09:28 -0000, Pshem Kowalczyk said:
If I give them public IPs then they're routable and potentially can reach the internet via devices that don't police the traffic.
They can potentially reach the Internet even without public IPs. All it takes is one idiot with a laptop with a Wifi and Internet Connection Sharing. Or one miscreant.
In message <CAEaZiRXU7DH9O9EwdjFiEMgDU7dt4v62W5+9+CTJ2-rqznP7Bg@mail.gmail.com>, Pshem Kowalczyk writes:
With NAT I have a single entry/exit point to those infrastructure subnets which can be easily policed. If I give them public IPs then they're routable and potentially can reach the internet via devices that don't police the traffic.
If you wish to believe that, believe that, but it is only wishful thinking.
My real question is does anyone bother with the fc00::/7 addressing or do > you use your public space (and police that)?
ULA is normally used in parallel with public addressing if it is used. IPv6 was designed to be deployed with multiple address and prefixes per interface. When ULA is deployed you have ULA <-> ULA, non-ULA <-> non-ULA. Non-privacy addresses for server functionality, privacy addresses for client functionality. Mark
kind regards Pshem -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka@isc.org
Hi, That's why I asked the question - if anyone actually puts its as an additional IP on their interfaces to keep it simple (and in-line with IPv4 policies, address allocation schemes, etc) or not. I can see the argument both ways - if we decide to use it we'll have to either overlay it with public IPv6 space (and provide the NAT/proxy for where we don't have any public IPv6 assigned) or simply not use the fc00::/7 and skip the NAT/proxy aspects of it. So one way it's aligned with what we do already (at the cost of the overhead) the other it's not aligned (but with potentially less overhead). kind regards Pshem On Fri, 9 Sep 2016 at 11:27 Mark Andrews <marka@isc.org> wrote:
In message < CAEaZiRXU7DH9O9EwdjFiEMgDU7dt4v62W5+9+CTJ2-rqznP7Bg@mail.gmail.com>, Pshem Kowalczyk writes:
With NAT I have a single entry/exit point to those infrastructure subnets which can be easily policed. If I give them public IPs then they're routable and potentially can reach the internet via devices that don't police the traffic.
If you wish to believe that, believe that, but it is only wishful thinking.
My real question is does anyone bother with the fc00::/7 addressing or do > you use your public space (and police that)?
ULA is normally used in parallel with public addressing if it is used. IPv6 was designed to be deployed with multiple address and prefixes per interface. When ULA is deployed you have ULA <-> ULA, non-ULA <-> non-ULA. Non-privacy addresses for server functionality, privacy addresses for client functionality.
Mark
kind regards Pshem -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka@isc.org
On Thu, 2016-09-08 at 23:43 +0000, Pshem Kowalczyk wrote:
both ways - if we decide to use it we'll have to either overlay it with public IPv6 space (and provide the NAT/proxy for where we don't have any public IPv6 assigned) or simply not use the fc00::/7 and skip the NAT/proxy aspects of it.
There is no necessary link between ULA addresses and NAT. You don't have to NAT ULA, *ever*. If you need public addresses, go get them. There are enough. IMHO one should use ULA in only three situations: - a completely isolated network - for internal communications e.g. fabric management) - for testing Regards, K. -- ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Karl Auer (kauer@biplane.com.au) http://www.biplane.com.au/kauer http://twitter.com/kauer389 GPG fingerprint: E00D 64ED 9C6A 8605 21E0 0ED0 EE64 2BEE CBCB C38B Old fingerprint: 3C41 82BE A9E7 99A1 B931 5AE7 7638 0147 2C3C 2AC4
I agree with Karl. We use the ULA space for our internal test labs. The /48's we have in use get routed around internally but have no chance of leaking to the internet. Spencer Ryan | Senior Systems Administrator | sryan@arbor.net<mailto:sryan@arbor.net> Arbor Networks +1.734.794.5033 (d) | +1.734.846.2053 (m) www.arbornetworks.com<http://www.arbornetworks.com/> ________________________________ From: NANOG <nanog-bounces@nanog.org> on behalf of Karl Auer <kauer@biplane.com.au> Sent: Thursday, September 8, 2016 8:49:34 PM To: nanog@nanog.org Subject: Re: Use of unique local IPv6 addressing rfc4193 On Thu, 2016-09-08 at 23:43 +0000, Pshem Kowalczyk wrote:
both ways - if we decide to use it we'll have to either overlay it with public IPv6 space (and provide the NAT/proxy for where we don't have any public IPv6 assigned) or simply not use the fc00::/7 and skip the NAT/proxy aspects of it.
There is no necessary link between ULA addresses and NAT. You don't have to NAT ULA, *ever*. If you need public addresses, go get them. There are enough. IMHO one should use ULA in only three situations: - a completely isolated network - for internal communications e.g. fabric management) - for testing Regards, K. -- ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Karl Auer (kauer@biplane.com.au) http://www.biplane.com.au/kauer http://twitter.com/kauer389 GPG fingerprint: E00D 64ED 9C6A 8605 21E0 0ED0 EE64 2BEE CBCB C38B Old fingerprint: 3C41 82BE A9E7 99A1 B931 5AE7 7638 0147 2C3C 2AC4
On Thursday, September 8, 2016, Pshem Kowalczyk <pshem.k@gmail.com> wrote:
With NAT I have a single entry/exit point to those infrastructure subnets which can be easily policed. If I give them public IPs then they're routable and potentially can reach the internet via devices that don't police the traffic.
My real question is does anyone bother with the fc00::/7 addressing or do
Yes. That space is used for non-internet scenarios. NAT is bad CB
you use your public space (and police that)?
kind regards Pshem
On Fri, 9 Sep 2016 at 10:27 Mark Andrews <marka@isc.org <javascript:;>> wrote:
In message <CAEaZiRU+wgQ0GDzxcmtqKO=_ SASAVsNX31Q_70Q+uDM1oeoHrQ@mail.gmail.com <javascript:;>>, Pshem
Kowalczyk writes:
Hi,
We're looking at rolling out IPv6 to our internal DC infrastructure. Those systems support only our internal network and in the IPv4 world they all live in 'private' space of 10.0.0.0/8. I was wondering if anyone uses the fc00::/7 space for these sort of things or do ppl use a bit of their public IPv6 allocation and manage the security for those ranges? I realise I'd have to use a proxy or NAT66 for the regular outbound connectivity (but we do it already for IPv4 anyway). The truth is that even if we do use something out of our public allocation we're likely to do the same thing (just to be sure that nothing spills out accidentally).
So what do you do in this space?
kind regards Pshem
If you have a NAT you can't prevent things spilling out. The ONLY way to prevent things spilling out is to not connect the network in any shape or form.
All NAT does is make it harder to run your network and increases the cost of software development.
Mark -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka@isc.org <javascript:;>
On Thu, Sep 8, 2016 at 7:17 PM, Ca By <cb.list6@gmail.com> wrote:
NAT is bad
On 09/08/2016 04:09 PM, Pshem Kowalczyk wrote:
With NAT I have a single entry/exit point to those infrastructure subnets which can be easily policed.
I have used NAT in IPv4 scenarios as an alternative for lack of routing control in the return direction. However, this does not mean that this is the correct, best or orthodox way, even for IPv4, much less in IPv6. So, even though you can hack your way using NAT, this is really a routing problem, not an addressing problem. And you will just create problems for your users, your developers, yourself and third parties.
If I give them public IPs then they're routable and potentially can reach the internet via devices that don't police the traffic.
First: this can happen with NAT too. If other devices have access to the Internet, they can just NAT themselves even if the third-party exit has a private address. Second: private addresses can reach the Internet too. Many devices and ISPs don't block RFC5375-sourced packets from the Internet. So they can go out, although they can't come back. This is enough to create unsourceable attacks. In both cases NAT isn't really solving any of your problems fully. It's just a misconception.
My real question is does anyone bother with the fc00::/7 addressing or do you use your public space (and police that)?
I use public address space and I have made sure I have a single point of exit and return for my traffic. If I understood your concerns correctly, then I'd add that if the user forces traffic through third-party exit points, service is not guaranteed, as the third party may BCP38-filter it. If you want to absolutely prevent that, NAT will not help. You'll need other techniques. Best regards and good luck!
participants (9)
-
Ca By -
Josh Reynolds -
Karl Auer -
Mark Andrews -
Octavio Alvarez -
Pshem Kowalczyk -
Ryan, Spencer -
Valdis.Kletnieks＠vt.edu -
Yang Yu