From brian.e.carpenter@gmail.com Thu Mar 1 14:56:27 2012 Return-Path: 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 6ACF321F8AFE for ; Thu, 1 Mar 2012 14:56:27 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.51 X-Spam-Level: X-Spam-Status: No, score=-103.51 tagged_above=-999 required=5 tests=[AWL=0.089, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, 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 qp1qvg1S7yyP for ; Thu, 1 Mar 2012 14:56:27 -0800 (PST) Received: from mail-ee0-f44.google.com (mail-ee0-f44.google.com [74.125.83.44]) by ietfa.amsl.com (Postfix) with ESMTP id AB31E21F8A0D for ; Thu, 1 Mar 2012 14:56:26 -0800 (PST) Received: by eeke51 with SMTP id e51so412957eek.31 for ; Thu, 01 Mar 2012 14:56:25 -0800 (PST) Received-SPF: pass (google.com: domain of brian.e.carpenter@gmail.com designates 10.14.99.204 as permitted sender) client-ip=10.14.99.204; Authentication-Results: mr.google.com; spf=pass (google.com: domain of brian.e.carpenter@gmail.com designates 10.14.99.204 as permitted sender) smtp.mail=brian.e.carpenter@gmail.com; dkim=pass header.i=brian.e.carpenter@gmail.com Received: from mr.google.com ([10.14.99.204]) by 10.14.99.204 with SMTP id x52mr4325484eef.7.1330642585947 (num_hops = 1); Thu, 01 Mar 2012 14:56:25 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:organization:user-agent:mime-version:to :subject:references:in-reply-to:content-type :content-transfer-encoding; bh=lM5ZG42vST/4yhLljd0/nGlJRyEBugKx6SmSh578cCs=; b=Skkj6G/ve2RGpTy/hMZisLeCT6WLs8FC94EVIVg9zqmkj+H0hQxs+AiQotkQf3V9p/ T+eq1W1aOSCPtDA8H+JWlsW3GeIJfZsB5l6phjE7+kugMNJkK5VLlZCqmaZ9LmHDW2JN kZcHWCCx6vhxTjMS/ajV1pbZCkvEe1/UzMpxzGT5xrAdpMdZgC45+17+zbjEmMEci3gK /dhMPBWiIVnO6r0MHBpN1YJBEx24/plvmnd3OZQkP9lwDeBFYOKER967NP6VqQAD565m 11Ctwx5MP6Wqk98xehPq+FSgN2rmOGhYh71NBHIIuHv1/+hzyF3oHd6rZ7B80PtTZR42 nMiw== Received: by 10.14.99.204 with SMTP id x52mr3316190eef.7.1330642585843; Thu, 01 Mar 2012 14:56:25 -0800 (PST) Received: from [10.1.1.4] ([121.98.251.219]) by mx.google.com with ESMTPS id u9sm12562272eem.11.2012.03.01.14.56.23 (version=SSLv3 cipher=OTHER); Thu, 01 Mar 2012 14:56:25 -0800 (PST) Message-ID: <4F4FFE91.8020906@gmail.com> Date: Fri, 02 Mar 2012 11:56:17 +1300 From: Brian E Carpenter Organization: University of Auckland User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: mif@ietf.org References: <20120301144229.28186.7229.idtracker@ietfa.amsl.com> In-Reply-To: <20120301144229.28186.7229.idtracker@ietfa.amsl.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Subject: Re: [mif] I-D Action: draft-mglt-mif-security-requirements-00.txt X-BeenThere: mif@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multiple Interface Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 01 Mar 2012 22:56:27 -0000 Hi, I don't understand the scope or the threat model for this draft. The scope seems to be less than the whole of MIF. It seems to be limited to a subset of MIF cases where a provider is in some way in control of the acquisition and use of additional interfaces. In the general case, nobody is in control - the user device simply discovers and uses whatever connectivity appears. If this is a correct understanding, could the title, Abstract and Introduction make it very clear what the scope is? I don't understand the threat model because it isn't described at all. So I can't evaluate any of the assertions about security requirements. I do know that a conclusion that IPsec must be used for everything is very unpalatable. There are risks in any public WLAN of course, but they exist whatever crypto is used. One detail: > Alternate IP addresses are provided for a given > communication, a Primary IP addresses is replaced by an > Alternate IP address, and Primary and Alternate are not used > simultaneously for the same communication. This is not true if the device uses recent techniques such as MPTCP, which automatically shares the available paths. Such end to end techniques are outside the control of the provider. Brian From internet-drafts@ietf.org Mon Mar 5 17:23:58 2012 Return-Path: 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 77F5921E807F; Mon, 5 Mar 2012 17:23:58 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.583 X-Spam-Level: X-Spam-Status: No, score=-102.583 tagged_above=-999 required=5 tests=[AWL=0.016, BAYES_00=-2.599, 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 V2VaLDpSGWE5; Mon, 5 Mar 2012 17:23:58 -0800 (PST) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F27C521E805B; Mon, 5 Mar 2012 17:23:57 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 4.00 Message-ID: <20120306012357.24704.1008.idtracker@ietfa.amsl.com> Date: Mon, 05 Mar 2012 17:23:57 -0800 Cc: mif@ietf.org Subject: [mif] I-D Action: draft-ietf-mif-api-extension-00.txt X-BeenThere: mif@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multiple Interface Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 06 Mar 2012 01:23:58 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Multiple Interfaces Working Group of = the IETF. Title : MIF API consideration Author(s) : Dapeng Liu Ted Lemon Yuri Ismailov Zhen Cao Filename : draft-ietf-mif-api-extension-00.txt Pages : 17 Date : 2012-03-04 This document describes an abstract API that provides the minimal functionality required for a program to communicate effectively with peers and services on the network while running on a host that has more than one active network interface. This API is abstract: we describe the functionality that must be provided, not the bindings that should be used to provide that functionality. The functionality described here provides the building blocks from which higher-level APIs might be built, and is not intended to be used directly by typical applications. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-mif-api-extension-00.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ This Internet-Draft can be retrieved at: ftp://ftp.ietf.org/internet-drafts/draft-ietf-mif-api-extension-00.txt From alexandru.petrescu@gmail.com Mon Mar 12 10:11:53 2012 Return-Path: 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 952EC21F8760 for ; Mon, 12 Mar 2012 10:11:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.359 X-Spam-Level: X-Spam-Status: No, score=-6.359 tagged_above=-999 required=5 tests=[AWL=-0.110, BAYES_00=-2.599, HELO_EQ_FR=0.35, RCVD_IN_DNSWL_MED=-4] 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 LPG-VqtlE+bE for ; Mon, 12 Mar 2012 10:11:52 -0700 (PDT) Received: from sainfoin-out.extra.cea.fr (sainfoin-out.extra.cea.fr [132.167.192.144]) by ietfa.amsl.com (Postfix) with ESMTP id 5C3B621F877F for ; Mon, 12 Mar 2012 10:11:51 -0700 (PDT) Received: from pisaure.intra.cea.fr (pisaure.intra.cea.fr [132.166.88.21]) by sainfoin.extra.cea.fr (8.14.2/8.14.2/CEAnet-Internet-out-2.3) with ESMTP id q2CHBnE0017692 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT) for ; Mon, 12 Mar 2012 18:11:49 +0100 Received: from muguet2.intra.cea.fr (muguet2.intra.cea.fr [132.166.192.7]) by pisaure.intra.cea.fr (8.14.4/8.14.4) with ESMTP id q2CHBngd002635 for ; Mon, 12 Mar 2012 18:11:49 +0100 (envelope-from alexandru.petrescu@gmail.com) Received: from [127.0.0.1] (is010446-4.intra.cea.fr [10.8.33.116]) by muguet2.intra.cea.fr (8.13.8/8.13.8/CEAnet-Intranet-out-1.2) with ESMTP id q2CHBjhg011494 for ; Mon, 12 Mar 2012 18:11:49 +0100 Message-ID: <4F5E2E52.9070408@gmail.com> Date: Mon, 12 Mar 2012 18:11:46 +0100 From: Alexandru Petrescu User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:10.0.2) Gecko/20120216 Thunderbird/10.0.2 MIME-Version: 1.0 To: mif Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: [mif] Updated draft-mouton-mif-dhcpv6-drlo-01.txt, no major change X-BeenThere: mif@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multiple Interface Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 12 Mar 2012 17:11:53 -0000 Dear MIF WG, We have updated draft-mouton-mif-dhcpv6-drlo-01.txt which describes the use of a Default Router List Option with DHCPv6: http://tools.ietf.org/html/draft-mouton-mif-dhcpv6-drlo-01 There is only one minor change in affiliation of a co-author. I have suggested in private to Chairs a short slot for presentation at Paris meeting. Alex From alexandru.petrescu@gmail.com Mon Mar 12 10:16:21 2012 Return-Path: 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 179E121F8871 for ; Mon, 12 Mar 2012 10:16:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.341 X-Spam-Level: X-Spam-Status: No, score=-6.341 tagged_above=-999 required=5 tests=[AWL=-0.092, BAYES_00=-2.599, HELO_EQ_FR=0.35, RCVD_IN_DNSWL_MED=-4] 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 Yn038FoyXMEp for ; Mon, 12 Mar 2012 10:16:20 -0700 (PDT) Received: from sainfoin-out.extra.cea.fr (sainfoin-out.extra.cea.fr [132.167.192.144]) by ietfa.amsl.com (Postfix) with ESMTP id A074F21F8865 for ; Mon, 12 Mar 2012 10:16:19 -0700 (PDT) Received: from pisaure.intra.cea.fr (pisaure.intra.cea.fr [132.166.88.21]) by sainfoin.extra.cea.fr (8.14.2/8.14.2/CEAnet-Internet-out-2.3) with ESMTP id q2CHGId8018908 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT) for ; Mon, 12 Mar 2012 18:16:18 +0100 Received: from muguet1.intra.cea.fr (muguet1.intra.cea.fr [132.166.192.6]) by pisaure.intra.cea.fr (8.14.4/8.14.4) with ESMTP id q2CHGIvb003682 for ; Mon, 12 Mar 2012 18:16:18 +0100 (envelope-from alexandru.petrescu@gmail.com) Received: from [127.0.0.1] (is010446-4.intra.cea.fr [10.8.33.116]) by muguet1.intra.cea.fr (8.13.8/8.13.8/CEAnet-Intranet-out-1.2) with ESMTP id q2CHGHPV027571 for ; Mon, 12 Mar 2012 18:16:18 +0100 Message-ID: <4F5E2F61.9040009@gmail.com> Date: Mon, 12 Mar 2012 18:16:17 +0100 From: Alexandru Petrescu User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:10.0.2) Gecko/20120216 Thunderbird/10.0.2 MIME-Version: 1.0 To: mif@ietf.org References: <20120224101611.22703.52041.idtracker@ietfa.amsl.com> <4F47688B.10508@gmail.com> In-Reply-To: <4F47688B.10508@gmail.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Subject: Re: [mif] draft-ietf-mif-dhcpv6-route-option-04 published X-BeenThere: mif@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multiple Interface Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 12 Mar 2012 17:16:21 -0000 Le 24/02/2012 11:38, Tomek Mrugalski a écrit : [...] > - DHCP vs RA conflict. Previously it was proposed that generally > DHCP should override RA. That is no longer the case. DHCP option > format was updated to closer follow RA format. But still RA uses 16bit lifetimes for default routes whereas this draft uses 32bit lifetimes, right? Alex > Although on-wire representation is different, conveyed information is > mostly the same. From a host perspective, route information received > over DHCP may be processed as if yet another RA was received. > > - There were several alternative solutions proposed, like RA used in > stateful manner or segregate hosts to different VLANs. I tried to > explain, why those proposals wouldn't work or are not desirable. > > Motivation and uses cases are now significant part of this draft > itself. If the group believes that it would be cleaner, it may be > split into separate draft. But please, don't use this possibility as > a way to delay this work. There are many networks that want this > option deployed asap. > > Please comment. > > Cheers, Tomek _______________________________________________ mif > mailing list mif@ietf.org https://www.ietf.org/mailman/listinfo/mif > From Ted.Lemon@nominum.com Mon Mar 12 10:23:47 2012 Return-Path: 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 0781721F868C for ; Mon, 12 Mar 2012 10:23:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.457 X-Spam-Level: X-Spam-Status: No, score=-106.457 tagged_above=-999 required=5 tests=[AWL=0.141, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4, 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 JO6N63dCKR5r for ; Mon, 12 Mar 2012 10:23:46 -0700 (PDT) Received: from exprod7og122.obsmtp.com (exprod7og122.obsmtp.com [64.18.2.22]) by ietfa.amsl.com (Postfix) with ESMTP id 6B35A21F8684 for ; Mon, 12 Mar 2012 10:23:45 -0700 (PDT) Received: from shell-too.nominum.com ([64.89.228.229]) (using TLSv1) by exprod7ob122.postini.com ([64.18.6.12]) with SMTP ID DSNKT14xIEHXw6yGOm4Fsweqz4P/sFU0qRs/@postini.com; Mon, 12 Mar 2012 10:23:45 PDT Received: from archivist.nominum.com (archivist.nominum.com [64.89.228.108]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "*.nominum.com", Issuer "Go Daddy Secure Certification Authority" (verified OK)) by shell-too.nominum.com (Postfix) with ESMTP id 2646A1B83E2 for ; Mon, 12 Mar 2012 10:23:44 -0700 (PDT) Received: from webmail.nominum.com (cas-02.win.nominum.com [64.89.228.132]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (Client CN "mail.nominum.com", Issuer "Go Daddy Secure Certification Authority" (verified OK)) by archivist.nominum.com (Postfix) with ESMTPS id 19E6E19005C; Mon, 12 Mar 2012 10:23:44 -0700 (PDT) (envelope-from Ted.Lemon@nominum.com) Received: from MBX-01.WIN.NOMINUM.COM ([64.89.228.133]) by CAS-02.WIN.NOMINUM.COM ([64.89.228.132]) with mapi id 14.02.0247.003; Mon, 12 Mar 2012 10:23:44 -0700 From: Ted Lemon To: Alexandru Petrescu Thread-Topic: [mif] draft-ietf-mif-dhcpv6-route-option-04 published Thread-Index: AQHM8uBsQi4512i5cE6t8t5dPnex2ZZnd0OAgAACEYA= Date: Mon, 12 Mar 2012 17:23:41 +0000 Message-ID: <611FBED3-349A-43E7-B4B9-0BC313EA4F7A@nominum.com> References: <20120224101611.22703.52041.idtracker@ietfa.amsl.com> <4F47688B.10508@gmail.com> <4F5E2F61.9040009@gmail.com> In-Reply-To: <4F5E2F61.9040009@gmail.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [192.168.1.10] Content-Type: multipart/alternative; boundary="_000_611FBED3349A43E7B4B90BC313EA4F7Anominumcom_" MIME-Version: 1.0 Cc: "" Subject: Re: [mif] draft-ietf-mif-dhcpv6-route-option-04 published X-BeenThere: mif@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multiple Interface Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 12 Mar 2012 17:23:47 -0000 --_000_611FBED3349A43E7B4B90BC313EA4F7Anominumcom_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable On Mar 12, 2012, at 1:16 PM, Alexandru Petrescu > wrote: But still RA uses 16bit lifetimes for default routes whereas this draft uses 32bit lifetimes, right? Since the 16-bit lifetimes can be represented as 32-bit lifetimes, I don't = think it's an issue. --_000_611FBED3349A43E7B4B90BC313EA4F7Anominumcom_ Content-Type: text/html; charset="iso-8859-1" Content-ID: <8DF6C4BC6EBA2D47B9E61F10AE41C41E@nominum.com> Content-Transfer-Encoding: quoted-printable
On Mar 12, 2012, at 1:16 PM, Alexandru Petrescu <alexandru.petrescu@gmail.com> wrote:
B= ut still RA uses 16bit lifetimes for default routes whereas this draft=
uses 32bit lifetimes, right?

Since the 16-bit lifetimes can be represented as 32-bit lifetimes, I d= on't think it's an issue.

--_000_611FBED3349A43E7B4B90BC313EA4F7Anominumcom_-- From alexandru.petrescu@gmail.com Thu Mar 15 05:28:05 2012 Return-Path: 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 837DE21F8584 for ; Thu, 15 Mar 2012 05:28:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.952 X-Spam-Level: X-Spam-Status: No, score=-6.952 tagged_above=-999 required=5 tests=[AWL=-0.703, BAYES_00=-2.599, HELO_EQ_FR=0.35, RCVD_IN_DNSWL_MED=-4] 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 lFIztOMngVrp for ; Thu, 15 Mar 2012 05:28:04 -0700 (PDT) Received: from sainfoin-out.extra.cea.fr (sainfoin-out.extra.cea.fr [132.167.192.144]) by ietfa.amsl.com (Postfix) with ESMTP id 5817021F8577 for ; Thu, 15 Mar 2012 05:28:04 -0700 (PDT) Received: from pisaure.intra.cea.fr (pisaure.intra.cea.fr [132.166.88.21]) by sainfoin.extra.cea.fr (8.14.2/8.14.2/CEAnet-Internet-out-2.3) with ESMTP id q2FCS3eR011438 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Thu, 15 Mar 2012 13:28:03 +0100 Received: from muguet2.intra.cea.fr (muguet2.intra.cea.fr [132.166.192.7]) by pisaure.intra.cea.fr (8.14.4/8.14.4) with ESMTP id q2FCS2RG027014; Thu, 15 Mar 2012 13:28:02 +0100 (envelope-from alexandru.petrescu@gmail.com) Received: from [127.0.0.1] (is010446-4.intra.cea.fr [10.8.33.116]) by muguet2.intra.cea.fr (8.13.8/8.13.8/CEAnet-Intranet-out-1.2) with ESMTP id q2FCRxbI006473; Thu, 15 Mar 2012 13:28:02 +0100 Message-ID: <4F61E04F.4020800@gmail.com> Date: Thu, 15 Mar 2012 13:27:59 +0100 From: Alexandru Petrescu User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:11.0) Gecko/20120312 Thunderbird/11.0 MIME-Version: 1.0 To: Ted Lemon References: <20120224101611.22703.52041.idtracker@ietfa.amsl.com> <4F47688B.10508@gmail.com> <4F5E2F61.9040009@gmail.com> <611FBED3-349A-43E7-B4B9-0BC313EA4F7A@nominum.com> In-Reply-To: <611FBED3-349A-43E7-B4B9-0BC313EA4F7A@nominum.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Cc: "" Subject: Re: [mif] draft-ietf-mif-dhcpv6-route-option-04 published X-BeenThere: mif@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multiple Interface Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 15 Mar 2012 12:28:05 -0000 Le 12/03/2012 18:23, Ted Lemon a écrit : > On Mar 12, 2012, at 1:16 PM, Alexandru Petrescu > > > wrote: >> But still RA uses 16bit lifetimes for default routes whereas this >> draft uses 32bit lifetimes, right? > > Since the 16-bit lifetimes can be represented as 32-bit lifetimes, I > don't think it's an issue. It may be an issue if DHCP Server sends a 32bit lifetime of a default route and the Client stores this in its ND default router list structures lifetime 16bit, no? Alex From Ted.Lemon@nominum.com Thu Mar 15 12:10:11 2012 Return-Path: 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 B03F621E8059 for ; Thu, 15 Mar 2012 12:10:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.963 X-Spam-Level: X-Spam-Status: No, score=-103.963 tagged_above=-999 required=5 tests=[AWL=-2.365, BAYES_00=-2.599, GB_SUMOF=5, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4, 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 63-vrbO-GNPB for ; Thu, 15 Mar 2012 12:10:11 -0700 (PDT) Received: from exprod7og116.obsmtp.com (exprod7og116.obsmtp.com [64.18.2.219]) by ietfa.amsl.com (Postfix) with ESMTP id 9019121E8064 for ; Thu, 15 Mar 2012 12:10:10 -0700 (PDT) Received: from shell-too.nominum.com ([64.89.228.229]) (using TLSv1) by exprod7ob116.postini.com ([64.18.6.12]) with SMTP ID DSNKT2I+kuK5lRDyoy5zkC8NnnjCxcqTfnFJ@postini.com; Thu, 15 Mar 2012 12:10:10 PDT Received: from archivist.nominum.com (archivist.nominum.com [64.89.228.108]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "*.nominum.com", Issuer "Go Daddy Secure Certification Authority" (verified OK)) by shell-too.nominum.com (Postfix) with ESMTP id 605321B8321 for ; Thu, 15 Mar 2012 12:10:09 -0700 (PDT) Received: from webmail.nominum.com (cas-02.win.nominum.com [64.89.228.132]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (Client CN "mail.nominum.com", Issuer "Go Daddy Secure Certification Authority" (verified OK)) by archivist.nominum.com (Postfix) with ESMTPS id 55EE719005C; Thu, 15 Mar 2012 12:10:09 -0700 (PDT) (envelope-from Ted.Lemon@nominum.com) Received: from MBX-01.WIN.NOMINUM.COM ([64.89.228.133]) by CAS-02.WIN.NOMINUM.COM ([64.89.228.132]) with mapi id 14.02.0247.003; Thu, 15 Mar 2012 12:10:09 -0700 From: Ted Lemon To: Alexandru Petrescu Thread-Topic: [mif] draft-ietf-mif-dhcpv6-route-option-04 published Thread-Index: AQHM8uBsQi4512i5cE6t8t5dPnex2ZZnd0OAgAACEYCABGRggIAAcFuA Date: Thu, 15 Mar 2012 19:10:08 +0000 Message-ID: References: <20120224101611.22703.52041.idtracker@ietfa.amsl.com> <4F47688B.10508@gmail.com> <4F5E2F61.9040009@gmail.com> <611FBED3-349A-43E7-B4B9-0BC313EA4F7A@nominum.com> <4F61E04F.4020800@gmail.com> In-Reply-To: <4F61E04F.4020800@gmail.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [192.168.1.10] Content-Type: multipart/alternative; boundary="_000_DF5F4B7B74864878A096084BDA1CB7C4nominumcom_" MIME-Version: 1.0 Cc: "" Subject: Re: [mif] draft-ietf-mif-dhcpv6-route-option-04 published X-BeenThere: mif@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multiple Interface Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 15 Mar 2012 19:10:11 -0000 --_000_DF5F4B7B74864878A096084BDA1CB7C4nominumcom_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable On Mar 15, 2012, at 8:27 AM, Alexandru Petrescu > wrote: It may be an issue if DHCP Server sends a 32bit lifetime of a default route and the Client stores this in its ND default router list structures lifetime 16bit, no? I think this is a non-problem. The RA lifetime may be represented as a 16= -bit offset in transit, but when it is stored in a table on the node, the n= ode has to know when the lifetime ends, not how long it is. So the implem= entation must necessarily convert the 16-bit offset to something like a tim= e_t, which is either 32 or 64 bits, and represents an absolute time, not a = relative time. Consequently, there will be no problem with receiving a 32-bit offset from = the DHCP server, other than that if the sum of the current absolute time an= d offset overflows, the implementation needs to truncate the result to the = maximum time value. This same behavior is necessary for 16-bit offsets; i= t's just that the range of dates during which it might occur is smaller. --_000_DF5F4B7B74864878A096084BDA1CB7C4nominumcom_ Content-Type: text/html; charset="iso-8859-1" Content-ID: <301750F99704654893FDE88F0D30FBD6@nominum.com> Content-Transfer-Encoding: quoted-printable
On Mar 15, 2012, at 8:27 AM, Alexandru Petrescu <alexandru.petrescu@gmail.com> wrote:
I= t may be an issue if DHCP Server sends a 32bit lifetime of a default<= br style=3D"color: rgb(0, 0, 0); font-family: Helvetica; font-style: normal= ; font-variant: normal; font-weight: normal; letter-spacing: normal; line-h= eight: normal; orphans: 2; text-align: -webkit-auto; text-indent: 0px; text= -transform: none; white-space: normal; widows: 2; word-spacing: 0px; -webki= t-text-size-adjust: auto; -webkit-text-stroke-width: 0px; font-size: medium= ; "> route and the Client stores this in its ND default router list
structures lifetime 16bit, no?

I think this is a non-problem.   The RA lifetime may be represent= ed as a 16-bit offset in transit, but when it is stored in a table on the n= ode, the node has to know when the lifetime ends, not how long it is.  = ; So the implementation must necessarily convert the 16-bit offset to something like a time_t, which is either 32 or 64 bit= s, and represents an absolute time, not a relative time.

Consequently, there will be no problem with receiving a 32-bit offset = from the DHCP server, other than that if the sum of the current absolute ti= me and offset overflows, the implementation needs to truncate the result to= the maximum time value.   This same behavior is necessary for 16-bit offsets; it's just that the range of= dates during which it might occur is smaller.

--_000_DF5F4B7B74864878A096084BDA1CB7C4nominumcom_-- From alexandru.petrescu@gmail.com Fri Mar 16 08:56:07 2012 Return-Path: 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 D87E021F85D8 for ; Fri, 16 Mar 2012 08:56:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.579 X-Spam-Level: X-Spam-Status: No, score=-6.579 tagged_above=-999 required=5 tests=[AWL=-1.330, BAYES_00=-2.599, GB_SUMOF=5, HELO_EQ_FR=0.35, RCVD_IN_DNSWL_HI=-8] 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 o+rostptg7bK for ; Fri, 16 Mar 2012 08:56:07 -0700 (PDT) Received: from cirse-out.extra.cea.fr (cirse-out.extra.cea.fr [132.167.192.142]) by ietfa.amsl.com (Postfix) with ESMTP id 083D721F8623 for ; Fri, 16 Mar 2012 08:56:06 -0700 (PDT) Received: from pisaure.intra.cea.fr (pisaure.intra.cea.fr [132.166.88.21]) by cirse.extra.cea.fr (8.14.2/8.14.2/CEAnet-Internet-out-2.3) with ESMTP id q2GFu5QR014566 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Fri, 16 Mar 2012 16:56:05 +0100 Received: from muguet1.intra.cea.fr (muguet1.intra.cea.fr [132.166.192.6]) by pisaure.intra.cea.fr (8.14.4/8.14.4) with ESMTP id q2GFu4J7016390; Fri, 16 Mar 2012 16:56:05 +0100 (envelope-from alexandru.petrescu@gmail.com) Received: from [127.0.0.1] (is010446-4.intra.cea.fr [10.8.33.116]) by muguet1.intra.cea.fr (8.13.8/8.13.8/CEAnet-Intranet-out-1.2) with ESMTP id q2GFu1ZA002093; Fri, 16 Mar 2012 16:56:04 +0100 Message-ID: <4F636291.7060104@gmail.com> Date: Fri, 16 Mar 2012 16:56:01 +0100 From: Alexandru Petrescu User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:11.0) Gecko/20120312 Thunderbird/11.0 MIME-Version: 1.0 To: Ted Lemon References: <20120224101611.22703.52041.idtracker@ietfa.amsl.com> <4F47688B.10508@gmail.com> <4F5E2F61.9040009@gmail.com> <611FBED3-349A-43E7-B4B9-0BC313EA4F7A@nominum.com> <4F61E04F.4020800@gmail.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Cc: "" Subject: Re: [mif] draft-ietf-mif-dhcpv6-route-option-04 published X-BeenThere: mif@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multiple Interface Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 16 Mar 2012 15:56:08 -0000 Le 15/03/2012 20:10, Ted Lemon a écrit : > On Mar 15, 2012, at 8:27 AM, Alexandru Petrescu > > > wrote: >> It may be an issue if DHCP Server sends a 32bit lifetime of a >> default route and the Client stores this in its ND default router >> list structures lifetime 16bit, no? > > I think this is a non-problem. The RA lifetime may be represented as > a 16-bit offset in transit, but when it is stored in a table on the > node, the node has to know when the lifetime ends, not how long it > is. I guess in some cases yes, and others no. Not all plaforms benefit from the typical timer implementation as a PC-class monolithic kernel offers. > So the implementation must necessarily convert the 16-bit offset to > something like a time_t, which is either 32 or 64 bits, and > represents an absolute time, not a relative time. Again depends on the implementaiton. Then all time is relative to something anyways, be it 1970 earlier or later. > Consequently, there will be no problem with receiving a 32-bit > offset from the DHCP server, other than that if the sum of the > current absolute time and offset overflows, the implementation needs > to truncate the result to the maximum time value. This same behavior > is necessary for 16-bit offsets; it's just that the range of dates > during which it might occur is smaller. SO there would _be_ a conversion needed, right? This may need to be specified. Wouldn't be easier to specify that both lifetimes (from ND and from DHCP) are represented in the same manner, thus no conversion? Alex From yding@cs.helsinki.fi Mon Mar 19 12:48:59 2012 Return-Path: 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 D22FA21F87E2 for ; Mon, 19 Mar 2012 12:48:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] 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 NM8DP1ZQPdGr for ; Mon, 19 Mar 2012 12:48:59 -0700 (PDT) Received: from mail.cs.helsinki.fi (courier.cs.helsinki.fi [128.214.9.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0D2EB21F885C for ; Mon, 19 Mar 2012 12:48:58 -0700 (PDT) Received: from [192.168.93.114] (host-94-101-2-100.igua.fi [94.101.2.100]) (AUTH: PLAIN yding, TLS: TLSv1/SSLv3,256bits,AES256-SHA) by mail.cs.helsinki.fi with esmtp; Mon, 19 Mar 2012 21:48:56 +0200 id 0006814F.4F678DA8.00007BA8 Message-ID: <4F678D9A.50403@cs.helsinki.fi> Date: Mon, 19 Mar 2012 21:48:42 +0200 From: "Yi DING(Aaron)" Organization: Uni Helsinki User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.2.23) Gecko/20110921 Thunderbird/3.1.15 MIME-Version: 1.0 To: mif@ietf.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: [mif] update for draft-korhonen-mif-ra-offload X-BeenThere: mif@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multiple Interface Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 19 Mar 2012 19:48:59 -0000 Hello, Based on the comments at IETF Taipei, we have updated the RA offload draft. http://tools.ietf.org/html/draft-korhonen-mif-ra-offload-04 Major modifications include * identify the target of this draft: IPv4 to IPv6 transition phase where mobile access provides dual-stack v6v4 while IPv4-only WiFi available; it's meant for hosts and networks without available DHCP support (rfc3442 anddraft-ietf-mif-dhcpv6-route-option-04 ). ** use the proposed offload option to configure specific route offloading, rather than trying to combine with RFC4191 router information option as done in previous version. Given the fact that majority of traffic is over v4, this proposal is for v4 offloading while RFC4191 already supports v6 offloading (ref. dhcpv4 rfc3442, and dhcpv6 basedhttp://www.ietf.org/id/draft-ietf-mif-dhcpv6-route-option-04.txt). Necessary info for specific route is contained in the option to configure specific route offloading. Given the gap between fast increase of data traffic and capacity offered by cellular data networks, this proposal supports network controlled offloading and cellular v6 access is used as the signaling channel. When hosts get both valid A and AAAA, this draft does not modify the default behavior of preferring AAAA. It only suggests v4 traffic to be offloaded to other interface e.g. WiFi. For v6 traffic offload, RFC4191 already addresses the issue. Concerning the comments on potential proliferation of various solutions, this draft is to guide what needs to be done in the case when DHCP is not available. It is not to compete with DHCP based solutions but meant for the scenario it targets at. Please comment and thanks in advance. BRs, Aaron "A new version of I-D, draft-korhonen-mif-ra-offload-04.txt has been successfully submitted by Yi Ding and posted to the IETF repository. Filename: draft-korhonen-mif-ra-offload Revision: 04 Title: Controlling Traffic Offloading Using Neighbor Discovery Protocol Creation date: 2012-03-12 WG ID: Individual Submission Number of pages: 14 Abstract: This specification defines an extension to IPv6 Neighbor Discovery Protocol, which allows management of IPv4 traffic offloading for multi-interface dual-stack capable hosts and moving IPv4 traffic away from a specific interface. " From yi.ding@cs.helsinki.fi Mon Mar 19 10:33:22 2012 Return-Path: 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 8BA2521F8894 for ; Mon, 19 Mar 2012 10:33:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] 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 idvTpgYwpo9p for ; Mon, 19 Mar 2012 10:33:21 -0700 (PDT) Received: from mail.cs.helsinki.fi (courier.cs.helsinki.fi [128.214.9.1]) by ietfa.amsl.com (Postfix) with ESMTP id 44D0721F888B for ; Mon, 19 Mar 2012 10:33:19 -0700 (PDT) Received: from [128.214.9.154] (wel-33.cs.helsinki.fi [128.214.9.154]) (AUTH: PLAIN yding, SSL: TLSv1/SSLv3,256bits,AES256-SHA) by mail.cs.helsinki.fi with esmtp; Mon, 19 Mar 2012 19:33:17 +0200 id 0006814A.4F676DDD.0000300D Message-ID: <4F676DDD.60903@cs.helsinki.fi> Date: Mon, 19 Mar 2012 19:33:17 +0200 From: "Yi DING(Aaron)" Organization: Uni Helsinki User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.27) Gecko/20120216 Thunderbird/3.1.19 MIME-Version: 1.0 To: mif@ietf.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Mailman-Approved-At: Mon, 19 Mar 2012 17:52:53 -0700 Cc: Jouni Korhonen , Markku Kojo Subject: [mif] update for draft-korhonen-mif-ra-offload X-BeenThere: mif@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multiple Interface Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 19 Mar 2012 17:33:22 -0000 Hello, Based on the comments at IETF Taipei, we have updated the RA offload draft. http://tools.ietf.org/html/draft-korhonen-mif-ra-offload-04 Major modifications include * identify the target of this draft: IPv4 to IPv6 transition phase where mobile access provides dual-stack v6v4 while IPv4-only WiFi available; it's meant for hosts and networks without available DHCP support (rfc3442 anddraft-ietf-mif-dhcpv6-route-option-04 ). ** use the proposed offload option to configure specific route offloading, rather than trying to combine with RFC4191 router information option as done in previous version. Given the fact that majority of traffic is over v4, this proposal is for v4 offloading while RFC4191 already supports v6 offloading (ref. dhcpv4 rfc3442, and dhcpv6 basedhttp://www.ietf.org/id/draft-ietf-mif-dhcpv6-route-option-04.txt). Necessary info for specific route is contained in the option to configure specific route offloading. Given the gap between fast increase of data traffic and capacity offered by cellular data networks, this proposal supports network controlled offloading and cellular v6 access is used as the signaling channel. When hosts get both valid A and AAAA, this draft does not modify the default behavior of preferring AAAA. It only suggests v4 traffic to be offloaded to other interface e.g. WiFi. For v6 traffic offload, RFC4191 already addresses the issue. Concerning the comments on potential proliferation of various solutions, this draft is to guide what needs to be done in the case when DHCP is not available. It is not to compete with DHCP based solutions but meant for the scenario it targets at. Please comment and thanks in advance. BRs, Aaron "A new version of I-D, draft-korhonen-mif-ra-offload-04.txt has been successfully submitted by Yi Ding and posted to the IETF repository. Filename: draft-korhonen-mif-ra-offload Revision: 04 Title: Controlling Traffic Offloading Using Neighbor Discovery Protocol Creation date: 2012-03-12 WG ID: Individual Submission Number of pages: 14 Abstract: This specification defines an extension to IPv6 Neighbor Discovery Protocol, which allows management of IPv4 traffic offloading for multi-interface dual-stack capable hosts and moving IPv4 traffic away from a specific interface. " From denghui02@hotmail.com Wed Mar 21 02:01:22 2012 Return-Path: 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 E367521F85CF for ; Wed, 21 Mar 2012 02:01:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.739 X-Spam-Level: X-Spam-Status: No, score=-100.739 tagged_above=-999 required=5 tests=[BAYES_20=-0.74, HTML_MESSAGE=0.001, 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 m4C4tKj1vxKH for ; Wed, 21 Mar 2012 02:01:22 -0700 (PDT) Received: from col0-omc2-s17.col0.hotmail.com (col0-omc2-s17.col0.hotmail.com [65.55.34.91]) by ietfa.amsl.com (Postfix) with ESMTP id 2102F21F8595 for ; Wed, 21 Mar 2012 02:01:22 -0700 (PDT) Received: from COL118-W58 ([65.55.34.72]) by col0-omc2-s17.col0.hotmail.com with Microsoft SMTPSVC(6.0.3790.4675); Wed, 21 Mar 2012 02:01:21 -0700 Message-ID: Content-Type: multipart/alternative; boundary="_e9eced5d-681c-4078-a5f2-6964d27a728f_" X-Originating-IP: [221.130.253.135] From: Hui Deng To: Date: Wed, 21 Mar 2012 17:01:21 +0800 Importance: Normal MIME-Version: 1.0 X-OriginalArrivalTime: 21 Mar 2012 09:01:21.0991 (UTC) FILETIME=[2FCDFD70:01CD0741] Subject: [mif] IPR discussion on draft-savolainen-mif-dns-server-selection X-BeenThere: mif@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multiple Interface Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 21 Mar 2012 09:01:23 -0000 --_e9eced5d-681c-4078-a5f2-6964d27a728f_ Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: 8bit Hello all We have once received IPR disclosure for draft-savolainen-mif-dns-server-selection at : https://datatracker.ietf.org/ipr/1103/ https://datatracker.ietf.org/ipr/search/?option=document_search&id_document_tag=draft-ietf-mif-dns-server-selection Just want to know your comments on this before moveing forward, By the way, we have found that Microsoft has open document for Name Resolution Policy Table http://technet.microsoft.com/en-us/magazine/ff394369.aspx And that IPR is filed around October 2008, don't know which is more early. thanks a lot -Hui --_e9eced5d-681c-4078-a5f2-6964d27a728f_ Content-Type: text/html; charset="gb2312" Content-Transfer-Encoding: 8bit
Hello all
 
We have once received IPR disclosure for draft-savolainen-mif-dns-server-selection at :
https://datatracker.ietf.org/ipr/1103/
https://datatracker.ietf.org/ipr/search/?option=document_search&id_document_tag=draft-ietf-mif-dns-server-selection
Just want to know your comments on this before moveing forward,
 
By the way, we have found that Microsoft has open document for Name Resolution Policy Table
http://technet.microsoft.com/en-us/magazine/ff394369.aspx
And that IPR is filed around October 2008,
don't know which is more early.
 
thanks a lot
 
-Hui
--_e9eced5d-681c-4078-a5f2-6964d27a728f_-- From ajs@anvilwalrusden.com Wed Mar 21 03:29:39 2012 Return-Path: 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 48F8E21F861C for ; Wed, 21 Mar 2012 03:29:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.488 X-Spam-Level: X-Spam-Status: No, score=-2.488 tagged_above=-999 required=5 tests=[AWL=0.111, BAYES_00=-2.599] 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 UheHyQli-IvO for ; Wed, 21 Mar 2012 03:29:38 -0700 (PDT) Received: from mail.yitter.info (mail.yitter.info [208.86.224.201]) by ietfa.amsl.com (Postfix) with ESMTP id C801A21F85FC for ; Wed, 21 Mar 2012 03:29:38 -0700 (PDT) Received: from mail.yitter.info (69-196-144-227.dsl.teksavvy.com [69.196.144.227]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.yitter.info (Postfix) with ESMTPSA id 6995C1ECB41D for ; Wed, 21 Mar 2012 10:29:37 +0000 (UTC) Date: Wed, 21 Mar 2012 06:29:25 -0400 From: Andrew Sullivan To: mif@ietf.org Message-ID: <20120321102918.GA48202@mail.yitter.info> References: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) Subject: Re: [mif] IPR discussion on draft-savolainen-mif-dns-server-selection X-BeenThere: mif@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multiple Interface Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 21 Mar 2012 10:29:39 -0000 Dear colleagues, On Wed, Mar 21, 2012 at 05:01:21PM +0800, Hui Deng wrote: > > We have once received IPR disclosure for draft-savolainen-mif-dns-server-selection at : > https://datatracker.ietf.org/ipr/1103/ > https://datatracker.ietf.org/ipr/search/?option=document_search&id_document_tag=draft-ietf-mif-dns-server-selection > Just want to know your comments on this before moveing forward, Thanks to the chairs for bringing this to our attention. The IPR disclosure is for the -00 draft submission. It would be nice to know whether Nokia (or for that matter, Microsoft, if they make IPR claims over these tricks -- I note there isn't one filed in the datatracker) think the draft as it currently stands is still covered. I'll assume so. To my chagrin, I'm not a lawyer, but the terms in that IPR filing seem acceptable -- or anyway, no worse than the rest of the project. (That is, the very idea of this sort of scoping of DNS servers is hideous to me, but I understand why to do it and can still think of no better way than what the draft does.) The IPR declaration is no worse than the idea itself. Best, A -- Andrew Sullivan ajs@anvilwalrusden.com From denghui02@gmail.com Wed Mar 21 18:49:54 2012 Return-Path: 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 359B821E8015; Wed, 21 Mar 2012 18:49:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.37 X-Spam-Level: X-Spam-Status: No, score=-103.37 tagged_above=-999 required=5 tests=[AWL=0.228, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1, 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 LeuIIPQTwqCg; Wed, 21 Mar 2012 18:49:53 -0700 (PDT) Received: from mail-yx0-f172.google.com (mail-yx0-f172.google.com [209.85.213.172]) by ietfa.amsl.com (Postfix) with ESMTP id 6ACBC21E800C; Wed, 21 Mar 2012 18:49:53 -0700 (PDT) Received: by yenm5 with SMTP id m5so1618625yen.31 for ; Wed, 21 Mar 2012 18:49:53 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:date:message-id:subject:from:to:content-type; bh=j5dWFsWs95m5VbEDQPgAQLeC7hO7tS6sD+ItVuJ8w8c=; b=pTRphpzZk8lS55R1Ur6dn+CQKFpClkKzYKAx3NZA1n+q9iaErblLsfpVTAu5+G8U77 fE7Lq7kPs+EnwbXwcD1Pfi/e8C3smgepYuUbzhRD1r9Z5/hcxMuRvWCX4+iWGtVdV9vm x2i2DP3yTIKU5CHeG59QmiScDeKnUz2WXJb90ITlXHRdGXK+tmctg3EdSMblzj+y/trn j9G+YnXVYyVwECvJStHcrRyF7ecnoLZMyDw2uK74OvHzCwS9RZCGpR76+LFUuDJ5EDYy rAeabZPuoy63lVEM7/fFmLzYR3VdPnSPLQsE+FUS+T+XrvQEQZqBC0SXRSh7Zepeebqx IZUg== MIME-Version: 1.0 Received: by 10.101.128.14 with SMTP id f14mr1886430ann.21.1332380992977; Wed, 21 Mar 2012 18:49:52 -0700 (PDT) Received: by 10.147.112.1 with HTTP; Wed, 21 Mar 2012 18:49:52 -0700 (PDT) Date: Thu, 22 Mar 2012 09:49:52 +0800 Message-ID: From: Hui Deng To: MIF Mailing List , IETF Discussion , Internet Area Content-Type: multipart/alternative; boundary=001636c597a3cabbcb04bbcb1f26 Subject: [mif] OMA IETF MIF API Workshop X-BeenThere: mif@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multiple Interface Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 22 Mar 2012 01:49:54 -0000 --001636c597a3cabbcb04bbcb1f26 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable OMA IETF MIF API Workshop Time: Tuesday: 18:10-20:00 Location: TBD 1) Program 1.1) OMA OpenCMAPI activity (Thierry) 1.2) IETF MIF API Design (Ted Lemon) 1.3) IETF API related work (TBD) 1.4) OMA API Program (OMA Member) 1.5) Vendor's today implementation (Maybe) 1.6) Next step between IETF and OMA (Thierry and Hui) 2) Purpose 2.1) From IETF, this workshop would help to explain the API related topic, and clarify what is recommended and not recommended to do and standardized, if possible, either publish a information document or adding word into the current MIF api draft about how to use those MIF API for Internet developer= . and some current practices information how today smart terminal is doing. 2.2) From OMA perspective, to socialize OMA=92s published specifications an= d current ongoing standards activities in the area of APIs. To make sure that the standards landscape for APIs is coordinated and harmonized. To solicit feedback about OMA=92s specification for Authorization4APIs, which is built on IETF OAuth as well as OpenCMAPI. 3) Outcomes: 3.1) Future work about how to use those MIF API in an IETF information document or inside current MIF API documentfor Internet developers. 3.2) Outcomes OMA: Improved understanding of each others=92 activities, and a coordinated approach going forward 3.3) Better mutual understanding of the work of both organizations, and how to cooperate in the future. --001636c597a3cabbcb04bbcb1f26 Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: quoted-printable OMA IETF MIF API Workshop
=A0
Time: Tuesday: 18:10-20:00
Location:= TBD
=A0
1) Program
1.1) OMA OpenCMAPI activity (Thierry)
1.2= ) IETF MIF API Design (Ted Lemon)
1.3) IETF API related work (TBD)
1= .4) OMA API Program (OMA Member)
1.5) Vendor's today implementation (Maybe)
1.6) Next step between IE= TF and OMA (Thierry and Hui)
=A0
2) Purpose
2.1) From IETF, this w= orkshop would help to explain the API related topic,
and clarify what is= recommended and not recommended to do and standardized,
if possible, either publish a information document or adding word into the =
current MIF api draft about how to use those MIF API for Internet devel= oper.
and some current practices information how today smart terminal is= doing.
=A0
2.2) From OMA perspective, to socialize OMA=92s published specificat= ions and
current ongoing standards activities in the area of APIs. To m= ake sure that
the standards landscape for APIs is coordinated and harmo= nized. To solicit
feedback about OMA=92s specification for Authorization4APIs, which is built=
on IETF OAuth as well as OpenCMAPI.
=A0
3) Outcomes:
3.1) Fut= ure work about how to use those MIF API in an IETF information
=A0docum= ent or inside current MIF API documentfor Internet developers.

3.2) Outcomes OMA: Improved understanding of each others=92 activities,=
=A0and a coordinated approach going forward

3.3) Better mutual u= nderstanding of the work of both organizations,
=A0and how to cooperate= in the future. --001636c597a3cabbcb04bbcb1f26-- From mglt.ietf@gmail.com Sun Mar 25 08:05:32 2012 Return-Path: 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 026F521F84D9 for ; Sun, 25 Mar 2012 08:05:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.598 X-Spam-Level: X-Spam-Status: No, score=-3.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] 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 CqBsEQj2XK-f for ; Sun, 25 Mar 2012 08:05:31 -0700 (PDT) Received: from mail-iy0-f172.google.com (mail-iy0-f172.google.com [209.85.210.172]) by ietfa.amsl.com (Postfix) with ESMTP id EB5CC21F84D7 for ; Sun, 25 Mar 2012 08:05:30 -0700 (PDT) Received: by iazz13 with SMTP id z13so8225714iaz.31 for ; Sun, 25 Mar 2012 08:05:30 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=2qlEwbcbBBfm8x/6h6ufIPHqCeQpPTvwI8g+/COU6Kw=; b=VCIJZOGjqbmlnEKmBbSqfiTjHovGY6QbVKkBeLgTl230GdmgLN+7+WPk8vvOTxj5vu s8xipxoLcKzbHqURgtIzi93LedZJCkBbrbiWjG7Ud4qvZ34RU1sTD8lZEiBHA3BJJVNQ E4F8gJtDy+DscW6nA9/VkcjCo5Wffj82gZ6frditxyY3RHP+L26O5pDR0KAavagnQRyg wtVruJlNp/7J7YSWli+mmrxx21ZwCuRCcuAoIuvP9xfblWDpiVuCiF3f8L68CJEY1QSA 80ya6qhK7RwtO8xG1+56f7jBtgZSZ6gesuJi+pKtSr7kHZFnIpix8zQHvutUUjA81tOM 9OXA== MIME-Version: 1.0 Received: by 10.50.106.226 with SMTP id gx2mr3488285igb.42.1332687930582; Sun, 25 Mar 2012 08:05:30 -0700 (PDT) Received: by 10.231.170.138 with HTTP; Sun, 25 Mar 2012 08:05:30 -0700 (PDT) In-Reply-To: <4F4FFE91.8020906@gmail.com> References: <20120301144229.28186.7229.idtracker@ietfa.amsl.com> <4F4FFE91.8020906@gmail.com> Date: Sun, 25 Mar 2012 17:05:30 +0200 Message-ID: From: Daniel Migault To: Brian E Carpenter Content-Type: multipart/alternative; boundary=e89a8f2351e1b2e55704bc12962e Cc: mif@ietf.org Subject: Re: [mif] I-D Action: draft-mglt-mif-security-requirements-00.txt X-BeenThere: mif@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multiple Interface Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 25 Mar 2012 15:05:32 -0000 --e89a8f2351e1b2e55704bc12962e Content-Type: text/plain; charset=ISO-8859-1 Hi Brian, Thank you for your remarks we are considering for the 01 version of the draft that will be published soon. I briefly provide inline responses. On Thu, Mar 1, 2012 at 11:56 PM, Brian E Carpenter < brian.e.carpenter@gmail.com> wrote: > Hi, > > I don't understand the scope or the threat model for this draft. > > The scope seems to be less than the whole of MIF. It seems to be > limited to a subset of MIF cases where a provider is in some way > in control of the acquisition and use of additional interfaces. > In the general case, nobody is in control - the user device simply > discovers and uses whatever connectivity appears. If this is a > correct understanding, could the title, Abstract and Introduction > make it very clear what the scope is? > > No. we are considering the general case of MIF. The confusion comes probably from the section that considered ISP hosted services. What we pointed out in this section was that the ISP would be able to adapt the security of the Service according to the type of network. I remove this confusing section in 01. > I don't understand the threat model because it isn't described > at all. So I can't evaluate any of the assertions about security > requirements. The model is that a communication being carried on a RAN MAY not need any protection because RAN is a trusted Network. WLAN MAY not be trusted Network, and EU switching to WLAN MAY want to protect the communication. We describe why we recommend IPsec and what IPsec currently misses to address the Multiple Interfaces Security Requirements. There is no threats description in 01, but we provide a better description of the motivations for Security Requirements. I do know that a conclusion that IPsec must be used > for everything is very unpalatable. I agree. For ISPs, IPsec is recommended, but we also insist that there is no systematic solutions. There are risks in any public > WLAN of course, but they exist whatever crypto is used. > > One detail: > > > Alternate IP addresses are provided for a given > > communication, a Primary IP addresses is replaced by an > > Alternate IP address, and Primary and Alternate are not used > > simultaneously for the same communication. > > This is not true if the device uses recent techniques such as > MPTCP, which automatically shares the available paths. Such end > to end techniques are outside the control of the provider. > Right. Version 01 should clarify this. The draft is focused on IPsec configuration for Multihoming. I considered IKEv2 own mechanisms to deal with Multihoming. I known work has previously been done to make IKEv2 work over SCTP to make IKEv2 benefit from SCTP features but do not considered here. The idea is to make IKEv2 resistant to change of Interfaces, Interface fail-over so that IKEv2 can proceed to the IPsec configuration for the communication. Mobility, Multihoming, Multiple Interfaces do not concern the communication in itself, but the way to configure IPsec. Configuring properly IPsec is necessary to avoid IPsec blocking the communication, when other protocols like SCTP, MTCP performs Mobility or Multihoming. Regards, Daniel > Brian > > _______________________________________________ > mif mailing list > mif@ietf.org > https://www.ietf.org/mailman/listinfo/mif > -- Daniel Migault Orange Labs -- Security +33 6 70 72 69 58 --e89a8f2351e1b2e55704bc12962e Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Hi Brian,

Thank you for your remarks we are considering for the=20 01 version of the draft that will be published soon. I briefly provide=20 inline responses.


On Thu, Mar 1, 201= 2 at 11:56 PM, Brian E Carpenter <brian.e.carpenter@gmail.com> wrote= :
Hi,

I don't understand the scope or the threat model for this draft.

The scope seems to be less than the whole of MIF. It seems to be
limited to a subset of MIF cases where a provider is in some way
in control of the acquisition and use of additional interfaces.
In the general case, nobody is in control - the user device simply
discovers and uses whatever connectivity appears. If this is a
correct understanding, could the title, Abstract and Introduction
make it very clear what the scope is?

No. we are considering the general case of MIF. The c= onfusion comes probably from the section that considered ISP hosted service= s. What we pointed out in this section was that the ISP would be able to ad= apt the security of the Service according to the type of network. I remove = this confusing section in 01.

=A0
I don't understand the threat model because it isn't described
at all. So I can't evaluate any of the assertions about security
requirements.
=A0
The model is that a communicat= ion being carried on a RAN MAY not need any protection because RAN is a tru= sted Network. WLAN MAY not be trusted Network, and EU switching to WLAN MAY= want to protect the communication. We describe why we recommend IPsec and = what IPsec currently misses to address the Multiple Interfaces Security Req= uirements.
There is no threats description in 01, but we provide a better description = of the motivations for Security Requirements.

I do know that a conclusion that IPsec must be used
for everything is very unpalatable.

I agree. For ISPs,= IPsec is recommended, but we also insist that there is no systematic solut= ions.

There are risks in any public
WLAN of course, but they exist whatever crypto is used.

One detail:

> Alternate IP addresses are provided for a given
> communication, a Primary IP addresses is replaced by an
> Alternate IP address, and Primary and Alternate are not used
> simultaneously for the same communication.

This is not true if the device uses recent techniques such as
MPTCP, which automatically shares the available paths. Such end
to end techniques are outside the control of the provider.
=

Right. Version 01 should=A0 clarify this. The draft is focused on = IPsec configuration for Multihoming. I considered IKEv2 own mechanisms to d= eal with Multihoming. I known work has previously been done to make IKEv2 w= ork over SCTP to make IKEv2 benefit from SCTP features but do not considere= d here.=A0
The idea is to make IKEv2 resistant to change of Interfaces, Interface fail= -over so that IKEv2 can proceed to the IPsec configuration for the communic= ation. Mobility, Multihoming, Multiple Interfaces do not concern the commun= ication in itself, but the way to configure IPsec. Configuring properly IPs= ec is necessary to avoid IPsec blocking the communication, when other proto= cols like SCTP, MTCP performs Mobility or Multihoming.
=A0
Regards,
Daniel
=A0 Brian

_______________________________________________
mif mailing list
mif@ietf.org
htt= ps://www.ietf.org/mailman/listinfo/mif



--
Daniel Migault
Orang= e Labs -- Security
+33 6 70 72 69 58
--e89a8f2351e1b2e55704bc12962e-- From ek@google.com Sun Mar 25 11:31:34 2012 Return-Path: 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 133AE21E8013 for ; Sun, 25 Mar 2012 11:31:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.677 X-Spam-Level: X-Spam-Status: No, score=-102.677 tagged_above=-999 required=5 tests=[AWL=0.300, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1, 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 HH0vaZtjuUhf for ; Sun, 25 Mar 2012 11:31:33 -0700 (PDT) Received: from mail-qc0-f172.google.com (mail-qc0-f172.google.com [209.85.216.172]) by ietfa.amsl.com (Postfix) with ESMTP id D5C4421E800E for ; Sun, 25 Mar 2012 11:31:32 -0700 (PDT) Received: by qcsq13 with SMTP id q13so3358466qcs.31 for ; Sun, 25 Mar 2012 11:31:32 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding:x-system-of-record; bh=RhwnXbgXPfYk6Lj/z+PSYpJN9FzcqkQbbjr7e8Rekyg=; b=XAgC86LxfUGn6pyCyOXOJgbqapvxY3wbTZPBhQzJNrBJ6KV15VRkPPfkr5NqMjXcea VBrqBlTAcf/JIMbwX0vdj7LYUiwPa03+aQX4u2YNW1aBEU/1u49pX5uZizb1WRlQqgij H4jPRUTj+VoI2F8ZAaLeDiqOf6oPZnhJfbaKZXl3XZeCGxkzkvCufIlzThP5K4kvWshn QCM4KCcaBL1/uBoGvCdxjtgBV4Xees2fFxRN69ItVkbwZ4vK7oDuPNFwcfO7s+NvuD49 uhvcUGzeYbDa1F3LOtjxKty8cH4qvIoo6NS0RXRkX5XnMHVk8Xbr5vW48j2QbVp1gTHb PJ0g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding:x-system-of-record :x-gm-message-state; bh=RhwnXbgXPfYk6Lj/z+PSYpJN9FzcqkQbbjr7e8Rekyg=; b=KhtW6fTr/QX9KLAs7PEyrzlgJkPq7CGUQqgJl+Oz7d8jtUuTcqIrjrSopjnCpC6Mnk 0CH3+r4lcG1EbRP1HVbzckZ4a46kW0Vq/Wn5hNkXng2hEsexoIhMs1vrZuwqZzAeggY4 LbmyKmh3Ok1uiK/D35KbLA4+ZhD0VP5jXW02fzQwn9WYZCj4eWnfUDbyIE4VAP1Bho4r CiSsXILVR5kmd1crM3cBOs7V7tS4EBbVlEf7mIudR7GsSLGDbiyOEYu35GwIzMgZ3h30 V+HhLLVw91hIDqdOkhILfCfK0xbbZVFOxcrSjfpnyXSJ5CExeix5xLeKWdbUMUhmvSIX Vbuw== Received: by 10.229.115.21 with SMTP id g21mr946104qcq.77.1332700292024; Sun, 25 Mar 2012 11:31:32 -0700 (PDT) MIME-Version: 1.0 Received: by 10.229.115.21 with SMTP id g21mr946098qcq.77.1332700291872; Sun, 25 Mar 2012 11:31:31 -0700 (PDT) Received: by 10.229.128.170 with HTTP; Sun, 25 Mar 2012 11:31:31 -0700 (PDT) In-Reply-To: <4F5E2F61.9040009@gmail.com> References: <20120224101611.22703.52041.idtracker@ietfa.amsl.com> <4F47688B.10508@gmail.com> <4F5E2F61.9040009@gmail.com> Date: Mon, 26 Mar 2012 03:31:31 +0900 Message-ID: From: Erik Kline To: Alexandru Petrescu Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-System-Of-Record: true X-Gm-Message-State: ALoCoQk8YwoMiC+5wiHfScU8BRRKLRjzSHemJhYZq7nrj6FrwM1F1BCI8jM82lQd7LoWDzZ7RubOK71mR48CFTGEYSVEaP/WzVidu4jCXQEY/srYdMuRYuA+vsvXCuDL+/bbyMnWMIAh Cc: mif@ietf.org Subject: Re: [mif] draft-ietf-mif-dhcpv6-route-option-04 published X-BeenThere: mif@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multiple Interface Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 25 Mar 2012 18:31:34 -0000 >> Motivation and uses cases are now significant part of this draft >> itself. If the group believes that it would be cleaner, it may be >> split into separate draft. But please, don't use this possibility as >> a way to delay this work. There are many networks that want this >> option deployed asap. With respect to motivations...I think we need to weed out all the specious ones first, to what's really left and worthy of interest. IMHO, most, if not all, are specious. (And I suspect that Suresh's Line-ID may be useful to address whatever else is left.) [3.1-1] "and the Service Provide would like to avoid routing on the CPE, there is a need to provision static route entries on RGs/CPEs" I read this as "we don't want to do routing so here's how we're going to do routing". If it's dynamic versus static, then saying that might be more clear. [3.1-2] Is there an external source for this claim? It is not at all the case for the two large IPv6 deployments with which I've been directly involved. Furthermore, the current deployments to O(millions) of existing IPv6 users make it seem like this isn't actually an issue. [3.1-4] Perhaps this has been discussed elsewhere, and I'm out of my depth, but I thought DHCPv6 wasn't really spec'd until R10, and even then only DHCPv6-PD. It looks to me like the 3GPP link goes to a draft for R11. Additionally, this 3GPP draft seems to reference this MIF draft. This makes it look like the references are circular (you can't cite IDs), which is a bad justification. [3.1-6] The thing about these walled-garden arguments is that they seem to imply that deployments don't want to give a route to a walled-garden network to non-customers. But surely the existence of a route is not alone sufficient for valid access? IOW, is there harm if a non-customer has a route a walled-garden network of which they are not a customer? Unless the walled-garden is advertising a default route, I wonder what the real harm is. But a potentially more important consideration is why walled garden arguments appear anywhere within a Motivation section. Quoting from the IAB in 2000, section 4.2.1 of RFC3002 (http://tools.ietf.org/html/rfc3002#section-4.2): """ It was strongly recommended that independent of the ubiquity of the "walled garden" deployment scenario that protocols and architectural decisions should not target this model. To continue the success of Internet protocols at operating across a highly diverse and heterogeneous environment the IETF must continue to foster the adoption of an "open model". IETF protocol design must address seamless, secure, and scalable access. """ In the spirit of the above, I would like to see all discussion pertaining to walled gardens unequivocally removed. This removes at least use cases 1, 6, and 8. [3.1-7] Do you have any metrics on the support situation WRT 4191? Both DHCPv6 and RIOs are SHOULDs in the IPv6 Node Requirements RFC (6434), and both are pretty old by now (from 2005?). [3.1-10] s/home network with/home networks/, I think I think the "solve the rogue RA problem" is not a valid argument. You're just trading a rogue RA problem for a rogue DHCPv6 server problem. You can claim some security association with the DHCPv6 server, but you can equally claim some security association with the router(s) (e.g., SEND). Also, I think this is specious: "forced to run two protocols increasing complexity and troubleshooting, where we have proof of concept in IPv4 that only one protocol (DHCP) should be needed." In networks where you want run reliable IPv4, you still need 2 protocols: DHCPv4 and VRRP. Just because they're operated by two different groups doesn't mean you don't need them both. [3.1-11] If this is a use case that is not "investigated further" then I would question why it's needed at all in what is fundamentally a "Motivation" discussion. It also seems circular to propose as a motivation that the option be used to break a tie when the option is coexisting with RAs. [3.1-12] I'm not sure that a "different failure mode" is much of a motivation. I would take exception with a claim like a "rogue DHCP server will cause no immediate harm". If someone gives me different DNS servers they can still hijack all my traffic. Only in this case I think it's even worse: I am aware of no provision in DHCP for the real server to send out messages that can nullify the bad information. Once a host is misconfigured that's pretty much it until the lease lifetime is up or a network change event happens. [3.1-concluding paragraphs] I disagree with the assertion "It is better to have a generic option then [sic] a bunch of competing vendor options". *IF* the decision of the IETF is that this constitutes a "You're Doing It Wrong (TM)" situation, then NO, a standardized option is not better; it would in fact send the opposite message. Also, like Microsoft's RADIUS extension for DNS servers, I don't think you would see multiple competing definitions=E3=83=BCthe first to publish would become the de fact= o standard. Fundamentally, I think the core issue to be decided is whether there should be a standardized way for hosts on the same network to learn different routes from their neighbors. I would think this constitutes a fundamental architectural change, and therefore ought to be considered in 6man (regardless of history and charters). From internet-drafts@ietf.org Mon Mar 26 02:12:34 2012 Return-Path: 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 A959C21F8531; Mon, 26 Mar 2012 02:12:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.464 X-Spam-Level: X-Spam-Status: No, score=-102.464 tagged_above=-999 required=5 tests=[AWL=0.135, BAYES_00=-2.599, 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 FQMqTRNsItyv; Mon, 26 Mar 2012 02:12:33 -0700 (PDT) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AD87F21F84FD; Mon, 26 Mar 2012 02:12:33 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 4.00 Message-ID: <20120326091233.22250.88556.idtracker@ietfa.amsl.com> Date: Mon, 26 Mar 2012 02:12:33 -0700 Cc: mif@ietf.org Subject: [mif] I-D Action: draft-ietf-mif-dns-server-selection-08.txt X-BeenThere: mif@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multiple Interface Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 26 Mar 2012 09:12:35 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Multiple Interfaces Working Group of = the IETF. Title : Improved DNS Server Selection for Multi-Interfaced Nodes Author(s) : Teemu Savolainen Jun-ya Kato Ted Lemon Filename : draft-ietf-mif-dns-server-selection-08.txt Pages : 25 Date : 2012-03-26 A multi-interfaced node is connected to multiple networks, some of which may be utilizing private DNS namespaces. A node commonly receives DNS server configuration information from all connected networks. Some of the DNS servers may have information about namespaces other servers do not have. When a multi-interfaced node needs to utilize DNS, the node has to choose which of the servers to contact to. This document describes DHCPv4 and DHCPv6 options that can be used to configure nodes with information required to perform informed DNS server selection decisions. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-mif-dns-server-selection-08.= txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ This Internet-Draft can be retrieved at: ftp://ftp.ietf.org/internet-drafts/draft-ietf-mif-dns-server-selection-08.t= xt From teemu.savolainen@nokia.com Mon Mar 26 02:19:56 2012 Return-Path: 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 A196621F84DE for ; Mon, 26 Mar 2012 02:19:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.048 X-Spam-Level: X-Spam-Status: No, score=-5.048 tagged_above=-999 required=5 tests=[AWL=1.551, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] 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 93VJBpmz33Hc for ; Mon, 26 Mar 2012 02:19:56 -0700 (PDT) Received: from mgw-sa02.nokia.com (smtp.nokia.com [147.243.1.48]) by ietfa.amsl.com (Postfix) with ESMTP id C07B721F8471 for ; Mon, 26 Mar 2012 02:19:52 -0700 (PDT) Received: from vaebh101.NOE.Nokia.com (vaebh101.europe.nokia.com [10.160.244.22]) by mgw-sa02.nokia.com (Sentrion-MTA-4.2.2/Sentrion-MTA-4.2.2) with ESMTP id q2Q9JeGu010254 for ; Mon, 26 Mar 2012 12:19:51 +0300 Received: from smtp.mgd.nokia.com ([65.54.30.25]) by vaebh101.NOE.Nokia.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.4675); Mon, 26 Mar 2012 12:19:43 +0300 Received: from 008-AM1MPN1-053.mgdnok.nokia.com ([169.254.3.161]) by 008-AM1MMR1-009.mgdnok.nokia.com ([65.54.30.25]) with mapi id 14.01.0355.003; Mon, 26 Mar 2012 11:19:35 +0200 From: To: Thread-Topic: [mif] I-D Action: draft-ietf-mif-dns-server-selection-08.txt Thread-Index: AQHNCzCn+SLau0AxEUeZvdPmeUd8CZZ8TIfQ Date: Mon, 26 Mar 2012 09:19:34 +0000 Message-ID: <916CE6CF87173740BC8A2CE443096962042FDB1C@008-AM1MPN1-053.mgdnok.nokia.com> References: <20120326091233.22250.88556.idtracker@ietfa.amsl.com> In-Reply-To: <20120326091233.22250.88556.idtracker@ietfa.amsl.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-tituslabs-classifications-30: TLPropertyRoot=Nokia;Confidentiality=Nokia Internal Use Only;Project=None; x-titus-version: 3.3.8.1 x-headerinfofordlp: None x-tituslabs-classificationhash-30: VgNFIFU9Hx+/nZJb9Kg7Ivi+ZPYNxIOHHQOy5XIAisnd0NemWySEbulPlVI/QHkZZN/9gjDrg6WMjjydPZC1DX6Jw87Xbe+7Dfc9EVCWqyys8MkNB3u4q9epamKzqLnDKHusvmNqT5LeHKTvvbX9UHferHEnhaMsErH4wjXVRMu1Tz2oudAG4l42AIBoGdlAOEPazIGvIyxefoaf1zW9CeF6lXA+RGafX0lQNIjD7vunIqd8JGz5BzobLec1uYBlXrp3907Vgx6b5c7LwfbeSQmcrwOSNcJq5c0JMVEhcIo= x-originating-ip: [10.162.86.87] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginalArrivalTime: 26 Mar 2012 09:19:43.0225 (UTC) FILETIME=[9441B690:01CD0B31] X-Nokia-AV: Clean Subject: Re: [mif] I-D Action: draft-ietf-mif-dns-server-selection-08.txt X-BeenThere: mif@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multiple Interface Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 26 Mar 2012 09:19:56 -0000 I just fixed idnits on this document revision (all related to references), = no other changes. Teemu > -----Original Message----- > From: mif-bounces@ietf.org [mailto:mif-bounces@ietf.org] On Behalf Of ext > internet-drafts@ietf.org > Sent: 26. maaliskuuta 2012 11:13 > To: i-d-announce@ietf.org > Cc: mif@ietf.org > Subject: [mif] I-D Action: draft-ietf-mif-dns-server-selection-08.txt > > > A New Internet-Draft is available from the on-line Internet-Drafts direct= ories. > This draft is a work item of the Multiple Interfaces Working Group of the > IETF. > > Title : Improved DNS Server Selection for Multi-Interface= d > Nodes > Author(s) : Teemu Savolainen > Jun-ya Kato > Ted Lemon > Filename : draft-ietf-mif-dns-server-selection-08.txt > Pages : 25 > Date : 2012-03-26 > > A multi-interfaced node is connected to multiple networks, some of > which may be utilizing private DNS namespaces. A node commonly > receives DNS server configuration information from all connected > networks. Some of the DNS servers may have information about > namespaces other servers do not have. When a multi-interfaced node > needs to utilize DNS, the node has to choose which of the servers to > contact to. This document describes DHCPv4 and DHCPv6 options that > can be used to configure nodes with information required to perform > informed DNS server selection decisions. > > > A URL for this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-ietf-mif-dns-server-selection-0= 8.txt > > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ > > This Internet-Draft can be retrieved at: > ftp://ftp.ietf.org/internet-drafts/draft-ietf-mif-dns-server-selection-08= .txt > > _______________________________________________ > mif mailing list > mif@ietf.org > https://www.ietf.org/mailman/listinfo/mif From hisuntao@gmail.com Mon Mar 26 05:22:58 2012 Return-Path: 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 A83F921F8715 for ; Mon, 26 Mar 2012 05:22:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.598 X-Spam-Level: X-Spam-Status: No, score=-3.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] 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 zN1ypX0fxqj1 for ; Mon, 26 Mar 2012 05:22:57 -0700 (PDT) Received: from mail-vb0-f44.google.com (mail-vb0-f44.google.com [209.85.212.44]) by ietfa.amsl.com (Postfix) with ESMTP id 485EF21F8724 for ; Mon, 26 Mar 2012 05:22:57 -0700 (PDT) Received: by vbbez10 with SMTP id ez10so2990918vbb.31 for ; Mon, 26 Mar 2012 05:22:56 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=5ndPdrzrkzhgGzlGQTPWaeXDuE7ih6N21cikbDb3lIU=; b=BEzsGO5Q2Y7Qm0M6hS11tlBiY1IVPvP/rPNcoTS/j9Qltt2GSWLkRlj41n3TUDWi6q rAm2yj0MnHq56uoz4Wm44Fzyrsg0D9KFP/aC8Ff80/yFkb9bSMhZdYN+FCrod9HPCoyU nUYgMdr154olSuaiOG6f+wAkWTHsaBYO6XYRHpxLjoPm9awumpjkJLRds+sMJmeUvUv1 QPmJhP2lLGW6uTPy7JrpWSiQWsi0P/deKkHHmJAhMd+uBMlEGtxPSsY7Kchg5o+nhPAg LLC9U+oTV73d4OKnIq4P1SANbjgKFKu9eEYyy0siyDoPByQ6v1UUdKTOhGn3d62DwYbN FYPA== MIME-Version: 1.0 Received: by 10.52.93.138 with SMTP id cu10mr8373354vdb.86.1332764576745; Mon, 26 Mar 2012 05:22:56 -0700 (PDT) Received: by 10.220.183.3 with HTTP; Mon, 26 Mar 2012 05:22:56 -0700 (PDT) In-Reply-To: References: <20120224101611.22703.52041.idtracker@ietfa.amsl.com> <4F47688B.10508@gmail.com> <4F5E2F61.9040009@gmail.com> Date: Mon, 26 Mar 2012 20:22:56 +0800 Message-ID: From: Tao Sun To: Erik Kline Content-Type: multipart/alternative; boundary=20cf307cfeaa2a87a304bc246fbb Cc: mif@ietf.org Subject: Re: [mif] draft-ietf-mif-dhcpv6-route-option-04 published X-BeenThere: mif@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multiple Interface Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 26 Mar 2012 12:22:58 -0000 --20cf307cfeaa2a87a304bc246fbb Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Hi Erik, Thanks for the review. I would like to clarify for your comments on [3.1-4]= . The link to 3GPP TR23.853 is a technical report for a R11 work item. The work item is not finished due to time limits of R11 in 3GPP. You may see that there are 3 scenarios agreed and documented in the TR. This draft refers the TR for the *Scenario* justification. On the *solution mechanism*, the TR listed some related work which includes this draft. The references are not circular since they are from different aspects. Regards, Tao On Mon, Mar 26, 2012 at 2:31 AM, Erik Kline wrote: > >> Motivation and uses cases are now significant part of this draft > >> itself. If the group believes that it would be cleaner, it may be > >> split into separate draft. But please, don't use this possibility as > >> a way to delay this work. There are many networks that want this > >> option deployed asap. > > With respect to motivations...I think we need to weed out all the > specious ones first, to what's really left and worthy of interest. > IMHO, most, if not all, are specious. (And I suspect that Suresh's > Line-ID may be useful to address whatever else is left.) > > [3.1-1] > > "and the Service Provide would like to avoid routing on the CPE, there > is a need to provision static route entries on RGs/CPEs" > > I read this as "we don't want to do routing so here's how we're going > to do routing". If it's dynamic versus static, then saying that might > be more clear. > > [3.1-2] > > Is there an external source for this claim? It is not at all the case > for the two large IPv6 deployments with which I've been directly > involved. Furthermore, the current deployments to O(millions) of > existing IPv6 users make it seem like this isn't actually an issue. > > [3.1-4] > > Perhaps this has been discussed elsewhere, and I'm out of my depth, > but I thought DHCPv6 wasn't really spec'd until R10, and even then > only DHCPv6-PD. > > It looks to me like the 3GPP link goes to a draft for R11. > Additionally, this 3GPP draft seems to reference this MIF draft. This > makes it look like the references are circular (you can't cite IDs), > which is a bad justification. > > [3.1-6] > > The thing about these walled-garden arguments is that they seem to > imply that deployments don't want to give a route to a walled-garden > network to non-customers. But surely the existence of a route is not > alone sufficient for valid access? > > IOW, is there harm if a non-customer has a route a walled-garden > network of which they are not a customer? Unless the walled-garden is > advertising a default route, I wonder what the real harm is. > > But a potentially more important consideration is why walled garden > arguments appear anywhere within a Motivation section. Quoting from > the IAB in 2000, section 4.2.1 of RFC3002 > (http://tools.ietf.org/html/rfc3002#section-4.2): > > """ > It was strongly recommended that independent of the ubiquity of the > "walled garden" deployment scenario that protocols and architectural > decisions should not target this model. To continue the success of > Internet protocols at operating across a highly diverse and > heterogeneous environment the IETF must continue to foster the > adoption of an "open model". IETF protocol design must address > seamless, secure, and scalable access. > """ > > In the spirit of the above, I would like to see all discussion > pertaining to walled gardens unequivocally removed. This removes at > least use cases 1, 6, and 8. > > [3.1-7] > > Do you have any metrics on the support situation WRT 4191? Both > DHCPv6 and RIOs are SHOULDs in the IPv6 Node Requirements RFC (6434), > and both are pretty old by now (from 2005?). > > [3.1-10] > > s/home network with/home networks/, I think > > I think the "solve the rogue RA problem" is not a valid argument. > You're just trading a rogue RA problem for a rogue DHCPv6 server > problem. You can claim some security association with the DHCPv6 > server, but you can equally claim some security association with the > router(s) (e.g., SEND). > > Also, I think this is specious: > > "forced to run two protocols increasing complexity and > troubleshooting, where we have proof of concept in IPv4 that only one > protocol (DHCP) should be needed." > > In networks where you want run reliable IPv4, you still need 2 > protocols: DHCPv4 and VRRP. Just because they're operated by two > different groups doesn't mean you don't need them both. > > [3.1-11] > > If this is a use case that is not "investigated further" then I would > question why it's needed at all in what is fundamentally a > "Motivation" discussion. It also seems circular to propose as a > motivation that the option be used to break a tie when the option is > coexisting with RAs. > > [3.1-12] > > I'm not sure that a "different failure mode" is much of a motivation. > > I would take exception with a claim like a "rogue DHCP server will > cause no immediate harm". If someone gives me different DNS servers > they can still hijack all my traffic. Only in this case I think it's > even worse: I am aware of no provision in DHCP for the real server to > send out messages that can nullify the bad information. Once a host > is misconfigured that's pretty much it until the lease lifetime is up > or a network change event happens. > > [3.1-concluding paragraphs] > > I disagree with the assertion "It is better to have a generic option > then [sic] a bunch of competing vendor options". *IF* the decision of > the IETF is that this constitutes a "You're Doing It Wrong (TM)" > situation, then NO, a standardized option is not better; it would in > fact send the opposite message. Also, like Microsoft's RADIUS > extension for DNS servers, I don't think you would see multiple > competing definitions=E3=83=BCthe first to publish would become the de fa= cto > standard. > > Fundamentally, I think the core issue to be decided is whether there > should be a standardized way for hosts on the same network to learn > different routes from their neighbors. I would think this constitutes > a fundamental architectural change, and therefore ought to be > considered in 6man (regardless of history and charters). > _______________________________________________ > mif mailing list > mif@ietf.org > https://www.ietf.org/mailman/listinfo/mif > --20cf307cfeaa2a87a304bc246fbb Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

Hi Erik,

=C2=A0

Thanks for the review. I would lik= e to clarify for your comments on [3.1-4].

The link to 3GPP TR23.853 is a tec= hnical report for a R11 work item. The work item is not finished due to tim= e limits of R11 in 3GPP.

You may see that there are 3 scena= rios agreed and documented in the TR. This draft refers the TR for the *Sce= nario* justification. On the *solution mechanism*, the TR listed some relat= ed work which includes this draft.

The references are not circular si= nce they are from different aspects.

=C2=A0

Regards,

=C2=A0

Tao


On Mon, Mar 26, 2012 at 2:31 AM, Erik Kline <ek@google.com> wrote:
>> Motivation and uses cases are now significant pa= rt of this draft
>> itself. If the group believes that it would be= cleaner, it may be
>> split into separate draft. But please, don&= #39;t use this possibility as
>> a way to delay this work. There are many networks that want this>> option deployed asap.

With respect to motivations..= .I think we need to weed out all the
specious ones first, to what's = really left and worthy of interest.
IMHO, most, if not all, are specious. =C2=A0(And I suspect that Suresh'= s
Line-ID may be useful to address whatever else is left.)

[3.1-1= ]

"and the Service Provide would like to avoid routing on the C= PE, there
is a need to provision static route entries on RGs/CPEs"

I read= this as "we don't want to do routing so here's how we're = going
to do routing". =C2=A0If it's dynamic versus static, then= saying that might
be more clear.

[3.1-2]

Is there an external source for this c= laim? =C2=A0It is not at all the case
for the two large IPv6 deployments= with which I've been directly
involved. Furthermore, the current de= ployments to O(millions) of
existing IPv6 users make it seem like this isn't actually an issue.
=
[3.1-4]

Perhaps this has been discussed elsewhere, and I'm o= ut of my depth,
but I thought DHCPv6 wasn't really spec'd until = R10, and even then
only DHCPv6-PD.

It looks to me like the 3GPP link goes to a draft fo= r R11.
Additionally, this 3GPP draft seems to reference this MIF draft. = =C2=A0This
makes it look like the references are circular (you can't= cite IDs),
which is a bad justification.

[3.1-6]

The thing about these w= alled-garden arguments is that they seem to
imply that deployments don&#= 39;t want to give a route to a walled-garden
network to non-customers. = =C2=A0But surely the existence of a route is not
alone sufficient for valid access?

IOW, is there harm if a non-custo= mer has a route a walled-garden
network of which they are not a customer= ? =C2=A0Unless the walled-garden is
advertising a default route, I wonde= r what the real harm is.

But a potentially more important consideration is why walled garden
= arguments appear anywhere within a Motivation section. =C2=A0Quoting fromthe IAB in 2000, section 4.2.1 of RFC3002
(http://tools.ietf.org/htm= l/rfc3002#section-4.2):

"""
=C2=A0 It was strongly recommended that independe= nt of the ubiquity of the
=C2=A0 "walled garden" deployment sc= enario that protocols and architectural
=C2=A0 decisions should not targ= et this model. =C2=A0To continue the success of
=C2=A0 Internet protocols at operating across a highly diverse and
=C2= =A0 heterogeneous environment the IETF must continue to foster the
=C2= =A0 adoption of an "open model". =C2=A0IETF protocol design must = address
=C2=A0 seamless, secure, and scalable access.
"""

In the spirit of the above, I would like to see a= ll discussion
pertaining to walled gardens unequivocally removed. This r= emoves at
least use cases 1, 6, and 8.

[3.1-7]

Do you have= any metrics on the support situation WRT 4191? =C2=A0Both
DHCPv6 and RIOs are SHOULDs in the IPv6 Node Requirements RFC (6434),
an= d both are pretty old by now (from 2005?).

[3.1-10]

s/home ne= twork with/home networks/, I think

I think the "solve the rogue= RA problem" is not a valid argument.
You're just trading a rogue RA problem for a rogue DHCPv6 server
pro= blem. =C2=A0You can claim some security association with the DHCPv6
serv= er, but you can equally claim some security association with the
router(= s) (e.g., SEND).

Also, I think this is specious:

=C2=A0 =C2=A0"forced to run= two protocols increasing complexity and
troubleshooting, where we have = proof of concept in IPv4 that only one
protocol (DHCP) should be needed.= "

In networks where you want run reliable IPv4, you still need 2
proto= cols: DHCPv4 and VRRP. =C2=A0Just because they're operated by two
di= fferent groups doesn't mean you don't need them both.

[3.1-1= 1]

If this is a use case that is not "investigated further" then= I would
question why it's needed at all in what is fundamentally a<= br>"Motivation" discussion. =C2=A0It also seems circular to propo= se as a
motivation that the option be used to break a tie when the option is
coe= xisting with RAs.

[3.1-12]

I'm not sure that a "diff= erent failure mode" is much of a motivation.

I would take excep= tion with a claim like a "rogue DHCP server will
cause no immediate harm". =C2=A0If someone gives me different DNS serv= ers
they can still hijack all my traffic. =C2=A0Only in this case I thin= k it's
even worse: I am aware of no provision in DHCP for the real s= erver to
send out messages that can nullify the bad information. =C2=A0Once a hostis misconfigured that's pretty much it until the lease lifetime is up=
or a network change event happens.

[3.1-concluding paragraphs]
I disagree with the assertion "It is better to have a generic opti= on
then [sic] a bunch of competing vendor options". =C2=A0*IF* the = decision of
the IETF is that this constitutes a "You're Doing I= t Wrong (TM)"
situation, then NO, a standardized option is not better; it would in
fac= t send the opposite message. =C2=A0Also, like Microsoft's RADIUS
ext= ension for DNS servers, I don't think you would see multiple
competi= ng definitions=E3=83=BCthe first to publish would become the de facto
standard.

Fundamentally, I think the core issue to be decided is whe= ther there
should be a standardized way for hosts on the same network to= learn
different routes from their neighbors. =C2=A0I would think this c= onstitutes
a fundamental architectural change, and therefore ought to be
considered= in 6man (regardless of history and charters).
_______________________________________________
mif ma= iling list
mif@ietf.org
https://ww= w.ietf.org/mailman/listinfo/mif

--20cf307cfeaa2a87a304bc246fbb-- From jonghyouk@gmail.com Mon Mar 26 08:36:21 2012 Return-Path: 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 0F27D21E80BB for ; Mon, 26 Mar 2012 08:36:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.598 X-Spam-Level: X-Spam-Status: No, score=-3.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] 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 LZ0ZDUy4WvHW for ; Mon, 26 Mar 2012 08:36:19 -0700 (PDT) Received: from mail-iy0-f172.google.com (mail-iy0-f172.google.com [209.85.210.172]) by ietfa.amsl.com (Postfix) with ESMTP id 40AE621E80A3 for ; Mon, 26 Mar 2012 08:36:19 -0700 (PDT) Received: by iazz13 with SMTP id z13so9934893iaz.31 for ; Mon, 26 Mar 2012 08:36:19 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=CfhLkLqxZtxlEr6LUTRDlDWfVltQfk+7iWRZ3w6dobw=; b=pFDweYx0NZS/H2sF6TTmT7J23Ks5yjpLOJohqrskbQUIsD8ZoNC7XOVo/OAP6+3ooN lzwrwDCYW+WgI9x8EwwNivB+BB8euqCd06+YtbvF8kLvWHiSa6OA/Ok19P5lEJJcQLDe kkIwnUV1DFEPYM/eN6WljLwV0Owv6scWcwOjitlKO497CBNUXJwYG5uTD8k8dnFiYaNb Ds/WtEoeXqkdRs1EeLWRFspWlPJ0k5jk8nEP14F2s4fpYar9xLmxhx4mgHrp9J61MHaa FPFqJ9VHMnvjBte0UpWL67o+5YxNmAMBfpdGcnyMI3C4O9fJ/NQbUsoPS/1jv4nSp/ph hFgw== MIME-Version: 1.0 Received: by 10.50.106.226 with SMTP id gx2mr6043867igb.42.1332776178863; Mon, 26 Mar 2012 08:36:18 -0700 (PDT) Received: by 10.64.30.200 with HTTP; Mon, 26 Mar 2012 08:36:18 -0700 (PDT) In-Reply-To: References: <20120301144229.28186.7229.idtracker@ietfa.amsl.com> <4F4FFE91.8020906@gmail.com> Date: Mon, 26 Mar 2012 17:36:18 +0200 Message-ID: From: Jong-Hyouk Lee To: Daniel Migault Content-Type: multipart/alternative; boundary=e89a8f2351e1b4ce6504bc27227e Cc: mif@ietf.org Subject: Re: [mif] I-D Action: draft-mglt-mif-security-requirements-00.txt X-BeenThere: mif@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multiple Interface Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 26 Mar 2012 15:36:21 -0000 --e89a8f2351e1b4ce6504bc27227e Content-Type: text/plain; charset=UTF-8 Dear Daniel. I would like to encourage you not to only focus IPsec cases for securing communication in multiple interface environments. As the title of this draft shows it should address and point out general security requirements for multiple interface environments. IPsec is not the sole solution. Note that the document 00 is not addressing the general security requirements. Access network attachment and flow security in multiple interface environments should be addressed in such a security requirement document. Cheers. On Sun, Mar 25, 2012 at 5:05 PM, Daniel Migault wrote: > Hi Brian, > > Thank you for your remarks we are considering for the 01 version of the > draft that will be published soon. I briefly provide inline responses. > > > On Thu, Mar 1, 2012 at 11:56 PM, Brian E Carpenter < > brian.e.carpenter@gmail.com> wrote: > >> Hi, >> >> I don't understand the scope or the threat model for this draft. >> >> The scope seems to be less than the whole of MIF. It seems to be >> limited to a subset of MIF cases where a provider is in some way >> in control of the acquisition and use of additional interfaces. >> In the general case, nobody is in control - the user device simply >> discovers and uses whatever connectivity appears. If this is a >> correct understanding, could the title, Abstract and Introduction >> make it very clear what the scope is? >> >> No. we are considering the general case of MIF. The confusion comes > probably from the section that considered ISP hosted services. What we > pointed out in this section was that the ISP would be able to adapt the > security of the Service according to the type of network. I remove this > confusing section in 01. > > > >> I don't understand the threat model because it isn't described >> at all. So I can't evaluate any of the assertions about security >> requirements. > > > The model is that a communication being carried on a RAN MAY not need any > protection because RAN is a trusted Network. WLAN MAY not be trusted > Network, and EU switching to WLAN MAY want to protect the communication. We > describe why we recommend IPsec and what IPsec currently misses to address > the Multiple Interfaces Security Requirements. > There is no threats description in 01, but we provide a better description > of the motivations for Security Requirements. > > I do know that a conclusion that IPsec must be used >> for everything is very unpalatable. > > > I agree. For ISPs, IPsec is recommended, but we also insist that there is > no systematic solutions. > > There are risks in any public >> WLAN of course, but they exist whatever crypto is used. >> >> One detail: >> >> > Alternate IP addresses are provided for a given >> > communication, a Primary IP addresses is replaced by an >> > Alternate IP address, and Primary and Alternate are not used >> > simultaneously for the same communication. >> >> This is not true if the device uses recent techniques such as >> MPTCP, which automatically shares the available paths. Such end >> to end techniques are outside the control of the provider. >> > > Right. Version 01 should clarify this. The draft is focused on IPsec > configuration for Multihoming. I considered IKEv2 own mechanisms to deal > with Multihoming. I known work has previously been done to make IKEv2 work > over SCTP to make IKEv2 benefit from SCTP features but do not considered > here. > The idea is to make IKEv2 resistant to change of Interfaces, Interface > fail-over so that IKEv2 can proceed to the IPsec configuration for the > communication. Mobility, Multihoming, Multiple Interfaces do not concern > the communication in itself, but the way to configure IPsec. Configuring > properly IPsec is necessary to avoid IPsec blocking the communication, when > other protocols like SCTP, MTCP performs Mobility or Multihoming. > > Regards, > Daniel > >> Brian >> >> _______________________________________________ >> mif mailing list >> mif@ietf.org >> https://www.ietf.org/mailman/listinfo/mif >> > > > > -- > Daniel Migault > Orange Labs -- Security > +33 6 70 72 69 58 > > _______________________________________________ > mif mailing list > mif@ietf.org > https://www.ietf.org/mailman/listinfo/mif > > -- RSM Department, TELECOM Bretagne, France Jong-Hyouk Lee, living somewhere between /dev/null and /dev/random #email: jonghyouk (at) gmail (dot) com #webpage: http://sites.google.com/site/hurryon/ --e89a8f2351e1b4ce6504bc27227e Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Dear Daniel.

I would like to=C2=A0encourage=C2=A0you not= to only focus IPsec cases for securing communication in multiple interface= environments. As the title of this draft shows it should address and point= out general security requirements for multiple interface environments. IPs= ec is not the sole solution. Note that the document 00 is not addressing th= e general security requirements.

Access network attachment and flow security in multiple= interface environments should be addressed in such a security requirement = document.

Cheers.


On Sun, Mar 25, 2012 at 5:05 PM, Daniel Miga= ult <mglt.ietf@= gmail.com> wrote:
Hi Brian,

Thank you for your remarks we are considering for the=20 01 version of the draft that will be published soon. I briefly provide=20 inline responses.


= On Thu, Mar 1, 2012 at 11:56 PM, Brian E Carpenter <brian.e.carp= enter@gmail.com> wrote:
Hi,

I don't understand the scope or the threat model for this draft.

The scope seems to be less than the whole of MIF. It seems to be
limited to a subset of MIF cases where a provider is in some way
in control of the acquisition and use of additional interfaces.
In the general case, nobody is in control - the user device simply
discovers and uses whatever connectivity appears. If this is a
correct understanding, could the title, Abstract and Introduction
make it very clear what the scope is?

No. we are considering the general case of MIF.= The confusion comes probably from the section that considered ISP hosted s= ervices. What we pointed out in this section was that the ISP would be able= to adapt the security of the Service according to the type of network. I r= emove this confusing section in 01.

=C2=A0
I don't understand the threat model because it isn't described
at all. So I can't evaluate any of the assertions about security
requirements.
=C2=A0
The model is that a c= ommunication being carried on a RAN MAY not need any protection because RAN= is a trusted Network. WLAN MAY not be trusted Network, and EU switching to= WLAN MAY want to protect the communication. We describe why we recommend I= Psec and what IPsec currently misses to address the Multiple Interfaces Sec= urity Requirements.
There is no threats description in 01, but we provide a better description = of the motivations for Security Requirements.

I do know that a conclusion that IPsec must be used
for everything is very unpalatable.

I agree. For= ISPs, IPsec is recommended, but we also insist that there is no systematic= solutions.

There are risks in any public
WLAN of course, but they exist whatever crypto is used.

One detail:

> Alternate IP addresses are provided for a given
> communication, a Primary IP addresses is replaced by an
> Alternate IP address, and Primary and Alternate are not used
> simultaneously for the same communication.

This is not true if the device uses recent techniques such as
MPTCP, which automatically shares the available paths. Such end
to end techniques are outside the control of the provider.
=

Right. Version 01 should=C2=A0 clarify this. The draft is fo= cused on IPsec configuration for Multihoming. I considered IKEv2 own mechan= isms to deal with Multihoming. I known work has previously been done to mak= e IKEv2 work over SCTP to make IKEv2 benefit from SCTP features but do not = considered here.=C2=A0
The idea is to make IKEv2 resistant to change of Interfaces, Interface fail= -over so that IKEv2 can proceed to the IPsec configuration for the communic= ation. Mobility, Multihoming, Multiple Interfaces do not concern the commun= ication in itself, but the way to configure IPsec. Configuring properly IPs= ec is necessary to avoid IPsec blocking the communication, when other proto= cols like SCTP, MTCP performs Mobility or Multihoming.
=C2=A0
Regards,
Daniel
=C2=A0 Brian

_______________________________________________
mif mailing list
mif@ietf.org
htt= ps://www.ietf.org/mailman/listinfo/mif


--
Daniel Migault
Orange Labs -- Security
= +33 6 70 72 69 58

_______________________________________________
mif mailing list
mif@ietf.org
htt= ps://www.ietf.org/mailman/listinfo/mif




--
RSM= Department, TELECOM Bretagne, France
Jong-Hyouk Lee, living some= where between /dev/null and /dev/random

#email:=C2= =A0jonghyouk (at) gmail (dot) com

--e89a8f2351e1b4ce6504bc27227e-- From denghui02@gmail.com Mon Mar 26 10:28:52 2012 Return-Path: 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 512C221E80BC; Mon, 26 Mar 2012 10:28:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.381 X-Spam-Level: X-Spam-Status: No, score=-103.381 tagged_above=-999 required=5 tests=[AWL=0.217, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1, 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 H3zeu6uB39Xu; Mon, 26 Mar 2012 10:28:51 -0700 (PDT) Received: from mail-yx0-f172.google.com (mail-yx0-f172.google.com [209.85.213.172]) by ietfa.amsl.com (Postfix) with ESMTP id E40DD21E80E5; Mon, 26 Mar 2012 10:28:50 -0700 (PDT) Received: by yenm5 with SMTP id m5so4465469yen.31 for ; Mon, 26 Mar 2012 10:28:50 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:date:message-id:subject:from:to:cc:content-type; bh=E/RzDaHuekNZWCc1VMUlQY/8x40p/ArRb4iArllNmIg=; b=Pp5LSlX2DP7rIwDrKzJx6/xdoWrR6XGneLrVVavgd1/WWDtucQpp7KgITFlERkMQBd Vsx0BGRcPcXOrEBE/J90mkcAt+gWBPJik+ubUAXTpMSEi1xOROO3WJkiJUkFuENRzvN+ 1KAwUQncqfvlVYxyp6kMvY6ojvd7fpX0mVkSFJmN2LZShoPbYEkn4bvF2nz3dSmuTV4a 4n3heGZDa8XSky7OBhu9WrNhCt/I3PfRa34H1/5T+HXBcf7rd7cQGA+FJYdAxYuVSdqN 2EwDaOjHexvLgN/1ZlpGrfeNLh0MikvnRyYCQxITTBFIA0HP98Gb29bnqHXnpL7GzdD/ xM8w== MIME-Version: 1.0 Received: by 10.236.46.232 with SMTP id r68mr23062351yhb.80.1332782930398; Mon, 26 Mar 2012 10:28:50 -0700 (PDT) Received: by 10.146.20.14 with HTTP; Mon, 26 Mar 2012 10:28:50 -0700 (PDT) Date: Mon, 26 Mar 2012 19:28:50 +0200 Message-ID: From: Hui Deng To: MIF Mailing List , Internet Area , IETF Discussion Content-Type: multipart/alternative; boundary=20cf303bfe24210f7f04bc28b539 Cc: thierry.berisot@telekom.de, jerry.shih@att.com, liliana.dinale@ericsson.com, Ralph Droms , msk@cloudmark.com Subject: [mif] OMA IETF MIF API Workshop - Room info X-BeenThere: mif@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multiple Interface Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 26 Mar 2012 17:28:52 -0000 --20cf303bfe24210f7f04bc28b539 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable OMA IETF MIF API Workshop Time: Tuesday: 18:10-20:00 Location: room 212/213 1) Program 1.1) OMA OpenCMAPI activity (Thierry Berisot, OMA) 1.2) IETF MIF API Design (Ted Lemon, IETF) 1.3) IETF API related consideration (TBD) 1.4) OMA API Program (Liliana Dinale, OMA) 1.5) Vendor's today implementation (Maybe) 1.6) Next step between IETF and OMA (Thierry, Margaret, and Hui) 2) Purpose 2.1) From IETF, this workshop would help to explain the API related topic, and clarify what is recommended and not recommended to do and standardized, if possible, either publish a information document or adding word into the current MIF api draft about how to use those MIF API for Internet developer= . and some current practices information how today smart terminal is doing. 2.2) From OMA perspective, to socialize OMA=92s published specifications an= d current ongoing standards activities in the area of APIs. To make sure that the standards landscape for APIs is coordinated and harmonized. To solicit feedback about OMA=92s specification for Authorization4APIs, which is built on IETF OAuth as well as OpenCMAPI. 3) Outcomes: 3.1) Future work about how to use those MIF API in an IETF information document or inside current MIF API documentfor Internet developers. 3.2) Outcomes OMA: Improved understanding of each others=92 activities, and a coordinated approach going forward 3.3) Better mutual understanding of the work of both organizations, and how to cooperate in the future. --20cf303bfe24210f7f04bc28b539 Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: quoted-printable

OMA IETF MIF API Workshop
=A0
Time: Tuesday: 18:10-20:00
Locati= on: room 212/213
=A0
1) Program
1.1) OMA OpenCMAPI activity (Thier= ry Berisot, OMA)
1.2) IETF MIF API Design (Ted Lemon, IETF)
1.3) IET= F API related consideration (TBD)
1.4) OMA API Program (Liliana Dinale, OMA)
1.5) Vendor's today impl= ementation (Maybe)
1.6) Next step between IETF and OMA (Thierry, Margare= t, and Hui)
=A0
2) Purpose
2.1) From IETF, this workshop would hel= p to explain the API related topic,
and clarify what is recommended and not recommended to do and standardized,=
if possible, either publish a information document or adding word into= the
current MIF api draft about how to use those MIF API for Internet = developer.
and some current practices information how today smart terminal is doing. <= br>=A0
2.2) From OMA perspective, to socialize OMA=92s published specifi= cations and
current ongoing standards activities in the area of APIs. T= o make sure that
the standards landscape for APIs is coordinated and harmonized. To solicit =
feedback about OMA=92s specification for Authorization4APIs, which is b= uilt
on IETF OAuth as well as OpenCMAPI.
=A0
3) Outcomes:
3.1)= Future work about how to use those MIF API in an IETF information
=A0document or inside current MIF API documentfor Internet developers.

3.2) Outcomes OMA: Improved understanding of each others=92 activities,<= br>=A0and a coordinated approach going forward

3.3) Better mutual understanding of the work of both organizations,
= =A0and how to cooperate in the future.

--20cf303bfe24210f7f04bc28b539-- From ek@google.com Tue Mar 27 01:50:17 2012 Return-Path: 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 3EEC221F8802 for ; Tue, 27 Mar 2012 01:50:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.737 X-Spam-Level: X-Spam-Status: No, score=-102.737 tagged_above=-999 required=5 tests=[AWL=0.240, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1, 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 JXBCIPOlW8k0 for ; Tue, 27 Mar 2012 01:50:16 -0700 (PDT) Received: from mail-qc0-f172.google.com (mail-qc0-f172.google.com [209.85.216.172]) by ietfa.amsl.com (Postfix) with ESMTP id 7192721F880B for ; Tue, 27 Mar 2012 01:50:16 -0700 (PDT) Received: by qcsq13 with SMTP id q13so4461479qcs.31 for ; Tue, 27 Mar 2012 01:50:15 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:x-system-of-record; bh=Nw8zm3o72NgaX7reURtAqe5dPOWUmJnntgDOWyK7WOA=; b=hFKnEXYV5ldxCj+yaO6d3H/Z5f7glys+4W6YanxJJvgaTePtVNLD0cobp9bb4g5co4 KnltwAiZ2Q8w6Mpmfv5Wx/vSw4aXtuy66u3wUkqcBCvDYmqKWDd7BZHgZjH8Ajpd5v6o mMaFmwB+1LLTD0otq+2NvWrmTVpW+Vk+4TjMMhoojpQsC64jHEWk6ZJZiPZA32Ua8u+i GzKx0IscWf5JyC5msn45Re7zrLu8oF90Oryh55QEomHVK7UnRZlms9r9Xed/bbfQnUVF 7eS7TdpGHpXf+6f6u+BADSIFqhgcmMcA4Vag1FA35GrOaiA22T3OF1VwcsOeGeirgDzL KtcQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:x-system-of-record:x-gm-message-state; bh=Nw8zm3o72NgaX7reURtAqe5dPOWUmJnntgDOWyK7WOA=; b=WJ4S4CgkGLepLhSH68mt0ziBF/CMolaOMltWlIIkRkiXfbt5fxtqt5eVVrzuTc9q9n lwpGR5rb8WK08zlXYNuKwVF61pZh3W77FOQlqKLgj5FsJCVlCZ9ZrQpNrJc6xeyoqLre nJqnT5oPSXyCdCRZeNAlcC3ivs7WfiKvmf3YagUOAMtEOvXSuRqC66mOYNwfIPpYJ1lg uZ8+mm/QV19uoZPQdM5CguwwKTLjvk7OtEVYRvQI5mGMF4D8Kie7L5u3I7+iuvmJL+Xs nwDA80mcXvLLjCrXY/QLXLV5O8C70h54k3rY1y881nfJZgazKm16wZnUqY4N5rl6cfuu zb5g== Received: by 10.224.33.9 with SMTP id f9mr1934585qad.49.1332838215748; Tue, 27 Mar 2012 01:50:15 -0700 (PDT) MIME-Version: 1.0 Received: by 10.224.33.9 with SMTP id f9mr1934578qad.49.1332838215678; Tue, 27 Mar 2012 01:50:15 -0700 (PDT) Received: by 10.229.128.170 with HTTP; Tue, 27 Mar 2012 01:50:15 -0700 (PDT) In-Reply-To: References: <20120224101611.22703.52041.idtracker@ietfa.amsl.com> <4F47688B.10508@gmail.com> <4F5E2F61.9040009@gmail.com> Date: Tue, 27 Mar 2012 08:50:15 +0000 Message-ID: From: Erik Kline To: Tao Sun Content-Type: text/plain; charset=UTF-8 X-System-Of-Record: true X-Gm-Message-State: ALoCoQnUu6APbHBHOrHM6pI0BDUfSp/PTWEhz5Nt+WBo8GNEJ7+KlXwk7ofLh+323eb4BodglsucI4mJ3V4pU9VJ4dBE59WFGtc4frjm344WqtStz0Uf17dYrzsEFbK5a2vTqprsRotj Cc: mif@ietf.org Subject: Re: [mif] draft-ietf-mif-dhcpv6-route-option-04 published X-BeenThere: mif@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multiple Interface Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 27 Mar 2012 08:50:17 -0000 > The references are not circular since they are from different aspects. For me personally that still sounds circular, though more like it's trying to claim it's not based solely on a technicality. From alexandru.petrescu@gmail.com Tue Mar 27 04:29:08 2012 Return-Path: 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 31A2E21E817D for ; Tue, 27 Mar 2012 04:29:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] 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 hHCX9bzUvrvP for ; Tue, 27 Mar 2012 04:29:07 -0700 (PDT) Received: from mail-we0-f172.google.com (mail-we0-f172.google.com [74.125.82.172]) by ietfa.amsl.com (Postfix) with ESMTP id 67DDE21F8838 for ; Tue, 27 Mar 2012 04:29:07 -0700 (PDT) Received: by werb10 with SMTP id b10so5821940wer.31 for ; Tue, 27 Mar 2012 04:29:06 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; bh=+bcJms0CnyNtQnDi4aTbrh5BflYCQvkfb2aYOnzECqA=; b=S8QKX/1Ua0xOOv+u6B0pY1BEAEgSfdFB84Ks80pzFgd70kKrAcGfh5aeZK5RyBV3jw FXQZlwYg6gIOTay2On/G9ZO4wBkvpas4/tujDszq34SFRqkL7JH84lazRcvaFqU8AF57 eBZD79CC8NnD6lS1dqEY13TlI0pg0jJkHwVtpN37YJGDXMXdyptmlik6XNp3A8PveAy7 KS4up/6OBx9VADe+4N72pQDD8JVoULo2ZGE4aBy4H9sMqbLvauiI8DuUmwUOkePzg4mC gayAzXtMpCzGbIKU4xvFTfRuJ5X939PNsGgQaf1PnVYCANltbO8LRSpyipa4kG8eruMJ G+DA== Received: by 10.216.225.12 with SMTP id y12mr14277772wep.39.1332847746497; Tue, 27 Mar 2012 04:29:06 -0700 (PDT) Received: from [130.129.22.135] (dhcp-1687.meeting.ietf.org. [130.129.22.135]) by mx.google.com with ESMTPS id ff2sm80065727wib.9.2012.03.27.04.29.05 (version=TLSv1/SSLv3 cipher=OTHER); Tue, 27 Mar 2012 04:29:05 -0700 (PDT) Message-ID: <4F71A47C.7050906@gmail.com> Date: Tue, 27 Mar 2012 13:29:00 +0200 From: Alexandru Petrescu User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:11.0) Gecko/20120312 Thunderbird/11.0 MIME-Version: 1.0 To: Ted Lemon References: <20120224101611.22703.52041.idtracker@ietfa.amsl.com> <4F47688B.10508@gmail.com> <4F5E2F61.9040009@gmail.com> <611FBED3-349A-43E7-B4B9-0BC313EA4F7A@nominum.com> <4F61E04F.4020800@gmail.com> <4F636291.7060104@gmail.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Cc: mif Subject: Re: [mif] draft-ietf-mif-dhcpv6-route-option-04 published X-BeenThere: mif@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multiple Interface Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 27 Mar 2012 11:29:08 -0000 Le 16/03/2012 18:23, Ted Lemon a écrit : > On Mar 16, 2012, at 11:56 AM, Alexandru > Petrescu wrote: >> Not all plaforms benefit from the typical timer implementation as >> a PC-class monolithic kernel offers. > > Platforms that cannot determine that time has passed won't be able to > know that a prefix is deprecated, or no longer valid, correct. > >> SO there would _be_ a conversion needed, right? This may need to >> be specified. Wouldn't be easier to specify that both lifetimes >> (from ND and from DHCP) are represented in the same manner, thus no >> conversion? > > The point is that neither the DHCP time nor the RA time is in the > form needed to notice when a prefix has stopped being preferred, or > has become invalid. So in both cases, a conversion to absolute time > will be necessary. There is simply no way in which we can make the > implementor's life easier by having the DHCP offset be 16 bits. Well maybe there is. A conversion in absolute time may indeed be necessary, provided systems keep same time, that being another matter. But the other conversion - between DHCP's way of representing lifetime and ND's way of same could be avoided, simply by representing them in the same manner (16bit length as ND does). A single unique C function could be used the same to convert the lifetime field from a DHCP message to absolute time, and fro, ND message field to absolute time. Otherwise one would have to write two functions. I find it strange that you oppose such an obvious thing to do - represent lifetimes in the same manner across protocols. What is the reason of _not_ representing lifetimes in the same manner across protocols? We do represent Types and other things in the same manner, why not lifetimes? Alex From alexandru.petrescu@gmail.com Tue Mar 27 04:47:39 2012 Return-Path: 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 F40DA21E81A3 for ; Tue, 27 Mar 2012 04:47:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] 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 Yk4vjkl+G3KE for ; Tue, 27 Mar 2012 04:47:38 -0700 (PDT) Received: from mail-wi0-f172.google.com (mail-wi0-f172.google.com [209.85.212.172]) by ietfa.amsl.com (Postfix) with ESMTP id 66C6621E81A4 for ; Tue, 27 Mar 2012 04:47:37 -0700 (PDT) Received: by wibhj6 with SMTP id hj6so4299446wib.13 for ; Tue, 27 Mar 2012 04:47:36 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; bh=D4umMIzWzEv6i25ZlpDo2+MKcc+iDZ9g1utHPNQKoYk=; b=HXlzCkJqnRsCbbBK+IlqlFP+r/MAiGTIJxYPHJ7/3tBmCWhFo1VhxfWWS/CGSiqKmB DLF8eTtr2hOygX8eaKhRQDZyoLHgDB+9yxH6sOZf8jdflTqCGBiLWtgjn9ml3JNlHzpl caXoqWbBGjwQJKLP12AI5CcQSCJfCnft13E0w9epvXItPA6Sis5T7Ay1OyGY/ziPaT4O Tr5t+k5r3GHVCfeEWZfnoay+vml13Y+mR+/BvyNLfjNM6rt9fJkw0L7fJE/YcyBt1ixF UxL3wBJYRT6jE4aknUjxq40nKGZ1UcEnzR0jiqpl3zkwKvHfNqRhWsyODydeTl4kc8MK eLLw== Received: by 10.180.103.35 with SMTP id ft3mr26761770wib.0.1332848856595; Tue, 27 Mar 2012 04:47:36 -0700 (PDT) Received: from [130.129.22.135] (dhcp-1687.meeting.ietf.org. [130.129.22.135]) by mx.google.com with ESMTPS id l5sm48862531wia.11.2012.03.27.04.47.35 (version=TLSv1/SSLv3 cipher=OTHER); Tue, 27 Mar 2012 04:47:36 -0700 (PDT) Message-ID: <4F71A8D1.6000807@gmail.com> Date: Tue, 27 Mar 2012 13:47:29 +0200 From: Alexandru Petrescu User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:11.0) Gecko/20120312 Thunderbird/11.0 MIME-Version: 1.0 To: Erik Kline References: <20120224101611.22703.52041.idtracker@ietfa.amsl.com> <4F47688B.10508@gmail.com> <4F5E2F61.9040009@gmail.com> In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Cc: mif@ietf.org Subject: Re: [mif] draft-ietf-mif-dhcpv6-route-option-04 published X-BeenThere: mif@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multiple Interface Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 27 Mar 2012 11:47:39 -0000 Le 25/03/2012 20:31, Erik Kline a écrit : >>> Motivation and uses cases are now significant part of this draft >>> itself. If the group believes that it would be cleaner, it may >>> be split into separate draft. But please, don't use this >>> possibility as a way to delay this work. There are many networks >>> that want this option deployed asap. > > With respect to motivations...I think we need to weed out all the > specious ones first, to what's really left and worthy of interest. > IMHO, most, if not all, are specious. (And I suspect that Suresh's > Line-ID may be useful to address whatever else is left.) > > [3.1-1] > > "and the Service Provide would like to avoid routing on the CPE, > there is a need to provision static route entries on RGs/CPEs" > > I read this as "we don't want to do routing so here's how we're going > to do routing". If it's dynamic versus static, then saying that > might be more clear. > > [3.1-2] > > Is there an external source for this claim? It is not at all the > case for the two large IPv6 deployments with which I've been directly > involved. Furthermore, the current deployments to O(millions) of > existing IPv6 users make it seem like this isn't actually an issue. > > [3.1-4] > > Perhaps this has been discussed elsewhere, and I'm out of my depth, > but I thought DHCPv6 wasn't really spec'd until R10, and even then > only DHCPv6-PD. > > It looks to me like the 3GPP link goes to a draft for R11. > Additionally, this 3GPP draft seems to reference this MIF draft. This > makes it look like the references are circular (you can't cite IDs), > which is a bad justification. > > [3.1-6] > > The thing about these walled-garden arguments is that they seem to > imply that deployments don't want to give a route to a walled-garden > network to non-customers. But surely the existence of a route is > not alone sufficient for valid access? > > IOW, is there harm if a non-customer has a route a walled-garden > network of which they are not a customer? Unless the walled-garden > is advertising a default route, I wonder what the real harm is. Allow me to take advantage of this conversation to mention that this brings up another issue. When setting up routes one would like to make sure they're right and they lead somewhere at least most of the time. At the smart end node and dumb network, there should always exist a fallback and that fallback is typically the default route ("when everything else fails"). In this sense, if the end node sets up its routes with DHCP, it would like to be sure they're right most of the time, otherwise use the default route. But when the default route _and_ the other more specific routes are provided by DHCP, and if failing, then there is a risk of misconfiguration. Something that could be done about this is the use of different Types in DHCP (ORO) for specific routes and a different Type for default routes. This would mean not only that the config file owuld have different sections for default routes vs specific routes (thus guide the Server's administrator to double check the default part) but also the DHCP Client implementation to have separate software sections for specific routes vs default routes. Some lighter DHCP Clients may choose to implement _only_ the default route option part (and not the specific route part). With respect to this there was also a question about compliance with specs - if a stack doesn implement eg ICMP Redirect then it's not compliant. Do we want to ensure the same level of strength in compliance with DHCP? Even for low end devices? Alex > > But a potentially more important consideration is why walled garden > arguments appear anywhere within a Motivation section. Quoting from > the IAB in 2000, section 4.2.1 of RFC3002 > (http://tools.ietf.org/html/rfc3002#section-4.2): > > """ It was strongly recommended that independent of the ubiquity of > the "walled garden" deployment scenario that protocols and > architectural decisions should not target this model. To continue > the success of Internet protocols at operating across a highly > diverse and heterogeneous environment the IETF must continue to > foster the adoption of an "open model". IETF protocol design must > address seamless, secure, and scalable access. """ > > In the spirit of the above, I would like to see all discussion > pertaining to walled gardens unequivocally removed. This removes at > least use cases 1, 6, and 8. > > [3.1-7] > > Do you have any metrics on the support situation WRT 4191? Both > DHCPv6 and RIOs are SHOULDs in the IPv6 Node Requirements RFC (6434), > and both are pretty old by now (from 2005?). > > [3.1-10] > > s/home network with/home networks/, I think > > I think the "solve the rogue RA problem" is not a valid argument. > You're just trading a rogue RA problem for a rogue DHCPv6 server > problem. You can claim some security association with the DHCPv6 > server, but you can equally claim some security association with the > router(s) (e.g., SEND). > > Also, I think this is specious: > > "forced to run two protocols increasing complexity and > troubleshooting, where we have proof of concept in IPv4 that only one > protocol (DHCP) should be needed." > > In networks where you want run reliable IPv4, you still need 2 > protocols: DHCPv4 and VRRP. Just because they're operated by two > different groups doesn't mean you don't need them both. > > [3.1-11] > > If this is a use case that is not "investigated further" then I would > question why it's needed at all in what is fundamentally a > "Motivation" discussion. It also seems circular to propose as a > motivation that the option be used to break a tie when the option is > coexisting with RAs. > > [3.1-12] > > I'm not sure that a "different failure mode" is much of a > motivation. > > I would take exception with a claim like a "rogue DHCP server will > cause no immediate harm". If someone gives me different DNS servers > they can still hijack all my traffic. Only in this case I think > it's even worse: I am aware of no provision in DHCP for the real > server to send out messages that can nullify the bad information. > Once a host is misconfigured that's pretty much it until the lease > lifetime is up or a network change event happens. > > [3.1-concluding paragraphs] > > I disagree with the assertion "It is better to have a generic option > then [sic] a bunch of competing vendor options". *IF* the decision > of the IETF is that this constitutes a "You're Doing It Wrong (TM)" > situation, then NO, a standardized option is not better; it would in > fact send the opposite message. Also, like Microsoft's RADIUS > extension for DNS servers, I don't think you would see multiple > competing definitionsーthe first to publish would become the de facto > standard. > > Fundamentally, I think the core issue to be decided is whether there > should be a standardized way for hosts on the same network to learn > different routes from their neighbors. I would think this > constitutes a fundamental architectural change, and therefore ought > to be considered in 6man (regardless of history and charters). > From alexandru.petrescu@gmail.com Tue Mar 27 04:56:57 2012 Return-Path: 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 3DE0521F89F6 for ; Tue, 27 Mar 2012 04:56:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] 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 kb8gyHZKsgk0 for ; Tue, 27 Mar 2012 04:56:56 -0700 (PDT) Received: from mail-wi0-f178.google.com (mail-wi0-f178.google.com [209.85.212.178]) by ietfa.amsl.com (Postfix) with ESMTP id 5F8E521F89F5 for ; Tue, 27 Mar 2012 04:56:56 -0700 (PDT) Received: by wibhq7 with SMTP id hq7so4383235wib.13 for ; Tue, 27 Mar 2012 04:56:55 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:subject :content-type:content-transfer-encoding; bh=A4Bmwg4npsuAumVRPUdfAUC6kf7lYZl85STHBL1AbCI=; b=nF9eLVTgtKLO1VZYQZCc2+sTbceC0GfDk0h49RY6XUWY/zAllot1s20+BOYq0Sk/0G JawrzzIHmlNOXEc+ZMjHbRMpJRJG3sDAIDiaeXjavZyy/0w5BbGNjRScV8meo/ok2khz +36toyWAKrwj/n6uXgZeTlZo0TdNacCbODptSowDec8tcDmf8NZ9wyC75odip0n42i43 6gBLRL1L5yzurDi8gRdbyTEYmeeJi0ISF1/oCVihmp4Pwy/OyOcEoTpzC+riyChAlvb9 smY0lZJkNQCOHTjqCiRSzJUU3zLKxQgWQJhrJBoU4qi+BP4vjHXsVik8afUS/+fcnVNd Me7A== Received: by 10.180.85.70 with SMTP id f6mr27216315wiz.5.1332849415564; Tue, 27 Mar 2012 04:56:55 -0700 (PDT) Received: from [130.129.22.135] (dhcp-1687.meeting.ietf.org. [130.129.22.135]) by mx.google.com with ESMTPS id w10sm80398368wiy.3.2012.03.27.04.56.53 (version=TLSv1/SSLv3 cipher=OTHER); Tue, 27 Mar 2012 04:56:54 -0700 (PDT) Message-ID: <4F71AB00.2020404@gmail.com> Date: Tue, 27 Mar 2012 13:56:48 +0200 From: Alexandru Petrescu User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:11.0) Gecko/20120312 Thunderbird/11.0 MIME-Version: 1.0 To: mif Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: [mif] Issue: separate specific routes from default routes? draft-ietf-mif-dhcpv6-route-option-04 X-BeenThere: mif@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multiple Interface Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 27 Mar 2012 11:56:57 -0000 Dear participants in MIF WG, Currently draft-ietf-mif-dhcpv6-route-option-04 specifies a way for the DHCPv6 Server to communicate a set of routes to the DHCPv6 Client. This covers both specific routes and the particular case of default routes (a default route is meant when the RT_PREFIX option is absent, or alternatively by using 128 0 bits as RT_PREFIX). I think this is an issue. It's not good to have two different things to achieve the same functionality. Second, using default routes in the same option type of specific routes means that they'd share the same faith - if specific routes are wrongly configured in the same section of the config file, there is a risk that the default route is wrongly configured too. Or, the default route is something of last resort, so it would be better to have it configured in a different place, communicated with a different ORO type. Third, if a single way of configuring default an specific routes with DHCP then this means that a bigger software implementation would be needed even for lightweight devices. Or, lightweight devices only use a single route - the default route. I suggest we separate the default route ORO from the specific routes ORO. I would like to request oppinion from the WG about this. Yours, Alex From alexandru.petrescu@gmail.com Tue Mar 27 05:02:03 2012 Return-Path: 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 A6C2C21F8A39 for ; Tue, 27 Mar 2012 05:02:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] 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 M2q0U+mJUwED for ; Tue, 27 Mar 2012 05:02:03 -0700 (PDT) Received: from mail-we0-f172.google.com (mail-we0-f172.google.com [74.125.82.172]) by ietfa.amsl.com (Postfix) with ESMTP id 0188521F89CA for ; Tue, 27 Mar 2012 05:02:02 -0700 (PDT) Received: by werb10 with SMTP id b10so5844928wer.31 for ; Tue, 27 Mar 2012 05:02:02 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:subject :content-type:content-transfer-encoding; bh=gJjz4ee0dbJKjtx0/M85AoDSAz9uzFe+rdVuE3qIfMY=; b=tQugrfVpy3TSgYbNvoUHKwc91otSeCDlGx00dEPSoH5nWpZrgHr4Ve1UvCGxcOG2mm WeNQNpmEQblxLwTpTTvnPVJLcnKANvdKP1W45M1uI6w9qP5HWo8ocoKUHZG/Xwl4Eckm 1yOK4o4Vbe9+AxdxvbEKyOykl0hrhWS1Xom2Um85Ve7uFgSDC5HfTzk3sq4lVYv1SnHr fERi3e6TkYzmcBEFwAn5e1T0XJSmD45W+scc0X1nnqSMLsHR9nUDxk3O1Jb14MNbxa+2 M8jrRdbj10JFWOouyKnZh2Go2N2lDXJMXSv+jFJkzdRj+Sh8xSWx6DgxLWExVnP/MTTz O1Gg== Received: by 10.180.24.35 with SMTP id r3mr15970335wif.7.1332849722197; Tue, 27 Mar 2012 05:02:02 -0700 (PDT) Received: from [130.129.22.135] (dhcp-1687.meeting.ietf.org. [130.129.22.135]) by mx.google.com with ESMTPS id fz9sm48967162wib.3.2012.03.27.05.02.01 (version=TLSv1/SSLv3 cipher=OTHER); Tue, 27 Mar 2012 05:02:01 -0700 (PDT) Message-ID: <4F71AC33.6050506@gmail.com> Date: Tue, 27 Mar 2012 14:01:55 +0200 From: Alexandru Petrescu User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:11.0) Gecko/20120312 Thunderbird/11.0 MIME-Version: 1.0 To: mif Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: [mif] Issue: lifetime 32bit or 16bit ? draft-ietf-mif-dhcpv6-route-option-04 X-BeenThere: mif@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multiple Interface Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 27 Mar 2012 12:02:03 -0000 Dear participants in MIF WG, Currently draft-ietf-mif-dhcpv6-route-option-04 specifies that the lifetime of a route (and implicitely of a default route) is to be 32bit length field. On another hand, the currently implemented default routes are implemented according to ND Neighbor Discovery, which uses route_r_ lifetime on 16bit (RFC 4861 search "Router Lifetime"). I think this is an issue. It generates additional work to the implementer. If one agrees that it is good to store the DHCP default route in the existing ND data structures, then one notices a conversion is needed. If these lifetime fields were expressed in the same number of bits (preferably 16bit, because that exists already) then the implementer would be relieved from conversion work. I wanted to ask the oppinion of the WG about this issue. Yours, Alex From marc.blanchet@viagenie.ca Tue Mar 27 05:05:57 2012 Return-Path: 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 32A4721E81BA for ; Tue, 27 Mar 2012 05:05:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.548 X-Spam-Level: X-Spam-Status: No, score=-102.548 tagged_above=-999 required=5 tests=[AWL=0.050, BAYES_00=-2.599, HTML_MESSAGE=0.001, 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 x86QlnKEvSmu for ; Tue, 27 Mar 2012 05:05:56 -0700 (PDT) Received: from jazz.viagenie.ca (unknown [IPv6:2620:0:230:8000:226:55ff:fe57:14db]) by ietfa.amsl.com (Postfix) with ESMTP id 64E6E21E81BB for ; Tue, 27 Mar 2012 05:05:56 -0700 (PDT) Received: from dhcp-51c6.meeting.ietf.org (dhcp-51c6.meeting.ietf.org [130.129.81.198]) by jazz.viagenie.ca (Postfix) with ESMTPSA id A75DE40054; Tue, 27 Mar 2012 08:05:55 -0400 (EDT) Mime-Version: 1.0 (Apple Message framework v1257) Content-Type: multipart/alternative; boundary="Apple-Mail=_A029AF96-F446-4CC0-AE2D-21DB10C75CBE" From: Marc Blanchet In-Reply-To: <4F71A8D1.6000807@gmail.com> Date: Tue, 27 Mar 2012 14:05:54 +0200 Message-Id: <3BA5CC86-1D2F-4DC1-8117-2C55218224BA@viagenie.ca> References: <20120224101611.22703.52041.idtracker@ietfa.amsl.com> <4F47688B.10508@gmail.com> <4F5E2F61.9040009@gmail.com> <4F71A8D1.6000807@gmail.com> To: Alexandru Petrescu X-Mailer: Apple Mail (2.1257) Cc: mif@ietf.org Subject: Re: [mif] draft-ietf-mif-dhcpv6-route-option-04 published X-BeenThere: mif@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multiple Interface Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 27 Mar 2012 12:05:57 -0000 --Apple-Mail=_A029AF96-F446-4CC0-AE2D-21DB10C75CBE Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=iso-8859-1 Le 2012-03-27 =E0 13:47, Alexandru Petrescu a =E9crit : >=20 > When setting up routes one would like to make sure they're right and > they lead somewhere at least most of the time. At the smart end node > and dumb network, there should always exist a fallback and that = fallback > is typically the default route ("when everything else fails"). >=20 > In this sense, if the end node sets up its routes with DHCP, it would > like to be sure they're right most of the time, otherwise use the > default route. >=20 > But when the default route _and_ the other more specific routes are > provided by DHCP, and if failing, then there is a risk of = misconfiguration. yes and no. ipv6 stack is pretty good in actively tracking if routers = are up.=20 in fact, having the default route or not does not change the basic = issue, which is, to me, a trust issue. say for example that you have two different types as you suggest: one = for more specific routes and one for default route. well, if the dhcpv6 server sends you a specific route such as 2000::/3, = it is almost a default route, and moreover, it will be preferred over = the (good,appropriate) default routes.=20 Therefore, a specific type does not help the problem. So your proposal does not help the root issue which is, to me, does the = node trust the dhcpv6 server for routes insertions. Marc. >=20 > Something that could be done about this is the use of different Types = in > DHCP (ORO) for specific routes and a different Type for default = routes. > This would mean not only that the config file owuld have different > sections for default routes vs specific routes (thus guide the = Server's > administrator to double check the default part) but also the DHCP = Client > implementation to have separate software sections for specific routes = vs > default routes. Some lighter DHCP Clients may choose to implement > _only_ the default route option part (and not the specific route = part). >=20 > With respect to this there was also a question about compliance with > specs - if a stack doesn implement eg ICMP Redirect then it's not > compliant. Do we want to ensure the same level of strength in > compliance with DHCP? Even for low end devices? >=20 > Alex >=20 > _______________________________________________ > mif mailing list > mif@ietf.org > https://www.ietf.org/mailman/listinfo/mif --Apple-Mail=_A029AF96-F446-4CC0-AE2D-21DB10C75CBE Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=iso-8859-1

When setting up routes one would like to = make sure they're right and
they lead somewhere at least most of the = time.  At the smart end node
and dumb network, there should = always exist a fallback and that fallback
is typically the default = route ("when everything else fails").

In this sense, if the end = node sets up its routes with DHCP, it would
like to be sure they're = right most of the time, otherwise use the
default route.

But = when the default route _and_ the other more specific routes = are
provided by DHCP, and if failing, then there is a risk of = misconfiguration.

yes and no. =  ipv6 stack is pretty good in actively tracking if routers are = up. 

in fact, having the default route or = not does not change the basic issue, which is, to me, a trust = issue.

say for example that you have two = different types as you suggest: one for more specific routes and one for = default route.
well, if the dhcpv6 server sends you a specific = route such as 2000::/3, it is almost a default route, and moreover, it = will be preferred over the (good,appropriate) default = routes. 
Therefore, a specific type does not help the = problem.

So your proposal does not help the = root issue which is, to me, does the node trust the dhcpv6 server for = routes = insertions.

Marc.



Something that could be done about this is = the use of different Types in
DHCP (ORO) for specific routes and a = different Type for default routes.
This would mean not only that the = config file owuld have different
sections for default routes vs = specific routes (thus guide  the Server's
administrator to = double check the default part) but also the DHCP = Client
implementation to have separate software sections for specific = routes vs
default routes.  Some lighter DHCP Clients may choose = to implement
_only_ the default route option part (and not the = specific route part).

With respect to this there was also a = question about compliance with
specs - if a stack doesn implement eg = ICMP Redirect then it's not
compliant.  Do we want to ensure the = same level of strength in
compliance with DHCP?   Even for = low end = devices?

Alex

______________________________________________= _
mif mailing list
mif@ietf.org
https://www.ietf.org/mail= man/listinfo/mif

= --Apple-Mail=_A029AF96-F446-4CC0-AE2D-21DB10C75CBE-- From alexandru.petrescu@gmail.com Tue Mar 27 05:11:07 2012 Return-Path: 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 9BBF021F89E8 for ; Tue, 27 Mar 2012 05:11:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] 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 tHjEcmq8wATQ for ; Tue, 27 Mar 2012 05:11:07 -0700 (PDT) Received: from mail-wg0-f44.google.com (mail-wg0-f44.google.com [74.125.82.44]) by ietfa.amsl.com (Postfix) with ESMTP id 8237521F8A47 for ; Tue, 27 Mar 2012 05:11:06 -0700 (PDT) Received: by wgbdr13 with SMTP id dr13so3263248wgb.13 for ; Tue, 27 Mar 2012 05:11:05 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:subject :content-type:content-transfer-encoding; bh=+lXBNXJ+4kT/dwhT5/GMWQR6f5tVDO1x4gd/yefmmUY=; b=R1qvqfxtdza/Ua53F41Ixz5KfNWUlKQgSW0kVOx1YcxDQKUtgmfuUOJZ+n7k0OmSox VLx7wdtMGj6qwE7F4xOp11rO3MMIaJwHiY1j6a+DpVLLtepql4+YoViSdIlpCQOlZwiJ XcDn0z6cp3CmwTp9ZnE//nIwtCvUtW5/WC3z1uj7Z9tsTANjBaXp/EGiLUxmzwf+H97k e9bg4NmkqDvODv9Ih/6jgfIeaqdleK/eg53Ih7SGEJ/Fp9FI31P+fVCEwFtXsCxgbE8n rmmmaEr3nzIebVZv7WdZLIb1dOvHsMOUDuicVy1L9ioko9J1UVP0xNxuDOJVGoh3SoYy fa5g== Received: by 10.180.103.35 with SMTP id ft3mr26939557wib.0.1332850265503; Tue, 27 Mar 2012 05:11:05 -0700 (PDT) Received: from [130.129.22.135] (dhcp-1687.meeting.ietf.org. [130.129.22.135]) by mx.google.com with ESMTPS id gd4sm67955526wib.6.2012.03.27.05.11.03 (version=TLSv1/SSLv3 cipher=OTHER); Tue, 27 Mar 2012 05:11:04 -0700 (PDT) Message-ID: <4F71AE51.4000304@gmail.com> Date: Tue, 27 Mar 2012 14:10:57 +0200 From: Alexandru Petrescu User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:11.0) Gecko/20120312 Thunderbird/11.0 MIME-Version: 1.0 To: mif Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: [mif] Issue: absent MAC address of default route? draft-ietf-mif-dhcpv6-route-option-04 X-BeenThere: mif@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multiple Interface Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 27 Mar 2012 12:11:07 -0000 Dear participants in MIF WG, Currently draft-ietf-mif-dhcpv6-route-option-04 specifies the DHCPv6 Server to communicate some route to the DHCPv6 Client. In the particular case of default route, the existing mechanism to achieve this is ND. This has the optional feature to communicate the MAC address of the default router at the same time. This saves on the number of messages exchanged (instead of 4 messages, only 2 are used). In the same manner, it would be useful to have DHCPv6 way of communicating the default route to add the MAC address of the IP address of the default router. This would save on the number of messages exchanged. I wanted to ask the oppinion of the WG on this particular topic, thank you. Yours, Alex From alexandru.petrescu@gmail.com Tue Mar 27 05:27:16 2012 Return-Path: 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 16DDA21F88F2 for ; Tue, 27 Mar 2012 05:27:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] 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 LDB23dp65-ca for ; Tue, 27 Mar 2012 05:27:15 -0700 (PDT) Received: from mail-we0-f172.google.com (mail-we0-f172.google.com [74.125.82.172]) by ietfa.amsl.com (Postfix) with ESMTP id 2B67121F8869 for ; Tue, 27 Mar 2012 05:27:15 -0700 (PDT) Received: by werb10 with SMTP id b10so5864147wer.31 for ; Tue, 27 Mar 2012 05:27:14 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:subject :content-type:content-transfer-encoding; bh=h0XPE0B6dQbzh++8MATCY90pzaUSROWjNIISh8hSDmQ=; b=E9DSi81WYsxZ/lqoANBolVI3PMycxS39qBOnmfqhoi1EThqr6zCCC3oSNfkGxeTcYD YBRw3xCb/XfTfvyZrMSy3rGXljvucToi0QZv7Q58uj74Y67OJKJQQgE/rr3EDkgKHsnN WOQL5ft4nE/rSdOrobMSRfxFTx8WBqMtFy/j02v4kR9pecSYCEvixJzSaQKDKL414nCb Jr8PJvCiZWGQlhCaYgM6lP769zWsFwmHDRVcHMxiIXuOubexV4uMFapps4QUXC5k0Ycn t+iOCBpudYJ5jG+fnhYDBscBx3MScZHmsIl/A6FKxNNGgzvYjU/e7EmFAn3AO81nvt6r mlKw== Received: by 10.180.88.164 with SMTP id bh4mr26970234wib.22.1332851234046; Tue, 27 Mar 2012 05:27:14 -0700 (PDT) Received: from [130.129.22.135] (dhcp-1687.meeting.ietf.org. [130.129.22.135]) by mx.google.com with ESMTPS id bx13sm49091792wib.10.2012.03.27.05.27.13 (version=TLSv1/SSLv3 cipher=OTHER); Tue, 27 Mar 2012 05:27:13 -0700 (PDT) Message-ID: <4F71B21B.3040907@gmail.com> Date: Tue, 27 Mar 2012 14:27:07 +0200 From: Alexandru Petrescu User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:11.0) Gecko/20120312 Thunderbird/11.0 MIME-Version: 1.0 To: mif Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: [mif] Issue: message size for communicating the default route? draft-ietf-mif-dhcpv6-route-option-04 X-BeenThere: mif@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multiple Interface Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 27 Mar 2012 12:27:16 -0000 Dear participants in MIF WG, Currently draft-ietf-mif-dhcpv6-route-option-04 specifies that when communicating a default route, the minimal message size (RT_PREFIX option absent) is 46 bytes (Next Hop Option 20bytes, Route Prefix Option 26bytes). Sometimes the draft says this Route Prefix Option may be absent for default routes, thus total length could be 20bytes. But it is not clear when could it be absent. Section 4.1 says "Default route is configured using RT_PREFIX option that specifies ::/0 route, included as suboption in NEXT_HOP." and section 5 says "Server MAY send a single NEXT_HOP without any RT_PREFIX suboptions or with RT_PREFIX that contains ::/0 to indicate available default route." I query opinions from the WG about this. Alex From alexandru.petrescu@gmail.com Tue Mar 27 05:31:11 2012 Return-Path: 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 A883E21F8949 for ; Tue, 27 Mar 2012 05:31:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] 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 TCdeVdjgHz-t for ; Tue, 27 Mar 2012 05:31:10 -0700 (PDT) Received: from mail-wg0-f42.google.com (mail-wg0-f42.google.com [74.125.82.42]) by ietfa.amsl.com (Postfix) with ESMTP id 71F7A21F8945 for ; Tue, 27 Mar 2012 05:31:10 -0700 (PDT) Received: by wgbds11 with SMTP id ds11so3307765wgb.1 for ; Tue, 27 Mar 2012 05:31:09 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:subject :content-type:content-transfer-encoding; bh=GWoxUCaeXYEiKOfZOgF78ZvEaMuX5ZICLsYZec3IE5M=; b=huMTnyLCAAGkfRR1CKxGdwqJdpUR2Qc+5uezalEjY5suBXUpDjzx+WIW0O4yFH78vn CVKRt1nX9VGGV7rCXoZQvw/Rbl/L4iWV7RovKDSFygCJ1yUHtvVw18VOLbp7tg76fGs8 /WhAX7OjvLh9lmPVxEa/DDG9ei5v9/YcnkP7YRajwyOBGFTRlHBuOVlDqPNEym0oAL5t a/6cHeZU9Hr3GfyRHUQoK/h5/tMYzuVwgCevgKWM5uCkvPlws2BQQxzPiESYZAehkZJu u35+8qH7Jwk5ylzF1Afj5VUQNhHkOx61AUQSruCUfsuRY4TXI7iNHV+Vmc9aROcLAfTi t1QA== Received: by 10.180.105.194 with SMTP id go2mr27212051wib.22.1332851469560; Tue, 27 Mar 2012 05:31:09 -0700 (PDT) Received: from [130.129.22.135] (dhcp-1687.meeting.ietf.org. [130.129.22.135]) by mx.google.com with ESMTPS id l5sm49125433wia.11.2012.03.27.05.31.08 (version=TLSv1/SSLv3 cipher=OTHER); Tue, 27 Mar 2012 05:31:08 -0700 (PDT) Message-ID: <4F71B306.1080509@gmail.com> Date: Tue, 27 Mar 2012 14:31:02 +0200 From: Alexandru Petrescu User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:11.0) Gecko/20120312 Thunderbird/11.0 MIME-Version: 1.0 To: mif Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: [mif] Issue: Only _one_ default route? draft-ietf-mif-dhcpv6-route-option-04 X-BeenThere: mif@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multiple Interface Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 27 Mar 2012 12:31:11 -0000 Dear participants in MIF WG, Currently draft-ietf-mif-dhcpv6-route-option-04 specifies that only one default route to be configured by the DHCPv6 Server for a particular client. draft-ietf-mif-dhcpv6-route-option-04 says: " Server MUST NOT define more than one default route." I do not know why this is so? In our implementation the DHCP Server delivers a list of default routes to the Client (draft-mouton...) Also, ND configures a list of default routes on the same link. I find it a bit bizarre that in this group's context the Server is required so strongly to configure a single default route no more. I wanted to ask the oppinion of the group about this. Alex From msa@moth.iki.fi Tue Mar 27 05:35:06 2012 Return-Path: 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 23A2F21F89DA for ; Tue, 27 Mar 2012 05:35:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] 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 2FrEmLSBiCsF for ; Tue, 27 Mar 2012 05:35:05 -0700 (PDT) Received: from moth.iki.fi (moth.iki.fi [212.16.111.74]) by ietfa.amsl.com (Postfix) with ESMTP id 24BA921F89B3 for ; Tue, 27 Mar 2012 05:35:05 -0700 (PDT) Received: from [130.188.197.233] (unknown [130.188.197.233]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: msa) by moth.iki.fi (Postfix) with ESMTPSA id 5E4DC1E581D for ; Tue, 27 Mar 2012 15:35:17 +0300 (EEST) Message-ID: <4F71B3EA.1000104@moth.iki.fi> Date: Tue, 27 Mar 2012 15:34:50 +0300 From: Markku Savela User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.2.28) Gecko/20120313 Lightning/1.0b2 Thunderbird/3.1.20 MIME-Version: 1.0 To: mif@ietf.org References: <4F71B306.1080509@gmail.com> In-Reply-To: <4F71B306.1080509@gmail.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [mif] Issue: Only _one_ default route? draft-ietf-mif-dhcpv6-route-option-04 X-BeenThere: mif@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multiple Interface Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 27 Mar 2012 12:35:06 -0000 On 03/27/2012 03:31 PM, Alexandru Petrescu wrote: > In our implementation the DHCP Server delivers a list of default routes > to the Client (draft-mouton...) Also, ND configures a list of default > routes on the same link. Is also the following configuration out of scope for this group? - a home network with TWO ISP's providing connection - both without knowledge of each other - both send default and specific route(s) (RA or DHCP) IMHO, my home desktop should really be able to handle this too (router selection needs to consider which source address was picked from which router). From alexandru.petrescu@gmail.com Tue Mar 27 05:38:31 2012 Return-Path: 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 DBFEC21E8129 for ; Tue, 27 Mar 2012 05:38:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] 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 Jqt2KYbhPA9O for ; Tue, 27 Mar 2012 05:38:31 -0700 (PDT) Received: from mail-wg0-f44.google.com (mail-wg0-f44.google.com [74.125.82.44]) by ietfa.amsl.com (Postfix) with ESMTP id 03A0221E8087 for ; Tue, 27 Mar 2012 05:38:30 -0700 (PDT) Received: by wgbdr13 with SMTP id dr13so3279001wgb.13 for ; Tue, 27 Mar 2012 05:38:30 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; bh=n91FaDq6CH33ntI3Qmkag8DzKvmxxCiOKla6BY0Mx78=; b=zYkfubb6bYP+XtvOJcXv+1W+CrseYVtKTIB+sDXIAREuCb8sWf5VIpzWSNkf0Y8Tpg TRcxk7oqHMTrGb1jYtC+x/QJ53MskJmQHtJBHZVkItYE2clkn8k2f/NGncsIhVzfOzzS 7tyLoBpGfyNe7yyPZMQ1JEZMdPFFRqI6g6xWzpsJRDGNmPk5YEbm62OpPFgrPfqLtlNi hMMhlIFPR12ODJ/YeFbndmrx0XNr3Ev9Tpy43LLmLA7ZCvPHPsLirAFNhRC4V2OTfHVn bTQ8MpMsaUNY/jGT3vN7LWlY55r4FlNv7lb/5yu7baNQ5U+kUXtyUCHWtw5V429nVwLP Tq5g== Received: by 10.180.94.33 with SMTP id cz1mr27481528wib.13.1332851910193; Tue, 27 Mar 2012 05:38:30 -0700 (PDT) Received: from [130.129.22.135] (dhcp-1687.meeting.ietf.org. [130.129.22.135]) by mx.google.com with ESMTPS id k7sm80782769wia.5.2012.03.27.05.38.29 (version=TLSv1/SSLv3 cipher=OTHER); Tue, 27 Mar 2012 05:38:29 -0700 (PDT) Message-ID: <4F71B4BF.9000303@gmail.com> Date: Tue, 27 Mar 2012 14:38:23 +0200 From: Alexandru Petrescu User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:11.0) Gecko/20120312 Thunderbird/11.0 MIME-Version: 1.0 To: Marc Blanchet References: <20120224101611.22703.52041.idtracker@ietfa.amsl.com> <4F47688B.10508@gmail.com> <4F5E2F61.9040009@gmail.com> <4F71A8D1.6000807@gmail.com> <3BA5CC86-1D2F-4DC1-8117-2C55218224BA@viagenie.ca> In-Reply-To: <3BA5CC86-1D2F-4DC1-8117-2C55218224BA@viagenie.ca> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Cc: mif@ietf.org Subject: Re: [mif] draft-ietf-mif-dhcpv6-route-option-04 published X-BeenThere: mif@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multiple Interface Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 27 Mar 2012 12:38:32 -0000 Le 27/03/2012 14:05, Marc Blanchet a écrit : > Le 2012-03-27 à 13:47, Alexandru Petrescu a écrit : >> >> When setting up routes one would like to make sure they're right >> and they lead somewhere at least most of the time. At the smart end >> node and dumb network, there should always exist a fallback and >> that fallback is typically the default route ("when everything else >> fails"). >> >> In this sense, if the end node sets up its routes with DHCP, it >> would like to be sure they're right most of the time, otherwise use >> the default route. >> >> But when the default route _and_ the other more specific routes >> are provided by DHCP, and if failing, then there is a risk of >> misconfiguration. > > yes and no. ipv6 stack is pretty good in actively tracking if routers > are up. > > in fact, having the default route or not does not change the basic > issue, which is, to me, a trust issue. > > say for example that you have two different types as you suggest: one > for more specific routes and one for default route. well, if the > dhcpv6 server sends you a specific route such as 2000::/3, it is > almost a default route, and moreover, it will be preferred over the > (good,appropriate) default routes. We could specify the specific routes part to MUST NOT send 2000::/3 as route. Would this solve that? > Therefore, a specific type does not help the problem. > > So your proposal does not help the root issue which is, to me, does > the node trust the dhcpv6 server for routes insertions. In a sense yes. But this seems to me you mention a security (trust) issue, not necessarily a misconfiguration. I think protocol specification may guide the way the dhcpd.conf is written and, if there are different types for specific routes vs default routes, then there could be different sections in that file as well, helping a bit to set aside the default routes. Alex > > Marc. > > >> >> Something that could be done about this is the use of different >> Types in DHCP (ORO) for specific routes and a different Type for >> default routes. This would mean not only that the config file owuld >> have different sections for default routes vs specific routes (thus >> guide the Server's administrator to double check the default part) >> but also the DHCP Client implementation to have separate software >> sections for specific routes vs default routes. Some lighter DHCP >> Clients may choose to implement _only_ the default route option >> part (and not the specific route part). >> >> With respect to this there was also a question about compliance >> with specs - if a stack doesn implement eg ICMP Redirect then it's >> not compliant. Do we want to ensure the same level of strength in >> compliance with DHCP? Even for low end devices? >> >> Alex >> >> _______________________________________________ mif mailing list >> mif@ietf.org >> https://www.ietf.org/mailman/listinfo/mif > From marc.blanchet@viagenie.ca Tue Mar 27 06:17:57 2012 Return-Path: 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 8854821F8798 for ; Tue, 27 Mar 2012 06:17:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.556 X-Spam-Level: X-Spam-Status: No, score=-102.556 tagged_above=-999 required=5 tests=[AWL=0.043, BAYES_00=-2.599, 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 yl7NCz5FPgYx for ; Tue, 27 Mar 2012 06:17:57 -0700 (PDT) Received: from jazz.viagenie.ca (unknown [IPv6:2620:0:230:8000:226:55ff:fe57:14db]) by ietfa.amsl.com (Postfix) with ESMTP id 0C08321F8795 for ; Tue, 27 Mar 2012 06:17:57 -0700 (PDT) Received: from dhcp-51c6.meeting.ietf.org (dhcp-51c6.meeting.ietf.org [130.129.81.198]) by jazz.viagenie.ca (Postfix) with ESMTPSA id 37618400D5; Tue, 27 Mar 2012 09:17:56 -0400 (EDT) Mime-Version: 1.0 (Apple Message framework v1257) Content-Type: text/plain; charset=windows-1252 From: Marc Blanchet In-Reply-To: <4F71B4BF.9000303@gmail.com> Date: Tue, 27 Mar 2012 15:17:53 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: References: <20120224101611.22703.52041.idtracker@ietfa.amsl.com> <4F47688B.10508@gmail.com> <4F5E2F61.9040009@gmail.com> <4F71A8D1.6000807@gmail.com> <3BA5CC86-1D2F-4DC1-8117-2C55218224BA@viagenie.ca> <4F71B4BF.9000303@gmail.com> To: Alexandru Petrescu X-Mailer: Apple Mail (2.1257) Cc: mif@ietf.org Subject: Re: [mif] draft-ietf-mif-dhcpv6-route-option-04 published X-BeenThere: mif@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multiple Interface Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 27 Mar 2012 13:17:57 -0000 Le 2012-03-27 =E0 14:38, Alexandru Petrescu a =E9crit : > Le 27/03/2012 14:05, Marc Blanchet a =E9crit : >> Le 2012-03-27 =E0 13:47, Alexandru Petrescu a =E9crit : >>>=20 >>> When setting up routes one would like to make sure they're right >>> and they lead somewhere at least most of the time. At the smart end >>> node and dumb network, there should always exist a fallback and >>> that fallback is typically the default route ("when everything else >>> fails"). >>>=20 >>> In this sense, if the end node sets up its routes with DHCP, it >>> would like to be sure they're right most of the time, otherwise use >>> the default route. >>>=20 >>> But when the default route _and_ the other more specific routes >>> are provided by DHCP, and if failing, then there is a risk of >>> misconfiguration. >>=20 >> yes and no. ipv6 stack is pretty good in actively tracking if routers >> are up. >>=20 >> in fact, having the default route or not does not change the basic >> issue, which is, to me, a trust issue. >>=20 >> say for example that you have two different types as you suggest: one >> for more specific routes and one for default route. well, if the >> dhcpv6 server sends you a specific route such as 2000::/3, it is >> almost a default route, and moreover, it will be preferred over the >> (good,appropriate) default routes. >=20 > We could specify the specific routes part to MUST NOT send 2000::/3 as > route. Would this solve that? no. what about 2000::/4, 2000::/5 =85=20 Marc. From alexandru.petrescu@gmail.com Tue Mar 27 06:32:55 2012 Return-Path: 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 CBDD721F883E for ; Tue, 27 Mar 2012 06:32:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] 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 XjriVRGHKgv4 for ; Tue, 27 Mar 2012 06:32:55 -0700 (PDT) Received: from mail-wg0-f44.google.com (mail-wg0-f44.google.com [74.125.82.44]) by ietfa.amsl.com (Postfix) with ESMTP id CFE6B21F8890 for ; Tue, 27 Mar 2012 06:32:54 -0700 (PDT) Received: by wgbdr13 with SMTP id dr13so3313219wgb.13 for ; Tue, 27 Mar 2012 06:32:54 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; bh=ByJscnaSPdso2ovaABBnjIkhDgJl5oO3YfQwiAfLw9g=; b=xjWwsTuqYo54iSd/g/h5qcT6CTJV9hsEOM+EmFhf1/WzkeaFHPS7kgepY4GanjcYop hE/w6mvXnYL8uLPyGJwb3Ugogl+xUueLhoEag/q6KVHhWx7j2zvD4AfCKHWP8QPbNk+/ EpHRUMtmd31FpXXQPeotfExBYXS9wSnF4VBKRNTeMv2XR1MDIQ9UaFY/qGcGdb9Ozb/6 7xzZWeaksV/m1nc/ZIKzYmjp4TRhKCEgc8484UfAZdJ5QHs7nP4fufhwNL5BJ9cFX2j2 7MmTX766fEjxzDyqp8YBbOXpApqUl3I9So7pU2deiwqr2Mg/HNR19biHWE61uS0wzXUK 5bGg== Received: by 10.180.102.101 with SMTP id fn5mr27652032wib.6.1332855174064; Tue, 27 Mar 2012 06:32:54 -0700 (PDT) Received: from [130.129.22.135] (dhcp-1687.meeting.ietf.org. [130.129.22.135]) by mx.google.com with ESMTPS id k6sm49486407wie.9.2012.03.27.06.32.52 (version=TLSv1/SSLv3 cipher=OTHER); Tue, 27 Mar 2012 06:32:53 -0700 (PDT) Message-ID: <4F71C17F.1060702@gmail.com> Date: Tue, 27 Mar 2012 15:32:47 +0200 From: Alexandru Petrescu User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:11.0) Gecko/20120312 Thunderbird/11.0 MIME-Version: 1.0 To: Marc Blanchet References: <20120224101611.22703.52041.idtracker@ietfa.amsl.com> <4F47688B.10508@gmail.com> <4F5E2F61.9040009@gmail.com> <4F71A8D1.6000807@gmail.com> <3BA5CC86-1D2F-4DC1-8117-2C55218224BA@viagenie.ca> <4F71B4BF.9000303@gmail.com> In-Reply-To: Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit Cc: mif@ietf.org Subject: Re: [mif] draft-ietf-mif-dhcpv6-route-option-04 published X-BeenThere: mif@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multiple Interface Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 27 Mar 2012 13:32:55 -0000 Le 27/03/2012 15:17, Marc Blanchet a écrit : > > Le 2012-03-27 à 14:38, Alexandru Petrescu a écrit : > >> Le 27/03/2012 14:05, Marc Blanchet a écrit : >>> Le 2012-03-27 à 13:47, Alexandru Petrescu a écrit : >>>> >>>> When setting up routes one would like to make sure they're >>>> right and they lead somewhere at least most of the time. At the >>>> smart end node and dumb network, there should always exist a >>>> fallback and that fallback is typically the default route >>>> ("when everything else fails"). >>>> >>>> In this sense, if the end node sets up its routes with DHCP, >>>> it would like to be sure they're right most of the time, >>>> otherwise use the default route. >>>> >>>> But when the default route _and_ the other more specific >>>> routes are provided by DHCP, and if failing, then there is a >>>> risk of misconfiguration. >>> >>> yes and no. ipv6 stack is pretty good in actively tracking if >>> routers are up. >>> >>> in fact, having the default route or not does not change the >>> basic issue, which is, to me, a trust issue. >>> >>> say for example that you have two different types as you suggest: >>> one for more specific routes and one for default route. well, if >>> the dhcpv6 server sends you a specific route such as 2000::/3, it >>> is almost a default route, and moreover, it will be preferred >>> over the (good,appropriate) default routes. >> >> We could specify the specific routes part to MUST NOT send 2000::/3 >> as route. Would this solve that? > > no. what about 2000::/4, 2000::/5 … Well, one one hand there should exist a means to write English about 4, 5 ... 128 prefix lengths. On another hand, the RFCs say that only ::/0 is a default route, so we may care more about this. No? Alex > > Marc. > > From ek@google.com Tue Mar 27 06:45:29 2012 Return-Path: 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 E3C4C21E8089 for ; Tue, 27 Mar 2012 06:45:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.777 X-Spam-Level: X-Spam-Status: No, score=-102.777 tagged_above=-999 required=5 tests=[AWL=0.200, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1, 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 UDlvXBWFPe8Z for ; Tue, 27 Mar 2012 06:45:23 -0700 (PDT) Received: from mail-qa0-f51.google.com (mail-qa0-f51.google.com [209.85.216.51]) by ietfa.amsl.com (Postfix) with ESMTP id 1569621E8090 for ; Tue, 27 Mar 2012 06:45:22 -0700 (PDT) Received: by qaea16 with SMTP id a16so129624qae.10 for ; Tue, 27 Mar 2012 06:45:22 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:x-system-of-record; bh=I95VBxun68VJyDhXsaen+fjBu6X1cGz8wLskvx0aVUI=; b=GLY0ZhMSb6s1kDybDBCAimsugBtoVKynN2XcLeLfUyhO1xIzOaGcN33VXhpIG+7T5g /7pKMTLZmmQITEoXoZrWp5rc12589f6P+8urOPcn87R4Ds+msam3An/09kIpwfJWKlj1 iMrA2vCmBr4KW4H8NII5sUM0LYKajt54CGUiokDg584xlsX9L/iLwj/Xf8EBtkIXm92G YoUYTw3t7RBDDCnfFxPjZYWNH2Ueqh+M9RE/zP2YacIKlxiXTcDNoRWRByu8rtV5bW68 galwT0qaOwgOHHagaVtyR2ZWqrqohuC+MKhYkd4/Cypv2pqxDo9Ora6bznlhFLDKd0X6 qZZg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:x-system-of-record:x-gm-message-state; bh=I95VBxun68VJyDhXsaen+fjBu6X1cGz8wLskvx0aVUI=; b=Cwj1vnEvsK5cpoSyMe/rlhRYXdFotzLlxx4fUIP6Gjmrt6URGeVQubauwKQ0zheL6W //yf+EsB84MNXR6nsGhO0zYTcveqyMGM6sm31mS5DyvmmmBAUoP0BXsDkbWhWlOWK7aZ rr65nOR7E40OYq6ssllbbq1522GTm0HoKjuwr3IHudjNZz9Orgh9yAFoJ0cn4pjTd5iG ccz+NQgpWb7fkB5N71c8c+Xg//BWulVK2B6QdVd8txz9FeKzS6TedeeeJSvuUEm8JAxX PQ9o/3eFuGsqUIW6szdoWQ3+w8Rdf9uP3OhvoS+RdKiQGUGY/LvrhIpNxAc0O7R/UN4a g67Q== Received: by 10.224.202.193 with SMTP id ff1mr32909921qab.36.1332855922533; Tue, 27 Mar 2012 06:45:22 -0700 (PDT) MIME-Version: 1.0 Received: by 10.224.202.193 with SMTP id ff1mr32909905qab.36.1332855922417; Tue, 27 Mar 2012 06:45:22 -0700 (PDT) Received: by 10.229.128.170 with HTTP; Tue, 27 Mar 2012 06:45:22 -0700 (PDT) In-Reply-To: <4F71B3EA.1000104@moth.iki.fi> References: <4F71B306.1080509@gmail.com> <4F71B3EA.1000104@moth.iki.fi> Date: Tue, 27 Mar 2012 13:45:22 +0000 Message-ID: From: Erik Kline To: Markku Savela Content-Type: text/plain; charset=UTF-8 X-System-Of-Record: true X-Gm-Message-State: ALoCoQmW6xBuOB9Zgr1UFdIzIDeoYC3Yz59yg+iUbIokFD4U41xWEJQZ/eDfncPJgTHmXqwL2+LXuTO9ptFsyzOPPG0Pgo7Yib5gUAM/nS6mxaQ8RPBbGQY41IdLCNmoxPf5+syrcDJy Cc: mif@ietf.org Subject: Re: [mif] Issue: Only _one_ default route? draft-ietf-mif-dhcpv6-route-option-04 X-BeenThere: mif@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multiple Interface Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 27 Mar 2012 13:45:30 -0000 > IMHO, my home desktop should really be able to handle > this too (router selection needs to consider which source > address was picked from which router). I think this is some of the stuff that 6man has been discussing. From alexandru.petrescu@gmail.com Tue Mar 27 06:50:48 2012 Return-Path: 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 BCF6121F89F7 for ; Tue, 27 Mar 2012 06:50:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] 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 hRLhReWcNFbE for ; Tue, 27 Mar 2012 06:50:48 -0700 (PDT) Received: from mail-wi0-f170.google.com (mail-wi0-f170.google.com [209.85.212.170]) by ietfa.amsl.com (Postfix) with ESMTP id 3AA6C21F890F for ; Tue, 27 Mar 2012 06:50:47 -0700 (PDT) Received: by wibhr17 with SMTP id hr17so4747719wib.1 for ; Tue, 27 Mar 2012 06:50:46 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:subject:references :in-reply-to:content-type:content-transfer-encoding; bh=sYKlPuj1DofTQEe7cOCeU+L4r5ScTSJ6iyKWlTwDG4A=; b=e+A7YCqR/NHQly/2c7u0/hMp6innSHb39rYzRYuH6XDP2nHHeexlDy7ARNXIPVebDV otCd+9n/yt4HWiCPN+me4up6CmeSvuhQ4rB+q/o+uzwK8RsiI4g0j9nEETj56W7s1Bo1 jh9mQ6KY10cgfq5oDDH/jMW7rVJnxJEwwXkmvFPLk3XVpx3mJZ2b3lXO9QBNjRIK3xqt SGNONhXhqx21MwVOspsihgvBHlhKO5anDkP92hX42HKMeue94uN0TK/NTqYKEhHR8UjN 2E/GfVYDGFBPVI6wguuaau6Y7A/kOXQ+SQKDMqhtm4gQbmQvd7dTRe8BCCY0qvsg1YFS V5vg== Received: by 10.180.107.164 with SMTP id hd4mr27638693wib.18.1332856246240; Tue, 27 Mar 2012 06:50:46 -0700 (PDT) Received: from [130.129.22.135] (dhcp-1687.meeting.ietf.org. [130.129.22.135]) by mx.google.com with ESMTPS id 17sm50521465wis.0.2012.03.27.06.50.44 (version=TLSv1/SSLv3 cipher=OTHER); Tue, 27 Mar 2012 06:50:45 -0700 (PDT) Message-ID: <4F71C5AE.8010305@gmail.com> Date: Tue, 27 Mar 2012 15:50:38 +0200 From: Alexandru Petrescu User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:11.0) Gecko/20120312 Thunderbird/11.0 MIME-Version: 1.0 To: mif@ietf.org References: <4F71B306.1080509@gmail.com> <4F71B3EA.1000104@moth.iki.fi> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Subject: Re: [mif] Issue: Only _one_ default route? draft-ietf-mif-dhcpv6-route-option-04 X-BeenThere: mif@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multiple Interface Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 27 Mar 2012 13:50:48 -0000 Le 27/03/2012 15:45, Erik Kline a écrit : >> IMHO, my home desktop should really be able to handle >> this too (router selection needs to consider which source >> address was picked from which router). > > I think this is some of the stuff that 6man has been discussing. Do you think that discussion may have concluded that it's not good to have several default routes on the Client? Alex > _______________________________________________ > mif mailing list > mif@ietf.org > https://www.ietf.org/mailman/listinfo/mif From ek@google.com Tue Mar 27 07:04:33 2012 Return-Path: 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 DC28D21E8207 for ; Tue, 27 Mar 2012 07:04:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.806 X-Spam-Level: X-Spam-Status: No, score=-102.806 tagged_above=-999 required=5 tests=[AWL=0.171, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1, 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 1bFLt81qoN9P for ; Tue, 27 Mar 2012 07:04:33 -0700 (PDT) Received: from mail-qa0-f43.google.com (mail-qa0-f43.google.com [209.85.216.43]) by ietfa.amsl.com (Postfix) with ESMTP id 5560721E81DA for ; Tue, 27 Mar 2012 07:04:33 -0700 (PDT) Received: by qadb15 with SMTP id b15so3879853qad.16 for ; Tue, 27 Mar 2012 07:04:32 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding:x-system-of-record; bh=pZ8pEWfdBkhKsh6ipmpNXZwgsxa3swMZvwUE0HWVPi8=; b=GIlIOJn2j0b8Kd4odLHyB8syQwi4IHnIKG4hYTYY0M9gV8BujUV9yx2NstX/lDtcat /UJ/1XRMX+CovgWWYwmxXSn+mVXLJg11arHkk6er5d/MfbrOpTG8LWMtOGrbziUTKutM 7Crm7lrpRrkCwtORiFhtfGQQWwCR1eO2p1g3Ez7fAC5N5lxXvs4osaFc0yX2D1ueYbx0 03wE8yBPiQviFvg6wbpVdLCr6J/L5zepzbkJhhrvunEMQpsFe6UsoUgtgP5tLl+k+xDA EWYqPaKjFCld8FQbf0aCxVPhoi2GfUpitTeyZF+g5e1wofISdgbGLPo8tBLBt/3YrAwh T3pQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding:x-system-of-record :x-gm-message-state; bh=pZ8pEWfdBkhKsh6ipmpNXZwgsxa3swMZvwUE0HWVPi8=; b=J/IhcyTeoTGhS7JZQJGbZErmmgx55SmOBKtWF6MobZBSnGzIhw+9kz9YBB34uY39Sp Lr6WaOn8GV+CRamSaciy1nfqF6S+5pMR9Ckvr6oggDqCZ9dLNUlCLnX960vDWaO6ZBTW OpXsbnFT81LixMqKmZWt238PTSvQx4JSYo6/6ZGnhXJKvTT/YB5K6az9N7to1eljK3Qb 991f5ilnjw26pP6Z/5w662GiM8pX8u9UkXSq3Sp8EcdB64bQGEQEn8cOdmBMq0uyZk76 ZYjefsCJKyiqawtrMa4S60uokVZ0qhrLN14elyKZPDrqJKN+vf5BM7dqCAXpSsi+yBq8 VBQg== Received: by 10.224.33.9 with SMTP id f9mr3174565qad.49.1332857068606; Tue, 27 Mar 2012 07:04:28 -0700 (PDT) MIME-Version: 1.0 Received: by 10.224.33.9 with SMTP id f9mr3174154qad.49.1332857064047; Tue, 27 Mar 2012 07:04:24 -0700 (PDT) Received: by 10.229.128.170 with HTTP; Tue, 27 Mar 2012 07:04:24 -0700 (PDT) In-Reply-To: <4F71C5AE.8010305@gmail.com> References: <4F71B306.1080509@gmail.com> <4F71B3EA.1000104@moth.iki.fi> <4F71C5AE.8010305@gmail.com> Date: Tue, 27 Mar 2012 14:04:24 +0000 Message-ID: From: Erik Kline To: Alexandru Petrescu Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-System-Of-Record: true X-Gm-Message-State: ALoCoQnDGh2WFvKT8U2wPxMhn0G7FwpBW7ziXZU1r5orBpipw4YpD4dczWeEq7UYxvtlM3r+HtjyQTUuHh4a0/8pVTGFKtDAj4KoPB7Fp6UHToC0G85RVaEOXGx7qiipnk7YOvW65pcc Cc: mif@ietf.org Subject: Re: [mif] Issue: Only _one_ default route? draft-ietf-mif-dhcpv6-route-option-04 X-BeenThere: mif@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multiple Interface Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 27 Mar 2012 14:04:34 -0000 On 27 March 2012 13:50, Alexandru Petrescu w= rote: > Le 27/03/2012 15:45, Erik Kline a =C3=A9crit : > >>> IMHO, my home desktop should really be able to handle >>> this too (router selection needs to consider which source >>> address was picked from which router). >> >> >> I think this is some of the stuff that 6man has been discussing. > > > Do you think that discussion may have concluded that it's not good to hav= e > several default routes on the Client? The discussion I'm referring to is about updating the source address selection depending on the next hop. This is obviously a more complicated issue overall, of course. Unless you get it right, you're likely to run afoul of BCP38. From alexandru.petrescu@gmail.com Tue Mar 27 07:14:26 2012 Return-Path: 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 C237321F8819 for ; Tue, 27 Mar 2012 07:14:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] 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 V9DCDd4KY7jp for ; Tue, 27 Mar 2012 07:14:26 -0700 (PDT) Received: from mail-wi0-f178.google.com (mail-wi0-f178.google.com [209.85.212.178]) by ietfa.amsl.com (Postfix) with ESMTP id B8F3F21F87C7 for ; Tue, 27 Mar 2012 07:14:25 -0700 (PDT) Received: by wibhq7 with SMTP id hq7so4496060wib.13 for ; Tue, 27 Mar 2012 07:14:25 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; bh=sd9zgmTYJ7gto5ukZcG8hrrB7FLYpRtlOluzbp7V5P4=; b=adocLfD2rePBEZ8SLBBPSr33HcduD/qASojBMgFcq+wpywJpo7ZQQ9ZGp3gYXO0F/m 82sEhuJu/fdMeDTOj1NvUwZGKxvKqEtP+xm4QwZ9qsrcndzIZDdNQqV7klVsqaA/Nt7O DsXO9clofxt2LF017PWZaCXRQXT5Mb9+3zkfvTLxY/KKeSDwAKmruIy4CSMXOgtXKvwb yUl3ddFoAWRpdh71V+R3rtieG9WOCDxK/uYIRBHERZsKR+t1OabtKsJUiAo1/qVcnDch QZxypaCbMJJMWjx34VUGe9obyFc0HZq3iPS6VL5QWQSNpccGse1rmf91HGU3dLhkep8A UOqw== Received: by 10.180.94.161 with SMTP id dd1mr3095065wib.16.1332857664896; Tue, 27 Mar 2012 07:14:24 -0700 (PDT) Received: from [130.129.22.135] (dhcp-1687.meeting.ietf.org. [130.129.22.135]) by mx.google.com with ESMTPS id fn2sm81763573wib.0.2012.03.27.07.14.23 (version=TLSv1/SSLv3 cipher=OTHER); Tue, 27 Mar 2012 07:14:24 -0700 (PDT) Message-ID: <4F71CB39.4030707@gmail.com> Date: Tue, 27 Mar 2012 16:14:17 +0200 From: Alexandru Petrescu User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:11.0) Gecko/20120312 Thunderbird/11.0 MIME-Version: 1.0 To: Erik Kline References: <4F71B306.1080509@gmail.com> <4F71B3EA.1000104@moth.iki.fi> <4F71C5AE.8010305@gmail.com> In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Cc: mif@ietf.org Subject: Re: [mif] Issue: Only _one_ default route? draft-ietf-mif-dhcpv6-route-option-04 X-BeenThere: mif@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multiple Interface Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 27 Mar 2012 14:14:26 -0000 Le 27/03/2012 16:04, Erik Kline a écrit : > On 27 March 2012 13:50, Alexandru > Petrescu wrote: >> Le 27/03/2012 15:45, Erik Kline a écrit : >> >>>> IMHO, my home desktop should really be able to handle this too >>>> (router selection needs to consider which source address was >>>> picked from which router). >>> >>> >>> I think this is some of the stuff that 6man has been discussing. >> >> >> Do you think that discussion may have concluded that it's not good >> to have several default routes on the Client? > > The discussion I'm referring to is about updating the source address > selection depending on the next hop. This is obviously a more > complicated issue overall, of course. Unless you get it right, > you're likely to run afoul of BCP38. I see. One wouldn't appreciate be subject to Ingress Filtering. As a sidenote, also there exist solutions in the 6man space about selecting the source address and even about selecting a route if there are two similar in the routing table. RFC3484 comes to mind, which shows a policy table where the routes have "precedence" fields. This means two default routes could be present in the routing table, have a different preference, and be selected according to some policy keyed by this preference value. In Neighbor Discovery also exist distinctors to choose among several default routes present in the Client. Alex From Ted.Lemon@nominum.com Tue Mar 27 08:26:48 2012 Return-Path: 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 84A6E21E80AA for ; Tue, 27 Mar 2012 08:26:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.461 X-Spam-Level: X-Spam-Status: No, score=-106.461 tagged_above=-999 required=5 tests=[AWL=0.138, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, 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 k8l4U96U7VZu for ; Tue, 27 Mar 2012 08:26:47 -0700 (PDT) Received: from exprod7og112.obsmtp.com (exprod7og112.obsmtp.com [64.18.2.177]) by ietfa.amsl.com (Postfix) with ESMTP id 29F9021E80A8 for ; Tue, 27 Mar 2012 08:26:47 -0700 (PDT) Received: from shell-too.nominum.com ([64.89.228.229]) (using TLSv1) by exprod7ob112.postini.com ([64.18.6.12]) with SMTP ID DSNKT3HcNmcGcVP1mXx/qk0zSIAI7mFpbVFk@postini.com; Tue, 27 Mar 2012 08:26:47 PDT Received: from archivist.nominum.com (archivist.nominum.com [64.89.228.108]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "*.nominum.com", Issuer "Go Daddy Secure Certification Authority" (verified OK)) by shell-too.nominum.com (Postfix) with ESMTP id 397E71B8184 for ; Tue, 27 Mar 2012 08:26:46 -0700 (PDT) Received: from webmail.nominum.com (cas-01.win.nominum.com [64.89.228.131]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (Client CN "mail.nominum.com", Issuer "Go Daddy Secure Certification Authority" (verified OK)) by archivist.nominum.com (Postfix) with ESMTPS id 328A1190068; Tue, 27 Mar 2012 08:26:46 -0700 (PDT) (envelope-from Ted.Lemon@nominum.com) Received: from MBX-02.WIN.NOMINUM.COM ([64.89.228.134]) by CAS-01.WIN.NOMINUM.COM ([64.89.228.131]) with mapi id 14.02.0247.003; Tue, 27 Mar 2012 08:26:46 -0700 From: Ted Lemon To: Markku Savela , "mif@ietf.org" Thread-Topic: [mif] Issue: Only _one_ default route? draft-ietf-mif-dhcpv6-route-option-04 Thread-Index: AQHNDBYNGjzYaz/6f0qHd6RYNzzkPpZ+Q41k Date: Tue, 27 Mar 2012 15:26:45 +0000 Message-ID: <8D23D4052ABE7A4490E77B1A012B6307472C3E95@mbx-02.win.nominum.com> References: <4F71B306.1080509@gmail.com>,<4F71B3EA.1000104@moth.iki.fi> In-Reply-To: <4F71B3EA.1000104@moth.iki.fi> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [192.168.1.10] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [mif] Issue: Only _one_ default route? draft-ietf-mif-dhcpv6-route-option-04 X-BeenThere: mif@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multiple Interface Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 27 Mar 2012 15:26:48 -0000 > Is also the following configuration out of scope for this group? > - a home network with TWO ISP's providing connection > - both without knowledge of each other > - both send default and specific route(s) (RA or DHCP) > IMHO, my home desktop should really be able to handle > this too (router selection needs to consider which source > address was picked from which router). Yes, this seems to be in scope to me. I think you should submit a draft, = since you've described both the problem and the solution quite well. You = are describing the "two provisioning domains" scenario, FWIW.= From ek@google.com Tue Mar 27 08:30:03 2012 Return-Path: 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 D667821E80A6 for ; Tue, 27 Mar 2012 08:30:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.827 X-Spam-Level: X-Spam-Status: No, score=-102.827 tagged_above=-999 required=5 tests=[AWL=0.150, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1, 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 YG9FAaJXuk4q for ; Tue, 27 Mar 2012 08:30:03 -0700 (PDT) Received: from mail-qa0-f51.google.com (mail-qa0-f51.google.com [209.85.216.51]) by ietfa.amsl.com (Postfix) with ESMTP id 3675E21E8083 for ; Tue, 27 Mar 2012 08:30:03 -0700 (PDT) Received: by qaea16 with SMTP id a16so210484qae.10 for ; Tue, 27 Mar 2012 08:30:02 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding:x-system-of-record; bh=pQUrXhSlhxRG7msuoh0UiiMk7peVOpndZDNJbfFM68w=; b=l+1bZPLjv0uIZG1LjZMAogcqdNhmXGCbRc/twqfycsK7VTmSOiAsya1K6fgrXGLa7t S7WMZCk9crfYCbt3khx6zM0EXy39C2/1xqKQN9up8SxnfMQGGKMPqeO6mMJzTQieYm+y 318QkuFANlEta9RyoDkj7lcSMa80NmFBrmnYH2aiaGO4DRjrp5f+q69GO/VPj8h2gNEk ZK8aQKFK4e61tAbY3yI+H1WHW1CnlTNt6jT/RSKAwRY+ca7iOC6KFBpiF8Vt4aC9jWv+ q1ZVnmOHP+xxwj5K2oTqgX9Bsu9kE0Q2tDr9yzaGJYnAe7XSOCp4s8mlgE/gV2UKl8rF x/ZQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding:x-system-of-record :x-gm-message-state; bh=pQUrXhSlhxRG7msuoh0UiiMk7peVOpndZDNJbfFM68w=; b=dzS6zJyYhNW7h3bruvQ0kULCHI1nmKJW2tocthRLV11oSOnskw9MfuQSOPExD58Qq+ 2mQ+V+FcnFszdPTGPc1BGGZIkkv6ikqIAJUMf8TC6SEODoFjsh+wiMaJSy+2X4KqExm8 QcMOLIzOETuhI64qQZ2r3YEazhxdBXsxOswgEg07vDGyGLzyGGotb7myHe2fDai709Ew NT0emKY0fxdjTvSbM74L7OjRnAN8zI23DfrBNAGvCs5a+CQ6vI2pNmq/0wfzp9luA+Py 6cy+SDHd118cUNmsFXfJw1SKwxuVhUrzFmUyXX4k0Kk6NtKLSQIocx5pTSi5BQnIUBsF bZ2g== Received: by 10.224.106.131 with SMTP id x3mr33211245qao.23.1332862202093; Tue, 27 Mar 2012 08:30:02 -0700 (PDT) MIME-Version: 1.0 Received: by 10.224.106.131 with SMTP id x3mr33211222qao.23.1332862201852; Tue, 27 Mar 2012 08:30:01 -0700 (PDT) Received: by 10.229.128.170 with HTTP; Tue, 27 Mar 2012 08:30:01 -0700 (PDT) In-Reply-To: <8D23D4052ABE7A4490E77B1A012B6307472C3E95@mbx-02.win.nominum.com> References: <4F71B306.1080509@gmail.com> <4F71B3EA.1000104@moth.iki.fi> <8D23D4052ABE7A4490E77B1A012B6307472C3E95@mbx-02.win.nominum.com> Date: Tue, 27 Mar 2012 15:30:01 +0000 Message-ID: From: Erik Kline To: Ted Lemon Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-System-Of-Record: true X-Gm-Message-State: ALoCoQnyq6TabliYoVJrud3F0hnW1TN2oVU4IwD6LVD3ocD0yilW7tRINBDUrxTc808Oo9CAr/GW2oRMaBCq71zEXRDe+rcaYr0H3Of9rc2/an2c4PKl5rgqyi9NTix+18ch4eVgTUb3 Cc: "mif@ietf.org" Subject: Re: [mif] Issue: Only _one_ default route? draft-ietf-mif-dhcpv6-route-option-04 X-BeenThere: mif@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multiple Interface Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 27 Mar 2012 15:30:03 -0000 On 27 March 2012 15:26, Ted Lemon wrote: >> Is also the following configuration out of scope for this group? > >> - a home network with TWO ISP's providing connection >> - both without knowledge of each other >> - both send default and specific route(s) (RA or DHCP) > >> IMHO, my home desktop should really be able to handle >> this too (router selection needs to consider which source >> address was picked from which router). > > Yes, this seems to be in scope to me. =C2=A0 I think you should submit a = draft, since you've described both the problem and the solution quite well.= =C2=A0 You are describing the "two provisioning domains" scenario, FWIW. Submit to 6man, I think. From Ted.Lemon@nominum.com Tue Mar 27 08:31:20 2012 Return-Path: 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 96D7821E813C for ; Tue, 27 Mar 2012 08:31:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.463 X-Spam-Level: X-Spam-Status: No, score=-106.463 tagged_above=-999 required=5 tests=[AWL=0.136, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, 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 mTdgKAXnTCJQ for ; Tue, 27 Mar 2012 08:31:20 -0700 (PDT) Received: from exprod7og110.obsmtp.com (exprod7og110.obsmtp.com [64.18.2.173]) by ietfa.amsl.com (Postfix) with ESMTP id 17AF321E8154 for ; Tue, 27 Mar 2012 08:31:10 -0700 (PDT) Received: from shell-too.nominum.com ([64.89.228.229]) (using TLSv1) by exprod7ob110.postini.com ([64.18.6.12]) with SMTP ID DSNKT3HdPTJmUVzgADZiXBGCNt7xmUbN2uTy@postini.com; Tue, 27 Mar 2012 08:31:10 PDT Received: from archivist.nominum.com (archivist.nominum.com [64.89.228.108]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "*.nominum.com", Issuer "Go Daddy Secure Certification Authority" (verified OK)) by shell-too.nominum.com (Postfix) with ESMTP id 4BC211B81E4 for ; Tue, 27 Mar 2012 08:31:09 -0700 (PDT) Received: from webmail.nominum.com (cas-01.win.nominum.com [64.89.228.131]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (Client CN "mail.nominum.com", Issuer "Go Daddy Secure Certification Authority" (verified OK)) by archivist.nominum.com (Postfix) with ESMTPS id 427FB190068; Tue, 27 Mar 2012 08:31:09 -0700 (PDT) (envelope-from Ted.Lemon@nominum.com) Received: from MBX-02.WIN.NOMINUM.COM ([64.89.228.134]) by CAS-01.WIN.NOMINUM.COM ([64.89.228.131]) with mapi id 14.02.0247.003; Tue, 27 Mar 2012 08:31:02 -0700 From: Ted Lemon To: Alexandru Petrescu , mif Thread-Topic: [mif] Issue: absent MAC address of default route? draft-ietf-mif-dhcpv6-route-option-04 Thread-Index: AQHNDBK+VVkeArEaFUu2CcFo2QwYmZZ+RKx0 Date: Tue, 27 Mar 2012 15:31:02 +0000 Message-ID: <8D23D4052ABE7A4490E77B1A012B6307472C3EB0@mbx-02.win.nominum.com> References: <4F71AE51.4000304@gmail.com> In-Reply-To: <4F71AE51.4000304@gmail.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [192.168.1.10] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [mif] Issue: absent MAC address of default route? draft-ietf-mif-dhcpv6-route-option-04 X-BeenThere: mif@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multiple Interface Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 27 Mar 2012 15:31:20 -0000 > In the particular case of default route, the existing mechanism to > achieve this is ND. This has the optional feature to communicate the > MAC address of the default router at the same time. This saves on the > number of messages exchanged (instead of 4 messages, only 2 are used). In environments where this is a significant amount of additional traffic, p= resumably ND will be the preferred mechanism for delivering the default rou= te. > In the same manner, it would be useful to have DHCPv6 way of > communicating the default route to add the MAC address of the IP address > of the default router. This would save on the number of messages exchang= ed. I think this is an unnecessary optimization. What's the use case where bo= th ND is not preferred, and bandwidth is so constrained as to make this a p= roblem? From Ted.Lemon@nominum.com Tue Mar 27 08:33:08 2012 Return-Path: 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 F275621E815C for ; Tue, 27 Mar 2012 08:33:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.465 X-Spam-Level: X-Spam-Status: No, score=-106.465 tagged_above=-999 required=5 tests=[AWL=0.134, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, 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 vq4xbrwLm9Td for ; Tue, 27 Mar 2012 08:33:06 -0700 (PDT) Received: from exprod7og122.obsmtp.com (exprod7og122.obsmtp.com [64.18.2.22]) by ietfa.amsl.com (Postfix) with ESMTP id 874BB21E8157 for ; Tue, 27 Mar 2012 08:33:05 -0700 (PDT) Received: from shell-too.nominum.com ([64.89.228.229]) (using TLSv1) by exprod7ob122.postini.com ([64.18.6.12]) with SMTP ID DSNKT3HdsZQWHW0ngTF91GclYbhhdNlByGiB@postini.com; Tue, 27 Mar 2012 08:33:05 PDT Received: from archivist.nominum.com (archivist.nominum.com [64.89.228.108]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "*.nominum.com", Issuer "Go Daddy Secure Certification Authority" (verified OK)) by shell-too.nominum.com (Postfix) with ESMTP id 864351B81D2 for ; Tue, 27 Mar 2012 08:33:04 -0700 (PDT) Received: from webmail.nominum.com (cas-01.win.nominum.com [64.89.228.131]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (Client CN "mail.nominum.com", Issuer "Go Daddy Secure Certification Authority" (verified OK)) by archivist.nominum.com (Postfix) with ESMTPS id 7F6A7190068; Tue, 27 Mar 2012 08:33:04 -0700 (PDT) (envelope-from Ted.Lemon@nominum.com) Received: from MBX-02.WIN.NOMINUM.COM ([64.89.228.134]) by CAS-01.WIN.NOMINUM.COM ([64.89.228.131]) with mapi id 14.02.0247.003; Tue, 27 Mar 2012 08:33:04 -0700 From: Ted Lemon To: Erik Kline Thread-Topic: [mif] Issue: Only _one_ default route? draft-ietf-mif-dhcpv6-route-option-04 Thread-Index: AQHNDC58Rpt4q+v4zE+K4i5+0ayRlJZ+RPfg Date: Tue, 27 Mar 2012 15:33:03 +0000 Message-ID: <8D23D4052ABE7A4490E77B1A012B6307472C3EC0@mbx-02.win.nominum.com> References: <4F71B306.1080509@gmail.com> <4F71B3EA.1000104@moth.iki.fi> <8D23D4052ABE7A4490E77B1A012B6307472C3E95@mbx-02.win.nominum.com>, In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [192.168.1.10] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "mif@ietf.org" Subject: Re: [mif] Issue: Only _one_ default route? draft-ietf-mif-dhcpv6-route-option-04 X-BeenThere: mif@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multiple Interface Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 27 Mar 2012 15:33:08 -0000 > Submit to 6man, I think. Thanks for telling us your opinion, Erik. Is there a reason behind the op= inion, or did it just spring into your mind like a tiny, perfect flower? :) From Ted.Lemon@nominum.com Tue Mar 27 08:37:38 2012 Return-Path: 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 36B1721E81FD for ; Tue, 27 Mar 2012 08:37:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.467 X-Spam-Level: X-Spam-Status: No, score=-106.467 tagged_above=-999 required=5 tests=[AWL=0.132, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, 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 PnsMbWg1ONUg for ; Tue, 27 Mar 2012 08:37:37 -0700 (PDT) Received: from exprod7og118.obsmtp.com (exprod7og118.obsmtp.com [64.18.2.8]) by ietfa.amsl.com (Postfix) with ESMTP id C8B5721E808F for ; Tue, 27 Mar 2012 08:37:35 -0700 (PDT) Received: from shell-too.nominum.com ([64.89.228.229]) (using TLSv1) by exprod7ob118.postini.com ([64.18.6.12]) with SMTP ID DSNKT3Hev3NghQhll4a8ltJGvJqOYlM1Degl@postini.com; Tue, 27 Mar 2012 08:37:35 PDT Received: from archivist.nominum.com (archivist.nominum.com [64.89.228.108]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "*.nominum.com", Issuer "Go Daddy Secure Certification Authority" (verified OK)) by shell-too.nominum.com (Postfix) with ESMTP id 577561B81E4 for ; Tue, 27 Mar 2012 08:37:34 -0700 (PDT) Received: from webmail.nominum.com (cas-01.win.nominum.com [64.89.228.131]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (Client CN "mail.nominum.com", Issuer "Go Daddy Secure Certification Authority" (verified OK)) by archivist.nominum.com (Postfix) with ESMTPS id 4C793190068; Tue, 27 Mar 2012 08:37:34 -0700 (PDT) (envelope-from Ted.Lemon@nominum.com) Received: from MBX-02.WIN.NOMINUM.COM ([64.89.228.134]) by CAS-01.WIN.NOMINUM.COM ([64.89.228.131]) with mapi id 14.02.0247.003; Tue, 27 Mar 2012 08:37:34 -0700 From: Ted Lemon To: Alexandru Petrescu , mif Thread-Topic: [mif] Issue: lifetime 32bit or 16bit ? draft-ietf-mif-dhcpv6-route-option-04 Thread-Index: AQHNDBFvH6Y760UXmEmmm2HylRC7z5Z+Rm9g Date: Tue, 27 Mar 2012 15:37:33 +0000 Message-ID: <8D23D4052ABE7A4490E77B1A012B6307472C3EDB@mbx-02.win.nominum.com> References: <4F71AC33.6050506@gmail.com> In-Reply-To: <4F71AC33.6050506@gmail.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [192.168.1.10] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [mif] Issue: lifetime 32bit or 16bit ? draft-ietf-mif-dhcpv6-route-option-04 X-BeenThere: mif@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multiple Interface Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 27 Mar 2012 15:37:38 -0000 > I think this [16 bit vs 32 bit lifetimes] is an issue. It generates addi= tional work to the > implementer. If one agrees that it is good to store the DHCP default > route in the existing ND data structures, then one notices a conversion > is needed. If these lifetime fields were expressed in the same number > of bits (preferably 16bit, because that exists already) then the > implementer would be relieved from conversion work. > I wanted to ask the oppinion of the WG about this issue. You already asked the working group this question, and got responses at lea= st from me. Has something changed since you last asked that encourages yo= u to ask again, or are you just hoping for a different answer this time? From ek@google.com Tue Mar 27 08:39:22 2012 Return-Path: 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 555E721E8244 for ; Tue, 27 Mar 2012 08:39:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.844 X-Spam-Level: X-Spam-Status: No, score=-102.844 tagged_above=-999 required=5 tests=[AWL=0.133, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1, 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 qHLVxUGZBMQO for ; Tue, 27 Mar 2012 08:39:21 -0700 (PDT) Received: from mail-qc0-f172.google.com (mail-qc0-f172.google.com [209.85.216.172]) by ietfa.amsl.com (Postfix) with ESMTP id A1BD421E8246 for ; Tue, 27 Mar 2012 08:39:21 -0700 (PDT) Received: by qcsq13 with SMTP id q13so42279qcs.31 for ; Tue, 27 Mar 2012 08:39:21 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding:x-system-of-record; bh=5Pc/RHlCB0kAHHv1IC2bTyJXWmOfTzAbupGzVBYE3uU=; b=g5FI8qr6WExxiWfSPMQw2Ehb31QMhw4+qlPCrPqowTsIkwe5mkFVJRAmLaG+tv4yzL RIGKnQzrd2Fe6KpOJ9UttVK81sp75Eegx5WWNyKDlqzY46Z/Dkr+l41QDUOL0r1U8Oa/ U98b8cqraKRtKorVxByZWMMxZ+GNGFP9YvHQW38+41KARCt+wl+RRK0xSpLOKaJneOnr Vd2M/IW///DQEC1miuh99yXpxmwijFVGH2WuJZr3LbDCB00gFq+8AiweLTR+OQiyBmOu rUAkc6oLJeAleCCeSzYqdg9XVcA14ISUQu1DXVIs65EBmhkxB69yOGxyAueaDF0pl/gN cYeQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding:x-system-of-record :x-gm-message-state; bh=5Pc/RHlCB0kAHHv1IC2bTyJXWmOfTzAbupGzVBYE3uU=; b=abJ71cjRJDmk03XSXD3q/4iA0Zr56xVwvKkpobK14bbde4OnkNKc/wkmHKmTfrDXqx IfZKLP0+8di4yFy5tqMT5+ApA5LyBv6yYeww/qCpao8/PXb8ZvYXkU1P/PJ2J+AQ0hkT 40QDe+bh0Yfd95mVX+Tgt6nZLlVejbWcKOqJxrZMaCEqY04fCYkaql8/uhWHbABd3sWK 1hVwWMqgV8ktAey2QHpLIbVkxgbC7F+Zvf0LIOnzU2iDhUu5iu0d1g9D+wGJAOQnq00Q LzaDae8I97WUYVnhnjvqmOHgbTcJBGwWCf6iP9uwIbAI6Lo4pZUg6ejbakJXOPQQTY3A ur1g== Received: by 10.229.102.101 with SMTP id f37mr9868226qco.37.1332862761178; Tue, 27 Mar 2012 08:39:21 -0700 (PDT) MIME-Version: 1.0 Received: by 10.229.102.101 with SMTP id f37mr9868217qco.37.1332862761041; Tue, 27 Mar 2012 08:39:21 -0700 (PDT) Received: by 10.229.128.170 with HTTP; Tue, 27 Mar 2012 08:39:21 -0700 (PDT) In-Reply-To: <8D23D4052ABE7A4490E77B1A012B6307472C3EC0@mbx-02.win.nominum.com> References: <4F71B306.1080509@gmail.com> <4F71B3EA.1000104@moth.iki.fi> <8D23D4052ABE7A4490E77B1A012B6307472C3E95@mbx-02.win.nominum.com> <8D23D4052ABE7A4490E77B1A012B6307472C3EC0@mbx-02.win.nominum.com> Date: Tue, 27 Mar 2012 15:39:21 +0000 Message-ID: From: Erik Kline To: Ted Lemon Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-System-Of-Record: true X-Gm-Message-State: ALoCoQl9PZ3Uh8zRl3Tp3m6xAb1ULoni2R0JxWJSWyPdq5/I2MhWgBJPwvM/DFrNHW9pT8pdnxe7ERPfqgmbVhrsC8chNUauJ/fyiWSKLzioo8KmSFatFpU5+RRRxENBaBjVU813WWaR Cc: "mif@ietf.org" Subject: Re: [mif] Issue: Only _one_ default route? draft-ietf-mif-dhcpv6-route-option-04 X-BeenThere: mif@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multiple Interface Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 27 Mar 2012 15:39:22 -0000 On 27 March 2012 15:33, Ted Lemon wrote: >> Submit to 6man, I think. > > Thanks for telling us your opinion, Erik. =C2=A0 Is there a reason behind= the opinion, or did it just spring into your mind like a tiny, perfect flo= wer? I was thinking of the RFC3484bis work going on right now. If there are changes that are needed there, it should get reviewed by the same group reviewing those other changes right now, yes? It would be a shame if the two I-Ds crossed in flight, but obviously not the end of the world. From Ted.Lemon@nominum.com Tue Mar 27 08:42:59 2012 Return-Path: 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 793DE21F8855 for ; Tue, 27 Mar 2012 08:42:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.468 X-Spam-Level: X-Spam-Status: No, score=-106.468 tagged_above=-999 required=5 tests=[AWL=0.131, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, 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 42CUsURn-hvK for ; Tue, 27 Mar 2012 08:42:58 -0700 (PDT) Received: from exprod7og101.obsmtp.com (exprod7og101.obsmtp.com [64.18.2.155]) by ietfa.amsl.com (Postfix) with ESMTP id 5FF7721F8824 for ; Tue, 27 Mar 2012 08:42:40 -0700 (PDT) Received: from shell-too.nominum.com ([64.89.228.229]) (using TLSv1) by exprod7ob101.postini.com ([64.18.6.12]) with SMTP ID DSNKT3Hf7rrRZITk0QCziQDuRrQ5iKdsxV2z@postini.com; Tue, 27 Mar 2012 08:42:40 PDT Received: from archivist.nominum.com (archivist.nominum.com [64.89.228.108]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "*.nominum.com", Issuer "Go Daddy Secure Certification Authority" (verified OK)) by shell-too.nominum.com (Postfix) with ESMTP id 8D3021B81E4 for ; Tue, 27 Mar 2012 08:42:37 -0700 (PDT) Received: from webmail.nominum.com (cas-02.win.nominum.com [64.89.228.132]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (Client CN "mail.nominum.com", Issuer "Go Daddy Secure Certification Authority" (verified OK)) by archivist.nominum.com (Postfix) with ESMTPS id 83E18190068; Tue, 27 Mar 2012 08:42:37 -0700 (PDT) (envelope-from Ted.Lemon@nominum.com) Received: from MBX-02.WIN.NOMINUM.COM ([64.89.228.134]) by CAS-02.WIN.NOMINUM.COM ([64.89.228.132]) with mapi id 14.02.0247.003; Tue, 27 Mar 2012 08:42:37 -0700 From: Ted Lemon To: Alexandru Petrescu , mif Thread-Topic: [mif] Issue: separate specific routes from default routes? draft-ietf-mif-dhcpv6-route-option-04 Thread-Index: AQHNDBC4I58B0DowIUysNniDIP8quZZ+R1Gs Date: Tue, 27 Mar 2012 15:42:36 +0000 Message-ID: <8D23D4052ABE7A4490E77B1A012B6307472C3F07@mbx-02.win.nominum.com> References: <4F71AB00.2020404@gmail.com> In-Reply-To: <4F71AB00.2020404@gmail.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [192.168.1.10] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [mif] Issue: separate specific routes from default routes? draft-ietf-mif-dhcpv6-route-option-04 X-BeenThere: mif@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multiple Interface Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 27 Mar 2012 15:42:59 -0000 > Second, using default routes in the same option type of specific routes > means that they'd share the same faith - if specific routes are wrongly > configured in the same section of the config file, there is a risk that > the default route is wrongly configured too. Or, the default route is > something of last resort, so it would be better to have it configured in > a different place, communicated with a different ORO type. Operationally it is always better for things to completely fail than to par= tially fail, because you see the problem immediately. In the case of a DH= CP server configuration problem, it's hard to see why it would be easier to= misconfigure a DHCP server when there is a single option than when there a= re two. > Third, if a single way of configuring default an specific routes with > DHCP then this means that a bigger software implementation would be > needed even for lightweight devices. Or, lightweight devices only use a > single route - the default route. Do you know of any specific devices that have this problem? > I suggest we separate the default route ORO from the specific routes ORO. I think this is a good way to solve the problem you have described, but I d= on't think the problem needs to be solved. I'd be interested to hear a sp= ecific, concrete use case for this. From lorenzo@google.com Tue Mar 27 08:44:05 2012 Return-Path: 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 04F9421F87E0 for ; Tue, 27 Mar 2012 08:44:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.816 X-Spam-Level: X-Spam-Status: No, score=-102.816 tagged_above=-999 required=5 tests=[AWL=0.160, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1, 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 yN--7ggYkRD9 for ; Tue, 27 Mar 2012 08:44:04 -0700 (PDT) Received: from mail-yx0-f172.google.com (mail-yx0-f172.google.com [209.85.213.172]) by ietfa.amsl.com (Postfix) with ESMTP id D6DC121F87DF for ; Tue, 27 Mar 2012 08:44:03 -0700 (PDT) Received: by yenm5 with SMTP id m5so31164yen.31 for ; Tue, 27 Mar 2012 08:44:03 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type:x-system-of-record; bh=ccVbpJCAd++Sj1ZTUGou2qtrwGcLHqWqNC+Zc5m8k5Q=; b=m7Y75TWRTQevOEX/I/qOFnCKIYPdmYEioH6FhU0ccOM5cGaIp/0V6sqtyDvwlAEL79 XUaEYC4Gy33kFBN7pAUcbO9AzaKakfQEUiRSf9pzC2T4hwLr4K9I0+pN8BW25xcRN0W5 E3aum5pnIySWrgAEAaUnTl4+FklRVxA9zxlyZqtjlsDz3NpyqNtWhiHThnyPsqui0C8A 2cLd3tMO9Z8HaPwphQXOchqPN3T9//xSb+oRsdi+kEsmeEMHmZZGGDLWisvYHKM2Tnw7 MA8Txp1dd6bxDwYJmJU3BPhdxBvDL8H1GDupVB9eNHHsdYeyli+iONOINXl65fNeUn6G /tpQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type:x-system-of-record:x-gm-message-state; bh=ccVbpJCAd++Sj1ZTUGou2qtrwGcLHqWqNC+Zc5m8k5Q=; b=cNGEgSE7+qpP8MKCwrcG8TQgCVbJn9rLYBduU7Wb8Hj6ub7llgkY430UE4w1FQ+FuV sWUKWjiu2XO/UayloBaBU1XoRc2ajijwrWBd8Owux0sB2+dHSb9SaPSHX9fPEsd7BlQA JdO23/kXBIIcyNfLa/REqht6eBtQnwrwo5DjYrzzx9a/54+KH0/0jGb1rVMwK0GCcn+m hNr4nbuDB+zUwHgkczpWIAl/CDoitzUXvriTiXfVxGXp2ePnIhxFZUZJL65da8JDZfi8 UV64vZI6n/8gfrB5OfpAThZFLkvyaS7LsWs45xUO2DVhKIILkCC3C6pqSB3cZtyYgs5v 9yHg== Received: by 10.60.7.196 with SMTP id l4mr32857383oea.8.1332863043409; Tue, 27 Mar 2012 08:44:03 -0700 (PDT) Received: by 10.60.7.196 with SMTP id l4mr32857359oea.8.1332863043242; Tue, 27 Mar 2012 08:44:03 -0700 (PDT) MIME-Version: 1.0 Received: by 10.182.63.231 with HTTP; Tue, 27 Mar 2012 08:43:43 -0700 (PDT) In-Reply-To: <4F47688B.10508@gmail.com> References: <20120224101611.22703.52041.idtracker@ietfa.amsl.com> <4F47688B.10508@gmail.com> From: Lorenzo Colitti Date: Tue, 27 Mar 2012 17:43:43 +0200 Message-ID: To: Tomek Mrugalski Content-Type: multipart/alternative; boundary=e89a8f6439103a097604bc3b5c5e X-System-Of-Record: true X-Gm-Message-State: ALoCoQn/R8g+LTLIwpeaGhkhGWUkYdVw/1ynrqF8muOJTws/BWT6uEU6odaxbd9jwY/ibZ7tJDTeDJPCPmmrs0udasjaCKfvT+6VcK5pfLIIw6q5m9ypgZS3C28+Z+KBInkjQF3bYg7f Cc: Thomas Narten , Brian Haberman , mif@ietf.org, Ron Bonica , Ted Lemon Subject: Re: [mif] draft-ietf-mif-dhcpv6-route-option-04 published X-BeenThere: mif@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multiple Interface Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 27 Mar 2012 15:44:05 -0000 --e89a8f6439103a097604bc3b5c5e Content-Type: text/plain; charset=ISO-8859-1 On Fri, Feb 24, 2012 at 19:38, Tomek Mrugalski wrote: > > > Title : DHCPv6 Route Options > > Author(s) : Wojciech Dec > > Tomasz Mrugalski > > Tao Sun > > Behcet Sarikaya > > Filename : draft-ietf-mif-dhcpv6-route-option-04.txt > > Pages : 22 > > Date : 2012-02-24 > [CCing a few of the folks we had a chat with about this in Taipei] Hi, I believe this document is not appropriate to be discussed in this working group, for two reasons: 1. It has almost nothing to do with multiple interfaces. Section 2 contains text on why this document applies to "multi-homed scenarios". However, there is nothing in this option that makes it any more applicable to a multi-homed scenario than to a single-homed scenario. At least 11 out of the 14 use cases cited (#1, #2, #3, #5, #6, #7, #10,#11, #12, #13, and #14) are equally applicable to hosts with only one interface. Further: a host needs to obtain routing information in both single and multi-homed scenarios, and how the information is obtained (DHCPv6, RA, HTTP, carrier pigeon) is completely orthogonal to whether the host has one or more interfaces. 2. This option provides a complete replacement for the ND functionality specified by RFC 4862 and RFC 4191, including default routes, more-specific routes, and on-link determination. This is all in 6man's domain. So this option should be taken to 6man. I have a number other issues with the document as well. The use cases do not seem particularly convincing; it seems to me that some of them are niche use cases, some are circular arguments, and some are specious. The long-term implications of configuring routing via DHCP, which is a static protocol mediated by servers and suited to making promises, instead of using dynamic information originated by routers, does not seem to be worth it. But most importantly this document should be moved to 6man so that the people who are responsible for the architecture can see it, comment on it, and possibly reach consensus on it. Regards, Lorenzo --e89a8f6439103a097604bc3b5c5e Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
On Fri, Feb 24, 2012 at 19:38, Tomek Mrugalski w= rote:
> =A0 =A0 =A0 Title =A0 =A0 =A0 =A0 = =A0 : DHCPv6 Route Options
> =A0 =A0 =A0 Author(s) =A0 =A0 =A0 : Wojciech Dec
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 Tomasz Mrugalski
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 Tao Sun
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 Behcet Sarikaya
> =A0 =A0 =A0 Filename =A0 =A0 =A0 =A0: draft-ietf-mif-dhcpv6-route-opti= on-04.txt
> =A0 =A0 =A0 Pages =A0 =A0 =A0 =A0 =A0 : 22
> =A0 =A0 =A0 Date =A0 =A0 =A0 =A0 =A0 =A0: 2012-02-24
<= div>
[CCing a few of the folks we had a chat with about this = in Taipei]

Hi,

I believe = this document is not appropriate to be discussed in this working group, for= two reasons:

1. It has almost nothing to do with multiple interfaces= . Section 2 contains text on why this document applies to "multi-homed= scenarios". However, there is nothing in this option that makes it an= y more applicable to a multi-homed scenario than to a single-homed scenario= .

At least 11 out of the 14 use cases cited (#1, #2, #3, = #5, #6, #7, #10,#11, #12, #13, and #14) are equally applicable to hosts wit= h only one interface.

Further: a host needs to obt= ain routing information in both single and multi-homed scenarios, and how t= he information is obtained (DHCPv6, RA, HTTP, carrier pigeon) is completely= orthogonal to whether the host has one or more interfaces.

2. This option provides a complete replacement for the = ND functionality specified by RFC 4862 and RFC 4191, including default rout= es, more-specific routes, and on-link determination. This is all=A0in 6man&= #39;s domain. So this option should be taken to 6man.

I have a number other issues with the document as well.= The use cases do not seem particularly convincing; it seems to me that som= e of them are niche use cases, some are circular arguments, and some are sp= ecious. The long-term implications of configuring routing via DHCP, which i= s a static protocol mediated by servers and suited to making promises, inst= ead of using dynamic information originated by routers, does not seem to be= worth it.

But most importantly this document should be moved to 6man so that= the people who are responsible for the architecture can see it, comment on= it, and possibly reach consensus on it.

Regards,<= /div>
Lorenzo
--e89a8f6439103a097604bc3b5c5e-- From Ted.Lemon@nominum.com Tue Mar 27 08:52:20 2012 Return-Path: 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 99E5D21F88C6 for ; Tue, 27 Mar 2012 08:52:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.47 X-Spam-Level: X-Spam-Status: No, score=-106.47 tagged_above=-999 required=5 tests=[AWL=0.129, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, 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 9wYS75wgM8mL for ; Tue, 27 Mar 2012 08:52:20 -0700 (PDT) Received: from exprod7og119.obsmtp.com (exprod7og119.obsmtp.com [64.18.2.16]) by ietfa.amsl.com (Postfix) with ESMTP id 9A33921F88C4 for ; Tue, 27 Mar 2012 08:52:16 -0700 (PDT) Received: from shell-too.nominum.com ([64.89.228.229]) (using TLSv1) by exprod7ob119.postini.com ([64.18.6.12]) with SMTP ID DSNKT3HiMOHPgtMmsI/ayLnTMLtG+eqWAon8@postini.com; Tue, 27 Mar 2012 08:52:16 PDT Received: from archivist.nominum.com (archivist.nominum.com [64.89.228.108]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "*.nominum.com", Issuer "Go Daddy Secure Certification Authority" (verified OK)) by shell-too.nominum.com (Postfix) with ESMTP id AEE4B1B81E4 for ; Tue, 27 Mar 2012 08:52:15 -0700 (PDT) Received: from webmail.nominum.com (cas-02.win.nominum.com [64.89.228.132]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (Client CN "mail.nominum.com", Issuer "Go Daddy Secure Certification Authority" (verified OK)) by archivist.nominum.com (Postfix) with ESMTPS id A0EDA190068; Tue, 27 Mar 2012 08:52:15 -0700 (PDT) (envelope-from Ted.Lemon@nominum.com) Received: from MBX-02.WIN.NOMINUM.COM ([64.89.228.134]) by CAS-02.WIN.NOMINUM.COM ([64.89.228.132]) with mapi id 14.02.0247.003; Tue, 27 Mar 2012 08:52:15 -0700 From: Ted Lemon To: Alexandru Petrescu Thread-Topic: [mif] draft-ietf-mif-dhcpv6-route-option-04 published Thread-Index: AQHM8uBsQi4512i5cE6t8t5dPnex2ZZnd0OAgAACEYCABGRggIAAcFuAgAFcGoCAABh6gIAQ5pEA///UD5w= Date: Tue, 27 Mar 2012 15:52:14 +0000 Message-ID: <8D23D4052ABE7A4490E77B1A012B6307472C3F41@mbx-02.win.nominum.com> References: <20120224101611.22703.52041.idtracker@ietfa.amsl.com> <4F47688B.10508@gmail.com> <4F5E2F61.9040009@gmail.com> <611FBED3-349A-43E7-B4B9-0BC313EA4F7A@nominum.com> <4F61E04F.4020800@gmail.com> <4F636291.7060104@gmail.com> , <4F71A47C.7050906@gmail.com> In-Reply-To: <4F71A47C.7050906@gmail.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [192.168.1.10] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: mif Subject: Re: [mif] draft-ietf-mif-dhcpv6-route-option-04 published X-BeenThere: mif@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multiple Interface Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 27 Mar 2012 15:52:20 -0000 > What is the reason of _not_ representing lifetimes in the same manner > across protocols? We do represent Types and other things in the same > manner, why not lifetimes? 2^16 seconds is 18 hours. From wherrin@gmail.com Tue Mar 27 08:53:21 2012 Return-Path: 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 B061021E8259 for ; Tue, 27 Mar 2012 08:53:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.977 X-Spam-Level: X-Spam-Status: No, score=-2.977 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1] 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 fA7hxXDnPJwe for ; Tue, 27 Mar 2012 08:53:21 -0700 (PDT) Received: from mail-bk0-f44.google.com (mail-bk0-f44.google.com [209.85.214.44]) by ietfa.amsl.com (Postfix) with ESMTP id C131D21E808F for ; Tue, 27 Mar 2012 08:53:04 -0700 (PDT) Received: by bkuw5 with SMTP id w5so39579bku.31 for ; Tue, 27 Mar 2012 08:53:03 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:from:date :x-google-sender-auth:message-id:subject:to:cc:content-type :content-transfer-encoding; bh=fnkoqB16evEm2HJ+v5jPJR67CxbmIV6KIJzTOZcWF0Y=; b=bmVM0TZdiBwoPWVRowybrWumaxzG3xbTtrAnUnbe/eNSnOHt9iukOQZDWqMt727wRU k7XPq98MztbY21hlv/kknpYjoRIlViyVNRDGcqg3bd4LSIIRIxO7RMRBEyXnfQtdvbD8 5u7KPraVPbTlNZqCbFbdYZ5DZLMvItIdMw25adZnDPHt+tyJ9l0I0fz+Lng1YoUjIIlF Uu0jPx9H6BKcB3993xN5kUPtULtCpoUxNUAQwSUVAgk2xCTVPND1BgbmvmTn+IoZ17ES EVklc6ja/R1hCEU35Dy/Pc0LS7aateSOh7nIU1uHpjNtfFAsG3Joq14YAlFkGb4tZ1fp sMGA== Received: by 10.204.156.204 with SMTP id y12mr10548360bkw.130.1332863583573; Tue, 27 Mar 2012 08:53:03 -0700 (PDT) MIME-Version: 1.0 Sender: wherrin@gmail.com Received: by 10.204.37.70 with HTTP; Tue, 27 Mar 2012 08:52:43 -0700 (PDT) In-Reply-To: <4F71AE51.4000304@gmail.com> References: <4F71AE51.4000304@gmail.com> From: William Herrin Date: Tue, 27 Mar 2012 11:52:43 -0400 X-Google-Sender-Auth: xbypEtlDF5PfsA47srnikXm2Nlo Message-ID: To: Alexandru Petrescu Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: mif Subject: Re: [mif] Issue: absent MAC address of default route? draft-ietf-mif-dhcpv6-route-option-04 X-BeenThere: mif@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multiple Interface Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 27 Mar 2012 15:53:21 -0000 On Tue, Mar 27, 2012 at 8:10 AM, Alexandru Petrescu wrote: > In the same manner, it would be useful to have DHCPv6 way of > communicating the default route to add the MAC address of the IP address > of the default router. =A0This would save on the number of messages excha= nged. > > I wanted to ask the oppinion of the WG on this particular topic, thank yo= u. Hi Alexandru, If added, I think it should be non-authoritative. That is, the receiving host can use it briefly to get a jump start on communication but is expected to promptly perform an ND request for the authoritative MAC. This would allow a host to recover gracefully in the inevitable event that the DHCP server and router get out of sync about the router's MAC address. Regards, Bill Herrin --=20 William D. Herrin ................ herrin@dirtside.com=A0 bill@herrin.us 3005 Crane Dr. ...................... Web: Falls Church, VA 22042-3004 From wherrin@gmail.com Tue Mar 27 08:54:43 2012 Return-Path: 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 76F1821E825C for ; Tue, 27 Mar 2012 08:54:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.977 X-Spam-Level: X-Spam-Status: No, score=-2.977 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1] 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 jbnmBfTPF3zJ for ; Tue, 27 Mar 2012 08:54:43 -0700 (PDT) Received: from mail-bk0-f44.google.com (mail-bk0-f44.google.com [209.85.214.44]) by ietfa.amsl.com (Postfix) with ESMTP id 8934F21E8250 for ; Tue, 27 Mar 2012 08:54:42 -0700 (PDT) Received: by bkuw5 with SMTP id w5so40987bku.31 for ; Tue, 27 Mar 2012 08:54:41 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:from:date :x-google-sender-auth:message-id:subject:to:cc:content-type :content-transfer-encoding; bh=CO9SLfhgOClHCsml+V6ep0VBPzEFXae28U2l1zANR24=; b=e+8rnC5Rz+wD0EmvhmJOsEcPVHYIPqKTpjkOGGNXEi69xRhfKN9JSfyTC+tjT/I4fz YLsVWa94TkbXSfBXA8q17gBZNBTGezdCGDvnSWQpLmks0pLkAh7OXQWKoiGOFZsT9smr a7dlTdl9lrnZ+HqmVa6sNKA2BOSM6LzxOD5mf0K7R5wVwf2fYg5+5VhXPVlSsTEuEW1j QXobXNJlxIDeuFjNA4hjVXBDSqZUmVJCezXc+zdDykWLAY4HML2ykZo5wJSPPcQyehtL C0Te22MeCHnDCRLqLvxJHdkbJp7b5A9kS9tNamPlKXkPzKyh2es5lYMcICmUO6EjMy5v tqVQ== Received: by 10.204.136.220 with SMTP id s28mr10652768bkt.94.1332863681494; Tue, 27 Mar 2012 08:54:41 -0700 (PDT) MIME-Version: 1.0 Sender: wherrin@gmail.com Received: by 10.204.37.70 with HTTP; Tue, 27 Mar 2012 08:54:20 -0700 (PDT) In-Reply-To: <4F71AC33.6050506@gmail.com> References: <4F71AC33.6050506@gmail.com> From: William Herrin Date: Tue, 27 Mar 2012 11:54:20 -0400 X-Google-Sender-Auth: iGKhBfztZKP8oTxepSf8rzEVXWY Message-ID: To: Alexandru Petrescu Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: mif Subject: Re: [mif] Issue: lifetime 32bit or 16bit ? draft-ietf-mif-dhcpv6-route-option-04 X-BeenThere: mif@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multiple Interface Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 27 Mar 2012 15:54:43 -0000 On Tue, Mar 27, 2012 at 8:01 AM, Alexandru Petrescu wrote: > Currently draft-ietf-mif-dhcpv6-route-option-04 specifies that the > lifetime of a route (and implicitely of a default route) is to be 32bit > length field. > > On another hand, the currently implemented default routes are > implemented according to ND Neighbor Discovery, which uses route_r_ > lifetime on 16bit (RFC 4861 search "Router Lifetime"). > > I think this is an issue. =A0It generates additional work to the > implementer. =A0If one agrees that it is good to store the DHCP default > route in the existing ND data structures, then one notices a conversion > is needed. =A0If these lifetime fields were expressed in the same number > of bits (preferably 16bit, because that exists already) then the > implementer would be relieved from conversion work. > > I wanted to ask the oppinion of the WG about this issue. I'm new to the questions surrounding DHCPv6, so my apologies if this has already been discussed. It's common practice to issue IPv4 DHCP lifetimes in excess of 24 hours (86400 seconds). I have to think that supporting common configurations outweighs preserving ND data structures. However... why would DHCP issue a router lifetime which is different from the overall lifetime anyway? What's the use case for different components of the DHCP message having different lifetimes? Thanks, Bill --=20 William D. Herrin ................ herrin@dirtside.com=A0 bill@herrin.us 3005 Crane Dr. ...................... Web: Falls Church, VA 22042-3004 From alexandru.petrescu@gmail.com Tue Mar 27 10:46:47 2012 Return-Path: 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 1B7F51F0C61 for ; Tue, 27 Mar 2012 10:46:47 -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=1.030, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] 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 p7mBzR0TSGMq for ; Tue, 27 Mar 2012 10:46:46 -0700 (PDT) Received: from mail-wg0-f44.google.com (mail-wg0-f44.google.com [74.125.82.44]) by ietfa.amsl.com (Postfix) with ESMTP id 6314D1F0C5E for ; Tue, 27 Mar 2012 10:46:46 -0700 (PDT) Received: by wgbdr13 with SMTP id dr13so118270wgb.13 for ; Tue, 27 Mar 2012 10:46:45 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; bh=TKJMWA/Z9vuH+PDvhQ4GwD/m1HdaN+gEc2gM9ys3DZo=; b=ReqkiqkyZ7BHkLinWJapITwgLFNtA43XcA9+b5lMvJlfo6RDInlSpI7DcbTQfey5/s puics8d6UR+zn9WawGyjHRFyzpMUnH/TIacQ06bHYgUTNyc6uOHQf9AVeK57ae6L+AkT vw4TDvfKEOp6MX083a7zILJrhbwgyR4lOHdB8H1ZVTtVNhxGte45qIplIVJ2Z4LoJ76e hdb7/SFyPoDGW7cxrnXbAZ0jq7zxxqeBC4q3wCjSCAiSOo8JlGIH1uFwuKuiS5DOUL35 QYXEDu1lekrfbbUhvvuczMgTPiDlLPnUWLoc75GJuScgz/7/Tp7sNNOvOf7Ct8M3kAVV NmiQ== Received: by 10.180.102.100 with SMTP id fn4mr5577wib.1.1332870405609; Tue, 27 Mar 2012 10:46:45 -0700 (PDT) Received: from [192.168.0.13] (bur91-3-82-239-213-32.fbx.proxad.net. [82.239.213.32]) by mx.google.com with ESMTPS id fn2sm1926272wib.0.2012.03.27.10.46.44 (version=TLSv1/SSLv3 cipher=OTHER); Tue, 27 Mar 2012 10:46:44 -0700 (PDT) Message-ID: <4F71FCFE.7080002@gmail.com> Date: Tue, 27 Mar 2012 19:46:38 +0200 From: Alexandru Petrescu User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:11.0) Gecko/20120312 Thunderbird/11.0 MIME-Version: 1.0 To: Ted Lemon References: <4F71AE51.4000304@gmail.com> <8D23D4052ABE7A4490E77B1A012B6307472C3EB0@mbx-02.win.nominum.com> In-Reply-To: <8D23D4052ABE7A4490E77B1A012B6307472C3EB0@mbx-02.win.nominum.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Cc: mif Subject: Re: [mif] Issue: absent MAC address of default route? draft-ietf-mif-dhcpv6-route-option-04 X-BeenThere: mif@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multiple Interface Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 27 Mar 2012 17:46:47 -0000 Le 27/03/2012 17:31, Ted Lemon a écrit : >> In the particular case of default route, the existing mechanism to >> achieve this is ND. This has the optional feature to communicate >> the MAC address of the default router at the same time. This >> saves on the number of messages exchanged (instead of 4 messages, >> only 2 are used). > > In environments where this is a significant amount of additional > traffic, presumably ND will be the preferred mechanism for > delivering the default route. In lightweight environments, and this is a MIF-ed router not host, it would only run DHCP and maybe no ND (only use its data structures). This is so to have only one software and protocol to obtain route, address, prefix and prefix for further away. ND would be superfluous. Similarly, work was and still is ongoing about doing same with ND not DHCP. >> In the same manner, it would be useful to have DHCPv6 way of >> communicating the default route to add the MAC address of the IP >> address of the default router. This would save on the number of >> messages exchanged. > > I think this is an unnecessary optimization. What's the use case > where both ND is not preferred, and bandwidth is so constrained as > to make this a problem? As above. Alex From alexandru.petrescu@gmail.com Tue Mar 27 10:48:04 2012 Return-Path: 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 CBF411F0C5E for ; Tue, 27 Mar 2012 10:48:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.637 X-Spam-Level: X-Spam-Status: No, score=-2.637 tagged_above=-999 required=5 tests=[AWL=0.962, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] 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 Q5rIBP5ogwmL for ; Tue, 27 Mar 2012 10:48:04 -0700 (PDT) Received: from mail-wi0-f170.google.com (mail-wi0-f170.google.com [209.85.212.170]) by ietfa.amsl.com (Postfix) with ESMTP id D41421F0C61 for ; Tue, 27 Mar 2012 10:48:03 -0700 (PDT) Received: by wibhr17 with SMTP id hr17so4952006wib.1 for ; Tue, 27 Mar 2012 10:48:03 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; bh=fqRZTWPUY0IPPrUHW3Rr+9BDXMLFZaoT68m3Xgh04ok=; b=GAZaQIdGOAwDQrMnJ7rqlzovw2qVPEbCZpWDZnUFtU24Nu9L7yrTI3yaj+dd0hY83l aoTFuOIY/F9DsaaJqmJuVRVUYqckVSPlQ0s9INXqYcHxyPCCnvUS2esj3IhHt9rrFrGd I5X14j400r8jY9Hs5E8IOmewTF8qDpakbuIsmhe1TV9gk+J8VPU1at3LqPhqXR/N2IlJ 8WA6EAnABwg0CzqymIoZJ29JadtcaJfO8Nm00H1CAtWVuuYqX5ATRfO1Q/N2yCq7aDst JeLr8W3S6+uYuHOxsS5RBoC9WMwdCZ3yLEnZNfS69OLSLMbQLb/VGQOYZgCmQ9oNobVD Mpag== Received: by 10.180.97.41 with SMTP id dx9mr29522836wib.9.1332870483070; Tue, 27 Mar 2012 10:48:03 -0700 (PDT) Received: from [192.168.0.13] (bur91-3-82-239-213-32.fbx.proxad.net. [82.239.213.32]) by mx.google.com with ESMTPS id 17sm51980208wis.0.2012.03.27.10.48.01 (version=TLSv1/SSLv3 cipher=OTHER); Tue, 27 Mar 2012 10:48:02 -0700 (PDT) Message-ID: <4F71FD4C.6050500@gmail.com> Date: Tue, 27 Mar 2012 19:47:56 +0200 From: Alexandru Petrescu User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:11.0) Gecko/20120312 Thunderbird/11.0 MIME-Version: 1.0 To: Ted Lemon References: <4F71AC33.6050506@gmail.com> <8D23D4052ABE7A4490E77B1A012B6307472C3EDB@mbx-02.win.nominum.com> In-Reply-To: <8D23D4052ABE7A4490E77B1A012B6307472C3EDB@mbx-02.win.nominum.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Cc: mif Subject: Re: [mif] Issue: lifetime 32bit or 16bit ? draft-ietf-mif-dhcpv6-route-option-04 X-BeenThere: mif@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multiple Interface Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 27 Mar 2012 17:48:04 -0000 Le 27/03/2012 17:37, Ted Lemon a écrit : >> I think this [16 bit vs 32 bit lifetimes] is an issue. It >> generates additional work to the implementer. If one agrees that >> it is good to store the DHCP default route in the existing ND data >> structures, then one notices a conversion is needed. If these >> lifetime fields were expressed in the same number of bits >> (preferably 16bit, because that exists already) then the >> implementer would be relieved from conversion work. > >> I wanted to ask the oppinion of the WG about this issue. > > You already asked the working group this question, and got responses > at least from me. What do the others think? > Has something changed since you last asked that encourages you to ask > again, or are you just hoping for a different answer this time? We need to fix this in Paris. Alex From alexandru.petrescu@gmail.com Tue Mar 27 10:51:51 2012 Return-Path: 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 8687321E80AF for ; Tue, 27 Mar 2012 10:51:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.697 X-Spam-Level: X-Spam-Status: No, score=-2.697 tagged_above=-999 required=5 tests=[AWL=0.902, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] 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 XsYr1p-pKgsr for ; Tue, 27 Mar 2012 10:51:51 -0700 (PDT) Received: from mail-we0-f172.google.com (mail-we0-f172.google.com [74.125.82.172]) by ietfa.amsl.com (Postfix) with ESMTP id BCE5521E80B3 for ; Tue, 27 Mar 2012 10:51:50 -0700 (PDT) Received: by werb10 with SMTP id b10so125376wer.31 for ; Tue, 27 Mar 2012 10:51:50 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; bh=h1ePtIszR46v9nMCDRfCupqrJSNyw531DpB7qmhMhUA=; b=pCWQw41noDT797kzGaxlyaOikI1yDoR0xY959u4ufMOL5vqJokH6iXGJBLPxIZBu5O x+WWTOeIknzBS/khckxEjWnBCYGcHZs25Eoa6iAe4xg7uUMKzTZyslLvnswNletVX52C B2TIJbRP2PLmppOzLQSEscLN4AQRWym0gC4e1RsyZ+zUvmY7WLQTd2H901TcC2arNTGp EqOgmm7KF73VjTeZo0FYixZUdrM0qCmcKc3/V6QDLkKWEofCiHGm8Xs66vxQ1IbXlu7V BN8fWvBzfs2MJnJt34AJ4jwKHcsTP+VaeYQbqAwHdIJroT45lrDS0jZeSBTHsxgtm+ha SUeg== Received: by 10.180.107.68 with SMTP id ha4mr28520871wib.15.1332870709956; Tue, 27 Mar 2012 10:51:49 -0700 (PDT) Received: from [192.168.0.13] (bur91-3-82-239-213-32.fbx.proxad.net. [82.239.213.32]) by mx.google.com with ESMTPS id gg2sm1885717wib.7.2012.03.27.10.51.48 (version=TLSv1/SSLv3 cipher=OTHER); Tue, 27 Mar 2012 10:51:49 -0700 (PDT) Message-ID: <4F71FE2F.9050309@gmail.com> Date: Tue, 27 Mar 2012 19:51:43 +0200 From: Alexandru Petrescu User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:11.0) Gecko/20120312 Thunderbird/11.0 MIME-Version: 1.0 To: Ted Lemon References: <4F71AB00.2020404@gmail.com> <8D23D4052ABE7A4490E77B1A012B6307472C3F07@mbx-02.win.nominum.com> In-Reply-To: <8D23D4052ABE7A4490E77B1A012B6307472C3F07@mbx-02.win.nominum.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Cc: mif Subject: Re: [mif] Issue: separate specific routes from default routes? draft-ietf-mif-dhcpv6-route-option-04 X-BeenThere: mif@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multiple Interface Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 27 Mar 2012 17:51:51 -0000 Le 27/03/2012 17:42, Ted Lemon a écrit : >> Second, using default routes in the same option type of specific >> routes means that they'd share the same faith - if specific routes >> are wrongly configured in the same section of the config file, >> there is a risk that the default route is wrongly configured too. >> Or, the default route is something of last resort, so it would be >> better to have it configured in a different place, communicated >> with a different ORO type. > > Operationally it is always better for things to completely fail than > to partially fail, because you see the problem immediately. In the > case of a DHCP server configuration problem, it's hard to see why it > would be easier to misconfigure a DHCP server when there is a single > option than when there are two. If there are two options instead of one this encorages the implementer to dedicate different sections in the dhcpd.conf file, and allocate a specific keyword for _default_ route. This is something that strikes the eye an makes him/her more cautious about what to put there in that single place. The specific routes are too generic and numerous to check one by one. >> Third, if a single way of configuring default an specific routes >> with DHCP then this means that a bigger software implementation >> would be needed even for lightweight devices. Or, lightweight >> devices only use a single route - the default route. > > Do you know of any specific devices that have this problem? > >> I suggest we separate the default route ORO from the specific >> routes ORO. > > I think this is a good way to solve the problem you have described, > but I don't think the problem needs to be solved. I'd be > interested to hear a specific, concrete use case for this. Hm, use cases. If I insist is that I believe there are some maybe under development. Also, if one simply checks the SDO that needs it one can see it easily. What do the others think about this issue? Alex From alexandru.petrescu@gmail.com Tue Mar 27 10:54:58 2012 Return-Path: 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 5B11C21F876C for ; Tue, 27 Mar 2012 10:54:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.75 X-Spam-Level: X-Spam-Status: No, score=-2.75 tagged_above=-999 required=5 tests=[AWL=0.849, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] 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 qfLhdcaSmK85 for ; Tue, 27 Mar 2012 10:54:57 -0700 (PDT) Received: from mail-wg0-f42.google.com (mail-wg0-f42.google.com [74.125.82.42]) by ietfa.amsl.com (Postfix) with ESMTP id 76FEE21F8768 for ; Tue, 27 Mar 2012 10:54:57 -0700 (PDT) Received: by wgbds11 with SMTP id ds11so3563173wgb.1 for ; Tue, 27 Mar 2012 10:54:56 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; bh=0Ko75k15yFyZBahALXXp6R7Oup2vLbPnGDJy23gEh7I=; b=qImRGMphMlTz5SwO16s7VbZtroiPuv0+0Py7yB94WdbNgxfQsoJgvh6yHv8It5iO/D U8QCEY1y6a+V8YmJ4mIv8lwzSQgAElmJ0p01BbGW1FfPnzqz0Emgyr54290whDhD0Ykj FlzrLsNXqgHOnkXnJnh/yP/t1ZuKyWLMWLz0Nu8zvdCtO/mAl/rluSgHdMOVWzErfDLm smbEIBvLoGTQ3oHokZGroL5oZTyih8DMnnGoPMzLKkF3r7rpPHgFW84Ecp0Jh2lMfzBL sDlxpDz9jKAqILPLqZ4jZLtucToRlw2VyHBfVsM0BqYljtTSs1Z/iU37RyN45f34STW+ 3rsQ== Received: by 10.180.98.8 with SMTP id ee8mr29888551wib.14.1332870896490; Tue, 27 Mar 2012 10:54:56 -0700 (PDT) Received: from [192.168.0.13] (bur91-3-82-239-213-32.fbx.proxad.net. [82.239.213.32]) by mx.google.com with ESMTPS id n8sm1885811wix.10.2012.03.27.10.54.54 (version=TLSv1/SSLv3 cipher=OTHER); Tue, 27 Mar 2012 10:54:55 -0700 (PDT) Message-ID: <4F71FEE9.2010106@gmail.com> Date: Tue, 27 Mar 2012 19:54:49 +0200 From: Alexandru Petrescu User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:11.0) Gecko/20120312 Thunderbird/11.0 MIME-Version: 1.0 To: Ted Lemon References: <20120224101611.22703.52041.idtracker@ietfa.amsl.com> <4F47688B.10508@gmail.com> <4F5E2F61.9040009@gmail.com> <611FBED3-349A-43E7-B4B9-0BC313EA4F7A@nominum.com> <4F61E04F.4020800@gmail.com> <4F636291.7060104@gmail.com> , <4F71A47C.7050906@gmail.com> <8D23D4052ABE7A4490E77B1A012B6307472C3F41@mbx-02.win.nominum.com> In-Reply-To: <8D23D4052ABE7A4490E77B1A012B6307472C3F41@mbx-02.win.nominum.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Cc: mif Subject: Re: [mif] draft-ietf-mif-dhcpv6-route-option-04 published X-BeenThere: mif@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multiple Interface Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 27 Mar 2012 17:54:58 -0000 Le 27/03/2012 17:52, Ted Lemon a écrit : >> What is the reason of _not_ representing lifetimes in the same >> manner across protocols? We do represent Types and other things in >> the same manner, why not lifetimes? > > 2^16 seconds is 18 hours. You seem to be saying that is too short? I believe it is way too long for a device that moves constantly. Alex From alexandru.petrescu@gmail.com Tue Mar 27 10:57:35 2012 Return-Path: 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 59F3421F8771 for ; Tue, 27 Mar 2012 10:57:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.798 X-Spam-Level: X-Spam-Status: No, score=-2.798 tagged_above=-999 required=5 tests=[AWL=0.801, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] 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 0vrmaClZ4tp1 for ; Tue, 27 Mar 2012 10:57:34 -0700 (PDT) Received: from mail-we0-f172.google.com (mail-we0-f172.google.com [74.125.82.172]) by ietfa.amsl.com (Postfix) with ESMTP id A112A21F8770 for ; Tue, 27 Mar 2012 10:57:34 -0700 (PDT) Received: by werb10 with SMTP id b10so129696wer.31 for ; Tue, 27 Mar 2012 10:57:33 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; bh=QE8TEGIMXXFLdBh6nq/wHbPJno+IthpxTX23tND075s=; b=bY7IftQhlRVR0XKEm02s1xxxQrqELdEe5xmL5s9a/n7MeE7KUF0KfL5j/O4LdCZNIm 0DhD0fXehQcVRDi3daW5Naf275Cn+6M1XzDfHW+281GZPYymkHB7lRd/NPZIGQPxmapG Hb3mU5eBbHbPShWq1NIzSAQXR4Uool0OZ7XW9kUCyt0HItALjRnm4zdo7QpJYBqCMkTd 2+Cq1GnmJJ9w3KC3yMHAEeeYP4u1nkdZ31hIX5fhy3dKXTfB4n8JrN4YqdFsMor+37BM ubCn8hmKJElKbNUsMDNqpjm7rX9Kjlsp039jud5eSXeaceipthbGQhfsklp0b6/bJo4W wb6w== Received: by 10.216.131.30 with SMTP id l30mr15132472wei.111.1332871053810; Tue, 27 Mar 2012 10:57:33 -0700 (PDT) Received: from [192.168.0.13] (bur91-3-82-239-213-32.fbx.proxad.net. [82.239.213.32]) by mx.google.com with ESMTPS id n15sm51104674wiw.6.2012.03.27.10.57.32 (version=TLSv1/SSLv3 cipher=OTHER); Tue, 27 Mar 2012 10:57:33 -0700 (PDT) Message-ID: <4F71FF86.2040502@gmail.com> Date: Tue, 27 Mar 2012 19:57:26 +0200 From: Alexandru Petrescu User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:11.0) Gecko/20120312 Thunderbird/11.0 MIME-Version: 1.0 To: William Herrin References: <4F71AE51.4000304@gmail.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Cc: mif Subject: Re: [mif] Issue: absent MAC address of default route? draft-ietf-mif-dhcpv6-route-option-04 X-BeenThere: mif@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multiple Interface Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 27 Mar 2012 17:57:35 -0000 Le 27/03/2012 17:52, William Herrin a écrit : > On Tue, Mar 27, 2012 at 8:10 AM, Alexandru Petrescu > wrote: >> In the same manner, it would be useful to have DHCPv6 way of >> communicating the default route to add the MAC address of the IP >> address of the default router. This would save on the number of >> messages exchanged. >> >> I wanted to ask the oppinion of the WG on this particular topic, >> thank you. > > Hi Alexandru, > > If added, I think it should be non-authoritative. That is, the > receiving host can use it briefly to get a jump start on > communication but is expected to promptly perform an ND request for > the authoritative MAC. This would allow a host to recover gracefully > in the inevitable event that the DHCP server and router get out of > sync about the router's MAC address. In most senses I agree. First, if added, I would think it would be optional - just send the MAC address if the admin puts it in the dhcpd.conf file. Second, I think indeed it should be non-authoritative, and be superseded by the ND operation. If ND implementation exists and is there, it should have authority over the information coming from DHCP, including the IP of the default router and its MAC. Alex > > Regards, Bill Herrin > From alexandru.petrescu@gmail.com Tue Mar 27 11:06:49 2012 Return-Path: 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 0964321E80FF for ; Tue, 27 Mar 2012 11:06:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.84 X-Spam-Level: X-Spam-Status: No, score=-2.84 tagged_above=-999 required=5 tests=[AWL=0.759, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] 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 FI6w5uMTYylT for ; Tue, 27 Mar 2012 11:06:48 -0700 (PDT) Received: from mail-we0-f172.google.com (mail-we0-f172.google.com [74.125.82.172]) by ietfa.amsl.com (Postfix) with ESMTP id 2E73C21E808D for ; Tue, 27 Mar 2012 11:06:48 -0700 (PDT) Received: by werb10 with SMTP id b10so136020wer.31 for ; Tue, 27 Mar 2012 11:06:47 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:subject :content-type:content-transfer-encoding; bh=iGq3g9YN0lu9mcy37gnXhosGOXxVSRYER1dg0eCWgW4=; b=MnYC7i+K6yhuAgIEh4d9TAzh9fp2ZEcg/77hOhzefehc9DKwi0QquiDkjGoo2aiQMJ m3nz7Vb5DaseVH9SJJ1bbVNhYzBiuy8uKq4oxjUJgN8ruU8GOvzIwHtGh1VM/1Z3O9pn YXxk/KCUEJ+zTbTAdyu/cM4xRJHUHq4OyDq9ycWqtCf9wRhCjxTCCTc3GLNXlZJC4OhX BhgMExjyTOSB43vfe6Mah7uOQa0nHvgLQbFJ2nNMeHY28sshRK2MicH7T5Q4a7w90LlJ hEza4xU9sxWqmRahcoMOCDxISBQeA2mzOzv9CkruIO/2qgDvkur4zi+j6jMccLKiUzOX O85Q== Received: by 10.180.101.8 with SMTP id fc8mr71041wib.12.1332871607404; Tue, 27 Mar 2012 11:06:47 -0700 (PDT) Received: from [192.168.0.13] (bur91-3-82-239-213-32.fbx.proxad.net. [82.239.213.32]) by mx.google.com with ESMTPS id l5sm51168255wia.11.2012.03.27.11.06.46 (version=TLSv1/SSLv3 cipher=OTHER); Tue, 27 Mar 2012 11:06:46 -0700 (PDT) Message-ID: <4F7201B0.8070702@gmail.com> Date: Tue, 27 Mar 2012 20:06:40 +0200 From: Alexandru Petrescu User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:11.0) Gecko/20120312 Thunderbird/11.0 MIME-Version: 1.0 To: mif Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: [mif] Preserving ND data structures when DHCP default route, why, command to issue X-BeenThere: mif@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multiple Interface Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 27 Mar 2012 18:06:49 -0000 In a discussion, I was shown a command line, and told that adding a default route is as simple as typing this, why bothering this much. # route add default ... I wanted then to say this below but didn't have time. # ip -6 route show default via 2002:c130:13c1:11f::ff dev eth0 proto kernel metric 1024 expires 7752sec mtu 1500 advmss 1440 hoplimit 0 ^^^^ Note that 'expires' field. If RS/RA are not used, but DHCPv6 route-option is used with 32bit lifetimes instead of 16bit lifetimes, would one think there may be a risk for that 'expires' field to overflow? Or to be understood wrongly by ND (if present), like not knowing when to send the RS to update the data? Or like simply crashing? Alex From alexandru.petrescu@gmail.com Tue Mar 27 11:20:33 2012 Return-Path: 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 A843321E80AE for ; Tue, 27 Mar 2012 11:20:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.878 X-Spam-Level: X-Spam-Status: No, score=-2.878 tagged_above=-999 required=5 tests=[AWL=0.721, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] 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 VHXV7YycBjPr for ; Tue, 27 Mar 2012 11:20:32 -0700 (PDT) Received: from mail-wg0-f44.google.com (mail-wg0-f44.google.com [74.125.82.44]) by ietfa.amsl.com (Postfix) with ESMTP id 633CF21E808D for ; Tue, 27 Mar 2012 11:20:32 -0700 (PDT) Received: by wgbdr13 with SMTP id dr13so139839wgb.13 for ; Tue, 27 Mar 2012 11:20:31 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:subject:references :in-reply-to:content-type:content-transfer-encoding; bh=92HvLVz8bzcTQptnZOubGi3WKczEgkMC/yzHGbMIR0Y=; b=oYBFiWzDZ3YsRV1TQunrRef3Ywd2qVCguaF119xOIakCLTJZ9ki/GNTtX1MRl9TzA9 GNHMspyEEt8zTpYBaAaWLMXHJ6zL33Qy1OM92F8FNuXBUr5xwu4V6T8HNBx8hih9DEdb y19H4DxIHswe1vZtYb9ne107NVoAgv3fzGDMzZ2OUGLWe6mfAkhXD62pfHWgucS7mLF+ 7TjIjCyjbj4td3cu1ve2+CDMAO4U8KaEusP9YS7KGd5vo99UUdb81W+rjpTh39jXDhUY UT/xDrHWuUFNu/OVXaNpcx7M5bbC19r2pO0BCieweqR6NX1GM1tYNk0qUNdD3j9d+/cC 2cTw== Received: by 10.216.135.223 with SMTP id u73mr15174918wei.117.1332872431423; Tue, 27 Mar 2012 11:20:31 -0700 (PDT) Received: from [192.168.0.13] (bur91-3-82-239-213-32.fbx.proxad.net. [82.239.213.32]) by mx.google.com with ESMTPS id ff2sm2157586wib.9.2012.03.27.11.20.29 (version=TLSv1/SSLv3 cipher=OTHER); Tue, 27 Mar 2012 11:20:30 -0700 (PDT) Message-ID: <4F7204E8.2080806@gmail.com> Date: Tue, 27 Mar 2012 20:20:24 +0200 From: Alexandru Petrescu User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:11.0) Gecko/20120312 Thunderbird/11.0 MIME-Version: 1.0 To: mif@ietf.org References: <20120224101611.22703.52041.idtracker@ietfa.amsl.com> <4F47688B.10508@gmail.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Subject: Re: [mif] draft-ietf-mif-dhcpv6-route-option-04 published X-BeenThere: mif@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multiple Interface Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 27 Mar 2012 18:20:33 -0000 Lorenzo, Let me take advantage of this. With respect to the main point you make about dealing with the draft in 6man rather than mif - to me as a commenter it makes no difference as long as it is in the Internet Area, the expertise be there, and the WG works by rules typical in that area. If 6man has cycles to take on this then why not. Some spare comments inserted below. Le 27/03/2012 17:43, Lorenzo Colitti a écrit : > On Fri, Feb 24, 2012 at 19:38, Tomek Mrugalski wrote: > >> Title : DHCPv6 Route Options Author(s) : Wojciech >> Dec Tomasz Mrugalski Tao Sun Behcet Sarikaya Filename : >> draft-ietf-mif-dhcpv6-route-option-04.txt Pages : 22 Date >> : 2012-02-24 > > > [CCing a few of the folks we had a chat with about this in Taipei] > > Hi, > > I believe this document is not appropriate to be discussed in this > working group, for two reasons: > > 1. It has almost nothing to do with multiple interfaces. Section 2 > contains text on why this document applies to "multi-homed > scenarios". However, there is nothing in this option that makes it > any more applicable to a multi-homed scenario than to a single-homed > scenario. > > At least 11 out of the 14 use cases cited (#1, #2, #3, #5, #6, #7, > #10,#11, #12, #13, and #14) are equally applicable to hosts with only > one interface. > > Further: a host needs to obtain routing information in both single > and multi-homed scenarios, and how the information is obtained > (DHCPv6, RA, HTTP, carrier pigeon) is completely orthogonal to > whether the host has one or more interfaces. In a sense I agree. Moreover, the same would be the case for a router as well. > 2. This option provides a complete replacement for the ND > functionality specified by RFC 4862 and RFC 4191, including default > routes, more-specific routes, and on-link determination. This is all > in 6man's domain. So this option should be taken to 6man. Well not quite a complete replacement. There still are a number of RA parameters absent from DHCP. MTU comes to mind but there are more when one considers the huge list of parameters and Flags in RA extensions used in other protocols. > I have a number other issues with the document as well. The use cases > do not seem particularly convincing; it seems to me that some of them > are niche use cases, some are circular arguments, and some are > specious. The long-term implications of configuring routing via DHCP, > which is a static protocol mediated by servers and suited to making > promises, instead of using dynamic information originated by routers, > does not seem to be worth it. > > But most importantly this document should be moved to 6man so that > the people who are responsible for the architecture can see it, > comment on it, and possibly reach consensus on it. In the past 30 oct 2011 the document was ran through 6man by Chairs asking for review. IIRC, one comment was on who supersedes whom (ND or DHCP) with respect to aspects like default route. I believe that comment was addressed by Authors in next versions (old versions said DHCP supersedes, new versions give advice close to what 6man wanted) - did that new version satisfy 6man commenters? Also, if more comments can come from 6man, I think it would be a good idea to run it again through it. Moving to 6man - do you mean having a Charter item in it? New presentations in subsequent meetings? Similar? Alex > > Regards, Lorenzo > > > _______________________________________________ mif mailing list > mif@ietf.org https://www.ietf.org/mailman/listinfo/mif From Ted.Lemon@nominum.com Tue Mar 27 13:31:50 2012 Return-Path: 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 4861421E80A8 for ; Tue, 27 Mar 2012 13:31:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.471 X-Spam-Level: X-Spam-Status: No, score=-106.471 tagged_above=-999 required=5 tests=[AWL=0.128, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, 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 EB-n6Z6wCDsc for ; Tue, 27 Mar 2012 13:31:49 -0700 (PDT) Received: from exprod7og120.obsmtp.com (exprod7og120.obsmtp.com [64.18.2.18]) by ietfa.amsl.com (Postfix) with ESMTP id 3D4DD21E80A7 for ; Tue, 27 Mar 2012 13:31:48 -0700 (PDT) Received: from shell-too.nominum.com ([64.89.228.229]) (using TLSv1) by exprod7ob120.postini.com ([64.18.6.12]) with SMTP ID DSNKT3IjtF+fruibSNKGuHuPreJyfpapDi8o@postini.com; Tue, 27 Mar 2012 13:31:49 PDT Received: from archivist.nominum.com (archivist.nominum.com [64.89.228.108]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "*.nominum.com", Issuer "Go Daddy Secure Certification Authority" (verified OK)) by shell-too.nominum.com (Postfix) with ESMTP id D4F631B8178 for ; Tue, 27 Mar 2012 13:31:47 -0700 (PDT) Received: from webmail.nominum.com (cas-01.win.nominum.com [64.89.228.131]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (Client CN "mail.nominum.com", Issuer "Go Daddy Secure Certification Authority" (verified OK)) by archivist.nominum.com (Postfix) with ESMTPS id CC455190064; Tue, 27 Mar 2012 13:31:47 -0700 (PDT) (envelope-from Ted.Lemon@nominum.com) Received: from MBX-02.WIN.NOMINUM.COM ([64.89.228.134]) by CAS-01.WIN.NOMINUM.COM ([64.89.228.131]) with mapi id 14.02.0247.003; Tue, 27 Mar 2012 13:31:41 -0700 From: Ted Lemon To: Alexandru Petrescu , mif Thread-Topic: [mif] Preserving ND data structures when DHCP default route, why, command to issue Thread-Index: AQHNDERjeEmQiXEK/0OoAe3TaVMXE5Z+lz4M Date: Tue, 27 Mar 2012 20:31:40 +0000 Message-ID: <8D23D4052ABE7A4490E77B1A012B6307472C409D@mbx-02.win.nominum.com> References: <4F7201B0.8070702@gmail.com> In-Reply-To: <4F7201B0.8070702@gmail.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [192.168.1.10] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [mif] Preserving ND data structures when DHCP default route, why, command to issue X-BeenThere: mif@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multiple Interface Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 27 Mar 2012 20:31:50 -0000 > # ip -6 route show > default via 2002:c130:13c1:11f::ff dev eth0 proto kernel metric 1024 > expires 7752sec mtu 1500 advmss 1440 hoplimit 0 > ^^^^ Okay, the route has a lifetime <7752s. So? > Note that 'expires' field. If RS/RA are not used, but DHCPv6 > route-option is used with 32bit lifetimes instead of 16bit lifetimes, > would one think there may be a risk for that 'expires' field to > overflow? Or to be understood wrongly by ND (if present), like not > knowing when to send the RS to update the data? Or like simply crashing? How do you think the route show command computed that value? Do you think= there's a field in a routing table entry somewhere that contains the numbe= r 7752, and a process somewhere that subtracts one from that field once eve= ry second? No, the field in the structure contains (time_t)now + 7752, an= d the route command subtracted (time_t)now from the value of the field to g= ive you the number 7752. So yes, of course there's a risk that an implementation will be broken. T= his risk exists whether the offset is 16 bits or 32 bits; it depends solely= on how soon it is before (time_t) overflows. If someone codes up a routi= ng table implementation that contains this flaw, I'm sure much lulz will co= me of it, but there is little we can do to prevent other people from making= mistakes, and making the offset smaller in the DHCP packet certainly isn't= an example of something that would have that result. From Ted.Lemon@nominum.com Tue Mar 27 13:34:17 2012 Return-Path: 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 E0B1D21E80D2 for ; Tue, 27 Mar 2012 13:34:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.473 X-Spam-Level: X-Spam-Status: No, score=-106.473 tagged_above=-999 required=5 tests=[AWL=0.126, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, 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 cf+zH+zFUEh1 for ; Tue, 27 Mar 2012 13:34:17 -0700 (PDT) Received: from exprod7og126.obsmtp.com (exprod7og126.obsmtp.com [64.18.2.206]) by ietfa.amsl.com (Postfix) with ESMTP id C395521E80D1 for ; Tue, 27 Mar 2012 13:34:16 -0700 (PDT) Received: from shell-too.nominum.com ([64.89.228.229]) (using TLSv1) by exprod7ob126.postini.com ([64.18.6.12]) with SMTP ID DSNKT3IkRdh6q8dViXZUUCo83smdsiUEarEc@postini.com; Tue, 27 Mar 2012 13:34:16 PDT Received: from archivist.nominum.com (archivist.nominum.com [64.89.228.108]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "*.nominum.com", Issuer "Go Daddy Secure Certification Authority" (verified OK)) by shell-too.nominum.com (Postfix) with ESMTP id 88FEE1B8178 for ; Tue, 27 Mar 2012 13:34:13 -0700 (PDT) Received: from webmail.nominum.com (cas-02.win.nominum.com [64.89.228.132]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (Client CN "mail.nominum.com", Issuer "Go Daddy Secure Certification Authority" (verified OK)) by archivist.nominum.com (Postfix) with ESMTPS id 807EC190064; Tue, 27 Mar 2012 13:34:13 -0700 (PDT) (envelope-from Ted.Lemon@nominum.com) Received: from MBX-02.WIN.NOMINUM.COM ([64.89.228.134]) by CAS-02.WIN.NOMINUM.COM ([64.89.228.132]) with mapi id 14.02.0247.003; Tue, 27 Mar 2012 13:34:13 -0700 From: Ted Lemon To: Alexandru Petrescu Thread-Topic: [mif] draft-ietf-mif-dhcpv6-route-option-04 published Thread-Index: AQHM8uBsQi4512i5cE6t8t5dPnex2ZZnd0OAgAACEYCABGRggIAAcFuAgAFcGoCAABh6gIAQ5pEA///UD5yAAJe8gP//tp/0 Date: Tue, 27 Mar 2012 20:34:12 +0000 Message-ID: <8D23D4052ABE7A4490E77B1A012B6307472C40AD@mbx-02.win.nominum.com> References: <20120224101611.22703.52041.idtracker@ietfa.amsl.com> <4F47688B.10508@gmail.com> <4F5E2F61.9040009@gmail.com> <611FBED3-349A-43E7-B4B9-0BC313EA4F7A@nominum.com> <4F61E04F.4020800@gmail.com> <4F636291.7060104@gmail.com> , <4F71A47C.7050906@gmail.com> <8D23D4052ABE7A4490E77B1A012B6307472C3F41@mbx-02.win.nominum.com>, <4F71FEE9.2010106@gmail.com> In-Reply-To: <4F71FEE9.2010106@gmail.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [192.168.1.10] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: mif Subject: Re: [mif] draft-ietf-mif-dhcpv6-route-option-04 published X-BeenThere: mif@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multiple Interface Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 27 Mar 2012 20:34:18 -0000 > You seem to be saying that is too short? I believe it is way too long > for a device that moves constantly. No, for a device that moves constantly, depending on route lifetimes to exp= ire will result in unhappy eyeballs. For such devices, a route might as w= ell not have an expiry time, unless it is soon, because network transition = events will invalidate the route before its lifetime expires. But of course there are devices that do not move constantly; for such devic= es, route lifetimes longer than 18 hours are reasonable, and should be supp= orted. From Ted.Lemon@nominum.com Tue Mar 27 13:45:07 2012 Return-Path: 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 9C77A21F8495 for ; Tue, 27 Mar 2012 13:45:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.475 X-Spam-Level: X-Spam-Status: No, score=-106.475 tagged_above=-999 required=5 tests=[AWL=0.125, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, 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 8FoBoyB+F8RS for ; Tue, 27 Mar 2012 13:45:07 -0700 (PDT) Received: from exprod7og125.obsmtp.com (exprod7og125.obsmtp.com [64.18.2.28]) by ietfa.amsl.com (Postfix) with ESMTP id D0D7721F848F for ; Tue, 27 Mar 2012 13:45:06 -0700 (PDT) Received: from shell-too.nominum.com ([64.89.228.229]) (using TLSv1) by exprod7ob125.postini.com ([64.18.6.12]) with SMTP ID DSNKT3Im0tYyUk1ZJrlSOvWpoxxNBtg1zWtQ@postini.com; Tue, 27 Mar 2012 13:45:06 PDT Received: from archivist.nominum.com (archivist.nominum.com [64.89.228.108]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "*.nominum.com", Issuer "Go Daddy Secure Certification Authority" (verified OK)) by shell-too.nominum.com (Postfix) with ESMTP id 86B281B809C for ; Tue, 27 Mar 2012 13:45:04 -0700 (PDT) Received: from webmail.nominum.com (cas-02.win.nominum.com [64.89.228.132]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (Client CN "mail.nominum.com", Issuer "Go Daddy Secure Certification Authority" (verified OK)) by archivist.nominum.com (Postfix) with ESMTPS id 80905190060; Tue, 27 Mar 2012 13:45:04 -0700 (PDT) (envelope-from Ted.Lemon@nominum.com) Received: from MBX-01.WIN.NOMINUM.COM ([64.89.228.133]) by CAS-02.WIN.NOMINUM.COM ([64.89.228.132]) with mapi id 14.02.0247.003; Tue, 27 Mar 2012 13:45:04 -0700 From: Ted Lemon To: Alexandru Petrescu Thread-Topic: [mif] Issue: separate specific routes from default routes? draft-ietf-mif-dhcpv6-route-option-04 Thread-Index: AQHNDEJLfFb3in7eyUqo+qNh9MTatJZ+mhkU Date: Tue, 27 Mar 2012 20:45:03 +0000 Message-ID: <8D23D4052ABE7A4490E77B1A012B6307472C40C5@mbx-02.win.nominum.com> References: <4F71AB00.2020404@gmail.com> <8D23D4052ABE7A4490E77B1A012B6307472C3F07@mbx-02.win.nominum.com>, <4F71FE2F.9050309@gmail.com> In-Reply-To: <4F71FE2F.9050309@gmail.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [192.168.1.10] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: mif Subject: Re: [mif] Issue: separate specific routes from default routes? draft-ietf-mif-dhcpv6-route-option-04 X-BeenThere: mif@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multiple Interface Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 27 Mar 2012 20:45:07 -0000 > If there are two options instead of one this encorages the implementer > to dedicate different sections in the dhcpd.conf file, and allocate a > specific keyword for _default_ route. This is something that strikes > the eye an makes him/her more cautious about what to put there in that > single place. The usability problem you describe here is not a protocol issue, but a user= interface issue. It's entirely possible that if we should decide to use = two options, some DHCP implementations will present both options using the = same user interface. So changing the underlying protocol does not address= this issue, whether it is a serious issue or not. Also, pink elephants may evolve in the future. Such elephants could poten= tially step on hosts that are attempting to configure routes. Should the = IETF henceforth mandate the presence of a Pink Elephant Considerations sect= ion in all drafts? > Hm, use cases. If I insist is that I believe there are some maybe under > development. Okay, so name one. =20 > What do the others think about this issue? I can't speak for them, but I suspect they are wishing we would both shut u= p about this and work on something useful. From brian.e.carpenter@gmail.com Tue Mar 27 15:08:10 2012 Return-Path: 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 F114521E8139 for ; Tue, 27 Mar 2012 15:08:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.599 X-Spam-Level: X-Spam-Status: No, score=-103.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, 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 pwmkLaoLwoS8 for ; Tue, 27 Mar 2012 15:08:10 -0700 (PDT) Received: from mail-iy0-f172.google.com (mail-iy0-f172.google.com [209.85.210.172]) by ietfa.amsl.com (Postfix) with ESMTP id 6DFB821E8126 for ; Tue, 27 Mar 2012 15:08:10 -0700 (PDT) Received: by iazz13 with SMTP id z13so513904iaz.31 for ; Tue, 27 Mar 2012 15:08:10 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:organization:user-agent:mime-version:to:cc :subject:references:in-reply-to:content-type :content-transfer-encoding; bh=T2JoTRt995BHYGG0iqHlb6zDXswgjGHzS8yCQstKiQs=; b=gMEp0xKDJT+cuWozIUNtWQHQlTZj1+katQ7+jIahevzhZXgQ30NkE+IVFAO99R3B4U QmuOcnJf6baHNvmxMLA6hzoUi6m5USYtC5JliWr78HxqKiH9cNao6DwCiesOFmxscrvd gY0GpIms5mrpOnpKjBMUqg0gsVEsQpm2MJ8Hkhy6myVNOw5dJsuPDsTWqsmWw86Z4WL6 7WALrK5DwxQ3ShLvdeKyxYsTsw9mAgE2jkzi5F0XCFU68yObEXzB+AeS29PAr8/LTp7/ cz2J/hxG/f76hy5+VNnMrbsaOS8a/KXVF4Z5XMAP3I6i56vZKZs7zewBVxn/nqTAZTCw TeTA== Received: by 10.50.219.199 with SMTP id pq7mr425119igc.70.1332886087011; Tue, 27 Mar 2012 15:08:07 -0700 (PDT) Received: from [192.168.182.29] (122-57-150-118.jetstream.xtra.co.nz. [122.57.150.118]) by mx.google.com with ESMTPS id wf10sm13499847igb.8.2012.03.27.15.08.02 (version=SSLv3 cipher=OTHER); Tue, 27 Mar 2012 15:08:06 -0700 (PDT) Message-ID: <4F723A39.3070201@gmail.com> Date: Wed, 28 Mar 2012 11:07:53 +1300 From: Brian E Carpenter Organization: University of Auckland User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: Lorenzo Colitti References: <20120224101611.22703.52041.idtracker@ietfa.amsl.com> <4F47688B.10508@gmail.com> In-Reply-To: Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: Thomas Narten , Brian Haberman , mif@ietf.org, Ron Bonica , Ted Lemon Subject: Re: [mif] draft-ietf-mif-dhcpv6-route-option-04 published X-BeenThere: mif@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multiple Interface Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 27 Mar 2012 22:08:11 -0000 On 2012-03-28 04:43, Lorenzo Colitti wrote: ... > > But most importantly this document should be moved to 6man so that the > people who are responsible for the architecture can see it, comment on it, > and possibly reach consensus on it. On balance I agree. MIF is a potential *customer* for this mechanism, and the same applies to homenet and probably others. Brian From brian.e.carpenter@gmail.com Tue Mar 27 15:16:24 2012 Return-Path: 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 A3BC321E8085 for ; Tue, 27 Mar 2012 15:16:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.599 X-Spam-Level: X-Spam-Status: No, score=-103.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, 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 394ms3KYX4DV for ; Tue, 27 Mar 2012 15:16:24 -0700 (PDT) Received: from mail-iy0-f172.google.com (mail-iy0-f172.google.com [209.85.210.172]) by ietfa.amsl.com (Postfix) with ESMTP id 1A2C621E8011 for ; Tue, 27 Mar 2012 15:16:24 -0700 (PDT) Received: by iazz13 with SMTP id z13so523533iaz.31 for ; Tue, 27 Mar 2012 15:16:23 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:organization:user-agent:mime-version:to:cc :subject:references:in-reply-to:content-type :content-transfer-encoding; bh=EYGEtYdKIDp7uO6ewn5UfWcGb5BaN8GsfMjCMlVJfIw=; b=O6MSO5yJLU+IieKrUDWpPSLrYtSptQkutvJqdQSUl2Wh/ZqBEfUW2yZ86ymbThnOkG a7JWS2sNEYzEquP42JjKSLJXyB8ZBsajRHrOR6xH52T+/WZ3flKbSFEHNXfwouIRmyH7 nCjcdvW+izPfAvcAnqSxsjfAqIVe1lMyGNrvm7zbK47igJ67ruJdP/njcEz6BoV6LQsY wSsn+qgThD3tqzTgcTQNe5TysSLX7NYIqN9EQ0pJ57lZtZoNnBnitVFDZzf9bqmYdNYH JvuJiw+OfTdh/cAd6lEZDA0s2xkBNSKAJHNPMBGrBA12WdpNlTetO8cCRbM7sW2wVjM0 Y2Ag== Received: by 10.50.183.137 with SMTP id em9mr535281igc.58.1332886583781; Tue, 27 Mar 2012 15:16:23 -0700 (PDT) Received: from [192.168.182.29] (122-57-150-118.jetstream.xtra.co.nz. [122.57.150.118]) by mx.google.com with ESMTPS id l9sm1001369iga.6.2012.03.27.15.16.13 (version=SSLv3 cipher=OTHER); Tue, 27 Mar 2012 15:16:16 -0700 (PDT) Message-ID: <4F723C26.4040105@gmail.com> Date: Wed, 28 Mar 2012 11:16:06 +1300 From: Brian E Carpenter Organization: University of Auckland User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: Erik Kline References: <4F71B306.1080509@gmail.com> <4F71B3EA.1000104@moth.iki.fi> <8D23D4052ABE7A4490E77B1A012B6307472C3E95@mbx-02.win.nominum.com> In-Reply-To: Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: "mif@ietf.org" Subject: Re: [mif] Issue: Only _one_ default route? draft-ietf-mif-dhcpv6-route-option-04 X-BeenThere: mif@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multiple Interface Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 27 Mar 2012 22:16:24 -0000 On 2012-03-28 04:30, Erik Kline wrote: > On 27 March 2012 15:26, Ted Lemon wrote: >>> Is also the following configuration out of scope for this group? >>> - a home network with TWO ISP's providing connection >>> - both without knowledge of each other >>> - both send default and specific route(s) (RA or DHCP) >>> IMHO, my home desktop should really be able to handle >>> this too (router selection needs to consider which source >>> address was picked from which router). >> Yes, this seems to be in scope to me. I think you should submit a draft, since you've described both the problem and the solution quite well. You are describing the "two provisioning domains" scenario, FWIW. The phrase "more than one default route" on its own makes my head hurt, given the normal meaning in computer science of the word "default". One default route per source prefix in use makes perfect sense, in view of the need for address pair selection and ingress-filtering avoidance. (When I think about it, a default route even makes sense for a ULA prefix.) > Submit to 6man, I think. Clearly - the customers for this include MIF, homenet and shim6 to name only three. Brian Brian From brian.e.carpenter@gmail.com Tue Mar 27 15:19:51 2012 Return-Path: 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 275DA21E8085 for ; Tue, 27 Mar 2012 15:19:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.599 X-Spam-Level: X-Spam-Status: No, score=-103.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, 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 3ZPqMHEnIgG1 for ; Tue, 27 Mar 2012 15:19:50 -0700 (PDT) Received: from mail-iy0-f172.google.com (mail-iy0-f172.google.com [209.85.210.172]) by ietfa.amsl.com (Postfix) with ESMTP id AD8D421E8011 for ; Tue, 27 Mar 2012 15:19:50 -0700 (PDT) Received: by iazz13 with SMTP id z13so528161iaz.31 for ; Tue, 27 Mar 2012 15:19:50 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:organization:user-agent:mime-version:to:cc :subject:references:in-reply-to:content-type :content-transfer-encoding; bh=T3bqjiQShK3bbEZ3tw5zOYYjR6ZMrQ+IpfUNwZ4wInQ=; b=VPPxOs+s9XIw/6Ros8Hndv2KEQcad+O71C8IZMzlJgO2IdvlQQhvJ0m8rssAUYHouV OWJuRnJdV34QK4vniCt0BbHavWaVAISiOGq0dwvfnw313BhYt6u3ZjmNBmyifvolKz02 x+O+8IA1cXwmvjrmN9lKNc+bJdcmXNbETSkpwqBGBwGPhMWl0eGdgXIzxbF9EVrfFEC3 Qn46fEOC1NoO1vDWhEWKu/3TWdgu9M38SrKlgQ1YApig5io3a0XvqVju51BOmQdP4iig IA2dzXWqpX36dYbPsf5XljJKO63z0UQOBtiLIFWzB1yz2VMHHUotVmANS/I0oZOmg0vg 8FTg== Received: by 10.50.217.137 with SMTP id oy9mr531649igc.31.1332886790422; Tue, 27 Mar 2012 15:19:50 -0700 (PDT) Received: from [192.168.182.29] (122-57-150-118.jetstream.xtra.co.nz. [122.57.150.118]) by mx.google.com with ESMTPS id c2sm1024232igj.1.2012.03.27.15.19.47 (version=SSLv3 cipher=OTHER); Tue, 27 Mar 2012 15:19:49 -0700 (PDT) Message-ID: <4F723CFE.4030207@gmail.com> Date: Wed, 28 Mar 2012 11:19:42 +1300 From: Brian E Carpenter Organization: University of Auckland User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: Alexandru Petrescu References: <4F71AB00.2020404@gmail.com> <8D23D4052ABE7A4490E77B1A012B6307472C3F07@mbx-02.win.nominum.com> <4F71FE2F.9050309@gmail.com> In-Reply-To: <4F71FE2F.9050309@gmail.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: mif Subject: Re: [mif] Issue: separate specific routes from default routes? draft-ietf-mif-dhcpv6-route-option-04 X-BeenThere: mif@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multiple Interface Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 27 Mar 2012 22:19:51 -0000 On 2012-03-28 06:51, Alexandru Petrescu wrote: ... > What do the others think about this issue? A default route is simply the route with the shortest prefix that matches. I don't see any real value in treating it as special in the route delivery mechanism. Brian From brian.e.carpenter@gmail.com Tue Mar 27 15:25:07 2012 Return-Path: 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 A54E621E80FD for ; Tue, 27 Mar 2012 15:25:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.599 X-Spam-Level: X-Spam-Status: No, score=-103.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, 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 uhdg-FmNIOPN for ; Tue, 27 Mar 2012 15:25:06 -0700 (PDT) Received: from mail-iy0-f172.google.com (mail-iy0-f172.google.com [209.85.210.172]) by ietfa.amsl.com (Postfix) with ESMTP id 79BCE21F86CA for ; Tue, 27 Mar 2012 15:24:45 -0700 (PDT) Received: by iazz13 with SMTP id z13so534563iaz.31 for ; Tue, 27 Mar 2012 15:24:45 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:organization:user-agent:mime-version:to:cc :subject:references:in-reply-to:content-type :content-transfer-encoding; bh=H0gdKGRVFl61o4hM0PjrhFtcpe7fmpWM0DLU62egvIY=; b=Yd5/p17fIPCQeBW07su+TBx/7At56xIyC93LNV2LEd2ubCqYYN16NJcbWQ66toW2kn 8Fp6uK/OiJV8NvfYz7kdNQG0mLIfbPH3unkST3VrNrCBSUeNsCwGZNYwC3+/H3vGbQ/B ZLe1NU6xyb6ldk4yuEi9XKUCIwU1+RNC2JwfrI040rfcL8Soxi1vckpcEBGAXk7lw7hv iXWtKx3O+9+xYoAqqbfiOmPVmWG96k30Dt9WSJK8+fyGO0GLxfo3lkE7MVnwAABcbQeP U3PSzFVQawPZ3GVdDvCoA5oiIWtZXKmy8rF7RIt8lOUj0iJkiUs4xNT9NWuh+Thmk+CF N8dg== Received: by 10.50.214.36 with SMTP id nx4mr596733igc.2.1332887084973; Tue, 27 Mar 2012 15:24:44 -0700 (PDT) Received: from [192.168.182.29] (122-57-150-118.jetstream.xtra.co.nz. [122.57.150.118]) by mx.google.com with ESMTPS id b11sm1019261igq.7.2012.03.27.15.24.42 (version=SSLv3 cipher=OTHER); Tue, 27 Mar 2012 15:24:44 -0700 (PDT) Message-ID: <4F723E25.2030303@gmail.com> Date: Wed, 28 Mar 2012 11:24:37 +1300 From: Brian E Carpenter Organization: University of Auckland User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: Alexandru Petrescu References: <4F71AE51.4000304@gmail.com> <8D23D4052ABE7A4490E77B1A012B6307472C3EB0@mbx-02.win.nominum.com> <4F71FCFE.7080002@gmail.com> In-Reply-To: <4F71FCFE.7080002@gmail.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: mif Subject: Re: [mif] Issue: absent MAC address of default route? draft-ietf-mif-dhcpv6-route-option-04 X-BeenThere: mif@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multiple Interface Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 27 Mar 2012 22:25:07 -0000 On 2012-03-28 06:46, Alexandru Petrescu wrote: ... > In lightweight environments, and this is a MIF-ed router not host, it > would only run DHCP and maybe no ND You can't conform to IPv6 and not run ND. In answer to your original question: no. KISS. Don't overload DHCPv6 with a function that is part of IPv6's basic mechanism (i.e. ND). Brian From tomasz.mrugalski@gmail.com Tue Mar 27 23:47:48 2012 Return-Path: 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 07A0421E812D for ; Tue, 27 Mar 2012 23:47:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] 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 NcLQduD+3OSW for ; Tue, 27 Mar 2012 23:47:47 -0700 (PDT) Received: from mail-ey0-f172.google.com (mail-ey0-f172.google.com [209.85.215.172]) by ietfa.amsl.com (Postfix) with ESMTP id AC0B721E8126 for ; Tue, 27 Mar 2012 23:47:46 -0700 (PDT) Received: by eaaq11 with SMTP id q11so160019eaa.31 for ; Tue, 27 Mar 2012 23:47:46 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:subject:references :in-reply-to:x-enigmail-version:content-type :content-transfer-encoding; bh=O31KjyTfgg6K0Me5+d5P/rgYT7gJSJNbW9atjBPfiLU=; b=veqLcrYcrHRnxjEiZ4VhJLQq59MHRpjAff2vik9DgPRC3tfqYLxuezBHHRzeGao2zA +l+BCS/adBNvPhWTwvWXpvLp3RLmZwb0slFTKXF+b2xlp392zZOIX0sxEOnwcqCked2W xuh+/2gllcfRHDf5+eLNPtvXg5hbkpygt4dk4F+cT9JZw0f7R3rmq0xLz0mAIVDogStO 52yxQ6psgJsQVxkApKWOvU506zN1+GmDHxSF+ql2IHqp8qbZwcXkD9Nvuf/kRG+hTHA+ NuVEuz43JPd132eWo/g7fHJnp2bEKYYXl14unvtFOyYZJkmYyNDmD82I34xsKM4sL7gp RWDA== Received: by 10.14.133.10 with SMTP id p10mr3924077eei.36.1332917265886; Tue, 27 Mar 2012 23:47:45 -0700 (PDT) Received: from dhcp-158e.meeting.ietf.org ([2001:df8:0:16:cabc:c8ff:fedf:daff]) by mx.google.com with ESMTPS id m42sm7128335eef.0.2012.03.27.23.47.44 (version=SSLv3 cipher=OTHER); Tue, 27 Mar 2012 23:47:45 -0700 (PDT) Message-ID: <4F72B40F.6050303@gmail.com> Date: Wed, 28 Mar 2012 08:47:43 +0200 From: Tomek Mrugalski User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:10.0.2) Gecko/20120216 Thunderbird/10.0.2 MIME-Version: 1.0 To: mif@ietf.org References: <4F71AB00.2020404@gmail.com> In-Reply-To: <4F71AB00.2020404@gmail.com> X-Enigmail-Version: 1.4 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: Re: [mif] Issue: separate specific routes from default routes? draft-ietf-mif-dhcpv6-route-option-04 X-BeenThere: mif@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multiple Interface Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 28 Mar 2012 06:47:48 -0000 On 12-03-27 13:56, Alexandru Petrescu wrote: > Dear participants in MIF WG, > > Currently draft-ietf-mif-dhcpv6-route-option-04 specifies a way for the > DHCPv6 Server to communicate a set of routes to the DHCPv6 Client. This > covers both specific routes and the particular case of default routes (a > default route is meant when the RT_PREFIX option is absent, or > alternatively by using 128 0 bits as RT_PREFIX). > > I think this is an issue. > > It's not good to have two different things to achieve the same > functionality. Agree. There used to be two ways of specifying default route (in -03), but this capability was removed. The original reason for having two ways of configuring the issue is well known to you as you suggested it in the first place. It was an attempt to solve your concerns about sent information being too big. As we modified prefix encoding to variable prefix field size option size is no longer a concern. Unfortunately, I missed one sentence that still suggest that. It will be removed in -05. Just be clear: sending only NEXT_HOP option without RT_PREFIX is not longer supported. Each NEXT_HOP MUST have at least one RT_PREFIX option. > Second, using default routes in the same option type of specific routes > means that they'd share the same faith - if specific routes are wrongly > configured in the same section of the config file, there is a risk that > the default route is wrongly configured too. Or, the default route is > something of last resort, so it would be better to have it configured in > a different place, communicated with a different ORO type. That argument is bogus. If your network administrator can't type ::/0, you should get a new admin. Some implementations may also accept word "default" in its configuration. > Third, if a single way of configuring default an specific routes with > DHCP then this means that a bigger software implementation would be > needed even for lightweight devices. Or, lightweight devices only use a > single route - the default route. My understanding is that all nodes that claim to be IPv6 compatible, must support ICMP Redirects, as defined in RFC4861. This implies required support for more than just a default route. > I suggest we separate the default route ORO from the specific routes ORO. You meant option, I assume. ORO (Option Request Option) is for requesting other options. Cheers, Tomek From tomasz.mrugalski@gmail.com Wed Mar 28 00:09:35 2012 Return-Path: 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 C26F021E8161 for ; Wed, 28 Mar 2012 00:09:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] 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 Bh8AIHwtTdHZ for ; Wed, 28 Mar 2012 00:09:35 -0700 (PDT) Received: from mail-ey0-f172.google.com (mail-ey0-f172.google.com [209.85.215.172]) by ietfa.amsl.com (Postfix) with ESMTP id CB9BC21E80E3 for ; Wed, 28 Mar 2012 00:09:34 -0700 (PDT) Received: by eaaq11 with SMTP id q11so164854eaa.31 for ; Wed, 28 Mar 2012 00:09:31 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:subject:references :in-reply-to:x-enigmail-version:content-type :content-transfer-encoding; bh=XpmRf9nPBpb44cgXIVPlY9sf92s1mh4JBEeqLsyIuGY=; b=MhqT+K6FiOKonR2AXo476HfnGv1Z+T2BvtFM+Y+7yhic0qfFaDXSOWtu6K119s/n4+ yuWv5jSn7RGaYhVZ6EdWhWst7PK1OPzFj1qMyZKXAfGnBnGYqmv0eU4oAwNrWmZzTxvr AJjHpLBxNjGCHaFUhqga99LDgMwFLAcCqy2wOKvqV9Mg07B+KGI4maViQaQtweVLpRRJ cz1iEjfrNq9HYvK8+awsmkkid01x+Dr8ZZxgMbVHv0iBqO5sEemPgp2H+ZUeq0S4ejgp 4wXYGPrBess1I3qwVXdiqkmpCKuaINtr8TfsmzkqXJNtblR+pTpp/2m8ATjZcZ0pkljX uoGA== Received: by 10.14.127.204 with SMTP id d52mr3867773eei.18.1332918570987; Wed, 28 Mar 2012 00:09:30 -0700 (PDT) Received: from dhcp-158e.meeting.ietf.org ([2001:df8:0:16:cabc:c8ff:fedf:daff]) by mx.google.com with ESMTPS id d54sm7201665eei.9.2012.03.28.00.09.30 (version=SSLv3 cipher=OTHER); Wed, 28 Mar 2012 00:09:30 -0700 (PDT) Message-ID: <4F72B929.7030204@gmail.com> Date: Wed, 28 Mar 2012 09:09:29 +0200 From: Tomek Mrugalski User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:10.0.2) Gecko/20120216 Thunderbird/10.0.2 MIME-Version: 1.0 To: mif@ietf.org References: <4F71B21B.3040907@gmail.com> In-Reply-To: <4F71B21B.3040907@gmail.com> X-Enigmail-Version: 1.4 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: Re: [mif] Issue: message size for communicating the default route? draft-ietf-mif-dhcpv6-route-option-04 X-BeenThere: mif@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multiple Interface Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 28 Mar 2012 07:09:35 -0000 On 12-03-27 14:27, Alexandru Petrescu wrote: > Dear participants in MIF WG, > > Currently draft-ietf-mif-dhcpv6-route-option-04 specifies that when > communicating a default route, the minimal message size (RT_PREFIX > option absent) is 46 bytes (Next Hop Option 20bytes, Route Prefix Option > 26bytes). Please re-read the draft, section 5.2. Note that prefix field itself is variable and its size depends on prefix-length. You seem to be interested in low-capability devices. Assuming you use route option to configure just default route, Route Prefix option is 10 bytes long, so the total is 30, not 46 bytes. > Sometimes the draft says this Route Prefix Option may be absent for > default routes, thus total length could be 20bytes. The ability to skip Route Prefix Option used to be allowed, but that is not the case anymore. As I mentioned, there is still text that was missed during the last series of updates and it will be removed in -05. Tomek From tomasz.mrugalski@gmail.com Wed Mar 28 00:18:27 2012 Return-Path: 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 A2A8321E817B for ; Wed, 28 Mar 2012 00:18:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] 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 CD2-bFYqmBkb for ; Wed, 28 Mar 2012 00:18:27 -0700 (PDT) Received: from mail-ey0-f172.google.com (mail-ey0-f172.google.com [209.85.215.172]) by ietfa.amsl.com (Postfix) with ESMTP id D9CD421E813E for ; Wed, 28 Mar 2012 00:18:26 -0700 (PDT) Received: by eaaq11 with SMTP id q11so167085eaa.31 for ; Wed, 28 Mar 2012 00:18:26 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:subject:references :in-reply-to:x-enigmail-version:content-type :content-transfer-encoding; bh=xx7fu/vlH3tb2ntF2pviA0DOtXZueoAtyVsk+5Qnr7E=; b=sUefMhkZV5jLBFHpCzKdoDHOGPp+GUvjHCWqSqwTmbej5coc1IxxfVR10I9sXPBuTQ lLnS9S6fNsL6EoBHy4beZmIHQsxI4r/YibmFiiCQ2Gv1at23GT/t6c96OXRiqY4BVnTb 3C7NdZHChSx/Dv1jjiS5BIWaFpWMnTBTO8kwpzZUo9i1RZs1YdaoRXgNHOI0Nma/GWl+ FD0+AGtwk3UsUJgxeFUwInwtI4+lp2gomSmBitBuQ2+aZ3B29vjZdnOq5sO3cfmpdRFt uJMP2lBZ4Bkr4pq8vB9E8lltJt4onx929EKZBETTU3eD3nDEoGpVmBrmwTy6iuIjDSLI PkUw== Received: by 10.213.32.78 with SMTP id b14mr1988704ebd.151.1332919105836; Wed, 28 Mar 2012 00:18:25 -0700 (PDT) Received: from dhcp-158e.meeting.ietf.org ([2001:df8:0:16:cabc:c8ff:fedf:daff]) by mx.google.com with ESMTPS id p57sm7285920eei.8.2012.03.28.00.18.24 (version=SSLv3 cipher=OTHER); Wed, 28 Mar 2012 00:18:25 -0700 (PDT) Message-ID: <4F72BB40.6010003@gmail.com> Date: Wed, 28 Mar 2012 09:18:24 +0200 From: Tomek Mrugalski User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:10.0.2) Gecko/20120216 Thunderbird/10.0.2 MIME-Version: 1.0 To: mif@ietf.org References: <4F71AE51.4000304@gmail.com> <8D23D4052ABE7A4490E77B1A012B6307472C3EB0@mbx-02.win.nominum.com> <4F71FCFE.7080002@gmail.com> <4F723E25.2030303@gmail.com> In-Reply-To: <4F723E25.2030303@gmail.com> X-Enigmail-Version: 1.4 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: Re: [mif] Issue: absent MAC address of default route? draft-ietf-mif-dhcpv6-route-option-04 X-BeenThere: mif@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multiple Interface Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 28 Mar 2012 07:18:27 -0000 On 12-03-28 00:24, Brian E Carpenter wrote: > On 2012-03-28 06:46, Alexandru Petrescu wrote: > ... >> In lightweight environments, and this is a MIF-ed router not host, it >> would only run DHCP and maybe no ND > > You can't conform to IPv6 and not run ND. > > In answer to your original question: no. KISS. Don't overload DHCPv6 > with a function that is part of IPv6's basic mechanism (i.e. ND). +1 (Actually, all co-authors agree, so theoretically that is +4, but please count it as my personal opinion only). Tomek From tomasz.mrugalski@gmail.com Wed Mar 28 00:21:24 2012 Return-Path: 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 7F4C321E8181 for ; Wed, 28 Mar 2012 00:21:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] 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 57ZZbbwMSlmK for ; Wed, 28 Mar 2012 00:21:24 -0700 (PDT) Received: from mail-ey0-f172.google.com (mail-ey0-f172.google.com [209.85.215.172]) by ietfa.amsl.com (Postfix) with ESMTP id B8FFC21E817B for ; Wed, 28 Mar 2012 00:21:23 -0700 (PDT) Received: by eaaq11 with SMTP id q11so167896eaa.31 for ; Wed, 28 Mar 2012 00:21:23 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:subject:references :in-reply-to:x-enigmail-version:content-type :content-transfer-encoding; bh=i32EPraPJ94GnUH3j6uY0UjAhOBuuQ03Tt5dYp9Mv1c=; b=AX7yjjmdTPKjV7OE9t6Oqy4Zv4zlmv1WeFNt8Q3s3meQ/U3r2nslkS72pk+TZN1AiH jFoGcpcmYvMSQ69tnvV4/4DTNohHcyXj7jhAVFGBXrc7b+S++MxC7j4W8anpluggkAXH H4z6AsF+HTaU2e0vYVmK4i/++RLAzwPA92CP2Vm7n8/kbPyLSf56tV0HaUvHqeq7s3di O2/a1zrKr/DumFbWrc6zgOH5b6x0miP6ufwDBp2nPm1AmUli+6K646IZ/wJslCEIKHfk 8L7xqatxoKBdgNsQO4Pj++nJPVrPrXqVDsRYe+eEONTErju0hyMPIbvrqjkd8kTIJRgE 3Y6w== Received: by 10.213.21.211 with SMTP id k19mr1915157ebb.292.1332919282975; Wed, 28 Mar 2012 00:21:22 -0700 (PDT) Received: from dhcp-158e.meeting.ietf.org ([2001:df8:0:16:cabc:c8ff:fedf:daff]) by mx.google.com with ESMTPS id d54sm7300364eei.9.2012.03.28.00.21.22 (version=SSLv3 cipher=OTHER); Wed, 28 Mar 2012 00:21:22 -0700 (PDT) Message-ID: <4F72BBF1.1080408@gmail.com> Date: Wed, 28 Mar 2012 09:21:21 +0200 From: Tomek Mrugalski User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:10.0.2) Gecko/20120216 Thunderbird/10.0.2 MIME-Version: 1.0 To: mif@ietf.org References: <4F71AE51.4000304@gmail.com> In-Reply-To: X-Enigmail-Version: 1.4 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: Re: [mif] Issue: absent MAC address of default route? draft-ietf-mif-dhcpv6-route-option-04 X-BeenThere: mif@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multiple Interface Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 28 Mar 2012 07:21:24 -0000 On 12-03-27 17:52, William Herrin wrote: > On Tue, Mar 27, 2012 at 8:10 AM, Alexandru Petrescu > If added, I think it should be non-authoritative. That is, the > receiving host can use it briefly to get a jump start on communication > but is expected to promptly perform an ND request for the > authoritative MAC. This would allow a host to recover gracefully in > the inevitable event that the DHCP server and router get out of sync > about the router's MAC address. No, we do not plan adding MAC field. That would give us nothing, but would bring a lot of troubles. In particular, the problem of MAC being mis-configured or becoming out of sync. ND is a good protocol for that purpose and is supported by all devices that claim IPv6 compatibility, so we plan to use it. Tomek From lorenzo@google.com Wed Mar 28 01:34:19 2012 Return-Path: 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 BFF5A21F88C3 for ; Wed, 28 Mar 2012 01:34:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.825 X-Spam-Level: X-Spam-Status: No, score=-102.825 tagged_above=-999 required=5 tests=[AWL=0.151, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1, 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 aX7T0PAq0C1L for ; Wed, 28 Mar 2012 01:34:19 -0700 (PDT) Received: from mail-ob0-f172.google.com (mail-ob0-f172.google.com [209.85.214.172]) by ietfa.amsl.com (Postfix) with ESMTP id 242A221F88B0 for ; Wed, 28 Mar 2012 01:34:18 -0700 (PDT) Received: by obbtb4 with SMTP id tb4so1207905obb.31 for ; Wed, 28 Mar 2012 01:34:18 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type:x-system-of-record; bh=QD41g6TWJks4lhfCdqvNkJ39MopaD9PGrrPFn+9KOfo=; b=hLby/dComJ2MrHU6siPNw8rdg0Z/Z525Vrp9e7GVbi228WawHGV3ArI7d406XT7fZh ++54n4O+AWegWM/qzYg/iNFU5WobmGxzEZ0z5197ktAPZP3BQ/5Roa+93crieOtYfP1E blTjyfyXBd4M5dJh+gyIgc6YbcoruN1sUF99CFbXk9pTBcwypPbozilSKqvqSiWS7VDo zu6qgfWuZdyuXOkjPF+rQTc99Gat/pf9zQtseDjvVn+t6hswbIFDO/mASggZnP8MAOe4 ANC9PX7C2UnESXarJsCvioErnFEomZaq23GT7z2KFzWTkaRODV5FMxVXv1hDcBK2YGT2 Ui3A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type:x-system-of-record:x-gm-message-state; bh=QD41g6TWJks4lhfCdqvNkJ39MopaD9PGrrPFn+9KOfo=; b=KB/KErxv+b2o4ddpDQae5XQUGW15wLKg9w++opEGIacctLIDa+fGdvM1WCN0DlpmZ8 sxHpNI6bE66QPK3/kyjDrB+J9jHvFnqNfCBwQ7QGuvxm0EsfIzbdZiiNxkU8LdnasUKa PTf+yKcQGTRdxe1YQFC972MJLUkf3mHrRmURVmCecpScTgbBiMOAbNXiUx3z4hOntfmQ Z+9gn5UdKNbA7vtaFujheKY3uL4vNMABpC9absndOD2BM2AsaZM5EbP0evS31eifJTrr Pv6UHf48z1KIBaCwq+y8KvVvEbct/1IaapW1PGAZd09l5wgJdul5QiU1Hj6Ye44pVhGp knNQ== Received: by 10.60.0.226 with SMTP id 2mr36215785oeh.18.1332923658489; Wed, 28 Mar 2012 01:34:18 -0700 (PDT) Received: by 10.60.0.226 with SMTP id 2mr36215764oeh.18.1332923658365; Wed, 28 Mar 2012 01:34:18 -0700 (PDT) MIME-Version: 1.0 Received: by 10.182.63.231 with HTTP; Wed, 28 Mar 2012 01:33:58 -0700 (PDT) In-Reply-To: <4F723C26.4040105@gmail.com> References: <4F71B306.1080509@gmail.com> <4F71B3EA.1000104@moth.iki.fi> <8D23D4052ABE7A4490E77B1A012B6307472C3E95@mbx-02.win.nominum.com> <4F723C26.4040105@gmail.com> From: Lorenzo Colitti Date: Wed, 28 Mar 2012 10:33:58 +0200 Message-ID: To: Brian E Carpenter Content-Type: multipart/alternative; boundary=e89a8fb1fbc62b6b3904bc4979e8 X-System-Of-Record: true X-Gm-Message-State: ALoCoQmjfi71ygKSKmFgZls8aKCbS+tZMj8a6c0dti38fvlcr3uiy0CbH9X8yHs+zm2JHD7CjniQgntznPYbMGqsqr/L/dAJC7uD4ZA1C5e33r1hJT13L4ws44A7SdA0nffFfEitY2hK Cc: "mif@ietf.org" Subject: Re: [mif] Issue: Only _one_ default route? draft-ietf-mif-dhcpv6-route-option-04 X-BeenThere: mif@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multiple Interface Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 28 Mar 2012 08:34:19 -0000 --e89a8fb1fbc62b6b3904bc4979e8 Content-Type: text/plain; charset=ISO-8859-1 On Wed, Mar 28, 2012 at 00:16, Brian E Carpenter < brian.e.carpenter@gmail.com> wrote: > The phrase "more than one default route" on its own makes my head hurt, > given the normal meaning in computer science of the word "default". > > One default route per source prefix in use makes perfect sense, in view > of the need for address pair selection and ingress-filtering avoidance. > (When I think about it, a default route even makes sense for a ULA prefix.) No, multiple default routes make sense even when they're not source-specific. For example, they make sense when you have two routers and one of them can go down. Remember that a route includes a next-hop, and that RFC 4861 defines a default router list (which is a list of possible next-hops for the default route). --e89a8fb1fbc62b6b3904bc4979e8 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
On Wed, Mar 28, 2012 at 00:16, Brian E Carpenter= <brian= .e.carpenter@gmail.com> wrote:
The phrase "more than one default route" on its= own makes my head hurt,
given the normal meaning in computer science of the word "default"= ;.

One default route per source prefix in use makes perfect sense, in view
of the need for address pair selection and ingress-filtering avoidance.
(When I think about it, a default route even makes sense for a ULA prefix.)=

No, multiple default routes make sense eve= n when they're not source-specific. For example, they make sense when y= ou have two routers and one of them can go down. Remember that a route incl= udes a next-hop, and that RFC 4861 defines a default router list (which is = a list of possible next-hops for the default route).
--e89a8fb1fbc62b6b3904bc4979e8-- From lorenzo@google.com Wed Mar 28 01:55:27 2012 Return-Path: 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 ADC0B21F8995 for ; Wed, 28 Mar 2012 01:55:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.534 X-Spam-Level: X-Spam-Status: No, score=-102.534 tagged_above=-999 required=5 tests=[AWL=-0.158, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, J_CHICKENPOX_13=0.6, RCVD_IN_DNSWL_LOW=-1, 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 KY-L5Z1FNTvU for ; Wed, 28 Mar 2012 01:55:27 -0700 (PDT) Received: from mail-ob0-f172.google.com (mail-ob0-f172.google.com [209.85.214.172]) by ietfa.amsl.com (Postfix) with ESMTP id 48ADB21F899C for ; Wed, 28 Mar 2012 01:55:26 -0700 (PDT) Received: by obbtb4 with SMTP id tb4so1236879obb.31 for ; Wed, 28 Mar 2012 01:55:25 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type:x-system-of-record; bh=3lQCnMEy7YzrtQlosdMH6LmfVxUTL2c3QTFg4O62jS4=; b=U+S2UznN55bDSo+wICpRNOAJOHmYJypNG9i2HsOpFcKAF7qYt4sCGM2W7wOLf9HlPg bjTxX3+Gs/1+XJi0cXasB5LrEpLnAQRHHF5TqQ7XRco/iKjhX/vFRLQnX8lBgu8xg8EV uJBjXn/L/iGYayFLd3J8lnlapivC6orBeuoZtDT121ehsxsmwcJ3RXpfrikaztPFD8fX 26SWa70ok37V3gzbW/X2QquZE3UURjlWGPNnGMNVEGcFUVhVJdy121ES88EyoZz07YU9 zULUDz0n+6ZX8KiDIQj7ffL+M1CCZ5WAgGyey57dKmYtPGxfYzj8snsrHjhcti7w7rQ4 s/Hg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type:x-system-of-record:x-gm-message-state; bh=3lQCnMEy7YzrtQlosdMH6LmfVxUTL2c3QTFg4O62jS4=; b=gLljbPCHUaM7bwHOru6uyunyxHV0TobeVYxncNlXUD94KUoExFd8MMgN6+VyivFtaM WW+qQSVXZPD+VYfH1TtFCtG88WkXSAdONYnoo4ZFWJtF+DUpa4jdIKAE1SbtRB0VoeeM bFe452VlOVgqY7hzaxJ6QhLbu0hXbenS18c2vPKzko0SPbTM7wO7ye00jOU830jlgrdn d6kQ3S5TYVOp5F06DArfoxdBZI+RWA7gp1DB5Y3EPSgwXZzAazZS49lAnGJX6eq+byIm PHmicq9ofTa7jZqWC4pgylQXpJV6wWWuypG8bkgpxeUiZVKw/2Ea3MdRcK29iFmhPFOJ Zt1g== Received: by 10.182.36.3 with SMTP id m3mr36771654obj.8.1332924925896; Wed, 28 Mar 2012 01:55:25 -0700 (PDT) Received: by 10.182.36.3 with SMTP id m3mr36771608obj.8.1332924925666; Wed, 28 Mar 2012 01:55:25 -0700 (PDT) MIME-Version: 1.0 Received: by 10.182.63.231 with HTTP; Wed, 28 Mar 2012 01:55:05 -0700 (PDT) In-Reply-To: <4F72CD22.3080604@gmail.com> References: <75459BC2-E733-45C0-BC1C-25A19BBA1137@gmail.com> <75D251D1-9828-4AFE-9BEF-B376E97133C7@nominum.com> <4A221CE5-ECF0-4E07-9329-E6BAA3F06A96@nominum.com> <4EC4AADB.8030803@piuha.net> <4F719186.3060507@gmail.com> <4F72CD22.3080604@gmail.com> From: Lorenzo Colitti Date: Wed, 28 Mar 2012 10:55:05 +0200 Message-ID: To: Tomek Mrugalski Content-Type: multipart/alternative; boundary=f46d04447f9fb4e4e904bc49c446 X-System-Of-Record: true X-Gm-Message-State: ALoCoQnsWkgRhLs6qkzn+FztWkWx1FKQ0sXiRIxhNtAWX2eogKavSL2ffPK9eh6I6Z5eKzRBghEFJVrz00rMGl+rebufe4kwFscs3BPrLXZehLZbaFJ8BTYcP9FvHFl6LbtmR7kW0ltu X-Mailman-Approved-At: Wed, 28 Mar 2012 04:10:30 -0700 Cc: Stuart Cheshire , Brian Haberman , mif@ietf.org, Ron Bonica , Margaret Wasserman , Dave Thaler , Tim Chown , "narten@us.ibm.com Narten" , Mark Townsley , Wojciech Dec 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 28 Mar 2012 08:55:27 -0000 --f46d04447f9fb4e4e904bc49c446 Content-Type: text/plain; charset=ISO-8859-1 [Putting mif back into CC, since now we're talking about the merits of the proposal] On Wed, Mar 28, 2012 at 10:34, Tomek Mrugalski wrote: > Let me comment on the deprecation a bit more. You mentioned previously > that you are concerned about route entries becoming invalid. Let me > explain how we plan this to defend against it: > - if a host detects link flap, it must flush all routes installed > - host verifies that router is reachable using ND, before using it > - host detects that router died using NUD > And then what does the host? Ask the server again for another default route? Why would the server return anything different than what it already returned? After all, the server doesn't share state with the router, so it has not idea that the host can't reach it. > - you also expressed concerns about new server not being able to > invalidate old server's configuration in case of old server crash. That > is actually an invalid argument. Failure of the server does not imply > failure of the router. Furthermore, it is possible to invalidate old > server's information. If you want to do this, your new server can > announce route to become obsolete by announcing it with lifetime of 0. > > Do you have any other deprecation mode in mind that is not covered? > Example A: 1. There are two routers on the link connected to a switch. 2. You get a default route from a DHCPv6 server pointing at one of them. 3. The router crashes or is taken out of service. You default route is not working any more. The server doesn't know this, and so doesn't validate your route 4. You have no default route. Example B: 1. There are two routers on the link connected to a switch. 2. You get a default route from a DHCPv6 server pointing at one of them. 3. The server crashes or is unreachable. 4. The router is taken out of service for planned maintenance. 5. You have no default route, and nobody can invalidate your route, since only the crashed / unreachable server has the nonce. In IPv4, the typical solution to these problems are NOT "use reconfigure accept", but "run VRRP". With RAs, we can get rid of VRRP; we just won't have the problem. In the homenet, where stuff can go away permanently at any time, things get even worse. > DHCPv6 servers often don't share fate with the routers. > So? There are over 65 options defined for DHCPv6, much more will be > defined. Do you expect server to share fate with all announced services? > No. I'm saying we already have a way to do this that shares fate, and that it's more reliable, and that we don't need another way. > This mechanism may affect many groups: MIF, DHC, homenet, shim6, 6man > and v6ops. Do you expect us to ask for adoption of this draft to all of > those groups in turn? My idea is that this mechanism may affect many > WGs, but such document must be adopted somewhere. > Agreed, it needs a place to live. I believe MIF is not the right place, because 11 of the 14 use cases are not about multiple interfaces. I believe that 6man is the right place, because this option provides a complete replacement for the basic way in which hosts learn about routers. If you take this to 6man and get consensus there, then that's fine. Cheers, Lorenzo --f46d04447f9fb4e4e904bc49c446 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
[Putting mif back into CC, since now we're t= alking about the merits of the proposal]
On Wed, Mar 28, 2012 at 10:34, Tomek Mru= galski <= tomasz.mrugalski@gmail.com> wrote:
Let me comment on the deprecation a bit more= . You mentioned previously
that you are concerned about route entries becoming invalid. Let me
explain how we plan this to defend against it:
- if a host detects link flap, it must flush all routes installed
- host verifies that router is reachable using ND, before using it
- host detects that router died using NUD

And then what does the host? Ask the server again for another default ro= ute? Why would the server return anything different than what it already re= turned? After all, the server doesn't share state with the router, so i= t has not idea that the host can't reach it.
=A0
- you also expressed concerns about new server not being able to
invalidate old server's configuration in case of old server crash. That=
is actually an invalid argument. Failure of the server does not imply
failure of the router. Furthermore, it is possible to invalidate old
server's information. If you want to do this, your new server can
announce route to become obsolete by announcing it with lifetime of 0.

Do you have any other deprecation mode in mind that is not covered?

Example A:
1. There are two routers = on the link connected to a switch.
2. You get a default route fro= m a DHCPv6 server pointing at one of them.
3. The router crashes or is taken out of service. You default route is= not working any more. The server doesn't know this, and so doesn't= validate your route
4. You have no default route.

Example B:
1. There are two routers on the link co= nnected to a switch.
2. You get a default route from a DHCPv6 ser= ver pointing at one of them.
3. The server crashes or is unreacha= ble.
4. The router is taken out of service for planned maintenance.
5. You have no default route, and nobody can invalidate your route, sinc= e only the crashed / unreachable server has the nonce.

In IPv4, the typical solution to these problems are NOT "use reco= nfigure accept", but "run VRRP". With RAs, we can get rid of= VRRP; we just won't have the problem.

In the = homenet, where stuff can go away permanently at any time, things get even w= orse.

> DHCPv6 servers often don= 't share fate with the routers.
So? There are over 65 options defined for DHCPv6, much more will be
defined. Do you expect server to share fate with all announced services?

No. I'm saying we already have a way = to do this that shares fate, and that it's more reliable, and that we d= on't need another way.
=A0
This mechanism may affect many= groups: MIF, DHC, homenet, shim6, 6man
and v6ops. Do you expect us to ask for adoption of this draft to all of
those groups in turn? My idea is that this mechanism may affect many
WGs, but such document must be adopted somewhere.

=
Agreed, it needs a place to live. I believe MIF is not the right= place, because 11 of the 14 use cases are not about multiple interfaces. I= believe that 6man is the right place, because this option provides a compl= ete replacement for the basic way in which hosts learn about routers.

If you take this to 6man and get consensus there, then = that's fine.

Cheers,
Lorenzo
--f46d04447f9fb4e4e904bc49c446-- From list-mif@dragon.net Wed Mar 28 10:22:59 2012 Return-Path: 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 9581721E809E for ; Wed, 28 Mar 2012 10:22:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.49 X-Spam-Level: X-Spam-Status: No, score=-1.49 tagged_above=-999 required=5 tests=[AWL=1.110, BAYES_00=-2.599] 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 KBsp0iHN25FM for ; Wed, 28 Mar 2012 10:22:59 -0700 (PDT) Received: from mail.dragon.net (mail.dragon.net [IPv6:2001:4f8:3:36::235]) by ietfa.amsl.com (Postfix) with ESMTP id EE4AE21E804A for ; Wed, 28 Mar 2012 10:22:58 -0700 (PDT) Received: from fafnir.remote.dragon.net (localhost [127.0.0.1]) by mail.dragon.net (Postfix) with ESMTP id 54C2B374058A for ; Wed, 28 Mar 2012 10:22:58 -0700 (PDT) Received: by fafnir.remote.dragon.net (Postfix, from userid 501) id 93C9A695873; Wed, 28 Mar 2012 19:22:57 +0200 (CEST) Received: from fafnir.remote.dragon.net (localhost [127.0.0.1]) by fafnir.remote.dragon.net (Postfix) with ESMTP id 9032E69586A for ; Wed, 28 Mar 2012 19:22:57 +0200 (CEST) To: mif@ietf.org From: Paul Ebersman In-reply-to: <4F71A8D1.6000807@gmail.com> References: <20120224101611.22703.52041.idtracker@ietfa.amsl.com> <4F47688B.10508@gmail.com> <4F5E2F61.9040009@gmail.com> <4F71A8D1.6000807@gmail.com> Comments: In-reply-to Alexandru Petrescu message dated "Tue, 27 Mar 2012 13:47:29 +0200." X-Mailer: MH-E 7.4.2; nmh 1.3; XEmacs 21.4 (patch 22) Date: Wed, 28 Mar 2012 19:22:57 +0200 Message-Id: <20120328172257.93C9A695873@fafnir.remote.dragon.net> Subject: Re: [mif] draft-ietf-mif-dhcpv6-route-option-04 published X-BeenThere: mif@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multiple Interface Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 28 Mar 2012 17:22:59 -0000 I have seen a reasonable number of sites that have multiple clients on the same wire (one broadcast domain) who want to be able to differentiate those clients into different groups, with different configurations. This may be for different classes of services, billing to different departments, different security zones, etc. but they want to be able to have different prefixes and different routes based on this. While we can argue that using IP address as a way of differentiating is error prone, it does work well for a number of companies. This is not to avoid using an RA. However, an RA can't give different answers to different clients on the same wire, nor do I think it should. Current RA design is still clean and simple and we should try to keep it that way. DHCP is designed to handle lots of complex configuration information, with a broad range of different clients having different needs, so it seems much more appropriate to have DHCP be able to hand out these configurations, including a default route. As to whether or not this draft should be in the mif WG, I have been away from the IETF process long enough that I am not as clear on standard protocol. I do agree that being able to have different clients have different answers for default route would be useful to more than multi-interface hosts (single interface, homenet, etc.). But this draft seems to have been in mif for quite a while. It does seem that suddenly changing its working group now is a bit odd; I'd be inclined to keep it here just so we can keep the draft moving. From brian.e.carpenter@gmail.com Wed Mar 28 12:32:50 2012 Return-Path: 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 96A2A21E8154 for ; Wed, 28 Mar 2012 12:32:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.599 X-Spam-Level: X-Spam-Status: No, score=-103.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, 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 URQkphg5877P for ; Wed, 28 Mar 2012 12:32:49 -0700 (PDT) Received: from mail-pb0-f44.google.com (mail-pb0-f44.google.com [209.85.160.44]) by ietfa.amsl.com (Postfix) with ESMTP id 8A68921E80E1 for ; Wed, 28 Mar 2012 12:32:47 -0700 (PDT) Received: by pbbrq13 with SMTP id rq13so2269228pbb.31 for ; Wed, 28 Mar 2012 12:32:47 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:organization:user-agent:mime-version:to:cc :subject:references:in-reply-to:content-type :content-transfer-encoding; bh=/+Xu8aqvfhJgCOHYAypnHNKg3yr9LgS1wnlbCXEUmyQ=; b=P9JcjTzrhub66/xqJOJV7VZdSeazxV/lwq04kJZNZARkTXclV7g42/jYt6N+J0fKlR cmbWuJgu5bb97lBK/lu/s6v9kFi4RmVq8EZWV14/Lsw0rN5OiUlHPrPU06qYCU16PswW yj4mN22uG9ZC19TNDYB5EBSKqgOtAXlpEKI12nfVwSLSvcV5fOoCTQQ+jQ/7dniYElZ7 DrsFzjqcfxAezt0/rjCjJ2epzyojIYebEkH78haS3V2HO0FU29nUiAk8FaMyeHfXP0CR K0jNfLILganWSrjVkoHyPEnaIFcg55pSbYn/Oqcytvwtf83wr8qVRF2gIkw6aKffELxZ 41gA== Received: by 10.68.234.195 with SMTP id ug3mr75966331pbc.4.1332963167405; Wed, 28 Mar 2012 12:32:47 -0700 (PDT) Received: from [192.168.182.22] (122-57-150-118.jetstream.xtra.co.nz. [122.57.150.118]) by mx.google.com with ESMTPS id o7sm3289871pbq.8.2012.03.28.12.32.45 (version=SSLv3 cipher=OTHER); Wed, 28 Mar 2012 12:32:46 -0700 (PDT) Message-ID: <4F736758.9080100@gmail.com> Date: Thu, 29 Mar 2012 08:32:40 +1300 From: Brian E Carpenter Organization: University of Auckland User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: Lorenzo Colitti References: <4F71B306.1080509@gmail.com> <4F71B3EA.1000104@moth.iki.fi> <8D23D4052ABE7A4490E77B1A012B6307472C3E95@mbx-02.win.nominum.com> <4F723C26.4040105@gmail.com> In-Reply-To: Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: "mif@ietf.org" Subject: Re: [mif] Issue: Only _one_ default route? draft-ietf-mif-dhcpv6-route-option-04 X-BeenThere: mif@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multiple Interface Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 28 Mar 2012 19:32:50 -0000 On 2012-03-28 21:33, Lorenzo Colitti wrote: > On Wed, Mar 28, 2012 at 00:16, Brian E Carpenter < > brian.e.carpenter@gmail.com> wrote: > >> The phrase "more than one default route" on its own makes my head hurt, >> given the normal meaning in computer science of the word "default". >> >> One default route per source prefix in use makes perfect sense, in view >> of the need for address pair selection and ingress-filtering avoidance. >> (When I think about it, a default route even makes sense for a ULA prefix.) > > > No, multiple default routes make sense even when they're not > source-specific. For example, they make sense when you have two routers and > one of them can go down. Remember that a route includes a next-hop, and > that RFC 4861 defines a default router list (which is a list of possible > next-hops for the default route). Fair enough, although if we were starting again there might be a better way of doing it. Brian From alexandru.petrescu@gmail.com Thu Mar 29 04:12:42 2012 Return-Path: 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 3ECD721F87C6 for ; Thu, 29 Mar 2012 04:12:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] 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 wlq8cCrQwrr4 for ; Thu, 29 Mar 2012 04:12:40 -0700 (PDT) Received: from mail-ee0-f44.google.com (mail-ee0-f44.google.com [74.125.83.44]) by ietfa.amsl.com (Postfix) with ESMTP id 3BA6E21F87B7 for ; Thu, 29 Mar 2012 04:12:40 -0700 (PDT) Received: by eeke51 with SMTP id e51so1098641eek.31 for ; Thu, 29 Mar 2012 04:12:39 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; bh=tqCINl6MXmb+p9RHuhfPQU9hSTtLKj9UgkNzLjUwlkw=; b=CCIz/+u+MVF99npauG7u7fJbZGJ5ybINvkGTe1SHnBcTWFNCtF9KddeL43OGdpvVrX CxK/zTYT+tyNfm2rz1Fd0Ej1QZ23H/sZ81NFlZQr0s/vG5nJOpBHrf94VJeGDMZltPSO RlWPUxmZaDVTC3BeLf0gK9vZZwj7rRFnAVRYemzmUQhztsl/KM4aYh/uFysdJIlSPvfL yv997jM8revqdfUp8IsjhmpdX39UKDDoyh6kJ5RvumPNjFIoVicnjf3250nvDfKtelXL qxH2AgJfXDkoqlID6J2xTepID49P4YmYIFN1f/WTnElacnVfT5Dwv2dTbxfw6+ayOMIG NYcg== Received: by 10.213.10.6 with SMTP id n6mr584493ebn.264.1333019558098; Thu, 29 Mar 2012 04:12:38 -0700 (PDT) Received: from [130.129.17.29] (dhcp-111d.meeting.ietf.org. [130.129.17.29]) by mx.google.com with ESMTPS id p57sm20147322eei.8.2012.03.29.04.12.36 (version=TLSv1/SSLv3 cipher=OTHER); Thu, 29 Mar 2012 04:12:37 -0700 (PDT) Message-ID: <4F74439C.2050000@gmail.com> Date: Thu, 29 Mar 2012 13:12:28 +0200 From: Alexandru Petrescu User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:11.0) Gecko/20120312 Thunderbird/11.0 MIME-Version: 1.0 To: Brian E Carpenter References: <4F71AE51.4000304@gmail.com> <8D23D4052ABE7A4490E77B1A012B6307472C3EB0@mbx-02.win.nominum.com> <4F71FCFE.7080002@gmail.com> <4F723E25.2030303@gmail.com> In-Reply-To: <4F723E25.2030303@gmail.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Cc: mif Subject: Re: [mif] Conform to IPv6 while not running ND (was: Issue: absent MAC address of default route? draft-ietf-mif-dhcpv6-route-option-04) X-BeenThere: mif@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multiple Interface Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 29 Mar 2012 11:12:42 -0000 Le 28/03/2012 00:24, Brian E Carpenter a écrit : > On 2012-03-28 06:46, Alexandru Petrescu wrote: ... >> In lightweight environments, and this is a MIF-ed router not host, >> it would only run DHCP and maybe no ND > > You can't conform to IPv6 and not run ND. Brian, Allow me a quick reply here. There are several active RFC proposals recent at IETF that simply don't run ND. Or, how to better say - if ND is present it is completely ignored, being replaced by something else claimed better than ND for some issue at hand. This is the case for example in the RoLL (RPL protocol), 6lowpan (IPv6 over header compression) and more. If I understand correctly, CoAP considers the sensor node to be an 'IPv6 node' but not necessarily run ND. If it did, then ICMP could be used without intermediary, instead of CoAP. ND relies on a very good notion of a link, subnet, whereas in these spaces this notion is totally absent, routers have only one interface and so forth. Somebody said that if node is not implementing ICMPv6 Redirect then it wouldnt't be accepted as an IPv6 node. These are points about which I could agree. At the same time the protocols that appear to be ignoring ND makes wonder about this IPv6 conformity aspect. Alex > > In answer to your original question: no. KISS. Don't overload DHCPv6 > with a function that is part of IPv6's basic mechanism (i.e. ND). > > Brian > From alexandru.petrescu@gmail.com Thu Mar 29 04:25:03 2012 Return-Path: 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 7372721F8913 for ; Thu, 29 Mar 2012 04:25:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] 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 ic7E5TqkYSrv for ; Thu, 29 Mar 2012 04:25:02 -0700 (PDT) Received: from mail-ee0-f44.google.com (mail-ee0-f44.google.com [74.125.83.44]) by ietfa.amsl.com (Postfix) with ESMTP id 9E8F221F880C for ; Thu, 29 Mar 2012 04:25:01 -0700 (PDT) Received: by eeke51 with SMTP id e51so1113489eek.31 for ; Thu, 29 Mar 2012 04:25:00 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:subject:references :in-reply-to:content-type:content-transfer-encoding; bh=+JNfLDM0lPn2FsxF1i9jIoWQYDASSJDXLLvaM6qJcUY=; b=hTKhPXDefTtAhJiw+xtxkbM3Yptc/phuq0fshjU0OJjaTTXoNzKTWqWODSRlV+zLor dPDY2hquYq0kW9TlqjLjLl7CMUvcJmBP91DZcSPCNjFIlxF/thdJZ7BjZe+HnOkvCzey t9W0P6Q3I477zzMQ5D+SDdv3gsmbxLF7pKIBR2jI8gbFzCf3h6yk4O4Fk23jGu407hri ydQn+9fvTQkAgTfkl4OXPo8RyNMmLTu6ixAdMnaXpnJVQzYaWvOKTIAgwxq65rgpQsIz lmnwS7Yk8mj8dlFevYvA2P9gRYzTYFikVEFo3z66J8Q8MXqQ32qMSm9sAYjxMlCmMnNw GAyw== Received: by 10.14.98.143 with SMTP id v15mr4816555eef.90.1333020300704; Thu, 29 Mar 2012 04:25:00 -0700 (PDT) Received: from [130.129.17.29] (dhcp-111d.meeting.ietf.org. [130.129.17.29]) by mx.google.com with ESMTPS id x8sm20211456eea.10.2012.03.29.04.24.58 (version=TLSv1/SSLv3 cipher=OTHER); Thu, 29 Mar 2012 04:24:59 -0700 (PDT) Message-ID: <4F744681.1090207@gmail.com> Date: Thu, 29 Mar 2012 13:24:49 +0200 From: Alexandru Petrescu User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:11.0) Gecko/20120312 Thunderbird/11.0 MIME-Version: 1.0 To: mif@ietf.org References: <4F71AB00.2020404@gmail.com> <4F72B40F.6050303@gmail.com> In-Reply-To: <4F72B40F.6050303@gmail.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Subject: Re: [mif] Issue: separate specific routes from default routes? draft-ietf-mif-dhcpv6-route-option-04 X-BeenThere: mif@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multiple Interface Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 29 Mar 2012 11:25:03 -0000 Le 28/03/2012 08:47, Tomek Mrugalski a écrit : > On 12-03-27 13:56, Alexandru Petrescu wrote: >> Dear participants in MIF WG, >> >> Currently draft-ietf-mif-dhcpv6-route-option-04 specifies a way >> for the DHCPv6 Server to communicate a set of routes to the DHCPv6 >> Client. This covers both specific routes and the particular case >> of default routes (a default route is meant when the RT_PREFIX >> option is absent, or alternatively by using 128 0 bits as >> RT_PREFIX). >> >> I think this is an issue. >> >> It's not good to have two different things to achieve the same >> functionality. > Agree. There used to be two ways of specifying default route (in > -03), but this capability was removed. The original reason for > having two ways of configuring the issue is well known to you as you > suggested it in the first place. It was an attempt to solve your > concerns about sent information being too big. As we modified prefix > encoding to variable prefix field size option size is no longer a > concern. > > Unfortunately, I missed one sentence that still suggest that. It > will be removed in -05. Thanks for the clarification. I will be following which sentence is to be removed: the one implying long packets or the one imposing short packets (i.e. in case of default route, transmit only router's address and not additional 128 0 bits). > Just be clear: sending only NEXT_HOP option without RT_PREFIX is not > longer supported. Each NEXT_HOP MUST have at least one RT_PREFIX > option. I will look at the spec when it's written down and wonder whether this implies long or short packets. >> Second, using default routes in the same option type of specific >> routes means that they'd share the same faith - if specific routes >> are wrongly configured in the same section of the config file, >> there is a risk that the default route is wrongly configured too. >> Or, the default route is something of last resort, so it would be >> better to have it configured in a different place, communicated >> with a different ORO type. > That argument is bogus. If your network administrator can't type > ::/0, you should get a new admin. Some implementations may also > accept word "default" in its configuration. I tend to agree. If the conf file says s something like this: option dhcp6.default-router 2002:c130:13c1:11f::ff 8400 ... ; then this is good. As implementer, when I read a spec, I tend to write a "default-router" token only if the spec has a special type for it. Otherwise I will write a token with the name "route" if that is what the spec says. On another hand if the spec says "route option" then I will write a "dhcp6.route" token. It would be more work to parse the route, decide it's a default. > >> Third, if a single way of configuring default an specific routes >> with DHCP then this means that a bigger software implementation >> would be needed even for lightweight devices. Or, lightweight >> devices only use a single route - the default route. > My understanding is that all nodes that claim to be IPv6 compatible, > must support ICMP Redirects, as defined in RFC4861. This implies > required support for more than just a default route. In a sense yes. Several people mentioned this and we could discuss separately. >> I suggest we separate the default route ORO from the specific >> routes ORO. > You meant option, I assume. ORO (Option Request Option) is for > requesting other options. To be more clear. I meant both, as described below. There should be an Option Request Option ORO to request a default route, and another ORO number to request a route. Also, in the reply, there should be an OPTION_DEFAULT_ROUTER_LIST to communicate default routes, and a different OPTION number to communicate the specific routes. Yours, Alex > > Cheers, Tomek _______________________________________________ mif > mailing list mif@ietf.org https://www.ietf.org/mailman/listinfo/mif From alexandru.petrescu@gmail.com Thu Mar 29 04:32:13 2012 Return-Path: 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 AC5D421F8699 for ; Thu, 29 Mar 2012 04:32:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.299 X-Spam-Level: X-Spam-Status: No, score=-3.299 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, J_CHICKENPOX_13=0.6, RCVD_IN_DNSWL_LOW=-1] 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 TSUDw1q2QZHI for ; Thu, 29 Mar 2012 04:32:13 -0700 (PDT) Received: from mail-ey0-f172.google.com (mail-ey0-f172.google.com [209.85.215.172]) by ietfa.amsl.com (Postfix) with ESMTP id 8666021F8693 for ; Thu, 29 Mar 2012 04:32:12 -0700 (PDT) Received: by eaaq11 with SMTP id q11so1144474eaa.31 for ; Thu, 29 Mar 2012 04:32:11 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:subject:references :in-reply-to:content-type:content-transfer-encoding; bh=BJDRNeXZ8zyBf3EUcw1ksv5dAQbcEOgLospvnnh331I=; b=u9TcVNFptlPOij9qyFu1/UGB64FyG26O6/mdQjzldoPirYr6Nn/jsIC5xR5hL04osN Pc4LG4g7opm4C6jrg3LDotP7pwVwX+VzkPHQuBp9dzy1cIY2uwRtUN24uLLenBOaXHPZ wygORjW7fKg9BC0GrNQt7deGh/ZB3WS//mAe9taZKm+8j0MWnNYfs2ULVUPQ5lvewUNX cipQPmaJccpcO9y88yM0C4dyC6HdQfCnnusiXrOeJ/ysDx26SgC4M7KT0dw9A28bKZH/ PWjmfNmOxCOBwQyIlKVy8qafQv85IJHyLUBM9uTd5rdH8Hi0tF+pzgE75bf9X6oZ1oPE 8ixQ== Received: by 10.14.28.207 with SMTP id g55mr2029994eea.67.1333020731437; Thu, 29 Mar 2012 04:32:11 -0700 (PDT) Received: from [130.129.17.29] (dhcp-111d.meeting.ietf.org. [130.129.17.29]) by mx.google.com with ESMTPS id q45sm20282407eem.7.2012.03.29.04.32.10 (version=TLSv1/SSLv3 cipher=OTHER); Thu, 29 Mar 2012 04:32:10 -0700 (PDT) Message-ID: <4F744831.3070406@gmail.com> Date: Thu, 29 Mar 2012 13:32:01 +0200 From: Alexandru Petrescu User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:11.0) Gecko/20120312 Thunderbird/11.0 MIME-Version: 1.0 To: mif@ietf.org References: <75459BC2-E733-45C0-BC1C-25A19BBA1137@gmail.com> <75D251D1-9828-4AFE-9BEF-B376E97133C7@nominum.com> <4A221CE5-ECF0-4E07-9329-E6BAA3F06A96@nominum.com> <4EC4AADB.8030803@piuha.net> <4F719186.3060507@gmail.com> <4F72CD22.3080604@gmail.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 29 Mar 2012 11:32:13 -0000 Le 28/03/2012 10:55, Lorenzo Colitti a écrit : > [Putting mif back into CC, since now we're talking about the merits of > the proposal] > >> On Wed, Mar 28, 2012 at 10:34, Tomek Mrugalski >> > wrote: >> >> Let me comment on the deprecation a bit more. You mentioned previously >> that you are concerned about route entries becoming invalid. Let me >> explain how we plan this to defend against it: >> - if a host detects link flap, it must flush all routes installed >> - host verifies that router is reachable using ND, before using it >> - host detects that router died using NUD > > And then what does the host? Ask the server again for another default > route? Why would the server return anything different than what it > already returned? After all, the server doesn't share state with the > router, so it has not idea that the host can't reach it. I agree with this point of view. In our work we were confronted with the question about what does the Client when the default router's lifetime expire: should it issue an RS or a DHCPv6 Request? Also, it may be good to have error processing in the route option draft. Maybe with error codes that would explain why the Server is not able to deliver some routes. Alex > > - you also expressed concerns about new server not being able to > invalidate old server's configuration in case of old server crash. That > is actually an invalid argument. Failure of the server does not imply > failure of the router. Furthermore, it is possible to invalidate old > server's information. If you want to do this, your new server can > announce route to become obsolete by announcing it with lifetime of 0. > > Do you have any other deprecation mode in mind that is not covered? > > > Example A: > 1. There are two routers on the link connected to a switch. > 2. You get a default route from a DHCPv6 server pointing at one of them. > 3. The router crashes or is taken out of service. You default route is > not working any more. The server doesn't know this, and so doesn't > validate your route > 4. You have no default route. > > Example B: > 1. There are two routers on the link connected to a switch. > 2. You get a default route from a DHCPv6 server pointing at one of them. > 3. The server crashes or is unreachable. > 4. The router is taken out of service for planned maintenance. > 5. You have no default route, and nobody can invalidate your route, > since only the crashed / unreachable server has the nonce. > > In IPv4, the typical solution to these problems are NOT "use reconfigure > accept", but "run VRRP". With RAs, we can get rid of VRRP; we just won't > have the problem. > > In the homenet, where stuff can go away permanently at any time, things > get even worse. > > > DHCPv6 servers often don't share fate with the routers. > So? There are over 65 options defined for DHCPv6, much more will be > defined. Do you expect server to share fate with all announced services? > > > No. I'm saying we already have a way to do this that shares fate, and > that it's more reliable, and that we don't need another way. > > This mechanism may affect many groups: MIF, DHC, homenet, shim6, 6man > and v6ops. Do you expect us to ask for adoption of this draft to all of > those groups in turn? My idea is that this mechanism may affect many > WGs, but such document must be adopted somewhere. > > > Agreed, it needs a place to live. I believe MIF is not the right place, > because 11 of the 14 use cases are not about multiple interfaces. I > believe that 6man is the right place, because this option provides a > complete replacement for the basic way in which hosts learn about routers. > > If you take this to 6man and get consensus there, then that's fine. > > Cheers, > Lorenzo > > > _______________________________________________ > mif mailing list > mif@ietf.org > https://www.ietf.org/mailman/listinfo/mif From Ted.Lemon@nominum.com Thu Mar 29 04:35:48 2012 Return-Path: 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 61B2821F89A3 for ; Thu, 29 Mar 2012 04:35:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.484 X-Spam-Level: X-Spam-Status: No, score=-106.484 tagged_above=-999 required=5 tests=[AWL=0.115, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, 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 5wWGSy51mdIK for ; Thu, 29 Mar 2012 04:35:47 -0700 (PDT) Received: from exprod7og117.obsmtp.com (exprod7og117.obsmtp.com [64.18.2.6]) by ietfa.amsl.com (Postfix) with ESMTP id 4B39321F8699 for ; Thu, 29 Mar 2012 04:35:47 -0700 (PDT) Received: from shell-too.nominum.com ([64.89.228.229]) (using TLSv1) by exprod7ob117.postini.com ([64.18.6.12]) with SMTP ID DSNKT3RJEopWEy0htIYjZNPA8GthXLd8Ks2q@postini.com; Thu, 29 Mar 2012 04:35:47 PDT Received: from archivist.nominum.com (archivist.nominum.com [64.89.228.108]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "*.nominum.com", Issuer "Go Daddy Secure Certification Authority" (verified OK)) by shell-too.nominum.com (Postfix) with ESMTP id 6639A1B8069 for ; Thu, 29 Mar 2012 04:35:46 -0700 (PDT) Received: from webmail.nominum.com (cas-01.win.nominum.com [64.89.228.131]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (Client CN "mail.nominum.com", Issuer "Go Daddy Secure Certification Authority" (verified OK)) by archivist.nominum.com (Postfix) with ESMTPS id 5F813190064; Thu, 29 Mar 2012 04:35:46 -0700 (PDT) (envelope-from Ted.Lemon@nominum.com) Received: from MBX-01.WIN.NOMINUM.COM ([64.89.228.133]) by CAS-01.WIN.NOMINUM.COM ([64.89.228.131]) with mapi id 14.02.0247.003; Thu, 29 Mar 2012 04:35:46 -0700 From: Ted Lemon To: Alexandru Petrescu , "mif@ietf.org" Thread-Topic: [mif] Route option for DHCPv6 - next steps? Thread-Index: AQHNDL2jhfr6t6vyVEeGR+93z5NinJZ/3M2AgAG+LoD//4t2bQ== Date: Thu, 29 Mar 2012 11:35:46 +0000 Message-ID: <8D23D4052ABE7A4490E77B1A012B6307472D4175@mbx-01.win.nominum.com> References: <75459BC2-E733-45C0-BC1C-25A19BBA1137@gmail.com> <75D251D1-9828-4AFE-9BEF-B376E97133C7@nominum.com> <4A221CE5-ECF0-4E07-9329-E6BAA3F06A96@nominum.com> <4EC4AADB.8030803@piuha.net> <4F719186.3060507@gmail.com> <4F72CD22.3080604@gmail.com> , <4F744831.3070406@gmail.com> In-Reply-To: <4F744831.3070406@gmail.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [192.168.1.10] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 29 Mar 2012 11:35:48 -0000 Probably the best thing to do is set the router lifetime to the DHCP renewa= l time, and not send a lifetime separate from that. Otherwise, as you say= , implementation is complicated. From alexandru.petrescu@gmail.com Thu Mar 29 04:43:41 2012 Return-Path: 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 2EA5021F897B for ; Thu, 29 Mar 2012 04:43:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.585 X-Spam-Level: X-Spam-Status: No, score=-3.585 tagged_above=-999 required=5 tests=[AWL=0.014, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] 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 ufK8ARo1DJne for ; Thu, 29 Mar 2012 04:43:40 -0700 (PDT) Received: from mail-ey0-f172.google.com (mail-ey0-f172.google.com [209.85.215.172]) by ietfa.amsl.com (Postfix) with ESMTP id 9080021F8973 for ; Thu, 29 Mar 2012 04:43:39 -0700 (PDT) Received: by eaaq11 with SMTP id q11so1152598eaa.31 for ; Thu, 29 Mar 2012 04:43:36 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; bh=clciPECIU4CENsN9+hLZH8OD3zEsZi5NEHPYBM/i1r0=; b=tTcrCfggbgezwwRNjbDBpmRJrU0HouBzOnFxqpAvj21aME8w+6HPxp1B2oLTPxw3m0 vbG4VVh1bZzgVGZX0saJVz+pD/a+CxJeUIYYWomRbpV7O/iMwpcot8Zcy9HrgjVHHHHL jzQUF7wuDsRAj//GVGe7o0M9iqh0CPrQtTsYCKgcCDfbTyYeTASr80vI/MVS7Qmf+nqQ D0DbaE9Sd1etLMXG7rjvbWrcPmu5Sk2xFGLxyXnhH/fPFiRGzEAqFpkoxsUcZ4J2rc16 Q9qtXZnznz47QkAzE1XxMa3pXOal78BnPYLgKBBxDQr12LpQGVX2p6lJ1OZZJ6U2jkEt foZA== Received: by 10.213.10.196 with SMTP id q4mr2400297ebq.294.1333021416227; Thu, 29 Mar 2012 04:43:36 -0700 (PDT) Received: from [130.129.17.29] (dhcp-111d.meeting.ietf.org. [130.129.17.29]) by mx.google.com with ESMTPS id m42sm20423445eef.0.2012.03.29.04.43.34 (version=TLSv1/SSLv3 cipher=OTHER); Thu, 29 Mar 2012 04:43:35 -0700 (PDT) Message-ID: <4F744ADE.4080103@gmail.com> Date: Thu, 29 Mar 2012 13:43:26 +0200 From: Alexandru Petrescu User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:11.0) Gecko/20120312 Thunderbird/11.0 MIME-Version: 1.0 To: William Herrin References: <4F71AC33.6050506@gmail.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Cc: mif Subject: Re: [mif] Issue: lifetime 32bit or 16bit ? draft-ietf-mif-dhcpv6-route-option-04 X-BeenThere: mif@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multiple Interface Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 29 Mar 2012 11:43:41 -0000 Le 27/03/2012 17:54, William Herrin a écrit : > On Tue, Mar 27, 2012 at 8:01 AM, Alexandru Petrescu > wrote: >> Currently draft-ietf-mif-dhcpv6-route-option-04 specifies that the >> lifetime of a route (and implicitely of a default route) is to be >> 32bit length field. >> >> On another hand, the currently implemented default routes are >> implemented according to ND Neighbor Discovery, which uses >> route_r_ lifetime on 16bit (RFC 4861 search "Router Lifetime"). >> >> I think this is an issue. It generates additional work to the >> implementer. If one agrees that it is good to store the DHCP >> default route in the existing ND data structures, then one notices >> a conversion is needed. If these lifetime fields were expressed >> in the same number of bits (preferably 16bit, because that exists >> already) then the implementer would be relieved from conversion >> work. >> >> I wanted to ask the oppinion of the WG about this issue. > > > I'm new to the questions surrounding DHCPv6, so my apologies if this > has already been discussed. > > It's common practice to issue IPv4 DHCP lifetimes in excess of 24 > hours (86400 seconds). I have to think that supporting common > configurations outweighs preserving ND data structures. > > However... why would DHCP issue a router lifetime which is different > from the overall lifetime anyway? What's the use case for different > components of the DHCP message having different lifetimes? Bill, The ND use of Router Lifetime is sometimes to distinguish among multiple default routers. I.e., if the Host has two default routes each with a different lifetime, it may prefer the one with longer lifetime. Also, the Router Lifetime has distinctive treatment of the value '0'. Depending on it the Router is considered good as default or not. This semantics is there already, but I wonder how it applies to the lifetime 32bit communicated by DHCP. One may wonder how that default route is inserted in the existing data structures and what happens when the lifetime expires - should it issue an RS or a DHCP Request? Alex > > Thanks, Bill > > From alexandru.petrescu@gmail.com Thu Mar 29 04:47:57 2012 Return-Path: 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 038CA21F87A7 for ; Thu, 29 Mar 2012 04:47:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.585 X-Spam-Level: X-Spam-Status: No, score=-3.585 tagged_above=-999 required=5 tests=[AWL=0.014, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] 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 x5Qx7YyYjyTr for ; Thu, 29 Mar 2012 04:47:56 -0700 (PDT) Received: from mail-ey0-f172.google.com (mail-ey0-f172.google.com [209.85.215.172]) by ietfa.amsl.com (Postfix) with ESMTP id 2FAF021F87A3 for ; Thu, 29 Mar 2012 04:47:56 -0700 (PDT) Received: by eaaq11 with SMTP id q11so1155147eaa.31 for ; Thu, 29 Mar 2012 04:47:52 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; bh=/u4LeVdBnN+uIDgnipGPqrZdJScrp589IPL/Sf/+jQs=; b=Dpp9CH4e9N1WxSF25QDcpawJiMqNKhxEPhDvjJSJfN4yD8MgP0PyB2Xsayth1nWgMQ GlaweXZjJyvKBFMTzMHYNkWcuT6D91Kr+ELiJUSokK68kC3vlEaHn62t0YUzzGBhfIUP Sf9b0hr8/Bjq+wduo2YeFu8bUjndAaNbQHMdi9RPBf4PR8vL7aSkN7D6PasJfd2+iJI3 jQ0s7Jv4g1ukwRnkFBIF7zAxzaFF7wmzuOl64oiXeVDanVbQG41cPkpGTnsGfADzBM6N sgFOcqnTkWW+vLALW4hFMKLoPz19OaWs/s91oSeOY1k1sr92kT7Bryr7dyQFcqWoVtJb UOkg== Received: by 10.213.17.66 with SMTP id r2mr2409444eba.118.1333021672048; Thu, 29 Mar 2012 04:47:52 -0700 (PDT) Received: from [130.129.17.29] (dhcp-111d.meeting.ietf.org. [130.129.17.29]) by mx.google.com with ESMTPS id y11sm20423564eem.3.2012.03.29.04.47.50 (version=TLSv1/SSLv3 cipher=OTHER); Thu, 29 Mar 2012 04:47:51 -0700 (PDT) Message-ID: <4F744BDE.2030704@gmail.com> Date: Thu, 29 Mar 2012 13:47:42 +0200 From: Alexandru Petrescu User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:11.0) Gecko/20120312 Thunderbird/11.0 MIME-Version: 1.0 To: Ted Lemon References: <4F7201B0.8070702@gmail.com> <8D23D4052ABE7A4490E77B1A012B6307472C409D@mbx-02.win.nominum.com> In-Reply-To: <8D23D4052ABE7A4490E77B1A012B6307472C409D@mbx-02.win.nominum.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Cc: mif Subject: Re: [mif] Preserving ND data structures when DHCP default route, why, command to issue X-BeenThere: mif@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multiple Interface Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 29 Mar 2012 11:47:57 -0000 Le 27/03/2012 22:31, Ted Lemon a écrit : >> # ip -6 route show default via 2002:c130:13c1:11f::ff dev eth0 >> proto kernel metric 1024 expires 7752sec mtu 1500 advmss 1440 >> hoplimit 0 ^^^^ > > Okay, the route has a lifetime<7752s. So? So what happens when it expires. Should an RS be issued? Should a DHCP message be issued? Alex > >> Note that 'expires' field. If RS/RA are not used, but DHCPv6 >> route-option is used with 32bit lifetimes instead of 16bit >> lifetimes, would one think there may be a risk for that 'expires' >> field to overflow? Or to be understood wrongly by ND (if present), >> like not knowing when to send the RS to update the data? Or like >> simply crashing? > > How do you think the route show command computed that value? Do you > think there's a field in a routing table entry somewhere that > contains the number 7752, and a process somewhere that subtracts one > from that field once every second? No, the field in the structure > contains (time_t)now + 7752, and the route command subtracted > (time_t)now from the value of the field to give you the number 7752. > > So yes, of course there's a risk that an implementation will be > broken. This risk exists whether the offset is 16 bits or 32 bits; > it depends solely on how soon it is before (time_t) overflows. If > someone codes up a routing table implementation that contains this > flaw, I'm sure much lulz will come of it, but there is little we can > do to prevent other people from making mistakes, and making the > offset smaller in the DHCP packet certainly isn't an example of > something that would have that result. From Ted.Lemon@nominum.com Thu Mar 29 04:54:33 2012 Return-Path: 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 00B9521F8878 for ; Thu, 29 Mar 2012 04:54:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.485 X-Spam-Level: X-Spam-Status: No, score=-106.485 tagged_above=-999 required=5 tests=[AWL=0.114, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, 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 wMo7579d1OpE for ; Thu, 29 Mar 2012 04:54:32 -0700 (PDT) Received: from exprod7og118.obsmtp.com (exprod7og118.obsmtp.com [64.18.2.8]) by ietfa.amsl.com (Postfix) with ESMTP id EF04621F8870 for ; Thu, 29 Mar 2012 04:54:31 -0700 (PDT) Received: from shell-too.nominum.com ([64.89.228.229]) (using TLSv1) by exprod7ob118.postini.com ([64.18.6.12]) with SMTP ID DSNKT3RNd6SwB9Z6NuSTxTxYDZoyRHtrqSYI@postini.com; Thu, 29 Mar 2012 04:54:32 PDT Received: from archivist.nominum.com (archivist.nominum.com [64.89.228.108]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "*.nominum.com", Issuer "Go Daddy Secure Certification Authority" (verified OK)) by shell-too.nominum.com (Postfix) with ESMTP id 02AEA1B81A7 for ; Thu, 29 Mar 2012 04:54:31 -0700 (PDT) Received: from webmail.nominum.com (cas-01.win.nominum.com [64.89.228.131]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (Client CN "mail.nominum.com", Issuer "Go Daddy Secure Certification Authority" (verified OK)) by archivist.nominum.com (Postfix) with ESMTPS id EA47F190064; Thu, 29 Mar 2012 04:54:30 -0700 (PDT) (envelope-from Ted.Lemon@nominum.com) Received: from MBX-01.WIN.NOMINUM.COM ([64.89.228.133]) by CAS-01.WIN.NOMINUM.COM ([64.89.228.131]) with mapi id 14.02.0247.003; Thu, 29 Mar 2012 04:54:31 -0700 From: Ted Lemon To: Alexandru Petrescu Thread-Topic: [mif] Preserving ND data structures when DHCP default route, why, command to issue Thread-Index: AQHNDERjeEmQiXEK/0OoAe3TaVMXE5Z+lz4MgAMJEQD//4r1qQ== Date: Thu, 29 Mar 2012 11:54:30 +0000 Message-ID: <8D23D4052ABE7A4490E77B1A012B6307472D41CB@mbx-01.win.nominum.com> References: <4F7201B0.8070702@gmail.com> <8D23D4052ABE7A4490E77B1A012B6307472C409D@mbx-02.win.nominum.com>, <4F744BDE.2030704@gmail.com> In-Reply-To: <4F744BDE.2030704@gmail.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [192.168.1.10] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: mif Subject: Re: [mif] Preserving ND data structures when DHCP default route, why, command to issue X-BeenThere: mif@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multiple Interface Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 29 Mar 2012 11:54:33 -0000 > So what happens when it expires. Should an RS be issued? Should a DHCP > message be issued? This is a really good question. I think in order to address this question= , we need 32-bit timers, so that the DHCP server can specify a lifetime lon= ger than that of the assigned address, if any, even if that lifetime is gre= ater than 18 hours. In the case of stateless DHCPv6, the lifetime of the = address should be greater than or equal to the IRT (RFC4242), and the docum= ent should require conforming clients to implement the IRT. From alexandru.petrescu@gmail.com Thu Mar 29 04:55:14 2012 Return-Path: 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 B037521F8870 for ; Thu, 29 Mar 2012 04:55:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.586 X-Spam-Level: X-Spam-Status: No, score=-3.586 tagged_above=-999 required=5 tests=[AWL=0.013, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] 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 F3xD2hXGwZGh for ; Thu, 29 Mar 2012 04:55:14 -0700 (PDT) Received: from mail-ey0-f172.google.com (mail-ey0-f172.google.com [209.85.215.172]) by ietfa.amsl.com (Postfix) with ESMTP id C011421F88F6 for ; Thu, 29 Mar 2012 04:55:13 -0700 (PDT) Received: by eaaq11 with SMTP id q11so1159580eaa.31 for ; Thu, 29 Mar 2012 04:55:01 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:subject:references :in-reply-to:content-type:content-transfer-encoding; bh=+dxf+61BwawcO3TErtNBDYJqLh+nM0vuCAZ0vYwN5Fc=; b=zJsHGg6/aRMvg7m8Q8UON2TMORARk0922+BSqmLu8fmMEetZrULlOj8xqQWd1ed63K y5V/BeQvewU569pkeOnMvbVPw7cmwlD1AIIihth93K+SuOPrJexICxonPdIVF4uN0Vfx t9FT9OVgSqakPg5fjTo5w7eBdVKeYBP8W0EAjiPRog/V0hwYdhoaDflBL9jHx1aZ57an zvbrHJE1a4tAzvgz7ik/CD1typz0doh05zfzyTE+X5P/l6nL9clHh4qIuZmen20Wgymx vJ1RNcxV5nQsUg/hwD7C2dxzF3+9gPv0tbbWl/jeSZkW1w4SaPzrS152pDWrt5BUN7oj NoOg== Received: by 10.213.96.5 with SMTP id f5mr2527169ebn.83.1333022101118; Thu, 29 Mar 2012 04:55:01 -0700 (PDT) Received: from [130.129.17.29] (dhcp-111d.meeting.ietf.org. [130.129.17.29]) by mx.google.com with ESMTPS id n56sm20466597eeb.4.2012.03.29.04.54.59 (version=TLSv1/SSLv3 cipher=OTHER); Thu, 29 Mar 2012 04:55:00 -0700 (PDT) Message-ID: <4F744D8B.6060106@gmail.com> Date: Thu, 29 Mar 2012 13:54:51 +0200 From: Alexandru Petrescu User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:11.0) Gecko/20120312 Thunderbird/11.0 MIME-Version: 1.0 To: mif@ietf.org References: <4F71AE51.4000304@gmail.com> <4F72BBF1.1080408@gmail.com> In-Reply-To: <4F72BBF1.1080408@gmail.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Subject: Re: [mif] Issue: absent MAC address of default route? draft-ietf-mif-dhcpv6-route-option-04 X-BeenThere: mif@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multiple Interface Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 29 Mar 2012 11:55:15 -0000 Le 28/03/2012 09:21, Tomek Mrugalski a écrit : > On 12-03-27 17:52, William Herrin wrote: >> On Tue, Mar 27, 2012 at 8:10 AM, Alexandru Petrescu If added, I >> think it should be non-authoritative. That is, the receiving host >> can use it briefly to get a jump start on communication but is >> expected to promptly perform an ND request for the authoritative >> MAC. This would allow a host to recover gracefully in the >> inevitable event that the DHCP server and router get out of sync >> about the router's MAC address. > > No, we do not plan adding MAC field. That would give us nothing, but > would bring a lot of troubles. In particular, the problem of MAC > being mis-configured or becoming out of sync. ND is a good protocol > for that purpose and is supported by all devices that claim IPv6 > compatibility, so we plan to use it. In a sense yes, the MAC is something with link scope and ND is link scope and ND may have the best local information about MAC. This would not prevent this information to be stored centrally, with all advantages centralized management brings, and inconvenients. Alex > > Tomek _______________________________________________ mif mailing > list mif@ietf.org https://www.ietf.org/mailman/listinfo/mif From tomasz.mrugalski@gmail.com Thu Mar 29 05:22:25 2012 Return-Path: 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 D97B121F86B6 for ; Thu, 29 Mar 2012 05:22:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] 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 SI51gB2IKC2E for ; Thu, 29 Mar 2012 05:22:23 -0700 (PDT) Received: from mail-bk0-f44.google.com (mail-bk0-f44.google.com [209.85.214.44]) by ietfa.amsl.com (Postfix) with ESMTP id 027A521F86B1 for ; Thu, 29 Mar 2012 05:22:22 -0700 (PDT) Received: by bkuw5 with SMTP id w5so2088839bku.31 for ; Thu, 29 Mar 2012 05:22:22 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:x-enigmail-version:content-type :content-transfer-encoding; bh=mdPa2r8JAZ8Hqnpvf70xgtte1AaFzUsYiNvY2VvmTBI=; b=B9A28IJ1MFyAJBffvsSZsiTB/rS5ZsR83KPsKmRmUX+9o/3KdhE9XMQdqwnL3DYHEn 3GjA6efG4qyS4pFzis3z5hrALl9mkJsixu1RTVEpV0XnvFP43nPlGFA3yMP/hsjU5Cmw OH1gK77Q/ghu2QIEFy5p2e2rHEgh4+U1VX+aIInj9seidH+NaRcIhJgkMYza2UBwlQ5d K0lV2/kSgbaklZa2A38/EEdFhgURiySR+ihOLlXaQtay/SW0XNKbP23Vke8kmHjRGGHc y8uNr3cHae6yyqfEEtgWzUr9Dbus9837QvanuPIG1nhlQjnH5nx878o6QOEZVRZXis0i f5Dw== Received: by 10.205.137.15 with SMTP id im15mr13781071bkc.54.1333023742110; Thu, 29 Mar 2012 05:22:22 -0700 (PDT) Received: from tomek.local (APuteaux-551-1-66-68.w92-132.abo.wanadoo.fr. [92.132.145.68]) by mx.google.com with ESMTPS id v2sm13340089bki.7.2012.03.29.05.22.20 (version=SSLv3 cipher=OTHER); Thu, 29 Mar 2012 05:22:21 -0700 (PDT) Message-ID: <4F7453FC.3010502@gmail.com> Date: Thu, 29 Mar 2012 14:22:20 +0200 From: Tomek Mrugalski User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:10.0.2) Gecko/20120216 Thunderbird/10.0.2 MIME-Version: 1.0 To: Ted Lemon References: <75459BC2-E733-45C0-BC1C-25A19BBA1137@gmail.com> <75D251D1-9828-4AFE-9BEF-B376E97133C7@nominum.com> <4A221CE5-ECF0-4E07-9329-E6BAA3F06A96@nominum.com> <4EC4AADB.8030803@piuha.net> <4F719186.3060507@gmail.com> <4F72CD22.3080604@gmail.com> , <4F744831.3070406@gmail.com> <8D23D4052ABE7A4490E77B1A012B6307472D4175@mbx-01.win.nominum.com> In-Reply-To: <8D23D4052ABE7A4490E77B1A012B6307472D4175@mbx-01.win.nominum.com> X-Enigmail-Version: 1.4 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: "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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 29 Mar 2012 12:22:25 -0000 On 12-03-29 13:35, Ted Lemon wrote: > Probably the best thing to do is set the router lifetime to the DHCP > renewal time, and not send a lifetime separate from that. We are talking about two timers here: route lifetime and renewal time (governed by information refresh time, defined in RFC4242). Will add clarification text that route lifetime should be greater than information refresh time. Making them equal is not a such good idea as it could trigger race conditions. Otherwise badness will happen. Tomek From alexandru.petrescu@gmail.com Thu Mar 29 05:24:27 2012 Return-Path: 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 DCAC721F8A9B for ; Thu, 29 Mar 2012 05:24:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.587 X-Spam-Level: X-Spam-Status: No, score=-3.587 tagged_above=-999 required=5 tests=[AWL=0.013, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] 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 1Up7viCdrW-k for ; Thu, 29 Mar 2012 05:24:26 -0700 (PDT) Received: from mail-ey0-f172.google.com (mail-ey0-f172.google.com [209.85.215.172]) by ietfa.amsl.com (Postfix) with ESMTP id A86E521F8A98 for ; Thu, 29 Mar 2012 05:24:25 -0700 (PDT) Received: by eaaq11 with SMTP id q11so1178112eaa.31 for ; Thu, 29 Mar 2012 05:24:24 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; bh=2pTL1HWVrg4ku1sU4gWwWvnukCezns3GcRYa8eAvDiA=; b=EXjs8U6ZinKHzOe2clWZH8H/NE602jiGREokYO2YWYJN0gd5iQ95GDa281QRBMU+RI ny08VzBcDHZN6rGunQRQZBxlAKmAXVTMIp7wN/TrRpd+ijGJAryQBOLvm8KE6wJZ8f6R cuPqXSBfI4EQqS5lO7VUZO6tAj2MLZbNlq6R2O38fHL91+RmfZUlaASlwcEz/y6X52mk TA6H9UiMj1dlEZmxI1gFjl+JG4Yci6DwnhFzsG4vl+Z4FRM7/GGIAqmt2YOyhWULLtIs sOQcIIRVBYKN8DTK3B739PNo76C6lH9icl2gSHpDBQzxsvzxAXLbCRXRmsd3TcLdUTkl sRDA== Received: by 10.213.17.130 with SMTP id s2mr2510617eba.115.1333023863322; Thu, 29 Mar 2012 05:24:23 -0700 (PDT) Received: from [130.129.17.29] (dhcp-111d.meeting.ietf.org. [130.129.17.29]) by mx.google.com with ESMTPS id q45sm20681502eem.7.2012.03.29.05.24.21 (version=TLSv1/SSLv3 cipher=OTHER); Thu, 29 Mar 2012 05:24:22 -0700 (PDT) Message-ID: <4F74546D.4060808@gmail.com> Date: Thu, 29 Mar 2012 14:24:13 +0200 From: Alexandru Petrescu User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:11.0) Gecko/20120312 Thunderbird/11.0 MIME-Version: 1.0 To: Tomek Mrugalski References: <75459BC2-E733-45C0-BC1C-25A19BBA1137@gmail.com> <75D251D1-9828-4AFE-9BEF-B376E97133C7@nominum.com> <4A221CE5-ECF0-4E07-9329-E6BAA3F06A96@nominum.com> <4EC4AADB.8030803@piuha.net> <4F719186.3060507@gmail.com> <4F72CD22.3080604@gmail.com> , <4F744831.3070406@gmail.com> <8D23D4052ABE7A4490E77B1A012B6307472D4175@mbx-01.win.nominum.com> <4F7453FC.3010502@gmail.com> In-Reply-To: <4F7453FC.3010502@gmail.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Cc: "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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 29 Mar 2012 12:24:28 -0000 Le 29/03/2012 14:22, Tomek Mrugalski a écrit : > On 12-03-29 13:35, Ted Lemon wrote: >> Probably the best thing to do is set the router lifetime to the DHCP >> renewal time, and not send a lifetime separate from that. > We are talking about two timers here: route lifetime and renewal time > (governed by information refresh time, defined in RFC4242). Will add > clarification text that route lifetime should be greater than > information refresh time. Making them equal is not a such good idea as > it could trigger race conditions. Otherwise badness will happen. We may be talking three timers: route lifetime, router lifetime (ND) and renewal time. Alex > > Tomek From mrw@lilacglade.org Thu Mar 29 05:30:05 2012 Return-Path: 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 A94D721F8AB1 for ; Thu, 29 Mar 2012 05:30:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.335 X-Spam-Level: X-Spam-Status: No, score=-102.335 tagged_above=-999 required=5 tests=[AWL=-0.070, BAYES_00=-2.599, 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 cL9wcAvxXVN6 for ; Thu, 29 Mar 2012 05:30:05 -0700 (PDT) Received: from permutation-city.suchdamage.org (permutation-city.suchdamage.org [69.25.196.28]) by ietfa.amsl.com (Postfix) with ESMTP id 26DA121F8A83 for ; Thu, 29 Mar 2012 05:30:05 -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 B89F8204D5; Thu, 29 Mar 2012 08:29:18 -0400 (EDT) Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Margaret Wasserman In-Reply-To: <4F74439C.2050000@gmail.com> Date: Thu, 29 Mar 2012 14:29:55 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: References: <4F71AE51.4000304@gmail.com> <8D23D4052ABE7A4490E77B1A012B6307472C3EB0@mbx-02.win.nominum.com> <4F71FCFE.7080002@gmail.com> <4F723E25.2030303@gmail.com> <4F74439C.2050000@gmail.com> To: Alexandru Petrescu X-Mailer: Apple Mail (2.1084) Cc: mif Subject: Re: [mif] Conform to IPv6 while not running ND (was: Issue: absent MAC address of default route? draft-ietf-mif-dhcpv6-route-option-04) X-BeenThere: mif@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multiple Interface Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 29 Mar 2012 12:30:05 -0000 On Mar 29, 2012, at 1:12 PM, Alexandru Petrescu wrote: > Allow me a quick reply here. There are several active RFC proposals > recent at IETF that simply don't run ND. Or, how to better say - if = ND > is present it is completely ignored, being replaced by something else > claimed better than ND for some issue at hand. >=20 > This is the case for example in the RoLL (RPL protocol), 6lowpan (IPv6 > over header compression) and more. If I understand correctly, CoAP > considers the sensor node to be an 'IPv6 node' but not necessarily run > ND. If it did, then ICMP could be used without intermediary, instead = of > CoAP. There are several parts of ND used for different purposes, and I think = that might be the source of some confusion here... 6lowpan does include a definition for how ND works over IEEE 802.15.14 = networks. There are some environments where ND is not used for address = autoconfiguration, where duplicate address detection (DAD) is = unnecessary, or where there are other means of determining whether = neighbors are reachable or not. In those environments, those parts of = ND are sometimes unnecessary. That doesn't mean that it is okay for a = general purpose IPv6 implementation to omit ND. I don't understand what it would even mean for ROLL (which is routing = protocol) or COAP (which is an HTTP compression protocol) to "use ND", = so I don't know how to comment on those. > Somebody said that if node is not implementing ICMPv6 > Redirect then it wouldnt't be accepted as an IPv6 node. I think this is something you may have taken away from a conversation = with me... You said that you have an IPv6 implementation that can only store one = default route (no default router list) and cannot store any other = routes. I told you that if you shipped that stack in a commercial = product, customers would be very unhappy with you because: (1) is not = acceptable (in the market) to ship and IPv6 node that can't fall back to = a second default router if the preferred one goes down, and (2) it is = not acceptable to ship an IP node that can't create a new route in = response to an ICMP redirect. That said, I believe it is also true that such a node would not be RFC = compliant, because IPv6 nodes are required to implement ICMPv6. Margaret From Ted.Lemon@nominum.com Thu Mar 29 05:36:57 2012 Return-Path: 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 167E721F8AE7 for ; Thu, 29 Mar 2012 05:36:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.488 X-Spam-Level: X-Spam-Status: No, score=-106.488 tagged_above=-999 required=5 tests=[AWL=0.111, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, 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 p1Sx+7+DLQPP for ; Thu, 29 Mar 2012 05:36:56 -0700 (PDT) Received: from exprod7og111.obsmtp.com (exprod7og111.obsmtp.com [64.18.2.175]) by ietfa.amsl.com (Postfix) with ESMTP id 091A021F8ADA for ; Thu, 29 Mar 2012 05:36:55 -0700 (PDT) Received: from shell-too.nominum.com ([64.89.228.229]) (using TLSv1) by exprod7ob111.postini.com ([64.18.6.12]) with SMTP ID DSNKT3RXZ7r3qVzxZmRf+g7OevuYVhzEpCZT@postini.com; Thu, 29 Mar 2012 05:36:56 PDT Received: from archivist.nominum.com (archivist.nominum.com [64.89.228.108]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "*.nominum.com", Issuer "Go Daddy Secure Certification Authority" (verified OK)) by shell-too.nominum.com (Postfix) with ESMTP id 1CB6F1B8213 for ; Thu, 29 Mar 2012 05:36:55 -0700 (PDT) Received: from webmail.nominum.com (cas-01.win.nominum.com [64.89.228.131]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (Client CN "mail.nominum.com", Issuer "Go Daddy Secure Certification Authority" (verified OK)) by archivist.nominum.com (Postfix) with ESMTPS id 139A4190064; Thu, 29 Mar 2012 05:36:55 -0700 (PDT) (envelope-from Ted.Lemon@nominum.com) Received: from MBX-01.WIN.NOMINUM.COM ([64.89.228.133]) by CAS-01.WIN.NOMINUM.COM ([64.89.228.131]) with mapi id 14.02.0247.003; Thu, 29 Mar 2012 05:36:55 -0700 From: Ted Lemon To: Alexandru Petrescu , Tomek Mrugalski Thread-Topic: [mif] Route option for DHCPv6 - next steps? Thread-Index: AQHNDL2jhfr6t6vyVEeGR+93z5NinJZ/3M2AgAG+LoD//4t2bYAAgpgAgAAAh4D//433iQ== Date: Thu, 29 Mar 2012 12:36:54 +0000 Message-ID: <8D23D4052ABE7A4490E77B1A012B6307472D42C2@mbx-01.win.nominum.com> References: <75459BC2-E733-45C0-BC1C-25A19BBA1137@gmail.com> <75D251D1-9828-4AFE-9BEF-B376E97133C7@nominum.com> <4A221CE5-ECF0-4E07-9329-E6BAA3F06A96@nominum.com> <4EC4AADB.8030803@piuha.net> <4F719186.3060507@gmail.com> <4F72CD22.3080604@gmail.com> , <4F744831.3070406@gmail.com> <8D23D4052ABE7A4490E77B1A012B6307472D4175@mbx-01.win.nominum.com> <4F7453FC.3010502@gmail.com>,<4F74546D.4060808@gmail.com> In-Reply-To: <4F74546D.4060808@gmail.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [192.168.1.10] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 29 Mar 2012 12:36:57 -0000 > We may be talking three timers: route lifetime, router lifetime (ND) and > renewal time. Router lifetime isn't an issue, since that's delivered via ND (right?). I= 'm saying that route lifetime MUST be >=3D renewal time. From alexandru.petrescu@gmail.com Thu Mar 29 05:57:27 2012 Return-Path: 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 8A16A21F88C9 for ; Thu, 29 Mar 2012 05:57:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.587 X-Spam-Level: X-Spam-Status: No, score=-3.587 tagged_above=-999 required=5 tests=[AWL=0.012, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] 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 BlZG9aQt1E-p for ; Thu, 29 Mar 2012 05:57:27 -0700 (PDT) Received: from mail-we0-f172.google.com (mail-we0-f172.google.com [74.125.82.172]) by ietfa.amsl.com (Postfix) with ESMTP id A520D21F8878 for ; Thu, 29 Mar 2012 05:57:26 -0700 (PDT) Received: by werb10 with SMTP id b10so1187053wer.31 for ; Thu, 29 Mar 2012 05:57:25 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; bh=QT3o8NMt+i/Px0GnG9czQyS1yUwDHJ3jm+3T1F27hsc=; b=ga9o3k+xv6dsd8G1QRqwSMqrWI6SGeX8Nn0L2rww/o5EfuS8fY8J29ZSzLxpCa4aEG 2VzE2i/yECl9VS2HpXbT4xTzFdD4+124p984HyLh79z+cmJGq7ZFjGz2L62EvLZF+djF D1EiVoqzq2+GlyYzX2C9pVtOOvvAoad/twiZR1oV2uMMCBaDAz+l0pDljO9O0U7skX2T /lg/4YgCbxdkN1PKqyFWarjqk+La+CXeyy4mNosny01I5SVuctURf5OiNT6kHO1BKzXQ aP7Zl2aK9/nOx4Eb42V1N6QSjzZVeG97wepDuKbOMNmNnLSMLPs13tiAb0VdMCLIjwlr 8u8g== Received: by 10.180.88.199 with SMTP id bi7mr5440462wib.12.1333025845790; Thu, 29 Mar 2012 05:57:25 -0700 (PDT) Received: from [130.129.17.29] (dhcp-111d.meeting.ietf.org. [130.129.17.29]) by mx.google.com with ESMTPS id 6sm30200900wiz.1.2012.03.29.05.57.24 (version=TLSv1/SSLv3 cipher=OTHER); Thu, 29 Mar 2012 05:57:24 -0700 (PDT) Message-ID: <4F745C2B.2050203@gmail.com> Date: Thu, 29 Mar 2012 14:57:15 +0200 From: Alexandru Petrescu User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:11.0) Gecko/20120312 Thunderbird/11.0 MIME-Version: 1.0 To: Margaret Wasserman References: <4F71AE51.4000304@gmail.com> <8D23D4052ABE7A4490E77B1A012B6307472C3EB0@mbx-02.win.nominum.com> <4F71FCFE.7080002@gmail.com> <4F723E25.2030303@gmail.com> <4F74439C.2050000@gmail.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Cc: mif Subject: Re: [mif] Conform to IPv6 while not running ND X-BeenThere: mif@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multiple Interface Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 29 Mar 2012 12:57:27 -0000 Le 29/03/2012 14:29, Margaret Wasserman a écrit : > > On Mar 29, 2012, at 1:12 PM, Alexandru Petrescu wrote: >> Allow me a quick reply here. There are several active RFC >> proposals recent at IETF that simply don't run ND. Or, how to >> better say - if ND is present it is completely ignored, being >> replaced by something else claimed better than ND for some issue >> at hand. >> >> This is the case for example in the RoLL (RPL protocol), 6lowpan >> (IPv6 over header compression) and more. If I understand >> correctly, CoAP considers the sensor node to be an 'IPv6 node' but >> not necessarily run ND. If it did, then ICMP could be used without >> intermediary, instead of CoAP. > > There are several parts of ND used for different purposes, and I > think that might be the source of some confusion here... > > 6lowpan does include a definition for how ND works over IEEE > 802.15.14 networks. > > There are some environments where ND is not used for address > autoconfiguration, where duplicate address detection (DAD) is > unnecessary, or where there are other means of determining whether > neighbors are reachable or not. In those environments, those parts > of ND are sometimes unnecessary. That doesn't mean that it is okay > for a general purpose IPv6 implementation to omit ND. > > I don't understand what it would even mean for ROLL (which is > routing protocol) Well yes RPL is a routing protocol and uses ICMP message types. There are number of ND incompatibility issues about it. > or COAP (which is an HTTP compression protocol) to "use ND", so I > don't know how to comment on those. Sorry, I dont know either. >> Somebody said that if node is not implementing ICMPv6 Redirect >> then it wouldnt't be accepted as an IPv6 node. > > I think this is something you may have taken away from a > conversation with me... > > You said that you have an IPv6 implementation that can only store > one default route (no default router list) and cannot store any > other routes. I said that if I were to store only one route that would be the default and not a specific route, because the default route is the only way to use a single routing entry table and reach the maximum number of destinations. The draft I am proposing proposes a list of default routers, not only one. > I told you that if you shipped that stack in a commercial product, > customers would be very unhappy with you because: (1) is not > acceptable (in the market) to ship and IPv6 node that can't fall back > to a second default router if the preferred one goes down, I agree. > and (2) it is not acceptable to ship an IP node that can't create a > new route in response to an ICMP redirect. This I am not sure. The point-to-point links (as in cellular) never use Redirects because there are no alternative routers on the link. I do agree though that Redirect is a necessary useful message on shared links. > That said, I believe it is also true that such a node would not be > RFC compliant, because IPv6 nodes are required to implement ICMPv6. In general I tend to agree. Just I am not sure how far this requirement goes when it comes to CoAP, RPL most header compression protocols. It may be just me. Yours, Alex > Margaret > > From alexandru.petrescu@gmail.com Thu Mar 29 06:03:25 2012 Return-Path: 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 8AB5821F8993 for ; Thu, 29 Mar 2012 06:03:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.587 X-Spam-Level: X-Spam-Status: No, score=-3.587 tagged_above=-999 required=5 tests=[AWL=0.012, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] 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 NQdy5-XrELn5 for ; Thu, 29 Mar 2012 06:03:24 -0700 (PDT) Received: from mail-wi0-f172.google.com (mail-wi0-f172.google.com [209.85.212.172]) by ietfa.amsl.com (Postfix) with ESMTP id 6E9DE21F8992 for ; Thu, 29 Mar 2012 06:03:24 -0700 (PDT) Received: by wibhj6 with SMTP id hj6so29919wib.13 for ; Thu, 29 Mar 2012 06:03:23 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; bh=Kc2W+/0aYv12J9qD7RByz2E8h4VXpkpLc7flMpwcXNA=; b=ND05+tUa+DkfeEKZ2aZo+EwA9PLzQxOhvjpNHw8YGqKOA1IbV8FGmii6QHIbJwxgey ONr0QFuW3B8OoPV6RfHsaSMdG5NtO6QnZsDmV/+BTgnOyzkBV7h7bScJtHFeszTjrfOC RWrachCjZhXEBDYno083Z+lacsFUl1fLJaSzRf3PckJ8IOeOisvQT8Y6X5qvUD0/aLxf XKEjfyr5IfSSshYtYzhqpuzr1XNQhek3X99Hh+y8LYDCFTCrQYJ0aCCNYr/VtAi5yBlG Jj8wNfqSqSx+8Q71adFlvj6ADHaPyZ2zukPMAeNblfvkwZwwmCMWoFDZH67KP7PJkbJc gaPw== Received: by 10.180.80.70 with SMTP id p6mr5397833wix.21.1333026203631; Thu, 29 Mar 2012 06:03:23 -0700 (PDT) Received: from [130.129.17.29] (dhcp-111d.meeting.ietf.org. [130.129.17.29]) by mx.google.com with ESMTPS id fl2sm28597894wib.4.2012.03.29.06.03.22 (version=TLSv1/SSLv3 cipher=OTHER); Thu, 29 Mar 2012 06:03:23 -0700 (PDT) Message-ID: <4F745D91.2050608@gmail.com> Date: Thu, 29 Mar 2012 15:03:13 +0200 From: Alexandru Petrescu User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:11.0) Gecko/20120312 Thunderbird/11.0 MIME-Version: 1.0 To: Ted Lemon References: <75459BC2-E733-45C0-BC1C-25A19BBA1137@gmail.com> <75D251D1-9828-4AFE-9BEF-B376E97133C7@nominum.com> <4A221CE5-ECF0-4E07-9329-E6BAA3F06A96@nominum.com> <4EC4AADB.8030803@piuha.net> <4F719186.3060507@gmail.com> <4F72CD22.3080604@gmail.com> , <4F744831.3070406@gmail.com> <8D23D4052ABE7A4490E77B1A012B6307472D4175@mbx-01.win.nominum.com> <4F7453FC.3010502@gmail.com>, <4F74546D.4060808@gmail.com> <8D23D4052ABE7A4490E77B1A012B6307472D42C2@mbx-01.win.nominum.com> In-Reply-To: <8D23D4052ABE7A4490E77B1A012B6307472D42C2@mbx-01.win.nominum.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Cc: "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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 29 Mar 2012 13:03:25 -0000 Le 29/03/2012 14:36, Ted Lemon a écrit : >> We may be talking three timers: route lifetime, router lifetime >> (ND) and renewal time. > > Router lifetime isn't an issue, since that's delivered via ND > (right?). Right, router lifetime is delivered by ND. > I'm saying that route lifetime MUST be>= renewal time. That sounds logic. But what is that "route lifetime" - which protocol specifies it? With which other protocol should this DHCP operation be compatible? (in case of _default_ routes, it's ND and it's Router Lifetime, in my interpretation). Alex From mrw@lilacglade.org Thu Mar 29 06:40:56 2012 Return-Path: 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 1D09E21E801A for ; Thu, 29 Mar 2012 06:40:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.329 X-Spam-Level: X-Spam-Status: No, score=-102.329 tagged_above=-999 required=5 tests=[AWL=-0.064, BAYES_00=-2.599, 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 P02UoOvvFx0u for ; Thu, 29 Mar 2012 06:40:55 -0700 (PDT) Received: from permutation-city.suchdamage.org (permutation-city.suchdamage.org [69.25.196.28]) by ietfa.amsl.com (Postfix) with ESMTP id E05B321F8B53 for ; Thu, 29 Mar 2012 06:40:49 -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 CBA24204D5; Thu, 29 Mar 2012 09:40:03 -0400 (EDT) Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=iso-8859-1 From: Margaret Wasserman In-Reply-To: <4F74546D.4060808@gmail.com> Date: Thu, 29 Mar 2012 15:40:48 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: References: <75459BC2-E733-45C0-BC1C-25A19BBA1137@gmail.com> <75D251D1-9828-4AFE-9BEF-B376E97133C7@nominum.com> <4A221CE5-ECF0-4E07-9329-E6BAA3F06A96@nominum.com> <4EC4AADB.8030803@piuha.net> <4F719186.3060507@gmail.com> <4F72CD22.3080604@gmail.com> , <4F744831.3070406@gmail.com> <8D23D4052ABE7A4490E77B1A012B6307472D4175@mbx-01.win.nominum.com> <4F7453FC.3010502@gmail.com> <4F74546D.4060808@gmail.com> To: Alexandru Petrescu X-Mailer: Apple Mail (2.1084) Cc: "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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 29 Mar 2012 13:40:56 -0000 Hi Alex, On Mar 29, 2012, at 2:24 PM, Alexandru Petrescu wrote: > Le 29/03/2012 14:22, Tomek Mrugalski a =E9crit : >> On 12-03-29 13:35, Ted Lemon wrote: >>> Probably the best thing to do is set the router lifetime to the DHCP >>> renewal time, and not send a lifetime separate from that. >> We are talking about two timers here: route lifetime and renewal time >> (governed by information refresh time, defined in RFC4242). Will add >> clarification text that route lifetime should be greater than >> information refresh time. Making them equal is not a such good idea = as >> it could trigger race conditions. Otherwise badness will happen. >=20 > We may be talking three timers: route lifetime, router lifetime (ND) = and renewal time. I am not exactly sure what you mean by a "timer" in this sentence? In = the implementations I have done, there is no "timer" (in the embedded = systems sense) associated with each route entry. There is a timestamp = that indicates the current end of the valid lifetime for that route (the = expiry time). Before a route is used, the expiry time is checked to see = if it is still valid. Each routing table entry would have (at most) one = expiry time associated with it. Static routes have no expiry time. Margaret From mrw@lilacglade.org Thu Mar 29 06:46:55 2012 Return-Path: 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 EC57C21F8B2E for ; Thu, 29 Mar 2012 06:46:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.327 X-Spam-Level: X-Spam-Status: No, score=-102.327 tagged_above=-999 required=5 tests=[AWL=-0.062, BAYES_00=-2.599, 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 kBNGf8So-WQW for ; Thu, 29 Mar 2012 06:46:55 -0700 (PDT) Received: from permutation-city.suchdamage.org (permutation-city.suchdamage.org [69.25.196.28]) by ietfa.amsl.com (Postfix) with ESMTP id 043A221F8B2D for ; Thu, 29 Mar 2012 06:46:55 -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 E6455204D5; Thu, 29 Mar 2012 09:46:08 -0400 (EDT) Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Margaret Wasserman In-Reply-To: <4F74546D.4060808@gmail.com> Date: Thu, 29 Mar 2012 15:46:52 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <72C42575-6BE2-4F27-B7F4-AA4539DA7EF9@lilacglade.org> References: <75459BC2-E733-45C0-BC1C-25A19BBA1137@gmail.com> <75D251D1-9828-4AFE-9BEF-B376E97133C7@nominum.com> <4A221CE5-ECF0-4E07-9329-E6BAA3F06A96@nominum.com> <4EC4AADB.8030803@piuha.net> <4F719186.3060507@gmail.com> <4F72CD22.3080604@gmail.com> , <4F744831.3070406@gmail.com> <8D23D4052ABE7A4490E77B1A012B6307472D4175@mbx-01.win.nominum.com> <4F7453FC.3010502@gmail.com> <4F74546D.4060808@gmail.com> To: Alexandru Petrescu X-Mailer: Apple Mail (2.1084) Cc: "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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 29 Mar 2012 13:46:56 -0000 Speaking solely as a technical contributor... I think this entire discussion of a "lifetime" of default routes being = assigned via DHCP is going off the rails, and I'd like to explain why. The DHCPv6 route option is _not_ a dynamic routing protocol. The DHCP = server doesn't fate share with the routing infrastructure and isn't = expected to get route updates from routing protocols. The purpose of = the DHCPv6 route option is to allow centralized configuration of _static = routes_ on a DHCPv6 configured node. These can, and should be, the same = sort of static routes as one can configure at a CLI ("sudo route add = ..."), via SNMP, or potentially at an administrative UI. The purpose = of putting this option in DHCP is to allow site admins to configure = these routes, on a per-node basis if desired, from a central location, = rather than needed to do it on each machine that joins that local = network. =20 So, why are we talking about route lifetimes, as though we think that = some entity will come along and refresh this information on a regular = basis? Obviously, like all DHCP config, this information should be flushed when = the node moves to a new network and begins a new DHCP exchange. But, = when the nodes stays on one network, it should remain constant, just = like a DHCPv6-configured DNS Server list or NTP Server list. =20 Shouldn't it? Margaret From Ted.Lemon@nominum.com Thu Mar 29 06:48:50 2012 Return-Path: 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 24BC621F8A60 for ; Thu, 29 Mar 2012 06:48:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.49 X-Spam-Level: X-Spam-Status: No, score=-106.49 tagged_above=-999 required=5 tests=[AWL=0.109, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, 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 71nrLeHD0LUS for ; Thu, 29 Mar 2012 06:48:48 -0700 (PDT) Received: from exprod7og122.obsmtp.com (exprod7og122.obsmtp.com [64.18.2.22]) by ietfa.amsl.com (Postfix) with ESMTP id 2E9DC21F8B0A for ; Thu, 29 Mar 2012 06:48:42 -0700 (PDT) Received: from shell-too.nominum.com ([64.89.228.229]) (using TLSv1) by exprod7ob122.postini.com ([64.18.6.12]) with SMTP ID DSNKT3RoOY0sIartf853OAnTil5eeuPj6AOH@postini.com; Thu, 29 Mar 2012 06:48:42 PDT Received: from archivist.nominum.com (archivist.nominum.com [64.89.228.108]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "*.nominum.com", Issuer "Go Daddy Secure Certification Authority" (verified OK)) by shell-too.nominum.com (Postfix) with ESMTP id 60F101B807D for ; Thu, 29 Mar 2012 06:48:41 -0700 (PDT) Received: from webmail.nominum.com (cas-01.win.nominum.com [64.89.228.131]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (Client CN "mail.nominum.com", Issuer "Go Daddy Secure Certification Authority" (verified OK)) by archivist.nominum.com (Postfix) with ESMTPS id 535A1190064; Thu, 29 Mar 2012 06:48:41 -0700 (PDT) (envelope-from Ted.Lemon@nominum.com) Received: from MBX-01.WIN.NOMINUM.COM ([64.89.228.133]) by CAS-01.WIN.NOMINUM.COM ([64.89.228.131]) with mapi id 14.02.0247.003; Thu, 29 Mar 2012 06:48:41 -0700 From: Ted Lemon To: Alexandru Petrescu Thread-Topic: [mif] Route option for DHCPv6 - next steps? Thread-Index: AQHNDL2jhfr6t6vyVEeGR+93z5NinJZ/3M2AgAG+LoD//4t2bYAAgpgAgAAAh4D//433iYAAfO+A//+Wf5A= Date: Thu, 29 Mar 2012 13:48:41 +0000 Message-ID: <8D23D4052ABE7A4490E77B1A012B6307472D4392@mbx-01.win.nominum.com> References: <75459BC2-E733-45C0-BC1C-25A19BBA1137@gmail.com> <75D251D1-9828-4AFE-9BEF-B376E97133C7@nominum.com> <4A221CE5-ECF0-4E07-9329-E6BAA3F06A96@nominum.com> <4EC4AADB.8030803@piuha.net> <4F719186.3060507@gmail.com> <4F72CD22.3080604@gmail.com> , <4F744831.3070406@gmail.com> <8D23D4052ABE7A4490E77B1A012B6307472D4175@mbx-01.win.nominum.com> <4F7453FC.3010502@gmail.com>,<4F74546D.4060808@gmail.com> <8D23D4052ABE7A4490E77B1A012B6307472D42C2@mbx-01.win.nominum.com>, <4F745D91.2050608@gmail.com> In-Reply-To: <4F745D91.2050608@gmail.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [192.168.1.10] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 29 Mar 2012 13:48:50 -0000 >> I'm saying that route lifetime MUST be>=3D renewal time. > That sounds logic. I misspoke here: the lifetime must be >=3D the valid lifetime of the addres= s for a statefully configured address, and > perhaps 2* the IRT for statele= ss. > But what is that "route lifetime" - which protocol specifies it? With > which other protocol should this DHCP operation be compatible? If the route is acquired through ND, its maintenance is up to ND, and isn't= the DHCP server's problem, so there's no need to specify in this case. S= imilarly with the router lifetime. However, if by "router lifetime" you m= ean the lifetime of the ND result, that's really orthogonal, since the expe= ctation is that this option will not be used in cases where routers are com= ing and going, and so it's not expected that ND on the router will fail; if= it does, it's a service outage for that network, not an opportunity to dis= cover a new route. From Ted.Lemon@nominum.com Thu Mar 29 06:52:15 2012 Return-Path: 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 296C521F8885 for ; Thu, 29 Mar 2012 06:52:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.491 X-Spam-Level: X-Spam-Status: No, score=-106.491 tagged_above=-999 required=5 tests=[AWL=0.108, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, 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 V1DfyXgx4Yp6 for ; Thu, 29 Mar 2012 06:52:14 -0700 (PDT) Received: from exprod7og103.obsmtp.com (exprod7og103.obsmtp.com [64.18.2.159]) by ietfa.amsl.com (Postfix) with ESMTP id 5333621F8833 for ; Thu, 29 Mar 2012 06:52:12 -0700 (PDT) Received: from shell-too.nominum.com ([64.89.228.229]) (using TLSv1) by exprod7ob103.postini.com ([64.18.6.12]) with SMTP ID DSNKT3RpC4z1ea8YUdCwC2SETp+b7PBU8/Di@postini.com; Thu, 29 Mar 2012 06:52:12 PDT Received: from archivist.nominum.com (archivist.nominum.com [64.89.228.108]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "*.nominum.com", Issuer "Go Daddy Secure Certification Authority" (verified OK)) by shell-too.nominum.com (Postfix) with ESMTP id 080521B807D for ; Thu, 29 Mar 2012 06:52:11 -0700 (PDT) Received: from webmail.nominum.com (cas-02.win.nominum.com [64.89.228.132]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (Client CN "mail.nominum.com", Issuer "Go Daddy Secure Certification Authority" (verified OK)) by archivist.nominum.com (Postfix) with ESMTPS id F2929190064; Thu, 29 Mar 2012 06:52:10 -0700 (PDT) (envelope-from Ted.Lemon@nominum.com) Received: from MBX-01.WIN.NOMINUM.COM ([64.89.228.133]) by CAS-02.WIN.NOMINUM.COM ([64.89.228.132]) with mapi id 14.02.0247.003; Thu, 29 Mar 2012 06:52:11 -0700 From: Ted Lemon To: Margaret Wasserman , Alexandru Petrescu Thread-Topic: [mif] Route option for DHCPv6 - next steps? Thread-Index: AQHNDL2jhfr6t6vyVEeGR+93z5NinJZ/3M2AgAG+LoD//4t2bYAAgpgAgAAAh4CAABcYAP//i0r4 Date: Thu, 29 Mar 2012 13:52:08 +0000 Message-ID: <8D23D4052ABE7A4490E77B1A012B6307472D43A1@mbx-01.win.nominum.com> References: <75459BC2-E733-45C0-BC1C-25A19BBA1137@gmail.com> <75D251D1-9828-4AFE-9BEF-B376E97133C7@nominum.com> <4A221CE5-ECF0-4E07-9329-E6BAA3F06A96@nominum.com> <4EC4AADB.8030803@piuha.net> <4F719186.3060507@gmail.com> <4F72CD22.3080604@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> In-Reply-To: <72C42575-6BE2-4F27-B7F4-AA4539DA7EF9@lilacglade.org> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [192.168.1.10] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 29 Mar 2012 13:52:15 -0000 > The DHCPv6 route option is _not_ a dynamic routing protocol. [etc] Wow, thanks, that's a really good point. It would be a big improvement to= this protocol if in fact we operated that way. However, there is one issue to consider: what happens when a route is remov= ed from the configuration of the DHCP server after it's been installed by a= client, and a new route replaces it? We'd like that route to expire. S= o even though I think you are right that we should *consider* these routes = to be essentially statiic, I think we still need to put lifetimes on them o= n the client side, when the client installs the route. This lifetime shou= ld be long enough that we can count on the routing table entry being refres= hed by a DHCP renewal or DHCP information refresh before the entry expires,= but short enough that if a route is removed from the DHCP server configura= tion, it does not remain, stale, in the client's routing table for an incon= venient time. From mglt.ietf@gmail.com Thu Mar 29 08:20:43 2012 Return-Path: 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 6BF6821F8847; Thu, 29 Mar 2012 08:20:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.474 X-Spam-Level: X-Spam-Status: No, score=-3.474 tagged_above=-999 required=5 tests=[AWL=0.124, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] 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 FDv1VaGnx-lB; Thu, 29 Mar 2012 08:20:42 -0700 (PDT) Received: from mail-yx0-f172.google.com (mail-yx0-f172.google.com [209.85.213.172]) by ietfa.amsl.com (Postfix) with ESMTP id 39D0321F883F; Thu, 29 Mar 2012 08:20:42 -0700 (PDT) Received: by yenm5 with SMTP id m5so1705809yen.31 for ; Thu, 29 Mar 2012 08:20:41 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type; bh=XSj4mm6v+u2cHtSm/zEtKifghznIUo7kXhDJszeIKbA=; b=sT2dYiAMqyxaskqkJedG43QI+aEj/Nh+51GQslY4pfy0Ub0CBI/L4I/iHjIkfZEG2U TWrz0h0xB0XJSISoWF+RY0lSxIK691wR4hYyJ/1jQzfyGxEi3K+kXQiCfQcjLK8NIUdq 263a/v9zdZyIE5oTptrSimXn4a3qm+bPWwnRhe3CLWFgnhqg8jdmfUenX9mtUT05iQOG eK0sjW6M7kWFSSFtaK/3h1WXHnn/k6PluXncWY2DHU6LyQyFvwdNupszz2y4hMNTDl3N LGqs/Qs5Ab0PmoZ7K1cN9o+pxIFXwd/zZhLMGxiRkguPJ16kWv/Zlj6uu5OhdRm+pffZ ZMMg== MIME-Version: 1.0 Received: by 10.68.125.195 with SMTP id ms3mr745941pbb.62.1333034441316; Thu, 29 Mar 2012 08:20:41 -0700 (PDT) Received: by 10.142.133.19 with HTTP; Thu, 29 Mar 2012 08:20:41 -0700 (PDT) In-Reply-To: <20120329151424.12323.65627.idtracker@ietfa.amsl.com> References: <20120329151424.12323.65627.idtracker@ietfa.amsl.com> Date: Thu, 29 Mar 2012 17:20:41 +0200 Message-ID: From: Daniel Migault To: mif@ietf.org, "multipathtcp@ietf.org Mailing List" Content-Type: multipart/alternative; boundary=047d7b2e4cdc5918cf04bc634450 Subject: [mif] Fwd: New Version Notification for draft-mglt-mif-security-requirements-01.txt X-BeenThere: mif@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multiple Interface Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 29 Mar 2012 15:20:43 -0000 --047d7b2e4cdc5918cf04bc634450 Content-Type: text/plain; charset=ISO-8859-1 Hi, Please find the version 01 of draft-mglt-mif-security-requirements-01.txt. Feel free to make comments on it. We would like to thank those who provided comments for version 00. They were very useful for us. Regards, Daniel ---------- Forwarded message ---------- From: Date: Thu, Mar 29, 2012 at 5:14 PM Subject: New Version Notification for draft-mglt-mif-security-requirements-01.txt To: mglt.ietf@gmail.com Cc: carlw@mcsr-labs.org A new version of I-D, draft-mglt-mif-security-requirements-01.txt has been successfully submitted by Daniel Migault and posted to the IETF repository. Filename: draft-mglt-mif-security-requirements Revision: 01 Title: Multiple Interfaces IPsec Security Requirements Creation date: 2012-03-29 WG ID: Individual Submission Number of pages: 11 Abstract: ISPs wants to take advantage of MIF Transport protocols like SCTP, MPTCP to enhance their End User's experience when the End User has been offloaded on WLAN. In addition, WLAN are untrusted so ISPs MUST Secure at least some of their End Users's communications. For various reasons IPsec is the protocol they choose to secure the communications. Currently, IPsec is not adapted to Multiple Interfaces Environment. IPsec can hardly be configured in a proper way which may result in breaking End Users' communications. At least, it makes it very hard for the End Users to combine Security with MIF enhancements. MOBIKE partly address the problem for a single Interface. This draft provides the problem statement and defines the IPsec Security Requirements for MIF. The IETF Secretariat -- Daniel Migault Orange Labs -- Security +33 6 70 72 69 58 --047d7b2e4cdc5918cf04bc634450 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Hi,
Please find the version 01 of draft-mglt-mif-security-requirements-0= 1.txt. Feel free to make comments on it.
We would like to thank those wh= o provided comments for version 00. They were very useful for us.

Regards,
Daniel

---------- Forwarded = message ----------
From: <internet-drafts@ietf.= org>
Date: Thu, Mar 29, 2012 at 5:14 PM
Subject: New Version Notification for= draft-mglt-mif-security-requirements-01.txt
To: mglt.ietf@gmail.com
Cc: carlw@mcsr-labs.org


A new version of I-D, draft-mglt-mif-security-requirements-01.txt h= as been successfully submitted by Daniel Migault and posted to the IETF rep= ository.

Filename: =A0 =A0 =A0 =A0draft-mglt-mif-security-requirements
Revision: =A0 =A0 =A0 =A001
Title: =A0 =A0 =A0 =A0 =A0 Multiple Interfaces IPsec Security Requirements<= br> Creation date: =A0 2012-03-29
WG ID: =A0 =A0 =A0 =A0 =A0 Individual Submission
Number of pages: 11

Abstract:
=A0 ISPs wants to take advantage of MIF Transport protocols like SCTP,
=A0 MPTCP to enhance their End User&#39;s experience when the End User= has
=A0 been offloaded on WLAN. =A0In addition, WLAN are untrusted so ISPs MUS= T
=A0 Secure at least some of their End Users&#39;s communications. =A0F= or
=A0 various reasons IPsec is the protocol they choose to secure the
=A0 communications. =A0Currently, IPsec is not adapted to Multiple
=A0 Interfaces Environment. =A0IPsec can hardly be configured in a proper<= br> =A0 way which may result in breaking End Users&#39; communications. = =A0At
=A0 least, it makes it very hard for the End Users to combine Security
=A0 with MIF enhancements. =A0MOBIKE partly address the problem for a
=A0 single Interface. =A0This draft provides the problem statement and
=A0 defines the IPsec Security Requirements for MIF.




The IETF Secretariat



--
Daniel Migault
Orange Labs -- Sec= urity
+33 6 70 72 69 58
--047d7b2e4cdc5918cf04bc634450-- From alexandru.petrescu@gmail.com Thu Mar 29 09:46:52 2012 Return-Path: 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 8B8BE21F86F3 for ; Thu, 29 Mar 2012 09:46:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.589 X-Spam-Level: X-Spam-Status: No, score=-3.589 tagged_above=-999 required=5 tests=[AWL=0.010, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] 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 001p83vaL1Cg for ; Thu, 29 Mar 2012 09:46:51 -0700 (PDT) Received: from mail-wi0-f178.google.com (mail-wi0-f178.google.com [209.85.212.178]) by ietfa.amsl.com (Postfix) with ESMTP id 412C221F86E1 for ; Thu, 29 Mar 2012 09:46:51 -0700 (PDT) Received: by wibhq7 with SMTP id hq7so204287wib.13 for ; Thu, 29 Mar 2012 09:46:50 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:subject :content-type:content-transfer-encoding; bh=xVZdVUVu0XH5rCYFqbrCAnM02AOoGtiOtIXvAVNbARc=; b=c8HUV3lS+66a3kC5DtKmA/dxSI4GfZZyD43NsZ1vIHK4pqVA81ecJEU5vykV98+5+t 5Z65Hm0kZXLjDDuTSrQpSDdSZCjdoHoOACv1R9xWRHMVtrUKfq6KY2hPuS19THsdBA8b slB8ZST3R9TFl+yBdzrxPqKwD65X00BT51r8KvkH+ZlWOoHZAuQuumXp8I7fYyAZY5em 60oMnZPbwuvMIUdj176hcOOVGZ562CZ/NiEwKK+uDTR/uu+drqChgksZMRJ4F/d9NFsp 7hz1SBk1nWgFJb7GV5aOdUuvzXPTUQaUTQTaUyrhLR+5plK+uYGrgqQQvtMRg2GyaRW/ 5RoA== Received: by 10.180.86.132 with SMTP id p4mr6907270wiz.15.1333039610451; Thu, 29 Mar 2012 09:46:50 -0700 (PDT) Received: from [130.129.17.29] (dhcp-111d.meeting.ietf.org. [130.129.17.29]) by mx.google.com with ESMTPS id ff2sm30722677wib.9.2012.03.29.09.46.49 (version=TLSv1/SSLv3 cipher=OTHER); Thu, 29 Mar 2012 09:46:49 -0700 (PDT) Message-ID: <4F7491F0.3040205@gmail.com> Date: Thu, 29 Mar 2012 18:46:40 +0200 From: Alexandru Petrescu User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:11.0) Gecko/20120312 Thunderbird/11.0 MIME-Version: 1.0 To: mif Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: [mif] Prefix Delegation for RA... X-BeenThere: mif@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multiple Interface Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 29 Mar 2012 16:46:52 -0000 What would solve the scenario with M2M for LTE, router, would be RA with Prefix Delegation in it... w/o DHCP. I believe htere was an I-D at some point in time about this. Alex From alh-ietf@tndh.net Thu Mar 29 10:35:37 2012 Return-Path: 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 56D2121E8183 for ; Thu, 29 Mar 2012 10:35:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.846 X-Spam-Level: X-Spam-Status: No, score=-0.846 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_HOST_EQ_D_D_D_D=0.765, FH_HOST_EQ_D_D_D_DB=0.888, RDNS_DYNAMIC=0.1] 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 X0AoH3BVcoq3 for ; Thu, 29 Mar 2012 10:35:36 -0700 (PDT) Received: from tndh.net (75-149-170-53-Washington.hfc.comcastbusiness.net [75.149.170.53]) by ietfa.amsl.com (Postfix) with ESMTP id C874821E8162 for ; Thu, 29 Mar 2012 10:35:36 -0700 (PDT) X-AuthUser: alh-ietf@tndh.net Received: from eaglet ([172.20.144.31]:37535) by tndh.net with [XMail 1.27 ESMTP Server] id for from ; Thu, 29 Mar 2012 10:35:34 -0700 From: "Tony Hain" To: "'Ted Lemon'" , "'Margaret Wasserman'" , "'Alexandru Petrescu'" References: <75459BC2-E733-45C0-BC1C-25A19BBA1137@gmail.com> <75D251D1-9828-4AFE-9BEF-B376E97133C7@nominum.com> <4A221CE5-ECF0-4E07-9329-E6BAA3F06A96@nominum.com> <4EC4AADB.8030803@piuha.net> <4F719186.3060507@gmail.com> <4F72CD22.3080604@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> In-Reply-To: <8D23D4052ABE7A4490E77B1A012B6307472D43A1@mbx-01.win.nominum.com> Date: Thu, 29 Mar 2012 10:35:32 -0700 Message-ID: <069301cd0dd2$5954df00$0bfe9d00$@tndh.net> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQGYocXPKzopiDhicKFSNXe3ky5PRQFWcj/vAj3jZD8CE4SQEAM8EDN1Aal2DB8CuqDa4AGu3TE6AouFInYBmOpBUgHiAfgSAabbPDMCVhY93gK9RQNgAaU+fSYBVklIJAKKPEcuAtiEBeKVybGXMA== Content-Language: en-us Cc: 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 29 Mar 2012 17:35:37 -0000 I asked this on the jabber, but it should probably go the mail list as well... Why is this not RFC 3442bis? DHCP option 121 already does this function for IPv4, so this is really just creating the IPv6 version of the existing option. It is required for VPN split tunnel, so the entire question about doing it or not is moot. People use 121 / 249 (MSFT private version that instigated 3442), so they need the IPv6 version of that. Tony -----Original Message----- From: mif-bounces@ietf.org [mailto:mif-bounces@ietf.org] On Behalf Of Ted Lemon Sent: Thursday, March 29, 2012 6:52 AM To: Margaret Wasserman; Alexandru Petrescu Cc: mif@ietf.org Subject: Re: [mif] Route option for DHCPv6 - next steps? > The DHCPv6 route option is _not_ a dynamic routing protocol. [etc] Wow, thanks, that's a really good point. It would be a big improvement to this protocol if in fact we operated that way. However, there is one issue to consider: what happens when a route is removed from the configuration of the DHCP server after it's been installed by a client, and a new route replaces it? We'd like that route to expire. So even though I think you are right that we should *consider* these routes to be essentially statiic, I think we still need to put lifetimes on them on the client side, when the client installs the route. This lifetime should be long enough that we can count on the routing table entry being refreshed by a DHCP renewal or DHCP information refresh before the entry expires, but short enough that if a route is removed from the DHCP server configuration, it does not remain, stale, in the client's routing table for an inconvenient time. _______________________________________________ mif mailing list mif@ietf.org https://www.ietf.org/mailman/listinfo/mif From Ted.Lemon@nominum.com Thu Mar 29 14:37:27 2012 Return-Path: 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 86CBD21F84FD for ; Thu, 29 Mar 2012 14:37:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.335 X-Spam-Level: X-Spam-Status: No, score=-106.335 tagged_above=-999 required=5 tests=[AWL=-0.051, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, SARE_MILLIONSOF=0.315, 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 CkkovtzyTZ5u for ; Thu, 29 Mar 2012 14:37:26 -0700 (PDT) Received: from exprod7og114.obsmtp.com (exprod7og114.obsmtp.com [64.18.2.215]) by ietfa.amsl.com (Postfix) with ESMTP id 6D6A021F84F8 for ; Thu, 29 Mar 2012 14:37:25 -0700 (PDT) Received: from shell-too.nominum.com ([64.89.228.229]) (using TLSv1) by exprod7ob114.postini.com ([64.18.6.12]) with SMTP ID DSNKT3TWFB9Cahw9uFBXI7gOWlxK3CnKUL1m@postini.com; Thu, 29 Mar 2012 14:37:25 PDT Received: from archivist.nominum.com (archivist.nominum.com [64.89.228.108]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "*.nominum.com", Issuer "Go Daddy Secure Certification Authority" (verified OK)) by shell-too.nominum.com (Postfix) with ESMTP id 62BA21B80C9 for ; Thu, 29 Mar 2012 14:37:24 -0700 (PDT) Received: from webmail.nominum.com (cas-02.win.nominum.com [64.89.228.132]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (Client CN "mail.nominum.com", Issuer "Go Daddy Secure Certification Authority" (verified OK)) by archivist.nominum.com (Postfix) with ESMTPS id 596A9190064; Thu, 29 Mar 2012 14:37:24 -0700 (PDT) (envelope-from Ted.Lemon@nominum.com) Received: from MBX-01.WIN.NOMINUM.COM ([64.89.228.133]) by CAS-02.WIN.NOMINUM.COM ([64.89.228.132]) with mapi id 14.02.0247.003; Thu, 29 Mar 2012 14:37:24 -0700 From: Ted Lemon To: Tony Hain Thread-Topic: [mif] Route option for DHCPv6 - next steps? Thread-Index: AQHNDL2jhfr6t6vyVEeGR+93z5NinJZ/3M2AgAG+LoD//4t2bYAAgpgAgAAAh4CAABcYAP//i0r4gAC0mQD//8qt3g== Date: Thu, 29 Mar 2012 21:37:23 +0000 Message-ID: <8D23D4052ABE7A4490E77B1A012B6307472D45F6@mbx-01.win.nominum.com> References: <75459BC2-E733-45C0-BC1C-25A19BBA1137@gmail.com> <75D251D1-9828-4AFE-9BEF-B376E97133C7@nominum.com> <4A221CE5-ECF0-4E07-9329-E6BAA3F06A96@nominum.com> <4EC4AADB.8030803@piuha.net> <4F719186.3060507@gmail.com> <4F72CD22.3080604@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> In-Reply-To: <069301cd0dd2$5954df00$0bfe9d00$@tndh.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [192.168.1.10] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 29 Mar 2012 21:37:27 -0000 > Why is this not RFC 3442bis? DHCP option 121 already does this function = for > IPv4, so this is really just creating the IPv6 version of the existing > option. It is required for VPN split tunnel, so the entire question about > doing it or not is moot. People use 121 / 249 (MSFT private version that > instigated 3442), so they need the IPv6 version of that. This wasn't about what is needed. This was about a public lynching of a = group that entertained an idea that is politically incorrect. If you look= at the reasons that were raised today, they were all garbage, with all due= respect to the generally very sensible and wise people who had the poor ju= dgment to offer them. We had one person, an operator, saying "for god's s= ake don't make this option, because I would not want to run a network on wh= ich this option was used," at the same time that another couple of people w= ho work for very large companies and have pretty close to final say in how = their networks are operated saying "if we allow this draft, willfylly stupi= d people will deploy itin places where it will work really poorly, it will = be widely adopted, and then network effects will force us to deploy it as w= ell." This document has been raised, in one form or another, every year or so for= the past five or six years. There's always a public lynching. It alway= s gets raised again, because there is demand. Numerous contributors to th= e IETF have wasted years working on this. Today many millions of tons of = carbon were put into the atmosphere in order that we might have another pub= lic lynching rather than getting about the business of the mif working grou= p. As a consequence of this useless lynching, I didn't get to hear any of= the presentations that followed it on the mif docket. I wish I could claim that I had never unwisely participated in a public was= te of time like the one we had today, but I can't. I'm sure people readin= g this are laughing in their sleeves to hear me complaining about this. B= ut I really wish we could stop doing this. The participants in today's lyn= ching should take a lesson from the working group's response when today's d= raft was killed. Everybody still wants it. When we are done smarting fr= om the spanking we got today, it will get raised again, maybe in a differen= t working group. This will keep happening until we all die of old age and= our metaphorical children, who have no recollection of the prejudices of t= he day, finally write it up and wonder why it took so long for it to get do= ne. 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 o= n 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 spl= it tunnel case isn't familiar to me. From mrw@lilacglade.org Fri Mar 30 00:21:44 2012 Return-Path: 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 ; 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 ; 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 ; 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 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> <75D251D1-9828-4AFE-9BEF-B376E97133C7@nominum.com> <4A221CE5-ECF0-4E07-9329-E6BAA3F06A96@nominum.com> <4EC4AADB.8030803@piuha.net> <4F719186.3060507@gmail.com> <4F72CD22.3080604@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 X-Mailer: Apple Mail (2.1084) Cc: "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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 30 Mar 2012 07:21:44 -0000 --Apple-Mail-15-450089456 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Hi Ted, On Mar 29, 2012, at 11:37 PM, Ted Lemon wrote: >=20 > 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. =20 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 --Apple-Mail-15-450089456 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii

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


=




<= /html>= --Apple-Mail-15-450089456-- From teemu.savolainen@nokia.com Fri Mar 30 00:33:22 2012 Return-Path: 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 3C9DE21F8611 for ; Fri, 30 Mar 2012 00:33:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.122 X-Spam-Level: X-Spam-Status: No, score=-5.122 tagged_above=-999 required=5 tests=[AWL=1.477, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] 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 InTgTzmJsovq for ; Fri, 30 Mar 2012 00:33:21 -0700 (PDT) Received: from mgw-da01.nokia.com (smtp.nokia.com [147.243.128.24]) by ietfa.amsl.com (Postfix) with ESMTP id 7621F21F850B for ; Fri, 30 Mar 2012 00:33:21 -0700 (PDT) Received: from vaebh104.NOE.Nokia.com (vaebh104.europe.nokia.com [10.160.244.30]) by mgw-da01.nokia.com (Sentrion-MTA-4.2.2/Sentrion-MTA-4.2.2) with ESMTP id q2U7Wsdo005547; Fri, 30 Mar 2012 10:33:14 +0300 Received: from smtp.mgd.nokia.com ([65.54.30.20]) by vaebh104.NOE.Nokia.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.4675); Fri, 30 Mar 2012 10:32:56 +0300 Received: from 008-AM1MPN1-053.mgdnok.nokia.com ([169.254.3.84]) by 008-AM1MMR1-011.mgdnok.nokia.com ([65.54.30.20]) with mapi id 14.01.0355.003; Fri, 30 Mar 2012 09:32:56 +0200 From: To: , Thread-Topic: [mif] Prefix Delegation for RA... Thread-Index: AQHNDcuQaLzOeL7MUUm1GzABRYxzhJaCceOA Date: Fri, 30 Mar 2012 07:32:55 +0000 Message-ID: <916CE6CF87173740BC8A2CE4430969620430F19E@008-AM1MPN1-053.mgdnok.nokia.com> References: <4F7491F0.3040205@gmail.com> In-Reply-To: <4F7491F0.3040205@gmail.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-tituslabs-classifications-30: TLPropertyRoot=Nokia;Confidentiality=Nokia Internal Use Only;Project=None; x-titus-version: 3.3.8.1 x-headerinfofordlp: None x-tituslabs-classificationhash-30: VgNFIFU9Hx+/nZJb9Kg7IhtrB8dFPVKy1a2pmXPy1XqoRo81NEBFuQb19ESDLJED1X5L1lcYw9CRwKZMAI4qPzWgZG5esPJJsw4IrqAqBpYtJoxeBKGZ55n/Zl52o/IkDCiVv9LIMznD1iqGwr5PdwTllmr8LAxywnUsO1dP9VwlkhChFzNLtOLd10CYCerpxXdwxJg31Y1o7oje9OEFGdR7/rhkHzpQj+sSYYlhhL/gFKP5ku3cBJqCy7PotAze x-originating-ip: [10.162.86.87] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginalArrivalTime: 30 Mar 2012 07:32:56.0981 (UTC) FILETIME=[537D7450:01CD0E47] X-Nokia-AV: Clean Subject: Re: [mif] Prefix Delegation for RA... X-BeenThere: mif@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multiple Interface Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 30 Mar 2012 07:33:22 -0000 Alexandru, We had this draft couple of years ago: http://tools.ietf.org/id/draft-savol= ainen-stateless-pd-01.txt In the past there has been also proposal for extending RA with PD: http://t= ools.ietf.org/id/draft-lutchann-ipv6-delegate-option-00.txt And maybe this ICMPv6 extension proposal for PD is also related to your que= stion: http://tools.ietf.org/id/draft-haberman-ipngwg-auto-prefix-02.txt Cheers, Teemu > -----Original Message----- > From: mif-bounces@ietf.org [mailto:mif-bounces@ietf.org] On Behalf Of ext > Alexandru Petrescu > Sent: 29. maaliskuuta 2012 18:47 > To: mif > Subject: [mif] Prefix Delegation for RA... > > What would solve the scenario with M2M for LTE, router, would be RA with > Prefix Delegation in it... w/o DHCP. > > I believe htere was an I-D at some point in time about this. > > Alex > _______________________________________________ > mif mailing list > mif@ietf.org > https://www.ietf.org/mailman/listinfo/mif From Ted.Lemon@nominum.com Fri Mar 30 02:36:11 2012 Return-Path: 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 E688D21F8918 for ; Fri, 30 Mar 2012 02:36:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.49 X-Spam-Level: X-Spam-Status: No, score=-106.49 tagged_above=-999 required=5 tests=[AWL=0.109, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, 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 la-pv09YVPJx for ; Fri, 30 Mar 2012 02:36:11 -0700 (PDT) Received: from exprod7og104.obsmtp.com (exprod7og104.obsmtp.com [64.18.2.161]) by ietfa.amsl.com (Postfix) with ESMTP id BE88821F8917 for ; Fri, 30 Mar 2012 02:36:10 -0700 (PDT) Received: from shell-too.nominum.com ([64.89.228.229]) (using TLSv1) by exprod7ob104.postini.com ([64.18.6.12]) with SMTP ID DSNKT3V+igfBQIPGHN+T1m7NZBzKEAYX3YB8@postini.com; Fri, 30 Mar 2012 02:36:10 PDT Received: from archivist.nominum.com (archivist.nominum.com [64.89.228.108]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "*.nominum.com", Issuer "Go Daddy Secure Certification Authority" (verified OK)) by shell-too.nominum.com (Postfix) with ESMTP id 002C81B8225 for ; Fri, 30 Mar 2012 02:36:10 -0700 (PDT) Received: from webmail.nominum.com (cas-01.win.nominum.com [64.89.228.131]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (Client CN "mail.nominum.com", Issuer "Go Daddy Secure Certification Authority" (verified OK)) by archivist.nominum.com (Postfix) with ESMTPS id EDF47190064; Fri, 30 Mar 2012 02:36:09 -0700 (PDT) (envelope-from Ted.Lemon@nominum.com) Received: from MBX-01.WIN.NOMINUM.COM ([64.89.228.133]) by CAS-01.WIN.NOMINUM.COM ([64.89.228.131]) with mapi id 14.02.0247.003; Fri, 30 Mar 2012 02:36:10 -0700 From: Ted Lemon To: Margaret Wasserman Thread-Topic: [mif] Route option for DHCPv6 - next steps? Thread-Index: AQHNDL2jhfr6t6vyVEeGR+93z5NinJZ/3M2AgAG+LoD//4t2bYAAgpgAgAAAh4CAABcYAP//i0r4gAC0mQD//8qt3gAjg1aA//+udoc= Date: Fri, 30 Mar 2012 09:36:09 +0000 Message-ID: <8D23D4052ABE7A4490E77B1A012B6307472D47A7@mbx-01.win.nominum.com> References: <75459BC2-E733-45C0-BC1C-25A19BBA1137@gmail.com> <75D251D1-9828-4AFE-9BEF-B376E97133C7@nominum.com> <4A221CE5-ECF0-4E07-9329-E6BAA3F06A96@nominum.com> <4EC4AADB.8030803@piuha.net> <4F719186.3060507@gmail.com> <4F72CD22.3080604@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 >,<550B9F79-1642-469F-9ED3-96DA26AA40AB@lilacglade.org> In-Reply-To: <550B9F79-1642-469F-9ED3-96DA26AA40AB@lilacglade.org> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [192.168.1.10] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 30 Mar 2012 09:36:12 -0000 > 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? We talked about Unicast RA in Taipei as well. It does solve the problem, = but it is only really useful in cases where you have a single router or a s= mall number of routers that need to be configured with these unicast ND rou= tes. In a large network with many routers, the information distribution p= roblem becomes truly painful. This is a specific use case for something l= ike a DHCP route option, and I was suprised not to see it mentioned yesterd= ay. It's true, as Jari said, that this can be accomplished in other ways, and m= aybe it would be better if it would. If there were some better central ma= nagement solution for populating unicast RA mappings on the router, then un= icast RA would indeed address the exact use case that I think we care about= . But without the mechanism for populating routers, we still have a poorl= y-addressed use case. And then the question is, do we want to develop a w= hole new protocol just to solve this one small problem? It might be worth developing the protocol just to put this issue to bed. From alexandru.petrescu@gmail.com Fri Mar 30 04:26:00 2012 Return-Path: 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 CE2B621F87D3 for ; Fri, 30 Mar 2012 04:26:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.079 X-Spam-Level: X-Spam-Status: No, score=-7.079 tagged_above=-999 required=5 tests=[AWL=-0.830, BAYES_00=-2.599, HELO_EQ_FR=0.35, RCVD_IN_DNSWL_MED=-4] 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 pbG-xmzaVQFP for ; Fri, 30 Mar 2012 04:26:00 -0700 (PDT) Received: from sainfoin-out.extra.cea.fr (sainfoin-out.extra.cea.fr [132.167.192.144]) by ietfa.amsl.com (Postfix) with ESMTP id A770F21F877F for ; Fri, 30 Mar 2012 04:25:59 -0700 (PDT) Received: from pisaure.intra.cea.fr (pisaure.intra.cea.fr [132.166.88.21]) by sainfoin.extra.cea.fr (8.14.2/8.14.2/CEAnet-Internet-out-2.3) with ESMTP id q2UBPwiF023900 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT) for ; Fri, 30 Mar 2012 13:25:58 +0200 Received: from muguet1.intra.cea.fr (muguet1.intra.cea.fr [132.166.192.6]) by pisaure.intra.cea.fr (8.14.4/8.14.4) with ESMTP id q2UBPw4Q008243 for ; Fri, 30 Mar 2012 13:25:58 +0200 (envelope-from alexandru.petrescu@gmail.com) Received: from [127.0.0.1] (is010446-4.intra.cea.fr [10.8.33.116]) by muguet1.intra.cea.fr (8.13.8/8.13.8/CEAnet-Intranet-out-1.2) with ESMTP id q2UBPsgC014983 for ; Fri, 30 Mar 2012 13:25:58 +0200 Message-ID: <4F759842.5080802@gmail.com> Date: Fri, 30 Mar 2012 13:25:54 +0200 From: Alexandru Petrescu User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:11.0) Gecko/20120327 Thunderbird/11.0.1 MIME-Version: 1.0 To: mif@ietf.org References: <75459BC2-E733-45C0-BC1C-25A19BBA1137@gmail.com> <75D251D1-9828-4AFE-9BEF-B376E97133C7@nominum.com> <4A221CE5-ECF0-4E07-9329-E6BAA3F06A96@nominum.com> <4EC4AADB.8030803@piuha.net> <4F719186.3060507@gmail.com> <4F72CD22.3080604@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 > <550B9F79-1642-469F-9ED3-96DA26AA40AB@lilacglade.org> In-Reply-To: <550B9F79-1642-469F-9ED3-96DA26AA40AB@lilacglade.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 30 Mar 2012 11:26:00 -0000 Le 30/03/2012 09:21, Margaret Wasserman a écrit : > > 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, Let me add to this, there was a vote along these lines in jabber as well. Alex > 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 > > > > > > > > > _______________________________________________ mif mailing list > mif@ietf.org https://www.ietf.org/mailman/listinfo/mif From alexandru.petrescu@gmail.com Fri Mar 30 04:29:03 2012 Return-Path: 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 9166D21F8799 for ; Fri, 30 Mar 2012 04:29:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.047 X-Spam-Level: X-Spam-Status: No, score=-9.047 tagged_above=-999 required=5 tests=[AWL=1.202, BAYES_00=-2.599, HELO_EQ_FR=0.35, RCVD_IN_DNSWL_HI=-8] 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 BDVnuhLc5UPX for ; Fri, 30 Mar 2012 04:29:02 -0700 (PDT) Received: from cirse-out.extra.cea.fr (cirse-out.extra.cea.fr [132.167.192.142]) by ietfa.amsl.com (Postfix) with ESMTP id 6FA8721F8755 for ; Fri, 30 Mar 2012 04:29:02 -0700 (PDT) Received: from pisaure.intra.cea.fr (pisaure.intra.cea.fr [132.166.88.21]) by cirse.extra.cea.fr (8.14.2/8.14.2/CEAnet-Internet-out-2.3) with ESMTP id q2UBT0Do010754 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT) for ; Fri, 30 Mar 2012 13:29:00 +0200 Received: from muguet1.intra.cea.fr (muguet1.intra.cea.fr [132.166.192.6]) by pisaure.intra.cea.fr (8.14.4/8.14.4) with ESMTP id q2UBSxWB009389 for ; Fri, 30 Mar 2012 13:29:00 +0200 (envelope-from alexandru.petrescu@gmail.com) Received: from [127.0.0.1] (is010446-4.intra.cea.fr [10.8.33.116]) by muguet1.intra.cea.fr (8.13.8/8.13.8/CEAnet-Intranet-out-1.2) with ESMTP id q2UBSxlX016426 for ; Fri, 30 Mar 2012 13:28:59 +0200 Message-ID: <4F7598FB.7070201@gmail.com> Date: Fri, 30 Mar 2012 13:28:59 +0200 From: Alexandru Petrescu User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:11.0) Gecko/20120327 Thunderbird/11.0.1 MIME-Version: 1.0 To: mif@ietf.org References: <75459BC2-E733-45C0-BC1C-25A19BBA1137@gmail.com> <75D251D1-9828-4AFE-9BEF-B376E97133C7@nominum.com> <4A221CE5-ECF0-4E07-9329-E6BAA3F06A96@nominum.com> <4EC4AADB.8030803@piuha.net> <4F719186.3060507@gmail.com> <4F72CD22.3080604@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 > <550B9F79-1642-469F-9ED3-96DA26AA40AB@lilacglade.org> In-Reply-To: <550B9F79-1642-469F-9ED3-96DA26AA40AB@lilacglade.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Subject: Re: [mif] use cases - Router instead of Host (was: 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 30 Mar 2012 11:29:03 -0000 Le 30/03/2012 09:21, Margaret Wasserman a écrit : > > 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? I suppose that transmitting routes over ND is what RFC4191 "more specific routes" is about. That applies to hosts only. The use cases that I am interested in are those using Routers. Unless specified otherwise, Routers would not use RFC4191. This is a reason why DHCP option is a good option to transmit, in particular, the default routes. Alex > 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 > > > > > > > > > _______________________________________________ > mif mailing list > mif@ietf.org > https://www.ietf.org/mailman/listinfo/mif From alexandru.petrescu@gmail.com Fri Mar 30 04:38:14 2012 Return-Path: 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 57E6B21F86FA for ; Fri, 30 Mar 2012 04:38:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.092 X-Spam-Level: X-Spam-Status: No, score=-9.092 tagged_above=-999 required=5 tests=[AWL=1.157, BAYES_00=-2.599, HELO_EQ_FR=0.35, RCVD_IN_DNSWL_HI=-8] 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 7HZFmwGs-fg6 for ; Fri, 30 Mar 2012 04:38:13 -0700 (PDT) Received: from cirse-out.extra.cea.fr (cirse-out.extra.cea.fr [132.167.192.142]) by ietfa.amsl.com (Postfix) with ESMTP id 5CC1721F86F9 for ; Fri, 30 Mar 2012 04:38:13 -0700 (PDT) Received: from pisaure.intra.cea.fr (pisaure.intra.cea.fr [132.166.88.21]) by cirse.extra.cea.fr (8.14.2/8.14.2/CEAnet-Internet-out-2.3) with ESMTP id q2UBcC8N014159 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Fri, 30 Mar 2012 13:38:12 +0200 Received: from muguet2.intra.cea.fr (muguet2.intra.cea.fr [132.166.192.7]) by pisaure.intra.cea.fr (8.14.4/8.14.4) with ESMTP id q2UBcCCa012214; Fri, 30 Mar 2012 13:38:12 +0200 (envelope-from alexandru.petrescu@gmail.com) Received: from [127.0.0.1] (is010446-4.intra.cea.fr [10.8.33.116]) by muguet2.intra.cea.fr (8.13.8/8.13.8/CEAnet-Intranet-out-1.2) with ESMTP id q2UBc8Hc027341; Fri, 30 Mar 2012 13:38:11 +0200 Message-ID: <4F759B20.7050306@gmail.com> Date: Fri, 30 Mar 2012 13:38:08 +0200 From: Alexandru Petrescu User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:11.0) Gecko/20120327 Thunderbird/11.0.1 MIME-Version: 1.0 To: teemu.savolainen@nokia.com References: <4F7491F0.3040205@gmail.com> <916CE6CF87173740BC8A2CE4430969620430F19E@008-AM1MPN1-053.mgdnok.nokia.com> In-Reply-To: <916CE6CF87173740BC8A2CE4430969620430F19E@008-AM1MPN1-053.mgdnok.nokia.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Cc: mif@ietf.org Subject: Re: [mif] Prefix Delegation for RA... X-BeenThere: mif@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multiple Interface Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 30 Mar 2012 11:38:14 -0000 Le 30/03/2012 09:32, teemu.savolainen@nokia.com a écrit : > Alexandru, > > We had this draft couple of years ago: > http://tools.ietf.org/id/draft-savolainen-stateless-pd-01.txt > > In the past there has been also proposal for extending RA with PD: > http://tools.ietf.org/id/draft-lutchann-ipv6-delegate-option-00.txt > > And maybe this ICMPv6 extension proposal for PD is also related to > your question: > http://tools.ietf.org/id/draft-haberman-ipngwg-auto-prefix-02.txt Thanks for the pointers. I was only aware of this: draft-krishnan-intarea-ra-dhcp-00 in 2007, which seems as a relatively generic way of putting DHCP options into RA messages, including prefix delegation maybe. Alex > > Cheers, > > Teemu > >> -----Original Message----- From: mif-bounces@ietf.org >> [mailto:mif-bounces@ietf.org] On Behalf Of ext Alexandru Petrescu >> Sent: 29. maaliskuuta 2012 18:47 To: mif Subject: [mif] Prefix >> Delegation for RA... >> >> What would solve the scenario with M2M for LTE, router, would be >> RA with Prefix Delegation in it... w/o DHCP. >> >> I believe htere was an I-D at some point in time about this. >> >> Alex _______________________________________________ mif mailing >> list mif@ietf.org https://www.ietf.org/mailman/listinfo/mif > From alexandru.petrescu@gmail.com Fri Mar 30 05:08:16 2012 Return-Path: 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 D211F21F853A for ; Fri, 30 Mar 2012 05:08:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.133 X-Spam-Level: X-Spam-Status: No, score=-9.133 tagged_above=-999 required=5 tests=[AWL=1.116, BAYES_00=-2.599, HELO_EQ_FR=0.35, RCVD_IN_DNSWL_HI=-8] 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 V3sOEDIWTlTw for ; Fri, 30 Mar 2012 05:08:16 -0700 (PDT) Received: from cirse-out.extra.cea.fr (cirse-out.extra.cea.fr [132.167.192.142]) by ietfa.amsl.com (Postfix) with ESMTP id 0FD1B21F85CE for ; Fri, 30 Mar 2012 05:08:15 -0700 (PDT) Received: from pisaure.intra.cea.fr (pisaure.intra.cea.fr [132.166.88.21]) by cirse.extra.cea.fr (8.14.2/8.14.2/CEAnet-Internet-out-2.3) with ESMTP id q2UC8FoT026945 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT) for ; Fri, 30 Mar 2012 14:08:15 +0200 Received: from muguet1.intra.cea.fr (muguet1.intra.cea.fr [132.166.192.6]) by pisaure.intra.cea.fr (8.14.4/8.14.4) with ESMTP id q2UC8Emm023789 for ; Fri, 30 Mar 2012 14:08:15 +0200 (envelope-from alexandru.petrescu@gmail.com) Received: from [127.0.0.1] (is010446-4.intra.cea.fr [10.8.33.116]) by muguet1.intra.cea.fr (8.13.8/8.13.8/CEAnet-Intranet-out-1.2) with ESMTP id q2UC8Bcj002705 for ; Fri, 30 Mar 2012 14:08:14 +0200 Message-ID: <4F75A22B.7080109@gmail.com> Date: Fri, 30 Mar 2012 14:08:11 +0200 From: Alexandru Petrescu User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:11.0) Gecko/20120327 Thunderbird/11.0.1 MIME-Version: 1.0 To: mif Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: [mif] LTE lightweight Router use-case for default routes X-BeenThere: mif@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multiple Interface Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 30 Mar 2012 12:08:16 -0000 There is a particular use-case I am interested in, with respect to the distribution of default routes. A lightweight IPv6 Router, of end user, connects to the LTE network. It needs to acquire several basic parameters such as address and default route. By LTE specifications, this Router uses RS/RA to make an address and DHCPv6-Prefix Delegation to obtain a prefix for use with other devices in its (movable) network. Since it is lightweight, and constrained in hardware ressources available, it may be better served if only one protocol implementation were used, instead of 2, and if a smaller number of smaller messages were used. LTE, M2M and vehicular settings are example applications. Others similar are e.g. satellite-WiFi connectors, and more. Is this use-case already mentioned in the route-option draft? Alex From alexandru.petrescu@gmail.com Fri Mar 30 05:35:48 2012 Return-Path: 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 9CC9C21F86BA for ; Fri, 30 Mar 2012 05:35:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.171 X-Spam-Level: X-Spam-Status: No, score=-7.171 tagged_above=-999 required=5 tests=[AWL=-0.922, BAYES_00=-2.599, HELO_EQ_FR=0.35, RCVD_IN_DNSWL_MED=-4] 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 vCIsf7GR+Lx3 for ; Fri, 30 Mar 2012 05:35:48 -0700 (PDT) Received: from sainfoin-out.extra.cea.fr (sainfoin-out.extra.cea.fr [132.167.192.144]) by ietfa.amsl.com (Postfix) with ESMTP id ACDC121F869E for ; Fri, 30 Mar 2012 05:35:47 -0700 (PDT) Received: from pisaure.intra.cea.fr (pisaure.intra.cea.fr [132.166.88.21]) by sainfoin.extra.cea.fr (8.14.2/8.14.2/CEAnet-Internet-out-2.3) with ESMTP id q2UCZjqI016496 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT) for ; Fri, 30 Mar 2012 14:35:45 +0200 Received: from muguet1.intra.cea.fr (muguet1.intra.cea.fr [132.166.192.6]) by pisaure.intra.cea.fr (8.14.4/8.14.4) with ESMTP id q2UCZi2w002718 for ; Fri, 30 Mar 2012 14:35:45 +0200 (envelope-from alexandru.petrescu@gmail.com) Received: from [127.0.0.1] (is010446-4.intra.cea.fr [10.8.33.116]) by muguet1.intra.cea.fr (8.13.8/8.13.8/CEAnet-Intranet-out-1.2) with ESMTP id q2UCZf7c017784 for ; Fri, 30 Mar 2012 14:35:44 +0200 Message-ID: <4F75A89D.9030404@gmail.com> Date: Fri, 30 Mar 2012 14:35:41 +0200 From: Alexandru Petrescu User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:11.0) Gecko/20120327 Thunderbird/11.0.1 MIME-Version: 1.0 To: mif@ietf.org References: <4F71B21B.3040907@gmail.com> <4F72B929.7030204@gmail.com> In-Reply-To: <4F72B929.7030204@gmail.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Subject: Re: [mif] Issue: message size for communicating the default route? draft-ietf-mif-dhcpv6-route-option-04 X-BeenThere: mif@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multiple Interface Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 30 Mar 2012 12:35:48 -0000 Le 28/03/2012 09:09, Tomek Mrugalski a écrit : > On 12-03-27 14:27, Alexandru Petrescu wrote: >> Dear participants in MIF WG, >> >> Currently draft-ietf-mif-dhcpv6-route-option-04 specifies that when >> communicating a default route, the minimal message size (RT_PREFIX >> option absent) is 46 bytes (Next Hop Option 20bytes, Route Prefix Option >> 26bytes). > Please re-read the draft, section 5.2. Note that prefix field itself is > variable and its size depends on prefix-length. You seem to be > interested in low-capability devices. Assuming you use route option to > configure just default route, Route Prefix option is 10 bytes long, so > the total is 30, not 46 bytes. The total could be even smaller (20bytes?) if only one option were used, not two (nexthop+routeprefix). Alex > >> Sometimes the draft says this Route Prefix Option may be absent for >> default routes, thus total length could be 20bytes. > The ability to skip Route Prefix Option used to be allowed, but that is > not the case anymore. As I mentioned, there is still text that was > missed during the last series of updates and it will be removed in -05. > > Tomek > _______________________________________________ > mif mailing list > mif@ietf.org > https://www.ietf.org/mailman/listinfo/mif > From alexandru.petrescu@gmail.com Fri Mar 30 05:36:53 2012 Return-Path: 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 4467021F8702 for ; Fri, 30 Mar 2012 05:36:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.141 X-Spam-Level: X-Spam-Status: No, score=-9.141 tagged_above=-999 required=5 tests=[AWL=1.108, BAYES_00=-2.599, HELO_EQ_FR=0.35, RCVD_IN_DNSWL_HI=-8] 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 q4dXx2LW-CZc for ; Fri, 30 Mar 2012 05:36:52 -0700 (PDT) Received: from cirse-out.extra.cea.fr (cirse-out.extra.cea.fr [132.167.192.142]) by ietfa.amsl.com (Postfix) with ESMTP id 08D8F21F86BA for ; Fri, 30 Mar 2012 05:36:51 -0700 (PDT) Received: from pisaure.intra.cea.fr (pisaure.intra.cea.fr [132.166.88.21]) by cirse.extra.cea.fr (8.14.2/8.14.2/CEAnet-Internet-out-2.3) with ESMTP id q2UCapRM006401 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT) for ; Fri, 30 Mar 2012 14:36:51 +0200 Received: from muguet1.intra.cea.fr (muguet1.intra.cea.fr [132.166.192.6]) by pisaure.intra.cea.fr (8.14.4/8.14.4) with ESMTP id q2UCaoob003128 for ; Fri, 30 Mar 2012 14:36:51 +0200 (envelope-from alexandru.petrescu@gmail.com) Received: from [127.0.0.1] (is010446-4.intra.cea.fr [10.8.33.116]) by muguet1.intra.cea.fr (8.13.8/8.13.8/CEAnet-Intranet-out-1.2) with ESMTP id q2UCaoRx018281 for ; Fri, 30 Mar 2012 14:36:50 +0200 Message-ID: <4F75A8E2.1010606@gmail.com> Date: Fri, 30 Mar 2012 14:36:50 +0200 From: Alexandru Petrescu User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:11.0) Gecko/20120327 Thunderbird/11.0.1 MIME-Version: 1.0 To: mif Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Subject: [mif] Summary issues after meeting, draft-ietf-mif-dhcpv6-route-option-04 X-BeenThere: mif@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multiple Interface Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 30 Mar 2012 12:36:53 -0000 We discussed on the email list and at the meeting about issues related to draft-ietf-mif-dhcpv6-route-option-04. The following issues were presented during the meeting: > MAC address not configured > > Answer: it doesn’t need to be. MAC derived via ND. This is not what was said on the email list, and even less at the mic. On the mailing list, the range of comments were from "no MAC" to "maybe MAC". To me the latter seemed more agreed. > Lifetime is 32, not 16 bits > > Answer: Does not appear to be a problem, timing calculation is OS > dependent, but it is done on 32 or 64 bit counters. In the recent emails on the mailing list there seemed to be convergence. But not the way you mention it. At the mic there seemed to exist as many supportive comments of doing lifetime (be it 16 or 32) as of doing no lifetime at all. In addition, the following issues were listed by email, with discussion. 1. Separate specific routes from default routes. Authors disagree with me, and Ted agrees with authors. 2. Message size better be smaller. Author indicates the length is 30bytes by now. But I'd suggest it could be 20bytes if the encoding were not split as nexthop-prefixoption (as is now). 3. Only one default route? Discussion seems to indicate that maybe the presence of several default routes would be in scope here. And if coupled with a novel source address selection scheme may constitute new work maybe 6man. Alex PS: Chairs, if you believe I should stop tracking these issues then please let me know. From Ted.Lemon@nominum.com Fri Mar 30 05:58:38 2012 Return-Path: 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 5E00D21F86D0 for ; Fri, 30 Mar 2012 05:58:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.491 X-Spam-Level: X-Spam-Status: No, score=-106.491 tagged_above=-999 required=5 tests=[AWL=0.108, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, 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 Vr9msyYuqC1y for ; Fri, 30 Mar 2012 05:58:38 -0700 (PDT) Received: from exprod7og105.obsmtp.com (exprod7og105.obsmtp.com [64.18.2.163]) by ietfa.amsl.com (Postfix) with ESMTP id B514621F86D1 for ; Fri, 30 Mar 2012 05:58:37 -0700 (PDT) Received: from shell-too.nominum.com ([64.89.228.229]) (using TLSv1) by exprod7ob105.postini.com ([64.18.6.12]) with SMTP ID DSNKT3Wt/MRTUhR6zI3gGfGePu3VGeuF10KT@postini.com; Fri, 30 Mar 2012 05:58:37 PDT Received: from archivist.nominum.com (archivist.nominum.com [64.89.228.108]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "*.nominum.com", Issuer "Go Daddy Secure Certification Authority" (verified OK)) by shell-too.nominum.com (Postfix) with ESMTP id 770051B8269 for ; Fri, 30 Mar 2012 05:58:36 -0700 (PDT) Received: from webmail.nominum.com (cas-01.win.nominum.com [64.89.228.131]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (Client CN "mail.nominum.com", Issuer "Go Daddy Secure Certification Authority" (verified OK)) by archivist.nominum.com (Postfix) with ESMTPS id 6B57E190064; Fri, 30 Mar 2012 05:58:36 -0700 (PDT) (envelope-from Ted.Lemon@nominum.com) Received: from MBX-01.WIN.NOMINUM.COM ([64.89.228.133]) by CAS-01.WIN.NOMINUM.COM ([64.89.228.131]) with mapi id 14.02.0247.003; Fri, 30 Mar 2012 05:58:36 -0700 From: Ted Lemon To: Alexandru Petrescu , mif Thread-Topic: [mif] Summary issues after meeting, draft-ietf-mif-dhcpv6-route-option-04 Thread-Index: AQHNDnHL2JhwvPbaZEatZIDGEix3ApaCy+g3 Date: Fri, 30 Mar 2012 12:58:36 +0000 Message-ID: <8D23D4052ABE7A4490E77B1A012B6307472D4897@mbx-01.win.nominum.com> References: <4F75A8E2.1010606@gmail.com> In-Reply-To: <4F75A8E2.1010606@gmail.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [192.168.1.10] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [mif] Summary issues after meeting, draft-ietf-mif-dhcpv6-route-option-04 X-BeenThere: mif@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multiple Interface Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 30 Mar 2012 12:58:38 -0000 Alexandru, I think the major misunderstanding here has to do with your use = case. The route option as it was floated was not originally intended to a= ddress your use case, and when it was changed to address your use case, it = got a lot less popular. Thiss was not because there's anything wrong with= your use case, but because it came to be perceived as more applicable to u= se cases where, from an architectural perspective, the IETF would prefer to= use RA. That is, it came to be perceived as a generic replacement for RA= , which wasn't what the working group set out to do. From alexandru.petrescu@gmail.com Fri Mar 30 06:12:01 2012 Return-Path: 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 E428021F864B for ; Fri, 30 Mar 2012 06:12:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.176 X-Spam-Level: X-Spam-Status: No, score=-9.176 tagged_above=-999 required=5 tests=[AWL=1.073, BAYES_00=-2.599, HELO_EQ_FR=0.35, RCVD_IN_DNSWL_HI=-8] 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 8T9pfBDj0Dx2 for ; Fri, 30 Mar 2012 06:12:01 -0700 (PDT) Received: from cirse-out.extra.cea.fr (cirse-out.extra.cea.fr [132.167.192.142]) by ietfa.amsl.com (Postfix) with ESMTP id 243C921F8510 for ; Fri, 30 Mar 2012 06:12:00 -0700 (PDT) Received: from pisaure.intra.cea.fr (pisaure.intra.cea.fr [132.166.88.21]) by cirse.extra.cea.fr (8.14.2/8.14.2/CEAnet-Internet-out-2.3) with ESMTP id q2UDC03U021592 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Fri, 30 Mar 2012 15:12:00 +0200 Received: from muguet1.intra.cea.fr (muguet1.intra.cea.fr [132.166.192.6]) by pisaure.intra.cea.fr (8.14.4/8.14.4) with ESMTP id q2UDBxaC017953; Fri, 30 Mar 2012 15:12:00 +0200 (envelope-from alexandru.petrescu@gmail.com) Received: from [127.0.0.1] (is010446-4.intra.cea.fr [10.8.33.116]) by muguet1.intra.cea.fr (8.13.8/8.13.8/CEAnet-Intranet-out-1.2) with ESMTP id q2UDBuBe005179; Fri, 30 Mar 2012 15:11:59 +0200 Message-ID: <4F75B11C.1000401@gmail.com> Date: Fri, 30 Mar 2012 15:11:56 +0200 From: Alexandru Petrescu User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:11.0) Gecko/20120327 Thunderbird/11.0.1 MIME-Version: 1.0 To: Ted Lemon References: <4F75A8E2.1010606@gmail.com> <8D23D4052ABE7A4490E77B1A012B6307472D4897@mbx-01.win.nominum.com> In-Reply-To: <8D23D4052ABE7A4490E77B1A012B6307472D4897@mbx-01.win.nominum.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Cc: mif Subject: Re: [mif] ways forward( was: Summary issues after meeting, draft-ietf-mif-dhcpv6-route-option-04) X-BeenThere: mif@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multiple Interface Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 30 Mar 2012 13:12:02 -0000 Le 30/03/2012 14:58, Ted Lemon a écrit : > Alexandru, I think the major misunderstanding here has to do with > your use case. The route option as it was floated was not > originally intended to address your use case, and when it was changed > to address your use case, it got a lot less popular. Thiss was not > because there's anything wrong with your use case, but because it > came to be perceived as more applicable to use cases where, from an > architectural perspective, the IETF would prefer to use RA. That > is, it came to be perceived as a generic replacement for RA, which > wasn't what the working group set out to do. It doesnt sound pleasant to me to hear so. But let's talk in terms of next steps. I remember having insisted on default routes at a time when draft-dec-dhcpv6-route-option-05 was out, or even earlier. Do you think it is that which may have induced later disapproval? Would this imply to suggest next steps of route-option without default routes? I would not oppose such way forward. What would be the possible ways forward? Alex From Ted.Lemon@nominum.com Fri Mar 30 06:18:26 2012 Return-Path: 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 359F221F8688 for ; Fri, 30 Mar 2012 06:18:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.492 X-Spam-Level: X-Spam-Status: No, score=-106.492 tagged_above=-999 required=5 tests=[AWL=0.107, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, 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 jeK96bH87yBX for ; Fri, 30 Mar 2012 06:18:24 -0700 (PDT) Received: from exprod7og101.obsmtp.com (exprod7og101.obsmtp.com [64.18.2.155]) by ietfa.amsl.com (Postfix) with ESMTP id 095BC21F8677 for ; Fri, 30 Mar 2012 06:18:22 -0700 (PDT) Received: from shell-too.nominum.com ([64.89.228.229]) (using TLSv1) by exprod7ob101.postini.com ([64.18.6.12]) with SMTP ID DSNKT3Wynt8I9iSeLjVqT+0WkQJovJXD9FIZ@postini.com; Fri, 30 Mar 2012 06:18:23 PDT Received: from archivist.nominum.com (archivist.nominum.com [64.89.228.108]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "*.nominum.com", Issuer "Go Daddy Secure Certification Authority" (verified OK)) by shell-too.nominum.com (Postfix) with ESMTP id CA7BA1B8269 for ; Fri, 30 Mar 2012 06:18:21 -0700 (PDT) Received: from webmail.nominum.com (cas-02.win.nominum.com [64.89.228.132]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (Client CN "mail.nominum.com", Issuer "Go Daddy Secure Certification Authority" (verified OK)) by archivist.nominum.com (Postfix) with ESMTPS id C286C190064; Fri, 30 Mar 2012 06:18:21 -0700 (PDT) (envelope-from Ted.Lemon@nominum.com) Received: from MBX-01.WIN.NOMINUM.COM ([64.89.228.133]) by CAS-02.WIN.NOMINUM.COM ([64.89.228.132]) with mapi id 14.02.0247.003; Fri, 30 Mar 2012 06:18:21 -0700 From: Ted Lemon To: Alexandru Petrescu Thread-Topic: ways forward( was: [mif] Summary issues after meeting, draft-ietf-mif-dhcpv6-route-option-04) Thread-Index: AQHNDna1+dCJm9+NZUKwEfMtrM1uU5aC0aAL Date: Fri, 30 Mar 2012 13:18:21 +0000 Message-ID: <8D23D4052ABE7A4490E77B1A012B6307472D48E8@mbx-01.win.nominum.com> References: <4F75A8E2.1010606@gmail.com> <8D23D4052ABE7A4490E77B1A012B6307472D4897@mbx-01.win.nominum.com>, <4F75B11C.1000401@gmail.com> In-Reply-To: <4F75B11C.1000401@gmail.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [192.168.1.10] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: mif Subject: Re: [mif] ways forward( was: Summary issues after meeting, draft-ietf-mif-dhcpv6-route-option-04) X-BeenThere: mif@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multiple Interface Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 30 Mar 2012 13:18:26 -0000 > Would this imply to suggest next steps of route-option without default > routes? I would not oppose such way forward. I think this would be a lot more palatable to the IETF as a whole. As to= the history, remember that it was after WGLC that the IETF as a whole saw = this draft, and objections were raised. Nobody in MIF particularly object= ed to the default route support, because we understood the use cases for th= e option, but when it went to the IETF at large, a lot of people read the d= raft for the first time who didn't understand what motivated it, and so to = them it looked like an RA replacement for general use in all networks. An= d the draft certainly did nothing to disabuse them of that notion. From Basavaraj.Patil@nokia.com Fri Mar 30 02:00:40 2012 Return-Path: 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 BFD2321F882B for ; Fri, 30 Mar 2012 02:00:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.599 X-Spam-Level: X-Spam-Status: No, score=-106.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, 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 uG59uVbbIjO1 for ; Fri, 30 Mar 2012 02:00:39 -0700 (PDT) Received: from mgw-sa01.nokia.com (smtp.nokia.com [147.243.1.47]) by ietfa.amsl.com (Postfix) with ESMTP id D4D1021F87D0 for ; Fri, 30 Mar 2012 02:00:38 -0700 (PDT) Received: from vaebh106.NOE.Nokia.com (in-mx.nokia.com [10.160.244.32]) by mgw-sa01.nokia.com (Sentrion-MTA-4.2.2/Sentrion-MTA-4.2.2) with ESMTP id q2U90aS5019707; Fri, 30 Mar 2012 12:00:36 +0300 Received: from smtp.mgd.nokia.com ([65.54.30.24]) by vaebh106.NOE.Nokia.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.4675); Fri, 30 Mar 2012 12:00:35 +0300 Received: from 008-AM1MPN1-073.mgdnok.nokia.com ([169.254.3.48]) by 008-AM1MMR1-008.mgdnok.nokia.com ([65.54.30.24]) with mapi id 14.01.0355.003; Fri, 30 Mar 2012 11:00:34 +0200 From: To: Thread-Topic: References to link layer triggers specs Thread-Index: AQHNDlOQ7gbr6OlhVUiiaOtMrSskdQ== Date: Fri, 30 Mar 2012 09:00:34 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.14.0.111121 x-originating-ip: [130.129.21.136] Content-Type: text/plain; charset="us-ascii" Content-ID: <7CB51991DD5BAB46BB16EC3FFBCF219A@mgd.nokia.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginalArrivalTime: 30 Mar 2012 09:00:35.0809 (UTC) FILETIME=[91FEED10:01CD0E53] X-Nokia-AV: Clean X-Mailman-Approved-At: Fri, 30 Mar 2012 08:47:09 -0700 Subject: [mif] References to link layer triggers specs X-BeenThere: mif@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multiple Interface Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 30 Mar 2012 09:00:40 -0000 Hello, I had agreed to send some references to link layer triggers related documents w.r.t the API discussion in the WG. Please see: 1. RFC4957 - Link-Layer Event Notifications for Detecting Network Attachments 2. RFC5184 - Unified Layer 2 (L2) Abstractions for Layer 3 (L3)-Driven Fast Handover=20 -Raj From alh-ietf@tndh.net Sat Mar 31 15:35:34 2012 Return-Path: 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 0D9DA21F877F for ; Sat, 31 Mar 2012 15:35:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.611 X-Spam-Level: X-Spam-Status: No, score=0.611 tagged_above=-999 required=5 tests=[AWL=-1.458, BAYES_50=0.001, FH_HOST_EQ_D_D_D_D=0.765, FH_HOST_EQ_D_D_D_DB=0.888, RDNS_DYNAMIC=0.1, SARE_MILLIONSOF=0.315] 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 1u-pPkE7Rb+Q for ; Sat, 31 Mar 2012 15:35:33 -0700 (PDT) Received: from tndh.net (75-149-170-53-Washington.hfc.comcastbusiness.net [75.149.170.53]) by ietfa.amsl.com (Postfix) with ESMTP id 0EC0121F8781 for ; Sat, 31 Mar 2012 15:35:32 -0700 (PDT) X-AuthUser: alh-ietf@tndh.net Received: from eaglet ([172.20.144.31]:22755) by tndh.net with [XMail 1.27 ESMTP Server] id for from ; Sat, 31 Mar 2012 15:35:31 -0700 From: "Tony Hain" To: "'Ted Lemon'" References: <75459BC2-E733-45C0-BC1C-25A19BBA1137@gmail.com> <75D251D1-9828-4AFE-9BEF-B376E97133C7@nominum.com> <4A221CE5-ECF0-4E07-9329-E6BAA3F06A96@nominum.com> <4EC4AADB.8030803@piuha.net> <4F719186.3060507@gmail.com> <4F72CD22.3080604@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> In-Reply-To: <8D23D4052ABE7A4490E77B1A012B6307472D45F6@mbx-01.win.nominum.com> Date: Sat, 31 Mar 2012 15:35:29 -0700 Message-ID: <075201cd0f8e$94cb8170$be628450$@tndh.net> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQGYocXPKzopiDhicKFSNXe3ky5PRQFWcj/vAj3jZD8CE4SQEAM8EDN1Aal2DB8CuqDa4AGu3TE6AouFInYBmOpBUgHiAfgSAabbPDMCVhY93gK9RQNgAaU+fSYBVklIJAKKPEcuAtiEBeIBI67GfQHRMw/llbWCBjA= Content-Language: en-us Cc: 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 31 Mar 2012 22:35:34 -0000 Well the simplest way to deal with this is to state that it is an IPv6 version of and existing DHCP option, therefore it doesn't belong in MIF, it belongs in DHC which knows how to deal with updating options. Why it is needed for mif use is something this WG will eventually need to come to grips with, but for now we don't need MIF to make progress. People use 249 (MSFT private version) so much that it justified the RFC specifying 121. I had just been looking for this and planned to do a 3442bis before finding out that it was on the MIF agenda. We should take it offline for the moment and revisit the wording to take it out of a MIF context per se, then revisit the AD's about putting it in DHC. I have only scanned the doc during the WG bashing, so I need to do a better read before knowing exactly what to suggest. Tony -----Original Message----- From: Ted Lemon [mailto:Ted.Lemon@nominum.com] Sent: Thursday, March 29, 2012 2:37 PM To: Tony Hain Cc: mif@ietf.org Subject: RE: [mif] Route option for DHCPv6 - next steps? > Why is this not RFC 3442bis? DHCP option 121 already does this > function for IPv4, so this is really just creating the IPv6 version of > the existing option. It is required for VPN split tunnel, so the > entire question about doing it or not is moot. People use 121 / 249 > (MSFT private version that instigated 3442), so they need the IPv6 version of that. This wasn't about what is needed. This was about a public lynching of a group that entertained an idea that is politically incorrect. If you look at the reasons that were raised today, they were all garbage, with all due respect to the generally very sensible and wise people who had the poor judgment to offer them. We had one person, an operator, saying "for god's sake don't make this option, because I would not want to run a network on which this option was used," at the same time that another couple of people who work for very large companies and have pretty close to final say in how their networks are operated saying "if we allow this draft, willfylly stupid people will deploy itin places where it will work really poorly, it will be widely adopted, and then network effects will force us to deploy it as well." This document has been raised, in one form or another, every year or so for the past five or six years. There's always a public lynching. It always gets raised again, because there is demand. Numerous contributors to the IETF have wasted years working on this. Today many millions of tons of carbon were put into the atmosphere in order that we might have another public lynching rather than getting about the business of the mif working group. As a consequence of this useless lynching, I didn't get to hear any of the presentations that followed it on the mif docket. I wish I could claim that I had never unwisely participated in a public waste of time like the one we had today, but I can't. I'm sure people reading this are laughing in their sleeves to hear me complaining about this. But I really wish we could stop doing this. The participants in today's lynching should take a lesson from the working group's response when today's draft was killed. Everybody still wants it. When we are done smarting from the spanking we got today, it will get raised again, maybe in a different working group. This will keep happening until we all die of old age and our metaphorical children, who have no recollection of the prejudices of the day, finally write it up and wonder why it took so long for it to get done. 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. From alh-ietf@tndh.net Sat Mar 31 15:43:50 2012 Return-Path: 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 52E3021F85D2 for ; Sat, 31 Mar 2012 15:43:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.183 X-Spam-Level: * X-Spam-Status: No, score=1.183 tagged_above=-999 required=5 tests=[AWL=-0.572, BAYES_50=0.001, FH_HOST_EQ_D_D_D_D=0.765, FH_HOST_EQ_D_D_D_DB=0.888, HTML_MESSAGE=0.001, RDNS_DYNAMIC=0.1] 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 ZHy+cYVM3p57 for ; Sat, 31 Mar 2012 15:43:48 -0700 (PDT) Received: from tndh.net (75-149-170-53-Washington.hfc.comcastbusiness.net [75.149.170.53]) by ietfa.amsl.com (Postfix) with ESMTP id C62EB21F8596 for ; Sat, 31 Mar 2012 15:43:47 -0700 (PDT) X-AuthUser: alh-ietf@tndh.net Received: from eaglet ([172.20.144.31]:21967) by tndh.net with [XMail 1.27 ESMTP Server] id for from ; Sat, 31 Mar 2012 15:43:46 -0700 From: "Tony Hain" To: "'Margaret Wasserman'" , "'Ted Lemon'" References: <75459BC2-E733-45C0-BC1C-25A19BBA1137@gmail.com> <75D251D1-9828-4AFE-9BEF-B376E97133C7@nominum.com> <4A221CE5-ECF0-4E07-9329-E6BAA3F06A96@nominum.com> <4EC4AADB.8030803@piuha.net> <4F719186.3060507@gmail.com> <4F72CD22.3080604@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 > <550B9F79-1642-469F -9ED3-96DA26AA40AB@lilacglade.org> In-Reply-To: <550B9F79-1642-469F-9ED3-96DA26AA40AB@lilacglade.org> Date: Sat, 31 Mar 2012 15:43:43 -0700 Message-ID: <075301cd0f8f$bbc8a040$3359e0c0$@tndh.net> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0754_01CD0F55.0F69C840" X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQGYocXPKzopiDhicKFSNXe3ky5PRQFWcj/vAj3jZD8CE4SQEAM8EDN1Aal2DB8CuqDa4AGu3TE6AouFInYBmOpBUgHiAfgSAabbPDMCVhY93gK9RQNgAaU+fSYBVklIJAKKPEcuAtiEBeIBI67GfQGvzmI1AkTakeuVpGiiYA== Content-Language: en-us Cc: 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 31 Mar 2012 22:43:50 -0000 This is a multipart message in MIME format. ------=_NextPart_000_0754_01CD0F55.0F69C840 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Margret, I am a strong believer we need to do both. This continuing crap that we need to isolate useful tools and only have one version which can't ever solve all problems has to end. There will be networks that use DHCP (even as a trust anchor, as absurd as that concept is), and there will be networks that want to operate without DHCP. There should be a mechanism for each of those operational models. Stop trying to use the standards process to drive people to your favorite mode, and simply make sure there is a way to do the job that fits your situation. For those that say the end systems won't want to do both, that is both true and false. For end systems that live almost exclusively in one operational model, those vendors will not want to bother with the other, but for the vendors the realize that their system might be in either, doing both is not that big a deal. The hard issue is deciding priority if you hear both, and personally I prefer that the end user gets to choose because network operators always think they know best, when in fact they almost never do. Tony From: Margaret Wasserman [mailto:mrw@lilacglade.org] Sent: Friday, March 30, 2012 12:22 AM To: Ted Lemon Cc: Tony Hain; mif@ietf.org Subject: Re: [mif] Route option for DHCPv6 - next steps? 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 ------=_NextPart_000_0754_01CD0F55.0F69C840 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Margret,

 

I am a strong believer we need to do both. This continuing crap that = we need to isolate useful tools and only have one version which = can’t ever solve all problems has to end. There will be networks = that use DHCP (even as a trust anchor, as absurd as that concept is), = and there will be networks that want to operate without DHCP. There = should be a mechanism for each of those operational models. =

 

Stop trying to use the standards process to drive people to your = favorite mode, and simply make sure there is a way to do the job that = fits your situation. For those that say the end systems won’t want = to do both, that is both true and false. For end systems that live = almost exclusively in one operational model, those vendors will not want = to bother with the other, but for the vendors the realize that their = system might be in either, doing both is not that big a deal. The hard = issue is deciding priority if you hear both, and personally I prefer = that the end user gets to choose because network operators always think = they know best, when in fact they almost never = do.

 

Tony

 

 

 

From:= = Margaret Wasserman [mailto:mrw@lilacglade.org]
Sent: Friday, = March 30, 2012 12:22 AM
To: Ted Lemon
Cc: Tony Hain; = mif@ietf.org
Subject: Re: [mif] Route option for DHCPv6 - next = steps?

 

 

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

 

 

 

 

 

 

------=_NextPart_000_0754_01CD0F55.0F69C840--