Hi,
* Arifumi Matsumoto
> But, your suggestion of Rule 4.5 does more than de-prioritization
> of 6to4 prefix.
It de-prioritizes 6to4 _routers_ - rule 6 is taking care of
de-prioritizing the 6to4 prefix. All put together, this ensures the
source address selection algorithm selects an address wit
Hi,
>> IMO, it's a matter of local network policy whether fe80::bad is
>> really good or bad.
>
> RFC 3484 with the default policy table already considers 6to4 source
> addresses worse than native addresses. I don't think it is
> controversial to similarly consider 6to4 routers as worse than na
Hello again,
* Arifumi Matsumoto
> Correct. But, I think the latter case is less problematic, in that
> it avoids avoidable troubles.
Agreed. While it does not avoid all potential troubles, it does seem
likely that it will cause less problems overall than the current algorithm.
> IMO, it's a m
Hi Tore,
On 2010/11/07, at 19:56, Tore Anderson wrote:
> * Arifumi Matsumoto
>
>> As I said, prioritization between IPv4 and IPv6 is a matter of
>> destination address selection, which my suggestion does not have any
>> effect on. Usually, native IPv6 is preferred over IPv4 in a
>> environmen
* Arifumi Matsumoto
> As I said, prioritization between IPv4 and IPv6 is a matter of
> destination address selection, which my suggestion does not have any
> effect on. Usually, native IPv6 is preferred over IPv4 in a
> environment that you assume here.
>
> In a situation where IPv6 is preferr
Hi,
2010/11/1 Tore Anderson :
> Hello Arifumi,
>
> * Arifumi Matsumoto
>
>> On a host to which my suggestion is applied,
>> if the next-hop is 6to4 advertising host/router, then the source
>> address will be 6to4.
>> If the next-hop is native IPv6 adverting router, then the source
>> address will
Hello Arifumi,
* Arifumi Matsumoto
> On a host to which my suggestion is applied,
> if the next-hop is 6to4 advertising host/router, then the source
> address will be 6to4.
> If the next-hop is native IPv6 adverting router, then the source
> address will be native IPv6.
> And, it's depending on w
Hi,
On 2010/10/27, at 16:00, Ole Troan wrote:
>> Off the top of my head, I thought about a new rule to the RFC 3484.
>> It's really a simple rule, and seems to solve several problematic
>> cases related to address selection.
>> The rule is:
>>
>> Prefer to select an address as the source address
Hi,
thanks for sharing your concern.
My comments below.
On 2010/10/31, at 20:31, Tore Anderson wrote:
> Hi,
>
> * Arifumi Matsumoto
>
>> Off the top of my head, I thought about a new rule to the RFC 3484.
>> It's really a simple rule, and seems to solve several problematic
>> cases related to
Hi,
* Arifumi Matsumoto
> Off the top of my head, I thought about a new rule to the RFC 3484.
> It's really a simple rule, and seems to solve several problematic
> cases related to address selection.
> The rule is:
>
> Prefer to select an address as the source address that is
> assigned by t
On 10/27/10 07:00, Ole Troan wrote:
Prefer to select an address as the source address that is
assigned by the selected next-hop.
I think this is a good idea.
we have talked on and off about it for a long time
> (I actually thought it was written down somewhere).
My alternative addr-sel a
> Off the top of my head, I thought about a new rule to the RFC 3484.
> It's really a simple rule, and seems to solve several problematic
> cases related to address selection.
> The rule is:
>
> Prefer to select an address as the source address that is
> assigned by the selected next-hop.
>
> T
Hi all,
Off the top of my head, I thought about a new rule to the RFC 3484.
It's really a simple rule, and seems to solve several problematic
cases related to address selection.
The rule is:
Prefer to select an address as the source address that is
assigned by the selected next-hop.
This rul
13 matches
Mail list logo