RE: IPv6...Fact or Fiction?
NAT is a broken idea, as are firewalls. Just because it works, doesn't change this.
I wouldn't call it broken. A band-aid solution perhaps but not broken. It does what it intended to do quite well. Gav --------- To unsubscribe from nznog, send email to majordomo(a)list.waikato.ac.nz where the body of your message reads: unsubscribe nznog
On Wed, Jul 18, 2001 at 12:51:34PM +1000, Gavin Cato wrote: I wouldn't call it broken. A band-aid solution perhaps but not broken. It does what it intended to do quite well. Fair enough... it's a technically evil hack that does happen to work most of the time. But its still a hack, and it makes IP work is ways it was never designed for, so sometimes bad stuff happens. --cw --------- To unsubscribe from nznog, send email to majordomo(a)list.waikato.ac.nz where the body of your message reads: unsubscribe nznog
Chris Wedgwood
Fair enough... it's a technically evil hack that does happen to work most of the time. But its still a hack, and it makes IP work is ways it was never designed for, so sometimes bad stuff happens.
Mostly it breaks in places where protocol layering is violated (e.g. putting a network address in the application layer), in which case it's going to break when you go to IPv6 (or any other protocol) anyway. It also doesn't work very well for peer-to-peer comms. But peer-to-peer comms are a problem when setting up any kind of firewall anyway. NAT/PNAT, along with other types of firewalls, recognises that between IP and TCP or UDP headers, there's 48 bits of address space, much of which is going to waste. It also recognises that "The Internet" doesn't need to include every single internal host, and that there should be a definite boundary between internal, non-public networks and the public Internet. Stop treating IP addresses as host addresses and the IP address space problem largely goes away. -- don --------- To unsubscribe from nznog, send email to majordomo(a)list.waikato.ac.nz where the body of your message reads: unsubscribe nznog
On Thu, Jul 19, 2001 at 09:01:17AM +1200, Don Stokes wrote: Mostly it breaks in places where protocol layering is violated (e.g. putting a network address in the application layer), in which case it's going to break when you go to IPv6 (or any other protocol) anyway. Well, for that there are even more evil hacks such as protocol helps most commonly for things like FTP and RTSP. The anal wanted-to-be-a-research-scientist-but-the-money-sucked retentive part of me finds the fact these systems are required to keep state in the middle of the connection disgusting. It's because of things you get timeouts and other such funnies caused by this horrible often poorly written state-machine in the middle trying to second guess the state of the two ends. TCP in particular was designed with a reasonable degree of care to ensure that you can mathematically validate various principals. To do so, there is logic which allows one state-machine to resynchronize if the other other one gets hosed, and for both state-machines to stay synchronized under a wide range of conditions. NAT completely stuffs this up. The most obvious example of this is TCP sessions die when they either time out or the NAT device looses state (e.g. nasty Nokia DSL modem crashes because it doesn't like packets with various '1323 extensions under load). It also doesn't work very well for peer-to-peer comms. But peer-to-peer comms are a problem when setting up any kind of firewall anyway. Firewalls are evil too. Arguably a necessary evil forced upon the world by legions of terrible application programmers and moderately inept system administrators, and also the fact that most of the critical protocols presently in use were designed during a much friendly Internet[1]. By biggest objection with firewalls and NAT devices is that the majority of the commercial ones out there suck. Checkpoint Firewall-1 is IN MY OPINION a terrible product. It's quirky, slow, extremely resource hungry, terribly buggy, with abysmal support quality. However, as almost everything else 'brand-name' commercially available is even worse, its very popular despite being horrendously expensive. The NAT implementation in cisco routers often supports only the most basic protocol helpers such as FTP, is again often buggy (heresy, I know, claiming IOS has bugs) and leaks memory like a sieve. If anyone has a Nokia DSL modem and spend a lot of time behind it with ssh session open, then you'll probably have noticed they crashed fairly often too. nmap will drop them dead too. Ironically, the average FreeBSD or Linux box is much quicker, cheaper, far less buggy, less resource intensive and has effectively much better support. Anyhow, this is getting way off topic.... --cw [1] Was it Vixie who said, "I want my old Internet back!" ??? --------- To unsubscribe from nznog, send email to majordomo(a)list.waikato.ac.nz where the body of your message reads: unsubscribe nznog
:: It's because of things you get timeouts and other such funnies caused :: by this horrible often poorly written state-machine in the middle :: trying to second guess the state of the two ends. TCP in particular :: was designed with a reasonable degree of care to ensure that you can :: mathematically validate various principals. To do so, there is logic :: which allows one state-machine to resynchronize if the other :: other one :: gets hosed, and for both state-machines to stay synchronized under a :: wide range of conditions. :: :: NAT completely stuffs this up. The most obvious example of this is :: TCP sessions die when they either time out or the NAT device looses :: state (e.g. nasty Nokia DSL modem crashes because it doesn't like :: packets with various '1323 extensions under load). The Cisco 827 doesn't suffer from NAT timeouts like the Nokia MW1122. -- Juha --------- To unsubscribe from nznog, send email to majordomo(a)list.waikato.ac.nz where the body of your message reads: unsubscribe nznog
The Cisco 827 doesn't suffer from NAT timeouts like the Nokia MW1122.
No, It just suffers an inability to deal with DSL defects. The first packet that it receives that's broken forces it to retrain. Talk about resilience. Cheers. James Tyson --- Samizdat New Media Solutions --------- To unsubscribe from nznog, send email to majordomo(a)list.waikato.ac.nz where the body of your message reads: unsubscribe nznog
The Cisco 827 doesn't suffer from NAT timeouts like the Nokia MW1122.
No, It just suffers an inability to deal with DSL defects. The first packet that it receives that's broken forces it to retrain. Talk about resilience.
I have noticed exactly the same thing with my Cisco 827. The Nokia outperforms the Cisco in terms of stability, but the Cisco outperforms the nokia with everything else. Simon Allard (Senior Tool Monkey) IHUG Ph (09) 358-5067 Email: simon.allard(a)staff.ihug.co.nz "There is no spoon" --------- To unsubscribe from nznog, send email to majordomo(a)list.waikato.ac.nz where the body of your message reads: unsubscribe nznog
:: I have noticed exactly the same thing with my Cisco 827. The Nokia :: outperforms the Cisco in terms of stability, but the Cisco :: outperforms :: the nokia with everything else. Yes, yes, but what does that mean? Details, man, details. ;-) I have found that with either the Nokia MW1122 and the Cisco 827 plugged in, my Jetstream connection suffers from "micro outages", usually once a day. It'd be interesting to discover if these outages are caused by the adapter or by a fault/flaw in Jetstream. Here's what the 827 logs: Jul 12 03:00:16 router 23: Jul 12 03:00:16.373 NZ: %LINK-3-UPDOWN: Interface ATM0, changed state to down Jul 12 03:00:16 router 24: Jul 12 03:00:16.381 NZ: %LINK-3-UPDOWN: Interface Virtual-Access1, changed state to down Jul 12 03:00:17 router 25: Jul 12 03:00:16.421 NZ: %DIALER-6-UNBIND: Interface Vi1 unbound from profile Di0 Jul 12 03:00:18 router 26: Jul 12 03:00:17.373 NZ: %LINEPROTO-5-UPDOWN: Line protocol on Interface ATM0, changed state to down Jul 12 03:00:18 router 27: Jul 12 03:00:17.381 NZ: %LINEPROTO-5-UPDOWN: Line protocol on Interface Virtual-Access1, changed state to down Jul 12 03:00:36 router 28: Jul 12 03:00:36.413 NZ: %LINK-3-UPDOWN: Interface Virtual-Access1, changed state to up Jul 12 03:00:36 router 29: Jul 12 03:00:36.413 NZ: %DIALER-6-BIND: Interface Vi1 bound to profile Di0 Jul 12 03:00:37 router 30: Jul 12 03:00:36.897 NZ: %LINK-3-UPDOWN: Interface ATM0, changed state to up Jul 12 03:00:37 router 31: Jul 12 03:00:37.897 NZ: %LINEPROTO-5-UPDOWN: Line protocol on Interface ATM0, changed state to up Jul 12 03:00:58 router 32: Jul 12 03:00:57.461 NZ: %LINEPROTO-5-UPDOWN: Line protocol on Interface Virtual-Access1, changed state to up -- Juha --------- To unsubscribe from nznog, send email to majordomo(a)list.waikato.ac.nz where the body of your message reads: unsubscribe nznog
Yes, yes, but what does that mean? Details, man, details. ;-)
I have found that with either the Nokia MW1122 and the Cisco 827 plugged in, my Jetstream connection suffers from "micro outages", usually once a day. It'd be interesting to discover if these outages are caused by the adapter or by a fault/flaw in Jetstream.
Here's what the 827 logs:
Jul 12 03:00:16 router 23: Jul 12 03:00:16.373 NZ: %LINK-3-UPDOWN: Interface ATM0, changed state to down Jul 12 03:00:16 router 24: Jul 12 03:00:16.381 NZ: %LINK-3-UPDOWN: Interface Virtual-Access1, changed state to down
<snip /> Juha, Try "debug atm errors" and email me the output - I'll bet your getting the same thing as me. Cheers. James Tyson --- Samizdat New Media Solutions --------- To unsubscribe from nznog, send email to majordomo(a)list.waikato.ac.nz where the body of your message reads: unsubscribe nznog
I see exactly that. But I see it quite often, say 3-4 times a day. The Nokia would only do it 1 time a day, if that. As James Tyson said, we should compare debug atm errors to see if thats the problem.
Jul 12 03:00:16 router 23: Jul 12 03:00:16.373 NZ: %LINK-3-UPDOWN: Interface ATM0, changed state to down Jul 12 03:00:16 router 24: Jul 12 03:00:16.381 NZ: %LINK-3-UPDOWN: Interface Virtual-Access1, changed state to down Jul 12 03:00:17 router 25: Jul 12 03:00:16.421 NZ: %DIALER-6-UNBIND: Interface Vi1 unbound from profile Di0 Jul 12 03:00:18 router 26: Jul 12 03:00:17.373 NZ: %LINEPROTO-5-UPDOWN: Line protocol on Interface ATM0, changed state to down Jul 12 03:00:18 router 27: Jul 12 03:00:17.381 NZ: %LINEPROTO-5-UPDOWN: Line protocol on Interface Virtual-Access1, changed state to down Jul 12 03:00:36 router 28: Jul 12 03:00:36.413 NZ: %LINK-3-UPDOWN: Interface Virtual-Access1, changed state to up Jul 12 03:00:36 router 29: Jul 12 03:00:36.413 NZ: %DIALER-6-BIND: Interface Vi1 bound to profile Di0 Jul 12 03:00:37 router 30: Jul 12 03:00:36.897 NZ: %LINK-3-UPDOWN: Interface ATM0, changed state to up Jul 12 03:00:37 router 31: Jul 12 03:00:37.897 NZ: %LINEPROTO-5-UPDOWN: Line protocol on Interface ATM0, changed state to up Jul 12 03:00:58 router 32: Jul 12 03:00:57.461 NZ: %LINEPROTO-5-UPDOWN: Line protocol on Interface Virtual-Access1, changed state to up
-- Juha
--------- To unsubscribe from nznog, send email to majordomo(a)list.waikato.ac.nz where the body of your message reads: unsubscribe nznog
Simon Allard (Senior Tool Monkey) IHUG Ph (09) 358-5067 Email: simon.allard(a)staff.ihug.co.nz "There is no spoon" --------- To unsubscribe from nznog, send email to majordomo(a)list.waikato.ac.nz where the body of your message reads: unsubscribe nznog
:: No, It just suffers an inability to deal with DSL defects. The first :: packet that it receives that's broken forces it to retrain. :: Talk about :: resilience. Eh? Can you elaborate? -- Juha --------- To unsubscribe from nznog, send email to majordomo(a)list.waikato.ac.nz where the body of your message reads: unsubscribe nznog
:: No, It just suffers an inability to deal with DSL defects. The first :: packet that it receives that's broken forces it to retrain. :: Talk about :: resilience.
Eh? Can you elaborate?
From looking at the debug logs it would seem that as soon as it recieves a
The 827 I am using at home is excellent in terms of features, but just cant stay up for more than 15 minutes at a time, it's constantly retraining. With an M1122 it stays online rock-solid 24 hours a day, 7 days a week. packet from the DSL that contains an error (does anyone know if aal5 uses CRC?) then it immediately drops the connection and retrains. The Nokia seems to wait until there is a signifigant number of errors - I mean when a line rate of 8Mb and a CIR of 128kb, it's not like I'm on a retransmit budget. Cheers. James Tyson --- Samizdat New Media Solutions --------- To unsubscribe from nznog, send email to majordomo(a)list.waikato.ac.nz where the body of your message reads: unsubscribe nznog
On Thu, Jul 19, 2001 at 10:07:55AM +1200, James Tyson wrote: From looking at the debug logs it would seem that as soon as it recieves a packet from the DSL that contains an error (does anyone know if aal5 uses CRC?) then it immediately drops the connection and retrains. The Nokia seems to wait until there is a signifigant number of errors - I mean when a line rate of 8Mb and a CIR of 128kb, it's not like I'm on a retransmit budget. The CPCS-PDU trailer has a 4-byte checksum. --cw --------- To unsubscribe from nznog, send email to majordomo(a)list.waikato.ac.nz where the body of your message reads: unsubscribe nznog
On Thu, Jul 19, 2001 at 09:42:50AM +1200, Juha Saarinen wrote: The Cisco 827 doesn't suffer from NAT timeouts like the Nokia MW1122. Actually, the 1122 with a new secret software load seems much more reliable. Certain protocols (eg. telnet and ssh) don't seen to time out for 86400 seconds or so (or maybe never with some kind of LRU replacement, not sure). <pause> tapu:~# nmap -O 192.168.1.254 Starting nmap V. 2.54BETA22 ( www.insecure.org/nmap/ ) Interesting ports on dsl-gw (192.168.1.254): (The 1539 ports scanned but not shown below are in state: closed) Port State Service 23/tcp open telnet 80/tcp open http 1723/tcp open pptp Remote operating system guess: Cisco Catalyst 1900 switch or Netopia DSL/ISDN router or Bay 350-450 software is several releases newer than what was previously there and I have no idea how long before this release will make it into general circulation (perhaps it is already, anyone know what is current?). --cw --------- To unsubscribe from nznog, send email to majordomo(a)list.waikato.ac.nz where the body of your message reads: unsubscribe nznog
(Yeah, we are getting off topic a little ... at least it's not about
Si's desk ...)
Chris Wedgwood
On Thu, Jul 19, 2001 at 09:01:17AM +1200, Don Stokes wrote:
Mostly it breaks in places where protocol layering is violated (e.g. putting a network address in the application layer), in which case it's going to break when you go to IPv6 (or any other protocol) anyway.
Well, for that there are even more evil hacks such as protocol helps most commonly for things like FTP and RTSP.
Well, the fact there exists duct tape to put over broken things doesn't alter the fact they're broken. And I have well-documented gripes about FTP and its PORT command, http://www.daedalus.co.nz/~don/ftp.html ...
It's because of things you get timeouts and other such funnies caused by this horrible often poorly written state-machine in the middle trying to second guess the state of the two ends. TCP in particular was designed with a reasonable degree of care to ensure that you can mathematically validate various principals. To do so, there is logic which allows one state-machine to resynchronize if the other other one gets hosed, and for both state-machines to stay synchronized under a wide range of conditions.
NAT completely stuffs this up. The most obvious example of this is TCP sessions die when they either time out or the NAT device looses state (e.g. nasty Nokia DSL modem crashes because it doesn't like packets with various '1323 extensions under load).
Well, we went around this question on the ADSL mailing list a month or four ago. Basically, if you have a long enough timeout on your NAT, it shouldn't be an issue, especially if you have TCP keepalives turned on. (Bear in mind that TCP sessions closing are also used to clean up NAT entries; timeouts are only necessary to clean up TCP NAT entries left over by abnormal terminations of connections. UDP is of course more problematic, but UDP based applications tend to be less inclined to keep state around for long periods.) Secondly, NAT mappings should be able to survive an interface transient, although if it negotiates a new IP address, those entries won't be of much use. And there's no reason why an interface transient should cause a new address to be assigned; a sensible RADIUS server should be able to re-assign an address if it's available. Router crashes are a pain. Some NAT implementations are smart enough to create new NAT entries from existing connections, although the packet that triggers them has to originate from the inside for this to work. But routers *shouldn't* crash...
By biggest objection with firewalls and NAT devices is that the majority of the commercial ones out there suck. Checkpoint Firewall-1 is IN MY OPINION a terrible product. It's quirky, slow, extremely resource hungry, terribly buggy, with abysmal support quality. However, as almost everything else 'brand-name' commercially available is even worse, its very popular despite being horrendously expensive.
After careful study (i.e. I still have the brickwork impressions on my forehead), I came to the conclusion that there exists a list of priorities for Firewall-1, of which the first ten entries are "Make Checkpoint more money". "Internet security" is well down the list, and customer satisfaction doesn't register at all. Has anyone succeeded in getting additional licenses out of Checkpoint in any semblance or reasonable time? Still, the fact that certain implementations of a thing are buggy or badly designed or sold by robbers doesn't make the thing inherently bad. In any case, it's not a question of whether NAT (and firewalls) is a nice solution or not. It's a fact that NAT *is* a solution (albeit one that comes with its own problems), and one that doesn't involve changing software on hundreds of millions of computers.
[1] Was it Vixie who said, "I want my old Internet back!" ???
The Internet is FULL! GO AWAY! (Joel Furr T-shirt from 1995) -- don --------- To unsubscribe from nznog, send email to majordomo(a)list.waikato.ac.nz where the body of your message reads: unsubscribe nznog
participants (6)
-
Chris Wedgwood -
Don Stokes -
Gavin Cato -
James Tyson -
Juha Saarinen -
Simon Allard