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.
miquels@cistron-office.nl (Miquel van Smoorenburg) writes:
In article <F5F3FBBFC94DD4118E4500D0B74A095F013E70E1@EMAIL2>,
>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.
Not to get involved in the RFC1918 for routers topic again, but the
NAT discussions here got me wondering if much of this could be solved
by having an edge router translate all of the internal router-network
addresses to some constant, real address. Setting aside opinions
about the brokenness of NAT, can anybody think of anything this would
break?
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.
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?