I'd call XPSP2 an upgrade, not just a bugfix - IE includes popup blocking and security features, the firewall is improved and enabled by default, users are prompted to enable automatic updates, and the security center reminds you about needing antivirus software. These are significant features for most users.
But um, that's basically two new things (IE popup blocking, and the Security Center which does the other things I mentioned - XPSP1 already had a firewall and automatic updates, this just makes them more obvious). So yeah, your point is still valid.
I do have issues with IPv6, but the size of the address isn't one of them.
I have absolutely no problem with computers using 128-bit addresses to route packets; my only concern with the size of the address is that it's significantly harder for humans (not computers) to deal with. 64-bit addresses in hexadecimal would be only slightly longer than IPv4 addresses.
I do see the point about not fragmenting the address space, though. I like the hierarchical idea; having to keep track of 16 million individual class C blocks with IPv4 is insane.
With IPv4 we've got 4 billion IPs and we're running out; this would give us 18 quintillion IPs. IPv6 gives us 340 undecillion addresses, and I just don't see that being useful.
Wow, sorry about that, I'm tired - I multiplied 4 billion by 4, when I meant to multiply 4 billion by 4 billion. I thought something about that didn't look right! What I meant was (rounding down):
I thnk the point was this: NAT and firewalls are different things. Nat does all it says it does and nothing more. If you want to filter traffic you need to add those features on top of NAT.
but if you use NAT, you don't have to filter traffic, because there's nothing to filter. Internal IPs aren't routable on the Internet, so nobody can send anything to your internal IPs anyway - they can only send packets to the external IP of the NAT router, which isn't going to forward them (because if they're not replies to something, it doesn't know where to forward them to).
This is a misunderstanding, and has been debated elsewhere: NAT offers no security by itself, it's because normally NATs have a firewall effect at the same time that they create the illusion (and in some cases reality) of security.
Uhhhhh...
The point of NAT is that IP addresses on the internal side are non-routable, i.e. there's no way to get to them from the Internet at all. The only way in is to contact the external IP of the NAT router, and convince it to let you inside, which it's not going to do unless you're replying to something. How does this not offer security?
If there's really nowhere to go, then sure, go ahead and slow down gradually... but do so with your turn signal on, so everyone around you knows you WANT to switch lanes so you can get out of the guy's way. Some people don't understand that turn signals are supposed to signal your intention or desire, not just your current action, so they wait to turn on the turn signal until an opening appears; this is dumb. Turn your turn signal on, and polite drivers will make room for you.
It also signals to the tailgater behind you that you know he wants to pass you and you'll get out of his way ASAP, so he no longer has to tailgate to let you know he wants to pass. If he's got a brain, he'll back off. Of course he probably doesn't.
Your point about speeds being low enough to make it a minor accident is valid, I suppose, but I'd much rather try to avoid it altogether.
I'm not too interested in whether it's overkill or not, but it sure as hell gets trickier trying to remember what IP you have. I can't even imagine the pain of working in ISP customer support and asking, over the phone, for someone to recite their IP address.
That's what I was thinking. 64-bit address would be twice as easy for us humans to deal with - but not twice as hard as IPv4, because we'd be using 16-digit hex addresses instead of up-to-12-digit decimal addresses. With IPv4 we've got 4 billion IPs and we're running out; this would give us 18 billion IPs. IPv6 gives us 340 billion addresses, and I just don't see that being useful.
New computers go on the "public" LAN, and can hit the Internet but can't access internal file servers etc. If someone in the company buys a new laptop or something, this will serve as their reminder that they need to let me know about it.:-P
Nothing less scales? I guess I'm not clear on why we need 340 billion IPs instead of only 18 billion IPs, when 4 billion IPs is what we're running out of.
The rest of your reply didn't make a whole lot of sense, so I'm ignoring it.:-)
Excuse me, they're on the same physical network. The machines can talk to each other directly; the firewall won't even know about it. They would have to be configured for this, of course.
Of course the machines can talk to each other directly... but not if they use the configuration they get from the DHCP server. If a client specifies something else, then yeah - and there's nothing I can do about that, really. At least not without buying fancier hardware or something. As long as the machines just use DHCP, they can't talk to each other across subnets without going through the router (which I can firewall), and that's all I'm after.
I believe I've found the answer to my configuration problem: the shared-network option.:-)
AHA! I think you've got it! The shared-network declaration looks like exactly what I was missing! I'll try that and see if I can get it working. Thanks!
It's because DHCP uses physical link broadcast (ie: 255.255.255.255 and also strange addresses like 0.0.0.0) to do it's work.
Of course the request is broadcast everywhere, and running two DHCP servers on the same physical LAN can't work. I only want to run one DHCP server, and have it assign IPs on different subnets depending on MAC.
You can use use VLAN aware equipment and OS and have isc-dhcp listen on the two vlan NICs.
This has been suggested to me. In this particular case, I don't have any VLAN switches and can't justify buying them.
Or you can record all the MAC addresses for the "other" subnet in dhcpd.conf.
Hmm, what do you mean? I tried what I think you're suggesting, and dhcpd ignored them. More details here.
As for you ISC DHCP problem, you can assign whatever address blocks you want to. You just need to setup the correct criteria and have a way to recognize it. The easiest way is to assign one block to particular MAC's an a different block to regular boxes.
If you mean two different ranges within the same subnet, that's what I eventually wound up doing, but I couldn't get it to work with two different subnets. See my reply here.
There is nothing in the protocol that says you can't run multiple IP subnets over the same physical wires, and in fact I do it all the time.
Just to clarify, I have no trouble running two subnets on the same physical LAN, the problem is using DHCP on both subnets. Let's say we have a "private" subnet and a "public" subnet. I've got a database of known MAC addresses, from which I build dhcpd.conf. If I get a DHCP request from a computer with a known MAC, I want to assign it a static IP address on the "private" subnet. If I get a DHCP request from a computer with an unknown MAC, I want to assigned it a dynamic IP from a range on the "public" subnet. Firewall rules on the router would prevent machines on the "public" subnet from accessing systems on the "private" subnet.
Obviously security wouldn't be perfect; anyone with a packet sniffer can see what's going on and it wouldn't affect non-IP traffic (e.g. AppleTalk, IPX, etc.). My problem is, dhcpd will absolutely refuse to run if you have IP aliases on Linux (e.g. eth0 and eth0:0), doesn't work correctly if you bind dhcpd to two NICs that are both plugged into the same switch, and ignores the configuration for the other subnet if you only bind it to one NIC.
Actually I don't think you even need the bumper sticker. IIRC in PA (and probably other states), if you rear end someone you're at fault, unless you can manage to prove that the other car cut you off. You are responsible for keeping a safe distance between you and the car in front of you.
As far as I know, this is correct.
I've heard of people turning on their headlights (which also lights up the taillights) to scare the person behind them by making them think they're seeing brake lights, without actually slowing down. Personally I always drive with my headlights on, because it makes me more visible to other drivers (even during the day in good weather), and my brake lights are very sensitive (they come on as soon as my foot touches the brake pedal).
However, when someone is following you that closely, the best thing you can do (assuming you're not already in the rightmost lane) is to maintain speed, turn on your right turn signal, wait for a safe opportunity to do so, and change lanes. Remember, it's not a race; you don't get a prize for crossing the finish line before the other guy. Other drivers are idiots - let them be idiots, and stay out of their way.
To be honest, IPv6 never really made sense to me either. I mean, OK, so we're running out of IP addresses and we need more... but as more and more companies are turning to NAT instead of using public IPs behind a firewall for internal services, some IP blocks are being freed up, and it looks to me like there are still a HUGE number of reserved subnets out there.
But assuming we really do need more IPs, why IPv6? Why 128 bits instead of, say, 64? Why build the functionality of DHCP, which (mostly) works perfectly well* and is extensible enough to support cool stuff that hadn't been thought of when IPv4 and DHCP were invented (e.g. WPAD, netbooting), into IP? What's the deal with including your MAC address as part of your IP address?
Going with the assumption that the problem really is as bad as people say it is (China has a gazillion people and more of them are getting online, and it'd be great if my refrigerator had a web-based interface I could access remotely without setting up port forwarding or a VPN, etc.)... I'm not convinced that IPv6 is the right solution to the problem. It just seems to be the only solution anyone has offered, and a lot of money has been spent bringing it closer to reality.
So, convince me: why is IPv6 the right answer to the problem?
* Off-topic, but can someone explain to me why (at least with ISC dhcpd) I can't assign IPs on two different subnets on the same physical LAN? Can this be done with a different DHCP server? Is there any kind of limitation to the protocol that makes this impossible, or is it just an implementation problem?
Slashdot Mirror
How many times have you had an ATM misprint your receipt? The same company makes those, you know.
I'd call XPSP2 an upgrade, not just a bugfix - IE includes popup blocking and security features, the firewall is improved and enabled by default, users are prompted to enable automatic updates, and the security center reminds you about needing antivirus software. These are significant features for most users.
But um, that's basically two new things (IE popup blocking, and the Security Center which does the other things I mentioned - XPSP1 already had a firewall and automatic updates, this just makes them more obvious). So yeah, your point is still valid.
No touching!
Uhh, it's also an application, which may be downloaded from bittorrent.com.
I do have issues with IPv6, but the size of the address isn't one of them.
I have absolutely no problem with computers using 128-bit addresses to route packets; my only concern with the size of the address is that it's significantly harder for humans (not computers) to deal with. 64-bit addresses in hexadecimal would be only slightly longer than IPv4 addresses.
I do see the point about not fragmenting the address space, though. I like the hierarchical idea; having to keep track of 16 million individual class C blocks with IPv4 is insane.
Please explain how the DMCA prohibits removing software from my own computer.
Whoops, I'm tired, and bad at math. Correction:
With IPv4 we've got 4 billion IPs and we're running out; this would give us 18 quintillion IPs. IPv6 gives us 340 undecillion addresses, and I just don't see that being useful.
Wow, sorry about that, I'm tired - I multiplied 4 billion by 4, when I meant to multiply 4 billion by 4 billion. I thought something about that didn't look right! What I meant was (rounding down):
0 0 = 340 undecillion
64 bits -> 18,000,000,000,000,000,000 = 18 quintillion
vs.
128 bits -> 340,000,000,000,000,000,000,000,000,000,000,000,0
I thnk the point was this: NAT and firewalls are different things. Nat does all it says it does and nothing more. If you want to filter traffic you need to add those features on top of NAT.
but if you use NAT, you don't have to filter traffic, because there's nothing to filter. Internal IPs aren't routable on the Internet, so nobody can send anything to your internal IPs anyway - they can only send packets to the external IP of the NAT router, which isn't going to forward them (because if they're not replies to something, it doesn't know where to forward them to).
This is a misunderstanding, and has been debated elsewhere: NAT offers no security by itself, it's because normally NATs have a firewall effect at the same time that they create the illusion (and in some cases reality) of security.
Uhhhhh...
The point of NAT is that IP addresses on the internal side are non-routable, i.e. there's no way to get to them from the Internet at all. The only way in is to contact the external IP of the NAT router, and convince it to let you inside, which it's not going to do unless you're replying to something. How does this not offer security?
If there's really nowhere to go, then sure, go ahead and slow down gradually... but do so with your turn signal on, so everyone around you knows you WANT to switch lanes so you can get out of the guy's way. Some people don't understand that turn signals are supposed to signal your intention or desire, not just your current action, so they wait to turn on the turn signal until an opening appears; this is dumb. Turn your turn signal on, and polite drivers will make room for you.
It also signals to the tailgater behind you that you know he wants to pass you and you'll get out of his way ASAP, so he no longer has to tailgate to let you know he wants to pass. If he's got a brain, he'll back off. Of course he probably doesn't.
Your point about speeds being low enough to make it a minor accident is valid, I suppose, but I'd much rather try to avoid it altogether.
Yep, thanks, shared-network is what I was missing.
I'm not too interested in whether it's overkill or not, but it sure as hell gets trickier trying to remember what IP you have. I can't even imagine the pain of working in ISP customer support and asking, over the phone, for someone to recite their IP address.
That's what I was thinking. 64-bit address would be twice as easy for us humans to deal with - but not twice as hard as IPv4, because we'd be using 16-digit hex addresses instead of up-to-12-digit decimal addresses. With IPv4 we've got 4 billion IPs and we're running out; this would give us 18 billion IPs. IPv6 gives us 340 billion addresses, and I just don't see that being useful.
New computers go on the "public" LAN, and can hit the Internet but can't access internal file servers etc. If someone in the company buys a new laptop or something, this will serve as their reminder that they need to let me know about it. :-P
Nothing less scales? I guess I'm not clear on why we need 340 billion IPs instead of only 18 billion IPs, when 4 billion IPs is what we're running out of.
:-)
The rest of your reply didn't make a whole lot of sense, so I'm ignoring it.
Excuse me, they're on the same physical network. The machines can talk to each other directly; the firewall won't even know about it. They would have to be configured for this, of course.
:-)
Of course the machines can talk to each other directly... but not if they use the configuration they get from the DHCP server. If a client specifies something else, then yeah - and there's nothing I can do about that, really. At least not without buying fancier hardware or something. As long as the machines just use DHCP, they can't talk to each other across subnets without going through the router (which I can firewall), and that's all I'm after.
I believe I've found the answer to my configuration problem: the shared-network option.
Yep, figured this out from someone else's reply. I hadn't been aware of the shared-network option. Thanks!
I think I may have found the answer: the shared-network statement in dhcpd.conf. I'll give this a try and see if I can get it working!
Did you try aliasing both to "eth0"? This is possible using the "iproute" tools.
No... I've never used iproute. Can you tell me more about it?
I think I may have found the answer I was looking for, though.
AHA! I think you've got it! The shared-network declaration looks like exactly what I was missing! I'll try that and see if I can get it working. Thanks!
It's because DHCP uses physical link broadcast (ie: 255.255.255.255 and also strange addresses like 0.0.0.0) to do it's work.
Of course the request is broadcast everywhere, and running two DHCP servers on the same physical LAN can't work. I only want to run one DHCP server, and have it assign IPs on different subnets depending on MAC.
You can use use VLAN aware equipment and OS and have isc-dhcp listen on the two vlan NICs.
This has been suggested to me. In this particular case, I don't have any VLAN switches and can't justify buying them.
Or you can record all the MAC addresses for the "other" subnet in dhcpd.conf.
Hmm, what do you mean? I tried what I think you're suggesting, and dhcpd ignored them. More details here.
As for you ISC DHCP problem, you can assign whatever address blocks you want to. You just need to setup the correct criteria and have a way to recognize it. The easiest way is to assign one block to particular MAC's an a different block to regular boxes.
If you mean two different ranges within the same subnet, that's what I eventually wound up doing, but I couldn't get it to work with two different subnets. See my reply here.
There is nothing in the protocol that says you can't run multiple IP subnets over the same physical wires, and in fact I do it all the time.
Just to clarify, I have no trouble running two subnets on the same physical LAN, the problem is using DHCP on both subnets. Let's say we have a "private" subnet and a "public" subnet. I've got a database of known MAC addresses, from which I build dhcpd.conf. If I get a DHCP request from a computer with a known MAC, I want to assign it a static IP address on the "private" subnet. If I get a DHCP request from a computer with an unknown MAC, I want to assigned it a dynamic IP from a range on the "public" subnet. Firewall rules on the router would prevent machines on the "public" subnet from accessing systems on the "private" subnet.
Obviously security wouldn't be perfect; anyone with a packet sniffer can see what's going on and it wouldn't affect non-IP traffic (e.g. AppleTalk, IPX, etc.). My problem is, dhcpd will absolutely refuse to run if you have IP aliases on Linux (e.g. eth0 and eth0:0), doesn't work correctly if you bind dhcpd to two NICs that are both plugged into the same switch, and ignores the configuration for the other subnet if you only bind it to one NIC.
Actually I don't think you even need the bumper sticker. IIRC in PA (and probably other states), if you rear end someone you're at fault, unless you can manage to prove that the other car cut you off. You are responsible for keeping a safe distance between you and the car in front of you.
As far as I know, this is correct.
I've heard of people turning on their headlights (which also lights up the taillights) to scare the person behind them by making them think they're seeing brake lights, without actually slowing down. Personally I always drive with my headlights on, because it makes me more visible to other drivers (even during the day in good weather), and my brake lights are very sensitive (they come on as soon as my foot touches the brake pedal).
However, when someone is following you that closely, the best thing you can do (assuming you're not already in the rightmost lane) is to maintain speed, turn on your right turn signal, wait for a safe opportunity to do so, and change lanes. Remember, it's not a race; you don't get a prize for crossing the finish line before the other guy. Other drivers are idiots - let them be idiots, and stay out of their way.
Cool insightful geeky traffic stuff here
But assuming we really do need more IPs, why IPv6? Why 128 bits instead of, say, 64? Why build the functionality of DHCP, which (mostly) works perfectly well* and is extensible enough to support cool stuff that hadn't been thought of when IPv4 and DHCP were invented (e.g. WPAD, netbooting), into IP? What's the deal with including your MAC address as part of your IP address?
Going with the assumption that the problem really is as bad as people say it is (China has a gazillion people and more of them are getting online, and it'd be great if my refrigerator had a web-based interface I could access remotely without setting up port forwarding or a VPN, etc.)... I'm not convinced that IPv6 is the right solution to the problem. It just seems to be the only solution anyone has offered, and a lot of money has been spent bringing it closer to reality.
So, convince me: why is IPv6 the right answer to the problem?