From Ted.Lemon@nominum.com Sun Nov 13 17:13:20 2011 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 933C321F8573 for ; Sun, 13 Nov 2011 17:13:20 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.55 X-Spam-Level: X-Spam-Status: No, score=-106.55 tagged_above=-999 required=5 tests=[AWL=0.049, 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 EbnIU49FfpQ9 for ; Sun, 13 Nov 2011 17:13:20 -0800 (PST) Received: from exprod7og103.obsmtp.com (exprod7og103.obsmtp.com [64.18.2.159]) by ietfa.amsl.com (Postfix) with ESMTP id CD2A121F856F for ; Sun, 13 Nov 2011 17:13:19 -0800 (PST) Received: from shell-too.nominum.com ([64.89.228.229]) (using TLSv1) by exprod7ob103.postini.com ([64.18.6.12]) with SMTP ID DSNKTsBrIEb1Nrm2a83lZFJMy85O2RaE2GQ+@postini.com; Sun, 13 Nov 2011 17:13:19 PST 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 4E7851B82B3 for ; Sun, 13 Nov 2011 17:13:04 -0800 (PST) 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 37CDA190052 for ; Sun, 13 Nov 2011 17:13:04 -0800 (PST) (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.01.0339.001; Sun, 13 Nov 2011 17:13:04 -0800 From: Ted Lemon To: "mif@ietf.org" Thread-Topic: Small nit on route option draft Thread-Index: Acyiao8QD5vjbXm9TE+xl6KwP+5RYg== Date: Mon, 14 Nov 2011 01:13:03 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: Content-Type: text/plain; charset="us-ascii" Content-ID: <91D41A8D7846444B8B02D42F62CC9F26@nominum.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: [mif] Small nit on route option draft 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, 14 Nov 2011 01:13:20 -0000 I would like to ask that you reverse the prefix length and metric fields in= the option. The reason for this is that the prefix length and prefix look= like they are going to become a common encoding (they are also used in a p= roposed source address configuration option). They are essentially a single= value, expressed as two fields. I have asked the source address draft auth= ors to group the prefix length and prefix together; I think it makes sense = to do the same thing here. This will speed adoption of both drafts, I thi= nk.=20 In order for this to be useful, of course, it would be necessary for you to= adopt the variable length format for the prefix that is used in that draft= . The draft is called draft-ietf-6man-address-select-opt-01.=20 I do apologize for interjecting this so late in the process, but I think it= 's a substantial win to use the same format for the same data across differ= ent options. From denghui02@gmail.com Sun Nov 13 17:46:48 2011 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 CA2CF11E80EB; Sun, 13 Nov 2011 17:46:48 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.598 X-Spam-Level: X-Spam-Status: No, score=-103.598 tagged_above=-999 required=5 tests=[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 oSgSO8jebU7y; Sun, 13 Nov 2011 17:46:48 -0800 (PST) Received: from mail-yx0-f172.google.com (mail-yx0-f172.google.com [209.85.213.172]) by ietfa.amsl.com (Postfix) with ESMTP id 02D7111E80D7; Sun, 13 Nov 2011 17:46:47 -0800 (PST) Received: by yenq4 with SMTP id q4so2790660yen.31 for ; Sun, 13 Nov 2011 17:46:47 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:date:message-id:subject:from:to:content-type; bh=riLXQ7m/yrNPXAPA6MiN9WsBqkItDrclgZJ7qm51WTg=; b=wyB81GAxHTRw+ZRYj+jPwpzwXUcJPmhSWWpsvSNhBHlt5RRsqHeLe+ALwspSHFjum0 myWIJ6Ai8hFR4NBVxzrsP8L2EwlLsZto0NwxgajEgv+RnK1Jymxx0SWPh9ZqL8PWderW Y7060hIZUgF0PPJmYr4ztEqDd2VVxvTOfrYLY= MIME-Version: 1.0 Received: by 10.236.197.72 with SMTP id s48mr11227596yhn.81.1321235207615; Sun, 13 Nov 2011 17:46:47 -0800 (PST) Received: by 10.146.84.10 with HTTP; Sun, 13 Nov 2011 17:46:47 -0800 (PST) Date: Mon, 14 Nov 2011 09:46:47 +0800 Message-ID: From: Hui Deng To: ipv6@ietf.org, MIF Mailing List , dhc WG Content-Type: multipart/alternative; boundary=20cf303f6c8036f66204b1a80bca Subject: [mif] Conflict between RA and DHCP in MIF case 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, 14 Nov 2011 01:46:48 -0000 --20cf303f6c8036f66204b1a80bca Content-Type: text/plain; charset=ISO-8859-1 Hello 6MAN and DHCP, Especially thanks *Wes Beebee*, Hemant Singh, Brian Carpenter, Alex and Ted's discussion. MIF is going to discuss the confliction between RA and DHCP on tuesday afternoon MIF session (15:20-17:00) the author Tomasz has propose below resolution: The problem is about potential conflict between RA and DHCP. Our proposed answer is as follows: RA provides configuration to all hosts in a network. DHCP can provide configuration on a per host basis. Therefore it may be useful to use DHCP to "override" configuration for some hosts in a network (e.g. engineering department has extra routes defined for a lab network). As such, DHCP should be preferred. However, there is also a matter of security. Both RA and DHCPv6 can be secured. If SEND is deployed, RA is more trustworthy than DHCP, so it should be preferred. Finally, there is such thing as secure DHCP, so if both RA and DHCP are secure, prefer SEND. I must admit that I never heard about any realistic deployments of secure DHCP, but it will change over time. This approach can be summed as: favor secure, favor DHCP. Or to be more explicit, there's a complete list of all cases: a) RA vs DHCP => prefer DHCP b) RA(SEND) vs DHCP => prefer RA c) RA vs secure DHCP => prefer DHCP d) RA(SEND) vs secure DHCP => prefer DHCP Does it sound reasonable? This approach is very similar to what was described in DNS configuration over RA and DHCP (except the part about both RA and DHCP being secure that is not covered in RFC6106). To summarize the discussion so far, Ted Lemon on MIF list agreed that DHCP should be preferred. Herman Singh on 6MAN list suggested to go look at what DNS over RA proposes and use the same approach. RFC6106, section 5.3.1covers cases a) and b). c) and d) are logical extension that takes DHCPv6 security into consideration. My understanding is that proposed solution will be satisfactory to everyone. --20cf303f6c8036f66204b1a80bca Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Hello 6MAN and DHCP,
=A0
Especially=A0thanks Wes Beebee, Hemant Singh, Brian C= arpenter, Alex and Ted's discussion.
=A0
MIF is going to discuss the confliction between RA and DHCP on tuesday= afternoon MIF session (15:20-17:00)=A0
the author Tomasz has propose below resolution:
=A0
The problem is about potential conflict between RA and DHCP. Our
pr= oposed answer is as follows:

RA provides configuration to all hosts = in a network. DHCP can provide
configuration on a per host basis. Theref= ore it may be useful to use
DHCP to "override" configuration for some hosts in a network (e.g= .
engineering department has extra routes defined for a lab network). As=
such, DHCP should be preferred.

However, there is also a matter = of security. Both RA and DHCPv6 can be
secured. If SEND is deployed, RA is more trustworthy than DHCP, so it
sh= ould be preferred. Finally, there is such thing as secure DHCP, so if
bo= th RA and DHCP are secure, prefer SEND. I must admit that I never
heard = about any realistic deployments of secure DHCP, but it will change
over time.

This approach can be summed as: favor secure, favor DHCP.= Or to be more
explicit, there's a complete list of all cases:
a)= RA vs DHCP =3D> prefer DHCP
b) RA(SEND) vs DHCP =3D> prefer RA c) RA vs secure DHCP =3D> prefer DHCP
d) RA(SEND) vs secure DHCP =3D&= gt; prefer DHCP

Does it sound reasonable?

This approach is ve= ry similar to what was described in DNS configuration
over RA and DHCP (= except the part about both RA and DHCP being secure
that is not covered in RFC6106).

To summarize the discussion so far,= Ted Lemon on MIF list agreed that
DHCP should be preferred. Herman Sing= h on 6MAN list suggested to go look
at what DNS over RA proposes and use= the same approach. RFC6106, section
5.3.1covers cases a) and b). c) and d) are logical extension that takes
= DHCPv6 security into consideration. My understanding is that proposed
so= lution will be satisfactory to everyone.
--20cf303f6c8036f66204b1a80bca-- From ichiroumakino@gmail.com Sun Nov 13 17:59:49 2011 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 BF55A11E8109; Sun, 13 Nov 2011 17:59:49 -0800 (PST) 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 SrWMA+93ObOo; Sun, 13 Nov 2011 17:59:49 -0800 (PST) Received: from mail-gx0-f172.google.com (mail-gx0-f172.google.com [209.85.161.172]) by ietfa.amsl.com (Postfix) with ESMTP id EB03211E8091; Sun, 13 Nov 2011 17:59:48 -0800 (PST) Received: by ggnr5 with SMTP id r5so433608ggn.31 for ; Sun, 13 Nov 2011 17:59:48 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=sender:subject:mime-version:content-type:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to:x-mailer; bh=WCUXB617eBHyCXPPmNzF+X0gl4DHSxdh2Aw1lleoVpA=; b=SlyqQ8NBV3Lfoiu+hSX3iA/diOaAm2CC3oaDDRlSbLvqbV8CfPfQ28QDrloky64S5H 1OKa0UEoM4yJw05bUGC+blJm8xERDVaJiMgMJw6KnBYUYuoTB4q5CAh1Om1CSjO7Av/q Mfvrjm2wDApRTCUaP4XHoukDnLnw34hRbCRPc= Received: by 10.68.73.71 with SMTP id j7mr32010423pbv.116.1321235987294; Sun, 13 Nov 2011 17:59:47 -0800 (PST) Received: from sjc-vpn4-250.cisco.com (128-107-239-233.cisco.com. [128.107.239.233]) by mx.google.com with ESMTPS id p10sm52531607pbd.15.2011.11.13.17.59.44 (version=TLSv1/SSLv3 cipher=OTHER); Sun, 13 Nov 2011 17:59:45 -0800 (PST) Sender: Ole Troan Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Ole Troan In-Reply-To: Date: Mon, 14 Nov 2011 09:59:40 +0800 Content-Transfer-Encoding: quoted-printable Message-Id: <402398CF-7F7C-4B8B-91CE-6EDE54B6C4CC@employees.org> References: To: Hui Deng X-Mailer: Apple Mail (2.1084) X-Mailman-Approved-At: Sun, 13 Nov 2011 18:02:14 -0800 Cc: MIF Mailing List , ipv6@ietf.org, dhc WG Subject: Re: [mif] [dhcwg] Conflict between RA and DHCP in MIF case 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, 14 Nov 2011 01:59:49 -0000 Hui, why not just merge all the information received? e.g. if you get DNS server over DHCP and RA, use all. if you get addresses via SLAAC and DHCP, you use all... cheers, Ole On Nov 14, 2011, at 9:46 , Hui Deng wrote: > Hello 6MAN and DHCP, > =20 > Especially thanks Wes Beebee, Hemant Singh, Brian Carpenter, Alex and = Ted's discussion. > =20 > MIF is going to discuss the confliction between RA and DHCP on tuesday = afternoon MIF session (15:20-17:00)=20 > the author Tomasz has propose below resolution: > =20 > The problem is about potential conflict between RA and DHCP. Our > proposed answer is as follows: >=20 > RA provides configuration to all hosts in a network. DHCP can provide > configuration on a per host basis. Therefore it may be useful to use > DHCP to "override" configuration for some hosts in a network (e.g. > engineering department has extra routes defined for a lab network). As > such, DHCP should be preferred. >=20 > However, there is also a matter of security. Both RA and DHCPv6 can be > secured. If SEND is deployed, RA is more trustworthy than DHCP, so it > should be preferred. Finally, there is such thing as secure DHCP, so = if > both RA and DHCP are secure, prefer SEND. I must admit that I never > heard about any realistic deployments of secure DHCP, but it will = change > over time. >=20 > This approach can be summed as: favor secure, favor DHCP. Or to be = more > explicit, there's a complete list of all cases: > a) RA vs DHCP =3D> prefer DHCP > b) RA(SEND) vs DHCP =3D> prefer RA > c) RA vs secure DHCP =3D> prefer DHCP > d) RA(SEND) vs secure DHCP =3D> prefer DHCP >=20 > Does it sound reasonable? >=20 > This approach is very similar to what was described in DNS = configuration > over RA and DHCP (except the part about both RA and DHCP being secure > that is not covered in RFC6106). >=20 > To summarize the discussion so far, Ted Lemon on MIF list agreed that > DHCP should be preferred. Herman Singh on 6MAN list suggested to go = look > at what DNS over RA proposes and use the same approach. RFC6106, = section > 5.3.1covers cases a) and b). c) and d) are logical extension that = takes > DHCPv6 security into consideration. My understanding is that proposed > solution will be satisfactory to everyone. > _______________________________________________ > dhcwg mailing list > dhcwg@ietf.org > https://www.ietf.org/mailman/listinfo/dhcwg From brian.e.carpenter@gmail.com Sun Nov 13 18:20:39 2011 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 2674A1F0C4E; Sun, 13 Nov 2011 18:20:39 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.442 X-Spam-Level: X-Spam-Status: No, score=-103.442 tagged_above=-999 required=5 tests=[AWL=0.158, 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 8O6yjVwzW8m2; Sun, 13 Nov 2011 18:20:38 -0800 (PST) Received: from mail-yx0-f172.google.com (mail-yx0-f172.google.com [209.85.213.172]) by ietfa.amsl.com (Postfix) with ESMTP id 5B62B1F0C62; Sun, 13 Nov 2011 18:20:38 -0800 (PST) Received: by yenq4 with SMTP id q4so2811608yen.31 for ; Sun, 13 Nov 2011 18:20:38 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=message-id:date:from:organization:user-agent:mime-version:to:cc :subject:references:in-reply-to:content-type :content-transfer-encoding; bh=x5SkQIePzE7xVG2xmaltQX4nChFg/4XxpaxQYVvRHRU=; b=SSn8S3vEnIdYmtNH2DuM8z0Y4zlsKS5ZbjjnnH3Gxj24i+nsClJLajEwkMgFsce45k qVgblvH/HRwDu6SBjXbd0YaHuD9HS+2K+t9w8pfkZ8aVn3rgWZQUFDKiW7JuhpfnIbuu HdssbrWBT9QnK0x4MZ6Z8BrPEkCMP2pgBusvU= Received: by 10.236.116.98 with SMTP id f62mr11231472yhh.48.1321237237925; Sun, 13 Nov 2011 18:20:37 -0800 (PST) Received: from [130.129.19.92] (dhcp-135c.meeting.ietf.org. [130.129.19.92]) by mx.google.com with ESMTPS id j25sm28619708yhm.12.2011.11.13.18.20.35 (version=SSLv3 cipher=OTHER); Sun, 13 Nov 2011 18:20:37 -0800 (PST) Message-ID: <4EC07AEF.7070303@gmail.com> Date: Mon, 14 Nov 2011 15:20:31 +1300 From: Brian E Carpenter Organization: University of Auckland User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: Hui Deng References: In-Reply-To: Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: MIF Mailing List , ipv6@ietf.org, dhc WG Subject: Re: [mif] Conflict between RA and DHCP in MIF case 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, 14 Nov 2011 02:20:39 -0000 > MIF is going to discuss the confliction between RA and DHCP on tuesday > afternoon MIF session (15:20-17:00) This clashes with SOFTWIRE. Can you do it in the 17:10 session? Regards Brian On 2011-11-14 14:46, Hui Deng wrote: > Hello 6MAN and DHCP, > > Especially thanks *Wes Beebee*, Hemant Singh, Brian Carpenter, Alex and > Ted's discussion. > > MIF is going to discuss the confliction between RA and DHCP on tuesday > afternoon MIF session (15:20-17:00) > the author Tomasz has propose below resolution: > > The problem is about potential conflict between RA and DHCP. Our > proposed answer is as follows: > > RA provides configuration to all hosts in a network. DHCP can provide > configuration on a per host basis. Therefore it may be useful to use > DHCP to "override" configuration for some hosts in a network (e.g. > engineering department has extra routes defined for a lab network). As > such, DHCP should be preferred. > > However, there is also a matter of security. Both RA and DHCPv6 can be > secured. If SEND is deployed, RA is more trustworthy than DHCP, so it > should be preferred. Finally, there is such thing as secure DHCP, so if > both RA and DHCP are secure, prefer SEND. I must admit that I never > heard about any realistic deployments of secure DHCP, but it will change > over time. > > This approach can be summed as: favor secure, favor DHCP. Or to be more > explicit, there's a complete list of all cases: > a) RA vs DHCP => prefer DHCP > b) RA(SEND) vs DHCP => prefer RA > c) RA vs secure DHCP => prefer DHCP > d) RA(SEND) vs secure DHCP => prefer DHCP > > Does it sound reasonable? > > This approach is very similar to what was described in DNS configuration > over RA and DHCP (except the part about both RA and DHCP being secure > that is not covered in RFC6106). > > To summarize the discussion so far, Ted Lemon on MIF list agreed that > DHCP should be preferred. Herman Singh on 6MAN list suggested to go look > at what DNS over RA proposes and use the same approach. RFC6106, section > 5.3.1covers cases a) and b). c) and d) are logical extension that takes > DHCPv6 security into consideration. My understanding is that proposed > solution will be satisfactory to everyone. > > > > ------------------------------------------------------------------------ > > _______________________________________________ > mif mailing list > mif@ietf.org > https://www.ietf.org/mailman/listinfo/mif From Ted.Lemon@nominum.com Sun Nov 13 18:22:59 2011 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 7B43011E8115; Sun, 13 Nov 2011 18:22:59 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.551 X-Spam-Level: X-Spam-Status: No, score=-106.551 tagged_above=-999 required=5 tests=[AWL=0.048, 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 HzyMtLcGYYFX; Sun, 13 Nov 2011 18:22:59 -0800 (PST) Received: from exprod7og116.obsmtp.com (exprod7og116.obsmtp.com [64.18.2.219]) by ietfa.amsl.com (Postfix) with ESMTP id 1AD5D11E810E; Sun, 13 Nov 2011 18:22:55 -0800 (PST) Received: from shell-too.nominum.com ([64.89.228.229]) (using TLSv1) by exprod7ob116.postini.com ([64.18.6.12]) with SMTP ID DSNKTsB7fWhHzHSoYUKdTaD25od0/IRG6os3@postini.com; Sun, 13 Nov 2011 18:22:55 PST 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 0B8DB1B82B8; Sun, 13 Nov 2011 18:22:53 -0800 (PST) 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 EC26E190052; Sun, 13 Nov 2011 18:22:51 -0800 (PST) (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.01.0339.001; Sun, 13 Nov 2011 18:22:52 -0800 From: Ted Lemon To: Hui Deng Thread-Topic: [dhcwg] Conflict between RA and DHCP in MIF case Thread-Index: AQHMom9Jeyu5uv/47kCfd4auwPXOIJWro757 Date: Mon, 14 Nov 2011 02:22:51 +0000 Message-ID: <0AAC8A70-8D90-45EA-9EB7-14D9596BA99A@nominum.com> References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: MIF Mailing List , "ipv6@ietf.org" , dhc WG Subject: Re: [mif] [dhcwg] Conflict between RA and DHCP in MIF case 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, 14 Nov 2011 02:22:59 -0000 On Nov 14, 2011, at 9:46 AM, "Hui Deng" wrote: > Finally, there is such thing as secure DHCP, so if > both RA and DHCP are secure, prefer SEND. I must admit that I never > heard about any realistic deployments of secure DHCP, but it will change > over time. This doesn't agree with the list of steps you gave subsequently. I agree t= o that list, but not to what is said here. That is, if both DHCP and ND ar= e secure, prefer DHCP. = From Ted.Lemon@nominum.com Sun Nov 13 18:24:43 2011 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 5081A11E812F; Sun, 13 Nov 2011 18:24:43 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.552 X-Spam-Level: X-Spam-Status: No, score=-106.552 tagged_above=-999 required=5 tests=[AWL=0.047, 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 5wEhlOxK7Fef; Sun, 13 Nov 2011 18:24:39 -0800 (PST) Received: from exprod7og117.obsmtp.com (exprod7og117.obsmtp.com [64.18.2.6]) by ietfa.amsl.com (Postfix) with ESMTP id 6071D11E812D; Sun, 13 Nov 2011 18:24:39 -0800 (PST) Received: from shell-too.nominum.com ([64.89.228.229]) (using TLSv1) by exprod7ob117.postini.com ([64.18.6.12]) with SMTP ID DSNKTsB75hyQMM1EIPgXAZI+xxzv48Q3CeCk@postini.com; Sun, 13 Nov 2011 18:24:39 PST 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 7B1421B82B5; Sun, 13 Nov 2011 18:24:38 -0800 (PST) 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 6DADC190052; Sun, 13 Nov 2011 18:24:38 -0800 (PST) (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.01.0339.001; Sun, 13 Nov 2011 18:24:38 -0800 From: Ted Lemon To: Ole Troan Thread-Topic: [dhcwg] Conflict between RA and DHCP in MIF case Thread-Index: AQHMom9Jeyu5uv/47kCfd4auwPXOIJWsI2EA//+A3Mc= Date: Mon, 14 Nov 2011 02:24:37 +0000 Message-ID: <23BACC91-621A-4E96-ACD6-92D226F9657A@nominum.com> References: , <402398CF-7F7C-4B8B-91CE-6EDE54B6C4CC@employees.org> In-Reply-To: <402398CF-7F7C-4B8B-91CE-6EDE54B6C4CC@employees.org> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "ipv6@ietf.org" , MIF Mailing List , dhc WG Subject: Re: [mif] [dhcwg] Conflict between RA and DHCP in MIF case 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, 14 Nov 2011 02:24:43 -0000 On Nov 14, 2011, at 9:59 AM, "Ole Troan" wrote: > why not just merge all the information received? > e.g. if you get DNS server over DHCP and RA, use all. > if you get addresses via SLAAC and DHCP, you use all... Because "just merge" is essentially equivalent to "just walk across the riv= er without your feet getting wet.". If you can write a spec that does this= correctly, you are probably the Messiah. = From ichiroumakino@gmail.com Sun Nov 13 18:30:09 2011 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 B409E11E814C; Sun, 13 Nov 2011 18:30:09 -0800 (PST) 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 18H+pg-0IfuY; Sun, 13 Nov 2011 18:30:09 -0800 (PST) Received: from mail-pz0-f50.google.com (mail-pz0-f50.google.com [209.85.210.50]) by ietfa.amsl.com (Postfix) with ESMTP id 2661F11E8146; Sun, 13 Nov 2011 18:30:09 -0800 (PST) Received: by pzk5 with SMTP id 5so8385536pzk.9 for ; Sun, 13 Nov 2011 18:30:07 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=sender:subject:mime-version:content-type:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to:x-mailer; bh=OL/RTiy832CbrPkkX+uNSdoiKCy286kPwZVRx/C+bMg=; b=vu7hqD8xYWkgrJWZ8YpE7HfpC1NuwyqoX+B84qw4BYIfwoDR3w+s2s+yYFFKczW3DZ PaNQwushP99Bkcrl7qz8/yDfC92L90u8N+rvFK9CyOjWPBHyyflYxTKZytLuJG7BUkPj MfcSyyCzWbhiLMmlBxjtcH/nzm6KNo0Hc8kE4= Received: by 10.68.7.9 with SMTP id f9mr34105931pba.47.1321237807839; Sun, 13 Nov 2011 18:30:07 -0800 (PST) Received: from sjc-vpn4-250.cisco.com (128-107-239-233.cisco.com. [128.107.239.233]) by mx.google.com with ESMTPS id b2sm52766995pbc.2.2011.11.13.18.30.04 (version=TLSv1/SSLv3 cipher=OTHER); Sun, 13 Nov 2011 18:30:06 -0800 (PST) Sender: Ole Troan Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Ole Troan In-Reply-To: <23BACC91-621A-4E96-ACD6-92D226F9657A@nominum.com> Date: Mon, 14 Nov 2011 10:30:00 +0800 Content-Transfer-Encoding: quoted-printable Message-Id: <83E275B4-915B-4989-88BC-4FF85E78E2B6@employees.org> References: , <402398CF-7F7C-4B8B-91CE-6EDE54B6C4CC@employees.org> <23BACC91-621A-4E96-ACD6-92D226F9657A@nominum.com> To: Ted Lemon X-Mailer: Apple Mail (2.1084) Cc: "ipv6@ietf.org" , MIF Mailing List , dhc WG Subject: Re: [mif] [dhcwg] Conflict between RA and DHCP in MIF case 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, 14 Nov 2011 02:30:09 -0000 Ted, >> why not just merge all the information received? >> e.g. if you get DNS server over DHCP and RA, use all. >> if you get addresses via SLAAC and DHCP, you use all... >=20 > Because "just merge" is essentially equivalent to "just walk across = the river without your feet getting wet.". If you can write a spec that = does this correctly, you are probably the Messiah. isn't this what a host does anyway? if it has more than one router on = the link? cheers, Ole From Ted.Lemon@nominum.com Sun Nov 13 18:32:44 2011 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 BBED211E8156; Sun, 13 Nov 2011 18:32:44 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.553 X-Spam-Level: X-Spam-Status: No, score=-106.553 tagged_above=-999 required=5 tests=[AWL=0.046, 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 RsljRLCj2Ig8; Sun, 13 Nov 2011 18:32:44 -0800 (PST) Received: from exprod7og111.obsmtp.com (exprod7og111.obsmtp.com [64.18.2.175]) by ietfa.amsl.com (Postfix) with ESMTP id D72E311E815D; Sun, 13 Nov 2011 18:32:42 -0800 (PST) Received: from shell-too.nominum.com ([64.89.228.229]) (using TLSv1) by exprod7ob111.postini.com ([64.18.6.12]) with SMTP ID DSNKTsB9ygQBkWaqH1t6aPuNOXtytBk/J6x4@postini.com; Sun, 13 Nov 2011 18:32:43 PST 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 20CD61B82B4; Sun, 13 Nov 2011 18:32:42 -0800 (PST) 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 140E2190052; Sun, 13 Nov 2011 18:32:42 -0800 (PST) (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.01.0339.001; Sun, 13 Nov 2011 18:32:42 -0800 From: Ted Lemon To: Ole Troan Thread-Topic: [dhcwg] Conflict between RA and DHCP in MIF case Thread-Index: AQHMom9Jeyu5uv/47kCfd4auwPXOIJWsI2EA//+A3MeAAIedAP//eqTG Date: Mon, 14 Nov 2011 02:32:41 +0000 Message-ID: References: , <402398CF-7F7C-4B8B-91CE-6EDE54B6C4CC@employees.org> <23BACC91-621A-4E96-ACD6-92D226F9657A@nominum.com>, <83E275B4-915B-4989-88BC-4FF85E78E2B6@employees.org> In-Reply-To: <83E275B4-915B-4989-88BC-4FF85E78E2B6@employees.org> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "ipv6@ietf.org" , MIF Mailing List , dhc WG Subject: Re: [mif] [dhcwg] Conflict between RA and DHCP in MIF case 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, 14 Nov 2011 02:32:44 -0000 On Nov 14, 2011, at 10:30 AM, "Ole Troan" wrote: > isn't this what a host does anyway? if it has more than one router on the= link? Yes, and they reliably do it wrong. This is why we have a MIF working grou= p! :)= From ichiroumakino@gmail.com Sun Nov 13 18:35:49 2011 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 077A81F0C84; Sun, 13 Nov 2011 18:35:49 -0800 (PST) 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 sCnEjca8orum; Sun, 13 Nov 2011 18:35:48 -0800 (PST) Received: from mail-iy0-f172.google.com (mail-iy0-f172.google.com [209.85.210.172]) by ietfa.amsl.com (Postfix) with ESMTP id 5BB751F0C82; Sun, 13 Nov 2011 18:35:48 -0800 (PST) Received: by iaeo4 with SMTP id o4so8657083iae.31 for ; Sun, 13 Nov 2011 18:35:48 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=sender:subject:mime-version:content-type:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to:x-mailer; bh=CBVfHdjz0vFHC1HrrG60280fjyGcT2DWKjrPiHFihCY=; b=Pebfe+GChnxOhhhv6UWNRIjx3IPQaWwLqZPSTj7AFNrFWE/yriLs6jgPtWBbT6I0uX 4nOM6yATHVAOCdnZbUf7D5DKpDfiqJ9hGq8iHh7y/VxRLeWymCFBln1fzOHP1lC9V32H Bc5A6Uen9EaS8aPjJT294/RbgC0ESihaUO/us= Received: by 10.42.154.194 with SMTP id r2mr20951585icw.50.1321238148016; Sun, 13 Nov 2011 18:35:48 -0800 (PST) Received: from sjc-vpn4-250.cisco.com (128-107-239-233.cisco.com. [128.107.239.233]) by mx.google.com with ESMTPS id n30sm28247533ibl.4.2011.11.13.18.35.44 (version=TLSv1/SSLv3 cipher=OTHER); Sun, 13 Nov 2011 18:35:46 -0800 (PST) Sender: Ole Troan Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Ole Troan In-Reply-To: Date: Mon, 14 Nov 2011 10:35:41 +0800 Content-Transfer-Encoding: quoted-printable Message-Id: <5DA6C509-3D10-4E56-A47C-2709030BE535@employees.org> References: , <402398CF-7F7C-4B8B-91CE-6EDE54B6C4CC@employees.org> <23BACC91-621A-4E96-ACD6-92D226F9657A@nominum.com>, <83E275B4-915B-4989-88BC-4FF85E78E2B6@employees.org> To: Ted Lemon X-Mailer: Apple Mail (2.1084) Cc: "ipv6@ietf.org" , MIF Mailing List , dhc WG Subject: Re: [mif] [dhcwg] Conflict between RA and DHCP in MIF case 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, 14 Nov 2011 02:35:49 -0000 >> isn't this what a host does anyway? if it has more than one router on = the link? >=20 > Yes, and they reliably do it wrong. This is why we have a MIF working = group! :) wouldn't they continue to do it wrong if we were to specify a default = "policy"? I'm in the camp of "use all the information you've got". the prefer one = of the other by default, is heading down 3484 country, and that hasn't = been a pleasant experience. cheers, Ole From tomasz.mrugalski@gmail.com Sun Nov 13 18:39:13 2011 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 092A911E8182 for ; Sun, 13 Nov 2011 18:39:13 -0800 (PST) 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 5H8OpV6acx9U for ; Sun, 13 Nov 2011 18:39:12 -0800 (PST) Received: from mail-yw0-f44.google.com (mail-yw0-f44.google.com [209.85.213.44]) by ietfa.amsl.com (Postfix) with ESMTP id 4439011E815C for ; Sun, 13 Nov 2011 18:39:12 -0800 (PST) Received: by ywt34 with SMTP id 34so4218313ywt.31 for ; Sun, 13 Nov 2011 18:39:11 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=message-id:date:from:user-agent:mime-version:to:subject:references :in-reply-to:content-type:content-transfer-encoding; bh=LsHCsh6cMX+IqvEY0zGPp5F6M01eWDWxQmwP73K+CSc=; b=OIgNz4oegEevdYSi2zkQ8pZZp9xZ0btzX11KBlX6gVZK6mtXROF0fKBTbx8B93tWen ENcB4wpxkAQepMO6bO3KeSBPKu4Mv8U+ui4W9g0mKWVzEtS/hjRp6VZZY1JJOzgI69in g+jVklVKnPr84B+g7nZRr7m53wKxeZC1q4z+s= Received: by 10.236.178.9 with SMTP id e9mr11207972yhm.77.1321238351907; Sun, 13 Nov 2011 18:39:11 -0800 (PST) Received: from dhcp-41d0.meeting.ietf.org ([2001:df8:0:64:de2b:61ff:fee5:409c]) by mx.google.com with ESMTPS id 36sm56981380anz.2.2011.11.13.18.39.09 (version=SSLv3 cipher=OTHER); Sun, 13 Nov 2011 18:39:11 -0800 (PST) Message-ID: <4EC07F4B.6020705@gmail.com> Date: Mon, 14 Nov 2011 10:39:07 +0800 From: Tomek Mrugalski User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:8.0) Gecko/20111105 Thunderbird/8.0 MIME-Version: 1.0 To: mif@ietf.org References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [mif] Small nit on route option draft 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, 14 Nov 2011 02:39:13 -0000 On 11-11-14 09:13, Ted Lemon wrote: > I would like to ask that you reverse the prefix length and metric > fields in the option. The reason for this is that the prefix length > and prefix look like they are going to become a common encoding > (they are also used in a proposed source address configuration > option). They are essentially a single value, expressed as two > fields. I have asked the source address draft authors to group the > prefix length and prefix together; I think it makes sense to do the > same thing here. This will speed adoption of both drafts, I think. > > In order for this to be useful, of course, it would be necessary for > you to adopt the variable length format for the prefix that is used > in that draft. The draft is called > draft-ietf-6man-address-select-opt-01. Reordering fields to have prefix length immediately followed by prefix is very much ok. I'll do that. However, I'm a bit hesitant about having prefix encoded as variable length. I admit that I haven't read address-select-opt yet, some maybe there is a text somewhere that justifies variable length format. I have 3 objections regarding variable length format. 1. It is against DHC WG item regarding option guidelines, at least that is how I understand the text. See draft-ietf-dhc-option-guidelines-07, section 5. If I'm reading option-guidelines wrong, perhaps it could use more explicit wording? Also, if we decide to go with variable length, we should consider updating option-guidelines to remain consistent. 2. What about similarity to existing and widely deployed option, i.e. IAPREFIX? See RFC3633, section 10. IAPREFIX encodes prefix as 16 octects, regardless of the actual prefix length. Please do note that validation of such options correctness is trivial. Option has to have at least X octets, otherwise it is truncated. With variable length format it is not so simple anymore. I admit that it's not that complicated either, so I can live with that. I never heard anyone complaining about this format. Of course that doesn't mean that there are no such complaints. Perhaps I'm ignorant and just never heard them. 3. The case in 6man-addr-select-opt is a bit different. I haven't read that draft yet, but according to the description, prefix-len field and its relation to length of the actual prefix field is a bit strange. Length is rounded up to the next quad octet boundary. This makes the prefix field to have length 0,4,8,12 or 16 octets. For example, for prefix lenth 33 bits you send 8 bytes of prefix. If we choose to go with variable lengths, perhaps more convenient would to round up to the next octet boundary? 33 bits prefix would be stored as 40 bits (5 octets)? These are very strong arguments against variable length approach. Personally, I would prefer fixed fields, but I won't insist on it. On a related note if we choose to go with variable format, draft-mdt-softwire-map-dhcp-option-01 has to be updated as well. That draft also conveys IPv4 prefix. If we go variable, we should probably do that for both v4 and v6. That in turn makes the option validation even nastier as there would be 2 variable length fields. > I do apologize for interjecting this so late in the process, but I > think it's a substantial win to use the same format for the same > data across different options. No problem at all. I appreciate any feedback we can get on this. Tomek From Ted.Lemon@nominum.com Sun Nov 13 18:59:32 2011 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 E0FBE11E819B; Sun, 13 Nov 2011 18:59:32 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.554 X-Spam-Level: X-Spam-Status: No, score=-106.554 tagged_above=-999 required=5 tests=[AWL=0.045, 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 rlbprWjbtrpR; Sun, 13 Nov 2011 18:59:32 -0800 (PST) Received: from exprod7og126.obsmtp.com (exprod7og126.obsmtp.com [64.18.2.206]) by ietfa.amsl.com (Postfix) with ESMTP id 02B9011E8198; Sun, 13 Nov 2011 18:59:31 -0800 (PST) Received: from shell-too.nominum.com ([64.89.228.229]) (using TLSv1) by exprod7ob126.postini.com ([64.18.6.12]) with SMTP ID DSNKTsCEE8kK+Vrx1n7JsE7t2C5d6O9FCj4k@postini.com; Sun, 13 Nov 2011 18:59:32 PST 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 058C71B82B3; Sun, 13 Nov 2011 18:59:31 -0800 (PST) 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 33506190052; Sun, 13 Nov 2011 18:59:27 -0800 (PST) (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.01.0339.001; Sun, 13 Nov 2011 18:59:27 -0800 From: Ted Lemon To: Ole Troan Thread-Topic: [dhcwg] Conflict between RA and DHCP in MIF case Thread-Index: AQHMom9Jeyu5uv/47kCfd4auwPXOIJWsI2EA//+A3MeAAIedAP//eqTGgACG84D//4CHUQ== Date: Mon, 14 Nov 2011 02:59:26 +0000 Message-ID: <8CF32B5B-3A57-46F7-AB16-A50B403F7595@nominum.com> References: , <402398CF-7F7C-4B8B-91CE-6EDE54B6C4CC@employees.org> <23BACC91-621A-4E96-ACD6-92D226F9657A@nominum.com>, <83E275B4-915B-4989-88BC-4FF85E78E2B6@employees.org> , <5DA6C509-3D10-4E56-A47C-2709030BE535@employees.org> In-Reply-To: <5DA6C509-3D10-4E56-A47C-2709030BE535@employees.org> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "ipv6@ietf.org" , MIF Mailing List , dhc WG Subject: Re: [mif] [dhcwg] Conflict between RA and DHCP in MIF case 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, 14 Nov 2011 02:59:33 -0000 On Nov 14, 2011, at 10:35 AM, "Ole Troan" wrote: > wouldn't they continue to do it wrong if we were to specify a default "po= licy"? > I'm in the camp of "use all the information you've got". the prefer one o= f the other by default, is heading down 3484 country, and that hasn't been = a pleasant experience. Great, then we can disband MIF and save everyone a lot of time! All of the= various failure modes, DOS attacks and spoofing attacks that are possible = in a MIF environment aren't all that important... :) From Ted.Lemon@nominum.com Sun Nov 13 21:39:56 2011 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 346F111E8184 for ; Sun, 13 Nov 2011 21:39:56 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.555 X-Spam-Level: X-Spam-Status: No, score=-106.555 tagged_above=-999 required=5 tests=[AWL=0.044, 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 vLp8VDEBblyH for ; Sun, 13 Nov 2011 21:39:55 -0800 (PST) Received: from exprod7og124.obsmtp.com (exprod7og124.obsmtp.com [64.18.2.26]) by ietfa.amsl.com (Postfix) with ESMTP id 228FE11E815A for ; Sun, 13 Nov 2011 21:39:54 -0800 (PST) Received: from shell-too.nominum.com ([64.89.228.229]) (using TLSv1) by exprod7ob124.postini.com ([64.18.6.12]) with SMTP ID DSNKTsCpndVrBB2o2/jWNM7SaWdYRr7Oh4Ej@postini.com; Sun, 13 Nov 2011 21:39:55 PST 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 6E2541B82B3 for ; Sun, 13 Nov 2011 21:39:41 -0800 (PST) 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 CC859190052; Sun, 13 Nov 2011 21:39:38 -0800 (PST) (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.01.0339.001; Sun, 13 Nov 2011 21:39:38 -0800 From: Ted Lemon To: Tomek Mrugalski Thread-Topic: [mif] Small nit on route option draft Thread-Index: Acyiao8QD5vjbXm9TE+xl6KwP+5RYgATxOuA//9+m82AAIwvAP//oYn1 Date: Mon, 14 Nov 2011 05:39:37 +0000 Message-ID: References: , <4EC07F4B.6020705@gmail.com> , <4EC08858.3070007@gmail.com> In-Reply-To: <4EC08858.3070007@gmail.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: MIF Mailing List Subject: Re: [mif] Small nit on route option draft 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, 14 Nov 2011 05:39:56 -0000 I replied to Tomek's original message, but neglected to cc: the list. Thi= s is my reply to his reply. I will forward my original reply as well=97I = apologize for the omission. On Nov 14, 2011, at 11:17 AM, "Tomek Mrugalski" wrote: > Of course, it a guideline, not a rule. Still, it would be useful to have = a consistent guideline that is followed. Perhaps we could add a section to = option-guidelines regarding recommended prefix format? Will you send a requ= est about this to David or do you want me to do that? I am thinking it might be worth writing a document that just describes all = the known data formats used by DHCPv6 options. Because so many options we= re defined at the time the DHCPv4 spec went out, we don't have as much of a= problem with consistency, but with DHCPv6 I think we are treading a danger= ous path. > It's not an issue, just something we could probably take into considerati= on. With fixed length, it's trivial. With variable length, it's very easy. = Ok, so we discussed that and decided that validation is not a concern. Cool. > I'd like to review it, but the reality is that I will probably add it to = endless list of draft that I'm supposed to read... I'm co-authoring 6 draft= s currently and for some reason I usually end up being the most active co-a= uthor. I feel your pain. I can say personally that I really appreciate all the w= ork you're doing. If you don't have time to read this draft, it's okay=97= I think we have sufficient review. > That's understandable. It was developed at break neck pace around 2 or 3 = weeks ago. It will be presented today in Softwires, at 13:00. Clever. > So I suppose your message is clear - go with variable length prefix. Ok, = I'll update all drafts I'm working on. Thanks. And as you suggested, cut the prefix on byte boundaries. > You responded directly to me. Perhaps you wanted to reply with cc: to mif= ? Argh. Sorry about that. From Ted.Lemon@nominum.com Sun Nov 13 21:41:07 2011 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 41F7011E8196 for ; Sun, 13 Nov 2011 21:41:07 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.555 X-Spam-Level: X-Spam-Status: No, score=-106.555 tagged_above=-999 required=5 tests=[AWL=0.043, 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 muWlzUq40sy6 for ; Sun, 13 Nov 2011 21:41:06 -0800 (PST) Received: from exprod7og116.obsmtp.com (exprod7og116.obsmtp.com [64.18.2.219]) by ietfa.amsl.com (Postfix) with ESMTP id B205411E815A for ; Sun, 13 Nov 2011 21:41:05 -0800 (PST) Received: from shell-too.nominum.com ([64.89.228.229]) (using TLSv1) by exprod7ob116.postini.com ([64.18.6.12]) with SMTP ID DSNKTsCp8SAPHib8jhnyWhgOEDb2Gkrkn5mR@postini.com; Sun, 13 Nov 2011 21:41:05 PST 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 E0A2D1B82B3 for ; Sun, 13 Nov 2011 21:41:04 -0800 (PST) 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 D9F40190052 for ; Sun, 13 Nov 2011 21:41:04 -0800 (PST) (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.01.0339.001; Sun, 13 Nov 2011 21:41:04 -0800 From: Ted Lemon To: MIF Mailing List Thread-Topic: [mif] Small nit on route option draft Thread-Index: Acyiao8QD5vjbXm9TE+xl6KwP+5RYgATxOuA//9+m82AAC4fKQ== Date: Mon, 14 Nov 2011 05:41:04 +0000 Message-ID: References: , <4EC07F4B.6020705@gmail.com>, In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: Content-Type: multipart/alternative; boundary="_000_EE099B040FC547AA9BCE317C5C05186Dnominumcom_" MIME-Version: 1.0 Subject: [mif] Fwd: Small nit on route option draft 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, 14 Nov 2011 05:41:07 -0000 --_000_EE099B040FC547AA9BCE317C5C05186Dnominumcom_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable I accidentally failed to include mif in this reply; here's the reply, as me= ntioned previously. From: Ted Lemon > Date: November 14, 2011 10:55:59 AM GMT+08:00 To: Tomek Mrugalski > Subject: Re: [mif] Small nit on route option draft On Nov 14, 2011, at 10:39 AM, "Tomek Mrugalski" > wrote: 1. It is against DHC WG item regarding option guidelines, at least that is = how I understand the text. See draft-ietf-dhc-option-guidelines-07, section= 5. If I'm reading option-guidelines wrong, perhaps it could use more expli= cit wording? Also, if we decide to go with variable length, we should consi= der updating option-guidelines to remain consistent. This is not a valid objection. The option guidelines draft is informational= , so can't be normative. It is also not an RFC, because it hasn't passed WG= LC or been reviewed by the IETF. So please do not use this document as if i= t were normative. 2. What about similarity to existing and widely deployed option, i.e. IAPRE= FIX? See RFC3633, section 10. IAPREFIX encodes prefix as 16 octects, regard= less of the actual prefix length. This is true, and unfortunate. The reason, I thing, is that Ralph wasn't ex= pecting to see a lot of these prefixes, and hence didn't consider space to = be an issue. But it is an issue with the route option and also with the add= ress selection option. Please do note that validation of such options correctness is trivial. Opti= on has to have at least X octets, otherwise it is truncated. With variable = length format it is not so simple anymore. I admit that it's not that compl= icated either, so I can live with that. I never heard anyone complaining ab= out this format. Of course that doesn't mean that there are no such complai= nts. Perhaps I'm ignorant and just never heard them. I think this is simply because it's not an issue with PD. I really don't th= ink validating the variable-length prefix is an issue. 3. The case in 6man-addr-select-opt is a bit different. I haven't read that= draft yet, but according to the description, prefix-len field and its relation to length of the actual prefix field is a bit strange. Len= gth is rounded up to the next quad octet boundary. This makes the prefix fi= eld to have length 0,4,8,12 or 16 octets. For example, for prefix lenth 33 = bits you send 8 bytes of prefix. If we choose to go with variable lengths, = perhaps more convenient would to round up to the next octet boundary? 33 bi= ts prefix would be stored as 40 bits (5 octets)? Yes, I agree. I will mention this to the authors. BTW, the authors are loo= king for more review, so it would be very helpful if you reviewed the draft= . On a related note if we choose to go with variable format, draft-mdt-softwi= re-map-dhcp-option-01 has to be updated as well. That draft also conveys IP= v4 prefix. If we go variable, we should probably do that for both v4 and v6= . That in turn makes the option validation even nastier as there would be 2= variable length fields. It's completely different. In IPv4, the maximum waste is 3 bytes. In IPv6, = the /typical/ waste will be 8 bytes. But I agree that the document needs = to be updated to group prefix length with prefix and use the variable lengt= h prefix format for IPv6. Thanks for bringing this document to my attention= =96it had slipped under my radar. :) No problem at all. I appreciate any feedback we can get on this. Thanks! --_000_EE099B040FC547AA9BCE317C5C05186Dnominumcom_ Content-Type: text/html; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable
I accidentally failed to include mif in this reply; here's the reply, = as mentioned previously.

From: Ted Lemon <Te= d.Lemon@nominum.com>
Date: November 14, 2011 10:55:59 AM GMT+08:00
To: Tomek Mrugalski <tomasz.mrugalski@gmail.com>
Subject: Re: [mif] Small nit on route option draft

On Nov 14, 2011, at 10:39 AM, "Tomek Mrugalski" <tomasz.mrugalski@gmail.com&= gt; wrote:

1. It is against DHC WG item regarding opti= on guidelines, at least that is how I understand the text. See draft-ietf-d= hc-option-guidelines-07, section 5. If I'm reading option-guidelines wrong,= perhaps it could use more explicit wording? Also, if we decide to go with variable length, we should consider= updating option-guidelines to remain consistent.

This is not a valid objection. The option guidelines draft is informa= tional, so can't be normative. It is also not an RFC, because it hasn't pas= sed WGLC or been reviewed by the IETF. So please do not use this document a= s if it were normative.

2. What about similarity to existing and wi= dely deployed option, i.e. IAPREFIX? See RFC3633, section 10. IAPREFIX enco= des prefix as 16 octects, regardless of the actual prefix length.

This is true, and unfortunate. The reason, I thing, is that Ralph was= n't expecting to see a lot of these prefixes, and hence didn't consider spa= ce to be an issue. But it is an issue with the route option and also with t= he address selection option.

Please do note that validation of such opti= ons correctness is trivial. Option has to have at least X octets, otherwise= it is truncated. With variable length format it is not so simple anymore. = I admit that it's not that complicated either, so I can live with that. I never heard anyone complaining about th= is format. Of course that doesn't mean that there are no such complaints. P= erhaps I'm ignorant and just never heard them.

I think this is simply because it's not an issue with PD. I really do= n't think validating the variable-length prefix is an issue.


3. The case in 6man-addr-select-opt is a bi= t different. I haven't read that draft yet, but according to the descriptio= n, prefix-len field
and its relation to length of the actual pr= efix field is a bit strange. Length is rounded up to the next quad octet bo= undary. This makes the prefix field to have length 0,4,8,12 or 16 octets. F= or example, for prefix lenth 33 bits you send 8 bytes of prefix. If we choose to go with variable lengths, perh= aps more convenient would to round up to the next octet boundary? 33 bits p= refix would be stored as 40 bits (5 octets)?

Yes, I agree. I will mention this to the authors.  BTW, the auth= ors are looking for more review, so it would be very helpful if you reviewe= d the draft.

On a related note if we choose to go with v= ariable format, draft-mdt-softwire-map-dhcp-option-01 has to be updated as = well. That draft also conveys IPv4 prefix. If we go variable, we should pro= bably do that for both v4 and v6. That in turn makes the option validation even nastier as there would be 2 = variable length fields.

It's completely different. In IPv4, the maximum waste is 3 bytes. In = IPv6, the /typical/ waste will be 8 bytes.   But I agree that the= document needs to be updated to group prefix length with prefix and use th= e variable length prefix format for IPv6. Thanks for bringing this document to my attention=96it had slipped under m= y radar.  :)

No problem at all. I appreciate any feedbac= k we can get on this.

Thanks!
--_000_EE099B040FC547AA9BCE317C5C05186Dnominumcom_-- From Ted.Lemon@nominum.com Sun Nov 13 22:21:04 2011 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 0EFE111E80BE for ; Sun, 13 Nov 2011 22:21:04 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.557 X-Spam-Level: X-Spam-Status: No, score=-106.557 tagged_above=-999 required=5 tests=[AWL=0.042, 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 0OmALfapgxal for ; Sun, 13 Nov 2011 22:21:03 -0800 (PST) Received: from exprod7og124.obsmtp.com (exprod7og124.obsmtp.com [64.18.2.26]) by ietfa.amsl.com (Postfix) with ESMTP id 4995611E8095 for ; Sun, 13 Nov 2011 22:21:02 -0800 (PST) Received: from shell-too.nominum.com ([64.89.228.229]) (using TLSv1) by exprod7ob124.postini.com ([64.18.6.12]) with SMTP ID DSNKTsCzTjLOceFZoz5aR2maSLM6hvH6hJSn@postini.com; Sun, 13 Nov 2011 22:21:03 PST 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 0BE9A1B82B4 for ; Sun, 13 Nov 2011 22:21:02 -0800 (PST) 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 EB81B190052; Sun, 13 Nov 2011 22:21:01 -0800 (PST) (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.01.0339.001; Sun, 13 Nov 2011 22:21:01 -0800 From: Ted Lemon To: Tomek Mrugalski Thread-Topic: [mif] Small nit on route option draft Thread-Index: Acyiao8QD5vjbXm9TE+xl6KwP+5RYgATxOuA//+343k= Date: Mon, 14 Nov 2011 06:21:01 +0000 Message-ID: References: , <4EC07F4B.6020705@gmail.com> In-Reply-To: <4EC07F4B.6020705@gmail.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "mif@ietf.org" Subject: Re: [mif] Small nit on route option draft 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, 14 Nov 2011 06:21:04 -0000 On Nov 14, 2011, at 10:39 AM, "Tomek Mrugalski" wrote: > On a related note if we choose to go with variable format, draft-mdt-soft= wire-map-dhcp-option-01 has to be updated as well. That draft also conveys = IPv4 prefix. If we go variable, we should probably do that for both v4 and = v6. That in turn makes the option validation even nastier as there would be= 2 variable length fields. BTW, my previous comment about efficiency assumes that you're only sending = one IPv4 prefix. However, there is a DHCPv4 option that sends prefixes th= e way you describe: RFC3442, the Classless Static Routes option. I'm pret= ty sure you already knew that, but I thought I'd mention it here for comple= teness. I still don't think you need to do prefix compression for this particular o= ption. I don't think it's likely that we're going to see a profusion of I= Pv4 prefixes in DHCPv6 options; the reason I raised the concern about IPv6 = prefixes is that I suspect we will see a profusion of those, and indeed the= route option and address selection option are evidence of that.= From mohacsi@niif.hu Sun Nov 13 23:55:48 2011 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 6E35211E824C; Sun, 13 Nov 2011 23:55:48 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.004 X-Spam-Level: X-Spam-Status: No, score=-0.004 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_HU=1.35, HOST_EQ_HU=1.245] 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 7SwRaSKTCd0y; Sun, 13 Nov 2011 23:55:47 -0800 (PST) Received: from mail.ki.iif.hu (mail.ki.iif.hu [IPv6:2001:738:0:411::241]) by ietfa.amsl.com (Postfix) with ESMTP id 2234011E8243; Sun, 13 Nov 2011 23:55:47 -0800 (PST) Received: from bolha.lvs.iif.hu (bolha.lvs.iif.hu [193.225.14.181]) by mail.ki.iif.hu (Postfix) with ESMTP id 6CEB28782D; Mon, 14 Nov 2011 08:55:45 +0100 (CET) X-Virus-Scanned: Debian amavisd-new at bolha.lvs.iif.hu Received: from mail.ki.iif.hu ([IPv6:::ffff:193.6.222.241]) by bolha.lvs.iif.hu (bolha.lvs.iif.hu [::ffff:193.225.14.72]) (amavisd-new, port 10024) with ESMTP id lIk6E--GN1y8; Mon, 14 Nov 2011 08:55:42 +0100 (CET) Received: by mail.ki.iif.hu (Postfix, from userid 9002) id 11A3D8782C; Mon, 14 Nov 2011 08:55:42 +0100 (CET) Received: from localhost (localhost [127.0.0.1]) by mail.ki.iif.hu (Postfix) with ESMTP id 023F8877F5; Mon, 14 Nov 2011 08:55:41 +0100 (CET) Date: Mon, 14 Nov 2011 08:55:41 +0100 (CET) From: Mohacsi Janos X-X-Sender: mohacsi@mignon.ki.iif.hu To: Hui Deng In-Reply-To: Message-ID: References: User-Agent: Alpine 2.00 (BSF 1167 2008-08-23) MIME-Version: 1.0 Content-Type: MULTIPART/MIXED; BOUNDARY="0-1307643040-1321257342=:66599" X-Mailman-Approved-At: Mon, 14 Nov 2011 00:05:31 -0800 Cc: MIF Mailing List , ipv6@ietf.org, dhc WG Subject: Re: [mif] [dhcwg] Conflict between RA and DHCP in MIF case 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, 14 Nov 2011 07:55:48 -0000 This message is in MIME format. The first part should be readable text, while the remaining parts are likely unreadable without MIME-aware tools. --0-1307643040-1321257342=:66599 Content-Type: TEXT/PLAIN; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8BIT On Mon, 14 Nov 2011, Hui Deng wrote: > Hello 6MAN and DHCP, >   > Especially thanks Wes Beebee, Hemant Singh, Brian Carpenter, Alex and Ted's discussion. >   > MIF is going to discuss the confliction between RA and DHCP on tuesday afternoon MIF session (15:20-17:00)  > the author Tomasz has propose below resolution: >   > The problem is about potential conflict between RA and DHCP. Our > proposed answer is as follows: > > RA provides configuration to all hosts in a network. DHCP can provide > configuration on a per host basis. Therefore it may be useful to use > DHCP to "override" configuration for some hosts in a network (e.g. > engineering department has extra routes defined for a lab network). As > such, DHCP should be preferred. > > However, there is also a matter of security. Both RA and DHCPv6 can be > secured. If SEND is deployed, RA is more trustworthy than DHCP, so it > should be preferred. Finally, there is such thing as secure DHCP, so if > both RA and DHCP are secure, prefer SEND. I must admit that I never > heard about any realistic deployments of secure DHCP, but it will change > over time. > > This approach can be summed as: favor secure, favor DHCP. Or to be more > explicit, there's a complete list of all cases: > a) RA vs DHCP => prefer DHCP > b) RA(SEND) vs DHCP => prefer RA > c) RA vs secure DHCP => prefer DHCP > d) RA(SEND) vs secure DHCP => prefer DHCP > > Does it sound reasonable? > > This approach is very similar to what was described in DNS configuration > over RA and DHCP (except the part about both RA and DHCP being secure > that is not covered in RFC6106). > > To summarize the discussion so far, Ted Lemon on MIF list agreed that > DHCP should be preferred. Herman Singh on 6MAN list suggested to go look > at what DNS over RA proposes and use the same approach. RFC6106, section > 5.3.1covers cases a) and b). c) and d) are logical extension that takes > DHCPv6 security into consideration. My understanding is that proposed > solution will be satisfactory to everyone. I think in reality it will not be very easy to implement all these things. Some Operating System might implement RA(SEND), some the Secure DHCP, some none of above. . The operator should operate the network consistently: - same information all the relevant channel..... This preferential treatment can give some protections against malicious activity or misconfiguration. Best Regards, Janos Mohacsi --0-1307643040-1321257342=:66599-- From Ted.Lemon@nominum.com Mon Nov 14 01:29:14 2011 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 BFEAB21F8EC4; Mon, 14 Nov 2011 01:29:13 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.558 X-Spam-Level: X-Spam-Status: No, score=-106.558 tagged_above=-999 required=5 tests=[AWL=0.041, 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 rpC-C+D4ZQlu; Mon, 14 Nov 2011 01:29:12 -0800 (PST) Received: from exprod7og127.obsmtp.com (exprod7og127.obsmtp.com [64.18.2.210]) by ietfa.amsl.com (Postfix) with ESMTP id A918521F8EC1; Mon, 14 Nov 2011 01:29:11 -0800 (PST) Received: from shell-too.nominum.com ([64.89.228.229]) (using TLSv1) by exprod7ob127.postini.com ([64.18.6.12]) with SMTP ID DSNKTsDfWlsuc1mRyVSRcmSwRRMFmjNZ6ab3@postini.com; Mon, 14 Nov 2011 01:29:11 PST 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 7ED531B82B5; Mon, 14 Nov 2011 01:28:58 -0800 (PST) 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 63C35190052; Mon, 14 Nov 2011 01:28:57 -0800 (PST) (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.01.0339.001; Mon, 14 Nov 2011 01:28:57 -0800 From: Ted Lemon To: Mohacsi Janos Thread-Topic: [dhcwg] Conflict between RA and DHCP in MIF case Thread-Index: AQHMom9Jeyu5uv/47kCfd4auwPXOIJWshtmA//+T8hI= Date: Mon, 14 Nov 2011 09:28:56 +0000 Message-ID: References: , In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "ipv6@ietf.org" , MIF Mailing List , dhc WG Subject: Re: [mif] [dhcwg] Conflict between RA and DHCP in MIF case 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, 14 Nov 2011 09:29:15 -0000 On Nov 14, 2011, at 3:55 PM, "Mohacsi Janos" wrote: > I think in reality it will not be very easy to implement all these things= . Some Operating System might implement RA(SEND), some the Secure DHCP, som= e none of above. . The operator should operate the network consistently: - = same information all the relevant channel..... This preferential treatment = can give some protections against malicious activity or misconfiguration. This is true, but the problem is that the RA may be trustworthy and DHCP no= t, or vice versa. So it's not safe to assume that the information you get f= rom each one is trustworthy, even though of course on a good network it sho= uld be.=20 From alexandru.petrescu@gmail.com Mon Nov 14 02:11:22 2011 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 8487E11E813B; Mon, 14 Nov 2011 02:11:22 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.326 X-Spam-Level: X-Spam-Status: No, score=-6.326 tagged_above=-999 required=5 tests=[AWL=-0.077, 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 Ld6HmnCmtY2R; Mon, 14 Nov 2011 02:11:21 -0800 (PST) Received: from sainfoin-out.extra.cea.fr (sainfoin-out.extra.cea.fr [132.167.192.144]) by ietfa.amsl.com (Postfix) with ESMTP id 3153C21F8F64; Mon, 14 Nov 2011 02:08:57 -0800 (PST) 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.2) with ESMTP id pAEA8IHM018751 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Mon, 14 Nov 2011 11:08:18 +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 pAEA8Itn031226; Mon, 14 Nov 2011 11:08:18 +0100 (envelope-from alexandru.petrescu@gmail.com) Received: from [127.0.0.1] ([132.166.133.173]) by muguet2.intra.cea.fr (8.13.8/8.13.8/CEAnet-Intranet-out-1.1) with ESMTP id pAEA8HNf005826; Mon, 14 Nov 2011 11:08:18 +0100 Message-ID: <4EC0E891.1060505@gmail.com> Date: Mon, 14 Nov 2011 11:08:17 +0100 From: Alexandru Petrescu User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:8.0) Gecko/20111105 Thunderbird/8.0 MIME-Version: 1.0 To: dhcwg@ietf.org, mif References: , <402398CF-7F7C-4B8B-91CE-6EDE54B6C4CC@employees.org> <23BACC91-621A-4E96-ACD6-92D226F9657A@nominum.com> In-Reply-To: <23BACC91-621A-4E96-ACD6-92D226F9657A@nominum.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Subject: Re: [mif] Conflict between RA and DHCP in MIF case 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, 14 Nov 2011 10:11:24 -0000 Le 14/11/2011 03:24, Ted Lemon a écrit : > On Nov 14, 2011, at 9:59 AM, "Ole Troan" > wrote: >> why not just merge all the information received? e.g. if you get >> DNS server over DHCP and RA, use all. if you get addresses via >> SLAAC and DHCP, you use all... > > Because "just merge" is essentially equivalent to "just walk across > the river without your feet getting wet.". One ingredient helping the merge is to represent data in the same manner. It would hardly merge two default route entries with a lifetime on 32bit and another on 16bit. Alex > If you can write a spec that does this correctly, you are probably > the Messiah. _______________________________________________ dhcwg > mailing list dhcwg@ietf.org > https://www.ietf.org/mailman/listinfo/dhcwg > From Ted.Lemon@nominum.com Mon Nov 14 02:26:16 2011 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 7DAD021F8AFF; Mon, 14 Nov 2011 02:26:16 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.558 X-Spam-Level: X-Spam-Status: No, score=-106.558 tagged_above=-999 required=5 tests=[AWL=0.041, 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 6-AYzGQ40vSI; Mon, 14 Nov 2011 02:26:16 -0800 (PST) Received: from exprod7og115.obsmtp.com (exprod7og115.obsmtp.com [64.18.2.217]) by ietfa.amsl.com (Postfix) with ESMTP id E075921F8468; Mon, 14 Nov 2011 02:26:13 -0800 (PST) Received: from shell-too.nominum.com ([64.89.228.229]) (using TLSv1) by exprod7ob115.postini.com ([64.18.6.12]) with SMTP ID DSNKTsDsxeVDLEQoMjTbPB4D6cP2l3c2KY6I@postini.com; Mon, 14 Nov 2011 02:26:14 PST 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 EA9D21B82B4; Mon, 14 Nov 2011 02:26:12 -0800 (PST) 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 D0DB2190052; Mon, 14 Nov 2011 02:26:11 -0800 (PST) (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.01.0339.001; Mon, 14 Nov 2011 02:26:11 -0800 From: Ted Lemon To: Alexandru Petrescu Thread-Topic: [dhcwg] Conflict between RA and DHCP in MIF case Thread-Index: AQHMom9Jeyu5uv/47kCfd4auwPXOIJWsI2EA//+A3MeAAQeogP//fuT6 Date: Mon, 14 Nov 2011 10:26:11 +0000 Message-ID: <87379F9F-CB45-4FC1-B411-26D5BBC2DC89@nominum.com> References: , <402398CF-7F7C-4B8B-91CE-6EDE54B6C4CC@employees.org> <23BACC91-621A-4E96-ACD6-92D226F9657A@nominum.com>, <4EC0E891.1060505@gmail.com> In-Reply-To: <4EC0E891.1060505@gmail.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "dhcwg@ietf.org" , mif Subject: Re: [mif] [dhcwg] Conflict between RA and DHCP in MIF case 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, 14 Nov 2011 10:26:16 -0000 On Nov 14, 2011, at 6:14 PM, "Alexandru Petrescu" wrote: > One ingredient helping the merge is to represent data in the same > manner. It would hardly merge two default route entries with a > lifetime on 32bit and another on 16bit. Again? Oy.=20 The problem of merging has to do with orthogonal (and possibly untrustworth= y) administrative domains, not trivial differences in data representation. = If /only/ the problem were that simple!= From denghui02@gmail.com Mon Nov 14 03:10:57 2011 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 103B421F8B7E; Mon, 14 Nov 2011 03:10:57 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.598 X-Spam-Level: X-Spam-Status: No, score=-103.598 tagged_above=-999 required=5 tests=[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 FExjS5TWswYC; Mon, 14 Nov 2011 03:10:56 -0800 (PST) Received: from mail-yx0-f172.google.com (mail-yx0-f172.google.com [209.85.213.172]) by ietfa.amsl.com (Postfix) with ESMTP id 9459421F8B84; Mon, 14 Nov 2011 03:10:54 -0800 (PST) Received: by yenq4 with SMTP id q4so3201678yen.31 for ; Mon, 14 Nov 2011 03:10:39 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:date:message-id:subject:from:to:content-type; bh=Z1teKVB2wgHV9DSqbcgeaFDvjZCM/6R9OBLzxwJM56Y=; b=oFNvCqXlml+Lnm+ijwyxiMCr+QPTVMFfFpQ98SR7sxxSjGbFzSPNSMh9yDcSybthnx B6pwy2F9V17E7o2KEtJ5UzdA7Hp/uOgOgMvcTVSBeas+bcNcICt3JcR+k6hgGMw/qLAN e12H8MGaUWeojuIjo+jVllzMPLoc7tacK8hFk= MIME-Version: 1.0 Received: by 10.236.155.2 with SMTP id i2mr13727959yhk.115.1321269038977; Mon, 14 Nov 2011 03:10:38 -0800 (PST) Received: by 10.146.84.10 with HTTP; Mon, 14 Nov 2011 03:10:38 -0800 (PST) Date: Mon, 14 Nov 2011 19:10:38 +0800 Message-ID: From: Hui Deng To: MIF Mailing List , dhc WG , ipv6@ietf.org Content-Type: multipart/alternative; boundary=20cf30363adbb8934404b1afeb9f Subject: [mif] New MIF agenda posted 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, 14 Nov 2011 11:10:57 -0000 --20cf30363adbb8934404b1afeb9f Content-Type: text/plain; charset=ISO-8859-1 Hello all We are going to postpone the mif dhc route option discussion to the second session to avoid the confliction with Softwire http://www.ietf.org/proceedings/82/agenda/mif.txt thanks for your work -Hui --20cf30363adbb8934404b1afeb9f Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Hello all
=A0
We are going to postpone the mif dhc route option discussion to the se= cond session to avoid the confliction with Softwire
=A0
=A0
thanks for your work
=A0
-Hui
--20cf30363adbb8934404b1afeb9f-- From maximilien.mouton@gmail.com Mon Nov 14 03:58:30 2011 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 8524111E8193; Mon, 14 Nov 2011 03:58:30 -0800 (PST) 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 usJrHEFm7kVn; Mon, 14 Nov 2011 03:58:30 -0800 (PST) Received: from mail-bw0-f44.google.com (mail-bw0-f44.google.com [209.85.214.44]) by ietfa.amsl.com (Postfix) with ESMTP id 84A2111E814A; Mon, 14 Nov 2011 03:58:29 -0800 (PST) Received: by bkbzv15 with SMTP id zv15so7175657bkb.31 for ; Mon, 14 Nov 2011 03:58:27 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=PM43X7tV3Cu0+V5/G3yKhiFse0AXfbgnyWoWIwwoTDo=; b=Wy6zsv67ARlUmeL/MUVbAfT0XOpQ2fhZzyIG521EuxR1QaQvdbEYOVZB9cKLiLRbGx tn0qH+xKrsEJzrzjAz6b2pHpHChh+dql6Z8n7Zm2AWTFhgiF2YfphC//oSvqwtDYrVQ5 3o/5XNEmHxJGbiHo5Qm0aSGYSz3m+VYFOhh38= MIME-Version: 1.0 Received: by 10.205.133.16 with SMTP id hw16mr11106259bkc.128.1321271907226; Mon, 14 Nov 2011 03:58:27 -0800 (PST) Received: by 10.223.81.77 with HTTP; Mon, 14 Nov 2011 03:58:26 -0800 (PST) In-Reply-To: <87379F9F-CB45-4FC1-B411-26D5BBC2DC89@nominum.com> References: <402398CF-7F7C-4B8B-91CE-6EDE54B6C4CC@employees.org> <23BACC91-621A-4E96-ACD6-92D226F9657A@nominum.com> <4EC0E891.1060505@gmail.com> <87379F9F-CB45-4FC1-B411-26D5BBC2DC89@nominum.com> Date: Mon, 14 Nov 2011 12:58:26 +0100 Message-ID: From: Maximilien Mouton To: Ted Lemon Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: "dhcwg@ietf.org" , mif Subject: Re: [mif] [dhcwg] Conflict between RA and DHCP in MIF case 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, 14 Nov 2011 11:58:30 -0000 Hello Ted, dhc and mif, > >-----Original Message----- >From: mif-bounces@ietf.org [mailto:mif-bounces@ietf.org] On Behalf Of >Ted Lemon >Sent: lundi 14 novembre 2011 11:26 >To: Alexandru Petrescu >Cc: dhcwg@ietf.org; mif >Subject: Re: [mif] [dhcwg] Conflict between RA and DHCP in MIF case > >On Nov 14, 2011, at 6:14 PM, "Alexandru Petrescu" wrote: >> One ingredient helping the merge is to represent data in the same >> manner.=A0 It would hardly merge two default route entries with a >> lifetime on 32bit and another on 16bit. > >Again?=A0=A0 Oy. > >The problem of merging has to do with orthogonal (and possibly untrustwort= hy) administrative domains, not trivial differences in data representation.= =A0 If /only/ the problem were that simple! > We all agree that this problem is not that simple. I think if both RA and DHCP are trustworthy, information received can be merge and consistent lifetimes size help to do this. In case of conflict a choice as to be made by the client. I agree with the rules stated by Hui. But, for some cases, one way of managing RA and DHCP information is already close to exist because rcf 4191 and draft route option (it is not quite clear but it seems) propose route preference option. Thus, with current specifications, if RA provides a default route with a high preference and DHCP another default route with medium preference the client should take RA's default route and vice versa. The question is: Has this information decided by admins to prevail over the rules stated here? If yes when? Personally I think that clients should have the last word. Maximilien >_______________________________________________ >mif mailing list >mif@ietf.org >https://www.ietf.org/mailman/listinfo/mif From pierrick.seite@orange.com Mon Nov 14 07:41:24 2011 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 0C33511E82D8; Mon, 14 Nov 2011 07:41:24 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.155 X-Spam-Level: X-Spam-Status: No, score=-3.155 tagged_above=-999 required=5 tests=[AWL=0.094, BAYES_00=-2.599, HELO_EQ_FR=0.35, 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 plpdjwtSR6rr; Mon, 14 Nov 2011 07:41:23 -0800 (PST) Received: from p-mail2.rd.francetelecom.com (p-mail2.rd.francetelecom.com [195.101.245.16]) by ietfa.amsl.com (Postfix) with ESMTP id 3CD2011E82B4; Mon, 14 Nov 2011 07:41:23 -0800 (PST) Received: from p-mail2.rd.francetelecom.com (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with SMTP id C7C09B58004; Mon, 14 Nov 2011 16:51:37 +0100 (CET) Received: from ftrdsmtp1.rd.francetelecom.fr (unknown [10.192.128.46]) by p-mail2.rd.francetelecom.com (Postfix) with ESMTP id BDBCB858001; Mon, 14 Nov 2011 16:51:37 +0100 (CET) Received: from ftrdmel0.rd.francetelecom.fr ([10.192.128.56]) by ftrdsmtp1.rd.francetelecom.fr with Microsoft SMTPSVC(6.0.3790.4675); Mon, 14 Nov 2011 16:41:22 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Date: Mon, 14 Nov 2011 16:41:19 +0100 Message-ID: <843DA8228A1BA74CA31FB4E111A5C46202068093@ftrdmel0.rd.francetelecom.fr> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [mif] [dhcwg] Conflict between RA and DHCP in MIF case Thread-Index: AcyixLuKGCucSkSrSwqPgELD/3H0ggAHbP0g References: <402398CF-7F7C-4B8B-91CE-6EDE54B6C4CC@employees.org><23BACC91-621A-4E96-ACD6-92D226F9657A@nominum.com><4EC0E891.1060505@gmail.com><87379F9F-CB45-4FC1-B411-26D5BBC2DC89@nominum.com> From: To: , X-OriginalArrivalTime: 14 Nov 2011 15:41:22.0661 (UTC) FILETIME=[DC719950:01CCA2E3] Cc: dhcwg@ietf.org, mif@ietf.org Subject: Re: [mif] [dhcwg] Conflict between RA and DHCP in MIF case 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, 14 Nov 2011 15:41:24 -0000 Hi, IMU, conflict issue raises up when the node is simultaneously attached = to two different administrative domains. In that case, we can't assume = consistency in lifetime size or default route preference or whatever... = In that case, it is reasonable to state that the node should apply the = default policy as suggested by Hui. =20 Pierrick > -----Message d'origine----- > De=A0: mif-bounces@ietf.org [mailto:mif-bounces@ietf.org] De la part = de > Maximilien Mouton > Envoy=E9=A0: lundi 14 novembre 2011 12:58 > =C0=A0: Ted Lemon > Cc=A0: dhcwg@ietf.org; mif > Objet=A0: Re: [mif] [dhcwg] Conflict between RA and DHCP in MIF case >=20 > Hello Ted, dhc and mif, >=20 > > > >-----Original Message----- > >From: mif-bounces@ietf.org [mailto:mif-bounces@ietf.org] On Behalf Of > >Ted Lemon > >Sent: lundi 14 novembre 2011 11:26 > >To: Alexandru Petrescu > >Cc: dhcwg@ietf.org; mif > >Subject: Re: [mif] [dhcwg] Conflict between RA and DHCP in MIF case > > > >On Nov 14, 2011, at 6:14 PM, "Alexandru Petrescu" > wrote: > >> One ingredient helping the merge is to represent data in the same > >> manner.=A0 It would hardly merge two default route entries with a > >> lifetime on 32bit and another on 16bit. > > > >Again?=A0=A0 Oy. > > > >The problem of merging has to do with orthogonal (and possibly > untrustworthy) administrative domains, not trivial differences in data > representation.=A0 If /only/ the problem were that simple! > > >=20 >=20 > We all agree that this problem is not that simple. > I think if both RA and DHCP are trustworthy, information received can > be merge and consistent lifetimes size help to do this. > In case of conflict a choice as to be made by the client. > I agree with the rules stated by Hui. >=20 > But, for some cases, one way of managing RA and DHCP information is > already close to exist because rcf 4191 and draft route option (it is > not quite clear but it seems) propose route preference option. >=20 > Thus, with current specifications, if RA provides a default route with > a high preference and DHCP another default route with medium > preference the client should take RA's default route and vice versa. >=20 > The question is: Has this information decided by admins to prevail > over the rules stated here? If yes when? >=20 > Personally I think that clients should have the last word. >=20 >=20 > Maximilien >=20 > >_______________________________________________ > >mif mailing list > >mif@ietf.org > >https://www.ietf.org/mailman/listinfo/mif > _______________________________________________ > mif mailing list > mif@ietf.org > https://www.ietf.org/mailman/listinfo/mif From brian.e.carpenter@gmail.com Tue Nov 15 00:40:25 2011 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 2FAB021F8F90 for ; Tue, 15 Nov 2011 00:40:25 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.57 X-Spam-Level: X-Spam-Status: No, score=-103.57 tagged_above=-999 required=5 tests=[AWL=0.029, 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 xff8W8nxKP6s for ; Tue, 15 Nov 2011 00:40:24 -0800 (PST) Received: from mail-yw0-f44.google.com (mail-yw0-f44.google.com [209.85.213.44]) by ietfa.amsl.com (Postfix) with ESMTP id 9AB2121F8F80 for ; Tue, 15 Nov 2011 00:40:24 -0800 (PST) Received: by ywt34 with SMTP id 34so5954228ywt.31 for ; Tue, 15 Nov 2011 00:40:24 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=message-id:date:from:organization:user-agent:mime-version:to :subject:content-type:content-transfer-encoding; bh=Cb06AqclB55zafJNpdgrS9c7mOVPlPzIUOpuq48ySdA=; b=YB5nzdffci2oMvw/lbLtdxsl8DrE5OooTMC1yg2Lh2M9v9EZ9jcVss192SdazGT0wr 4SJXFDVoqwf47XyhWpFL5uOXKnBu1BRTS45rPtfe9eDhWGoc+gM9aKCEePXLZcV7YO87 seNA4SXc/q8gE9Qjj3YTAw/SVW5FTAlfsInYs= Received: by 10.101.8.2 with SMTP id l2mr7730477ani.79.1321346424235; Tue, 15 Nov 2011 00:40:24 -0800 (PST) Received: from [130.129.19.92] (dhcp-135c.meeting.ietf.org. [130.129.19.92]) by mx.google.com with ESMTPS id 4sm71128540ano.9.2011.11.15.00.40.22 (version=SSLv3 cipher=OTHER); Tue, 15 Nov 2011 00:40:23 -0800 (PST) Message-ID: <4EC22572.8010209@gmail.com> Date: Tue, 15 Nov 2011 21:40:18 +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 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Subject: [mif] Charging pulses 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, 15 Nov 2011 08:40:25 -0000 Re the discussion on draft-chen-mif-happy-eyeballs-extension-03: Some may remember that the old fashioned telephone system used to generate charging pulses, a little beep each time it charged you a certain amount of money. Seems like we need that to make the happy-eyeballs-extension work; this would make it possible for the heuristic to actually work. Without it, I don't see how it can work. All we need is for all operators that charge by time and volume to send the charging pulses; flat rate operators don't need to bother. Easy enough to define an ICMP option for this. -- Regards Brian Carpenter From ichiroumakino@gmail.com Tue Nov 15 05:42:27 2011 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 F3C9411E813F; Tue, 15 Nov 2011 05:42:26 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.539 X-Spam-Level: X-Spam-Status: No, score=-3.539 tagged_above=-999 required=5 tests=[AWL=0.060, 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 EQ2JnED4l4+j; Tue, 15 Nov 2011 05:42:26 -0800 (PST) Received: from mail-pz0-f50.google.com (mail-pz0-f50.google.com [209.85.210.50]) by ietfa.amsl.com (Postfix) with ESMTP id 72D4811E811F; Tue, 15 Nov 2011 05:42:26 -0800 (PST) Received: by pzk5 with SMTP id 5so12761560pzk.9 for ; Tue, 15 Nov 2011 05:42:25 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=sender:subject:mime-version:content-type:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to:x-mailer; bh=SZK/RAbhp7ycL8jNYeBDdiYvPJ72AKTj399JKaJgIxM=; b=u7HLx/2PaVEWiukaiGjQ81Aib2W5zhnSaGaOS07PZq7yQtdpmxqXLJEEwhJ0lD1OKh mqALpDnPpmwLnXsT2tdPGKPhnmzelvAVCnbFn7V79vZsXwwBPR50ydHcWGOZ2RaWuWRA 0SqBZpUw5IJAWZHFLS9242/n76zpzVK00GwH8= Received: by 10.68.2.72 with SMTP id 8mr6871530pbs.11.1321364545778; Tue, 15 Nov 2011 05:42:25 -0800 (PST) Received: from sjc-vpn4-486.cisco.com (128-107-239-233.cisco.com. [128.107.239.233]) by mx.google.com with ESMTPS id wf19sm65091211pbb.17.2011.11.15.05.42.20 (version=TLSv1/SSLv3 cipher=OTHER); Tue, 15 Nov 2011 05:42:24 -0800 (PST) Sender: Ole Troan Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Ole Troan In-Reply-To: <87379F9F-CB45-4FC1-B411-26D5BBC2DC89@nominum.com> Date: Tue, 15 Nov 2011 21:42:13 +0800 Content-Transfer-Encoding: quoted-printable Message-Id: <452CD809-3935-4852-B0AF-F8B042742BE7@employees.org> References: , <402398CF-7F7C-4B8B-91CE-6EDE54B6C4CC@employees.org> <23BACC91-621A-4E96-ACD6-92D226F9657A@nominum.com>, <4EC0E891.1060505@gmail.com> <87379F9F-CB45-4FC1-B411-26D5BBC2DC89@nominum.com> To: Ted Lemon X-Mailer: Apple Mail (2.1084) Cc: "dhcwg@ietf.org" , mif Subject: Re: [mif] [dhcwg] Conflict between RA and DHCP in MIF case 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, 15 Nov 2011 13:42:27 -0000 >> One ingredient helping the merge is to represent data in the same >> manner. It would hardly merge two default route entries with a >> lifetime on 32bit and another on 16bit. >=20 > Again? Oy.=20 >=20 > The problem of merging has to do with orthogonal (and possibly = untrustworthy) administrative domains, not trivial differences in data = representation. If /only/ the problem were that simple! how is a network (that I don't trust) going to tell me that I should = trust it's information? making DHCP preferred over RA seems irrelevant here. cheers, Ole From Ted.Lemon@nominum.com Tue Nov 15 13:17:39 2011 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 387021F0C42; Tue, 15 Nov 2011 13:17:39 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.561 X-Spam-Level: X-Spam-Status: No, score=-106.561 tagged_above=-999 required=5 tests=[AWL=0.038, 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 A1i5gUiAskNx; Tue, 15 Nov 2011 13:17:38 -0800 (PST) Received: from exprod7og118.obsmtp.com (exprod7og118.obsmtp.com [64.18.2.8]) by ietfa.amsl.com (Postfix) with ESMTP id E00591F0C4E; Tue, 15 Nov 2011 13:17:37 -0800 (PST) Received: from shell-too.nominum.com ([64.89.228.229]) (using TLSv1) by exprod7ob118.postini.com ([64.18.6.12]) with SMTP ID DSNKTsLW6ktkmdwJC+BR5dY4WBYGebm+54y6@postini.com; Tue, 15 Nov 2011 13:17:38 PST 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 658E11B82A1; Tue, 15 Nov 2011 13:17:30 -0800 (PST) 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 34DD8190052; Tue, 15 Nov 2011 13:17:29 -0800 (PST) (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.01.0339.001; Tue, 15 Nov 2011 13:17:29 -0800 From: Ted Lemon To: Ole Troan Thread-Topic: [dhcwg] Conflict between RA and DHCP in MIF case Thread-Index: AQHMom9Jeyu5uv/47kCfd4auwPXOIJWsI2EA//+A3MeAAQeogP//fuT6gAJPN4D///kXvA== Date: Tue, 15 Nov 2011 21:17:29 +0000 Message-ID: <8844B648-51D8-43F3-92C2-8403FD032058@nominum.com> References: , <402398CF-7F7C-4B8B-91CE-6EDE54B6C4CC@employees.org> <23BACC91-621A-4E96-ACD6-92D226F9657A@nominum.com>, <4EC0E891.1060505@gmail.com> <87379F9F-CB45-4FC1-B411-26D5BBC2DC89@nominum.com>, <452CD809-3935-4852-B0AF-F8B042742BE7@employees.org> In-Reply-To: <452CD809-3935-4852-B0AF-F8B042742BE7@employees.org> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "dhcwg@ietf.org" , mif Subject: Re: [mif] [dhcwg] Conflict between RA and DHCP in MIF case 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, 15 Nov 2011 21:17:39 -0000 On Nov 15, 2011, at 9:42 PM, "Ole Troan" wrote: > how is a network (that I don't trust) going to tell me that I should trus= t it's information? > making DHCP preferred over RA seems irrelevant here. Well, things have moved on from this discussion, and now we are thinking th= at preferring DHCP actually breaks some things that people care about, so w= e're moving back in the direction of preferring RA. In answer to your que= stion, of course there's no way, in the abstract, to know what you can and = can't trust.= From roberta.maglione@telecomitalia.it Tue Nov 15 17:02:20 2011 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 4BB7E11E80E4 for ; Tue, 15 Nov 2011 17:02:20 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.536 X-Spam-Level: X-Spam-Status: No, score=0.536 tagged_above=-999 required=5 tests=[AWL=-0.834, BAYES_05=-1.11, HELO_EQ_IT=0.635, HOST_EQ_IT=1.245, J_CHICKENPOX_13=0.6] 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 5RhicCqsRcHD for ; Tue, 15 Nov 2011 17:02:19 -0800 (PST) Received: from GRFEDG702BA020.telecomitalia.it (grfedg702ba020.telecomitalia.it [156.54.233.201]) by ietfa.amsl.com (Postfix) with ESMTP id 7DF1D11E80B2 for ; Tue, 15 Nov 2011 17:02:19 -0800 (PST) Received: from GRFHUB703BA020.griffon.local (10.188.101.113) by GRFEDG702BA020.telecomitalia.it (10.188.45.101) with Microsoft SMTP Server (TLS) id 8.2.254.0; Wed, 16 Nov 2011 02:02:14 +0100 Received: from GRFMBX704BA020.griffon.local ([10.188.101.16]) by GRFHUB703BA020.griffon.local ([10.188.101.113]) with mapi; Wed, 16 Nov 2011 02:02:14 +0100 From: Maglione Roberta To: mif Date: Wed, 16 Nov 2011 01:59:42 +0100 Thread-Topic: Motivations for draft-ietf-mif-dhcpv6-route-option Thread-Index: AQHMo/tgviDlqlbdN0SXs3FChFIsqw== Message-ID: <282BBE8A501E1F4DA9C775F964BB21FE3EB78C3C98@GRFMBX704BA020.griffon.local> Accept-Language: en-US, it-IT Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US, it-IT Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: [mif] Motivations for draft-ietf-mif-dhcpv6-route-option 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, 16 Nov 2011 01:02:20 -0000 Hello, during the meeting the chairs and many people asked about use cases and= motivations for this work: as I quickly mentioned at the mic there is a draft in v6ops (draft-ietf-v6o= ps-ipv6-multihoming-without-ipv6nat) that clearly explains the use cases an= d the requirements, coming from a Service Provider, for this work. In Broadband network environment where the CPE is multi-homed to two upstre= am edge routers and each router provides connectivity for different types o= f services for example internet access and Video on Demand (restricted insi= de a walled garden,) and the Service Provide would like to avoid routing on= the CPE, there is a need to provision static route entries on RGs/CPEs. As a Service Provider we believe DHCPv6 is the right tool to that because = we need a centralized control/management point for storing the customer=92s= related info (ipv6 prefix, ipv6 routes, =85) and DHCPv6 is a good place f= or that. Using RA=92s would require to manually provision the edge router a= nd this operation is not always possible, for example when router is operat= ed by 3rd party. Regarding the issues raised about the potential need for VRRP on the CPE to= protect against failure, in my opinion in the scenario described above VRR= P is not needed because if the connection to the edge router providing inte= rnet service is down I don=92t want the user traffic using the other link b= ecause the other edge router only provides limited connectivity to a restr= icted walled garden. As far as DHCPv6 failure, as many of you know there is= ongoing work on dhc WG in order to provide DHCPv6 redundancy. I really would like to see this work progressing because it is needed as ma= ny Service Providers said not only draft-ietf-v6ops-ipv6-multihoming-withou= t-ipv6nat, but also in Broadband Forum documents, if you take a look at WT-= 124i3 you can find requirements calling exactly for this draft to solve the= problem described above, this means a community of Service Providers=92 re= cognized the need for this work. Thanks Regards, Roberta Questo messaggio e i suoi allegati sono indirizzati esclusivamente alle per= sone indicate. La diffusione, copia o qualsiasi altra azione derivante dall= a conoscenza di queste informazioni sono rigorosamente vietate. Qualora abb= iate ricevuto questo documento per errore siete cortesemente pregati di dar= ne immediata comunicazione al mittente e di provvedere alla sua distruzione= , Grazie. This e-mail and any attachments is confidential and may contain privileged = information intended for the addressee(s) only. Dissemination, copying, pri= nting or use by anybody else is unauthorised. If you are not the intended r= ecipient, please delete this message and any attachments and advise the sen= der by return e-mail, Thanks. From Dmitry.Anipko@microsoft.com Wed Nov 16 01:34:28 2011 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 A7F6721F94B3; Wed, 16 Nov 2011 01:34:28 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, 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 v2qMQb3Bt8-5; Wed, 16 Nov 2011 01:34:28 -0800 (PST) Received: from smtp.microsoft.com (smtp.microsoft.com [131.107.115.215]) by ietfa.amsl.com (Postfix) with ESMTP id 2E90421F947E; Wed, 16 Nov 2011 01:34:28 -0800 (PST) Received: from TK5EX14HUBC101.redmond.corp.microsoft.com (157.54.7.153) by TK5-EXGWY-E802.partners.extranet.microsoft.com (10.251.56.168) with Microsoft SMTP Server (TLS) id 8.2.176.0; Wed, 16 Nov 2011 01:34:27 -0800 Received: from TK5EX14MBXC264.redmond.corp.microsoft.com ([169.254.1.220]) by TK5EX14HUBC101.redmond.corp.microsoft.com ([157.54.7.153]) with mapi id 14.01.0355.003; Wed, 16 Nov 2011 01:34:27 -0800 From: Dmitry Anipko To: Ted Lemon , Ole Troan Thread-Topic: [dhcwg] Conflict between RA and DHCP in MIF case Thread-Index: AQHMom9K7XpxT/ARnkOuxygcgg3TeZWsI2EAgAAG+ICAAIGMgIAABQGAgAHJGoCAAH8zgIAARtGg Date: Wed, 16 Nov 2011 09:34:27 +0000 Message-ID: <03FE6A726D13284495EF1787D25F1DF9018EDD41@TK5EX14MBXC264.redmond.corp.microsoft.com> References: , <402398CF-7F7C-4B8B-91CE-6EDE54B6C4CC@employees.org> <23BACC91-621A-4E96-ACD6-92D226F9657A@nominum.com>, <4EC0E891.1060505@gmail.com> <87379F9F-CB45-4FC1-B411-26D5BBC2DC89@nominum.com>, <452CD809-3935-4852-B0AF-F8B042742BE7@employees.org> <8844B648-51D8-43F3-92C2-8403FD032058@nominum.com> In-Reply-To: <8844B648-51D8-43F3-92C2-8403FD032058@nominum.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [157.54.51.22] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Mailman-Approved-At: Wed, 16 Nov 2011 01:40:17 -0800 Cc: "dhcwg@ietf.org" , mif Subject: Re: [mif] [dhcwg] Conflict between RA and DHCP in MIF case 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, 16 Nov 2011 09:34:28 -0000 >> so we're moving back in the direction of preferring RA My understanding is that part of the feedback from the room was also to mov= e from "pick one" to "merge with tie breakers" approach, that would be no d= ifferent from other cases where e.g. multiple RAs with settings of the same= kind have been received and those settings are merged (specific prefixes, = DNS settings etc). -----Original Message----- From: dhcwg-bounces@ietf.org [mailto:dhcwg-bounces@ietf.org] On Behalf Of T= ed Lemon Sent: Tuesday, November 15, 2011 1:17 PM To: Ole Troan Cc: dhcwg@ietf.org; Alexandru Petrescu; mif Subject: Re: [dhcwg] Conflict between RA and DHCP in MIF case On Nov 15, 2011, at 9:42 PM, "Ole Troan" wrote: > how is a network (that I don't trust) going to tell me that I should trus= t it's information? > making DHCP preferred over RA seems irrelevant here. Well, things have moved on from this discussion, and now we are thinking th= at preferring DHCP actually breaks some things that people care about, so w= e're moving back in the direction of preferring RA. In answer to your que= stion, of course there's no way, in the abstract, to know what you can and = can't trust. _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www.ietf.org/mailman/listinfo/dhcwg From brian.e.carpenter@gmail.com Wed Nov 16 02:04:28 2011 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 432A221F95D8; Wed, 16 Nov 2011 02:04:28 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.539 X-Spam-Level: X-Spam-Status: No, score=-103.539 tagged_above=-999 required=5 tests=[AWL=0.060, 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 izrW77luEZ0f; Wed, 16 Nov 2011 02:04:27 -0800 (PST) Received: from mail-yw0-f44.google.com (mail-yw0-f44.google.com [209.85.213.44]) by ietfa.amsl.com (Postfix) with ESMTP id 4707F21F95E2; Wed, 16 Nov 2011 02:04:27 -0800 (PST) Received: by ywt34 with SMTP id 34so7646713ywt.31 for ; Wed, 16 Nov 2011 02:04:26 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=message-id:date:from:organization:user-agent:mime-version:to:cc :subject:references:in-reply-to:content-type :content-transfer-encoding; bh=DHpFFub65OKbiv7ZBryZQMnUs4hr2+lzp799UIkqRYI=; b=uCpdzLO7a8BkltqysRjhSfjVA+USgEpNj7mP+aY7IRMwZYe+GHPVUuCYooeVaEPOZ2 C3pl7BW4+2E8ZZ4IZ/XhAPu9l5surus0LPcIHHaJ32sIfkM3qBkeG3pVoFTcnhUMSIFL KKfv+NrBGqdmfo+tKoc+/WYP6C3Oms9/kLXjk= Received: by 10.236.191.198 with SMTP id g46mr25645yhn.118.1321437866485; Wed, 16 Nov 2011 02:04:26 -0800 (PST) Received: from [130.129.19.92] (dhcp-135c.meeting.ietf.org. [130.129.19.92]) by mx.google.com with ESMTPS id f32sm84594093ani.20.2011.11.16.02.04.23 (version=SSLv3 cipher=OTHER); Wed, 16 Nov 2011 02:04:25 -0800 (PST) Message-ID: <4EC38AA1.3070104@gmail.com> Date: Wed, 16 Nov 2011 23:04:17 +1300 From: Brian E Carpenter Organization: University of Auckland User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: Dmitry Anipko References: , <402398CF-7F7C-4B8B-91CE-6EDE54B6C4CC@employees.org> <23BACC91-621A-4E96-ACD6-92D226F9657A@nominum.com>, <4EC0E891.1060505@gmail.com> <87379F9F-CB45-4FC1-B411-26D5BBC2DC89@nominum.com>, <452CD809-3935-4852-B0AF-F8B042742BE7@employees.org> <8844B648-51D8-43F3-92C2-8403FD032058@nominum.com> <03FE6A726D13284495EF1787D25F1DF9018EDD41@TK5EX14MBXC264.redmond.corp.microsoft.com> In-Reply-To: <03FE6A726D13284495EF1787D25F1DF9018EDD41@TK5EX14MBXC264.redmond.corp.microsoft.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: "dhcwg@ietf.org" , Ole Troan , mif Subject: Re: [mif] [dhcwg] Conflict between RA and DHCP in MIF case 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, 16 Nov 2011 10:04:28 -0000 The main message I got was that there needs to be great care to ensure that the semantics of information received via RA should be the same (modulo superset/subset) as information received via DHCPv6. That way, merging them becomes feasible. Brian On 2011-11-16 22:34, Dmitry Anipko wrote: >>> so we're moving back in the direction of preferring RA > > My understanding is that part of the feedback from the room was also to move from "pick one" to "merge with tie breakers" approach, that would be no different from other cases where e.g. multiple RAs with settings of the same kind have been received and those settings are merged (specific prefixes, DNS settings etc). > > -----Original Message----- > From: dhcwg-bounces@ietf.org [mailto:dhcwg-bounces@ietf.org] On Behalf Of Ted Lemon > Sent: Tuesday, November 15, 2011 1:17 PM > To: Ole Troan > Cc: dhcwg@ietf.org; Alexandru Petrescu; mif > Subject: Re: [dhcwg] Conflict between RA and DHCP in MIF case > > On Nov 15, 2011, at 9:42 PM, "Ole Troan" wrote: >> how is a network (that I don't trust) going to tell me that I should trust it's information? >> making DHCP preferred over RA seems irrelevant here. > > Well, things have moved on from this discussion, and now we are thinking that preferring DHCP actually breaks some things that people care about, so we're moving back in the direction of preferring RA. In answer to your question, of course there's no way, in the abstract, to know what you can and can't trust. > _______________________________________________ > dhcwg mailing list > dhcwg@ietf.org > https://www.ietf.org/mailman/listinfo/dhcwg > > _______________________________________________ > mif mailing list > mif@ietf.org > https://www.ietf.org/mailman/listinfo/mif > From ogud@ogud.com Wed Nov 16 18:17:41 2011 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 32C481F0C96 for ; Wed, 16 Nov 2011 18:17:41 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.576 X-Spam-Level: X-Spam-Status: No, score=-106.576 tagged_above=-999 required=5 tests=[AWL=0.023, 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 gQ74uR05ECmf for ; Wed, 16 Nov 2011 18:17:40 -0800 (PST) Received: from stora.ogud.com (stora.ogud.com [66.92.146.20]) by ietfa.amsl.com (Postfix) with ESMTP id 2438B1F0C94 for ; Wed, 16 Nov 2011 18:17:40 -0800 (PST) Received: from [IPv6:::1] (nyttbox.md.ogud.com [10.20.30.4]) by stora.ogud.com (8.14.4/8.14.4) with ESMTP id pAH2Hc4p060333 for ; Wed, 16 Nov 2011 21:17:38 -0500 (EST) (envelope-from ogud@ogud.com) Message-ID: <4EC46D52.8030909@ogud.com> Date: Thu, 17 Nov 2011 10:11:30 +0800 From: Olafur Gudmundsson User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:8.0) Gecko/20111105 Thunderbird/8.0 MIME-Version: 1.0 To: mif@ietf.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Scanned-By: MIMEDefang 2.72 on 10.20.30.4 Subject: [mif] Server selection document is "band-aid" not solution 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, 17 Nov 2011 02:17:41 -0000 I sorry for the late comment but it has taken me a while to be able to put my finger on what I feel is wrong with the document (and the discussion in the working group) If a node has multiple interfaces and the interfaces have different resolution contexts then the basic question is "How can the services on the node tell what resolution context an application wants to use ?" Right now the "server-selection" document The fundamental problem we have is that OS's have a built in assumptions that a) there is only one resolution context i.e. only single /etc/resolv.conf b) There is no way to label a process that it wants to be a part of certain resolution context or tell the resolution which context to use. c) Results of resolution do not indicate which context was used. From brian.e.carpenter@gmail.com Wed Nov 16 18:41:09 2011 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 D46701F0C54 for ; Wed, 16 Nov 2011 18:41:09 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.546 X-Spam-Level: X-Spam-Status: No, score=-103.546 tagged_above=-999 required=5 tests=[AWL=0.053, 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 5AQCe6thAIjQ for ; Wed, 16 Nov 2011 18:41:09 -0800 (PST) Received: from mail-gx0-f172.google.com (mail-gx0-f172.google.com [209.85.161.172]) by ietfa.amsl.com (Postfix) with ESMTP id 46F9F1F0C53 for ; Wed, 16 Nov 2011 18:41:09 -0800 (PST) Received: by ggnr5 with SMTP id r5so536190ggn.31 for ; Wed, 16 Nov 2011 18:41:08 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=message-id:date:from:organization:user-agent:mime-version:to:cc :subject:references:in-reply-to:content-type :content-transfer-encoding; bh=9XsAryoRv/UJkI2NmFrI65wAQ1dPPH8ONlrVum0+VB4=; b=ZwwFgtrRclrPYh8CjlcQbuOiNLRou7FCoDSpYzmHgbGOvoBm9N4LYBH7xFyxZI/LfF 570QEmXe/LcSCSitblmLXQkTaInIZhy/h/rABEE3c0koasV4ygx4JyBW35fvza/J8JS9 8b1+Y3cf/WMTnOa/lZZCiahW6g+a7cEnmdCdo= Received: by 10.236.77.232 with SMTP id d68mr5985340yhe.98.1321497668845; Wed, 16 Nov 2011 18:41:08 -0800 (PST) Received: from [130.129.19.92] (dhcp-135c.meeting.ietf.org. [130.129.19.92]) by mx.google.com with ESMTPS id d5sm3704544yhl.19.2011.11.16.18.41.06 (version=SSLv3 cipher=OTHER); Wed, 16 Nov 2011 18:41:08 -0800 (PST) Message-ID: <4EC4743C.30901@gmail.com> Date: Thu, 17 Nov 2011 15:41:00 +1300 From: Brian E Carpenter Organization: University of Auckland User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: Olafur Gudmundsson References: <4EC46D52.8030909@ogud.com> In-Reply-To: <4EC46D52.8030909@ogud.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: mif@ietf.org Subject: Re: [mif] Server selection document is "band-aid" not solution 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, 17 Nov 2011 02:41:09 -0000 On 2011-11-17 15:11, Olafur Gudmundsson wrote: > > I sorry for the late comment but it has taken me a while to be able to > put my finger on what I feel is wrong with the document (and the > discussion in the working group) > > If a node has multiple interfaces and the interfaces have different > resolution contexts then the basic question is > "How can the services on the node tell what resolution context an > application wants to use ?" > > Right now the "server-selection" document > The fundamental problem we have is that OS's have a built in assumptions > that > a) there is only one resolution context i.e. only single /etc/resolv.conf > > b) There is no way to label a process that it wants to be a part of > certain resolution context or tell the resolution which context to use. > > c) Results of resolution do not indicate which context was used. > These are all symptoms of a much deeper problem that we have in the modern Internet: the notion of scope that we have, for both names and addresses, is broken, and inconsistent with the real world. I've been trying to get people interested in this for a while, e.g. http://tools.ietf.org/html/draft-carpenter-referral-ps There's actually more explicit discussion of scope in an even older draft, most of which is OBE: http://tools.ietf.org/html/draft-carpenter-grobj-reqts-00#section-2 However, I don't believe MIF can be expected to solve this problem, and therefore the server selection draft seems to be the best that MIF can do. Brian From teemu.savolainen@nokia.com Wed Nov 16 18:47:55 2011 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 6E88211E80C4 for ; Wed, 16 Nov 2011 18:47:55 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.501 X-Spam-Level: X-Spam-Status: No, score=-2.501 tagged_above=-999 required=5 tests=[AWL=0.098, 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 0ts3EX59ie3R for ; Wed, 16 Nov 2011 18:47:54 -0800 (PST) Received: from mgw-da02.nokia.com (smtp.nokia.com [147.243.128.26]) by ietfa.amsl.com (Postfix) with ESMTP id 9658E11E80BC for ; Wed, 16 Nov 2011 18:47:54 -0800 (PST) Received: from vaebh106.NOE.Nokia.com (vaebh106.europe.nokia.com [10.160.244.32]) by mgw-da02.nokia.com (Switch-3.4.4/Switch-3.4.4) with ESMTP id pAH2loHQ021520; Thu, 17 Nov 2011 04:47:53 +0200 Received: from smtp.mgd.nokia.com ([65.54.30.23]) by vaebh106.NOE.Nokia.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.4675); Thu, 17 Nov 2011 04:47:46 +0200 Received: from 008-AM1MMR1-002.mgdnok.nokia.com (65.54.30.57) by 008-AM1MMR1-007.mgdnok.nokia.com (65.54.30.23) with Microsoft SMTP Server (TLS) id 14.1.355.3; Thu, 17 Nov 2011 03:47:46 +0100 Received: from 008-AM1MPN1-053.mgdnok.nokia.com ([169.254.3.114]) by 008-AM1MMR1-002.mgdnok.nokia.com ([65.54.30.57]) with mapi id 14.01.0355.003; Thu, 17 Nov 2011 03:47:45 +0100 From: To: , Thread-Topic: [mif] Server selection document is "band-aid" not solution Thread-Index: AQHMpM8cTOsAnc2+q0G6xead7mSgZZWwWtgQ Date: Thu, 17 Nov 2011 02:47:45 +0000 Message-ID: <916CE6CF87173740BC8A2CE44309696204192558@008-AM1MPN1-053.mgdnok.nokia.com> References: <4EC46D52.8030909@ogud.com> In-Reply-To: <4EC46D52.8030909@ogud.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-tituslabs-classifications-30: TLPropertyRoot=Nokia;Confidentiality=Company Confidential;Project=None; x-titus-version: 3.3.8.1 x-headerinfofordlp: None x-tituslabs-classificationhash-30: VgNFIFU9Hx+/nZJb9Kg7IvaJJ98g1xw6ajjuiF5UmoaKq8umyOZD9ad1l9N9r5NECFByLs3Bt4g/wwz9DRSIrWcYYm/Bxz8jzPZSzkZKbcL6NxnhI1RPliqW0jzeRbuL1oJrP8kVNbdFK55Mc64BpIeQuLJZlzWof4BIfLou3+V+5CFJ8VS+22nuHJ+0vFjp3f8Ktn85v83tq/aZf2WmtrrMr6VJ/V6Qak1iUgJ84h1XIJW/kr0d9poZJ6ObP/udljFrDe65ZjHLpeBXDaJfXQ== x-originating-ip: [10.163.117.20] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginalArrivalTime: 17 Nov 2011 02:47:46.0890 (UTC) FILETIME=[49BA42A0:01CCA4D3] X-Nokia-AV: Clean Subject: Re: [mif] Server selection document is "band-aid" not solution 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, 17 Nov 2011 02:47:55 -0000 Hi, Thank you for your comment, but I don't really see what you are proposing. The current state document shows how some OSes provide means for applicatio= ns to specify "context" (e.g. by apps explicitly specifying what network in= terface they want to use, which impacts to all stack behavior: DNS, address= selection, routing). The system where *all* applications must specifically= tell to OS what network interface to use is considered not to be very nice= for most application developers.. The DNS server selection document indeed assumes applications do not provid= e preference on what "context" they want to use - because generally applica= tions just don't know that information, and we want to avoid bothering user= s with network selection UI dialogs. Perhaps the MIF API document could cover your concern? I.e. introduce an AP= I for applications to specify "context" in a manner that it affects also DN= S resolution procedure (or maybe it is there, I need to read it:) This expl= icit API could/would then override the DNS server selection information rec= eived from the network - for the application that knows better. Best regards, Teemu > -----Original Message----- > From: mif-bounces@ietf.org [mailto:mif-bounces@ietf.org] On Behalf Of ext > Olafur Gudmundsson > Sent: 17. marraskuuta 2011 10:12 > To: mif@ietf.org > Subject: [mif] Server selection document is "band-aid" not solution >=20 >=20 > I sorry for the late comment but it has taken me a while to be able to pu= t my > finger on what I feel is wrong with the document (and the discussion in t= he > working group) >=20 > If a node has multiple interfaces and the interfaces have different resol= ution > contexts then the basic question is "How can the services on the node tel= l > what resolution context an application wants to use ?" >=20 > Right now the "server-selection" document The fundamental problem we > have is that OS's have a built in assumptions that > a) there is only one resolution context i.e. only single /etc/resolv.conf >=20 > b) There is no way to label a process that it wants to be a part of certa= in > resolution context or tell the resolution which context to use. >=20 > c) Results of resolution do not indicate which context was used. >=20 > _______________________________________________ > mif mailing list > mif@ietf.org > https://www.ietf.org/mailman/listinfo/mif From brian.e.carpenter@gmail.com Wed Nov 16 19:05:13 2011 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 46B8511E80B4 for ; Wed, 16 Nov 2011 19:05:13 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.548 X-Spam-Level: X-Spam-Status: No, score=-103.548 tagged_above=-999 required=5 tests=[AWL=0.051, 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 JOw8WuGLWhSX for ; Wed, 16 Nov 2011 19:05:12 -0800 (PST) Received: from mail-yx0-f172.google.com (mail-yx0-f172.google.com [209.85.213.172]) by ietfa.amsl.com (Postfix) with ESMTP id A432B11E80DA for ; Wed, 16 Nov 2011 19:05:12 -0800 (PST) Received: by yenq4 with SMTP id q4so553730yen.31 for ; Wed, 16 Nov 2011 19:05:12 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=message-id:date:from:organization:user-agent:mime-version:to:cc :subject:references:in-reply-to:content-type :content-transfer-encoding; bh=MyfYNNczEjxNTj3GoqCLUar5SfVCcG3zaJNPb2y15xQ=; b=o+4s9nhIdFJc3YlU+bwzagBv3ofxH/13lYg+NGPusPIYoYGOhRcj4Ghf31gJLPR19v UOu/9lSjZbm2n4+mXwXkefvVDUdxup2pBR2B2OZDNlgDpWO2gjuwV+jFI4gpmR7i1/7U sV7CwFRv4yenBhnX8l3SYPOcG3fNClMMqBC+c= Received: by 10.101.4.7 with SMTP id g7mr11003298ani.32.1321499112316; Wed, 16 Nov 2011 19:05:12 -0800 (PST) Received: from [130.129.19.92] (dhcp-135c.meeting.ietf.org. [130.129.19.92]) by mx.google.com with ESMTPS id m33sm91981671ann.4.2011.11.16.19.05.10 (version=SSLv3 cipher=OTHER); Wed, 16 Nov 2011 19:05:11 -0800 (PST) Message-ID: <4EC479E0.6030704@gmail.com> Date: Thu, 17 Nov 2011 16:05:04 +1300 From: Brian E Carpenter Organization: University of Auckland User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: teemu.savolainen@nokia.com References: <4EC46D52.8030909@ogud.com> <916CE6CF87173740BC8A2CE44309696204192558@008-AM1MPN1-053.mgdnok.nokia.com> In-Reply-To: <916CE6CF87173740BC8A2CE44309696204192558@008-AM1MPN1-053.mgdnok.nokia.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: mif@ietf.org Subject: Re: [mif] Server selection document is "band-aid" not solution 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, 17 Nov 2011 03:05:13 -0000 Teemu, I don't see how we could define a helpful API until the generic problem of scope is solved (see my previous message). We have no general way for an application to know or describe the scope that applies to itself and the peer(s) it wants to talk to. Regards Brian On 2011-11-17 15:47, teemu.savolainen@nokia.com wrote: > Hi, > > Thank you for your comment, but I don't really see what you are proposing. > > The current state document shows how some OSes provide means for applications to specify "context" (e.g. by apps explicitly specifying what network interface they want to use, which impacts to all stack behavior: DNS, address selection, routing). The system where *all* applications must specifically tell to OS what network interface to use is considered not to be very nice for most application developers.. > > The DNS server selection document indeed assumes applications do not provide preference on what "context" they want to use - because generally applications just don't know that information, and we want to avoid bothering users with network selection UI dialogs. > > Perhaps the MIF API document could cover your concern? I.e. introduce an API for applications to specify "context" in a manner that it affects also DNS resolution procedure (or maybe it is there, I need to read it:) This explicit API could/would then override the DNS server selection information received from the network - for the application that knows better. > > Best regards, > > Teemu > >> -----Original Message----- >> From: mif-bounces@ietf.org [mailto:mif-bounces@ietf.org] On Behalf Of ext >> Olafur Gudmundsson >> Sent: 17. marraskuuta 2011 10:12 >> To: mif@ietf.org >> Subject: [mif] Server selection document is "band-aid" not solution >> >> >> I sorry for the late comment but it has taken me a while to be able to put my >> finger on what I feel is wrong with the document (and the discussion in the >> working group) >> >> If a node has multiple interfaces and the interfaces have different resolution >> contexts then the basic question is "How can the services on the node tell >> what resolution context an application wants to use ?" >> >> Right now the "server-selection" document The fundamental problem we >> have is that OS's have a built in assumptions that >> a) there is only one resolution context i.e. only single /etc/resolv.conf >> >> b) There is no way to label a process that it wants to be a part of certain >> resolution context or tell the resolution which context to use. >> >> c) Results of resolution do not indicate which context was used. >> >> _______________________________________________ >> mif mailing list >> mif@ietf.org >> https://www.ietf.org/mailman/listinfo/mif > _______________________________________________ > mif mailing list > mif@ietf.org > https://www.ietf.org/mailman/listinfo/mif > From teemu.savolainen@nokia.com Wed Nov 16 19:48:36 2011 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 5CABA11E80B3 for ; Wed, 16 Nov 2011 19:48:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.506 X-Spam-Level: X-Spam-Status: No, score=-2.506 tagged_above=-999 required=5 tests=[AWL=0.093, 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 TEL99a+tZqTe for ; Wed, 16 Nov 2011 19:48:35 -0800 (PST) Received: from mgw-da02.nokia.com (smtp.nokia.com [147.243.128.26]) by ietfa.amsl.com (Postfix) with ESMTP id 3E3BD11E80B0 for ; Wed, 16 Nov 2011 19:48:35 -0800 (PST) Received: from vaebh105.NOE.Nokia.com (vaebh105.europe.nokia.com [10.160.244.31]) by mgw-da02.nokia.com (Switch-3.4.4/Switch-3.4.4) with ESMTP id pAH3mOOF014429; Thu, 17 Nov 2011 05:48:32 +0200 Received: from smtp.mgd.nokia.com ([65.54.30.23]) by vaebh105.NOE.Nokia.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.4675); Thu, 17 Nov 2011 05:48:29 +0200 Received: from 008-AM1MMR1-001.mgdnok.nokia.com (65.54.30.56) by 008-AM1MMR1-007.mgdnok.nokia.com (65.54.30.23) with Microsoft SMTP Server (TLS) id 14.1.355.3; Thu, 17 Nov 2011 04:48:29 +0100 Received: from 008-AM1MPN1-053.mgdnok.nokia.com ([169.254.3.114]) by 008-AM1MMR1-001.mgdnok.nokia.com ([65.54.30.56]) with mapi id 14.01.0355.003; Thu, 17 Nov 2011 04:48:17 +0100 From: To: Thread-Topic: [mif] Server selection document is "band-aid" not solution Thread-Index: AQHMpM8cTOsAnc2+q0G6xead7mSgZZWwWtgQ///2LgCAABt78A== Date: Thu, 17 Nov 2011 03:48:16 +0000 Message-ID: <916CE6CF87173740BC8A2CE4430969620419278D@008-AM1MPN1-053.mgdnok.nokia.com> References: <4EC46D52.8030909@ogud.com> <916CE6CF87173740BC8A2CE44309696204192558@008-AM1MPN1-053.mgdnok.nokia.com> <4EC479E0.6030704@gmail.com> In-Reply-To: <4EC479E0.6030704@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=Company Confidential;Project=None; x-titus-version: 3.3.8.1 x-headerinfofordlp: None x-tituslabs-classificationhash-30: VgNFIFU9Hx+/nZJb9Kg7IvaJJ98g1xw6ajjuiF5UmoaKq8umyOZD9ad1l9N9r5NECFByLs3Bt4g/wwz9DRSIrWcYYm/Bxz8jzPZSzkZKbcL6NxnhI1RPliqW0jzeRbuL1oJrP8kVNbdFK55Mc64BpIeQuLJZlzWof4BIfLou3+V+5CFJ8VS+22nuHJ+0vFjp3f8Ktn85v83tq/aZf2WmtrrMr6VJ/V6Qak1iUgJ84h1XIJW/kr0d9poZJ6ObP/udljFrDe65ZjHLpeBXDaJfXQ== x-originating-ip: [10.163.117.20] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-OriginalArrivalTime: 17 Nov 2011 03:48:29.0922 (UTC) FILETIME=[C524D420:01CCA4DB] X-Nokia-AV: Clean Cc: mif@ietf.org Subject: Re: [mif] Server selection document is "band-aid" not solution 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, 17 Nov 2011 03:48:36 -0000 QnJpYW4sDQoNCkkgd2FzIHRoaW5raW5nIGFib3V0IGNsYXNzIG9mIGFwcGxpY2F0aW9ucyB0aGF0 IG1pZ2h0IGJlIGNvbmZpZ3VyZWQgKGJ5IHVzZXIgb3IgYnkgYWRtaW5pc3RyYXRvciBvciBlLmcu IGJ5IElTUCB1c2luZyBvdmVyLXRoZS1haXIgcHJvdmlzaW9uaW5nIHRlY2hub2xvZ2llcywgZXRj KSB0byB3b3JrIG9ubHkgd2l0aCBzcGVjaWZpYyBjb250ZXh0cy4gVGhlIEFQSSBjb3VsZCBtYWtl IGl0IGVhc2llciB0byBpbXBsZW1lbnQgdGhvc2UgYXBwcy4NCg0KQnV0IEkgYWdyZWUgd2l0aCB5 b3VyIGVtYWlsIGFib3V0IGJpZ2dlciBwcm9ibGVtIGFuZCBkaWZmaWN1bHRpZXMgb24gZmluZGlu ZyBnZW5lcmljIHNvbHV0aW9uIGZvciB0aGF0Lg0KDQpCZXN0IHJlZ2FyZHMsDQoNCiAgICAgICAg VGVlbXUNCg0KPiAtLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KPiBGcm9tOiBleHQgQnJpYW4g RSBDYXJwZW50ZXIgW21haWx0bzpicmlhbi5lLmNhcnBlbnRlckBnbWFpbC5jb21dDQo+IFNlbnQ6 IDE3LiBtYXJyYXNrdXV0YSAyMDExIDExOjA1DQo+IFRvOiBTYXZvbGFpbmVuIFRlZW11IChOb2tp YS1DVE8vVGFtcGVyZSkNCj4gQ2M6IG9ndWRAb2d1ZC5jb207IG1pZkBpZXRmLm9yZw0KPiBTdWJq ZWN0OiBSZTogW21pZl0gU2VydmVyIHNlbGVjdGlvbiBkb2N1bWVudCBpcyAiYmFuZC1haWQiIG5v dCBzb2x1dGlvbg0KPg0KPiBUZWVtdSwNCj4NCj4gSSBkb24ndCBzZWUgaG93IHdlIGNvdWxkIGRl ZmluZSBhIGhlbHBmdWwgQVBJIHVudGlsIHRoZSBnZW5lcmljIHByb2JsZW0gb2YNCj4gc2NvcGUg aXMgc29sdmVkIChzZWUgbXkgcHJldmlvdXMgbWVzc2FnZSkuIFdlIGhhdmUgbm8gZ2VuZXJhbCB3 YXkgZm9yIGFuDQo+IGFwcGxpY2F0aW9uIHRvIGtub3cgb3IgZGVzY3JpYmUgdGhlIHNjb3BlIHRo YXQgYXBwbGllcyB0byBpdHNlbGYgYW5kIHRoZQ0KPiBwZWVyKHMpIGl0IHdhbnRzIHRvIHRhbGsg dG8uDQo+DQo+IFJlZ2FyZHMNCj4gICAgQnJpYW4NCj4NCj4gT24gMjAxMS0xMS0xNyAxNTo0Nywg dGVlbXUuc2F2b2xhaW5lbkBub2tpYS5jb20gd3JvdGU6DQo+ID4gSGksDQo+ID4NCj4gPiBUaGFu ayB5b3UgZm9yIHlvdXIgY29tbWVudCwgYnV0IEkgZG9uJ3QgcmVhbGx5IHNlZSB3aGF0IHlvdSBh cmUgcHJvcG9zaW5nLg0KPiA+DQo+ID4gVGhlIGN1cnJlbnQgc3RhdGUgZG9jdW1lbnQgc2hvd3Mg aG93IHNvbWUgT1NlcyBwcm92aWRlIG1lYW5zIGZvcg0KPiBhcHBsaWNhdGlvbnMgdG8gc3BlY2lm eSAiY29udGV4dCIgKGUuZy4gYnkgYXBwcyBleHBsaWNpdGx5IHNwZWNpZnlpbmcgd2hhdA0KPiBu ZXR3b3JrIGludGVyZmFjZSB0aGV5IHdhbnQgdG8gdXNlLCB3aGljaCBpbXBhY3RzIHRvIGFsbCBz dGFjayBiZWhhdmlvcjogRE5TLA0KPiBhZGRyZXNzIHNlbGVjdGlvbiwgcm91dGluZykuIFRoZSBz eXN0ZW0gd2hlcmUgKmFsbCogYXBwbGljYXRpb25zIG11c3QNCj4gc3BlY2lmaWNhbGx5IHRlbGwg dG8gT1Mgd2hhdCBuZXR3b3JrIGludGVyZmFjZSB0byB1c2UgaXMgY29uc2lkZXJlZCBub3QgdG8g YmUNCj4gdmVyeSBuaWNlIGZvciBtb3N0IGFwcGxpY2F0aW9uIGRldmVsb3BlcnMuLg0KPiA+DQo+ ID4gVGhlIEROUyBzZXJ2ZXIgc2VsZWN0aW9uIGRvY3VtZW50IGluZGVlZCBhc3N1bWVzIGFwcGxp Y2F0aW9ucyBkbyBub3QNCj4gcHJvdmlkZSBwcmVmZXJlbmNlIG9uIHdoYXQgImNvbnRleHQiIHRo ZXkgd2FudCB0byB1c2UgLSBiZWNhdXNlIGdlbmVyYWxseQ0KPiBhcHBsaWNhdGlvbnMganVzdCBk b24ndCBrbm93IHRoYXQgaW5mb3JtYXRpb24sIGFuZCB3ZSB3YW50IHRvIGF2b2lkDQo+IGJvdGhl cmluZyB1c2VycyB3aXRoIG5ldHdvcmsgc2VsZWN0aW9uIFVJIGRpYWxvZ3MuDQo+ID4NCj4gPiBQ ZXJoYXBzIHRoZSBNSUYgQVBJIGRvY3VtZW50IGNvdWxkIGNvdmVyIHlvdXIgY29uY2Vybj8gSS5l LiBpbnRyb2R1Y2UgYW4NCj4gQVBJIGZvciBhcHBsaWNhdGlvbnMgdG8gc3BlY2lmeSAiY29udGV4 dCIgaW4gYSBtYW5uZXIgdGhhdCBpdCBhZmZlY3RzIGFsc28gRE5TDQo+IHJlc29sdXRpb24gcHJv Y2VkdXJlIChvciBtYXliZSBpdCBpcyB0aGVyZSwgSSBuZWVkIHRvIHJlYWQgaXQ6KSBUaGlzIGV4 cGxpY2l0IEFQSQ0KPiBjb3VsZC93b3VsZCB0aGVuIG92ZXJyaWRlIHRoZSBETlMgc2VydmVyIHNl bGVjdGlvbiBpbmZvcm1hdGlvbiByZWNlaXZlZA0KPiBmcm9tIHRoZSBuZXR3b3JrIC0gZm9yIHRo ZSBhcHBsaWNhdGlvbiB0aGF0IGtub3dzIGJldHRlci4NCj4gPg0KPiA+IEJlc3QgcmVnYXJkcywN Cj4gPg0KPiA+ICAgICBUZWVtdQ0KPiA+DQo+ID4+IC0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0t DQo+ID4+IEZyb206IG1pZi1ib3VuY2VzQGlldGYub3JnIFttYWlsdG86bWlmLWJvdW5jZXNAaWV0 Zi5vcmddIE9uIEJlaGFsZiBPZg0KPiA+PiBleHQgT2xhZnVyIEd1ZG11bmRzc29uDQo+ID4+IFNl bnQ6IDE3LiBtYXJyYXNrdXV0YSAyMDExIDEwOjEyDQo+ID4+IFRvOiBtaWZAaWV0Zi5vcmcNCj4g Pj4gU3ViamVjdDogW21pZl0gU2VydmVyIHNlbGVjdGlvbiBkb2N1bWVudCBpcyAiYmFuZC1haWQi IG5vdCBzb2x1dGlvbg0KPiA+Pg0KPiA+Pg0KPiA+PiBJIHNvcnJ5IGZvciB0aGUgbGF0ZSBjb21t ZW50IGJ1dCBpdCBoYXMgdGFrZW4gbWUgYSB3aGlsZSB0byBiZSBhYmxlDQo+ID4+IHRvIHB1dCBt eSBmaW5nZXIgb24gd2hhdCBJIGZlZWwgaXMgd3Jvbmcgd2l0aCB0aGUgZG9jdW1lbnQgKGFuZCB0 aGUNCj4gPj4gZGlzY3Vzc2lvbiBpbiB0aGUgd29ya2luZyBncm91cCkNCj4gPj4NCj4gPj4gSWYg YSBub2RlIGhhcyBtdWx0aXBsZSBpbnRlcmZhY2VzIGFuZCB0aGUgaW50ZXJmYWNlcyBoYXZlIGRp ZmZlcmVudA0KPiA+PiByZXNvbHV0aW9uIGNvbnRleHRzIHRoZW4gdGhlIGJhc2ljIHF1ZXN0aW9u IGlzICJIb3cgY2FuIHRoZSBzZXJ2aWNlcw0KPiA+PiBvbiB0aGUgbm9kZSB0ZWxsIHdoYXQgcmVz b2x1dGlvbiBjb250ZXh0IGFuIGFwcGxpY2F0aW9uIHdhbnRzIHRvIHVzZSA/Ig0KPiA+Pg0KPiA+ PiBSaWdodCBub3cgdGhlICJzZXJ2ZXItc2VsZWN0aW9uIiBkb2N1bWVudCBUaGUgZnVuZGFtZW50 YWwgcHJvYmxlbSB3ZQ0KPiA+PiBoYXZlIGlzIHRoYXQgT1MncyBoYXZlIGEgYnVpbHQgaW4gYXNz dW1wdGlvbnMgdGhhdA0KPiA+PiBhKSB0aGVyZSBpcyBvbmx5IG9uZSByZXNvbHV0aW9uIGNvbnRl eHQgaS5lLiBvbmx5IHNpbmdsZQ0KPiA+PiAvZXRjL3Jlc29sdi5jb25mDQo+ID4+DQo+ID4+IGIp IFRoZXJlIGlzIG5vIHdheSB0byBsYWJlbCBhIHByb2Nlc3MgdGhhdCBpdCB3YW50cyB0byBiZSBh IHBhcnQgb2YNCj4gPj4gY2VydGFpbiByZXNvbHV0aW9uIGNvbnRleHQgb3IgdGVsbCB0aGUgcmVz b2x1dGlvbiB3aGljaCBjb250ZXh0IHRvIHVzZS4NCj4gPj4NCj4gPj4gYykgUmVzdWx0cyBvZiBy ZXNvbHV0aW9uIGRvIG5vdCBpbmRpY2F0ZSB3aGljaCBjb250ZXh0IHdhcyB1c2VkLg0KPiA+Pg0K PiA+PiBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KPiA+ PiBtaWYgbWFpbGluZyBsaXN0DQo+ID4+IG1pZkBpZXRmLm9yZw0KPiA+PiBodHRwczovL3d3dy5p ZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL21pZg0KPiA+IF9fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fDQo+ID4gbWlmIG1haWxpbmcgbGlzdA0KPiA+IG1pZkBp ZXRmLm9yZw0KPiA+IGh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vbWlmDQo+ ID4NCg== From Ted.Lemon@nominum.com Wed Nov 16 20:52:39 2011 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 949F611E80C8 for ; Wed, 16 Nov 2011 20:52:39 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.563 X-Spam-Level: X-Spam-Status: No, score=-106.563 tagged_above=-999 required=5 tests=[AWL=0.036, 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 XgJFKa8fJFpI for ; Wed, 16 Nov 2011 20:52:39 -0800 (PST) Received: from exprod7og103.obsmtp.com (exprod7og103.obsmtp.com [64.18.2.159]) by ietfa.amsl.com (Postfix) with ESMTP id 5864911E80BA for ; Wed, 16 Nov 2011 20:52:38 -0800 (PST) Received: from shell-too.nominum.com ([64.89.228.229]) (using TLSv1) by exprod7ob103.postini.com ([64.18.6.12]) with SMTP ID DSNKTsSS/3T7eDlYiWxCGZ36qY7N0kvS+kfu@postini.com; Wed, 16 Nov 2011 20:52:38 PST 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 9D76C1B82E2 for ; Wed, 16 Nov 2011 20:52:14 -0800 (PST) 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 8E54E19005D; Wed, 16 Nov 2011 20:52:14 -0800 (PST) (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.01.0339.001; Wed, 16 Nov 2011 20:52:14 -0800 From: Ted Lemon To: Brian E Carpenter Thread-Topic: [mif] Server selection document is "band-aid" not solution Thread-Index: AQHMpM8ZeOJMqkjpCkunz3mHScTfw5Ww4SwA//+ejkA= Date: Thu, 17 Nov 2011 04:52:13 +0000 Message-ID: <1F8D5A49-8907-471B-AE61-C692FC63F151@nominum.com> References: <4EC46D52.8030909@ogud.com>,<4EC4743C.30901@gmail.com> In-Reply-To: <4EC4743C.30901@gmail.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "mif@ietf.org" Subject: Re: [mif] Server selection document is "band-aid" not solution 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, 17 Nov 2011 04:52:39 -0000 On Nov 17, 2011, at 10:41 AM, "Brian E Carpenter" wrote: > However, I don't believe MIF can be expected to solve this problem, > and therefore the server selection draft seems to be the best > that MIF can do. On the contrary, this is _exactly_ the problem MIF should be solving. And= I agree 100% that server selection is just a bandaid. Really it's not ev= en that: it's a hint that some DNS subdomains ought to be resolved by speci= fic DNS servers in a specific provisioning domain, but it doesn't even addr= ess the larger problem. From Ted.Lemon@nominum.com Wed Nov 16 20:54:26 2011 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 7918D11E80C7 for ; Wed, 16 Nov 2011 20:54:26 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.563 X-Spam-Level: X-Spam-Status: No, score=-106.563 tagged_above=-999 required=5 tests=[AWL=0.036, 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 65eDpBjxqk-L for ; Wed, 16 Nov 2011 20:54:21 -0800 (PST) Received: from exprod7og119.obsmtp.com (exprod7og119.obsmtp.com [64.18.2.16]) by ietfa.amsl.com (Postfix) with ESMTP id 605E011E80BA for ; Wed, 16 Nov 2011 20:54:21 -0800 (PST) Received: from shell-too.nominum.com ([64.89.228.229]) (using TLSv1) by exprod7ob119.postini.com ([64.18.6.12]) with SMTP ID DSNKTsSTfKBZFVLlfgKiDATIOknQHH4j5mV3@postini.com; Wed, 16 Nov 2011 20:54:21 PST 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 511261B82E2 for ; Wed, 16 Nov 2011 20:54:20 -0800 (PST) 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 4301A19005D; Wed, 16 Nov 2011 20:54:20 -0800 (PST) (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.01.0339.001; Wed, 16 Nov 2011 20:54:20 -0800 From: Ted Lemon To: Brian E Carpenter Thread-Topic: [mif] Server selection document is "band-aid" not solution Thread-Index: AQHMpM8ZeOJMqkjpCkunz3mHScTfw5Ww4w+AgAAE1gD//5hqNA== Date: Thu, 17 Nov 2011 04:54:18 +0000 Message-ID: <292CDFDE-32DE-43D9-83DD-86D3978F3EEF@nominum.com> References: <4EC46D52.8030909@ogud.com> <916CE6CF87173740BC8A2CE44309696204192558@008-AM1MPN1-053.mgdnok.nokia.com>, <4EC479E0.6030704@gmail.com> In-Reply-To: <4EC479E0.6030704@gmail.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "mif@ietf.org" Subject: Re: [mif] Server selection document is "band-aid" not solution 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, 17 Nov 2011 04:54:26 -0000 On Nov 17, 2011, at 11:05 AM, "Brian E Carpenter" wrote: > I don't see how we could define a helpful API until the generic problem > of scope is solved (see my previous message). We have no general way > for an application to know or describe the scope that applies to itself a= nd > the peer(s) it wants to talk to. It seems to me that applications "knowing" what scope they want to talk to = is a very isolated special case. E.g., perhaps your set-top box knows tha= t it needs to go through your cable ISP's provisioning domain to get stream= ing video. But generally speaking, your application wants to connect thro= ugh whatever provisioning domain works best, which is something no provisio= ning domain can claim to know; it is something only the host can determine. From moore@network-heretics.com Wed Nov 16 21:26:31 2011 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 9892211E8116 for ; Wed, 16 Nov 2011 21:26:31 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.296 X-Spam-Level: X-Spam-Status: No, score=-3.296 tagged_above=-999 required=5 tests=[AWL=0.303, 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 lhJ6tN3wNvKi for ; Wed, 16 Nov 2011 21:26:31 -0800 (PST) Received: from out2.smtp.messagingengine.com (out2.smtp.messagingengine.com [66.111.4.26]) by ietfa.amsl.com (Postfix) with ESMTP id 0634F11E810A for ; Wed, 16 Nov 2011 21:26:31 -0800 (PST) Received: from compute6.internal (compute6.nyi.mail.srv.osa [10.202.2.46]) by gateway1.nyi.mail.srv.osa (Postfix) with ESMTP id 01A1B20CFA for ; Thu, 17 Nov 2011 00:26:30 -0500 (EST) Received: from frontend2.nyi.mail.srv.osa ([10.202.2.161]) by compute6.internal (MEProxy); Thu, 17 Nov 2011 00:26:30 -0500 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d= messagingengine.com; h=subject:mime-version:content-type:from :in-reply-to:date:cc:content-transfer-encoding:message-id :references:to; s=smtpout; bh=RCUH7ARPbI7YyTZDhXb+WVdzz/4=; b=po Xj0JOkvrlXtA/MXTIN6bepbMUUd9aZMf2A9UjxrGjSTZy241RlJS7fqTExusQTsc fQ23GLsoDL8U8fExeqLAM918Bt6u+NDYMgfXxhKP4iozmd17JPHq1SQF2LoicFwP RDgKnmAymaNFB70rSvwWcjqy0K5PeIDXGWmsV1Dk4= X-Sasl-enc: ShbOlYMMcDCVBeZu9NxyIFyOsin8TvB5kwyn5Usg+H06 1321507589 Received: from [192.168.1.16] (host65-16-145-177.birch.net [65.16.145.177]) by mail.messagingengine.com (Postfix) with ESMTPA id 4FA34482490; Thu, 17 Nov 2011 00:26:29 -0500 (EST) Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Keith Moore In-Reply-To: <4EC46D52.8030909@ogud.com> Date: Thu, 17 Nov 2011 00:26:28 -0500 Content-Transfer-Encoding: quoted-printable Message-Id: References: <4EC46D52.8030909@ogud.com> To: Olafur Gudmundsson X-Mailer: Apple Mail (2.1084) Cc: mif@ietf.org Subject: Re: [mif] Server selection document is "band-aid" not solution 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, 17 Nov 2011 05:26:31 -0000 On Nov 16, 2011, at 9:11 PM, Olafur Gudmundsson wrote: >=20 > I sorry for the late comment but it has taken me a while to be able to = put my finger on what I feel is wrong with the document (and the = discussion in the working group) >=20 > If a node has multiple interfaces and the interfaces have different = resolution contexts then the basic question is > "How can the services on the node tell what resolution context an = application wants to use ?" >=20 > Right now the "server-selection" document > The fundamental problem we have is that OS's have a built in = assumptions that > a) there is only one resolution context i.e. only single = /etc/resolv.conf It's not just that. A fundamental design choice of DNS is that there is = only one resolution context. Yes, it's not unusual for that design = choice to be violated. But that still doesn't make it right for MIF to = violate it. Keith From Ted.Lemon@nominum.com Wed Nov 16 21:35:11 2011 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 731111F0C5B for ; Wed, 16 Nov 2011 21:35:11 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.564 X-Spam-Level: X-Spam-Status: No, score=-106.564 tagged_above=-999 required=5 tests=[AWL=0.035, 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 F8C32pajx5cE for ; Wed, 16 Nov 2011 21:35:04 -0800 (PST) Received: from exprod7og123.obsmtp.com (exprod7og123.obsmtp.com [64.18.2.24]) by ietfa.amsl.com (Postfix) with ESMTP id 5ECC61F0C42 for ; Wed, 16 Nov 2011 21:35:04 -0800 (PST) Received: from shell-too.nominum.com ([64.89.228.229]) (using TLSv1) by exprod7ob123.postini.com ([64.18.6.12]) with SMTP ID DSNKTsSdB/870KvnBJtGe6r8EDy88efMk62Z@postini.com; Wed, 16 Nov 2011 21:35:04 PST 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 F04D11B82E2 for ; Wed, 16 Nov 2011 21:35:02 -0800 (PST) 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 1117719005D; Wed, 16 Nov 2011 21:35:00 -0800 (PST) (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.01.0339.001; Wed, 16 Nov 2011 21:34:59 -0800 From: Ted Lemon To: Keith Moore Thread-Topic: [mif] Server selection document is "band-aid" not solution Thread-Index: AQHMpM8ZeOJMqkjpCkunz3mHScTfw5WxD2cA//98Rew= Date: Thu, 17 Nov 2011 05:34:58 +0000 Message-ID: <23E1BB1B-75C8-45E9-8CA3-2E3DC9B6DBC6@nominum.com> References: <4EC46D52.8030909@ogud.com>, In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "mif@ietf.org" Subject: Re: [mif] Server selection document is "band-aid" not solution 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, 17 Nov 2011 05:35:11 -0000 On Nov 17, 2011, at 1:26 PM, "Keith Moore" wro= te: > It's not just that. A fundamental design choice of DNS is that there is = only one resolution context. Yes, it's not unusual for that design choice = to be violated. But that still doesn't make it right for MIF to violate it= . Do you mean only one namespace? It is not at all a fundamental assumption = of the DNS that there is only one resolution context. That is an implemen= tation artifact that actually must be fixed if we are going to come up with= a good solution to the MIF problem statement. From moore@network-heretics.com Wed Nov 16 21:40:53 2011 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 6AB5C1F0C8B for ; Wed, 16 Nov 2011 21:40:53 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.305 X-Spam-Level: X-Spam-Status: No, score=-3.305 tagged_above=-999 required=5 tests=[AWL=0.294, 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 belsVpTz2OTB for ; Wed, 16 Nov 2011 21:40:52 -0800 (PST) Received: from out2.smtp.messagingengine.com (out2.smtp.messagingengine.com [66.111.4.26]) by ietfa.amsl.com (Postfix) with ESMTP id 583651F0C4F for ; Wed, 16 Nov 2011 21:40:52 -0800 (PST) Received: from compute6.internal (compute6.nyi.mail.srv.osa [10.202.2.46]) by gateway1.nyi.mail.srv.osa (Postfix) with ESMTP id C257220D9C for ; Thu, 17 Nov 2011 00:40:51 -0500 (EST) Received: from frontend2.nyi.mail.srv.osa ([10.202.2.161]) by compute6.internal (MEProxy); Thu, 17 Nov 2011 00:40:51 -0500 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d= messagingengine.com; h=subject:mime-version:content-type:from :in-reply-to:date:cc:content-transfer-encoding:message-id :references:to; s=smtpout; bh=lCwvE1B7pUqx9XyibA4IqUVGQmI=; b=b0 +shH/Mrvkza4bJ8yOE5ZLZuFNxyhboT2xFmgxutLIucHZxaJoNWCCF51pyFL/Lf1 P12cJVcsdotPl1fwMr8JMmxBJ7brlkMTui5yUGrG3R+q9uoGLDplvgYXpRU9P7hg a32fwHiA+9psxcHO5EWGKg5ckPWebLXOpAIylNX7Y= X-Sasl-enc: nR5cdtq2VcF9RGTsMo1HeI92MjHO5F9q7vHIa+gqLfZM 1321508451 Received: from [192.168.1.16] (host65-16-145-177.birch.net [65.16.145.177]) by mail.messagingengine.com (Postfix) with ESMTPA id 04AFD48251B; Thu, 17 Nov 2011 00:40:50 -0500 (EST) Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Keith Moore In-Reply-To: <23E1BB1B-75C8-45E9-8CA3-2E3DC9B6DBC6@nominum.com> Date: Thu, 17 Nov 2011 00:40:49 -0500 Content-Transfer-Encoding: quoted-printable Message-Id: <0B785F0F-F131-4C06-8B62-418B051EE79C@network-heretics.com> References: <4EC46D52.8030909@ogud.com>, <23E1BB1B-75C8-45E9-8CA3-2E3DC9B6DBC6@nominum.com> To: Ted Lemon X-Mailer: Apple Mail (2.1084) Cc: "mif@ietf.org" Subject: Re: [mif] Server selection document is "band-aid" not solution 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, 17 Nov 2011 05:40:53 -0000 On Nov 17, 2011, at 12:34 AM, Ted Lemon wrote: > On Nov 17, 2011, at 1:26 PM, "Keith Moore" = wrote: >> It's not just that. A fundamental design choice of DNS is that there = is only one resolution context. Yes, it's not unusual for that design = choice to be violated. But that still doesn't make it right for MIF to = violate it. >=20 > Do you mean only one namespace? It is not at all a fundamental = assumption of the DNS that there is only one resolution context. =20 Either I disagree, or we're talking about different things. But DNS = cacheing assumes that the correct set of answers to a particular DNS = query are the same independent of where the query came from. This isn't = an implementation artifact, it's how DNS was designed to work. =20 Keith From teemu.savolainen@nokia.com Wed Nov 16 22:02:47 2011 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 AC2C611E8106 for ; Wed, 16 Nov 2011 22:02:47 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.511 X-Spam-Level: X-Spam-Status: No, score=-2.511 tagged_above=-999 required=5 tests=[AWL=0.088, 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 5uh4kzsUgFWB for ; Wed, 16 Nov 2011 22:02:46 -0800 (PST) Received: from mgw-da02.nokia.com (smtp.nokia.com [147.243.128.26]) by ietfa.amsl.com (Postfix) with ESMTP id F314421F973E for ; Wed, 16 Nov 2011 22:02:45 -0800 (PST) Received: from vaebh102.NOE.Nokia.com (vaebh102.europe.nokia.com [10.160.244.23]) by mgw-da02.nokia.com (Switch-3.4.4/Switch-3.4.4) with ESMTP id pAH62bnM008756; Thu, 17 Nov 2011 08:02:44 +0200 Received: from smtp.mgd.nokia.com ([65.54.30.20]) by vaebh102.NOE.Nokia.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.4675); Thu, 17 Nov 2011 08:02:30 +0200 Received: from 008-AM1MPN1-053.mgdnok.nokia.com ([169.254.3.114]) by 008-AM1MMR1-011.mgdnok.nokia.com ([65.54.30.20]) with mapi id 14.01.0355.003; Thu, 17 Nov 2011 07:02:30 +0100 From: To: , Thread-Topic: [mif] Server selection document is "band-aid" not solution Thread-Index: AQHMpOt1TOsAnc2+q0G6xead7mSgZZWwks0Q Date: Thu, 17 Nov 2011 06:02:29 +0000 Message-ID: <916CE6CF87173740BC8A2CE44309696204192B5C@008-AM1MPN1-053.mgdnok.nokia.com> References: <4EC46D52.8030909@ogud.com>, <23E1BB1B-75C8-45E9-8CA3-2E3DC9B6DBC6@nominum.com> <0B785F0F-F131-4C06-8B62-418B051EE79C@network-heretics.com> In-Reply-To: <0B785F0F-F131-4C06-8B62-418B051EE79C@network-heretics.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-tituslabs-classifications-30: TLPropertyRoot=Nokia;Confidentiality=Company Confidential;Project=None; x-titus-version: 3.3.8.1 x-headerinfofordlp: None x-tituslabs-classificationhash-30: VgNFIFU9Hx+/nZJb9Kg7IvaJJ98g1xw6ajjuiF5UmoaKq8umyOZD9ad1l9N9r5NECFByLs3Bt4g/wwz9DRSIrWcYYm/Bxz8jzPZSzkZKbcL6NxnhI1RPliqW0jzeRbuL1oJrP8kVNbdFK55Mc64BpIeQuLJZlzWof4BIfLou3+V+5CFJ8VS+22nuHJ+0vFjp3f8Ktn85v83tq/aZf2WmtrrMr6VJ/V6Qak1iUgJ84h1XIJW/kr0d9poZJ6ObP/udljFrDe65ZjHLpeBXDaJfXQ== x-originating-ip: [10.163.117.20] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginalArrivalTime: 17 Nov 2011 06:02:30.0843 (UTC) FILETIME=[7DE800B0:01CCA4EE] X-Nokia-AV: Clean Cc: mif@ietf.org Subject: Re: [mif] Server selection document is "band-aid" not solution 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, 17 Nov 2011 06:02:47 -0000 Latest revision says: -- Private namespaces MUST be globally unique in order to keep DNS unambiguous and henceforth avoiding caching related issues and destination selection problems (see Section 2.3). Exceptions to this rule are domains utilized for local name resolution (such as .local). Private namespaces MUST only consist of subdomains of domains for which the relevant operator provides authoritative name service. Thus, subdomains of example.com are permitted in the private namespace served by an operator's DNS servers only if the same operator provides an SOA record for example.com. -- Doesn't that make DNS caches happy? Teemu > -----Original Message----- > From: mif-bounces@ietf.org [mailto:mif-bounces@ietf.org] On Behalf Of ext > Keith Moore > Sent: 17. marraskuuta 2011 13:41 > To: Ted Lemon > Cc: mif@ietf.org > Subject: Re: [mif] Server selection document is "band-aid" not solution > > > On Nov 17, 2011, at 12:34 AM, Ted Lemon wrote: > > > On Nov 17, 2011, at 1:26 PM, "Keith Moore" heretics.com> wrote: > >> It's not just that. A fundamental design choice of DNS is that there = is only > one resolution context. Yes, it's not unusual for that design choice to = be > violated. But that still doesn't make it right for MIF to violate it. > > > > Do you mean only one namespace? It is not at all a fundamental > assumption of the DNS that there is only one resolution context. > > Either I disagree, or we're talking about different things. But DNS cach= eing > assumes that the correct set of answers to a particular DNS query are the > same independent of where the query came from. This isn't an > implementation artifact, it's how DNS was designed to work. > > Keith > > _______________________________________________ > mif mailing list > mif@ietf.org > https://www.ietf.org/mailman/listinfo/mif From Ted.Lemon@nominum.com Wed Nov 16 22:19:55 2011 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 7210E11E8126 for ; Wed, 16 Nov 2011 22:19:55 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.565 X-Spam-Level: X-Spam-Status: No, score=-106.565 tagged_above=-999 required=5 tests=[AWL=0.034, 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 5l85QVdciGBu for ; Wed, 16 Nov 2011 22:19:55 -0800 (PST) Received: from exprod7og107.obsmtp.com (exprod7og107.obsmtp.com [64.18.2.167]) by ietfa.amsl.com (Postfix) with ESMTP id 973EC11E8125 for ; Wed, 16 Nov 2011 22:19:54 -0800 (PST) Received: from shell-too.nominum.com ([64.89.228.229]) (using TLSv1) by exprod7ob107.postini.com ([64.18.6.12]) with SMTP ID DSNKTsSniRI2IMJJ29etfzZjJTtDZJoBPUr4@postini.com; Wed, 16 Nov 2011 22:19:54 PST 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 1FD2E1B82E3 for ; Wed, 16 Nov 2011 22:19:53 -0800 (PST) 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 25DBD19005D; Wed, 16 Nov 2011 22:19:50 -0800 (PST) (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.01.0339.001; Wed, 16 Nov 2011 22:19:50 -0800 From: Ted Lemon To: Keith Moore Thread-Topic: [mif] Server selection document is "band-aid" not solution Thread-Index: AQHMpM8ZeOJMqkjpCkunz3mHScTfw5WxD2cA//98ReyAAIe9gP//hMrw Date: Thu, 17 Nov 2011 06:19:49 +0000 Message-ID: References: <4EC46D52.8030909@ogud.com>, <23E1BB1B-75C8-45E9-8CA3-2E3DC9B6DBC6@nominum.com>, <0B785F0F-F131-4C06-8B62-418B051EE79C@network-heretics.com> In-Reply-To: <0B785F0F-F131-4C06-8B62-418B051EE79C@network-heretics.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "mif@ietf.org" Subject: Re: [mif] Server selection document is "band-aid" not solution 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, 17 Nov 2011 06:19:55 -0000 On Nov 17, 2011, at 1:40 PM, "Keith Moore" wro= te: > Either I disagree, or we're talking about different things. But DNS cach= eing assumes that the correct set of answers to a particular DNS query are = the same independent of where the query came from. This isn't an implement= ation artifact, it's how DNS was designed to work. =20 Right, so that's the uniform namespace assumption. But if you have two ro= uters querying two different sets of servers, this is a non-issue. From ajs@crankycanuck.ca Wed Nov 16 22:01:35 2011 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 34C0021F973B for ; Wed, 16 Nov 2011 22:01:35 -0800 (PST) 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 unfpZ55quBov for ; Wed, 16 Nov 2011 22:01:34 -0800 (PST) Received: from mail.yitter.info (mail.yitter.info [208.86.224.201]) by ietfa.amsl.com (Postfix) with ESMTP id 5F1EA21F9738 for ; Wed, 16 Nov 2011 22:01:34 -0800 (PST) Received: from shinkuro.com (dhcp-464e.meeting.ietf.org [130.129.70.78]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.yitter.info (Postfix) with ESMTPSA id 57BD11ECB422 for ; Thu, 17 Nov 2011 06:01:19 +0000 (UTC) Date: Thu, 17 Nov 2011 01:01:28 -0500 From: Andrew Sullivan To: mif@ietf.org Message-ID: <20111117060127.GB34506@shinkuro.com> References: <4EC46D52.8030909@ogud.com> <916CE6CF87173740BC8A2CE44309696204192558@008-AM1MPN1-053.mgdnok.nokia.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <916CE6CF87173740BC8A2CE44309696204192558@008-AM1MPN1-053.mgdnok.nokia.com> User-Agent: Mutt/1.5.21 (2010-09-15) X-Mailman-Approved-At: Wed, 16 Nov 2011 22:26:03 -0800 Subject: Re: [mif] Server selection document is "band-aid" not solution 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, 17 Nov 2011 06:01:35 -0000 On Thu, Nov 17, 2011 at 02:47:45AM +0000, teemu.savolainen@nokia.com wrote: > The DNS server selection document indeed assumes applications do not > provide preference on what "context" they want to use - because > generally applications just don't know that information, and we want > to avoid bothering users with network selection UI dialogs. No, the reason applications don't have that interface is because we told them that the DNS is a unified name space. That's its design. (This is part of Olafur's point, if I read him correctly.) As a matter of fact, because of what people have done with the DNS, it is _not_ a unified name space, and you will indeed get different answers on different interfaces. Moreover, vendors (who perhaps ought to have known better) have attempted to fix that by adding curious different ways of not experiencing too much pain whenever this situation arises. The reason that we need the server selection document, therefore, is that we want people to do this hackery in a way that causes the least harm. We shouldn't mistake this attempt to do the least bad thing as itself good. You're quite right, however, that we don't want to bother users with a server selection UI for these cases, but I disagree that it's because it would be "bothering" them. I'd be happy to bother them if I thought there to be the remotest hope they could answer the question we'd have to ask. They just want to be able to go where they want to go, and if the idea of the right network context were the sort of thing that was coherent to most users, we probably wouldn't need to be doing these sorts of work-arounds for private DNS names in the first place. A -- Andrew Sullivan ajs@crankycanuck.ca From teemu.savolainen@nokia.com Thu Nov 17 03:14:56 2011 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 4A80921F9B6E for ; Thu, 17 Nov 2011 03:14:56 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.715 X-Spam-Level: X-Spam-Status: No, score=-2.715 tagged_above=-999 required=5 tests=[AWL=0.284, 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 9hij1RlYitUZ for ; Thu, 17 Nov 2011 03:14:55 -0800 (PST) Received: from mgw-da01.nokia.com (smtp.nokia.com [147.243.128.24]) by ietfa.amsl.com (Postfix) with ESMTP id 3CB1F21F9B78 for ; Thu, 17 Nov 2011 03:14:50 -0800 (PST) Received: from vaebh104.NOE.Nokia.com (vaebh104.europe.nokia.com [10.160.244.30]) by mgw-da01.nokia.com (Switch-3.4.4/Switch-3.4.4) with ESMTP id pAHBEjXp029404; Thu, 17 Nov 2011 13:14:48 +0200 Received: from smtp.mgd.nokia.com ([65.54.30.23]) by vaebh104.NOE.Nokia.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.4675); Thu, 17 Nov 2011 13:14:46 +0200 Received: from 008-AM1MPN1-053.mgdnok.nokia.com ([169.254.3.114]) by 008-AM1MMR1-007.mgdnok.nokia.com ([65.54.30.23]) with mapi id 14.01.0355.003; Thu, 17 Nov 2011 12:14:45 +0100 From: To: , Thread-Topic: Motivations for draft-ietf-mif-dhcpv6-route-option Thread-Index: AQHMo/tgviDlqlbdN0SXs3FChFIsq5Ww6oPQ Date: Thu, 17 Nov 2011 11:14:44 +0000 Message-ID: <916CE6CF87173740BC8A2CE44309696204193417@008-AM1MPN1-053.mgdnok.nokia.com> References: <282BBE8A501E1F4DA9C775F964BB21FE3EB78C3C98@GRFMBX704BA020.griffon.local> In-Reply-To: <282BBE8A501E1F4DA9C775F964BB21FE3EB78C3C98@GRFMBX704BA020.griffon.local> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-tituslabs-classifications-30: TLPropertyRoot=Nokia;Confidentiality=Company Confidential;Project=None; x-titus-version: 3.3.8.1 x-headerinfofordlp: None x-tituslabs-classificationhash-30: VgNFIFU9Hx+/nZJb9Kg7InnZ1iVA7RQq6/Csgsa1i7tpKIfClCqqBCCeZ/2AY55TV3U7jwreGxjFZQsrzs0eKVPkpBDX8uvApFdkq4dKEt6PIpf4VY7EPnq2G9/FILod9YxyuwCD8lQHC2HheIwYa2kuCdEKw1vHkm4wq55e5rUJ6YU/9L5Xg5sS5xwmrhhvHg0Y9/Yr/HCiOH391Srqjn26DxUzunEyqtzvql4OSH9lH+MN6t61mgVaZWmzV1MoeVx2FtX6B+QfUWVmf7waeA== x-originating-ip: [10.163.117.20] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginalArrivalTime: 17 Nov 2011 11:14:46.0161 (UTC) FILETIME=[1D06A810:01CCA51A] X-Nokia-AV: Clean Subject: Re: [mif] Motivations for draft-ietf-mif-dhcpv6-route-option 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, 17 Nov 2011 11:14:56 -0000 +1 I have to add I'm now quite confused why we are even having these motivatio= n discussions, as the charter was already agreed quite some time ago. We ar= e actually even late: -- Jun 2011 - Submit DHCPv6 routing configuration option to IESG for publica= tion as a Proposed Standard RFC -- We should focus on technical issues to complete the spec, like the semantic= s. Not to spend time repeating old discussions. Best regards,=20 Teemu > -----Original Message----- > From: mif-bounces@ietf.org [mailto:mif-bounces@ietf.org] On Behalf Of ext > Maglione Roberta > Sent: 16. marraskuuta 2011 09:00 > To: mif > Subject: [mif] Motivations for draft-ietf-mif-dhcpv6-route-option >=20 > Hello, > during the meeting the chairs and many people asked about use cases a= nd > motivations for this work: > as I quickly mentioned at the mic there is a draft in v6ops (draft-ietf-v= 6ops- > ipv6-multihoming-without-ipv6nat) that clearly explains the use cases and= the > requirements, coming from a Service Provider, for this work. > In Broadband network environment where the CPE is multi-homed to two > upstream edge routers and each router provides connectivity for different > types of services for example internet access and Video on Demand (restri= cted > inside a walled garden,) and the Service Provide would like to avoid rout= ing > on the CPE, there is a need to provision static route entries on RGs/CPEs= . >=20 > As a Service Provider we believe DHCPv6 is the right tool to that becaus= e we > need a centralized control/management point for storing the customer's > related info (ipv6 prefix, ipv6 routes, ...) and DHCPv6 is a good place = for that. > Using RA's would require to manually provision the edge router and this > operation is not always possible, for example when router is operated by = 3rd > party. >=20 > Regarding the issues raised about the potential need for VRRP on the CPE = to > protect against failure, in my opinion in the scenario described above VR= RP is > not needed because if the connection to the edge router providing interne= t > service is down I don't want the user traffic using the other link becaus= e the > other edge router only provides limited connectivity to a restricted wal= led > garden. As far as DHCPv6 failure, as many of you know there is ongoing wo= rk > on dhc WG in order to provide DHCPv6 redundancy. >=20 > I really would like to see this work progressing because it is needed as = many > Service Providers said not only draft-ietf-v6ops-ipv6-multihoming-without= - > ipv6nat, but also in Broadband Forum documents, if you take a look at WT- > 124i3 you can find requirements calling exactly for this draft to solve t= he > problem described above, this means a community of Service Providers' > recognized the need for this work. >=20 > Thanks > Regards, > Roberta >=20 > Questo messaggio e i suoi allegati sono indirizzati esclusivamente alle p= ersone > indicate. La diffusione, copia o qualsiasi altra azione derivante dalla > conoscenza di queste informazioni sono rigorosamente vietate. Qualora > abbiate ricevuto questo documento per errore siete cortesemente pregati d= i > darne immediata comunicazione al mittente e di provvedere alla sua > distruzione, Grazie. >=20 > This e-mail and any attachments is confidential and may contain privilege= d > information intended for the addressee(s) only. Dissemination, copying, > printing or use by anybody else is unauthorised. If you are not the inten= ded > recipient, please delete this message and any attachments and advise the > sender by return e-mail, Thanks. >=20 > _______________________________________________ > mif mailing list > mif@ietf.org > https://www.ietf.org/mailman/listinfo/mif From Ted.Lemon@nominum.com Thu Nov 17 04:29:08 2011 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 F0BE321F9AAF for ; Thu, 17 Nov 2011 04:29:08 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.566 X-Spam-Level: X-Spam-Status: No, score=-106.566 tagged_above=-999 required=5 tests=[AWL=0.033, 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 zt3GiO0kgxlS for ; Thu, 17 Nov 2011 04:29:02 -0800 (PST) Received: from exprod7og108.obsmtp.com (exprod7og108.obsmtp.com [64.18.2.169]) by ietfa.amsl.com (Postfix) with ESMTP id 1A2B021F9AAE for ; Thu, 17 Nov 2011 04:29:02 -0800 (PST) Received: from shell-too.nominum.com ([64.89.228.229]) (using TLSv1) by exprod7ob108.postini.com ([64.18.6.12]) with SMTP ID DSNKTsT+DWijzd0LA4tAhq1mGMHysCzx7cN4@postini.com; Thu, 17 Nov 2011 04:29:02 PST 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 94B071B82E5 for ; Thu, 17 Nov 2011 04:29:00 -0800 (PST) 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 7EDC419005D; Thu, 17 Nov 2011 04:28:59 -0800 (PST) (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.01.0339.001; Thu, 17 Nov 2011 04:28:59 -0800 From: Ted Lemon To: "teemu.savolainen@nokia.com" Thread-Topic: [mif] Motivations for draft-ietf-mif-dhcpv6-route-option Thread-Index: AQHMpSR6GTNnMi6f+UmkLHLSgpuiow== Date: Thu, 17 Nov 2011 12:28:58 +0000 Message-ID: References: <282BBE8A501E1F4DA9C775F964BB21FE3EB78C3C98@GRFMBX704BA020.griffon.local>, <916CE6CF87173740BC8A2CE44309696204193417@008-AM1MPN1-053.mgdnok.nokia.com> In-Reply-To: <916CE6CF87173740BC8A2CE44309696204193417@008-AM1MPN1-053.mgdnok.nokia.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "mif@ietf.org" Subject: Re: [mif] Motivations for draft-ietf-mif-dhcpv6-route-option 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, 17 Nov 2011 12:29:09 -0000 On Nov 17, 2011, at 7:15 PM, "teemu.savolainen@nokia.com" wrote: > I have to add I'm now quite confused why we are even having these motivat= ion discussions, as the charter was already agreed quite some time ago. We = are actually even late: The fact that this is in the MIF charter does not mean that there is consen= sus within the IETF to proceed with it. That is why we are having this co= nversation now. From moore@network-heretics.com Thu Nov 17 05:34:18 2011 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 202CB11E812C for ; Thu, 17 Nov 2011 05:34:18 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.314 X-Spam-Level: X-Spam-Status: No, score=-3.314 tagged_above=-999 required=5 tests=[AWL=0.285, 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 kpS4w-cIURYx for ; Thu, 17 Nov 2011 05:34:17 -0800 (PST) Received: from out2.smtp.messagingengine.com (out2.smtp.messagingengine.com [66.111.4.26]) by ietfa.amsl.com (Postfix) with ESMTP id 7813111E8124 for ; Thu, 17 Nov 2011 05:34:17 -0800 (PST) Received: from compute1.internal (compute1.nyi.mail.srv.osa [10.202.2.41]) by gateway1.nyi.mail.srv.osa (Postfix) with ESMTP id B16A6210ED for ; Thu, 17 Nov 2011 08:34:16 -0500 (EST) Received: from frontend1.nyi.mail.srv.osa ([10.202.2.160]) by compute1.internal (MEProxy); Thu, 17 Nov 2011 08:34:16 -0500 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d= messagingengine.com; h=subject:mime-version:content-type:from :in-reply-to:date:cc:content-transfer-encoding:message-id :references:to; s=smtpout; bh=9C8vZx591UEGiuvBsSb6yFEAtWw=; b=qr Fasqz/60Qz1y4i5Jv1+IDcCbGrLGaRV0KP5V7WpuYq4PrBKdmshE2jVknnIAiuIA ATewYcdRc2Khzc4xRxxcxoPDR+OCFZmKQfcojFvOW3C1Rc6cvRZtg6czJBiPEJnx x8EqUPJRr9i6fy8EI2p9WKExUwuupWCCS2kblnh8o= X-Sasl-enc: FqZ+tIIlz/lOsK2JDcp808pXbZmraU2lp5853QHdg6IK 1321536856 Received: from [192.168.1.16] (host65-16-145-177.birch.net [65.16.145.177]) by mail.messagingengine.com (Postfix) with ESMTPA id DB9528E014B; Thu, 17 Nov 2011 08:34:15 -0500 (EST) Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Keith Moore In-Reply-To: Date: Thu, 17 Nov 2011 08:34:14 -0500 Content-Transfer-Encoding: quoted-printable Message-Id: References: <4EC46D52.8030909@ogud.com>, <23E1BB1B-75C8-45E9-8CA3-2E3DC9B6DBC6@nominum.com>, <0B785F0F-F131-4C06-8B62-418B051EE79C@network-heretics.com> To: Ted Lemon X-Mailer: Apple Mail (2.1084) Cc: "mif@ietf.org" Subject: Re: [mif] Server selection document is "band-aid" not solution 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, 17 Nov 2011 13:34:18 -0000 On Nov 17, 2011, at 1:19 AM, Ted Lemon wrote: > On Nov 17, 2011, at 1:40 PM, "Keith Moore" = wrote: >> Either I disagree, or we're talking about different things. But DNS = cacheing assumes that the correct set of answers to a particular DNS = query are the same independent of where the query came from. This isn't = an implementation artifact, it's how DNS was designed to work. =20 >=20 > Right, so that's the uniform namespace assumption. But if you have = two routers querying two different sets of servers, this is a non-issue. Actually, that's not even true. And to the extent it is true, that is = an implementation artifact.=20 Keith From tomasz.mrugalski@gmail.com Thu Nov 17 05:56:57 2011 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 922BF21F9A63 for ; Thu, 17 Nov 2011 05:56:57 -0800 (PST) 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 oEdcL5p-G6QQ for ; Thu, 17 Nov 2011 05:56:56 -0800 (PST) Received: from mail-yw0-f44.google.com (mail-yw0-f44.google.com [209.85.213.44]) by ietfa.amsl.com (Postfix) with ESMTP id AA59121F9A4E for ; Thu, 17 Nov 2011 05:56:56 -0800 (PST) Received: by ywt34 with SMTP id 34so1275178ywt.31 for ; Thu, 17 Nov 2011 05:56:56 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=message-id:date:from:user-agent:mime-version:to:subject:references :in-reply-to:x-enigmail-version:content-type :content-transfer-encoding; bh=Lxd3qWSontuErL2MD6a0VxstY8cEr6WKpkl+zmI2YjQ=; b=ZKYW33jB3TrLytsGUlJNX/WCIf2h+PbzMHYBfDc8v8tjZBTUgRCS/S/y0zuvNe+G3P SYTViuhCqa7jHguUHIj2lUuBdT2tO9jTIvMkdcZFCHQkYHDNeOdwEZf+c5RI/HF9dJ2I 1X/+XdGAkUulqplPOPxQTjF56cKvUwW4xcHxI= Received: by 10.101.41.12 with SMTP id t12mr10247730anj.19.1321538216297; Thu, 17 Nov 2011 05:56:56 -0800 (PST) Received: from dhcp-41d0.meeting.ietf.org ([2001:df8:0:64:de2b:61ff:fee5:409c]) by mx.google.com with ESMTPS id k3sm96321033ann.0.2011.11.17.05.56.53 (version=SSLv3 cipher=OTHER); Thu, 17 Nov 2011 05:56:54 -0800 (PST) Message-ID: <4EC512A2.2060509@gmail.com> Date: Thu, 17 Nov 2011 21:56:50 +0800 From: Tomek Mrugalski User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:8.0) Gecko/20111105 Thunderbird/8.0 MIME-Version: 1.0 To: mif@ietf.org References: <282BBE8A501E1F4DA9C775F964BB21FE3EB78C3C98@GRFMBX704BA020.griffon.local> <916CE6CF87173740BC8A2CE44309696204193417@008-AM1MPN1-053.mgdnok.nokia.com> In-Reply-To: <916CE6CF87173740BC8A2CE44309696204193417@008-AM1MPN1-053.mgdnok.nokia.com> X-Enigmail-Version: 1.3.3 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: [mif] Use cases for draft-ietf-mif-dhcpv6-route-option needed 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, 17 Nov 2011 13:56:57 -0000 Hi, There was a meeting between proponents of this option, most vocal opponets, MIF chairs, DHC chairs and two ADs and several other knowledgeable people. The conclusion of this meeting was that to proceed with route option forward, specific use cases are needed. If you need this option, please describe your use case. If you assume that others will raise support for you, you may be in for a surprise. If this does not get enough documented, valid use cases, it seems that this option will not be standardized, at least not in IETF. Aternative solution discussed was to convey this using vendor-specific option (possibly within a body other than IETF); change the format to explicitly disallow default route. From my perspective (DHCP vendor) those approaches makes this solution much more difficult to deploy, often even preventing it completely. To have this list more organized, please assign a number to your support voice. It will make it easier to explain if comments are made about already mentioned use cases or new cases. If you have any specific concerns, there's separate thread for that. My understanding is that it helps if you are representing a large ISP, a vendor or someone else who has non-trivial impact on the industry. Voice of people, who express their personal opinions still count, but to a lesser degree. Here's the initial list of use cases. 1. http://www.ietf.org/mail-archive/web/mif/current/msg01412.html On 11-11-16 08:59, Maglione Roberta wrote: > Hello, during the meeting the chairs and many people asked about > use cases and motivations for this work: as I quickly mentioned at the > mic there is a draft in v6ops 2. http://www.ietf.org/mail-archive/web/mif/current/msg01428.html On 11-11-17 19:14, teemu.savolainen@nokia.com wrote: > +1 > > I have to add I'm now quite confused why we are even having these > motivation discussions, as the charter was already agreed quite some > time ago. We are actually even late: -- Jun 2011 - Submit DHCPv6 > routing configuration option to IESG for publication as a Proposed > Standard RFC -- > > We should focus on technical issues to complete the spec, like the > semantics. Not to spend time repeating old discussions. 3. Regarding motivation for real users, ISC is a DHCP vendor (client, server, relay). Our software is installed as a default client and server in many Linux and BSD distributions. Many of our customers and users request this feature. I can't explain each deployment model, but the commonly mentioned reason was simpler deployment and manageability. The latest ISC code supports route-option-03, but I'm not sure if it does matter or not. 4. I'm also author and developer of Dibbler, an open source DHCPv6 implementation (client, server, relay). This code works on Windows, Linux, Mac OS X, and most types of BSDs. There are users, who request this. Request for routing configuration (default route in particular) is the number one question asked througout the years. There is at least one ISP in Poland that wants (i.e. "already uses Dibbler and requests routing configuration") to deploy this feature. The latest version of Dibbler does support this route-option-03, but again I'm not sure if it matters or not. I admit that depending on your perspective this may be considered as a valid vendor (Dibbler has been around for 8 years, existing community, deployed in some production environments) or not (open source project without any real money behind it). I looked around and found the following other supporting voices. As I don't have operational experience, it would be great if the original proponents or commenters could go forward and explain their use cases. - Previous attempt to introduce very similar was proposed by Thomas Narten and Ralph Droms. Both were present during meeting and if I understand correctly, their reason to drop this work was because there was no substantial need for it last time (this was around 2009). Here's a link to their presentation: http://www.ietf.org/proceedings/74/slides/intarea-4.pdf It should be noted that some open issues (slide 8) are now resolved. - Wojciech Dec (Cisco) provided several usage models. I can't speak on behalf of Cisco, but can only assume that they have reasonable need for such feature. I'm sure Wojciech will provide detailed usage case soon. - In previous versions of this draft, there were several more use cases described: http://tools.ietf.org/html/draft-dec-dhcpv6-route-option-01 http://tools.ietf.org/html/draft-dec-dhcpv6-route-option-02 They were removed based on MIF WG feedback. - This draft is a result of a merge of 3 other drafts (draft-sarikaya-mif-dhcpv6solution, draft-sun-mif-address-policy-dhcp6 and draft-dec-dhcpv6-route-option). Present and former authors represent the following companies: Cisco, Huawei, China Mobile, Orange France Telecom and NTT PF Labs. Previous attempt to introduce similar option (draft-droms-dhc-dhcpv6-default-router-00) was undertaken by employees of Cisco and IBM. If you are one of authors, it would be great if you could step forward and explain your usage models and why you need this. Also, if you decided that this work is no longer relevant or was dropped, explaining the reasons would be very useful. There is a draft "IPv6 Multihoming without Network Address Translation" in v6ops (draft-ietf-v6ops-ipv6-multihoming-without-ipv6nat-03). It recommends use of this option. Again, if you are an author of this draft, could you please explain why you need this. We should also take into consideration people who were physically attending in MIF meeting. Significant majority of people (around 20) offered their support for this draft, while only 6 were against it. Similar support was voiced during adoption of this document in MIF. If you are one of those people, please express your support now. To have a balanced discussion on this topic, I will create one more thread regarding flaws and possible dangers of finishing this work, with comments from two opponents. Feel free to contribute your concerns. On a presonal note, my involvement in this work is on hold until this issue is resolved. Cheers, Tomek Mrugalski ISC From tomasz.mrugalski@gmail.com Thu Nov 17 05:59:31 2011 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 93DE921F97CF for ; Thu, 17 Nov 2011 05:59:31 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.524 X-Spam-Level: X-Spam-Status: No, score=-3.524 tagged_above=-999 required=5 tests=[AWL=0.075, 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 OZCeDkn0-or5 for ; Thu, 17 Nov 2011 05:59:30 -0800 (PST) Received: from mail-yx0-f172.google.com (mail-yx0-f172.google.com [209.85.213.172]) by ietfa.amsl.com (Postfix) with ESMTP id A615F21F97C6 for ; Thu, 17 Nov 2011 05:59:30 -0800 (PST) Received: by yenq4 with SMTP id q4so1262366yen.31 for ; Thu, 17 Nov 2011 05:59:30 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=message-id:date:from:user-agent:mime-version:to:subject :x-enigmail-version:content-type:content-transfer-encoding; bh=XyV2SXPbblhcIETSqGVAK4yBYyr3sQniYj8osT+qnj4=; b=CyLhV8bC6lwaZS/fKEN1atx9ejD1qKu0ZMWj3y0YyYmzbDvfD2iKF4pAnXCpS0YRaQ sb/73RpBg7kmQ03HhjZqTW4vaKbzOI3hmX0lSa8zaN+KMUl9TeQrrTG54RwDFGG1eq8C sApE1baFoE5YoV75biGnHQBWlgiTVSryhoXt0= Received: by 10.236.200.201 with SMTP id z49mr9683770yhn.20.1321538370304; Thu, 17 Nov 2011 05:59:30 -0800 (PST) Received: from dhcp-41d0.meeting.ietf.org ([2001:df8:0:64:de2b:61ff:fee5:409c]) by mx.google.com with ESMTPS id h28sm10818590ani.17.2011.11.17.05.59.27 (version=SSLv3 cipher=OTHER); Thu, 17 Nov 2011 05:59:29 -0800 (PST) Message-ID: <4EC5133D.3050508@gmail.com> Date: Thu, 17 Nov 2011 21:59:25 +0800 From: Tomek Mrugalski User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:8.0) Gecko/20111105 Thunderbird/8.0 MIME-Version: 1.0 To: mif@ietf.org X-Enigmail-Version: 1.3.3 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit Subject: [mif] Concerns regarding draft-ietf-mif-dhcpv6-route-option 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, 17 Nov 2011 13:59:31 -0000 Hi, This thread is about concerns regarding draft-ietf-mif-dhcpv6-route-option. At the moment this thead was started, the latest version is -03. See response to concern 3 below for proposed changes planned for -04. They will be implemented if the decision is made to continue this work. The latest presentation about this work was presented in DHC. It differs significantly compared to what was presnted in MIF. The major changes are: - option format to be unified to match RA - options from RA and DHCP do not override each other, but are merged instead (data delivered over DHCP are functional equivalent of receiving yet another RA). The goal of this thread and its "in favor" counter-part is to get input for chairs, ADs and possibly whole IESG whether work on route option should continue or not. There was substantial discussion during last MIF meeting, with follow-ups off the list. I tried to assemble major concerns raised. I'm sorry if I missed anything. If you want to expand this list, please add a number for easier reference. On 11-11-16 17:14, Stuart Cheshire wrote: > Some of my concerns with the DHCPv6 route option are: > > 1. It duplicates what RA already does. I do not like duplication. It > is *more* than double the work, because not only do you have to > implement two things, you also have to worry about how those two > things interact. Testing is more than twice as hard. Instead of just > testing RA, now you have to test RA alone, DHCPv6 route option alone, > and RA + DHCPv6 together. Tomek's comment: You can choose to: - not support DHCPv6 at all (using RA-only) - use DHCPv6, but not request route options (and keep using RA) - use DHCPv6, request route options and use RA Only the third option has the properties that you describe. I do not think that vendors suddenly jump to route option, start producing CPEs that use DHCP only and stop announcing RA. (therefore I haven't mentioned 4th option: use DHCPv6 exclusively and do not support RA) Stuart's answer: This sounds intentionally naïve about how standards evolve. The existence of two different sanctioned ways of doing things means that some vendors (and network operators) will do things one way and other vendors (and network operators) will do things the other way, and user pain will result. Wojciech's answer: Fair point, but the alternatives cause pain for the network operator. A balance needs to be found, and that balance does not appear to involve "loose DHCP" or "loose RAs". Developing towards an eco-system of "user and his device" and "no-one-else-matters" is also sounding intentionally naive. Stuart's comment #2: That sounds suspiciously like an attempt to bully and blackmail client vendors into having to do extra development, testing and support work that they did not willingly consent to, for someone else's convenience. Wojciech's response to #2: That plays both ways: Having a client vendor's convenience that forces network operators to change how they run their business, and support also looks like bullying. The balance appears to be in the middle. > 2. Its syntax and semantics are different to RA. If we're going to > duplicate RA, at least keep it as similar as possible. Tomek's answer: Agree. If we decide to continue work on this, I'll work with Dave Thaler on unifying format and conveyed information between RA and route option. Would you like to review a draft version before we publish it as -04? > 3. Rather than overriding RA, DHCPv6 route option data should merge > in with other RA data. Tomek's answer: I wasn't very clear in my presentation. My proposal about favoring DHCP was only in case of conflicting route entries. Discussion during presentation and many follow-ups showed that this approach would work in some cases, but not in all. I think we should consider following changes to -03: a. explain in which conditions this will not work, describe them and keep the preference as was proposed. Note that the approach of delivering RA to all hosts and then override for some hosts on a per hosts basis is a valid argument in favor of this approach. It seems that at this stage this would exclude homenet from deploying this mechanism (but please see point 5. below). Lorenzo Colitti (Google) noted that applicability statements do not prevent anything and are often ignored. b. merge data between DHCP and RA. From OS perspective the route provisioning over DHCP could be roughly perceived as reception of yet another RA, with equal treating. > 4. Speaking as an employee of one of the client vendors, I have not > seen any compelling argument why we should have to do a bunch of > extra work to satisfy some other unspecified people. There is dedicated thread for support voices. 5. (new point). There is another problem raised by Lorezno and further expanded by Ted Lemon that manifests itself in homenet deployment (but possibly could affect other deployments as well). In homenet architecture, one of the deployment models is one LAN network with 2 CPEs that connect to 2 different ISPs. If those CPE also offer DHCP, client will choose only one advertise and completely ignore the second. In case of failure of this CPE, client doesn't have any ability to learn the other set of parameter that the second DHCP server would have provided. That is general problem of DHCP protocol and affects all other options that DHCP can provide (including addresses, delegated prefixes, and options like DNS or routing). Ted Lemon started working on this problem. See presentation about DHCPv6 and Multihoming problem statement in DHC WG. Presentation is not up yet, but hopefully it will appear here: http://tools.ietf.org/agenda/82/dhc.html 6. Doom of RA. Lorezno Colitti described set of events that he predicts will happen that will eventually lead to a collapse of the whole RA model. As a vendor of mobile devices, he afraids that once route option is defined, some CPE vendors will adopt it. This will force mobile device vendors to support route option. Once it becomes more popular, some CPE vendors may decide to stop announcing RA. This will enable operation without RA. Not needing it, RA will become essentially obsolete. This in turn will make the benefits of dynamic configuration offered by RA and put us back with static configuration that is known from IPv4. I can't comment on feasibility of this scenario as I don't have operational experience. During follow up discussions, several people pointed out that this is an excessively pessimistic scenario. Please add your favourite reason, why this option should not be deployed here. On the other hand, if you are supporter of this option, there is a separate thread for this as well. On a presonal note, my involvement in this work is on hold until this issue is resolved. Cheers, Tomek Mrugalski ISC From moore@network-heretics.com Thu Nov 17 06:30:27 2011 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 1700411E815B for ; Thu, 17 Nov 2011 06:30:27 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.322 X-Spam-Level: X-Spam-Status: No, score=-3.322 tagged_above=-999 required=5 tests=[AWL=0.277, 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 IdD31yFaQNy4 for ; Thu, 17 Nov 2011 06:30:26 -0800 (PST) Received: from out2.smtp.messagingengine.com (out2.smtp.messagingengine.com [66.111.4.26]) by ietfa.amsl.com (Postfix) with ESMTP id 7B86E11E8153 for ; Thu, 17 Nov 2011 06:30:26 -0800 (PST) Received: from compute2.internal (compute2.nyi.mail.srv.osa [10.202.2.42]) by gateway1.nyi.mail.srv.osa (Postfix) with ESMTP id 1D7E921377 for ; Thu, 17 Nov 2011 09:30:26 -0500 (EST) Received: from frontend1.nyi.mail.srv.osa ([10.202.2.160]) by compute2.internal (MEProxy); Thu, 17 Nov 2011 09:30:26 -0500 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d= messagingengine.com; h=subject:mime-version:content-type:from :in-reply-to:date:cc:content-transfer-encoding:message-id :references:to; s=smtpout; bh=Hg9XgS53cWcxNIBNHvMS5347MAg=; b=bi xob1t1tzpkP2aZslr85FRyUU0FmM5h+Y3RHbnW8ZkVBWUs/WE+gTtULOC5XSVns/ Hes2YfoTYNeiX5Q8kopF/zFfz8WZoU9D779uJhdg240UK6A/rMLJQFLbX8nBJz+m y0QNKaYXuJ5pHSS+y4jNcqhFNYv/HEoUnDX2OZbGg= X-Sasl-enc: wQZ5Sod6izRikxQhTanGdw9GDPodfjnQTZodQUJPKOZx 1321540225 Received: from [192.168.1.16] (host65-16-145-177.birch.net [65.16.145.177]) by mail.messagingengine.com (Postfix) with ESMTPA id 4255A8E014C; Thu, 17 Nov 2011 09:30:25 -0500 (EST) Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Keith Moore In-Reply-To: <20111117060127.GB34506@shinkuro.com> Date: Thu, 17 Nov 2011 09:30:24 -0500 Content-Transfer-Encoding: quoted-printable Message-Id: References: <4EC46D52.8030909@ogud.com> <916CE6CF87173740BC8A2CE44309696204192558@008-AM1MPN1-053.mgdnok.nokia.com> <20111117060127.GB34506@shinkuro.com> To: Andrew Sullivan X-Mailer: Apple Mail (2.1084) Cc: mif@ietf.org Subject: Re: [mif] Server selection document is "band-aid" not solution 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, 17 Nov 2011 14:30:27 -0000 On Nov 17, 2011, at 1:01 AM, Andrew Sullivan wrote: > On Thu, Nov 17, 2011 at 02:47:45AM +0000, teemu.savolainen@nokia.com = wrote: >=20 >> The DNS server selection document indeed assumes applications do not >> provide preference on what "context" they want to use - because >> generally applications just don't know that information, and we want >> to avoid bothering users with network selection UI dialogs. >=20 > No, the reason applications don't have that interface is because we > told them that the DNS is a unified name space. That's its design. > (This is part of Olafur's point, if I read him correctly.) >=20 > As a matter of fact, because of what people have done with the DNS, it > is _not_ a unified name space, and you will indeed get different > answers on different interfaces. In other words, people have used DNS in a way that is contrary to its = design, and in the past it has happened to (often) work only because = hosts tended to have only one active interface to the network that = provided DNS at any given time. > Moreover, vendors (who perhaps ought > to have known better) have attempted to fix that by adding curious > different ways of not experiencing too much pain whenever this > situation arises. >=20 > The reason that we need the server selection document, therefore, is > that we want people to do this hackery in a way that causes the least > harm. =20 If we want that to happen then the server selection document should make = it explicit that the results of any DNS query via any network interface = MAY be used to establish a connection on any network interface. Or maybe there needs to be some way to distinguish name servers serving = private namespaces from those serving public name spaces, so that the = host can tell the difference. Ideally that should be communicated by = the private name servers themselves in every DNS response that involves = a private name. Then the host would know that that specific response = was interface-specific. Keith From teemu.savolainen@nokia.com Thu Nov 17 09:59:47 2011 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 14F8F1F0C44 for ; Thu, 17 Nov 2011 09:59:47 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.077 X-Spam-Level: X-Spam-Status: No, score=-1.077 tagged_above=-999 required=5 tests=[AWL=-1.378, BAYES_00=-2.599, J_CHICKENPOX_32=0.6, MANGLED_EMAIL=2.3] 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 SEQdlUoGHEwP for ; Thu, 17 Nov 2011 09:59:46 -0800 (PST) Received: from mgw-sa02.nokia.com (smtp.nokia.com [147.243.1.48]) by ietfa.amsl.com (Postfix) with ESMTP id 5BA0A1F0C38 for ; Thu, 17 Nov 2011 09:59:46 -0800 (PST) Received: from vaebh106.NOE.Nokia.com (vaebh106.europe.nokia.com [10.160.244.32]) by mgw-sa02.nokia.com (Switch-3.4.4/Switch-3.4.4) with ESMTP id pAHHxeDT024056; Thu, 17 Nov 2011 19:59:41 +0200 Received: from smtp.mgd.nokia.com ([65.54.30.25]) by vaebh106.NOE.Nokia.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.4675); Thu, 17 Nov 2011 19:59:36 +0200 Received: from 008-AM1MPN1-053.mgdnok.nokia.com ([169.254.3.114]) by 008-AM1MMR1-009.mgdnok.nokia.com ([65.54.30.25]) with mapi id 14.01.0355.003; Thu, 17 Nov 2011 18:59:35 +0100 From: To: , Thread-Topic: [mif] Server selection document is "band-aid" not solution Thread-Index: AQHMpTVxTOsAnc2+q0G6xead7mSgZZWxWi8g Date: Thu, 17 Nov 2011 17:59:35 +0000 Message-ID: <916CE6CF87173740BC8A2CE443096962041936A5@008-AM1MPN1-053.mgdnok.nokia.com> References: <4EC46D52.8030909@ogud.com> <916CE6CF87173740BC8A2CE44309696204192558@008-AM1MPN1-053.mgdnok.nokia.com> <20111117060127.GB34506@shinkuro.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-tituslabs-classifications-30: TLPropertyRoot=Nokia;Confidentiality=Company Confidential;Project=None; x-titus-version: 3.3.8.1 x-headerinfofordlp: None x-tituslabs-classificationhash-30: VgNFIFU9Hx+/nZJb9Kg7IvaJJ98g1xw6ajjuiF5UmoaKq8umyOZD9ad1l9N9r5NECFByLs3Bt4g/wwz9DRSIrWcYYm/Bxz8jzPZSzkZKbcL6NxnhI1RPliqW0jzeRbuL1oJrP8kVNbdFK55Mc64BpIeQuLJZlzWof4BIfLou3+V+5CFJ8VS+22nuHJ+0vFjp3f8Ktn85v83tq/aZf2WmtrrMr6VJ/V6Qak1iUgJ84h1XIJW/kr0d9poZJ6ObP/udljFrDe65ZjHLpeBXDaJfXQ== x-originating-ip: [10.163.117.20] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginalArrivalTime: 17 Nov 2011 17:59:36.0431 (UTC) FILETIME=[AB27B7F0:01CCA552] X-Nokia-AV: Clean Cc: mif@ietf.org Subject: Re: [mif] Server selection document is "band-aid" not solution 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, 17 Nov 2011 17:59:47 -0000 > If we want that to happen then the server selection document should make = it > explicit that the results of any DNS query via any network interface MAY = be > used to establish a connection on any network interface. Source and destination address selection is a separate process and describe= d in different documents. One could do even happy eyeballs after having the result back from DNS and = try'em'all in parallel. Teemu From Ted.Lemon@nominum.com Thu Nov 17 12:05:07 2011 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 8A4C611E8086 for ; Thu, 17 Nov 2011 12:05:07 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.567 X-Spam-Level: X-Spam-Status: No, score=-106.567 tagged_above=-999 required=5 tests=[AWL=0.032, 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 8S0crbRf1vUa for ; Thu, 17 Nov 2011 12:05:07 -0800 (PST) Received: from exprod7og103.obsmtp.com (exprod7og103.obsmtp.com [64.18.2.159]) by ietfa.amsl.com (Postfix) with ESMTP id B009411E8080 for ; Thu, 17 Nov 2011 12:05:06 -0800 (PST) Received: from shell-too.nominum.com ([64.89.228.229]) (using TLSv1) by exprod7ob103.postini.com ([64.18.6.12]) with SMTP ID DSNKTsVo4rVLxX5g8rGDZ3haUCvAjaIwTNUy@postini.com; Thu, 17 Nov 2011 12:05:06 PST 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 ABC4D1B829F for ; Thu, 17 Nov 2011 12:04:49 -0800 (PST) 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 9A28619005D; Thu, 17 Nov 2011 12:04:49 -0800 (PST) (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.01.0339.001; Thu, 17 Nov 2011 12:04:49 -0800 From: Ted Lemon To: Tomek Mrugalski Thread-Topic: [mif] Use cases for draft-ietf-mif-dhcpv6-route-option needed Thread-Index: AQHMpTDIlqhpaSyz00KEF63uwOK0AZWxffBi Date: Thu, 17 Nov 2011 20:04:49 +0000 Message-ID: <890A58CF-8EAD-4F92-9981-9B5AA07EBF00@nominum.com> References: <282BBE8A501E1F4DA9C775F964BB21FE3EB78C3C98@GRFMBX704BA020.griffon.local> <916CE6CF87173740BC8A2CE44309696204193417@008-AM1MPN1-053.mgdnok.nokia.com>, <4EC512A2.2060509@gmail.com> In-Reply-To: <4EC512A2.2060509@gmail.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "mif@ietf.org" Subject: Re: [mif] Use cases for draft-ietf-mif-dhcpv6-route-option needed 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, 17 Nov 2011 20:05:07 -0000 On Nov 17, 2011, at 9:57 PM, "Tomek Mrugalski" = wrote: > To have this list more organized, please assign a number to your support > voice. It will make it easier to explain if comments are made about > already mentioned use cases or new cases. If you have any specific > concerns, there's separate thread for that. >=20 > My understanding is that it helps if you are representing a large ISP, a > vendor or someone else who has non-trivial impact on the industry. Voice > of people, who express their personal opinions still count, but to a > lesser degree. To be clear, a use case is not "I want it because I think it would be nice.= " It's "Router Advertisements don't work for me for the following specifi= c reason in my actual deployment." =20 The fact that it is the most requested feature isn't the point. The quest= ion is, *why* is it the most requested feature? Is it because people have= zero operational experience with IPv6, and are just trying to do the same = thing they did in IPv4, and once you explain RAs to them they say "oh, okay= " and stop asking for it? Or is it the case that there is some genuine de= ployment problem that RAs don't properly address? The reason why the vendor option solution was proposed is that the only use= cases that anybody could actually come up with in the meeting yesterday we= re use cases that were specific to particular ISP deployment models, and it= seemed clear that these use cases could be adequately addressed with 3GPP-= and BBF-specific extensions. There is genuine need in these two cases fo= r this functionality. The reason why this isn't a no-brainer is that if it were added as a standa= rd IETF solution, it would change what end nodes have to do to get routes, = making end node software more complicated, and also more difficult to speci= fy. As one of the authors of the MIF API document, I've had to think a lo= t about this problem, and I do not like having to have two different ways o= f configuring routes. The MIF problem is hard enough already; adding this= to the problem seems to me to make it worse, not better. I'm also pragmatic. If we have to make this problem a little bit worse to= solve some real world problem, fine, let's make the problem a little bit w= orse. But if we're doing it because people think they have to have featur= e parity with DHCPv4, that's just not a good enough reason. From moore@network-heretics.com Thu Nov 17 12:37:34 2011 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 16F4621F999C for ; Thu, 17 Nov 2011 12:37:34 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.329 X-Spam-Level: X-Spam-Status: No, score=-3.329 tagged_above=-999 required=5 tests=[AWL=0.269, 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 4BO+5Xchos1l for ; Thu, 17 Nov 2011 12:37:33 -0800 (PST) Received: from out2.smtp.messagingengine.com (out2.smtp.messagingengine.com [66.111.4.26]) by ietfa.amsl.com (Postfix) with ESMTP id 65BE821F9979 for ; Thu, 17 Nov 2011 12:37:33 -0800 (PST) Received: from compute2.internal (compute2.nyi.mail.srv.osa [10.202.2.42]) by gateway1.nyi.mail.srv.osa (Postfix) with ESMTP id D4E6820527 for ; Thu, 17 Nov 2011 15:37:32 -0500 (EST) Received: from frontend1.nyi.mail.srv.osa ([10.202.2.160]) by compute2.internal (MEProxy); Thu, 17 Nov 2011 15:37:32 -0500 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d= messagingengine.com; h=subject:mime-version:content-type:from :in-reply-to:date:cc:message-id:references:to; s=smtpout; bh=RHQ ADq1i18fBL9bH1VBjxi45fww=; b=Y1eXBj5It5tuEyIN1Nhf4u5GRMLqE8bR5RI QAc7NtGfhLXRJ+rwjJvnyNhOfIx00rDlT2kHlCnX3rII0spXChmf4d3OsrPVtWJK BMrD5dNWnbmJdgD5hUPhf4k2HQv9ZVpUjiDtsEn7geKfaUDL9778iVzWBxrIELIa EJKf/d6M= X-Sasl-enc: iwoIHXf83ZY/RY2GssC/6zuR90jKmBHdgdat+owQvcFs 1321562252 Received: from [192.168.1.16] (host65-16-145-177.birch.net [65.16.145.177]) by mail.messagingengine.com (Postfix) with ESMTPA id D0DF88E00D5; Thu, 17 Nov 2011 15:37:31 -0500 (EST) Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: multipart/alternative; boundary=Apple-Mail-180--342332425 From: Keith Moore In-Reply-To: <4EC512A2.2060509@gmail.com> Date: Thu, 17 Nov 2011 15:37:31 -0500 Message-Id: <792585A2-A05D-4D55-90FE-E08C7F26143E@network-heretics.com> References: <282BBE8A501E1F4DA9C775F964BB21FE3EB78C3C98@GRFMBX704BA020.griffon.local> <916CE6CF87173740BC8A2CE44309696204193417@008-AM1MPN1-053.mgdnok.nokia.com> <4EC512A2.2060509@gmail.com> To: Tomek Mrugalski X-Mailer: Apple Mail (2.1084) Cc: mif@ietf.org Subject: Re: [mif] Use cases for draft-ietf-mif-dhcpv6-route-option needed 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, 17 Nov 2011 20:37:34 -0000 --Apple-Mail-180--342332425 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii On Nov 17, 2011, at 8:56 AM, Tomek Mrugalski wrote: > My understanding is that it helps if you are representing a large ISP, = a > vendor or someone else who has non-trivial impact on the industry. = Voice > of people, who express their personal opinions still count, but to a > lesser degree. That is a misunderstanding. =20 We are all supposed to be acting as individuals here, voicing our own = opinions as to what is best for the Internet. Nobody's opinion counts = more than any one else's when it comes to determining consensus. That said, many individuals (hopefully most of us) do care about the = degree of impact that a design choice would have, so if an employee = of a major vendor says that a choice will have a significant impact on = that vendor's customers, that input tends to be taken seriously. = Actually, input of that kind tends to be taken seriously even if it = doesn't come from a vendor's employee, but it might be taken as more = credible if it comes from someone who is presumed to have first-hand = knowledge. Keith --Apple-Mail-180--342332425 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii
My = understanding is that it helps if you are representing a large ISP, = a
vendor or someone else who has non-trivial impact on the industry. = Voice
of people, who express their personal opinions still count, but = to a
lesser degree.

That is a = misunderstanding.  

We are all supposed to = be acting as individuals here, voicing our own opinions as to what is = best for the Internet.    Nobody's opinion counts more than = any one else's when it comes to determining = consensus.

That said, many individuals = (hopefully most of us) do care about the degree of impact that a design = choice would have, so    if an employee of a major vendor says = that a choice will have a significant impact on that vendor's customers, = that input tends to be taken seriously.   Actually, input of that = kind tends to be taken seriously even if it doesn't come from a vendor's = employee, but it might be taken as more credible if it comes from = someone who is presumed to have first-hand = knowledge.

Keith



= --Apple-Mail-180--342332425-- From Ted.Lemon@nominum.com Thu Nov 17 12:37:54 2011 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 64D9E11E80D9 for ; Thu, 17 Nov 2011 12:37:54 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.567 X-Spam-Level: X-Spam-Status: No, score=-106.567 tagged_above=-999 required=5 tests=[AWL=0.032, 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 QG3LTG+WXWP6 for ; Thu, 17 Nov 2011 12:37:53 -0800 (PST) Received: from exprod7og114.obsmtp.com (exprod7og114.obsmtp.com [64.18.2.215]) by ietfa.amsl.com (Postfix) with ESMTP id D8D8B11E809C for ; Thu, 17 Nov 2011 12:37:51 -0800 (PST) Received: from shell-too.nominum.com ([64.89.228.229]) (using TLSv1) by exprod7ob114.postini.com ([64.18.6.12]) with SMTP ID DSNKTsVwn7SseQsFtKk+o1SiB1uZBWLAfnly@postini.com; Thu, 17 Nov 2011 12:37:51 PST 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 0CFD41B827C for ; Thu, 17 Nov 2011 12:37:51 -0800 (PST) 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 E348319005D; Thu, 17 Nov 2011 12:37:50 -0800 (PST) (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.01.0339.001; Thu, 17 Nov 2011 12:37:51 -0800 From: Ted Lemon To: Keith Moore Thread-Topic: [mif] Server selection document is "band-aid" not solution Thread-Index: AQHMpM8ZeOJMqkjpCkunz3mHScTfw5WxD2cA//98ReyAAIe9gP//hMrwgAD/fAD///A+ig== Date: Thu, 17 Nov 2011 20:37:50 +0000 Message-ID: <17DF2079-601E-4F84-8F0A-20ECF9FF1366@nominum.com> References: <4EC46D52.8030909@ogud.com>, <23E1BB1B-75C8-45E9-8CA3-2E3DC9B6DBC6@nominum.com>, <0B785F0F-F131-4C06-8B62-418B051EE79C@network-heretics.com> , In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "mif@ietf.org" Subject: Re: [mif] Server selection document is "band-aid" not solution 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, 17 Nov 2011 20:37:54 -0000 On Nov 17, 2011, at 9:34 PM, "Keith Moore" wro= te: >> Right, so that's the uniform namespace assumption. But if you have two= routers querying two different sets of servers, this is a non-issue. >=20 > Actually, that's not even true. And to the extent it is true, that is an= implementation artifact.=20 Wow, I don't know where my brain was just then. I meant "resolvers," not = "routers." From moore@network-heretics.com Thu Nov 17 12:39:25 2011 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 6688F11E80E9 for ; Thu, 17 Nov 2011 12:39:25 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.337 X-Spam-Level: X-Spam-Status: No, score=-3.337 tagged_above=-999 required=5 tests=[AWL=0.262, 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 AQ-UYfDkkoT8 for ; Thu, 17 Nov 2011 12:39:25 -0800 (PST) Received: from out2.smtp.messagingengine.com (out2.smtp.messagingengine.com [66.111.4.26]) by ietfa.amsl.com (Postfix) with ESMTP id E57B611E80D9 for ; Thu, 17 Nov 2011 12:39:24 -0800 (PST) Received: from compute6.internal (compute6.nyi.mail.srv.osa [10.202.2.46]) by gateway1.nyi.mail.srv.osa (Postfix) with ESMTP id 906B420F31 for ; Thu, 17 Nov 2011 15:39:24 -0500 (EST) Received: from frontend1.nyi.mail.srv.osa ([10.202.2.160]) by compute6.internal (MEProxy); Thu, 17 Nov 2011 15:39:24 -0500 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d= messagingengine.com; h=subject:mime-version:content-type:from :in-reply-to:date:cc:content-transfer-encoding:message-id :references:to; s=smtpout; bh=Nc1qJI41y7N0xGIHv0VUjgXIvQw=; b=ns oxwpTZv/nD9B59NR/79gxjCyEIBigo0MvzV97fpc6r3NjV8Jvak1JubNX7lGg1Cs TUt01dJ966b8ywGCTmbk1OVsiIgqySR9Z6Y/jkUk3jyQRFxkuPC5AOcbjdf/86zj fcj8ERtvubXyeqh/bQ08ayv1diJq+OFaJZf0+NDug= X-Sasl-enc: 10VqRpUHJiU/ERIHgXmsSauGgf48Y9MFCjoN+YguRZrT 1321562364 Received: from [192.168.1.16] (host65-16-145-177.birch.net [65.16.145.177]) by mail.messagingengine.com (Postfix) with ESMTPA id BAD888E00D6; Thu, 17 Nov 2011 15:39:23 -0500 (EST) Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Keith Moore In-Reply-To: <17DF2079-601E-4F84-8F0A-20ECF9FF1366@nominum.com> Date: Thu, 17 Nov 2011 15:39:22 -0500 Content-Transfer-Encoding: quoted-printable Message-Id: <358A8E60-5BFA-444A-B781-718BC5EF89A7@network-heretics.com> References: <4EC46D52.8030909@ogud.com>, <23E1BB1B-75C8-45E9-8CA3-2E3DC9B6DBC6@nominum.com>, <0B785F0F-F131-4C06-8B62-418B051EE79C@network-heretics.com> , <17DF2079-601E-4F84-8F0A-20ECF9FF1366@nominum.com> To: Ted Lemon X-Mailer: Apple Mail (2.1084) Cc: "mif@ietf.org" Subject: Re: [mif] Server selection document is "band-aid" not solution 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, 17 Nov 2011 20:39:25 -0000 On Nov 17, 2011, at 3:37 PM, Ted Lemon wrote: > On Nov 17, 2011, at 9:34 PM, "Keith Moore" = wrote: >>> Right, so that's the uniform namespace assumption. But if you have = two routers querying two different sets of servers, this is a non-issue. >>=20 >> Actually, that's not even true. And to the extent it is true, that = is an implementation artifact.=20 >=20 > Wow, I don't know where my brain was just then. I meant "resolvers," = not "routers." I just assumed you meant separate data paths, including all of = resolvers, routers, network links, etc. Seriously, dual-facing servers are the implementation artifacts. It's = an accident that they work at all. From brian.e.carpenter@gmail.com Thu Nov 17 15:25:25 2011 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 AE7A21F0C4C for ; Thu, 17 Nov 2011 15:25:25 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.895 X-Spam-Level: X-Spam-Status: No, score=-101.895 tagged_above=-999 required=5 tests=[AWL=-1.196, BAYES_00=-2.599, J_CHICKENPOX_32=0.6, MANGLED_EMAIL=2.3, 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 rFOYNWzibdmY for ; Thu, 17 Nov 2011 15:25:23 -0800 (PST) Received: from mail-yx0-f172.google.com (mail-yx0-f172.google.com [209.85.213.172]) by ietfa.amsl.com (Postfix) with ESMTP id CD3631F0C36 for ; Thu, 17 Nov 2011 15:25:23 -0800 (PST) Received: by yenq4 with SMTP id q4so2103539yen.31 for ; Thu, 17 Nov 2011 15:25:23 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=message-id:date:from:organization:user-agent:mime-version:to:cc :subject:references:in-reply-to:content-type :content-transfer-encoding; bh=FyUJngzfv/kRGEr+El5y1YoY222Awt2VINWf2BTPMao=; b=bD9VgE4BYxHGpskd+Q7NsXvujjwe5Yk7FB3nHkQ0q+YKkB1A497Ed45XApeYxwk3Yu dqbBc5/ll+WN9kfyC2BdLmApRjcHpPKuihFo85/afvwx55z+0y2oN4RBeENfXS8KVduy 84NiH2ajG3fRSo8yFVfrVKnDir6PlnkfjSLFw= Received: by 10.236.77.163 with SMTP id d23mr1096095yhe.34.1321572323422; Thu, 17 Nov 2011 15:25:23 -0800 (PST) Received: from [192.168.0.45] (61-31-89-133.static.tfn.net.tw. [61.31.89.133]) by mx.google.com with ESMTPS id 32sm19135785anu.10.2011.11.17.15.25.20 (version=SSLv3 cipher=OTHER); Thu, 17 Nov 2011 15:25:22 -0800 (PST) Message-ID: <4EC597DA.1020706@gmail.com> Date: Fri, 18 Nov 2011 12:25:14 +1300 From: Brian E Carpenter Organization: University of Auckland User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: teemu.savolainen@nokia.com References: <4EC46D52.8030909@ogud.com> <916CE6CF87173740BC8A2CE44309696204192558@008-AM1MPN1-053.mgdnok.nokia.com> <20111117060127.GB34506@shinkuro.com> <916CE6CF87173740BC8A2CE443096962041936A5@008-AM1MPN1-053.mgdnok.nokia.com> In-Reply-To: <916CE6CF87173740BC8A2CE443096962041936A5@008-AM1MPN1-053.mgdnok.nokia.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: ajs@crankycanuck.ca, mif@ietf.org, moore@network-heretics.com Subject: Re: [mif] Server selection document is "band-aid" not solution 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, 17 Nov 2011 23:25:25 -0000 On 2011-11-18 06:59, teemu.savolainen@nokia.com wrote: >> If we want that to happen then the server selection document should make it >> explicit that the results of any DNS query via any network interface MAY be >> used to establish a connection on any network interface. > > Source and destination address selection is a separate process and described in different documents. > > One could do even happy eyeballs after having the result back from DNS and try'em'all in parallel. IMHO Keith and Teemu are both correct, and all these three points should be made clear in paragraph 4 of the Introduction to draft-ietf-mif-dns-server-selection. Brian From brian.e.carpenter@gmail.com Thu Nov 17 17:18:36 2011 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 E3DF111E809D for ; Thu, 17 Nov 2011 17:18:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.933 X-Spam-Level: X-Spam-Status: No, score=-101.933 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, SARE_RECV_SPAM_DOMN0b=1.666, 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 gRZNOEWN0+dL for ; Thu, 17 Nov 2011 17:18:36 -0800 (PST) Received: from mail-vx0-f172.google.com (mail-vx0-f172.google.com [209.85.220.172]) by ietfa.amsl.com (Postfix) with ESMTP id 3B2E411E808C for ; Thu, 17 Nov 2011 17:18:36 -0800 (PST) Received: by vcbfl15 with SMTP id fl15so3094425vcb.31 for ; Thu, 17 Nov 2011 17:18:30 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=message-id:date:from:organization:user-agent:mime-version:to:cc :subject:references:in-reply-to:content-type :content-transfer-encoding; bh=6Fai+vg+hCAcJDYCzTm9o7RGSs/QmZ68CKrUZvOBzdU=; b=i6aeaeFOjFXgsLkaYF8sBX+ZRSrI14keyhRg+DMFsdJJOqzFsCJyEMzH30RM1tvtPI 2Cz0F+ADuVox5X4gjdONZdWJq70pflQD8unzC+wWsXKaMPKqHeSz5P5HlTnz0f4T5Ule xwEPUs14Pwq5vqk0Lp8R61vfLmV8UjvIqBc5o= Received: by 10.52.20.147 with SMTP id n19mr1113683vde.77.1321579109895; Thu, 17 Nov 2011 17:18:29 -0800 (PST) Received: from [192.168.0.45] (59-115-128-127.dynamic.hinet.net. [59.115.128.127]) by mx.google.com with ESMTPS id p2sm49996260vdi.22.2011.11.17.17.18.26 (version=SSLv3 cipher=OTHER); Thu, 17 Nov 2011 17:18:28 -0800 (PST) Message-ID: <4EC5B25C.7010903@gmail.com> Date: Fri, 18 Nov 2011 14:18:20 +1300 From: Brian E Carpenter Organization: University of Auckland User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: Ted Lemon References: <4EC46D52.8030909@ogud.com> <916CE6CF87173740BC8A2CE44309696204192558@008-AM1MPN1-053.mgdnok.nokia.com>, <4EC479E0.6030704@gmail.com> <292CDFDE-32DE-43D9-83DD-86D3978F3EEF@nominum.com> In-Reply-To: <292CDFDE-32DE-43D9-83DD-86D3978F3EEF@nominum.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: "mif@ietf.org" Subject: Re: [mif] Server selection document is "band-aid" not solution 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, 18 Nov 2011 01:18:37 -0000 Ted, On 2011-11-17 17:54, Ted Lemon wrote: > On Nov 17, 2011, at 11:05 AM, "Brian E Carpenter" wrote: >> I don't see how we could define a helpful API until the generic problem >> of scope is solved (see my previous message). We have no general way >> for an application to know or describe the scope that applies to itself and >> the peer(s) it wants to talk to. > > It seems to me that applications "knowing" what scope they want to talk to is a very isolated special case. E.g., perhaps your set-top box knows that it needs to go through your cable ISP's provisioning domain to get streaming video. But generally speaking, your application wants to connect through whatever provisioning domain works best, which is something no provisioning domain can claim to know; it is something only the host can determine. Ultimately, only the hosts involved in a particular transaction can discover what works best for them, which is why SCTP, MPTCP and SHIM6/REAP were invented, as well as happy-eyeballs. However these (and any other) host mechanisms need an initial set of address pairs to try out and, in many cases, an order of preference in which to try them. In some cases (but not all) DNS may be source of a set of destination addresses, but it's only the routing system that can provide a priori information about which address *pairs* are worth trying. On 2011-11-17 17:52, Ted Lemon wrote: > On Nov 17, 2011, at 10:41 AM, "Brian E Carpenter" wrote: >> > However, I don't believe MIF can be expected to solve this problem, >> > and therefore the server selection draft seems to be the best >> > that MIF can do. > > On the contrary, this is _exactly_ the problem MIF should be solving. And I agree 100% that server selection is just a bandaid. Really it's not even that: it's a hint that some DNS subdomains ought to be resolved by specific DNS servers in a specific provisioning domain, but it doesn't even address the larger problem. Well it's above my pay grade to make the calls about what is in scope for this WG, but it seems to me that it's a quite general architectural problem and MIF has a more tactical remit. Brian From brian.e.carpenter@gmail.com Thu Nov 17 17:38:51 2011 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 49F7921F90C0 for ; Thu, 17 Nov 2011 17:38:51 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.933 X-Spam-Level: X-Spam-Status: No, score=-101.933 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, SARE_RECV_SPAM_DOMN0b=1.666, 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 gxWxifxhAprG for ; Thu, 17 Nov 2011 17:38:50 -0800 (PST) Received: from mail-yx0-f172.google.com (mail-yx0-f172.google.com [209.85.213.172]) by ietfa.amsl.com (Postfix) with ESMTP id 593EC21F9000 for ; Thu, 17 Nov 2011 17:38:50 -0800 (PST) Received: by yenq4 with SMTP id q4so2229818yen.31 for ; Thu, 17 Nov 2011 17:38:50 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=message-id:date:from:organization:user-agent:mime-version:to:cc :subject:references:in-reply-to:content-type :content-transfer-encoding; bh=ngublHst8puUUW5BjolqtjzMNVdYNz+nIJw8wq8gbRw=; b=Z0o7hV1NpReRNi3KqF0vyUIOhTv7GT8oahU8THhAuj/5gdpfSWxDXm6lw2rZLOBPiC OQeyhEsZPpu8PvEjqAb3ZdoQ/BHXNZq6mTgYkjxFIba/Nz5IZEOE3ZIgy/BBwBaG4iUZ 3KDJ19VGbAXzsDwUszDO9A0Y2TMFy1r12DoQU= Received: by 10.236.154.193 with SMTP id h41mr1599452yhk.15.1321580329926; Thu, 17 Nov 2011 17:38:49 -0800 (PST) Received: from [192.168.0.45] (59-115-128-127.dynamic.hinet.net. [59.115.128.127]) by mx.google.com with ESMTPS id b9sm101375397anb.7.2011.11.17.17.38.47 (version=SSLv3 cipher=OTHER); Thu, 17 Nov 2011 17:38:49 -0800 (PST) Message-ID: <4EC5B720.8020605@gmail.com> Date: Fri, 18 Nov 2011 14:38:40 +1300 From: Brian E Carpenter Organization: University of Auckland User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: Ted Lemon References: <282BBE8A501E1F4DA9C775F964BB21FE3EB78C3C98@GRFMBX704BA020.griffon.local> <916CE6CF87173740BC8A2CE44309696204193417@008-AM1MPN1-053.mgdnok.nokia.com>, <4EC512A2.2060509@gmail.com> <890A58CF-8EAD-4F92-9981-9B5AA07EBF00@nominum.com> In-Reply-To: <890A58CF-8EAD-4F92-9981-9B5AA07EBF00@nominum.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: "mif@ietf.org" Subject: [mif] Use case 42 [Re: Use cases for draft-ietf-mif-dhcpv6-route-option needed] 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, 18 Nov 2011 01:38:51 -0000 On 2011-11-18 09:04, Ted Lemon wrote: > On Nov 17, 2011, at 9:57 PM, "Tomek Mrugalski" > wrote: >> To have this list more organized, please assign a number to >> your support voice. It will make it easier to explain if >> comments are made about already mentioned use cases or new >> cases. If you have any specific concerns, there's separate >> thread for that. >> >> My understanding is that it helps if you are representing a >> large ISP, a vendor or someone else who has non-trivial >> impact on the industry. Voice of people, who express their >> personal opinions still count, but to a lesser degree. In terms of IETF process, that is not OK. We are individuals here, expressing individual engineering arguments. Nevertheless it is important to hear from practitioners and, excuse me for saying it, they are not here because they are fed up with waiting for the IETF. > To be clear, a use case is not "I want it because I think it > would be nice." It's "Router Advertisements don't work for > me for the following specific reason in my actual > deployment." > > The fact that it is the most requested feature isn't the > point. The question is, *why* is it the most requested > feature? Is it because people have zero operational > experience with IPv6, and are just trying to do the same > thing they did in IPv4, and once you explain RAs to them they > say "oh, okay" and stop asking for it? Or is it the case > that there is some genuine deployment problem that RAs don't > properly address? The people on the *real* IPv6 ops list who are asking for this are not beginners. But they *are* trying to do the same thing they did for IPv4, for a reason... > I'm also pragmatic. If we have to make this problem a > little bit worse to solve some real world problem, fine, > let's make the problem a little bit worse. But if we're > doing it because people think they have to have feature > parity with DHCPv4, that's just not a good enough reason. Tomek didn't define a way of assigning use case numbers, so I'll call this use case #42: Operators say that they want (approximate) feature parity so that they can have (approximate) alignment between their operational procedures for v4 and v6, especially in a dual stack network. I assert that this is a very good engineering reason, and it isn't for the IETF to get on its high horse and say that experienced operators don't know how to manage OPEX. I don't know whether my final comment belongs on this thread or the drawbacks thread, but it's clear that a strong constraint on any DHCPv6 option that overlaps in functionality with RA is that it must convey exactly the same semantics or a proper superset of the same semantics. If we do that, DHCPv6 will not undercut RA and a special algorithm for RA vs DHCPv6 conflict resolution will not be needed. Brian From Ted.Lemon@nominum.com Thu Nov 17 18:13:35 2011 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 6485D1F0C4D for ; Thu, 17 Nov 2011 18:13:35 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.568 X-Spam-Level: X-Spam-Status: No, score=-106.568 tagged_above=-999 required=5 tests=[AWL=0.031, 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 EzzjzLg7Eri6 for ; Thu, 17 Nov 2011 18:13:34 -0800 (PST) Received: from exprod7og103.obsmtp.com (exprod7og103.obsmtp.com [64.18.2.159]) by ietfa.amsl.com (Postfix) with ESMTP id 4B7DC1F0C34 for ; Thu, 17 Nov 2011 18:13:34 -0800 (PST) Received: from shell-too.nominum.com ([64.89.228.229]) (using TLSv1) by exprod7ob103.postini.com ([64.18.6.12]) with SMTP ID DSNKTsW/QSuZS4PmsUP+2pGCmo8wfSdNqxvY@postini.com; Thu, 17 Nov 2011 18:13:34 PST 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 91E091B82AD for ; Thu, 17 Nov 2011 18:13:20 -0800 (PST) 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 7E2EE19005D; Thu, 17 Nov 2011 18:13:19 -0800 (PST) (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.01.0339.001; Thu, 17 Nov 2011 18:13:19 -0800 From: Ted Lemon To: Keith Moore Thread-Topic: [mif] Server selection document is "band-aid" not solution Thread-Index: AQHMpM8ZeOJMqkjpCkunz3mHScTfw5WxD2cA//98ReyAAIe9gP//hMrwgAD/fAD///A+igAQ0UgA///XMME= Date: Fri, 18 Nov 2011 02:13:18 +0000 Message-ID: References: <4EC46D52.8030909@ogud.com>, <23E1BB1B-75C8-45E9-8CA3-2E3DC9B6DBC6@nominum.com>, <0B785F0F-F131-4C06-8B62-418B051EE79C@network-heretics.com> , <17DF2079-601E-4F84-8F0A-20ECF9FF1366@nominum.com>, <358A8E60-5BFA-444A-B781-718BC5EF89A7@network-heretics.com> In-Reply-To: <358A8E60-5BFA-444A-B781-718BC5EF89A7@network-heretics.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "mif@ietf.org" Subject: Re: [mif] Server selection document is "band-aid" not solution 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, 18 Nov 2011 02:13:35 -0000 On Nov 18, 2011, at 4:39 AM, "Keith Moore" wro= te: > Seriously, dual-facing servers are the implementation artifacts. It's an= accident that they work at all. Sorry, Keith, I'm having trouble parsing this. If you have a point to mak= e, it would help if it involved statements about things that work or don't = work, and explanations as to why, not characterizations of the origins of v= arious pieces of software and your opinion of their ontological status.= From Ted.Lemon@nominum.com Thu Nov 17 18:17:12 2011 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 6E8C61F0C5C for ; Thu, 17 Nov 2011 18:17:12 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.568 X-Spam-Level: X-Spam-Status: No, score=-106.568 tagged_above=-999 required=5 tests=[AWL=0.031, 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 dOLB+NpU9rzC for ; Thu, 17 Nov 2011 18:17:12 -0800 (PST) Received: from exprod7og110.obsmtp.com (exprod7og110.obsmtp.com [64.18.2.173]) by ietfa.amsl.com (Postfix) with ESMTP id A86AE1F0C34 for ; Thu, 17 Nov 2011 18:17:11 -0800 (PST) Received: from shell-too.nominum.com ([64.89.228.229]) (using TLSv1) by exprod7ob110.postini.com ([64.18.6.12]) with SMTP ID DSNKTsXAJxlvEaDj6n0IKdSjgNSM/Relsu/T@postini.com; Thu, 17 Nov 2011 18:17:11 PST 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 C28321B82AD for ; Thu, 17 Nov 2011 18:17:10 -0800 (PST) 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 B51DA19005D; Thu, 17 Nov 2011 18:17:10 -0800 (PST) (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.01.0339.001; Thu, 17 Nov 2011 18:17:10 -0800 From: Ted Lemon To: Brian E Carpenter Thread-Topic: [mif] Server selection document is "band-aid" not solution Thread-Index: AQHMpM8ZeOJMqkjpCkunz3mHScTfw5Ww4w+AgAAE1gD//5hqNIAB3BkA//+KU9U= Date: Fri, 18 Nov 2011 02:17:09 +0000 Message-ID: References: <4EC46D52.8030909@ogud.com> <916CE6CF87173740BC8A2CE44309696204192558@008-AM1MPN1-053.mgdnok.nokia.com>, <4EC479E0.6030704@gmail.com> <292CDFDE-32DE-43D9-83DD-86D3978F3EEF@nominum.com>, <4EC5B25C.7010903@gmail.com> In-Reply-To: <4EC5B25C.7010903@gmail.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "mif@ietf.org" Subject: Re: [mif] Server selection document is "band-aid" not solution 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, 18 Nov 2011 02:17:12 -0000 On Nov 18, 2011, at 9:18 AM, "Brian E Carpenter" wrote: > However these (and any other) host mechanisms need an initial set of addr= ess > pairs to try out and, in many cases, an order of preference in which to > try them. In some cases (but not all) DNS may be source of a set of > destination addresses, but it's only the routing system that can provide > a priori information about which address *pairs* are worth trying. Can you provide an example of a case where the routing system has the capac= ity to do this in a MIF setting where you have two interfaces connected to = separate administrative domains? I agree at least in principle that you m= ay be able to come up with some special case where you could decide on the = basis of some such information which pair to try first. However, I am pre= tty sure that a general solution will not be able to rely on whatever infor= mation source you rely on in whatever special case you cite. From Ted.Lemon@nominum.com Thu Nov 17 18:21:23 2011 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 29A9811E80BA for ; Thu, 17 Nov 2011 18:21:23 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.569 X-Spam-Level: X-Spam-Status: No, score=-106.569 tagged_above=-999 required=5 tests=[AWL=0.030, 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 5b-ZcDAVFGoj for ; Thu, 17 Nov 2011 18:21:22 -0800 (PST) Received: from exprod7og126.obsmtp.com (exprod7og126.obsmtp.com [64.18.2.206]) by ietfa.amsl.com (Postfix) with ESMTP id 474A911E80B5 for ; Thu, 17 Nov 2011 18:21:22 -0800 (PST) Received: from shell-too.nominum.com ([64.89.228.229]) (using TLSv1) by exprod7ob126.postini.com ([64.18.6.12]) with SMTP ID DSNKTsXBIak6mOyn8Qkw/9mqmrj4Q8oAOJKk@postini.com; Thu, 17 Nov 2011 18:21:22 PST 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 521711B82AD for ; Thu, 17 Nov 2011 18:21:21 -0800 (PST) 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 1D2A819005D; Thu, 17 Nov 2011 18:21:21 -0800 (PST) (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.01.0339.001; Thu, 17 Nov 2011 18:21:21 -0800 From: Ted Lemon To: Brian E Carpenter Thread-Topic: Use case 42 [Re: [mif] Use cases for draft-ietf-mif-dhcpv6-route-option needed] Thread-Index: AQHMpZLTS1PZbX9WuEWWXuh7s0xwpZWx5l4N Date: Fri, 18 Nov 2011 02:21:20 +0000 Message-ID: <83A7D27A-9036-4252-AC94-3A89125C961B@nominum.com> References: <282BBE8A501E1F4DA9C775F964BB21FE3EB78C3C98@GRFMBX704BA020.griffon.local> <916CE6CF87173740BC8A2CE44309696204193417@008-AM1MPN1-053.mgdnok.nokia.com>, <4EC512A2.2060509@gmail.com> <890A58CF-8EAD-4F92-9981-9B5AA07EBF00@nominum.com>, <4EC5B720.8020605@gmail.com> In-Reply-To: <4EC5B720.8020605@gmail.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "mif@ietf.org" Subject: Re: [mif] Use case 42 [Re: Use cases for draft-ietf-mif-dhcpv6-route-option needed] 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, 18 Nov 2011 02:21:23 -0000 On Nov 18, 2011, at 9:38 AM, "Brian E Carpenter" wrote: > Operators say that they want (approximate) feature parity so > that they can have (approximate) alignment between their > operational procedures for v4 and v6, especially in a dual stack > network. I assert that this is a very good engineering reason, > and it isn't for the IETF to get on its high horse and say that > experienced operators don't know how to manage OPEX. This is the exact use case Tomek cited, and is (some of us think) adequatel= y satisfied by a vendor-specific route option in the BBF and/or 3GPP vendor= option spaces. John was pretty sure that there was no demand for this fr= om Cablelabs, although I'd certainly be interested in hearing other opinion= s on this question. The question is whether there is some use case that justifies a general-pur= pose DHCPv6 option that would wind up being widely deployed and likely used= *instead* of RA in some network to which arbitrary nodes might need to con= nect. > I don't know whether my final comment belongs on this thread or > the drawbacks thread, but it's clear that a strong constraint on > any DHCPv6 option that overlaps in functionality with RA is that > it must convey exactly the same semantics or a proper superset > of the same semantics. If we do that, DHCPv6 will not undercut > RA and a special algorithm for RA vs DHCPv6 conflict resolution > will not be needed. It's difficult to see how we could ensure that this was true, since the DHC= Pv6 server and router might actually be operated by independent entities wi= th no coordination.= From brian.e.carpenter@gmail.com Thu Nov 17 19:20:10 2011 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 2D63E11E8097 for ; Thu, 17 Nov 2011 19:20:10 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.52 X-Spam-Level: X-Spam-Status: No, score=-103.52 tagged_above=-999 required=5 tests=[AWL=0.079, 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 9k8RPNO3tvcQ for ; Thu, 17 Nov 2011 19:20:09 -0800 (PST) Received: from mail-yx0-f172.google.com (mail-yx0-f172.google.com [209.85.213.172]) by ietfa.amsl.com (Postfix) with ESMTP id 6EF5A1F0C61 for ; Thu, 17 Nov 2011 19:20:09 -0800 (PST) Received: by yenq4 with SMTP id q4so2320933yen.31 for ; Thu, 17 Nov 2011 19:20:09 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=message-id:date:from:organization:user-agent:mime-version:to:cc :subject:references:in-reply-to:content-type :content-transfer-encoding; bh=WOvRoQ3VH1VRkr7V2UqmQsqpj4TZwHx3C0M8j4AhTD4=; b=k9I4oMdXkzBSqB/Z2Jet9v/fiUVJMhbl96U1sia8ix/2x6WENs8MMKftsaUvBLQE/2 MvXA/aHnUtqChJP2Qn/fFwxoZj/EhymtBZT7AfvYwp4PfKLQ+ZzA9dk9CrnKkUJDypwU pdMLtbnds+x4pl5CMorfNnKOdf7K/3eUP+9BM= Received: by 10.236.181.36 with SMTP id k24mr2056292yhm.11.1321586409104; Thu, 17 Nov 2011 19:20:09 -0800 (PST) Received: from [130.129.19.92] (dhcp-135c.meeting.ietf.org. [130.129.19.92]) by mx.google.com with ESMTPS id y1sm9720520anj.18.2011.11.17.19.20.06 (version=SSLv3 cipher=OTHER); Thu, 17 Nov 2011 19:20:08 -0800 (PST) Message-ID: <4EC5CEE0.4090001@gmail.com> Date: Fri, 18 Nov 2011 16:20:00 +1300 From: Brian E Carpenter Organization: University of Auckland User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: Ted Lemon References: <282BBE8A501E1F4DA9C775F964BB21FE3EB78C3C98@GRFMBX704BA020.griffon.local> <916CE6CF87173740BC8A2CE44309696204193417@008-AM1MPN1-053.mgdnok.nokia.com>, <4EC512A2.2060509@gmail.com> <890A58CF-8EAD-4F92-9981-9B5AA07EBF00@nominum.com>, <4EC5B720.8020605@gmail.com> <83A7D27A-9036-4252-AC94-3A89125C961B@nominum.com> In-Reply-To: <83A7D27A-9036-4252-AC94-3A89125C961B@nominum.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: "mif@ietf.org" Subject: Re: [mif] Use case 42 [Re: Use cases for draft-ietf-mif-dhcpv6-route-option needed] 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, 18 Nov 2011 03:20:10 -0000 On 2011-11-18 15:21, Ted Lemon wrote: > On Nov 18, 2011, at 9:38 AM, "Brian E Carpenter" wrote: >> Operators say that they want (approximate) feature parity so >> that they can have (approximate) alignment between their >> operational procedures for v4 and v6, especially in a dual stack >> network. I assert that this is a very good engineering reason, >> and it isn't for the IETF to get on its high horse and say that >> experienced operators don't know how to manage OPEX. > > This is the exact use case Tomek cited, and is (some of us think) adequately satisfied by a vendor-specific route option in the BBF and/or 3GPP vendor option spaces. John was pretty sure that there was no demand for this from Cablelabs, although I'd certainly be interested in hearing other opinions on this question. I didn't read it as the same, and in any case I fail to see how a solution with some special features for CATV or ADSL or UMTS can solve the general problem of distributing routing info to hosts in an arbitary network, very possibly connected by none of those specific technologies. In any case, three layers of subnet down from the WAN connection, I hope there will be nothing that is specific to the tye of WAN connection. This is not a technology-specfic requirement. > The question is whether there is some use case that justifies a general-purpose DHCPv6 option that would wind up being widely deployed and likely used *instead* of RA in some network to which arbitrary nodes might need to connect. I don't know how to say it clearer: the use case is any IPv6 network, such as an enterprise network, whose operator *chooses* to manage it using DHCPv6. It isn't for the IETF to decide for these operators, and a technology-specific "vendor" option is not going to solve the general purpose requirement. >> I don't know whether my final comment belongs on this thread or >> the drawbacks thread, but it's clear that a strong constraint on >> any DHCPv6 option that overlaps in functionality with RA is that >> it must convey exactly the same semantics or a proper superset >> of the same semantics. If we do that, DHCPv6 will not undercut >> RA and a special algorithm for RA vs DHCPv6 conflict resolution >> will not be needed. > > It's difficult to see how we could ensure that this was true, since the DHCPv6 server and router might actually be operated by independent entities with no coordination. Sorry, I wasn't quite clear then. I mean semantics in the sense that Dave Thaler raised - two different ways of conveying route preferences is a Bad Thing. Obvious, in a situation such as a homenet where you have uncoordinated sources of configuration, their actual contents may be inconsistent, which is why you need an overarching method of resolving inconsistency. But we need that anyway, regardless of RA vs DHCP. Brian From moore@network-heretics.com Thu Nov 17 19:22:17 2011 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 1FE4E11E8098 for ; Thu, 17 Nov 2011 19:22:17 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.344 X-Spam-Level: X-Spam-Status: No, score=-3.344 tagged_above=-999 required=5 tests=[AWL=0.255, 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 f5VgEwSEHOxN for ; Thu, 17 Nov 2011 19:22:16 -0800 (PST) Received: from out2.smtp.messagingengine.com (out2.smtp.messagingengine.com [66.111.4.26]) by ietfa.amsl.com (Postfix) with ESMTP id 439F811E8097 for ; Thu, 17 Nov 2011 19:22:16 -0800 (PST) Received: from compute2.internal (compute2.nyi.mail.srv.osa [10.202.2.42]) by gateway1.nyi.mail.srv.osa (Postfix) with ESMTP id ABD1820F56 for ; Thu, 17 Nov 2011 22:22:15 -0500 (EST) Received: from frontend1.nyi.mail.srv.osa ([10.202.2.160]) by compute2.internal (MEProxy); Thu, 17 Nov 2011 22:22:15 -0500 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d= messagingengine.com; h=subject:mime-version:content-type:from :in-reply-to:date:cc:content-transfer-encoding:message-id :references:to; s=smtpout; bh=WKzNphkamvSlz1FED6XzGlg4vIs=; b=Ph AIlB2zytTyjKJsu+Ya6ZghnebtSudTgXoDwj7JkTVcwbPK7BvFD4Yi4zoAHpFtyy iVaSb9YGIvNy1GZZrpASP1gs90z/miHfxh02Mr8RrHkq5/IWhdr9UTJu4Kkvw+yN iTBtNj9ESa+m/Y9frlffsgW+2yNiVDuAlCn3Nqrf0= X-Sasl-enc: /MeQvefjxPr9Oq/1MNfUW7N7dKRVxFD5T3g1gBIeK4Hs 1321586535 Received: from [192.168.1.16] (host65-16-145-177.birch.net [65.16.145.177]) by mail.messagingengine.com (Postfix) with ESMTPA id 8A3968E00D5; Thu, 17 Nov 2011 22:22:14 -0500 (EST) Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Keith Moore In-Reply-To: <4EC5B25C.7010903@gmail.com> Date: Thu, 17 Nov 2011 22:22:13 -0500 Content-Transfer-Encoding: quoted-printable Message-Id: <4D5AAF54-D994-450E-9059-6993ECD6A9D9@network-heretics.com> References: <4EC46D52.8030909@ogud.com> <916CE6CF87173740BC8A2CE44309696204192558@008-AM1MPN1-053.mgdnok.nokia.com>, <4EC479E0.6030704@gmail.com> <292CDFDE-32DE-43D9-83DD-86D3978F3EEF@nominum.com> <4EC5B25C.7010903@gmail.com> To: Brian E Carpenter X-Mailer: Apple Mail (2.1084) Cc: "mif@ietf.org" Subject: Re: [mif] Server selection document is "band-aid" not solution 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, 18 Nov 2011 03:22:17 -0000 On Nov 17, 2011, at 8:18 PM, Brian E Carpenter wrote: > Ted, >=20 > On 2011-11-17 17:54, Ted Lemon wrote: >> On Nov 17, 2011, at 11:05 AM, "Brian E Carpenter" = wrote: >>> I don't see how we could define a helpful API until the generic = problem >>> of scope is solved (see my previous message). We have no general way >>> for an application to know or describe the scope that applies to = itself and >>> the peer(s) it wants to talk to. >>=20 >> It seems to me that applications "knowing" what scope they want to = talk to is a very isolated special case. E.g., perhaps your set-top = box knows that it needs to go through your cable ISP's provisioning = domain to get streaming video. But generally speaking, your = application wants to connect through whatever provisioning domain works = best, which is something no provisioning domain can claim to know; it is = something only the host can determine. >=20 > Ultimately, only the hosts involved in a particular transaction can = discover > what works best for them, which is why SCTP, MPTCP and SHIM6/REAP were > invented, as well as happy-eyeballs. Well, ultimately, only the applications involved in a particular = transaction can discover these things, because what's good for one = application isn't necessarily good for another. Which is why trying to = make e.g. happy eyeballs into a general-purpose mechanism is probably a = poor idea. > However these (and any other) host mechanisms need an initial set of = address > pairs to try out and, in many cases, an order of preference in which = to > try them. In some cases (but not all) DNS may be source of a set of > destination addresses, but it's only the routing system that can = provide > a priori information about which address *pairs* are worth trying. That is certainly how it should be. Anything based on heuristics, in = the absence of routing information provided by the routing system, is = just a hack. Keith From moore@network-heretics.com Thu Nov 17 19:25:46 2011 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 4533711E80A5 for ; Thu, 17 Nov 2011 19:25:46 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.35 X-Spam-Level: X-Spam-Status: No, score=-3.35 tagged_above=-999 required=5 tests=[AWL=0.248, 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 uOWSaUIktWl4 for ; Thu, 17 Nov 2011 19:25:45 -0800 (PST) Received: from out2.smtp.messagingengine.com (out2.smtp.messagingengine.com [66.111.4.26]) by ietfa.amsl.com (Postfix) with ESMTP id 86CEF11E8097 for ; Thu, 17 Nov 2011 19:25:45 -0800 (PST) Received: from compute6.internal (compute6.nyi.mail.srv.osa [10.202.2.46]) by gateway1.nyi.mail.srv.osa (Postfix) with ESMTP id 40AC220E3B for ; Thu, 17 Nov 2011 22:25:45 -0500 (EST) Received: from frontend1.nyi.mail.srv.osa ([10.202.2.160]) by compute6.internal (MEProxy); Thu, 17 Nov 2011 22:25:45 -0500 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d= messagingengine.com; h=subject:mime-version:content-type:from :in-reply-to:date:cc:message-id:references:to; s=smtpout; bh=/PX 4FQYhJO+kZTr6xFWfApZSG/A=; b=p8vUNjn05PBqguESsiOLl8MzMWiz2AExDA/ jaCHV9+t8kJ3yfs/q4/PZY1AijjP7H47kAbsu/OT746Bzgrl9Op7P0sCMO2o8bqG Ere+su+TO7QIL17u5CdvKGGxscW63HSLiKH/VRup8KmFpXCXm2MJzvbLJFFDCZva oz9OgIeo= X-Sasl-enc: ZTAKkoU6mvj32Akq8MsPtGv1kG48pEdqBNo0mF26g54K 1321586744 Received: from [192.168.1.16] (host65-16-145-177.birch.net [65.16.145.177]) by mail.messagingengine.com (Postfix) with ESMTPA id 268568E013E; Thu, 17 Nov 2011 22:25:44 -0500 (EST) Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: multipart/alternative; boundary=Apple-Mail-183--317840142 From: Keith Moore In-Reply-To: <4EC5B720.8020605@gmail.com> Date: Thu, 17 Nov 2011 22:25:43 -0500 Message-Id: <005FBBC0-A025-4282-B7CF-3A37845135C0@network-heretics.com> References: <282BBE8A501E1F4DA9C775F964BB21FE3EB78C3C98@GRFMBX704BA020.griffon.local> <916CE6CF87173740BC8A2CE44309696204193417@008-AM1MPN1-053.mgdnok.nokia.com>, <4EC512A2.2060509@gmail.com> <890A58CF-8EAD-4F92-9981-9B5AA07EBF00@nominum.com> <4EC5B720.8020605@gmail.com> To: Brian E Carpenter X-Mailer: Apple Mail (2.1084) Cc: "mif@ietf.org" Subject: Re: [mif] Use case 42 [Re: Use cases for draft-ietf-mif-dhcpv6-route-option needed] 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, 18 Nov 2011 03:25:46 -0000 --Apple-Mail-183--317840142 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii On Nov 17, 2011, at 8:38 PM, Brian E Carpenter wrote: > Operators say that they want (approximate) feature parity so > that they can have (approximate) alignment between their > operational procedures for v4 and v6, especially in a dual stack > network. I assert that this is a very good engineering reason, > and it isn't for the IETF to get on its high horse and say that > experienced operators don't know how to manage OPEX. I agree that it's a good engineering reason, but it's not the only = factor that should be considered. A number of things were broken in = IPv4, and we'd like to not have those things become permanently a part = of the architecture. On the other hand, second-system effect is arguably one of the factors = that has delayed adoption of IPv6. We need to be aware that change = comes with a cost, even if it seems like a change for the better. That = doesn't mean to never make changes, it means consider the cost when = considering whether to make a change. Keith --Apple-Mail-183--317840142 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii
Operators say = that they want (approximate) feature parity so
that they can have = (approximate) alignment between their
operational procedures for v4 = and v6, especially in a dual stack
network. I assert that this is a = very good engineering reason,
and it isn't for the IETF to get on its = high horse and say that
experienced operators don't know how to = manage OPEX.

I agree that it's a = good engineering reason, but it's not the only factor that should be = considered.   A number of things were broken in IPv4, and we'd = like to not have those things become permanently a part of the = architecture.

On the other hand, second-system = effect is arguably one of the factors that has delayed adoption of IPv6. =   We need to be aware that change comes with a cost, even if it = seems like a change for the better.   That doesn't mean to never = make changes, it means consider the cost when considering whether to = make a = change.

Keith

= --Apple-Mail-183--317840142-- From brian.e.carpenter@gmail.com Thu Nov 17 19:26:13 2011 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 65E7511E80C4 for ; Thu, 17 Nov 2011 19:26:13 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.522 X-Spam-Level: X-Spam-Status: No, score=-103.522 tagged_above=-999 required=5 tests=[AWL=0.077, 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 LKxZgxaJkqxb for ; Thu, 17 Nov 2011 19:26:12 -0800 (PST) Received: from mail-yx0-f172.google.com (mail-yx0-f172.google.com [209.85.213.172]) by ietfa.amsl.com (Postfix) with ESMTP id D15A811E8097 for ; Thu, 17 Nov 2011 19:26:12 -0800 (PST) Received: by yenq4 with SMTP id q4so2326124yen.31 for ; Thu, 17 Nov 2011 19:26:12 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=message-id:date:from:organization:user-agent:mime-version:to:cc :subject:references:in-reply-to:content-type :content-transfer-encoding; bh=n0uZ1fH1fuyYPokY5ILEWj8ZQVKXp2k+x7137tmNMAM=; b=s7qASp0i3sO1Ldex6Ov+RmNrU5VmjIbOrZlyKdQj1jW+JKYvexEbqxb9Ljzo3zsBnl vNztNQ9fWCrF+aA07hbL+/Cc8JfRD1YG/vDC/xSRnsPyoAxZGoC+4GvhQwWvvJcVqImH tr4vY7CGO0RoQ13NDCz6/mOK+6yjcr4WC3QUA= Received: by 10.100.99.16 with SMTP id w16mr341442anb.22.1321586772499; Thu, 17 Nov 2011 19:26:12 -0800 (PST) Received: from [130.129.19.92] (dhcp-135c.meeting.ietf.org. [130.129.19.92]) by mx.google.com with ESMTPS id h28sm16683550ani.17.2011.11.17.19.26.10 (version=SSLv3 cipher=OTHER); Thu, 17 Nov 2011 19:26:11 -0800 (PST) Message-ID: <4EC5D04B.9080509@gmail.com> Date: Fri, 18 Nov 2011 16:26:03 +1300 From: Brian E Carpenter Organization: University of Auckland User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: Ted Lemon References: <4EC46D52.8030909@ogud.com> <916CE6CF87173740BC8A2CE44309696204192558@008-AM1MPN1-053.mgdnok.nokia.com>, <4EC479E0.6030704@gmail.com> <292CDFDE-32DE-43D9-83DD-86D3978F3EEF@nominum.com>, <4EC5B25C.7010903@gmail.com> In-Reply-To: Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: "mif@ietf.org" Subject: Re: [mif] Server selection document is "band-aid" not solution 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, 18 Nov 2011 03:26:13 -0000 On 2011-11-18 15:17, Ted Lemon wrote: > On Nov 18, 2011, at 9:18 AM, "Brian E Carpenter" wrote: >> However these (and any other) host mechanisms need an initial set of address >> pairs to try out and, in many cases, an order of preference in which to >> try them. In some cases (but not all) DNS may be source of a set of >> destination addresses, but it's only the routing system that can provide >> a priori information about which address *pairs* are worth trying. > > Can you provide an example of a case where the routing system has the capacity to do this in a MIF setting where you have two interfaces connected to separate administrative domains? I agree at least in principle that you may be able to come up with some special case where you could decide on the basis of some such information which pair to try first. However, I am pretty sure that a general solution will not be able to rely on whatever information source you rely on in whatever special case you cite. > Today? Probably not. But that doesn't mean it shouldn't be a goal. Things like knowing which egresses are subject to which ingress filters, for example, could be known to the border routers. Brian From Ted.Lemon@nominum.com Thu Nov 17 21:11:07 2011 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 3C3DF21F8BF4 for ; Thu, 17 Nov 2011 21:11:07 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.57 X-Spam-Level: X-Spam-Status: No, score=-106.57 tagged_above=-999 required=5 tests=[AWL=0.029, 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 YgUuPuQxZm0R for ; Thu, 17 Nov 2011 21:11:06 -0800 (PST) Received: from exprod7og118.obsmtp.com (exprod7og118.obsmtp.com [64.18.2.8]) by ietfa.amsl.com (Postfix) with ESMTP id 7C97521F8BF3 for ; Thu, 17 Nov 2011 21:11:06 -0800 (PST) Received: from shell-too.nominum.com ([64.89.228.229]) (using TLSv1) by exprod7ob118.postini.com ([64.18.6.12]) with SMTP ID DSNKTsXo6l8ftcZPvDTJjeakQ3hE43rTmVpW@postini.com; Thu, 17 Nov 2011 21:11:06 PST 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 954F61B82E4 for ; Thu, 17 Nov 2011 21:11:05 -0800 (PST) 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 886AE19005D; Thu, 17 Nov 2011 21:11:05 -0800 (PST) (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.01.0339.001; Thu, 17 Nov 2011 21:11:05 -0800 From: Ted Lemon To: Brian E Carpenter Thread-Topic: Use case 42 [Re: [mif] Use cases for draft-ietf-mif-dhcpv6-route-option needed] Thread-Index: AQHMpZLTS1PZbX9WuEWWXuh7s0xwpZWx5l4NgACWgQD//5jtxA== Date: Fri, 18 Nov 2011 05:11:05 +0000 Message-ID: <290FDB96-9329-4A97-997F-AEE9A665D4B7@nominum.com> References: <282BBE8A501E1F4DA9C775F964BB21FE3EB78C3C98@GRFMBX704BA020.griffon.local> <916CE6CF87173740BC8A2CE44309696204193417@008-AM1MPN1-053.mgdnok.nokia.com>, <4EC512A2.2060509@gmail.com> <890A58CF-8EAD-4F92-9981-9B5AA07EBF00@nominum.com>, <4EC5B720.8020605@gmail.com> <83A7D27A-9036-4252-AC94-3A89125C961B@nominum.com>, <4EC5CEE0.4090001@gmail.com> In-Reply-To: <4EC5CEE0.4090001@gmail.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "mif@ietf.org" Subject: Re: [mif] Use case 42 [Re: Use cases for draft-ietf-mif-dhcpv6-route-option needed] 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, 18 Nov 2011 05:11:07 -0000 On Nov 18, 2011, at 11:20 AM, "Brian E Carpenter" wrote: > I didn't read it as the same, and in any case I fail to see how > a solution with some special features for CATV or ADSL or UMTS > can solve the general problem of distributing routing info to > hosts in an arbitary network, very possibly connected by none of > those specific technologies. This is true. However, since the general problem is already nicely solved= by RAs, I don't see how it supports your position. > I don't know how to say it clearer: the use case is any IPv6 > network, such as an enterprise network, whose operator *chooses* > to manage it using DHCPv6. It isn't for the IETF to decide for > these operators, and a technology-specific "vendor" option is > not going to solve the general purpose requirement. It most certainly _is_ up to the IETF to decide whether we will standardize= some mechanism for doing this. Of course we can't stop them engineering ar= ound us, but I think they would have to be motivated by some use case that = RA *really doesn't address* before they'd go to that trouble. So what's t= hat use case? From Ted.Lemon@nominum.com Thu Nov 17 21:14:42 2011 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 968FC11E80C6 for ; Thu, 17 Nov 2011 21:14:42 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.57 X-Spam-Level: X-Spam-Status: No, score=-106.57 tagged_above=-999 required=5 tests=[AWL=0.029, 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 IBhcpg9E4cot for ; Thu, 17 Nov 2011 21:14:36 -0800 (PST) Received: from exprod7og103.obsmtp.com (exprod7og103.obsmtp.com [64.18.2.159]) by ietfa.amsl.com (Postfix) with ESMTP id DD3C911E8097 for ; Thu, 17 Nov 2011 21:14:35 -0800 (PST) Received: from shell-too.nominum.com ([64.89.228.229]) (using TLSv1) by exprod7ob103.postini.com ([64.18.6.12]) with SMTP ID DSNKTsXpuJU+MPVjYRKHg/GXTPotsQOfz6az@postini.com; Thu, 17 Nov 2011 21:14:35 PST 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 76AD31B82E4 for ; Thu, 17 Nov 2011 21:14:32 -0800 (PST) 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 68ACE19005D; Thu, 17 Nov 2011 21:14:32 -0800 (PST) (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.01.0339.001; Thu, 17 Nov 2011 21:14:32 -0800 From: Ted Lemon To: Brian E Carpenter Thread-Topic: [mif] Server selection document is "band-aid" not solution Thread-Index: AQHMpM8ZeOJMqkjpCkunz3mHScTfw5Ww4w+AgAAE1gD//5hqNIAB3BkA//+KU9WAAJlcgP//mDME Date: Fri, 18 Nov 2011 05:14:31 +0000 Message-ID: References: <4EC46D52.8030909@ogud.com> <916CE6CF87173740BC8A2CE44309696204192558@008-AM1MPN1-053.mgdnok.nokia.com>, <4EC479E0.6030704@gmail.com> <292CDFDE-32DE-43D9-83DD-86D3978F3EEF@nominum.com>, <4EC5B25C.7010903@gmail.com> , <4EC5D04B.9080509@gmail.com> In-Reply-To: <4EC5D04B.9080509@gmail.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "mif@ietf.org" Subject: Re: [mif] Server selection document is "band-aid" not solution 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, 18 Nov 2011 05:14:42 -0000 On Nov 18, 2011, at 11:26 AM, "Brian E Carpenter" wrote: > Today? Probably not. But that doesn't mean it shouldn't be a > goal. Things like knowing which egresses are subject to which > ingress filters, for example, could be known to the border routers. I am skeptical that my hotel will get this right. And they _do_ typically= have egress filters. So it seems like a shaky foundation upon which to b= ase a general solution. From alexandru.petrescu@gmail.com Fri Nov 18 02:37:32 2011 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 5947D21F8AB8 for ; Fri, 18 Nov 2011 02:37:32 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.019 X-Spam-Level: X-Spam-Status: No, score=-6.019 tagged_above=-999 required=5 tests=[AWL=-0.370, BAYES_00=-2.599, HELO_EQ_FR=0.35, J_CHICKENPOX_13=0.6, 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 zedmgAVOayYZ for ; Fri, 18 Nov 2011 02:37:31 -0800 (PST) Received: from oxalide-out.extra.cea.fr (oxalide-out.extra.cea.fr [132.168.224.8]) by ietfa.amsl.com (Postfix) with ESMTP id BE8B521F8AAF for ; Fri, 18 Nov 2011 02:37:30 -0800 (PST) Received: from pisaure.intra.cea.fr (pisaure.intra.cea.fr [132.166.88.21]) by oxalide.extra.cea.fr (8.14.2/8.14.2/CEAnet-Internet-out-2.2) with ESMTP id pAIAbSu8019479 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT) for ; Fri, 18 Nov 2011 11:37:28 +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 pAIAbS4L004151 for ; Fri, 18 Nov 2011 11:37:28 +0100 (envelope-from alexandru.petrescu@gmail.com) Received: from [127.0.0.1] ([132.166.133.173]) by muguet1.intra.cea.fr (8.13.8/8.13.8/CEAnet-Intranet-out-1.1) with ESMTP id pAIAbOua014557 for ; Fri, 18 Nov 2011 11:37:27 +0100 Message-ID: <4EC63564.4080101@gmail.com> Date: Fri, 18 Nov 2011 11:37:24 +0100 From: Alexandru Petrescu User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:8.0) Gecko/20111105 Thunderbird/8.0 MIME-Version: 1.0 To: mif@ietf.org References: <282BBE8A501E1F4DA9C775F964BB21FE3EB78C3C98@GRFMBX704BA020.griffon.local> <916CE6CF87173740BC8A2CE44309696204193417@008-AM1MPN1-053.mgdnok.nokia.com> <4EC512A2.2060509@gmail.com> In-Reply-To: <4EC512A2.2060509@gmail.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Subject: Re: [mif] Use cases for draft-ietf-mif-dhcpv6-route-option needed 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, 18 Nov 2011 10:37:32 -0000 Le 17/11/2011 14:56, Tomek Mrugalski a écrit : > Hi, There was a meeting between proponents of this option, most vocal > opponets, MIF chairs, DHC chairs and two ADs and several other > knowledgeable people. > > The conclusion of this meeting was that to proceed with route option > forward, specific use cases are needed. If you need this option, > please describe your use case. I pick one use-case I am particularly concerned with: router device with limited memory and CPU MHz connected to low-rate cellular forced into using both DHCP and RA software. It would better use only one software implementation (not 2), and do a short exchanges of messages (4 messages instead of 6) to obtain: default route, prefix, address, DNS server. In this sense, it would be advantageous if DHCP provided a default route and optionally with a MAC address. Other use-cases relate to Mobile Routers in vehicular environments, that one could describe when necessary. > If you assume that others will raise support for you, you may be in > for a surprise. > > If this does not get enough documented, valid use cases, it seems > that this option will not be standardized, at least not in IETF. > > Aternative solution discussed was to convey this using > vendor-specific option (possibly within a body other than IETF); > change the format to explicitly disallow default route. From my > perspective (DHCP vendor) those approaches makes this solution much > more difficult to deploy, often even preventing it completely. I would support a decision where the default route is stripped off of the route-option draft and where it is given focused consideration in a single draft. The reason for this is that default route has a number of particular characteristics different than a specific (or generic) route: it is all-zeros prefix 0, its metric in table is typically 1, its lifetime treatment depends largely on ND, its reliability needs to be properly ensured by re-requesting coherently with ND, and more. > To have this list more organized, please assign a number to your > support voice. Sorry, please explain? What number should I assign to my voice? Do you want to assign a preference number between: - vendor-specific option - document use-cases? > It will make it easier to explain if comments are made about already > mentioned use cases or new cases. If you have any specific concerns, > there's separate thread for that. > > My understanding is that it helps if you are representing a large > ISP, a vendor or someone else who has non-trivial impact on the > industry. Voice of people, who express their personal opinions still > count, but to a lesser degree. I count my voice to count to a lesser degree. > Here's the initial list of use cases. > > 1. http://www.ietf.org/mail-archive/web/mif/current/msg01412.html On > 11-11-16 08:59, Maglione Roberta wrote: >> Hello, during the meeting the chairs and many people asked about >> use cases and motivations for this work: as I quickly mentioned at >> the mic there is a draft in v6ops > > 2. http://www.ietf.org/mail-archive/web/mif/current/msg01428.html On > 11-11-17 19:14, teemu.savolainen@nokia.com wrote: >> +1 >> >> I have to add I'm now quite confused why we are even having these >> motivation discussions, as the charter was already agreed quite >> some time ago. We are actually even late: -- Jun 2011 - Submit >> DHCPv6 routing configuration option to IESG for publication as a >> Proposed Standard RFC -- >> >> We should focus on technical issues to complete the spec, like the >> semantics. Not to spend time repeating old discussions. > > 3. Regarding motivation for real users, ISC is a DHCP vendor (client, > server, relay). Our software is installed as a default client and > server in many Linux and BSD distributions. Many of our customers and > users request this feature. I can't explain each deployment model, > but the commonly mentioned reason was simpler deployment and > manageability. The latest ISC code supports route-option-03, but I'm > not sure if it does matter or not. > > 4. I'm also author and developer of Dibbler, an open source DHCPv6 > implementation (client, server, relay). This code works on Windows, > Linux, Mac OS X, and most types of BSDs. There are users, who request > this. Request for routing configuration (default route in particular) > is the number one question asked througout the years. There is at > least one ISP in Poland that wants (i.e. "already uses Dibbler and > requests routing configuration") to deploy this feature. The latest > version of Dibbler does support this route-option-03, but again I'm > not sure if it matters or not. > > I admit that depending on your perspective this may be considered as > a valid vendor (Dibbler has been around for 8 years, existing > community, deployed in some production environments) or not (open > source project without any real money behind it). > > I looked around and found the following other supporting voices. As I > don't have operational experience, it would be great if the original > proponents or commenters could go forward and explain their use > cases. > > - Previous attempt to introduce very similar was proposed by Thomas > Narten and Ralph Droms. Both were present during meeting and if I > understand correctly, their reason to drop this work was because > there was no substantial need for it last time (this was around > 2009). Here's a link to their presentation: > http://www.ietf.org/proceedings/74/slides/intarea-4.pdf It should be > noted that some open issues (slide 8) are now resolved. > > - Wojciech Dec (Cisco) provided several usage models. I can't speak > on behalf of Cisco, but can only assume that they have reasonable > need for such feature. I'm sure Wojciech will provide detailed usage > case soon. > > - In previous versions of this draft, there were several more use > cases described: > http://tools.ietf.org/html/draft-dec-dhcpv6-route-option-01 > http://tools.ietf.org/html/draft-dec-dhcpv6-route-option-02 They > were removed based on MIF WG feedback. > > - This draft is a result of a merge of 3 other drafts > (draft-sarikaya-mif-dhcpv6solution, > draft-sun-mif-address-policy-dhcp6 and > draft-dec-dhcpv6-route-option). Present and former authors represent > the following companies: Cisco, Huawei, China Mobile, Orange France > Telecom and NTT PF Labs. Previous attempt to introduce similar > option (draft-droms-dhc-dhcpv6-default-router-00) was undertaken by > employees of Cisco and IBM. If you are one of authors, it would be > great if you could step forward and explain your usage models and > why you need this. Also, if you decided that this work is no longer > relevant or was dropped, explaining the reasons would be very > useful. I am not an author of these drafts. I am a co-author of draft-mouton-mif-dhcpv6-drlo-00. > There is a draft "IPv6 Multihoming without Network Address > Translation" in v6ops > (draft-ietf-v6ops-ipv6-multihoming-without-ipv6nat-03). It > recommends use of this option. Again, if you are an author of this > draft, could you please explain why you need this. > > We should also take into consideration people who were physically > attending in MIF meeting. Significant majority of people (around 20) > offered their support for this draft, while only 6 were against it. > Similar support was voiced during adoption of this document in MIF. > If you are one of those people, please express your support now. > > To have a balanced discussion on this topic, I will create one more > thread regarding flaws and possible dangers of finishing this work, > with comments from two opponents. Feel free to contribute your > concerns. > > On a presonal note, my involvement in this work is on hold until this > issue is resolved. Sorry, which issue? They seem a list of issues? Alex > > Cheers, Tomek Mrugalski ISC > _______________________________________________ mif mailing list > mif@ietf.org https://www.ietf.org/mailman/listinfo/mif > From alexandru.petrescu@gmail.com Fri Nov 18 02:50:55 2011 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 2789F21F8A69 for ; Fri, 18 Nov 2011 02:50:55 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.288 X-Spam-Level: X-Spam-Status: No, score=-6.288 tagged_above=-999 required=5 tests=[AWL=-0.039, 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 sBZxKf8ZfbeN for ; Fri, 18 Nov 2011 02:50:53 -0800 (PST) Received: from sainfoin-out.extra.cea.fr (sainfoin-out.extra.cea.fr [132.167.192.144]) by ietfa.amsl.com (Postfix) with ESMTP id 603E621F8A62 for ; Fri, 18 Nov 2011 02:50:53 -0800 (PST) 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.2) with ESMTP id pAIAopi0010426 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT) for ; Fri, 18 Nov 2011 11:50:51 +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 pAIAooWO010282 for ; Fri, 18 Nov 2011 11:50:50 +0100 (envelope-from alexandru.petrescu@gmail.com) Received: from [127.0.0.1] ([132.166.133.173]) by muguet2.intra.cea.fr (8.13.8/8.13.8/CEAnet-Intranet-out-1.1) with ESMTP id pAIAokNs021332 for ; Fri, 18 Nov 2011 11:50:50 +0100 Message-ID: <4EC63886.6050806@gmail.com> Date: Fri, 18 Nov 2011 11:50:46 +0100 From: Alexandru Petrescu User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:8.0) Gecko/20111105 Thunderbird/8.0 MIME-Version: 1.0 To: mif@ietf.org References: <4EC5133D.3050508@gmail.com> In-Reply-To: <4EC5133D.3050508@gmail.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Subject: Re: [mif] Concerns regarding draft-ietf-mif-dhcpv6-route-option 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, 18 Nov 2011 10:50:55 -0000 Le 17/11/2011 14:59, Tomek Mrugalski a écrit : > Hi, This thread is about concerns regarding > draft-ietf-mif-dhcpv6-route-option. At the moment this thead was > started, the latest version is -03. See response to concern 3 below > for proposed changes planned for -04. They will be implemented if > the decision is made to continue this work. The latest presentation > about this work was presented in DHC. It differs significantly > compared to what was presnted in MIF. The major changes are: - option > format to be unified to match RA - options from RA and DHCP do not > override each other, but are merged instead (data delivered over DHCP > are functional equivalent of receiving yet another RA). > > The goal of this thread and its "in favor" counter-part is to get > input for chairs, ADs and possibly whole IESG whether work on route > option should continue or not. > > There was substantial discussion during last MIF meeting, with > follow-ups off the list. I tried to assemble major concerns raised. > I'm sorry if I missed anything. If you want to expand this list, > please add a number for easier reference. > > On 11-11-16 17:14, Stuart Cheshire wrote: >> Some of my concerns with the DHCPv6 route option are: >> >> 1. It duplicates what RA already does. I do not like duplication. >> It is *more* than double the work, because not only do you have to >> implement two things, you also have to worry about how those two >> things interact. Testing is more than twice as hard. Instead of >> just testing RA, now you have to test RA alone, DHCPv6 route option >> alone, and RA + DHCPv6 together. > Tomek's comment: You can choose to: - not support DHCPv6 at all > (using RA-only) - use DHCPv6, but not request route options (and keep > using RA) - use DHCPv6, request route options and use RA There should be a 4th possible way: - use DHCPv6 and not use RA. > Only the third option has the properties that you describe. I do not > think that vendors suddenly jump to route option, start producing > CPEs that use DHCP only and stop announcing RA. (therefore I haven't > mentioned 4th option: use DHCPv6 exclusively and do not support RA) > > Stuart's answer: This sounds intentionally naïve about how standards > evolve. The existence of two different sanctioned ways of doing > things means that some vendors (and network operators) will do things > one way and other vendors (and network operators) will do things the > other way, and user pain will result. In this particular case, I believe a number of vendors currently deploy both DHCPv6 and RA in some devices. I do not see conflict shaping up until we mention default route. In the past, similar conflict shaped up with DNS server (provide with DHCP vs RA), and solved with lists of preferences. > Wojciech's answer: Fair point, but the alternatives cause pain for > the network operator. A balance needs to be found, and that balance > does not appear to involve "loose DHCP" or "loose RAs". Developing > towards an eco-system of "user and his device" and > "no-one-else-matters" is also sounding intentionally naive. > > Stuart's comment #2: That sounds suspiciously like an attempt to > bully and blackmail client vendors into having to do extra > development, testing and support work that they did not willingly > consent to, for someone else's convenience. > > Wojciech's response to #2: That plays both ways: Having a client > vendor's convenience that forces network operators to change how they > run their business, and support also looks like bullying. The balance > appears to be in the middle. > >> 2. Its syntax and semantics are different to RA. If we're going to >> duplicate RA, at least keep it as similar as possible. > Tomek's answer: Agree. If we decide to continue work on this, I'll > work with Dave Thaler on unifying format and conveyed information > between RA and route option. Would you like to review a draft version > before we publish it as -04? Sorry for interfering - I would like to if possible. >> 3. Rather than overriding RA, DHCPv6 route option data should >> merge in with other RA data. > Tomek's answer: I wasn't very clear in my presentation. My proposal > about favoring DHCP was only in case of conflicting route entries. Tomek, this may sound too strong. DHCPv6 default route is a new thing; text recognizing the reality of existing (RA default route) base should prevail now. Indicating otherwise provokes negative reaction. As time goes, implementations may head towards DHCPv6 default route, or not. Standards Track, Draft Standard, BCP - are much recognition of existing reality at their respective time. > Discussion during presentation and many follow-ups showed that this > approach would work in some cases, but not in all. I think we should > consider following changes to -03: > > a. explain in which conditions this will not work, describe them and > keep the preference as was proposed. Note that the approach of > delivering RA to all hosts and then override for some hosts on a per > hosts basis is a valid argument in favor of this approach. It seems > that at this stage this would exclude homenet from deploying this > mechanism (but please see point 5. below). Lorenzo Colitti (Google) > noted that applicability statements do not prevent anything and are > often ignored. > > b. merge data between DHCP and RA. From OS perspective the route > provisioning over DHCP could be roughly perceived as reception of > yet another RA, with equal treating. YEs, I agree with this, implementation at hand. Our implementation of DHCP default route merges DHCP data into ND data structures. >> 4. Speaking as an employee of one of the client vendors, I have >> not seen any compelling argument why we should have to do a bunch >> of extra work to satisfy some other unspecified people. > There is dedicated thread for support voices. > > 5. (new point). There is another problem raised by Lorenzo and > further expanded by Ted Lemon that manifests itself in homenet > deployment (but possibly could affect other deployments as well). In > homenet architecture, one of the deployment models is one LAN network > with 2 CPEs that connect to 2 different ISPs. If those CPE also offer > DHCP, client will choose only one advertise and completely ignore the > second. In case of failure of this CPE, client doesn't have any > ability to learn the other set of parameter that the second DHCP > server would have provided. That is general problem of DHCP protocol > and affects all other options that DHCP can provide (including > addresses, delegated prefixes, and options like DNS or routing). Ted > Lemon started working on this problem. See presentation about DHCPv6 > and Multihoming problem statement in DHC WG. Presentation is not up > yet, but hopefully it will appear here: > http://tools.ietf.org/agenda/82/dhc.html > > 6. Doom of RA. Lorenzo Colitti described set of events that he > predicts will happen that will eventually lead to a collapse of the > whole RA model. As a vendor of mobile devices, he afraids that once > route option is defined, some CPE vendors will adopt it. This will > force mobile device vendors to support route option. Once it becomes > more popular, some CPE vendors may decide to stop announcing RA. This > will enable operation without RA. Not needing it, RA will become > essentially obsolete. This in turn will make the benefits of dynamic > configuration offered by RA and put us back with static configuration > that is known from IPv4. I can't comment on feasibility of this > scenario as I don't have operational experience. During follow up > discussions, several people pointed out that this is an excessively > pessimistic scenario. DHCPv4 is probably the only widespread auto-configuration mechanism used to manage large networks, thanks to its centralized database and distributed relays. For IPv6, I am not aware of such widespread auto-configuration mechanism (free IPv6 doesn't use DHCPv6 but some different 6rd relying on IPv4). It may be possible that DHCPv6 will be grown to manage large IPv6 networks as well. Alex > Please add your favourite reason, why this option should not be > deployed here. On the other hand, if you are supporter of this > option, there is a separate thread for this as well. > > On a presonal note, my involvement in this work is on hold until > this issue is resolved. > > Cheers, Tomek Mrugalski ISC > > _______________________________________________ mif mailing list > mif@ietf.org https://www.ietf.org/mailman/listinfo/mif > From alexandru.petrescu@gmail.com Fri Nov 18 03:14:53 2011 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 6287C21F8B07 for ; Fri, 18 Nov 2011 03:14:53 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.285 X-Spam-Level: X-Spam-Status: No, score=-6.285 tagged_above=-999 required=5 tests=[AWL=-0.036, 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 C1eFSRtoG3gk for ; Fri, 18 Nov 2011 03:14:52 -0800 (PST) Received: from cirse-out.extra.cea.fr (cirse-out.extra.cea.fr [132.167.192.142]) by ietfa.amsl.com (Postfix) with ESMTP id 57AF821F8B04 for ; Fri, 18 Nov 2011 03:14:52 -0800 (PST) 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.2) with ESMTP id pAIBEoIt004716 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT) for ; Fri, 18 Nov 2011 12:14:50 +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 pAIBEoFV021926 for ; Fri, 18 Nov 2011 12:14:50 +0100 (envelope-from alexandru.petrescu@gmail.com) Received: from [127.0.0.1] ([132.166.133.173]) by muguet2.intra.cea.fr (8.13.8/8.13.8/CEAnet-Intranet-out-1.1) with ESMTP id pAIBEkUu004788 for ; Fri, 18 Nov 2011 12:14:50 +0100 Message-ID: <4EC63E26.70104@gmail.com> Date: Fri, 18 Nov 2011 12:14:46 +0100 From: Alexandru Petrescu User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:8.0) Gecko/20111105 Thunderbird/8.0 MIME-Version: 1.0 To: mif@ietf.org References: <282BBE8A501E1F4DA9C775F964BB21FE3EB78C3C98@GRFMBX704BA020.griffon.local> <916CE6CF87173740BC8A2CE44309696204193417@008-AM1MPN1-053.mgdnok.nokia.com>, <4EC512A2.2060509@gmail.com> <890A58CF-8EAD-4F92-9981-9B5AA07EBF00@nominum.com> In-Reply-To: <890A58CF-8EAD-4F92-9981-9B5AA07EBF00@nominum.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Subject: Re: [mif] Use cases for draft-ietf-mif-dhcpv6-route-option needed 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, 18 Nov 2011 11:14:53 -0000 Le 17/11/2011 21:04, Ted Lemon a écrit : > On Nov 17, 2011, at 9:57 PM, "Tomek > Mrugalski" wrote: >> To have this list more organized, please assign a number to your >> support voice. It will make it easier to explain if comments are >> made about already mentioned use cases or new cases. If you have >> any specific concerns, there's separate thread for that. >> >> My understanding is that it helps if you are representing a large >> ISP, a vendor or someone else who has non-trivial impact on the >> industry. Voice of people, who express their personal opinions >> still count, but to a lesser degree. > > To be clear, a use case is not "I want it because I think it would be > nice." It's "Router Advertisements don't work for me for the > following specific reason in my actual deployment." I agree with the clarification. But don't scare people away with the word "deployment". Initial deployments are often just lab settings, a desk, a pocket sometimes. RA defroutes don't work for me because there may be not enough memory space next to the DHCP daemon on a 400MHz ARM processor of mobile router. Would something like this qualify? > The fact that it is the most requested feature isn't the point. The > question is, *why* is it the most requested feature? Is it because > people have zero operational experience with IPv6, and are just > trying to do the same thing they did in IPv4, and once you explain > RAs to them they say "oh, okay" and stop asking for it? No, it is not this reason for me. In my particular case I am fully aware of RAs offering defroute, and aware of DHCPv4 and DHCPv6 Relays. In my lab setting it is easier to maintain de conf files centrally on a unique machine rather than on 5-like Access Routers. I do not have a std mechanism to remotely update the RA information these Access Routers offer. But for DHCP I have this central conf file. > Or is it the case that there is some genuine deployment problem that > RAs don't properly address? > > The reason why the vendor option solution was proposed is that the > only use cases that anybody could actually come up with in the > meeting yesterday were use cases that were specific to particular ISP > deployment models, and it seemed clear that these use cases could be > adequately addressed with 3GPP- and BBF-specific extensions. There is > genuine need in these two cases for this functionality. I do not work for a vendor. I don't see why calling the DHCP defroute a "vendor" option. On another hand I could agree with it being EXPERIMENTAL at this point in time. > The reason why this isn't a no-brainer is that if it were added as a > standard IETF solution, it would change what end nodes have to do to > get routes, making end node software more complicated, and also more > difficult to specify. As one of the authors of the MIF API > document, I've had to think a lot about this problem, and I do not > like having to have two different ways of configuring routes. The > MIF problem is hard enough already; adding this to the problem seems > to me to make it worse, not better. > > I'm also pragmatic. If we have to make this problem a little bit > worse to solve some real world problem, fine, let's make the problem > a little bit worse. But if we're doing it because people think > they have to have feature parity with DHCPv4, that's just not a good > enough reason. In my particular case parity with DHCPv4 is not the need. I am fully aware of RA having already implemented a number of features of it. Yours, Alex > > _______________________________________________ mif mailing list > mif@ietf.org https://www.ietf.org/mailman/listinfo/mif > From alexandru.petrescu@gmail.com Fri Nov 18 03:17:36 2011 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 033EA21F8B13 for ; Fri, 18 Nov 2011 03:17:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.283 X-Spam-Level: X-Spam-Status: No, score=-6.283 tagged_above=-999 required=5 tests=[AWL=-0.034, 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 BJoSVOnDt8-j for ; Fri, 18 Nov 2011 03:17:35 -0800 (PST) Received: from sainfoin-out.extra.cea.fr (sainfoin-out.extra.cea.fr [132.167.192.144]) by ietfa.amsl.com (Postfix) with ESMTP id DB9C021F8B11 for ; Fri, 18 Nov 2011 03:17:34 -0800 (PST) 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.2) with ESMTP id pAIBHYnl020289 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT) for ; Fri, 18 Nov 2011 12:17:34 +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 pAIBHXCd022688 for ; Fri, 18 Nov 2011 12:17:33 +0100 (envelope-from alexandru.petrescu@gmail.com) Received: from [127.0.0.1] ([132.166.133.173]) by muguet2.intra.cea.fr (8.13.8/8.13.8/CEAnet-Intranet-out-1.1) with ESMTP id pAIBHVia005976 for ; Fri, 18 Nov 2011 12:17:33 +0100 Message-ID: <4EC63ECC.8010700@gmail.com> Date: Fri, 18 Nov 2011 12:17:32 +0100 From: Alexandru Petrescu User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:8.0) Gecko/20111105 Thunderbird/8.0 MIME-Version: 1.0 To: mif@ietf.org References: <282BBE8A501E1F4DA9C775F964BB21FE3EB78C3C98@GRFMBX704BA020.griffon.local> <916CE6CF87173740BC8A2CE44309696204193417@008-AM1MPN1-053.mgdnok.nokia.com>, <4EC512A2.2060509@gmail.com> <890A58CF-8EAD-4F92-9981-9B5AA07EBF00@nominum.com>, <4EC5B720.8020605@gmail.com> <83A7D27A-9036-4252-AC94-3A89125C961B@nominum.com> In-Reply-To: <83A7D27A-9036-4252-AC94-3A89125C961B@nominum.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Subject: Re: [mif] Use case 42 [Re: Use cases for draft-ietf-mif-dhcpv6-route-option needed] 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, 18 Nov 2011 11:17:36 -0000 Le 18/11/2011 03:21, Ted Lemon a écrit : > On Nov 18, 2011, at 9:38 AM, "Brian E > Carpenter" wrote: >> Operators say that they want (approximate) feature parity so that >> they can have (approximate) alignment between their operational >> procedures for v4 and v6, especially in a dual stack network. I >> assert that this is a very good engineering reason, and it isn't >> for the IETF to get on its high horse and say that experienced >> operators don't know how to manage OPEX. > > This is the exact use case Tomek cited, and is (some of us think) > adequately satisfied by a vendor-specific route option in the BBF > and/or 3GPP vendor option spaces. John was pretty sure that there > was no demand for this from Cablelabs, although I'd certainly be > interested in hearing other opinions on this question. > > The question is whether there is some use case that justifies a > general-purpose DHCPv6 option that would wind up being widely > deployed and likely used *instead* of RA in some network to which > arbitrary nodes might need to connect. MAchine-type router devices do need DHCP software for its prefix delegation feature and are forced to use RA for its defroute feature. Yet they're constrained devices preferring to send less messages. Alex > >> I don't know whether my final comment belongs on this thread or the >> drawbacks thread, but it's clear that a strong constraint on any >> DHCPv6 option that overlaps in functionality with RA is that it >> must convey exactly the same semantics or a proper superset of the >> same semantics. If we do that, DHCPv6 will not undercut RA and a >> special algorithm for RA vs DHCPv6 conflict resolution will not be >> needed. > > It's difficult to see how we could ensure that this was true, since > the DHCPv6 server and router might actually be operated by > independent entities with no coordination. > _______________________________________________ mif mailing list > mif@ietf.org https://www.ietf.org/mailman/listinfo/mif > From Fred.L.Templin@boeing.com Fri Nov 18 12:38:18 2011 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 0746921F84C9 for ; Fri, 18 Nov 2011 12:38:18 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.749 X-Spam-Level: X-Spam-Status: No, score=-6.749 tagged_above=-999 required=5 tests=[AWL=-0.150, 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 4mqBi8gTvv2t for ; Fri, 18 Nov 2011 12:38:17 -0800 (PST) Received: from blv-smtpout-01.boeing.com (blv-smtpout-01.boeing.com [130.76.32.69]) by ietfa.amsl.com (Postfix) with ESMTP id 7BDD921F84C3 for ; Fri, 18 Nov 2011 12:38:17 -0800 (PST) Received: from blv-av-01.boeing.com (blv-av-01.boeing.com [130.247.48.231]) by blv-smtpout-01.ns.cs.boeing.com (8.14.4/8.14.4/8.14.4/SMTPOUT) with ESMTP id pAIKc7D4027984 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL) for ; Fri, 18 Nov 2011 12:38:15 -0800 (PST) Received: from blv-av-01.boeing.com (localhost [127.0.0.1]) by blv-av-01.boeing.com (8.14.4/8.14.4/DOWNSTREAM_RELAY) with ESMTP id pAIKc7eE028025 for ; Fri, 18 Nov 2011 12:38:07 -0800 (PST) Received: from XCH-NWHT-09.nw.nos.boeing.com (xch-nwht-09.nw.nos.boeing.com [130.247.25.115]) by blv-av-01.boeing.com (8.14.4/8.14.4/UPSTREAM_RELAY) with ESMTP id pAIKc7qu028017 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=OK) for ; Fri, 18 Nov 2011 12:38:07 -0800 (PST) Received: from XCH-NW-01V.nw.nos.boeing.com ([130.247.64.97]) by XCH-NWHT-09.nw.nos.boeing.com ([130.247.25.115]) with mapi; Fri, 18 Nov 2011 12:38:07 -0800 From: "Templin, Fred L" To: "mif@ietf.org" Date: Fri, 18 Nov 2011 12:38:06 -0800 Thread-Topic: IRON as a multiple interface solution Thread-Index: Acyl47ekZfkZT4I0Tz2nzbp32pI9zwASbcTA Message-ID: References: <282BBE8A501E1F4DA9C775F964BB21FE3EB78C3C98@GRFMBX704BA020.griffon.local> <916CE6CF87173740BC8A2CE44309696204193417@008-AM1MPN1-053.mgdnok.nokia.com>, <4EC512A2.2060509@gmail.com> <890A58CF-8EAD-4F92-9981-9B5AA07EBF00@nominum.com>, <4EC5B720.8020605@gmail.com> <83A7D27A-9036-4252-AC94-3A89125C961B@nominum.com> <4EC63ECC.8010700@gmail.com> In-Reply-To: <4EC63ECC.8010700@gmail.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: [mif] IRON as a multiple interface solution 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, 18 Nov 2011 20:38:18 -0000 Hi, A new routing and addressing system known as the Internet Routing Overlay Network (IRON) is available that (among many other things) supports hosts with multiple interfaces. IRON (along with its associated mechanisms VET and SEAL) uses a tunnel virtul interface to harness the host's ISP interfaces into a "bundle" that is represented to a server in the Internet. The tunnel interface assigns a single, stable IP address that host applications can use regardless of the ISP connection or connections used to carry traffic. The server is responsible for representing the host's stable IP address into the Internet routing system. The host is responsible for selecting ISP interfaces for outbound packets, and for providing directions to the server as to ISP interfaces to use for inbound packets. Traffic engineering, load balancing, fault tolerance, asymmetric routing, etc. are all therefore naturally supported. Mobility and NAT traversal are also naturally supported. The solution also supports the case of the host receiving an IP prefix instead of just a singleton IP address and then beginning to function as a router. Please see below for the documents and send comments: http://www.ietf.org/internet-drafts/draft-templin-ironbis-08.txt http://www.ietf.org/internet-drafts/draft-templin-intarea-vet-31.txt http://www.ietf.org/internet-drafts/draft-templin-intarea-seal-39.txt Thanks - Fred fred.l.templin@boeing.com= From Ted.Lemon@nominum.com Fri Nov 18 13:36:51 2011 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 BE5C41F0C81 for ; Fri, 18 Nov 2011 13:36:51 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.571 X-Spam-Level: X-Spam-Status: No, score=-106.571 tagged_above=-999 required=5 tests=[AWL=0.028, 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 qWvlopE0DcUq for ; Fri, 18 Nov 2011 13:36:51 -0800 (PST) Received: from exprod7og126.obsmtp.com (exprod7og126.obsmtp.com [64.18.2.206]) by ietfa.amsl.com (Postfix) with ESMTP id 183851F0C7D for ; Fri, 18 Nov 2011 13:36:50 -0800 (PST) Received: from shell-too.nominum.com ([64.89.228.229]) (using TLSv1) by exprod7ob126.postini.com ([64.18.6.12]) with SMTP ID DSNKTsbP5GRdBoCyjPKbqhtslaEBoDjs0OIP@postini.com; Fri, 18 Nov 2011 13:36:51 PST 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 E04BC1B8272 for ; Fri, 18 Nov 2011 13:36:35 -0800 (PST) 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 D364019005D; Fri, 18 Nov 2011 13:36:35 -0800 (PST) (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.01.0339.001; Fri, 18 Nov 2011 13:36:35 -0800 From: Ted Lemon To: Alexandru Petrescu Thread-Topic: [mif] Concerns regarding draft-ietf-mif-dhcpv6-route-option Thread-Index: AQHMpTEjHFvj9ATPck23AXX5xYdXX5Wy+5QAgAAuUws= Date: Fri, 18 Nov 2011 21:36:34 +0000 Message-ID: References: <4EC5133D.3050508@gmail.com>,<4EC63886.6050806@gmail.com> In-Reply-To: <4EC63886.6050806@gmail.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "mif@ietf.org" Subject: Re: [mif] Concerns regarding draft-ietf-mif-dhcpv6-route-option 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, 18 Nov 2011 21:36:51 -0000 Alexandru, was there a use case in there that I missed? From Ted.Lemon@nominum.com Fri Nov 18 13:53:10 2011 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 8FBB711E80D4 for ; Fri, 18 Nov 2011 13:53:10 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.571 X-Spam-Level: X-Spam-Status: No, score=-106.571 tagged_above=-999 required=5 tests=[AWL=0.028, 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 VKzPcWOrM4Ez for ; Fri, 18 Nov 2011 13:53:06 -0800 (PST) Received: from exprod7og116.obsmtp.com (exprod7og116.obsmtp.com [64.18.2.219]) by ietfa.amsl.com (Postfix) with ESMTP id 5DD1211E8095 for ; Fri, 18 Nov 2011 13:53:06 -0800 (PST) Received: from shell-too.nominum.com ([64.89.228.229]) (using TLSv1) by exprod7ob116.postini.com ([64.18.6.12]) with SMTP ID DSNKTsbTwc56lXCj4A6b/JNop6NBL6gg+fq7@postini.com; Fri, 18 Nov 2011 13:53:06 PST 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 861071B8291 for ; Fri, 18 Nov 2011 13:53:05 -0800 (PST) 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 7E5F919005D; Fri, 18 Nov 2011 13:53:05 -0800 (PST) (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.01.0339.001; Fri, 18 Nov 2011 13:53:05 -0800 From: Ted Lemon To: Alexandru Petrescu Thread-Topic: [mif] Use cases for draft-ietf-mif-dhcpv6-route-option needed Thread-Index: AQHMpd4WcQWUV79AAkeKKGYg/SGVkpWzLSoj Date: Fri, 18 Nov 2011 21:53:05 +0000 Message-ID: <816B77CB-F8A4-42CD-AE66-30789883BACC@nominum.com> References: <282BBE8A501E1F4DA9C775F964BB21FE3EB78C3C98@GRFMBX704BA020.griffon.local> <916CE6CF87173740BC8A2CE44309696204193417@008-AM1MPN1-053.mgdnok.nokia.com> <4EC512A2.2060509@gmail.com>,<4EC63564.4080101@gmail.com> In-Reply-To: <4EC63564.4080101@gmail.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "mif@ietf.org" Subject: Re: [mif] Use cases for draft-ietf-mif-dhcpv6-route-option needed 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, 18 Nov 2011 21:53:10 -0000 On Nov 18, 2011, at 6:37 PM, "Alexandru Petrescu" wrote: > I pick one use-case I am particularly concerned with: router device with > limited memory and CPU MHz connected to low-rate cellular forced into > using both DHCP and RA software. It would better use only one software > implementation (not 2), and do a short exchanges of messages (4 messages > instead of 6) to obtain: default route, prefix, address, DNS server. Can you tell us more about this device? I didn't know people made devices= this small anymore other than in the distributed sensor network environmen= t (e.g., lowpan). From Ted.Lemon@nominum.com Fri Nov 18 13:58:24 2011 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 7D8AA11E80F2 for ; Fri, 18 Nov 2011 13:58:24 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.572 X-Spam-Level: X-Spam-Status: No, score=-106.572 tagged_above=-999 required=5 tests=[AWL=0.027, 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 RdqQ9vp11m89 for ; Fri, 18 Nov 2011 13:58:23 -0800 (PST) Received: from exprod7og124.obsmtp.com (exprod7og124.obsmtp.com [64.18.2.26]) by ietfa.amsl.com (Postfix) with ESMTP id C269C11E80EA for ; Fri, 18 Nov 2011 13:58:20 -0800 (PST) Received: from shell-too.nominum.com ([64.89.228.229]) (using TLSv1) by exprod7ob124.postini.com ([64.18.6.12]) with SMTP ID DSNKTsbU/H1cfFeALZl2ek/vdh9M5Az+Or9j@postini.com; Fri, 18 Nov 2011 13:58:20 PST 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 DF5781B8291 for ; Fri, 18 Nov 2011 13:58:19 -0800 (PST) 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 C9F2219005D; Fri, 18 Nov 2011 13:58:19 -0800 (PST) (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.01.0339.001; Fri, 18 Nov 2011 13:58:19 -0800 From: Ted Lemon To: Alexandru Petrescu Thread-Topic: [mif] Use cases for draft-ietf-mif-dhcpv6-route-option needed Thread-Index: AQHMpeNOuu/E0pVKc0uk0cJFS4z9vZWzLpa7 Date: Fri, 18 Nov 2011 21:58:19 +0000 Message-ID: <86163A8F-8628-4F67-BE93-3747F95A2F52@nominum.com> References: <282BBE8A501E1F4DA9C775F964BB21FE3EB78C3C98@GRFMBX704BA020.griffon.local> <916CE6CF87173740BC8A2CE44309696204193417@008-AM1MPN1-053.mgdnok.nokia.com>, <4EC512A2.2060509@gmail.com> <890A58CF-8EAD-4F92-9981-9B5AA07EBF00@nominum.com>, <4EC63E26.70104@gmail.com> In-Reply-To: <4EC63E26.70104@gmail.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "mif@ietf.org" Subject: Re: [mif] Use cases for draft-ietf-mif-dhcpv6-route-option needed 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, 18 Nov 2011 21:58:24 -0000 On Nov 18, 2011, at 7:14 PM, "Alexandru Petrescu" wrote: > But don't scare people away with the word "deployment". Initial > deployments are often just lab settings, a desk, a pocket sometimes. Sure, but the question is whether you have a real situation where you are f= orced to use DHCP and not RA, or just a hypothetical situation. > RA defroutes don't work for me because there may be not enough memory > space next to the DHCP daemon on a 400MHz ARM processor of mobile router. Huh, I have a 400MHz ARM system that runs a full Linux kernel including DHC= Pv4 client and RA (which is in the kernel). It's a Sheeva CPU, so it's a = little slow, but I haven't had any problems at all with this: where I've ha= d problems is compiling kernels in reasonable amounts of time. So I reall= y, really have trouble believing that this device can't do RA. > No, it is not this reason for me. In my particular case I am fully > aware of RAs offering defroute, and aware of DHCPv4 and DHCPv6 Relays. > In my lab setting it is easier to maintain de conf files centrally on a > unique machine rather than on 5-like Access Routers. I do not have a > std mechanism to remotely update the RA information these Access Routers > offer. But for DHCP I have this central conf file. Okay, so why do you want this? I don't mean to say you shouldn't want it,= but can you explain why you want it? > I do not work for a vendor. I don't see why calling the DHCP defroute a > "vendor" option. On another hand I could agree with it being > EXPERIMENTAL at this point in time. As Lorenzo said in the meeting, if you give it an option code, it will see = wide implementation, regardless of whether it's standard, informational or = experimental, because lots of people say they want it. So from an archite= ctural standpoint, we can't punt on the question of whether we need it.= From Ted.Lemon@nominum.com Fri Nov 18 13:59:52 2011 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 E950211E80F6 for ; Fri, 18 Nov 2011 13:59:52 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.572 X-Spam-Level: X-Spam-Status: No, score=-106.572 tagged_above=-999 required=5 tests=[AWL=0.027, 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 zP8vJ1jnDaRt for ; Fri, 18 Nov 2011 13:59:52 -0800 (PST) Received: from exprod7og102.obsmtp.com (exprod7og102.obsmtp.com [64.18.2.157]) by ietfa.amsl.com (Postfix) with ESMTP id 469CC11E80F3 for ; Fri, 18 Nov 2011 13:59:52 -0800 (PST) Received: from shell-too.nominum.com ([64.89.228.229]) (using TLSv1) by exprod7ob102.postini.com ([64.18.6.12]) with SMTP ID DSNKTsbVVmudW/NXdiEr+1B9lhxS3ReogrV+@postini.com; Fri, 18 Nov 2011 13:59:52 PST 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 1A76B1B8286 for ; Fri, 18 Nov 2011 13:59:50 -0800 (PST) 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 13FA819005D; Fri, 18 Nov 2011 13:59:50 -0800 (PST) (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.01.0339.001; Fri, 18 Nov 2011 13:59:50 -0800 From: Ted Lemon To: "Templin, Fred L" Thread-Topic: [mif] IRON as a multiple interface solution Thread-Index: AQHMpj1koMqud6He1Eq9rIfXAKsZZA== Date: Fri, 18 Nov 2011 21:59:49 +0000 Message-ID: References: <282BBE8A501E1F4DA9C775F964BB21FE3EB78C3C98@GRFMBX704BA020.griffon.local> <916CE6CF87173740BC8A2CE44309696204193417@008-AM1MPN1-053.mgdnok.nokia.com>, <4EC512A2.2060509@gmail.com> <890A58CF-8EAD-4F92-9981-9B5AA07EBF00@nominum.com>, <4EC5B720.8020605@gmail.com> <83A7D27A-9036-4252-AC94-3A89125C961B@nominum.com> <4EC63ECC.8010700@gmail.com>, In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "mif@ietf.org" Subject: Re: [mif] IRON as a multiple interface solution 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, 18 Nov 2011 21:59:53 -0000 On Nov 19, 2011, at 4:38 AM, "Templin, Fred L" = wrote: > A new routing and addressing system known as the > Internet Routing Overlay Network (IRON) is available Correct me if I am wrong, but doesn't this depend on all provisioning domai= ns being in the same administrative domain? From Fred.L.Templin@boeing.com Fri Nov 18 14:19:47 2011 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 D0D9621F8AEA for ; Fri, 18 Nov 2011 14:19:47 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.741 X-Spam-Level: X-Spam-Status: No, score=-6.741 tagged_above=-999 required=5 tests=[AWL=-0.142, 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 Towxy+1Oe4iz for ; Fri, 18 Nov 2011 14:19:46 -0800 (PST) Received: from slb-smtpout-01.boeing.com (slb-smtpout-01.boeing.com [130.76.64.48]) by ietfa.amsl.com (Postfix) with ESMTP id E144921F8AE6 for ; Fri, 18 Nov 2011 14:19:46 -0800 (PST) Received: from slb-av-01.boeing.com (slb-av-01.boeing.com [129.172.13.4]) by slb-smtpout-01.ns.cs.boeing.com (8.14.4/8.14.4/8.14.4/SMTPOUT) with ESMTP id pAIMJf6r016829 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Fri, 18 Nov 2011 14:19:42 -0800 (PST) Received: from slb-av-01.boeing.com (localhost [127.0.0.1]) by slb-av-01.boeing.com (8.14.4/8.14.4/DOWNSTREAM_RELAY) with ESMTP id pAIMJfrZ029629; Fri, 18 Nov 2011 14:19:41 -0800 (PST) Received: from XCH-NWHT-06.nw.nos.boeing.com (xch-nwht-06.nw.nos.boeing.com [130.247.25.110]) by slb-av-01.boeing.com (8.14.4/8.14.4/UPSTREAM_RELAY) with ESMTP id pAIMJexW029597 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=OK); Fri, 18 Nov 2011 14:19:41 -0800 (PST) Received: from XCH-NW-01V.nw.nos.boeing.com ([130.247.64.97]) by XCH-NWHT-06.nw.nos.boeing.com ([130.247.25.110]) with mapi; Fri, 18 Nov 2011 14:19:40 -0800 From: "Templin, Fred L" To: Ted Lemon Date: Fri, 18 Nov 2011 14:19:39 -0800 Thread-Topic: [mif] IRON as a multiple interface solution Thread-Index: AQHMpj1koMqud6He1Eq9rIfXAKsZZJWzMgAQ Message-ID: References: <282BBE8A501E1F4DA9C775F964BB21FE3EB78C3C98@GRFMBX704BA020.griffon.local> <916CE6CF87173740BC8A2CE44309696204193417@008-AM1MPN1-053.mgdnok.nokia.com>, <4EC512A2.2060509@gmail.com> <890A58CF-8EAD-4F92-9981-9B5AA07EBF00@nominum.com>, <4EC5B720.8020605@gmail.com> <83A7D27A-9036-4252-AC94-3A89125C961B@nominum.com> <4EC63ECC.8010700@gmail.com>, In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "mif@ietf.org" Subject: Re: [mif] IRON as a multiple interface solution 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, 18 Nov 2011 22:19:47 -0000 Hi Ted,=20 > -----Original Message----- > From: Ted Lemon [mailto:Ted.Lemon@nominum.com]=20 > Sent: Friday, November 18, 2011 2:00 PM > To: Templin, Fred L > Cc: mif@ietf.org > Subject: Re: [mif] IRON as a multiple interface solution >=20 > On Nov 19, 2011, at 4:38 AM, "Templin, Fred L"=20 > wrote: > > A new routing and addressing system known as the > > Internet Routing Overlay Network (IRON) is available >=20 > Correct me if I am wrong, but doesn't this depend on all=20 > provisioning domains being in the same administrative domain? If you consider "the Internet" as a singe administrative domain then, yes, the IRON tunnel virtual interface is configured over a single administrative domain. So, the tunnel virtual interface is configured over all of the host's ISP interfaces. If the host also connects to a home enterprise network via a VPN, then that would be a separate administrative domain and a separate tunnel virtual interface. Does this help? Thanks - Fred = From arifumi@nttv6.net Sat Nov 19 11:54:56 2011 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 20ADF21F869E for ; Sat, 19 Nov 2011 11:54:56 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.393 X-Spam-Level: X-Spam-Status: No, score=-102.393 tagged_above=-999 required=5 tests=[AWL=-0.394, BAYES_00=-2.599, J_CHICKENPOX_13=0.6, 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 3xhMUPu44mBI for ; Sat, 19 Nov 2011 11:54:55 -0800 (PST) Received: from leo.nttv6.net (leo.nttv6.net [192.47.162.93]) by ietfa.amsl.com (Postfix) with ESMTP id 88FD421F8672 for ; Sat, 19 Nov 2011 11:54:55 -0800 (PST) Received: from [127.0.0.1] (localhost.nttv6.net [IPv6:::1]) by leo.nttv6.net (8.14.5/8.14.4) with ESMTP id pAJJrI8p073484; Sun, 20 Nov 2011 04:53:18 +0900 (JST) (envelope-from arifumi@nttv6.net) References: <282BBE8A501E1F4DA9C775F964BB21FE3EB78C3C98@GRFMBX704BA020.griffon.local> <916CE6CF87173740BC8A2CE44309696204193417@008-AM1MPN1-053.mgdnok.nokia.com> <4EC512A2.2060509@gmail.com> In-Reply-To: <4EC512A2.2060509@gmail.com> Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii Message-Id: <3814C125-A48E-459E-B5E8-9B549D237F9D@nttv6.net> Content-Transfer-Encoding: 7bit From: Arifumi Matsumoto Date: Sun, 20 Nov 2011 04:53:35 +0900 To: Tomek Mrugalski X-Mailer: Apple Mail (2.1084) Cc: mif@ietf.org Subject: Re: [mif] Use cases for draft-ietf-mif-dhcpv6-route-option needed 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, 19 Nov 2011 19:54:56 -0000 Hi, here are our reasons why we need DHCPv6 route option. * Relaying function is needed. We've already deployed lots of IPv6 edge routers that do not have RFC 4191 more specific routes function in them. Upgrading them or configuring each of them for each customer may not be possible or at least really painful. Central control brought by DHCP relaying function is really helpful here. * Performance problem in aggregating routers. Alexandru pointed out the resource limit on user devices. The similar situation occurs on the network side, such as aggregation routers. As a lot of people pointed out at 6man or v6ops session in Taipei, RA consumes a lot of resources on a user device, and also on the aggregating routers. If we can use DHCP for delegating prefixes, routes, and DNS server addresses, then we can completely move to DHCP. * Host based control is needed. When multiple users are on the same link, such as public wifi services, we want to deliver information, such as prefix, route, and DNS, dependent on the service the user subscribes. The user specific route info is needed, because some users just subscribes to walled garden services, and don't need default route. Some others subscribes to both Internet access and walled garden services. * Why BBF std doesn't work. In one type of access service, we allow directly attaching user's PC to the uplink, as well as attaching a router. So, in this case, PCs have to support DHCPv6 route, address, DNS options, not just the routers. Best regards, From ajs@anvilwalrusden.com Sat Nov 19 14:04:00 2011 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 235EB21F85F1 for ; Sat, 19 Nov 2011 14:04:00 -0800 (PST) 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 3ZlpKEacIM4X for ; Sat, 19 Nov 2011 14:03:59 -0800 (PST) Received: from mail.yitter.info (mail.yitter.info [208.86.224.201]) by ietfa.amsl.com (Postfix) with ESMTP id 8F45B21F849E for ; Sat, 19 Nov 2011 14:03:59 -0800 (PST) Received: from shinkuro.com (m070f36d0.tmodns.net [208.54.15.7]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.yitter.info (Postfix) with ESMTPSA id ACB551ECB424 for ; Sat, 19 Nov 2011 22:03:44 +0000 (UTC) Date: Sat, 19 Nov 2011 17:03:56 -0500 From: Andrew Sullivan To: mif@ietf.org Message-ID: <20111119220355.GA893@shinkuro.com> References: <282BBE8A501E1F4DA9C775F964BB21FE3EB78C3C98@GRFMBX704BA020.griffon.local> <916CE6CF87173740BC8A2CE44309696204193417@008-AM1MPN1-053.mgdnok.nokia.com> <4EC512A2.2060509@gmail.com> <890A58CF-8EAD-4F92-9981-9B5AA07EBF00@nominum.com> <4EC5B720.8020605@gmail.com> <83A7D27A-9036-4252-AC94-3A89125C961B@nominum.com> <4EC63ECC.8010700@gmail.com> 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] IRON as a multiple interface solution 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, 19 Nov 2011 22:04:00 -0000 On Fri, Nov 18, 2011 at 02:19:39PM -0800, Templin, Fred L wrote: > > If the host also connects to a home enterprise network > via a VPN, then that would be a separate administrative > domain and a separate tunnel virtual interface. Does > this help? It does, in that it seems to make it pretty hard to solve the multiple resolution context problem that the DNS server selection draft is trying to solve. A -- Andrew Sullivan ajs@anvilwalrusden.com From brian.e.carpenter@gmail.com Sun Nov 20 12:17:49 2011 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 9337B21F842E for ; Sun, 20 Nov 2011 12:17:49 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.499 X-Spam-Level: X-Spam-Status: No, score=-103.499 tagged_above=-999 required=5 tests=[AWL=0.100, 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 NtKHAChyLbT5 for ; Sun, 20 Nov 2011 12:17:48 -0800 (PST) Received: from mail-iy0-f172.google.com (mail-iy0-f172.google.com [209.85.210.172]) by ietfa.amsl.com (Postfix) with ESMTP id B68FF21F8876 for ; Sun, 20 Nov 2011 12:17:48 -0800 (PST) Received: by iaeo4 with SMTP id o4so7740209iae.31 for ; Sun, 20 Nov 2011 12:17:48 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=message-id:date:from:organization:user-agent:mime-version:to:cc :subject:references:in-reply-to:content-type :content-transfer-encoding; bh=p+Lh6Ht0nGhsg8VIOIor9ThbqnHdzGZfmehIJds7XWg=; b=QFMyGoOTyCe5XKMJMCQGc9DFW6z91Rs0tHKmOox/x5iuC2+XaJu046vvknRqanqfpe UqxSNqA75FRLVUSMSJx1opeAGgPVlLUxMRden5DU/vOjHQD81u9cKFdP59MIh/Thh9YC n+kQUt/CubeVV0kSEfVMPR/cVBOqWbYjrgsMA= Received: by 10.42.96.132 with SMTP id j4mr11547686icn.50.1321820266609; Sun, 20 Nov 2011 12:17:46 -0800 (PST) Received: from [130.216.38.124] (stf-brian.sfac.auckland.ac.nz. [130.216.38.124]) by mx.google.com with ESMTPS id ew6sm20778250igc.4.2011.11.20.12.17.43 (version=SSLv3 cipher=OTHER); Sun, 20 Nov 2011 12:17:45 -0800 (PST) Message-ID: <4EC96061.2050907@gmail.com> Date: Mon, 21 Nov 2011 09:17:37 +1300 From: Brian E Carpenter Organization: University of Auckland User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: Tomek Mrugalski References: <282BBE8A501E1F4DA9C775F964BB21FE3EB78C3C98@GRFMBX704BA020.griffon.local> <916CE6CF87173740BC8A2CE44309696204193417@008-AM1MPN1-053.mgdnok.nokia.com> <4EC512A2.2060509@gmail.com> In-Reply-To: <4EC512A2.2060509@gmail.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: mif@ietf.org Subject: Re: [mif] Use cases for draft-ietf-mif-dhcpv6-route-option needed 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, 20 Nov 2011 20:17:49 -0000 Please look at the thread "Why not RIO?" starting at http://lists.cluenet.de/pipermail/ipv6-ops/2011-November/006539.html There are various operational scenarios mentioned in the replies so far for which RA/RIO does not appear sufficient. In particular see http://lists.cluenet.de/pipermail/ipv6-ops/2011-November/006540.html (1 use case) http://lists.cluenet.de/pipermail/ipv6-ops/2011-November/006545.html (7 use cases) Regards Brian Carpenter From brian.e.carpenter@gmail.com Sun Nov 20 12:20:54 2011 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 4BACB21F8A71 for ; Sun, 20 Nov 2011 12:20:54 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.5 X-Spam-Level: X-Spam-Status: No, score=-103.5 tagged_above=-999 required=5 tests=[AWL=0.099, 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 bHQtObf7FK5D for ; Sun, 20 Nov 2011 12:20:53 -0800 (PST) Received: from mail-iy0-f172.google.com (mail-iy0-f172.google.com [209.85.210.172]) by ietfa.amsl.com (Postfix) with ESMTP id A998F21F8A6F for ; Sun, 20 Nov 2011 12:20:53 -0800 (PST) Received: by iaeo4 with SMTP id o4so7742924iae.31 for ; Sun, 20 Nov 2011 12:20:53 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=message-id:date:from:organization:user-agent:mime-version:to:cc :subject:references:in-reply-to:content-type :content-transfer-encoding; bh=8RVh/ayhVYPP8lbjZvgAFeM68ex7rADd1q6Ttjtjw3c=; b=lDiKQeYyVF0K6Iv4sFkE23ps3Nff9arSsrrkHtYA9nD7ndwqcKb6WOLTHUb3YpixBX so3GxoUvvf2G5dtREFTjyxcH7ESH+4LSbS1stCBbmFJuGbzVqbXZ4P0cFu8S+lUwvT0b JQrD7DdeiiL21nwFD8xamDNZsghwKPapCUElE= Received: by 10.42.41.143 with SMTP id p15mr10816471ice.9.1321820453225; Sun, 20 Nov 2011 12:20:53 -0800 (PST) Received: from [130.216.38.124] (stf-brian.sfac.auckland.ac.nz. [130.216.38.124]) by mx.google.com with ESMTPS id mb4sm20815072igc.1.2011.11.20.12.20.50 (version=SSLv3 cipher=OTHER); Sun, 20 Nov 2011 12:20:52 -0800 (PST) Message-ID: <4EC96120.8040506@gmail.com> Date: Mon, 21 Nov 2011 09:20:48 +1300 From: Brian E Carpenter Organization: University of Auckland User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: Tomek Mrugalski References: <282BBE8A501E1F4DA9C775F964BB21FE3EB78C3C98@GRFMBX704BA020.griffon.local> <916CE6CF87173740BC8A2CE44309696204193417@008-AM1MPN1-053.mgdnok.nokia.com> <4EC512A2.2060509@gmail.com> <4EC96061.2050907@gmail.com> In-Reply-To: <4EC96061.2050907@gmail.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: mif@ietf.org Subject: Re: [mif] Use cases for draft-ietf-mif-dhcpv6-route-option needed 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, 20 Nov 2011 20:20:54 -0000 And this one also describes another use case: http://lists.cluenet.de/pipermail/ipv6-ops/2011-November/006543.html On 2011-11-21 09:17, Brian E Carpenter wrote: > Please look at the thread "Why not RIO?" starting at > http://lists.cluenet.de/pipermail/ipv6-ops/2011-November/006539.html > > There are various operational scenarios mentioned in the replies so far > for which RA/RIO does not appear sufficient. In particular see > > http://lists.cluenet.de/pipermail/ipv6-ops/2011-November/006540.html (1 use case) > http://lists.cluenet.de/pipermail/ipv6-ops/2011-November/006545.html (7 use cases) > > Regards > Brian Carpenter > From Ted.Lemon@nominum.com Sun Nov 20 16:17:48 2011 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 E92CF11E808D for ; Sun, 20 Nov 2011 16:17:48 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.573 X-Spam-Level: X-Spam-Status: No, score=-106.573 tagged_above=-999 required=5 tests=[AWL=0.026, 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 8v1-H5gtZUbR for ; Sun, 20 Nov 2011 16:17:48 -0800 (PST) Received: from exprod7og107.obsmtp.com (exprod7og107.obsmtp.com [64.18.2.167]) by ietfa.amsl.com (Postfix) with ESMTP id E02FF11E808C for ; Sun, 20 Nov 2011 16:17:47 -0800 (PST) Received: from shell-too.nominum.com ([64.89.228.229]) (using TLSv1) by exprod7ob107.postini.com ([64.18.6.12]) with SMTP ID DSNKTsmYpLDHv77kQjlEbsO1dOUaAn6KqBJV@postini.com; Sun, 20 Nov 2011 16:17:47 PST 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 6DD381B8291 for ; Sun, 20 Nov 2011 16:17:40 -0800 (PST) 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 AE14719005D; Sun, 20 Nov 2011 16:17:38 -0800 (PST) (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.01.0339.001; Sun, 20 Nov 2011 16:17:38 -0800 From: Ted Lemon To: Brian E Carpenter Thread-Topic: [mif] Use cases for draft-ietf-mif-dhcpv6-route-option needed Thread-Index: AQHMp8F7pvQ7XNxt70G1N6a33JnFtpW2umEAgAAgSQA= Date: Mon, 21 Nov 2011 00:17:37 +0000 Message-ID: References: <282BBE8A501E1F4DA9C775F964BB21FE3EB78C3C98@GRFMBX704BA020.griffon.local> <916CE6CF87173740BC8A2CE44309696204193417@008-AM1MPN1-053.mgdnok.nokia.com> <4EC512A2.2060509@gmail.com> <4EC96061.2050907@gmail.com> <4EC96120.8040506@gmail.com> In-Reply-To: <4EC96120.8040506@gmail.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: Content-Type: text/plain; charset="us-ascii" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "mif@ietf.org" Subject: Re: [mif] Use cases for draft-ietf-mif-dhcpv6-route-option needed 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, 21 Nov 2011 00:17:49 -0000 On Nov 20, 2011, at 3:20 PM, "Brian E Carpenter" wrote: > http://lists.cluenet.de/pipermail/ipv6-ops/2011-November/006543.html DHCP is actually very poorly suited for many of these cases. E.g., using i= t to control access to a captive portal is a terrible idea. These are defin= itely things you /could/ do with dhcp, if you didn't have RA on your networ= k, and if your devices supported this configuration, but these documents re= ally read as "throw out RA," not "use DHCP," and seem really to be statemen= ts of preference, not cases where you can't do it with RA and must have som= e other solution. From brian.e.carpenter@gmail.com Sun Nov 20 16:54:37 2011 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 BD3DB11E808E for ; Sun, 20 Nov 2011 16:54:37 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.502 X-Spam-Level: X-Spam-Status: No, score=-103.502 tagged_above=-999 required=5 tests=[AWL=0.097, 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 6Tul1vx8jARV for ; Sun, 20 Nov 2011 16:54:37 -0800 (PST) Received: from mail-vx0-f172.google.com (mail-vx0-f172.google.com [209.85.220.172]) by ietfa.amsl.com (Postfix) with ESMTP id EA31A11E808D for ; Sun, 20 Nov 2011 16:54:36 -0800 (PST) Received: by vcbfy13 with SMTP id fy13so2338520vcb.31 for ; Sun, 20 Nov 2011 16:54:36 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=message-id:date:from:organization:user-agent:mime-version:to:cc :subject:references:in-reply-to:content-type :content-transfer-encoding; bh=OP0LKZphTWN3d1fbTXXs5XM+gDaBfd6dmyqdfQIQguE=; b=shJiNG1un/1s6678ZQpTJ0gIaffa2Zaw1xMtNZnS81z80VCfJ7VW1jsj8U3iG6ZTpr +zf3ysSxCE+Zk/F5ms6s4uw3Df9g2rYYXT+t89F4xP6KSd+F9hfi5GRBvrSoPF2mRY00 0mFj3MLtU/Gelo9mgSLCspo/X3en1ZY/aEM3I= Received: by 10.220.117.79 with SMTP id p15mr856635vcq.119.1321836876482; Sun, 20 Nov 2011 16:54:36 -0800 (PST) Received: from [130.216.38.124] (stf-brian.sfac.auckland.ac.nz. [130.216.38.124]) by mx.google.com with ESMTPS id em10sm12025825vdc.6.2011.11.20.16.54.33 (version=SSLv3 cipher=OTHER); Sun, 20 Nov 2011 16:54:35 -0800 (PST) Message-ID: <4EC9A14A.7030202@gmail.com> Date: Mon, 21 Nov 2011 13:54:34 +1300 From: Brian E Carpenter Organization: University of Auckland User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: Ted Lemon References: <282BBE8A501E1F4DA9C775F964BB21FE3EB78C3C98@GRFMBX704BA020.griffon.local> <916CE6CF87173740BC8A2CE44309696204193417@008-AM1MPN1-053.mgdnok.nokia.com> <4EC512A2.2060509@gmail.com> <4EC96061.2050907@gmail.com> <4EC96120.8040506@gmail.com> In-Reply-To: Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: "mif@ietf.org" Subject: Re: [mif] Use cases for draft-ietf-mif-dhcpv6-route-option needed 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, 21 Nov 2011 00:54:37 -0000 Ted, On 2011-11-21 13:17, Ted Lemon wrote: > On Nov 20, 2011, at 3:20 PM, "Brian E Carpenter" wrote: >> http://lists.cluenet.de/pipermail/ipv6-ops/2011-November/006543.html > > DHCP is actually very poorly suited for many of these cases. E.g., using it to control access to a captive portal is a terrible idea. These are definitely things you /could/ do with dhcp, if you didn't have RA on your network, and if your devices supported this configuration, but these documents really read as "throw out RA," not "use DHCP," and seem really to be statements of preference, not cases where you can't do it with RA and must have some other solution. I can't speak for the operators. I'm guessing a few things they might say though, if you were to answer in this way on the cluenet list. Where is it documented how to use unicast RA/RIO messages to configure individual hosts? Including, which products provide some sort of database-driven mechanism to generate individual RA/RIO (or other) options for a few thousand hosts, like many sites generate a few thousand DHCP(v4) entries today? Which off the shelf IPAM (address management) products support RA/RIO? What's the mechanism for configuring all this host-related data into the individual routers, especially when a given host (i.e. MAC address) may appear arbitrarily on any subnet at any time? Brian From Fred.L.Templin@boeing.com Mon Nov 21 08:17:35 2011 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 4A18821F8BB8 for ; Mon, 21 Nov 2011 08:17:35 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.734 X-Spam-Level: X-Spam-Status: No, score=-6.734 tagged_above=-999 required=5 tests=[AWL=-0.135, 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 qdOQyJRdlTpW for ; Mon, 21 Nov 2011 08:17:31 -0800 (PST) Received: from blv-smtpout-01.boeing.com (blv-smtpout-01.boeing.com [130.76.32.69]) by ietfa.amsl.com (Postfix) with ESMTP id 5B2AC21F8BB6 for ; Mon, 21 Nov 2011 08:17:31 -0800 (PST) Received: from stl-av-01.boeing.com (stl-av-01.boeing.com [192.76.190.6]) by blv-smtpout-01.ns.cs.boeing.com (8.14.4/8.14.4/8.14.4/SMTPOUT) with ESMTP id pALGHO21007015 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Mon, 21 Nov 2011 08:17:25 -0800 (PST) Received: from stl-av-01.boeing.com (localhost [127.0.0.1]) by stl-av-01.boeing.com (8.14.4/8.14.4/DOWNSTREAM_RELAY) with ESMTP id pALGHOZm001261; Mon, 21 Nov 2011 10:17:24 -0600 (CST) Received: from XCH-NWHT-05.nw.nos.boeing.com (xch-nwht-05.nw.nos.boeing.com [130.247.25.109]) by stl-av-01.boeing.com (8.14.4/8.14.4/UPSTREAM_RELAY) with ESMTP id pALGHMr7001181 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=OK); Mon, 21 Nov 2011 10:17:23 -0600 (CST) Received: from XCH-NW-01V.nw.nos.boeing.com ([130.247.64.97]) by XCH-NWHT-05.nw.nos.boeing.com ([130.247.25.109]) with mapi; Mon, 21 Nov 2011 08:17:22 -0800 From: "Templin, Fred L" To: Andrew Sullivan , "mif@ietf.org" Date: Mon, 21 Nov 2011 08:17:21 -0800 Thread-Topic: [mif] IRON as a multiple interface solution Thread-Index: AcynByfJKOKfwGnGSFCeOdx3ACd74QBYY/Mg Message-ID: References: <282BBE8A501E1F4DA9C775F964BB21FE3EB78C3C98@GRFMBX704BA020.griffon.local> <916CE6CF87173740BC8A2CE44309696204193417@008-AM1MPN1-053.mgdnok.nokia.com> <4EC512A2.2060509@gmail.com> <890A58CF-8EAD-4F92-9981-9B5AA07EBF00@nominum.com> <4EC5B720.8020605@gmail.com> <83A7D27A-9036-4252-AC94-3A89125C961B@nominum.com> <4EC63ECC.8010700@gmail.com> <20111119220355.GA893@shinkuro.com> In-Reply-To: <20111119220355.GA893@shinkuro.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [mif] IRON as a multiple interface solution 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, 21 Nov 2011 16:17:35 -0000 Hi Andrew,=20 > -----Original Message----- > From: mif-bounces@ietf.org [mailto:mif-bounces@ietf.org] On=20 > Behalf Of Andrew Sullivan > Sent: Saturday, November 19, 2011 2:04 PM > To: mif@ietf.org > Subject: Re: [mif] IRON as a multiple interface solution >=20 > On Fri, Nov 18, 2011 at 02:19:39PM -0800, Templin, Fred L wrote: > >=20 > > If the host also connects to a home enterprise network > > via a VPN, then that would be a separate administrative > > domain and a separate tunnel virtual interface. Does > > this help? >=20 > It does, in that it seems to make it pretty hard to solve the multiple > resolution context problem that the DNS server selection draft is > trying to solve. What I was describing was what is sometimes called a "Split Tunnel" scenario. AFAICT, any solution that would address that scenario would be applicable also to IRON, and not in any way made more difficult by IRON. Thanks - Fred > A >=20 > --=20 > Andrew Sullivan > ajs@anvilwalrusden.com >=20 > _______________________________________________ > mif mailing list > mif@ietf.org > https://www.ietf.org/mailman/listinfo/mif > = From narten@us.ibm.com Mon Nov 21 12:36:19 2011 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 5D16A11E8108 for ; Mon, 21 Nov 2011 12:36:19 -0800 (PST) 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 Nio9DnF+npuN for ; Mon, 21 Nov 2011 12:36:18 -0800 (PST) Received: from e32.co.us.ibm.com (e32.co.us.ibm.com [32.97.110.150]) by ietfa.amsl.com (Postfix) with ESMTP id C553E11E80F6 for ; Mon, 21 Nov 2011 12:36:18 -0800 (PST) Received: from /spool/local by e32.co.us.ibm.com with IBM ESMTP SMTP Gateway: Authorized Use Only! Violators will be prosecuted for from ; Mon, 21 Nov 2011 13:36:17 -0700 Received: from d03relay02.boulder.ibm.com ([9.17.195.227]) by e32.co.us.ibm.com ([192.168.1.132]) with IBM ESMTP SMTP Gateway: Authorized Use Only! Violators will be prosecuted; Mon, 21 Nov 2011 13:36:16 -0700 Received: from d03av02.boulder.ibm.com (d03av02.boulder.ibm.com [9.17.195.168]) by d03relay02.boulder.ibm.com (8.13.8/8.13.8/NCO v10.0) with ESMTP id pALKa6pM091116; Mon, 21 Nov 2011 13:36:06 -0700 Received: from d03av02.boulder.ibm.com (loopback [127.0.0.1]) by d03av02.boulder.ibm.com (8.14.4/8.13.1/NCO v10.0 AVout) with ESMTP id pALKa5Yt026445; Mon, 21 Nov 2011 13:36:05 -0700 Received: from cichlid.raleigh.ibm.com (sig-9-49-158-47.mts.ibm.com [9.49.158.47]) by d03av02.boulder.ibm.com (8.14.4/8.13.1/NCO v10.0 AVin) with ESMTP id pALKa1sf026148 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 21 Nov 2011 13:36:03 -0700 Received: from cichlid.raleigh.ibm.com (cichlid.raleigh.ibm.com [127.0.0.1]) by cichlid.raleigh.ibm.com (8.14.4/8.12.5) with ESMTP id pALKa0eO019515; Mon, 21 Nov 2011 15:36:00 -0500 Message-Id: <201111212036.pALKa0eO019515@cichlid.raleigh.ibm.com> To: Ted Lemon In-reply-to: <23BACC91-621A-4E96-ACD6-92D226F9657A@nominum.com> References: , <402398CF-7F7C-4B8B-91CE-6EDE54B6C4CC@employees.org> <23BACC91-621A-4E96-ACD6-92D226F9657A@nominum.com> Comments: In-reply-to Ted Lemon message dated "Mon, 14 Nov 2011 02:24:37 +0000." Date: Mon, 21 Nov 2011 15:36:00 -0500 From: Thomas Narten x-cbid: 11112120-3270-0000-0000-000001F5EAA9 Cc: MIF Mailing List , Ole Troan , "ipv6@ietf.org" , dhc WG Subject: Re: [mif] [dhcwg] Conflict between RA and DHCP in MIF case 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, 21 Nov 2011 20:36:19 -0000 Ted Lemon writes: > On Nov 14, 2011, at 9:59 AM, "Ole Troan" wrote: > > why not just merge all the information received? > > e.g. if you get DNS server over DHCP and RA, use all. > > if you get addresses via SLAAC and DHCP, you use all... > Because "just merge" is essentially equivalent to "just walk across > the river without your feet getting wet.". If you can write a spec > that does this correctly, you are probably the Messiah. Isn't this what DHC already does? I.e., you run DHCP on two interfaces, and get conflicting information. The existing DHCP specs are silent on this, and the DHC WG has never been willing to specify how to handle this case. The case of getting conflicting DNS configuration information via DHC seems a realistic scenario to me. How do you propose this get handled? Are you proposing we solve it for the DHC/RA case, but not for the DHC/DHC case? Thomas From Ted.Lemon@nominum.com Mon Nov 21 13:45:56 2011 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 87C9F11E8119; Mon, 21 Nov 2011 13:45:56 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.573 X-Spam-Level: X-Spam-Status: No, score=-106.573 tagged_above=-999 required=5 tests=[AWL=0.026, 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 6X8DUkiQTjOt; Mon, 21 Nov 2011 13:45:56 -0800 (PST) Received: from exprod7og114.obsmtp.com (exprod7og114.obsmtp.com [64.18.2.215]) by ietfa.amsl.com (Postfix) with ESMTP id B789211E80ED; Mon, 21 Nov 2011 13:45:54 -0800 (PST) Received: from shell-too.nominum.com ([64.89.228.229]) (using TLSv1) by exprod7ob114.postini.com ([64.18.6.12]) with SMTP ID DSNKTsrGiYlpmWw6Jm1FRFAY2302acyTXPM/@postini.com; Mon, 21 Nov 2011 13:45:55 PST 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 5B6671B826E; Mon, 21 Nov 2011 13:45:45 -0800 (PST) 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 3B379190052; Mon, 21 Nov 2011 13:45:42 -0800 (PST) (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.01.0339.001; Mon, 21 Nov 2011 13:45:42 -0800 From: Ted Lemon To: Thomas Narten Thread-Topic: [dhcwg] Conflict between RA and DHCP in MIF case Thread-Index: AQHMom9Jeyu5uv/47kCfd4auwPXOIJWsI2EA//+A3MeADLdcAIAAE2+A Date: Mon, 21 Nov 2011 21:45:41 +0000 Message-ID: <0DF2CC29-9D10-4DCB-8B12-7216D628FAAF@nominum.com> References: , <402398CF-7F7C-4B8B-91CE-6EDE54B6C4CC@employees.org> <23BACC91-621A-4E96-ACD6-92D226F9657A@nominum.com> <201111212036.pALKa0eO019515@cichlid.raleigh.ibm.com> In-Reply-To: <201111212036.pALKa0eO019515@cichlid.raleigh.ibm.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-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "ipv6@ietf.org" , MIF Mailing List , dhc WG Subject: Re: [mif] [dhcwg] Conflict between RA and DHCP in MIF case 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, 21 Nov 2011 21:45:56 -0000 On Nov 21, 2011, at 3:36 PM, Thomas Narten wrote: > Isn't this what DHC already does? I.e., you run DHCP on two > interfaces, and get conflicting information. I don't know what the antecedent to "this" was intended to be. > The existing DHCP specs are silent on this, and the DHC WG has never > been willing to specify how to handle this case. Right, because it's been our position that this is not a DHCP problem. > The case of getting conflicting DNS configuration information via DHC > seems a realistic scenario to me. It is completely realistic. > How do you propose this get handled? I think the right way to handle this is the way that the MIF working group = has proposed: treat each provisioning domain separately. Do not try to me= rge information you have no basis for assuming is valid across provisioning= domains (which is all configuration information). You wouldn't typically= send an IP packet with a source address for interface 2 out of interface 2= . Why would you query a DNS server out of interface 2 when you learned ab= out it through interface 1? > Are you proposing we solve it for the DHC/RA case, but not for the > DHC/DHC case? I think that having two ways of configuring things is a bad idea, and hence= I claim that standardizing the RA DNS server option was a mistake, one whi= ch unfortunately can't be undone at this point. I think that if we are go= ing to say that RAs and DHCP servers can both provide some piece of configu= ration information, then we kind of have to treat them as separate provisio= ning domains. But we can't really do that, because some information is pr= ovided only in RAs at the moment. My main wish is just to not make the mess any worse; secondarily, I'd like = to do what we can to make it less bad.= From marc.blanchet@viagenie.ca Mon Nov 21 13:58:09 2011 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 D88B721F87D3; Mon, 21 Nov 2011 13:58:09 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.483 X-Spam-Level: X-Spam-Status: No, score=-102.483 tagged_above=-999 required=5 tests=[AWL=0.116, 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 qpWC+ip-28dw; Mon, 21 Nov 2011 13:57:49 -0800 (PST) Received: from jazz.viagenie.ca (jazz.viagenie.ca [206.123.31.2]) by ietfa.amsl.com (Postfix) with ESMTP id 9791A21F8593; Mon, 21 Nov 2011 13:57:49 -0800 (PST) Received: from [IPv6:2607:fa48:6e6b:c280:15c9:6087:dafd:d077] (unknown [IPv6:2607:fa48:6e6b:c280:15c9:6087:dafd:d077]) by jazz.viagenie.ca (Postfix) with ESMTPSA id D384621F6D; Mon, 21 Nov 2011 16:57:18 -0500 (EST) Content-Type: text/plain; charset=iso-8859-1 Mime-Version: 1.0 (Apple Message framework v1251.1) From: Marc Blanchet In-Reply-To: <0DF2CC29-9D10-4DCB-8B12-7216D628FAAF@nominum.com> Date: Mon, 21 Nov 2011 16:57:18 -0500 Content-Transfer-Encoding: quoted-printable Message-Id: <5A43AEC2-9EF2-4F54-8ECE-76A254DD1B39@viagenie.ca> References: , <402398CF-7F7C-4B8B-91CE-6EDE54B6C4CC@employees.org> <23BACC91-621A-4E96-ACD6-92D226F9657A@nominum.com> <201111212036.pALKa0eO019515@cichlid.raleigh.ibm.com> <0DF2CC29-9D10-4DCB-8B12-7216D628FAAF@nominum.com> To: ipv6@ietf.org, MIF Mailing List , dhc WG X-Mailer: Apple Mail (2.1251.1) Subject: Re: [mif] [dhcwg] Conflict between RA and DHCP in MIF case 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, 21 Nov 2011 21:58:10 -0000 my take: the MIF problem statement draft about to be published as RFC) = discusses the various scenarios. probably more exists. But the issue of = receiving config info from multiple sources is not specific to dhcpv6. = it is related to any protocol sending config info. so it is a problem of = pppv4, pppv6, dhcpv4, dhcpv6, RA, maybe even others. Therefore, we need = to find the right solution for all the cases together, instead of just = looking at one specific provisioning protocol IP address family. In = this context, it appears to me that the right place to discuss that is = within MIF wg. my 2 cents. Marc. Le 2011-11-21 =E0 16:45, Ted Lemon a =E9crit : > On Nov 21, 2011, at 3:36 PM, Thomas Narten wrote: >> Isn't this what DHC already does? I.e., you run DHCP on two >> interfaces, and get conflicting information. >=20 > I don't know what the antecedent to "this" was intended to be. >=20 >> The existing DHCP specs are silent on this, and the DHC WG has never >> been willing to specify how to handle this case. >=20 > Right, because it's been our position that this is not a DHCP problem. >=20 >> The case of getting conflicting DNS configuration information via DHC >> seems a realistic scenario to me. >=20 > It is completely realistic. >=20 >> How do you propose this get handled? >=20 > I think the right way to handle this is the way that the MIF working = group has proposed: treat each provisioning domain separately. Do not = try to merge information you have no basis for assuming is valid across = provisioning domains (which is all configuration information). You = wouldn't typically send an IP packet with a source address for interface = 2 out of interface 2. Why would you query a DNS server out of = interface 2 when you learned about it through interface 1? >=20 >> Are you proposing we solve it for the DHC/RA case, but not for the >> DHC/DHC case? >=20 > I think that having two ways of configuring things is a bad idea, and = hence I claim that standardizing the RA DNS server option was a mistake, = one which unfortunately can't be undone at this point. I think that if = we are going to say that RAs and DHCP servers can both provide some = piece of configuration information, then we kind of have to treat them = as separate provisioning domains. But we can't really do that, because = some information is provided only in RAs at the moment. >=20 > My main wish is just to not make the mess any worse; secondarily, I'd = like to do what we can to make it less bad. > _______________________________________________ > dhcwg mailing list > dhcwg@ietf.org > https://www.ietf.org/mailman/listinfo/dhcwg From wwwrun@rfc-editor.org Mon Nov 21 22:09:11 2011 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 DB78F21F888A; Mon, 21 Nov 2011 22:09:11 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.497 X-Spam-Level: X-Spam-Status: No, score=-102.497 tagged_above=-999 required=5 tests=[AWL=0.103, BAYES_00=-2.599, NO_RELAYS=-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 XMPV5QtvBGJ6; Mon, 21 Nov 2011 22:09:11 -0800 (PST) Received: from rfc-editor.org (rfc-editor.org [IPv6:2001:1890:123a::1:2f]) by ietfa.amsl.com (Postfix) with ESMTP id 5DC7821F8C3E; Mon, 21 Nov 2011 22:09:11 -0800 (PST) Received: by rfc-editor.org (Postfix, from userid 30) id EA2D5B1E017; Mon, 21 Nov 2011 22:03:32 -0800 (PST) To: ietf-announce@ietf.org, rfc-dist@rfc-editor.org From: rfc-editor@rfc-editor.org Message-Id: <20111122060336.EA2D5B1E017@rfc-editor.org> Date: Mon, 21 Nov 2011 22:03:32 -0800 (PST) Cc: mif@ietf.org, rfc-editor@rfc-editor.org Subject: [mif] RFC 6418 on Multiple Interfaces and Provisioning Domains Problem Statement 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, 22 Nov 2011 06:09:12 -0000 A new Request for Comments is now available in online RFC libraries. RFC 6418 Title: Multiple Interfaces and Provisioning Domains Problem Statement Author: M. Blanchet, P. Seite Status: Informational Stream: IETF Date: November 2011 Mailbox: Marc.Blanchet@viagenie.ca, pierrick.seite@orange.com Pages: 22 Characters: 50537 Updates/Obsoletes/SeeAlso: None I-D Tag: draft-ietf-mif-problem-statement-15.txt URL: http://www.rfc-editor.org/rfc/rfc6418.txt This document describes issues encountered by a node attached to multiple provisioning domains. This node receives configuration information from each of its provisioning domains, where some configuration objects are global to the node and others are local to the interface. Issues such as selecting the wrong interface to send traffic happen when conflicting node-scoped configuration objects are received and inappropriately used. Moreover, other issues are the result of simultaneous attachment to multiple networks, such as domain selection or addressing and naming space overlaps, regardless of the provisioning mechanism. While multiple provisioning domains are typically seen on nodes with multiple interfaces, this document also discusses situations involving single-interface nodes. This document is not an Internet Standards Track specification; it is published for informational purposes. This document is a product of the Multiple Interfaces Working Group of the IETF. INFORMATIONAL: This memo provides information for the Internet community. It does not specify an Internet standard of any kind. Distribution of this memo is unlimited. This announcement is sent to the IETF-Announce and rfc-dist lists. To subscribe or unsubscribe, see http://www.ietf.org/mailman/listinfo/ietf-announce http://mailman.rfc-editor.org/mailman/listinfo/rfc-dist For searching the RFC series, see http://www.rfc-editor.org/rfcsearch.html. For downloading RFCs, see http://www.rfc-editor.org/rfc.html. Requests for special distribution should be addressed to either the author of the RFC in question, or to rfc-editor@rfc-editor.org. Unless specifically noted otherwise on the RFC itself, all RFCs are for unlimited distribution. The RFC Editor Team Association Management Solutions, LLC From wwwrun@rfc-editor.org Mon Nov 21 22:20:46 2011 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 39DBA21F8AEE; Mon, 21 Nov 2011 22:20:46 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.497 X-Spam-Level: X-Spam-Status: No, score=-102.497 tagged_above=-999 required=5 tests=[AWL=0.103, BAYES_00=-2.599, NO_RELAYS=-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 rYL3Tuh9joMU; Mon, 21 Nov 2011 22:20:45 -0800 (PST) Received: from rfc-editor.org (rfc-editor.org [IPv6:2001:1890:123a::1:2f]) by ietfa.amsl.com (Postfix) with ESMTP id 8CF3921F8AEC; Mon, 21 Nov 2011 22:20:45 -0800 (PST) Received: by rfc-editor.org (Postfix, from userid 30) id DF26DB1E013; Mon, 21 Nov 2011 22:03:47 -0800 (PST) To: ietf-announce@ietf.org, rfc-dist@rfc-editor.org From: rfc-editor@rfc-editor.org Message-Id: <20111122060348.DF26DB1E013@rfc-editor.org> Date: Mon, 21 Nov 2011 22:03:47 -0800 (PST) Cc: mif@ietf.org, rfc-editor@rfc-editor.org Subject: [mif] RFC 6419 on Current Practices for Multiple-Interface Hosts 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, 22 Nov 2011 06:20:46 -0000 A new Request for Comments is now available in online RFC libraries. RFC 6419 Title: Current Practices for Multiple-Interface Hosts Author: M. Wasserman, P. Seite Status: Informational Stream: IETF Date: November 2011 Mailbox: mrw@painless-security.com, pierrick.seite@orange-ftgroup.com Pages: 21 Characters: 51809 Updates/Obsoletes/SeeAlso: None I-D Tag: draft-ietf-mif-current-practices-12.txt URL: http://www.rfc-editor.org/rfc/rfc6419.txt An increasing number of hosts are operating in multiple-interface environments. This document summarizes current practices in this area and describes in detail how some common operating systems cope with challenges that ensue from this context. This document is not an Internet Standards Track specification; it is published for informational purposes. This document is a product of the Multiple Interfaces Working Group of the IETF. INFORMATIONAL: This memo provides information for the Internet community. It does not specify an Internet standard of any kind. Distribution of this memo is unlimited. This announcement is sent to the IETF-Announce and rfc-dist lists. To subscribe or unsubscribe, see http://www.ietf.org/mailman/listinfo/ietf-announce http://mailman.rfc-editor.org/mailman/listinfo/rfc-dist For searching the RFC series, see http://www.rfc-editor.org/rfcsearch.html. For downloading RFCs, see http://www.rfc-editor.org/rfc.html. Requests for special distribution should be addressed to either the author of the RFC in question, or to rfc-editor@rfc-editor.org. Unless specifically noted otherwise on the RFC itself, all RFCs are for unlimited distribution. The RFC Editor Team Association Management Solutions, LLC From alexandru.petrescu@gmail.com Tue Nov 22 01:19:16 2011 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 8BFD421F8D29 for ; Tue, 22 Nov 2011 01:19:16 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.281 X-Spam-Level: X-Spam-Status: No, score=-6.281 tagged_above=-999 required=5 tests=[AWL=-0.032, 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 7zKzoM3oPZba for ; Tue, 22 Nov 2011 01:19:16 -0800 (PST) Received: from oxalide-out.extra.cea.fr (oxalide-out.extra.cea.fr [132.168.224.8]) by ietfa.amsl.com (Postfix) with ESMTP id C811F21F8D27 for ; Tue, 22 Nov 2011 01:19:15 -0800 (PST) Received: from pisaure.intra.cea.fr (pisaure.intra.cea.fr [132.166.88.21]) by oxalide.extra.cea.fr (8.14.2/8.14.2/CEAnet-Internet-out-2.2) with ESMTP id pAM9JDnD030607 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Tue, 22 Nov 2011 10:19:13 +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 pAM9JDR0007814; Tue, 22 Nov 2011 10:19:13 +0100 (envelope-from alexandru.petrescu@gmail.com) Received: from [127.0.0.1] ([132.166.133.173]) by muguet2.intra.cea.fr (8.13.8/8.13.8/CEAnet-Intranet-out-1.1) with ESMTP id pAM9J3wq012135; Tue, 22 Nov 2011 10:19:13 +0100 Message-ID: <4ECB6907.3010208@gmail.com> Date: Tue, 22 Nov 2011 10:19:03 +0100 From: Alexandru Petrescu User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:8.0) Gecko/20111105 Thunderbird/8.0 MIME-Version: 1.0 To: Ted Lemon References: <282BBE8A501E1F4DA9C775F964BB21FE3EB78C3C98@GRFMBX704BA020.griffon.local> <916CE6CF87173740BC8A2CE44309696204193417@008-AM1MPN1-053.mgdnok.nokia.com> <4EC512A2.2060509@gmail.com>, <4EC63564.4080101@gmail.com> <816B77CB-F8A4-42CD-AE66-30789883BACC@nominum.com> In-Reply-To: <816B77CB-F8A4-42CD-AE66-30789883BACC@nominum.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Cc: "mif@ietf.org" Subject: Re: [mif] Use cases for draft-ietf-mif-dhcpv6-route-option needed 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, 22 Nov 2011 09:19:16 -0000 Le 18/11/2011 22:53, Ted Lemon a écrit : > On Nov 18, 2011, at 6:37 PM, "Alexandru > Petrescu" wrote: >> I pick one use-case I am particularly concerned with: router device >> with limited memory and CPU MHz connected to low-rate cellular >> forced into using both DHCP and RA software. It would better use >> only one software implementation (not 2), and do a short exchanges >> of messages (4 messages instead of 6) to obtain: default route, >> prefix, address, DNS server. > > Can you tell us more about this device? I didn't know people made > devices this small anymore other than in the distributed sensor > network environment (e.g., lowpan). Well, there exist machine-class devices which are that small and don't aren't necessarily lowpan ("p" would be replaced by a "w"). For example "M2M" devices. Alex From alexandru.petrescu@gmail.com Tue Nov 22 01:43:19 2011 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 8859E21F8C76 for ; Tue, 22 Nov 2011 01:43:19 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.279 X-Spam-Level: X-Spam-Status: No, score=-6.279 tagged_above=-999 required=5 tests=[AWL=-0.030, 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 rF6LLXmv4BFP for ; Tue, 22 Nov 2011 01:43:19 -0800 (PST) Received: from sainfoin-out.extra.cea.fr (sainfoin-out.extra.cea.fr [132.167.192.144]) by ietfa.amsl.com (Postfix) with ESMTP id 9E89D21F8C74 for ; Tue, 22 Nov 2011 01:43:18 -0800 (PST) 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.2) with ESMTP id pAM9hHt4004956 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Tue, 22 Nov 2011 10:43:17 +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 pAM9hGqF021111; Tue, 22 Nov 2011 10:43:16 +0100 (envelope-from alexandru.petrescu@gmail.com) Received: from [127.0.0.1] ([132.166.133.173]) by muguet2.intra.cea.fr (8.13.8/8.13.8/CEAnet-Intranet-out-1.1) with ESMTP id pAM9hAcf029086; Tue, 22 Nov 2011 10:43:16 +0100 Message-ID: <4ECB6EAE.2010701@gmail.com> Date: Tue, 22 Nov 2011 10:43:10 +0100 From: Alexandru Petrescu User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:8.0) Gecko/20111105 Thunderbird/8.0 MIME-Version: 1.0 To: Ted Lemon References: <282BBE8A501E1F4DA9C775F964BB21FE3EB78C3C98@GRFMBX704BA020.griffon.local> <916CE6CF87173740BC8A2CE44309696204193417@008-AM1MPN1-053.mgdnok.nokia.com>, <4EC512A2.2060509@gmail.com> <890A58CF-8EAD-4F92-9981-9B5AA07EBF00@nominum.com>, <4EC63E26.70104@gmail.com> <86163A8F-8628-4F67-BE93-3747F95A2F52@nominum.com> In-Reply-To: <86163A8F-8628-4F67-BE93-3747F95A2F52@nominum.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Cc: "mif@ietf.org" Subject: Re: [mif] Use cases for draft-ietf-mif-dhcpv6-route-option needed 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, 22 Nov 2011 09:43:19 -0000 Le 18/11/2011 22:58, Ted Lemon a écrit : > On Nov 18, 2011, at 7:14 PM, "Alexandru > Petrescu" wrote: >> But don't scare people away with the word "deployment". Initial >> deployments are often just lab settings, a desk, a pocket >> sometimes. > > Sure, but the question is whether you have a real situation where you > are forced to use DHCP and not RA, or just a hypothetical situation. > >> RA defroutes don't work for me because there may be not enough >> memory space next to the DHCP daemon on a 400MHz ARM processor of >> mobile router. > > Huh, I have a 400MHz ARM system that runs a full Linux kernel > including DHCPv4 client and RA (which is in the kernel). It's a > Sheeva CPU, so it's a little slow, but I haven't had any problems at > all with this: where I've had problems is compiling kernels in > reasonable amounts of time. So I really, really have trouble > believing that this device can't do RA. Sure, a 400MHz device could have large enough memory to hold both DHCP and ND implementations. However, if one tries to reduce the software to a bare minimum then one would eliminate as many components as possible - and RA vs DHCP is obvious duplicate functionality, double code line counts. This would give place for other necessary components like a route exchange software. When memory is limited there is compromise to be made, and software components to be traded off. >> No, it is not this reason for me. In my particular case I am >> fully aware of RAs offering defroute, and aware of DHCPv4 and >> DHCPv6 Relays. In my lab setting it is easier to maintain de conf >> files centrally on a unique machine rather than on 5-like Access >> Routers. I do not have a std mechanism to remotely update the RA >> information these Access Routers offer. But for DHCP I have this >> central conf file. > > Okay, so why do you want this? I don't mean to say you shouldn't > want it, but can you explain why you want it? I emulate a wifi operator network: several Access Routers and a single point maintaining the dhcp conf files. Some AR may offer the Default Route of another router on the same link (hence the need to have conf files). Alex >> I do not work for a vendor. I don't see why calling the DHCP >> defroute a "vendor" option. On another hand I could agree with it >> being EXPERIMENTAL at this point in time. > > As Lorenzo said in the meeting, if you give it an option code, it > will see wide implementation, regardless of whether it's standard, > informational or experimental, because lots of people say they want > it. So from an architectural standpoint, we can't punt on the > question of whether we need it. From ichiroumakino@gmail.com Tue Nov 22 05:18:40 2011 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 4FFB921F8CA3; Tue, 22 Nov 2011 05:18:40 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.559 X-Spam-Level: X-Spam-Status: No, score=-3.559 tagged_above=-999 required=5 tests=[AWL=0.040, 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 Cjh+Xw5uZ9-H; Tue, 22 Nov 2011 05:18:39 -0800 (PST) Received: from mail-ww0-f42.google.com (mail-ww0-f42.google.com [74.125.82.42]) by ietfa.amsl.com (Postfix) with ESMTP id 2C1D821F8CA2; Tue, 22 Nov 2011 05:18:39 -0800 (PST) Received: by wwe3 with SMTP id 3so7216977wwe.1 for ; Tue, 22 Nov 2011 05:18:37 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=sender:subject:mime-version:content-type:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to:x-mailer; bh=vLvqvycQR/Qk+9s7/K25kYzjx+PRYb60ICw9p3eT+pk=; b=hjLk2ozLzE45FWBL/6snPxKd/lcMDxUjvnqXs/RM/8HdGtuUb7vakItOLtuDbrevqm 0VLXBuI/oB4DHIh4/7lgujJsaiwX8xulxZgf3wEJRVIGQslRR/DFV6lKoDGvYJR8PY3W 6+uDh8SbgrHtKHr1I+dqAmNDiUnqoMKXPtZpM= Received: by 10.227.207.146 with SMTP id fy18mr8335362wbb.18.1321967916906; Tue, 22 Nov 2011 05:18:36 -0800 (PST) Received: from ams3-vpn-dhcp4888.cisco.com (64-103-25-233.cisco.com. [64.103.25.233]) by mx.google.com with ESMTPS id em4sm16579372wbb.20.2011.11.22.05.18.32 (version=TLSv1/SSLv3 cipher=OTHER); Tue, 22 Nov 2011 05:18:35 -0800 (PST) Sender: Ole Troan Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Ole Troan In-Reply-To: <0DF2CC29-9D10-4DCB-8B12-7216D628FAAF@nominum.com> Date: Tue, 22 Nov 2011 14:18:31 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: References: , <402398CF-7F7C-4B8B-91CE-6EDE54B6C4CC@employees.org> <23BACC91-621A-4E96-ACD6-92D226F9657A@nominum.com> <201111212036.pALKa0eO019515@cichlid.raleigh.ibm.com> <0DF2CC29-9D10-4DCB-8B12-7216D628FAAF@nominum.com> To: Ted Lemon X-Mailer: Apple Mail (2.1084) Cc: Thomas Narten , MIF Mailing List , "ipv6@ietf.org" , dhc WG Subject: Re: [mif] [dhcwg] Conflict between RA and DHCP in MIF case 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, 22 Nov 2011 13:18:40 -0000 >> How do you propose this get handled? >=20 > I think the right way to handle this is the way that the MIF working = group has proposed: treat each provisioning domain separately. Do not = try to merge information you have no basis for assuming is valid across = provisioning domains (which is all configuration information). You = wouldn't typically send an IP packet with a source address for interface = 2 out of interface 2. Why would you query a DNS server out of = interface 2 when you learned about it through interface 1? for clarification, that was not my proposal. my suggestion was to merge = all information within one "provisioning domain". unsure if we will end up with provisioning domain =3D link, as detection = of multiple provisioning domains on a single link may not be trivial in = all corner cases. cheers, Ole From Ted.Lemon@nominum.com Tue Nov 22 07:20:54 2011 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 CB1FA11E807F for ; Tue, 22 Nov 2011 07:20:54 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.573 X-Spam-Level: X-Spam-Status: No, score=-106.573 tagged_above=-999 required=5 tests=[AWL=0.025, 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 E94uiOym8JYZ for ; Tue, 22 Nov 2011 07:20:54 -0800 (PST) Received: from exprod7og108.obsmtp.com (exprod7og108.obsmtp.com [64.18.2.169]) by ietfa.amsl.com (Postfix) with ESMTP id D9CE811E808F for ; Tue, 22 Nov 2011 07:20:53 -0800 (PST) Received: from shell-too.nominum.com ([64.89.228.229]) (using TLSv1) by exprod7ob108.postini.com ([64.18.6.12]) with SMTP ID DSNKTsu9zt5oCeiyodTNNiNsptUMa+Dq/b14@postini.com; Tue, 22 Nov 2011 07:20:53 PST 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 232EC1B8164 for ; Tue, 22 Nov 2011 07:20:46 -0800 (PST) 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 0EEB6190052; Tue, 22 Nov 2011 07:20:46 -0800 (PST) (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.01.0339.001; Tue, 22 Nov 2011 07:20:46 -0800 From: Ted Lemon To: Alexandru Petrescu Thread-Topic: [mif] Use cases for draft-ietf-mif-dhcpv6-route-option needed Thread-Index: AQHMpd4WcQWUV79AAkeKKGYg/SGVkpWzLSojgAX8w4CAAGUOAA== Date: Tue, 22 Nov 2011 15:20:45 +0000 Message-ID: <5A4822FC-5666-4EF7-AD91-8D8A08F6ECFE@nominum.com> References: <282BBE8A501E1F4DA9C775F964BB21FE3EB78C3C98@GRFMBX704BA020.griffon.local> <916CE6CF87173740BC8A2CE44309696204193417@008-AM1MPN1-053.mgdnok.nokia.com> <4EC512A2.2060509@gmail.com>,<4EC63564.4080101@gmail.com> <816B77CB-F8A4-42CD-AE66-30789883BACC@nominum.com> <4ECB6907.3010208@gmail.com> In-Reply-To: <4ECB6907.3010208@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_5A4822FC56664EF7AD918D8A08F6ECFEnominumcom_" MIME-Version: 1.0 Cc: "mif@ietf.org" Subject: Re: [mif] Use cases for draft-ietf-mif-dhcpv6-route-option needed 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, 22 Nov 2011 15:20:54 -0000 --_000_5A4822FC56664EF7AD918D8A08F6ECFEnominumcom_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable On Nov 22, 2011, at 4:19 AM, Alexandru Petrescu wrote: Well, there exist machine-class devices which are that small and don't aren= 't necessarily lowpan ("p" would be replaced by a "w"). For example "M2M" = devices. I don't see anything about m2m that precludes implementing RA. --_000_5A4822FC56664EF7AD918D8A08F6ECFEnominumcom_ Content-Type: text/html; charset="iso-8859-1" Content-ID: <3AEB24105C7D4C4BAA5736A77DD352DD@nominum.com> Content-Transfer-Encoding: quoted-printable
On Nov 22, 2011, at 4:19 AM, Alexandru Petrescu wrote:
Well, there exist machine-class devices which are that small and don't aren't ne= cessarily lowpan ("p" would be replaced by a "w"). &nbs= p;For example "M2M" devices.

I don't see anything about m2m that precludes implementing RA.

--_000_5A4822FC56664EF7AD918D8A08F6ECFEnominumcom_-- From Ted.Lemon@nominum.com Tue Nov 22 07:25:54 2011 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 499B51F0C9C for ; Tue, 22 Nov 2011 07:25:54 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.574 X-Spam-Level: X-Spam-Status: No, score=-106.574 tagged_above=-999 required=5 tests=[AWL=0.024, 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 aEekDx5dUISo for ; Tue, 22 Nov 2011 07:25:53 -0800 (PST) Received: from exprod7og107.obsmtp.com (exprod7og107.obsmtp.com [64.18.2.167]) by ietfa.amsl.com (Postfix) with ESMTP id 6A86C1F0C98 for ; Tue, 22 Nov 2011 07:25:53 -0800 (PST) Received: from shell-too.nominum.com ([64.89.228.229]) (using TLSv1) by exprod7ob107.postini.com ([64.18.6.12]) with SMTP ID DSNKTsu++zubYTN02V4SYZ87fvLFc8IEGVa2@postini.com; Tue, 22 Nov 2011 07:25:53 PST 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 49CE01B8164 for ; Tue, 22 Nov 2011 07:25:47 -0800 (PST) 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 4141C190052; Tue, 22 Nov 2011 07:25:47 -0800 (PST) (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.01.0339.001; Tue, 22 Nov 2011 07:25:47 -0800 From: Ted Lemon To: Alexandru Petrescu Thread-Topic: [mif] Use cases for draft-ietf-mif-dhcpv6-route-option needed Thread-Index: AQHMpeNOuu/E0pVKc0uk0cJFS4z9vZWzLpa7gAYCCQCAAF+4gA== Date: Tue, 22 Nov 2011 15:25:46 +0000 Message-ID: <702C34B3-F6B7-4EFB-91D5-8538540534A1@nominum.com> References: <282BBE8A501E1F4DA9C775F964BB21FE3EB78C3C98@GRFMBX704BA020.griffon.local> <916CE6CF87173740BC8A2CE44309696204193417@008-AM1MPN1-053.mgdnok.nokia.com>, <4EC512A2.2060509@gmail.com> <890A58CF-8EAD-4F92-9981-9B5AA07EBF00@nominum.com>, <4EC63E26.70104@gmail.com> <86163A8F-8628-4F67-BE93-3747F95A2F52@nominum.com> <4ECB6EAE.2010701@gmail.com> In-Reply-To: <4ECB6EAE.2010701@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_702C34B3F6B74EFB91D58538540534A1nominumcom_" MIME-Version: 1.0 Cc: "mif@ietf.org" Subject: Re: [mif] Use cases for draft-ietf-mif-dhcpv6-route-option needed 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, 22 Nov 2011 15:25:54 -0000 --_000_702C34B3F6B74EFB91D58538540534A1nominumcom_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable On Nov 22, 2011, at 4:43 AM, Alexandru Petrescu wrote: Sure, a 400MHz device could have large enough memory to hold both DHCP and = ND implementations. However, if one tries to reduce the software to a bare= minimum then one would eliminate as many components as possible - and RA v= s DHCP is obvious duplicate functionality, double code line counts. This w= ould give place for other necessary components like a route exchange softwa= re. When memory is limited there is compromise to be made, and software compone= nts to be traded off. Look, I'm sorry, but this is just not convincing. RA is trivial. DHCPv6 = clients are trivial. If you can't cram both of these into your ARM stack,= you are doing something wrong. --_000_702C34B3F6B74EFB91D58538540534A1nominumcom_ Content-Type: text/html; charset="iso-8859-1" Content-ID: Content-Transfer-Encoding: quoted-printable
On Nov 22, 2011, at 4:43 AM, Alexandru Petrescu wrote:
Sure, a 400MHz device could have large enough memory to hold both DHCP and ND im= plementations.  However, if one tries to reduce the software to a bare= minimum then one would eliminate as many components as possible - and RA v= s DHCP is obvious duplicate functionality, double code line counts.  This would give place for other necessary c= omponents like a route exchange software.

When memory is limited there is compromise to be made, and software compone= nts to be traded off.

Look, I'm sorry, but this is just not convincing.  RA is trivial.=   DHCPv6 clients are trivial.   If you can't cram both of these = into your ARM stack, you are doing something wrong.

--_000_702C34B3F6B74EFB91D58538540534A1nominumcom_-- From Ted.Lemon@nominum.com Tue Nov 22 07:31:46 2011 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 5E0A021F8C6B; Tue, 22 Nov 2011 07:31:46 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.574 X-Spam-Level: X-Spam-Status: No, score=-106.574 tagged_above=-999 required=5 tests=[AWL=0.024, 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 XVQMgANepJNT; Tue, 22 Nov 2011 07:31:45 -0800 (PST) Received: from exprod7og118.obsmtp.com (exprod7og118.obsmtp.com [64.18.2.8]) by ietfa.amsl.com (Postfix) with ESMTP id 4B28C21F8C60; Tue, 22 Nov 2011 07:31:45 -0800 (PST) Received: from shell-too.nominum.com ([64.89.228.229]) (using TLSv1) by exprod7ob118.postini.com ([64.18.6.12]) with SMTP ID DSNKTsvAYCxrZBBXrBtpYQP4cofz7XIKlAc7@postini.com; Tue, 22 Nov 2011 07:31:45 PST 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 4EBE41B827D; Tue, 22 Nov 2011 07:31:44 -0800 (PST) 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 3B048190052; Tue, 22 Nov 2011 07:31:44 -0800 (PST) (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.01.0339.001; Tue, 22 Nov 2011 07:31:44 -0800 From: Ted Lemon To: Ole Troan Thread-Topic: [dhcwg] Conflict between RA and DHCP in MIF case Thread-Index: AQHMom9Jeyu5uv/47kCfd4auwPXOIJWsI2EA//+A3MeADLdcAIAAE2+AgAEEqoCAACU3AA== Date: Tue, 22 Nov 2011 15:31:43 +0000 Message-ID: References: , <402398CF-7F7C-4B8B-91CE-6EDE54B6C4CC@employees.org> <23BACC91-621A-4E96-ACD6-92D226F9657A@nominum.com> <201111212036.pALKa0eO019515@cichlid.raleigh.ibm.com> <0DF2CC29-9D10-4DCB-8B12-7216D628FAAF@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: multipart/alternative; boundary="_000_DF1C8CC913D0494BAB455A17AECD1CB4nominumcom_" MIME-Version: 1.0 Cc: Thomas Narten , MIF Mailing List , "ipv6@ietf.org" , dhc WG Subject: Re: [mif] [dhcwg] Conflict between RA and DHCP in MIF case 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, 22 Nov 2011 15:31:46 -0000 --_000_DF1C8CC913D0494BAB455A17AECD1CB4nominumcom_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable On Nov 22, 2011, at 8:18 AM, Ole Troan wrote: for clarification, that was not my proposal. my suggestion was to merge all= information within one "provisioning domain". unsure if we will end up with provisioning domain =3D link, as detection of= multiple provisioning domains on a single link may not be trivial in all c= orner cases. I agree with you that right now detecting provisioning domains is not trivi= al; indeed, in some cases it's impossible. However, if you think provisio= ning domain =3D=3D link, then that's a problem that needs fixing. Indeed,= that's *the* problem that needs fixing. I think we have to fix it; if we= punt, we're going to pay for it later. --_000_DF1C8CC913D0494BAB455A17AECD1CB4nominumcom_ Content-Type: text/html; charset="us-ascii" Content-ID: <2DE43083E24BF04E9495A21BC58F95C9@nominum.com> Content-Transfer-Encoding: quoted-printable
On Nov 22, 2011, at 8:18 AM, Ole Troan wrote:
for clarification, that was not my proposal. my suggestion was to merge all in= formation within one "provisioning domain".
unsure if we will end up with provisioning domain =3D link, as detection of multi= ple provisioning domains on a single link may not be trivial in all corner = cases.

I agree with you that right now detecting provisioning domains is not = trivial; indeed, in some cases it's impossible.   However, if you thin= k provisioning domain =3D=3D link, then that's a problem that needs fixing.=   Indeed, that's *the* problem that needs fixing.   I think we have to fix it; if we punt, we're going to pay f= or it later.

--_000_DF1C8CC913D0494BAB455A17AECD1CB4nominumcom_-- From alexandru.petrescu@gmail.com Tue Nov 22 10:02:45 2011 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 AD7B21F0C42 for ; Tue, 22 Nov 2011 10:02:45 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.277 X-Spam-Level: X-Spam-Status: No, score=-6.277 tagged_above=-999 required=5 tests=[AWL=-0.028, 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 VollRrKUcX8V for ; Tue, 22 Nov 2011 10:02:45 -0800 (PST) Received: from oxalide-out.extra.cea.fr (oxalide-out.extra.cea.fr [132.168.224.8]) by ietfa.amsl.com (Postfix) with ESMTP id C29EF1F0C35 for ; Tue, 22 Nov 2011 10:02:44 -0800 (PST) Received: from pisaure.intra.cea.fr (pisaure.intra.cea.fr [132.166.88.21]) by oxalide.extra.cea.fr (8.14.2/8.14.2/CEAnet-Internet-out-2.2) with ESMTP id pAMI2gcI025994 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Tue, 22 Nov 2011 19:02:42 +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 pAMI2fqD018849; Tue, 22 Nov 2011 19:02:42 +0100 (envelope-from alexandru.petrescu@gmail.com) Received: from [127.0.0.1] ([132.166.133.173]) by muguet1.intra.cea.fr (8.13.8/8.13.8/CEAnet-Intranet-out-1.1) with ESMTP id pAMI2chE001401; Tue, 22 Nov 2011 19:02:41 +0100 Message-ID: <4ECBE3BE.5070501@gmail.com> Date: Tue, 22 Nov 2011 19:02:38 +0100 From: Alexandru Petrescu User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:8.0) Gecko/20111105 Thunderbird/8.0 MIME-Version: 1.0 To: Ted Lemon References: <282BBE8A501E1F4DA9C775F964BB21FE3EB78C3C98@GRFMBX704BA020.griffon.local> <916CE6CF87173740BC8A2CE44309696204193417@008-AM1MPN1-053.mgdnok.nokia.com>, <4EC512A2.2060509@gmail.com> <890A58CF-8EAD-4F92-9981-9B5AA07EBF00@nominum.com>, <4EC63E26.70104@gmail.com> <86163A8F-8628-4F67-BE93-3747F95A2F52@nominum.com> <4ECB6EAE.2010701@gmail.com> <702C34B3-F6B7-4EFB-91D5-8538540534A1@nominum.com> In-Reply-To: <702C34B3-F6B7-4EFB-91D5-8538540534A1@nominum.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Cc: "mif@ietf.org" Subject: Re: [mif] Use cases for draft-ietf-mif-dhcpv6-route-option needed 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, 22 Nov 2011 18:02:45 -0000 Le 22/11/2011 16:25, Ted Lemon a écrit : > On Nov 22, 2011, at 4:43 AM, Alexandru Petrescu wrote: >> Sure, a 400MHz device could have large enough memory to hold both >> DHCP and ND implementations. However, if one tries to reduce the >> software to a bare minimum then one would eliminate as many >> components as possible - and RA vs DHCP is obvious duplicate >> functionality, double code line counts. This would give place for >> other necessary components like a route exchange software. >> >> When memory is limited there is compromise to be made, and >> software components to be traded off. > > Look, I'm sorry, but this is just not convincing. RA is trivial. > DHCPv6 clients are trivial. If you can't cram both of these into > your ARM stack, you are doing something wrong. The similar userland-vs-kernel (read DHCP vs RA) discussion has it that it is easier to do one not both. (also relating to your earlier mentioning compiling being lengthy for ARM kernel - yes it is quicker to compile userland DHCP than kernel RA). Alex From Ted.Lemon@nominum.com Tue Nov 22 10:33:47 2011 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 89BBB11E8082 for ; Tue, 22 Nov 2011 10:33:47 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.574 X-Spam-Level: X-Spam-Status: No, score=-106.574 tagged_above=-999 required=5 tests=[AWL=0.024, 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 SHx1bDaemwEm for ; Tue, 22 Nov 2011 10:33:47 -0800 (PST) Received: from exprod7og122.obsmtp.com (exprod7og122.obsmtp.com [64.18.2.22]) by ietfa.amsl.com (Postfix) with ESMTP id C3D6421F8801 for ; Tue, 22 Nov 2011 10:33:46 -0800 (PST) Received: from shell-too.nominum.com ([64.89.228.229]) (using TLSv1) by exprod7ob122.postini.com ([64.18.6.12]) with SMTP ID DSNKTsvrCL4qvmHWkQnAJeOJ7Jy+lav1/kCv@postini.com; Tue, 22 Nov 2011 10:33:46 PST 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 62CDD1B812A for ; Tue, 22 Nov 2011 10:33:43 -0800 (PST) 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 A5622190052; Tue, 22 Nov 2011 10:33:41 -0800 (PST) (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.01.0339.001; Tue, 22 Nov 2011 10:33:41 -0800 From: Ted Lemon To: Alexandru Petrescu Thread-Topic: [mif] Use cases for draft-ietf-mif-dhcpv6-route-option needed Thread-Index: AQHMpeNOuu/E0pVKc0uk0cJFS4z9vZWzLpa7gAYCCQCAAF+4gIAAK9UAgAAIrAA= Date: Tue, 22 Nov 2011 18:33:41 +0000 Message-ID: <759E821F-B503-4C8D-A79B-5F9A68A3613F@nominum.com> References: <282BBE8A501E1F4DA9C775F964BB21FE3EB78C3C98@GRFMBX704BA020.griffon.local> <916CE6CF87173740BC8A2CE44309696204193417@008-AM1MPN1-053.mgdnok.nokia.com>, <4EC512A2.2060509@gmail.com> <890A58CF-8EAD-4F92-9981-9B5AA07EBF00@nominum.com>, <4EC63E26.70104@gmail.com> <86163A8F-8628-4F67-BE93-3747F95A2F52@nominum.com> <4ECB6EAE.2010701@gmail.com> <702C34B3-F6B7-4EFB-91D5-8538540534A1@nominum.com> <4ECBE3BE.5070501@gmail.com> In-Reply-To: <4ECBE3BE.5070501@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_759E821FB5034C8DA79B5F9A68A3613Fnominumcom_" MIME-Version: 1.0 Cc: "mif@ietf.org" Subject: Re: [mif] Use cases for draft-ietf-mif-dhcpv6-route-option needed 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, 22 Nov 2011 18:33:47 -0000 --_000_759E821FB5034C8DA79B5F9A68A3613Fnominumcom_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable On Nov 22, 2011, at 1:02 PM, Alexandru Petrescu wrote: The similar userland-vs-kernel (read DHCP vs RA) discussion has it that it is easier to do one not both. Of course it is easier to do one, not both. But it's no problem to do bot= h. (also relating to your earlier mentioning compiling being lengthy for ARM k= ernel - yes it is quicker to compile userland DHCP than kernel RA). This is easily solved by cross-compiling. --_000_759E821FB5034C8DA79B5F9A68A3613Fnominumcom_ Content-Type: text/html; charset="iso-8859-1" Content-ID: Content-Transfer-Encoding: quoted-printable
On Nov 22, 2011, at 1:02 PM, Alexandru Petrescu wrote:
The similar userland-vs-kernel (read DHCP vs RA) discussion has it that
it is easier to do one not both.

Of course it is easier to do one, not both.   But it's no problem to d= o both.

(also relating to your earlier mentioning compiling being lengthy for ARM kernel= - yes it is quicker to compile userland DHCP than kernel RA).

This is easily solved by cross-compiling.

--_000_759E821FB5034C8DA79B5F9A68A3613Fnominumcom_-- From denghui02@gmail.com Thu Nov 24 16:47:24 2011 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 7472811E80AF for ; Thu, 24 Nov 2011 16:47:24 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.598 X-Spam-Level: X-Spam-Status: No, score=-103.598 tagged_above=-999 required=5 tests=[AWL=-0.000, 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 KGWu661bxfNx for ; Thu, 24 Nov 2011 16:47:23 -0800 (PST) Received: from mail-yx0-f172.google.com (mail-yx0-f172.google.com [209.85.213.172]) by ietfa.amsl.com (Postfix) with ESMTP id B6FA411E80AE for ; Thu, 24 Nov 2011 16:47:23 -0800 (PST) Received: by yenl8 with SMTP id l8so555015yen.31 for ; Thu, 24 Nov 2011 16:47:23 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=JViQlrWHq0OYTf+8vnvs2F8IFa78VH/dBzMob+HgmSg=; b=aI6CgtnAfkFl7m/bmsLS7MRMWSzZ7OMeSQ3QvJCM2OSqx6Ef2veLyots2RcC3odufi j1tLbvv0/h2Hh3kpFTao/Q/uBm+rY6X+OyMyvkyJq81D2GsKueUjhh4FbnE/xQPqwn84 eKbIh1px5N8BwVSYhIztFHG0lNMMtDX5o6AIg= MIME-Version: 1.0 Received: by 10.236.77.232 with SMTP id d68mr43964540yhe.98.1322182041585; Thu, 24 Nov 2011 16:47:21 -0800 (PST) Received: by 10.146.84.10 with HTTP; Thu, 24 Nov 2011 16:47:21 -0800 (PST) In-Reply-To: References: <282BBE8A501E1F4DA9C775F964BB21FE3EB78C3C98@GRFMBX704BA020.griffon.local> <916CE6CF87173740BC8A2CE44309696204193417@008-AM1MPN1-053.mgdnok.nokia.com> <4EC512A2.2060509@gmail.com> <890A58CF-8EAD-4F92-9981-9B5AA07EBF00@nominum.com> <4EC5B720.8020605@gmail.com> <83A7D27A-9036-4252-AC94-3A89125C961B@nominum.com> <4EC63ECC.8010700@gmail.com> <20111119220355.GA893@shinkuro.com> Date: Fri, 25 Nov 2011 08:47:21 +0800 Message-ID: From: Hui Deng To: "Templin, Fred L" Content-Type: multipart/alternative; boundary=20cf300515c0eac78604b2847ee6 Cc: "mif@ietf.org" Subject: Re: [mif] IRON as a multiple interface solution 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, 25 Nov 2011 00:47:24 -0000 --20cf300515c0eac78604b2847ee6 Content-Type: text/plain; charset=ISO-8859-1 Hi Fred, MIF is not proposing any new solution for administative domain to solve fundamental problem like mobility by harness virtual interface /tunnel at this moment. Today it is just solveing basic problem existed in multiple administrative domains. For DNS selection problem, what I understand is IRON DNS can provide sub-domain information with only one DNS server, but here is assuming that there exists two different administrative domain where two different DNS server may reply different information each. Regards, -Hui 2011/11/22 Templin, Fred L > Hi Andrew, > > > -----Original Message----- > > From: mif-bounces@ietf.org [mailto:mif-bounces@ietf.org] On > > Behalf Of Andrew Sullivan > > Sent: Saturday, November 19, 2011 2:04 PM > > To: mif@ietf.org > > Subject: Re: [mif] IRON as a multiple interface solution > > > > On Fri, Nov 18, 2011 at 02:19:39PM -0800, Templin, Fred L wrote: > > > > > > If the host also connects to a home enterprise network > > > via a VPN, then that would be a separate administrative > > > domain and a separate tunnel virtual interface. Does > > > this help? > > > > It does, in that it seems to make it pretty hard to solve the multiple > > resolution context problem that the DNS server selection draft is > > trying to solve. > > What I was describing was what is sometimes called a > "Split Tunnel" scenario. AFAICT, any solution that > would address that scenario would be applicable also > to IRON, and not in any way made more difficult by IRON. > > Thanks - Fred > > > A > > > > -- > > Andrew Sullivan > > ajs@anvilwalrusden.com > > > > _______________________________________________ > > mif mailing list > > mif@ietf.org > > https://www.ietf.org/mailman/listinfo/mif > > > _______________________________________________ > mif mailing list > mif@ietf.org > https://www.ietf.org/mailman/listinfo/mif > --20cf300515c0eac78604b2847ee6 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Hi Fred,
=A0
MIF is not proposing any new solution for administative domain to solv= e fundamental problem like mobility by harness virtual interface /tunnel at= this moment.=A0Today it is just solveing basic problem existed=A0in multip= le administrative domains.
=A0
For DNS selection problem, what I understand is IRON DNS can provide s= ub-domain information with only one DNS server, but here is assuming that t= here exists two different administrative domain where two different DNS ser= ver may reply different information each.
=A0
Regards,
=A0
-Hui

2011/11/22 Templin, Fred L <= ;Fred.L.Templin@boeing.com= >
Hi Andrew,

> -----Orig= inal Message-----
> From: mif= -bounces@ietf.org [mailto:mif-b= ounces@ietf.org] On
> Behalf Of Andrew Sullivan
> Sent: Saturday, November 19, 2011 2:= 04 PM
> To: mif@ietf.org
> Subject: Re: [mif] IRON as a multiple interface solu= tion
>
> On Fri, Nov 18, 2011 at 02:19:39PM -0800, Templin, F= red L wrote:
> >
> > If the host also connects to a home = enterprise network
> > via a VPN, then that would be a separate ad= ministrative
> > domain and a separate tunnel virtual interface. Does
> >= this help?
>
> It does, in that it seems to make it pretty har= d to solve the multiple
> resolution context problem that the DNS ser= ver selection draft is
> trying to solve.

What I was describing was what is someti= mes called a
"Split Tunnel" scenario. AFAICT, any solution tha= t
would address that scenario would be applicable also
to IRON, and n= ot in any way made more difficult by IRON.

Thanks - Fred

> A
>
> --
> Andrew Sullivan
= > ajs@anvilwalrusden.com>
> _______________________________________________
> mif = mailing list
> mif@ietf.org
> https://www.ietf= .org/mailman/listinfo/mif
>
__________________________________= _____________
mif mailing list
mif@ietf.org
https:= //www.ietf.org/mailman/listinfo/mif
<= br> --20cf300515c0eac78604b2847ee6-- From Fred.L.Templin@boeing.com Mon Nov 28 09:23:01 2011 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 EB93F21F87FC for ; Mon, 28 Nov 2011 09:23:01 -0800 (PST) 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 MltE7wp5TPLO for ; Mon, 28 Nov 2011 09:23:01 -0800 (PST) Received: from stl-smtpout-01.boeing.com (stl-smtpout-01.boeing.com [130.76.96.56]) by ietfa.amsl.com (Postfix) with ESMTP id 31D0C21F8573 for ; Mon, 28 Nov 2011 09:23:00 -0800 (PST) Received: from blv-av-01.boeing.com (blv-av-01.boeing.com [130.247.48.231]) by stl-smtpout-01.ns.cs.boeing.com (8.14.4/8.14.4/8.14.4/SMTPOUT) with ESMTP id pASHMuEG023425 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Mon, 28 Nov 2011 11:22:57 -0600 (CST) Received: from localhost (localhost [127.0.0.1]) by blv-av-01.boeing.com (8.14.4/8.14.4/DOWNSTREAM_RELAY) with SMTP id pASHMo4D002682; Mon, 28 Nov 2011 09:22:50 -0800 (PST) Received: from XCH-NWHT-06.nw.nos.boeing.com (xch-nwht-06.nw.nos.boeing.com [130.247.25.110]) by blv-av-01.boeing.com (8.14.4/8.14.4/UPSTREAM_RELAY) with ESMTP id pASHMkaC002353 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=OK); Mon, 28 Nov 2011 09:22:46 -0800 (PST) Received: from XCH-NW-01V.nw.nos.boeing.com ([130.247.64.97]) by XCH-NWHT-06.nw.nos.boeing.com ([130.247.25.110]) with mapi; Mon, 28 Nov 2011 09:22:46 -0800 From: "Templin, Fred L" To: Hui Deng Date: Mon, 28 Nov 2011 09:22:45 -0800 Thread-Topic: [mif] IRON as a multiple interface solution Thread-Index: AcyrC8+8JrZcx8+gS5+NbOD13dx1mgC4qQ/A Message-ID: References: <282BBE8A501E1F4DA9C775F964BB21FE3EB78C3C98@GRFMBX704BA020.griffon.local> <916CE6CF87173740BC8A2CE44309696204193417@008-AM1MPN1-053.mgdnok.nokia.com> <4EC512A2.2060509@gmail.com> <890A58CF-8EAD-4F92-9981-9B5AA07EBF00@nominum.com> <4EC5B720.8020605@gmail.com> <83A7D27A-9036-4252-AC94-3A89125C961B@nominum.com> <4EC63ECC.8010700@gmail.com> <20111119220355.GA893@shinkuro.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "mif@ietf.org" Subject: Re: [mif] IRON as a multiple interface solution 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, 28 Nov 2011 17:23:02 -0000 Hi Hui, IRON expects that the host will have multiple ISP connections - each with its own address that is delegated from within its own administrative domain. The host will also get a different DNS server for each ISP connection, yes. Over each ISP connection, the host should be able to access services not only in the Internet but also within the ISP network. I think perhaps the latter are what you are referring to as "different DNS server may reply different information" - right? With IRON, the host registers each of its ISP connections with a Virtual Service Provider (VSP) network and is delegated an address from the VSP administrative domain. The host can then use the VSP-delegated address over any of its ISP connections via tunneling. The difference with IRON is that the IRON VSP will always provide the host with a public IP address, and the IRON DNS will always provide the host with public IP addresses of services in the Internet - even if some of those services are controlled by the VSP. So, the IRON administrative domain is really "the Internet", and not an ISP network that may use private addressing and/or give different answers for DNS name resolutions than different ISP networks would. That said, IRON does not preclude the host from accessing services within the underlying ISP networks. To do so, however, the host would have to use its ISP-delegated address(es) and not the VSP-delegated address. Does this match your understanding? Thanks - Fred fred.l.templin@boeing.com ________________________________ From: Hui Deng [mailto:denghui02@gmail.com]=20 Sent: Thursday, November 24, 2011 4:47 PM To: Templin, Fred L Cc: Andrew Sullivan; mif@ietf.org Subject: Re: [mif] IRON as a multiple interface solution =09 =09 Hi Fred, =20 MIF is not proposing any new solution for administative domain to solve fu= ndamental problem like mobility by harness virtual interface /tunnel at thi= s moment. Today it is just solveing basic problem existed in multiple admin= istrative domains. =20 For DNS selection problem, what I understand is IRON DNS can provide sub-d= omain information with only one DNS server, but here is assuming that there= exists two different administrative domain where two different DNS server = may reply different information each. =20 Regards, =20 -Hui =09 =09 2011/11/22 Templin, Fred L =09 Hi Andrew, =09 > -----Original Message----- > From: mif-bounces@ietf.org [mailto:mif-bounces@ietf.org] On > Behalf Of Andrew Sullivan > Sent: Saturday, November 19, 2011 2:04 PM > To: mif@ietf.org =09 > Subject: Re: [mif] IRON as a multiple interface solution > =09 > On Fri, Nov 18, 2011 at 02:19:39PM -0800, Templin, Fred L wrote: > > > > If the host also connects to a home enterprise network > > via a VPN, then that would be a separate administrative > > domain and a separate tunnel virtual interface. Does > > this help? > > It does, in that it seems to make it pretty hard to solve the multiple > resolution context problem that the DNS server selection draft is > trying to solve. =09 =09 What I was describing was what is sometimes called a "Split Tunnel" scenario. AFAICT, any solution that would address that scenario would be applicable also to IRON, and not in any way made more difficult by IRON. =09 Thanks - Fred =09 > A > > -- > Andrew Sullivan > ajs@anvilwalrusden.com > > _______________________________________________ > mif mailing list > mif@ietf.org > https://www.ietf.org/mailman/listinfo/mif > _______________________________________________ mif mailing list mif@ietf.org https://www.ietf.org/mailman/listinfo/mif =09 From ajs@anvilwalrusden.com Mon Nov 28 10:11:19 2011 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 8FCDA21F8D57 for ; Mon, 28 Nov 2011 10:11:19 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.949 X-Spam-Level: X-Spam-Status: No, score=-1.949 tagged_above=-999 required=5 tests=[AWL=0.650, 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 EOOYxVggXEfY for ; Mon, 28 Nov 2011 10:11:19 -0800 (PST) Received: from mail.yitter.info (mail.yitter.info [208.86.224.201]) by ietfa.amsl.com (Postfix) with ESMTP id 1B24D21F8D4E for ; Mon, 28 Nov 2011 10:11:19 -0800 (PST) Received: from shinkuro.com (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 A17591ECB424; Mon, 28 Nov 2011 18:11:02 +0000 (UTC) Date: Mon, 28 Nov 2011 13:11:15 -0500 From: Andrew Sullivan To: "Templin, Fred L" Message-ID: <20111128181115.GC45293@shinkuro.com> References: <4EC5B720.8020605@gmail.com> <83A7D27A-9036-4252-AC94-3A89125C961B@nominum.com> <4EC63ECC.8010700@gmail.com> <20111119220355.GA893@shinkuro.com> 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) Cc: "mif@ietf.org" Subject: Re: [mif] IRON as a multiple interface solution 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, 28 Nov 2011 18:11:19 -0000 On Mon, Nov 28, 2011 at 09:22:45AM -0800, Templin, Fred L wrote: > That said, IRON does not preclude the host from accessing > services within the underlying ISP networks. To do so, > however, the host would have to use its ISP-delegated > address(es) and not the VSP-delegated address. > > Does this match your understanding? The central problem, however, is that if you are looking up the address for a name, you don't obviously know where it is (i.e. you don't know what network you need to go to). What I don't get in the IRON approach is how you cope with the fact that a user simply types some name into an application. We can't hardly ask them which network they want to use to look up the name. The MIF approach, as much as it makes me airsick, does address that issue. A -- Andrew Sullivan ajs@anvilwalrusden.com From hisuntao@gmail.com Wed Nov 30 10:13:25 2011 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 A3DD411E809A for ; Wed, 30 Nov 2011 10:13:25 -0800 (PST) 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 X1-fZzf4NemX for ; Wed, 30 Nov 2011 10:13:24 -0800 (PST) Received: from mail-vw0-f44.google.com (mail-vw0-f44.google.com [209.85.212.44]) by ietfa.amsl.com (Postfix) with ESMTP id B3CF811E8098 for ; Wed, 30 Nov 2011 10:13:24 -0800 (PST) Received: by vbbez10 with SMTP id ez10so752109vbb.31 for ; Wed, 30 Nov 2011 10:13:23 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=2eRRfhp0Io84v7GS2w+ebblal3p0+1HqMZYNMbzs0iM=; b=QZfKrJyRxysjJFP3+3y3oa0CPesZkIItx6/gKojs0hcRMjOSoeeEASzUdCgnTwoXU0 jGfeyVca462+ZDPOVwwKfpN+bkTHoVVNuVBSlDgx6Etb0ua8n486c1dpJ/UpKSzyBI84 ZfM3jJNwDALQpoQyOBql2QuE/LisHXThAqEi0= MIME-Version: 1.0 Received: by 10.52.29.97 with SMTP id j1mr3051567vdh.87.1322676803060; Wed, 30 Nov 2011 10:13:23 -0800 (PST) Received: by 10.220.194.133 with HTTP; Wed, 30 Nov 2011 10:13:22 -0800 (PST) In-Reply-To: <759E821F-B503-4C8D-A79B-5F9A68A3613F@nominum.com> References: <282BBE8A501E1F4DA9C775F964BB21FE3EB78C3C98@GRFMBX704BA020.griffon.local> <916CE6CF87173740BC8A2CE44309696204193417@008-AM1MPN1-053.mgdnok.nokia.com> <4EC512A2.2060509@gmail.com> <890A58CF-8EAD-4F92-9981-9B5AA07EBF00@nominum.com> <4EC63E26.70104@gmail.com> <86163A8F-8628-4F67-BE93-3747F95A2F52@nominum.com> <4ECB6EAE.2010701@gmail.com> <702C34B3-F6B7-4EFB-91D5-8538540534A1@nominum.com> <4ECBE3BE.5070501@gmail.com> <759E821F-B503-4C8D-A79B-5F9A68A3613F@nominum.com> Date: Thu, 1 Dec 2011 02:13:22 +0800 Message-ID: From: Tao Sun To: Ted Lemon Content-Type: multipart/alternative; boundary=20cf3079c0fcffc57304b2f7b06f Cc: "mif@ietf.org" Subject: Re: [mif] Use cases for draft-ietf-mif-dhcpv6-route-option needed 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, 30 Nov 2011 18:13:25 -0000 --20cf3079c0fcffc57304b2f7b06f Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Hi All, Thanks for the discussion. As one of the author of the draft, I would like to share our view on DHCPv6 used case in three aspects. *Network management and configuration. 1. It is efficient for the network to configure this in a central DHCPv6 server to do unified routing policy configuration. The gateways (e.g., GGSN in cellular network) only need to perform DHCPv6 relay. 2. The Option Code in the DHCPv6 Request message can be used as an indication that the host is MIF capable so that the network need not to do such configuration to host without MIF feature **Cellular network 1. In cellular network, DHCPv6 is used for IPv6 parameter configuration and RA is used for SLAAC of handset. This is start from 3GPP release 8 (or earlier). 2. The network gateway in cellular network (e.g., GGSN) can naturally support DHCPv6 extension since the gateway acts as a DHCPv6 relay. However, it is very hard to update those gateways to use RA announcing the route information. 3. The handsets with MIF feature need to visit subscribed/operator provided service. Some traffic is routed to the operator=92s network throug= h 3G interface instead of to Internet through WiFi. DHCPv6 will be used to configure these specific routes. You can refer to the following report on more description of MIF use case in cellular network. ***Broadband network 1. WiFi network. Some WiFi hotspots provide local services. The route configuration on RG is needed to direct some traffic to local network while other traffic to the Internet. 2. VPN network. When a user connect to enterprise VPN network, the routing of VPN traffic need to be configured. Due to the large number of such VPN network, we cannot assume all the VPN network only use RA. DHCPv6 provides another choice which may be preferred by the VPN network. We summarize the requirements and the use cases as the following: 1) In view of the DHCPv6 requirements in several fields, vendor-specific options lead to several segmented definitions. An IETF defined general option is a better choice. 2) Per user/host configuration makes DHCPv6 be used for the on-demand configuration. 3) The centralized relay architecture is a widely used way at present for IPv4 and it will also be used for IPv6. That is IETF=92s responsibility to support such requirement. Regards, Tao Sun On Wed, Nov 23, 2011 at 2:33 AM, Ted Lemon wrote: > On Nov 22, 2011, at 1:02 PM, Alexandru Petrescu wrote: > > The similar userland-vs-kernel (read DHCP vs RA) discussion has it that > it is easier to do one not both. > > > Of course it is easier to do one, not both. But it's no problem to do > both. > > (also relating to your earlier mentioning compiling being lengthy for ARM > kernel - yes it is quicker to compile userland DHCP than kernel RA). > > > This is easily solved by cross-compiling. > > > _______________________________________________ > mif mailing list > mif@ietf.org > https://www.ietf.org/mailman/listinfo/mif > > --20cf3079c0fcffc57304b2f7b06f Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: quoted-printable
Hi All,
=A0

= Thanks for the= discussion. As one of the author of the draft, I would like to share our v= iew on DHCPv6 used case in three aspects.

= *Network manag= ement and configuration.

<= font size=3D"3">1. It is efficient for the network t= o configure this in a central DHCPv6 server to do unified routing policy co= nfiguration. The gateways (e.g., GGSN in cellular network) only need to per= form DHCPv6 relay.

<= font size=3D"3">2. The Option Code in the DHCPv6 Req= uest message can be used as an indication that the host is MIF capable so t= hat the network need not to do such configuration to host without MIF featu= re

<= font size=3D"3" face=3D"Calibri">=A0

<= font size=3D"3">**Cellular network

1.<= /font>=A0=A0=A0=A0=A0= =A0 In cellular network, DHCPv6 is used for IPv6 parameter configu= ration and RA is used for SLAAC of handset. This is start from 3GPP release= 8 (or earlier).

2.<= /font>=A0=A0=A0=A0=A0= =A0 The network gateway in cellular network (e.g., GGSN) can natur= ally support DHCPv6 extension since the gateway acts as a DHCPv6 relay. How= ever, it is very hard to update those gateways to use RA announcing the rou= te information.

3.<= /font>=A0=A0=A0=A0=A0= =A0 The handsets with MIF feature need to visit subscribed/operato= r provided service. Some traffic is routed to the operator=92s network thro= ugh 3G interface instead of to Internet through WiFi. =A0DHCPv6 will be used to configure these specific rout= es.

You can refer to the following report on more descripti= on of MIF use case in cellular network.

=A0

<= font size=3D"3">***Broadband network

1.<= /font>=A0=A0=A0=A0=A0= =A0 WiFi network. Some WiFi hotspots provide local services. The r= oute configuration on RG is needed to direct some traffic to local network = while other traffic to the Internet.

2.<= /font>=A0=A0=A0=A0=A0= =A0 VPN network. When a user connect to enterprise VPN network, th= e routing of VPN traffic need to be configured. Due to the large number of = such VPN network, we cannot assume all the VPN network only use RA. DHCPv6 = provides another choice which may be preferred by the VPN network.

<= font size=3D"3" face=3D"Calibri">=A0

We summarize the requirements and = the use cases as the following: 1) In view of the DHCPv6 requirements in se= veral fields, vendor-specific options lead to several segmented definitions= . An IETF defined general option is a better choice. 2) Per user/host confi= guration makes DHCPv6 be used for the on-demand configuration. 3) The centr= alized relay architecture is a widely used way at present for IPv4 and it w= ill also be used for IPv6. That is IETF=92s responsibility to support such = requirement.
=A0
Regards,
Tao Sun
=

On Wed, Nov 23, 2011 at 2:33 AM, Ted Lemon <Ted.Lemon@nominum= .com> wrote:
On Nov 22, 2011, at 1:02 PM, Alexandru Petrescu wrote:
The similar userland-vs-kerne= l (read DHCP vs RA) discussion has it that
it is easier to do one not both.

Of course it is easier to do one, not both. =A0 But it= 's no problem to do both.

(also relating to your earlie= r mentioning compiling being lengthy for ARM kernel - yes it is quicker to = compile userland DHCP than kernel RA).

This is easily solved by cross-compiling.


_______________________________________________mif mailing list
mif@ietf.org
https= ://www.ietf.org/mailman/listinfo/mif


--20cf3079c0fcffc57304b2f7b06f-- From hisuntao@gmail.com Wed Nov 30 10:18:02 2011 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 852EF21F8770 for ; Wed, 30 Nov 2011 10:18:02 -0800 (PST) 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 wq7-q5YbJEwZ for ; Wed, 30 Nov 2011 10:18:01 -0800 (PST) Received: from mail-vx0-f172.google.com (mail-vx0-f172.google.com [209.85.220.172]) by ietfa.amsl.com (Postfix) with ESMTP id 499DF11E807F for ; Wed, 30 Nov 2011 10:18:01 -0800 (PST) Received: by vcbfy13 with SMTP id fy13so777854vcb.31 for ; Wed, 30 Nov 2011 10:18:00 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=yR5FsCYuAZRS3BcU3BHZsW8piPDNvaFGSJ1uQwkMPgg=; b=U8RpjESvwKMuG6TW+xiEBBQ3BJ5Epk7iMPZ4RUY70N/5/hfE/amB6t6F9M11kTtra1 xtHdUcXworqju99pqxu7eEqyVv/kU6NzsYI9/uVmkHMW540Q+2Wg+JH7FhB25cMoBQN2 jVUdqkOFAM7sdluvUwbx+qXDy5dPwWifjJbs0= MIME-Version: 1.0 Received: by 10.52.90.131 with SMTP id bw3mr3091662vdb.70.1322677080656; Wed, 30 Nov 2011 10:18:00 -0800 (PST) Received: by 10.220.194.133 with HTTP; Wed, 30 Nov 2011 10:18:00 -0800 (PST) In-Reply-To: References: <282BBE8A501E1F4DA9C775F964BB21FE3EB78C3C98@GRFMBX704BA020.griffon.local> <916CE6CF87173740BC8A2CE44309696204193417@008-AM1MPN1-053.mgdnok.nokia.com> <4EC512A2.2060509@gmail.com> <890A58CF-8EAD-4F92-9981-9B5AA07EBF00@nominum.com> <4EC63E26.70104@gmail.com> <86163A8F-8628-4F67-BE93-3747F95A2F52@nominum.com> <4ECB6EAE.2010701@gmail.com> <702C34B3-F6B7-4EFB-91D5-8538540534A1@nominum.com> <4ECBE3BE.5070501@gmail.com> <759E821F-B503-4C8D-A79B-5F9A68A3613F@nominum.com> Date: Thu, 1 Dec 2011 02:18:00 +0800 Message-ID: From: Tao Sun To: Ted Lemon Content-Type: multipart/alternative; boundary=20cf307f31da8b8c6f04b2f7c120 Cc: "mif@ietf.org" Subject: Re: [mif] Use cases for draft-ietf-mif-dhcpv6-route-option needed 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, 30 Nov 2011 18:18:02 -0000 --20cf307f31da8b8c6f04b2f7c120 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Forgot to include a website link in the previous email. Now I included it. Regards, Tao Sun On Thu, Dec 1, 2011 at 2:13 AM, Tao Sun wrote: > Hi All, > > > Thanks for the discussion. As one of the author of the draft, I would lik= e > to share our view on DHCPv6 used case in three aspects. > > *Network management and configuration. > > 1. It is efficient for the network to configure this in a central DHCPv6 > server to do unified routing policy configuration. The gateways (e.g., GG= SN > in cellular network) only need to perform DHCPv6 relay. > > 2. The Option Code in the DHCPv6 Request message can be used as an > indication that the host is MIF capable so that the network need not to d= o > such configuration to host without MIF feature > > > > **Cellular network > > 1. In cellular network, DHCPv6 is used for IPv6 parameter > configuration and RA is used for SLAAC of handset. This is start from 3GP= P > release 8 (or earlier). > > 2. The network gateway in cellular network (e.g., GGSN) can > naturally support DHCPv6 extension since the gateway acts as a DHCPv6 > relay. However, it is very hard to update those gateways to use RA > announcing the route information. > > 3. The handsets with MIF feature need to visit subscribed/operator > provided service. Some traffic is routed to the operator=92s network thro= ugh > 3G interface instead of to Internet through WiFi. DHCPv6 will be used to > configure these specific routes. > > You can refer to the following report on more description of MIF use case > in cellular network. > http://www.3gpp.org/ftp/Specs/html-info/23853.htm > > > ***Broadband network > > 1. WiFi network. Some WiFi hotspots provide local services. The > route configuration on RG is needed to direct some traffic to local netwo= rk > while other traffic to the Internet. > > 2. VPN network. When a user connect to enterprise VPN network, the > routing of VPN traffic need to be configured. Due to the large number of > such VPN network, we cannot assume all the VPN network only use RA. DHCPv= 6 > provides another choice which may be preferred by the VPN network. > > > We summarize the requirements and the use cases as the following: 1) In > view of the DHCPv6 requirements in several fields, vendor-specific option= s > lead to several segmented definitions. An IETF defined general option is = a > better choice. 2) Per user/host configuration makes DHCPv6 be used for th= e > on-demand configuration. 3) The centralized relay architecture is a widel= y > used way at present for IPv4 and it will also be used for IPv6. That is > IETF=92s responsibility to support such requirement. > > Regards, > Tao Sun > > > On Wed, Nov 23, 2011 at 2:33 AM, Ted Lemon wrote= : > >> On Nov 22, 2011, at 1:02 PM, Alexandru Petrescu wrote: >> >> The similar userland-vs-kernel (read DHCP vs RA) discussion has it that >> it is easier to do one not both. >> >> >> Of course it is easier to do one, not both. But it's no problem to do >> both. >> >> (also relating to your earlier mentioning compiling being lengthy for AR= M >> kernel - yes it is quicker to compile userland DHCP than kernel RA). >> >> >> This is easily solved by cross-compiling. >> >> >> _______________________________________________ >> mif mailing list >> mif@ietf.org >> https://www.ietf.org/mailman/listinfo/mif >> >> > --20cf307f31da8b8c6f04b2f7c120 Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: quoted-printable
Forgot to include a website link in the previous email. Now I included= it.
=A0
Regards,
=A0
Tao Sun

On Thu, Dec 1, 2011 at 2:13 AM, Tao Sun <hisuntao@gmail.com&= gt; wrote:
Hi All,
=A0

<= font size=3D"3">Thanks for the discussion. As one of= the author of the draft, I would like to share our view on DHCPv6 used cas= e in three aspects.

<= font size=3D"3">*Network management and configuratio= n.

<= font size=3D"3">1. It is efficient for the network t= o configure this in a central DHCPv6 server to do unified routing policy co= nfiguration. The gateways (e.g., GGSN in cellular network) only need to per= form DHCPv6 relay.

<= font size=3D"3">2. The Option Code in the DHCPv6 Req= uest message can be used as an indication that the host is MIF capable so t= hat the network need not to do such configuration to host without MIF featu= re

<= font size=3D"3" face=3D"Calibri">=A0

<= font size=3D"3">**Cellular network

1.=A0=A0=A0=A0=A0=A0 In cellular network, DHCPv6 is used for= IPv6 parameter configuration and RA is used for SLAAC of handset. This is = start from 3GPP release 8 (or earlier).

2.=A0=A0=A0=A0=A0=A0 The network gateway in cellular network= (e.g., GGSN) can naturally support DHCPv6 extension since the gateway acts= as a DHCPv6 relay. However, it is very hard to update those gateways to us= e RA announcing the route information.

3.=A0=A0=A0=A0=A0=A0 The handsets with MIF feature need to v= isit subscribed/operator provided service. Some traffic is routed to the op= erator=92s network through 3G interface instead of to Internet through WiFi= . =A0DHCPv6 will be used to configure these specific routes.

You can refer to the following re= port on more description of MIF use case in cellular network.=

=A0

<= font size=3D"3">***Broadband network

1.=A0=A0=A0=A0=A0=A0 WiFi network. Some WiFi hotspots provid= e local services. The route configuration on RG is needed to direct some tr= affic to local network while other traffic to the Internet.

2.=A0=A0=A0=A0=A0=A0 VPN network. When a user connect to ent= erprise VPN network, the routing of VPN traffic need to be configured. Due = to the large number of such VPN network, we cannot assume all the VPN netwo= rk only use RA. DHCPv6 provides another choice which may be preferred by th= e VPN network.

<= font size=3D"3" face=3D"Calibri">=A0

We summarize the requirements and = the use cases as the following: 1) In view of the DHCPv6 requirements in se= veral fields, vendor-specific options lead to several segmented definitions= . An IETF defined general option is a better choice. 2) Per user/host confi= guration makes DHCPv6 be used for the on-demand configuration. 3) The centr= alized relay architecture is a widely used way at present for IPv4 and it w= ill also be used for IPv6. That is IETF=92s responsibility to support such = requirement.
=A0
Regards,
Tao Sun
=

On Wed, Nov 23, 2011 at 2:33 AM, Ted Lemon <Ted.Lemo= n@nominum.com> wrote:
On Nov 22, 2011, at 1:02 PM, Alexandru Petrescu wrote:
The similar userland-vs-kerne= l (read DHCP vs RA) discussion has it that
it is easier to do one not both.

Of course it is easier to do one, not both. =A0 But it= 's no problem to do both.

(also relating to your earlie= r mentioning compiling being lengthy for ARM kernel - yes it is quicker to = compile userland DHCP than kernel RA).

This is easily solved by cross-compiling.


_______________________________________________
mif ma= iling list
mif@ietf.or= g
https://www.ietf.org/mailman/listinfo/mif



--20cf307f31da8b8c6f04b2f7c120-- From hisuntao@gmail.com Wed Nov 30 10:30:27 2011 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 461271F0C3B; Wed, 30 Nov 2011 10:30:27 -0800 (PST) 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 MnXpYvYaBHdR; Wed, 30 Nov 2011 10:30:26 -0800 (PST) Received: from mail-vx0-f172.google.com (mail-vx0-f172.google.com [209.85.220.172]) by ietfa.amsl.com (Postfix) with ESMTP id 32F7421F8B29; Wed, 30 Nov 2011 10:30:26 -0800 (PST) Received: by vcbfy13 with SMTP id fy13so793536vcb.31 for ; Wed, 30 Nov 2011 10:30:25 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=2U/S+8zlFLdKDpU5faZ4B+uGMJEMyy1I+8HOKR1ovEw=; b=fe0/7bQ7bIM2XlgYsAOfpGrSEVm306+rMrTaZpOEahVTgmA2hJ7Jb2qsTY+CBAFXjk Hm0vkzACglm4unAV5V03p4+ODKbtlxFXhhVG9dk4I5s8cjGiCSPfphqcbdBdXp7oXw7i CK+Ys+mp6D0R62XqqKHwO2qQ0Ekv5jWI8HhQo= MIME-Version: 1.0 Received: by 10.52.24.13 with SMTP id q13mr3095610vdf.104.1322677825740; Wed, 30 Nov 2011 10:30:25 -0800 (PST) Received: by 10.220.194.133 with HTTP; Wed, 30 Nov 2011 10:30:25 -0800 (PST) In-Reply-To: References: <402398CF-7F7C-4B8B-91CE-6EDE54B6C4CC@employees.org> <23BACC91-621A-4E96-ACD6-92D226F9657A@nominum.com> <201111212036.pALKa0eO019515@cichlid.raleigh.ibm.com> <0DF2CC29-9D10-4DCB-8B12-7216D628FAAF@nominum.com> Date: Thu, 1 Dec 2011 02:30:25 +0800 Message-ID: From: Tao Sun To: Ted Lemon Content-Type: multipart/alternative; boundary=20cf3071cd00f49f6f04b2f7ed64 Cc: Thomas Narten , "ipv6@ietf.org" , Ole Troan , MIF Mailing List , dhc WG Subject: Re: [mif] [dhcwg] Conflict between RA and DHCP in MIF case 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, 30 Nov 2011 18:30:27 -0000 --20cf3071cd00f49f6f04b2f7ed64 Content-Type: text/plain; charset=ISO-8859-1 Sorry for jump to this discussion thread late. The route policy shall be well considered by the operator/network. If we discuss confliction, it is more like to be the network configuration that may appear for MIF host rather than the mechanism of DHCPv6 or RA. Even we only use RIO, the confliction may still apprear on different interfaces. You may refer to the problem analysis discussed and agreed in 3GPP: http://www.3gpp.org/ftp/tsg_sa/WG2_Arch/TSGS2_85_XiAN/Docs/S2-112902.zip Regards, Tao On Tue, Nov 22, 2011 at 11:31 PM, Ted Lemon wrote: > On Nov 22, 2011, at 8:18 AM, Ole Troan wrote: > > for clarification, that was not my proposal. my suggestion was to merge > all information within one "provisioning domain". > > unsure if we will end up with provisioning domain = link, as detection of > multiple provisioning domains on a single link may not be trivial in all > corner cases. > > > I agree with you that right now detecting provisioning domains is not > trivial; indeed, in some cases it's impossible. However, if you think > provisioning domain == link, then that's a problem that needs fixing. > Indeed, that's *the* problem that needs fixing. I think we have to fix > it; if we punt, we're going to pay for it later. > > > _______________________________________________ > mif mailing list > mif@ietf.org > https://www.ietf.org/mailman/listinfo/mif > > --20cf3071cd00f49f6f04b2f7ed64 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Sorry for jump to this=A0discussion thread=A0late.
The route policy shall be well considered by the operator/network. If = we discuss confliction, it is more like to be the network configuration tha= t may appear for MIF host rather than the mechanism of DHCPv6 or RA. Even= =A0we only use RIO, the confliction may still apprear on different interfac= es.

You may=A0refer to the=A0problem analysis discussed and agreed in = 3GPP:
http://www.3gpp.org/ftp/tsg_sa/WG2_Arch/TSGS2_85_XiAN/Do= cs/S2-112902.zip
Regards,
=A0
Tao
On Tue, Nov 22, 2011 at 11:31 PM, Ted Lemon <Ted.Lemon@nominu= m.com> wrote:
On Nov 22, 2011, at 8:18 AM, Ole Troan wrote:
for clarification, that was n= ot my proposal. my suggestion was to merge all information within one "= ;provisioning domain".
unsure if we will end up with= provisioning domain =3D link, as detection of multiple provisioning domain= s on a single link may not be trivial in all corner cases.

I agree with you that right now detecting provisioning domains is not = trivial; indeed, in some cases it's impossible. =A0 However, if you thi= nk provisioning domain =3D=3D link, then that's a problem that needs fi= xing. =A0 Indeed, that's *the* problem that needs fixing. =A0 I think w= e have to fix it; if we punt, we're going to pay for it later.


_______________________________________________mif mailing list
mif@ietf.org
https= ://www.ietf.org/mailman/listinfo/mif


--20cf3071cd00f49f6f04b2f7ed64-- From lorenzo@google.com Wed Nov 30 10:49:03 2011 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 D079421F8C17 for ; Wed, 30 Nov 2011 10:49:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.44 X-Spam-Level: X-Spam-Status: No, score=-102.44 tagged_above=-999 required=5 tests=[AWL=0.536, 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 GIhTocCMlZHY for ; Wed, 30 Nov 2011 10:49:03 -0800 (PST) Received: from mail-gx0-f172.google.com (mail-gx0-f172.google.com [209.85.161.172]) by ietfa.amsl.com (Postfix) with ESMTP id D44C221F8C15 for ; Wed, 30 Nov 2011 10:49:02 -0800 (PST) Received: by ggnp4 with SMTP id p4so1163928ggn.31 for ; Wed, 30 Nov 2011 10:49:02 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=beta; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type:x-system-of-record; bh=ALSsI8470u9FZ1yxvrwYNhmYhwYD0cdykVk3qRiBtW4=; b=AlgReOiIRxsiquigEkOfdP5NtpsaC6xQbVwEXVxf43QwTzjVUK7KeN9vfRzbXE/96+ 94J3Zb+CNv8gku5ekNnQ== Received: by 10.236.75.167 with SMTP id z27mr5933807yhd.53.1322678942275; Wed, 30 Nov 2011 10:49:02 -0800 (PST) Received: by 10.236.75.167 with SMTP id z27mr5933790yhd.53.1322678942177; Wed, 30 Nov 2011 10:49:02 -0800 (PST) MIME-Version: 1.0 Received: by 10.150.202.14 with HTTP; Wed, 30 Nov 2011 10:48:40 -0800 (PST) In-Reply-To: References: <282BBE8A501E1F4DA9C775F964BB21FE3EB78C3C98@GRFMBX704BA020.griffon.local> <916CE6CF87173740BC8A2CE44309696204193417@008-AM1MPN1-053.mgdnok.nokia.com> <4EC512A2.2060509@gmail.com> <890A58CF-8EAD-4F92-9981-9B5AA07EBF00@nominum.com> <4EC63E26.70104@gmail.com> <86163A8F-8628-4F67-BE93-3747F95A2F52@nominum.com> <4ECB6EAE.2010701@gmail.com> <702C34B3-F6B7-4EFB-91D5-8538540534A1@nominum.com> <4ECBE3BE.5070501@gmail.com> <759E821F-B503-4C8D-A79B-5F9A68A3613F@nominum.com> From: Lorenzo Colitti Date: Wed, 30 Nov 2011 10:48:40 -0800 Message-ID: To: Tao Sun Content-Type: multipart/alternative; boundary=20cf3005dde680196804b2f83063 X-System-Of-Record: true Cc: "mif@ietf.org" Subject: Re: [mif] Use cases for draft-ietf-mif-dhcpv6-route-option needed 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, 30 Nov 2011 18:49:03 -0000 --20cf3005dde680196804b2f83063 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable On Wed, Nov 30, 2011 at 10:13, Tao Sun wrote: > **Cellular network > > 1. In cellular network, DHCPv6 is used for IPv6 parameter > configuration and RA is used for SLAAC of handset. This is start from 3GP= P > release 8 (or earlier). > > 2. The network gateway in cellular network (e.g., GGSN) can > naturally support DHCPv6 extension since the gateway acts as a DHCPv6 > relay. However, it is very hard to update those gateways to use RA > announcing the route information. > > 3. The handsets with MIF feature need to visit subscribed/operator > provided service. Some traffic is routed to the operator=92s network thro= ugh > 3G interface instead of to Internet through WiFi. DHCPv6 will be used to > configure these specific routes. > You can already do this today with RIOs, and I don't see why there need to be two ways of doing the same thing. Adding a different method to configure the same information is twice the code and more than twice the complexity, since when you have two sources of information with different semantics you need to figure out how to merge them, what happens if they disagree, what to do if one is wrong, what to do if one expires, and so on. Also, in the mobile case I don't understand how you would use a different gateway anyway. The mobile network is a point-to-point link, so there's no way to distinguish multiple gateways. How would you use this? > ***Broadband network > > 1. WiFi network. Some WiFi hotspots provide local services. The > route configuration on RG is needed to direct some traffic to local netwo= rk > while other traffic to the Internet. > I don't understand why you need host changes to do this. Since the hotspot router is a router, it can simply forward the packets the right way by itself. > 2. VPN network. When a user connect to enterprise VPN network, the > routing of VPN traffic need to be configured. Due to the large number of > such VPN network, we cannot assume all the VPN network only use RA. DHCPv= 6 > provides another choice which may be preferred by the VPN network. > The rationale here seems to be that "if we create a new option, some networks might use it". That's certainly true, but it doesn't provide a compelling reason why we need the option in the first place. --20cf3005dde680196804b2f83063 Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: quoted-printable
On Wed, Nov 30, 2011 at 10:13, Tao Sun <hisuntao@gmail.com&g= t; wrote:
**Cellular network

1.=A0=A0=A0=A0=A0=A0 In cellular network, DHCPv6 is used for = IPv6 parameter configuration and RA is used for SLAAC of handset. This is s= tart from 3GPP release 8 (or earlier).

2.=A0=A0=A0=A0=A0=A0 The network gateway in cellular network = (e.g., GGSN) can naturally support DHCPv6 extension since the gateway acts = as a DHCPv6 relay. However, it is very hard to update those gateways to use= RA announcing the route information.

3.=A0=A0=A0=A0=A0=A0 The handsets with MIF feature need to vi= sit subscribed/operator provided service. Some traffic is routed to the ope= rator=92s network through 3G interface instead of to Internet through WiFi.= =A0DHCPv6 will be used to configure these specific routes.


You can already do this today with RIOs, a= nd=A0I don't see why there need to be two ways of doing the same thing.= =A0Adding a different method to configure the same information is=A0twice t= he code and more than twice the complexity, since when you have two sources= of information with different semantics you need to figure out how to merg= e them, what happens if they disagree, what to do if one is wrong, what to = do if one expires, and so on.

Also, in the mobile case I don't understand how you= would use a different gateway anyway.=A0The mobile network is a point-to-p= oint link, so there's no way to distinguish multiple gateways. How woul= d you use this?
=A0=A0

***Broadband network

1.=A0=A0=A0=A0=A0=A0 WiFi network. Some WiFi hotspots provide= local services. The route configuration on RG is needed to direct some tra= ffic to local network while other traffic to the Internet.


I don't understand why you need host c= hanges to do this. Since the hotspot router is a router, it can simply forw= ard the packets the right way by itself.
=A0

2.=A0=A0=A0=A0=A0=A0 VPN network. When a user connect to ente= rprise VPN network, the routing of VPN traffic need to be configured. Due t= o the large number of such VPN network, we cannot assume all the VPN networ= k only use RA. DHCPv6 provides another choice which may be preferred by the= VPN network.


The rationale here seems to be that "= if we create a new option, some networks might use it". That's cer= tainly true, but it doesn't provide a compelling reason why we need the= option in the first place.
--20cf3005dde680196804b2f83063-- From brian.e.carpenter@gmail.com Wed Nov 30 13:30:59 2011 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 46C6911E80E2 for ; Wed, 30 Nov 2011 13:30:59 -0800 (PST) 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 9oGckkq3sKPn for ; Wed, 30 Nov 2011 13:30:58 -0800 (PST) Received: from mail-ey0-f172.google.com (mail-ey0-f172.google.com [209.85.215.172]) by ietfa.amsl.com (Postfix) with ESMTP id 8EAC811E80E0 for ; Wed, 30 Nov 2011 13:30:58 -0800 (PST) Received: by eabm6 with SMTP id m6so1427715eab.31 for ; Wed, 30 Nov 2011 13:30:57 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=message-id:date:from:organization:user-agent:mime-version:to :subject:references:in-reply-to:content-type :content-transfer-encoding; bh=4KHlUF5Z3rKyste7G4o+AOrt3U07ks8u2O3952Qrliw=; b=p9LeLvaNlMrEj//xPfa6lS/ZsH5Pte4LpG78XKBYYLYKrIHXb6rQAkYtWROuhThg1Q jqufjyiuItB6w39G5e24ElllaQAb8Itmrnft5uAcLsXXXrkWrc8Rk3VMDW+BTc2e+mbZ DsNeC4xUVALwHZbkKQs5Ar2tSePcb5DOtQdzU= Received: by 10.216.82.204 with SMTP id o54mr148134wee.82.1322688657714; Wed, 30 Nov 2011 13:30:57 -0800 (PST) Received: from [130.216.38.124] (stf-brian.sfac.auckland.ac.nz. [130.216.38.124]) by mx.google.com with ESMTPS id b5sm3481300wbh.4.2011.11.30.13.30.55 (version=SSLv3 cipher=OTHER); Wed, 30 Nov 2011 13:30:56 -0800 (PST) Message-ID: <4ED6A08D.9090703@gmail.com> Date: Thu, 01 Dec 2011 10:30:53 +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: <282BBE8A501E1F4DA9C775F964BB21FE3EB78C3C98@GRFMBX704BA020.griffon.local> <916CE6CF87173740BC8A2CE44309696204193417@008-AM1MPN1-053.mgdnok.nokia.com> <4EC512A2.2060509@gmail.com> <890A58CF-8EAD-4F92-9981-9B5AA07EBF00@nominum.com> <4EC63E26.70104@gmail.com> <86163A8F-8628-4F67-BE93-3747F95A2F52@nominum.com> <4ECB6EAE.2010701@gmail.com> <702C34B3-F6B7-4EFB-91D5-8538540534A1@nominum.com> <4ECBE3BE.5070501@gmail.com> <759E821F-B503-4C8D-A79B-5F9A68A3613F@nominum.com> In-Reply-To: Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Subject: Re: [mif] Use cases for draft-ietf-mif-dhcpv6-route-option needed 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, 30 Nov 2011 21:30:59 -0000 On 2011-12-01 07:18, Tao Sun wrote: ... >> We summarize the requirements and the use cases as the following: 1) In >> view of the DHCPv6 requirements in several fields, vendor-specific options >> lead to several segmented definitions. An IETF defined general option is a >> better choice. To me this is a killer argument. A general solution that is applicable to all deployment scenarios is vastly better than a free-for all of vendor options, which will increase the implementation burden for everybody and reduce the chances of smooth zero-conf operation. >> 2) Per user/host configuration makes DHCPv6 be used for the >> on-demand configuration. RA/RIO does not meet this requirement, which is a real requirement in networks with heterogeneous types of host. DHCPv6 does meet this requirement. >> 3) The centralized relay architecture is a widely >> used way at present for IPv4 and it will also be used for IPv6. That's the wrong way to say it IMHO. There are sound reasons why operators want a centralised host management system with distributed relays. The fact that the solution for IPv4 is called DHCP doesn't imply that the best solution for IPv6 is called DHCPv6. However, until there is a well-defined central management system for prefix delegation and routing options via RA, it seems that DHCPv6 *is* the only available solution. And then we loop back to point 1): it's better to have a generic option than a bunch of competing vendor options. Brian From lorenzo@google.com Wed Nov 30 15:23:50 2011 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 85A3B21F8C66 for ; Wed, 30 Nov 2011 15:23:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.74 X-Spam-Level: X-Spam-Status: No, score=-102.74 tagged_above=-999 required=5 tests=[AWL=0.236, 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 JBvYmeFKWe5J for ; Wed, 30 Nov 2011 15:23:49 -0800 (PST) Received: from mail-yx0-f172.google.com (mail-yx0-f172.google.com [209.85.213.172]) by ietfa.amsl.com (Postfix) with ESMTP id A54D721F8C65 for ; Wed, 30 Nov 2011 15:23:49 -0800 (PST) Received: by yenl9 with SMTP id l9so182508yen.31 for ; Wed, 30 Nov 2011 15:23:49 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=beta; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type:x-system-of-record; bh=GgFiJlUw/YD1ZqklrAsfDs25bUrp+yLmf+KHEeixlFg=; b=PTBUIadcTyE5EYEhgpkOfDZ7a1lHXAnbF2/i2nKDoDaVO4frb2AttfAjvSnehYR5He oxZAC168powGkRRfKxfw== Received: by 10.236.183.52 with SMTP id p40mr7718694yhm.19.1322695429279; Wed, 30 Nov 2011 15:23:49 -0800 (PST) Received: by 10.236.183.52 with SMTP id p40mr7718686yhm.19.1322695429173; Wed, 30 Nov 2011 15:23:49 -0800 (PST) MIME-Version: 1.0 Received: by 10.150.202.14 with HTTP; Wed, 30 Nov 2011 15:23:28 -0800 (PST) In-Reply-To: <4ED6A08D.9090703@gmail.com> References: <282BBE8A501E1F4DA9C775F964BB21FE3EB78C3C98@GRFMBX704BA020.griffon.local> <916CE6CF87173740BC8A2CE44309696204193417@008-AM1MPN1-053.mgdnok.nokia.com> <4EC512A2.2060509@gmail.com> <890A58CF-8EAD-4F92-9981-9B5AA07EBF00@nominum.com> <4EC63E26.70104@gmail.com> <86163A8F-8628-4F67-BE93-3747F95A2F52@nominum.com> <4ECB6EAE.2010701@gmail.com> <702C34B3-F6B7-4EFB-91D5-8538540534A1@nominum.com> <4ECBE3BE.5070501@gmail.com> <759E821F-B503-4C8D-A79B-5F9A68A3613F@nominum.com> <4ED6A08D.9090703@gmail.com> From: Lorenzo Colitti Date: Wed, 30 Nov 2011 15:23:28 -0800 Message-ID: To: Brian E Carpenter Content-Type: multipart/alternative; boundary=bcaec52c5ea933b15c04b2fc0722 X-System-Of-Record: true Cc: "mif@ietf.org" Subject: Re: [mif] Use cases for draft-ietf-mif-dhcpv6-route-option needed 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, 30 Nov 2011 23:23:50 -0000 --bcaec52c5ea933b15c04b2fc0722 Content-Type: text/plain; charset=ISO-8859-1 On Wed, Nov 30, 2011 at 13:30, Brian E Carpenter < brian.e.carpenter@gmail.com> wrote: > To me this is a killer argument. A general solution that is applicable > to all deployment scenarios is vastly better than a free-for all of > vendor options, which will increase the implementation burden for > everybody and reduce the chances of smooth zero-conf operation. > Actually, what decreases the implementation burden is not having the option at all. The use cases I've heard so far for this option are all a bit specious and I think they are outweighed by the harm that would be caused if this option were to get into general use. The reasoning goes something like this: 1. The option is defined. 2. OS foo implements it. 3. Some network, somewhere, decides that they're only going to use DHCPv6 for routing, because they only support OS foo. 4. Other OSes are forced to implement the option because if they don't, they are at a disadvantage compared to OS foo 5. Once all OSes implement it, some other network, somewhere else, decides that they're only going to support DHCPv6 for routing because it's easier and because it matches what they do in IPv4, so they turn off RAs. Then we have a problem, because DHCPv6 has much less rich semantics than RAs in the general case. A few examples: - DHCPv6 is static. A lease is a promise and it can't be deprecated except by the server that originally made the promise. If that server is not around any more, or if clients don't support reconfigure, it can't be deprecated at all. You can work around this with short lease times, but that creates a scaling problem on the DHCPv6 server, because it's centralized. - The way the standards and the clients are written, clients pick one DHCPv6 advertise and stick to it. So they can't merge multiple sources of information. - DHCPv6 does not share fate with routing; in fact, it has no knowledge of routing. - The combination of the fact that you can't merge multiple sources of information and the fact that you can only provide static information means that you're basically forced to hand out stuff that doesn't change. If you're using DHCPv6 to set the default router, that basically means you're forced to use VRRP or NAT if you want any sort of redundancy. To me, the lack of functionality that will result if we take the path of least resistance described above far outweighs the benefits of being able to configure [default] routes and on-link prefixes on a per-host basis. You can do this in lots of other ways, for example assigning the hosts you want to treat differently to different VLANs. >> 2) Per user/host configuration makes DHCPv6 be used for the > >> on-demand configuration. > > RA/RIO does not meet this requirement, which is a real requirement > in networks with heterogeneous types of host. DHCPv6 does meet this > requirement. > You can use selective unicast router advertisements for this if you want. There's no reason you can't look the RA properties in RADIUS. And of course, you can put the separate hosts on separate VLANs (which is probably the right thing to do in general). --bcaec52c5ea933b15c04b2fc0722 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
On Wed, Nov 30, 2011 at 13:30, Brian E Carpenter= <brian.e.carpenter@gmail.com> wrote:
To me this is a killer argument. A general solution that is applicable=
to all deployment scenarios is vastly better than a free-for all of
vendor options, which will increase the implementation burden for
everybody and reduce the chances of smooth zero-conf operation.

Actually, what decreases the implementation burden= is not having the option at all.=A0The use cases I've heard so far for= this option are all a bit specious and I think they are outweighed by the = harm that would be caused if this option were to get into general use.

The reasoning goes something like this:

<= /div>
1. The option is defined.
2. OS foo implements it.
3. Some network, somewhere, decides that they're only going to us= e DHCPv6 for routing, because they only support OS foo.
4. Other OSes are forced to implement the option because if they don&#= 39;t, they are at a disadvantage compared to OS foo
5. Once all O= Ses implement it, some other network, somewhere else, decides that they'= ;re only going to support DHCPv6 for routing because it's easier and be= cause it matches what they do in IPv4, so they turn off RAs.

Then we have a problem, because DHCPv6 has much less ri= ch semantics than RAs in the general case. A few examples:

- DHCPv6 is static. A lease is a promise and it can't be depre= cated except by the server that originally made the promise. If that server= is not around any more, or if clients don't support reconfigure, it ca= n't be deprecated at all. You can work around this with short lease tim= es, but that creates a scaling problem on the DHCPv6 server, because it'= ;s centralized.
- The way the standards and the clients are written, clients pick one = DHCPv6 advertise and stick to it. So they can't merge multiple sources = of information.
- DHCPv6 does not share fate with routing; in fac= t, it has no knowledge of routing.
- The combination of the fact that you can't merge multiple source= s of information and the fact that you can only provide static information = means that you're basically forced to hand out stuff that doesn't c= hange. If you're using DHCPv6 to set the default router, that basically= means you're forced to use VRRP or NAT if you want any sort of redunda= ncy.

To me, the lack of functionality that will result if we= take the path of least resistance described above far outweighs the benefi= ts of being able to configure [default] routes and on-link prefixes on a pe= r-host basis. You can do this in lots of other ways, for example assigning = the hosts you want to treat differently to different VLANs.

>> 2) Per user/host configuration makes DHCPv6 be used for the >> on-demand configuration.

RA/RIO does not meet this requirement, which is a real requirement in networks with heterogeneous types of host. DHCPv6 does meet this
requirement.

You can use selective unic= ast router advertisements for this if you want. There's no reason you c= an't look the RA properties in RADIUS. And of course, you can put the s= eparate hosts on separate VLANs (which is probably the right thing to do in= general).
--bcaec52c5ea933b15c04b2fc0722-- From moore@network-heretics.com Wed Nov 30 15:41:55 2011 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 9AB451F0C53 for ; Wed, 30 Nov 2011 15:41:55 -0800 (PST) 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 FPzzBYR+LU+A for ; Wed, 30 Nov 2011 15:41:54 -0800 (PST) Received: from out3.smtp.messagingengine.com (out3.smtp.messagingengine.com [66.111.4.27]) by ietfa.amsl.com (Postfix) with ESMTP id A7C4F1F0C52 for ; Wed, 30 Nov 2011 15:41:54 -0800 (PST) Received: from compute1.internal (compute1.nyi.mail.srv.osa [10.202.2.41]) by gateway1.nyi.mail.srv.osa (Postfix) with ESMTP id B21EB21BDF for ; Wed, 30 Nov 2011 18:41:53 -0500 (EST) Received: from frontend1.nyi.mail.srv.osa ([10.202.2.160]) by compute1.internal (MEProxy); Wed, 30 Nov 2011 18:41:53 -0500 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d= messagingengine.com; h=subject:mime-version:content-type:from :in-reply-to:date:cc:content-transfer-encoding:message-id :references:to; s=smtpout; bh=kD/Nl11w/eUV8b4unUtkugO+akE=; b=uY 82vuRIQr2AuO62z/aA98ft54+CkNOReu8HTAQAcaNrXKsskuoUpjNYL56NmCOUkH iR/Ouy47n8IZWjYALFc2T5mrKgyXoS2flrcjcZMKdUBa78sLU/4u6ynFgqEijGCx /CeMi6ZGAMNVWsDXrSvgn0sPOc31334kWIExFkmw4= X-Sasl-enc: kXjP78LctizZKv4J0oJmveiR4pm/NcjjzKQdf/djOkU2 1322696513 Received: from [10.164.210.59] (unknown [149.48.225.2]) by mail.messagingengine.com (Postfix) with ESMTPA id 7B2158E00D2; Wed, 30 Nov 2011 18:41:53 -0500 (EST) Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Keith Moore In-Reply-To: Date: Wed, 30 Nov 2011 18:41:53 -0500 Content-Transfer-Encoding: quoted-printable Message-Id: References: <282BBE8A501E1F4DA9C775F964BB21FE3EB78C3C98@GRFMBX704BA020.griffon.local> <916CE6CF87173740BC8A2CE44309696204193417@008-AM1MPN1-053.mgdnok.nokia.com> <4EC512A2.2060509@gmail.com> <890A58CF-8EAD-4F92-9981-9B5AA07EBF00@nominum.com> <4EC63E26.70104@gmail.com> <86163A8F-8628-4F67-BE93-3747F95A2F52@nominum.com> <4ECB6EAE.2010701@gmail.com> <702C34B3-F6B7-4EFB-91D5-8538540534A1@nominum.com> <4ECBE3BE.5070501@gmail.com> <759E821F-B503-4C8D-A79B-5F9A68A3613F@nominum.com> <4ED6A08D.9090703@gmail.com> To: Lorenzo Colitti X-Mailer: Apple Mail (2.1084) Cc: "mif@ietf.org" Subject: Re: [mif] Use cases for draft-ietf-mif-dhcpv6-route-option needed 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, 30 Nov 2011 23:41:55 -0000 +1. Keith On Nov 30, 2011, at 6:23 PM, Lorenzo Colitti wrote: > Actually, what decreases the implementation burden is not having the = option at all. The use cases I've heard so far for this option are all a = bit specious and I think they are outweighed by the harm that would be = caused if this option were to get into general use. >=20 > The reasoning goes something like this: >=20 > 1. The option is defined. > 2. OS foo implements it. > 3. Some network, somewhere, decides that they're only going to use = DHCPv6 for routing, because they only support OS foo. > 4. Other OSes are forced to implement the option because if they = don't, they are at a disadvantage compared to OS foo > 5. Once all OSes implement it, some other network, somewhere else, = decides that they're only going to support DHCPv6 for routing because = it's easier and because it matches what they do in IPv4, so they turn = off RAs. >=20 > Then we have a problem, because DHCPv6 has much less rich semantics = than RAs in the general case. A few examples: >=20 > - DHCPv6 is static. A lease is a promise and it can't be deprecated = except by the server that originally made the promise. If that server is = not around any more, or if clients don't support reconfigure, it can't = be deprecated at all. You can work around this with short lease times, = but that creates a scaling problem on the DHCPv6 server, because it's = centralized. > - The way the standards and the clients are written, clients pick one = DHCPv6 advertise and stick to it. So they can't merge multiple sources = of information. > - DHCPv6 does not share fate with routing; in fact, it has no = knowledge of routing. > - The combination of the fact that you can't merge multiple sources of = information and the fact that you can only provide static information = means that you're basically forced to hand out stuff that doesn't = change. If you're using DHCPv6 to set the default router, that basically = means you're forced to use VRRP or NAT if you want any sort of = redundancy. >=20 > To me, the lack of functionality that will result if we take the path = of least resistance described above far outweighs the benefits of being = able to configure [default] routes and on-link prefixes on a per-host = basis. You can do this in lots of other ways, for example assigning the = hosts you want to treat differently to different VLANs.