RE: end2end? (was: RE: Where NAT disenfranchises the end-user ... )
Em... I hate to be the bearer of bad news here, but I expect the Provider-in-the-middle isn't using NAT, They are probably using RFC 1918 Ip space for Transit links. This does not necessarily imply that they are using Nat. Using RFC 1918 space inside a network on transit segments that will be passing data but not generating it makes sense. No-one really needs to be able to Ping/SNMP-Query/http attack my routers serial links. using RFC 1918 space on these links precludes that possibility because my interfaces are not addressable on the public internet. Comments: -----Original Message----- From: bmanning@vacation.karoshi.com [mailto:bmanning@vacation.karoshi.com] Sent: Friday, September 07, 2001 8:56 PM To: andy@xecu.net Cc: bicknell@ufp.org; nanog@merit.edu Subject: Re: end2end? (was: RE: Where NAT disenfranchises the end-user ...)
Can you show damages in the situation of email? Yes. With packets? No. And before you come back at me with some crazy convoluted contrived scenario, let's just realize how far off the beaten path we are at this point. If your ISP is going to force you to use NAT, "against your will", get a new fricking provider. For that matter, what ISP NATs you against your will?
Not quite so friend Andy. Someone in UAE claims that I sent porn to them. And investigation shows that not only is there a NAT one hop away from the purported victim, there is -another- NAT in the path, injected by some intermediate ISP as well as the one injected by my provider. Now I can chage my provider to one w/o NAT. I can even get the PV to change their provider (well maybe, given they are in UAE) But how can we avoid the intermediate ISP that is in the transit path? And can I persuade the judge that since NATs are known to muck about w/ addresses & such that I can construct a case that what was received did not come from me. So the porn came from one of the NAT operators.
Andy Dills 301-682-9972 Dialup * Webhosting * E-Commerce * High-Speed Access
In article <F5F3FBBFC94DD4118E4500D0B74A095F013E70E1@EMAIL2>, Hire, Ejay <Ejay.Hire@Broadslate.net> wrote:
Using RFC 1918 space inside a network on transit segments that will be passing data but not generating it makes sense.
Only if the MTUs on all interfaces of the routers are the same. Otherwise you might generate a ICMP size exceeded message that will never reach the sender, breaking Path MTU Discovery. Mike. -- "I think...I think it's in my basement. Let me go upstairs and check." -- M.C. Escher (1898-1972)
On Mon, Sep 10, 2001 at 08:31:03PM +0000, Miquel van Smoorenburg wrote:
Only if the MTUs on all interfaces of the routers are the same. Otherwise you might generate a ICMP size exceeded message that will never reach the sender, breaking Path MTU Discovery.
And now I finally have something to add to this brilliant discussion. That is what I truly love about NAT. It breaks totally inane filth like path mtu discovery. I'm sure if someone had an MTU < ethernet on an internal router they wouldn't need NAT breaking path MTU discovery to bring it to their attention. -- Brandin Claar Network Analyst Penn State Applied Research Lab
On Mon, 10 Sep 2001, Brandin L Claar wrote:
That is what I truly love about NAT. It breaks totally inane filth like path mtu discovery. I'm sure if someone had an MTU < ethernet on an internal router they wouldn't need NAT breaking path MTU discovery to bring it to their attention.
You dont need NAT to break path mtu discovery. Solaris and Microsoft Windows will do the job just fine on their own. -Dan -- [-] Omae no subete no kichi wa ore no mono da. [-]
Firstly, please note the flamewar about NAT breaking or not breaking PMTU discovery is a different flamewar from the RFC1918 numbered links breaking PMTU discovery flamewar. And I am commenting here on neither. The answers to both are clear if you read the relevant docs. However:
That is what I truly love about NAT. It breaks totally inane filth like path mtu discovery.
Allegation of dubious merit aside: Please suggest alternate legacy compatible mechanisms to discover path MTU, or explain why you think fragmenting stuff as a matter of course aides performance, before you dismiss PMTU discovery as inane filth.
I'm sure if someone had an MTU < ethernet on an internal router they wouldn't need NAT breaking path MTU discovery to bring it to their attention.
Like, say, ethernet LAN -> dialup routed connection -> Internet. Or, urm, anything tunnelled between ethernet LANs passing at some point over ethernet. Both, of course, extremely uncommon applications. So now tell me why being unable to do path MTU discovery (somehow) is a good thing? -- Alex Bligh Personal Capacity
On Mon, 10 Sep 2001 17:20:42 -0400 Brandin L Claar wrote:
That is what I truly love about NAT. It breaks totally inane filth like path mtu discovery. I'm sure if someone had an MTU < ethernet on an internal router they wouldn't need NAT breaking path MTU discovery to bring it to their attention.
So... You do much 1, 10, 100 gigabit/sec Ethernet there?
Brandin Claar Network Analyst
On the Internet, no one knows you are a dog.
Penn State Applied Research Lab
I see, school is back in session.
participants (6)
-
Alex Bligh -
Brandin L Claar -
Dan Hollis -
Fletcher E Kittredge -
Hire, Ejay -
miquels＠cistron-office.nl