September 2001 - Test - lists.nanog.org

RE: end2end? (was: RE: Where NAT disenfranchises the end-user ... )
by Roeland Meyer 07 Sep '01

07 Sep '01

|> From: Jon Mansey [mailto:jon_mansey@verestar.com] |> Sent: Friday, September 07, 2001 11:57 AM |> |> I seem to be able to connect to port-forwarded services behind my |> office NAT firewall just fine from my laptop behind my home NAT box. |> Whats the problem? Can we talk ... using NetMeeting?

3 2

RE: Where NAT disenfranchises the end-user ...
by Roeland Meyer 07 Sep '01

07 Sep '01

|> From: Jim Shankland [mailto:nanog@shankland.org] |> Sent: Friday, September 07, 2001 11:33 AM |> "Mike Batchelor" <mikebat(a)tmcs.net> writes: |> |> > Oh yes, the firewall. That convenient device that network software |> > developers can assume will always pass port 80 and 443 traffic. So |> > everything uses port 80 and 443 in the future Internet, |> and we're all the |> > better for it. |> |> Um, sure, but what are you arguing? That firewalls are useless and |> should all go away? (Good luck.) That firewalls don't |> really exist :-)? Actually, for the ports that they have proxyd for, they don't. It's called "transparency", one of those fundimentaly concepts. The ports that they block, are supposed to be blocked, by design and not by accident. Firewalls are deterministic, NAT boundaries aren't. |> Maybe it would be useful to design a base protocol that would |> provide a standardized method for things like passing an <address, |> port> tuple, or registering a desire to receive packets on a |> particular UDP port -- the kind of things that gamers, e.g., |> want, and |> that are tricky to make work through a NAT. Games, etc., could be |> written on top of this base protocol, and NATs and firewalls could |> be made to be aware of that protocol. Just a thought; any |> merit to it? You've just described a NAT proxy daemon. I've spent years trying to write one. If you are that good, send code. Or better yet, send it to www.sourceforge.org. The fundimental reason that you can't write one is that it requires a whole other protocol that 1) deosn't exist, 2)Isn't implemented, 3)Violates more than one of Dykstra's laws.

1 0

RE: Where NAT disenfranchises the end-user ...
by Jim Shankland 07 Sep '01

07 Sep '01

"Mike Batchelor" <mikebat(a)tmcs.net> writes: > Oh yes, the firewall. That convenient device that network software > developers can assume will always pass port 80 and 443 traffic. So > everything uses port 80 and 443 in the future Internet, and we're all the > better for it. Um, sure, but what are you arguing? That firewalls are useless and should all go away? (Good luck.) That firewalls don't really exist :-)? I'm simply saying that those who cite the "fundamental principle of end-to-end connectivity" are describing a world that does not, in fact, exist today; and that reality appears to be diverging from, rather than converging toward, that world. Pretending that NAT and firewalls don't exist, and hectoring the world to change, in the name of a "fundamental principle", isn't going to work -- at least, that's my humble prediction :-). Maybe it would be useful to design a base protocol that would provide a standardized method for things like passing an <address, port> tuple, or registering a desire to receive packets on a particular UDP port -- the kind of things that gamers, e.g., want, and that are tricky to make work through a NAT. Games, etc., could be written on top of this base protocol, and NATs and firewalls could be made to be aware of that protocol. Just a thought; any merit to it? Jim Shankland

1 0

RE: Where NAT disenfranchises the end-user ...
by Roeland Meyer 07 Sep '01

07 Sep '01

|> From: Jon Mansey [mailto:jon_mansey@verestar.com] |> Sent: Friday, September 07, 2001 10:26 AM |> |> It seems a pretty simple argument to me. |> |> Do I want as many people using (and maybe _buying_, what a concept!) |> my app as possible with the least amount of network clue and setup |> headaches, or do I want to eliminate most of the corporate, SOHO, |> cable, DSL, Linux population because I cant be bothered to |> develop my app to be NAT-friendly. |> |> Duh! Since when, is an app supposed to care what's in the middle? Even firewalls are supported by middle-ware. NAT boundaries aren't. That's because NAT boundaries are unpredictable in both presence and character. As the man said, there is no NATpd so the end-points have to do all the work. Note that, it is the *only* boundary method where this is so. This is the fundimental reason that NAT is architectural fubar. |> All the previous times this discussion has arisen here, I have |> concluded that "real" IPs should only be owned and used by |> folks with clue, everyone else gets a NATed IP. Discuss. I sincerely hope that you are not telling your customers that they have full internet access. Also, is a quiz required to be a customer of yours? Is it a standardized test? Most customers, given such an opportunity, will find another ISP. They don't know, they don't want to know, and they will find someone that won't make them know.

1 0

Closest Exit Routing Decisions
by David McGaugh 07 Sep '01

07 Sep '01

