Subject: Invalid IP in MBone ?

From: Joao Carlos Mendes Luis <[email-masked]>
Date: Wed, 2 Oct 1996 19:06:24 -0300 (EST)

Hey, this source address is invalid, as stated in RFC1918...

gaia::root [45] tcpdump src net 172.16
tcpdump: listening on de0
18:55:55.151112 172.16.9.50.2733 > 224.2.100.101.32800: udp 105
18:55:55.643278 172.16.9.50.2737 > 224.2.100.100.16401: udp 44
18:55:58.126508 172.16.9.50.2733 > 224.2.100.101.32800: udp 105
18:55:59.307657 172.16.9.50.2737 > 224.2.100.100.16401: udp 44
18:56:01.145878 172.16.9.50.2733 > 224.2.100.101.32800: udp 105

Who is broadcasting this ?

My mtrace follows:

gaia::root [47] mtrace 172.16.9.50
Mtrace from 172.16.9.50 to 146.164.63.4 via group 224.2.0.1
Querying full reverse path... * switching to hop-by-hop:
  0  gaia.coppe.ufrj.br (146.164.63.4)
 -1  gaia.coppe.ufrj.br (146.164.63.4)  DVMRP  thresh^ 1
 -2  ceop4.rederio.br (146.164.10.4)  DVMRP  thresh^ 8
 -3  mbone.cerf.net (192.215.245.10)  DVMRP  thresh^ 64
 -4  mbone.sdsc.edu (198.17.46.39)  DVMRP  thresh^ 64
 -5  nccosc-mbone.dren.net (138.18.5.224)  DVMRP  thresh^ 48
 -6  mbone.nsi.nasa.gov (192.203.230.241)  DVMRP  thresh^ 64
 -7  llnl-mr2.es.net (134.55.12.229)  DVMRP  thresh^ 64
 -8  * * * * mbone1.pnl.gov (192.35.193.20) didn't respond
 -9  * * *
-10  * * *
-11  * * * ...giving up
Round trip time 288 ms

Results after 40 seconds:
 
  Source        Response Dest    Packet Statistics For     Only For Traffic
   * * *        146.164.63.4     All Multicast Traffic     From 172.16.9.50
     v       __/  rtt  370 ms    Lost/Sent = Pct  Rate       To 224.2.0.1
134.55.12.229   llnl-mr2.es.net
     v     ^      ttl   64        4/755  =  1%   0 pps     0/0    = --%   0 pps
192.203.230.241 mbone.nsi.nasa.gov
     v     ^      ttl   65       10/4895 =  0% 122 pps     0/0    = --%   0 pps
138.18.5.224    nccosc-mbone.dren.net
     v     ^      ttl   66    10178/17893= 57% 447 pps     0/0    = --%   0 pps
198.17.46.39    mbone.sdsc.edu
     v     ^      ttl   67        1/3994 =  0%  99 pps     0/0    = --%   0 pps
192.215.245.10  mbone.cerf.net
     v     ^      ttl   68       18/422  =  4%  10 pps     0/0    = --%   0 pps
146.164.10.4    ceop4.rederio.br
     v     ^      ttl   69        0/238  =  0%   5 pps     0/0    = --%   0 pps
146.164.63.4    gaia.coppe.ufrj.br
     v      \__   ttl   70
146.164.63.4    146.164.63.4
  Receiver      Query Source

And my traceroute:

gaia::root [49] traceroute 172.16.9.50
traceroute to 172.16.9.50 (172.16.9.50), 30 hops max, 40 byte packets
 1  cisco-ufrj (146.164.2.1)  2.701 ms  2.134 ms  3.411 ms
 2  cisco-ufrj-internacional (146.164.10.8)  3.141 ms  1.552 ms  1.590 ms
 3  sdsc-brazil.cerf.net (134.24.26.100)  197.842 ms  204.915 ms  187.169 ms
 4  mobydick-fddi.cerf.net (134.24.252.3)  261.329 ms  219.663 ms  209.616 ms
 5  sl-pen-2-F4/0.sprintlink.net (192.157.69.9)  292.641 ms *  269.749 ms
 6  * * *
 7  * * *

sl-pen-2-F4/0.sprintlink.net is probably filtering this invalid traffic,
as it should...

					Jonny

--
Joao Carlos Mendes Luis			[email-masked]
+55 21 290-4698 ( Job )			[email-masked]
Network Manager				UFRJ/COPPE/CISI
Universidade Federal do Rio de Janeiro

---

From: "Joe Burrescia" <[email-masked]>
Date: Wed, 02 Oct 96 17:44:12 -0700

I can see this route, 172.16/16, being learned by llnl-mr2.es.net
from mbone1.pnl.gov.  Not sure why they are announcing it,
but I've contacted the site mbone coordinator and taken
the tunnel between down to PNL till they get a chance to investigate.
The reason your unicast traceroute failed is that 172.16/16
is not being announced by PNL as a network it owns.

