I imagine some day in the near future there will be a switch to ipv6. I cannot imagine ever remembering the ip address then...crazy.
My question, since i have never done ip6 stuff, is what does that mean on my webservers?
Would I just need to replace my ip4 with ip6 in my eths, bonds, bridges, and configuration files...and copy out my iptables to ip6tables, and change the dns servers?
all that does not sound to harsh.
anything especially daunting to make that switch (save from someone having to do that on 100 computers really fast!!)
-bob
On Fri, Mar 30, 2012 at 02:23:55PM -0400, Bob Hoffman wrote:
My question, since i have never done ip6 stuff, is what does that mean on my webservers?
For modern software, not too much, really!
Would I just need to replace my ip4 with ip6 in my eths, bonds, bridges, and configuration files...and copy out my iptables to ip6tables, and change the dns servers?
You can test it today; if your ISP doesn't provide native IPv6 then you can get a tunnel (eg from tunnelbroker.net) for free. Then you can run IPv4 and IPv6 at the same time and see how easy it is. It's really easy :-)
I have a linode and a Panix v-colo with native IPv6, and my home network with an IPv6 HE tunnel. This email _should_ go via IPv6 from home to linode, and then probably via IPv4 to the list server... unless that is also IPv6 enabled! Most of the time (eg surfing the net) I don't even know if my traffic is using IPv4 or IPv6.
On 03/30/2012 11:23 AM, Bob Hoffman wrote:
I imagine some day in the near future there will be a switch to ipv6. I cannot imagine ever remembering the ip address then...crazy.
My question, since i have never done ip6 stuff, is what does that mean on my webservers?
Would I just need to replace my ip4 with ip6 in my eths, bonds, bridges, and configuration files...and copy out my iptables to ip6tables, and change the dns servers?
all that does not sound to harsh.
anything especially daunting to make that switch (save from someone having to do that on 100 computers really fast!!)
-bob
CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos
We've been running out of IPV4 address and needing to convert someday soon for the last 10 years..., but yet the vast majority of broadband providers and even most ISP's don't support it yet.
Nataraj
We've been running out of IPV4 address and needing to convert someday soon for the last 10 years..., but yet the vast majority of broadband providers and even most ISP's don't support it yet.
You've got another couple of months. I believe most U.S. network providers have agreed to a 'flag day' sometime in June 2012.
Internal networks / backbones at Comcast and Verizon have been IPv6 for some time now. At least that is what a credible little bird told me.
On 3/31/2012 6:44 AM, Adam Tauno Williams wrote:
We've been running out of IPV4 address and needing to convert someday soon for the last 10 years..., but yet the vast majority of broadband providers and even most ISP's don't support it yet.
You've got another couple of months. I believe most U.S. network providers have agreed to a 'flag day' sometime in June 2012.
Internal networks / backbones at Comcast and Verizon have been IPv6 for some time now. At least that is what a credible little bird told me.
CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos
yea they did one in june of last year. There has to be a time though for us web admins when are ipaddresses for our websites or phased into ip6... hopefully soon.
On Saturday, March 31, 2012 06:44:38 AM Adam Tauno Williams wrote:
We've been running out of IPV4 address and needing to convert someday soon for the last 10 years..., but yet the vast majority of broadband providers and even most ISP's don't support it yet.
You've got another couple of months. I believe most U.S. network providers have agreed to a 'flag day' sometime in June 2012.
Internal networks / backbones at Comcast and Verizon have been IPv6 for some time now. At least that is what a credible little bird told me.
Well, since 100.64.0.0/10 got allocated for draft-weil, CGN and NAT444 will be a reality, and IPv4 gets a new lease on its fugue state. (see: http://www.ietf.org/mail-archive/web/ietf-announce/current/msg09959.html )
To Bob's question, IPv6 and IPv4 will coexist as dual-stack until nothing of importance is left on IPv4, and then it will be turned off by network ops, one AS at a time (iterate across ~30,000 AS's). It will likely take decades for IPv4 to go away; but I reserve the right to be wrong.
Am 30.03.2012 20:23, schrieb Bob Hoffman:
I imagine some day in the near future there will be a switch to ipv6.
Wrong. There will be no switch. IPv6 is just being added while IPv4 continues to function. Both will coexist for a long time yet.
I cannot imagine ever remembering the ip address then...crazy.
Don't worry. You will. Well, not the autoconfigured ones for sure, but those you choose yourself, they'll cling to your brain after some time just as 192.168 does today.
My question, since i have never done ip6 stuff, is what does that mean on my webservers?
Not much, really. You just give them IPv6 addresses and they'll work with them just like they do with the IPv4 addresses today.
Would I just need to replace my ip4 with ip6 in my eths, bonds, bridges, and configuration files...and copy out my iptables to ip6tables, and change the dns servers?
That would be a really bad transition plan. Don't switch - migrate. Don't replace IPv4 - add IPv6 alongside. IPv6 is designed to coexist with IPv4.
anything especially daunting to make that switch (save from someone having to do that on 100 computers really fast!!)
DNS reverse zones take some getting used to. Apart from that, it's really straightforward and doesn't differ that much from setting up an IPv4 address range:
1. Get a suitable IPv6 address range from your provider. The regular size for companies is /48, but a /56 is fine too. (If your provider is unable to give you one, get a better provider. If you have a really good reason for sticking with a provider that is so behind the times that it still cannot provide IPv6, you might use a tunnel broker, but that's a bit more complicated.) Also create an IPv6 reverse DNS zone for your address range on your DNS server and get it delegated from your provider so that you can manage reverse resolution yourself. (Otherwise you'll have to ask your provider to create every PTR RR you need for you.)
2. Configure your firewall to route and announce a /64 subnet of the IPv6 address range you got to each of your LANs.
3. Give your machines IPv6 addresses in addition to their IPv4 ones. (Many of them will have gotten one automatically already via autoconfiguration, but those aren't pretty or easy to remember, so you may want to assign another one instead or in addition.) Leave the IPv4 addresses in place so that existing connections will continue to work.
4. Add those addresses to the machines' DNS entries as AAAA records. Again, don't remove the IPv4 addresses (A records), they're still needed for communication partners who aren't IPv6 capable yet. Also add corresponding PTR records to the IPv6 reverse zone.
That's it. At that point your machines will be reachable via IPv6 in addition to working with IPv4 as before.
(Well, of course there'll be a lot of tedious details like logfile analyzers not understanding the IPv6 address format, access control lists needing additional entries for the new addresses, users phoning the help desk because addresses look strangely different, etc. But nothing fundamentally new or incomprehensible.)
HTH Tilman
On Fri, 2012-03-30 at 14:23 -0400, Bob Hoffman wrote:
I imagine some day in the near future there will be a switch to ipv6.
A long way off; for a long time things will be dual-stack. It isn't either IPv4 or IPv6, they coexist just fine.
I cannot imagine ever remembering the ip address then...crazy.
That's why there is DNS! :)
My question, since i have never done ip6 stuff, is what does that mean on my webservers?
Nothing more than IPv4 means for you web servers. It is just-another-address, configured in the same way as if you had multiple IPv4 addresses.
Would I just need to replace my ip4 with ip6 in my eths, bonds, bridges, and configuration files...and copy out my iptables to ip6tables, and change the dns servers?
Nope, you don't replace, you add.
all that does not sound to harsh.
It isn't at scary as some people make it out to be. And IPv6 gets rid of numerous hideous hacks that have been built into / onto creaky old IPv4.
Die NAT Die!
anything especially daunting to make that switch (save from someone having to do that on 100 computers really fast!!)
And recent computer or distributions is sitting their quietly waiting for it's IPv6 address to arrive - probably automatically, via auto discovery. Clients are trivial.
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
Hi Adam,
And recent computer or distributions is sitting their quietly waiting for it's IPv6 address to arrive - probably automatically, via auto discovery. Clients are trivial.
... and that is EXACTLY the biggest problem with IPv6.
'Introducing' IPv6 happens automatically in most cases, and inadvertently as well. The moment ISPs will start supporting IPv6 for their customers will be a security nightmare, because IPv6 firewalls will not be configured on most networks, and the pseudo-security of NAT will no longer be in effect.
In fact, a very large number of networks (especially those currently relying on NAT 'security') will be completely exposed to the Internet without any protection, and the bad thing is that you just don't have to do anything to make it 'work'. From one day to the other, IPv6 connectivity will be there and most people won't even notice until it's too late.
One may only hope that home router manufacturers will deliver standard configurations with all incoming IPv6 traffic (except answers to outgoing packets, obviously) blocked by default, but I'm not very optimistic :-(
So, before you do anything else, set up proper incoming and outgoing IPv6 port filtering rules on your perimeter routers. It will save you a hell of a headache.
Peter.
On Sat, Mar 31, 2012 at 8:06 AM, Peter Eckel lists@eckel-edv.de wrote:
And recent computer or distributions is sitting their quietly waiting for it's IPv6 address to arrive - probably automatically, via auto discovery. Clients are trivial.
... and that is EXACTLY the biggest problem with IPv6.
'Introducing' IPv6 happens automatically in most cases, and inadvertently as well. The moment ISPs will start supporting IPv6 for their customers will be a security nightmare, because IPv6 firewalls will not be configured on most networks, and the pseudo-security of NAT will no longer be in effect.
In fact, a very large number of networks (especially those currently relying on NAT 'security') will be completely exposed to the Internet without any protection, and the bad thing is that you just don't have to do anything to make it 'work'. From one day to the other, IPv6 connectivity will be there and most people won't even notice until it's too late.
One may only hope that home router manufacturers will deliver standard configurations with all incoming IPv6 traffic (except answers to outgoing packets, obviously) blocked by default, but I'm not very optimistic :-(
So, before you do anything else, set up proper incoming and outgoing IPv6 port filtering rules on your perimeter routers. It will save you a hell of a headache.
If the addresses are auto-discovered, how are you supposed to be able to configure filtering rules for what you want to let through?
On Sat, Mar 31, 2012 at 11:37 AM, Les Mikesell lesmikesell@gmail.comwrote:
On Sat, Mar 31, 2012 at 8:06 AM, Peter Eckel lists@eckel-edv.de wrote:
And recent computer or distributions is sitting their quietly waiting for it's IPv6 address to arrive - probably automatically, via auto discovery. Clients are trivial.
... and that is EXACTLY the biggest problem with IPv6.
'Introducing' IPv6 happens automatically in most cases, and
inadvertently as well. The moment ISPs will start supporting IPv6 for their customers will be a security nightmare, because IPv6 firewalls will not be configured on most networks, and the pseudo-security of NAT will no longer be in effect.
In fact, a very large number of networks (especially those currently
relying on NAT 'security') will be completely exposed to the Internet without any protection, and the bad thing is that you just don't have to do anything to make it 'work'. From one day to the other, IPv6 connectivity will be there and most people won't even notice until it's too late.
One may only hope that home router manufacturers will deliver standard
configurations with all incoming IPv6 traffic (except answers to outgoing packets, obviously) blocked by default, but I'm not very optimistic :-(
So, before you do anything else, set up proper incoming and outgoing
IPv6 port filtering rules on your perimeter routers. It will save you a hell of a headache.
If the addresses are auto-discovered, how are you supposed to be able to configure filtering rules for what you want to let through?
They address is generated from the prefix advertised by the router and the mac address. Later versions of Windows generate a temporarily random address to increase privacy, which can be disabled. Of course you can still assign static IPv6 addresses. I have done this for servers so I can easily identify them as I use the last IPv4 octet in the IPv6 address.
Ryan
Am 31.03.2012 17:37, schrieb Les Mikesell:
On Sat, Mar 31, 2012 at 8:06 AM, Peter Eckel lists@eckel-edv.de wrote:
So, before you do anything else, set up proper incoming and outgoing IPv6 port filtering rules on your perimeter routers. It will save you a hell of a headache.
If the addresses are auto-discovered, how are you supposed to be able to configure filtering rules for what you want to let through?
Same as today: machines which need individual filtering rules need static addresses. That includes all machines which are to accept connections traversing the firewall, but also machines which are permitted to access services that are not generally allowed.
One difference though: machines will typically have more than one IPv6 address, so you may have to somehow make sure that you don't use a different address than the one which is mentioned in the filtering rule. That's no problem for incoming connections. You just have to allow the same addresses in the firewall as you published in DNS. But for outgoing connections (for example, from mail servers) you may have to explicitly specify the source address.
On Sat, 2012-03-31 at 19:52 +0200, Tilman Schmidt wrote:
Am 31.03.2012 17:37, schrieb Les Mikesell:
On Sat, Mar 31, 2012 at 8:06 AM, Peter Eckel lists@eckel-edv.de wrote:
So, before you do anything else, set up proper incoming and outgoing IPv6 port filtering rules on your perimeter routers. It will save you a hell of a headache
If the addresses are auto-discovered, how are you supposed to be able to configure filtering rules for what you want to let through
Same as today: machines which need individual filtering rules need static addresses.
Or you assign the rule to the interface, rather than the address. Nothing new, that is how firewalls work on DHCP clients today.
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
Hi Adam,
Or you assign the rule to the interface, rather than the address. Nothing new, that is how firewalls work on DHCP clients today.
that will be pretty difficult on the perimeter router ...
Best regards,
Peter.
Hi Lee,
If the addresses are auto-discovered, how are you supposed to be able to configure filtering rules for what you want to let through?
very simply.
1. Each interface on an IPv6 enabled machine has several addresses. One of them is the autoconfigured address, one is the (a) Privacy Extension address, and then you can still configure addresses manually. Obviously the latter method is the right choice for servers.
2. Except for the Privacy Extension address(es), auto-configured addresses are static (although virtually unmemorisable) as long as the prefix and the host's MAC address are. So there is a static address that you can put into your DNS and configure on your firewall.
Best regards,
Peter.
On Sat, Mar 31, 2012 at 3:24 PM, Peter Eckel lists@eckel-edv.de wrote:
If the addresses are auto-discovered, how are you supposed to be able to configure filtering rules for what you want to let through?
very simply.
Each interface on an IPv6 enabled machine has several addresses. One of them is the autoconfigured address, one is the (a) Privacy Extension address, and then you can still configure addresses manually. Obviously the latter method is the right choice for servers.
Except for the Privacy Extension address(es), auto-configured addresses are static (although virtually unmemorisable) as long as the prefix and the host's MAC address are. So there is a static address that you can put into your DNS and configure on your firewall.
How do applications choose the correct outbound address in that scenario? That has always been a problem when using multiple ipv4 addresses on the same interface in combination with firewalling, etc. where the source address matters.
Hi Lee,
How do applications choose the correct outbound address in that scenario? That has always been a problem when using multiple ipv4 addresses on the same interface in combination with firewalling, etc. where the source address matters.
that problem hasn't changed too much from IPv4 to IPv6. Basically, it's up to the application which IP address it binds to, while the OS should provide sensible defaults. In most cases with Privacy Extension enabled (mostly on client systems), the system should use a PE address, ideally a different one for each connection. Outgoing addresses for servers must be configured, e.g. in Postfix it's in the 'smtp_bind_address6' configuration variable, in BIND 'query-source-v6'.
The functionality is there (as it was with v4), applications just have to use it. It is, however, a more pressing issue as with v6 any interface is likely to have several addresses. The generic case for an interface's addresses is:
- link-local address, starting with 'fe80::' and ending with a node part that has been derived from the MAC of the interface for communication with the local network
- autoconfigured address, starting with your prefix and ending with the same node part as the link-local address (i.e., derived from the MAC)
- Privacy Extension address, starting with your prefix and ending with a random node part (it's likely that there are several of them, as a rollover mechanism exists for address rotation)
- Static addresses, starting with your prefix and ending with a user-chosen node part for specific services (there might me several of them as well)
All of them may co-exist. The normal logic for outgoing address selection is to use a PE address if there is one and the autoconfigured address (if present) otherwise (OK, that's as is *should* be, and most of the time it is). Everything else is up to you and how the software you use binds to outgoing addresses and lets you specify it.
Best regards,
Peter.
On Sat, 2012-03-31 at 16:38 -0500, Les Mikesell wrote:
On Sat, Mar 31, 2012 at 3:24 PM, Peter Eckel lists@eckel-edv.de wrote:
- Each interface on an IPv6 enabled machine has several addresses.
- Except for the Privacy Extension address(es), auto-configured a
How do applications choose the correct outbound address in that scenario? That has always been a problem when using multiple ipv4 addresses on the same interface in combination with firewalling, etc. where the source address matters.
Typically the routing table does a lot of work. Much like 127.0.0.0/8 the mask of a link-local will make it unprefered by 'public' traffic. There is also a syntax for specifying the outbound interface for traffic.
See http://wmmi.net/documents/BasicIPv6.pdf slide 24 - 26.
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
Hi Adam,
Typically the routing table does a lot of work. Much like 127.0.0.0/8 the mask of a link-local will make it unprefered by 'public' traffic. There is also a syntax for specifying the outbound interface for traffic.
Routing tables won't do much for you when you have several different IP addresses (stateless autocnfigured, privacy extension and static) within the same network on the same physical interface - they'll all use the same route. The longest match algorithm would more or less lead to a random choice of source addresses.
If you want a specific source address to be used, you have to specify it ... no big deal, though. bind() hasn't changed that much.
On Mon, Apr 2, 2012 at 5:28 AM, Peter Eckel lists@eckel-edv.de wrote:
Routing tables won't do much for you when you have several different IP addresses (stateless autocnfigured, privacy extension and static) within the same network on the same physical interface - they'll all use the same route. The longest match algorithm would more or less lead to a random choice of source addresses.
If you want a specific source address to be used, you have to specify it ... no big deal, though. bind() hasn't changed that much.
So what does that mean for a client application (http/ftp,etc.) where you might have local firewalls permitting things for internal-subnet source ranges but you also have external targets that only accept pre-configured static sources? With NAT you'd use the public side of the NAT for the remote configuration. What's the equivalent when the application has to do it itself?
Hi Lee,
So what does that mean for a client application (http/ftp,etc.) where you might have local firewalls permitting things for internal-subnet source ranges but you also have external targets that only accept pre-configured static sources?
Are you referring to the situation where you have several clients on the internal network that use NAT to appear as one single IPv4 host to an external server, which allows access based on that global outside NAT address?
The situation is a bit different without NAT. Instead of filtering on a single IPv4 address the external server would filter on a /64 IPv6 network. Security-wise there is no difference as you'll never get smaller allocations than /64 per site anyway, so what with respect to filtering was was a single IPv4 address with IPv4/NAT is a /64 subnet with IPv6: A unique identifier of the network connecting to the external server. Both with IPv4/NAT and IPv6 the server only knows which network you are coming from, not which specific host is trying to connect.
When there really is a requirement that the external server allows only a single address to access it and that can't be changed, you could resort to using a proxy.
If you're interested, RFC4864 expands on some of the aspects of IPv4/NAT vs. IPv6: http://tools.ietf.org/html/rfc4864
Best regards,
Peter.
On Mon, Apr 2, 2012 at 9:39 AM, Peter Eckel lists@eckel-edv.de wrote:
So what does that mean for a client application (http/ftp,etc.) where you might have local firewalls permitting things for internal-subnet source ranges but you also have external targets that only accept pre-configured static sources?
Are you referring to the situation where you have several clients on the internal network that use NAT to appear as one single IPv4 host to an external server, which allows access based on that global outside NAT address?
Yes, we have relationships with outside services that require pre-registering the source addresses that will be used for access. In the NAT scenario, these become the public side of the gateways that might be used - a manageable number, even for a large cluster of internal hosts. And we have internal firewalling among subnets based on the private address ranges of the hosts. I'd assume this is a common, if not universal situation for organizations.
The situation is a bit different without NAT. Instead of filtering on a single IPv4 address the external server would filter on a /64 IPv6 network. Security-wise there is no difference as you'll never get smaller allocations than /64 per site anyway, so what with respect to filtering was was a single IPv4 address with IPv4/NAT is a /64 subnet with IPv6: A unique identifier of the network connecting to the external server. Both with IPv4/NAT and IPv6 the server only knows which network you are coming from, not which specific host is trying to connect.
When there really is a requirement that the external server allows only a single address to access it and that can't be changed, you could resort to using a proxy.
What is typical or reasonable for source address restrictions? That is, if there are 2 global organizations, and one wants to increase the security on access to a service by limiting to the source addresses that might come from the other, is there a sane way to specify it, and to make the application use those addresses at the right times if the interface has others?
Hi Les (sorry for calling you 'Lee' before),
What is typical or reasonable for source address restrictions? That is, if there are 2 global organizations, and one wants to increase the security on access to a service by limiting to the source addresses that might come from the other, is there a sane way to specify it, and to make the application use those addresses at the right times if the interface has others?
In general, all IPv6 addresses on a given interface will have the same network prefix, and that will (except in some ... exotic ... cases) be a /64. So setting up the address filter on the server side to the whole /64 will make most sense.
When the client has only one interface, that should be all there is to do. When it has more than one interface, as Adam previously noted, you'll use routing tables to make sure external traffic uses the /64 that is allowed on the external server, while internal traffic uses whatever is needed.
If you are required to use one single address to connect to the external server and have only one interface, configuring the software to bind to the permitted v6 address will do the trick. It will also use that one for internal traffic, but that won't matter as it's on the same /64 as the other addresses on that LAN.
I'm not sure how to handle the case where you have one interface with several v6 addresses for external traffic and one or more interfaces for internal traffic and have to use one specific address on the external interface because of single-address restrictions on the external server. I'd say, either don't do it (filter on /64 instead), or remove all addreesses but the one required from the external interface and let routing tables handle the rest.
Bests,
Peter.
On Mon, 2012-04-02 at 09:59 -0500, Les Mikesell wrote:
On Mon, Apr 2, 2012 at 9:39 AM, Peter Eckel lists@eckel-edv.de wrote:
When there really is a requirement that the external server allows
only a single address to access it and that can't be changed, you could resort to using a proxy. What is typical or reasonable for source address restrictions?
To dispose of them; they are hopelessly pointless. If you want to authenticate the source use PKI.
I know they exist and have personally had to deal with them. That doesn't imply they make any kind of sense.
That is, if there are 2 global organizations, and one wants to increase the security on access to a service by limiting to the source addresses that might come from the other, is there a sane way to specify it, and to make the application use those addresses at the right times if the interface has others?
If two organizations want to communicate, exclusively and privately, with each other they should establish a tunnel.
On Mon, Apr 2, 2012 at 7:33 PM, Adam Tauno Williams awilliam@whitemice.org wrote:
On Mon, 2012-04-02 at 09:59 -0500, Les Mikesell wrote:
On Mon, Apr 2, 2012 at 9:39 AM, Peter Eckel lists@eckel-edv.de wrote:
When there really is a requirement that the external server allows
only a single address to access it and that can't be changed, you could resort to using a proxy. What is typical or reasonable for source address restrictions?
To dispose of them; they are hopelessly pointless. If you want to authenticate the source use PKI.
I know they exist and have personally had to deal with them. That doesn't imply they make any kind of sense.
That is, if there are 2 global organizations, and one wants to increase the security on access to a service by limiting to the source addresses that might come from the other, is there a sane way to specify it, and to make the application use those addresses at the right times if the interface has others?
If two organizations want to communicate, exclusively and privately, with each other they should establish a tunnel.
This isn't a one-to-one relationship, it is an assortment of data/service subscriptions among an assortment of providers and consumers. There's normally password protection as well but many have a small list of permitted source addresses associated with the account to reduce the risk of password sharing and give some protection against DDOS attacks. It seems reasonable to expect the same with IPv6 if there is a way to do it.
On Mon, Apr 02, 2012 at 04:39:17PM +0200, Peter Eckel wrote:
network. Security-wise there is no difference as you'll never get smaller allocations than /64 per site anyway, so what with respect to filtering
*gigglefit*
One of my providers gave me a single(!) IPv6 address. Another one has subdivided a /64 into multiple /96's (one for each customer).
You might want to rethink the /64 concept!
Hi Stephen,
*gigglefit*
One of my providers gave me a single(!) IPv6 address.
Actually that's at least something the IETF has thought of ... if it is certain that one and only one device will be connected. I'm not actually sure what use case there is for such a connection, but at least it is a possibility mentioned in RFC 3177:
This document provides recommendations to the addressing registries (APNIC, ARIN and RIPE-NCC) on policies for assigning IPv6 address blocks to end sites. In particular, it recommends the assignment of /48 in the general case, /64 when it is known that one and only one subnet is needed and /128 when it is absolutely known that one and only one device is connecting.
Another one has subdivided a /64 into multiple /96's (one for each customer).
Yuck. That doesn't make sense at all.
SLAAC won't work, Privacy Extensions won't work ... you're stuck with static addresses that way, which kills a big part of the ease of management IPv6 could provide, if used properly.
What are they trying to do? Save IPv6 address space? :-)
OK, 3177 is just a recommendation, but when you look at the schemes after which SLAAC und PE addresses are generated, anything less than /64 (except, in rare circumstances, /128) is just bull****.
You might want to rethink the /64 concept!
I think you might want to rethink the choice of your provider.
Bests,
Peter.
On Mon, Apr 02, 2012 at 05:30:57PM +0200, Peter Eckel wrote:
Hi Stephen,
Another one has subdivided a /64 into multiple /96's (one for each customer).
Yuck. That doesn't make sense at all.
SLAAC won't work, Privacy Extensions won't work ... you're stuck with static addresses that way, which kills a big part of the ease of management IPv6 could provide, if used properly.
What are they trying to do? Save IPv6 address space? :-)
It's a server farm based on Xen instances; they assign a single static address from one /64 and then route a /96 from a second /64 to that address. Since it's a server farm they, presumably, don't care about privacy extensions nor SLAAC and expect static addresses.
On Monday, April 02, 2012 11:11:29 AM Stephen Harris wrote:
One of my providers gave me a single(!) IPv6 address. Another one has subdivided a /64 into multiple /96's (one for each customer).
You might want to rethink the /64 concept!
Subscribe to the NANOG list, and let that group know who the provider is..... hilarity is guaranteed to ensue.
You can get your own PI space in /48 chunks now; you just have to demonstrate a need to multihome.
On Mon, 2012-04-02 at 11:11 -0400, Stephen Harris wrote:
On Mon, Apr 02, 2012 at 04:39:17PM +0200, Peter Eckel wrote:
network. Security-wise there is no difference as you'll never get smaller allocations than /64 per site anyway, so what with respect to filterin
*gigglefit One of my providers gave me a single(!) IPv6 address. Another one has subdivided a /64 into multiple /96's (one for each customer). You might want to rethink the /64 concept!
Yea. The clean delegation of IPv6 address space is a beautiful idea. Now sit back and watch while providers decimate the entire concept.
Sigh.
On Sat, 2012-03-31 at 15:06 +0200, Peter Eckel wrote:
Hi Adam,
And recent computer or distributions is sitting their quietly waiting for it's IPv6 address to arrive - probably automatically, via auto discovery. Clients are trivial.
... and that is EXACTLY the biggest problem with IPv6.
You can explicitly turn in off on every type of client. Then wait till you want to do it.
'Introducing' IPv6 happens automatically in most cases, and inadvertently as well. The moment ISPs will start supporting IPv6 for their customers will be a security nightmare, because IPv6 firewalls will not be configured on most networks, and the pseudo-security of NAT will no longer be in effect.
False. The same firewall rules will apply as before [and NAT isn't psuedo-security - NAT IS *NOT* *NOT* *NOT* A SECURITY FEATURE; please, let's not have to go over that again].
Your DOCSIS IPv6 capable black-box will apply the same filters to IPv6 traffic that it does to IPv4 traffic. As will you Vista and Windows 7 workstations.
In fact, a very large number of networks (especially those currently relying on NAT 'security')
There is no such thing as "NAT security" for them to rely on. If that is their security model the administrator is incompetent and should be fired immediately.
will be completely exposed to the Internet without any protection,
False.
and the bad thing is that you just don't have to do anything to make it 'work'. From one day to the other, IPv6 connectivity will be there and most people won't even notice until it's too late.
Or they won't notice and have nothing more to worry about than they did before.
One may only hope that home router manufacturers will deliver standard configurations with all incoming IPv6 traffic (except answers to outgoing packets, obviously) blocked by default, but I'm not very optimistic :-(
Well, don't worry. Because that is exactly what happens. An IPv6 stateful firewall is just as effective as an IPv4 stateful firewall.
So, before you do anything else, set up proper incoming and outgoing IPv6 port filtering rules on your perimeter routers. It will save you a hell of a headache.
Most just consumer routers simply mirror the IPv4 and IPv6 filters. If you have a managed network with 'real' routers your administrators have probably already done that; if you are unsure - ask them.
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
Hi Adam,
You can explicitly turn in off on every type of client. Then wait till you want to do it.
agreed. The problem is that you can, and you actually *must* do it. Doing nothing leaves v6 on by default on most modern operating systems.
False. The same firewall rules will apply as before
Unfortunately, this is only theoretically true.
[and NAT isn't psuedo-security - NAT IS *NOT* *NOT* *NOT* A SECURITY FEATURE; please, let's not have to go over that again].
That's the meaning of 'pseudo', isn't it? :-)
Your DOCSIS IPv6 capable black-box will apply the same filters to IPv6 traffic that it does to IPv4 traffic. As will you Vista and Windows 7 workstations.
I'm not talking about host-based packet filtering. Turn on IPv6 on a Cisco box, for example, and none of your packet filters will affect IPv6 traffic. Lots of home/small business routers show the same behaviour, except that you don't even have to turn on IPv6 routing, it's on by default.
There is no such thing as "NAT security" for them to rely on. If that is their security model the administrator is incompetent and should be fired immediately.
Agreed.
be completely exposed to the Internet without any protection,
False.
No. See above.
and the bad thing is that you just don't have to do anything to make it 'work'. From one day to the other, IPv6 connectivity will be there and most people won't even notice until it's too late.
Or they won't notice and have nothing more to worry about than they did before.
Not if they either rely on NAT (which *many* home users do - and they are the security problem with respect to Botnets, not properly managed networks like yours and mine.
Well, don't worry. Because that is exactly what happens. An IPv6 stateful firewall is just as effective as an IPv4 stateful firewall.
Yes, as long as it's there.
Most just consumer routers simply mirror the IPv4 and IPv6 filters. If you have a managed network with 'real' routers your administrators have probably already done that; if you are unsure - ask them.
I don't have to, as my introduction of IPv6 was some years ago. Telling people to just sit and wait is the worst you can do - at least I woudldn't trust a 'black box' router as far as I can throw it to actually implement v6 filter rules, especially since many of them are fairly old and not on the latest firmware level.
Best regards,
Peter.
-
Adam Tauno Williams -
Bob Hoffman -
Lamar Owen -
Les Mikesell -
Nataraj -
Peter Eckel -
Ryan Wagoner -
Stephen Harris -
Tilman Schmidt