Hello All, Question. For those who have networks supporting closest exit routing, which means are being used to influence the closest exit decision? ie. IGP metrics, IBGP internal MEDs, etc. Also for those using IGP metrics, which IGP is being used. Cheers, Dave

1 0

web pages not loading (from certain networks) but not a routing i ssue.
by Nanog 07 Sep '01

07 Sep '01

Ok guys, Interesting problem that seems to have started on Friday. Here's the deal, it seems that certain (not all) web pages on various sites we host are not loading for certain customers. It started on Friday with visitors on Verizon DSL waiting forever for pages to load. Yesterday and today PacBell DSL and some Netcom customers started complaining. This only seems to occur on HTTP traffic. If we have the visitors try HTTPS the pages load fine (with the normal encryption slowdown). We've looked at Layers 1-4, and can't see any problems, ping looks great, interfaces and cpus on routers, servers and switches look fine. It's almost like it's a transparent cache "bug". Anyone know if Inktomi, or any major cache vendors rolled out any new code this week? For that matter does anyone know what caches Verizon and SBC use for starters? Other variables: it only seems to occur on IIS based systems (I know I know, no flame wars or suggestions for replacements). Although it's not happening on all of our IIS servers. Any clues are greatly appreciated. Steve

2 1

RE: web pages not loading (from certain networks) but not a routi ng i ssue.
by Young, Jason 07 Sep '01

07 Sep '01

This reeks of an MTU problem somewhere. Did you happen to have ICMP filtered to/from your sites recently? Remember, ICMP isn't just that protocol that lets you ping stuff. You may have broken path MTU discovery. Jason Young CNS - Network Design, Anheuser-Busch (314)577-4597 > -----Original Message----- > From: Nanog [mailto:Nanog@exchange.ware.net] > Sent: Friday, September 07, 2001 9:52 AM > To: nanog(a)merit.edu > Subject: web pages not loading (from certain networks) but > not a routing > i ssue. > > > > Ok guys, > > Interesting problem that seems to have started on Friday. > > Here's the deal, it seems that certain (not all) web pages on > various sites > we host are not loading for certain customers. It started on > Friday with > visitors on Verizon DSL waiting forever for pages to load. > > Yesterday and today PacBell DSL and some Netcom customers started > complaining. > > This only seems to occur on HTTP traffic. If we have the > visitors try HTTPS > the pages load fine (with the normal encryption slowdown). > > We've looked at Layers 1-4, and can't see any problems, ping > looks great, > interfaces and cpus on routers, servers and switches look fine. > > It's almost like it's a transparent cache "bug". Anyone know > if Inktomi, or > any major cache vendors rolled out any new code this week? > > For that matter does anyone know what caches Verizon and SBC use for > starters? > > Other variables: it only seems to occur on IIS based systems > (I know I know, > no flame wars or suggestions for replacements). Although it's > not happening > on all of our IIS servers. > > Any clues are greatly appreciated. > > Steve > >

1 0

B-STDX S/W peculiarities
by Brian Wallingford 07 Sep '01

07 Sep '01

Short and sweet - if anyone would be willing to discuss certain peculiarities (specifically IP-based issues when interoperating w/Cisco in the core), I'd appreciate a private email. Pending responses and interest, I'll summarize later. cheers, brian

3 3

RE: Where NAT disenfranchises the end-user ...
by Roeland Meyer 07 Sep '01

07 Sep '01

|> From: David Howe [mailto:DaveHowe@gmx.co.uk] |> Sent: Thursday, September 06, 2001 5:54 PM |> |> > Or more completely, they expect the network to be |> > transparent so that every port at the destination IP |> > address connects to the same machine, and there |> > is no operational restriction on which end initiates |> > the communication. Absolutely true. I'll take that clarification. |> which of course *is* possible for at least one machine per visible IP |> address - even if additional IPs are masqed behind it. if you are doing one:one NAT then why do NAT at all? if you are doing one:many then it won't work (broken).

4 3

Re: Where NAT disenfranchises the end-user ...
by Bob K 07 Sep '01

07 Sep '01

> > ...except current implementations of IPSEC: > > > > http://www.isp-planet.com/technology/2001/ipsec_nat.html > > > > Luckily, the above article also mentions the fixes that are in the > > works... On Thu, 6 Sep 2001, Bora Akyol wrote: > Bob > I am not supporting NAT here, but > most common IPSEC implementations including Free S/WAN work fine behind > NAT. > > Bora I stand corrected after perusing http://jixen.tripod.com/#NATed%20gateways - although I'm not sure I'd describe that as working "fine", but rather "can be made to work, in a narrow set of circumstances". It should be noted that the Free S/WAN docs explicitly recommend against trying it. -- Bob <melange(a)yip.org> | Yes. I know. That is, indeed, *not* mayonnaise.

1 0