netdev
[Top] [All Lists]

Re: [patch]: CONFIG_IPV6_SUBTREES fix for MIPv6

To: Masahide NAKAMURA <nakam@xxxxxxxxxxxxxx>
Subject: Re: [patch]: CONFIG_IPV6_SUBTREES fix for MIPv6
From: Henrik Petander <lpetande@xxxxxxxxxx>
Date: Fri, 13 Jun 2003 17:27:50 +0300
Cc: "David S. Miller" <davem@xxxxxxxxxx>, lpetande@xxxxxxxxxxxxxxxxxxx, yoshfuji@xxxxxxxxxxxxxx, vnuorval@xxxxxxxxxx, kuznet@xxxxxxxxxxxxx, netdev@xxxxxxxxxxx, ajtuomin@xxxxxxxxxxxxxxxxxxx, jagana@xxxxxxxxxx, kumarkr@xxxxxxxxxx, usagi-core@xxxxxxxxxxxxxx
In-reply-to: <20030613202652.1d64ed6f.nakam@linux-ipv6.org>
References: <3EE5F85E.9080006@tml.hut.fi> <20030610.095135.28806569.davem@redhat.com> <3EE6ECD3.6050103@tml.hut.fi> <20030611.202003.74721468.davem@redhat.com> <3EE83D81.5030605@tml.hut.fi> <20030613202652.1d64ed6f.nakam@linux-ipv6.org>
Sender: netdev-bounce@xxxxxxxxxxx
User-agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.2.1) Gecko/20030225
Masahide NAKAMURA wrote:
On Thu, 12 Jun 2003 11:44:49 +0300
Henrik Petander <lpetande@xxxxxxxxxx> wrote:

I don't see a problem in that. It would only result in a short period of missing mipv6 route optimization information, until MIPv6 daemon reinserted the mipv6 information. MIPv6 daemon would do this after getting a notification of the deletion of the old mipv6 related cached routes. This would relate to zebra in the same way as pmtu discovery.


When routing information is deleted by zebra, the packets from user
application will be sent incorrectly until MIPv6 daemon re-inserts
the special host route.

The packets between Mobile Node and Correspondent Node would be just sent through the tunnel via Home Agent. Only parts of the direct traffic between MN and HA would be temporarily lost. Since HA is conceptually a router, the traffic between MN and HA should be very limited and Mobile IP / IPSec signaling would not be affected. This is why IMO the use of soft state is acceptable.


How about making new policy(MIPv6 policy) in the similar way of IPsec?
MIPv6 and IPsec policy are managed by separated list.

It would be a good solution from our POV, since it should work well with IPSec.


Regards,

Henrik


<Prev in Thread] Current Thread [Next in Thread>