RE: BCP38 exceptions for RFC1918 space
I very often see 1918 space in ICMP responses. It's quite dumb. -Original Message- From: valdis.kletni...@vt.edu [mailto:valdis.kletni...@vt.edu] Sent: 16 August 2010 14:27 To: Joe Greco Cc: na...@merit.edu Subject: Re: BCP38 exceptions for RFC1918 space On Mon, 16 Aug 2010 06:50:00 CDT, Joe Greco said: What *possible* use case would require a 1918-sourced packet to be traversing the public internet? We're all waiting with bated breath to hear this one. ;) It's great for showing in traceroutes who the heel is. Like I said, at that point it's name-n-shame time.
Re: BCP38 exceptions for RFC1918 space
Hahahahah How do we prevent BGP loops? Hahahhaahb Sent via mobile. On Aug 23, 2010, at 2:31 AM, Leigh Porter leigh.por...@ukbroadband.com wrote: I very often see 1918 space in ICMP responses. It's quite dumb. -Original Message- From: valdis.kletni...@vt.edu [mailto:valdis.kletni...@vt.edu] Sent: 16 August 2010 14:27 To: Joe Greco Cc: na...@merit.edu Subject: Re: BCP38 exceptions for RFC1918 space On Mon, 16 Aug 2010 06:50:00 CDT, Joe Greco said: What *possible* use case would require a 1918-sourced packet to be traversing the public internet? We're all waiting with bated breath to hear this one. ;) It's great for showing in traceroutes who the heel is. Like I said, at that point it's name-n-shame time.
Re: BCP38 exceptions for RFC1918 space
On 8/23/10 2:31 AM, Leigh Porter wrote: I very often see 1918 space in ICMP responses. It's quite dumb. you wouldn't if you filtered rfc 1918 source addresses on your border. -Original Message- From: valdis.kletni...@vt.edu [mailto:valdis.kletni...@vt.edu] Sent: 16 August 2010 14:27 To: Joe Greco Cc: na...@merit.edu Subject: Re: BCP38 exceptions for RFC1918 space On Mon, 16 Aug 2010 06:50:00 CDT, Joe Greco said: What *possible* use case would require a 1918-sourced packet to be traversing the public internet? We're all waiting with bated breath to hear this one. ;) It's great for showing in traceroutes who the heel is. Like I said, at that point it's name-n-shame time.
RE: BCP38 exceptions for RFC1918 space
Oh I do, just not to my workstation ;-) -Original Message- From: Joel Jaeggli [mailto:joe...@bogus.com] Sent: 23 August 2010 16:48 To: Leigh Porter Cc: valdis.kletni...@vt.edu; Joe Greco; na...@merit.edu Subject: Re: BCP38 exceptions for RFC1918 space On 8/23/10 2:31 AM, Leigh Porter wrote: I very often see 1918 space in ICMP responses. It's quite dumb. you wouldn't if you filtered rfc 1918 source addresses on your border. -Original Message- From: valdis.kletni...@vt.edu [mailto:valdis.kletni...@vt.edu] Sent: 16 August 2010 14:27 To: Joe Greco Cc: na...@merit.edu Subject: Re: BCP38 exceptions for RFC1918 space On Mon, 16 Aug 2010 06:50:00 CDT, Joe Greco said: What *possible* use case would require a 1918-sourced packet to be traversing the public internet? We're all waiting with bated breath to hear this one. ;) It's great for showing in traceroutes who the heel is. Like I said, at that point it's name-n-shame time.
Re: BCP38 exceptions for RFC1918 space
On Mon, Aug 16, 2010 at 1:49 AM, Marco Hogewoning mar...@marcoh.net wrote: On 15 aug 2010, at 20:05, Randy Bush wrote: rfc1918 packets are not supposed to reach the public internet. once you start accommodating their doing so, the downward slope gets pretty steep and does not end in a nice place. I cannot agree more with this. If you want PMTU use non-private space, there is enough really :) And saving a /24 by renumbering your core into RFC 1918 won't save you from the coming run out. I once suggested something along the lines of: interface Loopback0 ip address 1.2.3.4 255.255.255.255 interface GigabitEthernet0/0 ip address 192.168.0.1 255.255.255.0 icmp errors-from Loopback0 But I was yelled at for trying to break traceroute. Regards, Bill Herrin -- William D. Herrin her...@dirtside.com b...@herrin.us 3005 Crane Dr. .. Web: http://bill.herrin.us/ Falls Church, VA 22042-3004
Re: BCP38 exceptions for RFC1918 space
Florian Weimer wrote: What's the current consensus on exempting private network space from source address validation? Is it recommended? Discouraged? (One argument in favor of exceptions is that it makes PMTUD work if transfer networks use private address space.) IMHO, operators who number infrastructure out of RFC1918 and then permit internet traceroutes over it are misguided and should consider avoiding TTL decrement (i.e using mpls without internet TTL propagation) as a less stressful (for us) alternative to simply filtering. Dave. -- David Freedman Group Network Engineering Claranet Group
Re: BCP38 exceptions for RFC1918 space
On Sun, 15 Aug 2010 19:02:50 +0200, Florian Weimer said: * Valdis Kletnieks: On Sun, 15 Aug 2010 18:46:49 +0200, Florian Weimer said: And that connection that's trying to use PMTU got established across the commodity internet, how, exactly? ;) ICMP fragmentation needed, but DF set messages carry the a addresses of intermediate routers which generate them (potentially in response to MTU drops) as source addresses, not the IP addresses of the peers in a connection. If any long-haul carriers are originating ICMP packets for other people's consumption from 1918 addresses rather than addresses in their address space, it's time to name-n-shame so the rest of us can vote with our feet and checkbooks. There's no excuse for that in this day and age. What does originating mean? Creating the packets? Or forwarding them? Either way, there's no excuse. First off, remember that BCP38 and 1918 don't apply on your set of interconnected private networks, no matter how big a net it is. You want to filter between two of your private nets, go ahead. You don't want to, that's OK to. The fun starts when those packets leave your network(s) and hit the public Internet. Now that we have that squared away... Either that intermediate router originated the ICMP 'frag needed' packet, in which case somebody needs to be smacked for originating a 1918-addressed packet on the public internet, or it's forwarding the packet. And if it's forwarding the packet, then somebody *else* needs to be smacked for injecting that packet into the public internet. What *possible* use case would require a 1918-sourced packet to be traversing the public internet? We're all waiting with bated breath to hear this one. ;) pgpqXo6NLfzKs.pgp Description: PGP signature
Re: BCP38 exceptions for RFC1918 space
What does originating mean? Creating the packets? Or forwarding them? Either way, there's no excuse. First off, remember that BCP38 and 1918 don't apply on your set of interconnected private networks, no matter how big a net it is. You want to filter between two of your private nets, go ahead. You don't want to, that's OK to. The fun starts when those packets leave your network(s) and hit the public Internet. Now that we have that squared away... Either that intermediate router originated the ICMP 'frag needed' packet, in which case somebody needs to be smacked for originating a 1918-addressed packet on the public internet, or it's forwarding the packet. And if it's forwarding the packet, then somebody *else* needs to be smacked for injecting that packet into the public internet. What *possible* use case would require a 1918-sourced packet to be traversing the public internet? We're all waiting with bated breath to hear this one. ;) It's great for showing in traceroutes who the heel is. Do I win a prize? ... JG -- Joe Greco - sol.net Network Services - Milwaukee, WI - http://www.sol.net We call it the 'one bite at the apple' rule. Give me one chance [and] then I won't contact you again. - Direct Marketing Ass'n position on e-mail spam(CNN) With 24 million small businesses in the US alone, that's way too many apples.
Re: BCP38 exceptions for RFC1918 space
On Mon, 16 Aug 2010 06:50:00 CDT, Joe Greco said: What *possible* use case would require a 1918-sourced packet to be traversing the public internet? We're all waiting with bated breath to hear this one. ;) It's great for showing in traceroutes who the heel is. Like I said, at that point it's name-n-shame time. pgpuIXgUVU1aq.pgp Description: PGP signature
Re: BCP38 exceptions for RFC1918 space
On Sun, 15 Aug 2010 18:14:41 +0200, Florian Weimer said: What's the current consensus on exempting private network space from source address validation? Is it recommended? Discouraged? What you do on your internal networks and internal transit is your business. BCP38 talks about where you connect to the rest of the world. RFC 1918 is specific that you're supposed to get all medieval on any escaping packets: 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. (One argument in favor of exceptions is that it makes PMTUD work if transfer networks use private address space.) And that connection that's trying to use PMTU got established across the commodity internet, how, exactly? ;) That implies you let some routing info escape and got one of those ambiguous routing situations. pgpzBiUnAaJ4T.pgp Description: PGP signature
Re: BCP38 exceptions for RFC1918 space
* Valdis Kletnieks: On Sun, 15 Aug 2010 18:14:41 +0200, Florian Weimer said: What's the current consensus on exempting private network space from source address validation? Is it recommended? Discouraged? What you do on your internal networks and internal transit is your business. BCP38 talks about where you connect to the rest of the world. I'm seeing them across AS boundaries, otherwise I wouldn't have bothered. RFC 1918 is specific that you're supposed to get all medieval on any escaping packets: Yeah, but sometimes, the current practice moves on. 8-) (One argument in favor of exceptions is that it makes PMTUD work if transfer networks use private address space.) And that connection that's trying to use PMTU got established across the commodity internet, how, exactly? ;) ICMP fragmentation needed, but DF set messages carry the a addresses of intermediate routers which generate them (potentially in response to MTU drops) as source addresses, not the IP addresses of the peers in a connection. That implies you let some routing info escape and got one of those ambiguous routing situations. Not really, I'm afraid.
Re: BCP38 exceptions for RFC1918 space
On Aug 15, 2010, at 9:14 AM, Florian Weimer wrote: What's the current consensus on exempting private network space from source address validation? BCP38-land MUST *never* see RFC1918-space traffic. Ever. Unless you're using a border router as a NAT device, of course The only way your question makes sense is if someone who should know better is intending to announce some chunk of RFC1918-space via BGP. Please tell us that is not your intent. Aloha, Michael. -- Please have your Internet License http://kapu.net/~mjwise/ and Usenet Registration handy...
Re: BCP38 exceptions for RFC1918 space
* Valdis Kletnieks: On Sun, 15 Aug 2010 18:46:49 +0200, Florian Weimer said: And that connection that's trying to use PMTU got established across the commodity internet, how, exactly? ;) ICMP fragmentation needed, but DF set messages carry the a addresses of intermediate routers which generate them (potentially in response to MTU drops) as source addresses, not the IP addresses of the peers in a connection. If any long-haul carriers are originating ICMP packets for other people's consumption from 1918 addresses rather than addresses in their address space, it's time to name-n-shame so the rest of us can vote with our feet and checkbooks. There's no excuse for that in this day and age. What does originating mean? Creating the packets? Or forwarding them?
Re: BCP38 exceptions for RFC1918 space
* Michael J. Wise: On Aug 15, 2010, at 9:14 AM, Florian Weimer wrote: What's the current consensus on exempting private network space from source address validation? BCP38-land MUST *never* see RFC1918-space traffic. Ever. Unless you're using a border router as a NAT device, of course The only way your question makes sense is if someone who should know better is intending to announce some chunk of RFC1918-space via BGP. Please tell us that is not your intent. It's not. It's not even about my or my employer's network, that's why I need to exercise extra caution before handing out advice. 8-)
Re: BCP38 exceptions for RFC1918 space
What's the current consensus on exempting private network space from source address validation? Is it recommended? Discouraged? (One argument in favor of exceptions is that it makes PMTUD work if transfer networks use private address space.) and this is a good thing? rfc1918 packets are not supposed to reach the public internet. once you start accommodating their doing so, the downward slope gets pretty steep and does not end in a nice place. randy
Re: BCP38 exceptions for RFC1918 space
On 15/08/2010 18:02, Florian Weimer wrote: * Valdis Kletnieks: On Sun, 15 Aug 2010 18:46:49 +0200, Florian Weimer said: And that connection that's trying to use PMTU got established across the commodity internet, how, exactly? ;) ICMP fragmentation needed, but DF set messages carry the a addresses of intermediate routers which generate them (potentially in response to MTU drops) as source addresses, not the IP addresses of the peers in a connection. If any long-haul carriers are originating ICMP packets for other people's consumption from 1918 addresses rather than addresses in their address space, it's time to name-n-shame so the rest of us can vote with our feet and checkbooks. There's no excuse for that in this day and age. What does originating mean? Creating the packets? Or forwarding them? My bus originates in the town of bananaville, but before it finally originates at mangoburgh, it originates through 5 other towns. Wow, that would be a confusing language to speak. ;) The origin is the beginning point of something, where it is created. http://en.wiktionary.org/wiki/origin I'll let you off as you're German and German doesn't use any words with related etymology : Though really, if you know BGP you should understand the term 'origin'. adam.
Re: BCP38 exceptions for RFC1918 space
On 15 aug 2010, at 20:05, Randy Bush wrote: What's the current consensus on exempting private network space from source address validation? Is it recommended? Discouraged? (One argument in favor of exceptions is that it makes PMTUD work if transfer networks use private address space.) and this is a good thing? rfc1918 packets are not supposed to reach the public internet. once you start accommodating their doing so, the downward slope gets pretty steep and does not end in a nice place. I cannot agree more with this. If you want PMTU use non-private space, there is enough really :) And saving a /24 by renumbering your core into RFC 1918 won't save you from the coming run out. MarcoH
