Re: Maybe I'm misreading this but...
At 01:12 PM 10/16/98 -0400, tvo wrote:
Doesn't this break MTU path discovery though?
No, it wouldn't. Those addresses are not routable on the global 'Net, however, there is nothing stopping a device with an RFC1918 address from sending a packet onto the 'Net. Assume you have a T1 between two routers, but you are out of 'normal' addresses. So you make the two serial ports 10.1.1.1 and 10.1.1.2. Simple, huh? Well, anyone outside your network attempting to reach those addresses will fail - there is no route to 10.x.x.x on the Internet. (At least not in *my* network. :) Let's further assume there's a LAN on the other side of this T1 with a MTU below 1500 bytes. Now, when you attempt PMTU discovery to a device on that small MTU LAN (going through the T1 of course), what happens? When the router on the opposite end of the T1 gets the packet, it sees that the packet is "too big" and DF bit is set (as per PMTU rules) and cannot send the packet. So what should it do? Why send an ICMP "Datagram Too Big" error message, of course. (Type 3, "Destination Unreachable", Code 4, "fragmentation needed and DF set". See RFC 1191, http://www.pmg.lcs.mit.edu/cgi-bin/rfc/view-plain?number=1191, and RFC 792, http://www.pmg.lcs.mit.edu/cgi-bin/rfc/view?792, for more info.) Just like any other (properly functioning) router on the Internet. But what's the source address? Why 10.1.1.1 of course. So you get a packet from RFC1918 space. Perfectly normal, perfectly acceptable, perfectly legitimate. See, when a router gets a packet, it does not look at the source IP for routing info. (Unless you're doing something weird like policy routing.) So the source IP is irrelevant to a router. Hell, even the destination IP is irrelevant as long as it's 32 bits and matches something in the router's table (including a possible default route). I have never seen a router vendor treat a packet with RFC1918 space in source or destination any 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. The point is, there is magical router fairy looking for RFC1918 space and removing all those packets from your network. Those addresses are treated by your router just like *any other address*. Forwarded, filtered, whatever depending upon the rules you set up and the information it receives dynamically. I hope that explains everything. TTFN, patrick I Am Not An Isp www.ianai.net "Think of it as evolution in action." - Niven & Pournelle
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. 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. 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.
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.
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.
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 filtering your route announcement instead of your source address, but the PMTU is still not working. So, by your logic, spamming must break PMTU discovery. FACT: RFC1918 space does not break PMTU discovery. Deal with it. I've said it before and I will say it again - the combination of private policy decisions on some networks combined with the use of RFC1918 space on routers with different MTU links (thanx to Steve Gibbard for that last detail) *will* break PMTU discovery. However, if any *one* of the above three requirements are missing, PMTU will still work just fine. Any moderately intelligent person can plainly see from the above that RFC1918 address space in and of itself does *not* break PMTU discovery. I hope I've made this clear enough. If you honestly believe people are "clueless enough already", then you should be very careful not to mislead them with "half truths". Specifically, one should be careful to separate routing rules and private policies. By claiming a policy followed by some (and I'd bet not even most) providers is fact or rule, you could mislead people who are capable deducing the perfectly deterministic behavior for themselves. I would consider this act "irresponsible", if I thought you had any "responsibility" to teach these people in the first place. 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 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). 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!". TTFN, patrick I Am Not An Isp www.ianai.net "Think of it as evolution in action." - Niven & Pournelle
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.
participants (2)
-
I Am Not An Isp -
Marc Slemko