Re: [PATCH] net: ipv6: Allow netlink to set IPv6 address scope

On Fri, Oct 14, 2011 at 13:14, Brian Haley [off-list ref] wrote:

Playing devil's advocate here, isn't this a brain-dead ISP?  If they're
giving you a global IPv6 address you should get Internet connectivity
with it.  If not, you probably knew it up front, or you're going to find
another provider that does.  It's like they're giving you a site-local
address...

I wouldn't say they're a brain-dead carrier, because they also give you
true IPv6 connectivity on another interface. The phone will deactivate
this interface when bringing up wifi, because wifi is usually cheaper and
faster. However, the carrier interface needs to stay up all the time
in order to do such things as provisioning, send and receive SMS
messages, handle voice over IP calls, and so on. So you will have
cases where the phone's primary Internet connection is over wifi, but
the phone still has a global unicast IPv6 address on the carrier interface.

So are you talking about being able to dynamically change the scope
of an address?  Wifi comes up - change provider addreses to host-
local, wifi goes down - change it back to global.  That looks like a
hack.

What I'm suggesting is to have the carrier interface be created with
site scope and stay up forever (or as long as the phone is on the cell
network). If an application wants to use the carrier interface, it will create
host routes that explicitly specify the carrier interface and the source
address of the carrier interface.

Applications that don't use the carrier interface will not have to do
anything special; if you set the carrier interface to site scope,
the kernel should just do the right thing.

A default route with only a link-local address isn't very useful.  Will the
kernel ever use this interface with the global address of your carrier -
isn't it going to prefer the interface that address is configured on?

No, it will use the carrier address, because RFC3484 says "avoid
deprecated addresses" (rule 3) before it says "prefer outgoing interface"
(rule 5).

That's a pretty small window where the address is in tentative state (< 2 sec), and re-trying shortly after will work.

That's true, but as the application you don't know that. You just call
connect(), and sit there and hang. There's a lot of applications that want
to reconnect as soon as they see that wifi has come up, and they all
get stuck.

You can also use routing rules, like anyone that does dual-homed
with IPv4 does  - only use 1.2.3.4 on eth0, and only use 4.3.2.1 on
eth1.

That doesn't work, because when the kernel creates a new TCP
connection, its source address is empty, so no source-based rules
match. More specifically, if I do (assume the carrier IP address is
2001:db8::1/64):

ip -6 rule add prio 100 from 2001:db8::/64 lookup 100
ip -6 route add table 100 unreachable default
ip -6 route add default via fe80::1 dev wlan0

the system will still use the address from the carrier interface. I think
this is by design though.

And there's also gai.conf, although I haven't played with that in a
while.

gai.conf only handles destination address selection; the kernel
handles source address selection.

The other trick/hack is to change the preferred lifetime of an address
to zero, which should mark it deprecated, moving it down in the
selection list.

That will work, but I think it's more of a hack than setting scope to
site. The carrier address is not deprecated, it's perfectly
functional. It just can't reach the Internet, but only a part of it.
So I think that calling it scoped is the solution that makes the most
sense.

What else will break though?  If I configure fe80::1/64 and set the
scope to global, do applications know to look at ifa_scope and not
just the address itself to determine the scope?  Should they?

If the application treats scoped addresses specially, it will treat
fe80::1 as link-local scope, and will do things like check
sin6_scope_id to see if it's unique. On balance, I think that's the
right thing to do for an application in this situation, since, as
above, it's the network that truly decides what scope an address is
unique in, not the application or the kernel, and I would expect the
rest of the network to treat fe80::/64 as link-local (for example,
routers won't forward it, and so on).

The kernel, on the other hand, will try to use fe80::1 as if it were a
global address for the purposes of source address selection, but after
all, that's what you asked it to do, so you can't really blame it.

Make sense?