best practices for management nets in IPv6
Hi All, We're pushing to get IPv6 deployed and working everywhere in our operation, and I had some questions about best practices for a few things. On your management nets (network device management nets) , what's the best approach for addressing them? Do you use ULA? Or do you use global addresses and just depend on router ACLs to protect things? How close are we to having a central registry for unique local addresses, and will that really happen? Tom ----------------------------------------------------------------------------- Tom Ammon Network Engineer M: (801)674-9273 tom.ammon@utah.edu Center for High Performance Computing University of Utah http://www.chpc.utah.edu -----------------------------------------------------------------------------
On Tue, Jul 12, 2011 at 6:31 PM, Tom Ammon <tom.ammon@utah.edu> wrote:
Hi All,
We're pushing to get IPv6 deployed and working everywhere in our operation, and I had some questions about best practices for a few things.
On your management nets (network device management nets) , what's the best approach for addressing them? Do you use ULA? Or do you use global addresses and just depend on router ACLs to protect things? How close are we to having a central registry for unique local addresses, and will that really happen?
What if you apply to a /48 block as end-user because the management network is not part of your ISP-related /32 or larger block ? What if you happen to get that /48 and never announce it to the DFZ ? Then your attack surface gets very small (but still exists, you'll need some ACLs here and there, notably your customers having default-routes to your core). Rubens
On Jul 12, 2011 2:33 PM, "Tom Ammon" <tom.ammon@utah.edu> wrote:
Hi All,
We're pushing to get IPv6 deployed and working everywhere in our
operation, and I had some questions about best practices for a few things.
On your management nets (network device management nets) , what's the best
approach for addressing them? Do you use ULA? Or do you use global addresses and just depend on router ACLs to protect things? How close are we to having a central registry for unique local addresses, and will that really happen?
ACL are prone to typos and inconsistent deployment. If the security policy is that a give interface must not talk to the internet, ULA is a good choice as part of a multi-layer security strategy Cb
Tom
-----------------------------------------------------------------------------
Tom Ammon Network Engineer M: (801)674-9273 tom.ammon@utah.edu
Center for High Performance Computing University of Utah http://www.chpc.utah.edu
-----------------------------------------------------------------------------
Public IPs. At some point you will have to manage something outside your current world or your organization will need to merge/partner/outsource/contract/etc with someone else's network and they might not be keen to route to your ULA space (and might not be more trustworthy than the internet at large anyhow). Think about things like VPN endpoints, video devices, telephones, etc, that may end up on a public network, maybe behind a device you manage. You may just manage routers today, but who knows about tomorrow. Put behind a firewall and use good ingress filtering throughout your network, separating trust zones with distinct subnets. If you are worried about forgetting to enable a firewall, put in a network management system to verify connectivity stays blocked combined with a monitored IDS.
I couldn't agree more. If you set up private address space, it's going to come back and make more work for you later. Set up public IPv6 addresses. If you need stateful connection filtering, put in a stateful firewall. If you really really need address obfuscation, you can still do NAT, but NAT from public addresses to public a public address or pool of public addresses. If you ever need to turn off NAT, it's a lot easier than renumbering hundreds of machines and you always have the option of disabling it per-host instead of doing an all-or-nothing transition. On Tue, Jul 12, 2011 at 7:32 PM, Joel Maslak <jmaslak@antelope.net> wrote:
Public IPs.
At some point you will have to manage something outside your current world or your organization will need to merge/partner/outsource/contract/etc with someone else's network and they might not be keen to route to your ULA space (and might not be more trustworthy than the internet at large anyhow). Think about things like VPN endpoints, video devices, telephones, etc, that may end up on a public network, maybe behind a device you manage. You may just manage routers today, but who knows about tomorrow. Put behind a firewall and use good ingress filtering throughout your network, separating trust zones with distinct subnets.
If you are worried about forgetting to enable a firewall, put in a network management system to verify connectivity stays blocked combined with a monitored IDS.
-- ^[:wq^M
We our designing a new hosted exchange environment as well as Multi-Tenant Desktop as a Service environment and we are going to use IPv6 public address. Cheers Ryan -----Original Message----- From: James Harr [mailto:james.harr@gmail.com] Sent: Wednesday, July 13, 2011 11:22 AM To: Joel Maslak Cc: nanog@nanog.org Subject: Re: best practices for management nets in IPv6 I couldn't agree more. If you set up private address space, it's going to come back and make more work for you later. Set up public IPv6 addresses. If you need stateful connection filtering, put in a stateful firewall. If you really really need address obfuscation, you can still do NAT, but NAT from public addresses to public a public address or pool of public addresses. If you ever need to turn off NAT, it's a lot easier than renumbering hundreds of machines and you always have the option of disabling it per-host instead of doing an all-or-nothing transition. On Tue, Jul 12, 2011 at 7:32 PM, Joel Maslak <jmaslak@antelope.net> wrote:
Public IPs.
At some point you will have to manage something outside your current world or your organization will need to merge/partner/outsource/contract/etc with someone else's network and they might not be keen to route to your ULA space (and might not be more trustworthy than the internet at large anyhow). Think about things like VPN endpoints, video devices, telephones, etc, that may end up on a public network, maybe behind a device you manage. You may just manage routers today, but who knows about tomorrow. Put behind a firewall and use good ingress filtering throughout your network, separating trust zones with distinct subnets.
If you are worried about forgetting to enable a firewall, put in a network management system to verify connectivity stays blocked combined with a monitored IDS.
-- ^[:wq^M
On Wed, Jul 13, 2011 at 4:22 PM, James Harr <james.harr@gmail.com> wrote:
If you really really need address obfuscation, you can still do NAT, but NAT from public addresses to public a public address or pool of
Well, You can also use IPv6 privacy extensions (by default on Windows 7), see rfc4941. For Linux, you can also enable it, which is not a default. Steph
You can also use IPv6 privacy extensions (by default on Windows 7), see rfc4941. For Linux, you can also enable it, which is not a default.
In the context of "addresses I'm using to manage kit", having devices randomly renumber themselves at regular intervals does *not* sound like it's going to make my life easy :( Regards, Tim.
On Mon, Jul 18, 2011 at 13:12, Tim Franklin <tim@pelican.org> wrote:
You can also use IPv6 privacy extensions (by default on Windows 7), see rfc4941. For Linux, you can also enable it, which is not a default.
In the context of "addresses I'm using to manage kit", having devices randomly renumber themselves at regular intervals does *not* sound like it's going to make my life easy :(
Remember, every interface has multiple addresses in IPv6. While I don't know if Linux behaves similarly, for Windows, the privacy address is primarily used for outbound connections. The MAC-derived IPv6 address is also still active, and is the one registered automatically in DNS, so you would still reach your kit via stable addresses (well, as stable as the physical network interface). Cheers, Dave Hart
On 07/18/2011 06:12, Tim Franklin wrote:
You can also use IPv6 privacy extensions (by default on Windows 7), see rfc4941. For Linux, you can also enable it, which is not a default.
In the context of "addresses I'm using to manage kit", having devices randomly renumber themselves at regular intervals does *not* sound like it's going to make my life easy :(
In IPv4 most people use static assignments for servers, and often use dynamic assignments for client hosts (e.g., DHCP). The IPv6 world is not different. If you don't want privacy addresses for your servers (and it's unlikely that you would) you just make sure that they are not enabled. -- Nothin' ever doesn't change, but nothin' changes much. -- OK Go Breadth of IT experience, and depth of knowledge in the DNS. Yours for the right price. :) http://SupersetSolutions.com/
We keep running into problem with our IPv6 roll out. I just confirmed today that Exchange does not fully support IPv6 Cheers Ryan -----Original Message----- From: Doug Barton [mailto:dougb@dougbarton.us] Sent: Monday, July 18, 2011 4:59 PM To: Tim Franklin Cc: nanog@nanog.org Subject: Re: best practices for management nets in IPv6 On 07/18/2011 06:12, Tim Franklin wrote:
You can also use IPv6 privacy extensions (by default on Windows 7), see rfc4941. For Linux, you can also enable it, which is not a default.
In the context of "addresses I'm using to manage kit", having devices randomly renumber themselves at regular intervals does *not* sound like it's going to make my life easy :(
In IPv4 most people use static assignments for servers, and often use dynamic assignments for client hosts (e.g., DHCP). The IPv6 world is not different. If you don't want privacy addresses for your servers (and it's unlikely that you would) you just make sure that they are not enabled. -- Nothin' ever doesn't change, but nothin' changes much. -- OK Go Breadth of IT experience, and depth of knowledge in the DNS. Yours for the right price. :) http://SupersetSolutions.com/ _____ NANOG mailing list NANOG@nanog.org https://mailman.nanog.org/mailman/listinfo/nanog
Which version of Exchange are you talking about, and can you share what about it doesn't support IPv6? Frank -----Original Message----- From: Ryan Finnesey [mailto:ryan.finnesey@HarrierInvestments.com] Sent: Monday, July 18, 2011 10:56 PM To: Doug Barton; Tim Franklin Cc: nanog@nanog.org Subject: RE: best practices for management nets in IPv6 We keep running into problem with our IPv6 roll out. I just confirmed today that Exchange does not fully support IPv6 Cheers Ryan -----Original Message----- From: Doug Barton [mailto:dougb@dougbarton.us] Sent: Monday, July 18, 2011 4:59 PM To: Tim Franklin Cc: nanog@nanog.org Subject: Re: best practices for management nets in IPv6 On 07/18/2011 06:12, Tim Franklin wrote:
You can also use IPv6 privacy extensions (by default on Windows 7), see rfc4941. For Linux, you can also enable it, which is not a default.
In the context of "addresses I'm using to manage kit", having devices randomly renumber themselves at regular intervals does *not* sound like it's going to make my life easy :(
In IPv4 most people use static assignments for servers, and often use dynamic assignments for client hosts (e.g., DHCP). The IPv6 world is not different. If you don't want privacy addresses for your servers (and it's unlikely that you would) you just make sure that they are not enabled. -- Nothin' ever doesn't change, but nothin' changes much. -- OK Go Breadth of IT experience, and depth of knowledge in the DNS. Yours for the right price. :) http://SupersetSolutions.com/ _____ NANOG mailing list NANOG@nanog.org https://mailman.nanog.org/mailman/listinfo/nanog _____ NANOG mailing list NANOG@nanog.org https://mailman.nanog.org/mailman/listinfo/nanog
Yes sorry Exchange 2010 - OCS, Lync, Exchange UM - these require IPv4 Cheers Ryan -----Original Message----- From: Frank Bulk [mailto:frnkblk@iname.com] Sent: Tuesday, July 19, 2011 12:34 AM To: Ryan Finnesey Cc: nanog@nanog.org Subject: RE: best practices for management nets in IPv6 Which version of Exchange are you talking about, and can you share what about it doesn't support IPv6? Frank -----Original Message----- From: Ryan Finnesey [mailto:ryan.finnesey@HarrierInvestments.com] Sent: Monday, July 18, 2011 10:56 PM To: Doug Barton; Tim Franklin Cc: nanog@nanog.org Subject: RE: best practices for management nets in IPv6 We keep running into problem with our IPv6 roll out. I just confirmed today that Exchange does not fully support IPv6 Cheers Ryan -----Original Message----- From: Doug Barton [mailto:dougb@dougbarton.us] Sent: Monday, July 18, 2011 4:59 PM To: Tim Franklin Cc: nanog@nanog.org Subject: Re: best practices for management nets in IPv6 On 07/18/2011 06:12, Tim Franklin wrote:
You can also use IPv6 privacy extensions (by default on Windows 7), see rfc4941. For Linux, you can also enable it, which is not a default.
In the context of "addresses I'm using to manage kit", having devices randomly renumber themselves at regular intervals does *not* sound like it's going to make my life easy :(
In IPv4 most people use static assignments for servers, and often use dynamic assignments for client hosts (e.g., DHCP). The IPv6 world is not different. If you don't want privacy addresses for your servers (and it's unlikely that you would) you just make sure that they are not enabled. -- Nothin' ever doesn't change, but nothin' changes much. -- OK Go Breadth of IT experience, and depth of knowledge in the DNS. Yours for the right price. :) http://SupersetSolutions.com/ _____ NANOG mailing list NANOG@nanog.org https://mailman.nanog.org/mailman/listinfo/nanog _____ NANOG mailing list NANOG@nanog.org https://mailman.nanog.org/mailman/listinfo/nanog
ryan> We keep running into problem with our IPv6 roll out. I just ryan> confirmed today that Exchange does not fully support IPv6 [...] ryan> Yes sorry Exchange 2010 - OCS, Lync, Exchange UM - these require ryan> IPv4 It's a hack (but all ipv6 transition stuff is...) but have you tried using ipv6-literal.net for the apps that don't work with ipv6 yet? # Support for ipv6-literal.net Names Windows Vista and Windows Server 2008 support the use of IPv6Address.ivp6-literal.net names. An ipv6-literal.net name can be used in services or applications that do not recognize the syntax of normal IPv6 addresses. To specify an IPv6 address within the ipv6-literal.net name, convert the colons (:) in the address to dashes (-). For example, for the IPv6 address 2001:db8:28:3:f98a:5b31:67b7:67ef, the corresponding ipv6-literal.net name is 2001-db8-28-3-f98a-5b31-67b7-67ef.ipv6-literal.net. To specify a zone ID (also known as a scope ID), replace the "%" used to separate the IPv6 address from the zone ID with an "s". For example to specify the destination fe80::218:8bff:fe17:a226%4, the name is fe80--218-8bff-fe17-a226s4.ipv6-literal.net. You can use an ipv6-literal.net name in the computer name part of a Universal Naming Convention (UNC) path. For example, to specify the Docs share of the computer with the IPv6 address of 2001:db8:28:3:f98a:5b31:67b7:67ef, use the UNC path \\2001-db8-28-3-f98a-5b31-67b7-67ef.ipv6-literal.net\docs.
On Jul 12, 2011, at 5:31 PM, Tom Ammon wrote:
On your management nets (network device management nets) , what's the best approach for addressing them? Do you use ULA? Or do you use global addresses and just depend on router ACLs to protect things? How close are we to having a central registry for unique local addresses, and will that really happen?
We allocate a /64 per subnet as that's what most of the management hosts expect. We also build the CoPP/ACLs in a comparable way for the ipv6 afi as one does for the ipv4 afi to protect the device from unauthorized access. having access to a trusted net will get you a response to your SYN, you still need the ability to auth past that point to various devices/systems. Getting on that trusted net and protecting it is clearly something important. Certainly one can go crazy with trying to secure ones networks by wrapping it in 802.1x with various backing systems. I do recommend making sure your security practices are sensible and not forgotten. Nothing like having a machine on the 'trusted' lan becoming compromised. Never know what's going to happen :) - Jared
participants (13)
-
Cameron Byrne -
Dave Hart -
Doug Barton -
Frank Bulk -
FRLinux -
James Harr -
Jared Mauch -
Joel Maslak -
Paul Ebersman -
Rubens Kuhl -
Ryan Finnesey -
Tim Franklin -
Tom Ammon