RE: Racoon Problem & Cisco Tunnel

From: Ted Mittelstaedt (tedm@toybox.placo.com)
Date: 03/13/01 

From: "Ted Mittelstaedt" <tedm@toybox.placo.com>
To: "James Wyatt" <jwyatt@rwsystems.net>
Date: Tue, 13 Mar 2001 08:58:14 -0800

>-----Original Message-----
>From: owner-freebsd-questions@FreeBSD.ORG
>[mailto:owner-freebsd-questions@FreeBSD.ORG]On Behalf Of James Wyatt
>
>NAT is a tool and you can hurt yourself with it or do useful things with
>it, not an aberration or silver-bullet. Folks with fast hosts or small
>amounts of traffic and simple needs love it - especially home broadband
>users. There is a trade-off for many router users though: a) just change
>the header when NAT-ting, or b) correct the packet checksums and lose your
>ASIC efficiency and kill your shared-CPU. NAT can also make peer-to-peer
>networking for groups of workstations across NAT barriers difficult if you
>have to chew-up static IPs from what I can tell.
>
>Many large corporations like GE Corp have huge RFC networks internally. If
>you ever have to make an internal Frame Relay link between them behind
>their public firewalls, you will learn new words for describing RFC
>networking limitations. "Oh &$*^^%! Our router thinks their Chicago server
>is on the same LAN segment as our Fort Worth server, but with a different
>netmask.

So what? Different netmasks create different subnets. It's perfectly
fine to have 2 different subnets on the same segment.

Now, if your using the word "segment" to mean something other than a
physical segment, but rather to mean "subnet" then your statement is
impossible. If both systems have different netmasks (and not the same IP
addresses, of course) then it's impossible for them to be on the same
subnet. Same physical segment, yes, but not the same subnet.

> Which of us should renumber our servers?

Neither. Sites that are geographically distant should be on separate
subnets.

>
>When IPv4 was designed, everyone could have had their own number. It was
>done a *long* time ago, and did not envision "The Internet Explosion".
>Everyone else has just followed the specs so things interoperated. If
>those "idiot engineers" hadn't done that, you wouldn't have equipment
>coming out your "*rse-h*le" today. (^_^)
>

The engineers that designed all that wern't idiots - as they emphasized
interoperability. If someone had come along back then and said "Let's
throw away the IPv4 scheme and replace it with IPv6 because we might run
out of numbers in the future" those engineers would have squashed that
on the interoperability altar.

>btw: If you stopped saying everyone else (including Vint Cerf, however
>misgiuded or misquoted) is an idiot fewer folks might miss your otherwise
>valid points.

I'm not. I'm saying that people that insist the problem is we haven't
all switched over to IPv6 are idiots. I'm also saying that engineers that
sit down TODAY at a blank drawing board, AFTER NAT IS A REALITY, and design
TCP/IP protocols that are incompatible with it are idiots.

The majority of Internet engineers are NOT in this group. There's a vocal
minority that is and are currently engaged in running around and telling
the majority that we are doing it wrong by using NAT.

 If I get it: "NAT works and IPv6 is still a *long* way off
>for many very strong commercial realities." I gotta mostly agree with
>that, but NAT has a price as well.
>

Any connectivity solution has a price. NAT's price is cheaper than
the price of renumbering the entire Internet to IPv6 and it will
remain so until we truly are out of numbers, not just dealing with
an artifical shortage. Sorry, but engineers that ignore this fiscal
reality are idiot dreamers in my opinion.

>I hate fudging checksums because, while they only cause a little more
>coding for script kiddies making fake- or poison-packet generators, they
>also help ENet reliability. There are more things hurting packets than
>just collisions.
>
>If the world ever decides to jump to IPv6, all the server folks have to
>renumber as well. How is this all supposed to happen without massive
>outages and downtime? - Jy@
>

The IPv6 crowd is trying to frame the question as "It's not whether or not
we are going to switch, it's when" I'm interested to see your framing the
question as "It's not when we are going to switch to IPv6, it's IF"

I'm not even saying that. All I'm saying is that there is a tremendous
amount that can be done to extend the lifetime of the current
infrastructure, that includes NAT, extracting large public blocks from
corporations that don't use them publically, and many other things.
I'm saying that it's likely that in our lifetimes that the Internet will NOT
be switched over to IPv6. But, I'm not saying that it will NEVER be.

Ted Mittelstaedt tedm@toybox.placo.com
Author of: The FreeBSD Corporate Networker's Guide
Book website: http://www.freebsd-corp-net-guide.com

To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-security" in the body of the message

Relevant Pages

  • RE: Racoon Problem & Cisco Tunnel
    ... Internet is going to have to go there. ... IPv4, IPv6, and NAT are ... My protocol developers have a few LANs at home and we happily use NAT there. ...
    (FreeBSD-Security)
  • Re: Racoon Problem & Cisco Tunnel
    ... NAT are all just tools that I have to apply with "business sense." ... not inherently evil, nor is IPv6. ... My protocol developers have a few LANs at home and we happily use NAT ...
    (FreeBSD-Security)
  • Re: Notifying user of open Internet access
    ... Windows won't have this problem anymore. ... NAT will be gone when the Internet goes to IPv6, ...
    (alt.computer.security)
  • Re: Cmaj Bmaj Vamp
    ... So your saying that the harmony doesn't work? ... What I'm saying is that having the F nat in the BGs the way you have it will influence the way a melodic improviser hears that chord, and to some degree the other chord as well. ... I finally learn a 2 full songs but only because I met some people that know a lot of songs and play them regularly and I can sit in and listen and play along, ...
    (rec.music.theory)
  • RE: Racoon Problem & Cisco Tunnel
    ... Interference with protocols like IPSec is one of the reasons ... When it comes to NAT, I'm with Vint Cerf--avoid it if at all ... Let's hasten the deployment of IPv6. ... large network from IPv4 to IPv6 had Vint Cerf's money. ...
    (FreeBSD-Security)
Quantcast