From iesg-secretary@ietf.org Fri Sep 2 20:26: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 D03D121F8BB9; Fri, 2 Sep 2011 20:26:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[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 e2RmDP3Cd0Gu; Fri, 2 Sep 2011 20:26:59 -0700 (PDT) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 29E7621F8BBB; Fri, 2 Sep 2011 20:26:59 -0700 (PDT) Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit From: The IESG To: IETF-Announce X-Test-IDTracker: no X-IETF-IDTracker: 3.60 Message-ID: <20110903032659.28305.90747.idtracker@ietfa.amsl.com> Date: Fri, 02 Sep 2011 20:26:59 -0700 Cc: mif mailing list , mif chair , RFC Editor Subject: [mif] Document Action: 'Multiple Interfaces and Provisioning Domains Problem Statement' to Informational RFC (draft-ietf-mif-problem-statement-15.txt) X-BeenThere: mif@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multiple Interface Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 03 Sep 2011 03:27:00 -0000 The IESG has approved the following document: - 'Multiple Interfaces and Provisioning Domains Problem Statement' (draft-ietf-mif-problem-statement-15.txt) as an Informational RFC This document is the product of the Multiple Interfaces Working Group. The IESG contact persons are Jari Arkko and Ralph Droms. A URL of this Internet Draft is: http://datatracker.ietf.org/doc/draft-ietf-mif-problem-statement/ Technical Summary A multihomed host receives node configuration information from each of its provisioning domains. Some configuration objects are global to the node, some are local to the interface. Various issues arise when multiple conflicting node-scoped configuration objects are received on multiple interfaces. Similar situations also happen with single interface host connected to multiple networks. This document describes these issues. Working Group Summary There is a consensus in the MIF WG for publication as an informational RFC. Document Quality The document has gone through various reviews and a successful WGLC. Personnel Responsible AD is Jari Arkko and the document shepherd is Hui Deng. From brian.e.carpenter@gmail.com Wed Sep 7 21:06: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 3929121F8B6B for ; Wed, 7 Sep 2011 21:06:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.586 X-Spam-Level: X-Spam-Status: No, score=-103.586 tagged_above=-999 required=5 tests=[AWL=0.013, 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 r6ZZbHa8Za2x for ; Wed, 7 Sep 2011 21:06:11 -0700 (PDT) Received: from mail-yi0-f44.google.com (mail-yi0-f44.google.com [209.85.218.44]) by ietfa.amsl.com (Postfix) with ESMTP id A1AA221F8B5D for ; Wed, 7 Sep 2011 21:06:11 -0700 (PDT) Received: by yie12 with SMTP id 12so337860yie.31 for ; Wed, 07 Sep 2011 21:08:02 -0700 (PDT) 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=4SMdSulmr9dARXDZbmZmsTR7xhzkm2XEhNCYs2O+XYE=; b=IW9uFdRIjPtebwsxMO+38LxroWhREwQO0kxpe5BcvNEzCNYB9qJNGtsARJFS0cSCDA MLEhGv6rNbZGimUmF6Jrg5QGq/ZCkXpw8AaLJTlf6CtCniqxwGtLM9WDjZAzMc4BQu0B Ai7W7xt8ub7jtHBI5jVe5UDc4kX3jWyX8wgTQ= Received: by 10.43.43.196 with SMTP id ud4mr79197icb.287.1315454882295; Wed, 07 Sep 2011 21:08:02 -0700 (PDT) Received: from [130.216.38.124] (stf-brian.sfac.auckland.ac.nz [130.216.38.124]) by mx.google.com with ESMTPS id v2sm3617780ibg.2.2011.09.07.21.07.58 (version=SSLv3 cipher=OTHER); Wed, 07 Sep 2011 21:08:01 -0700 (PDT) Message-ID: <4E683F9B.7020905@gmail.com> Date: Thu, 08 Sep 2011 16:07:55 +1200 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: Margaret , mif@ietf.org Subject: Re: [mif] Last Call for MIF DNS server selection document 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, 08 Sep 2011 04:06:12 -0000 Hi, Has this document been reviewed in DNSEXT and DNSOP? If not, I would strongly recommend that before asking the AD to review it in detail. I would expect considerable discussion of the following text and its consequences: > In deployments where multiple namespaces are present, selection of > correct route and destination and source addresses for the actual IP > connection is crucial as well, as the resolved destination's IP > addresses may be only usable on the network interface over which the > name was resolved on. Regards Brian Carpenter On 2011-08-29 19:31, Hui Deng wrote: > Hello all, > > Based on the last IETF mif meeting, we are issueing working group last call for the document: > http://tools.ietf.org/id/draft-ietf-mif-dns-server-selection-03.txt > > This is a 2 week LC, it will finish on September 12, > Please send substantive review and editorial comments to mif@ietf.org, > > thanks, > > Margaret and Hui > > > > ------------------------------------------------------------------------ > > _______________________________________________ > mif mailing list > mif@ietf.org > https://www.ietf.org/mailman/listinfo/mif From teemu.savolainen@nokia.com Wed Sep 7 23:14: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 08F1921F8C73 for ; Wed, 7 Sep 2011 23:14:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.635 X-Spam-Level: X-Spam-Status: No, score=-2.635 tagged_above=-999 required=5 tests=[AWL=-0.036, 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 ZJFOXi7FyszE for ; Wed, 7 Sep 2011 23:14:31 -0700 (PDT) Received: from mgw-da02.nokia.com (smtp.nokia.com [147.243.128.26]) by ietfa.amsl.com (Postfix) with ESMTP id 05C3A21F8C63 for ; Wed, 7 Sep 2011 23:14:29 -0700 (PDT) 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.3) with ESMTP id p886GBbs003580; Thu, 8 Sep 2011 09:16:18 +0300 Received: from smtp.mgd.nokia.com ([65.54.30.6]) by vaebh102.NOE.Nokia.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.4675); Thu, 8 Sep 2011 09:16:11 +0300 Received: from 008-AM1MMR1-004.mgdnok.nokia.com (65.54.30.59) by NOK-am1MHUB-02.mgdnok.nokia.com (65.54.30.6) with Microsoft SMTP Server (TLS) id 8.2.255.0; Thu, 8 Sep 2011 08:16:10 +0200 Received: from 008-AM1MPN1-032.mgdnok.nokia.com ([169.254.2.143]) by 008-AM1MMR1-004.mgdnok.nokia.com ([65.54.30.59]) with mapi id 14.01.0323.007; Thu, 8 Sep 2011 08:16:07 +0200 From: To: , Thread-Topic: [mif] Last Call for MIF DNS server selection document Thread-Index: AQHMbdzsBHSQ8Tn9hkac95+LwFpGipVC/6Hg Date: Thu, 8 Sep 2011 06:16:07 +0000 Message-ID: <916CE6CF87173740BC8A2CE4430969620256F33F@008-AM1MPN1-032.mgdnok.nokia.com> References: <4E683F9B.7020905@gmail.com> In-Reply-To: <4E683F9B.7020905@gmail.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes 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+/nZJb9Kg7IijnarCFufw93yGp9Kqg4VsreROV3oSoCKo4MAZQAlH7cl7QEYi2t0p8hTrsrklpyqBfRuV1a3TP5t4zLsal1WzFsT0mQwFWR/yRh3UhJztIIhyLXE7aj3YtN85Eqji4hyMU9zDnsRybCxak6t2mfbgLZX2mjzSIIHnDkgCjyHZFFOhfBqPd/c5FcvKdb64f0sgP1bp0Rng5aZTrafF1qFNxmzB3fX0dr0qbeG9YfeKCcsiZk5WqSUtPkVYQ2fFAPg== x-originating-ip: [10.162.78.119] Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=SHA1; boundary="----=_NextPart_000_00A2_01CC6E07.EFE8CE60" MIME-Version: 1.0 X-OriginalArrivalTime: 08 Sep 2011 06:16:11.0037 (UTC) FILETIME=[CDDD2CD0:01CC6DEE] X-Nokia-AV: Clean Cc: mif@ietf.org, margaretw42@gmail.com Subject: Re: [mif] Last Call for MIF DNS server selection document 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, 08 Sep 2011 06:14:32 -0000 ------=_NextPart_000_00A2_01CC6E07.EFE8CE60 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Brian, Thank you for review. I agree it is a good idea to consult those WGs (and DHC as well I suppose), but what makes you so concerned of this text: > > In deployments where multiple namespaces are present, selection of > > correct route and destination and source addresses for the actual IP > > connection is crucial as well, as the resolved destination's IP > > addresses may be only usable on the network interface over which the > > name was resolved on. I wrote that as I thought it would be useful to talk a little about bigger picture of some deployments (like in the demo we had few IETFs back - without presence of DHCPv6 more specific route options the system would not have worked properly) .. but if that text creates an unwanted link or dependency or confusion, I think we can drop the text just as well and focus on the document just to the new options and leave this kind of additional system-level consideration out of the doc. Best regards, Teemu ------=_NextPart_000_00A2_01CC6E07.EFE8CE60 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIOuzCCAzYw ggIeoAMCAQICBDpVqdkwDQYJKoZIhvcNAQEFBQAwKTEOMAwGA1UEChMFTm9raWExFzAVBgNVBAMT Dk5va2lhICBSb290IENBMB4XDTAxMDEwNTExMDUwNVoXDTE2MDEwMjExMDUwNVowKTEOMAwGA1UE ChMFTm9raWExFzAVBgNVBAMTDk5va2lhICBSb290IENBMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8A MIIBCgKCAQEAsrTy8gLmr4LYvp0khVUVHw7ascdl+Cjr+yI5MlZ6J/U6Qsvkiqthgqq8rPcLV0P1 92TfBr27VgKEeCaZe0icS1jC2spM/wRv3j2WxdkKxb9kDJtuCNJaRBqvi5vGTHB15nmEmKuL5f3i rAxeHqPjgS496oWcudzFT1e7Xrc/gWGFYd72+/ykIFXjWOMZv6QpxD8x1hLPyh2YVXRk9U7N7pvm RQNX29g4SCFJY2BBIa5JPlwIF8Nc9IePaC/E/2M4tGMtiOOZlm99EoL7N0hJZtFSvUwdCBud/viH 4DgsKGjNkNKi6pAHc9IaXB6tIykcoYp+L+oe/3+cuEJaCj1EKwIDAQABo2YwZDASBgNVHRMBAf8E CDAGAQH/AgEEMB0GA1UdDgQWBBSNjfefoQ0AITLvqe0iruA79NB9sDAfBgNVHSMEGDAWgBSNjfef oQ0AITLvqe0iruA79NB9sDAOBgNVHQ8BAf8EBAMCAYYwDQYJKoZIhvcNAQEFBQADggEBAIGEPql2 TALyKi/h1J+Mh5XolAtYppcSOLMtBkoA7ZovGBDNvl0VbZs8AAojJqkUoWBB+L6DKyl/jKhNfKcu rWRGRyj7pnbxrKLsI3gmWNWkyo2b60wJwe9fqPD5ZQy3oEiMit9l0Ba6il/k2GqYopUCNMa7mfeb E2LeBy5ChYMiCi97UQSJvAdzEYylTJw8Awc6AiM2Ve5N+XxsmKgNf/2A/5IJ3EZZ+wFRmkI4062A oNU302rqAt0HH88jzoUF4AfYHWl6HpYhGXFbcX44rHINyPmFBRxLYIFJ6ZWUr/mXpL/e6rqFtNWO kV6UoJND7OVZkbLh7F1+lcqXRU8TPBMwggOHMIICb6ADAgECAgRBtbHpMA0GCSqGSIb3DQEBBQUA MCkxDjAMBgNVBAoTBU5va2lhMRcwFQYDVQQDEw5Ob2tpYSAgUm9vdCBDQTAeFw0wNjAzMzAwOTU3 MTFaFw0xNjAxMDIxMTA1MDVaMDMxCzAJBgNVBAYTAkZJMQ4wDAYDVQQKEwVOb2tpYTEUMBIGA1UE AxMLTm9raWEgQkkgQ0EwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQDtFCg3QEjSCg6T IUxoWsNwELh8bBNiUQPCPmg8c2DHQYXWWCSCMb+S0Fvh1qqI1xt+XnzyFq+5eqzGzDj4UaBcG+d9 qxrCFly8sHyoPTryyPrR0EI2UUDWwfS6ojhqgwghRqo8G38TjFusyBtLub/5L6yvWYSOHD+JcB+q VM2fbkArPYK4Ydv8WG/DbHjGn0gKq0zwpVZKI/gCK/QALYvte02NXseqvY9/GOyLtjy3Z8erFv71 KKTq+gxI/7DK55pJf3PoD+kT4kyGm6EF9DTdK4ojMdar17uyX0IOZz/4vkkF0d+60nmnLX63FJPA jUyB0HUNJ32NXDo9UsM38aoNAgMBAAGjgawwgakwDwYDVR0TAQH/BAUwAwEB/zARBgNVHSAECjAI MAYGBFUdIAAwDgYDVR0PAQH/BAQDAgGGMFQGA1UdIwRNMEuAFI2N95+hDQAhMu+p7SKu4Dv00H2w oS2kKzApMQ4wDAYDVQQKEwVOb2tpYTEXMBUGA1UEAxMOTm9raWEgIFJvb3QgQ0GCBDpVqdkwHQYD VR0OBBYEFKcksD7Fg+8EDlB2Sxgy58pW0Sy6MA0GCSqGSIb3DQEBBQUAA4IBAQAC3lEUplDlVNOT Pjz/XFezXx2bV2XbCFindhA3F815Egi55H6/cYezEjoP4QLNEGGl2I3aLvkn5A0T8I4pbiFPhIiu B/frbbGg6k6GjQLe/bFQ8F1mAOOR+GyneKZFPfzaRV0jiIR9QqnMXTf8RvKkCJyFj10MZVsLIy/Y uBkzeP3JhzDhUdtPfwmJN6ZbIhH5uR/2BwAGtgQknb8WX3I4wnhWtMUxB8XmayayYs8qWYeIiVkI FV+sLTkWUWVvvKUjyakBpbAW2vUP84DYsJ8TL1YefNjf/nIOByMcORLuV/1gPjyv00qJbcB59AA+ iXe3zIo8QNcgXG0uPQQFmrGDMIID5DCCAsygAwIBAgIQMH5apak8lEy6LmLlLsJy8TANBgkqhkiG 9w0BAQUFADAzMQswCQYDVQQGEwJGSTEOMAwGA1UEChMFTm9raWExFDASBgNVBAMTC05va2lhIEJJ IENBMB4XDTExMDkwNjA1NTIwNFoXDTE0MDkwNjA1NTIwNFowVjEOMAwGA1UECgwFTm9raWExDzAN BgNVBAsMBlBlb3BsZTEYMBYGCgmSJomT8ixkAQEMCDEwMDI0Njc2MRkwFwYDVQQDDBBTYXZvbGFp bmVuIFRlZW11MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAshEsmw6Yiz6XWX26oF+I s5fsfE1OfCjOelclmtqCiIgXND5klkNOBs2d4ZGzgD9mN+XnTZnOTh249c2WxPBugf12DCcDmBAJ gL+VuWUJVBTE5NRchm/O8nZnZsRFst+gAC9/Juykh4+EYewZ7QbpnlwW7hNpj8eH+rMr+OZHKzdp KTftgVjmuF4JJ/cPMQUjL8SuGj+zBW6IWPOZdqkEMtf7Pr8kkYbZsh0SgJ0ceRHZ7Uc06mB/y+C1 UnJPxehTTdu8tpCjdzXgBw/H2uuW1J3qdHbCfbuDILql8V8RiZKubcZLhdsD3Jvj8qK0DGWBJa6x p90q5p3pLE8LvAeCgQIDAQABo4HQMIHNMA4GA1UdDwEB/wQEAwIEMDAfBgNVHSMEGDAWgBSnJLA+ xYPvBA5QdksYMufKVtEsujAZBgNVHSAEEjAQMA4GDCsGAQQBXgExBgEHAzA5BgNVHR8EMjAwMC6g LKAqhihodHRwOi8vY3JsLm5va2lhLmNvbS9Ob2tpYSUyMEJJJTIwQ0EuY3JsMCUGA1UdEQQeMByB GnRlZW11LnNhdm9sYWluZW5Abm9raWEuY29tMB0GA1UdDgQWBBQTRzvZsgmQrAGCeuzdHTGAC6Jg UzANBgkqhkiG9w0BAQUFAAOCAQEACmPVsdi07pjK5gDa+W5JlE2C74kVVsB8alBqfioYeR5At2FG B7sua4Dz5H7TJMpZ1jYFeI+zjexD5f+beY2IlV15lMoWD+5e38QlLYjwfe2LAyvdzBKXW0e0U6Bt p78ft4gyVak1X+Db+ebR+FNHUOMNhm+yK3w9sy5ZQzBFusIx4OgxGvcZhyhmd9WjipSTalgPwgqV Ju2aPADCG++OEXmgEWRLsR4yNopkgK4ftVqrN5uUtLs83qdeXTRcNRiET1IOx5zmYFZ6q3gjKIx5 iyuxcDeYas93vVHUcaRRYpsoby5CHq7Z/j/TQhtqO/knWuxLFFiCUgdGKMKrRkg29DCCBAowggLy oAMCAQICEQCBvi+p+bA/dBtBtybwA6YYMA0GCSqGSIb3DQEBBQUAMDMxCzAJBgNVBAYTAkZJMQ4w DAYDVQQKEwVOb2tpYTEUMBIGA1UEAxMLTm9raWEgQkkgQ0EwHhcNMTEwOTA2MDU1MDM0WhcNMTMw OTA1MDU1MDM0WjBWMQ4wDAYDVQQKDAVOb2tpYTEPMA0GA1UECwwGUGVvcGxlMRgwFgYKCZImiZPy LGQBAQwIMTAwMjQ2NzYxGTAXBgNVBAMMEFNhdm9sYWluZW4gVGVlbXUwggEiMA0GCSqGSIb3DQEB AQUAA4IBDwAwggEKAoIBAQDFPmbRVwuo52v+h6xnQUqokAx2xsHjmPBniEkzgtgBNJsFi838ATEg 1zsx+VotoJg7hMijcrQfpTAgW6gpLGnlmw5QQswrNK1zleOHb4pA5JguU3WhVKFkAH/6/2EU2k/9 m8Pb/gwP55cYg80R6fRmbdsWKhseXF/1isW/rJcWLmIYDg/rXfo3ixqtT9MroAMiuoXnb0ij1L2d Jj64LDp3Ld8Jo0qZzk3Fj4apo8PBd8eAH6HloVBJkxQcwAnv561A+Xi1GHZ2mafRYJGO+1uBDwyd g/8ybEXXA4MKo8lPKjBebYBUFvz80DBA/Lq74UysXkG23BSulcG4xQSYGlyzAgMBAAGjgfUwgfIw HwYDVR0jBBgwFoAUpySwPsWD7wQOUHZLGDLnylbRLLowGQYDVR0gBBIwEDAOBgwrBgEEAV4BMQYB BgQwOQYDVR0fBDIwMDAuoCygKoYoaHR0cDovL2NybC5ub2tpYS5jb20vTm9raWElMjBCSSUyMENB LmNybDAjBgNVHSUEHDAaBggrBgEFBQcDAgYEVR0lAAYIKwYBBQUHAwQwDgYDVR0PAQH/BAQDAgeA MCUGA1UdEQQeMByBGnRlZW11LnNhdm9sYWluZW5Abm9raWEuY29tMB0GA1UdDgQWBBTGhbTJF0EX iagjymQo6GIuSQeRVDANBgkqhkiG9w0BAQUFAAOCAQEAqai6TxZ/BlMHZIhJNPriBPXkQhUlBkGA buJZ5sVm1HIQhWN8elZKjjJdHi1qWEKhMg7yHjEMZsyV8XAZzK0UnOqkpUnt+jnVkNZ9O7/jRtyK f4WUtq5jErc8Hlv4bbGFRHk1T7AuLLE52r1lYOdmoibnQp03QtlDvHUNa68G7jvzThJhieB7U1xh vH3yy0ktaVnWEgAylqf9yIUFjnqau5R6cE1Xo57IYPk/KitX0YF+OigEI/bOQVMi+fze93ZsAOJv /z6g/NGemvUgl5YSdX0uPQK6kEHf/sp/nZyUWWQ7OjtVSqkq2YuYEueQFxTfafl+78GWqgm6W/Bl 32laYzGCAuswggLnAgEBMEgwMzELMAkGA1UEBhMCRkkxDjAMBgNVBAoTBU5va2lhMRQwEgYDVQQD EwtOb2tpYSBCSSBDQQIRAIG+L6n5sD90G0G3JvADphgwCQYFKw4DAhoFAKCCAXgwGAYJKoZIhvcN AQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG9w0BCQUxDxcNMTEwOTA4MDYxNjA1WjAjBgkqhkiG9w0B CQQxFgQUFgSpDvDRTGuBfBKse57EqB/lC3EwVgYJKwYBBAGCNxAEMUkwRzAzMQswCQYDVQQGEwJG STEOMAwGA1UEChMFTm9raWExFDASBgNVBAMTC05va2lhIEJJIENBAhAwflqlqTyUTLouYuUuwnLx MFgGCyqGSIb3DQEJEAILMUmgRzAzMQswCQYDVQQGEwJGSTEOMAwGA1UEChMFTm9raWExFDASBgNV BAMTC05va2lhIEJJIENBAhAwflqlqTyUTLouYuUuwnLxMGcGCSqGSIb3DQEJDzFaMFgwCgYIKoZI hvcNAwcwDgYIKoZIhvcNAwICAgCAMA0GCCqGSIb3DQMCAgFAMAcGBSsOAwIHMA0GCCqGSIb3DQMC AgEoMAcGBSsOAwIaMAoGCCqGSIb3DQIFMA0GCSqGSIb3DQEBAQUABIIBAKzGuRObtUonyHnJeyGr eYTVFSNmoFI0ROyYT/P9PCnywpxzOqbKxKIe3XaZ4Zw/g+Wp2orOQLZEQtuLXyI44smY8fX97aEd 94zbJC9aw6fBwPo3FJbmNVVPNpAhqqSSx9iXUFdiE/nfOhvvsCgrh69CJYFtQQJpkSP6py9UUfho 7/S2750b4maToIzg+JgWe52HClZHusXaGz+8iqur/Kggf/cy1ci68rIJ8WqAJ3az3cHhfK+/MyhP t9DjVc2CPv+SnbfKI/qr9TdD/MZNopKvnTHT2KbPwM49vfTGocUvOQnKUGIbqHDAf8FRlPNH8sKg cTs0e5Z8kcjwL75QDnoAAAAAAAA= ------=_NextPart_000_00A2_01CC6E07.EFE8CE60-- From ajs@anvilwalrusden.com Thu Sep 8 13:41: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 A5E4F21F8B54 for ; Thu, 8 Sep 2011 13:41:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.568 X-Spam-Level: X-Spam-Status: No, score=-2.568 tagged_above=-999 required=5 tests=[AWL=0.031, 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 cPhSwi+HDdUJ for ; Thu, 8 Sep 2011 13:41:40 -0700 (PDT) Received: from mail.yitter.info (mail.yitter.info [208.86.224.201]) by ietfa.amsl.com (Postfix) with ESMTP id 51BB321F8B49 for ; Thu, 8 Sep 2011 13:41:40 -0700 (PDT) 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 CAF681ECB420 for ; Thu, 8 Sep 2011 20:43:30 +0000 (UTC) Date: Thu, 8 Sep 2011 16:43:30 -0400 From: Andrew Sullivan To: mif@ietf.org Message-ID: <20110908204329.GN38973@shinkuro.com> References: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) Subject: Re: [mif] Last Call for MIF DNS server selection document 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, 08 Sep 2011 20:41:41 -0000 Dear colleagues, On Mon, Aug 29, 2011 at 03:31:39PM +0800, Hui Deng wrote: > Based on the last IETF mif meeting, we are issueing working group last call for the document: > http://tools.ietf.org/id/draft-ietf-mif-dns-server-selection-03.txt I have read this document, and previous drafts. I have some comments. First, about nits: there are several places where the document needs a good once-over for correct usage, grammar, and spelling. Articles seem to be missing in many places. It'd be good to sort this out, but I can understand the document without this being fixed & I'm sure the RFC Editor will fix it anyway. I'm not going to send a list of nits just now because I have too many substantive comments. As an overall comment, there are sections of the document that explain the motivation and background, and sections of the document that prescribe steps to be taken. The former are informative, and the latter normative. I suggest including near the beginning an overview stating what sections are informative and what are normative, and breaking those sections cleanly (i.e. no explanatory text in the normative sections). At the beginning of the draft we have this: When multiple namespaces are visible for a node, some DNS servers have information other servers do not have. Because of that, a multi-homed node cannot assume every DNS server is able to properly answer for any query, but instead the node must be able to ask right server for the information it needs. I've had a hard time expressing why this text has been bothering me, but I think I understand what it is: that text is not explicit enough that it is starting from the premise that the DNS is not a unified global namespace. I think it needs another sentence, at the beginning, along the following lines: We start from the premise that operators sometimes include private namespaces in the answers they provide from DNS servers, and that those private namespaces are at least as useful to clients as the answers from the public DNS. The next paragraph is not really convincing as it stands: An example of an application that benefits from multi-homing is a web browser that commonly accesses many different destinations and needs to be able to dynamically communicate over different network interfaces. I think what that actually means is this: An example of an application that benefits from multi-homing is a web browser that commonly accesses many different destinations, each of which is available only on one network. The browser therefore needs to be able to communicate over different network interfaces, depending on the destination it is trying to reach. The key point here, I think, is that the networks are disparate and not actually all available via the public network. By making these adjustments, it makes the document more open-handed about the fact it's trying to address: there are all kinds of pockets on the Internet, and you have to connect to different pockets via different means. In section 4.1, we have this: When a DNS query needs to be made, the resolver SHOULD give highest precedence to the DNS servers explicitly known to serve matching suffixes or prefixes. I really dislike the term "suffix" here, and I'm not sure "prefix" is what you want either. I think "suffix" really means "domain", right? That is, if I offer a DNS server that is high-priority for example.com, it can answer for anything from example.com all the way down. No? Similarly, you might just want "networks" for the reverse tree, since "prefix" doesn't exactly get it right: the network address is turned around in the DNS query. (This also appears elsewhere in the draft, but I won't mention it again unless I'm proposing text.) "Prefix" is probably fine if you make it clear that you're providing the prefix of a network, and that it's the client's job to do the right thing with that prefix in order to formulate reverse-tree DNS queries. Next, However, the resolver SHOULD take into account different trust levels of pieces of DNS server selection information the resolver may have received from node's network interfaces. The resolver SHOULD prefer DNS servers of trusted interfaces. Why isn't this MUST? This entire procedure is hard for me to follow, in fact. It seems to me that we have two different meanings of "trust" here, and I think that may be part of the problem. The first meaning (trust1) is "a setting that comes with the information that DNS server S on interface I provides namespace N with trust-level T". This is a trust-value that is metadata provided by the provider of the name server address-interface binding. The second meaning (trust2) is how much you, the client, believe the data you got: did you get the trust1 data in a way that you can be sure it's legitimate? It seems to me that combining trust1 and trust2 into a single scale might be wrong, and I think that the last row in Figure 4 suggests this. If I simply don't know whether the data I get on interface B is real or spoofed, why would I ever use that, even if it's "medium priority", over the data I can be sure is an unspoofed answer on interface A? Also, I think this sentence is missing an "un" before some "trusted": The DNS servers of trusted interfaces may be of highest priority only if trusted interfaces specifically configure DNS servers to be of low priority. I think the discussion just after Figure 4 about revealing information about ongoing communications is total nonsense, and should be removed. If you want to put names in the DNS, they're never going to be secret. The attempts to use split-brain DNS and so on for hiding network resources are a completely misguided attempt at security by obscurity, and I don't think the draft should include any text that even implies this technique works. Private DNS names leak all over the place, and if you think otherwise you're dreaming. Later, we have Because DNSSEC provides cryptographic assurance of the integrity of DNS data, data that can be validated under DNSSEC is necessarily to be preferred over data that cannot be. It follows that, if validation is not performed by the host making the decision about whether to trust the DNS data from a given interface, it cannot make a decision to prefer data from any interface with any great assurance: any response could be forged, and there is no way to detect it without DNSSEC. That isn't true. If you have a cryptographically strong connection to a DNS server and you know that it is doing DNS validation (because, for instance, your corporate overlords told you, "We do validation on the VPN DNS server"), you do in fact have a reason to prefer the answers from that server. You might set DO and not CD, and get back the AD bit on your answer, giving you evidence that the validation was done by the server. I think the paragraph can be rewritten this way (although this includes some explanatory material and some normative material; as I suggested above, perhaps that ought to be split). Because DNSSEC provides cryptographic assurance of the integrity of DNS data, data that can be validated under DNSSEC is necessarily to be preferred over data that cannot be. There are two ways that a host can determine that data is valid under DNSSEC. The first is to perform DNSSEC validation itself. The second is to have a secure connection to an authenticated DNS server, and to rely on that DNS server to perform DNSSEC validation (signalling that it has done so using the AD bit). If a DNS response is not proven to be unmolested using DNSSEC, then a host cannot make a decision to prefer data from any interface with any great assurance: any response could be forged, and there is no way to detect the forgery without DNSSEC. Therefore, a DNSSEC-aware resolver MUST NOT proceed with a reply that cannot be validated using DNSSEC if DNS queries sent to other servers are still pending. This instruction seems to contradict the previous text: In the case of a trusted DNS server replying negatively to a question having matching suffix, it will be for implementation to decide whether to consider that as a final response, or whether to ask also from other DNS servers. The implementation decision may be based, for example, on deployment or trust models. Instead of "matching suffix", we could say something like "from a DNS server that can provide answers for the queried name". But I think what this is saying is that, if you get a validated NXDOMAIN from an interface, you're allowed to go on and ask other servers. Even if the answer can't be validated? If so, this seems to contradict the passages before it, and it's clearly an attack vector on DNSSEC's provable non-existence. Some people think that feature is dumb, but it's part of what DNSSEC offers now, and it would be strange to introduce a way to turn it off. I'd add a reference here to the "different trust anchor" discussion in Appendix B. See also below. I can't see anything you can do about cases where a DNS server always lies to you. On the other hand, if you do DNSSEC, those servers will always fail validation anyway, so we can hope they'll meet the fate they deserve. In section 4.2, I don't understand, "IPv6 prefixes should cover all the DNS suffixes configured in this option." Maybe I've actually misunderstood the use of "prefix" and "suffix" in this document? In section 4.5, I find this odd: The OPTION_DNS_SERVER_SELECT is designed to coexist with OPTION_DNS_SERVERS defined in [RFC3646]. The DNS servers configured via OPTION_DNS_SERVERS MUST BE considered as default name servers with medium preference. When both options are received from the same network interface and the OPTION_DNS_SERVER_SELECT contains default DNS server address, the resolver MUST make the decision which one to prefer based on preferences. I read that to mean that, if you get both options and the OPTION_DNS_SERVER_SELECT contains a default DNS server address, then the behaviour is up to you (i.e. undefined). Why is that a MUST? Why isn't it just "... the resolver MAY use whichever option it likes"? In the same section, does this If both OPTION_DNS_SERVERS and OPTION_DNS_SERVER_SELECT contain the same DNS server(s) IPv6 address(es), only one instance of each DNS servers' IPv6 addresses shall be added to the DNS server list. mean "only add the same address of a DNS server to the server list once"? The passage as it is reads to me as though you might throw away some addresses you get. In section 4.6., I think that it needs to be made clear that a bare name is first treated as a pre-DNS hostname before it encounters the DNS search list. (Frankly, that entire mechanism is broken, and it would suit me just fine if the document said, "This algorithm is incompatible with the DNS search list and the OPTION_DOMAIN_LIST feature." But I know people would scream about it. It's still broken.) In 4.7, what about other things that could do context-sensitive referrals, like SRV? In A.1, the same discussion about revealing information as above pertains. Appendix B is interesting because it addresses a concern I have about what to do when validation succeeds on an NXDOMAIN, as discussed above under section 4.1. I hope these comments are useful. Best regards, Andrew -- Andrew Sullivan ajs@anvilwalrusden.com From brian.e.carpenter@gmail.com Thu Sep 8 14:00: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 B3A6C21F8B46 for ; Thu, 8 Sep 2011 14:00:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.583 X-Spam-Level: X-Spam-Status: No, score=-103.583 tagged_above=-999 required=5 tests=[AWL=0.016, 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 l3unMCvYDaPK for ; Thu, 8 Sep 2011 14:00:54 -0700 (PDT) Received: from mail-fx0-f44.google.com (mail-fx0-f44.google.com [209.85.161.44]) by ietfa.amsl.com (Postfix) with ESMTP id A453021F8B29 for ; Thu, 8 Sep 2011 14:00:47 -0700 (PDT) Received: by fxe6 with SMTP id 6so2059889fxe.31 for ; Thu, 08 Sep 2011 14:02:40 -0700 (PDT) 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=QcI8W4WjjLrxQoKX98f18q6fHbjvC7yft9bD7FrBXq4=; b=Q+JZob5FBUtcqcrXGqgXhO12nBtGYIc4y822TMvoKR0W+mJc+0sn8dZEf+VsB4oiz2 fbQhZY71gjWGTl6E3K0HQSl66A2W7InSbAo7QZl20BDChgzbyIwmWxFf/S0AoGNY82uT /BamC+gJjO/MAb+HLd8spYg0gto80T2vqBhuQ= Received: by 10.223.85.154 with SMTP id o26mr325049fal.72.1315515760101; Thu, 08 Sep 2011 14:02:40 -0700 (PDT) Received: from [10.1.1.4] ([121.98.251.219]) by mx.google.com with ESMTPS id c5sm1916136fai.2.2011.09.08.14.02.35 (version=SSLv3 cipher=OTHER); Thu, 08 Sep 2011 14:02:38 -0700 (PDT) Message-ID: <4E692D62.5080902@gmail.com> Date: Fri, 09 Sep 2011 09:02:26 +1200 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: <4E683F9B.7020905@gmail.com> <916CE6CF87173740BC8A2CE4430969620256F33F@008-AM1MPN1-032.mgdnok.nokia.com> In-Reply-To: <916CE6CF87173740BC8A2CE4430969620256F33F@008-AM1MPN1-032.mgdnok.nokia.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: margaretw42@gmail.com, mif@ietf.org, denghui02@hotmail.com Subject: Re: [mif] Last Call for MIF DNS server selection document 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, 08 Sep 2011 21:00:54 -0000 Teemu, On 2011-09-08 18:16, teemu.savolainen@nokia.com wrote: > Brian, > > Thank you for review. I agree it is a good idea to consult those WGs (and > DHC as well I suppose), but what makes you so concerned of this text: > >>> In deployments where multiple namespaces are present, selection of >>> correct route and destination and source addresses for the actual IP >>> connection is crucial as well, as the resolved destination's IP >>> addresses may be only usable on the network interface over which the >>> name was resolved on. > > I wrote that as I thought it would be useful to talk a little about bigger > picture of some deployments (like in the demo we had few IETFs back - > without presence of DHCPv6 more specific route options the system would not > have worked properly) .. but if that text creates an unwanted link or > dependency or confusion, I think we can drop the text just as well and focus > on the document just to the new options and leave this kind of additional > system-level consideration out of the doc. As Andrew pointed out, the draft starts "...from the premise that operators sometimes include private namespaces in the answers they provide from DNS servers, and that those private namespaces are at least as useful to clients as the answers from the public DNS." I believe that you will discover during IETF LC that many people have strong feelings about this premise; as Andrew implied, conceptually the DNS is a unified global namespace. This draft is a backdoor way of legitimising an ambiguous namespace. I don't think that will have an easy time in IETF LC, especially if it is dropped as a surprise into the DNS community. It's your choice, but I would suggest that exposing it to the DNS WGs now would be a smart move. It goes further. The IETF has a longstanding issue with technology that encourages walled gardens. See for example RFC 3002. I think there will be quite some discussion, and this will definitely happen even if you try to remove the "system-level" considerations, because they are strongly implied anyway. Personally I'm not sure what I think about this, but it needs to be discussed in the community IMHO. Brian From ajs@anvilwalrusden.com Thu Sep 8 14:13: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 2342121F8804 for ; Thu, 8 Sep 2011 14:13:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.568 X-Spam-Level: X-Spam-Status: No, score=-2.568 tagged_above=-999 required=5 tests=[AWL=0.031, 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 aEsbb45VCa-l for ; Thu, 8 Sep 2011 14:12:59 -0700 (PDT) Received: from mail.yitter.info (mail.yitter.info [208.86.224.201]) by ietfa.amsl.com (Postfix) with ESMTP id 607D021F87FA for ; Thu, 8 Sep 2011 14:12:59 -0700 (PDT) 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 C510B1ECB420 for ; Thu, 8 Sep 2011 21:14:50 +0000 (UTC) Date: Thu, 8 Sep 2011 17:14:50 -0400 From: Andrew Sullivan To: mif@ietf.org Message-ID: <20110908211450.GP38973@shinkuro.com> References: <4E683F9B.7020905@gmail.com> <916CE6CF87173740BC8A2CE4430969620256F33F@008-AM1MPN1-032.mgdnok.nokia.com> <4E692D62.5080902@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4E692D62.5080902@gmail.com> User-Agent: Mutt/1.5.21 (2010-09-15) Subject: Re: [mif] Last Call for MIF DNS server selection document 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, 08 Sep 2011 21:13:00 -0000 On Fri, Sep 09, 2011 at 09:02:26AM +1200, Brian E Carpenter wrote: > into the DNS community. It's your choice, but I would suggest that > exposing it to the DNS WGs now would be a smart move. I'll mention that I did draw the attention of DNSEXT to this WGLC. I also mentioned it in a recent teleconference I had with some others. Sorry I didn't get the note out sooner: August turned out to be a rather trying month on the personal front, and I wasn't following many lists. Best, A -- Andrew Sullivan ajs@anvilwalrusden.com From moore@network-heretics.com Thu Sep 8 15:20: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 375C721F8BD3 for ; Thu, 8 Sep 2011 15:20:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.467 X-Spam-Level: X-Spam-Status: No, score=-3.467 tagged_above=-999 required=5 tests=[AWL=0.132, 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 br4zKnVUkufe for ; Thu, 8 Sep 2011 15:20:27 -0700 (PDT) Received: from out4.smtp.messagingengine.com (out4.smtp.messagingengine.com [66.111.4.28]) by ietfa.amsl.com (Postfix) with ESMTP id E693621F8BCB for ; Thu, 8 Sep 2011 15:20:26 -0700 (PDT) Received: from compute6.internal (compute6.nyi.mail.srv.osa [10.202.2.46]) by gateway1.nyi.mail.srv.osa (Postfix) with ESMTP id D25DF2B50B; Thu, 8 Sep 2011 18:22:19 -0400 (EDT) Received: from frontend1.nyi.mail.srv.osa ([10.202.2.160]) by compute6.internal (MEProxy); Thu, 08 Sep 2011 18:22:19 -0400 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=Y9f4QaK4NNJ8UvAJ4GwQMkHiRXY=; b=H9 fk0HX+1v1Ep0wXX8JRAK/Kh1liCiqgfVPdhi678rBk8mHpnBgHqy7bkXD8WCn0tP 3O+V73iYTCazBTxPMquq013z4mdinPZAZDrk68IACfgtoI3vK/TWiJbrniWtBV6p PYyLzuXo2khOyNul+tTt3SJLbX0q/4c5FOi5XwZJI= X-Sasl-enc: NYZRhHFXlaH0JehoFJobeGZq5DhA3gPx7ohDaRfD64S9 1315520539 Received: from host65-16-145-177.birch.net (host65-16-145-177.birch.net [65.16.145.177]) by mail.messagingengine.com (Postfix) with ESMTPA id 914F16C021B; Thu, 8 Sep 2011 18:22:18 -0400 (EDT) Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Keith Moore In-Reply-To: <4E692D62.5080902@gmail.com> Date: Thu, 8 Sep 2011 18:22:17 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: References: <4E683F9B.7020905@gmail.com> <916CE6CF87173740BC8A2CE4430969620256F33F@008-AM1MPN1-032.mgdnok.nokia.com> <4E692D62.5080902@gmail.com> To: Brian E Carpenter X-Mailer: Apple Mail (2.1084) Cc: mif@ietf.org, margaretw42@gmail.com, denghui02@hotmail.com Subject: Re: [mif] Last Call for MIF DNS server selection document 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, 08 Sep 2011 22:20:28 -0000 On Sep 8, 2011, at 5:02 PM, Brian E Carpenter wrote: > Teemu, >=20 > On 2011-09-08 18:16, teemu.savolainen@nokia.com wrote: >> Brian, >>=20 >> Thank you for review. I agree it is a good idea to consult those WGs = (and >> DHC as well I suppose), but what makes you so concerned of this text: >>=20 >>>> In deployments where multiple namespaces are present, selection = of >>>> correct route and destination and source addresses for the actual = IP >>>> connection is crucial as well, as the resolved destination's IP >>>> addresses may be only usable on the network interface over which = the >>>> name was resolved on. >>=20 >> I wrote that as I thought it would be useful to talk a little about = bigger >> picture of some deployments (like in the demo we had few IETFs back - >> without presence of DHCPv6 more specific route options the system = would not >> have worked properly) .. but if that text creates an unwanted link or >> dependency or confusion, I think we can drop the text just as well = and focus >> on the document just to the new options and leave this kind of = additional >> system-level consideration out of the doc. >=20 > As Andrew pointed out, the draft starts >=20 > "...from the premise that operators sometimes include private > namespaces in the answers they provide from DNS servers, and that > those private namespaces are at least as useful to clients as the > answers from the public DNS." >=20 > I believe that you will discover during IETF LC that many people have > strong feelings about this premise; as Andrew implied, conceptually > the DNS is a unified global namespace. This draft is a backdoor > way of legitimising an ambiguous namespace. I don't think that will > have an easy time in IETF LC, especially if it is dropped as a = surprise > into the DNS community. It's your choice, but I would suggest that > exposing it to the DNS WGs now would be a smart move. Frankly, I consider this very nearly a showstopper, in the sense that = MIF needs an extremely good reason to do this, and I haven't seen even a = hint of such a reason. You may recall that I raised this issue in = Quebec, though perhaps I was too polite about it. (Since I hadn't read = the document yet, and was coming late into the discussion, I wanted to = give the group the benefit of the doubt.) I'm quite surprised that MIF was able to get this far with the document = without the issue being raised. I'm shocked that this issue appears = to be a surprise to the WG. I think that by itself is likely a sign of = a serious process or management failure. > It goes further. The IETF has a longstanding issue with technology > that encourages walled gardens. See for example RFC 3002. I think > there will be quite some discussion, and this will definitely > happen even if you try to remove the "system-level" considerations, > because they are strongly implied anyway. >=20 > Personally I'm not sure what I think about this, but it needs > to be discussed in the community IMHO. +1. Keith From ajs@anvilwalrusden.com Thu Sep 8 17:09: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 0EA3F21F8B3A for ; Thu, 8 Sep 2011 17:09:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.568 X-Spam-Level: X-Spam-Status: No, score=-2.568 tagged_above=-999 required=5 tests=[AWL=0.031, 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 J2VdG+AcHYo3 for ; Thu, 8 Sep 2011 17:09:47 -0700 (PDT) Received: from mail.yitter.info (mail.yitter.info [208.86.224.201]) by ietfa.amsl.com (Postfix) with ESMTP id 7424F21F8B18 for ; Thu, 8 Sep 2011 17:09:18 -0700 (PDT) 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 2A2391ECB422 for ; Fri, 9 Sep 2011 00:11:02 +0000 (UTC) Date: Thu, 8 Sep 2011 20:11:01 -0400 From: Andrew Sullivan To: mif@ietf.org Message-ID: <20110909001101.GS38973@shinkuro.com> References: <4E683F9B.7020905@gmail.com> <916CE6CF87173740BC8A2CE4430969620256F33F@008-AM1MPN1-032.mgdnok.nokia.com> <4E692D62.5080902@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] Last Call for MIF DNS server selection document 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, 09 Sep 2011 00:09:48 -0000 On Thu, Sep 08, 2011 at 06:22:17PM -0400, Keith Moore wrote: > > I'm quite surprised that MIF was able to get this far with the document without the issue being raised. Have I really been so polite that this qualifies as "not raised"? I apologise to everyone, then. But I've been uneasy about this since early in my work on the DNS64 drafts. I'm getting perhaps too adept at nose-holding. A -- Andrew Sullivan ajs@anvilwalrusden.com From brian.e.carpenter@gmail.com Thu Sep 8 18:30: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 5E8A521F8B46 for ; Thu, 8 Sep 2011 18:30:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.584 X-Spam-Level: X-Spam-Status: No, score=-103.584 tagged_above=-999 required=5 tests=[AWL=0.015, 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 ejAU9vX7YCSo for ; Thu, 8 Sep 2011 18:30:12 -0700 (PDT) Received: from mail-fx0-f44.google.com (mail-fx0-f44.google.com [209.85.161.44]) by ietfa.amsl.com (Postfix) with ESMTP id 9B71D21F8B3F for ; Thu, 8 Sep 2011 18:30:12 -0700 (PDT) Received: by fxe6 with SMTP id 6so2241562fxe.31 for ; Thu, 08 Sep 2011 18:32:04 -0700 (PDT) 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=DyYDABg8CXDqbcE6EM5CxzjIt0NGq8CVsVRsxdvnkqY=; b=qJnWwRALeuJiQKMp4Q78u2usDSLzQZhmiNFOFdfG75uYpZIWlJe6OD2eNjcLYUMfwH vYfOyf9CXFYVG6O3Z2nE3bUHYMaUi0TAGa+1arsUJZR6YcfOkPjqrmIN0Yqgy98wB+nD /UpO127h9xJNALJWawzj+kFEH6epKUxp6RJo0= Received: by 10.223.15.145 with SMTP id k17mr1275689faa.132.1315531924440; Thu, 08 Sep 2011 18:32:04 -0700 (PDT) Received: from [10.1.1.4] ([121.98.251.219]) by mx.google.com with ESMTPS id f1sm2175534fah.9.2011.09.08.18.32.01 (version=SSLv3 cipher=OTHER); Thu, 08 Sep 2011 18:32:03 -0700 (PDT) Message-ID: <4E696C8B.9010401@gmail.com> Date: Fri, 09 Sep 2011 13:31:55 +1200 From: Brian E Carpenter Organization: University of Auckland User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: Andrew Sullivan References: <4E683F9B.7020905@gmail.com> <916CE6CF87173740BC8A2CE4430969620256F33F@008-AM1MPN1-032.mgdnok.nokia.com> <4E692D62.5080902@gmail.com> <20110909001101.GS38973@shinkuro.com> In-Reply-To: <20110909001101.GS38973@shinkuro.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: mif@ietf.org Subject: Re: [mif] Last Call for MIF DNS server selection document 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, 09 Sep 2011 01:30:13 -0000 On 2011-09-09 12:11, Andrew Sullivan wrote: > On Thu, Sep 08, 2011 at 06:22:17PM -0400, Keith Moore wrote: >> I'm quite surprised that MIF was able to get this far with the document without the issue being raised. > > Have I really been so polite that this qualifies as "not raised"? I > apologise to everyone, then. But I've been uneasy about this since > early in my work on the DNS64 drafts. I'm getting perhaps too adept > at nose-holding. DNS64 doesn't damage the logical structure of the namespace itself. As soon as you admit that not all DNS servers serve the exact same namespace, and that a host may be able to see more than one DNS server, the total namespace cannot be guaranteed unique. There could be two totally unrelated entries for host.example.com. Introducing ambiguity in the DNS namespace, having already done so in the IPv4 address space, is a very serious step indeed. If you want a citation, see clause 4.2 in RFC 1958. This could be fixed by a BCP describing appropriate constraints on names that only resolve within a limited scope, I think, but it should not be just a by-product of the draft under review. Brian From teemu.savolainen@nokia.com Thu Sep 8 23:13: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 AC49521F8802 for ; Thu, 8 Sep 2011 23:13:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.631 X-Spam-Level: X-Spam-Status: No, score=-2.631 tagged_above=-999 required=5 tests=[AWL=-0.032, 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 dKRWKQvJMAER for ; Thu, 8 Sep 2011 23:13:31 -0700 (PDT) Received: from mgw-sa02.nokia.com (smtp.nokia.com [147.243.1.48]) by ietfa.amsl.com (Postfix) with ESMTP id 3E0D321F87D6 for ; Thu, 8 Sep 2011 23:13:30 -0700 (PDT) Received: from vaebh104.NOE.Nokia.com (vaebh104.europe.nokia.com [10.160.244.30]) by mgw-sa02.nokia.com (Switch-3.4.4/Switch-3.4.3) with ESMTP id p896FFq4031773; Fri, 9 Sep 2011 09:15:20 +0300 Received: from smtp.mgd.nokia.com ([65.54.30.7]) by vaebh104.NOE.Nokia.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.4675); Fri, 9 Sep 2011 09:15:14 +0300 Received: from 008-AM1MMR1-003.mgdnok.nokia.com (65.54.30.58) by NOK-AM1MHUB-03.mgdnok.nokia.com (65.54.30.7) with Microsoft SMTP Server (TLS) id 8.2.255.0; Fri, 9 Sep 2011 08:15:14 +0200 Received: from 008-AM1MPN1-032.mgdnok.nokia.com ([169.254.2.143]) by 008-AM1MMR1-003.mgdnok.nokia.com ([65.54.30.58]) with mapi id 14.01.0323.007; Fri, 9 Sep 2011 08:15:13 +0200 From: To: , Thread-Topic: [mif] Last Call for MIF DNS server selection document Thread-Index: AQHMbdzsBHSQ8Tn9hkac95+LwFpGipVC/6HggADYVwCAABZPgIAAoquA Date: Fri, 9 Sep 2011 06:15:13 +0000 Message-ID: <916CE6CF87173740BC8A2CE443096962025704BA@008-AM1MPN1-032.mgdnok.nokia.com> References: <4E683F9B.7020905@gmail.com> <916CE6CF87173740BC8A2CE4430969620256F33F@008-AM1MPN1-032.mgdnok.nokia.com> <4E692D62.5080902@gmail.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes 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+/nZJb9Kg7IijnarCFufw93yGp9Kqg4VsreROV3oSoCKo4MAZQAlH7cl7QEYi2t0p8hTrsrklpyqBfRuV1a3TP5t4zLsal1WzFsT0mQwFWR/yRh3UhJztIIhyLXE7aj3YtN85Eqji4hyMU9zDnsRybCxak6t2mfbgLZX2mjzSIIHnDkgCjyHZFFOhfBqPd/c5FcvKdb64f0sgP1bp0Rng5aZTrafF1qFNxmzB3fX0dr0qbeG9YfeKCcsiZk5WqSUtPkVYQ2fFAPg== x-originating-ip: [10.162.91.110] Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=SHA1; boundary="----=_NextPart_000_0178_01CC6ED0.F9868F60" MIME-Version: 1.0 X-OriginalArrivalTime: 09 Sep 2011 06:15:14.0749 (UTC) FILETIME=[D6BA0ED0:01CC6EB7] X-Nokia-AV: Clean Cc: mif@ietf.org, margaretw42@gmail.com, denghui02@hotmail.com Subject: Re: [mif] Last Call for MIF DNS server selection document 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, 09 Sep 2011 06:13:32 -0000 ------=_NextPart_000_0178_01CC6ED0.F9868F60 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Keith, Brian, The problem this draft is addressing has been acknowledged in the draft-ietf-mif-problem-statement-15.txt section 4.1. The problem statement is already at the RFC editor's queue. Based on the acceptance of the problem, this WG was chartered with a goal of: -- 1) DNS server selection solution: a specification for describing a way for a network to communicate to nodes information required to perform advanced DNS server selection at name resolution request granularity in scenarios involving multiple namespaces. The specification shall describe the information to be delivered for nodes and the protocol to be used for delivery. -- This draft is the solution that has been accepted as a WG work item. The topic has been discussed for a quite long time and I don't think there are any such surprises you refer to (except perhaps for individuals who just now start following the work). Furthermore, I cannot easily buy the argument (I hope I read your points right) that a solution should not be developed for an acknowledged problem out of fear of "legitimizing" the problematic behavior. I do agree BCP or similar might be nice to have, but would such BCP really make any difference e.g. if the network administrator just does not want names to be resolvable on the public Internet. Best regards, Teemu > -----Original Message----- > From: ext Keith Moore [mailto:moore@network-heretics.com] > Sent: 09. syyskuuta 2011 01:22 > To: Brian E Carpenter > Cc: Savolainen Teemu (Nokia-CTO/Tampere); margaretw42@gmail.com; > mif@ietf.org; denghui02@hotmail.com > Subject: Re: [mif] Last Call for MIF DNS server selection document > > > On Sep 8, 2011, at 5:02 PM, Brian E Carpenter wrote: > > > Teemu, > > > > On 2011-09-08 18:16, teemu.savolainen@nokia.com wrote: > >> Brian, > >> > >> Thank you for review. I agree it is a good idea to consult those WGs > >> (and DHC as well I suppose), but what makes you so concerned of this > text: > >> > >>>> In deployments where multiple namespaces are present, selection of > >>>> correct route and destination and source addresses for the actual IP > >>>> connection is crucial as well, as the resolved destination's IP > >>>> addresses may be only usable on the network interface over which the > >>>> name was resolved on. > >> > >> I wrote that as I thought it would be useful to talk a little about > >> bigger picture of some deployments (like in the demo we had few IETFs > >> back - without presence of DHCPv6 more specific route options the > >> system would not have worked properly) .. but if that text creates an > >> unwanted link or dependency or confusion, I think we can drop the > >> text just as well and focus on the document just to the new options > >> and leave this kind of additional system-level consideration out of the > doc. > > > > As Andrew pointed out, the draft starts > > > > "...from the premise that operators sometimes include private > > namespaces in the answers they provide from DNS servers, and that > > those private namespaces are at least as useful to clients as the > > answers from the public DNS." > > > > I believe that you will discover during IETF LC that many people have > > strong feelings about this premise; as Andrew implied, conceptually > > the DNS is a unified global namespace. This draft is a backdoor way of > > legitimising an ambiguous namespace. I don't think that will have an > > easy time in IETF LC, especially if it is dropped as a surprise into > > the DNS community. It's your choice, but I would suggest that exposing > > it to the DNS WGs now would be a smart move. > > > Frankly, I consider this very nearly a showstopper, in the sense that MIF > needs an extremely good reason to do this, and I haven't seen even a hint of > such a reason. You may recall that I raised this issue in Quebec, though > perhaps I was too polite about it. (Since I hadn't read the document yet, and > was coming late into the discussion, I wanted to give the group the benefit > of the doubt.) > > I'm quite surprised that MIF was able to get this far with the document > without the issue being raised. I'm shocked that this issue appears to be a > surprise to the WG. I think that by itself is likely a sign of a serious process or > management failure. > > > > It goes further. The IETF has a longstanding issue with technology > > that encourages walled gardens. See for example RFC 3002. I think > > there will be quite some discussion, and this will definitely happen > > even if you try to remove the "system-level" considerations, because > > they are strongly implied anyway. > > > > Personally I'm not sure what I think about this, but it needs to be > > discussed in the community IMHO. > > +1. > > Keith ------=_NextPart_000_0178_01CC6ED0.F9868F60 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIOuzCCAzYw ggIeoAMCAQICBDpVqdkwDQYJKoZIhvcNAQEFBQAwKTEOMAwGA1UEChMFTm9raWExFzAVBgNVBAMT Dk5va2lhICBSb290IENBMB4XDTAxMDEwNTExMDUwNVoXDTE2MDEwMjExMDUwNVowKTEOMAwGA1UE ChMFTm9raWExFzAVBgNVBAMTDk5va2lhICBSb290IENBMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8A MIIBCgKCAQEAsrTy8gLmr4LYvp0khVUVHw7ascdl+Cjr+yI5MlZ6J/U6Qsvkiqthgqq8rPcLV0P1 92TfBr27VgKEeCaZe0icS1jC2spM/wRv3j2WxdkKxb9kDJtuCNJaRBqvi5vGTHB15nmEmKuL5f3i rAxeHqPjgS496oWcudzFT1e7Xrc/gWGFYd72+/ykIFXjWOMZv6QpxD8x1hLPyh2YVXRk9U7N7pvm RQNX29g4SCFJY2BBIa5JPlwIF8Nc9IePaC/E/2M4tGMtiOOZlm99EoL7N0hJZtFSvUwdCBud/viH 4DgsKGjNkNKi6pAHc9IaXB6tIykcoYp+L+oe/3+cuEJaCj1EKwIDAQABo2YwZDASBgNVHRMBAf8E CDAGAQH/AgEEMB0GA1UdDgQWBBSNjfefoQ0AITLvqe0iruA79NB9sDAfBgNVHSMEGDAWgBSNjfef oQ0AITLvqe0iruA79NB9sDAOBgNVHQ8BAf8EBAMCAYYwDQYJKoZIhvcNAQEFBQADggEBAIGEPql2 TALyKi/h1J+Mh5XolAtYppcSOLMtBkoA7ZovGBDNvl0VbZs8AAojJqkUoWBB+L6DKyl/jKhNfKcu rWRGRyj7pnbxrKLsI3gmWNWkyo2b60wJwe9fqPD5ZQy3oEiMit9l0Ba6il/k2GqYopUCNMa7mfeb E2LeBy5ChYMiCi97UQSJvAdzEYylTJw8Awc6AiM2Ve5N+XxsmKgNf/2A/5IJ3EZZ+wFRmkI4062A oNU302rqAt0HH88jzoUF4AfYHWl6HpYhGXFbcX44rHINyPmFBRxLYIFJ6ZWUr/mXpL/e6rqFtNWO kV6UoJND7OVZkbLh7F1+lcqXRU8TPBMwggOHMIICb6ADAgECAgRBtbHpMA0GCSqGSIb3DQEBBQUA MCkxDjAMBgNVBAoTBU5va2lhMRcwFQYDVQQDEw5Ob2tpYSAgUm9vdCBDQTAeFw0wNjAzMzAwOTU3 MTFaFw0xNjAxMDIxMTA1MDVaMDMxCzAJBgNVBAYTAkZJMQ4wDAYDVQQKEwVOb2tpYTEUMBIGA1UE AxMLTm9raWEgQkkgQ0EwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQDtFCg3QEjSCg6T IUxoWsNwELh8bBNiUQPCPmg8c2DHQYXWWCSCMb+S0Fvh1qqI1xt+XnzyFq+5eqzGzDj4UaBcG+d9 qxrCFly8sHyoPTryyPrR0EI2UUDWwfS6ojhqgwghRqo8G38TjFusyBtLub/5L6yvWYSOHD+JcB+q VM2fbkArPYK4Ydv8WG/DbHjGn0gKq0zwpVZKI/gCK/QALYvte02NXseqvY9/GOyLtjy3Z8erFv71 KKTq+gxI/7DK55pJf3PoD+kT4kyGm6EF9DTdK4ojMdar17uyX0IOZz/4vkkF0d+60nmnLX63FJPA jUyB0HUNJ32NXDo9UsM38aoNAgMBAAGjgawwgakwDwYDVR0TAQH/BAUwAwEB/zARBgNVHSAECjAI MAYGBFUdIAAwDgYDVR0PAQH/BAQDAgGGMFQGA1UdIwRNMEuAFI2N95+hDQAhMu+p7SKu4Dv00H2w oS2kKzApMQ4wDAYDVQQKEwVOb2tpYTEXMBUGA1UEAxMOTm9raWEgIFJvb3QgQ0GCBDpVqdkwHQYD VR0OBBYEFKcksD7Fg+8EDlB2Sxgy58pW0Sy6MA0GCSqGSIb3DQEBBQUAA4IBAQAC3lEUplDlVNOT Pjz/XFezXx2bV2XbCFindhA3F815Egi55H6/cYezEjoP4QLNEGGl2I3aLvkn5A0T8I4pbiFPhIiu B/frbbGg6k6GjQLe/bFQ8F1mAOOR+GyneKZFPfzaRV0jiIR9QqnMXTf8RvKkCJyFj10MZVsLIy/Y uBkzeP3JhzDhUdtPfwmJN6ZbIhH5uR/2BwAGtgQknb8WX3I4wnhWtMUxB8XmayayYs8qWYeIiVkI FV+sLTkWUWVvvKUjyakBpbAW2vUP84DYsJ8TL1YefNjf/nIOByMcORLuV/1gPjyv00qJbcB59AA+ iXe3zIo8QNcgXG0uPQQFmrGDMIID5DCCAsygAwIBAgIQMH5apak8lEy6LmLlLsJy8TANBgkqhkiG 9w0BAQUFADAzMQswCQYDVQQGEwJGSTEOMAwGA1UEChMFTm9raWExFDASBgNVBAMTC05va2lhIEJJ IENBMB4XDTExMDkwNjA1NTIwNFoXDTE0MDkwNjA1NTIwNFowVjEOMAwGA1UECgwFTm9raWExDzAN BgNVBAsMBlBlb3BsZTEYMBYGCgmSJomT8ixkAQEMCDEwMDI0Njc2MRkwFwYDVQQDDBBTYXZvbGFp bmVuIFRlZW11MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAshEsmw6Yiz6XWX26oF+I s5fsfE1OfCjOelclmtqCiIgXND5klkNOBs2d4ZGzgD9mN+XnTZnOTh249c2WxPBugf12DCcDmBAJ gL+VuWUJVBTE5NRchm/O8nZnZsRFst+gAC9/Juykh4+EYewZ7QbpnlwW7hNpj8eH+rMr+OZHKzdp KTftgVjmuF4JJ/cPMQUjL8SuGj+zBW6IWPOZdqkEMtf7Pr8kkYbZsh0SgJ0ceRHZ7Uc06mB/y+C1 UnJPxehTTdu8tpCjdzXgBw/H2uuW1J3qdHbCfbuDILql8V8RiZKubcZLhdsD3Jvj8qK0DGWBJa6x p90q5p3pLE8LvAeCgQIDAQABo4HQMIHNMA4GA1UdDwEB/wQEAwIEMDAfBgNVHSMEGDAWgBSnJLA+ xYPvBA5QdksYMufKVtEsujAZBgNVHSAEEjAQMA4GDCsGAQQBXgExBgEHAzA5BgNVHR8EMjAwMC6g LKAqhihodHRwOi8vY3JsLm5va2lhLmNvbS9Ob2tpYSUyMEJJJTIwQ0EuY3JsMCUGA1UdEQQeMByB GnRlZW11LnNhdm9sYWluZW5Abm9raWEuY29tMB0GA1UdDgQWBBQTRzvZsgmQrAGCeuzdHTGAC6Jg UzANBgkqhkiG9w0BAQUFAAOCAQEACmPVsdi07pjK5gDa+W5JlE2C74kVVsB8alBqfioYeR5At2FG B7sua4Dz5H7TJMpZ1jYFeI+zjexD5f+beY2IlV15lMoWD+5e38QlLYjwfe2LAyvdzBKXW0e0U6Bt p78ft4gyVak1X+Db+ebR+FNHUOMNhm+yK3w9sy5ZQzBFusIx4OgxGvcZhyhmd9WjipSTalgPwgqV Ju2aPADCG++OEXmgEWRLsR4yNopkgK4ftVqrN5uUtLs83qdeXTRcNRiET1IOx5zmYFZ6q3gjKIx5 iyuxcDeYas93vVHUcaRRYpsoby5CHq7Z/j/TQhtqO/knWuxLFFiCUgdGKMKrRkg29DCCBAowggLy oAMCAQICEQCBvi+p+bA/dBtBtybwA6YYMA0GCSqGSIb3DQEBBQUAMDMxCzAJBgNVBAYTAkZJMQ4w DAYDVQQKEwVOb2tpYTEUMBIGA1UEAxMLTm9raWEgQkkgQ0EwHhcNMTEwOTA2MDU1MDM0WhcNMTMw OTA1MDU1MDM0WjBWMQ4wDAYDVQQKDAVOb2tpYTEPMA0GA1UECwwGUGVvcGxlMRgwFgYKCZImiZPy LGQBAQwIMTAwMjQ2NzYxGTAXBgNVBAMMEFNhdm9sYWluZW4gVGVlbXUwggEiMA0GCSqGSIb3DQEB AQUAA4IBDwAwggEKAoIBAQDFPmbRVwuo52v+h6xnQUqokAx2xsHjmPBniEkzgtgBNJsFi838ATEg 1zsx+VotoJg7hMijcrQfpTAgW6gpLGnlmw5QQswrNK1zleOHb4pA5JguU3WhVKFkAH/6/2EU2k/9 m8Pb/gwP55cYg80R6fRmbdsWKhseXF/1isW/rJcWLmIYDg/rXfo3ixqtT9MroAMiuoXnb0ij1L2d Jj64LDp3Ld8Jo0qZzk3Fj4apo8PBd8eAH6HloVBJkxQcwAnv561A+Xi1GHZ2mafRYJGO+1uBDwyd g/8ybEXXA4MKo8lPKjBebYBUFvz80DBA/Lq74UysXkG23BSulcG4xQSYGlyzAgMBAAGjgfUwgfIw HwYDVR0jBBgwFoAUpySwPsWD7wQOUHZLGDLnylbRLLowGQYDVR0gBBIwEDAOBgwrBgEEAV4BMQYB BgQwOQYDVR0fBDIwMDAuoCygKoYoaHR0cDovL2NybC5ub2tpYS5jb20vTm9raWElMjBCSSUyMENB LmNybDAjBgNVHSUEHDAaBggrBgEFBQcDAgYEVR0lAAYIKwYBBQUHAwQwDgYDVR0PAQH/BAQDAgeA MCUGA1UdEQQeMByBGnRlZW11LnNhdm9sYWluZW5Abm9raWEuY29tMB0GA1UdDgQWBBTGhbTJF0EX iagjymQo6GIuSQeRVDANBgkqhkiG9w0BAQUFAAOCAQEAqai6TxZ/BlMHZIhJNPriBPXkQhUlBkGA buJZ5sVm1HIQhWN8elZKjjJdHi1qWEKhMg7yHjEMZsyV8XAZzK0UnOqkpUnt+jnVkNZ9O7/jRtyK f4WUtq5jErc8Hlv4bbGFRHk1T7AuLLE52r1lYOdmoibnQp03QtlDvHUNa68G7jvzThJhieB7U1xh vH3yy0ktaVnWEgAylqf9yIUFjnqau5R6cE1Xo57IYPk/KitX0YF+OigEI/bOQVMi+fze93ZsAOJv /z6g/NGemvUgl5YSdX0uPQK6kEHf/sp/nZyUWWQ7OjtVSqkq2YuYEueQFxTfafl+78GWqgm6W/Bl 32laYzGCAuswggLnAgEBMEgwMzELMAkGA1UEBhMCRkkxDjAMBgNVBAoTBU5va2lhMRQwEgYDVQQD EwtOb2tpYSBCSSBDQQIRAIG+L6n5sD90G0G3JvADphgwCQYFKw4DAhoFAKCCAXgwGAYJKoZIhvcN AQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG9w0BCQUxDxcNMTEwOTA5MDYxNTEwWjAjBgkqhkiG9w0B CQQxFgQUaoT4P2O0eiXTWLfDVor2/+CdvLgwVgYJKwYBBAGCNxAEMUkwRzAzMQswCQYDVQQGEwJG STEOMAwGA1UEChMFTm9raWExFDASBgNVBAMTC05va2lhIEJJIENBAhAwflqlqTyUTLouYuUuwnLx MFgGCyqGSIb3DQEJEAILMUmgRzAzMQswCQYDVQQGEwJGSTEOMAwGA1UEChMFTm9raWExFDASBgNV BAMTC05va2lhIEJJIENBAhAwflqlqTyUTLouYuUuwnLxMGcGCSqGSIb3DQEJDzFaMFgwCgYIKoZI hvcNAwcwDgYIKoZIhvcNAwICAgCAMA0GCCqGSIb3DQMCAgFAMAcGBSsOAwIHMA0GCCqGSIb3DQMC AgEoMAcGBSsOAwIaMAoGCCqGSIb3DQIFMA0GCSqGSIb3DQEBAQUABIIBAJ+9NqZN7HEmIbRnivUk VDLfdPUE8PgJYxOIlDz3bRzObrWuXDCVL3KMD0vs8VmmY6pzVK+jtc1S8ZA84bsUvhyV3cedCQYz MeTbwu5FudyST+TaaoThXsn7xfjdUCJBKL1htAixeQmg+NZTU8ybaYpXhupFM0XIGk8RC7pPG1kO IoIG5f43FUlLKYtsLQmlMqFGrfW3ribciKi4kr6iGz8mmL4ztVfRvAYnlAlTS7gi93Mkz8nWUFq8 qzu9nAZbCzp72COjTvln+feevlDIKcH45kkP1TreB3M4NttGP0JFSE6WCoRIYw5meUkz5vsTJwB6 LI8PxJunlXB4zjpwuXIAAAAAAAA= ------=_NextPart_000_0178_01CC6ED0.F9868F60-- From teemu.savolainen@nokia.com Thu Sep 8 23:14:58 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 C7C4F21F87D6 for ; Thu, 8 Sep 2011 23:14:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.828 X-Spam-Level: X-Spam-Status: No, score=-2.828 tagged_above=-999 required=5 tests=[AWL=0.171, 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 5ETM+-quMxMR for ; Thu, 8 Sep 2011 23:14:58 -0700 (PDT) Received: from mgw-da01.nokia.com (smtp.nokia.com [147.243.128.24]) by ietfa.amsl.com (Postfix) with ESMTP id 00F2421F85C0 for ; Thu, 8 Sep 2011 23:14:57 -0700 (PDT) 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.3) with ESMTP id p896GQ37002690; Fri, 9 Sep 2011 09:16:49 +0300 Received: from smtp.mgd.nokia.com ([65.54.30.7]) by vaebh104.NOE.Nokia.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.4675); Fri, 9 Sep 2011 09:16:47 +0300 Received: from 008-AM1MMR1-003.mgdnok.nokia.com (65.54.30.58) by NOK-AM1MHUB-03.mgdnok.nokia.com (65.54.30.7) with Microsoft SMTP Server (TLS) id 8.2.255.0; Fri, 9 Sep 2011 08:16:46 +0200 Received: from 008-AM1MPN1-032.mgdnok.nokia.com ([169.254.2.143]) by 008-AM1MMR1-003.mgdnok.nokia.com ([65.54.30.58]) with mapi id 14.01.0323.007; Fri, 9 Sep 2011 08:16:35 +0200 From: To: Thread-Topic: [mif] Last Call for MIF DNS server selection document Thread-Index: AQHMbdzsBHSQ8Tn9hkac95+LwFpGipVC/6HggADYVwCAALXRUA== Date: Fri, 9 Sep 2011 06:16:35 +0000 Message-ID: <916CE6CF87173740BC8A2CE443096962025704E6@008-AM1MPN1-032.mgdnok.nokia.com> References: <4E683F9B.7020905@gmail.com> <916CE6CF87173740BC8A2CE4430969620256F33F@008-AM1MPN1-032.mgdnok.nokia.com> <4E692D62.5080902@gmail.com> In-Reply-To: <4E692D62.5080902@gmail.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes 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+/nZJb9Kg7IijnarCFufw93yGp9Kqg4VsreROV3oSoCKo4MAZQAlH7cl7QEYi2t0p8hTrsrklpyqBfRuV1a3TP5t4zLsal1WzFsT0mQwFWR/yRh3UhJztIIhyLXE7aj3YtN85Eqji4hyMU9zDnsRybCxak6t2mfbgLZX2mjzSIIHnDkgCjyHZFFOhfBqPd/c5FcvKdb64f0sgP1bp0Rng5aZTrafF1qFNxmzB3fX0dr0qbeG9YfeKCcsiZk5WqSUtPkVYQ2fFAPg== x-originating-ip: [10.162.91.110] Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=SHA1; boundary="----=_NextPart_000_017D_01CC6ED1.2B484AC0" MIME-Version: 1.0 X-OriginalArrivalTime: 09 Sep 2011 06:16:47.0060 (UTC) FILETIME=[0DBF9940:01CC6EB8] X-Nokia-AV: Clean Cc: margaretw42@gmail.com, mif@ietf.org, denghui02@hotmail.com Subject: Re: [mif] Last Call for MIF DNS server selection document 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, 09 Sep 2011 06:14:58 -0000 ------=_NextPart_000_017D_01CC6ED1.2B484AC0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit Brian, The predecessors of this draft have been presented for the first time almost three years ago in 6man WG at IETF#73, but also in dnsop WG at IETF#78, and of course many times in mif WG (IETF#75,#77,#78,#79,#80,#81) and we also have had public demonstration of interoperability of two implementations at the IETF#79. That demo was announced at least in v6ops WG mailing list. Hence I would say we've been (at least trying to) drawing attention from community and soliciting feedback for WGLC from other WGs at this point is also just fine. I'm just not sure if we should first update the draft according to Andrew's comments, and only after that solicit feedback from beforementioned WGs. Best regards, Teemu > -----Original Message----- > From: ext Brian E Carpenter [mailto:brian.e.carpenter@gmail.com] > Sent: 09. syyskuuta 2011 00:02 > To: Savolainen Teemu (Nokia-CTO/Tampere) > Cc: denghui02@hotmail.com; margaretw42@gmail.com; mif@ietf.org > Subject: Re: [mif] Last Call for MIF DNS server selection document > > Teemu, > > On 2011-09-08 18:16, teemu.savolainen@nokia.com wrote: > > Brian, > > > > Thank you for review. I agree it is a good idea to consult those WGs > > (and DHC as well I suppose), but what makes you so concerned of this text: > > > >>> In deployments where multiple namespaces are present, selection of > >>> correct route and destination and source addresses for the actual IP > >>> connection is crucial as well, as the resolved destination's IP > >>> addresses may be only usable on the network interface over which the > >>> name was resolved on. > > > > I wrote that as I thought it would be useful to talk a little about > > bigger picture of some deployments (like in the demo we had few IETFs > > back - without presence of DHCPv6 more specific route options the > > system would not have worked properly) .. but if that text creates an > > unwanted link or dependency or confusion, I think we can drop the text > > just as well and focus on the document just to the new options and > > leave this kind of additional system-level consideration out of the doc. > > As Andrew pointed out, the draft starts > > "...from the premise that operators sometimes include private > namespaces in the answers they provide from DNS servers, and that > those private namespaces are at least as useful to clients as the > answers from the public DNS." > > I believe that you will discover during IETF LC that many people have strong > feelings about this premise; as Andrew implied, conceptually the DNS is a > unified global namespace. This draft is a backdoor way of legitimising an > ambiguous namespace. I don't think that will have an easy time in IETF LC, > especially if it is dropped as a surprise into the DNS community. It's your > choice, but I would suggest that exposing it to the DNS WGs now would be a > smart move. > > It goes further. The IETF has a longstanding issue with technology that > encourages walled gardens. See for example RFC 3002. I think there will be > quite some discussion, and this will definitely happen even if you try to > remove the "system-level" considerations, because they are strongly implied > anyway. > > Personally I'm not sure what I think about this, but it needs to be > discussed in > the community IMHO. > > Brian ------=_NextPart_000_017D_01CC6ED1.2B484AC0 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIOuzCCAzYw ggIeoAMCAQICBDpVqdkwDQYJKoZIhvcNAQEFBQAwKTEOMAwGA1UEChMFTm9raWExFzAVBgNVBAMT Dk5va2lhICBSb290IENBMB4XDTAxMDEwNTExMDUwNVoXDTE2MDEwMjExMDUwNVowKTEOMAwGA1UE ChMFTm9raWExFzAVBgNVBAMTDk5va2lhICBSb290IENBMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8A MIIBCgKCAQEAsrTy8gLmr4LYvp0khVUVHw7ascdl+Cjr+yI5MlZ6J/U6Qsvkiqthgqq8rPcLV0P1 92TfBr27VgKEeCaZe0icS1jC2spM/wRv3j2WxdkKxb9kDJtuCNJaRBqvi5vGTHB15nmEmKuL5f3i rAxeHqPjgS496oWcudzFT1e7Xrc/gWGFYd72+/ykIFXjWOMZv6QpxD8x1hLPyh2YVXRk9U7N7pvm RQNX29g4SCFJY2BBIa5JPlwIF8Nc9IePaC/E/2M4tGMtiOOZlm99EoL7N0hJZtFSvUwdCBud/viH 4DgsKGjNkNKi6pAHc9IaXB6tIykcoYp+L+oe/3+cuEJaCj1EKwIDAQABo2YwZDASBgNVHRMBAf8E CDAGAQH/AgEEMB0GA1UdDgQWBBSNjfefoQ0AITLvqe0iruA79NB9sDAfBgNVHSMEGDAWgBSNjfef oQ0AITLvqe0iruA79NB9sDAOBgNVHQ8BAf8EBAMCAYYwDQYJKoZIhvcNAQEFBQADggEBAIGEPql2 TALyKi/h1J+Mh5XolAtYppcSOLMtBkoA7ZovGBDNvl0VbZs8AAojJqkUoWBB+L6DKyl/jKhNfKcu rWRGRyj7pnbxrKLsI3gmWNWkyo2b60wJwe9fqPD5ZQy3oEiMit9l0Ba6il/k2GqYopUCNMa7mfeb E2LeBy5ChYMiCi97UQSJvAdzEYylTJw8Awc6AiM2Ve5N+XxsmKgNf/2A/5IJ3EZZ+wFRmkI4062A oNU302rqAt0HH88jzoUF4AfYHWl6HpYhGXFbcX44rHINyPmFBRxLYIFJ6ZWUr/mXpL/e6rqFtNWO kV6UoJND7OVZkbLh7F1+lcqXRU8TPBMwggOHMIICb6ADAgECAgRBtbHpMA0GCSqGSIb3DQEBBQUA MCkxDjAMBgNVBAoTBU5va2lhMRcwFQYDVQQDEw5Ob2tpYSAgUm9vdCBDQTAeFw0wNjAzMzAwOTU3 MTFaFw0xNjAxMDIxMTA1MDVaMDMxCzAJBgNVBAYTAkZJMQ4wDAYDVQQKEwVOb2tpYTEUMBIGA1UE AxMLTm9raWEgQkkgQ0EwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQDtFCg3QEjSCg6T IUxoWsNwELh8bBNiUQPCPmg8c2DHQYXWWCSCMb+S0Fvh1qqI1xt+XnzyFq+5eqzGzDj4UaBcG+d9 qxrCFly8sHyoPTryyPrR0EI2UUDWwfS6ojhqgwghRqo8G38TjFusyBtLub/5L6yvWYSOHD+JcB+q VM2fbkArPYK4Ydv8WG/DbHjGn0gKq0zwpVZKI/gCK/QALYvte02NXseqvY9/GOyLtjy3Z8erFv71 KKTq+gxI/7DK55pJf3PoD+kT4kyGm6EF9DTdK4ojMdar17uyX0IOZz/4vkkF0d+60nmnLX63FJPA jUyB0HUNJ32NXDo9UsM38aoNAgMBAAGjgawwgakwDwYDVR0TAQH/BAUwAwEB/zARBgNVHSAECjAI MAYGBFUdIAAwDgYDVR0PAQH/BAQDAgGGMFQGA1UdIwRNMEuAFI2N95+hDQAhMu+p7SKu4Dv00H2w oS2kKzApMQ4wDAYDVQQKEwVOb2tpYTEXMBUGA1UEAxMOTm9raWEgIFJvb3QgQ0GCBDpVqdkwHQYD VR0OBBYEFKcksD7Fg+8EDlB2Sxgy58pW0Sy6MA0GCSqGSIb3DQEBBQUAA4IBAQAC3lEUplDlVNOT Pjz/XFezXx2bV2XbCFindhA3F815Egi55H6/cYezEjoP4QLNEGGl2I3aLvkn5A0T8I4pbiFPhIiu B/frbbGg6k6GjQLe/bFQ8F1mAOOR+GyneKZFPfzaRV0jiIR9QqnMXTf8RvKkCJyFj10MZVsLIy/Y uBkzeP3JhzDhUdtPfwmJN6ZbIhH5uR/2BwAGtgQknb8WX3I4wnhWtMUxB8XmayayYs8qWYeIiVkI FV+sLTkWUWVvvKUjyakBpbAW2vUP84DYsJ8TL1YefNjf/nIOByMcORLuV/1gPjyv00qJbcB59AA+ iXe3zIo8QNcgXG0uPQQFmrGDMIID5DCCAsygAwIBAgIQMH5apak8lEy6LmLlLsJy8TANBgkqhkiG 9w0BAQUFADAzMQswCQYDVQQGEwJGSTEOMAwGA1UEChMFTm9raWExFDASBgNVBAMTC05va2lhIEJJ IENBMB4XDTExMDkwNjA1NTIwNFoXDTE0MDkwNjA1NTIwNFowVjEOMAwGA1UECgwFTm9raWExDzAN BgNVBAsMBlBlb3BsZTEYMBYGCgmSJomT8ixkAQEMCDEwMDI0Njc2MRkwFwYDVQQDDBBTYXZvbGFp bmVuIFRlZW11MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAshEsmw6Yiz6XWX26oF+I s5fsfE1OfCjOelclmtqCiIgXND5klkNOBs2d4ZGzgD9mN+XnTZnOTh249c2WxPBugf12DCcDmBAJ gL+VuWUJVBTE5NRchm/O8nZnZsRFst+gAC9/Juykh4+EYewZ7QbpnlwW7hNpj8eH+rMr+OZHKzdp KTftgVjmuF4JJ/cPMQUjL8SuGj+zBW6IWPOZdqkEMtf7Pr8kkYbZsh0SgJ0ceRHZ7Uc06mB/y+C1 UnJPxehTTdu8tpCjdzXgBw/H2uuW1J3qdHbCfbuDILql8V8RiZKubcZLhdsD3Jvj8qK0DGWBJa6x p90q5p3pLE8LvAeCgQIDAQABo4HQMIHNMA4GA1UdDwEB/wQEAwIEMDAfBgNVHSMEGDAWgBSnJLA+ xYPvBA5QdksYMufKVtEsujAZBgNVHSAEEjAQMA4GDCsGAQQBXgExBgEHAzA5BgNVHR8EMjAwMC6g LKAqhihodHRwOi8vY3JsLm5va2lhLmNvbS9Ob2tpYSUyMEJJJTIwQ0EuY3JsMCUGA1UdEQQeMByB GnRlZW11LnNhdm9sYWluZW5Abm9raWEuY29tMB0GA1UdDgQWBBQTRzvZsgmQrAGCeuzdHTGAC6Jg UzANBgkqhkiG9w0BAQUFAAOCAQEACmPVsdi07pjK5gDa+W5JlE2C74kVVsB8alBqfioYeR5At2FG B7sua4Dz5H7TJMpZ1jYFeI+zjexD5f+beY2IlV15lMoWD+5e38QlLYjwfe2LAyvdzBKXW0e0U6Bt p78ft4gyVak1X+Db+ebR+FNHUOMNhm+yK3w9sy5ZQzBFusIx4OgxGvcZhyhmd9WjipSTalgPwgqV Ju2aPADCG++OEXmgEWRLsR4yNopkgK4ftVqrN5uUtLs83qdeXTRcNRiET1IOx5zmYFZ6q3gjKIx5 iyuxcDeYas93vVHUcaRRYpsoby5CHq7Z/j/TQhtqO/knWuxLFFiCUgdGKMKrRkg29DCCBAowggLy oAMCAQICEQCBvi+p+bA/dBtBtybwA6YYMA0GCSqGSIb3DQEBBQUAMDMxCzAJBgNVBAYTAkZJMQ4w DAYDVQQKEwVOb2tpYTEUMBIGA1UEAxMLTm9raWEgQkkgQ0EwHhcNMTEwOTA2MDU1MDM0WhcNMTMw OTA1MDU1MDM0WjBWMQ4wDAYDVQQKDAVOb2tpYTEPMA0GA1UECwwGUGVvcGxlMRgwFgYKCZImiZPy LGQBAQwIMTAwMjQ2NzYxGTAXBgNVBAMMEFNhdm9sYWluZW4gVGVlbXUwggEiMA0GCSqGSIb3DQEB AQUAA4IBDwAwggEKAoIBAQDFPmbRVwuo52v+h6xnQUqokAx2xsHjmPBniEkzgtgBNJsFi838ATEg 1zsx+VotoJg7hMijcrQfpTAgW6gpLGnlmw5QQswrNK1zleOHb4pA5JguU3WhVKFkAH/6/2EU2k/9 m8Pb/gwP55cYg80R6fRmbdsWKhseXF/1isW/rJcWLmIYDg/rXfo3ixqtT9MroAMiuoXnb0ij1L2d Jj64LDp3Ld8Jo0qZzk3Fj4apo8PBd8eAH6HloVBJkxQcwAnv561A+Xi1GHZ2mafRYJGO+1uBDwyd g/8ybEXXA4MKo8lPKjBebYBUFvz80DBA/Lq74UysXkG23BSulcG4xQSYGlyzAgMBAAGjgfUwgfIw HwYDVR0jBBgwFoAUpySwPsWD7wQOUHZLGDLnylbRLLowGQYDVR0gBBIwEDAOBgwrBgEEAV4BMQYB BgQwOQYDVR0fBDIwMDAuoCygKoYoaHR0cDovL2NybC5ub2tpYS5jb20vTm9raWElMjBCSSUyMENB LmNybDAjBgNVHSUEHDAaBggrBgEFBQcDAgYEVR0lAAYIKwYBBQUHAwQwDgYDVR0PAQH/BAQDAgeA MCUGA1UdEQQeMByBGnRlZW11LnNhdm9sYWluZW5Abm9raWEuY29tMB0GA1UdDgQWBBTGhbTJF0EX iagjymQo6GIuSQeRVDANBgkqhkiG9w0BAQUFAAOCAQEAqai6TxZ/BlMHZIhJNPriBPXkQhUlBkGA buJZ5sVm1HIQhWN8elZKjjJdHi1qWEKhMg7yHjEMZsyV8XAZzK0UnOqkpUnt+jnVkNZ9O7/jRtyK f4WUtq5jErc8Hlv4bbGFRHk1T7AuLLE52r1lYOdmoibnQp03QtlDvHUNa68G7jvzThJhieB7U1xh vH3yy0ktaVnWEgAylqf9yIUFjnqau5R6cE1Xo57IYPk/KitX0YF+OigEI/bOQVMi+fze93ZsAOJv /z6g/NGemvUgl5YSdX0uPQK6kEHf/sp/nZyUWWQ7OjtVSqkq2YuYEueQFxTfafl+78GWqgm6W/Bl 32laYzGCAuswggLnAgEBMEgwMzELMAkGA1UEBhMCRkkxDjAMBgNVBAoTBU5va2lhMRQwEgYDVQQD EwtOb2tpYSBCSSBDQQIRAIG+L6n5sD90G0G3JvADphgwCQYFKw4DAhoFAKCCAXgwGAYJKoZIhvcN AQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG9w0BCQUxDxcNMTEwOTA5MDYxNjM0WjAjBgkqhkiG9w0B CQQxFgQUgdFZHgaLFVrDkOdpw0Jk+asfYjowVgYJKwYBBAGCNxAEMUkwRzAzMQswCQYDVQQGEwJG STEOMAwGA1UEChMFTm9raWExFDASBgNVBAMTC05va2lhIEJJIENBAhAwflqlqTyUTLouYuUuwnLx MFgGCyqGSIb3DQEJEAILMUmgRzAzMQswCQYDVQQGEwJGSTEOMAwGA1UEChMFTm9raWExFDASBgNV BAMTC05va2lhIEJJIENBAhAwflqlqTyUTLouYuUuwnLxMGcGCSqGSIb3DQEJDzFaMFgwCgYIKoZI hvcNAwcwDgYIKoZIhvcNAwICAgCAMA0GCCqGSIb3DQMCAgFAMAcGBSsOAwIHMA0GCCqGSIb3DQMC AgEoMAcGBSsOAwIaMAoGCCqGSIb3DQIFMA0GCSqGSIb3DQEBAQUABIIBAABiNg2ecfjPuPr0+fJM biy6IrhNm3ij84HTz2rmi7MtnVT29ClsnpoQ0qO7B+QKSYeVnnFuz1sdHWXekNUjadWBPAgKBnNb dHPHb6dksZom5J83GTXKpOUzGeeZCJYCkfsLJHXavWwucgkbYlpMJLVQ+DY2aFTbrvIPx6atSRDm +vMvc3NAoxEONzpPCtysZhUuJUQ70mV6cGhBMaa0/ho2pO2MCLt4cIg0wW2PJTa7xxaLYZucoqDH 4zILRFN/qtAyjZTlsyJZX+B0ucMor1CI+/9m+sZRKz8KjBymbeBsqILlqoryxQ4lRBrArlQPWn3B MM/RnSm+FfSm5nLUkxMAAAAAAAA= ------=_NextPart_000_017D_01CC6ED1.2B484AC0-- From teemu.savolainen@nokia.com Thu Sep 8 23:33: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 E654921F8AFD for ; Thu, 8 Sep 2011 23:33:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.143 X-Spam-Level: X-Spam-Status: No, score=-3.143 tagged_above=-999 required=5 tests=[AWL=0.457, 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 67GhHVbZccUZ for ; Thu, 8 Sep 2011 23:33:34 -0700 (PDT) Received: from mgw-da01.nokia.com (smtp.nokia.com [147.243.128.24]) by ietfa.amsl.com (Postfix) with ESMTP id 2C23C21F8A97 for ; Thu, 8 Sep 2011 23:33:34 -0700 (PDT) Received: from vaebh106.NOE.Nokia.com (vaebh106.europe.nokia.com [10.160.244.32]) by mgw-da01.nokia.com (Switch-3.4.4/Switch-3.4.3) with ESMTP id p896Yjlj024756; Fri, 9 Sep 2011 09:35:23 +0300 Received: from smtp.mgd.nokia.com ([65.54.30.7]) by vaebh106.NOE.Nokia.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.4675); Fri, 9 Sep 2011 09:34:58 +0300 Received: from 008-AM1MMR1-001.mgdnok.nokia.com (65.54.30.56) by NOK-AM1MHUB-03.mgdnok.nokia.com (65.54.30.7) with Microsoft SMTP Server (TLS) id 8.2.255.0; Fri, 9 Sep 2011 08:34:57 +0200 Received: from 008-AM1MPN1-032.mgdnok.nokia.com ([169.254.2.143]) by 008-AM1MMR1-001.mgdnok.nokia.com ([65.54.30.56]) with mapi id 14.01.0323.007; Fri, 9 Sep 2011 08:34:57 +0200 From: To: , Thread-Topic: [mif] Last Call for MIF DNS server selection document Thread-Index: AQHMbdzsBHSQ8Tn9hkac95+LwFpGipVC/6HggADYVwCAABZPgIAAHmGAgAAWm4CAAHEzQA== Date: Fri, 9 Sep 2011 06:34:56 +0000 Message-ID: <916CE6CF87173740BC8A2CE4430969620257052B@008-AM1MPN1-032.mgdnok.nokia.com> References: <4E683F9B.7020905@gmail.com> <916CE6CF87173740BC8A2CE4430969620256F33F@008-AM1MPN1-032.mgdnok.nokia.com> <4E692D62.5080902@gmail.com> <20110909001101.GS38973@shinkuro.com> <4E696C8B.9010401@gmail.com> In-Reply-To: <4E696C8B.9010401@gmail.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes 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+/nZJb9Kg7IijnarCFufw93yGp9Kqg4VsreROV3oSoCKo4MAZQAlH7cl7QEYi2t0p8hTrsrklpyqBfRuV1a3TP5t4zLsal1WzFsT0mQwFWR/yRh3UhJztIIhyLXE7aj3YtN85Eqji4hyMU9zDnsRybCxak6t2mfbgLZX2mjzSIIHnDkgCjyHZFFOhfBqPd/c5FcvKdb64f0sgP1bp0Rng5aZTrafF1qFNxmzB3fX0dr0qbeG9YfeKCcsiZk5WqSUtPkVYQ2fFAPg== x-originating-ip: [10.162.91.110] Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=SHA1; boundary="----=_NextPart_000_0181_01CC6ED3.BB8B38C0" MIME-Version: 1.0 X-OriginalArrivalTime: 09 Sep 2011 06:34:58.0215 (UTC) FILETIME=[9820A370:01CC6EBA] X-Nokia-AV: Clean Cc: mif@ietf.org Subject: Re: [mif] Last Call for MIF DNS server selection document 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, 09 Sep 2011 06:33:35 -0000 ------=_NextPart_000_0181_01CC6ED3.BB8B38C0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit About DNS64. I agree DNS64 does not damage the logical structure of the namespace itself. The main DNS64 related issue there is, I think, is just that the synthetic responses should not be retained in possible host local cache over movement from one network interface to another (oh well, WKP using synthetic addresses can work in different points of network attachment, if there just is WKP using NAT64 present:-). In the case of multiple parallel interfaces the NSP-using synthetic addresses of course are usable only on the interface learned on, but I believe the routing should take care of that with longest matching prefix rules and so. But once a point of attachment changes, records using NSP of course should be cleared (and also WKP using prefixes as those cannot be guaranteed to work on new IPv6-enabled point of attachment, and may actually be source of delays (ref happy eyeballs and non-working IPv6 paths)). Best regards, Teemu > -----Original Message----- > From: mif-bounces@ietf.org [mailto:mif-bounces@ietf.org] On Behalf Of > ext Brian E Carpenter > Sent: 09. syyskuuta 2011 04:32 > To: Andrew Sullivan > Cc: mif@ietf.org > Subject: Re: [mif] Last Call for MIF DNS server selection document > > On 2011-09-09 12:11, Andrew Sullivan wrote: > > On Thu, Sep 08, 2011 at 06:22:17PM -0400, Keith Moore wrote: > >> I'm quite surprised that MIF was able to get this far with the document > without the issue being raised. > > > > Have I really been so polite that this qualifies as "not raised"? I > > apologise to everyone, then. But I've been uneasy about this since > > early in my work on the DNS64 drafts. I'm getting perhaps too adept > > at nose-holding. > > DNS64 doesn't damage the logical structure of the namespace itself. > As soon as you admit that not all DNS servers serve the exact same > namespace, and that a host may be able to see more than one DNS server, > the total namespace cannot be guaranteed unique. > There could be two totally unrelated entries for host.example.com. > Introducing ambiguity in the DNS namespace, having already done so in the > IPv4 address space, is a very serious step indeed. > > If you want a citation, see clause 4.2 in RFC 1958. > > This could be fixed by a BCP describing appropriate constraints on names > that only resolve within a limited scope, I think, but it should not be just a by- > product of the draft under review. > > Brian > _______________________________________________ > mif mailing list > mif@ietf.org > https://www.ietf.org/mailman/listinfo/mif ------=_NextPart_000_0181_01CC6ED3.BB8B38C0 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIOuzCCAzYw ggIeoAMCAQICBDpVqdkwDQYJKoZIhvcNAQEFBQAwKTEOMAwGA1UEChMFTm9raWExFzAVBgNVBAMT Dk5va2lhICBSb290IENBMB4XDTAxMDEwNTExMDUwNVoXDTE2MDEwMjExMDUwNVowKTEOMAwGA1UE ChMFTm9raWExFzAVBgNVBAMTDk5va2lhICBSb290IENBMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8A MIIBCgKCAQEAsrTy8gLmr4LYvp0khVUVHw7ascdl+Cjr+yI5MlZ6J/U6Qsvkiqthgqq8rPcLV0P1 92TfBr27VgKEeCaZe0icS1jC2spM/wRv3j2WxdkKxb9kDJtuCNJaRBqvi5vGTHB15nmEmKuL5f3i rAxeHqPjgS496oWcudzFT1e7Xrc/gWGFYd72+/ykIFXjWOMZv6QpxD8x1hLPyh2YVXRk9U7N7pvm RQNX29g4SCFJY2BBIa5JPlwIF8Nc9IePaC/E/2M4tGMtiOOZlm99EoL7N0hJZtFSvUwdCBud/viH 4DgsKGjNkNKi6pAHc9IaXB6tIykcoYp+L+oe/3+cuEJaCj1EKwIDAQABo2YwZDASBgNVHRMBAf8E CDAGAQH/AgEEMB0GA1UdDgQWBBSNjfefoQ0AITLvqe0iruA79NB9sDAfBgNVHSMEGDAWgBSNjfef oQ0AITLvqe0iruA79NB9sDAOBgNVHQ8BAf8EBAMCAYYwDQYJKoZIhvcNAQEFBQADggEBAIGEPql2 TALyKi/h1J+Mh5XolAtYppcSOLMtBkoA7ZovGBDNvl0VbZs8AAojJqkUoWBB+L6DKyl/jKhNfKcu rWRGRyj7pnbxrKLsI3gmWNWkyo2b60wJwe9fqPD5ZQy3oEiMit9l0Ba6il/k2GqYopUCNMa7mfeb E2LeBy5ChYMiCi97UQSJvAdzEYylTJw8Awc6AiM2Ve5N+XxsmKgNf/2A/5IJ3EZZ+wFRmkI4062A oNU302rqAt0HH88jzoUF4AfYHWl6HpYhGXFbcX44rHINyPmFBRxLYIFJ6ZWUr/mXpL/e6rqFtNWO kV6UoJND7OVZkbLh7F1+lcqXRU8TPBMwggOHMIICb6ADAgECAgRBtbHpMA0GCSqGSIb3DQEBBQUA MCkxDjAMBgNVBAoTBU5va2lhMRcwFQYDVQQDEw5Ob2tpYSAgUm9vdCBDQTAeFw0wNjAzMzAwOTU3 MTFaFw0xNjAxMDIxMTA1MDVaMDMxCzAJBgNVBAYTAkZJMQ4wDAYDVQQKEwVOb2tpYTEUMBIGA1UE AxMLTm9raWEgQkkgQ0EwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQDtFCg3QEjSCg6T IUxoWsNwELh8bBNiUQPCPmg8c2DHQYXWWCSCMb+S0Fvh1qqI1xt+XnzyFq+5eqzGzDj4UaBcG+d9 qxrCFly8sHyoPTryyPrR0EI2UUDWwfS6ojhqgwghRqo8G38TjFusyBtLub/5L6yvWYSOHD+JcB+q VM2fbkArPYK4Ydv8WG/DbHjGn0gKq0zwpVZKI/gCK/QALYvte02NXseqvY9/GOyLtjy3Z8erFv71 KKTq+gxI/7DK55pJf3PoD+kT4kyGm6EF9DTdK4ojMdar17uyX0IOZz/4vkkF0d+60nmnLX63FJPA jUyB0HUNJ32NXDo9UsM38aoNAgMBAAGjgawwgakwDwYDVR0TAQH/BAUwAwEB/zARBgNVHSAECjAI MAYGBFUdIAAwDgYDVR0PAQH/BAQDAgGGMFQGA1UdIwRNMEuAFI2N95+hDQAhMu+p7SKu4Dv00H2w oS2kKzApMQ4wDAYDVQQKEwVOb2tpYTEXMBUGA1UEAxMOTm9raWEgIFJvb3QgQ0GCBDpVqdkwHQYD VR0OBBYEFKcksD7Fg+8EDlB2Sxgy58pW0Sy6MA0GCSqGSIb3DQEBBQUAA4IBAQAC3lEUplDlVNOT Pjz/XFezXx2bV2XbCFindhA3F815Egi55H6/cYezEjoP4QLNEGGl2I3aLvkn5A0T8I4pbiFPhIiu B/frbbGg6k6GjQLe/bFQ8F1mAOOR+GyneKZFPfzaRV0jiIR9QqnMXTf8RvKkCJyFj10MZVsLIy/Y uBkzeP3JhzDhUdtPfwmJN6ZbIhH5uR/2BwAGtgQknb8WX3I4wnhWtMUxB8XmayayYs8qWYeIiVkI FV+sLTkWUWVvvKUjyakBpbAW2vUP84DYsJ8TL1YefNjf/nIOByMcORLuV/1gPjyv00qJbcB59AA+ iXe3zIo8QNcgXG0uPQQFmrGDMIID5DCCAsygAwIBAgIQMH5apak8lEy6LmLlLsJy8TANBgkqhkiG 9w0BAQUFADAzMQswCQYDVQQGEwJGSTEOMAwGA1UEChMFTm9raWExFDASBgNVBAMTC05va2lhIEJJ IENBMB4XDTExMDkwNjA1NTIwNFoXDTE0MDkwNjA1NTIwNFowVjEOMAwGA1UECgwFTm9raWExDzAN BgNVBAsMBlBlb3BsZTEYMBYGCgmSJomT8ixkAQEMCDEwMDI0Njc2MRkwFwYDVQQDDBBTYXZvbGFp bmVuIFRlZW11MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAshEsmw6Yiz6XWX26oF+I s5fsfE1OfCjOelclmtqCiIgXND5klkNOBs2d4ZGzgD9mN+XnTZnOTh249c2WxPBugf12DCcDmBAJ gL+VuWUJVBTE5NRchm/O8nZnZsRFst+gAC9/Juykh4+EYewZ7QbpnlwW7hNpj8eH+rMr+OZHKzdp KTftgVjmuF4JJ/cPMQUjL8SuGj+zBW6IWPOZdqkEMtf7Pr8kkYbZsh0SgJ0ceRHZ7Uc06mB/y+C1 UnJPxehTTdu8tpCjdzXgBw/H2uuW1J3qdHbCfbuDILql8V8RiZKubcZLhdsD3Jvj8qK0DGWBJa6x p90q5p3pLE8LvAeCgQIDAQABo4HQMIHNMA4GA1UdDwEB/wQEAwIEMDAfBgNVHSMEGDAWgBSnJLA+ xYPvBA5QdksYMufKVtEsujAZBgNVHSAEEjAQMA4GDCsGAQQBXgExBgEHAzA5BgNVHR8EMjAwMC6g LKAqhihodHRwOi8vY3JsLm5va2lhLmNvbS9Ob2tpYSUyMEJJJTIwQ0EuY3JsMCUGA1UdEQQeMByB GnRlZW11LnNhdm9sYWluZW5Abm9raWEuY29tMB0GA1UdDgQWBBQTRzvZsgmQrAGCeuzdHTGAC6Jg UzANBgkqhkiG9w0BAQUFAAOCAQEACmPVsdi07pjK5gDa+W5JlE2C74kVVsB8alBqfioYeR5At2FG B7sua4Dz5H7TJMpZ1jYFeI+zjexD5f+beY2IlV15lMoWD+5e38QlLYjwfe2LAyvdzBKXW0e0U6Bt p78ft4gyVak1X+Db+ebR+FNHUOMNhm+yK3w9sy5ZQzBFusIx4OgxGvcZhyhmd9WjipSTalgPwgqV Ju2aPADCG++OEXmgEWRLsR4yNopkgK4ftVqrN5uUtLs83qdeXTRcNRiET1IOx5zmYFZ6q3gjKIx5 iyuxcDeYas93vVHUcaRRYpsoby5CHq7Z/j/TQhtqO/knWuxLFFiCUgdGKMKrRkg29DCCBAowggLy oAMCAQICEQCBvi+p+bA/dBtBtybwA6YYMA0GCSqGSIb3DQEBBQUAMDMxCzAJBgNVBAYTAkZJMQ4w DAYDVQQKEwVOb2tpYTEUMBIGA1UEAxMLTm9raWEgQkkgQ0EwHhcNMTEwOTA2MDU1MDM0WhcNMTMw OTA1MDU1MDM0WjBWMQ4wDAYDVQQKDAVOb2tpYTEPMA0GA1UECwwGUGVvcGxlMRgwFgYKCZImiZPy LGQBAQwIMTAwMjQ2NzYxGTAXBgNVBAMMEFNhdm9sYWluZW4gVGVlbXUwggEiMA0GCSqGSIb3DQEB AQUAA4IBDwAwggEKAoIBAQDFPmbRVwuo52v+h6xnQUqokAx2xsHjmPBniEkzgtgBNJsFi838ATEg 1zsx+VotoJg7hMijcrQfpTAgW6gpLGnlmw5QQswrNK1zleOHb4pA5JguU3WhVKFkAH/6/2EU2k/9 m8Pb/gwP55cYg80R6fRmbdsWKhseXF/1isW/rJcWLmIYDg/rXfo3ixqtT9MroAMiuoXnb0ij1L2d Jj64LDp3Ld8Jo0qZzk3Fj4apo8PBd8eAH6HloVBJkxQcwAnv561A+Xi1GHZ2mafRYJGO+1uBDwyd g/8ybEXXA4MKo8lPKjBebYBUFvz80DBA/Lq74UysXkG23BSulcG4xQSYGlyzAgMBAAGjgfUwgfIw HwYDVR0jBBgwFoAUpySwPsWD7wQOUHZLGDLnylbRLLowGQYDVR0gBBIwEDAOBgwrBgEEAV4BMQYB BgQwOQYDVR0fBDIwMDAuoCygKoYoaHR0cDovL2NybC5ub2tpYS5jb20vTm9raWElMjBCSSUyMENB LmNybDAjBgNVHSUEHDAaBggrBgEFBQcDAgYEVR0lAAYIKwYBBQUHAwQwDgYDVR0PAQH/BAQDAgeA MCUGA1UdEQQeMByBGnRlZW11LnNhdm9sYWluZW5Abm9raWEuY29tMB0GA1UdDgQWBBTGhbTJF0EX iagjymQo6GIuSQeRVDANBgkqhkiG9w0BAQUFAAOCAQEAqai6TxZ/BlMHZIhJNPriBPXkQhUlBkGA buJZ5sVm1HIQhWN8elZKjjJdHi1qWEKhMg7yHjEMZsyV8XAZzK0UnOqkpUnt+jnVkNZ9O7/jRtyK f4WUtq5jErc8Hlv4bbGFRHk1T7AuLLE52r1lYOdmoibnQp03QtlDvHUNa68G7jvzThJhieB7U1xh vH3yy0ktaVnWEgAylqf9yIUFjnqau5R6cE1Xo57IYPk/KitX0YF+OigEI/bOQVMi+fze93ZsAOJv /z6g/NGemvUgl5YSdX0uPQK6kEHf/sp/nZyUWWQ7OjtVSqkq2YuYEueQFxTfafl+78GWqgm6W/Bl 32laYzGCAuswggLnAgEBMEgwMzELMAkGA1UEBhMCRkkxDjAMBgNVBAoTBU5va2lhMRQwEgYDVQQD EwtOb2tpYSBCSSBDQQIRAIG+L6n5sD90G0G3JvADphgwCQYFKw4DAhoFAKCCAXgwGAYJKoZIhvcN AQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG9w0BCQUxDxcNMTEwOTA5MDYzNDU1WjAjBgkqhkiG9w0B CQQxFgQURjCm+A0j2Ku5v/IgrltE1nSmDjEwVgYJKwYBBAGCNxAEMUkwRzAzMQswCQYDVQQGEwJG STEOMAwGA1UEChMFTm9raWExFDASBgNVBAMTC05va2lhIEJJIENBAhAwflqlqTyUTLouYuUuwnLx MFgGCyqGSIb3DQEJEAILMUmgRzAzMQswCQYDVQQGEwJGSTEOMAwGA1UEChMFTm9raWExFDASBgNV BAMTC05va2lhIEJJIENBAhAwflqlqTyUTLouYuUuwnLxMGcGCSqGSIb3DQEJDzFaMFgwCgYIKoZI hvcNAwcwDgYIKoZIhvcNAwICAgCAMA0GCCqGSIb3DQMCAgFAMAcGBSsOAwIHMA0GCCqGSIb3DQMC AgEoMAcGBSsOAwIaMAoGCCqGSIb3DQIFMA0GCSqGSIb3DQEBAQUABIIBAC7WChrLgjwbiFxGwpGi kX4y0S0uoIjksNYXC7Fs+KB2Op2SgsEQPkrDEAgNvuhvhPlHePHz+nz6v2c0aytk7uPlZh7IxJR2 x3u1SWhJlzad+0uvytXwizYPFX4n/1OmybdTeS2Oo0t0FKc28De3+hspqQaxTGPhxQCrb93/BMI/ RffCGTKSBxSHU3lzTG+HnA34qkxuBb0F4bIaaYIrjrvO3k20aRTi14KyxItycgCXYslC5iBr/7UE JQXJ/ety9tverSsH77ypnTp98WTTvs0LpEwIAd/hl4kyAqrN2YrswinlM3+lzRun1yjUNOkiwelF 8Smf7mR9atGMLVYjhaQAAAAAAAA= ------=_NextPart_000_0181_01CC6ED3.BB8B38C0-- From teemu.savolainen@nokia.com Fri Sep 9 03:06:21 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 E57A621F886D for ; Fri, 9 Sep 2011 03:06:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.178 X-Spam-Level: X-Spam-Status: No, score=-3.178 tagged_above=-999 required=5 tests=[AWL=0.421, 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 r7Lr6PebMzpo for ; Fri, 9 Sep 2011 03:06:20 -0700 (PDT) Received: from mgw-da01.nokia.com (smtp.nokia.com [147.243.128.24]) by ietfa.amsl.com (Postfix) with ESMTP id 210C821F87FA for ; Fri, 9 Sep 2011 03:06:19 -0700 (PDT) Received: from vaebh101.NOE.Nokia.com (vaebh101.europe.nokia.com [10.160.244.22]) by mgw-da01.nokia.com (Switch-3.4.4/Switch-3.4.3) with ESMTP id p89A88u1018486; Fri, 9 Sep 2011 13:08:11 +0300 Received: from smtp.mgd.nokia.com ([65.54.30.5]) by vaebh101.NOE.Nokia.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.4675); Fri, 9 Sep 2011 13:07:47 +0300 Received: from 008-AM1MMR1-002.mgdnok.nokia.com (65.54.30.57) by NOK-am1MHUB-01.mgdnok.nokia.com (65.54.30.5) with Microsoft SMTP Server (TLS) id 8.2.255.0; Fri, 9 Sep 2011 12:07:47 +0200 Received: from 008-AM1MPN1-032.mgdnok.nokia.com ([169.254.2.143]) by 008-AM1MMR1-002.mgdnok.nokia.com ([65.54.30.57]) with mapi id 14.01.0323.007; Fri, 9 Sep 2011 12:07:46 +0200 From: To: , Thread-Topic: [mif] Last Call for MIF DNS server selection document Thread-Index: AQHMbmf3BHSQ8Tn9hkac95+LwFpGipVEmINQ Date: Fri, 9 Sep 2011 10:07:46 +0000 Message-ID: <916CE6CF87173740BC8A2CE44309696202570894@008-AM1MPN1-032.mgdnok.nokia.com> References: <20110908204329.GN38973@shinkuro.com> In-Reply-To: <20110908204329.GN38973@shinkuro.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes 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+/nZJb9Kg7IijnarCFufw93yGp9Kqg4VsreROV3oSoCKo4MAZQAlH7cl7QEYi2t0p8hTrsrklpyqBfRuV1a3TP5t4zLsal1WzFsT0mQwFWR/yRh3UhJztIIhyLXE7aj3YtN85Eqji4hyMU9zDnsRybCxak6t2mfbgLZX2mjzSIIHnDkgCjyHZFFOhfBqPd/c5FcvKdb64f0sgP1bp0Rng5aZTrafF1qFNxmzB3fX0dr0qbeG9YfeKCcsiZk5WqSUtPkVYQ2fFAPg== x-originating-ip: [10.162.91.110] Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=SHA1; boundary="----=_NextPart_000_018E_01CC6EF1.76A832D0" MIME-Version: 1.0 X-OriginalArrivalTime: 09 Sep 2011 10:07:47.0931 (UTC) FILETIME=[5378AAB0:01CC6ED8] X-Nokia-AV: Clean Subject: Re: [mif] Last Call for MIF DNS server selection document 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, 09 Sep 2011 10:06:22 -0000 ------=_NextPart_000_018E_01CC6EF1.76A832D0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Hi Andrew, Quite a review, thank you. Responses inline: > -----Original Message----- > From: mif-bounces@ietf.org [mailto:mif-bounces@ietf.org] On Behalf Of > ext Andrew Sullivan > Sent: 08. syyskuuta 2011 23:44 > To: mif@ietf.org > Subject: Re: [mif] Last Call for MIF DNS server selection document > > First, about nits: there are several places where the document needs a good > once-over for correct usage, grammar, and spelling. Articles seem to be > missing in many places. It'd be good to sort this out, but I can understand I know, that is mostly due imperfections in my English skills and lack of easy access to proofreaders:) I think language is best handled once the document is otherwise acceptable (e.g. by RFC Editor). > As an overall comment, there are sections of the document that explain the > motivation and background, and sections of the document that prescribe > steps to be taken. The former are informative, and the latter normative. I > suggest including near the beginning an overview stating what sections are > informative and what are normative, and breaking those sections cleanly (i.e. > no explanatory text in the normative sections). I have started writing -04 version, and added to the introduction section: -- Informative background information about problem descriptions and example deployment scenarios are included in sections 2 and 3. Section 4 contains all normative descriptions for DHCP options and required node behavior. Informative section 5 illustrates behavior of a node implementing functionality described in the section 4. Sections 6 and 7 contain informational considerations about scalability and network operations. Informational section 10 summarizes identified security considerations. -- Furthermore, I ensured that no normative keywords are outside of section 4 and because of that moved following text from section 10 to 4.1: -- A node that accepts DNS server selection rules from non-trusted interfaces and implements DNSSEC validation SHOULD send queries also to (all) other known DNS servers in case a non-validatable response is received from the preferred DNS server. This protects against possible redirection attacks. -- > I've had a hard time expressing why this text has been bothering me, but I > think I understand what it is: that text is not explicit enough that it is starting > from the premise that the DNS is not a unified global namespace. I think it > needs another sentence, at the beginning, along the following lines: > > We start from the premise that operators sometimes include private > namespaces in the answers they provide from DNS servers, and that > those private namespaces are at least as useful to clients as the > answers from the public DNS. I migrated the nice text you proposed, removed some old, and the paragraph looks now as following: -- We start from the premise that network operators sometimes include private namespaces in the answers they provide from DNS servers, and that those private namespaces are at least as useful to nodes as the answers from the public DNS. When private namespaces are visible for a node, some DNS servers have information other servers do not have. The node ought to be able to ask right server for the information it needs. -- > An example of an application that benefits from multi-homing is a > web browser that commonly accesses many different destinations, > each of which is available only on one network. The browser > therefore needs to be able to communicate over different network > interfaces, depending on the destination it is trying to reach. Copied as proposed. > The key point here, I think, is that the networks are disparate and not > actually all available via the public network. By making these adjustments, it > makes the document more open-handed about the fact it's trying to address: > there are all kinds of pockets on the Internet, and you have to connect to > different pockets via different means. Agree, Internet is a network of networks, after all. > In section 4.1, we have this: > > When a DNS query needs to be made, the resolver SHOULD give highest > precedence to the DNS servers explicitly known to serve matching > suffixes or prefixes. > > I really dislike the term "suffix" here, and I'm not sure "prefix" is what you > want either. I think "suffix" really means "domain", right? Suffix means domain, yes. Prefix is about IPv6 address prefix.. > That is, if I offer a DNS server that is high-priority for example.com, it can > answer for anything from example.com all the way down. No? Similarly, Yes. > you might just want "networks" for the reverse tree, since "prefix" doesn't > exactly get it right: the network address is turned around in the DNS query. And IPv4 was also added, hence prefix does not suit for that too well either. > (This also appears elsewhere in the draft, but I won't mention it again unless > I'm proposing text.) "Prefix" is probably fine if you make it clear that you're > providing the prefix of a network, and that it's the client's job to do the right > thing with that prefix in order to formulate reverse-tree DNS queries. In the -04 I switched using "domain" and "network". In the beginning of 4.1 I try to introduce those now as follows: -- To build the list in an optimal way, a node SHOULD ask with DHCP which DNS servers of each network interface are most likely able to successfully serve forward lookup requests matching to specific domain suffixes or reverse (PTR record) lookup requests matching to specific network addresses (later referred as "domain" and "network"). -- This changed e.g. the text your referred above to look as follows: -- When a DNS query needs to be made, the resolver SHOULD give highest precedence to the DNS servers explicitly known to serve matching domain or network. -- Is it better to talk about "DNS domain" or just "domain"? > However, the resolver SHOULD take into account > different trust levels of pieces of DNS server selection information > the resolver may have received from node's network interfaces. The > resolver SHOULD prefer DNS servers of trusted interfaces. > > Why isn't this MUST? Because a node implementation might not want to care about security (at this layer) for some reason. I mean it is of course easy to say why the node really SHOULD care about trust, but the DNS server selection itself should work just fine even if the node does not take security into account (it just may result in unwanted DNS server being used when under attack, but maybe said node is able to recover from that by some other means). In the past I've encountered MUSTs too often that are not applicable in some scenarios and therefore I personally hesitate using MUST unless that is absolutely required. To some extent this is matter of taste and hence I'm totally open for WG input. >This entire procedure is hard for me to follow, in fact. > It seems to me that we have two different meanings of "trust" here, and I > think that may be part of the problem. The first meaning (trust1) is "a setting > that comes with the information that DNS server S on interface I provides > namespace N with trust-level T". > This is a trust-value that is metadata provided by the provider of the name > server address-interface binding. The second meaning (trust2) is how much > you, the client, believe the data you got: did you get the > trust1 data in a way that you can be sure it's legitimate? It seems to me that > combining trust1 and trust2 into a single scale might be wrong, and I think > that the last row in Figure 4 suggests this. If I simply don't know whether the > data I get on interface B is real or spoofed, why would I ever use that, even if > it's "medium priority", over the data I can be sure is an unspoofed answer on > interface A? The idea is that the node by magic knows what interfaces can be trusted and what cannot (trust2). This results that trust1 is absolute if interface was trusted (trust2 is there), and ~none if interface was not trusted (trust2 is not there). In case of untrusted information not being in conflict with the trusted one, I thought one could just as well follow that information. Just like in the street you "trust" navigation guidance given by strangers when lost:) Another clear implementation alternative is simply to ignore untrusted interfaces. This makes me think about Brian's concern about "legitimizing" private namespaces. If this document would state that only trusted interfaces can configure DNS server selection rules, would that mitigate the "legitimizing" concern as then this tool would not be used in environments where network operator cannot configure nodes trust levels enough to make them request & listen the configuration message? I.e. that might help limit usage of the tool to scenarios where we have seen need for it. I did not update text on this area yet, waiting for discussion to progress. > Also, I think this sentence is missing an "un" before some "trusted": > > The DNS servers of trusted interfaces may be of highest priority > only if trusted interfaces specifically configure DNS servers to be > of low priority. Yes, should be:"The DNS servers of untrusted interfaces.." > I think the discussion just after Figure 4 about revealing information about > ongoing communications is total nonsense, and should be removed. Not everyone agrees on that one I believe. From folks following BroadBand Forum the message in some past discussion was that they do not want to broadcast DNS queries to all interfaces for this reason (I hope I recall that right). Also I believe in classic split-tunnel VPN case corporate IT would prefer not to provide all names to hostile hotspot DNS server, while they may not be able to totally block that (e.g. host probably sends DNS queries out also when VPN is not running). > If you want to put names in the DNS, they're never going to be secret. That's why they are private namespaces - you can't learn even existence of private names from the Internet. From the node you can of course, and the node (esp. if compromised) may of course leak them forward. > The attempts to use split-brain DNS and so on for hiding network resources > are a completely misguided attempt at security by obscurity, and I don't think > the draft should include any text that even implies this technique works. > Private DNS names leak all over the place, and if you think otherwise you're > dreaming. Should one not try to minimize that leak? I.e. avoid "unnecessary" revealing of information that does not have to be revealed. Would it satisfy your concern if we drop the:" unnecessary reveal information about ongoing communications" away? And hence would have just: -- The resolver SHOULD avoid sending queries to different interfaces in parallel as that may waste resources such as energy. -- Again SHOULD, as in some cases implementation does not care and could behave differently (and some cases the energy conservation is really important). > Later, we have > > Because DNSSEC provides cryptographic assurance of the integrity of > DNS data, data that can be validated under DNSSEC is necessarily to > be preferred over data that cannot be. It follows that, if > validation is not performed by the host making the decision about > whether to trust the DNS data from a given interface, it cannot make > a decision to prefer data from any interface with any great > assurance: any response could be forged, and there is no way to > detect it without DNSSEC. > > That isn't true. If you have a cryptographically strong connection to a DNS > server and you know that it is doing DNS validation (because, for instance, > your corporate overlords told you, "We do validation on the VPN DNS > server"), you do in fact have a reason to prefer the answers from that server. > You might set DO and not CD, and get back the AD bit on your answer, giving > you evidence that the validation was done by the server. I think the > paragraph can be rewritten this way (although this includes some > explanatory material and some normative material; as I suggested above, > perhaps that ought to be split). That piece of text came directly from you: http://www.ietf.org/mail-archive/web/mif/current/msg01058.html ... But I agree with you and let's use the new text you proposed instead: -- > Because DNSSEC provides cryptographic assurance of the integrity of > DNS data, data that can be validated under DNSSEC is necessarily to > be preferred over data that cannot be. There are two ways that a > host can determine that data is valid under DNSSEC. The first is > to perform DNSSEC validation itself. The second is to have a > secure connection to an authenticated DNS server, and to rely on > that DNS server to perform DNSSEC validation (signalling that it > has done so using the AD bit). If a DNS response is not proven to > be unmolested using DNSSEC, then a host cannot make a decision to > prefer data from any interface with any great assurance: any > response could be forged, and there is no way to detect the forgery > without DNSSEC. Therefore, a DNSSEC-aware resolver MUST NOT > proceed with a reply that cannot be validated using DNSSEC if DNS > queries sent to other servers are still pending. -- > This instruction seems to contradict the previous text: > > In the case of a trusted DNS server replying negatively to a question > having matching suffix, it will be for implementation to decide > whether to consider that as a final response, or whether to ask also > from other DNS servers. The implementation decision may be based, > for example, on deployment or trust models. > > Instead of "matching suffix", we could say something like "from a DNS server > that can provide answers for the queried name". But I think what this is > saying is that, if you get a validated NXDOMAIN from an interface, you're > allowed to go on and ask other servers. Even if the answer can't be > validated? If so, this seems to contradict the passages before it, and it's > clearly an attack vector on DNSSEC's provable non-existence. Some people > think that feature is dumb, but it's part of what DNSSEC offers now, and it > would be strange to introduce a way to turn it off. I'd add a reference here > to the "different trust anchor" discussion in Appendix B. See also below. So something along lines: -- In the case of validated NXDOMAIN response being received from a DNS server that can provide answers for the queried name a node MUST NOT accept non-validated replies from other DNS servers (see Appendix B for considerations related to multiple trust anchors). -- > I can't see anything you can do about cases where a DNS server always lies > to you. On the other hand, if you do DNSSEC, those servers will always fail > validation anyway, so we can hope they'll meet the fate they deserve. > > In section 4.2, I don't understand, "IPv6 prefixes should cover all the DNS > suffixes configured in this option." Maybe I've actually misunderstood the > use of "prefix" and "suffix" in this document? With new terms it says:"IPv6 networks should cover all the DNS domains..". It means that configuration should be such that one could do reverse queries successfully for all the domains that are configured (and vice versa). > In section 4.5, I find this odd: > > The OPTION_DNS_SERVER_SELECT is designed to coexist with > OPTION_DNS_SERVERS defined in [RFC3646]. The DNS servers configured > via OPTION_DNS_SERVERS MUST BE considered as default name servers > with medium preference. When both options are received from the same > network interface and the OPTION_DNS_SERVER_SELECT contains default > DNS server address, the resolver MUST make the decision which one to > prefer based on preferences. > > I read that to mean that, if you get both options and the > OPTION_DNS_SERVER_SELECT contains a default DNS server address, then > the behaviour is up to you (i.e. undefined). Why is that a MUST? Why isn't it > just "... the resolver MAY use whichever option it likes"? It should say that node must not select randomly, but use the preference value on OPTION_DNS_SERVER_SELECT. If the preference in _SERVER_SELECT is default (i.e. same preference for both), then the node SHALL use the server received via _SERVER_SELECT option. I.e. if both options are present, DNS server from OPTION_DNS_SERVERS is used by default only if OPTION_DNS_SERVER_SELECT contains low default preference. > In the same section, does this > > If both OPTION_DNS_SERVERS and OPTION_DNS_SERVER_SELECT contain > the > same DNS server(s) IPv6 address(es), only one instance of each DNS > servers' IPv6 addresses shall be added to the DNS server list. > > mean "only add the same address of a DNS server to the server list once"? > The passage as it is reads to me as though you might throw away some > addresses you get. "If both OPTION_DNS_SERVERS and OPTION_DNS_SERVER_SELECT contain the same DNS server(s) IPv6 address(es), a node SHALL add the same address of a DNS server to the server list only once. " ? > In section 4.6., I think that it needs to be made clear that a bare name is first > treated as a pre-DNS hostname before it encounters the DNS search list. > (Frankly, that entire mechanism is broken, and it would suit me just fine if the > document said, "This algorithm is incompatible with the DNS search list and > the OPTION_DOMAIN_LIST feature." But I know people would scream about > it. It's still broken.) I'm not sure what you mean with "pre-DNS" hostname.. > In 4.7, what about other things that could do context-sensitive referrals, like > SRV? Hmm.. what should we write about those? Any record type that contains domain names shall fall under this server selection logic? > In A.1, the same discussion about revealing information as above pertains. Would it be ok then if this is dropped: -- Another downside is revealing to all DNS servers the names a host is connecting to. For example, a DNS server of a public hotspot could learn all the private names host is trying to connect on other interfaces. -- > I hope these comments are useful. They were very useful. Additionally, for -04 under works, I corrected reference of draft-ietf-v6ops-multihoming-without-nat66 to draft-ietf-v6ops-ipv6-multihoming-without-ipv6nat. I also fixed some nits I encountered while going through these comments.. Will wait for discussion to proceed before doing additional updates. Best regards, Teemu ------=_NextPart_000_018E_01CC6EF1.76A832D0 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIOuzCCAzYw ggIeoAMCAQICBDpVqdkwDQYJKoZIhvcNAQEFBQAwKTEOMAwGA1UEChMFTm9raWExFzAVBgNVBAMT Dk5va2lhICBSb290IENBMB4XDTAxMDEwNTExMDUwNVoXDTE2MDEwMjExMDUwNVowKTEOMAwGA1UE ChMFTm9raWExFzAVBgNVBAMTDk5va2lhICBSb290IENBMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8A MIIBCgKCAQEAsrTy8gLmr4LYvp0khVUVHw7ascdl+Cjr+yI5MlZ6J/U6Qsvkiqthgqq8rPcLV0P1 92TfBr27VgKEeCaZe0icS1jC2spM/wRv3j2WxdkKxb9kDJtuCNJaRBqvi5vGTHB15nmEmKuL5f3i rAxeHqPjgS496oWcudzFT1e7Xrc/gWGFYd72+/ykIFXjWOMZv6QpxD8x1hLPyh2YVXRk9U7N7pvm RQNX29g4SCFJY2BBIa5JPlwIF8Nc9IePaC/E/2M4tGMtiOOZlm99EoL7N0hJZtFSvUwdCBud/viH 4DgsKGjNkNKi6pAHc9IaXB6tIykcoYp+L+oe/3+cuEJaCj1EKwIDAQABo2YwZDASBgNVHRMBAf8E CDAGAQH/AgEEMB0GA1UdDgQWBBSNjfefoQ0AITLvqe0iruA79NB9sDAfBgNVHSMEGDAWgBSNjfef oQ0AITLvqe0iruA79NB9sDAOBgNVHQ8BAf8EBAMCAYYwDQYJKoZIhvcNAQEFBQADggEBAIGEPql2 TALyKi/h1J+Mh5XolAtYppcSOLMtBkoA7ZovGBDNvl0VbZs8AAojJqkUoWBB+L6DKyl/jKhNfKcu rWRGRyj7pnbxrKLsI3gmWNWkyo2b60wJwe9fqPD5ZQy3oEiMit9l0Ba6il/k2GqYopUCNMa7mfeb E2LeBy5ChYMiCi97UQSJvAdzEYylTJw8Awc6AiM2Ve5N+XxsmKgNf/2A/5IJ3EZZ+wFRmkI4062A oNU302rqAt0HH88jzoUF4AfYHWl6HpYhGXFbcX44rHINyPmFBRxLYIFJ6ZWUr/mXpL/e6rqFtNWO kV6UoJND7OVZkbLh7F1+lcqXRU8TPBMwggOHMIICb6ADAgECAgRBtbHpMA0GCSqGSIb3DQEBBQUA MCkxDjAMBgNVBAoTBU5va2lhMRcwFQYDVQQDEw5Ob2tpYSAgUm9vdCBDQTAeFw0wNjAzMzAwOTU3 MTFaFw0xNjAxMDIxMTA1MDVaMDMxCzAJBgNVBAYTAkZJMQ4wDAYDVQQKEwVOb2tpYTEUMBIGA1UE AxMLTm9raWEgQkkgQ0EwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQDtFCg3QEjSCg6T IUxoWsNwELh8bBNiUQPCPmg8c2DHQYXWWCSCMb+S0Fvh1qqI1xt+XnzyFq+5eqzGzDj4UaBcG+d9 qxrCFly8sHyoPTryyPrR0EI2UUDWwfS6ojhqgwghRqo8G38TjFusyBtLub/5L6yvWYSOHD+JcB+q VM2fbkArPYK4Ydv8WG/DbHjGn0gKq0zwpVZKI/gCK/QALYvte02NXseqvY9/GOyLtjy3Z8erFv71 KKTq+gxI/7DK55pJf3PoD+kT4kyGm6EF9DTdK4ojMdar17uyX0IOZz/4vkkF0d+60nmnLX63FJPA jUyB0HUNJ32NXDo9UsM38aoNAgMBAAGjgawwgakwDwYDVR0TAQH/BAUwAwEB/zARBgNVHSAECjAI MAYGBFUdIAAwDgYDVR0PAQH/BAQDAgGGMFQGA1UdIwRNMEuAFI2N95+hDQAhMu+p7SKu4Dv00H2w oS2kKzApMQ4wDAYDVQQKEwVOb2tpYTEXMBUGA1UEAxMOTm9raWEgIFJvb3QgQ0GCBDpVqdkwHQYD VR0OBBYEFKcksD7Fg+8EDlB2Sxgy58pW0Sy6MA0GCSqGSIb3DQEBBQUAA4IBAQAC3lEUplDlVNOT Pjz/XFezXx2bV2XbCFindhA3F815Egi55H6/cYezEjoP4QLNEGGl2I3aLvkn5A0T8I4pbiFPhIiu B/frbbGg6k6GjQLe/bFQ8F1mAOOR+GyneKZFPfzaRV0jiIR9QqnMXTf8RvKkCJyFj10MZVsLIy/Y uBkzeP3JhzDhUdtPfwmJN6ZbIhH5uR/2BwAGtgQknb8WX3I4wnhWtMUxB8XmayayYs8qWYeIiVkI FV+sLTkWUWVvvKUjyakBpbAW2vUP84DYsJ8TL1YefNjf/nIOByMcORLuV/1gPjyv00qJbcB59AA+ iXe3zIo8QNcgXG0uPQQFmrGDMIID5DCCAsygAwIBAgIQMH5apak8lEy6LmLlLsJy8TANBgkqhkiG 9w0BAQUFADAzMQswCQYDVQQGEwJGSTEOMAwGA1UEChMFTm9raWExFDASBgNVBAMTC05va2lhIEJJ IENBMB4XDTExMDkwNjA1NTIwNFoXDTE0MDkwNjA1NTIwNFowVjEOMAwGA1UECgwFTm9raWExDzAN BgNVBAsMBlBlb3BsZTEYMBYGCgmSJomT8ixkAQEMCDEwMDI0Njc2MRkwFwYDVQQDDBBTYXZvbGFp bmVuIFRlZW11MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAshEsmw6Yiz6XWX26oF+I s5fsfE1OfCjOelclmtqCiIgXND5klkNOBs2d4ZGzgD9mN+XnTZnOTh249c2WxPBugf12DCcDmBAJ gL+VuWUJVBTE5NRchm/O8nZnZsRFst+gAC9/Juykh4+EYewZ7QbpnlwW7hNpj8eH+rMr+OZHKzdp KTftgVjmuF4JJ/cPMQUjL8SuGj+zBW6IWPOZdqkEMtf7Pr8kkYbZsh0SgJ0ceRHZ7Uc06mB/y+C1 UnJPxehTTdu8tpCjdzXgBw/H2uuW1J3qdHbCfbuDILql8V8RiZKubcZLhdsD3Jvj8qK0DGWBJa6x p90q5p3pLE8LvAeCgQIDAQABo4HQMIHNMA4GA1UdDwEB/wQEAwIEMDAfBgNVHSMEGDAWgBSnJLA+ xYPvBA5QdksYMufKVtEsujAZBgNVHSAEEjAQMA4GDCsGAQQBXgExBgEHAzA5BgNVHR8EMjAwMC6g LKAqhihodHRwOi8vY3JsLm5va2lhLmNvbS9Ob2tpYSUyMEJJJTIwQ0EuY3JsMCUGA1UdEQQeMByB GnRlZW11LnNhdm9sYWluZW5Abm9raWEuY29tMB0GA1UdDgQWBBQTRzvZsgmQrAGCeuzdHTGAC6Jg UzANBgkqhkiG9w0BAQUFAAOCAQEACmPVsdi07pjK5gDa+W5JlE2C74kVVsB8alBqfioYeR5At2FG B7sua4Dz5H7TJMpZ1jYFeI+zjexD5f+beY2IlV15lMoWD+5e38QlLYjwfe2LAyvdzBKXW0e0U6Bt p78ft4gyVak1X+Db+ebR+FNHUOMNhm+yK3w9sy5ZQzBFusIx4OgxGvcZhyhmd9WjipSTalgPwgqV Ju2aPADCG++OEXmgEWRLsR4yNopkgK4ftVqrN5uUtLs83qdeXTRcNRiET1IOx5zmYFZ6q3gjKIx5 iyuxcDeYas93vVHUcaRRYpsoby5CHq7Z/j/TQhtqO/knWuxLFFiCUgdGKMKrRkg29DCCBAowggLy oAMCAQICEQCBvi+p+bA/dBtBtybwA6YYMA0GCSqGSIb3DQEBBQUAMDMxCzAJBgNVBAYTAkZJMQ4w DAYDVQQKEwVOb2tpYTEUMBIGA1UEAxMLTm9raWEgQkkgQ0EwHhcNMTEwOTA2MDU1MDM0WhcNMTMw OTA1MDU1MDM0WjBWMQ4wDAYDVQQKDAVOb2tpYTEPMA0GA1UECwwGUGVvcGxlMRgwFgYKCZImiZPy LGQBAQwIMTAwMjQ2NzYxGTAXBgNVBAMMEFNhdm9sYWluZW4gVGVlbXUwggEiMA0GCSqGSIb3DQEB AQUAA4IBDwAwggEKAoIBAQDFPmbRVwuo52v+h6xnQUqokAx2xsHjmPBniEkzgtgBNJsFi838ATEg 1zsx+VotoJg7hMijcrQfpTAgW6gpLGnlmw5QQswrNK1zleOHb4pA5JguU3WhVKFkAH/6/2EU2k/9 m8Pb/gwP55cYg80R6fRmbdsWKhseXF/1isW/rJcWLmIYDg/rXfo3ixqtT9MroAMiuoXnb0ij1L2d Jj64LDp3Ld8Jo0qZzk3Fj4apo8PBd8eAH6HloVBJkxQcwAnv561A+Xi1GHZ2mafRYJGO+1uBDwyd g/8ybEXXA4MKo8lPKjBebYBUFvz80DBA/Lq74UysXkG23BSulcG4xQSYGlyzAgMBAAGjgfUwgfIw HwYDVR0jBBgwFoAUpySwPsWD7wQOUHZLGDLnylbRLLowGQYDVR0gBBIwEDAOBgwrBgEEAV4BMQYB BgQwOQYDVR0fBDIwMDAuoCygKoYoaHR0cDovL2NybC5ub2tpYS5jb20vTm9raWElMjBCSSUyMENB LmNybDAjBgNVHSUEHDAaBggrBgEFBQcDAgYEVR0lAAYIKwYBBQUHAwQwDgYDVR0PAQH/BAQDAgeA MCUGA1UdEQQeMByBGnRlZW11LnNhdm9sYWluZW5Abm9raWEuY29tMB0GA1UdDgQWBBTGhbTJF0EX iagjymQo6GIuSQeRVDANBgkqhkiG9w0BAQUFAAOCAQEAqai6TxZ/BlMHZIhJNPriBPXkQhUlBkGA buJZ5sVm1HIQhWN8elZKjjJdHi1qWEKhMg7yHjEMZsyV8XAZzK0UnOqkpUnt+jnVkNZ9O7/jRtyK f4WUtq5jErc8Hlv4bbGFRHk1T7AuLLE52r1lYOdmoibnQp03QtlDvHUNa68G7jvzThJhieB7U1xh vH3yy0ktaVnWEgAylqf9yIUFjnqau5R6cE1Xo57IYPk/KitX0YF+OigEI/bOQVMi+fze93ZsAOJv /z6g/NGemvUgl5YSdX0uPQK6kEHf/sp/nZyUWWQ7OjtVSqkq2YuYEueQFxTfafl+78GWqgm6W/Bl 32laYzGCAuswggLnAgEBMEgwMzELMAkGA1UEBhMCRkkxDjAMBgNVBAoTBU5va2lhMRQwEgYDVQQD EwtOb2tpYSBCSSBDQQIRAIG+L6n5sD90G0G3JvADphgwCQYFKw4DAhoFAKCCAXgwGAYJKoZIhvcN AQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG9w0BCQUxDxcNMTEwOTA5MTAwNzQ0WjAjBgkqhkiG9w0B CQQxFgQURDE/cZTo+Awqeg3YcwvXc+s1eyIwVgYJKwYBBAGCNxAEMUkwRzAzMQswCQYDVQQGEwJG STEOMAwGA1UEChMFTm9raWExFDASBgNVBAMTC05va2lhIEJJIENBAhAwflqlqTyUTLouYuUuwnLx MFgGCyqGSIb3DQEJEAILMUmgRzAzMQswCQYDVQQGEwJGSTEOMAwGA1UEChMFTm9raWExFDASBgNV BAMTC05va2lhIEJJIENBAhAwflqlqTyUTLouYuUuwnLxMGcGCSqGSIb3DQEJDzFaMFgwCgYIKoZI hvcNAwcwDgYIKoZIhvcNAwICAgCAMA0GCCqGSIb3DQMCAgFAMAcGBSsOAwIHMA0GCCqGSIb3DQMC AgEoMAcGBSsOAwIaMAoGCCqGSIb3DQIFMA0GCSqGSIb3DQEBAQUABIIBAKAu88zn4o5/jsouRms5 h0CBX84D9tApLhxKpVo+tjJXze78BdY595wPP+FCfYp6jnzzgyf5rD4Ld8WQys5jgce4y/dddUxZ ugRCY3jcsOAoz7gnxxkgffrkocxxyCz/o3TzQ/Munk10l7+EM22cA+0wa3osMULeKRxR1uOJhjSb XAqJ3Ezhn5fB/tjGqorMmMoiZN0372AzMnCVkbWnbGhRwRLf3eb2OSjAtBrthxiKzx4hgZw68M3x WDp93b+XNbwpJ4zqDjJ5o01dNlGKkUVaptiB0Fzg0/3PaR5xBSctXqPGQyIm7+LI1zZahSVRlfXk /b0eKv6Pisur2BY133kAAAAAAAA= ------=_NextPart_000_018E_01CC6EF1.76A832D0-- From ajs@anvilwalrusden.com Fri Sep 9 11:15: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 1C58421F8801 for ; Fri, 9 Sep 2011 11:15:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.569 X-Spam-Level: X-Spam-Status: No, score=-2.569 tagged_above=-999 required=5 tests=[AWL=0.030, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tPS-j4i3DMJF for ; Fri, 9 Sep 2011 11:15:09 -0700 (PDT) Received: from mail.yitter.info (mail.yitter.info [208.86.224.201]) by ietfa.amsl.com (Postfix) with ESMTP id F27DE21F87FA for ; Fri, 9 Sep 2011 11:15:08 -0700 (PDT) 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 12DBB1ECB41D for ; Fri, 9 Sep 2011 18:17:00 +0000 (UTC) Date: Fri, 9 Sep 2011 14:16:59 -0400 From: Andrew Sullivan To: mif@ietf.org Message-ID: <20110909181657.GB46494@shinkuro.com> References: <20110908204329.GN38973@shinkuro.com> <916CE6CF87173740BC8A2CE44309696202570894@008-AM1MPN1-032.mgdnok.nokia.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <916CE6CF87173740BC8A2CE44309696202570894@008-AM1MPN1-032.mgdnok.nokia.com> User-Agent: Mutt/1.5.21 (2010-09-15) Subject: Re: [mif] Last Call for MIF DNS server selection document 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, 09 Sep 2011 18:15:10 -0000 Hi, Thanks for your response. More inline. On Fri, Sep 09, 2011 at 10:07:46AM +0000, teemu.savolainen@nokia.com wrote: > > Is it better to talk about "DNS domain" or just "domain"? I think "domain" is fine, myself. > > However, the resolver SHOULD take into account > > different trust levels of pieces of DNS server selection information > > the resolver may have received from node's network interfaces. The > > resolver SHOULD prefer DNS servers of trusted interfaces. > > > > Why isn't this MUST? > > Because a node implementation might not want to care about security (at this > layer) for some reason. I mean it is of course easy to say why the node > really SHOULD care about trust, but the DNS server selection itself should > work just fine even if the node does not take security into account (it just > may result in unwanted DNS server being used when under attack, but maybe > said node is able to recover from that by some other means). I guess I don't think this is a 2119 SHOULD, then. If it's really just a matter of taste, it's not SHOULD, in my reading of the keywords. SHOULD means "you'd better have a pretty good reason not to do this", and I don't think "I don't wanna" qualifies. Perhaps MAY? > The idea is that the node by magic knows what interfaces can be trusted and > what cannot (trust2). Oh. That wasn't clear to me at all: I thought trust2 came from being able to validate the answers or else from having an authentecated and secure connection to the upstream resolver. > This makes me think about Brian's concern about "legitimizing" private > namespaces. If this document would state that only trusted interfaces can > configure DNS server selection rules, would that mitigate the "legitimizing" > concern as then this tool would not be used in environments where network > operator cannot configure nodes trust levels enough to make them request & > listen the configuration message? I.e. that might help limit usage of the > tool to scenarios where we have seen need for it. While I understand the "legitimizing" worry, I think the DNS community has been pig-headed about this in much the way the wider community once tried to respond to NAT: "Lalalalala I can't hear you." Even if we really hate it, private namespaces are a fact on the network. We can either tell people, "Here is how to do this bad thing in the least bad way possible," or we can endure the even worse ways that people think of to do that bad thing. So far, we seem to have been going for "endure", but I think it's a failure. Now, while I like this suggestion of yours, I worry about the potential to fail to address some use case we think we have. I haven't thought of a way it does, but maybe others can think about that too. > > I think the discussion just after Figure 4 about revealing information > about > > ongoing communications is total nonsense, and should be removed. > > Not everyone agrees on that one I believe. From folks following BroadBand > Forum the message in some past discussion was that they do not want to > broadcast DNS queries to all interfaces for this reason (I hope I recall > that right). Also I believe in classic split-tunnel VPN case corporate IT > would prefer not to provide all names to hostile hotspot DNS server, while > they may not be able to totally block that (e.g. host probably sends DNS > queries out also when VPN is not running). Yes, I know that lots of people think they can have a private namespace in their DNS servers, and that it won't leak. They're just wrong about this. Just because people believe in the Tooth Fairy doesn't mean that she exists, and just because people think that their private name space is secret because they only use it on the VPN doesn't mean that it really is secret. See above about bad ideas and even worse ones. I know of at least one large government where one department has 6 layers of NAT in an attempt to keep their sooper secret names inside the network. They still end up writing incident reports every time one of those names leaks, but leak they do. The DNS is _designed_ to leak this way. > Would it satisfy your concern if we drop the:" unnecessary reveal > information about ongoing communications" away? And hence would have just: > -- > The resolver SHOULD avoid sending queries to different interfaces in > parallel as that may waste resources such as energy. > -- Yeah, this works for me. > > That isn't true. > That piece of text came directly from you: Could be :) I'm not always terribly bright. > So something along lines: > -- > In the case of validated NXDOMAIN response being received from a DNS server > that can provide answers for the queried name a node MUST NOT accept > non-validated replies from other DNS servers (see Appendix B for > considerations related to multiple trust anchors). > -- Works for me. > > With new terms it says:"IPv6 networks should cover all the DNS domains..". > It means that configuration should be such that one could do reverse queries > successfully for all the domains that are configured (and vice versa). Hrm. I don't think this is a realistic requirement. First, there is no guarantee in the first place that the reverse tree will actually be maintained -- and there are people who have strong feelings that it is entirely optional. For your amusement, I can show you sometime the scourge marks I got from trying to get a draft through DNSOP that by last call said, in effect, "You can use the reverse tree, or not, depending on what you like." It still failed. But in any case, even if the reverse tree was fully maintained, the forward and reverse don't line up exactly. For instance, a CNAME in the forward tree is entirely likely not to be reflected in the reverse. I think you can probably cut this text (although I don't feel that strongly about it). > It should say that node must not select randomly, but use the preference > value on OPTION_DNS_SERVER_SELECT. If the preference in _SERVER_SELECT is > default (i.e. same preference for both), then the node SHALL use the server > received via _SERVER_SELECT option. I.e. if both options are present, DNS > server from OPTION_DNS_SERVERS is used by default only if > OPTION_DNS_SERVER_SELECT contains low default preference. Ok, I see. > "If both OPTION_DNS_SERVERS and OPTION_DNS_SERVER_SELECT contain the same > DNS server(s) IPv6 address(es), a node SHALL add the same address of a DNS > server to the server list only once. " ? Yes. > > In section 4.6., I think that it needs to be made clear that a bare name > is first > > treated as a pre-DNS hostname before it encounters the DNS search list. > > (Frankly, that entire mechanism is broken, and it would suit me just fine > if the > > document said, "This algorithm is incompatible with the DNS search list > and > > the OPTION_DOMAIN_LIST feature." But I know people would scream about > > it. It's still broken.) > > I'm not sure what you mean with "pre-DNS" hostname.. I.e. an RFC 952 hostname. The DNS search list is really a hack that was partly an attempt to make things work more like the old host name syntax (and partly to give local scoping). When you put something in /etc/hosts, what you're really doing is preventing the DNS from getting involved by using the hostname mechanism. Unfortunately, no naming technlogy on the Internet ever goes away. It just gets more cruft layered on top. > > In 4.7, what about other things that could do context-sensitive referrals, > like > > SRV? > > Hmm.. what should we write about those? Any record type that contains domain > names shall fall under this server selection logic? That would include NS records. But actually, now that I think about it, this should probably just say that any follow-up queries that are performed on the basis of an answer received on an interface MUST continue to use the same interface, irrespective of the DNS server selection settings on any other interface. This is required because of the assumption that different DNS servers possibly provide different namespaces. (I want to go lie down after having written that.) > Would it be ok then if this is dropped: > -- > Another downside is revealing to all DNS servers the names a > host is connecting to. > For example, a DNS server of a public hotspot could learn all > the private names host > is trying to connect on other interfaces. > -- Yes, I'd get rid of it. -- Andrew Sullivan ajs@anvilwalrusden.com From brian.e.carpenter@gmail.com Fri Sep 9 13:59: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 66A6C21F869E for ; Fri, 9 Sep 2011 13:59:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.584 X-Spam-Level: X-Spam-Status: No, score=-103.584 tagged_above=-999 required=5 tests=[AWL=0.015, 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 qPAqi1xNjk2D for ; Fri, 9 Sep 2011 13:59:35 -0700 (PDT) Received: from mail-fx0-f44.google.com (mail-fx0-f44.google.com [209.85.161.44]) by ietfa.amsl.com (Postfix) with ESMTP id 36ED321F8660 for ; Fri, 9 Sep 2011 13:59:35 -0700 (PDT) Received: by fxe6 with SMTP id 6so3136897fxe.31 for ; Fri, 09 Sep 2011 14:01:30 -0700 (PDT) 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=EwJAy+9zEACrnVv3q6XNFZaxJ4brOap2oAfk1TJFE4E=; b=bH/pGK1XMpfpxl37FGmPfJN0vm0RnqAsYraEsDShjW7377bQSClzXx3KfV8dPMPpjj qiZfStnhofOXSivcclc4qWK5lArq3NlkQDZ2kAPO1QUp56L08/zHehYEu2mY/um6o+GE aE2UPCdi1q0Rr0cup1gS+7jzLCpqoYF+za60g= Received: by 10.223.58.139 with SMTP id g11mr317380fah.14.1315602090540; Fri, 09 Sep 2011 14:01:30 -0700 (PDT) Received: from [10.1.1.4] ([121.98.251.219]) by mx.google.com with ESMTPS id l21sm3415279fac.8.2011.09.09.14.01.25 (version=SSLv3 cipher=OTHER); Fri, 09 Sep 2011 14:01:29 -0700 (PDT) Message-ID: <4E6A7E9F.5070706@gmail.com> Date: Sat, 10 Sep 2011 09:01:19 +1200 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: <4E683F9B.7020905@gmail.com> <916CE6CF87173740BC8A2CE4430969620256F33F@008-AM1MPN1-032.mgdnok.nokia.com> <4E692D62.5080902@gmail.com> <916CE6CF87173740BC8A2CE443096962025704BA@008-AM1MPN1-032.mgdnok.nokia.com> In-Reply-To: <916CE6CF87173740BC8A2CE443096962025704BA@008-AM1MPN1-032.mgdnok.nokia.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: mif@ietf.org, margaretw42@gmail.com, moore@network-heretics.com, denghui02@hotmail.com Subject: Re: [mif] Last Call for MIF DNS server selection document 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, 09 Sep 2011 20:59:36 -0000 Teemu, I think the reference to multiple namespaces in the requirements draft is too short to really generate discussion, and in any case it's only an Informational document. However, I was trying to be quite careful in what I wrote. >> if the network administrator just does not want >> names to be resolvable on the public Internet. That is one thing, and an *ambiguous* namespace is another. I guess I would like to see some MUSTs or MUST NOTs in the MIF draft or elsewhere that make it clear that any domains that are not globally resolvable must nevertheless be globally unique. That needs to be expressed a bit more precisely and there might have to be an exception for .local. However, if a host can see a DNS server from example.com, a rule could be: that server MUST NOT resolve any domains that are not globally resolvable and are not subdomains of example.com. I am sure there is a better way to express this. It just needs to guarantee a strict hierarchy in the namespace. Regards Brian Carpenter On 2011-09-09 18:15, teemu.savolainen@nokia.com wrote: > Keith, Brian, > > The problem this draft is addressing has been acknowledged in the > draft-ietf-mif-problem-statement-15.txt section 4.1. The problem statement > is already at the RFC editor's queue. > > Based on the acceptance of the problem, this WG was chartered with a goal > of: > -- > 1) DNS server selection solution: a specification for describing a way > for a network to communicate to nodes information required to perform > advanced DNS server selection at name resolution request granularity > in scenarios involving multiple namespaces. The specification shall > describe the information to be delivered for nodes and the protocol to > be used for delivery. > -- > > This draft is the solution that has been accepted as a WG work item. > > The topic has been discussed for a quite long time and I don't think there > are any such surprises you refer to (except perhaps for individuals who just > now start following the work). > > Furthermore, I cannot easily buy the argument (I hope I read your points > right) that a solution should not be developed for an acknowledged problem > out of fear of "legitimizing" the problematic behavior. > > I do agree BCP or similar might be nice to have, but would such BCP really > make any difference e.g. if the network administrator just does not want > names to be resolvable on the public Internet. > > Best regards, > > Teemu > >> -----Original Message----- >> From: ext Keith Moore [mailto:moore@network-heretics.com] >> Sent: 09. syyskuuta 2011 01:22 >> To: Brian E Carpenter >> Cc: Savolainen Teemu (Nokia-CTO/Tampere); margaretw42@gmail.com; >> mif@ietf.org; denghui02@hotmail.com >> Subject: Re: [mif] Last Call for MIF DNS server selection document >> >> >> On Sep 8, 2011, at 5:02 PM, Brian E Carpenter wrote: >> >>> Teemu, >>> >>> On 2011-09-08 18:16, teemu.savolainen@nokia.com wrote: >>>> Brian, >>>> >>>> Thank you for review. I agree it is a good idea to consult those WGs >>>> (and DHC as well I suppose), but what makes you so concerned of this >> text: >>>>>> In deployments where multiple namespaces are present, selection of >>>>>> correct route and destination and source addresses for the actual > IP >>>>>> connection is crucial as well, as the resolved destination's IP >>>>>> addresses may be only usable on the network interface over which > the >>>>>> name was resolved on. >>>> I wrote that as I thought it would be useful to talk a little about >>>> bigger picture of some deployments (like in the demo we had few IETFs >>>> back - without presence of DHCPv6 more specific route options the >>>> system would not have worked properly) .. but if that text creates an >>>> unwanted link or dependency or confusion, I think we can drop the >>>> text just as well and focus on the document just to the new options >>>> and leave this kind of additional system-level consideration out of the >> doc. >>> As Andrew pointed out, the draft starts >>> >>> "...from the premise that operators sometimes include private >>> namespaces in the answers they provide from DNS servers, and that >>> those private namespaces are at least as useful to clients as the >>> answers from the public DNS." >>> >>> I believe that you will discover during IETF LC that many people have >>> strong feelings about this premise; as Andrew implied, conceptually >>> the DNS is a unified global namespace. This draft is a backdoor way of >>> legitimising an ambiguous namespace. I don't think that will have an >>> easy time in IETF LC, especially if it is dropped as a surprise into >>> the DNS community. It's your choice, but I would suggest that exposing >>> it to the DNS WGs now would be a smart move. >> >> Frankly, I consider this very nearly a showstopper, in the sense that MIF >> needs an extremely good reason to do this, and I haven't seen even a hint > of >> such a reason. You may recall that I raised this issue in Quebec, > though >> perhaps I was too polite about it. (Since I hadn't read the document yet, > and >> was coming late into the discussion, I wanted to give the group the > benefit >> of the doubt.) >> >> I'm quite surprised that MIF was able to get this far with the document >> without the issue being raised. I'm shocked that this issue appears to > be a >> surprise to the WG. I think that by itself is likely a sign of a serious > process or >> management failure. >> >> >>> It goes further. The IETF has a longstanding issue with technology >>> that encourages walled gardens. See for example RFC 3002. I think >>> there will be quite some discussion, and this will definitely happen >>> even if you try to remove the "system-level" considerations, because >>> they are strongly implied anyway. >>> >>> Personally I'm not sure what I think about this, but it needs to be >>> discussed in the community IMHO. >> +1. >> >> Keith > From moore@network-heretics.com Fri Sep 9 14:27: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 EFA2021F86A2; Fri, 9 Sep 2011 14:27:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.468 X-Spam-Level: X-Spam-Status: No, score=-3.468 tagged_above=-999 required=5 tests=[AWL=0.130, 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 pj++IVceFIuT; Fri, 9 Sep 2011 14:27:33 -0700 (PDT) Received: from out4.smtp.messagingengine.com (out4.smtp.messagingengine.com [66.111.4.28]) by ietfa.amsl.com (Postfix) with ESMTP id ADF5A21F85A1; Fri, 9 Sep 2011 14:27:33 -0700 (PDT) Received: from compute1.internal (compute1.nyi.mail.srv.osa [10.202.2.41]) by gateway1.nyi.mail.srv.osa (Postfix) with ESMTP id 15C8428D3B; Fri, 9 Sep 2011 17:29:29 -0400 (EDT) Received: from frontend2.nyi.mail.srv.osa ([10.202.2.161]) by compute1.internal (MEProxy); Fri, 09 Sep 2011 17:29:29 -0400 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=u9o N/ussW8+RA+fehQ7gUJni52A=; b=IYgukW61tsXTcbvrHFNkDE7TceXulpUXlxK yYQxnyI45+G+Q0yAhmHmukEj+z2O46UoYTo2pQRDMqUstEC/YnBCBjtLws4PyUjQ nCEVKnJ0VC4HnogFj4eoFgnHUOtUZQkhktycm1fMFjvR0q5y6Upmz3H3zD2SCZeE GHWAF3rI= X-Sasl-enc: ZoKNQfXcCFJS8tQmIAc/kdODqDUJQIbXI6YfO5am5cqV 1315603767 Received: from host65-16-145-177.birch.net (host65-16-145-177.birch.net [65.16.145.177]) by mail.messagingengine.com (Postfix) with ESMTPA id B158D9E027A; Fri, 9 Sep 2011 17:29:26 -0400 (EDT) Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: multipart/alternative; boundary=Apple-Mail-1-141627720 From: Keith Moore In-Reply-To: <916CE6CF87173740BC8A2CE443096962025704BA@008-AM1MPN1-032.mgdnok.nokia.com> Date: Fri, 9 Sep 2011 17:29:20 -0400 Message-Id: <0A7B9663-0C40-4D19-BDBE-7EB72430D47D@network-heretics.com> References: <4E683F9B.7020905@gmail.com> <916CE6CF87173740BC8A2CE4430969620256F33F@008-AM1MPN1-032.mgdnok.nokia.com> <4E692D62.5080902@gmail.com> <916CE6CF87173740BC8A2CE443096962025704BA@008-AM1MPN1-032.mgdnok.nokia.com> To: X-Mailer: Apple Mail (2.1084) Cc: mif@ietf.org, Margaret Wasserman , denghui02@hotmail.com, The IESG Subject: Re: [mif] Last Call for MIF DNS server selection document 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, 09 Sep 2011 21:27:35 -0000 --Apple-Mail-1-141627720 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii On Sep 9, 2011, at 2:15 AM, = wrote: > Keith, Brian, >=20 > The problem this draft is addressing has been acknowledged in the > draft-ietf-mif-problem-statement-15.txt section 4.1. The problem = statement > is already at the RFC editor's queue. >=20 > Based on the acceptance of the problem, this WG was chartered with a = goal > of: > -- > 1) DNS server selection solution: a specification for describing a = way > for a network to communicate to nodes information required to perform > advanced DNS server selection at name resolution request granularity > in scenarios involving multiple namespaces. The specification shall > describe the information to be delivered for nodes and the protocol = to > be used for delivery. Selecting a name server is one thing. Standardizing a behavior that = assumes that DNS name servers are specific to networks, is something = else entirely. It's a violation of the DNS architecture, which clearly = assumes that DNS queries are location-independent. (Otherwise, it would = not allow caching of query results without some awareness of the scope = in which they are valid.) I realize that this is a slippery slope that IETF and the Internet have = been sliding down for many years, given two-faced DNS, SiteFinder and = other criminal acts, DNS interception proxies imposed by ISPs, certain = dubious uses of LLMNR, DNS64, and several other things that break the = architecture. DNS is almost as polluted these days as IPv4 is. But = at some point it goes too far. =20 (It's an even worse problem with DNS than with IPv4, because by now = everyone should realize that IPv4 is on the way out, but we're stuck = with DNS for the foreseeable future.) Sometimes I think that people forget that the goal of these efforts is = (or should be) to provide a predictable environment for applications. = Part of being "predictable" is location-independence. An application = shouldn't have to act differently in one part of the network, than in = another part of the network, in order to function properly. One of the implications is that a DNS name needs to mean the same thing, = even to the point of having the same RRs associated with it, from = everywhere on the network. =20 Now, some may think that it's mostly harmless, or even beneficial, to = say that addresses that aren't reachable from some part of the network = need not appear in DNS responses received in that part of the network. = Some people may think that v4-v6 transition is so important that it = warrants having DNS proxies lie to applications about what a domain's = resource records are. Then again, some parties think that their = ability to sell advertisements or to work around customer = misconfiguration of hosts is so important that they can also lie about a = domain's resource records, even though that practice breaks = applications. Again, it's a slippery slope. IMO, all of this behavior = is broken, and none of this behavior should be considered acceptable for = standardization according to RFC 2026's criteria ("no known technical = omissions"). =20 I realize that MIF was just trying to recognize "reality" of NATted = networks, two-faced DNS, and other hacks. Sometimes that's appropriate = when designing an API. But such second-guessing can also degrade the = predictability of the network environment as viewed by applications. =20= IETF keeps moving away from an Internet that is _engineered_ to work = because the interactions between components have been analyzed and found = to work correctly, to an Internet that relies on guesswork, empirical = measurement, incomplete analysis, and luck in order to allow = applications to work. Again, the problem isn't at all specific to = MIF, but THIS NEEDS TO STOP. =20 > This draft is the solution that has been accepted as a WG work item. Indeed, that's precisely the problem. How did the WG go so far down = this path without significant pushback, or without the architectural = question being raised and discussed in a wider or more appropriate = forum? Why was this decision not subject to extensive review, not just = within DNS WGs but also cross-area review, long before the MIF WG made = its decision? > The topic has been discussed for a quite long time and I don't think = there > are any such surprises you refer to (except perhaps for individuals = who just > now start following the work). Again, why should applications developers who might be concerned about = pollution of DNS and harm to the DNS architecture, have to follow the = work of the MIF working group in order to do damage control? > Furthermore, I cannot easily buy the argument (I hope I read your = points > right) that a solution should not be developed for an acknowledged = problem > out of fear of "legitimizing" the problematic behavior. You might not buy it, but I do. Again, MIF isn't the first = contributor to the problem, so I don't exclusively blame that WG. I see = it as more of a structural and process problem within IETF - IETF is = frequently failing to maintain the Internet architecture and hoping that = somehow everything will work out. But I also think that the MIF work = needs to be fixed somehow to avoid encouraging further pollution of DNS. Keith --Apple-Mail-1-141627720 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii teemu.savolainen@nokia.com&= gt; <teemu.savolainen@nokia.com&= gt; wrote:
Keith, Brian,

The problem this draft is = addressing has been acknowledged in = the
draft-ietf-mif-problem-statement-15.txt section 4.1. The problem = statement
is already at the RFC editor's queue.

Based on the = acceptance of the problem, this WG was chartered with a = goal
of:
--
 1) DNS server selection solution: a = specification for describing a way
 for a network to = communicate to nodes information required to perform
 advanced = DNS server selection at name resolution request granularity
 in = scenarios involving multiple namespaces. The specification shall
=  describe the information to be delivered for nodes and the = protocol to
 be used for = delivery.

Selecting a name server = is one thing.  Standardizing a behavior that assumes that DNS name = servers are specific to networks, is something else entirely.  It's = a violation of the DNS architecture, which clearly assumes that DNS = queries are location-independent.  (Otherwise, it would not allow = caching of query results without some awareness of the scope in which = they are valid.)

I realize that this is a = slippery slope that IETF and the Internet have been sliding down for = many years, given two-faced DNS,  SiteFinder and other criminal = acts, DNS interception proxies imposed by ISPs, certain dubious uses of = LLMNR, DNS64, and several other things that break the architecture. =   DNS is almost as polluted these days as IPv4 is.   But at = some point it goes too far.   

(It's = an even worse problem with DNS than with IPv4, because by now everyone = should realize that IPv4 is on the way out, but we're stuck with DNS for = the foreseeable future.)

Sometimes I think that = people forget that the goal of these efforts is (or should be) to = provide a predictable environment for applications.  Part of being = "predictable" is location-independence.  An application shouldn't = have to act differently in one part of the network, than in another part = of the network, in order to function = properly.

One of the implications is that a DNS = name needs to mean the same thing, even to the point of having the same = RRs associated with it, from everywhere on the network. =  

Now, some may think that it's mostly = harmless, or even beneficial, to say that addresses that aren't = reachable from some part of the network need not appear in DNS responses = received in that part of the network.   Some people may think that = v4-v6 transition is so important that it warrants having DNS proxies lie = to applications about what a domain's resource records are.   Then = again, some parties think that their ability to sell advertisements or = to work around customer misconfiguration of hosts is so important that = they can also lie about a domain's resource records, even though that = practice breaks applications.   Again, it's a slippery slope. =  IMO, all of this behavior is broken, and none of this behavior = should be considered acceptable for standardization according to RFC = 2026's criteria ("no known technical omissions"). =  

I realize that MIF was just trying to = recognize "reality" of NATted networks, two-faced DNS, and other hacks. =   Sometimes that's appropriate when designing an API.   =  But such second-guessing can also degrade the predictability of = the network environment as viewed by applications.   =  

IETF keeps moving away from an Internet = that is _engineered_ to work because the interactions between components = have been analyzed and found to work correctly, to an Internet that = relies on guesswork, empirical measurement, incomplete analysis, and = luck in order to allow applications to work.    Again, the = problem isn't at all specific to MIF, but THIS NEEDS TO STOP. =  

This = draft is the solution that has been accepted as a WG work = item.

Indeed, that's precisely the = problem.    How did the WG go so far down this path without = significant pushback, or without the architectural question being raised = and discussed in a wider or more appropriate forum?  Why was this = decision not subject to extensive review, not just within DNS WGs but = also cross-area review, long before the MIF WG made its = decision?

The = topic has been discussed for a quite long time and I don't think = there
are any such surprises you refer to (except perhaps for = individuals who just
now start following the = work).

Again, why should = applications developers who might be concerned about pollution of DNS = and harm to the DNS architecture, have to follow the work of the MIF = working group in order to do damage = control?

Furthermore, = I cannot easily buy the argument (I hope I read your points
right) = that a solution should not be developed for an acknowledged = problem
out of fear of "legitimizing" the problematic = behavior.

You might not buy it, but = I do.    Again, MIF isn't the first contributor to the = problem, so I don't exclusively blame that WG.  I see it as more of = a structural and process problem within IETF - IETF is frequently = failing to maintain the Internet architecture and hoping that somehow = everything will work out.  But I also think that the MIF work needs = to be fixed somehow to avoid encouraging further pollution of = DNS.

Keith


= --Apple-Mail-1-141627720-- From ajs@anvilwalrusden.com Fri Sep 9 15:59: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 2439711E8081; Fri, 9 Sep 2011 15:59:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.569 X-Spam-Level: X-Spam-Status: No, score=-2.569 tagged_above=-999 required=5 tests=[AWL=0.030, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iXrwXHtmrmT1; Fri, 9 Sep 2011 15:59:22 -0700 (PDT) Received: from mail.yitter.info (mail.yitter.info [208.86.224.201]) by ietfa.amsl.com (Postfix) with ESMTP id 3712C11E8073; Fri, 9 Sep 2011 15:59:22 -0700 (PDT) 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 0466F1ECB41D; Fri, 9 Sep 2011 23:01:15 +0000 (UTC) Date: Fri, 9 Sep 2011 19:01:15 -0400 From: Andrew Sullivan To: mif@ietf.org, iesg@ietf.org Message-ID: <20110909230115.GG46494@shinkuro.com> References: <4E683F9B.7020905@gmail.com> <916CE6CF87173740BC8A2CE4430969620256F33F@008-AM1MPN1-032.mgdnok.nokia.com> <4E692D62.5080902@gmail.com> <916CE6CF87173740BC8A2CE443096962025704BA@008-AM1MPN1-032.mgdnok.nokia.com> <0A7B9663-0C40-4D19-BDBE-7EB72430D47D@network-heretics.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <0A7B9663-0C40-4D19-BDBE-7EB72430D47D@network-heretics.com> User-Agent: Mutt/1.5.21 (2010-09-15) Subject: Re: [mif] Last Call for MIF DNS server selection document 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, 09 Sep 2011 22:59:23 -0000 On Fri, Sep 09, 2011 at 05:29:20PM -0400, Keith Moore wrote: > > Selecting a name server is one thing. Standardizing a behavior that > assumes that DNS name servers are specific to networks, is something > else entirely. It's a violation of the DNS architecture, which > clearly assumes that DNS queries are location-independent. > (Otherwise, it would not allow caching of query results without some > awareness of the scope in which they are valid.) First, I fully agree with this. At the same time, in point of fact we walked off the cliff some time ago. > I realize that this is a slippery slope that IETF and the Internet > have been sliding down for many years, given two-faced DNS, > SiteFinder and other criminal acts, DNS interception proxies imposed > by ISPs, certain dubious uses of LLMNR, DNS64, and several other > things that break the architecture. DNS is almost as polluted these > days as IPv4 is. But at some point it goes too far. The problem that I see is that we _already_ see techniques in the wild where people have broken the architecture, and are charging ahead and doing their thing. We can try to say, "This is too far," but we'll be right back where we were with NAT many years ago. Once we started split-brain DNS, we were just doomed to the eventual state of affairs where the exact same question asked of servers in different networks would give different answers. We can't change the past. > Indeed, that's precisely the problem. How did the WG go so far down this path without significant pushback, or without the architectural question being raised and discussed in a wider or more appropriate forum? Why was this decision not subject to extensive review, not just within DNS WGs but also cross-area review, long before the MIF WG made its decision? Actually, the DNS Directorate has been paying active attention to this work, and part of the reason I did the review I did was precisely because of that interest. The problem we DNS weenies have is that we know it's a horrible disastrous mess, but people are _doing it anyway_, and the only option left to us now is to try to contain damage. I hate DNS64. I hate this server selection stuff, too. But no matter how much I shout at the tide, still it comes in. Better that I should try to help build the dike. -- Andrew Sullivan ajs@anvilwalrusden.com From brian.e.carpenter@gmail.com Fri Sep 9 16:31: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 2959121F8586; Fri, 9 Sep 2011 16:31:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.585 X-Spam-Level: X-Spam-Status: No, score=-103.585 tagged_above=-999 required=5 tests=[AWL=0.014, 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 n5Aamzr23iPV; Fri, 9 Sep 2011 16:31:43 -0700 (PDT) Received: from mail-fx0-f44.google.com (mail-fx0-f44.google.com [209.85.161.44]) by ietfa.amsl.com (Postfix) with ESMTP id B415F21F8564; Fri, 9 Sep 2011 16:31:42 -0700 (PDT) Received: by fxe6 with SMTP id 6so3225541fxe.31 for ; Fri, 09 Sep 2011 16:33:38 -0700 (PDT) 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=Ryr8O4nCb00n+SKTBWcsXjgeu2bgaW3cmMLCMN0/Tis=; b=jWHE7w+irSyMCmiuTy78GCAD5exInEGq/0lInWtvE7mRkZJHY1Pye9kU+uGEiTHNEU ccbGJqeniklypEnmh6ISX8yBWdd4KNZi9ptNuWRuTpOKQjYHs+1o1Ml3elVS20zvI02f zxAHTF64KrkohxVCTy7GLbhMEI5g+WDr/hUZg= Received: by 10.223.39.193 with SMTP id h1mr590962fae.135.1315611218224; Fri, 09 Sep 2011 16:33:38 -0700 (PDT) Received: from [10.1.1.4] ([121.98.251.219]) by mx.google.com with ESMTPS id d23sm3579918fam.4.2011.09.09.16.33.33 (version=SSLv3 cipher=OTHER); Fri, 09 Sep 2011 16:33:37 -0700 (PDT) Message-ID: <4E6AA248.6000406@gmail.com> Date: Sat, 10 Sep 2011 11:33:28 +1200 From: Brian E Carpenter Organization: University of Auckland User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: Andrew Sullivan References: <4E683F9B.7020905@gmail.com> <916CE6CF87173740BC8A2CE4430969620256F33F@008-AM1MPN1-032.mgdnok.nokia.com> <4E692D62.5080902@gmail.com> <916CE6CF87173740BC8A2CE443096962025704BA@008-AM1MPN1-032.mgdnok.nokia.com> <0A7B9663-0C40-4D19-BDBE-7EB72430D47D@network-heretics.com> <20110909230115.GG46494@shinkuro.com> In-Reply-To: <20110909230115.GG46494@shinkuro.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: mif@ietf.org, iesg@ietf.org Subject: Re: [mif] Last Call for MIF DNS server selection document 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, 09 Sep 2011 23:31:44 -0000 > doomed to the eventual state of affairs > where the exact same question asked of servers in different networks > would give different answers. We can't change the past. As long as the reply for a given query is always NXDOMAIN *except* for the one name server serving the particular offshoot of the namespace that the location-dependent domain is in, we have not broken the uniqueness of the namespace. Hence the suggestion in my previous message, quoted here for the benefit of the IESG that someone added in CC: "I guess I would like to see some MUSTs or MUST NOTs in the MIF draft or elsewhere that make it clear that any domains that are not globally resolvable must nevertheless be globally unique. That needs to be expressed a bit more precisely and there might have to be an exception for .local. However, if a host can see a DNS server from example.com, a rule could be: that server MUST NOT resolve any domains that are not globally resolvable and are not subdomains of example.com." Regards Brian Carpenter On 2011-09-10 11:01, Andrew Sullivan wrote: > On Fri, Sep 09, 2011 at 05:29:20PM -0400, Keith Moore wrote: >> Selecting a name server is one thing. Standardizing a behavior that >> assumes that DNS name servers are specific to networks, is something >> else entirely. It's a violation of the DNS architecture, which >> clearly assumes that DNS queries are location-independent. >> (Otherwise, it would not allow caching of query results without some >> awareness of the scope in which they are valid.) > > First, I fully agree with this. At the same time, in point of fact we > walked off the cliff some time ago. > >> I realize that this is a slippery slope that IETF and the Internet >> have been sliding down for many years, given two-faced DNS, >> SiteFinder and other criminal acts, DNS interception proxies imposed >> by ISPs, certain dubious uses of LLMNR, DNS64, and several other >> things that break the architecture. DNS is almost as polluted these >> days as IPv4 is. But at some point it goes too far. > > The problem that I see is that we _already_ see techniques in the wild > where people have broken the architecture, and are charging ahead and > doing their thing. We can try to say, "This is too far," but we'll be > right back where we were with NAT many years ago. Once we started > split-brain DNS, we were just doomed to the eventual state of affairs > where the exact same question asked of servers in different networks > would give different answers. We can't change the past. > >> Indeed, that's precisely the problem. How did the WG go so far down this path without significant pushback, or without the architectural question being raised and discussed in a wider or more appropriate forum? Why was this decision not subject to extensive review, not just within DNS WGs but also cross-area review, long before the MIF WG made its decision? > > Actually, the DNS Directorate has been paying active attention to this > work, and part of the reason I did the review I did was precisely > because of that interest. The problem we DNS weenies have is that we > know it's a horrible disastrous mess, but people are _doing it > anyway_, and the only option left to us now is to try to contain > damage. I hate DNS64. I hate this server selection stuff, too. But > no matter how much I shout at the tide, still it comes in. Better > that I should try to help build the dike. > > > From moore@network-heretics.com Fri Sep 9 17:00: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 330D221F85F2; Fri, 9 Sep 2011 17:00:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.47 X-Spam-Level: X-Spam-Status: No, score=-3.47 tagged_above=-999 required=5 tests=[AWL=0.129, 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 zPOPbPFTpBT1; Fri, 9 Sep 2011 17:00:36 -0700 (PDT) Received: from out4.smtp.messagingengine.com (out4.smtp.messagingengine.com [66.111.4.28]) by ietfa.amsl.com (Postfix) with ESMTP id 2CCAB21F85F1; Fri, 9 Sep 2011 17:00:36 -0700 (PDT) Received: from compute5.internal (compute5.nyi.mail.srv.osa [10.202.2.45]) by gateway1.nyi.mail.srv.osa (Postfix) with ESMTP id 4D82924DB8; Fri, 9 Sep 2011 20:02:32 -0400 (EDT) Received: from frontend1.nyi.mail.srv.osa ([10.202.2.160]) by compute5.internal (MEProxy); Fri, 09 Sep 2011 20:02:32 -0400 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=ylUBqg2hcoOobu62KFOJ5J7PWHc=; b=kZ l7sWcaWtr0v6BnAHdMIp+0reHCSgMdzDrOra9RMM3E/3jhFWvGFSIV7/2Zge6pIK rs7N66BqK7jQAU031KB1ylQ5CMrSGiKYijyrU7xoQlzLAu+7c69Fhb2RrJdBDRWn F5ERrpHrRIhH7CHRAsuZjJLIKw3W4MR+oZKI2ID8s= X-Sasl-enc: EcLEC+OpPssHsyOfidBOwebQT6/R57JL1qD9ZAJg6Sjb 1315612951 Received: from host65-16-145-177.birch.net (host65-16-145-177.birch.net [65.16.145.177]) by mail.messagingengine.com (Postfix) with ESMTPA id 0A5107204B8; Fri, 9 Sep 2011 20:02:30 -0400 (EDT) Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Keith Moore In-Reply-To: <20110909230115.GG46494@shinkuro.com> Date: Fri, 9 Sep 2011 20:02:25 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: <10C27AF2-A9A9-4161-BC94-3964E725DA9D@network-heretics.com> References: <4E683F9B.7020905@gmail.com> <916CE6CF87173740BC8A2CE4430969620256F33F@008-AM1MPN1-032.mgdnok.nokia.com> <4E692D62.5080902@gmail.com> <916CE6CF87173740BC8A2CE443096962025704BA@008-AM1MPN1-032.mgdnok.nokia.com> <0A7B9663-0C40-4D19-BDBE-7EB72430D47D@network-heretics.com> <20110909230115.GG46494@shinkuro.com> To: Andrew Sullivan X-Mailer: Apple Mail (2.1084) Cc: mif@ietf.org, iesg@ietf.org Subject: Re: [mif] Last Call for MIF DNS server selection document 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, 10 Sep 2011 00:00:37 -0000 On Sep 9, 2011, at 7:01 PM, Andrew Sullivan wrote: > On Fri, Sep 09, 2011 at 05:29:20PM -0400, Keith Moore wrote: >>=20 >> Selecting a name server is one thing. Standardizing a behavior that >> assumes that DNS name servers are specific to networks, is something >> else entirely. It's a violation of the DNS architecture, which >> clearly assumes that DNS queries are location-independent. >> (Otherwise, it would not allow caching of query results without some >> awareness of the scope in which they are valid.) >=20 > First, I fully agree with this. At the same time, in point of fact we > walked off the cliff some time ago. Who's this "we" of which you speak? :) >> I realize that this is a slippery slope that IETF and the Internet >> have been sliding down for many years, given two-faced DNS, >> SiteFinder and other criminal acts, DNS interception proxies imposed >> by ISPs, certain dubious uses of LLMNR, DNS64, and several other >> things that break the architecture. DNS is almost as polluted these >> days as IPv4 is. But at some point it goes too far. >=20 > The problem that I see is that we _already_ see techniques in the wild > where people have broken the architecture, and are charging ahead and > doing their thing. We can try to say, "This is too far," but we'll be > right back where we were with NAT many years ago. Once we started > split-brain DNS, we were just doomed to the eventual state of affairs > where the exact same question asked of servers in different networks > would give different answers. We can't change the past.=20 >=20 >> Indeed, that's precisely the problem. How did the WG go so far = down this path without significant pushback, or without the = architectural question being raised and discussed in a wider or more = appropriate forum? Why was this decision not subject to extensive = review, not just within DNS WGs but also cross-area review, long before = the MIF WG made its decision? >=20 > Actually, the DNS Directorate has been paying active attention to this > work, and part of the reason I did the review I did was precisely > because of that interest. The problem we DNS weenies have is that we > know it's a horrible disastrous mess, but people are _doing it > anyway_, and the only option left to us now is to try to contain > damage. I hate DNS64. I hate this server selection stuff, too. But > no matter how much I shout at the tide, still it comes in. Better > that I should try to help build the dike. People often do things that violate the standards. That doesn't mean = that IETF should endorse such practices. Nor does it mean that IETF = should ignore them. Sometimes when people do things that violate the standards, it's a sign = of a deficiency in the architecture that should be remedied. And = sometimes it means that they're just being shortsighted and what IETF = needs to do is to say "here's why this is a Bad Idea". Keith =20= From moore@network-heretics.com Fri Sep 9 17:02:05 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 BF08721F8678; Fri, 9 Sep 2011 17:02:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.47 X-Spam-Level: X-Spam-Status: No, score=-3.47 tagged_above=-999 required=5 tests=[AWL=0.129, 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 oReZAmnwx-R1; Fri, 9 Sep 2011 17:02:05 -0700 (PDT) Received: from out4.smtp.messagingengine.com (out4.smtp.messagingengine.com [66.111.4.28]) by ietfa.amsl.com (Postfix) with ESMTP id 4EBEB21F84B1; Fri, 9 Sep 2011 17:02:05 -0700 (PDT) Received: from compute4.internal (compute4.nyi.mail.srv.osa [10.202.2.44]) by gateway1.nyi.mail.srv.osa (Postfix) with ESMTP id 8351D24DFC; Fri, 9 Sep 2011 20:04:01 -0400 (EDT) Received: from frontend1.nyi.mail.srv.osa ([10.202.2.160]) by compute4.internal (MEProxy); Fri, 09 Sep 2011 20:04:01 -0400 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=2bGyu9Wd2xskmFdP6w7gQmG6lMo=; b=ZX RIe49AAEySXtRLcxihkDGzg7zSh8ME8VxNRh/a+TWsVntEGHiRj4fpv9HVTCeF8Q JSos6I/KYl526fm9SM/qrDD7NOq0WYYKGubEbxTXs4/DJa+Efo9q0OldURQOw5kA WRMvlR/ei8Q/1WFj2JVmteL6XYzGfuklPaD5jkbv4= X-Sasl-enc: I0KSVIUi8RRXoRAIwZcG2VBJ/3YKU8NqT+qRhoL26ElE 1315613041 Received: from host65-16-145-177.birch.net (host65-16-145-177.birch.net [65.16.145.177]) by mail.messagingengine.com (Postfix) with ESMTPA id 4796D720519; Fri, 9 Sep 2011 20:04:00 -0400 (EDT) Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Keith Moore In-Reply-To: <4E6AA248.6000406@gmail.com> Date: Fri, 9 Sep 2011 20:03:54 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: <4D854606-64C6-4F7F-81A1-B15F1054E8BE@network-heretics.com> References: <4E683F9B.7020905@gmail.com> <916CE6CF87173740BC8A2CE4430969620256F33F@008-AM1MPN1-032.mgdnok.nokia.com> <4E692D62.5080902@gmail.com> <916CE6CF87173740BC8A2CE443096962025704BA@008-AM1MPN1-032.mgdnok.nokia.com> <0A7B9663-0C40-4D19-BDBE-7EB72430D47D@network-heretics.com> <20110909230115.GG46494@shinkuro.com> <4E6AA248.6000406@gmail.com> To: Brian E Carpenter X-Mailer: Apple Mail (2.1084) Cc: mif@ietf.org, iesg@ietf.org Subject: Re: [mif] Last Call for MIF DNS server selection document 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, 10 Sep 2011 00:02:05 -0000 On Sep 9, 2011, at 7:33 PM, Brian E Carpenter wrote: >> doomed to the eventual state of affairs >> where the exact same question asked of servers in different networks >> would give different answers. We can't change the past.=20 >=20 > As long as the reply for a given query is always NXDOMAIN > *except* for the one name server serving the particular offshoot > of the namespace that the location-dependent domain is in, > we have not broken the uniqueness of the namespace. Actually, I disagree. NXDOMAIN means "this domain does not exist". = Applications should be able to rely on that. Keith From brian.e.carpenter@gmail.com Fri Sep 9 18:56: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 E58A921F8540; Fri, 9 Sep 2011 18:56:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.585 X-Spam-Level: X-Spam-Status: No, score=-103.585 tagged_above=-999 required=5 tests=[AWL=0.014, 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 yw4qcEptGqUq; Fri, 9 Sep 2011 18:56:32 -0700 (PDT) Received: from mail-fx0-f44.google.com (mail-fx0-f44.google.com [209.85.161.44]) by ietfa.amsl.com (Postfix) with ESMTP id 0B43021F84CE; Fri, 9 Sep 2011 18:56:31 -0700 (PDT) Received: by fxe6 with SMTP id 6so3282884fxe.31 for ; Fri, 09 Sep 2011 18:58:28 -0700 (PDT) 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=6OBfWLQBAH95jyv5cwrCXxiYz+ztVq+LOafJ9CsrZgw=; b=a1da4esz5bfuQ6H7uxTOKOSzcq7WNTnVhKWsQLshR5pgCR8Wkc9Hf8GOJuGkd9U6fF /18oGNky2SfBvDuushAfPMUKTQUZTDLy7XDtkByX0FJD7Z8WdE/y3Lff15JAt9/1AfVQ 0qRbXbwKHjw/l+M7I6ntE+W3N7k7m5skVGH44= Received: by 10.223.88.22 with SMTP id y22mr487018fal.144.1315619907946; Fri, 09 Sep 2011 18:58:27 -0700 (PDT) Received: from [10.1.1.4] ([121.98.251.219]) by mx.google.com with ESMTPS id l21sm3706432fac.8.2011.09.09.18.58.23 (version=SSLv3 cipher=OTHER); Fri, 09 Sep 2011 18:58:26 -0700 (PDT) Message-ID: <4E6AC439.5060100@gmail.com> Date: Sat, 10 Sep 2011 13:58:17 +1200 From: Brian E Carpenter Organization: University of Auckland User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: Keith Moore References: <4E683F9B.7020905@gmail.com> <916CE6CF87173740BC8A2CE4430969620256F33F@008-AM1MPN1-032.mgdnok.nokia.com> <4E692D62.5080902@gmail.com> <916CE6CF87173740BC8A2CE443096962025704BA@008-AM1MPN1-032.mgdnok.nokia.com> <0A7B9663-0C40-4D19-BDBE-7EB72430D47D@network-heretics.com> <20110909230115.GG46494@shinkuro.com> <4E6AA248.6000406@gmail.com> <4D854606-64C6-4F7F-81A1-B15F1054E8BE@network-heretics.com> In-Reply-To: <4D854606-64C6-4F7F-81A1-B15F1054E8BE@network-heretics.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: mif@ietf.org, iesg@ietf.org Subject: Re: [mif] Last Call for MIF DNS server selection document 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, 10 Sep 2011 01:56:33 -0000 On 2011-09-10 12:03, Keith Moore wrote: > On Sep 9, 2011, at 7:33 PM, Brian E Carpenter wrote: > >>> doomed to the eventual state of affairs >>> where the exact same question asked of servers in different networks >>> would give different answers. We can't change the past. >> As long as the reply for a given query is always NXDOMAIN >> *except* for the one name server serving the particular offshoot >> of the namespace that the location-dependent domain is in, >> we have not broken the uniqueness of the namespace. > > Actually, I disagree. NXDOMAIN means "this domain does not exist". Applications should be able to rely on that. Well, that's the point: they can't. As far as I can see, ever since the first deployment of split DNS, you have to qualify that meaning with "as far as I know." I don't mean to imply that I'm happy with this. Brian From moore@network-heretics.com Fri Sep 9 19:08: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 0F5E011E8073; Fri, 9 Sep 2011 19:08:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.471 X-Spam-Level: X-Spam-Status: No, score=-3.471 tagged_above=-999 required=5 tests=[AWL=0.128, 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 ib-AhOWRJZhz; Fri, 9 Sep 2011 19:08:39 -0700 (PDT) Received: from out4.smtp.messagingengine.com (out4.smtp.messagingengine.com [66.111.4.28]) by ietfa.amsl.com (Postfix) with ESMTP id BE46F21F852C; Fri, 9 Sep 2011 19:08:39 -0700 (PDT) Received: from compute3.internal (compute3.nyi.mail.srv.osa [10.202.2.43]) by gateway1.nyi.mail.srv.osa (Postfix) with ESMTP id 2790C29B2C; Fri, 9 Sep 2011 22:10:36 -0400 (EDT) Received: from frontend2.nyi.mail.srv.osa ([10.202.2.161]) by compute3.internal (MEProxy); Fri, 09 Sep 2011 22:10:36 -0400 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=MASg95tQj6lgBwwiYNLtjkgFd/I=; b=k9 eGZ5CQoX0kXlKaQZB+99z/kXOnsRVmdVKZEbVgyuqo0HZ5gofafjYqDIQOnD2gbY P985TbzKWHnbqxkztPieM6wH8VDBSIz5jqJc8lui3mXB57nYb89lVQJebh3TRJZA laryRzs6bsIJDM/0ZsxvYRBahFVVfnFS3AOJCdNcY= X-Sasl-enc: g6n8vxa30vKQIsvBaAu/YOy1UyylP0D3ie28LEp3rsqt 1315620635 Received: from host65-16-145-177.birch.net (host65-16-145-177.birch.net [65.16.145.177]) by mail.messagingengine.com (Postfix) with ESMTPA id 13825B409BA; Fri, 9 Sep 2011 22:10:34 -0400 (EDT) Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Keith Moore In-Reply-To: <4E6AC439.5060100@gmail.com> Date: Fri, 9 Sep 2011 22:10:23 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: <78069B79-CA66-40C2-B63D-7CFE60749EBF@network-heretics.com> References: <4E683F9B.7020905@gmail.com> <916CE6CF87173740BC8A2CE4430969620256F33F@008-AM1MPN1-032.mgdnok.nokia.com> <4E692D62.5080902@gmail.com> <916CE6CF87173740BC8A2CE443096962025704BA@008-AM1MPN1-032.mgdnok.nokia.com> <0A7B9663-0C40-4D19-BDBE-7EB72430D47D@network-heretics.com> <20110909230115.GG46494@shinkuro.com> <4E6AA248.6000406@gmail.com> <4D854606-64C6-4F7F-81A1-B15F1054E8BE@network-heretics.com> <4E6AC439.5060100@gmail.com> To: Brian E Carpenter X-Mailer: Apple Mail (2.1084) Cc: mif@ietf.org, iesg@ietf.org Subject: Re: [mif] Last Call for MIF DNS server selection document 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, 10 Sep 2011 02:08:45 -0000 On Sep 9, 2011, at 9:58 PM, Brian E Carpenter wrote: > On 2011-09-10 12:03, Keith Moore wrote: >> On Sep 9, 2011, at 7:33 PM, Brian E Carpenter wrote: >>=20 >>>> doomed to the eventual state of affairs >>>> where the exact same question asked of servers in different = networks >>>> would give different answers. We can't change the past.=20 >>> As long as the reply for a given query is always NXDOMAIN >>> *except* for the one name server serving the particular offshoot >>> of the namespace that the location-dependent domain is in, >>> we have not broken the uniqueness of the namespace. >>=20 >> Actually, I disagree. NXDOMAIN means "this domain does not exist". = Applications should be able to rely on that. >=20 > Well, that's the point: they can't. As far as I can see, ever since > the first deployment of split DNS, you have to qualify that > meaning with "as far as I know." People who deploy split DNS need to understand that the consequence of = doing so is that if some application just happens to query the "wrong" = server, or the "wrong" side of the server, that it's going to get an = NXDOMAIN error, and that application is going to (quite properly) report = that the domain does not exist - even if that domain does exist, and = even if that application happens to have access to a network that lets = it query the "right" server. The notion that the network tells the host what DNS server to use (via = DHCP or whatever means), and that the host should do what the network = tells it to do, has always been suspect. The existence of multiple = active interfaces on hosts just makes the problem more obvious. Keith From internet-drafts@ietf.org Sat Sep 10 15:03: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 E974D21F86DD; Sat, 10 Sep 2011 15:03:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.587 X-Spam-Level: X-Spam-Status: No, score=-102.587 tagged_above=-999 required=5 tests=[AWL=0.012, 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 Y+Ix7scd1jkX; Sat, 10 Sep 2011 15:03:45 -0700 (PDT) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3C01221F86AA; Sat, 10 Sep 2011 15:03:45 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 3.60 Message-ID: <20110910220345.29077.66749.idtracker@ietfa.amsl.com> Date: Sat, 10 Sep 2011 15:03:45 -0700 Cc: mif@ietf.org Subject: [mif] I-D Action: draft-ietf-mif-dhcpv6-route-option-03.txt X-BeenThere: mif@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multiple Interface Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 10 Sep 2011 22:03:46 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Multiple Interfaces Working Group of = the IETF. Title : DHCPv6 Route Options Author(s) : Wojciech Dec Tomasz Mrugalski Tao Sun Behcet Sarikaya Filename : draft-ietf-mif-dhcpv6-route-option-03.txt Pages : 14 Date : 2011-09-10 This document describes DHCPv6 Route Options for provisioning IPv6 routes on DHCPv6 client nodes. This is expected to improve the ability of an operator to configure and influence a nodes' ability to pick an appropriate route to a destination when this node is multi- homed and where other means of route configuration may be impractical. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-mif-dhcpv6-route-option-03.t= xt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ This Internet-Draft can be retrieved at: ftp://ftp.ietf.org/internet-drafts/draft-ietf-mif-dhcpv6-route-option-03.txt From tomasz.mrugalski@gmail.com Sat Sep 10 15:40: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 E588B21F85C6; Sat, 10 Sep 2011 15:40:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.809 X-Spam-Level: X-Spam-Status: No, score=-3.809 tagged_above=-999 required=5 tests=[AWL=-0.210, 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 eHr7s0D5WULc; Sat, 10 Sep 2011 15:40:12 -0700 (PDT) Received: from mail-fx0-f44.google.com (mail-fx0-f44.google.com [209.85.161.44]) by ietfa.amsl.com (Postfix) with ESMTP id C5BD021F8565; Sat, 10 Sep 2011 15:40:11 -0700 (PDT) Received: by fxe6 with SMTP id 6so3853682fxe.31 for ; Sat, 10 Sep 2011 15:42:10 -0700 (PDT) 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:cc:subject :references:in-reply-to:x-tagtoolbar-keys:content-type :content-transfer-encoding; bh=m64HKGpO0uaK5FRRY/ZAfVPWceXqku597Na/Cut5Z5w=; b=c02EC/L5n0+Cp9z++25LI42cOTJMvemArbcF2acSd57eZdDlalTSFs5U2zAAp/nzRY G4tDk4RNuBPt0nyHyADEzNmhkv+8OHHYPlTIsPiZMn9eew+UU7pY+q2N7zFN/izZ9lOP cZRQQsVqPkZhkBaF5dM/Uu66vm/nglawsdnv4= Received: by 10.223.92.148 with SMTP id r20mr1888301fam.94.1315694530136; Sat, 10 Sep 2011 15:42:10 -0700 (PDT) Received: from [10.0.0.100] (host-109-107-11-157.ip.jarsat.pl [109.107.11.157]) by mx.google.com with ESMTPS id g1sm5191856fad.24.2011.09.10.15.42.08 (version=SSLv3 cipher=OTHER); Sat, 10 Sep 2011 15:42:09 -0700 (PDT) Message-ID: <4E6BE7BF.5030501@gmail.com> Date: Sun, 11 Sep 2011 00:42:07 +0200 From: Tomasz Mrugalski User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.21) Gecko/20110831 Lightning/1.0b2 Thunderbird/3.1.13 MIME-Version: 1.0 To: mif@ietf.org References: <20110910220345.29077.66749.idtracker@ietfa.amsl.com> In-Reply-To: <20110910220345.29077.66749.idtracker@ietfa.amsl.com> X-TagToolbar-Keys: D20110911004207102 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: dhcwg@ietf.org Subject: [mif] I-D draft-ietf-mif-dhcpv6-route-option-03 published X-BeenThere: mif@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multiple Interface Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 10 Sep 2011 22:40:13 -0000 On 11.09.2011 00:03, internet-drafts@ietf.org wrote: > A New Internet-Draft is available from the on-line Internet-Drafts > directories. This draft is a work item of the Multiple Interfaces > Working Group of the IETF. > > Title : DHCPv6 Route Options > Author(s) : Wojciech Dec > Tomasz Mrugalski > Tao Sun > Behcet Sarikaya > Filename : draft-ietf-mif-dhcpv6-route-option-03.txt > Pages : 14 > Date : 2011-09-10 > > This document describes DHCPv6 Route Options for provisioning IPv6 > routes on DHCPv6 client nodes. This is expected to improve the > ability of an operator to configure and influence a nodes' > ability to pick an appropriate route to a destination when this node > is multi- homed and where other means of route configuration may be > impractical. Dear MIF and DHC groups, This draft was presented in DHC WG in Quebec. While the primary area of review was from DHCP protocol perspective, there were quite a few insightful comments received related to other aspects. I was also presented again in MIF WG. After a long discussion we reached consensus and solved concerns raised during review by Routing Directorate. Authors would like to thank Joel Halpern, Marcin Siodelski and Alexandru Petrescu for their insightful comments and through review. Significant changes since -03 version: - added a route lifetime field. This provides a way to age and expire a route - route lifetime can be used to revoke a route during renewal - IA_RT prefix removed. It was only a container option, so this removal does not change the way this option works - clarified that default route may be configured with this mechanism - provided a way to configure default route in bandwidth-constrained networks - clarified that this mechanism may be used on routers (e.g. residential gateways) - added a way to configure on-link routes - added a limitation section pointing out that using this mechanism in networks that do dynamic routing is usually a bad idea The only comment that we chose not to implement is a suggestion to include MAC address information. We believe that would be wrong for number of reasons. If reviewers still thinks this is useful, we would like to point out a possible solution. As proposed options are designed to be extensible, reviewers who proposed adding MAC address can simply define a suboption that will provide necessary information in cases, where such information cannot be obtained in the usual way. Such approach is also better, because in most cases this information is not needed and may even be harmful. This kind of information should be requested only in those limited cases, where it is really needed. If proponents choose to define such extensions, our belief is that extra explanation why such information is needed would be very useful to understand their use case. There are no outstanding issues with this draft. This draft has been reviewed by Routing Directorate, by DHC WG and was presented several times in MIF meetings and in DHC meeting. As one of the authors (and I believe I speak on behalf of all authors) I think this draft is ready for last call. Therefore I would like to ask MIF chairs to announce WGLC. Of course any additional comments are more than welcome. Cheers, Tomek Mrugalski From maximilien.mouton@gmail.com Sun Sep 11 03:35: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 CD00B21F84D3; Sun, 11 Sep 2011 03:35:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tRb5TGyLKyMe; Sun, 11 Sep 2011 03:35:20 -0700 (PDT) Received: from mail-fx0-f44.google.com (mail-fx0-f44.google.com [209.85.161.44]) by ietfa.amsl.com (Postfix) with ESMTP id 829E721F84CE; Sun, 11 Sep 2011 03:35:19 -0700 (PDT) Received: by fxd18 with SMTP id 18so109814fxd.31 for ; Sun, 11 Sep 2011 03:37:19 -0700 (PDT) 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:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; bh=/8O9MUfIzsV/xTDG50jSwLaUqou2HmzIyoeDpGIOtaw=; b=v7i8jP6BWEaidubf3ddGUaVjNf3jfl9xAODm8rDb5Nc2En4AWA8BC7zIMJOyXnQn6Z ot+oBFio0qK6M/q+PTHT5GfK8wsc5WaSFppCxojj4nK5IfoEENRH7a3kwkJoJELdgBw7 /cN/rJ+qTDcuTb9SZLp2Z753dGk4ePoDYDr8k= Received: by 10.223.29.208 with SMTP id r16mr1738300fac.17.1315737439248; Sun, 11 Sep 2011 03:37:19 -0700 (PDT) Received: from [127.0.0.1] (2sm55-1-78-226-24-11.fbx.proxad.net [78.226.24.11]) by mx.google.com with ESMTPS id c5sm6060621fai.2.2011.09.11.03.37.16 (version=SSLv3 cipher=OTHER); Sun, 11 Sep 2011 03:37:18 -0700 (PDT) Message-ID: <4E6C8F4A.308@gmail.com> Date: Sun, 11 Sep 2011 12:36:58 +0200 From: maximilien mouton User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:6.0.2) Gecko/20110902 Thunderbird/6.0.2 MIME-Version: 1.0 To: Tomasz Mrugalski References: <20110910220345.29077.66749.idtracker@ietfa.amsl.com> <4E6BE7BF.5030501@gmail.com> In-Reply-To: <4E6BE7BF.5030501@gmail.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Cc: dhcwg@ietf.org, mif@ietf.org Subject: Re: [mif] I-D draft-ietf-mif-dhcpv6-route-option-03 published X-BeenThere: mif@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multiple Interface Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 11 Sep 2011 10:35:20 -0000 Hello Tomasz and MIF wg, I am pleased to see that you took in account our previous comments with Alexandru. But reading this new version of your draft I still think a default route should be seen as a special route and thus not treated the same way than others. Default route is an information taking part of what I call the "survival kit" for Internet i.e. the 3-tuple of IP address, DNS server address and default router address which is the minimum requirement for a client to access to Internet. This is why I think the default router configuration should have its own DHCPv6 option like default router list option described in http://tools.ietf.org/search/draft-mouton-mif-dhcpv6-drlo-00 (draft-mouton). I thus think that a client should be able to require only a default route (and no other route). The problem with the options defined in your draft is that a client who wants to configure only a default route must include NEXT_HOP and RT_PREFIX options in ORO. In this case the client will obtain unnecessary route information because the server will send back all route information it has in NEXT_HOP and RT_PREFIX options. This is why I think the options described in your draft should not allow server to provide default router information. I also think it could be good to share this discussion with dhcwg because it covers not only mif scenarios. Maximilien Le 11/09/2011 00:42, Tomasz Mrugalski a 閏rit : > On 11.09.2011 00:03, internet-drafts@ietf.org wrote: >> A New Internet-Draft is available from the on-line Internet-Drafts >> directories. This draft is a work item of the Multiple Interfaces >> Working Group of the IETF. >> >> Title : DHCPv6 Route Options >> Author(s) : Wojciech Dec >> Tomasz Mrugalski >> Tao Sun >> Behcet Sarikaya >> Filename : draft-ietf-mif-dhcpv6-route-option-03.txt >> Pages : 14 >> Date : 2011-09-10 >> >> This document describes DHCPv6 Route Options for provisioning IPv6 >> routes on DHCPv6 client nodes. This is expected to improve the >> ability of an operator to configure and influence a nodes' >> ability to pick an appropriate route to a destination when this node >> is multi- homed and where other means of route configuration may be >> impractical. > Dear MIF and DHC groups, > > This draft was presented in DHC WG in Quebec. While the primary area of > review was from DHCP protocol perspective, there were quite a few > insightful comments received related to other aspects. I was also > presented again in MIF WG. > > After a long discussion we reached consensus and solved concerns raised > during review by Routing Directorate. > > Authors would like to thank Joel Halpern, Marcin Siodelski and Alexandru > Petrescu for their insightful comments and through review. > > Significant changes since -03 version: > - added a route lifetime field. This provides a way to age and expire a > route > - route lifetime can be used to revoke a route during renewal > - IA_RT prefix removed. It was only a container option, so this removal > does not change the way this option works > - clarified that default route may be configured with this mechanism > - provided a way to configure default route in bandwidth-constrained > networks > - clarified that this mechanism may be used on routers (e.g. residential > gateways) > - added a way to configure on-link routes > - added a limitation section pointing out that using this mechanism in > networks that do dynamic routing is usually a bad idea > > The only comment that we chose not to implement is a suggestion to > include MAC address information. We believe that would be wrong for > number of reasons. If reviewers still thinks this is useful, we would > like to point out a possible solution. As proposed options are designed > to be extensible, reviewers who proposed adding MAC address can simply > define a suboption that will provide necessary information in cases, > where such information cannot be obtained in the usual way. Such > approach is also better, because in most cases this information is not > needed and may even be harmful. This kind of information should be > requested only in those limited cases, where it is really needed. If > proponents choose to define such extensions, our belief is that extra > explanation why such information is needed would be very useful to > understand their use case. > > There are no outstanding issues with this draft. This draft has been > reviewed by Routing Directorate, by DHC WG and was presented several > times in MIF meetings and in DHC meeting. As one of the authors (and I > believe I speak on behalf of all authors) I think this draft is ready > for last call. Therefore I would like to ask MIF chairs to announce WGLC. > > Of course any additional comments are more than welcome. > > Cheers, > Tomek Mrugalski > _______________________________________________ > mif mailing list > mif@ietf.org > https://www.ietf.org/mailman/listinfo/mif From ghalwasi@cisco.com Sun Sep 11 22:08:58 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 8C77B21F8AE1 for ; Sun, 11 Sep 2011 22:08:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.71 X-Spam-Level: X-Spam-Status: No, score=-9.71 tagged_above=-999 required=5 tests=[AWL=0.888, BAYES_00=-2.599, HTML_MESSAGE=0.001, 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 ea296xDrpfGG for ; Sun, 11 Sep 2011 22:08:57 -0700 (PDT) Received: from ams-iport-2.cisco.com (ams-iport-2.cisco.com [144.254.224.141]) by ietfa.amsl.com (Postfix) with ESMTP id 0A62E21F8AD8 for ; Sun, 11 Sep 2011 22:08:56 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=ghalwasi@cisco.com; l=4198; q=dns/txt; s=iport; t=1315804260; x=1317013860; h=mime-version:subject:date:message-id:from:to; bh=IIUmSwrpM2bDw2AEYrOOxNl0Fa1z6mmqxPagkSJfwNQ=; b=VJo4CQ6ty6PhAck5TYePl9nj/fsps6MxkxTOnPLpnmBNrzXAHHMBmHdI e2wBtvt7L16ZGjA0AEocdUDXcyxgTleMaDFlXJIrf9V3yWftUEyFi8dwu k7vWUvLY52PqQLtg+29rhUo04J3Ug+OKVhdF4vXrm9eLO71JYCTCV+e5i Y=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: An8GAMKTbU5Io8UR/2dsb2JhbABBgk2WaI5NeIFUAQEDEgEJEQNbAQweBhgHVwEECxAangqBJgGcaIYOYASHa5BwjAY X-IronPort-AV: E=Sophos;i="4.68,366,1312156800"; d="scan'208,217";a="54137970" Received: from bgl-core-2.cisco.com ([72.163.197.17]) by ams-iport-2.cisco.com with ESMTP; 12 Sep 2011 05:10:58 +0000 Received: from xbh-bgl-411.cisco.com (xbh-bgl-411.cisco.com [72.163.129.201]) by bgl-core-2.cisco.com (8.14.3/8.14.3) with ESMTP id p8C5AvvC019985 for ; Mon, 12 Sep 2011 05:10:57 GMT Received: from xmb-bgl-41e.cisco.com ([72.163.129.220]) by xbh-bgl-411.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Mon, 12 Sep 2011 10:40:57 +0530 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01CC710A.5A997C2B" Date: Mon, 12 Sep 2011 10:40:56 +0530 Message-ID: <3CF88B99A9ED504197498BC6F6F04B81040FBDA9@XMB-BGL-41E.cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Comments on draft-mouton-mif-dhcpv6-drlo-00 Thread-Index: AcxxClosDL9zuhm1Q+CTqXShqzwWxA== From: "Gaurav Halwasia (ghalwasi)" To: X-OriginalArrivalTime: 12 Sep 2011 05:10:57.0172 (UTC) FILETIME=[5AABC540:01CC710A] Subject: [mif] Comments on draft-mouton-mif-dhcpv6-drlo-00 X-BeenThere: mif@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multiple Interface Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 12 Sep 2011 05:08:58 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01CC710A.5A997C2B Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi, =20 I read this draft, I think similar issue is also being discussed/solved by draft-dec-dhcpv6-route-option-05 as well. =20 I see that you are proposing to have lifetime and MAC address in the route option. Why do we want to communicate the lifetime of the route in this option and that too I guess you are proposing to have a upper limit of 150 minutes (9000 seconds) on that. What is the reason behind that. What should be done after the expiry of this 150 minutes..? Information-Request..? or DHCP Renew.? I don't think that router lifetime will be that short and even if router lifetime expires, DHCPv6 server can just send RECONFIGURE. Normally IPv6 addres lease time will not usually be that less. =20 =20 Further, What's the real need of having MAC/link address in the route list option as there already exists means to get it. Thanks, Gaurav ------_=_NextPart_001_01CC710A.5A997C2B Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi,

 

I read this = draft, I think similar issue is also being discussed/solved by = draft-dec-dhcpv6-route-option-05 as well.

 

I see that = you are proposing to have lifetime and MAC address in the route option. = Why do we want to communicate the lifetime of the route in this option = and that too I guess you are proposing to have a upper limit of 150 = minutes (9000 seconds) on that. What is the reason behind that. What = should be done after the expiry of this 150 minutes..? = Information-Request..? or DHCP Renew.?

I don’t think that router lifetime will be that = short and even if router lifetime expires, DHCPv6 server can just send = RECONFIGURE.  Normally IPv6 addres lease time will not usually be = that less.  

 

Further, = What’s the real need of having MAC/link address in the route list = option as there already exists means to get it.

Thanks,

Gaurav

------_=_NextPart_001_01CC710A.5A997C2B-- From teemu.savolainen@nokia.com Mon Sep 12 01:06: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 2E2F021F848E; Mon, 12 Sep 2011 01:06:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.708 X-Spam-Level: X-Spam-Status: No, score=-2.708 tagged_above=-999 required=5 tests=[AWL=-0.109, 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 7wDRY4wvaGlb; Mon, 12 Sep 2011 01:06:41 -0700 (PDT) Received: from mgw-sa01.nokia.com (smtp.nokia.com [147.243.1.47]) by ietfa.amsl.com (Postfix) with ESMTP id 6660021F848D; Mon, 12 Sep 2011 01:06:38 -0700 (PDT) Received: from vaebh106.NOE.Nokia.com (vaebh106.europe.nokia.com [10.160.244.32]) by mgw-sa01.nokia.com (Switch-3.4.4/Switch-3.4.3) with ESMTP id p8C88ait007247; Mon, 12 Sep 2011 11:08:37 +0300 Received: from smtp.mgd.nokia.com ([65.54.30.8]) by vaebh106.NOE.Nokia.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.4675); Mon, 12 Sep 2011 11:08:32 +0300 Received: from 008-AM1MMR1-004.mgdnok.nokia.com (65.54.30.59) by NOK-AM1MHUB-04.mgdnok.nokia.com (65.54.30.8) with Microsoft SMTP Server (TLS) id 8.2.255.0; Mon, 12 Sep 2011 10:08:28 +0200 Received: from 008-AM1MPN1-032.mgdnok.nokia.com ([169.254.2.143]) by 008-AM1MMR1-004.mgdnok.nokia.com ([65.54.30.59]) with mapi id 14.01.0323.007; Mon, 12 Sep 2011 10:08:28 +0200 From: To: Thread-Topic: [mif] Last Call for MIF DNS server selection document Thread-Index: AQHMbdzsBHSQ8Tn9hkac95+LwFpGipVC/6HggADYVwCAABZPgIAAoquAgADZC4CAA/dpoA== Date: Mon, 12 Sep 2011 08:08:27 +0000 Message-ID: <916CE6CF87173740BC8A2CE44309696202571A30@008-AM1MPN1-032.mgdnok.nokia.com> References: <4E683F9B.7020905@gmail.com> <916CE6CF87173740BC8A2CE4430969620256F33F@008-AM1MPN1-032.mgdnok.nokia.com> <4E692D62.5080902@gmail.com> <916CE6CF87173740BC8A2CE443096962025704BA@008-AM1MPN1-032.mgdnok.nokia.com> <4E6A7E9F.5070706@gmail.com> In-Reply-To: <4E6A7E9F.5070706@gmail.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes 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+/nZJb9Kg7IijnarCFufw93yGp9Kqg4VsreROV3oSoCKo4MAZQAlH7cl7QEYi2t0p8hTrsrklpyqBfRuV1a3TP5t4zLsal1WzFsT0mQwFWR/yRh3UhJztIIhyLXE7aj3YtN85Eqji4hyMU9zDnsRybCxak6t2mfbgLZX2mjzSIIHnDkgCjyHZFFOhfBqPd/c5FcvKdb64f0sgP1bp0Rng5aZTrafF1qFNxmzB3fX0dr0qbeG9YfeKCcsiZk5WqSUtPkVYQ2fFAPg== x-originating-ip: [10.162.78.119] Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=SHA1; boundary="----=_NextPart_000_0016_01CC713C.4A440550" MIME-Version: 1.0 X-OriginalArrivalTime: 12 Sep 2011 08:08:32.0604 (UTC) FILETIME=[29CDA9C0:01CC7123] X-Nokia-AV: Clean Cc: mif@ietf.org, margaretw42@gmail.com, moore@network-heretics.com, denghui02@hotmail.com, iesg@ietf.org Subject: Re: [mif] Last Call for MIF DNS server selection document X-BeenThere: mif@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multiple Interface Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 12 Sep 2011 08:06:43 -0000 ------=_NextPart_000_0016_01CC713C.4A440550 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit Brian, I agree with that very reasonable suggestion. I think the problem described in section 2.3 is one symptom of issues caused by non-uniqueness (and for which I have not figured out automated solution). I mostly rewrote (for the -04 draft version) section 7 "Considerations for network administrators" as follows. Would that address this concern? -- Network administrators deploying private namespaces should assist advanced nodes in their DNS server selection process by providing information described within this document. 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). An exception to this rule are domains utilized for local name resolution (such as .local). Private namespaces MUST only consist of subdomains of the domains communicated for nodes (e.g. subdomains of example.com). This means that a DNS server MUST NOT resolve any domains that are not globally resolvable and are not subdomains of said communicated domains. To mitigate against attacks against local namespaces, administrators utilizing this tool SHOULD deploy DNSSEC for their zone. -- The .local remains open issue though, I encountered this also in homenet mailing list.. well it works fine as long as node is not connected to multiple local networks at the same time... If node is, then I guess the application must be able to select the right local network interface to use.. Best regards, Teemu > -----Original Message----- > From: ext Brian E Carpenter [mailto:brian.e.carpenter@gmail.com] > Sent: 10. syyskuuta 2011 00:01 > To: Savolainen Teemu (Nokia-CTO/Tampere) > Cc: moore@network-heretics.com; margaretw42@gmail.com; > mif@ietf.org; denghui02@hotmail.com > Subject: Re: [mif] Last Call for MIF DNS server selection document > > Teemu, > > I think the reference to multiple namespaces in the requirements draft is > too > short to really generate discussion, and in any case it's only an > Informational > document. > > However, I was trying to be quite careful in what I wrote. > > >> if the network administrator just does not want names to be > >> resolvable on the public Internet. > > That is one thing, and an *ambiguous* namespace is another. > > I guess I would like to see some MUSTs or MUST NOTs in the MIF draft or > elsewhere that make it clear that any domains that are not globally > resolvable must nevertheless be globally unique. That needs to be expressed > a bit more precisely and there might have to be an exception for .local. > However, if a host can see a DNS server from example.com, a rule could > be: that server MUST NOT resolve any domains that are not globally > resolvable and are not subdomains of example.com. > > I am sure there is a better way to express this. It just needs to guarantee > a > strict hierarchy in the namespace. > > Regards > Brian Carpenter > > On 2011-09-09 18:15, teemu.savolainen@nokia.com wrote: > > Keith, Brian, > > > > The problem this draft is addressing has been acknowledged in the > > draft-ietf-mif-problem-statement-15.txt section 4.1. The problem > > statement is already at the RFC editor's queue. > > > > Based on the acceptance of the problem, this WG was chartered with a > > goal > > of: > > -- > > 1) DNS server selection solution: a specification for describing a way > > for a network to communicate to nodes information required to perform > > advanced DNS server selection at name resolution request granularity > > in scenarios involving multiple namespaces. The specification shall > > describe the information to be delivered for nodes and the protocol to > > be used for delivery. > > -- > > > > This draft is the solution that has been accepted as a WG work item. > > > > The topic has been discussed for a quite long time and I don't think > > there are any such surprises you refer to (except perhaps for > > individuals who just now start following the work). > > > > Furthermore, I cannot easily buy the argument (I hope I read your > > points > > right) that a solution should not be developed for an acknowledged > > problem out of fear of "legitimizing" the problematic behavior. > > > > I do agree BCP or similar might be nice to have, but would such BCP > > really make any difference e.g. if the network administrator just does > > not want names to be resolvable on the public Internet. > > > > Best regards, > > > > Teemu > > > >> -----Original Message----- > >> From: ext Keith Moore [mailto:moore@network-heretics.com] > >> Sent: 09. syyskuuta 2011 01:22 > >> To: Brian E Carpenter > >> Cc: Savolainen Teemu (Nokia-CTO/Tampere); margaretw42@gmail.com; > >> mif@ietf.org; denghui02@hotmail.com > >> Subject: Re: [mif] Last Call for MIF DNS server selection document > >> > >> > >> On Sep 8, 2011, at 5:02 PM, Brian E Carpenter wrote: > >> > >>> Teemu, > >>> > >>> On 2011-09-08 18:16, teemu.savolainen@nokia.com wrote: > >>>> Brian, > >>>> > >>>> Thank you for review. I agree it is a good idea to consult those > >>>> WGs (and DHC as well I suppose), but what makes you so concerned of > >>>> this > >> text: > >>>>>> In deployments where multiple namespaces are present, selection > of > >>>>>> correct route and destination and source addresses for the > >>>>>> actual > > IP > >>>>>> connection is crucial as well, as the resolved destination's IP > >>>>>> addresses may be only usable on the network interface over > >>>>>> which > > the > >>>>>> name was resolved on. > >>>> I wrote that as I thought it would be useful to talk a little about > >>>> bigger picture of some deployments (like in the demo we had few > >>>> IETFs back - without presence of DHCPv6 more specific route options > >>>> the system would not have worked properly) .. but if that text > >>>> creates an unwanted link or dependency or confusion, I think we can > >>>> drop the text just as well and focus on the document just to the > >>>> new options and leave this kind of additional system-level > >>>> consideration out of the > >> doc. > >>> As Andrew pointed out, the draft starts > >>> > >>> "...from the premise that operators sometimes include private > >>> namespaces in the answers they provide from DNS servers, and that > >>> those private namespaces are at least as useful to clients as the > >>> answers from the public DNS." > >>> > >>> I believe that you will discover during IETF LC that many people > >>> have strong feelings about this premise; as Andrew implied, > >>> conceptually the DNS is a unified global namespace. This draft is a > >>> backdoor way of legitimising an ambiguous namespace. I don't think > >>> that will have an easy time in IETF LC, especially if it is dropped > >>> as a surprise into the DNS community. It's your choice, but I would > >>> suggest that exposing it to the DNS WGs now would be a smart move. > >> > >> Frankly, I consider this very nearly a showstopper, in the sense that > >> MIF needs an extremely good reason to do this, and I haven't seen > >> even a hint > > of > >> such a reason. You may recall that I raised this issue in Quebec, > > though > >> perhaps I was too polite about it. (Since I hadn't read the document > >> yet, > > and > >> was coming late into the discussion, I wanted to give the group the > > benefit > >> of the doubt.) > >> > >> I'm quite surprised that MIF was able to get this far with the document > >> without the issue being raised. I'm shocked that this issue appears to > > be a > >> surprise to the WG. I think that by itself is likely a sign of a > >> serious > > process or > >> management failure. > >> > >> > >>> It goes further. The IETF has a longstanding issue with technology > >>> that encourages walled gardens. See for example RFC 3002. I think > >>> there will be quite some discussion, and this will definitely happen > >>> even if you try to remove the "system-level" considerations, because > >>> they are strongly implied anyway. > >>> > >>> Personally I'm not sure what I think about this, but it needs to be > >>> discussed in the community IMHO. > >> +1. > >> > >> Keith > > ------=_NextPart_000_0016_01CC713C.4A440550 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIOuzCCAzYw ggIeoAMCAQICBDpVqdkwDQYJKoZIhvcNAQEFBQAwKTEOMAwGA1UEChMFTm9raWExFzAVBgNVBAMT Dk5va2lhICBSb290IENBMB4XDTAxMDEwNTExMDUwNVoXDTE2MDEwMjExMDUwNVowKTEOMAwGA1UE ChMFTm9raWExFzAVBgNVBAMTDk5va2lhICBSb290IENBMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8A MIIBCgKCAQEAsrTy8gLmr4LYvp0khVUVHw7ascdl+Cjr+yI5MlZ6J/U6Qsvkiqthgqq8rPcLV0P1 92TfBr27VgKEeCaZe0icS1jC2spM/wRv3j2WxdkKxb9kDJtuCNJaRBqvi5vGTHB15nmEmKuL5f3i rAxeHqPjgS496oWcudzFT1e7Xrc/gWGFYd72+/ykIFXjWOMZv6QpxD8x1hLPyh2YVXRk9U7N7pvm RQNX29g4SCFJY2BBIa5JPlwIF8Nc9IePaC/E/2M4tGMtiOOZlm99EoL7N0hJZtFSvUwdCBud/viH 4DgsKGjNkNKi6pAHc9IaXB6tIykcoYp+L+oe/3+cuEJaCj1EKwIDAQABo2YwZDASBgNVHRMBAf8E CDAGAQH/AgEEMB0GA1UdDgQWBBSNjfefoQ0AITLvqe0iruA79NB9sDAfBgNVHSMEGDAWgBSNjfef oQ0AITLvqe0iruA79NB9sDAOBgNVHQ8BAf8EBAMCAYYwDQYJKoZIhvcNAQEFBQADggEBAIGEPql2 TALyKi/h1J+Mh5XolAtYppcSOLMtBkoA7ZovGBDNvl0VbZs8AAojJqkUoWBB+L6DKyl/jKhNfKcu rWRGRyj7pnbxrKLsI3gmWNWkyo2b60wJwe9fqPD5ZQy3oEiMit9l0Ba6il/k2GqYopUCNMa7mfeb E2LeBy5ChYMiCi97UQSJvAdzEYylTJw8Awc6AiM2Ve5N+XxsmKgNf/2A/5IJ3EZZ+wFRmkI4062A oNU302rqAt0HH88jzoUF4AfYHWl6HpYhGXFbcX44rHINyPmFBRxLYIFJ6ZWUr/mXpL/e6rqFtNWO kV6UoJND7OVZkbLh7F1+lcqXRU8TPBMwggOHMIICb6ADAgECAgRBtbHpMA0GCSqGSIb3DQEBBQUA MCkxDjAMBgNVBAoTBU5va2lhMRcwFQYDVQQDEw5Ob2tpYSAgUm9vdCBDQTAeFw0wNjAzMzAwOTU3 MTFaFw0xNjAxMDIxMTA1MDVaMDMxCzAJBgNVBAYTAkZJMQ4wDAYDVQQKEwVOb2tpYTEUMBIGA1UE AxMLTm9raWEgQkkgQ0EwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQDtFCg3QEjSCg6T IUxoWsNwELh8bBNiUQPCPmg8c2DHQYXWWCSCMb+S0Fvh1qqI1xt+XnzyFq+5eqzGzDj4UaBcG+d9 qxrCFly8sHyoPTryyPrR0EI2UUDWwfS6ojhqgwghRqo8G38TjFusyBtLub/5L6yvWYSOHD+JcB+q VM2fbkArPYK4Ydv8WG/DbHjGn0gKq0zwpVZKI/gCK/QALYvte02NXseqvY9/GOyLtjy3Z8erFv71 KKTq+gxI/7DK55pJf3PoD+kT4kyGm6EF9DTdK4ojMdar17uyX0IOZz/4vkkF0d+60nmnLX63FJPA jUyB0HUNJ32NXDo9UsM38aoNAgMBAAGjgawwgakwDwYDVR0TAQH/BAUwAwEB/zARBgNVHSAECjAI MAYGBFUdIAAwDgYDVR0PAQH/BAQDAgGGMFQGA1UdIwRNMEuAFI2N95+hDQAhMu+p7SKu4Dv00H2w oS2kKzApMQ4wDAYDVQQKEwVOb2tpYTEXMBUGA1UEAxMOTm9raWEgIFJvb3QgQ0GCBDpVqdkwHQYD VR0OBBYEFKcksD7Fg+8EDlB2Sxgy58pW0Sy6MA0GCSqGSIb3DQEBBQUAA4IBAQAC3lEUplDlVNOT Pjz/XFezXx2bV2XbCFindhA3F815Egi55H6/cYezEjoP4QLNEGGl2I3aLvkn5A0T8I4pbiFPhIiu B/frbbGg6k6GjQLe/bFQ8F1mAOOR+GyneKZFPfzaRV0jiIR9QqnMXTf8RvKkCJyFj10MZVsLIy/Y uBkzeP3JhzDhUdtPfwmJN6ZbIhH5uR/2BwAGtgQknb8WX3I4wnhWtMUxB8XmayayYs8qWYeIiVkI FV+sLTkWUWVvvKUjyakBpbAW2vUP84DYsJ8TL1YefNjf/nIOByMcORLuV/1gPjyv00qJbcB59AA+ iXe3zIo8QNcgXG0uPQQFmrGDMIID5DCCAsygAwIBAgIQMH5apak8lEy6LmLlLsJy8TANBgkqhkiG 9w0BAQUFADAzMQswCQYDVQQGEwJGSTEOMAwGA1UEChMFTm9raWExFDASBgNVBAMTC05va2lhIEJJ IENBMB4XDTExMDkwNjA1NTIwNFoXDTE0MDkwNjA1NTIwNFowVjEOMAwGA1UECgwFTm9raWExDzAN BgNVBAsMBlBlb3BsZTEYMBYGCgmSJomT8ixkAQEMCDEwMDI0Njc2MRkwFwYDVQQDDBBTYXZvbGFp bmVuIFRlZW11MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAshEsmw6Yiz6XWX26oF+I s5fsfE1OfCjOelclmtqCiIgXND5klkNOBs2d4ZGzgD9mN+XnTZnOTh249c2WxPBugf12DCcDmBAJ gL+VuWUJVBTE5NRchm/O8nZnZsRFst+gAC9/Juykh4+EYewZ7QbpnlwW7hNpj8eH+rMr+OZHKzdp KTftgVjmuF4JJ/cPMQUjL8SuGj+zBW6IWPOZdqkEMtf7Pr8kkYbZsh0SgJ0ceRHZ7Uc06mB/y+C1 UnJPxehTTdu8tpCjdzXgBw/H2uuW1J3qdHbCfbuDILql8V8RiZKubcZLhdsD3Jvj8qK0DGWBJa6x p90q5p3pLE8LvAeCgQIDAQABo4HQMIHNMA4GA1UdDwEB/wQEAwIEMDAfBgNVHSMEGDAWgBSnJLA+ xYPvBA5QdksYMufKVtEsujAZBgNVHSAEEjAQMA4GDCsGAQQBXgExBgEHAzA5BgNVHR8EMjAwMC6g LKAqhihodHRwOi8vY3JsLm5va2lhLmNvbS9Ob2tpYSUyMEJJJTIwQ0EuY3JsMCUGA1UdEQQeMByB GnRlZW11LnNhdm9sYWluZW5Abm9raWEuY29tMB0GA1UdDgQWBBQTRzvZsgmQrAGCeuzdHTGAC6Jg UzANBgkqhkiG9w0BAQUFAAOCAQEACmPVsdi07pjK5gDa+W5JlE2C74kVVsB8alBqfioYeR5At2FG B7sua4Dz5H7TJMpZ1jYFeI+zjexD5f+beY2IlV15lMoWD+5e38QlLYjwfe2LAyvdzBKXW0e0U6Bt p78ft4gyVak1X+Db+ebR+FNHUOMNhm+yK3w9sy5ZQzBFusIx4OgxGvcZhyhmd9WjipSTalgPwgqV Ju2aPADCG++OEXmgEWRLsR4yNopkgK4ftVqrN5uUtLs83qdeXTRcNRiET1IOx5zmYFZ6q3gjKIx5 iyuxcDeYas93vVHUcaRRYpsoby5CHq7Z/j/TQhtqO/knWuxLFFiCUgdGKMKrRkg29DCCBAowggLy oAMCAQICEQCBvi+p+bA/dBtBtybwA6YYMA0GCSqGSIb3DQEBBQUAMDMxCzAJBgNVBAYTAkZJMQ4w DAYDVQQKEwVOb2tpYTEUMBIGA1UEAxMLTm9raWEgQkkgQ0EwHhcNMTEwOTA2MDU1MDM0WhcNMTMw OTA1MDU1MDM0WjBWMQ4wDAYDVQQKDAVOb2tpYTEPMA0GA1UECwwGUGVvcGxlMRgwFgYKCZImiZPy LGQBAQwIMTAwMjQ2NzYxGTAXBgNVBAMMEFNhdm9sYWluZW4gVGVlbXUwggEiMA0GCSqGSIb3DQEB AQUAA4IBDwAwggEKAoIBAQDFPmbRVwuo52v+h6xnQUqokAx2xsHjmPBniEkzgtgBNJsFi838ATEg 1zsx+VotoJg7hMijcrQfpTAgW6gpLGnlmw5QQswrNK1zleOHb4pA5JguU3WhVKFkAH/6/2EU2k/9 m8Pb/gwP55cYg80R6fRmbdsWKhseXF/1isW/rJcWLmIYDg/rXfo3ixqtT9MroAMiuoXnb0ij1L2d Jj64LDp3Ld8Jo0qZzk3Fj4apo8PBd8eAH6HloVBJkxQcwAnv561A+Xi1GHZ2mafRYJGO+1uBDwyd g/8ybEXXA4MKo8lPKjBebYBUFvz80DBA/Lq74UysXkG23BSulcG4xQSYGlyzAgMBAAGjgfUwgfIw HwYDVR0jBBgwFoAUpySwPsWD7wQOUHZLGDLnylbRLLowGQYDVR0gBBIwEDAOBgwrBgEEAV4BMQYB BgQwOQYDVR0fBDIwMDAuoCygKoYoaHR0cDovL2NybC5ub2tpYS5jb20vTm9raWElMjBCSSUyMENB LmNybDAjBgNVHSUEHDAaBggrBgEFBQcDAgYEVR0lAAYIKwYBBQUHAwQwDgYDVR0PAQH/BAQDAgeA MCUGA1UdEQQeMByBGnRlZW11LnNhdm9sYWluZW5Abm9raWEuY29tMB0GA1UdDgQWBBTGhbTJF0EX iagjymQo6GIuSQeRVDANBgkqhkiG9w0BAQUFAAOCAQEAqai6TxZ/BlMHZIhJNPriBPXkQhUlBkGA buJZ5sVm1HIQhWN8elZKjjJdHi1qWEKhMg7yHjEMZsyV8XAZzK0UnOqkpUnt+jnVkNZ9O7/jRtyK f4WUtq5jErc8Hlv4bbGFRHk1T7AuLLE52r1lYOdmoibnQp03QtlDvHUNa68G7jvzThJhieB7U1xh vH3yy0ktaVnWEgAylqf9yIUFjnqau5R6cE1Xo57IYPk/KitX0YF+OigEI/bOQVMi+fze93ZsAOJv /z6g/NGemvUgl5YSdX0uPQK6kEHf/sp/nZyUWWQ7OjtVSqkq2YuYEueQFxTfafl+78GWqgm6W/Bl 32laYzGCAuswggLnAgEBMEgwMzELMAkGA1UEBhMCRkkxDjAMBgNVBAoTBU5va2lhMRQwEgYDVQQD EwtOb2tpYSBCSSBDQQIRAIG+L6n5sD90G0G3JvADphgwCQYFKw4DAhoFAKCCAXgwGAYJKoZIhvcN AQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG9w0BCQUxDxcNMTEwOTEyMDgwODI0WjAjBgkqhkiG9w0B CQQxFgQUoz8aN5DheX4HqLfh3ZTvB32KohQwVgYJKwYBBAGCNxAEMUkwRzAzMQswCQYDVQQGEwJG STEOMAwGA1UEChMFTm9raWExFDASBgNVBAMTC05va2lhIEJJIENBAhAwflqlqTyUTLouYuUuwnLx MFgGCyqGSIb3DQEJEAILMUmgRzAzMQswCQYDVQQGEwJGSTEOMAwGA1UEChMFTm9raWExFDASBgNV BAMTC05va2lhIEJJIENBAhAwflqlqTyUTLouYuUuwnLxMGcGCSqGSIb3DQEJDzFaMFgwCgYIKoZI hvcNAwcwDgYIKoZIhvcNAwICAgCAMA0GCCqGSIb3DQMCAgFAMAcGBSsOAwIHMA0GCCqGSIb3DQMC AgEoMAcGBSsOAwIaMAoGCCqGSIb3DQIFMA0GCSqGSIb3DQEBAQUABIIBAFQbUMqcVDXCec9nyd8+ c8i7fsGHdI8rTY4hUZcEgACwDC/gfAC4qCqNqcJypXTLgL4nfHTTKpAkSMfSWzyy+oXaNBsMC4aa ou2r6lMNdK0SvrNTbS/OE5wx+YwKV7sWeWb6GSmC2K7Dhlmc7MHDAsXYOuyVYUkSAawpv2Bp1Qgi 8dRqqyIdm1igEgvNf6MdaIspXFYMlXwwF0pTa/oIdRjI5Abav3t4cPwx6jzHVBOU6FTqiAp/vduw gFGFXBNyTd/qVeD4IAnN9kXP789cIgkBGUafUAK96ZqnyRECyhMt0vPdCf1R6GjMSxsCbgMjf1u3 HwSGhL5IKMiNv6smvS4AAAAAAAA= ------=_NextPart_000_0016_01CC713C.4A440550-- From teemu.savolainen@nokia.com Mon Sep 12 05:46: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 AD93721F8AFD for ; Mon, 12 Sep 2011 05:46:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[AWL=-0.101, 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 jC-VB7iVNk7Q for ; Mon, 12 Sep 2011 05:46:01 -0700 (PDT) Received: from mgw-sa01.nokia.com (smtp.nokia.com [147.243.1.47]) by ietfa.amsl.com (Postfix) with ESMTP id 4BA4321F8AF4 for ; Mon, 12 Sep 2011 05:45:50 -0700 (PDT) Received: from vaebh102.NOE.Nokia.com (vaebh102.europe.nokia.com [10.160.244.23]) by mgw-sa01.nokia.com (Switch-3.4.4/Switch-3.4.3) with ESMTP id p8CClhnV032571; Mon, 12 Sep 2011 15:47:49 +0300 Received: from smtp.mgd.nokia.com ([65.54.30.8]) by vaebh102.NOE.Nokia.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.4675); Mon, 12 Sep 2011 15:47:45 +0300 Received: from 008-AM1MMR1-005.mgdnok.nokia.com (65.54.30.60) by NOK-AM1MHUB-04.mgdnok.nokia.com (65.54.30.8) with Microsoft SMTP Server (TLS) id 8.2.255.0; Mon, 12 Sep 2011 14:47:45 +0200 Received: from 008-AM1MPN1-032.mgdnok.nokia.com ([169.254.2.143]) by 008-AM1MMR1-005.mgdnok.nokia.com ([65.54.30.60]) with mapi id 14.01.0323.007; Mon, 12 Sep 2011 14:47:44 +0200 From: To: , Thread-Topic: [mif] Last Call for MIF DNS server selection document Thread-Index: AQHMbmf3BHSQ8Tn9hkac95+LwFpGipVEmINQgACieoCABDDqoA== Date: Mon, 12 Sep 2011 12:47:44 +0000 Message-ID: <916CE6CF87173740BC8A2CE44309696202571ED2@008-AM1MPN1-032.mgdnok.nokia.com> References: <20110908204329.GN38973@shinkuro.com> <916CE6CF87173740BC8A2CE44309696202570894@008-AM1MPN1-032.mgdnok.nokia.com> <20110909181657.GB46494@shinkuro.com> In-Reply-To: <20110909181657.GB46494@shinkuro.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes 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+/nZJb9Kg7IijnarCFufw93yGp9Kqg4VsreROV3oSoCKo4MAZQAlH7cl7QEYi2t0p8hTrsrklpyqBfRuV1a3TP5t4zLsal1WzFsT0mQwFWR/yRh3UhJztIIhyLXE7aj3YtN85Eqji4hyMU9zDnsRybCxak6t2mfbgLZX2mjzSIIHnDkgCjyHZFFOhfBqPd/c5FcvKdb64f0sgP1bp0Rng5aZTrafF1qFNxmzB3fX0dr0qbeG9YfeKCcsiZk5WqSUtPkVYQ2fFAPg== x-originating-ip: [10.162.78.119] Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=SHA1; boundary="----=_NextPart_000_0053_01CC7163.4ED42A10" MIME-Version: 1.0 X-OriginalArrivalTime: 12 Sep 2011 12:47:45.0534 (UTC) FILETIME=[2B53E9E0:01CC714A] X-Nokia-AV: Clean Subject: Re: [mif] Last Call for MIF DNS server selection document X-BeenThere: mif@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multiple Interface Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 12 Sep 2011 12:46:02 -0000 ------=_NextPart_000_0053_01CC7163.4ED42A10 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Hi Andrew, > -----Original Message----- > From: mif-bounces@ietf.org [mailto:mif-bounces@ietf.org] On Behalf Of > ext Andrew Sullivan > Sent: 09. syyskuuta 2011 21:17 > To: mif@ietf.org > Subject: Re: [mif] Last Call for MIF DNS server selection document > > > Is it better to talk about "DNS domain" or just "domain"? > > I think "domain" is fine, myself. Fine for me, changed in draft (for now at least). > > > However, the resolver SHOULD take into account > > > different trust levels of pieces of DNS server selection information > > > the resolver may have received from node's network interfaces. The > > > resolver SHOULD prefer DNS servers of trusted interfaces. > > > > > > Why isn't this MUST? > > > > Because a node implementation might not want to care about security > > (at this > > layer) for some reason. I mean it is of course easy to say why the > > node really SHOULD care about trust, but the DNS server selection > > itself should work just fine even if the node does not take security > > into account (it just may result in unwanted DNS server being used > > when under attack, but maybe said node is able to recover from that by > some other means). > > I guess I don't think this is a 2119 SHOULD, then. If it's really just a > matter of > taste, it's not SHOULD, in my reading of the keywords. SHOULD means > "you'd better have a pretty good reason not to do this", and I don't think > "I > don't wanna" qualifies. Perhaps MAY? Well...MAY sounds too weak for me especially after hearing so many complaints emails about possible new attack vectors. On the other hand.. maybe it could be MUST, and then it would be up to node implementation (or other SDOs) to determine what interface is judged to be trusty enough. Changed the sentences into: -- The resolver MUST take into account differences in trust levels of DNS server selection information the resolver has received. The resolver MUST prefer DNS servers of trusted interfaces. The DNS servers of untrusted interfaces may be of highest priority only if trusted interfaces specifically configure low priority DNS servers. -- > > The idea is that the node by magic knows what interfaces can be > > trusted and what cannot (trust2). > > Oh. That wasn't clear to me at all: I thought trust2 came from being able > to > validate the answers or else from having an authentecated and secure > connection to the upstream resolver. I added following text, would it clarify this? -- Trustworthiness of an interface and configuration information received over the interface is implementation and/or node deployment dependent. Trust may be based on, for example, on the nature of an interface. For example, an authenticated and encrypted VPN or layer 2 connection to a trusted home network may be considered as trusted, and an unauthenticated and unencrypted connection to an unknown visited network may be considered as untrusted. -- > government where one department has 6 layers of NAT in an attempt to > keep their sooper secret names inside the network. They still end up > writing > incident reports every time one of those names leaks, but leak they do. The > DNS is _designed_ to leak this way. Right... first design a network that should withstand a nuclear war and then complain when data actually finds paths around "damaged sections":) > > Would it satisfy your concern if we drop the:" unnecessary reveal > > information about ongoing communications" away? And hence would have > just: > > -- > > The resolver SHOULD avoid sending queries to different interfaces in > > parallel as that may waste resources such as energy. > > -- > > Yeah, this works for me. Ok, changed. > > With new terms it says:"IPv6 networks should cover all the DNS domains..". > > It means that configuration should be such that one could do reverse > > queries successfully for all the domains that are configured (and vice > versa). > > Hrm. I don't think this is a realistic requirement. First, there is no > guarantee > in the first place that the reverse tree will actually be maintained -- and > there > are people who have strong feelings that it is entirely optional. For your > amusement, I can show you sometime the scourge marks I got from trying to > get a draft through DNSOP that by last call said, in effect, "You can use > the > reverse tree, or not, depending on what you like." It still failed. > > But in any case, even if the reverse tree was fully maintained, the forward > and reverse don't line up exactly. For instance, a CNAME in the forward > tree > is entirely likely not to be reflected in the reverse. I think you can > probably > cut this text (although I don't feel that strongly about it). Cut the "IPv6 networks.." paragraph fully away? And just let admins configure whateevr they think is best/needed for the network part? My original thinking was that e.g. an ISP could configure here very large network, like their full single /32 or so. > > > In section 4.6., I think that it needs to be made clear that a bare > > > name > > is first > > > treated as a pre-DNS hostname before it encounters the DNS search list. > > > (Frankly, that entire mechanism is broken, and it would suit me just > > > fine > > if the > > > document said, "This algorithm is incompatible with the DNS search > > > list > > and > > > the OPTION_DOMAIN_LIST feature." But I know people would scream > > > about it. It's still broken.) > > > > I'm not sure what you mean with "pre-DNS" hostname.. > > I.e. an RFC 952 hostname. The DNS search list is really a hack that was > partly > an attempt to make things work more like the old host name syntax (and > partly to give local scoping). When you put something in /etc/hosts, what > you're really doing is preventing the DNS from getting involved by using the > hostname mechanism. Unfortunately, no naming technlogy on the Internet > ever goes away. It just gets more cruft layered on top. So something like this: -- 4.6. Interactions with OPTION_DOMAIN_LIST and pre-DNS hostnames A node may be configured with DNS search list with OPTION_DOMAIN_LIST. A bare name (a name without any dots) MUST be first treated as a pre-DNS hostname, and only after that the name SHALL be appended with suffix(es) and improved DNS server selection be utilized. Resolution for the name containing any dots SHOULD first be attempted with DNS servers of all interfaces as is described above. Only if the resolution fails the node SHOULD append the name with search list suffix(es) and then again utilize improved DNS server selection algorithm to decide which DNS server(s) to contact. -- > > > In 4.7, what about other things that could do context-sensitive > > > referrals, > > like > > > SRV? > > > > Hmm.. what should we write about those? Any record type that contains > > domain names shall fall under this server selection logic? > > That would include NS records. But actually, now that I think about it, > this > should probably just say that any follow-up queries that are performed on > the basis of an answer received on an interface MUST continue to use the > same interface, irrespective of the DNS server selection settings on any > other > interface. This is required because of the assumption that different DNS > servers possibly provide different namespaces. (I want to go lie down after > having written > that.) Something like: -- 4.7 Considerations on follow-up queries Any follow-up queries that are performed on the basis of an answer received on an interface MUST continue to use the same interface, irrespective of the DNS server selection settings on any other interface. For example, if a node receives a reply with a canonical name (CNAME) or delegation name (DNAME) the follow-up queries MUST be sent to DNS server(s) of the same interface, or to same DNS server, irrespectively of the FQDN received. Otherwise referrals may fail. -- I'm not sure this is too difficult to implement - a stub resolver ought to see the DNS server who provided the answer, and hence it should be quite trivial to send follow-up queries to the same server. Or can that Thank you again for your suggestions and efforts to find least evil solutions.. Teemu ------=_NextPart_000_0053_01CC7163.4ED42A10 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIOuzCCAzYw ggIeoAMCAQICBDpVqdkwDQYJKoZIhvcNAQEFBQAwKTEOMAwGA1UEChMFTm9raWExFzAVBgNVBAMT Dk5va2lhICBSb290IENBMB4XDTAxMDEwNTExMDUwNVoXDTE2MDEwMjExMDUwNVowKTEOMAwGA1UE ChMFTm9raWExFzAVBgNVBAMTDk5va2lhICBSb290IENBMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8A MIIBCgKCAQEAsrTy8gLmr4LYvp0khVUVHw7ascdl+Cjr+yI5MlZ6J/U6Qsvkiqthgqq8rPcLV0P1 92TfBr27VgKEeCaZe0icS1jC2spM/wRv3j2WxdkKxb9kDJtuCNJaRBqvi5vGTHB15nmEmKuL5f3i rAxeHqPjgS496oWcudzFT1e7Xrc/gWGFYd72+/ykIFXjWOMZv6QpxD8x1hLPyh2YVXRk9U7N7pvm RQNX29g4SCFJY2BBIa5JPlwIF8Nc9IePaC/E/2M4tGMtiOOZlm99EoL7N0hJZtFSvUwdCBud/viH 4DgsKGjNkNKi6pAHc9IaXB6tIykcoYp+L+oe/3+cuEJaCj1EKwIDAQABo2YwZDASBgNVHRMBAf8E CDAGAQH/AgEEMB0GA1UdDgQWBBSNjfefoQ0AITLvqe0iruA79NB9sDAfBgNVHSMEGDAWgBSNjfef oQ0AITLvqe0iruA79NB9sDAOBgNVHQ8BAf8EBAMCAYYwDQYJKoZIhvcNAQEFBQADggEBAIGEPql2 TALyKi/h1J+Mh5XolAtYppcSOLMtBkoA7ZovGBDNvl0VbZs8AAojJqkUoWBB+L6DKyl/jKhNfKcu rWRGRyj7pnbxrKLsI3gmWNWkyo2b60wJwe9fqPD5ZQy3oEiMit9l0Ba6il/k2GqYopUCNMa7mfeb E2LeBy5ChYMiCi97UQSJvAdzEYylTJw8Awc6AiM2Ve5N+XxsmKgNf/2A/5IJ3EZZ+wFRmkI4062A oNU302rqAt0HH88jzoUF4AfYHWl6HpYhGXFbcX44rHINyPmFBRxLYIFJ6ZWUr/mXpL/e6rqFtNWO kV6UoJND7OVZkbLh7F1+lcqXRU8TPBMwggOHMIICb6ADAgECAgRBtbHpMA0GCSqGSIb3DQEBBQUA MCkxDjAMBgNVBAoTBU5va2lhMRcwFQYDVQQDEw5Ob2tpYSAgUm9vdCBDQTAeFw0wNjAzMzAwOTU3 MTFaFw0xNjAxMDIxMTA1MDVaMDMxCzAJBgNVBAYTAkZJMQ4wDAYDVQQKEwVOb2tpYTEUMBIGA1UE AxMLTm9raWEgQkkgQ0EwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQDtFCg3QEjSCg6T IUxoWsNwELh8bBNiUQPCPmg8c2DHQYXWWCSCMb+S0Fvh1qqI1xt+XnzyFq+5eqzGzDj4UaBcG+d9 qxrCFly8sHyoPTryyPrR0EI2UUDWwfS6ojhqgwghRqo8G38TjFusyBtLub/5L6yvWYSOHD+JcB+q VM2fbkArPYK4Ydv8WG/DbHjGn0gKq0zwpVZKI/gCK/QALYvte02NXseqvY9/GOyLtjy3Z8erFv71 KKTq+gxI/7DK55pJf3PoD+kT4kyGm6EF9DTdK4ojMdar17uyX0IOZz/4vkkF0d+60nmnLX63FJPA jUyB0HUNJ32NXDo9UsM38aoNAgMBAAGjgawwgakwDwYDVR0TAQH/BAUwAwEB/zARBgNVHSAECjAI MAYGBFUdIAAwDgYDVR0PAQH/BAQDAgGGMFQGA1UdIwRNMEuAFI2N95+hDQAhMu+p7SKu4Dv00H2w oS2kKzApMQ4wDAYDVQQKEwVOb2tpYTEXMBUGA1UEAxMOTm9raWEgIFJvb3QgQ0GCBDpVqdkwHQYD VR0OBBYEFKcksD7Fg+8EDlB2Sxgy58pW0Sy6MA0GCSqGSIb3DQEBBQUAA4IBAQAC3lEUplDlVNOT Pjz/XFezXx2bV2XbCFindhA3F815Egi55H6/cYezEjoP4QLNEGGl2I3aLvkn5A0T8I4pbiFPhIiu B/frbbGg6k6GjQLe/bFQ8F1mAOOR+GyneKZFPfzaRV0jiIR9QqnMXTf8RvKkCJyFj10MZVsLIy/Y uBkzeP3JhzDhUdtPfwmJN6ZbIhH5uR/2BwAGtgQknb8WX3I4wnhWtMUxB8XmayayYs8qWYeIiVkI FV+sLTkWUWVvvKUjyakBpbAW2vUP84DYsJ8TL1YefNjf/nIOByMcORLuV/1gPjyv00qJbcB59AA+ iXe3zIo8QNcgXG0uPQQFmrGDMIID5DCCAsygAwIBAgIQMH5apak8lEy6LmLlLsJy8TANBgkqhkiG 9w0BAQUFADAzMQswCQYDVQQGEwJGSTEOMAwGA1UEChMFTm9raWExFDASBgNVBAMTC05va2lhIEJJ IENBMB4XDTExMDkwNjA1NTIwNFoXDTE0MDkwNjA1NTIwNFowVjEOMAwGA1UECgwFTm9raWExDzAN BgNVBAsMBlBlb3BsZTEYMBYGCgmSJomT8ixkAQEMCDEwMDI0Njc2MRkwFwYDVQQDDBBTYXZvbGFp bmVuIFRlZW11MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAshEsmw6Yiz6XWX26oF+I s5fsfE1OfCjOelclmtqCiIgXND5klkNOBs2d4ZGzgD9mN+XnTZnOTh249c2WxPBugf12DCcDmBAJ gL+VuWUJVBTE5NRchm/O8nZnZsRFst+gAC9/Juykh4+EYewZ7QbpnlwW7hNpj8eH+rMr+OZHKzdp KTftgVjmuF4JJ/cPMQUjL8SuGj+zBW6IWPOZdqkEMtf7Pr8kkYbZsh0SgJ0ceRHZ7Uc06mB/y+C1 UnJPxehTTdu8tpCjdzXgBw/H2uuW1J3qdHbCfbuDILql8V8RiZKubcZLhdsD3Jvj8qK0DGWBJa6x p90q5p3pLE8LvAeCgQIDAQABo4HQMIHNMA4GA1UdDwEB/wQEAwIEMDAfBgNVHSMEGDAWgBSnJLA+ xYPvBA5QdksYMufKVtEsujAZBgNVHSAEEjAQMA4GDCsGAQQBXgExBgEHAzA5BgNVHR8EMjAwMC6g LKAqhihodHRwOi8vY3JsLm5va2lhLmNvbS9Ob2tpYSUyMEJJJTIwQ0EuY3JsMCUGA1UdEQQeMByB GnRlZW11LnNhdm9sYWluZW5Abm9raWEuY29tMB0GA1UdDgQWBBQTRzvZsgmQrAGCeuzdHTGAC6Jg UzANBgkqhkiG9w0BAQUFAAOCAQEACmPVsdi07pjK5gDa+W5JlE2C74kVVsB8alBqfioYeR5At2FG B7sua4Dz5H7TJMpZ1jYFeI+zjexD5f+beY2IlV15lMoWD+5e38QlLYjwfe2LAyvdzBKXW0e0U6Bt p78ft4gyVak1X+Db+ebR+FNHUOMNhm+yK3w9sy5ZQzBFusIx4OgxGvcZhyhmd9WjipSTalgPwgqV Ju2aPADCG++OEXmgEWRLsR4yNopkgK4ftVqrN5uUtLs83qdeXTRcNRiET1IOx5zmYFZ6q3gjKIx5 iyuxcDeYas93vVHUcaRRYpsoby5CHq7Z/j/TQhtqO/knWuxLFFiCUgdGKMKrRkg29DCCBAowggLy oAMCAQICEQCBvi+p+bA/dBtBtybwA6YYMA0GCSqGSIb3DQEBBQUAMDMxCzAJBgNVBAYTAkZJMQ4w DAYDVQQKEwVOb2tpYTEUMBIGA1UEAxMLTm9raWEgQkkgQ0EwHhcNMTEwOTA2MDU1MDM0WhcNMTMw OTA1MDU1MDM0WjBWMQ4wDAYDVQQKDAVOb2tpYTEPMA0GA1UECwwGUGVvcGxlMRgwFgYKCZImiZPy LGQBAQwIMTAwMjQ2NzYxGTAXBgNVBAMMEFNhdm9sYWluZW4gVGVlbXUwggEiMA0GCSqGSIb3DQEB AQUAA4IBDwAwggEKAoIBAQDFPmbRVwuo52v+h6xnQUqokAx2xsHjmPBniEkzgtgBNJsFi838ATEg 1zsx+VotoJg7hMijcrQfpTAgW6gpLGnlmw5QQswrNK1zleOHb4pA5JguU3WhVKFkAH/6/2EU2k/9 m8Pb/gwP55cYg80R6fRmbdsWKhseXF/1isW/rJcWLmIYDg/rXfo3ixqtT9MroAMiuoXnb0ij1L2d Jj64LDp3Ld8Jo0qZzk3Fj4apo8PBd8eAH6HloVBJkxQcwAnv561A+Xi1GHZ2mafRYJGO+1uBDwyd g/8ybEXXA4MKo8lPKjBebYBUFvz80DBA/Lq74UysXkG23BSulcG4xQSYGlyzAgMBAAGjgfUwgfIw HwYDVR0jBBgwFoAUpySwPsWD7wQOUHZLGDLnylbRLLowGQYDVR0gBBIwEDAOBgwrBgEEAV4BMQYB BgQwOQYDVR0fBDIwMDAuoCygKoYoaHR0cDovL2NybC5ub2tpYS5jb20vTm9raWElMjBCSSUyMENB LmNybDAjBgNVHSUEHDAaBggrBgEFBQcDAgYEVR0lAAYIKwYBBQUHAwQwDgYDVR0PAQH/BAQDAgeA MCUGA1UdEQQeMByBGnRlZW11LnNhdm9sYWluZW5Abm9raWEuY29tMB0GA1UdDgQWBBTGhbTJF0EX iagjymQo6GIuSQeRVDANBgkqhkiG9w0BAQUFAAOCAQEAqai6TxZ/BlMHZIhJNPriBPXkQhUlBkGA buJZ5sVm1HIQhWN8elZKjjJdHi1qWEKhMg7yHjEMZsyV8XAZzK0UnOqkpUnt+jnVkNZ9O7/jRtyK f4WUtq5jErc8Hlv4bbGFRHk1T7AuLLE52r1lYOdmoibnQp03QtlDvHUNa68G7jvzThJhieB7U1xh vH3yy0ktaVnWEgAylqf9yIUFjnqau5R6cE1Xo57IYPk/KitX0YF+OigEI/bOQVMi+fze93ZsAOJv /z6g/NGemvUgl5YSdX0uPQK6kEHf/sp/nZyUWWQ7OjtVSqkq2YuYEueQFxTfafl+78GWqgm6W/Bl 32laYzGCAuswggLnAgEBMEgwMzELMAkGA1UEBhMCRkkxDjAMBgNVBAoTBU5va2lhMRQwEgYDVQQD EwtOb2tpYSBCSSBDQQIRAIG+L6n5sD90G0G3JvADphgwCQYFKw4DAhoFAKCCAXgwGAYJKoZIhvcN AQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG9w0BCQUxDxcNMTEwOTEyMTI0NzQyWjAjBgkqhkiG9w0B CQQxFgQUFXr0+7Uo45KxSerM59/CEyc8XUgwVgYJKwYBBAGCNxAEMUkwRzAzMQswCQYDVQQGEwJG STEOMAwGA1UEChMFTm9raWExFDASBgNVBAMTC05va2lhIEJJIENBAhAwflqlqTyUTLouYuUuwnLx MFgGCyqGSIb3DQEJEAILMUmgRzAzMQswCQYDVQQGEwJGSTEOMAwGA1UEChMFTm9raWExFDASBgNV BAMTC05va2lhIEJJIENBAhAwflqlqTyUTLouYuUuwnLxMGcGCSqGSIb3DQEJDzFaMFgwCgYIKoZI hvcNAwcwDgYIKoZIhvcNAwICAgCAMA0GCCqGSIb3DQMCAgFAMAcGBSsOAwIHMA0GCCqGSIb3DQMC AgEoMAcGBSsOAwIaMAoGCCqGSIb3DQIFMA0GCSqGSIb3DQEBAQUABIIBACkWUDM73eQ78T7FqRkD fJ0LTL8Rjz3DeqXqgEJ7OFSGKjEYABoJAe+Mbs30WYWn271/9VdKf7YTIngORey29E5OQ1UyHnw5 ObkoHitB1gYazGnaLFDd/py0wq+Pg/WCA53qYyhGOgn0EFT0Tm6zspw6MbpeWVLZnmZjLhKfSk/S k71dZSG/c1qnZhz8gGS59OehM4fIol12Mqmvf7W2SZG5dPk8d4FxwV0Raqpr7fH1Va/FQStlIKCu c61mfirGCCIUmmGG3PgG5Hy7CJCMTeWbUpLrle50cuKawCWjKiZSz3Dyne/T63FbNt6S/BKwuIwZ aOwaZKs53tAXD9YzpaIAAAAAAAA= ------=_NextPart_000_0053_01CC7163.4ED42A10-- From moore@network-heretics.com Mon Sep 12 05:52: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 B880B21F84D4 for ; Mon, 12 Sep 2011 05:52:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.475 X-Spam-Level: X-Spam-Status: No, score=-3.475 tagged_above=-999 required=5 tests=[AWL=0.123, 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 8EkkKsc6tIEF for ; Mon, 12 Sep 2011 05:52:17 -0700 (PDT) Received: from out4.smtp.messagingengine.com (out4.smtp.messagingengine.com [66.111.4.28]) by ietfa.amsl.com (Postfix) with ESMTP id E033C21F84D5 for ; Mon, 12 Sep 2011 05:52:16 -0700 (PDT) Received: from compute3.internal (compute3.nyi.mail.srv.osa [10.202.2.43]) by gateway1.nyi.mail.srv.osa (Postfix) with ESMTP id 0318028EE9; Mon, 12 Sep 2011 08:54:20 -0400 (EDT) Received: from frontend1.nyi.mail.srv.osa ([10.202.2.160]) by compute3.internal (MEProxy); Mon, 12 Sep 2011 08:54:20 -0400 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=lt3 CxFDqwvQXU212us+tyLcUqPg=; b=Aiyh5EySwesNqzjRwMfZR4rGwWOdtW7a+WO TJDw7xwjQf1Wz8pCkqwSWEEyiB6GkYWow23tnvdOMqpk3DVolp1QdpKBV+B3wfdN Vza6eOiqjlM7fn0yehTGAjAIPtQqRLXu6f3mXbGoe90JVgQcGpWHiiYhSTGULRyJ cYicSi6Y= X-Sasl-enc: UhHOxC3ShlWebcDBT6wnBZaYPWDZw5jPIQW9esyktiKs 1315832059 Received: from host65-16-145-177.birch.net (host65-16-145-177.birch.net [65.16.145.177]) by mail.messagingengine.com (Postfix) with ESMTPA id B364F7401CC; Mon, 12 Sep 2011 08:54:18 -0400 (EDT) Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: multipart/alternative; boundary=Apple-Mail-1-369912639 From: Keith Moore In-Reply-To: <916CE6CF87173740BC8A2CE44309696202571ED2@008-AM1MPN1-032.mgdnok.nokia.com> Date: Mon, 12 Sep 2011 08:54:05 -0400 Message-Id: <051540FD-3AA1-4D1E-BAE3-AE7AC42BBBE3@network-heretics.com> References: <20110908204329.GN38973@shinkuro.com> <916CE6CF87173740BC8A2CE44309696202570894@008-AM1MPN1-032.mgdnok.nokia.com> <20110909181657.GB46494@shinkuro.com> <916CE6CF87173740BC8A2CE44309696202571ED2@008-AM1MPN1-032.mgdnok.nokia.com> To: X-Mailer: Apple Mail (2.1084) Cc: mif@ietf.org Subject: Re: [mif] Last Call for MIF DNS server selection document X-BeenThere: mif@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multiple Interface Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 12 Sep 2011 12:52:17 -0000 --Apple-Mail-1-369912639 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii On Sep 12, 2011, at 8:47 AM, = wrote: > The resolver MUST take into account differences in trust levels of DNS = server=20 > selection information the resolver has received. The resolver MUST = prefer DNS=20 > servers of trusted interfaces. The DNS servers of untrusted interfaces = may be=20 > of highest priority only if trusted interfaces specifically configure = low=20 > priority DNS servers. > -- > [...] > -- > Trustworthiness of an interface and configuration information received = over=20 > the interface is implementation and/or node deployment dependent. = Trust may be=20 > based on, for example, on the nature of an interface. For example, an=20= > authenticated and encrypted VPN or layer 2 connection to a trusted = home=20 > network may be considered as trusted, and an unauthenticated and = unencrypted=20 > connection to an unknown visited network may be considered as = untrusted. I don't think it makes sense to impose a MUST requirement in conjunction = with something that's so imprecisely defined. Also, the notion that trustworthiness of an interface and = trustworthiness of a DNS server are somehow related strikes me as = dubious. Keith --Apple-Mail-1-369912639 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii teemu.savolainen@nokia.com&= gt; <teemu.savolainen@nokia.com&= gt; wrote:
The resolver = MUST take into account differences in trust levels of DNS server 
selection information = the resolver has received. The resolver MUST prefer = DNS 
servers of = trusted interfaces. The DNS servers of untrusted = interfaces may be 
of highest priority only if = trusted interfaces specifically configure low 
the interface is = implementation and/or node deployment dependent. Trust may = be 
based on, for = example, on the nature of an interface. For example, an 
authenticated and = encrypted VPN or layer 2 connection to a trusted home 
network may be = considered as trusted, and an unauthenticated and unencrypted 
connection to an = unknown visited network may be considered as = untrusted.</t>


= I don't think it makes sense to impose a MUST requirement in conjunction = with something that's so imprecisely = defined.

Also, the notion that trustworthiness = of an interface and trustworthiness of a DNS server are somehow related = strikes me as = dubious.

Keith

= --Apple-Mail-1-369912639-- From simon.perreault@viagenie.ca Mon Sep 12 06:10: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 E516621F8B06; Mon, 12 Sep 2011 06:10:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, NO_RELAYS=-0.001] 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 prd1ehIXr8+S; Mon, 12 Sep 2011 06:10:34 -0700 (PDT) Received: from jazz.viagenie.ca (unknown [IPv6:2620:0:230:8000:226:55ff:fe57:14db]) by ietfa.amsl.com (Postfix) with ESMTP id 3EF5021F8B53; Mon, 12 Sep 2011 06:10:34 -0700 (PDT) Received: from ringo.viagenie.ca (unknown [IPv6:2620:0:230:c000:21d:60ff:fed7:e732]) by jazz.viagenie.ca (Postfix) with ESMTPSA id 5AC7520DC4; Mon, 12 Sep 2011 09:12:28 -0400 (EDT) Message-ID: <4E6E053B.7000305@viagenie.ca> Date: Mon, 12 Sep 2011 09:12:27 -0400 From: Simon Perreault User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:5.0) Gecko/20110720 Thunderbird/5.0 MIME-Version: 1.0 To: maximilien mouton References: <20110910220345.29077.66749.idtracker@ietfa.amsl.com> <4E6BE7BF.5030501@gmail.com> <4E6C8F4A.308@gmail.com> In-Reply-To: <4E6C8F4A.308@gmail.com> X-Enigmail-Version: 1.2.1 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: dhcwg@ietf.org, mif@ietf.org Subject: Re: [mif] I-D draft-ietf-mif-dhcpv6-route-option-03 published X-BeenThere: mif@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multiple Interface Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 12 Sep 2011 13:10:35 -0000 On 2011-09-11 06:36, maximilien mouton wrote: > I thus think that a client should be able to require only a default > route (and no other route). Why? What's the use case? Are you working with hosts that do not have a generic routing table and only support a single default route? Simon -- DTN made easy, lean, and smart --> http://postellation.viagenie.ca NAT64/DNS64 open-source --> http://ecdysis.viagenie.ca STUN/TURN server --> http://numb.viagenie.ca From teemu.savolainen@nokia.com Mon Sep 12 06:15: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 62E3D21F8B2D for ; Mon, 12 Sep 2011 06:15:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.694 X-Spam-Level: X-Spam-Status: No, score=-2.694 tagged_above=-999 required=5 tests=[AWL=-0.096, BAYES_00=-2.599, HTML_MESSAGE=0.001] 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 X1lhNP6qGTug for ; Mon, 12 Sep 2011 06:15:32 -0700 (PDT) Received: from mgw-da02.nokia.com (smtp.nokia.com [147.243.128.26]) by ietfa.amsl.com (Postfix) with ESMTP id 542B421F8B03 for ; Mon, 12 Sep 2011 06:15:32 -0700 (PDT) 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.3) with ESMTP id p8CDH9xW025242; Mon, 12 Sep 2011 16:17:33 +0300 Received: from smtp.mgd.nokia.com ([65.54.30.8]) by vaebh102.NOE.Nokia.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.4675); Mon, 12 Sep 2011 16:17:32 +0300 Received: from 008-AM1MMR1-001.mgdnok.nokia.com (65.54.30.56) by NOK-AM1MHUB-04.mgdnok.nokia.com (65.54.30.8) with Microsoft SMTP Server (TLS) id 8.2.255.0; Mon, 12 Sep 2011 15:17:32 +0200 Received: from 008-AM1MPN1-032.mgdnok.nokia.com ([169.254.2.143]) by 008-AM1MMR1-001.mgdnok.nokia.com ([65.54.30.56]) with mapi id 14.01.0323.007; Mon, 12 Sep 2011 15:17:31 +0200 From: To: Thread-Topic: [mif] Last Call for MIF DNS server selection document Thread-Index: AQHMbmf3BHSQ8Tn9hkac95+LwFpGipVEmINQgACieoCABDDqoIAAK92AgAAm/PA= Date: Mon, 12 Sep 2011 13:17:30 +0000 Message-ID: <916CE6CF87173740BC8A2CE44309696202571F34@008-AM1MPN1-032.mgdnok.nokia.com> References: <20110908204329.GN38973@shinkuro.com> <916CE6CF87173740BC8A2CE44309696202570894@008-AM1MPN1-032.mgdnok.nokia.com> <20110909181657.GB46494@shinkuro.com> <916CE6CF87173740BC8A2CE44309696202571ED2@008-AM1MPN1-032.mgdnok.nokia.com> <051540FD-3AA1-4D1E-BAE3-AE7AC42BBBE3@network-heretics.com> In-Reply-To: <051540FD-3AA1-4D1E-BAE3-AE7AC42BBBE3@network-heretics.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes 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+/nZJb9Kg7IijnarCFufw93yGp9Kqg4VsreROV3oSoCKo4MAZQAlH7cl7QEYi2t0p8hTrsrklpyqBfRuV1a3TP5t4zLsal1WzFsT0mQwFWR/yRh3UhJztIIhyLXE7aj3YtN85Eqji4hyMU9zDnsRybCxak6t2mfbgLZX2mjzSIIHnDkgCjyHZFFOhfBqPd/c5FcvKdb64f0sgP1bp0Rng5aZTrafF1qFNxmzB3fX0dr0qbeG9YfeKCcsiZk5WqSUtPkVYQ2fFAPg== x-originating-ip: [10.162.78.119] Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=SHA1; boundary="----=_NextPart_000_0057_01CC7167.77CAEEA0" MIME-Version: 1.0 X-OriginalArrivalTime: 12 Sep 2011 13:17:32.0258 (UTC) FILETIME=[544C5C20:01CC714E] X-Nokia-AV: Clean Cc: mif@ietf.org Subject: Re: [mif] Last Call for MIF DNS server selection document X-BeenThere: mif@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multiple Interface Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 12 Sep 2011 13:15:34 -0000 ------=_NextPart_000_0057_01CC7167.77CAEEA0 Content-Type: multipart/alternative; boundary="----=_NextPart_001_0058_01CC7167.77CAEEA0" ------=_NextPart_001_0058_01CC7167.77CAEEA0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Hi, Well, SHOULD was my original intent there, but let's try to find agreement. "Also, the notion that trustworthiness of an interface and trustworthiness of a DNS server are somehow related strikes me as dubious." This was not my intended meaning, but instead trustworthiness of domain configuration information received from DHCP server of trusted interface. I.e. I was suggesting that if a node for example trust a cellular network, it can trust the DHCPv6 option from DHCPv6 server on cellular interface telling "operator.com" domain is to be resolved via DNS servers of that interface as high preference. I was not trying to that node could trust actual responses from said DNS servers at all (DNSSEC is still needed for that). I can clarify this. Teemu From: ext Keith Moore [mailto:moore@network-heretics.com] Sent: 12. syyskuuta 2011 15:54 To: Savolainen Teemu (Nokia-CTO/Tampere) Cc: ajs@anvilwalrusden.com; mif@ietf.org Subject: Re: [mif] Last Call for MIF DNS server selection document On Sep 12, 2011, at 8:47 AM, wrote: The resolver MUST take into account differences in trust levels of DNS server selection information the resolver has received. The resolver MUST prefer DNS servers of trusted interfaces. The DNS servers of untrusted interfaces may be of highest priority only if trusted interfaces specifically configure low priority DNS servers. -- [...] -- Trustworthiness of an interface and configuration information received over the interface is implementation and/or node deployment dependent. Trust may be based on, for example, on the nature of an interface. For example, an authenticated and encrypted VPN or layer 2 connection to a trusted home network may be considered as trusted, and an unauthenticated and unencrypted connection to an unknown visited network may be considered as untrusted. I don't think it makes sense to impose a MUST requirement in conjunction with something that's so imprecisely defined. Also, the notion that trustworthiness of an interface and trustworthiness of a DNS server are somehow related strikes me as dubious. Keith ------=_NextPart_001_0058_01CC7167.77CAEEA0 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi,

 

Well, SHOULD was my original intent there, but let’s try to = find agreement.

 

“Also, the notion that trustworthiness of an interface = and trustworthiness of a DNS server are somehow related strikes me as = dubious.” This was not my intended meaning, but instead trustworthiness = of domain configuration information received from DHCP server of trusted = interface. I.e. I was suggesting that if a node for example trust a = cellular network, it can trust the DHCPv6 option from DHCPv6 server on = cellular interface telling “operator.com” domain is to be = resolved via DNS servers of that interface as high preference. I was not = trying to that node could trust actual responses from said DNS servers = at all (DNSSEC is still needed for that). I can clarify = this.

 

Teemu

 

From:= = ext Keith Moore [mailto:moore@network-heretics.com]
Sent: 12. = syyskuuta 2011 15:54
To: Savolainen Teemu = (Nokia-CTO/Tampere)
Cc: ajs@anvilwalrusden.com; = mif@ietf.org
Subject: Re: [mif] Last Call for MIF DNS server = selection document

 

 

On = Sep 12, 2011, at 8:47 AM, <teemu.savolainen@nokia.com= > <teemu.savolainen@nokia.com= > wrote:



The = resolver MUST take into account differences in trust levels of DNS = server 
selection information the resolver has = received. The resolver = MUST prefer DNS 
servers of trusted interfaces. The DNS servers of untrusted interfaces may = be 
of highest priority only = if trusted interfaces specifically configure low 
priority DNS = servers.
--
[...]
--
Trustworthiness of an interface and = configuration information received over 
the interface is implementation and/or node = deployment dependent. Trust = may be 
based on, for example, on the nature of an = interface. For example, an 
authenticated and encrypted VPN or layer 2 = connection to a trusted home 
network may be considered as trusted, and an = unauthenticated and unencrypted 
connection to an unknown visited network may be = considered as = untrusted.</t>

 

 

I = don't think it makes sense to impose a MUST requirement in conjunction = with something that's so imprecisely = defined.

 

Also, the notion that trustworthiness of an interface = and trustworthiness of a DNS server are somehow related strikes me as = dubious.

 

Keith

 

------=_NextPart_001_0058_01CC7167.77CAEEA0-- ------=_NextPart_000_0057_01CC7167.77CAEEA0 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIOuzCCAzYw ggIeoAMCAQICBDpVqdkwDQYJKoZIhvcNAQEFBQAwKTEOMAwGA1UEChMFTm9raWExFzAVBgNVBAMT Dk5va2lhICBSb290IENBMB4XDTAxMDEwNTExMDUwNVoXDTE2MDEwMjExMDUwNVowKTEOMAwGA1UE ChMFTm9raWExFzAVBgNVBAMTDk5va2lhICBSb290IENBMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8A MIIBCgKCAQEAsrTy8gLmr4LYvp0khVUVHw7ascdl+Cjr+yI5MlZ6J/U6Qsvkiqthgqq8rPcLV0P1 92TfBr27VgKEeCaZe0icS1jC2spM/wRv3j2WxdkKxb9kDJtuCNJaRBqvi5vGTHB15nmEmKuL5f3i rAxeHqPjgS496oWcudzFT1e7Xrc/gWGFYd72+/ykIFXjWOMZv6QpxD8x1hLPyh2YVXRk9U7N7pvm RQNX29g4SCFJY2BBIa5JPlwIF8Nc9IePaC/E/2M4tGMtiOOZlm99EoL7N0hJZtFSvUwdCBud/viH 4DgsKGjNkNKi6pAHc9IaXB6tIykcoYp+L+oe/3+cuEJaCj1EKwIDAQABo2YwZDASBgNVHRMBAf8E CDAGAQH/AgEEMB0GA1UdDgQWBBSNjfefoQ0AITLvqe0iruA79NB9sDAfBgNVHSMEGDAWgBSNjfef oQ0AITLvqe0iruA79NB9sDAOBgNVHQ8BAf8EBAMCAYYwDQYJKoZIhvcNAQEFBQADggEBAIGEPql2 TALyKi/h1J+Mh5XolAtYppcSOLMtBkoA7ZovGBDNvl0VbZs8AAojJqkUoWBB+L6DKyl/jKhNfKcu rWRGRyj7pnbxrKLsI3gmWNWkyo2b60wJwe9fqPD5ZQy3oEiMit9l0Ba6il/k2GqYopUCNMa7mfeb E2LeBy5ChYMiCi97UQSJvAdzEYylTJw8Awc6AiM2Ve5N+XxsmKgNf/2A/5IJ3EZZ+wFRmkI4062A oNU302rqAt0HH88jzoUF4AfYHWl6HpYhGXFbcX44rHINyPmFBRxLYIFJ6ZWUr/mXpL/e6rqFtNWO kV6UoJND7OVZkbLh7F1+lcqXRU8TPBMwggOHMIICb6ADAgECAgRBtbHpMA0GCSqGSIb3DQEBBQUA MCkxDjAMBgNVBAoTBU5va2lhMRcwFQYDVQQDEw5Ob2tpYSAgUm9vdCBDQTAeFw0wNjAzMzAwOTU3 MTFaFw0xNjAxMDIxMTA1MDVaMDMxCzAJBgNVBAYTAkZJMQ4wDAYDVQQKEwVOb2tpYTEUMBIGA1UE AxMLTm9raWEgQkkgQ0EwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQDtFCg3QEjSCg6T IUxoWsNwELh8bBNiUQPCPmg8c2DHQYXWWCSCMb+S0Fvh1qqI1xt+XnzyFq+5eqzGzDj4UaBcG+d9 qxrCFly8sHyoPTryyPrR0EI2UUDWwfS6ojhqgwghRqo8G38TjFusyBtLub/5L6yvWYSOHD+JcB+q VM2fbkArPYK4Ydv8WG/DbHjGn0gKq0zwpVZKI/gCK/QALYvte02NXseqvY9/GOyLtjy3Z8erFv71 KKTq+gxI/7DK55pJf3PoD+kT4kyGm6EF9DTdK4ojMdar17uyX0IOZz/4vkkF0d+60nmnLX63FJPA jUyB0HUNJ32NXDo9UsM38aoNAgMBAAGjgawwgakwDwYDVR0TAQH/BAUwAwEB/zARBgNVHSAECjAI MAYGBFUdIAAwDgYDVR0PAQH/BAQDAgGGMFQGA1UdIwRNMEuAFI2N95+hDQAhMu+p7SKu4Dv00H2w oS2kKzApMQ4wDAYDVQQKEwVOb2tpYTEXMBUGA1UEAxMOTm9raWEgIFJvb3QgQ0GCBDpVqdkwHQYD VR0OBBYEFKcksD7Fg+8EDlB2Sxgy58pW0Sy6MA0GCSqGSIb3DQEBBQUAA4IBAQAC3lEUplDlVNOT Pjz/XFezXx2bV2XbCFindhA3F815Egi55H6/cYezEjoP4QLNEGGl2I3aLvkn5A0T8I4pbiFPhIiu B/frbbGg6k6GjQLe/bFQ8F1mAOOR+GyneKZFPfzaRV0jiIR9QqnMXTf8RvKkCJyFj10MZVsLIy/Y uBkzeP3JhzDhUdtPfwmJN6ZbIhH5uR/2BwAGtgQknb8WX3I4wnhWtMUxB8XmayayYs8qWYeIiVkI FV+sLTkWUWVvvKUjyakBpbAW2vUP84DYsJ8TL1YefNjf/nIOByMcORLuV/1gPjyv00qJbcB59AA+ iXe3zIo8QNcgXG0uPQQFmrGDMIID5DCCAsygAwIBAgIQMH5apak8lEy6LmLlLsJy8TANBgkqhkiG 9w0BAQUFADAzMQswCQYDVQQGEwJGSTEOMAwGA1UEChMFTm9raWExFDASBgNVBAMTC05va2lhIEJJ IENBMB4XDTExMDkwNjA1NTIwNFoXDTE0MDkwNjA1NTIwNFowVjEOMAwGA1UECgwFTm9raWExDzAN BgNVBAsMBlBlb3BsZTEYMBYGCgmSJomT8ixkAQEMCDEwMDI0Njc2MRkwFwYDVQQDDBBTYXZvbGFp bmVuIFRlZW11MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAshEsmw6Yiz6XWX26oF+I s5fsfE1OfCjOelclmtqCiIgXND5klkNOBs2d4ZGzgD9mN+XnTZnOTh249c2WxPBugf12DCcDmBAJ gL+VuWUJVBTE5NRchm/O8nZnZsRFst+gAC9/Juykh4+EYewZ7QbpnlwW7hNpj8eH+rMr+OZHKzdp KTftgVjmuF4JJ/cPMQUjL8SuGj+zBW6IWPOZdqkEMtf7Pr8kkYbZsh0SgJ0ceRHZ7Uc06mB/y+C1 UnJPxehTTdu8tpCjdzXgBw/H2uuW1J3qdHbCfbuDILql8V8RiZKubcZLhdsD3Jvj8qK0DGWBJa6x p90q5p3pLE8LvAeCgQIDAQABo4HQMIHNMA4GA1UdDwEB/wQEAwIEMDAfBgNVHSMEGDAWgBSnJLA+ xYPvBA5QdksYMufKVtEsujAZBgNVHSAEEjAQMA4GDCsGAQQBXgExBgEHAzA5BgNVHR8EMjAwMC6g LKAqhihodHRwOi8vY3JsLm5va2lhLmNvbS9Ob2tpYSUyMEJJJTIwQ0EuY3JsMCUGA1UdEQQeMByB GnRlZW11LnNhdm9sYWluZW5Abm9raWEuY29tMB0GA1UdDgQWBBQTRzvZsgmQrAGCeuzdHTGAC6Jg UzANBgkqhkiG9w0BAQUFAAOCAQEACmPVsdi07pjK5gDa+W5JlE2C74kVVsB8alBqfioYeR5At2FG B7sua4Dz5H7TJMpZ1jYFeI+zjexD5f+beY2IlV15lMoWD+5e38QlLYjwfe2LAyvdzBKXW0e0U6Bt p78ft4gyVak1X+Db+ebR+FNHUOMNhm+yK3w9sy5ZQzBFusIx4OgxGvcZhyhmd9WjipSTalgPwgqV Ju2aPADCG++OEXmgEWRLsR4yNopkgK4ftVqrN5uUtLs83qdeXTRcNRiET1IOx5zmYFZ6q3gjKIx5 iyuxcDeYas93vVHUcaRRYpsoby5CHq7Z/j/TQhtqO/knWuxLFFiCUgdGKMKrRkg29DCCBAowggLy oAMCAQICEQCBvi+p+bA/dBtBtybwA6YYMA0GCSqGSIb3DQEBBQUAMDMxCzAJBgNVBAYTAkZJMQ4w DAYDVQQKEwVOb2tpYTEUMBIGA1UEAxMLTm9raWEgQkkgQ0EwHhcNMTEwOTA2MDU1MDM0WhcNMTMw OTA1MDU1MDM0WjBWMQ4wDAYDVQQKDAVOb2tpYTEPMA0GA1UECwwGUGVvcGxlMRgwFgYKCZImiZPy LGQBAQwIMTAwMjQ2NzYxGTAXBgNVBAMMEFNhdm9sYWluZW4gVGVlbXUwggEiMA0GCSqGSIb3DQEB AQUAA4IBDwAwggEKAoIBAQDFPmbRVwuo52v+h6xnQUqokAx2xsHjmPBniEkzgtgBNJsFi838ATEg 1zsx+VotoJg7hMijcrQfpTAgW6gpLGnlmw5QQswrNK1zleOHb4pA5JguU3WhVKFkAH/6/2EU2k/9 m8Pb/gwP55cYg80R6fRmbdsWKhseXF/1isW/rJcWLmIYDg/rXfo3ixqtT9MroAMiuoXnb0ij1L2d Jj64LDp3Ld8Jo0qZzk3Fj4apo8PBd8eAH6HloVBJkxQcwAnv561A+Xi1GHZ2mafRYJGO+1uBDwyd g/8ybEXXA4MKo8lPKjBebYBUFvz80DBA/Lq74UysXkG23BSulcG4xQSYGlyzAgMBAAGjgfUwgfIw HwYDVR0jBBgwFoAUpySwPsWD7wQOUHZLGDLnylbRLLowGQYDVR0gBBIwEDAOBgwrBgEEAV4BMQYB BgQwOQYDVR0fBDIwMDAuoCygKoYoaHR0cDovL2NybC5ub2tpYS5jb20vTm9raWElMjBCSSUyMENB LmNybDAjBgNVHSUEHDAaBggrBgEFBQcDAgYEVR0lAAYIKwYBBQUHAwQwDgYDVR0PAQH/BAQDAgeA MCUGA1UdEQQeMByBGnRlZW11LnNhdm9sYWluZW5Abm9raWEuY29tMB0GA1UdDgQWBBTGhbTJF0EX iagjymQo6GIuSQeRVDANBgkqhkiG9w0BAQUFAAOCAQEAqai6TxZ/BlMHZIhJNPriBPXkQhUlBkGA buJZ5sVm1HIQhWN8elZKjjJdHi1qWEKhMg7yHjEMZsyV8XAZzK0UnOqkpUnt+jnVkNZ9O7/jRtyK f4WUtq5jErc8Hlv4bbGFRHk1T7AuLLE52r1lYOdmoibnQp03QtlDvHUNa68G7jvzThJhieB7U1xh vH3yy0ktaVnWEgAylqf9yIUFjnqau5R6cE1Xo57IYPk/KitX0YF+OigEI/bOQVMi+fze93ZsAOJv /z6g/NGemvUgl5YSdX0uPQK6kEHf/sp/nZyUWWQ7OjtVSqkq2YuYEueQFxTfafl+78GWqgm6W/Bl 32laYzGCAuswggLnAgEBMEgwMzELMAkGA1UEBhMCRkkxDjAMBgNVBAoTBU5va2lhMRQwEgYDVQQD EwtOb2tpYSBCSSBDQQIRAIG+L6n5sD90G0G3JvADphgwCQYFKw4DAhoFAKCCAXgwGAYJKoZIhvcN AQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG9w0BCQUxDxcNMTEwOTEyMTMxNzI5WjAjBgkqhkiG9w0B CQQxFgQUJVnXj5iLNFUIgFzXzH4Zp/8BBb4wVgYJKwYBBAGCNxAEMUkwRzAzMQswCQYDVQQGEwJG STEOMAwGA1UEChMFTm9raWExFDASBgNVBAMTC05va2lhIEJJIENBAhAwflqlqTyUTLouYuUuwnLx MFgGCyqGSIb3DQEJEAILMUmgRzAzMQswCQYDVQQGEwJGSTEOMAwGA1UEChMFTm9raWExFDASBgNV BAMTC05va2lhIEJJIENBAhAwflqlqTyUTLouYuUuwnLxMGcGCSqGSIb3DQEJDzFaMFgwCgYIKoZI hvcNAwcwDgYIKoZIhvcNAwICAgCAMA0GCCqGSIb3DQMCAgFAMAcGBSsOAwIHMA0GCCqGSIb3DQMC AgEoMAcGBSsOAwIaMAoGCCqGSIb3DQIFMA0GCSqGSIb3DQEBAQUABIIBALB0PaqxsKj+AbpUi/ZN Q9Xhk8EjmFifAXd8kWWyQbr1XjInk+DoGFF4a9HKz3KKum/YsrwiylSJzXYA2b0IxR3rFJuS6dFj svrLj53PF1QNc0/RNpfKdFpCdA8Zt91lMWt3hKgRha6gprzRmlwvFEqfWze8yCuwQHyeYIF+vJWR vxFaPN3v6rnX+rHEDqAOvNKdZ7oSQjQQiWdxLp7T1qEKE5PXsRZnziX72blHp+e2UMg55jpOt21J f4TbXJuO0B6qYlsTVorAFM+8uJDZkqR3VqvngjIx8gHgSROtSYACqsoRsKn8CpSvnkguj/WmNbFg VvZczlZJ7Pr/bON62DgAAAAAAAA= ------=_NextPart_000_0057_01CC7167.77CAEEA0-- From alexandru.petrescu@gmail.com Mon Sep 12 06:28: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 0229C21F8B48 for ; Mon, 12 Sep 2011 06:28:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.46 X-Spam-Level: X-Spam-Status: No, score=-2.46 tagged_above=-999 required=5 tests=[AWL=-0.211, BAYES_00=-2.599, HELO_EQ_FR=0.35] 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 dkep5LiTT09w for ; Mon, 12 Sep 2011 06:28:42 -0700 (PDT) Received: from oxalide-out.extra.cea.fr (oxalide-out.extra.cea.fr [132.168.224.8]) by ietfa.amsl.com (Postfix) with ESMTP id 067DD21F8B47 for ; Mon, 12 Sep 2011 06:28:41 -0700 (PDT) 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 p8CDUgOQ007693 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT) for ; Mon, 12 Sep 2011 15:30:42 +0200 Received: from muguet1.intra.cea.fr (muguet1.intra.cea.fr [132.166.192.6]) by pisaure.intra.cea.fr (8.14.4/8.14.4) with ESMTP id p8CDUgjT010207 for ; Mon, 12 Sep 2011 15:30:42 +0200 (envelope-from alexandru.petrescu@gmail.com) Received: from [127.0.0.1] ([132.166.133.183]) by muguet1.intra.cea.fr (8.13.8/8.13.8/CEAnet-Intranet-out-1.1) with ESMTP id p8CDUdnJ018071 for ; Mon, 12 Sep 2011 15:30:42 +0200 Message-ID: <4E6E097F.8010205@gmail.com> Date: Mon, 12 Sep 2011 15:30:39 +0200 From: Alexandru Petrescu User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:6.0.2) Gecko/20110902 Thunderbird/6.0.2 MIME-Version: 1.0 To: mif@ietf.org References: <20110910220345.29077.66749.idtracker@ietfa.amsl.com> <4E6BE7BF.5030501@gmail.com> <4E6C8F4A.308@gmail.com> <4E6E053B.7000305@viagenie.ca> In-Reply-To: <4E6E053B.7000305@viagenie.ca> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Subject: Re: [mif] I-D draft-ietf-mif-dhcpv6-route-option-03 published X-BeenThere: mif@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multiple Interface Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 12 Sep 2011 13:28:43 -0000 Le 12/09/2011 15:12, Simon Perreault a 閏rit : > On 2011-09-11 06:36, maximilien mouton wrote: >> I thus think that a client should be able to require only a >> default route (and no other route). > > Why? What's the use case? CErtainly there are exist use cases for machines using only default route, and no other route. Typically with single-interfaced Hosts. One particular example is the typical office desktop PCs, which are typically leafs to the Internet, and only browse web; the net appliances. Another is typical PDA, cellphone, smartphone which only has a default route and no specific route to its neighbors (operator typically opposes this, because needs to charge uniformly). > Are you working with hosts that do not have a generic routing table > and only support a single default route? I am not sure about the term generic routing table... I think most Hosts which support routes, support several of them, and several of default routes. But, one may think about the very small platforms which have very little memory and may hold a very limited number of routes... in these cases the default route is the one kind of route which allows it to reach the widest number of other Hosts in the Internet (every other non-default but specific route helps it reach a smaller number of Hosts). What do you think? Alex > > Simon From simon.perreault@viagenie.ca Mon Sep 12 06:40: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 EF50D21F8B66 for ; Mon, 12 Sep 2011 06:40:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, NO_RELAYS=-0.001] 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 P3Ss+SuzKT-J for ; Mon, 12 Sep 2011 06:40:31 -0700 (PDT) Received: from jazz.viagenie.ca (unknown [IPv6:2620:0:230:8000:226:55ff:fe57:14db]) by ietfa.amsl.com (Postfix) with ESMTP id 6EF1421F8B64 for ; Mon, 12 Sep 2011 06:40:31 -0700 (PDT) Received: from ringo.viagenie.ca (unknown [IPv6:2620:0:230:c000:21d:60ff:fed7:e732]) by jazz.viagenie.ca (Postfix) with ESMTPSA id AB0E621100 for ; Mon, 12 Sep 2011 09:42:34 -0400 (EDT) Message-ID: <4E6E0C4A.7030105@viagenie.ca> Date: Mon, 12 Sep 2011 09:42:34 -0400 From: Simon Perreault User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:5.0) Gecko/20110720 Thunderbird/5.0 MIME-Version: 1.0 To: mif@ietf.org References: <20110910220345.29077.66749.idtracker@ietfa.amsl.com> <4E6BE7BF.5030501@gmail.com> <4E6C8F4A.308@gmail.com> <4E6E053B.7000305@viagenie.ca> <4E6E097F.8010205@gmail.com> In-Reply-To: <4E6E097F.8010205@gmail.com> X-Enigmail-Version: 1.2.1 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit Subject: Re: [mif] I-D draft-ietf-mif-dhcpv6-route-option-03 published X-BeenThere: mif@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multiple Interface Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 12 Sep 2011 13:40:32 -0000 On 2011-09-12 09:30, Alexandru Petrescu wrote: > Le 12/09/2011 15:12, Simon Perreault a 閏rit : >> On 2011-09-11 06:36, maximilien mouton wrote: >>> I thus think that a client should be able to require only a >>> default route (and no other route). >> >> Why? What's the use case? > > CErtainly there are exist use cases for machines using only default > route, and no other route. Typically with single-interfaced Hosts. > > One particular example is the typical office desktop PCs, which are > typically leafs to the Internet, and only browse web; the net appliances. > > Another is typical PDA, cellphone, smartphone which only has a default > route and no specific route to its neighbors (operator typically opposes > this, because needs to charge uniformly). What you're describing is typical usage. I agree that the typical usage will be default routes, but there is no harm if these devices receive specific routes. Both of these examples typically have a regular routing table and can install and use specific routes. So where's the harm if they receive specific routes? >> Are you working with hosts that do not have a generic routing table >> and only support a single default route? > > I am not sure about the term generic routing table... I think most Hosts > which support routes, support several of them, and several of default > routes. > > But, one may think about the very small platforms which have very little > memory and may hold a very limited number of routes... in these cases > the default route is the one kind of route which allows it to reach the > widest number of other Hosts in the Internet (every other non-default > but specific route helps it reach a smaller number of Hosts). > > What do you think? I don't see the use case. Can't the DHCP client on the very small platform just install the default route first, then whatever other routes it can support, and ignore the rest? The number of routes will also be limited by MTU, so it will end up being very low anyway. Simon -- DTN made easy, lean, and smart --> http://postellation.viagenie.ca NAT64/DNS64 open-source --> http://ecdysis.viagenie.ca STUN/TURN server --> http://numb.viagenie.ca From alexandru.petrescu@gmail.com Mon Sep 12 06:54:38 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 52CEE21F8B63; Mon, 12 Sep 2011 06:54:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.452 X-Spam-Level: X-Spam-Status: No, score=-2.452 tagged_above=-999 required=5 tests=[AWL=-0.203, BAYES_00=-2.599, HELO_EQ_FR=0.35] 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 ulaEfcCeHNeO; Mon, 12 Sep 2011 06:54:37 -0700 (PDT) Received: from oxalide-out.extra.cea.fr (oxalide-out.extra.cea.fr [132.168.224.8]) by ietfa.amsl.com (Postfix) with ESMTP id 1FEB721F8B5B; Mon, 12 Sep 2011 06:54:36 -0700 (PDT) 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 p8CDucaL017891 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Mon, 12 Sep 2011 15:56:38 +0200 Received: from muguet1.intra.cea.fr (muguet1.intra.cea.fr [132.166.192.6]) by pisaure.intra.cea.fr (8.14.4/8.14.4) with ESMTP id p8CDucla018187; Mon, 12 Sep 2011 15:56:38 +0200 (envelope-from alexandru.petrescu@gmail.com) Received: from [127.0.0.1] ([132.166.133.183]) by muguet1.intra.cea.fr (8.13.8/8.13.8/CEAnet-Intranet-out-1.1) with ESMTP id p8CDuYCZ007808; Mon, 12 Sep 2011 15:56:38 +0200 Message-ID: <4E6E0F93.30700@gmail.com> Date: Mon, 12 Sep 2011 15:56:35 +0200 From: Alexandru Petrescu User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:6.0.2) Gecko/20110902 Thunderbird/6.0.2 MIME-Version: 1.0 To: Tomasz Mrugalski References: <20110910220345.29077.66749.idtracker@ietfa.amsl.com> <4E6BE7BF.5030501@gmail.com> In-Reply-To: <4E6BE7BF.5030501@gmail.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Cc: dhcwg@ietf.org, mif@ietf.org Subject: Re: [mif] [dhcwg] I-D draft-ietf-mif-dhcpv6-route-option-03 published X-BeenThere: mif@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multiple Interface Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 12 Sep 2011 13:54:38 -0000 Tomasz, Thank you for this update. I am happy our earlier email and f2f discussion is taken into account. Thanks. I have some remarks though. I wonder whether it is necessary to treat of default routes in draft-ietf-mif-dhcpv6-route-option. Remark: I do not oppose the use of default routes in DHCPv6, but question the best place to do it. Other remarks below. Le 11/09/2011 00:42, Tomasz Mrugalski a 閏rit : > On 11.09.2011 00:03, internet-drafts@ietf.org wrote: [...] > Dear MIF and DHC groups, > > This draft was presented in DHC WG in Quebec. While the primary area > of review was from DHCP protocol perspective, there were quite a > few insightful comments received related to other aspects. I was also > presented again in MIF WG. Thanks for the presentations that we have followed carefully. > After a long discussion we reached consensus and solved concerns > raised during review by Routing Directorate. > > Authors would like to thank Joel Halpern, Marcin Siodelski and > Alexandru Petrescu for their insightful comments and through review. I am interested about the review from the Routing Directorate - is it public somewhere? > Significant changes since -03 version: - added a route lifetime > field. This provides a way to age and expire a route Yes, lifetime is needed for default route, because the default route needs to sit in the ND "default router list" structure, structure described in RFC4861, pp. 34, last par. > - route lifetime can be used to revoke a route during renewal "revoke" sounds as if some server revokes the route from the client... but I believe one means to simply have the Client delete that route, or simply the route to disappear. (?) I agree. > - IA_RT prefix removed. It was only a container option, so this > removal does not change the way this option works Yes, but it is much change in the way the draft is written, and the implementation as well. > - clarified that default route may be configured with this mechanism > - provided a way to configure default route in bandwidth-constrained > networks - clarified that this mechanism may be used on routers (e.g. > residential gateways) It should be used on more than residential gateways. The typical use case is consider is about sensors, machines and cellular smartphones. But there should be only one way to configure default routes with DHCP, I think (and not two different DHCP ways of configuring the default route). > - added a way to configure on-link routes I think as well that on-link routes ("Connected" routes by Cisco terminology I believe) are useful for distribution with DHCP. I would go even further about this, but not necessarily to request addition in your draft. There may exist a need to have default routes using prefix ::/0 and next-hop the particular ::/0 as well (and not a generic IPv6 address like e.g. 2001:db8::1/128); the only distinction among the default routes would be the interface name. The specification could be "a 3GPP device receiving DHCP Advertise containing the specific default-route-option needs to insert a routing table entry for the special default route ::/0 ::/0 interface-name by identifying the interface on which that Advertise was received". This need may exist because currently some 3G+ implementations of client handset (not using DHCP, not IPv6) have default routes of the form "0.0.0.0 0.0.0.0 hso0"; specifying DHCP to accommodate this kind of default route is not straightforward, but may be needed. > - added a limitation section pointing out that using this mechanism > in networks that do dynamic routing is usually a bad idea I agree that dynamic routing and DHCP route option may come to be contradictory. But the existing recommendation "SHOULD NOT" DHCPv6 && rt protocol sounds a bit strong to me... > The only comment that we chose not to implement is a suggestion to > include MAC address information. We believe that would be wrong for > number of reasons. Please explain these reasons. We believe in the advantage offered by MAC address present in the DHCP messages - avoids additional NS/NA roundtrips of the Client. > If reviewers still thinks this is useful, we would like to point out > a possible solution. As proposed options are designed to be > extensible, reviewers who proposed adding MAC address can simply > define a suboption that will provide necessary information in cases, > where such information cannot be obtained in the usual way. Such > approach is also better, because in most cases this information is > not needed and may even be harmful. This kind of information should > be requested only in those limited cases, where it is really needed. > If proponents choose to define such extensions, our belief is that > extra explanation why such information is needed would be very useful > to understand their use case. I understand. We would like to add the MAC address in this DHCP exchange about default route. But we find it difficult to extend the existing draft-ietf-mif-dhcpv6-route-option-03 messages. They continue to be updated (new version of draft) and we are not consulted about the way they are updated. In this sense we think our ways of extending the default route DHCP exhanges can be accommodated only if expressed in a way we can influence. > There are no outstanding issues with this draft. This draft has been > reviewed by Routing Directorate, by DHC WG and was presented several > times in MIF meetings and in DHC meeting. As one of the authors (and > I believe I speak on behalf of all authors) I think this draft is > ready for last call. Therefore I would like to ask MIF chairs to > announce WGLC. I believe this draft is not ready for Last Call. It is too early for Last Call, because there exist a similar draft about the particular aspect of default route (draft-mouton-mif-dhcpv6-drlo-00.txt "Default Router List Option for DHCPv6 (DRLO)"). Alex > > Of course any additional comments are more than welcome. > > Cheers, Tomek Mrugalski > _______________________________________________ dhcwg mailing list > dhcwg@ietf.org https://www.ietf.org/mailman/listinfo/dhcwg > From alexandru.petrescu@gmail.com Mon Sep 12 07:00: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 DBEA621F8B7C for ; Mon, 12 Sep 2011 07:00:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.444 X-Spam-Level: X-Spam-Status: No, score=-2.444 tagged_above=-999 required=5 tests=[AWL=-0.195, BAYES_00=-2.599, HELO_EQ_FR=0.35] 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 AypGGwLfnnib for ; Mon, 12 Sep 2011 07:00:09 -0700 (PDT) Received: from cirse-out.extra.cea.fr (cirse-out.extra.cea.fr [132.167.192.142]) by ietfa.amsl.com (Postfix) with ESMTP id 05B8021F8B79 for ; Mon, 12 Sep 2011 07:00:08 -0700 (PDT) Received: from pisaure.intra.cea.fr (pisaure.intra.cea.fr [132.166.88.21]) by cirse.extra.cea.fr (8.14.2/8.14.2/CEAnet-Internet-out-2.2) with ESMTP id p8CE2BWG027663 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT) for ; Mon, 12 Sep 2011 16:02:11 +0200 Received: from muguet2.intra.cea.fr (muguet2.intra.cea.fr [132.166.192.7]) by pisaure.intra.cea.fr (8.14.4/8.14.4) with ESMTP id p8CE2AVa019637 for ; Mon, 12 Sep 2011 16:02:10 +0200 (envelope-from alexandru.petrescu@gmail.com) Received: from [127.0.0.1] ([132.166.133.183]) by muguet2.intra.cea.fr (8.13.8/8.13.8/CEAnet-Intranet-out-1.1) with ESMTP id p8CE28MF014472 for ; Mon, 12 Sep 2011 16:02:10 +0200 Message-ID: <4E6E10E0.6010607@gmail.com> Date: Mon, 12 Sep 2011 16:02:08 +0200 From: Alexandru Petrescu User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:6.0.2) Gecko/20110902 Thunderbird/6.0.2 MIME-Version: 1.0 To: mif@ietf.org References: <20110910220345.29077.66749.idtracker@ietfa.amsl.com> <4E6BE7BF.5030501@gmail.com> <4E6C8F4A.308@gmail.com> <4E6E053B.7000305@viagenie.ca> <4E6E097F.8010205@gmail.com> <4E6E0C4A.7030105@viagenie.ca> In-Reply-To: <4E6E0C4A.7030105@viagenie.ca> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Subject: Re: [mif] I-D draft-ietf-mif-dhcpv6-route-option-03 published X-BeenThere: mif@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multiple Interface Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 12 Sep 2011 14:00:10 -0000 Le 12/09/2011 15:42, Simon Perreault a 閏rit : > On 2011-09-12 09:30, Alexandru Petrescu wrote: >> Le 12/09/2011 15:12, Simon Perreault a 閏rit : >>> On 2011-09-11 06:36, maximilien mouton wrote: >>>> I thus think that a client should be able to require only a >>>> default route (and no other route). >>> >>> Why? What's the use case? >> >> CErtainly there are exist use cases for machines using only >> default route, and no other route. Typically with >> single-interfaced Hosts. >> >> One particular example is the typical office desktop PCs, which >> are typically leafs to the Internet, and only browse web; the net >> appliances. >> >> Another is typical PDA, cellphone, smartphone which only has a >> default route and no specific route to its neighbors (operator >> typically opposes this, because needs to charge uniformly). > > What you're describing is typical usage. I agree that the typical > usage will be default routes, but there is no harm if these devices > receive specific routes. I do not oppose devices to receive specific routes from DHCP Server. They are needed for particular cases, for example in vehicular communications. > Both of these examples typically have a regular routing table and can > install and use specific routes. So where's the harm if they receive > specific routes? No harm in specific routes. But default routes are the ones which must always work, they represent the last resort when everything else fails. It is for this reason I believe the default routes deserve special treatment - special option type - in the DHCP messages. >>> Are you working with hosts that do not have a generic routing >>> table and only support a single default route? >> >> I am not sure about the term generic routing table... I think most >> Hosts which support routes, support several of them, and several of >> default routes. >> >> But, one may think about the very small platforms which have very >> little memory and may hold a very limited number of routes... in >> these cases the default route is the one kind of route which allows >> it to reach the widest number of other Hosts in the Internet (every >> other non-default but specific route helps it reach a smaller >> number of Hosts). >> >> What do you think? > > I don't see the use case. Can't the DHCP client on the very small > platform just install the default route first, then whatever other > routes it can support, and ignore the rest? Do you think there exist a DHCP way to say: "install the default route first and, if you have enough memory, install these specific routes"? > The number of routes will also be limited by MTU, so it will end up > being very low anyway. Hmmm... maybe. Alex > > Simon From simon.perreault@viagenie.ca Mon Sep 12 07:12: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 E7B0821F8B5D for ; Mon, 12 Sep 2011 07:12:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, NO_RELAYS=-0.001] 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 vlw1gmQQk2TY for ; Mon, 12 Sep 2011 07:12:53 -0700 (PDT) Received: from jazz.viagenie.ca (unknown [IPv6:2620:0:230:8000:226:55ff:fe57:14db]) by ietfa.amsl.com (Postfix) with ESMTP id 75D4521F8569 for ; Mon, 12 Sep 2011 07:12:53 -0700 (PDT) Received: from ringo.viagenie.ca (unknown [IPv6:2620:0:230:c000:21d:60ff:fed7:e732]) by jazz.viagenie.ca (Postfix) with ESMTPSA id C933821100 for ; Mon, 12 Sep 2011 10:14:56 -0400 (EDT) Message-ID: <4E6E13E0.2030402@viagenie.ca> Date: Mon, 12 Sep 2011 10:14:56 -0400 From: Simon Perreault User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:5.0) Gecko/20110720 Thunderbird/5.0 MIME-Version: 1.0 To: mif@ietf.org References: <20110910220345.29077.66749.idtracker@ietfa.amsl.com> <4E6BE7BF.5030501@gmail.com> <4E6C8F4A.308@gmail.com> <4E6E053B.7000305@viagenie.ca> <4E6E097F.8010205@gmail.com> <4E6E0C4A.7030105@viagenie.ca> <4E6E10E0.6010607@gmail.com> In-Reply-To: <4E6E10E0.6010607@gmail.com> X-Enigmail-Version: 1.2.1 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: Re: [mif] I-D draft-ietf-mif-dhcpv6-route-option-03 published X-BeenThere: mif@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multiple Interface Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 12 Sep 2011 14:12:54 -0000 On 2011-09-12 10:02, Alexandru Petrescu wrote: >> I don't see the use case. Can't the DHCP client on the very small >> platform just install the default route first, then whatever other >> routes it can support, and ignore the rest? > > Do you think there exist a DHCP way to say: "install the default route > first and, if you have enough memory, install these specific routes"? Maybe it can be written in the draft. For example: Hosts MUST install routes in the order they are listed. If any routes cannot be installed due to resource constraints, routes MAY be dropped starting from the end. With this, the operator can put the default route first and obtain the behaviour you're describing. Simon -- DTN made easy, lean, and smart --> http://postellation.viagenie.ca NAT64/DNS64 open-source --> http://ecdysis.viagenie.ca STUN/TURN server --> http://numb.viagenie.ca From alexandru.petrescu@gmail.com Mon Sep 12 07:17: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 7CF0121F8B4C for ; Mon, 12 Sep 2011 07:17:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.437 X-Spam-Level: X-Spam-Status: No, score=-2.437 tagged_above=-999 required=5 tests=[AWL=-0.188, BAYES_00=-2.599, HELO_EQ_FR=0.35] 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 dD0B6sMmWgGJ for ; Mon, 12 Sep 2011 07:17:51 -0700 (PDT) Received: from oxalide-out.extra.cea.fr (oxalide-out.extra.cea.fr [132.168.224.8]) by ietfa.amsl.com (Postfix) with ESMTP id BBDED21F8B73 for ; Mon, 12 Sep 2011 07:17:50 -0700 (PDT) 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 p8CEJrWE026090 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT) for ; Mon, 12 Sep 2011 16:19:53 +0200 Received: from muguet1.intra.cea.fr (muguet1.intra.cea.fr [132.166.192.6]) by pisaure.intra.cea.fr (8.14.4/8.14.4) with ESMTP id p8CEJrcR026723 for ; Mon, 12 Sep 2011 16:19:53 +0200 (envelope-from alexandru.petrescu@gmail.com) Received: from [127.0.0.1] ([132.166.133.183]) by muguet1.intra.cea.fr (8.13.8/8.13.8/CEAnet-Intranet-out-1.1) with ESMTP id p8CEJoIR029238 for ; Mon, 12 Sep 2011 16:19:53 +0200 Message-ID: <4E6E1506.9000602@gmail.com> Date: Mon, 12 Sep 2011 16:19:50 +0200 From: Alexandru Petrescu User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:6.0.2) Gecko/20110902 Thunderbird/6.0.2 MIME-Version: 1.0 To: mif@ietf.org References: <20110910220345.29077.66749.idtracker@ietfa.amsl.com> <4E6BE7BF.5030501@gmail.com> <4E6C8F4A.308@gmail.com> <4E6E053B.7000305@viagenie.ca> <4E6E097F.8010205@gmail.com> <4E6E0C4A.7030105@viagenie.ca> <4E6E10E0.6010607@gmail.com> <4E6E13E0.2030402@viagenie.ca> In-Reply-To: <4E6E13E0.2030402@viagenie.ca> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Subject: Re: [mif] I-D draft-ietf-mif-dhcpv6-route-option-03 published X-BeenThere: mif@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multiple Interface Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 12 Sep 2011 14:17:51 -0000 Le 12/09/2011 16:14, Simon Perreault a 閏rit : > On 2011-09-12 10:02, Alexandru Petrescu wrote: >>> I don't see the use case. Can't the DHCP client on the very >>> small platform just install the default route first, then >>> whatever other routes it can support, and ignore the rest? >> >> Do you think there exist a DHCP way to say: "install the default >> route first and, if you have enough memory, install these specific >> routes"? > > Maybe it can be written in the draft. For example: > > Hosts MUST install routes in the order they are listed. If any > routes cannot be installed due to resource constraints, routes MAY be > dropped starting from the end. I think this could be achieved if we had 2 different types: one type for default routes and one type for specific routes. With that, the specification would say that the type dr must always be installed, whereas the ones sr (specific) would be installed only if place is left, or similar. In this way, the action of installing is at the Client's intelligence and will, not at the Server's (the Server would list these options in the message, without knowing how much memory has the Client). > With this, the operator can put the default route first and obtain > the behaviour you're describing. Yes, if Server knew how much memory the Client had. Alex > > Simon From maximilien.mouton@gmail.com Mon Sep 12 14:30: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 164C021F8E3A for ; Mon, 12 Sep 2011 14:30:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QU9E5UKJOpBB for ; Mon, 12 Sep 2011 14:30:47 -0700 (PDT) Received: from mail-fx0-f44.google.com (mail-fx0-f44.google.com [209.85.161.44]) by ietfa.amsl.com (Postfix) with ESMTP id 4815B21F8E22 for ; Mon, 12 Sep 2011 14:30:47 -0700 (PDT) Received: by fxd18 with SMTP id 18so1592110fxd.31 for ; Mon, 12 Sep 2011 14:32:51 -0700 (PDT) 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:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; bh=2z+zA70HVvxF4WTIickWfTpwwGp0gFjFxKpaCCxTmDE=; b=Mn6tHxEWmNwTNalm/wBWWBK4XutdANXlf9B9wVJSgg336rj+FIv0ETDbwas3uuDHGg aMyEKnSyJtthVtsHYyh/UrdIDy7/8+filq0qgbbVowvlCr5pzuw2nU/d4gbWlKNQUd00 4jeX6KKv4bkGz5xpod0r5aAB+plY5WN2T+W3Q= Received: by 10.223.53.84 with SMTP id l20mr611492fag.89.1315863171009; Mon, 12 Sep 2011 14:32:51 -0700 (PDT) Received: from [127.0.0.1] (scy57-1-88-169-184-224.fbx.proxad.net [88.169.184.224]) by mx.google.com with ESMTPS id o16sm8077667fag.21.2011.09.12.14.32.50 (version=SSLv3 cipher=OTHER); Mon, 12 Sep 2011 14:32:50 -0700 (PDT) Message-ID: <4E6E7A72.9030208@gmail.com> Date: Mon, 12 Sep 2011 23:32:34 +0200 From: maximilien mouton User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:6.0.2) Gecko/20110902 Thunderbird/6.0.2 MIME-Version: 1.0 To: "Gaurav Halwasia (ghalwasi)" References: <3CF88B99A9ED504197498BC6F6F04B81040FBDA9@XMB-BGL-41E.cisco.com> In-Reply-To: <3CF88B99A9ED504197498BC6F6F04B81040FBDA9@XMB-BGL-41E.cisco.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Cc: mif@ietf.org Subject: Re: [mif] Comments on draft-mouton-mif-dhcpv6-drlo-00 X-BeenThere: mif@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multiple Interface Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 12 Sep 2011 21:30:48 -0000 Hi Gaurav, Thank you for your review. See my answers inside. Le 12/09/2011 07:10, Gaurav Halwasia (ghalwasi) a 閏rit : > Hi, > > > > I read this draft, I think similar issue is also being discussed/solved > by draft-dec-dhcpv6-route-option-05 as well. > Can you say more about this discussion? > > > I see that you are proposing to have lifetime and MAC address in the > route option. Why do we want to communicate the lifetime of the route in > this option and that too I guess you are proposing to have a upper limit > of 150 minutes (9000 seconds) on that. What is the reason behind that. Actually we are following section 6.2.1 of rfc 4861 but this value can be discussed. > What should be done after the expiry of this 150 minutes..? > Information-Request..? or DHCP Renew.? I tend to Information-Request. > > I don't think that router lifetime will be that short I understand your comment. What do you propose? 7 days like proposed for a not default route? Do you think this field should be 2 or 4 bytes long? > and even if router > lifetime expires, DHCPv6 server can just send RECONFIGURE. I agree. > Normally > IPv6 addres lease time will not usually be that less. > > > > Further, What's the real need of having MAC/link address in the route > list option as there already exists means to get it. We assume that this option is useful because it gives the client the possibility to avoid waiting for na. Thanks, Maximilien > > Thanks, > > Gaurav > > > > > > _______________________________________________ > mif mailing list > mif@ietf.org > https://www.ietf.org/mailman/listinfo/mif From brian.e.carpenter@gmail.com Mon Sep 12 18:14: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 0BF5621F8CC6; Mon, 12 Sep 2011 18:14:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.585 X-Spam-Level: X-Spam-Status: No, score=-103.585 tagged_above=-999 required=5 tests=[AWL=0.014, 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 p-QCg+hhXwVv; Mon, 12 Sep 2011 18:14:06 -0700 (PDT) Received: from mail-fx0-f44.google.com (mail-fx0-f44.google.com [209.85.161.44]) by ietfa.amsl.com (Postfix) with ESMTP id 5868921F8CC3; Mon, 12 Sep 2011 18:14:05 -0700 (PDT) Received: by fxd18 with SMTP id 18so59585fxd.31 for ; Mon, 12 Sep 2011 18:16:09 -0700 (PDT) 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=JBJWUx33j6bAc8PWJfSYFoOZGjyxy2MyweX1ASc3MdI=; b=crZkV2xM4pc+tUOPtC/KqMWhgk/VXU81wZYQXStuLCkDWcca1QnEuaYzhjW5KFhgNc Ah5cGX4TtehVXqaaYxLT9oOwWap/YznYPUsCzikOvLEDOjpXXMpKpEF2mEIlkZhaz4pQ 1ThagzxCtoTHFRvZbuM8N+z5oLzAwJIS0Pn40= Received: by 10.223.29.76 with SMTP id p12mr625218fac.51.1315876569430; Mon, 12 Sep 2011 18:16:09 -0700 (PDT) Received: from [10.1.1.4] ([121.98.251.219]) by mx.google.com with ESMTPS id a1sm112446fab.4.2011.09.12.18.16.03 (version=SSLv3 cipher=OTHER); Mon, 12 Sep 2011 18:16:07 -0700 (PDT) Message-ID: <4E6EAECC.6080703@gmail.com> Date: Tue, 13 Sep 2011 13:15:56 +1200 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: <4E683F9B.7020905@gmail.com> <916CE6CF87173740BC8A2CE4430969620256F33F@008-AM1MPN1-032.mgdnok.nokia.com> <4E692D62.5080902@gmail.com> <916CE6CF87173740BC8A2CE443096962025704BA@008-AM1MPN1-032.mgdnok.nokia.com> <4E6A7E9F.5070706@gmail.com> <916CE6CF87173740BC8A2CE44309696202571A30@008-AM1MPN1-032.mgdnok.nokia.com> In-Reply-To: <916CE6CF87173740BC8A2CE44309696202571A30@008-AM1MPN1-032.mgdnok.nokia.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: mif@ietf.org, margaretw42@gmail.com, moore@network-heretics.com, denghui02@hotmail.com, iesg@ietf.org Subject: Re: [mif] Last Call for MIF DNS server selection document 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, 13 Sep 2011 01:14:07 -0000 Teemu, I think that is the best approach in order to get this document out without launching a war about the integrity of the DNS namespace. >> Private namespaces MUST only consist of subdomains of the domains communicated >> for nodes (e.g. subdomains of example.com) I'm wondering whether that doesn't have to be a bit more elaborated. Something like: 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. Thanks Brian On 2011-09-12 20:08, teemu.savolainen@nokia.com wrote: > Brian, > > I agree with that very reasonable suggestion. I think the problem described in > section 2.3 is one symptom of issues caused by non-uniqueness (and for which I > have not figured out automated solution). > > I mostly rewrote (for the -04 draft version) section 7 "Considerations for > network administrators" as follows. Would that address this concern? > -- > Network administrators deploying private namespaces should assist advanced > nodes in their DNS server selection process by providing information described > within this document. > > 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). An exception to this rule are domains utilized for > local name resolution (such as .local). > > Private namespaces MUST only consist of subdomains of the domains communicated > for nodes (e.g. subdomains of example.com). This means that a DNS server MUST > NOT resolve any domains that are not globally resolvable and are not > subdomains of said communicated domains. > > To mitigate against attacks against local namespaces, administrators utilizing > this tool SHOULD deploy DNSSEC for their zone. > -- > > The .local remains open issue though, I encountered this also in homenet > mailing list.. well it works fine as long as node is not connected to multiple > local networks at the same time... If node is, then I guess the application > must be able to select the right local network interface to use.. > > Best regards, > > Teemu > >> -----Original Message----- >> From: ext Brian E Carpenter [mailto:brian.e.carpenter@gmail.com] >> Sent: 10. syyskuuta 2011 00:01 >> To: Savolainen Teemu (Nokia-CTO/Tampere) >> Cc: moore@network-heretics.com; margaretw42@gmail.com; >> mif@ietf.org; denghui02@hotmail.com >> Subject: Re: [mif] Last Call for MIF DNS server selection document >> >> Teemu, >> >> I think the reference to multiple namespaces in the requirements draft is >> too >> short to really generate discussion, and in any case it's only an >> Informational >> document. >> >> However, I was trying to be quite careful in what I wrote. >> >>>> if the network administrator just does not want names to be >>>> resolvable on the public Internet. >> That is one thing, and an *ambiguous* namespace is another. >> >> I guess I would like to see some MUSTs or MUST NOTs in the MIF draft or >> elsewhere that make it clear that any domains that are not globally >> resolvable must nevertheless be globally unique. That needs to be expressed >> a bit more precisely and there might have to be an exception for .local. >> However, if a host can see a DNS server from example.com, a rule could >> be: that server MUST NOT resolve any domains that are not globally >> resolvable and are not subdomains of example.com. >> >> I am sure there is a better way to express this. It just needs to guarantee >> a >> strict hierarchy in the namespace. >> >> Regards >> Brian Carpenter >> >> On 2011-09-09 18:15, teemu.savolainen@nokia.com wrote: >>> Keith, Brian, >>> >>> The problem this draft is addressing has been acknowledged in the >>> draft-ietf-mif-problem-statement-15.txt section 4.1. The problem >>> statement is already at the RFC editor's queue. >>> >>> Based on the acceptance of the problem, this WG was chartered with a >>> goal >>> of: >>> -- >>> 1) DNS server selection solution: a specification for describing a way >>> for a network to communicate to nodes information required to perform >>> advanced DNS server selection at name resolution request granularity >>> in scenarios involving multiple namespaces. The specification shall >>> describe the information to be delivered for nodes and the protocol to >>> be used for delivery. >>> -- >>> >>> This draft is the solution that has been accepted as a WG work item. >>> >>> The topic has been discussed for a quite long time and I don't think >>> there are any such surprises you refer to (except perhaps for >>> individuals who just now start following the work). >>> >>> Furthermore, I cannot easily buy the argument (I hope I read your >>> points >>> right) that a solution should not be developed for an acknowledged >>> problem out of fear of "legitimizing" the problematic behavior. >>> >>> I do agree BCP or similar might be nice to have, but would such BCP >>> really make any difference e.g. if the network administrator just does >>> not want names to be resolvable on the public Internet. >>> >>> Best regards, >>> >>> Teemu >>> >>>> -----Original Message----- >>>> From: ext Keith Moore [mailto:moore@network-heretics.com] >>>> Sent: 09. syyskuuta 2011 01:22 >>>> To: Brian E Carpenter >>>> Cc: Savolainen Teemu (Nokia-CTO/Tampere); margaretw42@gmail.com; >>>> mif@ietf.org; denghui02@hotmail.com >>>> Subject: Re: [mif] Last Call for MIF DNS server selection document >>>> >>>> >>>> On Sep 8, 2011, at 5:02 PM, Brian E Carpenter wrote: >>>> >>>>> Teemu, >>>>> >>>>> On 2011-09-08 18:16, teemu.savolainen@nokia.com wrote: >>>>>> Brian, >>>>>> >>>>>> Thank you for review. I agree it is a good idea to consult those >>>>>> WGs (and DHC as well I suppose), but what makes you so concerned of >>>>>> this >>>> text: >>>>>>>> In deployments where multiple namespaces are present, selection >> of >>>>>>>> correct route and destination and source addresses for the >>>>>>>> actual >>> IP >>>>>>>> connection is crucial as well, as the resolved destination's IP >>>>>>>> addresses may be only usable on the network interface over >>>>>>>> which >>> the >>>>>>>> name was resolved on. >>>>>> I wrote that as I thought it would be useful to talk a little about >>>>>> bigger picture of some deployments (like in the demo we had few >>>>>> IETFs back - without presence of DHCPv6 more specific route options >>>>>> the system would not have worked properly) .. but if that text >>>>>> creates an unwanted link or dependency or confusion, I think we can >>>>>> drop the text just as well and focus on the document just to the >>>>>> new options and leave this kind of additional system-level >>>>>> consideration out of the >>>> doc. >>>>> As Andrew pointed out, the draft starts >>>>> >>>>> "...from the premise that operators sometimes include private >>>>> namespaces in the answers they provide from DNS servers, and that >>>>> those private namespaces are at least as useful to clients as the >>>>> answers from the public DNS." >>>>> >>>>> I believe that you will discover during IETF LC that many people >>>>> have strong feelings about this premise; as Andrew implied, >>>>> conceptually the DNS is a unified global namespace. This draft is a >>>>> backdoor way of legitimising an ambiguous namespace. I don't think >>>>> that will have an easy time in IETF LC, especially if it is dropped >>>>> as a surprise into the DNS community. It's your choice, but I would >>>>> suggest that exposing it to the DNS WGs now would be a smart move. >>>> Frankly, I consider this very nearly a showstopper, in the sense that >>>> MIF needs an extremely good reason to do this, and I haven't seen >>>> even a hint >>> of >>>> such a reason. You may recall that I raised this issue in Quebec, >>> though >>>> perhaps I was too polite about it. (Since I hadn't read the document >>>> yet, >>> and >>>> was coming late into the discussion, I wanted to give the group the >>> benefit >>>> of the doubt.) >>>> >>>> I'm quite surprised that MIF was able to get this far with the document >>>> without the issue being raised. I'm shocked that this issue appears to >>> be a >>>> surprise to the WG. I think that by itself is likely a sign of a >>>> serious >>> process or >>>> management failure. >>>> >>>> >>>>> It goes further. The IETF has a longstanding issue with technology >>>>> that encourages walled gardens. See for example RFC 3002. I think >>>>> there will be quite some discussion, and this will definitely happen >>>>> even if you try to remove the "system-level" considerations, because >>>>> they are strongly implied anyway. >>>>> >>>>> Personally I'm not sure what I think about this, but it needs to be >>>>> discussed in the community IMHO. >>>> +1. >>>> >>>> Keith From brian.e.carpenter@gmail.com Mon Sep 12 18:18:06 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 B483421F8D16 for ; Mon, 12 Sep 2011 18:18:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.585 X-Spam-Level: X-Spam-Status: No, score=-103.585 tagged_above=-999 required=5 tests=[AWL=0.014, 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 vUeQY8hpxtrm for ; Mon, 12 Sep 2011 18:18:06 -0700 (PDT) Received: from mail-fx0-f44.google.com (mail-fx0-f44.google.com [209.85.161.44]) by ietfa.amsl.com (Postfix) with ESMTP id ECCFB21F8D15 for ; Mon, 12 Sep 2011 18:18:05 -0700 (PDT) Received: by fxd18 with SMTP id 18so62084fxd.31 for ; Mon, 12 Sep 2011 18:20:10 -0700 (PDT) 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=vKoP2YvvWEVWmXPZAqMVjmTaeuwFi/+9jiCmsixEqK8=; b=VhLSpeL7ojAf9hhixPxxHdS4SM2AvCkRpP47sSB6wI3noJs6SLm+lJM98uYEoNiemY AxG0oZHvBPQQ+VWfVxZarW0bhG1UDIIi+Y2qe/vk/eW+bmNL+LUTPceBtBhdcgzm9F3C BZxRybvFOCEILAULVQmWKIGbEWX68vV8ypwCs= Received: by 10.223.18.73 with SMTP id v9mr1348729faa.70.1315876810163; Mon, 12 Sep 2011 18:20:10 -0700 (PDT) Received: from [10.1.1.4] ([121.98.251.219]) by mx.google.com with ESMTPS id w14sm109342fae.13.2011.09.12.18.20.06 (version=SSLv3 cipher=OTHER); Mon, 12 Sep 2011 18:20:09 -0700 (PDT) Message-ID: <4E6EAFC2.5060906@gmail.com> Date: Tue, 13 Sep 2011 13:20:02 +1200 From: Brian E Carpenter Organization: University of Auckland User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: maximilien mouton References: <3CF88B99A9ED504197498BC6F6F04B81040FBDA9@XMB-BGL-41E.cisco.com> <4E6E7A72.9030208@gmail.com> In-Reply-To: <4E6E7A72.9030208@gmail.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: mif@ietf.org Subject: Re: [mif] Comments on draft-mouton-mif-dhcpv6-drlo-00 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, 13 Sep 2011 01:18:06 -0000 On 2011-09-13 09:32, maximilien mouton wrote: > Hi Gaurav, >=20 > Thank you for your review. See my answers inside. >=20 > Le 12/09/2011 07:10, Gaurav Halwasia (ghalwasi) a =C3=A9crit : =2E.. >> and even if router >> lifetime expires, DHCPv6 server can just send RECONFIGURE. >=20 > I agree.=20 However, that has to be sent unicast to every DHCP client. That makes it problematic for a large network. Brian From brian.e.carpenter@gmail.com Mon Sep 12 18:22: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 29CB521F8AE9 for ; Mon, 12 Sep 2011 18:22:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.585 X-Spam-Level: X-Spam-Status: No, score=-103.585 tagged_above=-999 required=5 tests=[AWL=0.014, 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 VAuuachbDnrN for ; Mon, 12 Sep 2011 18:22:50 -0700 (PDT) Received: from mail-fx0-f44.google.com (mail-fx0-f44.google.com [209.85.161.44]) by ietfa.amsl.com (Postfix) with ESMTP id 6487D21F8AE6 for ; Mon, 12 Sep 2011 18:22:50 -0700 (PDT) Received: by fxd18 with SMTP id 18so65291fxd.31 for ; Mon, 12 Sep 2011 18:24:54 -0700 (PDT) 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=43LlAo+4uDZEx/ygure5d77x9yfgvartuwTO4T3QbKk=; b=Mhq5a8UEGGpYWm1jJp5XHeOmMzaz/ducOKxj5OjbAP7MNfpax7rZGEq1OXpk3WeYJ7 bD6NSWGVvAjDhXcBassWuUtusymFn36E/caRDdbYfS/1oZio7j4uKSCZhObAfq7/iFQg HFB19FFZD7pMQw/DXhy6akEMBDgq2tH3Xng1w= Received: by 10.223.34.143 with SMTP id l15mr631404fad.46.1315877094668; Mon, 12 Sep 2011 18:24:54 -0700 (PDT) Received: from [10.1.1.4] ([121.98.251.219]) by mx.google.com with ESMTPS id o22sm118909fab.11.2011.09.12.18.24.51 (version=SSLv3 cipher=OTHER); Mon, 12 Sep 2011 18:24:53 -0700 (PDT) Message-ID: <4E6EB0DC.5040102@gmail.com> Date: Tue, 13 Sep 2011 13:24:44 +1200 From: Brian E Carpenter Organization: University of Auckland User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: Simon Perreault References: <20110910220345.29077.66749.idtracker@ietfa.amsl.com> <4E6BE7BF.5030501@gmail.com> <4E6C8F4A.308@gmail.com> <4E6E053B.7000305@viagenie.ca> <4E6E097F.8010205@gmail.com> <4E6E0C4A.7030105@viagenie.ca> <4E6E10E0.6010607@gmail.com> <4E6E13E0.2030402@viagenie.ca> In-Reply-To: <4E6E13E0.2030402@viagenie.ca> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: mif@ietf.org Subject: Re: [mif] I-D draft-ietf-mif-dhcpv6-route-option-03 published X-BeenThere: mif@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multiple Interface Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 13 Sep 2011 01:22:51 -0000 On 2011-09-13 02:14, Simon Perreault wrote: > On 2011-09-12 10:02, Alexandru Petrescu wrote: >>> I don't see the use case. Can't the DHCP client on the very small >>> platform just install the default route first, then whatever other >>> routes it can support, and ignore the rest? >> Do you think there exist a DHCP way to say: "install the default route >> first and, if you have enough memory, install these specific routes"? > > Maybe it can be written in the draft. For example: > > Hosts MUST install routes in the order they are listed. If any routes > cannot be installed due to resource constraints, routes MAY be dropped > starting from the end. > > With this, the operator can put the default route first and obtain the > behaviour you're describing. That won't work if the host also gets a default route from RA. There's nothing to stop DHCPv6 and RA being used simultaneously, for different prefixes, and providing different default routers. Brian From maximilien.mouton@gmail.com Mon Sep 12 21:38: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 B3B2121F8A35 for ; Mon, 12 Sep 2011 21:38:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IH5m2Yi9HY0B for ; Mon, 12 Sep 2011 21:38:22 -0700 (PDT) Received: from mail-fx0-f44.google.com (mail-fx0-f44.google.com [209.85.161.44]) by ietfa.amsl.com (Postfix) with ESMTP id D51C021F8C28 for ; Mon, 12 Sep 2011 21:38:21 -0700 (PDT) Received: by fxd18 with SMTP id 18so191576fxd.31 for ; Mon, 12 Sep 2011 21:40:26 -0700 (PDT) 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:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; bh=rd8O7aSojtzj9+NNsuAP/p30cAJ7rqzEXTmInh0r3cs=; b=wcQYq98h8/wxnd1rFap3T3O1zG68JG1CGlYmi4Lw2dCZjeAEn9nv+2CTbcH019a0nF ubeJHjK7BcI7mf6zJiEZVMV/AReXcf55kaLlovXv5RJzAUEOaffcdf5pwwxfhQnUo+zt qWLOPZtEGSEWW88Fzn6kQQx43+IQ0+ZrfOQGQ= Received: by 10.223.7.7 with SMTP id b7mr651948fab.9.1315888826209; Mon, 12 Sep 2011 21:40:26 -0700 (PDT) Received: from [127.0.0.1] (scy57-1-88-169-184-224.fbx.proxad.net [88.169.184.224]) by mx.google.com with ESMTPS id u6sm466108faf.3.2011.09.12.21.40.25 (version=SSLv3 cipher=OTHER); Mon, 12 Sep 2011 21:40:25 -0700 (PDT) Message-ID: <4E6EDEA8.3080108@gmail.com> Date: Tue, 13 Sep 2011 06:40:08 +0200 From: maximilien mouton User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:6.0.2) Gecko/20110902 Thunderbird/6.0.2 MIME-Version: 1.0 To: Brian E Carpenter References: <3CF88B99A9ED504197498BC6F6F04B81040FBDA9@XMB-BGL-41E.cisco.com> <4E6E7A72.9030208@gmail.com> <4E6EAFC2.5060906@gmail.com> In-Reply-To: <4E6EAFC2.5060906@gmail.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Cc: mif@ietf.org Subject: Re: [mif] Comments on draft-mouton-mif-dhcpv6-drlo-00 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, 13 Sep 2011 04:38:22 -0000 Hi Brian, My answer below. Le 13/09/2011 03:20, Brian E Carpenter a 茅crit : > On 2011-09-13 09:32, maximilien mouton wrote: >> Hi Gaurav, >> >> Thank you for your review. See my answers inside. >> >> Le 12/09/2011 07:10, Gaurav Halwasia (ghalwasi) a 茅crit : > > ... >>> and even if router >>> lifetime expires, DHCPv6 server can just send RECONFIGURE. >> >> I agree. > > However, that has to be sent unicast to every DHCP client. > That makes it problematic for a large network. In this case an Information-Request when client's lifetime expires (or is close to) is sufficient especially if lifetime's upper limit is higher. Thanks Maximilien > > Brian > From ghalwasi@cisco.com Mon Sep 12 22:46: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 97F3221F8B12 for ; Mon, 12 Sep 2011 22:46:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.791 X-Spam-Level: X-Spam-Status: No, score=-9.791 tagged_above=-999 required=5 tests=[AWL=0.808, 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 J5p8YaHd7WKX for ; Mon, 12 Sep 2011 22:46:13 -0700 (PDT) Received: from ams-iport-2.cisco.com (ams-iport-2.cisco.com [144.254.224.141]) by ietfa.amsl.com (Postfix) with ESMTP id 6F57A21F8B11 for ; Mon, 12 Sep 2011 22:46:13 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=ghalwasi@cisco.com; l=3417; q=dns/txt; s=iport; t=1315892899; x=1317102499; h=mime-version:content-transfer-encoding:subject:date: message-id:in-reply-to:references:from:to:cc; bh=nj//NNQ/zXwkzBAVduz3rjCEm9tWzpz9arZKYm+ljsE=; b=D5nFGEqB/eVRV4kqhklNiakm5tLKBL4uGyY9GrZLqCXTgROZzcRk545x ailrwsr/wLZUzMLUOxmJDtO7XL8qUWg7jPvgnuQf/vlylC6cKO2LjPBUB Xu+4TsVGvT7daUSxYL5eDPEnnxXz7w+BiyLmjf9WmSpEiBguIw92LORMu M=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AsoAAJDtbk5Io8US/2dsb2JhbABCmGOPEHiBUgEBAQECAQEBAQ8BHT4LBQcEAgEIEQQBAQsGFwEGASAGHwkIAQEECwgIGodVBJd8AZ5Jhg5gBIc+LZBxhGiHHg X-IronPort-AV: E=Sophos;i="4.68,372,1312156800"; d="scan'208";a="54299013" Received: from bgl-core-3.cisco.com ([72.163.197.18]) by ams-iport-2.cisco.com with ESMTP; 13 Sep 2011 05:48:16 +0000 Received: from xbh-bgl-412.cisco.com (xbh-bgl-412.cisco.com [72.163.129.202]) by bgl-core-3.cisco.com (8.14.3/8.14.3) with ESMTP id p8D5mEGw005554; Tue, 13 Sep 2011 05:48:16 GMT Received: from xmb-bgl-41e.cisco.com ([72.163.129.220]) by xbh-bgl-412.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Tue, 13 Sep 2011 11:18:16 +0530 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: Tue, 13 Sep 2011 11:18:14 +0530 Message-ID: <3CF88B99A9ED504197498BC6F6F04B81040FC010@XMB-BGL-41E.cisco.com> In-Reply-To: <4E6E7A72.9030208@gmail.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [mif] Comments on draft-mouton-mif-dhcpv6-drlo-00 Thread-Index: Acxxk5M+uurvpeTvTlSqs6hlC7s9TQAM8ULA References: <3CF88B99A9ED504197498BC6F6F04B81040FBDA9@XMB-BGL-41E.cisco.com> <4E6E7A72.9030208@gmail.com> From: "Gaurav Halwasia (ghalwasi)" To: "maximilien mouton" X-OriginalArrivalTime: 13 Sep 2011 05:48:16.0088 (UTC) FILETIME=[BB94FD80:01CC71D8] Cc: mif@ietf.org Subject: Re: [mif] Comments on draft-mouton-mif-dhcpv6-drlo-00 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, 13 Sep 2011 05:46:14 -0000 Hi Maximilien, >> I read this draft, I think similar issue is also being = discussed/solved >> by draft-dec-dhcpv6-route-option-05 as well. >> >Can you say more about this discussion? Draft [draft-dec-dhcpv6-route-option-05] handles the cases of both = default/other static route using one generic option. That's it I was = able to gather in my one glance to this draft. On Route lifetime and the length of it's field. I strongly think that this field is unnecessary as I don't think default = route (given by DHCPv6 server) will be that shortlived. Even if it is = short lived, anyways a new message exchange needs to happen irrespective = of this field. (either server initiated or client initiated.) In ND, as the messages are quite periodic (in comparison to DHCPv6), = having a lifetime in ND message makes sense. One of the primary use of = having lifetime in ND is to advertise route as stale (by setting = lifetime as zero). The main purpose of having RECONFIGURE (sent by Server) message is to = actually achieve the same thing. At the first place, I feel that default = routes are not going to be that short lived and even if it is (in some = scenarios), server can always use RECONFIGURE. On MAC address issue. Again, think that it's not a good idea to send MAC address of default = router in DHCPv6 option. I will probably eat a lot of bandwidth in = comparison to the benefit it can provide. Thanks, Gaurav -----Original Message----- From: maximilien mouton [mailto:maximilien.mouton@gmail.com]=20 Sent: Tuesday, September 13, 2011 3:03 AM To: Gaurav Halwasia (ghalwasi) Cc: mif@ietf.org Subject: Re: [mif] Comments on draft-mouton-mif-dhcpv6-drlo-00 Hi Gaurav, Thank you for your review. See my answers inside. Le 12/09/2011 07:10, Gaurav Halwasia (ghalwasi) a =E9crit : > Hi, > > > > I read this draft, I think similar issue is also being = discussed/solved > by draft-dec-dhcpv6-route-option-05 as well. > Can you say more about this discussion? > > > I see that you are proposing to have lifetime and MAC address in the > route option. Why do we want to communicate the lifetime of the route = in > this option and that too I guess you are proposing to have a upper = limit > of 150 minutes (9000 seconds) on that. What is the reason behind that. Actually we are following section 6.2.1 of rfc 4861 but this value can be discussed. > What should be done after the expiry of this 150 minutes..? > Information-Request..? or DHCP Renew.? I tend to Information-Request. > > I don't think that router lifetime will be that short I understand your comment. What do you propose? 7 days like proposed for = a not default route? Do you think this field should be 2 or 4 bytes long? > and even if router > lifetime expires, DHCPv6 server can just send RECONFIGURE. I agree. > Normally > IPv6 addres lease time will not usually be that less. > > > > Further, What's the real need of having MAC/link address in the route > list option as there already exists means to get it. We assume that this option is useful because it gives the client the=20 possibility to avoid waiting for na. Thanks, Maximilien > > Thanks, > > Gaurav > > > > > > _______________________________________________ > mif mailing list > mif@ietf.org > https://www.ietf.org/mailman/listinfo/mif From teemu.savolainen@nokia.com Tue Sep 13 01: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 993A121F8B51; Tue, 13 Sep 2011 01:47:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.689 X-Spam-Level: X-Spam-Status: No, score=-2.689 tagged_above=-999 required=5 tests=[AWL=-0.089, 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 2PTiH50hzBxM; Tue, 13 Sep 2011 01:47:23 -0700 (PDT) Received: from mgw-da02.nokia.com (smtp.nokia.com [147.243.128.26]) by ietfa.amsl.com (Postfix) with ESMTP id 4017D21F8997; Tue, 13 Sep 2011 01:47:22 -0700 (PDT) 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.3) with ESMTP id p8D8nNSg008091; Tue, 13 Sep 2011 11:49:23 +0300 Received: from smtp.mgd.nokia.com ([65.54.30.8]) by vaebh102.NOE.Nokia.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.4675); Tue, 13 Sep 2011 11:49:22 +0300 Received: from 008-AM1MMR1-003.mgdnok.nokia.com (65.54.30.58) by NOK-AM1MHUB-04.mgdnok.nokia.com (65.54.30.8) with Microsoft SMTP Server (TLS) id 8.2.255.0; Tue, 13 Sep 2011 10:49:22 +0200 Received: from 008-AM1MPN1-032.mgdnok.nokia.com ([169.254.2.143]) by 008-AM1MMR1-003.mgdnok.nokia.com ([65.54.30.58]) with mapi id 14.01.0323.007; Tue, 13 Sep 2011 10:49:21 +0200 From: To: Thread-Topic: [mif] Last Call for MIF DNS server selection document Thread-Index: AQHMbdzsBHSQ8Tn9hkac95+LwFpGipVC/6HggADYVwCAABZPgIAAoquAgADZC4CAA/dpoIABBrkAgACdsBA= Date: Tue, 13 Sep 2011 08:49:21 +0000 Message-ID: <916CE6CF87173740BC8A2CE44309696202572997@008-AM1MPN1-032.mgdnok.nokia.com> References: <4E683F9B.7020905@gmail.com> <916CE6CF87173740BC8A2CE4430969620256F33F@008-AM1MPN1-032.mgdnok.nokia.com> <4E692D62.5080902@gmail.com> <916CE6CF87173740BC8A2CE443096962025704BA@008-AM1MPN1-032.mgdnok.nokia.com> <4E6A7E9F.5070706@gmail.com> <916CE6CF87173740BC8A2CE44309696202571A30@008-AM1MPN1-032.mgdnok.nokia.com> <4E6EAECC.6080703@gmail.com> In-Reply-To: <4E6EAECC.6080703@gmail.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes 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+/nZJb9Kg7IijnarCFufw93yGp9Kqg4VsreROV3oSoCKo4MAZQAlH7cl7QEYi2t0p8hTrsrklpyqBfRuV1a3TP5t4zLsal1WzFsT0mQwFWR/yRh3UhJztIIhyLXE7aj3YtN85Eqji4hyMU9zDnsRybCxak6t2mfbgLZX2mjzSIIHnDkgCjyHZFFOhfBqPd/c5FcvKdb64f0sgP1bp0Rng5aZTrafF1qFNxmzB3fX0dr0qbeG9YfeKCcsiZk5WqSUtPkVYQ2fFAPg== x-originating-ip: [10.162.25.130] Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=SHA1; boundary="----=_NextPart_000_00C6_01CC720B.2CA99620" MIME-Version: 1.0 X-OriginalArrivalTime: 13 Sep 2011 08:49:22.0102 (UTC) FILETIME=[083B2560:01CC71F2] X-Nokia-AV: Clean Cc: mif@ietf.org, margaretw42@gmail.com, moore@network-heretics.com, denghui02@hotmail.com, iesg@ietf.org Subject: Re: [mif] Last Call for MIF DNS server selection document 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, 13 Sep 2011 08:47:24 -0000 ------=_NextPart_000_00C6_01CC720B.2CA99620 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit Brian, Sounds good for me - included now for the next update. Thank you, Teemu > -----Original Message----- > From: ext Brian E Carpenter [mailto:brian.e.carpenter@gmail.com] > Sent: 13. syyskuuta 2011 04:16 > To: Savolainen Teemu (Nokia-CTO/Tampere) > Cc: moore@network-heretics.com; margaretw42@gmail.com; > mif@ietf.org; denghui02@hotmail.com; iesg@ietf.org > Subject: Re: [mif] Last Call for MIF DNS server selection document > > Teemu, > > I think that is the best approach in order to get this document out without > launching a war about the integrity of the DNS namespace. > > >> Private namespaces MUST only consist of subdomains of the domains > >> communicated for nodes (e.g. subdomains of example.com) > > I'm wondering whether that doesn't have to be a bit more elaborated. > Something like: > > 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. > > Thanks > > Brian > > On 2011-09-12 20:08, teemu.savolainen@nokia.com wrote: > > Brian, > > > > I agree with that very reasonable suggestion. I think the problem > > described in section 2.3 is one symptom of issues caused by > > non-uniqueness (and for which I have not figured out automated solution). > > > > I mostly rewrote (for the -04 draft version) section 7 "Considerations > > for network administrators" as follows. Would that address this concern? > > -- > > Network administrators deploying private namespaces should assist > > advanced nodes in their DNS server selection process by providing > > information described within this document. > > > > 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). An exception to this > > rule are domains utilized for local name resolution (such as .local). > > > > Private namespaces MUST only consist of subdomains of the domains > > communicated for nodes (e.g. subdomains of example.com). This means > > that a DNS server MUST NOT resolve any domains that are not globally > > resolvable and are not subdomains of said communicated domains. > > > > To mitigate against attacks against local namespaces, administrators > > utilizing this tool SHOULD deploy DNSSEC for their zone. > > -- > > > > The .local remains open issue though, I encountered this also in > > homenet mailing list.. well it works fine as long as node is not > > connected to multiple local networks at the same time... If node is, > > then I guess the application must be able to select the right local > > network > interface to use.. > > > > Best regards, > > > > Teemu > > > >> -----Original Message----- > >> From: ext Brian E Carpenter [mailto:brian.e.carpenter@gmail.com] > >> Sent: 10. syyskuuta 2011 00:01 > >> To: Savolainen Teemu (Nokia-CTO/Tampere) > >> Cc: moore@network-heretics.com; margaretw42@gmail.com; > mif@ietf.org; > >> denghui02@hotmail.com > >> Subject: Re: [mif] Last Call for MIF DNS server selection document > >> > >> Teemu, > >> > >> I think the reference to multiple namespaces in the requirements > >> draft is too short to really generate discussion, and in any case > >> it's only an Informational document. > >> > >> However, I was trying to be quite careful in what I wrote. > >> > >>>> if the network administrator just does not want names to be > >>>> resolvable on the public Internet. > >> That is one thing, and an *ambiguous* namespace is another. > >> > >> I guess I would like to see some MUSTs or MUST NOTs in the MIF draft > >> or elsewhere that make it clear that any domains that are not > >> globally resolvable must nevertheless be globally unique. That needs > >> to be expressed a bit more precisely and there might have to be an > exception for .local. > >> However, if a host can see a DNS server from example.com, a rule > >> could > >> be: that server MUST NOT resolve any domains that are not globally > >> resolvable and are not subdomains of example.com. > >> > >> I am sure there is a better way to express this. It just needs to > >> guarantee a strict hierarchy in the namespace. > >> > >> Regards > >> Brian Carpenter > >> > >> On 2011-09-09 18:15, teemu.savolainen@nokia.com wrote: > >>> Keith, Brian, > >>> > >>> The problem this draft is addressing has been acknowledged in the > >>> draft-ietf-mif-problem-statement-15.txt section 4.1. The problem > >>> statement is already at the RFC editor's queue. > >>> > >>> Based on the acceptance of the problem, this WG was chartered with a > >>> goal > >>> of: > >>> -- > >>> 1) DNS server selection solution: a specification for describing a way > >>> for a network to communicate to nodes information required to > perform > >>> advanced DNS server selection at name resolution request granularity > >>> in scenarios involving multiple namespaces. The specification shall > >>> describe the information to be delivered for nodes and the protocol to > >>> be used for delivery. > >>> -- > >>> > >>> This draft is the solution that has been accepted as a WG work item. > >>> > >>> The topic has been discussed for a quite long time and I don't think > >>> there are any such surprises you refer to (except perhaps for > >>> individuals who just now start following the work). > >>> > >>> Furthermore, I cannot easily buy the argument (I hope I read your > >>> points > >>> right) that a solution should not be developed for an acknowledged > >>> problem out of fear of "legitimizing" the problematic behavior. > >>> > >>> I do agree BCP or similar might be nice to have, but would such BCP > >>> really make any difference e.g. if the network administrator just > >>> does not want names to be resolvable on the public Internet. > >>> > >>> Best regards, > >>> > >>> Teemu > >>> > >>>> -----Original Message----- > >>>> From: ext Keith Moore [mailto:moore@network-heretics.com] > >>>> Sent: 09. syyskuuta 2011 01:22 > >>>> To: Brian E Carpenter > >>>> Cc: Savolainen Teemu (Nokia-CTO/Tampere); > margaretw42@gmail.com; > >>>> mif@ietf.org; denghui02@hotmail.com > >>>> Subject: Re: [mif] Last Call for MIF DNS server selection document > >>>> > >>>> > >>>> On Sep 8, 2011, at 5:02 PM, Brian E Carpenter wrote: > >>>> > >>>>> Teemu, > >>>>> > >>>>> On 2011-09-08 18:16, teemu.savolainen@nokia.com wrote: > >>>>>> Brian, > >>>>>> > >>>>>> Thank you for review. I agree it is a good idea to consult those > >>>>>> WGs (and DHC as well I suppose), but what makes you so concerned > >>>>>> of this > >>>> text: > >>>>>>>> In deployments where multiple namespaces are present, > >>>>>>>> selection > >> of > >>>>>>>> correct route and destination and source addresses for the > >>>>>>>> actual > >>> IP > >>>>>>>> connection is crucial as well, as the resolved destination's IP > >>>>>>>> addresses may be only usable on the network interface over > >>>>>>>> which > >>> the > >>>>>>>> name was resolved on. > >>>>>> I wrote that as I thought it would be useful to talk a little > >>>>>> about bigger picture of some deployments (like in the demo we had > >>>>>> few IETFs back - without presence of DHCPv6 more specific route > >>>>>> options the system would not have worked properly) .. but if that > >>>>>> text creates an unwanted link or dependency or confusion, I think > >>>>>> we can drop the text just as well and focus on the document just > >>>>>> to the new options and leave this kind of additional system-level > >>>>>> consideration out of the > >>>> doc. > >>>>> As Andrew pointed out, the draft starts > >>>>> > >>>>> "...from the premise that operators sometimes include private > >>>>> namespaces in the answers they provide from DNS servers, and that > >>>>> those private namespaces are at least as useful to clients as the > >>>>> answers from the public DNS." > >>>>> > >>>>> I believe that you will discover during IETF LC that many people > >>>>> have strong feelings about this premise; as Andrew implied, > >>>>> conceptually the DNS is a unified global namespace. This draft is > >>>>> a backdoor way of legitimising an ambiguous namespace. I don't > >>>>> think that will have an easy time in IETF LC, especially if it is > >>>>> dropped as a surprise into the DNS community. It's your choice, > >>>>> but I would suggest that exposing it to the DNS WGs now would be a > smart move. > >>>> Frankly, I consider this very nearly a showstopper, in the sense > >>>> that MIF needs an extremely good reason to do this, and I haven't > >>>> seen even a hint > >>> of > >>>> such a reason. You may recall that I raised this issue in Quebec, > >>> though > >>>> perhaps I was too polite about it. (Since I hadn't read the > >>>> document yet, > >>> and > >>>> was coming late into the discussion, I wanted to give the group the > >>> benefit > >>>> of the doubt.) > >>>> > >>>> I'm quite surprised that MIF was able to get this far with the document > >>>> without the issue being raised. I'm shocked that this issue appears > >>>> to > >>> be a > >>>> surprise to the WG. I think that by itself is likely a sign of a > >>>> serious > >>> process or > >>>> management failure. > >>>> > >>>> > >>>>> It goes further. The IETF has a longstanding issue with technology > >>>>> that encourages walled gardens. See for example RFC 3002. I think > >>>>> there will be quite some discussion, and this will definitely > >>>>> happen even if you try to remove the "system-level" > >>>>> considerations, because they are strongly implied anyway. > >>>>> > >>>>> Personally I'm not sure what I think about this, but it needs to > >>>>> be discussed in the community IMHO. > >>>> +1. > >>>> > >>>> Keith ------=_NextPart_000_00C6_01CC720B.2CA99620 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIOuzCCAzYw ggIeoAMCAQICBDpVqdkwDQYJKoZIhvcNAQEFBQAwKTEOMAwGA1UEChMFTm9raWExFzAVBgNVBAMT Dk5va2lhICBSb290IENBMB4XDTAxMDEwNTExMDUwNVoXDTE2MDEwMjExMDUwNVowKTEOMAwGA1UE ChMFTm9raWExFzAVBgNVBAMTDk5va2lhICBSb290IENBMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8A MIIBCgKCAQEAsrTy8gLmr4LYvp0khVUVHw7ascdl+Cjr+yI5MlZ6J/U6Qsvkiqthgqq8rPcLV0P1 92TfBr27VgKEeCaZe0icS1jC2spM/wRv3j2WxdkKxb9kDJtuCNJaRBqvi5vGTHB15nmEmKuL5f3i rAxeHqPjgS496oWcudzFT1e7Xrc/gWGFYd72+/ykIFXjWOMZv6QpxD8x1hLPyh2YVXRk9U7N7pvm RQNX29g4SCFJY2BBIa5JPlwIF8Nc9IePaC/E/2M4tGMtiOOZlm99EoL7N0hJZtFSvUwdCBud/viH 4DgsKGjNkNKi6pAHc9IaXB6tIykcoYp+L+oe/3+cuEJaCj1EKwIDAQABo2YwZDASBgNVHRMBAf8E CDAGAQH/AgEEMB0GA1UdDgQWBBSNjfefoQ0AITLvqe0iruA79NB9sDAfBgNVHSMEGDAWgBSNjfef oQ0AITLvqe0iruA79NB9sDAOBgNVHQ8BAf8EBAMCAYYwDQYJKoZIhvcNAQEFBQADggEBAIGEPql2 TALyKi/h1J+Mh5XolAtYppcSOLMtBkoA7ZovGBDNvl0VbZs8AAojJqkUoWBB+L6DKyl/jKhNfKcu rWRGRyj7pnbxrKLsI3gmWNWkyo2b60wJwe9fqPD5ZQy3oEiMit9l0Ba6il/k2GqYopUCNMa7mfeb E2LeBy5ChYMiCi97UQSJvAdzEYylTJw8Awc6AiM2Ve5N+XxsmKgNf/2A/5IJ3EZZ+wFRmkI4062A oNU302rqAt0HH88jzoUF4AfYHWl6HpYhGXFbcX44rHINyPmFBRxLYIFJ6ZWUr/mXpL/e6rqFtNWO kV6UoJND7OVZkbLh7F1+lcqXRU8TPBMwggOHMIICb6ADAgECAgRBtbHpMA0GCSqGSIb3DQEBBQUA MCkxDjAMBgNVBAoTBU5va2lhMRcwFQYDVQQDEw5Ob2tpYSAgUm9vdCBDQTAeFw0wNjAzMzAwOTU3 MTFaFw0xNjAxMDIxMTA1MDVaMDMxCzAJBgNVBAYTAkZJMQ4wDAYDVQQKEwVOb2tpYTEUMBIGA1UE AxMLTm9raWEgQkkgQ0EwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQDtFCg3QEjSCg6T IUxoWsNwELh8bBNiUQPCPmg8c2DHQYXWWCSCMb+S0Fvh1qqI1xt+XnzyFq+5eqzGzDj4UaBcG+d9 qxrCFly8sHyoPTryyPrR0EI2UUDWwfS6ojhqgwghRqo8G38TjFusyBtLub/5L6yvWYSOHD+JcB+q VM2fbkArPYK4Ydv8WG/DbHjGn0gKq0zwpVZKI/gCK/QALYvte02NXseqvY9/GOyLtjy3Z8erFv71 KKTq+gxI/7DK55pJf3PoD+kT4kyGm6EF9DTdK4ojMdar17uyX0IOZz/4vkkF0d+60nmnLX63FJPA jUyB0HUNJ32NXDo9UsM38aoNAgMBAAGjgawwgakwDwYDVR0TAQH/BAUwAwEB/zARBgNVHSAECjAI MAYGBFUdIAAwDgYDVR0PAQH/BAQDAgGGMFQGA1UdIwRNMEuAFI2N95+hDQAhMu+p7SKu4Dv00H2w oS2kKzApMQ4wDAYDVQQKEwVOb2tpYTEXMBUGA1UEAxMOTm9raWEgIFJvb3QgQ0GCBDpVqdkwHQYD VR0OBBYEFKcksD7Fg+8EDlB2Sxgy58pW0Sy6MA0GCSqGSIb3DQEBBQUAA4IBAQAC3lEUplDlVNOT Pjz/XFezXx2bV2XbCFindhA3F815Egi55H6/cYezEjoP4QLNEGGl2I3aLvkn5A0T8I4pbiFPhIiu B/frbbGg6k6GjQLe/bFQ8F1mAOOR+GyneKZFPfzaRV0jiIR9QqnMXTf8RvKkCJyFj10MZVsLIy/Y uBkzeP3JhzDhUdtPfwmJN6ZbIhH5uR/2BwAGtgQknb8WX3I4wnhWtMUxB8XmayayYs8qWYeIiVkI FV+sLTkWUWVvvKUjyakBpbAW2vUP84DYsJ8TL1YefNjf/nIOByMcORLuV/1gPjyv00qJbcB59AA+ iXe3zIo8QNcgXG0uPQQFmrGDMIID5DCCAsygAwIBAgIQMH5apak8lEy6LmLlLsJy8TANBgkqhkiG 9w0BAQUFADAzMQswCQYDVQQGEwJGSTEOMAwGA1UEChMFTm9raWExFDASBgNVBAMTC05va2lhIEJJ IENBMB4XDTExMDkwNjA1NTIwNFoXDTE0MDkwNjA1NTIwNFowVjEOMAwGA1UECgwFTm9raWExDzAN BgNVBAsMBlBlb3BsZTEYMBYGCgmSJomT8ixkAQEMCDEwMDI0Njc2MRkwFwYDVQQDDBBTYXZvbGFp bmVuIFRlZW11MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAshEsmw6Yiz6XWX26oF+I s5fsfE1OfCjOelclmtqCiIgXND5klkNOBs2d4ZGzgD9mN+XnTZnOTh249c2WxPBugf12DCcDmBAJ gL+VuWUJVBTE5NRchm/O8nZnZsRFst+gAC9/Juykh4+EYewZ7QbpnlwW7hNpj8eH+rMr+OZHKzdp KTftgVjmuF4JJ/cPMQUjL8SuGj+zBW6IWPOZdqkEMtf7Pr8kkYbZsh0SgJ0ceRHZ7Uc06mB/y+C1 UnJPxehTTdu8tpCjdzXgBw/H2uuW1J3qdHbCfbuDILql8V8RiZKubcZLhdsD3Jvj8qK0DGWBJa6x p90q5p3pLE8LvAeCgQIDAQABo4HQMIHNMA4GA1UdDwEB/wQEAwIEMDAfBgNVHSMEGDAWgBSnJLA+ xYPvBA5QdksYMufKVtEsujAZBgNVHSAEEjAQMA4GDCsGAQQBXgExBgEHAzA5BgNVHR8EMjAwMC6g LKAqhihodHRwOi8vY3JsLm5va2lhLmNvbS9Ob2tpYSUyMEJJJTIwQ0EuY3JsMCUGA1UdEQQeMByB GnRlZW11LnNhdm9sYWluZW5Abm9raWEuY29tMB0GA1UdDgQWBBQTRzvZsgmQrAGCeuzdHTGAC6Jg UzANBgkqhkiG9w0BAQUFAAOCAQEACmPVsdi07pjK5gDa+W5JlE2C74kVVsB8alBqfioYeR5At2FG B7sua4Dz5H7TJMpZ1jYFeI+zjexD5f+beY2IlV15lMoWD+5e38QlLYjwfe2LAyvdzBKXW0e0U6Bt p78ft4gyVak1X+Db+ebR+FNHUOMNhm+yK3w9sy5ZQzBFusIx4OgxGvcZhyhmd9WjipSTalgPwgqV Ju2aPADCG++OEXmgEWRLsR4yNopkgK4ftVqrN5uUtLs83qdeXTRcNRiET1IOx5zmYFZ6q3gjKIx5 iyuxcDeYas93vVHUcaRRYpsoby5CHq7Z/j/TQhtqO/knWuxLFFiCUgdGKMKrRkg29DCCBAowggLy oAMCAQICEQCBvi+p+bA/dBtBtybwA6YYMA0GCSqGSIb3DQEBBQUAMDMxCzAJBgNVBAYTAkZJMQ4w DAYDVQQKEwVOb2tpYTEUMBIGA1UEAxMLTm9raWEgQkkgQ0EwHhcNMTEwOTA2MDU1MDM0WhcNMTMw OTA1MDU1MDM0WjBWMQ4wDAYDVQQKDAVOb2tpYTEPMA0GA1UECwwGUGVvcGxlMRgwFgYKCZImiZPy LGQBAQwIMTAwMjQ2NzYxGTAXBgNVBAMMEFNhdm9sYWluZW4gVGVlbXUwggEiMA0GCSqGSIb3DQEB AQUAA4IBDwAwggEKAoIBAQDFPmbRVwuo52v+h6xnQUqokAx2xsHjmPBniEkzgtgBNJsFi838ATEg 1zsx+VotoJg7hMijcrQfpTAgW6gpLGnlmw5QQswrNK1zleOHb4pA5JguU3WhVKFkAH/6/2EU2k/9 m8Pb/gwP55cYg80R6fRmbdsWKhseXF/1isW/rJcWLmIYDg/rXfo3ixqtT9MroAMiuoXnb0ij1L2d Jj64LDp3Ld8Jo0qZzk3Fj4apo8PBd8eAH6HloVBJkxQcwAnv561A+Xi1GHZ2mafRYJGO+1uBDwyd g/8ybEXXA4MKo8lPKjBebYBUFvz80DBA/Lq74UysXkG23BSulcG4xQSYGlyzAgMBAAGjgfUwgfIw HwYDVR0jBBgwFoAUpySwPsWD7wQOUHZLGDLnylbRLLowGQYDVR0gBBIwEDAOBgwrBgEEAV4BMQYB BgQwOQYDVR0fBDIwMDAuoCygKoYoaHR0cDovL2NybC5ub2tpYS5jb20vTm9raWElMjBCSSUyMENB LmNybDAjBgNVHSUEHDAaBggrBgEFBQcDAgYEVR0lAAYIKwYBBQUHAwQwDgYDVR0PAQH/BAQDAgeA MCUGA1UdEQQeMByBGnRlZW11LnNhdm9sYWluZW5Abm9raWEuY29tMB0GA1UdDgQWBBTGhbTJF0EX iagjymQo6GIuSQeRVDANBgkqhkiG9w0BAQUFAAOCAQEAqai6TxZ/BlMHZIhJNPriBPXkQhUlBkGA buJZ5sVm1HIQhWN8elZKjjJdHi1qWEKhMg7yHjEMZsyV8XAZzK0UnOqkpUnt+jnVkNZ9O7/jRtyK f4WUtq5jErc8Hlv4bbGFRHk1T7AuLLE52r1lYOdmoibnQp03QtlDvHUNa68G7jvzThJhieB7U1xh vH3yy0ktaVnWEgAylqf9yIUFjnqau5R6cE1Xo57IYPk/KitX0YF+OigEI/bOQVMi+fze93ZsAOJv /z6g/NGemvUgl5YSdX0uPQK6kEHf/sp/nZyUWWQ7OjtVSqkq2YuYEueQFxTfafl+78GWqgm6W/Bl 32laYzGCAuswggLnAgEBMEgwMzELMAkGA1UEBhMCRkkxDjAMBgNVBAoTBU5va2lhMRQwEgYDVQQD EwtOb2tpYSBCSSBDQQIRAIG+L6n5sD90G0G3JvADphgwCQYFKw4DAhoFAKCCAXgwGAYJKoZIhvcN AQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG9w0BCQUxDxcNMTEwOTEzMDg0OTIwWjAjBgkqhkiG9w0B CQQxFgQUT8OepGy3HSFBmxwUujP/otVUAl0wVgYJKwYBBAGCNxAEMUkwRzAzMQswCQYDVQQGEwJG STEOMAwGA1UEChMFTm9raWExFDASBgNVBAMTC05va2lhIEJJIENBAhAwflqlqTyUTLouYuUuwnLx MFgGCyqGSIb3DQEJEAILMUmgRzAzMQswCQYDVQQGEwJGSTEOMAwGA1UEChMFTm9raWExFDASBgNV BAMTC05va2lhIEJJIENBAhAwflqlqTyUTLouYuUuwnLxMGcGCSqGSIb3DQEJDzFaMFgwCgYIKoZI hvcNAwcwDgYIKoZIhvcNAwICAgCAMA0GCCqGSIb3DQMCAgFAMAcGBSsOAwIHMA0GCCqGSIb3DQMC AgEoMAcGBSsOAwIaMAoGCCqGSIb3DQIFMA0GCSqGSIb3DQEBAQUABIIBAH9RhGRKXE1oj86c28tF 7jzE9fncCfQPGjwKgVK8aqoSHqSf1n5QpPo2ciFH7E4IfPws0eET1kPScCIhsOudOdFvnMAqPuBS 5iUilvv/ujYe1yluhava/IHygoj+7IVxhWd71ZqUZoTInBM7Nt+m3+8sVuYqUb49QVBjvXW1ewaE mJu1L6CCui0Rw7IA2yec2mgrDWJMc8mkmpt+XER3aP3dV8LEAQPzYpyScDaF1hliDQW5JUoSmC5e jlnSSRGENh+sfWjgzEU2WwGYvW3VOKYgvPwqiQE+U1v7u0b+cwK4r1jKpkLVCNSJPXW9s+PMcb4o N8G5jP/KYhyve81i1h0AAAAAAAA= ------=_NextPart_000_00C6_01CC720B.2CA99620-- From ajs@anvilwalrusden.com Tue Sep 13 03:13: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 24AC021F8B19 for ; Tue, 13 Sep 2011 03:13:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.98 X-Spam-Level: X-Spam-Status: No, score=-1.98 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_SORBS_WEB=0.619] 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 Ls3nDB-ZjUO8 for ; Tue, 13 Sep 2011 03:13:12 -0700 (PDT) Received: from mail.yitter.info (mail.yitter.info [208.86.224.201]) by ietfa.amsl.com (Postfix) with ESMTP id 9460021F8797 for ; Tue, 13 Sep 2011 03:13:12 -0700 (PDT) Received: from shinkuro.com (unknown [89.211.51.194]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.yitter.info (Postfix) with ESMTPSA id 5D5F01ECB41C for ; Tue, 13 Sep 2011 10:15:14 +0000 (UTC) Date: Tue, 13 Sep 2011 06:15:13 -0400 From: Andrew Sullivan To: mif@ietf.org Message-ID: <20110913101512.GB71534@shinkuro.com> References: <4E683F9B.7020905@gmail.com> <916CE6CF87173740BC8A2CE4430969620256F33F@008-AM1MPN1-032.mgdnok.nokia.com> <4E692D62.5080902@gmail.com> <916CE6CF87173740BC8A2CE443096962025704BA@008-AM1MPN1-032.mgdnok.nokia.com> <4E6A7E9F.5070706@gmail.com> <916CE6CF87173740BC8A2CE44309696202571A30@008-AM1MPN1-032.mgdnok.nokia.com> <4E6EAECC.6080703@gmail.com> <916CE6CF87173740BC8A2CE44309696202572997@008-AM1MPN1-032.mgdnok.nokia.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <916CE6CF87173740BC8A2CE44309696202572997@008-AM1MPN1-032.mgdnok.nokia.com> User-Agent: Mutt/1.5.21 (2010-09-15) Subject: Re: [mif] Last Call for MIF DNS server selection document 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, 13 Sep 2011 10:13:13 -0000 On Tue, Sep 13, 2011 at 08:49:21AM +0000, teemu.savolainen@nokia.com wrote: > Brian, > > Sounds good for me - included now for the next update. I like this too. A -- Andrew Sullivan ajs@anvilwalrusden.com From mrw@lilacglade.org Tue Sep 13 04:54: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 6DC5521F877F for ; Tue, 13 Sep 2011 04:54:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.11 X-Spam-Level: X-Spam-Status: No, score=-102.11 tagged_above=-999 required=5 tests=[AWL=0.155, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GAq7c43ImIgJ for ; Tue, 13 Sep 2011 04:54:31 -0700 (PDT) Received: from mail.suchdamage.org (permutation-city.suchdamage.org [69.25.196.28]) by ietfa.amsl.com (Postfix) with ESMTP id 8A05521F8B06 for ; Tue, 13 Sep 2011 04:54:30 -0700 (PDT) Received: from [10.36.0.36] (pool-108-7-232-64.bstnma.fios.verizon.net [108.7.232.64]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (Client did not present a certificate) by mail.suchdamage.org (Postfix) with ESMTPSA id B1B4B2010E; Tue, 13 Sep 2011 07:58:27 -0400 (EDT) Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Margaret Wasserman In-Reply-To: <20110908204329.GN38973@shinkuro.com> Date: Tue, 13 Sep 2011 07:56:32 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: <63F4EE41-6AC5-4605-9C5E-9C33238BB460@lilacglade.org> References: <20110908204329.GN38973@shinkuro.com> To: Andrew Sullivan X-Mailer: Apple Mail (2.1084) Cc: mif@ietf.org Subject: Re: [mif] Last Call for MIF DNS server selection document 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, 13 Sep 2011 11:54:35 -0000 Hi Andrew, Thank you for this careful review, and your very helpful comments. The = draft authors should address these issues before the draft moves = forward. Margaret On Sep 8, 2011, at 4:43 PM, Andrew Sullivan wrote: > Dear colleagues, >=20 > On Mon, Aug 29, 2011 at 03:31:39PM +0800, Hui Deng wrote: >> Based on the last IETF mif meeting, we are issueing working group = last call for the document: >> http://tools.ietf.org/id/draft-ietf-mif-dns-server-selection-03.txt >=20 > I have read this document, and previous drafts. >=20 > I have some comments. >=20 > First, about nits: there are several places where the document needs a > good once-over for correct usage, grammar, and spelling. Articles > seem to be missing in many places. It'd be good to sort this out, but > I can understand the document without this being fixed & I'm sure the > RFC Editor will fix it anyway. I'm not going to send a list of nits > just now because I have too many substantive comments. >=20 > As an overall comment, there are sections of the document that explain > the motivation and background, and sections of the document that > prescribe steps to be taken. The former are informative, and the > latter normative. I suggest including near the beginning an overview > stating what sections are informative and what are normative, and > breaking those sections cleanly (i.e. no explanatory text in the > normative sections).=20 >=20 > At the beginning of the draft we have this: >=20 > When multiple namespaces are visible for a node, some DNS servers > have information other servers do not have. Because of that, a > multi-homed node cannot assume every DNS server is able to properly > answer for any query, but instead the node must be able to ask right > server for the information it needs. >=20 > I've had a hard time expressing why this text has been bothering me, > but I think I understand what it is: that text is not explicit enough > that it is starting from the premise that the DNS is not a unified > global namespace. I think it needs another sentence, at the > beginning, along the following lines: >=20 > We start from the premise that operators sometimes include private > namespaces in the answers they provide from DNS servers, and that > those private namespaces are at least as useful to clients as the > answers from the public DNS. >=20 > The next paragraph is not really convincing as it stands: >=20 > An example of an application that benefits from multi-homing is a = web > browser that commonly accesses many different destinations and needs > to be able to dynamically communicate over different network > interfaces. >=20 > I think what that actually means is this: >=20 > An example of an application that benefits from multi-homing is a > web browser that commonly accesses many different destinations, > each of which is available only on one network. The browser > therefore needs to be able to communicate over different network > interfaces, depending on the destination it is trying to reach. >=20 > The key point here, I think, is that the networks are disparate and > not actually all available via the public network. By making these > adjustments, it makes the document more open-handed about the fact > it's trying to address: there are all kinds of pockets on the > Internet, and you have to connect to different pockets via different > means. >=20 > In section 4.1, we have this: >=20 > When a DNS query needs to be made, the resolver SHOULD give highest > precedence to the DNS servers explicitly known to serve matching > suffixes or prefixes. >=20 > I really dislike the term "suffix" here, and I'm not sure "prefix" is > what you want either. I think "suffix" really means "domain", right? > That is, if I offer a DNS server that is high-priority for > example.com, it can answer for anything from example.com all the way > down. No? Similarly, you might just want "networks" for the reverse > tree, since "prefix" doesn't exactly get it right: the network address > is turned around in the DNS query. (This also appears elsewhere in > the draft, but I won't mention it again unless I'm proposing text.) > "Prefix" is probably fine if you make it clear that you're providing > the prefix of a network, and that it's the client's job to do the > right thing with that prefix in order to formulate reverse-tree DNS > queries. >=20 > Next, >=20 > However, the resolver SHOULD take into account > different trust levels of pieces of DNS server selection information > the resolver may have received from node's network interfaces. The > resolver SHOULD prefer DNS servers of trusted interfaces. >=20 > Why isn't this MUST? This entire procedure is hard for me to follow, > in fact. It seems to me that we have two different meanings of > "trust" here, and I think that may be part of the problem. The first > meaning (trust1) is "a setting that comes with the information that > DNS server S on interface I provides namespace N with trust-level T". > This is a trust-value that is metadata provided by the provider of the > name server address-interface binding. The second meaning (trust2) is > how much you, the client, believe the data you got: did you get the > trust1 data in a way that you can be sure it's legitimate? It seems > to me that combining trust1 and trust2 into a single scale might be > wrong, and I think that the last row in Figure 4 suggests this. If I > simply don't know whether the data I get on interface B is real or > spoofed, why would I ever use that, even if it's "medium priority", > over the data I can be sure is an unspoofed answer on interface A? >=20 > Also, I think this sentence is missing an "un" before some "trusted": >=20 > The DNS servers of trusted interfaces may be of highest priority > only if trusted interfaces specifically configure DNS servers to be > of low priority. >=20 > I think the discussion just after Figure 4 about revealing information > about ongoing communications is total nonsense, and should be removed. > If you want to put names in the DNS, they're never going to be secret. > The attempts to use split-brain DNS and so on for hiding network > resources are a completely misguided attempt at security by obscurity, > and I don't think the draft should include any text that even implies > this technique works. Private DNS names leak all over the place, and > if you think otherwise you're dreaming. >=20 > Later, we have >=20 > Because DNSSEC provides cryptographic assurance of the integrity of > DNS data, data that can be validated under DNSSEC is necessarily to > be preferred over data that cannot be. It follows that, if > validation is not performed by the host making the decision about > whether to trust the DNS data from a given interface, it cannot make > a decision to prefer data from any interface with any great > assurance: any response could be forged, and there is no way to > detect it without DNSSEC. >=20 > That isn't true. If you have a cryptographically strong connection to > a DNS server and you know that it is doing DNS validation (because, > for instance, your corporate overlords told you, "We do validation on > the VPN DNS server"), you do in fact have a reason to prefer the > answers from that server. You might set DO and not CD, and get back > the AD bit on your answer, giving you evidence that the validation was > done by the server. I think the paragraph can be rewritten this way > (although this includes some explanatory material and some normative > material; as I suggested above, perhaps that ought to be split). >=20 > Because DNSSEC provides cryptographic assurance of the integrity of > DNS data, data that can be validated under DNSSEC is necessarily to > be preferred over data that cannot be. There are two ways that a > host can determine that data is valid under DNSSEC. The first is > to perform DNSSEC validation itself. The second is to have a > secure connection to an authenticated DNS server, and to rely on > that DNS server to perform DNSSEC validation (signalling that it > has done so using the AD bit). If a DNS response is not proven to > be unmolested using DNSSEC, then a host cannot make a decision to > prefer data from any interface with any great assurance: any > response could be forged, and there is no way to detect the forgery > without DNSSEC. Therefore, a DNSSEC-aware resolver MUST NOT > proceed with a reply that cannot be validated using DNSSEC if DNS > queries sent to other servers are still pending. >=20 > This instruction seems to contradict the previous text: >=20 > In the case of a trusted DNS server replying negatively to a = question > having matching suffix, it will be for implementation to decide > whether to consider that as a final response, or whether to ask also > from other DNS servers. The implementation decision may be based, > for example, on deployment or trust models. >=20 > Instead of "matching suffix", we could say something like "from a DNS > server that can provide answers for the queried name". But I think > what this is saying is that, if you get a validated NXDOMAIN from an > interface, you're allowed to go on and ask other servers. Even if the > answer can't be validated? If so, this seems to contradict the > passages before it, and it's clearly an attack vector on DNSSEC's > provable non-existence. Some people think that feature is dumb, but > it's part of what DNSSEC offers now, and it would be strange to > introduce a way to turn it off. I'd add a reference here to the > "different trust anchor" discussion in Appendix B. See also below. >=20 > I can't see anything you can do about cases where a DNS server always > lies to you. On the other hand, if you do DNSSEC, those servers will > always fail validation anyway, so we can hope they'll meet the fate > they deserve. >=20 > In section 4.2, I don't understand, "IPv6 prefixes should cover all > the DNS suffixes configured in this option." Maybe I've actually > misunderstood the use of "prefix" and "suffix" in this document? >=20 > In section 4.5, I find this odd: >=20 > The OPTION_DNS_SERVER_SELECT is designed to coexist with > OPTION_DNS_SERVERS defined in [RFC3646]. The DNS servers configured > via OPTION_DNS_SERVERS MUST BE considered as default name servers > with medium preference. When both options are received from the = same > network interface and the OPTION_DNS_SERVER_SELECT contains default > DNS server address, the resolver MUST make the decision which one to > prefer based on preferences. >=20 > I read that to mean that, if you get both options and the > OPTION_DNS_SERVER_SELECT contains a default DNS server address, then > the behaviour is up to you (i.e. undefined). Why is that a MUST? Why > isn't it just "... the resolver MAY use whichever option it likes"? >=20 > In the same section, does this >=20 > If both OPTION_DNS_SERVERS and OPTION_DNS_SERVER_SELECT contain the > same DNS server(s) IPv6 address(es), only one instance of each DNS > servers' IPv6 addresses shall be added to the DNS server list. >=20 > mean "only add the same address of a DNS server to the server list > once"? The passage as it is reads to me as though you might throw > away some addresses you get. >=20 > In section 4.6., I think that it needs to be made clear that a bare > name is first treated as a pre-DNS hostname before it encounters the > DNS search list. (Frankly, that entire mechanism is broken, and it > would suit me just fine if the document said, "This algorithm is > incompatible with the DNS search list and the OPTION_DOMAIN_LIST > feature." But I know people would scream about it. It's still > broken.) >=20 > In 4.7, what about other things that could do context-sensitive > referrals, like SRV? >=20 > In A.1, the same discussion about revealing information as above > pertains. >=20 > Appendix B is interesting because it addresses a concern I have about > what to do when validation succeeds on an NXDOMAIN, as discussed above > under section 4.1. >=20 > I hope these comments are useful. >=20 > Best regards, >=20 > Andrew >=20 > --=20 > Andrew Sullivan > ajs@anvilwalrusden.com > _______________________________________________ > mif mailing list > mif@ietf.org > https://www.ietf.org/mailman/listinfo/mif From margaretw42@gmail.com Tue Sep 13 04:58: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 A1E9121F8B0D for ; Tue, 13 Sep 2011 04:58:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.265 X-Spam-Level: X-Spam-Status: No, score=-2.265 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334] 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 alZvW2rfrg48 for ; Tue, 13 Sep 2011 04:58:04 -0700 (PDT) Received: from mail.suchdamage.org (permutation-city.suchdamage.org [69.25.196.28]) by ietfa.amsl.com (Postfix) with ESMTP id 3028621F8B06 for ; Tue, 13 Sep 2011 04:58:04 -0700 (PDT) Received: from [10.36.0.36] (pool-108-7-232-64.bstnma.fios.verizon.net [108.7.232.64]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (Client did not present a certificate) by mail.suchdamage.org (Postfix) with ESMTPSA id EC06C203BA; Tue, 13 Sep 2011 08:02:04 -0400 (EDT) Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Margaret Wasserman In-Reply-To: <4E683F9B.7020905@gmail.com> Date: Tue, 13 Sep 2011 08:00:09 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: <37CF81A7-B249-40EB-B8E6-A706680C4174@gmail.com> References: <4E683F9B.7020905@gmail.com> To: Brian E Carpenter X-Mailer: Apple Mail (2.1084) Cc: mif@ietf.org, Hui Deng Subject: Re: [mif] Last Call for MIF DNS server selection document 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, 13 Sep 2011 11:58:04 -0000 Hi Brian, On Sep 8, 2011, at 12:07 AM, Brian E Carpenter wrote: > Has this document been reviewed in DNSEXT and DNSOP? No, but this is a good thought... I will talk to Jari and Hui about how = best to get good review of this draft by DNS experts. I'm not sure if = we should just send mail to the DNSEXT and DNSOP WGs, or if we should = ask for a DNS Directorate review. Jari and Hui, what do you think? > If not, I would strongly recommend that before asking the AD > to review it in detail. I would expect considerable discussion of > the following text and its consequences: >=20 >> In deployments where multiple namespaces are present, selection of >> correct route and destination and source addresses for the actual = IP >> connection is crucial as well, as the resolved destination's IP >> addresses may be only usable on the network interface over which = the >> name was resolved on. I think there is a lot more acceptance, now, that these sorts of = deployments do exist in the real world and need to be handled properly = (otherwise they cause real-world problems) than there used to be in the = IETF in the past. We'll see how the discussion goes, but I'm expecting = a lot less controversy on this point than we would have seen 5+ years = ago. Margaret From Ted.Lemon@nominum.com Tue Sep 13 05:59: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 8656321F8B4A for ; Tue, 13 Sep 2011 05:59:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.593 X-Spam-Level: X-Spam-Status: No, score=-106.593 tagged_above=-999 required=5 tests=[AWL=0.005, 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 ZWRXwBaMw1PH for ; Tue, 13 Sep 2011 05:59:44 -0700 (PDT) Received: from exprod7og116.obsmtp.com (exprod7og116.obsmtp.com [64.18.2.219]) by ietfa.amsl.com (Postfix) with ESMTP id C2CA721F8B42 for ; Tue, 13 Sep 2011 05:59:43 -0700 (PDT) Received: from shell-too.nominum.com ([64.89.228.229]) (using TLSv1) by exprod7ob116.postini.com ([64.18.6.12]) with SMTP ID DSNKTm9UNv6qLJe5dsAbZJLwWb/wedwgcVal@postini.com; Tue, 13 Sep 2011 06:01:50 PDT Received: from archivist.nominum.com (archivist.nominum.com [64.89.228.108]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "*.nominum.com", Issuer "Go Daddy Secure Certification Authority" (verified OK)) by shell-too.nominum.com (Postfix) with ESMTP id 234E7F8020 for ; Tue, 13 Sep 2011 06:01:42 -0700 (PDT) Received: from webmail.nominum.com (cas-02.win.nominum.com [64.89.228.132]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (Client CN "mail.nominum.com", Issuer "Go Daddy Secure Certification Authority" (verified OK)) by archivist.nominum.com (Postfix) with ESMTPS id 6289B190061; Tue, 13 Sep 2011 06:01:40 -0700 (PDT) (envelope-from Ted.Lemon@nominum.com) Received: from MBX-01.WIN.NOMINUM.COM ([64.89.228.133]) by CAS-02.WIN.NOMINUM.COM ([64.89.228.132]) with mapi id 14.01.0289.001; Tue, 13 Sep 2011 06:01:40 -0700 From: Ted Lemon To: maximilien mouton Thread-Topic: [mif] Comments on draft-mouton-mif-dhcpv6-drlo-00 Thread-Index: AcxxClosDL9zuhm1Q+CTqXShqzwWxAAw84cAAAfxtgAABv0IAAARg+mA Date: Tue, 13 Sep 2011 13:01:39 +0000 Message-ID: References: <3CF88B99A9ED504197498BC6F6F04B81040FBDA9@XMB-BGL-41E.cisco.com> <4E6E7A72.9030208@gmail.com> <4E6EAFC2.5060906@gmail.com> <4E6EDEA8.3080108@gmail.com> In-Reply-To: <4E6EDEA8.3080108@gmail.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [173.162.214.218] Content-Type: multipart/alternative; boundary="_000_CFDF82EE052B4A61AE1B152337822B6Enominumcom_" MIME-Version: 1.0 Cc: "" Subject: Re: [mif] Comments on draft-mouton-mif-dhcpv6-drlo-00 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, 13 Sep 2011 12:59:44 -0000 --_000_CFDF82EE052B4A61AE1B152337822B6Enominumcom_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable On Sep 13, 2011, at 12:40 AM, maximilien mouton wrote: In this case an Information-Request when client's lifetime expires (or is close to) is sufficient especially if lifetime's upper limit is higher. One thing to be crystal clear about is that even if an option is added that= contains a lifetime, it would be a major extension of the DHCP protocol to= propose that the client include that lifetime in its calculations for when= to renew. Adding an option is a minor extension. I would oppose a majo= r extension for this purpose; I don't know how the working group as a whole= would feel about it, but I suspect there would be a great deal of skeptici= sm. The way lifetimes of configuration information are handled is either with t= he IRT, in the case of stateless DHCPv6, or with the lease renewal timer, i= n the case of stateful. So if you put a lifetime in a route option, I don= 't see what good it would do. --_000_CFDF82EE052B4A61AE1B152337822B6Enominumcom_ Content-Type: text/html; charset="us-ascii" Content-ID: Content-Transfer-Encoding: quoted-printable
On Sep 13, 2011, at 12:40 AM, maximilien mouton wrote:
In this case an Information-Request when client's lifetime expires (or
is close to) is sufficient especially if lifetime's upper limit is
higher.

One thing to be crystal clear about is that even if an option is added= that contains a lifetime, it would be a major extension of the DHCP protoc= ol to propose that the client include that lifetime in its calculations for= when to renew.   Adding an option is a minor extension.   I would oppose a major extension for this pur= pose; I don't know how the working group as a whole would feel about it, bu= t I suspect there would be a great deal of skepticism.

The way lifetimes of configuration information are handled is either w= ith the IRT, in the case of stateless DHCPv6, or with the lease renewal tim= er, in the case of stateful.   So if you put a lifetime in a route opt= ion, I don't see what good it would do.

--_000_CFDF82EE052B4A61AE1B152337822B6Enominumcom_-- From simon.perreault@viagenie.ca Tue Sep 13 07:29: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 B6D1121F8804 for ; Tue, 13 Sep 2011 07:29:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.59 X-Spam-Level: X-Spam-Status: No, score=-2.59 tagged_above=-999 required=5 tests=[AWL=0.009, 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 gyffe1wj+ksm for ; Tue, 13 Sep 2011 07:29:07 -0700 (PDT) Received: from jazz.viagenie.ca (unknown [IPv6:2620:0:230:8000:226:55ff:fe57:14db]) by ietfa.amsl.com (Postfix) with ESMTP id CDEEB21F87C2 for ; Tue, 13 Sep 2011 07:29:02 -0700 (PDT) Received: from banana.viagenie.ca (nomis80.org [97.107.136.111]) by jazz.viagenie.ca (Postfix) with ESMTPSA id 18FAC21107; Tue, 13 Sep 2011 10:31:07 -0400 (EDT) Message-ID: <4E6F6933.1010908@viagenie.ca> Date: Tue, 13 Sep 2011 10:31:15 -0400 From: Simon Perreault User-Agent: Mozilla/5.0 (X11; Linux i686; rv:5.0) Gecko/20110707 Thunderbird/5.0 MIME-Version: 1.0 To: Brian E Carpenter References: <20110910220345.29077.66749.idtracker@ietfa.amsl.com> <4E6BE7BF.5030501@gmail.com> <4E6C8F4A.308@gmail.com> <4E6E053B.7000305@viagenie.ca> <4E6E097F.8010205@gmail.com> <4E6E0C4A.7030105@viagenie.ca> <4E6E10E0.6010607@gmail.com> <4E6E13E0.2030402@viagenie.ca> <4E6EB0DC.5040102@gmail.com> In-Reply-To: <4E6EB0DC.5040102@gmail.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: mif@ietf.org Subject: Re: [mif] I-D draft-ietf-mif-dhcpv6-route-option-03 published X-BeenThere: mif@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multiple Interface Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 13 Sep 2011 14:29:20 -0000 Brian E Carpenter wrote, on 09/12/2011 09:24 PM: > On 2011-09-13 02:14, Simon Perreault wrote: >> On 2011-09-12 10:02, Alexandru Petrescu wrote: >>>> I don't see the use case. Can't the DHCP client on the very small >>>> platform just install the default route first, then whatever other >>>> routes it can support, and ignore the rest? >>> Do you think there exist a DHCP way to say: "install the default route >>> first and, if you have enough memory, install these specific routes"? >> >> Maybe it can be written in the draft. For example: >> >> Hosts MUST install routes in the order they are listed. If any routes >> cannot be installed due to resource constraints, routes MAY be dropped >> starting from the end. >> >> With this, the operator can put the default route first and obtain the >> behaviour you're describing. > > That won't work if the host also gets a default route from RA. There's > nothing to stop DHCPv6 and RA being used simultaneously, for different > prefixes, and providing different default routers. I'm not following you. - That's not a problem I'm trying to solve with the above proposal. - Even with a separate DHCP option dedicated to the default route, I don't see how the problem you mentioned gets solved. Simon -- DTN made easy, lean, and smart --> http://postellation.viagenie.ca NAT64/DNS64 open-source --> http://ecdysis.viagenie.ca STUN/TURN server --> http://numb.viagenie.ca From alexandru.petrescu@gmail.com Tue Sep 13 09:16: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 3674C21F8A69 for ; Tue, 13 Sep 2011 09:16:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.43 X-Spam-Level: X-Spam-Status: No, score=-2.43 tagged_above=-999 required=5 tests=[AWL=-0.181, BAYES_00=-2.599, HELO_EQ_FR=0.35] 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 HynPqkzS-7d9 for ; Tue, 13 Sep 2011 09:16:35 -0700 (PDT) Received: from oxalide-out.extra.cea.fr (oxalide-out.extra.cea.fr [132.168.224.8]) by ietfa.amsl.com (Postfix) with ESMTP id 649B421F86AA for ; Tue, 13 Sep 2011 09:16:35 -0700 (PDT) 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 p8DGIe5k022493 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT) for ; Tue, 13 Sep 2011 18:18:40 +0200 Received: from muguet1.intra.cea.fr (muguet1.intra.cea.fr [132.166.192.6]) by pisaure.intra.cea.fr (8.14.4/8.14.4) with ESMTP id p8DGIeo0023004 for ; Tue, 13 Sep 2011 18:18:40 +0200 (envelope-from alexandru.petrescu@gmail.com) Received: from [127.0.0.1] ([132.166.133.183]) by muguet1.intra.cea.fr (8.13.8/8.13.8/CEAnet-Intranet-out-1.1) with ESMTP id p8DGIaGL017783 for ; Tue, 13 Sep 2011 18:18:40 +0200 Message-ID: <4E6F825C.3080303@gmail.com> Date: Tue, 13 Sep 2011 18:18:36 +0200 From: Alexandru Petrescu User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:6.0.2) Gecko/20110902 Thunderbird/6.0.2 MIME-Version: 1.0 To: mif@ietf.org References: <3CF88B99A9ED504197498BC6F6F04B81040FBDA9@XMB-BGL-41E.cisco.com> <4E6E7A72.9030208@gmail.com> <4E6EAFC2.5060906@gmail.com> <4E6EDEA8.3080108@gmail.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Subject: Re: [mif] Comments on draft-mouton-mif-dhcpv6-drlo-00 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, 13 Sep 2011 16:16:36 -0000 Le 13/09/2011 15:01, Ted Lemon a 閏rit : > On Sep 13, 2011, at 12:40 AM, maximilien mouton wrote: >> In this case an Information-Request when client's lifetime expires >> (or is close to) is sufficient especially if lifetime's upper limit >> is higher. > > One thing to be crystal clear about is that even if an option is > added that contains a lifetime, it would be a major extension of the > DHCP protocol to propose that the client include that lifetime in its > calculations for when to renew. Adding an option is a minor > extension. I would oppose a major extension for this purpose; I don't > know how the working group as a whole would feel about it, but I > suspect there would be a great deal of skepticism. > > The way lifetimes of configuration information are handled is either > with the IRT, in the case of stateless DHCPv6, or with the lease > renewal timer, in the case of stateful. So if you put a lifetime in a > route option, I don't see what good it would do. I agree DHCP has its separate means to deal with lifetimes. Default route (not route in general) has a particular lifetime characteristic when managed with ND. It is good that lifetime of ND and of DHCP are coherent when used on default route. Alex > > > > _______________________________________________ mif mailing list > mif@ietf.org https://www.ietf.org/mailman/listinfo/mif From alexandru.petrescu@gmail.com Tue Sep 13 09:33: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 4E71D21F8BF7 for ; Tue, 13 Sep 2011 09:33:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.424 X-Spam-Level: X-Spam-Status: No, score=-2.424 tagged_above=-999 required=5 tests=[AWL=-0.175, BAYES_00=-2.599, HELO_EQ_FR=0.35] 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 YYmQCurcRlHS for ; Tue, 13 Sep 2011 09:33:31 -0700 (PDT) Received: from cirse-out.extra.cea.fr (cirse-out.extra.cea.fr [132.167.192.142]) by ietfa.amsl.com (Postfix) with ESMTP id 6909621F8BA0 for ; Tue, 13 Sep 2011 09:33:31 -0700 (PDT) Received: from pisaure.intra.cea.fr (pisaure.intra.cea.fr [132.166.88.21]) by cirse.extra.cea.fr (8.14.2/8.14.2/CEAnet-Internet-out-2.2) with ESMTP id p8DGZZmX014404 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT) for ; Tue, 13 Sep 2011 18:35:36 +0200 Received: from muguet1.intra.cea.fr (muguet1.intra.cea.fr [132.166.192.6]) by pisaure.intra.cea.fr (8.14.4/8.14.4) with ESMTP id p8DGZZND028071 for ; Tue, 13 Sep 2011 18:35:35 +0200 (envelope-from alexandru.petrescu@gmail.com) Received: from [127.0.0.1] ([132.166.133.183]) by muguet1.intra.cea.fr (8.13.8/8.13.8/CEAnet-Intranet-out-1.1) with ESMTP id p8DGZVTh025824 for ; Tue, 13 Sep 2011 18:35:35 +0200 Message-ID: <4E6F8653.6050708@gmail.com> Date: Tue, 13 Sep 2011 18:35:31 +0200 From: Alexandru Petrescu User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:6.0.2) Gecko/20110902 Thunderbird/6.0.2 MIME-Version: 1.0 To: mif@ietf.org References: <3CF88B99A9ED504197498BC6F6F04B81040FBDA9@XMB-BGL-41E.cisco.com> <4E6E7A72.9030208@gmail.com> <3CF88B99A9ED504197498BC6F6F04B81040FC010@XMB-BGL-41E.cisco.com> In-Reply-To: <3CF88B99A9ED504197498BC6F6F04B81040FC010@XMB-BGL-41E.cisco.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Subject: Re: [mif] Comments on draft-mouton-mif-dhcpv6-drlo-00 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, 13 Sep 2011 16:33:32 -0000 Le 13/09/2011 07:48, Gaurav Halwasia (ghalwasi) a 閏rit : > Hi Maximilien, > >>> I read this draft, I think similar issue is also being >>> discussed/solved by draft-dec-dhcpv6-route-option-05 as well. >>> > >> Can you say more about this discussion? > > Draft [draft-dec-dhcpv6-route-option-05] handles the cases of both > default/other static route using one generic option. That's it I was > able to gather in my one glance to this draft. Clarification: do you actually mean draft-ietf-mif-dhcpv6-route-option-03 (which is a WG item) instead of draft-dec-dhcpv6-route-option-05? > On Route lifetime and the length of it's field. I strongly think that > this field is unnecessary as I don't think default route (given by > DHCPv6 server) will be that shortlived. Even if it is short lived, > anyways a new message exchange needs to happen irrespective of this > field. (either server initiated or client initiated.) > > In ND, as the messages are quite periodic (in comparison to DHCPv6), PEriodicity of ND messages can be tweaked at knob. Also, DHCP can be quite verbose. In a WiFi hotspot setting of several APs I see DHCP messages as often as every minute, or worse - depends on user physical speed - which is unpredictable. The quicker the movement, the more often DHCP messages happen. > having a lifetime in ND message makes sense. One of the primary use > of having lifetime in ND is to advertise route as stale (by setting > lifetime as zero). Hmm.. yes and no. Yes prefixes in ND structures may become stale in time, or triggered. No, thinking the "Router Lifetime" (not "route lifetime") set to 0 in an RA means that is a default router, and does not mean that is a stale route. > The main purpose of having RECONFIGURE (sent by Server) message is to > actually achieve the same thing. At the first place, I feel that > default routes are not going to be that short lived and even if it is > (in some scenarios), server can always use RECONFIGURE. I agree there are a number of choices of what happens when lifetime of a default route expires. We have not implemented this because we don't know for sure what should happen. > On MAC address issue. Again, think that it's not a good idea to send > MAC address of default router in DHCPv6 option. I will probably eat > a lot of bandwidth in comparison to the benefit it can provide. The benefit of having (optional) MAC address in the DHCP Advertise next to the IP address of the default router is that it avoids doing NS-NA to solve that IP address into a MAC address. MAC address is 48bit and a pair of NS-NA messages is bigger in terms of message size. Alex > Thanks, Gaurav > > -----Original Message----- From: maximilien mouton > [mailto:maximilien.mouton@gmail.com] Sent: Tuesday, September 13, > 2011 3:03 AM To: Gaurav Halwasia (ghalwasi) Cc: mif@ietf.org Subject: > Re: [mif] Comments on draft-mouton-mif-dhcpv6-drlo-00 > > Hi Gaurav, > > Thank you for your review. See my answers inside. > > Le 12/09/2011 07:10, Gaurav Halwasia (ghalwasi) a 閏rit : >> Hi, >> >> >> >> I read this draft, I think similar issue is also being >> discussed/solved by draft-dec-dhcpv6-route-option-05 as well. >> > > Can you say more about this discussion? > >> >> >> I see that you are proposing to have lifetime and MAC address in >> the route option. Why do we want to communicate the lifetime of the >> route in this option and that too I guess you are proposing to have >> a upper limit of 150 minutes (9000 seconds) on that. What is the >> reason behind that. > > Actually we are following section 6.2.1 of rfc 4861 but this value > can be discussed. > >> What should be done after the expiry of this 150 minutes..? >> Information-Request..? or DHCP Renew.? > > I tend to Information-Request. > >> >> I don't think that router lifetime will be that short > > I understand your comment. What do you propose? 7 days like proposed > for a not default route? Do you think this field should be 2 or 4 > bytes long? > > >> and even if router lifetime expires, DHCPv6 server can just send >> RECONFIGURE. > > I agree. > >> Normally IPv6 addres lease time will not usually be that less. >> >> >> >> Further, What's the real need of having MAC/link address in the >> route list option as there already exists means to get it. > > We assume that this option is useful because it gives the client the > possibility to avoid waiting for na. > > Thanks, > > Maximilien > >> >> Thanks, >> >> Gaurav >> >> >> >> >> >> _______________________________________________ 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 Ted.Lemon@nominum.com Tue Sep 13 09:56: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 7E16E21F8B40 for ; Tue, 13 Sep 2011 09:56:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.593 X-Spam-Level: X-Spam-Status: No, score=-106.593 tagged_above=-999 required=5 tests=[AWL=0.005, 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 kkJ3q1V9C5Kv for ; Tue, 13 Sep 2011 09:56:55 -0700 (PDT) Received: from exprod7og106.obsmtp.com (exprod7og106.obsmtp.com [64.18.2.165]) by ietfa.amsl.com (Postfix) with ESMTP id BBFF321F8B2F for ; Tue, 13 Sep 2011 09:56:54 -0700 (PDT) Received: from shell-too.nominum.com ([64.89.228.229]) (using TLSv1) by exprod7ob106.postini.com ([64.18.6.12]) with SMTP ID DSNKTm+L01Wm5x5DQM3bVIrY0osbNQoTL19d@postini.com; Tue, 13 Sep 2011 09:59:01 PDT Received: from archivist.nominum.com (archivist.nominum.com [64.89.228.108]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "*.nominum.com", Issuer "Go Daddy Secure Certification Authority" (verified OK)) by shell-too.nominum.com (Postfix) with ESMTP id B60781B82BC for ; Tue, 13 Sep 2011 09:58:59 -0700 (PDT) Received: from webmail.nominum.com (cas-02.win.nominum.com [64.89.228.132]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (Client CN "mail.nominum.com", Issuer "Go Daddy Secure Certification Authority" (verified OK)) by archivist.nominum.com (Postfix) with ESMTPS id A92AA190061; Tue, 13 Sep 2011 09:58:59 -0700 (PDT) (envelope-from Ted.Lemon@nominum.com) Received: from MBX-01.WIN.NOMINUM.COM ([64.89.228.133]) by CAS-02.WIN.NOMINUM.COM ([64.89.228.132]) with mapi id 14.01.0289.001; Tue, 13 Sep 2011 09:58:59 -0700 From: Ted Lemon To: Alexandru Petrescu Thread-Topic: [mif] Comments on draft-mouton-mif-dhcpv6-drlo-00 Thread-Index: AcxxClosDL9zuhm1Q+CTqXShqzwWxAAw84cAAAfxtgAABv0IAAARg+mAAAbg3wAAAWjoAA== Date: Tue, 13 Sep 2011 16:58:58 +0000 Message-ID: <3D0B3661-8A8F-4BB2-A8EF-25007BEAF66C@nominum.com> References: <3CF88B99A9ED504197498BC6F6F04B81040FBDA9@XMB-BGL-41E.cisco.com> <4E6E7A72.9030208@gmail.com> <4E6EAFC2.5060906@gmail.com> <4E6EDEA8.3080108@gmail.com> <4E6F825C.3080303@gmail.com> In-Reply-To: <4E6F825C.3080303@gmail.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [173.162.214.218] Content-Type: multipart/alternative; boundary="_000_3D0B36618A8F4BB2A8EF25007BEAF66Cnominumcom_" MIME-Version: 1.0 Cc: "" Subject: Re: [mif] Comments on draft-mouton-mif-dhcpv6-drlo-00 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, 13 Sep 2011 16:56:55 -0000 --_000_3D0B36618A8F4BB2A8EF25007BEAF66Cnominumcom_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable On Sep 13, 2011, at 12:18 PM, Alexandru Petrescu wrote: It is good that lifetime of ND and of DHCP are coherent when used on default route. Could you restate your point more explicitly? I find that I could interpr= et your response to mean either that you think that the major extension to = DHCP is required, or that it is not. --_000_3D0B36618A8F4BB2A8EF25007BEAF66Cnominumcom_ Content-Type: text/html; charset="iso-8859-1" Content-ID: Content-Transfer-Encoding: quoted-printable
On Sep 13, 2011, at 12:18 PM, Alexandru Petrescu wrote:
It is good that lifetime of ND and of DHCP are coherent when used on
default route.

Could you restate your point more explicitly?   I find that I cou= ld interpret your response to mean either that you think that the major ext= ension to DHCP is required, or that it is not.

--_000_3D0B36618A8F4BB2A8EF25007BEAF66Cnominumcom_-- From alexandru.petrescu@gmail.com Tue Sep 13 10:24: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 3302711E808E for ; Tue, 13 Sep 2011 10:24:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.418 X-Spam-Level: X-Spam-Status: No, score=-2.418 tagged_above=-999 required=5 tests=[AWL=-0.169, BAYES_00=-2.599, HELO_EQ_FR=0.35] 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 q0rGyYMqZUia for ; Tue, 13 Sep 2011 10:24:23 -0700 (PDT) Received: from oxalide-out.extra.cea.fr (oxalide-out.extra.cea.fr [132.168.224.8]) by ietfa.amsl.com (Postfix) with ESMTP id 1892611E808D for ; Tue, 13 Sep 2011 10:24:22 -0700 (PDT) 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 p8DHQSq2005319 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Tue, 13 Sep 2011 19:26:28 +0200 Received: from muguet1.intra.cea.fr (muguet1.intra.cea.fr [132.166.192.6]) by pisaure.intra.cea.fr (8.14.4/8.14.4) with ESMTP id p8DHQSQr003570; Tue, 13 Sep 2011 19:26:28 +0200 (envelope-from alexandru.petrescu@gmail.com) Received: from [127.0.0.1] ([132.166.133.183]) by muguet1.intra.cea.fr (8.13.8/8.13.8/CEAnet-Intranet-out-1.1) with ESMTP id p8DHQNsO006108; Tue, 13 Sep 2011 19:26:28 +0200 Message-ID: <4E6F923F.7090304@gmail.com> Date: Tue, 13 Sep 2011 19:26:23 +0200 From: Alexandru Petrescu User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:6.0.2) Gecko/20110902 Thunderbird/6.0.2 MIME-Version: 1.0 To: Ted Lemon References: <3CF88B99A9ED504197498BC6F6F04B81040FBDA9@XMB-BGL-41E.cisco.com> <4E6E7A72.9030208@gmail.com> <4E6EAFC2.5060906@gmail.com> <4E6EDEA8.3080108@gmail.com> <4E6F825C.3080303@gmail.com> <3D0B3661-8A8F-4BB2-A8EF-25007BEAF66C@nominum.com> In-Reply-To: <3D0B3661-8A8F-4BB2-A8EF-25007BEAF66C@nominum.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Cc: "" Subject: Re: [mif] Comments on draft-mouton-mif-dhcpv6-drlo-00 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, 13 Sep 2011 17:24:24 -0000 Le 13/09/2011 18:58, Ted Lemon a 閏rit : > On Sep 13, 2011, at 12:18 PM, Alexandru Petrescu wrote: >> It is good that lifetime of ND and of DHCP are coherent when used >> on default route. > > Could you restate your point more explicitly? I find that I could > interpret your response to mean either that you think that the major > extension to DHCP is required, or that it is not. Allow me explain myself. I am not sure what is meant by a major extension to DHCP. Generally speaking I oppose major rehauling of such vast software as DHCP benefitting such huge installed base. But I do believe a different option type is needed to communicate the default route (different than the option type used in general for route option for DHCP). In the particular case of default route being communicated by DHCP (not generally any routes communicated by DHCP) I believe that DHCP should use a lifetime for default route in a way that is coherent with how ND communicates that default route. The lifetime fields that DHCP typically communicates are of different length than the lifetime field used by ND about default router (32bit vs 16bit if I am not mistaken). If that implies a major rehaul to DHCP implementation of timing in general then I would oppose suggesting such a change. If that implies that DHCP implementation does not change its way of managing its 32bit timing for usual DHCP matters, but just stores 16bit Default Route lifetime values in a conf file, and communicates these fields to Client in a DHCP Message, then I would agree with it. If that implies that ND should be modified such at the expiration of the Default Router lifetime it fires a RS _and_ (optionally) a DHCP Request ORO 64 asking anew the Default Router, then I would not oppose it either. Does this explanation add to clarity of my initially short phrase? Alex From maximilien.mouton@gmail.com Tue Sep 13 10:46: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 74EF321F8B83 for ; Tue, 13 Sep 2011 10:46:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CLTmL11Xtlb6 for ; Tue, 13 Sep 2011 10:46:29 -0700 (PDT) Received: from mail-fx0-f44.google.com (mail-fx0-f44.google.com [209.85.161.44]) by ietfa.amsl.com (Postfix) with ESMTP id 9826A21F8B1F for ; Tue, 13 Sep 2011 10:46:29 -0700 (PDT) Received: by fxd18 with SMTP id 18so875183fxd.31 for ; Tue, 13 Sep 2011 10:48:35 -0700 (PDT) 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:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; bh=ppelzVEd22jrg5Kx0TBDq8dSdiVKxfGVN2NNHUmeyu4=; b=IUTCPCu0ls/eOgwXmwAKY47V7gD43gD7iZ6BAje4/9nfxN0MblkKpTdureqF6Sl/jp 1OHF+JKRmphjgGTXVc9fxdD8vX/W7PEHaL6BUqn5kPVbrTQH7LGDDeLU1E/dD91yKw2g iHfk7C0tqTRZuiJ0qSCyMXNYW3y8iwfHExkrM= Received: by 10.223.57.12 with SMTP id a12mr461159fah.97.1315936115798; Tue, 13 Sep 2011 10:48:35 -0700 (PDT) Received: from [127.0.0.1] (scy57-1-88-169-184-224.fbx.proxad.net. [88.169.184.224]) by mx.google.com with ESMTPS id u6sm1014629faf.3.2011.09.13.10.48.34 (version=SSLv3 cipher=OTHER); Tue, 13 Sep 2011 10:48:35 -0700 (PDT) Message-ID: <4E6F9762.5000400@gmail.com> Date: Tue, 13 Sep 2011 19:48:18 +0200 From: maximilien mouton User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:6.0.2) Gecko/20110902 Thunderbird/6.0.2 MIME-Version: 1.0 To: Ted Lemon References: <3CF88B99A9ED504197498BC6F6F04B81040FBDA9@XMB-BGL-41E.cisco.com> <4E6E7A72.9030208@gmail.com> <4E6EAFC2.5060906@gmail.com> <4E6EDEA8.3080108@gmail.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Cc: "" Subject: Re: [mif] Comments on draft-mouton-mif-dhcpv6-drlo-00 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, 13 Sep 2011 17:46:30 -0000 Hi Ted, Le 13/09/2011 15:01, Ted Lemon a 閏rit : > On Sep 13, 2011, at 12:40 AM, maximilien mouton wrote: In this case > an Information-Request when client's lifetime expires (or is close > to) is sufficient especially if lifetime's upper limit is higher. > > One thing to be crystal clear about is that even if an option is > added that contains a lifetime, it would be a major extension of the > DHCP protocol to propose that the client include that lifetime in > its calculations for when to renew. Even if I grant It would imply big changes in DHCP, I think it would be interesting for DHCP to imitate ND dynamic behavior because in this draft we are trying to challenge ND by allowing DHCP to provide an entire IP/Internet configuration by its own. Best regards, Maximilien > Adding an option is a minor extension. I would oppose a major > extension for this purpose; I don't know how the working group as a > whole would feel about it, but I suspect there would be a great deal > of skepticism. > > The way lifetimes of configuration information are handled is either > with the IRT, in the case of stateless DHCPv6, or with the lease > renewal timer, in the case of stateful. So if you put a lifetime in > a route option, I don't see what good it would do. > > From Ted.Lemon@nominum.com Tue Sep 13 10:53: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 8C34A21F8CD3 for ; Tue, 13 Sep 2011 10:53:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.593 X-Spam-Level: X-Spam-Status: No, score=-106.593 tagged_above=-999 required=5 tests=[AWL=0.005, 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 miY6SHPwbwCo for ; Tue, 13 Sep 2011 10:53:35 -0700 (PDT) Received: from exprod7og124.obsmtp.com (exprod7og124.obsmtp.com [64.18.2.26]) by ietfa.amsl.com (Postfix) with ESMTP id D2DBB21F8CCA for ; Tue, 13 Sep 2011 10:53:34 -0700 (PDT) Received: from shell-too.nominum.com ([64.89.228.229]) (using TLSv1) by exprod7ob124.postini.com ([64.18.6.12]) with SMTP ID DSNKTm+ZHN0DFsF4TLl99dGoRx4XsG9ky5Sm@postini.com; Tue, 13 Sep 2011 10:55:41 PDT Received: from archivist.nominum.com (archivist.nominum.com [64.89.228.108]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "*.nominum.com", Issuer "Go Daddy Secure Certification Authority" (verified OK)) by shell-too.nominum.com (Postfix) with ESMTP id A0E6710801F for ; Tue, 13 Sep 2011 10:55:40 -0700 (PDT) Received: from webmail.nominum.com (cas-02.win.nominum.com [64.89.228.132]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (Client CN "mail.nominum.com", Issuer "Go Daddy Secure Certification Authority" (verified OK)) by archivist.nominum.com (Postfix) with ESMTPS id 93D3C190061; Tue, 13 Sep 2011 10:55:40 -0700 (PDT) (envelope-from Ted.Lemon@nominum.com) Received: from MBX-01.WIN.NOMINUM.COM ([64.89.228.133]) by CAS-02.WIN.NOMINUM.COM ([64.89.228.132]) with mapi id 14.01.0289.001; Tue, 13 Sep 2011 10:55:40 -0700 From: Ted Lemon To: Alexandru Petrescu Thread-Topic: [mif] Comments on draft-mouton-mif-dhcpv6-drlo-00 Thread-Index: AcxxClosDL9zuhm1Q+CTqXShqzwWxAAw84cAAAfxtgAABv0IAAARg+mAAAbg3wAAAWjoAAAA9R+AAAEFqoA= Date: Tue, 13 Sep 2011 17:55:39 +0000 Message-ID: <7061CEB8-8084-41D5-B31E-9F8E3B6C7091@nominum.com> References: <3CF88B99A9ED504197498BC6F6F04B81040FBDA9@XMB-BGL-41E.cisco.com> <4E6E7A72.9030208@gmail.com> <4E6EAFC2.5060906@gmail.com> <4E6EDEA8.3080108@gmail.com> <4E6F825C.3080303@gmail.com> <3D0B3661-8A8F-4BB2-A8EF-25007BEAF66C@nominum.com> <4E6F923F.7090304@gmail.com> In-Reply-To: <4E6F923F.7090304@gmail.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [173.162.214.218] Content-Type: multipart/alternative; boundary="_000_7061CEB8808441D5B31E9F8E3B6C7091nominumcom_" MIME-Version: 1.0 Cc: "" Subject: Re: [mif] Comments on draft-mouton-mif-dhcpv6-drlo-00 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, 13 Sep 2011 17:53:35 -0000 --_000_7061CEB8808441D5B31E9F8E3B6C7091nominumcom_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable On Sep 13, 2011, at 1:26 PM, Alexandru Petrescu wrote: Does this explanation add to clarity of my initially short phrase? I think so, yes. I think it's fine to have an option in the config file t= hat specifies a default route, or routes in general. Putting a lifetime o= n that, I think, is impractical. If the administrator wants a short lifet= ime on these routes, they should be setting a short lifetime on the address= es offered by the DHCP server, so that renewals come often enough to meet t= his need. --_000_7061CEB8808441D5B31E9F8E3B6C7091nominumcom_ Content-Type: text/html; charset="iso-8859-1" Content-ID: Content-Transfer-Encoding: quoted-printable
On Sep 13, 2011, at 1:26 PM, Alexandru Petrescu wrote:
Does this explanation add to clarity of my initially short phrase?

I think so, yes.   I think it's fine to have an option in the con= fig file that specifies a default route, or routes in general.   Putti= ng a lifetime on that, I think, is impractical.   If the administrator= wants a short lifetime on these routes, they should be setting a short lifetime on the addresses offered by the DHCP server, s= o that renewals come often enough to meet this need.

--_000_7061CEB8808441D5B31E9F8E3B6C7091nominumcom_-- From Ted.Lemon@nominum.com Tue Sep 13 10:54: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 A4AB721F8CD9 for ; Tue, 13 Sep 2011 10:54:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.594 X-Spam-Level: X-Spam-Status: No, score=-106.594 tagged_above=-999 required=5 tests=[AWL=0.005, 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 tRJl+KGJFAaI for ; Tue, 13 Sep 2011 10:54:27 -0700 (PDT) Received: from exprod7og120.obsmtp.com (exprod7og120.obsmtp.com [64.18.2.18]) by ietfa.amsl.com (Postfix) with ESMTP id D570A21F8CD8 for ; Tue, 13 Sep 2011 10:54:26 -0700 (PDT) Received: from shell-too.nominum.com ([64.89.228.229]) (using TLSv1) by exprod7ob120.postini.com ([64.18.6.12]) with SMTP ID DSNKTm+ZUHdDz7uCo0w2V/HjWP8502uy/GMR@postini.com; Tue, 13 Sep 2011 10:56:33 PDT Received: from archivist.nominum.com (archivist.nominum.com [64.89.228.108]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "*.nominum.com", Issuer "Go Daddy Secure Certification Authority" (verified OK)) by shell-too.nominum.com (Postfix) with ESMTP id 4C0E6F8023 for ; Tue, 13 Sep 2011 10:56:32 -0700 (PDT) Received: from webmail.nominum.com (cas-02.win.nominum.com [64.89.228.132]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (Client CN "mail.nominum.com", Issuer "Go Daddy Secure Certification Authority" (verified OK)) by archivist.nominum.com (Postfix) with ESMTPS id 44660190061; Tue, 13 Sep 2011 10:56:32 -0700 (PDT) (envelope-from Ted.Lemon@nominum.com) Received: from MBX-01.WIN.NOMINUM.COM ([64.89.228.133]) by CAS-02.WIN.NOMINUM.COM ([64.89.228.132]) with mapi id 14.01.0289.001; Tue, 13 Sep 2011 10:56:32 -0700 From: Ted Lemon To: Maximilien MOUTON Thread-Topic: [mif] Comments on draft-mouton-mif-dhcpv6-drlo-00 Thread-Index: AcxxClosDL9zuhm1Q+CTqXShqzwWxAAw84cAAAfxtgAABv0IAAARg+mAAAngboAAAGu8AA== Date: Tue, 13 Sep 2011 17:56:30 +0000 Message-ID: References: <3CF88B99A9ED504197498BC6F6F04B81040FBDA9@XMB-BGL-41E.cisco.com> <4E6E7A72.9030208@gmail.com> <4E6EAFC2.5060906@gmail.com> <4E6EDEA8.3080108@gmail.com> <4E6F967B.5030909@gmail.com> In-Reply-To: <4E6F967B.5030909@gmail.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [173.162.214.218] Content-Type: multipart/alternative; boundary="_000_F7334D5F6C4D4B609F30A0A9C729DE29nominumcom_" MIME-Version: 1.0 Cc: "" Subject: Re: [mif] Comments on draft-mouton-mif-dhcpv6-drlo-00 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, 13 Sep 2011 17:54:27 -0000 --_000_F7334D5F6C4D4B609F30A0A9C729DE29nominumcom_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable On Sep 13, 2011, at 1:44 PM, Maximilien MOUTON wrote: Even if I grant It would imply big changes in DHCP, I think it would be interesting for DHCP to imitate ND dynamic behavior because in this draft we are trying to challenge ND by allowing DHCP to provide an entire IP/Internet configuration by its own. We never had a TTL on the route offered in DHCPv4. Why is DHCPv6 differen= t? --_000_F7334D5F6C4D4B609F30A0A9C729DE29nominumcom_ Content-Type: text/html; charset="iso-8859-1" Content-ID: Content-Transfer-Encoding: quoted-printable
On Sep 13, 2011, at 1:44 PM, Maximilien MOUTON wrote:
Even if I grant It would imply big changes in DHCP, I think it would be
interesting for DHCP to imitate ND dynamic behavior because in this
draft we are trying to challenge ND by allowing DHCP to provide an
entire IP/Internet configuration by its own.

We never had a TTL on the route offered in DHCPv4.   Why is DHCPv= 6 different?

--_000_F7334D5F6C4D4B609F30A0A9C729DE29nominumcom_-- From alexandru.petrescu@gmail.com Tue Sep 13 11:04: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 8B0A711E80B3 for ; Tue, 13 Sep 2011 11:04:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.112 X-Spam-Level: X-Spam-Status: No, score=-2.112 tagged_above=-999 required=5 tests=[AWL=-0.463, BAYES_00=-2.599, HELO_EQ_FR=0.35, J_CHICKENPOX_42=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 hr95mL2+YBhj for ; Tue, 13 Sep 2011 11:04:08 -0700 (PDT) Received: from sainfoin-out.extra.cea.fr (sainfoin-out.extra.cea.fr [132.167.192.144]) by ietfa.amsl.com (Postfix) with ESMTP id D026E11E808E for ; Tue, 13 Sep 2011 11:04:07 -0700 (PDT) Received: from pisaure.intra.cea.fr (pisaure.intra.cea.fr [132.166.88.21]) by sainfoin.extra.cea.fr (8.14.2/8.14.2/CEAnet-Internet-out-2.2) with ESMTP id p8DI6D7d022470 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Tue, 13 Sep 2011 20:06:13 +0200 Received: from muguet2.intra.cea.fr (muguet2.intra.cea.fr [132.166.192.7]) by pisaure.intra.cea.fr (8.14.4/8.14.4) with ESMTP id p8DI6CGJ008879; Tue, 13 Sep 2011 20:06:12 +0200 (envelope-from alexandru.petrescu@gmail.com) Received: from [127.0.0.1] ([132.166.133.183]) by muguet2.intra.cea.fr (8.13.8/8.13.8/CEAnet-Intranet-out-1.1) with ESMTP id p8DI69qS024966; Tue, 13 Sep 2011 20:06:12 +0200 Message-ID: <4E6F9B91.7010503@gmail.com> Date: Tue, 13 Sep 2011 20:06:09 +0200 From: Alexandru Petrescu User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:6.0.2) Gecko/20110902 Thunderbird/6.0.2 MIME-Version: 1.0 To: Ted Lemon References: <3CF88B99A9ED504197498BC6F6F04B81040FBDA9@XMB-BGL-41E.cisco.com> <4E6E7A72.9030208@gmail.com> <4E6EAFC2.5060906@gmail.com> <4E6EDEA8.3080108@gmail.com> <4E6F825C.3080303@gmail.com> <3D0B3661-8A8F-4BB2-A8EF-25007BEAF66C@nominum.com> <4E6F923F.7090304@gmail.com> <7061CEB8-8084-41D5-B31E-9F8E3B6C7091@nominum.com> In-Reply-To: <7061CEB8-8084-41D5-B31E-9F8E3B6C7091@nominum.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Cc: "" Subject: Re: [mif] Comments on draft-mouton-mif-dhcpv6-drlo-00 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, 13 Sep 2011 18:04:08 -0000 Le 13/09/2011 19:55, Ted Lemon a 閏rit : > On Sep 13, 2011, at 1:26 PM, Alexandru Petrescu wrote: >> Does this explanation add to clarity of my initially short phrase? > > I think so, yes. I think it's fine to have an option in the config > file that specifies a default route, or routes in general. Putting a > lifetime on that, I think, is impractical. I can see the impracticality aspect reflected in the difference 16bit-vs-32bit ND-DHCP. But when a Client receives a DHCP Advertise with fields about a default router then it should copy these fields into local existing data structures. These data structures about the default route are what ND maintains, and that includes a lifetime field. A Client could ignore that lifetime field of the ND data structure, and consider that entry permanent forever. Or it could try to manage the time of life of that default router entry in a coherent manner DHCP+ND, which implies deciding, among other things, what to do when lifetime expires. If the expiration of the DHCP lifetime implies triggering _only_ DHCP messaging that would be less advantageous. > If the administrator wants a short lifetime on these routes, they > should be setting a short lifetime on the addresses offered by the > DHCP server, so that renewals come often enough to meet this need. I find it to be a stretch to link the lifetime of addresses to lifetime of routes in the routing table. It is possible that a Client does not have any address assigned by DHCP, but needs a default router assigned by DHCP. E.g. when using link-local addresses (self formed) and be part of some global multicast group. Alex From Ted.Lemon@nominum.com Tue Sep 13 11:20: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 7D8D321F8C60 for ; Tue, 13 Sep 2011 11:20:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.594 X-Spam-Level: X-Spam-Status: No, score=-106.594 tagged_above=-999 required=5 tests=[AWL=0.004, 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 G1J3aykJmvLM for ; Tue, 13 Sep 2011 11:20:43 -0700 (PDT) Received: from exprod7og123.obsmtp.com (exprod7og123.obsmtp.com [64.18.2.24]) by ietfa.amsl.com (Postfix) with ESMTP id 2F31011E8095 for ; Tue, 13 Sep 2011 11:20:41 -0700 (PDT) Received: from shell-too.nominum.com ([64.89.228.229]) (using TLSv1) by exprod7ob123.postini.com ([64.18.6.12]) with SMTP ID DSNKTm+fc0luajaUFG+3E6h4V9F7etgrTvmq@postini.com; Tue, 13 Sep 2011 11:22:49 PDT Received: from archivist.nominum.com (archivist.nominum.com [64.89.228.108]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "*.nominum.com", Issuer "Go Daddy Secure Certification Authority" (verified OK)) by shell-too.nominum.com (Postfix) with ESMTP id B311110801F for ; Tue, 13 Sep 2011 11:22:43 -0700 (PDT) Received: from webmail.nominum.com (cas-02.win.nominum.com [64.89.228.132]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (Client CN "mail.nominum.com", Issuer "Go Daddy Secure Certification Authority" (verified OK)) by archivist.nominum.com (Postfix) with ESMTPS id 5BE49190061; Tue, 13 Sep 2011 11:22:42 -0700 (PDT) (envelope-from Ted.Lemon@nominum.com) Received: from MBX-01.WIN.NOMINUM.COM ([64.89.228.133]) by CAS-02.WIN.NOMINUM.COM ([64.89.228.132]) with mapi id 14.01.0289.001; Tue, 13 Sep 2011 11:22:41 -0700 From: Ted Lemon To: Alexandru Petrescu Thread-Topic: [mif] Comments on draft-mouton-mif-dhcpv6-drlo-00 Thread-Index: AcxxClosDL9zuhm1Q+CTqXShqzwWxAAw84cAAAfxtgAABv0IAAARg+mAAAbg3wAAAWjoAAAA9R+AAAEFqoAAAF3hgAAAk6wA Date: Tue, 13 Sep 2011 18:22:41 +0000 Message-ID: References: <3CF88B99A9ED504197498BC6F6F04B81040FBDA9@XMB-BGL-41E.cisco.com> <4E6E7A72.9030208@gmail.com> <4E6EAFC2.5060906@gmail.com> <4E6EDEA8.3080108@gmail.com> <4E6F825C.3080303@gmail.com> <3D0B3661-8A8F-4BB2-A8EF-25007BEAF66C@nominum.com> <4E6F923F.7090304@gmail.com> <7061CEB8-8084-41D5-B31E-9F8E3B6C7091@nominum.com> <4E6F9B91.7010503@gmail.com> In-Reply-To: <4E6F9B91.7010503@gmail.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [173.162.214.218] Content-Type: multipart/alternative; boundary="_000_B987CA14569C428C8D8AC97A0E42EF48nominumcom_" MIME-Version: 1.0 Cc: "" Subject: Re: [mif] Comments on draft-mouton-mif-dhcpv6-drlo-00 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, 13 Sep 2011 18:20:43 -0000 --_000_B987CA14569C428C8D8AC97A0E42EF48nominumcom_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable On Sep 13, 2011, at 2:06 PM, Alexandru Petrescu wrote: I find it to be a stretch to link the lifetime of addresses to lifetime of routes in the routing table. Could you please clearly articulate a use case where this option is necessa= ry, and the existing proposed option is not adequate? Please do not menti= on operating system data structures. Please do not say "I find it to be t= he case that.." Without a use case, I just don't see the point in discuss= ing this further. --_000_B987CA14569C428C8D8AC97A0E42EF48nominumcom_ Content-Type: text/html; charset="iso-8859-1" Content-ID: Content-Transfer-Encoding: quoted-printable
On Sep 13, 2011, at 2:06 PM, Alexandru Petrescu wrote:
I find it to be a stretch to link the lifetime of addresses to lifetime
of routes in the routing table.

Could you please clearly articulate a use case where this option is ne= cessary, and the existing proposed option is not adequate?   Please do= not mention operating system data structures.   Please do not say &qu= ot;I find it to be the case that.."   Without a use case, I just don't see the point in discussing this further.

--_000_B987CA14569C428C8D8AC97A0E42EF48nominumcom_-- From simon.perreault@viagenie.ca Tue Sep 13 11:24: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 0243411E80A2 for ; Tue, 13 Sep 2011 11:24:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.591 X-Spam-Level: X-Spam-Status: No, score=-2.591 tagged_above=-999 required=5 tests=[AWL=0.008, 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 jzQ3z5YHDCPP for ; Tue, 13 Sep 2011 11:24:27 -0700 (PDT) Received: from jazz.viagenie.ca (unknown [IPv6:2620:0:230:8000:226:55ff:fe57:14db]) by ietfa.amsl.com (Postfix) with ESMTP id 5F15711E808E for ; Tue, 13 Sep 2011 11:24:27 -0700 (PDT) Received: from banana.viagenie.ca (nomis80.org [97.107.136.111]) by jazz.viagenie.ca (Postfix) with ESMTPSA id 5593E21107 for ; Tue, 13 Sep 2011 14:26:33 -0400 (EDT) Message-ID: <4E6FA049.1040309@viagenie.ca> Date: Tue, 13 Sep 2011 14:26:17 -0400 From: Simon Perreault User-Agent: Mozilla/5.0 (X11; Linux i686; rv:5.0) Gecko/20110707 Thunderbird/5.0 MIME-Version: 1.0 To: mif@ietf.org References: <3CF88B99A9ED504197498BC6F6F04B81040FBDA9@XMB-BGL-41E.cisco.com> <4E6E7A72.9030208@gmail.com> <4E6EAFC2.5060906@gmail.com> <4E6EDEA8.3080108@gmail.com> <4E6F825C.3080303@gmail.com> <3D0B3661-8A8F-4BB2-A8EF-25007BEAF66C@nominum.com> <4E6F923F.7090304@gmail.com> <7061CEB8-8084-41D5-B31E-9F8E3B6C7091@nominum.com> <4E6F9B91.7010503@gmail.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: Re: [mif] Comments on draft-mouton-mif-dhcpv6-drlo-00 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, 13 Sep 2011 18:24:28 -0000 Ted Lemon wrote, on 09/13/2011 02:22 PM: > Could you please clearly articulate a use case where this option is necessary, > and the existing proposed option is not adequate? Please do not mention > operating system data structures. Please do not say "I find it to be the case > that.." Without a use case, I just don't see the point in discussing this further. +1 Simon -- DTN made easy, lean, and smart --> http://postellation.viagenie.ca NAT64/DNS64 open-source --> http://ecdysis.viagenie.ca STUN/TURN server --> http://numb.viagenie.ca From alexandru.petrescu@gmail.com Tue Sep 13 11:28: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 898D911E808E for ; Tue, 13 Sep 2011 11:28:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.398 X-Spam-Level: X-Spam-Status: No, score=-2.398 tagged_above=-999 required=5 tests=[AWL=-0.149, BAYES_00=-2.599, HELO_EQ_FR=0.35] 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 CodYcJ8JPIfN for ; Tue, 13 Sep 2011 11:28:49 -0700 (PDT) Received: from oxalide-out.extra.cea.fr (oxalide-out.extra.cea.fr [132.168.224.8]) by ietfa.amsl.com (Postfix) with ESMTP id 1722011E80A2 for ; Tue, 13 Sep 2011 11:28:39 -0700 (PDT) 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 p8DIUjYh016933 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT) for ; Tue, 13 Sep 2011 20:30:45 +0200 Received: from muguet1.intra.cea.fr (muguet1.intra.cea.fr [132.166.192.6]) by pisaure.intra.cea.fr (8.14.4/8.14.4) with ESMTP id p8DIUjWi011919 for ; Tue, 13 Sep 2011 20:30:45 +0200 (envelope-from alexandru.petrescu@gmail.com) Received: from [127.0.0.1] ([132.166.133.183]) by muguet1.intra.cea.fr (8.13.8/8.13.8/CEAnet-Intranet-out-1.1) with ESMTP id p8DIUfF9020649 for ; Tue, 13 Sep 2011 20:30:45 +0200 Message-ID: <4E6FA151.7000906@gmail.com> Date: Tue, 13 Sep 2011 20:30:41 +0200 From: Alexandru Petrescu User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:6.0.2) Gecko/20110902 Thunderbird/6.0.2 MIME-Version: 1.0 To: mif@ietf.org References: <3CF88B99A9ED504197498BC6F6F04B81040FBDA9@XMB-BGL-41E.cisco.com> <4E6E7A72.9030208@gmail.com> <4E6EAFC2.5060906@gmail.com> <4E6EDEA8.3080108@gmail.com> <4E6F967B.5030909@gmail.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Subject: Re: [mif] Comments on draft-mouton-mif-dhcpv6-drlo-00 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, 13 Sep 2011 18:28:49 -0000 Le 13/09/2011 19:56, Ted Lemon a 閏rit : > On Sep 13, 2011, at 1:44 PM, Maximilien MOUTON wrote: >> Even if I grant It would imply big changes in DHCP, I think it >> would be interesting for DHCP to imitate ND dynamic behavior >> because in this draft we are trying to challenge ND by allowing >> DHCP to provide an entire IP/Internet configuration by its own. > > We never had a TTL on the route offered in DHCPv4. Why is DHCPv6 > different? Did DHCPv4 already offer routes? Is there a document thanks? This is quite an interesting question, and at first it may confuse. I suppose you mean "Time To Live", as it could be the lifetime of a route (and not as the TTL field of IPv4 datagrams which is an integer of hops, as hopcount, despite its "Time" in "TTL"). In this sense, indeed, the question can be raised why a route communicated with DHCP should have a lifetime associated with it. And answers exist. In another sense, in IPv6 the TTL of IP datagrams (the hopcount, not the time value) is "Hop Limit". ND's RA does communicate a suggested Hop Limit value for end hosts to configure on their local data structures. E.g. RFC4861 uses a "Cur Hop Limit" value in an RA. We have debated locally about proposing that "Cur Hop Limit" in DHCP as well, alternatively to it being communicated by DHCP. (sorry for dissecting the TTL question). Alex > > > > _______________________________________________ mif mailing list > mif@ietf.org https://www.ietf.org/mailman/listinfo/mif From alexandru.petrescu@gmail.com Tue Sep 13 11:49: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 73EAD21F8A35 for ; Tue, 13 Sep 2011 11:49:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.393 X-Spam-Level: X-Spam-Status: No, score=-2.393 tagged_above=-999 required=5 tests=[AWL=-0.144, BAYES_00=-2.599, HELO_EQ_FR=0.35] 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 69Lh1eUMSREN for ; Tue, 13 Sep 2011 11:49:57 -0700 (PDT) Received: from sainfoin-out.extra.cea.fr (sainfoin-out.extra.cea.fr [132.167.192.144]) by ietfa.amsl.com (Postfix) with ESMTP id BAC1F21F87D9 for ; Tue, 13 Sep 2011 11:49:56 -0700 (PDT) Received: from pisaure.intra.cea.fr (pisaure.intra.cea.fr [132.166.88.21]) by sainfoin.extra.cea.fr (8.14.2/8.14.2/CEAnet-Internet-out-2.2) with ESMTP id p8DIq2wg031706 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Tue, 13 Sep 2011 20:52:02 +0200 Received: from muguet2.intra.cea.fr (muguet2.intra.cea.fr [132.166.192.7]) by pisaure.intra.cea.fr (8.14.4/8.14.4) with ESMTP id p8DIq1ML015273; Tue, 13 Sep 2011 20:52:02 +0200 (envelope-from alexandru.petrescu@gmail.com) Received: from [127.0.0.1] ([132.166.133.183]) by muguet2.intra.cea.fr (8.13.8/8.13.8/CEAnet-Intranet-out-1.1) with ESMTP id p8DIpwA6002252; Tue, 13 Sep 2011 20:52:01 +0200 Message-ID: <4E6FA64E.7020801@gmail.com> Date: Tue, 13 Sep 2011 20:51:58 +0200 From: Alexandru Petrescu User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:6.0.2) Gecko/20110902 Thunderbird/6.0.2 MIME-Version: 1.0 To: Ted Lemon References: <3CF88B99A9ED504197498BC6F6F04B81040FBDA9@XMB-BGL-41E.cisco.com> <4E6E7A72.9030208@gmail.com> <4E6EAFC2.5060906@gmail.com> <4E6EDEA8.3080108@gmail.com> <4E6F825C.3080303@gmail.com> <3D0B3661-8A8F-4BB2-A8EF-25007BEAF66C@nominum.com> <4E6F923F.7090304@gmail.com> <7061CEB8-8084-41D5-B31E-9F8E3B6C7091@nominum.com> <4E6F9B91.7010503@gmail.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Cc: "" Subject: Re: [mif] Comments on draft-mouton-mif-dhcpv6-drlo-00 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, 13 Sep 2011 18:49:57 -0000 Le 13/09/2011 20:22, Ted Lemon a 閏rit : > On Sep 13, 2011, at 2:06 PM, Alexandru Petrescu wrote: >> I find it to be a stretch to link the lifetime of addresses to >> lifetime of routes in the routing table. > > Could you please clearly articulate a use case where this option is > necessary, and the existing proposed option is not adequate? Please > do not mention operating system data structures. Please do not say > "I find it to be the case that.." Without a use case, I just don't > see the point in discussing this further. What do you mean by "use case" so I can better detail how this default route option is necessary, thanks. The existing proposed option does not accommodate several use-cases. One particular case is a 3G+ operator using terminals whose default routes are under the form "0.0.0.0 0.0.0.0 hso0" remark no address for next hop, but an interface name (existing option does not communicate interface names). 3G is mentioned as a use case in draft-ietf-mif-dhcpv6-route-option-03 yet I believe 3G+ is not covered. Can I thus suggest that existing option is not adequate? With respect to lifetimes: if you do not agree discussing lifetimes now then you may agree discussing lifetimes when implementation feedback of existing option is out. I suppose there is currently no implementation of the existing option, whereas implementation of draft-mouton-mif-dhcpv6-drlo-00 does exist, as reflected in http://www.ietf.org/mail-archive/web/mif/current/msg01166.html Alex From Ted.Lemon@nominum.com Tue Sep 13 12:13: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 2BD5621F8B76 for ; Tue, 13 Sep 2011 12:13:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.594 X-Spam-Level: X-Spam-Status: No, score=-106.594 tagged_above=-999 required=5 tests=[AWL=0.004, 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 GQfLnPR2Ti-S for ; Tue, 13 Sep 2011 12:13:55 -0700 (PDT) Received: from exprod7og117.obsmtp.com (exprod7og117.obsmtp.com [64.18.2.6]) by ietfa.amsl.com (Postfix) with ESMTP id 20CCD21F8B64 for ; Tue, 13 Sep 2011 12:13:55 -0700 (PDT) Received: from shell-too.nominum.com ([64.89.228.229]) (using TLSv1) by exprod7ob117.postini.com ([64.18.6.12]) with SMTP ID DSNKTm+r8H9RLrfBaf/xIaPCfxDMNbmN/1R6@postini.com; Tue, 13 Sep 2011 12:16:02 PDT Received: from archivist.nominum.com (archivist.nominum.com [64.89.228.108]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "*.nominum.com", Issuer "Go Daddy Secure Certification Authority" (verified OK)) by shell-too.nominum.com (Postfix) with ESMTP id 89DEBF8020 for ; Tue, 13 Sep 2011 12:16:00 -0700 (PDT) Received: from webmail.nominum.com (cas-02.win.nominum.com [64.89.228.132]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (Client CN "mail.nominum.com", Issuer "Go Daddy Secure Certification Authority" (verified OK)) by archivist.nominum.com (Postfix) with ESMTPS id 0DFBF190061; Tue, 13 Sep 2011 12:15:57 -0700 (PDT) (envelope-from Ted.Lemon@nominum.com) Received: from MBX-01.WIN.NOMINUM.COM ([64.89.228.133]) by CAS-02.WIN.NOMINUM.COM ([64.89.228.132]) with mapi id 14.01.0289.001; Tue, 13 Sep 2011 12:15:56 -0700 From: Ted Lemon To: Alexandru Petrescu Thread-Topic: [mif] Comments on draft-mouton-mif-dhcpv6-drlo-00 Thread-Index: AcxxClosDL9zuhm1Q+CTqXShqzwWxAAw84cAAAfxtgAABv0IAAARg+mAAAbg3wAAAWjoAAAA9R+AAAEFqoAAAF3hgAAAk6wAAAEF9gAAANZHAA== Date: Tue, 13 Sep 2011 19:15:56 +0000 Message-ID: <82337D11-0A39-4A10-AA0E-1E81B09DBA4F@nominum.com> References: <3CF88B99A9ED504197498BC6F6F04B81040FBDA9@XMB-BGL-41E.cisco.com> <4E6E7A72.9030208@gmail.com> <4E6EAFC2.5060906@gmail.com> <4E6EDEA8.3080108@gmail.com> <4E6F825C.3080303@gmail.com> <3D0B3661-8A8F-4BB2-A8EF-25007BEAF66C@nominum.com> <4E6F923F.7090304@gmail.com> <7061CEB8-8084-41D5-B31E-9F8E3B6C7091@nominum.com> <4E6F9B91.7010503@gmail.com> <4E6FA64E.7020801@gmail.com> In-Reply-To: <4E6FA64E.7020801@gmail.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [173.162.214.218] Content-Type: multipart/alternative; boundary="_000_82337D110A394A10AA0E1E81B09DBA4Fnominumcom_" MIME-Version: 1.0 Cc: "" Subject: Re: [mif] Comments on draft-mouton-mif-dhcpv6-drlo-00 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, 13 Sep 2011 19:13:56 -0000 --_000_82337D110A394A10AA0E1E81B09DBA4Fnominumcom_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable On Sep 13, 2011, at 2:51 PM, Alexandru Petrescu wrote: With respect to lifetimes: if you do not agree discussing lifetimes now then you may agree discussing lifetimes when implementation feedback of existing option is out. I suppose there is currently no implementation of the existing option, whereas implementation of draft-mouton-mif-dhcpv6-drlo-00 does exist, as reflected in http://www.ietf.org/mail-archive/web/mif/current/msg01166.html How does the existing implementation handle renewal? What do you mean by "use case" so I can better detail how this default rout= e option is necessary, thanks. The 3G+ scenario is the first use case you've presented, so thanks for that= . If interface names are in fact required, that's interesting. I really don= 't understand how that could work, though, since the DHCP server has no way= to know what the client operating system is calling the interface. Also, I'm a bit confused by the idea of an interface route with no router a= ddress in IPv6. I will admit to being something of a tyro when it comes t= o these things, but I don't understand how that would work. Does the clie= nt simply multicast every packet? Is there an RFC or draft that documents= how this works? --_000_82337D110A394A10AA0E1E81B09DBA4Fnominumcom_ Content-Type: text/html; charset="iso-8859-1" Content-ID: <88D61F7CF8F8234DB59CFAD91BD75F10@nominum.com> Content-Transfer-Encoding: quoted-printable
On Sep 13, 2011, at 2:51 PM, Alexandru Petrescu wrote:
With respect to lifetimes: if you do not agree discussing lifetimes now
then you may agree discussing lifetimes when implementation feedback of
existing option is out.  I suppose there is currently no implementatio= n
of the existing option, whereas implementation of
draft-mouton-mif-dhcpv6-drlo-00 does exist, as reflected in
= http://www.ietf.org/mail-archive/web/mif/current/msg01166.html

How does the existing implementation handle renewal?

What do you mean by "use case" so I can= better detail how this default route option is necessary, thanks.

The 3G+ scenario is the first use case you've presented, so thanks= for that. 

If interface names are in fact required, that's interesting.   I = really don't understand how that could work, though, since the DHCP server = has no way to know what the client operating system is calling the interfac= e.

Also, I'm a bit confused by the idea of an interface route with no rou= ter address in IPv6.   I will admit to being something of a tyro when = it comes to these things, but I don't understand how that would work.  = ; Does the client simply multicast every packet?   Is there an RFC or draft that documents how this works?

--_000_82337D110A394A10AA0E1E81B09DBA4Fnominumcom_-- From simon.perreault@viagenie.ca Tue Sep 13 12:18:21 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 0E25A11E80BF for ; Tue, 13 Sep 2011 12:18:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.591 X-Spam-Level: X-Spam-Status: No, score=-2.591 tagged_above=-999 required=5 tests=[AWL=0.008, 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 ZnnOt28bfUD1 for ; Tue, 13 Sep 2011 12:18:20 -0700 (PDT) Received: from jazz.viagenie.ca (unknown [IPv6:2620:0:230:8000:226:55ff:fe57:14db]) by ietfa.amsl.com (Postfix) with ESMTP id 5C83611E80BB for ; Tue, 13 Sep 2011 12:18:20 -0700 (PDT) Received: from banana.viagenie.ca (nomis80.org [97.107.136.111]) by jazz.viagenie.ca (Postfix) with ESMTPSA id 5568121107 for ; Tue, 13 Sep 2011 15:20:24 -0400 (EDT) Message-ID: <4E6FACF6.5000007@viagenie.ca> Date: Tue, 13 Sep 2011 15:20:22 -0400 From: Simon Perreault User-Agent: Mozilla/5.0 (X11; Linux i686; rv:5.0) Gecko/20110707 Thunderbird/5.0 MIME-Version: 1.0 To: mif@ietf.org References: <3CF88B99A9ED504197498BC6F6F04B81040FBDA9@XMB-BGL-41E.cisco.com> <4E6E7A72.9030208@gmail.com> <4E6EAFC2.5060906@gmail.com> <4E6EDEA8.3080108@gmail.com> <4E6F825C.3080303@gmail.com> <3D0B3661-8A8F-4BB2-A8EF-25007BEAF66C@nominum.com> <4E6F923F.7090304@gmail.com> <7061CEB8-8084-41D5-B31E-9F8E3B6C7091@nominum.com> <4E6F9B91.7010503@gmail.com> <4E6FA64E.7020801@gmail.com> <82337D11-0A39-4A10-AA0E-1E81B09DBA4F@nominum.com> In-Reply-To: <82337D11-0A39-4A10-AA0E-1E81B09DBA4F@nominum.com> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: Re: [mif] Comments on draft-mouton-mif-dhcpv6-drlo-00 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, 13 Sep 2011 19:18:21 -0000 Ted Lemon wrote, on 09/13/2011 03:15 PM: > Also, I'm a bit confused by the idea of an interface route with no router > address in IPv6. I will admit to being something of a tyro when it comes to > these things, but I don't understand how that would work. Does the client > simply multicast every packet? Is there an RFC or draft that documents how > this works? I'm guessing that's a point-to-point interface. So you don't need the next hop's L2 address. You just send it down the tube and it gets at the other end. The classic example is PPP. Simon -- DTN made easy, lean, and smart --> http://postellation.viagenie.ca NAT64/DNS64 open-source --> http://ecdysis.viagenie.ca STUN/TURN server --> http://numb.viagenie.ca From Ted.Lemon@nominum.com Tue Sep 13 12:39: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 601EE21F8C41 for ; Tue, 13 Sep 2011 12:39:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.594 X-Spam-Level: X-Spam-Status: No, score=-106.594 tagged_above=-999 required=5 tests=[AWL=0.004, 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 73+TSS5pN0pT for ; Tue, 13 Sep 2011 12:38:59 -0700 (PDT) Received: from exprod7og117.obsmtp.com (exprod7og117.obsmtp.com [64.18.2.6]) by ietfa.amsl.com (Postfix) with ESMTP id C7B0B21F8C21 for ; Tue, 13 Sep 2011 12:38:58 -0700 (PDT) Received: from shell-too.nominum.com ([64.89.228.229]) (using TLSv1) by exprod7ob117.postini.com ([64.18.6.12]) with SMTP ID DSNKTm+x0Yr/OD6Rx6GRNpvn/fm+Ljx6P9ut@postini.com; Tue, 13 Sep 2011 12:41:06 PDT Received: from archivist.nominum.com (archivist.nominum.com [64.89.228.108]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "*.nominum.com", Issuer "Go Daddy Secure Certification Authority" (verified OK)) by shell-too.nominum.com (Postfix) with ESMTP id D9DF2F8023 for ; Tue, 13 Sep 2011 12:41:04 -0700 (PDT) Received: from webmail.nominum.com (cas-02.win.nominum.com [64.89.228.132]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (Client CN "mail.nominum.com", Issuer "Go Daddy Secure Certification Authority" (verified OK)) by archivist.nominum.com (Postfix) with ESMTPS id C22B8190061; Tue, 13 Sep 2011 12:41:03 -0700 (PDT) (envelope-from Ted.Lemon@nominum.com) Received: from MBX-01.WIN.NOMINUM.COM ([64.89.228.133]) by CAS-02.WIN.NOMINUM.COM ([64.89.228.132]) with mapi id 14.01.0289.001; Tue, 13 Sep 2011 12:41:03 -0700 From: Ted Lemon To: Simon Perreault Thread-Topic: [mif] Comments on draft-mouton-mif-dhcpv6-drlo-00 Thread-Index: AcxxClosDL9zuhm1Q+CTqXShqzwWxAAw84cAAAfxtgAABv0IAAARg+mAAAbg3wAAAWjoAAAA9R+AAAEFqoAAAF3hgAAAk6wAAAEF9gAAANZHAAAAJ6MAAAC4xwA= Date: Tue, 13 Sep 2011 19:41:03 +0000 Message-ID: <460A90E1-7A38-484E-BA55-62F080478DB3@nominum.com> References: <3CF88B99A9ED504197498BC6F6F04B81040FBDA9@XMB-BGL-41E.cisco.com> <4E6E7A72.9030208@gmail.com> <4E6EAFC2.5060906@gmail.com> <4E6EDEA8.3080108@gmail.com> <4E6F825C.3080303@gmail.com> <3D0B3661-8A8F-4BB2-A8EF-25007BEAF66C@nominum.com> <4E6F923F.7090304@gmail.com> <7061CEB8-8084-41D5-B31E-9F8E3B6C7091@nominum.com> <4E6F9B91.7010503@gmail.com> <4E6FA64E.7020801@gmail.com> <82337D11-0A39-4A10-AA0E-1E81B09DBA4F@nominum.com> <4E6FACF6.5000007@viagenie.ca> In-Reply-To: <4E6FACF6.5000007@viagenie.ca> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [173.162.214.218] Content-Type: multipart/alternative; boundary="_000_460A90E17A38484EBA5562F080478DB3nominumcom_" MIME-Version: 1.0 Cc: "" Subject: Re: [mif] Comments on draft-mouton-mif-dhcpv6-drlo-00 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, 13 Sep 2011 19:39:00 -0000 --_000_460A90E17A38484EBA5562F080478DB3nominumcom_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable On Sep 13, 2011, at 3:20 PM, Simon Perreault wrote: I'm guessing that's a point-to-point interface. So you don't need the next = hop's L2 address. You just send it down the tube and it gets at the other end. Th= e classic example is PPP. Okay, that sort of makes sense, but it seems like it's impossible for the D= HCP server to know what that interface is called, and easy to just have the= client set up the routing since it knows what it's doing. --_000_460A90E17A38484EBA5562F080478DB3nominumcom_ Content-Type: text/html; charset="us-ascii" Content-ID: <847A2E59CE1B5B41B4A1DA08D175E8B7@nominum.com> Content-Transfer-Encoding: quoted-printable
On Sep 13, 2011, at 3:20 PM, Simon Perreault wrote:
I'm guessing that's a point-to-point interface. So you don't need the next hop= 's
L2 address. You just send it down the tube and it gets at the other end. Th= e
classic example is PPP.

Okay, that sort of makes sense, but it seems like it's impossible for = the DHCP server to know what that interface is called, and easy to just hav= e the client set up the routing since it knows what it's doing.

--_000_460A90E17A38484EBA5562F080478DB3nominumcom_-- From internet-drafts@ietf.org Tue Sep 13 12:42: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 8422611E80E9; Tue, 13 Sep 2011 12:42:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.581 X-Spam-Level: X-Spam-Status: No, score=-102.581 tagged_above=-999 required=5 tests=[AWL=0.018, 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 bI5GqlLJyoD6; Tue, 13 Sep 2011 12:42:16 -0700 (PDT) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 210D211E80E5; Tue, 13 Sep 2011 12:42:16 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 3.60 Message-ID: <20110913194216.28946.30352.idtracker@ietfa.amsl.com> Date: Tue, 13 Sep 2011 12:42:16 -0700 Cc: mif@ietf.org Subject: [mif] I-D Action: draft-ietf-mif-dns-server-selection-04.txt X-BeenThere: mif@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multiple Interface Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 13 Sep 2011 19:42:16 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Multiple Interfaces Working Group of = the IETF. Title : Improved DNS Server Selection for Multi-Interfaced Nodes Author(s) : Teemu Savolainen Jun-ya Kato Ted Lemon Filename : draft-ietf-mif-dns-server-selection-04.txt Pages : 25 Date : 2011-09-13 A multi-interfaced node is connected to multiple networks, some of which may be utilizing private DNS namespaces. A node commonly receives DNS server configuration information from all connected networks. Some of the DNS servers may have information about namespaces other servers do not have. When a multi-interfaced node needs to utilize DNS, the node has to choose which of the servers to contact to. This document describes DHCPv4 and DHCPv6 option that can be used to configure nodes with information required to perform informed DNS server selection decisions. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-mif-dns-server-selection-04.= txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ This Internet-Draft can be retrieved at: ftp://ftp.ietf.org/internet-drafts/draft-ietf-mif-dns-server-selection-04.t= xt From simon.perreault@viagenie.ca Tue Sep 13 12:44: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 DD3D911E80E6 for ; Tue, 13 Sep 2011 12:44:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.592 X-Spam-Level: X-Spam-Status: No, score=-2.592 tagged_above=-999 required=5 tests=[AWL=0.007, 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 4d2WwwwW+mqU for ; Tue, 13 Sep 2011 12:44:07 -0700 (PDT) Received: from jazz.viagenie.ca (unknown [IPv6:2620:0:230:8000:226:55ff:fe57:14db]) by ietfa.amsl.com (Postfix) with ESMTP id D64DC11E80E5 for ; Tue, 13 Sep 2011 12:44:07 -0700 (PDT) Received: from banana.viagenie.ca (nomis80.org [97.107.136.111]) by jazz.viagenie.ca (Postfix) with ESMTPSA id CF83221107; Tue, 13 Sep 2011 15:46:13 -0400 (EDT) Message-ID: <4E6FB304.1060703@viagenie.ca> Date: Tue, 13 Sep 2011 15:46:12 -0400 From: Simon Perreault User-Agent: Mozilla/5.0 (X11; Linux i686; rv:5.0) Gecko/20110707 Thunderbird/5.0 MIME-Version: 1.0 To: Ted Lemon References: <3CF88B99A9ED504197498BC6F6F04B81040FBDA9@XMB-BGL-41E.cisco.com> <4E6E7A72.9030208@gmail.com> <4E6EAFC2.5060906@gmail.com> <4E6EDEA8.3080108@gmail.com> <4E6F825C.3080303@gmail.com> <3D0B3661-8A8F-4BB2-A8EF-25007BEAF66C@nominum.com> <4E6F923F.7090304@gmail.com> <7061CEB8-8084-41D5-B31E-9F8E3B6C7091@nominum.com> <4E6F9B91.7010503@gmail.com> <4E6FA64E.7020801@gmail.com> <82337D11-0A39-4A10-AA0E-1E81B09DBA4F@nominum.com> <4E6FACF6.5000007@viagenie.ca> <460A90E1-7A38-484E-BA55-62F080478DB3@nominum.com> In-Reply-To: <460A90E1-7A38-484E-BA55-62F080478DB3@nominum.com> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: "" Subject: Re: [mif] Comments on draft-mouton-mif-dhcpv6-drlo-00 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, 13 Sep 2011 19:44:09 -0000 Ted Lemon wrote, on 09/13/2011 03:41 PM: > On Sep 13, 2011, at 3:20 PM, Simon Perreault wrote: >> I'm guessing that's a point-to-point interface. So you don't need the next hop's >> L2 address. You just send it down the tube and it gets at the other end. The >> classic example is PPP. > > Okay, that sort of makes sense, but it seems like it's impossible for the DHCP > server to know what that interface is called, and easy to just have the client > set up the routing since it knows what it's doing. Agreed. In any case it's still possible to describe a P-t-P route using the remote endpoint's IP address instead of the interface name or index. So IMHO the 3G use case is supported by the current draft. Simon -- DTN made easy, lean, and smart --> http://postellation.viagenie.ca NAT64/DNS64 open-source --> http://ecdysis.viagenie.ca STUN/TURN server --> http://numb.viagenie.ca From teemu.savolainen@nokia.com Tue Sep 13 12:48: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 5AB6C11E80F5 for ; Tue, 13 Sep 2011 12:48:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.299 X-Spam-Level: X-Spam-Status: No, score=-3.299 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, J_CHICKENPOX_13=0.6, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hVQ6PtP2BQ8i for ; Tue, 13 Sep 2011 12:48:11 -0700 (PDT) Received: from mgw-da01.nokia.com (smtp.nokia.com [147.243.128.24]) by ietfa.amsl.com (Postfix) with ESMTP id 30FEF11E80E5 for ; Tue, 13 Sep 2011 12:48:03 -0700 (PDT) Received: from vaebh101.NOE.Nokia.com (vaebh101.europe.nokia.com [10.160.244.22]) by mgw-da01.nokia.com (Switch-3.4.4/Switch-3.4.3) with ESMTP id p8DJnZDH010635 for ; Tue, 13 Sep 2011 22:50:09 +0300 Received: from smtp.mgd.nokia.com ([65.54.30.8]) by vaebh101.NOE.Nokia.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.4675); Tue, 13 Sep 2011 22:49:48 +0300 Received: from 008-AM1MMR1-001.mgdnok.nokia.com (65.54.30.56) by NOK-AM1MHUB-04.mgdnok.nokia.com (65.54.30.8) with Microsoft SMTP Server (TLS) id 8.2.255.0; Tue, 13 Sep 2011 21:49:47 +0200 Received: from 008-AM1MPN1-032.mgdnok.nokia.com ([169.254.2.143]) by 008-AM1MMR1-001.mgdnok.nokia.com ([65.54.30.56]) with mapi id 14.01.0323.007; Tue, 13 Sep 2011 21:49:47 +0200 From: To: Thread-Topic: [mif] I-D Action: draft-ietf-mif-dns-server-selection-04.txt Thread-Index: AQHMck2hiDHLctruIUqtXaCp4cV/I5VLtrHQ Date: Tue, 13 Sep 2011 19:49:46 +0000 Message-ID: <916CE6CF87173740BC8A2CE443096962025731AE@008-AM1MPN1-032.mgdnok.nokia.com> References: <20110913194216.28946.30352.idtracker@ietfa.amsl.com> In-Reply-To: <20110913194216.28946.30352.idtracker@ietfa.amsl.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes 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+/nZJb9Kg7Ivi+ZPYNxIOHHQOy5XIAisnd0NemWySEbulPlVI/QHkZZN/9gjDrg6WMjjydPZC1Dd0tVMnpBZPKmXcW4wpP4faiUqTxBJWOV7RM0T0M25NUq6/J1jkLEKh9L73zhow7xDpoaWsqDxAEkOjYaJIV7Xm9QbZod6U2dYRNiMneD4ePs9p6pn+feNbDXHAMDPemhkLu7LEVecgfmXMkmnbz6IMZIkYw1d+xi8p9Dwc2CKErcX0mqnuOwGggew6UVEyECw== x-originating-ip: [88.115.224.28] Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=SHA1; boundary="----=_NextPart_000_00D6_01CC7267.6E9E7C60" MIME-Version: 1.0 X-OriginalArrivalTime: 13 Sep 2011 19:49:48.0841 (UTC) FILETIME=[4B9BA990:01CC724E] X-Nokia-AV: Clean Subject: Re: [mif] I-D Action: draft-ietf-mif-dns-server-selection-04.txt X-BeenThere: mif@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multiple Interface Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 13 Sep 2011 19:48:12 -0000 ------=_NextPart_000_00D6_01CC7267.6E9E7C60 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Hi all, I wanted to share the current working version where I have accommodated feedback I've received this far (I need to check if I've missed any, there has been quite a bunch) and also fixed quite some nits. I changed title to "multi-interfaced" from "multi-homed" in recollection if discussion with Brian on v6ops list earlier. I have two questions: - is it ok to have ip6.arpa and in-addr.arpa in both DHCPv4 and DHCPv6 options? - should the question of "The resolver MUST take into account differences in trust levels of pieces of received DNS server selection information." Be MAY/SHOULD/MUST? Current text says MUST. Thank you for all feedback, Teemu > -----Original Message----- > From: mif-bounces@ietf.org [mailto:mif-bounces@ietf.org] On Behalf Of > ext internet-drafts@ietf.org > Sent: 13. syyskuuta 2011 22:42 > To: i-d-announce@ietf.org > Cc: mif@ietf.org > Subject: [mif] I-D Action: draft-ietf-mif-dns-server-selection-04.txt > > A New Internet-Draft is available from the on-line Internet-Drafts directories. > This draft is a work item of the Multiple Interfaces Working Group of the > IETF. > > Title : Improved DNS Server Selection for Multi-Interfaced > Nodes > Author(s) : Teemu Savolainen > Jun-ya Kato > Ted Lemon > Filename : draft-ietf-mif-dns-server-selection-04.txt > Pages : 25 > Date : 2011-09-13 > > A multi-interfaced node is connected to multiple networks, some of > which may be utilizing private DNS namespaces. A node commonly > receives DNS server configuration information from all connected > networks. Some of the DNS servers may have information about > namespaces other servers do not have. When a multi-interfaced node > needs to utilize DNS, the node has to choose which of the servers to > contact to. This document describes DHCPv4 and DHCPv6 option that > can be used to configure nodes with information required to perform > informed DNS server selection decisions. > > > A URL for this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-ietf-mif-dns-server-selection- > 04.txt > > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ > > This Internet-Draft can be retrieved at: > ftp://ftp.ietf.org/internet-drafts/draft-ietf-mif-dns-server-selection-04.tx t > _______________________________________________ > mif mailing list > mif@ietf.org > https://www.ietf.org/mailman/listinfo/mif ------=_NextPart_000_00D6_01CC7267.6E9E7C60 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIOuzCCAzYw ggIeoAMCAQICBDpVqdkwDQYJKoZIhvcNAQEFBQAwKTEOMAwGA1UEChMFTm9raWExFzAVBgNVBAMT Dk5va2lhICBSb290IENBMB4XDTAxMDEwNTExMDUwNVoXDTE2MDEwMjExMDUwNVowKTEOMAwGA1UE ChMFTm9raWExFzAVBgNVBAMTDk5va2lhICBSb290IENBMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8A MIIBCgKCAQEAsrTy8gLmr4LYvp0khVUVHw7ascdl+Cjr+yI5MlZ6J/U6Qsvkiqthgqq8rPcLV0P1 92TfBr27VgKEeCaZe0icS1jC2spM/wRv3j2WxdkKxb9kDJtuCNJaRBqvi5vGTHB15nmEmKuL5f3i rAxeHqPjgS496oWcudzFT1e7Xrc/gWGFYd72+/ykIFXjWOMZv6QpxD8x1hLPyh2YVXRk9U7N7pvm RQNX29g4SCFJY2BBIa5JPlwIF8Nc9IePaC/E/2M4tGMtiOOZlm99EoL7N0hJZtFSvUwdCBud/viH 4DgsKGjNkNKi6pAHc9IaXB6tIykcoYp+L+oe/3+cuEJaCj1EKwIDAQABo2YwZDASBgNVHRMBAf8E CDAGAQH/AgEEMB0GA1UdDgQWBBSNjfefoQ0AITLvqe0iruA79NB9sDAfBgNVHSMEGDAWgBSNjfef oQ0AITLvqe0iruA79NB9sDAOBgNVHQ8BAf8EBAMCAYYwDQYJKoZIhvcNAQEFBQADggEBAIGEPql2 TALyKi/h1J+Mh5XolAtYppcSOLMtBkoA7ZovGBDNvl0VbZs8AAojJqkUoWBB+L6DKyl/jKhNfKcu rWRGRyj7pnbxrKLsI3gmWNWkyo2b60wJwe9fqPD5ZQy3oEiMit9l0Ba6il/k2GqYopUCNMa7mfeb E2LeBy5ChYMiCi97UQSJvAdzEYylTJw8Awc6AiM2Ve5N+XxsmKgNf/2A/5IJ3EZZ+wFRmkI4062A oNU302rqAt0HH88jzoUF4AfYHWl6HpYhGXFbcX44rHINyPmFBRxLYIFJ6ZWUr/mXpL/e6rqFtNWO kV6UoJND7OVZkbLh7F1+lcqXRU8TPBMwggOHMIICb6ADAgECAgRBtbHpMA0GCSqGSIb3DQEBBQUA MCkxDjAMBgNVBAoTBU5va2lhMRcwFQYDVQQDEw5Ob2tpYSAgUm9vdCBDQTAeFw0wNjAzMzAwOTU3 MTFaFw0xNjAxMDIxMTA1MDVaMDMxCzAJBgNVBAYTAkZJMQ4wDAYDVQQKEwVOb2tpYTEUMBIGA1UE AxMLTm9raWEgQkkgQ0EwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQDtFCg3QEjSCg6T IUxoWsNwELh8bBNiUQPCPmg8c2DHQYXWWCSCMb+S0Fvh1qqI1xt+XnzyFq+5eqzGzDj4UaBcG+d9 qxrCFly8sHyoPTryyPrR0EI2UUDWwfS6ojhqgwghRqo8G38TjFusyBtLub/5L6yvWYSOHD+JcB+q VM2fbkArPYK4Ydv8WG/DbHjGn0gKq0zwpVZKI/gCK/QALYvte02NXseqvY9/GOyLtjy3Z8erFv71 KKTq+gxI/7DK55pJf3PoD+kT4kyGm6EF9DTdK4ojMdar17uyX0IOZz/4vkkF0d+60nmnLX63FJPA jUyB0HUNJ32NXDo9UsM38aoNAgMBAAGjgawwgakwDwYDVR0TAQH/BAUwAwEB/zARBgNVHSAECjAI MAYGBFUdIAAwDgYDVR0PAQH/BAQDAgGGMFQGA1UdIwRNMEuAFI2N95+hDQAhMu+p7SKu4Dv00H2w oS2kKzApMQ4wDAYDVQQKEwVOb2tpYTEXMBUGA1UEAxMOTm9raWEgIFJvb3QgQ0GCBDpVqdkwHQYD VR0OBBYEFKcksD7Fg+8EDlB2Sxgy58pW0Sy6MA0GCSqGSIb3DQEBBQUAA4IBAQAC3lEUplDlVNOT Pjz/XFezXx2bV2XbCFindhA3F815Egi55H6/cYezEjoP4QLNEGGl2I3aLvkn5A0T8I4pbiFPhIiu B/frbbGg6k6GjQLe/bFQ8F1mAOOR+GyneKZFPfzaRV0jiIR9QqnMXTf8RvKkCJyFj10MZVsLIy/Y uBkzeP3JhzDhUdtPfwmJN6ZbIhH5uR/2BwAGtgQknb8WX3I4wnhWtMUxB8XmayayYs8qWYeIiVkI FV+sLTkWUWVvvKUjyakBpbAW2vUP84DYsJ8TL1YefNjf/nIOByMcORLuV/1gPjyv00qJbcB59AA+ iXe3zIo8QNcgXG0uPQQFmrGDMIID5DCCAsygAwIBAgIQMH5apak8lEy6LmLlLsJy8TANBgkqhkiG 9w0BAQUFADAzMQswCQYDVQQGEwJGSTEOMAwGA1UEChMFTm9raWExFDASBgNVBAMTC05va2lhIEJJ IENBMB4XDTExMDkwNjA1NTIwNFoXDTE0MDkwNjA1NTIwNFowVjEOMAwGA1UECgwFTm9raWExDzAN BgNVBAsMBlBlb3BsZTEYMBYGCgmSJomT8ixkAQEMCDEwMDI0Njc2MRkwFwYDVQQDDBBTYXZvbGFp bmVuIFRlZW11MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAshEsmw6Yiz6XWX26oF+I s5fsfE1OfCjOelclmtqCiIgXND5klkNOBs2d4ZGzgD9mN+XnTZnOTh249c2WxPBugf12DCcDmBAJ gL+VuWUJVBTE5NRchm/O8nZnZsRFst+gAC9/Juykh4+EYewZ7QbpnlwW7hNpj8eH+rMr+OZHKzdp KTftgVjmuF4JJ/cPMQUjL8SuGj+zBW6IWPOZdqkEMtf7Pr8kkYbZsh0SgJ0ceRHZ7Uc06mB/y+C1 UnJPxehTTdu8tpCjdzXgBw/H2uuW1J3qdHbCfbuDILql8V8RiZKubcZLhdsD3Jvj8qK0DGWBJa6x p90q5p3pLE8LvAeCgQIDAQABo4HQMIHNMA4GA1UdDwEB/wQEAwIEMDAfBgNVHSMEGDAWgBSnJLA+ xYPvBA5QdksYMufKVtEsujAZBgNVHSAEEjAQMA4GDCsGAQQBXgExBgEHAzA5BgNVHR8EMjAwMC6g LKAqhihodHRwOi8vY3JsLm5va2lhLmNvbS9Ob2tpYSUyMEJJJTIwQ0EuY3JsMCUGA1UdEQQeMByB GnRlZW11LnNhdm9sYWluZW5Abm9raWEuY29tMB0GA1UdDgQWBBQTRzvZsgmQrAGCeuzdHTGAC6Jg UzANBgkqhkiG9w0BAQUFAAOCAQEACmPVsdi07pjK5gDa+W5JlE2C74kVVsB8alBqfioYeR5At2FG B7sua4Dz5H7TJMpZ1jYFeI+zjexD5f+beY2IlV15lMoWD+5e38QlLYjwfe2LAyvdzBKXW0e0U6Bt p78ft4gyVak1X+Db+ebR+FNHUOMNhm+yK3w9sy5ZQzBFusIx4OgxGvcZhyhmd9WjipSTalgPwgqV Ju2aPADCG++OEXmgEWRLsR4yNopkgK4ftVqrN5uUtLs83qdeXTRcNRiET1IOx5zmYFZ6q3gjKIx5 iyuxcDeYas93vVHUcaRRYpsoby5CHq7Z/j/TQhtqO/knWuxLFFiCUgdGKMKrRkg29DCCBAowggLy oAMCAQICEQCBvi+p+bA/dBtBtybwA6YYMA0GCSqGSIb3DQEBBQUAMDMxCzAJBgNVBAYTAkZJMQ4w DAYDVQQKEwVOb2tpYTEUMBIGA1UEAxMLTm9raWEgQkkgQ0EwHhcNMTEwOTA2MDU1MDM0WhcNMTMw OTA1MDU1MDM0WjBWMQ4wDAYDVQQKDAVOb2tpYTEPMA0GA1UECwwGUGVvcGxlMRgwFgYKCZImiZPy LGQBAQwIMTAwMjQ2NzYxGTAXBgNVBAMMEFNhdm9sYWluZW4gVGVlbXUwggEiMA0GCSqGSIb3DQEB AQUAA4IBDwAwggEKAoIBAQDFPmbRVwuo52v+h6xnQUqokAx2xsHjmPBniEkzgtgBNJsFi838ATEg 1zsx+VotoJg7hMijcrQfpTAgW6gpLGnlmw5QQswrNK1zleOHb4pA5JguU3WhVKFkAH/6/2EU2k/9 m8Pb/gwP55cYg80R6fRmbdsWKhseXF/1isW/rJcWLmIYDg/rXfo3ixqtT9MroAMiuoXnb0ij1L2d Jj64LDp3Ld8Jo0qZzk3Fj4apo8PBd8eAH6HloVBJkxQcwAnv561A+Xi1GHZ2mafRYJGO+1uBDwyd g/8ybEXXA4MKo8lPKjBebYBUFvz80DBA/Lq74UysXkG23BSulcG4xQSYGlyzAgMBAAGjgfUwgfIw HwYDVR0jBBgwFoAUpySwPsWD7wQOUHZLGDLnylbRLLowGQYDVR0gBBIwEDAOBgwrBgEEAV4BMQYB BgQwOQYDVR0fBDIwMDAuoCygKoYoaHR0cDovL2NybC5ub2tpYS5jb20vTm9raWElMjBCSSUyMENB LmNybDAjBgNVHSUEHDAaBggrBgEFBQcDAgYEVR0lAAYIKwYBBQUHAwQwDgYDVR0PAQH/BAQDAgeA MCUGA1UdEQQeMByBGnRlZW11LnNhdm9sYWluZW5Abm9raWEuY29tMB0GA1UdDgQWBBTGhbTJF0EX iagjymQo6GIuSQeRVDANBgkqhkiG9w0BAQUFAAOCAQEAqai6TxZ/BlMHZIhJNPriBPXkQhUlBkGA buJZ5sVm1HIQhWN8elZKjjJdHi1qWEKhMg7yHjEMZsyV8XAZzK0UnOqkpUnt+jnVkNZ9O7/jRtyK f4WUtq5jErc8Hlv4bbGFRHk1T7AuLLE52r1lYOdmoibnQp03QtlDvHUNa68G7jvzThJhieB7U1xh vH3yy0ktaVnWEgAylqf9yIUFjnqau5R6cE1Xo57IYPk/KitX0YF+OigEI/bOQVMi+fze93ZsAOJv /z6g/NGemvUgl5YSdX0uPQK6kEHf/sp/nZyUWWQ7OjtVSqkq2YuYEueQFxTfafl+78GWqgm6W/Bl 32laYzGCAuswggLnAgEBMEgwMzELMAkGA1UEBhMCRkkxDjAMBgNVBAoTBU5va2lhMRQwEgYDVQQD EwtOb2tpYSBCSSBDQQIRAIG+L6n5sD90G0G3JvADphgwCQYFKw4DAhoFAKCCAXgwGAYJKoZIhvcN AQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG9w0BCQUxDxcNMTEwOTEzMTk0OTQ0WjAjBgkqhkiG9w0B CQQxFgQUlSO10xdKX9Sg8SGJBOlM3rrGcfUwVgYJKwYBBAGCNxAEMUkwRzAzMQswCQYDVQQGEwJG STEOMAwGA1UEChMFTm9raWExFDASBgNVBAMTC05va2lhIEJJIENBAhAwflqlqTyUTLouYuUuwnLx MFgGCyqGSIb3DQEJEAILMUmgRzAzMQswCQYDVQQGEwJGSTEOMAwGA1UEChMFTm9raWExFDASBgNV BAMTC05va2lhIEJJIENBAhAwflqlqTyUTLouYuUuwnLxMGcGCSqGSIb3DQEJDzFaMFgwCgYIKoZI hvcNAwcwDgYIKoZIhvcNAwICAgCAMA0GCCqGSIb3DQMCAgFAMAcGBSsOAwIHMA0GCCqGSIb3DQMC AgEoMAcGBSsOAwIaMAoGCCqGSIb3DQIFMA0GCSqGSIb3DQEBAQUABIIBAAEV4Rtxffml0dBoixL8 JQ+p8k3EbzySISURKMESlvKvbyml0zLg8fBi5BeXyJnfILKjGDwWHciArGU+3chD+sK8ReD0YW0b RCryj+vIo9CGfj8uA4PqZ5UnMUd6uY4BFJkRTWfA0tv0OJJZV6vsGF/3etQ1UhsU26QorVG3XOi8 eKCTl/TNFyA3uq0fqCdBz80k7cqA1K50GNmpD/KaFqz3/CD+jLGoJ3Q//VWO5qikWujnkwaOWCdO J/O6Vk7kfH/GIwdbR001MLq2qwKJ0Mg4WC9Q3WL93pBtgfA3ny1u8yneCJQpQ4sXvmNZf9DhcyjV 8yE+DK3frdry+7iz6TIAAAAAAAA= ------=_NextPart_000_00D6_01CC7267.6E9E7C60-- From alexandru.petrescu@gmail.com Tue Sep 13 13:37: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 05A2E11E80C9 for ; Tue, 13 Sep 2011 13:37:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.975 X-Spam-Level: X-Spam-Status: No, score=-1.975 tagged_above=-999 required=5 tests=[AWL=1.624, 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 crKOWnV9V5wE for ; Tue, 13 Sep 2011 13:37:06 -0700 (PDT) Received: from mail-ww0-f44.google.com (mail-ww0-f44.google.com [74.125.82.44]) by ietfa.amsl.com (Postfix) with ESMTP id D34CD11E80C7 for ; Tue, 13 Sep 2011 13:37:05 -0700 (PDT) Received: by wwf22 with SMTP id 22so892387wwf.13 for ; Tue, 13 Sep 2011 13:39:12 -0700 (PDT) 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=8Q251dhKveuCHrVYLpapQWFGyEPej/9uVEnOgIm45oc=; b=hOXXR8ijmaZIuQP2y4GcCUpr7d+bDIR7jHMXH4j62Q/+tJQqT5JFryC37fhWqisUKr CwQYloK6OP3j+KDHc5xLL79tuvmhO1/35XO7YPqX0dsp/ce2h3mIEM/vRcGJiHNELU4l EfcyUsiOge+5o0If7kcxfTzHsmWLnxQLFwV3U= Received: by 10.216.163.83 with SMTP id z61mr1431584wek.58.1315946352319; Tue, 13 Sep 2011 13:39:12 -0700 (PDT) Received: from [127.0.0.1] (bur91-3-82-239-213-32.fbx.proxad.net. [82.239.213.32]) by mx.google.com with ESMTPS id ev5sm1727901wbb.11.2011.09.13.13.39.10 (version=SSLv3 cipher=OTHER); Tue, 13 Sep 2011 13:39:11 -0700 (PDT) Message-ID: <4E6FBF69.2020705@gmail.com> Date: Tue, 13 Sep 2011 22:39:05 +0200 From: Alexandru Petrescu User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:6.0.2) Gecko/20110902 Thunderbird/6.0.2 MIME-Version: 1.0 To: mif@ietf.org References: <3CF88B99A9ED504197498BC6F6F04B81040FBDA9@XMB-BGL-41E.cisco.com> <4E6E7A72.9030208@gmail.com> <4E6EAFC2.5060906@gmail.com> <4E6EDEA8.3080108@gmail.com> <4E6F825C.3080303@gmail.com> <3D0B3661-8A8F-4BB2-A8EF-25007BEAF66C@nominum.com> <4E6F923F.7090304@gmail.com> <7061CEB8-8084-41D5-B31E-9F8E3B6C7091@nominum.com> <4E6F9B91.7010503@gmail.com> <4E6FA64E.7020801@gmail.com> <82337D11-0A39-4A10-AA0E-1E81B09DBA4F@nominum.com> <4E6FACF6.5000007@viagenie.ca> <460A90E1-7A38-484E-BA55-62F080478DB3@nominum.com> <4E6FB304.1060703@viagenie.ca> In-Reply-To: <4E6FB304.1060703@viagenie.ca> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Subject: Re: [mif] Comments on draft-mouton-mif-dhcpv6-drlo-00 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, 13 Sep 2011 20:37:07 -0000 Le 13/09/2011 21:46, Simon Perreault a 閏rit : > Ted Lemon wrote, on 09/13/2011 03:41 PM: >> On Sep 13, 2011, at 3:20 PM, Simon Perreault wrote: >>> I'm guessing that's a point-to-point interface. So you don't need >>> the next hop's L2 address. You just send it down the tube and it >>> gets at the other end. The classic example is PPP. >> >> Okay, that sort of makes sense, but it seems like it's impossible >> for the DHCP server to know what that interface is called, and easy >> to just have the client set up the routing since it knows what it's >> doing. > > Agreed. > > In any case it's still possible to describe a P-t-P route using the > remote endpoint's IP address instead of the interface name or index. Except that when that default route is given by the DHCP Server this latter may not know the remote endpoint's IP address. It may be for this reason why currently is a "0.0.0.0"; and also because it changes with every new attachement which does not involve a new DHCP exchange. One alternative could be to specify that the Client adds that default route on the interface on which it received the Advertise. Without this clarification the Client does not know what to do with a "0.0.0.0 0.0.0.0" default route received in a DHCP message. There may exist other alternatives. But spec should say what the Client should do about a "0.0.0.0 0.0.0.0" default route otherwise it can't insert it in its forwarding information base. Alex So IMHO the 3G use > case is supported by the current draft. > > Simon From alexandru.petrescu@gmail.com Tue Sep 13 13:39:21 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 D98D111E80C9 for ; Tue, 13 Sep 2011 13:39:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.091 X-Spam-Level: X-Spam-Status: No, score=-2.091 tagged_above=-999 required=5 tests=[AWL=1.508, 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 ppSgvqYp39Pj for ; Tue, 13 Sep 2011 13:39:21 -0700 (PDT) Received: from mail-wy0-f172.google.com (mail-wy0-f172.google.com [74.125.82.172]) by ietfa.amsl.com (Postfix) with ESMTP id D68D411E80BB for ; Tue, 13 Sep 2011 13:39:20 -0700 (PDT) Received: by wyg24 with SMTP id 24so986039wyg.31 for ; Tue, 13 Sep 2011 13:41:27 -0700 (PDT) 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=FgeQ7g2m/aCFzUmkFWIxuGv4oI02x90xPsBE5SRC2lE=; b=wWPNLTSeV+CH6ZMBV+T2mas4bSUSkmwzYbp2MrXpLb7GIbH64Y5Ly/BtAi7y7MKB+K jYZFaA0s/4OEM6EuiBwQQ5ej/u9MyvD2Q67q4Z5z4GvYYI+fLTaKkGq51XxwkSXPYqPi U0aI+sCjxFsnHsk2dExHxNAg9UtedjepZy9JA= Received: by 10.227.59.129 with SMTP id l1mr4604954wbh.66.1315946487362; Tue, 13 Sep 2011 13:41:27 -0700 (PDT) Received: from [127.0.0.1] (bur91-3-82-239-213-32.fbx.proxad.net. [82.239.213.32]) by mx.google.com with ESMTPS id y28sm1721125wbn.17.2011.09.13.13.41.26 (version=SSLv3 cipher=OTHER); Tue, 13 Sep 2011 13:41:26 -0700 (PDT) Message-ID: <4E6FBFF0.9060003@gmail.com> Date: Tue, 13 Sep 2011 22:41:20 +0200 From: Alexandru Petrescu User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:6.0.2) Gecko/20110902 Thunderbird/6.0.2 MIME-Version: 1.0 To: mif@ietf.org References: <3CF88B99A9ED504197498BC6F6F04B81040FBDA9@XMB-BGL-41E.cisco.com> <4E6E7A72.9030208@gmail.com> <4E6EAFC2.5060906@gmail.com> <4E6EDEA8.3080108@gmail.com> <4E6F825C.3080303@gmail.com> <3D0B3661-8A8F-4BB2-A8EF-25007BEAF66C@nominum.com> <4E6F923F.7090304@gmail.com> <7061CEB8-8084-41D5-B31E-9F8E3B6C7091@nominum.com> <4E6F9B91.7010503@gmail.com> <4E6FA64E.7020801@gmail.com> <82337D11-0A39-4A10-AA0E-1E81B09DBA4F@nominum.com> <4E6FACF6.5000007@viagenie.ca> <460A90E1-7A38-484E-BA55-62F080478DB3@nominum.com> In-Reply-To: <460A90E1-7A38-484E-BA55-62F080478DB3@nominum.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Subject: Re: [mif] Comments on draft-mouton-mif-dhcpv6-drlo-00 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, 13 Sep 2011 20:39:22 -0000 Le 13/09/2011 21:41, Ted Lemon a 閏rit : > On Sep 13, 2011, at 3:20 PM, Simon Perreault wrote: >> I'm guessing that's a point-to-point interface. So you don't need >> the next hop's L2 address. You just send it down the tube and it >> gets at the other end. The classic example is PPP. > > Okay, that sort of makes sense, but it seems like it's impossible > for the DHCP server to know what that interface is called, and easy > to just have the client set up the routing since it knows what it's > doing. A Client with multiple interfaces has difficulty to set up its default route properly when all the DHCP Server tells it is a "0.0.0.0 0.0.0.0". Alex > > > > _______________________________________________ mif mailing list > mif@ietf.org https://www.ietf.org/mailman/listinfo/mif From alexandru.petrescu@gmail.com Tue Sep 13 13:42: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 B5C4321F8C8F for ; Tue, 13 Sep 2011 13:42:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.191 X-Spam-Level: X-Spam-Status: No, score=-2.191 tagged_above=-999 required=5 tests=[AWL=1.408, 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 NOHvWn02aBGW for ; Tue, 13 Sep 2011 13:42:34 -0700 (PDT) Received: from mail-fx0-f44.google.com (mail-fx0-f44.google.com [209.85.161.44]) by ietfa.amsl.com (Postfix) with ESMTP id 054AB21F8C8E for ; Tue, 13 Sep 2011 13:42:33 -0700 (PDT) Received: by fxd18 with SMTP id 18so1020011fxd.31 for ; Tue, 13 Sep 2011 13:44:40 -0700 (PDT) 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=qsNBOBH38y/Lcuxw0UVAuXhXyw9XgKckpaUlD+fRyjs=; b=A4ndFcyWkpi63KkYotILoXEeEGISePJTye7UUf++GBZuRrRiaeV/Xrn0FEqXpvnc1j RDgQ2MrwI6Q/l/QHD5s/pHetV3bk7qYOQBwnhLjv/fW1x9uMh/tIvZDLrJ0p+5PXp3ag e6WGDZzDRa3lTTRMz0gPLiV1QH50flZuVb450= Received: by 10.223.91.75 with SMTP id l11mr547169fam.66.1315946680444; Tue, 13 Sep 2011 13:44:40 -0700 (PDT) Received: from [127.0.0.1] (bur91-3-82-239-213-32.fbx.proxad.net. [82.239.213.32]) by mx.google.com with ESMTPS id s13sm1373876fad.18.2011.09.13.13.44.36 (version=SSLv3 cipher=OTHER); Tue, 13 Sep 2011 13:44:36 -0700 (PDT) Message-ID: <4E6FC0AE.5000108@gmail.com> Date: Tue, 13 Sep 2011 22:44:30 +0200 From: Alexandru Petrescu User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:6.0.2) Gecko/20110902 Thunderbird/6.0.2 MIME-Version: 1.0 To: mif@ietf.org References: <3CF88B99A9ED504197498BC6F6F04B81040FBDA9@XMB-BGL-41E.cisco.com> <4E6E7A72.9030208@gmail.com> <4E6EAFC2.5060906@gmail.com> <4E6EDEA8.3080108@gmail.com> <4E6F825C.3080303@gmail.com> <3D0B3661-8A8F-4BB2-A8EF-25007BEAF66C@nominum.com> <4E6F923F.7090304@gmail.com> <7061CEB8-8084-41D5-B31E-9F8E3B6C7091@nominum.com> <4E6F9B91.7010503@gmail.com> <4E6FA64E.7020801@gmail.com> <82337D11-0A39-4A10-AA0E-1E81B09DBA4F@nominum.com> <4E6FACF6.5000007@viagenie.ca> In-Reply-To: <4E6FACF6.5000007@viagenie.ca> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Subject: Re: [mif] Comments on draft-mouton-mif-dhcpv6-drlo-00 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, 13 Sep 2011 20:42:34 -0000 Le 13/09/2011 21:20, Simon Perreault a 閏rit : > Ted Lemon wrote, on 09/13/2011 03:15 PM: >> Also, I'm a bit confused by the idea of an interface route with no >> router address in IPv6. I will admit to being something of a tyro >> when it comes to these things, but I don't understand how that >> would work. Does the client simply multicast every packet? Is >> there an RFC or draft that documents how this works? > > I'm guessing that's a point-to-point interface. So you don't need the > next hop's L2 address. You just send it down the tube and it gets at > the other end. The classic example is PPP. YEs, it is a "no ARP" interface, but in some 3G+ it is not PPP. Yes, the client just sends it down the tube. But no, the Client can't set up that default route when all is being given is "0.0.0.0". It must tell the interface name. The Client by itself is not capable to decide how to insert that default router entry in its routing table, it just can't solve "0.0.0.0" on some interface name so it must be told the interface name by some spec or mechanism. Alex > > Simon From alexandru.petrescu@gmail.com Tue Sep 13 13:49:58 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 3B8A111E80D4 for ; Tue, 13 Sep 2011 13:49:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.279 X-Spam-Level: X-Spam-Status: No, score=-2.279 tagged_above=-999 required=5 tests=[AWL=1.320, 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 I9LKsXFjZwP9 for ; Tue, 13 Sep 2011 13:49:57 -0700 (PDT) Received: from mail-fx0-f44.google.com (mail-fx0-f44.google.com [209.85.161.44]) by ietfa.amsl.com (Postfix) with ESMTP id 68D6C11E80C9 for ; Tue, 13 Sep 2011 13:49:57 -0700 (PDT) Received: by fxd18 with SMTP id 18so1028708fxd.31 for ; Tue, 13 Sep 2011 13:52:04 -0700 (PDT) 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:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; bh=b0GVr2nAZXvi2E1tmq6zSIQWFKRfCbY1H1piIwpMm7g=; b=hcKSzY5FMW/NdLW5QdP9wN8G9QKNmqT38+NRmvkidy4o2r8Sn9fxdipkKRNlff7trM E0LAF/fPBXd/afGRnqErs/ytmSGTeH28zakzqQSs1Im4J5GCdWucqckn5Wo1Go7HTlEm WC6/+m9HpZzTsayt0WGvan/qMgIShuq417H1o= Received: by 10.223.42.24 with SMTP id q24mr867283fae.148.1315947123949; Tue, 13 Sep 2011 13:52:03 -0700 (PDT) Received: from [127.0.0.1] (bur91-3-82-239-213-32.fbx.proxad.net. [82.239.213.32]) by mx.google.com with ESMTPS id r3sm1370180fam.26.2011.09.13.13.52.02 (version=SSLv3 cipher=OTHER); Tue, 13 Sep 2011 13:52:03 -0700 (PDT) Message-ID: <4E6FC26C.3020304@gmail.com> Date: Tue, 13 Sep 2011 22:51:56 +0200 From: Alexandru Petrescu User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:6.0.2) Gecko/20110902 Thunderbird/6.0.2 MIME-Version: 1.0 To: Ted Lemon References: <3CF88B99A9ED504197498BC6F6F04B81040FBDA9@XMB-BGL-41E.cisco.com> <4E6E7A72.9030208@gmail.com> <4E6EAFC2.5060906@gmail.com> <4E6EDEA8.3080108@gmail.com> <4E6F825C.3080303@gmail.com> <3D0B3661-8A8F-4BB2-A8EF-25007BEAF66C@nominum.com> <4E6F923F.7090304@gmail.com> <7061CEB8-8084-41D5-B31E-9F8E3B6C7091@nominum.com> <4E6F9B91.7010503@gmail.com> <4E6FA64E.7020801@gmail.com> <82337D11-0A39-4A10-AA0E-1E81B09DBA4F@nominum.com> In-Reply-To: <82337D11-0A39-4A10-AA0E-1E81B09DBA4F@nominum.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Cc: "" Subject: Re: [mif] Comments on draft-mouton-mif-dhcpv6-drlo-00 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, 13 Sep 2011 20:49:58 -0000 Le 13/09/2011 21:15, Ted Lemon a 閏rit : > On Sep 13, 2011, at 2:51 PM, Alexandru Petrescu wrote: >> With respect to lifetimes: if you do not agree discussing lifetimes >> now then you may agree discussing lifetimes when implementation >> feedback of existing option is out. I suppose there is currently no >> implementation of the existing option, whereas implementation of >> draft-mouton-mif-dhcpv6-drlo-00 does exist, as reflected in >> http://www.ietf.org/mail-archive/web/mif/current/msg01166.html > > How does the existing implementation handle renewal? The existing implementation of draft-mouton-mif-dhcpv6-drlo-00 does not handle renewal. We're facing too many options about it: should it RENEW? Should it send an RS as well? This is up to debate. But it is related only to the default route, not the other routes. Remark the debate comes from the lifetime of ND as well. >> What do you mean by "use case" so I can better detail how this >> default route option is necessary, thanks. > > The 3G+ scenario is the first use case you've presented, so thanks > for that. > > If interface names are in fact required, that's interesting. I really > don't understand how that could work, though, since the DHCP server > has no way to know what the client operating system is calling the > interface. > > Also, I'm a bit confused by the idea of an interface route with no > router address in IPv6. I will admit to being something of a tyro > when it comes to these things, but I don't understand how that would > work. Does the client simply multicast every packet? Is there an RFC > or draft that documents how this works? Just puts it on the pipe, but needs to know on which pipe when several interfaces are available. I would like to add further: - we do not try to suggest problems for others to solve, but would like to participate in the solution space. - in the use case of use Mobile IP, the default route on a 3G+ terminal points actually to a virtual interface tunnel name, and not to a real interface. (the real interface is used as target of a host-specific route towards the Mobile IP home agent.) - in the case of using a v6-v4 transition method, the default IPv6 route points to a virtual interface as well, and not to a real interface. In this case as well, the default route communicated by DHCPv6 to a multiply-interfaced Client needs potentially much more than simply dst address of the default router. Alex > From alexandru.petrescu@gmail.com Tue Sep 13 13:57: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 3E5EE11E80E5 for ; Tue, 13 Sep 2011 13:57:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.357 X-Spam-Level: X-Spam-Status: No, score=-2.357 tagged_above=-999 required=5 tests=[AWL=1.242, 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 jkFCy+0Q7AiQ for ; Tue, 13 Sep 2011 13:57:12 -0700 (PDT) Received: from mail-fx0-f44.google.com (mail-fx0-f44.google.com [209.85.161.44]) by ietfa.amsl.com (Postfix) with ESMTP id 77BDA11E80DB for ; Tue, 13 Sep 2011 13:57:12 -0700 (PDT) Received: by fxd18 with SMTP id 18so1035463fxd.31 for ; Tue, 13 Sep 2011 13:59:19 -0700 (PDT) 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=wkTWLW6mYufLoYkVxwodz/6HJ3Leg4DRBeJ7NOS5ocU=; b=NDnz9pYa99npYdbIqruztSCIaZhTcnSzGnIol5K6DsmXWLMFKA+4KX5rwd3XsYy0m6 TGSA794eXRXBRzzo1/CkbIvcPySrrh/d44fGtYuP8hHfz5TYneA6DCyBj2cZtGJDhCWh RKcgqO2jwl3pu0cZ+HTgctPovrMjX3np0Sj0I= Received: by 10.223.48.141 with SMTP id r13mr252792faf.115.1315947559069; Tue, 13 Sep 2011 13:59:19 -0700 (PDT) Received: from [127.0.0.1] (bur91-3-82-239-213-32.fbx.proxad.net. [82.239.213.32]) by mx.google.com with ESMTPS id b10sm1444016fam.1.2011.09.13.13.59.16 (version=SSLv3 cipher=OTHER); Tue, 13 Sep 2011 13:59:16 -0700 (PDT) Message-ID: <4E6FC41E.6010002@gmail.com> Date: Tue, 13 Sep 2011 22:59:10 +0200 From: Alexandru Petrescu User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:6.0.2) Gecko/20110902 Thunderbird/6.0.2 MIME-Version: 1.0 To: mif@ietf.org References: <3CF88B99A9ED504197498BC6F6F04B81040FBDA9@XMB-BGL-41E.cisco.com> <4E6E7A72.9030208@gmail.com> <4E6EAFC2.5060906@gmail.com> <4E6EDEA8.3080108@gmail.com> <4E6F825C.3080303@gmail.com> <3D0B3661-8A8F-4BB2-A8EF-25007BEAF66C@nominum.com> <4E6F923F.7090304@gmail.com> <7061CEB8-8084-41D5-B31E-9F8E3B6C7091@nominum.com> <4E6F9B91.7010503@gmail.com> <4E6FA049.1040309@viagenie.ca> In-Reply-To: <4E6FA049.1040309@viagenie.ca> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Subject: Re: [mif] Comments on draft-mouton-mif-dhcpv6-drlo-00 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, 13 Sep 2011 20:57:13 -0000 Le 13/09/2011 20:26, Simon Perreault a 閏rit : > Ted Lemon wrote, on 09/13/2011 02:22 PM: >> Could you please clearly articulate a use case where this option is >> necessary, and the existing proposed option is not adequate? >> Please do not mention operating system data structures. Please do >> not say "I find it to be the case that.." Without a use case, I >> just don't see the point in discussing this further. > > +1 -1 One particular use case is: DHCP communicates a default route without lifetime to Client. Client inserts the default route without lifetime. Some implementations may set that mandatory ND local field to arbitrary values- some will expire it some won't. Some Clients will run RS after that time others won't. One other case is the following, for WiFi hotspot: DHCP communicates the default route wihtout MAC address Client will receive the defualt route and install it. When it first uses it it will necessarily generate an NS-NA in order to solve the default router's address into the MAC address. This additional NS-NA is noise on wire, compared to if the MAC address were communicated in the first place. Alex > > Simon From Ted.Lemon@nominum.com Tue Sep 13 14:25: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 459AA11E80EC for ; Tue, 13 Sep 2011 14:25:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.594 X-Spam-Level: X-Spam-Status: No, score=-106.594 tagged_above=-999 required=5 tests=[AWL=0.004, 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 RqSfAQ1WAUlO for ; Tue, 13 Sep 2011 14:25:11 -0700 (PDT) Received: from exprod7og125.obsmtp.com (exprod7og125.obsmtp.com [64.18.2.28]) by ietfa.amsl.com (Postfix) with ESMTP id F13B511E80CA for ; Tue, 13 Sep 2011 14:25:10 -0700 (PDT) Received: from shell-too.nominum.com ([64.89.228.229]) (using TLSv1) by exprod7ob125.postini.com ([64.18.6.12]) with SMTP ID DSNKTm/KtH/nXXjwDgX1c5/MbxdIbvZ92C27@postini.com; Tue, 13 Sep 2011 14:27:18 PDT Received: from archivist.nominum.com (archivist.nominum.com [64.89.228.108]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "*.nominum.com", Issuer "Go Daddy Secure Certification Authority" (verified OK)) by shell-too.nominum.com (Postfix) with ESMTP id B2E90F8021 for ; Tue, 13 Sep 2011 14:27:16 -0700 (PDT) Received: from webmail.nominum.com (cas-02.win.nominum.com [64.89.228.132]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (Client CN "mail.nominum.com", Issuer "Go Daddy Secure Certification Authority" (verified OK)) by archivist.nominum.com (Postfix) with ESMTPS id A4293190065; Tue, 13 Sep 2011 14:27:16 -0700 (PDT) (envelope-from Ted.Lemon@nominum.com) Received: from MBX-01.WIN.NOMINUM.COM ([64.89.228.133]) by CAS-02.WIN.NOMINUM.COM ([64.89.228.132]) with mapi id 14.01.0289.001; Tue, 13 Sep 2011 14:27:16 -0700 From: Ted Lemon To: Alexandru Petrescu Thread-Topic: [mif] Comments on draft-mouton-mif-dhcpv6-drlo-00 Thread-Index: AcxxClosDL9zuhm1Q+CTqXShqzwWxAAw84cAAAfxtgAABv0IAAARg+mAAAbg3wAAAWjoAAAA9R+AAAEFqoAAAF3hgAAAk6wAAAEF9gAAANZHAAADWk8AAAE7wYA= Date: Tue, 13 Sep 2011 21:27:15 +0000 Message-ID: References: <3CF88B99A9ED504197498BC6F6F04B81040FBDA9@XMB-BGL-41E.cisco.com> <4E6E7A72.9030208@gmail.com> <4E6EAFC2.5060906@gmail.com> <4E6EDEA8.3080108@gmail.com> <4E6F825C.3080303@gmail.com> <3D0B3661-8A8F-4BB2-A8EF-25007BEAF66C@nominum.com> <4E6F923F.7090304@gmail.com> <7061CEB8-8084-41D5-B31E-9F8E3B6C7091@nominum.com> <4E6F9B91.7010503@gmail.com> <4E6FA64E.7020801@gmail.com> <82337D11-0A39-4A10-AA0E-1E81B09DBA4F@nominum.com> <4E6FC26C.3020304@gmail.com> In-Reply-To: <4E6FC26C.3020304@gmail.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [173.162.214.218] Content-Type: multipart/alternative; boundary="_000_A98471C4145F4D69990B981577A6135Dnominumcom_" MIME-Version: 1.0 Cc: "" Subject: Re: [mif] Comments on draft-mouton-mif-dhcpv6-drlo-00 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, 13 Sep 2011 21:25:12 -0000 --_000_A98471C4145F4D69990B981577A6135Dnominumcom_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable On Sep 13, 2011, at 4:51 PM, Alexandru Petrescu wrote: The existing implementation of draft-mouton-mif-dhcpv6-drlo-00 does not handle renewal. We're facing too many options about it: should it RENEW? Should it send an RS as well? This is up to debate. But it is related only to the default route, not the other routes. That doesn't even make sense. Why does a default route need a lifetime, b= ut the other routes don't? Why do we need a default route option at all? = It doesn't look like the use case you've proposed justifies this option. --_000_A98471C4145F4D69990B981577A6135Dnominumcom_ Content-Type: text/html; charset="iso-8859-1" Content-ID: Content-Transfer-Encoding: quoted-printable
On Sep 13, 2011, at 4:51 PM, Alexandru Petrescu wrote:
The existing implementation of draft-mouton-mif-dhcpv6-drlo-00 does not
handle renewal.  We're facing too many options about it: should it
RENEW?  Should it send an RS as well?  This is up to debate. &nbs= p;But it is
related only to the default route, not the other routes.

That doesn't even make sense.   Why does a default route need a l= ifetime, but the other routes don't?   Why do we need a default route = option at all?   It doesn't look like the use case you've proposed jus= tifies this option.

--_000_A98471C4145F4D69990B981577A6135Dnominumcom_-- From teemu.savolainen@nokia.com Tue Sep 13 14: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 7F53B11E80CA for ; Tue, 13 Sep 2011 14:29:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.683 X-Spam-Level: X-Spam-Status: No, score=-2.683 tagged_above=-999 required=5 tests=[AWL=-0.085, BAYES_00=-2.599, HTML_MESSAGE=0.001] 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 kuQXHFQKKx8n for ; Tue, 13 Sep 2011 14:29:07 -0700 (PDT) Received: from mgw-sa01.nokia.com (smtp.nokia.com [147.243.1.47]) by ietfa.amsl.com (Postfix) with ESMTP id 8B34A11E80B8 for ; Tue, 13 Sep 2011 14:29:07 -0700 (PDT) Received: from vaebh106.NOE.Nokia.com (vaebh106.europe.nokia.com [10.160.244.32]) by mgw-sa01.nokia.com (Switch-3.4.4/Switch-3.4.3) with ESMTP id p8DLVBOK015464; Wed, 14 Sep 2011 00:31:12 +0300 Received: from smtp.mgd.nokia.com ([65.54.30.7]) by vaebh106.NOE.Nokia.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.4675); Wed, 14 Sep 2011 00:31:07 +0300 Received: from 008-AM1MMR1-006.mgdnok.nokia.com (65.54.30.61) by NOK-AM1MHUB-03.mgdnok.nokia.com (65.54.30.7) with Microsoft SMTP Server (TLS) id 8.2.255.0; Tue, 13 Sep 2011 23:31:06 +0200 Received: from 008-AM1MPN1-032.mgdnok.nokia.com ([169.254.2.143]) by 008-AM1MMR1-006.mgdnok.nokia.com ([65.54.30.61]) with mapi id 14.01.0323.007; Tue, 13 Sep 2011 23:31:04 +0200 From: To: , Thread-Topic: [mif] Comments on draft-mouton-mif-dhcpv6-drlo-00 Thread-Index: AQHMclXvmeatSbe770ilB6P1NUlbCpVL1DV4 Date: Tue, 13 Sep 2011 21:31:03 +0000 Message-ID: <916CE6CF87173740BC8A2CE4430969620257327E@008-AM1MPN1-032.mgdnok.nokia.com> References: <3CF88B99A9ED504197498BC6F6F04B81040FBDA9@XMB-BGL-41E.cisco.com> <4E6E7A72.9030208@gmail.com> <4E6EAFC2.5060906@gmail.com> <4E6EDEA8.3080108@gmail.com> <4E6F825C.3080303@gmail.com> <3D0B3661-8A8F-4BB2-A8EF-25007BEAF66C@nominum.com> <4E6F923F.7090304@gmail.com> <7061CEB8-8084-41D5-B31E-9F8E3B6C7091@nominum.com> <4E6F9B91.7010503@gmail.com> <4E6FA64E.7020801@gmail.com> <82337D11-0A39-4A10-AA0E-1E81B09DBA4F@nominum.com> <4E6FACF6.5000007@viagenie.ca>,<4E6FC0AE.5000108@gmail.com> In-Reply-To: <4E6FC0AE.5000108@gmail.com> Accept-Language: en-US Content-Language: fi-FI X-MS-Has-Attach: X-MS-TNEF-Correlator: Content-Type: multipart/alternative; boundary="_000_916CE6CF87173740BC8A2CE4430969620257327E008AM1MPN1032mg_" MIME-Version: 1.0 X-OriginalArrivalTime: 13 Sep 2011 21:31:07.0491 (UTC) FILETIME=[72C40B30:01CC725C] X-Nokia-AV: Clean Subject: Re: [mif] Comments on draft-mouton-mif-dhcpv6-drlo-00 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, 13 Sep 2011 21:29:08 -0000 --_000_916CE6CF87173740BC8A2CE4430969620257327E008AM1MPN1032mg_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Could you please be more specific what is this 3G+? I mean use of DHCPv4 fo= r address config is extremely rare on real 3GPP accesses and stateful DHCPv= 6 for address config is not on any 3GPP spec version (save PD) at least.. Sent from my Windows Phone ________________________________ From: ext Alexandru Petrescu Sent: 13.9.2011 23:44 To: mif@ietf.org Subject: Re: [mif] Comments on draft-mouton-mif-dhcpv6-drlo-00 Le 13/09/2011 21:20, Simon Perreault a =E9crit : > Ted Lemon wrote, on 09/13/2011 03:15 PM: >> Also, I'm a bit confused by the idea of an interface route with no >> router address in IPv6. I will admit to being something of a tyro >> when it comes to these things, but I don't understand how that >> would work. Does the client simply multicast every packet? Is >> there an RFC or draft that documents how this works? > > I'm guessing that's a point-to-point interface. So you don't need the > next hop's L2 address. You just send it down the tube and it gets at > the other end. The classic example is PPP. YEs, it is a "no ARP" interface, but in some 3G+ it is not PPP. Yes, the client just sends it down the tube. But no, the Client can't set up that default route when all is being given is "0.0.0.0". It must tell the interface name. The Client by itself is not capable to decide how to insert that default router entry in its routing table, it just can't solve "0.0.0.0" on some interface name so it must be told the interface name by some spec or mechanism. Alex > > Simon _______________________________________________ mif mailing list mif@ietf.org https://www.ietf.org/mailman/listinfo/mif --_000_916CE6CF87173740BC8A2CE4430969620257327E008AM1MPN1032mg_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
Could you ple= ase be more specific what is this 3G+? I mean use of DHCPv4 for address= config is extremely rare on real 3GPP accesses and stateful DHCPv6 for add= ress config is not on any 3GPP spec version (save PD) at least..

Sent from my Windows Phone
From: ext Al= exandru Petrescu
Sent: 13.9.2= 011 23:44
To: mif@ie= tf.org
Subject: Re: [m= if] Comments on draft-mouton-mif-dhcpv6-drlo-00

Le 13/09/2011 21:20, Simon Perreault a =E9crit : > Ted Lemon wrote, on 09/13/2011 03:15 PM:
>> Also, I'm a bit confused by the idea of an interface route with no=
>> router address in IPv6.   I will admit to being somethin= g of a tyro
>> when it comes to these things, but I don't understand how that
>> would work.   Does the client simply multicast every pac= ket?   Is
>> there an RFC or draft that documents how this works?
>
> I'm guessing that's a point-to-point interface. So you don't need the<= br> > next hop's L2 address. You just send it down the tube and it gets at > the other end. The classic example is PPP.

YEs, it is a "no ARP" interface, but in some 3G+ it is not PP= P.

Yes, the client just sends it down the tube.

But no, the Client can't set up that default route when all is being
given is "0.0.0.0".  It must tell the interface name.  = The Client by
itself is not capable to decide how to insert that default router entry
in its routing table, it just can't solve "0.0.0.0" on some inter= face
name so it must be told the interface name by some spec or mechanism.

Alex

>
> Simon

_______________________________________________
mif mailing list
mif@ietf.org
https://www.ietf.org/= mailman/listinfo/mif
 --_000_916CE6CF87173740BC8A2CE4430969620257327E008AM1MPN1032mg_-- From Ted.Lemon@nominum.com Tue Sep 13 14: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 ED04511E8109 for ; Tue, 13 Sep 2011 14:29:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.594 X-Spam-Level: X-Spam-Status: No, score=-106.594 tagged_above=-999 required=5 tests=[AWL=0.004, 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 4+M1Pxk9sILd for ; Tue, 13 Sep 2011 14:29:14 -0700 (PDT) Received: from exprod7og123.obsmtp.com (exprod7og123.obsmtp.com [64.18.2.24]) by ietfa.amsl.com (Postfix) with ESMTP id 380CF11E80B8 for ; Tue, 13 Sep 2011 14:29:14 -0700 (PDT) Received: from shell-too.nominum.com ([64.89.228.229]) (using TLSv1) by exprod7ob123.postini.com ([64.18.6.12]) with SMTP ID DSNKTm/LqfrZVXvGr9ua4PERXcvFkECwjZt7@postini.com; Tue, 13 Sep 2011 14:31:21 PDT Received: from archivist.nominum.com (archivist.nominum.com [64.89.228.108]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "*.nominum.com", Issuer "Go Daddy Secure Certification Authority" (verified OK)) by shell-too.nominum.com (Postfix) with ESMTP id 07AB2F8023 for ; Tue, 13 Sep 2011 14:31:21 -0700 (PDT) Received: from webmail.nominum.com (cas-02.win.nominum.com [64.89.228.132]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (Client CN "mail.nominum.com", Issuer "Go Daddy Secure Certification Authority" (verified OK)) by archivist.nominum.com (Postfix) with ESMTPS id 01C40190065; Tue, 13 Sep 2011 14:31:21 -0700 (PDT) (envelope-from Ted.Lemon@nominum.com) Received: from MBX-01.WIN.NOMINUM.COM ([64.89.228.133]) by CAS-02.WIN.NOMINUM.COM ([64.89.228.132]) with mapi id 14.01.0289.001; Tue, 13 Sep 2011 14:31:21 -0700 From: Ted Lemon To: Alexandru Petrescu Thread-Topic: [mif] Comments on draft-mouton-mif-dhcpv6-drlo-00 Thread-Index: AcxxClosDL9zuhm1Q+CTqXShqzwWxAAw84cAAAfxtgAABv0IAAARg+mAAAbg3wAAAWjoAAAA9R+AAAEFqoAAAF3hgAAAk6wAAAAgVoAABVbiAAABH5cA Date: Tue, 13 Sep 2011 21:31:20 +0000 Message-ID: <10031B1F-30BC-4475-8866-C21CD4E1E819@nominum.com> References: <3CF88B99A9ED504197498BC6F6F04B81040FBDA9@XMB-BGL-41E.cisco.com> <4E6E7A72.9030208@gmail.com> <4E6EAFC2.5060906@gmail.com> <4E6EDEA8.3080108@gmail.com> <4E6F825C.3080303@gmail.com> <3D0B3661-8A8F-4BB2-A8EF-25007BEAF66C@nominum.com> <4E6F923F.7090304@gmail.com> <7061CEB8-8084-41D5-B31E-9F8E3B6C7091@nominum.com> <4E6F9B91.7010503@gmail.com> <4E6FA049.1040309@viagenie.ca> <4E6FC41E.6010002@gmail.com> In-Reply-To: <4E6FC41E.6010002@gmail.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [173.162.214.218] Content-Type: multipart/alternative; boundary="_000_10031B1F30BC44758866C21CD4E1E819nominumcom_" MIME-Version: 1.0 Cc: "" Subject: Re: [mif] Comments on draft-mouton-mif-dhcpv6-drlo-00 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, 13 Sep 2011 21:29:15 -0000 --_000_10031B1F30BC44758866C21CD4E1E819nominumcom_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable On Sep 13, 2011, at 4:59 PM, Alexandru Petrescu wrote: One particular use case is: Sorry, to be clear, a use case is an example of usage that requires new pro= tocol action, because existing functionality cannot address the use case. = Use cases have to be real, concrete things, not hypotheticals. I can alw= ays make up a hypothetical example to justify any sort of protocol extensio= n, but if there is no real-world use case that requires it, all the work of= doing that protocol extension is wasted. What you've given in this particular message are a couple of examples of ho= w the option could be used. These are not relevant use cases, because the= y could also be addressed with the existing proposed option. That is, the= y do not motivate additional work. --_000_10031B1F30BC44758866C21CD4E1E819nominumcom_ Content-Type: text/html; charset="iso-8859-1" Content-ID: Content-Transfer-Encoding: quoted-printable
On Sep 13, 2011, at 4:59 PM, Alexandru Petrescu wrote:
One particular use case is:

Sorry, to be clear, a use case is an example of usage that requires ne= w protocol action, because existing functionality cannot address the use ca= se.   Use cases have to be real, concrete things, not hypotheticals. &= nbsp; I can always make up a hypothetical example to justify any sort of protocol extension, but if there is no real= -world use case that requires it, all the work of doing that protocol exten= sion is wasted.

What you've given in this particular message are a couple of examples = of how the option could be used.   These are not relevant use cases, b= ecause they could also be addressed with the existing proposed option. &nbs= p; That is, they do not motivate additional work.

--_000_10031B1F30BC44758866C21CD4E1E819nominumcom_-- From brian.e.carpenter@gmail.com Tue Sep 13 15:06: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 69E8721F8B3F for ; Tue, 13 Sep 2011 15:06:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.586 X-Spam-Level: X-Spam-Status: No, score=-103.586 tagged_above=-999 required=5 tests=[AWL=0.013, 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 RkR1TXsihJWP for ; Tue, 13 Sep 2011 15:06:26 -0700 (PDT) Received: from mail-qy0-f172.google.com (mail-qy0-f172.google.com [209.85.216.172]) by ietfa.amsl.com (Postfix) with ESMTP id 73FA821F8B3E for ; Tue, 13 Sep 2011 15:06:26 -0700 (PDT) Received: by qyk32 with SMTP id 32so3177753qyk.10 for ; Tue, 13 Sep 2011 15:08:29 -0700 (PDT) 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=kfkwuzsFLNPHzvk4fUVbIc6pRviWd4B9srd0CWoYIJw=; b=Eqn0G3IUpqM1PNqs/IRiQmiXcsHnzYZ+Ga6RXjDXes0+5XfK2GQ0myBfWqTMOUzzA/ jh24ET3zDjbUG7DB3h4+VBDoplVb15P1EKLllJfHHEGFj0YYOu4H7EUUF4hvPiwnVIYT GFSgTYmw2VzYo+uNeKyxaMw5sEDhf5bE9pFMI= Received: by 10.224.180.210 with SMTP id bv18mr2394389qab.171.1315951709511; Tue, 13 Sep 2011 15:08:29 -0700 (PDT) Received: from [130.216.38.124] (stf-brian.sfac.auckland.ac.nz. [130.216.38.124]) by mx.google.com with ESMTPS id o18sm2832543qaz.3.2011.09.13.15.08.27 (version=SSLv3 cipher=OTHER); Tue, 13 Sep 2011 15:08:28 -0700 (PDT) Message-ID: <4E6FD459.30303@gmail.com> Date: Wed, 14 Sep 2011 10:08:25 +1200 From: Brian E Carpenter Organization: University of Auckland User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: Simon Perreault References: <20110910220345.29077.66749.idtracker@ietfa.amsl.com> <4E6BE7BF.5030501@gmail.com> <4E6C8F4A.308@gmail.com> <4E6E053B.7000305@viagenie.ca> <4E6E097F.8010205@gmail.com> <4E6E0C4A.7030105@viagenie.ca> <4E6E10E0.6010607@gmail.com> <4E6E13E0.2030402@viagenie.ca> <4E6EB0DC.5040102@gmail.com> <4E6F6933.1010908@viagenie.ca> In-Reply-To: <4E6F6933.1010908@viagenie.ca> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: mif@ietf.org Subject: Re: [mif] I-D draft-ietf-mif-dhcpv6-route-option-03 published X-BeenThere: mif@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multiple Interface Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 13 Sep 2011 22:06:27 -0000 On 2011-09-14 02:31, Simon Perreault wrote: > Brian E Carpenter wrote, on 09/12/2011 09:24 PM: >> On 2011-09-13 02:14, Simon Perreault wrote: >>> On 2011-09-12 10:02, Alexandru Petrescu wrote: >>>>> I don't see the use case. Can't the DHCP client on the very small >>>>> platform just install the default route first, then whatever other >>>>> routes it can support, and ignore the rest? >>>> Do you think there exist a DHCP way to say: "install the default route >>>> first and, if you have enough memory, install these specific routes"? >>> Maybe it can be written in the draft. For example: >>> >>> Hosts MUST install routes in the order they are listed. If any routes >>> cannot be installed due to resource constraints, routes MAY be dropped >>> starting from the end. >>> >>> With this, the operator can put the default route first and obtain the >>> behaviour you're describing. >> That won't work if the host also gets a default route from RA. There's >> nothing to stop DHCPv6 and RA being used simultaneously, for different >> prefixes, and providing different default routers. > > I'm not following you. > - That's not a problem I'm trying to solve with the above proposal. > - Even with a separate DHCP option dedicated to the default route, I don't see > how the problem you mentioned gets solved. I agree, it appears insoluble to me too. I think you should mention that as an operational consideration. Brian From alexandru.petrescu@gmail.com Tue Sep 13 15:18:33 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 E991711E8089 for ; Tue, 13 Sep 2011 15:18:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.426 X-Spam-Level: X-Spam-Status: No, score=-2.426 tagged_above=-999 required=5 tests=[AWL=1.173, 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 kJ+PAoHmf5Yx for ; Tue, 13 Sep 2011 15:18:33 -0700 (PDT) Received: from mail-fx0-f44.google.com (mail-fx0-f44.google.com [209.85.161.44]) by ietfa.amsl.com (Postfix) with ESMTP id A995D11E8082 for ; Tue, 13 Sep 2011 15:18:32 -0700 (PDT) Received: by fxd18 with SMTP id 18so1099338fxd.31 for ; Tue, 13 Sep 2011 15:20:37 -0700 (PDT) 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:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; bh=3X0gZdu6SZhpnKjelD1LnITiabzDjkYbrjHvBOAdR4o=; b=IdVR1fbZm8SuvTORSOBVaD3lMPh2tIShLNNy43wdJ7lyRyZeH5812vVwxLNx6iVxIy +tv29Cepc7exRo5E0Uovsy0QyMySUhlMV/W8f8+jT3BRjzRD3G288QXgbP5QoPSHL1kh /MX9qOSHrFL+ALbjhq1BlP9pYTg5Mnl4tX8t0= Received: by 10.223.92.148 with SMTP id r20mr129963fam.94.1315952423662; Tue, 13 Sep 2011 15:20:23 -0700 (PDT) Received: from [127.0.0.1] (bur91-3-82-239-213-32.fbx.proxad.net. [82.239.213.32]) by mx.google.com with ESMTPS id d22sm1592730fak.10.2011.09.13.15.20.21 (version=SSLv3 cipher=OTHER); Tue, 13 Sep 2011 15:20:22 -0700 (PDT) Message-ID: <4E6FD720.6030300@gmail.com> Date: Wed, 14 Sep 2011 00:20:16 +0200 From: Alexandru Petrescu User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:6.0.2) Gecko/20110902 Thunderbird/6.0.2 MIME-Version: 1.0 To: Ted Lemon References: <3CF88B99A9ED504197498BC6F6F04B81040FBDA9@XMB-BGL-41E.cisco.com> <4E6E7A72.9030208@gmail.com> <4E6EAFC2.5060906@gmail.com> <4E6EDEA8.3080108@gmail.com> <4E6F825C.3080303@gmail.com> <3D0B3661-8A8F-4BB2-A8EF-25007BEAF66C@nominum.com> <4E6F923F.7090304@gmail.com> <7061CEB8-8084-41D5-B31E-9F8E3B6C7091@nominum.com> <4E6F9B91.7010503@gmail.com> <4E6FA64E.7020801@gmail.com> <82337D11-0A39-4A10-AA0E-1E81B09DBA4F@nominum.com> <4E6FC26C.3020304@gmail.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Cc: "" Subject: Re: [mif] Comments on draft-mouton-mif-dhcpv6-drlo-00 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, 13 Sep 2011 22:18:34 -0000 Le 13/09/2011 23:27, Ted Lemon a 閏rit : > On Sep 13, 2011, at 4:51 PM, Alexandru Petrescu wrote: >> The existing implementation of draft-mouton-mif-dhcpv6-drlo-00 does >> not handle renewal. We're facing too many options about it: should >> it RENEW? Should it send an RS as well? This is up to debate. But >> it is related only to the default route, not the other routes. > > That doesn't even make sense. Why does a default route need a > lifetime, but the other routes don't? Because, most if not all IPv6 implementations come with a mandatory ND implementation. That has the notion of "default router". That default router has a mandatory lifetime field. There can be several routers on a link acting as a "default router" and their lifetime. RFC4861 syas "The Router Lifetime applies only to the router's usefulness as a default router; it does not apply to information contained in other message fields or options. Options that need [...]" in sync with lifetimes communicated by ospf. > Why do we need a default route option at all? Because it is more important than the specific routes. It must work when everything else fails. Must be distinguishable when several present; must be reliably renewed even though no global address assigned with DHCP; must be in sync with what RA does. Must tell the number of hops between Client the gw address. Etc. If some of these aspects fail the Client without a default route may be unreachable by arbitrary nodes trying to ICMP diagnose it. On another hand, a specific route incompletely specified may not do that much harm to Client. > It doesn't look like the use case you've proposed justifies this > option. Hmmm... I am not sure whether you're saying that these aspects (interface name resolution, number of hops, sync with ND/rt protocols) are necessary for all other specific routes as well. Or you're saying simply that the currrrent draft-mif is ok as it is with its way of being extended. Alex > From alexandru.petrescu@gmail.com Tue Sep 13 15:28: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 7BBA121F8CA5 for ; Tue, 13 Sep 2011 15:28:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.488 X-Spam-Level: X-Spam-Status: No, score=-2.488 tagged_above=-999 required=5 tests=[AWL=1.111, 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 l6cPzqPQEjhh for ; Tue, 13 Sep 2011 15:28:20 -0700 (PDT) Received: from mail-fx0-f44.google.com (mail-fx0-f44.google.com [209.85.161.44]) by ietfa.amsl.com (Postfix) with ESMTP id 6D47421F8CAB for ; Tue, 13 Sep 2011 15:28:12 -0700 (PDT) Received: by fxd18 with SMTP id 18so1106349fxd.31 for ; Tue, 13 Sep 2011 15:30:19 -0700 (PDT) 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:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; bh=qv3yrX/G0eRPeH31HlRTnzOk4wzf5eiXHg6l86Y07Mk=; b=nfL0ErK3IYPYmCvQi2IJBqXfq5lRXf8FNN7HXe6e23Mit0e8XhSCrnsucQLDjgYXd5 txiTOq3ysy5qQ17r416fvT4nddxpCKkRgcgtASfz/jYuSMU5/5Pj6KRX1bMJQln46ekX fJfxBJApq0piz4TX98A2mMUybB1PkzyPBEiXo= Received: by 10.223.44.90 with SMTP id z26mr143984fae.28.1315952951343; Tue, 13 Sep 2011 15:29:11 -0700 (PDT) Received: from [127.0.0.1] (bur91-3-82-239-213-32.fbx.proxad.net. [82.239.213.32]) by mx.google.com with ESMTPS id w14sm1604956fae.13.2011.09.13.15.29.09 (version=SSLv3 cipher=OTHER); Tue, 13 Sep 2011 15:29:10 -0700 (PDT) Message-ID: <4E6FD930.7040401@gmail.com> Date: Wed, 14 Sep 2011 00:29:04 +0200 From: Alexandru Petrescu User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:6.0.2) Gecko/20110902 Thunderbird/6.0.2 MIME-Version: 1.0 To: teemu.savolainen@nokia.com References: <3CF88B99A9ED504197498BC6F6F04B81040FBDA9@XMB-BGL-41E.cisco.com> <4E6E7A72.9030208@gmail.com> <4E6EAFC2.5060906@gmail.com> <4E6EDEA8.3080108@gmail.com> <4E6F825C.3080303@gmail.com> <3D0B3661-8A8F-4BB2-A8EF-25007BEAF66C@nominum.com> <4E6F923F.7090304@gmail.com> <7061CEB8-8084-41D5-B31E-9F8E3B6C7091@nominum.com> <4E6F9B91.7010503@gmail.com> <4E6FA64E.7020801@gmail.com> <82337D11-0A39-4A10-AA0E-1E81B09DBA4F@nominum.com> <4E6FACF6.5000007@viagenie.ca>, <4E6FC0AE.5000108@gmail.com> <916CE6CF87173740BC8A2CE4430969620257327E@008-AM1MPN1-032.mgdnok.nokia.com> In-Reply-To: <916CE6CF87173740BC8A2CE4430969620257327E@008-AM1MPN1-032.mgdnok.nokia.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Cc: mif@ietf.org Subject: Re: [mif] Comments on draft-mouton-mif-dhcpv6-drlo-00 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, 13 Sep 2011 22:28:24 -0000 Le 13/09/2011 23:31, teemu.savolainen@nokia.com a 閏rit : > Could you please be more specific what is this 3G+? 3G+ just as 3G is a market to end user label means of advertising more speed. Similar to what WiFi is to 802.11. > I mean use of DHCPv4 for address config is extremely rare on real > 3GPP accesses Yes, DHCP rare on 3GPP access, and IPv6 rare as well, let alone DHCPv6. In some situations I experienced DHCPv6 may provide routing configuration via WiFi to a Windows Phone also connected on 3G+. That routing configuration would need to tell the Windows Phone its IPv6 default route via the 3G+ access. > and stateful DHCPv6 for address config is not on any 3GPP spec > version (save PD) at least.. Not sure about it. I agree that PD may be in the 3GPP spec, but I am almost sure DHCPv6 is also specified by 3GPP as an alternative means to configure a Client, alternate to IPv6 stateless autoconfig. If 3GPP uses DHCPv6 to configure addresses to Clients then it may be used to configure the default route as well, for more efficiency. Alex > Sent from my Windows Phone > ------------------------------------------------------------------------ > > > > From: ext Alexandru Petrescu > Sent: 13.9.2011 23:44 To: mif@ietf.org Subject: Re: [mif] Comments on > draft-mouton-mif-dhcpv6-drlo-00 > > Le 13/09/2011 21:20, Simon Perreault a 閏rit : >> Ted Lemon wrote, on 09/13/2011 03:15 PM: >>> Also, I'm a bit confused by the idea of an interface route with >>> no router address in IPv6. I will admit to being something of a >>> tyro when it comes to these things, but I don't understand how >>> that would work. Does the client simply multicast every packet? >>> Is there an RFC or draft that documents how this works? >> >> I'm guessing that's a point-to-point interface. So you don't need >> the next hop's L2 address. You just send it down the tube and it >> gets at the other end. The classic example is PPP. > > YEs, it is a "no ARP" interface, but in some 3G+ it is not PPP. > > Yes, the client just sends it down the tube. > > But no, the Client can't set up that default route when all is being > given is "0.0.0.0". It must tell the interface name. The Client by > itself is not capable to decide how to insert that default router > entry in its routing table, it just can't solve "0.0.0.0" on some > interface name so it must be told the interface name by some spec or > mechanism. > > Alex > >> >> Simon > > _______________________________________________ mif mailing list > mif@ietf.org https://www.ietf.org/mailman/listinfo/mif From alexandru.petrescu@gmail.com Tue Sep 13 15:43: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 95A2D21F8CDE for ; Tue, 13 Sep 2011 15:43:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.543 X-Spam-Level: X-Spam-Status: No, score=-2.543 tagged_above=-999 required=5 tests=[AWL=1.056, 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 JKAA-2sxGZYA for ; Tue, 13 Sep 2011 15:43:59 -0700 (PDT) Received: from mail-fx0-f44.google.com (mail-fx0-f44.google.com [209.85.161.44]) by ietfa.amsl.com (Postfix) with ESMTP id C25B721F8CDB for ; Tue, 13 Sep 2011 15:43:58 -0700 (PDT) Received: by fxd18 with SMTP id 18so1115724fxd.31 for ; Tue, 13 Sep 2011 15:46:05 -0700 (PDT) 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:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; bh=ydvkHFDjjghJLMLnGY+iqP8xfPil7SLNLCt1+pWbRMQ=; b=vpKMXX2clVwPBFcNnsOMP3lVKHENI3cucm8ZLW3CrKSdQuKFLbz1Gh6lgd6KLbDgyd f3xm7DDPJHVYmayetwq9lx9h8OTMpfTyQ/E4XcOfV/JO5vEQQHH40F9rPYT4/qhwdfhR mvEDOtNSXbOl3b6pBVY/llOsFOU645jCnaVkk= Received: by 10.223.5.155 with SMTP id 27mr154050fav.90.1315953965583; Tue, 13 Sep 2011 15:46:05 -0700 (PDT) Received: from [127.0.0.1] (bur91-3-82-239-213-32.fbx.proxad.net. [82.239.213.32]) by mx.google.com with ESMTPS id c2sm1631365faf.16.2011.09.13.15.46.03 (version=SSLv3 cipher=OTHER); Tue, 13 Sep 2011 15:46:04 -0700 (PDT) Message-ID: <4E6FDD26.4070206@gmail.com> Date: Wed, 14 Sep 2011 00:45:58 +0200 From: Alexandru Petrescu User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:6.0.2) Gecko/20110902 Thunderbird/6.0.2 MIME-Version: 1.0 To: Ted Lemon References: <3CF88B99A9ED504197498BC6F6F04B81040FBDA9@XMB-BGL-41E.cisco.com> <4E6E7A72.9030208@gmail.com> <4E6EAFC2.5060906@gmail.com> <4E6EDEA8.3080108@gmail.com> <4E6F825C.3080303@gmail.com> <3D0B3661-8A8F-4BB2-A8EF-25007BEAF66C@nominum.com> <4E6F923F.7090304@gmail.com> <7061CEB8-8084-41D5-B31E-9F8E3B6C7091@nominum.com> <4E6F9B91.7010503@gmail.com> <4E6FA049.1040309@viagenie.ca> <4E6FC41E.6010002@gmail.com> <10031B1F-30BC-4475-8866-C21CD4E1E819@nominum.com> In-Reply-To: <10031B1F-30BC-4475-8866-C21CD4E1E819@nominum.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Cc: "" Subject: Re: [mif] Comments on draft-mouton-mif-dhcpv6-drlo-00 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, 13 Sep 2011 22:43:59 -0000 Le 13/09/2011 23:31, Ted Lemon a 閏rit : > On Sep 13, 2011, at 4:59 PM, Alexandru Petrescu wrote: >> One particular use case is: > > Sorry, to be clear, a use case is an example of usage that requires > new protocol action, because existing functionality cannot address > the use case. The use case is a wifi-3G phone whose default route is provided by DHCP on WiFi and must point to a virtual interface - current spec does not allow for it. Must also be expirable at the same time as ND - current spec does not allow for it. > Use cases have to be real, concrete things, not hypotheticals. Protocol specs must be coherent in text and not hypotheticals either. Or, current spec says "Each IPv6 route consists of an IPv6 next hop address, an IPv6 destination prefix (a.k.a. the destination subnet), and a host preference value for the route." There is no preference in the draft. And, non-hypothetical IPv6 routes consist in more than nexthop, dstprefix, preference. Examples are: number of hops to reach that nexthop, interface name and lifetimes. Protocol specs should be implementable. Ideally, one would take the implementation and write the draft literally after it; and less ideally the other way around. > I can always make up a hypothetical example to justify any sort of > protocol extension, but if there is no real-world use case that > requires it, all the work of doing that protocol extension is > wasted. The use cases I have described are all hands-on that I have experimented several times. They are not hypotheticals. > What you've given in this particular message are a couple of > examples of how the option could be used. These are not relevant use > cases, because they could also be addressed with the existing > proposed option. That is, they do not motivate additional work. The proposed option is incomplete, not implemented, and missing some reference to existing base. It is difficult to suggest improvements to it because it takes a wrong direction. We have made some suggestions, and we did discuss f2f a few times, and we are thankful for having taken some of our comments; but not all messages get through. This is one reason we suggest a different option for default route. Alex > From denghui02@hotmail.com Tue Sep 13 18:00: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 4698F11E808A for ; Tue, 13 Sep 2011 18:00:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.598 X-Spam-Level: X-Spam-Status: No, score=-102.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vl5wwhxy1-S0 for ; Tue, 13 Sep 2011 18:00:43 -0700 (PDT) Received: from col0-omc1-s13.col0.hotmail.com (col0-omc1-s13.col0.hotmail.com [65.55.34.23]) by ietfa.amsl.com (Postfix) with ESMTP id 9027D11E8083 for ; Tue, 13 Sep 2011 18:00:43 -0700 (PDT) Received: from COL118-W4 ([65.55.34.8]) by col0-omc1-s13.col0.hotmail.com with Microsoft SMTPSVC(6.0.3790.4675); Tue, 13 Sep 2011 18:02:48 -0700 Message-ID: Content-Type: multipart/alternative; boundary="_f1d5e4ed-d05c-4580-964f-f6e60b0d63ca_" X-Originating-IP: [121.15.129.73] From: Hui Deng To: Margaret , Date: Wed, 14 Sep 2011 09:02:47 +0800 Importance: Normal In-Reply-To: <37CF81A7-B249-40EB-B8E6-A706680C4174@gmail.com> References: <4E683F9B.7020905@gmail.com>, <37CF81A7-B249-40EB-B8E6-A706680C4174@gmail.com> MIME-Version: 1.0 X-OriginalArrivalTime: 14 Sep 2011 01:02:48.0688 (UTC) FILETIME=[0544E700:01CC727A] Cc: mif@ietf.org Subject: Re: [mif] Last Call for MIF DNS server selection document 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, 14 Sep 2011 01:00:44 -0000 --_f1d5e4ed-d05c-4580-964f-f6e60b0d63ca_ Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: 8bit Hi Margaret, I have seen the draft updated for 04 version, this has been a not small changes, we may can make a last call again for the new draft posting across multiple working groups such as MIF, DNSEXT and DNSOP, require theirs review? Anyway, Andrew and Keith have already made lots of significant comments about alignment with Internet DNS architecture. -Hui > Subject: Re: [mif] Last Call for MIF DNS server selection document > From: margaretw42@gmail.com > Date: Tue, 13 Sep 2011 08:00:09 -0400 > CC: denghui02@hotmail.com; mif@ietf.org; jari.arkko@piuha.net > To: brian.e.carpenter@gmail.com > > > Hi Brian, > > On Sep 8, 2011, at 12:07 AM, Brian E Carpenter wrote: > > Has this document been reviewed in DNSEXT and DNSOP? > > No, but this is a good thought... I will talk to Jari and Hui about how best to get good review of this draft by DNS experts. I'm not sure if we should just send mail to the DNSEXT and DNSOP WGs, or if we should ask for a DNS Directorate review. Jari and Hui, what do you think? > > > If not, I would strongly recommend that before asking the AD > > to review it in detail. I would expect considerable discussion of > > the following text and its consequences: > > > >> In deployments where multiple namespaces are present, selection of > >> correct route and destination and source addresses for the actual IP > >> connection is crucial as well, as the resolved destination's IP > >> addresses may be only usable on the network interface over which the > >> name was resolved on. > > I think there is a lot more acceptance, now, that these sorts of deployments do exist in the real world and need to be handled properly (otherwise they cause real-world problems) than there used to be in the IETF in the past. We'll see how the discussion goes, but I'm expecting a lot less controversy on this point than we would have seen 5+ years ago. > > Margaret > > --_f1d5e4ed-d05c-4580-964f-f6e60b0d63ca_ Content-Type: text/html; charset="gb2312" Content-Transfer-Encoding: 8bit

Hi Margaret,

 

I have seen the draft updated for 04 version, this has been a not small changes, we may can make a last call again for the new draft posting across multiple working groups such as MIF, DNSEXT and DNSOP, require theirs review?

 

Anyway, Andrew and Keith have already made lots of significant comments about alignment with Internet DNS architecture.

 

-Hui


 
> Subject: Re: [mif] Last Call for MIF DNS server selection document
> From: margaretw42@gmail.com
> Date: Tue, 13 Sep 2011 08:00:09 -0400
> CC: denghui02@hotmail.com; mif@ietf.org; jari.arkko@piuha.net
> To: brian.e.carpenter@gmail.com
>
>
> Hi Brian,
>
> On Sep 8, 2011, at 12:07 AM, Brian E Carpenter wrote:
> > Has this document been reviewed in DNSEXT and DNSOP?
>
> No, but this is a good thought... I will talk to Jari and Hui about how best to get good review of this draft by DNS experts. I'm not sure if we should just send mail to the DNSEXT and DNSOP WGs, or if we should ask for a DNS Directorate review. Jari and Hui, what do you think?
>
> > If not, I would strongly recommend that before asking the AD
> > to review it in detail. I would expect considerable discussion of
> > the following text and its consequences:
> >
> >> In deploym ents where multiple namespaces are present, selection of
> >> correct route and destination and source addresses for the actual IP
> >> connection is crucial as well, as the resolved destination's IP
> >> addresses may be only usable on the network interface over which the
> >> name was resolved on.
>
> I think there is a lot more acceptance, now, that these sorts of deployments do exist in the real world and need to be handled properly (otherwise they cause real-world problems) than there used to be in the IETF in the past. We'll see how the discussion goes, but I'm expecting a lot less controversy on this point than we would have seen 5+ years ago.
>
> Margaret
>
>
--_f1d5e4ed-d05c-4580-964f-f6e60b0d63ca_-- From margaretw42@gmail.com Tue Sep 13 19:03: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 740F021F8BDC for ; Tue, 13 Sep 2011 19:03:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.264 X-Spam-Level: X-Spam-Status: No, score=-2.264 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HTML_MESSAGE=0.001, IP_NOT_FRIENDLY=0.334] 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 Pikx4NwUk0Xo for ; Tue, 13 Sep 2011 19:03:35 -0700 (PDT) Received: from mail.suchdamage.org (permutation-city.suchdamage.org [69.25.196.28]) by ietfa.amsl.com (Postfix) with ESMTP id 85C4F21F8BBE for ; Tue, 13 Sep 2011 19:03:35 -0700 (PDT) Received: from [10.36.0.36] (pool-108-7-232-64.bstnma.fios.verizon.net [108.7.232.64]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (Client did not present a certificate) by mail.suchdamage.org (Postfix) with ESMTPSA id 90F6F203BA; Tue, 13 Sep 2011 22:07:34 -0400 (EDT) Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: multipart/alternative; boundary=Apple-Mail-23-503807004 From: Margaret Wasserman In-Reply-To: Date: Tue, 13 Sep 2011 22:05:39 -0400 Message-Id: <4BD05B04-DB10-47A7-855F-6AAB8EF7646D@gmail.com> References: <4E683F9B.7020905@gmail.com>, <37CF81A7-B249-40EB-B8E6-A706680C4174@gmail.com> To: Hui Deng X-Mailer: Apple Mail (2.1084) Cc: mif@ietf.org Subject: Re: [mif] Last Call for MIF DNS server selection document 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, 14 Sep 2011 02:03:36 -0000 --Apple-Mail-23-503807004 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Posting the new version ASAP, and having a new LC for the new version = makes sense to me. Maybe we should talk to the DNSEXT and DNSOP chairs before sending the = LC to their mailing lists, to see what they think? Margaret On Sep 13, 2011, at 9:02 PM, Hui Deng wrote: > Hi Margaret, > =20 > I have seen the draft updated for 04 version, this has been a not = small changes, we may can make a last call again for the new draft = posting across multiple working groups such as MIF, DNSEXT and DNSOP, = require theirs review? > =20 > Anyway, Andrew and Keith have already made lots of significant = comments about alignment with Internet DNS architecture. > =20 > -Hui >=20 > =20 > > Subject: Re: [mif] Last Call for MIF DNS server selection document > > From: margaretw42@gmail.com > > Date: Tue, 13 Sep 2011 08:00:09 -0400 > > CC: denghui02@hotmail.com; mif@ietf.org; jari.arkko@piuha.net > > To: brian.e.carpenter@gmail.com > >=20 > >=20 > > Hi Brian, > >=20 > > On Sep 8, 2011, at 12:07 AM, Brian E Carpenter wrote: > > > Has this document been reviewed in DNSEXT and DNSOP? > >=20 > > No, but this is a good thought... I will talk to Jari and Hui about = how best to get good review of this draft by DNS experts. I'm not sure = if we should just send mail to the DNSEXT and DNSOP WGs, or if we should = ask for a DNS Directorate review. Jari and Hui, what do you think? > >=20 > > > If not, I would strongly recommend that before asking the AD > > > to review it in detail. I would expect considerable discussion of > > > the following text and its consequences: > > >=20 > > >> In deployments where multiple namespaces are present, selection = of > > >> correct route and destination and source addresses for the actual = IP > > >> connection is crucial as well, as the resolved destination's IP > > >> addresses may be only usable on the network interface over which = the > > >> name was resolved on. > >=20 > > I think there is a lot more acceptance, now, that these sorts of = deployments do exist in the real world and need to be handled properly = (otherwise they cause real-world problems) than there used to be in the = IETF in the past. We'll see how the discussion goes, but I'm expecting a = lot less controversy on this point than we would have seen 5+ years ago. > >=20 > > Margaret > >=20 > >=20 --Apple-Mail-23-503807004 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii

Posting the new version ASAP, and = having a new LC for the new version makes sense to = me.

Maybe we should talk to the DNSEXT and DNSOP = chairs before sending the LC to their mailing lists, to see what they = think?

Margaret

On Sep = 13, 2011, at 9:02 PM, Hui Deng wrote:

Hi = Margaret,
 
I = have seen the draft updated for 04 version, this has been a not small = changes, we may can make a last call again for the new draft = posting across multiple working groups such as MIF, DNSEXT and = DNSOP, require theirs review?

 

Anyway, Andrew = and Keith have already made lots of significant comments about alignment = with Internet DNS = architecture.
 
-Hui

 
<= div>> Subject: Re: [mif] Last Call for MIF DNS server selection = document
> From: margaretw42@gmail.com
> = Date: Tue, 13 Sep 2011 08:00:09 -0400
> CC: denghui02@hotmail.com; mif@ietf.org; jari.arkko@piuha.net
> = To: brian.e.carpenter@gmail.com
> 
> 
> Hi = Brian,
> 
> = On Sep 8, 2011, at 12:07 AM, Brian E Carpenter wrote:
> > Has = this document been reviewed in DNSEXT and DNSOP?
> 
> No, but this is a = good thought... I will talk to Jari and Hui about how best to get good = review of this draft by DNS experts. I'm not sure if we should just send = mail to the DNSEXT and DNSOP WGs, or if we should ask for a DNS = Directorate review. Jari and Hui, what do you think?
> 
> > If not, I = would strongly recommend that before asking the AD
> > to = review it in detail. I would expect considerable discussion of
> = > the following text and its consequences:
> > 
> >> In = deployments where multiple namespaces are present, selection of
> = >> correct route and destination and source addresses for the = actual IP
> >> connection is crucial as well, as the = resolved destination's IP
> >> addresses may be only usable = on the network interface over which the
> >> name was = resolved on.
> 
> I think there is a = lot more acceptance, now, that these sorts of deployments do exist in = the real world and need to be handled properly (otherwise they cause = real-world problems) than there used to be in the IETF in the past. = We'll see how the discussion goes, but I'm expecting a lot less = controversy on this point than we would have seen 5+ years = ago.
> 
> = Margaret
> 
> 
=
= --Apple-Mail-23-503807004-- From Ted.Lemon@nominum.com Tue Sep 13 19:38: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 BD6D021F8C3D for ; Tue, 13 Sep 2011 19:38:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.594 X-Spam-Level: X-Spam-Status: No, score=-106.594 tagged_above=-999 required=5 tests=[AWL=0.004, 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 XjZVkADCsPhY for ; Tue, 13 Sep 2011 19:38:31 -0700 (PDT) Received: from exprod7og127.obsmtp.com (exprod7og127.obsmtp.com [64.18.2.210]) by ietfa.amsl.com (Postfix) with ESMTP id 1D48921F8C1C for ; Tue, 13 Sep 2011 19:38:31 -0700 (PDT) Received: from shell-too.nominum.com ([64.89.228.229]) (using TLSv1) by exprod7ob127.postini.com ([64.18.6.12]) with SMTP ID DSNKTnAUIBUCxSyoL0qAdnlk645xmM9zP28l@postini.com; Tue, 13 Sep 2011 19:40:39 PDT Received: from archivist.nominum.com (archivist.nominum.com [64.89.228.108]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "*.nominum.com", Issuer "Go Daddy Secure Certification Authority" (verified OK)) by shell-too.nominum.com (Postfix) with ESMTP id E8683F8022 for ; Tue, 13 Sep 2011 19:40:31 -0700 (PDT) Received: from webmail.nominum.com (cas-01.win.nominum.com [64.89.228.131]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (Client CN "mail.nominum.com", Issuer "Go Daddy Secure Certification Authority" (verified OK)) by archivist.nominum.com (Postfix) with ESMTPS id D1B05190065; Tue, 13 Sep 2011 19:40:30 -0700 (PDT) (envelope-from Ted.Lemon@nominum.com) Received: from MBX-01.WIN.NOMINUM.COM ([64.89.228.133]) by CAS-01.WIN.NOMINUM.COM ([64.89.228.131]) with mapi id 14.01.0323.003; Tue, 13 Sep 2011 19:40:31 -0700 From: Ted Lemon To: Margaret Wasserman Thread-Topic: [mif] Last Call for MIF DNS server selection document Thread-Index: AQHMZh210eh69oD+y0+3nspEpxu1BZVDYuKAgAhfmYCAANqqgIAAEZGAgAAJu4A= Date: Wed, 14 Sep 2011 02:40:29 +0000 Message-ID: <1F1C4F83-CE15-4656-A752-B0307F8F97B4@nominum.com> References: <4E683F9B.7020905@gmail.com>, <37CF81A7-B249-40EB-B8E6-A706680C4174@gmail.com> <4BD05B04-DB10-47A7-855F-6AAB8EF7646D@gmail.com> In-Reply-To: <4BD05B04-DB10-47A7-855F-6AAB8EF7646D@gmail.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [173.162.214.218] Content-Type: multipart/alternative; boundary="_000_1F1C4F83CE154656A752B0307F8F97B4nominumcom_" MIME-Version: 1.0 Cc: "" , Hui Deng Subject: Re: [mif] Last Call for MIF DNS server selection document 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, 14 Sep 2011 02:38:31 -0000 --_000_1F1C4F83CE154656A752B0307F8F97B4nominumcom_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable On Sep 13, 2011, at 10:05 PM, Margaret Wasserman wrote: Maybe we should talk to the DNSEXT and DNSOP chairs before sending the LC t= o their mailing lists, to see what they think? Also, sorry to say, probably DHC, since it's a DHCP option. --_000_1F1C4F83CE154656A752B0307F8F97B4nominumcom_ Content-Type: text/html; charset="us-ascii" Content-ID: <29B88F4579595A4AA5E78D5E67A78D00@nominum.com> Content-Transfer-Encoding: quoted-printable
On Sep 13, 2011, at 10:05 PM, Margaret Wasserman wrote:
Maybe we should talk to the DNSEXT and DNSOP chairs before sending the= LC to their mailing lists, to see what they think?

Also, sorry to say, probably DHC, since it's a DHCP option.


--_000_1F1C4F83CE154656A752B0307F8F97B4nominumcom_-- From denghui02@hotmail.com Tue Sep 13 19:39: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 51BBB21F8C46 for ; Tue, 13 Sep 2011 19:39:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.598 X-Spam-Level: X-Spam-Status: No, score=-102.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9i-RIla7fJnu for ; Tue, 13 Sep 2011 19:39:11 -0700 (PDT) Received: from col0-omc2-s6.col0.hotmail.com (col0-omc2-s6.col0.hotmail.com [65.55.34.80]) by ietfa.amsl.com (Postfix) with ESMTP id 68D7621F8C42 for ; Tue, 13 Sep 2011 19:39:11 -0700 (PDT) Received: from COL118-W48 ([65.55.34.73]) by col0-omc2-s6.col0.hotmail.com with Microsoft SMTPSVC(6.0.3790.4675); Tue, 13 Sep 2011 19:41:19 -0700 Message-ID: Content-Type: multipart/alternative; boundary="_9e7b7058-e99f-4d27-b072-9548409b9297_" X-Originating-IP: [121.15.129.73] From: Hui Deng To: , Margaret Date: Wed, 14 Sep 2011 10:41:18 +0800 Importance: Normal In-Reply-To: <1F1C4F83-CE15-4656-A752-B0307F8F97B4@nominum.com> References: , <4E683F9B.7020905@gmail.com>, , <37CF81A7-B249-40EB-B8E6-A706680C4174@gmail.com>, , <4BD05B04-DB10-47A7-855F-6AAB8EF7646D@gmail.com>, <1F1C4F83-CE15-4656-A752-B0307F8F97B4@nominum.com> MIME-Version: 1.0 X-OriginalArrivalTime: 14 Sep 2011 02:41:19.0976 (UTC) FILETIME=[C8ABDE80:01CC7287] Cc: mif@ietf.org Subject: Re: [mif] Last Call for MIF DNS server selection document 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, 14 Sep 2011 02:39:12 -0000 --_9e7b7058-e99f-4d27-b072-9548409b9297_ Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: 8bit Sure, thanks Ted -Hui From: Ted.Lemon@nominum.com To: margaretw42@gmail.com CC: denghui02@hotmail.com; mif@ietf.org Subject: Re: [mif] Last Call for MIF DNS server selection document Date: Wed, 14 Sep 2011 02:40:29 +0000 On Sep 13, 2011, at 10:05 PM, Margaret Wasserman wrote: Maybe we should talk to the DNSEXT and DNSOP chairs before sending the LC to their mailing lists, to see what they think? Also, sorry to say, probably DHC, since it's a DHCP option. --_9e7b7058-e99f-4d27-b072-9548409b9297_ Content-Type: text/html; charset="gb2312" Content-Transfer-Encoding: 8bit
Sure, thanks Ted
 
-Hui
 
From: Ted.Lemon@nominum.com
To: margaretw42@gmail.com
CC: denghui02@hotmail.com; mif@ietf.org
Subject: Re: [mif] Last Call for MIF DNS server selection document
Date: Wed, 14 Sep 2011 02:40:29 +0000

On Sep 13, 2011, at 10:05 PM, Margaret Wasserman wrote:
Maybe we should talk to the DNSEXT and DNSOP chairs before sending the LC to their mailing lists, to see what they think?

Also, sorry to say, probably DHC, since it's a DHCP option.


--_9e7b7058-e99f-4d27-b072-9548409b9297_-- From ajs@anvilwalrusden.com Tue Sep 13 22:49:33 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 AC80A21F8C74 for ; Tue, 13 Sep 2011 22:49:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.98 X-Spam-Level: X-Spam-Status: No, score=-1.98 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_SORBS_WEB=0.619] 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 8bVHWQqPYQQO for ; Tue, 13 Sep 2011 22:49:33 -0700 (PDT) Received: from mail.yitter.info (mail.yitter.info [208.86.224.201]) by ietfa.amsl.com (Postfix) with ESMTP id DF13621F8C66 for ; Tue, 13 Sep 2011 22:49:32 -0700 (PDT) Received: from shinkuro.com (unknown [89.211.51.194]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.yitter.info (Postfix) with ESMTPSA id 7B7AE1ECB41C for ; Wed, 14 Sep 2011 05:51:37 +0000 (UTC) Date: Wed, 14 Sep 2011 01:51:35 -0400 From: Andrew Sullivan To: mif@ietf.org Message-ID: <20110914054256.GC78623@shinkuro.com> References: <4E683F9B.7020905@gmail.com> <37CF81A7-B249-40EB-B8E6-A706680C4174@gmail.com> <4BD05B04-DB10-47A7-855F-6AAB8EF7646D@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4BD05B04-DB10-47A7-855F-6AAB8EF7646D@gmail.com> User-Agent: Mutt/1.5.21 (2010-09-15) Subject: Re: [mif] Last Call for MIF DNS server selection document 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, 14 Sep 2011 05:49:33 -0000 On Tue, Sep 13, 2011 at 10:05:39PM -0400, Margaret Wasserman wrote: > > Maybe we should talk to the DNSEXT and DNSOP chairs before sending the LC to their mailing lists, to see what they think? > I did in fact send a note to the dnsext list asking people to come over here and review or comment. AFAIK, this had no effect, but I could be wrong. If you want us to run a formal LC on the document in dnsext, I'm certainly willing to do it. Note that we have a policy that we need at least five positive reviews (this is a necessary but not sufficient condition) for WG consensus in favour to be declared, and we have had serious problems in DNSEXT in getting sufficient review even for documents we have actually adopted as WG items. So be careful what you ask for. A -- Andrew Sullivan ajs@anvilwalrusden.com From teemu.savolainen@nokia.com Tue Sep 13 23:08: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 5E9C021F8CA2 for ; Tue, 13 Sep 2011 23:08:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.679 X-Spam-Level: X-Spam-Status: No, score=-2.679 tagged_above=-999 required=5 tests=[AWL=-0.080, 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 WTLow8MincKM for ; Tue, 13 Sep 2011 23:08:56 -0700 (PDT) Received: from mgw-sa01.nokia.com (smtp.nokia.com [147.243.1.47]) by ietfa.amsl.com (Postfix) with ESMTP id 774DA21F8C9F for ; Tue, 13 Sep 2011 23:08:56 -0700 (PDT) Received: from vaebh102.NOE.Nokia.com (vaebh102.europe.nokia.com [10.160.244.23]) by mgw-sa01.nokia.com (Switch-3.4.4/Switch-3.4.3) with ESMTP id p8E6B1l8003616; Wed, 14 Sep 2011 09:11:02 +0300 Received: from smtp.mgd.nokia.com ([65.54.30.7]) by vaebh102.NOE.Nokia.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.4675); Wed, 14 Sep 2011 09:10:38 +0300 Received: from 008-AM1MMR1-001.mgdnok.nokia.com (65.54.30.56) by NOK-AM1MHUB-03.mgdnok.nokia.com (65.54.30.7) with Microsoft SMTP Server (TLS) id 8.2.255.0; Wed, 14 Sep 2011 08:10:38 +0200 Received: from 008-AM1MPN1-032.mgdnok.nokia.com ([169.254.2.143]) by 008-AM1MMR1-001.mgdnok.nokia.com ([65.54.30.56]) with mapi id 14.01.0323.007; Wed, 14 Sep 2011 08:08:11 +0200 From: To: Thread-Topic: [mif] Comments on draft-mouton-mif-dhcpv6-drlo-00 Thread-Index: AQHMclXvmeatSbe770ilB6P1NUlbCpVL1DV4///urQCAAJ4CcA== Date: Wed, 14 Sep 2011 06:08:11 +0000 Message-ID: <916CE6CF87173740BC8A2CE443096962025734A7@008-AM1MPN1-032.mgdnok.nokia.com> References: <3CF88B99A9ED504197498BC6F6F04B81040FBDA9@XMB-BGL-41E.cisco.com> <4E6E7A72.9030208@gmail.com> <4E6EAFC2.5060906@gmail.com> <4E6EDEA8.3080108@gmail.com> <4E6F825C.3080303@gmail.com> <3D0B3661-8A8F-4BB2-A8EF-25007BEAF66C@nominum.com> <4E6F923F.7090304@gmail.com> <7061CEB8-8084-41D5-B31E-9F8E3B6C7091@nominum.com> <4E6F9B91.7010503@gmail.com> <4E6FA64E.7020801@gmail.com> <82337D11-0A39-4A10-AA0E-1E81B09DBA4F@nominum.com> <4E6FACF6.5000007@viagenie.ca>,<4E6FC0AE.5000108@gmail.com> <916CE6CF87173740BC8A2CE4430969620257327E@008-AM1MPN1-032.mgdnok.nokia.com> <4E6FD930.7040401@gmail.com> In-Reply-To: <4E6FD930.7040401@gmail.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes 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+/nZJb9Kg7IuZuBXX/gTPnV8RRCmXgbNBLv+s+z8dze93E2y5N3eQswSwwwxgghs89TU1NiT1JcwoYrWJF1mZc/NrOJDhIyVOXH9EPAg712fNqHrpoDEsvuRlOS1hSiwqJBl/y+vrUMbNcSOiAMcMwyx351Sa6Z/IFSlHIhsBMoR40FyewYK3KCsi7Yxw68v+kP9DvNAmUZxPlsGYqXedFJIa5k15Bm0XdsxKvBnVcmuxqzTj4b4GDU4EfHLLHaH9VmYnqNFtQ0A== x-originating-ip: [10.162.78.119] Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=SHA1; boundary="----=_NextPart_000_00DB_01CC72BD.D1FE4870" MIME-Version: 1.0 X-OriginalArrivalTime: 14 Sep 2011 06:10:38.0796 (UTC) FILETIME=[064FB8C0:01CC72A5] X-Nokia-AV: Clean Cc: mif@ietf.org Subject: Re: [mif] Comments on draft-mouton-mif-dhcpv6-drlo-00 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, 14 Sep 2011 06:08:57 -0000 ------=_NextPart_000_00DB_01CC72BD.D1FE4870 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit > 3G+ just as 3G is a market to end user label means of advertising more > speed. Similar to what WiFi is to 802.11. Ok, so referring to 3GPP technologies I assume (not WiMAX for example). > In some situations I experienced DHCPv6 may provide routing configuration > via WiFi to a Windows Phone also connected on 3G+. That routing > configuration would need to tell the Windows Phone its IPv6 default route > via the 3G+ access. Do you mean the WiFi access would explicitly spell out 3G as the default route for a node, or indirectly by the WiFi access telling it is low priority default route (ref RFC4191) - and hence suggesting using some other interfaces by default instead? > Not sure about it. I agree that PD may be in the 3GPP spec, but I am almost > sure DHCPv6 is also specified by 3GPP as an alternative means to configure a > Client, alternate to IPv6 stateless autoconfig. I am absolutely sure 3GPP as of today does not specify Stateful DHCPv6 as an option to configure client's WAN interface addresses on cellular interface. There is only Prefix Delegation in Release-10, but even in Rel-10 case client's WAN interface address is always configured with SLAAC. (Ref 3GPP 23.060 and 23.401 for more details). I have to say I don't recall immediately what 3GPP specs says about client configuration on trusted WLANs (but I would except also only SLAAC there as well, otherwise things like netext's logical interface might be even bigger challenges to get working). > If 3GPP uses DHCPv6 to configure addresses to Clients then it may be used to > configure the default route as well, for more efficiency. It is true that DHCPv6 can be used to configure additional information (stateless DHCPv6). Hence yes, specific routes and even maybe default route could be configured via DHCPv6... but I don't see why default route would be, as the Router Advertisements used by SLAAC already provide default route information. Best regards, Teemu ------=_NextPart_000_00DB_01CC72BD.D1FE4870 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIOuzCCAzYw ggIeoAMCAQICBDpVqdkwDQYJKoZIhvcNAQEFBQAwKTEOMAwGA1UEChMFTm9raWExFzAVBgNVBAMT Dk5va2lhICBSb290IENBMB4XDTAxMDEwNTExMDUwNVoXDTE2MDEwMjExMDUwNVowKTEOMAwGA1UE ChMFTm9raWExFzAVBgNVBAMTDk5va2lhICBSb290IENBMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8A MIIBCgKCAQEAsrTy8gLmr4LYvp0khVUVHw7ascdl+Cjr+yI5MlZ6J/U6Qsvkiqthgqq8rPcLV0P1 92TfBr27VgKEeCaZe0icS1jC2spM/wRv3j2WxdkKxb9kDJtuCNJaRBqvi5vGTHB15nmEmKuL5f3i rAxeHqPjgS496oWcudzFT1e7Xrc/gWGFYd72+/ykIFXjWOMZv6QpxD8x1hLPyh2YVXRk9U7N7pvm RQNX29g4SCFJY2BBIa5JPlwIF8Nc9IePaC/E/2M4tGMtiOOZlm99EoL7N0hJZtFSvUwdCBud/viH 4DgsKGjNkNKi6pAHc9IaXB6tIykcoYp+L+oe/3+cuEJaCj1EKwIDAQABo2YwZDASBgNVHRMBAf8E CDAGAQH/AgEEMB0GA1UdDgQWBBSNjfefoQ0AITLvqe0iruA79NB9sDAfBgNVHSMEGDAWgBSNjfef oQ0AITLvqe0iruA79NB9sDAOBgNVHQ8BAf8EBAMCAYYwDQYJKoZIhvcNAQEFBQADggEBAIGEPql2 TALyKi/h1J+Mh5XolAtYppcSOLMtBkoA7ZovGBDNvl0VbZs8AAojJqkUoWBB+L6DKyl/jKhNfKcu rWRGRyj7pnbxrKLsI3gmWNWkyo2b60wJwe9fqPD5ZQy3oEiMit9l0Ba6il/k2GqYopUCNMa7mfeb E2LeBy5ChYMiCi97UQSJvAdzEYylTJw8Awc6AiM2Ve5N+XxsmKgNf/2A/5IJ3EZZ+wFRmkI4062A oNU302rqAt0HH88jzoUF4AfYHWl6HpYhGXFbcX44rHINyPmFBRxLYIFJ6ZWUr/mXpL/e6rqFtNWO kV6UoJND7OVZkbLh7F1+lcqXRU8TPBMwggOHMIICb6ADAgECAgRBtbHpMA0GCSqGSIb3DQEBBQUA MCkxDjAMBgNVBAoTBU5va2lhMRcwFQYDVQQDEw5Ob2tpYSAgUm9vdCBDQTAeFw0wNjAzMzAwOTU3 MTFaFw0xNjAxMDIxMTA1MDVaMDMxCzAJBgNVBAYTAkZJMQ4wDAYDVQQKEwVOb2tpYTEUMBIGA1UE AxMLTm9raWEgQkkgQ0EwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQDtFCg3QEjSCg6T IUxoWsNwELh8bBNiUQPCPmg8c2DHQYXWWCSCMb+S0Fvh1qqI1xt+XnzyFq+5eqzGzDj4UaBcG+d9 qxrCFly8sHyoPTryyPrR0EI2UUDWwfS6ojhqgwghRqo8G38TjFusyBtLub/5L6yvWYSOHD+JcB+q VM2fbkArPYK4Ydv8WG/DbHjGn0gKq0zwpVZKI/gCK/QALYvte02NXseqvY9/GOyLtjy3Z8erFv71 KKTq+gxI/7DK55pJf3PoD+kT4kyGm6EF9DTdK4ojMdar17uyX0IOZz/4vkkF0d+60nmnLX63FJPA jUyB0HUNJ32NXDo9UsM38aoNAgMBAAGjgawwgakwDwYDVR0TAQH/BAUwAwEB/zARBgNVHSAECjAI MAYGBFUdIAAwDgYDVR0PAQH/BAQDAgGGMFQGA1UdIwRNMEuAFI2N95+hDQAhMu+p7SKu4Dv00H2w oS2kKzApMQ4wDAYDVQQKEwVOb2tpYTEXMBUGA1UEAxMOTm9raWEgIFJvb3QgQ0GCBDpVqdkwHQYD VR0OBBYEFKcksD7Fg+8EDlB2Sxgy58pW0Sy6MA0GCSqGSIb3DQEBBQUAA4IBAQAC3lEUplDlVNOT Pjz/XFezXx2bV2XbCFindhA3F815Egi55H6/cYezEjoP4QLNEGGl2I3aLvkn5A0T8I4pbiFPhIiu B/frbbGg6k6GjQLe/bFQ8F1mAOOR+GyneKZFPfzaRV0jiIR9QqnMXTf8RvKkCJyFj10MZVsLIy/Y uBkzeP3JhzDhUdtPfwmJN6ZbIhH5uR/2BwAGtgQknb8WX3I4wnhWtMUxB8XmayayYs8qWYeIiVkI FV+sLTkWUWVvvKUjyakBpbAW2vUP84DYsJ8TL1YefNjf/nIOByMcORLuV/1gPjyv00qJbcB59AA+ iXe3zIo8QNcgXG0uPQQFmrGDMIID5DCCAsygAwIBAgIQMH5apak8lEy6LmLlLsJy8TANBgkqhkiG 9w0BAQUFADAzMQswCQYDVQQGEwJGSTEOMAwGA1UEChMFTm9raWExFDASBgNVBAMTC05va2lhIEJJ IENBMB4XDTExMDkwNjA1NTIwNFoXDTE0MDkwNjA1NTIwNFowVjEOMAwGA1UECgwFTm9raWExDzAN BgNVBAsMBlBlb3BsZTEYMBYGCgmSJomT8ixkAQEMCDEwMDI0Njc2MRkwFwYDVQQDDBBTYXZvbGFp bmVuIFRlZW11MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAshEsmw6Yiz6XWX26oF+I s5fsfE1OfCjOelclmtqCiIgXND5klkNOBs2d4ZGzgD9mN+XnTZnOTh249c2WxPBugf12DCcDmBAJ gL+VuWUJVBTE5NRchm/O8nZnZsRFst+gAC9/Juykh4+EYewZ7QbpnlwW7hNpj8eH+rMr+OZHKzdp KTftgVjmuF4JJ/cPMQUjL8SuGj+zBW6IWPOZdqkEMtf7Pr8kkYbZsh0SgJ0ceRHZ7Uc06mB/y+C1 UnJPxehTTdu8tpCjdzXgBw/H2uuW1J3qdHbCfbuDILql8V8RiZKubcZLhdsD3Jvj8qK0DGWBJa6x p90q5p3pLE8LvAeCgQIDAQABo4HQMIHNMA4GA1UdDwEB/wQEAwIEMDAfBgNVHSMEGDAWgBSnJLA+ xYPvBA5QdksYMufKVtEsujAZBgNVHSAEEjAQMA4GDCsGAQQBXgExBgEHAzA5BgNVHR8EMjAwMC6g LKAqhihodHRwOi8vY3JsLm5va2lhLmNvbS9Ob2tpYSUyMEJJJTIwQ0EuY3JsMCUGA1UdEQQeMByB GnRlZW11LnNhdm9sYWluZW5Abm9raWEuY29tMB0GA1UdDgQWBBQTRzvZsgmQrAGCeuzdHTGAC6Jg UzANBgkqhkiG9w0BAQUFAAOCAQEACmPVsdi07pjK5gDa+W5JlE2C74kVVsB8alBqfioYeR5At2FG B7sua4Dz5H7TJMpZ1jYFeI+zjexD5f+beY2IlV15lMoWD+5e38QlLYjwfe2LAyvdzBKXW0e0U6Bt p78ft4gyVak1X+Db+ebR+FNHUOMNhm+yK3w9sy5ZQzBFusIx4OgxGvcZhyhmd9WjipSTalgPwgqV Ju2aPADCG++OEXmgEWRLsR4yNopkgK4ftVqrN5uUtLs83qdeXTRcNRiET1IOx5zmYFZ6q3gjKIx5 iyuxcDeYas93vVHUcaRRYpsoby5CHq7Z/j/TQhtqO/knWuxLFFiCUgdGKMKrRkg29DCCBAowggLy oAMCAQICEQCBvi+p+bA/dBtBtybwA6YYMA0GCSqGSIb3DQEBBQUAMDMxCzAJBgNVBAYTAkZJMQ4w DAYDVQQKEwVOb2tpYTEUMBIGA1UEAxMLTm9raWEgQkkgQ0EwHhcNMTEwOTA2MDU1MDM0WhcNMTMw OTA1MDU1MDM0WjBWMQ4wDAYDVQQKDAVOb2tpYTEPMA0GA1UECwwGUGVvcGxlMRgwFgYKCZImiZPy LGQBAQwIMTAwMjQ2NzYxGTAXBgNVBAMMEFNhdm9sYWluZW4gVGVlbXUwggEiMA0GCSqGSIb3DQEB AQUAA4IBDwAwggEKAoIBAQDFPmbRVwuo52v+h6xnQUqokAx2xsHjmPBniEkzgtgBNJsFi838ATEg 1zsx+VotoJg7hMijcrQfpTAgW6gpLGnlmw5QQswrNK1zleOHb4pA5JguU3WhVKFkAH/6/2EU2k/9 m8Pb/gwP55cYg80R6fRmbdsWKhseXF/1isW/rJcWLmIYDg/rXfo3ixqtT9MroAMiuoXnb0ij1L2d Jj64LDp3Ld8Jo0qZzk3Fj4apo8PBd8eAH6HloVBJkxQcwAnv561A+Xi1GHZ2mafRYJGO+1uBDwyd g/8ybEXXA4MKo8lPKjBebYBUFvz80DBA/Lq74UysXkG23BSulcG4xQSYGlyzAgMBAAGjgfUwgfIw HwYDVR0jBBgwFoAUpySwPsWD7wQOUHZLGDLnylbRLLowGQYDVR0gBBIwEDAOBgwrBgEEAV4BMQYB BgQwOQYDVR0fBDIwMDAuoCygKoYoaHR0cDovL2NybC5ub2tpYS5jb20vTm9raWElMjBCSSUyMENB LmNybDAjBgNVHSUEHDAaBggrBgEFBQcDAgYEVR0lAAYIKwYBBQUHAwQwDgYDVR0PAQH/BAQDAgeA MCUGA1UdEQQeMByBGnRlZW11LnNhdm9sYWluZW5Abm9raWEuY29tMB0GA1UdDgQWBBTGhbTJF0EX iagjymQo6GIuSQeRVDANBgkqhkiG9w0BAQUFAAOCAQEAqai6TxZ/BlMHZIhJNPriBPXkQhUlBkGA buJZ5sVm1HIQhWN8elZKjjJdHi1qWEKhMg7yHjEMZsyV8XAZzK0UnOqkpUnt+jnVkNZ9O7/jRtyK f4WUtq5jErc8Hlv4bbGFRHk1T7AuLLE52r1lYOdmoibnQp03QtlDvHUNa68G7jvzThJhieB7U1xh vH3yy0ktaVnWEgAylqf9yIUFjnqau5R6cE1Xo57IYPk/KitX0YF+OigEI/bOQVMi+fze93ZsAOJv /z6g/NGemvUgl5YSdX0uPQK6kEHf/sp/nZyUWWQ7OjtVSqkq2YuYEueQFxTfafl+78GWqgm6W/Bl 32laYzGCAuswggLnAgEBMEgwMzELMAkGA1UEBhMCRkkxDjAMBgNVBAoTBU5va2lhMRQwEgYDVQQD EwtOb2tpYSBCSSBDQQIRAIG+L6n5sD90G0G3JvADphgwCQYFKw4DAhoFAKCCAXgwGAYJKoZIhvcN AQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG9w0BCQUxDxcNMTEwOTE0MDYwODA4WjAjBgkqhkiG9w0B CQQxFgQUc1KzdBbfQ1F8OljUQi21hBfJog4wVgYJKwYBBAGCNxAEMUkwRzAzMQswCQYDVQQGEwJG STEOMAwGA1UEChMFTm9raWExFDASBgNVBAMTC05va2lhIEJJIENBAhAwflqlqTyUTLouYuUuwnLx MFgGCyqGSIb3DQEJEAILMUmgRzAzMQswCQYDVQQGEwJGSTEOMAwGA1UEChMFTm9raWExFDASBgNV BAMTC05va2lhIEJJIENBAhAwflqlqTyUTLouYuUuwnLxMGcGCSqGSIb3DQEJDzFaMFgwCgYIKoZI hvcNAwcwDgYIKoZIhvcNAwICAgCAMA0GCCqGSIb3DQMCAgFAMAcGBSsOAwIHMA0GCCqGSIb3DQMC AgEoMAcGBSsOAwIaMAoGCCqGSIb3DQIFMA0GCSqGSIb3DQEBAQUABIIBAGr9ze06j4TshTMlOFxW VDZmCpO6sG59bpt2glKcZmeyh+3FeaTNl+qqss5XbNyByCtFQEE5PTcwJzNBmOXjuiMmoKIXsotm Mh8P9hG0ZILVIIlCIIPmpdQEpGJanofkqmwSgv/dW/IOYZCEJjRIetnpRdTyGRNOGut4wXa8a5vT QCeCM187b7xl/dDsp9u79mtEe9j68b1DQW46iQFjYigxW+yU/QbBxXzi2HBGM7oJvX72IA8qnn/w ifaQ1jC5mYyq7aAnJ5Lm+2efZzmGWekyHvYxRQHi4WaBh/nn9Ht5N0W+INx6nNHf0wr8x3YunNDl oghfx+kHimcF2UPCXXAAAAAAAAA= ------=_NextPart_000_00DB_01CC72BD.D1FE4870-- From alexandru.petrescu@gmail.com Wed Sep 14 02:13:33 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 D679021F8C60 for ; Wed, 14 Sep 2011 02:13:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.389 X-Spam-Level: X-Spam-Status: No, score=-2.389 tagged_above=-999 required=5 tests=[AWL=-0.140, BAYES_00=-2.599, HELO_EQ_FR=0.35] 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 Cw3N6tlBScvl for ; Wed, 14 Sep 2011 02:13:33 -0700 (PDT) Received: from sainfoin-out.extra.cea.fr (sainfoin-out.extra.cea.fr [132.167.192.144]) by ietfa.amsl.com (Postfix) with ESMTP id B038021F8B67 for ; Wed, 14 Sep 2011 02:13:32 -0700 (PDT) Received: from pisaure.intra.cea.fr (pisaure.intra.cea.fr [132.166.88.21]) by sainfoin.extra.cea.fr (8.14.2/8.14.2/CEAnet-Internet-out-2.2) with ESMTP id p8E9Fer9017648 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Wed, 14 Sep 2011 11:15:40 +0200 Received: from muguet1.intra.cea.fr (muguet1.intra.cea.fr [132.166.192.6]) by pisaure.intra.cea.fr (8.14.4/8.14.4) with ESMTP id p8E9Fb8s012287; Wed, 14 Sep 2011 11:15:37 +0200 (envelope-from alexandru.petrescu@gmail.com) Received: from [127.0.0.1] ([132.166.133.183]) by muguet1.intra.cea.fr (8.13.8/8.13.8/CEAnet-Intranet-out-1.1) with ESMTP id p8E9FXaU027532; Wed, 14 Sep 2011 11:15:37 +0200 Message-ID: <4E7070B5.6080900@gmail.com> Date: Wed, 14 Sep 2011 11:15:33 +0200 From: Alexandru Petrescu User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:6.0.2) Gecko/20110902 Thunderbird/6.0.2 MIME-Version: 1.0 To: teemu.savolainen@nokia.com References: <3CF88B99A9ED504197498BC6F6F04B81040FBDA9@XMB-BGL-41E.cisco.com> <4E6E7A72.9030208@gmail.com> <4E6EAFC2.5060906@gmail.com> <4E6EDEA8.3080108@gmail.com> <4E6F825C.3080303@gmail.com> <3D0B3661-8A8F-4BB2-A8EF-25007BEAF66C@nominum.com> <4E6F923F.7090304@gmail.com> <7061CEB8-8084-41D5-B31E-9F8E3B6C7091@nominum.com> <4E6F9B91.7010503@gmail.com> <4E6FA64E.7020801@gmail.com> <82337D11-0A39-4A10-AA0E-1E81B09DBA4F@nominum.com> <4E6FACF6.5000007@viagenie.ca>, <4E6FC0AE.5000108@gmail.com> <916CE6CF87173740BC8A2CE4430969620257327E@008-AM1MPN1-032.mgdnok.nokia.com> <4E6FD930.7040401@gmail.com> <916CE6CF87173740BC8A2CE443096962025734A7@008-AM1MPN1-032.mgdnok.nokia.com> In-Reply-To: <916CE6CF87173740BC8A2CE443096962025734A7@008-AM1MPN1-032.mgdnok.nokia.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Cc: mif@ietf.org Subject: Re: [mif] Comments on draft-mouton-mif-dhcpv6-drlo-00 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, 14 Sep 2011 09:13:33 -0000 Le 14/09/2011 08:08, teemu.savolainen@nokia.com a 閏rit : >> 3G+ just as 3G is a market to end user label means of advertising >> more speed. Similar to what WiFi is to 802.11. > > Ok, so referring to 3GPP technologies I assume (not WiMAX for > example). > >> In some situations I experienced DHCPv6 may provide routing >> configuration via WiFi to a Windows Phone also connected on 3G+. >> That routing configuration would need to tell the Windows Phone its >> IPv6 default route via the 3G+ access. > > Do you mean the WiFi access would explicitly spell out 3G as the > default route for a node, or indirectly by the WiFi access telling it > is low priority default route (ref RFC4191) - and hence suggesting > using some other interfaces by default instead? YEs, in this way. >> Not sure about it. I agree that PD may be in the 3GPP spec, but I >> am almost sure DHCPv6 is also specified by 3GPP as an alternative >> means to configure a Client, alternate to IPv6 stateless >> autoconfig. > > I am absolutely sure 3GPP as of today does not specify Stateful > DHCPv6 as an option to configure client's WAN interface addresses on > cellular interface. Hmm... in a sense I agree with you - currently in 3GPP specs 23401-a40 and 24301-a30 there is DHCPv6 only as PD and as Stateless DHCPv6, not as stateful DHCPv6. I have limited knowledge of these documents. However, I have remarks. In many places the term "default prefix" is used. For example like this: > IPv6 Prefix Delegation via DHCPv6 Optionally a single network prefix > shorter than the default /64 prefix may be assigned to a PDN > connection. In this case, the /64 default prefix used for IPv6 > stateless autoconfiguration will be allocated from this network > prefix This is difficult to understand because SLAAC has no "default prefix" (grep rfc4862). 24.301-a30 says often GW allocates via RA like this: > The PDN GW allocates a globally unique /64 IPv6 prefix via Router > Advertisement to a given UE. But this is so difficult for me to understand because RA RFC text never says an RA "allocates" some prefix. This allocation action is typically a DHCP action, not RA. The RA simply advertises an allocation already done by DHCP or administrator or ospf. In a number of other places the 3GPP spec is incoherent with respect to who is the "Requesting Router" - the UE or the PDN GW (at a moment the GW is a DHCP client requesting a prefix, at another moment it is the UE being a requesting router). For me it is not clear how a Requesting Router below another Requesting Router can work. Another remark is that Stateless DHCP _could_ be used to communicate default routes to Clients because the data about default route is not state which should be maintained at server. It is possible for a 3G client to simply receive a DHCP Advertise which may be empty and still set a correct default route. > There is only Prefix Delegation in Release-10, but even in Rel-10 > case client's WAN interface address is always configured with SLAAC. Hmmm... I would not rely on 3GPP specs to make a terminal run ok on WiFi. I would guess a 3GPP spec about WiFi is just FYI(?) no offense. ------------ May I try to interpret further the DHCP text in 3GPP specs, IMHO. It is unclear to me why the 23401 3GPP spec says that "The UE acts as a "Requesting Router"" requesting a Prefix. An entire Prefix (in addition to the onlink prefixes) is useful only if that UE is a Mobile Router, giving addresses further to some LFNs. Otherwise it is not clear why do Prefix Delegation to a UE Requesting Router. Yet the spec never says "Mobile Router". If it makes sense for this UE to actually be a MR, and to run DHCPv6-PD then it could make sense to use DHCPv6 for address and default route configuration as well, instead of DHCPv6+SLAAC - simply the number of messages is reduced, and configuration of addresses/routes/prefixes is centralizely managed. But this is just personal opinion, motivating the use of DHCPv6 for default route in 3GPP. > (Ref 3GPP 23.060 and 23.401 for more details). Thanks for ref 23.060. > I have to say I don't recall immediately what 3GPP specs says about > client configuration on trusted WLANs (but I would except also only > SLAAC there as well, otherwise things like netext's logical interface > might be even bigger challenges to get working). Hmmm... in a sense the netext logical interface is to me still unclear. >> If 3GPP uses DHCPv6 to configure addresses to Clients then it may >> be used to configure the default route as well, for more >> efficiency. > > It is true that DHCPv6 can be used to configure additional > information (stateless DHCPv6). Hence yes, specific routes and even > maybe default route could be configured via DHCPv6... but I don't see > why default route would be, as the Router Advertisements used by > SLAAC already provide default route information. _If_ the UE is a Mobile Router and uses DHCPv6-PD to request its prefix (DHCPv6-PD is the only way it can get a prefix for its LFNs) then it may make sense to use same DHCP software to request routes and addresses. What do you think? Alex > > Best regards, > > Teemu From teemu.savolainen@nokia.com Wed Sep 14 03:24: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 7E01E21F8C47 for ; Wed, 14 Sep 2011 03:24:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.675 X-Spam-Level: X-Spam-Status: No, score=-2.675 tagged_above=-999 required=5 tests=[AWL=-0.076, 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 VIeAHMoZhKak for ; Wed, 14 Sep 2011 03:24:13 -0700 (PDT) Received: from mgw-sa01.nokia.com (smtp.nokia.com [147.243.1.47]) by ietfa.amsl.com (Postfix) with ESMTP id 81BF021F8C46 for ; Wed, 14 Sep 2011 03:24:13 -0700 (PDT) Received: from vaebh102.NOE.Nokia.com (vaebh102.europe.nokia.com [10.160.244.23]) by mgw-sa01.nokia.com (Switch-3.4.4/Switch-3.4.3) with ESMTP id p8EAQHNO020367; Wed, 14 Sep 2011 13:26:19 +0300 Received: from smtp.mgd.nokia.com ([65.54.30.8]) by vaebh102.NOE.Nokia.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.4675); Wed, 14 Sep 2011 13:26:13 +0300 Received: from 008-AM1MMR1-001.mgdnok.nokia.com (65.54.30.56) by NOK-AM1MHUB-04.mgdnok.nokia.com (65.54.30.8) with Microsoft SMTP Server (TLS) id 8.2.255.0; Wed, 14 Sep 2011 12:26:13 +0200 Received: from 008-AM1MPN1-032.mgdnok.nokia.com ([169.254.2.143]) by 008-AM1MMR1-001.mgdnok.nokia.com ([65.54.30.56]) with mapi id 14.01.0323.007; Wed, 14 Sep 2011 12:26:12 +0200 From: To: Thread-Topic: [mif] Comments on draft-mouton-mif-dhcpv6-drlo-00 Thread-Index: AQHMclXvmeatSbe770ilB6P1NUlbCpVL1DV4///urQCAAJ4CcIAAFp+AgAAwtvA= Date: Wed, 14 Sep 2011 10:26:11 +0000 Message-ID: <916CE6CF87173740BC8A2CE44309696202573B89@008-AM1MPN1-032.mgdnok.nokia.com> References: <3CF88B99A9ED504197498BC6F6F04B81040FBDA9@XMB-BGL-41E.cisco.com> <4E6E7A72.9030208@gmail.com> <4E6EAFC2.5060906@gmail.com> <4E6EDEA8.3080108@gmail.com> <4E6F825C.3080303@gmail.com> <3D0B3661-8A8F-4BB2-A8EF-25007BEAF66C@nominum.com> <4E6F923F.7090304@gmail.com> <7061CEB8-8084-41D5-B31E-9F8E3B6C7091@nominum.com> <4E6F9B91.7010503@gmail.com> <4E6FA64E.7020801@gmail.com> <82337D11-0A39-4A10-AA0E-1E81B09DBA4F@nominum.com> <4E6FACF6.5000007@viagenie.ca>,<4E6FC0AE.5000108@gmail.com> <916CE6CF87173740BC8A2CE4430969620257327E@008-AM1MPN1-032.mgdnok.nokia.com> <4E6FD930.7040401@gmail.com> <916CE6CF87173740BC8A2CE443096962025734A7@008-AM1MPN1-032.mgdnok.nokia.com> <4E7070B5.6080900@gmail.com> In-Reply-To: <4E7070B5.6080900@gmail.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes 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+/nZJb9Kg7IuZuBXX/gTPnV8RRCmXgbNBLv+s+z8dze93E2y5N3eQswSwwwxgghs89TU1NiT1JcwoYrWJF1mZc/NrOJDhIyVOXH9EPAg712fNqHrpoDEsvuRlOS1hSiwqJBl/y+vrUMbNcSOiAMcMwyx351Sa6Z/IFSlHIhsBMoR40FyewYK3KCsi7Yxw68v+kP9DvNAmUZxPlsGYqXedFJIa5k15Bm0XdsxKvBnVcmuxqzTj4b4GDU4EfHLLHaH9VmYnqNFtQ0A== x-originating-ip: [10.162.78.119] Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=SHA1; boundary="----=_NextPart_000_012F_01CC72E1.DE149280" MIME-Version: 1.0 X-OriginalArrivalTime: 14 Sep 2011 10:26:13.0399 (UTC) FILETIME=[BA727270:01CC72C8] X-Nokia-AV: Clean Cc: mif@ietf.org Subject: Re: [mif] Comments on draft-mouton-mif-dhcpv6-drlo-00 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, 14 Sep 2011 10:24:14 -0000 ------=_NextPart_000_012F_01CC72E1.DE149280 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit > In many places the term "default prefix" is used. For example like this: > > IPv6 Prefix Delegation via DHCPv6 Optionally a single network prefix > > shorter than the default /64 prefix may be assigned to a PDN > > connection. In this case, the /64 default prefix used for IPv6 > > stateless autoconfiguration will be allocated from this network prefix > > This is difficult to understand because SLAAC has no "default prefix" > (grep rfc4862). It refers to unique /64 prefix allocated for a PDN connection. > 24.301-a30 says often GW allocates via RA like this: > > The PDN GW allocates a globally unique /64 IPv6 prefix via Router > > Advertisement to a given UE. > > But this is so difficult for me to understand because RA RFC text never says > an RA "allocates" some prefix. This allocation action is typically a DHCP > action, not RA. The RA simply advertises an allocation already done by DHCP > or administrator or ospf. Maybe the terminology is not clearest, but it means /64 prefix is advertised to the PDN connection. It is different topic then where the PDN GW got the addresses (statically allocated pool or by DHCPv6 or whatever means). The "allocate" text probably comes from the view that it is P-t-P connection between UE and PDN GW and hence there is just single UE that "gets" the whole /64 "allocated" for its use. > In a number of other places the 3GPP spec is incoherent with respect to who > is the "Requesting Router" - the UE or the PDN GW (at a moment the GW is a > DHCP client requesting a prefix, at another moment it is the UE being a > requesting router). For me it is not clear how a Requesting Router below > another Requesting Router can work. In my understanding the PDN GW can use DHCPv6 Prefix Delegation to get an address pool from where to "advertise" /64s for different UEs PDN connections. Additionally, in rel-10, also UE connected to PDN GW can use DHCPv6 Prefix Delegation to get prefixes for advertisement on local area networks (such as "MiFi hotspot"). > It is unclear to me why the 23401 3GPP spec says that "The UE acts as a > "Requesting Router"" requesting a Prefix. An entire Prefix (in addition to the > onlink prefixes) is useful only if that UE is a Mobile Router, giving addresses > further to some LFNs. Otherwise it is not clear why do Prefix Delegation to a > UE Requesting Router. Yet the spec never says "Mobile Router". UE acts as requesting router in order to behave as a router. I understand not using term Mobile Router there, as the UE does not necessarily implement any "IP Mobility" solutions (e.g. DSMIP6). UE just acts as a router. > If it makes sense for this UE to actually be a MR, and to run DHCPv6-PD then > it could make sense to use DHCPv6 for address and default route > configuration as well, instead of DHCPv6+SLAAC - simply the number of > messages is reduced, and configuration of addresses/routes/prefixes is > centralizely managed. It could, but as of now it is not specified to be possible. 3GPP UE always uses SLAAC to number its cellular WAN interface (unnumbered model is not supported), including getting default route pointing to cellular interface. After SLAAC, UE acting as router MAY use DHCPv6 PD to get prefixes for advertisement in "southbound" local area networks. Because SLAAC is always used and UE gets its IPv6 default route that way, there is currently no need to use DHCPv6 to specify default routes. As always, things may change in the future and that's one reason why I'm ok for defining default route option for DHCPv6. Best regards, Teemu ------=_NextPart_000_012F_01CC72E1.DE149280 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIOuzCCAzYw ggIeoAMCAQICBDpVqdkwDQYJKoZIhvcNAQEFBQAwKTEOMAwGA1UEChMFTm9raWExFzAVBgNVBAMT Dk5va2lhICBSb290IENBMB4XDTAxMDEwNTExMDUwNVoXDTE2MDEwMjExMDUwNVowKTEOMAwGA1UE ChMFTm9raWExFzAVBgNVBAMTDk5va2lhICBSb290IENBMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8A MIIBCgKCAQEAsrTy8gLmr4LYvp0khVUVHw7ascdl+Cjr+yI5MlZ6J/U6Qsvkiqthgqq8rPcLV0P1 92TfBr27VgKEeCaZe0icS1jC2spM/wRv3j2WxdkKxb9kDJtuCNJaRBqvi5vGTHB15nmEmKuL5f3i rAxeHqPjgS496oWcudzFT1e7Xrc/gWGFYd72+/ykIFXjWOMZv6QpxD8x1hLPyh2YVXRk9U7N7pvm RQNX29g4SCFJY2BBIa5JPlwIF8Nc9IePaC/E/2M4tGMtiOOZlm99EoL7N0hJZtFSvUwdCBud/viH 4DgsKGjNkNKi6pAHc9IaXB6tIykcoYp+L+oe/3+cuEJaCj1EKwIDAQABo2YwZDASBgNVHRMBAf8E CDAGAQH/AgEEMB0GA1UdDgQWBBSNjfefoQ0AITLvqe0iruA79NB9sDAfBgNVHSMEGDAWgBSNjfef oQ0AITLvqe0iruA79NB9sDAOBgNVHQ8BAf8EBAMCAYYwDQYJKoZIhvcNAQEFBQADggEBAIGEPql2 TALyKi/h1J+Mh5XolAtYppcSOLMtBkoA7ZovGBDNvl0VbZs8AAojJqkUoWBB+L6DKyl/jKhNfKcu rWRGRyj7pnbxrKLsI3gmWNWkyo2b60wJwe9fqPD5ZQy3oEiMit9l0Ba6il/k2GqYopUCNMa7mfeb E2LeBy5ChYMiCi97UQSJvAdzEYylTJw8Awc6AiM2Ve5N+XxsmKgNf/2A/5IJ3EZZ+wFRmkI4062A oNU302rqAt0HH88jzoUF4AfYHWl6HpYhGXFbcX44rHINyPmFBRxLYIFJ6ZWUr/mXpL/e6rqFtNWO kV6UoJND7OVZkbLh7F1+lcqXRU8TPBMwggOHMIICb6ADAgECAgRBtbHpMA0GCSqGSIb3DQEBBQUA MCkxDjAMBgNVBAoTBU5va2lhMRcwFQYDVQQDEw5Ob2tpYSAgUm9vdCBDQTAeFw0wNjAzMzAwOTU3 MTFaFw0xNjAxMDIxMTA1MDVaMDMxCzAJBgNVBAYTAkZJMQ4wDAYDVQQKEwVOb2tpYTEUMBIGA1UE AxMLTm9raWEgQkkgQ0EwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQDtFCg3QEjSCg6T IUxoWsNwELh8bBNiUQPCPmg8c2DHQYXWWCSCMb+S0Fvh1qqI1xt+XnzyFq+5eqzGzDj4UaBcG+d9 qxrCFly8sHyoPTryyPrR0EI2UUDWwfS6ojhqgwghRqo8G38TjFusyBtLub/5L6yvWYSOHD+JcB+q VM2fbkArPYK4Ydv8WG/DbHjGn0gKq0zwpVZKI/gCK/QALYvte02NXseqvY9/GOyLtjy3Z8erFv71 KKTq+gxI/7DK55pJf3PoD+kT4kyGm6EF9DTdK4ojMdar17uyX0IOZz/4vkkF0d+60nmnLX63FJPA jUyB0HUNJ32NXDo9UsM38aoNAgMBAAGjgawwgakwDwYDVR0TAQH/BAUwAwEB/zARBgNVHSAECjAI MAYGBFUdIAAwDgYDVR0PAQH/BAQDAgGGMFQGA1UdIwRNMEuAFI2N95+hDQAhMu+p7SKu4Dv00H2w oS2kKzApMQ4wDAYDVQQKEwVOb2tpYTEXMBUGA1UEAxMOTm9raWEgIFJvb3QgQ0GCBDpVqdkwHQYD VR0OBBYEFKcksD7Fg+8EDlB2Sxgy58pW0Sy6MA0GCSqGSIb3DQEBBQUAA4IBAQAC3lEUplDlVNOT Pjz/XFezXx2bV2XbCFindhA3F815Egi55H6/cYezEjoP4QLNEGGl2I3aLvkn5A0T8I4pbiFPhIiu B/frbbGg6k6GjQLe/bFQ8F1mAOOR+GyneKZFPfzaRV0jiIR9QqnMXTf8RvKkCJyFj10MZVsLIy/Y uBkzeP3JhzDhUdtPfwmJN6ZbIhH5uR/2BwAGtgQknb8WX3I4wnhWtMUxB8XmayayYs8qWYeIiVkI FV+sLTkWUWVvvKUjyakBpbAW2vUP84DYsJ8TL1YefNjf/nIOByMcORLuV/1gPjyv00qJbcB59AA+ iXe3zIo8QNcgXG0uPQQFmrGDMIID5DCCAsygAwIBAgIQMH5apak8lEy6LmLlLsJy8TANBgkqhkiG 9w0BAQUFADAzMQswCQYDVQQGEwJGSTEOMAwGA1UEChMFTm9raWExFDASBgNVBAMTC05va2lhIEJJ IENBMB4XDTExMDkwNjA1NTIwNFoXDTE0MDkwNjA1NTIwNFowVjEOMAwGA1UECgwFTm9raWExDzAN BgNVBAsMBlBlb3BsZTEYMBYGCgmSJomT8ixkAQEMCDEwMDI0Njc2MRkwFwYDVQQDDBBTYXZvbGFp bmVuIFRlZW11MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAshEsmw6Yiz6XWX26oF+I s5fsfE1OfCjOelclmtqCiIgXND5klkNOBs2d4ZGzgD9mN+XnTZnOTh249c2WxPBugf12DCcDmBAJ gL+VuWUJVBTE5NRchm/O8nZnZsRFst+gAC9/Juykh4+EYewZ7QbpnlwW7hNpj8eH+rMr+OZHKzdp KTftgVjmuF4JJ/cPMQUjL8SuGj+zBW6IWPOZdqkEMtf7Pr8kkYbZsh0SgJ0ceRHZ7Uc06mB/y+C1 UnJPxehTTdu8tpCjdzXgBw/H2uuW1J3qdHbCfbuDILql8V8RiZKubcZLhdsD3Jvj8qK0DGWBJa6x p90q5p3pLE8LvAeCgQIDAQABo4HQMIHNMA4GA1UdDwEB/wQEAwIEMDAfBgNVHSMEGDAWgBSnJLA+ xYPvBA5QdksYMufKVtEsujAZBgNVHSAEEjAQMA4GDCsGAQQBXgExBgEHAzA5BgNVHR8EMjAwMC6g LKAqhihodHRwOi8vY3JsLm5va2lhLmNvbS9Ob2tpYSUyMEJJJTIwQ0EuY3JsMCUGA1UdEQQeMByB GnRlZW11LnNhdm9sYWluZW5Abm9raWEuY29tMB0GA1UdDgQWBBQTRzvZsgmQrAGCeuzdHTGAC6Jg UzANBgkqhkiG9w0BAQUFAAOCAQEACmPVsdi07pjK5gDa+W5JlE2C74kVVsB8alBqfioYeR5At2FG B7sua4Dz5H7TJMpZ1jYFeI+zjexD5f+beY2IlV15lMoWD+5e38QlLYjwfe2LAyvdzBKXW0e0U6Bt p78ft4gyVak1X+Db+ebR+FNHUOMNhm+yK3w9sy5ZQzBFusIx4OgxGvcZhyhmd9WjipSTalgPwgqV Ju2aPADCG++OEXmgEWRLsR4yNopkgK4ftVqrN5uUtLs83qdeXTRcNRiET1IOx5zmYFZ6q3gjKIx5 iyuxcDeYas93vVHUcaRRYpsoby5CHq7Z/j/TQhtqO/knWuxLFFiCUgdGKMKrRkg29DCCBAowggLy oAMCAQICEQCBvi+p+bA/dBtBtybwA6YYMA0GCSqGSIb3DQEBBQUAMDMxCzAJBgNVBAYTAkZJMQ4w DAYDVQQKEwVOb2tpYTEUMBIGA1UEAxMLTm9raWEgQkkgQ0EwHhcNMTEwOTA2MDU1MDM0WhcNMTMw OTA1MDU1MDM0WjBWMQ4wDAYDVQQKDAVOb2tpYTEPMA0GA1UECwwGUGVvcGxlMRgwFgYKCZImiZPy LGQBAQwIMTAwMjQ2NzYxGTAXBgNVBAMMEFNhdm9sYWluZW4gVGVlbXUwggEiMA0GCSqGSIb3DQEB AQUAA4IBDwAwggEKAoIBAQDFPmbRVwuo52v+h6xnQUqokAx2xsHjmPBniEkzgtgBNJsFi838ATEg 1zsx+VotoJg7hMijcrQfpTAgW6gpLGnlmw5QQswrNK1zleOHb4pA5JguU3WhVKFkAH/6/2EU2k/9 m8Pb/gwP55cYg80R6fRmbdsWKhseXF/1isW/rJcWLmIYDg/rXfo3ixqtT9MroAMiuoXnb0ij1L2d Jj64LDp3Ld8Jo0qZzk3Fj4apo8PBd8eAH6HloVBJkxQcwAnv561A+Xi1GHZ2mafRYJGO+1uBDwyd g/8ybEXXA4MKo8lPKjBebYBUFvz80DBA/Lq74UysXkG23BSulcG4xQSYGlyzAgMBAAGjgfUwgfIw HwYDVR0jBBgwFoAUpySwPsWD7wQOUHZLGDLnylbRLLowGQYDVR0gBBIwEDAOBgwrBgEEAV4BMQYB BgQwOQYDVR0fBDIwMDAuoCygKoYoaHR0cDovL2NybC5ub2tpYS5jb20vTm9raWElMjBCSSUyMENB LmNybDAjBgNVHSUEHDAaBggrBgEFBQcDAgYEVR0lAAYIKwYBBQUHAwQwDgYDVR0PAQH/BAQDAgeA MCUGA1UdEQQeMByBGnRlZW11LnNhdm9sYWluZW5Abm9raWEuY29tMB0GA1UdDgQWBBTGhbTJF0EX iagjymQo6GIuSQeRVDANBgkqhkiG9w0BAQUFAAOCAQEAqai6TxZ/BlMHZIhJNPriBPXkQhUlBkGA buJZ5sVm1HIQhWN8elZKjjJdHi1qWEKhMg7yHjEMZsyV8XAZzK0UnOqkpUnt+jnVkNZ9O7/jRtyK f4WUtq5jErc8Hlv4bbGFRHk1T7AuLLE52r1lYOdmoibnQp03QtlDvHUNa68G7jvzThJhieB7U1xh vH3yy0ktaVnWEgAylqf9yIUFjnqau5R6cE1Xo57IYPk/KitX0YF+OigEI/bOQVMi+fze93ZsAOJv /z6g/NGemvUgl5YSdX0uPQK6kEHf/sp/nZyUWWQ7OjtVSqkq2YuYEueQFxTfafl+78GWqgm6W/Bl 32laYzGCAuswggLnAgEBMEgwMzELMAkGA1UEBhMCRkkxDjAMBgNVBAoTBU5va2lhMRQwEgYDVQQD EwtOb2tpYSBCSSBDQQIRAIG+L6n5sD90G0G3JvADphgwCQYFKw4DAhoFAKCCAXgwGAYJKoZIhvcN AQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG9w0BCQUxDxcNMTEwOTE0MTAyNjEwWjAjBgkqhkiG9w0B CQQxFgQUB/gkoJJshowFo3r3W1MMAxM4NvswVgYJKwYBBAGCNxAEMUkwRzAzMQswCQYDVQQGEwJG STEOMAwGA1UEChMFTm9raWExFDASBgNVBAMTC05va2lhIEJJIENBAhAwflqlqTyUTLouYuUuwnLx MFgGCyqGSIb3DQEJEAILMUmgRzAzMQswCQYDVQQGEwJGSTEOMAwGA1UEChMFTm9raWExFDASBgNV BAMTC05va2lhIEJJIENBAhAwflqlqTyUTLouYuUuwnLxMGcGCSqGSIb3DQEJDzFaMFgwCgYIKoZI hvcNAwcwDgYIKoZIhvcNAwICAgCAMA0GCCqGSIb3DQMCAgFAMAcGBSsOAwIHMA0GCCqGSIb3DQMC AgEoMAcGBSsOAwIaMAoGCCqGSIb3DQIFMA0GCSqGSIb3DQEBAQUABIIBAIgUkj03IQ/6VX42du13 3JeJhX37Y0XUFufJEggmhYfj/42RHf+b2+TQmqckbqZ9JlXEY2Lue/priOQyvnh5x/ty+bOV4Sdr kT0iZkx1e7d84R5cSWGaRPt3XSHU4/F1jp28raLdo06rakwyCwVFM8DFkc2lJVsfyCrI6FH+FLD4 cK/adtVETMgBelPcA1NYrqf9WAnOob3SnSw/H0Z9gEZgOrrZHwVt6v/gKoU7NFpPDulE+gBqlnRd xUERjKXcehIf8VNj+dpjUqcj2iXIuR9ezla2ooT0OphEi+4sNxsC9jqzjYINw6Uar6MAEbBNdos0 1rT2KWV+jGq7r+b1taQAAAAAAAA= ------=_NextPart_000_012F_01CC72E1.DE149280-- From teemu.savolainen@nokia.com Wed Sep 14 06:53:58 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 5F3FE21F8BE8; Wed, 14 Sep 2011 06:53:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.171 X-Spam-Level: X-Spam-Status: No, score=-3.171 tagged_above=-999 required=5 tests=[AWL=0.428, 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 pWgbYCqBUSBO; Wed, 14 Sep 2011 06:53:53 -0700 (PDT) Received: from mgw-da01.nokia.com (smtp.nokia.com [147.243.128.24]) by ietfa.amsl.com (Postfix) with ESMTP id 9ED4021F8BBE; Wed, 14 Sep 2011 06:53:53 -0700 (PDT) Received: from vaebh102.NOE.Nokia.com (vaebh102.europe.nokia.com [10.160.244.23]) by mgw-da01.nokia.com (Switch-3.4.4/Switch-3.4.3) with ESMTP id p8EDtwUO004145; Wed, 14 Sep 2011 16:55:59 +0300 Received: from smtp.mgd.nokia.com ([65.54.30.7]) by vaebh102.NOE.Nokia.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.4675); Wed, 14 Sep 2011 16:55:53 +0300 Received: from 008-AM1MMR1-002.mgdnok.nokia.com (65.54.30.57) by NOK-AM1MHUB-03.mgdnok.nokia.com (65.54.30.7) with Microsoft SMTP Server (TLS) id 8.2.255.0; Wed, 14 Sep 2011 15:55:43 +0200 Received: from 008-AM1MPN1-032.mgdnok.nokia.com ([169.254.2.143]) by 008-AM1MMR1-002.mgdnok.nokia.com ([65.54.30.57]) with mapi id 14.01.0323.007; Wed, 14 Sep 2011 15:55:42 +0200 From: To: Thread-Topic: apps-team review of draft-ietf-mif-dns-server-selection Thread-Index: AcxyrBw6zVCShQsaRQaFoCi5Am4oqAALTEuA Date: Wed, 14 Sep 2011 13:55:41 +0000 Message-ID: <916CE6CF87173740BC8A2CE44309696202573D36@008-AM1MPN1-032.mgdnok.nokia.com> References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes 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+/nZJb9Kg7Io6FujjSfNcXJGUP9WUdfQoJmpfVHi50dPq5KK9wdv8YWMOnlWEAV7vitTS8DUHPOf+v+0rDoqIXDlYBGAkr4aFmlVX72DYkzc7FMyhxe1AE8JaiM8N+owe8T46p+5odYFpcc3S+UERsY5D3pIS96GmVqZGZtQWAUs09Yxm1Ek/ZYVTro9BId1kuOpfCWBge+hJ0ptecrs9ytVuIdhk7jdg+3nvOdW/pcJuz+sJe2aL250googH0+uPDSPjEzpjeNw== x-originating-ip: [10.162.78.119] Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=SHA1; boundary="----=_NextPart_000_0158_01CC72FF.21E75F20" MIME-Version: 1.0 X-OriginalArrivalTime: 14 Sep 2011 13:55:53.0618 (UTC) FILETIME=[04D78720:01CC72E6] X-Nokia-AV: Clean Cc: apps-ads@tools.ietf.org, mif@ietf.org, apps-review@ietf.org Subject: Re: [mif] apps-team review of draft-ietf-mif-dns-server-selection X-BeenThere: mif@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multiple Interface Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 14 Sep 2011 13:53:58 -0000 ------=_NextPart_000_0158_01CC72FF.21E75F20 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Thank you very much for your extensive review, I have replied and = commented inline. I cc=92d mif, apps-ads, and apps-review =96 hope it is ok. Completing review of -03 revision was just fine approach, as the -04 was created only to share updates done based on feedback for -03 that was received by yesterday evening my time.=20 I will wait a while for additional input before uploading -05. Best regards, Teemu ------- From: ext Murray S. Kucherawy [mailto:msk@cloudmark.com]=20 Sent: 14. syyskuuta 2011 10:01 To: draft-ietf-mif-dns-server-selection@tools.ietf.org; mif-chairs@tools.ietf.org Cc: apps-review@ietf.org; apps-ads@tools.ietf.org Subject: apps-team review of draft-ietf-mif-dns-server-selection I have been selected as the Applications Area Review Team reviewer for = this draft (for background on apps-review, please see http://www.apps.ietf.org/content/applications-area-review-team). Please resolve these comments along with any other Last Call comments = you may receive. Please wait for direction from your document shepherd or AD before posting a new version of the draft. Document: draft-ietf-mif-dns-server-selection-03 Title: Improved DNS Server Selection for Multi-Homed Nodes Reviewer: Murray S. Kucherawy Review Date: September 13, 2011 IETF Last Call Date: N/A (not yet in IETF Last Call) IESG Telechat Date: N/A (not scheduled) Summary: This draft is almost ready for publication as a Standards Track = RFC but has a few issues that should be fixed before publication. NOTE: This is an early review, so please ignore the parts of this boilerplate that sound as though you=92re in IETF Last Call.=A0 Also, = this is a review of the -03 version of the draft.=A0 A new version was published = after I had already completed a good part of my review, so I completed it based = on this version and not the new one.=A0 I haven=92t looked at the diffs = between the two. Major Issues: =95 None. Minor Issues: =95 The IANA Considerations section seems to be a little understated. = =A0I would suggest copying the one from RFC3646 and modifying it accordingly. Teemu>Roger that, I updated my -05 candidate IANA considerations section = to look following (as of now): -- This memo requests IANA to assign two new option codes. First option code is requested to be assigned for DHCPv4 DNS Server Selection option (TBD) from the DHCP option code space defined in section "New DHCP option codes" of RFC 2939. Second option code is requested to be assigned to the DHCPv6 DNS Server Selection option (TBD) from the DHCPv6 option code space defined in section "IANA Considerations" of RFC 3315. -- =95 The use of =93domain=94 in the first paragraph of Section 1 is = ambiguous.=A0 The word =93domain=94 is unfortunately overloaded to mean management domain, = DNS domain, and probably some others, plus the usual dictionary = definition.=A0 I recommend simply saying =93a solution for IPv6.=94=A0 Don=92t be = surprised if a DNS Directorate reviewer complains about this as well. Teemu>It now says:=94=85multi-interfaced nodes and provides a = solution=94, as the solution is proposed for both IPv4 and IPv6. =95 The document in general makes use of the term =93DNS suffix=94.=A0 = It could be that I=92ve simply never encountered the term before, but it took me a = while of reading to realize this actually meant =93domain name=94.=A0 I would = suggest clarifying this up front someplace, or changing it to =93domain name=94 throughout. Teemu>It was changed to =93domain=94 throughout. However, for section = 4.1 (where this is introduced) I added further clarification that =93domain=94 is = referring to =93DNS domain name suffixes=94: -- =85..matching to specific DNS domain name suffixes or reverse (PTR = record) lookup requests matching to specific network addresses (later = referred as "domain" and "network"). -- =95 The last paragraph of Section 2.4 is confusing.=A0 It says =93After = the interface change[,] a host could have both positive and negative DNS = cache entries no longer valid on the new network interface.=94=A0 Should that =93both=85and=94 be =93either=85or=94?=A0 I=92m not clear on how a = single node can have both positive and negative DNS cache entries no longer valid on the new interface, unless you mean some of its cache will be positive and wrong = and some of its cache will be negative and wrong (about different names) = after the move.=A0 This should be clarified. Teemu> Section 2.2.. It tries to say any cached entry may or may not be valid after interface change =96 as you guessed. How about: -- A thing worth noting is that network specific IP addresses can cause problems also for a single-homed node, if the node retains DNS cache = during movement from one network to another. After the network change, a node = may have both wrong positive and wrong negative entries in its DNS cache. -- =95 I found it strange to read RFC2119 normative language Section 4.1 = which describes an internal-use algorithm for collecting and organizing data learned from DHCP and DHCPv6 to build up a set of rules for deciding = which nameserver(s) to use for which queries.=A0 The same sort of thing = appeared later in Sections 4.5 and 4.6.=A0 My understanding is that, since DHCP = and DHCPv6 are the wire protocols used and this section describes an internal-use mechanism, these bits of the text shouldn=92t include any = RFC2119 language; there is nothing here that affects interoperability between = two nodes implementing this protocol.=A0 If a node implementing this gets it wrong, it only hurts itself; the wire protocols don=92t break.=A0 If = this section were to be separated into its own document, it would be Informational, not Standards Track.=A0 This isn=92t a showstopper for = me, but I did find it unusual. Teemu>The normative text for this algorithm is there mostly due concerns that otherwise this option could open a new attack vector. By describing = how a node MUST handle the information it receives, the risk of attacks = should be decreased. The normative text is there also so that if a node claims compliancy to RFC, network operator who provides such options (to build = a system) could expect a node to behave as is described.=20 =95 There are a few places in the document, the Introduction and Section = 4.1 for example, that talk about PTR lookup requests matching specific IPv6 prefixes.=A0 However, the abstract mentions IPv4 support, and the = mechanism is also described for IPv4.=A0 I suggest making a quick pass through the = document to be sure it doesn=92t appear as if IPv6 is the focus and IPv4 was = added in as an after-thought. Teemu>Well IPv4 was after-thought as I would have settled for IPv6-only = but WG wanted IPv4 option as well:-) The -04 version should have cleared = several of these "IPv6 focus" issues (by talking about network addresses instead = of prefixes), but I guess checking again would not hurt. On the other hand, IPv6 really is the focus here, as multi-interface behavior with IPv4 = anyway is terrible mess due widespread usage of RFC1918 addressed networks (and that's why I'm secretly hoping DHC WG would say they don=92t want to use = DHCP option code for this option and hence this technology must be = IPv6-only:-D. =95 The normative language in Section 4.1 around DNSSEC seems to be the = kind of thing that should be left for local policy.=A0 I can envision = environments where the client isn=92t doing anything sensitive enough to demand = DNSSEC, so the first reply it gets from any nameserver it queried is probably = fine.=A0 The same sort of thing reappears in Section 4.4. Teemu>This document should already allow such local policy. Section 4.4. describes possibility of "unless the node is specifically configured to = do so.". The DNSSEC requirement has been very hard on MIF WG mailing list discussions in order to fight against creation of new attack vectors, = hence easing that requirement requires restarting of those discussions. See = also section 4.4 for cases where DNSSEC is not required - like the option = 1:"The server selection option is delivered across a secure, trusted channel." =95 In Section 4.2, the paragraph starting =93If the = OPTION_DNS_SERVER_SELECT contains=85=94 was a little confusing to read.=A0 It says in general = that when learning about DNS servers available, the node can update what it knows = but can=92t forget what it=92s learned, however it can ignore things it = chooses to ignore.=A0 I found this difficult to follow.=A0 Some expansion of this paragraph, perhaps with examples, might help. Teemu>I wonder if it would be actually wiser just to keep one instance = of the option contents in memory (from most trusted network interface?), = and ensure all legitimate DHCP servers have the same content for the same = DNS server option? =95 At the end of Section 4.2, it says =93=85use of generic DHCPv6 = Information Refresh Time Option, as specified in [RFC4242], is envisaged.=94=A0 That = wording is odd; shouldn=92t it be RECOMMENDED?=A0 It=92s too vague otherwise. Teemu>Fine for me, changed on -05 candidate accordingly. =95 Section 4.4 says a node MUST NOT use the feature being described = here unless specifically configured to do so.=A0 That seems odd.=A0 Is the = intent to have implementations force this feature off-by-default? Teemu>Pretty much so, due security concerns. Please note that other SDOs = or organizations that create profiles may say that in their environments = the feature shall be on-by-default. =95 I didn=92t understand this sentence in Section 4.5: =93When both = options are received from the same network interface =85, the resolver MUST make the decision which one to prefer based on preferences.=94 Teemu>modified to:"...decision which one to prefer based on DNS = preference field value.". Better? =95 Section 7 says =93To ensure nodes=92 routing =85 works correctly, = network administrators should also deploy related technologies for that = purpose.=94=A0 Are there any that can be suggested or referenced here? Teemu>I actually removed that sentence on -04 as it is probably better = to tie different solution documents together in some other document (like = at draft-ietf-v6ops-ipv6-multihoming-without-ipv6nat ). The reference could have been to RFC4191 and MIF DHCPv6 route option (at least). =20 =95 Appendix A is called =93Best Current Practice=94, but the first = section starts out =93A possible current practice=85=94=A0 Where=92s the best one, and = why is it best? Teemu>well.. changed title of Appendix A to "Possible alternative = practices for DNS server selection". Better? Nits: =95 There are a few places where I saw RFC2119 words used in = non-normative ways, such as the last sentence of Section 3.1 or the middle of Section = 7.=A0 I would suggest considering alternate words like =93might=94 in place of = =93may=94 specifically to avoid such issues. Teemu>You refer to section 7 comment regarding "are recommended to = avoid..". The section 7 was completely rewritten for -04 and is now using = normative ways. On section 3.1 you refer to "may be considered.."? Changed that to might. I guess the doc needs reading pass to find possible other = instances of this issue... =95 There=92s a discussion point at the end of Section 4.1 that asks = =93What about those DNS servers that instead of a negative answer always return = positive reply with an IP address of some captive portal?=94=A0 I don=92t think = software implementing this specification can determine that via a DHCP query = without other supporting changes to the infrastructure.=A0 I suggest not trying = to tackle this point. Teemu>Thank you for commenting - and also supporting - on this issue. I thought about this yesterday and also decided not trying to tackle this point and removed the note from -04.... Node with DNSSEC implementation would fail on validation on such cases.. but would still have to = continue in order to get to the captive portal.... =95 In Section 4.3, Figure 6, the order of = =93DNS-recusrive-name-server=94 and =93prf=94 in the description should be swapped to match the order in = which they appear in the diagram. Teemu>Changed =95 In Section 5, the explanation bullets under Figure 7 include two = DHCPv6 replies.=A0 The second one covered =93example.com=94 and a specific IPv6 = suffix, but it=92s not clear that there was no overlap with the first one (i.e., = the first one could=92ve said the same thing).=A0 It should be made clear = that they had disjoint replies. Teemu>Ok.. changed to: --- 2. The node obtains domain 'domain1.example.com' and IPv6 network '0.8.b.d.0.1.0.0.2.ip6.arpa' for the new interface 1 from DHCPv6 server .... 5. The node obtains domain 'domain2.example.com' and IPv6 network information, say '1.8.b.d.0.1.0.0.2.ip6.arpa' for the new interface 2 from DHCPv6 server ---=20 and later in fig 8: -- 1. An application makes a request for resolving an FQDN, e.g. 'private.domain2.example.com' -- =95 In several places there are references to =93chapters=94 instead of = =93sections=94 or the =93section=94 reference is not capitalized, which xml2rfc does = for you.=A0 It seems then these are manual references rather than automatic ones, = though the document does claim to have been produced by xml2rfc.=A0=A0 You = might make your life easier by changing them to tags. Teemu>Fixed manually... will try to remember to update to automatic = later:-D =95 Section 10 might be improved by dividing separate topics into their = own subsections.=A0 For example, the first three paragraphs could become = Section 10.1, and the remaining two could go in 10.2 and 10.3. Teemu>I will think about this (now running out of time to do edits while replying) =95 Appendix A.1 uses the term =93hotspot=94 which is colloquial and = might even be trademarked.=A0 I suggest =93wireless network=94. Teemu>That part was removed at the same time the text talking about = leaking names was removed.. =95 The document is in need of a full edit pass with attention to = corrections of English grammar.=20 Teemu>Yep, hopefully by someone who is native English speaker:-) (or otherwise skilled). ------=_NextPart_000_0158_01CC72FF.21E75F20 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIOuzCCAzYw ggIeoAMCAQICBDpVqdkwDQYJKoZIhvcNAQEFBQAwKTEOMAwGA1UEChMFTm9raWExFzAVBgNVBAMT Dk5va2lhICBSb290IENBMB4XDTAxMDEwNTExMDUwNVoXDTE2MDEwMjExMDUwNVowKTEOMAwGA1UE ChMFTm9raWExFzAVBgNVBAMTDk5va2lhICBSb290IENBMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8A MIIBCgKCAQEAsrTy8gLmr4LYvp0khVUVHw7ascdl+Cjr+yI5MlZ6J/U6Qsvkiqthgqq8rPcLV0P1 92TfBr27VgKEeCaZe0icS1jC2spM/wRv3j2WxdkKxb9kDJtuCNJaRBqvi5vGTHB15nmEmKuL5f3i rAxeHqPjgS496oWcudzFT1e7Xrc/gWGFYd72+/ykIFXjWOMZv6QpxD8x1hLPyh2YVXRk9U7N7pvm RQNX29g4SCFJY2BBIa5JPlwIF8Nc9IePaC/E/2M4tGMtiOOZlm99EoL7N0hJZtFSvUwdCBud/viH 4DgsKGjNkNKi6pAHc9IaXB6tIykcoYp+L+oe/3+cuEJaCj1EKwIDAQABo2YwZDASBgNVHRMBAf8E CDAGAQH/AgEEMB0GA1UdDgQWBBSNjfefoQ0AITLvqe0iruA79NB9sDAfBgNVHSMEGDAWgBSNjfef oQ0AITLvqe0iruA79NB9sDAOBgNVHQ8BAf8EBAMCAYYwDQYJKoZIhvcNAQEFBQADggEBAIGEPql2 TALyKi/h1J+Mh5XolAtYppcSOLMtBkoA7ZovGBDNvl0VbZs8AAojJqkUoWBB+L6DKyl/jKhNfKcu rWRGRyj7pnbxrKLsI3gmWNWkyo2b60wJwe9fqPD5ZQy3oEiMit9l0Ba6il/k2GqYopUCNMa7mfeb E2LeBy5ChYMiCi97UQSJvAdzEYylTJw8Awc6AiM2Ve5N+XxsmKgNf/2A/5IJ3EZZ+wFRmkI4062A oNU302rqAt0HH88jzoUF4AfYHWl6HpYhGXFbcX44rHINyPmFBRxLYIFJ6ZWUr/mXpL/e6rqFtNWO kV6UoJND7OVZkbLh7F1+lcqXRU8TPBMwggOHMIICb6ADAgECAgRBtbHpMA0GCSqGSIb3DQEBBQUA MCkxDjAMBgNVBAoTBU5va2lhMRcwFQYDVQQDEw5Ob2tpYSAgUm9vdCBDQTAeFw0wNjAzMzAwOTU3 MTFaFw0xNjAxMDIxMTA1MDVaMDMxCzAJBgNVBAYTAkZJMQ4wDAYDVQQKEwVOb2tpYTEUMBIGA1UE AxMLTm9raWEgQkkgQ0EwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQDtFCg3QEjSCg6T IUxoWsNwELh8bBNiUQPCPmg8c2DHQYXWWCSCMb+S0Fvh1qqI1xt+XnzyFq+5eqzGzDj4UaBcG+d9 qxrCFly8sHyoPTryyPrR0EI2UUDWwfS6ojhqgwghRqo8G38TjFusyBtLub/5L6yvWYSOHD+JcB+q VM2fbkArPYK4Ydv8WG/DbHjGn0gKq0zwpVZKI/gCK/QALYvte02NXseqvY9/GOyLtjy3Z8erFv71 KKTq+gxI/7DK55pJf3PoD+kT4kyGm6EF9DTdK4ojMdar17uyX0IOZz/4vkkF0d+60nmnLX63FJPA jUyB0HUNJ32NXDo9UsM38aoNAgMBAAGjgawwgakwDwYDVR0TAQH/BAUwAwEB/zARBgNVHSAECjAI MAYGBFUdIAAwDgYDVR0PAQH/BAQDAgGGMFQGA1UdIwRNMEuAFI2N95+hDQAhMu+p7SKu4Dv00H2w oS2kKzApMQ4wDAYDVQQKEwVOb2tpYTEXMBUGA1UEAxMOTm9raWEgIFJvb3QgQ0GCBDpVqdkwHQYD VR0OBBYEFKcksD7Fg+8EDlB2Sxgy58pW0Sy6MA0GCSqGSIb3DQEBBQUAA4IBAQAC3lEUplDlVNOT Pjz/XFezXx2bV2XbCFindhA3F815Egi55H6/cYezEjoP4QLNEGGl2I3aLvkn5A0T8I4pbiFPhIiu B/frbbGg6k6GjQLe/bFQ8F1mAOOR+GyneKZFPfzaRV0jiIR9QqnMXTf8RvKkCJyFj10MZVsLIy/Y uBkzeP3JhzDhUdtPfwmJN6ZbIhH5uR/2BwAGtgQknb8WX3I4wnhWtMUxB8XmayayYs8qWYeIiVkI FV+sLTkWUWVvvKUjyakBpbAW2vUP84DYsJ8TL1YefNjf/nIOByMcORLuV/1gPjyv00qJbcB59AA+ iXe3zIo8QNcgXG0uPQQFmrGDMIID5DCCAsygAwIBAgIQMH5apak8lEy6LmLlLsJy8TANBgkqhkiG 9w0BAQUFADAzMQswCQYDVQQGEwJGSTEOMAwGA1UEChMFTm9raWExFDASBgNVBAMTC05va2lhIEJJ IENBMB4XDTExMDkwNjA1NTIwNFoXDTE0MDkwNjA1NTIwNFowVjEOMAwGA1UECgwFTm9raWExDzAN BgNVBAsMBlBlb3BsZTEYMBYGCgmSJomT8ixkAQEMCDEwMDI0Njc2MRkwFwYDVQQDDBBTYXZvbGFp bmVuIFRlZW11MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAshEsmw6Yiz6XWX26oF+I s5fsfE1OfCjOelclmtqCiIgXND5klkNOBs2d4ZGzgD9mN+XnTZnOTh249c2WxPBugf12DCcDmBAJ gL+VuWUJVBTE5NRchm/O8nZnZsRFst+gAC9/Juykh4+EYewZ7QbpnlwW7hNpj8eH+rMr+OZHKzdp KTftgVjmuF4JJ/cPMQUjL8SuGj+zBW6IWPOZdqkEMtf7Pr8kkYbZsh0SgJ0ceRHZ7Uc06mB/y+C1 UnJPxehTTdu8tpCjdzXgBw/H2uuW1J3qdHbCfbuDILql8V8RiZKubcZLhdsD3Jvj8qK0DGWBJa6x p90q5p3pLE8LvAeCgQIDAQABo4HQMIHNMA4GA1UdDwEB/wQEAwIEMDAfBgNVHSMEGDAWgBSnJLA+ xYPvBA5QdksYMufKVtEsujAZBgNVHSAEEjAQMA4GDCsGAQQBXgExBgEHAzA5BgNVHR8EMjAwMC6g LKAqhihodHRwOi8vY3JsLm5va2lhLmNvbS9Ob2tpYSUyMEJJJTIwQ0EuY3JsMCUGA1UdEQQeMByB GnRlZW11LnNhdm9sYWluZW5Abm9raWEuY29tMB0GA1UdDgQWBBQTRzvZsgmQrAGCeuzdHTGAC6Jg UzANBgkqhkiG9w0BAQUFAAOCAQEACmPVsdi07pjK5gDa+W5JlE2C74kVVsB8alBqfioYeR5At2FG B7sua4Dz5H7TJMpZ1jYFeI+zjexD5f+beY2IlV15lMoWD+5e38QlLYjwfe2LAyvdzBKXW0e0U6Bt p78ft4gyVak1X+Db+ebR+FNHUOMNhm+yK3w9sy5ZQzBFusIx4OgxGvcZhyhmd9WjipSTalgPwgqV Ju2aPADCG++OEXmgEWRLsR4yNopkgK4ftVqrN5uUtLs83qdeXTRcNRiET1IOx5zmYFZ6q3gjKIx5 iyuxcDeYas93vVHUcaRRYpsoby5CHq7Z/j/TQhtqO/knWuxLFFiCUgdGKMKrRkg29DCCBAowggLy oAMCAQICEQCBvi+p+bA/dBtBtybwA6YYMA0GCSqGSIb3DQEBBQUAMDMxCzAJBgNVBAYTAkZJMQ4w DAYDVQQKEwVOb2tpYTEUMBIGA1UEAxMLTm9raWEgQkkgQ0EwHhcNMTEwOTA2MDU1MDM0WhcNMTMw OTA1MDU1MDM0WjBWMQ4wDAYDVQQKDAVOb2tpYTEPMA0GA1UECwwGUGVvcGxlMRgwFgYKCZImiZPy LGQBAQwIMTAwMjQ2NzYxGTAXBgNVBAMMEFNhdm9sYWluZW4gVGVlbXUwggEiMA0GCSqGSIb3DQEB AQUAA4IBDwAwggEKAoIBAQDFPmbRVwuo52v+h6xnQUqokAx2xsHjmPBniEkzgtgBNJsFi838ATEg 1zsx+VotoJg7hMijcrQfpTAgW6gpLGnlmw5QQswrNK1zleOHb4pA5JguU3WhVKFkAH/6/2EU2k/9 m8Pb/gwP55cYg80R6fRmbdsWKhseXF/1isW/rJcWLmIYDg/rXfo3ixqtT9MroAMiuoXnb0ij1L2d Jj64LDp3Ld8Jo0qZzk3Fj4apo8PBd8eAH6HloVBJkxQcwAnv561A+Xi1GHZ2mafRYJGO+1uBDwyd g/8ybEXXA4MKo8lPKjBebYBUFvz80DBA/Lq74UysXkG23BSulcG4xQSYGlyzAgMBAAGjgfUwgfIw HwYDVR0jBBgwFoAUpySwPsWD7wQOUHZLGDLnylbRLLowGQYDVR0gBBIwEDAOBgwrBgEEAV4BMQYB BgQwOQYDVR0fBDIwMDAuoCygKoYoaHR0cDovL2NybC5ub2tpYS5jb20vTm9raWElMjBCSSUyMENB LmNybDAjBgNVHSUEHDAaBggrBgEFBQcDAgYEVR0lAAYIKwYBBQUHAwQwDgYDVR0PAQH/BAQDAgeA MCUGA1UdEQQeMByBGnRlZW11LnNhdm9sYWluZW5Abm9raWEuY29tMB0GA1UdDgQWBBTGhbTJF0EX iagjymQo6GIuSQeRVDANBgkqhkiG9w0BAQUFAAOCAQEAqai6TxZ/BlMHZIhJNPriBPXkQhUlBkGA buJZ5sVm1HIQhWN8elZKjjJdHi1qWEKhMg7yHjEMZsyV8XAZzK0UnOqkpUnt+jnVkNZ9O7/jRtyK f4WUtq5jErc8Hlv4bbGFRHk1T7AuLLE52r1lYOdmoibnQp03QtlDvHUNa68G7jvzThJhieB7U1xh vH3yy0ktaVnWEgAylqf9yIUFjnqau5R6cE1Xo57IYPk/KitX0YF+OigEI/bOQVMi+fze93ZsAOJv /z6g/NGemvUgl5YSdX0uPQK6kEHf/sp/nZyUWWQ7OjtVSqkq2YuYEueQFxTfafl+78GWqgm6W/Bl 32laYzGCAuswggLnAgEBMEgwMzELMAkGA1UEBhMCRkkxDjAMBgNVBAoTBU5va2lhMRQwEgYDVQQD EwtOb2tpYSBCSSBDQQIRAIG+L6n5sD90G0G3JvADphgwCQYFKw4DAhoFAKCCAXgwGAYJKoZIhvcN AQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG9w0BCQUxDxcNMTEwOTE0MTM1NTM5WjAjBgkqhkiG9w0B CQQxFgQU6x3CPrUmfIoeen1aZAFN046Od/YwVgYJKwYBBAGCNxAEMUkwRzAzMQswCQYDVQQGEwJG STEOMAwGA1UEChMFTm9raWExFDASBgNVBAMTC05va2lhIEJJIENBAhAwflqlqTyUTLouYuUuwnLx MFgGCyqGSIb3DQEJEAILMUmgRzAzMQswCQYDVQQGEwJGSTEOMAwGA1UEChMFTm9raWExFDASBgNV BAMTC05va2lhIEJJIENBAhAwflqlqTyUTLouYuUuwnLxMGcGCSqGSIb3DQEJDzFaMFgwCgYIKoZI hvcNAwcwDgYIKoZIhvcNAwICAgCAMA0GCCqGSIb3DQMCAgFAMAcGBSsOAwIHMA0GCCqGSIb3DQMC AgEoMAcGBSsOAwIaMAoGCCqGSIb3DQIFMA0GCSqGSIb3DQEBAQUABIIBAFz3c+sQzhunX2YH2E7n 6GyLez7IGR2wrxVmwGtU8JghaFi9qiflnqvox3cZbszdlAW7az+qUzwyGiEl7skvwwPBJ5IVhttw Zxg22zq2OE0IMiNw4fJ4rgOzNXYA8Ebn+sx8/2tF8P39t+KRxOkMZwufBjF0geCrfSrN1hcOg4NM LK9TKeoBvfhrL5isYJfqTr09kUQrMhAnoeXm8BrJJZkeDy5gRy9ULwxSnp2lNjVyyPMGECOXfumY LkPA4OoADvGy+2KaGUSDWrHGG7NtgjfsCl0eU7Jm77aXgLAXmpMLiKSNOdWXY6GRpOpfHbBFswfd mfTE/gLmmuz2yN5582oAAAAAAAA= ------=_NextPart_000_0158_01CC72FF.21E75F20-- From teemu.savolainen@nokia.com Thu Sep 15 03:55: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 AB6E821F87C2 for ; Thu, 15 Sep 2011 03:55:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.091 X-Spam-Level: X-Spam-Status: No, score=-2.091 tagged_above=-999 required=5 tests=[AWL=-0.692, BAYES_00=-2.599, J_CHICKENPOX_13=0.6, J_CHICKENPOX_54=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 qijUk8mHMaqX for ; Thu, 15 Sep 2011 03:55:12 -0700 (PDT) Received: from mgw-da02.nokia.com (smtp.nokia.com [147.243.128.26]) by ietfa.amsl.com (Postfix) with ESMTP id 67A6521F85F6 for ; Thu, 15 Sep 2011 03:55:12 -0700 (PDT) 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.3) with ESMTP id p8FAumec019493; Thu, 15 Sep 2011 13:57:22 +0300 Received: from smtp.mgd.nokia.com ([65.54.30.5]) by vaebh102.NOE.Nokia.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.4675); Thu, 15 Sep 2011 13:57:01 +0300 Received: from 008-AM1MMR1-006.mgdnok.nokia.com (65.54.30.61) by NOK-am1MHUB-01.mgdnok.nokia.com (65.54.30.5) with Microsoft SMTP Server (TLS) id 8.2.255.0; Thu, 15 Sep 2011 12:57:01 +0200 Received: from 008-AM1MPN1-032.mgdnok.nokia.com ([169.254.2.143]) by 008-AM1MMR1-006.mgdnok.nokia.com ([65.54.30.61]) with mapi id 14.01.0323.007; Thu, 15 Sep 2011 12:57:00 +0200 From: To: Thread-Topic: apps-team review of draft-ietf-mif-dns-server-selection Thread-Index: AcxyrBw6zVCShQsaRQaFoCi5Am4oqAALTEuAAAtSoYAAHq+RsA== Date: Thu, 15 Sep 2011 10:57:00 +0000 Message-ID: <916CE6CF87173740BC8A2CE4430969620257496F@008-AM1MPN1-032.mgdnok.nokia.com> References: <916CE6CF87173740BC8A2CE44309696202573D36@008-AM1MPN1-032.mgdnok.nokia.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes 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+/nZJb9Kg7Io6FujjSfNcXJGUP9WUdfQoJmpfVHi50dPq5KK9wdv8YWMOnlWEAV7vitTS8DUHPOf+v+0rDoqIXDlYBGAkr4aFmlVX72DYkzc7FMyhxe1AE8JaiM8N+owe8T46p+5odYFpcc3S+UERsY5D3pIS96GmVqZGZtQWAUs09Yxm1Ek/ZYVTro9BId1kuOpfCWBge+hJ0ptecrs9ytVuIdhk7jdg+3nvOdW/pcJuz+sJe2aL250googH0+uPDSPjEzpjeNw== x-originating-ip: [10.162.78.119] Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=SHA1; boundary="----=_NextPart_000_01C9_01CC73AF.5559A0B0" MIME-Version: 1.0 X-OriginalArrivalTime: 15 Sep 2011 10:57:01.0514 (UTC) FILETIME=[326C2AA0:01CC7396] X-Nokia-AV: Clean Cc: mif@ietf.org Subject: Re: [mif] apps-team review of draft-ietf-mif-dns-server-selection X-BeenThere: mif@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multiple Interface Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 15 Sep 2011 10:55:13 -0000 ------=_NextPart_000_01C9_01CC73AF.5559A0B0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Hi, inline > -----Original Message----- > From: ext Murray S. Kucherawy [mailto:msk@cloudmark.com] > Sent: 14. syyskuuta 2011 21:21 > To: Savolainen Teemu (Nokia-CTO/Tampere) > Cc: apps-review@ietf.org; apps-ads@tools.ietf.org > Subject: RE: apps-team review of draft-ietf-mif-dns-server-selection > > Fine with me, though I can't reply to mif since I'm not on it so I've > dropped it > from this reply. Feel free to forward this as well. And I can't send to apps-review nor apps-ads, so I'll reply to MIF - hence mailing lists will get every other mail.. > I still think the use of "suffix" is odd, though it's hard to argue that > it's > technically incorrect. For foobar.nokia.com, I would think "nokia.com" is > the > domain name, not a suffix attached to the name "foobar". I'd be more > comfortable with calling "foobar" a prefix, but even that doesn't seem right > to me. > > If you really like the term "suffix", I suggest putting a paragraph > somewhere > early on saying "When we use the term 'DNS suffix', we actually mean a > domain name that is the root of future queries in common" or something like > that. I really liked:) But I looked a bit to RFC3397 (DHCP Domain Search Option) and as that used solely "domain" term, I now remove all "suffix" instances and now that text e.g. says: -- To build the list in an optimal way, a node SHOULD ask with DHCP which DNS servers of each network interface are most likely to be able to successfully serve forward lookup requests matching to specific domain or reverse (PTR record) lookup requests matching to specific network addresses (later referred as "network"). -- > I suggest: > > It is worth noting is that network specific IP addresses can cause > problems also for a single-homed node, if the node retains DNS cache during > movement from one network to another. After the network change, a node > may > have entries in its DNS cache that are no longer correct or appropriate for > its > new network position. Copied as proposed. > OK. In that case, I suggest that this be stated either before the normative > stuff begins, or along with it, to show how important it is that this be the > way > things are done. > > Another approach would be to spell out the security implications of not > precisely following the algorithm later on in Section 10. How about following Security section (I also now splitted it into subtopics): 10. Security Considerations 10.1. Attack vectors It is possible that attackers might try to utilize OPTION_DNS_SERVER_SELECT option to redirect some or all DNS queries sent by a resolver to undesired destinations. The purpose of an attack might be denial-of-service, preparation for man-in-the-middle attack, or something akin. Attackers might try to lure specific traffic by advertising domains and networks from very small to very large scope or simply by trying to place attacker's DNS server as the highest priority default server. The best countermeasure for nodes is to implement validating DNSSEC aware resolvers. Trusting on validation done by a DNS server is a possibility only if a node trusts the DNS server and can use a secure channel for DNS messages. 10.2. Trust levels of network interfaces Decision on trust levels of network interfaces depends very much on deployment scenario and types of network interfaces. For example, unmanaged WLAN may be considered less trustworthy than managed cellular or VPN connections. The decision on levels of trust may be made by implementation, by node administrators, or for example by other standards defining organizations as part of system design work. 10.3. Importance of following the algorithm The Section 4 uses normative language for describing node internal behavior in order to ensure nodes would not open up new attack vectors by accidental use of DNS server selection options. During the standards work consensus was that it is safer to not to enable this option always by default, but only when deemed useful and safe. > > The -04 version should have cleared several > > of these "IPv6 focus" issues (by talking about network addresses instead > > of > > prefixes), but I guess checking again would not hurt. On the other hand, > > IPv6 really is the focus here, as multi-interface behavior with IPv4 > > anyway > > is terrible mess due widespread usage of RFC1918 addressed networks (and > > that's why I'm secretly hoping DHC WG would say they don't want to use > DHCP > > option code for this option and hence this technology must be IPv6- > > only:-D. > > This is also text you might want to add in there, perhaps in a later section > or > an appendix, explaining why doing this in IPv4 space is more challenging. > Referring to another document that already discusses this is fine as well. I'm not sure this document is best for that discussion (because it is way larger than DNS server selection )... the mif problem statement section 4.1 situation 4 and section 4.2 situation 3 refers already to this problem, and that draft is referred first thing in section 1. > I think the thing that's nagging me the most about 4.1 is this: "Therefore, > a > DNSSEC-aware resolver MUST NOT proceed with a reply that cannot be > validated using DNSSEC if DNS queries sent to other servers are still > pending." > If my node is DNSSEC-aware and connected simultaneously to the public > internet and a corporate VPN, but neither the public nameserver nor the one > on the corporate VPN use DNSSEC, then by this rule my node can't use any > reply at all. It seems to me that ought to be a SHOULD NOT, because this is > a > case where my resolver can just use whatever replies it gets. > > It could also be that you're saying you SHOULD NOT use any replies until (a) > you get a DNSSEC one back or (b) you get all of them back and none of them > are DNSSEC-protected in which case you can use any of them at your > discretion. If that's the case, then you should say so. It seems we indeed need to clarify this one. The text misses a paragraph even it seems. This is actually quite big issue I'm afraid and probably Andrew and Ted have something to say as well.. For both DNSSEC-aware and DNSSEC-unaware cellular devices it is extremely important that in the common case DNS queries are not always sent out via all interfaces, as that would consume way too much battery. A tradeoff decision. Can you btw know in advanced whether a DNS server (like behind VPN) is able to perform validation or not before receiving answer from them? Would it be useful information to learn via this option "bit for telling if DNS resolver supports validation"? I'm now adding following key paragraph to section 4.1 (including moving some text from other paragraphs there). Please comment: -- A node SHALL send requests to DNS servers in the order defined by the priority list until an acceptable reply is received, all replies are received, or a time out occurs. In the case of a requested name matching to a specific domain or network rule accepted from any interface, a DNSSEC-aware resolver MUST NOT proceed with a reply that cannot be validated using DNSSEC until all DNS servers on the priority list have been contacted or timed out. This protects against possible redirection attacks. In the case of the requested name not matching to any specific domain or network, first received response from any DNS server MAY be considered acceptable. A DNSSEC- aware node MAY always contact all DNS server in an attempt to receive a response that can be validated, but contacting all DNS servers is not mandated for the default case as in some deployments that would consume excess resources. -- > You might just keep everything and rank them in decreasing order of trust, > evaluated through some appropriate means (known friendly networks first, > secured networks second, public networks third), and then search top-to- > bottom when you're preparing to send a query. That's just off the top of my > head though; you guys are the experts here. :-) Sounds too complex... What if just allowing appending the information if received from different DHCPv6 server but same interface, and not accepting an option for each DNS server only once and from the most trusted interface. So have it like this instead, then: -- If the OPTION_DNS_SERVER_SELECT contains a DNS server address already learned from other DHCPv6 servers of the same network, and contains new domains or networks, the node SHOULD append the information to the information received earlier. The node MUST NOT remove previously obtained information. However, the node SHOULD NOT extent lifetime of earlier information either. In the case of conflicting DNS server address is learned from less trusted interface, the node MUST ignore the new information. -- > Fair enough. It's a minor point, but I would probably be more comfortable > with: > > Use of OPTION_DNS_SERVER_SELECT is ideal in the following environments, > but SHOULD NOT be enabled by default otherwise: Hmm.. I guess the old text of "MUST NOT unless configured to do so" equals meaning of "SHOULD NOT". Changing as you proposed unless someone raises voices against? > Your call; removing it is fine, pointing the reader to a useful technology > to fill > that gap is fine too. I think I'll leave it out for now, let's see if others have comments. E.g. BBF that refers to this document refers also those address selection documents.. and also the v6ops doc I mentioned. > > trademarked. I suggest "wireless network". > > > > Teemu>That part was removed at the same time the text talking about > leaking > > names was removed.. > > Why was that removed? I thought it was a good point. Because Andrew was very strongly against that point - i.e. against even hinting that it might be somehow possible to keep private namespaces private. > Good work, thanks for your response! Thanks, and thank you for good review (that is triggering major clarifications). Best regards, Teemu ------=_NextPart_000_01C9_01CC73AF.5559A0B0 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIOuzCCAzYw ggIeoAMCAQICBDpVqdkwDQYJKoZIhvcNAQEFBQAwKTEOMAwGA1UEChMFTm9raWExFzAVBgNVBAMT Dk5va2lhICBSb290IENBMB4XDTAxMDEwNTExMDUwNVoXDTE2MDEwMjExMDUwNVowKTEOMAwGA1UE ChMFTm9raWExFzAVBgNVBAMTDk5va2lhICBSb290IENBMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8A MIIBCgKCAQEAsrTy8gLmr4LYvp0khVUVHw7ascdl+Cjr+yI5MlZ6J/U6Qsvkiqthgqq8rPcLV0P1 92TfBr27VgKEeCaZe0icS1jC2spM/wRv3j2WxdkKxb9kDJtuCNJaRBqvi5vGTHB15nmEmKuL5f3i rAxeHqPjgS496oWcudzFT1e7Xrc/gWGFYd72+/ykIFXjWOMZv6QpxD8x1hLPyh2YVXRk9U7N7pvm RQNX29g4SCFJY2BBIa5JPlwIF8Nc9IePaC/E/2M4tGMtiOOZlm99EoL7N0hJZtFSvUwdCBud/viH 4DgsKGjNkNKi6pAHc9IaXB6tIykcoYp+L+oe/3+cuEJaCj1EKwIDAQABo2YwZDASBgNVHRMBAf8E CDAGAQH/AgEEMB0GA1UdDgQWBBSNjfefoQ0AITLvqe0iruA79NB9sDAfBgNVHSMEGDAWgBSNjfef oQ0AITLvqe0iruA79NB9sDAOBgNVHQ8BAf8EBAMCAYYwDQYJKoZIhvcNAQEFBQADggEBAIGEPql2 TALyKi/h1J+Mh5XolAtYppcSOLMtBkoA7ZovGBDNvl0VbZs8AAojJqkUoWBB+L6DKyl/jKhNfKcu rWRGRyj7pnbxrKLsI3gmWNWkyo2b60wJwe9fqPD5ZQy3oEiMit9l0Ba6il/k2GqYopUCNMa7mfeb E2LeBy5ChYMiCi97UQSJvAdzEYylTJw8Awc6AiM2Ve5N+XxsmKgNf/2A/5IJ3EZZ+wFRmkI4062A oNU302rqAt0HH88jzoUF4AfYHWl6HpYhGXFbcX44rHINyPmFBRxLYIFJ6ZWUr/mXpL/e6rqFtNWO kV6UoJND7OVZkbLh7F1+lcqXRU8TPBMwggOHMIICb6ADAgECAgRBtbHpMA0GCSqGSIb3DQEBBQUA MCkxDjAMBgNVBAoTBU5va2lhMRcwFQYDVQQDEw5Ob2tpYSAgUm9vdCBDQTAeFw0wNjAzMzAwOTU3 MTFaFw0xNjAxMDIxMTA1MDVaMDMxCzAJBgNVBAYTAkZJMQ4wDAYDVQQKEwVOb2tpYTEUMBIGA1UE AxMLTm9raWEgQkkgQ0EwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQDtFCg3QEjSCg6T IUxoWsNwELh8bBNiUQPCPmg8c2DHQYXWWCSCMb+S0Fvh1qqI1xt+XnzyFq+5eqzGzDj4UaBcG+d9 qxrCFly8sHyoPTryyPrR0EI2UUDWwfS6ojhqgwghRqo8G38TjFusyBtLub/5L6yvWYSOHD+JcB+q VM2fbkArPYK4Ydv8WG/DbHjGn0gKq0zwpVZKI/gCK/QALYvte02NXseqvY9/GOyLtjy3Z8erFv71 KKTq+gxI/7DK55pJf3PoD+kT4kyGm6EF9DTdK4ojMdar17uyX0IOZz/4vkkF0d+60nmnLX63FJPA jUyB0HUNJ32NXDo9UsM38aoNAgMBAAGjgawwgakwDwYDVR0TAQH/BAUwAwEB/zARBgNVHSAECjAI MAYGBFUdIAAwDgYDVR0PAQH/BAQDAgGGMFQGA1UdIwRNMEuAFI2N95+hDQAhMu+p7SKu4Dv00H2w oS2kKzApMQ4wDAYDVQQKEwVOb2tpYTEXMBUGA1UEAxMOTm9raWEgIFJvb3QgQ0GCBDpVqdkwHQYD VR0OBBYEFKcksD7Fg+8EDlB2Sxgy58pW0Sy6MA0GCSqGSIb3DQEBBQUAA4IBAQAC3lEUplDlVNOT Pjz/XFezXx2bV2XbCFindhA3F815Egi55H6/cYezEjoP4QLNEGGl2I3aLvkn5A0T8I4pbiFPhIiu B/frbbGg6k6GjQLe/bFQ8F1mAOOR+GyneKZFPfzaRV0jiIR9QqnMXTf8RvKkCJyFj10MZVsLIy/Y uBkzeP3JhzDhUdtPfwmJN6ZbIhH5uR/2BwAGtgQknb8WX3I4wnhWtMUxB8XmayayYs8qWYeIiVkI FV+sLTkWUWVvvKUjyakBpbAW2vUP84DYsJ8TL1YefNjf/nIOByMcORLuV/1gPjyv00qJbcB59AA+ iXe3zIo8QNcgXG0uPQQFmrGDMIID5DCCAsygAwIBAgIQMH5apak8lEy6LmLlLsJy8TANBgkqhkiG 9w0BAQUFADAzMQswCQYDVQQGEwJGSTEOMAwGA1UEChMFTm9raWExFDASBgNVBAMTC05va2lhIEJJ IENBMB4XDTExMDkwNjA1NTIwNFoXDTE0MDkwNjA1NTIwNFowVjEOMAwGA1UECgwFTm9raWExDzAN BgNVBAsMBlBlb3BsZTEYMBYGCgmSJomT8ixkAQEMCDEwMDI0Njc2MRkwFwYDVQQDDBBTYXZvbGFp bmVuIFRlZW11MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAshEsmw6Yiz6XWX26oF+I s5fsfE1OfCjOelclmtqCiIgXND5klkNOBs2d4ZGzgD9mN+XnTZnOTh249c2WxPBugf12DCcDmBAJ gL+VuWUJVBTE5NRchm/O8nZnZsRFst+gAC9/Juykh4+EYewZ7QbpnlwW7hNpj8eH+rMr+OZHKzdp KTftgVjmuF4JJ/cPMQUjL8SuGj+zBW6IWPOZdqkEMtf7Pr8kkYbZsh0SgJ0ceRHZ7Uc06mB/y+C1 UnJPxehTTdu8tpCjdzXgBw/H2uuW1J3qdHbCfbuDILql8V8RiZKubcZLhdsD3Jvj8qK0DGWBJa6x p90q5p3pLE8LvAeCgQIDAQABo4HQMIHNMA4GA1UdDwEB/wQEAwIEMDAfBgNVHSMEGDAWgBSnJLA+ xYPvBA5QdksYMufKVtEsujAZBgNVHSAEEjAQMA4GDCsGAQQBXgExBgEHAzA5BgNVHR8EMjAwMC6g LKAqhihodHRwOi8vY3JsLm5va2lhLmNvbS9Ob2tpYSUyMEJJJTIwQ0EuY3JsMCUGA1UdEQQeMByB GnRlZW11LnNhdm9sYWluZW5Abm9raWEuY29tMB0GA1UdDgQWBBQTRzvZsgmQrAGCeuzdHTGAC6Jg UzANBgkqhkiG9w0BAQUFAAOCAQEACmPVsdi07pjK5gDa+W5JlE2C74kVVsB8alBqfioYeR5At2FG B7sua4Dz5H7TJMpZ1jYFeI+zjexD5f+beY2IlV15lMoWD+5e38QlLYjwfe2LAyvdzBKXW0e0U6Bt p78ft4gyVak1X+Db+ebR+FNHUOMNhm+yK3w9sy5ZQzBFusIx4OgxGvcZhyhmd9WjipSTalgPwgqV Ju2aPADCG++OEXmgEWRLsR4yNopkgK4ftVqrN5uUtLs83qdeXTRcNRiET1IOx5zmYFZ6q3gjKIx5 iyuxcDeYas93vVHUcaRRYpsoby5CHq7Z/j/TQhtqO/knWuxLFFiCUgdGKMKrRkg29DCCBAowggLy oAMCAQICEQCBvi+p+bA/dBtBtybwA6YYMA0GCSqGSIb3DQEBBQUAMDMxCzAJBgNVBAYTAkZJMQ4w DAYDVQQKEwVOb2tpYTEUMBIGA1UEAxMLTm9raWEgQkkgQ0EwHhcNMTEwOTA2MDU1MDM0WhcNMTMw OTA1MDU1MDM0WjBWMQ4wDAYDVQQKDAVOb2tpYTEPMA0GA1UECwwGUGVvcGxlMRgwFgYKCZImiZPy LGQBAQwIMTAwMjQ2NzYxGTAXBgNVBAMMEFNhdm9sYWluZW4gVGVlbXUwggEiMA0GCSqGSIb3DQEB AQUAA4IBDwAwggEKAoIBAQDFPmbRVwuo52v+h6xnQUqokAx2xsHjmPBniEkzgtgBNJsFi838ATEg 1zsx+VotoJg7hMijcrQfpTAgW6gpLGnlmw5QQswrNK1zleOHb4pA5JguU3WhVKFkAH/6/2EU2k/9 m8Pb/gwP55cYg80R6fRmbdsWKhseXF/1isW/rJcWLmIYDg/rXfo3ixqtT9MroAMiuoXnb0ij1L2d Jj64LDp3Ld8Jo0qZzk3Fj4apo8PBd8eAH6HloVBJkxQcwAnv561A+Xi1GHZ2mafRYJGO+1uBDwyd g/8ybEXXA4MKo8lPKjBebYBUFvz80DBA/Lq74UysXkG23BSulcG4xQSYGlyzAgMBAAGjgfUwgfIw HwYDVR0jBBgwFoAUpySwPsWD7wQOUHZLGDLnylbRLLowGQYDVR0gBBIwEDAOBgwrBgEEAV4BMQYB BgQwOQYDVR0fBDIwMDAuoCygKoYoaHR0cDovL2NybC5ub2tpYS5jb20vTm9raWElMjBCSSUyMENB LmNybDAjBgNVHSUEHDAaBggrBgEFBQcDAgYEVR0lAAYIKwYBBQUHAwQwDgYDVR0PAQH/BAQDAgeA MCUGA1UdEQQeMByBGnRlZW11LnNhdm9sYWluZW5Abm9raWEuY29tMB0GA1UdDgQWBBTGhbTJF0EX iagjymQo6GIuSQeRVDANBgkqhkiG9w0BAQUFAAOCAQEAqai6TxZ/BlMHZIhJNPriBPXkQhUlBkGA buJZ5sVm1HIQhWN8elZKjjJdHi1qWEKhMg7yHjEMZsyV8XAZzK0UnOqkpUnt+jnVkNZ9O7/jRtyK f4WUtq5jErc8Hlv4bbGFRHk1T7AuLLE52r1lYOdmoibnQp03QtlDvHUNa68G7jvzThJhieB7U1xh vH3yy0ktaVnWEgAylqf9yIUFjnqau5R6cE1Xo57IYPk/KitX0YF+OigEI/bOQVMi+fze93ZsAOJv /z6g/NGemvUgl5YSdX0uPQK6kEHf/sp/nZyUWWQ7OjtVSqkq2YuYEueQFxTfafl+78GWqgm6W/Bl 32laYzGCAuswggLnAgEBMEgwMzELMAkGA1UEBhMCRkkxDjAMBgNVBAoTBU5va2lhMRQwEgYDVQQD EwtOb2tpYSBCSSBDQQIRAIG+L6n5sD90G0G3JvADphgwCQYFKw4DAhoFAKCCAXgwGAYJKoZIhvcN AQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG9w0BCQUxDxcNMTEwOTE1MTA1NjU3WjAjBgkqhkiG9w0B CQQxFgQUnPmNKT01zsKq1BnAtzc76zYY3+gwVgYJKwYBBAGCNxAEMUkwRzAzMQswCQYDVQQGEwJG STEOMAwGA1UEChMFTm9raWExFDASBgNVBAMTC05va2lhIEJJIENBAhAwflqlqTyUTLouYuUuwnLx MFgGCyqGSIb3DQEJEAILMUmgRzAzMQswCQYDVQQGEwJGSTEOMAwGA1UEChMFTm9raWExFDASBgNV BAMTC05va2lhIEJJIENBAhAwflqlqTyUTLouYuUuwnLxMGcGCSqGSIb3DQEJDzFaMFgwCgYIKoZI hvcNAwcwDgYIKoZIhvcNAwICAgCAMA0GCCqGSIb3DQMCAgFAMAcGBSsOAwIHMA0GCCqGSIb3DQMC AgEoMAcGBSsOAwIaMAoGCCqGSIb3DQIFMA0GCSqGSIb3DQEBAQUABIIBADNN+HclCYJYcWI8YSsM gcR6o5HilxOB2ooKMO2Y/kj80BnTt+sFlcMbSusVfGMUGXVdXS6ZjYwsyph2PRkdbjjERzbrjXqT ki2mEoWfyJbIBorU4nEzATqovoXC63Cebuvw8yXbwOZsULafuUudrqiC1thLD5V88aY5ftokRRpI 53IfkQN335c7QNDbFvpUPkBSjamFCI2SM58Wv1YEVnd8ouWQYUL/Qc/1eR+RHh7izY/sumdGnY47 toT5l8rrSmV6QKWTc9Iufxrhp1WLPQkPCzlXipYi+LlC0HG3jvY6nHdc0bzscVgHNqJublDB8LL0 YFUHnxKnKR6BGBgLFxcAAAAAAAA= ------=_NextPart_000_01C9_01CC73AF.5559A0B0-- From denghui02@gmail.com Thu Sep 15 22:40: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 F265A21F8B8C for ; Thu, 15 Sep 2011 22:40:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.494 X-Spam-Level: X-Spam-Status: No, score=-103.494 tagged_above=-999 required=5 tests=[AWL=0.104, 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 rgSwMIVtloWO for ; Thu, 15 Sep 2011 22:40:15 -0700 (PDT) Received: from mail-ww0-f44.google.com (mail-ww0-f44.google.com [74.125.82.44]) by ietfa.amsl.com (Postfix) with ESMTP id 6D9C321F8B8A for ; Thu, 15 Sep 2011 22:40:15 -0700 (PDT) Received: by wwf22 with SMTP id 22so3162069wwf.13 for ; Thu, 15 Sep 2011 22:42:28 -0700 (PDT) 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=bNSQ+9/e+Re+MzREsDLtjjkCiHPL6/xTgUqgAAUxtPA=; b=KrHqnW78GphGQ+cWE1Xr+nZzMD0EIlCN5/cxnSfAmpRFIQCdIWlTzJw8ymk8uPfCDD CGU1WJ9I/PJiWMZi2eXzJxt9N9HxNMi8xQW9PZJ6JsJytOmlwTyrr2aL/XPnyu/JZXYf 1yCBjwzNKpZJ/6DBjxHFrGGzJTAVyPsNwPBX8= MIME-Version: 1.0 Received: by 10.216.6.211 with SMTP id 61mr1912824wen.94.1316151747345; Thu, 15 Sep 2011 22:42:27 -0700 (PDT) Received: by 10.216.186.13 with HTTP; Thu, 15 Sep 2011 22:42:27 -0700 (PDT) In-Reply-To: <916CE6CF87173740BC8A2CE44309696202573B89@008-AM1MPN1-032.mgdnok.nokia.com> References: <3CF88B99A9ED504197498BC6F6F04B81040FBDA9@XMB-BGL-41E.cisco.com> <4E6E7A72.9030208@gmail.com> <4E6EAFC2.5060906@gmail.com> <4E6EDEA8.3080108@gmail.com> <4E6F825C.3080303@gmail.com> <3D0B3661-8A8F-4BB2-A8EF-25007BEAF66C@nominum.com> <4E6F923F.7090304@gmail.com> <7061CEB8-8084-41D5-B31E-9F8E3B6C7091@nominum.com> <4E6F9B91.7010503@gmail.com> <4E6FA64E.7020801@gmail.com> <82337D11-0A39-4A10-AA0E-1E81B09DBA4F@nominum.com> <4E6FACF6.5000007@viagenie.ca> <4E6FC0AE.5000108@gmail.com> <916CE6CF87173740BC8A2CE4430969620257327E@008-AM1MPN1-032.mgdnok.nokia.com> <4E6FD930.7040401@gmail.com> <916CE6CF87173740BC8A2CE443096962025734A7@008-AM1MPN1-032.mgdnok.nokia.com> <4E7070B5.6080900@gmail.com> <916CE6CF87173740BC8A2CE44309696202573B89@008-AM1MPN1-032.mgdnok.nokia.com> Date: Fri, 16 Sep 2011 13:42:27 +0800 Message-ID: From: Hui Deng To: teemu.savolainen@nokia.com Content-Type: multipart/alternative; boundary=0016364c77655efdd104ad08759c Cc: mif@ietf.org Subject: Re: [mif] Comments on draft-mouton-mif-dhcpv6-drlo-00 X-BeenThere: mif@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multiple Interface Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 16 Sep 2011 05:40:17 -0000 --0016364c77655efdd104ad08759c Content-Type: text/plain; charset=ISO-8859-1 Hello all Observations from the mailing list discussion about this draft is: the Scenario author proposed related to 3GPP is not valid based on current specification. Because SLAAC is always used and UE gets its IPv6 default route that way, there is currently no need to use DHCPv6 to specify default routes. So whether we would like to have different option for default route option have to wait for future evolution opportunity. could I summarize the discussion like Whether we need to specify future purpose option at this moment? Thanks for this detail discussion -Hui 2011/9/14 > > In many places the term "default prefix" is used. For example like this: > > > IPv6 Prefix Delegation via DHCPv6 Optionally a single network prefix > > > shorter than the default /64 prefix may be assigned to a PDN > > > connection. In this case, the /64 default prefix used for IPv6 > > > stateless autoconfiguration will be allocated from this network prefix > > > > This is difficult to understand because SLAAC has no "default prefix" > > (grep rfc4862). > > It refers to unique /64 prefix allocated for a PDN connection. > > > 24.301-a30 says often GW allocates via RA like this: > > > The PDN GW allocates a globally unique /64 IPv6 prefix via Router > > > Advertisement to a given UE. > > > > But this is so difficult for me to understand because RA RFC text never > says > > an RA "allocates" some prefix. This allocation action is typically a > DHCP > > action, not RA. The RA simply advertises an allocation already done by > DHCP > > or administrator or ospf. > > Maybe the terminology is not clearest, but it means /64 prefix is > advertised > to the PDN connection. It is different topic then where the PDN GW got the > addresses (statically allocated pool or by DHCPv6 or whatever means). > > The "allocate" text probably comes from the view that it is P-t-P > connection > between UE and PDN GW and hence there is just single UE that "gets" the > whole /64 "allocated" for its use. > > > In a number of other places the 3GPP spec is incoherent with respect to > who > > is the "Requesting Router" - the UE or the PDN GW (at a moment the GW is > a > > DHCP client requesting a prefix, at another moment it is the UE being a > > requesting router). For me it is not clear how a Requesting Router below > > another Requesting Router can work. > > In my understanding the PDN GW can use DHCPv6 Prefix Delegation to get an > address pool from where to "advertise" /64s for different UEs PDN > connections. > > Additionally, in rel-10, also UE connected to PDN GW can use DHCPv6 Prefix > Delegation to get prefixes for advertisement on local area networks (such > as > "MiFi hotspot"). > > > It is unclear to me why the 23401 3GPP spec says that "The UE acts as a > > "Requesting Router"" requesting a Prefix. An entire Prefix (in addition > to the > > onlink prefixes) is useful only if that UE is a Mobile Router, giving > addresses > > further to some LFNs. Otherwise it is not clear why do Prefix Delegation > to a > > UE Requesting Router. Yet the spec never says "Mobile Router". > > UE acts as requesting router in order to behave as a router. I understand > not using term Mobile Router there, as the UE does not necessarily > implement > any "IP Mobility" solutions (e.g. DSMIP6). UE just acts as a router. > > > If it makes sense for this UE to actually be a MR, and to run DHCPv6-PD > then > > it could make sense to use DHCPv6 for address and default route > > configuration as well, instead of DHCPv6+SLAAC - simply the number of > > messages is reduced, and configuration of addresses/routes/prefixes is > > centralizely managed. > > It could, but as of now it is not specified to be possible. 3GPP UE always > uses SLAAC to number its cellular WAN interface (unnumbered model is not > supported), including getting default route pointing to cellular interface. > After SLAAC, UE acting as router MAY use DHCPv6 PD to get prefixes for > advertisement in "southbound" local area networks. > > Because SLAAC is always used and UE gets its IPv6 default route that way, > there is currently no need to use DHCPv6 to specify default routes. > > As always, things may change in the future and that's one reason why I'm ok > for defining default route option for DHCPv6. > > Best regards, > > Teemu > > _______________________________________________ > mif mailing list > mif@ietf.org > https://www.ietf.org/mailman/listinfo/mif > > --0016364c77655efdd104ad08759c Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Hello all
=A0
Observations from the mailing list discussion about this draft is:
the Scenario author proposed related to 3GPP is not valid based on cur= rent specification.
Because SLAAC is always used and UE gets its IPv6 default route that w= ay,
there is currently no need to use DHCPv6 to specify default routes.<= br>So whether=A0we would like to have different option for default route op= tion have to wait for future evolution opportunity.
=A0
could I summarize the discussion like
Whether we need to specify future purpose option at this moment?
=A0
Thanks for this detail discussion
=A0
-Hui

2011/9/14 <teemu.savolainen@nokia.com>
> In many places the term "default prefix" i= s used. =A0For example like this:
> > IPv6 Prefix Delegation via D= HCPv6 Optionally a single network prefix
> > shorter than the defa= ult /64 prefix may be assigned to a PDN
> > connection. In this case, the /64 default prefix used for IPv6> > stateless autoconfiguration will be allocated from this network = prefix
>
> This is difficult to understand because SLAAC has no= "default prefix"
> (grep rfc4862).

It refers to unique /64 prefix allocated = for a PDN connection.

> 24.301-a30 says often GW allocates via RA like t= his:
> > The PDN GW allocates a globally unique /64 IPv6 prefix vi= a Router
> > Advertisement to a given UE.
>
> But this= is so difficult for me to understand because RA RFC text never
says
> an RA "allocates" some prefix. =A0This allocation ac= tion is typically a DHCP
> action, not RA. =A0The RA simply advertise= s an allocation already done by
DHCP
> or administrator or ospf.
Maybe the terminology is not clearest, but it means /64 prefix is= advertised
to the PDN connection. It is different topic then where the = PDN GW got the
addresses (statically allocated pool or by DHCPv6 or what= ever means).

The "allocate" text probably comes from the view that it is P= -t-P connection
between UE and PDN GW and hence there is just single UE = that "gets" the
whole /64 "allocated" for its use.

> In a number of other places the 3GPP spec is inc= oherent with respect to
who
> is the "Requesting Router"= - the UE or the PDN GW (at a moment the GW is a
> DHCP client reques= ting a prefix, at another moment it is the UE being a
> requesting router). =A0For me it is not clear how a Requesting Router = below
> another Requesting Router can work.

In my unders= tanding the PDN GW can use DHCPv6 Prefix Delegation to get an
address po= ol from where to "advertise" /64s for different UEs PDN
connections.

Additionally, in rel-10, also UE connected to PDN GW ca= n use DHCPv6 Prefix
Delegation to get prefixes for advertisement on loca= l area networks (such as
"MiFi hotspot").

> It is unclear to me why the 23401 3GPP spec says= that "The UE acts as a
> "Requesting Router"" re= questing a Prefix. =A0An entire Prefix (in addition
to the
> onlin= k prefixes) is useful only if that UE is a Mobile Router, giving
addresses
> further to some LFNs. =A0Otherwise it is not clear why do= Prefix Delegation
to a
> UE Requesting Router. =A0Yet the spec ne= ver says "Mobile Router".

UE acts as requesting rout= er in order to behave as a router. I understand
not using term Mobile Router there, as the UE does not necessarily implemen= t
any "IP Mobility" solutions (e.g. DSMIP6). UE just acts as a= router.

> If it makes sense for this UE to actually be a M= R, and to run DHCPv6-PD
then
> it could make sense to use DHCPv6 f= or address and default route
> configuration as well, instead of DHCP= v6+SLAAC - simply the number of
> messages is reduced, and configuration of addresses/routes/prefixes is=
> centralizely managed.

It could, but as of now it is n= ot specified to be possible. 3GPP UE always
uses SLAAC to number its cel= lular WAN interface (unnumbered model is not
supported), including getting default route pointing to cellular interface.=
After SLAAC, UE acting as router MAY use DHCPv6 PD to get prefixes for<= br>advertisement in "southbound" local area networks.

Because SLAAC is always used and UE gets its IPv6 default route that way,there is currently no need to use DHCPv6 to specify default routes.
As always, things may change in the future and that's one reason why = I'm ok
for defining default route option for DHCPv6.

Best regards,

=A0 =A0 =A0 =A0Teemu

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


--0016364c77655efdd104ad08759c-- From alexandru.petrescu@gmail.com Sat Sep 17 07:35: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 37AC421F8B0E for ; Sat, 17 Sep 2011 07:35:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.593 X-Spam-Level: X-Spam-Status: No, score=-2.593 tagged_above=-999 required=5 tests=[AWL=1.006, 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 zTcuQmev6K3i for ; Sat, 17 Sep 2011 07:35:03 -0700 (PDT) Received: from mail-ww0-f44.google.com (mail-ww0-f44.google.com [74.125.82.44]) by ietfa.amsl.com (Postfix) with ESMTP id 090E921F8B05 for ; Sat, 17 Sep 2011 07:35:02 -0700 (PDT) Received: by wwf22 with SMTP id 22so4247874wwf.13 for ; Sat, 17 Sep 2011 07:37:20 -0700 (PDT) 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:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; bh=JcnLakLXaZlXZE5AvhsYJ84fsMxw/R2hzAXAcid/4jU=; b=tMaWHj9Wkjv4+QobWAHLfY68Cs4JJuuDy4OsJH/QeV+2wdEDKS/jD/CQJqj2JSqeSD TN6cVEMthCNXM5kpoNP7ynI2CxElb+gxOZZZy4wiKJ+WKxldIWgLbIvQZkVm7bGFdywa bZ9uc74DF5v0m6QMNj7ePWfUm3DxsOnFQCEpA= Received: by 10.227.198.143 with SMTP id eo15mr682850wbb.2.1316270238206; Sat, 17 Sep 2011 07:37:18 -0700 (PDT) Received: from [127.0.0.1] (bur91-3-82-239-213-32.fbx.proxad.net. [82.239.213.32]) by mx.google.com with ESMTPS id n39sm17262390wbp.7.2011.09.17.07.37.14 (version=SSLv3 cipher=OTHER); Sat, 17 Sep 2011 07:37:16 -0700 (PDT) Message-ID: <4E74B094.70001@gmail.com> Date: Sat, 17 Sep 2011 16:37:08 +0200 From: Alexandru Petrescu User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:6.0.2) Gecko/20110902 Thunderbird/6.0.2 MIME-Version: 1.0 To: Hui Deng References: <3CF88B99A9ED504197498BC6F6F04B81040FBDA9@XMB-BGL-41E.cisco.com> <4E6E7A72.9030208@gmail.com> <4E6EAFC2.5060906@gmail.com> <4E6EDEA8.3080108@gmail.com> <4E6F825C.3080303@gmail.com> <3D0B3661-8A8F-4BB2-A8EF-25007BEAF66C@nominum.com> <4E6F923F.7090304@gmail.com> <7061CEB8-8084-41D5-B31E-9F8E3B6C7091@nominum.com> <4E6F9B91.7010503@gmail.com> <4E6FA64E.7020801@gmail.com> <82337D11-0A39-4A10-AA0E-1E81B09DBA4F@nominum.com> <4E6FACF6.5000007@viagenie.ca> <4E6FC0AE.5000108@gmail.com> <916CE6CF87173740BC8A2CE4430969620257327E@008-AM1MPN1-032.mgdnok.nokia.com> <4E6FD930.7040401@gmail.com> <916CE6CF87173740BC8A2CE443096962025734A7@008-AM1MPN1-032.mgdnok.nokia.com> <4E7070B5.6080900@gmail.com> <916CE6CF87173740BC8A2CE44309696202573B89@008-AM1MPN1-032.mgdnok.nokia.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Cc: mif@ietf.org Subject: Re: [mif] Comments on draft-mouton-mif-dhcpv6-drlo-00 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, 17 Sep 2011 14:35:04 -0000 Hello Hui, Thank you for summarising the discussion. Allow me to comment. Le 16/09/2011 07:42, Hui Deng a 閏rit : > Hello all Observations from the mailing list discussion about this > draft is: the Scenario author proposed related to 3GPP is not valid > based on current specification. Because SLAAC is always used and UE > gets its IPv6 default route that way, there is currently no need to > use DHCPv6 to specify default routes. Indeed currently 3GPP specs imply that SLAAC is used for default route (and not DHCP, although DHCP is used for other aspects such as Prefix Delegation and stateless parameters). > So whether we would like to have different option for default route > option have to wait for future evolution opportunity. For 3GPP yes, maybe future evolution will involve default route with DHCP, or maybe not. > could I summarize the discussion like Whether we need to specify > future purpose option at this moment? If we take only current 3GPP, and only 3GPP overall, into account then no, there is seemingly no need to specify a specific option for default route. On another hand. A unique DHCP default route option that could apply to non-3GPP, and maybe to future 3GPP, would be useful, considering that IP runs over non-3GPP and over 3GPP in same manner. Additionally, consider that the current MIP draft-ietf route option does specify a means to offer default route as a particular case of normal route. Do you think it is possible to specify default route in draft-ietf- route option (as currently it does) and still specify it in another way in a future document? (a default route is more special than a typical route. It has a number of other parameters that need to be present differently. For example: (1) the associated lifetime must be present in the ND default router list (whereas the other routes don't), (2) MAC address is useful (whereas for the other routes maybe the next hop may not be on the same link). Not to mention that a failing default route disconnects the Host from a potentially large part of the Internet.) Alex > Thanks for this detail discussion -Hui > > 2011/9/14 > > >> In many places the term "default prefix" is used. For example > like this: >>> IPv6 Prefix Delegation via DHCPv6 Optionally a single network > prefix >>> shorter than the default /64 prefix may be assigned to a PDN >>> connection. In this case, the /64 default prefix used for IPv6 >>> stateless autoconfiguration will be allocated from this network > prefix >> >> This is difficult to understand because SLAAC has no "default >> prefix" (grep rfc4862). > > It refers to unique /64 prefix allocated for a PDN connection. > >> 24.301-a30 says often GW allocates via RA like this: >>> The PDN GW allocates a globally unique /64 IPv6 prefix via >>> Router Advertisement to a given UE. >> >> But this is so difficult for me to understand because RA RFC text > never says >> an RA "allocates" some prefix. This allocation action is > typically a DHCP >> action, not RA. The RA simply advertises an allocation already > done by DHCP >> or administrator or ospf. > > Maybe the terminology is not clearest, but it means /64 prefix is > advertised to the PDN connection. It is different topic then where > the PDN GW got the addresses (statically allocated pool or by DHCPv6 > or whatever means). > > The "allocate" text probably comes from the view that it is P-t-P > connection between UE and PDN GW and hence there is just single UE > that "gets" the whole /64 "allocated" for its use. > >> In a number of other places the 3GPP spec is incoherent with > respect to who >> is the "Requesting Router" - the UE or the PDN GW (at a moment > the GW is a >> DHCP client requesting a prefix, at another moment it is the UE > being a >> requesting router). For me it is not clear how a Requesting > Router below >> another Requesting Router can work. > > In my understanding the PDN GW can use DHCPv6 Prefix Delegation to > get an address pool from where to "advertise" /64s for different UEs > PDN connections. > > Additionally, in rel-10, also UE connected to PDN GW can use DHCPv6 > Prefix Delegation to get prefixes for advertisement on local area > networks (such as "MiFi hotspot"). > >> It is unclear to me why the 23401 3GPP spec says that "The UE > acts as a >> "Requesting Router"" requesting a Prefix. An entire Prefix (in > addition to the >> onlink prefixes) is useful only if that UE is a Mobile Router, >> giving > addresses >> further to some LFNs. Otherwise it is not clear why do Prefix > Delegation to a >> UE Requesting Router. Yet the spec never says "Mobile Router". > > UE acts as requesting router in order to behave as a router. I > understand not using term Mobile Router there, as the UE does not > necessarily implement any "IP Mobility" solutions (e.g. DSMIP6). UE > just acts as a router. > >> If it makes sense for this UE to actually be a MR, and to run > DHCPv6-PD then >> it could make sense to use DHCPv6 for address and default route >> configuration as well, instead of DHCPv6+SLAAC - simply the number >> of messages is reduced, and configuration of > addresses/routes/prefixes is >> centralizely managed. > > It could, but as of now it is not specified to be possible. 3GPP UE > always uses SLAAC to number its cellular WAN interface (unnumbered > model is not supported), including getting default route pointing to > cellular interface. After SLAAC, UE acting as router MAY use DHCPv6 > PD to get prefixes for advertisement in "southbound" local area > networks. > > Because SLAAC is always used and UE gets its IPv6 default route that > way, there is currently no need to use DHCPv6 to specify default > routes. > > As always, things may change in the future and that's one reason why > I'm ok for defining default route option for DHCPv6. > > Best regards, > > Teemu > > _______________________________________________ mif mailing list > mif@ietf.org > https://www.ietf.org/mailman/listinfo/mif > > From alexandru.petrescu@gmail.com Sat Sep 17 07:46: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 C752121F886F for ; Sat, 17 Sep 2011 07:46:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.639 X-Spam-Level: X-Spam-Status: No, score=-2.639 tagged_above=-999 required=5 tests=[AWL=0.960, 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 envHIc2S6HFT for ; Sat, 17 Sep 2011 07:46:59 -0700 (PDT) Received: from mail-ww0-f44.google.com (mail-ww0-f44.google.com [74.125.82.44]) by ietfa.amsl.com (Postfix) with ESMTP id B553921F87FC for ; Sat, 17 Sep 2011 07:46:58 -0700 (PDT) Received: by wwf22 with SMTP id 22so4253006wwf.13 for ; Sat, 17 Sep 2011 07:49:15 -0700 (PDT) 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:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; bh=3lgQl657WHZfJ9p8Kkv6Syoi1RsYQSYcRgG0r9Y9Ssc=; b=fkOE17KYQWui/GlBrueFKRZ/4DVfJv1bWJa/Htk/PB6WlBOMd/j30ftnZlIbBcXmGt odXCVtrXFrXkmY5sp01u6PKNCYg0T17Z6L41jI5ONAY3qMFlVXQsXLU7zq7/N6LtWLYf eGgxgAeIVcKJJ1Gr00OgyxkoMCWOu0aYJJh8s= Received: by 10.216.221.65 with SMTP id q43mr659474wep.22.1316270955778; Sat, 17 Sep 2011 07:49:15 -0700 (PDT) Received: from [127.0.0.1] (bur91-3-82-239-213-32.fbx.proxad.net. [82.239.213.32]) by mx.google.com with ESMTPS id fr18sm17299852wbb.9.2011.09.17.07.49.14 (version=SSLv3 cipher=OTHER); Sat, 17 Sep 2011 07:49:14 -0700 (PDT) Message-ID: <4E74B363.7000402@gmail.com> Date: Sat, 17 Sep 2011 16:49:07 +0200 From: Alexandru Petrescu User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:6.0.2) Gecko/20110902 Thunderbird/6.0.2 MIME-Version: 1.0 To: teemu.savolainen@nokia.com References: <3CF88B99A9ED504197498BC6F6F04B81040FBDA9@XMB-BGL-41E.cisco.com> <4E6E7A72.9030208@gmail.com> <4E6EAFC2.5060906@gmail.com> <4E6EDEA8.3080108@gmail.com> <4E6F825C.3080303@gmail.com> <3D0B3661-8A8F-4BB2-A8EF-25007BEAF66C@nominum.com> <4E6F923F.7090304@gmail.com> <7061CEB8-8084-41D5-B31E-9F8E3B6C7091@nominum.com> <4E6F9B91.7010503@gmail.com> <4E6FA64E.7020801@gmail.com> <82337D11-0A39-4A10-AA0E-1E81B09DBA4F@nominum.com> <4E6FACF6.5000007@viagenie.ca>, <4E6FC0AE.5000108@gmail.com> <916CE6CF87173740BC8A2CE4430969620257327E@008-AM1MPN1-032.mgdnok.nokia.com> <4E6FD930.7040401@gmail.com> <916CE6CF87173740BC8A2CE443096962025734A7@008-AM1MPN1-032.mgdnok.nokia.com> <4E7070B5.6080900@gmail.com> <916CE6CF87173740BC8A2CE44309696202573B89@008-AM1MPN1-032.mgdnok.nokia.com> In-Reply-To: <916CE6CF87173740BC8A2CE44309696202573B89@008-AM1MPN1-032.mgdnok.nokia.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Cc: mif@ietf.org Subject: Re: [mif] Comments on draft-mouton-mif-dhcpv6-drlo-00 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, 17 Sep 2011 14:46:59 -0000 Le 14/09/2011 12:26, teemu.savolainen@nokia.com a 閏rit : >> In many places the term "default prefix" is used. For example >> like this: >>> IPv6 Prefix Delegation via DHCPv6 Optionally a single network >>> prefix shorter than the default /64 prefix may be assigned to a >>> PDN connection. In this case, the /64 default prefix used for >>> IPv6 stateless autoconfiguration will be allocated from this >>> network prefix >> >> This is difficult to understand because SLAAC has no "default >> prefix" (grep rfc4862). > > It refers to unique /64 prefix allocated for a PDN connection. Hm.. I agree, it may be only me who confuses 3GPP "default prefix" with "IP default route". >> 24.301-a30 says often GW allocates via RA like this: >>> The PDN GW allocates a globally unique /64 IPv6 prefix via Router >>> Advertisement to a given UE. >> >> But this is so difficult for me to understand because RA RFC text >> never says an RA "allocates" some prefix. This allocation action >> is typically a DHCP action, not RA. The RA simply advertises an >> allocation already done by DHCP or administrator or ospf. > > Maybe the terminology is not clearest, but it means /64 prefix is > advertised to the PDN connection. It is different topic then where > the PDN GW got the addresses (statically allocated pool or by DHCPv6 > or whatever means). > > The "allocate" text probably comes from the view that it is P-t-P > connection between UE and PDN GW and hence there is just single UE > that "gets" the whole /64 "allocated" for its use. If it is "allocated" for PtP connection for like-PPP then yes (although I am not sure what the PPPv6 spec uses "allocate"), but that should be "advertised" when used with RA. Allocation of a prefix may happen in a number of ways like DHCP, manual, router renumbering, but never RA. >> In a number of other places the 3GPP spec is incoherent with >> respect to who is the "Requesting Router" - the UE or the PDN GW >> (at a moment the GW is a DHCP client requesting a prefix, at >> another moment it is the UE being a requesting router). For me it >> is not clear how a Requesting Router below another Requesting >> Router can work. > > In my understanding the PDN GW can use DHCPv6 Prefix Delegation to > get an address pool from where to "advertise" /64s for different UEs > PDN connections. > > Additionally, in rel-10, also UE connected to PDN GW can use DHCPv6 > Prefix Delegation to get prefixes for advertisement on local area > networks (such as "MiFi hotspot"). Hmmm... but I don't understand how a UE can be a Requesting Router at the same time as the PDN-GW being a RR. If the MiFi hotspot router requests a /64 prefix from a PDN-GW which has only /64 prefixes then the number of routing entries in the PDN-GW may double. Second, if the MiFi hotspot router is a RR then I suppose the PDN-GW must be a delegating router for it (DR); the spec doesn't say, it says just it's a RR. (if I read correctly). >> It is unclear to me why the 23401 3GPP spec says that "The UE acts >> as a "Requesting Router"" requesting a Prefix. An entire Prefix >> (in addition > to the >> onlink prefixes) is useful only if that UE is a Mobile Router, >> giving > addresses >> further to some LFNs. Otherwise it is not clear why do Prefix >> Delegation > to a >> UE Requesting Router. Yet the spec never says "Mobile Router". > > UE acts as requesting router in order to behave as a router. I > understand not using term Mobile Router there, as the UE does not > necessarily implement any "IP Mobility" solutions (e.g. DSMIP6). UE > just acts as a router. > >> If it makes sense for this UE to actually be a MR, and to run >> DHCPv6-PD > then >> it could make sense to use DHCPv6 for address and default route >> configuration as well, instead of DHCPv6+SLAAC - simply the number >> of messages is reduced, and configuration of >> addresses/routes/prefixes is centralizely managed. > > It could, but as of now it is not specified to be possible. 3GPP UE > always uses SLAAC to number its cellular WAN interface (unnumbered > model is not supported), including getting default route pointing to > cellular interface. After SLAAC, UE acting as router MAY use DHCPv6 > PD to get prefixes for advertisement in "southbound" local area > networks. > > Because SLAAC is always used and UE gets its IPv6 default route that > way, there is currently no need to use DHCPv6 to specify default > routes. > > As always, things may change in the future and that's one reason why > I'm ok for defining default route option for DHCPv6. Yes, me too, Alex > > Best regards, > > Teemu From alexandru.petrescu@gmail.com Sat Sep 17 07:49: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 EF95821F8A35 for ; Sat, 17 Sep 2011 07:49:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.681 X-Spam-Level: X-Spam-Status: No, score=-2.681 tagged_above=-999 required=5 tests=[AWL=0.918, 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 nCjp-IPzdVPB for ; Sat, 17 Sep 2011 07:49:09 -0700 (PDT) Received: from mail-ww0-f44.google.com (mail-ww0-f44.google.com [74.125.82.44]) by ietfa.amsl.com (Postfix) with ESMTP id B9FAA21F886F for ; Sat, 17 Sep 2011 07:49:08 -0700 (PDT) Received: by wwf22 with SMTP id 22so4253951wwf.13 for ; Sat, 17 Sep 2011 07:51:25 -0700 (PDT) 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=q9/JHRnq7WAToG6R1bLe/UCbVb+W5qavjDHxJbutXmI=; b=qGlGZOHXzK4z9xwAEONHG+ORayek9RyLJxvub9DJjgKHl312vcmWER//sY5xaYcTyw DS5e+tAhx2qW6Qqho0acBCb53NisUNnZBlhrCoQp9vkU8KTFKk9DTTm9LR5pmq71wITi 7bWkoYCSrhzQTtqKKMywuAk9vD4THYHHte0Sc= Received: by 10.216.8.5 with SMTP id 5mr603821weq.68.1316271085802; Sat, 17 Sep 2011 07:51:25 -0700 (PDT) Received: from [127.0.0.1] (bur91-3-82-239-213-32.fbx.proxad.net. [82.239.213.32]) by mx.google.com with ESMTPS id gd6sm17325439wbb.1.2011.09.17.07.51.24 (version=SSLv3 cipher=OTHER); Sat, 17 Sep 2011 07:51:24 -0700 (PDT) Message-ID: <4E74B3E6.6020701@gmail.com> Date: Sat, 17 Sep 2011 16:51:18 +0200 From: Alexandru Petrescu User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:6.0.2) Gecko/20110902 Thunderbird/6.0.2 MIME-Version: 1.0 To: mif@ietf.org References: <3CF88B99A9ED504197498BC6F6F04B81040FBDA9@XMB-BGL-41E.cisco.com> <4E6E7A72.9030208@gmail.com> <4E6EAFC2.5060906@gmail.com> <4E6EDEA8.3080108@gmail.com> <4E6F825C.3080303@gmail.com> <3D0B3661-8A8F-4BB2-A8EF-25007BEAF66C@nominum.com> <4E6F923F.7090304@gmail.com> <7061CEB8-8084-41D5-B31E-9F8E3B6C7091@nominum.com> <4E6F9B91.7010503@gmail.com> <4E6FA64E.7020801@gmail.com> <82337D11-0A39-4A10-AA0E-1E81B09DBA4F@nominum.com> <4E6FACF6.5000007@viagenie.ca> <4E6FC0AE.5000108@gmail.com> <916CE6CF87173740BC8A2CE4430969620257327E@008-AM1MPN1-032.mgdnok.nokia.com> <4E6FD930.7040401@gmail.com> <916CE6CF87173740BC8A2CE443096962025734A7@008-AM1MPN1-032.mgdnok.nokia.com> <4E7070B5.6080900@gmail.com> <916CE6CF87173740BC8A2CE44309696202573B89@008-AM1MPN1-032.mgdnok.nokia.com> <4E74B094.70001@gmail.com> In-Reply-To: <4E74B094.70001@gmail.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Subject: Re: [mif] Comments on draft-mouton-mif-dhcpv6-drlo-00 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, 17 Sep 2011 14:49:10 -0000 (small typo below "MIF" instead of "MIP") Alex Le 17/09/2011 16:37, Alexandru Petrescu a 閏rit : > Hello Hui, > > Thank you for summarising the discussion. Allow me to comment. > > Le 16/09/2011 07:42, Hui Deng a 閏rit : >> Hello all Observations from the mailing list discussion about this >> draft is: the Scenario author proposed related to 3GPP is not >> valid based on current specification. Because SLAAC is always used >> and UE gets its IPv6 default route that way, there is currently no >> need to use DHCPv6 to specify default routes. > > Indeed currently 3GPP specs imply that SLAAC is used for default > route (and not DHCP, although DHCP is used for other aspects such as > Prefix Delegation and stateless parameters). > >> So whether we would like to have different option for default >> route option have to wait for future evolution opportunity. > > For 3GPP yes, maybe future evolution will involve default route with > DHCP, or maybe not. > >> could I summarize the discussion like Whether we need to specify >> future purpose option at this moment? > > If we take only current 3GPP, and only 3GPP overall, into account > then no, there is seemingly no need to specify a specific option for > default route. > > On another hand. A unique DHCP default route option that could apply > to non-3GPP, and maybe to future 3GPP, would be useful, considering > that IP runs over non-3GPP and over 3GPP in same manner. > > Additionally, consider that the current MIP draft-ietf route option > does sorry I meant MIF Alex > specify a means to offer default route as a particular case of > normal route. > > Do you think it is possible to specify default route in draft-ietf- > route option (as currently it does) and still specify it in another > way in a future document? > > (a default route is more special than a typical route. It has a > number of other parameters that need to be present differently. For > example: (1) the associated lifetime must be present in the ND > default router list (whereas the other routes don't), (2) MAC address > is useful (whereas for the other routes maybe the next hop may not be > on the same link). Not to mention that a failing default route > disconnects the Host from a potentially large part of the Internet.) > > Alex > > >> Thanks for this detail discussion -Hui >> >> 2011/9/14 > > >> >>> In many places the term "default prefix" is used. For example >> like this: >>>> IPv6 Prefix Delegation via DHCPv6 Optionally a single network >> prefix >>>> shorter than the default /64 prefix may be assigned to a PDN >>>> connection. In this case, the /64 default prefix used for IPv6 >>>> stateless autoconfiguration will be allocated from this >>>> network >> prefix >>> >>> This is difficult to understand because SLAAC has no "default >>> prefix" (grep rfc4862). >> >> It refers to unique /64 prefix allocated for a PDN connection. >> >>> 24.301-a30 says often GW allocates via RA like this: >>>> The PDN GW allocates a globally unique /64 IPv6 prefix via >>>> Router Advertisement to a given UE. >>> >>> But this is so difficult for me to understand because RA RFC >>> text >> never says >>> an RA "allocates" some prefix. This allocation action is >> typically a DHCP >>> action, not RA. The RA simply advertises an allocation already >> done by DHCP >>> or administrator or ospf. >> >> Maybe the terminology is not clearest, but it means /64 prefix is >> advertised to the PDN connection. It is different topic then where >> the PDN GW got the addresses (statically allocated pool or by >> DHCPv6 or whatever means). >> >> The "allocate" text probably comes from the view that it is P-t-P >> connection between UE and PDN GW and hence there is just single UE >> that "gets" the whole /64 "allocated" for its use. >> >>> In a number of other places the 3GPP spec is incoherent with >> respect to who >>> is the "Requesting Router" - the UE or the PDN GW (at a moment >> the GW is a >>> DHCP client requesting a prefix, at another moment it is the UE >> being a >>> requesting router). For me it is not clear how a Requesting >> Router below >>> another Requesting Router can work. >> >> In my understanding the PDN GW can use DHCPv6 Prefix Delegation to >> get an address pool from where to "advertise" /64s for different >> UEs PDN connections. >> >> Additionally, in rel-10, also UE connected to PDN GW can use >> DHCPv6 Prefix Delegation to get prefixes for advertisement on local >> area networks (such as "MiFi hotspot"). >> >>> It is unclear to me why the 23401 3GPP spec says that "The UE >> acts as a >>> "Requesting Router"" requesting a Prefix. An entire Prefix (in >> addition to the >>> onlink prefixes) is useful only if that UE is a Mobile Router, >>> giving >> addresses >>> further to some LFNs. Otherwise it is not clear why do Prefix >> Delegation to a >>> UE Requesting Router. Yet the spec never says "Mobile Router". >> >> UE acts as requesting router in order to behave as a router. I >> understand not using term Mobile Router there, as the UE does not >> necessarily implement any "IP Mobility" solutions (e.g. DSMIP6). >> UE just acts as a router. >> >>> If it makes sense for this UE to actually be a MR, and to run >> DHCPv6-PD then >>> it could make sense to use DHCPv6 for address and default route >>> configuration as well, instead of DHCPv6+SLAAC - simply the >>> number of messages is reduced, and configuration of >> addresses/routes/prefixes is >>> centralizely managed. >> >> It could, but as of now it is not specified to be possible. 3GPP >> UE always uses SLAAC to number its cellular WAN interface >> (unnumbered model is not supported), including getting default >> route pointing to cellular interface. After SLAAC, UE acting as >> router MAY use DHCPv6 PD to get prefixes for advertisement in >> "southbound" local area networks. >> >> Because SLAAC is always used and UE gets its IPv6 default route >> that way, there is currently no need to use DHCPv6 to specify >> default routes. >> >> As always, things may change in the future and that's one reason >> why I'm ok for defining default route option for DHCPv6. >> >> Best regards, >> >> Teemu >> >> _______________________________________________ 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 Mon Sep 19 01:31:05 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 2120421F8B36 for ; Mon, 19 Sep 2011 01:31:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.161 X-Spam-Level: X-Spam-Status: No, score=-3.161 tagged_above=-999 required=5 tests=[AWL=0.438, 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 nbH5zI2w2XOd for ; Mon, 19 Sep 2011 01:31:04 -0700 (PDT) Received: from mgw-da01.nokia.com (smtp.nokia.com [147.243.128.24]) by ietfa.amsl.com (Postfix) with ESMTP id 60C4421F8A71 for ; Mon, 19 Sep 2011 01:31:04 -0700 (PDT) Received: from vaebh105.NOE.Nokia.com (vaebh105.europe.nokia.com [10.160.244.31]) by mgw-da01.nokia.com (Switch-3.4.4/Switch-3.4.3) with ESMTP id p8J8X17w012815; Mon, 19 Sep 2011 11:33:24 +0300 Received: from smtp.mgd.nokia.com ([65.54.30.6]) by vaebh105.NOE.Nokia.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.4675); Mon, 19 Sep 2011 11:33:13 +0300 Received: from 008-AM1MMR1-002.mgdnok.nokia.com (65.54.30.57) by NOK-am1MHUB-02.mgdnok.nokia.com (65.54.30.6) with Microsoft SMTP Server (TLS) id 8.2.255.0; Mon, 19 Sep 2011 10:33:13 +0200 Received: from 008-AM1MPN1-037.mgdnok.nokia.com ([169.254.7.199]) by 008-AM1MMR1-002.mgdnok.nokia.com ([65.54.30.57]) with mapi id 14.01.0339.002; Mon, 19 Sep 2011 10:33:12 +0200 From: To: Thread-Topic: [mif] Comments on draft-mouton-mif-dhcpv6-drlo-00 Thread-Index: AQHMclXvmeatSbe770ilB6P1NUlbCpVL1DV4///urQCAAJ4CcIAAFp+AgAAwtvCABON7gIAC19rw Date: Mon, 19 Sep 2011 08:33:12 +0000 Message-ID: <916CE6CF87173740BC8A2CE44309696202F2B407@008-AM1MPN1-037.mgdnok.nokia.com> References: <3CF88B99A9ED504197498BC6F6F04B81040FBDA9@XMB-BGL-41E.cisco.com> <4E6E7A72.9030208@gmail.com> <4E6EAFC2.5060906@gmail.com> <4E6EDEA8.3080108@gmail.com> <4E6F825C.3080303@gmail.com> <3D0B3661-8A8F-4BB2-A8EF-25007BEAF66C@nominum.com> <4E6F923F.7090304@gmail.com> <7061CEB8-8084-41D5-B31E-9F8E3B6C7091@nominum.com> <4E6F9B91.7010503@gmail.com> <4E6FA64E.7020801@gmail.com> <82337D11-0A39-4A10-AA0E-1E81B09DBA4F@nominum.com> <4E6FACF6.5000007@viagenie.ca>,<4E6FC0AE.5000108@gmail.com> <916CE6CF87173740BC8A2CE4430969620257327E@008-AM1MPN1-032.mgdnok.nokia.com> <4E6FD930.7040401@gmail.com> <916CE6CF87173740BC8A2CE443096962025734A7@008-AM1MPN1-032.mgdnok.nokia.com> <4E7070B5.6080900@gmail.com> <916CE6CF87173740BC8A2CE44309696202573B89@008-AM1MPN1-032.mgdnok.nokia.com> <4E74B363.7000402@gmail.com> In-Reply-To: <4E74B363.7000402@gmail.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes 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+/nZJb9Kg7IuZuBXX/gTPnV8RRCmXgbNBLv+s+z8dze93E2y5N3eQswSwwwxgghs89TU1NiT1JcwoYrWJF1mZc/NrOJDhIyVOXH9EPAg712fNqHrpoDEsvuRlOS1hSiwqJBl/y+vrUMbNcSOiAMcMwyx351Sa6Z/IFSlHIhsBMoR40FyewYK3KCsi7Yxw68v+kP9DvNAmUZxPlsGYqXedFJIa5k15Bm0XdsxKvBnVcmuxqzTj4b4GDU4EfHLLHaH9VmYnqNFtQ0A== x-originating-ip: [10.162.60.55] Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=SHA1; boundary="----=_NextPart_000_0023_01CC76BF.E9913320" MIME-Version: 1.0 X-OriginalArrivalTime: 19 Sep 2011 08:33:13.0869 (UTC) FILETIME=[C59903D0:01CC76A6] X-Nokia-AV: Clean Cc: mif@ietf.org Subject: Re: [mif] Comments on draft-mouton-mif-dhcpv6-drlo-00 X-BeenThere: mif@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multiple Interface Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 19 Sep 2011 08:31:05 -0000 ------=_NextPart_000_0023_01CC76BF.E9913320 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit > > Additionally, in rel-10, also UE connected to PDN GW can use DHCPv6 > > Prefix Delegation to get prefixes for advertisement on local area > > networks (such as "MiFi hotspot"). > > Hmmm... but I don't understand how a UE can be a Requesting Router at the > same time as the PDN-GW being a RR. PDG-GW can use DHCPv6 PD to ask for a pool of addresses it uses for UEs (or it may have a locally provisioned pool), and from where it can further delegate prefixes downstream (in DR role) to those UEs that implement RR function. > If the MiFi hotspot router requests a /64 prefix from a PDN-GW which has > only /64 prefixes then the number of routing entries in the PDN-GW may > double. Yes! That is one big reason for existence of draft-ietf-dhc-pd-exclude-03 that optimizes routing entries in these kinds of scenarios on 3GPP accesses, but also elsewhere - there was interest from fixed side for this as well. The exclude option optimizes routing entries on gateway but with a deployment-scenario/network setup dependent possible tradeoff of increased address space usage. > Second, if the MiFi hotspot router is a RR then I suppose the PDN-GW must > be a delegating router for it (DR); the spec doesn't say, it says just it's a RR. (if > I read correctly). Did you look at the 23.401 V10.4.0 (the latest version) section 5.3.1.2.6 that says it clearly: "The PDN GW acts as the DHCP server and fulfils the role of a "Delegating Router" according to RFC 3633". Best regards, Teemu ------=_NextPart_000_0023_01CC76BF.E9913320 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIOuzCCAzYw ggIeoAMCAQICBDpVqdkwDQYJKoZIhvcNAQEFBQAwKTEOMAwGA1UEChMFTm9raWExFzAVBgNVBAMT Dk5va2lhICBSb290IENBMB4XDTAxMDEwNTExMDUwNVoXDTE2MDEwMjExMDUwNVowKTEOMAwGA1UE ChMFTm9raWExFzAVBgNVBAMTDk5va2lhICBSb290IENBMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8A MIIBCgKCAQEAsrTy8gLmr4LYvp0khVUVHw7ascdl+Cjr+yI5MlZ6J/U6Qsvkiqthgqq8rPcLV0P1 92TfBr27VgKEeCaZe0icS1jC2spM/wRv3j2WxdkKxb9kDJtuCNJaRBqvi5vGTHB15nmEmKuL5f3i rAxeHqPjgS496oWcudzFT1e7Xrc/gWGFYd72+/ykIFXjWOMZv6QpxD8x1hLPyh2YVXRk9U7N7pvm RQNX29g4SCFJY2BBIa5JPlwIF8Nc9IePaC/E/2M4tGMtiOOZlm99EoL7N0hJZtFSvUwdCBud/viH 4DgsKGjNkNKi6pAHc9IaXB6tIykcoYp+L+oe/3+cuEJaCj1EKwIDAQABo2YwZDASBgNVHRMBAf8E CDAGAQH/AgEEMB0GA1UdDgQWBBSNjfefoQ0AITLvqe0iruA79NB9sDAfBgNVHSMEGDAWgBSNjfef oQ0AITLvqe0iruA79NB9sDAOBgNVHQ8BAf8EBAMCAYYwDQYJKoZIhvcNAQEFBQADggEBAIGEPql2 TALyKi/h1J+Mh5XolAtYppcSOLMtBkoA7ZovGBDNvl0VbZs8AAojJqkUoWBB+L6DKyl/jKhNfKcu rWRGRyj7pnbxrKLsI3gmWNWkyo2b60wJwe9fqPD5ZQy3oEiMit9l0Ba6il/k2GqYopUCNMa7mfeb E2LeBy5ChYMiCi97UQSJvAdzEYylTJw8Awc6AiM2Ve5N+XxsmKgNf/2A/5IJ3EZZ+wFRmkI4062A oNU302rqAt0HH88jzoUF4AfYHWl6HpYhGXFbcX44rHINyPmFBRxLYIFJ6ZWUr/mXpL/e6rqFtNWO kV6UoJND7OVZkbLh7F1+lcqXRU8TPBMwggOHMIICb6ADAgECAgRBtbHpMA0GCSqGSIb3DQEBBQUA MCkxDjAMBgNVBAoTBU5va2lhMRcwFQYDVQQDEw5Ob2tpYSAgUm9vdCBDQTAeFw0wNjAzMzAwOTU3 MTFaFw0xNjAxMDIxMTA1MDVaMDMxCzAJBgNVBAYTAkZJMQ4wDAYDVQQKEwVOb2tpYTEUMBIGA1UE AxMLTm9raWEgQkkgQ0EwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQDtFCg3QEjSCg6T IUxoWsNwELh8bBNiUQPCPmg8c2DHQYXWWCSCMb+S0Fvh1qqI1xt+XnzyFq+5eqzGzDj4UaBcG+d9 qxrCFly8sHyoPTryyPrR0EI2UUDWwfS6ojhqgwghRqo8G38TjFusyBtLub/5L6yvWYSOHD+JcB+q VM2fbkArPYK4Ydv8WG/DbHjGn0gKq0zwpVZKI/gCK/QALYvte02NXseqvY9/GOyLtjy3Z8erFv71 KKTq+gxI/7DK55pJf3PoD+kT4kyGm6EF9DTdK4ojMdar17uyX0IOZz/4vkkF0d+60nmnLX63FJPA jUyB0HUNJ32NXDo9UsM38aoNAgMBAAGjgawwgakwDwYDVR0TAQH/BAUwAwEB/zARBgNVHSAECjAI MAYGBFUdIAAwDgYDVR0PAQH/BAQDAgGGMFQGA1UdIwRNMEuAFI2N95+hDQAhMu+p7SKu4Dv00H2w oS2kKzApMQ4wDAYDVQQKEwVOb2tpYTEXMBUGA1UEAxMOTm9raWEgIFJvb3QgQ0GCBDpVqdkwHQYD VR0OBBYEFKcksD7Fg+8EDlB2Sxgy58pW0Sy6MA0GCSqGSIb3DQEBBQUAA4IBAQAC3lEUplDlVNOT Pjz/XFezXx2bV2XbCFindhA3F815Egi55H6/cYezEjoP4QLNEGGl2I3aLvkn5A0T8I4pbiFPhIiu B/frbbGg6k6GjQLe/bFQ8F1mAOOR+GyneKZFPfzaRV0jiIR9QqnMXTf8RvKkCJyFj10MZVsLIy/Y uBkzeP3JhzDhUdtPfwmJN6ZbIhH5uR/2BwAGtgQknb8WX3I4wnhWtMUxB8XmayayYs8qWYeIiVkI FV+sLTkWUWVvvKUjyakBpbAW2vUP84DYsJ8TL1YefNjf/nIOByMcORLuV/1gPjyv00qJbcB59AA+ iXe3zIo8QNcgXG0uPQQFmrGDMIID5DCCAsygAwIBAgIQMH5apak8lEy6LmLlLsJy8TANBgkqhkiG 9w0BAQUFADAzMQswCQYDVQQGEwJGSTEOMAwGA1UEChMFTm9raWExFDASBgNVBAMTC05va2lhIEJJ IENBMB4XDTExMDkwNjA1NTIwNFoXDTE0MDkwNjA1NTIwNFowVjEOMAwGA1UECgwFTm9raWExDzAN BgNVBAsMBlBlb3BsZTEYMBYGCgmSJomT8ixkAQEMCDEwMDI0Njc2MRkwFwYDVQQDDBBTYXZvbGFp bmVuIFRlZW11MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAshEsmw6Yiz6XWX26oF+I s5fsfE1OfCjOelclmtqCiIgXND5klkNOBs2d4ZGzgD9mN+XnTZnOTh249c2WxPBugf12DCcDmBAJ gL+VuWUJVBTE5NRchm/O8nZnZsRFst+gAC9/Juykh4+EYewZ7QbpnlwW7hNpj8eH+rMr+OZHKzdp KTftgVjmuF4JJ/cPMQUjL8SuGj+zBW6IWPOZdqkEMtf7Pr8kkYbZsh0SgJ0ceRHZ7Uc06mB/y+C1 UnJPxehTTdu8tpCjdzXgBw/H2uuW1J3qdHbCfbuDILql8V8RiZKubcZLhdsD3Jvj8qK0DGWBJa6x p90q5p3pLE8LvAeCgQIDAQABo4HQMIHNMA4GA1UdDwEB/wQEAwIEMDAfBgNVHSMEGDAWgBSnJLA+ xYPvBA5QdksYMufKVtEsujAZBgNVHSAEEjAQMA4GDCsGAQQBXgExBgEHAzA5BgNVHR8EMjAwMC6g LKAqhihodHRwOi8vY3JsLm5va2lhLmNvbS9Ob2tpYSUyMEJJJTIwQ0EuY3JsMCUGA1UdEQQeMByB GnRlZW11LnNhdm9sYWluZW5Abm9raWEuY29tMB0GA1UdDgQWBBQTRzvZsgmQrAGCeuzdHTGAC6Jg UzANBgkqhkiG9w0BAQUFAAOCAQEACmPVsdi07pjK5gDa+W5JlE2C74kVVsB8alBqfioYeR5At2FG B7sua4Dz5H7TJMpZ1jYFeI+zjexD5f+beY2IlV15lMoWD+5e38QlLYjwfe2LAyvdzBKXW0e0U6Bt p78ft4gyVak1X+Db+ebR+FNHUOMNhm+yK3w9sy5ZQzBFusIx4OgxGvcZhyhmd9WjipSTalgPwgqV Ju2aPADCG++OEXmgEWRLsR4yNopkgK4ftVqrN5uUtLs83qdeXTRcNRiET1IOx5zmYFZ6q3gjKIx5 iyuxcDeYas93vVHUcaRRYpsoby5CHq7Z/j/TQhtqO/knWuxLFFiCUgdGKMKrRkg29DCCBAowggLy oAMCAQICEQCBvi+p+bA/dBtBtybwA6YYMA0GCSqGSIb3DQEBBQUAMDMxCzAJBgNVBAYTAkZJMQ4w DAYDVQQKEwVOb2tpYTEUMBIGA1UEAxMLTm9raWEgQkkgQ0EwHhcNMTEwOTA2MDU1MDM0WhcNMTMw OTA1MDU1MDM0WjBWMQ4wDAYDVQQKDAVOb2tpYTEPMA0GA1UECwwGUGVvcGxlMRgwFgYKCZImiZPy LGQBAQwIMTAwMjQ2NzYxGTAXBgNVBAMMEFNhdm9sYWluZW4gVGVlbXUwggEiMA0GCSqGSIb3DQEB AQUAA4IBDwAwggEKAoIBAQDFPmbRVwuo52v+h6xnQUqokAx2xsHjmPBniEkzgtgBNJsFi838ATEg 1zsx+VotoJg7hMijcrQfpTAgW6gpLGnlmw5QQswrNK1zleOHb4pA5JguU3WhVKFkAH/6/2EU2k/9 m8Pb/gwP55cYg80R6fRmbdsWKhseXF/1isW/rJcWLmIYDg/rXfo3ixqtT9MroAMiuoXnb0ij1L2d Jj64LDp3Ld8Jo0qZzk3Fj4apo8PBd8eAH6HloVBJkxQcwAnv561A+Xi1GHZ2mafRYJGO+1uBDwyd g/8ybEXXA4MKo8lPKjBebYBUFvz80DBA/Lq74UysXkG23BSulcG4xQSYGlyzAgMBAAGjgfUwgfIw HwYDVR0jBBgwFoAUpySwPsWD7wQOUHZLGDLnylbRLLowGQYDVR0gBBIwEDAOBgwrBgEEAV4BMQYB BgQwOQYDVR0fBDIwMDAuoCygKoYoaHR0cDovL2NybC5ub2tpYS5jb20vTm9raWElMjBCSSUyMENB LmNybDAjBgNVHSUEHDAaBggrBgEFBQcDAgYEVR0lAAYIKwYBBQUHAwQwDgYDVR0PAQH/BAQDAgeA MCUGA1UdEQQeMByBGnRlZW11LnNhdm9sYWluZW5Abm9raWEuY29tMB0GA1UdDgQWBBTGhbTJF0EX iagjymQo6GIuSQeRVDANBgkqhkiG9w0BAQUFAAOCAQEAqai6TxZ/BlMHZIhJNPriBPXkQhUlBkGA buJZ5sVm1HIQhWN8elZKjjJdHi1qWEKhMg7yHjEMZsyV8XAZzK0UnOqkpUnt+jnVkNZ9O7/jRtyK f4WUtq5jErc8Hlv4bbGFRHk1T7AuLLE52r1lYOdmoibnQp03QtlDvHUNa68G7jvzThJhieB7U1xh vH3yy0ktaVnWEgAylqf9yIUFjnqau5R6cE1Xo57IYPk/KitX0YF+OigEI/bOQVMi+fze93ZsAOJv /z6g/NGemvUgl5YSdX0uPQK6kEHf/sp/nZyUWWQ7OjtVSqkq2YuYEueQFxTfafl+78GWqgm6W/Bl 32laYzGCAuswggLnAgEBMEgwMzELMAkGA1UEBhMCRkkxDjAMBgNVBAoTBU5va2lhMRQwEgYDVQQD EwtOb2tpYSBCSSBDQQIRAIG+L6n5sD90G0G3JvADphgwCQYFKw4DAhoFAKCCAXgwGAYJKoZIhvcN AQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG9w0BCQUxDxcNMTEwOTE5MDgzMzExWjAjBgkqhkiG9w0B CQQxFgQUpCl0ScDR8VFRii99e1NlsQeY9PMwVgYJKwYBBAGCNxAEMUkwRzAzMQswCQYDVQQGEwJG STEOMAwGA1UEChMFTm9raWExFDASBgNVBAMTC05va2lhIEJJIENBAhAwflqlqTyUTLouYuUuwnLx MFgGCyqGSIb3DQEJEAILMUmgRzAzMQswCQYDVQQGEwJGSTEOMAwGA1UEChMFTm9raWExFDASBgNV BAMTC05va2lhIEJJIENBAhAwflqlqTyUTLouYuUuwnLxMGcGCSqGSIb3DQEJDzFaMFgwCgYIKoZI hvcNAwcwDgYIKoZIhvcNAwICAgCAMA0GCCqGSIb3DQMCAgFAMAcGBSsOAwIHMA0GCCqGSIb3DQMC AgEoMAcGBSsOAwIaMAoGCCqGSIb3DQIFMA0GCSqGSIb3DQEBAQUABIIBAEJZWYsh70NvvqzWg79x exLS0WOalS5SGAfBRgUNYlGbZQTSsoIjaLmhn/wFzg3tBEdT0ieVuWnFGtTo774XK8hFZMMFV9oc Q2S+8vCfzLLFdnNagk/+NwLy9FYFB5YndNqLhGcgJ5KQcnGP6PSotDfro7BLvYF14nh0q2FbXZKq zfnuJUuCKTB0waTdAAWjbFsuQyMT6FbzG+/ER1kt+i+blWjNBf2ej4B1uSGHl1X4TPFO81x9c/2D FrKTdSC5nxs2YgEq86WO9VV66NRQ+estTKUm5KyHOafbuv52E6PLoT3u9ixusmZs4qyVPz2DadZk qdyp1pAxTI/6B8wdP1UAAAAAAAA= ------=_NextPart_000_0023_01CC76BF.E9913320-- From internet-drafts@ietf.org Tue Sep 20 12:10: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 766C821F8A71; Tue, 20 Sep 2011 12:10:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.557 X-Spam-Level: X-Spam-Status: No, score=-102.557 tagged_above=-999 required=5 tests=[AWL=0.042, 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 RTJn5DBv6kxb; Tue, 20 Sep 2011 12:10:20 -0700 (PDT) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EBF9A21F85A4; Tue, 20 Sep 2011 12:10:19 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 3.60 Message-ID: <20110920191019.29511.68737.idtracker@ietfa.amsl.com> Date: Tue, 20 Sep 2011 12:10:19 -0700 Cc: mif@ietf.org Subject: [mif] I-D Action: draft-ietf-mif-dns-server-selection-05.txt X-BeenThere: mif@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multiple Interface Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 20 Sep 2011 19:10:20 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Multiple Interfaces Working Group of = the IETF. Title : Improved DNS Server Selection for Multi-Interfaced Nodes Author(s) : Teemu Savolainen Jun-ya Kato Ted Lemon Filename : draft-ietf-mif-dns-server-selection-05.txt Pages : 26 Date : 2011-09-20 A multi-interfaced node is connected to multiple networks, some of which may be utilizing private DNS namespaces. A node commonly receives DNS server configuration information from all connected networks. Some of the DNS servers may have information about namespaces other servers do not have. When a multi-interfaced node needs to utilize DNS, the node has to choose which of the servers to contact to. This document describes DHCPv4 and DHCPv6 option that can be used to configure nodes with information required to perform informed DNS server selection decisions. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-mif-dns-server-selection-05.= txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ This Internet-Draft can be retrieved at: ftp://ftp.ietf.org/internet-drafts/draft-ietf-mif-dns-server-selection-05.t= xt From teemu.savolainen@nokia.com Tue Sep 20 13:36: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 5A4891F0C83 for ; Tue, 20 Sep 2011 13:36:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7Ck0O53buirC for ; Tue, 20 Sep 2011 13:36:38 -0700 (PDT) Received: from mgw-da01.nokia.com (smtp.nokia.com [147.243.128.24]) by ietfa.amsl.com (Postfix) with ESMTP id 99A001F0C5D for ; Tue, 20 Sep 2011 13:36:38 -0700 (PDT) Received: from vaebh106.NOE.Nokia.com (vaebh106.europe.nokia.com [10.160.244.32]) by mgw-da01.nokia.com (Switch-3.4.4/Switch-3.4.3) with ESMTP id p8KKd3HR016172 for ; Tue, 20 Sep 2011 23:39:04 +0300 Received: from smtp.mgd.nokia.com ([65.54.30.6]) by vaebh106.NOE.Nokia.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.4675); Tue, 20 Sep 2011 23:38:58 +0300 Received: from 008-AM1MMR1-004.mgdnok.nokia.com (65.54.30.59) by NOK-am1MHUB-02.mgdnok.nokia.com (65.54.30.6) with Microsoft SMTP Server (TLS) id 8.2.255.0; Tue, 20 Sep 2011 22:38:57 +0200 Received: from 008-AM1MPN1-037.mgdnok.nokia.com ([169.254.7.199]) by 008-AM1MMR1-004.mgdnok.nokia.com ([65.54.30.59]) with mapi id 14.01.0339.002; Tue, 20 Sep 2011 22:38:57 +0200 From: To: Thread-Topic: [mif] I-D Action: draft-ietf-mif-dns-server-selection-05.txt Thread-Index: AQHMd8lnB6tnA31Pg02StbhXl/KaSpVWuhMA Date: Tue, 20 Sep 2011 20:38:56 +0000 Message-ID: <916CE6CF87173740BC8A2CE44309696202F2C268@008-AM1MPN1-037.mgdnok.nokia.com> References: <20110920191019.29511.68737.idtracker@ietfa.amsl.com> In-Reply-To: <20110920191019.29511.68737.idtracker@ietfa.amsl.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes 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+/nZJb9Kg7Ivi+ZPYNxIOHHQOy5XIAisnd0NemWySEbulPlVI/QHkZZN/9gjDrg6WMjjydPZC1DWU2zvkz3XY45pupziFmhV5UQAEv6XrD6CB72A8WLvBIEpxQHzVoC4o2n9/xCuC2pvaJFRMYrkvM+mKyGAKEfE/kyqzbXdhLIr3iJXMRoiFT6vfNMPZ1IMl9vhxtMisCowj/kzvgCNOJs005u8tKngqUjoMXHmbIU/+rAXJAEKjzyQwT7/BRyd1tzRSvMtJfyw== x-originating-ip: [194.136.87.226] Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=SHA1; boundary="----=_NextPart_000_0094_01CC77EE.74B45980" MIME-Version: 1.0 X-OriginalArrivalTime: 20 Sep 2011 20:38:58.0423 (UTC) FILETIME=[52966870:01CC77D5] X-Nokia-AV: Clean Subject: Re: [mif] I-D Action: draft-ietf-mif-dns-server-selection-05.txt X-BeenThere: mif@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multiple Interface Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 20 Sep 2011 20:36:39 -0000 ------=_NextPart_000_0094_01CC77EE.74B45980 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit I uploaded -05 update so that next comments would take into account changes I already did based on discussions with Murray (as was copied to this list). The biggest clarifications related to how DNS queries are sent to different servers and when all servers are waited for answers (if reply is not validated) and when not. I.e. this text: -- A node SHALL send requests to DNS servers in the order defined by the priority list until an acceptable reply is received, all replies are received, or a time out occurs. In the case of a requested name matching to a specific domain or network rule accepted from any interface, a DNSSEC-aware resolver MUST NOT proceed with a reply that cannot be validated using DNSSEC until all DNS servers on the priority list have been contacted or timed out. This protects against possible redirection attacks. In the case of the requested name not matching to any specific domain or network, first received response from any DNS server MAY be considered acceptable. A DNSSEC- aware node MAY always contact all DNS server in an attempt to receive a response that can be validated, but contacting all DNS servers is not mandated for the default case as in some deployments that would consume excess resources. -- Teemu > -----Original Message----- > From: mif-bounces@ietf.org [mailto:mif-bounces@ietf.org] On Behalf Of > ext internet-drafts@ietf.org > Sent: 20. syyskuuta 2011 22:10 > To: i-d-announce@ietf.org > Cc: mif@ietf.org > Subject: [mif] I-D Action: draft-ietf-mif-dns-server-selection-05.txt > > A New Internet-Draft is available from the on-line Internet-Drafts directories. > This draft is a work item of the Multiple Interfaces Working Group of the > IETF. > > Title : Improved DNS Server Selection for Multi-Interfaced > Nodes > Author(s) : Teemu Savolainen > Jun-ya Kato > Ted Lemon > Filename : draft-ietf-mif-dns-server-selection-05.txt > Pages : 26 > Date : 2011-09-20 > > A multi-interfaced node is connected to multiple networks, some of > which may be utilizing private DNS namespaces. A node commonly > receives DNS server configuration information from all connected > networks. Some of the DNS servers may have information about > namespaces other servers do not have. When a multi-interfaced node > needs to utilize DNS, the node has to choose which of the servers to > contact to. This document describes DHCPv4 and DHCPv6 option that > can be used to configure nodes with information required to perform > informed DNS server selection decisions. > > > A URL for this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-ietf-mif-dns-server-selection- > 05.txt > > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ > > This Internet-Draft can be retrieved at: > ftp://ftp.ietf.org/internet-drafts/draft-ietf-mif-dns-server-selection-05.tx t > _______________________________________________ > mif mailing list > mif@ietf.org > https://www.ietf.org/mailman/listinfo/mif ------=_NextPart_000_0094_01CC77EE.74B45980 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIOuzCCAzYw ggIeoAMCAQICBDpVqdkwDQYJKoZIhvcNAQEFBQAwKTEOMAwGA1UEChMFTm9raWExFzAVBgNVBAMT Dk5va2lhICBSb290IENBMB4XDTAxMDEwNTExMDUwNVoXDTE2MDEwMjExMDUwNVowKTEOMAwGA1UE ChMFTm9raWExFzAVBgNVBAMTDk5va2lhICBSb290IENBMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8A MIIBCgKCAQEAsrTy8gLmr4LYvp0khVUVHw7ascdl+Cjr+yI5MlZ6J/U6Qsvkiqthgqq8rPcLV0P1 92TfBr27VgKEeCaZe0icS1jC2spM/wRv3j2WxdkKxb9kDJtuCNJaRBqvi5vGTHB15nmEmKuL5f3i rAxeHqPjgS496oWcudzFT1e7Xrc/gWGFYd72+/ykIFXjWOMZv6QpxD8x1hLPyh2YVXRk9U7N7pvm RQNX29g4SCFJY2BBIa5JPlwIF8Nc9IePaC/E/2M4tGMtiOOZlm99EoL7N0hJZtFSvUwdCBud/viH 4DgsKGjNkNKi6pAHc9IaXB6tIykcoYp+L+oe/3+cuEJaCj1EKwIDAQABo2YwZDASBgNVHRMBAf8E CDAGAQH/AgEEMB0GA1UdDgQWBBSNjfefoQ0AITLvqe0iruA79NB9sDAfBgNVHSMEGDAWgBSNjfef oQ0AITLvqe0iruA79NB9sDAOBgNVHQ8BAf8EBAMCAYYwDQYJKoZIhvcNAQEFBQADggEBAIGEPql2 TALyKi/h1J+Mh5XolAtYppcSOLMtBkoA7ZovGBDNvl0VbZs8AAojJqkUoWBB+L6DKyl/jKhNfKcu rWRGRyj7pnbxrKLsI3gmWNWkyo2b60wJwe9fqPD5ZQy3oEiMit9l0Ba6il/k2GqYopUCNMa7mfeb E2LeBy5ChYMiCi97UQSJvAdzEYylTJw8Awc6AiM2Ve5N+XxsmKgNf/2A/5IJ3EZZ+wFRmkI4062A oNU302rqAt0HH88jzoUF4AfYHWl6HpYhGXFbcX44rHINyPmFBRxLYIFJ6ZWUr/mXpL/e6rqFtNWO kV6UoJND7OVZkbLh7F1+lcqXRU8TPBMwggOHMIICb6ADAgECAgRBtbHpMA0GCSqGSIb3DQEBBQUA MCkxDjAMBgNVBAoTBU5va2lhMRcwFQYDVQQDEw5Ob2tpYSAgUm9vdCBDQTAeFw0wNjAzMzAwOTU3 MTFaFw0xNjAxMDIxMTA1MDVaMDMxCzAJBgNVBAYTAkZJMQ4wDAYDVQQKEwVOb2tpYTEUMBIGA1UE AxMLTm9raWEgQkkgQ0EwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQDtFCg3QEjSCg6T IUxoWsNwELh8bBNiUQPCPmg8c2DHQYXWWCSCMb+S0Fvh1qqI1xt+XnzyFq+5eqzGzDj4UaBcG+d9 qxrCFly8sHyoPTryyPrR0EI2UUDWwfS6ojhqgwghRqo8G38TjFusyBtLub/5L6yvWYSOHD+JcB+q VM2fbkArPYK4Ydv8WG/DbHjGn0gKq0zwpVZKI/gCK/QALYvte02NXseqvY9/GOyLtjy3Z8erFv71 KKTq+gxI/7DK55pJf3PoD+kT4kyGm6EF9DTdK4ojMdar17uyX0IOZz/4vkkF0d+60nmnLX63FJPA jUyB0HUNJ32NXDo9UsM38aoNAgMBAAGjgawwgakwDwYDVR0TAQH/BAUwAwEB/zARBgNVHSAECjAI MAYGBFUdIAAwDgYDVR0PAQH/BAQDAgGGMFQGA1UdIwRNMEuAFI2N95+hDQAhMu+p7SKu4Dv00H2w oS2kKzApMQ4wDAYDVQQKEwVOb2tpYTEXMBUGA1UEAxMOTm9raWEgIFJvb3QgQ0GCBDpVqdkwHQYD VR0OBBYEFKcksD7Fg+8EDlB2Sxgy58pW0Sy6MA0GCSqGSIb3DQEBBQUAA4IBAQAC3lEUplDlVNOT Pjz/XFezXx2bV2XbCFindhA3F815Egi55H6/cYezEjoP4QLNEGGl2I3aLvkn5A0T8I4pbiFPhIiu B/frbbGg6k6GjQLe/bFQ8F1mAOOR+GyneKZFPfzaRV0jiIR9QqnMXTf8RvKkCJyFj10MZVsLIy/Y uBkzeP3JhzDhUdtPfwmJN6ZbIhH5uR/2BwAGtgQknb8WX3I4wnhWtMUxB8XmayayYs8qWYeIiVkI FV+sLTkWUWVvvKUjyakBpbAW2vUP84DYsJ8TL1YefNjf/nIOByMcORLuV/1gPjyv00qJbcB59AA+ iXe3zIo8QNcgXG0uPQQFmrGDMIID5DCCAsygAwIBAgIQMH5apak8lEy6LmLlLsJy8TANBgkqhkiG 9w0BAQUFADAzMQswCQYDVQQGEwJGSTEOMAwGA1UEChMFTm9raWExFDASBgNVBAMTC05va2lhIEJJ IENBMB4XDTExMDkwNjA1NTIwNFoXDTE0MDkwNjA1NTIwNFowVjEOMAwGA1UECgwFTm9raWExDzAN BgNVBAsMBlBlb3BsZTEYMBYGCgmSJomT8ixkAQEMCDEwMDI0Njc2MRkwFwYDVQQDDBBTYXZvbGFp bmVuIFRlZW11MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAshEsmw6Yiz6XWX26oF+I s5fsfE1OfCjOelclmtqCiIgXND5klkNOBs2d4ZGzgD9mN+XnTZnOTh249c2WxPBugf12DCcDmBAJ gL+VuWUJVBTE5NRchm/O8nZnZsRFst+gAC9/Juykh4+EYewZ7QbpnlwW7hNpj8eH+rMr+OZHKzdp KTftgVjmuF4JJ/cPMQUjL8SuGj+zBW6IWPOZdqkEMtf7Pr8kkYbZsh0SgJ0ceRHZ7Uc06mB/y+C1 UnJPxehTTdu8tpCjdzXgBw/H2uuW1J3qdHbCfbuDILql8V8RiZKubcZLhdsD3Jvj8qK0DGWBJa6x p90q5p3pLE8LvAeCgQIDAQABo4HQMIHNMA4GA1UdDwEB/wQEAwIEMDAfBgNVHSMEGDAWgBSnJLA+ xYPvBA5QdksYMufKVtEsujAZBgNVHSAEEjAQMA4GDCsGAQQBXgExBgEHAzA5BgNVHR8EMjAwMC6g LKAqhihodHRwOi8vY3JsLm5va2lhLmNvbS9Ob2tpYSUyMEJJJTIwQ0EuY3JsMCUGA1UdEQQeMByB GnRlZW11LnNhdm9sYWluZW5Abm9raWEuY29tMB0GA1UdDgQWBBQTRzvZsgmQrAGCeuzdHTGAC6Jg UzANBgkqhkiG9w0BAQUFAAOCAQEACmPVsdi07pjK5gDa+W5JlE2C74kVVsB8alBqfioYeR5At2FG B7sua4Dz5H7TJMpZ1jYFeI+zjexD5f+beY2IlV15lMoWD+5e38QlLYjwfe2LAyvdzBKXW0e0U6Bt p78ft4gyVak1X+Db+ebR+FNHUOMNhm+yK3w9sy5ZQzBFusIx4OgxGvcZhyhmd9WjipSTalgPwgqV Ju2aPADCG++OEXmgEWRLsR4yNopkgK4ftVqrN5uUtLs83qdeXTRcNRiET1IOx5zmYFZ6q3gjKIx5 iyuxcDeYas93vVHUcaRRYpsoby5CHq7Z/j/TQhtqO/knWuxLFFiCUgdGKMKrRkg29DCCBAowggLy oAMCAQICEQCBvi+p+bA/dBtBtybwA6YYMA0GCSqGSIb3DQEBBQUAMDMxCzAJBgNVBAYTAkZJMQ4w DAYDVQQKEwVOb2tpYTEUMBIGA1UEAxMLTm9raWEgQkkgQ0EwHhcNMTEwOTA2MDU1MDM0WhcNMTMw OTA1MDU1MDM0WjBWMQ4wDAYDVQQKDAVOb2tpYTEPMA0GA1UECwwGUGVvcGxlMRgwFgYKCZImiZPy LGQBAQwIMTAwMjQ2NzYxGTAXBgNVBAMMEFNhdm9sYWluZW4gVGVlbXUwggEiMA0GCSqGSIb3DQEB AQUAA4IBDwAwggEKAoIBAQDFPmbRVwuo52v+h6xnQUqokAx2xsHjmPBniEkzgtgBNJsFi838ATEg 1zsx+VotoJg7hMijcrQfpTAgW6gpLGnlmw5QQswrNK1zleOHb4pA5JguU3WhVKFkAH/6/2EU2k/9 m8Pb/gwP55cYg80R6fRmbdsWKhseXF/1isW/rJcWLmIYDg/rXfo3ixqtT9MroAMiuoXnb0ij1L2d Jj64LDp3Ld8Jo0qZzk3Fj4apo8PBd8eAH6HloVBJkxQcwAnv561A+Xi1GHZ2mafRYJGO+1uBDwyd g/8ybEXXA4MKo8lPKjBebYBUFvz80DBA/Lq74UysXkG23BSulcG4xQSYGlyzAgMBAAGjgfUwgfIw HwYDVR0jBBgwFoAUpySwPsWD7wQOUHZLGDLnylbRLLowGQYDVR0gBBIwEDAOBgwrBgEEAV4BMQYB BgQwOQYDVR0fBDIwMDAuoCygKoYoaHR0cDovL2NybC5ub2tpYS5jb20vTm9raWElMjBCSSUyMENB LmNybDAjBgNVHSUEHDAaBggrBgEFBQcDAgYEVR0lAAYIKwYBBQUHAwQwDgYDVR0PAQH/BAQDAgeA MCUGA1UdEQQeMByBGnRlZW11LnNhdm9sYWluZW5Abm9raWEuY29tMB0GA1UdDgQWBBTGhbTJF0EX iagjymQo6GIuSQeRVDANBgkqhkiG9w0BAQUFAAOCAQEAqai6TxZ/BlMHZIhJNPriBPXkQhUlBkGA buJZ5sVm1HIQhWN8elZKjjJdHi1qWEKhMg7yHjEMZsyV8XAZzK0UnOqkpUnt+jnVkNZ9O7/jRtyK f4WUtq5jErc8Hlv4bbGFRHk1T7AuLLE52r1lYOdmoibnQp03QtlDvHUNa68G7jvzThJhieB7U1xh vH3yy0ktaVnWEgAylqf9yIUFjnqau5R6cE1Xo57IYPk/KitX0YF+OigEI/bOQVMi+fze93ZsAOJv /z6g/NGemvUgl5YSdX0uPQK6kEHf/sp/nZyUWWQ7OjtVSqkq2YuYEueQFxTfafl+78GWqgm6W/Bl 32laYzGCAuswggLnAgEBMEgwMzELMAkGA1UEBhMCRkkxDjAMBgNVBAoTBU5va2lhMRQwEgYDVQQD EwtOb2tpYSBCSSBDQQIRAIG+L6n5sD90G0G3JvADphgwCQYFKw4DAhoFAKCCAXgwGAYJKoZIhvcN AQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG9w0BCQUxDxcNMTEwOTIwMjAzODUzWjAjBgkqhkiG9w0B CQQxFgQUUHFOjykT0vp8GJ7qnvDFJu+3oOQwVgYJKwYBBAGCNxAEMUkwRzAzMQswCQYDVQQGEwJG STEOMAwGA1UEChMFTm9raWExFDASBgNVBAMTC05va2lhIEJJIENBAhAwflqlqTyUTLouYuUuwnLx MFgGCyqGSIb3DQEJEAILMUmgRzAzMQswCQYDVQQGEwJGSTEOMAwGA1UEChMFTm9raWExFDASBgNV BAMTC05va2lhIEJJIENBAhAwflqlqTyUTLouYuUuwnLxMGcGCSqGSIb3DQEJDzFaMFgwCgYIKoZI hvcNAwcwDgYIKoZIhvcNAwICAgCAMA0GCCqGSIb3DQMCAgFAMAcGBSsOAwIHMA0GCCqGSIb3DQMC AgEoMAcGBSsOAwIaMAoGCCqGSIb3DQIFMA0GCSqGSIb3DQEBAQUABIIBAJftoR5bs8iWpqaETFnu eXKmYAMTvpX2wzJNxZNNQQaX1vYTWOj+YsqFR5yLIk054p8+YCMCnTPC/GVeaVn/p4YG0joDR4t+ LOk4NRKYIbR8Hyy9NxW0ch1D6rwmOgvl59IYHI/dyRv73ujQA3C/PRPb9mo+/EBdxn7PWEEqzUFG RZpgEHVh3FGzqD5uoZAwmNllCIwjfrTLXhxyEyNqAFkLCyn3qnOySesNuFwJ2W3yMl96+LZQyRhY giufm+xVJMQU1vlyJdF+QrzMuSOQAiuY3NKuME1srAbHq0fNWxS2P3Lic0eF+xy6YjZvUn9yS2UX XxNI6Ss33XScsdcRZfMAAAAAAAA= ------=_NextPart_000_0094_01CC77EE.74B45980-- From maximilien.mouton@gmail.com Mon Sep 26 01:39: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 2D21921F8B51 for ; Mon, 26 Sep 2011 01:39:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.999 X-Spam-Level: X-Spam-Status: No, score=-2.999 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_45=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 6YPlj2r2rV2m for ; Mon, 26 Sep 2011 01:39:52 -0700 (PDT) Received: from mail-ey0-f172.google.com (mail-ey0-f172.google.com [209.85.215.172]) by ietfa.amsl.com (Postfix) with ESMTP id 5AB7E21F8B50 for ; Mon, 26 Sep 2011 01:39:52 -0700 (PDT) Received: by eye4 with SMTP id 4so3509023eye.31 for ; Mon, 26 Sep 2011 01:42:34 -0700 (PDT) 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:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; bh=hu1exEXxMQCyp/jiEVV72WvNcqVnmFrKmfpzprrwJRY=; b=RkawLr5+rnILtquJosrUAoVwddIUPWx5C4bYs6zHn3aJvbNOkRrsH+Rze8O2PNITbn AMM88V6fYNEPa8H1eBaOMBG7gQFdNk55wRxhcKLlfzoKru2/e1snZnd7XpeHUGhqXZ8E NS/nfIGjGR5WMao48HiromPLZSEWqEULmQ4Jc= Received: by 10.14.19.144 with SMTP id n16mr1289971een.128.1317026553927; Mon, 26 Sep 2011 01:42:33 -0700 (PDT) Received: from [127.0.0.1] ([158.64.77.102]) by mx.google.com with ESMTPS id v60sm57755264eev.12.2011.09.26.01.42.32 (version=SSLv3 cipher=OTHER); Mon, 26 Sep 2011 01:42:33 -0700 (PDT) Message-ID: <4E803AE5.2000203@gmail.com> Date: Mon, 26 Sep 2011 10:42:13 +0200 From: maximilien mouton User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:6.0.2) Gecko/20110902 Thunderbird/6.0.2 MIME-Version: 1.0 To: Simon Perreault References: <3CF88B99A9ED504197498BC6F6F04B81040FBDA9@XMB-BGL-41E.cisco.com> <4E6E7A72.9030208@gmail.com> <4E6EAFC2.5060906@gmail.com> <4E6EDEA8.3080108@gmail.com> <4E6F825C.3080303@gmail.com> <3D0B3661-8A8F-4BB2-A8EF-25007BEAF66C@nominum.com> <4E6F923F.7090304@gmail.com> <7061CEB8-8084-41D5-B31E-9F8E3B6C7091@nominum.com> <4E6F9B91.7010503@gmail.com> <4E6FA049.1040309@viagenie.ca> In-Reply-To: <4E6FA049.1040309@viagenie.ca> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Cc: mif@ietf.org Subject: Re: [mif] Comments on draft-mouton-mif-dhcpv6-drlo-00 X-BeenThere: mif@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multiple Interface Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 26 Sep 2011 08:39:53 -0000 Hi Simon and Ted, Le 13/09/2011 20:26, Simon Perreault a 閏rit : > Ted Lemon wrote, on 09/13/2011 02:22 PM: >> Could you please clearly articulate a use case where this option is >> necessary, and the existing proposed option is not adequate? >> Please do not mention operating system data structures. Please do >> not say "I find it to be the case that.." Without a use case, I >> just don't see the point in discussing this further. > > +1 First, I think we can say that there is a consensus on the fact that DHCP should have an option including default router. Second, why a specific option for default route rather than specify it in route option? You can notice that router option and static route option (the stateful one) are defined separately since rfc 2132 (DHCP Options). Moreover, rfc 3442 (Route Option for DHCP version 4) has a similar point of view than what we propose with DRLO. But beside this history point here is a scenario explaining the need of specific option for default route: Imagine a realistic network in which in the same prefix is, a limited resource device not able to carry more than a default route (see previous discussion with Alex), a classic device like a laptop with one interface and a MIF device which want to run route option. A reasonable configuration is DRLO for 2 the two first type of device and DRLO+route option for the third (less frequent case). In the opposit specify specific routes without default route may be useful for instance for security or accounting reasons. Maximilien > > Simon From maximilien.mouton@gmail.com Mon Sep 26 01:41: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 F047B21F8B50 for ; Mon, 26 Sep 2011 01:41:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.299 X-Spam-Level: X-Spam-Status: No, score=-3.299 tagged_above=-999 required=5 tests=[AWL=0.300, BAYES_00=-2.599, 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 oBTBVjhHynzj for ; Mon, 26 Sep 2011 01:41:18 -0700 (PDT) Received: from mail-ey0-f172.google.com (mail-ey0-f172.google.com [209.85.215.172]) by ietfa.amsl.com (Postfix) with ESMTP id F1CE921F8B3F for ; Mon, 26 Sep 2011 01:41:17 -0700 (PDT) Received: by eye4 with SMTP id 4so3510124eye.31 for ; Mon, 26 Sep 2011 01:43:59 -0700 (PDT) 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:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; bh=Nimjn21Owog7VFt11w6l8vKHfJBPAcp8EqfgyUSlsr8=; b=AUgc/vI/bhGU+0cqwv4NV8Wj4PiQzuLday8VLNckcLxCM3n/BnJm8fXvcMQDZ869rL Pywq/an1f1KEHSU5J0wRnEKRD8vyuTvvov/Up7qIW0JLll59Nr8y6ZlkfUGKFX32wTe8 tFaUoEAQU4dEpkX6aLMsy/s9OSfNE2hfxyf3Q= Received: by 10.213.27.68 with SMTP id h4mr1543142ebc.108.1317026638094; Mon, 26 Sep 2011 01:43:58 -0700 (PDT) Received: from [127.0.0.1] ([158.64.77.102]) by mx.google.com with ESMTPS id v9sm57832778eej.5.2011.09.26.01.43.57 (version=SSLv3 cipher=OTHER); Mon, 26 Sep 2011 01:43:57 -0700 (PDT) Message-ID: <4E803B3A.7010905@gmail.com> Date: Mon, 26 Sep 2011 10:43:38 +0200 From: maximilien mouton User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:6.0.2) Gecko/20110902 Thunderbird/6.0.2 MIME-Version: 1.0 To: Ted Lemon References: <3CF88B99A9ED504197498BC6F6F04B81040FBDA9@XMB-BGL-41E.cisco.com> <4E6E7A72.9030208@gmail.com> <4E6EAFC2.5060906@gmail.com> <4E6EDEA8.3080108@gmail.com> <4E6F967B.5030909@gmail.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Cc: "" Subject: Re: [mif] Comments on draft-mouton-mif-dhcpv6-drlo-00 X-BeenThere: mif@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multiple Interface Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 26 Sep 2011 08:41:19 -0000 Hi Ted again, Le 13/09/2011 19:56, Ted Lemon a 閏rit : > On Sep 13, 2011, at 1:44 PM, Maximilien MOUTON wrote: >> Even if I grant It would imply big changes in DHCP, I think it >> would be interesting for DHCP to imitate ND dynamic behavior >> because in this draft we are trying to challenge ND by allowing >> DHCP to provide an entire IP/Internet configuration by its own. > > We never had a TTL on the route offered in DHCPv4. Why is DHCPv6 > different? DHCPv6 could be different because of ND. Why include a lifetime in default router list option(DRLO)? ND has been chosen as the best way for default router configuration because it provides a dynamic autoconfiguration. But in some case RA is not set or not desirable. This is what describes Ralph Droms in draft-droms-dhc-dhcpv6-default-router-00. This is why DHCP should provide default router also. Use cases for using default router lifetime are actually each cases in which you can use ND for autoconf and either you can't or don't want to. An example of scenario is given in the draft. As we are here challenging ND as an autoconfiguration mechanism we propose a solution which tries to imitate its dynamic behavior. This is why we propose a lifetime. Here's a concrete case to illustrate this: A client has multiple default routers available. Usually if those routers use RA if the selected default router fails, the connectivity of the client is down while the lifetime of the router in its default router list is not null. At this time another default router is selected. But if a static configuration is used without lifetime, as far as I know, the default router list is not updated and the client connectivity is never recovered whereas it could be. The default router lifetime could solve this problem by making the failed router expire in the client's default router list and let another one take its place. We receive also questions about the interest of providing a link layer address. Why a link layer address field? Because it avoids unnecessary NS/NA exchange which represents an economy of network resources (very useful for some resource constraint networks) and a gain of time because client don't need to wait for NA anymore. This field is also useful if ND is nor present in the link between the client and the router. Maximilien > > > > _______________________________________________ mif mailing list > mif@ietf.org https://www.ietf.org/mailman/listinfo/mif From alexandru.petrescu@gmail.com Mon Sep 26 06:04: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 C987621F8C2A for ; Mon, 26 Sep 2011 06:04:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.385 X-Spam-Level: X-Spam-Status: No, score=-4.385 tagged_above=-999 required=5 tests=[AWL=1.864, 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 X-u4lAvl0A8I for ; Mon, 26 Sep 2011 06:04:59 -0700 (PDT) Received: from sainfoin-out.extra.cea.fr (sainfoin-out.extra.cea.fr [132.167.192.144]) by ietfa.amsl.com (Postfix) with ESMTP id E7E3521F8BF3 for ; Mon, 26 Sep 2011 06:04:58 -0700 (PDT) Received: from pisaure.intra.cea.fr (pisaure.intra.cea.fr [132.166.88.21]) by sainfoin.extra.cea.fr (8.14.2/8.14.2/CEAnet-Internet-out-2.2) with ESMTP id p8QD7e9H020941 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT) for ; Mon, 26 Sep 2011 15:07:40 +0200 Received: from muguet2.intra.cea.fr (muguet2.intra.cea.fr [132.166.192.7]) by pisaure.intra.cea.fr (8.14.4/8.14.4) with ESMTP id p8QD7eQe016433 for ; Mon, 26 Sep 2011 15:07:40 +0200 (envelope-from alexandru.petrescu@gmail.com) Received: from [127.0.0.1] ([132.166.133.183]) by muguet2.intra.cea.fr (8.13.8/8.13.8/CEAnet-Intranet-out-1.1) with ESMTP id p8QD7akZ021800 for ; Mon, 26 Sep 2011 15:07:39 +0200 Message-ID: <4E807918.1020308@gmail.com> Date: Mon, 26 Sep 2011 15:07:36 +0200 From: Alexandru Petrescu User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:6.0.2) Gecko/20110902 Thunderbird/6.0.2 MIME-Version: 1.0 To: mif@ietf.org References: <3CF88B99A9ED504197498BC6F6F04B81040FBDA9@XMB-BGL-41E.cisco.com> <4E6E7A72.9030208@gmail.com> <4E6EAFC2.5060906@gmail.com> <4E6EDEA8.3080108@gmail.com> <4E6F825C.3080303@gmail.com> <3D0B3661-8A8F-4BB2-A8EF-25007BEAF66C@nominum.com> <4E6F923F.7090304@gmail.com> <7061CEB8-8084-41D5-B31E-9F8E3B6C7091@nominum.com> <4E6F9B91.7010503@gmail.com> <4E6FA049.1040309@viagenie.ca> <4E803AE5.2000203@gmail.com> In-Reply-To: <4E803AE5.2000203@gmail.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Subject: Re: [mif] IPv4 similarity in DefRoute-distinct-from-RouteOption (was: Comments on draft-mouton-mif-dhcpv6-drlo-00) X-BeenThere: mif@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multiple Interface Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 26 Sep 2011 13:04:59 -0000 Maximilien, With respect to one particular point you mention below: Le 26/09/2011 10:42, maximilien mouton a 閏rit : > Hi Simon and Ted, > > Le 13/09/2011 20:26, Simon Perreault a 閏rit : >> Ted Lemon wrote, on 09/13/2011 02:22 PM: >>> Could you please clearly articulate a use case where this option >>> is necessary, and the existing proposed option is not adequate? >>> Please do not mention operating system data structures. Please do >>> not say "I find it to be the case that.." Without a use case, I >>> just don't see the point in discussing this further. >> >> +1 [...] > You can notice that router option and static route option (the > stateful one) are defined separately since rfc 2132 (DHCP Options). > Moreover, rfc 3442 (Route Option for DHCP version 4) has a similar > point of view than what we propose with DRLO. Looking through RFC2132 and RFC3442 I understand that DHCPv4 uses distinct options for classful - and incidentally default - route (option code 33), than for classless routes (121). The reason for a new option 121 seems to have been the classlessness absence in classful routes at thetime, and worse 33 option seems non-extensible. Nonetheless, the IPv4 software ended up with distinct options: one for default route and one for classless routes. It would be little straightforward to port that IPv4 software to IPv6 if this latter had only one option for both route and default route. Alex [...] From Ted.Lemon@nominum.com Mon Sep 26 08:03: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 0C94A21F8CF3 for ; Mon, 26 Sep 2011 08:03:56 -0700 (PDT) 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.027, 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 wWAk+KAd-Ktw for ; Mon, 26 Sep 2011 08:03:55 -0700 (PDT) Received: from exprod7og119.obsmtp.com (exprod7og119.obsmtp.com [64.18.2.16]) by ietfa.amsl.com (Postfix) with ESMTP id 513C621F8CB8 for ; Mon, 26 Sep 2011 08:03:54 -0700 (PDT) Received: from shell-too.nominum.com ([64.89.228.229]) (using TLSv1) by exprod7ob119.postini.com ([64.18.6.12]) with SMTP ID DSNKToCU/bORAXOzLV8umkTaPt/RmcieVrxr@postini.com; Mon, 26 Sep 2011 08:06:38 PDT Received: from archivist.nominum.com (archivist.nominum.com [64.89.228.108]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "*.nominum.com", Issuer "Go Daddy Secure Certification Authority" (verified OK)) by shell-too.nominum.com (Postfix) with ESMTP id 54CEB1B8470 for ; Mon, 26 Sep 2011 08:06:37 -0700 (PDT) Received: from webmail.nominum.com (cas-02.win.nominum.com [64.89.228.132]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (Client CN "mail.nominum.com", Issuer "Go Daddy Secure Certification Authority" (verified OK)) by archivist.nominum.com (Postfix) with ESMTPS id 476AF190052; Mon, 26 Sep 2011 08:06:37 -0700 (PDT) (envelope-from Ted.Lemon@nominum.com) Received: from MBX-01.WIN.NOMINUM.COM ([64.89.228.133]) by CAS-02.WIN.NOMINUM.COM ([64.89.228.132]) with mapi id 14.01.0323.003; Mon, 26 Sep 2011 08:06:37 -0700 From: Ted Lemon To: Alexandru Petrescu Thread-Topic: [mif] IPv4 similarity in DefRoute-distinct-from-RouteOption (was: Comments on draft-mouton-mif-dhcpv6-drlo-00) Thread-Index: AQHMfE1JTf4LgNHYIE2Rdm+waETggJVgOIUA Date: Mon, 26 Sep 2011 15:06:36 +0000 Message-ID: References: <3CF88B99A9ED504197498BC6F6F04B81040FBDA9@XMB-BGL-41E.cisco.com> <4E6E7A72.9030208@gmail.com> <4E6EAFC2.5060906@gmail.com> <4E6EDEA8.3080108@gmail.com> <4E6F825C.3080303@gmail.com> <3D0B3661-8A8F-4BB2-A8EF-25007BEAF66C@nominum.com> <4E6F923F.7090304@gmail.com> <7061CEB8-8084-41D5-B31E-9F8E3B6C7091@nominum.com> <4E6F9B91.7010503@gmail.com> <4E6FA049.1040309@viagenie.ca> <4E803AE5.2000203@gmail.com> <4E807918.1020308@gmail.com> In-Reply-To: <4E807918.1020308@gmail.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [64.89.227.148] Content-Type: multipart/alternative; boundary="_000_C2E732086CF641938ACBAB3B34F390CBnominumcom_" MIME-Version: 1.0 Cc: "" Subject: Re: [mif] IPv4 similarity in DefRoute-distinct-from-RouteOption (was: Comments on draft-mouton-mif-dhcpv6-drlo-00) X-BeenThere: mif@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multiple Interface Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 26 Sep 2011 15:03:56 -0000 --_000_C2E732086CF641938ACBAB3B34F390CBnominumcom_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable On Sep 26, 2011, at 9:07 AM, Alexandru Petrescu wrote: Nonetheless, the IPv4 software ended up with distinct options: one for default route and one for classless routes. It would be little straightforward to port that IPv4 software to IPv6 if this latter had only one option for both route and default route. I personally consider it an unfortunate artifact of the way the classless s= tatic routes option evolved that we weren't able to have it support all rou= tes, including the default route. It's always a bad idea to have two ways= of specifying the same information=97it creates a very clear potential for= interoperability problems. --_000_C2E732086CF641938ACBAB3B34F390CBnominumcom_ Content-Type: text/html; charset="Windows-1252" Content-ID: <94D9E5D833BF1547AAE6ECB2C2BB06B8@nominum.com> Content-Transfer-Encoding: quoted-printable
On Sep 26, 2011, at 9:07 AM, Alexandru Petrescu wrote:
Nonetheless, the IPv4 software ended up with distinct options: one for
default route and one for classless routes.  It would be little
straightforward to port that IPv4 software to IPv6 if this latter had
only one option for both route and default route.

I personally consider it an unfortunate artifact of the way the classl= ess static routes option evolved that we weren't able to have it support al= l routes, including the default route.   It's always a bad idea to hav= e two ways of specifying the same information=97it creates a very clear potential for interoperability problems.

--_000_C2E732086CF641938ACBAB3B34F390CBnominumcom_-- From marc.blanchet@viagenie.ca Mon Sep 26 08:05: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 B5F7C21F8D7A for ; Mon, 26 Sep 2011 08:05:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.775 X-Spam-Level: X-Spam-Status: No, score=-102.775 tagged_above=-999 required=5 tests=[AWL=-0.175, 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 hT6C5HdJEnP6 for ; Mon, 26 Sep 2011 08:05:57 -0700 (PDT) Received: from jazz.viagenie.ca (unknown [IPv6:2620:0:230:8000:226:55ff:fe57:14db]) by ietfa.amsl.com (Postfix) with ESMTP id 23B1921F8CF3 for ; Mon, 26 Sep 2011 08:05:57 -0700 (PDT) Received: from [IPv6:2607:fa48:6e6b:c280:3cbe:25fe:e30e:bedd] (unknown [IPv6:2607:fa48:6e6b:c280:3cbe:25fe:e30e:bedd]) by jazz.viagenie.ca (Postfix) with ESMTPSA id A780C21C52; Mon, 26 Sep 2011 11:08:39 -0400 (EDT) Mime-Version: 1.0 (Apple Message framework v1244.3) Content-Type: text/plain; charset=windows-1252 From: Marc Blanchet In-Reply-To: Date: Mon, 26 Sep 2011 11:08:38 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: <6D49E8C2-1D38-4612-98E7-B56FE2FF76AC@viagenie.ca> References: <3CF88B99A9ED504197498BC6F6F04B81040FBDA9@XMB-BGL-41E.cisco.com> <4E6E7A72.9030208@gmail.com> <4E6EAFC2.5060906@gmail.com> <4E6EDEA8.3080108@gmail.com> <4E6F825C.3080303@gmail.com> <3D0B3661-8A8F-4BB2-A8EF-25007BEAF66C@nominum.com> <4E6F923F.7090304@gmail.com> <7061CEB8-8084-41D5-B31E-9F8E3B6C7091@nominum.com> <4E6F9B91.7010503@gmail.com> <4E6FA049.1040309@viagenie.ca> <4E803AE5.2000203@gmail.com> <4E807918.1020308@gmail.com> To: Ted Lemon X-Mailer: Apple Mail (2.1244.3) Cc: "" Subject: Re: [mif] IPv4 similarity in DefRoute-distinct-from-RouteOption (was: Comments on draft-mouton-mif-dhcpv6-drlo-00) X-BeenThere: mif@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multiple Interface Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 26 Sep 2011 15:05:57 -0000 Le 2011-09-26 =E0 11:06, Ted Lemon a =E9crit : > On Sep 26, 2011, at 9:07 AM, Alexandru Petrescu wrote: >> Nonetheless, the IPv4 software ended up with distinct options: one = for >> default route and one for classless routes. It would be little >> straightforward to port that IPv4 software to IPv6 if this latter had >> only one option for both route and default route. >=20 > I personally consider it an unfortunate artifact of the way the = classless static routes option evolved that we weren't able to have it = support all routes, including the default route. It's always a bad = idea to have two ways of specifying the same information=97it creates a = very clear potential for interoperability problems. s/interoperability/interoperability and operational/ Marc. >=20 > _______________________________________________ > mif mailing list > mif@ietf.org > https://www.ietf.org/mailman/listinfo/mif From Ted.Lemon@nominum.com Mon Sep 26 08:11:29 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 A691921F8C86 for ; Mon, 26 Sep 2011 08:11:29 -0700 (PDT) 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.026, 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 92Uf549PUNMI for ; Mon, 26 Sep 2011 08:11:29 -0700 (PDT) Received: from exprod7og124.obsmtp.com (exprod7og124.obsmtp.com [64.18.2.26]) by ietfa.amsl.com (Postfix) with ESMTP id DBFD921F8C77 for ; Mon, 26 Sep 2011 08:11:28 -0700 (PDT) Received: from shell-too.nominum.com ([64.89.228.229]) (using TLSv1) by exprod7ob124.postini.com ([64.18.6.12]) with SMTP ID DSNKToCWwmQ+5OWXHvFCmSRQLrafKTUfK43C@postini.com; Mon, 26 Sep 2011 08:14:12 PDT Received: from archivist.nominum.com (archivist.nominum.com [64.89.228.108]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "*.nominum.com", Issuer "Go Daddy Secure Certification Authority" (verified OK)) by shell-too.nominum.com (Postfix) with ESMTP id 822F81B846F for ; Mon, 26 Sep 2011 08:14:10 -0700 (PDT) Received: from webmail.nominum.com (cas-02.win.nominum.com [64.89.228.132]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (Client CN "mail.nominum.com", Issuer "Go Daddy Secure Certification Authority" (verified OK)) by archivist.nominum.com (Postfix) with ESMTPS id 7CCE6190052; Mon, 26 Sep 2011 08:14:10 -0700 (PDT) (envelope-from Ted.Lemon@nominum.com) Received: from MBX-01.WIN.NOMINUM.COM ([64.89.228.133]) by CAS-02.WIN.NOMINUM.COM ([64.89.228.132]) with mapi id 14.01.0323.003; Mon, 26 Sep 2011 08:14:10 -0700 From: Ted Lemon To: maximilien mouton Thread-Topic: [mif] Comments on draft-mouton-mif-dhcpv6-drlo-00 Thread-Index: AcxxClosDL9zuhm1Q+CTqXShqzwWxAAw84cAAAfxtgAABv0IAAARg+mAAAbg3wAAAWjoAAAA9R+AAAEFqoAAAF3hgAAAk6wAAAAgVoACeWPhgAANsJoA Date: Mon, 26 Sep 2011 15:14:10 +0000 Message-ID: <303B5E8F-2AF8-4DB5-A51D-5DE07925B58C@nominum.com> References: <3CF88B99A9ED504197498BC6F6F04B81040FBDA9@XMB-BGL-41E.cisco.com> <4E6E7A72.9030208@gmail.com> <4E6EAFC2.5060906@gmail.com> <4E6EDEA8.3080108@gmail.com> <4E6F825C.3080303@gmail.com> <3D0B3661-8A8F-4BB2-A8EF-25007BEAF66C@nominum.com> <4E6F923F.7090304@gmail.com> <7061CEB8-8084-41D5-B31E-9F8E3B6C7091@nominum.com> <4E6F9B91.7010503@gmail.com> <4E6FA049.1040309@viagenie.ca> <4E803AE5.2000203@gmail.com> In-Reply-To: <4E803AE5.2000203@gmail.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [64.89.227.148] Content-Type: multipart/alternative; boundary="_000_303B5E8F2AF84DB5A51D5DE07925B58Cnominumcom_" MIME-Version: 1.0 Cc: "" Subject: Re: [mif] Comments on draft-mouton-mif-dhcpv6-drlo-00 X-BeenThere: mif@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multiple Interface Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 26 Sep 2011 15:11:29 -0000 --_000_303B5E8F2AF84DB5A51D5DE07925B58Cnominumcom_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable On Sep 26, 2011, at 4:42 AM, maximilien mouton wrote: Imagine a realistic network in which in the same prefix is, a limited resource device not able to carry more than a default route (see previous discussion with Alex), We hear a lot about fictitious devices that have bizarre limitations like t= his. The reason, for instance, that DHCP only allows 576 byte packets by = default was a theory that there might be some device in the network that wo= uldn't have buffer space for a larger packet. I've never actually seen such a device in the wild, and am skeptical that a= ny such device is likely to exist in the future. If it's got enough memor= y to run DHCP, it's got enough memory to extract the default route from an = option carrying a selection of routes, and it almost certainly also has eno= ugh memory to keep a full routing table anyway. --_000_303B5E8F2AF84DB5A51D5DE07925B58Cnominumcom_ Content-Type: text/html; charset="iso-8859-1" Content-ID: Content-Transfer-Encoding: quoted-printable
On Sep 26, 2011, at 4:42 AM, maximilien mouton wrote:
Imagine a realistic network in which in the same prefix is, a limited
resource device not able to carry more than a default route (see
previous discussion with Alex),

We hear a lot about fictitious devices that have bizarre limitations l= ike this.   The reason, for instance, that DHCP only allows 576 byte p= ackets by default was a theory that there might be some device in the netwo= rk that wouldn't have buffer space for a larger packet.

I've never actually seen such a device in the wild, and am skeptical t= hat any such device is likely to exist in the future.   If it's got en= ough memory to run DHCP, it's got enough memory to extract the default rout= e from an option carrying a selection of routes, and it almost certainly also has enough memory to keep a full r= outing table anyway.

--_000_303B5E8F2AF84DB5A51D5DE07925B58Cnominumcom_-- From denghui02@hotmail.com Fri Sep 30 08:26: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 6881321F8C49; Fri, 30 Sep 2011 08:26:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.148 X-Spam-Level: X-Spam-Status: No, score=-100.148 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_CHARSET_FARAWAY=2.45, 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 Ozse7vX1UZyG; Fri, 30 Sep 2011 08:26:24 -0700 (PDT) Received: from col0-omc2-s3.col0.hotmail.com (col0-omc2-s3.col0.hotmail.com [65.55.34.77]) by ietfa.amsl.com (Postfix) with ESMTP id 7F10721F8BDB; Fri, 30 Sep 2011 08:26:24 -0700 (PDT) Received: from COL118-W55 ([65.55.34.73]) by col0-omc2-s3.col0.hotmail.com with Microsoft SMTPSVC(6.0.3790.4675); Fri, 30 Sep 2011 08:29:18 -0700 Message-ID: Content-Type: multipart/alternative; boundary="_bcee45fa-b601-421d-9227-642c3b85b5f8_" X-Originating-IP: [117.136.0.1] From: Hui Deng To: , , , Date: Fri, 30 Sep 2011 23:29:18 +0800 Importance: Normal MIME-Version: 1.0 X-OriginalArrivalTime: 30 Sep 2011 15:29:18.0255 (UTC) FILETIME=[B81343F0:01CC7F85] X-Mailman-Approved-At: Fri, 30 Sep 2011 08:28:17 -0700 Cc: pk@isoc.de, john_brzozowski@cable.comcast.com, sa.morris7@googlemail.com Subject: [mif] 2nd Last Call for MIF DNS server selection document X-BeenThere: mif@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multiple Interface Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 30 Sep 2011 15:26:25 -0000 --_bcee45fa-b601-421d-9227-642c3b85b5f8_ Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: 8bit Dear all Based on 1st round WG LC, the authors have received significant advice about revision and submited a new version accordingly: http://www.ietf.org/internet-drafts/draft-ietf-mif-dns-server-selection-05.txt And we plan to issue a second round WG LC, and cc to DHCWG, DNSEXT, DNSOP related working groups, please DNSEXT/DNSOP chairs help to forward to the MLs since I may not subscribe to them. This is a 2 weeks with little extension LC, it will finish on October 17, Please send substantive review and editorial comments to mif@ietf.org Thanks a lot for youre view Best regards, Margaret and Hui Below are Teemu's writeup about the revision: I uploaded -05 update so that next comments would take into account changes I already did based on discussions with Murray (as was copied to this list). The biggest clarifications related to how DNS queries are sent to different servers and when all servers are waited for answers (if reply is not validated) and when not. I.e. this text: -- A node SHALL send requests to DNS servers in the order defined by the priority list until an acceptable reply is received, all replies are received, or a time out occurs. In the case of a requested name matching to a specific domain or network rule accepted from any interface, a DNSSEC-aware resolver MUST NOT proceed with a reply that cannot be validated using DNSSEC until all DNS servers on the priority list have been contacted or timed out. This protects against possible redirection attacks. In the case of the requested name not matching to any specific domain or network, first received response from any DNS server MAY be considered acceptable. A DNSSEC- aware node MAY always contact all DNS server in an attempt to receive a response that can be validated, but contacting all DNS servers is not mandated for the default case as in some deployments that would consume excess resources. -- Teemu > -----Original Message----- > From: mif-bounces@ietf.org [mailto:mif-bounces@ietf.org] On Behalf Of > ext internet-drafts@ietf.org > Sent: 20. syyskuuta 2011 22:10 > To: i-d-announce@ietf.org > Cc: mif@ietf.org > Subject: [mif] I-D Action: draft-ietf-mif-dns-server-selection-05.txt - 显示引用文字 - > > A New Internet-Draft is available from the on-line Internet-Drafts directories. > This draft is a work item of the Multiple Interfaces Working Group of the > IETF. > > Title : Improved DNS Server Selection for Multi-Interfaced > Nodes > Author(s) : Teemu Savolainen > Jun-ya Kato > Ted Lemon > Filename : draft-ietf-mif-dns-server-selection-05.txt > Pages : 26 > Date : 2011-09-20 > > A multi-interfaced node is connected to multiple networks, some of > which may be utilizing private DNS namespaces. A node commonly > receives DNS server configuration information from all connected > networks. Some of the DNS servers may have information about > namespaces other servers do not have. When a multi-interfaced node > needs to utilize DNS, the node has to choose which of the servers to > contact to. This document describes DHCPv4 and DHCPv6 option that > can be used to configure nodes with information required to perform > informed DNS server selection decisions. > > > A URL for this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-ietf-mif-dns-server-selection-05.txt --_bcee45fa-b601-421d-9227-642c3b85b5f8_ Content-Type: text/html; charset="gb2312" Content-Transfer-Encoding: 8bit
Dear all
 
Based on 1st round WG LC, the authors have received significant advice about revision and submited a new version accordingly:
http://www.ietf.org/internet-drafts/draft-ietf-mif-dns-server-selection-05.txt
 
And we plan to issue a second round WG LC, and cc to DHCWG, DNSEXT, DNSOP related working groups, please DNSEXT/DNSOP chairs help to forward to the MLs since I may not subscribe to them.
 
This is a 2 weeks with little extension LC, it will finish on October 17,
Please send substantive review and editorial comments to mif@ietf.org
 
Thanks a lot for youre view
Best regards,
 
Margaret and Hui
 
 
 
Below are Teemu's writeup about the revision:
 
I uploaded -05 update so that next comments would take into account changes
I already did based on discussions with Murray (as was copied to this list).
The biggest clarifications related to how DNS queries are sent to different
servers and when all servers are waited for answers (if reply is not
validated) and when not. I.e. this text:
--
  A node SHALL send requests to DNS servers in the order defined by the
  priority list until an acceptable reply is received, all replies are
  received, or a time out occurs.  In the case of a requested name
  matching to a specific domain or network rule accepted from any
  interface, a DNSSEC-aware resolver MUST NOT proceed with a reply that
  cannot be validated using DNSSEC until all DNS servers on the
  priority list have been contacted or timed out.  This protects
  against possible redirection attacks.  In the case of the requested
  name not matching to any specific domain or network, first received
  response from any DNS server MAY be considered acceptable.  A DNSSEC-
  aware node MAY always contact all DNS server in an attempt to receive
  a response that can be validated, but contacting all DNS servers is
  not mandated for the default case as in some deployments that would
  consume excess resources.
--
       Teemu
> -----Original Message-----
> From: mif-bounces@ietf.org [mailto:mif-bounces@ietf.org] On Behalf Of
> ext internet-drafts@ietf.org
> Sent: 20. syyskuuta 2011 22:10
> To: i-d-announce@ietf.org
> Cc: mif@ietf.org
> Subject: [mif] I-D Action: draft-ietf-mif-dns-server-selection-05.txt
- 显示引用文字 -
>
> A New Internet-Draft is available from the on-line Internet-Drafts
directories.
> This draft is a work item of the Multiple Interfaces Working Group of the
> IETF.
>
>       Title           : Improved DNS Server Selection for Multi-Interfaced
> Nodes
>       Author(s)       : Teemu Savolainen
>                           Jun-ya Kato
>                           Ted Lemon
>       Filename        : draft-ietf-mif-dns-server-selection-0 5.txt
>       Pages           : 26
>       Date            : 2011-09-20
>
>    A multi-interfaced node is connected to multiple networks, some of
>    which may be utilizing private DNS namespaces.  A node commonly
>    receives DNS server configuration information from all connected
>    networks.  Some of the DNS servers may have information about
>    namespaces other servers do not have.  When a multi-interfaced node
>    needs to utilize DNS, the node has to choose which of the servers to
>    contact to.  This document describes DHCPv4 and DHCPv6 option that
>    can be used to configure nodes with inform ation required to perform
>    informed DNS server selection decisions.
>
>
> A URL for this Internet-Draft is:
> http://www.ietf.org/internet-drafts/draft-ietf-mif-dns-server-selection-05.txt

--_bcee45fa-b601-421d-9227-642c3b85b5f8_-- From alexandru.petrescu@gmail.com Fri Sep 30 09:34: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 AD44C21F8B67 for ; Fri, 30 Sep 2011 09:34:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.437 X-Spam-Level: X-Spam-Status: No, score=-4.437 tagged_above=-999 required=5 tests=[AWL=1.812, 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 CtjzSau+Tkh6 for ; Fri, 30 Sep 2011 09:34:55 -0700 (PDT) Received: from sainfoin-out.extra.cea.fr (sainfoin-out.extra.cea.fr [132.167.192.144]) by ietfa.amsl.com (Postfix) with ESMTP id A113F21F8B5E for ; Fri, 30 Sep 2011 09:34:54 -0700 (PDT) Received: from pisaure.intra.cea.fr (pisaure.intra.cea.fr [132.166.88.21]) by sainfoin.extra.cea.fr (8.14.2/8.14.2/CEAnet-Internet-out-2.2) with ESMTP id p8UGblNQ015470 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Fri, 30 Sep 2011 18:37:47 +0200 Received: from muguet1.intra.cea.fr (muguet1.intra.cea.fr [132.166.192.6]) by pisaure.intra.cea.fr (8.14.4/8.14.4) with ESMTP id p8UGbkrw015104; Fri, 30 Sep 2011 18:37:46 +0200 (envelope-from alexandru.petrescu@gmail.com) Received: from [127.0.0.1] ([132.166.133.183]) by muguet1.intra.cea.fr (8.13.8/8.13.8/CEAnet-Intranet-out-1.1) with ESMTP id p8UGbham017551; Fri, 30 Sep 2011 18:37:46 +0200 Message-ID: <4E85F057.8060603@gmail.com> Date: Fri, 30 Sep 2011 18:37:43 +0200 From: Alexandru Petrescu User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:7.0) Gecko/20110922 Thunderbird/7.0 MIME-Version: 1.0 To: teemu.savolainen@nokia.com References: <3CF88B99A9ED504197498BC6F6F04B81040FBDA9@XMB-BGL-41E.cisco.com> <4E6E7A72.9030208@gmail.com> <4E6EAFC2.5060906@gmail.com> <4E6EDEA8.3080108@gmail.com> <4E6F825C.3080303@gmail.com> <3D0B3661-8A8F-4BB2-A8EF-25007BEAF66C@nominum.com> <4E6F923F.7090304@gmail.com> <7061CEB8-8084-41D5-B31E-9F8E3B6C7091@nominum.com> <4E6F9B91.7010503@gmail.com> <4E6FA64E.7020801@gmail.com> <82337D11-0A39-4A10-AA0E-1E81B09DBA4F@nominum.com> <4E6FACF6.5000007@viagenie.ca>, <4E6FC0AE.5000108@gmail.com> <916CE6CF87173740BC8A2CE4430969620257327E@008-AM1MPN1-032.mgdnok.nokia.com> <4E6FD930.7040401@gmail.com> <916CE6CF87173740BC8A2CE443096962025734A7@008-AM1MPN1-032.mgdnok.nokia.com> <4E7070B5.6080900@gmail.com> <916CE6CF87173740BC8A2CE44309696202573B89@008-AM1MPN1-032.mgdnok.nokia.com> In-Reply-To: <916CE6CF87173740BC8A2CE44309696202573B89@008-AM1MPN1-032.mgdnok.nokia.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Cc: mif@ietf.org Subject: Re: [mif] (long, 3GPP) Comments on draft-mouton-mif-dhcpv6-drlo-00 X-BeenThere: mif@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multiple Interface Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 30 Sep 2011 16:34:56 -0000 This is about text in document 23401-a50 V10.5.0 of 3GPP 2011-09, section 5.3.1.2.6. Le 14/09/2011 12:26, teemu.savolainen@nokia.com a 閏rit : >> In many places the term "default prefix" is used. For example like >> this: >>> IPv6 Prefix Delegation via DHCPv6 Optionally a single network >>> prefix shorter than the default /64 prefix may be assigned to a >>> PDN connection. In this case, the /64 default prefix used for >>> IPv6 stateless autoconfiguration will be allocated from this >>> network prefix >> >> This is difficult to understand because SLAAC has no "default >> prefix" (grep rfc4862). > > It refers to unique /64 prefix allocated for a PDN connection. Teemu, let me bring back this text again. "unique" is not the same as "default". Each one such word has a specific meaning. Each is implemented differently. >> 24.301-a30 says often GW allocates via RA like this: >>> The PDN GW allocates a globally unique /64 IPv6 prefix via >>> Router Advertisement to a given UE. >> >> But this is so difficult for me to understand because RA RFC text >> never says an RA "allocates" some prefix. This allocation action >> is typically a DHCP action, not RA. The RA simply advertises an >> allocation already done by DHCP or administrator or ospf. > > Maybe the terminology is not clearest, but it means /64 prefix is > advertised to the PDN connection. It is different topic then where > the PDN GW got the addresses (statically allocated pool or by DHCPv6 > or whatever means). > > The "allocate" text probably comes from the view that it is P-t-P > connection between UE and PDN GW and hence there is just single UE > that "gets" the whole /64 "allocated" for its use. I can hear the similar use of 'allocate' in PtP ppp rfc. But The use of the word "allocate" in this doc is ambiguous. There exist IETF docs SLAAC non-PPP methods which _do_ allocate prefixes, this makes think an MTC-inclined reader to confuse even further. The terminology in this spec should be clarified to say "advertized" instead of "allocated". The same with section's use of "assigned". >> In a number of other places the 3GPP spec is incoherent with >> respect to who is the "Requesting Router" - the UE or the PDN GW >> (at a moment the GW is a DHCP client requesting a prefix, at >> another moment it is the UE being a requesting router). For me it >> is not clear how a Requesting Router below another Requesting >> Router can work. > > In my understanding the PDN GW can use DHCPv6 Prefix Delegation to > get an address pool from where to "advertise" /64s for different UEs > PDN connections. An "address pool" (a set of distinct /128 addresses) is not the same as a "prefix". Prefix Delegation can not be used to obtain address pools, but prefixes. > Additionally, in rel-10, also UE connected to PDN GW can use DHCPv6 > Prefix Delegation to get prefixes for advertisement on local area > networks (such as "MiFi hotspot"). How? >> It is unclear to me why the 23401 3GPP spec says that "The UE acts >> as a "Requesting Router"" requesting a Prefix. An entire Prefix >> (in addition to the onlink prefixes) is useful only if that UE is >> a Mobile Router, giving addresses further to some LFNs. Otherwise >> it is not clear why do Prefix Delegation > to a >> UE Requesting Router. Yet the spec never says "Mobile Router". > > UE acts as requesting router in order to behave as a router. I > understand not using term Mobile Router there, as the UE does not > necessarily implement any "IP Mobility" solutions (e.g. DSMIP6). UE > just acts as a router. Ok that not implementing NEMO then not MR. But an UE which is a Router (DHC Requesting Router, forwards between 3g and wifi ifaces, etc.) should be called something more powerful than just "User Equipment". It's something that offers Internet access to other User Equipments. >> If it makes sense for this UE to actually be a MR, and to run >> DHCPv6-PD then it could make sense to use DHCPv6 for address and >> default route configuration as well, instead of DHCPv6+SLAAC - >> simply the number of messages is reduced, and configuration of >> addresses/routes/prefixes is centralizely managed. > > It could, but as of now it is not specified to be possible. Maybe better could be done. An implementer optimizing the amount of complexity on terminal would use just DHCPv6 (if available) for address/prefix/defaultroute, (not RA) - easier to administer in some cases. > 3GPP UE always uses SLAAC to number its cellular WAN interface > (unnumbered model is not supported), including getting default route > pointing to cellular interface. Well, in IPv4 some 3G+ implementations, the driver setting up the interface does not forcefully assign neither address nor default route on that in interface - it just tells them so some other smart middleware can. Recent ISC DHCPv6 Client implementations do the same on Ethernet: they don't forcefully assign addresses/prefixes/dr that are extracted from the received DHCP messages... they just tell them so other smart middleware can assign it. In a MIF device one would't want the network to forcefully impose where the default route should go. > After SLAAC, UE acting as router MAY use DHCPv6 PD to get prefixes > for advertisement in "southbound" local area networks. SLAAC could be used _only_ to do some things which DHCP doesn't: MTU, HopLimit, on-link or off/link prefix - that's about it. No need to do more than that when DHCP can (address, default route, prefix for further advertisement, dns, more). This makes it easier to control the assignment of prefixes and routes in central DHCP conf files in the network. > Because SLAAC is always used and UE gets its IPv6 default route that > way, there is currently no need to use DHCPv6 to specify default > routes. It is doubtful in a MIF terminal to have the network impose the default one way or another. It is good to have as much alternatives as possible for the default route: SLAAC, DHCP, more. > As always, things may change in the future and that's one reason why > I'm ok for defining default route option for DHCPv6. I agree with you. Section 5.3.1.2.6 of 3GPP doc 23401-a50 text which bothers: > Optionally a single network prefix shorter than the default /64 > prefix may be assigned to a PDN connection. Ok, so a /56 is assigned to a PDN connection. > In this case, the /64 default prefix used for IPv6 stateless > autoconfiguration will be allocated from this network prefix; Ok, so a /64 is extracted from that /56, and used by SLAAC, supposedly advertised to the PDN connection. But earlier, the _/56_ was 'assigned' to that PDN connection. Did the text really mean that the /56 was 'assigned' to a PDN connection? Or was it just preventive setting aside of a /56 for a PDN connection yet to materialize, in the same way as the 'provisioned' used later in the text? Better just use one. > the remaining address space from the network prefix can be delegated > to the PDN connection using prefix delegation Ok, it is about the remaining address space left after the /56 was extracted a /64. I believe that to be 254 other /64s or so. Does it mean that the UE may do DHCP Prefix Delegation to request these prefixes? If yes, then UE will not use them on the PDN connection, but on another connection (you name it 'southbound' elsewhere). In this sense this remaining address space is _not_ delegated to the PDN connection but to the UE to use on other connections. > after the default bearer establishment Again - what is 'default' in 'default bearer establishment' - is it 'default bearer' or 'default establishment'? In both cases I see it has no relationship with 'default router' nor 'default route'. > and IPv6 prefix allocation via IPv6 stateless address > autoconfiguration as defined in clause 5.3.1.2.2. IPv6 stateless address autoconfiguration does not do IPv6 prefix allocation. This sentence is purely wrong and should be corrected. > When PLMN based parameter configuration is used, the PDN GW provides > the requested IPv6 prefix from a locally provisioned pool. Is this 'provisioned' pool containing a set of prefixes or of addresses? Is that 'provisioned' word the same as the initial 'assigned' /56 above ("Optionally a single network prefix shorter than the default /64 prefix may be _assigned_ to a PDN connection"). > When external PDN based IPv6 prefix allocation is used, the PDN GW > obtains the prefix from the external PDN. [*] How does the PDN GW obtain the prefix from the external PDN? Is it by using DHCPv6 Prefix Delegation? I am asking because there exist no other way to automatically (no human intervention) request and obtain prefixes. I assume DHCPv6-PD is meant by the above. IF so it should say so. > Note: Allocation of IPv6 prefixes with flexible prefix length can > leverage e.g. local configuration on the PDN GW or interaction with > the AAA server. I do not quite understand this. In general, I agree a network should offer a router more than just a /64, in particular if that router had Ethernet interfaces (no PPP) and used SLAAC (not DHCP). Break any of these two conditions and one is free to use /64 to end user. E.g. use DHCP with Ethernet, or use SLAAC with PPP, or use DHCP with PPP - for each those there's no need to allocate shorter-than-/64 prefixes to UE-which-are-Routers. I also agree that local configuration is easier to do for operator if centralized conf files are used, with DHCP, rather than distributed files with RA. But 'IPv6 prefixes with flexible length' doesn't really mean much to me (no offence :-) SLAAC doesn't allocate prefixes, so this statement can only request DHCP. DHCP-PD already allocates prefixes with any length. I do not understand why this Note is there. > The address space provided is maintained as an IPv6 address space 'provided'? (not 'provisioned', not 'assigned') > pool available to the PDN connection for DHCPv6 IPv6 prefix requests ^^^^^^^^^^^^^^ This should rather be UE-Router, rather than 'PDN connection', because the PDN connection does not do any prefix request (the UE-Router does). Moreover, the prefixes delegated by DHCP this way are not used at all on that PDN connection. > with the exclusion of the IPv6 prefix that is allocated to the PDN > connection during default bearer establishment as defined in clause > 5.3.1.2.2. So, the /64 is 'allocated' to the PDN connection and the other 254 /64s are 'provided' to the same PDN connection? This is unclear. In implementation, the way these prefixes are 'assigned', 'requested', 'advertised' have very precise meanings, and they relate to the ways the routing tables are constructed (triplets of "prefix-nexthop-interface"). Rather use these terms from implementation if one wants to avoid confusion and be understandable. > The total IPv6 address space available for the PDN connection (UE > default bearer prefix 'default bearer prefix'? Earlier it was 'default bearer establishment'. So 'default' relates to 'default bearer', not 'default prefix'. But before that occurence, on the first phrase, it said 'default /64 prefix'! Overall we have: default bearer establishment default bearer prefix default /64 prefix None appears in RFCs I look at. > and UE PDN connection IPv6 address space pool) shall be possible to > aggregate into one IPv6 prefix that will represent all IPv6 addresses > that the UE may use. What does it mean to 'aggregate'? Earlier it said "Optionally a single network prefix shorter than the default /64 prefix may be assigned to a PDN connection [...] the /64 default prefix will be allocated from this network prefix; the remaining address space from the network prefix can be delegated" I believe this aggregation happens all the time, no need to request it with a "shall be possible". It is always automatically possible given the initial 'shorter prefix, remaining prefix'. Besides, I believe that if one tries to really understand that word 'aggregation' one may have surprises. For example, a UE-Router with two 'southbound' interfaces and one 3GPP interface may need to request two prefixes: one for each southbound interface. These two prefixes don't necessarily need to be 'aggregated' into each other (differ at the 4th leftmost bit!) and they don't even need to be aggregated with the prefix of the address of the 3GPP interface (differ at the 4th leftmost bit again). In one way, all distinct prefixes are aggregated into one another because they have the same 3 leftmost bit. In another way two distinct /64 prefixes can never be aggregated one into another because they differ at the leftmost 65th bit. > The UE uses DHCPv6 to request additional IPv6 prefixes (i.e. > prefixes in addition to the default prefix) Again - what is a 'default prefix'? It doesn't appear in relevant RFCs. > The UE acts as a "Requesting Router" [...] > The PDN GW acts as the DHCP server and fulfils the role of a > "Delegating Router" But could PDN GW act as a DHCP Relay as well? It is useful option for deployments to use a multiplicity of Relays (one per PDN GW?) and one central DHCP Server rather than a DHCP Server for each PDN GW. Besides, if we assume that PDN GW obtains its prefixes also using DHCPv6-PD (implied by the earlier 'PDN GW obtains the prefix from the external PDN'), is PDN GW be a Requesting Router as well? > The PDN GW delegates a prefix excluding the default prefix How does it 'exclude'? draft pd-exclude doesn't tell how. There are many ways to 'exclude' especially when it's not told how. Excluding a /64 from a /48 results in several prefix_es_ and hence the above statement is wrong to say PDN GW delegates _a_ prefix. Given 2001:db8:1:1::/64 and 2001:db8:1::/48, the 'exclusion' of the former from the latter may result in: 2001:db8:1:0000::/64 2001:db8:1:0002::/64 2001:db8:1:0003::/64 ... 2001:db8:1:ffff::/64 or it may result in: 2001:db8:1::/63 if we ignore 0. > Prefix exclusion procedures shall follow > draft-ietf-dhc-pd-exclude-00 Sorry it doesn't tell to my reading. That draft only tells: > the requesting router has earlier been assigned a > 2001:db8:dead:beef::/64 prefix by the delegating router, and the > delegated prefix in the OPTION_IAPREFIX is 2001:db8:dead:bee0::/59. > In this case, 2001:db8: dead:beef::/64 is a valid prefix to be used > in the OPTION_PD_EXCLUDE option. Certainly yes, 2001:db8:dead:beef::/64 is a valid prefix to be used in the EXCLUDE option, because 'the RR has earlier been assigned a 2001:db8:dead:beef::/64' - it's said right above. This is always true. But, what an implementer is interested in is: what prefixes (or single prefix?) result when 'excluding' 2001:db8:dead:beef::/64 from 2001:db8:dead:bee0::/59? This draft doesn't tell. Friendly yours, Alex > > Best regards, > > Teemu