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

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:	Sun, 16 Oct 2011 20:45:19 -0400
From:	Brian Haley <brian.haley@...com>
To:	Lorenzo Colitti <lorenzo@...gle.com>
CC:	maze@...gle.com, yoshfuji@...ux-ipv6.org, netdev@...r.kernel.org
Subject: Re: [PATCH] net: ipv6: Allow netlink to set IPv6 address scope

On 10/14/2011 06:32 PM, Lorenzo Colitti wrote:
> On Fri, Oct 14, 2011 at 13:14, Brian Haley <brian.haley@...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
--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html