Re: [mif] Route option for DHCPv6 - next steps?

Margaret Wasserman <mrw@lilacglade.org> Fri, 30 March 2012 07:21 UTC

Return-Path: <mrw@lilacglade.org>
X-Original-To: mif@ietfa.amsl.com
Delivered-To: mif@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 35B7A21E80B1 for <mif@ietfa.amsl.com>; Fri, 30 Mar 2012 00:21:44 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.287
X-Spam-Level:
X-Spam-Status: No, score=-102.287 tagged_above=-999 required=5 tests=[AWL=-0.023, BAYES_00=-2.599, HTML_MESSAGE=0.001, IP_NOT_FRIENDLY=0.334, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id J6cp06CLXMp6 for <mif@ietfa.amsl.com>; Fri, 30 Mar 2012 00:21:43 -0700 (PDT)
Received: from permutation-city.suchdamage.org (permutation-city.suchdamage.org [69.25.196.28]) by ietfa.amsl.com (Postfix) with ESMTP id 29D7921E80B0 for <mif@ietf.org>; Fri, 30 Mar 2012 00:21:43 -0700 (PDT)
Received: from dhcp-43e9.meeting.ietf.org (dhcp-43e9.meeting.ietf.org [130.129.67.233]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (Client did not present a certificate) by mail.suchdamage.org (Postfix) with ESMTPSA id 594992021E; Fri, 30 Mar 2012 03:20:53 -0400 (EDT)
Mime-Version: 1.0 (Apple Message framework v1084)
Content-Type: multipart/alternative; boundary="Apple-Mail-15-450089456"
From: Margaret Wasserman <mrw@lilacglade.org>
In-Reply-To: <8D23D4052ABE7A4490E77B1A012B6307472D45F6@mbx-01.win.nominum.com>
Date: Fri, 30 Mar 2012 09:21:31 +0200
Message-Id: <550B9F79-1642-469F-9ED3-96DA26AA40AB@lilacglade.org>
References: <75459BC2-E733-45C0-BC1C-25A19BBA1137@gmail.com> <CAE97176.17DF4%wdec@cisco.com> <CANF0JMD_zfXGcfMy+rCOFXS1aCZ3RPHoRtkBeS8kDgOFcfQ8Fg@mail.gmail.com> <75D251D1-9828-4AFE-9BEF-B376E97133C7@nominum.com> <CANF0JMBbhrF0G=hSvcvyZAddAMW7oSO5KpzUmcJXCtwcnmyWOw@mail.gmail.com> <4A221CE5-ECF0-4E07-9329-E6BAA3F06A96@nominum.com> <4EC4AADB.8030803@piuha.net> <DD1241D5-B794-49C3-A3A2-4294248DDD10@gmail.com> <4F719186.3060507@gmail.com> <CAKD1Yr3tSoDPcheriWdZEeKyhqpDANCP7Co0wVVqK5+mXc7e5A@mail.gmail.com> <4F72CD22.3080604@gmail.com> <CAKD1Yr3RUUthiawKrmxjSNqzEbJcOLpHvDGb9XLtdiU-tfEYyw@mail.gmail.com>, <4F744831.3070406@gmail.com> <8D23D4052ABE7A4490E77B1A012B6307472D4175@mbx-01.win.nominum.com> <4F7453FC.3010502@gmail.com> <4F74546D.4060808@gmail.com>, <72C42575-6BE2-4F27-B7F4-AA4539DA7EF9@lilacglade.org> <8D23D4052ABE7A4490E77B1A012B6307472D43A1@mbx-01.win.nominum.com>, <069301cd0dd2$5954df00$0bfe9d00$@tndh.net> <8D23D4052ABE7A4490E77B1A012B6307472D45F6@mbx-01.win.nominum.com >
To: Ted Lemon <Ted.Lemon@nominum.com>
X-Mailer: Apple Mail (2.1084)
Cc: "mif@ietf.org" <mif@ietf.org>
Subject: Re: [mif] Route option for DHCPv6 - next steps?
X-BeenThere: mif@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Multiple Interface Discussion List <mif.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/mif>, <mailto:mif-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/mif>
List-Post: <mailto:mif@ietf.org>
List-Help: <mailto:mif-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/mif>, <mailto:mif-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 30 Mar 2012 07:21:44 -0000

Hi Ted,

On Mar 29, 2012, at 11:37 PM, Ted Lemon wrote:
> 
> Tony, if you really think this option is a good idea, can you send me some email explaining why you think it is, privately, since the working group is at least temporarily not working on this?   I'd like to get some clarity on the reasons why people want this that can be used next time it comes up, so that we have a clear set of use cases to present next time.  The VPN split tunnel case isn't familiar to me.

Actually, this topic is still in the MIF charter, and there was pretty strong consensus that we still want to work on a solution to this problem.

What there wasn't consensus on, unfortunately, is whether we should specify a DHCPv6 option to solve it -- ~12 people thought we should, and ~18 people thought we should consider something else (unspecified).  Sadly, those 18 people probably won't unite around a single alternative, so what we have is a bit of a mess...

I think it would make sense to document a couple of solid use cases where we think that something like this is needed, and current RAs can't or don't solve the problem.  

Tony, it sounds like you have a specific VPN use-case in mind, could you elaborate?

As I understand it, there is a need to get routes to cell phones that tell them that certain services (ones that are only accessible over 3GPP) need to be routed via the 3GPP interface, not via the 802.11 interface, even if 802.11 is cheaper, faster and preferred for general traffic.  I am wondering if this is essentially the same as the VPN use case?  Is there a reason why routes could not be transmitted over ND for this purpose, though?

One alternative that was raised at the mic, but that has not (to my knowledge actually been proposed anywhere) was the use of unicast ND for cases when you want to configure different routes on different nodes.  Are there problems in this space that would not be solved by doing that?  If so, what are they?  If not, perhaps we need to write up a unicast ND mechanism?

Margaret