- Test - lists.nanog.org

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

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

07 Sep '01

Hello all, In the recent multi-homing dicussions, many references were made, both public and private, to encouraging NAT and NAT techniques, in implementing local multi-homing. To be honest, even though I've used NAT myself and have implemented NAT for friends and clients, I would NEVER represent that a NAT'd address has the full connectivity to the Internet that a static address does. I've had many people ask me why. I've even gotten some hate-mail from members of this forum over this. The attached message is one instance-proof of where NAT is deficient. If you are selling transit and you are going to NAT them, then you cannot tell them that they have access to the full internet. There is a *lot* of stuff that will not transition a NAT boundary. A business that requires direct Internet access can't use NAT at the border. A business that delivers services to the internet can't use NAT, for their application servers, at all. BTW, I apologize if the subject-line appears inflammatory. |> -----Original Message----- |> From: ceo(a)vany.org [mailto:ceo@vany.org] |> Sent: Wednesday, September 05, 2001 10:39 AM |> To: announce(a)icann-ncc.org; ga(a)dnso.org |> Subject: [ga] Announcement: Invitation to remote participation in |> Non-Commercial Domain Names Holders Constituency in Montevideo |> |> |> The NCDNHC invites to all interested not able to attend our |> meeting in |> Montevideo to join us online. |> |> The meeting will be held on September 7 from 9:30 a.m. to |> 2:00 p.m local |> time (UTC -3). |> |> Details on remote participation are as follow: |> |> 1. Remote participation will be done through the VRVS system. To |> access it please browse http://www.vrvs.org |> 2. The Videoconference will take place in the Virtual Room Neptune, |> accesible from the World Wide Virtual Rooms. |> 3. To download the necessary software please access the |> DOWNLOAD sections at http://www.vrvs.org/ftp/ftp.html. All |> software is |> free of use |> 4. To learn more about how to use the VRVS tools, please |> access the DOC |> section at http://www.vrvs.org/Doc/doc.html |> 5. Don't forget to register your machine in the VRVS before use any |> tool installed. |> |> Connectivity requisites: |> 1. A public fixed IP address |> 2. A LAN must not be behing a NAT (Network Address Translation) |> 3. Machines should be properly registered in the DNS |> system. If you |> don't know what is this, please contact your network administrator. |> 4. Dialup users also can use VRVS (it is suppoused that |> your ISP have |> their DNS correctely setted-up) |> 5. H323 clients as Netmeeting, Polycom, and others works also with |> VRVS. Please read the documentation for more details. |> |> IMPORTANT: Try the VRVS software several days before the meeting to |> make sure that everything works properly. For this purpose, Vany |> Martinez will be in a test virtual room named CAFE, accessible from |> World Wide virtual rooms on September 6 from 10:00 a.m. to |> 12:00 p.m. local time (UTC -3). |> |> For any futher inquiry, please address them directly to Vany |> Martinez at |> ceo(a)vany.org |> |> |> -- |> Nilda Vany Martinez Grajales |> Information Technology Specialist |> Sustainable Development Networking Programme/Panama |> e-mail: vany(a)sdnp.org.pa |> http://www.sdnp.org.pa |> |> Nilda Vany Martinez Grajales |> Information Technology Specialist |> Sustainable Development Networking Programme/Panama |> http://www.sdnp.org.pa |> e-mail: vany(a)sdnp.org.pa |> Tel: (507) 230-4011 ext 213 |> Tel: (507) 230-3455 |> Fax: (507) 230-3646 |> __________________________________________ |> Get your free domain name and domain-based |> e-mail from Namezero.com |> New! Namezero Plus domains now available. |> Find out more at: http://www.namezero.com |> |> -- |> This message was passed to you via the ga(a)dnso.org list. |> Send mail to majordomo(a)dnso.org to unsubscribe |> ("unsubscribe ga" in the body of the message). |> Archives at http://www.dnso.org/archives.html |>

6 5

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

07 Sep '01

|> From: Doug Clements [mailto:dsclements@linkline.com] |> Sent: Thursday, September 06, 2001 7:14 PM |> > A business that requires direct Internet access can't use |> > NAT at the border. |> |> Not true. While I expect you will take this as nitpicking, |> one:one NAT is very conveniently used for servers while |> one:many NAT can be used for generic workstation access |> while preserving a consistent LAN numbering scheme. |> Anything that a "full" internet connection gets you will |> also work with one:one NAT. Yes, one:one NAT has transitional uses. It is also good for many dial-up scenarios. But, it is not a full internet connection and users should be told so. |> > A business that delivers services to the internet can't |> use NAT, for their |> > application servers, at all. |> |> This is laughable. You're telling me that we can't use |> our Alteons or Arrowpoints that use NAT to provide |> (redundant and load balanced!) internet services? I |> guess we should just go back to the One Big Web Server |> days, and put all our MS SQL database servers out in |> "full" view of the internet. Now there's any idea. 'A' doesn't follow 'B'. Just because the app servers are visible, doesn't mean that the RDBMS servers have to be (and yes, I like F5's). That isn't even a NAT issue. The only RDBMS servers visible, on my LANs, are Oracle Enterprise Management servers and usually they are behind a VPN. There is no earthly reason to expose an RDBMS server to the internet. The only ones that need to see them are the (dual NIC) app servers and the VPN gateway. You can't run a IPSEC VPN from NAT'd space. But, we have gotten quite far from the original post, which was prompted by a scheme to implement multi-homing, using dual NAT interfaces (one to each provider). Thereby, allowing multi-homing without having to advertise the /24 in BGP. This makes a many:one relationship. Basically, you burn two static IP addrs for each host, just to avoid advertising the /24. That's 512 IP addrs where 255 would have done the job.

1 0