Re: best practices for management nets in IPv6
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. _ NANOG mailing list NANOG@nanog.org https://mailman.nanog.org/mailman/listinfo/nanog
Re: best practices for management nets in IPv6
On 2011-07-23 17:44 , Paul Ebersman wrote: 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? That only helps you in situations where entering an IPv6 is unsupported because the parser chokes on the ':' or does not support scope identifiers. The app itself still needs to resolve that literal using getaddrinfo() into a valid IPv6 address (and scope-id) for it to make any sense of it. For apps that don't support IPv6 the only way you are (likely) getting them to to talk to IPv6 capable services is to proxy them. Good old SOCKS is a great one there and otherwise one of the various TCP forwarders (on windows one can use: netsh interface portproxy add v4tov6 listenport=80 connectaddress=theipv6nox connectport=80) Greets, Jeroen _ NANOG mailing list NANOG@nanog.org https://mailman.nanog.org/mailman/listinfo/nanog
Re: best practices for management nets in IPv6
On Wed, Jul 13, 2011 at 4:22 PM, James Harr james.h...@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 _ NANOG mailing list NANOG@nanog.org https://mailman.nanog.org/mailman/listinfo/nanog
Re: best practices for management nets in IPv6
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. _ NANOG mailing list NANOG@nanog.org https://mailman.nanog.org/mailman/listinfo/nanog
Re: best practices for management nets in IPv6
On Mon, Jul 18, 2011 at 13:12, Tim Franklin t...@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 _ NANOG mailing list NANOG@nanog.org https://mailman.nanog.org/mailman/listinfo/nanog
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
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:do...@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
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.finne...@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:do...@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 _ NANOG mailing list NANOG@nanog.org https://mailman.nanog.org/mailman/listinfo/nanog
RE: best practices for management nets in IPv6
Yes sorry Exchange 2010 - OCS, Lync, Exchange UM - these require IPv4 Cheers Ryan -Original Message- From: Frank Bulk [mailto:frnk...@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.finne...@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:do...@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 _ NANOG mailing list NANOG@nanog.org https://mailman.nanog.org/mailman/listinfo/nanog
RE: best practices for management nets in IPv6
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.h...@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 jmas...@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 _ NANOG mailing list NANOG@nanog.org https://mailman.nanog.org/mailman/listinfo/nanog
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 jmas...@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
Re: best practices for management nets in IPv6
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
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.am...@utah.edu Center for High Performance Computing University of Utah http://www.chpc.utah.edu -
Re: best practices for management nets in IPv6
On Tue, Jul 12, 2011 at 6:31 PM, Tom Ammon tom.am...@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
Re: best practices for management nets in IPv6
On Jul 12, 2011 2:33 PM, Tom Ammon tom.am...@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.am...@utah.edu Center for High Performance Computing University of Utah http://www.chpc.utah.edu -
Re: best practices for management nets in IPv6
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.
