Just lie to your equipment and tell it you're in Japan:-) I did that to a USR/3Com TC shelf once -- just for testing, mind you:-) I got a 56k (and sometimes higher?! wtf) connection every time. Of course, at that power level, it creates problems for everyone else in that trunk. And, that was before 3com started locking the country codes.
Connecting to your friend's 56k modem would yield only 33.6 in each direction IIRC.
Unless you were my friend... I had an ISDN BRI, so I could answer x2/v.90/v.92 calls the same as an ISP. Of course, the line was never callable 'cause I kept it nailed up at 128k.
(Yes, it was (still is) expensive as hell, but it was the only option for a very long time... out of range for DSL (and wasn't until about a year ago when HellSouth finally desided to put a DSLAM in the pedistal serving the apartment complex -- yeap, they ignored *800* apartments for almost a decade), and the p***ies at TW made Raleigh, NC the last place for cable modem rollout -- despite it being the testbed for the technology.)
It's easier to do with ISDN (BRI or PRI), but it was also possible with a plain old T1. It had to be a "trunk side" T1, 'tho -- to avoid any D-A conversions that ruin the whole process.
It had to remain digital all the way to the serving line CO. If you were off a multiplexor (an "SLC", pronounced "slick"), it wouldn't work.
Longer answer: At best, the heat from the strike will melt the cable. Even if 100% of the flash were visable inside the fiber, it simply won't carry enough photons to do any real damage to the equipment. (and no where near that much light will enter the cable. any light visable to the cable will be so oblique it will be attentuated by the first big bend -- it won't reflect at such a high angle.)
...screwed when it's own reflection (from the break) interfered with reception.
I don't think you understand how light or fiber optics work. First off, photons don't interfere with each other (slit experiments aside), so those photons reflected back down the cable from the break have ZERO effect on the signal at the break -- there's no lose due to photon collisions. Second, the cables and interfaces are desgined to generate nearly zero reflection (i.e. the tx/rx elements will not mirror anything back into the cable and the ends are "perfect" 90deg polished surfaces generating nearly zero reflection.) What makes a break bad is the lose of signal due to the reflections. For example, 90% of the signal is reflected back down the cable leaving only 10% to possibly make it across the break to the other end of the cable which might also reflect part or all of the signal (into oblivion) depending on the exact surface conditions. (think "broken mirror") Long packets are more susceptible to error because there are more bits that have to make it across the break. Smaller packets are less susceptible because there are fewer bits. And ping generates a pretty stable bit pattern to begin with. (And yes, I've seen the exact same thing a few times. Moral of the story, it's all but impossible to get a telco tech to run anything other than all-one's and all-zero's. [*])
(It's not the photon reflections that are the problem. It's the photon interactions with the random, jagged edges of the broken fiber bits. Things like refraction, and angle of incident are the important things. If the light enters the cable at odd angles (!= 90 to the cable end), then it becomes increasingly susceptible to bends in the cable -- at some point, the wall of the cable is no longer reflective and the light escapes.)
However, I heartly agree with the lack of utility for "desktop" fibre runs.
[I've been fascinated with fiber(fibre) optics for 25+ years.]
[* At a previous job (telco/ISP), two engineers had been pulling their hair out for hours -- 17 hours, all night, in fact -- trying to figure out a problem for one customer... one application didn't work -- I vaguely remember it being an issue with email attachments. They couldn't figure out what was wrong. Tech's sent to every node between the CO and the customer netted nothing. *They* saw nothing when they ran their tests, but it was still broken when they released the line. I overheard the mess when makin' the rounds for lunch. Armed with this knowledge, it took me three (3) minutes to find a bit pattern to cause continuous bi-polar violations... another 15 to get the tech's to watch me create the errors (and them to call the CO to make sure I wasn't manually injecting errors at the patch panel:-)) After "scolding" them for not running more "exhotic" tests -- their BERTs will do about a dozen different patterns, they run exactly two, EVER -- we left them to run quasi-random tests from every point to isolate the fault and went to lunch. They eventually fixed it.]
froogle shows the cheapest 1000baseSX card @ $105; SX-TX media converter @ $188 So, not exactly "double the cost". That is 5-10x more than a copper card. But, fibre to the home will likely not be gig, and will very likely have a telco provided terminal for voice, video, and data.
(Even our office T1 has a telco provided terminal providing ethernet for data and twisted pair (db25) for voice. It's actually voice and data over frame relay -- ATM multiplexed most likely, but I didn't dig any further.)
A 30cent piece of plastic is all it takes to "join" two fibre cables. I have a little "haloween" bucket with various couplers in it. They do range from free to f'ing insanely expensive, 'tho. The only trick is getting the two 60 micron holes to line up. In theory, a swizzle stick or some heat shrink tubing will work. (wrap the hack in electrical tape to block out light.)
(I'm assuming you don't have spools of raw fibre cable laying around. In that case, splicing cables together will require some expensive toys -- I've never heard of anyone successfully fusion splicing with a bic lighter.)
They use single mode because it's lower loss and thus supports longer runs. Which is cheaper: multi-mode cable with a regen every kilometer, or single-mode cable with a regen every 10km (or 100km if you use non-standard emitters)?
Fibre cable is more expensive because (a) it's harder to make, and (b) because it can be. Extruding a 62.5 micron glass/plastic fibre is more involved than extruding a 26AWG copper wire; the copper wire doesn't have sub-micron tolerances. But, the ultimate factor is the people buying the stuff... fibre costs what it does because that's what people are willing to pay for it.
Labor costs for actually running the cable far outweigh the cost of goods. Fibre, copper, or string... doesn't really matter what they hang/bury. So, they run whatever will provided the best long-term economy.
And it's immune to interference (unless you're close to a blackhole.) Bundles of copper wire have issues with cross-talk. Optical fibre has no such problems.
Also, photons behave very different from electrons. Photons don't interfere with each other. So, one strand of fibre can handle both tx/rx at the same time. This is what makes DWDM possible.
Any company concerned with NAT traversal uses VPN tunnels. Trusting inherently untrustable machines beyond the protection of the company firewall is never a good idea. VPN's provide the necessary controls to limit who may use what and when.
For the record, NAT has existed longer than it's been called "NAT". I was using "NAT" as far back as 1995. That far back, people called things that didn't run routing protocols "gateways"; routers were expensive, complex systems that ran complicated routing protocols (RIP doesn't count.)
As I said, the problem is not, and never has been, *NAT*. It's application protocols making assumptions that get them in trouble. When an application binds INADDR_ANY to a socket, it does not know what address it will be when it finally reaches the wire. By using INADDR_ANY, you're telling the kernel to set the address. If you want to tell a remote node the address to which it sould connect, the application MUST bind a socket to that specific address and use it for communications. (or use getsockaddr() once a tcp connection is established.) Otherwise, you have very little idea what your address is as seen by the remote node. [routing logic in modern systems can be very complex making it impractical to replicate it in an application for the sole purpose of telling someone what your address is when they can easily see it right there in the packet they just received.]
People also seem to be unable to remember the mistakes of the past... FTP PORT command anyone? Multihomed systems? Protocol translation? (ok, so we do that anymore.) Split-horizan? (technically a routing term, but still a lesson that applies here.)
The truth of the matter is the SIP designers were blind to the existing network landscape. NAT was here in '99. NAT was a large part of the Internet in '99. There were no indications it was going away. Poking your head in the sand thinking everyone will switch to IPv6 and NAT will go away was (and is) certifiable lunacy. IPv6 may be the best technical solution (read: "on paper") to IPv4 address exhaustion, but it's the worst possible effective solution because it requires the entire IPv4 infrastructure be abandoned in favor of IPv6; given the number of existing IPv4 devices that will never be IPv6 capable because there's no one around to reprogram them, there will always be significant pressure against IPv6 adoption. This is especially true given a very effective solution that doesn't require burning down the farm: NAT!
I've said it before, and I'm saying it again. EVERY problem that has cropped up with protocols not working through NAT has been attributable to the protocol being designed as though it authoritatively know things that it cannot authoritatively assess.
I see the problem with SIP after 30s of reviewing the RFC. Right there in Fig. 1... it tells the remote end how to connect back. That will not work reliably - period. NAT or not. The SIP client is picking an interface/hostname (at random) and feeding it to the remote client. For any machine that has more than one NIC, there exists the possibility the client will pick the wrong interface.
I have never seen an application with the necessary logic to correctly determine what INADDR_ANY should be for a remote client. Most simply pluck the hostname from the system (and to my surprise, not always with gethostname()!) and either send that or lookup the address and send that. Those that try (and fail) to be smart and fetch a list of interfaces, never bother to look at the route table to use the correct interface. (on linux they'd have to look through any rules as well.)
NAT is not the evil here. The protocol itself demands clear, unobstructed communications between peers. This is extremely unlikely on the internet. And that's not going to change. If your NAT and/or FW device is not SIP aware, you will have problems. It's not NAT or the firewall's fault the protocol was designed this way. The designers of the protocol are to blame for not concidering the existing medium through which it would have to work -- NAT and firewalls have been around much longer than SIP. (the truth is, SIP was never intended to cross these network boundries.)
53byte cells are the "grand unifying theory" of why designing by committee is Stupid(tm).
Why 53? Because several manufacturers had already made competing ATM equipment prior to any standard. Some were 32byte cells, others were 64. So, in an infinitely stupid move to give neither an upper hand, the standard is 53bytes; they all had to redesign their gear.
Ok, list me the firewalls that are IPv6 capable. Linux/*BSD/etc. are OSes, not firewalls; they can be used to build a firewall, but are not, themselves, "a firewall." I'm looking for things you can tell your grandmother to buy and plug in as simply as all the linksys and netgear "cable routers". (which aren't firewalls, but do play one on TV.)
I do see that I said worst case. We don't have 2^20 route entries right now (and actually cannot with reserved space, multicast, etc.) Nor will we actually ever see 2^64 IPv6 prefixes. (certainly not within my lifetime, I hope.) The original commenter has missed the point of "more address space": more people will have globally routed networks. That means more prefixes, not less. Route aggregation will only go so far; depending on it is more of a "kludge" than IPv4 NAT.
And routers will have to handle all 128bits in their tables -- there could be network tables and more detailed sub-network tables, but as the wizard says "that's another story" -- otherwise you've hardcoded the IPv6 landscape into a classful corner (and thus doomed yourself to repeating the lessons (not) learned from IPv4.)
HAH! Planning a global routing hierarchy. Excuse me while I get the Dr. Pepper out of my nose. First off, you'll never get the entire world to agree on a numbering plan. And second, you'll never be able to enforce it. Besides, the IPv6 design already poopoo's on such things... address assignments are portable -- to avoid the issues of renumbering when changing ISPs.
What matters is whether you can reduce the *number* of routing entries by a few factors.
Except you will not be reducing the number of prefixes. They will increase. This is a fundamental point to creating a larger address space: more people can have globally routed networks.
Hierarchtical routing is one of those things that look good on paper. But they never quiet live up to promise in the real world. The IPv4 world calls this route aggregation. It takes significant planning, and it's very hard to maintain over time. One of the points of IPv6 is that people are assigned addresses that are "theirs", forever; they can take them to any provider, any where and they'll work. That is completely impossible within a hierarchtical routing scheme. If you're very lucky, you can keep people within various hierarchtical prefixes, but that'll be through shear, blind, luck.
Just to give you an example...
Ding. ISPs already do this with IPv4 addresses. They are assigned a/20 (or larger) from a RIR which they annouce globally as the/20 "supernet". Internally, they can break that address space all the way down to/32's if they want; the rest of the world will still only see one prefix. The only difference with IPv6 is that the prefixes are 4x larger. (32 x 4 = 128)
IPv6 will not magically flatten people's network infrastructures. If a company has 40 networks (subnets) internally using IPv4, they'll very likely have the exact same 40 networks using IPv6. [think hub-and-spoke for a bunch of offices.] The number of prefixs within the company will not change; the the hub will still have 40 networks in it's tables and each spoke will still have the same default route in it's tables. However, the memory used for those prefixes will increase by a factor of 4 because the addresses are now 128bits.
I'll have to spy on my Cisco router and see how it's doing this very thing. I have two networks on the same interface and dhcp pools within them. It happly hands out addresses from the first pool until full and then hands out addresses from the second pool. And all my machines work just fine.
Maybe ISC's server just isn't coded to handle something odd like this.
32bit address space -> 128bit address space, and the route table is supposed to be smaller?!
For IPv4, the minimum prefix length is/24. (nothing smaller than that is globally routable. And/20 is all you're required to support.) So, the current IPv4 route table could be as large as 2^24 elements, worst case. IPv6 uses a 64bit network address, so the IPv6 route table could be as large as 2^64 elements, worst case. Let's see, that's 2^40 times MORE table entries, plus the increased sizes of the addresses within the table themselves (which are 4x larger.)
IPv6 will, in fact, greatly increase the size of everyone's route tables. The size of the data within the table is 4x larger. And there will be more route prefixes, not less, in global routing tables. [that is, after all, the whole point of *more address space*.]
Firewall rules on the router would prevent machines on the "public" subnet from accessing systems on the "private" subnet
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....if you have IP aliases on Linux (e.g. eth0 and eth0:0)...
Don't use interface aliases. iproute2 can assign multiple addresses to one nic:
[root:pts/1{1}]master:~/[01:48 PM]:ip addr show dev eth1 3: eth1: mtu 1500 qdisc pfifo_fast qlen 1000
link/ether 00:e0:81:25:d1:ad brd ff:ff:ff:ff:ff:ff
inet 10.0.0.1/24 brd 10.0.0.255 scope global eth1 [root:pts/1{1}]master:~/[01:48 PM]:ip addr add 10.1.0.1/24 dev eth1 [root:pts/1{1}]master:~/[01:49 PM]:ip addr show dev eth1 3: eth1: mtu 1500 qdisc pfifo_fast qlen 1000
link/ether 00:e0:81:25:d1:ad brd ff:ff:ff:ff:ff:ff
inet 10.0.0.1/24 brd 10.0.0.255 scope global eth1
inet 10.1.0.1/24 scope global eth1
Yes, he was... "it should be whipped thoroughly with multiple passes of random data (to avoid data recovery though forensics techniques)." Forensic data recovery IS DIFFICULT. Anyone who says otherwise doesn't know what they are talking about.
Once a new stream of bits has been written to a sector, it takes highly specialized tools to even attempt reading back the previous layers. That information is now noise. Hard drives are not designed to read that noise. (add in modern day high density technologies -- GMR, multiple pickups, proprietary modulations, proprietary error correction, 10-15k rpm speeds, super high aerial densities, etc. -- and it's beyond the reach of "common folk" and way out of reach of poor students.) The few companies that specialize in this sort of thing have all manner of toys for reading back all sorts of stuff from the platters -- custom hard drive circuit boards, custom firmware, precision magnetic read heads, powerful recovery software (to make sense of the noise), etc.
Let's see you read between tracks using the factory hardware and firmware. Even reading remapped sectors can be difficult -- most drives will not return defective data under any circumstances.
All this crap about DoD data security proceedures is laughable paranoia. 99.999999% of the hard drives on Earth don't have anything worth recovering. And that includes many of the hard drives used by various governments. Even the DoD knows the only way to be 100% certain the data is deleted is to physically destroy the drive. I guess people skip right over that -- any drive that has ever held "Top Secret" data must be destroyed - period; it cannot be declassified.
You're a student... go get a few years of *realworld* experience under your belt before running off at the mouth. Books are a good thing. And theory is nice. But reality is always different.
Give me physical access to a computer of an IT staff member who has reasonable levels of access and I will be able to compromise the entire network; period.
Bold statements from someone who probablly couldn't follow through on it. (And if you did, you'd be fired on the spot.) You seem to think the admin's computer is the key to the kingdom. The machine is merely a way to get there -- like a car, any car will do. The passwords the admin knows (or has secured somewhere) is what gets them into various resources. You'd be better off stealing every scrap of paper in their office; admins are much more likely to write down a password as put it in a file somewhere.
If I have physical access to a computer it is mine...
This is partially true. Given physical access, no amount of security will protect the information forever. It's a race against the clock... how long before the owner comes back? How long before someone notices you under the desk? How long before someone notices the machine isn't online? How long before people notice the machine isn't there anymore? How long before any possibly compromised security information is invalidated?
Even a small amount of protection will secure a machine that you cannot take. There's only so much time you can spend under someone's desk before you're caught. Taking the computer apart (eg. to clear a BIOS password) is a clear sign of mischef.
So I go away for an hour or two, come back, retrieve my external HD and there is no way to detect I ever accessed that disk.
While true, they wouldn't know the disk had been accessed, it would be easy to tell the machine had been restarted. And even how long it had been down. And if it had been shutdown properly. etc. etc. Doctoring those records can be troublesome -- they might not even be on that box.
Any, and I stress this: Any computer terminal that is not physically secured should be a diskless workstation...
Ok. Now you're just being an idiot. How many times does the computer industry have to learn the same damned lesson? F'ing terminals... *sigh* Where the hell do you go to school? Did they not teach you anything about computing history?
Even diskless workstations have to have files stored somewhere. And since it's accessing them remotely, it's pretty easy to watch the wire for what you want. (it's not likely to be (strongly) encrypted.) Or just impersonate the workstation. Or steal the fileserver.
Forensic recovery of a hard drive is very difficult and *expensive*. It's not a process any random hacker can do in their basement. Some random schmuck is not going to spend 100k$ to recover a few useless passwords, documents, etc. Nothing any of us do is that valuable. (military installations aside. 'tho an interesting read, most of what they do isn't worth the trouble either.)
Or as a friend of my recounts... a sledge and a broom:-) They smashed the drive, flattened the platers into tissue paper, and swept the mess into the MED. Good luck recovering that.
What's this about "no waste"? If he's creating what he's claiming, "hydrinos", then he's partially collapsing a hydrogen atom. Once it's collapsed and thus energy released, it'll take energy to get it back to normal.
The hydrino's being created from the process(es) ARE the waste product. What the hell are you going to do with collapsed hydrogen atoms? They won't behave like normal hyrdogen; compounds created from them won't behave in expected ways. What's he going to do, cycle hydrino's through the "reactor" until they've collapsed into a neutron? Then what's to come of these free floating neutrons? (neutrons don't stay neutrons when they're all alone.)
For my money, I think this guy slept through every physics class he's ever taken.
Slashdot Mirror
52k is due to power restrictions. Damn you FCC!
:-) I did that to a USR/3Com TC shelf once -- just for testing, mind you :-) I got a 56k (and sometimes higher?! wtf) connection every time. Of course, at that power level, it creates problems for everyone else in that trunk. And, that was before 3com started locking the country codes.
Just lie to your equipment and tell it you're in Japan
Connecting to your friend's 56k modem would yield only 33.6 in each direction IIRC.
Unless you were my friend... I had an ISDN BRI, so I could answer x2/v.90/v.92 calls the same as an ISP. Of course, the line was never callable 'cause I kept it nailed up at 128k.
(Yes, it was (still is) expensive as hell, but it was the only option for a very long time... out of range for DSL (and wasn't until about a year ago when HellSouth finally desided to put a DSLAM in the pedistal serving the apartment complex -- yeap, they ignored *800* apartments for almost a decade), and the p***ies at TW made Raleigh, NC the last place for cable modem rollout -- despite it being the testbed for the technology.)
It's easier to do with ISDN (BRI or PRI), but it was also possible with a plain old T1. It had to be a "trunk side" T1, 'tho -- to avoid any D-A conversions that ruin the whole process.
It had to remain digital all the way to the serving line CO. If you were off a multiplexor (an "SLC", pronounced "slick"), it wouldn't work.
Simple answer: Heh, NO.
Longer answer: At best, the heat from the strike will melt the cable. Even if 100% of the flash were visable inside the fiber, it simply won't carry enough photons to do any real damage to the equipment. (and no where near that much light will enter the cable. any light visable to the cable will be so oblique it will be attentuated by the first big bend -- it won't reflect at such a high angle.)
...screwed when it's own reflection (from the break) interfered with reception.
:-)) After "scolding" them for not running more "exhotic" tests -- their BERTs will do about a dozen different patterns, they run exactly two, EVER -- we left them to run quasi-random tests from every point to isolate the fault and went to lunch. They eventually fixed it.]
I don't think you understand how light or fiber optics work. First off, photons don't interfere with each other (slit experiments aside), so those photons reflected back down the cable from the break have ZERO effect on the signal at the break -- there's no lose due to photon collisions. Second, the cables and interfaces are desgined to generate nearly zero reflection (i.e. the tx/rx elements will not mirror anything back into the cable and the ends are "perfect" 90deg polished surfaces generating nearly zero reflection.) What makes a break bad is the lose of signal due to the reflections. For example, 90% of the signal is reflected back down the cable leaving only 10% to possibly make it across the break to the other end of the cable which might also reflect part or all of the signal (into oblivion) depending on the exact surface conditions. (think "broken mirror") Long packets are more susceptible to error because there are more bits that have to make it across the break. Smaller packets are less susceptible because there are fewer bits. And ping generates a pretty stable bit pattern to begin with. (And yes, I've seen the exact same thing a few times. Moral of the story, it's all but impossible to get a telco tech to run anything other than all-one's and all-zero's. [*])
(It's not the photon reflections that are the problem. It's the photon interactions with the random, jagged edges of the broken fiber bits. Things like refraction, and angle of incident are the important things. If the light enters the cable at odd angles (!= 90 to the cable end), then it becomes increasingly susceptible to bends in the cable -- at some point, the wall of the cable is no longer reflective and the light escapes.)
However, I heartly agree with the lack of utility for "desktop" fibre runs.
[I've been fascinated with fiber(fibre) optics for 25+ years.]
[* At a previous job (telco/ISP), two engineers had been pulling their hair out for hours -- 17 hours, all night, in fact -- trying to figure out a problem for one customer... one application didn't work -- I vaguely remember it being an issue with email attachments. They couldn't figure out what was wrong. Tech's sent to every node between the CO and the customer netted nothing. *They* saw nothing when they ran their tests, but it was still broken when they released the line. I overheard the mess when makin' the rounds for lunch. Armed with this knowledge, it took me three (3) minutes to find a bit pattern to cause continuous bi-polar violations... another 15 to get the tech's to watch me create the errors (and them to call the CO to make sure I wasn't manually injecting errors at the patch panel
froogle shows the cheapest 1000baseSX card @ $105; SX-TX media converter @ $188 So, not exactly "double the cost". That is 5-10x more than a copper card. But, fibre to the home will likely not be gig, and will very likely have a telco provided terminal for voice, video, and data.
(Even our office T1 has a telco provided terminal providing ethernet for data and twisted pair (db25) for voice. It's actually voice and data over frame relay -- ATM multiplexed most likely, but I didn't dig any further.)
A 30cent piece of plastic is all it takes to "join" two fibre cables. I have a little "haloween" bucket with various couplers in it. They do range from free to f'ing insanely expensive, 'tho. The only trick is getting the two 60 micron holes to line up. In theory, a swizzle stick or some heat shrink tubing will work. (wrap the hack in electrical tape to block out light.)
(I'm assuming you don't have spools of raw fibre cable laying around. In that case, splicing cables together will require some expensive toys -- I've never heard of anyone successfully fusion splicing with a bic lighter.)
They use single mode because it's lower loss and thus supports longer runs. Which is cheaper: multi-mode cable with a regen every kilometer, or single-mode cable with a regen every 10km (or 100km if you use non-standard emitters)?
Fibre cable is more expensive because (a) it's harder to make, and (b) because it can be. Extruding a 62.5 micron glass/plastic fibre is more involved than extruding a 26AWG copper wire; the copper wire doesn't have sub-micron tolerances. But, the ultimate factor is the people buying the stuff... fibre costs what it does because that's what people are willing to pay for it.
Labor costs for actually running the cable far outweigh the cost of goods. Fibre, copper, or string... doesn't really matter what they hang/bury. So, they run whatever will provided the best long-term economy.
And it's immune to interference (unless you're close to a blackhole.) Bundles of copper wire have issues with cross-talk. Optical fibre has no such problems.
Also, photons behave very different from electrons. Photons don't interfere with each other. So, one strand of fibre can handle both tx/rx at the same time. This is what makes DWDM possible.
Any company concerned with NAT traversal uses VPN tunnels. Trusting inherently untrustable machines beyond the protection of the company firewall is never a good idea. VPN's provide the necessary controls to limit who may use what and when.
For the record, NAT has existed longer than it's been called "NAT". I was using "NAT" as far back as 1995. That far back, people called things that didn't run routing protocols "gateways"; routers were expensive, complex systems that ran complicated routing protocols (RIP doesn't count.)
As I said, the problem is not, and never has been, *NAT*. It's application protocols making assumptions that get them in trouble. When an application binds INADDR_ANY to a socket, it does not know what address it will be when it finally reaches the wire. By using INADDR_ANY, you're telling the kernel to set the address. If you want to tell a remote node the address to which it sould connect, the application MUST bind a socket to that specific address and use it for communications. (or use getsockaddr() once a tcp connection is established.) Otherwise, you have very little idea what your address is as seen by the remote node. [routing logic in modern systems can be very complex making it impractical to replicate it in an application for the sole purpose of telling someone what your address is when they can easily see it right there in the packet they just received.]
People also seem to be unable to remember the mistakes of the past... FTP PORT command anyone? Multihomed systems? Protocol translation? (ok, so we do that anymore.) Split-horizan? (technically a routing term, but still a lesson that applies here.)
The truth of the matter is the SIP designers were blind to the existing network landscape. NAT was here in '99. NAT was a large part of the Internet in '99. There were no indications it was going away. Poking your head in the sand thinking everyone will switch to IPv6 and NAT will go away was (and is) certifiable lunacy. IPv6 may be the best technical solution (read: "on paper") to IPv4 address exhaustion, but it's the worst possible effective solution because it requires the entire IPv4 infrastructure be abandoned in favor of IPv6; given the number of existing IPv4 devices that will never be IPv6 capable because there's no one around to reprogram them, there will always be significant pressure against IPv6 adoption. This is especially true given a very effective solution that doesn't require burning down the farm: NAT!
I've said it before, and I'm saying it again. EVERY problem that has cropped up with protocols not working through NAT has been attributable to the protocol being designed as though it authoritatively know things that it cannot authoritatively assess.
I see the problem with SIP after 30s of reviewing the RFC. Right there in Fig. 1... it tells the remote end how to connect back. That will not work reliably - period. NAT or not. The SIP client is picking an interface/hostname (at random) and feeding it to the remote client. For any machine that has more than one NIC, there exists the possibility the client will pick the wrong interface.
I have never seen an application with the necessary logic to correctly determine what INADDR_ANY should be for a remote client. Most simply pluck the hostname from the system (and to my surprise, not always with gethostname()!) and either send that or lookup the address and send that. Those that try (and fail) to be smart and fetch a list of interfaces, never bother to look at the route table to use the correct interface. (on linux they'd have to look through any rules as well.)
NAT is not the evil here. The protocol itself demands clear, unobstructed communications between peers. This is extremely unlikely on the internet. And that's not going to change. If your NAT and/or FW device is not SIP aware, you will have problems. It's not NAT or the firewall's fault the protocol was designed this way. The designers of the protocol are to blame for not concidering the existing medium through which it would have to work -- NAT and firewalls have been around much longer than SIP. (the truth is, SIP was never intended to cross these network boundries.)
I just silently starting banging my head on the table when this was revealed to me.
53byte cells are the "grand unifying theory" of why designing by committee is Stupid(tm).
Why 53? Because several manufacturers had already made competing ATM equipment prior to any standard. Some were 32byte cells, others were 64. So, in an infinitely stupid move to give neither an upper hand, the standard is 53bytes; they all had to redesign their gear.
Ok, list me the firewalls that are IPv6 capable. Linux/*BSD/etc. are OSes, not firewalls; they can be used to build a firewall, but are not, themselves, "a firewall." I'm looking for things you can tell your grandmother to buy and plug in as simply as all the linksys and netgear "cable routers". (which aren't firewalls, but do play one on TV.)
[see also: my recent comment]
I do see that I said worst case. We don't have 2^20 route entries right now (and actually cannot with reserved space, multicast, etc.) Nor will we actually ever see 2^64 IPv6 prefixes. (certainly not within my lifetime, I hope.) The original commenter has missed the point of "more address space": more people will have globally routed networks. That means more prefixes, not less. Route aggregation will only go so far; depending on it is more of a "kludge" than IPv4 NAT.
And routers will have to handle all 128bits in their tables -- there could be network tables and more detailed sub-network tables, but as the wizard says "that's another story" -- otherwise you've hardcoded the IPv6 landscape into a classful corner (and thus doomed yourself to repeating the lessons (not) learned from IPv4.)
HAH! Planning a global routing hierarchy. Excuse me while I get the Dr. Pepper out of my nose. First off, you'll never get the entire world to agree on a numbering plan. And second, you'll never be able to enforce it. Besides, the IPv6 design already poopoo's on such things... address assignments are portable -- to avoid the issues of renumbering when changing ISPs.
What matters is whether you can reduce the *number* of routing entries by a few factors.
/20 (or larger) from a RIR which they annouce globally as the /20 "supernet". Internally, they can break that address space all the way down to /32's if they want; the rest of the world will still only see one prefix. The only difference with IPv6 is that the prefixes are 4x larger. (32 x 4 = 128)
Except you will not be reducing the number of prefixes. They will increase. This is a fundamental point to creating a larger address space: more people can have globally routed networks.
Hierarchtical routing is one of those things that look good on paper. But they never quiet live up to promise in the real world. The IPv4 world calls this route aggregation. It takes significant planning, and it's very hard to maintain over time. One of the points of IPv6 is that people are assigned addresses that are "theirs", forever; they can take them to any provider, any where and they'll work. That is completely impossible within a hierarchtical routing scheme. If you're very lucky, you can keep people within various hierarchtical prefixes, but that'll be through shear, blind, luck.
Just to give you an example...
Ding. ISPs already do this with IPv4 addresses. They are assigned a
IPv6 will not magically flatten people's network infrastructures. If a company has 40 networks (subnets) internally using IPv4, they'll very likely have the exact same 40 networks using IPv6. [think hub-and-spoke for a bunch of offices.] The number of prefixs within the company will not change; the the hub will still have 40 networks in it's tables and each spoke will still have the same default route in it's tables. However, the memory used for those prefixes will increase by a factor of 4 because the addresses are now 128bits.
I'll have to spy on my Cisco router and see how it's doing this very thing. I have two networks on the same interface and dhcp pools within them. It happly hands out addresses from the first pool until full and then hands out addresses from the second pool. And all my machines work just fine.
Maybe ISC's server just isn't coded to handle something odd like this.
32bit address space -> 128bit address space, and the route table is supposed to be smaller?!
/24. (nothing smaller than that is globally routable. And /20 is all you're required to support.) So, the current IPv4 route table could be as large as 2^24 elements, worst case. IPv6 uses a 64bit network address, so the IPv6 route table could be as large as 2^64 elements, worst case. Let's see, that's 2^40 times MORE table entries, plus the increased sizes of the addresses within the table themselves (which are 4x larger.)
For IPv4, the minimum prefix length is
IPv6 will, in fact, greatly increase the size of everyone's route tables. The size of the data within the table is 4x larger. And there will be more route prefixes, not less, in global routing tables. [that is, after all, the whole point of *more address space*.]
Firewall rules on the router would prevent machines on the "public" subnet from accessing systems on the "private" subnet
...if you have IP aliases on Linux (e.g. eth0 and eth0:0)...
:ip addr show dev eth1 :ip addr add 10.1.0.1/24 dev eth1 :ip addr show dev eth1
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.
Don't use interface aliases. iproute2 can assign multiple addresses to one nic:
[root:pts/1{1}]master:~/[01:48 PM]
3: eth1: mtu 1500 qdisc pfifo_fast qlen 1000
link/ether 00:e0:81:25:d1:ad brd ff:ff:ff:ff:ff:ff
inet 10.0.0.1/24 brd 10.0.0.255 scope global eth1
[root:pts/1{1}]master:~/[01:48 PM]
[root:pts/1{1}]master:~/[01:49 PM]
3: eth1: mtu 1500 qdisc pfifo_fast qlen 1000
link/ether 00:e0:81:25:d1:ad brd ff:ff:ff:ff:ff:ff
inet 10.0.0.1/24 brd 10.0.0.255 scope global eth1
inet 10.1.0.1/24 scope global eth1
Yes, he was... "it should be whipped thoroughly with multiple passes of random data (to avoid data recovery though forensics techniques)." Forensic data recovery IS DIFFICULT . Anyone who says otherwise doesn't know what they are talking about.
Once a new stream of bits has been written to a sector, it takes highly specialized tools to even attempt reading back the previous layers. That information is now noise. Hard drives are not designed to read that noise. (add in modern day high density technologies -- GMR, multiple pickups, proprietary modulations, proprietary error correction, 10-15k rpm speeds, super high aerial densities, etc. -- and it's beyond the reach of "common folk" and way out of reach of poor students.) The few companies that specialize in this sort of thing have all manner of toys for reading back all sorts of stuff from the platters -- custom hard drive circuit boards, custom firmware, precision magnetic read heads, powerful recovery software (to make sense of the noise), etc.
Let's see you read between tracks using the factory hardware and firmware. Even reading remapped sectors can be difficult -- most drives will not return defective data under any circumstances.
All this crap about DoD data security proceedures is laughable paranoia. 99.999999% of the hard drives on Earth don't have anything worth recovering. And that includes many of the hard drives used by various governments. Even the DoD knows the only way to be 100% certain the data is deleted is to physically destroy the drive. I guess people skip right over that -- any drive that has ever held "Top Secret" data must be destroyed - period; it cannot be declassified.
So there will be a "hydrino collection bottle(tm)" on the heater that's used to fuel the air conditioner?
This stinks like cold-fusion with a paladium rod.
You're a student... go get a few years of *realworld* experience under your belt before running off at the mouth. Books are a good thing. And theory is nice. But reality is always different.
Give me physical access to a computer of an IT staff member who has reasonable levels of access and I will be able to compromise the entire network; period.
Bold statements from someone who probablly couldn't follow through on it. (And if you did, you'd be fired on the spot.) You seem to think the admin's computer is the key to the kingdom. The machine is merely a way to get there -- like a car, any car will do. The passwords the admin knows (or has secured somewhere) is what gets them into various resources. You'd be better off stealing every scrap of paper in their office; admins are much more likely to write down a password as put it in a file somewhere.
If I have physical access to a computer it is mine...
This is partially true. Given physical access, no amount of security will protect the information forever. It's a race against the clock... how long before the owner comes back? How long before someone notices you under the desk? How long before someone notices the machine isn't online? How long before people notice the machine isn't there anymore? How long before any possibly compromised security information is invalidated?
Even a small amount of protection will secure a machine that you cannot take. There's only so much time you can spend under someone's desk before you're caught. Taking the computer apart (eg. to clear a BIOS password) is a clear sign of mischef.
So I go away for an hour or two, come back, retrieve my external HD and there is no way to detect I ever accessed that disk.
While true, they wouldn't know the disk had been accessed, it would be easy to tell the machine had been restarted. And even how long it had been down. And if it had been shutdown properly. etc. etc. Doctoring those records can be troublesome -- they might not even be on that box.
Any, and I stress this: Any computer terminal that is not physically secured should be a diskless workstation...
Ok. Now you're just being an idiot. How many times does the computer industry have to learn the same damned lesson? F'ing terminals... *sigh* Where the hell do you go to school? Did they not teach you anything about computing history?
Even diskless workstations have to have files stored somewhere. And since it's accessing them remotely, it's pretty easy to watch the wire for what you want. (it's not likely to be (strongly) encrypted.) Or just impersonate the workstation. Or steal the fileserver.
Forensic recovery of a hard drive is very difficult and *expensive*. It's not a process any random hacker can do in their basement. Some random schmuck is not going to spend 100k$ to recover a few useless passwords, documents, etc. Nothing any of us do is that valuable. (military installations aside. 'tho an interesting read, most of what they do isn't worth the trouble either.)
Or as a friend of my recounts... a sledge and a broom :-) They smashed the drive, flattened the platers into tissue paper, and swept the mess into the MED. Good luck recovering that.
What's this about "no waste"? If he's creating what he's claiming, "hydrinos", then he's partially collapsing a hydrogen atom. Once it's collapsed and thus energy released, it'll take energy to get it back to normal.
The hydrino's being created from the process(es) ARE the waste product. What the hell are you going to do with collapsed hydrogen atoms? They won't behave like normal hyrdogen; compounds created from them won't behave in expected ways. What's he going to do, cycle hydrino's through the "reactor" until they've collapsed into a neutron? Then what's to come of these free floating neutrons? (neutrons don't stay neutrons when they're all alone.)
For my money, I think this guy slept through every physics class he's ever taken.