North American Network Operators Group|
Date Prev | Date Next | Date Index | Thread Index | Author Index | Historical
Re: Maybe I'm misreading this but...
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.