IETF Logo Mail Archive

Re: [homenet] I-D Action: draft-haddad-homenet-multihomed-00

Michael Thomas <mike@mtcc.com> Thu, 25 October 2012 16:30 UTC

Return-Path: <mike@mtcc.com>
X-Original-To: homenet@ietfa.amsl.com
Delivered-To: homenet@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A463921F893C for <homenet@ietfa.amsl.com>; Thu, 25 Oct 2012 09:30:17 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.569
X-Spam-Level:
X-Spam-Status: No, score=-2.569 tagged_above=-999 required=5 tests=[AWL=0.030, BAYES_00=-2.599]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oW4YuAyVPnXq for <homenet@ietfa.amsl.com>; Thu, 25 Oct 2012 09:30:17 -0700 (PDT)
Received: from mtcc.com (mtcc.com [IPv6:2001:5a8:4:9fe0:224:8cff:feaa:6d9b]) by ietfa.amsl.com (Postfix) with ESMTP id D3EF721F892C for <homenet@ietf.org>; Thu, 25 Oct 2012 09:30:16 -0700 (PDT)
Received: from takifugu.mtcc.com (takifugu.mtcc.com [50.0.18.224]) (authenticated bits=0) by mtcc.com (8.14.3/8.14.3) with ESMTP id q9PGUDR3004585 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO) for <homenet@ietf.org>; Thu, 25 Oct 2012 09:30:13 -0700
Message-ID: <50896915.6080404@mtcc.com>
Date: Thu, 25 Oct 2012 09:30:13 -0700
From: Michael Thomas <mike@mtcc.com>
User-Agent: Mozilla/5.0 (X11; U; Linux i686 (x86_64); en-US; rv:1.8.1.22) Gecko/20090605 Thunderbird/2.0.0.22 Mnenhy/0.7.5.0
MIME-Version: 1.0
To: homenet@ietf.org
References: <201210011801.q91I1tfW056624@gateway1.orleans.occnc.com> <10328E81-3C94-455B-9A37-B421200A5C38@ecs.soton.ac.uk> <EMEW3|19238916f7ff9a0ada655caf80bba8cao9AAbJ03tjc|ecs.soton.ac.uk|10328E81-3C94-455B-9A37-B421200A5C38@ecs.soton.ac.uk> <7F6EA97D-5DA8-4872-A647-D879B1955824@gmail.com> <49FCFE49-9DFB-44D2-ADAD-636A3C80F906@ecs.soton.ac.uk> <EMEW3|09bc323dc12a06be7c21e18f2752cd05o9LECn03tjc|ecs.soton.ac.uk|49FCFE49-9DFB-44D2-ADAD-636A3C80F906@ecs.soton.ac.uk> <7F4B245F-9355-4134-9176-EB7DB1634469@apple.com> <77A8749D-DF81-4816-8277-CB69861E524A@fugue.com> <C3720598-400C-4B83-9CEC-878B3FA8109E@ecs.soton.ac.uk> <EMEW3|3e5d3f7836c5b4ddbd99d74df88ecc6ao9LJ8r03tjc|ecs.soton.ac.uk|C3720598-400C-4B83-9CEC-878B3FA8109E@ecs.soton.ac.uk> <5085905A.8030206@mtcc.com> <52E31542-3B7C-4EC1-9B2C-3C9D8E6B3BB1@apple.com> <50859C1B.7070707@mtcc.com> <CAKD1Yr0v3NdN+QCj=jFiZcv0ox1S-YAj29dZyMd6kAWAv723dg@mail.gmail.com> <5086B5A7.3040706@mtcc.com> <0435F886-1E8B-4302-832F-C9D0269981A4@apple! .com>
In-Reply-To: <0435F886-1E8B-4302-832F-C9D0269981A4@apple.com>
Content-Type: text/plain; charset="ISO-8859-1"; format="flowed"
Content-Transfer-Encoding: 7bit
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=1388; t=1351182616; x=1352046616; c=relaxed/simple; s=thundersaddle.kirkwood; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=mtcc.com; i=mike@mtcc.com; z=From:=20Michael=20Thomas=20<mike@mtcc.com> |Subject:=20Re=3A=20[homenet]=20I-D=20Action=3A=20draft-had dad-homenet-multihomed-00 |Sender:=20 |To:=20homenet@ietf.org |Content-Type:=20text/plain=3B=20charset=3DISO-8859-1=3B=20 format=3Dflowed |Content-Transfer-Encoding:=207bit |MIME-Version:=201.0; bh=vi3cqnALLoRQFPJF2Uro/46NIKKXnVGvN/OCgo/bNI8=; b=NlliAOUuT9atL4hI2oWlotnx2k+UCSbjSuE9f4dHadLj9EywhS/h117Aki mu9TxC4dYy/dSnWVumEAs7ZPDWaiSeXtA8XdZ3q4oLooitttGZvda3BGQx5b CRZWED0zTc/RZ05uXmXUVgQs03Kc5L71oUykI8XNmFE9B/y5/hvgg=;
Authentication-Results: ; v=0.1; dkim=pass header.i=mike@mtcc.com ( sig from mtcc.com/thundersaddle.kirkwood verified; ); dkim-asp=pass header.From=mike@mtcc.com
Subject: Re: [homenet] I-D Action: draft-haddad-homenet-multihomed-00
X-BeenThere: homenet@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: <homenet.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/homenet>, <mailto:homenet-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/homenet>
List-Post: <mailto:homenet@ietf.org>
List-Help: <mailto:homenet-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/homenet>, <mailto:homenet-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 25 Oct 2012 16:30:17 -0000

On 10/23/2012 11:01 AM, james woodyatt wrote:
> On Oct 23, 2012, at 08:20 , Michael Thomas <mike@mtcc.com> wrote:
>> On 10/22/2012 08:35 PM, Lorenzo Colitti wrote:
>>> Can you explain why this behaviour, combined with the "prefer matching interface" rule in RFC 3484, is not sufficient? If not, then there is no problem to solve here.
>> Your ISP gives you 2001:xxxx:: via SLAAC. Your employer gives you 2000::,
>> but also has 2001:yyyy::. You connect to a server on 2001:yyyy::. Your
>> 3484 v6 stack picks 2001:xxxx for the source address. Hilarity ensues:
> My IPv6 stack doesn't pick a 2001:xxxx:... address.  When the VPN client connects, it inserts a more-specific host route to 2001:yyyy::/z via the VPN pseudo-interface, so the IPv6 stack picks the interface address assigned by the VPN access concentrator as the source address for application flows to the 2001:yyyy:/z network.
>
> Hilarity does not ensue. Happy faces on the security team.
>
>

As I alluded to in my previous note, this doesn't work unless the vpn is
terminated in host devices. When it's router-router, it fails as I mentioned
because the hosts are clueless. I expect that walled off overlay networks
will be more rather than less prevalent in v6, especially when homenets
are truly visible -- though access controlled -- from the outside which is
pretty untrue today with v4/nat.

Mike

v2.23.0 | Report a Bug | By Email