Hi Arifumi,
On Wed, 27 Apr 2011 15:43:33 +0900
Arifumi Matsumoto wrote:
> Mark,
>
> On 2011/04/27, at 7:17, Mark Smith wrote:
>
> > Hi Arifumi,
> >
> > On Tue, 26 Apr 2011 20:15:31 +0900
> > Arifumi Matsumoto wrote:
> >
> >> Mark,
> >>
> >> in your case, policy table should be helpful to m
Mark,
On 2011/04/27, at 7:17, Mark Smith wrote:
> Hi Arifumi,
>
> On Tue, 26 Apr 2011 20:15:31 +0900
> Arifumi Matsumoto wrote:
>
>> Mark,
>>
>> in your case, policy table should be helpful to manipulate source
>> address selection behavior for SLAAC and manually configured
>> addresses.
>>
Hi Arifumi,
On Tue, 26 Apr 2011 20:15:31 +0900
Arifumi Matsumoto wrote:
> Mark,
>
> in your case, policy table should be helpful to manipulate source
> address selection behavior for SLAAC and manually configured
> addresses.
>
True, although that requires actively changing the default policy
Mark,
in your case, policy table should be helpful to manipulate source
address selection behavior for SLAAC and manually configured
addresses.
As the final tie breaker, I do not see much sense to use preferred
lifetime for that purpose. Indefinite lifetime does not always mean
high preference. R
Hi,
I'd like to suggest the a few rules to be inserted between Rules 3 and 4
of RFC3484 -
Rule 3: Avoid deprecated addresses.
The addresses SA and SB have the same scope. If one of the two
source addresses is "preferred" and one of them is "deprecated" (in
the RFC 2462 sense), then
