- NANOG - lists.nanog.org

Re: end2end? (was: RE: Where NAT disenfranchises the end-user ...)
by smd＠clock.org 07 Sep '01

07 Sep '01

| has *any* form of identity That IP overloads "who" and "what" into one value is a fatal flaw. NAT forces the IP address to indicate topological _location_ and is therefore good. Anyone who attempts to use a locator as an identifier is wrong-headed and deserves no sympathy on the grounds of, "well our forefathers were wrongheaded too!" and other arguments of that style. Sean.

2 1

Re: end2end? (was: RE: Where NAT disenfranchises the end-user ...)
by smd＠clock.org 07 Sep '01

07 Sep '01

I wrote: | That IP overloads "who" and "what" *Where* and what, or who and where, is what I meant, of course. Sean.

1 0

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 12:44 PM |> |> At 12:31 PM -0700 9/7/01, Roeland Meyer wrote: |> >|> 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? |> |> NM, along with IPsec are examples of apps that dont play well here, |> but thats the point, they are apps that have not been written with |> the real world in mind, ie that a good proportion of the edge these |> days is behind NAT. NAT is the first and only method (I won't dignify it by calling it a protocol) that munges the data. Most real protocols only mess with the envelope and leave the data strictly alone. With NAT, its snafu. Now, if we had bi-directional transparency, via a NAT proxyd, it wouldn't hurt so bad. But, such a daemon is impossible to write and, if written, is impossible to deploy. |> Who gives in first here, the app developers (or their marketing |> depts) who decide that supporting NAT is important, or the NAT |> developers who decide they can fix cuseeme or PPTP by re-writing the |> packet data? |> |> I am also playing devil's advocate here somewhat, we all know the |> real solution to lack of IPv4 space, true end2end, and security lies |> with IPv6, right? <grin> 1) Feigned IPv4 addr shortages were ameliorated by recovery of legacy IPv4 allocations (/8s). IMHO, too late to prevent us from doing NAT. 2) Routeing table sizes are a routing architecture problem that won't go away wrt IPv6. They will only get worse there. <personal opinion> Whomever shot down IPv6 imbedded routing, needs to be taken out and shot in turn. The counter-arguments were not convincing, IMHO. I thought it was a great idea. There is nothing inherently wrong with imbedding the routing into the protocol itself and it sure helps (a bunch) to standardize things. </personal opinion>

1 0

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

07 Sep '01

|> From: Jim Shankland [mailto:jas@parker.net] |> Sent: Friday, September 07, 2001 12:35 PM |> |> Roeland Meyer <rmeyer(a)mhsc.com> writes: |> |> > 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. |> |> Don't mean to nitpick, but I was describing no such thing. I was |> suggesting the development of a protocol. Saying that can't be done |> because the protocol "1) deosn't exist, 2)Isn't implemented" seems |> a little circular :-). Don't know which of Dijkstra's laws |> that might |> violate, either (except maybe "Don't misspell my name" :-)). I'm also dutch and should know better. However, neither can I type, as the quoted portion clearly shows. .. cna't spell, can't type, I must write code <g>. lint will save me. I'm also too terse for my own good, sometimes. Item 2 is looking forward to deployment. Adoption will be supremely difficult and unless universally adopted, it won't fly. It's a flash cut-over scenario with disparate implementors. Success is estimated at around 0.001%, in such cases. The law I am thinking of is the one where the application can't tell where the failure is until it fails. It is fundimentally unpredictable. |> The argument, roughly, is that there is a small set of operations |> (identifying an <ipaddr:port> tuple in a network-portable way, and |> dynamically allocating a new port to an application, are two |> that come |> to my mind) that make NAT and firewalls difficult for games, |> streaming |> audio/video, etc.; and that providing a standard protocol for these |> operations would make building such applications, and having them |> interoperate well with NATs and firewalls, much easier. |> |> I'm not convinced this argument is correct, though it passes the |> first-tier plausibility test in my mind. I just thought I'd float |> the trial balloon. The problem is in how to deal with the legacy. Also, most FW builders don't want to give out any clue to a potential attacker, so they silently discard the packets. In this case, how is a feedback mechanism supposed to work?

1 0

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