You are almost correct.
1) I have static routing like this : Router3 - > Router2 -> Router1 -> Router0
ad 1 : there won't be ICMP redirect, because next hop of Router 3 , which is Router 2 isn't on the same subnet as PC0 is. Every time PC0 will communicate with PC1 the path will be PC0 -> Router3 -> Router2 -> Router1 -> Router0 -> PC1
Absolutely correct. Since Router3 doesn't know the full path, only the next hop, it would just forward the packet to Router2
2) I have static routing like this : Router3 -> Router1 -> Router0
ad 2: At the begining communication will be PC0 -> Router3 -> Router1 -> Router0 -> PC1 Then ICMP redirect will send and next communication will be PC0 -> Router1 -> Router0 -> PC1 and ICMP redirect will send again and next communication will be PC0 -> Router0 -> PC1
Almost. You are correct in saying that Router 3 will send an ICMP Redirect to PC0, informing PC0 that the proper 'next-hop' to get to PC1 is to use Router1. However, when the ICMP Redirect is sent to the original sender, the original packet is still forwarded. Which means when Router1 receives the original packet, it will be receiving a packet from a host in its own network, for which a better next-hop exists, also in the same network (Router0). So Router1 will also send an ICMP redirect from the first packet.
So the path of the first packet will actually go Router3 -> Router1 -> Router0 -> PC1. But both Router3 and Router1 will send PC0 an ICMP Redirect informing PC0 of the better next hop. Since Router1's ICMP redirect will come after Router3's, then Router1's ICMP redirect will overwrite Router3's. So the second packet will go PC0 -> Router0 -> PC1.
3) I have static routing like this : Router3 -> Router0
ad 3: At the begining PC0 -> Router3 -> Router0 -> PC1. Then, ICMP redirect and the path will be PC0 -> Router0 -> PC1
Absolutely Correct.
Two final points to keep in mind:
First, in all cases, the ICMP Redirect is temporary. I believe that PC0 will use the information in the ICMP redirect for 10 minutes, before 'going back to' what it knew before... which would prompt additional ICMP redirects, and an additional 10 minutes of more efficient routing.
Second, ICMP Redirect was created when the Internet was a nice place, with trust worthy people. Now a days, the Internet is a dark and scary place, for which you should have very little trust. As a security best practice, most Network Admins prevent their Routers from sending ICMP Redirects and prevent their Routers from 'obeying' ICMP redirects. Similarly, a lot of client OS's also flat out ignore ICMP redirects.
The reason for this is it would be very easy to abuse the ICMP redirect to become a Man in the Middle. If you and I happen to be on the same network, I could easily send you an ICMP Redirect message that tells you the "better next hop" to reach your [Facebook, Banking, e-Commerce, Intra-net Portal, anything] network is through my own IP. Voila, instant Man in the Middle.
As such, I think its good to know the basics of ICMP Redirect, but I think it isn't very functional to spend much time mastering how they work. Its nearly across the board disabled and/or disallowed -- for good reason.
Let me start by saying proxy ARP is at best a sloppy solution. They only time I found it useful as a feature is when I was dealing with devices on the network that could not utilize classless netmasks or couldn't set a default route.
Yes, it can "cover" many client configuration or bad design problems, but it doesn't fix those problems. It also doesn't "cover" all of them and it can make troubleshooting issues more difficult.
Getting back to your question, the most likely reason this isn't working is that your client's aren't ARPing. My guess is that you have given them what is often considered a "standard" network mask of /24. In your example, there is likely no solution to get proxy ARP to work as clients should not accept a network mask less than /8 so your client will never think the destination is on the local network and send out an ARP request.
Why? A client uses it's IP address and network mask to determine if a destination is on the local network or not. If it is on the local network, the client checks it's ARP table for any entries for the destination and if one doesn't exist, will send out an ARP request to get this information. This is where the router with proxy ARP enabled can respond, but if there is no ARP request then the router cannot provide a proxy ARP response.
If the destination is not on the local network, then the client will check it's routing table to see where to forward the traffic. This is typically your default gateway.
Now, with the IP addresses you used, when the client checked the destination against it's IP/mask, it would find the destination is not on the local network. Going to the routing table, it won't have a specific entry for the destination network (clients won't by default) and no default route/gateway. It will then fail with a "no route to host" type of message.
Best Answer
The same way that you would for IPv4, except where IPv4 uses the
ip routecommand, IPv6 uses theipv6 routecommand.In R1, you could create a static route to
3000:4::/64:or possibly a default route:
and in the Central router, you would have:
You will need to do the same on all the R routers, and for all the networks on the other side of the R routers on the Central router.
This type of question is easily answered by doing a simple search. Cisco maintains documents on all the features. For example, Implement Static Routes for IPv6 Configuration Example.