Subject: Re: adding one source address selection rule to rfc3484

From: Tore Anderson <[email-masked]>
Date: Mon, 01 Nov 2010 10:05:57 +0100

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.

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.

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.

> 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.

Best regards,
-- 
Tore Anderson
Redpill Linpro AS - http://www.redpill-linpro.com
Tel: +47 21 54 41 27

---

From: Arifumi Matsumoto <[email-masked]>
Date: Tue, 2 Nov 2010 02:10:33 +0900

Hi,

> 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.

> 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.

> 6to4 is preferred over both native IPv4 and IPv6 - a _very_ undesirable

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

> 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.

> --------------------------------------------------------------------
> IETF IPv6 working group mailing list
> [email-masked]
> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
> --------------------------------------------------------------------
>

---

From: Tore Anderson <[email-masked]>
Date: Sun, 07 Nov 2010 11:56:19 +0100

* 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.
> 
> 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.

Hi again,

upon re-reading 3484 I agree I'm mistaken in thinking this will have any
effect on IPv4 vs IPv6 being used.  My apologies.

There's one situation that I'm still not entirely sure about though.
Imagine a host with two IPv6 addresses (and only one network interface):

SA) 2002:f00::1/64
SB) 2001:db8::1/64

It has two default routes, same RA router preference, next-hops are:

R1) fe80::bad <-- a 6to4 rogue router, assigned us SA
R2) fe80::1   <-- a "proper" router, assigned us SB

The destination address D is a native IPv6 address - say
2001:db8:1234::1.  Single-stack IPv6 only so the destination address
selection doesn't come into play.

My understanding of the current RFC 3484 source address selection, rule
5 would be a tie (as there's only one interface on the host), and rule 6
would ensure SB would be the chosen as Label(SB) = Label(D).

However, this does not in any way preclude the host from transmitting
the packet (with src=2001:db8::1 and dst=2001:db8:1234::1) to R1, the
6to4 router.  That will break.  I have recent real-world experience
where it seems very likely that this is the cause of a large amount of
dualstack brokenness.  (See the ipv6-ops mailing list in case you're
interested in that story.)

Your proposal, the way I understand it, will add a rule 5.5 that would
ensure that in the above case, since the next-hop used is R1, the
selected source address is SA.  That means preferring 6to4 to native
IPv6, something which will also break.

Please let me know if I've misunderstood something here.

Note that I'm not saying that the new rule makes the algorithm any worse
than it already is.  I just think it could go further;  I would like to
see the algorithm ensure that both SB and R2 are selected.  Since we're
already revising RFC 3484 anyway, it would be a shame to not use the
opportunity to also fix this properly, in my opinion.

Perhaps something along the lines of (note: in addition to your rule
5.5, not replacing it):

  Rule 4.5:  Avoid next-hops that have assigned candidate source
             addresses whose labels do not match Label(D).

But perhaps interfering with next-hop selection is outside the scope of
RFC 3484?

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.

Best regards,
-- 
Tore Anderson
Redpill Linpro AS - http://www.redpill-linpro.com/
Tel: +47 21 54 41 27

---

From: Arifumi Matsumoto <[email-masked]>
Date: Mon, 8 Nov 2010 01:53:08 +0900

Hi Tore,

> effect on IPv4 vs IPv6 being used.  My apologies.

No problem. I'm really glad that you got what I meant.

> Please let me know if I've misunderstood something here.

Correct.
But, I think the latter case is less problematic, in that
it avoids avoidable troubles.

IMO, it's a matter of local network policy whether fe80::bad
is really good or bad.

> But perhaps interfering with next-hop selection is outside the scope of

Thank you for providing a constructive suggestion. 

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.

> 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.

Best regards,

Arifumi Matsumoto

---

From: Tore Anderson <[email-masked]>
Date: Sun, 07 Nov 2010 19:43:15 +0100

Hello again,

* Arifumi Matsumoto

> Correct. But, I think the latter case is less problematic, in that

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 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.

> of destination address selection, route (next-hop) selection, and
> source address selection, brings much benefits to implementing and 
> understanding the protocol stack.
> 

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.)

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.

>> 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.
> 

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.

Best regards,

---

From: Arifumi Matsumoto <[email-masked]>
Date: Mon, 8 Nov 2010 11:44:00 +0900

Hi,

> 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 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.

> selection I think it makes lots of sense to handle both in RFC 3484.

IMO, it's closely related with a certain rule followed.

> prevent us from adding the final piece of the puzzle (i.e. next-hop

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 ?

---

From: Tore Anderson <[email-masked]>
Date: Mon, 08 Nov 2010 09:38:18 +0100

Hi,

* Arifumi Matsumoto

> But, your suggestion of Rule 4.5 does more than de-prioritization

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 with a label that
matches the destination (if available), and that the next-hop is
appropriate for the selected next-hop.

We do agree that getting the source and destination labels to match is a
good thing, right?  (For what it's worth, rule 6 already codifies it.)
At least I have a hard time picturing a scenario where you would want to
use non-matching labels if matching labels are available.

As an added bonus, when Teredo and other non-native forms of
connectivity is added to the policy table with different labels than
native, you get the same de-prioritizing effect for them as well.

> Great. I really appreciate we could have good discussion here.

Likewise!  :-)

> Such as The longest match rule in section B.4 ?

Certainly:

B.1:  No strong opinion either way.

B.2:  We should go to great lengths to ensure that IPv4 (and native
IPv6) is prioritized above transitional IPv6 like Teredo and especially
6to4.  Overuse of transitional IPv6 is causing lots of problems and is
_the_ reason why there's essentially no IPv6 content generally available
on the internet today.

There are three proposed changes that together accomplish this goal.
In order of importance (in my opinion):

1) Changing RFC 1918 address scope to global:  prevents transitional
   IPv6 from being used in preference to (NAT-ed) IPv4.
2) Your rule 5.5:  prevents transitional IPv6 from being used
   in preference to IPv4 or native IPv6 in dual-stack situations.
3) My rule 4.5: prevents transitional IPv6 from being used in
   preference to native IPv6 in single-stack situations.

B.3:  IMHO, IPv6 isn't deployed enough that we need to go to great
lengths to maintain backwards compatibility with outdated
implementations.  So I'd remove the outdated cruft.  But I don't feel
very strongly about it.

B.4:  My personal opinion of the longest match rule is that it should be
scrapped.  IPv6 isn't hierarchical anymore and the DNS round robin
technique is as useful in IPv6 as in IPv4 - it's something worth not
breaking.  I can't say I like the idea of applying a limit on how many
bits you will compare either as that's basically just making a guess on
how operators will structure their networks.  I suspect that providers
that are interested in the functionality the longest match rule attempts
to provide, will instead be using some kind of split-horizon DNS solution.

Best regards,