I have single PUBLIC ip on WAN interface of Mikrotik.
From yesterday I am continuously being hit by various public ip with UDP attack. this results in WAN link usage to 100% and chocking.
the src and dst ports (udp) are different. I tried to block ports, i tried to block source ip's in INPUT/FORWARD chains but still no use.

If I will ask my ISP to change the IP, they will but still its no solution, attack can come to new ip as well sooner or later.

in my LAB, i used 'UDP Unicorn' tool to FLOOd my mikrotik & it simply flooded mikrotik. no rules are blocking the UDP traffic. even i tried bandwidth limiting those pkts.

What is the real solution to this problem ? How can I block such UDP attack?

You cannot stop incoming traffic. Only ISP could do this. Your Mikrotik could however filter it out and do not pass to LAN.

You could be the target of a DDoS, but more likely you're contributing to a DDoS targeting someone else. You should configure your router to drop the UDP traffic in question, rather than reject or forward.

in my LAB, i used 'UDP Unicorn' tool to FLOOd my mikrotik & it simply flooded mikrotik. no rules are blocking the UDP traffic. even i tried bandwidth limiting those pkts.

What is the real solution to this problem ? How can I block such UDP attack?

Show us the firewall config you are using. And indeed, as written above, when you are under DDoS attack no filtering can stop that.

Are you on dynamic ip? if so try resetting your modem to get a new ip.
And as mentioned, make sure you don't provoke it again in future.

Right now I donot have any FIREWALL in place.
In TORCH i can see on IP address with UDP traffic , traffic reaching upto 80-100 mbps which chocks the whole bandwidth.
Even if block this ip in INPUT/FORWARD chain , still the traffic is reaching upto 80-100mbps.
Some one told me about UNICORN UDP flooder, when I downloaded it and run the test, my mikrotik reached traffic full.
I can understand TCP flooding, but how can I prevent UDP flooding which doesnt stops even with the rules?

You cannot stop incoming traffic. Only ISP could do this. Your Mikrotik could however filter it out and do not pass to LAN.

How ISP's block such traffic , using what technique?

Are you on dynamic ip? if so try resetting your modem to get a new ip.
And as mentioned, make sure you don't provoke it again in future.

I am static public IP, it is required for some services. Getting public ip is very difficult here, after many months of requests I am now able to get public ip.

what rules I can make to DROP or REJECT the flooding (so that it may not pass to other) ?
is DROP better or REJECT?

Drop is better than reject, as reject will also generate outgoing traffic.
And best to do it in raw table.

In very old days I faced similar issue, & I have one Linux base Transparent Bridge which was placed between the ISA Server & the Clients for MAC - IP filtering.
With some tuning, I placed it between ISA & Internet & it filtered all unnecessary ports / flooding & block it from reaching ISA which saved at least ISA, but still bandwidth hogging will happen.
ISP need to block them via ther BGP blackhole routes.

How ISP's block such traffic , using what technique?

They should be informed by you that you are flooded from particular IP or to particular port.
The problem is that UDP traffic does not care about confirmation what happens to packets. Flooder just sends packets and ignores the result ... your link is saturated so you are DDOS's victim.
Rejecting or Dropping packets plays role for TCP traffic. but should be done with your router/firewall.
Rejecting packets lets you inform flooder that your network/host is not accessible but intelligent flooder could check that the packet comes from the attacked device so it is alive. You should mangle TTL to fool flooder that your device is really not accessible.
Dropping packets does not give any information to flooder and you can just wait till it is "tootired" to flood nonresponsing host.

How might TTL mangle help in this case, with UDP with possibly blind transmission?
Also keep in mind, that the resulting ICMP will carry source ip, which would be targeted ip when transmitted by router, so how would it fool the attacker?

As I've written ... it makes sense only for TCP traffic.

I think it doesn't make sense even for TCP, as source ip of that ICMP will be the targeted ip, telling the attacker that host IS responding / up?