So, where can I get an IPv8 implementation? ipv8.org appears to be down, my OpenBSD and Linux boxes don't have an implementation, and my Windows XP machine at work lacks IPv8 (but has IPv6).
Hell, where can I get a copy of the IPv8 RFC; it's not an official IETF one, and I can't find a proper spec for it.
Not going to happen; the/64 is needed to let stateless autoconfiguration work (which happens by default, unless you turn it off explicitly). For some degree of privacy, you can use RFC3041 privacy extensions to hide which machine you're using.
Internet registries have already decreed that you must justify (on technical grounds, not financial) issuing less than a/48. Issuing less than a/64 becomes a support nightmare (autoconfiguration is understandable, whereas static addressing isn't).
So, I doubt ISPs are ever going to issue smaller than/64s to residential customers; it's the easiest size to issue in terms of support. For now, ISPs are unlikely to issue less than/48s - see Making and Reporting Reassignments in the ARIN IPv6 guidelines. It's just easier to comply than to write document after document justifying smaller allocations.
It's not the change of port that matters, it's the connection tracking. The STUN server can detect what external port you're on, but this is useless information to the other party if the NAT insists that all data comes back from the STUN server, not from a third party.
STUN can work around a NAT device that changes ports. It cannot work around a NAT device that tracks the full (protocol, source port, destination port, source IP, destination IP) tuple. Tracking all of these is more secure (as a random idiot aware of the NAT cannot spoof data easily), but costs 13 bytes of memory per tuple, plus the associated comparisons. In the days when an embedded device vendor drooled at the idea of affordable 32-bit processors, hoped that 16-bit processors would get just a bit faster before release, and could rarely afford to fit a full megabyte of RAM, vendors found ways around storing and tracking the lot; it turns out that for most uses, tracking (protocol, source port, source IP) is enough, and it's now only 7 bytes per tuple.
Linux was never designed to run under those constraints, so it always tracked the entire tuple. Nowadays, Moore's Law has caught up on the vendors; it's cheaper to fit an ARM and 4MB of SDRAM, than to fit a cheap 16 bit processor and 512kB of SRAM. Further, you can get cheap yet complete ASICs including a reasonably fast ARM, MIPS or PPC processor, a 4-port ethernet switch with an ethernet controller attached, enough RAM and flash for your application, plus an easy route to attach a second ethernet controller, or an xDSL chip, or whatever access method you need. Price-wise, these ASICs are usually similar to just the processor, RAM and flash alone.
Those vendors with existing code that they've ported still find that STUN works; those who've started from scratch, used Linux, or taken a BSD as their base have full tuple tracking, which stops STUN working.
For reference, both MSN Messenger and Skype get round symmetric NAT using two different, nonscalable techniques. MSN simply direct traffic between two symmetric NAT users through MSN's servers; as the number of users relying on this go up, either their connections go slower, Microsoft has to buy bigger and bigger pipes, and spread NAT breaking servers across more and more countries.
Skype relies on there being enough users out there behind STUN compatible NATs (or with real addresses) who won't mind routing a small amount of data for another Skype user. Neither mechanism scales if more and more users disappear behind symmetric NAT.
Finally, since I seem to have got suckered into writing a bit of a treatise on NAT, people use symmetric NAT because it scales to more clients. A symmetric NAT can cope with 65535 UDP states or TCP connections per external IP assigned to the NAT to each and every (host, port) tuple on the Internet (so a symmetric NAT can have 65535 connections to Slashdot for HTTP, and a further 65535 connections to Slashdot for HTTPS, plus 65535 connections for MSN, and so on).
All other NAT types limit you to at most total of 65535 UDP states or TCP connections (1 UDP state per UDP port, 1 TCP connection per TCP port), which means that once 65535 TCP connections are established, one has to be killed before another one can start.
An IPv6 address is the same as 4 IPv4s in the worst case. I have a/48, and even I can remember 2001:8b0:104:1::1 and 2001:8b0:104:2::1 off the top of my head (DNS and gateway for two subnets); it's not much harder than remembering 81.187.250.193 and 81.187.250.201 for both. Plus, DNS deals with the need to remember lots of IPs anyway.
The other (serious) issue is that STUN does not handle symmetric NAT at all; it depends on the NAT simply remembering which port it's assigned.
Most corporate NATs, and more and more consumer NATs remember the (protocol, source port, source IP, destination port, destination IP) tuple for each state. STUN depends on the NAT remembering no more than (protocol, source port, source IP, destination port); anything built on Linux IPTables, or OpenBSD's pf already remembers too much.
Bullshit. Complete and utter bullshit. In decent equipment, when you reclock, you use a PLL to lock to the existing signal, and create a binary bitstream in a buffer; you then use your own clock to pump bits out of the buffer. So long as the jitter isn't too bad, there will be bits going in often enough that the buffer never drains. All that then matters is the quality of your clock.
Jitter is an issue for equipment designers; it is not an issue for equipment users. With the aid of a decent lab, you can verify this in double-blind tests; jitter either makes no difference at all, or causes the sound to glitch.
Jitter may well be there, but with a digital transmission, either the data doesn't get through (in which case the sound doesn't come out), or it does. There's no inbetween state, so unless there are errors, jitter is not worth caring about.
In any case, most (if not all) equipment with SPDIF inputs reclocks the signal before doing anything (even loopthrough is reclocked). Again, so long as no link is reporting errors, you're A-OK, no matter what the level of jitter is.
Re:Its only the bad things we head about?
on
Safari vs. KHTML
·
· Score: 3, Interesting
AIUI, the big problem is that people see that Safari is built on KHTML, and assume that the WebCore codebase and the KHTML codebase are closely related; thus, when KHTML doesn't function as well as Safari, idiots go shouting at the devs, accusing them of being lazy for "not merging Apple's lovely changes quickly enough".
The KHTML devs would like Apple to either make it clear that WebCore and KHTML are now very different, despite the common ancestor, or to help merge things back. Either way, they want something to hit the idiots with that makes sense to a clueless type, rather than stick with the current "Apple says", "KHTML says", "But Apple says!" back and forth.
ARM stacks don't grow in any direction; by convention, R13 is the stack pointer register, and you either handle it manually (using LDR and STR to pop and push, and one of ADD, SUB or RSB to manipulate it), or you use one of the variants of LDM and STM (load multiple and store multiple). I can't remember what the low-level equivalents are, but from a high-level assembler perspective, you get LDMFD/STMFD (Full, Descending), LDMED/STMED (Empty, Descending), LDMFA/STMFA (Full, Ascending), and LDMEA/STMEA (Full, Ascending). Gives you the same flexibility as hand-coding a series of STR or LDR instructions (*SP can be the next empty slot, or the last item pushed, and you can do SP++ or SP-- after each store or load).
In case anyone's wondering how an attacker sends raw packets without the aid of the Windows API, it's easy for an administrator to install any protocol driver they want on-the-fly under Windows XP and 2000. That protocol driver can provide anything it likes to the underlying network interface, including a raw sockets API.
Thus, providing the admnistrator only with raw sockets access is as secure as not doing so. Any worm that wants raw sockets for a DDoS just needs to install its own protocol handler; as soon as the need exists, you can bet that worm writers will write and share one.
In the end, it's the recipient's mail admin who uses an RBL, not the sender's. Therefore, as a mail sender, I have no power to get something done about a bad RBL that some mail admin uses; as a recipient, I can complain, contact the mail admin's manager, or even switch service altogether.
If you're paying for e-mail, and your mail admin isn't clueful enough to understand that an RBL is a delegation of mail policy to the admins of that RBL, then your mail admin has other issues too; either a God complex (in which case what else is he doing with your e-mails?), or plain old promotion beyond the point of competence.
And I'm not suggesting that an admin maintains a whitelist on a customer's request; I am suggesting that they have an unfiltered (slow) server for customers who ask for it, and that the admin should be responsible for dealing with the RBL maintainers if a customer complains about an entry. Simply put, I'm paying for an e-mail service; you are providing it, and I shouldn't have to know what RBLs you use, what anti-spam packages you have running, what mail server, what greylisting system. If I can't receive e-mail I want to receive, you are responsible for getting things changed, and if you won't do that, I should switch to a different mail provider.
The blame lies with the recipient who chooses to use a blacklist. By setting up my mailserver to use (say) MAPS RBL as an absolute indicator of whether I wish to receive e-mail from you, I am partly delegating my mail policy to MAPS.
If my decision to use MAPS RBL affects my customers' ability to receive legitimate e-mail, they should take action, as I should be answerable to them (in the worst case, they can pay for alternate mail provision). As sender, you have no relationship to me, as recipient, you do.
You've misunderstood this law; it doesn't prevent you agreeing to any terms for purchase and use that you would like to. Instead, it prevents the seller from hiding "significant" terms in a form that cannot been seen by the buyer before purchase.
It's not interfering with the negotiated and agreed to terms for purchase and use; it's interfering with terms that the seller has tried to "slip in" behind the buyer's back. The terms would be completely legal and acceptable if they had been made clear, or if a signature was required to buy the item; it was the addition of implicit terms to what appeared to be a normal purchase by the use of tiny symbols that's been declared illegal.
The "artificial" limit you refer to is no more natural than copyright; the law requires companies to clearly label any point where the product restricts purchasers from behaving in ways that they've come to consider reasonable, unless the user is informed in advance.
In this case, the court has ruled that the DVD companies haven't made it clear that DVDs have DRM that prevents you copying the content for personal use; consumers were believed to be buying the DVDs on the assumption that they could exercise that right under French copyright law. Now, the companies may either drop the DRM, or relabel all DVDs to indicate the restriction clearly.
I'm on 2MBit broadband, but for me, large content downloads (http://www.gbjab.com/ for example) are not instant. My connection is fast enough when I cannot perceive the difference between a page already cached on my local machine, and a page downloaded from the remote server. This includes big downloads like OpenOffice installers, or Windows service packs.
The endgame is preventing MS from using its legally acquired dominance in the Operating System market to obtain dominance in any other market; the hope with this penalty is that (for example) Real will do a deal with Dell to offer RealPlayer where WMP used to be on Dells, while Apple will do a deal to put iTunes on Time machines and so on.
So, why doesn't the Windows 2000 driver for my SCSI card work on Windows XP RTM, SP1, or SP2? Why doesn't the Windows 2000 driver for the scanner itself work on any version of XP (tested by switching to an Adaptec card)? Why do the scanner manufacturer, the card manufacturer and Microsoft all tell me to get a new scanner, as the old drivers are incompatible?
The answer is that the driver writers used an API that didn't support power management properly, but which flags the driver as supporting power management. Thus, the driver causes Windows to crash hard as soon as it tries to do anything with power management. Given the choice between an unstable ABI, which breaks drivers like that completely (do not load at all), and a stable ABI that results in unpredictable failures of the system (BSOD whenever Windows XP does something unexpected), I'll take the unstable ABI.
The problem is capacity; DVDs give you a max of 17GB/disc, implying 10 or more DVDs per movie. High-capacity tape formats (HD-D5 or similar) is certainly a possible distribution method, just not commonly used, as RAID arrays have the capability to be plugged into the system and run immediately, whereas a tape needs to be copied onto the system.
DVDs aren't big enough; where media is delivered physically for digital cinema, the current preferred format is RAID arrays (a film is several hundred GB).
All digital isn't a problem for smaller distributors; just telecine the film, then deliver discs rather than film. It's still cheaper (although not as much as delivery by satellite).
Cracking the satellite signal is going to be interesting to academia; it'll use strong encryption (think PGP), and the interceptor lacks the key.
I'm in the UK; my broadband router does not do NAT or filtering. Guess what? I'm clueful enough to run my own firewall and lock down the boxes I own, so I'm not a problem.
The only other two people I know well enough to comment on their security who have broadband have NAT routers. It doesn't exactly stop them getting turned into zombies from the warez they download and install (download 10 different "adobe photoshop cs" installers, run each one in turn until one works).
More accurately, HURD maps the entire filesystem into memory space because at the point it was designed, people were reckoning that we'd switch to 64-bit virtual memory systems (UltraSparc, MIPS64, AMD64) before we got to 2GB hard drives. History proved them wrong.
Slashdot Mirror
Hell, where can I get a copy of the IPv8 RFC; it's not an official IETF one, and I can't find a proper spec for it.
Not going to happen; the /64 is needed to let stateless autoconfiguration work (which happens by default, unless you turn it off explicitly). For some degree of privacy, you can use RFC3041 privacy extensions to hide which machine you're using.
So, I doubt ISPs are ever going to issue smaller than /64s to residential customers; it's the easiest size to issue in terms of support. For now, ISPs are unlikely to issue less than /48s - see Making and Reporting Reassignments in the ARIN IPv6 guidelines. It's just easier to comply than to write document after document justifying smaller allocations.
You can, but IPv6 gives you a lot more addresses than that. You get a /48 (65536 networks, each with up to 4,294,967,296 machines).
STUN can work around a NAT device that changes ports. It cannot work around a NAT device that tracks the full (protocol, source port, destination port, source IP, destination IP) tuple. Tracking all of these is more secure (as a random idiot aware of the NAT cannot spoof data easily), but costs 13 bytes of memory per tuple, plus the associated comparisons. In the days when an embedded device vendor drooled at the idea of affordable 32-bit processors, hoped that 16-bit processors would get just a bit faster before release, and could rarely afford to fit a full megabyte of RAM, vendors found ways around storing and tracking the lot; it turns out that for most uses, tracking (protocol, source port, source IP) is enough, and it's now only 7 bytes per tuple.
Linux was never designed to run under those constraints, so it always tracked the entire tuple. Nowadays, Moore's Law has caught up on the vendors; it's cheaper to fit an ARM and 4MB of SDRAM, than to fit a cheap 16 bit processor and 512kB of SRAM. Further, you can get cheap yet complete ASICs including a reasonably fast ARM, MIPS or PPC processor, a 4-port ethernet switch with an ethernet controller attached, enough RAM and flash for your application, plus an easy route to attach a second ethernet controller, or an xDSL chip, or whatever access method you need. Price-wise, these ASICs are usually similar to just the processor, RAM and flash alone.
Those vendors with existing code that they've ported still find that STUN works; those who've started from scratch, used Linux, or taken a BSD as their base have full tuple tracking, which stops STUN working.
For reference, both MSN Messenger and Skype get round symmetric NAT using two different, nonscalable techniques. MSN simply direct traffic between two symmetric NAT users through MSN's servers; as the number of users relying on this go up, either their connections go slower, Microsoft has to buy bigger and bigger pipes, and spread NAT breaking servers across more and more countries.
Skype relies on there being enough users out there behind STUN compatible NATs (or with real addresses) who won't mind routing a small amount of data for another Skype user. Neither mechanism scales if more and more users disappear behind symmetric NAT.
Finally, since I seem to have got suckered into writing a bit of a treatise on NAT, people use symmetric NAT because it scales to more clients. A symmetric NAT can cope with 65535 UDP states or TCP connections per external IP assigned to the NAT to each and every (host, port) tuple on the Internet (so a symmetric NAT can have 65535 connections to Slashdot for HTTP, and a further 65535 connections to Slashdot for HTTPS, plus 65535 connections for MSN, and so on).
All other NAT types limit you to at most total of 65535 UDP states or TCP connections (1 UDP state per UDP port, 1 TCP connection per TCP port), which means that once 65535 TCP connections are established, one has to be killed before another one can start.
An IPv6 address is the same as 4 IPv4s in the worst case. I have a /48, and even I can remember 2001:8b0:104:1::1 and 2001:8b0:104:2::1 off the top of my head (DNS and gateway for two subnets); it's not much harder than remembering 81.187.250.193 and 81.187.250.201 for both. Plus, DNS deals with the need to remember lots of IPs anyway.
Most corporate NATs, and more and more consumer NATs remember the (protocol, source port, source IP, destination port, destination IP) tuple for each state. STUN depends on the NAT remembering no more than (protocol, source port, source IP, destination port); anything built on Linux IPTables, or OpenBSD's pf already remembers too much.
Jitter is an issue for equipment designers; it is not an issue for equipment users. With the aid of a decent lab, you can verify this in double-blind tests; jitter either makes no difference at all, or causes the sound to glitch.
In any case, most (if not all) equipment with SPDIF inputs reclocks the signal before doing anything (even loopthrough is reclocked). Again, so long as no link is reporting errors, you're A-OK, no matter what the level of jitter is.
The KHTML devs would like Apple to either make it clear that WebCore and KHTML are now very different, despite the common ancestor, or to help merge things back. Either way, they want something to hit the idiots with that makes sense to a clueless type, rather than stick with the current "Apple says", "KHTML says", "But Apple says!" back and forth.
ARM stacks don't grow in any direction; by convention, R13 is the stack pointer register, and you either handle it manually (using LDR and STR to pop and push, and one of ADD, SUB or RSB to manipulate it), or you use one of the variants of LDM and STM (load multiple and store multiple). I can't remember what the low-level equivalents are, but from a high-level assembler perspective, you get LDMFD/STMFD (Full, Descending), LDMED/STMED (Empty, Descending), LDMFA/STMFA (Full, Ascending), and LDMEA/STMEA (Full, Ascending). Gives you the same flexibility as hand-coding a series of STR or LDR instructions (*SP can be the next empty slot, or the last item pushed, and you can do SP++ or SP-- after each store or load).
Thus, providing the admnistrator only with raw sockets access is as secure as not doing so. Any worm that wants raw sockets for a DDoS just needs to install its own protocol handler; as soon as the need exists, you can bet that worm writers will write and share one.
If you're paying for e-mail, and your mail admin isn't clueful enough to understand that an RBL is a delegation of mail policy to the admins of that RBL, then your mail admin has other issues too; either a God complex (in which case what else is he doing with your e-mails?), or plain old promotion beyond the point of competence.
And I'm not suggesting that an admin maintains a whitelist on a customer's request; I am suggesting that they have an unfiltered (slow) server for customers who ask for it, and that the admin should be responsible for dealing with the RBL maintainers if a customer complains about an entry. Simply put, I'm paying for an e-mail service; you are providing it, and I shouldn't have to know what RBLs you use, what anti-spam packages you have running, what mail server, what greylisting system. If I can't receive e-mail I want to receive, you are responsible for getting things changed, and if you won't do that, I should switch to a different mail provider.
If my decision to use MAPS RBL affects my customers' ability to receive legitimate e-mail, they should take action, as I should be answerable to them (in the worst case, they can pay for alternate mail provision). As sender, you have no relationship to me, as recipient, you do.
It's not interfering with the negotiated and agreed to terms for purchase and use; it's interfering with terms that the seller has tried to "slip in" behind the buyer's back. The terms would be completely legal and acceptable if they had been made clear, or if a signature was required to buy the item; it was the addition of implicit terms to what appeared to be a normal purchase by the use of tiny symbols that's been declared illegal.
In this case, the court has ruled that the DVD companies haven't made it clear that DVDs have DRM that prevents you copying the content for personal use; consumers were believed to be buying the DVDs on the assumption that they could exercise that right under French copyright law. Now, the companies may either drop the DRM, or relabel all DVDs to indicate the restriction clearly.
I'm on 2MBit broadband, but for me, large content downloads (http://www.gbjab.com/ for example) are not instant. My connection is fast enough when I cannot perceive the difference between a page already cached on my local machine, and a page downloaded from the remote server. This includes big downloads like OpenOffice installers, or Windows service packs.
He'll be with 3. Cheap, but no web browsing, and (in my experience), appalling customer service.
The endgame is preventing MS from using its legally acquired dominance in the Operating System market to obtain dominance in any other market; the hope with this penalty is that (for example) Real will do a deal with Dell to offer RealPlayer where WMP used to be on Dells, while Apple will do a deal to put iTunes on Time machines and so on.
The answer is that the driver writers used an API that didn't support power management properly, but which flags the driver as supporting power management. Thus, the driver causes Windows to crash hard as soon as it tries to do anything with power management. Given the choice between an unstable ABI, which breaks drivers like that completely (do not load at all), and a stable ABI that results in unpredictable failures of the system (BSOD whenever Windows XP does something unexpected), I'll take the unstable ABI.
The problem is capacity; DVDs give you a max of 17GB/disc, implying 10 or more DVDs per movie. High-capacity tape formats (HD-D5 or similar) is certainly a possible distribution method, just not commonly used, as RAID arrays have the capability to be plugged into the system and run immediately, whereas a tape needs to be copied onto the system.
All digital isn't a problem for smaller distributors; just telecine the film, then deliver discs rather than film. It's still cheaper (although not as much as delivery by satellite).
Cracking the satellite signal is going to be interesting to academia; it'll use strong encryption (think PGP), and the interceptor lacks the key.
41% of British Internet connections are broadband or other always-on connections, and 4% use a mixture of access methods. Leaves 55% who are exclusively modem users.
The only other two people I know well enough to comment on their security who have broadband have NAT routers. It doesn't exactly stop them getting turned into zombies from the warez they download and install (download 10 different "adobe photoshop cs" installers, run each one in turn until one works).
More accurately, HURD maps the entire filesystem into memory space because at the point it was designed, people were reckoning that we'd switch to 64-bit virtual memory systems (UltraSparc, MIPS64, AMD64) before we got to 2GB hard drives. History proved them wrong.