From internet-drafts@ietf.org Tue Oct 1 19:31:11 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 319AD21E826C; Tue, 1 Oct 2013 19:31:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.364 X-Spam-Level: X-Spam-Status: No, score=-102.364 tagged_above=-999 required=5 tests=[AWL=0.236, 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 9lugYvt9rHo8; Tue, 1 Oct 2013 19:30:53 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 3263121E8274; Tue, 1 Oct 2013 19:30:47 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 4.72.p1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20131002023047.20702.67016.idtracker@ietfa.amsl.com> Date: Tue, 01 Oct 2013 19:30:47 -0700 Cc: v6ops@ietf.org Subject: [v6ops] I-D Action: draft-ietf-v6ops-nat64-experience-03.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 02 Oct 2013 02:31:11 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the IPv6 Operations Working Group of the IETF. Title : NAT64 Operational Experiences Author(s) : Gang Chen Zhen Cao Chongfeng Xie David Binet Filename : draft-ietf-v6ops-nat64-experience-03.txt Pages : 20 Date : 2013-10-01 Abstract: This document summarizes NAT64 function deployment scenarios and operational experience. Both NAT64 Carrier Grade NAT (NAT64-CGN) and NAT64 server Front End (NAT64-FE) are considered in this document. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-v6ops-nat64-experience There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-v6ops-nat64-experience-03 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-v6ops-nat64-experience-03 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From phdgang@gmail.com Tue Oct 1 19:35:52 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F11F421E8280 for ; Tue, 1 Oct 2013 19:35:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_13=0.6, 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 kX0rWonV3kWN for ; Tue, 1 Oct 2013 19:35:45 -0700 (PDT) Received: from mail-qe0-x236.google.com (mail-qe0-x236.google.com [IPv6:2607:f8b0:400d:c02::236]) by ietfa.amsl.com (Postfix) with ESMTP id D34E921E8268 for ; Tue, 1 Oct 2013 19:35:44 -0700 (PDT) Received: by mail-qe0-f54.google.com with SMTP id cy11so137317qeb.13 for ; Tue, 01 Oct 2013 19:35:44 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:date:message-id:subject:from:to:content-type :content-transfer-encoding; bh=BJag9Vp2dSaxvR+jN0LZmqdU5DRIFCd2k50Q7TVwioY=; b=UGYzuhtnRKoJTIh66tDsotyqoomklVQpA/OCzB+jC7d82xmaFh/XwQcxm4A2YvejmO yR8ehpzijN9B2++12+IQDUkhk8eEkeDBw3W5/G3ZJXZlOsb2tQwWHmXeppKIE7efDNPS wqOusPfPouLgnLfWNcgFYXHFCy6yNZrB7sss6sGw7HjAxGfHkOJPyaCYPUhDHT3MKsc2 jknG9diU8tjSUXReTzd8O5ZuwePoeMwSsB4C9I0B81ZXSO3tT7pLDQ2g+noXQuFEb+RH S3LKaRI7Z4u8Nv1wrsMTeZWnSztGCSbOXXqG5InEYOQ62wD7UEObcdwM9qCPIxfezK/4 w2oA== MIME-Version: 1.0 X-Received: by 10.49.1.9 with SMTP id 9mr39371804qei.51.1380681344312; Tue, 01 Oct 2013 19:35:44 -0700 (PDT) Received: by 10.224.184.68 with HTTP; Tue, 1 Oct 2013 19:35:44 -0700 (PDT) Date: Wed, 2 Oct 2013 10:35:44 +0800 Message-ID: From: GangChen To: v6ops Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Subject: [v6ops] new version is available: draft-ietf-v6ops-nat64-experience-03.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 02 Oct 2013 02:35:52 -0000 Wg, We have just submitted the new version to address the comments during the W= GLC. The main changes are 1) Add the ULAs statement to feedback Lorenzo's comments 2) Add the description of bulk port allocation in Section 5.1 suggested by Mikael 3) Add the experience description for geo-location service in Section 5.2 according to Dan Wing and Mikael comments 4) Add sub-levels in Section 3.1 and improve the description in section 3.1.2 to echo Sheng's comments 5) Polish the entire draft according to the suggestions from IETF#87=93Document Language Editing Session=94 Please kindly check if all comments are addressed in this version. Many thanks Gang 2013/10/2, internet-drafts@ietf.org : > > A New Internet-Draft is available from the on-line Internet-Drafts > directories. > This draft is a work item of the IPv6 Operations Working Group of the > IETF. > > Title : NAT64 Operational Experiences > Author(s) : Gang Chen > Zhen Cao > Chongfeng Xie > David Binet > Filename : draft-ietf-v6ops-nat64-experience-03.txt > Pages : 20 > Date : 2013-10-01 > > Abstract: > This document summarizes NAT64 function deployment scenarios and > operational experience. Both NAT64 Carrier Grade NAT (NAT64-CGN) and > NAT64 server Front End (NAT64-FE) are considered in this document. > > > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-ietf-v6ops-nat64-experience > > There's also a htmlized version available at: > http://tools.ietf.org/html/draft-ietf-v6ops-nat64-experience-03 > > A diff from the previous version is available at: > http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-v6ops-nat64-experience-03 > > > Please note that it may take a couple of minutes from the time of > submission > until the htmlized version and diff are available at tools.ietf.org. > > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ > > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops > From fred@cisco.com Wed Oct 2 09:31:22 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A99F921F9E3F for ; Wed, 2 Oct 2013 09:31:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.599 X-Spam-Level: X-Spam-Status: No, score=-110.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, 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 zZgT5+8+2Bfs for ; Wed, 2 Oct 2013 09:31:11 -0700 (PDT) Received: from rcdn-iport-5.cisco.com (rcdn-iport-5.cisco.com [173.37.86.76]) by ietfa.amsl.com (Postfix) with ESMTP id 141AA21F9A7E for ; Wed, 2 Oct 2013 09:29:38 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=840; q=dns/txt; s=iport; t=1380731378; x=1381940978; h=from:to:subject:date:message-id:mime-version; bh=0y5XYuvCZnA4F22o+mmUXdjyzUq6RTLR9edxmb8w+wU=; b=YM3hnBL/CCX6+YnTUf1002FB/N4b7tS+F2XrG79PKitfiIQKxCZiBDWb fIgy24wz+KJAABbBVfoLIgKW3+EKP4wCJ2wNGo7u1r4X/qGX5G+IquuBv YDW8ThzjAruEVmlgfPvzM3Yuf6oznM/aLoqhcsAXpCvf9WpVAEgJUKOMm w=; X-Files: signature.asc : 195 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgIFAJtJTFKtJV2a/2dsb2JhbABZgwc4UsEWgRgWdIInAQSBCwEqVicEGwaHeAybVKE5BI8gg1eBBAOQKIEwmCiDJIIq X-IronPort-AV: E=Sophos;i="4.90,1019,1371081600"; d="asc'?scan'208";a="267198987" Received: from rcdn-core-3.cisco.com ([173.37.93.154]) by rcdn-iport-5.cisco.com with ESMTP; 02 Oct 2013 16:29:37 +0000 Received: from xhc-rcd-x15.cisco.com (xhc-rcd-x15.cisco.com [173.37.183.89]) by rcdn-core-3.cisco.com (8.14.5/8.14.5) with ESMTP id r92GTblZ013239 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for ; Wed, 2 Oct 2013 16:29:37 GMT Received: from xmb-rcd-x09.cisco.com ([169.254.9.23]) by xhc-rcd-x15.cisco.com ([173.37.183.89]) with mapi id 14.02.0318.004; Wed, 2 Oct 2013 11:29:37 -0500 From: "Fred Baker (fred)" To: " WG" Thread-Topic: Packet size matters Thread-Index: AQHOv4yVrYm2uUuoYkyWyDaKSMcKmg== Date: Wed, 2 Oct 2013 16:29:37 +0000 Message-ID: <8C48B86A895913448548E6D15DA7553BA50CBA@xmb-rcd-x09.cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-originating-ip: [10.19.64.115] Content-Type: multipart/signed; boundary="Apple-Mail=_6F52E630-62F1-4B3B-9606-FFFB6F5A5F01"; protocol="application/pgp-signature"; micalg=pgp-sha1 MIME-Version: 1.0 Subject: [v6ops] Packet size matters X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 02 Oct 2013 16:31:22 -0000 --Apple-Mail=_6F52E630-62F1-4B3B-9606-FFFB6F5A5F01 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii An article was posted this morning that is relevant to the fragmentation = discussion https://labs.ripe.net/Members/emileaben/ripe-atlas-packet-size-matters --Apple-Mail=_6F52E630-62F1-4B3B-9606-FFFB6F5A5F01 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="signature.asc" Content-Type: application/pgp-signature; name="signature.asc" Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- Comment: GPGTools - http://gpgtools.org iD8DBQFSTEowbjEdbHIsm0MRApacAJ9lzVF2PIB8AHhSnFyFlN2KLlienACfdyWf kZsvr0Q4FJxSyNiA11RXvFY= =hEbj -----END PGP SIGNATURE----- --Apple-Mail=_6F52E630-62F1-4B3B-9606-FFFB6F5A5F01-- From fred@cisco.com Wed Oct 2 12:42:10 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2C1B621F9634 for ; Wed, 2 Oct 2013 12:42:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.599 X-Spam-Level: X-Spam-Status: No, score=-110.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, 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 Sl1rX28HRzA2 for ; Wed, 2 Oct 2013 12:41:58 -0700 (PDT) Received: from rcdn-iport-3.cisco.com (rcdn-iport-3.cisco.com [173.37.86.74]) by ietfa.amsl.com (Postfix) with ESMTP id 8161321F9697 for ; Wed, 2 Oct 2013 12:32:42 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1063; q=dns/txt; s=iport; t=1380742362; x=1381951962; h=from:to:subject:date:message-id:mime-version; bh=x7hRozEMltaxJ6E4oIUHx9Z2t+Z2bikXdcPJJX1TXD0=; b=PsZs61keFY+DkiPT9nDDlI+tEtdNw11CALb+So3bsjg6bqiAveAM4lsh w8l/K+4fap55Ax0dtZGCDw0TWA2oY5DvQyaegHoz/CfDnra7A/04S841E tdZswwDhYHEn+GdTmHODrvoTbHv8s+enY0Te064WnSzjcmEtmR3y/TQb0 A=; X-Files: signature.asc : 195 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgEFAAd0TFKtJV2d/2dsb2JhbABZgweBCsEpgRgWdIInAQSBCwEqVicEGwaHeJwvoTqPIINXgQQDkCiBMJgogySCKg X-IronPort-AV: E=Sophos;i="4.90,1020,1371081600"; d="asc'?scan'208";a="267312390" Received: from rcdn-core-6.cisco.com ([173.37.93.157]) by rcdn-iport-3.cisco.com with ESMTP; 02 Oct 2013 19:32:42 +0000 Received: from xhc-rcd-x14.cisco.com (xhc-rcd-x14.cisco.com [173.37.183.88]) by rcdn-core-6.cisco.com (8.14.5/8.14.5) with ESMTP id r92JWfjC012936 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for ; Wed, 2 Oct 2013 19:32:41 GMT Received: from xmb-rcd-x09.cisco.com ([169.254.9.23]) by xhc-rcd-x14.cisco.com ([173.37.183.88]) with mapi id 14.02.0318.004; Wed, 2 Oct 2013 14:32:41 -0500 From: "Fred Baker (fred)" To: " WG" Thread-Topic: Deadlines Thread-Index: AQHOv6YpHhxI640Ve0aT8W3tOuAB1g== Date: Wed, 2 Oct 2013 19:32:41 +0000 Message-ID: <8C48B86A895913448548E6D15DA7553BA511CA@xmb-rcd-x09.cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-originating-ip: [10.19.64.115] Content-Type: multipart/signed; boundary="Apple-Mail=_926A2E42-12E1-4FA0-BD59-83CEB99CF65A"; protocol="application/pgp-signature"; micalg=pgp-sha1 MIME-Version: 1.0 Subject: [v6ops] Deadlines X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 02 Oct 2013 19:42:10 -0000 --Apple-Mail=_926A2E42-12E1-4FA0-BD59-83CEB99CF65A Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii A word to the wise: The -00 draft cutoff is scheduled for 21 October, and the update cutoff = is 28 October. As usual, we will be scheduling air time for drafts that = are new or have been updated since the July meeting, and which have = sparked supportive interest on the list. If you have something you would = like to discuss four weeks hence, the time to post it is "now". --Apple-Mail=_926A2E42-12E1-4FA0-BD59-83CEB99CF65A Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="signature.asc" Content-Type: application/pgp-signature; name="signature.asc" Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- Comment: GPGTools - http://gpgtools.org iD8DBQFSTHUdbjEdbHIsm0MRAjlGAJ4u3H8RKJwwPKfoWg1DFxU8V2fxawCg6zGH /CNpKAOTRtgzF5ZXtNnCFAg= =4viv -----END PGP SIGNATURE----- --Apple-Mail=_926A2E42-12E1-4FA0-BD59-83CEB99CF65A-- From nalini.elkins@insidethestack.com Fri Oct 4 06:21:15 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A18FE21F9DC9 for ; Fri, 4 Oct 2013 06:21:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.298 X-Spam-Level: X-Spam-Status: No, score=-1.298 tagged_above=-999 required=5 tests=[AWL=1.300, 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 lN15jfU8SrEX for ; Fri, 4 Oct 2013 06:21:15 -0700 (PDT) Received: from nm8-vm5.access.bullet.mail.gq1.yahoo.com (nm8-vm5.access.bullet.mail.gq1.yahoo.com [216.39.63.126]) by ietfa.amsl.com (Postfix) with ESMTP id 3CA8C21F9DE1 for ; Fri, 4 Oct 2013 06:10:29 -0700 (PDT) Received: from [216.39.60.174] by nm8.access.bullet.mail.gq1.yahoo.com with NNFMP; 04 Oct 2013 13:10:27 -0000 Received: from [216.39.60.239] by tm10.access.bullet.mail.gq1.yahoo.com with NNFMP; 04 Oct 2013 13:10:27 -0000 Received: from [127.0.0.1] by omp1010.access.mail.gq1.yahoo.com with NNFMP; 04 Oct 2013 13:10:27 -0000 X-Yahoo-Newman-Property: ymail-3 X-Yahoo-Newman-Id: 812384.74728.bm@omp1010.access.mail.gq1.yahoo.com Received: (qmail 95265 invoked by uid 60001); 4 Oct 2013 13:10:27 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s1024; t=1380892227; bh=fGwGyFKWNrkAC9bp4LoU06ni1pokIRQ3q2sC8GwQR2Q=; h=X-YMail-OSG:Received:X-Rocket-MIMEInfo:X-Mailer:References:Message-ID:Date:From:Reply-To:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type; b=bukK02xBhaw21ncpciCQV98nHYRJo0kzW/SG5ZcTu8dtizqn1RdgAgT9eGUJ/2FrmAUkYqE2MdEtgkItW+f91V5oGwNXBwvhHUYsRIV42Dd/Fz0Rfe3PWiT5fb0iH3j3kIPG3w77pOV5KF9XXjKayAAyzfPVUHnq5FaRvgrONWs= X-YMail-OSG: BU4VMsYVM1l.PM9E_dXxBjdCBiUriVFJuo8ad5LfRLssNiA FoM9I2aTaZnHhizWEAcHn9mXRDr5GiP_Xz9bmp8Uw5ngnNYbd7O4Gk7clo7s ecCZrUA4a.ZIGcVjAYuVFU_e2KHX8ZZgYNNf8DXqCg_FqiyUbiRckOdlXr5w H2qOZA7Gtce3rfpWvFAEaRzAYwQJdibTqZXox6keqolHQ5VNe9TeMRogjD5M 3AlvmvlEw_n6826WVFNNYZEB5Z6IcDPe7acO_79clriLfl0g0K.qqtd1nyJv kLjPra0cj3mPJJb9_Jl8GiL7U8WSgoOSUdV3Fi_HuQnWEy7XUuc5_KCDWNMd RCHMS8bUXJHY3NvjRnOXqp00Y3iJIiXfJrlDhLeBr6SD3fHeCFM1FyyWYUCZ 1nw9uYmMkNuV.ywtEdepH3w2fQcGyF7UyzGrmUOs62TSWlDOY.iQvPyb0qij c32iP.7wS1EpbbqtUI46ktCh32oz8eEYO6vU0iemxvqBHc0UTTTL7d0nIcN3 SlTHAgV2bEnviX5Wk9tT5k8wpLyaDqvUbZ3i3tEnTiagVWA.uh9S0FLs19WP R0Vj6dIARxZiofqiKdAxsb0m6MUGYy1_zPnN4nP9g.SCirZ3obB06UoODshy jDBBGkxPQWiDHZgU.KF1_k7xbUep5nvXN0vSlk5YtzlYoZT8sAuwg22OfTi4 fFDe_dagEzAAUM07JuJk.eKCWEj_hDNVAYeeuRaSGiBXt Received: from [24.130.37.147] by web2805.biz.mail.ne1.yahoo.com via HTTP; Fri, 04 Oct 2013 06:10:27 PDT X-Rocket-MIMEInfo: 002.001, CgpXZSBoYXZlIHN1Ym1pdHRlZCBhIG51bWJlciBvZiBkcmFmdHMuIMKgU29tZSBhcmUgbmV3IGFuZCBzb21lIGFyZSB1cGRhdGVzIHRvIG91ciBleGlzdGluZyBQRE0gcHJvcG9zYWwuIMKgV2Ugd291bGQgYXBwcmVjaWF0ZSBhbnkgY29tbWVudHMsIHF1ZXN0aW9ucywgYW5kIGNvcnJlY3Rpb25zIGZyb20gdGhlIGxpc3RzLgoKClRoZSBuZXcgb25lcyBhcmU6CgoxLiDCoEluIElQUE06CgpodHRwOi8vd3d3LmlldGYub3JnL2ludGVybmV0LWRyYWZ0cy9kcmFmdC1lbGtpbnMtaXBwbS1wZG0tbWV0cmljcy0wMC4BMAEBAQE- X-Mailer: YahooMailWebService/0.8.160.587 References: <20131004030407.30291.83858.idtracker@ietfa.amsl.com> Message-ID: <1380892227.93952.YahooMailNeo@web2805.biz.mail.ne1.yahoo.com> Date: Fri, 4 Oct 2013 06:10:27 -0700 (PDT) From: Nalini Elkins To: "WG \(v6ops@ietf.org\)" , 6man WG , "ippm@ietf.org" In-Reply-To: <20131004030407.30291.83858.idtracker@ietfa.amsl.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="1619178251-585868665-1380892227=:93952" Cc: Sigfrido Perdomo Subject: [v6ops] Fw: New Version Notification for draft-elkins-ippm-pdm-metrics-00.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: Nalini Elkins List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 Oct 2013 13:21:15 -0000 --1619178251-585868665-1380892227=:93952 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable =0A=0AWe have submitted a number of drafts. =A0Some are new and some are up= dates to our existing PDM proposal. =A0We would appreciate any comments, qu= estions, and corrections from the lists.=0A=0A=0AThe new ones are:=0A=0A1. = =A0In IPPM:=0A=0Ahttp://www.ietf.org/internet-drafts/draft-elkins-ippm-pdm-= metrics-00.txt=0A=0AThis describes the base and derived metrics which can b= e obtained from the IPv6 PDM DO Extension Header.=0A=0A=0A2. =A0In TicToc:= =0A=0Ahttp://www.ietf.org/internet-drafts/draft-ackermann-tictoc-pdm-ntp-us= age-00.txt=0A=0A=0AThis describes how NTP may be implemented to support PDM= .=0A=0A=0AThe updates are as follows=0A=0A1. =A0In=A06man:=0A=0Ahttp://www.= ietf.org/internet-drafts/draft-elkins-ippm-pdm-metrics-00.txt=0A=0A=0AThis = is the layout of the PDM DO header.=0A=0A=0A2. =A0In v6ops:=0A=0Ahttp://www= .ietf.org/internet-drafts/draft-elkins-v6ops-ipv6-packet-sequence-needed-01= .txt=0A=0A=0Ahttp://www.ietf.org/internet-drafts/draft-elkins-v6ops-ipv6-pd= m-recommended-usage-01.txt=0A=0A=0Ahttp://www.ietf.org/internet-drafts/draf= t-elkins-v6ops-ipv6-end-to-end-rt-needed-01.txt=0A=0A=0AThese are=A0backgro= und for the proposal.=0A=0A=A0=0AThanks,=0A=0ANalini Elkins=0AInside Produc= ts, Inc.=0A(831) 659-8360=0Awww.insidethestack.com=0A=0A=0A----- Forwarded = Message -----=0AFrom: "internet-drafts@ietf.org" = =0ATo: Nalini Elkins ; William Jouris =0ASent: Thursday, October 3, 2013 8:04 PM=0A= Subject: New Version Notification for draft-elkins-ippm-pdm-metrics-00.txt= =0A =0A=0A=0AA new version of I-D, draft-elkins-ippm-pdm-metrics-00.txt=0Ah= as been successfully submitted by Nalini Elkins and posted to the=0AIETF re= pository.=0A=0AFilename:=A0=A0=A0 draft-elkins-ippm-pdm-metrics=0ARevision= :=A0=A0=A0 00=0ATitle:=A0=A0=A0 =A0=A0=A0 IPPM Considerations for the IPv= 6 PDM Extension Header=0ACreation date:=A0=A0=A0 2013-10-03=0AGroup:=A0=A0= =A0 =A0=A0=A0 Individual Submission=0ANumber of pages: 14=0AURL:=A0 =A0 = =A0 =A0 =A0 =A0 http://www.ietf.org/internet-drafts/draft-elkins-ippm-pdm-= metrics-00.txt=0AStatus:=A0 =A0 =A0 =A0 =A0 http://datatracker.ietf.org/doc= /draft-elkins-ippm-pdm-metrics=0AHtmlized:=A0 =A0 =A0 =A0 http://tools.ietf= .org/html/draft-elkins-ippm-pdm-metrics-00=0A=0A=0AAbstract:=0A=A0 To diag= nose performance and connectivity problems, metrics on real=0A=A0 (non-syn= thetic) transmission are critical for timely end-to-end=0A=A0 problem reso= lution. Such diagnostics may be real-time or after the=0A=A0 fact, but mus= t not impact an operational production network. These=0A=A0 metrics are de= fined in the IPv6 Performance and Diagnostic Metrics=0A=A0 Destination Opt= ion (PDM). The base metrics are: packet sequence=0A=A0 number and packet t= imestamp. Other metrics may be derived from these=0A=A0 for use in diagnos= tics.=A0 This document specifies such metrics, their=0A=A0 calculation, an= d usage.=0A=0A=0A=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 = =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0= =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =0A=0A=0APlease note that it may take a co= uple of minutes from the time of submission=0Auntil the htmlized version an= d diff are available at tools.ietf.org.=0A=0AThe IETF Secretariat --1619178251-585868665-1380892227=:93952 Content-Type: text/html; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable

We hav= e submitted a number of drafts.  Some are new and some are updates to = our existing PDM proposal.  We would appreciate any comments, question= s, and corrections from the lists.


<= /span>
The new ones are:

1.  In= IPPM:

http://www.ietf.org/internet-draf= ts/draft-elkins-ippm-pdm-metrics-00.txt

This describes the base and derived metrics which can be obtained from = the IPv6 PDM DO Extension Header.


2.  In TicToc:

http://www.ietf.org/in= ternet-drafts/draft-ackermann-tictoc-pdm-ntp-usage-00.txt
<= div style=3D"background-color: transparent; color: rgb(0, 0, 0); font-size:= 16px; font-family: arial, helvetica, sans-serif; font-style: normal;">
This describes how NTP may be implemented to support = PDM.


T= he updates are as follows

1.  In 6man:

http://ww= w.ietf.org/internet-drafts/draft-elkins-ippm-pdm-metrics-00.txt
<= /div>

This is the layout of the PDM DO header.


2.  In v6ops:

http://www.ietf.org/int= ernet-drafts/draft-elkins-v6ops-ipv6-packet-sequence-needed-01.txt

http://www.ietf.org/internet-drafts/draft-elkins-v6ops-ipv6-pdm= -recommended-usage-01.txt
=
http://www.ietf.org/internet-drafts/dra= ft-elkins-v6ops-ipv6-end-to-end-rt-needed-01.txt

These = are background for the = proposal.

 
Thanks,

=
= Nalini Elkins
Inside Products, Inc.
(831) 659-8360
www.insidethest= ack.com

----- Forwarded M= essage -----
From: "internet-drafts@ietf.org" <internet-draft= s@ietf.org>
To: Nal= ini Elkins <nalini.elkins@insidethestack.com>; William Jouris <bill.jouris@i= nsidethestack.com>
Sent: Thursday, October 3, 2013 8:04 PM
Subject: New Version Notification for draft-elkins-ippm-= pdm-metrics-00.txt

= =0A
A new version of I-D, draft-elkins-ippm-pdm-metrics-00.txt
has be= en successfully submitted by Nalini Elkins and posted to the
IETF reposi= tory.

Filename:    draft-elkins-ippm-pdm-metrics
= Revision:    00
Title:      &nb= sp; IPPM Considerations for the IPv6 PDM Extension Header
Creation date= :    2013-10-03
Group:      &nb= sp; Individual Submission
Number of pages: 14
URL:    &nbs= p;       http://www.ietf.org/internet-drafts/draft-elkins-i= ppm-pdm-metrics-00.txt
Status:          http://= datatracker.ietf.org/doc/draft-elkins-ippm-pdm-metrics
Htmlized:  &= nbsp;     http://tools.ietf.org/html/draft-elkins-ippm-pdm-metric= s-00


Abstract:
  To diagnose performance and connectivi= ty problems, metrics on real
  (non-synthetic) transmission are critical for timely end-to-end
  problem resolution. Such dia= gnostics may be real-time or after the
  fact, but must not impact= an operational production network. These
  metrics are defined in= the IPv6 Performance and Diagnostic Metrics
  Destination Option = (PDM). The base metrics are: packet sequence
  number and packet t= imestamp. Other metrics may be derived from these
  for use in dia= gnostics.  This document specifies such metrics, their
  calc= ulation, and usage.


            &n= bsp;                     =                      = ;                     &nb= sp;    


Please note that it may take a couple of minu= tes from the time of submission
until the htmlized version and diff are available at tools.ietf.org.

The IETF Secretariat



--1619178251-585868665-1380892227=:93952-- From fred@cisco.com Fri Oct 4 17:09:38 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BD4DC21F9DD6 for ; Fri, 4 Oct 2013 17:09:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.599 X-Spam-Level: X-Spam-Status: No, score=-110.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, 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 dy6CShMi9iSp for ; Fri, 4 Oct 2013 17:09:33 -0700 (PDT) Received: from rcdn-iport-7.cisco.com (rcdn-iport-7.cisco.com [173.37.86.78]) by ietfa.amsl.com (Postfix) with ESMTP id 9C7CA21F9D62 for ; Fri, 4 Oct 2013 17:09:33 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=6246; q=dns/txt; s=iport; t=1380931773; x=1382141373; h=from:to:subject:date:message-id:references:mime-version; bh=2gKEuhpnMiEKf36uccWcK2uI2L6oocvCYuET+eOGDwQ=; b=ATM5PB0Tem8kK/wrFw6dQPDlf72yKfopgxi62aoRDrzSDK785z91ZdcD lGdIVLFqnwAg73400Z6w07nWDJCl8y/hmlgy9+JIiftoPuVywjAMZQAat CPaAHiw+7PFqM03uzMEbAdfj2qNO64rMZqMloOdRe0cxrIn5pWe4ResNo 4=; X-Files: signature.asc : 195 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AjgFAGxYT1KtJV2Y/2dsb2JhbABZgwc4UsEhgRYWdIIlAQEBAwEdTgIRCwIBGQMBAgsLGTIUBwIIAgQTCAYGh2wGDLw/jgiBGAYaGgQEgxWBBAOQKIEwgkyFDJBQgySBcTk X-IronPort-AV: E=Sophos;i="4.90,1036,1371081600"; d="asc'?scan'208";a="268325003" Received: from rcdn-core-1.cisco.com ([173.37.93.152]) by rcdn-iport-7.cisco.com with ESMTP; 05 Oct 2013 00:09:15 +0000 Received: from xhc-aln-x07.cisco.com (xhc-aln-x07.cisco.com [173.36.12.81]) by rcdn-core-1.cisco.com (8.14.5/8.14.5) with ESMTP id r9509FZE002887 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for ; Sat, 5 Oct 2013 00:09:15 GMT Received: from xmb-rcd-x09.cisco.com ([169.254.9.23]) by xhc-aln-x07.cisco.com ([173.36.12.81]) with mapi id 14.02.0318.004; Fri, 4 Oct 2013 19:09:15 -0500 From: "Fred Baker (fred)" To: " WG" Thread-Topic: NOMCOM 2013 - Second Call for Nominations - two weeks left Thread-Index: AQHOwSe3sw9PfbKehkCwMzVD/LkIIA== Date: Sat, 5 Oct 2013 00:09:14 +0000 Message-ID: <8C48B86A895913448548E6D15DA7553BA5AAE8@xmb-rcd-x09.cisco.com> References: <20131004173149.22991.14931.idtracker@ietfa.amsl.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-originating-ip: [10.19.64.115] Content-Type: multipart/signed; boundary="Apple-Mail=_A5558725-5888-458A-8449-CB1BAFB071CF"; protocol="application/pgp-signature"; micalg=pgp-sha1 MIME-Version: 1.0 Subject: [v6ops] Fwd: NOMCOM 2013 - Second Call for Nominations - two weeks left X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 05 Oct 2013 00:09:38 -0000 --Apple-Mail=_A5558725-5888-458A-8449-CB1BAFB071CF Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii If you have any suggestions, now would be a great time to put them = forward. Begin forwarded message: > From: NomCom Chair 2013 > Subject: NOMCOM 2013 - Second Call for Nominations - two weeks left > Date: October 4, 2013 10:31:49 AM PDT > To: IETF Announcement List > Cc: IETF Discuss List > Reply-To: , , = , <"2013 >=20 > Nominations for the IESG, IAB, and IAOC are due to the Nomcom by = Friday, 18 October, 2013. >=20 > Is there someone you work with at IETF who has leadership potential = and a growing track record? Please read the Nomcom call for nominations = and consider nominating her or him. Or several folks! Deadline for = nominations is October 18. Nominate soon to give your nominee(s) plenty = time to fill in the questionnaire. Information about the desired = expertise for positions is here:=20 > https://datatracker.ietf.org/nomcom/2013/expertise >=20 > Lots more, including which positions are open, how to make a = nomination, and how to=20 > send us your feedback on the desired expertise, follows. >=20 > IETFers, let's hear from you! Make nominations, accept nominations! >=20 > If you have any questions about the process, feel free to get in touch = with me. >=20 > Best regards, >=20 > Allison for the Nomcom >=20 > Allison Mankin=20 > Nomcom Chair 2013-14 >=20 > ----- The Info You Need for Nominating ----- >=20 > The 2013-14 Nominating Committee (Nomcom) is seeking nominations > from now until October 18, 2013. The open positions being considered > by this year's Nomcom can be found later in this section, and also on > this year's Nomcom website:=20 >=20 > https://datatracker.ietf.org/nomcom/2013/ >=20 > Nominations may be made by selecting the Nominate link at the top of > the Nomcom 2013 home page, or by visiting the following URL:=20 >=20 > https://datatracker.ietf.org/nomcom/2013/nominate/ >=20 > Note that nominations made using the web tool require an ietf.org=20 > datatracker account. You can create a datatracker ietf.org account=20 > if you don't have one already by visiting the following URL: >=20 > https://datatracker.ietf.org/accounts/create/ >=20 > Nominations may also be made by email to nomcom13 at ietf.org. > If you nominate by email, please include the word "Nominate" in the = Subject > and indicate in the email who is being nominated, their email address = (to > confirm acceptance of the nomination), and the position for which you > are making the nomination. If you use email, please use a separate = email for > each person you nominate, and for each position (if you are nominating = one > person for multiple positions). >=20 > Self-nomination is welcome! No need to be shy. >=20 > Nomcom 2013-14 will follow the policy for "Open Disclosure of Willing > Nominees" described in RFC 5680. As stated in RFC 5680: "The list of > nominees willing to be considered for positions under review in the > current Nomcom cycle is not confidential". Willing nominees for each > position will be listed in a publicly accessible way - anyone with a > datatracker account may access the lists. In all other ways, the=20 > confidentiality requirements of RFC 3777/BCP10 remain in effect. All > feedback and all Nomcom deliberations will remain confidential and = will > not be disclosed. =20 >=20 > In order to ensure time to collect sufficient community feedback about > each of the willing nominees, nominations must be received by the=20 > Nomcom on or before October 18, 2013. Please submit your nominations =20= > as early as possible for the sake of your nominees, as we've set the=20= > questionnaire submission deadline for October 25, 2013. >=20 > The list of people and posts whose terms end with the March 2014 IETF = meeting,=20 > and thus the positions for which we are accepting nominations: =20 >=20 > IAOC > Chris Griffiths >=20 > IAB > Bernard Aboba > Marc Blanchet > Ross Callon > Eliot Lear > Hannes Tschofenig >=20 > IESG > Barry Leiba (Applications) > Brian Haberman (Internet) > Benoit Claise (Operations and Management) > Gonzalo Camarillo (RAI) > Stewart Bryant (Routing) > Sean Turner (Security) > Martin Stiemerling (Transport) >=20 > Please be resourceful in identifying possible candidates for these > positions, as developing our talent is a very crucial requirement for > the IETF. Also, please give serious consideration to accepting = nominations > you receive. =20 >=20 > The summaries of the desired expertise for the positions, developed by = the=20 > respective bodies, are found at: >=20 > https://datatracker.ietf.org/nomcom/2013/expertise/ >=20 > In addition to nominations, the Nomcom seeks community input on=20 > the positions themselves. We need and welcome the community's=20 > views and input on the jobs within each organization. If you=20 > have ideas on the positions' responsibilities (more, less,=20 > different), please let us know. You can send us email about this to > nomcom13 at ietf.org, and we will use this feedback actively. >=20 > Thank you for your help in nominating a great pool of strong and = interesting > nominees! >=20 >=20 >=20 ----------------------------------- "We are learning to do a great many clever things...The next great task will be to learn not to do them." - G. K. Chesterton (1874-1936) --Apple-Mail=_A5558725-5888-458A-8449-CB1BAFB071CF Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="signature.asc" Content-Type: application/pgp-signature; name="signature.asc" Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- Comment: GPGTools - http://gpgtools.org iD8DBQFST1jPbjEdbHIsm0MRAqHlAKDFyJrPslVk9tmj8pCLiVpYQ/at6gCeN7nM EIpL2vEuAvCTW/cibTSaTyI= =AiIC -----END PGP SIGNATURE----- --Apple-Mail=_A5558725-5888-458A-8449-CB1BAFB071CF-- From internet-drafts@ietf.org Sun Oct 6 15:53:03 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EC9E321E80E7; Sun, 6 Oct 2013 15:53:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.553 X-Spam-Level: X-Spam-Status: No, score=-102.553 tagged_above=-999 required=5 tests=[AWL=0.047, 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 tBx1GqiJ7Nsp; Sun, 6 Oct 2013 15:53:03 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 6C1F721E80E1; Sun, 6 Oct 2013 15:53:00 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 4.80.p1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20131006225300.2583.94870.idtracker@ietfa.amsl.com> Date: Sun, 06 Oct 2013 15:53:00 -0700 Cc: v6ops@ietf.org Subject: [v6ops] I-D Action: draft-ietf-v6ops-64share-09.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 06 Oct 2013 22:53:04 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the IPv6 Operations Working Group of the IETF. Title : Extending an IPv6 /64 Prefix from a 3GPP Mobile Interfac= e to a LAN link Author(s) : Cameron Byrne Dan Drown Ales Vizdal Filename : draft-ietf-v6ops-64share-09.txt Pages : 9 Date : 2013-10-06 Abstract: This document describes requirements for extending an IPv6 /64 prefix from a User Equipment 3GPP radio interface to a LAN link as well as two implementation examples. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-v6ops-64share There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-v6ops-64share-09 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-v6ops-64share-09 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From ales.vizdal@t-mobile.cz Sun Oct 6 16:02:36 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 918DB21E80E9 for ; Sun, 6 Oct 2013 16:02:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.35 X-Spam-Level: X-Spam-Status: No, score=-0.35 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_CZ=0.445, HOST_EQ_CZ=0.904, J_CHICKENPOX_13=0.6, MIME_8BIT_HEADER=0.3] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EZwWi47ItVqm for ; Sun, 6 Oct 2013 16:02:32 -0700 (PDT) Received: from ctxmailhub.t-mobile.cz (ctxmailhub.t-mobile.cz [93.153.104.87]) by ietfa.amsl.com (Postfix) with ESMTP id A00A521E80EB for ; Sun, 6 Oct 2013 16:02:27 -0700 (PDT) Received: from srvhk503.rdm.cz (unknown [10.254.92.81]) by ctxmailhub.t-mobile.cz (Postfix) with ESMTP id 4092A2E0989 for ; Mon, 7 Oct 2013 01:02:26 +0200 (CEST) Received: from SRVHKE02.rdm.cz ([fe80::94ce:8456:f6fa:86a8]) by srvhk503.rdm.cz ([fe80::a0bc:fdcc:adf9:5f66%12]) with mapi; Mon, 7 Oct 2013 01:02:25 +0200 From: =?iso-8859-2?Q?V=EDzdal_Ale=B9?= To: "v6ops@ietf.org" Date: Mon, 7 Oct 2013 01:02:24 +0200 Thread-Topic: [v6ops] I-D Action: draft-ietf-v6ops-64share-09.txt Thread-Index: Ac7C5wWSXiExcDAYQjiyLNF9RsB57wAAJhaw Message-ID: <1808340F7EC362469DDFFB112B37E2FCD8771BDB9F@SRVHKE02.rdm.cz> References: <20131006225300.2583.94870.idtracker@ietfa.amsl.com> In-Reply-To: <20131006225300.2583.94870.idtracker@ietfa.amsl.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="iso-8859-2" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Forwarded Subject: Re: [v6ops] I-D Action: draft-ietf-v6ops-64share-09.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 06 Oct 2013 23:02:36 -0000 Hi, A new version has just been submitted, please check it and provide your com= ments. This version is mainly addressing (or at least trying to) Lorenzo's comment= (s) about splitting=20 the document into requirements and example section. Cheers, Ales > -----Original Message----- > From: v6ops-bounces@ietf.org [mailto:v6ops-bounces@ietf.org] On Behalf Of= internet- > drafts@ietf.org > Sent: Monday, October 07, 2013 12:53 AM > To: i-d-announce@ietf.org > Cc: v6ops@ietf.org > Subject: [v6ops] I-D Action: draft-ietf-v6ops-64share-09.txt >=20 >=20 > A New Internet-Draft is available from the on-line Internet-Drafts direct= ories. > This draft is a work item of the IPv6 Operations Working Group of the IE= TF. >=20 > Title : Extending an IPv6 /64 Prefix from a 3GPP Mobile Interf= ace to a > LAN link > Author(s) : Cameron Byrne > Dan Drown > Ales Vizdal > Filename : draft-ietf-v6ops-64share-09.txt > Pages : 9 > Date : 2013-10-06 >=20 > Abstract: > This document describes requirements for extending an IPv6 /64 prefix > from a User Equipment 3GPP radio interface to a LAN link as well as > two implementation examples. >=20 >=20 > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-ietf-v6ops-64share >=20 > There's also a htmlized version available at: > http://tools.ietf.org/html/draft-ietf-v6ops-64share-09 >=20 > A diff from the previous version is available at: > http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-v6ops-64share-09 >=20 >=20 > Please note that it may take a couple of minutes from the time of submiss= ion until the > htmlized version and diff are available at tools.ietf.org. >=20 > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ >=20 > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops From alexandru.petrescu@gmail.com Mon Oct 7 00:51:10 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 507F021E817B for ; Mon, 7 Oct 2013 00:51:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.761 X-Spam-Level: X-Spam-Status: No, score=-9.761 tagged_above=-999 required=5 tests=[AWL=-0.412, BAYES_00=-2.599, HELO_EQ_FR=0.35, J_CHICKENPOX_13=0.6, MIME_8BIT_HEADER=0.3, 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 YnvwDJJhB8S4 for ; Mon, 7 Oct 2013 00:51:00 -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 B370021E8177 for ; Mon, 7 Oct 2013 00:50:55 -0700 (PDT) Received: from pisaure.intra.cea.fr (pisaure.intra.cea.fr [132.166.88.21]) by cirse.extra.cea.fr (8.14.2/8.14.2/CEAnet-Internet-out-2.3) with ESMTP id r977orfX029094 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Mon, 7 Oct 2013 09:50: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 r977or0c015068; Mon, 7 Oct 2013 09:50:53 +0200 (envelope-from alexandru.petrescu@gmail.com) Received: from [127.0.0.1] (is010446-4.intra.cea.fr [10.8.33.116]) by muguet1.intra.cea.fr (8.13.8/8.13.8/CEAnet-Intranet-out-1.2) with ESMTP id r977oceh019782; Mon, 7 Oct 2013 09:50:53 +0200 Message-ID: <525267CD.2030702@gmail.com> Date: Mon, 07 Oct 2013 09:50:37 +0200 From: Alexandru Petrescu User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:24.0) Gecko/20100101 Thunderbird/24.0 MIME-Version: 1.0 To: =?windows-1252?Q?V=EDzdal_Ale=9A?= References: <20131006225300.2583.94870.idtracker@ietfa.amsl.com> <1808340F7EC362469DDFFB112B37E2FCD8771BDB9F@SRVHKE02.rdm.cz> In-Reply-To: <1808340F7EC362469DDFFB112B37E2FCD8771BDB9F@SRVHKE02.rdm.cz> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit Cc: "v6ops@ietf.org" Subject: Re: [v6ops] illustration? (was: I-D Action: draft-ietf-v6ops-64share-09.txt) X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 07 Oct 2013 07:51:10 -0000 Hi, Thanks for this new version. Remark: it may be that a graphical illustration may be useful to a hurried reader. To that end I suggest this: > Example of use > -------------- > > Use-case > -------- > > The following use case is pertinent for the 64share method described > in this document. It consists in a User Equipment (UE) connecting to > a IPv6 cellular network and 'sharing' this connection with one or > several Hosts present in a small network it controls. This use-case > is also known under the name 'tethering' (despite concerning mostly > wireless links). > > The topology supporting such a use case is depicted in the following > figure: > > /-----\ > / \ > / -- \ ptp link ---- ------ > Internet-- |AR|------ --| UE |-- --| Host1| > \ -- / ---- ------ > \ / | > \- ---/ | ------ > cellular +--| Hostn| > network ------ What do you think? Alex Le 07/10/2013 01:02, Vízdal Aleš a écrit : > Hi, > > A new version has just been submitted, please check it and provide your comments. > > This version is mainly addressing (or at least trying to) Lorenzo's comment(s) about splitting > the document into requirements and example section. > > Cheers, > Ales > >> -----Original Message----- >> From: v6ops-bounces@ietf.org [mailto:v6ops-bounces@ietf.org] On Behalf Of internet- >> drafts@ietf.org >> Sent: Monday, October 07, 2013 12:53 AM >> To: i-d-announce@ietf.org >> Cc: v6ops@ietf.org >> Subject: [v6ops] I-D Action: draft-ietf-v6ops-64share-09.txt >> >> >> A New Internet-Draft is available from the on-line Internet-Drafts directories. >> This draft is a work item of the IPv6 Operations Working Group of the IETF. >> >> Title : Extending an IPv6 /64 Prefix from a 3GPP Mobile Interface to a >> LAN link >> Author(s) : Cameron Byrne >> Dan Drown >> Ales Vizdal >> Filename : draft-ietf-v6ops-64share-09.txt >> Pages : 9 >> Date : 2013-10-06 >> >> Abstract: >> This document describes requirements for extending an IPv6 /64 prefix >> from a User Equipment 3GPP radio interface to a LAN link as well as >> two implementation examples. >> >> >> The IETF datatracker status page for this draft is: >> https://datatracker.ietf.org/doc/draft-ietf-v6ops-64share >> >> There's also a htmlized version available at: >> http://tools.ietf.org/html/draft-ietf-v6ops-64share-09 >> >> A diff from the previous version is available at: >> http://www.ietf.org/rfcdiff?url2=draft-ietf-v6ops-64share-09 >> >> >> Please note that it may take a couple of minutes from the time of submission until the >> htmlized version and diff are available at tools.ietf.org. >> >> Internet-Drafts are also available by anonymous FTP at: >> ftp://ftp.ietf.org/internet-drafts/ >> >> _______________________________________________ >> v6ops mailing list >> v6ops@ietf.org >> https://www.ietf.org/mailman/listinfo/v6ops > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops > From alexandru.petrescu@gmail.com Mon Oct 7 01:19:10 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DE66C21E818C for ; Mon, 7 Oct 2013 01:19:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.108 X-Spam-Level: X-Spam-Status: No, score=-10.108 tagged_above=-999 required=5 tests=[AWL=0.141, BAYES_00=-2.599, HELO_EQ_FR=0.35, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5VnSI0NC3im5 for ; Mon, 7 Oct 2013 01:19:04 -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 1D41321E8189 for ; Mon, 7 Oct 2013 01:19:02 -0700 (PDT) Received: from pisaure.intra.cea.fr (pisaure.intra.cea.fr [132.166.88.21]) by cirse.extra.cea.fr (8.14.2/8.14.2/CEAnet-Internet-out-2.3) with ESMTP id r978J1XC002287 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT) for ; Mon, 7 Oct 2013 10:19:01 +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 r978J1Ao003356 for ; Mon, 7 Oct 2013 10:19:01 +0200 (envelope-from alexandru.petrescu@gmail.com) Received: from [127.0.0.1] (is010446-4.intra.cea.fr [10.8.33.116]) by muguet1.intra.cea.fr (8.13.8/8.13.8/CEAnet-Intranet-out-1.2) with ESMTP id r978IvvF013115 for ; Mon, 7 Oct 2013 10:19:01 +0200 Message-ID: <52526E71.4050402@gmail.com> Date: Mon, 07 Oct 2013 10:18:57 +0200 From: Alexandru Petrescu User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:24.0) Gecko/20100101 Thunderbird/24.0 MIME-Version: 1.0 To: "v6ops@ietf.org" Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: [v6ops] Need ref to 3GPP spec for the use of DHCPv6 Prefix Delegation, e.g. for smartphone tethering X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 07 Oct 2013 08:19:10 -0000 Hello, I need a reference to a 3GPP spec which requires or explains the use of DHCPv6 Prefix Delegation for smartphone tethering (mobile hotspot). This is because we write a problem statement draft in DHC WG ""Route Problem at Relay during DHCPv6 Prefix Delegation". I would like that draft to reflect the problem not only in the homenet-kind of deployments (DSL, broadband forum) but also smartphone deployments. Thanks in advance, Alex (in that draft, we are refer to a BroadBand Forum document "Broadband Forum, Technical Report, TR-177, "IPv6 in the Context of TR-101, Issue: 1, Issue date: November 2010", document freely available at the URL http://www.broadbandforum.org/technical/download/TR-177.pdf accessed on October 4th, 2013." which lists a number of problems and requirements for Relay during PD.) From swmike@swm.pp.se Mon Oct 7 01:33:45 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5AC9021E8192 for ; Mon, 7 Oct 2013 01:33:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.424 X-Spam-Level: X-Spam-Status: No, score=-4.424 tagged_above=-999 required=5 tests=[AWL=1.825, BAYES_00=-2.599, HELO_EQ_SE=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 pESiI+t0twXj for ; Mon, 7 Oct 2013 01:33:39 -0700 (PDT) Received: from uplift.swm.pp.se (swm.pp.se [212.247.200.143]) by ietfa.amsl.com (Postfix) with ESMTP id CC8DF21E8113 for ; Mon, 7 Oct 2013 01:33:37 -0700 (PDT) Received: by uplift.swm.pp.se (Postfix, from userid 501) id E2B4D9C; Mon, 7 Oct 2013 10:33:35 +0200 (CEST) Received: from localhost (localhost [127.0.0.1]) by uplift.swm.pp.se (Postfix) with ESMTP id DA8AF9A; Mon, 7 Oct 2013 10:33:35 +0200 (CEST) Date: Mon, 7 Oct 2013 10:33:35 +0200 (CEST) From: Mikael Abrahamsson To: Alexandru Petrescu In-Reply-To: <52526E71.4050402@gmail.com> Message-ID: References: <52526E71.4050402@gmail.com> User-Agent: Alpine 2.02 (DEB 1266 2009-07-14) Organization: People's Front Against WWW MIME-Version: 1.0 Content-Type: MULTIPART/MIXED; BOUNDARY="-137064504-643784932-1381134815=:20065" Cc: "v6ops@ietf.org" Subject: Re: [v6ops] Need ref to 3GPP spec for the use of DHCPv6 Prefix Delegation, e.g. for smartphone tethering X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 07 Oct 2013 08:33:45 -0000 This message is in MIME format. The first part should be readable text, while the remaining parts are likely unreadable without MIME-aware tools. ---137064504-643784932-1381134815=:20065 Content-Type: TEXT/PLAIN; charset=ISO-8859-15; format=flowed Content-Transfer-Encoding: 8BIT On Mon, 7 Oct 2013, Alexandru Petrescu wrote: > Hello, > > I need a reference to a 3GPP spec which requires or explains the use of > DHCPv6 Prefix Delegation for smartphone tethering (mobile hotspot). > > This is because we write a problem statement draft in DHC WG ""Route > Problem at Relay during DHCPv6 Prefix Delegation". > > I would like that draft to reflect the problem not only in the > homenet-kind of deployments (DSL, broadband forum) but also smartphone > deployments. http://www.3gpp.org/ftp/Specs/html-info/23402.htm If you download the 10.8.0 spec you will find: "4.7.5 IPv6 Prefix Delegation using S2c Optionally a single network prefix shorter than a /64 prefix may be assigned to a PDN connection (TS 23.401 [4]). When S2c is used to access a PDN, the UE acting as a Mobile Router may request delegation of one or more IPv6 prefix(es) via DHCPv6 Prefix Delegation signalling as described in RFC 6267 [56]. The UE does not need to explicitly register these additional prefixes using S2c signaling as implicit mode registration is used." So this is not specific to smartphone tethering, but to any kind of mobile device that wants to act as a router. -- Mikael Abrahamsson email: swmike@swm.pp.se ---137064504-643784932-1381134815=:20065-- From alexandru.petrescu@gmail.com Mon Oct 7 04:43:54 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AE4BB21F9EFB for ; Mon, 7 Oct 2013 04:43:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.136 X-Spam-Level: X-Spam-Status: No, score=-10.136 tagged_above=-999 required=5 tests=[AWL=0.113, BAYES_00=-2.599, HELO_EQ_FR=0.35, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id u9UuHuOq+Dvq for ; Mon, 7 Oct 2013 04:43: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 BAC6111E80D9 for ; Mon, 7 Oct 2013 04:43:40 -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.3) with ESMTP id r97Bhd9r023096 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Mon, 7 Oct 2013 13:43:39 +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 r97BhcEI007547; Mon, 7 Oct 2013 13:43:38 +0200 (envelope-from alexandru.petrescu@gmail.com) Received: from [127.0.0.1] (is010446-4.intra.cea.fr [10.8.33.116]) by muguet1.intra.cea.fr (8.13.8/8.13.8/CEAnet-Intranet-out-1.2) with ESMTP id r97BhZv6029952; Mon, 7 Oct 2013 13:43:38 +0200 Message-ID: <52529E67.3000905@gmail.com> Date: Mon, 07 Oct 2013 13:43:35 +0200 From: Alexandru Petrescu User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:24.0) Gecko/20100101 Thunderbird/24.0 MIME-Version: 1.0 To: Mikael Abrahamsson References: <52526E71.4050402@gmail.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-15; format=flowed Content-Transfer-Encoding: 8bit Cc: "v6ops@ietf.org" Subject: Re: [v6ops] Need ref to 3GPP spec for the use of DHCPv6 Prefix Delegation, e.g. for smartphone tethering X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 07 Oct 2013 11:43:54 -0000 Le 07/10/2013 10:33, Mikael Abrahamsson a écrit : > On Mon, 7 Oct 2013, Alexandru Petrescu wrote: > >> Hello, >> >> I need a reference to a 3GPP spec which requires or explains the >> use of DHCPv6 Prefix Delegation for smartphone tethering (mobile >> hotspot). >> >> This is because we write a problem statement draft in DHC WG >> ""Route Problem at Relay during DHCPv6 Prefix Delegation". >> >> I would like that draft to reflect the problem not only in the >> homenet-kind of deployments (DSL, broadband forum) but also >> smartphone deployments. > > http://www.3gpp.org/ftp/Specs/html-info/23402.htm > > If you download the 10.8.0 spec you will find: > > "4.7.5 IPv6 Prefix Delegation using S2c Optionally a single > network prefix shorter than a /64 prefix may be assigned to a PDN > connection (TS 23.401 [4]). When S2c is used to access a PDN, the UE > acting as a Mobile Router may request delegation of one or more IPv6 > prefix(es) via DHCPv6 Prefix Delegation signalling as described in > RFC 6267 [56]. The UE does not need to explicitly register these > additional prefixes using S2c signaling as implicit mode registration > is used." Thanks for the reference. This is the kind of use at 3GPP that I am looking for. I will use it right away. (for info: there are some errors in the above text (I guess they mean RFC 6276 bit 6267; second, I doubt Prefix Delegation with NEMO is needed in this context - but rather simple PD without tunnels; RFC 6276 assumes the Relay is on the mobile router, whereas the cellular deployment would host the Relay in the fixed network).) > So this is not specific to smartphone tethering, but to any kind of > mobile device that wants to act as a router. Yes, I agree, they call it 'UE acting as a Mobile Router'. Alex > From ales.vizdal@t-mobile.cz Mon Oct 7 05:20:03 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B5CEF21E8091 for ; Mon, 7 Oct 2013 05:20:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.65 X-Spam-Level: X-Spam-Status: No, score=-0.65 tagged_above=-999 required=5 tests=[AWL=0.300, BAYES_00=-2.599, HELO_EQ_CZ=0.445, HOST_EQ_CZ=0.904, MIME_8BIT_HEADER=0.3] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BF6ivBCaeiDo for ; Mon, 7 Oct 2013 05:19:59 -0700 (PDT) Received: from ctxmailhub.t-mobile.cz (ctxmailhub.t-mobile.cz [93.153.104.87]) by ietfa.amsl.com (Postfix) with ESMTP id DC66C21E808E for ; Mon, 7 Oct 2013 05:19:54 -0700 (PDT) Received: from srvhk504.rdm.cz (unknown [10.254.92.81]) by ctxmailhub.t-mobile.cz (Postfix) with ESMTP id 142D92E06A1; Mon, 7 Oct 2013 14:19:53 +0200 (CEST) Received: from SRVHKE02.rdm.cz ([fe80::94ce:8456:f6fa:86a8]) by srvhk504.rdm.cz ([::1]) with mapi; Mon, 7 Oct 2013 14:19:52 +0200 From: =?iso-8859-2?Q?V=EDzdal_Ale=B9?= To: Alexandru Petrescu , Mikael Abrahamsson Date: Mon, 7 Oct 2013 14:19:51 +0200 Thread-Topic: [v6ops] Need ref to 3GPP spec for the use of DHCPv6 Prefix Delegation, e.g. for smartphone tethering Thread-Index: Ac7DUplkr1DBMwMlT4yThBQaya/zcAABKNOA Message-ID: <1808340F7EC362469DDFFB112B37E2FCD8771BDD53@SRVHKE02.rdm.cz> References: <52526E71.4050402@gmail.com> <52529E67.3000905@gmail.com> In-Reply-To: <52529E67.3000905@gmail.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="iso-8859-2" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Forwarded Cc: "v6ops@ietf.org" Subject: Re: [v6ops] Need ref to 3GPP spec for the use of DHCPv6 Prefix Delegation, e.g. for smartphone tethering X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 07 Oct 2013 12:20:03 -0000 > -----Original Message----- > From: v6ops-bounces@ietf.org [mailto:v6ops-bounces@ietf.org] On Behalf Of > Alexandru Petrescu > Sent: Monday, October 07, 2013 1:44 PM > To: Mikael Abrahamsson > Cc: v6ops@ietf.org > Subject: Re: [v6ops] Need ref to 3GPP spec for the use of DHCPv6 Prefix D= elegation, > e.g. for smartphone tethering >=20 > Le 07/10/2013 10:33, Mikael Abrahamsson a =E9crit : > > On Mon, 7 Oct 2013, Alexandru Petrescu wrote: > > > >> Hello, > >> > >> I need a reference to a 3GPP spec which requires or explains the use > >> of DHCPv6 Prefix Delegation for smartphone tethering (mobile > >> hotspot). > >> > >> This is because we write a problem statement draft in DHC WG ""Route > >> Problem at Relay during DHCPv6 Prefix Delegation". > >> > >> I would like that draft to reflect the problem not only in the > >> homenet-kind of deployments (DSL, broadband forum) but also > >> smartphone deployments. > > > > http://www.3gpp.org/ftp/Specs/html-info/23402.htm > > > > If you download the 10.8.0 spec you will find: > > > > "4.7.5 IPv6 Prefix Delegation using S2c Optionally a single > > network prefix shorter than a /64 prefix may be assigned to a PDN > > connection (TS 23.401 [4]). When S2c is used to access a PDN, the UE > > acting as a Mobile Router may request delegation of one or more IPv6 > > prefix(es) via DHCPv6 Prefix Delegation signalling as described in RFC > > 6267 [56]. The UE does not need to explicitly register these > > additional prefixes using S2c signaling as implicit mode registration > > is used." >=20 > Thanks for the reference. This is the kind of use at 3GPP that I am look= ing for. I will > use it right away. >=20 > (for info: there are some errors in the above text (I guess they mean RFC= 6276 bit > 6267; second, I doubt Prefix Delegation with NEMO is needed in this conte= xt - but > rather simple PD without tunnels; RFC 6276 assumes the Relay is on the mo= bile router, > whereas the cellular deployment would host the Relay in the fixed network= ).) I guess that the right RFCs shall be 3633 & 6603. =20 > > So this is not specific to smartphone tethering, but to any kind of > > mobile device that wants to act as a router. >=20 > Yes, I agree, they call it 'UE acting as a Mobile Router'. >=20 > Alex Ales From alexandru.petrescu@gmail.com Mon Oct 7 06:58:30 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0912A21F9E83 for ; Mon, 7 Oct 2013 06:58:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.005 X-Spam-Level: X-Spam-Status: No, score=-10.005 tagged_above=-999 required=5 tests=[AWL=-0.056, BAYES_00=-2.599, HELO_EQ_FR=0.35, MIME_8BIT_HEADER=0.3, 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 0g14WHQaosUn for ; Mon, 7 Oct 2013 06:58:25 -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 A2C7121F9E6C for ; Mon, 7 Oct 2013 06:58:24 -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.3) with ESMTP id r97DwN8m021551 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Mon, 7 Oct 2013 15:58:23 +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 r97DwMfq018046; Mon, 7 Oct 2013 15:58:22 +0200 (envelope-from alexandru.petrescu@gmail.com) Received: from [127.0.0.1] (is010446-4.intra.cea.fr [10.8.33.116]) by muguet1.intra.cea.fr (8.13.8/8.13.8/CEAnet-Intranet-out-1.2) with ESMTP id r97DwJ8q031126; Mon, 7 Oct 2013 15:58:22 +0200 Message-ID: <5252BDFA.8040907@gmail.com> Date: Mon, 07 Oct 2013 15:58:18 +0200 From: Alexandru Petrescu User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:24.0) Gecko/20100101 Thunderbird/24.0 MIME-Version: 1.0 To: =?ISO-8859-2?Q?V=EDzdal_Ale=B9?= , Mikael Abrahamsson References: <52526E71.4050402@gmail.com> <52529E67.3000905@gmail.com> <1808340F7EC362469DDFFB112B37E2FCD8771BDD53@SRVHKE02.rdm.cz> In-Reply-To: <1808340F7EC362469DDFFB112B37E2FCD8771BDD53@SRVHKE02.rdm.cz> Content-Type: text/plain; charset=ISO-8859-2; format=flowed Content-Transfer-Encoding: 8bit Cc: "v6ops@ietf.org" Subject: Re: [v6ops] Need ref to 3GPP spec for the use of DHCPv6 Prefix Delegation, e.g. for smartphone tethering X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 07 Oct 2013 13:58:30 -0000 Le 07/10/2013 14:19, Vízdal Aleš a écrit : >> -----Original Message----- From: v6ops-bounces@ietf.org >> [mailto:v6ops-bounces@ietf.org] On Behalf Of Alexandru Petrescu >> Sent: Monday, October 07, 2013 1:44 PM To: Mikael Abrahamsson Cc: >> v6ops@ietf.org Subject: Re: [v6ops] Need ref to 3GPP spec for the >> use of DHCPv6 Prefix Delegation, e.g. for smartphone tethering >> >> Le 07/10/2013 10:33, Mikael Abrahamsson a écrit : >>> On Mon, 7 Oct 2013, Alexandru Petrescu wrote: >>> >>>> Hello, >>>> >>>> I need a reference to a 3GPP spec which requires or explains >>>> the use of DHCPv6 Prefix Delegation for smartphone tethering >>>> (mobile hotspot). >>>> >>>> This is because we write a problem statement draft in DHC WG >>>> ""Route Problem at Relay during DHCPv6 Prefix Delegation". >>>> >>>> I would like that draft to reflect the problem not only in the >>>> homenet-kind of deployments (DSL, broadband forum) but also >>>> smartphone deployments. >>> >>> http://www.3gpp.org/ftp/Specs/html-info/23402.htm >>> >>> If you download the 10.8.0 spec you will find: >>> >>> "4.7.5 IPv6 Prefix Delegation using S2c Optionally a single >>> network prefix shorter than a /64 prefix may be assigned to a PDN >>> connection (TS 23.401 [4]). When S2c is used to access a PDN, the >>> UE acting as a Mobile Router may request delegation of one or >>> more IPv6 prefix(es) via DHCPv6 Prefix Delegation signalling as >>> described in RFC 6267 [56]. The UE does not need to explicitly >>> register these additional prefixes using S2c signaling as >>> implicit mode registration is used." >> >> Thanks for the reference. This is the kind of use at 3GPP that I >> am looking for. I will use it right away. >> >> (for info: there are some errors in the above text (I guess they >> mean RFC 6276 bit 6267; second, I doubt Prefix Delegation with >> NEMO is needed in this context - but rather simple PD without >> tunnels; RFC 6276 assumes the Relay is on the mobile router, >> whereas the cellular deployment would host the Relay in the fixed >> network).) > > I guess that the right RFCs shall be 3633 & 6603. I think yes, sure, that's better, that's the pure PD and the PD-exclude RFCs. Not sure about the necessity of PD-exclude in a 3GPP specific scenario, but there may exist a reason for that -exclude. Remark though that in that spec I couldnt find enunciating a problem of routing at Relay, during the Prefix Delegation process. It's strange, because the broadband forum _has_ identified such a problem. Either there is no problem, in which case 3gpp would rather advise bf to not worry about it; or there is, and 3gpp would need to ack it. Alex PS: the BroadBand's problem at Relay during Prefix Delegation is described in technical report titled "IPv6 in the context of TR-101", dated November 2010 as: > "hosts receiving IPv6 addresses from the RR are not known to the > BNG, i.e. the BNG is not aware of what addresses/prefixes are > assigned to hosts attached to the RG acting as RR." From rajiva@cisco.com Mon Oct 7 07:12:09 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AE5EB21E80AE for ; Mon, 7 Oct 2013 07:12:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.299 X-Spam-Level: X-Spam-Status: No, score=-10.299 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, 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 83wAAAtnNul1 for ; Mon, 7 Oct 2013 07:12:03 -0700 (PDT) Received: from rcdn-iport-3.cisco.com (rcdn-iport-3.cisco.com [173.37.86.74]) by ietfa.amsl.com (Postfix) with ESMTP id DE92D21F9EB0 for ; Mon, 7 Oct 2013 07:12:02 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=4215; q=dns/txt; s=iport; t=1381155123; x=1382364723; h=from:to:cc:subject:date:message-id:in-reply-to: content-id:content-transfer-encoding:mime-version; bh=osq8XYyqfzbG5TH7ZU7FwnoSYgBHUNXzE5Nn2+I9JHg=; b=j8Twe7p2bUHIHRmRfaySyYarZjNw3h/rOKFtzhwnwuSrJn99ISTjw2ln fcr06KOh6Hho9fO9LQDV7BjnvSgNbtnNEa0d6HXljkJhyRqWJ/dwkBhXZ f3ukdpWls3noMH4d4yO/JzVMtqgVwK9QdMPksQCtRGgSWQZzf2jksCLGV 8=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AlcFAB7AUlKtJXG8/2dsb2JhbABZgwc4UsAJgRGBHhZ0giUBAQEEAQEBawsMBgEIEQMBAQEBChkEKAYLFAkIAgQBDQUIh2wDDwywVg2Ja4xmgjoxBwaDGYEEA5YYjjOFNoFmgT6CKg X-IronPort-AV: E=Sophos;i="4.90,1050,1371081600"; d="scan'208";a="268983449" Received: from rcdn-core2-1.cisco.com ([173.37.113.188]) by rcdn-iport-3.cisco.com with ESMTP; 07 Oct 2013 14:12:02 +0000 Received: from xhc-aln-x12.cisco.com (xhc-aln-x12.cisco.com [173.36.12.86]) by rcdn-core2-1.cisco.com (8.14.5/8.14.5) with ESMTP id r97EC2xx032391 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Mon, 7 Oct 2013 14:12:02 GMT Received: from xmb-rcd-x06.cisco.com ([169.254.6.250]) by xhc-aln-x12.cisco.com ([173.36.12.86]) with mapi id 14.02.0318.004; Mon, 7 Oct 2013 09:12:02 -0500 From: "Rajiv Asati (rajiva)" To: Alexandru Petrescu , =?iso-8859-2?Q?V=EDzdal_Ale=B9?= , "Mikael Abrahamsson" Thread-Topic: [v6ops] Need ref to 3GPP spec for the use of DHCPv6 Prefix Delegation, e.g. for smartphone tethering Thread-Index: AQHOwzXxj74egbxewk2p7w25wCZZjJnpPTiAgAA1FoCAAAoigIAAG4IA///AvwA= Date: Mon, 7 Oct 2013 14:12:01 +0000 Message-ID: In-Reply-To: <5252BDFA.8040907@gmail.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.3.6.130613 x-originating-ip: [64.102.38.113] Content-Type: text/plain; charset="iso-8859-2" Content-ID: <05F4B28201DECF449C042E0ECA1703EB@emea.cisco.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "v6ops@ietf.org" Subject: Re: [v6ops] Need ref to 3GPP spec for the use of DHCPv6 Prefix Delegation, e.g. for smartphone tethering X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 07 Oct 2013 14:12:09 -0000 >PS: the BroadBand's problem at Relay during Prefix Delegation is >described in technical report titled "IPv6 in the context of TR-101", >dated November 2010 as: >>"hosts receiving IPv6 addresses from the RR are not known to the >>BNG, i.e. the BNG is not aware of what addresses/prefixes are >>assigned to hosts attached to the RG acting as RR." We may be getting off-topic here, but why is the above deemed as a problem? It is a hierarchical distribution model after all. =20 --=20 Cheers, Rajiv Asati Distinguished Engineer, Cisco -----Original Message----- From: Alexandru Petrescu Date: Monday, October 7, 2013 9:58 AM To: V=EDzdal Ale=B9 , Mikael Abrahamsson Cc: "v6ops@ietf.org" Subject: Re: [v6ops] Need ref to 3GPP spec for the use of DHCPv6 Prefix Delegation, e.g. for smartphone tethering >Le 07/10/2013 14:19, V=EDzdal Ale=B9 a =E9crit : >>> -----Original Message----- From: v6ops-bounces@ietf.org >>> [mailto:v6ops-bounces@ietf.org] On Behalf Of Alexandru Petrescu >>> Sent: Monday, October 07, 2013 1:44 PM To: Mikael Abrahamsson Cc: >>> v6ops@ietf.org Subject: Re: [v6ops] Need ref to 3GPP spec for the >>> use of DHCPv6 Prefix Delegation, e.g. for smartphone tethering >>> >>> Le 07/10/2013 10:33, Mikael Abrahamsson a =E9crit : >>>> On Mon, 7 Oct 2013, Alexandru Petrescu wrote: >>>> >>>>> Hello, >>>>> >>>>> I need a reference to a 3GPP spec which requires or explains >>>>> the use of DHCPv6 Prefix Delegation for smartphone tethering >>>>> (mobile hotspot). >>>>> >>>>> This is because we write a problem statement draft in DHC WG >>>>> ""Route Problem at Relay during DHCPv6 Prefix Delegation". >>>>> >>>>> I would like that draft to reflect the problem not only in the >>>>> homenet-kind of deployments (DSL, broadband forum) but also >>>>> smartphone deployments. >>>> >>>> http://www.3gpp.org/ftp/Specs/html-info/23402.htm >>>> >>>> If you download the 10.8.0 spec you will find: >>>> >>>> "4.7.5 IPv6 Prefix Delegation using S2c Optionally a single >>>> network prefix shorter than a /64 prefix may be assigned to a PDN >>>> connection (TS 23.401 [4]). When S2c is used to access a PDN, the >>>> UE acting as a Mobile Router may request delegation of one or >>>> more IPv6 prefix(es) via DHCPv6 Prefix Delegation signalling as >>>> described in RFC 6267 [56]. The UE does not need to explicitly >>>> register these additional prefixes using S2c signaling as >>>> implicit mode registration is used." >>> >>> Thanks for the reference. This is the kind of use at 3GPP that I >>> am looking for. I will use it right away. >>> >>> (for info: there are some errors in the above text (I guess they >>> mean RFC 6276 bit 6267; second, I doubt Prefix Delegation with >>> NEMO is needed in this context - but rather simple PD without >>> tunnels; RFC 6276 assumes the Relay is on the mobile router, >>> whereas the cellular deployment would host the Relay in the fixed >>> network).) >> >> I guess that the right RFCs shall be 3633 & 6603. > >I think yes, sure, that's better, that's the pure PD and the PD-exclude >RFCs. Not sure about the necessity of PD-exclude in a 3GPP specific >scenario, but there may exist a reason for that -exclude. > >Remark though that in that spec I couldnt find enunciating a problem of >routing at Relay, during the Prefix Delegation process. > >It's strange, because the broadband forum _has_ identified such a problem. > >Either there is no problem, in which case 3gpp would rather advise bf to >not worry about it; or there is, and 3gpp would need to ack it. > >Alex >PS: the BroadBand's problem at Relay during Prefix Delegation is >described in technical report titled "IPv6 in the context of TR-101", >dated November 2010 as: >> "hosts receiving IPv6 addresses from the RR are not known to the >> BNG, i.e. the BNG is not aware of what addresses/prefixes are >> assigned to hosts attached to the RG acting as RR." > >_______________________________________________ >v6ops mailing list >v6ops@ietf.org >https://www.ietf.org/mailman/listinfo/v6ops From alexandru.petrescu@gmail.com Mon Oct 7 07:31:44 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E7DD921E80A6 for ; Mon, 7 Oct 2013 07:31:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.997 X-Spam-Level: X-Spam-Status: No, score=-9.997 tagged_above=-999 required=5 tests=[AWL=-0.048, BAYES_00=-2.599, HELO_EQ_FR=0.35, MIME_8BIT_HEADER=0.3, 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 hGeoZlFb0IRf for ; Mon, 7 Oct 2013 07:31:38 -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 1B2A221E80BF for ; Mon, 7 Oct 2013 07:31:37 -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.3) with ESMTP id r97EVYn0004843 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Mon, 7 Oct 2013 16:31:35 +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 r97EVYth004900; Mon, 7 Oct 2013 16:31:34 +0200 (envelope-from alexandru.petrescu@gmail.com) Received: from [127.0.0.1] (is010446-4.intra.cea.fr [10.8.33.116]) by muguet1.intra.cea.fr (8.13.8/8.13.8/CEAnet-Intranet-out-1.2) with ESMTP id r97EVUuK023513; Mon, 7 Oct 2013 16:31:34 +0200 Message-ID: <5252C5C2.5080706@gmail.com> Date: Mon, 07 Oct 2013 16:31:30 +0200 From: Alexandru Petrescu User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:24.0) Gecko/20100101 Thunderbird/24.0 MIME-Version: 1.0 To: "Rajiv Asati (rajiva)" , =?ISO-8859-2?Q?V=EDzdal_?= =?ISO-8859-2?Q?Ale=B9?= , Mikael Abrahamsson References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-2; format=flowed Content-Transfer-Encoding: 8bit Cc: "v6ops@ietf.org" Subject: Re: [v6ops] Need ref to 3GPP spec for the use of DHCPv6 Prefix Delegation, e.g. for smartphone tethering X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 07 Oct 2013 14:31:45 -0000 Le 07/10/2013 16:12, Rajiv Asati (rajiva) a écrit : > >> PS: the BroadBand's problem at Relay during Prefix Delegation is >> described in technical report titled "IPv6 in the context of TR-101", >> dated November 2010 as: >>> "hosts receiving IPv6 addresses from the RR are not known to the >>> BNG, i.e. the BNG is not aware of what addresses/prefixes are >>> assigned to hosts attached to the RG acting as RR." > > We may be getting off-topic here, but why is the above deemed as a > problem? It is a hierarchical distribution model after all. Not trying to get off-topic. This is a DHC discussion. BAsically it all starts at section 14 "Relay Agent Behaviour" of RFC 3633 DHCPv6-PD which says this: > If a delegating router communicates with a requesting router through > a relay agent, the delegating router may need a protocol or other > out-of-band communication to add routing information for delegated > prefixes into the provider edge router. Absent that protocol or out of band communication, the routing information is not getting into that router. (for bbf it's BNG, for 3gpp it could be AR). Even with a hierarchical distribution model, these allocated prefixes need to appear in the routing table of that AR only if the prefix is allocated, and otherwise be absent from that table. And, one may note that a pure hierarchical model may not be possible for "UE acting as Mobile Router". Such a smartphone MR needs an e.g. /64 for its wifi LAN link and another /64 for its cellular link. One couldn't aggregate a /64 into another, unless of course one uses 64share... (which is of course deemed unnecessary _if_ DHCPv6-PD is used). Alex > > > From ales.vizdal@t-mobile.cz Mon Oct 7 08:58:37 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5ECB321E81BD for ; Mon, 7 Oct 2013 08:58:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.8 X-Spam-Level: X-Spam-Status: No, score=-0.8 tagged_above=-999 required=5 tests=[AWL=0.150, BAYES_00=-2.599, HELO_EQ_CZ=0.445, HOST_EQ_CZ=0.904, MIME_8BIT_HEADER=0.3] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VlC7bkRzthOI for ; Mon, 7 Oct 2013 08:58:32 -0700 (PDT) Received: from ctxmailhub.t-mobile.cz (ctxmailhub.t-mobile.cz [93.153.104.87]) by ietfa.amsl.com (Postfix) with ESMTP id 0115F21E8204 for ; Mon, 7 Oct 2013 08:57:40 -0700 (PDT) Received: from srvhk503.rdm.cz (unknown [10.254.92.81]) by ctxmailhub.t-mobile.cz (Postfix) with ESMTP id B23632E099A; Mon, 7 Oct 2013 17:57:34 +0200 (CEST) Received: from SRVHKE02.rdm.cz ([fe80::94ce:8456:f6fa:86a8]) by srvhk503.rdm.cz ([fe80::a0bc:fdcc:adf9:5f66%12]) with mapi; Mon, 7 Oct 2013 17:57:34 +0200 From: =?iso-8859-2?Q?V=EDzdal_Ale=B9?= To: Alexandru Petrescu , "Rajiv Asati (rajiva)" , Mikael Abrahamsson Date: Mon, 7 Oct 2013 17:57:30 +0200 Thread-Topic: [v6ops] Need ref to 3GPP spec for the use of DHCPv6 Prefix Delegation, e.g. for smartphone tethering Thread-Index: Ac7DafO+kG2X8D9LQjG/R/81jsxwRwACyAvA Message-ID: <1808340F7EC362469DDFFB112B37E2FCD87724529F@SRVHKE02.rdm.cz> References: <5252C5C2.5080706@gmail.com> In-Reply-To: <5252C5C2.5080706@gmail.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="iso-8859-2" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Forwarded Cc: "v6ops@ietf.org" Subject: Re: [v6ops] Need ref to 3GPP spec for the use of DHCPv6 Prefix Delegation, e.g. for smartphone tethering X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 07 Oct 2013 15:58:37 -0000 > -----Original Message----- > From: Alexandru Petrescu [mailto:alexandru.petrescu@gmail.com] > Sent: Monday, October 07, 2013 4:32 PM > To: Rajiv Asati (rajiva); V=EDzdal Ale=B9; Mikael Abrahamsson > Cc: v6ops@ietf.org > Subject: Re: [v6ops] Need ref to 3GPP spec for the use of DHCPv6 Prefix D= elegation, > e.g. for smartphone tethering >=20 > Le 07/10/2013 16:12, Rajiv Asati (rajiva) a =E9crit : > > > >> PS: the BroadBand's problem at Relay during Prefix Delegation is > >> described in technical report titled "IPv6 in the context of TR-101", > >> dated November 2010 as: > >>> "hosts receiving IPv6 addresses from the RR are not known to the > >>> BNG, i.e. the BNG is not aware of what addresses/prefixes are > >>> assigned to hosts attached to the RG acting as RR." > > > > We may be getting off-topic here, but why is the above deemed as a > > problem? It is a hierarchical distribution model after all. >=20 > Not trying to get off-topic. This is a DHC discussion. >=20 > BAsically it all starts at section 14 "Relay Agent Behaviour" of RFC > 3633 DHCPv6-PD which says this: > > If a delegating router communicates with a requesting router through > > a relay agent, the delegating router may need a protocol or other > > out-of-band communication to add routing information for delegated > > prefixes into the provider edge router. >=20 > Absent that protocol or out of band communication, the routing informatio= n is not > getting into that router. >=20 > (for bbf it's BNG, for 3gpp it could be AR). >=20 > Even with a hierarchical distribution model, these allocated prefixes nee= d to appear in > the routing table of that AR only if the prefix is allocated, and otherwi= se be absent > from that table. >=20 > And, one may note that a pure hierarchical model may not be possible for = "UE acting as > Mobile Router". Such a smartphone MR needs an e.g. /64 for its wifi LAN = link and > another /64 for its cellular link. One couldn't aggregate a /64 into an= other, unless of > course one uses 64share... (which is of course deemed unnecessary _if_ DH= CPv6-PD is > used). There are no relays in the 3GPP case. The UE can either be assigned a /64 o= r a shorter prefix using DHCP-PD. In case the mobile router is multihomed it needs to d= o source based routing or any other magic to deal with it. > Alex Ales From alexandru.petrescu@gmail.com Mon Oct 7 09:10:35 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 531CB21E80BC for ; Mon, 7 Oct 2013 09:10:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.991 X-Spam-Level: X-Spam-Status: No, score=-9.991 tagged_above=-999 required=5 tests=[AWL=-0.042, BAYES_00=-2.599, HELO_EQ_FR=0.35, MIME_8BIT_HEADER=0.3, 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 T2U3qhumJoAz for ; Mon, 7 Oct 2013 09:10:29 -0700 (PDT) Received: from sainfoin-out.extra.cea.fr (sainfoin-out.extra.cea.fr [132.167.192.145]) by ietfa.amsl.com (Postfix) with ESMTP id 80D4F21E8093 for ; Mon, 7 Oct 2013 09:10:28 -0700 (PDT) Received: from pisaure.intra.cea.fr (pisaure.intra.cea.fr [132.166.88.21]) by sainfoin.extra.cea.fr (8.14.2/8.14.2/CEAnet-Internet-out-2.3) with ESMTP id r97GAOtH026775 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Mon, 7 Oct 2013 18:10:24 +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 r97GAOwg013102; Mon, 7 Oct 2013 18:10:24 +0200 (envelope-from alexandru.petrescu@gmail.com) Received: from [127.0.0.1] (is010446-4.intra.cea.fr [10.8.33.116]) by muguet1.intra.cea.fr (8.13.8/8.13.8/CEAnet-Intranet-out-1.2) with ESMTP id r97GAN0c017467; Mon, 7 Oct 2013 18:10:24 +0200 Message-ID: <5252DCEF.6030705@gmail.com> Date: Mon, 07 Oct 2013 18:10:23 +0200 From: Alexandru Petrescu User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:24.0) Gecko/20100101 Thunderbird/24.0 MIME-Version: 1.0 To: =?ISO-8859-2?Q?V=EDzdal_Ale=B9?= , "Rajiv Asati (rajiva)" , Mikael Abrahamsson References: <5252C5C2.5080706@gmail.com> <1808340F7EC362469DDFFB112B37E2FCD87724529F@SRVHKE02.rdm.cz> In-Reply-To: <1808340F7EC362469DDFFB112B37E2FCD87724529F@SRVHKE02.rdm.cz> Content-Type: text/plain; charset=ISO-8859-2; format=flowed Content-Transfer-Encoding: 8bit Cc: "v6ops@ietf.org" Subject: Re: [v6ops] Need ref to 3GPP spec for the use of DHCPv6 Prefix Delegation, e.g. for smartphone tethering X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 07 Oct 2013 16:10:35 -0000 Le 07/10/2013 17:57, Vízdal Aleš a écrit : >> -----Original Message----- From: Alexandru Petrescu >> [mailto:alexandru.petrescu@gmail.com] Sent: Monday, October 07, >> 2013 4:32 PM To: Rajiv Asati (rajiva); Vízdal Aleš; Mikael >> Abrahamsson Cc: v6ops@ietf.org Subject: Re: [v6ops] Need ref to >> 3GPP spec for the use of DHCPv6 Prefix Delegation, e.g. for >> smartphone tethering >> >> Le 07/10/2013 16:12, Rajiv Asati (rajiva) a écrit : >>> >>>> PS: the BroadBand's problem at Relay during Prefix Delegation >>>> is described in technical report titled "IPv6 in the context >>>> of TR-101", dated November 2010 as: >>>>> "hosts receiving IPv6 addresses from the RR are not known to >>>>> the BNG, i.e. the BNG is not aware of what >>>>> addresses/prefixes are assigned to hosts attached to the RG >>>>> acting as RR." >>> >>> We may be getting off-topic here, but why is the above deemed as >>> a problem? It is a hierarchical distribution model after all. >> >> Not trying to get off-topic. This is a DHC discussion. >> >> BAsically it all starts at section 14 "Relay Agent Behaviour" of >> RFC 3633 DHCPv6-PD which says this: >>> If a delegating router communicates with a requesting router >>> through a relay agent, the delegating router may need a protocol >>> or other out-of-band communication to add routing information >>> for delegated prefixes into the provider edge router. >> >> Absent that protocol or out of band communication, the routing >> information is not getting into that router. >> >> (for bbf it's BNG, for 3gpp it could be AR). >> >> Even with a hierarchical distribution model, these allocated >> prefixes need to appear in the routing table of that AR only if >> the prefix is allocated, and otherwise be absent from that table. >> >> And, one may note that a pure hierarchical model may not be >> possible for "UE acting as Mobile Router". Such a smartphone MR >> needs an e.g. /64 for its wifi LAN link and another /64 for its >> cellular link. One couldn't aggregate a /64 into another, unless >> of course one uses 64share... (which is of course deemed >> unnecessary _if_ DHCPv6-PD is used). > > There are no relays in the 3GPP case. There may be a misunderstanding here, because that 3gpp spec seems to mention Relay several times... like the Serving GW being the Relay and the PDN GW being the Server. > The UE can either be assigned a /64 or a shorter prefix using > DHCP-PD. In case the mobile router is multihomed it needs to do > source based routing or any other magic to deal with it. (ok, but I didnt mean multihomed mobile router, I meand a mobile router with a cellular interface towards the 3gpp network and a wifi interface towards that person's PAN devices). Alex > >> Alex > > Ales > > From ales.vizdal@t-mobile.cz Mon Oct 7 09:20:07 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1EAC511E80E4 for ; Mon, 7 Oct 2013 09:20:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.85 X-Spam-Level: X-Spam-Status: No, score=-0.85 tagged_above=-999 required=5 tests=[AWL=0.100, BAYES_00=-2.599, HELO_EQ_CZ=0.445, HOST_EQ_CZ=0.904, MIME_8BIT_HEADER=0.3] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id O5+jYYl-N14L for ; Mon, 7 Oct 2013 09:20:01 -0700 (PDT) Received: from ctxmailhub.t-mobile.cz (ctxmailhub.t-mobile.cz [93.153.104.87]) by ietfa.amsl.com (Postfix) with ESMTP id 2C64A21E81A6 for ; Mon, 7 Oct 2013 09:19:21 -0700 (PDT) Received: from srvhk503.rdm.cz (unknown [10.254.92.81]) by ctxmailhub.t-mobile.cz (Postfix) with ESMTP id B77952E06A1; Mon, 7 Oct 2013 18:19:11 +0200 (CEST) Received: from SRVHKE02.rdm.cz ([fe80::94ce:8456:f6fa:86a8]) by srvhk503.rdm.cz ([fe80::a0bc:fdcc:adf9:5f66%12]) with mapi; Mon, 7 Oct 2013 18:19:11 +0200 From: =?iso-8859-2?Q?V=EDzdal_Ale=B9?= To: Alexandru Petrescu , "Rajiv Asati (rajiva)" , Mikael Abrahamsson Date: Mon, 7 Oct 2013 18:19:09 +0200 Thread-Topic: [v6ops] Need ref to 3GPP spec for the use of DHCPv6 Prefix Delegation, e.g. for smartphone tethering Thread-Index: Ac7Dd8KFe+PcYzqvRzq7HUAr1KPXOgAAHj4w Message-ID: <1808340F7EC362469DDFFB112B37E2FCD87724530A@SRVHKE02.rdm.cz> References: <5252C5C2.5080706@gmail.com> <1808340F7EC362469DDFFB112B37E2FCD87724529F@SRVHKE02.rdm.cz> <5252DCEF.6030705@gmail.com> In-Reply-To: <5252DCEF.6030705@gmail.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="iso-8859-2" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Forwarded Cc: "v6ops@ietf.org" Subject: Re: [v6ops] Need ref to 3GPP spec for the use of DHCPv6 Prefix Delegation, e.g. for smartphone tethering X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 07 Oct 2013 16:20:07 -0000 > > There are no relays in the 3GPP case. >=20 > There may be a misunderstanding here, because that 3gpp spec seems to men= tion > Relay several times... like the Serving GW being the Relay and the PDN GW= being the > Server. Hmm there is one ... as the TS 24.302 mentioned earlier is 'Architecture en= hancements for non-3GPP accesses' and there is another one TS 24.301 talking about the 3GPP access and that's= the one I believe you're looking for. http://www.3gpp.org/ftp/Specs/html-info/23401.htm (5.3.1.2.6 IPv6 Prefix De= legation via DHCPv6) Ales From alexandru.petrescu@gmail.com Mon Oct 7 09:51:19 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A3B0311E80FC for ; Mon, 7 Oct 2013 09:51:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.986 X-Spam-Level: X-Spam-Status: No, score=-9.986 tagged_above=-999 required=5 tests=[AWL=-0.037, BAYES_00=-2.599, HELO_EQ_FR=0.35, MIME_8BIT_HEADER=0.3, 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 AGsgcJXq+pNK for ; Mon, 7 Oct 2013 09:51:14 -0700 (PDT) Received: from sainfoin-out.extra.cea.fr (sainfoin-out.extra.cea.fr [132.167.192.145]) by ietfa.amsl.com (Postfix) with ESMTP id DD04B11E80FD for ; Mon, 7 Oct 2013 09:51:00 -0700 (PDT) Received: from pisaure.intra.cea.fr (pisaure.intra.cea.fr [132.166.88.21]) by sainfoin.extra.cea.fr (8.14.2/8.14.2/CEAnet-Internet-out-2.3) with ESMTP id r97GowRs010498 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Mon, 7 Oct 2013 18:50:58 +0200 Received: from muguet1.intra.cea.fr (muguet1.intra.cea.fr [132.166.192.6]) by pisaure.intra.cea.fr (8.14.4/8.14.4) with ESMTP id r97GovDM022417; Mon, 7 Oct 2013 18:50:57 +0200 (envelope-from alexandru.petrescu@gmail.com) Received: from [127.0.0.1] (is010446-4.intra.cea.fr [10.8.33.116]) by muguet1.intra.cea.fr (8.13.8/8.13.8/CEAnet-Intranet-out-1.2) with ESMTP id r97GorQG000796; Mon, 7 Oct 2013 18:50:57 +0200 Message-ID: <5252E66D.3080005@gmail.com> Date: Mon, 07 Oct 2013 18:50:53 +0200 From: Alexandru Petrescu User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:24.0) Gecko/20100101 Thunderbird/24.0 MIME-Version: 1.0 To: =?ISO-8859-2?Q?V=EDzdal_Ale=B9?= , "Rajiv Asati (rajiva)" , Mikael Abrahamsson References: <5252C5C2.5080706@gmail.com> <1808340F7EC362469DDFFB112B37E2FCD87724529F@SRVHKE02.rdm.cz> <5252DCEF.6030705@gmail.com> <1808340F7EC362469DDFFB112B37E2FCD87724530A@SRVHKE02.rdm.cz> In-Reply-To: <1808340F7EC362469DDFFB112B37E2FCD87724530A@SRVHKE02.rdm.cz> Content-Type: text/plain; charset=ISO-8859-2; format=flowed Content-Transfer-Encoding: 8bit Cc: "v6ops@ietf.org" Subject: Re: [v6ops] Need ref to 3GPP spec for the use of DHCPv6 Prefix Delegation, e.g. for smartphone tethering X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 07 Oct 2013 16:51:19 -0000 Le 07/10/2013 18:19, Vízdal Aleš a écrit : >>> There are no relays in the 3GPP case. >> >> There may be a misunderstanding here, because that 3gpp spec seems >> to mention Relay several times... like the Serving GW being the >> Relay and the PDN GW being the Server. > > Hmm there is one ... as the TS 24.302 mentioned earlier is > 'Architecture enhancements for non-3GPP accesses' and there is > another one TS 24.301 talking about the 3GPP access and that's the > one I believe you're looking for. > > http://www.3gpp.org/ftp/Specs/html-info/23401.htm (5.3.1.2.6 IPv6 > Prefix Delegation via DHCPv6) Ok I looked at that as well. That section talks that the PDN GW being the DHCP Server. That section does not mention the use of a Relay Agent. However, given the number of intermediary boxes one sees between the UE and the PDN GW in figure 4.2.1-1 (e.g. Serving Gateway, PDN Gateway, more), one could hardly imagine that the UE and the PDN GW are neighbors in terms of IP. I have a doubt about it. BEcause of this doubt, I assume that there is a Relay Agent somewhere between the UE and the PDN GW (DHCP discovery phase would not work without a Relay Agent if the Server were not a neighbor). This may be wrong though... This is why I wonder whether or not 3gpp uses DHCPv6 Relay Agent functionality, or not. Alex > > Ales > > > From gert@space.net Mon Oct 7 10:09:18 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 184EE21E8190 for ; Mon, 7 Oct 2013 10:09:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0HCFIBSQdbbi for ; Mon, 7 Oct 2013 10:09:17 -0700 (PDT) Received: from mobil.space.net (mobil.space.net [IPv6:2001:608:2:81::67]) by ietfa.amsl.com (Postfix) with ESMTP id E45E421F9CC5 for ; Mon, 7 Oct 2013 10:09:16 -0700 (PDT) Received: from mobil.space.net (localhost [127.0.0.1]) by mobil.space.net (Postfix) with ESMTP id 96CF260A17 for ; Mon, 7 Oct 2013 19:09:14 +0200 (CEST) X-SpaceNet-Relay: true Received: from moebius3.space.net (moebius3.Space.Net [IPv6:2001:608:2:2::250]) by mobil.space.net (Postfix) with ESMTPS id 6912760810 for ; Mon, 7 Oct 2013 19:09:14 +0200 (CEST) Received: (qmail 74742 invoked by uid 1007); 7 Oct 2013 19:09:14 +0200 Date: Mon, 7 Oct 2013 19:09:14 +0200 From: Gert Doering To: Alexandru Petrescu Message-ID: <20131007170914.GU65295@Space.Net> References: <5252C5C2.5080706@gmail.com> <1808340F7EC362469DDFFB112B37E2FCD87724529F@SRVHKE02.rdm.cz> <5252DCEF.6030705@gmail.com> <1808340F7EC362469DDFFB112B37E2FCD87724530A@SRVHKE02.rdm.cz> <5252E66D.3080005@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <5252E66D.3080005@gmail.com> X-NCC-RegID: de.space User-Agent: Mutt/1.5.21 (2010-09-15) Cc: "v6ops@ietf.org" Subject: Re: [v6ops] Need ref to 3GPP spec for the use of DHCPv6 Prefix Delegation, e.g. for smartphone tethering X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 07 Oct 2013 17:09:18 -0000 Hi, On Mon, Oct 07, 2013 at 06:50:53PM +0200, Alexandru Petrescu wrote: > This is why I wonder whether or not 3gpp uses DHCPv6 Relay Agent > functionality, or not. This is really an implementation detail on the PE side, as in "it is not relevant to the user side". Of course, if you're using a relay, the relaying router needs to understand what it relays and what the response means - and again, that's an implementation detail the vendor in question needs to solve, nothing particularily confusing about that. Gert Doering -- NetMaster -- have you enabled IPv6 on something today...? SpaceNet AG Vorstand: Sebastian v. Bomhard Joseph-Dollinger-Bogen 14 Aufsichtsratsvors.: A. Grundner-Culemann D-80807 Muenchen HRB: 136055 (AG Muenchen) Tel: +49 (0)89/32356-444 USt-IdNr.: DE813185279 From alexandru.petrescu@gmail.com Mon Oct 7 10:31:32 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C773A11E80F6 for ; Mon, 7 Oct 2013 10:31:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.133 X-Spam-Level: X-Spam-Status: No, score=-10.133 tagged_above=-999 required=5 tests=[AWL=0.116, BAYES_00=-2.599, HELO_EQ_FR=0.35, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4NFhpp7Ritnc for ; Mon, 7 Oct 2013 10:31:26 -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 5112C11E80F2 for ; Mon, 7 Oct 2013 10:31:26 -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.3) with ESMTP id r97HVMKj005326 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Mon, 7 Oct 2013 19:31:22 +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 r97HVL2O030359; Mon, 7 Oct 2013 19:31:21 +0200 (envelope-from alexandru.petrescu@gmail.com) Received: from [127.0.0.1] (is010446-4.intra.cea.fr [10.8.33.116]) by muguet1.intra.cea.fr (8.13.8/8.13.8/CEAnet-Intranet-out-1.2) with ESMTP id r97HVLZ4015177; Mon, 7 Oct 2013 19:31:21 +0200 Message-ID: <5252EFE9.2090008@gmail.com> Date: Mon, 07 Oct 2013 19:31:21 +0200 From: Alexandru Petrescu User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:24.0) Gecko/20100101 Thunderbird/24.0 MIME-Version: 1.0 To: Gert Doering References: <5252C5C2.5080706@gmail.com> <1808340F7EC362469DDFFB112B37E2FCD87724529F@SRVHKE02.rdm.cz> <5252DCEF.6030705@gmail.com> <1808340F7EC362469DDFFB112B37E2FCD87724530A@SRVHKE02.rdm.cz> <5252E66D.3080005@gmail.com> <20131007170914.GU65295@Space.Net> In-Reply-To: <20131007170914.GU65295@Space.Net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Cc: "v6ops@ietf.org" Subject: Re: [v6ops] Need ref to 3GPP spec for the use of DHCPv6 Prefix Delegation, e.g. for smartphone tethering X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 07 Oct 2013 17:31:32 -0000 Le 07/10/2013 19:09, Gert Doering a écrit : > Hi, > > On Mon, Oct 07, 2013 at 06:50:53PM +0200, Alexandru Petrescu wrote: >> This is why I wonder whether or not 3gpp uses DHCPv6 Relay Agent >> functionality, or not. > > This is really an implementation detail on the PE side, as in "it is > not relevant to the user side". Of course, if you're using a relay, > the relaying router needs to understand what it relays and what the > response means - and again, that's an implementation detail the > vendor in question needs to solve, nothing particularily confusing about > that. YEs and no. Indeed it is implementation detail the vendor in question needs to solve. Just that solving it for DHCPv6 Prefix Delegation is going to be more complex than just solving it for DHCPv6 for addresses, as the bbf document presents it. Alex > > Gert Doering > -- NetMaster > From gert@space.net Mon Oct 7 12:17:48 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 79BC711E8123 for ; Mon, 7 Oct 2013 12:17:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4TFuwYNjj3yc for ; Mon, 7 Oct 2013 12:17:47 -0700 (PDT) Received: from mobil.space.net (mobil.space.net [IPv6:2001:608:2:81::67]) by ietfa.amsl.com (Postfix) with ESMTP id 34D5E11E8118 for ; Mon, 7 Oct 2013 12:17:45 -0700 (PDT) Received: from mobil.space.net (localhost [127.0.0.1]) by mobil.space.net (Postfix) with ESMTP id 3B2D060A1A for ; Mon, 7 Oct 2013 21:17:43 +0200 (CEST) X-SpaceNet-Relay: true Received: from moebius3.space.net (moebius3.Space.Net [IPv6:2001:608:2:2::250]) by mobil.space.net (Postfix) with ESMTPS id 22B6460835 for ; Mon, 7 Oct 2013 21:17:43 +0200 (CEST) Received: (qmail 24863 invoked by uid 1007); 7 Oct 2013 21:17:43 +0200 Date: Mon, 7 Oct 2013 21:17:43 +0200 From: Gert Doering To: Alexandru Petrescu Message-ID: <20131007191743.GY65295@Space.Net> References: <5252C5C2.5080706@gmail.com> <1808340F7EC362469DDFFB112B37E2FCD87724529F@SRVHKE02.rdm.cz> <5252DCEF.6030705@gmail.com> <1808340F7EC362469DDFFB112B37E2FCD87724530A@SRVHKE02.rdm.cz> <5252E66D.3080005@gmail.com> <20131007170914.GU65295@Space.Net> <5252EFE9.2090008@gmail.com> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="nXr/ldaYcWq08yut" Content-Disposition: inline In-Reply-To: <5252EFE9.2090008@gmail.com> X-NCC-RegID: de.space User-Agent: Mutt/1.5.21 (2010-09-15) Cc: "v6ops@ietf.org" Subject: Re: [v6ops] Need ref to 3GPP spec for the use of DHCPv6 Prefix Delegation, e.g. for smartphone tethering X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 07 Oct 2013 19:17:48 -0000 --nXr/ldaYcWq08yut Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Hi, On Mon, Oct 07, 2013 at 07:31:21PM +0200, Alexandru Petrescu wrote: > Indeed it is implementation detail the vendor in question needs to solve. >=20 > Just that solving it for DHCPv6 Prefix Delegation is going to be more=20 > complex than just solving it for DHCPv6 for addresses, as the bbf=20 > document presents it. Well, DHCPv6-for-addresses is about as complex if you do it via a relay, and the addresses do not come from a locally assigned pool. DHCPv6-for-addresses is much easier indeed if you only assign for a=20 directly connected multiaccess network (cable, for example...) and do not= =20 have to deal with "ok, assignment has been done, now what addresses need to be stuffed into routing?" But still, I'm not sure what the context is to make a big deal out of=20 it now? Gert Doering -- NetMaster --=20 have you enabled IPv6 on something today...? SpaceNet AG Vorstand: Sebastian v. Bomhard Joseph-Dollinger-Bogen 14 Aufsichtsratsvors.: A. Grundner-Culemann D-80807 Muenchen HRB: 136055 (AG Muenchen) Tel: +49 (0)89/32356-444 USt-IdNr.: DE813185279 --nXr/ldaYcWq08yut Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.15 (FreeBSD) iQCVAwUBUlMI16kuBuNlUUl1AQKPDwQAtrIvzKDBMGW/FHYAlQ63NTJGmWsFf1xo OX3MZi2NXnps1zNjGdk+9yzOA+aqsKx+F/UExbW8KfKob68nL6eOuPkm6Pup9HqP mN9RyvT+ewO8+LBdAIRJDEfeh3ysnoxzngGgCLnlPzpdN6jDw/kg+HJyCq4oy9sb 78XCxomj930= =Dug7 -----END PGP SIGNATURE----- --nXr/ldaYcWq08yut-- From ales.vizdal@t-mobile.cz Mon Oct 7 13:51:35 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6DF0B11E8135 for ; Mon, 7 Oct 2013 13:51:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.875 X-Spam-Level: X-Spam-Status: No, score=-0.875 tagged_above=-999 required=5 tests=[AWL=0.075, BAYES_00=-2.599, HELO_EQ_CZ=0.445, HOST_EQ_CZ=0.904, MIME_8BIT_HEADER=0.3] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Fzn7rAWRisIt for ; Mon, 7 Oct 2013 13:51:31 -0700 (PDT) Received: from ctxmailhub.t-mobile.cz (ctxmailhub.t-mobile.cz [93.153.104.87]) by ietfa.amsl.com (Postfix) with ESMTP id 7D7AF21E81BB for ; Mon, 7 Oct 2013 13:51:28 -0700 (PDT) Received: from srvhk503.rdm.cz (unknown [10.254.92.81]) by ctxmailhub.t-mobile.cz (Postfix) with ESMTP id 98FC52E09A5; Mon, 7 Oct 2013 22:51:26 +0200 (CEST) Received: from SRVHKE02.rdm.cz ([fe80::94ce:8456:f6fa:86a8]) by srvhk503.rdm.cz ([fe80::a0bc:fdcc:adf9:5f66%12]) with mapi; Mon, 7 Oct 2013 22:51:26 +0200 From: =?iso-8859-2?Q?V=EDzdal_Ale=B9?= To: Alexandru Petrescu , "Rajiv Asati (rajiva)" , Mikael Abrahamsson Date: Mon, 7 Oct 2013 22:51:25 +0200 Thread-Topic: [v6ops] Need ref to 3GPP spec for the use of DHCPv6 Prefix Delegation, e.g. for smartphone tethering Thread-Index: Ac7DfWnMnbciGzv/Snu7TDSliyMwewAGyDdw Message-ID: <1808340F7EC362469DDFFB112B37E2FCD87724531C@SRVHKE02.rdm.cz> References: <5252C5C2.5080706@gmail.com> <1808340F7EC362469DDFFB112B37E2FCD87724529F@SRVHKE02.rdm.cz> <5252DCEF.6030705@gmail.com> <1808340F7EC362469DDFFB112B37E2FCD87724530A@SRVHKE02.rdm.cz> <5252E66D.3080005@gmail.com> In-Reply-To: <5252E66D.3080005@gmail.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="iso-8859-2" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Forwarded Cc: "v6ops@ietf.org" Subject: Re: [v6ops] Need ref to 3GPP spec for the use of DHCPv6 Prefix Delegation, e.g. for smartphone tethering X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 07 Oct 2013 20:51:35 -0000 > -----Original Message----- > From: Alexandru Petrescu [mailto:alexandru.petrescu@gmail.com] > Sent: Monday, October 07, 2013 6:51 PM > To: V=EDzdal Ale=B9; Rajiv Asati (rajiva); Mikael Abrahamsson > Cc: v6ops@ietf.org > Subject: Re: [v6ops] Need ref to 3GPP spec for the use of DHCPv6 Prefix D= elegation, > e.g. for smartphone tethering >=20 > Le 07/10/2013 18:19, V=EDzdal Ale=B9 a =E9crit : > >>> There are no relays in the 3GPP case. > >> > >> There may be a misunderstanding here, because that 3gpp spec seems to > >> mention Relay several times... like the Serving GW being the Relay > >> and the PDN GW being the Server. > > > > Hmm there is one ... as the TS 24.302 mentioned earlier is > > 'Architecture enhancements for non-3GPP accesses' and there is another > > one TS 24.301 talking about the 3GPP access and that's the one I > > believe you're looking for. > > > > http://www.3gpp.org/ftp/Specs/html-info/23401.htm (5.3.1.2.6 IPv6 > > Prefix Delegation via DHCPv6) >=20 > Ok I looked at that as well. >=20 > That section talks that the PDN GW being the DHCP Server. >=20 > That section does not mention the use of a Relay Agent. >=20 > However, given the number of intermediary boxes one sees between the UE a= nd the > PDN GW in figure 4.2.1-1 (e.g. Serving Gateway, PDN Gateway, more), one c= ould > hardly imagine that the UE and the PDN GW are neighbors in terms of IP. = I have a > doubt about it. >=20 > BEcause of this doubt, I assume that there is a Relay Agent somewhere bet= ween the > UE and the PDN GW (DHCP discovery phase would not work without a Relay Ag= ent if > the Server were not a neighbor). >=20 > This may be wrong though... The GGSN/PGW is UEs next-hop as the traffic is tunnelled in GTP through all= the intermediate nodes. =20 > This is why I wonder whether or not 3gpp uses DHCPv6 Relay Agent function= ality, or > not. >=20 > Alex >=20 > > > > Ales Ales From leo.liubing@huawei.com Mon Oct 7 20:52:10 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6F05121E8128 for ; Mon, 7 Oct 2013 20:52:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.999 X-Spam-Level: X-Spam-Status: No, score=-5.999 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_13=0.6, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PIH6TimIaO5S for ; Mon, 7 Oct 2013 20:52:05 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) by ietfa.amsl.com (Postfix) with ESMTP id B0B1321E81E7 for ; Mon, 7 Oct 2013 20:52:03 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml203-edg.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id AYR75412; Tue, 08 Oct 2013 03:52:02 +0000 (GMT) Received: from LHREML404-HUB.china.huawei.com (10.201.5.218) by lhreml203-edg.huawei.com (172.18.7.221) with Microsoft SMTP Server (TLS) id 14.3.146.0; Tue, 8 Oct 2013 04:51:30 +0100 Received: from NKGEML404-HUB.china.huawei.com (10.98.56.35) by lhreml404-hub.china.huawei.com (10.201.5.218) with Microsoft SMTP Server (TLS) id 14.3.146.0; Tue, 8 Oct 2013 04:51:58 +0100 Received: from NKGEML506-MBX.china.huawei.com ([169.254.3.141]) by nkgeml404-hub.china.huawei.com ([10.98.56.35]) with mapi id 14.03.0146.000; Tue, 8 Oct 2013 11:51:52 +0800 From: "Liubing (Leo)" To: GangChen , v6ops Thread-Topic: [v6ops] new version is available: draft-ietf-v6ops-nat64-experience-03.txt Thread-Index: AQHOvxgkT3Sr1/wAKEGCtLsRfYzgQZnqNIRw Date: Tue, 8 Oct 2013 03:51:52 +0000 Message-ID: <8AE0F17B87264D4CAC7DE0AA6C406F453D7C7F1B@nkgeml506-mbx.china.huawei.com> References: In-Reply-To: Accept-Language: en-US, zh-CN Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.111.98.132] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Reflected Subject: Re: [v6ops] new version is available: draft-ietf-v6ops-nat64-experience-03.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 Oct 2013 03:52:10 -0000 Hi, all I support this new version. The ULA statement is valuable guide to the real= deployment. B.R. Bing > -----Original Message----- > From: v6ops-bounces@ietf.org [mailto:v6ops-bounces@ietf.org] On Behalf > Of GangChen > Sent: Wednesday, October 02, 2013 10:36 AM > To: v6ops > Subject: [v6ops] new version is available: > draft-ietf-v6ops-nat64-experience-03.txt >=20 > Wg, >=20 > We have just submitted the new version to address the comments during the > WGLC. > The main changes are > 1) Add the ULAs statement to feedback Lorenzo's comments > 2) Add the description of bulk port allocation in Section 5.1 > suggested by Mikael > 3) Add the experience description for geo-location service in Section > 5.2 according to Dan Wing and Mikael comments > 4) Add sub-levels in Section 3.1 and improve the description in > section 3.1.2 to echo Sheng's comments > 5) Polish the entire draft according to the suggestions from > IETF#87"Document Language Editing Session" >=20 > Please kindly check if all comments are addressed in this version. >=20 > Many thanks >=20 > Gang >=20 > 2013/10/2, internet-drafts@ietf.org : > > > > A New Internet-Draft is available from the on-line Internet-Drafts > > directories. > > This draft is a work item of the IPv6 Operations Working Group of the > > IETF. > > > > Title : NAT64 Operational Experiences > > Author(s) : Gang Chen > > Zhen Cao > > Chongfeng Xie > > David Binet > > Filename : draft-ietf-v6ops-nat64-experience-03.txt > > Pages : 20 > > Date : 2013-10-01 > > > > Abstract: > > This document summarizes NAT64 function deployment scenarios and > > operational experience. Both NAT64 Carrier Grade NAT (NAT64-CGN) > and > > NAT64 server Front End (NAT64-FE) are considered in this document. > > > > > > The IETF datatracker status page for this draft is: > > https://datatracker.ietf.org/doc/draft-ietf-v6ops-nat64-experience > > > > There's also a htmlized version available at: > > http://tools.ietf.org/html/draft-ietf-v6ops-nat64-experience-03 > > > > A diff from the previous version is available at: > > http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-v6ops-nat64-experience-03 > > > > > > Please note that it may take a couple of minutes from the time of > > submission > > until the htmlized version and diff are available at tools.ietf.org. > > > > Internet-Drafts are also available by anonymous FTP at: > > ftp://ftp.ietf.org/internet-drafts/ > > > > _______________________________________________ > > v6ops mailing list > > v6ops@ietf.org > > https://www.ietf.org/mailman/listinfo/v6ops > > > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops From alexandru.petrescu@gmail.com Tue Oct 8 00:42:57 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 88F9D21E815A for ; Tue, 8 Oct 2013 00:42:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.843 X-Spam-Level: X-Spam-Status: No, score=-9.843 tagged_above=-999 required=5 tests=[AWL=-0.194, BAYES_00=-2.599, HELO_EQ_FR=0.35, J_CHICKENPOX_13=0.6, 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 47ZIk-5Qpuh5 for ; Tue, 8 Oct 2013 00:42: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 27AB721E8159 for ; Tue, 8 Oct 2013 00:42:48 -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.3) with ESMTP id r987gjfD017653 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Tue, 8 Oct 2013 09:42: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 r987gi4J009203; Tue, 8 Oct 2013 09:42:44 +0200 (envelope-from alexandru.petrescu@gmail.com) Received: from [127.0.0.1] (is010446-4.intra.cea.fr [10.8.33.116]) by muguet1.intra.cea.fr (8.13.8/8.13.8/CEAnet-Intranet-out-1.2) with ESMTP id r987gfSj024587; Tue, 8 Oct 2013 09:42:44 +0200 Message-ID: <5253B771.6060505@gmail.com> Date: Tue, 08 Oct 2013 09:42:41 +0200 From: Alexandru Petrescu User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:24.0) Gecko/20100101 Thunderbird/24.0 MIME-Version: 1.0 To: Gert Doering References: <5252C5C2.5080706@gmail.com> <1808340F7EC362469DDFFB112B37E2FCD87724529F@SRVHKE02.rdm.cz> <5252DCEF.6030705@gmail.com> <1808340F7EC362469DDFFB112B37E2FCD87724530A@SRVHKE02.rdm.cz> <5252E66D.3080005@gmail.com> <20131007170914.GU65295@Space.Net> <5252EFE9.2090008@gmail.com> <20131007191743.GY65295@Space.Net> In-Reply-To: <20131007191743.GY65295@Space.Net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Cc: "v6ops@ietf.org" Subject: Re: [v6ops] Need ref to 3GPP spec for the use of DHCPv6 Prefix Delegation, e.g. for smartphone tethering X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 Oct 2013 07:42:57 -0000 Le 07/10/2013 21:17, Gert Doering a écrit : > Hi, > > On Mon, Oct 07, 2013 at 07:31:21PM +0200, Alexandru Petrescu wrote: >> Indeed it is implementation detail the vendor in question needs to >> solve. >> >> Just that solving it for DHCPv6 Prefix Delegation is going to be >> more complex than just solving it for DHCPv6 for addresses, as the >> bbf document presents it. > > Well, DHCPv6-for-addresses is about as complex if you do it via a > relay, and the addresses do not come from a locally assigned pool. > > DHCPv6-for-addresses is much easier indeed if you only assign for a > directly connected multiaccess network (cable, for example...) and do > not have to deal with "ok, assignment has been done, now what > addresses need to be stuffed into routing?" Right, that is one point. DHCPv6-for-addresses Relay bevaviour considers that the Relay is already preconfigured statically with a single prefix which covers all assigned addresses. There is no need to dynamically insert/remove that prefix upon address assignment. On another hand, DHCPv6-for-prefixes may not consider a single prefix covering (aggregating) all dynamically assigned prefixes. One such case is when the smartphone is assigned one /64 for its ptp link and another /64 for its LAN (one couldn't aggregate one /64 into another). > But still, I'm not sure what the context is to make a big deal out > of it now? No big deal. And yes, it is known since some time. In DHC WG there were many drafts discussing these aspects, since some years. Just that now we spend some time on writing a Problem Statement draft (individual proposal) per AD suggestion. Comments welcome here, because v6ops WG has expertise in the cellular networks IPv6 deployments (note the 64share and related discussions). Alex > > Gert Doering -- NetMaster > From alexandru.petrescu@gmail.com Tue Oct 8 00:45:29 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B368121E8161 for ; Tue, 8 Oct 2013 00:45:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.977 X-Spam-Level: X-Spam-Status: No, score=-9.977 tagged_above=-999 required=5 tests=[AWL=-0.028, BAYES_00=-2.599, HELO_EQ_FR=0.35, MIME_8BIT_HEADER=0.3, 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 Zi44UBJpmxi4 for ; Tue, 8 Oct 2013 00:45: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 E11BE21E8159 for ; Tue, 8 Oct 2013 00:45:21 -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.3) with ESMTP id r987jIr1018915 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Tue, 8 Oct 2013 09:45:18 +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 r987jIMf011026; Tue, 8 Oct 2013 09:45:18 +0200 (envelope-from alexandru.petrescu@gmail.com) Received: from [127.0.0.1] (is010446-4.intra.cea.fr [10.8.33.116]) by muguet1.intra.cea.fr (8.13.8/8.13.8/CEAnet-Intranet-out-1.2) with ESMTP id r987jIPo026763; Tue, 8 Oct 2013 09:45:18 +0200 Message-ID: <5253B80E.7030008@gmail.com> Date: Tue, 08 Oct 2013 09:45:18 +0200 From: Alexandru Petrescu User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:24.0) Gecko/20100101 Thunderbird/24.0 MIME-Version: 1.0 To: =?ISO-8859-2?Q?V=EDzdal_Ale=B9?= , "Rajiv Asati (rajiva)" , Mikael Abrahamsson References: <5252C5C2.5080706@gmail.com> <1808340F7EC362469DDFFB112B37E2FCD87724529F@SRVHKE02.rdm.cz> <5252DCEF.6030705@gmail.com> <1808340F7EC362469DDFFB112B37E2FCD87724530A@SRVHKE02.rdm.cz> <5252E66D.3080005@gmail.com> <1808340F7EC362469DDFFB112B37E2FCD87724531C@SRVHKE02.rdm.cz> In-Reply-To: <1808340F7EC362469DDFFB112B37E2FCD87724531C@SRVHKE02.rdm.cz> Content-Type: text/plain; charset=ISO-8859-2; format=flowed Content-Transfer-Encoding: 8bit Cc: "v6ops@ietf.org" Subject: Re: [v6ops] Need ref to 3GPP spec for the use of DHCPv6 Prefix Delegation, e.g. for smartphone tethering X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 Oct 2013 07:45:29 -0000 Le 07/10/2013 22:51, Vízdal Aleš a écrit : >> -----Original Message----- From: Alexandru Petrescu >> [mailto:alexandru.petrescu@gmail.com] Sent: Monday, October 07, >> 2013 6:51 PM To: Vízdal Aleš; Rajiv Asati (rajiva); Mikael >> Abrahamsson Cc: v6ops@ietf.org Subject: Re: [v6ops] Need ref to >> 3GPP spec for the use of DHCPv6 Prefix Delegation, e.g. for >> smartphone tethering >> >> Le 07/10/2013 18:19, Vízdal Aleš a écrit : >>>>> There are no relays in the 3GPP case. >>>> >>>> There may be a misunderstanding here, because that 3gpp spec >>>> seems to mention Relay several times... like the Serving GW >>>> being the Relay and the PDN GW being the Server. >>> >>> Hmm there is one ... as the TS 24.302 mentioned earlier is >>> 'Architecture enhancements for non-3GPP accesses' and there is >>> another one TS 24.301 talking about the 3GPP access and that's >>> the one I believe you're looking for. >>> >>> http://www.3gpp.org/ftp/Specs/html-info/23401.htm (5.3.1.2.6 >>> IPv6 Prefix Delegation via DHCPv6) >> >> Ok I looked at that as well. >> >> That section talks that the PDN GW being the DHCP Server. >> >> That section does not mention the use of a Relay Agent. >> >> However, given the number of intermediary boxes one sees between >> the UE and the PDN GW in figure 4.2.1-1 (e.g. Serving Gateway, PDN >> Gateway, more), one could hardly imagine that the UE and the PDN GW >> are neighbors in terms of IP. I have a doubt about it. >> >> BEcause of this doubt, I assume that there is a Relay Agent >> somewhere between the UE and the PDN GW (DHCP discovery phase would >> not work without a Relay Agent if the Server were not a neighbor). >> >> This may be wrong though... > > The GGSN/PGW is UEs next-hop as the traffic is tunnelled in GTP > through all the intermediate nodes. Ah, right, there is a GTP tunnel above all the intermediary IP nodes. However, even when a tunnel is dynamically set up, a routing table entry is added in the Relay's routing table (or other similar entry). The parameters of that entry necessarily include, among others, the prefix which is allocated. No? Alex > >> This is why I wonder whether or not 3gpp uses DHCPv6 Relay Agent >> functionality, or not. >> >> Alex >> >>> >>> Ales > > Ales > > From ales.vizdal@t-mobile.cz Tue Oct 8 01:49:24 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6ABB321E8187 for ; Tue, 8 Oct 2013 01:49:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.89 X-Spam-Level: X-Spam-Status: No, score=-0.89 tagged_above=-999 required=5 tests=[AWL=0.060, BAYES_00=-2.599, HELO_EQ_CZ=0.445, HOST_EQ_CZ=0.904, MIME_8BIT_HEADER=0.3] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id N1zF9iw96pRC for ; Tue, 8 Oct 2013 01:49:18 -0700 (PDT) Received: from ctxmailhub.t-mobile.cz (ctxmailhub.t-mobile.cz [93.153.104.87]) by ietfa.amsl.com (Postfix) with ESMTP id 5D4FE21E8185 for ; Tue, 8 Oct 2013 01:49:13 -0700 (PDT) Received: from srvhk504.rdm.cz (unknown [10.254.92.81]) by ctxmailhub.t-mobile.cz (Postfix) with ESMTP id 6AD1A2E09A8; Tue, 8 Oct 2013 10:49:12 +0200 (CEST) Received: from SRVHKE02.rdm.cz ([fe80::94ce:8456:f6fa:86a8]) by srvhk504.rdm.cz ([::1]) with mapi; Tue, 8 Oct 2013 10:49:11 +0200 From: =?iso-8859-2?Q?V=EDzdal_Ale=B9?= To: Alexandru Petrescu , "Rajiv Asati (rajiva)" , Mikael Abrahamsson Date: Tue, 8 Oct 2013 10:49:04 +0200 Thread-Topic: [v6ops] Need ref to 3GPP spec for the use of DHCPv6 Prefix Delegation, e.g. for smartphone tethering Thread-Index: Ac7D+lubGOVDUXZmRxWjznDvEvmbKwABm/ZQ Message-ID: <1808340F7EC362469DDFFB112B37E2FCD877245410@SRVHKE02.rdm.cz> References: <5252C5C2.5080706@gmail.com> <1808340F7EC362469DDFFB112B37E2FCD87724529F@SRVHKE02.rdm.cz> <5252DCEF.6030705@gmail.com> <1808340F7EC362469DDFFB112B37E2FCD87724530A@SRVHKE02.rdm.cz> <5252E66D.3080005@gmail.com> <1808340F7EC362469DDFFB112B37E2FCD87724531C@SRVHKE02.rdm.cz> <5253B80E.7030008@gmail.com> In-Reply-To: <5253B80E.7030008@gmail.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="iso-8859-2" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Forwarded Cc: "v6ops@ietf.org" Subject: Re: [v6ops] Need ref to 3GPP spec for the use of DHCPv6 Prefix Delegation, e.g. for smartphone tethering X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 Oct 2013 08:49:24 -0000 > > The GGSN/PGW is UEs next-hop as the traffic is tunnelled in GTP > > through all the intermediate nodes. >=20 > Ah, right, there is a GTP tunnel above all the intermediary IP nodes. >=20 > However, even when a tunnel is dynamically set up, a routing table entry = is added in > the Relay's routing table (or other similar entry). The parameters of th= at entry > necessarily include, among others, the prefix which is allocated. >=20 > No? The tunnel stays up for the lifetime of the PDP/PDN context. There is no re= lay in the 3GPP access architecture. If the tunnel drops the PGW/GGSN will remove the route from t= heir routing table, once a new tunnel is setup the routing table is updated accordingly. > Alex Ales From alexandru.petrescu@gmail.com Tue Oct 8 01:56:01 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0595621E818E for ; Tue, 8 Oct 2013 01:56:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.975 X-Spam-Level: X-Spam-Status: No, score=-9.975 tagged_above=-999 required=5 tests=[AWL=-0.026, BAYES_00=-2.599, HELO_EQ_FR=0.35, MIME_8BIT_HEADER=0.3, 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 LqcuyLEk0UnV for ; Tue, 8 Oct 2013 01:55:54 -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 9F76F21E8169 for ; Tue, 8 Oct 2013 01:55:53 -0700 (PDT) Received: from pisaure.intra.cea.fr (pisaure.intra.cea.fr [132.166.88.21]) by cirse.extra.cea.fr (8.14.2/8.14.2/CEAnet-Internet-out-2.3) with ESMTP id r988tn6L011642 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Tue, 8 Oct 2013 10:55:49 +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 r988tnTo020540; Tue, 8 Oct 2013 10:55:49 +0200 (envelope-from alexandru.petrescu@gmail.com) Received: from [127.0.0.1] (is010446-4.intra.cea.fr [10.8.33.116]) by muguet2.intra.cea.fr (8.13.8/8.13.8/CEAnet-Intranet-out-1.2) with ESMTP id r988tj8f011992; Tue, 8 Oct 2013 10:55:49 +0200 Message-ID: <5253C891.7090009@gmail.com> Date: Tue, 08 Oct 2013 10:55:45 +0200 From: Alexandru Petrescu User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:24.0) Gecko/20100101 Thunderbird/24.0 MIME-Version: 1.0 To: =?ISO-8859-2?Q?V=EDzdal_Ale=B9?= , "Rajiv Asati (rajiva)" , Mikael Abrahamsson References: <5252C5C2.5080706@gmail.com> <1808340F7EC362469DDFFB112B37E2FCD87724529F@SRVHKE02.rdm.cz> <5252DCEF.6030705@gmail.com> <1808340F7EC362469DDFFB112B37E2FCD87724530A@SRVHKE02.rdm.cz> <5252E66D.3080005@gmail.com> <1808340F7EC362469DDFFB112B37E2FCD87724531C@SRVHKE02.rdm.cz> <5253B80E.7030008@gmail.com> <1808340F7EC362469DDFFB112B37E2FCD877245410@SRVHKE02.rdm.cz> In-Reply-To: <1808340F7EC362469DDFFB112B37E2FCD877245410@SRVHKE02.rdm.cz> Content-Type: text/plain; charset=ISO-8859-2; format=flowed Content-Transfer-Encoding: 8bit Cc: "v6ops@ietf.org" Subject: Re: [v6ops] Need ref to 3GPP spec for the use of DHCPv6 Prefix Delegation, e.g. for smartphone tethering X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 Oct 2013 08:56:01 -0000 Le 08/10/2013 10:49, Vízdal Aleš a écrit : >>> The GGSN/PGW is UEs next-hop as the traffic is tunnelled in GTP >>> through all the intermediate nodes. >> >> Ah, right, there is a GTP tunnel above all the intermediary IP >> nodes. >> >> However, even when a tunnel is dynamically set up, a routing table >> entry is added in the Relay's routing table (or other similar >> entry). The parameters of that entry necessarily include, among >> others, the prefix which is allocated. >> >> No? > > The tunnel stays up for the lifetime of the PDP/PDN context. Ok. > There is no relay in the 3GPP access architecture. Ok. > If the tunnel drops, the PGW/GGSN will remove the route from their > routing table, once a new tunnel is setup the routing table is > updated accordingly. The route associated with that tunnel should contain a parameter containing the Delegated Prefix. When there is no delegated prefix, that route entry should be updated. The tunnel could stay up but only for the Smartphone. Or it could stay up for both the Smartphone _and_ the Hosts in the smartphone's LAN. These are two different things. Alex > >> Alex > > Ales > > From ales.vizdal@t-mobile.cz Tue Oct 8 02:00:31 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6A39021E819D for ; Tue, 8 Oct 2013 02:00:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.9 X-Spam-Level: X-Spam-Status: No, score=-0.9 tagged_above=-999 required=5 tests=[AWL=0.050, BAYES_00=-2.599, HELO_EQ_CZ=0.445, HOST_EQ_CZ=0.904, MIME_8BIT_HEADER=0.3] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yXvIyRNdww5Z for ; Tue, 8 Oct 2013 02:00:26 -0700 (PDT) Received: from ctxmailhub.t-mobile.cz (ctxmailhub.t-mobile.cz [93.153.104.87]) by ietfa.amsl.com (Postfix) with ESMTP id 478FC21E8166 for ; Tue, 8 Oct 2013 02:00:26 -0700 (PDT) Received: from srvhk504.rdm.cz (unknown [10.254.92.81]) by ctxmailhub.t-mobile.cz (Postfix) with ESMTP id 9B5E52E09D3; Tue, 8 Oct 2013 11:00:25 +0200 (CEST) Received: from SRVHKE02.rdm.cz ([fe80::94ce:8456:f6fa:86a8]) by srvhk504.rdm.cz ([::1]) with mapi; Tue, 8 Oct 2013 11:00:25 +0200 From: =?iso-8859-2?Q?V=EDzdal_Ale=B9?= To: Alexandru Petrescu , "Rajiv Asati (rajiva)" , Mikael Abrahamsson Date: Tue, 8 Oct 2013 11:00:23 +0200 Thread-Topic: [v6ops] Need ref to 3GPP spec for the use of DHCPv6 Prefix Delegation, e.g. for smartphone tethering Thread-Index: Ac7EBDQAkhn/wf8OQd+7dsT1jAnQuQAABhbQ Message-ID: <1808340F7EC362469DDFFB112B37E2FCD87724542A@SRVHKE02.rdm.cz> References: <5252C5C2.5080706@gmail.com> <1808340F7EC362469DDFFB112B37E2FCD87724529F@SRVHKE02.rdm.cz> <5252DCEF.6030705@gmail.com> <1808340F7EC362469DDFFB112B37E2FCD87724530A@SRVHKE02.rdm.cz> <5252E66D.3080005@gmail.com> <1808340F7EC362469DDFFB112B37E2FCD87724531C@SRVHKE02.rdm.cz> <5253B80E.7030008@gmail.com> <1808340F7EC362469DDFFB112B37E2FCD877245410@SRVHKE02.rdm.cz> <5253C891.7090009@gmail.com> In-Reply-To: <5253C891.7090009@gmail.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="iso-8859-2" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Forwarded Cc: "v6ops@ietf.org" Subject: Re: [v6ops] Need ref to 3GPP spec for the use of DHCPv6 Prefix Delegation, e.g. for smartphone tethering X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 Oct 2013 09:00:31 -0000 > > If the tunnel drops, the PGW/GGSN will remove the route from their > > routing table, once a new tunnel is setup the routing table is updated > > accordingly. >=20 > The route associated with that tunnel should contain a parameter containi= ng the > Delegated Prefix. When there is no delegated prefix, that route entry sh= ould be > updated. >=20 > The tunnel could stay up but only for the Smartphone. Or it could stay u= p for both the > Smartphone _and_ the Hosts in the smartphone's LAN. > These are two different things. There is only one GTP tunnel and there is only one route as both the GGSN/P= GW to UE prefix (/64) and the delegated prefix route must be aggregateable. Check th= e specs ;-) or take this one offline. > Alex >=20 >=20 > > > >> Alex Ales From lorenzo@google.com Tue Oct 8 02:06:53 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 269E621E8166 for ; Tue, 8 Oct 2013 02:06:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.677 X-Spam-Level: X-Spam-Status: No, score=-1.677 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, J_CHICKENPOX_13=0.6, 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 AWdl86PhwP61 for ; Tue, 8 Oct 2013 02:06:51 -0700 (PDT) Received: from mail-ie0-x235.google.com (mail-ie0-x235.google.com [IPv6:2607:f8b0:4001:c03::235]) by ietfa.amsl.com (Postfix) with ESMTP id 593D921E8188 for ; Tue, 8 Oct 2013 02:06:41 -0700 (PDT) Received: by mail-ie0-f181.google.com with SMTP id tp5so17843146ieb.26 for ; Tue, 08 Oct 2013 02:06:41 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=GEaKz5Wk4GIxKHCJcE32UcFXrFFBG9ZXAsp+MCg5yDM=; b=e9vTdNvrSl4j67xfWXLl1nCkl7DDvEuva6Ndx4AV0dfesblT+PS2VppRm5Wou1oNHz 5oiQInutYjyMdrpp9ms5LdVI3tsIpqF2xAGvkH9cdHd9hMbnAb135vQ0LTISb+nPv5Kp B44vl7KWhimfQxzBCtAZAxPpSkJiP6z+1wHmLacCMYAjYgGxAJdEbMGWlem1xFLVimcm MJS92IwWKoBqlSYZ1n1CxJ6ChfhiU1VJPqcfHmqGpbTskvURs+CcX4rifckYr9qdGARs JypZIcueMSwOldIAz1xj00TF71FGxlTXDYPuwIWSgbZayP84feTg1tTrTPTrfkkbJ97c J7jg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type; bh=GEaKz5Wk4GIxKHCJcE32UcFXrFFBG9ZXAsp+MCg5yDM=; b=k31+2uuWsibBQHJl1USXXalDUCcMuFIxUSpyEiZoRJNCXjF6qWPOQZMEGkdxTQNsTx nHpb+oQWPV/LJBaMPfawSxrW9Tf+alx8FBxser6bwRHwlRtaH/+DqdU5T9QJu9Es7HMp S27rzOZUiS6BnxFf9s77i63vFD3iMoXYrz4YdXhUT0N2l9KCWABtrwEy9FCQ08fAQXqZ jsvl0ucHgSiEGwG45nIq/RmkUJ+m02zM0YEZdIBxcSmSHIEiQsiNm5M+yWHxIYWnBVBB /gV2CN0Wn+rqjFB9VAoVKTBVVwOhCJihrHwIviMNxeUW3RwH4GJPptIQCVHq3EWM4AT8 RFkg== X-Gm-Message-State: ALoCoQl9Dq8ITzvfJ3mme9C6exk4IIM7XjDnufkON4SfRPj3c+s/RTGMbmv2OhMM2syF0ipnM/SnLdcLQs+AcRtJdZ4Bx+V6PgIlaZU1HQ3AWnsq3b+hM2A7/L/5arVyTNlgrKQfkjO4aZdXeM4zKfV/Fo3gFcJush5/n/RJAPh1K2Nn7jp7YiT0fuyKT763aazivAzoi3LF X-Received: by 10.50.119.68 with SMTP id ks4mr1236237igb.6.1381223200962; Tue, 08 Oct 2013 02:06:40 -0700 (PDT) MIME-Version: 1.0 Received: by 10.64.86.106 with HTTP; Tue, 8 Oct 2013 02:06:20 -0700 (PDT) In-Reply-To: <8AE0F17B87264D4CAC7DE0AA6C406F453D7C7F1B@nkgeml506-mbx.china.huawei.com> References: <8AE0F17B87264D4CAC7DE0AA6C406F453D7C7F1B@nkgeml506-mbx.china.huawei.com> From: Lorenzo Colitti Date: Tue, 8 Oct 2013 18:06:20 +0900 Message-ID: To: "Liubing (Leo)" Content-Type: multipart/alternative; boundary=e89a8f64317a3fe9fa04e8371671 Cc: v6ops Subject: Re: [v6ops] new version is available: draft-ietf-v6ops-nat64-experience-03.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 Oct 2013 09:06:53 -0000 --e89a8f64317a3fe9fa04e8371671 Content-Type: text/plain; charset=ISO-8859-1 Comments on the ULA section only: 1. Please do not cite RFC 3484 anywhere. It is obsolete and thus irrelevant; hosts that implement it are not compliant with current IETF standards. Instead, say that compliant host implementations will never prefer ULA over IPv4. The logical conclusion is to say that ULA addresses are not recommended for use on a NAT64-CGN, because they will never be used. 2. Don't cite RFC 6555, it has nothing to do with issuing both A and AAAA DNS requests. Issuing both an AAAA lookup and an A lookup is standard for RFC 6724 implementations that have both IPv4 and IPv6 addresses. On Tue, Oct 8, 2013 at 12:51 PM, Liubing (Leo) wrote: > Hi, all > > I support this new version. The ULA statement is valuable guide to the > real deployment. > > B.R. > Bing > > > -----Original Message----- > > From: v6ops-bounces@ietf.org [mailto:v6ops-bounces@ietf.org] On Behalf > > Of GangChen > > Sent: Wednesday, October 02, 2013 10:36 AM > > To: v6ops > > Subject: [v6ops] new version is available: > > draft-ietf-v6ops-nat64-experience-03.txt > > > > Wg, > > > > We have just submitted the new version to address the comments during the > > WGLC. > > The main changes are > > 1) Add the ULAs statement to feedback Lorenzo's comments > > 2) Add the description of bulk port allocation in Section 5.1 > > suggested by Mikael > > 3) Add the experience description for geo-location service in Section > > 5.2 according to Dan Wing and Mikael comments > > 4) Add sub-levels in Section 3.1 and improve the description in > > section 3.1.2 to echo Sheng's comments > > 5) Polish the entire draft according to the suggestions from > > IETF#87"Document Language Editing Session" > > > > Please kindly check if all comments are addressed in this version. > > > > Many thanks > > > > Gang > > > > 2013/10/2, internet-drafts@ietf.org : > > > > > > A New Internet-Draft is available from the on-line Internet-Drafts > > > directories. > > > This draft is a work item of the IPv6 Operations Working Group of the > > > IETF. > > > > > > Title : NAT64 Operational Experiences > > > Author(s) : Gang Chen > > > Zhen Cao > > > Chongfeng Xie > > > David Binet > > > Filename : draft-ietf-v6ops-nat64-experience-03.txt > > > Pages : 20 > > > Date : 2013-10-01 > > > > > > Abstract: > > > This document summarizes NAT64 function deployment scenarios and > > > operational experience. Both NAT64 Carrier Grade NAT (NAT64-CGN) > > and > > > NAT64 server Front End (NAT64-FE) are considered in this document. > > > > > > > > > The IETF datatracker status page for this draft is: > > > https://datatracker.ietf.org/doc/draft-ietf-v6ops-nat64-experience > > > > > > There's also a htmlized version available at: > > > http://tools.ietf.org/html/draft-ietf-v6ops-nat64-experience-03 > > > > > > A diff from the previous version is available at: > > > http://www.ietf.org/rfcdiff?url2=draft-ietf-v6ops-nat64-experience-03 > > > > > > > > > Please note that it may take a couple of minutes from the time of > > > submission > > > until the htmlized version and diff are available at tools.ietf.org. > > > > > > Internet-Drafts are also available by anonymous FTP at: > > > ftp://ftp.ietf.org/internet-drafts/ > > > > > > _______________________________________________ > > > v6ops mailing list > > > v6ops@ietf.org > > > https://www.ietf.org/mailman/listinfo/v6ops > > > > > _______________________________________________ > > v6ops mailing list > > v6ops@ietf.org > > https://www.ietf.org/mailman/listinfo/v6ops > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops > --e89a8f64317a3fe9fa04e8371671 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Comments on the ULA section only:

1. Pl= ease do not cite RFC 3484 anywhere. It is obsolete and thus irrelevant; hos= ts that implement it are not compliant with current IETF standards. Instead= , say that compliant host implementations will never prefer ULA over IPv4. = The logical conclusion is to say that ULA addresses are not recommended for= use on a NAT64-CGN, because they will never be used.

2. Don't cite RFC 6555, it has nothing to do w= ith issuing both A and AAAA DNS requests. Issuing both an AAAA lookup and a= n A lookup is standard for RFC 6724 implementations that have both IPv4 and= IPv6 addresses.


O= n Tue, Oct 8, 2013 at 12:51 PM, Liubing (Leo) <leo.liubing@huawei.com= > wrote:
Hi, all

I support this new version. The ULA statement is valuable guide to the real= deployment.

B.R.
Bing

> -----Original Message-----
> From: v6ops-bounces@ietf.org= [mailto:v6ops-bounces@ietf.o= rg] On Behalf
> Of GangChen
> Sent: Wednesday, October 02, 2013 10:36 AM
> To: v6ops
> Subject: [v6ops] new version is available:
> draft-ietf-v6ops-nat64-experience-03.txt
>
> Wg,
>
> We have just submitted the new version to address the comments during = the
> WGLC.
> The main changes are
> 1) Add the ULAs statement to feedback Lorenzo's comments
> 2) Add the description of bulk port allocation in Section 5.1
> suggested by Mikael
> 3) Add the experience description for geo-location service in Section<= br> > 5.2 according to Dan Wing and Mikael comments
> 4) Add sub-levels in Section 3.1 and improve the description in
> section 3.1.2 to echo Sheng's comments
> 5) Polish the entire draft according to the suggestions from
> IETF#87"Document Language Editing Session"
>
> Please kindly check if all comments are addressed in this version.
>
> Many thanks
>
> Gang
>
> 2013/10/2, internet-drafts= @ietf.org <internet-draf= ts@ietf.org>:
> >
> > A New Internet-Draft is available from the on-line Internet-Draft= s
> > directories.
> > =A0This draft is a work item of the IPv6 Operations Working Group= of the
> > IETF.
> >
> > =A0 =A0 Title =A0 =A0 =A0 =A0 =A0 : NAT64 Operational Experiences=
> > =A0 =A0 Author(s) =A0 =A0 =A0 : Gang Chen
> > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 Zhen Cao
> > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 Chongfeng Xie=
> > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 David Binet > > =A0 =A0 Filename =A0 =A0 =A0 =A0: draft-ietf-v6ops-nat64-experien= ce-03.txt
> > =A0 =A0 Pages =A0 =A0 =A0 =A0 =A0 : 20
> > =A0 =A0 Date =A0 =A0 =A0 =A0 =A0 =A0: 2013-10-01
> >
> > Abstract:
> > =A0 =A0This document summarizes NAT64 function deployment scenari= os and
> > =A0 =A0operational experience. =A0Both NAT64 Carrier Grade NAT (N= AT64-CGN)
> and
> > =A0 =A0NAT64 server Front End (NAT64-FE) are considered in this d= ocument.
> >
> >
> > The IETF datatracker status page for this draft is:
> > https://datatracker.ietf.org/doc/draft-ietf= -v6ops-nat64-experience
> >
> > There's also a htmlized version available at:
> > http://tools.ietf.org/html/draft-ietf-v6ops-na= t64-experience-03
> >
> > A diff from the previous version is available at:
> > http://www.ietf.org/rfcdiff?url2=3Ddra= ft-ietf-v6ops-nat64-experience-03
> >
> >
> > Please note that it may take a couple of minutes from the time of=
> > submission
> > until the htmlized version and diff are available at tools.ietf.org.
> >
> > Internet-Drafts are also available by anonymous FTP at:
> > ftp://ftp.ietf.org/internet-drafts/
> >
> > _______________________________________________
> > v6ops mailing list
> > v6ops@ietf.org
> > https://www.ietf.org/mailman/listinfo/v6ops
> >
> _______________________________________________
> v6ops mailing list
> v6ops@ietf.org
> https://www.ietf.org/mailman/listinfo/v6ops
_______________________________________________
v6ops mailing list
v6ops@ietf.org
h= ttps://www.ietf.org/mailman/listinfo/v6ops

--e89a8f64317a3fe9fa04e8371671-- From phdgang@gmail.com Tue Oct 8 03:04:52 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D866421E8196 for ; Tue, 8 Oct 2013 03:04:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_13=0.6, 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 2mx03DXcA6zI for ; Tue, 8 Oct 2013 03:04:52 -0700 (PDT) Received: from mail-qe0-x22b.google.com (mail-qe0-x22b.google.com [IPv6:2607:f8b0:400d:c02::22b]) by ietfa.amsl.com (Postfix) with ESMTP id 0432011E8190 for ; Tue, 8 Oct 2013 03:04:46 -0700 (PDT) Received: by mail-qe0-f43.google.com with SMTP id nc12so1415908qeb.30 for ; Tue, 08 Oct 2013 03:04:46 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=Xz3KLM3tZcJl0wqLeiTEwChweJG7AmFliu/rp9T0CjE=; b=qLoMYu+3P+lieycPZ0EcSWefeuPjFl0b70/gwmm1BJSCUOYmdyPhQOfvyZtNcrXde8 Ygisp2a0orHdeJ+oYwijji1da7wiplIjwLYSnJ/VC3cJRwyfrJLuaTWo0ziYfycIQWWU Fqo1tQIRkbi5UF/A7Dxn66MfjUIPZ9EuwjCheLrwWP+CxqVE7Id32uLb7Y0dV5GTw53E VNcASpXfFJOwG+4CqRpnvd7ETxnyXoqDCS8dD7zDazqUUSUciIIveGjOiOgyvxcn9N2h Ir63YGFVR22mUtLJYiX8ES+glUDWByOKhND+SuV7GAT4jHxZMp08YYH/8E5bdIIgTIPA d1/Q== MIME-Version: 1.0 X-Received: by 10.224.147.143 with SMTP id l15mr507257qav.113.1381226686298; Tue, 08 Oct 2013 03:04:46 -0700 (PDT) Received: by 10.224.184.68 with HTTP; Tue, 8 Oct 2013 03:04:46 -0700 (PDT) In-Reply-To: References: <8AE0F17B87264D4CAC7DE0AA6C406F453D7C7F1B@nkgeml506-mbx.china.huawei.com> Date: Tue, 8 Oct 2013 18:04:46 +0800 Message-ID: From: GangChen To: Lorenzo Colitti Content-Type: text/plain; charset=ISO-8859-1 Cc: v6ops Subject: Re: [v6ops] new version is available: draft-ietf-v6ops-nat64-experience-03.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 Oct 2013 10:04:53 -0000 Hello Lorenzo, Many thanks for the message. I make following changes to incorporate your comments Please kindly check. ==OLD=== When the host has both IPv4 and IPv6 address, it would initiate both A and AAAA record lookup may due to Happy Eyeballs [RFC6555], then both original A record and DNS64-generated AAAA record would be received. The host would prefer the AAAA record as the destination, if the address selection process still follows the recommendation of [RFC3484]. While, if the host implements the default policy table as defined in [RFC6724], since the IPv4 takes the precedence over ULA (which is difference than [RFC3484]), an IPv4 path will be always preferred. It may be undesirable because the traffic path is unexpected due to vary implementations on hosts. Operators have to make site-specific rules to gauge the host's behaviors, which may likely add the operational complexity. ==New== When the host has both IPv4 and IPv6 address, it would initiate both A and AAAA record lookup, then both original A record and DNS64-generated AAAA record would be received. A host, which is compliant with [RFC6724], will never prefer ULA over IPv4. An IPv4 path will be always selected. It may be undesirable because the NAT64-CGN will never be used. Operators may consider to add additional site-specific rows to the default table to steer traffic flows going through NAT64-CGN. However, it involves significant costs to change terminal's behavior. Therefore, operators are not suggested to configure ULAs on a NAT64-CGN. BRs Gang 2013/10/8, Lorenzo Colitti : > Comments on the ULA section only: > > 1. Please do not cite RFC 3484 anywhere. It is obsolete and thus > irrelevant; hosts that implement it are not compliant with current IETF > standards. Instead, say that compliant host implementations will never > prefer ULA over IPv4. The logical conclusion is to say that ULA addresses > are not recommended for use on a NAT64-CGN, because they will never be > used. > > 2. Don't cite RFC 6555, it has nothing to do with issuing both A and AAAA > DNS requests. Issuing both an AAAA lookup and an A lookup is standard for > RFC 6724 implementations that have both IPv4 and IPv6 addresses. > > > On Tue, Oct 8, 2013 at 12:51 PM, Liubing (Leo) > wrote: > >> Hi, all >> >> I support this new version. The ULA statement is valuable guide to the >> real deployment. >> >> B.R. >> Bing >> >> > -----Original Message----- >> > From: v6ops-bounces@ietf.org [mailto:v6ops-bounces@ietf.org] On Behalf >> > Of GangChen >> > Sent: Wednesday, October 02, 2013 10:36 AM >> > To: v6ops >> > Subject: [v6ops] new version is available: >> > draft-ietf-v6ops-nat64-experience-03.txt >> > >> > Wg, >> > >> > We have just submitted the new version to address the comments during >> > the >> > WGLC. >> > The main changes are >> > 1) Add the ULAs statement to feedback Lorenzo's comments >> > 2) Add the description of bulk port allocation in Section 5.1 >> > suggested by Mikael >> > 3) Add the experience description for geo-location service in Section >> > 5.2 according to Dan Wing and Mikael comments >> > 4) Add sub-levels in Section 3.1 and improve the description in >> > section 3.1.2 to echo Sheng's comments >> > 5) Polish the entire draft according to the suggestions from >> > IETF#87"Document Language Editing Session" >> > >> > Please kindly check if all comments are addressed in this version. >> > >> > Many thanks >> > >> > Gang >> > >> > 2013/10/2, internet-drafts@ietf.org : >> > > >> > > A New Internet-Draft is available from the on-line Internet-Drafts >> > > directories. >> > > This draft is a work item of the IPv6 Operations Working Group of >> > > the >> > > IETF. >> > > >> > > Title : NAT64 Operational Experiences >> > > Author(s) : Gang Chen >> > > Zhen Cao >> > > Chongfeng Xie >> > > David Binet >> > > Filename : draft-ietf-v6ops-nat64-experience-03.txt >> > > Pages : 20 >> > > Date : 2013-10-01 >> > > >> > > Abstract: >> > > This document summarizes NAT64 function deployment scenarios and >> > > operational experience. Both NAT64 Carrier Grade NAT (NAT64-CGN) >> > and >> > > NAT64 server Front End (NAT64-FE) are considered in this document. >> > > >> > > >> > > The IETF datatracker status page for this draft is: >> > > https://datatracker.ietf.org/doc/draft-ietf-v6ops-nat64-experience >> > > >> > > There's also a htmlized version available at: >> > > http://tools.ietf.org/html/draft-ietf-v6ops-nat64-experience-03 >> > > >> > > A diff from the previous version is available at: >> > > http://www.ietf.org/rfcdiff?url2=draft-ietf-v6ops-nat64-experience-03 >> > > >> > > >> > > Please note that it may take a couple of minutes from the time of >> > > submission >> > > until the htmlized version and diff are available at tools.ietf.org. >> > > >> > > Internet-Drafts are also available by anonymous FTP at: >> > > ftp://ftp.ietf.org/internet-drafts/ >> > > >> > > _______________________________________________ >> > > v6ops mailing list >> > > v6ops@ietf.org >> > > https://www.ietf.org/mailman/listinfo/v6ops >> > > >> > _______________________________________________ >> > v6ops mailing list >> > v6ops@ietf.org >> > https://www.ietf.org/mailman/listinfo/v6ops >> _______________________________________________ >> v6ops mailing list >> v6ops@ietf.org >> https://www.ietf.org/mailman/listinfo/v6ops >> > From leo.liubing@huawei.com Tue Oct 8 03:07:13 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 18BF621E8166 for ; Tue, 8 Oct 2013 03:07:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.998 X-Spam-Level: X-Spam-Status: No, score=-5.998 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_13=0.6, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MaQrJv4UQGJx for ; Tue, 8 Oct 2013 03:07:08 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) by ietfa.amsl.com (Postfix) with ESMTP id B497011E8173 for ; Tue, 8 Oct 2013 03:07:05 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml203-edg.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id AWO10709; Tue, 08 Oct 2013 10:07:04 +0000 (GMT) Received: from LHREML404-HUB.china.huawei.com (10.201.5.218) by lhreml203-edg.huawei.com (172.18.7.221) with Microsoft SMTP Server (TLS) id 14.3.146.0; Tue, 8 Oct 2013 11:06:18 +0100 Received: from NKGEML404-HUB.china.huawei.com (10.98.56.35) by lhreml404-hub.china.huawei.com (10.201.5.218) with Microsoft SMTP Server (TLS) id 14.3.146.0; Tue, 8 Oct 2013 11:06:47 +0100 Received: from NKGEML506-MBX.china.huawei.com ([169.254.3.141]) by nkgeml404-hub.china.huawei.com ([10.98.56.35]) with mapi id 14.03.0146.000; Tue, 8 Oct 2013 18:06:42 +0800 From: "Liubing (Leo)" To: Lorenzo Colitti Thread-Topic: [v6ops] new version is available: draft-ietf-v6ops-nat64-experience-03.txt Thread-Index: AQHOxAW7QL3p5UFaaEuUlttem8di5pnqhyMw Date: Tue, 8 Oct 2013 10:06:41 +0000 Message-ID: <8AE0F17B87264D4CAC7DE0AA6C406F453D7C8042@nkgeml506-mbx.china.huawei.com> References: <8AE0F17B87264D4CAC7DE0AA6C406F453D7C7F1B@nkgeml506-mbx.china.huawei.com> In-Reply-To: Accept-Language: en-US, zh-CN Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.111.98.132] Content-Type: multipart/alternative; boundary="_000_8AE0F17B87264D4CAC7DE0AA6C406F453D7C8042nkgeml506mbxchi_" MIME-Version: 1.0 X-CFilter-Loop: Reflected Cc: v6ops Subject: Re: [v6ops] new version is available: draft-ietf-v6ops-nat64-experience-03.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 Oct 2013 10:07:13 -0000 --_000_8AE0F17B87264D4CAC7DE0AA6C406F453D7C8042nkgeml506mbxchi_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable > The logical conclusion is to say that ULA addresses are not recommended f= or use on a NAT64-CGN, because they will never be used. [Bing]IMHO, it goes too far to say "ULA addresses are not recommended for u= se on a NAT64-CGN". If the admins deploy site-specific addr-select policy t= ables, it is OK to use ULA. I think it is enough to just make a caution for= the authors that ULA prefix would be invalid under default policy. From: Lorenzo Colitti [mailto:lorenzo@google.com] Sent: Tuesday, October 08, 2013 5:06 PM To: Liubing (Leo) Cc: GangChen; v6ops Subject: Re: [v6ops] new version is available: draft-ietf-v6ops-nat64-exper= ience-03.txt Comments on the ULA section only: 1. Please do not cite RFC 3484 anywhere. It is obsolete and thus irrelevant= ; hosts that implement it are not compliant with current IETF standards. In= stead, say that compliant host implementations will never prefer ULA over I= Pv4. The logical conclusion is to say that ULA addresses are not recommende= d for use on a NAT64-CGN, because they will never be used. 2. Don't cite RFC 6555, it has nothing to do with issuing both A and AAAA D= NS requests. Issuing both an AAAA lookup and an A lookup is standard for RF= C 6724 implementations that have both IPv4 and IPv6 addresses. On Tue, Oct 8, 2013 at 12:51 PM, Liubing (Leo) > wrote: Hi, all I support this new version. The ULA statement is valuable guide to the real= deployment. B.R. Bing > -----Original Message----- > From: v6ops-bounces@ietf.org [mailto:v6ops= -bounces@ietf.org] On Behalf > Of GangChen > Sent: Wednesday, October 02, 2013 10:36 AM > To: v6ops > Subject: [v6ops] new version is available: > draft-ietf-v6ops-nat64-experience-03.txt > > Wg, > > We have just submitted the new version to address the comments during the > WGLC. > The main changes are > 1) Add the ULAs statement to feedback Lorenzo's comments > 2) Add the description of bulk port allocation in Section 5.1 > suggested by Mikael > 3) Add the experience description for geo-location service in Section > 5.2 according to Dan Wing and Mikael comments > 4) Add sub-levels in Section 3.1 and improve the description in > section 3.1.2 to echo Sheng's comments > 5) Polish the entire draft according to the suggestions from > IETF#87"Document Language Editing Session" > > Please kindly check if all comments are addressed in this version. > > Many thanks > > Gang > > 2013/10/2, internet-drafts@ietf.org >: > > > > A New Internet-Draft is available from the on-line Internet-Drafts > > directories. > > This draft is a work item of the IPv6 Operations Working Group of the > > IETF. > > > > Title : NAT64 Operational Experiences > > Author(s) : Gang Chen > > Zhen Cao > > Chongfeng Xie > > David Binet > > Filename : draft-ietf-v6ops-nat64-experience-03.txt > > Pages : 20 > > Date : 2013-10-01 > > > > Abstract: > > This document summarizes NAT64 function deployment scenarios and > > operational experience. Both NAT64 Carrier Grade NAT (NAT64-CGN) > and > > NAT64 server Front End (NAT64-FE) are considered in this document. > > > > > > The IETF datatracker status page for this draft is: > > https://datatracker.ietf.org/doc/draft-ietf-v6ops-nat64-experience > > > > There's also a htmlized version available at: > > http://tools.ietf.org/html/draft-ietf-v6ops-nat64-experience-03 > > > > A diff from the previous version is available at: > > http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-v6ops-nat64-experience-03 > > > > > > Please note that it may take a couple of minutes from the time of > > submission > > until the htmlized version and diff are available at tools.ietf.org. > > > > Internet-Drafts are also available by anonymous FTP at: > > ftp://ftp.ietf.org/internet-drafts/ > > > > _______________________________________________ > > v6ops mailing list > > v6ops@ietf.org > > https://www.ietf.org/mailman/listinfo/v6ops > > > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops _______________________________________________ v6ops mailing list v6ops@ietf.org https://www.ietf.org/mailman/listinfo/v6ops --_000_8AE0F17B87264D4CAC7DE0AA6C406F453D7C8042nkgeml506mbxchi_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

> The l= ogical conclusion is to say that ULA addresses are not recommended for use = on a NAT64-CGN, because they will never be used.

 = ;

[Bing]IMHO= , it goes too far to say “ULA addresses are not recommended for use o= n a NAT64-CGN”. If the admins deploy site-specific addr-select policy tables, it is OK to use ULA. I think it is enough to just make a caution f= or the authors that ULA prefix would be invalid under default policy.<= /o:p>

 = ;

From: Lorenzo Colitti [mailto:lorenzo@google.com]
Sent: Tuesday, October 08, 2013 5:06 PM
To: Liubing (Leo)
Cc: GangChen; v6ops
Subject: Re: [v6ops] new version is available: draft-ietf-v6ops-nat6= 4-experience-03.txt

 

Comments on the ULA section onl= y:

 

1. Please do not cite RFC 3484 = anywhere. It is obsolete and thus irrelevant; hosts that implement it are n= ot compliant with current IETF standards. Instead, say that compliant host = implementations will never prefer ULA over IPv4. The logical conclusion is to say that ULA addresses are not rec= ommended for use on a NAT64-CGN, because they will never be used.

 

2. Don't cite RFC 6555, it has = nothing to do with issuing both A and AAAA DNS requests. Issuing both an AA= AA lookup and an A lookup is standard for RFC 6724 implementations that hav= e both IPv4 and IPv6 addresses.

=  

On Tue, Oct 8, 2013 at 12:51 PM= , Liubing (Leo) <leo.liubing@huawei.com> wrote:

Hi, all

I support this new version. The ULA statement is valuable guide to the real= deployment.

B.R.
Bing


> -----Original Message-----
> From: v6ops-bounces@ietf.org= [mailto:v6ops-bounces@ietf.o= rg] On Behalf
> Of GangChen
> Sent: Wednesday, October 02, 2013 10:36 AM
> To: v6ops
> Subject: [v6ops] new version is available:
> draft-ietf-v6ops-nat64-experience-03.txt
>
> Wg,
>
> We have just submitted the new version to address the comments during = the
> WGLC.
> The main changes are
> 1) Add the ULAs statement to feedback Lorenzo's comments
> 2) Add the description of bulk port allocation in Section 5.1
> suggested by Mikael
> 3) Add the experience description for geo-location service in Section<= br> > 5.2 according to Dan Wing and Mikael comments
> 4) Add sub-levels in Section 3.1 and improve the description in
> section 3.1.2 to echo Sheng's comments
> 5) Polish the entire draft according to the suggestions from
> IETF#87"Document Language Editing Session"
>
> Please kindly check if all comments are addressed in this version.
>
> Many thanks
>
> Gang
>
> 2013/10/2, internet-drafts= @ietf.org <internet-draf= ts@ietf.org>:
> >
> > A New Internet-Draft is available from the on-line Internet-Draft= s
> > directories.
> >  This draft is a work item of the IPv6 Operations Working Gr= oup of the
> > IETF.
> >
> >     Title           : NAT64 Op= erational Experiences
> >     Author(s)       : Gang Chen
> >                   &n= bsp;       Zhen Cao
> >                   &n= bsp;       Chongfeng Xie
> >                   &n= bsp;       David Binet
> >     Filename        : draft-ietf-v6= ops-nat64-experience-03.txt
> >     Pages           : 20
> >     Date            : 201= 3-10-01
> >
> > Abstract:
> >    This document summarizes NAT64 function deployment s= cenarios and
> >    operational experience.  Both NAT64 Carrier Gra= de NAT (NAT64-CGN)
> and
> >    NAT64 server Front End (NAT64-FE) are considered in = this document.
> >
> >
> > The IETF datatracker status page for this draft is:
> > https://datatracker.ietf.org/doc/draft-ietf-v6ops-nat64-experience
> >
> > There's also a htmlized version available at:
> > http://tools.ietf.org/html/draft-ietf-v6ops-nat64-experience-03
> >
> > A diff from the previous version is available at:
> > http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-v6ops-nat64-experience-03=
> >
> >
> > Please note that it may take a couple of minutes from the time of=
> > submission
> > until the htmlized version and diff are available at tools.ietf.org.
> >
> > Internet-Drafts are also available by anonymous FTP at:
> > ftp://ftp.ietf.org/internet-drafts/
> >
> > _______________________________________________
> > v6ops mailing list
> > v6ops@ietf.org
> > https://www.ietf.org/mailman/listinfo/v6ops
> >
> _______________________________________________
> v6ops mailing list
> v6ops@ietf.org
> https://www.ietf.org/mailman/listinfo/v6ops
_______________________________________________
v6ops mailing list
v6ops@ietf.org
h= ttps://www.ietf.org/mailman/listinfo/v6ops

 

--_000_8AE0F17B87264D4CAC7DE0AA6C406F453D7C8042nkgeml506mbxchi_-- From lorenzo@google.com Tue Oct 8 03:23:25 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3464521E81BF for ; Tue, 8 Oct 2013 03:23:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.827 X-Spam-Level: X-Spam-Status: No, score=-1.827 tagged_above=-999 required=5 tests=[AWL=0.150, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, 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 FTk7sp1Hh99i for ; Tue, 8 Oct 2013 03:23:24 -0700 (PDT) Received: from mail-ie0-x231.google.com (mail-ie0-x231.google.com [IPv6:2607:f8b0:4001:c03::231]) by ietfa.amsl.com (Postfix) with ESMTP id 93BDD21E8174 for ; Tue, 8 Oct 2013 03:23:24 -0700 (PDT) Received: by mail-ie0-f177.google.com with SMTP id qd12so18962450ieb.36 for ; Tue, 08 Oct 2013 03:23:24 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=PIzckDNftUmDzlpkUhsqowaOr4JR06M+ko3LjP0zntA=; b=JYFiAtOh1CWQegBHtuj45rs3G2zVEfdx6WHSx8xB9sPCLoN8XmXCVpbxzzb2vrF0jQ 3zQRU8oj8cX1WgsmoL/2anz68aYOViBw+nw6cQ8Jmi6sGMdpOF9Our5qFqS0TJmGQi8J 3O25yo4n+WugcLe4ezpy6hc9pdgqAbn6unEDqN85d+Zzy5tWkQPN4Ux9XMC2EjjlpqGG ug6NJdEBhAvsXx+S4e4lkwtNUE/yO6/ekO1L9bXV/Ku7Vb/A/APl2DKpoTvQYsQ7USJB 0+COyDAbLV24SGeqZgz/5moaFkLcNwH6j9h8zFy7ThHkGoOFHuTANQ1kcfFexGhOCoOF gtTA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type; bh=PIzckDNftUmDzlpkUhsqowaOr4JR06M+ko3LjP0zntA=; b=TGDZfZHoC9SdCeSHY2uoiqyEL5lhNecTtrytax44c2cVCOXIp18DBo589bEiwuJnwx jwuHWBdHREqKhGWvrq74C/yAz4yeI877a+HeNtUwZHP7nxvfvma1kJHWR//RdkEkBXez 93xqUTKs5kepiDwKbQyEjhWBF2jApqcIrpleqUtk55oxlOtMzlLkjUSQSN2Ox9f6UPOI 4KWojA13LrzmrxYkL4c5cAhjOOuvUDy+pRyABj31h9LZEMk4OVaPyAFuSfxJ4gAJmIx2 AmlYLL+CgNeZlxmvtASBVzHE8ryuZOk/UtXYEt75V2Rf/w43r3g9OLhII7AisbBV5J5h yQKg== X-Gm-Message-State: ALoCoQnpMf1AWvXoZ7hDqTXMQBlJN2p5R/qOpRRyjuwkLy1A3Sy7yPOCexl8GVNaUqoDuvdn+kWJXX9+oL0s1c72UhkQJccfZxQUmTA2viJ+PnpzoYbvSe8PBMleLjYetsuCk6+ShqYJVz7pmH10X5mBgYUoUH6abWYeUK9OOhQMboeNdMQ9PBXNWsiFtUSp7BhlIlPlHZUG X-Received: by 10.43.172.4 with SMTP id nw4mr510237icc.25.1381227803946; Tue, 08 Oct 2013 03:23:23 -0700 (PDT) MIME-Version: 1.0 Received: by 10.64.86.106 with HTTP; Tue, 8 Oct 2013 03:23:03 -0700 (PDT) In-Reply-To: <8AE0F17B87264D4CAC7DE0AA6C406F453D7C8042@nkgeml506-mbx.china.huawei.com> References: <8AE0F17B87264D4CAC7DE0AA6C406F453D7C7F1B@nkgeml506-mbx.china.huawei.com> <8AE0F17B87264D4CAC7DE0AA6C406F453D7C8042@nkgeml506-mbx.china.huawei.com> From: Lorenzo Colitti Date: Tue, 8 Oct 2013 19:23:03 +0900 Message-ID: To: "Liubing (Leo)" Content-Type: multipart/alternative; boundary=001a11c2fe3c9bd08304e8382850 Cc: v6ops Subject: Re: [v6ops] new version is available: draft-ietf-v6ops-nat64-experience-03.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 Oct 2013 10:23:25 -0000 --001a11c2fe3c9bd08304e8382850 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable On Tue, Oct 8, 2013 at 7:06 PM, Liubing (Leo) wrote= : > > The logical conclusion is to say that ULA addresses are not > recommended for use on a NAT64-CGN, because they will never be used.**** > > ** ** > > [Bing]IMHO, it goes too far to say =93ULA addresses are not recommended f= or > use on a NAT64-CGN=94. If the admins deploy site-specific addr-select pol= icy > tables, it is OK to use ULA. I think it is enough to just make a caution > for the authors that ULA prefix would be invalid under default policy. > But for that to work, the operator needs to control both the CGN and all the devices, right? Then say it's not recommended unless the operator controls both the CGN and all the devices. --001a11c2fe3c9bd08304e8382850 Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: quoted-printable
On Tue, Oct 8, 2013 at 7:06 PM, Liubing (Leo) <leo.l= iubing@huawei.com> wrote:

> The l= ogical conclusion is to say that ULA addresses are not recommended for use = on a NAT64-CGN, because they will never be used.

=A0=

[Bin= g]IMHO, it goes too far to say =93ULA addresses are not recommended for use= on a NAT64-CGN=94. If the admins deploy site-specific addr-select policy tables, it is OK to use ULA. I think it is enough to just make a caution f= or the authors that ULA prefix would be invalid under default policy.


But for that to work, the= operator needs to control both the CGN and all the devices, right? Then sa= y it's not recommended unless the operator controls both the CGN and al= l the devices.
--001a11c2fe3c9bd08304e8382850-- From fred@cisco.com Tue Oct 8 12:08:00 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9565921F91BF for ; Tue, 8 Oct 2013 12:08:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.599 X-Spam-Level: X-Spam-Status: No, score=-110.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, 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 LoW3lscXUcYq for ; Tue, 8 Oct 2013 12:07:55 -0700 (PDT) Received: from rcdn-iport-5.cisco.com (rcdn-iport-5.cisco.com [173.37.86.76]) by ietfa.amsl.com (Postfix) with ESMTP id 8298E21F994A for ; Tue, 8 Oct 2013 12:07:44 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1137; q=dns/txt; s=iport; t=1381259269; x=1382468869; h=from:to:subject:date:message-id:mime-version; bh=uojJH4dcLuiLovSNljxfnfYaBsOVSXtHJkaW94H07uM=; b=PAJvcZd9lX6RqfIF71GFepcNCrIXGi0ilGfKrIXo9xy3/p3/y1hRLlfK YJI9HYP2csGlWxSPKPNuO6PkvmPoZiaoJjasrse81mWKsMHM9hV+U5tYI nNqFSHfpRV1/yNhLtnYRyyTuhznG0dHSecWyVd4KC7kQF7w4aIu7+r4e+ U=; X-Files: signature.asc : 195 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AhwFAP9WVFKtJXG8/2dsb2JhbABZgwc4UsElgSIWdIInAQSBCwEqVicEGwaHeAyZUqFAjxGDV4EEA5AogTCHWJBRgySCKg X-IronPort-AV: E=Sophos;i="4.90,1058,1371081600"; d="asc'?scan'208";a="269632455" Received: from rcdn-core2-1.cisco.com ([173.37.113.188]) by rcdn-iport-5.cisco.com with ESMTP; 08 Oct 2013 19:07:44 +0000 Received: from xhc-aln-x04.cisco.com (xhc-aln-x04.cisco.com [173.36.12.78]) by rcdn-core2-1.cisco.com (8.14.5/8.14.5) with ESMTP id r98J7iux007156 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for ; Tue, 8 Oct 2013 19:07:44 GMT Received: from xmb-rcd-x09.cisco.com ([169.254.9.23]) by xhc-aln-x04.cisco.com ([173.36.12.78]) with mapi id 14.02.0318.004; Tue, 8 Oct 2013 14:07:43 -0500 From: "Fred Baker (fred)" To: " WG" Thread-Topic: On Consensus Thread-Index: AQHOxFmqjsYLxBf03E27pCKHkPznqw== Date: Tue, 8 Oct 2013 19:07:43 +0000 Message-ID: <8C48B86A895913448548E6D15DA7553BA5F63D@xmb-rcd-x09.cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-originating-ip: [10.19.64.115] Content-Type: multipart/signed; boundary="Apple-Mail=_2AE9E86C-08C4-4D28-9272-001ACDD822A2"; protocol="application/pgp-signature"; micalg=pgp-sha1 MIME-Version: 1.0 Subject: [v6ops] On Consensus X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 Oct 2013 19:08:00 -0000 --Apple-Mail=_2AE9E86C-08C4-4D28-9272-001ACDD822A2 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii I'd appreciate it if folks took ten minutes to read http://tools.ietf.org/html/draft-resnick-on-consensus "On Consensus and Humming in the IETF", Pete Resnick, 2013-10-04 The document is currently in last call on the IETF list, and Ted Hardie = specifically has some comments on it. Whatever the shortcomings of the = document may be, though, it makes some important points that I would = like our working group to consider in its deliberations. --Apple-Mail=_2AE9E86C-08C4-4D28-9272-001ACDD822A2 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="signature.asc" Content-Type: application/pgp-signature; name="signature.asc" Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- Comment: GPGTools - http://gpgtools.org iD8DBQFSVFi9bjEdbHIsm0MRAse3AKCixRpHTv0IJe3ngSCp8RqUKJGVSgCdGU0/ oSh0cV1NLjdZINGGFcoS2RE= =/bFQ -----END PGP SIGNATURE----- --Apple-Mail=_2AE9E86C-08C4-4D28-9272-001ACDD822A2-- From gert@space.net Tue Oct 8 12:40:03 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0069A21F9123 for ; Tue, 8 Oct 2013 12:40:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.299 X-Spam-Level: X-Spam-Status: No, score=-1.299 tagged_above=-999 required=5 tests=[AWL=-1.300, BAYES_50=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 Nws4+tdoib9p for ; Tue, 8 Oct 2013 12:40:01 -0700 (PDT) Received: from mobil.space.net (mobil.space.net [IPv6:2001:608:2:81::67]) by ietfa.amsl.com (Postfix) with ESMTP id F30EB21F997D for ; Tue, 8 Oct 2013 12:39:42 -0700 (PDT) Received: from mobil.space.net (localhost [127.0.0.1]) by mobil.space.net (Postfix) with ESMTP id 692C460B30 for ; Tue, 8 Oct 2013 21:39:39 +0200 (CEST) X-SpaceNet-Relay: true Received: from moebius3.space.net (moebius3.Space.Net [IPv6:2001:608:2:2::250]) by mobil.space.net (Postfix) with ESMTPS id 3CACB60B24 for ; Tue, 8 Oct 2013 21:39:39 +0200 (CEST) Received: (qmail 14558 invoked by uid 1007); 8 Oct 2013 21:39:39 +0200 Date: Tue, 8 Oct 2013 21:39:39 +0200 From: Gert Doering To: "Fred Baker \(fred\)" Message-ID: <20131008193939.GR65295@Space.Net> References: <8C48B86A895913448548E6D15DA7553BA5F63D@xmb-rcd-x09.cisco.com> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="q2LmTmcAMWYQjrWl" Content-Disposition: inline In-Reply-To: <8C48B86A895913448548E6D15DA7553BA5F63D@xmb-rcd-x09.cisco.com> X-NCC-RegID: de.space User-Agent: Mutt/1.5.21 (2010-09-15) Cc: " WG" Subject: Re: [v6ops] On Consensus X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 Oct 2013 19:40:03 -0000 --q2LmTmcAMWYQjrWl Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Hi, On Tue, Oct 08, 2013 at 07:07:43PM +0000, Fred Baker (fred) wrote: > I'd appreciate it if folks took ten minutes to read >=20 > http://tools.ietf.org/html/draft-resnick-on-consensus > "On Consensus and Humming in the IETF", Pete Resnick, 2013-10-04 Great document. We follow roughly the same principles in the RIPE address policy working=20 group when trying to decide on (rough) consensus - so it's good to have someone actually write it down so people can understand how the process works. Gert Doering -- RIPE APWG chair --=20 have you enabled IPv6 on something today...? SpaceNet AG Vorstand: Sebastian v. Bomhard Joseph-Dollinger-Bogen 14 Aufsichtsratsvors.: A. Grundner-Culemann D-80807 Muenchen HRB: 136055 (AG Muenchen) Tel: +49 (0)89/32356-444 USt-IdNr.: DE813185279 --q2LmTmcAMWYQjrWl Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.15 (FreeBSD) iQCVAwUBUlRfe6kuBuNlUUl1AQLI5wP/cH/1ubfPZmOxeoLoNNK7HzdCl/7ci1VX QHgrLISWIjHI5mMkBgxzuPHdq+GlYF3g3wcmeAoH+NTpUagH9OwDwVqkH8NtgIRZ o862P7/EScleF3aim/qHjDW/I1DwwqFK0ZedYKu1tXur7/NibkC8TB9N5tFlXekp kioj+cjQ8BU= =7fDJ -----END PGP SIGNATURE----- --q2LmTmcAMWYQjrWl-- From jiangsheng@huawei.com Tue Oct 8 18:56:59 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 75AD721E80AB for ; Tue, 8 Oct 2013 18:56:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.299 X-Spam-Level: X-Spam-Status: No, score=-6.299 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, J_CHICKENPOX_13=0.6, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id c9Iy8va2ukGw for ; Tue, 8 Oct 2013 18:56:55 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) by ietfa.amsl.com (Postfix) with ESMTP id 48E3F21F9611 for ; Tue, 8 Oct 2013 18:56:49 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml203-edg.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id AYT03263; Wed, 09 Oct 2013 01:56:43 +0000 (GMT) Received: from LHREML402-HUB.china.huawei.com (10.201.5.241) by lhreml203-edg.huawei.com (172.18.7.221) with Microsoft SMTP Server (TLS) id 14.3.146.0; Wed, 9 Oct 2013 02:56:11 +0100 Received: from NKGEML410-HUB.china.huawei.com (10.98.56.41) by lhreml402-hub.china.huawei.com (10.201.5.241) with Microsoft SMTP Server (TLS) id 14.3.146.0; Wed, 9 Oct 2013 02:56:42 +0100 Received: from NKGEML512-MBX.china.huawei.com ([169.254.7.191]) by nkgeml410-hub.china.huawei.com ([10.98.56.41]) with mapi id 14.03.0146.000; Wed, 9 Oct 2013 09:56:34 +0800 From: Sheng Jiang To: GangChen , v6ops Thread-Topic: [v6ops] new version is available: draft-ietf-v6ops-nat64-experience-03.txt Thread-Index: AQHOvxgmP4xmjjASK0ea4o7OfjORwJnrpyRA Date: Wed, 9 Oct 2013 01:56:32 +0000 Message-ID: <5D36713D8A4E7348A7E10DF7437A4B923AD4630F@nkgeml512-mbx.china.huawei.com> References: In-Reply-To: Accept-Language: en-GB, zh-CN, en-US Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.111.98.145] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-CFilter-Loop: Reflected Subject: Re: [v6ops] new version is available: draft-ietf-v6ops-nat64-experience-03.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 09 Oct 2013 01:56:59 -0000 PldlIGhhdmUganVzdCBzdWJtaXR0ZWQgdGhlIG5ldyB2ZXJzaW9uIHRvIGFkZHJlc3MgdGhlIGNv bW1lbnRzIGR1cmluZyB0aGUNCj5XR0xDLg0KPlRoZSBtYWluIGNoYW5nZXMgYXJlDQo+MSkgQWRk IHRoZSBVTEFzIHN0YXRlbWVudCB0byBmZWVkYmFjayBMb3JlbnpvJ3MgY29tbWVudHMNCj4yKSBB ZGQgdGhlIGRlc2NyaXB0aW9uIG9mIGJ1bGsgcG9ydCBhbGxvY2F0aW9uIGluIFNlY3Rpb24gNS4x DQo+c3VnZ2VzdGVkIGJ5IE1pa2FlbA0KPjMpIEFkZCB0aGUgZXhwZXJpZW5jZSBkZXNjcmlwdGlv biBmb3IgZ2VvLWxvY2F0aW9uIHNlcnZpY2UgaW4gU2VjdGlvbg0KPjUuMiBhY2NvcmRpbmcgdG8g RGFuIFdpbmcgYW5kIE1pa2FlbCBjb21tZW50cw0KPjQpIEFkZCBzdWItbGV2ZWxzIGluIFNlY3Rp b24gMy4xIGFuZCBpbXByb3ZlIHRoZSBkZXNjcmlwdGlvbiBpbg0KPnNlY3Rpb24gMy4xLjIgdG8g ZWNobyBTaGVuZydzIGNvbW1lbnRzDQo+NSkgUG9saXNoIHRoZSBlbnRpcmUgZHJhZnQgYWNjb3Jk aW5nIHRvIHRoZSBzdWdnZXN0aW9ucyBmcm9tDQo+SUVURiM4N+KAnERvY3VtZW50IExhbmd1YWdl IEVkaXRpbmcgU2Vzc2lvbuKAnQ0KDQpUaGFua3MgZm9yIGFkZHJlc3MgbXkgY29tbWVudHMuIEkg c3VwcG9ydCB0aGlzIGRvY3VtZW50IHRvIGdvIGZvcndhcmQuDQoNClJlZ2FyZHMsDQoNClNoZW5n DQoNCj5QbGVhc2Uga2luZGx5IGNoZWNrIGlmIGFsbCBjb21tZW50cyBhcmUgYWRkcmVzc2VkIGlu IHRoaXMgdmVyc2lvbi4NCj4NCj5NYW55IHRoYW5rcw0KPg0KPkdhbmcNCj4NCj4yMDEzLzEwLzIs IGludGVybmV0LWRyYWZ0c0BpZXRmLm9yZyA8aW50ZXJuZXQtZHJhZnRzQGlldGYub3JnPjoNCj4+ DQo+PiBBIE5ldyBJbnRlcm5ldC1EcmFmdCBpcyBhdmFpbGFibGUgZnJvbSB0aGUgb24tbGluZSBJ bnRlcm5ldC1EcmFmdHMNCj4+IGRpcmVjdG9yaWVzLg0KPj4gIFRoaXMgZHJhZnQgaXMgYSB3b3Jr IGl0ZW0gb2YgdGhlIElQdjYgT3BlcmF0aW9ucyBXb3JraW5nIEdyb3VwIG9mIHRoZQ0KPj4gSUVU Ri4NCj4+DQo+PiAJVGl0bGUgICAgICAgICAgIDogTkFUNjQgT3BlcmF0aW9uYWwgRXhwZXJpZW5j ZXMNCj4+IAlBdXRob3IocykgICAgICAgOiBHYW5nIENoZW4NCj4+ICAgICAgICAgICAgICAgICAg ICAgICAgICAgWmhlbiBDYW8NCj4+ICAgICAgICAgICAgICAgICAgICAgICAgICAgQ2hvbmdmZW5n IFhpZQ0KPj4gICAgICAgICAgICAgICAgICAgICAgICAgICBEYXZpZCBCaW5ldA0KPj4gCUZpbGVu YW1lICAgICAgICA6IGRyYWZ0LWlldGYtdjZvcHMtbmF0NjQtZXhwZXJpZW5jZS0wMy50eHQNCj4+ IAlQYWdlcyAgICAgICAgICAgOiAyMA0KPj4gCURhdGUgICAgICAgICAgICA6IDIwMTMtMTAtMDEN Cj4+DQo+PiBBYnN0cmFjdDoNCj4+ICAgIFRoaXMgZG9jdW1lbnQgc3VtbWFyaXplcyBOQVQ2NCBm dW5jdGlvbiBkZXBsb3ltZW50IHNjZW5hcmlvcyBhbmQNCj4+ICAgIG9wZXJhdGlvbmFsIGV4cGVy aWVuY2UuICBCb3RoIE5BVDY0IENhcnJpZXIgR3JhZGUgTkFUIChOQVQ2NC1DR04pDQo+YW5kDQo+ PiAgICBOQVQ2NCBzZXJ2ZXIgRnJvbnQgRW5kIChOQVQ2NC1GRSkgYXJlIGNvbnNpZGVyZWQgaW4g dGhpcyBkb2N1bWVudC4NCj4+DQo+Pg0KPj4gVGhlIElFVEYgZGF0YXRyYWNrZXIgc3RhdHVzIHBh Z2UgZm9yIHRoaXMgZHJhZnQgaXM6DQo+PiBodHRwczovL2RhdGF0cmFja2VyLmlldGYub3JnL2Rv Yy9kcmFmdC1pZXRmLXY2b3BzLW5hdDY0LWV4cGVyaWVuY2UNCj4+DQo+PiBUaGVyZSdzIGFsc28g YSBodG1saXplZCB2ZXJzaW9uIGF2YWlsYWJsZSBhdDoNCj4+IGh0dHA6Ly90b29scy5pZXRmLm9y Zy9odG1sL2RyYWZ0LWlldGYtdjZvcHMtbmF0NjQtZXhwZXJpZW5jZS0wMw0KPj4NCj4+IEEgZGlm ZiBmcm9tIHRoZSBwcmV2aW91cyB2ZXJzaW9uIGlzIGF2YWlsYWJsZSBhdDoNCj4+IGh0dHA6Ly93 d3cuaWV0Zi5vcmcvcmZjZGlmZj91cmwyPWRyYWZ0LWlldGYtdjZvcHMtbmF0NjQtZXhwZXJpZW5j ZS0wMw0KPj4NCj4+DQo+PiBQbGVhc2Ugbm90ZSB0aGF0IGl0IG1heSB0YWtlIGEgY291cGxlIG9m IG1pbnV0ZXMgZnJvbSB0aGUgdGltZSBvZg0KPj4gc3VibWlzc2lvbg0KPj4gdW50aWwgdGhlIGh0 bWxpemVkIHZlcnNpb24gYW5kIGRpZmYgYXJlIGF2YWlsYWJsZSBhdCB0b29scy5pZXRmLm9yZy4N Cj4+DQo+PiBJbnRlcm5ldC1EcmFmdHMgYXJlIGFsc28gYXZhaWxhYmxlIGJ5IGFub255bW91cyBG VFAgYXQ6DQo+PiBmdHA6Ly9mdHAuaWV0Zi5vcmcvaW50ZXJuZXQtZHJhZnRzLw0KPj4NCj4+IF9f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQo+PiB2Nm9wcyBt YWlsaW5nIGxpc3QNCj4+IHY2b3BzQGlldGYub3JnDQo+PiBodHRwczovL3d3dy5pZXRmLm9yZy9t YWlsbWFuL2xpc3RpbmZvL3Y2b3BzDQo+Pg0KPl9fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fDQo+djZvcHMgbWFpbGluZyBsaXN0DQo+djZvcHNAaWV0Zi5vcmcN Cj5odHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3Y2b3BzDQo= From cb.list6@gmail.com Thu Oct 10 18:32:52 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 56A4921F96ED for ; Thu, 10 Oct 2013 18:32:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, 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 JIw+L2BhSPIc for ; Thu, 10 Oct 2013 18:32:52 -0700 (PDT) Received: from mail-wi0-x22b.google.com (mail-wi0-x22b.google.com [IPv6:2a00:1450:400c:c05::22b]) by ietfa.amsl.com (Postfix) with ESMTP id B1C1921F9697 for ; Thu, 10 Oct 2013 18:32:51 -0700 (PDT) Received: by mail-wi0-f171.google.com with SMTP id hm2so354360wib.4 for ; Thu, 10 Oct 2013 18:32:50 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:date:message-id:subject:from:to:content-type; bh=n0LhY2Bh5t2ynxCDjir9gYLEdZeby5VyxShctNj2aLo=; b=aGQE8E/G+VQS/BYAhITAaDaa1cHEIKHl2FyLvBM73EkHeBvx2CsJe6ROOgwMhUKgS/ W4iYbSvgM9Ywv/cLGBgWx/203nxsd7PWv42Y6rkZZyDb0UuO0qcT6SE8k9FvQ1Q+g84I KwaqS1uQ/MYRGyXA9JdprwModpzSjMh9TtdEBuMWTvjr1OmFHt38Jwmfq0+lDtWu0uL+ W7ir/BGVnFr1U7cbvxM6SiPKWpo70RH+FveccQ+vfEqgQrcIoHCLXR7zZnZR/rf96S82 wU81Pv5PN2xZx1IqHKpjWi6H9M8BIcNWZPT0RNQ3XAA3jB3VEVg+W/zoaVdgw6L6pl1A TQtw== MIME-Version: 1.0 X-Received: by 10.180.37.227 with SMTP id b3mr995890wik.24.1381455170684; Thu, 10 Oct 2013 18:32:50 -0700 (PDT) Received: by 10.217.114.137 with HTTP; Thu, 10 Oct 2013 18:32:50 -0700 (PDT) Received: by 10.217.114.137 with HTTP; Thu, 10 Oct 2013 18:32:50 -0700 (PDT) Date: Thu, 10 Oct 2013 18:32:50 -0700 Message-ID: From: "cb.list6" To: v6ops@ietf.org Content-Type: multipart/alternative; boundary=e89a8f646ff9b8cd7904e86d187c Subject: [v6ops] draft-byrne-v6ops-clatip-00 X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 11 Oct 2013 01:32:52 -0000 --e89a8f646ff9b8cd7904e86d187c Content-Type: text/plain; charset=ISO-8859-1 Hi, I wrote a draft to expand the scope of the ds-lite v4 range to include 464xlat in its scope Please have a look and let me know your thought on adopting and moving this forward. http://tools.ietf.org/html/draft-byrne-v6ops-clatip-00 --e89a8f646ff9b8cd7904e86d187c Content-Type: text/html; charset=ISO-8859-1

Hi,

I wrote a draft to expand the scope of the ds-lite v4 range to include 464xlat in its scope

Please have a look and let me know your thought on adopting and moving this forward.

http://tools.ietf.org/html/draft-byrne-v6ops-clatip-00

--e89a8f646ff9b8cd7904e86d187c-- From lorenzo@google.com Thu Oct 10 18:54:02 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F066D21E8188 for ; Thu, 10 Oct 2013 18:54:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.877 X-Spam-Level: X-Spam-Status: No, score=-1.877 tagged_above=-999 required=5 tests=[AWL=0.100, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, 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 TJUA2fVg7YcZ for ; Thu, 10 Oct 2013 18:54:02 -0700 (PDT) Received: from mail-ie0-x22a.google.com (mail-ie0-x22a.google.com [IPv6:2607:f8b0:4001:c03::22a]) by ietfa.amsl.com (Postfix) with ESMTP id E430F11E812A for ; Thu, 10 Oct 2013 18:54:01 -0700 (PDT) Received: by mail-ie0-f170.google.com with SMTP id x13so7000749ief.1 for ; Thu, 10 Oct 2013 18:54:01 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=Im+bMLVlUmRDn2TPC9HdJOQajiuA+NgXLSqTeZyYhLE=; b=PY3e6f83BaV2ggNWvjdG2N5BSPEngXywlhY20ab1NoVfVf7h6SUOIVXk9dtvu1W8O+ jSdSEHVV1sa+k054t8uO4uq1V60f0voD5yF0eb15cMgVr5U2Cl6ARVbYAYrsk0rIysXK nCobvHGvCtk3iuthEX2bC8bcLxxMnGOampRqN7aPq5cmbysxuXSVHhIPaI81jQ9vf8f6 2HMPltrYLD7tKlUF50VlV64ovqyrR8gB+9llClu4MIUZ+D/+xWH5L7SDNqAqJSlaMW9q R2zf6QXRu822yDIlxB5G6IBzUIU1lg3NGJcW7zLa5aki2XFbDdacqVjjWYSKaHXO2Rtn zZUQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type; bh=Im+bMLVlUmRDn2TPC9HdJOQajiuA+NgXLSqTeZyYhLE=; b=h3OUEUalS4AGe97KO3jHRgUC0haDEn13bpacUnH408izstKV3vpw1sND/r6x1OMMTr bwJZk70qiQP+k//9SlvlSAyU7YEB5D7ji7pCVY+SXTbTgDidrwQ5zS2UCzeVqk8x2OR4 8ImXqETboN9Mv/3/F+qa0iKEDdwW0iIS9tjeHlELxsEcyvcl77EQ2YT0GSSL7JXsvSwO E6th6LoY+4U4Fj7Je4/TTgpGrBuEj8nyz7WtJrmKE1ty0lhDtWRZjLBmW/giLovWHsPL mgaQofT1QunndenmnYPSP1l/DqqwIBQV51zEnKN/Tq9oJ1ndUSM5unY2rHqL9i3s9Z10 ZRuA== X-Gm-Message-State: ALoCoQmKfNvJyNS5zMZy+XYwodFwp7ZcqM3ZR4kB1Oe78AmsXx8KpuLoA7JHIRVdm2xovgcaUnH0L+iR44zVU0mw3xI7tDkSXycqNw8WNGioJhnpqcijcb9P2W6RYs/mKKXBPlVSrZ0Vo7eLQVzqd+5jxQlVz9kFOix8ZySBYzennAzbz63mGW5JEAeHGCbhkoNQ0MH0RQGM X-Received: by 10.50.66.163 with SMTP id g3mr933529igt.20.1381456441119; Thu, 10 Oct 2013 18:54:01 -0700 (PDT) MIME-Version: 1.0 Received: by 10.64.86.106 with HTTP; Thu, 10 Oct 2013 18:53:41 -0700 (PDT) In-Reply-To: References: From: Lorenzo Colitti Date: Fri, 11 Oct 2013 10:53:41 +0900 Message-ID: To: "cb.list6" Content-Type: multipart/alternative; boundary=047d7bdca31c72485f04e86d64bf Cc: "v6ops@ietf.org WG" Subject: Re: [v6ops] draft-byrne-v6ops-clatip-00 X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 11 Oct 2013 01:54:03 -0000 --047d7bdca31c72485f04e86d64bf Content-Type: text/plain; charset=ISO-8859-1 On Fri, Oct 11, 2013 at 10:32 AM, cb.list6 wrote: > I wrote a draft to expand the scope of the ds-lite v4 range to include > 464xlat in its scope > > Please have a look and let me know your thought on adopting and moving > this forward. > > http://tools.ietf.org/html/draft-byrne-v6ops-clatip-00 > Full disclosure: I implemented this in Android, which uses 192.0.0.4, so I obviously support it. :-) The reason I think this makes sense is because the semantics of the 464xlat IPv4 address are very similar to the semantics of the B4 IP address. Like DS-Lite, the 464xlat IPv4 address never appears on the wire, and it clearly identifies transitional IPv4 connectivity. Again like DS-Lite (but unlike other transition mechanisms such as MAP) the 464xlat IPv4 address is globally identical for all devices that implement the techology. Using an IPv4 address in the DS-Lite range allows other standards and code which need to deal with the properties of IPv4 addresses (for example, address sorting as documented in RFC 6724) to only support one "transitional IPv4" range instead of separately implementing mostly identical behaviour for DS-Lite and 464xlat (and possibly other similar IPv4-in-IPv6 transition mechanisms that have not yet been defined). If this document goes forward it might make sense not to have it refer to 464xlat explicitly but to specify under what conditions a transition mechanism can use this range. For example, instead of explicitly referring to 464xlat, the document might say that this range can be used for any transition mechanism which uses IPv6 to provide IPv4 and where the IPv4 address is the same for all hosts and never appears in the wire. --047d7bdca31c72485f04e86d64bf Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
On Fri, Oct 11, 2013 at 10:32 AM, cb.list6 <cb.list6@gma= il.com> wrote:

I wrote a draft to expand the scope of the = ds-lite v4 range to include 464xlat in its scope

Please have a look and let me know your thought on adopting = and moving this forward.

http://tools.ietf.org/html/draft-byrne-v6ops-clati= p-00

Full disclosure: I implemented=A0this in Android, which uses 192.0.0.4, = so I obviously support it. :-)

The reason I think this makes sense is because th= e semantics of the 464xlat IPv4 address are very similar to the semantics o= f the B4 IP address. Like DS-Lite, the 464xlat IPv4 address never appears o= n the wire, and it clearly identifies transitional IPv4 connectivity. Again= like DS-Lite (but unlike other transition mechanisms such as MAP) the 464x= lat IPv4 address is globally identical for all devices that implement the t= echology.

Using an IPv4 address in the DS-Lite range allows other= standards and code which need to deal with the properties of IPv4 addresse= s (for example, address sorting as documented in RFC 6724) to only support = one "transitional IPv4" range instead of separately implementing = mostly identical behaviour for DS-Lite and 464xlat (and possibly other simi= lar IPv4-in-IPv6 transition mechanisms that have not yet been defined).

If this document goes forward it might make sense not t= o have it refer to 464xlat explicitly but to specify under what conditions = a transition mechanism can use this range. For example, instead of explicit= ly referring to 464xlat, the document might say that this range can be used= for any transition mechanism which uses IPv6 to provide IPv4 and where the= IPv4 address is the same for all hosts and never appears in the wire.
--047d7bdca31c72485f04e86d64bf-- From fred@cisco.com Fri Oct 11 05:45:09 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 73D1B21F9BA4 for ; Fri, 11 Oct 2013 05:45:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.599 X-Spam-Level: X-Spam-Status: No, score=-110.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, 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 YGwgynKJn3n1 for ; Fri, 11 Oct 2013 05:45:03 -0700 (PDT) Received: from mtv-iport-1.cisco.com (mtv-iport-1.cisco.com [173.36.130.12]) by ietfa.amsl.com (Postfix) with ESMTP id 29A0111E8143 for ; Fri, 11 Oct 2013 05:45:02 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=126; q=dns/txt; s=iport; t=1381495502; x=1382705102; h=date:from:message-id:to:subject:cc; bh=fVTFu1azA+GtbdJjn7gVayeRz0VqPgGbe5SZkHQbSAw=; b=QZIRAOCfSaHrjMOJFd5Cc+9E6eMm0C6AwYNi14cRJ1sCdG0BHmYT/kyV U1ts6JTYI/M+nqnzoddF8+ubittN2hn2OH3R7l34MS7W8T2aj0ZVjKuRQ BfSw0E77JO3Pafqckn3vzo73sXOarnWaTLfyACOw+dBoxM5aij0rcdAOF s=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AiYIAInxV1KrRDoH/2dsb2JhbABZgwc4r28BkigJgSMWdIMlPC0HiGYNuwqPRx2EDQOJPI94kFODRA X-IronPort-AV: E=Sophos;i="4.90,1080,1371081600"; d="scan'208";a="91190780" Received: from mtv-core-2.cisco.com ([171.68.58.7]) by mtv-iport-1.cisco.com with ESMTP; 11 Oct 2013 12:45:01 +0000 Received: from ftpeng-update.cisco.com (ftpeng-update.cisco.com [171.69.17.32]) by mtv-core-2.cisco.com (8.14.5/8.14.5) with ESMTP id r9BCj0XG026112; Fri, 11 Oct 2013 12:45:00 GMT Received: (fred@localhost) by ftpeng-update.cisco.com (8.11.2/CISCO.WS.1.2) id r9BCj0319881; Fri, 11 Oct 2013 05:45:00 -0700 (PDT) Date: Fri, 11 Oct 2013 05:45:00 -0700 (PDT) From: Message-Id: <201310111245.r9BCj0319881@ftpeng-update.cisco.com> To: v6ops@ietf.org Cc: draft-byrne-v6ops-clatip@tools.ietf.org Subject: [v6ops] new draft: draft-byrne-v6ops-clatip X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 11 Oct 2013 12:45:09 -0000 A new draft has been posted, at http://tools.ietf.org/html/draft-byrne-v6ops-clatip. Please take a look at it and comment. From internet-drafts@ietf.org Sun Oct 13 16:59:46 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8BCB721E8143; Sun, 13 Oct 2013 16:59:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.566 X-Spam-Level: X-Spam-Status: No, score=-102.566 tagged_above=-999 required=5 tests=[AWL=0.034, 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 CUdKmAyHCRv5; Sun, 13 Oct 2013 16:59:46 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id B4C9E21E8154; Sun, 13 Oct 2013 16:59:41 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 4.80.p2 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20131013235941.31896.30276.idtracker@ietfa.amsl.com> Date: Sun, 13 Oct 2013 16:59:41 -0700 Cc: v6ops@ietf.org Subject: [v6ops] I-D Action: draft-ietf-v6ops-nat64-experience-04.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 13 Oct 2013 23:59:46 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the IPv6 Operations Working Group of the IETF. Title : NAT64 Operational Experiences Author(s) : Gang Chen Zhen Cao Chongfeng Xie David Binet Filename : draft-ietf-v6ops-nat64-experience-04.txt Pages : 20 Date : 2013-10-13 Abstract: This document summarizes NAT64 function deployment scenarios and operational experience. Both NAT64 Carrier Grade NAT (NAT64-CGN) and NAT64 server Front End (NAT64-FE) are considered in this document. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-v6ops-nat64-experience There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-v6ops-nat64-experience-04 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-v6ops-nat64-experience-04 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From phdgang@gmail.com Sun Oct 13 17:03:25 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F1BAA21E8151 for ; Sun, 13 Oct 2013 17:03:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.3 X-Spam-Level: X-Spam-Status: No, score=-2.3 tagged_above=-999 required=5 tests=[AWL=0.300, 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 7ZAuv9UVbMdX for ; Sun, 13 Oct 2013 17:03:24 -0700 (PDT) Received: from mail-qc0-x22a.google.com (mail-qc0-x22a.google.com [IPv6:2607:f8b0:400d:c01::22a]) by ietfa.amsl.com (Postfix) with ESMTP id 6643621E8143 for ; Sun, 13 Oct 2013 17:03:24 -0700 (PDT) Received: by mail-qc0-f170.google.com with SMTP id n9so1625052qcw.15 for ; Sun, 13 Oct 2013 17:03:23 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type; bh=chs5Nbk+kJS2UkArSOQCh5F37BFiMzuNBebNL60f8cU=; b=tpyWM0tWSwupVI+Wqrbtn+PX9Px+BCVUXU9MyaJlwtviqYDZonj2qUG5jFU3sOQ5JQ NxQ/mncbyxozqEVnu0T7uQC8I9Ax+WfRqOsgCE59+14SQ2QKOj59xmtJ9aUha5KNSBKa FtyfVgr1uKgevVJQJksnoLnY+lfUBsSD2ve95Uj7CsSRKXlZLWDG1e8QwwldgwVzLAHN Lfl0R6CUdcAcbB9Zr5dJC1Bl0uZMvLrFALquLor/OyldPKRfWcjYVDKTkT4co92X3Jzv GrHdYZD8JyfRb/T6AtZ+4MR9RoklVDnRnezCcm5mL8VEjl0HFTX7aKMFD/TgyCHCdnhF VZWQ== MIME-Version: 1.0 X-Received: by 10.224.130.72 with SMTP id r8mr19090879qas.32.1381709003862; Sun, 13 Oct 2013 17:03:23 -0700 (PDT) Received: by 10.224.204.4 with HTTP; Sun, 13 Oct 2013 17:03:23 -0700 (PDT) In-Reply-To: <20131013235941.31896.30276.idtracker@ietfa.amsl.com> References: <20131013235941.31896.30276.idtracker@ietfa.amsl.com> Date: Mon, 14 Oct 2013 08:03:23 +0800 Message-ID: From: GangChen To: v6ops@ietf.org Content-Type: text/plain; charset=ISO-8859-1 Subject: Re: [v6ops] I-D Action: draft-ietf-v6ops-nat64-experience-04.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 14 Oct 2013 00:03:25 -0000 Hello all, We have published the new version to address the comments regarding to the ULA Usages. Please kinldy check Best Regards Gang 2013/10/14, internet-drafts@ietf.org : > > A New Internet-Draft is available from the on-line Internet-Drafts > directories. > This draft is a work item of the IPv6 Operations Working Group of the > IETF. > > Title : NAT64 Operational Experiences > Author(s) : Gang Chen > Zhen Cao > Chongfeng Xie > David Binet > Filename : draft-ietf-v6ops-nat64-experience-04.txt > Pages : 20 > Date : 2013-10-13 > > Abstract: > This document summarizes NAT64 function deployment scenarios and > operational experience. Both NAT64 Carrier Grade NAT (NAT64-CGN) and > NAT64 server Front End (NAT64-FE) are considered in this document. > > > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-ietf-v6ops-nat64-experience > > There's also a htmlized version available at: > http://tools.ietf.org/html/draft-ietf-v6ops-nat64-experience-04 > > A diff from the previous version is available at: > http://www.ietf.org/rfcdiff?url2=draft-ietf-v6ops-nat64-experience-04 > > > Please note that it may take a couple of minutes from the time of > submission > until the htmlized version and diff are available at tools.ietf.org. > > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ > > _______________________________________________ > I-D-Announce mailing list > I-D-Announce@ietf.org > https://www.ietf.org/mailman/listinfo/i-d-announce > Internet-Draft directories: http://www.ietf.org/shadow.html > or ftp://ftp.ietf.org/ietf/1shadow-sites.txt > From randy@psg.com Tue Oct 15 00:20:15 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2977B21E80A9 for ; Tue, 15 Oct 2013 00:20:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.493 X-Spam-Level: X-Spam-Status: No, score=-2.493 tagged_above=-999 required=5 tests=[AWL=0.106, 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 ZBCyNMCDuZZ5 for ; Tue, 15 Oct 2013 00:20:14 -0700 (PDT) Received: from ran.psg.com (ran.psg.com [IPv6:2001:418:8006::18]) by ietfa.amsl.com (Postfix) with ESMTP id 914DE21E80B2 for ; Tue, 15 Oct 2013 00:20:11 -0700 (PDT) Received: from localhost ([127.0.0.1] helo=ryuu.psg.com.psg.com) by ran.psg.com with esmtp (Exim 4.76) (envelope-from ) id 1VVyvI-00013X-Kp; Tue, 15 Oct 2013 07:20:09 +0000 Date: Tue, 15 Oct 2013 10:20:07 +0300 Message-ID: From: Randy Bush To: Fred Baker In-Reply-To: <8C48B86A895913448548E6D15DA7553BA5F63D@xmb-rcd-x09.cisco.com> References: <8C48B86A895913448548E6D15DA7553BA5F63D@xmb-rcd-x09.cisco.com> User-Agent: Wanderlust/2.15.9 (Almost Unreal) Emacs/22.3 Mule/5.0 (SAKAKI) MIME-Version: 1.0 (generated by SEMI 1.14.7 - "Harue") Content-Type: text/plain; charset=US-ASCII Cc: V6 Ops List Subject: Re: [v6ops] On Consensus X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 15 Oct 2013 07:20:15 -0000 > I'd appreciate it if folks took ten minutes to read > > http://tools.ietf.org/html/draft-resnick-on-consensus > "On Consensus and Humming in the IETF", Pete Resnick, 2013-10-04 it seems to run over ipv6. what else concerned you? randy From brian@innovationslab.net Tue Oct 15 10:02:10 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 09DB411E8140; Tue, 15 Oct 2013 10:02:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.589 X-Spam-Level: X-Spam-Status: No, score=-102.589 tagged_above=-999 required=5 tests=[AWL=0.010, 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 YOhZvioF8Z3J; Tue, 15 Oct 2013 10:02:03 -0700 (PDT) Received: from uillean.fuaim.com (uillean.fuaim.com [206.197.161.140]) by ietfa.amsl.com (Postfix) with ESMTP id 0EF9911E80E3; Tue, 15 Oct 2013 10:01:57 -0700 (PDT) Received: from clairseach.fuaim.com (clairseach-high.fuaim.com [206.197.161.158]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by uillean.fuaim.com (Postfix) with ESMTP id 006DC880D1; Tue, 15 Oct 2013 10:01:56 -0700 (PDT) Received: from 102520116.rudm1.ra.johnshopkins.edu (addr16212925014.ippl.jhmi.edu [162.129.250.14]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by clairseach.fuaim.com (Postfix) with ESMTP id 8EFCB130003; Tue, 15 Oct 2013 10:01:55 -0700 (PDT) Message-ID: <525D74F2.7050202@innovationslab.net> Date: Tue, 15 Oct 2013 13:01:38 -0400 From: Brian Haberman User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:17.0) Gecko/20130801 Thunderbird/17.0.8 MIME-Version: 1.0 To: 6man WG , v6ops WG References: <20131015164653.2118.61260.idtracker@ietfa.amsl.com> In-Reply-To: <20131015164653.2118.61260.idtracker@ietfa.amsl.com> X-Enigmail-Version: 1.5.2 X-Forwarded-Message-Id: <20131015164653.2118.61260.idtracker@ietfa.amsl.com> Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="8qQ5o9WqOmwiKlskmpSnrOFEpA9sNWBkj" Subject: [v6ops] Fwd: WG Review: Source Packet Routing in Networking (spring) X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 15 Oct 2013 17:02:10 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --8qQ5o9WqOmwiKlskmpSnrOFEpA9sNWBkj Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable All, I know some of you will get this twice, but I want to make sure the v6 community is fully aware of this proposed WG. Specifically, you should notice that they are proposing to work on source routing in IPv6. Please review the charter and provide your comments to the *IESG*. Regards, Brian -------- Original Message -------- Subject: WG Review: Source Packet Routing in Networking (spring) Date: Tue, 15 Oct 2013 09:46:53 -0700 From: The IESG To: IETF-Announce CC: spring WG A new IETF working group has been proposed in the Routing Area. The IESG has not made any determination yet. The following draft charter was submitted, and is provided for informational purposes only. Please send your comments to the IESG mailing list (iesg at ietf.org) by 2013-10-22. Source Packet Routing in Networking (spring) ------------------------------------------------ Current Status: Proposed WG Assigned Area Director: Stewart Bryant Mailing list Address: status@ietf.org To Subscribe: https://www.ietf.org/mailman/listinfo/status Archive: http://www.ietf.org/mail-archive/web/status/current/maillist.html Charter: The ability for a node to specify a forwarding path, other than the normal shortest path, that a particular packet will traverse, benefits a number of network functions, for example: o Some types of network virtualization, including multi- topology networks and the partitioning of network resources for VPNs o Network path and node protection such as fast re-route o Network programmability o New OAM techniques o Simplification and reduction of network signalling components o Load balancing and traffic engineering Source-based routing mechanisms have previously been specified for network protocols, but have not seen widespread adoption other than in MPLS traffic engineering. These applications may require greater flexibility and per packet source imposed routing than can be achieved through the use of the previously defined methods. The SPRING working group will define procedures that will allow a node to steer a packet along an explicit route using information attached to the packet and without the need for per-path state information to be held at transit nodes. Full explicit control (through loose or strict path specification) can be achieved in a network comprising only SPRING nodes, however SPRING must inter-operate through loose routing in existing networks and may find it advantageous to use loose routing for for other network applications. The initial data planes that will be considered are MPLS and IPv6. There is an assumed trust model such that any node imposing an explicit route on a packet is assumed to be allowed to do so, however administrative and trust boundaries may strip explicit routes from a packet. For each data plane technology that SPRING specifies, a security analysis must be provided showing how protection is provided against an attacker disrupting the network by for example, maliciously injecting SPRING packets. There are a number of serious security concerns with source routing at the IP layer [RFC 5095]. As a part of its work, the working group will define the new IPv6-based routing header in way that blind attacks are never possible, i.e., attackers will be unable to send source routed packets that get successfully processed, without being part of the negotiation for setting up the source routes or being able to eavesdrop legitimate source routed packets. In some networks this base level security may be complemented with other mechanisms, such as packet filtering, cryptographic security, etc. Initial work will focus on SPRING within in a single AS, however design decisions must not preclude operation of SPRING across AS boundaries. SPRING should support both centralised and distributed path computation. The SPRING WG should provide OAM and the management needed to manage SPRING enabled networks. The SPRING protocol itself may also be used as a tool for OAM in SPRING enabled networks. SPRING should avoid modification to existing data planes that would make them incompatible with existing deployments. Where possible, existing control and management plane protocols must be used within existing architectures to implement the SPRING function. Any modification of or extension to existing architectures, data planes, or control or management plane protocols must be carried out in the working groups responsible for the architecture, data plane, or control or management plane protocol being modified and in co-ordination with this working group, but may be done in this working group after agreement with all the relevant WG chairs and responsible Area Directors. The SPRING working group is chartered for the following list of items: o Identification and evaluation of use cases for SPRING. These use cases must include a definition of the data plane for the environment in which they are to be deployed. o Definition of requirements and/or any new data plane encodings and procedures, required to implement the use cases. Such procedures must include the necessary security considerations. o Definition of requirements and/or any new control plane mechanism needed to enable the use cases. o Definition of requirements and/or management plane mechanism needed to manage and operate a SPRING enabled network. The SPRING working group will not work on any mechanisms for use in networks that forward IPv4 packets. [ Following to be replaced by milestones before final review] The working group will develop the following documents: o One or more documents describing SPRING use cases. o Specification of a high-level abstract architecture for SPRING and requirements for modifications to existing architecture to support SPRING use cases. o Specification of any required new procedures to support SPRING use cases. o One or more data plane extension requirements documents, including documenting the impact on existing deployments of the existing data plane. o One or more control protocol extensions requirements documents. o Publish SPRING management requirements document. o Specify the OAM mechanisms needed to support SPRING. o Document inter-working and co-existence between the new procedures and the existing signalling and routing protocols. o Inter-operability reports pertaining to the implementation of extensions supporting SPRING. Milestones: TBD --8qQ5o9WqOmwiKlskmpSnrOFEpA9sNWBkj Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG/MacGPG2 v2.0.20 (Darwin) Comment: GPGTools - https://gpgtools.org iQEcBAEBCgAGBQJSXXT4AAoJEBOZRqCi7goqp6UIAKC9B8rWpuC1HMWvXCrQQv1u jvGnAaMKzka0+iYywCtgtgNaH5Qie6zveOCMCGBwqYlAJuL+3q6gQ7/vSXOUmWTH moC12/NaDi6duQfRlGzhbzEHipZxhFJpbzBEDojCtahuubplWpql82APctURjHgU cXBDY4RwpqnIzR1WZXNDOqZUNlG67mSnZ6rFFebOBQkBEC5efz9SXe/j7cUdO0mW 2C0a4941xcBWAy94lQJxTMtWyiBXMGkEQUK5yvRFIqComX1EvMDUNPI1k2kPZeYM gWffqfkAxkvMpV2f3L3SOC7PbkEAaq+8cmuvfuGjrkYPh+GNLHuIMLGPiF5S2eo= =XkSQ -----END PGP SIGNATURE----- --8qQ5o9WqOmwiKlskmpSnrOFEpA9sNWBkj-- From brian.e.carpenter@gmail.com Tue Oct 15 12:49:16 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0A49611E8156 for ; Tue, 15 Oct 2013 12:49:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.571 X-Spam-Level: X-Spam-Status: No, score=-102.571 tagged_above=-999 required=5 tests=[AWL=0.028, 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 BHDk8k5Q0J3W for ; Tue, 15 Oct 2013 12:49:15 -0700 (PDT) Received: from mail-pd0-x22c.google.com (mail-pd0-x22c.google.com [IPv6:2607:f8b0:400e:c02::22c]) by ietfa.amsl.com (Postfix) with ESMTP id CC3C111E81E6 for ; Tue, 15 Oct 2013 12:49:14 -0700 (PDT) Received: by mail-pd0-f172.google.com with SMTP id z10so9344813pdj.3 for ; Tue, 15 Oct 2013 12:49:14 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:organization:user-agent:mime-version:to:cc :subject:references:in-reply-to:content-type :content-transfer-encoding; bh=AcAYO0lWVMqdT/0tle1ZKeK/QrhYmWIlgGNz1wALkQA=; b=DFNStNUiVIclLUfpBjWO9CG/GfNNUhSvOsIB8hMmJrvaCCkVt8pyCyddz4FqHafoXC S2+0kW+ScS5XJEJVeLpLwGA9yWL0xF+AWd/xfmVTgSDtosw7YrqX33k1GXHWw5u482C+ Q99i52OIUutUOYMpsNL0cyYf83hVUJCgQ9YpckhOxjUDPyw7ZOnjfQ0iMYaQrPj0iZrI LGycc3lUMQKCsxfreHcDUShVsxcZDMq121y0hvck0yR5oBKblWNLh+6j35Y22W5JaWEc PrnBW69gM54kT6n25NPFOauaz/kGyzETmdUUp9z8SrJ3jBcW91zgdNIrEIdm/GReSOIb 2nEQ== X-Received: by 10.67.14.231 with SMTP id fj7mr45352087pad.115.1381866554606; Tue, 15 Oct 2013 12:49:14 -0700 (PDT) Received: from [192.168.178.20] (55.198.69.111.dynamic.snap.net.nz. [111.69.198.55]) by mx.google.com with ESMTPSA id o1sm86330187pbe.37.1969.12.31.16.00.00 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Tue, 15 Oct 2013 12:49:13 -0700 (PDT) Message-ID: <525D9C3A.8030704@gmail.com> Date: Wed, 16 Oct 2013 08:49:14 +1300 From: Brian E Carpenter Organization: University of Auckland User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: Randy Bush References: <8C48B86A895913448548E6D15DA7553BA5F63D@xmb-rcd-x09.cisco.com> In-Reply-To: Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: V6 Ops List Subject: Re: [v6ops] On Consensus X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 15 Oct 2013 19:49:16 -0000 On 15/10/2013 20:20, Randy Bush wrote: >> I'd appreciate it if folks took ten minutes to read >> >> http://tools.ietf.org/html/draft-resnick-on-consensus >> "On Consensus and Humming in the IETF", Pete Resnick, 2013-10-04 > > it seems to run over ipv6. what else concerned you? Yes, humming over IPv6 seems to work for me: http://www.youtube.com/watch?v=tPDILKQjJW8 Brian From nalini.elkins@insidethestack.com Tue Oct 15 17:04:02 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1395811E8143 for ; Tue, 15 Oct 2013 17:04:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.165 X-Spam-Level: X-Spam-Status: No, score=-2.165 tagged_above=-999 required=5 tests=[AWL=0.433, 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 PtzTR0nkMyof for ; Tue, 15 Oct 2013 17:03:56 -0700 (PDT) Received: from nm23-vm5.access.bullet.mail.gq1.yahoo.com (nm23-vm5.access.bullet.mail.gq1.yahoo.com [216.39.63.141]) by ietfa.amsl.com (Postfix) with ESMTP id DF38911E820F for ; Tue, 15 Oct 2013 17:03:52 -0700 (PDT) Received: from [216.39.60.168] by nm23.access.bullet.mail.gq1.yahoo.com with NNFMP; 16 Oct 2013 00:03:52 -0000 Received: from [216.39.60.246] by tm4.access.bullet.mail.gq1.yahoo.com with NNFMP; 16 Oct 2013 00:03:51 -0000 Received: from [127.0.0.1] by omp1017.access.mail.gq1.yahoo.com with NNFMP; 16 Oct 2013 00:03:51 -0000 X-Yahoo-Newman-Property: ymail-3 X-Yahoo-Newman-Id: 908460.54731.bm@omp1017.access.mail.gq1.yahoo.com Received: (qmail 36317 invoked by uid 60001); 16 Oct 2013 00:03:51 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s1024; t=1381881831; bh=fWEKUkOZgD4Zal9Y72DMSPCZN1A7gGDD7lfajVd7uXk=; h=X-YMail-OSG:Received:X-Rocket-MIMEInfo:X-Mailer:References:Message-ID:Date:From:Reply-To:Subject:To:In-Reply-To:MIME-Version:Content-Type; b=3Ef3yP9O5Gz/8k4nbvSgtBgkuArZntlKDruFbXbJ/VIIq1qlYbfxIGIF1mq3FLHp2aR+ECbT5MB3KMd/dJh2KUCX5GXQLmVep7lpVvyzgWwo616kho3JMBUqJFyhqsH9uhGad+FgcT/BlSlq/i5TWxyfJw+7VNSO2pwDa2QWPOk= X-YMail-OSG: jb6qHngVM1nl969yNLWv5KtQkQjGxcJ5ejs9_QcjmP3A0Xt lhGD51BCVMGejBqLHQyyU2eRIuYtV6imrlwMQ9QlmSAcSa3wCK18B00oEAN_ kKfLEXkTsHP28ax1XDO0594jGj_tLocy1eraLz3nogtuKx1cB9VaTymNTaJY 81BFEO7_1U8kTsqDrKWOL6Z46lf92NrOnnHoC7GzXa1Pv3AFxvCIFvNuRz_d QxqAHzXxZesfSAvgKVQTBW4Cl3XgDk2S6ynvf8DhZ2fHWouj0D2IwFZEB6cj uGukI7wceCC3mMwew1hHT8eVM61nMo8buPpvkYVizeFv.v.F55pQfmiR3orN P5HXL_YSfqYM_4_vrfm0TJpyVXHK7RHdKowFmhuq3uYwAEmHIn_7PRlyC9GY BTWjptrJu1VBnYEnfbucr2ZQPfIJMeTO8MrG6U3kgHuGvDR.D82tCNHTXbSL rim0gQA.mGHMIWociBFaY8BJ4J1io0Su8D3xC0edvrTjQ86c1ogXOm1EIYou 5qs2jjC3pPOZ362lw6YJ_qtUDz7kBWxlEMoKEBOweSX1hqe0I4WKYDhrTC2p x6K8Nu4h66CbUOirVtl.3BMP5Z_NKfrcvmAHdTO8V42t8N5O2JGCCJoPHRzt pzBP1V5WqPXeLgqkpZo6ud8npDgqb6e_.kjDt0iw- Received: from [24.130.37.147] by web2801.biz.mail.ne1.yahoo.com via HTTP; Tue, 15 Oct 2013 17:03:51 PDT X-Rocket-MIMEInfo: 002.001, QWxsLAoKSSBoYXZlIHVwZGF0ZWQgdGhlIFBETSBzcGVjaWZpY2F0aW9uIHRvIGFkZCBhIHNlY29uZCBQRE0gdHlwZSB3aGljaCByZXF1aXJlcyBOTyB0aW1lIHN5bmNocm9uaXphdGlvbi4gwqAgVGhlIGRyYWZ0IGZvciBJUFBNIHdoaWNoIGRlc2NyaWJlcyBob3cgdG8gY2FsY3VsYXRlIGFuZCB1c2UgdGhlIHZhbHVlcyBkZXNjcmliZWQgaW4gdGhlIFBETS4gwqAgVGhlIElQUE0gZHJhZnQgaXM6CgpodHRwOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1lbGtpbnMtaXBwbS1wZG0tbWV0cmljcy0wMQoKCkkBMAEBAQE- X-Mailer: YahooMailWebService/0.8.160.587 References: <20131015235832.2100.62094.idtracker@ietfa.amsl.com> Message-ID: <1381881831.35197.YahooMailNeo@web2801.biz.mail.ne1.yahoo.com> Date: Tue, 15 Oct 2013 17:03:51 -0700 (PDT) From: Nalini Elkins To: v6ops WG , 6man WG , "ippm@ietf.org" In-Reply-To: <20131015235832.2100.62094.idtracker@ietfa.amsl.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="36908767-168568284-1381881831=:35197" Subject: [v6ops] Fw: New Version Notification for draft-elkins-6man-ipv6-pdm-dest-option-03.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: Nalini Elkins List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 16 Oct 2013 00:04:02 -0000 --36908767-168568284-1381881831=:35197 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable All,=0A=0AI have updated the PDM specification to add a second PDM type whi= ch requires NO time synchronization. =A0 The draft for IPPM which describes= how to calculate and use the values described in the PDM. =A0 The IPPM dra= ft is:=0A=0Ahttp://tools.ietf.org/html/draft-elkins-ippm-pdm-metrics-01=0A= =0A=0AI would appreciate any comments or feedback.=A0=0A=0A=0AA new version= of I-D, draft-elkins-6man-ipv6-pdm-dest-option-03.txt=0Ahas been successfu= lly submitted by Nalini Elkins and posted to the=0AIETF repository.=0A=0AFi= lename:=A0=A0=A0 draft-elkins-6man-ipv6-pdm-dest-option=0ARevision:=A0=A0= =A0 03=0ATitle:=A0=A0=A0 =A0=A0=A0 IPv6 Performance and Diagnostic Metric= s Destination Option=0ACreation date:=A0=A0=A0 2013-10-15=0AGroup:=A0=A0= =A0 =A0=A0=A0 Individual Submission=0ANumber of pages: 18=0AURL:=A0 =A0 = =A0 =A0 =A0 =A0 http://www.ietf.org/internet-drafts/draft-elkins-6man-ipv6= -pdm-dest-option-03.txt=0AStatus:=A0 =A0 =A0 =A0 =A0 http://datatracker.iet= f.org/doc/draft-elkins-6man-ipv6-pdm-dest-option=0AHtmlized:=A0 =A0 =A0 =A0= http://tools.ietf.org/html/draft-elkins-6man-ipv6-pdm-dest-option-03=0ADif= f:=A0 =A0 =A0 =A0 =A0 =A0 http://www.ietf.org/rfcdiff?url2=3Ddraft-elkins-6= man-ipv6-pdm-dest-option-03=0A=0AAbstract:=0A=A0 To diagnose performance a= nd connectivity problems, metrics on real=0A=A0 (non-synthetic) transmissi= on are critical for timely end-to-end=0A=A0 problem resolution. Such diagn= ostics may be real-time or after the=0A=A0 fact, but must not impact an op= erational production network. The base=0A=A0 metrics are: packet sequence = number and packet timestamp.=A0 Metrics=0A=A0 derived from these will be d= escribed separately. This document solves=0A=A0 these problems with a new = destination option, the Performance and=0A=A0 Diagnostic Metrics destinati= on option (PDM).=0A=0A=0A=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 = =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0= =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =0A=0A=0APlease note that it may t= ake a couple of minutes from the time of submission=0Auntil the htmlized ve= rsion and diff are available at tools.ietf.org.=0A=0AThe IETF Secretariat --36908767-168568284-1381881831=:35197 Content-Type: text/html; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable
All,
<= br>
I have updated the PDM specification to add a second PDM= type which requires NO time synchronization.   The draft for IPPM whi= ch describes how to calculate and use the values described in the PDM. &nbs= p; The IPPM draft is:


I would ap= preciate any comments or feedback. 

=0A
A new version of I-D, draft-elkins-6man-ipv6-pdm-dest-opt= ion-03.txt
has been successfully submitted by Nalini Elkins and posted t= o the
IETF repository.

Filename:    draft-elkins-= 6man-ipv6-pdm-dest-option
Revision:    03
Title: = ;       IPv6 Performance and Diagnostic Metrics D= estination Option
Creation date:    2013-10-15
Group:=         Individual Submission
Number of p= ages: 18
URL:            http://www.ietf.= org/internet-drafts/draft-elkins-6man-ipv6-pdm-dest-option-03.txt
Status= :          http://datatracker.ietf.org/doc/draft-e= lkins-6man-ipv6-pdm-dest-option
Htmlized:        htt= p://tools.ietf.org/html/draft-elkins-6man-ipv6-pdm-dest-option-03
Diff:&= nbsp;           http://www.ietf.org/rfcdiff?url2=3Ddraft-elkins-6man-ipv6-pdm-dest-option-= 03

Abstract:
  To diagnose performance and connectivity pro= blems, metrics on real
  (non-synthetic) transmission are critical= for timely end-to-end
  problem resolution. Such diagnostics may = be real-time or after the
  fact, but must not impact an operation= al production network. The base
  metrics are: packet sequence num= ber and packet timestamp.  Metrics
  derived from these will = be described separately. This document solves
  these problems wit= h a new destination option, the Performance and
  Diagnostic Metri= cs destination option (PDM).


          =                      = ;                     &nb= sp;                            


Please note that it may tak= e a couple of minutes from the time of submission
until the htmlized ver= sion and diff are available at tools.ietf.org.

The IETF Secretariat



--36908767-168568284-1381881831=:35197-- From v6ops@globis.net Wed Oct 16 06:15:10 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CAC7F11E82A7; Wed, 16 Oct 2013 06:15:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, 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 h3cjMEz5564x; Wed, 16 Oct 2013 06:15:10 -0700 (PDT) Received: from globis01.globis.net (RayH-1-pt.tunnel.tserv11.ams1.ipv6.he.net [IPv6:2001:470:1f14:62e::2]) by ietfa.amsl.com (Postfix) with ESMTP id B3F7B11E82AB; Wed, 16 Oct 2013 06:15:05 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by globis01.globis.net (Postfix) with ESMTP id DF19687007F; Wed, 16 Oct 2013 15:15:00 +0200 (CEST) Received: from globis01.globis.net ([127.0.0.1]) by localhost (mail.globis.net [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4-eHjwW1gte4; Wed, 16 Oct 2013 15:15:00 +0200 (CEST) Received: from Rays-iMac-2.local (unknown [192.168.0.3]) (Authenticated sender: Ray.Hunter@globis.net) by globis01.globis.net (Postfix) with ESMTPA id 915A9870073; Wed, 16 Oct 2013 15:15:00 +0200 (CEST) Message-ID: <525E9152.60209@globis.net> Date: Wed, 16 Oct 2013 15:14:58 +0200 From: Ray Hunter User-Agent: Postbox 3.0.8 (Macintosh/20130427) MIME-Version: 1.0 To: Nalini Elkins References: <20131015235832.2100.62094.idtracker@ietfa.amsl.com> <1381881831.35197.YahooMailNeo@web2801.biz.mail.ne1.yahoo.com> In-Reply-To: <1381881831.35197.YahooMailNeo@web2801.biz.mail.ne1.yahoo.com> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: v6ops WG , 6man WG , "ippm@ietf.org" Subject: Re: [v6ops] Fw: New Version Notification for draft-elkins-6man-ipv6-pdm-dest-option-03.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 16 Oct 2013 13:15:11 -0000 Nalini Elkins wrote: > All, > > I have updated the PDM specification to add a second PDM type which requires NO time synchronization. The draft for IPPM which describes how to calculate and use the values described in the PDM. The IPPM draft is: > > http://tools.ietf.org/html/draft-elkins-ippm-pdm-metrics-01 > > > I would appreciate any comments or feedback. > > > A new version of I-D, draft-elkins-6man-ipv6-pdm-dest-option-03.txt > has been successfully submitted by Nalini Elkins and posted to the > IETF repository. > > Filename: draft-elkins-6man-ipv6-pdm-dest-option > Revision: 03 > Title: IPv6 Performance and Diagnostic Metrics Destination Option > Creation date: 2013-10-15 > Group: Individual Submission > Number of pages: 18 > URL: http://www.ietf.org/internet-drafts/draft-elkins-6man-ipv6-pdm-dest-option-03.txt > Status: http://datatracker.ietf.org/doc/draft-elkins-6man-ipv6-pdm-dest-option > Htmlized: http://tools.ietf.org/html/draft-elkins-6man-ipv6-pdm-dest-option-03 > Diff: http://www.ietf.org/rfcdiff?url2=draft-elkins-6man-ipv6-pdm-dest-option-03 > > Abstract: > To diagnose performance and connectivity problems, metrics on real > (non-synthetic) transmission are critical for timely end-to-end > problem resolution. Such diagnostics may be real-time or after the > fact, but must not impact an operational production network. The base > metrics are: packet sequence number and packet timestamp. Metrics > derived from these will be described separately. This document solves > these problems with a new destination option, the Performance and > Diagnostic Metrics destination option (PDM). > > > > > > Please note that it may take a couple of minutes from the time of submission > until the htmlized version and diff are available at tools.ietf.org. > > The IETF Secretariat I have read this draft. All in all it seems rather simplistic, and I can't help thinking that there's much more to this than is expressed in the draft. For example, the server time calculation seems to assume that a response packet has to be sent immediately by every application as soon as data has been processed: every response requires a response. What additional processing is required to cater for cases where the sender and the receiver simply have nothing to say to each other at that point in time? e.g. a simple poll response protocol that is triggered every minute would seem to suggest that there's a minimum of a sixty second server processing time in the poller, when in fact it's just not doing anything at all for this process. Likewise, the calculations for round trip time do not seem to take into account any packet drops or duplicates, which would seem to suggest to me that the protocol as described would report packet drops as additional latency, rather than any sort of protocol recovery/ retransmission timers being triggered. Wouldn't the PDM sequence numbers have to be linked to TCP sequence numbers when calculating stats? And for UDP you'd have no indication (or have to use some app specific sequence number or hash to detect forward progression of the flow)? -- Regards, RayH From nalini.elkins@insidethestack.com Wed Oct 16 06:41:22 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 47BE611E82AA for ; Wed, 16 Oct 2013 06:41:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.382 X-Spam-Level: X-Spam-Status: No, score=-2.382 tagged_above=-999 required=5 tests=[AWL=0.217, 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 J4J3-3NKt1VE for ; Wed, 16 Oct 2013 06:41:14 -0700 (PDT) Received: from nm6-vm8.access.bullet.mail.gq1.yahoo.com (nm6-vm8.access.bullet.mail.gq1.yahoo.com [216.39.63.214]) by ietfa.amsl.com (Postfix) with ESMTP id 0BC6D11E8260 for ; Wed, 16 Oct 2013 06:41:09 -0700 (PDT) Received: from [216.39.60.166] by nm6.access.bullet.mail.gq1.yahoo.com with NNFMP; 16 Oct 2013 13:41:09 -0000 Received: from [216.39.60.162] by tm2.access.bullet.mail.gq1.yahoo.com with NNFMP; 16 Oct 2013 13:41:09 -0000 Received: from [127.0.0.1] by omp1028.access.mail.gq1.yahoo.com with NNFMP; 16 Oct 2013 13:41:09 -0000 X-Yahoo-Newman-Property: ymail-3 X-Yahoo-Newman-Id: 457716.22533.bm@omp1028.access.mail.gq1.yahoo.com Received: (qmail 81911 invoked by uid 60001); 16 Oct 2013 13:41:08 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s1024; t=1381930868; bh=PXTBaoBK2gyima4oe58XWR+6cc4gjXMt/q5XMgvfHWs=; h=X-YMail-OSG:Received:X-Rocket-MIMEInfo:X-Mailer:References:Message-ID:Date:From:Reply-To:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type:Content-Transfer-Encoding; b=Y8wXcmn5ZATyCGplafZEXFiPGCxQHyU5RSh5zRMZho0PkTCinAbUgTBm81VmruPaZpcKhMa+qCwcAcSF68el9XAo6DQLHLwwmeDxL8ZLFzZgRL91QVyFUQTG9ityzMhHVITCDpRWp5kL985qakkFZZe5bHacY2TIB3YeQYQ/ypQ= X-YMail-OSG: yPUi0tUVM1nlfy5zZ0Nqz5jVRtwJgJtxrCo7gdr_VOL5hq1 uiuJpgWHYYDs9AVZkxCZN0anvtPYDvG_mS_bMckAVgAuWOWZ3at5Jw5T8_Ll JpM8u8Mw7zXBm_WjFCkEfmkEIZOqRMTEoFtFpvuMxdMqEvhpORuZT27QRng2 rjCpiEAFa7tqZ.YdqvORIBmiVW.zsIiCW1I3MBNP2UcAU1UqtW4hBeCJz2rl mcyskhosTxLvuExgrl_GR4uvz4kAMIh5MntAGtAqQVdg.t4r0NDqnnbAI6f. OpoUgmpwnRFFH67UM.KiQW23eiwrC0LfmcfCVmVllYFGH22fXpzlBc97yrMj khH0TpRtLkah_STBDH5sRDy_ZizHvRZTvqwlz6aIFnp_pQv2zVWKxqzSLWna KCDLAVOmqbv7QV0BOmVbxfs3iEDNWr1h_3kkMr08nrFDOX0Cg8EVe.p4muHU 86p3pkOvhhVQxbyPs6cavM0Q_u.19_9qrJRquyta3EhIrg7MuHAoYKyUSVWO VQX7MsUuIPbuDaCI6.FHtbreCs1WZKUyybA5tC3fYEX8zEgwLtUcbMCngId0 f98uO3uTofRiqelam__tVz0U4kkBzwpJCIjF.4A-- Received: from [24.130.37.147] by web2803.biz.mail.ne1.yahoo.com via HTTP; Wed, 16 Oct 2013 06:41:08 PDT X-Rocket-MIMEInfo: 002.001, PiBJIGhhdmUgcmVhZCB0aGlzIGRyYWZ0LgoKPkFsbCBpbiBhbGwgaXQgc2VlbXMgcmF0aGVyIHNpbXBsaXN0aWMsIGFuZCBJIGNhbid0IGhlbHAgdGhpbmtpbmcgdGhhdAo.dGhlcmUncyBtdWNoIG1vcmUgdG8gdGhpcyB0aGFuIGlzIGV4cHJlc3NlZCBpbiB0aGUgZHJhZnQuCgpZZXMuIMKgVGhlcmUgaXMuIMKgU2VlIGJlbG93LgoKPkZvciBleGFtcGxlLCB0aGUgc2VydmVyIHRpbWUgY2FsY3VsYXRpb24gc2VlbXMgdG8gYXNzdW1lIHRoYXQgYSByZXNwb25zZQo.cGFja2V0IGhhcyB0byBiZSBzZW50IGltbWUBMAEBAQE- X-Mailer: YahooMailWebService/0.8.160.587 References: <20131015235832.2100.62094.idtracker@ietfa.amsl.com> <1381881831.35197.YahooMailNeo@web2801.biz.mail.ne1.yahoo.com> <525E9152.60209@globis.net> Message-ID: <1381930868.81291.YahooMailNeo@web2803.biz.mail.ne1.yahoo.com> Date: Wed, 16 Oct 2013 06:41:08 -0700 (PDT) From: Nalini Elkins To: Ray Hunter In-Reply-To: <525E9152.60209@globis.net> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Cc: v6ops WG , 6man WG , "ippm@ietf.org" Subject: Re: [v6ops] Fw: New Version Notification for draft-elkins-6man-ipv6-pdm-dest-option-03.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: Nalini Elkins List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 16 Oct 2013 13:41:22 -0000 > I have read this draft.=0A=0A>All in all it seems rather simplistic, and = I can't help thinking that=0A>there's much more to this than is expressed i= n the draft.=0A=0AYes. =C2=A0There is. =C2=A0See below.=0A=0A>For example, = the server time calculation seems to assume that a response=0A>packet has t= o be sent immediately by every application as soon as data=0A>has been proc= essed: every response requires a response.=0A=0ANot at all.=0A=0A>What addi= tional processing is required to cater for cases where the=0A>sender and th= e receiver simply have nothing to say to each other at that=0A>point in tim= e?=0A=0AFrankly, other than keep-alives, I have not seen this. =C2=A0Please= correct me if I am wrong.=0A=0AThe logic for processing and making 'sense'= of these metrics is much more complex than the fields to be sent. =C2=A0Th= is is as it should be. =C2=A0 The OS needs to send packets quickly. =C2=A0A= fter the fact, we can take our time and do analysis.=0A=0AWhat needs to be = handled (at a minimum) are the following cases. =C2=A0You may have more.=0A= =0A1. =C2=A0 Host clocks=C2=A0not synchronized - done=0A2. =C2=A0 IP fragme= ntation=C2=A0=0A3. =C2=A0 Multiple=C2=A0sends from one side (multiple segme= nts)=C2=A0=0A4. =C2=A0=C2=A0Out=C2=A0of order segments (PSN will go negativ= e)=0A5. =C2=A0=C2=A0Retransmits=C2=A0(PSN will go negative)=0A6. =C2=A0 One= =E2=80=93way transmit only (ex. FTP) =C2=A0(server delta will continually i= ncrease)=0A7 =C2=A0 =C2=A0Delayed acks=0A8. =C2=A0 ACKs preceeding send for= another reason=0A9 =C2=A0 =C2=A0Proxy servers=0A10. Full=C2=A0duplex traff= ic=0A11. Keep alive (0 / 1 byte segments, larger segments)=0A12. No respons= e from other side (your case - which I believe to fall under Keep Alives) = =C2=A0=0A,=0A=0AI have only provided the most basic case in this draft. =C2= =A0 But, have thought a great deal about these others and how they would be= handled. =C2=A0I can provide packet flows for all these above to let you k= now how these can be handled. =C2=A0Again, if you have more cases, I welcom= e your input.=0A=0AAdditionally, I am in no way suggesting that this be the= ONLY metric that is used to calculate errors or performance. =C2=A0For exa= mple, =C2=A0if you look at my definition of the "Retransmit Duplication" me= tric, you will see that TCP sequence number is used in addition to the Pack= et Sequence Number to good effect.=C2=A0=0A=C2=A0=0A=C2=A0=0ARegards,=0ARay= H From v6ops@globis.net Wed Oct 16 07:14:28 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C9B3B11E81D3; Wed, 16 Oct 2013 07:14:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, 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 2e4v9xPSUB-k; Wed, 16 Oct 2013 07:14:28 -0700 (PDT) Received: from globis01.globis.net (RayH-1-pt.tunnel.tserv11.ams1.ipv6.he.net [IPv6:2001:470:1f14:62e::2]) by ietfa.amsl.com (Postfix) with ESMTP id 2322C11E81DB; Wed, 16 Oct 2013 07:14:26 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by globis01.globis.net (Postfix) with ESMTP id E4D05870074; Wed, 16 Oct 2013 16:14:24 +0200 (CEST) Received: from globis01.globis.net ([127.0.0.1]) by localhost (mail.globis.net [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ucbpHUt47nty; Wed, 16 Oct 2013 16:14:24 +0200 (CEST) Received: from Rays-iMac-2.local (unknown [192.168.0.3]) (Authenticated sender: Ray.Hunter@globis.net) by globis01.globis.net (Postfix) with ESMTPA id C2E69870073; Wed, 16 Oct 2013 16:14:24 +0200 (CEST) Message-ID: <525E9F3F.2020600@globis.net> Date: Wed, 16 Oct 2013 16:14:23 +0200 From: Ray Hunter User-Agent: Postbox 3.0.8 (Macintosh/20130427) MIME-Version: 1.0 To: Nalini Elkins References: <20131015235832.2100.62094.idtracker@ietfa.amsl.com> <1381881831.35197.YahooMailNeo@web2801.biz.mail.ne1.yahoo.com> <525E9152.60209@globis.net> <1381930868.81291.YahooMailNeo@web2803.biz.mail.ne1.yahoo.com> In-Reply-To: <1381930868.81291.YahooMailNeo@web2803.biz.mail.ne1.yahoo.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Cc: v6ops WG , 6man WG , "ippm@ietf.org" Subject: Re: [v6ops] Fw: New Version Notification for draft-elkins-6man-ipv6-pdm-dest-option-03.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 16 Oct 2013 14:14:28 -0000 > Nalini Elkins > 16 October 2013 15:41 >> I have read this draft. > >> All in all it seems rather simplistic, and I can't help thinking that >> there's much more to this than is expressed in the draft. > > Yes. There is. See below. Then I would humbly suggest that you consider keeping this as a clean standards track draft just defining the message formats for the transport (in 6man WG) = Section 1 & 2, and leave the use cases, architecture, and calculations to other informational drafts (e.g. in ippm) = Section 3,4. c.f. SNMP >> For example, the server time calculation seems to assume that a response >> packet has to be sent immediately by every application as soon as data >> has been processed: every response requires a response. > > Not at all. > >> What additional processing is required to cater for cases where the >> sender and the receiver simply have nothing to say to each other at that >> point in time? > > Frankly, other than keep-alives, I have not seen this. Please correct me if I am wrong. > > The logic for processing and making 'sense' of these metrics is much more complex than the fields to be sent. This is as it should be. The OS needs to send packets quickly. After the fact, we can take our time and do analysis. > > What needs to be handled (at a minimum) are the following cases. You may have more. > > 1. Host clocks not synchronized - done > 2. IP fragmentation > 3. Multiple sends from one side (multiple segments) > 4. Out of order segments (PSN will go negative) > 5. Retransmits (PSN will go negative) > 6. One–way transmit only (ex. FTP) (server delta will continually increase) > 7 Delayed acks > 8. ACKs preceeding send for another reason > 9 Proxy servers > 10. Full duplex traffic > 11. Keep alive (0 / 1 byte segments, larger segments) > 12. No response from other side (your case - which I believe to fall under Keep Alives) > , > > I have only provided the most basic case in this draft. But, have thought a great deal about these others and how they would be handled. I can provide packet flows for all these above to let you know how these can be handled. Again, if you have more cases, I welcome your input. 6. one way transmit only (e.g.real time transports and streaming protocols, although RTP has it's own timestamps based on NTP) 13. Drop without retransmit (real time transports) 14. Looped packets (where the same packet may pass the same point multiple times without duplication) 15. Multihoming via Shim6 > Additionally, I am in no way suggesting that this be the ONLY metric that is used to calculate errors or performance. For example, if you look at my definition of the "Retransmit Duplication" metric, you will see that TCP sequence number is used in addition to the Packet Sequence Number to good effect. > > -- Regards, RayH From nalini.elkins@insidethestack.com Wed Oct 16 07:28:03 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 41BCA11E82AB for ; Wed, 16 Oct 2013 07:28:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.413 X-Spam-Level: X-Spam-Status: No, score=-2.413 tagged_above=-999 required=5 tests=[AWL=0.186, 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 0CjBe0aASbmH for ; Wed, 16 Oct 2013 07:27:56 -0700 (PDT) Received: from nm4-vm9.access.bullet.mail.bf1.yahoo.com (nm4-vm9.access.bullet.mail.bf1.yahoo.com [216.109.114.120]) by ietfa.amsl.com (Postfix) with ESMTP id 4FD6611E8260 for ; Wed, 16 Oct 2013 07:27:56 -0700 (PDT) Received: from [66.196.81.164] by nm4.access.bullet.mail.bf1.yahoo.com with NNFMP; 16 Oct 2013 14:27:55 -0000 Received: from [66.196.81.153] by tm10.access.bullet.mail.bf1.yahoo.com with NNFMP; 16 Oct 2013 14:27:55 -0000 Received: from [127.0.0.1] by omp1029.access.mail.bf1.yahoo.com with NNFMP; 16 Oct 2013 14:27:55 -0000 X-Yahoo-Newman-Property: ymail-3 X-Yahoo-Newman-Id: 686565.35587.bm@omp1029.access.mail.bf1.yahoo.com Received: (qmail 16838 invoked by uid 60001); 16 Oct 2013 14:27:55 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s1024; t=1381933675; bh=vyXxIzfBO5pxgoDZyas51ZQJGK5zOWp8DDcQs6NzN9E=; h=X-YMail-OSG:Received:X-Rocket-MIMEInfo:X-Mailer:References:Message-ID:Date:From:Reply-To:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type:Content-Transfer-Encoding; b=OvJMIay+Lsv/T9vmYTrMqx759OxrWSXupHh3M0w7p1OHKjMrpkjDf28l0AqCzI3Btkd3++I5YugAGB8tU4bmbSJdUpXXsiLyNbohPylT+pLaOWgmMKPdRHwTCBqJP5b2udyzUinxrPDmIiE+IvCLZO3XfG33KSyS0v5gKx++PkM= X-YMail-OSG: hY5N5ykVM1mHmqJizrmjHCT4oNTk7BAoILWiQ9ltii1GVqr SlP_EdbfG6it6nleU6mGYTwTpIJFmlZopS.oOGeNTKDG625v9m5v2k1ia4dp 7ilhmU69MZ_lx_CHfc2svhwOF4w2t7YrU.TTgvalckqrAtuNUO479gdJ2GjV tBgSgwmdT1SQIC1q1._qLl09PdwfWRBs.kXPgPWcZ.od6a0VhfcxIwoVt51t iSgJ7p9pFF3xJbfy5O2nIxnKOtsm_ofjd3v.h1LuPQ2AaVtbD9AGsnF7iIgY rfqxH5d9iDm.xpCfqFWpI8KnoqiHg.B6uLjIIpNnt2PBuKFKIzpYwpqwdNc9 E640KTnXK1GhpzCza1vAbdSuznLiHnm3OUiuAAtjB5qwVFr_5PJdo7QB8BMj mMzwuOT.CNZt3fg4MCEUlEZzS5jphERZphOaY9Z9jfT2aiYC2ayuhCYj1Slg QYEbwyksTCtd6HDxvbtPoZ7TXVPkZi3qPoe.mkH9zZrFvD0600yWkXvbw5Iv LIOP4SYoF3Pn067qyRUINLQcq6rRbg54OjDAUMGOM17_r4HF6Ua9LQfL_MPa 0Px24YjF67TSw0a8x_C4F3dhdlw8PmRTlMln0dw-- Received: from [24.130.37.147] by web2803.biz.mail.ne1.yahoo.com via HTTP; Wed, 16 Oct 2013 07:27:55 PDT X-Rocket-MIMEInfo: 002.001, UmF5LAoKVGhhbmsgeW91IHZlcnkgbXVjaCBmb3IgeW91ciBjb21tZW50cyBhbmQgeW91ciBncmVhdCB1c2UgY2FzZXMuCsKgCj4.PiBJIGhhdmUgcmVhZCB0aGlzIGRyYWZ0LgoKPj4KPj4.IEFsbCBpbiBhbGwgaXQgc2VlbXMgcmF0aGVyIHNpbXBsaXN0aWMsIGFuZCBJIGNhbid0IGhlbHAgdGhpbmtpbmcgdGhhdAo.Pj4gdGhlcmUncyBtdWNoIG1vcmUgdG8gdGhpcyB0aGFuIGlzIGV4cHJlc3NlZCBpbiB0aGUgZHJhZnQuCj4.Cj4.IFllcy7CoCBUaGVyZSBpcy7CoCBTZWUgYmVsb3cuCgo.wqBUaGVuIEkgd28BMAEBAQE- X-Mailer: YahooMailWebService/0.8.160.587 References: <20131015235832.2100.62094.idtracker@ietfa.amsl.com> <1381881831.35197.YahooMailNeo@web2801.biz.mail.ne1.yahoo.com> <525E9152.60209@globis.net> <1381930868.81291.YahooMailNeo@web2803.biz.mail.ne1.yahoo.com> <525E9F3F.2020600@globis.net> Message-ID: <1381933675.16692.YahooMailNeo@web2803.biz.mail.ne1.yahoo.com> Date: Wed, 16 Oct 2013 07:27:55 -0700 (PDT) From: Nalini Elkins To: Ray Hunter In-Reply-To: <525E9F3F.2020600@globis.net> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Cc: v6ops WG , 6man WG , "ippm@ietf.org" Subject: Re: [v6ops] Fw: New Version Notification for draft-elkins-6man-ipv6-pdm-dest-option-03.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: Nalini Elkins List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 16 Oct 2013 14:28:03 -0000 Ray,=0A=0AThank you very much for your comments and your great use cases.= =0A=A0=0A>>> I have read this draft.=0A=0A>>=0A>>> All in all it seems rath= er simplistic, and I can't help thinking that=0A>>> there's much more to th= is than is expressed in the draft.=0A>>=0A>> Yes.=A0 There is.=A0 See below= .=0A=0A>=A0Then I would humbly suggest that you consider keeping this as a = clean=0A>standards track draft just defining the message formats for the=0A= >transport (in 6man WG) =3D Section 1 & 2, and leave the use cases,=0A>arch= itecture, and calculations to other informational drafts (e.g. in=0A>ippm) = =3D Section 3,4. c.f. SNMP=0A=A0=0AI will do this and provide an updated ve= rsion of both IPPM and 6Man documents by end of day today. =A0I will also a= dd use cases to the IPPM document.=0A=0AIf any others have use cases or com= ments, I would very much appreciate hearing from you.=0A=0AThanks,=0ANalini From internet-drafts@ietf.org Wed Oct 16 12:03:14 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3D7FB11E8335; Wed, 16 Oct 2013 12:03:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.574 X-Spam-Level: X-Spam-Status: No, score=-102.574 tagged_above=-999 required=5 tests=[AWL=0.026, 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 0FHQ62EiZ17H; Wed, 16 Oct 2013 12:03:13 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 2419611E81E0; Wed, 16 Oct 2013 12:03:06 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 4.80.p2 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20131016190306.16404.45502.idtracker@ietfa.amsl.com> Date: Wed, 16 Oct 2013 12:03:06 -0700 Cc: v6ops@ietf.org Subject: [v6ops] I-D Action: draft-ietf-v6ops-enterprise-incremental-ipv6-04.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 16 Oct 2013 19:03:14 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the IPv6 Operations Working Group of the IETF. Title : Enterprise IPv6 Deployment Guidelines Author(s) : Kiran K. Chittimaneni Tim Chown Lee Howard Victor Kuarsingh Yanick Pouffary Eric Vyncke Filename : draft-ietf-v6ops-enterprise-incremental-ipv6-04.txt Pages : 35 Date : 2013-10-16 Abstract: Enterprise network administrators worldwide are in various stages of preparing for or deploying IPv6 into their networks. The administrators face different challenges than operators of Internet access providers, and have reasons for different priorities. The overall problem for many administrators will be to offer Internet- facing services over IPv6, while continuing to support IPv4, and while introducing IPv6 access within the enterprise IT network. The overall transition will take most networks from an IPv4-only environment to a dual stack network environment and eventually an IPv6-only operating mode. This document helps provide a framework for enterprise network architects or administrators who may be faced with many of these challenges as they consider their IPv6 support strategies. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-v6ops-enterprise-incremental-ip= v6 There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-v6ops-enterprise-incremental-ipv6-04 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-v6ops-enterprise-incremental-= ipv6-04 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nalini.elkins@insidethestack.com Wed Oct 16 20:25:26 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 62AAB11E823C for ; Wed, 16 Oct 2013 20:25:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.468 X-Spam-Level: X-Spam-Status: No, score=-2.468 tagged_above=-999 required=5 tests=[AWL=0.130, 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 uz9Rs5xQ3irp for ; Wed, 16 Oct 2013 20:25:26 -0700 (PDT) Received: from nm7-vm5.access.bullet.mail.bf1.yahoo.com (nm7-vm5.access.bullet.mail.bf1.yahoo.com [216.109.114.164]) by ietfa.amsl.com (Postfix) with ESMTP id 547CE11E8236 for ; Wed, 16 Oct 2013 20:25:10 -0700 (PDT) Received: from [66.196.81.164] by nm7.access.bullet.mail.bf1.yahoo.com with NNFMP; 17 Oct 2013 03:25:06 -0000 Received: from [66.196.81.128] by tm10.access.bullet.mail.bf1.yahoo.com with NNFMP; 17 Oct 2013 03:25:06 -0000 Received: from [127.0.0.1] by omp1004.access.mail.bf1.yahoo.com with NNFMP; 17 Oct 2013 03:25:06 -0000 X-Yahoo-Newman-Property: ymail-3 X-Yahoo-Newman-Id: 279888.9161.bm@omp1004.access.mail.bf1.yahoo.com Received: (qmail 38103 invoked by uid 60001); 17 Oct 2013 03:25:06 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s1024; t=1381980306; bh=mh+oOdKCb2QvARY0zwoNtRPnZbCODjlb33S9+KrICg0=; h=X-YMail-OSG:Received:X-Rocket-MIMEInfo:X-Mailer:References:Message-ID:Date:From:Reply-To:Subject:To:In-Reply-To:MIME-Version:Content-Type; b=nzxBSXhwYbz0s/nMnFUB0m0I1TEgSHOT3gcRyf4zh7mjWp7KFo5TD8hS/vYdpVIVID5VqyyZnZdtnzY4aIKpy5s43NJi1dLFLKasCtm1fRKCtyew0k4uwgKtV0lBnhT9N0AmYwPt2qykrZ5/TBABR2T9KCBigL/7ttlHwaRI88k= X-YMail-OSG: 1sz_vFYVM1ngcJrIW7V59MZW_xiOO6tZT.SNylU6w7CYKJz 9F7drv1c3ENvQxsGYwfBhqAxOkRKh_pqMBDSeRXrqUUPsw59enSew6ISqzor 5Ca_30y4RB0yw8MoH0LZE4BRESTUNcvIOK2rBEomPNi7ZparDoYpPATPuEci cHMM1tdhOR6Dy1EcLQk0RVTL3EkNk_FdHwUNoMfGb9wgkywvBqzSGezCODvU UMR.A9o8ewqAkbci.JJA_fze7O4JtdHat6wZdr9_EtKQ7OSD0SLxwb1gbOlk .kDW8qv5PTLh_zUKpHll.EJJABj_oXWnPNEvyZOv5AoQFZaUMXIE2jen4TwX ZuInf_NZsn6t2BdJaQ4w3GA3qbhY5wjavDoEu9DpuAdnGhILXJynNvHnjb4f p9TyRS1PY78Z9QiMGuu08dSNjJV00.x9WZ6rp2wLLlYdaftXzJqWz4YiDfRD tWeZoA16uK4kkiue.IYJnNk13htS9GFC0h._MT43w80pgxUG24LDK5Hc50wA uYEJih4PoJSwZ3ubuczlblctvdjcb13RzEmsdM2s8CufkzJ074BWqqAE45ND __iYU8pk86lSMRDKuOk2G40d8pBkecKufNHKnnA6_enl3k8JfNQpW3nMvhv2 SbXqTo4HE0s9_4KD7MdA6Q2xXxX6Df8jBNTqPAJM- Received: from [24.130.37.147] by web2803.biz.mail.ne1.yahoo.com via HTTP; Wed, 16 Oct 2013 20:25:05 PDT X-Rocket-MIMEInfo: 002.001, QWxsLAoKSSBoYXZlIHJldmlzZWQgdGhlIDZtYW4gc3VibWlzc2lvbiB0byB0YWtlIG91dCB0aGUgY2FsY3VsYXRpb25zIGFuZCBwYWNrZXQgZmxvd3MuIMKgQWxsIG9mIHRoZXNlIGFyZSBpbiB0aGUgSVBQTSBkb2N1bWVudC4gwqAgQSBub3RhdGlvbiBvZiBhbGwgdGhlIHVzYWdlIGNhc2VzIHRoYXQgdGhpcyBtZXRob2RvbG9neSBzaG91bGQgaGFuZGxlIGhhcyBhbHNvIGJlZW7CoGFkZGVkIHRvIHRoZSBJUFBNIGRyYWZ0LgoKVGhlIElQUE0gZHJhZnQgaXMgaGVyZTrCoGh0dHA6Ly9kYXRhdHJhY2tlci5pZXQBMAEBAQE- X-Mailer: YahooMailWebService/0.8.160.587 References: <20131017032024.5051.20799.idtracker@ietfa.amsl.com> Message-ID: <1381980305.36254.YahooMailNeo@web2803.biz.mail.ne1.yahoo.com> Date: Wed, 16 Oct 2013 20:25:05 -0700 (PDT) From: Nalini Elkins To: v6ops WG , 6man WG , "ippm@ietf.org" In-Reply-To: <20131017032024.5051.20799.idtracker@ietfa.amsl.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="-1551098171-1958070460-1381980305=:36254" Subject: [v6ops] Fw: New Version Notification for draft-elkins-6man-ipv6-pdm-dest-option-04.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: Nalini Elkins List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 17 Oct 2013 03:25:26 -0000 ---1551098171-1958070460-1381980305=:36254 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable All,=0A=0AI have revised the 6man submission to take out the calculations a= nd packet flows. =A0All of these are in the IPPM document. =A0 A notation o= f all the usage cases that this methodology should handle has also been=A0a= dded to the IPPM draft.=0A=0AThe IPPM draft is here:=A0http://datatracker.i= etf.org/doc/draft-elkins-ippm-pdm-metrics/=0A=0AThe 6man draft is below.=0A= =0AI appreciate any thoughts and comments.=0A=0AA new version of I-D, draft= -elkins-6man-ipv6-pdm-dest-option-04.txt=0Ahas been successfully submitted = by Nalini Elkins and posted to the=0AIETF repository.=0A=0AFilename:=A0=A0= =A0 draft-elkins-6man-ipv6-pdm-dest-option=0ARevision:=A0=A0=A0 04=0ATitl= e:=A0=A0=A0 =A0=A0=A0 IPv6 Performance and Diagnostic Metrics Destination = Option=0ACreation date:=A0=A0=A0 2013-10-16=0AGroup:=A0=A0=A0 =A0=A0=A0 I= ndividual Submission=0ANumber of pages: 12=0AURL:=A0 =A0 =A0 =A0 =A0 =A0 h= ttp://www.ietf.org/internet-drafts/draft-elkins-6man-ipv6-pdm-dest-option-0= 4.txt=0AStatus:=A0 =A0 =A0 =A0 =A0 http://datatracker.ietf.org/doc/draft-el= kins-6man-ipv6-pdm-dest-option=0AHtmlized:=A0 =A0 =A0 =A0 http://tools.ietf= .org/html/draft-elkins-6man-ipv6-pdm-dest-option-04=0ADiff:=A0 =A0 =A0 =A0 = =A0 =A0 http://www.ietf.org/rfcdiff?url2=3Ddraft-elkins-6man-ipv6-pdm-dest-= option-04=0A=0AAbstract:=0A=A0 To diagnose performance and connectivity pr= oblems, metrics on real=0A=A0 (non-synthetic) transmission are critical fo= r timely end-to-end=0A=A0 problem resolution. Such diagnostics may be real= -time or after the=0A=A0 fact, but must not impact an operational producti= on network. The base=0A=A0 metrics are: packet sequence number and packet = timestamp.=A0 Metrics=0A=A0 derived from these will be described separatel= y. This document solves=0A=A0 these problems with a new destination option= , the Performance and=0A=A0 Diagnostic Metrics destination option (PDM).= =0A=0A=0A=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 = =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0= =A0 =A0 =A0 =A0 =A0 =A0 =0A=0A=0APlease note that it may take a couple of = minutes from the time of submission=0Auntil the htmlized version and diff a= re available at tools.ietf.org.=0A=0AThe IETF Secretariat ---1551098171-1958070460-1381980305=:36254 Content-Type: text/html; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable
All,
<= br>
I have revised the 6man submission to take out the calcu= lations and packet flows.  All of these are in the IPPM document. &nbs= p; A notation of all the usage cases that this methodology should handle ha= s also been adde= d to the IPPM draft.


The 6man draft is below.

I appreciate any thoughts and comments.
=0A
A new version of I-D, draft-elki= ns-6man-ipv6-pdm-dest-option-04.txt
has been successfully submitted by N= alini Elkins and posted to the
IETF repository.

Filename: &n= bsp;  draft-elkins-6man-ipv6-pdm-dest-option
Revision:  =   04
Title:        IPv6 Performance= and Diagnostic Metrics Destination Option
Creation date:  &nb= sp; 2013-10-16
Group:        Individual = Submission
Number of pages: 12
URL:         =   http://www.ietf.org/internet-drafts/draft-elkins-6man-ipv6-pdm-des= t-option-04.txt
Status:          http://datatra= cker.ietf.org/doc/draft-elkins-6man-ipv6-pdm-dest-option
Htmlized: =       http://tools.ietf.org/html/draft-elkins-6man-ipv6-pdm= -dest-option-04
Diff:            http://www.ietf.org/rfcdiff?url2=3Ddraft-elkins-6man-ipv6-pdm-dest-option-= 04

Abstract:
  To diagnose performance and connectivity pro= blems, metrics on real
  (non-synthetic) transmission are critical= for timely end-to-end
  problem resolution. Such diagnostics may = be real-time or after the
  fact, but must not impact an operation= al production network. The base
  metrics are: packet sequence num= ber and packet timestamp.  Metrics
  derived from these will = be described separately. This document solves
  these problems wit= h a new destination option, the Performance and
  Diagnostic Metri= cs destination option (PDM).


          =                      = ;                     &nb= sp;                            


Please note that it may tak= e a couple of minutes from the time of submission
until the htmlized ver= sion and diff are available at tools.ietf.org.

The IETF Secretariat



---1551098171-1958070460-1381980305=:36254-- From fred@cisco.com Fri Oct 18 05:45:10 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0D7CC11E822C for ; Fri, 18 Oct 2013 05:45:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.599 X-Spam-Level: X-Spam-Status: No, score=-110.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, 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 pIR0ziiiLORW for ; Fri, 18 Oct 2013 05:45:05 -0700 (PDT) Received: from mtv-iport-3.cisco.com (mtv-iport-3.cisco.com [173.36.130.14]) by ietfa.amsl.com (Postfix) with ESMTP id 75AEC11E8294 for ; Fri, 18 Oct 2013 05:45:04 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=128; q=dns/txt; s=iport; t=1382100304; x=1383309904; h=date:from:message-id:to:subject:cc; bh=+xad9YPAB+gBvA83f1pV1XW+GniCXoBUL9kXVqEUzNk=; b=NA34GdB6jIxRZfiQ5VsKvaCJZKcLWPaALLJvPMxwoMm05cC/bE0KyjOx 8jMh3ljS5/+tucmYjngyiHbnQjaDfd8CvQvsnKHtOOPKLU/hBTX1fTS/J AfriVWWn+Rd7JAs8OFpE3pxRm0pa++Qjq99udILHSTfIsEbtOgh1mGQ4w k=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AoEHAN4sYVKrRDoH/2dsb2JhbABagwc4rD4BkioJgSQWdIMlPC0HiGYNwFSPVh2DCYEKA4k/j3mQWINE X-IronPort-AV: E=Sophos;i="4.93,522,1378857600"; d="scan'208";a="92434878" Received: from mtv-core-2.cisco.com ([171.68.58.7]) by mtv-iport-3.cisco.com with ESMTP; 18 Oct 2013 12:45:02 +0000 Received: from ftpeng-update.cisco.com (ftpeng-update.cisco.com [171.69.17.32]) by mtv-core-2.cisco.com (8.14.5/8.14.5) with ESMTP id r9ICj0KE004122; Fri, 18 Oct 2013 12:45:00 GMT Received: (fred@localhost) by ftpeng-update.cisco.com (8.11.2/CISCO.WS.1.2) id r9ICj0D01738; Fri, 18 Oct 2013 05:45:00 -0700 (PDT) Date: Fri, 18 Oct 2013 05:45:00 -0700 (PDT) From: Message-Id: <201310181245.r9ICj0D01738@ftpeng-update.cisco.com> To: v6ops@ietf.org Cc: draft-ma-v6ops-router-test@tools.ietf.org Subject: [v6ops] new draft: draft-ma-v6ops-router-test X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 18 Oct 2013 12:45:10 -0000 A new draft has been posted, at http://tools.ietf.org/html/draft-ma-v6ops-router-test. Please take a look at it and comment. From Ted.Lemon@nominum.com Sat Oct 19 16:17:23 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3191011E82E2 for ; Sat, 19 Oct 2013 16:17:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.592 X-Spam-Level: X-Spam-Status: No, score=-106.592 tagged_above=-999 required=5 tests=[AWL=0.007, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8dtrU00xRX92 for ; Sat, 19 Oct 2013 16:17:17 -0700 (PDT) Received: from exprod7og114.obsmtp.com (exprod7og114.obsmtp.com [64.18.2.215]) by ietfa.amsl.com (Postfix) with ESMTP id 3E67511E82D6 for ; Sat, 19 Oct 2013 16:17:17 -0700 (PDT) Received: from shell-too.nominum.com ([64.89.228.229]) (using TLSv1) by exprod7ob114.postini.com ([64.18.6.12]) with SMTP ID DSNKUmMS/IMhXLPp5Fa9+EF3qum1xPHPxHVe@postini.com; Sat, 19 Oct 2013 16:17:17 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 DE78C1B82CB for ; Sat, 19 Oct 2013 16:17:15 -0700 (PDT) Received: from webmail.nominum.com (cas-01.win.nominum.com [64.89.228.131]) (using TLSv1 with cipher RC4-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 BEE16190060; Sat, 19 Oct 2013 16:17:15 -0700 (PDT) (envelope-from Ted.Lemon@nominum.com) Received: from [10.0.10.40] (192.168.1.10) by CAS-01.WIN.NOMINUM.COM (192.168.1.100) with Microsoft SMTP Server (TLS) id 14.3.158.1; Sat, 19 Oct 2013 16:17:09 -0700 Content-Type: text/plain; charset="windows-1252" MIME-Version: 1.0 (Mac OS X Mail 7.0 \(1812\)) From: Ted Lemon In-Reply-To: <201307301245.r6UCj0k13216@ftpeng-update.cisco.com> Date: Sat, 19 Oct 2013 19:17:06 -0400 Content-Transfer-Encoding: quoted-printable Message-ID: <3FA123B5-FC2C-4934-BD64-87D3E515D333@nominum.com> References: <201307301245.r6UCj0k13216@ftpeng-update.cisco.com> To: "Fred Baker (fred)" X-Mailer: Apple Mail (2.1812) X-Originating-IP: [192.168.1.10] Cc: draft-smith-v6ops-ce-dhcpv6-transparency@tools.ietf.org, IPv6 Ops WG Subject: Re: [v6ops] new draft: draft-smith-v6ops-ce-dhcpv6-transparency X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 19 Oct 2013 23:17:23 -0000 On Jul 30, 2013, at 8:45 AM, fred@cisco.com wrote: > A new draft has been posted, at = http://tools.ietf.org/html/draft-smith-v6ops-ce-dhcpv6-transparency. = Please take a look at it and comment. Very belated reply=97sorry. This document is sort of close, but there are a few issues. First of = all, there should be no relay; rather, the CE router should, when it = receives a request, issue _its own_ information request to the PE relay. = It would provide no information about the client to the PE relay, but = instead would use its own information. This model would be followed = both for stateless and stateful. This is necessary for two reasons. First, some DHCP parameters need to = come from the CE router, not the provider. Second, as is noted in this = document's security considerations section, revealing information about = clients on the local network is a privacy issue, and should be avoided. Of course, this solution creates some problems in cases where for = example vendor-specific options need to be communicated upstream, but = realistically the provider isn't going to have custom configuration = information like that in their DHCP server or, if they do, for devices = like a provider-specific VoIP device, it should be handled with a = specific extension that ensures that _only_ such information as is = necessary is communicated upstream. Aside from these comments, the general flow of the proposed solution = seems right. It probably make sense to decouple information requests = and use caching and information refresh timers to maintain local = information for local clients, but that's the only substantial change = I'd suggest. This would provide some degree of control over revealing = information about the comings and goings of users of devices on the home = network. It does add complexity to the implementation, though, = particularly in the case where device-specific configuration information = needs to be maintained, such as in the case where the device asks to = send a vendor class identifier upstream.= From v6ops@globis.net Sun Oct 20 05:07:43 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 25B9E11E83B7; Sun, 20 Oct 2013 05:07:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id D86ek-V6F8fQ; Sun, 20 Oct 2013 05:07:42 -0700 (PDT) Received: from globis01.globis.net (RayH-1-pt.tunnel.tserv11.ams1.ipv6.he.net [IPv6:2001:470:1f14:62e::2]) by ietfa.amsl.com (Postfix) with ESMTP id DD26611E81B0; Sun, 20 Oct 2013 05:07:41 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by globis01.globis.net (Postfix) with ESMTP id 05DC1870076; Sun, 20 Oct 2013 14:07:33 +0200 (CEST) Received: from globis01.globis.net ([127.0.0.1]) by localhost (mail.globis.net [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2FVtSBQZRb1a; Sun, 20 Oct 2013 14:07:32 +0200 (CEST) Received: from Rays-iMac-2.local (unknown [192.168.0.3]) (Authenticated sender: Ray.Hunter@globis.net) by globis01.globis.net (Postfix) with ESMTPA id C7D7987003F; Sun, 20 Oct 2013 14:07:32 +0200 (CEST) Message-ID: <5263C783.1080001@globis.net> Date: Sun, 20 Oct 2013 14:07:31 +0200 From: Ray Hunter User-Agent: Postbox 3.0.8 (Macintosh/20130427) MIME-Version: 1.0 To: Nalini Elkins References: <20131017032024.5051.20799.idtracker@ietfa.amsl.com> <1381980305.36254.YahooMailNeo@web2803.biz.mail.ne1.yahoo.com> In-Reply-To: <1381980305.36254.YahooMailNeo@web2803.biz.mail.ne1.yahoo.com> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: v6ops WG , 6man WG , "ippm@ietf.org" Subject: Re: [v6ops] Fw: New Version Notification for draft-elkins-6man-ipv6-pdm-dest-option-04.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 20 Oct 2013 12:07:43 -0000 Nalini Elkins wrote: > All, > > I have revised the 6man submission to take out the calculations and packet flows. All of these are in the IPPM document. A notation of all the usage cases that this methodology should handle has also been added to the IPPM draft. > > The IPPM draft is here: http://datatracker.ietf.org/doc/draft-elkins-ippm-pdm-metrics/ > > The 6man draft is below. > > I appreciate any thoughts and comments. > > A new version of I-D, draft-elkins-6man-ipv6-pdm-dest-option-04.txt > has been successfully submitted by Nalini Elkins and posted to the > IETF repository. > > Filename: draft-elkins-6man-ipv6-pdm-dest-option > Revision: 04 > Title: IPv6 Performance and Diagnostic Metrics Destination Option > Creation date: 2013-10-16 > Group: Individual Submission > Number of pages: 12 > URL: http://www.ietf.org/internet-drafts/draft-elkins-6man-ipv6-pdm-dest-option-04.txt > Status: http://datatracker.ietf.org/doc/draft-elkins-6man-ipv6-pdm-dest-option > Htmlized: http://tools.ietf.org/html/draft-elkins-6man-ipv6-pdm-dest-option-04 > Diff: http://www.ietf.org/rfcdiff?url2=draft-elkins-6man-ipv6-pdm-dest-option-04 > > Abstract: > To diagnose performance and connectivity problems, metrics on real > (non-synthetic) transmission are critical for timely end-to-end > problem resolution. Such diagnostics may be real-time or after the > fact, but must not impact an operational production network. The base > metrics are: packet sequence number and packet timestamp. Metrics > derived from these will be described separately. This document solves > these problems with a new destination option, the Performance and > Diagnostic Metrics destination option (PDM). > > > > > > Please note that it may take a couple of minutes from the time of submission > until the htmlized version and diff are available at tools.ietf.org. > > The IETF Secretariat Given that it seems to me that: 1) encoding has to be fast, but decoding does not 2) a node's clock could be either in our out of synch with some notional master clock (e.g. via NTP) 3) two clocks could be in synch to a master source, but the master sources may themselves not share a common source (one sourced from GPS, one from DCF77) 4) the key to being able to perform the end to end calculations is whether two communicating nodes are synchronised to the same master clock (within some level of error/jitter) 5) the absolute time is not particularly important Q1. Why do you want to encode differences as deltas in the case of an unsynchronised/ free running clock? Isn't that slow, and difficult for hardware implementations to achieve (e.g. TCP offload)? Doesn't it also require maintaining large amounts of state in the sending node. Why not just encode the timestamp as-is and perform the appropriate difference calculation during decoding? Q2. Why do you need two separate packet formats at all? Why not have a common format for all cases, containing a timestamp based on the local clock, plus an optional field containing a flag that states if the local timestamp is coordinated to some master clock, plus an identifier for the master clock. You could then encode whether a node had a free-running clock (case 2), a synchronised clock (case 1), and whether it was synched via NTP to some stratum 0 source e.g. GPS, and also some identification of the stratum 1 source (IPv6 address). Two communicating nodes could then use e.g. NTP trace to see if they shared a common clock source or not, before performing their calculations. IMHO that would then allow you to place some error bounds on your time calculations, whilst also simplifying the implementation for the sender. -- Regards, RayH From lorenzo@google.com Mon Oct 21 01:38:43 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8D0EF11E836F for ; Mon, 21 Oct 2013 01:38:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.917 X-Spam-Level: X-Spam-Status: No, score=-1.917 tagged_above=-999 required=5 tests=[AWL=0.060, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, 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 ZHlWMdjJi-SC for ; Mon, 21 Oct 2013 01:38:40 -0700 (PDT) Received: from mail-ie0-x22c.google.com (mail-ie0-x22c.google.com [IPv6:2607:f8b0:4001:c03::22c]) by ietfa.amsl.com (Postfix) with ESMTP id 5C91911E8365 for ; Mon, 21 Oct 2013 01:38:32 -0700 (PDT) Received: by mail-ie0-f172.google.com with SMTP id tp5so11203987ieb.3 for ; Mon, 21 Oct 2013 01:38:29 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=zu5vINMbYTpYHs5XXBhuYcJbEa/lWdOCGTMtUFB54cI=; b=BNRd3pP22L7J1YRthOtnX+2KOr35v5DHmvcmoXXmtRdktZIgwN9lPThFH5463tCiPI D9bFagkPxsHPL9TbyHL3TnCL/6gqc8cmIGud1aYrca72l5FUhV0FpH3Bet5WkA8LoYd4 uZZvMiLAlvqRNI02dYvKO5x9JM9lo+xddZfjpFbDsIIKjVGC4bWTJAoxQlvUkvTS/n/2 mb8E6CcdTl5d9MDywfKdJj1paW87auHqAKZHAvRrx55Mba5kLUtiirkDOg8B+Mb3KzwP jcSfuY/6xEP9m0cG53Z2G+nEYpY9eomztegH2gKMyen7Zx34fPYP2Jk5OwWTUSKWDBZc Q8Hw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type; bh=zu5vINMbYTpYHs5XXBhuYcJbEa/lWdOCGTMtUFB54cI=; b=B0z2NrRVHc6xxK/Qe7sJpw6Bfu7T8O00XQZ/2zrn4Uskb6cSrbYX5X3VPfcV7Tmlhq T9Mi/UUhh6kQhuo5izkYEdwV8VkAk7WH1pcF+p8921P92Uff5SBR2jvOoAQq0jf6LLpV v+MLIssr2x6Mc6JfJqp9AuZN7Zqbzuk3z38b9eLL/IArdaUDad5IZc7IJw4V8iYjha/Q dAMP+eKlsEHJ467eb+QJ12B2H8QDNnzY6pw2ffx8JPLzbEOHXtEJ6c+rcUO2xE/pzSKn 6haNkwgzvEFM3QvaryY1ME4+XtJqE7tedlRhwNHebE45e9SO2FMiWEji7v7azYEwImbO lM4A== X-Gm-Message-State: ALoCoQn4I+1sx711EsYG7MitdQvdvwsFqYSGyLrgRmLhMsXRf9EUoy17d4Vx1uzZG4VDy9M4C3HbZ3KcuXlyHxHBURO/CvUJIGDIHHWXdFONnplFe3wZ5HDbzdZsPdOg7TS/RoHzhGLQ7NON/bBLwKUjwLatgCBODw2TBx6lFW/P5tN7lfsKrmpnaMcd7fuu7BmJrbKIZVgx X-Received: by 10.42.48.202 with SMTP id t10mr9685649icf.9.1382344709152; Mon, 21 Oct 2013 01:38:29 -0700 (PDT) MIME-Version: 1.0 Received: by 10.64.86.106 with HTTP; Mon, 21 Oct 2013 01:38:08 -0700 (PDT) In-Reply-To: <3FA123B5-FC2C-4934-BD64-87D3E515D333@nominum.com> References: <201307301245.r6UCj0k13216@ftpeng-update.cisco.com> <3FA123B5-FC2C-4934-BD64-87D3E515D333@nominum.com> From: Lorenzo Colitti Date: Mon, 21 Oct 2013 17:38:08 +0900 Message-ID: To: Ted Lemon Content-Type: multipart/alternative; boundary=90e6ba6e8e8858cc0e04e93c35ab Cc: draft-smith-v6ops-ce-dhcpv6-transparency@tools.ietf.org, IPv6 Ops WG , "homenet-chairs@tools.ietf.org" Subject: Re: [v6ops] new draft: draft-smith-v6ops-ce-dhcpv6-transparency X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 21 Oct 2013 08:38:45 -0000 --90e6ba6e8e8858cc0e04e93c35ab Content-Type: text/plain; charset=ISO-8859-1 On Sun, Oct 20, 2013 at 8:17 AM, Ted Lemon wrote: > > A new draft has been posted, at > http://tools.ietf.org/html/draft-smith-v6ops-ce-dhcpv6-transparency. > Please take a look at it and comment. > > Aside from these comments, the general flow of the proposed solution seems > right. Actually, I'm not sure this is the right approach. For example, it would seem to be incompatible with the homenet approach of acquiring configuration via DHCPv6 at the edge of the homenet network and then passing that information around inside the homenet. Given that this document is targeted at exactly the same problem that homenet is attempting to solve, I'd rather see this work be moved to homenet, where a lot more thinking has been done on this problem already, than taking it on in an operational group without necessarily considering the implications on the designs that homenet is working on. --90e6ba6e8e8858cc0e04e93c35ab Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
On Sun, Oct 20, 2013 at 8:17 AM, Ted Lemon <ted.lemon= @nominum.com> wrote:
Aside from these comments, the general flow of the proposed solution = seems right.


Given that this document is targeted at exactly the sam= e problem that homenet is attempting to solve, I'd rather see this work= be moved to homenet, where a lot more thinking has been done on this probl= em already, than taking it on in an operational group without necessarily c= onsidering the implications on the designs that homenet is working on.
--90e6ba6e8e8858cc0e04e93c35ab-- From internet-drafts@ietf.org Mon Oct 21 05:17:18 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6BE0A11E8170; Mon, 21 Oct 2013 05:17:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.573 X-Spam-Level: X-Spam-Status: No, score=-102.573 tagged_above=-999 required=5 tests=[AWL=0.027, 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 bnDhMeJhudTG; Mon, 21 Oct 2013 05:17:16 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 90F6D11E83AE; Mon, 21 Oct 2013 05:17:00 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 4.80.p3 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20131021121657.29534.92365.idtracker@ietfa.amsl.com> Date: Mon, 21 Oct 2013 05:16:57 -0700 Cc: v6ops@ietf.org Subject: [v6ops] I-D Action: draft-ietf-v6ops-ula-usage-recommendations-01.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 21 Oct 2013 12:17:18 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the IPv6 Operations Working Group of the IETF. Title : Recommendations of Using Unique Local Addresses Author(s) : Bing Liu Sheng Jiang Cameron Byrne Filename : draft-ietf-v6ops-ula-usage-recommendations-01.txt Pages : 14 Date : 2013-10-21 Abstract: This document provides guidance of how to use ULA. It analyzes ULA usage scenarios and recommends use cases where ULA address might be beneficially used. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-v6ops-ula-usage-recommendations There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-v6ops-ula-usage-recommendations-01 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-v6ops-ula-usage-recommendatio= ns-01 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From fred@cisco.com Mon Oct 21 05:45:10 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3A69511E83A0 for ; Mon, 21 Oct 2013 05:45:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.599 X-Spam-Level: X-Spam-Status: No, score=-110.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, 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 8JO97KRU-+Xe for ; Mon, 21 Oct 2013 05:45:05 -0700 (PDT) Received: from mtv-iport-1.cisco.com (mtv-iport-1.cisco.com [173.36.130.12]) by ietfa.amsl.com (Postfix) with ESMTP id C0A4C11E81B8 for ; Mon, 21 Oct 2013 05:45:02 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=145; q=dns/txt; s=iport; t=1382359502; x=1383569102; h=date:from:message-id:to:subject:cc; bh=kM5Sz6pMCuhGU+bt6dLIKVRE4u97MnGoxN01eoHuEIg=; b=RG3t+z5AQMOIuq7gAwPO69hzrZ7UbYmxQIV4K8ElKExegpBqCTL5PKRZ F1yoc3NIzbTO55yqTxMVMWs/g47SC16DYGuWvuNqClqciGP0sMC5q/l9G fOOslVDqutFukgM5NsOLryilsQtg31XZWv9F05iAOzqqFsL4RR3WJRqT1 U=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AmgIAB4hZVKrRDoI/2dsb2JhbABZgwc4rE0BkisJgSwWdIMlPC0HiGYOvVmPXB2DCYEKA4k/j3mQWINE X-IronPort-AV: E=Sophos;i="4.93,539,1378857600"; d="scan'208";a="91910987" Received: from mtv-core-3.cisco.com ([171.68.58.8]) by mtv-iport-1.cisco.com with ESMTP; 21 Oct 2013 12:45:01 +0000 Received: from ftpeng-update.cisco.com (ftpeng-update.cisco.com [171.69.17.32]) by mtv-core-3.cisco.com (8.14.5/8.14.5) with ESMTP id r9LCj03s009775; Mon, 21 Oct 2013 12:45:00 GMT Received: (fred@localhost) by ftpeng-update.cisco.com (8.11.2/CISCO.WS.1.2) id r9LCj0B29668; Mon, 21 Oct 2013 05:45:00 -0700 (PDT) Date: Mon, 21 Oct 2013 05:45:00 -0700 (PDT) From: Message-Id: <201310211245.r9LCj0B29668@ftpeng-update.cisco.com> To: v6ops@ietf.org Cc: draft-liu-bonica-v6ops-dhcpv6-slaac-problem@tools.ietf.org Subject: [v6ops] new draft: draft-liu-bonica-v6ops-dhcpv6-slaac-problem X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 21 Oct 2013 12:45:10 -0000 A new draft has been posted, at http://tools.ietf.org/html/draft-liu-bonica-v6ops-dhcpv6-slaac-problem. Please take a look at it and comment. From swmike@swm.pp.se Mon Oct 21 06:01:46 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A806611E83AE for ; Mon, 21 Oct 2013 06:01:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.472 X-Spam-Level: X-Spam-Status: No, score=-5.472 tagged_above=-999 required=5 tests=[AWL=0.777, BAYES_00=-2.599, HELO_EQ_SE=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 wudjePJZb9Bt for ; Mon, 21 Oct 2013 06:01:41 -0700 (PDT) Received: from uplift.swm.pp.se (swm.pp.se [212.247.200.143]) by ietfa.amsl.com (Postfix) with ESMTP id 6064111E81B1 for ; Mon, 21 Oct 2013 06:01:30 -0700 (PDT) Received: by uplift.swm.pp.se (Postfix, from userid 501) id BEC689C; Mon, 21 Oct 2013 15:01:28 +0200 (CEST) Received: from localhost (localhost [127.0.0.1]) by uplift.swm.pp.se (Postfix) with ESMTP id BA9FF9A; Mon, 21 Oct 2013 15:01:28 +0200 (CEST) Date: Mon, 21 Oct 2013 15:01:28 +0200 (CEST) From: Mikael Abrahamsson To: fred@cisco.com In-Reply-To: <201310211245.r9LCj0B29668@ftpeng-update.cisco.com> Message-ID: References: <201310211245.r9LCj0B29668@ftpeng-update.cisco.com> User-Agent: Alpine 2.02 (DEB 1266 2009-07-14) Organization: People's Front Against WWW MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: v6ops@ietf.org, draft-liu-bonica-v6ops-dhcpv6-slaac-problem@tools.ietf.org Subject: Re: [v6ops] new draft: draft-liu-bonica-v6ops-dhcpv6-slaac-problem X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 21 Oct 2013 13:01:47 -0000 On Mon, 21 Oct 2013, fred@cisco.com wrote: > > A new draft has been posted, at http://tools.ietf.org/html/draft-liu-bonica-v6ops-dhcpv6-slaac-problem. Please take a look at it and comment. I like the fact that this work is being done. It seems to me the current standards leave too much room for interpretation. I would like to see the following deployment scenarios being possible, and all hosts should support them. 1. No Prefix information, M=1, Host gets /128 IPv6 address for own use and a default route (RA), possibly other information. All traffic to other hosts that is not LL goes via router. 2. PIO /64, A=0, M=1, host gets /128 out of on-link /64, can communicate with other hosts on-link directly. 3. PIO /64, A=1, M=1. Host gets /128 from DHCP plus can do SLAAC, otherwise same as above. 4. PIO /64, A=1, M=1. Host gets /128 from outside /64 via DHCP, plus can do SLAAC within the /64. Also it's quite worrying about the state changes when A/M/O changes. I believe that it might be time to re-rev our standards documents to specify exactly what should happen for each case. From Ted.Lemon@nominum.com Mon Oct 21 06:30:40 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 30AFC11E81BC for ; Mon, 21 Oct 2013 06:30:40 -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.006, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Z1+xbwzf8k4R for ; Mon, 21 Oct 2013 06:30:33 -0700 (PDT) Received: from exprod7og108.obsmtp.com (exprod7og108.obsmtp.com [64.18.2.169]) by ietfa.amsl.com (Postfix) with ESMTP id 8A19B21F9FE7 for ; Mon, 21 Oct 2013 06:30:00 -0700 (PDT) Received: from shell-too.nominum.com ([64.89.228.229]) (using TLSv1) by exprod7ob108.postini.com ([64.18.6.12]) with SMTP ID DSNKUmUsWLo9LUeIh3XceO1JXIcMwWoUZDho@postini.com; Mon, 21 Oct 2013 06:30:00 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 11E731B82A3 for ; Mon, 21 Oct 2013 06:30:00 -0700 (PDT) Received: from webmail.nominum.com (cas-01.win.nominum.com [64.89.228.131]) (using TLSv1 with cipher RC4-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 E7092190052; Mon, 21 Oct 2013 06:29:59 -0700 (PDT) (envelope-from Ted.Lemon@nominum.com) Received: from [10.0.10.40] (192.168.1.10) by CAS-01.WIN.NOMINUM.COM (192.168.1.100) with Microsoft SMTP Server (TLS) id 14.3.158.1; Mon, 21 Oct 2013 06:29:59 -0700 Content-Type: text/plain; charset="windows-1252" MIME-Version: 1.0 (Mac OS X Mail 7.0 \(1812\)) From: Ted Lemon In-Reply-To: Date: Mon, 21 Oct 2013 09:29:57 -0400 Content-Transfer-Encoding: quoted-printable Message-ID: References: <201307301245.r6UCj0k13216@ftpeng-update.cisco.com> <3FA123B5-FC2C-4934-BD64-87D3E515D333@nominum.com> To: Lorenzo Colitti X-Mailer: Apple Mail (2.1812) X-Originating-IP: [192.168.1.10] Cc: draft-smith-v6ops-ce-dhcpv6-transparency@tools.ietf.org, IPv6 Ops WG , "homenet-chairs@tools.ietf.org" Subject: Re: [v6ops] new draft: draft-smith-v6ops-ce-dhcpv6-transparency X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 21 Oct 2013 13:30:40 -0000 On Oct 21, 2013, at 4:38 AM, Lorenzo Colitti wrote: > Actually, I'm not sure this is the right approach. For example, it = would seem to be incompatible with the homenet approach of acquiring = configuration via DHCPv6 at the edge of the homenet network and then = passing that information around inside the homenet. It's not clear to me that there is a problem here. In a multi-homed = scenario, a host on the homenet is either going to do DHCP with multiple = CE routers, in which case this works, or with a single CE router, in = which case this works. If the homenet does cascaded DHCP, then each DHCP server would cascade = unknown options toward the edge, but that's a bad model=97only CE = routers should be doing DHCP anyway in a homenet, IMHO. But that is = certainly a discussion to be had on the homenet mailing list. From volz@cisco.com Mon Oct 21 06:47:07 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2BC7211E83C1 for ; Mon, 21 Oct 2013 06:47:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.598 X-Spam-Level: X-Spam-Status: No, score=-10.598 tagged_above=-999 required=5 tests=[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 LsNvQLn9goJ6 for ; Mon, 21 Oct 2013 06:47:01 -0700 (PDT) Received: from rcdn-iport-8.cisco.com (rcdn-iport-8.cisco.com [173.37.86.79]) by ietfa.amsl.com (Postfix) with ESMTP id E6C0611E8539 for ; Mon, 21 Oct 2013 06:46:46 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=11855; q=dns/txt; s=iport; t=1382363207; x=1383572807; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=DUY6eUGk1GK5kglJhfXgI2avW+TL30Y4X86FNRkdF6I=; b=dvHySS4RpH1ybU8xL2Ite9QfOAzS62LpFtcIQMmJoHVnV9PpcfImErBI 5CORap3A6ojgnvnvvjeSc7Jrjt7nCwLQv+5kDMtdjm6QNEeYdPRFSZLgT 3ZNFAUplebaqSzPZctwx0qmZOV5JngS2/mHluhOxrlRP1BbUzk+e1x1gu o=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AmEGAKkvZVKtJV2Z/2dsb2JhbABZgkNEOFS1YohNgSwWdIIlAQEBAwEtTAULAgEIEQQBAQEKHQcyFAkIAgQBDQUIE4dlBg27YI8rMQYBgx+BCgOZOJBYgySCKg X-IronPort-AV: E=Sophos;i="4.93,539,1378857600"; d="scan'208,217";a="274610734" Received: from rcdn-core-2.cisco.com ([173.37.93.153]) by rcdn-iport-8.cisco.com with ESMTP; 21 Oct 2013 13:46:46 +0000 Received: from xhc-aln-x14.cisco.com (xhc-aln-x14.cisco.com [173.36.12.88]) by rcdn-core-2.cisco.com (8.14.5/8.14.5) with ESMTP id r9LDkkxJ012235 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Mon, 21 Oct 2013 13:46:46 GMT Received: from xmb-rcd-x04.cisco.com ([169.254.8.27]) by xhc-aln-x14.cisco.com ([173.36.12.88]) with mapi id 14.02.0318.004; Mon, 21 Oct 2013 08:46:45 -0500 From: "Bernie Volz (volz)" To: Lorenzo Colitti , Ted Lemon Thread-Topic: [v6ops] new draft: draft-smith-v6ops-ce-dhcpv6-transparency Thread-Index: AQHOzSFnJFDEcroMoE6aAr3o6mVMypn/K0sAgAAAkwA= Date: Mon, 21 Oct 2013 13:46:45 +0000 Message-ID: <489D13FBFA9B3E41812EA89F188F018E1AD2CBC3@xmb-rcd-x04.cisco.com> References: <201307301245.r6UCj0k13216@ftpeng-update.cisco.com> <3FA123B5-FC2C-4934-BD64-87D3E515D333@nominum.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.82.212.218] Content-Type: multipart/alternative; boundary="_000_489D13FBFA9B3E41812EA89F188F018E1AD2CBC3xmbrcdx04ciscoc_" MIME-Version: 1.0 Cc: "draft-smith-v6ops-ce-dhcpv6-transparency@tools.ietf.org" , IPv6 Ops WG , "homenet-chairs@tools.ietf.org" Subject: Re: [v6ops] new draft: draft-smith-v6ops-ce-dhcpv6-transparency X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 21 Oct 2013 13:47:07 -0000 --_000_489D13FBFA9B3E41812EA89F188F018E1AD2CBC3xmbrcdx04ciscoc_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable There was also the following (now expired) draft related to this topic - ht= tp://tools.ietf.org/html/draft-ietf-dhc-container-opt-07. In that draft's model, the SP could push down a "bucket" of options which t= he "DHCPv6 hybrid server" could pull options from to provide the client. Ra= lph Droms originally started this document and it even went to the IESG. Bu= t it has not progressed much further and I think Reinaldo (and Ralph) lost = interest as there didn't seem to be any strong push for it. Regarding this draft, I think SPs would like not to see traffic from the de= vices behind the CPE router. It does seem appropriate to me to consolidate the efforts and have them occ= ur (mostly) in one place. - Bernie From: v6ops-bounces@ietf.org [mailto:v6ops-bounces@ietf.org] On Behalf Of L= orenzo Colitti Sent: Monday, October 21, 2013 4:38 AM To: Ted Lemon Cc: draft-smith-v6ops-ce-dhcpv6-transparency@tools.ietf.org; IPv6 Ops WG; h= omenet-chairs@tools.ietf.org Subject: Re: [v6ops] new draft: draft-smith-v6ops-ce-dhcpv6-transparency On Sun, Oct 20, 2013 at 8:17 AM, Ted Lemon > wrote: > A new draft has been posted, at http://tools.ietf.org/html/draft-smith-v6= ops-ce-dhcpv6-transparency. Please take a look at it and comment. Aside from these comments, the general flow of the proposed solution seems = right. Actually, I'm not sure this is the right approach. For example, it would se= em to be incompatible with the homenet approach of acquiring configuration = via DHCPv6 at the edge of the homenet network and then passing that informa= tion around inside the homenet. Given that this document is targeted at exactly the same problem that homen= et is attempting to solve, I'd rather see this work be moved to homenet, wh= ere a lot more thinking has been done on this problem already, than taking = it on in an operational group without necessarily considering the implicati= ons on the designs that homenet is working on. --_000_489D13FBFA9B3E41812EA89F188F018E1AD2CBC3xmbrcdx04ciscoc_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

There was also the follow= ing (now expired) draft related to this topic - http://tools.ietf.org/html/draft-ietf-dhc-container-opt-07.

 <= /p>

In that draft’s mod= el, the SP could push down a “bucket” of options which the R= 20;DHCPv6 hybrid server” could pull options from to provide the clien= t. Ralph Droms originally started this document and it even went to the IESG. But it has = not progressed much further and I think Reinaldo (and Ralph) lost interest = as there didn’t seem to be any strong push for it.<= /p>

 <= /p>

Regarding this draft, I t= hink SPs would like not to see traffic from the devices behind the CPE rout= er.

 <= /p>

It does seem appropriate = to me to consolidate the efforts and have them occur (mostly) in one place.=

 <= /p>

- =          Bernie=

 <= /p>

From: v6ops-bo= unces@ietf.org [mailto:v6ops-bounces@ietf.org] On Behalf Of Lorenzo Colitti
Sent: Monday, October 21, 2013 4:38 AM
To: Ted Lemon
Cc: draft-smith-v6ops-ce-dhcpv6-transparency@tools.ietf.org; IPv6 Op= s WG; homenet-chairs@tools.ietf.org
Subject: Re: [v6ops] new draft: draft-smith-v6ops-ce-dhcpv6-transpar= ency

 

On Sun, Oct 20, 2013 at 8:17 AM, Ted Lemon <ted.lemon@nominum.com= > wrote:

> A new draft has = been posted, at http://tools.ietf.org/html/draft-smith-v6ops-ce-dhcpv6-transparency. Pl= ease take a look at it and comment.

Aside from these comments, the general flow of the p= roposed solution seems right.

 

Actually, I'm not sure this is the right approach. F= or example, it would seem to be incompatible with the homenet approach of a= cquiring configuration via DHCPv6 at the edge of the homenet network and th= en passing that information around inside the homenet.

 

Given that this document is targeted at exactly the = same problem that homenet is attempting to solve, I'd rather see this work = be moved to homenet, where a lot more thinking has been done on this proble= m already, than taking it on in an operational group without necessarily considering the implications on the = designs that homenet is working on.

--_000_489D13FBFA9B3E41812EA89F188F018E1AD2CBC3xmbrcdx04ciscoc_-- From internet-drafts@ietf.org Mon Oct 21 06:49:02 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2AB2D11E8522; Mon, 21 Oct 2013 06:48:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.568 X-Spam-Level: X-Spam-Status: No, score=-102.568 tagged_above=-999 required=5 tests=[AWL=0.032, 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 xTYt1tZiqTzn; Mon, 21 Oct 2013 06:48:58 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id BAFC511E83D3; Mon, 21 Oct 2013 06:48:52 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 4.80.p3 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20131021134852.29396.64222.idtracker@ietfa.amsl.com> Date: Mon, 21 Oct 2013 06:48:52 -0700 Cc: v6ops@ietf.org Subject: [v6ops] I-D Action: draft-ietf-v6ops-balanced-ipv6-security-00.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 21 Oct 2013 13:49:05 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the IPv6 Operations Working Group of the IETF. Title : Balanced Security for IPv6 Residential CPE Author(s) : Martin Gysi Guillaume Leclanche Eric Vyncke Ragnar Anfinsen Filename : draft-ietf-v6ops-balanced-ipv6-security-00.txt Pages : 7 Date : 2013-10-21 Abstract: This document describes how an IPv6 residential Customer Premise Equipment (CPE) can have a balanced security policy that allows for a mostly end-to-end connectivity while keeping the major threats outside of the home. It is based on an actual IPv6 deployment by Swisscom and allows all packets inbound/outbound EXCEPT for some layer-4 ports where attacks and vulnerabilities (such as weak passwords) are well-known. The blocked inbound ports is expected to be updated as threats come and go. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-v6ops-balanced-ipv6-security There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-v6ops-balanced-ipv6-security-00 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From ecordeiro@nic.br Mon Oct 21 12:28:16 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D544A11E8557 for ; Mon, 21 Oct 2013 12:28:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=-0.000, 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 M4gdzOkjFh6c for ; Mon, 21 Oct 2013 12:28:13 -0700 (PDT) Received: from mail.nic.br (mail.cgi.br [IPv6:2001:12ff:0:4::5]) by ietfa.amsl.com (Postfix) with ESMTP id 4D2FC11E86B4 for ; Mon, 21 Oct 2013 12:28:08 -0700 (PDT) Received: by mail.nic.br (Postfix, from userid 33) id 04EB720802C6; Mon, 21 Oct 2013 17:28:07 -0200 (BRST) Received: from 177-44-240-252.univates.br (177-44-240-252.univates.br [177.44.240.252]) by mail.nic.br (Horde Framework) with HTTP; Mon, 21 Oct 2013 17:28:07 -0200 Message-ID: <20131021172807.271020y1ekidxv0n@mail.nic.br> Date: Mon, 21 Oct 2013 17:28:07 -0200 From: ecordeiro@nic.br To: v6ops@ietf.org MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; DelSp="Yes"; format="flowed" Content-Disposition: inline Content-Transfer-Encoding: 7bit User-Agent: Internet Messaging Program (IMP) H3 (4.3.7) Subject: [v6ops] New Version Notification for draft-moreiras-v6ops-rfc3849bis-01 X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 21 Oct 2013 19:28:17 -0000 All, We have revised the draft to include a better justification for the bigger documentation address need and an ULA documentation prefix as requested on the discussion of version 00. On the first version of the draft there was no consensus on what prefix should be used, so we didn't define the prefix to be used yet. The new draft version is here: http://www.ietf.org/id/draft-moreiras-v6ops-rfc3849bis-01.txt We appreciate any thoughts and comments. Edwin Cordeiro NIC.br From markzzzsmith@yahoo.com.au Mon Oct 21 12:37:43 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AC9BB11E870B for ; Mon, 21 Oct 2013 12:37:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.101 X-Spam-Level: * X-Spam-Status: No, score=1.101 tagged_above=-999 required=5 tests=[BAYES_50=0.001, FROM_LOCAL_NOVOWEL=0.5, J_CHICKENPOX_13=0.6] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id m0IvnnV0S4ge for ; Mon, 21 Oct 2013 12:37:27 -0700 (PDT) Received: from nm23-vm1.bullet.mail.bf1.yahoo.com (nm23-vm1.bullet.mail.bf1.yahoo.com [98.139.213.141]) by ietfa.amsl.com (Postfix) with ESMTP id A821411E86F5 for ; Mon, 21 Oct 2013 12:36:51 -0700 (PDT) Received: from [98.139.212.144] by nm23.bullet.mail.bf1.yahoo.com with NNFMP; 21 Oct 2013 19:36:48 -0000 Received: from [98.139.212.214] by tm1.bullet.mail.bf1.yahoo.com with NNFMP; 21 Oct 2013 19:36:48 -0000 Received: from [127.0.0.1] by omp1023.mail.bf1.yahoo.com with NNFMP; 21 Oct 2013 19:36:48 -0000 X-Yahoo-Newman-Property: ymail-3 X-Yahoo-Newman-Id: 77083.24386.bm@omp1023.mail.bf1.yahoo.com Received: (qmail 11468 invoked by uid 60001); 21 Oct 2013 19:36:48 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com.au; s=s1024; t=1382384207; bh=iKB0RoL2G5H4marm1HoILGXStFsSljhU+ZOkjVMBs5U=; h=X-YMail-OSG:Received:X-Rocket-MIMEInfo:X-Mailer:References:Message-ID:Date:From:Reply-To:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type:Content-Transfer-Encoding; b=sG5GTJxAp2eV+vxJKQyN7j/aLWyruwvjZutsYG/6zRbpvyWdi9DRNDMTYTwV9Bj6ENsjiEwyF5B0dw8Ofn57QIlwF8COsTnimd2xV8aMgQ25kqjF49PClP5znpXs4YXD8BqqtI5pwt0hv6ZBn+0N7A6Rel4YZP0aWqzwUDnpgj0= DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com.au; h=X-YMail-OSG:Received:X-Rocket-MIMEInfo:X-Mailer:References:Message-ID:Date:From:Reply-To:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type:Content-Transfer-Encoding; b=D/h/cxjfg0p67aib4093KOTdf6rpKaaUGUb+CNCJdXTljVStRQN00aTqKxHH/d8ClmQgorXSV2XQPDm6pwCSoiULTHIdArDxbSIMZmU3BVZndjxmH4ac1jnoLRLSuikAR235//28tGYXat6T3c05WCSE1tfLiadvD+7qd6Zj7B4=; X-YMail-OSG: zcxmCHAVM1ltoV9BTkXcy29Uz4Zt29tCpvCT4HgMYcT3.4R WMcpVkiIGr_Bcl2FTZTCrKiCGCEBrwb5BTdJgYGkuPMXb3eg0_QXuAuWg1Ez R1xciD2To43w.6GmeXD3Zjn_HkaYfL05ah4FZYKtQUgBrPKy_zZ6M2VgJwy4 iWCdsJFEkw3RWtnlEt_FfTaB8ZVwgALjV4DP2q2DuGCRt6Ngo7bQfePOobZ7 pmDxScEy6PD54C852m1UN5Q2pWLBBAD4EsXs6XMndcw4M7vJceIrbGdbYzfL 9fm9mtwaVy1mNUAJjnLIn5RtT7IY7cjuxszn6YyKgSFjJDZT0DHhoJLg7bcN rot3TyzmmzBuLQq3XJuJugH8dU9_M5vJtY9YPv0aa1A9Zp2vPWMkt7VOS9yZ EqDo2TBkPnO5wvpiu7Ww4m2W0vv5Gr.GLBGY827r1xlXtTh0i6VzfDTS96cp pO0wLctgU0Tv9ZUDBtenBRxVPK7G.x.5SfzTmm.TkfmEgYoSRG04pN9evbTG IbbhS5saFQNVoQAFAC54FbJITXLkd.sp4y8kGfIicGnlMYMrAOIlDs.3AY59 1rvYH9oNArSSvOdXroOxooHGlQ4lNwimLMTizzHUIHGl2dg5QxwEf0hXBUiX 6x3j_d1viL.OtmbvG8BCl1XhrM0q9hRBxcpBtg.7Qj93dWCQ1Uc15PvVrJxu t9YxkJASrC8UINlNw Received: from [150.101.221.237] by web142504.mail.bf1.yahoo.com via HTTP; Mon, 21 Oct 2013 12:36:47 PDT X-Rocket-MIMEInfo: 002.001, CgoKCgo.X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18KPiBGcm9tOiBMb3JlbnpvIENvbGl0dGkgPGxvcmVuem9AZ29vZ2xlLmNvbT4KPlRvOiBUZWQgTGVtb24gPHRlZC5sZW1vbkBub21pbnVtLmNvbT4gCj5DYzogRnJlZCBCYWtlciAoZnJlZCkgPGZyZWRAY2lzY28uY29tPjsgZHJhZnQtc21pdGgtdjZvcHMtY2UtZGhjcHY2LXRyYW5zcGFyZW5jeUB0b29scy5pZXRmLm9yZzsgSVB2NiBPcHMgV0cgPHY2b3BzQGlldGYub3JnPjsgImhvbWVuZXQtY2hhaXJzQHRvb2xzLmlldGYub3JnIiA8aG9tZW4BMAEBAQE- X-Mailer: YahooMailWebService/0.8.160.587 References: <201307301245.r6UCj0k13216@ftpeng-update.cisco.com> <3FA123B5-FC2C-4934-BD64-87D3E515D333@nominum.com> Message-ID: <1382384207.11444.YahooMailNeo@web142504.mail.bf1.yahoo.com> Date: Mon, 21 Oct 2013 12:36:47 -0700 (PDT) From: Mark ZZZ Smith To: Lorenzo Colitti , Ted Lemon In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Cc: "draft-smith-v6ops-ce-dhcpv6-transparency@tools.ietf.org" , IPv6 Ops WG , "homenet-chairs@tools.ietf.org" Subject: Re: [v6ops] new draft: draft-smith-v6ops-ce-dhcpv6-transparency X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: Mark ZZZ Smith List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 21 Oct 2013 19:37:43 -0000 =0A=0A=0A=0A=0A>________________________________=0A> From: Lorenzo Colitti = =0A>To: Ted Lemon =0A>Cc: Fred = Baker (fred) ; draft-smith-v6ops-ce-dhcpv6-transparency@too= ls.ietf.org; IPv6 Ops WG ; "homenet-chairs@tools.ietf.org" = =0A>Sent: Monday, 21 October 2013 7:38 PM= =0A>Subject: Re: [v6ops] new draft: draft-smith-v6ops-ce-dhcpv6-transparenc= y=0A> =0A>=0A>=0A>On Sun, Oct 20, 2013 at 8:17 AM, Ted Lemon wrote:=0A>=0A>> A new draft has been posted, at http://tools.ietf= .org/html/draft-smith-v6ops-ce-dhcpv6-transparency. Please take a look at i= t and comment.=0A>>=0A>>Aside from these comments, the general flow of the = proposed solution seems right.=0A>=0A>=0A>Actually, I'm not sure this is th= e right approach. For example, it would seem to be incompatible with the ho= menet approach of acquiring configuration via DHCPv6 at the edge of the hom= enet network and then passing that information around inside the homenet.= =0A>=0A>=0A=0A>Given that this document is targeted at exactly the same pro= blem that homenet is attempting to solve, I'd rather see this work be moved= to homenet, where a lot more thinking has been done on this problem alread= y, than taking it on in an operational group without necessarily considerin= g the implications on the designs that homenet is working on.=0A>=0A>=0A=0A= Homenet does seem the place for it in some respects, I thought v6ops was th= e primary place mainly because the update to RFC6204 is a v6ops draft. Howe= ver, thinking about it further, I don't think it is a homenet unique issue = though - 3G devices that are providing tethered Internet access via their L= AN interfaces also have the same constraint as they also follow the DHCPv6 = Client/Server model rather than a DHCPv6 relay or DHCPv6 hybrid server mode= l that I propose. It also more generally applies to any environment where t= he customer brings their own router - SOHO, most enterprises etc.=0A=0AI th= ink where it is the biggest issue is in the residential market, if it is on= e where customers can bring their own CPE (such as here in .au), and are re= sponsible for updates to it. Asking them to upgrade their CPE firmware to s= upport new options is pretty much a waste of time - they either won't under= stand what you're asking them to do, won't be competent to do it, or won't = be confident of doing it because the consequences of losing their Internet = services if it isn't successful are too high. DHCPv6 option transparency wo= uld avoid a continuous cycle of CPE upgrades to support new DHCPv6 options = that the hosts might like to use and the upstream service provider might li= ke to provide.=0A=0AAs for the thinking behind it, I've been thinking about= this problem since about 2010/2011. I worked on Internode's production IPv= 6 broadband deployment during that period. While waiting for some vendor fe= atures/bug fixes to BNG software, I also worked with a number of residentia= l IPv6 CPE vendors, advising them on their IPv6 implementations. I realised= the problem with "DHCPv6 option" transparency after there were different l= evels of CPE support for different DHCPv6 options. This was while RFC6204 w= as being developed, however as I mentioned in the draft, future useful DHCP= v6 options will not be supported in the DHCPv6 client/server model. *=0A=0A= I understand the need for providing local services, and when writing this, = wondered about the DHCPv6 hybrid server either adding options to the Client= replies it constructs from the relayed Information-Request, or overwriting= or adding to values in the options that it received in the relayed Informa= tion-Request. There are "interesting" issues though - should the CPE's opti= on values always override those supplied by the service provider? =A0Or sho= uld they be added to those that the service provider supplies. For some opt= ions the CPE policy might be to defer to the SP supplied option values, whe= re as for other options it might need to be a setting. I think these issues= are DHCPv6 option specific, and the theme of the draft is to try to minimi= se / avoid any DHCPv6 option specific handling to attain DHCPv6 option tran= sparency.=0A=0ARegards,=0A=0AMark.=0A=0A=0Ap.s., thanks all for your review= and comments.=0A=0A=0A* I did a presentation at Ausnog 2011 on my experien= ces with IPv6 CPE =A0- "Residential IPv6 CPE - What not to do and other obs= ervations" - http://www.users.on.net/~markachy/resi_ipv6_cpe.pdf From nalini.elkins@insidethestack.com Mon Oct 21 15:58:39 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3F5AD11E87D9 for ; Mon, 21 Oct 2013 15:58:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.181 X-Spam-Level: X-Spam-Status: No, score=-1.181 tagged_above=-999 required=5 tests=[AWL=-1.181, BAYES_50=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 NPTqbTBxHC7z for ; Mon, 21 Oct 2013 15:58:39 -0700 (PDT) Received: from nm3-vm4.access.bullet.mail.bf1.yahoo.com (nm3-vm4.access.bullet.mail.bf1.yahoo.com [216.109.114.99]) by ietfa.amsl.com (Postfix) with ESMTP id E4F0811E87C0 for ; Mon, 21 Oct 2013 15:58:22 -0700 (PDT) Received: from [66.196.81.160] by nm3.access.bullet.mail.bf1.yahoo.com with NNFMP; 21 Oct 2013 22:58:22 -0000 Received: from [66.196.81.130] by tm6.access.bullet.mail.bf1.yahoo.com with NNFMP; 21 Oct 2013 22:58:22 -0000 Received: from [127.0.0.1] by omp1006.access.mail.bf1.yahoo.com with NNFMP; 21 Oct 2013 22:58:22 -0000 X-Yahoo-Newman-Property: ymail-3 X-Yahoo-Newman-Id: 66706.57983.bm@omp1006.access.mail.bf1.yahoo.com Received: (qmail 23180 invoked by uid 60001); 21 Oct 2013 22:58:21 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s1024; t=1382396301; bh=gz7bsWA3BKYe3p8KchJBGACAUiJhFU+zTjXy2NOwom0=; h=X-YMail-OSG:Received:X-Rocket-MIMEInfo:X-Mailer:References:Message-ID:Date:From:Reply-To:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type:Content-Transfer-Encoding; b=qdS7Q3Cy6lMzupXUJmmljNB/YrBNx/+yUBc9iKsGxxBNs+QEs/TRb6JXap2xfY/PkeeysCwQHmkjaMwChshIp6i3ToV3ebMokr17E2MESN6uvj8MCPhtQfUaNmCMWSfJQ6rK6WeNIstMipirz3dNoU36Sp54UDZtl8xIFXOlPhM= X-YMail-OSG: 3qSutDkVM1m_rKOwD95QcNtpkvhcHeb9fl8kjbNU_zTepCz HpYBLoU8elofJ3oS18.BqVNg3h0TwGU5CANcnT30cosgpoOj1TSWC2l6vJX9 QFFrri7PMeDKffpZuH7mWWphetrFM6HF_vtVjXdEoRTmgmsGsnf00eGO2FAN l_a3a5fvrZZhH2b3DQPd06lhJIHNz.YKEjgpzggYc6jP7eJrxGnsJONWudMI tcqOh4R0NbruuSL9Q77wuqbxplQBmXM2dVQvLeKAhpGEPbkX16cR70wEf3aD WeoDj_HhOyKW.JLB6lKl4vY8vWYjE01qKOTYTbebOFmeM3RA.7gGGNsIaadq WPbIiC9BI8yLhGpaqXmVwgegUX84grXgjG1jpeYaguRYMfohIwQeWE_Xm0Vx SJvQE4RQCF4u2wFTfwVcpCduWql6lWyhAOmgBJXEZEWlt0HivW7Y3R6UJEGE EiNcNcAskPO9ZAoR7PdyPPTT.62TL5QJ3yzspqcO0sEJTkGVlSCRejis3XT. jGnv6I6YKq3lRqgv4Fs8JcEc_nc6HGHXwevqBtG2UF5ky5khqh3MaEHDspoc oSWu003NfORL2l8w- Received: from [24.130.37.147] by web2801.biz.mail.ne1.yahoo.com via HTTP; Mon, 21 Oct 2013 15:58:20 PDT X-Rocket-MIMEInfo: 002.001, Cj7CoDEpIGVuY29kaW5nIGhhcyB0byBiZSBmYXN0LCBidXQgZGVjb2RpbmcgZG9lcyBub3QKClRydWUKCj7CoDIpIGEgbm9kZSdzIGNsb2NrIGNvdWxkIGJlIGVpdGhlciBpbiBvdXIgb3V0IG9mIHN5bmNoIHdpdGggc29tZSBub3Rpb25hbAo.wqBtYXN0ZXIgY2xvY2sgKGUuZy4gdmlhIE5UUCkKPsKgMykgdHdvIGNsb2NrcyBjb3VsZCBiZSBpbiBzeW5jaCB0byBhIG1hc3RlciBzb3VyY2UsIGJ1dCB0aGUgbWFzdGVyCj7CoHNvdXJjZXMgbWF5IHRoZW1zZWx2ZXMgbm90IHNoYXJlIGEgY29tbW9uIHNvdXJjZSABMAEBAQE- X-Mailer: YahooMailWebService/0.8.160.587 References: <20131017032024.5051.20799.idtracker@ietfa.amsl.com> <1381980305.36254.YahooMailNeo@web2803.biz.mail.ne1.yahoo.com> <5263C783.1080001@globis.net> Message-ID: <1382396300.22968.YahooMailNeo@web2801.biz.mail.ne1.yahoo.com> Date: Mon, 21 Oct 2013 15:58:20 -0700 (PDT) From: Nalini Elkins To: Ray Hunter In-Reply-To: <5263C783.1080001@globis.net> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Cc: v6ops WG , 6man WG , "ippm@ietf.org" Subject: Re: [v6ops] Fw: New Version Notification for draft-elkins-6man-ipv6-pdm-dest-option-04.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: Nalini Elkins List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 21 Oct 2013 22:58:39 -0000 =0A>=A01) encoding has to be fast, but decoding does not=0A=0ATrue=0A=0A>= =A02) a node's clock could be either in our out of synch with some notional= =0A>=A0master clock (e.g. via NTP)=0A>=A03) two clocks could be in synch to= a master source, but the master=0A>=A0sources may themselves not share a c= ommon source (one sourced from GPS,=0A>one from DCF77)=0A>4) the key to bei= ng able to perform the end to end calculations is=0A>whether two communicat= ing nodes are synchronised to the same master=0A>clock (within some level o= f error/jitter)=0A>5) the absolute time is not particularly important=0A=0A= =0AThis is true for PDM 1 only. =A0PDM 2 does not require time synchronizat= ion.=0A=0A>=A0Q1. Why do you want to encode differences as deltas in the ca= se of an=A0unsynchronised/ free running clock?=0A>=A0Isn't that slow, and d= ifficult for hardware implementations to achieve=A0(e.g. TCP offload)?=A0Do= esn't it also require maintaining large amounts of state in the=A0sending n= ode.=0A>=0A=0A1.=A0I think that it is going to be interesting to see how ha= rdware is going to handle TCP offload with IPv6 extension headers. =A0 I do= not see why PDM 2 would be so much harder than PDM 1 for an OS.=0ACan you = tell me which end host operating systems are doing TCP offload in hardware?= =A0=A0=0A=0AI know some OS's which process TCP segmentation in hardware. = =A0 =A0But at this point, the packet is already crafted. =A0Also some do IP= checksum offload in hardware but that does not apply to IPv6 as there is n= o IP header checksum.=0A=0A=0A2. =A0End hosts already maintain quite a bit = of state. =A0Every OS has control blocks to handle events such as TCP dupli= cate packets, round trip time, congestion window, etc. =A0 We are NOT sugge= sting=0Athat the PDM headers be used in middle boxes. =A0That is, we are NO= T asking routers to maintain state.=0A=0A=0A>=A0Why not just encode the tim= estamp as-is and perform the appropriate=A0difference calculation during de= coding?=0A=0AIf clocks are out of synch, you could end up having it look li= ke you received the packet before you sent it.=0A=0A>=A0Q2. Why do you need= two separate packet formats at all?=0A=0A>=A0Why not have a common format = for all cases, containing a timestamp based=0A>on the local clock, plus an = optional field containing a flag that states=0A>if the local timestamp is c= oordinated to some master clock, plus an=0A>identifier for the master clock= .=0A=0A>You could then encode whether a node had a free-running clock (case= 2),=0A>a synchronised clock (case 1), and whether it was synched via NTP t= o=0A>some stratum 0 source e.g. GPS, and also some identification of the=0A= >stratum 1 source (IPv6 address).=0A=0A>Two communicating nodes could then = use e.g. NTP trace to see if they=0A>shared a common clock source or not, b= efore performing their calculations.=0A=0AWe are trying to craft a solution= with PDM 2 for those situations where time synchronization is not practica= l, possible or desired.=0A From ietf@rozanak.com Mon Oct 21 16:23:28 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 16EE511E827C for ; Mon, 21 Oct 2013 16:23:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.392 X-Spam-Level: X-Spam-Status: No, score=-1.392 tagged_above=-999 required=5 tests=[AWL=1.208, 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 vE590gC+6b-A for ; Mon, 21 Oct 2013 16:23:23 -0700 (PDT) Received: from mout.perfora.net (mout.perfora.net [74.208.4.195]) by ietfa.amsl.com (Postfix) with ESMTP id 5527411E81A4 for ; Mon, 21 Oct 2013 16:23:23 -0700 (PDT) Received: from kopoli (g231251108.adsl.alicedsl.de [92.231.251.108]) by mrelay.perfora.net (node=mrus3) with ESMTP (Nemesis) id 0M24nL-1VsPTY182t-00tCms; Mon, 21 Oct 2013 19:23:22 -0400 From: "Hosnieh Rafiee" To: Date: Tue, 22 Oct 2013 01:23:16 +0200 Message-ID: <021e01ceceb4$88158570$98409050$@rozanak.com> MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Outlook 14.0 Thread-Index: Ac7Os6IH9xR8BzUtQCCafxW36arWMQ== Content-Language: en-us X-Provags-ID: V02:K0:H5EncYuFp0AxOhmoDNDfKicu8sYHgX2awePVOhkcy6+ ST2TzHXQjoKvlqVtpYdkocb3dEDV2gEH7t52Ww7BzJ88JUh6kl IFH1phTxyPfTFFP0+WIreBmDyyhvkIWE60z83FtQrZVue3TX8A LWtkR/XnIZsHY+01GNK4GF65wu7KIX6sNV+rXY4hh00+IqksCL 7YeBxCADa9h1X9RDxdgRch8UfqvixF1cW3wx12Dwr9KVezlVat 1oykKKGU/diOr+0w6HkcLog9otrI3RdimcljGxKK56XCdM0S4G 9MElhb4UGluG9iRVlTsxMgZ0SnApF5d2vbltX0YMZXsrGdbdAV ScdoXcgqhGbiakDaR51I= Cc: Erik Nordmark Subject: [v6ops] I-D: draft-rafiee-v6ops-iid-lifetime-00.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 21 Oct 2013 23:23:28 -0000 We submitted a new draft which compares the current mechanisms to = maintain the lifetime of IIDs and then introduces a framework to enable = applications maintaining their privacy by making it difficult to = correlate a user's activities by using different IIDs for different = applications, without negatively impacting the robustness of the = applications. We're looking forward to receiving your comments. Filename: draft-rafiee-v6ops-iid-lifetime Revision: 00 Title: Interface ID lifetime Algorithms Creation date: 2013-10-21 Group: Individual Submission Number of pages: 11 URL: = http://www.ietf.org/internet-drafts/draft-rafiee-v6ops-iid-lifetime-00.tx= t Status: = http://datatracker.ietf.org/doc/draft-rafiee-v6ops-iid-lifetime Htmlized: = http://tools.ietf.org/html/draft-rafiee-v6ops-iid-lifetime-00 Abstract: This document introduces a framework, i.e., an application layer based lifetime [applicationiid] to enable applications maintaining their users' privacy as well as controlling the number of Interface IDs (IIDs) per network adapter. It will also explain different approaches that can be used for maintaining the lifetime of an IID. We also compare this framework to the other available mechanisms. This document also explains when to remove deprecated IP addresses from the a network interface. -----------smile---------- Hosnieh =E2=80=A6 success is a journey, not a destination=E2=80=A6. You cannot change your destination overnight, but you can change your = direction ... Focus on the journey From evyncke@cisco.com Mon Oct 21 22:35:52 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8E87E11E845D for ; Mon, 21 Oct 2013 22:35:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.149 X-Spam-Level: X-Spam-Status: No, score=-10.149 tagged_above=-999 required=5 tests=[AWL=-0.149, BAYES_00=-2.599, J_CHICKENPOX_13=0.6, 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 gtPyZ82Aqhpz for ; Mon, 21 Oct 2013 22:35:47 -0700 (PDT) Received: from rcdn-iport-4.cisco.com (rcdn-iport-4.cisco.com [173.37.86.75]) by ietfa.amsl.com (Postfix) with ESMTP id 8610611E8440 for ; Mon, 21 Oct 2013 22:35:47 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=3107; q=dns/txt; s=iport; t=1382420147; x=1383629747; h=from:to:subject:date:message-id:references:in-reply-to: content-transfer-encoding:mime-version; bh=A9yV8fUcI7UR0uvymdIfwnfGEtpdXQuLCNeaDFE9QRU=; b=iQUGQ/oJYCa/DVht62+zqXqGMZR9E+2iPYoZ5qT2dH9bTACWAmc3fKCD Y4nw4iC/Ez+8vkHYaX3mZXTHX/YYvhODZg5G52g/yKSk2VMAAsFF6BbIB RvTemLf9mG772A7lHBVrJblteMxxr1AISqyoOtsQIonA23h1Ru5RSCI3j I=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AjsGADINZlKtJV2a/2dsb2JhbABZgwc4VL5CgSEWbQeCJQEBAQQBAQE3KwkXBAIBCBEEAQELFAkHJwsUAwEFCAIEEwiHfg27C48qOAaDGYEKA5QqhQ6QWIMkgio X-IronPort-AV: E=Sophos;i="4.93,546,1378857600"; d="scan'208";a="275020523" Received: from rcdn-core-3.cisco.com ([173.37.93.154]) by rcdn-iport-4.cisco.com with ESMTP; 22 Oct 2013 05:35:47 +0000 Received: from xhc-aln-x02.cisco.com (xhc-aln-x02.cisco.com [173.36.12.76]) by rcdn-core-3.cisco.com (8.14.5/8.14.5) with ESMTP id r9M5ZjLI014339 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for ; Tue, 22 Oct 2013 05:35:47 GMT Received: from xmb-aln-x02.cisco.com ([169.254.5.143]) by xhc-aln-x02.cisco.com ([173.36.12.76]) with mapi id 14.02.0318.004; Tue, 22 Oct 2013 00:35:45 -0500 From: "Eric Vyncke (evyncke)" To: "v6ops@ietf.org" Thread-Topic: [v6ops] I-D Action: draft-ietf-v6ops-balanced-ipv6-security-00.txt Thread-Index: AQHOzmRxX1vGW2G7M0u07RuArHqPW5oAM1Mg Date: Tue, 22 Oct 2013 05:35:44 +0000 Message-ID: <97EB7536A2B2C549846804BBF3FD47E123795E0B@xmb-aln-x02.cisco.com> References: <20131021134852.29396.64222.idtracker@ietfa.amsl.com> In-Reply-To: <20131021134852.29396.64222.idtracker@ietfa.amsl.com> Accept-Language: fr-FR, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.65.35.143] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [v6ops] I-D Action: draft-ietf-v6ops-balanced-ipv6-security-00.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 22 Oct 2013 05:35:52 -0000 Here are the main changes based on the Berlin meeting discussion: In order to avoid that this document appears as an IETF 'blessing' of a spe= cific ACL (or layer-4 ports), a lot of verbiage has been added to show the = list as EXAMPLE and we have removed all 'proposals' and 'recommend' in favo= r of the word 'example'. We kept the list of ports as an example but clearly mentioned that this lis= t was based on known vulnerabilities in protocols (e.g. Telnet is in the cl= ear) or implementations (still some worms active on 445 for old Windows imp= lementations). Again, examples. Another generic rule was added to allow for remote management (in the case = of managed CPE). A mention is also added about whether to do stateless or stateful filtering= is not that relevant for this I-D as its only objective is to give an exam= ple of what a SP did. As a side note, Ragnar (a co-author) has presented this approach at the RIP= E meeting =3D> several positive discussions > -----Original Message----- > From: v6ops-bounces@ietf.org [mailto:v6ops-bounces@ietf.org] On Behalf Of > internet-drafts@ietf.org > Sent: lundi 21 octobre 2013 19:19 > To: i-d-announce@ietf.org > Cc: v6ops@ietf.org > Subject: [v6ops] I-D Action: draft-ietf-v6ops-balanced-ipv6-security- > 00.txt >=20 >=20 > A New Internet-Draft is available from the on-line Internet-Drafts > directories. > This draft is a work item of the IPv6 Operations Working Group of the > IETF. >=20 > Title : Balanced Security for IPv6 Residential CPE > Author(s) : Martin Gysi > Guillaume Leclanche > Eric Vyncke > Ragnar Anfinsen > Filename : draft-ietf-v6ops-balanced-ipv6-security-00.txt > Pages : 7 > Date : 2013-10-21 >=20 > Abstract: > This document describes how an IPv6 residential Customer Premise > Equipment (CPE) can have a balanced security policy that allows for a > mostly end-to-end connectivity while keeping the major threats > outside of the home. It is based on an actual IPv6 deployment by > Swisscom and allows all packets inbound/outbound EXCEPT for some > layer-4 ports where attacks and vulnerabilities (such as weak > passwords) are well-known. The blocked inbound ports is expected to > be updated as threats come and go. >=20 >=20 > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-ietf-v6ops-balanced-ipv6-security >=20 > There's also a htmlized version available at: > http://tools.ietf.org/html/draft-ietf-v6ops-balanced-ipv6-security-00 >=20 >=20 > Please note that it may take a couple of minutes from the time of > submission until the htmlized version and diff are available at > tools.ietf.org. >=20 > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ >=20 > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops From v6ops@globis.net Mon Oct 21 23:10:16 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7868011E815B; Mon, 21 Oct 2013 23:10:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SJFbTpG883gE; Mon, 21 Oct 2013 23:10:15 -0700 (PDT) Received: from globis01.globis.net (RayH-1-pt.tunnel.tserv11.ams1.ipv6.he.net [IPv6:2001:470:1f14:62e::2]) by ietfa.amsl.com (Postfix) with ESMTP id 6ED2511E8160; Mon, 21 Oct 2013 23:10:15 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by globis01.globis.net (Postfix) with ESMTP id 823348700BD; Tue, 22 Oct 2013 08:10:14 +0200 (CEST) Received: from globis01.globis.net ([127.0.0.1]) by localhost (mail.globis.net [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Rc69tpUhZj34; Tue, 22 Oct 2013 08:10:14 +0200 (CEST) Received: from Rays-iMac-2.local (unknown [192.168.0.3]) (Authenticated sender: Ray.Hunter@globis.net) by globis01.globis.net (Postfix) with ESMTPA id 0222387005F; Tue, 22 Oct 2013 08:10:13 +0200 (CEST) Message-ID: <526616C4.40304@globis.net> Date: Tue, 22 Oct 2013 08:10:12 +0200 From: Ray Hunter User-Agent: Postbox 3.0.8 (Macintosh/20130427) MIME-Version: 1.0 To: Nalini Elkins References: <20131017032024.5051.20799.idtracker@ietfa.amsl.com> <1381980305.36254.YahooMailNeo@web2803.biz.mail.ne1.yahoo.com> <5263C783.1080001@globis.net> <1382396300.22968.YahooMailNeo@web2801.biz.mail.ne1.yahoo.com> In-Reply-To: <1382396300.22968.YahooMailNeo@web2801.biz.mail.ne1.yahoo.com> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: v6ops WG , 6man WG , "ippm@ietf.org" Subject: Re: [v6ops] Fw: New Version Notification for draft-elkins-6man-ipv6-pdm-dest-option-04.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 22 Oct 2013 06:10:16 -0000 > Nalini Elkins > 22 October 2013 00:58 >> 1) encoding has to be fast, but decoding does not > > True > >> 2) a node's clock could be either in our out of synch with some notional >> master clock (e.g. via NTP) >> 3) two clocks could be in synch to a master source, but the master >> sources may themselves not share a common source (one sourced from GPS, >> one from DCF77) >> 4) the key to being able to perform the end to end calculations is >> whether two communicating nodes are synchronised to the same master >> clock (within some level of error/jitter) >> 5) the absolute time is not particularly important > > > This is true for PDM 1 only. PDM 2 does not require time synchronization. > >> Q1. Why do you want to encode differences as deltas in the case of an unsynchronised/ free running clock? >> Isn't that slow, and difficult for hardware implementations to achieve (e.g. TCP offload)? Doesn't it also require maintaining large amounts of state in the sending node. >> > > 1. I think that it is going to be interesting to see how hardware is going to handle TCP offload with IPv6 extension headers. I do not see why PDM 2 would be so much harder than PDM 1 for an OS. > Can you tell me which end host operating systems are doing TCP offload in hardware? IMHO Not a relevant question. As a standards body we should be looking to the future. There are many operations that are delegated to microcode. If you specified the packet with one single way of encapsulating timestamps, then hardware or interface microcode could add the timestamp at the last possible moment before the packet reached the wire, without having to examine the original packet contents, or knowing the context of the communicating nodes. I think that's very desirable. > I know some OS's which process TCP segmentation in hardware. But at this point, the packet is already crafted. Also some do IP checksum offload in hardware but that does not apply to IPv6 as there is no IP header checksum. > > > 2. End hosts already maintain quite a bit of state. Every OS has control blocks to handle events such as TCP duplicate packets, round trip time, congestion window, etc. We are NOT suggesting > that the PDM headers be used in middle boxes. That is, we are NOT asking routers to maintain state. So what? Why add to the problem? Why does the timestamp require synchronisation with that other TCP state? Isn't it better to define a solution that is independent of the upper layer header transport protocol? Why not allow middleboxes (or node hardware) to insert the timestamp header on the fly? > >> Why not just encode the timestamp as-is and perform the appropriate difference calculation during decoding? > > If clocks are out of synch, you could end up having it look like you received the packet before you sent it. No. I'm not suggesting you use the same decoding algorithm: only that you define a single common encoding algorithm that combines all the information required for PDM 1 and PDM 2 calculations. Having to chose which packet encoding to use in advance is problematic IMHO. >> Q2. Why do you need two separate packet formats at all? > >> Why not have a common format for all cases, containing a timestamp based >> on the local clock, plus an optional field containing a flag that states >> if the local timestamp is coordinated to some master clock, plus an >> identifier for the master clock. > >> You could then encode whether a node had a free-running clock (case 2), >> a synchronised clock (case 1), and whether it was synched via NTP to >> some stratum 0 source e.g. GPS, and also some identification of the >> stratum 1 source (IPv6 address). > >> Two communicating nodes could then use e.g. NTP trace to see if they >> shared a common clock source or not, before performing their calculations. > > We are trying to craft a solution with PDM 2 for those situations where time synchronization is not practical, possible or desired. I understand the aim, but let me ask my question a different way. Imagine there are nodes A&B that with clocks synched to DCF77. Imagine there are nodes C&D that with clocks synched to GPS. Node E has free running clock (possibly because the GPS receiver is down). Which packet format PDM type 1 or PDM type 2 do you use between each pair of nodes, and how does the sending node know that? Scale this solution to 100K hosts. > > ------------------------------------------------------------------------ -- Regards, RayH From leo.liubing@huawei.com Mon Oct 21 23:50:23 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0345B11E8481 for ; Mon, 21 Oct 2013 23:50:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.179 X-Spam-Level: X-Spam-Status: No, score=-6.179 tagged_above=-999 required=5 tests=[AWL=-0.180, BAYES_00=-2.599, J_CHICKENPOX_13=0.6, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YklyL6cK94JG for ; Mon, 21 Oct 2013 23:50:18 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) by ietfa.amsl.com (Postfix) with ESMTP id F05DC11E816D for ; Mon, 21 Oct 2013 23:50:17 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml204-edg.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id AXA96610; Tue, 22 Oct 2013 06:50:06 +0000 (GMT) Received: from LHREML405-HUB.china.huawei.com (10.201.5.242) by lhreml204-edg.china.huawei.com (172.18.7.223) with Microsoft SMTP Server (TLS) id 14.3.146.0; Tue, 22 Oct 2013 07:48:29 +0100 Received: from nkgeml409-hub.china.huawei.com (10.98.56.40) by lhreml405-hub.china.huawei.com (10.201.5.242) with Microsoft SMTP Server (TLS) id 14.3.146.0; Tue, 22 Oct 2013 07:49:27 +0100 Received: from NKGEML506-MBX.china.huawei.com ([169.254.3.141]) by nkgeml409-hub.china.huawei.com ([10.98.56.40]) with mapi id 14.03.0146.000; Tue, 22 Oct 2013 14:49:22 +0800 From: "Liubing (Leo)" To: "v6ops@ietf.org" Thread-Topic: DHCPv6/SLAAC Make Hosts Confusing-//RE: new draft: draft-liu-bonica-v6ops-dhcpv6-slaac-problem Thread-Index: AQHOzltsXXG/hvZHw0OAdgyFq+29zZoAR9Tw Date: Tue, 22 Oct 2013 06:49:21 +0000 Message-ID: <8AE0F17B87264D4CAC7DE0AA6C406F453D7CBF49@nkgeml506-mbx.china.huawei.com> References: <201310211245.r9LCj0B29668@ftpeng-update.cisco.com> In-Reply-To: <201310211245.r9LCj0B29668@ftpeng-update.cisco.com> Accept-Language: en-US, zh-CN Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.111.98.132] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Reflected Cc: "draft-liu-bonica-v6ops-dhcpv6-slaac-problem@tools.ietf.org" Subject: [v6ops] DHCPv6/SLAAC Make Hosts Confusing-//RE: new draft: draft-liu-bonica-v6ops-dhcpv6-slaac-problem X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 22 Oct 2013 06:50:23 -0000 Hi, Chairs & All The draft (http://tools.ietf.org/html/draft-liu-bonica-v6ops-dhcpv6-slaac-p= roblem) is about the SLAAC/DHCPv6 interaction problems might cause hosts un= -consistent behaviors, which might harmful for management. The content of the draft has been discussed a couple of times in 6man WG, m= ost of the feedbacks are positive. Some people have showed their willing to= fix the problems by revising the standard. But considering this is a historic problem which was used to be discussed a= lot before, we think it might be necessary to identify the problems clearl= y and solidly before revising the standard.=20 So we made a Problem Statement document in v6ops, and hope the OPS people c= ould provide opinions on this topic, e.g.=20 - do you agree the problems in the draft; - have you considered/suffered the impacts to the real IPv6 deployment by t= his issue;=20 - do you think we must have to fix the problems .etc. Your review and comments would be appreciated very much. For those who are not familiar with the draft, please see the introduction = as the following (also as the replies to the Chairs' questions) > 1) Please provide a succinct problem statement for your draft. What > problem/issue is this draft discussing? What operational problems does th= e > proposal address in real life networks? [Bing] As we know there are several flags in RA messages regarding with the= host configuration behavior, which are A (Autonomous) flag, M (Managed) fl= ag, and O (Otherconfig) flag. For some reason, the host behavior of interpreting the flags is ambiguous i= n the standard (mainly RFC4862). This draft analyzed all the three flags, a= nd provided test result of current implementations, it showed the behavior = of different mainstream desktop/mobile OSes have varied. The ambiguous and = variation might cause operational problems, such as renumbering, cold start= problem, and management gaps .etc. > 2) Where does this draft or presentation fits into v6ops' current charter > (http://datatracker.ietf.org/wg/v6ops/charter/)? Citing specific a sectio= n(s) > of the charter is preferable. [Bing] 1. Solicit input from network operators and users to identify operational issues with the IPv4/IPv6 Internet, and determine solutions or workarounds to those issues. These issues will be documented in Informational or BCP RFCs, or in Internet-Drafts. > 3) Who is this draft's audience? [Bing] Administrators/Operators. > 4) Have any operators expressed interest in this draft or its problem spa= ce, > either via review or other discussion? [Bing] Yes, China Telecom had expressed the problem when they deployed IPv6= networks. Their scenario was the CPE doing SLAAC while getting information= through stateless DHCPv6. And the found the flags definition is ambiguous = in current standard, so they had to directly specify the behavior of interp= reting the flags to the CPE vendors. > 5) Is this draft pursuing discussion in any other WGs? If so, please list= them > here, along with rationale for the interaction with multiple WGs in paral= lel. [Bing] In 6man, as described in the main body. > 6) Is any protocol work being recommended in the draft? [Bing] Not yet. This draft was intend to be a pure Problem Statement draft. Many thanks. Best regards, Bing > -----Original Message----- > From: fred@cisco.com [mailto:fred@cisco.com] > Sent: Monday, October 21, 2013 8:45 PM > To: v6ops@ietf.org > Cc: draft-liu-bonica-v6ops-dhcpv6-slaac-problem@tools.ietf.org > Subject: new draft: draft-liu-bonica-v6ops-dhcpv6-slaac-problem >=20 >=20 > A new draft has been posted, at > http://tools.ietf.org/html/draft-liu-bonica-v6ops-dhcpv6-slaac-problem. > Please take a look at it and comment. From leo.liubing@huawei.com Tue Oct 22 00:22:32 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6022911E82E9 for ; Tue, 22 Oct 2013 00:22:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.449 X-Spam-Level: X-Spam-Status: No, score=-6.449 tagged_above=-999 required=5 tests=[AWL=0.150, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lHxdNOJDXNLM for ; Tue, 22 Oct 2013 00:22:27 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) by ietfa.amsl.com (Postfix) with ESMTP id 31E2811E8169 for ; Tue, 22 Oct 2013 00:22:21 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml203-edg.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id AXA99876; Tue, 22 Oct 2013 07:22:19 +0000 (GMT) Received: from LHREML401-HUB.china.huawei.com (10.201.5.240) by lhreml203-edg.huawei.com (172.18.7.221) with Microsoft SMTP Server (TLS) id 14.3.146.0; Tue, 22 Oct 2013 08:22:03 +0100 Received: from NKGEML402-HUB.china.huawei.com (10.98.56.33) by lhreml401-hub.china.huawei.com (10.201.5.240) with Microsoft SMTP Server (TLS) id 14.3.146.0; Tue, 22 Oct 2013 08:22:12 +0100 Received: from NKGEML506-MBX.china.huawei.com ([169.254.3.141]) by nkgeml402-hub.china.huawei.com ([10.98.56.33]) with mapi id 14.03.0146.000; Tue, 22 Oct 2013 15:21:30 +0800 From: "Liubing (Leo)" To: Mikael Abrahamsson Thread-Topic: DHCPv6/SLAAC Make Hosts Confusing-//RE: [v6ops] new draft: draft-liu-bonica-v6ops-dhcpv6-slaac-problem Thread-Index: AQHOzltsXXG/hvZHw0OAdgyFq+29zZn+mHwAgAGxNZA= Date: Tue, 22 Oct 2013 07:21:26 +0000 Message-ID: <8AE0F17B87264D4CAC7DE0AA6C406F453D7CC14B@nkgeml506-mbx.china.huawei.com> References: <201310211245.r9LCj0B29668@ftpeng-update.cisco.com> In-Reply-To: Accept-Language: en-US, zh-CN Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.111.98.132] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Reflected Cc: "v6ops@ietf.org" , "draft-liu-bonica-v6ops-dhcpv6-slaac-problem@tools.ietf.org" Subject: [v6ops] DHCPv6/SLAAC Make Hosts Confusing-//RE: new draft: draft-liu-bonica-v6ops-dhcpv6-slaac-problem X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 22 Oct 2013 07:22:32 -0000 Hi, Mikael Thanks for your comments. (I change the mail title to help identify the tra= ffic to this specific draft/problem). Please see replies inline. > I like the fact that this work is being done. It seems to me the current > standards leave too much room for interpretation. [Bing] Agreed. Ambiguity is usually a bad thing. > I would like to see the following deployment scenarios being possible, an= d > all hosts should support them. >=20 > 1. No Prefix information, M=3D1, Host gets /128 IPv6 address for own use = and > a default route (RA), possibly other information. All traffic to other > hosts that is not LL goes via router. >=20 > 2. PIO /64, A=3D0, M=3D1, host gets /128 out of on-link /64, can communic= ate > with other hosts on-link directly. [Bing] I'm a little confused about the scenario. A=3D0 switch SLAAC off, an= d host would initial DHCP according M=3D1, do you mean the DHCP Server need= to be aware of the PIO /64, so that the /128 from dhcp in accordance with = the PIO /64? =20 > 3. PIO /64, A=3D1, M=3D1. Host gets /128 from DHCP plus can do SLAAC, > otherwise same as above. >=20 > 4. PIO /64, A=3D1, M=3D1. Host gets /128 from outside /64 via DHCP, plus = can > do SLAAC within the /64. >=20 > Also it's quite worrying about the state changes when A/M/O changes. I > believe that it might be time to re-rev our standards documents to specif= y > exactly what should happen for each case. [Bing] Agreed.=20 Best regards, Bing From alexandru.petrescu@gmail.com Tue Oct 22 04:36:03 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7D12B11E8155 for ; Tue, 22 Oct 2013 04:36:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.905 X-Spam-Level: X-Spam-Status: No, score=-9.905 tagged_above=-999 required=5 tests=[AWL=-0.256, BAYES_00=-2.599, HELO_EQ_FR=0.35, J_CHICKENPOX_13=0.6, 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 kZ5mgHPMXc2N for ; Tue, 22 Oct 2013 04:35:53 -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 911AF11E818B for ; Tue, 22 Oct 2013 04:35:22 -0700 (PDT) Received: from nephilia.intra.cea.fr (nephilia.intra.cea.fr [132.166.88.33]) by cirse.extra.cea.fr (8.14.2/8.14.2/CEAnet-Internet-out-2.3) with ESMTP id r9MBZIA1028097 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT) for ; Tue, 22 Oct 2013 13:35:18 +0200 Received: from muguet2.intra.cea.fr (muguet2.intra.cea.fr [132.166.192.7]) by nephilia.intra.cea.fr (8.14.4/8.14.4) with ESMTP id r9MBZItA001244 for ; Tue, 22 Oct 2013 13:35:18 +0200 (envelope-from alexandru.petrescu@gmail.com) Received: from [127.0.0.1] (is010446-4.intra.cea.fr [10.8.33.116]) by muguet2.intra.cea.fr (8.13.8/8.13.8/CEAnet-Intranet-out-1.2) with ESMTP id r9MBZEnl001583 for ; Tue, 22 Oct 2013 13:35:18 +0200 Message-ID: <526662F2.1060808@gmail.com> Date: Tue, 22 Oct 2013 13:35:14 +0200 From: Alexandru Petrescu User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:24.0) Gecko/20100101 Thunderbird/24.0.1 MIME-Version: 1.0 To: "v6ops@ietf.org" References: <5252C5C2.5080706@gmail.com> <1808340F7EC362469DDFFB112B37E2FCD87724529F@SRVHKE02.rdm.cz> <5252DCEF.6030705@gmail.com> <1808340F7EC362469DDFFB112B37E2FCD87724530A@SRVHKE02.rdm.cz> <5252E66D.3080005@gmail.com> <1808340F7EC362469DDFFB112B37E2FCD87724531C@SRVHKE02.rdm.cz> <5253B80E.7030008@gmail.com> <1808340F7EC362469DDFFB112B37E2FCD877245410@SRVHKE02.rdm.cz> <5253C891.7090009@gmail.com> In-Reply-To: <5253C891.7090009@gmail.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Subject: [v6ops] Announcing draft-petrescu-relay-route-pd-problem-00 (was: Need ref to 3GPP spec for the use of DHCPv6 Prefix Delegation, e.g. for smartphone tethering) X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 22 Oct 2013 11:36:03 -0000 Hello participants to v6ops WG, We have just submitted draft-petrescu-relay-route-pd-problem-00 http://tools.ietf.org/html/draft-petrescu-relay-route-pd-problem-00 "Route Problem at Relay during DHCPv6 Prefix Delegation" M. Boucadair (France Telecom) L. Yeh (Freelancer Technologies) A. Petrescu (CEA). It presents a problem of routing at Relay during Prefix Delegation of DHCPv6; also lists some solutions I-Ds. The problem may be relevant in the DHC WG, at the Broadband Forum and maybe at 3GPP. Please comment on this draft. Thanks, Alex Le 08/10/2013 10:55, Alexandru Petrescu a ĂŠcrit : > Le 08/10/2013 10:49, VĂ­zdal AleĹĄ a ĂŠcrit : >>>> The GGSN/PGW is UEs next-hop as the traffic is tunnelled in GTP >>>> through all the intermediate nodes. >>> >>> Ah, right, there is a GTP tunnel above all the intermediary IP >>> nodes. >>> >>> However, even when a tunnel is dynamically set up, a routing >>> table entry is added in the Relay's routing table (or other >>> similar entry). The parameters of that entry necessarily >>> include, among others, the prefix which is allocated. >>> >>> No? >> >> The tunnel stays up for the lifetime of the PDP/PDN context. > > Ok. > >> There is no relay in the 3GPP access architecture. > > Ok. > >> If the tunnel drops, the PGW/GGSN will remove the route from their >> routing table, once a new tunnel is setup the routing table is >> updated accordingly. > > The route associated with that tunnel should contain a parameter > containing the Delegated Prefix. When there is no delegated prefix, > that route entry should be updated. > > The tunnel could stay up but only for the Smartphone. Or it could > stay up for both the Smartphone _and_ the Hosts in the smartphone's > LAN. These are two different things. > > Alex > > >> >>> Alex >> >> Ales >> >> > > > _______________________________________________ v6ops mailing list > v6ops@ietf.org https://www.ietf.org/mailman/listinfo/v6ops > > From fred@cisco.com Tue Oct 22 05:46:34 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DC7F611E8390 for ; Tue, 22 Oct 2013 05:46:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.599 X-Spam-Level: X-Spam-Status: No, score=-110.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, 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 frn4o5Qhpjy9 for ; Tue, 22 Oct 2013 05:45:50 -0700 (PDT) Received: from mtv-iport-3.cisco.com (mtv-iport-3.cisco.com [173.36.130.14]) by ietfa.amsl.com (Postfix) with ESMTP id 295C411E838B for ; Tue, 22 Oct 2013 05:45:08 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=133; q=dns/txt; s=iport; t=1382445911; x=1383655511; h=date:from:message-id:to:subject:cc; bh=L5vmkpxwPMXIF1ubdldGYKeYtyi6bmxUJfLc2qNcnIk=; b=RUq1MXJK0YpEZ4OxZ8sAO7g36qUI9y+KDQiw0M3w7rqzWS5TlnRDM2Vm 4vLxPEH+CxVbzn7KmMuu4sEIO8z/1uO6XvnJ0CuiCmUdbFpddI3NBF3ia Qwvrs0ySBl8ih2umxEPakAE6xGoeHM5ob8WuH+OD09+gnjnTVzHs9x70A s=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ArcIAOdyZlKrRDoG/2dsb2JhbABZgwc4rG0BkiMJgScWdIMlPC0HiGYOuwuPRh2EEwOJP495kFiDRA X-IronPort-AV: E=Sophos;i="4.93,548,1378857600"; d="scan'208";a="92725878" Received: from mtv-core-1.cisco.com ([171.68.58.6]) by mtv-iport-3.cisco.com with ESMTP; 22 Oct 2013 12:45:03 +0000 Received: from ftpeng-update.cisco.com (ftpeng-update.cisco.com [171.69.17.32]) by mtv-core-1.cisco.com (8.14.5/8.14.5) with ESMTP id r9MCj1qY022606; Tue, 22 Oct 2013 12:45:01 GMT Received: (fred@localhost) by ftpeng-update.cisco.com (8.11.2/CISCO.WS.1.2) id r9MCj1809529; Tue, 22 Oct 2013 05:45:01 -0700 (PDT) Date: Tue, 22 Oct 2013 05:45:01 -0700 (PDT) From: Message-Id: <201310221245.r9MCj1809529@ftpeng-update.cisco.com> To: v6ops@ietf.org Cc: draft-rafiee-v6ops-iid-lifetime@tools.ietf.org Subject: [v6ops] new draft: draft-rafiee-v6ops-iid-lifetime X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 22 Oct 2013 12:46:35 -0000 A new draft has been posted, at http://tools.ietf.org/html/draft-rafiee-v6ops-iid-lifetime. Please take a look at it and comment. From fred@cisco.com Tue Oct 22 05:46:39 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A3ADB11E838D for ; Tue, 22 Oct 2013 05:46:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.599 X-Spam-Level: X-Spam-Status: No, score=-110.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, 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 dCaFXLcHKI-T for ; Tue, 22 Oct 2013 05:46:34 -0700 (PDT) Received: from mtv-iport-1.cisco.com (mtv-iport-1.cisco.com [173.36.130.12]) by ietfa.amsl.com (Postfix) with ESMTP id B6F3611E838F for ; Tue, 22 Oct 2013 05:45:24 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=141; q=dns/txt; s=iport; t=1382445926; x=1383655526; h=date:from:message-id:to:subject:cc; bh=m9eHlOa5cFwd90oixSn7MvkQrtkK3afsxHVYGkOdhZo=; b=GDf8lc7Z3e5PbtltOMRycW5hzrvr4AUGBI9yqRlXqyg9qlMZyd2wvQ9r ZkPpFCdw/FPups4KbLzH7G/D6U/wBp/uVkDYJ8F3L12KFVPitZM4EQaUr /kA/beKNVbkL8/IY4/Tjn+j9shCFGCQHzCDA37H1MZJ2m6Fy4sGCEJqrX w=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ArgIAOdyZlKrRDoG/2dsb2JhbABZgwc4rG0BkiMJgScWdIMRFDwtB4hmDrsLj0YdgwmBCgOJP495kFiDRA X-IronPort-AV: E=Sophos;i="4.93,548,1378857600"; d="scan'208";a="92009047" Received: from mtv-core-1.cisco.com ([171.68.58.6]) by mtv-iport-1.cisco.com with ESMTP; 22 Oct 2013 12:45:02 +0000 Received: from ftpeng-update.cisco.com (ftpeng-update.cisco.com [171.69.17.32]) by mtv-core-1.cisco.com (8.14.5/8.14.5) with ESMTP id r9MCj1cE022601; Tue, 22 Oct 2013 12:45:01 GMT Received: (fred@localhost) by ftpeng-update.cisco.com (8.11.2/CISCO.WS.1.2) id r9MCj1D09526; Tue, 22 Oct 2013 05:45:01 -0700 (PDT) Date: Tue, 22 Oct 2013 05:45:01 -0700 (PDT) From: Message-Id: <201310221245.r9MCj1D09526@ftpeng-update.cisco.com> To: v6ops@ietf.org Cc: draft-ietf-v6ops-balanced-ipv6-security@tools.ietf.org Subject: [v6ops] new draft: draft-ietf-v6ops-balanced-ipv6-security X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 22 Oct 2013 12:46:39 -0000 A new draft has been posted, at http://tools.ietf.org/html/draft-ietf-v6ops-balanced-ipv6-security. Please take a look at it and comment. From fred@cisco.com Tue Oct 22 05:46:39 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AB03411E8390 for ; Tue, 22 Oct 2013 05:46:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.599 X-Spam-Level: X-Spam-Status: No, score=-110.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, 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 GIKfJUsOovOP for ; Tue, 22 Oct 2013 05:46:34 -0700 (PDT) Received: from mtv-iport-1.cisco.com (mtv-iport-1.cisco.com [173.36.130.12]) by ietfa.amsl.com (Postfix) with ESMTP id CAC6C11E838C for ; Tue, 22 Oct 2013 05:45:10 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=148; q=dns/txt; s=iport; t=1382445912; x=1383655512; h=date:from:message-id:to:subject:cc; bh=X3OAja1ehMf+yb72qrI1MzcJCG7Wyge/zBe/D4TXsYc=; b=fdZI3n76AtKNqZSEvHTItmZTctnJPKiegc8Q/jb++Ymm7+cVMrG+87ye hJAO3fF7hby48lyl4P1AM/g8wqZCFPDbDO6mt2G/chZUnHn67vx2THjEQ GpHimQHTp/1XdhzQM2c0UtK/rHy5bLvl4A3/QbLvGLK+5HnEmPBVbauLf E=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ArYIAOdyZlKrRDoG/2dsb2JhbABZgwc4rG0BkiyBJxZ0gyU8LQeIZg67C49GHYQTA4k/j3mQWINE X-IronPort-AV: E=Sophos;i="4.93,548,1378857600"; d="scan'208";a="92009046" Received: from mtv-core-1.cisco.com ([171.68.58.6]) by mtv-iport-1.cisco.com with ESMTP; 22 Oct 2013 12:45:02 +0000 Received: from ftpeng-update.cisco.com (ftpeng-update.cisco.com [171.69.17.32]) by mtv-core-1.cisco.com (8.14.5/8.14.5) with ESMTP id r9MCj1rE022608; Tue, 22 Oct 2013 12:45:01 GMT Received: (fred@localhost) by ftpeng-update.cisco.com (8.11.2/CISCO.WS.1.2) id r9MCj1N09535; Tue, 22 Oct 2013 05:45:01 -0700 (PDT) Date: Tue, 22 Oct 2013 05:45:01 -0700 (PDT) From: Message-Id: <201310221245.r9MCj1N09535@ftpeng-update.cisco.com> To: v6ops@ietf.org Cc: draft-sun-v6ops-openv6-address-pool-management@tools.ietf.org Subject: [v6ops] new draft: draft-sun-v6ops-openv6-address-pool-management X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 22 Oct 2013 12:46:39 -0000 A new draft has been posted, at http://tools.ietf.org/html/draft-sun-v6ops-openv6-address-pool-management. Please take a look at it and comment. From swmike@swm.pp.se Tue Oct 22 06:13:14 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BAB6611E83B6 for ; Tue, 22 Oct 2013 06:13:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.627 X-Spam-Level: X-Spam-Status: No, score=-5.627 tagged_above=-999 required=5 tests=[AWL=0.622, BAYES_00=-2.599, HELO_EQ_SE=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 nBaywomsMfYh for ; Tue, 22 Oct 2013 06:13:09 -0700 (PDT) Received: from uplift.swm.pp.se (swm.pp.se [212.247.200.143]) by ietfa.amsl.com (Postfix) with ESMTP id 8839E11E8378 for ; Tue, 22 Oct 2013 06:13:09 -0700 (PDT) Received: by uplift.swm.pp.se (Postfix, from userid 501) id 01511A1; Tue, 22 Oct 2013 15:13:07 +0200 (CEST) Received: from localhost (localhost [127.0.0.1]) by uplift.swm.pp.se (Postfix) with ESMTP id F03D39C; Tue, 22 Oct 2013 15:13:07 +0200 (CEST) Date: Tue, 22 Oct 2013 15:13:07 +0200 (CEST) From: Mikael Abrahamsson To: "Liubing (Leo)" In-Reply-To: <8AE0F17B87264D4CAC7DE0AA6C406F453D7CC14B@nkgeml506-mbx.china.huawei.com> Message-ID: References: <201310211245.r9LCj0B29668@ftpeng-update.cisco.com> <8AE0F17B87264D4CAC7DE0AA6C406F453D7CC14B@nkgeml506-mbx.china.huawei.com> User-Agent: Alpine 2.02 (DEB 1266 2009-07-14) Organization: People's Front Against WWW MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: "v6ops@ietf.org" , "draft-liu-bonica-v6ops-dhcpv6-slaac-problem@tools.ietf.org" Subject: Re: [v6ops] DHCPv6/SLAAC Make Hosts Confusing-//RE: new draft: draft-liu-bonica-v6ops-dhcpv6-slaac-problem X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 22 Oct 2013 13:13:14 -0000 On Tue, 22 Oct 2013, Liubing (Leo) wrote: >> 2. PIO /64, A=0, M=1, host gets /128 out of on-link /64, can communicate >> with other hosts on-link directly. > [Bing] I'm a little confused about the scenario. A=0 switch SLAAC off, > and host would initial DHCP according M=1, do you mean the DHCP Server > need to be aware of the PIO /64, so that the /128 from dhcp in > accordance with the PIO /64? Yes. I already do this at home with a Cisco router with built-in DHCPv6 IA_NA (and IA_PD) server. -- Mikael Abrahamsson email: swmike@swm.pp.se From markzzzsmith@yahoo.com.au Tue Oct 22 12:17:43 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D80CD21E8093 for ; Tue, 22 Oct 2013 12:17:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.499 X-Spam-Level: X-Spam-Status: No, score=-0.499 tagged_above=-999 required=5 tests=[AWL=1.600, BAYES_00=-2.599, FROM_LOCAL_NOVOWEL=0.5] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BITKi0lHpPSh for ; Tue, 22 Oct 2013 12:17:39 -0700 (PDT) Received: from nm2-vm1.bullet.mail.bf1.yahoo.com (nm2-vm1.bullet.mail.bf1.yahoo.com [98.139.213.158]) by ietfa.amsl.com (Postfix) with ESMTP id 38E9121F9DFC for ; Tue, 22 Oct 2013 12:16:47 -0700 (PDT) Received: from [98.139.212.144] by nm2.bullet.mail.bf1.yahoo.com with NNFMP; 22 Oct 2013 19:16:46 -0000 Received: from [98.139.212.227] by tm1.bullet.mail.bf1.yahoo.com with NNFMP; 22 Oct 2013 19:16:46 -0000 Received: from [127.0.0.1] by omp1036.mail.bf1.yahoo.com with NNFMP; 22 Oct 2013 19:16:46 -0000 X-Yahoo-Newman-Property: ymail-3 X-Yahoo-Newman-Id: 584531.17731.bm@omp1036.mail.bf1.yahoo.com Received: (qmail 56411 invoked by uid 60001); 22 Oct 2013 19:16:46 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com.au; s=s1024; t=1382469406; bh=30PxgPGUW8xCIZoWU4iILvPWSA4dE+FqgLhOkaMVYYw=; h=X-YMail-OSG:Received:X-Rocket-MIMEInfo:X-Mailer:References:Message-ID:Date:From:Reply-To:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type:Content-Transfer-Encoding; b=Vjsk43JGvXt4lEjeyzPLT3o7yRtIFhLDdefDlp0mlluhOJFF4OxA0WtJmp1tsvrvVkX3zpL+5X/DnfoPX2C36tphZXmQt+4VY8osq56AbKIvaZmNrd0uGkzr73HHgF3C0NOK+2o2zIQay/7YPFmp0a3GUL1C6aOg64l39Hp1tMo= DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com.au; h=X-YMail-OSG:Received:X-Rocket-MIMEInfo:X-Mailer:References:Message-ID:Date:From:Reply-To:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type:Content-Transfer-Encoding; b=TJkqN836bIO2I+rqkj3h4/FtuxGqgCDzztZBuw0XNlW0eJK9/IOitxbwadhLJsq6FfH1TPsQz7WlZCLdfMZoJ0Sd5CFc0kYdai3Bpo9+cTExu2r0Y3doXXMj/sPrqHA9MJ1HceXn4NrW84GY7FaM74AMy6/bGyArlkNxApf/zgU=; X-YMail-OSG: MBf_p3YVM1kBomCytqDTzL2DIiq.IMWwI.mItAo0yd0y5Z8 FdhJGxu2VyigutV8isVf.Vk2uEeHRQqjxt2mVlCkQ0yfZ1Lb3Meae3AlcseM zEGUcmsHi4WeeJKBqD4os68VTIWiRxqk.ReGCLPdEi4hTSE_reQSH1aMShbw UKZclZ5W7eYbdvDkTyjrSIBTRagKHCpcOsbexpyXlF7M0WKTeMtUvLVuC7P. Ztkek6jONp9kTvZ9j4bY.VTpMFaeZAGF9E4OxBtXcbnwwsZd_eZ7N0_UXO2N b7yQdtUH_KBpWLPW1BiEleUeJT4oCGOJ5hR6d6UL25rDeW0UBElIBPnQdEof Xt_FUpTPWEYQyVb6GwigwEbBVunaEfpannAkfH9mRv_MA.a5ZPqQKKLBHCNa tir59DsFOrGgqcVprZku2mV88gFuBj_d6M.dd8K5fLqJ9Yb3RD7i1zCxrOYO OUFg7aX2JY8Sh0QIqjJOf1utgLihb7nMSvAYtQ3iZDueBXYCsY44m5m.XQZM ywpOXEUGlIADVJl09Gf43DUbaQZnByq5Yn7kiRbRcWsDz6YrYBEz57Ai6vgI 12WHwxMWO1dpvZr0KVYLYcWCOdATehpUuPIefT_CtXuWNbQ-- Received: from [150.101.221.237] by web142504.mail.bf1.yahoo.com via HTTP; Tue, 22 Oct 2013 12:16:45 PDT X-Rocket-MIMEInfo: 002.001, Cj5fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXwo.IEZyb206IE1pa2FlbCBBYnJhaGFtc3NvbiA8c3dtaWtlQHN3bS5wcC5zZT4KPlRvOiBMaXViaW5nIChMZW8pIDxsZW8ubGl1YmluZ0BodWF3ZWkuY29tPiAKPkNjOiAidjZvcHNAaWV0Zi5vcmciIDx2Nm9wc0BpZXRmLm9yZz47ICJkcmFmdC1saXUtYm9uaWNhLXY2b3BzLWRoY3B2Ni1zbGFhYy1wcm9ibGVtQHRvb2xzLmlldGYub3JnIiA8ZHJhZnQtbGl1LWJvbmljYS12Nm9wcy1kaGNwdjYtc2xhYWMtcHJvYmxlbUB0b29scy5pZXRmLm9yZz4gCj4BMAEBAQE- X-Mailer: YahooMailWebService/0.8.160.587 References: <201310211245.r9LCj0B29668@ftpeng-update.cisco.com> <8AE0F17B87264D4CAC7DE0AA6C406F453D7CC14B@nkgeml506-mbx.china.huawei.com> Message-ID: <1382469405.56346.YahooMailNeo@web142504.mail.bf1.yahoo.com> Date: Tue, 22 Oct 2013 12:16:45 -0700 (PDT) From: Mark ZZZ Smith To: Mikael Abrahamsson , "Liubing \(Leo\)" In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Cc: "v6ops@ietf.org" , "draft-liu-bonica-v6ops-dhcpv6-slaac-problem@tools.ietf.org" Subject: Re: [v6ops] DHCPv6/SLAAC Make Hosts Confusing-//RE: new draft: draft-liu-bonica-v6ops-dhcpv6-slaac-problem X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: Mark ZZZ Smith List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 22 Oct 2013 19:17:44 -0000 =0A>________________________________=0A> From: Mikael Abrahamsson =0A>To: Liubing (Leo) =0A>Cc: "v6ops@ietf= .org" ; "draft-liu-bonica-v6ops-dhcpv6-slaac-problem@tools.= ietf.org" =0A>= Sent: Wednesday, 23 October 2013 12:13 AM=0A>Subject: Re: [v6ops] DHCPv6/SL= AAC Make Hosts Confusing-//RE: new draft: draft-liu-bonica-v6ops-dhcpv6-sla= ac-problem=0A> =0A>=0A>On Tue, 22 Oct 2013, Liubing (Leo) wrote:=0A>=0A>>> = 2. PIO /64, A=3D0, M=3D1, host gets /128 out of on-link /64, can communicat= e=0A>>> with other hosts on-link directly.=0A>=0A>> [Bing] I'm a little con= fused about the scenario. A=3D0 switch SLAAC off, =0A>> and host would init= ial DHCP according M=3D1, do you mean the DHCP Server =0A>> need to be awar= e of the PIO /64, so that the /128 from dhcp in =0A>> accordance with the P= IO /64?=0A>=0A>Yes. I already do this at home with a Cisco router with buil= t-in DHCPv6 =0A>IA_NA (and IA_PD) server.=0A>=0A=0AIs this saying that the = prefix length of the address on host is /128?=0A=0AIf that is the case, as = the prefix length in doesn't indicate on-link or off-link status (as RA PIO= s do), is there any specific reason for the prefix length the DHCPv6 server= hands out to be /128 instead of the subnet's prefix length of /64?=A0=0A= =0A=0A>-- =0A>Mikael Abrahamsson=A0 =A0 email: swmike@swm.pp.se=0A>=0A>____= ___________________________________________=0A>v6ops mailing list=0A>v6ops@= ietf.org=0A>https://www.ietf.org/mailman/listinfo/v6ops=0A>=0A>=0A> From markzzzsmith@yahoo.com.au Tue Oct 22 13:22:46 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E587921F9C3A for ; Tue, 22 Oct 2013 13:22:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.999 X-Spam-Level: X-Spam-Status: No, score=-0.999 tagged_above=-999 required=5 tests=[AWL=0.500, BAYES_00=-2.599, FROM_LOCAL_NOVOWEL=0.5, J_CHICKENPOX_13=0.6] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qjfSe26cXBiB for ; Tue, 22 Oct 2013 13:22:42 -0700 (PDT) Received: from nm15.bullet.mail.bf1.yahoo.com (nm15.bullet.mail.bf1.yahoo.com [98.139.212.174]) by ietfa.amsl.com (Postfix) with ESMTP id D9E9421F9FAE for ; Tue, 22 Oct 2013 13:22:36 -0700 (PDT) Received: from [98.139.212.148] by nm15.bullet.mail.bf1.yahoo.com with NNFMP; 22 Oct 2013 20:22:36 -0000 Received: from [98.139.212.211] by tm5.bullet.mail.bf1.yahoo.com with NNFMP; 22 Oct 2013 20:22:36 -0000 Received: from [127.0.0.1] by omp1020.mail.bf1.yahoo.com with NNFMP; 22 Oct 2013 20:22:36 -0000 X-Yahoo-Newman-Property: ymail-3 X-Yahoo-Newman-Id: 69120.20859.bm@omp1020.mail.bf1.yahoo.com Received: (qmail 22411 invoked by uid 60001); 22 Oct 2013 20:22:35 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com.au; s=s1024; t=1382473355; bh=kykSwcetqebs4DROuS+cZa8ah1TpdYaGbWMOoG+/Xgk=; h=X-YMail-OSG:Received:X-Rocket-MIMEInfo:X-Mailer:References:Message-ID:Date:From:Reply-To:Subject:To:In-Reply-To:MIME-Version:Content-Type:Content-Transfer-Encoding; b=UDR/bKotJtnWoSa4oW7IUfWytOd2KLKrdfc0zlxPHAY9pYJ6zGnD9H0stJomO4e+TbQSdERoBlweMr0xkRf3w26LGSWNYTELo00WdGusRZQo6TT7lKEd/9fGog+IaMhTtLzwdLPQ7wgqBBct/RIfIaXZIRrqXRjva8ZNqYh2G80= DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com.au; h=X-YMail-OSG:Received:X-Rocket-MIMEInfo:X-Mailer:References:Message-ID:Date:From:Reply-To:Subject:To:In-Reply-To:MIME-Version:Content-Type:Content-Transfer-Encoding; b=rYeiqLa2ZZykFv9Qy3HWDCDDw2qhR6qc7QZUEu0rFbdkqDnzcg5XsU2uhJGm43mv7ufhzJ7VX1It/syxkNgcORUM2aXImg1GbE5Dhm5+hup/ElcaoXtZwh/DrfAlV4tTDvHk7MS/aynU6UBEELjrGbGu0pvcxC0g6hJKjbhQmEQ=; X-YMail-OSG: iAH2bfQVM1m_RXSrvOj67vJHfR6LZF4u_bLbvIdXGJjnydq F1h4a6pkjFmgZX401PInWL2kUZdlrToMVSYtYrUP8SNlzaLGLpU4Q76eBqGX wzD03yXcQX2fu29CQMm6D9gnh8Isy4vGY8zmMqZlxQYLR2xMAbjOTQWkJwwg VPbtiFJcjkXB7FlNAxUSxjJuUPNm7HY.5p8ed3g6BLvuw8mixCB8nun2KJE8 A.65cRY7I2wA69cUJqsUSMlC5D929WD8ZOvZtmOX36XFIuEoE6vjiYcWnmY9 eRBxvup7z2b5OPsRq3vxaTfaMFkLV_R5bfWiPewzsadJcDIWEt3wYC5_ZAmq ZSVghlB3Tbvk7bQYzUTs9pjfzGUJ9uurGWllGo1WSO99u6eiMcNwwrKYC6yR FSU0FSGXfi5a_lKQj9MZm5rJotwmU38fJhXaP4GZRDHQ48ntHn_pz_nZnFkt DHvn5uc3kwbdJZciXdT7HJPts_f2pJO0JHCIsEFEoDlTxAZDuoMUNObz4Tmi z23IvAhPYbSr6S1u_cj8bW8ZDFI7ANcskGK7hkYLbRojE1eL04xRJQEhI5Bw y7fBEp3uhC2V99Fmw6BrcYC6g.mCOjUP0u3cwMFJsj.M- Received: from [150.101.221.237] by web142504.mail.bf1.yahoo.com via HTTP; Tue, 22 Oct 2013 13:22:35 PDT X-Rocket-MIMEInfo: 002.001, U28gdGhlIG9uZSBxdWVzdGlvbiB0aGF0IGRvZXMgbm90IHNlZW0gdG8gYmUgYW5zd2VyZWQgaXMgd2h5IGlzIHRoZSBDUEUgdGhlIGJlc3QgcGxhY2UgdG8gZG8gdGhpcz8gV2h5IG5vdCBkbyBpdCBvbiB0aGUgQk5HL0JSQVM_IFRoZSBkcmFmdCBkb2VzIHNheSAib3IgZm9yIG1vYmlsZSBTZXJ2aWNlIFByb3ZpZGVycyAod2hlcmUgaXQgY2FuIGJlwqBjZW50cmFsbHkgaW1wbGVtZW50ZWQpLiIgaG93ZXZlciB0aGUgcmVzdCBvZiBpdCBpcyB0YWtpbmcgYWJvdXQgZG9pbmcgaXQgb24gdGhlIENQRS4KClRoaXMBMAEBAQE- X-Mailer: YahooMailWebService/0.8.160.587 References: <20131021134852.29396.64222.idtracker@ietfa.amsl.com> <97EB7536A2B2C549846804BBF3FD47E123795E0B@xmb-aln-x02.cisco.com> Message-ID: <1382473355.16715.YahooMailNeo@web142504.mail.bf1.yahoo.com> Date: Tue, 22 Oct 2013 13:22:35 -0700 (PDT) From: Mark ZZZ Smith To: "Eric Vyncke \(evyncke\)" , "v6ops@ietf.org" In-Reply-To: <97EB7536A2B2C549846804BBF3FD47E123795E0B@xmb-aln-x02.cisco.com> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Subject: Re: [v6ops] I-D Action: draft-ietf-v6ops-balanced-ipv6-security-00.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: Mark ZZZ Smith List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 22 Oct 2013 20:22:47 -0000 So the one question that does not seem to be answered is why is the CPE the= best place to do this? Why not do it on the BNG/BRAS? The draft does say "= or for mobile Service Providers (where it can be=A0centrally implemented)."= however the rest of it is taking about doing it on the CPE.=0A=0AThis sort= of thing has been done here in Australia by Internode on the BNG/BRAS sinc= e around 2007/2008, using both ingress and egress ACLs applied to each cust= omer's session. Customers can opt out of it if they choose. It doesn't requ= ire any special CPE capabilities, and keeps the unwanted traffic off of the= customers link. It is used/available for both IPv4 and IPv6.=0A=0AI also t= hink there should be some discussion of host based firewalls that are likel= y if not ubiquitously available on IPv6 hosts, in the context of this secur= ity model. This document seems to be presenting a view that the CPE is the = only security mechanism present.=0A=0AThis document seems to be being half = way between documenting what Swisscom have done, and providing general advi= ce derived from what Swisscom have done. Yet I'd disagree with a number of = things Swisscom have done, such as doing this in CPE rather than the BNG/BR= AS, and e.g., blocking SSH to the customer(!), but not SNMP(!). If it is go= ing to be an advice document, the other topics should be covered such as th= is idea in the context of (near) ubiquitous host based firewalling, expansi= on of the pros/cons of doing it on the CPE verses the BNG/BRAS, and things = such as what if the central updating mechanism either fails or is subverted= by an attacker. Otherwise, I think it should very explicitly only document= exactly what Swisscom have done.=0A=0AAs a side note, I generally disagree= with the whole idea, as it seems to me that once you start blocking specif= ic applications, you're not providing "Internet access" any more, you're pr= oviding "certain Internet application access". I don't think it is an ISPs = place to say what applications a user can or can't use. SNMP is a good exam= ple - v1 and 2 are quite insecure, but v3 is very secure - yet they all use= the same UDP port, so v3 would be dropped if SNMP was included in the Swis= scom list. There is also a form of encrypted telnet (RFC2946), and it would= seem my Fedora 19 box supports it (-x option). Encrypted telnet may not be= popularly used, but the assertion that telnet is not secure cannot be made= (people of course use SSH instead, but that is dropped too!). In general, = the customer opt-out that Internode provide makes it somewhat tolerable to = me. Customer opt out is easy to do on the BNG/BRAS, but if it was embedded = in the CPE, it is up to the CPE vendor as to whether it is able to be switched off or not and the rule set= s are and can easily be kept up to date by customers, assuming they have th= e competence to do so. We really don't want something like this to happen a= gain :=0A=0AAutoSecure Bogon Filter Potentially Causes Blackholing of Inter= net Traffic=0A=0Ahttp://www.cisco.com/en/US/ts/fn/610/fn61971.html=0A=0A=0A= =0ARegards,=0AMark.=A0=0A=0A=0A=0A----- Original Message -----=0A> From: Er= ic Vyncke (evyncke) =0A> To: "v6ops@ietf.org" =0A> Cc: =0A> Sent: Tuesday, 22 October 2013 4:35 PM=0A> Subject: Re:= [v6ops] I-D Action: draft-ietf-v6ops-balanced-ipv6-security-00.txt=0A> =0A= > Here are the main changes based on the Berlin meeting discussion:=0A> =0A= > In order to avoid that this document appears as an IETF 'blessing' of a = =0A> specific ACL (or layer-4 ports), a lot of verbiage has been added to s= how the =0A> list as EXAMPLE and we have removed all 'proposals' and =0A> '= recommend' in favor of the word 'example'.=0A> =0A> We kept the list of por= ts as an example but clearly mentioned that this list was =0A> based on kno= wn vulnerabilities in protocols (e.g. Telnet is in the clear) or =0A> imple= mentations (still some worms active on 445 for old Windows =0A> implementat= ions). Again, examples.=0A> =0A> Another generic rule was added to allow fo= r remote management (in the case of =0A> managed CPE).=0A> =0A> A mention i= s also added about whether to do stateless or stateful filtering is =0A> no= t that relevant for this I-D as its only objective is to give an example of= =0A> what a SP did.=0A> =0A> =0A> As a side note, Ragnar (a co-author) has= presented this approach at the RIPE =0A> meeting =3D> several positive dis= cussions=0A> =0A>> -----Original Message-----=0A>> From: v6ops-bounces@ie= tf.org [mailto:v6ops-bounces@ietf.org] On Behalf Of=0A>> internet-drafts@i= etf.org=0A>> Sent: lundi 21 octobre 2013 19:19=0A>> To: i-d-announce@ietf= .org=0A>> Cc: v6ops@ietf.org=0A>> Subject: [v6ops] I-D Action: draft-ietf= -v6ops-balanced-ipv6-security-=0A>> 00.txt=0A>> =0A>> =0A>> A New Interne= t-Draft is available from the on-line Internet-Drafts=0A>> directories.=0A= >> =A0 This draft is a work item of the IPv6 Operations Working Group of th= e=0A>> IETF.=0A>> =0A>> =A0=A0=A0 Title=A0 =A0 =A0 =A0 =A0 : Balanced Se= curity for IPv6 Residential CPE=0A>> =A0=A0=A0 Author(s)=A0 =A0 =A0 : Mar= tin Gysi=0A>> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 Guillaum= e Leclanche=0A>> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 Eric = Vyncke=0A>> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 Ragnar Anf= insen=0A>> =A0=A0=A0 Filename=A0 =A0 =A0 =A0 : draft-ietf-v6ops-balanced-i= pv6-security-00.txt=0A>> =A0=A0=A0 Pages=A0 =A0 =A0 =A0 =A0 : 7=0A>> =A0= =A0=A0 Date=A0 =A0 =A0 =A0 =A0 =A0 : 2013-10-21=0A>> =0A>> Abstract:=0A>> = =A0 =A0 This document describes how an IPv6 residential Customer Premise=0A= >> =A0 =A0 Equipment (CPE) can have a balanced security policy that allows = for a=0A>> =A0 =A0 mostly end-to-end connectivity while keeping the major t= hreats=0A>> =A0 =A0 outside of the home.=A0 It is based on an actual IPv6 d= eployment by=0A>> =A0 =A0 Swisscom and allows all packets inbound/outbound = EXCEPT for some=0A>> =A0 =A0 layer-4 ports where attacks and vulnerabilitie= s (such as weak=0A>> =A0 =A0 passwords) are well-known.=A0 The blocked inbo= und ports is expected to=0A>> =A0 =A0 be updated as threats come and go.=0A= >> =0A>> =0A>> The IETF datatracker status page for this draft is:=0A>> h= ttps://datatracker.ietf.org/doc/draft-ietf-v6ops-balanced-ipv6-security=0A>= > =0A>> There's also a htmlized version available at:=0A>> http://tools.i= etf.org/html/draft-ietf-v6ops-balanced-ipv6-security-00=0A>> =0A>> =0A>> P= lease note that it may take a couple of minutes from the time of=0A>> subm= ission until the htmlized version and diff are available at=0A>> tools.iet= f.org.=0A>> =0A>> Internet-Drafts are also available by anonymous FTP at:= =0A>> ftp://ftp.ietf.org/internet-drafts/=0A>> =0A>> ____________________= ___________________________=0A>> v6ops mailing list=0A>> v6ops@ietf.org= =0A>> https://www.ietf.org/mailman/listinfo/v6ops=0A> =0A> _______________= ________________________________=0A> v6ops mailing list=0A> v6ops@ietf.org= =0A> https://www.ietf.org/mailman/listinfo/v6ops=0A> From nalini.elkins@insidethestack.com Tue Oct 22 19:47:48 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EEBB411E8275 for ; Tue, 22 Oct 2013 19:47:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.382 X-Spam-Level: X-Spam-Status: No, score=-2.382 tagged_above=-999 required=5 tests=[AWL=0.216, 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 o4SYxmUedkcf for ; Tue, 22 Oct 2013 19:47:42 -0700 (PDT) Received: from nm22-vm4.access.bullet.mail.gq1.yahoo.com (nm22-vm4.access.bullet.mail.gq1.yahoo.com [216.39.63.110]) by ietfa.amsl.com (Postfix) with ESMTP id 3F8EE11E80F6 for ; Tue, 22 Oct 2013 19:47:42 -0700 (PDT) Received: from [216.39.60.165] by nm22.access.bullet.mail.gq1.yahoo.com with NNFMP; 23 Oct 2013 02:47:42 -0000 Received: from [216.39.60.243] by tm1.access.bullet.mail.gq1.yahoo.com with NNFMP; 23 Oct 2013 02:47:42 -0000 Received: from [127.0.0.1] by omp1014.access.mail.gq1.yahoo.com with NNFMP; 23 Oct 2013 02:47:42 -0000 X-Yahoo-Newman-Property: ymail-3 X-Yahoo-Newman-Id: 27151.64201.bm@omp1014.access.mail.gq1.yahoo.com Received: (qmail 47023 invoked by uid 60001); 23 Oct 2013 02:47:41 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s1024; t=1382496461; bh=cp/HBCX/azKn4xEzvCECFX47EmKLyeH/PkzW2nQkVfg=; h=X-YMail-OSG:Received:X-Rocket-MIMEInfo:X-Mailer:References:Message-ID:Date:From:Reply-To:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type; b=cCILD0lcg4yCQrbCKIsOasldBSmzwrTwj00/2xYq+zJyjhhy6n3Cf5eMNxUWwt01dbFxx0V6L9Bz02kC8gSPYcH27aQlZXRuFHSS5R12P1bDmuwMFSb5Tu1pqV/ecSbv2ZNdO3lx3MZm0XAqscPSdZmaEKL+ZqQTSnbg3bDyZ20= X-YMail-OSG: QPQC_PsVM1kZD_X6gftynY4P1O7fpNe3sXgZmv80zWVACon 0c4YSAvjLK7lrM9GBYC1tsImxDhj_Yv_c9JUzlt89s57taT5hkZaFLU3wura dbkpAoGoL398Wp_SPxc6_I5D8ZqfG2.auj7MojOJvR.m6gH7_i1JjdrNoKAW KskYXNZCdRS.xDt2RdTzdHoQq2FFHxACNh3gXI3OAQpAnek2xNd96ar0Fb0y G3T9Llgg_uvxyqa_4kkh3_FFtTwno0mVzqPSfsH5c6fFo6hvdA2g5OdHpDVD 8moyZzinaLOczBgi6tiUzZU9vrCtcx2_FkiB4KuwpHr0nKtpC4i5mp8NQbLZ ydi5VRWZ2QxsuV7DwQ5.VA.2PBKscBTAy5xUmi5d568mNhbjvUE.KuFWXUIC dDlNxkMQaR_dHsLO9f9L_vK3On292mgnHeNomXnjjTjkikPpCCpnhG7Hkmn. xVLQmLtyHx.y1jy8PitoDE4wJQuqOJmDa.0K9xSPXID3gu_DzAS12QmtSjsb CpIWqr1JMPLCSwVgFmkczX7Vzwsr8exMm__v5fIfD3TbT_1kih2VQJFwGrQK PXoNxb6DajkwKdVcCiJj_xJ1Aspkil4VXwKHorw-- Received: from [24.130.37.147] by web2802.biz.mail.ne1.yahoo.com via HTTP; Tue, 22 Oct 2013 19:47:40 PDT X-Rocket-MIMEInfo: 002.001, Cgo.IE5hbGluaSBFbGtpbnMgPG1haWx0bzpuYWxpbmkuZWxraW5zQGluc2lkZXRoZXN0YWNrLmNvbT4KPiAyMiBPY3RvYmVyIDIwMTMgMDA6NTgKPj7CoCAxKSBlbmNvZGluZyBoYXMgdG8gYmUgZmFzdCwgYnV0IGRlY29kaW5nIGRvZXMgbm90Cj4KPiBUcnVlCj4KPj7CoCAyKSBhIG5vZGUncyBjbG9jayBjb3VsZCBiZSBlaXRoZXIgaW4gb3VyIG91dCBvZiBzeW5jaCB3aXRoIHNvbWUgbm90aW9uYWwKPj7CoCBtYXN0ZXIgY2xvY2sgKGUuZy4gdmlhIE5UUCkKPj7CoCAzKSB0d28gY2xvY2tzIGNvdWxkIGJlIGkBMAEBAQE- X-Mailer: YahooMailWebService/0.8.160.587 References: <20131017032024.5051.20799.idtracker@ietfa.amsl.com> <1381980305.36254.YahooMailNeo@web2803.biz.mail.ne1.yahoo.com> <5263C783.1080001@globis.net> <1382396300.22968.YahooMailNeo@web2801.biz.mail.ne1.yahoo.com> <526616C4.40304@globis.net> Message-ID: <1382496460.46942.YahooMailNeo@web2802.biz.mail.ne1.yahoo.com> Date: Tue, 22 Oct 2013 19:47:40 -0700 (PDT) From: Nalini Elkins To: Ray Hunter In-Reply-To: <526616C4.40304@globis.net> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="-153701192-410707112-1382496460=:46942" Cc: v6ops WG , 6man WG , "ippm@ietf.org" Subject: Re: [v6ops] Fw: New Version Notification for draft-elkins-6man-ipv6-pdm-dest-option-04.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: Nalini Elkins List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 23 Oct 2013 02:47:49 -0000 ---153701192-410707112-1382496460=:46942 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable =0A=0A> Nalini Elkins =0A> 22 Octo= ber 2013 00:58=0A>>=A0 1) encoding has to be fast, but decoding does not=0A= >=0A> True=0A>=0A>>=A0 2) a node's clock could be either in our out of sync= h with some notional=0A>>=A0 master clock (e.g. via NTP)=0A>>=A0 3) two clo= cks could be in synch to a master source, but the master=0A>>=A0 sources ma= y themselves not share a common source (one sourced from GPS,=0A>> one from= DCF77)=0A>> 4) the key to being able to perform the end to end calculation= s is=0A>> whether two communicating nodes are synchronised to the same mast= er=0A>> clock (within some level of error/jitter)=0A>> 5) the absolute time= is not particularly important=0A>=0A>=0A> This is true for PDM 1 only.=A0 = PDM 2 does not require time synchronization.=0A>=0A>>=A0 Q1. Why do you wan= t to encode differences as deltas in the case of an unsynchronised/ free ru= nning clock?=0A>>=A0 Isn't that slow, and difficult for hardware implementa= tions to achieve (e.g. TCP offload)? Doesn't it also require maintaining la= rge amounts of state in the sending node.=0A>>=0A>=0A> 1. I think that it i= s going to be interesting to see how hardware is going to handle TCP offloa= d with IPv6 extension headers.=A0 I do not see why PDM 2 would be so much = harder than PDM 1 for an OS.=0A> Can you tell me which end host operating s= ystems are doing TCP offload in hardware?=A0 =0A=0A=0A>IMHO Not a relevant = question. As a standards body we should be looking=0A>to the future. There = are many operations that are delegated to microcode.=0A=0A>If you specified= the packet with one single way of encapsulating=0A>timestamps, then hardwa= re or interface microcode could add the timestamp=0A>at the last possible m= oment before the packet reached the wire, without=0A>having to examine the = original packet contents, or knowing the context=0A>of the communicating no= des. I think that's very desirable.=0A=0ASure. =A0 Sounds good! =A0Also loo= king to the future, then I will speculate that we will likely have more and= better time synchronization also.=0A=0A=0A> I know some OS's which process= TCP segmentation in hardware.=A0 =A0 But at this point, the packet is alre= ady crafted.=A0 Also some do IP checksum offload in hardware but that does = not apply to IPv6 as there is no IP header checksum.=0A=0A>=0A>=0A> 2.=A0 E= nd hosts already maintain quite a bit of state.=A0 Every OS has control blo= cks to handle events such as TCP duplicate packets, round trip time, conges= tion window, etc.=A0 We are NOT suggesting=0A> that the PDM headers be use= d in middle boxes.=A0 That is, we are NOT asking routers to maintain state.= =0A=0A=0A>So what? Why add to the problem?=0A=0AYes. =A0Just saying that we= are not CREATING the problem.=0A=0A>Why does the timestamp require synchro= nisation with that other TCP state?=0A=0AIt doesn't. =A0Just mentioning oth= er reasons why state is maintained.=0A=0A>Isn't it better to define a solut= ion that is independent of the upper=A0layer header transport protocol?=0A= =0AYes. =A0Our solution IS independent. =A0I think my analogy actually conf= used the issue!=0A=0A>=A0 Why not allow middleboxes (or node hardwa= re) to insert the=A0timestamp header on the fly?=0A=0AInteresting = idea!=0A=0A>=0A>>=A0 Why not just encode the timestamp as-is and perform th= e appropriate difference calculation during decoding?=0A>=0A> If clocks are= out of synch, you could end up having it look like you received the packet= before you sent it.=0A=0A>=A0No. I'm not suggesting you use the same decod= ing algorithm: only that=A0you define a single common encoding algorithm th= at combines all the=A0information required for PDM 1 and PDM 2 calculations= . Having to chose=0A>which packet encoding to use in advance is problematic= IMHO.=A0=0A=0AWe will look at this. =A0 I am also meeting with a couple of= the end host OS vendors to get their viewpoint on the PDMs. =A0 Their engi= neers have good opinions on what the problems might be with actually creati= ng PDMs.=0AI should have that info before Vancouver.=0A=0A>>=A0 Q2. Why do = you need two separate packet formats at all?=0A>=0A>>=A0 Why not have a com= mon format for all cases, containing a timestamp based=0A>> on the local cl= ock, plus an optional field containing a flag that states=0A>> if the local= timestamp is coordinated to some master clock, plus an=0A>> identifier for= the master clock.=0A>=0A>> You could then encode whether a node had a free= -running clock (case 2),=0A>> a synchronised clock (case 1), and whether it= was synched via NTP to=0A>> some stratum 0 source e.g. GPS, and also some = identification of the=0A>> stratum 1 source (IPv6 address).=0A>=0A>> Two co= mmunicating nodes could then use e.g. NTP trace to see if they=0A>> shared = a common clock source or not, before performing their calculations.=0A>=0A>= We are trying to craft a solution with PDM 2 for those situations where ti= me synchronization is not practical, possible or desired.=0A=0A>I understan= d the aim, but let me ask my question a different way.=0A=0A>Imagine there = are nodes A&B that with clocks synched to DCF77.=0A>Imagine there are nodes= C&D that with clocks=A0 synched to GPS.=0A>Node E has free running clock (= possibly because the GPS receiver is down).=0A=0A>Which packet format PDM t= ype 1 or PDM type 2 do you use between each=0A>pair of nodes, and how does = the sending node know that?=0A=0A>Scale this solution to 100K hosts.=0A=0AG= ood question. =A0We were thinking that each node would start with PDM 1 and= then if the other side could not do PDM 1, then it would drop back to PDM = 2.=0ABut, the clock issue is good. =A0Now,=A0my understanding is that clock= difference has more to do with Stratum levels. =A0 =A0But, I am not the NT= P expert in the group.=A0=0AI am just wondering (leaving off Node E) how mu= ch clock difference would there be? =A0 What do you think?=A0I have a meeti= ng with my team tomorrow &=A0will bring this up for discussion.=0A=0A>=0A> = ------------------------------------------------------------------------=0A= =0A=0A-- =0ARegards,=0ARayH ---153701192-410707112-1382496460=:46942 Content-Type: text/html; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable

=0A> Nalini Elkins <mailto:nalini.elkins@insidethestack.com>
> 22 October= 2013 00:58
>>  1) encoding has to be fast, but decoding does= not
>
> True
>
>>  2) a node's clock could= be either in our out of synch with some notional
>>  master = clock (e.g. via NTP)
>>  3) two clocks could be in synch to a= master source, but the master
>>  sources may themselves not= share a common source (one sourced from GPS,
>> one from DCF77)>> 4) the key to being able to perform the end to end calculations = is
>> whether two communicating nodes are synchronised to the same= master
>> clock (within some level of error/jitter)
>> 5= ) the absolute time is not particularly important
>
>
> T= his is true for PDM 1 only.  PDM 2 does not require time synchronization.
>
>&g= t;  Q1. Why do you want to encode differences as deltas in the case of= an unsynchronised/ free running clock?
>>  Isn't that slow, = and difficult for hardware implementations to achieve (e.g. TCP offload)? D= oesn't it also require maintaining large amounts of state in the sending no= de.
>>
>
> 1. I think that it is going to be interesti= ng to see how hardware is going to handle TCP offload with IPv6 extension h= eaders.  I do not see why PDM 2 would be so much harder than PDM 1 fo= r an OS.
> Can you tell me which end host operating systems are doing= TCP offload in hardware? 

>IMHO Not a relevant question. As a standards body we should be looki= ng
>to the future. There are many operations that are delegated to mi= crocode.

>If you specified the packet with one single way of encapsulating
>timestamps, then hardware or interface microcode coul= d add the timestamp
>at the last possible moment before the packet re= ached the wire, without
>having to examine the original packet conten= ts, or knowing the context
>of the communicating nodes. I think that'= s very desirable.

Sure.   Sounds good!  Also looking to the fu= ture, then I will speculate that we will likely have more and better time s= ynchronization also.

> I know som= e OS's which process TCP segmentation in hardware.    But at this= point, the packet is already crafted.  Also some do IP checksum offlo= ad in hardware but that does not apply to IPv6 as there is no IP header che= cksum.
>
>
> 2.  End hosts already maintain quite a bit of state.  Every OS h= as control blocks to handle events such as TCP duplicate packets, round tri= p time, congestion window, etc.  We are NOT suggesting
> that t= he PDM headers be used in middle boxes.  That is, we are NOT asking ro= uters to maintain state.

>So= what? Why add to the problem?

Yes.  Just saying that we are no= t CREATING the problem.

>Why doe= s the timestamp require synchronisation with that other TCP state?

It doesn't.  Just mentioning other reasons why state is maintained.

>Isn't it better to define a solution that is independent of the upper&= nbsp;layer header transport protocol?

Yes. &n= bsp;Our solution IS independent.  I think my analogy actually confused= the issue!

><heresy>  Why= not allow middleboxes (or node hardware) to insert the timestamp header on the fly?</heresy>

=

><= br>>>  Why not just encode the timestamp as-is and perform the a= ppropriate difference calculation during decoding?
>
> If clock= s are out of synch, you could end up having it look like you received the p= acket before you sent it.

> No. I'm not suggesting you use the same decoding= algorithm: only that you define a single common encoding algorithm th= at combines all the information required for PDM 1 and PDM 2 calculati= ons. Having to chose
>which packet e= ncoding to use in advance is problematic IMHO. 

We will look at this= .   I am also meeting with a couple of the end host OS vendors to get = their viewpoint on the PDMs.   Their engineers have good opinions on w= hat the problems might be with actually creating PDMs.
I should have that info before Vancouver.

>>&n= bsp; Q2. Why do you need two separate packet formats at all?
>
>= ;>  Why not have a common format for all cases, containing a timest= amp based
>> on the local clock, plus an optional field containing a flag that states
>> if the local timestamp is coordinated to so= me master clock, plus an
>> identifier for the master clock.
&g= t;
>> You could then encode whether a node had a free-running cloc= k (case 2),
>> a synchronised clock (case 1), and whether it was s= ynched via NTP to
>> some stratum 0 source e.g. GPS, and also some= identification of the
>> stratum 1 source (IPv6 address).
>=
>> Two communicating nodes could then use e.g. NTP trace to see i= f they
>> shared a common clock source or not, before performing t= heir calculations.
>
> We are trying to craft a solution with P= DM 2 for those situations where time synchronization is not practical, poss= ible or desired.

>I understand the aim, but let me ask my questio= n a different way.

>Imagine there are nodes A&B that with clo= cks synched to DCF77.
>Imagine there are nodes C&D that with clocks  synched to GPS.
>= Node E has free running clock (possibly because the GPS receiver is down).<= br>
>Which packet format PDM type 1 or PDM type 2 do you use between = each
>pair of nodes, and how does th= e sending node know that?

>Scale this solution to 100K hosts.

Good q= uestion.  We were thinking that each node would start with PDM 1 and t= hen if the other side could not do PDM 1, then it would drop back to PDM 2.=
But, = the clock issue is good.  Now,=  my understanding is that cloc= k difference has more to do with Stratum levels.    But, I am not= the NTP expert in the group. 
I am just wondering (leaving off Node E) how much clock difference would there be= ?   What do you think? I = have a meeting with my team tomorrow & will bring this up for discussion.

>
> ------------------------------------------= ------------------------------


--
Regards,
RayH


---153701192-410707112-1382496460=:46942-- From swmike@swm.pp.se Tue Oct 22 20:40:20 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9F8B511E80F5 for ; Tue, 22 Oct 2013 20:40:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xLcfNbROxc+P for ; Tue, 22 Oct 2013 20:40:20 -0700 (PDT) Received: from uplift.swm.pp.se (ipv6.swm.pp.se [IPv6:2a00:801::f]) by ietfa.amsl.com (Postfix) with ESMTP id 26F0611E8118 for ; Tue, 22 Oct 2013 20:40:14 -0700 (PDT) Received: by uplift.swm.pp.se (Postfix, from userid 501) id 332599C; Wed, 23 Oct 2013 05:40:14 +0200 (CEST) Received: from localhost (localhost [127.0.0.1]) by uplift.swm.pp.se (Postfix) with ESMTP id 272739A; Wed, 23 Oct 2013 05:40:14 +0200 (CEST) Date: Wed, 23 Oct 2013 05:40:14 +0200 (CEST) From: Mikael Abrahamsson To: Mark ZZZ Smith In-Reply-To: <1382469405.56346.YahooMailNeo@web142504.mail.bf1.yahoo.com> Message-ID: References: <201310211245.r9LCj0B29668@ftpeng-update.cisco.com> <8AE0F17B87264D4CAC7DE0AA6C406F453D7CC14B@nkgeml506-mbx.china.huawei.com> <1382469405.56346.YahooMailNeo@web142504.mail.bf1.yahoo.com> User-Agent: Alpine 2.02 (DEB 1266 2009-07-14) Organization: People's Front Against WWW MIME-Version: 1.0 Content-Type: MULTIPART/MIXED; BOUNDARY="-137064504-61013402-1382499614=:1838" Cc: "v6ops@ietf.org" , "draft-liu-bonica-v6ops-dhcpv6-slaac-problem@tools.ietf.org" Subject: Re: [v6ops] DHCPv6/SLAAC Make Hosts Confusing-//RE: new draft: draft-liu-bonica-v6ops-dhcpv6-slaac-problem X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 23 Oct 2013 03:40:20 -0000 This message is in MIME format. The first part should be readable text, while the remaining parts are likely unreadable without MIME-aware tools. ---137064504-61013402-1382499614=:1838 Content-Type: TEXT/PLAIN; charset=iso-8859-1; format=flowed Content-Transfer-Encoding: 8BIT On Tue, 22 Oct 2013, Mark ZZZ Smith wrote: > Is this saying that the prefix length of the address on host is /128? A single address is always a /128. This /128 can be part of an on-link other network, or it isn't. > If that is the case, as the prefix length in doesn't indicate on-link or > off-link status (as RA PIOs do), is there any specific reason for the > prefix length the DHCPv6 server hands out to be /128 instead of the > subnet's prefix length of /64?  The DHCPv6 server always hands out /128. This /128 can be within a subnet advertised in RA, or it can be outside of it. The host doesn't care. When a subnet is being advertised in RA you get a network route pointing to the interface without an IPv6 address as next-hop. So it's perfectly achievable today (and it works) to have the following: Host gets 2001:db8:fff::1/128 from dhcp host gets on-link 2001:db8:1::/64 from RA and creates a route towards the interface for this, but doesn't do SLAAC because A=0. Host gets default route from router and installs it. Now, the *router* needs to understand that 2001:db8:fff::1/128 is on-link, but no other hosts on the network does not. So what networks are being announced in RA is completely decoupled from addresses handed out by DHCPv6 IA_NA. It's perfectly valid to hand out a /128 and then have no on-link prefixes at all, or have some with A=0. -- Mikael Abrahamsson email: swmike@swm.pp.se ---137064504-61013402-1382499614=:1838-- From fred@cisco.com Tue Oct 22 22:52:59 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C336011E82F1 for ; Tue, 22 Oct 2013 22:52:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.299 X-Spam-Level: X-Spam-Status: No, score=-110.299 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, J_CHICKENPOX_13=0.6, RCVD_IN_DNSWL_HI=-8, 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 ss4ugGn2D9ns for ; Tue, 22 Oct 2013 22:52:55 -0700 (PDT) Received: from rcdn-iport-8.cisco.com (rcdn-iport-8.cisco.com [173.37.86.79]) by ietfa.amsl.com (Postfix) with ESMTP id A289511E82ED for ; Tue, 22 Oct 2013 22:52:51 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=4001; q=dns/txt; s=iport; t=1382507571; x=1383717171; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=Bg2fJj9aetTlb3UgYBjfT/IES+LRNfg/KuO0zvpW/5w=; b=X3vZFtFb3JkZzkDSIKmj5n1s/GR7FtiQ2Y2L6gkD0lqtBMTAGzsA9vQo BjGYNysK/Yrrqwmhk3XQdYoGyy9dEl/AXGuWjTm4nzFMd8+AJfZKpuhBT N8uFKLj7e2LldGa208hOp4LlMu3nApDhaYM79stMJ9o6XmAHBMNqsC4wG s=; X-Files: signature.asc : 195 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgYFAN5iZ1KtJXG//2dsb2JhbABZgwc4VL5SgS0WdIIlAQEBAwEBAQFrCwULAgEIDgQQJCcLFw4CBAENBQgBBYdyBg26Yo8dMQeDH4EKA5AtgTCHW5BYgySCKg X-IronPort-AV: E=Sophos;i="4.93,553,1378857600"; d="asc'?scan'208";a="275468122" Received: from rcdn-core2-4.cisco.com ([173.37.113.191]) by rcdn-iport-8.cisco.com with ESMTP; 23 Oct 2013 05:52:51 +0000 Received: from xhc-rcd-x14.cisco.com (xhc-rcd-x14.cisco.com [173.37.183.88]) by rcdn-core2-4.cisco.com (8.14.5/8.14.5) with ESMTP id r9N5qpkP014417 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 23 Oct 2013 05:52:51 GMT Received: from xmb-rcd-x09.cisco.com ([169.254.9.23]) by xhc-rcd-x14.cisco.com ([173.37.183.88]) with mapi id 14.02.0318.004; Wed, 23 Oct 2013 00:52:50 -0500 From: "Fred Baker (fred)" To: Hosnieh Rafiee , Erik Nordmark Thread-Topic: [v6ops] I-D: draft-rafiee-v6ops-iid-lifetime-00.txt Thread-Index: AQHOz7Qb7tczfBfL102ng3enJ0ivMw== Date: Wed, 23 Oct 2013 05:52:50 +0000 Message-ID: <8C48B86A895913448548E6D15DA7553BA74263@xmb-rcd-x09.cisco.com> References: <021e01ceceb4$88158570$98409050$@rozanak.com> In-Reply-To: <021e01ceceb4$88158570$98409050$@rozanak.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-originating-ip: [10.61.212.192] Content-Type: multipart/signed; boundary="Apple-Mail=_AF99458F-E073-4762-A391-3D5A1401314E"; protocol="application/pgp-signature"; micalg=pgp-sha1 MIME-Version: 1.0 Cc: "v6ops@ietf.org" Subject: Re: [v6ops] I-D: draft-rafiee-v6ops-iid-lifetime-00.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 23 Oct 2013 05:52:59 -0000 --Apple-Mail=_AF99458F-E073-4762-A391-3D5A1401314E Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 This, along with RFC 4941's observation that there may be utility in an = IID that is not tied to hardware identifiers, would appear consistent = with the thought and recommendations of=20 https://tools.ietf.org/html/rfc1498 1498 On the Naming and Binding of Network Destinations. J. Saltzer. August 1993. (Format: TXT=3D24698 bytes) (Status: INFORMATIONAL) and the definition of an Endpoint ID in=20 https://tools.ietf.org/html/rfc1992 1992 The Nimrod Routing Architecture. I. Castineyra, N. Chiappa, M. Steenstrup. August 1996. (Format: TXT=3D59848 bytes) (Status: INFORMATIONAL) The latter is the origin of the question of a locator/id split; a = locator identifies the location of a network point of attachment, and an = identifier in essence identifies what we might call a "socket". Imagine = - although I can't say I know *why* someone would want to do this = - one wanted to move an application from one physical or = virtual machine to another. If the identifier could move with the = application, that would simplify such motion. Note that the NIMROD architecture and Saltzer's document are not = fundamentally about security. They are about scalable management of = applications interconnected by a network and routing in that network. On Oct 22, 2013, at 3:23 AM, Hosnieh Rafiee wrote: > We submitted a new draft which compares the current mechanisms to = maintain the lifetime of IIDs and then introduces a framework to enable = applications maintaining their privacy by making it difficult to = correlate a user's activities by using different IIDs for different = applications, without negatively impacting the robustness of the = applications. >=20 > We're looking forward to receiving your comments. >=20 >=20 > Filename: draft-rafiee-v6ops-iid-lifetime > Revision: 00 > Title: Interface ID lifetime Algorithms > Creation date: 2013-10-21 > Group: Individual Submission > Number of pages: 11 > URL: = http://www.ietf.org/internet-drafts/draft-rafiee-v6ops-iid-lifetime-00.txt= > Status: = http://datatracker.ietf.org/doc/draft-rafiee-v6ops-iid-lifetime > Htmlized: = http://tools.ietf.org/html/draft-rafiee-v6ops-iid-lifetime-00 >=20 >=20 > Abstract: > This document introduces a framework, i.e., an application layer > based lifetime [applicationiid] to enable applications maintaining > their users' privacy as well as controlling the number of Interface > IDs (IIDs) per network adapter. It will also explain different > approaches that can be used for maintaining the lifetime of an IID. > We also compare this framework to the other available mechanisms. > This document also explains when to remove deprecated IP addresses > from the a network interface. >=20 >=20 > -----------smile---------- > Hosnieh > =85 success is a journey, not a destination=85. > You cannot change your destination overnight, but you can change your = direction ... Focus on the journey >=20 >=20 > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops If at first the idea is not absurd, then there is no hope for it. =20 Albert Einstein --Apple-Mail=_AF99458F-E073-4762-A391-3D5A1401314E Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="signature.asc" Content-Type: application/pgp-signature; name="signature.asc" Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- Comment: GPGTools - http://gpgtools.org iD8DBQFSZ2QsbjEdbHIsm0MRAnM1AJ9coqILaxhBL9BOJIk9xL2cQCZkPQCgsa4h Cxn83ZbXZ8nz3KDNU9pZ84g= =27ZU -----END PGP SIGNATURE----- --Apple-Mail=_AF99458F-E073-4762-A391-3D5A1401314E-- From fred@cisco.com Tue Oct 22 23:44:17 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7A85411E82F6 for ; Tue, 22 Oct 2013 23:44:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.261 X-Spam-Level: X-Spam-Status: No, score=-110.261 tagged_above=-999 required=5 tests=[AWL=-0.262, BAYES_00=-2.599, J_CHICKENPOX_13=0.6, RCVD_IN_DNSWL_HI=-8, 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 wtbu+ShHyMyO for ; Tue, 22 Oct 2013 23:44:12 -0700 (PDT) Received: from rcdn-iport-6.cisco.com (rcdn-iport-6.cisco.com [173.37.86.77]) by ietfa.amsl.com (Postfix) with ESMTP id 732DE11E816F for ; Tue, 22 Oct 2013 23:44:12 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=4910; q=dns/txt; s=iport; t=1382510652; x=1383720252; h=from:to:cc:subject:date:message-id:references: in-reply-to:reply-to:mime-version; bh=daQKLIrcTUFOj7dCtQWkXwvTsmRLSpRGahk/kykxShc=; b=KblF7Je9p4MzXySsJ3cE+WBBjziHa51+xNTUc2kU7JbGt1O8Nuxd6tme LhwdoZYpQCThsh/I7ol83CnJcvA07nz0GUDg1pdu04dDB9e0a8eJMOBv4 wmgAEL9jQg5s6zUs/iRcDX7FmaVGZeJ/dV6bYP0yA8j02v5HvTUujDGFq 8=; X-Files: signature.asc : 195 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgUFABpvZ1KtJXG9/2dsb2JhbABZgwc4VL5SgSIWdIImAQEEZQkLEAIBKiQyDhcCBA4FCAaHeA26UI8dMQeDH4EKA5AtgTCHW5BYgySCKg X-IronPort-AV: E=Sophos;i="4.93,553,1378857600"; d="asc'?scan'208";a="275489960" Received: from rcdn-core2-2.cisco.com ([173.37.113.189]) by rcdn-iport-6.cisco.com with ESMTP; 23 Oct 2013 06:44:12 +0000 Received: from xhc-rcd-x07.cisco.com (xhc-rcd-x07.cisco.com [173.37.183.81]) by rcdn-core2-2.cisco.com (8.14.5/8.14.5) with ESMTP id r9N6iA5I019806 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 23 Oct 2013 06:44:11 GMT Received: from xmb-rcd-x09.cisco.com ([169.254.9.23]) by xhc-rcd-x07.cisco.com ([173.37.183.81]) with mapi id 14.02.0318.004; Wed, 23 Oct 2013 01:44:10 -0500 From: "Fred Baker (fred)" To: "v6ops@ietf.org WG" Thread-Topic: Current state of v6ops drafts, updated Thread-Index: AQHOz7tGrq1y9sLiZkyqLxEuU22YOg== Date: Wed, 23 Oct 2013 06:44:09 +0000 Message-ID: <8C48B86A895913448548E6D15DA7553BA74409@xmb-rcd-x09.cisco.com> References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-originating-ip: [10.61.212.192] Content-Type: multipart/signed; boundary="Apple-Mail=_8810E651-34D8-4824-82EF-ACDB2F6F229B"; protocol="application/pgp-signature"; micalg=pgp-sha1 MIME-Version: 1.0 Subject: [v6ops] Current state of v6ops drafts, updated X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: "V6ops Chairs \(v6ops-chairs@tools.ietf.org\)" , joel jaeggli List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 23 Oct 2013 06:44:17 -0000 --Apple-Mail=_8810E651-34D8-4824-82EF-ACDB2F6F229B Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii I'm pulling an agenda together for IETF 88. My sources include the = internet drafts directory and http://datatracker.ietf.org/wg/v6ops/, = plus my mail store. I am interested in your viewpoints on this. The last = paragraph of this note contains a question I'd appreciate answers to, = private to v6ops-chairs@tools.ietf.org or to the list. One relevant point - Chris Palmer of Microsoft wants to talk about the = evolution of the XBOX. When Dave Thaler asked me to speak about the = evolution (devolution?) of Teredo, I put him on the agenda on the = premise that this was an ongoing topic in the WG and of interest to the = operators. In the case of the XBOX, that's not so obvious to me. So, = please, if you're interested in such a talk, please advise, copying at = least John, Chris, and myself if not the working group. Draft status: RFC Ed Queue: Oct 30 draft-ietf-v6ops-6204bis Nov 14 draft-ietf-v6ops-ra-guard-implementation Mar 18 draft-ietf-v6ops-ipv6-multihoming-without-ipv6nat Sep 15 draft-ietf-v6ops-rfc3316bis Exiting WGLC; on its way to IESG: Oct 7 draft-ietf-v6ops-64share Oct 16 draft-ietf-v6ops-enterprise-incremental-ipv6 Working Group Document updated since IETF: Aug 14 draft-ietf-v6ops-dc-ipv6 Aug 15 draft-ietf-v6ops-monitor-ds-ipv6 Sep 11 draft-ietf-v6ops-mobile-device-profile Oct 14 draft-ietf-v6ops-nat64-experience Oct 21 draft-ietf-v6ops-ula-usage-recommendations Oct 21 draft-ietf-v6ops-balanced-ipv6-security Individual Submission to v6ops posted/updated since IETF: Jul 30 draft-smith-v6ops-ce-dhcpv6-transparency Oct 4 draft-elkins-v6ops-ipv6-end-to-end-rt-needed Oct 4 draft-elkins-v6ops-ipv6-packet-sequence-needed Oct 4 draft-elkins-v6ops-ipv6-pdm-recommended-usage Oct 11 draft-byrne-v6ops-clatip Oct 18 draft-ma-v6ops-router-test Oct 21 draft-liu-bonica-v6ops-dhcpv6-slaac-problem Oct 21 draft-yang-v6ops-ipv6tran-select Oct 21 draft-sun-v6ops-openv6-address-pool-management Oct 21 draft-chen-v6ops-ipv6-roaming-analysis Oct 21 draft-moreiras-v6ops-rfc3849bis Oct 21 draft-petrescu-relay-route-pd-problem Oct 22 draft-rafiee-v6ops-iid-lifetime My guess at an IETF 88 agenda given current data: Aug 14 draft-ietf-v6ops-dc-ipv6 (get discussion = going) Aug 15 draft-ietf-v6ops-monitor-ds-ipv6 (get discussion = going) Sep 11 draft-ietf-v6ops-mobile-device-profile (discussion of = changes resulting from IETF LC) Oct 14 draft-ietf-v6ops-nat64-experience (do we have = rough consensus?) Oct 21 draft-ietf-v6ops-ula-usage-recommendations (get discussion = going) Oct 21 draft-ietf-v6ops-balanced-ipv6-security (get discussion = going) X BOX evolution? Some subset of the individual submissions In 4.5 hours, we probably have time for discussion of 9-13 drafts - my = preference being closer to 9 (30 minutes/draft) than 13 (20 = minutes/draft). That suggests that we could, if we chose, have the X Box = discussion, and/or have time for discussion of 2-7 of the individual = submissions. There was some on-list discussion of = draft-smith-v6ops-ce-dhcpv6-transparency in August, and I think I caught = a vote of confidence for draft-liu-bonica-v6ops-dhcpv6-slaac-problem. I = personally find draft-rafiee-v6ops-iid-lifetime interesting = architecturally. Wes George tells me that draft-yang-v6ops-ipv6tran-select has some = interaction with DHC and Sunset4. I'm looking for him and the DHC chairs = to tell me what to do with that - the draft may be appropriate for v6ops = discussion, and may be better in one of those other working groups. Frankly, with the draft cutoff so close to the date I need to post an = agenda, it is difficult for me to follow our usual practice of = monitoring mailing list discussion to vet WG interest in drafts. = Therefore, I'm going to pose this question directly. I presume that = every author wants to discuss their draft; some have asked for time. = Would folks please advise the chairs which among the individual = submissions and the X Box discussion they think merit discussion in = v6ops at IETF 88?=20 --Apple-Mail=_8810E651-34D8-4824-82EF-ACDB2F6F229B Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="signature.asc" Content-Type: application/pgp-signature; name="signature.asc" Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- Comment: GPGTools - http://gpgtools.org iD8DBQFSZ3A1bjEdbHIsm0MRAqawAJ9qwmogNvbiWFjvELVUMewXScFw+gCgxejV Ziu/xwOZguCHkIDIWzIFYzk= =RKFD -----END PGP SIGNATURE----- --Apple-Mail=_8810E651-34D8-4824-82EF-ACDB2F6F229B-- From joelja@bogus.com Tue Oct 22 23:55:35 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CFBC211E82FD for ; Tue, 22 Oct 2013 23:55:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.299 X-Spam-Level: X-Spam-Status: No, score=-102.299 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, J_CHICKENPOX_13=0.6, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yH+17o9gUrIw for ; Tue, 22 Oct 2013 23:55:35 -0700 (PDT) Received: from nagasaki.bogus.com (nagasaki.bogus.com [IPv6:2001:418:1::81]) by ietfa.amsl.com (Postfix) with ESMTP id C155311E82FF for ; Tue, 22 Oct 2013 23:55:31 -0700 (PDT) Received: from [192.168.1.11] (c-50-174-18-221.hsd1.ca.comcast.net [50.174.18.221]) (authenticated bits=0) by nagasaki.bogus.com (8.14.4/8.14.4) with ESMTP id r9N6tOtp006104 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Wed, 23 Oct 2013 06:55:25 GMT (envelope-from joelja@bogus.com) Content-Type: multipart/signed; boundary="Apple-Mail=_7247A0D3-4357-4099-B833-2AD5A84C7554"; protocol="application/pgp-signature"; micalg=pgp-sha1 Mime-Version: 1.0 (Mac OS X Mail 6.6 \(1510\)) From: joel jaeggli In-Reply-To: <8C48B86A895913448548E6D15DA7553BA74409@xmb-rcd-x09.cisco.com> Date: Tue, 22 Oct 2013 23:55:19 -0700 Message-Id: <3158034D-1264-44DF-B9CA-9384E3577FE7@bogus.com> References: <8C48B86A895913448548E6D15DA7553BA74409@xmb-rcd-x09.cisco.com> To: "V6ops Chairs (v6ops-chairs@tools.ietf.org)" , joel jaeggli X-Mailer: Apple Mail (2.1510) X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.7 (nagasaki.bogus.com [147.28.0.81]); Wed, 23 Oct 2013 06:55:26 +0000 (UTC) Cc: "v6ops@ietf.org WG" Subject: Re: [v6ops] Current state of v6ops drafts, updated X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 23 Oct 2013 06:55:35 -0000 --Apple-Mail=_7247A0D3-4357-4099-B833-2AD5A84C7554 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii On Oct 22, 2013, at 11:44 PM, "Fred Baker (fred)" = wrote: > I'm pulling an agenda together for IETF 88. My sources include the = internet drafts directory and http://datatracker.ietf.org/wg/v6ops/, = plus my mail store. I am interested in your viewpoints on this. The last = paragraph of this note contains a question I'd appreciate answers to, = private to v6ops-chairs@tools.ietf.org or to the list. >=20 > One relevant point - Chris Palmer of Microsoft wants to talk about the = evolution of the XBOX. When Dave Thaler asked me to speak about the = evolution (devolution?) of Teredo, I put him on the agenda on the = premise that this was an ongoing topic in the WG and of interest to the = operators. In the case of the XBOX, that's not so obvious to me. So, = please, if you're interested in such a talk, please advise, copying at = least John, Chris, and myself if not the working group. If it's a talk about a large scale deployment of ipv6 hosts IEPG = (sunday) might be interested. my first reaction is what's the punchline = for v6ops? >=20 > Draft status: >=20 > RFC Ed Queue: > Oct 30 draft-ietf-v6ops-6204bis > Nov 14 draft-ietf-v6ops-ra-guard-implementation > Mar 18 draft-ietf-v6ops-ipv6-multihoming-without-ipv6nat > Sep 15 draft-ietf-v6ops-rfc3316bis >=20 > Exiting WGLC; on its way to IESG: > Oct 7 draft-ietf-v6ops-64share > Oct 16 draft-ietf-v6ops-enterprise-incremental-ipv6 >=20 > Working Group Document updated since IETF: > Aug 14 draft-ietf-v6ops-dc-ipv6 > Aug 15 draft-ietf-v6ops-monitor-ds-ipv6 > Sep 11 draft-ietf-v6ops-mobile-device-profile > Oct 14 draft-ietf-v6ops-nat64-experience > Oct 21 draft-ietf-v6ops-ula-usage-recommendations > Oct 21 draft-ietf-v6ops-balanced-ipv6-security >=20 > Individual Submission to v6ops posted/updated since IETF: > Jul 30 draft-smith-v6ops-ce-dhcpv6-transparency > Oct 4 draft-elkins-v6ops-ipv6-end-to-end-rt-needed > Oct 4 draft-elkins-v6ops-ipv6-packet-sequence-needed > Oct 4 draft-elkins-v6ops-ipv6-pdm-recommended-usage > Oct 11 draft-byrne-v6ops-clatip > Oct 18 draft-ma-v6ops-router-test > Oct 21 draft-liu-bonica-v6ops-dhcpv6-slaac-problem > Oct 21 draft-yang-v6ops-ipv6tran-select > Oct 21 draft-sun-v6ops-openv6-address-pool-management > Oct 21 draft-chen-v6ops-ipv6-roaming-analysis > Oct 21 draft-moreiras-v6ops-rfc3849bis > Oct 21 draft-petrescu-relay-route-pd-problem > Oct 22 draft-rafiee-v6ops-iid-lifetime >=20 > My guess at an IETF 88 agenda given current data: > Aug 14 draft-ietf-v6ops-dc-ipv6 (get discussion = going) > Aug 15 draft-ietf-v6ops-monitor-ds-ipv6 (get discussion = going) > Sep 11 draft-ietf-v6ops-mobile-device-profile (discussion of = changes resulting from IETF LC) > Oct 14 draft-ietf-v6ops-nat64-experience (do we have = rough consensus?) > Oct 21 draft-ietf-v6ops-ula-usage-recommendations (get discussion = going) > Oct 21 draft-ietf-v6ops-balanced-ipv6-security (get discussion = going) > X BOX evolution? > Some subset of the individual submissions >=20 > In 4.5 hours, we probably have time for discussion of 9-13 drafts - my = preference being closer to 9 (30 minutes/draft) than 13 (20 = minutes/draft). That suggests that we could, if we chose, have the X Box = discussion, and/or have time for discussion of 2-7 of the individual = submissions. >=20 > There was some on-list discussion of = draft-smith-v6ops-ce-dhcpv6-transparency in August, and I think I caught = a vote of confidence for draft-liu-bonica-v6ops-dhcpv6-slaac-problem. I = personally find draft-rafiee-v6ops-iid-lifetime interesting = architecturally. >=20 > Wes George tells me that draft-yang-v6ops-ipv6tran-select has some = interaction with DHC and Sunset4. I'm looking for him and the DHC chairs = to tell me what to do with that - the draft may be appropriate for v6ops = discussion, and may be better in one of those other working groups. >=20 > Frankly, with the draft cutoff so close to the date I need to post an = agenda, it is difficult for me to follow our usual practice of = monitoring mailing list discussion to vet WG interest in drafts. = Therefore, I'm going to pose this question directly. I presume that = every author wants to discuss their draft; some have asked for time. = Would folks please advise the chairs which among the individual = submissions and the X Box discussion they think merit discussion in = v6ops at IETF 88?=20 --Apple-Mail=_7247A0D3-4357-4099-B833-2AD5A84C7554 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- Comment: GPGTools - http://gpgtools.org iEYEARECAAYFAlJnctcACgkQ8AA1q7Z/VrJ1GQCfaFlAOM3um5ts8y+6G6gzVNEH +5gAn0anxtl4Y1XktU/AU21sE8EH3i+F =cisQ -----END PGP SIGNATURE----- --Apple-Mail=_7247A0D3-4357-4099-B833-2AD5A84C7554-- From sajjad_akr@yahoo.com Wed Oct 23 02:01:47 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 44C1511E833D for ; Wed, 23 Oct 2013 02:01:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.002 X-Spam-Level: X-Spam-Status: No, score=0.002 tagged_above=-999 required=5 tests=[BAYES_50=0.001, 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 A1bpG8ndHPAs for ; Wed, 23 Oct 2013 02:01:40 -0700 (PDT) Received: from nm1-vm6.bullet.mail.ne1.yahoo.com (nm1-vm6.bullet.mail.ne1.yahoo.com [98.138.91.253]) by ietfa.amsl.com (Postfix) with ESMTP id 6E18911E8339 for ; Wed, 23 Oct 2013 02:01:23 -0700 (PDT) Received: from [98.138.101.129] by nm1.bullet.mail.ne1.yahoo.com with NNFMP; 23 Oct 2013 09:01:22 -0000 Received: from [98.138.89.162] by tm17.bullet.mail.ne1.yahoo.com with NNFMP; 23 Oct 2013 09:01:22 -0000 Received: from [127.0.0.1] by omp1018.mail.ne1.yahoo.com with NNFMP; 23 Oct 2013 09:01:22 -0000 X-Yahoo-Newman-Property: ymail-3 X-Yahoo-Newman-Id: 596749.41837.bm@omp1018.mail.ne1.yahoo.com Received: (qmail 43161 invoked by uid 60001); 23 Oct 2013 09:01:22 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s1024; t=1382518882; bh=95a/k65wEUgn2DiLySVCATT6A2xcecaBeZ7NAvpXo+o=; h=X-YMail-OSG:Received:X-Rocket-MIMEInfo:X-Mailer:Message-ID:Date:From:Reply-To:Subject:To:MIME-Version:Content-Type; b=O4pi2g9nFAW6zds9cK8hilPb+OshCJhzH4jMeh+v4sDFD6Fo++uHix69CLErjZh+lm9thivpJ89KgK0v6O8UbAwvDUAmG5EZU59I3E4XmVPa7oEYRR7R053HRPI0uKDTvLreDBxjl6CaKG5GD0h12pAvqTNTHEwNnBP+rmWyug0= DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=X-YMail-OSG:Received:X-Rocket-MIMEInfo:X-Mailer:Message-ID:Date:From:Reply-To:Subject:To:MIME-Version:Content-Type; b=enwq6NagLaMmU9PblLN6cIWesqD5cb/h/VgNGMLo4B0FHdlE3MPVB0wdPrBfAIBz9UenyqlLrBPF7EAjYj9wgyibZx+g6CdXxwEim4yBfd2t3glKCKZQl0vM9OsoWduYM9KmdMJeOHOnv34AtLLoc84KNj6shS4AcnrDjbw83OQ=; X-YMail-OSG: Wr40I6wVM1kY9LGNu0uX2qrDOeV3STn43rpUtQ_Ydvh.6iZ 0VfD2AY2xlxPVjtfNAjgepM9dpEhJiJ526Gur0sph9E38rEAPBoCv6AWZSyG _RDM3xY1E3BZ8YBBk_pwHWysxdVweDqWm8EfnhHG6R0sMYlNFJ4ggsS4.66T yJxEcqUFvTFeCTuyI17qnnk0FkUcvtsoXYAbyauOF8.obAGNMH9B.zWiY00X nXic6OXxwPjJ4IkcCLbAavABcqH2IOsYXBC.Ai77J6_ikWVQho4oEAg_mzck Qs8NHNXsBoOzCJA.9Hdvg1NxbzDGPeJEIi1KSOn7vi8GVskKsJfkNdoCUmMq PTuePx7bqKCz5BSKHmf6HOHtYfQXhc.hW.wBByCQvy4fdaZhd2eQDWRaZREz sDj_IeyhgV.3lrAKo3m5NCglvdjuEtmxwDGRUVDirHsytBB4fkzIbFdYZYYb k5r3X97FI_rl7xUo.4nf8D1NRz_HGl5qUug75l1AwaImkljj_aSH2xUT1upe dLf0pmhhXNi4XF7k6MFGmEPAoMPLnj_Q7i_n3koi02QWMMearOl_Nlj2wC26 7oHdbqA7.UWdf5WSXEUyl Received: from [203.99.52.164] by web121504.mail.ne1.yahoo.com via HTTP; Wed, 23 Oct 2013 02:01:21 PDT X-Rocket-MIMEInfo: 002.001, CgoKRGVhciBmZWxsb3dzwqAKCgpXZSBuZWVkIHRvIGltcGxlbWVudCBtdWx0aWNhc3QgZm9ywqBoeWJyaWQgbmV0d29yayAoSVB2Ni1JUHY0KSBpbiBvdXIgdGVzdGJlZC4gTm8gYXV0b21hdGljIHR1bm5lbGluZyBtZWNoYW5pc20gaXMgc3VwcG9ydGluZyBtdWx0aWNhc3QuwqAKY2FuIEdSRSB0dW5uZWwgc3VwcG9ydCBtdWx0aWNhc3Qgc3RyZWFtaW5nIGluIGEgaHlicmlkIG5ldHdvcmsgKElQdjYtSVB2NCk_wqAKClJlZ2FyZHMKU2FqamFkATABAQEB X-Mailer: YahooMailWebService/0.8.160.587 Message-ID: <1382518881.42811.YahooMailNeo@web121504.mail.ne1.yahoo.com> Date: Wed, 23 Oct 2013 02:01:21 -0700 (PDT) From: sajjad akbar To: "v6ops@ietf.org" MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="1050781934-252994362-1382518881=:42811" Subject: [v6ops] Possibility of Multicast support through GRE tunnel? X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: sajjad akbar List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 23 Oct 2013 09:01:47 -0000 --1050781934-252994362-1382518881=:42811 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable =0A=0A=0ADear fellows=A0=0A=0A=0AWe need to implement multicast for=A0hybri= d network (IPv6-IPv4) in our testbed. No automatic tunneling mechanism is s= upporting multicast.=A0=0Acan GRE tunnel support multicast streaming in a h= ybrid network (IPv6-IPv4)?=A0=0A=0ARegards=0ASajjad --1050781934-252994362-1382518881=:42811 Content-Type: text/html; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable


Dear fellows 


We need to implement multicast for hybrid network (IPv6-IPv4) in our testbed. No automat= ic tunneling mechanism is supporting multicast. 
can GRE tunnel suppor= t multicast streaming in a hybrid network (IPv6-IPv4)? 

Regards
Sajjad
--1050781934-252994362-1382518881=:42811-- From markzzzsmith@yahoo.com.au Wed Oct 23 02:12:06 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9835821E80AE for ; Wed, 23 Oct 2013 02:12:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.466 X-Spam-Level: X-Spam-Status: No, score=-1.466 tagged_above=-999 required=5 tests=[AWL=0.633, BAYES_00=-2.599, FROM_LOCAL_NOVOWEL=0.5] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TCkVkgRELyLa for ; Wed, 23 Oct 2013 02:12:01 -0700 (PDT) Received: from nm30-vm0.bullet.mail.bf1.yahoo.com (nm30-vm0.bullet.mail.bf1.yahoo.com [98.139.213.126]) by ietfa.amsl.com (Postfix) with ESMTP id 160A511E8341 for ; Wed, 23 Oct 2013 02:11:50 -0700 (PDT) Received: from [98.139.212.150] by nm30.bullet.mail.bf1.yahoo.com with NNFMP; 23 Oct 2013 09:11:50 -0000 Received: from [98.139.212.193] by tm7.bullet.mail.bf1.yahoo.com with NNFMP; 23 Oct 2013 09:11:50 -0000 Received: from [127.0.0.1] by omp1002.mail.bf1.yahoo.com with NNFMP; 23 Oct 2013 09:11:50 -0000 X-Yahoo-Newman-Property: ymail-3 X-Yahoo-Newman-Id: 586058.22437.bm@omp1002.mail.bf1.yahoo.com Received: (qmail 39671 invoked by uid 60001); 23 Oct 2013 09:11:50 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com.au; s=s1024; t=1382519510; bh=7+vP2QyR7UvVVm82+WKyk0YvmjT3OT/FtVIzIAruRIA=; h=X-YMail-OSG:Received:X-Rocket-MIMEInfo:X-Mailer:References:Message-ID:Date:From:Reply-To:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type:Content-Transfer-Encoding; b=53QL4bho/7HHzx67HMRdDuLutFyW7lMzd1+ZN1DVUWHLvi6ksjoGnifTIfFGGNu/gHeyK3DaNRNZ5X1P6ZMzuzv7q0vmJIEJhdxd1EHQm05yCfwxzV85K8vA7SSKXmXr5XGtYeThDzFugtZyCaISCBXnvznE3/25XgtaZ3ffL88= DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com.au; h=X-YMail-OSG:Received:X-Rocket-MIMEInfo:X-Mailer:References:Message-ID:Date:From:Reply-To:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type:Content-Transfer-Encoding; b=bFr/Qa/Lz280KCYVNxOhoXauAWwq6Qn/gbL1gSZjXt6T8hXs67H8MNLOqI9I4M/7+bWj+N91BbUchaI+mXag/KASyxTI0Mbs4GmlKZZMFUZOQVCN5G6T1jIREB+TlHu/SirYUR/g21yIyagtjH4/z4UNdRuCMHCoj4ZRCa7VG7I=; X-YMail-OSG: YnSPwTEVM1my8uKzVxFmztNbK991FajHsZ_wgHOVMOifoKc IQDqrUzFnA65aJ5cOaF8EbyccJcD1toZwnAJLSIeJvAp5AR8bUhwbG00Aie4 hj.uiwH4rY6AV_IH728ktVyQ.Aey.9.y8tdsYpi80XvYT.OU_RItnZ20rzfa PwJ9YXRIXn1uiHwivxtp4SaqxgW54XhZ7XBKUtnyLH.uqT0CGzIJ6Fqv.bn0 CBWSfJdACZ26ABXVZHqgj8YGdLrQQ3r6Iy_vdQI9ETJ9oVPy3ygM6muvHkrx rLF9GVwrIvdnzxPhEA4Qbs1Yih8nDL.cJAkjNSvbpJDkhDcelboW7PXK3n1N pzXXiHBQ_SRsiu8BkbX_.J9WVXR5BEFmDRzEu0HS5NBPqQMoYweqIXizpb2M B48wVje4JohWEgborAggSXRK2YBzK8hINDDu4tNWcEzQgK5ejXilkELDuv_E GGuo2hH1BW6lZh49sE0OrXi8fkafajBtUkfiHtLbj9G.J.UYNDgR5rkP6r5P 5PYjXTUqt_ge0Y4o6HymgaGvgU2w7Uzhi5IlUdB_f7lG5RKNLHS4vmuMspbI ZTSqRATYWT4nBLq8H6xaFMw-- Received: from [150.101.221.237] by web142502.mail.bf1.yahoo.com via HTTP; Wed, 23 Oct 2013 02:11:49 PDT X-Rocket-MIMEInfo: 002.001, SGksCgoKLS0tLS0gT3JpZ2luYWwgTWVzc2FnZSAtLS0tLQo.IEZyb206IE1pa2FlbCBBYnJhaGFtc3NvbiA8c3dtaWtlQHN3bS5wcC5zZT4KPiBUbzogTWFyayBaWlogU21pdGggPG1hcmt6enpzbWl0aEB5YWhvby5jb20uYXU.Cj4gQ2M6IExpdWJpbmcgKExlbykgPGxlby5saXViaW5nQGh1YXdlaS5jb20.OyAidjZvcHNAaWV0Zi5vcmciIDx2Nm9wc0BpZXRmLm9yZz47ICJkcmFmdC1saXUtYm9uaWNhLXY2b3BzLWRoY3B2Ni1zbGFhYy1wcm9ibGVtQHRvb2xzLmlldGYub3JnIiA8ZHJhZnQtbGl1LWJvbmljYS0BMAEBAQE- X-Mailer: YahooMailWebService/0.8.160.587 References: <201310211245.r9LCj0B29668@ftpeng-update.cisco.com> <8AE0F17B87264D4CAC7DE0AA6C406F453D7CC14B@nkgeml506-mbx.china.huawei.com> <1382469405.56346.YahooMailNeo@web142504.mail.bf1.yahoo.com> Message-ID: <1382519509.39565.YahooMailNeo@web142502.mail.bf1.yahoo.com> Date: Wed, 23 Oct 2013 02:11:49 -0700 (PDT) From: Mark ZZZ Smith To: Mikael Abrahamsson In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Cc: "v6ops@ietf.org" , "draft-liu-bonica-v6ops-dhcpv6-slaac-problem@tools.ietf.org" Subject: Re: [v6ops] DHCPv6/SLAAC Make Hosts Confusing-//RE: new draft: draft-liu-bonica-v6ops-dhcpv6-slaac-problem X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: Mark ZZZ Smith List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 23 Oct 2013 09:12:06 -0000 Hi,=0A=0A=0A----- Original Message -----=0A> From: Mikael Abrahamsson =0A> To: Mark ZZZ Smith =0A> Cc: Li= ubing (Leo) ; "v6ops@ietf.org" ; "d= raft-liu-bonica-v6ops-dhcpv6-slaac-problem@tools.ietf.org" =0A> Sent: Wednesday, 23 Octobe= r 2013 2:40 PM=0A> Subject: Re: [v6ops] DHCPv6/SLAAC Make Hosts Confusing-/= /RE: new draft: draft-liu-bonica-v6ops-dhcpv6-slaac-problem=0A> =0A> On Tue= , 22 Oct 2013, Mark ZZZ Smith wrote:=0A> =0A>>=A0 Is this saying that the p= refix length of the address on host is /128?=0A> =0A> A single address is a= lways a /128. This /128 can be part of an on-link =0A> other network, or it= isn't.=0A>=A0=0A=0AMy question was more specificaly about you using "/128"= , rather than "an address" or "a single address", because I wondered if the= DHCPv6 server supplies a /128 prefix length and the host configures a /128= prefix length on the address.=0A=0AAs you say below, address prefix length= doesn't indicate on-link or off-link presence. So I'd expect a DHCPv6 serv= er to hand out single IPv6 addresses with a /64 prefix length, as I think t= hat would be more consistent and more expected when the subnet's prefix len= gth is /64.=0A=0AFor somebody with a IPv4 experience, who wasn't aware an I= Pv6 prefix length doesn't indicate on-link presence, I think the use of a /= 128 prefix length in this scenario would imply that prefix length does indi= cate on-link presence. Somewhat pedantic perhaps, however I think anything = that may give false indications of IPv6's behaviour, when it is different t= o IPv4's, is better to avoid.=0A=0A=0ARegards,=0AMark.=0A=0A>>=A0 If that i= s the case, as the prefix length in doesn't indicate on-link =0A> or =0A>>= =A0 off-link status (as RA PIOs do), is there any specific reason for the = =0A>>=A0 prefix length the DHCPv6 server hands out to be /128 instead of th= e =0A>>=A0 subnet's prefix length of /64?=A0=0A> =0A> The DHCPv6 server alw= ays hands out /128. This /128 can be within a subnet =0A> advertised in RA,= or it can be outside of it. The host doesn't care. When =0A> a subnet is b= eing advertised in RA you get a network route pointing to the =0A> interfac= e without an IPv6 address as next-hop.=0A> =0A> So it's perfectly achievabl= e today (and it works) to have the following:=0A> =0A> Host gets 2001:db8:f= ff::1/128 from dhcp=0A> host gets on-link 2001:db8:1::/64 from RA and creat= es a route towards the =0A> interface for this, but doesn't do SLAAC becaus= e A=3D0.=0A> Host gets default route from router and installs it.=0A> =0A> = Now, the *router* needs to understand that 2001:db8:fff::1/128 is on-link, = =0A> but no other hosts on the network does not.=0A> =0A> So what networks = are being announced in RA is completely decoupled from =0A> addresses hande= d out by DHCPv6 IA_NA. It's perfectly valid to hand out a =0A> /128 and the= n have no on-link prefixes at all, or have some with A=3D0.=0A> =0A> =0A> -= - =0A> Mikael Abrahamsson=A0 =A0 email: swmike@swm.pp.se=0A> From swmike@swm.pp.se Wed Oct 23 02:21:12 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E07D011E8182 for ; Wed, 23 Oct 2013 02:21:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.684 X-Spam-Level: X-Spam-Status: No, score=-5.684 tagged_above=-999 required=5 tests=[AWL=0.565, BAYES_00=-2.599, HELO_EQ_SE=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 y7ti4rxDHsvf for ; Wed, 23 Oct 2013 02:21:07 -0700 (PDT) Received: from uplift.swm.pp.se (swm.pp.se [212.247.200.143]) by ietfa.amsl.com (Postfix) with ESMTP id 9421821F968B for ; Wed, 23 Oct 2013 02:21:07 -0700 (PDT) Received: by uplift.swm.pp.se (Postfix, from userid 501) id 1D2299C; Wed, 23 Oct 2013 11:21:05 +0200 (CEST) Received: from localhost (localhost [127.0.0.1]) by uplift.swm.pp.se (Postfix) with ESMTP id 15F709A; Wed, 23 Oct 2013 11:21:05 +0200 (CEST) Date: Wed, 23 Oct 2013 11:21:05 +0200 (CEST) From: Mikael Abrahamsson To: Mark ZZZ Smith In-Reply-To: <1382519509.39565.YahooMailNeo@web142502.mail.bf1.yahoo.com> Message-ID: References: <201310211245.r9LCj0B29668@ftpeng-update.cisco.com> <8AE0F17B87264D4CAC7DE0AA6C406F453D7CC14B@nkgeml506-mbx.china.huawei.com> <1382469405.56346.YahooMailNeo@web142504.mail.bf1.yahoo.com> <1382519509.39565.YahooMailNeo@web142502.mail.bf1.yahoo.com> User-Agent: Alpine 2.02 (DEB 1266 2009-07-14) Organization: People's Front Against WWW MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: "v6ops@ietf.org" , "draft-liu-bonica-v6ops-dhcpv6-slaac-problem@tools.ietf.org" Subject: Re: [v6ops] DHCPv6/SLAAC Make Hosts Confusing-//RE: new draft: draft-liu-bonica-v6ops-dhcpv6-slaac-problem X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 23 Oct 2013 09:21:13 -0000 On Wed, 23 Oct 2013, Mark ZZZ Smith wrote: > My question was more specificaly about you using "/128", rather than "an > address" or "a single address", because I wondered if the DHCPv6 server > supplies a /128 prefix length and the host configures a /128 prefix > length on the address. I am not aware of DHCP being able to hand out IA_NA ranges to hosts. I only thought it could hand out single IA_NA. > As you say below, address prefix length doesn't indicate on-link or > off-link presence. So I'd expect a DHCPv6 server to hand out single IPv6 > addresses with a /64 prefix length, as I think that would be more > consistent and more expected when the subnet's prefix length is /64. You're missing the point. There doesn't have to be a /64. DHCPv6 hands out IA_NA which is a single address, which might or might not be covered by an on-link prefix. > For somebody with a IPv4 experience, who wasn't aware an IPv6 prefix > length doesn't indicate on-link presence, I think the use of a /128 > prefix length in this scenario would imply that prefix length does > indicate on-link presence. Somewhat pedantic perhaps, however I think > anything that may give false indications of IPv6's behaviour, when it is > different to IPv4's, is better to avoid. The /128 is on-link (it's bound to that interface), just that most likely nobody else knows about it apart from the router (unless it's covered by a prefix being announced as on-link). -- Mikael Abrahamsson email: swmike@swm.pp.se From otroan@cisco.com Wed Oct 23 02:21:28 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6FF5311E834E for ; Wed, 23 Oct 2013 02:21:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.999 X-Spam-Level: X-Spam-Status: No, score=-9.999 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_13=0.6, 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 JksejiBPPIgL for ; Wed, 23 Oct 2013 02:21:23 -0700 (PDT) Received: from rcdn-iport-2.cisco.com (rcdn-iport-2.cisco.com [173.37.86.73]) by ietfa.amsl.com (Postfix) with ESMTP id 6ACCC21F968B for ; Wed, 23 Oct 2013 02:21:23 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=3559; q=dns/txt; s=iport; t=1382520083; x=1383729683; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=GxP5hLWeBB8QXbzLMtjRchRnqkXhA9/PtlWpu+EWrZ4=; b=aDEbm0bRrzjNnFaLT51H8ub9YIqClhnqb2iIJS/9T0YJ9G4RZtGBD8BS fIybgiynOLEnae5J0PRe5yIfXah73WpOgzQBUhZOyeOxph9e6qGAw0YKs 4qsh3vHORE7+i/ma6OgcVXeJP28vz8IzUundJHyblCtuPX372bEc0rkLi A=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgQFAJ2UZ1KtJXG8/2dsb2JhbABZgmYhOL8ggScWdIIlAQEBAwEBAQE3NAsFBwQCAQgRBAEBAR4FCycLHQgBAQQOBYd0AwkGAQy6TwSMYIElgRYoCwcGgxmBCwOWJIFljFCFN4FmgT6BcQ X-IronPort-AV: E=Sophos;i="4.93,553,1378857600"; d="scan'208";a="275498182" Received: from rcdn-core2-1.cisco.com ([173.37.113.188]) by rcdn-iport-2.cisco.com with ESMTP; 23 Oct 2013 09:21:22 +0000 Received: from xhc-aln-x08.cisco.com (xhc-aln-x08.cisco.com [173.36.12.82]) by rcdn-core2-1.cisco.com (8.14.5/8.14.5) with ESMTP id r9N9LMJp002569 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 23 Oct 2013 09:21:22 GMT Received: from xmb-aln-x13.cisco.com ([fe80::5404:b599:9f57:834b]) by xhc-aln-x08.cisco.com ([173.36.12.82]) with mapi id 14.02.0318.004; Wed, 23 Oct 2013 04:21:22 -0500 From: "Ole Troan (otroan)" To: Mark ZZZ Smith Thread-Topic: [v6ops] DHCPv6/SLAAC Make Hosts Confusing-//RE: new draft: draft-liu-bonica-v6ops-dhcpv6-slaac-problem Thread-Index: Ac7P0TyVueJWVMLhSL2iAHeIFInvMA== Date: Wed, 23 Oct 2013 09:21:21 +0000 Message-ID: <55F2A998-0417-4C19-B248-AA2A80EBF29C@cisco.com> References: <201310211245.r9LCj0B29668@ftpeng-update.cisco.com> <8AE0F17B87264D4CAC7DE0AA6C406F453D7CC14B@nkgeml506-mbx.china.huawei.com> <1382469405.56346.YahooMailNeo@web142504.mail.bf1.yahoo.com> <1382519509.39565.YahooMailNeo@web142502.mail.bf1.yahoo.com> In-Reply-To: <1382519509.39565.YahooMailNeo@web142502.mail.bf1.yahoo.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: Content-Type: text/plain; charset="us-ascii" Content-ID: <17F3D1AA1D1A2543B9B24C67BB839E8E@emea.cisco.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "v6ops@ietf.org" , "draft-liu-bonica-v6ops-dhcpv6-slaac-problem@tools.ietf.org" Subject: Re: [v6ops] DHCPv6/SLAAC Make Hosts Confusing-//RE: new draft: draft-liu-bonica-v6ops-dhcpv6-slaac-problem X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 23 Oct 2013 09:21:28 -0000 A single address does not have a mask.=20 DHCP gives out addresses, not prefixes that can be used for onlink determin= ation.=20 Cheers, Ole > On 23 Oct 2013, at 11:11, Mark ZZZ Smith wrot= e: >=20 > Hi, >=20 >=20 > ----- Original Message ----- >> From: Mikael Abrahamsson >> To: Mark ZZZ Smith >> Cc: Liubing (Leo) ; "v6ops@ietf.org" ; "draft-liu-bonica-v6ops-dhcpv6-slaac-problem@tools.ietf.org" >> Sent: Wednesday, 23 October 2013 2:40 PM >> Subject: Re: [v6ops] DHCPv6/SLAAC Make Hosts Confusing-//RE: new draft: = draft-liu-bonica-v6ops-dhcpv6-slaac-problem >>=20 >>> On Tue, 22 Oct 2013, Mark ZZZ Smith wrote: >>>=20 >>> Is this saying that the prefix length of the address on host is /128? >>=20 >> A single address is always a /128. This /128 can be part of an on-link=20 >> other network, or it isn't. >=20 > My question was more specificaly about you using "/128", rather than "an = address" or "a single address", because I wondered if the DHCPv6 server sup= plies a /128 prefix length and the host configures a /128 prefix length on = the address. >=20 > As you say below, address prefix length doesn't indicate on-link or off-l= ink presence. So I'd expect a DHCPv6 server to hand out single IPv6 address= es with a /64 prefix length, as I think that would be more consistent and m= ore expected when the subnet's prefix length is /64. >=20 > For somebody with a IPv4 experience, who wasn't aware an IPv6 prefix leng= th doesn't indicate on-link presence, I think the use of a /128 prefix leng= th in this scenario would imply that prefix length does indicate on-link pr= esence. Somewhat pedantic perhaps, however I think anything that may give f= alse indications of IPv6's behaviour, when it is different to IPv4's, is be= tter to avoid. >=20 >=20 > Regards, > Mark. >=20 >>> If that is the case, as the prefix length in doesn't indicate on-link >> or=20 >>> off-link status (as RA PIOs do), is there any specific reason for the= =20 >>> prefix length the DHCPv6 server hands out to be /128 instead of the=20 >>> subnet's prefix length of /64?=20 >>=20 >> The DHCPv6 server always hands out /128. This /128 can be within a subne= t=20 >> advertised in RA, or it can be outside of it. The host doesn't care. Whe= n=20 >> a subnet is being advertised in RA you get a network route pointing to t= he=20 >> interface without an IPv6 address as next-hop. >>=20 >> So it's perfectly achievable today (and it works) to have the following: >>=20 >> Host gets 2001:db8:fff::1/128 from dhcp >> host gets on-link 2001:db8:1::/64 from RA and creates a route towards th= e=20 >> interface for this, but doesn't do SLAAC because A=3D0. >> Host gets default route from router and installs it. >>=20 >> Now, the *router* needs to understand that 2001:db8:fff::1/128 is on-lin= k,=20 >> but no other hosts on the network does not. >>=20 >> So what networks are being announced in RA is completely decoupled from= =20 >> addresses handed out by DHCPv6 IA_NA. It's perfectly valid to hand out a= =20 >> /128 and then have no on-link prefixes at all, or have some with A=3D0. >>=20 >>=20 >> --=20 >> Mikael Abrahamsson email: swmike@swm.pp.se > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops From jeroen@massar.ch Wed Oct 23 02:24:41 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C004011E8131 for ; Wed, 23 Oct 2013 02:24:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5LQZN+9BPYTY for ; Wed, 23 Oct 2013 02:24:36 -0700 (PDT) Received: from icaras.de.unfix.org (icaras.de.unfix.org [78.47.209.234]) by ietfa.amsl.com (Postfix) with ESMTP id EA37811E8340 for ; Wed, 23 Oct 2013 02:24:35 -0700 (PDT) Received: from kami.ch.unfix.org (84-73-144-213.dclient.hispeed.ch [84.73.144.213]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: jeroen) by icaras.de.unfix.org (Postfix) with ESMTPSA id 84667801C2A2; Wed, 23 Oct 2013 11:24:27 +0200 (CEST) Message-ID: <526795C1.7060803@massar.ch> Date: Wed, 23 Oct 2013 11:24:17 +0200 From: Jeroen Massar Organization: Massar MIME-Version: 1.0 To: sajjad akbar , "v6ops@ietf.org" References: <1382518881.42811.YahooMailNeo@web121504.mail.ne1.yahoo.com> In-Reply-To: <1382518881.42811.YahooMailNeo@web121504.mail.ne1.yahoo.com> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: Re: [v6ops] Possibility of Multicast support through GRE tunnel? X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 23 Oct 2013 09:24:41 -0000 On 2013-10-23 11:01, sajjad akbar wrote: > > > Dear fellows > > > We need to implement multicast for hybrid network (IPv6-IPv4) in our > testbed. No automatic tunneling mechanism is supporting multicast. > can GRE tunnel support multicast streaming in a hybrid network (IPv6-IPv4)? As per: http://www.sixxs.net/faq/connectivity/?faq=comparison Yes, GRE can do it, but as listed there many others do too. The trick is that at either end of the tunnel you will have to run a MLD proxy or a real multicast router for things to work. (ecmh amongst many others can achieve this) You state you have a 'hybrid network', why is that network not native? Greets, Jeroen From nick@inex.ie Wed Oct 23 03:07:06 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A263011E8372 for ; Wed, 23 Oct 2013 03:07:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id i-ECM1aZp8Xk for ; Wed, 23 Oct 2013 03:07:05 -0700 (PDT) Received: from mail.netability.ie (mail.netability.ie [IPv6:2a03:8900:0:100::5]) by ietfa.amsl.com (Postfix) with ESMTP id 103BC11E8343 for ; Wed, 23 Oct 2013 03:06:53 -0700 (PDT) X-Envelope-To: v6ops@ietf.org Received: from vpn-250.int.inex.ie (vpn-250.int.inex.ie [193.242.111.250]) (authenticated bits=0) by mail.netability.ie (8.14.7/8.14.5) with ESMTP id r9NA6Omn016132 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO); Wed, 23 Oct 2013 11:06:27 +0100 (IST) (envelope-from nick@inex.ie) Message-ID: <52679F9F.7040403@inex.ie> Date: Wed, 23 Oct 2013 18:06:23 +0800 From: Nick Hilliard User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:24.0) Gecko/20100101 Thunderbird/24.0.1 MIME-Version: 1.0 To: "Ole Troan (otroan)" , Mark ZZZ Smith References: <201310211245.r9LCj0B29668@ftpeng-update.cisco.com> <8AE0F17B87264D4CAC7DE0AA6C406F453D7CC14B@nkgeml506-mbx.china.huawei.com> <1382469405.56346.YahooMailNeo@web142504.mail.bf1.yahoo.com> <1382519509.39565.YahooMailNeo@web142502.mail.bf1.yahoo.com> <55F2A998-0417-4C19-B248-AA2A80EBF29C@cisco.com> In-Reply-To: <55F2A998-0417-4C19-B248-AA2A80EBF29C@cisco.com> X-Enigmail-Version: 1.6 X-Company-Info-1: Internet Neutral Exchange Association Limited. Registered in Ireland No. 253804 X-Company-Info-2: Registered Offices: 1-2, Marino Mart, Fairview, Dublin 3 X-Company-Info-3: Internet Neutral Exchange Association Limited is limited by guarantee X-Company-Info-4: Offices: 4027 Kingswood Road, Citywest, Dublin 24. Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: "v6ops@ietf.org" , "draft-liu-bonica-v6ops-dhcpv6-slaac-problem@tools.ietf.org" Subject: Re: [v6ops] DHCPv6/SLAAC Make Hosts Confusing-//RE: new draft: draft-liu-bonica-v6ops-dhcpv6-slaac-problem X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 23 Oct 2013 10:07:06 -0000 On 23/10/2013 17:21, Ole Troan (otroan) wrote: > DHCP gives out addresses, not prefixes that can be used for onlink determination. and if dhcpv6 gave out netmasks and default gateways, we could finally ditch RA. I look forward to the day when I can finally expunge RA from my networks. Nick From Carl.Wuyts@technicolor.com Wed Oct 23 03:17:56 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C2C6E11E831B for ; Wed, 23 Oct 2013 03:17:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.999 X-Spam-Level: X-Spam-Status: No, score=-5.999 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_13=0.6, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1vxtSy-jhD64 for ; Wed, 23 Oct 2013 03:17:51 -0700 (PDT) Received: from na3sys009aog110.obsmtp.com (na3sys009aog110.obsmtp.com [74.125.149.203]) by ietfa.amsl.com (Postfix) with ESMTP id 5092A11E830F for ; Wed, 23 Oct 2013 03:17:38 -0700 (PDT) Received: from MOPESEDGE01.eu.thmulti.com ([129.35.174.203]) (using TLSv1) by na3sys009aob110.postini.com ([74.125.148.12]) with SMTP ID DSNKUmeiQnRKC3u/gqzOUg1VjWNe2YYXgrUL@postini.com; Wed, 23 Oct 2013 03:17:50 PDT Received: from MOPESMAILHC01.eu.thmulti.com (141.11.100.25) by mail3.technicolor.com (141.11.253.22) with Microsoft SMTP Server (TLS) id 8.3.298.1; Wed, 23 Oct 2013 12:12:34 +0200 Received: from MOPESMBX01.eu.thmulti.com ([169.254.1.42]) by MOPESMAILHC01.eu.thmulti.com ([141.11.100.25]) with mapi; Wed, 23 Oct 2013 12:12:38 +0200 From: Wuyts Carl To: Nick Hilliard , "Ole Troan (otroan)" , Mark ZZZ Smith Date: Wed, 23 Oct 2013 12:12:36 +0200 Thread-Topic: [v6ops] DHCPv6/SLAAC Make Hosts Confusing-//RE: new draft: draft-liu-bonica-v6ops-dhcpv6-slaac-problem Thread-Index: Ac7P17Xu9JteDAClS7iy/LLSJYKH8wAABjJw Message-ID: <3135C2851EB6764BACEF35D8B495596806F97635FF@MOPESMBX01.eu.thmulti.com> References: <201310211245.r9LCj0B29668@ftpeng-update.cisco.com> <8AE0F17B87264D4CAC7DE0AA6C406F453D7CC14B@nkgeml506-mbx.china.huawei.com> <1382469405.56346.YahooMailNeo@web142504.mail.bf1.yahoo.com> <1382519509.39565.YahooMailNeo@web142502.mail.bf1.yahoo.com> <55F2A998-0417-4C19-B248-AA2A80EBF29C@cisco.com> <52679F9F.7040403@inex.ie> In-Reply-To: <52679F9F.7040403@inex.ie> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "v6ops@ietf.org" , "draft-liu-bonica-v6ops-dhcpv6-slaac-problem@tools.ietf.org" Subject: Re: [v6ops] DHCPv6/SLAAC Make Hosts Confusing-//RE: new draft: draft-liu-bonica-v6ops-dhcpv6-slaac-problem X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 23 Oct 2013 10:17:56 -0000 To be honest, I haven't kept up with the full exchange on this topic, so pl= ease disregard my question if it is not relative to this discussion. I read below that, if netmask and def gw would be added on handing out dhcp= v6, "I can finally get rid of RA messages". But what with hosts NOT supporting dhcpv6 client in this case ? I might be= fully wrong, but I cannot imagine it can be 100% enforced upon each host v= endor to include dhcpv6 client support? Regs Carl -----Original Message----- From: v6ops-bounces@ietf.org [mailto:v6ops-bounces@ietf.org] On Behalf Of N= ick Hilliard Sent: woensdag 23 oktober 2013 12:06 To: Ole Troan (otroan); Mark ZZZ Smith Cc: v6ops@ietf.org; draft-liu-bonica-v6ops-dhcpv6-slaac-problem@tools.ietf.= org Subject: Re: [v6ops] DHCPv6/SLAAC Make Hosts Confusing-//RE: new draft: dra= ft-liu-bonica-v6ops-dhcpv6-slaac-problem On 23/10/2013 17:21, Ole Troan (otroan) wrote: > DHCP gives out addresses, not prefixes that can be used for onlink determ= ination.=20 and if dhcpv6 gave out netmasks and default gateways, we could finally ditc= h RA. I look forward to the day when I can finally expunge RA from my netw= orks. Nick _______________________________________________ v6ops mailing list v6ops@ietf.org https://www.ietf.org/mailman/listinfo/v6ops From sthaug@nethelp.no Wed Oct 23 03:20:17 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B18BC11E8328 for ; Wed, 23 Oct 2013 03:20:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id q724aliemCfv for ; Wed, 23 Oct 2013 03:20:12 -0700 (PDT) Received: from bizet.nethelp.no (bizet.nethelp.no [195.1.209.33]) by ietfa.amsl.com (Postfix) with SMTP id F3DC111E831B for ; Wed, 23 Oct 2013 03:20:10 -0700 (PDT) Received: (qmail 48944 invoked from network); 23 Oct 2013 10:20:09 -0000 Received: from bizet.nethelp.no (HELO localhost) (195.1.209.33) by bizet.nethelp.no with SMTP; 23 Oct 2013 10:20:09 -0000 Date: Wed, 23 Oct 2013 12:20:08 +0200 (CEST) Message-Id: <20131023.122008.74708818.sthaug@nethelp.no> To: nick@inex.ie From: sthaug@nethelp.no In-Reply-To: <52679F9F.7040403@inex.ie> References: <1382519509.39565.YahooMailNeo@web142502.mail.bf1.yahoo.com> <55F2A998-0417-4C19-B248-AA2A80EBF29C@cisco.com> <52679F9F.7040403@inex.ie> X-Mailer: Mew version 3.3 on Emacs 21.3 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Cc: otroan@cisco.com, draft-liu-bonica-v6ops-dhcpv6-slaac-problem@tools.ietf.org, v6ops@ietf.org Subject: Re: [v6ops] DHCPv6/SLAAC Make Hosts Confusing-//RE: new draft: draft-liu-bonica-v6ops-dhcpv6-slaac-problem X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 23 Oct 2013 10:20:17 -0000 > > DHCP gives out addresses, not prefixes that can be used for onlink determination. > > and if dhcpv6 gave out netmasks and default gateways, we could finally > ditch RA. I look forward to the day when I can finally expunge RA from my > networks. Amen. But it doesn't look like this is going to happen any time soon... Steinar Haug, AS 2116 From sthaug@nethelp.no Wed Oct 23 03:25:39 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0DDA211E817A for ; Wed, 23 Oct 2013 03:25:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Jc+oAntySLQr for ; Wed, 23 Oct 2013 03:25:34 -0700 (PDT) Received: from bizet.nethelp.no (bizet.nethelp.no [195.1.209.33]) by ietfa.amsl.com (Postfix) with SMTP id 27C8E11E831B for ; Wed, 23 Oct 2013 03:25:29 -0700 (PDT) Received: (qmail 49036 invoked from network); 23 Oct 2013 10:25:07 -0000 Received: from bizet.nethelp.no (HELO localhost) (195.1.209.33) by bizet.nethelp.no with SMTP; 23 Oct 2013 10:25:07 -0000 Date: Wed, 23 Oct 2013 12:25:07 +0200 (CEST) Message-Id: <20131023.122507.41670841.sthaug@nethelp.no> To: Carl.Wuyts@technicolor.com From: sthaug@nethelp.no In-Reply-To: <3135C2851EB6764BACEF35D8B495596806F97635FF@MOPESMBX01.eu.thmulti.com> References: <55F2A998-0417-4C19-B248-AA2A80EBF29C@cisco.com> <52679F9F.7040403@inex.ie> <3135C2851EB6764BACEF35D8B495596806F97635FF@MOPESMBX01.eu.thmulti.com> X-Mailer: Mew version 3.3 on Emacs 21.3 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Cc: otroan@cisco.com, draft-liu-bonica-v6ops-dhcpv6-slaac-problem@tools.ietf.org, v6ops@ietf.org Subject: Re: [v6ops] DHCPv6/SLAAC Make Hosts Confusing-//RE: new draft: draft-liu-bonica-v6ops-dhcpv6-slaac-problem X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 23 Oct 2013 10:25:39 -0000 > To be honest, I haven't kept up with the full exchange on this topic, so please disregard my question if it is not relative to this discussion. > > I read below that, if netmask and def gw would be added on handing out dhcpv6, "I can finally get rid of RA messages". > But what with hosts NOT supporting dhcpv6 client in this case ? I might be fully wrong, but I cannot imagine it can be 100% enforced upon each host vendor to include dhcpv6 client support? It worked for IPv4. Yes, I realize IPv6 is different, and the target market is different (e.g. light bulbs). Nevertheless - as an ISP, I am going to require DHCPv6 for dynamic address customers. I would be very happy if I only needed DHCPv6 and could do without RA. (Note RA != ND/NS) Steinar Haug, AS 2116 From Carl.Wuyts@technicolor.com Wed Oct 23 04:09:40 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0D12211E8348 for ; Wed, 23 Oct 2013 04:09:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.299 X-Spam-Level: X-Spam-Status: No, score=-6.299 tagged_above=-999 required=5 tests=[AWL=0.300, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hBgPlBHDrIV8 for ; Wed, 23 Oct 2013 04:09:33 -0700 (PDT) Received: from na3sys009aog134.obsmtp.com (na3sys009aog134.obsmtp.com [74.125.149.83]) by ietfa.amsl.com (Postfix) with ESMTP id BA4A811E836B for ; Wed, 23 Oct 2013 04:09:16 -0700 (PDT) Received: from MOPESEDGE01.eu.thmulti.com ([129.35.174.203]) (using TLSv1) by na3sys009aob134.postini.com ([74.125.148.12]) with SMTP ID DSNKUmeuW0rdgEPsMqODYVpwjYxeQUFwoFKB@postini.com; Wed, 23 Oct 2013 04:09:25 PDT Received: from MOPESMAILHC03.eu.thmulti.com (141.11.100.132) by mail3.technicolor.com (141.11.253.22) with Microsoft SMTP Server (TLS) id 8.3.298.1; Wed, 23 Oct 2013 13:04:58 +0200 Received: from MOPESMBX01.eu.thmulti.com ([169.254.1.42]) by MOPESMAILHC03.eu.thmulti.com ([141.11.100.132]) with mapi; Wed, 23 Oct 2013 13:05:03 +0200 From: Wuyts Carl To: "sthaug@nethelp.no" Date: Wed, 23 Oct 2013 13:05:02 +0200 Thread-Topic: [v6ops] DHCPv6/SLAAC Make Hosts Confusing-//RE: new draft: draft-liu-bonica-v6ops-dhcpv6-slaac-problem Thread-Index: Ac7P2ije0zMJ+BesSs69PxBwDk5w1QABS7hA Message-ID: <3135C2851EB6764BACEF35D8B495596806F97636E8@MOPESMBX01.eu.thmulti.com> References: <55F2A998-0417-4C19-B248-AA2A80EBF29C@cisco.com> <52679F9F.7040403@inex.ie> <3135C2851EB6764BACEF35D8B495596806F97635FF@MOPESMBX01.eu.thmulti.com> <20131023.122507.41670841.sthaug@nethelp.no> In-Reply-To: <20131023.122507.41670841.sthaug@nethelp.no> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "otroan@cisco.com" , "draft-liu-bonica-v6ops-dhcpv6-slaac-problem@tools.ietf.org" , "v6ops@ietf.org" Subject: Re: [v6ops] DHCPv6/SLAAC Make Hosts Confusing-//RE: new draft: draft-liu-bonica-v6ops-dhcpv6-slaac-problem X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 23 Oct 2013 11:09:40 -0000 Well, "it worked in IPv4" might not be the correct approach :-). From time= to time I hear: let's do clamping again for v6, it works on v4 too .... a= nyway, out of scope in this discussion. Nevertheless, I can imagine you prefer the dhcpv6 over RA, but I doubt, loo= king at the big number of devices taking part in this these days (sensors, = bulbs, etc) that they will all start supporting dhcpv6 client, not a chance= I'm afraid. Thx for feedback Regs Carl -----Original Message----- From: sthaug@nethelp.no [mailto:sthaug@nethelp.no]=20 Sent: woensdag 23 oktober 2013 12:25 To: Wuyts Carl Cc: nick@inex.ie; otroan@cisco.com; markzzzsmith@yahoo.com.au; v6ops@ietf.o= rg; draft-liu-bonica-v6ops-dhcpv6-slaac-problem@tools.ietf.org Subject: Re: [v6ops] DHCPv6/SLAAC Make Hosts Confusing-//RE: new draft: dra= ft-liu-bonica-v6ops-dhcpv6-slaac-problem > To be honest, I haven't kept up with the full exchange on this topic, so = please disregard my question if it is not relative to this discussion. >=20 > I read below that, if netmask and def gw would be added on handing out dh= cpv6, "I can finally get rid of RA messages". > But what with hosts NOT supporting dhcpv6 client in this case ? I might = be fully wrong, but I cannot imagine it can be 100% enforced upon each host= vendor to include dhcpv6 client support? It worked for IPv4. Yes, I realize IPv6 is different, and the target market= is different (e.g. light bulbs). Nevertheless - as an ISP, I am going to require DHCPv6 for dynamic address = customers. I would be very happy if I only needed DHCPv6 and could do witho= ut RA. (Note RA !=3D ND/NS) Steinar Haug, AS 2116 From leo.liubing@huawei.com Wed Oct 23 04:20:38 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8D2A311E8362 for ; Wed, 23 Oct 2013 04:20:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.517 X-Spam-Level: X-Spam-Status: No, score=-6.517 tagged_above=-999 required=5 tests=[AWL=0.082, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pxgMklFXcTAD for ; Wed, 23 Oct 2013 04:20:33 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) by ietfa.amsl.com (Postfix) with ESMTP id F31E011E8259 for ; Wed, 23 Oct 2013 04:20:32 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml203-edg.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id AXC23370; Wed, 23 Oct 2013 11:20:00 +0000 (GMT) Received: from LHREML406-HUB.china.huawei.com (10.201.5.243) by lhreml203-edg.huawei.com (172.18.7.221) with Microsoft SMTP Server (TLS) id 14.3.158.1; Wed, 23 Oct 2013 12:19:49 +0100 Received: from NKGEML408-HUB.china.huawei.com (10.98.56.39) by lhreml406-hub.china.huawei.com (10.201.5.243) with Microsoft SMTP Server (TLS) id 14.3.158.1; Wed, 23 Oct 2013 12:19:50 +0100 Received: from NKGEML506-MBX.china.huawei.com ([169.254.3.141]) by nkgeml408-hub.china.huawei.com ([10.98.56.39]) with mapi id 14.03.0146.000; Wed, 23 Oct 2013 19:19:43 +0800 From: "Liubing (Leo)" To: Wuyts Carl , "sthaug@nethelp.no" Thread-Topic: [v6ops] DHCPv6/SLAAC Make Hosts Confusing-//RE: new draft: draft-liu-bonica-v6ops-dhcpv6-slaac-problem Thread-Index: AQHOz9ovEcEntaJe+k2jS/ZALT1zlZoBmaAAgACH3iA= Date: Wed, 23 Oct 2013 11:19:42 +0000 Message-ID: <8AE0F17B87264D4CAC7DE0AA6C406F453D7CCAB5@nkgeml506-mbx.china.huawei.com> References: <55F2A998-0417-4C19-B248-AA2A80EBF29C@cisco.com> <52679F9F.7040403@inex.ie> <3135C2851EB6764BACEF35D8B495596806F97635FF@MOPESMBX01.eu.thmulti.com> <20131023.122507.41670841.sthaug@nethelp.no> <3135C2851EB6764BACEF35D8B495596806F97636E8@MOPESMBX01.eu.thmulti.com> In-Reply-To: <3135C2851EB6764BACEF35D8B495596806F97636E8@MOPESMBX01.eu.thmulti.com> Accept-Language: en-US, zh-CN Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.111.98.132] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Reflected Cc: "otroan@cisco.com" , "draft-liu-bonica-v6ops-dhcpv6-slaac-problem@tools.ietf.org" , "v6ops@ietf.org" Subject: Re: [v6ops] DHCPv6/SLAAC Make Hosts Confusing-//RE: new draft: draft-liu-bonica-v6ops-dhcpv6-slaac-problem X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 23 Oct 2013 11:20:38 -0000 > From: Wuyts Carl [mailto:Carl.Wuyts@technicolor.com] ... > Nevertheless, I can imagine you prefer the dhcpv6 over RA, but I doubt, > looking at the big number of devices taking part in this these days (sens= ors, > bulbs, etc) that they will all start supporting dhcpv6 client, not a chan= ce I'm > afraid. [Bing] Agreed. These lightweight/embed systems might become an important pa= rt of the IPv6 net. ND allows minimal management burden for them. Beyond address space, in my mind SLAAC is the most obvious advantage compar= ing to IPv4. Regards, Bing > Thx for feedback >=20 > Regs > Carl >=20 >=20 >=20 >=20 > -----Original Message----- > From: sthaug@nethelp.no [mailto:sthaug@nethelp.no] > Sent: woensdag 23 oktober 2013 12:25 > To: Wuyts Carl > Cc: nick@inex.ie; otroan@cisco.com; markzzzsmith@yahoo.com.au; > v6ops@ietf.org; > draft-liu-bonica-v6ops-dhcpv6-slaac-problem@tools.ietf.org > Subject: Re: [v6ops] DHCPv6/SLAAC Make Hosts Confusing-//RE: new draft: > draft-liu-bonica-v6ops-dhcpv6-slaac-problem >=20 > > To be honest, I haven't kept up with the full exchange on this topic, s= o > please disregard my question if it is not relative to this discussion. > > > > I read below that, if netmask and def gw would be added on handing out > dhcpv6, "I can finally get rid of RA messages". > > But what with hosts NOT supporting dhcpv6 client in this case ? I migh= t > be fully wrong, but I cannot imagine it can be 100% enforced upon each ho= st > vendor to include dhcpv6 client support? >=20 > It worked for IPv4. Yes, I realize IPv6 is different, and the target mark= et is > different (e.g. light bulbs). >=20 > Nevertheless - as an ISP, I am going to require DHCPv6 for dynamic addres= s > customers. I would be very happy if I only needed DHCPv6 and could do > without RA. (Note RA !=3D ND/NS) >=20 > Steinar Haug, AS 2116 From nick@inex.ie Wed Oct 23 04:29:23 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 358DC11E8380 for ; Wed, 23 Oct 2013 04:29:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id swMVh-U4DPjQ for ; Wed, 23 Oct 2013 04:29:22 -0700 (PDT) Received: from mail.netability.ie (mail.netability.ie [IPv6:2a03:8900:0:100::5]) by ietfa.amsl.com (Postfix) with ESMTP id 7344911E81D5 for ; Wed, 23 Oct 2013 04:29:21 -0700 (PDT) X-Envelope-To: v6ops@ietf.org Received: from vpn-250.int.inex.ie (vpn-250.int.inex.ie [193.242.111.250]) (authenticated bits=0) by mail.netability.ie (8.14.7/8.14.5) with ESMTP id r9NBTB5K016949 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO); Wed, 23 Oct 2013 12:29:13 +0100 (IST) (envelope-from nick@inex.ie) Message-ID: <5267B306.10109@inex.ie> Date: Wed, 23 Oct 2013 19:29:10 +0800 From: Nick Hilliard User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:24.0) Gecko/20100101 Thunderbird/24.0.1 MIME-Version: 1.0 To: Wuyts Carl , "sthaug@nethelp.no" References: <55F2A998-0417-4C19-B248-AA2A80EBF29C@cisco.com> <52679F9F.7040403@inex.ie> <3135C2851EB6764BACEF35D8B495596806F97635FF@MOPESMBX01.eu.thmulti.com> <20131023.122507.41670841.sthaug@nethelp.no> <3135C2851EB6764BACEF35D8B495596806F97636E8@MOPESMBX01.eu.thmulti.com> In-Reply-To: <3135C2851EB6764BACEF35D8B495596806F97636E8@MOPESMBX01.eu.thmulti.com> X-Enigmail-Version: 1.6 X-Company-Info-1: Internet Neutral Exchange Association Limited. Registered in Ireland No. 253804 X-Company-Info-2: Registered Offices: 1-2, Marino Mart, Fairview, Dublin 3 X-Company-Info-3: Internet Neutral Exchange Association Limited is limited by guarantee X-Company-Info-4: Offices: 4027 Kingswood Road, Citywest, Dublin 24. Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: "otroan@cisco.com" , "draft-liu-bonica-v6ops-dhcpv6-slaac-problem@tools.ietf.org" , "v6ops@ietf.org" Subject: Re: [v6ops] DHCPv6/SLAAC Make Hosts Confusing-//RE: new draft: draft-liu-bonica-v6ops-dhcpv6-slaac-problem X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 23 Oct 2013 11:29:23 -0000 On 23/10/2013 19:05, Wuyts Carl wrote: > Nevertheless, I can imagine you prefer the dhcpv6 over RA, but I doubt, > looking at the big number of devices taking part in this these days > (sensors, bulbs, etc) that they will all start supporting dhcpv6 client, > not a chance I'm afraid. All I'm asking is that people stop blocking attempts to add prefixlen and defgw to DHCPv6. That's all, nothing more. Everyone is welcome to do what they want on their networks and if they're happy to run RA, I'm happy too. Nick From jcurran@istaff.org Wed Oct 23 04:59:21 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AE3A611E821C for ; Wed, 23 Oct 2013 04:59:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[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 ulIRkS7JeMvr for ; Wed, 23 Oct 2013 04:59:16 -0700 (PDT) Received: from mho-02-ewr.mailhop.org (mho-02-ewr.mailhop.org [204.13.248.72]) by ietfa.amsl.com (Postfix) with ESMTP id AC06711E8185 for ; Wed, 23 Oct 2013 04:59:14 -0700 (PDT) Received: from [203.153.101.244] (helo=[10.128.128.68]) by mho-02-ewr.mailhop.org with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.72) (envelope-from ) id 1VYx5l-0006w3-17 for v6ops@ietf.org; Wed, 23 Oct 2013 11:59:14 +0000 X-Mail-Handler: Dyn Standard SMTP by Dyn X-Originating-IP: 203.153.101.244 X-Report-Abuse-To: abuse@dyndns.com (see http://www.dyndns.com/services/sendlabs/outbound_abuse.html for abuse reporting information) X-MHO-User: U2FsdGVkX1/4k4AhsurfS3EBaD1S1mll From: John Curran Content-Type: multipart/alternative; boundary="Apple-Mail=_D5CB4B5D-6AF7-42CB-9D97-7BAFDA3644FF" Date: Wed, 23 Oct 2013 19:59:07 +0800 References: <28CFF7E5-E98E-4D97-B7F4-3A18C255253C@gigix.net> To: v6ops@ietf.org Message-Id: Mime-Version: 1.0 (Mac OS X Mail 6.6 \(1510\)) X-Mailer: Apple Mail (2.1510) Subject: [v6ops] Revised Internet Drafts for allocation of IPv6 space for LISP EIDs X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 23 Oct 2013 11:59:21 -0000 --Apple-Mail=_D5CB4B5D-6AF7-42CB-9D97-7BAFDA3644FF Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii V6ops Folks -=20 There are two revised Internet Drafts in the Lisp working group that = might=20 be worth reviewing by those running IPv6 networks. These drafts = will=20 allocate a /16 IPv6 prefix for use as LISP global Endpoint = IDentifier (EID)=20 space and define the associated allocation framework. Assignments from this block may appear the in the BGP routing infrastructure. FYI, /John Begin forwarded message: > From: Luigi Iannone > Subject: [lisp] Fwd: I-D Action: = draft-iannone-lisp-eid-block-mgmnt-03.txt > Date: October 21, 2013 9:23:26 PM GMT+08:00 > To: "lisp@ietf.org list" >=20 > Hi All, >=20 > the EID block documents have been updated as discussed during the last = meeting in Orlando. >=20 > Since both documents changed a lot would be great if people can read = them and send feedback >=20 > thanks >=20 > ciao >=20 > Luigi >=20 > Begin forwarded message: >=20 >> From: internet-drafts@ietf.org >> Subject: I-D Action: draft-iannone-lisp-eid-block-mgmnt-03.txt >> Date: 21 October 2013 15:14:46 GMT+02:00 >> To: i-d-announce@ietf.org >> Reply-To: internet-drafts@ietf.org >>=20 >>=20 >> A New Internet-Draft is available from the on-line Internet-Drafts = directories. >>=20 >>=20 >> Title : LISP EID Block Management Guidelines >> Author(s) : Luigi Iannone >> Roger Jorgensen >> David Conrad >> Filename : draft-iannone-lisp-eid-block-mgmnt-03.txt >> Pages : 11 >> Date : 2013-10-21 >>=20 >> Abstract: >> This document proposes an allocation framework for the management = of >> the LISP EID address prefix (requested in = [I-D.ietf-lisp-eid-block]). >> The framework described relies on hierarchical distribution of the >> address space with sub-prefixes allocated on a temporary basis to >> requesting organizations. >>=20 >>=20 >> The IETF datatracker status page for this draft is: >> https://datatracker.ietf.org/doc/draft-iannone-lisp-eid-block-mgmnt >>=20 >> There's also a htmlized version available at: >> http://tools.ietf.org/html/draft-iannone-lisp-eid-block-mgmnt-03 >>=20 >> A diff from the previous version is available at: >> = http://www.ietf.org/rfcdiff?url2=3Ddraft-iannone-lisp-eid-block-mgmnt-03 >>=20 >>=20 >> Please note that it may take a couple of minutes from the time of = submission >> until the htmlized version and diff are available at tools.ietf.org. >>=20 >> Internet-Drafts are also available by anonymous FTP at: >> ftp://ftp.ietf.org/internet-drafts/ >>=20 >> _______________________________________________ >> I-D-Announce mailing list >> I-D-Announce@ietf.org >> https://www.ietf.org/mailman/listinfo/i-d-announce >> Internet-Draft directories: http://www.ietf.org/shadow.html >> or ftp://ftp.ietf.org/ietf/1shadow-sites.txt >=20 > _______________________________________________ > lisp mailing list > lisp@ietf.org > https://www.ietf.org/mailman/listinfo/lisp Begin forwarded message: > From: internet-drafts@ietf.org > Subject: [lisp] I-D Action: draft-ietf-lisp-eid-block-06.txt > Date: October 21, 2013 9:12:38 PM GMT+08:00 > To: i-d-announce@ietf.org > Cc: lisp@ietf.org >=20 >=20 > A New Internet-Draft is available from the on-line Internet-Drafts = directories. > This draft is a work item of the Locator/ID Separation Protocol = Working Group of the IETF. >=20 > Title : LISP EID Block > Author(s) : Luigi Iannone > Darrel Lewis > David Meyer > Vince Fuller > Filename : draft-ietf-lisp-eid-block-06.txt > Pages : 16 > Date : 2013-10-21 >=20 > Abstract: > This is a direction to IANA to allocate a /16 IPv6 prefix for use > with the Locator/ID Separation Protocol (LISP). The prefix will be > used for local intra-domain routing and global endpoint > identification, by sites deploying LISP as EID (Endpoint IDentifier) > addressing space. >=20 >=20 > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-ietf-lisp-eid-block >=20 > There's also a htmlized version available at: > http://tools.ietf.org/html/draft-ietf-lisp-eid-block-06 >=20 > A diff from the previous version is available at: > http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-lisp-eid-block-06 >=20 >=20 > Please note that it may take a couple of minutes from the time of = submission > until the htmlized version and diff are available at tools.ietf.org. >=20 > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ >=20 > _______________________________________________ > lisp mailing list > lisp@ietf.org > https://www.ietf.org/mailman/listinfo/lisp --Apple-Mail=_D5CB4B5D-6AF7-42CB-9D97-7BAFDA3644FF Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii V6ops = Folks - 

    There are two revised = Internet Drafts in the Lisp working group = that might 
    be worth reviewing by = those running IPv6 networks.   These drafts = will 
    allocate a /16 IPv6 prefix for use as = LISP global Endpoint IDentifier (EID) 
  =   space and define the associated allocation framework. =  Assignments
    from this block may = appear the in the BGP routing = infrastructure.

FYI,
/John

Begin forwarded message:

From: Luigi Iannone = <ggx@gigix.net>
Subject: = [lisp] Fwd: I-D Action: = draft-iannone-lisp-eid-block-mgmnt-03.txt
Date: October 21, 2013 = 9:23:26 PM GMT+08:00

Hi = All,

the EID block documents have been updated as = discussed during the last meeting in = Orlando.

Since both documents changed a lot = would be great if people can read them and send = feedback

thanks

ciao

Luigi

Begin forwarded = message:

Subject: I-D Action: = draft-iannone-lisp-eid-block-mgmnt-03.txt
Date: 21 October 2013 15:14:46 = GMT+02:00
Reply-To: internet-drafts@ietf.org
<= /span>


A New Internet-Draft is available from the = on-line Internet-Drafts directories.


Title =           : LISP EID = Block Management Guidelines
Author(s) =       : Luigi Iannone
=             &n= bsp;           &nbs= p;Roger Jorgensen
=             &n= bsp;           &nbs= p;David Conrad
Filename =        : = draft-iannone-lisp-eid-block-mgmnt-03.txt
Pages =           : = 11
= Date =            : = 2013-10-21

Abstract:
  This document proposes an = allocation framework for the management of
  the LISP EID = address prefix (requested in [I-D.ietf-lisp-eid-block]).
=   The framework described relies on hierarchical distribution = of the
  address space with sub-prefixes allocated on a = temporary basis to
  requesting = organizations.


The IETF datatracker status page for this = draft is:
https://datatracker.ietf.org/doc/draft-iannone-lisp-eid-block-mgmnt=

There's also a htmlized version available at:
= http://tools.ietf.org/html/draft-iannone-lisp-eid-block-mgmnt-03
A diff from the previous version is available at:
http://www.ietf.org/rfcdiff?url2=3Ddraft-iannone-lisp-eid-block-mg= mnt-03


Please note that it may take a couple of minutes = from the time of submission
until the htmlized version and diff are = available at tools.ietf.org.

Internet-Drafts are also available = by anonymous FTP = at:
ftp://ftp.ietf.org/internet-drafts/

________________________= _______________________
I-D-Announce mailing = list
I-D-Announce@ietf.org
https://www.ietf.org/mailman/listinfo/i-d= -announce
Internet-Draft directories: = http://www.ietf.org/shadow.html
or = ftp://ftp.ietf.org/ietf/1shadow-sites.txt

=
_______________________________________________
lisp = mailing list
lisp@ietf.org
https://www.ietf.org/m= ailman/listinfo/lisp

Begin = forwarded message:

From: internet-drafts@ietf.org
<= /div>
Subject: [lisp] I-D = Action: draft-ietf-lisp-eid-block-06.txt
Date: October 21, 2013 9:12:38 PM = GMT+08:00
<= div style=3D"margin: 0px; ">Cc: lisp@ietf.org


A = New Internet-Draft is available from the on-line Internet-Drafts = directories.
This draft is a work item of the Locator/ID Separation = Protocol Working Group of the IETF.

Title =           : LISP EID = Block
= Author(s)       : Luigi = Iannone
          &nb= sp;            = ;  Darrel = Lewis
           = ;            &= nbsp; David = Meyer
           = ;            &= nbsp; Vince Fuller
Filename =        : = draft-ietf-lisp-eid-block-06.txt
Pages =           : = 16
= Date =            : = 2013-10-21

Abstract:
  This is a direction to IANA = to allocate a /16 IPv6 prefix for use
  with the Locator/ID = Separation Protocol (LISP).  The prefix will be
  used = for local intra-domain routing and global = endpoint
  identification, by sites deploying LISP as EID = (Endpoint IDentifier)
  addressing space.


The = IETF datatracker status page for this draft is:
https:= //datatracker.ietf.org/doc/draft-ietf-lisp-eid-block

There's = also a htmlized version available at:
http://to= ols.ietf.org/html/draft-ietf-lisp-eid-block-06

A diff from = the previous version is available = at:
http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-lisp-eid-block-06
=

Please note that it may take a couple of minutes from the time = of submission
until the htmlized version and diff are available at = tools.ietf.org.

Internet-Drafts are also available by anonymous = FTP = at:
ftp://ftp.ietf.org/internet-drafts/

________________________= _______________________
lisp mailing = list
lisp@ietf.org
https://www.ietf.org/mailman/listinfo/lisp


= --Apple-Mail=_D5CB4B5D-6AF7-42CB-9D97-7BAFDA3644FF-- From Fred.L.Templin@boeing.com Wed Oct 23 08:20:12 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 627D211E81B6 for ; Wed, 23 Oct 2013 08:20:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.226 X-Spam-Level: X-Spam-Status: No, score=-6.226 tagged_above=-999 required=5 tests=[AWL=-0.227, BAYES_00=-2.599, J_CHICKENPOX_13=0.6, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZJ4Ius0kLU-M for ; Wed, 23 Oct 2013 08:20:07 -0700 (PDT) Received: from stl-mbsout-02.boeing.com (stl-mbsout-02.boeing.com [130.76.96.170]) by ietfa.amsl.com (Postfix) with ESMTP id 46BB721F9C4A for ; Wed, 23 Oct 2013 08:20:07 -0700 (PDT) Received: from stl-mbsout-02.boeing.com (localhost.localdomain [127.0.0.1]) by stl-mbsout-02.boeing.com (8.14.4/8.14.4/DOWNSTREAM_MBSOUT) with ESMTP id r9NFK6RH009745 for ; Wed, 23 Oct 2013 10:20:06 -0500 Received: from XCH-NWHT-11.nw.nos.boeing.com (xch-nwht-11.nw.nos.boeing.com [130.247.25.114]) by stl-mbsout-02.boeing.com (8.14.4/8.14.4/UPSTREAM_MBSOUT) with ESMTP id r9NFJK7L007829 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=OK); Wed, 23 Oct 2013 10:20:05 -0500 Received: from XCH-BLV-405.nw.nos.boeing.com (130.247.25.158) by XCH-NWHT-11.nw.nos.boeing.com (130.247.25.114) with Microsoft SMTP Server (TLS) id 8.3.327.1; Wed, 23 Oct 2013 08:20:01 -0700 Received: from XCH-BLV-504.nw.nos.boeing.com ([169.254.4.85]) by XCH-BLV-405.nw.nos.boeing.com ([169.254.5.227]) with mapi id 14.03.0158.001; Wed, 23 Oct 2013 08:20:00 -0700 From: "Templin, Fred L" To: Jeroen Massar , sajjad akbar , "v6ops@ietf.org" Thread-Topic: [v6ops] Possibility of Multicast support through GRE tunnel? Thread-Index: AQHOz86LrF5XfDACgUG7e74P15fBx5oCV3+AgAAMO/A= Date: Wed, 23 Oct 2013 15:20:00 +0000 Message-ID: <2134F8430051B64F815C691A62D98318137D15@XCH-BLV-504.nw.nos.boeing.com> References: <1382518881.42811.YahooMailNeo@web121504.mail.ne1.yahoo.com> <526795C1.7060803@massar.ch> In-Reply-To: <526795C1.7060803@massar.ch> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [130.247.104.6] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-TM-AS-MML: disable Subject: Re: [v6ops] Possibility of Multicast support through GRE tunnel? X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 23 Oct 2013 15:20:12 -0000 RFC2529 is an automatic tunneling mechanism that specifies a multicast mapping from the IPv6 multicast space to the IPv4 space. VET is a more recent automatic tunneling mechanism that picks up the RFC2529 mapping. Thanks - Fred fred.l.templin@boeing.com=20 > -----Original Message----- > From: v6ops-bounces@ietf.org [mailto:v6ops-bounces@ietf.org] On Behalf > Of Jeroen Massar > Sent: Wednesday, October 23, 2013 2:24 AM > To: sajjad akbar; v6ops@ietf.org > Subject: Re: [v6ops] Possibility of Multicast support through GRE > tunnel? >=20 > On 2013-10-23 11:01, sajjad akbar wrote: > > > > > > Dear fellows > > > > > > We need to implement multicast for hybrid network (IPv6-IPv4) in our > > testbed. No automatic tunneling mechanism is supporting multicast. > > can GRE tunnel support multicast streaming in a hybrid network (IPv6- > IPv4)? >=20 > As per: http://www.sixxs.net/faq/connectivity/?faq=3Dcomparison >=20 > Yes, GRE can do it, but as listed there many others do too. >=20 > The trick is that at either end of the tunnel you will have to run a > MLD > proxy or a real multicast router for things to work. > (ecmh amongst many others can achieve this) >=20 > You state you have a 'hybrid network', why is that network not native? >=20 > Greets, > Jeroen >=20 >=20 > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops From brian@innovationslab.net Wed Oct 23 08:21:27 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1757311E844A for ; Wed, 23 Oct 2013 08:21:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.299 X-Spam-Level: X-Spam-Status: No, score=-102.299 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, J_CHICKENPOX_13=0.6, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JiacFA6PpxHm for ; Wed, 23 Oct 2013 08:21:22 -0700 (PDT) Received: from uillean.fuaim.com (uillean.fuaim.com [206.197.161.140]) by ietfa.amsl.com (Postfix) with ESMTP id 16FB211E81B6 for ; Wed, 23 Oct 2013 08:21:22 -0700 (PDT) Received: from clairseach.fuaim.com (clairseach-high.fuaim.com [206.197.161.158]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by uillean.fuaim.com (Postfix) with ESMTP id 1E7A18810A for ; Wed, 23 Oct 2013 08:21:22 -0700 (PDT) Received: from 10252520.rudm1.ra.johnshopkins.edu (addr16212925014.ippl.jhmi.edu [162.129.250.14]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by clairseach.fuaim.com (Postfix) with ESMTP id 7EEF7136811A for ; Wed, 23 Oct 2013 08:21:21 -0700 (PDT) Message-ID: <5267E96B.1000802@innovationslab.net> Date: Wed, 23 Oct 2013 11:21:15 -0400 From: Brian Haberman User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:24.0) Gecko/20100101 Thunderbird/24.0.1 MIME-Version: 1.0 To: v6ops@ietf.org References: <28CFF7E5-E98E-4D97-B7F4-3A18C255253C@gigix.net> In-Reply-To: X-Enigmail-Version: 1.5.2 Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="qKVtXubmx0b49kxN9pi4J7M8ce6VLEvvG" Subject: Re: [v6ops] Revised Internet Drafts for allocation of IPv6 space for LISP EIDs X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 23 Oct 2013 15:21:27 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --qKVtXubmx0b49kxN9pi4J7M8ce6VLEvvG Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Hi John, On 10/23/13 7:59 AM, John Curran wrote: > V6ops Folks -=20 >=20 > There are two revised Internet Drafts in the Lisp working group tha= t might=20 > be worth reviewing by those running IPv6 networks. These drafts w= ill=20 > allocate a /16 IPv6 prefix for use as LISP global Endpoint IDentifi= er (EID)=20 > space and define the associated allocation framework. Assignments > from this block may appear the in the BGP routing infrastructure. >=20 With no hat on... I don't think there is any "may" about their appearance in BGP route tables. Regards, Brian > FYI, > /John >=20 > Begin forwarded message: >=20 >> From: Luigi Iannone >> Subject: [lisp] Fwd: I-D Action: draft-iannone-lisp-eid-block-mgmnt-03= =2Etxt >> Date: October 21, 2013 9:23:26 PM GMT+08:00 >> To: "lisp@ietf.org list" >> >> Hi All, >> >> the EID block documents have been updated as discussed during the last= meeting in Orlando. >> >> Since both documents changed a lot would be great if people can read t= hem and send feedback >> >> thanks >> >> ciao >> >> Luigi >> >> Begin forwarded message: >> >>> From: internet-drafts@ietf.org >>> Subject: I-D Action: draft-iannone-lisp-eid-block-mgmnt-03.txt >>> Date: 21 October 2013 15:14:46 GMT+02:00 >>> To: i-d-announce@ietf.org >>> Reply-To: internet-drafts@ietf.org >>> >>> >>> A New Internet-Draft is available from the on-line Internet-Drafts di= rectories. >>> >>> >>> Title : LISP EID Block Management Guidelines >>> Author(s) : Luigi Iannone >>> Roger Jorgensen >>> David Conrad >>> Filename : draft-iannone-lisp-eid-block-mgmnt-03.txt >>> Pages : 11 >>> Date : 2013-10-21 >>> >>> Abstract: >>> This document proposes an allocation framework for the management o= f >>> the LISP EID address prefix (requested in [I-D.ietf-lisp-eid-block]= ). >>> The framework described relies on hierarchical distribution of the >>> address space with sub-prefixes allocated on a temporary basis to >>> requesting organizations. >>> >>> >>> The IETF datatracker status page for this draft is: >>> https://datatracker.ietf.org/doc/draft-iannone-lisp-eid-block-mgmnt >>> >>> There's also a htmlized version available at: >>> http://tools.ietf.org/html/draft-iannone-lisp-eid-block-mgmnt-03 >>> >>> A diff from the previous version is available at: >>> http://www.ietf.org/rfcdiff?url2=3Ddraft-iannone-lisp-eid-block-mgmnt= -03 >>> >>> >>> Please note that it may take a couple of minutes from the time of sub= mission >>> until the htmlized version and diff are available at tools.ietf.org. >>> >>> Internet-Drafts are also available by anonymous FTP at: >>> ftp://ftp.ietf.org/internet-drafts/ >>> >>> _______________________________________________ >>> I-D-Announce mailing list >>> I-D-Announce@ietf.org >>> https://www.ietf.org/mailman/listinfo/i-d-announce >>> Internet-Draft directories: http://www.ietf.org/shadow.html >>> or ftp://ftp.ietf.org/ietf/1shadow-sites.txt >> >> _______________________________________________ >> lisp mailing list >> lisp@ietf.org >> https://www.ietf.org/mailman/listinfo/lisp >=20 > Begin forwarded message: >=20 >> From: internet-drafts@ietf.org >> Subject: [lisp] I-D Action: draft-ietf-lisp-eid-block-06.txt >> Date: October 21, 2013 9:12:38 PM GMT+08:00 >> To: i-d-announce@ietf.org >> Cc: lisp@ietf.org >> >> >> A New Internet-Draft is available from the on-line Internet-Drafts dir= ectories. >> This draft is a work item of the Locator/ID Separation Protocol Workin= g Group of the IETF. >> >> Title : LISP EID Block >> Author(s) : Luigi Iannone >> Darrel Lewis >> David Meyer >> Vince Fuller >> Filename : draft-ietf-lisp-eid-block-06.txt >> Pages : 16 >> Date : 2013-10-21 >> >> Abstract: >> This is a direction to IANA to allocate a /16 IPv6 prefix for use >> with the Locator/ID Separation Protocol (LISP). The prefix will be >> used for local intra-domain routing and global endpoint >> identification, by sites deploying LISP as EID (Endpoint IDentifier)= >> addressing space. >> >> >> The IETF datatracker status page for this draft is: >> https://datatracker.ietf.org/doc/draft-ietf-lisp-eid-block >> >> There's also a htmlized version available at: >> http://tools.ietf.org/html/draft-ietf-lisp-eid-block-06 >> >> A diff from the previous version is available at: >> http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-lisp-eid-block-06 >> >> >> Please note that it may take a couple of minutes from the time of subm= ission >> until the htmlized version and diff are available at tools.ietf.org. >> >> Internet-Drafts are also available by anonymous FTP at: >> ftp://ftp.ietf.org/internet-drafts/ >> >> _______________________________________________ >> lisp mailing list >> lisp@ietf.org >> https://www.ietf.org/mailman/listinfo/lisp >=20 >=20 >=20 >=20 >=20 > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops >=20 --qKVtXubmx0b49kxN9pi4J7M8ce6VLEvvG Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG/MacGPG2 v2.0.20 (Darwin) Comment: GPGTools - https://gpgtools.org iQEcBAEBCgAGBQJSZ+lrAAoJEBOZRqCi7goqPbIIAKlZktYsrp20+PvmV+7K0SDX AykBXXDImrPsyBPOrV8ECYKlGI21y/duIAyH9MjQM4tGGpD7AqxaHoEkZwWhAL6a ZBB0vtJ4WPjjddhIyea4U7EPG0BEgRtARgLp3Ll44OHtnIgK5kbNf2ahHWyKa9Y6 ilEPKcbU3g6yCrGXzf20tQ/h7ykdgMtWq9DbglThjkWW9VYomKEB30/cPtYU/ZgM kVTyGsIGyBo8YLUcidtSkmcWqGAzraH7Jpe1nLVBfTowjCoAvfUrnCh5J2w0yNLo 8BOVWIYwM8gDO3I0iszmXoxYePGpn3OjJ3hM8D86dzO1M8TS1aMDYNrlw6hjbjE= =1mQR -----END PGP SIGNATURE----- --qKVtXubmx0b49kxN9pi4J7M8ce6VLEvvG-- From gert@space.net Wed Oct 23 08:25:54 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9F16C11E83C7 for ; Wed, 23 Oct 2013 08:25:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.166 X-Spam-Level: X-Spam-Status: No, score=-2.166 tagged_above=-999 required=5 tests=[AWL=0.433, 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 7jNmeGPPrXoA for ; Wed, 23 Oct 2013 08:25:54 -0700 (PDT) Received: from mobil.space.net (mobil.space.net [IPv6:2001:608:2:81::67]) by ietfa.amsl.com (Postfix) with ESMTP id 56E9811E83F0 for ; Wed, 23 Oct 2013 08:25:51 -0700 (PDT) Received: from mobil.space.net (localhost [127.0.0.1]) by mobil.space.net (Postfix) with ESMTP id 0DD0A60889 for ; Wed, 23 Oct 2013 17:25:50 +0200 (CEST) X-SpaceNet-Relay: true Received: from moebius3.space.net (moebius3.Space.Net [IPv6:2001:608:2:2::250]) by mobil.space.net (Postfix) with ESMTPS id D5213607E7 for ; Wed, 23 Oct 2013 17:25:49 +0200 (CEST) Received: (qmail 14207 invoked by uid 1007); 23 Oct 2013 17:25:49 +0200 Date: Wed, 23 Oct 2013 17:25:49 +0200 From: Gert Doering To: Brian Haberman Message-ID: <20131023152549.GN50205@Space.Net> References: <28CFF7E5-E98E-4D97-B7F4-3A18C255253C@gigix.net> <5267E96B.1000802@innovationslab.net> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="jHP/eq8oeUshSv2p" Content-Disposition: inline In-Reply-To: <5267E96B.1000802@innovationslab.net> X-NCC-RegID: de.space User-Agent: Mutt/1.5.21 (2010-09-15) Cc: v6ops@ietf.org Subject: Re: [v6ops] Revised Internet Drafts for allocation of IPv6 space for LISP EIDs X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 23 Oct 2013 15:25:54 -0000 --jHP/eq8oeUshSv2p Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Hi, On Wed, Oct 23, 2013 at 11:21:15AM -0400, Brian Haberman wrote: > > space and define the associated allocation framework. Assignments > > from this block may appear the in the BGP routing infrastructure. >=20 > With no hat on... I don't think there is any "may" about their > appearance in BGP route tables. So is this "will" or "MUST NOT"? I haven't read the IDs yet, but would be wary about any "we're not happy with the way the RIRs hand out addresses, so we build our own system in parallel to it, and to hell with global routing" drafts. If that's just "we use this inside LISP, and RIR space will used on the outside", these addresses SHOULD NOT appear in global BGP. Gert Doering -- NetMaster --=20 have you enabled IPv6 on something today...? SpaceNet AG Vorstand: Sebastian v. Bomhard Joseph-Dollinger-Bogen 14 Aufsichtsratsvors.: A. Grundner-Culemann D-80807 Muenchen HRB: 136055 (AG Muenchen) Tel: +49 (0)89/32356-444 USt-IdNr.: DE813185279 --jHP/eq8oeUshSv2p Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.15 (FreeBSD) iQIVAwUBUmfqfd9WwGXkzn/FAQJobg//QjUnFhkN/2o/1RKhmoNjr+K8vwW9Wup+ f9iGVJMmFRG2L1FXLhKNSSWPlu2SkpqAk0+fC0oMlWCWE8f/CvQ3OjJs3D2hnCCg 1F5UzoxoyDscqLYCA54EiZQ64j8738ODMI5WlZ4cfJ95sPHLTEl/xPIYLM/RH95M 5DgpTFamu+RoaE32e9IYciZRCgU/At5wXt/hCvxFvbrGTG1zEZbhInbOujHyf8qJ CpFyzieRQM2254g0oNl0+NxCT5VyLSQttOEOSP9dTTKSku3Db5Szet9Ntihlv0TI tI0DXGevG8arLwf1gNPoVpM4vW3DSQXBsLGETmMCA8Me40fSnbXTjLq2Mz2ojL8a fBXcCEEK/zISOXKxBgx23v9vOKiwMAKmLAaiu8g8A3+6YYsTMwcis4W77zCOts9V 4EOBzJtRDAOtjRTByRWtcKoCxdEygTKhamJ2TgvlYD/BGjXYkArx67Dc+w85TWo1 /1Ajxm7qRC7wK+aLt1g9KCEaD/JW+KanxbowpHjeK2ZuqZ3Fb9k0kpkfxqKWH50D 2W/0ZS87ez6/WLx3LaA5nx6HSC2J3eqy1BImRTIrOdVpiT30IKsoi+BiyOOvLnyB 9tJYbzZR5drui+nv8FTzNy67TGjnzNa3IEKPgO6rxNHckqb4XDaKIeUlFDdqqOyN SfHuuaV5Ipw= =OpBW -----END PGP SIGNATURE----- --jHP/eq8oeUshSv2p-- From brian@innovationslab.net Wed Oct 23 08:29:48 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3057611E813A for ; Wed, 23 Oct 2013 08:29:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.499 X-Spam-Level: X-Spam-Status: No, score=-102.499 tagged_above=-999 required=5 tests=[AWL=0.100, 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 Y3-clyWur9dY for ; Wed, 23 Oct 2013 08:29:43 -0700 (PDT) Received: from uillean.fuaim.com (uillean.fuaim.com [206.197.161.140]) by ietfa.amsl.com (Postfix) with ESMTP id 2681511E81AF for ; Wed, 23 Oct 2013 08:29:43 -0700 (PDT) Received: from clairseach.fuaim.com (clairseach-high.fuaim.com [206.197.161.158]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by uillean.fuaim.com (Postfix) with ESMTP id DE4A28810A; Wed, 23 Oct 2013 08:29:42 -0700 (PDT) Received: from 10252520.rudm1.ra.johnshopkins.edu (addr16212925014.ippl.jhmi.edu [162.129.250.14]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by clairseach.fuaim.com (Postfix) with ESMTP id 8F07B136811A; Wed, 23 Oct 2013 08:29:42 -0700 (PDT) Message-ID: <5267EB60.7080105@innovationslab.net> Date: Wed, 23 Oct 2013 11:29:36 -0400 From: Brian Haberman User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:24.0) Gecko/20100101 Thunderbird/24.0.1 MIME-Version: 1.0 To: Gert Doering References: <28CFF7E5-E98E-4D97-B7F4-3A18C255253C@gigix.net> <5267E96B.1000802@innovationslab.net> <20131023152549.GN50205@Space.Net> In-Reply-To: <20131023152549.GN50205@Space.Net> X-Enigmail-Version: 1.5.2 Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="faGvBxbrnjjJkFdaWf3v9P8mBIDr6LEc7" Cc: v6ops@ietf.org Subject: Re: [v6ops] Revised Internet Drafts for allocation of IPv6 space for LISP EIDs X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 23 Oct 2013 15:29:48 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --faGvBxbrnjjJkFdaWf3v9P8mBIDr6LEc7 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Hi Gert, On 10/23/13 11:25 AM, Gert Doering wrote: > Hi, >=20 > On Wed, Oct 23, 2013 at 11:21:15AM -0400, Brian Haberman wrote: >>> space and define the associated allocation framework. Assignment= s >>> from this block may appear the in the BGP routing infrastructure.= >> >> With no hat on... I don't think there is any "may" about their >> appearance in BGP route tables. >=20 > So is this "will" or "MUST NOT"? "Will" by my interpretation and based on discussions within the LISP WG. To quote http://tools.ietf.org/html/draft-ietf-lisp-eid-block-06#section= -7 "In order to provide connectivity between the Legacy Internet and LISP sites, PITRs announcing large aggregates (ideally one single large aggregate) of the IPv6 EID Block could be deployed." Regards, Brian --faGvBxbrnjjJkFdaWf3v9P8mBIDr6LEc7 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG/MacGPG2 v2.0.20 (Darwin) Comment: GPGTools - https://gpgtools.org iQEcBAEBCgAGBQJSZ+tgAAoJEBOZRqCi7goqcZkIALigCBP5t45KYEoiPtlqzKIU RnqMX2/jdYH2med66jHSIic+o6jWlURg6tnMA87jeArd5QoiRmdcEzoaiyoEZtfP qg5KMabfij5sqdSsvu8TwE8y4rk9LEJPvStJxfSBWXouT9+w5E2OIm9fhZbxhB0o nrpEERyE3r8Oa1yqi1mGgPJIeK7raP7CiwhenM60RYpnOHbBHJvvlYHUao8Xxle+ v0/x5zTVeyapAwyd9NoI6h7hZXTdyHK+S81QklxdQRhoC6utAe1MILZWOseCxy48 nQEvQJ3Ldtv6hY5zOBIfdCtP5/5kII0CbgxVN7oFOJgBFtA21gFSzPi+OTUiJxg= =cOb6 -----END PGP SIGNATURE----- --faGvBxbrnjjJkFdaWf3v9P8mBIDr6LEc7-- From lorenzo@google.com Wed Oct 23 08:31:46 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D62AA11E813A for ; Wed, 23 Oct 2013 08:31:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.934 X-Spam-Level: X-Spam-Status: No, score=-1.934 tagged_above=-999 required=5 tests=[AWL=0.043, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, 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 klGeKHqAYPaP for ; Wed, 23 Oct 2013 08:31:46 -0700 (PDT) Received: from mail-ie0-x236.google.com (mail-ie0-x236.google.com [IPv6:2607:f8b0:4001:c03::236]) by ietfa.amsl.com (Postfix) with ESMTP id D732911E83C7 for ; Wed, 23 Oct 2013 08:31:45 -0700 (PDT) Received: by mail-ie0-f182.google.com with SMTP id as1so1594904iec.27 for ; Wed, 23 Oct 2013 08:31:45 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=KaeEGJcI1xSYcE1k2ZZTpOSqEvgOy4+pjOF0i6fpKt0=; b=hYga/NllG0B3u/GWNBXeGVU7YdApXYItqHJSC19gFyZL8kJHWZH0F2nWXYX6vYhTOu GuoGYkcP07Om+Zgp+2lPoun2lZ19Y1SGsYcz+g9EA69sCysjHY+CC0dWYc1yq13Oy3Gu jwzhtasJ7IFDVpKXKb1CpdA5yngYjuNrZnxf4PUU82LU9JeLBlI1N64znwhJS9ocs4la pppJUVEAlUR2Td7E75n9phP8kaMtU+yL4NKRsacjql0zY65ZQ8lvAFFeTo5injfITUlR 0qbZFSEuq/OmqDT0TPpMtV6gTZJU84aNxucjPr4saILCnfb2Mr9oFDEs6aBSa7ZNVcFM iVlw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type; bh=KaeEGJcI1xSYcE1k2ZZTpOSqEvgOy4+pjOF0i6fpKt0=; b=h7TipxpCf7uw8tTNYGXULt6EtpR49Uc8qBCACbNsIqow/cyxyPn5H0tLKG50/KBA9L v+Bng/tfk3BMYf1Jq9jkhok5CUHs9ptURCBx11L+HcD2H9CHsXKxt/AYIfRpsRGx15dC dzIhKH9UfpIqXvnmfAP7+xmbUfH+r4lJq3sJX4mlXgFgPj8kXrByKa8pDtI2L2Pph9/u R43gsyr/IvfLk9tgxi/vSS5A+OiVmhS02HmQFt04L38zP1q0qgGTJiwfU4fRH03pZWuO ce+bMTG0y4Z3bZ3n+gpsfMyN0h59KJ9RyjNiYPkOwE7vn8PuBzxrlM0s44zrqnuH6L5n HGCA== X-Gm-Message-State: ALoCoQkJFRyT9FHHX1A+kGVFFAMACZmJdqu0HRlY/r4wlThTirTfAO8X5c1uivZm0mfIMPU0AkS1P0sQVEzIaZCz+PZy30djquQRf2aAAGXbcAkv3mcO4VHWYiCjdTfsv3YRiPhrTr1PfDtZlGr/VV25P3cDntjLH1xH0U4gVUA9xKmv9vNzI8KUc8ATxp2QK/TaH+dmzc05 X-Received: by 10.43.80.67 with SMTP id zt3mr955223icb.23.1382542305468; Wed, 23 Oct 2013 08:31:45 -0700 (PDT) MIME-Version: 1.0 Received: by 10.64.86.106 with HTTP; Wed, 23 Oct 2013 08:31:25 -0700 (PDT) In-Reply-To: <5267EB60.7080105@innovationslab.net> References: <28CFF7E5-E98E-4D97-B7F4-3A18C255253C@gigix.net> <5267E96B.1000802@innovationslab.net> <20131023152549.GN50205@Space.Net> <5267EB60.7080105@innovationslab.net> From: Lorenzo Colitti Date: Thu, 24 Oct 2013 00:31:25 +0900 Message-ID: To: Brian Haberman Content-Type: multipart/alternative; boundary=001a1133326a01415504e96a3733 Cc: "v6ops@ietf.org WG" Subject: Re: [v6ops] Revised Internet Drafts for allocation of IPv6 space for LISP EIDs X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 23 Oct 2013 15:31:47 -0000 --001a1133326a01415504e96a3733 Content-Type: text/plain; charset=ISO-8859-1 On Thu, Oct 24, 2013 at 12:29 AM, Brian Haberman wrote: > "In order to provide connectivity between the Legacy Internet and LISP > sites, PITRs announcing large aggregates (ideally one single large > aggregate) of the IPv6 EID Block could be deployed." > That sounds very much like a 6to4 relay router, which experience has shown was an unworkable deployment model. Why is this different? --001a1133326a01415504e96a3733 Content-Type: text/html; charset=ISO-8859-1
On Thu, Oct 24, 2013 at 12:29 AM, Brian Haberman <brian@innovationslab.net> wrote:
"In order to provide connectivity between the Legacy Internet and LISP
sites, PITRs announcing large aggregates (ideally one single large
aggregate) of the IPv6 EID Block could be deployed."

That sounds very much like a 6to4 relay router, which experience has shown was an unworkable deployment model. Why is this different?
--001a1133326a01415504e96a3733-- From brian@innovationslab.net Wed Oct 23 08:37:16 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1FD0A11E83EF for ; Wed, 23 Oct 2013 08:37:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.524 X-Spam-Level: X-Spam-Status: No, score=-102.524 tagged_above=-999 required=5 tests=[AWL=0.075, 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 cog2dRgsG44d for ; Wed, 23 Oct 2013 08:37:09 -0700 (PDT) Received: from uillean.fuaim.com (uillean.fuaim.com [206.197.161.140]) by ietfa.amsl.com (Postfix) with ESMTP id 5EFBF11E83D7 for ; Wed, 23 Oct 2013 08:37:09 -0700 (PDT) Received: from clairseach.fuaim.com (clairseach-high.fuaim.com [206.197.161.158]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by uillean.fuaim.com (Postfix) with ESMTP id 12BFD8810A; Wed, 23 Oct 2013 08:36:58 -0700 (PDT) Received: from 10252520.rudm1.ra.johnshopkins.edu (addr16212925014.ippl.jhmi.edu [162.129.250.14]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by clairseach.fuaim.com (Postfix) with ESMTP id 9FC50136811A; Wed, 23 Oct 2013 08:36:57 -0700 (PDT) Message-ID: <5267ED12.4090602@innovationslab.net> Date: Wed, 23 Oct 2013 11:36:50 -0400 From: Brian Haberman User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:24.0) Gecko/20100101 Thunderbird/24.0.1 MIME-Version: 1.0 To: Lorenzo Colitti References: <28CFF7E5-E98E-4D97-B7F4-3A18C255253C@gigix.net> <5267E96B.1000802@innovationslab.net> <20131023152549.GN50205@Space.Net> <5267EB60.7080105@innovationslab.net> In-Reply-To: X-Enigmail-Version: 1.5.2 Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="3CDDt6ewvRsbp6QllpnsGH1RiF95LnjxC" Cc: "v6ops@ietf.org WG" Subject: Re: [v6ops] Revised Internet Drafts for allocation of IPv6 space for LISP EIDs X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 23 Oct 2013 15:37:16 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --3CDDt6ewvRsbp6QllpnsGH1RiF95LnjxC Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Hi Lorenzo, On 10/23/13 11:31 AM, Lorenzo Colitti wrote: > On Thu, Oct 24, 2013 at 12:29 AM, Brian Haberman > wrote: >=20 >> "In order to provide connectivity between the Legacy Internet and LISP= >> sites, PITRs announcing large aggregates (ideally one single large >> aggregate) of the IPv6 EID Block could be deployed." >> >=20 > That sounds very much like a 6to4 relay router, which experience has sh= own > was an unworkable deployment model. Why is this different? >=20 It's not different. But, that is the tact the LISP WG is trying to take. Keep in mind that the referenced draft went through IETF Last Call and was subsequently sent back to the WG due to the concerns raised about routing and potentially creating a parallel address registry outside of the RIRs. Regards, Brian --3CDDt6ewvRsbp6QllpnsGH1RiF95LnjxC Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG/MacGPG2 v2.0.20 (Darwin) Comment: GPGTools - https://gpgtools.org iQEcBAEBCgAGBQJSZ+0TAAoJEBOZRqCi7goqUN4H/1Ic3HmNdkzA0l7eHr9GXMy4 vwuAaxtbnVe/Bu8BefO8yiIDT8Xwv1dfddCGmgKwaTHQRhSkZRzZPmkq04bZkoPj 9zDBPJv1NBlCgqgVPYxQ3DhF5pxsBiL+2LfWDi6TmLKbhtIFu4O9iyU4pq2HXQL1 qegkwurLLtGtrPiPj8jzfIavgrcT6JavIxsdNbiG5ZuZJL5d8lKCRixc0nT/DvK4 qh8njOerl94Uu6j3LtEsKDYtmFV9iBQA6kL2UT7/y0zdJfaRbMO2A+l4M9BmppOv wrwtoxxtJ8Yz3/L9fjkwN0oYkeTnrn+aFC2jGhFS+7wW5lfoSAQMteFEiObPr2E= =Y66Q -----END PGP SIGNATURE----- --3CDDt6ewvRsbp6QllpnsGH1RiF95LnjxC-- From gert@space.net Wed Oct 23 09:02:46 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2C47C11E840D for ; Wed, 23 Oct 2013 09:02:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.274 X-Spam-Level: X-Spam-Status: No, score=-2.274 tagged_above=-999 required=5 tests=[AWL=0.325, 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 qxXQjWDDOV+w for ; Wed, 23 Oct 2013 09:02:45 -0700 (PDT) Received: from mobil.space.net (mobil.space.net [IPv6:2001:608:2:81::67]) by ietfa.amsl.com (Postfix) with ESMTP id 642AF11E8465 for ; Wed, 23 Oct 2013 09:02:03 -0700 (PDT) Received: from mobil.space.net (localhost [127.0.0.1]) by mobil.space.net (Postfix) with ESMTP id E01D7608BB for ; Wed, 23 Oct 2013 18:02:02 +0200 (CEST) X-SpaceNet-Relay: true Received: from moebius3.space.net (moebius3.Space.Net [IPv6:2001:608:2:2::250]) by mobil.space.net (Postfix) with ESMTPS id C8687608A1 for ; Wed, 23 Oct 2013 18:02:02 +0200 (CEST) Received: (qmail 27467 invoked by uid 1007); 23 Oct 2013 18:02:02 +0200 Date: Wed, 23 Oct 2013 18:02:02 +0200 From: Gert Doering To: Brian Haberman Message-ID: <20131023160202.GO50205@Space.Net> References: <28CFF7E5-E98E-4D97-B7F4-3A18C255253C@gigix.net> <5267E96B.1000802@innovationslab.net> <20131023152549.GN50205@Space.Net> <5267EB60.7080105@innovationslab.net> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="Kgh2FNDOY+603hGA" Content-Disposition: inline In-Reply-To: <5267EB60.7080105@innovationslab.net> X-NCC-RegID: de.space User-Agent: Mutt/1.5.21 (2010-09-15) Cc: v6ops@ietf.org Subject: Re: [v6ops] Revised Internet Drafts for allocation of IPv6 space for LISP EIDs X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 23 Oct 2013 16:02:46 -0000 --Kgh2FNDOY+603hGA Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Hi, On Wed, Oct 23, 2013 at 11:29:36AM -0400, Brian Haberman wrote: > "In order to provide connectivity between the Legacy Internet and LISP > sites, PITRs announcing large aggregates (ideally one single large > aggregate) of the IPv6 EID Block could be deployed." Mmmh, someone got told how 6to4 anycast not-worked and intends to bring it = all back. Yay. Gert Doering -- NetMaster --=20 have you enabled IPv6 on something today...? SpaceNet AG Vorstand: Sebastian v. Bomhard Joseph-Dollinger-Bogen 14 Aufsichtsratsvors.: A. Grundner-Culemann D-80807 Muenchen HRB: 136055 (AG Muenchen) Tel: +49 (0)89/32356-444 USt-IdNr.: DE813185279 --Kgh2FNDOY+603hGA Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.15 (FreeBSD) iQIVAwUBUmfy+t9WwGXkzn/FAQI2EA/9Ef4U2HAGZajhcG1sknTSfwZiS66/s9iS yGxGkWBmcHD03iqNgmnSD5if9QgbeSPNYKtZ7ImY/bvfLG8yOR8wPtIje3Ci3cSx himRX2RwzQzp2/mYhsXKOnF0gRArZpNZGuinhtqIfHOymsKI8tPkpD9HXv6/I++F c/L0QC1rBX0RQEPHruLK+fsr1hIKQ7ujKzZPoFgs+6ndW46n1UCNNNCZ366Qu2/X 0bLq0p1XlBrzulO6cg7ztR2HmBJyXeYeVZMDPg4Mkyxyf4kCW+/I80xfv/hE1IAe NhhKD0Uq23j2rGoR66aewgLo2inHudG/P9rjC8N0F6fS4tGq8KqsAlcbcgNoby4N ySHI3nyk6jlNWnlEjb2gMf4EUDb0E91dfZNBlbZM3WcVqxoduvyX2n7qCEfr8TMC HwfBsae0elQNlzOo6PQMNVCKaU01PcGzVcc7nSVdBur3bZuMcpKhv6QV+aqn08dH nVDxI3M8qXpniDduY1v2B3Ryc29XJehfBKHnbf825WKNvDnGkcJLg1bnbdM7014o QzLj4FFY5LdiPtmk1O2BgPRzIWwXZBoTXQyEwZNuckYMdnXnD0bc1wOLDZ7erLcc MDqS1nkhzi8aTs38aTbQFkA3wtMfjphuNWfCCfHtmrMDUceD5n2LUfrGGQspkI39 +mCpLuQPA34= =u5gM -----END PGP SIGNATURE----- --Kgh2FNDOY+603hGA-- From gert@space.net Wed Oct 23 09:07:18 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AAE4C11E840D for ; Wed, 23 Oct 2013 09:07:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.339 X-Spam-Level: X-Spam-Status: No, score=-2.339 tagged_above=-999 required=5 tests=[AWL=0.260, 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 ln31C0Ty4ud5 for ; Wed, 23 Oct 2013 09:07:14 -0700 (PDT) Received: from mobil.space.net (mobil.space.net [IPv6:2001:608:2:81::67]) by ietfa.amsl.com (Postfix) with ESMTP id D983C11E844C for ; Wed, 23 Oct 2013 09:06:49 -0700 (PDT) Received: from mobil.space.net (localhost [127.0.0.1]) by mobil.space.net (Postfix) with ESMTP id 5C3FB608C9 for ; Wed, 23 Oct 2013 18:06:49 +0200 (CEST) X-SpaceNet-Relay: true Received: from moebius3.space.net (moebius3.Space.Net [IPv6:2001:608:2:2::250]) by mobil.space.net (Postfix) with ESMTPS id 426BA608BA for ; Wed, 23 Oct 2013 18:06:49 +0200 (CEST) Received: (qmail 33967 invoked by uid 1007); 23 Oct 2013 18:06:49 +0200 Date: Wed, 23 Oct 2013 18:06:49 +0200 From: Gert Doering To: Brian Haberman Message-ID: <20131023160649.GP50205@Space.Net> References: <28CFF7E5-E98E-4D97-B7F4-3A18C255253C@gigix.net> <5267E96B.1000802@innovationslab.net> <20131023152549.GN50205@Space.Net> <5267EB60.7080105@innovationslab.net> <5267ED12.4090602@innovationslab.net> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="jnCIwN96y15MEy/K" Content-Disposition: inline In-Reply-To: <5267ED12.4090602@innovationslab.net> X-NCC-RegID: de.space User-Agent: Mutt/1.5.21 (2010-09-15) Cc: "v6ops@ietf.org WG" Subject: Re: [v6ops] Revised Internet Drafts for allocation of IPv6 space for LISP EIDs X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 23 Oct 2013 16:07:18 -0000 --jnCIwN96y15MEy/K Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Hi, On Wed, Oct 23, 2013 at 11:36:50AM -0400, Brian Haberman wrote: > Keep in mind that the referenced draft went through IETF Last > Call and was subsequently sent back to the WG due to the concerns raised > about routing and potentially creating a parallel address registry > outside of the RIRs. These are the concerns I share, so I consider this pushback to be good news. And no, I do not have reasonable ideas how to solve this, as=20 I see this area as one of the hardest points in deploying LISP in a mixed LISP-talks-to-non-LISP model. Thanks for the background info. Gert Doering -- NetMaster --=20 have you enabled IPv6 on something today...? SpaceNet AG Vorstand: Sebastian v. Bomhard Joseph-Dollinger-Bogen 14 Aufsichtsratsvors.: A. Grundner-Culemann D-80807 Muenchen HRB: 136055 (AG Muenchen) Tel: +49 (0)89/32356-444 USt-IdNr.: DE813185279 --jnCIwN96y15MEy/K Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.15 (FreeBSD) iQIVAwUBUmf0GN9WwGXkzn/FAQL7/BAAhdHpMMGcYNQywL0X7STDz0LphbZtKTi0 KxN3V8SzN6YilKmsVvLr5RAkXc/XoEr7OO/qL8SAneLqHRc82oaDlxz/UEkwE//W 8ZsNpMzM/3FfSn5KRIaMSO+ywv3LTOio0HrHKWLTUxjK+Nu8QdMX+gJ0cHmsl+NP ZN9ONdV1pEFsXRItSZqmSLajMWyDHIqg44lQOtG4cRMSq5HeWKPm3mJF8cP0/Si+ u6EgCyn7wjDq/e7JsxZPefTLDv26rmml5YjTSlETy8MZ1wn6vw0QDKzuebHNlHH+ Zqnc0DCP1PXYomsWKBK0ZUtXfRWbX5MRlAQOkxbAMsezSj2PbOy+eyb3uz8XX+OE p/I+1erLvsr7aSniCNizwEPe3PertwEGd9DFZFjrvfGefmem9QMPZUEuK0wmzhXL VYQFzUnhC9gySVi/RilDxl8kBW9IgR8PbCFLMiEbEkpU+Mlarle5Dr6WtdIU1Vgy m5WffBLF4y7nyECG/CYfbwXwJasOS/Wsqoctmb6DBXmPrI2nNK0K8O+9qg3NV6UU S8esN5Pg7Ie4i5jI08H+JImP2zOiSqasgpciY01gnrlXXRB2vj6YEC3VhyxvqCam kHon1z6fZE+8UlxpvWN/QYKNu69ff7hRy0gQW3N/SdKLxB+tQyEsYRlfMjgaYLzF nZqV5ybAMFg= =0qaO -----END PGP SIGNATURE----- --jnCIwN96y15MEy/K-- From lorenzo@google.com Wed Oct 23 09:11:33 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BE36911E83EC for ; Wed, 23 Oct 2013 09:11:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.94 X-Spam-Level: X-Spam-Status: No, score=-1.94 tagged_above=-999 required=5 tests=[AWL=0.037, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, 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 ltuJ+u50wc+f for ; Wed, 23 Oct 2013 09:11:33 -0700 (PDT) Received: from mail-ie0-x22a.google.com (mail-ie0-x22a.google.com [IPv6:2607:f8b0:4001:c03::22a]) by ietfa.amsl.com (Postfix) with ESMTP id BC29B11E834D for ; Wed, 23 Oct 2013 09:11:29 -0700 (PDT) Received: by mail-ie0-f170.google.com with SMTP id at1so1702055iec.1 for ; Wed, 23 Oct 2013 09:11:29 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=gpEnHoA24/B3tqLAFffFX5NQGEAAjSBIRyY5JPNNpjs=; b=KjrsdM0u/fb9CyzbR8a/mGOdP85yLpACs0GVcfSTvwiTh38rrfEgUkXaOzaFxxeHJJ jXIXdMOC5rqtBPMkMcithYhuP0GGwmlTm5/zYCmbSZk8Vg9S/6yZdGTUzARavT0sZfTz 6AXOqg2YDfp/AqBqKiIbdVYfGtdZ3iEJn+UXIeiHQGnQsmst8GBOFnkvME0s179ZBpce 4P2SLaBZRwtd7tNRNksHjn+5pBKl2HwjY+rvmdNPVlFb44algmxmF2qJCX6dVUANBpMQ oQsqVwVyhGrj/5teUFCuCt2fK9Q9cmxRVomTQoXPP2Ru1aVrEsQvcb3TCXcy8LwfaMNT 3TUg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type; bh=gpEnHoA24/B3tqLAFffFX5NQGEAAjSBIRyY5JPNNpjs=; b=JIGa8q/0ef7kABVdx4PiHKvetYbA4sOL8V4AVLYhR34IWimr9wxN4ZfxSpLIu12m8P qJNkuO+BB3d+MK47grY3Nh9eI6mtpjtIgAbCzXA3unO5vlif5DkBhdmT4UM6DLy1++VG vnbE2OFqzNvGPud59QtOkJm1MDNf/2IiMvEwHs08oRly2CM2ze7mSFMSU0/Z5Th1GznE T41U4y5OCzMxMtepHus96GqQAtNM/wMTZxh7FFNEEywR5zz3H3lEyiZx3bCWwfXuyHUn saVxmLtlcIfyM17fgIBDMPqOwLDbowTo281Ep70boRZR8SqNINB2J5QE4UiK6zjJcX9O RLBA== X-Gm-Message-State: ALoCoQkm+s53k8LXOUUi2qkSWLjZD53/SuY12URDXByeLSKMILRfSWU1aG7ak0ous72B0DvrukprCentCll1UjsXbzpUGA582u6XQYTgw1mXUOqnO/qlCnefCzKNFSQ2NUl8fRxq4v7Hnm7u2l4aHEv1dDF/hakNjrNQVZBoDSwyqd30ahu/id/JZ/hBKHEl4RU1Q0V+2vqd X-Received: by 10.50.66.163 with SMTP id g3mr1268058igt.20.1382544689242; Wed, 23 Oct 2013 09:11:29 -0700 (PDT) MIME-Version: 1.0 Received: by 10.64.86.106 with HTTP; Wed, 23 Oct 2013 09:11:09 -0700 (PDT) In-Reply-To: <5267ED12.4090602@innovationslab.net> References: <28CFF7E5-E98E-4D97-B7F4-3A18C255253C@gigix.net> <5267E96B.1000802@innovationslab.net> <20131023152549.GN50205@Space.Net> <5267EB60.7080105@innovationslab.net> <5267ED12.4090602@innovationslab.net> From: Lorenzo Colitti Date: Thu, 24 Oct 2013 01:11:09 +0900 Message-ID: To: Brian Haberman Content-Type: multipart/alternative; boundary=047d7bdca31c16cb5f04e96ac505 Cc: "v6ops@ietf.org WG" Subject: Re: [v6ops] Revised Internet Drafts for allocation of IPv6 space for LISP EIDs X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 23 Oct 2013 16:11:33 -0000 --047d7bdca31c16cb5f04e96ac505 Content-Type: text/plain; charset=ISO-8859-1 On Thu, Oct 24, 2013 at 12:36 AM, Brian Haberman wrote: > Keep in mind that the referenced draft went through IETF Last > Call and was subsequently sent back to the WG due to the concerns > raised about routing and potentially creating a parallel address registry > outside of the RIRs. > Which it's still doing, right? The block-mgmnt draft is all about creating a parallel address registry. --047d7bdca31c16cb5f04e96ac505 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
On Thu, Oct 24, 2013 at 12:36 AM, Brian Haberman <= brian@innovationslab.net> wrote:
Keep in mind that the referenced draft went through IETF L= ast
Call and was subsequently sent back to the WG due to the concerns raised=A0= about routing and potentially creating a parallel address registry
outside of the RIRs.

Which it's sti= ll doing, right? The block-mgmnt draft is all about creating a parallel add= ress registry.
--047d7bdca31c16cb5f04e96ac505-- From brian@innovationslab.net Wed Oct 23 09:12:42 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 039B311E8451 for ; Wed, 23 Oct 2013 09:12:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.539 X-Spam-Level: X-Spam-Status: No, score=-102.539 tagged_above=-999 required=5 tests=[AWL=0.060, 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 l0-pkYDiOH8S for ; Wed, 23 Oct 2013 09:12:35 -0700 (PDT) Received: from uillean.fuaim.com (uillean.fuaim.com [206.197.161.140]) by ietfa.amsl.com (Postfix) with ESMTP id CC85B11E844B for ; Wed, 23 Oct 2013 09:12:32 -0700 (PDT) Received: from clairseach.fuaim.com (clairseach-high.fuaim.com [206.197.161.158]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by uillean.fuaim.com (Postfix) with ESMTP id DF72A8810A; Wed, 23 Oct 2013 09:12:32 -0700 (PDT) Received: from 10252520.rudm1.ra.johnshopkins.edu (addr16212925014.ippl.jhmi.edu [162.129.250.14]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by clairseach.fuaim.com (Postfix) with ESMTP id 75792130003; Wed, 23 Oct 2013 09:12:32 -0700 (PDT) Message-ID: <5267F562.1040405@innovationslab.net> Date: Wed, 23 Oct 2013 12:12:18 -0400 From: Brian Haberman User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:24.0) Gecko/20100101 Thunderbird/24.0.1 MIME-Version: 1.0 To: Gert Doering References: <28CFF7E5-E98E-4D97-B7F4-3A18C255253C@gigix.net> <5267E96B.1000802@innovationslab.net> <20131023152549.GN50205@Space.Net> <5267EB60.7080105@innovationslab.net> <5267ED12.4090602@innovationslab.net> <20131023160649.GP50205@Space.Net> In-Reply-To: <20131023160649.GP50205@Space.Net> X-Enigmail-Version: 1.5.2 Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="JKQcp3tdTn7O8X11aN6l59xQbbxG0g0ik" Cc: "v6ops@ietf.org WG" Subject: Re: [v6ops] Revised Internet Drafts for allocation of IPv6 space for LISP EIDs X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 23 Oct 2013 16:12:42 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --JKQcp3tdTn7O8X11aN6l59xQbbxG0g0ik Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Hi Gert, On 10/23/13 12:06 PM, Gert Doering wrote: > Hi, >=20 > On Wed, Oct 23, 2013 at 11:36:50AM -0400, Brian Haberman wrote: >> Keep in mind that the referenced draft went through IETF Last >> Call and was subsequently sent back to the WG due to the concerns rais= ed >> about routing and potentially creating a parallel address registry >> outside of the RIRs. >=20 > These are the concerns I share, so I consider this pushback to be good > news. And no, I do not have reasonable ideas how to solve this, as=20 > I see this area as one of the hardest points in deploying LISP in a > mixed LISP-talks-to-non-LISP model. >=20 There is more to this than just the LISP-talking-to-non-LISP model. The goal is essentially to avoid a mapping lookup by having a globally assigned blocks for EIDs. It is an implementation optimization that allows a LISP router to determine that a particular IPv6 address is (or is not) reachable via LISP. Regards, Brian --JKQcp3tdTn7O8X11aN6l59xQbbxG0g0ik Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG/MacGPG2 v2.0.20 (Darwin) Comment: GPGTools - https://gpgtools.org iQEcBAEBCgAGBQJSZ/VoAAoJEBOZRqCi7goq9t0IANMHdgw1695pHoeo/3nURt9E hhfaaYfU1znQMPd0x0oFdsaMlo/Y91gjvCV0u9H8WNMlgiMHbowPB6sxUbCD3Myh zeQBgjRsb+Pgc/pz2/juBtx1wwLiu3jY6WsKQIKwb9AFLTq8Xpc1NXMSUH1NHKHQ ni3vsgBad0IV11g7vlqVfaiXgwSEHaKV8jehjiCNOxex+gJUV5e1iVCRFFw0Y3xM BPJ6kRTlCFysYAQ3ZfJbKU2qtR3XJe2GXEf2RbiyL+Zj7rlO5UEHxKhu2adoehJD EGdhFRSjXkq2R4BhS/+EEUPqcboq/NYPyKaJ6bioJ/11wF6nKQbaiTFbZzrYzAE= =h1RE -----END PGP SIGNATURE----- --JKQcp3tdTn7O8X11aN6l59xQbbxG0g0ik-- From gert@space.net Wed Oct 23 09:14:38 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 29D3711E834D for ; Wed, 23 Oct 2013 09:14:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.382 X-Spam-Level: X-Spam-Status: No, score=-2.382 tagged_above=-999 required=5 tests=[AWL=0.217, 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 13hHx4Q1Krpd for ; Wed, 23 Oct 2013 09:14:37 -0700 (PDT) Received: from mobil.space.net (mobil.space.net [IPv6:2001:608:2:81::67]) by ietfa.amsl.com (Postfix) with ESMTP id 6FA9111E81C5 for ; Wed, 23 Oct 2013 09:14:31 -0700 (PDT) Received: from mobil.space.net (localhost [127.0.0.1]) by mobil.space.net (Postfix) with ESMTP id 90924608DB for ; Wed, 23 Oct 2013 18:14:30 +0200 (CEST) X-SpaceNet-Relay: true Received: from moebius3.space.net (moebius3.Space.Net [IPv6:2001:608:2:2::250]) by mobil.space.net (Postfix) with ESMTPS id 6DC57608C2 for ; Wed, 23 Oct 2013 18:14:30 +0200 (CEST) Received: (qmail 36090 invoked by uid 1007); 23 Oct 2013 18:14:30 +0200 Date: Wed, 23 Oct 2013 18:14:30 +0200 From: Gert Doering To: Brian Haberman Message-ID: <20131023161430.GQ50205@Space.Net> References: <28CFF7E5-E98E-4D97-B7F4-3A18C255253C@gigix.net> <5267E96B.1000802@innovationslab.net> <20131023152549.GN50205@Space.Net> <5267EB60.7080105@innovationslab.net> <5267ED12.4090602@innovationslab.net> <20131023160649.GP50205@Space.Net> <5267F562.1040405@innovationslab.net> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="0jdOO2+ODOkP2/E4" Content-Disposition: inline In-Reply-To: <5267F562.1040405@innovationslab.net> X-NCC-RegID: de.space User-Agent: Mutt/1.5.21 (2010-09-15) Cc: "v6ops@ietf.org WG" Subject: Re: [v6ops] Revised Internet Drafts for allocation of IPv6 space for LISP EIDs X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 23 Oct 2013 16:14:38 -0000 --0jdOO2+ODOkP2/E4 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Hi, On Wed, Oct 23, 2013 at 12:12:18PM -0400, Brian Haberman wrote: > There is more to this than just the LISP-talking-to-non-LISP model. The > goal is essentially to avoid a mapping lookup by having a globally > assigned blocks for EIDs. It is an implementation optimization that > allows a LISP router to determine that a particular IPv6 address is (or > is not) reachable via LISP. Yeah, but having a set-aside block for LISP is actually something I could live with. The "it will leak to routing, create 'interesting' connectivity issues to non-LISP and, and will fully confuse people on where to get their IPv6 addresses from" is more what I'm worried about... Gert Doering -- NetMaster --=20 have you enabled IPv6 on something today...? SpaceNet AG Vorstand: Sebastian v. Bomhard Joseph-Dollinger-Bogen 14 Aufsichtsratsvors.: A. Grundner-Culemann D-80807 Muenchen HRB: 136055 (AG Muenchen) Tel: +49 (0)89/32356-444 USt-IdNr.: DE813185279 --0jdOO2+ODOkP2/E4 Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.15 (FreeBSD) iQIVAwUBUmf15t9WwGXkzn/FAQIU+BAAjoc3OyEHOjIw9J5W57IPry5yxJL0djuk feaYS2d6pP+P0urjld6m+4ZCgeDLMH6xO9ZXoqulp6MihUnojHGxDNTKiNhbK0BO x3hSKaGYKiV75WY9J/uLhHkGkkSWAWjDn9VXaTWap354DJVJypuWkjgBbZBsefG2 Ve2ToXv3zlBw/tMLw1Icjh+04YbNRLUmkfYoc3nMj1T6UBSz7kiSLd6c1oEi0TF7 a5rDpUiYIUdVFH+0WYdMiAVDQodSkdoxxII0vXJwjkTuXQ9R6RCGzWNwAHLAhO5v MXJey2R3ocb9YB4+Oc9M3oIl+EP57pcit93p6WmCCHBlO/20/D4E9N8lqHhOWPpg N71vXpTpa0gZUpfKnfc6Aei8MqU3FsKkA0K1GypOF0ZX0Jvxo6Blm4AHG8rYGf1N 1eQEgxDstWLnvf10mdTByGpmyUUuLKLkidoip9hWsK8RqfAwCmnGDy/xhVuYKWHl AkDadc/wly3pCZgcwiTDFx0ZpTEdMOlS9TfD5CKJdf5sxu3iKB8IlqTCz0Q34Woa kFbBgM/pqgeXPkcLfHXHUi1lmI9lBV15xevAazMAztcVvlV2RKmNQ0b3yCRrLMzP 7318QhMham0+Xx1+EK5J1CmgPd2ER1tqHJxJtFpVARQ9qzuj8Pr5SSQIv9k1QqrW difK/pXCb04= =yeDu -----END PGP SIGNATURE----- --0jdOO2+ODOkP2/E4-- From brian@innovationslab.net Wed Oct 23 09:15:26 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 855E211E8436 for ; Wed, 23 Oct 2013 09:15:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.549 X-Spam-Level: X-Spam-Status: No, score=-102.549 tagged_above=-999 required=5 tests=[AWL=0.050, 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 uzRToGFtcsrf for ; Wed, 23 Oct 2013 09:15:20 -0700 (PDT) Received: from uillean.fuaim.com (uillean.fuaim.com [206.197.161.140]) by ietfa.amsl.com (Postfix) with ESMTP id C1F6221E808A for ; Wed, 23 Oct 2013 09:15:03 -0700 (PDT) Received: from clairseach.fuaim.com (clairseach-high.fuaim.com [206.197.161.158]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by uillean.fuaim.com (Postfix) with ESMTP id 9FA6E8810A; Wed, 23 Oct 2013 09:15:03 -0700 (PDT) Received: from 10252520.rudm1.ra.johnshopkins.edu (addr16212925014.ippl.jhmi.edu [162.129.250.14]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by clairseach.fuaim.com (Postfix) with ESMTP id 397AD130003; Wed, 23 Oct 2013 09:15:03 -0700 (PDT) Message-ID: <5267F5FF.60907@innovationslab.net> Date: Wed, 23 Oct 2013 12:14:55 -0400 From: Brian Haberman User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:24.0) Gecko/20100101 Thunderbird/24.0.1 MIME-Version: 1.0 To: Lorenzo Colitti References: <28CFF7E5-E98E-4D97-B7F4-3A18C255253C@gigix.net> <5267E96B.1000802@innovationslab.net> <20131023152549.GN50205@Space.Net> <5267EB60.7080105@innovationslab.net> <5267ED12.4090602@innovationslab.net> In-Reply-To: X-Enigmail-Version: 1.5.2 Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="xmgXPJh2IkoxPFCGI2nGDBKCAcTNaQdax" Cc: "v6ops@ietf.org WG" Subject: Re: [v6ops] Revised Internet Drafts for allocation of IPv6 space for LISP EIDs X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 23 Oct 2013 16:15:26 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --xmgXPJh2IkoxPFCGI2nGDBKCAcTNaQdax Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Lorenzo, On 10/23/13 12:11 PM, Lorenzo Colitti wrote: > On Thu, Oct 24, 2013 at 12:36 AM, Brian Haberman > wrote: >=20 >> Keep in mind that the referenced draft went through IETF Last >> Call and was subsequently sent back to the WG due to the concerns >> raised about routing and potentially creating a parallel address regis= try >> outside of the RIRs. >> >=20 > Which it's still doing, right? The block-mgmnt draft is all about creat= ing > a parallel address registry. >=20 Yes. The creation of the block-mgmnt draft was driven by the feedback received during the IETF Last Call that it was unclear how they would manage an allocation. Regards, Brian --xmgXPJh2IkoxPFCGI2nGDBKCAcTNaQdax Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG/MacGPG2 v2.0.20 (Darwin) Comment: GPGTools - https://gpgtools.org iQEcBAEBCgAGBQJSZ/X/AAoJEBOZRqCi7goqdVgIAKXf8/ytzAuMSn7uGYXy7I+g EVyvSR582SOca/yPUWHlchMZBCJAqTyb6tAP8LzgxsBIHbM0n/glggLp4YySdNxc gIy0ulrHbRpgYecHrK4KdKJKavsbZjySNyig1I6AXn34WiaysM2qc+72UIB4cbpy TyPHCBZWiE/oW9ucW04KiI2LgtpLhVwMRqrhZqUEg/qr1WjietzY/unATcqoo5fF 0i3zuMKKJw+cm1Nt9Zcx2pKz/6rcBkJ9dllr6mziJ4yH1SmVVwstF/QxTNvWOAR6 FISONMh31fVER7T9KTHRlhfGXBzU2B9XrKqBcU6NnSGvdCZUq+0gQDPFKhHL+K8= =q6ig -----END PGP SIGNATURE----- --xmgXPJh2IkoxPFCGI2nGDBKCAcTNaQdax-- From jinmei.tatuya@gmail.com Wed Oct 23 11:15:47 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CB15111E8145 for ; Wed, 23 Oct 2013 11:15:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.222 X-Spam-Level: * X-Spam-Status: No, score=1.222 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, CHARSET_FARAWAY_HEADER=3.2, FM_FORGED_GMAIL=0.622, 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 dl78NILNQ4yG for ; Wed, 23 Oct 2013 11:15:47 -0700 (PDT) Received: from mail-wi0-x22d.google.com (mail-wi0-x22d.google.com [IPv6:2a00:1450:400c:c05::22d]) by ietfa.amsl.com (Postfix) with ESMTP id 13FBA11E8208 for ; Wed, 23 Oct 2013 11:15:46 -0700 (PDT) Received: by mail-wi0-f173.google.com with SMTP id ey11so7823785wid.12 for ; Wed, 23 Oct 2013 11:15:46 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type:content-transfer-encoding; bh=l3SYt5l3BOgcQpHPyZXxpuXG2cUC7g9cdv0swDhj7JY=; b=O/m4P1jMqCiV5ytqGxqVZP6E5+eTusaM24mxe0Fb3YC0Q5eszQMzaVZqauKb+wGqEI VOyorBMhHqBQSyMP1juu8eSHmvrR6WLCEDBn5YG4WfNPZkRlUqdz3MwrA06x4i2jjj19 XQ4+vL18gqSps5CcrydfA5V6nSkIWWBeLZZlfeF0+tiGP2CJmJV5rhJSB5yiZnMmNpT4 rVx8b6+9OxnoQQb7kYf/ecFKJjW8fgS+nGEkd+EuMfX+p9+2p4TM3WnABsyGr3wBxL0W FcElf9+/4kx9+7shDMaRGFhAl4WEoK+hJjf++7QUt3mScpwF+ERyJNHz9df8smmrCdNe TDBQ== MIME-Version: 1.0 X-Received: by 10.194.108.164 with SMTP id hl4mr2833801wjb.62.1382552146382; Wed, 23 Oct 2013 11:15:46 -0700 (PDT) Sender: jinmei.tatuya@gmail.com Received: by 10.194.120.167 with HTTP; Wed, 23 Oct 2013 11:15:46 -0700 (PDT) In-Reply-To: <55F2A998-0417-4C19-B248-AA2A80EBF29C@cisco.com> References: <201310211245.r9LCj0B29668@ftpeng-update.cisco.com> <8AE0F17B87264D4CAC7DE0AA6C406F453D7CC14B@nkgeml506-mbx.china.huawei.com> <1382469405.56346.YahooMailNeo@web142504.mail.bf1.yahoo.com> <1382519509.39565.YahooMailNeo@web142502.mail.bf1.yahoo.com> <55F2A998-0417-4C19-B248-AA2A80EBF29C@cisco.com> Date: Wed, 23 Oct 2013 11:15:46 -0700 X-Google-Sender-Auth: IqyuESFL_ZPdMPqbE-NnKwhrUHk Message-ID: From: =?ISO-2022-JP?B?GyRCP0BMQEMjOkgbKEI=?= To: "Ole Troan (otroan)" Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: "v6ops@ietf.org" , "draft-liu-bonica-v6ops-dhcpv6-slaac-problem@tools.ietf.org" Subject: Re: [v6ops] DHCPv6/SLAAC Make Hosts Confusing-//RE: new draft: draft-liu-bonica-v6ops-dhcpv6-slaac-problem X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 23 Oct 2013 18:15:47 -0000 At Wed, 23 Oct 2013 09:21:21 +0000, "Ole Troan (otroan)" wrote: > A single address does not have a mask. > DHCP gives out addresses, not prefixes that can be used for onlink determ= ination. True, and this would mean that a /128 prefix is implicitly assumed for a host implementation that manages addresses with a corresponding netmask/prefix length, such as BSD variants. But that can be implementation dependent, and IIRC the ISC DHCPv6 client unconditionally uses a /64 prefix when it configures a host's interface with the address assigned via DHCPv6. > > My question was more specificaly about you using "/128", rather than "a= n address" or "a single address", because I wondered if the DHCPv6 server s= upplies a /128 prefix length and the host configures a /128 prefix length o= n the address. > > > > As you say below, address prefix length doesn't indicate on-link or off= -link presence. So I'd expect a DHCPv6 server to hand out single IPv6 addre= sses with a /64 prefix length, as I think that would be more consistent and= more expected when the subnet's prefix length is /64. > > > > For somebody with a IPv4 experience, who wasn't aware an IPv6 prefix le= ngth doesn't indicate on-link presence, I think the use of a /128 prefix le= ngth in this scenario would imply that prefix length does indicate on-link = presence. Somewhat pedantic perhaps, however I think anything that may give= false indications of IPv6's behaviour, when it is different to IPv4's, is = better to avoid. I guess this point is related to this change in RFC 4861: o Removed the on-link assumption in Section 5.2 based on RFC 4942, "IPv6 Neighbor Discovery On-Link Assumption Considered Harmful". In RFC 2461, if no router (in this context, a node that sends out RAs) is available, all addresses should be considered on-link. So it didn't matter whether a DHCPv6 client chose a /64 or /128 or whatever prefix. With the change of RFC 4861, however, there can be a real interoperability issue if it's a router-less network. Again, IIRC, that was the main reason why the ISC implementation used a /64 prefix. Maybe we should also clarify these points as we want to clarify other matters regarding RA/DHCPv6 interactions such as A/M/O flags. -- JINMEI, Tatuya From lorenzo@google.com Wed Oct 23 11:21:55 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D4D6D11E8406 for ; Wed, 23 Oct 2013 11:21:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.931 X-Spam-Level: X-Spam-Status: No, score=-1.931 tagged_above=-999 required=5 tests=[AWL=0.046, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, 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 I0eFPv1kOaAa for ; Wed, 23 Oct 2013 11:21:55 -0700 (PDT) Received: from mail-ie0-x229.google.com (mail-ie0-x229.google.com [IPv6:2607:f8b0:4001:c03::229]) by ietfa.amsl.com (Postfix) with ESMTP id 5F08F11E83ED for ; Wed, 23 Oct 2013 11:21:55 -0700 (PDT) Received: by mail-ie0-f169.google.com with SMTP id ar20so1988194iec.14 for ; Wed, 23 Oct 2013 11:21:55 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=T0k6h7cWgniErs3M4ibxwAzCuVXbdfMOTCf+PSHvXsk=; b=WjoYHbhG6AKb+osD628PioRTc1t2S0LxOUd37d0bSRz4zjKMfBfh58QPWk/rQw24qX v67IqfXOwkOsUPXK8vUuf0oCOvpOJ7Mk/7o0BGMR17gSAylDehUogt5VlBz1wLuBURXS VWnV62HAwuMgy9DffbMz7uOZ7XXe/84bpuyqR1KClUyAsa7hCfnzk9P50earAkmRPu/g VYW7R+tQ0LJiXbS52ab5ffZdeT2nuad+xbcTFecw1664RPrQQRfYPZrehw2dWLcjHAa4 +24Vir6Kzv29gyegJiHVncziAw5z1z9zMz6YC0ttO3QV1zSBMwJJ3EbVSJ4CGxmB9C5V tKUg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type; bh=T0k6h7cWgniErs3M4ibxwAzCuVXbdfMOTCf+PSHvXsk=; b=SWG4KfnmgGImYsM6pSSjYdedhOG4CRxPuzmJxoI2g901wIbvkh8/ZMvhMntazdnrqQ 3l+vj4BS9gmryN2FpEbd61s1lfw4NKkqiJAK2dPkwswblkGD/zVprZn32gP417cj4UVk sZQDX96G9EN1UKz7ryoiIOF/I467u4j5eLRlnNdKP3GnB+1tNhcLrdlUxd/2IwiG8V68 TZNfNlMbjPCV2oJoLHANd3W+ZkzbsYlf6bFXMmvftvGC2da1+AzHp7lqYu4ihFuhgBl2 Ww/kpkxPv+qSTXl8fXux52yN18WerXsM1bqJWhh4LAsou2GjcmyBYamkEbCOOJ9iQx1d m+lw== X-Gm-Message-State: ALoCoQkg1CH/1JANrMsHPwk4ziC5n6snP3zsLkva3arR3rUbzM0f8fk9w7vFPU3Dz7RBsTtHCl530/l/MB0piBDoyHB0xDkGAn4bxtKWQhD6oNywZmFJwK4suRoIcHNdC9XVfW5/C8XlN6wY0X4B1RPISkOEc74zSiQyj4AcSUmTLi4Ov6eS7XiiwLhgzYAfEyB5aWtaNocO X-Received: by 10.50.66.163 with SMTP id g3mr1561946igt.20.1382552514987; Wed, 23 Oct 2013 11:21:54 -0700 (PDT) MIME-Version: 1.0 Received: by 10.64.86.106 with HTTP; Wed, 23 Oct 2013 11:21:34 -0700 (PDT) In-Reply-To: <20131023.122008.74708818.sthaug@nethelp.no> References: <1382519509.39565.YahooMailNeo@web142502.mail.bf1.yahoo.com> <55F2A998-0417-4C19-B248-AA2A80EBF29C@cisco.com> <52679F9F.7040403@inex.ie> <20131023.122008.74708818.sthaug@nethelp.no> From: Lorenzo Colitti Date: Thu, 24 Oct 2013 03:21:34 +0900 Message-ID: To: sthaug@nethelp.no Content-Type: multipart/alternative; boundary=047d7bdca31c8a328004e96c97cf Cc: "v6ops@ietf.org WG" , "Ole Troan \(otroan\)" , draft-liu-bonica-v6ops-dhcpv6-slaac-problem@tools.ietf.org Subject: Re: [v6ops] DHCPv6/SLAAC Make Hosts Confusing-//RE: new draft: draft-liu-bonica-v6ops-dhcpv6-slaac-problem X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 23 Oct 2013 18:21:55 -0000 --047d7bdca31c8a328004e96c97cf Content-Type: text/plain; charset=ISO-8859-1 On Wed, Oct 23, 2013 at 7:20 PM, wrote: > > and if dhcpv6 gave out netmasks and default gateways, we could finally > > ditch RA. I look forward to the day when I can finally expunge RA from > my > > networks. > > Amen. But it doesn't look like this is going to happen any time soon... > And then what? Rely on client polling to before you can change any network parameter, ever? Be forced to run things like VRRP because you can never change anything on the hosts? Sure that's the way we do it today in IPv4. But is it the best way? Maybe in an enterprise, but in a home? What happens when your precious "DHCPv6 server" (home router) gets unplugged by the user and all the hosts are dead in the water until they decide to send another DHCPv6 request, even though there are 3 other routers and DHCPv6 servers on the same link? --047d7bdca31c8a328004e96c97cf Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
On Wed, Oct 23, 2013 at 7:20 PM, <sthaug@nethelp.no&= gt; wrote:
=
> and if dhcpv6 gave out netmasks and default gateways= , we could finally
> ditch RA. =A0I look forward to the day when I can finally expunge RA f= rom my
> networks.

Amen. But it doesn't look like this is going to happen any time s= oon...

And then what? Rely on client po= lling to before you can change any network parameter, ever? Be forced to ru= n things like VRRP because you can never change anything on the hosts?

Sure that's the way we do it today in IPv4. But is = it the best way? Maybe in an enterprise, but in a home? What happens when y= our precious "DHCPv6 server" (home router) gets unplugged by the = user and all the hosts are dead in the water until they decide to send anot= her DHCPv6 request, even though there are 3 other routers and DHCPv6 server= s on the same link?
--047d7bdca31c8a328004e96c97cf-- From swmike@swm.pp.se Wed Oct 23 11:50:52 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B8A2811E8156 for ; Wed, 23 Oct 2013 11:50:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, 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 d6TlHVsseFAB for ; Wed, 23 Oct 2013 11:50:52 -0700 (PDT) Received: from uplift.swm.pp.se (ipv6.swm.pp.se [IPv6:2a00:801::f]) by ietfa.amsl.com (Postfix) with ESMTP id 7051411E810B for ; Wed, 23 Oct 2013 11:50:45 -0700 (PDT) Received: by uplift.swm.pp.se (Postfix, from userid 501) id 7CD2A9C; Wed, 23 Oct 2013 20:50:43 +0200 (CEST) Received: from localhost (localhost [127.0.0.1]) by uplift.swm.pp.se (Postfix) with ESMTP id 5DF359A; Wed, 23 Oct 2013 20:50:43 +0200 (CEST) Date: Wed, 23 Oct 2013 20:50:43 +0200 (CEST) From: Mikael Abrahamsson To: =?ISO-2022-JP?Q?=1B$B=3F=40L=40C#=3AH=1B=28J?= In-Reply-To: Message-ID: References: <201310211245.r9LCj0B29668@ftpeng-update.cisco.com> <8AE0F17B87264D4CAC7DE0AA6C406F453D7CC14B@nkgeml506-mbx.china.huawei.com> <1382469405.56346.YahooMailNeo@web142504.mail.bf1.yahoo.com> <1382519509.39565.YahooMailNeo@web142502.mail.bf1.yahoo.com> <55F2A998-0417-4C19-B248-AA2A80EBF29C@cisco.com> User-Agent: Alpine 2.02 (DEB 1266 2009-07-14) Organization: People's Front Against WWW MIME-Version: 1.0 Content-Type: MULTIPART/MIXED; BOUNDARY="-137064504-1772504458-1382554243=:1838" Cc: "v6ops@ietf.org" , "draft-liu-bonica-v6ops-dhcpv6-slaac-problem@tools.ietf.org" Subject: Re: [v6ops] DHCPv6/SLAAC Make Hosts Confusing-//RE: new draft: draft-liu-bonica-v6ops-dhcpv6-slaac-problem X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 23 Oct 2013 18:50:52 -0000 This message is in MIME format. The first part should be readable text, while the remaining parts are likely unreadable without MIME-aware tools. ---137064504-1772504458-1382554243=:1838 Content-Type: TEXT/PLAIN; charset=ISO-2022-JP; format=flowed On Wed, 23 Oct 2013, $B?@L@C#:H(J wrote: > implementation dependent, and IIRC the ISC DHCPv6 client > unconditionally uses a /64 prefix when it configures a host's > interface with the address assigned via DHCPv6. Are you sure? I don't know what Ubuntu uses, but I have successfully gotten it to just get a single IA_NA + default gw, no /64 on the interface. -- Mikael Abrahamsson email: swmike@swm.pp.se ---137064504-1772504458-1382554243=:1838-- From markzzzsmith@yahoo.com.au Wed Oct 23 12:09:50 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6292111E834F for ; Wed, 23 Oct 2013 12:09:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.324 X-Spam-Level: X-Spam-Status: No, score=-1.324 tagged_above=-999 required=5 tests=[AWL=0.175, BAYES_00=-2.599, FROM_LOCAL_NOVOWEL=0.5, J_CHICKENPOX_13=0.6] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IDLSf80GDZsT for ; Wed, 23 Oct 2013 12:09:43 -0700 (PDT) Received: from nm49-vm3.bullet.mail.bf1.yahoo.com (nm49-vm3.bullet.mail.bf1.yahoo.com [216.109.115.190]) by ietfa.amsl.com (Postfix) with ESMTP id E536111E81DF for ; Wed, 23 Oct 2013 12:09:42 -0700 (PDT) Received: from [98.139.215.141] by nm49.bullet.mail.bf1.yahoo.com with NNFMP; 23 Oct 2013 19:09:42 -0000 Received: from [98.139.212.196] by tm12.bullet.mail.bf1.yahoo.com with NNFMP; 23 Oct 2013 19:09:42 -0000 Received: from [127.0.0.1] by omp1005.mail.bf1.yahoo.com with NNFMP; 23 Oct 2013 19:09:42 -0000 X-Yahoo-Newman-Property: ymail-3 X-Yahoo-Newman-Id: 215623.87756.bm@omp1005.mail.bf1.yahoo.com Received: (qmail 15827 invoked by uid 60001); 23 Oct 2013 19:09:42 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com.au; s=s1024; t=1382555382; bh=z3UPXsIumBqJJS1Fgz0robaqAWeRxijbi3r0ce2c8Oc=; h=X-YMail-OSG:Received:X-Rocket-MIMEInfo:X-Mailer:References:Message-ID:Date:From:Reply-To:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type:Content-Transfer-Encoding; b=5UT2iqB4BdtO8ir/tFjZtBfhynJr/mV1ImDfpa3VBdFb3LKsw1dtRxJLlHwCQX7HgseX7KGCEpG9vbrWZqpPVNJj6b6MuZ+/ag6EPGqJZdNbj9d3F4wwRVlMuT7OT/4wkcrHRGb0eP1PIgIaNe0LCWFMgrBE9tpstja0Jivxa0A= DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com.au; h=X-YMail-OSG:Received:X-Rocket-MIMEInfo:X-Mailer:References:Message-ID:Date:From:Reply-To:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type:Content-Transfer-Encoding; b=zJnpYN6h0epdXmay0kJ3j5Y9zStCGn5Fr1yLf+EpkOzoTujEPtlWDL6DH4paGQux+ZzRoGmo3MKIzpJKmRlkodjWBbRHqE8sbIvJeFm/oQq2RU39J/5HjosdGLdvQ/pyfDe3+35IxmOQtjNeU3KX8Uu1ZmzCSD83HPchsA8MClg=; X-YMail-OSG: ZHUT_0oVM1mLZHmvoLs0JatBXq3dVdUd0Bdw2QAO.tWZYq9 rT.4lLetViR5DG3afiPH0uemTWZ8mr0javF7AR5eKhPQIKfkwIbHDtj31DLa GFIh6cZtbIkFQKkIYj_NL..nT4taTFclaW.BxyymUVY60eIXc0n.o5cj8eVJ Qn0bALT7Smumo4sU_U7FR029IVDGqy2nKTzIGzg.wkq8fzEAgKJZqIGNj4jA 3wCuZrLJh1rVno8ttgTXRqJ._IOnS9q5ec6vHxqr1IWAHmm0gTUsUogd_EzH aRfT7VL.tyDw9Wzy3FhS0LuhvLnY23FD1c5z1hA0nP7G7STkOO8Hb91mQmYN QapppXB29MerqOfo2982X6jVhlbEmTSO2tFOZRaSKBW5qt3y4THWH_Kdj3sd Igzl2ikGzeGONmOxWhkgX6TBzPGB_vDSBvzSKI2HMM5XS4zkFRxg5jVNPjvb Qt7LJeDrrlWPtP_88rtxjidy_cP9CLiE4nqHiEs7nnVDoTp7G2hXsr18vutC szl234iX_0zM3S32pi7nbOn1Sm0VinHqUp1DqcVilG0PbKFk1oi5cOX4eCxh 9ksINBAjx7dzvWjluzpCeQQNhPmQKfchedTqD069DPRMw Received: from [150.101.221.237] by web142505.mail.bf1.yahoo.com via HTTP; Wed, 23 Oct 2013 12:09:41 PDT X-Rocket-MIMEInfo: 002.001, CgoKCi0tLS0tIE9yaWdpbmFsIE1lc3NhZ2UgLS0tLS0KPiBGcm9tOiBPbGUgVHJvYW4gKG90cm9hbikgPG90cm9hbkBjaXNjby5jb20.Cj4gVG86IE1hcmsgWlpaIFNtaXRoIDxtYXJrenp6c21pdGhAeWFob28uY29tLmF1Pgo.IENjOiBNaWthZWwgQWJyYWhhbXNzb24gPHN3bWlrZUBzd20ucHAuc2U.OyAidjZvcHNAaWV0Zi5vcmciIDx2Nm9wc0BpZXRmLm9yZz47ICJkcmFmdC1saXUtYm9uaWNhLXY2b3BzLWRoY3B2Ni1zbGFhYy1wcm9ibGVtQHRvb2xzLmlldGYub3JnIiA8ZHJhZnQtbGl1LWJvbmljYS12Nm8BMAEBAQE- X-Mailer: YahooMailWebService/0.8.160.587 References: <201310211245.r9LCj0B29668@ftpeng-update.cisco.com> <8AE0F17B87264D4CAC7DE0AA6C406F453D7CC14B@nkgeml506-mbx.china.huawei.com> <1382469405.56346.YahooMailNeo@web142504.mail.bf1.yahoo.com> <1382519509.39565.YahooMailNeo@web142502.mail.bf1.yahoo.com> <55F2A998-0417-4C19-B248-AA2A80EBF29C@cisco.com> Message-ID: <1382555381.11936.YahooMailNeo@web142505.mail.bf1.yahoo.com> Date: Wed, 23 Oct 2013 12:09:41 -0700 (PDT) From: Mark ZZZ Smith To: "Ole Troan \(otroan\)" In-Reply-To: <55F2A998-0417-4C19-B248-AA2A80EBF29C@cisco.com> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Cc: "v6ops@ietf.org" , "draft-liu-bonica-v6ops-dhcpv6-slaac-problem@tools.ietf.org" Subject: Re: [v6ops] DHCPv6/SLAAC Make Hosts Confusing-//RE: new draft: draft-liu-bonica-v6ops-dhcpv6-slaac-problem X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: Mark ZZZ Smith List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 23 Oct 2013 19:09:52 -0000 =0A=0A=0A=0A----- Original Message -----=0A> From: Ole Troan (otroan) =0A> To: Mark ZZZ Smith =0A> Cc: Mi= kael Abrahamsson ; "v6ops@ietf.org" ; "dr= aft-liu-bonica-v6ops-dhcpv6-slaac-problem@tools.ietf.org" =0A> Sent: Wednesday, 23 October= 2013 8:21 PM=0A> Subject: Re: [v6ops] DHCPv6/SLAAC Make Hosts Confusing-//= RE: new draft: draft-liu-bonica-v6ops-dhcpv6-slaac-problem=0A> =0A> A singl= e address does not have a mask. =0A> DHCP gives out addresses, not prefixes= that can be used for onlink =0A> determination. =0A>=A0=0A=0AThat makes it= clearer. There was no need for=A0Mikael=A0to use "/128", which to me impli= ed that the DHCPv6 server conveyed a prefix length when handing out address= es, and that a specific /128 prefix length mattered to=A0Mikael, which is w= hy I asked the question.=0A=0AThanks,=0AMark.=0A=0A> Cheers,=0A> Ole=0A> = =0A>> On 23 Oct 2013, at 11:11, Mark ZZZ Smith = =0A> wrote:=0A>> =0A>> Hi,=0A>> =0A>> =0A>> ----- Original Message -----= =0A>>> From: Mikael Abrahamsson =0A>>> To: Mark ZZZ Smi= th =0A>>> Cc: Liubing (Leo) ; =0A> "v6ops@ietf.org" ; =0A> "draft-liu-bonica-v6ops= -dhcpv6-slaac-problem@tools.ietf.org" =0A> =0A>>> Sent: Wednesday, 23 October 2013 2:40 P= M=0A>>> Subject: Re: [v6ops] DHCPv6/SLAAC Make Hosts Confusing-//RE: new d= raft: =0A> draft-liu-bonica-v6ops-dhcpv6-slaac-problem=0A>>> =0A>>>> On Tu= e, 22 Oct 2013, Mark ZZZ Smith wrote:=0A>>>> =0A>>>> =A0 Is this saying th= at the prefix length of the address on host is =0A> /128?=0A>>> =0A>>> A s= ingle address is always a /128. This /128 can be part of an on-link =0A>>> = other network, or it isn't.=0A>> =0A>> My question was more specificaly a= bout you using "/128", rather =0A> than "an address" or "a single address",= because I wondered =0A> if the DHCPv6 server supplies a /128 prefix length= and the host configures a =0A> /128 prefix length on the address.=0A>> =0A= >> As you say below, address prefix length doesn't indicate on-link or =0A= > off-link presence. So I'd expect a DHCPv6 server to hand out single IPv6 = =0A> addresses with a /64 prefix length, as I think that would be more cons= istent and =0A> more expected when the subnet's prefix length is /64.=0A>> = =0A>> For somebody with a IPv4 experience, who wasn't aware an IPv6 prefix= =0A> length doesn't indicate on-link presence, I think the use of a /128 p= refix =0A> length in this scenario would imply that prefix length does indi= cate on-link =0A> presence. Somewhat pedantic perhaps, however I think anyt= hing that may give =0A> false indications of IPv6's behaviour, when it is d= ifferent to IPv4's, =0A> is better to avoid.=0A>> =0A>> =0A>> Regards,=0A>= > Mark.=0A>> =0A>>>> =A0 If that is the case, as the prefix length in doe= sn't indicate =0A> on-link=0A>>> or =0A>>>> =A0 off-link status (as RA PI= Os do), is there any specific reason for =0A> the =0A>>>> =A0 prefix lengt= h the DHCPv6 server hands out to be /128 instead of =0A> the =0A>>>> =A0 s= ubnet's prefix length of /64? =0A>>> =0A>>> The DHCPv6 server always hands= out /128. This /128 can be within a =0A> subnet =0A>>> advertised in RA, = or it can be outside of it. The host doesn't =0A> care. When =0A>>> a subn= et is being advertised in RA you get a network route pointing to =0A> the = =0A>>> interface without an IPv6 address as next-hop.=0A>>> =0A>>> So it'= s perfectly achievable today (and it works) to have the =0A> following:=0A>= >> =0A>>> Host gets 2001:db8:fff::1/128 from dhcp=0A>>> host gets on-link= 2001:db8:1::/64 from RA and creates a route towards =0A> the =0A>>> inter= face for this, but doesn't do SLAAC because A=3D0.=0A>>> Host gets default= route from router and installs it.=0A>>> =0A>>> Now, the *router* needs t= o understand that 2001:db8:fff::1/128 is =0A> on-link, =0A>>> but no other= hosts on the network does not.=0A>>> =0A>>> So what networks are being an= nounced in RA is completely decoupled from =0A> =0A>>> addresses handed ou= t by DHCPv6 IA_NA. It's perfectly valid to hand =0A> out a =0A>>> /128 and= then have no on-link prefixes at all, or have some with A=3D0.=0A>>> =0A>>= > =0A>>> -- =0A>>> Mikael Abrahamsson=A0 =A0 email: swmike@swm.pp.se=0A>>= _______________________________________________=0A>> v6ops mailing list= =0A> =0A>> v6ops@ietf.org=0A>> https://www.ietf.org/mailman/listinfo/v6op= s=0A> From jinmei.tatuya@gmail.com Wed Oct 23 12:12:32 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8FBEE11E8358 for ; Wed, 23 Oct 2013 12:12:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.222 X-Spam-Level: * X-Spam-Status: No, score=1.222 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, CHARSET_FARAWAY_HEADER=3.2, FM_FORGED_GMAIL=0.622, 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 oKgHmzrufcRa for ; Wed, 23 Oct 2013 12:12:32 -0700 (PDT) Received: from mail-wi0-x233.google.com (mail-wi0-x233.google.com [IPv6:2a00:1450:400c:c05::233]) by ietfa.amsl.com (Postfix) with ESMTP id DAA1711E8353 for ; Wed, 23 Oct 2013 12:12:29 -0700 (PDT) Received: by mail-wi0-f179.google.com with SMTP id hm4so1424458wib.12 for ; Wed, 23 Oct 2013 12:12:29 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type; bh=ZwIzIh0tcXY1qE/A+79EjpiqHurMwXKdueomtNde34Q=; b=XjrSSIit3Lf/benJYAkRcR2RcLg5/THwVyf9LrAPJ3KrwHqIYSfG2mEinj29t++ksX jfYxe6ebOVJk6UBVtHEqbEu2o1VWIkWq60/tDyNpvCysryE/e06lq01qhDucF3dW8SwC 5+sYW1+kigm8gKjDwXm3qGP/7g5ymLkAR+Rjs8OHf5C3pLrViEEcfPkkNKoJl7md2UZb 6nYs6/OaQZVk62P5pdHWU1IRH3dR2EP+V9Zgd8zjb675x95qFuRxT+fScpgU55mSTCZR DQ9GTraNdB5PXirQmt85zjmuSNv4tl8Zuqh1IfpwzAqDxtla4ruEZQW7G+ElSMoBpc06 5IuQ== MIME-Version: 1.0 X-Received: by 10.194.9.70 with SMTP id x6mr3004722wja.22.1382555549115; Wed, 23 Oct 2013 12:12:29 -0700 (PDT) Sender: jinmei.tatuya@gmail.com Received: by 10.194.120.167 with HTTP; Wed, 23 Oct 2013 12:12:29 -0700 (PDT) In-Reply-To: References: <201310211245.r9LCj0B29668@ftpeng-update.cisco.com> <8AE0F17B87264D4CAC7DE0AA6C406F453D7CC14B@nkgeml506-mbx.china.huawei.com> <1382469405.56346.YahooMailNeo@web142504.mail.bf1.yahoo.com> <1382519509.39565.YahooMailNeo@web142502.mail.bf1.yahoo.com> <55F2A998-0417-4C19-B248-AA2A80EBF29C@cisco.com> Date: Wed, 23 Oct 2013 12:12:29 -0700 X-Google-Sender-Auth: DlIrbn7tHCxFb2q24D2SIEdxnxc Message-ID: From: =?ISO-2022-JP?B?GyRCP0BMQEMjOkgbKEI=?= To: Mikael Abrahamsson Content-Type: text/plain; charset=ISO-8859-1 Cc: "v6ops@ietf.org" , "draft-liu-bonica-v6ops-dhcpv6-slaac-problem@tools.ietf.org" Subject: Re: [v6ops] DHCPv6/SLAAC Make Hosts Confusing-//RE: new draft: draft-liu-bonica-v6ops-dhcpv6-slaac-problem X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 23 Oct 2013 19:12:32 -0000 At Wed, 23 Oct 2013 20:50:43 +0200 (CEST), Mikael Abrahamsson wrote: > > implementation dependent, and IIRC the ISC DHCPv6 client > > unconditionally uses a /64 prefix when it configures a host's > > interface with the address assigned via DHCPv6. > > Are you sure? I don't know what Ubuntu uses, but I have successfully > gotten it to just get a single IA_NA + default gw, no /64 on the > interface. I'm pretty sure at least it behaved that way before. I don't know what the very latest implementation does in this regard, but at least according to the source code it doesn't seem to change. This is a snippet of ISC DHCP 4.2.5: /* addr fields. */ if (addr != NULL) { if ((ia != NULL) && (ia->ia_type == D6O_IA_PD)) { [...] } else { /* Current practice is that all subnets are /64's, but * some suspect this may not be permanent. */ client_envadd(client, prefix, "ip6_prefixlen", "%d", 64); client_envadd(client, prefix, "ip6_address", "%s", piaddr(addr->address)); } and, e.g., in scripts/linux: ${ip} -f inet6 addr add ${new_ip6_address}/${new_ip6_prefixlen} \ dev ${interface} scope global But a specific installation of ISC DHCP could use its own client script, and it's possible that one such custom implementation just ignores (new_)ip6_prefixlen given by dhclient. (And, of course, I don't even know whether your Ubuntu client uses the ISC implementation in the first place). -- JINMEI, Tatuya From markzzzsmith@yahoo.com.au Wed Oct 23 12:21:03 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C80D911E836F for ; Wed, 23 Oct 2013 12:21:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.659 X-Spam-Level: X-Spam-Status: No, score=-1.659 tagged_above=-999 required=5 tests=[AWL=0.440, BAYES_00=-2.599, FROM_LOCAL_NOVOWEL=0.5] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RcYMhdFT3-NH for ; Wed, 23 Oct 2013 12:20:58 -0700 (PDT) Received: from nm26-vm0.bullet.mail.bf1.yahoo.com (nm26-vm0.bullet.mail.bf1.yahoo.com [98.139.213.74]) by ietfa.amsl.com (Postfix) with ESMTP id 9CFA411E8358 for ; Wed, 23 Oct 2013 12:20:57 -0700 (PDT) Received: from [98.139.214.32] by nm26.bullet.mail.bf1.yahoo.com with NNFMP; 23 Oct 2013 19:20:57 -0000 Received: from [98.139.212.224] by tm15.bullet.mail.bf1.yahoo.com with NNFMP; 23 Oct 2013 19:20:57 -0000 Received: from [127.0.0.1] by omp1033.mail.bf1.yahoo.com with NNFMP; 23 Oct 2013 19:20:57 -0000 X-Yahoo-Newman-Property: ymail-3 X-Yahoo-Newman-Id: 175627.22265.bm@omp1033.mail.bf1.yahoo.com Received: (qmail 28708 invoked by uid 60001); 23 Oct 2013 19:20:57 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com.au; s=s1024; t=1382556056; bh=mIYZXKtAQ0C0DquL+Wyf9dP+F5ULE9XQDRqccbgCVTE=; h=X-YMail-OSG:Received:X-Rocket-MIMEInfo:X-Mailer:References:Message-ID:Date:From:Reply-To:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type:Content-Transfer-Encoding; b=CMITmxtHa9S2nNb+pB6TXm4yjpjvTlKQ71J8dOnZbn8h8oa2To+bFmuF341herU360zvJGdsHzeb18foOj1nO2ysIxXjAg8007DX0mZZ93OVzMlpC84qNATweqAZ/3nrJlSBsaNOXMH0SnBEXqXSkvW10sDKUYRBsPn1YfQsDiw= DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com.au; h=X-YMail-OSG:Received:X-Rocket-MIMEInfo:X-Mailer:References:Message-ID:Date:From:Reply-To:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type:Content-Transfer-Encoding; b=VjVhzGEE0vOBoTTsesa/ifV8O7LlN8oXBi5mC8OrAPd9NsSOb0cTR9l0mr0lU9pqU/Th6ud34Y+1AQLTaFpr2CoGYjs4DtSen83yGYgip2oM2e+MOhyRytEfEMR8TU53Vre/ydbB8cykcG7euw6nbZ47P97HoMgK0eXGVoaHuYc=; X-YMail-OSG: 3jIieBcVM1krUWLePkjdUr5.RIu_K2Yu1QOWFVMlwQ0Wnfm myonvzMOsOsdEurLLKesYxMQRpF9FazLtGsDtppX8ywZW9WClKNGN.6pkfpC 0MsIoHxZXej0I0.5Fxi1zbFB8qLbfibeMWd4ThZkbe9NO4IBiMcVolR.LCuV QjA1PcdA2apaUDrzQBsvYWuuE..pnw.RDWeSJbC_67GYydloi3ma_I5ivedz L44VJsjLFhnLIVhbD4.BMiyBFEnPjs0sxDSRlnoxUs.ppwDylO7i5KBJaLMW A41Vb_VGqWlcPLt.1T7kWTNKNHpQC0e_NeiNi3NF5BsH1gnfkzYVevnGXL6f qQDFWMlGiv3iJBuhPNlC_EZCXuLj2WmLSzqk7zNn5SWafrhLNSaW6YGDxuZX PdvumL7wDni9dt7xBsyLmTdKHwuKu6dWCxhAfEn6sG4MDVJSpFXWo3EqzurM 8L.kAKQDeUUuPBlKzb8NIX0wRYfQC7SvTNsO_Wm5gBbewJw1qKEkPYUGeYVQ tmiC9Pg3wcEhMBM3HN5g32wiO0RNjYVh0YoeoF9139vfRBgoxyyMjAJcnsPe YA28yUsbjflneQnydGal3puZjZhcHMH7USQLoqF5V7w-- Received: from [150.101.221.237] by web142505.mail.bf1.yahoo.com via HTTP; Wed, 23 Oct 2013 12:20:56 PDT X-Rocket-MIMEInfo: 002.001, CgoKCi0tLS0tIE9yaWdpbmFsIE1lc3NhZ2UgLS0tLS0KPiBGcm9tOiBOaWNrIEhpbGxpYXJkIDxuaWNrQGluZXguaWU.Cj4gVG86IE9sZSBUcm9hbiAob3Ryb2FuKSA8b3Ryb2FuQGNpc2NvLmNvbT47IE1hcmsgWlpaIFNtaXRoIDxtYXJrenp6c21pdGhAeWFob28uY29tLmF1Pgo.IENjOiAidjZvcHNAaWV0Zi5vcmciIDx2Nm9wc0BpZXRmLm9yZz47ICJkcmFmdC1saXUtYm9uaWNhLXY2b3BzLWRoY3B2Ni1zbGFhYy1wcm9ibGVtQHRvb2xzLmlldGYub3JnIiA8ZHJhZnQtbGl1LWJvbmljYS12Nm9wcy1kaGNwdjYBMAEBAQE- X-Mailer: YahooMailWebService/0.8.160.587 References: <201310211245.r9LCj0B29668@ftpeng-update.cisco.com> <8AE0F17B87264D4CAC7DE0AA6C406F453D7CC14B@nkgeml506-mbx.china.huawei.com> <1382469405.56346.YahooMailNeo@web142504.mail.bf1.yahoo.com> <1382519509.39565.YahooMailNeo@web142502.mail.bf1.yahoo.com> <55F2A998-0417-4C19-B248-AA2A80EBF29C@cisco.com> <52679F9F.7040403@inex.ie> Message-ID: <1382556056.28376.YahooMailNeo@web142505.mail.bf1.yahoo.com> Date: Wed, 23 Oct 2013 12:20:56 -0700 (PDT) From: Mark ZZZ Smith To: Nick Hilliard , "Ole Troan \(otroan\)" In-Reply-To: <52679F9F.7040403@inex.ie> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Cc: "v6ops@ietf.org" , "draft-liu-bonica-v6ops-dhcpv6-slaac-problem@tools.ietf.org" Subject: Re: [v6ops] DHCPv6/SLAAC Make Hosts Confusing-//RE: new draft: draft-liu-bonica-v6ops-dhcpv6-slaac-problem X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: Mark ZZZ Smith List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 23 Oct 2013 19:21:03 -0000 =0A=0A=0A=0A----- Original Message -----=0A> From: Nick Hilliard =0A> To: Ole Troan (otroan) ; Mark ZZZ Smith =0A> Cc: "v6ops@ietf.org" ; "draft-liu-b= onica-v6ops-dhcpv6-slaac-problem@tools.ietf.org" =0A> Sent: Wednesday, 23 October 2013 9:0= 6 PM=0A> Subject: Re: [v6ops] DHCPv6/SLAAC Make Hosts Confusing-//RE: new d= raft: draft-liu-bonica-v6ops-dhcpv6-slaac-problem=0A> =0A> On 23/10/2013 17= :21, Ole Troan (otroan) wrote:=0A>> DHCP gives out addresses, not prefixes= that can be used for onlink =0A> determination. =0A> =0A> and if dhcpv6 ga= ve out netmasks and default gateways, we could finally=0A> ditch RA.=A0 I l= ook forward to the day when I can finally expunge RA from my=0A>=A0=0A=0ARA= s are prehaps misnamed. They're not really router advertisements, they're a= dvertisements (typically) sent from routers. View them as layer 3 configura= tion protocol packets, because they do far more than advertise a default ro= uter, and don't even need to advertise a default router to be useful.=0A=0A= They can be use for:=0A=0A- changing host MTUs, instead of individual manua= l configuration on each host=0A- announce on-link presence of prefixes, exc= lusive of whether hosts have addresses within the prefix,=A0instead of indi= vidual manual configuration on each host=0A- adjust neighbor discovery para= meters (e.g., timers),=A0instead of individual manual configuration on each= host=0A- announce prefix(es) to be used to generate SLAAC addresses,=A0ins= tead of individual manual configuration on each host=0A- indicate to hosts = whether to use DHCPv6 or SLAAC or both (during a transition between SLAAC/D= HCPv6 or vice-versa),=A0instead of individual manual configuration on each = host=0A- advertise a default router, and an associated lifetime,=A0instead = of individual manual configuration on each host=0A=0A=0A=0A=0A> networks.= =0A> =0A> Nick=0A> From brian.e.carpenter@gmail.com Wed Oct 23 12:27:38 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0C7C211E8204 for ; Wed, 23 Oct 2013 12:27:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.536 X-Spam-Level: X-Spam-Status: No, score=-102.536 tagged_above=-999 required=5 tests=[AWL=0.063, 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 h1ArrVEiJi-d for ; Wed, 23 Oct 2013 12:27:37 -0700 (PDT) Received: from mail-pb0-x232.google.com (mail-pb0-x232.google.com [IPv6:2607:f8b0:400e:c01::232]) by ietfa.amsl.com (Postfix) with ESMTP id 8EF3711E81CA for ; Wed, 23 Oct 2013 12:27:37 -0700 (PDT) Received: by mail-pb0-f50.google.com with SMTP id uo15so1432271pbc.9 for ; Wed, 23 Oct 2013 12:27:37 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:organization:user-agent:mime-version:to:cc :subject:references:in-reply-to:content-type :content-transfer-encoding; bh=l1/gRNpkCPIrzkWr9lMDRguvDAJQe0Pdzm3oE/F0yJI=; b=u2eDzfbqfOn4i5K/kyTSZQdlh1Jm3Mt+JPYn6BEq/gTu9r38vWmY5R1dYAf5zNbVq6 Yvx7VqcEyqQt7P1YUgqb1swKqtdpfPhKw59gKexWpsL7FYuwoKrJWdQiDnqbHM0w1I/j lAdsFPITjH6NRHkWU2iaALuKgvlI2UfWhUGOjaNw71jv4udUR5TXX46akNfBCrpeT4XM aHX7fKC585OKaVzqTAnWKEo7lGMjMt55IO/FosonO1XcOcSJ2m/M5CyDSJK4ec8lhV+u a55ROGP4Um5I0EWH0dAbUA74bqLVhDH+Z1qNnycQkelsJI4/ZFtw/z1KDTI4A1jJ+Fll 2wEw== X-Received: by 10.69.4.100 with SMTP id cd4mr3243070pbd.120.1382556457423; Wed, 23 Oct 2013 12:27:37 -0700 (PDT) Received: from [192.168.178.20] (186.201.69.111.dynamic.snap.net.nz. [111.69.201.186]) by mx.google.com with ESMTPSA id ik1sm6297317pbc.9.2013.10.23.12.27.35 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Wed, 23 Oct 2013 12:27:36 -0700 (PDT) Message-ID: <5268232A.2000805@gmail.com> Date: Thu, 24 Oct 2013 08:27:38 +1300 From: Brian E Carpenter Organization: University of Auckland User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: Brian Haberman References: <28CFF7E5-E98E-4D97-B7F4-3A18C255253C@gigix.net> <5267E96B.1000802@innovationslab.net> <20131023152549.GN50205@Space.Net> <5267EB60.7080105@innovationslab.net> <5267ED12.4090602@innovationslab.net> In-Reply-To: <5267ED12.4090602@innovationslab.net> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: "v6ops@ietf.org WG" Subject: Re: [v6ops] Revised Internet Drafts for allocation of IPv6 space for LISP EIDs X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 23 Oct 2013 19:27:38 -0000 On 24/10/2013 04:36, Brian Haberman wrote: > Hi Lorenzo, > > On 10/23/13 11:31 AM, Lorenzo Colitti wrote: >> On Thu, Oct 24, 2013 at 12:29 AM, Brian Haberman >> wrote: >> >>> "In order to provide connectivity between the Legacy Internet and LISP >>> sites, PITRs announcing large aggregates (ideally one single large >>> aggregate) of the IPv6 EID Block could be deployed." >>> >> That sounds very much like a 6to4 relay router, which experience has shown >> was an unworkable deployment model. Why is this different? >> > > It's not different. But, that is the tact the LISP WG is trying to > take. Keep in mind that the referenced draft went through IETF Last > Call and was subsequently sent back to the WG due to the concerns raised > about routing and potentially creating a parallel address registry > outside of the RIRs. I think there is one difference from the 6to4 case - well, two actually. 1. A lot of operators learnt the hard way that failing to coordinate 6to4 prefix routing between operators caused very substantial problems. (And, btw, the 6to4 RFC said that such coordination was needed.) 2. LISP has grown out of the routing community, so the need for operational coordination is presumably understood in that community. Nevertheless, the risk of a failure of coordination seems high. But then, it seemed high for BGP4 itself in 1994. Brian From jcurran@istaff.org Wed Oct 23 12:40:05 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1964111E823E for ; Wed, 23 Oct 2013 12:40:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.001, 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 G1HulTYYRFOg for ; Wed, 23 Oct 2013 12:39:53 -0700 (PDT) Received: from mho-01-ewr.mailhop.org (mho-03-ewr.mailhop.org [204.13.248.66]) by ietfa.amsl.com (Postfix) with ESMTP id C590D11E81D0 for ; Wed, 23 Oct 2013 12:39:31 -0700 (PDT) Received: from [203.153.101.244] (helo=[10.128.128.68]) by mho-01-ewr.mailhop.org with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.72) (envelope-from ) id 1VZ4HC-000FxW-Gf; Wed, 23 Oct 2013 19:39:30 +0000 X-Mail-Handler: Dyn Standard SMTP by Dyn X-Originating-IP: 203.153.101.244 X-Report-Abuse-To: abuse@dyndns.com (see http://www.dyndns.com/services/sendlabs/outbound_abuse.html for abuse reporting information) X-MHO-User: U2FsdGVkX1/fO1VyI6UF6qOKeSCSQyJB Content-Type: text/plain; charset=iso-8859-1 Mime-Version: 1.0 (Mac OS X Mail 6.6 \(1510\)) From: John Curran In-Reply-To: <5267ED12.4090602@innovationslab.net> Date: Thu, 24 Oct 2013 03:39:24 +0800 Content-Transfer-Encoding: quoted-printable Message-Id: <396D59B9-A143-447C-B3D0-C03D377222B1@istaff.org> References: <28CFF7E5-E98E-4D97-B7F4-3A18C255253C@gigix.net> <5267E96B.1000802@innovationslab.net> <20131023152549.GN50205@Space.Net> <5267EB60.7080105@innovationslab.net> <5267ED12.4090602@innovationslab.net> To: Brian Haberman X-Mailer: Apple Mail (2.1510) Cc: "v6ops@ietf.org WG" Subject: Re: [v6ops] Revised Internet Drafts for allocation of IPv6 space for LISP EIDs X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 23 Oct 2013 19:40:05 -0000 On Oct 23, 2013, at 11:36 PM, Brian Haberman = wrote: On 10/23/13 11:31 AM, Lorenzo Colitti wrote: >> That sounds very much like a 6to4 relay router, which experience has = shown >> was an unworkable deployment model. Why is this different? >=20 > It's not different. But, that is the tact the LISP WG is trying to > take. Keep in mind that the referenced draft went through IETF Last > Call and was subsequently sent back to the WG due to the concerns = raised > about routing and potentially creating a parallel address registry > outside of the RIRs. Minor nit in the above: I believe that drafts were sent back to the WG _primarily_ due to lack of detail about the "experimental" nature of the=20= proposed allocation, which made further consideration about the = potential implications rather difficult. The authors have done significant edits=20= as a result, and hence it's probably a good idea for everyone to reread the drafts and come to their own conclusion. (This is my main reason = for=20 bringing the matter to the attention to this list - I am not asserting=20= that these are wonderful drafts or that we have a problem, only that = full=20 consideration should involve a slightly larger circle of folks... :-) Thanks! /John From cb.list6@gmail.com Wed Oct 23 13:01:03 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 693CB11E820C for ; Wed, 23 Oct 2013 13:01:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.3 X-Spam-Level: X-Spam-Status: No, score=-2.3 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, J_CHICKENPOX_13=0.6, 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 QBMbsoI2s+Ph for ; Wed, 23 Oct 2013 13:01:03 -0700 (PDT) Received: from mail-we0-x22f.google.com (mail-we0-x22f.google.com [IPv6:2a00:1450:400c:c03::22f]) by ietfa.amsl.com (Postfix) with ESMTP id E2A8111E81DF for ; Wed, 23 Oct 2013 13:01:00 -0700 (PDT) Received: by mail-we0-f175.google.com with SMTP id t61so1327682wes.6 for ; Wed, 23 Oct 2013 13:01:00 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=AfoUrAjVXyZx4xUHWrWuygcnae0WuHVZ271AJF8ajU4=; b=ij4JiUvRkLtiYvYrTxiZlxWbVsJZdGlIxeVz/6ZVEMSXznvbjzyucLa5OBTL0Nm0Jg UH6HYX0h3UNEo4i51ukiNwk/3XY3cc2cejKBhynhU4shMpXSEisC8FE9d5qaF8KyaEas jws2s6KjZtBzUgD+7g55ENZJZkewUVgc9jHBFf1E8NRnAZsTuVkV0cV5P5mgmTeB8kY/ RZI3087+nkf8f2OPiPw6FnBQwiiDIgcfZLU7ixmnJStyAPmzDUclXZtHPtnuSfgK4729 Ub94k7nfgU2/ERI00LjzKyJ55+XQPXtAm4b2bD7XsBfe+4EmD+XpURbjYR8k7WM6tJm6 0V+Q== MIME-Version: 1.0 X-Received: by 10.194.235.138 with SMTP id um10mr3277398wjc.30.1382558460017; Wed, 23 Oct 2013 13:01:00 -0700 (PDT) Received: by 10.217.114.137 with HTTP; Wed, 23 Oct 2013 13:00:59 -0700 (PDT) In-Reply-To: <5268232A.2000805@gmail.com> References: <28CFF7E5-E98E-4D97-B7F4-3A18C255253C@gigix.net> <5267E96B.1000802@innovationslab.net> <20131023152549.GN50205@Space.Net> <5267EB60.7080105@innovationslab.net> <5267ED12.4090602@innovationslab.net> <5268232A.2000805@gmail.com> Date: Wed, 23 Oct 2013 13:00:59 -0700 Message-ID: From: "cb.list6" To: Brian E Carpenter Content-Type: text/plain; charset=ISO-8859-1 Cc: "v6ops@ietf.org WG" Subject: Re: [v6ops] Revised Internet Drafts for allocation of IPv6 space for LISP EIDs X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 23 Oct 2013 20:01:03 -0000 On Wed, Oct 23, 2013 at 12:27 PM, Brian E Carpenter wrote: > On 24/10/2013 04:36, Brian Haberman wrote: >> Hi Lorenzo, >> >> On 10/23/13 11:31 AM, Lorenzo Colitti wrote: >>> On Thu, Oct 24, 2013 at 12:29 AM, Brian Haberman >>> wrote: >>> >>>> "In order to provide connectivity between the Legacy Internet and LISP >>>> sites, PITRs announcing large aggregates (ideally one single large >>>> aggregate) of the IPv6 EID Block could be deployed." >>>> >>> That sounds very much like a 6to4 relay router, which experience has shown >>> was an unworkable deployment model. Why is this different? >>> >> >> It's not different. But, that is the tact the LISP WG is trying to >> take. Keep in mind that the referenced draft went through IETF Last >> Call and was subsequently sent back to the WG due to the concerns raised >> about routing and potentially creating a parallel address registry >> outside of the RIRs. > > I think there is one difference from the 6to4 case - well, two actually. > > 1. A lot of operators learnt the hard way that failing to coordinate > 6to4 prefix routing between operators caused very substantial problems. > (And, btw, the 6to4 RFC said that such coordination was needed.) > > 2. LISP has grown out of the routing community, so the need for > operational coordination is presumably understood in that community. > Maybe i am wrong, but i have an idea where LISP has grown out of, and it is not the networks operators that would have to coordinate this to work. CB > Nevertheless, the risk of a failure of coordination seems high. > But then, it seemed high for BGP4 itself in 1994. > > Brian > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops From markzzzsmith@yahoo.com.au Wed Oct 23 13:01:14 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9496711E83BB for ; Wed, 23 Oct 2013 13:01:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.732 X-Spam-Level: X-Spam-Status: No, score=-1.732 tagged_above=-999 required=5 tests=[AWL=0.367, BAYES_00=-2.599, FROM_LOCAL_NOVOWEL=0.5] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WSc-2GSje5Ot for ; Wed, 23 Oct 2013 13:01:09 -0700 (PDT) Received: from nm35-vm5.bullet.mail.bf1.yahoo.com (nm35-vm5.bullet.mail.bf1.yahoo.com [72.30.238.77]) by ietfa.amsl.com (Postfix) with ESMTP id 1304A11E83A6 for ; Wed, 23 Oct 2013 13:01:07 -0700 (PDT) Received: from [98.139.214.32] by nm35.bullet.mail.bf1.yahoo.com with NNFMP; 23 Oct 2013 20:01:07 -0000 Received: from [98.139.212.193] by tm15.bullet.mail.bf1.yahoo.com with NNFMP; 23 Oct 2013 20:01:07 -0000 Received: from [127.0.0.1] by omp1002.mail.bf1.yahoo.com with NNFMP; 23 Oct 2013 20:01:07 -0000 X-Yahoo-Newman-Property: ymail-3 X-Yahoo-Newman-Id: 30365.91231.bm@omp1002.mail.bf1.yahoo.com Received: (qmail 55324 invoked by uid 60001); 23 Oct 2013 20:01:06 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com.au; s=s1024; t=1382558466; bh=hJGEHxm+3bAvUxlpeaWrzaZZsl18WQBy4G/PfbIWcYk=; h=X-YMail-OSG:Received:X-Rocket-MIMEInfo:X-Mailer:References:Message-ID:Date:From:Reply-To:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type:Content-Transfer-Encoding; b=GsVLjySybNnBqeNxV6Ef323DcjWXA9ept9sEQpg0IJurhl9yEuCWkSm4dKQ7cV5Q0R1aeBzjuUd6qi9T7Qp3G1xEvXwJ0WctpZ4o3gjgfxVjEObjN4mwB8sTALTLJtv/E5+DVJFjGDbfeq774jzZC0jJPtjo8JxcmYzdWj6JeyM= DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com.au; h=X-YMail-OSG:Received:X-Rocket-MIMEInfo:X-Mailer:References:Message-ID:Date:From:Reply-To:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type:Content-Transfer-Encoding; b=5BmYd47Fd5C+gSRdq+f+6eSzmebPmsJAcVaKwQzuqpu/LlI4c7GXY1DwYd3qGuhl9GvfeaIxkshglGnrI+s0r9/9MS39BntPmdAsZQe/HksRyCSpWE1bWLEUgpB8UJKL2AXLjcVIdyHkW6GOTt/0DRKX3OXR5cO5UV5JehC9Aec=; X-YMail-OSG: QfbJJTEVM1kS.n31oL8r361tIXPBNnwZvt5mrzNdiPbO7Y0 MpzzG_KQmE5E.FdqfjBWC5hdlxwlA3ExEU4MLUWdtsD9bX2hI8qiCpZthReV r6YkBLlSvlZoJoLV9wEyymTOcOhkMp5DmEG7cxmyFIjlyI9v9uRDT0mtjVV7 nNqdItOLXc86Aq6I60Y5ViX.dIKyfK6oMVLf8cqqjKXG5aokv1Y4KKgfneBB P5rUc6dFZlB8nsSCDw7QHciD0USMbbUoL8JQduPwe6OeGOQ_yOSxCjEuZTwr HYjO4UNXilTk72cFFy9bygC_bSLsSlLBeoVg2CK9bISZOELfJ8_.md00V0Wk LH8kjvFxlQj7UUk4KmGCqt61.IBiFRPyKH_97n3g_chdu.7YndIr9mYJiFUn 98L0jja.J9KQAZFoyhwmoEdMzPuSXmrPgROOdiOow9_Q.pbjCt6vqdRcECZT RHrJqQmCQ8rS3SztZ6a_c1nYFAfYQCpcOKhVgsj_S_9yd2vB3tqaA2FRmLDw u.0RJ0U6Hn6ZFyAuLqwqgRNLTN6_g0P9HKKiBLOkTVTSl2dexeweaDeHhWew zqsOYg8Mp1D5dYmM92HBjE4boSA6zIolczaBFhvO1G6XqE97qqoB4S7nSe.u HoHFDF9kDOpFzHrJbj6v2nNbEYIspBVZjuW46HABi6v2bJNaM63M25gaYnWj HAX9RKJfzRaDd Received: from [150.101.221.237] by web142502.mail.bf1.yahoo.com via HTTP; Wed, 23 Oct 2013 13:01:06 PDT X-Rocket-MIMEInfo: 002.001, CgoKCgo.X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18KPiBGcm9tOiBMb3JlbnpvIENvbGl0dGkgPGxvcmVuem9AZ29vZ2xlLmNvbT4KPlRvOiBzdGhhdWdAbmV0aGVscC5ubyAKPkNjOiAidjZvcHNAaWV0Zi5vcmcgV0ciIDx2Nm9wc0BpZXRmLm9yZz47IE9sZSBUcm9hbiAob3Ryb2FuKSA8b3Ryb2FuQGNpc2NvLmNvbT47IGRyYWZ0LWxpdS1ib25pY2EtdjZvcHMtZGhjcHY2LXNsYWFjLXByb2JsZW1AdG9vbHMuaWV0Zi5vcmcgCj5TZW50OiBUaHVyc2RheSwgMjQgT2N0b2JlciAyMDEzIDU6MjEgQU0BMAEBAQE- X-Mailer: YahooMailWebService/0.8.160.587 References: <1382519509.39565.YahooMailNeo@web142502.mail.bf1.yahoo.com> <55F2A998-0417-4C19-B248-AA2A80EBF29C@cisco.com> <52679F9F.7040403@inex.ie> <20131023.122008.74708818.sthaug@nethelp.no> Message-ID: <1382558466.50096.YahooMailNeo@web142502.mail.bf1.yahoo.com> Date: Wed, 23 Oct 2013 13:01:06 -0700 (PDT) From: Mark ZZZ Smith To: Lorenzo Colitti , "sthaug@nethelp.no" In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Cc: "v6ops@ietf.org WG" , "Ole Troan \(otroan\)" , "draft-liu-bonica-v6ops-dhcpv6-slaac-problem@tools.ietf.org" Subject: Re: [v6ops] DHCPv6/SLAAC Make Hosts Confusing-//RE: new draft: draft-liu-bonica-v6ops-dhcpv6-slaac-problem X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: Mark ZZZ Smith List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 23 Oct 2013 20:01:14 -0000 =0A=0A=0A=0A=0A>________________________________=0A> From: Lorenzo Colitti = =0A>To: sthaug@nethelp.no =0A>Cc: "v6ops@ietf.org WG" <= v6ops@ietf.org>; Ole Troan (otroan) ; draft-liu-bonica-v6= ops-dhcpv6-slaac-problem@tools.ietf.org =0A>Sent: Thursday, 24 October 2013= 5:21 AM=0A>Subject: Re: [v6ops] DHCPv6/SLAAC Make Hosts Confusing-//RE: ne= w draft:=A0=A0=A0=A0draft-liu-bonica-v6ops-dhcpv6-slaac-problem=0A> =0A>=0A= >=0A>On Wed, Oct 23, 2013 at 7:20 PM, wrote:=0A>=0A>> a= nd if dhcpv6 gave out netmasks and default gateways, we could finally=0A>>>= ditch RA. =A0I look forward to the day when I can finally expunge RA from = my=0A>>> networks.=0A>>=0A>>Amen. But it doesn't look like this is going to= happen any time soon...=0A>>=0A>=0A>=0A>And then what? Rely on client poll= ing to before you can change any network parameter, ever? Be forced to run = things like VRRP because you can never change anything on the hosts?=0A>=0A= >=0A>Sure that's the way we do it today in IPv4. But is it the best way? Ma= ybe in an enterprise, but in a home?=0A=0AHaving learned about Novell's IPX= before I learnt IPv4, I've since had a bit of an interest in the different= ways different protocols do things, with addressing being one of the more = interesting areas. Of all the protocols I've since looked at or learned ove= r the years (which I think would count to be around or at least 1/2 a dozen= ), only IPv4 with DHCPv4 has used a centralised, database and quite statefu= l address allocation and configuration method.=A0As DHCPv4 was developed qu= ite a number of years after IPv4 addressing had originally been defined and= then evolved through the addition of classes and subnets, it would seem th= at the model used by DHCPv4 is likely to have been chosen to solve needs or= a situation that doesn't normally exist when developing a protocol from sc= ratch. If you go back far enough with IPv4, similar to Novell IPX and Xerox= XNS, it also used the link-layer addresses as host addresses:=0A=0Ahttps:/= /www.rfc-editor.org/ien/ien91.txt=0A=0A=0ASo in the history of protocol dev= elopment and addressing, the DHCPv4 model is quite an anomaly.=0A=0A=0A> Wh= at happens when your precious "DHCPv6 server" (home router) gets unplugged = by the user and all the hosts are dead in the water until they decide to se= nd another DHCPv6 request, even though there are 3 other routers and DHCPv6= servers on the same link?=0A>_____________________________________________= __=0A>v6ops mailing list=0A>v6ops@ietf.org=0A>https://www.ietf.org/mailman/= listinfo/v6ops=0A>=0A>=0A>=0A> From brian.e.carpenter@gmail.com Wed Oct 23 19:55:13 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2405E11E81A2 for ; Wed, 23 Oct 2013 19:55:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.237 X-Spam-Level: X-Spam-Status: No, score=-102.237 tagged_above=-999 required=5 tests=[AWL=-0.238, BAYES_00=-2.599, J_CHICKENPOX_13=0.6, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id incsQ2jcYf+1 for ; Wed, 23 Oct 2013 19:55:12 -0700 (PDT) Received: from mail-pa0-x22d.google.com (mail-pa0-x22d.google.com [IPv6:2607:f8b0:400e:c03::22d]) by ietfa.amsl.com (Postfix) with ESMTP id A5A5A11E80E2 for ; Wed, 23 Oct 2013 19:55:12 -0700 (PDT) Received: by mail-pa0-f45.google.com with SMTP id kp14so1523349pab.4 for ; Wed, 23 Oct 2013 19:55:12 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:organization:user-agent:mime-version:to:cc :subject:references:in-reply-to:content-type :content-transfer-encoding; bh=DmZrFdTtObMfvrVcbssUbv9LITMMFw9q5ITqR2YH3aI=; b=TJ4qQQkRcMOFkasqUpFQHL6mftpa1LpfPa2N6RhyHtb/2d/T9AqtcibhfwB3XrJf02 zyyGFIBO9THpPn07svb5QYaO5pY+dkZNrHFJjJkWCjmAQcI1lDIIZs6/eOYC/qwfq7b2 yzLsPEFY87HabE99AhFDZQQ9glTabv8KMNXSmHwMePKb7wkmjSpFzx+z2ogtZRvtsIUW 9QvGeAoJegLzx34myL4ZwTQDfUVCbXJQUkn3W2cGxcvTLZdvqw0xoeCQHM9/Pce8Zenv WMw5Pr0NbvadFrpKR2gFKVAGmIiVHZOc9eDJoXtmjOJoTJGDo+DkxTJkf68zUU6enBZ+ X6SQ== X-Received: by 10.66.66.11 with SMTP id b11mr948401pat.154.1382583312378; Wed, 23 Oct 2013 19:55:12 -0700 (PDT) Received: from [192.168.178.20] (186.201.69.111.dynamic.snap.net.nz. [111.69.201.186]) by mx.google.com with ESMTPSA id lm2sm1341624pab.2.2013.10.23.19.55.09 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Wed, 23 Oct 2013 19:55:11 -0700 (PDT) Message-ID: <52688C15.2010601@gmail.com> Date: Thu, 24 Oct 2013 15:55:17 +1300 From: Brian E Carpenter Organization: University of Auckland User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: "cb.list6" References: <28CFF7E5-E98E-4D97-B7F4-3A18C255253C@gigix.net> <5267E96B.1000802@innovationslab.net> <20131023152549.GN50205@Space.Net> <5267EB60.7080105@innovationslab.net> <5267ED12.4090602@innovationslab.net> <5268232A.2000805@gmail.com> In-Reply-To: Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: "v6ops@ietf.org WG" Subject: Re: [v6ops] Revised Internet Drafts for allocation of IPv6 space for LISP EIDs X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 24 Oct 2013 02:55:13 -0000 On 24/10/2013 09:00, cb.list6 wrote: > On Wed, Oct 23, 2013 at 12:27 PM, Brian E Carpenter > wrote: >> On 24/10/2013 04:36, Brian Haberman wrote: >>> Hi Lorenzo, >>> >>> On 10/23/13 11:31 AM, Lorenzo Colitti wrote: >>>> On Thu, Oct 24, 2013 at 12:29 AM, Brian Haberman >>>> wrote: >>>> >>>>> "In order to provide connectivity between the Legacy Internet and LISP >>>>> sites, PITRs announcing large aggregates (ideally one single large >>>>> aggregate) of the IPv6 EID Block could be deployed." >>>>> >>>> That sounds very much like a 6to4 relay router, which experience has shown >>>> was an unworkable deployment model. Why is this different? >>>> >>> It's not different. But, that is the tact the LISP WG is trying to >>> take. Keep in mind that the referenced draft went through IETF Last >>> Call and was subsequently sent back to the WG due to the concerns raised >>> about routing and potentially creating a parallel address registry >>> outside of the RIRs. >> I think there is one difference from the 6to4 case - well, two actually. >> >> 1. A lot of operators learnt the hard way that failing to coordinate >> 6to4 prefix routing between operators caused very substantial problems. >> (And, btw, the 6to4 RFC said that such coordination was needed.) >> >> 2. LISP has grown out of the routing community, so the need for >> operational coordination is presumably understood in that community. >> > > Maybe i am wrong, but i have an idea where LISP has grown out of, and > it is not the networks operators that would have to coordinate this to > work. Agreed, routing community != network operators I phrased it quite carefully. Brian > > CB > >> Nevertheless, the risk of a failure of coordination seems high. >> But then, it seemed high for BGP4 itself in 1994. >> >> Brian >> _______________________________________________ >> v6ops mailing list >> v6ops@ietf.org >> https://www.ietf.org/mailman/listinfo/v6ops > From nick@inex.ie Wed Oct 23 21:15:43 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0EFC711E811B for ; Wed, 23 Oct 2013 21:15:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 40IYMY+VLaZb for ; Wed, 23 Oct 2013 21:15:42 -0700 (PDT) Received: from mail.netability.ie (mail.netability.ie [IPv6:2a03:8900:0:100::5]) by ietfa.amsl.com (Postfix) with ESMTP id 32E4311E8109 for ; Wed, 23 Oct 2013 21:15:41 -0700 (PDT) X-Envelope-To: v6ops@ietf.org Received: from vpn-250.int.inex.ie (vpn-250.int.inex.ie [193.242.111.250]) (authenticated bits=0) by mail.netability.ie (8.14.7/8.14.5) with ESMTP id r9O4FTN3024312 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO); Thu, 24 Oct 2013 05:15:31 +0100 (IST) (envelope-from nick@inex.ie) Message-ID: <52689EE0.3030201@inex.ie> Date: Thu, 24 Oct 2013 12:15:28 +0800 From: Nick Hilliard User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:24.0) Gecko/20100101 Thunderbird/24.0.1 MIME-Version: 1.0 To: Mark ZZZ Smith , "Ole Troan (otroan)" References: <201310211245.r9LCj0B29668@ftpeng-update.cisco.com> <8AE0F17B87264D4CAC7DE0AA6C406F453D7CC14B@nkgeml506-mbx.china.huawei.com> <1382469405.56346.YahooMailNeo@web142504.mail.bf1.yahoo.com> <1382519509.39565.YahooMailNeo@web142502.mail.bf1.yahoo.com> <55F2A998-0417-4C19-B248-AA2A80EBF29C@cisco.com> <52679F9F.7040403@inex.ie> <1382556056.28376.YahooMailNeo@web142505.mail.bf1.yahoo.com> In-Reply-To: <1382556056.28376.YahooMailNeo@web142505.mail.bf1.yahoo.com> X-Enigmail-Version: 1.6 X-Company-Info-1: Internet Neutral Exchange Association Limited. Registered in Ireland No. 253804 X-Company-Info-2: Registered Offices: 1-2, Marino Mart, Fairview, Dublin 3 X-Company-Info-3: Internet Neutral Exchange Association Limited is limited by guarantee X-Company-Info-4: Offices: 4027 Kingswood Road, Citywest, Dublin 24. Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: "v6ops@ietf.org" , "draft-liu-bonica-v6ops-dhcpv6-slaac-problem@tools.ietf.org" Subject: Re: [v6ops] DHCPv6/SLAAC Make Hosts Confusing-//RE: new draft: draft-liu-bonica-v6ops-dhcpv6-slaac-problem X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 24 Oct 2013 04:15:43 -0000 On 24/10/2013 03:20, Mark ZZZ Smith wrote: > RAs are prehaps misnamed. They're not really router advertisements, > they're advertisements (typically) sent from routers. View them as layer > 3 configuration protocol packets, because they do far more than > advertise a default router, and don't even need to advertise a default > router to be useful. I know what RAs are. Both protocols provide info to network hosts necessary for functional ipv6 connectivity. They have different approaches, but they are both lan configuration protocols. If you feel that SLAAC+DHCPv6 or SLAAC only is the right thing for you, then that's great and I'm really happy for you. There is a tiny amount of protocol glue missing which would allow dhcpv6 to act as a fully functional standalone protocol, and the various attempts to introduce this glue have been shot down repeatedly, mostly on the basis of arguments like "how do you expect your network to work when critical components of your network are broken?", "we don't like duplication of functionality at the IETF (but we'll ignore all the other duplicated functionality in other ietf protocols)" or "polling sucks". None of these points address the core issue which is that there are a lot of operators who have a strong preference to use a single lan configuration protocol instead of two protocols with strongly overlapping functionality and an ambiguous and poorly defined interaction model. There is no reason for DHCP not to to be standalone-capable, so that operators can make up their own minds about what to use on their networks. I completely understand that you want to use SLAAC on your networks: please stop insisting that I run it on mine. Incidentally a couple of minutes ago, Andrew Sullivan just spoke these words about the IETF at IGF2013 in Bali: "We're not in the business of telling people how to run their networks". Nick > They can be use for: > > - changing host MTUs, instead of individual manual configuration on each host > - announce on-link presence of prefixes, exclusive of whether hosts have addresses within the prefix, instead of individual manual configuration on each host > - adjust neighbor discovery parameters (e.g., timers), instead of individual manual configuration on each host > - announce prefix(es) to be used to generate SLAAC addresses, instead of individual manual configuration on each host > - indicate to hosts whether to use DHCPv6 or SLAAC or both (during a transition between SLAAC/DHCPv6 or vice-versa), instead of individual manual configuration on each host > - advertise a default router, and an associated lifetime, instead of individual manual configuration on each host > > > > >> networks. >> >> Nick >> > From victor@jvknet.com Wed Oct 23 22:57:20 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AFE3311E813F for ; Wed, 23 Oct 2013 22:57:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.901 X-Spam-Level: X-Spam-Status: No, score=-2.901 tagged_above=-999 required=5 tests=[AWL=0.699, 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 5h40gPec42hn for ; Wed, 23 Oct 2013 22:57:13 -0700 (PDT) Received: from mail-ie0-f170.google.com (mail-ie0-f170.google.com [209.85.223.170]) by ietfa.amsl.com (Postfix) with ESMTP id 4FA4911E8132 for ; Wed, 23 Oct 2013 22:57:13 -0700 (PDT) Received: by mail-ie0-f170.google.com with SMTP id at1so3139791iec.15 for ; Wed, 23 Oct 2013 22:57:07 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:user-agent:date:subject:from:to:cc:message-id :thread-topic:in-reply-to:mime-version:content-type :content-transfer-encoding; bh=rCx510k5dJ03Y/1a19efsCl8JtvN2TOA+Gb5LT9G08k=; b=Vb3KTRLZwuX2lQ/vtxQ6wu6/3XEPfHbZvS280LQs5/MuO7OMJw6Jg5coVMN4a4ISHf mMgoUjRpkXkMZCGe7BcL4OnXY0U1mLI9nq7VlUJ94PJG7ajr6CCizFzntq4bh01A/KXE EHhWq8AWQuJpjgkUehsArBpzZLWZb/CE3SRiTDiQh7NwsqRHlSV/u7/OQmIQf9HRmbP0 WLuFTNO4ZdX8LUr47CzwTGRijlMs+QmoYhPxEuRQhs+aA5yjy2qhO/b6N1L7QwtIGHNb I/auKtmPgWg3HasIHIEV4xQEw8oH3cH9Li6a/eM8Ag3S5qZQ3oKdfcHyAPhpma92gPuP LadQ== X-Gm-Message-State: ALoCoQnpAhrtbi3eZwXlnfWdarUa17Qe0vYv2IYYgG7IXr3HArjgk824GWCq25k7HOlJstOeZdZP X-Received: by 10.50.129.39 with SMTP id nt7mr468249igb.13.1382594227070; Wed, 23 Oct 2013 22:57:07 -0700 (PDT) Received: from [192.168.100.33] ([67.224.83.162]) by mx.google.com with ESMTPSA id k6sm10511014igx.8.2013.10.23.22.57.02 for (version=TLSv1 cipher=RC4-SHA bits=128/128); Wed, 23 Oct 2013 22:57:06 -0700 (PDT) User-Agent: Microsoft-MacOutlook/14.10.0.110310 Date: Thu, 24 Oct 2013 01:56:58 -0400 From: Victor Kuarsingh To: Nick Hilliard , Mark ZZZ Smith , "Ole Troan (otroan)" Message-ID: Thread-Topic: [v6ops] DHCPv6/SLAAC Make Hosts Confusing-//RE: new draft: draft-liu-bonica-v6ops-dhcpv6-slaac-problem In-Reply-To: <52689EE0.3030201@inex.ie> Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit Cc: "v6ops@ietf.org" , "draft-liu-bonica-v6ops-dhcpv6-slaac-problem@tools.ietf.org" Subject: Re: [v6ops] DHCPv6/SLAAC Make Hosts Confusing-//RE: new draft: draft-liu-bonica-v6ops-dhcpv6-slaac-problem X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 24 Oct 2013 05:57:20 -0000 On 2013-10-24 12:15 AM, "Nick Hilliard" wrote: > >I know what RAs are. Both protocols provide info to network hosts >necessary for functional ipv6 connectivity. They have different >approaches, but they are both lan configuration protocols. > >If you feel that SLAAC+DHCPv6 or SLAAC only is the right thing for you, >then that's great and I'm really happy for you. There seems to be folks talking about very different environments, and in some cases attempting to make arguments which don't address the comments of the other side. I understand Nick's point. Coming freshly off a long sting at an ISP, I see the value (if it can be done in a sound technical manner), of having the * option * of a clean deployment for addressing and supplying IP related configuration information to the end host/router. This is not saying that it applies everywhere. It's quite obvious that in environments like sensor nets, home nets and other places, SLACC/RAs supply significant value. In other areas, like an operator access network (edge element addressing), it's a different case. Operators, such as the one I worked or, would never (rarely?) let an element auto-configure itself onto the network. I think there may be valid uses cases where, if feasible, there is perceived value is operating in DHCPv6 only mode. Of course, in many environments, DHCPv6 alone is not a good idea (example, my IPv6 light bulb) In the case of client functionality, in those highly controlled access network attachment areas, it is expected that the client (router or host) has a certain level of functionality (and often times this can be enforced). So it's reasonable to expect DHCPv6 client functionality in some use cases. > >There is a tiny amount of protocol glue missing which would allow dhcpv6 >to >act as a fully functional standalone protocol, and the various attempts to If this can be done, without harm to other environments, and achieve it's goals for those who want it (I.e operators who see a need and can articulate the benefits it will supply in network management and operation), I don't see why we are unwilling to discuss it's technical merits. >None of these points address the core issue which is that there are a lot >of operators who have a strong preference to use a single lan >configuration >protocol instead of two protocols with strongly overlapping functionality >and an ambiguous and poorly defined interaction model. I do wonder how many operators will ask for this? My concern is that if there are not too many raising their hands now, it may be that they either don't care, or if they are way behind in IPv6 deployment, they may not know that they care yet. Regards, Victor K > From swmike@swm.pp.se Wed Oct 23 23:40:34 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C09C311E815B for ; Wed, 23 Oct 2013 23:40:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.771 X-Spam-Level: X-Spam-Status: No, score=-5.771 tagged_above=-999 required=5 tests=[AWL=0.478, BAYES_00=-2.599, HELO_EQ_SE=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 oKlu2XKoNVwQ for ; Wed, 23 Oct 2013 23:40:29 -0700 (PDT) Received: from uplift.swm.pp.se (swm.pp.se [212.247.200.143]) by ietfa.amsl.com (Postfix) with ESMTP id B39E111E8140 for ; Wed, 23 Oct 2013 23:40:26 -0700 (PDT) Received: by uplift.swm.pp.se (Postfix, from userid 501) id 647499C; Thu, 24 Oct 2013 08:40:19 +0200 (CEST) Received: from localhost (localhost [127.0.0.1]) by uplift.swm.pp.se (Postfix) with ESMTP id 58A039A; Thu, 24 Oct 2013 08:40:19 +0200 (CEST) Date: Thu, 24 Oct 2013 08:40:19 +0200 (CEST) From: Mikael Abrahamsson To: "v6ops@ietf.org" In-Reply-To: Message-ID: References: User-Agent: Alpine 2.02 (DEB 1266 2009-07-14) Organization: People's Front Against WWW MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: "draft-liu-bonica-v6ops-dhcpv6-slaac-problem@tools.ietf.org" Subject: Re: [v6ops] DHCPv6/SLAAC Make Hosts Confusing-//RE: new draft: draft-liu-bonica-v6ops-dhcpv6-slaac-problem X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 24 Oct 2013 06:40:34 -0000 On Thu, 24 Oct 2013, Victor Kuarsingh wrote: > I understand Nick's point. Coming freshly off a long sting at an ISP, I > see the value (if it can be done in a sound technical manner), of having > the * option * of a clean deployment for addressing and supplying IP > related configuration information to the end host/router. When I first started working with IPv6 I didn't understand the separation. But then again, now that I have gotten used to it, I don't really see the reason to avoid RAs either. On IPv4, the router person has to configure an IPv4 address and netmask, this then has to be mirrored by the DHCPv4 configuration. On IPv6 you can do exactly the same, just set the A-bit off. As stated before, you even don't need an on-link prefix to be sent to clients, so this is actually *better* than IPv4, because if there is a forced-forwarding configuration on L2 the configuration can now be mirrored at the client so no "local-proxy-arp" is needed (which is an ugly hack). So if one really wants to, one can exactly mirror the workflow of IPv4 into IPv6. If I was going to change anything, I wouldn't focus on RA/DHCPv6, but instead on ND. The whole "discovery" part is a mess, and it would be better if the router just could keep state with hosts what IPv6 addresses were in use and never sent out an discovery message. If it wasn't already in the Neighbor table then the packet would just be dropped. -- Mikael Abrahamsson email: swmike@swm.pp.se From lorenzo@google.com Wed Oct 23 23:42:19 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 444A711E8109 for ; Wed, 23 Oct 2013 23:42:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.935 X-Spam-Level: X-Spam-Status: No, score=-1.935 tagged_above=-999 required=5 tests=[AWL=0.042, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, 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 JW-VpwxmmnUs for ; Wed, 23 Oct 2013 23:42:18 -0700 (PDT) Received: from mail-ie0-x22c.google.com (mail-ie0-x22c.google.com [IPv6:2607:f8b0:4001:c03::22c]) by ietfa.amsl.com (Postfix) with ESMTP id 80F8011E8140 for ; Wed, 23 Oct 2013 23:42:15 -0700 (PDT) Received: by mail-ie0-f172.google.com with SMTP id tp5so3158904ieb.31 for ; Wed, 23 Oct 2013 23:42:15 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=JkopkNRqdhXXU1luUaU5/2KDjzSyx/QAh/ZovxD0gN0=; b=SAlr61Zn0zPcstt4+Jj6rORFax6B4rb/9mMBDhs9gQ+SeICmco/0nsK7lsdDrpLi29 Hzk6CBYSHaU7pvO1G7DBsr0tjx8cadBzaBKb0PE94PfbcUBlwjHDFsGYd/RTFBv4eaou GbG9MNzh4zLuumZ4kwNC4VxE/tXD3WWrxCMjZiq88AxZqDzo9W9bmOeBzkEsA1IdGG5A 30/0xsQWCe4FLWuzu7/OFgmrIue0CKMTaSihDzPEzm7uRMeEJDVG1s4CZ5uL9XxeyqWZ PsTEyJ08XXpeVzc46cqHS/CFyfg4eyP/QtlbCS5jFIxi1jHtdwaN4EhWSCCP4oZr+6xS baNg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type; bh=JkopkNRqdhXXU1luUaU5/2KDjzSyx/QAh/ZovxD0gN0=; b=du6iHJWvtctlC5Y23cVA+3RfoV56NYPonibyi9bJD7fY76yEsm7rFTLCe+uiZ4Rmnn CocOsQIqSzj1bqujf/bMPq3NmqmIylI5+Gw0zN+vfaHsuF7SdiEcJWcYpck/+n+Y9P+F xD4GWsmT8gZ64tsnAZNYrWhUmnwLvz7Y/2IDMQtz6w82nTjpXCo3nq5hkXHiIFa4RnGb ca+hQ2XcS9AIZt50LzQGptRouXVibWl44B8umBxfNin9sMAQlTByhhwLyX33zwI5t8tW ZpH+RGkvDGpKJkrcBG9aE/nn1heRaqLbeV6zxWmLaQiieo4iz/06BUf/SwIxGf7MnUap 61eg== X-Gm-Message-State: ALoCoQnresqWJY+1hzH5lfNu61L/JXTvdzEZlmUmyCYljyEIY/PVpwpqs/1oh8VvUOzWPnvNdJAYOcyINpY1tZMbnSjHyoFB/ln1qpAMk1EpCrL48tuVU8DX6QWz9nwfrD3BvazQ9wiSfZxKWbRPp/aqOpCLqdBdvs4RFG4xtgI3E4J9gg2my1fYR2ky0eHMMfF2lMn0woNZ X-Received: by 10.43.57.79 with SMTP id wf15mr710165icb.14.1382596934812; Wed, 23 Oct 2013 23:42:14 -0700 (PDT) MIME-Version: 1.0 Received: by 10.64.86.106 with HTTP; Wed, 23 Oct 2013 23:41:54 -0700 (PDT) In-Reply-To: References: <52689EE0.3030201@inex.ie> From: Lorenzo Colitti Date: Thu, 24 Oct 2013 15:41:54 +0900 Message-ID: To: Victor Kuarsingh Content-Type: multipart/alternative; boundary=bcaec51dd90f2af3b504e976ef09 Cc: "v6ops@ietf.org" , Ted Lemon , Dave Thaler , "Ole Troan \(otroan\)" , "draft-liu-bonica-v6ops-dhcpv6-slaac-problem@tools.ietf.org" Subject: Re: [v6ops] DHCPv6/SLAAC Make Hosts Confusing-//RE: new draft: draft-liu-bonica-v6ops-dhcpv6-slaac-problem X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 24 Oct 2013 06:42:19 -0000 --bcaec51dd90f2af3b504e976ef09 Content-Type: text/plain; charset=ISO-8859-1 On Thu, Oct 24, 2013 at 2:56 PM, Victor Kuarsingh wrote: > It's quite obvious that in environments like sensor nets, home nets and > other places, SLACC/RAs supply significant value. In other areas, like > an operator access network (edge element addressing), it's a different > case. Operators, such as the one I worked or, would never (rarely?) let > an element auto-configure itself onto the network. > Right - and there's the rub. It seems to me that we have two different ways of configuring things (RA and DHCPv6) that don't differ in functionality but differ in how suitable they are for different environments. One mechanism (RA) is dynamic, self-configuring, serverless and fate-sharing, and the other is static, operator-controlled, and centralized. Operators and enterprises want the one they feel gives them more control and are willing to provision the infrastructure to make it reliable (e.g., centralized configuration repositories; DHCPv6 servers and relays; VRRP so they don't need fate-sharing, etc.). But the one that offers more control falls over in home networks, because the infrastructure to run it is either not available or unreliable: there's nothing anyone can do to make the DHCPv6 server (or the DHCPv6-provided router or DNS server) keep working if the user has unplugged it or tripped over the power cord, and there's nothing that can withdraw a stateful DHCPv6 lease if the original server has been unplugged, because nobody knows the nonce any more. I think we need to accept that neither protocol is sufficient in all environments. We have to realize that DHCPv6 just isn't suited to dynamic, self-organizing environments like home networks. We can keep hacking it with more semantics like unsolicited updates, but at the end of the day we'll simply end up with something that looks like RAs - multicast updates to everyone on the link (equivalent to multicast RAs), configuration requests/replies (equivalent to RS/RA), and so on. Then we'll have to implement DHCPv6 guard to stop rogue servers, and even then there will be no fate-sharing with routing. On the other hand, RA doesn't offer the wealth of different option types that DHCPv6 has, and while it's possible to do fine-grained configuration with unicast RAs, today most RA implementations don't support fine-grained per-client configuration via unicast RA or "RS relaying" to a central server to fetch per-client RA information. I see two possible ways out of this: 1. Decide a clear split between what goes into RA and what goes into DHCPv6, and then stick to it. For example, we could say that configuration information that is required to obtain basic connectivity on a network must be available in RA so it can be dynamically updated and shares fate with routing, and that everything that's not strictly required for the host's connectivity can go into DHCPv6. I don't know if it will be possible to draw a line here. If operators insist that DHCPv6 by itself must be sufficient, then we have no choice but to duplicate information. 2. Attempt to say that RAs and DHCPv6 are simply containers and propose a unified option format so we can have the same options in both of them. I know this was already proposed once and was shot down, but I wasn't around, so I don't know why. (CCing a few people who might know). Cheers, Lorenzo --bcaec51dd90f2af3b504e976ef09 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
On Thu, Oct 24, 2013 at 2:56 PM, Victor Kuarsingh <victor= @jvknet.com> wrote:
It&#= 39;s quite obvious that in=A0env= ironments like sensor nets, home nets and other places, SLACC/RAs=A0= supply significant value. =A0In other a= reas, like an operator access network=A0(edge element addressing), it's a different case. =A0Operators,= such as the=A0one I worked or, = would never (rarely?) let an element auto-configure=A0itself onto the network.

Right - and there's the rub.

It seems to me that we have two different ways of configuri= ng things (RA and DHCPv6) that don't differ in functionality but differ= in how suitable they are for different environments. One mechanism (RA) is= dynamic, self-configuring, serverless and fate-sharing, and the other is s= tatic, operator-controlled, and centralized.

Operators and enterprises want the one they feel gives = them more control and are willing to provision the infrastructure to make i= t reliable (e.g., centralized configuration repositories; DHCPv6 servers an= d relays; VRRP so they don't need fate-sharing, etc.). But the one that= offers more control falls over in home networks, because the infrastructur= e to run it is either not available or unreliable: there's nothing anyo= ne can do to make the DHCPv6 server (or the DHCPv6-provided router or DNS s= erver) keep working if the user has unplugged it or tripped over the power = cord, and there's nothing that can withdraw a stateful DHCPv6 lease if = the original server has been unplugged, because nobody knows the nonce any = more.

I think we need to accept that neither protocol is suff= icient in all environments. We have to realize that DHCPv6 just isn't s= uited to dynamic, self-organizing environments like home networks. We can k= eep hacking it with more semantics like unsolicited updates, but at the end= of the day we'll simply end up with something that looks like RAs - mu= lticast updates to everyone on the link (equivalent to multicast RAs), conf= iguration requests/replies (equivalent to RS/RA), and so on. Then we'll= have to implement DHCPv6 guard to stop rogue servers, and even then there = will be no fate-sharing with routing. On the other hand, RA doesn't off= er the wealth of different option types that DHCPv6 has, and while it's= possible to do fine-grained configuration with unicast RAs, today most RA = implementations don't support fine-grained per-client configuration via= unicast RA or "RS relaying" to a central server to fetch per-cli= ent RA information.

I see two possible ways out of this:

1. Decide a clear split between what goes into RA and what goes into= DHCPv6, and then stick to it. For example, we could say that configuration= information that is required to obtain basic connectivity on a network mus= t be available in RA so it can be dynamically updated and shares fate with = routing, and that everything that's not strictly required for the host&= #39;s connectivity can go into DHCPv6. I don't know if it will be possi= ble to draw a line here. If operators insist that DHCPv6 by itself must be = sufficient, then we have no choice but to duplicate information.

2. Attempt to say that RAs and DHCPv6 are simply contai= ners and propose a unified option format so we can have the same options in= both of them. I know this was already proposed once and was shot down, but= I wasn't around, so I don't know why. (CCing a few people who migh= t know).

Cheers,
Lorenzo
--bcaec51dd90f2af3b504e976ef09-- From leo.liubing@huawei.com Wed Oct 23 23:57:38 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B0D1311E8115 for ; Wed, 23 Oct 2013 23:57:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.535 X-Spam-Level: X-Spam-Status: No, score=-6.535 tagged_above=-999 required=5 tests=[AWL=0.064, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id A10CkxYN57CN for ; Wed, 23 Oct 2013 23:57:33 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) by ietfa.amsl.com (Postfix) with ESMTP id 0B17B11E82CC for ; Wed, 23 Oct 2013 23:57:18 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml203-edg.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id AZK36929; Thu, 24 Oct 2013 06:57:14 +0000 (GMT) Received: from LHREML406-HUB.china.huawei.com (10.201.5.243) by lhreml203-edg.huawei.com (172.18.7.221) with Microsoft SMTP Server (TLS) id 14.3.158.1; Thu, 24 Oct 2013 07:57:10 +0100 Received: from NKGEML402-HUB.china.huawei.com (10.98.56.33) by lhreml406-hub.china.huawei.com (10.201.5.243) with Microsoft SMTP Server (TLS) id 14.3.158.1; Thu, 24 Oct 2013 07:57:14 +0100 Received: from NKGEML506-MBX.china.huawei.com ([169.254.3.141]) by nkgeml402-hub.china.huawei.com ([10.98.56.33]) with mapi id 14.03.0146.000; Thu, 24 Oct 2013 14:57:09 +0800 From: "Liubing (Leo)" To: "v6ops@ietf.org" Thread-Topic: Soliciting comments on draft-liu-running-multiple-prefixes-01 Thread-Index: AQHO0IZC8XpvAnq6mEe80UtnaJBYjg== Date: Thu, 24 Oct 2013 06:57:09 +0000 Message-ID: <8AE0F17B87264D4CAC7DE0AA6C406F453D7CDC65@nkgeml506-mbx.china.huawei.com> Accept-Language: en-US, zh-CN Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-cr-hashedpuzzle: CsWv Dqn6 FJRB FLMi FUl4 GXNA GXyV Gi74 G7C/ IVCi Iwdd JUlq JfAv KXWm KvtX LQSL; 1; dgA2AG8AcABzAEAAaQBlAHQAZgAuAG8AcgBnAA==; Sosha1_v1; 7; {681E6F08-285F-4F5B-A355-5B5BD950A0C1}; bABlAG8ALgBsAGkAdQBiAGkAbgBnAEAAaAB1AGEAdwBlAGkALgBjAG8AbQA=; Thu, 24 Oct 2013 06:57:06 GMT; UwBvAGwAaQBjAGkAdABpAG4AZwAgAGMAbwBtAG0AZQBuAHQAcwAgAG8AbgAJAGQAcgBhAGYAdAAtAGwAaQB1AC0AcgB1AG4AbgBpAG4AZwAtAG0AdQBsAHQAaQBwAGwAZQAtAHAAcgBlAGYAaQB4AGUAcwAtADAAMQA= x-cr-puzzleid: {681E6F08-285F-4F5B-A355-5B5BD950A0C1} x-originating-ip: [10.111.98.132] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Reflected Subject: [v6ops] Soliciting comments on draft-liu-running-multiple-prefixes-01 X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 24 Oct 2013 06:57:38 -0000 Hi Dear All, We have a draft:=20 http://tools.ietf.org/html/draft-liu-running-multiple-prefixes-01 The draft aims to collect the considerations regarding running multiple pre= fixes in IPv6 networks, and try to provide some guidance, as well as pointi= ng out some gaps. May I request your review and comments. Especially your deploy experience r= egarding with the topic would help a lot to improve the draft. Any feedback would be appreciated much. Many thanks and best regards, Bing From sander@steffann.nl Thu Oct 24 01:37:04 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DA4B911E8305 for ; Thu, 24 Oct 2013 01:37:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ykgq9D2ykt0P for ; Thu, 24 Oct 2013 01:37:04 -0700 (PDT) Received: from mail.sintact.nl (mail.sintact.nl [IPv6:2001:9e0:803::6]) by ietfa.amsl.com (Postfix) with ESMTP id EBE9D11E812D for ; Thu, 24 Oct 2013 01:37:03 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mail.sintact.nl (Postfix) with ESMTP id 66E2048; Thu, 24 Oct 2013 10:37:02 +0200 (CEST) X-Virus-Scanned: Debian amavisd-new at mail.sintact.nl Received: from mail.sintact.nl ([127.0.0.1]) by localhost (mail.sintact.nl [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tHrVD+nfHNRI; Thu, 24 Oct 2013 10:37:00 +0200 (CEST) Received: from [172.20.1.180] (unknown [172.20.1.180]) by mail.sintact.nl (Postfix) with ESMTPSA id AA3F83A; Thu, 24 Oct 2013 10:36:57 +0200 (CEST) Content-Type: text/plain; charset=iso-8859-1 Mime-Version: 1.0 (Mac OS X Mail 7.0 \(1816\)) From: Sander Steffann In-Reply-To: Date: Thu, 24 Oct 2013 10:36:56 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <5F8A3583-5CC0-4950-9238-65F597E97D5A@steffann.nl> References: <52689EE0.3030201@inex.ie> To: Lorenzo Colittf X-Mailer: Apple Mail (2.1816) Cc: "v6ops@ietf.org" , Ted Lemon , "Ole Troan \(otroan\)" , Dave Thaler , "draft-liu-bonica-v6ops-dhcpv6-slaac-problem@tools.ietf.org" Subject: Re: [v6ops] DHCPv6/SLAAC Make Hosts Confusing-//RE: new draft: draft-liu-bonica-v6ops-dhcpv6-slaac-problem X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 24 Oct 2013 08:37:05 -0000 Hi, > 2. Attempt to say that RAs and DHCPv6 are simply containers and = propose a unified option format so we can have the same options in both = of them. I know this was already proposed once and was shot down, but I = wasn't around, so I don't know why. (CCing a few people who might know). I don't know why it was shot down, but this seems the least bad option = to me. At least there will be a uniform set of options. Having = almost-the-same-but-not-quite duplication between RA and DHCP will be = the worst possible outcome... Met vriendelijke groet, Sander Steffann From tore@fud.no Thu Oct 24 02:02:22 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 774C711E8144 for ; Thu, 24 Oct 2013 02:02:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.3 X-Spam-Level: X-Spam-Status: No, score=-2.3 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, 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 8xNgcqAVkjJn for ; Thu, 24 Oct 2013 02:02:21 -0700 (PDT) Received: from greed.fud.no (greed.fud.no [IPv6:2a02:c0:1001:100::145]) by ietfa.amsl.com (Postfix) with ESMTP id 5800411E817D for ; Thu, 24 Oct 2013 02:02:21 -0700 (PDT) Received: from [2a02:c0:2:1:1194:17:0:1000] (port=47136 helo=echo.linpro.no) by greed.fud.no with esmtpsa (TLS1.0:DHE_RSA_CAMELLIA_256_CBC_SHA1:256) (Exim 4.80) (envelope-from ) id 1VZGo5-0002ue-KN; Thu, 24 Oct 2013 11:02:17 +0200 Message-ID: <5268E219.4090100@fud.no> Date: Thu, 24 Oct 2013 11:02:17 +0200 From: Tore Anderson User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.0 MIME-Version: 1.0 To: Mikael Abrahamsson , =?UTF-8?B?56We5piO6YGU5ZOJ?= References: <201310211245.r9LCj0B29668@ftpeng-update.cisco.com> <8AE0F17B87264D4CAC7DE0AA6C406F453D7CC14B@nkgeml506-mbx.china.huawei.com> <1382469405.56346.YahooMailNeo@web142504.mail.bf1.yahoo.com> <1382519509.39565.YahooMailNeo@web142502.mail.bf1.yahoo.com> <55F2A998-0417-4C19-B248-AA2A80EBF29C@cisco.com> In-Reply-To: Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Cc: "v6ops@ietf.org" , "draft-liu-bonica-v6ops-dhcpv6-slaac-problem@tools.ietf.org" Subject: Re: [v6ops] DHCPv6/SLAAC Make Hosts Confusing-//RE: new draft: draft-liu-bonica-v6ops-dhcpv6-slaac-problem X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 24 Oct 2013 09:02:22 -0000 * Mikael Abrahamsson > On Wed, 23 Oct 2013, 神明達哉 wrote: > >> implementation dependent, and IIRC the ISC DHCPv6 client >> unconditionally uses a /64 prefix when it configures a host's >> interface with the address assigned via DHCPv6. > > Are you sure? I don't know what Ubuntu uses, but I have successfully > gotten it to just get a single IA_NA + default gw, no /64 on the interface. I added a workaround for the ISC bug in GNOME NetworkManager one and ahalf year ago, basically we ignore whatever the DHCPv6 client tells us and go with a prefix length of 128 always: http://cgit.freedesktop.org/NetworkManager/NetworkManager/commit/?id=eb460b70dad82d366d35fa5703c0e79a1389e4d1 I reported the bug to ISC too, but I have heard exactly nothing back from them. Tore From victor@jvknet.com Thu Oct 24 05:56:41 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BB3FF11E81A1 for ; Thu, 24 Oct 2013 05:56:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.435 X-Spam-Level: X-Spam-Status: No, score=-2.435 tagged_above=-999 required=5 tests=[AWL=-0.233, BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=1.396, 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 AqvPhyeT0r1h for ; Thu, 24 Oct 2013 05:56:24 -0700 (PDT) Received: from mail-qe0-f51.google.com (mail-qe0-f51.google.com [209.85.128.51]) by ietfa.amsl.com (Postfix) with ESMTP id 8142511E81A5 for ; Thu, 24 Oct 2013 05:56:00 -0700 (PDT) Received: by mail-qe0-f51.google.com with SMTP id q19so1351724qeb.24 for ; Thu, 24 Oct 2013 05:55:53 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:user-agent:date:subject:from:to:cc:message-id :thread-topic:in-reply-to:mime-version:content-type; bh=+C5hKb1IWraHXjxlbtblSvB4Jywky4mNZ9rtEDirync=; b=SDVg28l4Py2ESrlMl+bnr2rViybGOwbjiIJXYp7Z+OCiOa8JHgIZaO9zgHEVwye9zu BrKAlDiNwNRiRQupVp03DNmar9jxAXNttqF7gpZpuzNB2lWsV4OYQiqhSHKATXs/mS2t bKRd/JTdwqTFuJ5H7T7VaDbHQDnW0FCvOGLP1VaesjREMzuImRE0q3wqxltNa9N9NjvV vNU+4yUTk3MWpV1xIWNgaQ3eS/i4QDSOeSPid+f0c3nGINmYuqsBhYOd8/t7gQR81eBv W98JalpkMqhekY+sHrca9M1rLzlClK6l/kaMa+DzhMCguwfPQZ88/DUWmQn5LqV8MMlS HEFg== X-Gm-Message-State: ALoCoQlzqXOxUZ+GcAdOW7R5XMY2KqPSuZ6LjeR9/9I7egFXTS3yCRx43dixb7zDSp8E8nCarMSa X-Received: by 10.224.88.70 with SMTP id z6mr1899986qal.116.1382619353714; Thu, 24 Oct 2013 05:55:53 -0700 (PDT) Received: from [192.168.100.33] ([67.224.83.162]) by mx.google.com with ESMTPSA id kz8sm2529273qeb.0.2013.10.24.05.55.46 for (version=TLSv1 cipher=RC4-SHA bits=128/128); Thu, 24 Oct 2013 05:55:52 -0700 (PDT) User-Agent: Microsoft-MacOutlook/14.10.0.110310 Date: Thu, 24 Oct 2013 08:55:38 -0400 From: Victor Kuarsingh To: Lorenzo Colitti Message-ID: Thread-Topic: [v6ops] DHCPv6/SLAAC Make Hosts Confusing-//RE: new draft: draft-liu-bonica-v6ops-dhcpv6-slaac-problem In-Reply-To: Mime-version: 1.0 Content-type: multipart/alternative; boundary="B_3465449752_6261691" Cc: "v6ops@ietf.org" , Ted Lemon , Dave Thaler , "Ole Troan \(otroan\)" , "draft-liu-bonica-v6ops-dhcpv6-slaac-problem@tools.ietf.org" Subject: Re: [v6ops] DHCPv6/SLAAC Make Hosts Confusing-//RE: new draft: draft-liu-bonica-v6ops-dhcpv6-slaac-problem X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 24 Oct 2013 12:56:42 -0000 > This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. --B_3465449752_6261691 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit From: Lorenzo Colitti >I see two possible ways out of this: >>1. Decide a clear split between what goes into RA and what goes into DHCPv6, and then stick to it. For example, we >>could say that configuration information that is required to obtain basic connectivity on a network must be available in >>RA so it can be dynamically updated and shares fate with routing, and that everything that's not strictly required for >>the host's connectivity can go into DHCPv6. I don't know if it will be possible to draw a line here. If operators insist that >>DHCPv6 by itself must be sufficient, then we have no choice but to duplicate information. [VK] Although this is theoretically possible, I am not if we can actually orchestrate this and keep it split indefinitely. I think we will see requests/requirements on both sides which may drive (I.e. Like operators) functions into either protocol. >>2. Attempt to say that RAs and DHCPv6 are simply containers and propose a unified option format so we can have the >>same options in both of them. I know this was already proposed once and was shot down, but I wasn't around, so I >>don't know why. (CCing a few people who might know). [VK] This seems like an intriguing idea. Would this mean that every option must go into each container, or that there will be a common set of options which go into both, and perhaps exceptions go into one or the other? (On that latter part, I guess that line of thinking gets us back to where we are). Regards, Victor K --B_3465449752_6261691 Content-type: text/html; charset="US-ASCII" Content-transfer-encoding: quoted-printable


From: Lorenzo Colitti <lorenzo@google.com>
>I see two possible ways out of th= is:

>>1. Decide a clear split between what goes i= nto RA and what goes into DHCPv6, and then stick to it. For example, we >= >could say that configuration information that is required to obtain basi= c connectivity on a network must be available in >>RA so it can be dyn= amically updated and shares fate with routing, and that everything that's no= t strictly required for >>the host's connectivity can go into DHCPv6. = I don't know if it will be possible to draw a line here. If operators insist= that >>DHCPv6 by itself must be sufficient, then we have no choice bu= t to duplicate information.

[VK] Although this is theoretically possible, I am not if we can actually = orchestrate this and keep it split indefinitely.  I think we will see r= equests/requirements on both sides which may drive (I.e. Like operators) fun= ctions into either protocol.

<= br>
>>2. Attempt to say that RAs and DHCPv6 are simply conta= iners and propose a unified option format so we can have the >>same op= tions in both of them. I know this was already proposed once and was shot do= wn, but I wasn't around, so I >>don't know why. (CCing a few people wh= o might know).

[VK] This s= eems like an intriguing idea. Would this mean that every option mu= st go into each container, or that there will be a common set of options whi= ch go into both, and perhaps exceptions go into one or the other? (On that l= atter part, I guess that line of thinking gets us back to where we are).

Regards,

Victor K
<= br>

--B_3465449752_6261691-- From arturo.servin@gmail.com Thu Oct 24 08:00:09 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 18A5E11E8349 for ; Thu, 24 Oct 2013 08:00:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_13=0.6, 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 zv+IZ5HRleqH for ; Thu, 24 Oct 2013 08:00:08 -0700 (PDT) Received: from mail-wi0-x234.google.com (mail-wi0-x234.google.com [IPv6:2a00:1450:400c:c05::234]) by ietfa.amsl.com (Postfix) with ESMTP id 9B29811E8355 for ; Thu, 24 Oct 2013 07:56:53 -0700 (PDT) Received: by mail-wi0-f180.google.com with SMTP id ey11so2690327wid.7 for ; Thu, 24 Oct 2013 07:56:49 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=BCv/72zh4CCV5ujU3+VY4k5wxgBo5lto5JDCXtmAfkM=; b=f4yslWTT0yX2EDCt7aRUS5M/Uo0O9GNjBGRrKX2iMbxamGUuFG8L3Hvex8Qyv3/5kp MEFjK7lumis2CWPjgQmLM7bvbnhtXKVFBYhfvsQX6eJVlXxtxQjwda0KBBmLQ8qxtows MHC+8V/+e1QSEixGtS4rLz8mzFOd1F3tev8OpnmWZzCcb+OL/tXXI5tAOPelvGmi3kOp /QQIMVz3uEpeJT1oZ63hj1ojK9bWugjB7hRqKjrcfx+q6f1lJFymKqF/2FneGEvO249s rrEZqqAJqnO8h8nbQnraiuhEsdnIeiYt+y9TYIp+HTC4Me4tFmfmBySCIewV8CkyIRwq l47g== X-Received: by 10.194.219.70 with SMTP id pm6mr2987327wjc.47.1382626609388; Thu, 24 Oct 2013 07:56:49 -0700 (PDT) MIME-Version: 1.0 Received: by 10.194.42.4 with HTTP; Thu, 24 Oct 2013 07:56:29 -0700 (PDT) In-Reply-To: References: From: Arturo Servin Date: Thu, 24 Oct 2013 12:56:29 -0200 Message-ID: To: Victor Kuarsingh Content-Type: multipart/alternative; boundary=001a11c1b31ce8ef3204e97dd737 Cc: "v6ops@ietf.org" , Ted Lemon , "Ole Troan \(otroan\)" , Dave Thaler , "draft-liu-bonica-v6ops-dhcpv6-slaac-problem@tools.ietf.org" Subject: Re: [v6ops] DHCPv6/SLAAC Make Hosts Confusing-//RE: new draft: draft-liu-bonica-v6ops-dhcpv6-slaac-problem X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 24 Oct 2013 15:00:09 -0000 --001a11c1b31ce8ef3204e97dd737 Content-Type: text/plain; charset=ISO-8859-1 I think that neither RA or DHCP can serve as the only-solution to provide dynamic configuration information in IPv6. There are use cases where one is suitable and the other is not as some have point out. What I think we need is a clear strategy of what we need to do regarding those mechanisms and accept that we will need to support them both in the stack. Lorenzo's proposals seems to be a good start. /as On Thu, Oct 24, 2013 at 10:55 AM, Victor Kuarsingh wrote: > > > From: Lorenzo Colitti > > >I see two possible ways out of this: > > >>1. Decide a clear split between what goes into RA and what goes into > DHCPv6, and then stick to it. For example, we >>could say that > configuration information that is required to obtain basic connectivity on > a network must be available in >>RA so it can be dynamically updated and > shares fate with routing, and that everything that's not strictly required > for >>the host's connectivity can go into DHCPv6. I don't know if it will > be possible to draw a line here. If operators insist that >>DHCPv6 by > itself must be sufficient, then we have no choice but to duplicate > information. > > [VK] Although this is theoretically possible, I am not if we can actually > orchestrate this and keep it split indefinitely. I think we will see > requests/requirements on both sides which may drive (I.e. Like operators) > functions into either protocol. > > > >>2. Attempt to say that RAs and DHCPv6 are simply containers and propose > a unified option format so we can have the >>same options in both of them. > I know this was already proposed once and was shot down, but I wasn't > around, so I >>don't know why. (CCing a few people who might know). > > [VK] This seems like an intriguing idea. Would this mean that every option > must go into each container, or that there will be a common set of options > which go into both, and perhaps exceptions go into one or the other? (On > that latter part, I guess that line of thinking gets us back to where we > are). > > Regards, > > Victor K > > > > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops > > --001a11c1b31ce8ef3204e97dd737 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable

I think that neither RA or DHCP can serve as the = only-solution to provide dynamic configuration information in IPv6. There a= re use cases where one is suitable and the other is not as some have point = out.

What I think we need is a clear strategy of what we nee= d to do regarding those mechanisms and accept that we will need to support = them both in the stack.=A0

Lorenzo's proposals= seems to be a good start.

/as


On Thu, Oct 24, 2013 at 10:55 AM, Victor Kuarsingh <= victor@jvknet.com> wrote:


<= div style=3D"border-right:medium none;padding-right:0in;padding-left:0in;pa= dding-top:3pt;text-align:left;font-size:11pt;border-bottom:medium none;font= -family:Calibri;border-top:#b5c4df 1pt solid;padding-bottom:0in;border-left= :medium none"> From: Lorenzo Colitti <lorenzo@google.com>=

>I see two possible ways out of this:

>>1. Decide a clear split bet= ween what goes into RA and what goes into DHCPv6, and then stick to it. For= example, we >>could say that configuration information that is requi= red to obtain basic connectivity on a network must be available in >>= RA so it can be dynamically updated and shares fate with routing, and that = everything that's not strictly required for >>the host's conn= ectivity can go into DHCPv6. I don't know if it will be possible to dra= w a line here. If operators insist that >>DHCPv6 by itself must be su= fficient, then we have no choice but to duplicate information.

[VK] Although this is th= eoretically possible, I am not if we can actually orchestrate this and keep= it split indefinitely. =A0I think we will see requests/requirements on bot= h sides which may drive (I.e. Like operators) functions into either protoco= l.


>>2. Attempt t= o say that RAs and DHCPv6 are simply containers and propose a unified optio= n format so we can have the >>same options in both of them. I know th= is was already proposed once and was shot down, but I wasn't around, so= I >>don't know why. (CCing a few people who might know).

[VK] This seems like an= =A0intriguing=A0idea. Would this mean that every option must go into each c= ontainer, or that there will be a common set of options which go into both,= and perhaps exceptions go into one or the other? (On that latter part, I g= uess that line of thinking gets us back to where we are).

Regards,

Victor K


_______________________________________________
v6ops mailing list
v6ops@ietf.org
h= ttps://www.ietf.org/mailman/listinfo/v6ops


--001a11c1b31ce8ef3204e97dd737-- From mackermann@bcbsm.com Thu Oct 24 09:52:49 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B0EB611E8374 for ; Thu, 24 Oct 2013 09:52:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.057 X-Spam-Level: X-Spam-Status: No, score=-6.057 tagged_above=-999 required=5 tests=[AWL=-0.058, BAYES_00=-2.599, J_CHICKENPOX_13=0.6, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DinlNggzuj8O for ; Thu, 24 Oct 2013 09:52:29 -0700 (PDT) Received: from mx.z120.zixworks.com (mx.z120.zixworks.com [199.30.235.120]) by ietfa.amsl.com (Postfix) with ESMTP id 3A73C11E836B for ; Thu, 24 Oct 2013 09:50:43 -0700 (PDT) Received: from vmvpm02.z120.zixworks.com (ZixVPM [127.0.0.1]) by Outbound.z120.zixworks.com (Proprietary) with ESMTP id CCB362FF69F for ; Thu, 24 Oct 2013 11:50:17 -0500 (CDT) Received: from imsva1.bcbsm.com (unknown [12.107.172.80]) by mx.z120.zixworks.com (Proprietary) with SMTP id A162830743A; Thu, 24 Oct 2013 11:50:16 -0500 (CDT) Received: from imsva1.bcbsm.com (unknown [127.0.0.1]) by IMSVA80 (Postfix) with ESMTP id 4EDEE4F8051; Thu, 24 Oct 2013 12:40:02 -0400 (EDT) Received: from PWN401EA110.ent.corp.bcbsm.com (unknown [10.64.80.218]) by imsva1.bcbsm.com (Postfix) with ESMTP id 2FEE74F805A; Thu, 24 Oct 2013 12:40:02 -0400 (EDT) Received: from PWN401EA160.ent.corp.bcbsm.com ([fe80::fdcb:603d:469e:b1db]) by PWN401EA110.ent.corp.bcbsm.com ([fe80::716f:e3f0:b97f:8900%13]) with mapi id 14.01.0438.000; Thu, 24 Oct 2013 12:50:02 -0400 From: "Ackermann, Michael" To: Ray Hunter , Nalini Elkins Thread-Topic: [v6ops] Fw: New Version Notification for draft-elkins-6man-ipv6-pdm-dest-option-04.txt Thread-Index: AQHOyuiEsp3P94CgjEaaXBige+0sO5n9xySAgAJIKwCAAHiqAIAChzTA Date: Thu, 24 Oct 2013 16:50:01 +0000 Message-ID: <4FC37E442D05A748896589E468752CAA0CA88734@PWN401EA160.ent.corp.bcbsm.com> References: <20131017032024.5051.20799.idtracker@ietfa.amsl.com> <1381980305.36254.YahooMailNeo@web2803.biz.mail.ne1.yahoo.com> <5263C783.1080001@globis.net> <1382396300.22968.YahooMailNeo@web2801.biz.mail.ne1.yahoo.com> <526616C4.40304@globis.net> In-Reply-To: <526616C4.40304@globis.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.64.10.35] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: v6ops WG , 6man WG , "ippm@ietf.org" Subject: Re: [v6ops] Fw: New Version Notification for draft-elkins-6man-ipv6-pdm-dest-option-04.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 24 Oct 2013 16:52:49 -0000 Hi Ray. And thanks again for all your insightful comments/questions.=20 I am a little late in responding, so let me just tack on a little to what = Nalini and others have already said.=20 Your point 4 seems to indicate that all nodes in a desired time = synchronization domain need to be synched to the same master clock. This = has not been my experience. As long as the required Stratum level is = realized, for the level of accuracy required by the situation or = application, the proper level of time synchronization is achieved. = Example would be that if one node in the NTP domain is referencing a GPS = Stratum 0 and another node is referencing a separate Stratum 0 source, the = two nodes should be Stratum 1 and within that level of accuracy. =20 This is something we have implemented across several disparate enterprises = and it has worked well for us. I am wondering if your experience has = yielded different results? You also had two other points/questions, that I believe Nalini already = responded to, but.............. 1. The possibility that =22Middleboxes=22 could utilize PDM, is very = intriguing to me. I believe this would be more difficult to = add/implement, but worth the effort if the Middlebox vendors would = perceive value and actually use PDM. Not sure how to determine if this = would be the case or not?=20 2. It would be ideal to have only 1 PDM format that handles both time = sycnronized and non synchronized situations. I do not readily see how to = achieve this. Would love to talk to you some more if you have some = ideas=21 =20 Again, thanks for your great input, thoughts and questions=21=21=21 (and = hopefully more to come). =20 Mike -----Original Message----- From: v6ops-bounces=40ietf.org =5Bmailto:v6ops-bounces=40ietf.org=5D On = Behalf Of Ray Hunter Sent: Tuesday, October 22, 2013 2:10 AM To: Nalini Elkins Cc: v6ops WG; 6man WG; ippm=40ietf.org Subject: Re: =5Bv6ops=5D Fw: New Version Notification for = draft-elkins-6man-ipv6-pdm-dest-option-04.txt > Nalini Elkins > 22 October 2013 00:58 >> 1) encoding has to be fast, but decoding does not > > True > >> 2) a node's clock could be either in our out of synch with some=20 >> notional master clock (e.g. via NTP) >> 3) two clocks could be in synch to a master source, but the master =20 >> sources may themselves not share a common source (one sourced from=20 >> GPS, one from DCF77) >> 4) the key to being able to perform the end to end calculations is=20 >> whether two communicating nodes are synchronised to the same master=20 >> clock (within some level of error/jitter) >> 5) the absolute time is not particularly important > > > This is true for PDM 1 only. PDM 2 does not require time synchronization. > >> Q1. Why do you want to encode differences as deltas in the case of an = unsynchronised/ free running clock? >> Isn't that slow, and difficult for hardware implementations to achieve = (e.g. TCP offload)? Doesn't it also require maintaining large amounts of = state in the sending node. >> > > 1. I think that it is going to be interesting to see how hardware is = going to handle TCP offload with IPv6 extension headers. I do not see = why PDM 2 would be so much harder than PDM 1 for an OS. > Can you tell me which end host operating systems are doing TCP offload = in hardware? =20 IMHO Not a relevant question. As a standards body we should be looking to = the future. There are many operations that are delegated to microcode. If you specified the packet with one single way of encapsulating = timestamps, then hardware or interface microcode could add the timestamp = at the last possible moment before the packet reached the wire, without = having to examine the original packet contents, or knowing the context of = the communicating nodes. I think that's very desirable. > I know some OS's which process TCP segmentation in hardware. But at = this point, the packet is already crafted. Also some do IP checksum = offload in hardware but that does not apply to IPv6 as there is no IP = header checksum. > > > 2. End hosts already maintain quite a bit of state. Every OS has = control blocks to handle events such as TCP duplicate packets, round trip = time, congestion window, etc. We are NOT suggesting > that the PDM headers be used in middle boxes. That is, we are NOT = asking routers to maintain state. So what? Why add to the problem? Why does the timestamp require synchronisation with that other TCP state? Isn't it better to define a solution that is independent of the upper = layer header transport protocol? Why not allow middleboxes (or node hardware) to insert the = timestamp header on the fly? > >> Why not just encode the timestamp as-is and perform the appropriate = difference calculation during decoding? > > If clocks are out of synch, you could end up having it look like you = received the packet before you sent it. No. I'm not suggesting you use the same decoding algorithm: only that you = define a single common encoding algorithm that combines all the = information required for PDM 1 and PDM 2 calculations. Having to chose = which packet encoding to use in advance is problematic IMHO. >> Q2. Why do you need two separate packet formats at all? > >> Why not have a common format for all cases, containing a timestamp=20 >> based on the local clock, plus an optional field containing a flag=20 >> that states if the local timestamp is coordinated to some master=20 >> clock, plus an identifier for the master clock. > >> You could then encode whether a node had a free-running clock (case=20 >> 2), a synchronised clock (case 1), and whether it was synched via NTP=20 >> to some stratum 0 source e.g. GPS, and also some identification of=20 >> the stratum 1 source (IPv6 address). > >> Two communicating nodes could then use e.g. NTP trace to see if they=20 >> shared a common clock source or not, before performing their = calculations. > > We are trying to craft a solution with PDM 2 for those situations where = time synchronization is not practical, possible or desired. I understand the aim, but let me ask my question a different way. Imagine there are nodes A&B that with clocks synched to DCF77. Imagine there are nodes C&D that with clocks synched to GPS. Node E has free running clock (possibly because the GPS receiver is down). Which packet format PDM type 1 or PDM type 2 do you use between each pair = of nodes, and how does the sending node know that? Scale this solution to 100K hosts. > > ---------------------------------------------------------------------- > -- -- Regards, RayH _______________________________________________ v6ops mailing list v6ops=40ietf.org https://www.ietf.org/mailman/listinfo/v6ops The information contained in this communication is highly confidential and = is intended solely for the use of the individual(s) to whom this = communication is directed. If you are not the intended recipient, you are = hereby notified that any viewing, copying, disclosure or distribution of = this information is prohibited. Please notify the sender, by electronic = mail or telephone, of any unintended receipt and delete the original = message without making any copies. =20 Blue Cross Blue Shield of Michigan and Blue Care Network of Michigan are = nonprofit corporations and independent licensees of the Blue Cross and = Blue Shield Association. From v6ops@globis.net Thu Oct 24 10:53:45 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BE93211E8389; Thu, 24 Oct 2013 10:53:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, 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 lhAtgmm-MqFl; Thu, 24 Oct 2013 10:53:44 -0700 (PDT) Received: from globis01.globis.net (RayH-1-pt.tunnel.tserv11.ams1.ipv6.he.net [IPv6:2001:470:1f14:62e::2]) by ietfa.amsl.com (Postfix) with ESMTP id 0758C21E809F; Thu, 24 Oct 2013 10:52:14 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by globis01.globis.net (Postfix) with ESMTP id 08B7F8700B3; Thu, 24 Oct 2013 19:51:56 +0200 (CEST) Received: from globis01.globis.net ([127.0.0.1]) by localhost (mail.globis.net [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7ZEcBsCHet+2; Thu, 24 Oct 2013 19:51:55 +0200 (CEST) Received: from Rays-iMac-2.local (unknown [192.168.0.3]) (Authenticated sender: Ray.Hunter@globis.net) by globis01.globis.net (Postfix) with ESMTPA id CED81870056; Thu, 24 Oct 2013 19:51:55 +0200 (CEST) Message-ID: <52695E3A.9090406@globis.net> Date: Thu, 24 Oct 2013 19:51:54 +0200 From: Ray Hunter User-Agent: Postbox 3.0.8 (Macintosh/20130427) MIME-Version: 1.0 To: "Ackermann, Michael" References: <20131017032024.5051.20799.idtracker@ietfa.amsl.com> <1381980305.36254.YahooMailNeo@web2803.biz.mail.ne1.yahoo.com> <5263C783.1080001@globis.net> <1382396300.22968.YahooMailNeo@web2801.biz.mail.ne1.yahoo.com> <526616C4.40304@globis.net> <4FC37E442D05A748896589E468752CAA0CA88734@PWN401EA160.ent.corp.bcbsm.com> In-Reply-To: <4FC37E442D05A748896589E468752CAA0CA88734@PWN401EA160.ent.corp.bcbsm.com> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: v6ops WG , "ippm@ietf.org" , 6man WG Subject: Re: [v6ops] Fw: New Version Notification for draft-elkins-6man-ipv6-pdm-dest-option-04.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 24 Oct 2013 17:53:46 -0000 > Ackermann, Michael > 24 October 2013 18:50 > Hi Ray. > And thanks again for all your insightful comments/questions. > > I am a little late in responding, so let me just tack on a little to what Nalini and others have already said. > > Your point 4 seems to indicate that all nodes in a desired time synchronization domain need to be synched to the same master clock. No. I think what I said was that the level of certainty in your measurements is dependent on the level of synchronisation of the 2 clock sources if you are calculating a delta of timestamp of clock 1 - timestamp clock 2. I think it might be instructive to go back and look at high school physics books on making measurements, precision, accuracy, and error estimations, especially when taking the difference of two measurements, or making other calculations on top of raw observations. For example, as far as I know, DFC-77 is not compensated for speed of light travel time from Frankfurt: that is a manual offset. So even if two nodes using DCF-77 that are geographically spread across Europe are perfectly synchronised to the incoming radio signal, they might have a constant offset compared to the "absolute" time in Frankfurt. That may or may not have an effect on one way trip measurement times you measure, depending on how you perform your calculations. I think this link might be instructive. http://www.hopf.com/en/dcf77-gps_en.html Equally a stratum 0 clock can be free running if it loses it's radio signal. I see time stamps in the picosecond range defined in the protocol, and errors on DCF-77 of up to 150mS...... completely different orders of magnitude of precision. > This has not been my experience. As long as the required Stratum level is realized, for the level of accuracy required by the situation or application, the proper level of time synchronization is achieved. Example would be that if one node in the NTP domain is referencing a GPS Stratum 0 and another node is referencing a separate Stratum 0 source, the two nodes should be Stratum 1 and within that level of accuracy. > This is something we have implemented across several disparate enterprises and it has worked well for us. I am wondering if your experience has yielded different results? Absolutely. Different NTP servers are not guaranteed to be synched to each other. They're close. But not in the picosecond range. > You also had two other points/questions, that I believe Nalini already responded to, but.............. > > 1. The possibility that "Middleboxes" could utilize PDM, is very intriguing to me. I believe this would be more difficult to add/implement, but worth the effort if the Middlebox vendors would perceive value and actually use PDM. Not sure how to determine if this would be the case or not? Why would it be difficult? If you can define the encoder in your protocol in terms of absolute local timestamps only, plus a provenance of the clock used for the timestamp, it would be a simple matter of inserting an additional destination header into every forwarded packet when the middlebox forwards it. > 2. It would be ideal to have only 1 PDM format that handles both time sycnronized and non synchronized situations. I do not readily see how to achieve this. Would love to talk to you some more if you have some ideas! Well for example, PDM 2 uses a local delta for the last packet transmission time: DELTALS. IMHO If you know absolute timestamp 1 of clock 1 @ last packet n sent from node 1, and absolute timestamp 2 of clock 1 @ last packet n+1 sent from node 1, I see it as a trivial matter to calculate the delta time between sending packet n and sending packet n+1 remotely at a decoder at a remote location (as observed at node 1), which will be identical to DELTALS, rather than calculating this value locally in the transmitting node 1 before sending the packet. [you can only encode this DELTALS value in packet 2.. anyway] I suspect the step that you are missing is coupling a timestamp to a clock and a packet ID and an event, and specifying only two timestamps in the packet, rather than both nodes timestamping the same events with their respective local clocks. You could also have timestamps for last received n from node 2 based on clock 1 sent in replies to packet n by node 1, and last received n+1 from node 2 based on clock1 sent in replies to packet n+1 by node 1, so that you can calculate DELTALR remotely too (as observed at the location of the receiving node 1). That way you avoid the need to calculate delta locally, or any need to track sessions in the transmitter (so that you can calculate a delta in the transmitter). You do obviously have to calculate a delta and track sessions in the decoder, but that is not time critical, and also can be applied to a subset of all traffic. > > Again, thanks for your great input, thoughts and questions!!! (and hopefully more to come). > > Mike > It seems to me that what you are essentially doing with this protocol is largely what NTP does anyway. So examining the NTP RFC might give you tips on what timestamps you need. And equally, since you are going to be sending high bandwidth synch traffic between 2 nodes, you might want to consider feeding the results back into NTP to see if you can improve the clock synchronisation between measuring nodes. -- Regards, RayH From joelja@bogus.com Thu Oct 24 11:14:50 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 85EE311E81C5; Thu, 24 Oct 2013 11:14:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.431 X-Spam-Level: X-Spam-Status: No, score=-102.431 tagged_above=-999 required=5 tests=[AWL=-0.432, BAYES_00=-2.599, J_CHICKENPOX_13=0.6, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VBs8g+YIrVom; Thu, 24 Oct 2013 11:14:49 -0700 (PDT) Received: from nagasaki.bogus.com (nagasaki.bogus.com [IPv6:2001:418:1::81]) by ietfa.amsl.com (Postfix) with ESMTP id 621D811E8200; Thu, 24 Oct 2013 11:14:47 -0700 (PDT) Received: from 00698a-hsutim.corp.zynga.com ([199.48.105.4]) (authenticated bits=0) by nagasaki.bogus.com (8.14.4/8.14.4) with ESMTP id r9OIEeJu029937 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Thu, 24 Oct 2013 18:14:42 GMT (envelope-from joelja@bogus.com) Content-Type: multipart/signed; boundary="Apple-Mail=_4C19CD7E-9716-48FB-A56B-DCFF30077490"; protocol="application/pgp-signature"; micalg=pgp-sha1 Mime-Version: 1.0 (Mac OS X Mail 7.0 \(1816\)) From: joel jaeggli In-Reply-To: <4FC37E442D05A748896589E468752CAA0CA88734@PWN401EA160.ent.corp.bcbsm.com> Date: Thu, 24 Oct 2013 11:14:35 -0700 Message-Id: <585D21EB-BD17-40C7-9C31-67F12EC6712F@bogus.com> References: <20131017032024.5051.20799.idtracker@ietfa.amsl.com> <1381980305.36254.YahooMailNeo@web2803.biz.mail.ne1.yahoo.com> <5263C783.1080001@globis.net> <1382396300.22968.YahooMailNeo@web2801.biz.mail.ne1.yahoo.com> <526616C4.40304@globis.net> <4FC37E442D05A748896589E468752CAA0CA88734@PWN401EA160.ent.corp.bcbsm.com> To: "Ackermann, Michael" X-Mailer: Apple Mail (2.1816) X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.7 (nagasaki.bogus.com [147.28.0.81]); Thu, 24 Oct 2013 18:14:43 +0000 (UTC) Cc: Ray Hunter , v6ops WG , "ippm@ietf.org" , 6man WG Subject: Re: [v6ops] New Version Notification for draft-elkins-6man-ipv6-pdm-dest-option-04.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 24 Oct 2013 18:14:50 -0000 --Apple-Mail=_4C19CD7E-9716-48FB-A56B-DCFF30077490 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 On Oct 24, 2013, at 9:50 AM, Ackermann, Michael = wrote: > Hi Ray. > And thanks again for all your insightful comments/questions.=20 >=20 > I am a little late in responding, so let me just tack on a little to = what Nalini and others have already said.=20 >=20 > Your point 4 seems to indicate that all nodes in a desired time = synchronization domain need to be synched to the same master clock. = This has not been my experience. As long as the required Stratum level = is realized, for the level of accuracy required by the situation or = application, the proper level of time synchronization is achieved. = Example would be that if one node in the NTP domain is referencing a GPS = Stratum 0 and another node is referencing a separate Stratum 0 source, = the two nodes should be Stratum 1 and within that level of accuracy. =20 stratum is not an indication of either precision or accuracy it=92s an = inidication of a position within the NTP heirachary. > This is something we have implemented across several disparate = enterprises and it has worked well for us. I am wondering if your = experience has yielded different results? >=20 > You also had two other points/questions, that I believe Nalini already = responded to, but.............. >=20 > 1. The possibility that "Middleboxes" could utilize PDM, is very = intriguing to me. I believe this would be more difficult to = add/implement, but worth the effort if the Middlebox vendors would = perceive value and actually use PDM. Not sure how to determine if this = would be the case or not?=20 >=20 > 2. It would be ideal to have only 1 PDM format that handles both time = sycnronized and non synchronized situations. I do not readily see how = to achieve this. Would love to talk to you some more if you have some = ideas! =20 >=20 > Again, thanks for your great input, thoughts and questions!!! (and = hopefully more to come). =20 >=20 > Mike >=20 >=20 >=20 >=20 >=20 > -----Original Message----- > From: v6ops-bounces@ietf.org [mailto:v6ops-bounces@ietf.org] On Behalf = Of Ray Hunter > Sent: Tuesday, October 22, 2013 2:10 AM > To: Nalini Elkins > Cc: v6ops WG; 6man WG; ippm@ietf.org > Subject: Re: [v6ops] Fw: New Version Notification for = draft-elkins-6man-ipv6-pdm-dest-option-04.txt >=20 >> Nalini Elkins >> 22 October 2013 00:58 >>> 1) encoding has to be fast, but decoding does not >>=20 >> True >>=20 >>> 2) a node's clock could be either in our out of synch with some=20 >>> notional master clock (e.g. via NTP) >>> 3) two clocks could be in synch to a master source, but the master =20= >>> sources may themselves not share a common source (one sourced from=20= >>> GPS, one from DCF77) >>> 4) the key to being able to perform the end to end calculations is=20= >>> whether two communicating nodes are synchronised to the same master=20= >>> clock (within some level of error/jitter) >>> 5) the absolute time is not particularly important >>=20 >>=20 >> This is true for PDM 1 only. PDM 2 does not require time = synchronization. >>=20 >>> Q1. Why do you want to encode differences as deltas in the case of = an unsynchronised/ free running clock? >>> Isn't that slow, and difficult for hardware implementations to = achieve (e.g. TCP offload)? Doesn't it also require maintaining large = amounts of state in the sending node. >>>=20 >>=20 >> 1. I think that it is going to be interesting to see how hardware is = going to handle TCP offload with IPv6 extension headers. I do not see = why PDM 2 would be so much harder than PDM 1 for an OS. >> Can you tell me which end host operating systems are doing TCP = offload in hardware? =20 > IMHO Not a relevant question. As a standards body we should be looking = to the future. There are many operations that are delegated to = microcode. >=20 > If you specified the packet with one single way of encapsulating = timestamps, then hardware or interface microcode could add the timestamp = at the last possible moment before the packet reached the wire, without = having to examine the original packet contents, or knowing the context = of the communicating nodes. I think that's very desirable. >> I know some OS's which process TCP segmentation in hardware. But = at this point, the packet is already crafted. Also some do IP checksum = offload in hardware but that does not apply to IPv6 as there is no IP = header checksum. >>=20 >>=20 >> 2. End hosts already maintain quite a bit of state. Every OS has = control blocks to handle events such as TCP duplicate packets, round = trip time, congestion window, etc. We are NOT suggesting >> that the PDM headers be used in middle boxes. That is, we are NOT = asking routers to maintain state. > So what? Why add to the problem? >=20 > Why does the timestamp require synchronisation with that other TCP = state? >=20 > Isn't it better to define a solution that is independent of the upper = layer header transport protocol? >=20 > Why not allow middleboxes (or node hardware) to insert the = timestamp header on the fly? >>=20 >>> Why not just encode the timestamp as-is and perform the appropriate = difference calculation during decoding? >>=20 >> If clocks are out of synch, you could end up having it look like you = received the packet before you sent it. >=20 > No. I'm not suggesting you use the same decoding algorithm: only that = you define a single common encoding algorithm that combines all the = information required for PDM 1 and PDM 2 calculations. Having to chose = which packet encoding to use in advance is problematic IMHO. >=20 >=20 >=20 >>> Q2. Why do you need two separate packet formats at all? >>=20 >>> Why not have a common format for all cases, containing a timestamp=20= >>> based on the local clock, plus an optional field containing a flag=20= >>> that states if the local timestamp is coordinated to some master=20 >>> clock, plus an identifier for the master clock. >>=20 >>> You could then encode whether a node had a free-running clock (case=20= >>> 2), a synchronised clock (case 1), and whether it was synched via = NTP=20 >>> to some stratum 0 source e.g. GPS, and also some identification of=20= >>> the stratum 1 source (IPv6 address). >>=20 >>> Two communicating nodes could then use e.g. NTP trace to see if they=20= >>> shared a common clock source or not, before performing their = calculations. >>=20 >> We are trying to craft a solution with PDM 2 for those situations = where time synchronization is not practical, possible or desired. >=20 > I understand the aim, but let me ask my question a different way. >=20 > Imagine there are nodes A&B that with clocks synched to DCF77. > Imagine there are nodes C&D that with clocks synched to GPS. > Node E has free running clock (possibly because the GPS receiver is = down). >=20 > Which packet format PDM type 1 or PDM type 2 do you use between each = pair of nodes, and how does the sending node know that? >=20 > Scale this solution to 100K hosts. >>=20 >> = ---------------------------------------------------------------------- >> -- >=20 >=20 > -- > Regards, > RayH >=20 > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops >=20 >=20 > The information contained in this communication is highly confidential = and is intended solely for the use of the individual(s) to whom this = communication is directed. If you are not the intended recipient, you = are hereby notified that any viewing, copying, disclosure or = distribution of this information is prohibited. Please notify the = sender, by electronic mail or telephone, of any unintended receipt and = delete the original message without making any copies. >=20 > Blue Cross Blue Shield of Michigan and Blue Care Network of Michigan = are nonprofit corporations and independent licensees of the Blue Cross = and Blue Shield Association. > -------------------------------------------------------------------- > IETF IPv6 working group mailing list > ipv6@ietf.org > Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 > -------------------------------------------------------------------- >=20 --Apple-Mail=_4C19CD7E-9716-48FB-A56B-DCFF30077490 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- Comment: GPGTools - http://gpgtools.org iEYEARECAAYFAlJpY4sACgkQ8AA1q7Z/VrKo/wCcDK5BXwTKRrJAadowt4znf186 rTgAnR/PcdhLLw8rsgOOhnTmlYlYh58I =5W5c -----END PGP SIGNATURE----- --Apple-Mail=_4C19CD7E-9716-48FB-A56B-DCFF30077490-- From markzzzsmith@yahoo.com.au Thu Oct 24 12:44:33 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C218511E81DC for ; Thu, 24 Oct 2013 12:44:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.785 X-Spam-Level: X-Spam-Status: No, score=-1.785 tagged_above=-999 required=5 tests=[AWL=0.314, BAYES_00=-2.599, FROM_LOCAL_NOVOWEL=0.5] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QQweMCGUX8oG for ; Thu, 24 Oct 2013 12:44:28 -0700 (PDT) Received: from nm39-vm9.bullet.mail.bf1.yahoo.com (nm39-vm9.bullet.mail.bf1.yahoo.com [72.30.239.153]) by ietfa.amsl.com (Postfix) with ESMTP id 2586011E8209 for ; Thu, 24 Oct 2013 12:44:20 -0700 (PDT) Received: from [98.139.215.140] by nm39.bullet.mail.bf1.yahoo.com with NNFMP; 24 Oct 2013 19:44:20 -0000 Received: from [98.139.212.215] by tm11.bullet.mail.bf1.yahoo.com with NNFMP; 24 Oct 2013 19:44:20 -0000 Received: from [127.0.0.1] by omp1024.mail.bf1.yahoo.com with NNFMP; 24 Oct 2013 19:44:20 -0000 X-Yahoo-Newman-Property: ymail-3 X-Yahoo-Newman-Id: 86529.3286.bm@omp1024.mail.bf1.yahoo.com Received: (qmail 42297 invoked by uid 60001); 24 Oct 2013 19:44:19 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com.au; s=s1024; t=1382643859; bh=5gZmKSjSvTChVWxPsf45i8IuwB6Hvy5bAhTtpKWzxKs=; h=X-YMail-OSG:Received:X-Rocket-MIMEInfo:X-Mailer:References:Message-ID:Date:From:Reply-To:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type:Content-Transfer-Encoding; b=mK/rIp5/Q/KzWPdM6qxQ9rZR5FGKi5ZSFBiVtDuC0H3Uf8w21pDAEr4P6i5FvHyaIBblIshSMfbEseN6xDX4GWScyjh4m2st1zlTILce1+3NyYrk5YhYeBqFbOPW8PfabUodrbez3OVnKaISZQElS963dybCEr1XbuqUnbR+sUc= DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com.au; h=X-YMail-OSG:Received:X-Rocket-MIMEInfo:X-Mailer:References:Message-ID:Date:From:Reply-To:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type:Content-Transfer-Encoding; b=AK8wylmoFNTho7mdJ4OmdzslBE7w7Rn1KlNke2+cZokPssQeE9Duy4oGdYMluUi6yqQlc5neLCkZm+SZ0Yqf0tfybl3QEWd2Y0XLwhltqPuVjv4SZaWR0E3UIehAKhJgL2jpxg68jOv4wUuzFQRi3hT3JthR2KTPzlct8RUXSYE=; X-YMail-OSG: rIuyjAMVM1kFTbjddKH41dYo_PbhST3B_Ei1sQhzi.nSaQ9 E7kMfAc7.7uMuh_Thj212u5eHLUVxnlKuaa6N_DX2jrBb3bAybs__7aMW139 US9bJErFaB.6Np_oCRC_1S66kvM7KaROLTeqmDeIyvrIO2dhVuKiIaDyyfiO P5kI.G2U9Pd69n8pZlyjfn3KJH1NCyLrSRgcon2LqBJE3kPlcICROhkvfCsA etUMUMnm_7i_IZZDRzX36hZFA31ASz5_9eyPRp9kejmj8DO73B6UiXlAmShe DqLtok_Ag8b6NBN6jzjfwswiSJpNfsrIdKrDKBKenAsLr28pdU4rBTvnyeCb D.YFlx3rrf0R5qNKu8sHbHd8PMBh.ZN0W8OCAFV5Mo4zisqzgb.hLjzZMNiM _38DXkOI2ULRbPGAw.4.pydpA2CSSOdufVYZ6W8biTj_VCKPUjSVQnBjXduB abqRo6F04cdoy9FifSzTPpn2NMDRPbOY8UhklVD7WwoR3PlvU7FViWdn0jtF NiYgxAUhzTDEwrjyvUI8mWSDyd57KhsSGcW.P7d4EV5WsNqmotgG0p0nw6Pi H.j6w5y4Fg4_5m8ipW_B2GCWAFJsUghweoU6CitUY0g-- Received: from [150.101.221.237] by web142503.mail.bf1.yahoo.com via HTTP; Thu, 24 Oct 2013 12:44:18 PDT X-Rocket-MIMEInfo: 002.001, CgoKCi0tLS0tIE9yaWdpbmFsIE1lc3NhZ2UgLS0tLS0KPiBGcm9tOiBOaWNrIEhpbGxpYXJkIDxuaWNrQGluZXguaWU.Cj4gVG86IE1hcmsgWlpaIFNtaXRoIDxtYXJrenp6c21pdGhAeWFob28uY29tLmF1PjsgT2xlIFRyb2FuIChvdHJvYW4pIDxvdHJvYW5AY2lzY28uY29tPgo.IENjOiAidjZvcHNAaWV0Zi5vcmciIDx2Nm9wc0BpZXRmLm9yZz47ICJkcmFmdC1saXUtYm9uaWNhLXY2b3BzLWRoY3B2Ni1zbGFhYy1wcm9ibGVtQHRvb2xzLmlldGYub3JnIiA8ZHJhZnQtbGl1LWJvbmljYS12Nm9wcy1kaGNwdjYBMAEBAQE- X-Mailer: YahooMailWebService/0.8.160.587 References: <201310211245.r9LCj0B29668@ftpeng-update.cisco.com> <8AE0F17B87264D4CAC7DE0AA6C406F453D7CC14B@nkgeml506-mbx.china.huawei.com> <1382469405.56346.YahooMailNeo@web142504.mail.bf1.yahoo.com> <1382519509.39565.YahooMailNeo@web142502.mail.bf1.yahoo.com> <55F2A998-0417-4C19-B248-AA2A80EBF29C@cisco.com> <52679F9F.7040403@inex.ie> <1382556056.28376.YahooMailNeo@web142505.mail.bf1.yahoo.com> <52689EE0.3030201@inex.ie> Message-ID: <1382643858.41679.YahooMailNeo@web142503.mail.bf1.yahoo.com> Date: Thu, 24 Oct 2013 12:44:18 -0700 (PDT) From: Mark ZZZ Smith To: Nick Hilliard , "Ole Troan \(otroan\)" In-Reply-To: <52689EE0.3030201@inex.ie> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Cc: "v6ops@ietf.org" , "draft-liu-bonica-v6ops-dhcpv6-slaac-problem@tools.ietf.org" Subject: Re: [v6ops] DHCPv6/SLAAC Make Hosts Confusing-//RE: new draft: draft-liu-bonica-v6ops-dhcpv6-slaac-problem X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: Mark ZZZ Smith List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 24 Oct 2013 19:44:33 -0000 =0A=0A=0A=0A----- Original Message -----=0A> From: Nick Hilliard =0A> To: Mark ZZZ Smith ; Ole Troan (otroan)= =0A> Cc: "v6ops@ietf.org" ; "draft-liu-b= onica-v6ops-dhcpv6-slaac-problem@tools.ietf.org" =0A> Sent: Thursday, 24 October 2013 3:15= PM=0A> Subject: Re: [v6ops] DHCPv6/SLAAC Make Hosts Confusing-//RE: new dr= aft: draft-liu-bonica-v6ops-dhcpv6-slaac-problem=0A> =0A> On 24/10/2013 03:= 20, Mark ZZZ Smith wrote:=0A>> RAs are prehaps misnamed. They're not reall= y router advertisements,=0A>> they're advertisements (typically) sent from= routers. View them as =0A> layer=0A>> 3 configuration protocol packets, b= ecause they do far more than=0A>> advertise a default router, and don't ev= en need to advertise a default=0A>> router to be useful.=0A> =0A> I know w= hat RAs are.=A0 Both protocols provide info to network hosts=0A> necessary = for functional ipv6 connectivity.=A0 They have different=0A> approaches, bu= t they are both lan configuration protocols.=0A> =0A> If you feel that SLAA= C+DHCPv6 or SLAAC only is the right thing for you,=0A> then that's great an= d I'm really happy for you.=0A> =0A> There is a tiny amount of protocol glu= e missing which would allow dhcpv6 to=0A> act as a fully functional standal= one protocol=0A=0ANo, there is lots of glue missing. You'd have to define D= HCPv6 options for all of the functions I listed. You'd also have to define = an option conflict resolution method or methods for those options, when the= y happen to be supplied by both RAs and DHCPv6. It may be argued that an ne= twork operator shouldn't be doing this, but it might happen accidentally, b= ecause your mother is not a network operator, and in the interests of robus= tness, and more importantly Internet user satisfaction (also your mother), = the IETF must not ignore those consequences.=0A=0ABy leaving these RA optio= ns out of DHCPv6, the IETF is doing better - it is preventing this problem = ever occurring, rather than having to then solve it after having then just = creating it. I don't think this problem has been solved for DNS options in = RAs (duplication in the other direction), so I won't be confident people wo= uld get around to solving it if RA options are put in DHCPv6.=0A=0A=0A>, an= d the various attempts to=0A> introduce this glue have been shot down repea= tedly,=0A> mostly on the basis of=0A=0A> arguments like "how do you expect = your network to work when critical=0A> components of your network are broke= n?", "we don't like =0A> duplication of=0A> functionality at the IETF (but = we'll ignore all the other duplicated=0A> functionality in other ietf proto= cols)"=0A=0ASo you solve the problem of excess duplication by creating more= ?=A0=0A=0A> or "polling sucks".=0A=0A> =0A> None of these points address th= e core issue which is that there are a lot=0A> of operators who have a stro= ng preference to use a single lan configuration=0A> protocol instead of two= protocols with strongly overlapping functionality=0A=0AIf you take address= configuration out of DHCPv6, there is no overlapping functionality. Addres= s configuration in DHCPv6 is the thing that is not correctly placed in my o= pinion, not the existence RAs.=A0=0A=0A=0ARAs should be limited to configur= ing layer 3 IPv6 parameters only, solving the network layer configuration p= roblem, on a per link/subnet basis. Different links can have different laye= r 3 parameters, so the place to provide those parameters is on a per-link b= asis, using a link-local protocol.=0A=0ADHCPv6 should be limited to providi= ng primarily application parameters (and perhaps layer 4 parameters) to hos= ts, solving the end-to-end configuration problem. This problem exists regar= dless of the network layer parameters, and the parameters for applications = are not restricted to being subnet specific, they're more likely to be glob= al across the network, so a solution needs to be subnet/link-local protocol= independent.=0A=0Ahttp://tools.ietf.org/html/draft-smith-v6ops-ce-dhcpv6-t= ransparency-00#section-2=0A=0A=0A=0AIf you shove everything into DHCPv6, yo= u now start having a circular dependency problem - DHCPv6 requires UDP to w= ork, which requires IPv6 to work, which requires DHCPv6 to work, which requ= ires UDP to work etc., etc.,=0A=0A> and an ambiguous and poorly defined int= eraction model.=0A> =0A> There is no reason for DHCP not to to be standalon= e-capable, so that=0A> operators can make up their own minds about what to = use on their networks.=0A> =0A> I completely understand that you want to us= e SLAAC on your networks: please=0A> stop insisting that I run it on mine.= =0A>=A0=0A=0AI'm not thinking of you, you're capable of running a network a= nd fixing complicated problems with it. I'm thinking of my mother. How can = she build a working IPv6 network without bothering me. Appletalk and IPX ac= hieved this 20 years ago, it is time the Internet protocols met their stand= ards of user friendliness. Avoiding duplication and function conflict visib= le to end-users is one of the best ways to achieve that.=0A=0A> Incidentall= y a couple of minutes ago, Andrew Sullivan just spoke these=0A> words about= the IETF at IGF2013 in Bali:=0A> =0A> "We're not in the business of tellin= g people how to run their =0A> networks".=0A>=A0=0A=0AThat's true if you do= n't have to care about interoperability and ease of use.=0A=0ALess is more.= =A0Complex equals more things that can break.=0A=0A=0A> =0A> Nick=0A> =0A>>= They can be use for:=0A>> =0A>> - changing host MTUs, instead of individ= ual manual configuration on each =0A> host=0A>> - announce on-link presenc= e of prefixes, exclusive of whether hosts have =0A> addresses within the pr= efix, instead of individual manual configuration on each =0A> host=0A>> - = adjust neighbor discovery parameters (e.g., timers), instead of =0A> indivi= dual manual configuration on each host=0A>> - announce prefix(es) to be us= ed to generate SLAAC addresses, instead of =0A> individual manual configura= tion on each host=0A>> - indicate to hosts whether to use DHCPv6 or SLAAC = or both (during a =0A> transition between SLAAC/DHCPv6 or vice-versa), inst= ead of individual manual =0A> configuration on each host=0A>> - advertise = a default router, and an associated lifetime, instead of =0A> individual ma= nual configuration on each host=0A>> =0A>> =0A>> =0A>> =0A>>> networks.=0A= >>> =0A>>> Nick=0A>>> =0A>> =0A> From victor@jvknet.com Thu Oct 24 13:45:30 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9757311E8196 for ; Thu, 24 Oct 2013 13:45:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.918 X-Spam-Level: X-Spam-Status: No, score=-2.918 tagged_above=-999 required=5 tests=[AWL=0.366, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, SARE_MILLIONSOF=0.315] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FcgKv50RO987 for ; Thu, 24 Oct 2013 13:45:25 -0700 (PDT) Received: from mail-ie0-f171.google.com (mail-ie0-f171.google.com [209.85.223.171]) by ietfa.amsl.com (Postfix) with ESMTP id D159A11E8392 for ; Thu, 24 Oct 2013 13:45:21 -0700 (PDT) Received: by mail-ie0-f171.google.com with SMTP id tp5so5041265ieb.30 for ; Thu, 24 Oct 2013 13:45:20 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:user-agent:date:subject:from:to:cc:message-id :thread-topic:in-reply-to:mime-version:content-type :content-transfer-encoding; bh=cp5QSi4h29F41Fepbft6PiP+79aanX8o+cr3/SHq6Uo=; b=HYJGJpRiA03m3WcDcy+6DtPHUJ2ZsFxtlAoN0gu4FZNGIs3jDoKJG7IzbMbKrfAc9F M2S518nVBcicwt6GmCXSjKMK6b6OGUL7YF2y0iHqVpqDNXQlRGFFZzmfABgXI1g8zy7S FuqugdhlRp8JIsVq8JvZgXxsf+7POiFnNpsmgewNAtDI+D2KXHIuosCscCtJ7ae0m+i4 /XL7Jj/2Kixh+mSKSOiKF+Ry3x6P9kHjhc1paj1t6eJTOvX/W2YDe6i5xQVl//nec0ax C1AY1wIdpUb8wL6cq56fRO6JcymDRkDkhzaaEk0H1jpglLAI43qNd6fASnThKXZ6OA1a rlZw== X-Gm-Message-State: ALoCoQlIquG3Ny5UN1LTsMx0B2Ye6jFqrnhWMUZEjWmKFHmnULBMkGwxpvdgu7fUC5i+iju/Puca X-Received: by 10.50.16.45 with SMTP id c13mr3220731igd.55.1382647520364; Thu, 24 Oct 2013 13:45:20 -0700 (PDT) Received: from [192.168.100.52] ([67.224.83.162]) by mx.google.com with ESMTPSA id q6sm407588igi.0.2013.10.24.13.45.18 for (version=TLSv1 cipher=RC4-SHA bits=128/128); Thu, 24 Oct 2013 13:45:19 -0700 (PDT) User-Agent: Microsoft-MacOutlook/14.10.0.110310 Date: Thu, 24 Oct 2013 16:45:15 -0400 From: Victor Kuarsingh To: Mark ZZZ Smith , Nick Hilliard , "Ole Troan (otroan)" Message-ID: Thread-Topic: [v6ops] DHCPv6/SLAAC Make Hosts Confusing-//RE: new draft: draft-liu-bonica-v6ops-dhcpv6-slaac-problem In-Reply-To: <1382643858.41679.YahooMailNeo@web142503.mail.bf1.yahoo.com> Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit Cc: "v6ops@ietf.org" , "draft-liu-bonica-v6ops-dhcpv6-slaac-problem@tools.ietf.org" Subject: Re: [v6ops] DHCPv6/SLAAC Make Hosts Confusing-//RE: new draft: draft-liu-bonica-v6ops-dhcpv6-slaac-problem X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 24 Oct 2013 20:45:30 -0000 Mark, On 2013-10-24 3:44 PM, "Mark ZZZ Smith" wrote: > >RAs should be limited to configuring layer 3 IPv6 parameters only, >solving the network layer configuration problem, on a per link/subnet >basis. Different links can have different layer 3 parameters, so the >place to provide those parameters is on a per-link basis, using a >link-local protocol. > >DHCPv6 should be limited to providing primarily application parameters >(and perhaps layer 4 parameters) to hosts, solving the end-to-end >configuration problem. This problem exists regardless of the network >layer parameters, and the parameters for applications are not restricted >to being subnet specific, they're more likely to be global across the >network, so a solution needs to be subnet/link-local protocol independent. > >http://tools.ietf.org/html/draft-smith-v6ops-ce-dhcpv6-transparency-00#sec >tion-2 > I am not arguing against these points, but have a few questions and comments to this approach. Based on the approach above, it appears that in the model you describe, DHCPv6 would not provide layer 3 addresses to end hosts (from the position of many operators, that's the first router or host behind their access facility). It this in fact what you are thinking, I believe there are a number of issues that should be considered to that approach (if this is not what you are describing, then ignore my next few statements). Pushing addressing to the operators edge would effectively decentralize addressing in large operator networks. This may introduce significant challenges for those operators (often managing millions of endpoints). Also, pushing more work the the edge routers should be done with caution. Edge routers are already becoming bogged down with code, and adding more state and/or work for that device can exasperate this issue (sometimes it takes months to over a year to get a code drop which can actually be put into production). Pushing the configuration to a centralized function like DHCP has definite advantages in larger operators environments, providing the ability to manage very large infrastructures. It also provides them an ability to standardize addressing across many different access types and/or platform versions. If we push this function to the edge, then we will need to chase many vendors constantly, to keep up with the needs of this function. Keeping the edge simple, and allowing the centralized functions to take on the task of addressing and administering many of these configuration functions makes the infrastructure much more manageable (and in my experience, more stable which translates into a better user experience). Of course, I am only talking about one (significant) use case, and any changes and/or agreement on what to do with DHCPv6 and/or RAs needs to take in to account all the use cases. Regards, Victor K > From mackermann@bcbsm.com Thu Oct 24 16:45:15 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3FE2711E825F for ; Thu, 24 Oct 2013 16:45:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.048 X-Spam-Level: X-Spam-Status: No, score=-6.048 tagged_above=-999 required=5 tests=[AWL=-0.049, BAYES_00=-2.599, J_CHICKENPOX_13=0.6, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Flj6b9kS1KL1 for ; Thu, 24 Oct 2013 16:45:15 -0700 (PDT) Received: from mx.z120.zixworks.com (mx.z120.zixworks.com [199.30.235.120]) by ietfa.amsl.com (Postfix) with ESMTP id B8E7111E8224 for ; Thu, 24 Oct 2013 16:45:12 -0700 (PDT) Received: from vmvpm01.z120.zixworks.com (ZixVPM [127.0.0.1]) by Outbound.z120.zixworks.com (Proprietary) with ESMTP id 352B59AD9FD for ; Thu, 24 Oct 2013 18:45:08 -0500 (CDT) Received: from imsva1.bcbsm.com (unknown [12.107.172.80]) by mx.z120.zixworks.com (Proprietary) with SMTP id EC5BF9AD9E9; Thu, 24 Oct 2013 18:45:06 -0500 (CDT) Received: from imsva1.bcbsm.com (unknown [127.0.0.1]) by IMSVA80 (Postfix) with ESMTP id DEE554F804D; Thu, 24 Oct 2013 19:34:51 -0400 (EDT) Received: from pwn401ea100.ent.corp.bcbsm.com (unknown [10.64.80.217]) by imsva1.bcbsm.com (Postfix) with ESMTP id D10194F8049; Thu, 24 Oct 2013 19:34:51 -0400 (EDT) Received: from PWN401EA160.ent.corp.bcbsm.com ([fe80::fdcb:603d:469e:b1db]) by PWN401EA100.ent.corp.bcbsm.com ([fe80::8db:9ce7:e2cf:8565%13]) with mapi id 14.01.0438.000; Thu, 24 Oct 2013 19:44:52 -0400 From: "Ackermann, Michael" To: Ray Hunter Thread-Topic: [v6ops] Fw: New Version Notification for draft-elkins-6man-ipv6-pdm-dest-option-04.txt Thread-Index: AQHO0OGzc1wNgnhly0SIwwwBJHHHZZoEfl4g Date: Thu, 24 Oct 2013 23:44:51 +0000 Message-ID: <4FC37E442D05A748896589E468752CAA0CA8A36F@PWN401EA160.ent.corp.bcbsm.com> References: <20131017032024.5051.20799.idtracker@ietfa.amsl.com> <1381980305.36254.YahooMailNeo@web2803.biz.mail.ne1.yahoo.com> <5263C783.1080001@globis.net> <1382396300.22968.YahooMailNeo@web2801.biz.mail.ne1.yahoo.com> <526616C4.40304@globis.net> <4FC37E442D05A748896589E468752CAA0CA88734@PWN401EA160.ent.corp.bcbsm.com> <52695E3A.9090406@globis.net> In-Reply-To: <52695E3A.9090406@globis.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.64.10.35] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: v6ops WG , 6man WG , "ippm@ietf.org" Subject: Re: [v6ops] Fw: New Version Notification for draft-elkins-6man-ipv6-pdm-dest-option-04.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 24 Oct 2013 23:45:15 -0000 Ray Your Comment:=20 No. I think what I said was that the level of certainty in your = measurements is dependent on the level of synchronisation of the 2 clock = sources if you are calculating a delta of timestamp of clock 1 - timestamp = clock 2. My Response: Then it sounds like we are in agreement. Given the appropriate stratum = level at both nodes, the desired level of time synchronization is = achieved.=20 Your Comment:=20 I think it might be instructive to go back and look at high school physics = books on making measurements, precision, accuracy, and error estimations, = especially when taking the difference of two measurements, or making other = calculations on top of raw observations My Response: Not sure exactly what this means but I can say that this = sounds like theoretical doubt that time synchronization will not work = properly in geographically dispersed environments? I can tell you that = it does in our experiences and that the surrounding = protocols/implementations are crafted to account for such vicissitudes. =20 I will say that I have no field experience with DCF-77 sources, only GPS = and Cesium. =20 Your Comment: Equally a stratum 0 clock can be free running if it loses it's radio signal. My Response:=20 This comment sort of confused me as well, but suffice to say, if any = component is broken, results will be impaired. Obviously this is not = limited to the time synch subject. =20 Finally, your comment about =22Middleboxes=22. I hope it can be as = simple to accommodate as you describe. My concern is that if there are = numerous middleboxes, the fields may get repetitively overlaid, or there = will need to be so many separate fields, we could incur excessive = complexity or overhead. Given that we can accomplish this with a = workable solution, I am certainly all for it. =20 The more information I can have to manage networks and solve problems, the = better=21 Thanks again for your thoughts, inputs and questions=21 Mike =20 -----Original Message----- From: Ray Hunter =5Bmailto:v6ops=40globis.net=5D=20 Sent: Thursday, October 24, 2013 1:52 PM To: Ackermann, Michael Cc: Nalini Elkins; v6ops WG; 6man WG; ippm=40ietf.org Subject: Re: =5Bv6ops=5D Fw: New Version Notification for = draft-elkins-6man-ipv6-pdm-dest-option-04.txt > Ackermann, Michael > 24 October 2013 18:50 > Hi Ray. > And thanks again for all your insightful comments/questions.=20 > > I am a little late in responding, so let me just tack on a little to = what Nalini and others have already said.=20 > > Your point 4 seems to indicate that all nodes in a desired time = synchronization domain need to be synched to the same master clock.=20 No. I think what I said was that the level of certainty in your = measurements is dependent on the level of synchronisation of the 2 clock = sources if you are calculating a delta of timestamp of clock 1 - timestamp = clock 2. I think it might be instructive to go back and look at high school physics = books on making measurements, precision, accuracy, and error estimations, = especially when taking the difference of two measurements, or making other = calculations on top of raw observations. For example, as far as I know, DFC-77 is not compensated for speed of = light travel time from Frankfurt: that is a manual offset. So even if two = nodes using DCF-77 that are geographically spread across Europe are = perfectly synchronised to the incoming radio signal, they might have a = constant offset compared to the =22absolute=22 time in Frankfurt. That may = or may not have an effect on one way trip measurement times you measure, = depending on how you perform your calculations. I think this link might be instructive. http://www.hopf.com/en/dcf77-gps_en.html Equally a stratum 0 clock can be free running if it loses it's radio signal. I see time stamps in the picosecond range defined in the protocol, and = errors on DCF-77 of up to 150mS...... completely different orders of = magnitude of precision. > This has not been my experience. As long as the required Stratum = level is realized, for the level of accuracy required by the situation or = application, the proper level of time synchronization is achieved. = Example would be that if one node in the NTP domain is referencing a GPS = Stratum 0 and another node is referencing a separate Stratum 0 source, the = two nodes should be Stratum 1 and within that level of accuracy. =20 > This is something we have implemented across several disparate = enterprises and it has worked well for us. I am wondering if your = experience has yielded different results? Absolutely. Different NTP servers are not guaranteed to be synched to each = other. They're close. But not in the picosecond range. > You also had two other points/questions, that I believe Nalini already = responded to, but.............. > > 1. The possibility that =22Middleboxes=22 could utilize PDM, is very = intriguing to me. I believe this would be more difficult to = add/implement, but worth the effort if the Middlebox vendors would = perceive value and actually use PDM. Not sure how to determine if this = would be the case or not?=20 Why would it be difficult? If you can define the encoder in your protocol = in terms of absolute local timestamps only, plus a provenance of the clock = used for the timestamp, it would be a simple matter of inserting an = additional destination header into every forwarded packet when the = middlebox forwards it. > 2. It would be ideal to have only 1 PDM format that handles both time = sycnronized and non synchronized situations. I do not readily see how to = achieve this. Would love to talk to you some more if you have some = ideas=21 =20 Well for example, PDM 2 uses a local delta for the last packet = transmission time: DELTALS. IMHO If you know absolute timestamp 1 of clock 1 =40 last packet n sent = from node 1, and absolute timestamp 2 of clock 1 =40 last packet n+1 sent = from node 1, I see it as a trivial matter to calculate the delta time = between sending packet n and sending packet n+1 remotely at a decoder at a = remote location (as observed at node 1), which will be identical to = DELTALS, rather than calculating this value locally in the transmitting = node 1 before sending the packet. =5Byou can only encode this DELTALS = value in packet 2.. anyway=5D I suspect the step that you are missing is coupling a timestamp to a clock = and a packet ID and an event, and specifying only two timestamps in the = packet, rather than both nodes timestamping the same events with their = respective local clocks. You could also have timestamps for last received n from node 2 based on = clock 1 sent in replies to packet n by node 1, and last received n+1 from = node 2 based on clock1 sent in replies to packet n+1 by node 1, so that = you can calculate DELTALR remotely too (as observed at the location of the = receiving node 1). That way you avoid the need to calculate delta locally, = or any need to track sessions in the transmitter (so that you can = calculate a delta in the transmitter). You do obviously have to calculate = a delta and track sessions in the decoder, but that is not time critical, = and also can be applied to a subset of all traffic. > > Again, thanks for your great input, thoughts and questions=21=21=21 = (and hopefully more to come). =20 > > Mike > It seems to me that what you are essentially doing with this protocol is = largely what NTP does anyway. So examining the NTP RFC might give you tips on what timestamps you need. = And equally, since you are going to be sending high bandwidth synch = traffic between 2 nodes, you might want to consider feeding the results = back into NTP to see if you can improve the clock synchronisation between = measuring nodes. -- Regards, RayH The information contained in this communication is highly confidential and = is intended solely for the use of the individual(s) to whom this = communication is directed. If you are not the intended recipient, you are = hereby notified that any viewing, copying, disclosure or distribution of = this information is prohibited. Please notify the sender, by electronic = mail or telephone, of any unintended receipt and delete the original = message without making any copies. =20 Blue Cross Blue Shield of Michigan and Blue Care Network of Michigan are = nonprofit corporations and independent licensees of the Blue Cross and = Blue Shield Association. From holger.metschulat@telekom.de Fri Oct 25 06:04:21 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0A7D511E83E0 for ; Fri, 25 Oct 2013 06:04:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.249 X-Spam-Level: X-Spam-Status: No, score=-3.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id a7C5TO9U0ws3 for ; Fri, 25 Oct 2013 06:04:16 -0700 (PDT) Received: from tcmail43.telekom.de (tcmail43.telekom.de [80.149.113.173]) by ietfa.amsl.com (Postfix) with ESMTP id 7A58511E831D for ; Fri, 25 Oct 2013 06:04:12 -0700 (PDT) From: Received: from he111510.emea1.cds.t-internal.com ([10.206.92.113]) by tcmail41.telekom.de with ESMTP/TLS/AES128-SHA; 25 Oct 2013 15:04:10 +0200 Received: from HE111490.emea1.cds.t-internal.com ([10.206.92.87]) by HE111510.emea1.cds.t-internal.com ([::1]) with mapi; Fri, 25 Oct 2013 15:04:10 +0200 To: Date: Fri, 25 Oct 2013 15:04:09 +0200 Thread-Topic: [v6ops] new draft: draft-byrne-v6ops-clatip Thread-Index: Ac7Gf9DowRmN9HMfSWCYX3uNm9/78gKya7pw Message-ID: References: <201310111245.r9BCj0319881@ftpeng-update.cisco.com> In-Reply-To: <201310111245.r9BCj0319881@ftpeng-update.cisco.com> Accept-Language: de-DE Content-Language: de-DE X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: de-DE Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Cc: draft-byrne-v6ops-clatip@tools.ietf.org Subject: Re: [v6ops] new draft: draft-byrne-v6ops-clatip X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 25 Oct 2013 13:04:21 -0000 SGkgYWxsLA0KDQpJIHRoaW5rIHRoaXMgaXMgYSB2YWx1ZWFibGUgZHJhZnQsIG1ha2luZyBzdXJl IHRoYXQgdGhlIENMQVQgSVAgYWRkcmVzcyBpcyB3ZWxsLWRlZmluZWQgYW5kIGRvZXMgbm90IGNv bGxpZGUgd2l0aCBvdGhlciB1c2UgY2FzZXMgd2hlbiB1c2luZyBSRkMxOTE4IGFkZHJlc3NlcyBh cyB0aGUgQ0xBVCBJUCBhZGRyZXNzLg0KDQpTb21lIHRob3VnaHRzOg0KDQotIENhbiB3ZSBleGNs dWRlIHRoYXQgYSBVRSBpcyB1c2luZyBDTEFUIGFuZCBEUy1MaXRlIGF0IHRoZSBzYW1lIHRpbWU/ DQotIFNob3VsZCB3ZSBhbHNvIG5haWwgZG93biBhIHNwZWNpZmljIElQIGFkZHJlc3Mgb3V0IG9m IHRoYXQgcmFuZ2UgKGUuZy4gMTkyLjAuMC4zKSBmb3IgdGhlIENMQVQgaW50ZXJmYWNlIHdpdGgg dGhlIGZyZWVkb20gdG8gY2hvb3NlIGEgZGlmZmVyZW50IElQIGFkZHJlc3Mgb3V0IG9mIHRoYXQg c3VibmV0IGlmIG5lY2Vzc2FyeT8NCi0gU29tZSBhcHBsaWNhdGlvbiBpbXBsZW1lbnRhdGlvbnMg c3dpdGNoIHRvICJJIGFtIGJlaGluZCBOQVQgbW9kZSIgd2hlbiBzZWVpbmcgYW4gUkZDMTkxOCBh ZGRyZXNzIGFuZCBiZWhhdmUgZGlmZmVyZW50bHkgdGhhbiBkaXJlY3RseSBjb25uZWN0ZWQgdG8g dGhlIEludGVybmV0IHdpdGhvdXQgTkFULiBUaGlzIChpbiBteSBvcGluaW9uKSBiYWQgIk5BVCBk aXNjb3ZlcnkiIHdpbGwgbm90IGJlIHRyaWdnZXJlZCB3aXRoIHRoaXMgSVAgYWRkcmVzcyByYW5n ZS4NCi0gVGhlIHJlcXVpcmVtZW50cyB0b3dhcmRzIHRoZSBDTEFUIElQdjQgYWRkcmVzcyBzaG91 bGQgYmUgYmV0dGVyIGRlc2NyaWJlZC4gSW4gdGhlIGRyYWZ0LCBJIHJlYWQgImxvY2FsbHkgdW5p cXVlIElQdjQgYWRkcmVzcyIgYW5kICJ1bmlxdWUgYWRkcmVzcyIgLSBzaG91bGQgYmUgd29yZGVk IGxpa2UgIklQdjQgYWRkcmVzcyB0aGF0IG11c3QgYmUgdW5pcXVlIHdpdGhpbiB0aGUgVUUgYW5k IG11c3Qgbm90IGJlIHVzZWQgYnkgYW55IGhvc3QgdGhlIFVFIG1heSBjb25uZWN0IHRvIi4NCg0K DQpNeSDigqwwLjAxLA0KDQpIb2xnZXI= From jmh@joelhalpern.com Fri Oct 25 07:02:44 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 946D111E8316 for ; Fri, 25 Oct 2013 07:02:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.356 X-Spam-Level: X-Spam-Status: No, score=-102.356 tagged_above=-999 required=5 tests=[AWL=-0.357, BAYES_00=-2.599, J_CHICKENPOX_13=0.6, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RzuziL8Kk8gC for ; Fri, 25 Oct 2013 07:02:40 -0700 (PDT) Received: from mailc2.tigertech.net (mailc2.tigertech.net [208.80.4.156]) by ietfa.amsl.com (Postfix) with ESMTP id 1705611E83DB for ; Fri, 25 Oct 2013 07:02:38 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mailc2.tigertech.net (Postfix) with ESMTP id F20287C; Fri, 25 Oct 2013 07:02:37 -0700 (PDT) X-Virus-Scanned: Debian amavisd-new at c2.tigertech.net Received: from Joels-MacBook-Pro.local (c213-89-137-101.bredband.comhem.se [213.89.137.101]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mailc2.tigertech.net (Postfix) with ESMTPSA id 130797B; Fri, 25 Oct 2013 07:02:36 -0700 (PDT) Message-ID: <526A79FB.8010101@joelhalpern.com> Date: Fri, 25 Oct 2013 10:02:35 -0400 From: "Joel M. Halpern" User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:17.0) Gecko/20130801 Thunderbird/17.0.8 MIME-Version: 1.0 To: Lorenzo Colitti References: <28CFF7E5-E98E-4D97-B7F4-3A18C255253C@gigix.net> <5267E96B.1000802@innovationslab.net> <20131023152549.GN50205@Space.Net> <5267EB60.7080105@innovationslab.net> <5267ED12.4090602@innovationslab.net> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: "v6ops@ietf.org WG" Subject: Re: [v6ops] Revised Internet Drafts for allocation of IPv6 space for LISP EIDs X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 25 Oct 2013 14:02:44 -0000 Arguably, LISP creates a separate (overlayed) connectivity infrastructure. It should not come as a great surprise that such an infrastructure uses (one way or another) an effectively separate address registry for its separate operation. Having said that, leaks and how they relate to the allocation is one of the questions I asked the WG to clarify about this document. It is currently unclear on the point, and that is not going to work for any of us. Yours, Joel On 10/23/13 12:11 PM, Lorenzo Colitti wrote: > On Thu, Oct 24, 2013 at 12:36 AM, Brian Haberman > > wrote: > > Keep in mind that the referenced draft went through IETF Last > Call and was subsequently sent back to the WG due to the concerns > raised about routing and potentially creating a parallel address > registry > outside of the RIRs. > > > Which it's still doing, right? The block-mgmnt draft is all about > creating a parallel address registry. > > > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops > From v6ops@globis.net Fri Oct 25 10:38:37 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E3FFB11E8359; Fri, 25 Oct 2013 10:38:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, 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 BNoxocoBg6cN; Fri, 25 Oct 2013 10:38:37 -0700 (PDT) Received: from globis01.globis.net (RayH-1-pt.tunnel.tserv11.ams1.ipv6.he.net [IPv6:2001:470:1f14:62e::2]) by ietfa.amsl.com (Postfix) with ESMTP id BD21E11E837F; Fri, 25 Oct 2013 10:38:28 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by globis01.globis.net (Postfix) with ESMTP id 7EB5787007C; Fri, 25 Oct 2013 19:38:11 +0200 (CEST) Received: from globis01.globis.net ([127.0.0.1]) by localhost (mail.globis.net [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PzFpEHYhKdgX; Fri, 25 Oct 2013 19:38:11 +0200 (CEST) Received: from Rays-iMac-2.local (unknown [192.168.0.3]) (Authenticated sender: Ray.Hunter@globis.net) by globis01.globis.net (Postfix) with ESMTPA id 4C26387003F; Fri, 25 Oct 2013 19:38:11 +0200 (CEST) Message-ID: <526AAC81.3050402@globis.net> Date: Fri, 25 Oct 2013 19:38:09 +0200 From: Ray Hunter User-Agent: Postbox 3.0.8 (Macintosh/20130427) MIME-Version: 1.0 To: "Ackermann, Michael" References: <20131017032024.5051.20799.idtracker@ietfa.amsl.com> <1381980305.36254.YahooMailNeo@web2803.biz.mail.ne1.yahoo.com> <5263C783.1080001@globis.net> <1382396300.22968.YahooMailNeo@web2801.biz.mail.ne1.yahoo.com> <526616C4.40304@globis.net> <4FC37E442D05A748896589E468752CAA0CA88734@PWN401EA160.ent.corp.bcbsm.com> <52695E3A.9090406@globis.net> <4FC37E442D05A748896589E468752CAA0CA8A36F@PWN401EA160.ent.corp.bcbsm.com> In-Reply-To: <4FC37E442D05A748896589E468752CAA0CA8A36F@PWN401EA160.ent.corp.bcbsm.com> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: v6ops WG , 6man WG , "ippm@ietf.org" Subject: Re: [v6ops] Fw: New Version Notification for draft-elkins-6man-ipv6-pdm-dest-option-04.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 25 Oct 2013 17:38:38 -0000 > Ackermann, Michael > 25 October 2013 01:44 > Ray > > Your Comment: > No. I think what I said was that the level of certainty in your measurements is dependent on the level of synchronisation of the 2 clock sources if you are calculating a delta of timestamp of clock 1 - timestamp clock 2. > My Response: > Then it sounds like we are in agreement. Given the appropriate stratum level at both nodes, the desired level of time synchronization is achieved. > No. We are not in agreement. Stratum is an indication of how far down you are in the hierarchy from any NTP Stratum 0 clock. It says nothing about whether your stratum 0 and my stratum 0 are synchronised. We could both be running caesium clocks, and there could still be an offset if I don't set my reference time of my caesium clock the same as your reference time. When talking about microsecond or picosecond timing that will almost certainly be significant. You really need to know that the true provenance of the clock source is identical in order to make PDM 1 calculations, not just the stratum. Hence my comment to couple some sort of "clock ID" to the timestamp. > Your Comment: > I think it might be instructive to go back and look at high school physics books on making measurements, precision, accuracy, and error estimations, especially when taking the difference of two measurements, or making other calculations on top of raw observations > My Response: Not sure exactly what this means but I can say that this sounds like theoretical doubt that time synchronization will not work properly in geographically dispersed environments? I can tell you that it does in our experiences and that the surrounding protocols/implementations are crafted to account for such vicissitudes. > I will say that I have no field experience with DCF-77 sources, only GPS and Cesium. > > > Your Comment: > Equally a stratum 0 clock can be free running if it loses it's radio signal. > My Response: > This comment sort of confused me as well, but suffice to say, if any component is broken, results will be impaired. Obviously this is not limited to the time synch subject. > > > Finally, your comment about "Middleboxes". I hope it can be as simple to accommodate as you describe. My concern is that if there are numerous middleboxes, the fields may get repetitively overlaid, or there will need to be so many separate fields, we could incur excessive complexity or overhead. Given that we can accomplish this with a workable solution, I am certainly all for it. > The more information I can have to manage networks and solve problems, the better! > > Thanks again for your thoughts, inputs and questions! > > Mike > > > > > > > > > > > From ietf@rozanak.com Fri Oct 25 15:55:41 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6659F21F9FF9 for ; Fri, 25 Oct 2013 15:55:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.997 X-Spam-Level: X-Spam-Status: No, score=-1.997 tagged_above=-999 required=5 tests=[AWL=0.002, BAYES_00=-2.599, J_CHICKENPOX_13=0.6] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id A-HwRae5v3QA for ; Fri, 25 Oct 2013 15:55:36 -0700 (PDT) Received: from mout.perfora.net (mout.perfora.net [74.208.4.195]) by ietfa.amsl.com (Postfix) with ESMTP id 8F7B521F8411 for ; Fri, 25 Oct 2013 15:55:32 -0700 (PDT) Received: from kopoli (g231250140.adsl.alicedsl.de [92.231.250.140]) by mrelay.perfora.net (node=mrus1) with ESMTP (Nemesis) id 0M6BzW-1VssCn3Dys-00yThG; Fri, 25 Oct 2013 18:55:14 -0400 From: "Hosnieh Rafiee" To: References: <201310221245.r9MCj1n09532@ftpeng-update.cisco.com> In-Reply-To: <201310221245.r9MCj1n09532@ftpeng-update.cisco.com> Date: Sat, 26 Oct 2013 00:55:04 +0200 Message-ID: <008901ced1d5$434e5790$c9eb06b0$@rozanak.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQGR/c6oFX+mvk/6gDLEuSjOLB4jLpp/ouWQ Content-Language: en-us X-Provags-ID: V02:K0:QRjc/Rjev/SiGgIV02hL0PJoE8b9UjFD9GGt3sOeXZ+ 9PMxc8jNBp6PNUD0Z6dHyIheCoLMFjwGy0QU2ZGfSNCH/8f8xO sUaTm1vXYrc1+Pl/CT6JnlVS+0kFslgbnb44d3UUHSKVbCWKkh L9q2aP0BXtXGwjczmIXTnJ66/CG3Q1LBCYQgd2X1DjENjPyG9l QPom5zn0Gx3UVrjqNSnVuEvPgfIa6ul7qrsO0pwcTvbuK9M9p0 vo0x6K5LSpyaUHPCYvxpzylHSvnE+r66ySjOhwHrIhDXuikLA1 9nnkSyX+YhRckSiDVifwZCGJT8KJVTCicMYfxdZhl/xo0d4zXn p/mxXQqCK73HNOq3SKcU= Cc: v6ops@ietf.org, v6ops-chairs@tools.ietf.org, Erik Nordmark Subject: Re: [v6ops] Some questions on draft-rafiee-v6ops-iid-lifetime X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 25 Oct 2013 22:55:45 -0000 Hi Fred, Actually the content of this draft (http://tools.ietf.org/html/draft-rafiee-v6ops-iid-lifetime ) was presented in IETF 87 as a part of ra-privacy. Some people during that meeting thought that it is better to make this draft more generate and separate it from ra-privacy; http://tools.ietf.org/html/draft-rafiee-6man-ra-privacy (this draft also does nothing with security and it address the problems with RFC 4941 and also deprecating EUI-64 in RFC 4941. The draft "deprecated IID" that is new and contain most of the section that is already explained in ra-privacy could improve this existing draft) So, iid lifetime draft, as you already know, does nothing with security but it is a way of maintaining privacy and try to avoid sacrificing user's connectivity in IPv6 networks. This draft, first, compares the current mechanisms available for the lifetime of an IID and then offer a new mechanism for the mentioned purpose (privacy and connectivity) > > 1) Please provide a succinct problem statement for your draft. What > problem/issue is this draft discussing? What operational problems does the > proposal address in real life networks? We tried to have a short problem statement at the end of Introduction. But we are open to suggestions if you or anybody else think that there is a need for expanding this section. > > 2) Where does this draft or presentation fits into v6ops' current charter > (http://datatracker.ietf.org/wg/v6ops/charter/)? Citing specific a section(s) > of the charter is preferable. It might fit to number 4 and the rest of the explanation. Why we think it can fit? It is because IPv6 addresses are public and at least at the moment our computer connect to internet using its own unique IP address. I guess this will open new issues for privacy and security. The reason is the initial attack on node's security and privacy is to recon the node. So, when your node has a fix IID, then the attacker has better possibility to attack this node. Now the purpose of this draft is only to give information to the implementers that they can improve the privacy and security of their mechanisms. It also provide a way for privacy-aware-applications to use a same framework which can also control the total number of IID and not generate the IID themselves. This means they do not need to have any information about IP layer while at the same time they can ensure their users that their application is privacy-aware > 3) Who is this draft's audience? Privacy-aware implementers > 4) Have any operators expressed interest in this draft or its problem space, > either via review or other discussion? I guess I have already answered this > 5) Is this draft pursuing discussion in any other WGs? If so, please list them > here, along with rationale for the interaction with multiple WGs in parallel. Please check the recordings of ra-privacy (lifetime section) and the mailing list discussion about ra-privacy after IETF 87 > 6) Is any protocol work being recommended in the draft? It is actually in informational track that gives the choice for implementers. I am also in the process of implementing it for Linux. Thank you again, -----------smile---------- Hosnieh . success is a journey, not a destination.. You cannot change your destination overnight, but you can change your direction ... Focus on the journey From fred@cisco.com Sat Oct 26 00:37:17 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AE1F111E8214 for ; Sat, 26 Oct 2013 00:37:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.209 X-Spam-Level: X-Spam-Status: No, score=-110.209 tagged_above=-999 required=5 tests=[AWL=-0.210, BAYES_00=-2.599, J_CHICKENPOX_13=0.6, RCVD_IN_DNSWL_HI=-8, 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 Mir3xKRIh8Nu for ; Sat, 26 Oct 2013 00:37:12 -0700 (PDT) Received: from rcdn-iport-3.cisco.com (rcdn-iport-3.cisco.com [173.37.86.74]) by ietfa.amsl.com (Postfix) with ESMTP id D906111E816F for ; Sat, 26 Oct 2013 00:37:02 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=6025; q=dns/txt; s=iport; t=1382773023; x=1383982623; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=bbCzzv7db0M337sy+B6HtAPrIpynGO0W60gOwz1RZYY=; b=de5SI/DnnExYXhDVc3kFDi1wnNbjg77TMKUH9f5wOJGmA0Ia4gQjLMkJ N2dyjo0W4430XyM85pSHS0xGrqjOOD7J/NvOi2P0pTCdV5aJEK4ikgjck /rx/X8yF5zt2BXw1Rc4xo8u6Jba/ZanRKVOe6p8Rt/vYHOAhipqka4ydE o=; X-Files: signature.asc : 195 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgQFAH5wa1KtJV2d/2dsb2JhbABZgwc4VL5OgR4WdIIlAQEBAwFuCwULAgEIDhQkMiUCBA4FCAYLh2gGDbh8jyQxB4MfgQ0DkC2BMIdckFiDJoIq X-IronPort-AV: E=Sophos;i="4.93,575,1378857600"; d="asc'?scan'208";a="276975794" Received: from rcdn-core-6.cisco.com ([173.37.93.157]) by rcdn-iport-3.cisco.com with ESMTP; 26 Oct 2013 07:37:02 +0000 Received: from xhc-rcd-x03.cisco.com (xhc-rcd-x03.cisco.com [173.37.183.77]) by rcdn-core-6.cisco.com (8.14.5/8.14.5) with ESMTP id r9Q7b2iv003747 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Sat, 26 Oct 2013 07:37:02 GMT Received: from xmb-rcd-x09.cisco.com ([169.254.9.23]) by xhc-rcd-x03.cisco.com ([173.37.183.77]) with mapi id 14.02.0318.004; Sat, 26 Oct 2013 02:37:01 -0500 From: "Fred Baker (fred)" To: Hosnieh Rafiee Thread-Topic: Some questions on draft-rafiee-v6ops-iid-lifetime Thread-Index: AQHO0h4ohu+AJDz6okWKOgIP4IJSIw== Date: Sat, 26 Oct 2013 07:37:00 +0000 Message-ID: <8C48B86A895913448548E6D15DA7553BA7B7F4@xmb-rcd-x09.cisco.com> References: <201310221245.r9MCj1n09532@ftpeng-update.cisco.com> <008901ced1d5$434e5790$c9eb06b0$@rozanak.com> In-Reply-To: <008901ced1d5$434e5790$c9eb06b0$@rozanak.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-originating-ip: [10.61.201.55] Content-Type: multipart/signed; boundary="Apple-Mail=_87E66DB0-43BA-4652-9ACA-510E29FF90DF"; protocol="application/pgp-signature"; micalg=pgp-sha1 MIME-Version: 1.0 Cc: "6man-chairs@tools.ietf.org" <6man-chairs@tools.ietf.org>, "v6ops@ietf.org WG" , "v6ops-chairs@tools.ietf.org" , Erik Nordmark Subject: Re: [v6ops] Some questions on draft-rafiee-v6ops-iid-lifetime X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 26 Oct 2013 07:37:17 -0000 --Apple-Mail=_87E66DB0-43BA-4652-9ACA-510E29FF90DF Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Thanks. Question for you. What is the interaction with = draft-gont-6man-deprecate-eui64-based-addresses? In conversation with = him there, you asked if he would be folding your draft into his and = therefore making yours redundant. Does he plan to? If he does, it may be = appropriate for you to become a co-author on that paper. My sense, which could be completely incorrect, is that the exact value = of the IID isn't all that interesting to most operators, as once it is = in use nobody really cares how it was chosen. Duplicate IIDs in use = would be a problem, so DAD is important. The means by which it is = assigned is interesting (some operators require SLAAC, some use DHCPv6 = but permit SLAAC, some require DHCPv6, and some assign IIDs to their = servers or to routers for BGP purposes). Duplicate IIDs in use would be = a problem, so DAD is important operationally if SLAAC is in use, and in = DSL and Cable networks the behavior of DAD in their transmission systems = is "interesting". The number of addresses that are in actual use at a = given time (and therefore neighbor slots that are in use) is = operationally interesting in that it affects and is affected by table = capacity, and can therefore be an attack vector. The bits in the IID and = the mechanism by which they are generated is, however, very important to = 6man, which defines SLAAC. =46rom that perspective, the paper may be of = interest in 6man. I'm looking, as always, for operational feedback on the list. But that's = my initial thought. On Oct 26, 2013, at 12:55 AM, Hosnieh Rafiee wrote: > Hi Fred, >=20 > Actually the content of this draft > (http://tools.ietf.org/html/draft-rafiee-v6ops-iid-lifetime ) was = presented > in IETF 87 as a part of ra-privacy. Some people during that meeting = thought > that it is better to make this draft more generate and separate it = from > ra-privacy; http://tools.ietf.org/html/draft-rafiee-6man-ra-privacy = (this > draft also does nothing with security and it address the problems with = RFC > 4941 and also deprecating EUI-64 in RFC 4941. The draft "deprecated = IID" > that is new and contain most of the section that is already explained = in > ra-privacy could improve this existing draft) >=20 > So, iid lifetime draft, as you already know, does nothing with = security but > it is a way of maintaining privacy and try to avoid sacrificing user's > connectivity in IPv6 networks. This draft, first, compares the current > mechanisms available for the lifetime of an IID and then offer a new > mechanism for the mentioned purpose (privacy and connectivity) >=20 >>=20 >> 1) Please provide a succinct problem statement for your draft. What >> problem/issue is this draft discussing? What operational problems = does the >> proposal address in real life networks? >=20 > We tried to have a short problem statement at the end of Introduction. = But > we are open to suggestions if you or anybody else think that there is = a > need for expanding this section. >=20 >>=20 >> 2) Where does this draft or presentation fits into v6ops' current = charter >> (http://datatracker.ietf.org/wg/v6ops/charter/)? Citing specific a > section(s) >> of the charter is preferable. >=20 > It might fit to number 4 and the rest of the explanation. Why we think = it > can fit? It is because IPv6 addresses are public and at least at the = moment > our computer connect to internet using its own unique IP address. I = guess > this will open new issues for privacy and security. The reason is the > initial attack on node's security and privacy is to recon the node. = So, when > your node has a fix IID, then the attacker has better possibility to = attack > this node.=20 > Now the purpose of this draft is only to give information to the > implementers that they can improve the privacy and security of their > mechanisms. It also provide a way for privacy-aware-applications to = use a > same framework which can also control the total number of IID and not > generate the IID themselves.=20 > This means they do not need to have any information about IP layer = while at > the same time they can ensure their users that their application is > privacy-aware >=20 >> 3) Who is this draft's audience? >=20 > Privacy-aware implementers >=20 >> 4) Have any operators expressed interest in this draft or its problem > space, >> either via review or other discussion? >=20 > I guess I have already answered this=20 >=20 >> 5) Is this draft pursuing discussion in any other WGs? If so, please = list > them >> here, along with rationale for the interaction with multiple WGs in > parallel. >=20 > Please check the recordings of ra-privacy (lifetime section) and the = mailing > list discussion about ra-privacy after IETF 87 >=20 >=20 >> 6) Is any protocol work being recommended in the draft? >=20 > It is actually in informational track that gives the choice for > implementers. I am also in the process of implementing it for Linux.=20= >=20 > Thank you again, > -----------smile---------- > Hosnieh > . success is a journey, not a destination.. > You cannot change your destination overnight, but you can change your > direction ... Focus on the journey >=20 >=20 --Apple-Mail=_87E66DB0-43BA-4652-9ACA-510E29FF90DF Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="signature.asc" Content-Type: application/pgp-signature; name="signature.asc" Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- Comment: GPGTools - http://gpgtools.org iD8DBQFSa3E6bjEdbHIsm0MRAn//AKDlVkA84je91QYhGiOez3E411UWEACg4i6K 1Emij3l6bwr8uL5gN7n/RY4= =tajN -----END PGP SIGNATURE----- --Apple-Mail=_87E66DB0-43BA-4652-9ACA-510E29FF90DF-- From ietf@rozanak.com Sat Oct 26 02:34:50 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6159511E8175 for ; Sat, 26 Oct 2013 02:34:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_13=0.6] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mPe689kWVyYX for ; Sat, 26 Oct 2013 02:34:43 -0700 (PDT) Received: from mout.perfora.net (mout.perfora.net [74.208.4.194]) by ietfa.amsl.com (Postfix) with ESMTP id 7CAEA11E818F for ; Sat, 26 Oct 2013 02:34:40 -0700 (PDT) Received: from kopoli (g225045086.adsl.alicedsl.de [92.225.45.86]) by mrelay.perfora.net (node=mrus4) with ESMTP (Nemesis) id 0MbOgO-1VJZKy1qIW-00JQkO; Sat, 26 Oct 2013 05:34:26 -0400 From: "Hosnieh Rafiee" To: "'Fred Baker \(fred\)'" References: <201310221245.r9MCj1n09532@ftpeng-update.cisco.com> <008901ced1d5$434e5790$c9eb06b0$@rozanak.com> <8C48B86A895913448548E6D15DA7553BA7B7F4@xmb-rcd-x09.cisco.com> In-Reply-To: <8C48B86A895913448548E6D15DA7553BA7B7F4@xmb-rcd-x09.cisco.com> Date: Sat, 26 Oct 2013 11:34:16 +0200 Message-ID: <001f01ced22e$8f08a4c0$ad19ee40$@rozanak.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQGR/c6oFX+mvk/6gDLEuSjOLB4jLgJJTk5DATuMhfOaZDYRUA== Content-Language: en-us X-Provags-ID: V02:K0:UKAObx/mtzjdgXK2DnihLwDHDicYWOq/LytCcjUprqR EaEFsdHA3Ktz4VTj5qmZm7np7JZJP0Qkqs9+Jh2xokQDoakX6o eLHPg5GD9xfLHtlv7dhacjsGdEzo1rraT1PwJ1prYLRFUhNufu i2ClaWAlDNC61wLWT8xKTaK70gUIRCNatlC4OSlnYeD5HOh9I1 BUxCR+Zb9IPu/xeUT6aKY9N16uY296AyFQXvKy/FkGnkQfS3Fs kKu7JY79XdLlOR/pbUPc/0rihMP7TLeYyy59T7Lb12V76Wukeo XVRSlp2rJ1813V0xn6SHZ/51JFCw64BoVlZMn2hb80qHtsEPhI wCm0lWEVtYI+5G/OqKC0= Cc: 6man-chairs@tools.ietf.org, v6ops@ietf.org, v6ops-chairs@tools.ietf.org, 'Erik Nordmark' Subject: Re: [v6ops] Some questions on draft-rafiee-v6ops-iid-lifetime X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 26 Oct 2013 09:34:50 -0000 Hi Fred, Thanks again. > > Question for you. What is the interaction with draft-gont-6man-deprecate- > eui64-based-addresses? In conversation with him there, you asked if he > would be folding your draft into his and therefore making yours redundant. > Does he plan to? If he does, it may be appropriate for you to become a co- > author on that paper. That conversation is nothing to do with Iid-lifetime draft which we submitted to v6ops. It is about ra-privacy which I submitted to 6man. Ra-privacy has been active for some months and the content of this new submitted draft, "deprecate EUI-64", is the same as some sections in ra-privacy. They wanted to have an informational draft recommending all operators to use stable addresses. Since I was improving ra-privacy, there was a discussion about this and since I had a section about "Not using EUI-64 in general" in my draft. I said it can be just changing a sentence in this section to recommend using stable addresses as a public address. I guessed we agreed on that. But now I see otherwise! Since they didn't discuss this with me and just suddenly submit a draft and used the content of ra-privacy, I just asked them whether they want to merge this work with their draft. But it appears they ignored my message! I thought in IETF you try first to improve the existing drafts and then if the existing draft does n't address what you plan to do, you would submit a new draft, but not copy and paste the content and make it new draft. > My sense, which could be completely incorrect, is that the exact value of the > IID isn't all that interesting to most operators, as once it is in use nobody > really cares how it was chosen. Duplicate IIDs in use would be a problem, so > DAD is important. The means by which it is assigned is interesting (some > operators require SLAAC, some use DHCPv6 but permit SLAAC, some require > DHCPv6, and some assign IIDs to their servers or to routers for BGP > purposes). Duplicate IIDs in use would be a problem, so DAD is important > operationally if SLAAC is in use, and in DSL and Cable networks the behavior > of DAD in their transmission systems is "interesting". The number of > addresses that are in actual use at a given time (and therefore neighbor slots > that are in use) is operationally interesting in that it affects and is affected by > table capacity, and can therefore be an attack vector. The bits in the IID and > the mechanism by which they are generated is, however, very important to > 6man, which defines SLAAC. From that perspective, the paper may be of > interest in 6man. > > I'm looking, as always, for operational feedback on the list. But that's my > initial thought. Iid- Lifetime is not about how you generate IID. It doesn't matter for it. It only recommends a lifetime for the IID. You can use different approach to generate your IID but at the same time care about your privacy. Thanks again, -----------smile---------- Hosnieh . success is a journey, not a destination.. You cannot change your destination overnight, but you can change your direction ... Focus on the journey From mellon@fugue.com Thu Oct 24 06:47:31 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 043BB21E8093 for ; Thu, 24 Oct 2013 06:47:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TyO4ol6YRqjn for ; Thu, 24 Oct 2013 06:47:17 -0700 (PDT) Received: from toccata.fugue.com (toccata.fugue.com [204.152.186.142]) by ietfa.amsl.com (Postfix) with ESMTP id 06E8211E81C9 for ; Thu, 24 Oct 2013 06:44:50 -0700 (PDT) Received: from [10.0.10.40] (c-174-62-147-182.hsd1.nh.comcast.net [174.62.147.182]) by toccata.fugue.com (Postfix) with ESMTPSA id 88D5B23802F4; Thu, 24 Oct 2013 09:44:43 -0400 (EDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 7.0 \(1816\)) From: Ted Lemon In-Reply-To: Date: Thu, 24 Oct 2013 09:44:43 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: <06601039-CAFD-49B0-918B-A8ACD51B978D@fugue.com> References: To: Victor Kuarsingh X-Mailer: Apple Mail (2.1816) X-Mailman-Approved-At: Sat, 26 Oct 2013 22:18:26 -0700 Cc: "draft-liu-bonica-v6ops-dhcpv6-slaac-problem@tools.ietf.org" , "v6ops@ietf.org" , "Ole Troan \(otroan\)" , Dave Thaler Subject: Re: [v6ops] DHCPv6/SLAAC Make Hosts Confusing-//RE: new draft: draft-liu-bonica-v6ops-dhcpv6-slaac-problem X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 24 Oct 2013 13:47:32 -0000 On Oct 24, 2013, at 8:55 AM, Victor Kuarsingh wrote: > From: Lorenzo Colitti >> 2. Attempt to say that RAs and DHCPv6 are simply containers and = propose a unified option format so we can have the >>same options in = both of them. I know this was already proposed once and was shot down, = but I wasn't around, so I >>don't know why. (CCing a few people who = might know). >=20 > [VK] This seems like an intriguing idea. Would this mean that every = option must go into each container, or that there will be a common set = of options which go into both, and perhaps exceptions go into one or the = other? (On that latter part, I guess that line of thinking gets us back = to where we are). I think the main reason we didn't do this is that it seems like a = mistake to have two mechanisms for delivering the same information. If = we really think RA is the right way to do all host configuration, why = not just add a stateful mode? If we really think DHCP is the right way = to do all host configuration, why not just add support for configuring = routes? Stateful RA could actually be piggybacked onto DHCP, so that = the router just creates a DHCP message and forwards it upstream, or = answers it locally, depending on the circumstances. Doing what's proposed here means that code on clients needs to be four = times more complicated than it would be otherwise. Putting DNS server = options in RAs was a bad idea. Continuing down that path is a worse = idea, particularly since this proposal would mean there'd be two ways of = representing DNS server information in RAs. If we really got this wrong, we should fix it, not make it worse. Anyway, that's the rhetorical position I'm going to stake out for now. = I'm curious to see if anybody can come up with a reason to disagree that = doesn't simplify to either "I hate RA" or "I hate DHCP." From xing@cernet.edu.cn Sun Oct 27 06:40:16 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4ABA211E81D5 for ; Sun, 27 Oct 2013 06:40:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.999 X-Spam-Level: X-Spam-Status: No, score=-101.999 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_13=0.6, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 78-v00oaFgsq for ; Sun, 27 Oct 2013 06:40:11 -0700 (PDT) Received: from cernet.edu.cn (sea.net.edu.cn [202.112.39.2]) by ietfa.amsl.com (Postfix) with ESMTP id 53A0E11E817A for ; Sun, 27 Oct 2013 06:40:09 -0700 (PDT) Received: from [127.0.0.1] (unknown [123.112.67.7]) by centos (Coremail) with SMTP id AQAAf3B7cQM2F21SRxEpAA--.53312S5; Sun, 27 Oct 2013 21:37:59 +0800 (CST) Message-ID: <526D17A5.9050804@cernet.edu.cn> Date: Sun, 27 Oct 2013 21:39:49 +0800 From: Xing Li User-Agent: Thunderbird 2.0.0.24 (Windows/20100228) MIME-Version: 1.0 To: Ted Lemon References: <06601039-CAFD-49B0-918B-A8ACD51B978D@fugue.com> In-Reply-To: <06601039-CAFD-49B0-918B-A8ACD51B978D@fugue.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit X-CM-TRANSID: AQAAf3B7cQM2F21SRxEpAA--.53312S5 X-Coremail-Antispam: 1UD129KBjvJXoW7AF13AF43ZFykKw18tFWUJwb_yoW8uryDpF 4UX3Z5Kw4kJF1fA3ykG34YkFyFkrZ5JFW3Jwn8Ga1DCr98GFy2yrsIvw1Y9F9rWr1fAr4j va1Y9rnrCwsxZFJanT9S1TB71UUUUUUqnTZGkaVYY2UrUUUUjbIjqfuFe4nvWSU5nxnvy2 9KBjDU0xBIdaVrnRJUUU6mb7Iv0xC_Kw4lb4IE77IF4wAFF20E14v26r4j6ryUM7CY07I2 0VC2zVCF04k26cxKx2IYs7xG6rWj6s0DM7CIcVAFz4kK6r1j6r18M28lY4IEw2IIxxk0rw A2z4x0Y4vE2Ix0cI8IcVAFwI0_Jr0_JF4l84ACjcxK6xIIjxv20xvEc7CjxVAFwI0_Jr0_ Gr1l84ACjcxK6I8E87Iv67AKxVW8Jr0_Cr1UM28EF7xvwVC2z280aVCY1x0267AKxVW8Jr 0_Cr1UM2AIxVAIcxkEcVAq07x20xvEncxIr21l5I8CrVACY4xI64kE6c02F40Ex7xfMcIj 6I8E87Iv67AKxVWUJVW8JwAm72CE4IkC6x0Yz7v_Jr0_Gr1lF7xvr2IY64vIr41l42xK82 IYc2Ij64vIr41lx2IqxVAqx4xG67AKxVWUJVWUGwC20s026x8GjcxK67AKxVWUGVWUWwC2 zVAF1VAY17CE14v26r126r1DMIIYrxkI7VAKI48JMIIF0xvE2Ix0cI8IcVAFwI0_Jr0_JF 4lIxAIcVC0I7IYx2IY6xkF7I0E14v26r1j6r4UMIIF0xvE42xK8VAvwI8IcIk0rVWrZr1j 6s0DMIIF0xvEx4A2jsIE14v26r1j6r4UMIIF0xvEx4A2jsIEc7CjxVAFwI0_Jr0_GrUvcS sGvfC2KfnxnUUI43ZEXa7IU52zutUUUUU== X-CM-SenderInfo: p0lqwqxfhu0vvwohv3gofq/ Cc: "v6ops@ietf.org" , Dave Thaler , "Ole Troan \(otroan\)" , "draft-liu-bonica-v6ops-dhcpv6-slaac-problem@tools.ietf.org" Subject: Re: [v6ops] DHCPv6/SLAAC Make Hosts Confusing-//RE: new draft: draft-liu-bonica-v6ops-dhcpv6-slaac-problem X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 27 Oct 2013 13:40:16 -0000 Ted Lemon 写道: > On Oct 24, 2013, at 8:55 AM, Victor Kuarsingh wrote: > >> From: Lorenzo Colitti >> >>> 2. Attempt to say that RAs and DHCPv6 are simply containers and propose a unified option format so we can have the >>same options in both of them. I know this was already proposed once and was shot down, but I wasn't around, so I >>don't know why. (CCing a few people who might know). >>> >> [VK] This seems like an intriguing idea. Would this mean that every option must go into each container, or that there will be a common set of options which go into both, and perhaps exceptions go into one or the other? (On that latter part, I guess that line of thinking gets us back to where we are). >> > > I think the main reason we didn't do this is that it seems like a mistake to have two mechanisms for delivering the same information. If we really think RA is the right way to do all host configuration, why not just add a stateful mode? If we really think DHCP is the right way to do all host configuration, why not just add support for configuring routes? Stateful RA could actually be piggybacked onto DHCP, so that the router just creates a DHCP message and forwards it upstream, or answers it locally, depending on the circumstances. > Based on CERNET2's IPv6 experience, I fully support Ted's proposal. xing > Doing what's proposed here means that code on clients needs to be four times more complicated than it would be otherwise. Putting DNS server options in RAs was a bad idea. Continuing down that path is a worse idea, particularly since this proposal would mean there'd be two ways of representing DNS server information in RAs. > > If we really got this wrong, we should fix it, not make it worse. > > Anyway, that's the rhetorical position I'm going to stake out for now. I'm curious to see if anybody can come up with a reason to disagree that doesn't simplify to either "I hate RA" or "I hate DHCP." > > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops > > > From xing@cernet.edu.cn Sun Oct 27 06:45:42 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 574FF21E80C6 for ; Sun, 27 Oct 2013 06:45:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.299 X-Spam-Level: X-Spam-Status: No, score=-102.299 tagged_above=-999 required=5 tests=[AWL=0.300, 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 ip2LbJjeQDgG for ; Sun, 27 Oct 2013 06:45:36 -0700 (PDT) Received: from cernet.edu.cn (sea.net.edu.cn [202.112.39.2]) by ietfa.amsl.com (Postfix) with ESMTP id 698DC21E809D for ; Sun, 27 Oct 2013 06:45:31 -0700 (PDT) Received: from [127.0.0.1] (unknown [123.112.67.7]) by centos (Coremail) with SMTP id AQAAf3CbkQOCGG1SeBEpAA--.53176S5; Sun, 27 Oct 2013 21:43:32 +0800 (CST) Message-ID: <526D18F2.8040103@cernet.edu.cn> Date: Sun, 27 Oct 2013 21:45:22 +0800 From: Xing Li User-Agent: Thunderbird 2.0.0.24 (Windows/20100228) MIME-Version: 1.0 To: Ted Lemon References: <06601039-CAFD-49B0-918B-A8ACD51B978D@fugue.com> <526D17A5.9050804@cernet.edu.cn> In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit X-CM-TRANSID: AQAAf3CbkQOCGG1SeBEpAA--.53176S5 X-Coremail-Antispam: 1UD129KBjDUn29KB7ZKAUJUUUUU529EdanIXcx71UUUUU7v73 VFW2AGmfu7bjvjm3AaLaJ3UjIYCTnIWjp_UUU5z7k0a2IF6F4UM7kC6x804xWl14x267AK xVW8JVW5JwAFc2x0x2IEx4CE42xK8VAvwI8IcIk0rVWrJVCq3wAFIxvE14AKwVWUJVWUGw A2ocxC64kIII0Yj41l84ACjcxK6xIIjxv20xvE14v26r1I6r4UM28EF7xvwVC0I7IYx2IY 6xkF7I0E14v26r4j6F4UM28EF7xvwVC2z280aVAFwI0_Gr1j6F4UJwA2z4x0Y4vEx4A2js IEc7CjxVAFwI0_Gr1j6F4UJwAS0I0E0xvYzxvE52x082IY62kv0487Mc02F40EFcxC0VAK zVAqx4xG6I80ewAv7VC0I7IYx2IY67AKxVWUXVWUAwAv7VC2z280aVAFwI0_Jr0_Gr1lOx 8S6xCaFVCjc4AY6r1j6r4UM4x0Y48IcVAKI48JMxAIw28IcxkI7VAKI48JMI8I3I0E5I8C rVAFwI0_Jr0_Jr4lx2IqxVCjr7xvwVAFwI0_JrI_JrWlx4CE17CEb7AF67AKxVWUAVWUtw CIc40Y0x0EwIxGrwCI42IY6xIIjxv20xvE14v26r1j6r1xMIIF0xvE2Ix0cI8IcVCY1x02 67AKxVW8JVWxJwCI42IY6xAIw20EY4v20xvaj40_Zr0_Wr1UMIIF0xvEx4A2jsIE14v26r 1j6r4UMIIF0xvEx4A2jsIEc7CjxVAFwI0_Gr0_Gr1UYxBIdaVFxhVjvjDU0xZFpf9x07jj Q6JUUUUU= X-CM-SenderInfo: p0lqwqxfhu0vvwohv3gofq/ Cc: "v6ops@ietf.org" , Dave Thaler , "Ole Troan \(otroan\)" , "draft-liu-bonica-v6ops-dhcpv6-slaac-problem@tools.ietf.org" Subject: Re: [v6ops] DHCPv6/SLAAC Make Hosts Confusing-//RE: new draft: draft-liu-bonica-v6ops-dhcpv6-slaac-problem X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 27 Oct 2013 13:45:42 -0000 Ted Lemon 写道: > On Oct 27, 2013, at 9:39 AM, Xing Li wrote: > >> Based on CERNET2's IPv6 experience, I fully support Ted's proposal. xing >> > > I do not think that I made an actual proposal here. > I mean "Stateful RA could actually be piggybacked onto DHCP, so that the router just creates a DHCP message and forwards it upstream, or answers it locally, depending on the circumstances." xing > > > From gert@space.net Sun Oct 27 07:52:27 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DE35E11E8260 for ; Sun, 27 Oct 2013 07:52:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.413 X-Spam-Level: X-Spam-Status: No, score=-2.413 tagged_above=-999 required=5 tests=[AWL=0.186, 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 vcKnJIdvZU84 for ; Sun, 27 Oct 2013 07:52:27 -0700 (PDT) Received: from mobil.space.net (mobil.space.net [IPv6:2001:608:2:81::67]) by ietfa.amsl.com (Postfix) with ESMTP id 4D36921F9FF3 for ; Sun, 27 Oct 2013 07:52:26 -0700 (PDT) Received: from mobil.space.net (localhost [127.0.0.1]) by mobil.space.net (Postfix) with ESMTP id 1A4AF602D0 for ; Sun, 27 Oct 2013 15:52:25 +0100 (CET) X-SpaceNet-Relay: true Received: from moebius3.space.net (moebius3.Space.Net [IPv6:2001:608:2:2::250]) by mobil.space.net (Postfix) with ESMTPS id DCD016029F for ; Sun, 27 Oct 2013 15:52:24 +0100 (CET) Received: (qmail 23916 invoked by uid 1007); 27 Oct 2013 15:52:24 +0100 Date: Sun, 27 Oct 2013 15:52:24 +0100 From: Gert Doering To: Xing Li Message-ID: <20131027145224.GT50205@Space.Net> References: <06601039-CAFD-49B0-918B-A8ACD51B978D@fugue.com> <526D17A5.9050804@cernet.edu.cn> <526D18F2.8040103@cernet.edu.cn> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <526D18F2.8040103@cernet.edu.cn> X-NCC-RegID: de.space User-Agent: Mutt/1.5.21 (2010-09-15) Cc: "draft-liu-bonica-v6ops-dhcpv6-slaac-problem@tools.ietf.org" , "v6ops@ietf.org" , Ted Lemon , "Ole Troan \(otroan\)" , Dave Thaler Subject: Re: [v6ops] DHCPv6/SLAAC Make Hosts Confusing-//RE: new draft: draft-liu-bonica-v6ops-dhcpv6-slaac-problem X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 27 Oct 2013 14:52:28 -0000 Hi, On Sun, Oct 27, 2013 at 09:45:22PM +0800, Xing Li wrote: > > I do not think that I made an actual proposal here. > I mean "Stateful RA could actually be piggybacked onto DHCP, so that the > router just creates a DHCP message and forwards it upstream, or answers > it locally, depending on the circumstances." xing This is called "DHCP relay or DHCP server on the router". I can't see what this has to do with RA ("periodically multicasted to everyone who wants to receive it"). This idea is... completely lacking the understanding of the difference between solicited and unsolicited information, and also of the existing possibilities of just having a DHCPv6 server (or relay) on the router itself. Gert Doering -- NetMaster -- have you enabled IPv6 on something today...? SpaceNet AG Vorstand: Sebastian v. Bomhard Joseph-Dollinger-Bogen 14 Aufsichtsratsvors.: A. Grundner-Culemann D-80807 Muenchen HRB: 136055 (AG Muenchen) Tel: +49 (0)89/32356-444 USt-IdNr.: DE813185279 From lorenzo@google.com Sun Oct 27 07:58:54 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9B61611E8283 for ; Sun, 27 Oct 2013 07:58:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.893 X-Spam-Level: X-Spam-Status: No, score=-1.893 tagged_above=-999 required=5 tests=[AWL=0.084, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, 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 IpVderKZA3qH for ; Sun, 27 Oct 2013 07:58:54 -0700 (PDT) Received: from mail-ie0-x234.google.com (mail-ie0-x234.google.com [IPv6:2607:f8b0:4001:c03::234]) by ietfa.amsl.com (Postfix) with ESMTP id DE67E11E8192 for ; Sun, 27 Oct 2013 07:58:53 -0700 (PDT) Received: by mail-ie0-f180.google.com with SMTP id e14so9376574iej.39 for ; Sun, 27 Oct 2013 07:58:53 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=MNHTAuXJp4dS9guAxYrCT4HkyB7bNLtL6kzK+5R8NJI=; b=k4hiLExto2wLNrHXv1dxfaUjdYWRtFsgYa6b34mgHT9WyWKko0PJzdqqHS9Z6nellM nQfprjwukroyg5DxAEpV8AGKIySmE6IvJuX27QBbS/eM0rhJoNfhoiH4+nSA0CnDrrZN IYgU85YGH2S3AeTL7ZJRpYl3aAnTLsqn03B/lSF1sw2yzCWWxY29FPBULsAm4hmvQpKN RYfmqzUJAYYOafPjABW1ruwSSb2EfzmCoqr/WGFI9fMsieUj4bsQ7J0Uw4ZbY+jugcp2 ULEoYRR0DDE1Xjquq3tio4uXy8TG9TRMEqpOpnb4Mi+rRC1p/b+IfoEeC9SBKlFkPv+I SYMQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type; bh=MNHTAuXJp4dS9guAxYrCT4HkyB7bNLtL6kzK+5R8NJI=; b=VLQAHJGBVEpGMNkNhF6ASYbo8msW2qMCwBV/AFEJmm+agVI0OKtnMTCkzUcZ1KadBx vynNuMHiqBCtc7YO7eEpcAHyy0NHjW9QESxxSG1cCiYOZW9quAhxNhFdxoy9JG6iOkmG BZN8MvPq6Q0ARb/xQ910SE4YsSBIScep/0hdgJ87KASPonqD/4HCwyxceGDJjpih67j+ kSZeTLeEPKeqq80/oPGKrQ3KLITunO7aqSq3COdk6j5HvUP+UwwhnhQcNNWRhs7IMznT aBAo2sO6KHpfpTjBRhGVoNwsOqfoCDoYuwtUk+/lZPB38K3fMBR2lu7LuZSWY6b0i8cU 3Okw== X-Gm-Message-State: ALoCoQmA8du44b1H2mYPAuFrzTuGW3YQuM5cOR29DpYDQFezFbKuKKhTTNexgtVCjhPJM4CepfCPEHULtBVtBFORqeqcLNhqny2FhYf1uO1T9+REftpe1ELEHYAFsODy/oJ8VW4Lwyh4HufExbhcRb5NtW3nJ95TDFXHGEXVX1AZ2OWoqJk00j0qZs/RcYSwx7AO6HEc69pw X-Received: by 10.50.43.131 with SMTP id w3mr5421662igl.17.1382885933289; Sun, 27 Oct 2013 07:58:53 -0700 (PDT) MIME-Version: 1.0 Received: by 10.64.86.106 with HTTP; Sun, 27 Oct 2013 07:58:33 -0700 (PDT) In-Reply-To: <20131027145224.GT50205@Space.Net> References: <06601039-CAFD-49B0-918B-A8ACD51B978D@fugue.com> <526D17A5.9050804@cernet.edu.cn> <526D18F2.8040103@cernet.edu.cn> <20131027145224.GT50205@Space.Net> From: Lorenzo Colitti Date: Sun, 27 Oct 2013 23:58:33 +0900 Message-ID: To: Gert Doering Content-Type: multipart/alternative; boundary=047d7bfea186d1cdb104e9ba389f Cc: "v6ops@ietf.org" , Ted Lemon , "Ole Troan \(otroan\)" , Dave Thaler , "draft-liu-bonica-v6ops-dhcpv6-slaac-problem@tools.ietf.org" Subject: Re: [v6ops] DHCPv6/SLAAC Make Hosts Confusing-//RE: new draft: draft-liu-bonica-v6ops-dhcpv6-slaac-problem X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 27 Oct 2013 14:58:54 -0000 --047d7bfea186d1cdb104e9ba389f Content-Type: text/plain; charset=ISO-8859-1 On Sun, Oct 27, 2013 at 11:52 PM, Gert Doering wrote: > > > I do not think that I made an actual proposal here. > > I mean "Stateful RA could actually be piggybacked onto DHCP, so that the > > router just creates a DHCP message and forwards it upstream, or answers > > it locally, depending on the circumstances." xing > > This is called "DHCP relay or DHCP server on the router". I can't see > what this has to do with RA ("periodically multicasted to everyone who > wants to receive it"). > > This idea is... completely lacking the understanding of the difference > between solicited and unsolicited information, and also of the existing > possibilities of just having a DHCPv6 server (or relay) on the router > itself. > The way I read that was: 1. Host sends RS. 2. Router gets RS, encapsulates it in DHCPv6 option to DHCPv6 server. 3. Server replies with RA parameters. 4. Router sends unicast RA to host. The unicast RA would have more information than the multicast RA (e.g., more specific routes). The idea being that you if you do this you can send different clients different information (which is one of the things that DHCPv6 offers but RAs typically do not). So it's basically a RA-to-DHCPv6 translator in the router. If you want to do it this way, I don't see why you would use DHCPv6 and not something like radius, but I suppose you might want to do that if you need to keep state on the server (radius is stateless). --047d7bfea186d1cdb104e9ba389f Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
On Sun, Oct 27, 2013 at 11:52 PM, Gert Doering <gert@space= .net> wrote:
> > I do not think that I made an actual proposal h= ere.
> I mean "Stateful RA could actually be piggybacked onto DHCP, so t= hat the
> router just creates a DHCP message and forwards it upstream, or answer= s
> it locally, depending on the circumstances." xing

This is called "DHCP relay or DHCP server on the router". = =A0I can't see
what this has to do with RA ("periodically multicasted to everyone who=
wants to receive it").

This idea is... completely lacking the understanding of the difference
between solicited and unsolicited information, and also of the existing
possibilities of just having a DHCPv6 server (or relay) on the router
itself.

The way I read that was:
<= div>
1. Host sends RS.
2. Router gets RS, encap= sulates it in DHCPv6 option to DHCPv6 server.
3. Server replies w= ith RA parameters.
4. Router sends unicast RA to host.

The unica= st RA would have more information than the multicast RA (e.g., more specifi= c routes). The idea being that you if you do this you can send different cl= ients different information (which is one of the things that DHCPv6 offers = but RAs typically do not).

So it's basically a RA-to-DHCPv6 translator in the = router.

If you want to do it this way, I don't= see why you would use DHCPv6 and not something like radius, but I suppose = you might want to do that if you need to keep state on the server (radius i= s stateless).
--047d7bfea186d1cdb104e9ba389f-- From nalini.elkins@insidethestack.com Sun Oct 27 07:59:34 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2C62621E80BC for ; Sun, 27 Oct 2013 07:59:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.425 X-Spam-Level: X-Spam-Status: No, score=-2.425 tagged_above=-999 required=5 tests=[AWL=0.173, 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 by3jBMbqDBMz for ; Sun, 27 Oct 2013 07:59:27 -0700 (PDT) Received: from nm21-vm7.access.bullet.mail.bf1.yahoo.com (nm21-vm7.access.bullet.mail.bf1.yahoo.com [216.109.115.134]) by ietfa.amsl.com (Postfix) with ESMTP id BC20D21E80C9 for ; Sun, 27 Oct 2013 07:59:20 -0700 (PDT) Received: from [66.196.81.159] by nm21.access.bullet.mail.bf1.yahoo.com with NNFMP; 27 Oct 2013 14:59:10 -0000 Received: from [66.196.81.129] by tm5.access.bullet.mail.bf1.yahoo.com with NNFMP; 27 Oct 2013 14:59:10 -0000 Received: from [127.0.0.1] by omp1005.access.mail.bf1.yahoo.com with NNFMP; 27 Oct 2013 14:59:10 -0000 X-Yahoo-Newman-Property: ymail-3 X-Yahoo-Newman-Id: 657093.20594.bm@omp1005.access.mail.bf1.yahoo.com Received: (qmail 35450 invoked by uid 60001); 27 Oct 2013 14:59:10 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s1024; t=1382885950; bh=wOKNkdars8PLDZG1U2pbwEK9JDzg+hQGDiwhUmbD9gU=; h=X-YMail-OSG:Received:X-Rocket-MIMEInfo:X-Mailer:References:Message-ID:Date:From:Reply-To:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type; b=M9GqXRiO8q9arPfEFFHASp03HBz85vQSFFvRCF6shTKjyq4uVWdB6jXMwkhXAXkgjQAKUCoiIATJqmm1mVJs3b9yIXMHITxh3Hx9J9dx9fSy/u7rF/CocW/mm+pj7z4mRTla6FCeLXyARMcrLDAkqIED8ovNXo9rxrJDgXICjOQ= X-YMail-OSG: E3Q7NPIVM1mjLxS93qGStooceTupQQ440.tdN4CMPnzFe3I zCLYKlmGMdG1jbDG00jNE6DXuNBDOPrOzCC4ZiA077w.FwCFw3xLZ50sWFMs dSD6X1WoNwlDOy0NHkgeIK6dt3Z7ruzDuwdzCn.zqCuuqUGHtI_bao4nFVCs QDwJSXFEb_4gLOSlsAABbOHIdj7WoUTT8oMvU.a62DikDZdv09dkEegYmL8t HkSh_u0Z2wcmDF1Lu7rEbTiAKCqgq3F.WmvRFBMxwcqldGupxm01nuKH3WBG 1jCj3I1vz9mYY4FWBzgkzmAim.km4YECTpDBS9NkeWEPld4xA6OUjOs9rlO5 LuCpdUFhY0Jv9ieFmzupyOz0AgBBPpl4RJBYAcJtkE8JLY3CsBSG7er1bL9U 1Dv_TxRAQ5miJdJfpyaKUp4c.mGb.XGsNZTUPVyXKU93b9TkDEJIXv7q2sjg e3XNNz6.UddmWGS0OYLfishAECfDO9pNEmm.4Ol58jYSfF8NvMU1h0MUaQFX Zv.TSHkmynEfa6684duBuGek4lNMr3GNPgeJnGRH2.dqhviQxHXXRdOUMxNh 47h9hsyJx.oSHv97glGCT47BjSsXqerN2FJah5kbBTMwy0mFpAoqWyt5i606 AWspLK6tsLL2SYeYj_BcaBDXiJfJwdSm5Hz4CdUWXAU2oL6k.K_oYLtPI Received: from [24.130.37.147] by web2803.biz.mail.ne1.yahoo.com via HTTP; Sun, 27 Oct 2013 07:59:10 PDT X-Rocket-MIMEInfo: 002.001, PiA.WW91ciBwb2ludCA0IHNlZW1zIHRvIGluZGljYXRlIHRoYXQgYWxsIG5vZGVzIGluIGEgZGVzaXJlZCB0aW1lIHN5bmNocm9uaXphdGlvbiBkb21haW4gbmVlZCB0byBiZSBzeW5jaGVkIHRvIHRoZSBzYW1lIG1hc3RlciBjbG9jay7CoCBUaGlzIGhhcyBub3QgYmVlbiBteSBleHBlcmllbmNlLsKgIEFzIGxvbmcgYXMgdGhlIHJlcXVpcmVkIFN0cmF0dW0gbGV2ZWwgaXMgcmVhbGl6ZWQsIGZvciB0aGUgbGV2ZWwgPj5vZiBhY2N1cmFjeSByZXF1aXJlZCBieSB0aGUgc2l0dWF0aW9uIG9yIGFwcGxpY2F0aW8BMAEBAQE- X-Mailer: YahooMailWebService/0.8.160.587 References: <20131017032024.5051.20799.idtracker@ietfa.amsl.com> <1381980305.36254.YahooMailNeo@web2803.biz.mail.ne1.yahoo.com> <5263C783.1080001@globis.net> <1382396300.22968.YahooMailNeo@web2801.biz.mail.ne1.yahoo.com> <526616C4.40304@globis.net> <4FC37E442D05A748896589E468752CAA0CA88734@PWN401EA160.ent.corp.bcbsm.com> <585D21EB-BD17-40C7-9C31-67F12EC6712F@bogus.com> Message-ID: <1382885950.30079.YahooMailNeo@web2803.biz.mail.ne1.yahoo.com> Date: Sun, 27 Oct 2013 07:59:10 -0700 (PDT) From: Nalini Elkins To: joel jaeggli , "Ackermann, Michael" In-Reply-To: <585D21EB-BD17-40C7-9C31-67F12EC6712F@bogus.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="-1551098171-557329641-1382885950=:30079" Cc: Ray Hunter , v6ops WG , 6man WG , "ippm@ietf.org" Subject: Re: [v6ops] New Version Notification for draft-elkins-6man-ipv6-pdm-dest-option-04.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: Nalini Elkins List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 27 Oct 2013 14:59:34 -0000 ---1551098171-557329641-1382885950=:30079 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable > >Your point 4 seems to indicate that all nodes in a desired time synchron= ization domain need to be synched to the same master clock.=C2=A0 This has = not been my experience.=C2=A0 As long as the required Stratum level is real= ized, for the level >>of accuracy required by the situation or application,= the proper level of time synchronization is achieved.=C2=A0 Example would = be that if one node in the NTP domain is referencing a GPS Stratum 0 and an= other node is referencing a >>separate Stratum 0 source, the two nodes shou= ld be Stratum 1 and within that level of accuracy.=C2=A0=C2=A0=0A=0A>stratu= m is not an indication of either precision or accuracy it=E2=80=99s an inid= ication of a position within the NTP heirachary.=0A=0A=0AGuys, you know, I = wonder if this discussion of time synchronization is distracting us from th= e point of our proposal. =C2=A0=C2=A0=0A=0AWhat we are advocating for is a = capability for embedded diagnostics and performance for all upper layer pro= tocols that is relatively simple to implement. =C2=A0 I am thinking more an= d more that our PDM 2 proposal which does not require time synchronization = is the way to go. =C2=A0 Let me say that this is my opinion only! =C2=A0 Ot= hers on our team believe that they can indeed do time synch within their da= ta centers and want the enhanced capabilities of PDM 1 which requires time = synch.=0A=0ABTW, we have discussed the proposals for PDMs already with one = end host OS vendor who, on initial look, believes it will be easy to implem= ent and should be quite useful. =C2=A0 We are setting up more discussions w= ith their engineering team to see if they can tell us where the pit falls i= n our thinking might be. =C2=A0=C2=A0I hope I can get them to comment publi= cly. =C2=A0 But, that will take a while.=0A=0AAlso, one of my guys has alre= ady done a prototype implementation of PDM 1 going from a simple client to = server which I can show all who are interested in Vancouver. =C2=A0=C2=A0= =0A=C2=A0=0A=0AThanks,=0A=0ANalini Elkins=0AInside Products, Inc.=0A(831) 6= 59-8360=0Awww.insidethestack.com=0A=0A=0A=0A_______________________________= _ ---1551098171-557329641-1382885950=:30079 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable
> >Your point 4 = seems to indicate that all nodes in a desired time synchronization domain n= eed to be synched to the same master clock.  This has not been my expe= rience.  As long as the required Stratum level is realized, for the le= vel >>of accuracy required by the situation or application, the prope= r level of time synchronization is achieved.  Example would be that if= one node in the NTP domain is referencing a GPS Stratum 0 and another node= is referencing a >>separate Stratum 0 source, the two nodes should b= e Stratum 1 and within that level of accuracy.  

>st= ratum is not an indication of either precision or accuracy it=E2=80=99s an = inidication of a position within the NTP heirachary.

Guys, you know, I wonde= r if this discussion of time synchronization is distracting us from the poi= nt of our proposal.   

What we are advocating for is a capability for embe= dded diagnostics and performance for all upper layer protocols that is rela= tively simple to implement.   I am thinking more and more that our PDM= 2 proposal which does not require time synchronization is the way to go. &= nbsp; Let me say that this is my opinion only!   Others on our team be= lieve that they can indeed do time synch within their data centers and want= the enhanced capabilities of PDM 1 which requires time synch.

BTW, w= I hope I can get them to comment publicly.   But, that will take a whil= e.
<= br>
= Also, one of my guys has already done a prototype implementation of PDM 1 g= oing from a simple client to server which I can show all who are interested= in Vancouver.   
 
Thanks,

Nalini= Elkins
Inside Products, Inc.
(831) 659-8360
www.insidethestack.co= m

=
 
---1551098171-557329641-1382885950=:30079-- From markzzzsmith@yahoo.com.au Sun Oct 27 13:20:15 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 101D011E81B4 for ; Sun, 27 Oct 2013 13:20:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.824 X-Spam-Level: X-Spam-Status: No, score=-1.824 tagged_above=-999 required=5 tests=[AWL=0.275, BAYES_00=-2.599, FROM_LOCAL_NOVOWEL=0.5] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hRsdZJzG84p7 for ; Sun, 27 Oct 2013 13:20:10 -0700 (PDT) Received: from nm23-vm1.bullet.mail.bf1.yahoo.com (nm23-vm1.bullet.mail.bf1.yahoo.com [98.139.213.141]) by ietfa.amsl.com (Postfix) with ESMTP id F423911E8198 for ; Sun, 27 Oct 2013 13:20:09 -0700 (PDT) Received: from [98.139.212.153] by nm23.bullet.mail.bf1.yahoo.com with NNFMP; 27 Oct 2013 20:20:09 -0000 Received: from [98.139.212.221] by tm10.bullet.mail.bf1.yahoo.com with NNFMP; 27 Oct 2013 20:20:09 -0000 Received: from [127.0.0.1] by omp1030.mail.bf1.yahoo.com with NNFMP; 27 Oct 2013 20:20:09 -0000 X-Yahoo-Newman-Property: ymail-3 X-Yahoo-Newman-Id: 507360.5798.bm@omp1030.mail.bf1.yahoo.com Received: (qmail 68107 invoked by uid 60001); 27 Oct 2013 20:20:09 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com.au; s=s1024; t=1382905209; bh=dPOTuvxlNQvYl+6QzWCaMG+tnplSAyQltnEOUf3+SZg=; h=X-YMail-OSG:Received:X-Rocket-MIMEInfo:X-Mailer:References:Message-ID:Date:From:Reply-To:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type:Content-Transfer-Encoding; b=3Wlf8hr8uj6M/dpYsMn1REU3DGkxv4DUJefws5Mvc/PdoFskcrNR+qbcme5RRNT6qxgmHDC4+Jlih52prYhJy3qrwlZTy92PIlHGoaRMQShDpcxSLaTKzp92FFquXa3WVbvRmRBINcYigaaa3/sXdheWnvbtUqyLiRr5MoaGDhw= DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com.au; h=X-YMail-OSG:Received:X-Rocket-MIMEInfo:X-Mailer:References:Message-ID:Date:From:Reply-To:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type:Content-Transfer-Encoding; b=fP5ygUiJBdKpdWunR7cFwO2h+KS9N2KFcET7ZHBx3/YY3qx+VfgzE55mOj5vSJL8Hz8uh1xSqN8m/9RfV0BApZc/OZ/7GJUGaPctSIz8x+XW8iBl1CYa02UP8EW0EemhXo/54RsaMa2cac8lR1Qj4DpR/47DhbW6XzkFkPD/nRU=; X-YMail-OSG: Ku_LtR0VM1lavHqI3zayhNeTYEunMd9z0DL_yIpiy3aofH9 2NLQQs5.5MrjKiwp8nljYNULYU3C86OIMv.jmi.1weC.SNUUaKm5oJBAVWFs WQzkn9zTWh6jex6xRA76I7GMrG3WIeEngKbvo7yNpt96EpZpT9VK4HHhsb1B 4CflSM4Di8jzS6odCR0SZTpEnshAL1GQbB5taKLcbNNNzSdh1Q1AHH5O6.D. u2JZc2MSOucdktlq1fuMzuaReu5.ZAl6kvZPctEoT0SGBJl8p8v1n6Siq3O8 UNeoGrOE_QeVAijhvmCsxtyPDO8K1DXEophyZhscHw363mBohI8M28nlWTsf ur8DZFJcTNVXWedZxcNzXfIANypfw3cM4WBaicVBDJr3efrI_ju8aBxxO21v .san2kCgVZIfUW3sT.yP3BEYyNjQ2IfTmuPMzmkYnwryI3vpcPMtlTQYiAUr kI6w1UWqDFwMaV7EVZcZjs8EpbXaR.XNvzyB2reC9Yu3tzprEqEyHhZeMolq c_9_fNOrtZJhn68BprNPnvtwLrSUGwqIO_8EfzUzCPu.8ls3HBzfAed1meD1 UYR1l6MTkzJC6cw_3yPV3tmiSyMUM7Yl.lnlW.meZeZYS Received: from [150.101.221.237] by web142503.mail.bf1.yahoo.com via HTTP; Sun, 27 Oct 2013 13:20:07 PDT X-Rocket-MIMEInfo: 002.001, U28gd2hhdCBJIHJlYWxseSB3YW50IHRvIHNlZSBpcyBhbiBhY3R1YWwgYW5kIHNwZWNpZmljIGRlZmluaXRpb24gb2YgdGhlIHByb2JsZW0gd2l0aCBSQXMgZm9yIGNvbnZleWluZyBsYXllciAzIHByb3RvY29sIHBhcmFtZXRlcnMsIG5vdCB0aGUgYXNzZXJ0aW9uIHRoYXQgdGhlcmUgYXJlIHByb2JsZW1zLCBhbmQgdGhlbiB0aW1lIHNwZW50IHNwZWN1bGF0aW5nIG9uIHdheXMgb2YgYWNoaWV2aW5nIGl0LgoKSXQgc2VlbXMgdG8gbWUgdGhhdCB0aGUgdGhpbmdzIHBlb3BsZSBjb21wbGFpbiBvciBtaWdodCABMAEBAQE- X-Mailer: YahooMailWebService/0.8.160.587 References: <06601039-CAFD-49B0-918B-A8ACD51B978D@fugue.com> <526D17A5.9050804@cernet.edu.cn> <526D18F2.8040103@cernet.edu.cn> <20131027145224.GT50205@Space.Net> Message-ID: <1382905207.67992.YahooMailNeo@web142503.mail.bf1.yahoo.com> Date: Sun, 27 Oct 2013 13:20:07 -0700 (PDT) From: Mark ZZZ Smith To: Lorenzo Colitti , Gert Doering In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Cc: "draft-liu-bonica-v6ops-dhcpv6-slaac-problem@tools.ietf.org" , "v6ops@ietf.org" , Ted Lemon , "Ole Troan \(otroan\)" , Dave Thaler Subject: Re: [v6ops] DHCPv6/SLAAC Make Hosts Confusing-//RE: new draft: draft-liu-bonica-v6ops-dhcpv6-slaac-problem X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: Mark ZZZ Smith List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 27 Oct 2013 20:20:15 -0000 So what I really want to see is an actual and specific definition of the pr= oblem with RAs for conveying layer 3 protocol parameters, not the assertion= that there are problems, and then time spent speculating on ways of achiev= ing it.=0A=0AIt seems to me that the things people complain or might compla= in about RAs are :=0A=0A(1) it is different to how it is done in IPv4, whic= h is therefore asserting that IPv4 DHCP is the best way to solve the addres= s configuration problem (which is different to the way the problem has been= previously solved in every other protocol, including original IPv4, and ne= eds to be considered in the context of when it was developed (IIRC, the pri= mary thing DHCPv4 solved at the time, over bootp from which it is derived, = was the ability to have more physical hosts than addresses, as long as the = number of active hosts was less than or equal to the number of addresses. )= =0A=0A(2) it is database driven, so there are records of active addresses i= n use (which isn't actually the case, because DHCPv6 won't capture link-loc= al addresses in use, or statically configured addresses)=0A=0A(3) periodic = unsolicited multicasts=0A=0ASo I think (2) is invalid, as it won't record l= ink-local or static addresses in use. A better method would be to have the = routers on the link monitor DADs, and them via some other method.=0A=0AI th= ink (3) is invalid, as by default RAs are announced once every 10 minutes, = which means is RA multicasts are likely to be lesser of multicast traffic o= n the network. That timer can be changed to up to once very 30 minutes.=0A= =0AWhich leaves (1). I don't think just because something is different is a= reason to change it, when it has been shown to work.=0A=0AThe costs of pro= viding two different methods for layer 3 network to host configuration woul= d now be huge. It isn't just a matter of defining the methods in the IETF, = which is cheap. For it to be useful and effective, it needs to be developed= , debugged, deployed and supported/troubleshooted on hosts. Specifically, *= all* possible hosts that might be exposed to the new method, which includes= the billion+ IPv6 capable smartphones and tablets that are already deploye= d. Any IPv6 segment that a host might attach to might be using one or the o= ther of these methods. To facilitate a smooth transition to DHCPv6 for ever= ything, RAs will have to be enabled anyway ...=0A=0A=0AI don't think the ar= gument that this decision is isolated to a network is valid. I'm guessing t= he example people are thinking of is the IS-IS vs OSPF vs other IGPs choice= inside a network. However, that is nicely partitioned and isolated to a ne= twork using BGP (a single protocol between two different parties), and the = only people who are impacted by the choice are the same people who choose, = deploy and operate the devices in question, and their vendors (and the vend= ors won't provide that choice unless their are enough paying customers). A = host to network interaction is very different when hosts are commonly owned= , operated and developed by parties that are both exposed to the choice of = the protocol between the host and the network but have no or very little sa= y in it.=0A=0ASo provide evidence that RAs are inadequate, and that the hug= e time, effort and cost involved in moving to a dual RA and DHCPv6 method i= s worth while. Justify why creating more reasons not to deploy IPv6, by cre= ating more choice and therefore more uncertainty, are worthwhile.=0A=0ACrea= te a problem statement before working on a solution to it.=0A=0ARegards,=0A= Mark.=0A=0A=0A=0A=0A>________________________________=0A> From: Lorenzo Col= itti =0A>To: Gert Doering =0A>Cc: "v6o= ps@ietf.org" ; Ted Lemon ; Ole Troan (otr= oan) ; Dave Thaler ; "draft-liu-bo= nica-v6ops-dhcpv6-slaac-problem@tools.ietf.org" =0A>Sent: Monday, 28 October 2013 1:58 AM= =0A>Subject: Re: [v6ops] DHCPv6/SLAAC Make Hosts Confusing-//RE: new draft:= =A0=A0=A0=A0draft-liu-bonica-v6ops-dhcpv6-slaac-problem=0A> =0A>=0A>=0A>On = Sun, Oct 27, 2013 at 11:52 PM, Gert Doering wrote:=0A>=0A>= > > I do not think that I made an actual proposal here.=0A>>> I mean "State= ful RA could actually be piggybacked onto DHCP, so that the=0A>>> router ju= st creates a DHCP message and forwards it upstream, or answers=0A>>> it loc= ally, depending on the circumstances." xing=0A>>=0A>>This is called "DHCP r= elay or DHCP server on the router". =A0I can't see=0A>>what this has to do = with RA ("periodically multicasted to everyone who=0A>>wants to receive it"= ).=0A>>=0A>>This idea is... completely lacking the understanding of the dif= ference=0A>>between solicited and unsolicited information, and also of the = existing=0A>>possibilities of just having a DHCPv6 server (or relay) on the= router=0A>>itself.=0A>>=0A>=0A>=0A>The way I read that was:=0A>=0A>=0A>1. = Host sends RS.=0A>=0A>2. Router gets RS, encapsulates it in DHCPv6 option t= o DHCPv6 server.=0A>3. Server replies with RA parameters.=0A>4. Router send= s unicast RA to host.=0A>=0A>=0A>The unicast RA would have more information= than the multicast RA (e.g., more specific routes). The idea being that yo= u if you do this you can send different clients different information (whic= h is one of the things that DHCPv6 offers but RAs typically do not).=0A>=0A= >=0A>So it's basically a RA-to-DHCPv6 translator in the router.=0A>=0A>=0A>= If you want to do it this way, I don't see why you would use DHCPv6 and not= something like radius, but I suppose you might want to do that if you need= to keep state on the server (radius is stateless).=0A>=0A>________________= _______________________________=0A>v6ops mailing list=0A>v6ops@ietf.org=0A>= https://www.ietf.org/mailman/listinfo/v6ops=0A>=0A>=0A> From xing@cernet.edu.cn Sun Oct 27 16:21:56 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B150311E82D1 for ; Sun, 27 Oct 2013 16:21:56 -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 LpM-PV36CE3E for ; Sun, 27 Oct 2013 16:21:50 -0700 (PDT) Received: from cernet.edu.cn (sea.net.edu.cn [202.112.39.2]) by ietfa.amsl.com (Postfix) with ESMTP id 86C9311E8196 for ; Sun, 27 Oct 2013 16:21:47 -0700 (PDT) Received: from [127.0.0.1] (unknown [125.34.53.14]) by centos (Coremail) with SMTP id AQAAf3A7HwSLn21Svx4pAA--.43940S5; Mon, 28 Oct 2013 07:19:42 +0800 (CST) Message-ID: <526D9FFC.9060307@cernet.edu.cn> Date: Mon, 28 Oct 2013 07:21:32 +0800 From: Xing Li User-Agent: Thunderbird 2.0.0.24 (Windows/20100228) MIME-Version: 1.0 To: Lorenzo Colitti References: <06601039-CAFD-49B0-918B-A8ACD51B978D@fugue.com> <526D17A5.9050804@cernet.edu.cn> <526D18F2.8040103@cernet.edu.cn> <20131027145224.GT50205@Space.Net> In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit X-CM-TRANSID: AQAAf3A7HwSLn21Svx4pAA--.43940S5 X-Coremail-Antispam: 1UD129KBjvJXoW7Zr48uFy7Ar4xJryfCr47twb_yoW8Wr1rpF W8KF1kA3WDtw1xAwn7Awn7ZF93Cr1kKas3J3sxJwn7Zrn8CFy2qr1Fkayfuas7WFs3AF1j v3yqy34fu3sxZaDanT9S1TB71UUUUUUqnTZGkaVYY2UrUUUUjbIjqfuFe4nvWSU5nxnvy2 9KBjDU0xBIdaVrnRJUUUDFb7Iv0xC_Zr1lb4IE77IF4wAFF20E14v26ryj6rWUM7CY07I2 0VC2zVCF04k26cxKx2IYs7xG6rWj6s0DM7CIcVAFz4kK6r1j6r18M28lY4IEw2IIxxk0rw A2z4x0Y4vE2Ix0cI8IcVAFwI0_Jr0_JF4l84ACjcxK6xIIjxv20xvEc7CjxVAFwI0_Gr0_ Cr1l84ACjcxK6I8E87Iv67AKxVW8JVWxJwA2z4x0Y4vEx4A2jsIEc7CjxVAFwI0_Gr0_Gr 1UM2AIxVAIcxkEcVAq07x20xvEncxIr21l5I8CrVACY4xI64kE6c02F40Ex7xfMcIj6I8E 87Iv67AKxVWUJVW8JwAm72CE4IkC6x0Yz7v_Jr0_Gr1lF7xvr2IY64vIr41lc2xSY4AK67 AK6FWl42xK82IYc2Ij64vIr41lx2IqxVAqx4xG67AKxVWUJVWUGwC20s026x8GjcxK67AK xVWUGVWUWwC2zVAF1VAY17CE14v26r126r1DMIIYrxkI7VAKI48JMIIF0xvE2Ix0cI8IcV AFwI0_Jr0_JF4lIxAIcVC0I7IYx2IY6xkF7I0E14v26r1j6r4UMIIF0xvE42xK8VAvwI8I cIk0rVWrZr1j6s0DMIIF0xvEx4A2jsIE14v26r1j6r4UMIIF0xvEx4A2jsIEc7CjxVAFwI 0_Jr0_GrUvcSsGvfC2KfnxnUUI43ZEXa7IU0beOJUUUUU== X-CM-SenderInfo: p0lqwqxfhu0vvwohv3gofq/ Cc: "v6ops@ietf.org" , Ted Lemon , "Ole Troan \(otroan\)" , Dave Thaler , "draft-liu-bonica-v6ops-dhcpv6-slaac-problem@tools.ietf.org" Subject: Re: [v6ops] DHCPv6/SLAAC Make Hosts Confusing-//RE: new draft: draft-liu-bonica-v6ops-dhcpv6-slaac-problem X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 27 Oct 2013 23:21:56 -0000 Lorenzo Colitti 写道: > On Sun, Oct 27, 2013 at 11:52 PM, Gert Doering > wrote: > > > > I do not think that I made an actual proposal here. > > I mean "Stateful RA could actually be piggybacked onto DHCP, so > that the > > router just creates a DHCP message and forwards it upstream, or > answers > > it locally, depending on the circumstances." xing > > This is called "DHCP relay or DHCP server on the router". I can't see > what this has to do with RA ("periodically multicasted to everyone who > wants to receive it"). > > This idea is... completely lacking the understanding of the difference > between solicited and unsolicited information, and also of the > existing > possibilities of just having a DHCPv6 server (or relay) on the router > itself. > > > The way I read that was: > > 1. Host sends RS. > 2. Router gets RS, encapsulates it in DHCPv6 option to DHCPv6 server. > 3. Server replies with RA parameters. > 4. Router sends unicast RA to host. > > The unicast RA would have more information than the multicast RA > (e.g., more specific routes). The idea being that you if you do this > you can send different clients different information (which is one of > the things that DHCPv6 offers but RAs typically do not). > > So it's basically a RA-to-DHCPv6 translator in the router. > > If you want to do it this way, I don't see why you would use DHCPv6 > and not something like radius, but I suppose you might want to do that > if you need to keep state on the server (radius is stateless). +1. The stateful configuration is required in CERNET2 case. xing From meng.wei2@zte.com.cn Sun Oct 27 19:49:33 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 963BE11E8215 for ; Sun, 27 Oct 2013 19:49:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -99.998 X-Spam-Level: X-Spam-Status: No, score=-99.998 tagged_above=-999 required=5 tests=[BAYES_50=0.001, 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 uQ4BxFO84TNo for ; Sun, 27 Oct 2013 19:49:28 -0700 (PDT) Received: from mx5.zte.com.cn (mx5.zte.com.cn [63.217.80.70]) by ietfa.amsl.com (Postfix) with ESMTP id E63A511E82EB for ; Sun, 27 Oct 2013 19:49:26 -0700 (PDT) Received: from zte.com.cn (unknown [192.168.168.119]) by Websense Email Security Gateway with ESMTP id AF57512C49A8 for ; Mon, 28 Oct 2013 10:49:12 +0800 (CST) Received: from mse01.zte.com.cn (unknown [10.30.3.20]) by Websense Email Security Gateway with ESMTPS id 1A84572D223 for ; Mon, 28 Oct 2013 10:49:11 +0800 (CST) Received: from notes_smtp.zte.com.cn ([10.30.1.239]) by mse01.zte.com.cn with ESMTP id r9S2mtKF092139 for ; Mon, 28 Oct 2013 10:48:59 +0800 (GMT-8) (envelope-from meng.wei2@zte.com.cn) In-Reply-To: <526D9FFC.9060307@cernet.edu.cn> To: v6ops@ietf.org MIME-Version: 1.0 X-KeepSent: B7C11E0F:00D5BD9F-48257C12:000D206A; type=4; name=$KeepSent X-Mailer: Lotus Notes Release 6.5.6 March 06, 2007 Message-ID: From: meng.wei2@zte.com.cn Date: Mon, 28 Oct 2013 10:48:58 +0800 X-MIMETrack: Serialize by Router on notes_smtp/zte_ltd(Release 8.5.3FP1 HF212|May 23, 2012) at 2013-10-28 10:48:46, Serialize complete at 2013-10-28 10:48:46 Content-Type: multipart/alternative; boundary="=_alternative 000F93EE48257C12_=" X-MAIL: mse01.zte.com.cn r9S2mtKF092139 Subject: [v6ops] Comments on draft-sun-v6ops-openv6-address-pool-management. X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 28 Oct 2013 02:49:33 -0000 This is a multipart message in MIME format. --=_alternative 000F93EE48257C12_= Content-Type: text/plain; charset="US-ASCII" Hi authors, Sharing global IP address is a interesting topic of pool management. The pool management will be migrated to centralized mode to avoid complex configurations in NAT44/NAT64, even in DHCP pools. I reviewed this draft. I'm not sure whether we should define more detail in request-ack between client and server? Or we should defined a specific protocol? Or we should define some parameters ,such as priority/threshold... Cheers, Wei Meng ZTE -------------------------------------------------------- ZTE Information Security Notice: The information contained in this mail (and any attachment transmitted herewith) is privileged and confidential and is intended for the exclusive use of the addressee(s). If you are not an intended recipient, any disclosure, reproduction, distribution or other dissemination or use of the information contained is strictly prohibited. If you have received this mail in error, please delete it and notify us immediately. -------------------------------------------------------- ZTE Information Security Notice: The information contained in this mail (and any attachment transmitted herewith) is privileged and confidential and is intended for the exclusive use of the addressee(s). If you are not an intended recipient, any disclosure, reproduction, distribution or other dissemination or use of the information contained is strictly prohibited. If you have received this mail in error, please delete it and notify us immediately. --=_alternative 000F93EE48257C12_= Content-Type: text/html; charset="US-ASCII"
Hi authors,

    Sharing global IP address is a interesting topic of pool management. The pool
management will be migrated to centralized mode to avoid complex configurations in
NAT44/NAT64, even in DHCP pools.

    I reviewed this draft. I'm not sure whether we should define more detail in
request-ack between client and server? Or we should defined a specific protocol?
Or we should define some parameters ,such as priority/threshold...

Cheers,

Wei Meng
ZTE 

--------------------------------------------------------
ZTE Information Security Notice: The information contained in this mail (and any attachment transmitted herewith) is privileged and confidential and is intended for the exclusive use of the addressee(s).  If you are not an intended recipient, any disclosure, reproduction, distribution or other dissemination or use of the information contained is strictly prohibited.  If you have received this mail in error, please delete it and notify us immediately.





--------------------------------------------------------
ZTE Information Security Notice: The information contained in this mail (and any attachment transmitted herewith) is privileged and confidential and is intended for the exclusive use of the addressee(s).  If you are not an intended recipient, any disclosure, reproduction, distribution or other dissemination or use of the information contained is strictly prohibited.  If you have received this mail in error, please delete it and notify us immediately.

--=_alternative 000F93EE48257C12_=-- From bingxuere@gmail.com Sun Oct 27 22:17:33 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BD73111E8311 for ; Sun, 27 Oct 2013 22:17:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_13=0.6, 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 szJTgvpaQKHw for ; Sun, 27 Oct 2013 22:17:32 -0700 (PDT) Received: from mail-ve0-x22b.google.com (mail-ve0-x22b.google.com [IPv6:2607:f8b0:400c:c01::22b]) by ietfa.amsl.com (Postfix) with ESMTP id 96DC511E80FC for ; Sun, 27 Oct 2013 22:17:28 -0700 (PDT) Received: by mail-ve0-f171.google.com with SMTP id pa12so4178172veb.2 for ; Sun, 27 Oct 2013 22:17:28 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=HbWS7l32gvugz3slDHcyG9ITzjS7VS7FtAbG0AWFaYw=; b=Dp3g5xlyIVZBDGLCX+/t27FaQHYsjU8FJBuped1ZYxb8F7dKBRWkY934rceq96FByX KqLbM1pLzItnvRBOBDKmpEbZKl7ssatiWdk6kZkFpkZCMynh/J6AVJ/I0ziEO7r0LpWq UNIZGW9Dyf+5V5LyPxDRqUqzOj4Me7/qF7gGBmfPoXR87nYo49fFQssUAXGZi5JMPxv4 Vh9IAiIb3o5YpGD5V8rrhthlqH+46XCbNlJ71hjncvAL7TdSXVvXP/nN5/fA+PhNz7Q5 GusmdY6lgizAvAtQNuhYxBdnL9Q8gf+MASo+JXTD1HgH5+8bHZrhpGDxVS3LHHvS6wXz EgZQ== X-Received: by 10.52.118.73 with SMTP id kk9mr10109505vdb.13.1382937447991; Sun, 27 Oct 2013 22:17:27 -0700 (PDT) MIME-Version: 1.0 Received: by 10.220.93.6 with HTTP; Sun, 27 Oct 2013 22:16:47 -0700 (PDT) In-Reply-To: References: <526D9FFC.9060307@cernet.edu.cn> From: Qiong Date: Mon, 28 Oct 2013 13:16:47 +0800 Message-ID: To: meng.wei2@zte.com.cn Content-Type: multipart/alternative; boundary=089e0122f0f255923b04e9c63752 Cc: "v6ops@ietf.org" Subject: Re: [v6ops] Comments on draft-sun-v6ops-openv6-address-pool-management. X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 28 Oct 2013 05:17:33 -0000 --089e0122f0f255923b04e9c63752 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Hi Wei, Thanks for your review and comments. Yes, we are trying to solve the problem of the scattered address pool management. Currently, there are many transition devices deployed in our network (even multiple transition instances will be needed for different purpose or redundancy). However, different transition instance needs to be configured with separated address pools. That will bring a great burden for operators to manage rather scattered address pools. More detailed protocol and parameters definitions are needed and will be included in the next version. Here we would like to get suggestions/comments from v6ops about this framework/solution. Your further comments/suggestion/input are highly appreciated. Best wishes Qiong On Mon, Oct 28, 2013 at 10:48 AM, wrote: > > Hi authors, > > Sharing global IP address is a interesting topic of pool management. > The pool > management will be migrated to centralized mode to avoid complex > configurations in > NAT44/NAT64, even in DHCP pools. > > I reviewed this draft. I'm not sure whether we should define more > detail in > request-ack between client and server? Or we should defined a specific > protocol? > Or we should define some parameters ,such as priority/threshold... > > Cheers, > > Wei Meng > ZTE > > > -------------------------------------------------------- > ZTE Information Security Notice: The information contained in this mail (= and any attachment transmitted herewith) is privileged and confidential and= is intended for the exclusive use of the addressee(s). If you are not an = intended recipient, any disclosure, reproduction, distribution or other dis= semination or use of the information contained is strictly prohibited. If = you have received this mail in error, please delete it and notify us immedi= ately. > > > > > > -------------------------------------------------------- > ZTE Information Security Notice: The information contained in this mail (= and any attachment transmitted herewith) is privileged and confidential and= is intended for the exclusive use of the addressee(s). If you are not an = intended recipient, any disclosure, reproduction, distribution or other dis= semination or use of the information contained is strictly prohibited. If = you have received this mail in error, please delete it and notify us immedi= ately. > > > > > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops > > --=20 =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D Qiong Sun China Telecom Beijing Research Institude Open source code: lightweight 4over6: *http://sourceforge.net/projects/laft6/* PCP-natcoord:* http://sourceforge.net/projects/pcpportsetdemo/ * =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D --089e0122f0f255923b04e9c63752 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hi Wei,

Thanks for your review and comm= ents.

Yes, we are trying to solve the problem of t= he scattered address pool management. Currently, there are many transition = devices deployed=20 in our network (even multiple transition instances will be needed for diffe= rent=20 purpose or redundancy). However, different transition instance=C2=A0needs t= o be=20 configured with=C2=A0separated address pools. That will bring a great burde= n for=20 operators to manage rather scattered address pools.=C2=A0

More detailed protocol and parameters definitions are needed and wi= ll be included in the next version. Here we would like to get suggestions/c= omments from v6ops about this framework/solution.

Your further comments/suggestion/input are highly appre= ciated.=C2=A0

Best wishes
Qiong



On Mon, Oct 28, 2013 at 10:48 AM, <meng.wei2@zte.com.cn>= wrote:

Hi authors,

=C2=A0 =C2=A0 Sharing global IP address is a interesti= ng topic of pool management. The pool
management will be migrated to centralized mode to avo= id complex configurations in
NAT44/NAT64, even in DHCP pools.

=C2=A0 =C2=A0 I reviewed this draft. I'm not sure = whether we should define more detail in
request-ack between client and server? Or we should de= fined a specific protocol?
Or we should define some parameters ,such as priority/= threshold...

Cheers,

Wei Meng
ZTE 

--------------------------------------------------------
ZTE Information Security Notice: The information contained in this mail (an=
d any attachment transmitted herewith) is privileged and confidential and i=
s intended for the exclusive use of the addressee(s).  If you are not an in=
tended recipient, any disclosure, reproduction, distribution or other disse=
mination or use of the information contained is strictly prohibited.  If yo=
u have received this mail in error, please delete it and notify us immediat=
ely.





--------------------------------------------------------
ZTE Information Security Notice: The information contained in this mail (an=
d any attachment transmitted herewith) is privileged and confidential and i=
s intended for the exclusive use of the addressee(s).  If you are not an in=
tended recipient, any disclosure, reproduction, distribution or other disse=
mination or use of the information contained is strictly prohibited.  If yo=
u have received this mail in error, please delete it and notify us immediat=
ely.


_______________________________________________
v6ops mailing list
v6ops@ietf.org
h= ttps://www.ietf.org/mailman/listinfo/v6ops




--
=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
Qiong Sun
C= hina Telecom Beijing Research Institude


Open source code:
lig= htweight 4over6: http://sourceforge.net/projects/laft6/
PCP-natcoord: http://sourceforge.net/projects/pcpportsetdemo/
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
--089e0122f0f255923b04e9c63752-- From alexandru.petrescu@gmail.com Mon Oct 28 08:17:02 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 23A5D11E817F for ; Mon, 28 Oct 2013 08:17:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.993 X-Spam-Level: X-Spam-Status: No, score=-9.993 tagged_above=-999 required=5 tests=[AWL=-0.344, BAYES_00=-2.599, HELO_EQ_FR=0.35, J_CHICKENPOX_13=0.6, 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 LklL61imEhvR for ; Mon, 28 Oct 2013 08:16:57 -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 EDBE511E814C for ; Mon, 28 Oct 2013 08:16:33 -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.3) with ESMTP id r9SFGWcj006800 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT) for ; Mon, 28 Oct 2013 16:16:32 +0100 Received: from muguet2.intra.cea.fr (muguet2.intra.cea.fr [132.166.192.7]) by pisaure.intra.cea.fr (8.14.4/8.14.4) with ESMTP id r9SFGVKM028605 for ; Mon, 28 Oct 2013 16:16:31 +0100 (envelope-from alexandru.petrescu@gmail.com) Received: from [127.0.0.1] (is010446-4.intra.cea.fr [10.8.33.116]) by muguet2.intra.cea.fr (8.13.8/8.13.8/CEAnet-Intranet-out-1.2) with ESMTP id r9SFGQ4u017954 for ; Mon, 28 Oct 2013 16:16:31 +0100 Message-ID: <526E7FCA.60702@gmail.com> Date: Mon, 28 Oct 2013 16:16:26 +0100 From: Alexandru Petrescu User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:24.0) Gecko/20100101 Thunderbird/24.0.1 MIME-Version: 1.0 To: v6ops@ietf.org References: <06601039-CAFD-49B0-918B-A8ACD51B978D@fugue.com> <526D17A5.9050804@cernet.edu.cn> <526D18F2.8040103@cernet.edu.cn> <20131027145224.GT50205@Space.Net> <526D9FFC.9060307@cernet.edu.cn> In-Reply-To: <526D9FFC.9060307@cernet.edu.cn> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Subject: Re: [v6ops] DHCPv6/SLAAC Make Hosts Confusing-//RE: new draft: draft-liu-bonica-v6ops-dhcpv6-slaac-problem X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 28 Oct 2013 15:17:02 -0000 Le 28/10/2013 00:21, Xing Li a écrit : > Lorenzo Colitti 写道: >> On Sun, Oct 27, 2013 at 11:52 PM, Gert Doering > > wrote: >> >> > > I do not think that I made an actual proposal here. >> > I mean "Stateful RA could actually be piggybacked onto DHCP, so >> that the >> > router just creates a DHCP message and forwards it upstream, or >> answers >> > it locally, depending on the circumstances." xing >> >> This is called "DHCP relay or DHCP server on the router". I can't see >> what this has to do with RA ("periodically multicasted to everyone >> who >> wants to receive it"). >> >> This idea is... completely lacking the understanding of the >> difference >> between solicited and unsolicited information, and also of the >> existing >> possibilities of just having a DHCPv6 server (or relay) on the router >> itself. >> >> >> The way I read that was: >> >> 1. Host sends RS. >> 2. Router gets RS, encapsulates it in DHCPv6 option to DHCPv6 server. >> 3. Server replies with RA parameters. >> 4. Router sends unicast RA to host. >> >> The unicast RA would have more information than the multicast RA >> (e.g., more specific routes). The idea being that you if you do this >> you can send different clients different information (which is one of >> the things that DHCPv6 offers but RAs typically do not). >> >> So it's basically a RA-to-DHCPv6 translator in the router. >> >> If you want to do it this way, I don't see why you would use DHCPv6 >> and not something like radius, but I suppose you might want to do that >> if you need to keep state on the server (radius is stateless). > > +1. The stateful configuration is required in CERNET2 case. xing This was proposed in the past and it has advantages to which I could agree. I thought the goal was to not modify RA, whereas the above does modify the RA to include a DNS resolver. If yes, would it be ok to include a Prefix Delegation option as well in the RA? (not an RFC4191 option, but a new Prefix Delegation option pasted from DHCPv6 Prefix Delegation). Alex > > > > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops From jhw@conjury.org Mon Oct 28 08:50:29 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2857111E8160 for ; Mon, 28 Oct 2013 08:50:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[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 GV9vvUbm5g+4 for ; Mon, 28 Oct 2013 08:50:23 -0700 (PDT) Received: from prime.conjury.org (prime.conjury.org [174.136.98.234]) by ietfa.amsl.com (Postfix) with ESMTP id C284911E8166 for ; Mon, 28 Oct 2013 08:50:19 -0700 (PDT) Received: from [10.0.1.2] (moon.conjury.org [50.0.204.61]) by prime.conjury.org (Postfix) with ESMTPSA id A3FCEAE8DF; Mon, 28 Oct 2013 08:54:04 -0700 (PDT) Content-Type: multipart/alternative; boundary="Apple-Mail=_2E053BF0-3465-4924-90BB-85DEC9717686" Mime-Version: 1.0 (Mac OS X Mail 7.0 \(1816\)) From: james woodyatt In-Reply-To: Date: Mon, 28 Oct 2013 08:50:14 -0700 Message-Id: References: <52689EE0.3030201@inex.ie> To: Lorenzo Colitti X-Mailer: Apple Mail (2.1816) Cc: V6OPS Working Group Subject: Re: [v6ops] DHCPv6/SLAAC Make Hosts Confusing-//RE: new draft: draft-liu-bonica-v6ops-dhcpv6-slaac-problem X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 28 Oct 2013 15:50:29 -0000 --Apple-Mail=_2E053BF0-3465-4924-90BB-85DEC9717686 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 On Oct 23, 2013, at 23:41 , Lorenzo Colitti wrote: > I see two possible ways out of this: >=20 > 1. Decide a clear split between what goes into RA and what goes into = DHCPv6, and then stick to it. For example, we could say that = configuration information that is required to obtain basic connectivity = on a network must be available in RA so it can be dynamically updated = and shares fate with routing, and that everything that's not strictly = required for the host's connectivity can go into DHCPv6. I don't know if = it will be possible to draw a line here. If operators insist that DHCPv6 = by itself must be sufficient, then we have no choice but to duplicate = information. I prefer this way out. I've said this before, but now seems like a good = time to say it again: stateless DHCPv6 has a lifetime of information = problem, and I think RFC 3736 should be sent to pasture. p1. If there are information objects that must be individually and = separately configured at each host by the network, then stateful DHCPv6 = [RFC 3315] is the protocol for doing that. p2. The only information objects that deserve to be in RA messages are = those that facilitate discovering routers and domain name resolving = servers. (If pressed, I can come up with a couple of very minor = exceptions, but I'm saving that for another discussion.) p3. If there are information objects that do not strictly need to be = individually and separately configured at each host by the network, and = they are also not strictly required to facilitate routing and domain = service discovery, then there are two viable options available: A) use = stateful DHCPv6 despite not requiring state, or B) use DNS-SD, which is = stateless. If both are available on the same network, then DHCPv6 = information should override DNS-SD information, because=97 well=97 = sometimes the network decides that hosts need state. There is no good = reason to lard up RA messages with this stuff too. If operators insist that DHCPv6 by itself MUST be sufficient, then the = only information that requires duplication is the minimal set that is = currently defined in RA messages. Everything else --james woodyatt --Apple-Mail=_2E053BF0-3465-4924-90BB-85DEC9717686 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=windows-1252 On Oct = 23, 2013, at 23:41 , Lorenzo Colitti <lorenzo@google.com> = wrote:

I see = two possible ways out of this:

1. Decide a clear split between what = goes into RA and what goes into DHCPv6, and then stick to it. For = example, we could say that configuration information that is required to = obtain basic connectivity on a network must be available in RA so it can = be dynamically updated and shares fate with routing, and that everything = that's not strictly required for the host's connectivity can go into = DHCPv6. I don't know if it will be possible to draw a line here. If = operators insist that DHCPv6 by itself must be sufficient, then we have = no choice but to duplicate = information.

I prefer this way out. =  I've said this before, but now seems like a good time to say it = again: stateless DHCPv6 has a lifetime of information problem, and I = think RFC 3736 should be sent to pasture.

p1. = If there are information objects that must be individually and = separately configured at each host by the network, then stateful DHCPv6 = [RFC 3315] is the protocol for doing that.

p2. = The only information objects that deserve to be in RA messages are those = that facilitate discovering routers and domain name resolving servers. = (If pressed, I can come up with a couple of very minor exceptions, but = I'm saving that for another discussion.)

p3. If = there are information objects that do not strictly need to be = individually and separately configured at each host by the network, and = they are also not strictly required to facilitate routing and domain = service discovery, then there are two viable options available: A) use = stateful DHCPv6 despite not requiring state, or B) use DNS-SD, which is = stateless.  If both are available on the same network, then DHCPv6 = information should override DNS-SD information, because=97 well=97 = sometimes the network decides that hosts need state. There is no good = reason to lard up RA messages with this stuff = too.

If operators insist that DHCPv6 by itself = MUST be sufficient, then the only information that requires duplication = is the minimal set that is currently defined in RA messages. Everything = else

jhw@conjury.org>




= --Apple-Mail=_2E053BF0-3465-4924-90BB-85DEC9717686-- From gert@space.net Mon Oct 28 09:12:24 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7053711E8248 for ; Mon, 28 Oct 2013 09:12:24 -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.163, 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 FBXVO5z0xZpD for ; Mon, 28 Oct 2013 09:12:24 -0700 (PDT) Received: from mobil.space.net (mobil.space.net [IPv6:2001:608:2:81::67]) by ietfa.amsl.com (Postfix) with ESMTP id 1FBB811E8185 for ; Mon, 28 Oct 2013 09:12:21 -0700 (PDT) Received: from mobil.space.net (localhost [127.0.0.1]) by mobil.space.net (Postfix) with ESMTP id 3CC9F608C6 for ; Mon, 28 Oct 2013 17:12:19 +0100 (CET) X-SpaceNet-Relay: true Received: from moebius3.space.net (moebius3.Space.Net [IPv6:2001:608:2:2::250]) by mobil.space.net (Postfix) with ESMTPS id 1138B608AF for ; Mon, 28 Oct 2013 17:12:19 +0100 (CET) Received: (qmail 22905 invoked by uid 1007); 28 Oct 2013 17:12:19 +0100 Date: Mon, 28 Oct 2013 17:12:19 +0100 From: Gert Doering To: Alexandru Petrescu Message-ID: <20131028161219.GQ50205@Space.Net> References: <06601039-CAFD-49B0-918B-A8ACD51B978D@fugue.com> <526D17A5.9050804@cernet.edu.cn> <526D18F2.8040103@cernet.edu.cn> <20131027145224.GT50205@Space.Net> <526D9FFC.9060307@cernet.edu.cn> <526E7FCA.60702@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <526E7FCA.60702@gmail.com> X-NCC-RegID: de.space User-Agent: Mutt/1.5.21 (2010-09-15) Cc: v6ops@ietf.org Subject: Re: [v6ops] DHCPv6/SLAAC Make Hosts Confusing-//RE: new draft: draft-liu-bonica-v6ops-dhcpv6-slaac-problem X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 28 Oct 2013 16:12:24 -0000 Hi, On Mon, Oct 28, 2013 at 04:16:26PM +0100, Alexandru Petrescu wrote: > I thought the goal was to not modify RA, whereas the above does modify > the RA to include a DNS resolver. Uh. *That* train has sailed 6 years ago with RFC5006... > If yes, would it be ok to include a Prefix Delegation option as well in > the RA? (not an RFC4191 option, but a new Prefix Delegation option > pasted from DHCPv6 Prefix Delegation). What use would that be? The benefit of RA is that "everyone can see them and the information contained applies to *all* consumers, and is periodically refreshed without having to poll". PD is, by definition, very specific to the device where you delegate to... This thread is full of weirdness. Gert Doering -- NetMaster -- have you enabled IPv6 on something today...? SpaceNet AG Vorstand: Sebastian v. Bomhard Joseph-Dollinger-Bogen 14 Aufsichtsratsvors.: A. Grundner-Culemann D-80807 Muenchen HRB: 136055 (AG Muenchen) Tel: +49 (0)89/32356-444 USt-IdNr.: DE813185279 From mackermann@bcbsm.com Mon Oct 28 09:13:24 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1536621E8095 for ; Mon, 28 Oct 2013 09:13:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.035 X-Spam-Level: X-Spam-Status: No, score=-6.035 tagged_above=-999 required=5 tests=[AWL=-0.036, BAYES_00=-2.599, J_CHICKENPOX_13=0.6, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dssZnZ0JDLgy for ; Mon, 28 Oct 2013 09:13:23 -0700 (PDT) Received: from mx.z120.zixworks.com (mx.z120.zixworks.com [199.30.235.120]) by ietfa.amsl.com (Postfix) with ESMTP id 2957821E8091 for ; Mon, 28 Oct 2013 09:13:18 -0700 (PDT) Received: from vmvpm02.z120.zixworks.com (ZixVPM [127.0.0.1]) by Outbound.z120.zixworks.com (Proprietary) with ESMTP id 5AAB12FF652 for ; Mon, 28 Oct 2013 11:13:17 -0500 (CDT) Received: from imsva1.bcbsm.com (unknown [12.107.172.80]) by mx.z120.zixworks.com (Proprietary) with SMTP id 23FA3307427; Mon, 28 Oct 2013 11:13:16 -0500 (CDT) Received: from imsva1.bcbsm.com (unknown [127.0.0.1]) by IMSVA80 (Postfix) with ESMTP id 0CF194F804D; Mon, 28 Oct 2013 12:02:52 -0400 (EDT) Received: from pwn401ea100.ent.corp.bcbsm.com (unknown [10.64.80.217]) by imsva1.bcbsm.com (Postfix) with ESMTP id E76C24F8049; Mon, 28 Oct 2013 12:02:51 -0400 (EDT) Received: from PWN401EA105.ent.corp.bcbsm.com (10.64.102.241) by PWN401EA100.ent.corp.bcbsm.com (10.64.80.217) with Microsoft SMTP Server (TLS) id 14.1.438.0; Mon, 28 Oct 2013 12:13:14 -0400 Received: from PWN401EA160.ent.corp.bcbsm.com ([fe80::fdcb:603d:469e:b1db]) by PWN401EA105.ent.corp.bcbsm.com ([fe80::f13e:83e4:1dae:5345%10]) with mapi id 14.01.0438.000; Mon, 28 Oct 2013 12:13:13 -0400 From: "Ackermann, Michael" To: Ray Hunter Thread-Topic: [v6ops] Fw: New Version Notification for draft-elkins-6man-ipv6-pdm-dest-option-04.txt Thread-Index: AQHO0OGzc1wNgnhly0SIwwwBJHHHZZoEfl4ggAF03YCABFViAA== Date: Mon, 28 Oct 2013 16:13:13 +0000 Message-ID: <4FC37E442D05A748896589E468752CAA0CA8B1CD@PWN401EA160.ent.corp.bcbsm.com> References: <20131017032024.5051.20799.idtracker@ietfa.amsl.com> <1381980305.36254.YahooMailNeo@web2803.biz.mail.ne1.yahoo.com> <5263C783.1080001@globis.net> <1382396300.22968.YahooMailNeo@web2801.biz.mail.ne1.yahoo.com> <526616C4.40304@globis.net> <4FC37E442D05A748896589E468752CAA0CA88734@PWN401EA160.ent.corp.bcbsm.com> <52695E3A.9090406@globis.net> <4FC37E442D05A748896589E468752CAA0CA8A36F@PWN401EA160.ent.corp.bcbsm.com> <526AAC81.3050402@globis.net> In-Reply-To: <526AAC81.3050402@globis.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.64.10.35] x-tm-as-product-ver: SMEX-10.2.0.1135-7.000.1014-20254.000 x-tm-as-result: No--39.910400-8.000000-31 x-tm-as-user-approved-sender: No x-tm-as-user-blocked-sender: No Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: v6ops WG , 6man WG , "ippm@ietf.org" Subject: Re: [v6ops] Fw: New Version Notification for draft-elkins-6man-ipv6-pdm-dest-option-04.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 28 Oct 2013 16:13:24 -0000 Hey Ray It appears your experiences with Time Synch and Stratum levels are = different than mine. In the older Telecom and Voice World Stratum was a = great indicator of clocking accuracy. Still is as far as I know. This = was always true with or without NTP in the picture. =20 And whenever we had two Stratum 0's or 1's, be they the same or different = masters, they WOULD be in synch. We never had a situation that was an = exception to that, with or without NTP. =20 Thanks Mike -----Original Message----- From: Ray Hunter =5Bmailto:v6ops=40globis.net=5D=20 Sent: Friday, October 25, 2013 1:38 PM To: Ackermann, Michael Cc: Nalini Elkins; v6ops WG; 6man WG; ippm=40ietf.org; = bill.jouris=40insidethestack.com; keven.haining=40usbank.com Subject: Re: =5Bv6ops=5D Fw: New Version Notification for = draft-elkins-6man-ipv6-pdm-dest-option-04.txt > Ackermann, Michael > 25 October 2013 01:44 > Ray > > Your Comment:=20 > No. I think what I said was that the level of certainty in your = measurements is dependent on the level of synchronisation of the 2 clock = sources if you are calculating a delta of timestamp of clock 1 - timestamp = clock 2. > My Response: > Then it sounds like we are in agreement. Given the appropriate stratum = level at both nodes, the desired level of time synchronization is = achieved.=20 > No. We are not in agreement. Stratum is an indication of how far down you are in the hierarchy from any = NTP Stratum 0 clock. It says nothing about whether your stratum 0 and my stratum 0 are = synchronised. We could both be running caesium clocks, and there could still be an = offset if I don't set my reference time of my caesium clock the same as = your reference time. When talking about microsecond or picosecond timing = that will almost certainly be significant. You really need to know that the true provenance of the clock source is = identical in order to make PDM 1 calculations, not just the stratum. Hence my comment to couple some sort of =22clock ID=22 to the timestamp. > Your Comment:=20 > I think it might be instructive to go back and look at high school = physics books on making measurements, precision, accuracy, and error = estimations, especially when taking the difference of two measurements, or = making other calculations on top of raw observations > My Response: Not sure exactly what this means but I can say that this = sounds like theoretical doubt that time synchronization will not work = properly in geographically dispersed environments? I can tell you that = it does in our experiences and that the surrounding = protocols/implementations are crafted to account for such vicissitudes. =20 > I will say that I have no field experience with DCF-77 sources, only GPS = and Cesium. =20 > > > Your Comment: > Equally a stratum 0 clock can be free running if it loses it's radio = signal. > My Response:=20 > This comment sort of confused me as well, but suffice to say, if any = component is broken, results will be impaired. Obviously this is not = limited to the time synch subject. =20 > > > Finally, your comment about =22Middleboxes=22. I hope it can be as = simple to accommodate as you describe. My concern is that if there are = numerous middleboxes, the fields may get repetitively overlaid, or there = will need to be so many separate fields, we could incur excessive = complexity or overhead. Given that we can accomplish this with a = workable solution, I am certainly all for it. =20 > The more information I can have to manage networks and solve problems, = the better=21 > > Thanks again for your thoughts, inputs and questions=21 > > Mike > > > > > > > > > > > The information contained in this communication is highly confidential and = is intended solely for the use of the individual(s) to whom this = communication is directed. If you are not the intended recipient, you are = hereby notified that any viewing, copying, disclosure or distribution of = this information is prohibited. Please notify the sender, by electronic = mail or telephone, of any unintended receipt and delete the original = message without making any copies. =20 Blue Cross Blue Shield of Michigan and Blue Care Network of Michigan are = nonprofit corporations and independent licensees of the Blue Cross and = Blue Shield Association. From brian@innovationslab.net Mon Oct 28 09:24:19 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 69EA521F9F08; Mon, 28 Oct 2013 09:24:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.562 X-Spam-Level: X-Spam-Status: No, score=-102.562 tagged_above=-999 required=5 tests=[AWL=0.038, 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 uJT9wXzC8fBb; Mon, 28 Oct 2013 09:24:13 -0700 (PDT) Received: from uillean.fuaim.com (uillean.fuaim.com [206.197.161.140]) by ietfa.amsl.com (Postfix) with ESMTP id EC8F421F9FE9; Mon, 28 Oct 2013 09:24:12 -0700 (PDT) Received: from clairseach.fuaim.com (clairseach-high.fuaim.com [206.197.161.158]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by uillean.fuaim.com (Postfix) with ESMTP id 6B2A6880A4; Mon, 28 Oct 2013 09:24:12 -0700 (PDT) Received: from 102527254.rudm1.ra.johnshopkins.edu (addr16212925014.ippl.jhmi.edu [162.129.250.14]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by clairseach.fuaim.com (Postfix) with ESMTP id D1EE3130003; Mon, 28 Oct 2013 09:24:11 -0700 (PDT) Message-ID: <526E8FA3.70506@innovationslab.net> Date: Mon, 28 Oct 2013 12:24:03 -0400 From: Brian Haberman User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:24.0) Gecko/20100101 Thunderbird/24.0.1 MIME-Version: 1.0 To: "Ackermann, Michael" , Ray Hunter References: <20131017032024.5051.20799.idtracker@ietfa.amsl.com> <1381980305.36254.YahooMailNeo@web2803.biz.mail.ne1.yahoo.com> <5263C783.1080001@globis.net> <1382396300.22968.YahooMailNeo@web2801.biz.mail.ne1.yahoo.com> <526616C4.40304@globis.net> <4FC37E442D05A748896589E468752CAA0CA88734@PWN401EA160.ent.corp.bcbsm.com> <52695E3A.9090406@globis.net> <4FC37E442D05A748896589E468752CAA0CA8A36F@PWN401EA160.ent.corp.bcbsm.com> <526AAC81.3050402@globis.net> <4FC37E442D05A748896589E468752CAA0CA8B1CD@PWN401EA160.ent.corp.bcbsm.com> In-Reply-To: <4FC37E442D05A748896589E468752CAA0CA8B1CD@PWN401EA160.ent.corp.bcbsm.com> X-Enigmail-Version: 1.6 Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="LXMC8R1hVTxIoGgRMCMvKvREBwr3bvGvq" Cc: v6ops WG , 6man WG , "ippm@ietf.org" Subject: Re: [v6ops] Fw: New Version Notification for draft-elkins-6man-ipv6-pdm-dest-option-04.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 28 Oct 2013 16:24:19 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --LXMC8R1hVTxIoGgRMCMvKvREBwr3bvGvq Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Hi Michael. On 10/28/13 12:13 PM, Ackermann, Michael wrote: > Hey Ray >=20 > It appears your experiences with Time Synch and Stratum levels are > different than mine. In the older Telecom and Voice World Stratum > was a great indicator of clocking accuracy. Still is as far as I > know. This was always true with or without NTP in the picture. And > whenever we had two Stratum 0's or 1's, be they the same or different > masters, they WOULD be in synch. We never had a situation that was > an exception to that, with or without NTP. The NTP definition of stratum is different from that used in the telecommunications domain. The primary feature of a NTP stratum 0 clock is the ability to generate accurate pulse per second signals, hence calling them reference clocks. It should be noted that in NTP, stratum 0 clocks are *not* NTP servers, they are the source of time information to stratum 1 servers that serve time via NTP. Regards, Brian --LXMC8R1hVTxIoGgRMCMvKvREBwr3bvGvq Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG/MacGPG2 v2.0.20 (Darwin) Comment: GPGTools - https://gpgtools.org iQEcBAEBCgAGBQJSbo+oAAoJEBOZRqCi7goqJT8IANGmjK6dYI7nZ/3QdwAVIANj fVHFVQ/XBKDld0ZX37POiLxI8FwfqYYRmEEWeyRRrej2qcHiAyGD+d1YstctL/qw PVIZbBwZSHkZIGp/Sd6PZEm//R3opF8RhV/TFnJL35vEELyfClH0qb70BJaZ9Fxu EBfIoXI4IJB3YS7h+De/lD0VYd4JprdUVj3kbnVOI23UWR7OMUiG4o1nQy0rPkvP ItKZq4BzNUp8fhZovlwOb0GlocyBx1qmXl7Ptiij4SmM0BRBVHNhZ0uoRyyq7C73 PodrP7N68+VVszPfU9Xv5LgVGIE2iTyLQVt5QFdFl6dDfaAEM5N6Q36Cc0IY6f4= =tJLW -----END PGP SIGNATURE----- --LXMC8R1hVTxIoGgRMCMvKvREBwr3bvGvq-- From mackermann@bcbsm.com Mon Oct 28 09:49:54 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6D7A521E80AA for ; Mon, 28 Oct 2013 09:49:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.028 X-Spam-Level: X-Spam-Status: No, score=-6.028 tagged_above=-999 required=5 tests=[AWL=-0.029, BAYES_00=-2.599, J_CHICKENPOX_13=0.6, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5RD9GEvVSrnm for ; Mon, 28 Oct 2013 09:49:54 -0700 (PDT) Received: from mx.z120.zixworks.com (mx.z120.zixworks.com [199.30.235.120]) by ietfa.amsl.com (Postfix) with ESMTP id 2CF9921E80AE for ; Mon, 28 Oct 2013 09:49:27 -0700 (PDT) Received: from vmvpm02.z120.zixworks.com (ZixVPM [127.0.0.1]) by Outbound.z120.zixworks.com (Proprietary) with ESMTP id A552D2FF698 for ; Mon, 28 Oct 2013 11:49:26 -0500 (CDT) Received: from imsva2.bcbsm.com (unknown [12.107.172.81]) by mx.z120.zixworks.com (Proprietary) with SMTP id BAD5230742E; Mon, 28 Oct 2013 11:49:25 -0500 (CDT) Received: from imsva2.bcbsm.com (unknown [127.0.0.1]) by IMSVA80 (Postfix) with ESMTP id C733D2F0049; Mon, 28 Oct 2013 12:38:42 -0400 (EDT) Received: from pwn401ea100.ent.corp.bcbsm.com (unknown [10.64.80.217]) by imsva2.bcbsm.com (Postfix) with ESMTP id BAB912F0043; Mon, 28 Oct 2013 12:38:42 -0400 (EDT) Received: from PWN401EA105.ent.corp.bcbsm.com (10.64.102.241) by PWN401EA100.ent.corp.bcbsm.com (10.64.80.217) with Microsoft SMTP Server (TLS) id 14.1.438.0; Mon, 28 Oct 2013 12:49:24 -0400 Received: from PWN401EA160.ent.corp.bcbsm.com ([fe80::fdcb:603d:469e:b1db]) by PWN401EA105.ent.corp.bcbsm.com ([fe80::f13e:83e4:1dae:5345%10]) with mapi id 14.01.0438.000; Mon, 28 Oct 2013 12:49:23 -0400 From: "Ackermann, Michael" To: Brian Haberman , Ray Hunter Thread-Topic: [v6ops] Fw: New Version Notification for draft-elkins-6man-ipv6-pdm-dest-option-04.txt Thread-Index: AQHO0OGzc1wNgnhly0SIwwwBJHHHZZoEfl4ggAF03YCABFViAIAATOiA///D2ZA= Date: Mon, 28 Oct 2013 16:49:21 +0000 Message-ID: <4FC37E442D05A748896589E468752CAA0CA8B261@PWN401EA160.ent.corp.bcbsm.com> References: <20131017032024.5051.20799.idtracker@ietfa.amsl.com> <1381980305.36254.YahooMailNeo@web2803.biz.mail.ne1.yahoo.com> <5263C783.1080001@globis.net> <1382396300.22968.YahooMailNeo@web2801.biz.mail.ne1.yahoo.com> <526616C4.40304@globis.net> <4FC37E442D05A748896589E468752CAA0CA88734@PWN401EA160.ent.corp.bcbsm.com> <52695E3A.9090406@globis.net> <4FC37E442D05A748896589E468752CAA0CA8A36F@PWN401EA160.ent.corp.bcbsm.com> <526AAC81.3050402@globis.net> <4FC37E442D05A748896589E468752CAA0CA8B1CD@PWN401EA160.ent.corp.bcbsm.com> <526E8FA3.70506@innovationslab.net> In-Reply-To: <526E8FA3.70506@innovationslab.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.64.10.35] x-tm-as-product-ver: SMEX-10.2.0.1135-7.000.1014-20254.000 x-tm-as-result: No--36.829100-8.000000-31 x-tm-as-user-approved-sender: No x-tm-as-user-blocked-sender: No Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: v6ops WG , 6man WG , "ippm@ietf.org" Subject: Re: [v6ops] Fw: New Version Notification for draft-elkins-6man-ipv6-pdm-dest-option-04.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 28 Oct 2013 16:49:54 -0000 Thank you Brian. What you say matches my understanding and experiences -----Original Message----- From: Brian Haberman =5Bmailto:brian=40innovationslab.net=5D=20 Sent: Monday, October 28, 2013 12:24 PM To: Ackermann, Michael; Ray Hunter Cc: v6ops WG; 6man WG; ippm=40ietf.org Subject: Re: =5Bv6ops=5D Fw: New Version Notification for = draft-elkins-6man-ipv6-pdm-dest-option-04.txt Hi Michael. On 10/28/13 12:13 PM, Ackermann, Michael wrote: > Hey Ray >=20 > It appears your experiences with Time Synch and Stratum levels are > different than mine. In the older Telecom and Voice World Stratum > was a great indicator of clocking accuracy. Still is as far as I > know. This was always true with or without NTP in the picture. And > whenever we had two Stratum 0's or 1's, be they the same or different > masters, they WOULD be in synch. We never had a situation that was > an exception to that, with or without NTP. The NTP definition of stratum is different from that used in the = telecommunications domain. The primary feature of a NTP stratum 0 clock = is the ability to generate accurate pulse per second signals, hence = calling them reference clocks. It should be noted that in NTP, stratum 0 clocks are *not* NTP servers, they are the source of time information to = stratum 1 servers that serve time via NTP. Regards, Brian The information contained in this communication is highly confidential and = is intended solely for the use of the individual(s) to whom this = communication is directed. If you are not the intended recipient, you are = hereby notified that any viewing, copying, disclosure or distribution of = this information is prohibited. Please notify the sender, by electronic = mail or telephone, of any unintended receipt and delete the original = message without making any copies. =20 Blue Cross Blue Shield of Michigan and Blue Care Network of Michigan are = nonprofit corporations and independent licensees of the Blue Cross and = Blue Shield Association. From joelja@bogus.com Mon Oct 28 10:07:08 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7E44E21E80BA; Mon, 28 Oct 2013 10:07:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.25 X-Spam-Level: X-Spam-Status: No, score=-102.25 tagged_above=-999 required=5 tests=[AWL=-0.251, BAYES_00=-2.599, J_CHICKENPOX_13=0.6, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7uORJfg7G7hd; Mon, 28 Oct 2013 10:07:02 -0700 (PDT) Received: from nagasaki.bogus.com (nagasaki.bogus.com [IPv6:2001:418:1::81]) by ietfa.amsl.com (Postfix) with ESMTP id D150111E8286; Mon, 28 Oct 2013 10:06:56 -0700 (PDT) Received: from 00698a-hsutim.corp.zynga.com ([199.48.105.4]) (authenticated bits=0) by nagasaki.bogus.com (8.14.4/8.14.4) with ESMTP id r9SH6oA9084644 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Mon, 28 Oct 2013 17:06:51 GMT (envelope-from joelja@bogus.com) Content-Type: multipart/signed; boundary="Apple-Mail=_F0041254-84C3-481F-8877-236BC366790F"; protocol="application/pgp-signature"; micalg=pgp-sha1 Mime-Version: 1.0 (Mac OS X Mail 7.0 \(1816\)) From: joel jaeggli In-Reply-To: <4FC37E442D05A748896589E468752CAA0CA8B261@PWN401EA160.ent.corp.bcbsm.com> Date: Mon, 28 Oct 2013 10:06:44 -0700 Message-Id: <822EAF96-CFCF-4584-B590-08CAFE6AF260@bogus.com> References: <20131017032024.5051.20799.idtracker@ietfa.amsl.com> <1381980305.36254.YahooMailNeo@web2803.biz.mail.ne1.yahoo.com> <5263C783.1080001@globis.net> <1382396300.22968.YahooMailNeo@web2801.biz.mail.ne1.yahoo.com> <526616C4.40304@globis.net> <4FC37E442D05A748896589E468752CAA0CA88734@PWN401EA160.ent.corp.bcbsm.com> <52695E3A.9090406@globis.net> <4FC37E442D05A748896589E468752CAA0CA8A36F@PWN401EA160.ent.corp.bcbsm.com> <526AAC81.3050402@globis.net> <4FC37E442D05A748896589E468752CAA0CA8B1CD@PWN401EA160.ent.corp.bcbsm.com> <526E8FA3.70506@innovationslab.net> <4FC37E442D05A748896589E468752CAA0CA8B261@PWN401EA160.ent.corp.bcbsm.com> To: "Ackermann, Michael" X-Mailer: Apple Mail (2.1816) X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.7 (nagasaki.bogus.com [147.28.0.81]); Mon, 28 Oct 2013 17:06:52 +0000 (UTC) Cc: Ray Hunter , 6man WG , v6ops WG , "ippm@ietf.org" Subject: Re: [v6ops] Fw: New Version Notification for draft-elkins-6man-ipv6-pdm-dest-option-04.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 28 Oct 2013 17:07:09 -0000 --Apple-Mail=_F0041254-84C3-481F-8877-236BC366790F Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 On Oct 28, 2013, at 9:49 AM, Ackermann, Michael = wrote: > Thank you Brian. >=20 > What you say matches my understanding and experiences >=20 Then you should revise your statement accordingly=85 >=20 >=20 > -----Original Message----- > From: Brian Haberman [mailto:brian@innovationslab.net]=20 > Sent: Monday, October 28, 2013 12:24 PM > To: Ackermann, Michael; Ray Hunter > Cc: v6ops WG; 6man WG; ippm@ietf.org > Subject: Re: [v6ops] Fw: New Version Notification for = draft-elkins-6man-ipv6-pdm-dest-option-04.txt >=20 > Hi Michael. >=20 > On 10/28/13 12:13 PM, Ackermann, Michael wrote: >> Hey Ray >>=20 >> It appears your experiences with Time Synch and Stratum levels are >> different than mine. In the older Telecom and Voice World Stratum >> was a great indicator of clocking accuracy. Still is as far as I >> know. This was always true with or without NTP in the picture. And >> whenever we had two Stratum 0's or 1's, be they the same or different >> masters, they WOULD be in synch. We never had a situation that was >> an exception to that, with or without NTP. >=20 > The NTP definition of stratum is different from that used in the = telecommunications domain. The primary feature of a NTP stratum 0 clock = is the ability to generate accurate pulse per second signals, hence = calling them reference clocks. It should be noted that in NTP, stratum > 0 clocks are *not* NTP servers, they are the source of time = information to stratum 1 servers that serve time via NTP. >=20 > Regards, > Brian >=20 >=20 >=20 > The information contained in this communication is highly confidential = and is intended solely for the use of the individual(s) to whom this = communication is directed. If you are not the intended recipient, you = are hereby notified that any viewing, copying, disclosure or = distribution of this information is prohibited. Please notify the = sender, by electronic mail or telephone, of any unintended receipt and = delete the original message without making any copies. >=20 > Blue Cross Blue Shield of Michigan and Blue Care Network of Michigan = are nonprofit corporations and independent licensees of the Blue Cross = and Blue Shield Association. > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops >=20 --Apple-Mail=_F0041254-84C3-481F-8877-236BC366790F Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- Comment: GPGTools - http://gpgtools.org iEYEARECAAYFAlJumaQACgkQ8AA1q7Z/VrKNTwCeKwXEXH3o3mhMn6Nk+j9OFjSy hv8AniJHBe98K8aKQCwTjT/H6QszaUy9 =wjCb -----END PGP SIGNATURE----- --Apple-Mail=_F0041254-84C3-481F-8877-236BC366790F-- From nalini.elkins@insidethestack.com Mon Oct 28 10:18:43 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2AFE811E8293 for ; Mon, 28 Oct 2013 10:18:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.136 X-Spam-Level: X-Spam-Status: No, score=-2.136 tagged_above=-999 required=5 tests=[AWL=-0.138, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_13=0.6] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Z08lIUVmkTV2 for ; Mon, 28 Oct 2013 10:18:38 -0700 (PDT) Received: from nm13-vm7.access.bullet.mail.gq1.yahoo.com (nm13-vm7.access.bullet.mail.gq1.yahoo.com [216.39.63.191]) by ietfa.amsl.com (Postfix) with ESMTP id D5F3311E828D for ; Mon, 28 Oct 2013 10:18:34 -0700 (PDT) Received: from [216.39.60.165] by nm13.access.bullet.mail.gq1.yahoo.com with NNFMP; 28 Oct 2013 17:18:34 -0000 Received: from [216.39.60.232] by tm1.access.bullet.mail.gq1.yahoo.com with NNFMP; 28 Oct 2013 17:18:34 -0000 Received: from [127.0.0.1] by omp1003.access.mail.gq1.yahoo.com with NNFMP; 28 Oct 2013 17:18:34 -0000 X-Yahoo-Newman-Property: ymail-5 X-Yahoo-Newman-Id: 573782.81346.bm@omp1003.access.mail.gq1.yahoo.com Received: (qmail 33934 invoked by uid 60001); 28 Oct 2013 17:18:33 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s1024; t=1382980713; bh=rXSK8sW+3/5tdnyY0Sc8auV9s0yAGCkwsuBtqJmFW/A=; h=X-YMail-OSG:Received:X-Rocket-MIMEInfo:X-Mailer:References:Message-ID:Date:From:Reply-To:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type; b=SM4NOdNvVxNHda879K2Amj/aMc01mozea4IvVNWrqYJ06m/lAM+O57tupP91OFQ0Dr3Hb5/2X5KIhq6qvRKfOlxUXV2TWREjtUov2wCnlcFmMycrTCTH/CoFKiA3/dpyYCLXQCjoK1HSDiKd4CDBqAAMCYvLK4gB+EYA/AePKqA= X-YMail-OSG: USF1x1wVM1lqW_gBckIC_LJIXQA4iP2lj3vtUpC5f.TD5Cv WGZYTTSFbmhu_ifAK2fO6IR3gclr8ESV4X05Z5JsRCOyKYswGVAFJprWvEVo PDZaqsftfM9V_Bf.tN8HDOok51CkgqkpX3WuNC5ENZck3VxRpTBiTEeKaN3I d0fxvLK9nR9nJ6SWrBX.SXbSkudpu63hG3nQTVnoP5IxOot5aIsz_TrOPGJ. qdDES5Qkf1F0qE2vw6mQEnsESYo0wtmPqsfmMRsZNaXArY3S4sxTC.dqN6xw CoAL4.8ERCXWflpMQ2Imd3c.agkJQDbrrh0qL31ARHcCXoqOs0DxZybDNJEH NJjZD3FN1wFGKv_fnicu9XfKI2Nab_QV7mN45QRXMKACed0DmXzDK8azfArw y7oUYFs36TYzJbslMFwgvKY7CN_oMEK_L.YfC2.KQS0BvS2fYmOYTYLMpeba 0HFiy9baTLNqcxxpOIeJ8IDksfpYnfR8RqVqIlrbRlJ0ZWdAMQWchs6bjFdj qiLhKZ2R_020HnmmnM5TjE0qVpFprMhG1v9AZYkQl95qdkfKYI2ybgHywSNF 9PApXtRRXTXIjuRJ3sGYYYPN0Mf02RKDPcH3U3_WgvA7bQGZzN5MlNvtQsaF ed5gThAd35Dql2blZvUu0W0slHsMkgUB04G_59f_swTr7iLyeF0ikiv_3ivh lX8iN Received: from [24.130.37.147] by web2805.biz.mail.ne1.yahoo.com via HTTP; Mon, 28 Oct 2013 10:18:33 PDT X-Rocket-MIMEInfo: 002.001, Sm9hY2hpbSwKwqAKVGhhbmtzIHZlcnkgbXVjaC4gwqBXZSB3aWxsIHRha2UgYSBsb29rIGFuZCByZXZpc2UgdGhlIGRyYWZ0cyBhY2NvcmRpbmdseS4KCk5hbGluaSBFbGtpbnMKSW5zaWRlIFByb2R1Y3RzLCBJbmMuCig4MzEpIDY1OS04MzYwCnd3dy5pbnNpZGV0aGVzdGFjay5jb20KCgoKX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18KIEZyb206IEpvYWNoaW0gRmFiaW5pIDxKb2FjaGltLkZhYmluaUB0dXdpZW4uYWMuYXQ.ClRvOiAiQWNrZXJtYW5uLCBNaWNoYWVsIiA8TUFja2VybWFubkBiY2IBMAEBAQE- X-Mailer: YahooMailWebService/0.8.160.587 References: <20131017032024.5051.20799.idtracker@ietfa.amsl.com> <1381980305.36254.YahooMailNeo@web2803.biz.mail.ne1.yahoo.com> <5263C783.1080001@globis.net> <1382396300.22968.YahooMailNeo@web2801.biz.mail.ne1.yahoo.com> <526616C4.40304@globis.net> <4FC37E442D05A748896589E468752CAA0CA88734@PWN401EA160.ent.corp.bcbsm.com> <52695E3A.9090406@globis.net> <4FC37E442D05A748896589E468752CAA0CA8A36F@PWN401EA160.ent.corp.bcbsm.com> <526AAC81.3050402@globis.net> <4FC37E442D05A748896589E468752CAA0CA8B1CD@PWN401EA160.ent.corp.bcbsm.com> <526E936D.1000404@tuwien.ac.at> Message-ID: <1382980713.24463.YahooMailNeo@web2805.biz.mail.ne1.yahoo.com> Date: Mon, 28 Oct 2013 10:18:33 -0700 (PDT) From: Nalini Elkins To: Joachim Fabini , "Ackermann, Michael" , Ray Hunter In-Reply-To: <526E936D.1000404@tuwien.ac.at> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="1619178251-1261008546-1382980713=:24463" Cc: v6ops WG , 6man WG , "ippm@ietf.org" Subject: Re: [v6ops] [ippm] Fw: New Version Notification for draft-elkins-6man-ipv6-pdm-dest-option-04.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: Nalini Elkins List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 28 Oct 2013 17:18:43 -0000 --1619178251-1261008546-1382980713=:24463 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Joachim,=0A=A0=0AThanks very much. =A0We will take a look and revise the dr= afts accordingly.=0A=0ANalini Elkins=0AInside Products, Inc.=0A(831) 659-83= 60=0Awww.insidethestack.com=0A=0A=0A=0A________________________________=0A = From: Joachim Fabini =0ATo: "Ackermann, Michae= l" ; Ray Hunter =0ACc: v6ops WG ; 6man WG ; "bill.jouris@insidethestack.com" <= bill.jouris@insidethestack.com>; "ippm@ietf.org" =0ASent: M= onday, October 28, 2013 9:40 AM=0ASubject: Re: [ippm] [v6ops] Fw: New Versi= on Notification for draft-elkins-6man-ipv6-pdm-dest-option-04.txt=0A =0A=0A= Mike, Nalini,=0A=0Aplease have a look at http://tools.ietf.org/html/rfc2330= #section-10 =0Aand/or http://tools.ietf.org/html/rfc5905 for a detailed tec= hnical =0Adiscussion on time issues/NTP. With respect to these parameters, = the =0Aterm "in sync" which you use is _purely_ theoretical and must be =0A= consolidated to a technical specification in terms of RFC2330 clock =0Apara= meters (accuracy, resolution, etc.) to be usable in practice. I =0Athink th= is is what Ray meant. Stratum per se (in the NTP sense) is imho =0Amisleadi= ng/useless as a quality indicator.=0A=0Aregards=0AJoachim=0A=0A=0AAm 28.10.= 2013 17:13, schrieb Ackermann, Michael:=0A> Hey Ray=0A>=0A> It appears your= experiences with Time Synch and Stratum levels are different than mine.=A0= In the older Telecom and Voice World Stratum was a great indicator of clo= cking accuracy.=A0 Still is as far as I know.=A0 This was always true wit= h or without NTP in the picture.=0A> And whenever we had two Stratum 0's or= 1's, be they the same or different masters, they WOULD be in synch.=A0 We= never had a situation that was an exception to that, with or without NTP.= =0A>=0A> Thanks=0A>=0A> Mike=0A>=0A>=0A> -----Original Message-----=0A> Fro= m: Ray Hunter [mailto:v6ops@globis.net]=0A> Sent: Friday, October 25, 2013 = 1:38 PM=0A> To: Ackermann, Michael=0A> Cc: Nalini Elkins; v6ops WG; 6man WG= ; ippm@ietf.org; bill.jouris@insidethestack.com; keven.haining@usbank.com= =0A> Subject: Re: [v6ops] Fw: New Version Notification for draft-elkins-6ma= n-ipv6-pdm-dest-option-04.txt=0A>=0A>> Ackermann, Michael =0A>> 25 October 2013 01:44=0A>> Ray=0A>>=0A>> Your Comment:=0A= >> No. I think what I said was that the level of certainty in your measurem= ents is dependent on the level of synchronisation of the 2 clock sources if= you are calculating a delta of timestamp of clock 1 - timestamp clock 2.= =0A>> My Response:=0A>> Then it sounds like we are in agreement.=A0 Given = the appropriate stratum level at both nodes, the desired level of time sync= hronization is achieved.=0A>>=0A> No. We are not in agreement.=0A>=0A> Stra= tum is an indication of how far down you are in the hierarchy from any NTP = Stratum 0 clock.=0A>=0A> It says nothing about whether your stratum 0 and m= y stratum 0 are synchronised.=0A>=0A> We could both be running caesium cloc= ks, and there could still be an offset if I don't set my reference time of = my caesium clock the same as your reference time. When talking about micros= econd or picosecond timing that will almost certainly be significant.=0A>= =0A> You really need to know that the true provenance of the clock source i= s identical in order to make PDM 1 calculations, not just the stratum.=0A>= =0A> Hence my comment to couple some sort of "clock ID" to the timestamp.= =0A>> Your Comment:=0A>> I think it might be instructive to go back and loo= k at high school physics books on making measurements, precision, accuracy,= and error estimations, especially when taking the difference of two measur= ements, or making other calculations on top of raw observations=0A>> My Res= ponse:=A0 Not sure exactly what this means but I can say that this sounds l= ike theoretical doubt that time synchronization will not work properly in g= eographically dispersed environments?=A0 =A0 I can tell you that it does in= our experiences and that the surrounding protocols/implementations are cra= fted to account for such vicissitudes.=0A>> I will say that I have no field= experience with DCF-77 sources, only GPS and Cesium.=0A>>=0A>>=0A>> Your C= omment:=0A>> Equally a stratum 0 clock can be free running if it loses it's= radio signal.=0A>> My Response:=0A>> This comment sort of confused me as w= ell, but suffice to say, if any component is broken, results will be impair= ed.=A0 Obviously this is not limited to the time synch subject.=0A>>=0A>>= =0A>> Finally, your comment about "Middleboxes".=A0 =A0 I hope it can be as= simple to accommodate as you describe.=A0 My concern is that if there are= numerous middleboxes, the fields may get repetitively overlaid, or there w= ill need to be so many separate fields, we could incur excessive complexity= or overhead.=A0 =A0 Given that we can accomplish this with a workable solu= tion, I am certainly all for it.=0A>> The more information I can have to ma= nage networks and solve problems, the better!=0A>>=0A>> Thanks again for yo= ur thoughts, inputs and questions!=0A>>=0A>> Mike=0A>>=0A>>=0A>>=0A>>=0A>>= =0A>>=0A>>=0A>>=0A>>=0A>>=0A>>=0A>=0A>=0A>=0A> The information contained in= this communication is highly confidential and is intended solely for the u= se of the individual(s) to whom this communication is directed. If you are = not the intended recipient, you are hereby notified that any viewing, copyi= ng, disclosure or distribution of this information is prohibited. Please no= tify the sender, by electronic mail or telephone, of any unintended receipt= and delete the original message without making any copies.=0A>=0A>=A0 Blu= e Cross Blue Shield of Michigan and Blue Care Network of Michigan are nonpr= ofit corporations and independent licensees of the Blue Cross and Blue Shie= ld Association.=0A> _______________________________________________=0A> ipp= m mailing list=0A> ippm@ietf.org=0A> https://www.ietf.org/mailman/listinfo/= ippm=0A>=0A_______________________________________________=0Aippm mailing l= ist=0Aippm@ietf.org=0Ahttps://www.ietf.org/mailman/listinfo/ippm --1619178251-1261008546-1382980713=:24463 Content-Type: text/html; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable
Joachim,
=
 
Thanks very much.  We will take a loo= k and revise the drafts accordingly.

Nalini Elkins=
Inside Products, Inc.
(831) 659-8360
www.insidethestack.com

From: J= oachim Fabini <Joachim.Fabini@tuwien.ac.at>
To: "Ackermann, Michael" <MAckermann@bcbsm.c= om>; Ray Hunter <v6ops@globis.net>
Cc: v6ops WG <v6ops@ietf.org>; 6man WG <ipv6@ietf.org>; "bill.jouris@insidethestack.com" <bill.jouris@in= sidethestack.com>; "ippm@ietf.org" <ippm@ietf.org>
Sent: Monday, October 28, 2013 9:40 = AM
Subject: Re: [ippm]= [v6ops] Fw: New Version Notification for draft-elkins-6man-ipv6-pdm-dest-o= ption-04.txt

=0AMike,= Nalini,

please have a look at http://tools.ietf.org/html/rfc2330#se= ction-10
and/or http://tools.ietf.org/html/rfc5905 for a detailed techn= ical
discussion on time issues/NTP. With respect to these parameters, t= he
term "in sync" which you use is _purely_ theoretical and must be consolidated to a technical specification in terms of RFC2330 clock
pa= rameters (accuracy, resolution, etc.) to be usable in practice. I
think= this is what Ray meant. Stratum per se (in the NTP sense) is imho
misl= eading/useless as a quality indicator.

regards
Joachim

Am 28.10.2013 17:13, schrieb Ackermann, Michael:
> Hey Ray
>> It appears your experiences with Time Synch and Stratum levels are d= ifferent than mine.  In the older Telecom and Voice World Stratum was= a great indicator of clocking accuracy.  Still is as far as I know.&= nbsp; This was always true with or without NTP in the picture.
> And whenever we had two Stratum 0's or 1's, be they the s= ame or different masters, they WOULD be in synch.  We never had a sit= uation that was an exception to that, with or without NTP.
>
> = Thanks
>
> Mike
>
>
> -----Original Message--= ---
> From: Ray Hunter [mailto:v6ops@globis.net]
> Sent: Frida= y, October 25, 2013 1:38 PM
> To: Ackermann, Michael
> Cc: Nali= ni Elkins; v6ops WG; 6man WG; ippm@ietf.org; bill.jouri= s@insidethestack.com; keven.haining@usbank.com
>= Subject: Re: [v6ops] Fw: New Version Notification for draft-elkins-6man-ipv6-pdm-dest-option-04.txt
>
>> Ackerman= n, Michael <mailto:MAckermann@bcbsm.com>
>> 25 Octo= ber 2013 01:44
>> Ray
>>
>> Your Comment:
>= ;> No. I think what I said was that the level of certainty in your measu= rements is dependent on the level of synchronisation of the 2 clock sources= if you are calculating a delta of timestamp of clock 1 - timestamp clock 2= .
>> My Response:
>> Then it sounds like we are in agreem= ent.  Given the appropriate stratum level at both nodes, the desired = level of time synchronization is achieved.
>>
> No. We are n= ot in agreement.
>
> Stratum is an indication of how far down y= ou are in the hierarchy from any NTP Stratum 0 clock.
>
> It sa= ys nothing about whether your stratum 0 and my stratum 0 are synchronised.
>
> We could both be running caesium clocks, and= there could still be an offset if I don't set my reference time of my caes= ium clock the same as your reference time. When talking about microsecond o= r picosecond timing that will almost certainly be significant.
>
&= gt; You really need to know that the true provenance of the clock source is= identical in order to make PDM 1 calculations, not just the stratum.
&g= t;
> Hence my comment to couple some sort of "clock ID" to the timest= amp.
>> Your Comment:
>> I think it might be instructive = to go back and look at high school physics books on making measurements, pr= ecision, accuracy, and error estimations, especially when taking the differ= ence of two measurements, or making other calculations on top of raw observ= ations
>> My Response:  Not sure exactly what this means but = I can say that this sounds like theoretical doubt that time synchronization will not work properly in geographically dispersed environ= ments?    I can tell you that it does in our experiences and that= the surrounding protocols/implementations are crafted to account for such = vicissitudes.
>> I will say that I have no field experience with D= CF-77 sources, only GPS and Cesium.
>>
>>
>> You= r Comment:
>> Equally a stratum 0 clock can be free running if it = loses it's radio signal.
>> My Response:
>> This comment = sort of confused me as well, but suffice to say, if any component is broken= , results will be impaired.  Obviously this is not limited to the tim= e synch subject.
>>
>>
>> Finally, your comment = about "Middleboxes".    I hope it can be as simple to accommodate= as you describe.  My concern is that if there are numerous middlebox= es, the fields may get repetitively overlaid, or there will need to be so many separate fields, we could incur excessive complexity or overhea= d.    Given that we can accomplish this with a workable solution,= I am certainly all for it.
>> The more information I can have to = manage networks and solve problems, the better!
>>
>> Tha= nks again for your thoughts, inputs and questions!
>>
>> = Mike
>>
>>
>>
>>
>>
>>= ;
>>
>>
>>
>>
>>
>
&g= t;
>
> The information contained in this communication is highl= y confidential and is intended solely for the use of the individual(s) to w= hom this communication is directed. If you are not the intended recipient, = you are hereby notified that any viewing, copying, disclosure or distributi= on of this information is prohibited. Please notify the sender, by electron= ic mail or telephone, of any unintended receipt and delete the original message without making any copies.
>
>  Blue Cr= oss Blue Shield of Michigan and Blue Care Network of Michigan are nonprofit= corporations and independent licensees of the Blue Cross and Blue Shield A= ssociation.
> _______________________________________________
>= ippm mailing list
> ippm@ietf.org
> https://www.ietf.org/mailman/list= info/ippm
>
_______________________________________________ippm mailing list
ippm@ietf.org
https://www.ietf.org/mailman/listinfo/ippm<= /a>


--1619178251-1261008546-1382980713=:24463-- From Ted.Lemon@nominum.com Mon Oct 28 10:40:13 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 09CB421F9CC5 for ; Mon, 28 Oct 2013 10:40:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.589 X-Spam-Level: X-Spam-Status: No, score=-106.589 tagged_above=-999 required=5 tests=[AWL=0.010, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sU04VcgbPtya for ; Mon, 28 Oct 2013 10:40:06 -0700 (PDT) Received: from exprod7og127.obsmtp.com (exprod7og127.obsmtp.com [64.18.2.210]) by ietfa.amsl.com (Postfix) with ESMTP id 37FB021F9D7C for ; Mon, 28 Oct 2013 10:40:00 -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 DSNKUm6hb1yfhR12o+v/cQUBjDtelkqayuOu@postini.com; Mon, 28 Oct 2013 10:40:00 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 BF1F61B82E0 for ; Mon, 28 Oct 2013 10:39:59 -0700 (PDT) Received: from webmail.nominum.com (cas-02.win.nominum.com [64.89.228.132]) (using TLSv1 with cipher RC4-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 9C2B0190060; Mon, 28 Oct 2013 10:39: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.03.0158.001; Mon, 28 Oct 2013 10:39:59 -0700 From: Ted Lemon To: james woodyatt Thread-Topic: [v6ops] DHCPv6/SLAAC Make Hosts Confusing-//RE: new draft: draft-liu-bonica-v6ops-dhcpv6-slaac-problem Thread-Index: AQHO0IQ5zlc2OKux70a0Yodils1+5poKvxgAgAAeqQA= Date: Mon, 28 Oct 2013 17:39:59 +0000 Message-ID: <73493F7B-5284-4EC8-8F72-922C68AE6FA3@nominum.com> References: <52689EE0.3030201@inex.ie> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [192.168.1.10] Content-Type: text/plain; charset="Windows-1252" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: V6OPS Working Group Subject: Re: [v6ops] DHCPv6/SLAAC Make Hosts Confusing-//RE: new draft: draft-liu-bonica-v6ops-dhcpv6-slaac-problem X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 28 Oct 2013 17:40:13 -0000 On Oct 28, 2013, at 11:50 AM, james woodyatt wrote: > I prefer this way out. I've said this before, but now seems like a good = time to say it again: stateless DHCPv6 has a lifetime of information proble= m, and I think RFC 3736 should be sent to pasture. >=20 > p1. If there are information objects that must be individually and separa= tely configured at each host by the network, then stateful DHCPv6 [RFC 3315= ] is the protocol for doing that. It sounds like you are saying that devices that need per-device configurati= on must use stateful address allocation. That's an odd position to take, = so I just want to make sure: is that what you intended to say? FWIW, RFC 3736 was updated eight years ago with RFC 4242, which provides an= information refresh timer. If you aren't currently implementing that, yo= u should. Unfortunately the working group didn't think to actually say th= at 4242 updates 3736, so I'm not surprised if it's not on peoples' radar. From jhw@conjury.org Mon Oct 28 10:45:09 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 60C7911E822E for ; Mon, 28 Oct 2013 10:45:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.001, 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 V149FWwrpDm4 for ; Mon, 28 Oct 2013 10:45:08 -0700 (PDT) Received: from prime.conjury.org (prime.conjury.org [IPv6:2607:f2f8:a938::2]) by ietfa.amsl.com (Postfix) with ESMTP id 2C46411E819B for ; Mon, 28 Oct 2013 10:45:08 -0700 (PDT) Received: from [10.0.1.2] (moon.conjury.org [50.0.204.61]) by prime.conjury.org (Postfix) with ESMTPSA id CCD08AEB8F; Mon, 28 Oct 2013 10:48:56 -0700 (PDT) Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 7.0 \(1816\)) From: james woodyatt In-Reply-To: <73493F7B-5284-4EC8-8F72-922C68AE6FA3@nominum.com> Date: Mon, 28 Oct 2013 10:45:05 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: References: <52689EE0.3030201@inex.ie> <73493F7B-5284-4EC8-8F72-922C68AE6FA3@nominum.com> To: Ted Lemon X-Mailer: Apple Mail (2.1816) Cc: V6OPS Working Group Subject: Re: [v6ops] DHCPv6/SLAAC Make Hosts Confusing-//RE: new draft: draft-liu-bonica-v6ops-dhcpv6-slaac-problem X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 28 Oct 2013 17:45:09 -0000 On Oct 28, 2013, at 10:39 , Ted Lemon wrote: > On Oct 28, 2013, at 11:50 AM, james woodyatt wrote: >> I prefer this way out. I've said this before, but now seems like a = good time to say it again: stateless DHCPv6 has a lifetime of = information problem, and I think RFC 3736 should be sent to pasture. >>=20 >> p1. If there are information objects that must be individually and = separately configured at each host by the network, then stateful DHCPv6 = [RFC 3315] is the protocol for doing that. >=20 > It sounds like you are saying that devices that need per-device = configuration must use stateful address allocation. That's an odd = position to take, so I just want to make sure: is that what you intended = to say? Is stateful address allocation required? I didn't think that was the = case. It seems perfectly reasonable to me that routers can advertise = M=3D0 and O=3D1, and hosts can then proceed to use RFC 3315 stateful = DHCPv6 to obtain things like their OpenDirectory service parameters. = Isn't that what the DUID mechanism is supposed to be about? Decoupling = the address allocation from the host identifier? > FWIW, RFC 3736 was updated eight years ago with RFC 4242, which = provides an information refresh timer. If you aren't currently = implementing that, you should. Unfortunately the working group didn't = think to actually say that 4242 updates 3736, so I'm not surprised if = it's not on peoples' radar. That's a problem. I'm not sure how much uptake RFC 4242 has gotten. --james woodyatt From lorenzo@google.com Mon Oct 28 10:46:10 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0CA2F11E819B for ; Mon, 28 Oct 2013 10:46:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.914 X-Spam-Level: X-Spam-Status: No, score=-1.914 tagged_above=-999 required=5 tests=[AWL=0.063, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, 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 OxZV7yLBB1Pz for ; Mon, 28 Oct 2013 10:46:09 -0700 (PDT) Received: from mail-ie0-x233.google.com (mail-ie0-x233.google.com [IPv6:2607:f8b0:4001:c03::233]) by ietfa.amsl.com (Postfix) with ESMTP id 4999A11E81A5 for ; Mon, 28 Oct 2013 10:46:07 -0700 (PDT) Received: by mail-ie0-f179.google.com with SMTP id aq17so11569268iec.24 for ; Mon, 28 Oct 2013 10:46:06 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=DwvrmF4bXlK0bpJnTwnT977sli1eYMkNHt5+cpr5HIA=; b=BHsaEet2a0xAdSuzb5hJGSuLRuwKDBxjNgWlMzvl/tF6uPfKrxG0MjOVRbV5vwg0iQ e9D4kTi4MH7VU8In5NcobiR6igiC0JbdR29UNWHLsyGj8L35uNa5VegvIPoRwV3dcdGl G8bjUHofzCMHrIGSx6N+Z871PHZxLbDWCn7MWLoofhVk+hppFiElNMzH4o1dqJlZMdz7 wr9Lkc6YHMKlO9RQd6z14YMhFDZIQQ45tIkqAZx8JtvhtmzACAuSIWvSaxD3NiYJAkL8 GfBIgrVWHGbZKf6h5cziNwRVfgYNbXSKhnQAZxdPZnhf0Xt4D57YveulXUAU3hIavPjq DrHw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type; bh=DwvrmF4bXlK0bpJnTwnT977sli1eYMkNHt5+cpr5HIA=; b=R3b1+THowXCf1gxAOZgMT6VTTPnnHuDJjT5tfnyUvkCxOVPv2qnpZuz0rLQESLBmuw hmH+EJjiEKRRfNWyjNchXwXVpxT6kViiWLQ+yIGOCGfmsSnlOETPFSvGVDboedX1HN60 cgy15SuukFYcPRpx5V9Op9feIdL7F39kUB3oFPWqQXK/UlAFu1HKFqPK8iAGJHwSV1uJ yudk4lGvQPzDn3U+5n7tfXCn5XE0mWlYQ577NOihhTrFFDEDb2IxfzUVxUUYdCAi5NFC e6YYk+OTMveoAxAj/6JVN+EAeASspZGUBCVFGHn9FUBB56wZsfxegGln+M4ztFAY0YgB Um6A== X-Gm-Message-State: ALoCoQm3SH1bICoed8GNBqiNaRE0uyYW1gDRTSlGUYEBFwh3Js+en1yXBWJzQltoazC4Id0kYnuGnr+qKyk+2WpLoXXksIoa2tWhjJJYsZ+1WvBglSkwg8vMQdsjxOM10wWPmiYpkxt2gPIoHJbZz2X5oAGM9dHN+jTN0zV0zm7nV76WL+WD35dFMt6LpGpdles8ZmqB5qD1 X-Received: by 10.43.159.5 with SMTP id lw5mr14319362icc.22.1382982366638; Mon, 28 Oct 2013 10:46:06 -0700 (PDT) MIME-Version: 1.0 Received: by 10.64.86.106 with HTTP; Mon, 28 Oct 2013 10:45:45 -0700 (PDT) In-Reply-To: <73493F7B-5284-4EC8-8F72-922C68AE6FA3@nominum.com> References: <52689EE0.3030201@inex.ie> <73493F7B-5284-4EC8-8F72-922C68AE6FA3@nominum.com> From: Lorenzo Colitti Date: Tue, 29 Oct 2013 02:45:45 +0900 Message-ID: To: Ted Lemon Content-Type: multipart/alternative; boundary=001a11c1feb6b1d56f04e9d0ac00 Cc: V6OPS Working Group Subject: Re: [v6ops] DHCPv6/SLAAC Make Hosts Confusing-//RE: new draft: draft-liu-bonica-v6ops-dhcpv6-slaac-problem X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 28 Oct 2013 17:46:10 -0000 --001a11c1feb6b1d56f04e9d0ac00 Content-Type: text/plain; charset=ISO-8859-1 On Tue, Oct 29, 2013 at 2:39 AM, Ted Lemon wrote: > FWIW, RFC 3736 was updated eight years ago with RFC 4242, which provides > an information refresh timer. If you aren't currently implementing that, > you should. Unfortunately the working group didn't think to actually say > that 4242 updates 3736, so I'm not surprised if it's not on peoples' radar. > With a minimum of 10 minutes, unfortunately. --001a11c1feb6b1d56f04e9d0ac00 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
On Tue, Oct 29, 2013 at 2:39 AM, Ted Lemon <Ted.Lemon= @nominum.com> wrote:
FWIW, RFC 3736 was updated eight years ago with RFC 4242, which p= rovides an information refresh timer. =A0 If you aren't currently imple= menting that, you should. =A0 Unfortunately the working group didn't th= ink to actually say that 4242 updates 3736, so I'm not surprised if it&= #39;s not on peoples' radar.

=A0With a minimum of 10 minutes, unfortuna= tely.
--001a11c1feb6b1d56f04e9d0ac00-- From ayourtch@cisco.com Mon Oct 28 12:17:46 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D6FD611E80E7 for ; Mon, 28 Oct 2013 12:17:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[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 f9SqnYZe4v8v for ; Mon, 28 Oct 2013 12:17:36 -0700 (PDT) Received: from rcdn-iport-2.cisco.com (rcdn-iport-2.cisco.com [173.37.86.73]) by ietfa.amsl.com (Postfix) with ESMTP id 80AD511E81C8 for ; Mon, 28 Oct 2013 12:17:35 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=5968; q=dns/txt; s=iport; t=1382987855; x=1384197455; h=date:from:to:cc:subject:in-reply-to:message-id: references:mime-version; bh=KL2MC9mM9JyQG9e72G7ZqG3KhJxJPSLTwiYjYgao09E=; b=jt7S1OMiFk6/4Xwj9nEDcrimoEl2tjzNDHs0UXsNkFSSTy0Xn7nEzso0 4M/9YzRDJLkLSE+aldFCIZ8qju43LXb/L7zRBSRvx0YxtFjEUU42+89S7 lROc5UD/dsPaz2bM0hsNFU3kaO68mkw0B8llkc9I2fWy5IyvSysK5czuq Y=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ai8FAA+3blKtJV2a/2dsb2JhbABZgweBDL5kgSkWdIIlAQEBAwE4Aj8FCwsOHw4LSQENBg6IBga4Wo9VBwqEIgOeRYtMgWiBP4Ip X-IronPort-AV: E=Sophos;i="4.93,587,1378857600"; d="scan'208";a="277636690" Received: from rcdn-core-3.cisco.com ([173.37.93.154]) by rcdn-iport-2.cisco.com with ESMTP; 28 Oct 2013 19:17:35 +0000 Received: from xhc-rcd-x10.cisco.com (xhc-rcd-x10.cisco.com [173.37.183.84]) by rcdn-core-3.cisco.com (8.14.5/8.14.5) with ESMTP id r9SJHY4H013108 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Mon, 28 Oct 2013 19:17:34 GMT Received: from [10.61.212.63] (10.61.212.63) by xhc-rcd-x10.cisco.com (173.37.183.84) with Microsoft SMTP Server (TLS) id 14.2.318.4; Mon, 28 Oct 2013 14:17:33 -0500 Date: Mon, 28 Oct 2013 20:17:12 +0100 From: Andrew Yourtchenko X-X-Sender: ayourtch@ayourtch-mac To: Ted Lemon In-Reply-To: <06601039-CAFD-49B0-918B-A8ACD51B978D@fugue.com> Message-ID: References: <06601039-CAFD-49B0-918B-A8ACD51B978D@fugue.com> User-Agent: Alpine 2.00 (OSX 1167 2008-08-23) MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="US-ASCII" X-Originating-IP: [10.61.212.63] Cc: "v6ops@ietf.org" , Dave Thaler , "Ole Troan \(otroan\)" , "draft-liu-bonica-v6ops-dhcpv6-slaac-problem@tools.ietf.org" Subject: Re: [v6ops] DHCPv6/SLAAC Make Hosts Confusing-//RE: new draft: draft-liu-bonica-v6ops-dhcpv6-slaac-problem X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 28 Oct 2013 19:17:46 -0000 On Thu, 24 Oct 2013, Ted Lemon wrote: > Anyway, that's the rhetorical position I'm going to stake out for now. > I'm curious to see if anybody can come up with a reason to disagree that > doesn't simplify to either "I hate RA" or "I hate DHCP." I'll take a shot at outlining the differences as I see them between the two, and the factors that may influence the "I hate RA" or "I hate DHCP" reply in each particular case... 1) Interworking with different L2 topologies RA is "server-initiated, send once, receive many, no confirmation" abstraction - something that works well on the 10base2-type shared bus and even the today's wired ethernet, but looks quite miserable on the WiFi media without the ugly special tricks (802.11 provides reliable delivery for unicast frames, and does not provide one for multicast frames, also the physical speeds are different and even the contention management and the speed/modulation can be different as well). DHCPv6 is "client-initiated, send once, receive once, confirmation" abstraction. This may be wasteful on the low-bandwidth links that provide bus topology, but maps extremely well onto scenarios like WiFi - as it allows to maintain somewhat familiar mode of operation to wired ethernet. This is where the p2p, acknowledged nature of DHCPv6 may be beneficial - on a crowded large-scale WiFi, without dirty tricks, you simply will not get the SLAAC working because the multicast RAs will get crunched by the interference. Alternatively, in a very mobile environment and the RFC-compliant router, multicast solicited RAs might make a significant portion of your traffic - which, due to a difference in modulation, etc. may eat way more bandwidth than if they were sent unicast. 2) Acknowledged vs. unacknowledged DHCPv6 needs at least 2 packets. RA is just one packet. RA Plus: RA is quicker RA Minus: you have to take care that it is legitimate router and not your evil neighbor sending you the RAs you take the configuration from. DHCPv6 Plus: works well in the noisy/lossy environments DHCPv6 minus: takes at least 1 RTT to the server. 3) Client initiated vs. server initiated Despite of the division above, RA can be client-initiated, to some extent, with RS, and DHCPv6 can be server-initiated, to some extent, with "Reconfigure" messages. If we treat these as "nudge" messages, the behavior of the sending and receiving parties is similar - the "nudge" message causes the orderly protocol exchange to occur before the due time. The part that is different, though, is that RA, due to its "send once, receive many" nature, can aggregate the "nudge" messages, so intuitively seems best for a scenario with a very large number of the hosts, as it should have self-stabilizing properties, compared to DHCPv6. This "self-stabilizing" property intuitively seems to make RA safer to use, IFF it is used in purely "multicast" fashion. However, refer to (1) for the interaction with the underlying media. 4) Centralized coordination vs. distributed coordination RA, due to its "send once, receive many" nature, in its pure form necessarily can not dictate a per-client settings, but rather can only advise the domain the client would pick from (SLAAC). DHCPv6 on the other hand, due to its p2p nature is by default well suited for the individual per-client tweaking. The distributed nature can be a blessing if you do not care about who gets which address and a curse if you need to account everyone strictly. NB: address assignment does not mean that the hosts will always use those addresses - e.g. it's perfectly possible to statically configure a different address, but we talk just homogenous standards-compliant well-behaved hosts for simplicity sake). That's why I do not use the word "control" but use the word "coordination". 5) Involvement or not into routing RAs are a mechanism to provide some form of reliability for the routing in an independent fashion to the reasonably unsophisticated hosts. DHCPv6 was specifically denied any involvement in the routing. While architecturally "pure", the reliability and timing of the routing resiliency provided by the RAs is far below those achieved by FHRP protocols which are used in today's networks predominantly. This might create a dissonance between those who want to ensure RAs are used for routing, and those who do not see any use of them in that regard - with the corresponding contention of adding anything routing-related into DHCPv6. 6) Server locality Both DHCPv6 and RA are inherently link-local mechanisms, however DHCPv6 has a means to "jump" over multiple hops by use of the relays. This means RA *has* to be distributed, while DHCPv6 can be both centralized and distributed. Frequently it is made centralized because of other benefits that centralized administration brings, but almost any router today can run a DHCPv6 server on the box with no problem. 7) Programming: UDP vs. ICMP For a random programmer today, coding a server to receive the data on a UDP socket is a more familiar exercise than working with ICMP. Disclaimer: the value of "random" was chosen to be "me" for arbitrary reasons. This point is more of a rathole and a personal preference, probably. I think I remember Dave Thaler saying one of the mechanisms in Windows was way easier to extend than the other, but I do not remember which. 8) Separate vs. unified management If DHCPv4 and routing is managed by the different groups in the organization, then conceivably the "server" people will not like to have their work go away and similarly "router" guys are happy to get rid of yet another point of coordination and argument. This is where the "I hate $protocol" should definitely pop up. Add here the concerns from the previous 7 points. HTH. --a From tjc@ecs.soton.ac.uk Mon Oct 28 12:52:28 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1E04B11E8187 for ; Mon, 28 Oct 2013 12:52:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, 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 8RPPjatTiuk6 for ; Mon, 28 Oct 2013 12:52:27 -0700 (PDT) Received: from falcon.ecs.soton.ac.uk (falcon.ecs.soton.ac.uk [IPv6:2001:630:d0:f102::25e]) by ietfa.amsl.com (Postfix) with ESMTP id 036FD11E81AD for ; Mon, 28 Oct 2013 12:52:26 -0700 (PDT) Received: from falcon.ecs.soton.ac.uk (localhost.ecs.soton.ac.uk [127.0.0.1]) by falcon.ecs.soton.ac.uk (8.13.8/8.13.8) with ESMTP id r9SJqMFn032391; Mon, 28 Oct 2013 19:52:22 GMT X-DKIM: Sendmail DKIM Filter v2.8.2 falcon.ecs.soton.ac.uk r9SJqMFn032391 DKIM-Signature: v=1; a=rsa-sha1; c=simple/simple; d=ecs.soton.ac.uk; s=201304; t=1382989942; bh=l8b+r5UbGPwCE3BidodNUrW8k08=; h=Mime-Version:Subject:From:In-Reply-To:Date:Cc:References:To; b=ofKLWOwFKzW0dv4kq2lavXOKWxoHI61KK1f89Rm4zFfROJfMiaUG/FjCn48bJlSyP IVQLXgBzYtrwQnH9BHDE6OSsV7tvRTM4D49/HV+mWfJLAx5Y/cK0EQ8wJiY9t5/j1Q E053NKABhJ85kp3GPNHrTpjS8BS3x17v3x30mrsE= Received: from gander.ecs.soton.ac.uk ([2001:630:d0:f102:250:56ff:fea0:401]) by falcon.ecs.soton.ac.uk (falcon.ecs.soton.ac.uk [2001:630:d0:f102:250:56ff:fea0:68da]) envelope-from with ESMTP (valid=N/A) id p9RJqM09596290168y ret-id none; Mon, 28 Oct 2013 19:52:22 +0000 Received: from [192.168.1.108] (host213-123-213-183.in-addr.btopenworld.com [213.123.213.183]) (authenticated bits=0) by gander.ecs.soton.ac.uk (8.13.8/8.13.8) with ESMTP id r9SJox7G005581 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Mon, 28 Oct 2013 19:51:04 GMT Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 7.0 \(1816\)) From: Tim Chown In-Reply-To: Date: Mon, 28 Oct 2013 19:50:59 +0000 Content-Transfer-Encoding: quoted-printable Message-ID: References: <52689EE0.3030201@inex.ie> <73493F7B-5284-4EC8-8F72-922C68AE6FA3@nominum.com> To: james woodyatt X-Mailer: Apple Mail (2.1816) X-ECS-MailScanner: Found to be clean, Found to be clean X-smtpf-Report: sid=p9RJqM095962901600; tid=p9RJqM09596290168y; client=relay,forged,no_ptr,ipv6; mail=; rcpt=; nrcpt=3:0; fails=0 X-ECS-MailScanner-Information: Please contact the ISP for more information X-ECS-MailScanner-ID: r9SJqMFn032391 X-ECS-MailScanner-From: tjc@ecs.soton.ac.uk Cc: V6OPS Working Group Subject: Re: [v6ops] DHCPv6/SLAAC Make Hosts Confusing-//RE: new draft: draft-liu-bonica-v6ops-dhcpv6-slaac-problem X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 28 Oct 2013 19:52:28 -0000 On 28 Oct 2013, at 17:45, james woodyatt wrote: > On Oct 28, 2013, at 10:39 , Ted Lemon wrote: >> On Oct 28, 2013, at 11:50 AM, james woodyatt wrote: >>> I prefer this way out. I've said this before, but now seems like a = good time to say it again: stateless DHCPv6 has a lifetime of = information problem, and I think RFC 3736 should be sent to pasture. >>>=20 >>> p1. If there are information objects that must be individually and = separately configured at each host by the network, then stateful DHCPv6 = [RFC 3315] is the protocol for doing that. >>=20 >> It sounds like you are saying that devices that need per-device = configuration must use stateful address allocation. That's an odd = position to take, so I just want to make sure: is that what you intended = to say? >=20 > Is stateful address allocation required? I didn't think that was the = case. It seems perfectly reasonable to me that routers can advertise = M=3D0 and O=3D1, and hosts can then proceed to use RFC 3315 stateful = DHCPv6 to obtain things like their OpenDirectory service parameters. = Isn't that what the DUID mechanism is supposed to be about? Decoupling = the address allocation from the host identifier? >=20 >> FWIW, RFC 3736 was updated eight years ago with RFC 4242, which = provides an information refresh timer. If you aren't currently = implementing that, you should. Unfortunately the working group didn't = think to actually say that 4242 updates 3736, so I'm not surprised if = it's not on peoples' radar. >=20 > That's a problem. I'm not sure how much uptake RFC 4242 has gotten. As the person who pushed for this option as a result of experiments ten = years ago, it=92s disappointing. Can we at least fix that now? Tim= From tjc@ecs.soton.ac.uk Mon Oct 28 13:05:46 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EE8A311E819F for ; Mon, 28 Oct 2013 13:05:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[AWL=-0.000, 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 bRjl4KJ4ikqJ for ; Mon, 28 Oct 2013 13:05:46 -0700 (PDT) Received: from falcon.ecs.soton.ac.uk (falcon.ecs.soton.ac.uk [IPv6:2001:630:d0:f102::25e]) by ietfa.amsl.com (Postfix) with ESMTP id CE9D911E81DE for ; Mon, 28 Oct 2013 13:05:40 -0700 (PDT) Received: from falcon.ecs.soton.ac.uk (localhost [127.0.0.1]) by falcon.ecs.soton.ac.uk (8.13.8/8.13.8) with ESMTP id r9SK5ZFZ002430; Mon, 28 Oct 2013 20:05:35 GMT X-DKIM: Sendmail DKIM Filter v2.8.2 falcon.ecs.soton.ac.uk r9SK5ZFZ002430 DKIM-Signature: v=1; a=rsa-sha1; c=simple/simple; d=ecs.soton.ac.uk; s=201304; t=1382990735; bh=A0T+CrnNazxuQ080cHyzbPhFWQI=; h=Mime-Version:Subject:From:In-Reply-To:Date:Cc:References:To; b=2BUu5+0CKLLzjZQq5oVjjuvRZWqb6jPAmWmEhwwH2wAjSaUucolNOxS/xK4A9UI42 Feh1CXP5AxwVMkyks58VIF2GKkTSznsbL3z9WXYvyodlzlApXJv/9QDM/5Lu4cC2eO ucv/ENmOBDyj6MkTK3vOEDZG59X1Z65Q5buUSnwI= Received: from gander.ecs.soton.ac.uk (gander.ecs.soton.ac.uk [2001:630:d0:f102::25d]) by falcon.ecs.soton.ac.uk (falcon.ecs.soton.ac.uk [2001:630:d0:f102::25e]) envelope-from with ESMTP (valid=N/A) id p9RK5Z0959629084FY ret-id none; Mon, 28 Oct 2013 20:05:35 +0000 Received: from [192.168.1.108] (host213-123-213-183.in-addr.btopenworld.com [213.123.213.183]) (authenticated bits=0) by gander.ecs.soton.ac.uk (8.13.8/8.13.8) with ESMTP id r9SK4GdN008429 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Mon, 28 Oct 2013 20:04:16 GMT Content-Type: multipart/alternative; boundary="Apple-Mail=_123E849A-A6F9-4BC6-AD7A-E79C97A966EE" Mime-Version: 1.0 (Mac OS X Mail 7.0 \(1816\)) From: Tim Chown In-Reply-To: Date: Mon, 28 Oct 2013 20:04:13 +0000 Message-ID: References: <52689EE0.3030201@inex.ie> <73493F7B-5284-4EC8-8F72-922C68AE6FA3@nominum.com> <31841FF0-A7ED-468A-9589-959989C2303F@ecs.soton.ac.uk> To: Lorenzo Colitti X-Mailer: Apple Mail (2.1816) X-ECS-MailScanner: Found to be clean, Found to be clean X-smtpf-Report: sid=p9RK5Z095962908400; tid=p9RK5Z0959629084FY; client=relay,ipv6; mail=; rcpt=; nrcpt=3:0; fails=0 X-ECS-MailScanner-Information: Please contact the ISP for more information X-ECS-MailScanner-ID: r9SK5ZFZ002430 X-ECS-MailScanner-From: tjc@ecs.soton.ac.uk Cc: V6OPS Working Group Subject: Re: [v6ops] DHCPv6/SLAAC Make Hosts Confusing-//RE: new draft: draft-liu-bonica-v6ops-dhcpv6-slaac-problem X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 28 Oct 2013 20:05:47 -0000 --Apple-Mail=_123E849A-A6F9-4BC6-AD7A-E79C97A966EE Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=iso-8859-1 On 28 Oct 2013, at 17:45, Lorenzo Colitti wrote: > On Tue, Oct 29, 2013 at 2:39 AM, Ted Lemon = wrote: > FWIW, RFC 3736 was updated eight years ago with RFC 4242, which = provides an information refresh timer. If you aren't currently = implementing that, you should. Unfortunately the working group didn't = think to actually say that 4242 updates 3736, so I'm not surprised if = it's not on peoples' radar. >=20 > With a minimum of 10 minutes, unfortunately. At the time, 10 minutes was significantly better than infinity. It was = somewhat arbitraily picked. The concern was a very low value could cause significant load on the = stateless dhc server. The use case that drove RFC4242 was renumbering; we went through the = RFC4192 process, and this was a glaring gap. Tim --Apple-Mail=_123E849A-A6F9-4BC6-AD7A-E79C97A966EE Content-Transfer-Encoding: 7bit Content-Type: text/html; charset=iso-8859-1 On 28 Oct 2013, at 17:45, Lorenzo Colitti <lorenzo@google.com> wrote:

On Tue, Oct 29, 2013 at 2:39 AM, Ted Lemon <Ted.Lemon@nominum.com> wrote:
FWIW, RFC 3736 was updated eight years ago with RFC 4242, which provides an information refresh timer.   If you aren't currently implementing that, you should.   Unfortunately the working group didn't think to actually say that 4242 updates 3736, so I'm not surprised if it's not on peoples' radar.

 With a minimum of 10 minutes, unfortunately.

At the time, 10 minutes was significantly better than infinity.  It was somewhat arbitraily picked.

The concern was a very low value could cause significant load on the stateless dhc server.

The use case that drove RFC4242 was renumbering; we went through the RFC4192 process, and this was a glaring gap.

Tim

--Apple-Mail=_123E849A-A6F9-4BC6-AD7A-E79C97A966EE-- From Ted.Lemon@nominum.com Mon Oct 28 15:21:57 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 036E011E81B5 for ; Mon, 28 Oct 2013 15:21:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.289 X-Spam-Level: X-Spam-Status: No, score=-106.289 tagged_above=-999 required=5 tests=[AWL=-0.290, BAYES_00=-2.599, J_CHICKENPOX_13=0.6, 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 HsOTw5bYcSzG for ; Mon, 28 Oct 2013 15:21:51 -0700 (PDT) Received: from exprod7og104.obsmtp.com (exprod7og104.obsmtp.com [64.18.2.161]) by ietfa.amsl.com (Postfix) with ESMTP id 292B711E81ED for ; Mon, 28 Oct 2013 15:21:48 -0700 (PDT) Received: from shell-too.nominum.com ([64.89.228.229]) (using TLSv1) by exprod7ob104.postini.com ([64.18.6.12]) with SMTP ID DSNKUm7je1uah1u+mL7Dr9QUOsFxgP8INAYL@postini.com; Mon, 28 Oct 2013 15:21:48 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 DD1251B82E2 for ; Mon, 28 Oct 2013 15:21:46 -0700 (PDT) Received: from webmail.nominum.com (cas-01.win.nominum.com [64.89.228.131]) (using TLSv1 with cipher RC4-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 BA1CC190060; Mon, 28 Oct 2013 15:21:46 -0700 (PDT) (envelope-from Ted.Lemon@nominum.com) Received: from MBX-01.WIN.NOMINUM.COM ([64.89.228.133]) by CAS-01.WIN.NOMINUM.COM ([64.89.228.131]) with mapi id 14.03.0158.001; Mon, 28 Oct 2013 15:21:46 -0700 From: Ted Lemon To: Andrew Yourtchenko Thread-Topic: [v6ops] DHCPv6/SLAAC Make Hosts Confusing-//RE: new draft: draft-liu-bonica-v6ops-dhcpv6-slaac-problem Thread-Index: AQHO1BJoK2xB+cCJz0yYqhTRLsl1MpoKsAeS Date: Mon, 28 Oct 2013 22:21:45 +0000 Message-ID: <8hghajpatxclj78ue6ahqlod.1382998902797@email.android.com> References: <06601039-CAFD-49B0-918B-A8ACD51B978D@fugue.com>, In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "draft-liu-bonica-v6ops-dhcpv6-slaac-problem@tools.ietf.org" , "v6ops@ietf.org" , Ted Lemon , "Ole Troan \(otroan\)" , Dave Thaler Subject: Re: [v6ops] DHCPv6/SLAAC Make Hosts Confusing-//RE: new draft: draft-liu-bonica-v6ops-dhcpv6-slaac-problem X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 28 Oct 2013 22:21:57 -0000 Andrew, this is a really great analysis. It would be nice if it could be t= urned into a draft. Andrew Yourtchenko wrote: On Thu, 24 Oct 2013, Ted Lemon wrote: > Anyway, that's the rhetorical position I'm going to stake out for now. > I'm curious to see if anybody can come up with a reason to disagree that > doesn't simplify to either "I hate RA" or "I hate DHCP." I'll take a shot at outlining the differences as I see them between the two, and the factors that may influence the "I hate RA" or "I hate DHCP" reply in each particular case... 1) Interworking with different L2 topologies RA is "server-initiated, send once, receive many, no confirmation" abstraction - something that works well on the 10base2-type shared bus and even the today's wired ethernet, but looks quite miserable on the WiFi media without the ugly special tricks (802.11 provides reliable delivery for unicast frames, and does not provide one for multicast frames, also the physical speeds are different and even the contention management and the speed/modulation can be different as well). DHCPv6 is "client-initiated, send once, receive once, confirmation" abstraction. This may be wasteful on the low-bandwidth links that provide bus topology, but maps extremely well onto scenarios like WiFi - as it allows to maintain somewhat familiar mode of operation to wired ethernet. This is where the p2p, acknowledged nature of DHCPv6 may be beneficial - on a crowded large-scale WiFi, without dirty tricks, you simply will not get the SLAAC working because the multicast RAs will get crunched by the interference. Alternatively, in a very mobile environment and the RFC-compliant router, multicast solicited RAs might make a significant portion of your traffic - which, due to a difference in modulation, etc. may eat way more bandwidth than if they were sent unicast. 2) Acknowledged vs. unacknowledged DHCPv6 needs at least 2 packets. RA is just one packet. RA Plus: RA is quicker RA Minus: you have to take care that it is legitimate router and not your evil neighbor sending you the RAs you take the configuration from. DHCPv6 Plus: works well in the noisy/lossy environments DHCPv6 minus: takes at least 1 RTT to the server. 3) Client initiated vs. server initiated Despite of the division above, RA can be client-initiated, to some extent, with RS, and DHCPv6 can be server-initiated, to some extent, with "Reconfigure" messages. If we treat these as "nudge" messages, the behavior of the sending and receiving parties is similar - the "nudge" message causes the orderly protocol exchange to occur before the due time. The part that is different, though, is that RA, due to its "send once, receive many" nature, can aggregate the "nudge" messages, so intuitively seems best for a scenario with a very large number of the hosts, as it should have self-stabilizing properties, compared to DHCPv6. This "self-stabilizing" property intuitively seems to make RA safer to use, IFF it is used in purely "multicast" fashion. However, refer to (1) for the interaction with the underlying media. 4) Centralized coordination vs. distributed coordination RA, due to its "send once, receive many" nature, in its pure form necessarily can not dictate a per-client settings, but rather can only advise the domain the client would pick from (SLAAC). DHCPv6 on the other hand, due to its p2p nature is by default well suited for the individual per-client tweaking. The distributed nature can be a blessing if you do not care about who gets which address and a curse if you need to account everyone strictly. NB: address assignment does not mean that the hosts will always use those addresses - e.g. it's perfectly possible to statically configure a different address, but we talk just homogenous standards-compliant well-behaved hosts for simplicity sake). That's why I do not use the word "control" but use the word "coordination". 5) Involvement or not into routing RAs are a mechanism to provide some form of reliability for the routing in an independent fashion to the reasonably unsophisticated hosts. DHCPv6 was specifically denied any involvement in the routing. While architecturally "pure", the reliability and timing of the routing resiliency provided by the RAs is far below those achieved by FHRP protocols which are used in today's networks predominantly. This might create a dissonance between those who want to ensure RAs are used for routing, and those who do not see any use of them in that regard - with the corresponding contention of adding anything routing-related into DHCPv6. 6) Server locality Both DHCPv6 and RA are inherently link-local mechanisms, however DHCPv6 has a means to "jump" over multiple hops by use of the relays. This means RA *has* to be distributed, while DHCPv6 can be both centralized and distributed. Frequently it is made centralized because of other benefits that centralized administration brings, but almost any router today can run a DHCPv6 server on the box with no problem. 7) Programming: UDP vs. ICMP For a random programmer today, coding a server to receive the data on a UDP socket is a more familiar exercise than working with ICMP. Disclaimer: the value of "random" was chosen to be "me" for arbitrary reasons. This point is more of a rathole and a personal preference, probably. I think I remember Dave Thaler saying one of the mechanisms in Windows was way easier to extend than the other, but I do not remember which. 8) Separate vs. unified management If DHCPv4 and routing is managed by the different groups in the organization, then conceivably the "server" people will not like to have their work go away and similarly "router" guys are happy to get rid of yet another point of coordination and argument. This is where the "I hate $protocol" should definitely pop up. Add here the concerns from the previous 7 points. HTH. --a _______________________________________________ v6ops mailing list v6ops@ietf.org https://www.ietf.org/mailman/listinfo/v6ops From lorenzo@google.com Mon Oct 28 21:53:35 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6EAE011E8108 for ; Mon, 28 Oct 2013 21:53:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.783 X-Spam-Level: X-Spam-Status: No, score=-0.783 tagged_above=-999 required=5 tests=[AWL=-1.072, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, J_CHICKENPOX_13=0.6, NO_RELAYS=-0.001, SARE_HTML_USL_OBFU=1.666] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fyo6b9Do7TOi for ; Mon, 28 Oct 2013 21:53:34 -0700 (PDT) Received: from mail-ie0-x229.google.com (mail-ie0-x229.google.com [IPv6:2607:f8b0:4001:c03::229]) by ietfa.amsl.com (Postfix) with ESMTP id CE35921F9DF7 for ; Mon, 28 Oct 2013 21:53:33 -0700 (PDT) Received: by mail-ie0-f169.google.com with SMTP id ar20so13062389iec.14 for ; Mon, 28 Oct 2013 21:53:32 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=K1M5u6BSkV9UQ8f6MxFwPkUCxFxEbhtPrU1MfnZnWoM=; b=X52VdeDtyvxfuP++cMhzBoghMDrwM9dfc86P20n/el2zGnwum0um2iJ+/ih9wX0ddb TiO7th/CIaDJiy8QTPSgDC8mmjyxTR0eYFsSaTwMY//9rdG8zulBzkMMvs5U7eiaxmn0 vIHAekHmSdp32CvVPtQBAzLQ6XGBk6eaF9zpRHnXGBGBVSJyEDmat7VSh+WI+3fbMWrs JwW5Vc2O062KqZfl+r8pVyEGqKtN9HHY8TSP7+njc2tFbd8GUOkIIIscesNOX+s+BsBB zQevdq7wYWisVw8bfdPeLiqlFPfcoWrQ6HNYf38NORHydhpbyQD2d5Uzb+NxSqwojYiB a2+w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type; bh=K1M5u6BSkV9UQ8f6MxFwPkUCxFxEbhtPrU1MfnZnWoM=; b=XMkw+OlATFPHytmq0DHotVK6UuPhUXheKQEPxojmvKd035Qd6dcNTiTZVcvYEgtcKp wSJyoI1MMPF+Cfryq4HEdRVs07o93jTxP4gI+qU4vzZGfv4EWU2Apkyn3wuZrZxaahLc AsCHYHtzcMotevj3M4RgvEYqXyvcjSs+HxxH1J5qdyZwKjsnXm9FcZN0QLg0VGE8Vmnn 3yK5t/jKhl6bhTi0IaCCEyv2mHfgMj7Sp6VQJ0g7BFulZSzeI7mXSgpOaDDP1IY7vkhm eFhGuqbDsb4nHFTnq+yZ9O2iOK+YEZgL51bgd9lx67G77KNs5ljULJDFyFyEnjqGmxSM GosA== X-Gm-Message-State: ALoCoQl7cTlva7BBBfkT3t/2tvYAzQgrGUk8NMlm7Klglk2o2aFW6Va1DHoGhFyXcaNYIAR/pS42iN1ytPQcEr3ib8EDPVVG71++xpvUlrKP/omjTN0QqYhx30POzXCsJYRyf7FSLtzeAUWw3ONzZQR/CbjFlr2m/ywNNyKlXnSaCR44SCNAuDMOuSp4Sjq3UUsYO7ECAbyv X-Received: by 10.43.10.198 with SMTP id pb6mr3536240icb.40.1383022412593; Mon, 28 Oct 2013 21:53:32 -0700 (PDT) MIME-Version: 1.0 Received: by 10.64.86.106 with HTTP; Mon, 28 Oct 2013 21:53:11 -0700 (PDT) In-Reply-To: References: <06601039-CAFD-49B0-918B-A8ACD51B978D@fugue.com> From: Lorenzo Colitti Date: Tue, 29 Oct 2013 13:53:11 +0900 Message-ID: To: Andrew Yourtchenko Content-Type: multipart/alternative; boundary=bcaec50e5ce79eb88a04e9d9ff8c Cc: "draft-liu-bonica-v6ops-dhcpv6-slaac-problem@tools.ietf.org" , "v6ops@ietf.org" , Ted Lemon , "Ole Troan \(otroan\)" , Dave Thaler Subject: Re: [v6ops] DHCPv6/SLAAC Make Hosts Confusing-//RE: new draft: draft-liu-bonica-v6ops-dhcpv6-slaac-problem X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 29 Oct 2013 04:53:35 -0000 --bcaec50e5ce79eb88a04e9d9ff8c Content-Type: text/plain; charset=ISO-8859-1 Andrew, those are good points, though from the perspective of protocol design I think semantics and functionality are a bit more important than performance. Once you have the semantics right you can look at improving performance (e.g., via QoS, prioritization, queue isolation, etc. etc.), but if the semantics are wrong it's hard to fix that. So, semantics I think you forgot: 1. DHCPv6 makes it very hard to update client information from the network side. You can use reconfigure, but that requires authentication (clients MUST discard reconfigure messages that aren't authenticated). I don't know if anyone actually implements authentication. Also, it requires that the server know the DUID of the client. How do you do this if the client has never talked to you before, (e.g., if you booted after the client)? You'd have to have all the DHCPv6 servers on link communicate with each other. Also, it's not clear to me how you would implement reconfigure in a stateless environment, since the server doesn't know which clients are still there and not all clients (none?) implement RFC 4242. For an example of why this is useful, consider a homenet. You have two routers on the same link that share state via a routing protocol. Router A is unplugged. Router B knows this and wants to tell the client "don't use router A as DNS server any more". How do you do this? Using an RA you can just send out a message with a lifetime of zero. How do you do it with DHCPv6? 2. DHCPv6 doesn't support multiple sources of information. In particular, stateful DHCPv6 requires that the client choose one of the advertise messages it receives. The spec doesn't prevent it from starting a new transaction with a transaction ID, but I don't know what the original server would do if it received such a message. The RFC doesn't seem to specify this very well, if at all. 3. You can do per-client configuration using RA as well. There's nothing preventing routers from replying to RS packets with unicast RAs, so per-client configuration is possible. There's also nothing stopping you from causing an RS to trigger a provisioning (e.g., radius) request to a server asking for configuration parameters for that client - for example, giving it its own VLAN and its own /64. (I've built networks that do this, so I know it works). So your "it's not possible to jump" assertion is not entirely true. It's true that RAs can't jump by themselves, but the information requests can. I'm also don't think the "multicast doesn't work in congested networks" argument is valid. In a network where multicast is so overloaded that it's completely broken, it's not just RAs that will fail. NSes will get dropped too; MDNS won't work; basically, the network is broken. That said, unicast RAs don't have this problem. I'd be happy to contribute to a draft documenting these issues. Andrew, were you going to start one? On Tue, Oct 29, 2013 at 4:17 AM, Andrew Yourtchenko wrote: > On Thu, 24 Oct 2013, Ted Lemon wrote: > > Anyway, that's the rhetorical position I'm going to stake out for now. >> I'm curious to see if anybody can come up with a reason to disagree that >> doesn't simplify to either "I hate RA" or "I hate DHCP." >> > > I'll take a shot at outlining the differences as I see them between the > two, and the factors that may influence the "I hate RA" or "I hate DHCP" > reply in each particular case... > > 1) Interworking with different L2 topologies > > RA is "server-initiated, send once, receive many, no confirmation" > abstraction - something that works well on the 10base2-type shared bus and > even the today's wired ethernet, but looks quite miserable on the WiFi > media without the ugly special tricks (802.11 provides reliable delivery > for unicast frames, and does not provide one for multicast frames, also the > physical speeds are different and even the contention management and the > speed/modulation can be different as well). > > DHCPv6 is "client-initiated, send once, receive once, confirmation" > abstraction. This may be wasteful on the low-bandwidth links that provide > bus topology, but maps extremely well onto scenarios like WiFi - as it > allows to maintain somewhat familiar mode of operation to wired ethernet. > > This is where the p2p, acknowledged nature of DHCPv6 may be beneficial - > on a crowded large-scale WiFi, without dirty tricks, you simply will not > get the SLAAC working because the multicast RAs will get crunched by the > interference. > > Alternatively, in a very mobile environment and the RFC-compliant router, > multicast solicited RAs might make a significant portion of your traffic - > which, due to a difference in modulation, etc. may eat way more bandwidth > than if they were sent unicast. > > 2) Acknowledged vs. unacknowledged > > DHCPv6 needs at least 2 packets. RA is just one packet. > > RA Plus: RA is quicker > > RA Minus: you have to take care that it is legitimate router and not your > evil neighbor sending you the RAs you take the configuration from. > > DHCPv6 Plus: works well in the noisy/lossy environments > > DHCPv6 minus: takes at least 1 RTT to the server. > > > 3) Client initiated vs. server initiated > > Despite of the division above, RA can be client-initiated, to some extent, > with RS, and DHCPv6 can be server-initiated, to some extent, with > "Reconfigure" messages. > > If we treat these as "nudge" messages, the behavior of the sending and > receiving parties is similar - the "nudge" message causes the orderly > protocol exchange to occur before the due time. > > The part that is different, though, is that RA, due to its "send once, > receive many" nature, can aggregate the "nudge" messages, so intuitively > seems best for a scenario with a very large number of the hosts, as it > should have self-stabilizing properties, compared to DHCPv6. > > This "self-stabilizing" property intuitively seems to make RA safer to > use, IFF it is used in purely "multicast" fashion. > However, refer to (1) for the interaction with the underlying media. > > 4) Centralized coordination vs. distributed coordination > > RA, due to its "send once, receive many" nature, in its pure form > necessarily can not dictate a per-client settings, but rather can only > advise the domain the client would pick from (SLAAC). > > DHCPv6 on the other hand, due to its p2p nature is by default well suited > for the individual per-client tweaking. > > The distributed nature can be a blessing if you do not care about who gets > which address and a curse if you need to account everyone strictly. > > NB: address assignment does not mean that the hosts will always use those > addresses - e.g. it's perfectly possible to statically configure a > different address, but we talk just homogenous standards-compliant > well-behaved hosts for simplicity sake). > > That's why I do not use the word "control" but use the word "coordination". > > 5) Involvement or not into routing > > RAs are a mechanism to provide some form of reliability for the routing in > an independent fashion to the reasonably unsophisticated hosts. DHCPv6 was > specifically denied any involvement in the routing. > > While architecturally "pure", the reliability and timing of the routing > resiliency provided by the RAs is far below those achieved by FHRP > protocols which are used in today's networks predominantly. > > This might create a dissonance between those who want to ensure RAs are > used for routing, and those who do not see any use of them in that regard - > with the corresponding contention of adding anything routing-related into > DHCPv6. > > > 6) Server locality > > Both DHCPv6 and RA are inherently link-local mechanisms, however DHCPv6 > has a means to "jump" over multiple hops by use of the relays. This means > RA *has* to be distributed, while DHCPv6 can be both centralized and > distributed. Frequently it is made centralized because of other benefits > that centralized administration brings, but almost any router today can run > a DHCPv6 server on the box with no problem. > > 7) Programming: UDP vs. ICMP > > For a random programmer today, coding a server to receive the data on a > UDP socket is a more familiar exercise than working with ICMP. Disclaimer: > the value of "random" was chosen to be "me" for arbitrary reasons. This > point is more of a rathole and a personal preference, probably. I think I > remember Dave Thaler saying one of the mechanisms in Windows was way easier > to extend than the other, but I do not remember which. > > 8) Separate vs. unified management > > If DHCPv4 and routing is managed by the different groups in the > organization, then conceivably the "server" people will not like to have > their work go away and similarly "router" guys are happy to get rid of yet > another point of coordination and argument. This is where the "I hate > $protocol" should definitely pop up. Add here the concerns from the > previous 7 points. > > HTH. > > > --a > > ______________________________**_________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/**listinfo/v6ops > --bcaec50e5ce79eb88a04e9d9ff8c Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Andrew, those are good points, though from the perspective= of protocol design I think semantics and functionality are a bit more impo= rtant than performance. Once you have the semantics right you can look at i= mproving performance (e.g., via QoS, prioritization, queue isolation, etc. = etc.), but if the semantics are wrong it's hard to fix that.

So, semantics I think you forgot:

1. DHCP= v6 makes it very hard to update client information from the network side.

You can use reconfigure, but that requires authenti= cation (clients MUST discard reconfigure messages that aren't authentic= ated). I don't know if anyone actually implements authentication. Also,= it requires that the server know the DUID of the client. How do you do thi= s if the client has never talked to you before, (e.g., if you booted after = the client)? You'd have to have all the DHCPv6 servers on link communic= ate with each other.

Also, it's not clear to me how you would implement reconfigure= in a stateless environment, since the server doesn't know which client= s are still there and not all clients (none?) implement RFC 4242.

For an example of why this is useful, consider a homene= t. You have two routers on the same link that share state via a routing pro= tocol. Router A is unplugged. Router B knows this and wants to tell the cli= ent "don't use router A as DNS server any more". How do you d= o this? Using an RA you can just send out a message with a lifetime of zero= . How do you do it with DHCPv6?


2. DHCPv6 doesn't support multiple s= ources of information.

In particular, stateful DHC= Pv6 requires that the client choose one of the advertise messages it receiv= es. The spec doesn't prevent it from starting a new transaction with a = transaction ID, but I don't know what the original server would do if i= t received such a message. The RFC doesn't seem to specify this very we= ll, if at all.


3. You can do per-client configuration u= sing RA as well.

There's nothing preventing ro= uters from replying to RS packets with unicast RAs, so per-client configura= tion is possible. There's also nothing stopping you from causing an RS = to trigger a provisioning (e.g., radius) request to a server asking for con= figuration parameters for that client - for example, giving it its own VLAN= and its own /64. (I've built networks that do this, so I know it works= ). So your "it's not possible to jump" assertion is not entir= ely true. It's true that RAs can't jump by themselves, but the info= rmation requests can.


I'm also don't think the "m= ulticast doesn't work in congested networks" argument is valid. In= a network where multicast is so overloaded that it's completely broken= , it's not just RAs that will fail. NSes will get dropped too; MDNS won= 't work; basically, the network is broken. That said, unicast RAs don&#= 39;t have this problem.

I'd be happy to contribute to a draft documenting t= hese issues. Andrew, were you going to start one?


On Tue, Oct 29, 2013 at 4:1= 7 AM, Andrew Yourtchenko <ayourtch@cisco.com> wrote:
On Thu, 24 Oct 2013, Ted Lemon wrote:
Anyway, that's the rhetorical position I'm going to stake out for n= ow. I'm curious to see if anybody can come up with a reason to disagree= that doesn't simplify to either "I hate RA" or "I hate = DHCP."

I'll take a shot at outlining the differences as I see them between the= two, and the factors that may influence the "I hate RA" or "= ;I hate DHCP" reply in each particular case...

1) Interworking with different L2 topologies

RA is "server-initiated, send once, receive many, no confirmation"= ; abstraction - something that works well on the 10base2-type shared bus an= d even the today's wired ethernet, but looks quite miserable on the WiF= i media without the ugly special tricks (802.11 provides reliable delivery = for unicast frames, and does not provide one for multicast frames, also the= physical speeds are different and even the contention management and the s= peed/modulation can be different as well).

DHCPv6 is "client-initiated, send once, receive once, confirmation&quo= t; abstraction. This may be wasteful on the low-bandwidth links that provid= e bus topology, but maps extremely well onto scenarios like WiFi - as it al= lows to maintain somewhat familiar mode of operation to wired ethernet.

This is where the p2p, acknowledged nature of DHCPv6 may be beneficial - on= a crowded large-scale WiFi, without dirty tricks, you simply will not get = the SLAAC working because the multicast RAs will get crunched by the interf= erence.

Alternatively, in a very mobile environment and the RFC-compliant router, m= ulticast solicited RAs might make a significant portion of your traffic - w= hich, due to a difference in modulation, etc. may eat way more bandwidth th= an if they were sent unicast.

2) Acknowledged vs. unacknowledged

DHCPv6 needs at least 2 packets. RA is just one packet.

RA Plus: RA is quicker

RA Minus: you have to take care that it is legitimate router and not your e= vil neighbor sending you the RAs you take the configuration from.

DHCPv6 Plus: works well in the noisy/lossy environments

DHCPv6 minus: takes at least 1 RTT to the server.


3) Client initiated vs. server initiated

Despite of the division above, RA can be client-initiated, to some extent, = with RS, and DHCPv6 can be server-initiated, to some extent, with "Rec= onfigure" messages.

If we treat these as "nudge" messages, the behavior of the sendin= g and receiving parties is similar - the "nudge" message causes t= he orderly protocol exchange to occur before the due time.

The part that is different, though, is that RA, due to its "send once,= receive many" nature, can aggregate the "nudge" messages, s= o intuitively seems best for a scenario with a very large number of the hos= ts, as it should have self-stabilizing properties, compared to DHCPv6.

This "self-stabilizing" property intuitively seems to make RA saf= er to use, IFF it is used in purely "multicast" fashion.
However, refer to (1) for the interaction with the underlying media.

4) Centralized coordination vs. distributed coordination

RA, due to its "send once, receive many" nature, in its pure form= necessarily can not dictate a per-client settings, but rather can only adv= ise the domain the client would pick from (SLAAC).

DHCPv6 on the other hand, due to its p2p nature is by default well suited f= or the individual per-client tweaking.

The distributed nature can be a blessing if you do not care about who gets = which address and a curse if you need to account everyone strictly.

NB: address assignment does not mean that the hosts will always use those a= ddresses - e.g. it's perfectly possible to statically configure a diffe= rent address, but we talk just homogenous standards-compliant well-behaved = hosts for simplicity sake).

That's why I do not use the word "control" but use the word &= quot;coordination".

5) Involvement or not into routing

RAs are a mechanism to provide some form of reliability for the routing in = an independent fashion to the reasonably unsophisticated hosts. DHCPv6 was = specifically denied any involvement in the routing.

While architecturally "pure", the reliability and timing of the r= outing resiliency provided by the RAs is far below those achieved by FHRP p= rotocols which are used in today's networks predominantly.

This might create a dissonance between those who want to ensure RAs are use= d for routing, and those who do not see any use of them in that regard - wi= th the corresponding contention of adding anything routing-related into DHC= Pv6.


6) Server locality

Both DHCPv6 and RA are inherently link-local mechanisms, however DHCPv6 has= a means to "jump" over multiple hops by use of the relays. This = means RA *has* to be distributed, while DHCPv6 can be both centralized and = distributed. Frequently it is made centralized because of other benefits th= at centralized administration brings, but almost any router today can run a= DHCPv6 server on the box with no problem.

7) Programming: UDP vs. ICMP

For a random programmer today, coding a server to receive the data on a UDP= socket is a more familiar exercise than working with ICMP. Disclaimer: the= value of "random" was chosen to be "me" for arbitrary = reasons. This point is more of a rathole and a personal preference, probabl= y. I think I remember Dave Thaler saying one of the mechanisms in Windows w= as way easier to extend than the other, but I do not remember which.

8) Separate vs. unified management

If DHCPv4 and routing is managed by the different groups in the organizatio= n, then conceivably the "server" people will not like to have the= ir work go away and similarly "router" guys are happy to get rid = of yet another point of coordination and argument. This is where the "= I hate $protocol" should definitely pop up. Add here the concerns from= the previous 7 points.

HTH.


--a

_______________________________________________
v6ops mailing list
v6ops@ietf.org
h= ttps://www.ietf.org/mailman/listinfo/v6ops

--bcaec50e5ce79eb88a04e9d9ff8c-- From lorenzo@google.com Mon Oct 28 22:14:01 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C278121E80AC for ; Mon, 28 Oct 2013 22:14:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.88 X-Spam-Level: X-Spam-Status: No, score=-1.88 tagged_above=-999 required=5 tests=[AWL=0.097, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, 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 lt+tmrYf32YT for ; Mon, 28 Oct 2013 22:14:00 -0700 (PDT) Received: from mail-ie0-x235.google.com (mail-ie0-x235.google.com [IPv6:2607:f8b0:4001:c03::235]) by ietfa.amsl.com (Postfix) with ESMTP id 8402921F9CB5 for ; Mon, 28 Oct 2013 22:14:00 -0700 (PDT) Received: by mail-ie0-f181.google.com with SMTP id ar20so13335193iec.12 for ; Mon, 28 Oct 2013 22:14:00 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=+2Ejj8RzT0CxY/9s7aiPG/TnT2/AtQsXAFS1ecO/6OE=; b=pQn2F31STfu6y+PP6qvsCwdUfMX0vX5DfFM1evtDdEEAle3dm0OliaCcx6A+NVxBYw iiCgWxHx5pBKLisGgR3MD916bB4G+7UgLcXt6l5pRNwB0336UbtYjCPZujM1LzBo3A9q ldsfSJhq8WeI00b9CJEQce4p8mf8b05bWd7lY/ty9N4T9fSD1yrRTRlJ40Q4B8vwmCBy ktBx19uuw+Hidrp/UQ0NMc6NsdB9N1brnjgXf41kVeYxO20q5z6WiDt21DFk674ICLZP M0oRhLfzCtPcTnwa924Qqgb8EvQcjcmkLoe1uR6MFAfoDPKJVOBHISILRDZ9ompEAxov fi8A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type; bh=+2Ejj8RzT0CxY/9s7aiPG/TnT2/AtQsXAFS1ecO/6OE=; b=IYXw1wMqT2SYQHMa1cHYn8TaBgGmPfW0N8WtUDBtPS9mYZcP0XA4286lZjIqn8XvJh ETKjOxXvAUUvaVi4C5hEkX1rQlxK1gjiEYSmWQq42YBFD01a3xVvUujOvV9fX9zbUuDE s/u1fb97AJ5GGcF6Ca/nUOJmkUcPL7v5bjEJF/PKmtDHgCViSafcDPUEaDeBRJrfUq9e AK+V6Cv6SnTbpkUT+WZZDiKIWMWVCC+Zf8p9pokgy9xG8Qm7IzrbMJ7/GTsC7gY34qDm eCGqRVdwk9JpMu8wa3UNAk5DuapzEQFz6jBzQWLpqq+wpA0y8ck1mOPMjYH5ycFT+7TC L0Dw== X-Gm-Message-State: ALoCoQlV4mjcZCyiOAycQQ0Qyn/yhUGITVUgXbrRx5lP/BDabAqnLQmlXhn029UIWNUEXPhFvVkosIrUOd7zsTeTnGNZg57Nkz/GKUASEHNaGHHcvHP7n1KzL/mMzgZznDoCbdc2BOeK4Zt0+WlYpRKzydTp0pfpMTns7JsoNWpIvT5V6vzK+uLpO/SYEIhaK5K3NpLe6LHE X-Received: by 10.50.153.50 with SMTP id vd18mr11096194igb.6.1383023639973; Mon, 28 Oct 2013 22:13:59 -0700 (PDT) MIME-Version: 1.0 Received: by 10.64.86.106 with HTTP; Mon, 28 Oct 2013 22:13:39 -0700 (PDT) In-Reply-To: References: <06601039-CAFD-49B0-918B-A8ACD51B978D@fugue.com> From: Lorenzo Colitti Date: Tue, 29 Oct 2013 14:13:39 +0900 Message-ID: To: Andrew Yourtchenko Content-Type: multipart/alternative; boundary=089e013a009ec6f30304e9da48b4 Cc: "draft-liu-bonica-v6ops-dhcpv6-slaac-problem@tools.ietf.org" , "v6ops@ietf.org" , Ted Lemon , "Ole Troan \(otroan\)" , Dave Thaler Subject: Re: [v6ops] DHCPv6/SLAAC Make Hosts Confusing-//RE: new draft: draft-liu-bonica-v6ops-dhcpv6-slaac-problem X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 29 Oct 2013 05:14:01 -0000 --089e013a009ec6f30304e9da48b4 Content-Type: text/plain; charset=ISO-8859-1 Comments inline. On Tue, Oct 29, 2013 at 4:17 AM, Andrew Yourtchenko wrote: > This is where the p2p, acknowledged nature of DHCPv6 may be beneficial - > on a crowded large-scale WiFi, without dirty tricks, you simply will not > get the SLAAC working because the multicast RAs will get crunched by the > interference. > Well, but multicast NS won't work either, so the network is pretty broken at this point. You can also send solicited RAs unicast, of course. > 2) Acknowledged vs. unacknowledged > > DHCPv6 needs at least 2 packets. RA is just one packet. > > RA Plus: RA is quicker > > RA Minus: you have to take care that it is legitimate router and not your > evil neighbor sending you the RAs you take the configuration from. > But you can't authenticate in DHCPv6 either, right? Whether you get an unsolicited "here's some config parameters" RA or a unicast "thank you for your request, here's some config parameters" DHCPv6 reply, the problem is the same: is the source trustworthy? AIUI we don't have any solution for this except DHCPv6 guard and RA guard, which are effectively the same solution. I mean - we do have SEND and DHCPv6 authentication, but does anyone implement those? > 3) Client initiated vs. server initiated > > Despite of the division above, RA can be client-initiated, to some extent, > with RS, and DHCPv6 can be server-initiated, to some extent, with > "Reconfigure" messages. > > If we treat these as "nudge" messages, the behavior of the sending and > receiving parties is similar - the "nudge" message causes the orderly > protocol exchange to occur before the due time. > > The part that is different, though, is that RA, due to its "send once, > receive many" nature, can aggregate the "nudge" messages, so intuitively > seems best for a scenario with a very large number of the hosts, as it > should have self-stabilizing properties, compared to DHCPv6. > RAs also allow someone who's not the original server to send you a nudge. In DHCPv6 you need to know the client's DUID to send a nudge, which is hard (impossible?) to do unless the client has talked to you before, or you've at least seen a multicast solicit from it. > 4) Centralized coordination vs. distributed coordination > > RA, due to its "send once, receive many" nature, in its pure form > necessarily can not dictate a per-client settings, but rather can only > advise the domain the client would pick from (SLAAC). > You can dictate per-client settings via unicast RA. But it's true that you can't dictate per-client addressing, because RAs don't support that. > DHCPv6 on the other hand, due to its p2p nature is by default well suited > for the individual per-client tweaking. > I agree that it's more suited. A lot of this is not due to the protocol itself, but due to the fact that we have a lot of infrastructure (protocol and implementation) built around this: we have relays, relay-inserted options, sophisticated DHCPv6 servers with per-client configuration, etc. > 5) Involvement or not into routing > > RAs are a mechanism to provide some form of reliability for the routing in > an independent fashion to the reasonably unsophisticated hosts. DHCPv6 was > specifically denied any involvement in the routing. > > While architecturally "pure", the reliability and timing of the routing > resiliency provided by the RAs is far below those achieved by FHRP > protocols which are used in today's networks predominantly. > This is a fairly complex issue. It very much depends on what network you're building. If you're in a wired environment, it doesn't matter - send RAs every 3 seconds with lifetimes of 6 seconds and you're doing roughly as well as VRRP. (Yes, you can crank VRRP timers down lower than that, but in a large network with lots of VLANs, that will cause too much control plane load). All else being equal, I think multicast RA should be more scalable because it just requires the router to periodically spit out identical packets, whereas VRRP requires group coordination and state machines. But that might be in the noise. If you're in a home environment, the coordination required to use VRRP might not be available, but having multiple routers send RAs is quite easy. In a battery-constrained setting, sending frequent RAs is expensive. You can use NUD with low timers to do failover, but that can get expensive if you have many clients. So there are lots of tradeoffs here. > 6) Server locality > > Both DHCPv6 and RA are inherently link-local mechanisms, however DHCPv6 > has a means to "jump" over multiple hops by use of the relays. This means > RA *has* to be distributed, while DHCPv6 can be both centralized and > distributed. Frequently it is made centralized because of other benefits > that centralized administration brings, but almost any router today can run > a DHCPv6 server on the box with no problem. > I've built networks that send radius requests on receipt of RSes and then send unicast RAs to the client. So it's possible to do this via RA as well. It's true that we have a lot more infrastructure to do this in DHCPv6 as well. > 7) Programming: UDP vs. ICMP > > For a random programmer today, coding a server to receive the data on a > UDP socket is a more familiar exercise than working with ICMP. Disclaimer: > the value of "random" was chosen to be "me" for arbitrary reasons. This > point is more of a rathole and a personal preference, probably. I think I > remember Dave Thaler saying one of the mechanisms in Windows was way easier > to extend than the other, but I do not remember which. > ICMP is harder than UDP to implement; it often requires raw sockets or kernel collaboration (e.g., on Linux RDNSS information can be read using netlink. UDP is much simpler). On the other hand, I think stateful DHCPv6 is a more complicated protocol to implement than RAs, with more message types and so on. > 8) Separate vs. unified management > > If DHCPv4 and routing is managed by the different groups in the > organization, then conceivably the "server" people will not like to have > their work go away and similarly "router" guys are happy to get rid of yet > another point of coordination and argument. This is where the "I hate > $protocol" should definitely pop up. Add here the concerns from the > previous 7 points. > Agreed. This is mostly true in an enterprise environment though. You don't get turf wars at home. :-) On the other hand, in some enterprises, it's possible that the "server" people might relish the chance of not having to support DHCPv6 at all. If everything the client needs can be done via RA - they might just say "great, one less thing we have to do to move to IPv6". --089e013a009ec6f30304e9da48b4 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Comments inline.

On Tue, Oct 29, = 2013 at 4:17 AM, Andrew Yourtchenko <ayourtch@cisco.com> wr= ote:
This is whe= re the p2p, acknowledged nature of DHCPv6 may be beneficial - on a crowded = large-scale WiFi, without dirty tricks, you simply will not get the SLAAC w= orking because the multicast RAs will get crunched by the interference.

Well, but multicast NS won't work eith= er, so the network is pretty broken at this point. You can also send solici= ted RAs unicast, of course.
=A0
2) Acknowledged vs. unacknowledged

DHCPv6 needs at least 2 packets. RA is just one packet.

RA Plus: RA is quicker

RA Minus: you have to take care that it is legitimate router and not your e= vil neighbor sending you the RAs you take the configuration from.

But you can't authenticate in DHCPv6 either,= right? Whether you get an unsolicited "here's some config paramet= ers" RA or a unicast "thank you for your request, here's some= config parameters" DHCPv6 reply, the problem is the same: is the sour= ce trustworthy? AIUI we don't have any solution for this except DHCPv6 = guard and RA guard, which are effectively the same solution. I mean - we do= have SEND and DHCPv6 authentication, but does anyone implement those?
=A0
3) Client initiated vs. server= initiated

Despite of the division above, RA can be client-initiated, to some extent, = with RS, and DHCPv6 can be server-initiated, to some extent, with "Rec= onfigure" messages.

If we treat these as "nudge" messages, the behavior of the sendin= g and receiving parties is similar - the "nudge" message causes t= he orderly protocol exchange to occur before the due time.

The part that is different, though, is that RA, due to its "send once,= receive many" nature, can aggregate the "nudge" messages, s= o intuitively seems best for a scenario with a very large number of the hos= ts, as it should have self-stabilizing properties, compared to DHCPv6.

RAs also allow someone who's not the o= riginal server to send you a nudge. In DHCPv6 you need to know the client&#= 39;s DUID to send a nudge, which is hard (impossible?) to do unless the cli= ent has talked to you before, or you've at least seen a multicast solic= it from it.
=A0
4) Centralized coordination vs= . distributed coordination

RA, due to its "send once, receive many" nature, in its pure form= necessarily can not dictate a per-client settings, but rather can only adv= ise the domain the client would pick from (SLAAC).

You can dictate per-client settings via unicast RA. But it&#= 39;s true that you can't dictate per-client addressing, because RAs don= 't support that.=A0
=A0
DHCPv6 on the other hand, due to its p2p nature is by default well suited f= or the individual per-client tweaking.

= I agree that it's more suited. A lot of this is not due to the protocol= itself, but due to the fact that we have a lot of infrastructure (protocol= and implementation) built around this: we have relays, relay-inserted opti= ons, sophisticated DHCPv6 servers with per-client configuration, etc.
=A0
5) Involvement or not into rou= ting

RAs are a mechanism to provide some form of reliability for the routing in = an independent fashion to the reasonably unsophisticated hosts. DHCPv6 was = specifically denied any involvement in the routing.

While architecturally "pure", the reliability and timing of the r= outing resiliency provided by the RAs is far below those achieved by FHRP p= rotocols which are used in today's networks predominantly.

This is a fairly complex issue. It very much depends on= what network you're building.

If you're i= n a wired environment, it doesn't matter - send RAs every 3 seconds wit= h lifetimes of 6 seconds and you're doing roughly as well as VRRP. (Yes= , you can crank VRRP timers down lower than that, but in a large network wi= th lots of VLANs, that will cause too much control plane load). All else be= ing equal, I think multicast RA should be more scalable because it just req= uires the router to periodically spit out identical packets, whereas VRRP r= equires group coordination and state machines. But that might be in the noi= se.

If you're in a home environment, the coordination r= equired to use VRRP might not be available, but having multiple routers sen= d RAs is quite easy.

In a battery-constrained sett= ing, sending frequent RAs is expensive. You can use NUD with low timers to = do failover, but that can get expensive if you have many clients. So there = are lots of tradeoffs here.

=A0
6) Server local= ity

Both DHCPv6 and RA are inherently link-local mechanisms, however DHCPv6 has= a means to "jump" over multiple hops by use of the relays. This = means RA *has* to be distributed, while DHCPv6 can be both centralized and = distributed. Frequently it is made centralized because of other benefits th= at centralized administration brings, but almost any router today can run a= DHCPv6 server on the box with no problem.

I've built networks that send radius r= equests on receipt of RSes and then send unicast RAs to the client. So it&#= 39;s possible to do this via RA as well. It's true that we have a lot m= ore infrastructure to do this in DHCPv6 as well.
=A0
7) Programming: UDP vs. ICMP
For a random programmer today, coding a server to receive the data on a UDP= socket is a more familiar exercise than working with ICMP. Disclaimer: the= value of "random" was chosen to be "me" for arbitrary = reasons. This point is more of a rathole and a personal preference, probabl= y. I think I remember Dave Thaler saying one of the mechanisms in Windows w= as way easier to extend than the other, but I do not remember which.

ICMP is harder than UDP to implement; it o= ften requires raw sockets or kernel collaboration (e.g., on Linux RDNSS inf= ormation can be read using netlink. UDP is much simpler). On the other hand= , I think stateful DHCPv6 is a more complicated protocol to implement than = RAs, with more message types and so on.
=A0
8) Separate vs. unified manage= ment

If DHCPv4 and routing is managed by the different groups in the organizatio= n, then conceivably the "server" people will not like to have the= ir work go away and similarly "router" guys are happy to get rid = of yet another point of coordination and argument. This is where the "= I hate $protocol" should definitely pop up. Add here the concerns from= the previous 7 points.

Agreed. This is mostly true in an enterpri= se environment though. You don't get turf wars at home. :-) On the othe= r hand, in some enterprises, it's possible that the "server" = people might relish the chance of not having to support DHCPv6 at all. If e= verything the client needs can be done via RA - they might just say "g= reat, one less thing we have to do to move to IPv6".
--089e013a009ec6f30304e9da48b4-- From markzzzsmith@yahoo.com.au Tue Oct 29 01:47:31 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4324511E814E for ; Tue, 29 Oct 2013 01:47:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[AWL=0.200, BAYES_00=-2.599, FROM_LOCAL_NOVOWEL=0.5] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HxsEEpu8js00 for ; Tue, 29 Oct 2013 01:47:26 -0700 (PDT) Received: from nm45-vm1.bullet.mail.bf1.yahoo.com (nm45-vm1.bullet.mail.bf1.yahoo.com [216.109.115.60]) by ietfa.amsl.com (Postfix) with ESMTP id CBFE711E8146 for ; Tue, 29 Oct 2013 01:47:24 -0700 (PDT) Received: from [98.139.215.140] by nm45.bullet.mail.bf1.yahoo.com with NNFMP; 29 Oct 2013 08:47:24 -0000 Received: from [98.139.212.250] by tm11.bullet.mail.bf1.yahoo.com with NNFMP; 29 Oct 2013 08:47:23 -0000 Received: from [127.0.0.1] by omp1059.mail.bf1.yahoo.com with NNFMP; 29 Oct 2013 08:47:23 -0000 X-Yahoo-Newman-Property: ymail-3 X-Yahoo-Newman-Id: 934308.28677.bm@omp1059.mail.bf1.yahoo.com Received: (qmail 56994 invoked by uid 60001); 29 Oct 2013 08:47:23 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com.au; s=s1024; t=1383036443; bh=/vfzMgNeSI3KYyQVGfnGlU7GgSepDOG1koA8iE7vliw=; h=X-YMail-OSG:Received:X-Rocket-MIMEInfo:X-Mailer:References:Message-ID:Date:From:Reply-To:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type:Content-Transfer-Encoding; b=IVtWw5JiiSZ8BVC1NuHHDbisT/3x3h0kv+VtqlKOeFVksjjdaZWeTYjbjrATBW26ZM0fMIcO0jSUGyJDAOJrciL+AO/IxwO1vOmEuAZXw9VEzsTPho2Tr2Szq4IlGhyKkC8/KuVSD8BRiY1XFvhiTbIcz9ATjNQt3p2jWrp1yBM= DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com.au; h=X-YMail-OSG:Received:X-Rocket-MIMEInfo:X-Mailer:References:Message-ID:Date:From:Reply-To:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type:Content-Transfer-Encoding; b=heIf+VI9g7i/7on9uWn2ZJnyzz3Ox+QQcVT2h/A47FEY8VkRqIywCB4HWVng0ksfD9rNItCiHLfMHiifNCHrsYyFZ0tgcrpHSrpUaIoRPdUvLdZB5otI5UFwq99Ds/wZSTKlzYNfi1sic0LVrFjLjVLMq5iCKUPJXwM5kCq0eTU=; X-YMail-OSG: zFyWrsMVM1mfo_45er.zVNep5hQE4pkCNFBdgpgpio8ZMLD h7j35o6PC..fmilEEAxlfdd070EMS18qMYXoRUrw50vmFwdeg1HwUk5Cv6_k UmXvRz.qEEq0GJR1IVCqQ5ubgZO4FQJVpqdjYKueOPQBabJz4FKwO_oWCqBu qEhMsuphhTm2V2Dn6hB6i3ulAGDfVgmVQZJXxcCp0wQlgbLqAV..fVRwfnCE i5EigbUVjXHQxv6cg9vRsFyCmtMl2hymwAgA0vbzsT8Lpla_TxSoFjrXjEoB rYnecwPHz5PjDlCydEwM0AMZrN5MTrnjDo4A1_7srPoIXx6TR9rB3HAyDX6k _AXIJSHH5rTWQwhxQfIXTHpowepBpBwjK59n67d15aVkdqkuShXRH_3br7vR BRd3C4OUzIn1DOSl.ahdNgZa9i6HBx7v1myzlDDpxFInSKhzLRSPkOBp7lt4 oGVGpU3I5LeMn3U3junXlA4OvIoIgACB8LtypTYLSmI.A1v0xwV7uXW5U57R _wkxlt.2QD77H5q20XA4zU9oSI49WxuhTCbXcwoQN5bi_WL0ZBEh6kVrqFyl 6n7ImEvyPN5.v279d3Is7vCTmO_5SNEV.LiqlDBurNzjBIQ-- Received: from [150.101.221.237] by web142501.mail.bf1.yahoo.com via HTTP; Tue, 29 Oct 2013 01:47:23 PDT X-Rocket-MIMEInfo: 002.001, SGksCgpBIGZldyBvdGhlciBwb2ludHM6CgotIFJvZ3VlIERIQ1B2NiBzZXJ2ZXJzIGFyZSBhbHNvIGEgcG90ZW50aWFsIGlzc3VlLCBzbyB0aGlzIHNvcnQgb2YgcHJvYmxlbSBpc24ndCBleGNsdXNpdmUgdG8gUkFzLsKgCgotIERIQ1B2NiB1c2VzIG11bHRpY2FzdCBmb3IgSW5mb3JtYXRpb24tUmVxdWVzdCBtZXNzYWdlcyBmb3Igc3RhdGVsZXNzIERIQ1B2NiBzZXJ2aWNlIGFuZCBTb2xpY2l0IG1lc3NhZ2VzIGZvciBzdGF0ZWZ1bCBESENQdjYgc2VydmljZSwgc28gYSBsaW5rIHN1ZmZlcmluZyBmcm9tIGUBMAEBAQE- X-Mailer: YahooMailWebService/0.8.160.587 References: <06601039-CAFD-49B0-918B-A8ACD51B978D@fugue.com> Message-ID: <1383036443.56704.YahooMailNeo@web142501.mail.bf1.yahoo.com> Date: Tue, 29 Oct 2013 01:47:23 -0700 (PDT) From: Mark ZZZ Smith To: Lorenzo Colitti , Andrew Yourtchenko In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Cc: "v6ops@ietf.org" , Dave Thaler , Ted Lemon , "Ole Troan \(otroan\)" , "draft-liu-bonica-v6ops-dhcpv6-slaac-problem@tools.ietf.org" Subject: Re: [v6ops] DHCPv6/SLAAC Make Hosts Confusing-//RE: new draft: draft-liu-bonica-v6ops-dhcpv6-slaac-problem X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: Mark ZZZ Smith List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 29 Oct 2013 08:47:31 -0000 Hi,=0A=0AA few other points:=0A=0A- Rogue DHCPv6 servers are also a potenti= al issue, so this sort of problem isn't exclusive to RAs.=A0=0A=0A- DHCPv6 = uses multicast for Information-Request messages for stateless DHCPv6 servic= e and Solicit messages for stateful DHCPv6 service, so a link suffering fro= m excessive multicast traffic drops may also prevent DHCPv6 working reliabl= y or quickly.=0A=0AI'm a bit confused by "something that works well on the = 10base2-type shared bus and even the today's wired ethernet, but looks quit= e miserable on the WiFi media without the ugly special tricks". My understa= nding is that Internet protocols of all types are to be designed with the a= ssumption of the possibility of a low level of packet loss. If the packet l= oss is too high, then link-layer designers are advised to use link-layer re= liability mechanisms, as per advised in RFC3819.=A0I'm interested in detail= s of the "ugly special tricks" if they're more than proprietary wifi link-l= ayer multicast reliability mechanisms.=A0=0A=0AGeneral lack of Wifi multica= st performance is the motive behind the following draft - replication and l= ink-layer unicasting of unsolicited RAs could be used on Wifi to make them = more reliable.=0A=0AMLDv2 Procedures for Link-Layer Unicast Delivery of Mul= ticast IPv6=0Ahttp://tools.ietf.org/html/draft-smith-mldv2-link-unicast-00= =0A=0A=0A=0A- "While architecturally "pure", the reliability and timing of = the routing resiliency provided by the RAs is far below those achieved by F= HRP protocols which are used in today's networks predominantly." This seems= to suggest that you can't run VRRP/HSRP if you're using RAs. I don't think= they're mutually exclusive, as long as the RAs come from the virtual route= r link-local address, rather than the routers' physical interface link-loca= l addresses.=0A=0ARegards,=0AMark.=0A=0A=0A>_______________________________= _=0A> From: Lorenzo Colitti =0A>To: Andrew Yourtchenko = =0A>Cc: "draft-liu-bonica-v6ops-dhcpv6-slaac-problem@t= ools.ietf.org" = ; "v6ops@ietf.org" ; Ted Lemon ; Ole Troa= n (otroan) ; Dave Thaler =0A>Sent= : Tuesday, 29 October 2013 3:53 PM=0A>Subject: Re: [v6ops] DHCPv6/SLAAC Mak= e Hosts Confusing-//RE: new draft:=A0=A0=A0=A0draft-liu-bonica-v6ops-dhcpv6= -slaac-problem=0A> =0A>=0A>=0A>Andrew, those are good points, though from t= he perspective of protocol design I think semantics and functionality are a= bit more important than performance. Once you have the semantics right you= can look at improving performance (e.g., via QoS, prioritization, queue is= olation, etc. etc.), but if the semantics are wrong it's hard to fix that.= =0A>=0A>=0A>So, semantics I think you forgot:=0A>=0A>=0A>1. DHCPv6 makes it= very hard to update client information from the network side.=0A>=0A>=0A>Y= ou can use reconfigure, but that requires authentication (clients MUST disc= ard reconfigure messages that aren't authenticated). I don't know if anyone= actually implements authentication. Also, it requires that the server know= the DUID of the client. How do you do this if the client has never talked = to you before, (e.g., if you booted after the client)? You'd have to have a= ll the DHCPv6 servers on link communicate with each other.=0A>=0A>Also, it'= s not clear to me how you would implement reconfigure in a stateless enviro= nment, since the server doesn't know which clients are still there and not = all clients (none?) implement RFC 4242.=0A>=0A>=0A>For an example of why th= is is useful, consider a homenet. You have two routers on the same link tha= t share state via a routing protocol. Router A is unplugged. Router B knows= this and wants to tell the client "don't use router A as DNS server any mo= re". How do you do this? Using an RA you can just send out a message with a= lifetime of zero. How do you do it with DHCPv6?=0A>=0A>=0A>=0A>=0A>2. DHCP= v6 doesn't support multiple sources of information.=0A>=0A>=0A>In particula= r, stateful DHCPv6 requires that the client choose one of the advertise mes= sages it receives. The spec doesn't prevent it from starting a new transact= ion with a transaction ID, but I don't know what the original server would = do if it received such a message. The RFC doesn't seem to specify this very= well, if at all.=0A>=0A>=0A>=0A>=0A>3. You can do per-client configuration= using RA as well.=0A>=0A>=0A>There's nothing preventing routers from reply= ing to RS packets with unicast RAs, so per-client configuration is possible= . There's also nothing stopping you from causing an RS to trigger a provisi= oning (e.g., radius) request to a server asking for configuration parameter= s for that client - for example, giving it its own VLAN and its own /64. (I= 've built networks that do this, so I know it works). So your "it's not pos= sible to jump" assertion is not entirely true. It's true that RAs can't jum= p by themselves, but the information requests can.=0A>=0A>=0A>=0A>=0A>I'm a= lso don't think the "multicast doesn't work in congested networks" argument= is valid. In a network where multicast is so overloaded that it's complete= ly broken, it's not just RAs that will fail. NSes will get dropped too; MDN= S won't work; basically, the network is broken. That said, unicast RAs don'= t have this problem.=0A>=0A>=0A>I'd be happy to contribute to a draft docum= enting these issues. Andrew, were you going to start one?=0A>=0A>=0A>=0A>On= Tue, Oct 29, 2013 at 4:17 AM, Andrew Yourtchenko wrot= e:=0A>=0A>On Thu, 24 Oct 2013, Ted Lemon wrote:=0A>>=0A>>=0A>>Anyway, that'= s the rhetorical position I'm going to stake out for now. I'm curious to se= e if anybody can come up with a reason to disagree that doesn't simplify to= either "I hate RA" or "I hate DHCP."=0A>>>=0A>>=0AI'll take a shot at outl= ining the differences as I see them between the two, and the factors that m= ay influence the "I hate RA" or "I hate DHCP" reply in each particular case= ...=0A>>=0A>>1) Interworking with different L2 topologies=0A>>=0A>>RA is "s= erver-initiated, send once, receive many, no confirmation" abstraction - so= mething that works well on the 10base2-type shared bus and even the today's= wired ethernet, but looks quite miserable on the WiFi media without the ug= ly special tricks (802.11 provides reliable delivery for unicast frames, an= d does not provide one for multicast frames, also the physical speeds are d= ifferent and even the contention management and the speed/modulation can be= different as well).=0A>>=0A>>DHCPv6 is "client-initiated, send once, recei= ve once, confirmation" abstraction. This may be wasteful on the low-bandwid= th links that provide bus topology, but maps extremely well onto scenarios = like WiFi - as it allows to maintain somewhat familiar mode of operation to= wired ethernet.=0A>>=0A>>This is where the p2p, acknowledged nature of DHC= Pv6 may be beneficial - on a crowded large-scale WiFi, without dirty tricks= , you simply will not get the SLAAC working because the multicast RAs will = get crunched by the interference.=0A>>=0A>>Alternatively, in a very mobile = environment and the RFC-compliant router, multicast solicited RAs might mak= e a significant portion of your traffic - which, due to a difference in mod= ulation, etc. may eat way more bandwidth than if they were sent unicast.=0A= >>=0A>>2) Acknowledged vs. unacknowledged=0A>>=0A>>DHCPv6 needs at least 2 = packets. RA is just one packet.=0A>>=0A>>RA Plus: RA is quicker=0A>>=0A>>RA= Minus: you have to take care that it is legitimate router and not your evi= l neighbor sending you the RAs you take the configuration from.=0A>>=0A>>DH= CPv6 Plus: works well in the noisy/lossy environments=0A>>=0A>>DHCPv6 minus= : takes at least 1 RTT to the server.=0A>>=0A>>=0A>>3) Client initiated vs.= server initiated=0A>>=0A>>Despite of the division above, RA can be client-= initiated, to some extent, with RS, and DHCPv6 can be server-initiated, to = some extent, with "Reconfigure" messages.=0A>>=0A>>If we treat these as "nu= dge" messages, the behavior of the sending and receiving parties is similar= - the "nudge" message causes the orderly protocol exchange to occur before= the due time.=0A>>=0A>>The part that is different, though, is that RA, due= to its "send once, receive many" nature, can aggregate the "nudge" message= s, so intuitively seems best for a scenario with a very large number of the= hosts, as it should have self-stabilizing properties, compared to DHCPv6.= =0A>>=0A>>This "self-stabilizing" property intuitively seems to make RA saf= er to use, IFF it is used in purely "multicast" fashion.=0A>>However, refer= to (1) for the interaction with the underlying media.=0A>>=0A>>4) Centrali= zed coordination vs. distributed coordination=0A>>=0A>>RA, due to its "send= once, receive many" nature, in its pure form necessarily can not dictate a= per-client settings, but rather can only advise the domain the client woul= d pick from (SLAAC).=0A>>=0A>>DHCPv6 on the other hand, due to its p2p natu= re is by default well suited for the individual per-client tweaking.=0A>>= =0A>>The distributed nature can be a blessing if you do not care about who = gets which address and a curse if you need to account everyone strictly.=0A= >>=0A>>NB: address assignment does not mean that the hosts will always use = those addresses - e.g. it's perfectly possible to statically configure a di= fferent address, but we talk just homogenous standards-compliant well-behav= ed hosts for simplicity sake).=0A>>=0A>>That's why I do not use the word "c= ontrol" but use the word "coordination".=0A>>=0A>>5) Involvement or not int= o routing=0A>>=0A>>RAs are a mechanism to provide some form of reliability = for the routing in an independent fashion to the reasonably unsophisticated= hosts. DHCPv6 was specifically denied any involvement in the routing.=0A>>= =0A>>While architecturally "pure", the reliability and timing of the routin= g resiliency provided by the RAs is far below those achieved by FHRP protoc= ols which are used in today's networks predominantly.=0A>>=0A>>This might c= reate a dissonance between those who want to ensure RAs are used for routin= g, and those who do not see any use of them in that regard - with the corre= sponding contention of adding anything routing-related into DHCPv6.=0A>>=0A= >>=0A>>6) Server locality=0A>>=0A>>Both DHCPv6 and RA are inherently link-l= ocal mechanisms, however DHCPv6 has a means to "jump" over multiple hops by= use of the relays. This means RA *has* to be distributed, while DHCPv6 can= be both centralized and distributed. Frequently it is made centralized bec= ause of other benefits that centralized administration brings, but almost a= ny router today can run a DHCPv6 server on the box with no problem.=0A>>=0A= >>7) Programming: UDP vs. ICMP=0A>>=0A>>For a random programmer today, codi= ng a server to receive the data on a UDP socket is a more familiar exercise= than working with ICMP. Disclaimer: the value of "random" was chosen to be= "me" for arbitrary reasons. This point is more of a rathole and a personal= preference, probably. I think I remember Dave Thaler saying one of the mec= hanisms in Windows was way easier to extend than the other, but I do not re= member which.=0A>>=0A>>8) Separate vs. unified management=0A>>=0A>>If DHCPv= 4 and routing is managed by the different groups in the organization, then = conceivably the "server" people will not like to have their work go away an= d similarly "router" guys are happy to get rid of yet another point of coor= dination and argument. This is where the "I hate $protocol" should definite= ly pop up. Add here the concerns from the previous 7 points.=0A>>=0A>>HTH.= =0A>>=0A>>=0A>>--a=0A>>=0A>>_______________________________________________= =0A>>v6ops mailing list=0A>>v6ops@ietf.org=0A>>https://www.ietf.org/mailman= /listinfo/v6ops=0A>>=0A>=0A>=0A>___________________________________________= ____=0A>v6ops mailing list=0A>v6ops@ietf.org=0A>https://www.ietf.org/mailma= n/listinfo/v6ops=0A>=0A>=0A> From alexandru.petrescu@gmail.com Tue Oct 29 06:04:02 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CA23B11E8244 for ; Tue, 29 Oct 2013 06:04:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.282 X-Spam-Level: X-Spam-Status: No, score=-10.282 tagged_above=-999 required=5 tests=[AWL=-0.033, BAYES_00=-2.599, HELO_EQ_FR=0.35, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7ZhjI6BJjdfV for ; Tue, 29 Oct 2013 06:03:57 -0700 (PDT) Received: from sainfoin-out.extra.cea.fr (sainfoin-out.extra.cea.fr [132.167.192.145]) by ietfa.amsl.com (Postfix) with ESMTP id 189FB11E8239 for ; Tue, 29 Oct 2013 06:03: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.3) with ESMTP id r9TD3tYn030005 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Tue, 29 Oct 2013 14:03:55 +0100 Received: from muguet1.intra.cea.fr (muguet1.intra.cea.fr [132.166.192.6]) by pisaure.intra.cea.fr (8.14.4/8.14.4) with ESMTP id r9TD3tnw020001; Tue, 29 Oct 2013 14:03:55 +0100 (envelope-from alexandru.petrescu@gmail.com) Received: from [127.0.0.1] (is010446-4.intra.cea.fr [10.8.33.116]) by muguet1.intra.cea.fr (8.13.8/8.13.8/CEAnet-Intranet-out-1.2) with ESMTP id r9TD3ngB017794; Tue, 29 Oct 2013 14:03:55 +0100 Message-ID: <526FB236.3090106@gmail.com> Date: Tue, 29 Oct 2013 14:03:50 +0100 From: Alexandru Petrescu User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:24.0) Gecko/20100101 Thunderbird/24.0.1 MIME-Version: 1.0 To: Gert Doering References: <06601039-CAFD-49B0-918B-A8ACD51B978D@fugue.com> <526D17A5.9050804@cernet.edu.cn> <526D18F2.8040103@cernet.edu.cn> <20131027145224.GT50205@Space.Net> <526D9FFC.9060307@cernet.edu.cn> <526E7FCA.60702@gmail.com> <20131028161219.GQ50205@Space.Net> In-Reply-To: <20131028161219.GQ50205@Space.Net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Cc: v6ops@ietf.org Subject: Re: [v6ops] DHCPv6/SLAAC Make Hosts Confusing-//RE: new draft: draft-liu-bonica-v6ops-dhcpv6-slaac-problem X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 29 Oct 2013 13:04:02 -0000 Le 28/10/2013 17:12, Gert Doering a écrit : > Hi, > > On Mon, Oct 28, 2013 at 04:16:26PM +0100, Alexandru Petrescu wrote: >> I thought the goal was to not modify RA, whereas the above does >> modify the RA to include a DNS resolver. > > Uh. *That* train has sailed 6 years ago with RFC5006... Right. But in this thread some say we should no longer do DHCP-typical-info in the RA, and at the same time they propose to do it, provided the backend info comes from a DHCP server. Hence my question about whether a delegated prefix (another DHCP-typical-info) would be ok for this concept. (I author an earlier draft in this space). >> If yes, would it be ok to include a Prefix Delegation option as >> well in the RA? (not an RFC4191 option, but a new Prefix Delegation >> option pasted from DHCPv6 Prefix Delegation). > > What use would that be? The benefit of RA is that "everyone can see > them and the information contained applies to *all* consumers, and is > periodically refreshed without having to poll". PD is, by > definition, very specific to the device where you delegate to... I tend to agree that RA's content is generally valid for everyone receiving that RA, and that typically RAs are multicasted to all nodes on a link. However, there are some specific cases where the RA is unicast to particular nodes and contain information specific to that node. For example in Proxy Mobile IPv6 RFC5213 an access router sends an RA to a particular mobile host attaching to it, and it puts inside a prefix to make believe that particular node to be at its home. Each node has a different home prefix. Another example is in Fast Mobile IPv6 protocol RFC4068 where a Proxy RA contains an address specific to a mobile. A more remote example is that of RPL RFC6550 which uses a new ICMP message 'RPL Control Message' remotely similar to RA, and whose destination is unicast. Apart from that, the use case I am considering is fast exchanges of IP messages to establish quickly short-lived communications (10ms IP establishment address/defroute, and app-layer communications during a few minutes). Used in vehicular communications. A vehicle containing a cellular link (SIM subscription) may offer Internet connectivity to a SIM-less vehicle nearby - mobile billboard vehicle, like in this figure http://en.wikipedia.org/wiki/File:MSNBC_mobile_billboard_at_Union_Station.jpg (check the "Free WiFi" banner). Alex > > This thread is full of weirdness. > > Gert Doering -- NetMaster > From ayourtch@cisco.com Tue Oct 29 06:37:18 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1DBA411E823D for ; Tue, 29 Oct 2013 06:37:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.999 X-Spam-Level: X-Spam-Status: No, score=-9.999 tagged_above=-999 required=5 tests=[AWL=-0.600, BAYES_00=-2.599, J_CHICKENPOX_13=0.6, J_CHICKENPOX_33=0.6, 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 TnBFCK2ETrMA for ; Tue, 29 Oct 2013 06:37:13 -0700 (PDT) Received: from rcdn-iport-7.cisco.com (rcdn-iport-7.cisco.com [173.37.86.78]) by ietfa.amsl.com (Postfix) with ESMTP id 4BFEB21F9EC8 for ; Tue, 29 Oct 2013 06:37:04 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=11235; q=dns/txt; s=iport; t=1383053825; x=1384263425; h=date:from:to:cc:subject:in-reply-to:message-id: references:mime-version; bh=B6b9Dcj/CFFNsqlf+IDLrQC6MK3i/v5PRr25TNUdvfo=; b=HWNis5ZBYTIEgHoMN015wbER7iqu7z48qJ6m2VjtyuAVBOQeusbQeG27 K1DaL4NcGAr2IG9D77rRijInREncg1S94ST2f8FiigBdhn3wR/vNKmCTc oTwujX84fzHRup69b8jq22Sk2FtAP6220Ko3GV0uVyfHsPhfACuMivIKD I=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AhAFAJS5b1KtJV2d/2dsb2JhbABZgwc4VL8xgSgWdIIlAQEBAwEBAQE1AjQLBQsLGBUOCyciAQ0GDgUZh2gGDblXBI9HBwqEIgOeRotMgWiBP4Ip X-IronPort-AV: E=Sophos;i="4.93,593,1378857600"; d="scan'208";a="277977506" Received: from rcdn-core-6.cisco.com ([173.37.93.157]) by rcdn-iport-7.cisco.com with ESMTP; 29 Oct 2013 13:37:04 +0000 Received: from xhc-rcd-x09.cisco.com (xhc-rcd-x09.cisco.com [173.37.183.83]) by rcdn-core-6.cisco.com (8.14.5/8.14.5) with ESMTP id r9TDb39m018978 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 29 Oct 2013 13:37:03 GMT Received: from [10.61.170.92] (10.61.170.92) by xhc-rcd-x09.cisco.com (173.37.183.83) with Microsoft SMTP Server (TLS) id 14.2.318.4; Tue, 29 Oct 2013 08:37:02 -0500 Date: Tue, 29 Oct 2013 14:36:43 +0100 From: Andrew Yourtchenko X-X-Sender: ayourtch@ayourtch-mac To: Lorenzo Colitti In-Reply-To: Message-ID: References: <06601039-CAFD-49B0-918B-A8ACD51B978D@fugue.com> User-Agent: Alpine 2.00 (OSX 1167 2008-08-23) MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII"; format=flowed X-Originating-IP: [10.61.170.92] Cc: "draft-liu-bonica-v6ops-dhcpv6-slaac-problem@tools.ietf.org" , "v6ops@ietf.org" , Ted Lemon , "Ole Troan \(otroan\)" , Dave Thaler Subject: Re: [v6ops] DHCPv6/SLAAC Make Hosts Confusing-//RE: new draft: draft-liu-bonica-v6ops-dhcpv6-slaac-problem X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 29 Oct 2013 13:37:18 -0000 Ted, Lorenzo, Given the submission tool is for now closed, I've whipped up the xml+txt and a git repo and put it onto https://github.com/ayourtch/ra-dhcpv6/ I also tried to express/generalize Lorenzo's points below and put them into a separate new sections. More inline.. On Tue, 29 Oct 2013, Lorenzo Colitti wrote: > Andrew, those are good points, though from the perspective of protocol design I think semantics and functionality are a bit more important than performance. Once you have the semantics > right you can look at improving performance (e.g., via QoS, prioritization, queue isolation, etc. etc.), but if the semantics are wrong it's hard to fix that. > So, semantics I think you forgot: > 1. DHCPv6 makes it very hard to update client information from the network side. > > You can use reconfigure, but that requires authentication (clients MUST discard reconfigure messages that aren't authenticated). I don't know if anyone actually implements > authentication. Agreed. This is something that needs testing. > Also, it requires that the server know the DUID of the client. How do you > do this if the client has never talked to you before, (e.g., if you > booted after the client)? > You'd have to have all the DHCPv6 servers on link communicate with each other. Yes, you will need some form of redundancy, and means you can not be fully "stateless". But if we are going the road of extending things, we might come up with a multicast RECONFIGURE message, which would specify the time interval within which the clients should come back and report their DUID. I can't argue too hard on this one because I never tested this in real life. > > Also, it's not clear to me how you would implement reconfigure in a stateless environment, since the server doesn't know which clients are still there and not all clients (none?) > implement RFC 4242. > > For an example of why this is useful, consider a homenet. You have two routers on the same link that share state via a routing protocol. Router A is unplugged. Router B knows this and > wants to tell the client "don't use router A as DNS server any more". How do you do this? Using an RA you can just send out a message with a lifetime of zero. How do you do it with > DHCPv6? I agree this is definitely a useful scenario. I've added it under a new section "Single Source of Truth vs. Multiple sources". > > > 2. DHCPv6 doesn't support multiple sources of information. > > In particular, stateful DHCPv6 requires that the client choose one of the advertise messages it receives. The spec doesn't prevent it from starting a new transaction with a transaction > ID, but I don't know what the original server would do if it received such a message. The RFC doesn't seem to specify this very well, if at all. > I think this is conceptually, again, "single source of truth" problem. > > 3. You can do per-client configuration using RA as well. > > There's nothing preventing routers from replying to RS packets with unicast RAs, so per-client configuration is possible. There's also nothing stopping you from causing an RS to trigger > a provisioning (e.g., radius) request to a server asking for configuration parameters for that client - for example, giving it its own VLAN and its own /64. (I've built networks that do > this, so I know it works). So your "it's not possible to jump" assertion is not entirely true. It's true that RAs can't jump by themselves, but the information requests can. > yeah. I did not go into this in my write-up, but it is entirely possible to morph RA so it becomes some kind of DHCPv6, and it is likewise possible to morph DHCPv6 so it becomes some kind of RA. To some extent, you can do it without the host modifications. Full conversion of either would require host mods. This was beyond what I aimed for - merely a comparison of the protocols 'as is'. > > I'm also don't think the "multicast doesn't work in congested networks" argument is valid. In a network where multicast is so overloaded that it's completely broken, it's not just RAs > that will fail. NSes will get dropped too; MDNS won't work; basically, the network is broken. That said, unicast RAs don't have this problem. IPv4 does not have this problem. your DHCPv4 will complete. After a minute, but it will complete. Your client has only one ARP entry (default gateway). The connectivity sucks big time, but it survives. Contrary to that, in IPv6 the very first RS is lost and if the client is not persistent enough, this is where it ends (Hoping the hosts get draft-ietf-6man-resilient-rs implemented so it is less of a problem) > > I'd be happy to contribute to a draft documenting these issues. Andrew, were you going to start one? > Sure, github above. feel free to clone/edit/send pull requests :) --a > > On Tue, Oct 29, 2013 at 4:17 AM, Andrew Yourtchenko wrote: > On Thu, 24 Oct 2013, Ted Lemon wrote: > > Anyway, that's the rhetorical position I'm going to stake out for now. I'm curious to see if anybody can come up with a reason to disagree that doesn't simplify > to either "I hate RA" or "I hate DHCP." > > > I'll take a shot at outlining the differences as I see them between the two, and the factors that may influence the "I hate RA" or "I hate DHCP" reply in each particular case... > > 1) Interworking with different L2 topologies > > RA is "server-initiated, send once, receive many, no confirmation" abstraction - something that works well on the 10base2-type shared bus and even the today's wired ethernet, but > looks quite miserable on the WiFi media without the ugly special tricks (802.11 provides reliable delivery for unicast frames, and does not provide one for multicast frames, also > the physical speeds are different and even the contention management and the speed/modulation can be different as well). > > DHCPv6 is "client-initiated, send once, receive once, confirmation" abstraction. This may be wasteful on the low-bandwidth links that provide bus topology, but maps extremely well > onto scenarios like WiFi - as it allows to maintain somewhat familiar mode of operation to wired ethernet. > > This is where the p2p, acknowledged nature of DHCPv6 may be beneficial - on a crowded large-scale WiFi, without dirty tricks, you simply will not get the SLAAC working because the > multicast RAs will get crunched by the interference. > > Alternatively, in a very mobile environment and the RFC-compliant router, multicast solicited RAs might make a significant portion of your traffic - which, due to a difference in > modulation, etc. may eat way more bandwidth than if they were sent unicast. > > 2) Acknowledged vs. unacknowledged > > DHCPv6 needs at least 2 packets. RA is just one packet. > > RA Plus: RA is quicker > > RA Minus: you have to take care that it is legitimate router and not your evil neighbor sending you the RAs you take the configuration from. > > DHCPv6 Plus: works well in the noisy/lossy environments > > DHCPv6 minus: takes at least 1 RTT to the server. > > > 3) Client initiated vs. server initiated > > Despite of the division above, RA can be client-initiated, to some extent, with RS, and DHCPv6 can be server-initiated, to some extent, with "Reconfigure" messages. > > If we treat these as "nudge" messages, the behavior of the sending and receiving parties is similar - the "nudge" message causes the orderly protocol exchange to occur before the > due time. > > The part that is different, though, is that RA, due to its "send once, receive many" nature, can aggregate the "nudge" messages, so intuitively seems best for a scenario with a > very large number of the hosts, as it should have self-stabilizing properties, compared to DHCPv6. > > This "self-stabilizing" property intuitively seems to make RA safer to use, IFF it is used in purely "multicast" fashion. > However, refer to (1) for the interaction with the underlying media. > > 4) Centralized coordination vs. distributed coordination > > RA, due to its "send once, receive many" nature, in its pure form necessarily can not dictate a per-client settings, but rather can only advise the domain the client would pick > from (SLAAC). > > DHCPv6 on the other hand, due to its p2p nature is by default well suited for the individual per-client tweaking. > > The distributed nature can be a blessing if you do not care about who gets which address and a curse if you need to account everyone strictly. > > NB: address assignment does not mean that the hosts will always use those addresses - e.g. it's perfectly possible to statically configure a different address, but we talk just > homogenous standards-compliant well-behaved hosts for simplicity sake). > > That's why I do not use the word "control" but use the word "coordination". > > 5) Involvement or not into routing > > RAs are a mechanism to provide some form of reliability for the routing in an independent fashion to the reasonably unsophisticated hosts. DHCPv6 was specifically denied any > involvement in the routing. > > While architecturally "pure", the reliability and timing of the routing resiliency provided by the RAs is far below those achieved by FHRP protocols which are used in today's > networks predominantly. > > This might create a dissonance between those who want to ensure RAs are used for routing, and those who do not see any use of them in that regard - with the corresponding > contention of adding anything routing-related into DHCPv6. > > > 6) Server locality > > Both DHCPv6 and RA are inherently link-local mechanisms, however DHCPv6 has a means to "jump" over multiple hops by use of the relays. This means RA *has* to be distributed, while > DHCPv6 can be both centralized and distributed. Frequently it is made centralized because of other benefits that centralized administration brings, but almost any router today can > run a DHCPv6 server on the box with no problem. > > 7) Programming: UDP vs. ICMP > > For a random programmer today, coding a server to receive the data on a UDP socket is a more familiar exercise than working with ICMP. Disclaimer: the value of "random" was chosen > to be "me" for arbitrary reasons. This point is more of a rathole and a personal preference, probably. I think I remember Dave Thaler saying one of the mechanisms in Windows was > way easier to extend than the other, but I do not remember which. > > 8) Separate vs. unified management > > If DHCPv4 and routing is managed by the different groups in the organization, then conceivably the "server" people will not like to have their work go away and similarly "router" > guys are happy to get rid of yet another point of coordination and argument. This is where the "I hate $protocol" should definitely pop up. Add here the concerns from the previous > 7 points. > > HTH. > > > --a > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops > > > > From ayourtch@cisco.com Tue Oct 29 07:05:53 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 976D911E8258 for ; Tue, 29 Oct 2013 07:05:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.999 X-Spam-Level: X-Spam-Status: No, score=-9.999 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_13=0.6, 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 i5x9TkHatiRx for ; Tue, 29 Oct 2013 07:05:48 -0700 (PDT) Received: from rcdn-iport-6.cisco.com (rcdn-iport-6.cisco.com [173.37.86.77]) by ietfa.amsl.com (Postfix) with ESMTP id BA0CA11E8251 for ; Tue, 29 Oct 2013 07:05:40 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=13136; q=dns/txt; s=iport; t=1383055540; x=1384265140; h=date:from:to:cc:subject:in-reply-to:message-id: references:mime-version; bh=T7GFe/7Aoh0mrWDG9RRmAVaTF3kDcHPVxXBgjMUGEq4=; b=Lq6DxFD5Ev9X6M56WT+vAlcPrqLAquwFCWkr2PuwbGwZX8b+LFM38Qo+ Bvqm6DUr2hGOUBbHL9rRP90YHFponN9IptUCNlgAgCc6dgyFHyR+YttJ7 slyGVxtj1qJDTkTCFkorlOD9cj0UYe4WwbSz5wPHF9P2bEB0GKA6t7K7G s=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AuwLACrAb1KtJXHB/2dsb2JhbABZgwc4VKpNA5RlgSkWdIIlAQEBAwEBAQFrCwULCxEEAQEBFQ4LJyIBBQgGCgQFGYdoBg25cY9HBwYEhCIDiQeQMoUNi0yBaIE/gik X-IronPort-AV: E=Sophos;i="4.93,593,1378857600"; d="scan'208";a="278018171" Received: from rcdn-core2-6.cisco.com ([173.37.113.193]) by rcdn-iport-6.cisco.com with ESMTP; 29 Oct 2013 14:05:39 +0000 Received: from xhc-rcd-x09.cisco.com (xhc-rcd-x09.cisco.com [173.37.183.83]) by rcdn-core2-6.cisco.com (8.14.5/8.14.5) with ESMTP id r9TE5dBY029146 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 29 Oct 2013 14:05:39 GMT Received: from [10.61.170.92] (10.61.170.92) by xhc-rcd-x09.cisco.com (173.37.183.83) with Microsoft SMTP Server (TLS) id 14.2.318.4; Tue, 29 Oct 2013 09:05:38 -0500 Date: Tue, 29 Oct 2013 15:05:19 +0100 From: Andrew Yourtchenko X-X-Sender: ayourtch@ayourtch-mac To: Mark ZZZ Smith In-Reply-To: <1383036443.56704.YahooMailNeo@web142501.mail.bf1.yahoo.com> Message-ID: References: <06601039-CAFD-49B0-918B-A8ACD51B978D@fugue.com> <1383036443.56704.YahooMailNeo@web142501.mail.bf1.yahoo.com> User-Agent: Alpine 2.00 (OSX 1167 2008-08-23) MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="0-587510315-1383055539=:31066" X-Originating-IP: [10.61.170.92] Cc: "v6ops@ietf.org" , Ted Lemon , "Ole Troan \(otroan\)" , Dave Thaler , "draft-liu-bonica-v6ops-dhcpv6-slaac-problem@tools.ietf.org" Subject: Re: [v6ops] DHCPv6/SLAAC Make Hosts Confusing-//RE: new draft: draft-liu-bonica-v6ops-dhcpv6-slaac-problem X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 29 Oct 2013 14:05:53 -0000 --0-587510315-1383055539=:31066 Content-Type: text/plain; charset="iso-8859-1"; format=flowed Content-Transfer-Encoding: 8BIT Hi, On Tue, 29 Oct 2013, Mark ZZZ Smith wrote: > Hi, > > A few other points: > > - Rogue DHCPv6 servers are also a potential issue, so this sort of problem isn't exclusive to RAs. Good point, agree. > > - DHCPv6 uses multicast for Information-Request messages for stateless DHCPv6 service and Solicit messages for stateful DHCPv6 service, so a link suffering from excessive multicast traffic drops may also prevent DHCPv6 working reliably or quickly. > > I'm a bit confused by "something that works well on the 10base2-type >shared bus and even the today's wired ethernet, but looks quite miserable >on the WiFi media without the ugly special tricks". My understanding is >that Internet protocols of all types are to be designed with the >assumption of the possibility of a low level of packet loss. If the >packet loss is too high, then link-layer designers are advised to use >link-layer reliability mechanisms, as per advised in RFC3819. I'm >interested in details of the "ugly special tricks" if they're more than >proprietary wifi link-layer multicast reliability mechanisms. I removed the word "ugly", it should not have been there, my apologies. "advised" != "real life". 802.11-2002, page 842, which discusses the individual and group-addressed MPDU transfer procedure. So, yes, the loss for mcast can be significantly higher than for unicast, which means loss of the periodic RAs and unreliable and hard to troubleshoot sporadic failures on the clients. The ugly^H^H^H^H tricks indeed involve unicasting the multicast traffic at link layer. > > General lack of Wifi multicast performance is the motive behind the >following draft - replication and link-layer unicasting of unsolicited >RAs could be used on Wifi to make them more reliable. > > MLDv2 Procedures for Link-Layer Unicast Delivery of Multicast IPv6 > http://tools.ietf.org/html/draft-smith-mldv2-link-unicast-00 > hm. Interesting idea. Although it adds a new (and big) requirement into the First Hop Security - to track and enforce the behavior of hosts to this regard. Tricky. > > > - "While architecturally "pure", the reliability and timing of the >routing resiliency provided by the RAs is far below those achieved by >FHRP protocols which are used in today's networks predominantly." This >seems to suggest that you can't run VRRP/HSRP if you're using RAs. I >don't think they're mutually exclusive, as long as the RAs come from the >virtual router link-local address, rather than the routers' physical >interface link-local addresses. No, this is a long-winded way to say that RA as a routing mechanism is useless a lot of today's networks' requirements, not that it is incompatible. :-) --a > > Regards, > Mark. > > >> ________________________________ >> From: Lorenzo Colitti >> To: Andrew Yourtchenko >> Cc: "draft-liu-bonica-v6ops-dhcpv6-slaac-problem@tools.ietf.org" ; "v6ops@ietf.org" ; Ted Lemon ; Ole Troan (otroan) ; Dave Thaler >> Sent: Tuesday, 29 October 2013 3:53 PM >> Subject: Re: [v6ops] DHCPv6/SLAAC Make Hosts Confusing-//RE: new draft:    draft-liu-bonica-v6ops-dhcpv6-slaac-problem >> >> >> >> Andrew, those are good points, though from the perspective of protocol design I think semantics and functionality are a bit more important than performance. Once you have the semantics right you can look at improving performance (e.g., via QoS, prioritization, queue isolation, etc. etc.), but if the semantics are wrong it's hard to fix that. >> >> >> So, semantics I think you forgot: >> >> >> 1. DHCPv6 makes it very hard to update client information from the network side. >> >> >> You can use reconfigure, but that requires authentication (clients MUST discard reconfigure messages that aren't authenticated). I don't know if anyone actually implements authentication. Also, it requires that the server know the DUID of the client. How do you do this if the client has never talked to you before, (e.g., if you booted after the client)? You'd have to have all the DHCPv6 servers on link communicate with each other. >> >> Also, it's not clear to me how you would implement reconfigure in a stateless environment, since the server doesn't know which clients are still there and not all clients (none?) implement RFC 4242. >> >> >> For an example of why this is useful, consider a homenet. You have two routers on the same link that share state via a routing protocol. Router A is unplugged. Router B knows this and wants to tell the client "don't use router A as DNS server any more". How do you do this? Using an RA you can just send out a message with a lifetime of zero. How do you do it with DHCPv6? >> >> >> >> >> 2. DHCPv6 doesn't support multiple sources of information. >> >> >> In particular, stateful DHCPv6 requires that the client choose one of the advertise messages it receives. The spec doesn't prevent it from starting a new transaction with a transaction ID, but I don't know what the original server would do if it received such a message. The RFC doesn't seem to specify this very well, if at all. >> >> >> >> >> 3. You can do per-client configuration using RA as well. >> >> >> There's nothing preventing routers from replying to RS packets with unicast RAs, so per-client configuration is possible. There's also nothing stopping you from causing an RS to trigger a provisioning (e.g., radius) request to a server asking for configuration parameters for that client - for example, giving it its own VLAN and its own /64. (I've built networks that do this, so I know it works). So your "it's not possible to jump" assertion is not entirely true. It's true that RAs can't jump by themselves, but the information requests can. >> >> >> >> >> I'm also don't think the "multicast doesn't work in congested networks" argument is valid. In a network where multicast is so overloaded that it's completely broken, it's not just RAs that will fail. NSes will get dropped too; MDNS won't work; basically, the network is broken. That said, unicast RAs don't have this problem. >> >> >> I'd be happy to contribute to a draft documenting these issues. Andrew, were you going to start one? >> >> >> >> On Tue, Oct 29, 2013 at 4:17 AM, Andrew Yourtchenko wrote: >> >> On Thu, 24 Oct 2013, Ted Lemon wrote: >>> >>> >>> Anyway, that's the rhetorical position I'm going to stake out for now. I'm curious to see if anybody can come up with a reason to disagree that doesn't simplify to either "I hate RA" or "I hate DHCP." >>>> >>> > I'll take a shot at outlining the differences as I see them between the two, and the factors that may influence the "I hate RA" or "I hate DHCP" reply in each particular case... >>> >>> 1) Interworking with different L2 topologies >>> >>> RA is "server-initiated, send once, receive many, no confirmation" abstraction - something that works well on the 10base2-type shared bus and even the today's wired ethernet, but looks quite miserable on the WiFi media without the ugly special tricks (802.11 provides reliable delivery for unicast frames, and does not provide one for multicast frames, also the physical speeds are different and even the contention management and the speed/modulation can be different as well). >>> >>> DHCPv6 is "client-initiated, send once, receive once, confirmation" abstraction. This may be wasteful on the low-bandwidth links that provide bus topology, but maps extremely well onto scenarios like WiFi - as it allows to maintain somewhat familiar mode of operation to wired ethernet. >>> >>> This is where the p2p, acknowledged nature of DHCPv6 may be beneficial - on a crowded large-scale WiFi, without dirty tricks, you simply will not get the SLAAC working because the multicast RAs will get crunched by the interference. >>> >>> Alternatively, in a very mobile environment and the RFC-compliant router, multicast solicited RAs might make a significant portion of your traffic - which, due to a difference in modulation, etc. may eat way more bandwidth than if they were sent unicast. >>> >>> 2) Acknowledged vs. unacknowledged >>> >>> DHCPv6 needs at least 2 packets. RA is just one packet. >>> >>> RA Plus: RA is quicker >>> >>> RA Minus: you have to take care that it is legitimate router and not your evil neighbor sending you the RAs you take the configuration from. >>> >>> DHCPv6 Plus: works well in the noisy/lossy environments >>> >>> DHCPv6 minus: takes at least 1 RTT to the server. >>> >>> >>> 3) Client initiated vs. server initiated >>> >>> Despite of the division above, RA can be client-initiated, to some extent, with RS, and DHCPv6 can be server-initiated, to some extent, with "Reconfigure" messages. >>> >>> If we treat these as "nudge" messages, the behavior of the sending and receiving parties is similar - the "nudge" message causes the orderly protocol exchange to occur before the due time. >>> >>> The part that is different, though, is that RA, due to its "send once, receive many" nature, can aggregate the "nudge" messages, so intuitively seems best for a scenario with a very large number of the hosts, as it should have self-stabilizing properties, compared to DHCPv6. >>> >>> This "self-stabilizing" property intuitively seems to make RA safer to use, IFF it is used in purely "multicast" fashion. >>> However, refer to (1) for the interaction with the underlying media. >>> >>> 4) Centralized coordination vs. distributed coordination >>> >>> RA, due to its "send once, receive many" nature, in its pure form necessarily can not dictate a per-client settings, but rather can only advise the domain the client would pick from (SLAAC). >>> >>> DHCPv6 on the other hand, due to its p2p nature is by default well suited for the individual per-client tweaking. >>> >>> The distributed nature can be a blessing if you do not care about who gets which address and a curse if you need to account everyone strictly. >>> >>> NB: address assignment does not mean that the hosts will always use those addresses - e.g. it's perfectly possible to statically configure a different address, but we talk just homogenous standards-compliant well-behaved hosts for simplicity sake). >>> >>> That's why I do not use the word "control" but use the word "coordination". >>> >>> 5) Involvement or not into routing >>> >>> RAs are a mechanism to provide some form of reliability for the routing in an independent fashion to the reasonably unsophisticated hosts. DHCPv6 was specifically denied any involvement in the routing. >>> >>> While architecturally "pure", the reliability and timing of the routing resiliency provided by the RAs is far below those achieved by FHRP protocols which are used in today's networks predominantly. >>> >>> This might create a dissonance between those who want to ensure RAs are used for routing, and those who do not see any use of them in that regard - with the corresponding contention of adding anything routing-related into DHCPv6. >>> >>> >>> 6) Server locality >>> >>> Both DHCPv6 and RA are inherently link-local mechanisms, however DHCPv6 has a means to "jump" over multiple hops by use of the relays. This means RA *has* to be distributed, while DHCPv6 can be both centralized and distributed. Frequently it is made centralized because of other benefits that centralized administration brings, but almost any router today can run a DHCPv6 server on the box with no problem. >>> >>> 7) Programming: UDP vs. ICMP >>> >>> For a random programmer today, coding a server to receive the data on a UDP socket is a more familiar exercise than working with ICMP. Disclaimer: the value of "random" was chosen to be "me" for arbitrary reasons. This point is more of a rathole and a personal preference, probably. I think I remember Dave Thaler saying one of the mechanisms in Windows was way easier to extend than the other, but I do not remember which. >>> >>> 8) Separate vs. unified management >>> >>> If DHCPv4 and routing is managed by the different groups in the organization, then conceivably the "server" people will not like to have their work go away and similarly "router" guys are happy to get rid of yet another point of coordination and argument. This is where the "I hate $protocol" should definitely pop up. Add here the concerns from the previous 7 points. >>> >>> HTH. >>> >>> >>> --a >>> >>> _______________________________________________ >>> v6ops mailing list >>> v6ops@ietf.org >>> https://www.ietf.org/mailman/listinfo/v6ops >>> >> >> >> _______________________________________________ >> v6ops mailing list >> v6ops@ietf.org >> https://www.ietf.org/mailman/listinfo/v6ops >> >> >> > --0-587510315-1383055539=:31066-- From jason.weil@twcable.com Tue Oct 29 07:50:34 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4B26111E82CD for ; Tue, 29 Oct 2013 07:50:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.463 X-Spam-Level: X-Spam-Status: No, score=-0.463 tagged_above=-999 required=5 tests=[AWL=0.001, BAYES_00=-2.599, HELO_EQ_MODEMCABLE=0.768, HOST_EQ_MODEMCABLE=1.368] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id h0XqcmLtic+2 for ; Tue, 29 Oct 2013 07:50:30 -0700 (PDT) Received: from cdpipgw02.twcable.com (cdpipgw02.twcable.com [165.237.59.23]) by ietfa.amsl.com (Postfix) with ESMTP id A68D321E816A for ; Tue, 29 Oct 2013 07:44:20 -0700 (PDT) X-SENDER-IP: 10.136.163.11 X-SENDER-REPUTATION: None X-IronPort-AV: E=Sophos;i="4.93,593,1378872000"; d="scan'208";a="149280157" Received: from unknown (HELO PRVPEXHUB02.corp.twcable.com) ([10.136.163.11]) by cdpipgw02.twcable.com with ESMTP/TLS/RC4-MD5; 29 Oct 2013 10:43:55 -0400 Received: from PRVPEXVS17.corp.twcable.com ([10.136.163.95]) by PRVPEXHUB02.corp.twcable.com ([10.136.163.11]) with mapi; Tue, 29 Oct 2013 10:44:14 -0400 From: "Weil, Jason" To: "Liubing (Leo)" , Wuyts Carl , "sthaug@nethelp.no" Date: Tue, 29 Oct 2013 10:44:14 -0400 Thread-Topic: [v6ops] DHCPv6/SLAAC Make Hosts Confusing-//RE: new draft: draft-liu-bonica-v6ops-dhcpv6-slaac-problem Thread-Index: Ac7UtVZgvdBgBSxvREe9fxwyKLZfLg== Message-ID: In-Reply-To: <8AE0F17B87264D4CAC7DE0AA6C406F453D7CCAB5@nkgeml506-mbx.china.huawei.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.3.6.130613 acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "v6ops@ietf.org" , "otroan@cisco.com" , "draft-liu-bonica-v6ops-dhcpv6-slaac-problem@tools.ietf.org" Subject: Re: [v6ops] DHCPv6/SLAAC Make Hosts Confusing-//RE: new draft: draft-liu-bonica-v6ops-dhcpv6-slaac-problem X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 29 Oct 2013 14:50:34 -0000 Leo, First I wanted to say this is useful work and I support it. This topic in this email reminds me of an issue that we have run across that might be relevant to your draft: The use case involves a home network whose gateway router sets M=3D1 and A= =3D1 in order to provide DHC and and SLAAC for hosts that do not implement a DHC client. If the DHCPv6 Server is implementing IP assignment using interface-identifier and using the same prefix as advertised in the PIO (assuming the server resides on the router advertising the PIO) with the A bit set, hosts that support SLAAC and a DHCPv6 client could construct the same address using DHC as the one they construct using SLAAC. What is not clear is what hosts should do in this situation. IMO, there is a benefit if hosts that support both SLAAC and DHCPv6 construct the address and prefer the DHC address over the SLAAC address. The benefit is that you reduce the number of active addresses and all hosts end up with a single address per prefix administered in this fashion. Of course if your DHC Server implements another assignment algorithm (e.g. Random) then your hosts that support both may end up with 2 addresses out of the same prefix. Thanks, Jason On 10/23/13 7:19 AM, "Liubing (Leo)" wrote: >> From: Wuyts Carl [mailto:Carl.Wuyts@technicolor.com] >... >> Nevertheless, I can imagine you prefer the dhcpv6 over RA, but I doubt, >> looking at the big number of devices taking part in this these days >>(sensors, >> bulbs, etc) that they will all start supporting dhcpv6 client, not a >>chance I'm >> afraid. >[Bing] Agreed. These lightweight/embed systems might become an important >part of the IPv6 net. ND allows minimal management burden for them. >Beyond address space, in my mind SLAAC is the most obvious advantage >comparing to IPv4. > >Regards, >Bing > >> Thx for feedback >> >> Regs >> Carl >> >> >> >> >> -----Original Message----- >> From: sthaug@nethelp.no [mailto:sthaug@nethelp.no] >> Sent: woensdag 23 oktober 2013 12:25 >> To: Wuyts Carl >> Cc: nick@inex.ie; otroan@cisco.com; markzzzsmith@yahoo.com.au; >> v6ops@ietf.org; >> draft-liu-bonica-v6ops-dhcpv6-slaac-problem@tools.ietf.org >> Subject: Re: [v6ops] DHCPv6/SLAAC Make Hosts Confusing-//RE: new draft: >> draft-liu-bonica-v6ops-dhcpv6-slaac-problem >> >> > To be honest, I haven't kept up with the full exchange on this topic, >>so >> please disregard my question if it is not relative to this discussion. >> > >> > I read below that, if netmask and def gw would be added on handing out >> dhcpv6, "I can finally get rid of RA messages". >> > But what with hosts NOT supporting dhcpv6 client in this case ? I >>might >> be fully wrong, but I cannot imagine it can be 100% enforced upon each >>host >> vendor to include dhcpv6 client support? >> >> It worked for IPv4. Yes, I realize IPv6 is different, and the target >>market is >> different (e.g. light bulbs). >> >> Nevertheless - as an ISP, I am going to require DHCPv6 for dynamic >>address >> customers. I would be very happy if I only needed DHCPv6 and could do >> without RA. (Note RA !=3D ND/NS) >> >> Steinar Haug, AS 2116 >_______________________________________________ >v6ops mailing list >v6ops@ietf.org >https://www.ietf.org/mailman/listinfo/v6ops This E-mail and any of its attachments may contain Time Warner Cable propri= etary information, which is privileged, confidential, or subject to copyrig= ht belonging to Time Warner Cable. This E-mail is intended solely for the u= se of the individual or entity to which it is addressed. If you are not the= intended recipient of this E-mail, you are hereby notified that any dissem= ination, distribution, copying, or action taken in relation to the contents= of and attachments to this E-mail is strictly prohibited and may be unlawf= ul. If you have received this E-mail in error, please notify the sender imm= ediately and permanently delete the original and any copy of this E-mail an= d any printout. From mellon@fugue.com Sun Oct 27 06:42:47 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 671B821F9FD6 for ; Sun, 27 Oct 2013 06:42:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vt8a3ueJQzql for ; Sun, 27 Oct 2013 06:42:39 -0700 (PDT) Received: from toccata.fugue.com (toccata.fugue.com [204.152.186.142]) by ietfa.amsl.com (Postfix) with ESMTP id 0DDD011E81D5 for ; Sun, 27 Oct 2013 06:42:36 -0700 (PDT) Received: from [10.0.10.40] (c-174-62-147-182.hsd1.nh.comcast.net [174.62.147.182]) by toccata.fugue.com (Postfix) with ESMTPSA id 9468F2380625; Sun, 27 Oct 2013 09:42:31 -0400 (EDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 7.0 \(1816\)) From: Ted Lemon In-Reply-To: <526D17A5.9050804@cernet.edu.cn> Date: Sun, 27 Oct 2013 09:42:30 -0400 Content-Transfer-Encoding: 7bit Message-Id: References: <06601039-CAFD-49B0-918B-A8ACD51B978D@fugue.com> <526D17A5.9050804@cernet.edu.cn> To: Xing Li X-Mailer: Apple Mail (2.1816) X-Mailman-Approved-At: Tue, 29 Oct 2013 09:38:14 -0700 Cc: "v6ops@ietf.org" , Dave Thaler , "Ole Troan \(otroan\)" , "draft-liu-bonica-v6ops-dhcpv6-slaac-problem@tools.ietf.org" Subject: Re: [v6ops] DHCPv6/SLAAC Make Hosts Confusing-//RE: new draft: draft-liu-bonica-v6ops-dhcpv6-slaac-problem X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 27 Oct 2013 13:42:47 -0000 On Oct 27, 2013, at 9:39 AM, Xing Li wrote: > Based on CERNET2's IPv6 experience, I fully support Ted's proposal. xing I do not think that I made an actual proposal here. From Joachim.Fabini@tuwien.ac.at Mon Oct 28 09:40:27 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B040B21E80A8; Mon, 28 Oct 2013 09:40:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.13 X-Spam-Level: X-Spam-Status: No, score=-5.13 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, HELO_EQ_AT=0.424, HOST_EQ_AT=0.745, J_CHICKENPOX_13=0.6, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pUV1h2jSDlYM; Mon, 28 Oct 2013 09:40:23 -0700 (PDT) Received: from mail1.zserv.tuwien.ac.at (mail1.zserv.tuwien.ac.at [128.130.35.37]) by ietfa.amsl.com (Postfix) with ESMTP id AFD7421F9E89; Mon, 28 Oct 2013 09:40:22 -0700 (PDT) Received: from [128.131.88.241] (priamos.ibk.tuwien.ac.at [128.131.88.241]) (authenticated bits=0) by mail1.zserv.tuwien.ac.at (8.13.8/8.13.8) with ESMTP id r9SGeFgY012631 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 28 Oct 2013 17:40:15 +0100 Message-ID: <526E936D.1000404@tuwien.ac.at> Date: Mon, 28 Oct 2013 17:40:13 +0100 From: Joachim Fabini User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.0.1 MIME-Version: 1.0 To: "Ackermann, Michael" , Ray Hunter References: <20131017032024.5051.20799.idtracker@ietfa.amsl.com> <1381980305.36254.YahooMailNeo@web2803.biz.mail.ne1.yahoo.com> <5263C783.1080001@globis.net> <1382396300.22968.YahooMailNeo@web2801.biz.mail.ne1.yahoo.com> <526616C4.40304@globis.net> <4FC37E442D05A748896589E468752CAA0CA88734@PWN401EA160.ent.corp.bcbsm.com> <52695E3A.9090406@globis.net> <4FC37E442D05A748896589E468752CAA0CA8A36F@PWN401EA160.ent.corp.bcbsm.com> <526AAC81.3050402@globis.net> <4FC37E442D05A748896589E468752CAA0CA8B1CD@PWN401EA160.ent.corp.bcbsm.com> In-Reply-To: <4FC37E442D05A748896589E468752CAA0CA8B1CD@PWN401EA160.ent.corp.bcbsm.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Mailman-Approved-At: Tue, 29 Oct 2013 09:38:10 -0700 Cc: v6ops WG , 6man WG , "ippm@ietf.org" Subject: Re: [v6ops] [ippm] Fw: New Version Notification for draft-elkins-6man-ipv6-pdm-dest-option-04.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 28 Oct 2013 16:40:27 -0000 Mike, Nalini, please have a look at http://tools.ietf.org/html/rfc2330#section-10 and/or http://tools.ietf.org/html/rfc5905 for a detailed technical discussion on time issues/NTP. With respect to these parameters, the term "in sync" which you use is _purely_ theoretical and must be consolidated to a technical specification in terms of RFC2330 clock parameters (accuracy, resolution, etc.) to be usable in practice. I think this is what Ray meant. Stratum per se (in the NTP sense) is imho misleading/useless as a quality indicator. regards Joachim Am 28.10.2013 17:13, schrieb Ackermann, Michael: > Hey Ray > > It appears your experiences with Time Synch and Stratum levels are different than mine. In the older Telecom and Voice World Stratum was a great indicator of clocking accuracy. Still is as far as I know. This was always true with or without NTP in the picture. > And whenever we had two Stratum 0's or 1's, be they the same or different masters, they WOULD be in synch. We never had a situation that was an exception to that, with or without NTP. > > Thanks > > Mike > > > -----Original Message----- > From: Ray Hunter [mailto:v6ops@globis.net] > Sent: Friday, October 25, 2013 1:38 PM > To: Ackermann, Michael > Cc: Nalini Elkins; v6ops WG; 6man WG; ippm@ietf.org; bill.jouris@insidethestack.com; keven.haining@usbank.com > Subject: Re: [v6ops] Fw: New Version Notification for draft-elkins-6man-ipv6-pdm-dest-option-04.txt > >> Ackermann, Michael >> 25 October 2013 01:44 >> Ray >> >> Your Comment: >> No. I think what I said was that the level of certainty in your measurements is dependent on the level of synchronisation of the 2 clock sources if you are calculating a delta of timestamp of clock 1 - timestamp clock 2. >> My Response: >> Then it sounds like we are in agreement. Given the appropriate stratum level at both nodes, the desired level of time synchronization is achieved. >> > No. We are not in agreement. > > Stratum is an indication of how far down you are in the hierarchy from any NTP Stratum 0 clock. > > It says nothing about whether your stratum 0 and my stratum 0 are synchronised. > > We could both be running caesium clocks, and there could still be an offset if I don't set my reference time of my caesium clock the same as your reference time. When talking about microsecond or picosecond timing that will almost certainly be significant. > > You really need to know that the true provenance of the clock source is identical in order to make PDM 1 calculations, not just the stratum. > > Hence my comment to couple some sort of "clock ID" to the timestamp. >> Your Comment: >> I think it might be instructive to go back and look at high school physics books on making measurements, precision, accuracy, and error estimations, especially when taking the difference of two measurements, or making other calculations on top of raw observations >> My Response: Not sure exactly what this means but I can say that this sounds like theoretical doubt that time synchronization will not work properly in geographically dispersed environments? I can tell you that it does in our experiences and that the surrounding protocols/implementations are crafted to account for such vicissitudes. >> I will say that I have no field experience with DCF-77 sources, only GPS and Cesium. >> >> >> Your Comment: >> Equally a stratum 0 clock can be free running if it loses it's radio signal. >> My Response: >> This comment sort of confused me as well, but suffice to say, if any component is broken, results will be impaired. Obviously this is not limited to the time synch subject. >> >> >> Finally, your comment about "Middleboxes". I hope it can be as simple to accommodate as you describe. My concern is that if there are numerous middleboxes, the fields may get repetitively overlaid, or there will need to be so many separate fields, we could incur excessive complexity or overhead. Given that we can accomplish this with a workable solution, I am certainly all for it. >> The more information I can have to manage networks and solve problems, the better! >> >> Thanks again for your thoughts, inputs and questions! >> >> Mike >> >> >> >> >> >> >> >> >> >> >> > > > > The information contained in this communication is highly confidential and is intended solely for the use of the individual(s) to whom this communication is directed. If you are not the intended recipient, you are hereby notified that any viewing, copying, disclosure or distribution of this information is prohibited. Please notify the sender, by electronic mail or telephone, of any unintended receipt and delete the original message without making any copies. > > Blue Cross Blue Shield of Michigan and Blue Care Network of Michigan are nonprofit corporations and independent licensees of the Blue Cross and Blue Shield Association. > _______________________________________________ > ippm mailing list > ippm@ietf.org > https://www.ietf.org/mailman/listinfo/ippm > From james.cutler@consultant.com Mon Oct 28 09:58:36 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7114721E80DC for ; Mon, 28 Oct 2013 09:58:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BmV5TnahkcwJ for ; Mon, 28 Oct 2013 09:58:36 -0700 (PDT) Received: from mout.gmx.net (mout.gmx.net [74.208.4.200]) by ietfa.amsl.com (Postfix) with ESMTP id D678921E80EA for ; Mon, 28 Oct 2013 09:57:41 -0700 (PDT) Received: from [192.168.1.44] ([68.43.142.33]) by mail.gmx.com (mrgmxus001) with ESMTPSA (Nemesis) id 0Lp49C-1WDB5z28xw-00esiS for ; Mon, 28 Oct 2013 17:57:41 +0100 Content-Type: multipart/signed; boundary="Apple-Mail=_4131A7D2-A07B-4DA4-9414-BD6083408703"; protocol="application/pgp-signature"; micalg=pgp-sha1 Mime-Version: 1.0 (Mac OS X Mail 7.0 \(1816\)) From: Cutler James R In-Reply-To: <4FC37E442D05A748896589E468752CAA0CA8B1CD@PWN401EA160.ent.corp.bcbsm.com> Date: Mon, 28 Oct 2013 12:57:36 -0400 Message-Id: <1B14CBF5-5F4D-4B92-B1BB-31E15AD7786D@consultant.com> References: <20131017032024.5051.20799.idtracker@ietfa.amsl.com> <1381980305.36254.YahooMailNeo@web2803.biz.mail.ne1.yahoo.com> <5263C783.1080001@globis.net> <1382396300.22968.YahooMailNeo@web2801.biz.mail.ne1.yahoo.com> <526616C4.40304@globis.net> <4FC37E442D05A748896589E468752CAA0CA88734@PWN401EA160.ent.corp.bcbsm.com> <52695E3A.9090406@globis.net> <4FC37E442D05A748896589E468752CAA0CA8A36F@PWN401EA160.ent.corp.bcbsm.com> <526AAC81.3050402@globis.net> <4FC37E442D05A748896589E468752CAA0CA8B1CD@PWN401EA160.ent.corp.bcbsm.com> To: "Ackermann, Michael" X-Mailer: Apple Mail (2.1816) X-Provags-ID: V03:K0:Wwf6PeMQnbEOSG+W6fEtxwxxLqpVKEfHFcwic2ogU3HfNOlVPFP mb8vzouKT3mwzvqPX8OrqcwztT8ZsL/AB4BmTHC7XizdX13HAc/JjnEen2PyZKY7aYGd7in y3WMfDaNgEGUwq2NRvPmpAOcyrMszx77N7VGYTLXKUDWClbYp44SO59zpPl9zUYrvoWAjTx mLSNBsddNOFTyRvanmgBA== X-Mailman-Approved-At: Tue, 29 Oct 2013 09:38:08 -0700 Cc: Ray Hunter , v6ops WG , 6man WG , "ippm@ietf.org" Subject: Re: [v6ops] Fw: New Version Notification for draft-elkins-6man-ipv6-pdm-dest-option-04.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 28 Oct 2013 16:58:37 -0000 --Apple-Mail=_4131A7D2-A07B-4DA4-9414-BD6083408703 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 On Oct 28, 2013, at 12:13 PM, Ackermann, Michael = wrote: > Hey Ray >=20 > It appears your experiences with Time Synch and Stratum levels are = different than mine. In the older Telecom and Voice World Stratum was = a great indicator of clocking accuracy. Still is as far as I know. = This was always true with or without NTP in the picture. =20 > And whenever we had two Stratum 0's or 1's, be they the same or = different masters, they WOULD be in synch. We never had a situation = that was an exception to that, with or without NTP. =20 >=20 > Thanks >=20 > Mike Before getting too deep into this particular argument, it would be good = to review documents at http://www.eecis.udel.edu/~mills/ntp.html and = ntp.org. =20 When discussion time synchronization using NTP, stratum refers to the = distance from reference clock. Accuracy is separately a function of = reference clock and there are many variants of reference clock. That = two systems are =93in synch=94 is the magic of NTP algorithms and is = orthogonal to accuracy. James R. Cutler james.cutler@consultant.com --Apple-Mail=_4131A7D2-A07B-4DA4-9414-BD6083408703 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- Version: GnuPG/MacGPG2 v2.0.22 (Darwin) Comment: GPGTools - http://gpgtools.org iEYEARECAAYFAlJul4AACgkQHzETiNcaVPm/0gCgkKNJcGiI9JB5dp8MKjpgjhk7 Pq0An3M3/w1/+86pdlWThCMUlJkpQCTK =yNzd -----END PGP SIGNATURE----- --Apple-Mail=_4131A7D2-A07B-4DA4-9414-BD6083408703-- From markzzzsmith@yahoo.com.au Tue Oct 29 12:17:03 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C47C221F9D7A for ; Tue, 29 Oct 2013 12:17:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.916 X-Spam-Level: X-Spam-Status: No, score=-1.916 tagged_above=-999 required=5 tests=[AWL=0.183, BAYES_00=-2.599, FROM_LOCAL_NOVOWEL=0.5] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id v8vtAnpfq00S for ; Tue, 29 Oct 2013 12:16:57 -0700 (PDT) Received: from nm41.bullet.mail.bf1.yahoo.com (nm41.bullet.mail.bf1.yahoo.com [216.109.114.57]) by ietfa.amsl.com (Postfix) with ESMTP id 1DFA211E8282 for ; Tue, 29 Oct 2013 12:16:55 -0700 (PDT) Received: from [66.196.81.174] by nm41.bullet.mail.bf1.yahoo.com with NNFMP; 29 Oct 2013 19:16:49 -0000 Received: from [98.139.212.248] by tm20.bullet.mail.bf1.yahoo.com with NNFMP; 29 Oct 2013 19:16:48 -0000 Received: from [127.0.0.1] by omp1057.mail.bf1.yahoo.com with NNFMP; 29 Oct 2013 19:16:48 -0000 X-Yahoo-Newman-Property: ymail-3 X-Yahoo-Newman-Id: 870134.16799.bm@omp1057.mail.bf1.yahoo.com Received: (qmail 73749 invoked by uid 60001); 29 Oct 2013 19:16:48 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com.au; s=s1024; t=1383074208; bh=2jeu+lH2mPxKxNzKwC5iLeQURTXSRse/kcptCDmK9dA=; h=X-YMail-OSG:Received:X-Rocket-MIMEInfo:X-Mailer:References:Message-ID:Date:From:Reply-To:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type:Content-Transfer-Encoding; b=GHhYcm+EA6JxVZG5pGyJv/JrFB7Z4vjruQb9BykFlpZ4PZrLSeSIkOFo72fzE+3CQmtjJuE6dqkWFDspBohIwWIsQCUjiOEXLmft1xUofRfwpidx54r/vSWmcf+B1C+jtHbqavB3MYaK0Oy4WI6XqTj0D8xYZIq/o+Fe3sV5nnY= DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com.au; h=X-YMail-OSG:Received:X-Rocket-MIMEInfo:X-Mailer:References:Message-ID:Date:From:Reply-To:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type:Content-Transfer-Encoding; b=ZwM29YU9Qy72Vk99GmU/TYVHbU0fcaTcXcJLS9T4DqAWT0h9+nZ5oUrJE1WOvnZKFlVZkwOrmvykGlTdHFdOKywa3oMx+Iy+YZezP9qGc/3qU1bxUVivTAHKNj2kWvqdu1JU9I44JQ7T+fIUxmrlAAVUz8tycXZc5a705TOEbUg=; X-YMail-OSG: tU5MPPMVM1n.e.Xjzv3FGfg7HCUvWmjA1z7In0GZJH_EZxD J7mdS.Dnphn9I7E3_O4_V9aROv01ZF1FABT46jf3IUJh.wQImpeY94B6l9M_ witz.yAVvgRpEJLWdnEjb7U9_f3lqjFFpsCREH7wrKKZzYgcwPadva5KjQCi d67qx.m1WJOG1s6DRHlXuISF1BcGKAm_TFH3BGNjBs_AedYGKnhYB4zBgh2C Y79nTylzA3txUTh0hLGPTtPb6qTVMrBcgW9_VIdErf6yntuHpwxSqNqiYdr1 oMCXwUbLqavQCkJSNce_QjDYNlqcgtL8OoBWK1mWfEG7UIjFQ7rudvORDdaX 5YZI5y8UYzANtxgNMVv4U4WCinMPpbhRddqwHEViGwPw_d2vd32K0ON13Tf. gT7pKUK_aw7aOpdxhPDOoUHDezWSwMwLIK4I8TT_Q68t3S9kx99_7.QMrOK4 CB.Rvj48wo.YNr5PpPnASIGmKsmNXV_xMveIvuw_azpN0IcNlR11VvgYdh0F JUZwExAx7tSfmU9I.sdvXGCyGKZ.GAuG5uUw4ibBltH99A8nJv63MrKWx.P7 pr8YKefQj5MXLSQ7oc0qMGNfUE356fQ9YXri2ZSruodZA Received: from [150.101.221.237] by web142505.mail.bf1.yahoo.com via HTTP; Tue, 29 Oct 2013 12:16:48 PDT X-Rocket-MIMEInfo: 002.001, CgoKCi0tLS0tIE9yaWdpbmFsIE1lc3NhZ2UgLS0tLS0KPiBGcm9tOiBBbmRyZXcgWW91cnRjaGVua28gPGF5b3VydGNoQGNpc2NvLmNvbT4KPiBUbzogTWFyayBaWlogU21pdGggPG1hcmt6enpzbWl0aEB5YWhvby5jb20uYXU.Cj4gQ2M6IExvcmVuem8gQ29saXR0aSA8bG9yZW56b0Bnb29nbGUuY29tPjsgImRyYWZ0LWxpdS1ib25pY2EtdjZvcHMtZGhjcHY2LXNsYWFjLXByb2JsZW1AdG9vbHMuaWV0Zi5vcmciIDxkcmFmdC1saXUtYm9uaWNhLXY2b3BzLWRoY3B2Ni1zbGFhYy1wcm9ibGVtQHRvb2xzLmlldGYBMAEBAQE- X-Mailer: YahooMailWebService/0.8.160.587 References: <06601039-CAFD-49B0-918B-A8ACD51B978D@fugue.com> <1383036443.56704.YahooMailNeo@web142501.mail.bf1.yahoo.com> Message-ID: <1383074208.73179.YahooMailNeo@web142505.mail.bf1.yahoo.com> Date: Tue, 29 Oct 2013 12:16:48 -0700 (PDT) From: Mark ZZZ Smith To: Andrew Yourtchenko In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Cc: "v6ops@ietf.org" , Ted Lemon , "Ole Troan \(otroan\)" , Dave Thaler , "draft-liu-bonica-v6ops-dhcpv6-slaac-problem@tools.ietf.org" Subject: Re: [v6ops] DHCPv6/SLAAC Make Hosts Confusing-//RE: new draft: draft-liu-bonica-v6ops-dhcpv6-slaac-problem X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: Mark ZZZ Smith List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 29 Oct 2013 19:17:03 -0000 =0A=0A=0A=0A----- Original Message -----=0A> From: Andrew Yourtchenko =0A> To: Mark ZZZ Smith =0A> Cc: = Lorenzo Colitti ; "draft-liu-bonica-v6ops-dhcpv6-slaac-= problem@tools.ietf.org" ; "v6ops@ietf.org" ; Ted Lemon ;= Ole Troan (otroan) ; Dave Thaler = =0A> Sent: Wednesday, 30 October 2013 1:05 AM=0A> Subject: Re: [v6ops] DHCP= v6/SLAAC Make Hosts Confusing-//RE: new draft: draft-liu-bonica-v6ops-dhcpv= 6-slaac-problem=0A> =0A> Hi,=0A> =0A> On Tue, 29 Oct 2013, Mark ZZZ Smith w= rote:=0A> =0A>> Hi,=0A>>=A0=0A=0A=0A=0A=0A> =0A>> =0A>> =0A>> - "Wh= ile architecturally "pure", the reliability and timing =0A> of the =0A>> ro= uting resiliency provided by the RAs is far below those achieved by =0A>> F= HRP protocols which are used in today's networks predominantly." =0A> This = =0A>> seems to suggest that you can't run VRRP/HSRP if you're using RAs. I = =0A> =0A>> don't think they're mutually exclusive, as long as the RAs come = from =0A> the =0A>> virtual router link-local address, rather than the rout= ers' physical =0A>> interface link-local addresses.=0A> =0A> No, this is a = long-winded way to say that RA as a routing =0A> mechanism is useless a lot= of today's networks' requirements, not that =0A> it =0A> is incompatible. = :-)=0A>=A0=0A=0ASo I'm afraid I'm still confused by this.=0A=0AThe reason w= hy you need VRRP/HSRP etc. is because ND NUD isn't acceptably fast enough t= o detect that a default gateway has gone away. It might be possible to lowe= r the NUD timers such that they detect default gateway death much quicker, = however you then have all of the hosts actively probing the default gateway= very quickly, creating load on its control plane.=0A=0AVRRP/HSRP avoids th= is control plane load by making the the switch between routers transparent = or nearly transparent to the hosts, without the need to lower NUD timers. I= t could be viewed as a NUD special case and optimisation.=0A=0AThis all has= nothing to do with RAs or DHCPv6 - the need for VRRP is to overcome a perf= ormance limit in ND NUD, and that limitation would still exist in a DHCPv6 = only model without VRRP/HSRP. So I don't understand why DHCPv6 is or woud b= e "better" and RAs are "worse" in this scenario.=0A=0A=0ARegards,=0AMark. From markzzzsmith@yahoo.com.au Tue Oct 29 12:28:23 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1173311E8243 for ; Tue, 29 Oct 2013 12:28:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.93 X-Spam-Level: X-Spam-Status: No, score=-1.93 tagged_above=-999 required=5 tests=[AWL=0.169, BAYES_00=-2.599, FROM_LOCAL_NOVOWEL=0.5] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FHvxTTRIsbvG for ; Tue, 29 Oct 2013 12:28:17 -0700 (PDT) Received: from nm40-vm2.bullet.mail.bf1.yahoo.com (nm40-vm2.bullet.mail.bf1.yahoo.com [72.30.239.210]) by ietfa.amsl.com (Postfix) with ESMTP id AA39811E8260 for ; Tue, 29 Oct 2013 12:28:14 -0700 (PDT) Received: from [98.139.215.141] by nm40.bullet.mail.bf1.yahoo.com with NNFMP; 29 Oct 2013 19:28:14 -0000 Received: from [98.139.212.194] by tm12.bullet.mail.bf1.yahoo.com with NNFMP; 29 Oct 2013 19:28:13 -0000 Received: from [127.0.0.1] by omp1003.mail.bf1.yahoo.com with NNFMP; 29 Oct 2013 19:28:13 -0000 X-Yahoo-Newman-Property: ymail-3 X-Yahoo-Newman-Id: 935964.55578.bm@omp1003.mail.bf1.yahoo.com Received: (qmail 2663 invoked by uid 60001); 29 Oct 2013 19:28:13 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com.au; s=s1024; t=1383074893; bh=Uc+EHGQvmavgxdAG37tZeG8AJt9F5WUElmWVzJ0HgOA=; h=X-YMail-OSG:Received:X-Rocket-MIMEInfo:X-Mailer:References:Message-ID:Date:From:Reply-To:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type:Content-Transfer-Encoding; b=XWZY5tyovyagRpEicd45qC+A0sBUcT++/m/6EmjWWiw1AOtMD/kvgKuHNT3AVr3texuYnhcsoUQeQL/6HUCMzkMtB/TKCTl+0yBSbq6SIgvsQXWkf7oyVtPDyVchRlPlBjVdvPiLTOxat/ZdALTszLa4Om6QnHvbwtbeJDeNNXg= DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com.au; h=X-YMail-OSG:Received:X-Rocket-MIMEInfo:X-Mailer:References:Message-ID:Date:From:Reply-To:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type:Content-Transfer-Encoding; b=5WKdUQbcDvhTVwFHQibswfFFnSMBxvwZMX++NF1GRv+vlOFAtk7WcjvfXLPWHBer6IAnbzA4hCOpRtSZ9kEq5I9mQF0xPzDmOS7jhQhTRv364lwZBD/Nex0Cgf0dPeKL2WWDcxHmUUAtHxXpgSFlS3syc+EGiVWuiktNqRukL4E=; X-YMail-OSG: nnO0UmYVM1nH_GxASCz6lkgzlm_agEcMYBd4yn_6R1Nc5Jx 73znDvk6Z0CR2Tn3Z5.AK4FbO8KU7bblA7nL7JOhg8VPfplgMt6I03qo6nR3 MchMg6Y2OUjOsInDTrXTPzFLwEjMB4uaZD11wZo2fGJ022FKjm0u__iO5Ii_ Jw0g6Y06mnQ14d920Md8_mSomUp6GGABagWTPR3iBnKtqdDRySOS3tND_ubp JE4ALU76O69GHf8Nn7O9A_9cUa8DZl6YIbgrUwu1APOOzwnkqTo0.KE_LSM. E7hN0EnEc3NkwfTlDc85RRjYyCarz93rIHm_37W8ox1vwS9VBm1sfz5VDgCJ vNGIOt9cPDXNr9PE_vDH.80cKqvFnkewMdk656EzbwMQ4m.ExiaqB9Ugzyxz QeLx6yLmh0G2Rg_3Fmhu8Dt36brJlkrfXvOVxc7r35yk1cbGIUOySOZlnvH9 ET0yce7jFoFHJlgkvBvTpUeGN7YaW7b.GZQoVq91lUb2rBXb.bSUhjHJVNZ4 iNG43SiTbpO5sRZ7OZn4XOT3IB1stx7b_2YVN.fHLs9UIB.m4Ou8hXlKuBYR k6X1W3df44_giktwfuljHF5IXiYmI.m1gvv45iuWeyDNo Received: from [150.101.221.237] by web142504.mail.bf1.yahoo.com via HTTP; Tue, 29 Oct 2013 12:28:12 PDT X-Rocket-MIMEInfo: 002.001, CgoKCi0tLS0tIE9yaWdpbmFsIE1lc3NhZ2UgLS0tLS0KPiBGcm9tOiAiV2VpbCwgSmFzb24iIDxqYXNvbi53ZWlsQHR3Y2FibGUuY29tPgo.IFRvOiBMaXViaW5nIChMZW8pIDxsZW8ubGl1YmluZ0BodWF3ZWkuY29tPjsgV3V5dHMgQ2FybCA8Q2FybC5XdXl0c0B0ZWNobmljb2xvci5jb20.OyAic3RoYXVnQG5ldGhlbHAubm8iIDxzdGhhdWdAbmV0aGVscC5ubz4KPiBDYzogInY2b3BzQGlldGYub3JnIiA8djZvcHNAaWV0Zi5vcmc.OyAib3Ryb2FuQGNpc2NvLmNvbSIgPG90cm9hbkBjaXNjby5jb20.OyAiZHIBMAEBAQE- X-Mailer: YahooMailWebService/0.8.160.587 References: <8AE0F17B87264D4CAC7DE0AA6C406F453D7CCAB5@nkgeml506-mbx.china.huawei.com> Message-ID: <1383074892.1756.YahooMailNeo@web142504.mail.bf1.yahoo.com> Date: Tue, 29 Oct 2013 12:28:12 -0700 (PDT) From: Mark ZZZ Smith To: "Weil, Jason" , "Liubing \(Leo\)" , Wuyts Carl , "sthaug@nethelp.no" In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Cc: "v6ops@ietf.org" , "otroan@cisco.com" , "draft-liu-bonica-v6ops-dhcpv6-slaac-problem@tools.ietf.org" Subject: Re: [v6ops] DHCPv6/SLAAC Make Hosts Confusing-//RE: new draft: draft-liu-bonica-v6ops-dhcpv6-slaac-problem X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: Mark ZZZ Smith List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 29 Oct 2013 19:28:23 -0000 =0A=0A=0A=0A----- Original Message -----=0A> From: "Weil, Jason" =0A> To: Liubing (Leo) ; Wuyts Carl <= Carl.Wuyts@technicolor.com>; "sthaug@nethelp.no" =0A> Cc= : "v6ops@ietf.org" ; "otroan@cisco.com" ;= "draft-liu-bonica-v6ops-dhcpv6-slaac-problem@tools.ietf.org" =0A> Sent: Wednesday, 30 Oct= ober 2013 1:44 AM=0A> Subject: Re: [v6ops] DHCPv6/SLAAC Make Hosts Confusin= g-//RE: new draft: draft-liu-bonica-v6ops-dhcpv6-slaac-problem=0A> =0A> Leo= ,=0A> =0A> First I wanted to say this is useful work and I support it.=0A> = =0A> This topic in this email reminds me of an issue that we have run acros= s=0A> that might be relevant to your draft:=0A> =0A> The use case involves = a home network whose gateway router sets M=3D1 and A=3D1=0A> in order to pr= ovide DHC and and SLAAC for hosts that do not implement a=0A> DHC client. I= f the DHCPv6 Server is implementing IP assignment using=0A> interface-ident= ifier and using the same prefix as advertised in the PIO=0A> (assuming the = server resides on the router advertising the PIO) with the A=0A> bit set, h= osts that support SLAAC and a DHCPv6 client could construct the=0A> same ad= dress using DHC as the one they construct using SLAAC. What is not=0A> clea= r is what hosts should do in this situation. IMO, there is a benefit=0A> if= hosts that support both SLAAC and DHCPv6 construct the address and=0A> pre= fer the DHC address over the SLAAC address. The benefit is that you=0A> red= uce the number of active addresses and all hosts end up with a single=0A> a= ddress per prefix administered in this fashion.=0A> =0A> Of course if your = DHC Server implements another assignment algorithm (e.g.=0A> Random) then y= our hosts that support both may end up with 2 addresses out=0A> of the same= prefix.=0A>=A0=0A=0AAnother way to describe your scenario is that it is a = transition scenario between SLAAC and stateful DHCPv6, since some of your h= osts don't support stateful DHCPv6.=0A=0AIn your scenario, I don't think it= is a big problem that some of your hosts will have two addresses within th= e same prefix - IPv6 hosts are designed to cope with many addresses, and a = /64 has plenty of addresses to go around.=0A=0AIf you do want to be specifi= cally selective about which hosts use SLAAC and which hosts use stateful DH= CPv6 for addressing, use host specific RAs which set the M and the PIO A bi= ts on a selected host basis.=0A=0ARegards,=0AMark. From ayourtch@cisco.com Tue Oct 29 12:34:19 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BB8AA21E8087 for ; Tue, 29 Oct 2013 12:34:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.299 X-Spam-Level: X-Spam-Status: No, score=-10.299 tagged_above=-999 required=5 tests=[AWL=0.300, 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 u51HsgN-Kfhn for ; Tue, 29 Oct 2013 12:34:14 -0700 (PDT) Received: from rcdn-iport-5.cisco.com (rcdn-iport-5.cisco.com [173.37.86.76]) by ietfa.amsl.com (Postfix) with ESMTP id 4F66011E8262 for ; Tue, 29 Oct 2013 12:33:50 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1140; q=dns/txt; s=iport; t=1383075230; x=1384284830; h=date:from:to:cc:subject:in-reply-to:message-id: references:mime-version; bh=5luLoR5IkJAhlppk92vDPs7XxRMl0wOKwtyIzng9ucU=; b=i9JqTylH5rpO2RH1FRCJepxoxQPFWabB/4WL1RtqLZw4s59pzANl7Npu yHXyT2twF/bk7zDWjrTpk6sKhZMCtGFpp+vgSENfWf5FJIEZ+s37gUe4N kiO8RzFcihUUqcCXuWwOpEKI3wSJCQylTfWMM1OxuUy80Zkx2P7bSby3+ w=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ah4FAMIMcFKtJXHB/2dsb2JhbABZgweBDL80gSwWdIIlAQEBAwE4Aj8FCws7C1cGDogGBro3jgmBPgeELAOeRotMgWiBP4FoQQ X-IronPort-AV: E=Sophos;i="4.93,595,1378857600"; d="scan'208";a="278142385" Received: from rcdn-core2-6.cisco.com ([173.37.113.193]) by rcdn-iport-5.cisco.com with ESMTP; 29 Oct 2013 19:33:49 +0000 Received: from xhc-rcd-x04.cisco.com (xhc-rcd-x04.cisco.com [173.37.183.78]) by rcdn-core2-6.cisco.com (8.14.5/8.14.5) with ESMTP id r9TJXn7k030878 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 29 Oct 2013 19:33:49 GMT Received: from [10.61.200.140] (10.61.200.140) by xhc-rcd-x04.cisco.com (173.37.183.78) with Microsoft SMTP Server (TLS) id 14.2.318.4; Tue, 29 Oct 2013 14:33:48 -0500 Date: Tue, 29 Oct 2013 20:33:30 +0100 From: Andrew Yourtchenko X-X-Sender: ayourtch@ayourtch-mac To: Mark ZZZ Smith In-Reply-To: <1383074208.73179.YahooMailNeo@web142505.mail.bf1.yahoo.com> Message-ID: References: <06601039-CAFD-49B0-918B-A8ACD51B978D@fugue.com> <1383036443.56704.YahooMailNeo@web142501.mail.bf1.yahoo.com> <1383074208.73179.YahooMailNeo@web142505.mail.bf1.yahoo.com> User-Agent: Alpine 2.00 (OSX 1167 2008-08-23) MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII"; format=flowed X-Originating-IP: [10.61.200.140] Cc: "v6ops@ietf.org" , Ted Lemon , "Ole Troan \(otroan\)" , Dave Thaler , "draft-liu-bonica-v6ops-dhcpv6-slaac-problem@tools.ietf.org" Subject: Re: [v6ops] DHCPv6/SLAAC Make Hosts Confusing-//RE: new draft: draft-liu-bonica-v6ops-dhcpv6-slaac-problem X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 29 Oct 2013 19:34:19 -0000 On Tue, 29 Oct 2013, Mark ZZZ Smith wrote: > So I'm afraid I'm still confused by this. > > The reason why you need VRRP/HSRP etc. is because ND NUD isn't acceptably fast enough to detect that a default gateway has gone away. It might be possible to lower the NUD timers such that they detect default gateway death much quicker, however you then have all of the hosts actively probing the default gateway very quickly, creating load on its control plane. > > VRRP/HSRP avoids this control plane load by making the the switch between routers transparent or nearly transparent to the hosts, without the need to lower NUD timers. It could be viewed as a NUD special case and optimisation. > > This all has nothing to do with RAs or DHCPv6 - the need for VRRP is to overcome a performance limit in ND NUD, and that limitation would still exist in a DHCPv6 only model without VRRP/HSRP. So I don't understand why DHCPv6 is or woud be "better" and RAs are "worse" in this scenario. Essence of that section: RA deals with routing [not always very efficently]. DHCPv6 does not do it at all. --a > > > Regards, > Mark. > From lorenzo@google.com Tue Oct 29 12:42:04 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 97D6121E80A6 for ; Tue, 29 Oct 2013 12:42:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.884 X-Spam-Level: X-Spam-Status: No, score=-1.884 tagged_above=-999 required=5 tests=[AWL=0.093, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, 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 uBFYFwp7xxwN for ; Tue, 29 Oct 2013 12:42:04 -0700 (PDT) Received: from mail-ie0-x230.google.com (mail-ie0-x230.google.com [IPv6:2607:f8b0:4001:c03::230]) by ietfa.amsl.com (Postfix) with ESMTP id E005121E8087 for ; Tue, 29 Oct 2013 12:38:37 -0700 (PDT) Received: by mail-ie0-f176.google.com with SMTP id u16so591273iet.35 for ; Tue, 29 Oct 2013 12:38:27 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=vNH1zWz7OkWBYdWN6CzUABUnE6NHBGV7wSxRo/j6Q0Q=; b=PLTMp4lbq/c4GXK9i0hf2MEcBMFkLltyMUUXMpyIM0qQO4Yfe8HyoEMau1dEl69I71 hpWMx3LFWEDY58Cv1lLSDvJAhjYBALy+L8PEJRmV9fpm3G5mpJONIsWspnurek45LBu2 83XEVWffU7Bn9stYkBn0VMwu8QqdVfxBYuedJ59YwT2EdMwq51ip34mACVVW4hC/8Bes jyrGRsIYVzh2vfEuG1aJECBIeshy8vwZXBF1e8pMI7UVc57vVuUthjdrxB+LOfm4f6NT Z/4vLNjxezCraFCMymVM+BXsU/ZhoCFM2Cf+Jn55HMkY0W4WAWdw1Kdbs92/aEauQZw7 nbCg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type; bh=vNH1zWz7OkWBYdWN6CzUABUnE6NHBGV7wSxRo/j6Q0Q=; b=BWX7vfXobc3eArpw3TqPcvC4373PijWbBG20YPJ3rzLY44HQZOz2Wi7sXhqJ71twCn B0T2xTn86fGC8tsK7zMK9KLhDoUoAxhG35280ScPnx92htKnSErAtGC0yMeczt++uQ93 w9SrbFLaW0G75CiObNcIp0sFpMlZkR5fYbUGrNTnfOznd0iZbU2fO6bf55tVYsufHoJw 1JaqUPCOyy3B6bZ/g/3g7ElZb/ogjYXHVyo46tdR/xJJNJYH0KZSHGEO9yBaxLT4PY4k hbmWjEIOhXtOPn6JiXM6qqlOwllgs5ZZohM+rmSDEXYkCC2zhAKEIiSyXp4+Q4O01lFT k4Ew== X-Gm-Message-State: ALoCoQnFqD7c8hiKzQ4qAlthSxnRYgRvu7u4+z9i+oseJeHc7YJfAV8lffaURkYz5nVd1M79FWN6CnJ2hraR6h60vW/Zm1z50j3dF2HYQZhNEFXhSoLTz7yCWbftJn4aHk1MorpqpZCLsFNIC/RnHLev8X62DfDOu0eI/B3OxDSp27AUBt7ALb4bV4SOB5eHgwELV6RwcrvS X-Received: by 10.50.66.163 with SMTP id g3mr1042604igt.20.1383075507513; Tue, 29 Oct 2013 12:38:27 -0700 (PDT) MIME-Version: 1.0 Received: by 10.64.86.106 with HTTP; Tue, 29 Oct 2013 12:38:07 -0700 (PDT) In-Reply-To: References: <06601039-CAFD-49B0-918B-A8ACD51B978D@fugue.com> <1383036443.56704.YahooMailNeo@web142501.mail.bf1.yahoo.com> <1383074208.73179.YahooMailNeo@web142505.mail.bf1.yahoo.com> From: Lorenzo Colitti Date: Wed, 30 Oct 2013 04:38:07 +0900 Message-ID: To: Andrew Yourtchenko Content-Type: multipart/alternative; boundary=047d7bdca31c52dcc304e9e65ce8 Cc: Ted Lemon , "v6ops@ietf.org" , Dave Thaler , "Ole Troan \(otroan\)" , "draft-liu-bonica-v6ops-dhcpv6-slaac-problem@tools.ietf.org" Subject: Re: [v6ops] DHCPv6/SLAAC Make Hosts Confusing-//RE: new draft: draft-liu-bonica-v6ops-dhcpv6-slaac-problem X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 29 Oct 2013 19:42:04 -0000 --047d7bdca31c52dcc304e9e65ce8 Content-Type: text/plain; charset=ISO-8859-1 On Wed, Oct 30, 2013 at 4:33 AM, Andrew Yourtchenko wrote: > Essence of that section: RA deals with routing [not always very > efficently]. DHCPv6 does not do it at all. > I think the words you want are that RA "shares fate" with routing, right? --047d7bdca31c52dcc304e9e65ce8 Content-Type: text/html; charset=ISO-8859-1
On Wed, Oct 30, 2013 at 4:33 AM, Andrew Yourtchenko <ayourtch@cisco.com> wrote:
Essence of that section: RA deals with routing [not always very efficently]. DHCPv6 does not do it at all.

I think the words you want are that RA "shares fate" with routing, right?
--047d7bdca31c52dcc304e9e65ce8-- From jason.weil@twcable.com Tue Oct 29 12:59:50 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7918B11E8255 for ; Tue, 29 Oct 2013 12:59:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.163 X-Spam-Level: X-Spam-Status: No, score=-0.163 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, HELO_EQ_MODEMCABLE=0.768, HOST_EQ_MODEMCABLE=1.368, J_CHICKENPOX_53=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 5Je9e8c90AWx for ; Tue, 29 Oct 2013 12:59:45 -0700 (PDT) Received: from cdcipgw02.twcable.com (cdcipgw02.twcable.com [165.237.91.111]) by ietfa.amsl.com (Postfix) with ESMTP id 4C07911E81F8 for ; Tue, 29 Oct 2013 12:59:45 -0700 (PDT) X-SENDER-IP: 10.136.163.15 X-SENDER-REPUTATION: None X-IronPort-AV: E=Sophos;i="4.93,595,1378872000"; d="scan'208";a="45998287" Received: from unknown (HELO PRVPEXHUB06.corp.twcable.com) ([10.136.163.15]) by cdcipgw02.twcable.com with ESMTP/TLS/RC4-MD5; 29 Oct 2013 15:59:24 -0400 Received: from PRVPEXVS17.corp.twcable.com ([10.136.163.95]) by PRVPEXHUB06.corp.twcable.com ([10.136.163.15]) with mapi; Tue, 29 Oct 2013 15:59:40 -0400 From: "Weil, Jason" To: Mark ZZZ Smith , "Liubing (Leo)" , Wuyts Carl , "sthaug@nethelp.no" Date: Tue, 29 Oct 2013 15:59:40 -0400 Thread-Topic: [v6ops] DHCPv6/SLAAC Make Hosts Confusing-//RE: new draft: draft-liu-bonica-v6ops-dhcpv6-slaac-problem Thread-Index: Ac7U4WdVlBlo6XOJQ5Obnz7A4BuHFw== Message-ID: In-Reply-To: <1383074892.1756.YahooMailNeo@web142504.mail.bf1.yahoo.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.3.6.130613 acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "v6ops@ietf.org" , "otroan@cisco.com" , "draft-liu-bonica-v6ops-dhcpv6-slaac-problem@tools.ietf.org" Subject: Re: [v6ops] DHCPv6/SLAAC Make Hosts Confusing-//RE: new draft: draft-liu-bonica-v6ops-dhcpv6-slaac-problem X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 29 Oct 2013 19:59:50 -0000 I wasn't claiming it was a problem that a host has two addresses. I was just saying it might be beneficial in certain scenarios for all hosts on a network segment (SLAAC-only, SLAAC+DHC, DHC-only) to have a single address created using the same algorithm. Jason On 10/29/13 3:28 PM, "Mark ZZZ Smith" wrote: > > > > >----- Original Message ----- >> From: "Weil, Jason" >> To: Liubing (Leo) ; Wuyts Carl >>; "sthaug@nethelp.no" >> Cc: "v6ops@ietf.org" ; "otroan@cisco.com" >>; >>"draft-liu-bonica-v6ops-dhcpv6-slaac-problem@tools.ietf.org" >> >> Sent: Wednesday, 30 October 2013 1:44 AM >> Subject: Re: [v6ops] DHCPv6/SLAAC Make Hosts Confusing-//RE: new draft: >>draft-liu-bonica-v6ops-dhcpv6-slaac-problem >> >> Leo, >> >> First I wanted to say this is useful work and I support it. >> >> This topic in this email reminds me of an issue that we have run across >> that might be relevant to your draft: >> >> The use case involves a home network whose gateway router sets M=3D1 and >>A=3D1 >> in order to provide DHC and and SLAAC for hosts that do not implement a >> DHC client. If the DHCPv6 Server is implementing IP assignment using >> interface-identifier and using the same prefix as advertised in the PIO >> (assuming the server resides on the router advertising the PIO) with >>the A >> bit set, hosts that support SLAAC and a DHCPv6 client could construct >>the >> same address using DHC as the one they construct using SLAAC. What is >>not >> clear is what hosts should do in this situation. IMO, there is a benefit >> if hosts that support both SLAAC and DHCPv6 construct the address and >> prefer the DHC address over the SLAAC address. The benefit is that you >> reduce the number of active addresses and all hosts end up with a single >> address per prefix administered in this fashion. >> >> Of course if your DHC Server implements another assignment algorithm >>(e.g. >> Random) then your hosts that support both may end up with 2 addresses >>out >> of the same prefix. >> > >Another way to describe your scenario is that it is a transition scenario >between SLAAC and stateful DHCPv6, since some of your hosts don't support >stateful DHCPv6. > >In your scenario, I don't think it is a big problem that some of your >hosts will have two addresses within the same prefix - IPv6 hosts are >designed to cope with many addresses, and a /64 has plenty of addresses >to go around. > >If you do want to be specifically selective about which hosts use SLAAC >and which hosts use stateful DHCPv6 for addressing, use host specific RAs >which set the M and the PIO A bits on a selected host basis. > >Regards, >Mark. This E-mail and any of its attachments may contain Time Warner Cable propri= etary information, which is privileged, confidential, or subject to copyrig= ht belonging to Time Warner Cable. This E-mail is intended solely for the u= se of the individual or entity to which it is addressed. If you are not the= intended recipient of this E-mail, you are hereby notified that any dissem= ination, distribution, copying, or action taken in relation to the contents= of and attachments to this E-mail is strictly prohibited and may be unlawf= ul. If you have received this E-mail in error, please notify the sender imm= ediately and permanently delete the original and any copy of this E-mail an= d any printout. From jinmei.tatuya@gmail.com Tue Oct 29 12:59:57 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B6D7D11E827E for ; Tue, 29 Oct 2013 12:59:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.222 X-Spam-Level: * X-Spam-Status: No, score=1.222 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, CHARSET_FARAWAY_HEADER=3.2, FM_FORGED_GMAIL=0.622, 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 NTgVq9hfKpBu for ; Tue, 29 Oct 2013 12:59:56 -0700 (PDT) Received: from mail-wg0-x233.google.com (mail-wg0-x233.google.com [IPv6:2a00:1450:400c:c00::233]) by ietfa.amsl.com (Postfix) with ESMTP id F30F111E8255 for ; Tue, 29 Oct 2013 12:59:55 -0700 (PDT) Received: by mail-wg0-f51.google.com with SMTP id l18so367402wgh.30 for ; Tue, 29 Oct 2013 12:59:54 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type; bh=y+vEcsaW1jdrxH3xeZdSCTwFTNdMeaXC9GKQPsHogAY=; b=txhQWvgmh/DM/q1GcRLdL3nJFfUVU9TcZG8MGUo00VasJpFnkqMPJiXqXpTKsrUG/X RCmCoaz8CjkCdFAPrrD8J8t66DEkZbd4wtSe/HK6yYdgzE7puW+HrVB6UIS2LAUYAL1f HT6ydpmVQP349Wa/zQp1eorEkvdLWaAWtIewFkYZzLws0K/hmgZmHUlSZNVgnEVG62cX 72xEZTQ/J5wauRe8CoB+xwzEJwCDMRywwPEwtA1pLhI1AYM4nUmUxq+CNJEtbP4XrIr/ UXygS3sBOzLXz9AVHsDO1qdQuIpF3KV+ZgXufv75cOnze/RyXLfA6+Twuk51EojdGXef qzZw== MIME-Version: 1.0 X-Received: by 10.180.76.69 with SMTP id i5mr14517766wiw.34.1383076794702; Tue, 29 Oct 2013 12:59:54 -0700 (PDT) Sender: jinmei.tatuya@gmail.com Received: by 10.194.120.167 with HTTP; Tue, 29 Oct 2013 12:59:54 -0700 (PDT) In-Reply-To: References: <06601039-CAFD-49B0-918B-A8ACD51B978D@fugue.com> Date: Tue, 29 Oct 2013 12:59:54 -0700 X-Google-Sender-Auth: x7oJy0PBoh3aS2r-t0g5vW_X4Pk Message-ID: From: =?ISO-2022-JP?B?GyRCP0BMQEMjOkgbKEI=?= To: Lorenzo Colitti Content-Type: text/plain; charset=ISO-8859-1 Cc: "v6ops@ietf.org" , Ted Lemon , "Ole Troan \(otroan\)" , Dave Thaler , "draft-liu-bonica-v6ops-dhcpv6-slaac-problem@tools.ietf.org" Subject: Re: [v6ops] DHCPv6/SLAAC Make Hosts Confusing-//RE: new draft: draft-liu-bonica-v6ops-dhcpv6-slaac-problem X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 29 Oct 2013 19:59:57 -0000 At Tue, 29 Oct 2013 14:13:39 +0900, Lorenzo Colitti wrote: > > 7) Programming: UDP vs. ICMP > > > > For a random programmer today, coding a server to receive the data on a > > UDP socket is a more familiar exercise than working with ICMP. Disclaimer: > > the value of "random" was chosen to be "me" for arbitrary reasons. This > > point is more of a rathole and a personal preference, probably. I think I > > remember Dave Thaler saying one of the mechanisms in Windows was way easier > > to extend than the other, but I do not remember which. > > ICMP is harder than UDP to implement; it often requires raw sockets or > kernel collaboration (e.g., on Linux RDNSS information can be read using > netlink. UDP is much simpler). On the other hand, I think stateful DHCPv6 > is a more complicated protocol to implement than RAs, with more message > types and so on. I don't know why Linux uses a non portable API, but I believe writing programs handling RA options like RDNSS is no harder than writing DHCPv6 client in terms of socket API. As long as the system supports RFC3542 you should be able to write a portable RA "client" pretty easily (meaning as easy/hard as writing some UDP client program). For example, FreeBSD's rtsold supports RDNSS and (AFAIK) only relies on the RFC3542 APIs. Also, since DHCP is trickier than other UDP applications in some points (it's more sensitive to which interface to use, and in some cases you need to make sure the source address is link-local, etc), it's quite likely that you'll need something like unusual APIs like RFC3542 or some non-portable system dependent interface to write a standard-compliant DHCP(v6) client. So, overall, I'd say the programming difficulty regarding UDP (DHCP) vs ICMP (RS/RA) is marginal. As I'm writing a response, I'll also make a comment on another, more minor point: At Tue, 29 Oct 2013 14:13:39 +0900, Lorenzo Colitti wrote: > But you can't authenticate in DHCPv6 either, right? Whether you get an > unsolicited "here's some config parameters" RA or a unicast "thank you for > your request, here's some config parameters" DHCPv6 reply, the problem is > the same: is the source trustworthy? AIUI we don't have any solution for > this except DHCPv6 guard and RA guard, which are effectively the same > solution. I mean - we do have SEND and DHCPv6 authentication, but does > anyone implement those? If you mean the Delayed Authentication Protocol by DHCPv6 authentication, the WIDE DHCPv6 supports it: http://sourceforge.net/projects/wide-dhcpv6/ although I myself have only used it in testing. I heard some other vendors implemented it, too. (And, for that matter, it also supports the Information Refresh Time option (RFC4242)). -- jinmei From ayourtch@cisco.com Tue Oct 29 13:21:08 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1470C11E82C5 for ; Tue, 29 Oct 2013 13:21:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.374 X-Spam-Level: X-Spam-Status: No, score=-10.374 tagged_above=-999 required=5 tests=[AWL=0.225, 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 0sTX+XV5oFQn for ; Tue, 29 Oct 2013 13:21:03 -0700 (PDT) Received: from rcdn-iport-6.cisco.com (rcdn-iport-6.cisco.com [173.37.86.77]) by ietfa.amsl.com (Postfix) with ESMTP id 695FD11E82B7 for ; Tue, 29 Oct 2013 13:20:57 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1309; q=dns/txt; s=iport; t=1383078057; x=1384287657; h=date:from:to:cc:subject:in-reply-to:message-id: references:mime-version; bh=BnOwo5U1vNUcAhJ9tmZAFBSnXYFRWvpOdspB3M+DBT4=; b=fyHjYgS0w0qa/ruvaBHT/iqRZG1Z4AJKWVtAOPLyAnRf7A5K/JY864rP KSBPcYD0jnSf66zrbN+81Cglmo6jv8hrrkhz/9IMFH4Y46Zz7IHOXfH9w IXaYNPiwrUu+kZi2NIm6XohM5eHJvVdjtiS+viI93tP9Ky5IWmzSgNLlh g=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AroHAHAYcFKtJXG9/2dsb2JhbABZgwc4VL58OYEtFnSCJQEBAQMBOAI/BQsLGCMLVwYOBYgBBg26OQSPQQeELAOeRotMgWiBP4Ip X-IronPort-AV: E=Sophos;i="4.93,595,1378857600"; d="scan'208";a="278173444" Received: from rcdn-core2-2.cisco.com ([173.37.113.189]) by rcdn-iport-6.cisco.com with ESMTP; 29 Oct 2013 20:20:57 +0000 Received: from xhc-rcd-x04.cisco.com (xhc-rcd-x04.cisco.com [173.37.183.78]) by rcdn-core2-2.cisco.com (8.14.5/8.14.5) with ESMTP id r9TKKuLH020357 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 29 Oct 2013 20:20:56 GMT Received: from [10.61.200.140] (10.61.200.140) by xhc-rcd-x04.cisco.com (173.37.183.78) with Microsoft SMTP Server (TLS) id 14.2.318.4; Tue, 29 Oct 2013 15:20:56 -0500 Date: Tue, 29 Oct 2013 21:20:37 +0100 From: Andrew Yourtchenko X-X-Sender: ayourtch@ayourtch-mac To: Lorenzo Colitti In-Reply-To: Message-ID: References: <06601039-CAFD-49B0-918B-A8ACD51B978D@fugue.com> <1383036443.56704.YahooMailNeo@web142501.mail.bf1.yahoo.com> <1383074208.73179.YahooMailNeo@web142505.mail.bf1.yahoo.com> User-Agent: Alpine 2.00 (OSX 1167 2008-08-23) MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII"; format=flowed X-Originating-IP: [10.61.200.140] Cc: Ted Lemon , "v6ops@ietf.org" , Dave Thaler , "Ole Troan \(otroan\)" , "draft-liu-bonica-v6ops-dhcpv6-slaac-problem@tools.ietf.org" Subject: Re: [v6ops] DHCPv6/SLAAC Make Hosts Confusing-//RE: new draft: draft-liu-bonica-v6ops-dhcpv6-slaac-problem X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 29 Oct 2013 20:21:08 -0000 On Wed, 30 Oct 2013, Lorenzo Colitti wrote: > On Wed, Oct 30, 2013 at 4:33 AM, Andrew Yourtchenko wrote: > Essence of that section: RA deals with routing [not always very efficently]. DHCPv6 does not do it at all. > > > I think the words you want are that RA "shares fate" with routing, right? I don't think "shares fate" is the correct wording for it - but maybe I misunderstand what you meant. Please expand. Meantime I tried to reword that section: https://github.com/ayourtch/ra-dhcpv6/blob/0bfbfd0f3c69de9b0c208aa1b7933ab6cc71be30/draft-yourtchenko-ra-dhcpv6-comparison-00.txt#L230 Take a look and see if this captures the things any better. It's a very tricky section. There's an intertwine of "DHCPv6 was not allowed to do any routing" + the implicit "I got an RA therefore that router exists" (though "I got a DHCP offer from that router therefore that router exists" is also can be argued for) + the "multiple sources of truths"... I feel it turns into a micro-version of the "RA vs. DHCP" debate - maybe worth just folding it back into a pure factual "It was decided that RA does routing, DHCPv6 does not, by the way RA does a slow redundancy, which people do not like, therefore they think DHCPv6 should do routing". --a From markzzzsmith@yahoo.com.au Tue Oct 29 13:23:49 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D061C11E8294 for ; Tue, 29 Oct 2013 13:23:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.652 X-Spam-Level: X-Spam-Status: No, score=-1.652 tagged_above=-999 required=5 tests=[AWL=-0.153, BAYES_00=-2.599, FROM_LOCAL_NOVOWEL=0.5, J_CHICKENPOX_53=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 8TBUF6xtaXl9 for ; Tue, 29 Oct 2013 13:23:44 -0700 (PDT) Received: from nm14-vm0.bullet.mail.bf1.yahoo.com (nm14-vm0.bullet.mail.bf1.yahoo.com [98.139.213.164]) by ietfa.amsl.com (Postfix) with ESMTP id F03FE11E828E for ; Tue, 29 Oct 2013 13:23:40 -0700 (PDT) Received: from [66.196.81.171] by nm14.bullet.mail.bf1.yahoo.com with NNFMP; 29 Oct 2013 20:23:40 -0000 Received: from [98.139.212.201] by tm17.bullet.mail.bf1.yahoo.com with NNFMP; 29 Oct 2013 20:23:40 -0000 Received: from [127.0.0.1] by omp1010.mail.bf1.yahoo.com with NNFMP; 29 Oct 2013 20:23:40 -0000 X-Yahoo-Newman-Property: ymail-3 X-Yahoo-Newman-Id: 434390.4947.bm@omp1010.mail.bf1.yahoo.com Received: (qmail 37494 invoked by uid 60001); 29 Oct 2013 20:23:40 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com.au; s=s1024; t=1383078220; bh=QDbZAzg15gPsW+Ijgcxn55RZ7K1s7fdzYndS1yMMrSo=; h=X-YMail-OSG:Received:X-Rocket-MIMEInfo:X-Mailer:References:Message-ID:Date:From:Reply-To:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type:Content-Transfer-Encoding; b=AYUZh609ehsRxXbIhbZqo3SwpLdhVWSJt5KeZ8yUSBwGvs+spL9QMp+Hg623t9xiL9h4zbcnDOaQkh186Gio+IyeJVp0b9i30q/Gs8Ys6mR+cn6rXq32buxRkA+dwjnaBdF9HXVaigrEF7bAsRkoBcameVBEkUi2ZIKrh7p5HwY= DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com.au; h=X-YMail-OSG:Received:X-Rocket-MIMEInfo:X-Mailer:References:Message-ID:Date:From:Reply-To:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type:Content-Transfer-Encoding; b=LjYYA9+t1UhdDedGp1Bxy/DuVDiBV4s2SjCD4XX2sjCo17XVuHUnJE0Le8ngJkCsrSTKu+MXjv2BzQOmTSUFwCt8hTO4Sn/AZZaJk3n6oK1EZUY4RgItcke63iYzx8qeFzy4Qces30/0NJF7a5sxJBSFZPA4cloYGWwNAbq6Asw=; X-YMail-OSG: MpJgwWYVM1mKs7x6SYnYLlLJrRFMojIL_bRlfN.FLRuOuiP Q9LI_N4Pu_JGWrikduqNmrNCHOndf.v7N0pc_YT1lwlqWW3MdZ_lmjGhujXk NcBiVFZOKJkRsmocCHBokT1K54ppbcDC0q1ptRRBIOkM3Q_KQxBqmkyrSy61 KgA7T.0Pr2R1yf.tWNzdylWu__7DVGGeZkoT_byDvlksqoSz8OczJki8vhO0 ws3Wrca7v_sKI2nrH.nKcnm7IyGoD9V3Rgjvao168g_wIfD3AWVZuF4PB3Vp urx7uTc0CL93mJQGiYcHD0uYmELY_meWl7c9LA6wzUKS33oeHLafs1077vSF DS4a68UpJgw.fC4IGzRdLgkISZ0NyHp50_Or.addiLjfy0Z.AFemgdaTRx6k dvocIsMCZuCMXBQ4EhbGyKjfyGRNxYAcDefOOZLv0Gi6roKn.NDBVLc9ykLi _txZmT0472Lk9gsJXEneg_49DeG4Gfx0VeCcDxtdsr26kL2TCCtzoB.P0k6F jOMk9FpsIOOBmn2W1RYfZqy9ssRsgKOTIAgLUy_fd8bvo1655Q8SLirvyadR 4v0H8g.UGDd.IjcSMkjYu4JCJ9qOoJBV8S.QLOKMvsTy4 Received: from [150.101.221.237] by web142505.mail.bf1.yahoo.com via HTTP; Tue, 29 Oct 2013 13:23:40 PDT X-Rocket-MIMEInfo: 002.001, CgoKCi0tLS0tIE9yaWdpbmFsIE1lc3NhZ2UgLS0tLS0KPiBGcm9tOiAiV2VpbCwgSmFzb24iIDxqYXNvbi53ZWlsQHR3Y2FibGUuY29tPgo.IFRvOiBNYXJrIFpaWiBTbWl0aCA8bWFya3p6enNtaXRoQHlhaG9vLmNvbS5hdT47IExpdWJpbmcgKExlbykgPGxlby5saXViaW5nQGh1YXdlaS5jb20.OyBXdXl0cyBDYXJsIDxDYXJsLld1eXRzQHRlY2huaWNvbG9yLmNvbT47ICJzdGhhdWdAbmV0aGVscC5ubyIgPHN0aGF1Z0BuZXRoZWxwLm5vPgo.IENjOiAidjZvcHNAaWV0Zi5vcmciIDx2Nm9wc0BpZXRmLm9yZz4BMAEBAQE- X-Mailer: YahooMailWebService/0.8.160.587 References: <1383074892.1756.YahooMailNeo@web142504.mail.bf1.yahoo.com> Message-ID: <1383078220.37415.YahooMailNeo@web142505.mail.bf1.yahoo.com> Date: Tue, 29 Oct 2013 13:23:40 -0700 (PDT) From: Mark ZZZ Smith To: "Weil, Jason" , "Liubing \(Leo\)" , Wuyts Carl , "sthaug@nethelp.no" In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Cc: "v6ops@ietf.org" , "otroan@cisco.com" , "draft-liu-bonica-v6ops-dhcpv6-slaac-problem@tools.ietf.org" Subject: Re: [v6ops] DHCPv6/SLAAC Make Hosts Confusing-//RE: new draft: draft-liu-bonica-v6ops-dhcpv6-slaac-problem X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: Mark ZZZ Smith List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 29 Oct 2013 20:23:49 -0000 =0A=0A=0A=0A----- Original Message -----=0A> From: "Weil, Jason" =0A> To: Mark ZZZ Smith ; Liubing = (Leo) ; Wuyts Carl ; "s= thaug@nethelp.no" =0A> Cc: "v6ops@ietf.org" ; "otroan@cisco.com" ; "draft-liu-bonica-v6ops-dhcpv6= -slaac-problem@tools.ietf.org" =0A> Sent: Wednesday, 30 October 2013 6:59 AM=0A> Subject: = Re: [v6ops] DHCPv6/SLAAC Make Hosts Confusing-//RE: new draft: draft-liu-bo= nica-v6ops-dhcpv6-slaac-problem=0A> =0A> I wasn't claiming it was a problem= that a host has two addresses. I was=0A> just saying it might be beneficia= l in certain scenarios for all hosts on a=0A> network segment (SLAAC-only, = SLAAC+DHC, DHC-only) to have a single address=0A> created using the same al= gorithm.=0A>=A0=0A=0AOnce you have a host using two different address confi= guration methods at the same time (SLAAC+DHC), then I don't think it is pos= sible to avoid having a host have two addresses.=A0=0A=0ARegarding the usin= g the same algorithm, that is the reason why I asked for the text in the op= aque stable IID draft to not specifically limit the address generation algo= rithm specified in it to be limited to SLAAC. There is no reason why a stat= eful DHCPv6 server couldn't use the algorithm to generate IPv6 addresses/II= Ds before handing them to clients.=0A=0ARegards,=0AMark.=0A=0A=0A> Jason=0A= > =0A> =0A> On 10/29/13 3:28 PM, "Mark ZZZ Smith" =0A> wrote:=0A> =0A>> =0A>> =0A>> =0A>> =0A>> ----- Original Message ---= --=0A>>> From: "Weil, Jason" =0A>>> To: Liubing (= Leo) ; Wuyts Carl=0A>>> ; "sthaug@nethelp.no" =0A> =0A>>> Cc: "v6ops@ietf.org"= ; =0A> "otroan@cisco.com"=0A>>> ;=0A>>> = "draft-liu-bonica-v6ops-dhcpv6-slaac-problem@tools.ietf.org"=0A>>> =0A>>> Sent: Wednesday= , 30 October 2013 1:44 AM=0A>>> Subject: Re: [v6ops] DHCPv6/SLAAC Make Hos= ts Confusing-//RE: new draft:=0A>>> draft-liu-bonica-v6ops-dhcpv6-slaac-pro= blem=0A>>> =0A>>> Leo,=0A>>> =0A>>> First I wanted to say this is useful = work and I support it.=0A>>> =0A>>> This topic in this email reminds me of= an issue that we have run across=0A>>> that might be relevant to your dra= ft:=0A>>> =0A>>> The use case involves a home network whose gateway router= sets M=3D1 and=0A>>> A=3D1=0A>>> in order to provide DHC and and SLAAC fo= r hosts that do not implement a=0A>>> DHC client. If the DHCPv6 Server is = implementing IP assignment using=0A>>> interface-identifier and using the = same prefix as advertised in the PIO=0A>>> (assuming the server resides on= the router advertising the PIO) with=0A>>> the A=0A>>> bit set, hosts tha= t support SLAAC and a DHCPv6 client could construct=0A>>> the=0A>>> same a= ddress using DHC as the one they construct using SLAAC. What is=0A>>> not= =0A>>> clear is what hosts should do in this situation. IMO, there is a = =0A> benefit=0A>>> if hosts that support both SLAAC and DHCPv6 construct t= he address and=0A>>> prefer the DHC address over the SLAAC address. The be= nefit is that you=0A>>> reduce the number of active addresses and all host= s end up with a =0A> single=0A>>> address per prefix administered in this = fashion.=0A>>> =0A>>> Of course if your DHC Server implements another assi= gnment algorithm=0A>>> (e.g.=0A>>> Random) then your hosts that support bo= th may end up with 2 addresses=0A>>> out=0A>>> of the same prefix.=0A>>> = =0A>> =0A>> Another way to describe your scenario is that it is a transitio= n scenario=0A>> between SLAAC and stateful DHCPv6, since some of your hosts= don't =0A> support=0A>> stateful DHCPv6.=0A>> =0A>> In your scenario, I do= n't think it is a big problem that some of your=0A>> hosts will have two ad= dresses within the same prefix - IPv6 hosts are=0A>> designed to cope with = many addresses, and a /64 has plenty of addresses=0A>> to go around.=0A>> = =0A>> If you do want to be specifically selective about which hosts use SLA= AC=0A>> and which hosts use stateful DHCPv6 for addressing, use host specif= ic RAs=0A>> which set the M and the PIO A bits on a selected host basis.=0A= >> =0A>> Regards,=0A>> Mark.=0A> =0A> =0A> This E-mail and any of its attac= hments may contain Time Warner Cable proprietary =0A> information, which is= privileged, confidential, or subject to copyright =0A> belonging to Time W= arner Cable. This E-mail is intended solely for the use of =0A> the individ= ual or entity to which it is addressed. If you are not the intended =0A> re= cipient of this E-mail, you are hereby notified that any dissemination, =0A= > distribution, copying, or action taken in relation to the contents of and= =0A> attachments to this E-mail is strictly prohibited and may be unlawful= . If you =0A> have received this E-mail in error, please notify the sender = immediately and =0A> permanently delete the original and any copy of this E= -mail and any printout.=0A> From brian@innovationslab.net Tue Oct 29 13:26:54 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2922911E81C3 for ; Tue, 29 Oct 2013 13:26:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.663 X-Spam-Level: X-Spam-Status: No, score=-102.663 tagged_above=-999 required=5 tests=[AWL=-0.064, 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 Kom4YCFz4C4X for ; Tue, 29 Oct 2013 13:26:47 -0700 (PDT) Received: from uillean.fuaim.com (uillean.fuaim.com [206.197.161.140]) by ietfa.amsl.com (Postfix) with ESMTP id BC97E21E809D for ; Tue, 29 Oct 2013 13:26:35 -0700 (PDT) Received: from clairseach.fuaim.com (clairseach-high.fuaim.com [206.197.161.158]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by uillean.fuaim.com (Postfix) with ESMTP id AAA238809F for ; Tue, 29 Oct 2013 13:26:35 -0700 (PDT) Received: from 102527254.rudm1.ra.johnshopkins.edu (addr16212925014.ippl.jhmi.edu [162.129.250.14]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by clairseach.fuaim.com (Postfix) with ESMTP id 70F3F130003 for ; Tue, 29 Oct 2013 13:26:35 -0700 (PDT) Message-ID: <527019EC.3090508@innovationslab.net> Date: Tue, 29 Oct 2013 16:26:20 -0400 From: Brian Haberman User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:24.0) Gecko/20100101 Thunderbird/24.0.1 MIME-Version: 1.0 To: v6ops@ietf.org References: <06601039-CAFD-49B0-918B-A8ACD51B978D@fugue.com> <1383036443.56704.YahooMailNeo@web142501.mail.bf1.yahoo.com> <1383074208.73179.YahooMailNeo@web142505.mail.bf1.yahoo.com> In-Reply-To: X-Enigmail-Version: 1.6 Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="V6HuDkShGobC6L4ADaCBp5wLxsjbsFHGw" Subject: Re: [v6ops] DHCPv6/SLAAC Make Hosts Confusing-//RE: new draft: draft-liu-bonica-v6ops-dhcpv6-slaac-problem X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 29 Oct 2013 20:26:54 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --V6HuDkShGobC6L4ADaCBp5wLxsjbsFHGw Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Hi Andrew, On 10/29/13 4:20 PM, Andrew Yourtchenko wrote: >=20 >=20 > Take a look and see if this captures the things any better. >=20 > It's a very tricky section. There's an intertwine of "DHCPv6 was not=20 > allowed to do any routing" + the implicit "I got an RA therefore > that router exists" (though "I got a DHCP offer from that router > therefore that router exists" is also can be argued for) + the But you do not know that the DHCPv6 message you received came from a router or a server. Regards, Brian --V6HuDkShGobC6L4ADaCBp5wLxsjbsFHGw Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG/MacGPG2 v2.0.20 (Darwin) Comment: GPGTools - https://gpgtools.org iQEcBAEBCgAGBQJScBnsAAoJEBOZRqCi7goqOI8IAKLkGYkSNfKKMxAYWLMhZYBP WLd0MlNvRwdI2lMWiqtdF4n8NyHn4dkiRIJdDeeUt6lmY0WU50MWmaLMwKb+ojOD a04hQRzV7F1cnUyXYE5MlSUEaLYoNGfvxyPVeaVfUtPcQGz9uUPCK+udMfdE5ptk Nvbj1ow7pEKBw52B2N6I20yl5W+aOnlBTZ3S0zSF36k3tn2c5ipyfCMHpBkHNeGU W0Jwn7N52d/VBSVSfQu0qXd39Hnkd2kX/XIAQRCW3hE5gkaLb/J2sOIC056I3iBk mfEh/01aQcLSrp6eOrujpxrLrRLCVcji3EkKAlnA79b+WhKkxthJ+4i6zpssNaA= =x6Jb -----END PGP SIGNATURE----- --V6HuDkShGobC6L4ADaCBp5wLxsjbsFHGw-- From ayourtch@cisco.com Tue Oct 29 13:53:26 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B6B5621F9AED for ; Tue, 29 Oct 2013 13:53:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.419 X-Spam-Level: X-Spam-Status: No, score=-10.419 tagged_above=-999 required=5 tests=[AWL=0.180, 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 FQB0v62JpGYE for ; Tue, 29 Oct 2013 13:53:21 -0700 (PDT) Received: from rcdn-iport-2.cisco.com (rcdn-iport-2.cisco.com [173.37.86.73]) by ietfa.amsl.com (Postfix) with ESMTP id 8F82611E81C8 for ; Tue, 29 Oct 2013 13:53:05 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=819; q=dns/txt; s=iport; t=1383079985; x=1384289585; h=date:from:to:cc:subject:in-reply-to:message-id: references:mime-version; bh=tdD1KVLDqQm3X/FF1HcQ2uER3RXuiK1xg/r8PbZRZAk=; b=iBjVqCZaXfrn090Nrh8ZT9DG22KWfYtEUE5AonkjhF/n5blpwonX23EC zVDtD4bgJfq2PL0O7q1yG3Ef+83DEJh26tR6CmjAgUSnY6MGWVXIs2tpr Ii1f+TOyqkcySSJk6KLFQpZ85ncF6IGRYi0uxtzxezw8pDSI9xB8+hp45 0=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgUFAIgfcFKtJXG+/2dsb2JhbABZgweBDL81gS0WdIIlAQEBAwE4Aj8FCwsYIwtXBg6IBga6V49BB4QsA55Gi0yBaIE/gik X-IronPort-AV: E=Sophos;i="4.93,595,1378857600"; d="scan'208";a="278129428" Received: from rcdn-core2-3.cisco.com ([173.37.113.190]) by rcdn-iport-2.cisco.com with ESMTP; 29 Oct 2013 20:53:05 +0000 Received: from xhc-rcd-x04.cisco.com (xhc-rcd-x04.cisco.com [173.37.183.78]) by rcdn-core2-3.cisco.com (8.14.5/8.14.5) with ESMTP id r9TKr5tR018153 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 29 Oct 2013 20:53:05 GMT Received: from [10.61.200.140] (10.61.200.140) by xhc-rcd-x04.cisco.com (173.37.183.78) with Microsoft SMTP Server (TLS) id 14.2.318.4; Tue, 29 Oct 2013 15:52:58 -0500 Date: Tue, 29 Oct 2013 21:52:40 +0100 From: Andrew Yourtchenko X-X-Sender: ayourtch@ayourtch-mac To: Brian Haberman In-Reply-To: <527019EC.3090508@innovationslab.net> Message-ID: References: <06601039-CAFD-49B0-918B-A8ACD51B978D@fugue.com> <1383036443.56704.YahooMailNeo@web142501.mail.bf1.yahoo.com> <1383074208.73179.YahooMailNeo@web142505.mail.bf1.yahoo.com> <527019EC.3090508@innovationslab.net> User-Agent: Alpine 2.00 (OSX 1167 2008-08-23) MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII"; format=flowed X-Originating-IP: [10.61.200.140] Cc: v6ops@ietf.org Subject: Re: [v6ops] DHCPv6/SLAAC Make Hosts Confusing-//RE: new draft: draft-liu-bonica-v6ops-dhcpv6-slaac-problem X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 29 Oct 2013 20:53:26 -0000 On Tue, 29 Oct 2013, Brian Haberman wrote: > Hi Andrew, > > On 10/29/13 4:20 PM, Andrew Yourtchenko wrote: >> >> >> Take a look and see if this captures the things any better. >> >> It's a very tricky section. There's an intertwine of "DHCPv6 was not >> allowed to do any routing" + the implicit "I got an RA therefore >> that router exists" (though "I got a DHCP offer from that router >> therefore that router exists" is also can be argued for) + the > > But you do not know that the DHCPv6 message you received came from a > router or a server. Thanks. Not sure whether it should actually be another section or not - "Control plane and data plane" - RAs are sent by an entity that is in the path, whereas the DHCPv6 may be sent by an off-path entity... --a > > Regards, > Brian > > From brian.e.carpenter@gmail.com Tue Oct 29 14:28:06 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D135F11E81DF for ; Tue, 29 Oct 2013 14:28:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.455 X-Spam-Level: X-Spam-Status: No, score=-102.455 tagged_above=-999 required=5 tests=[AWL=0.144, 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 Q5NY+v9gzr-I for ; Tue, 29 Oct 2013 14:28:06 -0700 (PDT) Received: from mail-pa0-x22f.google.com (mail-pa0-x22f.google.com [IPv6:2607:f8b0:400e:c03::22f]) by ietfa.amsl.com (Postfix) with ESMTP id 4B4F411E81E6 for ; Tue, 29 Oct 2013 14:28:06 -0700 (PDT) Received: by mail-pa0-f47.google.com with SMTP id lf10so613186pab.34 for ; Tue, 29 Oct 2013 14:27:59 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:organization:user-agent:mime-version:to:cc :subject:references:in-reply-to:content-type :content-transfer-encoding; bh=l6+eIcblnYl0D2Q/0jVIb6zz+BGhhlQiTZgzBbvswqA=; b=Q4Su/xzlHZeDay36Pp9d50ot1z1NMHSbwpONvu6FdxqbesFhkNfx1yCZFmtne1ZI3m nnjAPxSf5hb6Aj8nHqbza4d0kqvkfr+SR8STcc5bLxvs0rR8u1Ow1YvZL1X0K5W8lOfb eGKZdFWZN2gOJ2cpcjRvkliYWQl6pZvSSOjGFZPWVna28Nzi0NOXsvli+YsPOOYiY5le JG8HV/urDtYNCzX67f/wTFz2qvandV4PFy/bKAbow471AF/Cn77PIZUbDPihehePw3h9 GJjWjBY4QSwo4lWuk3eMAi1J0EcvHj7zig65FAURW9DV9gq6h9mLAhpH85owTPYEjH0P mz1w== X-Received: by 10.68.180.131 with SMTP id do3mr1760444pbc.34.1383082079500; Tue, 29 Oct 2013 14:27:59 -0700 (PDT) Received: from [130.216.38.108] ([130.216.38.108]) by mx.google.com with ESMTPSA id qn1sm36954142pbc.34.2013.10.29.14.27.56 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Tue, 29 Oct 2013 14:27:58 -0700 (PDT) Message-ID: <52702860.9090503@gmail.com> Date: Wed, 30 Oct 2013 10:28:00 +1300 From: Brian E Carpenter Organization: University of Auckland User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: Mark ZZZ Smith References: <06601039-CAFD-49B0-918B-A8ACD51B978D@fugue.com> <1383036443.56704.YahooMailNeo@web142501.mail.bf1.yahoo.com> In-Reply-To: <1383036443.56704.YahooMailNeo@web142501.mail.bf1.yahoo.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: "v6ops@ietf.org" , Ted Lemon , "Ole Troan \(otroan\)" , Dave Thaler , "draft-liu-bonica-v6ops-dhcpv6-slaac-problem@tools.ietf.org" Subject: [v6ops] Link layer lossage [DHCPv6/SLAAC Make Hosts Confusing-//RE: new draft: draft-liu-bonica-v6ops-dhcpv6-slaac-problem] X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 29 Oct 2013 21:28:07 -0000 On 29/10/2013 21:47, Mark ZZZ Smith wrote: > If the packet loss is too high, then link-layer designers are advised to use link-layer reliability mechanisms, as per advised in RFC3819. That may in fact be exactly the wrong advice. At least, the results I've seen on Coded TCP suggest that retransmission managed by the link layer can do more harm than good, compared to a smart transport layer designed for uncongested lossy paths. (Conventional TCP is a different matter, which is why RFC 3819 says what it says.) Brian From nick@inex.ie Tue Oct 29 14:51:04 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 596CE11E829E for ; Tue, 29 Oct 2013 14:51:04 -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 CLJHBbxgqISZ for ; Tue, 29 Oct 2013 14:51:03 -0700 (PDT) Received: from mail.netability.ie (mail.netability.ie [IPv6:2a03:8900:0:100::5]) by ietfa.amsl.com (Postfix) with ESMTP id 33BEB11E8264 for ; Tue, 29 Oct 2013 14:51:02 -0700 (PDT) X-Envelope-To: Received: from cupcake.foobar.org ([IPv6:2001:4d68:2002:100::110]) (authenticated bits=0) by mail.netability.ie (8.14.7/8.14.5) with ESMTP id r9TLowQp025270 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO) for ; Tue, 29 Oct 2013 21:50:59 GMT (envelope-from nick@inex.ie) X-Authentication-Warning: cheesecake.netability.ie: Host [IPv6:2001:4d68:2002:100::110] claimed to be cupcake.foobar.org Message-ID: <52702DC2.1080507@inex.ie> Date: Tue, 29 Oct 2013 21:50:58 +0000 From: Nick Hilliard User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:17.0) Gecko/20130801 Thunderbird/17.0.8 MIME-Version: 1.0 To: v6ops@ietf.org References: <06601039-CAFD-49B0-918B-A8ACD51B978D@fugue.com> <1383036443.56704.YahooMailNeo@web142501.mail.bf1.yahoo.com> <1383074208.73179.YahooMailNeo@web142505.mail.bf1.yahoo.com> In-Reply-To: X-Enigmail-Version: 1.6 X-Company-Info-1: Internet Neutral Exchange Association Limited. Registered in Ireland No. 253804 X-Company-Info-2: Registered Offices: 1-2, Marino Mart, Fairview, Dublin 3 X-Company-Info-3: Internet Neutral Exchange Association Limited is limited by guarantee X-Company-Info-4: Offices: 4027 Kingswood Road, Citywest, Dublin 24. Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: Re: [v6ops] DHCPv6/SLAAC Make Hosts Confusing-//RE: new draft: draft-liu-bonica-v6ops-dhcpv6-slaac-problem X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 29 Oct 2013 21:51:04 -0000 On 29/10/2013 20:20, Andrew Yourtchenko wrote: > debate - maybe worth just folding it back into a pure factual "It was > decided that RA does routing, DHCPv6 does not, by the way RA does a slow > redundancy, which people do not like, therefore they think DHCPv6 should do > routing". WFM, and I very much like your draft so far, btw. Later on in the text, it says: > However, the "single source of truth" nature of DHCPv6 prevents the > successful operation in case of multiple servers on the segment > supplying different information. RAs in this case may still work. > > Some consider the inability to support this scenario crucial, and > some think it is not useful. This creates contention between the > proponents of those who want DHCPv6 deal with routing, and those who > think RA is the single possible candidate for that. > > The other aspect is that because RA ties in the routing and > addressing information, one can say "RA shares the fate with > routing". However, this distinction is merely because of the > decision to explicitly keep DHCPv6 away from routing - so can not be > considered a true property of the protocol. The premise that many people in the IETF seem to be working on is that the typical - or even a common - deployment case of ipv6 will involve multiple routers per lan segment. I say this because every time the issue of DHCP providing a defgw comes up, one of the main arguments that's trotted out is that it will break the multiple-routers-per-lan-segment scenario. The above 3 paragraphs also strongly hint at this as being the target deployment. Well maybe dhcpv6 doesn't do that, but the operational reality is that multiple gateways on the same lan is going to be the rare exception rather than the rule. The reason why I think this is because: 1. enterprises have an obtuse obsession for L2. They'd pave the world with L2 and extend L2 from one end of the universe to the other if they could. Just look at the horror of vxlan (who are they kidding? themselves?) as a perfect example of this insanity. I don't know why this is but it's the way that lots of enterprise rolls, ranging from SME to largish networks. Outside truly large operations (i.e. 10s of thousands of users), I have never got the impression that enterprises got L3 routing. 2. homenet: I don't understand the target audience for the entire homenet multiple network movement. Putting this another way: who is going to debug homenet multiple network stuff when it breaks, because as far as I can tell, that belongs in the realm of level 2 engineering escalation (i.e. $120/hr sort of thing). It's a little far-fetched to expect gramps and grandma to set up and maintain and debug multiple networking segments. A good chunk of the stuff going on in homenet is vastly more complicated than pretty much any home network is ever going to need. Architecturally interesting, but srsly not realistic as a viable approach to home networking. 3. service providers - the single operational group on the internet that actually understands L3 / network segmentation and why it's important - will attempt avoid multiple gateways per network like the plague because it makes their deployment scenarios more complicated and provides no extra value. For server / host farms, service providers like FHRP with tight timers because it gives control of onward connectivity. All of which doesn't leave very many more user-market segments. Regarding RA for routing and DHCP for addressing, what people care about is connectivity. What I need as an operator is a protocol (preferably a single protocol because that is simpler) which will enable my boxes to gain the connectivity they need. Whether you call this routing or providing a default gateway, I don't much mind. Look, there's too much ideology going on here. The IETF is being dazzled by the sight of multiple lan segments and multiple egress gateways without realising that these are the minority configuration. All this effort is going into optimising ipv6 address / lan autoconfiguration for these unusual scenarios without heeding the sober reality that most people, service providers and enterprises are only ever going to want to have a single defgw per lan segment, and that by far the most common deployment scenario will be a single lan segment per organisation. I'm aware that this viewpoint will be regarded as retrograde, and that a bunch of people on this list will probably sit there, rolling their eyes and thinking: "yeah, and 640k was enough for everyone". Just bear in mind that added complexity is not necessarily a good thing. The support costs are high and the return on effort is dubious at best. IOW, the IETF is optimising a corner case. This is not smart. Nick From nick@inex.ie Tue Oct 29 15:03:43 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5B37121F9D18 for ; Tue, 29 Oct 2013 15:03:43 -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 koMpbdHTL-aG for ; Tue, 29 Oct 2013 15:03:42 -0700 (PDT) Received: from mail.netability.ie (mail.netability.ie [IPv6:2a03:8900:0:100::5]) by ietfa.amsl.com (Postfix) with ESMTP id F001E21F9D28 for ; Tue, 29 Oct 2013 15:03:41 -0700 (PDT) X-Envelope-To: v6ops@ietf.org Received: from cupcake.foobar.org ([IPv6:2001:4d68:2002:100::110]) (authenticated bits=0) by mail.netability.ie (8.14.7/8.14.5) with ESMTP id r9TM3ZQZ025350 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO); Tue, 29 Oct 2013 22:03:35 GMT (envelope-from nick@inex.ie) X-Authentication-Warning: cheesecake.netability.ie: Host [IPv6:2001:4d68:2002:100::110] claimed to be cupcake.foobar.org Message-ID: <527030B7.40206@inex.ie> Date: Tue, 29 Oct 2013 22:03:35 +0000 From: Nick Hilliard User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:17.0) Gecko/20130801 Thunderbird/17.0.8 MIME-Version: 1.0 To: Andrew Yourtchenko References: <06601039-CAFD-49B0-918B-A8ACD51B978D@fugue.com> <1383036443.56704.YahooMailNeo@web142501.mail.bf1.yahoo.com> <1383074208.73179.YahooMailNeo@web142505.mail.bf1.yahoo.com> <527019EC.3090508@innovationslab.net> In-Reply-To: X-Enigmail-Version: 1.6 X-Company-Info-1: Internet Neutral Exchange Association Limited. Registered in Ireland No. 253804 X-Company-Info-2: Registered Offices: 1-2, Marino Mart, Fairview, Dublin 3 X-Company-Info-3: Internet Neutral Exchange Association Limited is limited by guarantee X-Company-Info-4: Offices: 4027 Kingswood Road, Citywest, Dublin 24. Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: v6ops@ietf.org Subject: Re: [v6ops] DHCPv6/SLAAC Make Hosts Confusing-//RE: new draft: draft-liu-bonica-v6ops-dhcpv6-slaac-problem X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 29 Oct 2013 22:03:43 -0000 On 29/10/2013 20:52, Andrew Yourtchenko wrote: > Thanks. Not sure whether it should actually be another section or not - > "Control plane and data plane" - RAs are sent by an entity that is in the > path, whereas the DHCPv6 may be sent by an off-path entity... this brings up another important issue, namely source address validation. I'm not sure if it's relevant to bring this up in your draft, but the requirement to handle snooping two new protocols for effective lan source address validation seems to be more than most vendors can handle at the moment, which means that as operators we are very exposed to rogue RAs and rogue DHCPv6 packets flying around networks. [Once upon a time, all we needed was vendor support for dhcp snooping and ARP inspection. Now we need an entire IETF working group to handle the complication that the IETF has brought upon itself by overthinking ipv6 lan requirements. Is this progress?] Nick From nick@inex.ie Tue Oct 29 15:05:26 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AAD5321E8094 for ; Tue, 29 Oct 2013 15:05:26 -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 TL97iLAlubzv for ; Tue, 29 Oct 2013 15:05:26 -0700 (PDT) Received: from mail.netability.ie (mail.netability.ie [IPv6:2a03:8900:0:100::5]) by ietfa.amsl.com (Postfix) with ESMTP id 720CD21E809C for ; Tue, 29 Oct 2013 15:05:22 -0700 (PDT) X-Envelope-To: v6ops@ietf.org Received: from cupcake.foobar.org ([IPv6:2001:4d68:2002:100::110]) (authenticated bits=0) by mail.netability.ie (8.14.7/8.14.5) with ESMTP id r9TM5FHU025363 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO); Tue, 29 Oct 2013 22:05:15 GMT (envelope-from nick@inex.ie) X-Authentication-Warning: cheesecake.netability.ie: Host [IPv6:2001:4d68:2002:100::110] claimed to be cupcake.foobar.org Message-ID: <5270311B.5010703@inex.ie> Date: Tue, 29 Oct 2013 22:05:15 +0000 From: Nick Hilliard User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:17.0) Gecko/20130801 Thunderbird/17.0.8 MIME-Version: 1.0 To: Brian E Carpenter References: <06601039-CAFD-49B0-918B-A8ACD51B978D@fugue.com> <1383036443.56704.YahooMailNeo@web142501.mail.bf1.yahoo.com> <52702860.9090503@gmail.com> In-Reply-To: <52702860.9090503@gmail.com> X-Enigmail-Version: 1.6 X-Company-Info-1: Internet Neutral Exchange Association Limited. Registered in Ireland No. 253804 X-Company-Info-2: Registered Offices: 1-2, Marino Mart, Fairview, Dublin 3 X-Company-Info-3: Internet Neutral Exchange Association Limited is limited by guarantee X-Company-Info-4: Offices: 4027 Kingswood Road, Citywest, Dublin 24. Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: "v6ops@ietf.org" , "draft-liu-bonica-v6ops-dhcpv6-slaac-problem@tools.ietf.org" Subject: Re: [v6ops] Link layer lossage [DHCPv6/SLAAC Make Hosts Confusing-//RE: new draft: draft-liu-bonica-v6ops-dhcpv6-slaac-problem] X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 29 Oct 2013 22:05:26 -0000 On 29/10/2013 21:28, Brian E Carpenter wrote: > That may in fact be exactly the wrong advice. At least, the results > I've seen on Coded TCP suggest that retransmission managed by the link > layer can do more harm than good, compared to a smart transport layer > designed for uncongested lossy paths. if you could explain it to my GPRS cellular provider that doing 40 second RTT isn't actually helpful, I'd really appreciate it. Particularly when all the retransmissions count towards my monthly data budget. Nick From ayourtch@cisco.com Tue Oct 29 15:39:26 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5851011E8214 for ; Tue, 29 Oct 2013 15:39:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.449 X-Spam-Level: X-Spam-Status: No, score=-10.449 tagged_above=-999 required=5 tests=[AWL=0.150, 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 KeiNmZFocxS0 for ; Tue, 29 Oct 2013 15:39:20 -0700 (PDT) Received: from rcdn-iport-8.cisco.com (rcdn-iport-8.cisco.com [173.37.86.79]) by ietfa.amsl.com (Postfix) with ESMTP id A27E611E81CC for ; Tue, 29 Oct 2013 15:39:20 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1529; q=dns/txt; s=iport; t=1383086360; x=1384295960; h=date:from:to:cc:subject:in-reply-to:message-id: references:mime-version; bh=4W7LR7Smjr88kF+1PCUeH59HoG/+rJ8jxDPnqbcaLt4=; b=QPOKQdWT62qE4g/rH7hrw5rLbG6CGn6DX0PtU5Z7ygVSmc5cE5XsvPx/ hlxCJp2yF8C1w0QGAvRqL4APzPaNSB3f213Gi2D79vNOlOOMbGT9wzzqj DfPUADYp2cY9kK9n/YmrynEYNk9+q73Bsv3+vBgsonlo03tSaP0YsDRY1 o=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgcFAOc3cFKtJXG+/2dsb2JhbABZgweBDLw+gnqBKxZ0giUBAQEDATgCMg0FCwsYIwtXBg6IBga6c49BB4QsA55Gi0yBaIE/gWkkHA X-IronPort-AV: E=Sophos;i="4.93,596,1378857600"; d="scan'208";a="278212001" Received: from rcdn-core2-3.cisco.com ([173.37.113.190]) by rcdn-iport-8.cisco.com with ESMTP; 29 Oct 2013 22:39:04 +0000 Received: from xhc-rcd-x04.cisco.com (xhc-rcd-x04.cisco.com [173.37.183.78]) by rcdn-core2-3.cisco.com (8.14.5/8.14.5) with ESMTP id r9TMd3AF025013 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 29 Oct 2013 22:39:03 GMT Received: from [10.61.200.140] (10.61.200.140) by xhc-rcd-x04.cisco.com (173.37.183.78) with Microsoft SMTP Server (TLS) id 14.2.318.4; Tue, 29 Oct 2013 17:39:03 -0500 Date: Tue, 29 Oct 2013 23:38:44 +0100 From: Andrew Yourtchenko X-X-Sender: ayourtch@ayourtch-mac To: Nick Hilliard In-Reply-To: <527030B7.40206@inex.ie> Message-ID: References: <06601039-CAFD-49B0-918B-A8ACD51B978D@fugue.com> <1383036443.56704.YahooMailNeo@web142501.mail.bf1.yahoo.com> <1383074208.73179.YahooMailNeo@web142505.mail.bf1.yahoo.com> <527019EC.3090508@innovationslab.net> <527030B7.40206@inex.ie> User-Agent: Alpine 2.00 (OSX 1167 2008-08-23) MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII"; format=flowed X-Originating-IP: [10.61.200.140] Cc: v6ops@ietf.org Subject: Re: [v6ops] DHCPv6/SLAAC Make Hosts Confusing-//RE: new draft: draft-liu-bonica-v6ops-dhcpv6-slaac-problem X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 29 Oct 2013 22:39:26 -0000 On Tue, 29 Oct 2013, Nick Hilliard wrote: > On 29/10/2013 20:52, Andrew Yourtchenko wrote: >> Thanks. Not sure whether it should actually be another section or not - >> "Control plane and data plane" - RAs are sent by an entity that is in the >> path, whereas the DHCPv6 may be sent by an off-path entity... > > this brings up another important issue, namely source address validation. > > I'm not sure if it's relevant to bring this up in your draft, but the > requirement to handle snooping two new protocols for effective lan source > address validation seems to be more than most vendors can handle at the > moment, which means that as operators we are very exposed to rogue RAs and > rogue DHCPv6 packets flying around networks. > > [Once upon a time, all we needed was vendor support for dhcp snooping and > ARP inspection. Now we need an entire IETF working group to handle the > complication that the IETF has brought upon itself by overthinking ipv6 lan > requirements. Is this progress?] [ It creates the jobs lost due to simplicity gained by the absence of NATs. :-) ] I've captured the non-bracketed part of your comment into a separate section, even if it is not really a comparison. Maybe given that all the rest of the bullet points is implicitly "Reasons for keeping both of the protocols implemented in the nodes - they are useful in different circumstances", I should create a part "Reasons for having only one of the protocols running in a particular network" ? --a From nick@inex.ie Tue Oct 29 15:47:35 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A625111E81CC for ; Tue, 29 Oct 2013 15:47:35 -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 ui+mlSex7W2L for ; Tue, 29 Oct 2013 15:47:35 -0700 (PDT) Received: from mail.netability.ie (mail.netability.ie [IPv6:2a03:8900:0:100::5]) by ietfa.amsl.com (Postfix) with ESMTP id 7A5F111E82A4 for ; Tue, 29 Oct 2013 15:47:20 -0700 (PDT) X-Envelope-To: v6ops@ietf.org Received: from cupcake.foobar.org ([IPv6:2001:4d68:2002:100::110]) (authenticated bits=0) by mail.netability.ie (8.14.7/8.14.5) with ESMTP id r9TMlDXQ025578 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO); Tue, 29 Oct 2013 22:47:14 GMT (envelope-from nick@inex.ie) X-Authentication-Warning: cheesecake.netability.ie: Host [IPv6:2001:4d68:2002:100::110] claimed to be cupcake.foobar.org Message-ID: <52703AF1.8000701@inex.ie> Date: Tue, 29 Oct 2013 22:47:13 +0000 From: Nick Hilliard User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:17.0) Gecko/20130801 Thunderbird/17.0.8 MIME-Version: 1.0 To: Andrew Yourtchenko References: <06601039-CAFD-49B0-918B-A8ACD51B978D@fugue.com> <1383036443.56704.YahooMailNeo@web142501.mail.bf1.yahoo.com> <1383074208.73179.YahooMailNeo@web142505.mail.bf1.yahoo.com> <527019EC.3090508@innovationslab.net> <527030B7.40206@inex.ie> In-Reply-To: X-Enigmail-Version: 1.6 X-Company-Info-1: Internet Neutral Exchange Association Limited. Registered in Ireland No. 253804 X-Company-Info-2: Registered Offices: 1-2, Marino Mart, Fairview, Dublin 3 X-Company-Info-3: Internet Neutral Exchange Association Limited is limited by guarantee X-Company-Info-4: Offices: 4027 Kingswood Road, Citywest, Dublin 24. Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: v6ops@ietf.org Subject: Re: [v6ops] DHCPv6/SLAAC Make Hosts Confusing-//RE: new draft: draft-liu-bonica-v6ops-dhcpv6-slaac-problem X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 29 Oct 2013 22:47:35 -0000 On 29/10/2013 22:38, Andrew Yourtchenko wrote: > Maybe given that all the rest of the bullet points is implicitly "Reasons > for keeping both of the protocols implemented in the nodes - they are > useful in different circumstances", I should create a part "Reasons for > having only one of the protocols running in a particular network" ? i think this would be useful, yes. Nick From ayourtch@cisco.com Tue Oct 29 15:56:02 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4D52311E829E for ; Tue, 29 Oct 2013 15:56:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.47 X-Spam-Level: X-Spam-Status: No, score=-10.47 tagged_above=-999 required=5 tests=[AWL=0.129, 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 3+AgJmGlHbsw for ; Tue, 29 Oct 2013 15:55:56 -0700 (PDT) Received: from rcdn-iport-5.cisco.com (rcdn-iport-5.cisco.com [173.37.86.76]) by ietfa.amsl.com (Postfix) with ESMTP id 459E111E8264 for ; Tue, 29 Oct 2013 15:55:49 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=453; q=dns/txt; s=iport; t=1383087349; x=1384296949; h=date:from:to:cc:subject:in-reply-to:message-id: references:mime-version; bh=e1wHy/bf6rdvGRv5EnK+eZpedBwKlGTs0VlxxZl3RXs=; b=SlRC2zhBK21aTTL45GNSBUpeTup4fruufSpnpwnrOvrGKhHSiXQteb7w ej8WNDL7mffleNlf75CD4PUJVvks1FGrk/ZE7NaiAcBtCy7F+Jicp65yX tBQgF2jmbfSOIKRm+CXTr1WeXAiII0Y8L+TQCU7LBjvhpL3taRv4W3Obz Y=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgcFAKA7cFKtJV2Z/2dsb2JhbABZgweBDLw/gnqBKhZ0giUBAQEDATgCPwULCxgjC1cGDogGBrp1j0EHhCwDnkaLTIFogT+CKQ X-IronPort-AV: E=Sophos;i="4.93,596,1378857600"; d="scan'208";a="278206878" Received: from rcdn-core-2.cisco.com ([173.37.93.153]) by rcdn-iport-5.cisco.com with ESMTP; 29 Oct 2013 22:55:49 +0000 Received: from xhc-rcd-x04.cisco.com (xhc-rcd-x04.cisco.com [173.37.183.78]) by rcdn-core-2.cisco.com (8.14.5/8.14.5) with ESMTP id r9TMtme0008130 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 29 Oct 2013 22:55:48 GMT Received: from [10.61.200.140] (10.61.200.140) by xhc-rcd-x04.cisco.com (173.37.183.78) with Microsoft SMTP Server (TLS) id 14.2.318.4; Tue, 29 Oct 2013 17:55:42 -0500 Date: Tue, 29 Oct 2013 23:55:24 +0100 From: Andrew Yourtchenko X-X-Sender: ayourtch@ayourtch-mac To: Nick Hilliard In-Reply-To: <52703AF1.8000701@inex.ie> Message-ID: References: <06601039-CAFD-49B0-918B-A8ACD51B978D@fugue.com> <1383036443.56704.YahooMailNeo@web142501.mail.bf1.yahoo.com> <1383074208.73179.YahooMailNeo@web142505.mail.bf1.yahoo.com> <527019EC.3090508@innovationslab.net> <527030B7.40206@inex.ie> <52703AF1.8000701@inex.ie> User-Agent: Alpine 2.00 (OSX 1167 2008-08-23) MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII"; format=flowed X-Originating-IP: [10.61.200.140] Cc: v6ops@ietf.org Subject: Re: [v6ops] DHCPv6/SLAAC Make Hosts Confusing-//RE: new draft: draft-liu-bonica-v6ops-dhcpv6-slaac-problem X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 29 Oct 2013 22:56:02 -0000 On Tue, 29 Oct 2013, Nick Hilliard wrote: > On 29/10/2013 22:38, Andrew Yourtchenko wrote: >> Maybe given that all the rest of the bullet points is implicitly "Reasons >> for keeping both of the protocols implemented in the nodes - they are >> useful in different circumstances", I should create a part "Reasons for >> having only one of the protocols running in a particular network" ? > > i think this would be useful, yes. Done. --a From markzzzsmith@yahoo.com.au Wed Oct 30 01:22:58 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 84C2921E8133 for ; Wed, 30 Oct 2013 01:22:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.943 X-Spam-Level: X-Spam-Status: No, score=-1.943 tagged_above=-999 required=5 tests=[AWL=0.156, BAYES_00=-2.599, FROM_LOCAL_NOVOWEL=0.5] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id P1k7ZmUo+Pfo for ; Wed, 30 Oct 2013 01:22:51 -0700 (PDT) Received: from nm31.bullet.mail.bf1.yahoo.com (nm31.bullet.mail.bf1.yahoo.com [72.30.239.198]) by ietfa.amsl.com (Postfix) with ESMTP id 39C5521F9649 for ; Wed, 30 Oct 2013 01:22:49 -0700 (PDT) Received: from [98.139.212.145] by nm31.bullet.mail.bf1.yahoo.com with NNFMP; 30 Oct 2013 08:22:48 -0000 Received: from [98.139.212.244] by tm2.bullet.mail.bf1.yahoo.com with NNFMP; 30 Oct 2013 08:22:48 -0000 Received: from [127.0.0.1] by omp1053.mail.bf1.yahoo.com with NNFMP; 30 Oct 2013 08:22:48 -0000 X-Yahoo-Newman-Property: ymail-3 X-Yahoo-Newman-Id: 548715.67679.bm@omp1053.mail.bf1.yahoo.com Received: (qmail 56768 invoked by uid 60001); 30 Oct 2013 08:22:48 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com.au; s=s1024; t=1383121368; bh=E+syyCwE6Lnxxzrj33wVfEaaqnPGWk8U99QlSY/Swc0=; h=X-YMail-OSG:Received:X-Rocket-MIMEInfo:X-Mailer:References:Message-ID:Date:From:Reply-To:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type:Content-Transfer-Encoding; b=auzyCjw+1siVhL60zxivZnMTAH46PFsIjBfF8MibSWKIwmpxv8hm12yPCy/5I62TojE44o85KeetmfN6RDdhAyeg4X9G91gAMbo94cANNLrfo1jmpP9PCic0lyQ2+Yp1XZXjrP9dPjazi18R4Jl39v0zWNnwJIjVoeP7kS9aZFk= DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com.au; h=X-YMail-OSG:Received:X-Rocket-MIMEInfo:X-Mailer:References:Message-ID:Date:From:Reply-To:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type:Content-Transfer-Encoding; b=H3XLkEht84vtp7rpsIFTMoDxBaTOADMADRVke9hLEfYOr6EeTjJdLbAeamnhYvpJLCs5P7i8nsDFzSeLCY3m+LIAhoVp8FrcI1sM8YgrXEFDbTQoe2voqIgO09ZkNIX/sNWnKEnDFlehPmIXYR+Tdq0EityVoiEGJDpbvyK47ys=; X-YMail-OSG: gY3uk.kVM1k0eG97z_MilirG7Hi_mA_b9MvNsC3QClpEKXG N4qvnDP3KPj7.P97hKl.hgrAtnLsxtLz_5fOHuwSN0usP0wN8jHd91HHmS5N raeDIQ3TmQsYHP7EMlaiQwLntySUOC70cupdaygw1EZpdJA0._ACDTtyG9R. ZNGQSV_0i53uDhpVp1ReecXSHraZK0aZNmzLyWX7FyakkqiaDBQCAJusiS4T ZGCXFHHqKTpPFK3yGWsimADeTFBIy9UvR7cJOHpTPIKSlVxYflPuw0it.zip yyU71su0yEpIwUyIaQcIzJHZuXPD1o3r9P2eH3BsOrKhkxfE12rY3.3MJoDd g7MT47SSB8Jahn8i1wR3TzogMp0wOwS.vOJnlB0MqK6kj.Kdr_6j5WWNLsq1 VDGTBCyPNOXk_2EK2.qA_2XGccett06H1.tEP_GYZ98qEWDFNofIl8z8ccmY cmWEirRRztt5oKknehvcPwi585a8Dn5JS7TkRJkuwkC6OmUfWYlDOcOUynQY nAR.9Psflt.dWzlM.f_zCi8OA9kg.2rg_dSC3hFozyIkNZmkuW5Vj_20vw3x dc32OZYENtLaM9tXR1XoDS5zjBeHt6S2StVHf6DNj2eMsJtkH3XGG_GKGk7H hj_.cy7XTHgzbCdT0rhvGjc0IyDbx2Igl3324.EpEMS0DhMVXLHoAQK9vAB4 JCtBTLdzyQ2PwAoCAIfbBfrWBcoION2pSp8rnrve62Z_wrnA0eXv7_aOpQPa 4sFnLf6MUvQrgr5AleU0EvkFo8KFzI5JjhMoB_7KJ1_p_OXTOqRIX221TMXG T1njSIw-- Received: from [150.101.221.237] by web142505.mail.bf1.yahoo.com via HTTP; Wed, 30 Oct 2013 01:22:48 PDT X-Rocket-MIMEInfo: 002.001, CgoKCi0tLS0tIE9yaWdpbmFsIE1lc3NhZ2UgLS0tLS0KPiBGcm9tOiBBbmRyZXcgWW91cnRjaGVua28gPGF5b3VydGNoQGNpc2NvLmNvbT4KPiBUbzogTG9yZW56byBDb2xpdHRpIDxsb3JlbnpvQGdvb2dsZS5jb20.Cj4gQ2M6IE1hcmsgWlpaIFNtaXRoIDxtYXJrenp6c21pdGhAeWFob28uY29tLmF1PjsgImRyYWZ0LWxpdS1ib25pY2EtdjZvcHMtZGhjcHY2LXNsYWFjLXByb2JsZW1AdG9vbHMuaWV0Zi5vcmciIDxkcmFmdC1saXUtYm9uaWNhLXY2b3BzLWRoY3B2Ni1zbGFhYy1wcm9ibGVtQHRvb2xzLmlldGYBMAEBAQE- X-Mailer: YahooMailWebService/0.8.160.587 References: <06601039-CAFD-49B0-918B-A8ACD51B978D@fugue.com> <1383036443.56704.YahooMailNeo@web142501.mail.bf1.yahoo.com> <1383074208.73179.YahooMailNeo@web142505.mail.bf1.yahoo.com> Message-ID: <1383121368.56079.YahooMailNeo@web142505.mail.bf1.yahoo.com> Date: Wed, 30 Oct 2013 01:22:48 -0700 (PDT) From: Mark ZZZ Smith To: Andrew Yourtchenko , Lorenzo Colitti In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Cc: "v6ops@ietf.org" , Dave Thaler , Ted Lemon , "Ole Troan \(otroan\)" , "draft-liu-bonica-v6ops-dhcpv6-slaac-problem@tools.ietf.org" Subject: Re: [v6ops] DHCPv6/SLAAC Make Hosts Confusing-//RE: new draft: draft-liu-bonica-v6ops-dhcpv6-slaac-problem X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: Mark ZZZ Smith List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 30 Oct 2013 08:22:59 -0000 =0A=0A=0A=0A----- Original Message -----=0A> From: Andrew Yourtchenko =0A> To: Lorenzo Colitti =0A> Cc: Mark Z= ZZ Smith ; "draft-liu-bonica-v6ops-dhcpv6-slaac-= problem@tools.ietf.org" ; "v6ops@ietf.org" ; Ted Lemon ;= Ole Troan (otroan) ; Dave Thaler = =0A> Sent: Wednesday, 30 October 2013 7:20 AM=0A> Subject: Re: [v6ops] DHCP= v6/SLAAC Make Hosts Confusing-//RE: new draft: draft-liu-bonica-v6ops-dhcpv= 6-slaac-problem=0A> =0A> =0A> =0A> On Wed, 30 Oct 2013, Lorenzo Colitti wro= te:=0A> =0A>> On Wed, Oct 30, 2013 at 4:33 AM, Andrew Yourtchenko =0A> wrote:=0A>> =A0 =A0 =A0 Essence of that section: RA deal= s with routing [not always very =0A> efficently]. DHCPv6 does not do it at = all.=0A>> =0A>> =0A>> I think the words you want are that RA "shares fate"= with =0A> routing, right?=0A> =0A> I don't think "shares fate" is the corr= ect wording for it - but =0A> maybe I =0A> misunderstand what you meant. Pl= ease expand.=0A> =0A> Meantime I tried to reword that section: =0A> https:/= /github.com/ayourtch/ra-dhcpv6/blob/0bfbfd0f3c69de9b0c208aa1b7933ab6cc71be3= 0/draft-yourtchenko-ra-dhcpv6-comparison-00.txt#L230=0A> =0A> Take a look a= nd see if this captures the things any better.=0A> =0A> It's a very tricky = section. There's an intertwine of "DHCPv6 was =0A> not =0A> allowed to do a= ny routing" + the implicit "I got an RA therefore that =0A> router exists" = (though "I got a DHCP offer from that router therefore =0A> that =0A> route= r exists" is also can be argued for) + the "multiple sources of =0A> truths= "...=A0 I feel it turns into a micro-version of the "RA vs. =0A> DHCP" =0A>= debate - maybe worth just folding it back into a pure factual "It was =0A>= decided that RA does routing, DHCPv6 does not, by the way RA does a slow = =0A> redundancy, which people do not like, therefore they think DHCPv6 shou= ld =0A> do routing".=0A>=A0=0A=0A(Disclaimer: Haven't had a chance to read = the text yet)=0A=0AI would generalise the description of RAs.=A0=0A=0AThey'= re not "Router Advertisments", they're Advertisements (typically) from Rout= ers, and they propagate per-subnet IPv6 parameters to hosts - per-link MTU,= per-link ND timers, per-link address configuration method, per-link on-lin= k prefix status, default router lifetime (if not announced as zero). The ca= n be used to propagate per-client per-link IPv6 parameters if necessary usi= ng unicasts.=0A=0A=0AI think DHCPv6 is really solving the application layer= configuration problem, which is independent of and not specific to the und= erlying links and network layer parameters. I think IPv6 per-link parameter= setting and application layer parameter setting are conceptually quite dif= ferent problems (I think the sets of layer parameters they provide values f= or is one of the give aways.)=0A=0A=0ARegards,=0AMark. From v6ops@globis.net Wed Oct 30 02:39:15 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1E21611E81A1 for ; Wed, 30 Oct 2013 02:39:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, 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 lIGFvTxjyNOb for ; Wed, 30 Oct 2013 02:39:14 -0700 (PDT) Received: from globis01.globis.net (RayH-1-pt.tunnel.tserv11.ams1.ipv6.he.net [IPv6:2001:470:1f14:62e::2]) by ietfa.amsl.com (Postfix) with ESMTP id EF25B11E8146 for ; Wed, 30 Oct 2013 02:38:45 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by globis01.globis.net (Postfix) with ESMTP id 11E27870F99; Wed, 30 Oct 2013 10:38:14 +0100 (CET) Received: from globis01.globis.net ([127.0.0.1]) by localhost (mail.globis.net [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id A5kYS3LXRJNr; Wed, 30 Oct 2013 10:38:13 +0100 (CET) Received: from Rays-iMac-2.local (unknown [192.168.0.3]) (Authenticated sender: Ray.Hunter@globis.net) by globis01.globis.net (Postfix) with ESMTPA id E053E8700B2; Wed, 30 Oct 2013 10:38:13 +0100 (CET) Message-ID: <5270D384.7030400@globis.net> Date: Wed, 30 Oct 2013 10:38:12 +0100 From: Ray Hunter User-Agent: Postbox 3.0.8 (Macintosh/20130427) MIME-Version: 1.0 To: Nick Hilliard References: <06601039-CAFD-49B0-918B-A8ACD51B978D@fugue.com> <1383036443.56704.YahooMailNeo@web142501.mail.bf1.yahoo.com> <1383074208.73179.YahooMailNeo@web142505.mail.bf1.yahoo.com> <52702DC2.1080507@inex.ie> In-Reply-To: <52702DC2.1080507@inex.ie> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: v6ops@ietf.org Subject: Re: [v6ops] DHCPv6/SLAAC Make Hosts Confusing-//RE: new draft: draft-liu-bonica-v6ops-dhcpv6-slaac-problem X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 30 Oct 2013 09:39:15 -0000 inline Nick Hilliard wrote: > On 29/10/2013 20:20, Andrew Yourtchenko wrote: >> debate - maybe worth just folding it back into a pure factual "It was >> decided that RA does routing, DHCPv6 does not, by the way RA does a slow >> redundancy, which people do not like, therefore they think DHCPv6 should do >> routing". > > WFM, and I very much like your draft so far, btw. > > Later on in the text, it says: > >> However, the "single source of truth" nature of DHCPv6 prevents the >> successful operation in case of multiple servers on the segment >> supplying different information. RAs in this case may still work. >> >> Some consider the inability to support this scenario crucial, and >> some think it is not useful. This creates contention between the >> proponents of those who want DHCPv6 deal with routing, and those who >> think RA is the single possible candidate for that. >> >> The other aspect is that because RA ties in the routing and >> addressing information, one can say "RA shares the fate with >> routing". However, this distinction is merely because of the >> decision to explicitly keep DHCPv6 away from routing - so can not be >> considered a true property of the protocol. > > The premise that many people in the IETF seem to be working on is that the > typical - or even a common - deployment case of ipv6 will involve multiple > routers per lan segment. I say this because every time the issue of DHCP > providing a defgw comes up, one of the main arguments that's trotted out is > that it will break the multiple-routers-per-lan-segment scenario. The > above 3 paragraphs also strongly hint at this as being the target deployment. > > Well maybe dhcpv6 doesn't do that, but the operational reality is that > multiple gateways on the same lan is going to be the rare exception rather > than the rule. The reason why I think this is because: > > 1. enterprises have an obtuse obsession for L2. They'd pave the world with > L2 and extend L2 from one end of the universe to the other if they could. > Just look at the horror of vxlan (who are they kidding? themselves?) as a > perfect example of this insanity. I don't know why this is but it's the > way that lots of enterprise rolls, ranging from SME to largish networks. > Outside truly large operations (i.e. 10s of thousands of users), I have > never got the impression that enterprises got L3 routing. I think you do Enterprise engineers a serious dis-service. Many consciously choose for L2 interfaces (with HSRP/ VRRP) isolation LANs between service providers precisely because L3 is more complex to debug and engineer across an administrative boundary. Even agreeing on an IGP can be tricky, never mind worrying about route flapping or redistribution loops. Experience has shown that HSRP/VRRP + static routes in a simple active/standby construction can deliver extremely robust SLA KPI's. Secondly, practical deployment of L3 routing protocols on end hosts was a no-go in IPv4. > 2. homenet: I don't understand the target audience for the entire homenet > multiple network movement. Putting this another way: who is going to debug > homenet multiple network stuff when it breaks, because as far as I can > tell, that belongs in the realm of level 2 engineering escalation (i.e. > $120/hr sort of thing). It's a little far-fetched to expect gramps and > grandma to set up and maintain and debug multiple networking segments. A > good chunk of the stuff going on in homenet is vastly more complicated than > pretty much any home network is ever going to need. Architecturally > interesting, but srsly not realistic as a viable approach to home networking. I think Homenet WG well-understands the challenges with deployment and little-conf.. > 3. service providers - the single operational group on the internet that > actually understands L3 / network segmentation and why it's important - > will attempt avoid multiple gateways per network like the plague because it > makes their deployment scenarios more complicated and provides no extra > value. For server / host farms, service providers like FHRP with tight > timers because it gives control of onward connectivity. > > All of which doesn't leave very many more user-market segments. I disagree entirely, and would characterise this as a rather network-operator-centric view, rather than a host-centric view. > Regarding RA for routing and DHCP for addressing, what people care about is > connectivity. What I need as an operator is a protocol (preferably a > single protocol because that is simpler) which will enable my boxes to gain > the connectivity they need. Whether you call this routing or providing a > default gateway, I don't much mind. > > Look, there's too much ideology going on here. The IETF is being dazzled > by the sight of multiple lan segments and multiple egress gateways without > realising that these are the minority configuration. All this effort is > going into optimising ipv6 address / lan autoconfiguration for these > unusual scenarios without heeding the sober reality that most people, > service providers and enterprises are only ever going to want to have a > single defgw per lan segment, and that by far the most common deployment > scenario will be a single lan segment per organisation. Erm. Have you missed the move to wireless? My smartphone already has two radios and a physical interface, connected to multiple providers. How exactly do you then configure a "single defgw per lan segment" (without draft-troan-homenet-sadr-01) > I'm aware that this viewpoint will be regarded as retrograde, and that a > bunch of people on this list will probably sit there, rolling their eyes > and thinking: "yeah, and 640k was enough for everyone". > > Just bear in mind that added complexity is not necessarily a good thing. > The support costs are high and the return on effort is dubious at best. > IOW, the IETF is optimising a corner case. This is not smart. > > Nick > > -- Regards, RayH From lorenzo@google.com Wed Oct 30 06:08:41 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B504611E822F for ; Wed, 30 Oct 2013 06:08:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.889 X-Spam-Level: X-Spam-Status: No, score=-1.889 tagged_above=-999 required=5 tests=[AWL=0.088, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, 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 gnmNVYRNg5Xj for ; Wed, 30 Oct 2013 06:08:40 -0700 (PDT) Received: from mail-ie0-x22e.google.com (mail-ie0-x22e.google.com [IPv6:2607:f8b0:4001:c03::22e]) by ietfa.amsl.com (Postfix) with ESMTP id C297011E8232 for ; Wed, 30 Oct 2013 06:08:19 -0700 (PDT) Received: by mail-ie0-f174.google.com with SMTP id qd12so2192656ieb.5 for ; Wed, 30 Oct 2013 06:08:14 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=8PwT8Ulkrz/zu61av1fAc4ANXKps1MnJB/722QnmcQw=; b=H4Gy60quzr83wD5dzGo6zhTX4oYA08ScqvixRzoyk0oau12zH0tbeCerAgaQd0hKqJ KfpjlLwIvfzDz41fw0RquSK8QTbbmA/iwczw7QIU8BGnZ+Pj9gcqaIduUMIjfvwfOuDJ SYHolQoNvbZtI69z9mHmu57TsptP4O5HjFZrspvwHkA9lODMIFs0gy2vep4it06cAG1H Hb2J15jnVGGjPN+y8kEqk1rlkfi2jbqk3hozrRU2IcMIKyDjHJM7QgqgfXDlD0bx0vTp FfUclh6zcLS4ahGSOgKJI/+9/If6W4jkkrPfK99amwCTWxN519ulMX7hn3+sgtCjySw7 l9kw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type; bh=8PwT8Ulkrz/zu61av1fAc4ANXKps1MnJB/722QnmcQw=; b=AksRNTIvWXTFAglNOnltIGE5knjBF34o/g69uPcD3eRdypN88qEt59l20/mBKfxL8l XQS/UjDiQGolub8wXtHw5ImJJdeEAKZvuh2ri5o88G5LrTie9vEzNC9eN4MaIjNHfP/0 Nb19BqvbToeCtukPIPofX4i5tsmVT/dmCHkdYn3JQUX5qKJMAElGMkSSqkFBmpJBJGo3 hNjVMju3HXwpcAjfkVd0iKEwO/aZOHScCPlDVNyDLH6JtUrZs9U21IKOq6G0BIedOsNM ef6dSMYiRbRjnSJn1wGoVHKPA95p/q5tcQUN6XU8HZGzIOzVRHEZvtAs6iF1wjaP/2fB x0nw== X-Gm-Message-State: ALoCoQlE1l5MfH7v2hbWQiOgtRQYY3j0u0PEA/peTqoV9BJKPZtj7HydzR0zGpXoeCQ+OUxZGd4tSZ+lx2LBt83BR2fFxZmYM1ITNEJpSw9Y7TH2gvI089TpKJqCOrzIKfiqRYPukKmqEIGkK07ozM6PUZ9A9sOMzlhrsnSe3loXHrM1og6Rxd+w0SDp/Wr6Cet1SzJAkD0o X-Received: by 10.43.138.8 with SMTP id iq8mr3137873icc.37.1383138493758; Wed, 30 Oct 2013 06:08:13 -0700 (PDT) MIME-Version: 1.0 Received: by 10.64.86.106 with HTTP; Wed, 30 Oct 2013 06:07:52 -0700 (PDT) In-Reply-To: <52702DC2.1080507@inex.ie> References: <06601039-CAFD-49B0-918B-A8ACD51B978D@fugue.com> <1383036443.56704.YahooMailNeo@web142501.mail.bf1.yahoo.com> <1383074208.73179.YahooMailNeo@web142505.mail.bf1.yahoo.com> <52702DC2.1080507@inex.ie> From: Lorenzo Colitti Date: Wed, 30 Oct 2013 22:07:52 +0900 Message-ID: To: Nick Hilliard Content-Type: multipart/alternative; boundary=001a11c2036498b4c404e9f506af Cc: "v6ops@ietf.org WG" Subject: Re: [v6ops] DHCPv6/SLAAC Make Hosts Confusing-//RE: new draft: draft-liu-bonica-v6ops-dhcpv6-slaac-problem X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 30 Oct 2013 13:08:41 -0000 --001a11c2036498b4c404e9f506af Content-Type: text/plain; charset=ISO-8859-1 On Wed, Oct 30, 2013 at 6:50 AM, Nick Hilliard wrote: > The premise that many people in the IETF seem to be working on is that the typical > - or even a common - deployment case of ipv6 will involve multiple routers > per lan segment. I say this because every time the issue of DHCP providing > a defgw comes up, one of the main arguments that's trotted out is that it > will break the multiple-routers-per-lan-segment scenario. The above 3 > paragraphs also strongly hint at this as being the target deployment. > Find me an medium or large enterprise deployment that doesn't have two routers on every LAN segment. I'll bet almost all of them do, because they know that if one crashes or they want to take it down for maintenance, they have an outage, and nobody likes outages. Now, the way - the *only* way - you do this in IPv4 is to run some failover protocol like VRRP between the routers. In IPv6 you can do that, but you don't have to, because all the RA protocol was designed to support multiple sources of information and multiple routers. There are situations in which that capability is useful, and I don't think we should take it away. --001a11c2036498b4c404e9f506af Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
On Wed, Oct 30, 2013 at 6:50 AM, Nick Hilliard <nick@inex.ie= > wrote:
The premise that many= people in the IETF seem to be working on is that the=A0typical - or even a common - deployment case of ip= v6 will involve multiple=A0route= rs per lan segment. =A0I say this because every time the issue of DHCP=A0providing a defgw comes up, one of= the main arguments that's trotted out is=A0that it will break the multiple-routers-per-lan-segment scenario. =A0The=A0above 3 paragraphs also strongly hint at this as= being the target deployment.

Find me an medium or large enterprise depl= oyment that doesn't have two routers on every LAN segment. I'll bet= almost all of them do, because they know that if one crashes or they want = to take it down for maintenance, they have an outage, and nobody likes outa= ges.

Now, the way - the *only* way - you do this in IPv4 is = to run some failover protocol like VRRP between the routers. In IPv6 you ca= n do that, but you don't have to, because all the RA protocol was desig= ned to support multiple sources of information and multiple routers.

There are situations in which that capability is useful= , and I don't think we should take it away.
--001a11c2036498b4c404e9f506af-- From jason.weil@twcable.com Wed Oct 30 07:28:31 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1DBB011E8252 for ; Wed, 30 Oct 2013 07:28:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.363 X-Spam-Level: X-Spam-Status: No, score=-0.363 tagged_above=-999 required=5 tests=[AWL=0.100, BAYES_00=-2.599, HELO_EQ_MODEMCABLE=0.768, HOST_EQ_MODEMCABLE=1.368] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id j6iPh7Meo7yv for ; Wed, 30 Oct 2013 07:28:27 -0700 (PDT) Received: from cdcipgw02.twcable.com (cdcipgw02.twcable.com [165.237.91.111]) by ietfa.amsl.com (Postfix) with ESMTP id B994D21F9FE9 for ; Wed, 30 Oct 2013 07:27:58 -0700 (PDT) X-SENDER-IP: 10.136.163.10 X-SENDER-REPUTATION: None X-IronPort-AV: E=Sophos;i="4.93,601,1378872000"; d="scan'208";a="46080522" Received: from unknown (HELO PRVPEXHUB01.corp.twcable.com) ([10.136.163.10]) by cdcipgw02.twcable.com with ESMTP/TLS/RC4-MD5; 30 Oct 2013 10:27:38 -0400 Received: from PRVPEXVS17.corp.twcable.com ([10.136.163.95]) by PRVPEXHUB01.corp.twcable.com ([10.136.163.10]) with mapi; Wed, 30 Oct 2013 10:27:57 -0400 From: "Weil, Jason" To: Nick Hilliard , "v6ops@ietf.org" Date: Wed, 30 Oct 2013 10:27:56 -0400 Thread-Topic: [v6ops] DHCPv6/SLAAC Make Hosts Confusing-//RE: new draft: draft-liu-bonica-v6ops-dhcpv6-slaac-problem Thread-Index: Ac7VfDp60V5ctKc8RFOMPNQPMzzaSg== Message-ID: In-Reply-To: <52702DC2.1080507@inex.ie> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.3.6.130613 acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [v6ops] DHCPv6/SLAAC Make Hosts Confusing-//RE: new draft: draft-liu-bonica-v6ops-dhcpv6-slaac-problem X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 30 Oct 2013 14:28:31 -0000 Silly Nick! Operational reality never factored into this equation. It is a thought project. Jason On 10/29/13 5:50 PM, "Nick Hilliard" wrote: >On 29/10/2013 20:20, Andrew Yourtchenko wrote: >> debate - maybe worth just folding it back into a pure factual "It was >> decided that RA does routing, DHCPv6 does not, by the way RA does a slow >> redundancy, which people do not like, therefore they think DHCPv6 >>should do >> routing". > >WFM, and I very much like your draft so far, btw. > >Later on in the text, it says: > >> However, the "single source of truth" nature of DHCPv6 prevents the >> successful operation in case of multiple servers on the segment >> supplying different information. RAs in this case may still work. >> >> Some consider the inability to support this scenario crucial, and >> some think it is not useful. This creates contention between the >> proponents of those who want DHCPv6 deal with routing, and those who >> think RA is the single possible candidate for that. >> >> The other aspect is that because RA ties in the routing and >> addressing information, one can say "RA shares the fate with >> routing". However, this distinction is merely because of the >> decision to explicitly keep DHCPv6 away from routing - so can not be >> considered a true property of the protocol. > >The premise that many people in the IETF seem to be working on is that the >typical - or even a common - deployment case of ipv6 will involve multiple >routers per lan segment. I say this because every time the issue of DHCP >providing a defgw comes up, one of the main arguments that's trotted out >is >that it will break the multiple-routers-per-lan-segment scenario. The >above 3 paragraphs also strongly hint at this as being the target >deployment. > >Well maybe dhcpv6 doesn't do that, but the operational reality is that >multiple gateways on the same lan is going to be the rare exception rather >than the rule. The reason why I think this is because: > >1. enterprises have an obtuse obsession for L2. They'd pave the world >with >L2 and extend L2 from one end of the universe to the other if they could. >Just look at the horror of vxlan (who are they kidding? themselves?) as a >perfect example of this insanity. I don't know why this is but it's the >way that lots of enterprise rolls, ranging from SME to largish networks. >Outside truly large operations (i.e. 10s of thousands of users), I have >never got the impression that enterprises got L3 routing. > >2. homenet: I don't understand the target audience for the entire homenet >multiple network movement. Putting this another way: who is going to debug >homenet multiple network stuff when it breaks, because as far as I can >tell, that belongs in the realm of level 2 engineering escalation (i.e. >$120/hr sort of thing). It's a little far-fetched to expect gramps and >grandma to set up and maintain and debug multiple networking segments. A >good chunk of the stuff going on in homenet is vastly more complicated >than >pretty much any home network is ever going to need. Architecturally >interesting, but srsly not realistic as a viable approach to home >networking. > >3. service providers - the single operational group on the internet that >actually understands L3 / network segmentation and why it's important - >will attempt avoid multiple gateways per network like the plague because >it >makes their deployment scenarios more complicated and provides no extra >value. For server / host farms, service providers like FHRP with tight >timers because it gives control of onward connectivity. > >All of which doesn't leave very many more user-market segments. > >Regarding RA for routing and DHCP for addressing, what people care about >is >connectivity. What I need as an operator is a protocol (preferably a >single protocol because that is simpler) which will enable my boxes to >gain >the connectivity they need. Whether you call this routing or providing a >default gateway, I don't much mind. > >Look, there's too much ideology going on here. The IETF is being dazzled >by the sight of multiple lan segments and multiple egress gateways without >realising that these are the minority configuration. All this effort is >going into optimising ipv6 address / lan autoconfiguration for these >unusual scenarios without heeding the sober reality that most people, >service providers and enterprises are only ever going to want to have a >single defgw per lan segment, and that by far the most common deployment >scenario will be a single lan segment per organisation. > >I'm aware that this viewpoint will be regarded as retrograde, and that a >bunch of people on this list will probably sit there, rolling their eyes >and thinking: "yeah, and 640k was enough for everyone". > >Just bear in mind that added complexity is not necessarily a good thing. >The support costs are high and the return on effort is dubious at best. >IOW, the IETF is optimising a corner case. This is not smart. > >Nick > >_______________________________________________ >v6ops mailing list >v6ops@ietf.org >https://www.ietf.org/mailman/listinfo/v6ops This E-mail and any of its attachments may contain Time Warner Cable propri= etary information, which is privileged, confidential, or subject to copyrig= ht belonging to Time Warner Cable. This E-mail is intended solely for the u= se of the individual or entity to which it is addressed. If you are not the= intended recipient of this E-mail, you are hereby notified that any dissem= ination, distribution, copying, or action taken in relation to the contents= of and attachments to this E-mail is strictly prohibited and may be unlawf= ul. If you have received this E-mail in error, please notify the sender imm= ediately and permanently delete the original and any copy of this E-mail an= d any printout. From nick@inex.ie Wed Oct 30 11:15:12 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B3F7511E82C4 for ; Wed, 30 Oct 2013 11:15:12 -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 VvUjcKBF2Hx7 for ; Wed, 30 Oct 2013 11:15:12 -0700 (PDT) Received: from mail.netability.ie (mail.netability.ie [IPv6:2a03:8900:0:100::5]) by ietfa.amsl.com (Postfix) with ESMTP id 5843921E80F1 for ; Wed, 30 Oct 2013 11:15:04 -0700 (PDT) X-Envelope-To: v6ops@ietf.org Received: from crumpet.dyn.netability.ie ([IPv6:2001:1bb8:2004:200::180]) (authenticated bits=0) by mail.netability.ie (8.14.7/8.14.5) with ESMTP id r9UIExhG033631 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO); Wed, 30 Oct 2013 18:14:59 GMT (envelope-from nick@inex.ie) X-Authentication-Warning: cheesecake.netability.ie: Host [IPv6:2001:1bb8:2004:200::180] claimed to be crumpet.dyn.netability.ie Message-ID: <52714CA2.2090409@inex.ie> Date: Wed, 30 Oct 2013 18:14:58 +0000 From: Nick Hilliard User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:24.0) Gecko/20100101 Thunderbird/24.0.1 MIME-Version: 1.0 To: Lorenzo Colitti References: <06601039-CAFD-49B0-918B-A8ACD51B978D@fugue.com> <1383036443.56704.YahooMailNeo@web142501.mail.bf1.yahoo.com> <1383074208.73179.YahooMailNeo@web142505.mail.bf1.yahoo.com> <52702DC2.1080507@inex.ie> In-Reply-To: X-Enigmail-Version: 1.6 X-Company-Info-1: Internet Neutral Exchange Association Limited. Registered in Ireland No. 253804 X-Company-Info-2: Registered Offices: 1-2, Marino Mart, Fairview, Dublin 3 X-Company-Info-3: Internet Neutral Exchange Association Limited is limited by guarantee X-Company-Info-4: Offices: 4027 Kingswood Road, Citywest, Dublin 24. Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: "v6ops@ietf.org WG" Subject: Re: [v6ops] DHCPv6/SLAAC Make Hosts Confusing-//RE: new draft: draft-liu-bonica-v6ops-dhcpv6-slaac-problem X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 30 Oct 2013 18:15:12 -0000 On 30/10/2013 13:07, Lorenzo Colitti wrote: > Find me an medium or large enterprise deployment that doesn't have two > routers on every LAN segment. I'll bet almost all of them do, because they > know that if one crashes or they want to take it down for maintenance, they > have an outage, and nobody likes outages. no need to bet - using multiple routers on a LAN is standard procedure where uptime matters. The question is why would someone use RA for multiple gateway announcement when you'll get much better operational performance from a FHRP + single gateway address? And why use RA for addressing when you'll get finer grained operational host control using dhcp? Or when you need to use dhcp anyway in order to make your hosts do what they need to do? Or on server farms when most of your hosts are statically addressed and it doesn't make sense to have multiple gateways with different addresses - and you'll get better uptime by not using RA? I'm not proposing to take away the option of using RAs if that's what you want to do. I'm only suggesting that for many situations, it makes more sense to have a single static gateway address (optionally with multiple routers using a FHRP if you need reliability) and that consequently the idea of periodically announcing a selection of arbitrary gateways via RA is operationally second rate. Nick From markzzzsmith@yahoo.com.au Wed Oct 30 12:40:45 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5369721E80AE for ; Wed, 30 Oct 2013 12:40:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.652 X-Spam-Level: X-Spam-Status: No, score=-1.652 tagged_above=-999 required=5 tests=[AWL=-0.153, BAYES_00=-2.599, FROM_LOCAL_NOVOWEL=0.5, J_CHICKENPOX_13=0.6] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IH8TbXhu+keQ for ; Wed, 30 Oct 2013 12:40:40 -0700 (PDT) Received: from nm24-vm0.bullet.mail.bf1.yahoo.com (nm24-vm0.bullet.mail.bf1.yahoo.com [98.139.213.161]) by ietfa.amsl.com (Postfix) with ESMTP id 8AB5221E814A for ; Wed, 30 Oct 2013 12:40:08 -0700 (PDT) Received: from [98.139.212.149] by nm24.bullet.mail.bf1.yahoo.com with NNFMP; 30 Oct 2013 19:39:51 -0000 Received: from [98.139.212.228] by tm6.bullet.mail.bf1.yahoo.com with NNFMP; 30 Oct 2013 19:39:51 -0000 Received: from [127.0.0.1] by omp1037.mail.bf1.yahoo.com with NNFMP; 30 Oct 2013 19:39:51 -0000 X-Yahoo-Newman-Property: ymail-3 X-Yahoo-Newman-Id: 14864.5189.bm@omp1037.mail.bf1.yahoo.com Received: (qmail 2989 invoked by uid 60001); 30 Oct 2013 19:39:50 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com.au; s=s1024; t=1383161990; bh=ih8Jd8sALNAx37jQBhid15gQF6NMuKpzj7kyIiPyMro=; h=X-YMail-OSG:Received:X-Rocket-MIMEInfo:X-Mailer:References:Message-ID:Date:From:Reply-To:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type:Content-Transfer-Encoding; b=5G6I1qGysjSBqBRU2no6DhkAuWoYhBU9y83BwWEQXTppf1Wv+yVMr5bMC0BSwkETleBWb2qvt7mhkB7BBa8q/jAoH/BDFoGJXU+NXbf5Z6GAMg/E5/YsjJijBO5UMLuDGQBflHP3MKQ5aByoiOQJKBYsCAx43jimsh3LDQlmBSQ= DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com.au; h=X-YMail-OSG:Received:X-Rocket-MIMEInfo:X-Mailer:References:Message-ID:Date:From:Reply-To:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type:Content-Transfer-Encoding; b=vTwGQF7gy4fHZzOqtPbQHsVDPwepfFDSk5Lhkjqpi2alWWgvNGHpQSXEVA3dHnSW1XsoICZlWtinhZQHnB2tGzeSF8Dto26ZI/9J9nfMTe52zgziZ9jwJQK2xd0FnqriiS4cab8OIxjSjWFiHSStjC5MV8IwtJzRfkqD/ep3uLQ=; X-YMail-OSG: 9pR7v8MVM1nnQ1iOD2zV7uHFCprn2hNsxxIacsWAi.mGGI8 uU6mZ3yjU7h8GNG6mIQebuCVZfAM0uKEqa9.70wvbmN0rA3grakfqJY6g9yz ADgAM3A9NYqteBMbng5FJWD0.P4UTsrYHlYpwylXgtO2ruBRTPwyxS1rp3Em WdVGkKNa2gvDV8pcyVD2qe6DZlmNDHxfkInj18RIYCGYyZixAI6bRWA5fgdz NYtULF6.1uivGB6DzLZBh2Pcgw9IZEqn1X9V81QCZE2PdoE5lfNupl9Dy6BO LOa.AGpQvnhfcy3ux7xTDq.x4broy06AfZsRIpt5kXc3NyubP8CNXe.8GwLw nDSrtv.Hkqy2jDUZaW9xB3fJjCGqBtlNCjEkoWPsHkfnMLXVA5EuYuhFe9hb Rf8A2qMMrBrHjbzTiBKgDgCt8SLPBxqdGbXAOQugQHx8M4jfWxnppavrKGY4 SlisuenipDLgq2cAl7IhzqvSCGL6NkHCme86tMNAQRZfIcNiL2tSPz5p2z1m 1QCN4SmGU4pU9hlt.p1_DN0Kz98jyO3IV2dTNSZE58jxDZ7CJr2XJmT53sa6 cPz66f_OOvbyDor816lZY_j0bNpzmJpYYAtiwrscdm16QPQ-- Received: from [150.101.221.237] by web142502.mail.bf1.yahoo.com via HTTP; Wed, 30 Oct 2013 12:39:50 PDT X-Rocket-MIMEInfo: 002.001, CgoKCi0tLS0tIE9yaWdpbmFsIE1lc3NhZ2UgLS0tLS0KPiBGcm9tOiBOaWNrIEhpbGxpYXJkIDxuaWNrQGluZXguaWU.Cj4gVG86IExvcmVuem8gQ29saXR0aSA8bG9yZW56b0Bnb29nbGUuY29tPgo.IENjOiAidjZvcHNAaWV0Zi5vcmcgV0ciIDx2Nm9wc0BpZXRmLm9yZz4KPiBTZW50OiBUaHVyc2RheSwgMzEgT2N0b2JlciAyMDEzIDU6MTQgQU0KPiBTdWJqZWN0OiBSZTogW3Y2b3BzXSBESENQdjYvU0xBQUMgTWFrZSBIb3N0cyBDb25mdXNpbmctLy9SRTogbmV3IGRyYWZ0OglkcmFmdC1saXUtYm9uaWNhLXYBMAEBAQE- X-Mailer: YahooMailWebService/0.8.160.587 References: <06601039-CAFD-49B0-918B-A8ACD51B978D@fugue.com> <1383036443.56704.YahooMailNeo@web142501.mail.bf1.yahoo.com> <1383074208.73179.YahooMailNeo@web142505.mail.bf1.yahoo.com> <52702DC2.1080507@inex.ie> <52714CA2.2090409@inex.ie> Message-ID: <1383161990.2899.YahooMailNeo@web142502.mail.bf1.yahoo.com> Date: Wed, 30 Oct 2013 12:39:50 -0700 (PDT) From: Mark ZZZ Smith To: Nick Hilliard , Lorenzo Colitti In-Reply-To: <52714CA2.2090409@inex.ie> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Cc: "v6ops@ietf.org WG" Subject: Re: [v6ops] DHCPv6/SLAAC Make Hosts Confusing-//RE: new draft: draft-liu-bonica-v6ops-dhcpv6-slaac-problem X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: Mark ZZZ Smith List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 30 Oct 2013 19:40:45 -0000 =0A=0A=0A=0A----- Original Message -----=0A> From: Nick Hilliard =0A> To: Lorenzo Colitti =0A> Cc: "v6ops@ietf.org W= G" =0A> Sent: Thursday, 31 October 2013 5:14 AM=0A> Subject= : Re: [v6ops] DHCPv6/SLAAC Make Hosts Confusing-//RE: new draft:=09draft-li= u-bonica-v6ops-dhcpv6-slaac-problem=0A> =0A> On 30/10/2013 13:07, Lorenzo C= olitti wrote:=0A>> Find me an medium or large enterprise deployment that d= oesn't have two=0A>> routers on every LAN segment. I'll bet almost all of = them do, because =0A> they=0A>> know that if one crashes or they want to t= ake it down for maintenance, they=0A>> have an outage, and nobody likes ou= tages.=0A> =0A> no need to bet - using multiple routers on a LAN is standar= d procedure=0A> where uptime matters.=0A> =0A> The question is why would so= meone use RA for multiple gateway announcement=0A> when you'll get much bet= ter operational performance from a FHRP + single=0A> gateway address?=A0 An= d why use RA for addressing when you'll get finer=0A> grained operational h= ost control using dhcp?=0A=0AIt's been said a number of times in this threa= d. You can have client specific RAs that solve that problem. This is not a = missing capability that duplicating RA functionality in DHCPv6 would then p= rovide.=0A=0A=0A> Or when you need to use dhcp=0A> anyway in order to make = your hosts do what they need to do?=A0 Or on server=0A> farms when most of = your hosts are statically addressed and it doesn't make=0A> sense to have m= ultiple gateways with different addresses - and you'll get=0A> better uptim= e by not using RA?=0A> =0A> I'm not proposing to take away the option of us= ing RAs if that's what =0A> you=0A> want to do.=A0 I'm only suggesting that= for many situations, it makes more=0A> sense to have a single static gatew= ay address (optionally with multiple=0A> routers using a FHRP if you need r= eliability) and that consequently the=0A> idea of periodically announcing a= selection of arbitrary gateways via RA is=0A> operationally second rate.= =0A>=A0=0A=0AI'd really like to know specific details of these many situati= ons, and what specific benefits switching off RAs would have. I've been in = many situations in many networks, and when I consider my IPv4 experience (a= nd also compare it to my Novell IPX and Appletalk experiences), I see a lot= of value in having RAs provide default gateway(s) (VRRP/HSRP or not) infor= mation and other layer 3 parameters to directly attached hosts from the dir= ectly attached router(s). This is in comparison with the IPv4 alternative= =A0effort of enabling and configuring a heavier and more resource consuming= stateful DHCP server on either the first hop routers, or enabling DHCP rel= ays and then having to have a redundant DHCP infrastructure somewhere else = in the network.=0A=0AIt could be argued that DHCP could be enabled and conf= igured by default, but that is also obviously the case with RAs, and they'v= e been enabled by default since day one. The ability to automate the config= uration of DHCP doesn't inherently make DHCP better than RAs.=0A=0ARegards,= =0AMark.=0A=0A>=A0=0A=0A> Nick=0A> ________________________________________= _______=0A> v6ops mailing list=0A> v6ops@ietf.org=0A> https://www.ietf.org/= mailman/listinfo/v6ops=0A> From markzzzsmith@yahoo.com.au Wed Oct 30 13:07:30 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A76CE11E8220 for ; Wed, 30 Oct 2013 13:07:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.943 X-Spam-Level: X-Spam-Status: No, score=-1.943 tagged_above=-999 required=5 tests=[AWL=0.156, BAYES_00=-2.599, FROM_LOCAL_NOVOWEL=0.5] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lYqv0-5VAlwE for ; Wed, 30 Oct 2013 13:06:57 -0700 (PDT) Received: from nm3-vm0.bullet.mail.bf1.yahoo.com (nm3-vm0.bullet.mail.bf1.yahoo.com [98.139.212.154]) by ietfa.amsl.com (Postfix) with ESMTP id 669F011E818E for ; Wed, 30 Oct 2013 13:06:09 -0700 (PDT) Received: from [98.139.215.142] by nm3.bullet.mail.bf1.yahoo.com with NNFMP; 30 Oct 2013 20:06:05 -0000 Received: from [98.139.212.233] by tm13.bullet.mail.bf1.yahoo.com with NNFMP; 30 Oct 2013 20:06:05 -0000 Received: from [127.0.0.1] by omp1042.mail.bf1.yahoo.com with NNFMP; 30 Oct 2013 20:06:05 -0000 X-Yahoo-Newman-Property: ymail-3 X-Yahoo-Newman-Id: 141564.87325.bm@omp1042.mail.bf1.yahoo.com Received: (qmail 25669 invoked by uid 60001); 30 Oct 2013 20:06:04 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com.au; s=s1024; t=1383163564; bh=ENbe0QcgMSwVtEaM5r3BPuAly3G3Q5QasLIpgatVP24=; h=X-YMail-OSG:Received:X-Rocket-MIMEInfo:X-Mailer:References:Message-ID:Date:From:Reply-To:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type:Content-Transfer-Encoding; b=fcj7YNbA3IOYpcwU0u4a3GVd0OxnbNS/ZOXgz1yK/jaxfFPZURcTiiBRB7aJBKDOxjOTY/SlJcMA1ReGdtm+fZLFHsddH9U41lESAJn2//VoQb7Cqc8U1AlAXa6+b4T17pvlK0d/xo5H0t6B2ECEbljmYDLRSpPZDIK7zesjzso= DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com.au; h=X-YMail-OSG:Received:X-Rocket-MIMEInfo:X-Mailer:References:Message-ID:Date:From:Reply-To:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type:Content-Transfer-Encoding; b=v+/dK/GT1tGG/wukn7GThvOqNmGeTVWFuStVYPjdocuAMgA9bQbhcvRfW4xPblgL+XGnRH6yaT1a/mBpE10D0RQt5uCP2+qSNIMOdo8oyuHTyRxexLyfOCodWalP2XvR8tLdWxvh7eiH/Ptzsjht51f67H3YTqeVNvHi51a4008=; X-YMail-OSG: QyB3LJQVM1n5UDhAAFXckjYp.EBN.MLB84ynDmPo.ESS4T9 34N5dAyMLaY6vDDsAzdV23tS875N76qY7FJfAZcf.U3SiXSLIQLTPSUVnIMq dULTA.Jmvr31IJsCsWnfUNbo3afmZ8MVzIhqnYAhxLWPcsaQPjhpE6sjIB.S JmBkcXIZC6EqpManFfUsMaOCmDBTPwQJqjUzZN5OMat03xJLYeDWDfu1vQ5G QFFgD_s2CT1o92k4.hoVZqJ06zsgOkF_aBRFTseY2lsQXdxlfG9qASifrAXG K7HvQy4CTn9G0hfo1EDRzDVyVHY1UP2AGXLW631hLfburOH82317Eu._H65Q iehky8._sWMmXA91y80yFwralTeAKP26KidnEvE18iKmizIbloTnz5fcwCV8 _JwI3dPOFwrrd8VLUa1kk5iLnepvAnKCafsDsjTqnZUUWiHFxb9XI3.VQvXS J_PSvpYshYlFq8r9EnPUq2AWbT2YYxC4Glva4vaAxq2DQHqg3ViprgMSdVWT mVPKfr83QcJ_a8BZjnHYtAmiwh3Wz0ok44QjPi4gXpMX_bqyviPyNuD4aS0g cuWIwnu257paXfmEmiweRKBhiteH4zaWvQdma7yEhCouu Received: from [150.101.221.237] by web142505.mail.bf1.yahoo.com via HTTP; Wed, 30 Oct 2013 13:06:04 PDT X-Rocket-MIMEInfo: 002.001, CgoKCi0tLS0tIE9yaWdpbmFsIE1lc3NhZ2UgLS0tLS0KPiBGcm9tOiBUZWQgTGVtb24gPG1lbGxvbkBmdWd1ZS5jb20.Cj4gVG86IE1hcmsgWlpaIFNtaXRoIDxtYXJrenp6c21pdGhAeWFob28uY29tLmF1Pgo.IENjOiBBbmRyZXcgWW91cnRjaGVua28gPGF5b3VydGNoQGNpc2NvLmNvbT47IExvcmVuem8gQ29saXR0aSA8bG9yZW56b0Bnb29nbGUuY29tPjsgImRyYWZ0LWxpdS1ib25pY2EtdjZvcHMtZGhjcHY2LXNsYWFjLXByb2JsZW1AdG9vbHMuaWV0Zi5vcmciIDxkcmFmdC1saXUtYm9uaWNhLXY2b3BzLWQBMAEBAQE- X-Mailer: YahooMailWebService/0.8.160.587 References: <06601039-CAFD-49B0-918B-A8ACD51B978D@fugue.com> <1383036443.56704.YahooMailNeo@web142501.mail.bf1.yahoo.com> <1383074208.73179.YahooMailNeo@web142505.mail.bf1.yahoo.com> <1383121368.56079.YahooMailNeo@web142505.mail.bf1.yahoo.com> <9631E070-0CC7-4D19-9FC7-3E8091A5395A@fugue.com> Message-ID: <1383163564.25414.YahooMailNeo@web142505.mail.bf1.yahoo.com> Date: Wed, 30 Oct 2013 13:06:04 -0700 (PDT) From: Mark ZZZ Smith To: Ted Lemon In-Reply-To: <9631E070-0CC7-4D19-9FC7-3E8091A5395A@fugue.com> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Cc: "v6ops@ietf.org" , "Ole Troan \(otroan\)" , Dave Thaler , "draft-liu-bonica-v6ops-dhcpv6-slaac-problem@tools.ietf.org" Subject: Re: [v6ops] DHCPv6/SLAAC Make Hosts Confusing-//RE: new draft: draft-liu-bonica-v6ops-dhcpv6-slaac-problem X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: Mark ZZZ Smith List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 30 Oct 2013 20:07:31 -0000 =0A=0A=0A=0A----- Original Message -----=0A> From: Ted Lemon =0A> To: Mark ZZZ Smith =0A> Cc: Andrew Your= tchenko ; Lorenzo Colitti ; "draft-= liu-bonica-v6ops-dhcpv6-slaac-problem@tools.ietf.org" ; "v6ops@ietf.org" ;= Ole Troan (otroan) ; Dave Thaler = =0A> Sent: Wednesday, 30 October 2013 11:07 PM=0A> Subject: Re: [v6ops] DHC= Pv6/SLAAC Make Hosts Confusing-//RE: new draft: draft-liu-bonica-v6ops-dhcp= v6-slaac-problem=0A> =0A> On Oct 30, 2013, at 4:22 AM, Mark ZZZ Smith =0A> wrote:=0A> =0A>> I think DHCPv6 is really solv= ing the application layer configuration =0A> problem, which is independent = of and not specific to the underlying links and =0A> network layer paramete= rs.=0A> =0A> Actually DHCPv6 is a poor solution to that problem, because ap= plication =0A> configuration is not typically network-specific.=A0 This has= been discussed at =0A> some length recently on the IETF mailing list.=0A> = =0A=0AI'll have to look that up. Thanks for letting me know.=0A=0AI have re= cently been thinking a bit more about that in the context of the DHCPv6 opt= ion transparency draft I posted, and have started to wonder if LDAP or SLP = style directories would be better, with a special well known directory bran= ch to represent network or subnet local application parameters.=0A=0AThanks= ,=0AMark. From volz@cisco.com Wed Oct 30 14:39:27 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 27F0121F9A37 for ; Wed, 30 Oct 2013 14:39:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.299 X-Spam-Level: X-Spam-Status: No, score=-10.299 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, J_CHICKENPOX_13=0.6, 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 v98jAFyHu4cu for ; Wed, 30 Oct 2013 14:39:22 -0700 (PDT) Received: from rcdn-iport-6.cisco.com (rcdn-iport-6.cisco.com [173.37.86.77]) by ietfa.amsl.com (Postfix) with ESMTP id 8D12C21F9D70 for ; Wed, 30 Oct 2013 14:39:18 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2921; q=dns/txt; s=iport; t=1383169158; x=1384378758; h=from:to:cc:subject:date:message-id: content-transfer-encoding:mime-version; bh=n8bLYCHefZc9nDu5Vl6RD9rpSUW4DxET/zONrIYmy20=; b=YiGcu+aVQkPCzhDWSg97VZzzLNnN7Xu5F45sJ2BJoiTJPWRKfd30XXmh LWqRrI/ZDy2tNqnelKPKMirEmZ6EgCJTfH2qvpv6UfM4AqUZloQNVyoR9 5puuwFYtGLhGFbpcR84Druln8qRV/fw8BNuN0MSBFjzi5BwC9+LAQx8GY w=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgkFAAN8cVKtJXG+/2dsb2JhbABZgwc4VL9hgSoWdIIlAQEBBAEBAWsLDAYBCBEEAQEBChkELgsUCQkBBAENBQgTh1oDDw26dASMX4EngRgxDYMZgQ0DiQeNHo43hTeBaIE+gXE5 X-IronPort-AV: E=Sophos;i="4.93,604,1378857600"; d="scan'208";a="278706102" Received: from rcdn-core2-3.cisco.com ([173.37.113.190]) by rcdn-iport-6.cisco.com with ESMTP; 30 Oct 2013 21:39:18 +0000 Received: from xhc-aln-x07.cisco.com (xhc-aln-x07.cisco.com [173.36.12.81]) by rcdn-core2-3.cisco.com (8.14.5/8.14.5) with ESMTP id r9ULdITp010624 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 30 Oct 2013 21:39:18 GMT Received: from xmb-rcd-x04.cisco.com ([169.254.8.27]) by xhc-aln-x07.cisco.com ([173.36.12.81]) with mapi id 14.02.0318.004; Wed, 30 Oct 2013 16:39:17 -0500 From: "Bernie Volz (volz)" To: Mark ZZZ Smith , Ted Lemon Thread-Topic: [v6ops] DHCPv6/SLAAC Make Hosts Confusing-//RE: new draft: draft-liu-bonica-v6ops-dhcpv6-slaac-problem Thread-Index: Ac7VuHt2/xyVyKkzQgijPiRUOo/hzg== Date: Wed, 30 Oct 2013 21:39:16 +0000 Message-ID: <489D13FBFA9B3E41812EA89F188F018E1AD4CBA4@xmb-rcd-x04.cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [161.44.65.145] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "draft-liu-bonica-v6ops-dhcpv6-slaac-problem@tools.ietf.org" , "v6ops@ietf.org" , "Ole Troan \(otroan\)" , Dave Thaler Subject: Re: [v6ops] DHCPv6/SLAAC Make Hosts Confusing-//RE: new draft: draft-liu-bonica-v6ops-dhcpv6-slaac-problem X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 30 Oct 2013 21:39:27 -0000 I think we have to be a bit careful about "application". We certainly don't= want DHCP to configure user based application information. But network con= figuration related to applications may be valid (although if there are othe= r discovery techniques available, they may well be preferred). DHCP SHOULD configure the network resources available for the client device= to use (i.e., things needed to provide tnetwork connectivity and access to= that network's services). It should not configure user specific services (= i.e., there was some discussion about email (SMTP, POP, IMAP server) inform= ation as an example of something that would not be DHCP configured). This is a bit tricky to clarify. And, I am certain someone will have issues= with my attempt; hopefully they can do better. - Bernie -----Original Message----- From: v6ops-bounces@ietf.org [mailto:v6ops-bounces@ietf.org] On Behalf Of M= ark ZZZ Smith Sent: Wednesday, October 30, 2013 4:06 PM To: Ted Lemon Cc: v6ops@ietf.org; Ole Troan (otroan); Dave Thaler; draft-liu-bonica-v6ops= -dhcpv6-slaac-problem@tools.ietf.org Subject: Re: [v6ops] DHCPv6/SLAAC Make Hosts Confusing-//RE: new draft: dra= ft-liu-bonica-v6ops-dhcpv6-slaac-problem ----- Original Message ----- > From: Ted Lemon > To: Mark ZZZ Smith > Cc: Andrew Yourtchenko ; Lorenzo Colitti=20 > ;=20 > "draft-liu-bonica-v6ops-dhcpv6-slaac-problem@tools.ietf.org"=20 > ;=20 > "v6ops@ietf.org" ; Ole Troan (otroan)=20 > ; Dave Thaler > Sent: Wednesday, 30 October 2013 11:07 PM > Subject: Re: [v6ops] DHCPv6/SLAAC Make Hosts Confusing-//RE: new=20 > draft: draft-liu-bonica-v6ops-dhcpv6-slaac-problem >=20 > On Oct 30, 2013, at 4:22 AM, Mark ZZZ Smith=20 > > wrote: >=20 >> I think DHCPv6 is really solving the application layer configuration > problem, which is independent of and not specific to the underlying=20 > links and network layer parameters. >=20 > Actually DHCPv6 is a poor solution to that problem, because=20 > application configuration is not typically network-specific.=A0 This has= =20 > been discussed at some length recently on the IETF mailing list. >=20 I'll have to look that up. Thanks for letting me know. I have recently been thinking a bit more about that in the context of the D= HCPv6 option transparency draft I posted, and have started to wonder if LDA= P or SLP style directories would be better, with a special well known direc= tory branch to represent network or subnet local application parameters. Thanks, Mark. _______________________________________________ v6ops mailing list v6ops@ietf.org https://www.ietf.org/mailman/listinfo/v6ops From nick@inex.ie Wed Oct 30 14:56:56 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 49E8A11E81E9 for ; Wed, 30 Oct 2013 14:56:56 -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 a-9BfHwzZ40P for ; Wed, 30 Oct 2013 14:56:53 -0700 (PDT) Received: from mail.netability.ie (mail.netability.ie [IPv6:2a03:8900:0:100::5]) by ietfa.amsl.com (Postfix) with ESMTP id 9D46E11E81E6 for ; Wed, 30 Oct 2013 14:56:46 -0700 (PDT) X-Envelope-To: v6ops@ietf.org Received: from cupcake.foobar.org ([IPv6:2001:4d68:2002:100::110]) (authenticated bits=0) by mail.netability.ie (8.14.7/8.14.5) with ESMTP id r9ULuf0K035239 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO); Wed, 30 Oct 2013 21:56:41 GMT (envelope-from nick@inex.ie) X-Authentication-Warning: cheesecake.netability.ie: Host [IPv6:2001:4d68:2002:100::110] claimed to be cupcake.foobar.org Message-ID: <52718098.3050302@inex.ie> Date: Wed, 30 Oct 2013 21:56:40 +0000 From: Nick Hilliard User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:17.0) Gecko/20130801 Thunderbird/17.0.8 MIME-Version: 1.0 To: Mark ZZZ Smith References: <06601039-CAFD-49B0-918B-A8ACD51B978D@fugue.com> <1383036443.56704.YahooMailNeo@web142501.mail.bf1.yahoo.com> <1383074208.73179.YahooMailNeo@web142505.mail.bf1.yahoo.com> <1383121368.56079.YahooMailNeo@web142505.mail.bf1.yahoo.com> <9631E070-0CC7-4D19-9FC7-3E8091A5395A@fugue.com> <1383163564.25414.YahooMailNeo@web142505.mail.bf1.yahoo.com> In-Reply-To: <1383163564.25414.YahooMailNeo@web142505.mail.bf1.yahoo.com> X-Enigmail-Version: 1.6 X-Company-Info-1: Internet Neutral Exchange Association Limited. Registered in Ireland No. 253804 X-Company-Info-2: Registered Offices: 1-2, Marino Mart, Fairview, Dublin 3 X-Company-Info-3: Internet Neutral Exchange Association Limited is limited by guarantee X-Company-Info-4: Offices: 4027 Kingswood Road, Citywest, Dublin 24. Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: "v6ops@ietf.org" Subject: Re: [v6ops] DHCPv6/SLAAC Make Hosts Confusing-//RE: new draft: draft-liu-bonica-v6ops-dhcpv6-slaac-problem X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 30 Oct 2013 21:56:56 -0000 On 30/10/2013 20:06, Mark ZZZ Smith wrote: > I have recently been thinking a bit more about that in the context of > the DHCPv6 option transparency draft I posted, and have started to > wonder if LDAP or SLP style directories would be better, with a special > well known directory branch to represent network or subnet local > application parameters. rfc2244? Nick From nick@inex.ie Wed Oct 30 15:14:58 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0014B21F9FAC for ; Wed, 30 Oct 2013 15:14:57 -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 R60VYcToHeSv for ; Wed, 30 Oct 2013 15:14:57 -0700 (PDT) Received: from mail.netability.ie (mail.netability.ie [IPv6:2a03:8900:0:100::5]) by ietfa.amsl.com (Postfix) with ESMTP id BC03321E809D for ; Wed, 30 Oct 2013 15:14:56 -0700 (PDT) X-Envelope-To: v6ops@ietf.org Received: from cupcake.foobar.org ([IPv6:2001:4d68:2002:100::110]) (authenticated bits=0) by mail.netability.ie (8.14.7/8.14.5) with ESMTP id r9UMEncN035321 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO); Wed, 30 Oct 2013 22:14:50 GMT (envelope-from nick@inex.ie) X-Authentication-Warning: cheesecake.netability.ie: Host [IPv6:2001:4d68:2002:100::110] claimed to be cupcake.foobar.org Message-ID: <527184D9.8070409@inex.ie> Date: Wed, 30 Oct 2013 22:14:49 +0000 From: Nick Hilliard User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:17.0) Gecko/20130801 Thunderbird/17.0.8 MIME-Version: 1.0 To: Mark ZZZ Smith References: <06601039-CAFD-49B0-918B-A8ACD51B978D@fugue.com> <1383036443.56704.YahooMailNeo@web142501.mail.bf1.yahoo.com> <1383074208.73179.YahooMailNeo@web142505.mail.bf1.yahoo.com> <52702DC2.1080507@inex.ie> <52714CA2.2090409@inex.ie> <1383161990.2899.YahooMailNeo@web142502.mail.bf1.yahoo.com> In-Reply-To: <1383161990.2899.YahooMailNeo@web142502.mail.bf1.yahoo.com> X-Enigmail-Version: 1.6 X-Company-Info-1: Internet Neutral Exchange Association Limited. Registered in Ireland No. 253804 X-Company-Info-2: Registered Offices: 1-2, Marino Mart, Fairview, Dublin 3 X-Company-Info-3: Internet Neutral Exchange Association Limited is limited by guarantee X-Company-Info-4: Offices: 4027 Kingswood Road, Citywest, Dublin 24. Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: "v6ops@ietf.org WG" Subject: Re: [v6ops] DHCPv6/SLAAC Make Hosts Confusing-//RE: new draft: draft-liu-bonica-v6ops-dhcpv6-slaac-problem X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 30 Oct 2013 22:14:58 -0000 On 30/10/2013 19:39, Mark ZZZ Smith wrote: >> The question is why would someone use RA for multiple gateway announcement >> when you'll get much better operational performance from a FHRP + single >> gateway address? And why use RA for addressing when you'll get finer >> grained operational host control using dhcp? > > It's been said a number of times in this thread. You can have client > specific RAs that solve that problem. This is not a missing capability > that duplicating RA functionality in DHCPv6 would then provide. You don't have address assignment with RA: you have prefix assignment and host address selection. I'm sure this is great for other people, but I do not want this behaviour on my networks, ever. I want address assignment via stateful dhcp. This is a missing capability of RA. >> Or when you need to use dhcp >> anyway in order to make your hosts do what they need to do? Or on server >> farms when most of your hosts are statically addressed and it doesn't make >> sense to have multiple gateways with different addresses - and you'll get >> better uptime by not using RA? >> >> I'm not proposing to take away the option of using RAs if that's what >> you >> want to do. I'm only suggesting that for many situations, it makes more >> sense to have a single static gateway address (optionally with multiple >> routers using a FHRP if you need reliability) and that consequently the >> idea of periodically announcing a selection of arbitrary gateways via RA is >> operationally second rate. >> > > I'd really like to know specific details of these many situations, and > what specific benefits switching off RAs would have. Please see my earlier email: http://www.ietf.org/mail-archive/web/v6ops/current/msg17769.html The standard argument of having multiple routers on a network announcing different prefixes and allowing host self-selection is a red herring. This is going to be an edge case because most networks are not multihomed. A small number are; let them use whatever they want. The standard argument of having multiple routers on a network announcing multiple gateways for the same prefix value is a red herring because the failover time for RA gateway address selection cannot match that of a FHRP based mechanism. No doubt some people will want to use multiple gateways addresses. If they do, I wish them well. If you want to run with RAs, then go for it. I don't because they add nothing to my production configurations except unnecessary complication. All my networks are mtu 1500 and I don't need to tweak ND timers and all that. Other than assigning a defgw, the only thing that RA does on my dhcp enabled networks is to point everything towards dhcp. From my point of view this is entirely pointless and if dhcpv6 had defgw assignment, I could ditch an entire protocol. This would be good (simpler configuration, easier to protect at L2, etc). For service provider and enterprise purposes, it is more sensible to centralise configuration and have a single protocol for assigning all network parameters than having two auto-configuration protocols doing slightly different things in slightly different ways with poorly defined interactions and several pitfalls if you don't know what you're doing. > I've been in many > situations in many networks, and when I consider my IPv4 experience (and > also compare it to my Novell IPX and Appletalk experiences), I see a lot > of value in having RAs provide default gateway(s) (VRRP/HSRP or not) > information and other layer 3 parameters to directly attached hosts from > the directly attached router(s). Glad it works for you. I see it as being utterly pointless, because it's an entire protocol just to provide a single network parameter which could just as easily be provided by another protocol which I need to run anyway because stateless dhcpv6 has stuff that I need to provide on production networks that RA doesn't provide. Does this work for you as a problem statement? What about any of the other reasons I've provided? > This is in comparison with the IPv4 > alternative effort of enabling and configuring a heavier and more > resource consuming stateful DHCP server on either the first hop routers, > or enabling DHCP relays and then having to have a redundant DHCP > infrastructure somewhere else in the network. stateful dhcpv4 works incredibly well in production. > It could be argued that DHCP could be enabled and configured by default, This is a straw man. Straw men don't help. Nick From Ted.Lemon@nominum.com Wed Oct 30 15:16:30 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1A8CE11E827A for ; Wed, 30 Oct 2013 15:16:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.588 X-Spam-Level: X-Spam-Status: No, score=-106.588 tagged_above=-999 required=5 tests=[AWL=0.011, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GaXxtK5OmL4E for ; Wed, 30 Oct 2013 15:16:23 -0700 (PDT) Received: from exprod7og101.obsmtp.com (exprod7og101.obsmtp.com [64.18.2.155]) by ietfa.amsl.com (Postfix) with ESMTP id 9B1ED11E81E6 for ; Wed, 30 Oct 2013 15:16:21 -0700 (PDT) Received: from shell-too.nominum.com ([64.89.228.229]) (using TLSv1) by exprod7ob101.postini.com ([64.18.6.12]) with SMTP ID DSNKUnGFMuupFF0QcwBRWkSYM5Shnx3tftge@postini.com; Wed, 30 Oct 2013 15:16: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 DDC231B82A4 for ; Wed, 30 Oct 2013 15:16:17 -0700 (PDT) Received: from webmail.nominum.com (cas-02.win.nominum.com [64.89.228.132]) (using TLSv1 with cipher RC4-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 D5F83190043; Wed, 30 Oct 2013 15:16:17 -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.03.0158.001; Wed, 30 Oct 2013 15:16:17 -0700 From: Ted Lemon To: "Bernie Volz (volz)" Thread-Topic: [v6ops] DHCPv6/SLAAC Make Hosts Confusing-//RE: new draft: draft-liu-bonica-v6ops-dhcpv6-slaac-problem Thread-Index: Ac7VuHt2iFBL+1h3kE6ceyrynOvMOAAP9baA Date: Wed, 30 Oct 2013 22:16:17 +0000 Message-ID: <38D115EE-C955-42ED-8437-543495EEA163@nominum.com> References: <489D13FBFA9B3E41812EA89F188F018E1AD4CBA4@xmb-rcd-x04.cisco.com> In-Reply-To: <489D13FBFA9B3E41812EA89F188F018E1AD4CBA4@xmb-rcd-x04.cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [192.168.1.10] Content-Type: text/plain; charset="iso-8859-1" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: Dave Thaler , "v6ops@ietf.org" , "draft-liu-bonica-v6ops-dhcpv6-slaac-problem@tools.ietf.org" , "Ole Troan \(otroan\)" Subject: Re: [v6ops] DHCPv6/SLAAC Make Hosts Confusing-//RE: new draft: draft-liu-bonica-v6ops-dhcpv6-slaac-problem X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 30 Oct 2013 22:16:30 -0000 On Oct 30, 2013, at 5:39 PM, Bernie Volz (volz) wrote: > This is a bit tricky to clarify. And, I am certain someone will have issu= es with my attempt; hopefully they can do better. One point of clarification that I found useful but was not universally appl= auded was the notion that if the protocol is or was in the Internet area, i= t's probably something you can configure with DHCP; if it's not, think care= fully before using DHCP to configure it. This lets out a _lot_ of stuff that has options in DHCPv4. But I can't th= ink of anything it excludes that I'd want to keep around. Of course, Mobi= le IPv6 is an Internet area protocol, and it's not entirely clear to me tha= t it's configurable via DHCP, although there exist DHCP options to configur= e it. From ayourtch@cisco.com Wed Oct 30 16:41:58 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C00A521E80A6 for ; Wed, 30 Oct 2013 16:41:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[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 TuQI2fiKFAGf for ; Wed, 30 Oct 2013 16:41:47 -0700 (PDT) Received: from rcdn-iport-9.cisco.com (rcdn-iport-9.cisco.com [173.37.86.80]) by ietfa.amsl.com (Postfix) with ESMTP id 732F121F9E52 for ; Wed, 30 Oct 2013 16:41:44 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1696; q=dns/txt; s=iport; t=1383176504; x=1384386104; h=date:from:to:cc:subject:in-reply-to:message-id: references:mime-version; bh=3Sv+YCOM6gn2A/jiNDGLFj3PZYb+07lix1eYRvKGonk=; b=WWRcotgtIu4x5ybTXunt8N6ggqyude+W5LGV1cxeGWPN7Ud3S3RlGkv8 bGi5rgNQKKNu5xJu6FM4xQHDrfE7ByabUctBKZsRm8a+s9KtJrSJAFPJG 5Kous1bpbGlVXBjAiREVCBodbvBZlqxi2Wbg7iq801t0h+JsgkD/v27n+ w=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgYFAGWYcVKtJXG//2dsb2JhbABZgweBDL9igSoWdIImAQEEOAI/EAs7C1cGDogMuwKPTweELAOqE4FogVqCDg X-IronPort-AV: E=Sophos;i="4.93,605,1378857600"; d="scan'208";a="275723471" Received: from rcdn-core2-4.cisco.com ([173.37.113.191]) by rcdn-iport-9.cisco.com with ESMTP; 30 Oct 2013 23:41:44 +0000 Received: from xhc-rcd-x14.cisco.com (xhc-rcd-x14.cisco.com [173.37.183.88]) by rcdn-core2-4.cisco.com (8.14.5/8.14.5) with ESMTP id r9UNfhen017978 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 30 Oct 2013 23:41:43 GMT Received: from localhost (144.254.73.146) by xhc-rcd-x14.cisco.com (173.37.183.88) with Microsoft SMTP Server (TLS) id 14.2.318.4; Wed, 30 Oct 2013 18:41:43 -0500 Date: Wed, 30 Oct 2013 19:41:17 -0400 From: Andrew Yourtchenko X-X-Sender: ayourtch@ayourtch-mac To: Mark ZZZ Smith In-Reply-To: <1383121368.56079.YahooMailNeo@web142505.mail.bf1.yahoo.com> Message-ID: References: <06601039-CAFD-49B0-918B-A8ACD51B978D@fugue.com> <1383036443.56704.YahooMailNeo@web142501.mail.bf1.yahoo.com> <1383074208.73179.YahooMailNeo@web142505.mail.bf1.yahoo.com> <1383121368.56079.YahooMailNeo@web142505.mail.bf1.yahoo.com> User-Agent: Alpine 2.00 (OSX 1167 2008-08-23) MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII"; format=flowed X-Originating-IP: [144.254.73.146] Cc: "v6ops@ietf.org" , Ted Lemon , "Ole Troan \(otroan\)" , Dave Thaler , "draft-liu-bonica-v6ops-dhcpv6-slaac-problem@tools.ietf.org" Subject: Re: [v6ops] DHCPv6/SLAAC Make Hosts Confusing-//RE: new draft: draft-liu-bonica-v6ops-dhcpv6-slaac-problem X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 30 Oct 2013 23:41:58 -0000 On Wed, 30 Oct 2013, Mark ZZZ Smith wrote: > (Disclaimer: Haven't had a chance to read the text yet) > > I would generalise the description of RAs. > > They're not "Router Advertisments", they're Advertisements (typically) >from Routers, and they propagate per-subnet IPv6 parameters to hosts - >per-link MTU, per-link ND timers, per-link address configuration method, >per-link on-link prefix status, default router lifetime (if not announced >as zero). The can be used to propagate per-client per-link IPv6 >parameters if necessary using unicasts. > > > I think DHCPv6 is really solving the application layer configuration >problem, which is independent of and not specific to the underlying links >and network layer parameters. I think IPv6 per-link parameter setting and >application layer parameter setting are conceptually quite different >problems (I think the sets of layer parameters they provide values for is >one of the give aways.) I will try to rephrase this into another section: -- cut -- Link-centric vs. client-centric RA traditionally provide the information pertaining to the link and its parameters, whereas DHCPv6 typically provides the information specific to the client configuration. However, this distinction is mostly a semantic one "by convention" - because technically nothing prevents to put a per-client configuration into an RA that would be sent unicast (at this point however the periodic multicast RA mechanism will break), as well as use the scopes in Stateless DHCPv6 with appropriate blobs of data to communicate the per-link parameter. -- cut -- Is this an adequate representation ? --a From evyncke@cisco.com Thu Oct 31 05:29:15 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3858921F9E54 for ; Thu, 31 Oct 2013 05:29:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.074 X-Spam-Level: X-Spam-Status: No, score=-10.074 tagged_above=-999 required=5 tests=[AWL=-0.075, BAYES_00=-2.599, J_CHICKENPOX_13=0.6, 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 mkTtKntXHI1o for ; Thu, 31 Oct 2013 05:29:10 -0700 (PDT) Received: from rcdn-iport-2.cisco.com (rcdn-iport-2.cisco.com [173.37.86.73]) by ietfa.amsl.com (Postfix) with ESMTP id D39DC21F9E91 for ; Thu, 31 Oct 2013 05:29:09 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1477; q=dns/txt; s=iport; t=1383222550; x=1384432150; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=HtGtMusMTpzTboiyXU8HMkX0Ksuc3gtcxT7LrgQ7BMo=; b=O7NHeYebK31ne/gSNYb/j7Oyy2CSUzoT+KFw+BXHeaFW1pSKxHTTc8/l bT3ZrSuWvMJHpdrN8gZf62vV80Im8GMCcaBHHhIizXn1lITJnnDK7bw04 oQHOX26Yo7/CaDzG4FIUB+F5W646TL53F6P4EFdoXidraR5cxXDrK2Ghl M=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AlQGALRMclKtJXHA/2dsb2JhbABZgwc4VL9qgSQWbQeCJQEBAQQBAQFrCwwEAgEIEQQBAQsdBycLFAkIAgQOBQiHfw28Fo8eMQcGgxqBDgOJCJAykFqDJoIq X-IronPort-AV: E=Sophos;i="4.93,608,1378857600"; d="scan'208";a="278920534" Received: from rcdn-core2-5.cisco.com ([173.37.113.192]) by rcdn-iport-2.cisco.com with ESMTP; 31 Oct 2013 12:29:09 +0000 Received: from xhc-aln-x09.cisco.com (xhc-aln-x09.cisco.com [173.36.12.83]) by rcdn-core2-5.cisco.com (8.14.5/8.14.5) with ESMTP id r9VCT9AR003431 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Thu, 31 Oct 2013 12:29:09 GMT Received: from xmb-aln-x02.cisco.com ([169.254.5.143]) by xhc-aln-x09.cisco.com ([173.36.12.83]) with mapi id 14.02.0318.004; Thu, 31 Oct 2013 07:29:09 -0500 From: "Eric Vyncke (evyncke)" To: "v6ops@ietf.org" Thread-Topic: [v6ops] new draft: draft-byrne-v6ops-clatip Thread-Index: AQHOxn/MbNcUnb4RF06iE7HhtcnLUZoO2R8Q Date: Thu, 31 Oct 2013 12:29:08 +0000 Message-ID: <97EB7536A2B2C549846804BBF3FD47E1237A6BA2@xmb-aln-x02.cisco.com> References: <201310111245.r9BCj0319881@ftpeng-update.cisco.com> In-Reply-To: <201310111245.r9BCj0319881@ftpeng-update.cisco.com> Accept-Language: fr-FR, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.82.237.195] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "draft-byrne-v6ops-clatip@tools.ietf.org" Subject: Re: [v6ops] new draft: draft-byrne-v6ops-clatip X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 31 Oct 2013 12:29:15 -0000 Cameron As you asked for a quick review, here we go :-) Getting a CLAT prefix from IANA sounds logical for me as we cannot 'steal' = a prefix from someone else. This would also allow some IPv4-only applicatio= n to detect CLAT (and possibly force the use of IPv6 even if happy eyeball = is not happy). My concern about re-using the DS-lite prefix is when (if ever) the CLAT wil= l then go over DS-lite in some weird (home?) network configurations... This= would confuse traceroute and possibly other ICMP mechanisms. Sharing the DS-lite prefix also prevents a dual-stack measurement apps to d= etect whether it uses DS-lite or CLAT for the IPv4 path. About measurements= , it is really easy to detect Teredo & 6to4 but much less 6RD (if you do no= t have the IPv4 address). So, 'just for measurements' I would love to have = another prefix for CLAT Hope this helps -=E9ric > -----Original Message----- > From: v6ops-bounces@ietf.org [mailto:v6ops-bounces@ietf.org] On Behalf Of > Fred Baker (fred) > Sent: vendredi 11 octobre 2013 14:45 > To: v6ops@ietf.org > Cc: draft-byrne-v6ops-clatip@tools.ietf.org > Subject: [v6ops] new draft: draft-byrne-v6ops-clatip >=20 >=20 > A new draft has been posted, at http://tools.ietf.org/html/draft-byrne- > v6ops-clatip. Please take a look at it and comment. > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops From cb.list6@gmail.com Thu Oct 31 07:04:26 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 75F4121F9D3E for ; Thu, 31 Oct 2013 07:04:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.249 X-Spam-Level: X-Spam-Status: No, score=-2.249 tagged_above=-999 required=5 tests=[AWL=-0.250, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_13=0.6, 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 X7EXaHEiEn1V for ; Thu, 31 Oct 2013 07:04:25 -0700 (PDT) Received: from mail-we0-x231.google.com (mail-we0-x231.google.com [IPv6:2a00:1450:400c:c03::231]) by ietfa.amsl.com (Postfix) with ESMTP id A7B0511E8196 for ; Thu, 31 Oct 2013 07:04:21 -0700 (PDT) Received: by mail-we0-f177.google.com with SMTP id x55so2671494wes.8 for ; Thu, 31 Oct 2013 07:04:20 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=dQX6hwiZRs+4+a12afcnUsVl0Rb0dBjYV/7eJNJj0vc=; b=lDyh1R3lID3L2rfpjMCf+tRiqparRH2OSQGwtlk89Vtq7Nj6sjOKJgD8+FfauTfWv8 1mwZqXoQL48GlLPmj9PbE2t13/eY6BgEVQVVl5lFsp6I3Jzk2BcYkbzitbtmNMRdFgTk +t1624fyrkkV2n0KhziXT/Hsl9DR8UYf/72LdQw2H3tUOeybxxvfOawYB9UtSvOlyqF9 k3QwQSTMwPbKePhgAaS9ZdTiHknu/C5MXlLJqldXheYs98i7iV+/Qh1wPHWTu2nqU6jk yC0/lBzt1te1cArf7YUuLddfr39rPo8aNkrkeULGPeiFUNadnfqZ68+gET2JPv0N/A9m CMig== MIME-Version: 1.0 X-Received: by 10.180.182.193 with SMTP id eg1mr1648916wic.49.1383228260849; Thu, 31 Oct 2013 07:04:20 -0700 (PDT) Received: by 10.216.99.68 with HTTP; Thu, 31 Oct 2013 07:04:20 -0700 (PDT) Received: by 10.216.99.68 with HTTP; Thu, 31 Oct 2013 07:04:20 -0700 (PDT) In-Reply-To: <97EB7536A2B2C549846804BBF3FD47E1237A6BA2@xmb-aln-x02.cisco.com> References: <201310111245.r9BCj0319881@ftpeng-update.cisco.com> <97EB7536A2B2C549846804BBF3FD47E1237A6BA2@xmb-aln-x02.cisco.com> Date: Thu, 31 Oct 2013 07:04:20 -0700 Message-ID: From: "cb.list6" To: "Eric Vyncke (evyncke)" Content-Type: multipart/alternative; boundary=089e016340ce219fa804ea09ed2e Cc: v6ops@ietf.org, draft-byrne-v6ops-clatip@tools.ietf.org Subject: Re: [v6ops] new draft: draft-byrne-v6ops-clatip X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 31 Oct 2013 14:04:26 -0000 --089e016340ce219fa804ea09ed2e Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Thanks Eric On Oct 31, 2013 5:29 AM, "Eric Vyncke (evyncke)" wrote: > > Cameron > > As you asked for a quick review, here we go :-) > > Getting a CLAT prefix from IANA sounds logical for me as we cannot 'steal' a prefix from someone else. This would also allow some IPv4-only application to detect CLAT (and possibly force the use of IPv6 even if happy eyeball is not happy). > In theory, yes, but 464xlat is only a band-aid for the most archaic apps, so I find it frustrating if someone tried to modify their app to have logic to use or not use CLAT instead of enabling ipv6 or generically using HE. Your line of thinking is correct in practice, I just dont like this certain reality :) In any event, the path in the i-d is to generalize the ds-lite range, such that in one step an app could know they are not on true dual-stack, they are on some overlay. > My concern about re-using the DS-lite prefix is when (if ever) the CLAT will then go over DS-lite in some weird (home?) network configurations... This would confuse traceroute and possibly other ICMP mechanisms. > The address is never on the wire from CLAT, and that topology should never occur since both 464xlat emit only ipv6, so there should be no case where the transition happens twice AND that on-path address responds... But you made me think about the case of tracerouting from 464xlat node to a ds-lite node across the ipv6 internet... And that b4 does not use the specific addresses reserved for b4s. In this case, the b4 can send a icmp ttl exceeded to the clat, where the clat will see the packet with a possible same source and destination > Sharing the DS-lite prefix also prevents a dual-stack measurement apps to detect whether it uses DS-lite or CLAT for the IPv4 path. About measurements, it is really easy to detect Teredo & 6to4 but much less 6RD (if you do not have the IPv4 address). So, 'just for measurements' I would love to have another prefix for CLAT > Another prefix dedicated for CLAT is an option. Thanks for the feedback. > Hope this helps > > -=E9ric > > > -----Original Message----- > > From: v6ops-bounces@ietf.org [mailto:v6ops-bounces@ietf.org] On Behalf Of > > Fred Baker (fred) > > Sent: vendredi 11 octobre 2013 14:45 > > To: v6ops@ietf.org > > Cc: draft-byrne-v6ops-clatip@tools.ietf.org > > Subject: [v6ops] new draft: draft-byrne-v6ops-clatip > > > > > > A new draft has been posted, at http://tools.ietf.org/html/draft-byrne- > > v6ops-clatip. Please take a look at it and comment. > > _______________________________________________ > > v6ops mailing list > > v6ops@ietf.org > > https://www.ietf.org/mailman/listinfo/v6ops > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops --089e016340ce219fa804ea09ed2e Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable

Thanks Eric

On Oct 31, 2013 5:29 AM, "Eric Vyncke (evyncke)" &= lt;evyncke@cisco.com> wrote: >
> Cameron
>
> As you asked for a quick review, here we go :-)
>
> Getting a CLAT prefix from IANA sounds logical for me as we cannot = 9;steal' a prefix from someone else. This would also allow some IPv4-on= ly application to detect CLAT (and possibly force the use of IPv6 even if h= appy eyeball is not happy).
>

In theory, yes, but 464xlat is only a band-aid for the most = archaic apps, so I find it frustrating if someone tried to modify their app= to have logic to use or not use CLAT instead of enabling ipv6 or generical= ly using HE.
Your line of thinking is correct in practice, I just dont like this certain= reality :)

In any event, the path in the i-d is to generalize the ds-li= te range,=A0 such that in one step an app could know they are not on true d= ual-stack, they are on some overlay.

> My concern about re-using the DS-lite prefix is when (i= f ever) the CLAT will then go over DS-lite in some weird (home?) network co= nfigurations... This would confuse traceroute and possibly other ICMP mecha= nisms.
>

The address is never on the wire from CLAT, and that topology should never = occur since both 464xlat emit only ipv6, so there should be no case where t= he transition happens twice AND that on-path address responds...

But you made me think about the case of=A0 tracerouting from= 464xlat node to a ds-lite node across the ipv6 internet... And=A0 that b4 = does not use the specific addresses reserved for b4s.=A0 In this case, the = b4 can send a icmp ttl exceeded to the clat, where the clat will see the pa= cket with a possible same source and destination

> Sharing the DS-lite prefix also prevents a dual-stack m= easurement apps to detect whether it uses DS-lite or CLAT for the IPv4 path= . About measurements, it is really easy to detect Teredo & 6to4 but muc= h less 6RD (if you do not have the IPv4 address). So, 'just for measure= ments' I would love to have another prefix for CLAT
>

Another=A0 prefix dedicated for CLAT is an option.=A0 Thanks= for the feedback.=A0

> Hope this helps
>
> -=E9ric
>
> > -----Original Message-----
> > From: v6ops-bounces@iet= f.org [mailto:v6ops-bounces@i= etf.org] On Behalf Of
> > Fred Baker (fred)
> > Sent: vendredi 11 octobre 2013 14:45
> > To: v6ops@ietf.org
> > Cc: dr= aft-byrne-v6ops-clatip@tools.ietf.org
> > Subject: [v6ops] new draft: draft-byrne-v6ops-clatip
> >
> >
> > A new draft has been posted, at http://tools.ietf.org/html/draft-byrne-
> > v6ops-clatip. Please take a look at it and comment.
> > _______________________________________________
> > v6ops mailing list
> > v6ops@ietf.org
> > https://w= ww.ietf.org/mailman/listinfo/v6ops
> _______________________________________________
> v6ops mailing list
> v6ops@ietf.org
> https://www.ie= tf.org/mailman/listinfo/v6ops

--089e016340ce219fa804ea09ed2e-- From lorenzo@google.com Thu Oct 31 07:16:46 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1C4C211E8146 for ; Thu, 31 Oct 2013 07:16:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.892 X-Spam-Level: X-Spam-Status: No, score=-1.892 tagged_above=-999 required=5 tests=[AWL=0.085, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, 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 bRdck2kgvU17 for ; Thu, 31 Oct 2013 07:16:45 -0700 (PDT) Received: from mail-ie0-x236.google.com (mail-ie0-x236.google.com [IPv6:2607:f8b0:4001:c03::236]) by ietfa.amsl.com (Postfix) with ESMTP id 14D7A11E8162 for ; Thu, 31 Oct 2013 07:16:44 -0700 (PDT) Received: by mail-ie0-f182.google.com with SMTP id as1so5121145iec.27 for ; Thu, 31 Oct 2013 07:16:44 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=9LCOSZCEOO+Z0SPe1G9+KHUSzmguJ6vdxjuHEDRHxHE=; b=i9pvNyNTlhrsTPGvyc7H4bWh/Kf7LbNVJA6JRQXK1e56wllictdjKuSByMEpICBgBO FVXbPYC9v0DogmF45DwBHUkcsIVPpQvIXO30JbQwPeBxnyBT8UTXt3M7BVheiX8VTxX/ YcfCrXsNATBpzLnX1s48/QxmnNXn552VL++cQZJkg2ZEAsrcppzfeMaFI1K5ReiO4gJe WqQ8J/6jbx68eyEes18ob4+FLvGPhosYuiyqmzBWZIyzHrCcqAKb6fn9KnTqxNQfk2pv enuy5nWUjKfW3Ktyz/kS0tbROle3chDo/FaZaqLKelXmbwxUcQerVOEc53f0k0G7w2FT Ja9w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type; bh=9LCOSZCEOO+Z0SPe1G9+KHUSzmguJ6vdxjuHEDRHxHE=; b=gLeoDjpCJ2ayRWLE/KDS12uXOMZzXFKYq/H0qyUFiP2J7R8uvcNThM3FCjt6CFvl2x LXyKjGqsDkg9r5tK7Z1OehhxIyB8Nc8P8lotpu/TU+kQxaYgydOGgUMLdWSpmjwBFNOQ neYwfuV1HcqBpwTgvToXPPl6Kyi17gJiuqQfT77r9uaXpemAnLMUNdoJZSYx8RXYiEpA 8HYJTdzHV5whdMr6olRRg4qkv73ThR3MXsnuhsZoLlTRFqlihfNM9Igp0DBMhMgWep5H a7m7ymDZVMCfu+4aNoAMQcALOvl3FZLEdS4IIv30bVulVXhBJ0TVF0nUXBF2Qr+0Hxdu 5yEQ== X-Gm-Message-State: ALoCoQnCtZkKLgABdvuXXmH0nvkQrNS5v2rqMvzITKk0uELZTITh4xvFM29IiAdGpZXtFjoWsOufyv4y6kSTMtD6TmK26MFQn3s5nk9KBRu/Jj5mLGzl4F2/kISZSC3GrWOBL18ueB1KzGfHN9+8+KIdGZW/u7N9Ne9ccmHmQ2WtG3DMsjsUZ8mIoEh/h7tt+qeLxe/fh+Mm X-Received: by 10.50.153.50 with SMTP id vd18mr7002370igb.6.1383229004590; Thu, 31 Oct 2013 07:16:44 -0700 (PDT) MIME-Version: 1.0 Received: by 10.64.86.106 with HTTP; Thu, 31 Oct 2013 07:16:24 -0700 (PDT) In-Reply-To: References: <201310111245.r9BCj0319881@ftpeng-update.cisco.com> <97EB7536A2B2C549846804BBF3FD47E1237A6BA2@xmb-aln-x02.cisco.com> From: Lorenzo Colitti Date: Thu, 31 Oct 2013 23:16:24 +0900 Message-ID: To: "cb.list6" Content-Type: multipart/alternative; boundary=089e013a009e76569404ea0a198f Cc: draft-byrne-v6ops-clatip@tools.ietf.org, "v6ops@ietf.org WG" Subject: Re: [v6ops] new draft: draft-byrne-v6ops-clatip X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 31 Oct 2013 14:16:46 -0000 --089e013a009e76569404ea0a198f Content-Type: text/plain; charset=ISO-8859-1 On Thu, Oct 31, 2013 at 11:04 PM, cb.list6 wrote: > The address is never on the wire from CLAT, and that topology should never > occur since both 464xlat emit only ipv6, so there should be no case where > the transition happens twice AND that on-path address responds... > > But you made me think about the case of tracerouting from 464xlat node to > a ds-lite node across the ipv6 internet... And that b4 does not use the > specific addresses reserved for b4s. In this case, the b4 can send a icmp > ttl exceeded to the clat, where the clat will see the packet with a > possible same source and destination > But that can't happen, right? Nobody will ever see either the 464xlat IP address or the DS-Lite IP address, because neither ever appears on the wire - both terminals will see the public IPv4 address of the other side. Even if they pass each other their IP addresses through some other mechanism (e.g., SIP), that's no different from the case where two machines talk to each other and both have the IPv4 address 192.168.1.2. --089e013a009e76569404ea0a198f Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
On Thu, Oct 31, 2013 at 11:04 PM, cb.list6 <cb.list6@gma= il.com> wrote:

The address is never on the w= ire from CLAT, and that topology should never occur since both 464xlat emit= only ipv6, so there should be no case where the transition happens twice A= ND that on-path address responds...

But you made me think about the case of=A0 tracerouting from= 464xlat node to a ds-lite node across the ipv6 internet... And=A0 that b4 = does not use the specific addresses reserved for b4s.=A0 In this case, the = b4 can send a icmp ttl exceeded to the clat, where the clat will see the pa= cket with a possible same source and destination

But that can't happen, right? Nobody will ever see ei= ther the 464xlat IP address or the DS-Lite IP address, because neither ever= appears on the wire - both terminals will see the public IPv4 address of t= he other side.

Even if they pass each other their IP addresses through= some other mechanism (e.g., SIP), that's no different from the case wh= ere two machines talk to each other and both have the IPv4 address 192.168.= 1.2.
--089e013a009e76569404ea0a198f-- From cb.list6@gmail.com Thu Oct 31 07:28:55 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8CDD921E805D for ; Thu, 31 Oct 2013 07:28:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.513 X-Spam-Level: X-Spam-Status: No, score=-2.513 tagged_above=-999 required=5 tests=[AWL=0.086, BAYES_00=-2.599, HTML_MESSAGE=0.001, 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 kHmMq+A2mrs8 for ; Thu, 31 Oct 2013 07:28:55 -0700 (PDT) Received: from mail-wg0-x229.google.com (mail-wg0-x229.google.com [IPv6:2a00:1450:400c:c00::229]) by ietfa.amsl.com (Postfix) with ESMTP id B945C11E8167 for ; Thu, 31 Oct 2013 07:28:54 -0700 (PDT) Received: by mail-wg0-f41.google.com with SMTP id b13so7391691wgh.2 for ; Thu, 31 Oct 2013 07:28:53 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=ba86kAaQAkkKvuYyhXB+ZbwoY2oN1CzjSAm2Vzv/FRo=; b=uY3IKCVabomaES3OWJXMSmQMual5Z0jGe5WYGlb98bh1s9VMVWXl0dZnUZv41vSYKR ym+MC4X3+BEvfcfHDjw45G7zK5TC9C2SNoWRFCqAzS2kT8StN728JExoMpsmHEzw9yE4 OS4TLzw/FEgUfgPN8usIazF5MxJDvXiOF7Jsm5tuYAaoeEBdSZhjpEKxYSMJSxIxURFm QeeLXWDA16kltzrogb81AitBW/fg7lsqWSvM2iAFBvfUlAYzZMmZ8c72TAnl8UtjD9RP dQgm6hQwsIRdFNkG1m8GognsfKNj3v74S+ymLd8LrzsX73YJqUhaqmMlJKDQA/OqRvRx 24sw== MIME-Version: 1.0 X-Received: by 10.180.76.69 with SMTP id i5mr7134957wiw.34.1383229733749; Thu, 31 Oct 2013 07:28:53 -0700 (PDT) Received: by 10.216.99.68 with HTTP; Thu, 31 Oct 2013 07:28:53 -0700 (PDT) Received: by 10.216.99.68 with HTTP; Thu, 31 Oct 2013 07:28:53 -0700 (PDT) In-Reply-To: References: <201310111245.r9BCj0319881@ftpeng-update.cisco.com> <97EB7536A2B2C549846804BBF3FD47E1237A6BA2@xmb-aln-x02.cisco.com> Date: Thu, 31 Oct 2013 07:28:53 -0700 Message-ID: From: "cb.list6" To: Lorenzo Colitti Content-Type: multipart/alternative; boundary=f46d043c7e68ec48de04ea0a4485 Cc: draft-byrne-v6ops-clatip@tools.ietf.org, "v6ops@ietf.org WG" Subject: Re: [v6ops] new draft: draft-byrne-v6ops-clatip X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 31 Oct 2013 14:28:55 -0000 --f46d043c7e68ec48de04ea0a4485 Content-Type: text/plain; charset=ISO-8859-1 On Oct 31, 2013 7:16 AM, "Lorenzo Colitti" wrote: > > On Thu, Oct 31, 2013 at 11:04 PM, cb.list6 wrote: >> >> The address is never on the wire from CLAT, and that topology should never occur since both 464xlat emit only ipv6, so there should be no case where the transition happens twice AND that on-path address responds... >> >> But you made me think about the case of tracerouting from 464xlat node to a ds-lite node across the ipv6 internet... And that b4 does not use the specific addresses reserved for b4s. In this case, the b4 can send a icmp ttl exceeded to the clat, where the clat will see the packet with a possible same source and destination > > But that can't happen, right? Nobody will ever see either the 464xlat IP address or the DS-Lite IP address, because neither ever appears on the wire - both terminals will see the public IPv4 address of the other side. > You are right. In the case I was thinking of I overlooked that the aftr would translate the ipv4 to public before returning towards the clat. Furthermore, I doubt the range would be allowed to be translated to a public ipv4 as a matter of policy on the aftr CB > Even if they pass each other their IP addresses through some other mechanism (e.g., SIP), that's no different from the case where two machines talk to each other and both have the IPv4 address 192.168.1.2. --f46d043c7e68ec48de04ea0a4485 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable


On Oct 31, 2013 7:16 AM, "Lorenzo Colitti" <lorenzo@google.com> wrote:
>
> On Thu, Oct 31, 2013 at 11:04 PM, cb.list6 <cb.list6@gmail.com> wrote:
>>
>> The address is never on the wire from CLAT, and that topology shou= ld never occur since both 464xlat emit only ipv6, so there should be no cas= e where the transition happens twice AND that on-path address responds... >>
>> But you made me think about the case of=A0 tracerouting from 464xl= at node to a ds-lite node across the ipv6 internet... And=A0 that b4 does n= ot use the specific addresses reserved for b4s.=A0 In this case, the b4 can= send a icmp ttl exceeded to the clat, where the clat will see the packet w= ith a possible same source and destination
>
> But that can't happen, right? Nobody will ever see either the 464x= lat IP address or the DS-Lite IP address, because neither ever appears on t= he wire - both terminals will see the public IPv4 address of the other side= .
>

You are right.=A0 In the case I was thinking of I overlooked= that the aftr would translate the ipv4 to public before returning towards = the clat.

Furthermore, I doubt the range would be allowed to be transl= ated to a public ipv4 as a matter of policy on the aftr

CB
> Even if they pass each other their IP addresses through some other mec= hanism (e.g., SIP), that's no different from the case where two machine= s talk to each other and both have the IPv4 address 192.168.1.2.

--f46d043c7e68ec48de04ea0a4485--