Maybe I'm misreading this but...

Sat Oct 17 07:03:42 UTC 1998

On Fri, 16 Oct 1998, I Am Not An Isp wrote:

> At 10:37 PM 10/16/98 -0700, Marc Slemko wrote:
> >On Fri, 16 Oct 1998, I Am Not An Isp wrote:
> >
> >> differently than any other packet.  Unless, of course, the user manually
> >> modifies the default behavior with filters or something - which can be done
> >> to any address just as easily.
> >
> >That argument is so bogus that I am amazed you are trying to use it.
> 
> I was going to leave this alone, as most people were polite and at least
> partially rational.  But you win, I'll reply.

Thanks.

> >Saying that using private addresses for links doesn't break PMTU-D if
> >there is a MTU change just because it requires other things in place to
> >actually break is quite irresponsible.  People are clueless enough
> >already, don't confuse them with half truths.
> 
> I am afraid that you are the one spouting factually incorrect information.
> I am neither responsible for your lack of clue or your filtering.  The fact
> that you filter RFC1918 space may be admirable, but that does not mean that
> RFC1918 breaks PMTU.

No, RFC-1918 does not break PMTU-D in any way and I have never claimed it 
did.

People configuring their routers to generate packets with an invalid and
illegal (according to RFC-1918) source address are what breaks it.  By
telling people that doing so doesn't break things, you are ignoring both
the fact that it does for a certain unknown percent of users and that it
violates RFC-1918.  What more do you need?

> 
> >The reality is, that for the Internet today where a large number of people
> >filter such addresses, using private addresses does break PMTU-D.  They
> >_CAN_ put filters on any address just as easily; if I don't want traffic
> >from you, I can filter it.  If I don't want traffic from addresses that
> >shouldn't be sending traffic or that I use internally, I will filter it.
> >If you have a MTU change on a router using private link addresses, then
> >the second filter implies that the first will implicitly be true anyway
> >for at least some traffic.  It is _NOT_ correct to say that filtering
> >either your address or private address space has just the same effect.
> 
> And if I use the RBL, and you are a known spammer, I can then deduce that
> spamming breaks PMTU discover in much the same way.  Sure, I'm just

Nope.  If I filter an address, then I don't want traffic from that
address.  There is a direct cause effect relationship.  If I filter
RFC-1918 address space, I am filtering addresses with the explicit
definition of:

   In order to use private address space, an enterprise needs to
   determine which hosts do not need to have network layer connectivity
   outside the enterprise in the foreseeable future and thus could be
   classified as private. Such hosts will use the private address space
   defined above.  Private hosts can communicate with all other hosts
   inside the enterprise, both public and private. However, they cannot
   have IP connectivity to any host outside of the enterprise. While not
   having external (outside of the enterprise) IP connectivity private
   hosts can still have access to external services via mediating
   gateways (e.g., application layer gateways).

and:

   Because private addresses have no global meaning, routing information
   about private networks shall not be propagated on inter-enterprise
   links, and packets with private source or destination addresses
   should not be forwarded across such links. Routers in networks not
   using private address space, especially those of Internet service
   providers, are expected to be configured to reject (filter out)
   routing information about private networks. If such a router receives
   such information the rejection shall not be treated as a routing
   protocol error.

and:

   One might be tempted to have both public and private addresses on the
   same physical medium. While this is possible, there are pitfalls to
   such a design (note that the pitfalls have nothing to do with the use
   of private addresses, but are due to the presence of multiple IP
   subnets on a common Data Link subnetwork).  We advise caution when
   proceeding in this area.

   It is strongly recommended that routers which connect enterprises to
   external networks are set up with appropriate packet and routing
   filters at both ends of the link in order to prevent packet and
   routing information leakage. An enterprise should also filter any
   private networks from inbound routing information in order to protect
   itself from ambiguous routing situations which can occur if routes to
   the private address space point outside the enterprise.

Nowhere does it imply that any legitimate use of such addresses will
result in me losing connectivity if I filter them.  The only reason why
that holds true is because of people (mostly who heard someone say it was
a cool thing to do but don't themself have a clue about such things)
violating the RFC-1918 specified use of such addresses.

> As for your implication that so many people on the Internet filter RFC1918
> space it should just be taken for granted, I'd like to point out you
> obviously didn't even read the first post in this thread.  The original
> post included a traceroute - through a well known provider - that showed
> RFC1918 space source addresses.  Guess both the original poster and his

So what?  "many" certainly doesn't imply a majority.

Note that the fact that major backbones may not filter such things has
little relation to how the majority of end to end connections will see
things, since most of them don't go from a backbone to a backbone but go
from something connected to a backbone to something connected to a
backbone.

> upstream forgot to read your rules.  But that's okay, lots of other
> providers also forgot.  Of course, it's usually smaller ones like UUNET,
> Sprint (that I'm sure of), MCI and BBN (I believe).

I wouldn't pay to much attention to what sprint does, since they are the
bozos that haven't heard of filtering advertisements or taking two seconds
to look at their configs before they implement them and start spewing
bogus routes to the world.

> 
> Sorry if I'm a bit harsh, but it simply amazes me that people will respond
> to an e-mail showing a traceroute with RFC1918 space and respond with
> "everyone filters RFC1918, you'll never see a packet sourced from there!".

I have never said such a thing, and if I implied it then I apoligize.

It is amazing how this comes up over and over, and people still defend it
somehow.