Please create an account to participate in the Slashdot moderation system


Forgot your password?
Check out the new SourceForge HTML5 internet speed test! No Flash necessary and runs on all devices. ×

Comment Re:No Russian ancestry here... apk (Score 1) 126

You're talking about the grand duchy of Poland-Lithuania? That included what's today Belarus and the western parts of Ukraine. Saying that Poland took 'Russia' seems to suggest that they took the entire country. At the time in question, I doubt that the Poles even had Moscow, much less the western Urals

Comment Re:First lesson (Score 1) 126

Assuming that all the addresses coming out of, say, Russia, are suspect, one can look up RIPE's address assignments to see which addresses they have been assigned, and block them. In fact, this is something that one can do pretty easily if one needs to block out a country. Like you think all the addresses from Syria are owned by ISIS? Check out RIPE, see which blocks have been assigned to Syria, and instruct your firewall to drop all their packets. This can be done as high up as ISP level

Comment Re:First lesson (Score 1) 126

I have two major beefs with IPV6. The first is that the end-point 2^48 switch address space wasn't well thought-through. Hey, wouldn't it be great if we didn't have to use NAT and give all of those IOT devices their own IPV6 address? Well... no actually, NAT does a pretty good job of obscuring the internal topology of the end-point network. Just having a statefull firewall and no NAT exposes the internal topology. Not such a good idea.

The second is that all the discovery protocols were left unencrypted and made complex enough to virtually guarantee a plethora of possible exploits. Some have been discovered and fixed, I guarantee there are many more in the wings. IPV4 security is a well known problem with well known solutions. IPV6 security is a different beast entirely.

Other problems including the excessively flexible protocol layering allowing for all sorts of encapsulation tricks (some of which have already been demonstrated), pasting on a 'mandatory' IPSEC without integration with a mandatory secure validation framework (making it worthless w/regards to generic applications being able to assert a packet-level secure connection), assumptions that the address space would be too big to scan (yah right... the hackers didn't get that memo my tcpdump tells me), not making use of MAC-layer features that would have improved local LAN security, if only a little. Also idiotically and arbitrarily blocking off a switch subspace, eating 48 bits for no good reason and trying to disallow routing within that space (which will soon have to be changed considering that number of people who want to have stateful *routers* to break up their sub-48-bit traffic and who have no desire whatsoever to treat those 48 bits as one big switched sub-space).

The list goes on. But now we are saddled with this pile, so we have to deal with it.


The first point about NAT - while that used to be a shortcoming in terms of topology masking and load balancing, the IETF did explicitly define Network Prefix Translation, which is a 1:1 NAT mechanism that would do what you want, but avoid the pitfalls associated w/ the 1:many mapping in IPv4 NAT. Also, IPv4 NAT consumes several port addresses, and also often several NAT layers, reducing the networking to layer 2. As for IPSEC, I didn't exactly get your point on why that is a bad thing. As for the subnet port scanning, I happen to think that having a DHCP-PAM setup where addreses can be set to change regularly would be more effective at preventing a breaking, rather than relying on the brute force of trying to prevent a port scan of /64. But this is something that can be done in IPv6, where you have no address shortage within your subnet, as opposed to IPv4, where chances are you wouldn't have > 256 addresses to play w/, unless you happen to be IBM or HP or one of the early recipients of public Class A blocks.

Also, on the 48 bit space - I somewhat agree w/ you that assigning 64-bits to the interface ID was way overkill. But if you are assigned a /48, you can have 65536 subnets of /64 within that - that's what the convention allows. Breaking it up more is what may create problems, which again, I disagree w/. The main thing about the subnet address assignment is that the moment you want to lend structure to it, the number of effective subnets you can create goes down. Which is why I wish they had made the entire top half the global prefix, and then split the bottom half b/w the subnet address and interface ID. Something like a 16:48 would have been ideal, or else, even a 32:32 if one needed plenty of structure from the subnet addressing plan.

Comment Re:First lesson (Score 1) 126

As I've pointed out in past IPv6 threads, using the lower 64 bits is overkill. No subnet is ever gonna come close to even 32 bits, but in the meantime, you're limiting the hierarchical routing upstream in the global prefix that could have used some 16-32 bits more. In other words, had we had a split of 96:32 instead of 64:64, that would have made more sense. The subnet addresses could have used 16 bits, so that you'd have had a global prefix of 80, subnet addresses 16 and lowest 32 bits the interface ID. And one can still do auto-configuration under that system

Comment Re:First lesson (Score 1) 126

True, but on a /64 network, a server need not be restricted to one address. Like if you click on a link, it could redirect to another virtual host instead of a sub-directory, and here, the virtual host can use a different IP address instead of sharing it as is done in IPv4. There are several ways one could mitigate this issue

Slashdot Top Deals

I cannot believe that God plays dice with the cosmos. -- Albert Einstein, on the randomness of quantum mechanics