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

[Brian Haley <brian.haley@hp.com>]

On 10/14/2011 06:32 PM, Lorenzo Colitti wrote:
> On Fri, Oct 14, 2011 at 13:14, Brian Haley <brian.haley@hp.com> 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.

I think this goes against the intent of RFC 3879 (Deprecating Site Local
Addresses), and it assumes that the user has some knowledge of the network
topology.  When we send something out the carrier interface, we don't know why
it didn't make it to it's final destination - firewall, network link down,
congestion - we might not get the ICMP reason back.

The MIF problem statement (in the RFC editor's queue) talks about this problem,
http://tools.ietf.org/html/draft-ietf-mif-problem-statement-15 - perhaps it's
better to work there to develop a more generic solution (using DHCPv6, RA
options, etc) before making this change?

-Brian