-- Joe
+++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
Joseph Burrescia
Energy Sciences Network (ESnet)
Network Engineering Services Group 
Lawrence Berkeley National Laboratory
(510)486-8623

> 146.164.63.4    gaia.coppe.ufrj.br

+++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
Joseph Burrescia
Energy Sciences Network (ESnet)
Network Engineering Services Group 
Lawrence Berkeley National Laboratory
(510)486-8623

---

From: Bill Fenner <[email-masked]>
Date: Thu, 3 Oct 1996 13:52:40 PDT

>Hey, this source address is invalid, as stated in RFC1918...

Right now, I see the routes for the following RFC1918 subnets:

10/8 is in the private class A block
10.10.10/24 is in the private class A block
172.16/16 is in the private class B block
172.16.3/24 is in the private class B block
172.21/16 is in the private class B block
192.168.1/24 is in the private class C block
192.168.7/24 is in the private class C block
192.168.10/24 is in the private class C block
192.168.14/24 is in the private class C block
192.168.52/24 is in the private class C block
192.168.100.192/27 is in the private class C block
192.168.101/24 is in the private class C block
192.168.106/24 is in the private class C block
192.168.128/17 is in the private class C block
192.168.132/24 is in the private class C block
192.168.224/24 is in the private class C block
192.168.230/24 is in the private class C block
192.168.240/24 is in the private class C block
192.168.241/24 is in the private class C block
192.168.242/24 is in the private class C block
192.168.243/24 is in the private class C block
192.168.245/24 is in the private class C block
192.168.253/24 is in the private class C block
192.168.253.4/30 is in the private class C block
192.168.253.8/30 is in the private class C block
192.168.253.12/30 is in the private class C block
192.168.253.16/30 is in the private class C block
192.168.253.20/30 is in the private class C block
192.168.253.24/30 is in the private class C block
192.168.254/24 is in the private class C block
192.168.255/24 is in the private class C block

I sent a periodic posting to this list about a year ago, but things were
getting worse with each posting, so I figured it wasn't doing any good and
quit sending it.

  Bill

---

From: Petri Helenius <[email-masked]>
Date: Fri, 4 Oct 1996 08:14:56 +0300 (EET DST)

> getting worse with each posting, so I figured it wasn't doing any good and
I think you were also including the CIDR routes, which at that point
of time might have been of concern but were supported also back then
by more recent mrouted versions. Pushing the private addresses off the
MBone might be a good idea, since many people are clueless about
their effect.

Maybe mrouted should filter them by default from the route
announcements, unless configured othervise on by-neighbor basis?

Pete

---

From: Joao Carlos Mendes Luis <[email-masked]>
Date: Fri, 4 Oct 1996 04:28:11 -0300 (EST)

#define quoting(Petri Helenius)
; Bill Fenner writes:
;  > In message <[email-masked]> you write:
;  > >Hey, this source address is invalid, as stated in RFC1918...
;  > 
;  > 192.168.253.20/30 is in the private class C block
;  > 192.168.253.24/30 is in the private class C block
;  > 192.168.254/24 is in the private class C block
;  > 192.168.255/24 is in the private class C block
;  > 
;  > I sent a periodic posting to this list about a year ago, but things were
;  > getting worse with each posting, so I figured it wasn't doing any good and
;  > quit sending it.
;  > 
; I think you were also including the CIDR routes, which at that point
; of time might have been of concern but were supported also back then
; by more recent mrouted versions. Pushing the private addresses off the
; MBone might be a good idea, since many people are clueless about
; their effect.
; 
; Maybe mrouted should filter them by default from the route
; announcements, unless configured othervise on by-neighbor basis?

This makes me think about something.  Imagine I have a RFC1918 numbered
network behind a firewall, and I want those machines to receive the
MBone transmissions.  How could this be done ?  And if I want to transmit
also ?

					Jonny

---

From: Petri Helenius <[email-masked]>
Date: Fri, 4 Oct 1996 14:07:24 +0300 (EET DST)

> MBone transmissions.  How could this be done ?  And if I want to transmit
Receive works, you lose RTCP. For transmit you have to do NAT which
you have to do for other applications also, if you don't have
application level proxies.

Pete

---

From: Bill Fenner <[email-masked]>
Date: Fri, 4 Oct 1996 10:03:35 PDT

In message <[email-masked]> you write:
>Imagine I have a RFC1918 numbered

You use an application gateway, just like you use for your RFC1918 hosts
to access the Web, email, ...

Sun, for example, has an application gateway to connect their interior
multicast network to the MBone.  Theirs exists for firewall reasons as
opposed to RFC1918 reasons but the idea works in either environment.

  Bill