Subject: adding one source address selection rule to rfc3484

From: Arifumi Matsumoto <[email-masked]>
Date: Wed, 27 Oct 2010 15:43:32 +0900

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 rule assumes that the next-hop selection (rule 5) is already
performed before visiting this rule. Also, it assumes the address
assignment and routing are correlated. The second assumption does
not apply to every environment, but typically this is true for
a site that uses RA. 

Any comments ?

--
Arifumi Matsumoto
  NGN System Architecture Project
  NTT Service Integration Laboratories
  E-mail: [email-masked]
  TEL +81-422-59-3334 FAX +81-422-59-6364

---

From: Ole Troan <[email-masked]>
Date: Wed, 27 Oct 2010 09:00:20 +0200

> not apply to every environment, but typically this is true for

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

it doesn't help in the case of multiple levels of routers though.

cheers,
Ole

---

From: Aleksi Suhonen <[email-masked]>
Date: Fri, 29 Oct 2010 11:59:15 +0000

> we have talked on and off about it for a long time
 > (I actually thought it was written down somewhere).

My alternative addr-sel algorithm (*) incorporates this as one of its 
base assumptions and as such I'm of course all for it.

However, in the general case it can prove to be very difficult to 
actually implement. Source address selection usually happens in the 
kernel, but interface address assignment happens in user space in many 
cases. So the kernel probably won't have any feed back method to 
recognize which address is assigned by which next-hop.

My algorithm gets away with this, because it gives this information to 
the kernel in advance. (I.e. the next-hops and source addresses are tied 
together by virtue of having one routing table per source address.)

When trying to figure out how to automate the routing table creation and 
deletion for my algorithm, I've already run into the problem I described 
above....

-- 
	Aleksi Suhonen, Researcher
	Department of Communications Engineering
	Tampere University of Technology

(*) http://tools.ietf.org/html/draft-axu-addr-sel-01

---

From: Tore Anderson <[email-masked]>
Date: Sun, 31 Oct 2010 12:31:15 +0100

Hi,

* Arifumi Matsumoto

> not apply to every environment, but typically this is true for

This would perhaps have solved a problem we just experienced when
bringing native IPv6 service to a network that earlier was IPv4-only and
had big problems with rogue 6to4 routers spamming RAs onto the access LAN:

Before deploying IPv6, RFC 3484-compliant hosts like Windows and Linux
would de-pref the 6to4 addresses that was assigned by the rogue RAs and
use IPv4, and things would work just nicely.

After deploying IPv6, the 3484-compliant hosts have begun having
difficulties connecting to dual-stack destinations.  I believe what is
going wrong is that the presence of a native IPv6 address makes IPv6
preferred but that the next-hop selection is wrong and the outbound
packets are sent to one of the rogue 6to4 routers (probably with the
native IPv6 source address).

However, if you're determining the source address based on an
already-selected next-hop instead of the other way around, won't you
risk ending up preferring a 6to4 source address (and its associated
router) over a native source address and its associated router?  That
would be very undesireable if so.

If not, I support the rule.

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, 1 Nov 2010 11:04:10 +0900

Hi,

thanks for sharing your concern.
My comments below.

> use IPv4, and things would work just nicely.

Yes. this draft also suggests a small change for de-pref 6to4 a little more,
by tweaking precedence field of 6to4.
http://tools.ietf.org/html/draft-ietf-6man-rfc3484-revise-01

> If not, I support the rule.

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.

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.

Best regards,

---

From: Arifumi Matsumoto <[email-masked]>
Date: Mon, 1 Nov 2010 11:15:50 +0900

Hi,

> it doesn't help in the case of multiple levels of routers though.

No.
But its possible when multiple instances of router are running and are assigned
different addresses at a intermediate router.