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 native
> routers by default.
>
> Besides, a large majority of the 6to4 routers on the internet today are
> indeed unwanted and cause very bad results for people like me that want
> to deploy IPv6 services in a reliable manner.
I agree.
But, your suggestion of Rule 4.5 does more than de-prioritization
of 6to4 prefix.
Rule 4.5: Avoid next-hops that have assigned candidate source
addresses whose labels do not match Label(D).
>> As you mention it, I think the simplicity came from modularization
>> of destination address selection, route (next-hop) selection, and
>> source address selection, brings much benefits to implementing and
>> understanding the protocol stack.
>>
>> So, if you break it, we really have to be careful about its benefits
>> and side effects.
>
> I can see that. There's in my opinion a clear benefit to making sure
> that both 1) the best available source address is selected, and 2) the
> next-hop used is appropriate for the source address used. (Your new
> rule sacrifices #1 to achieve #2 the way I see it.)
It may be yes in the case of rogue 6to4 RA.
But, what matters is if it can always select the best address, or
expected to select the best in most reasonable environment.
> Since next-hop selection is so tightly coupled with source address
> selection I think it makes lots of sense to handle both in RFC 3484.
IMO, it's closely related with a certain rule followed.
>
>>> BTW: With your new rule active, and if the destination in my
>>> example situation above is dual-stacked, do I understand correctly
>>> that if the selected source address for the IPv6 destination
>>> address ends up being the 6to4 one (SA, in my example above), then
>>> IPv4 will be preferred, thanks to rule 5 of the destination address
>>> selection algorithm?
>>>
>>> If that is the case would be a great help with dual-stack
>>> brokenness. Even though preferring IPv4 where native IPv6 is
>>> available isn't optimal, it's much better than accidentally
>>> preferring 6to4 (either source address or next-hop) to, well,
>>> pretty much anything else.
>>
>> I think it is correct, as far as the IPv4 address is global, or IPv4
>> private address scope is changed to global as proposed in my draft.
>>
>> And, I think this should be a reasonable compromise for this specific
>> case.
>
> Good. I support adding your new rule. It's a step forward compared to
> RFC 3484, even though it doesn't get us all the way. And it won't
> prevent us from adding the final piece of the puzzle (i.e. next-hop
> selection logic) later.
Great. I really appreciate we could have good discussion here.
Can I have your opinion about other remaining issues of this item ?
Such as The longest match rule in section B.4 ?
--------------------------------------------------------------------
IETF IPv6 working group mailing list
ipv6@ietf.org
Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------
