Re: adding one source address selection rule to rfc3484

[Arifumi Matsumoto <[e-mail]>]

Hi,

2010/11/1 Tore Anderson <[e-mail]>:
> 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 which gateway the host uses for the default
>> route.
>> So, it does not solve the whole issue of rogue 6to4 RA.
>
> The way I understand it, if you select the next-hop prior to selecting
> the best source/destination address pair, you end up pre-empting the
> address table completely.  To avoid that I think you have to determine
> the appropriate next-hop _after_ the source/destination address.

The RFC 3484 source address selection rule 5 already makes use of the
information of which outgoing interface is:

   Rule 5:  Prefer outgoing interface.
   If SA is assigned to the interface that will be used to send to D
   and SB is assigned to a different interface, then prefer SA.

My suggestion is to add a rule below this rule 5, or extending this rule to
refer to the next-hop as well as the interface.

So, I believe it does not break the existing address selection.

>
> I can picture how it would break otherwise.  Imagine a host with the
> following IP addresses configured on its ethernet interface:
>
> A 192.0.2.10/24
> B 2002:c000:0264:0:21d:60ff:fe48:f59e/64
> C 2001:db8::21d:60ff:fe48:f59e/64
>
> And associated routes:
>
> A 0.0.0.0/0 next-hop 192.0.2.1
> B ::/0 next-hop fe80::1
> C ::/0 next-hop fe80::2
>
> Failure scenario 1:
>
> The host picks route A as its selected next-hop.  Your rule, applied
> after next-hop selection, will ensure the host use 192.0.2.10 as its
> source address when connecting to a dual-stacked destination.  This
> would cause IPv4 to be preferred over (native) IPv6, which is not desired.

The destination address selection determines first which to use IPv4 or IPv6
in this case. The destination address selection determines IPv4 or IPv6, and
the source address selection determines which IPv4 or IPv6 address to use
which consulting the routing table.

> Failure scenario 2:
>
> The host picks route B as its next-hop.  Your rule will then ensure that
> it ends up using 2002:c000:0264:0:21d:60ff:fe48:f59e as its source
> address when connecting to a dual-stacked destination.  In other words,
> 6to4 is preferred over both native IPv4 and IPv6 - a _very_ undesirable
> effect.

My suggestion does not worse this problem, because it does not touch
the destination address selection, and the next-hop selection.

>
>> However, the good thing is that if we adopt this rule, then we can
>> use next-hop preference to avoid the undesirable effects of rogue
>> RA. That is, if the legitimate RA has higher preference than a rogue
>> RA, in RFC 4191 sense, then the host does not use either the next-hop
>> or the source address given from rogue RA.
>
> That is true, however it does not help with distinguishing between IPv4
> and IPv6 next-hops.  You cannot statically prefer IPv6 next-hops over
> IPv4 next-hops either, as that will cause 6to4 to be preferred over IPv4
> in the case of a rogue RA;  nor vice verca, as that would cause IPv4 to
> be preferred to native IPv6.

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 preferred over IPv4, my suggestion makes
the 6to4 address will be chosen for the 6to4 next-hop, and native IPv6
address will be chosen for the native IPv6 next-hop. That's all.


BTW,
for the purpose of tweaking IPv4 and IPv6 prioritization, I propose another
mechanism that distributes the address selection policy table via DHCP.
http://datatracker.ietf.org/doc/draft-fujisaki-6man-addr-select-opt/

I know a lot of people are in need of this kind of control method of host's
address selection behavior. But, here in this 6man ML, we did not have
much discussion yet. I'm glad to have comments on that, too.

>
> Best regards,
> --
> Tore Anderson
> Redpill Linpro AS - http://www.redpill-linpro.com
> Tel: [phone]
> --------------------------------------------------------------------
> IETF IPv6 working group mailing list
> [e-mail]
> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
> --------------------------------------------------------------------
>