From nobody Mon Jan 4 09:04:24 2016 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 682381A8ABA for ; Mon, 4 Jan 2016 09:04:23 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.511 X-Spam-Level: X-Spam-Status: No, score=-14.511 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CeWzF5fzJyRI for ; Mon, 4 Jan 2016 09:04:22 -0800 (PST) Received: from rcdn-iport-7.cisco.com (rcdn-iport-7.cisco.com [173.37.86.78]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1C08A1A8AA1 for ; Mon, 4 Jan 2016 09:04:22 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2358; q=dns/txt; s=iport; t=1451927062; x=1453136662; h=from:to:subject:date:message-id:references:in-reply-to: content-id:content-transfer-encoding:mime-version; bh=0tMJbVrFJeB38NKA3mzhwNifP0d6a3dtHIg2mJbQy9c=; b=O93pg3t3H8uMdZtQRJvjL9Wud8vTh/4e8OO1GjHNnuH3AI7AJ8OYPr0n l+oyRztfMul5eN32ubjZkfx6KoLLQ6OS+KwOSvo4bk6EwXfmcKrQ8swS2 sI8ZNWdyMul7LXP2Xf9w+hFwXQ4JkSwrbS677dzRQ1+SR4OaUYmXczL1R U=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0D/AQAkpYpW/4sNJK1egzpSbQaIU7N2A?= =?us-ascii?q?Q2BZCSFawIcgQA4FAEBAQEBAQGBCoQ1AQEEIxE6GwIBCBoCERUCAgIfERUQAgQ?= =?us-ascii?q?BEogaAxIOsBeNfQ2CdAEBAQEBAQEBAQEBAQEBAQEBAQEWBIEBhVUBhH6CT4IGG?= =?us-ascii?q?CmCXYFJBZcGAYU/hhmBeI57hmGHWAEgAQFChApyhAiBCAEBAQ?= X-IronPort-AV: E=Sophos;i="5.20,521,1444694400"; d="scan'208";a="58523024" Received: from alln-core-6.cisco.com ([173.36.13.139]) by rcdn-iport-7.cisco.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 04 Jan 2016 17:04:21 +0000 Received: from XCH-RTP-012.cisco.com (xch-rtp-012.cisco.com [64.101.220.152]) by alln-core-6.cisco.com (8.14.5/8.14.5) with ESMTP id u04H4Kqx013427 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Mon, 4 Jan 2016 17:04:21 GMT Received: from xch-rtp-015.cisco.com (64.101.220.155) by XCH-RTP-012.cisco.com (64.101.220.152) with Microsoft SMTP Server (TLS) id 15.0.1104.5; Mon, 4 Jan 2016 12:04:20 -0500 Received: from xch-rtp-015.cisco.com ([64.101.220.155]) by XCH-RTP-015.cisco.com ([64.101.220.155]) with mapi id 15.00.1104.009; Mon, 4 Jan 2016 12:04:20 -0500 From: "Eric Vyncke (evyncke)" To: Bob Hinden , IPv6 List Subject: Re: 6MAN WG Last Call - draft-ietf-6man-deprecate-atomfrag-generation Thread-Topic: 6MAN WG Last Call - draft-ietf-6man-deprecate-atomfrag-generation Thread-Index: AQHRNxas2BdjRKpLAkOViS/LrjGptZ7sGkwA Date: Mon, 4 Jan 2016 17:04:20 +0000 Message-ID: References: <7BEE06A2-0F6E-493F-B2C6-68DAB3774FD5@gmail.com> In-Reply-To: <7BEE06A2-0F6E-493F-B2C6-68DAB3774FD5@gmail.com> Accept-Language: fr-FR, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.5.9.151119 x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.55.56.4] Content-Type: text/plain; charset="utf-8" Content-ID: Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 04 Jan 2016 17:04:23 -0000 Qm9iLCB0aGFua3MgZm9yIHRoZSBleHRlbmRlZCBXR0xDLg0KDQpJIGRvIG5vdCBzZWUgYSByZWFs IHZhbHVlIGluIHRoaXMgcHJvcG9zYWwgKHNvcnJ5IEZlcm5hbmRvICYgVG9yZSk6DQoxKSB0aGUg YXR0YWNrIHZlY3RvciBjYW4gYWxzbyBiZSB1c2VkIHdpdGggYSBwYWNrZXQtdG9vLWJpZyBNVFU9 MTQwMCwgaXQNCndpbGwgZm9yY2UgcmVhbCBmcmFnbWVudHMgdG8gYmUgc2VudC4gU28sIGRlcHJl Y2F0aW5nIGF0b21pYyBmcmFnbWVudCBoYXMNCmxpdHRsZSB2YWx1ZSBvciBhbSBJIG1pc3Npbmcg c29tZXRoaW5nPw0KMikgdGhlIGNvcmUgaXNzdWUgaXMgdGhhdCB0cmFuc2l0IHByb3ZpZGVycyBk cm9wICdub3JtYWwnIGZyYWdtZW50cyAoYXMNCm9wcG9zZWQgdG8gdGhlIGV2aWwgUkZDIDcxMTIp LCB0aGlzIGlzIHRoZSByZWFsIHByb2JsZW0gdGhhdCBuZWVkIHRvIGJlDQpzb2x2ZWQgYW55d2F5 IGJlY2F1c2Ugbm9ybWFsIGZyYWdtZW50cyB3aWxsIHN0aWxsIGhhcHBlbg0KDQpFbHNlLCBpbmRl ZWQgdGhlIE5BVDY0IGZ1bmN0aW9uIGNvdWxkIGJlY29tZSBzdGF0ZWZ1bCBmb3IgdGhvc2UgcGFj a2V0cyBhdA0KdGhlIHJpc2sgb2YgYmVjb21pbmcgdGhlIHRhcmdldCBvZiBhIERvUyB0aGVtc2Vs dmVzIDstKQ0KDQpTb3JyeSB0byBzdGFydCB0aGUgeWVhciB3aXRoIGEgbmVnYXRpdmUgY29tbWVu dA0KDQpIYXBweSBOZXcgWWVhciBhbnl3YXkgOi0pDQoNCi3DqXJpYw0KDQoNCk9uIDE1LzEyLzE1 IDA5OjU3LCAiaXB2NiBvbiBiZWhhbGYgb2YgQm9iIEhpbmRlbiIgPGlwdjYtYm91bmNlc0BpZXRm Lm9yZw0Kb24gYmVoYWxmIG9mIGJvYi5oaW5kZW5AZ21haWwuY29tPiB3cm90ZToNCg0KPlRoaXMg bWVzc2FnZSByZXN0YXJ0cyBhIHR3byB3ZWVrIDZNQU4gV29ya2luZyBHcm91cCBMYXN0IENhbGwg b24NCj5hZHZhbmNpbmc6DQo+DQo+ICAgVGl0bGUgICAgICAgICAgIDogRGVwcmVjYXRpb24gb2Yg dGhlIEdlbmVyYXRpb24gb2YgSVB2NiBBdG9taWMNCj5GcmFnbWVudHMNCj4gICBBdXRob3JzICAg ICAgICAgOiBGZXJuYW5kbyBHb250DQo+ICAgICAgICAgICAgICAgICAgICAgV2lsbChTaHVjaGVu ZykgTGl1DQo+ICAgICAgICAgICAgICAgICAgICAgVG9yZSBBbmRlcnNvbg0KPiAgIEZpbGVuYW1l ICAgICAgICA6IGRyYWZ0LWlldGYtNm1hbi1kZXByZWNhdGUtYXRvbWZyYWctZ2VuZXJhdGlvbi0w NC50eHQNCj4gICBQYWdlcyAgICAgICAgICAgOiA5DQo+ICAgRGF0ZSAgICAgICAgICAgIDogMjAx NS0xMS0yNg0KPg0KPiAgIA0KPmh0dHBzOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1pZXRm LTZtYW4tZGVwcmVjYXRlLWF0b21mcmFnLWdlbmVyYXRpb24tDQo+MDQNCj4NCj5hcyBhbiBJbmZv cm1hdGlvbmFsIERvY3VtZW50LiAgU3Vic3RhbnRpdmUgY29tbWVudHMgYW5kIHN0YXRlbWVudHMg b2YNCj5zdXBwb3J0IGZvciBwdWJsaXNoaW5nIHRoaXMgZG9jdW1lbnQgc2hvdWxkIGJlIGRpcmVj dGVkIHRvIHRoZSBtYWlsaW5nDQo+bGlzdC4gIEVkaXRvcmlhbCBzdWdnZXN0aW9ucyBjYW4gYmUg c2VudCB0byB0aGUgYXV0aG9ycy4gIFRoaXMgbGFzdCBjYWxsDQo+d2lsbCBlbmQgb24gMTIgSmFu dWFyeSAyMDE2LiAgVGhpcyBpcyBhIGZvdXIgd2VlayBsYXN0IGNhbGwgdG8gYWNjb3VudA0KPmZv ciB0aGUgaG9saWRheXMgaW4gRGVjZW1iZXIuDQo+DQo+QmVzdCByZWdhcmRzLA0KPk9sZSAmIEJv Yg0KPg0KPg0KDQo= From nobody Mon Jan 4 11:08:36 2016 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F3EB21A1A91 for ; Mon, 4 Jan 2016 11:08:34 -0800 (PST) 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=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cKPSL0DsLRXJ for ; Mon, 4 Jan 2016 11:08:33 -0800 (PST) Received: from mail-qg0-x229.google.com (mail-qg0-x229.google.com [IPv6:2607:f8b0:400d:c04::229]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0BFEF1A21A4 for ; Mon, 4 Jan 2016 11:08:33 -0800 (PST) Received: by mail-qg0-x229.google.com with SMTP id e32so170961749qgf.3 for ; Mon, 04 Jan 2016 11:08:33 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=subject:mime-version:content-type:from:in-reply-to:date:cc :message-id:references:to; bh=Y2fX7r8WXgFRRzcImDuy1q0Cqlq/44CqaoNKeTAoo7w=; b=rL0MwYC5CV00bEQMC1L2BZw2GWe3ziUOToNsWpOvWwwGgoesaINLxBWfkrFBDoLHm8 0FLQX7zAZENfDl5rwTtdy7mYELRVCNqRCfrMbd4wDhgDXOTUsGE5Ac0UANKpVWTHsk2f xYMJiwLLhp9RgTLQ8Hr9ufLvKYpDr5qTzUKrFnJPqlfyQil3/XOpyB4buxZuwAao809X xPMb+X92TPiDkmMA/G0D0Pyn3zuu1HGYcJ+IpwTdUMYs3wcnxOZFOCGnbw5eYmN7abWp uJ3wnoYqDND8tk8yBsRe+V9GtUTWnQgIwoyrs9s32D4R6Mt7V7BNawEjPdDJ+zFkKwYz pI1Q== X-Received: by 10.140.102.228 with SMTP id w91mr107956436qge.21.1451934512216; Mon, 04 Jan 2016 11:08:32 -0800 (PST) Received: from [172.16.224.219] ([209.97.127.34]) by smtp.gmail.com with ESMTPSA id 201sm40337225qhf.21.2016.01.04.11.08.30 (version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Mon, 04 Jan 2016 11:08:30 -0800 (PST) Subject: Re: 6MAN WG Last Call - draft-ietf-6man-deprecate-atomfrag-generation Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2104\)) Content-Type: multipart/signed; boundary="Apple-Mail=_598F018F-D359-4BA5-A5E8-772B3556634B"; protocol="application/pgp-signature"; micalg=pgp-sha512 X-Pgp-Agent: GPGMail 2.5.2 From: Bob Hinden In-Reply-To: Date: Mon, 4 Jan 2016 11:08:26 -0800 Message-Id: <696861A5-7714-4A3F-8ACE-8D7F25A89A81@gmail.com> References: <7BEE06A2-0F6E-493F-B2C6-68DAB3774FD5@gmail.com> To: "Eric Vyncke (evyncke)" X-Mailer: Apple Mail (2.2104) Archived-At: Cc: IPv6 List , Bob Hinden X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 04 Jan 2016 19:08:35 -0000 --Apple-Mail=_598F018F-D359-4BA5-A5E8-772B3556634B Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Hi Eric, > On Jan 4, 2016, at 9:04 AM, Eric Vyncke (evyncke) = wrote: >=20 > Bob, thanks for the extended WGLC. >=20 Given the holidays it was appropriate. > I do not see a real value in this proposal (sorry Fernando & Tore): > 1) the attack vector can also be used with a packet-too-big MTU=3D1400, = it > will force real fragments to be sent. So, deprecating atomic fragment = has > little value or am I missing something? My understand the attack is forcing =E2=80=9Catomic=E2=80=9D fragments = to be sent. Before this change (now removed in rfc1981bis and = rfc2460bis) this could be triggered by sending a packet too big with an = MTU of less than 1280. The case you mention would cause two fragments to be sent (assuming the = MTU of the packet was >1400), not an atomic fragement. The text removed = was specific about MTUs < 1280. Does that help? Bob > 2) the core issue is that transit providers drop 'normal' fragments = (as > opposed to the evil RFC 7112), this is the real problem that need to = be > solved anyway because normal fragments will still happen >=20 > Else, indeed the NAT64 function could become stateful for those = packets at > the risk of becoming the target of a DoS themselves ;-) >=20 > Sorry to start the year with a negative comment >=20 > Happy New Year anyway :-) >=20 > -=C3=A9ric >=20 >=20 > On 15/12/15 09:57, "ipv6 on behalf of Bob Hinden" = on behalf of bob.hinden@gmail.com> wrote: >=20 >> This message restarts a two week 6MAN Working Group Last Call on >> advancing: >>=20 >> Title : Deprecation of the Generation of IPv6 Atomic >> Fragments >> Authors : Fernando Gont >> Will(Shucheng) Liu >> Tore Anderson >> Filename : = draft-ietf-6man-deprecate-atomfrag-generation-04.txt >> Pages : 9 >> Date : 2015-11-26 >>=20 >>=20 >> = https://tools.ietf.org/html/draft-ietf-6man-deprecate-atomfrag-generation-= >> 04 >>=20 >> as an Informational Document. Substantive comments and statements of >> support for publishing this document should be directed to the = mailing >> list. Editorial suggestions can be sent to the authors. This last = call >> will end on 12 January 2016. This is a four week last call to = account >> for the holidays in December. >>=20 >> Best regards, >> Ole & Bob >>=20 >>=20 >=20 --Apple-Mail=_598F018F-D359-4BA5-A5E8-772B3556634B 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 - https://gpgtools.org iQEcBAEBCgAGBQJWisMrAAoJEK7rdBF357uoIVgIAIiv6Brn2hmTahJZS8VIR1ui OOmwIb0hd8xLKOwj7r3H03uVMpt+c/IA7XqecImEtoHNbQXXjecs83QAYsOH7Z2c NbaWfRWmnM/bO9/wyta8IiEZoLuRursg1zRpMaOyf2N1xaLyMc5dCcQT2uJXjc3a yccsnDpbQc3nAONL7yxqJaJFBEMaI7vvOtb2x1zfSqbredwNyb++ngMVdxD1kIGC EjaWmWYwLJEBYTlrH1OwJJkhpg6Jr7uWYITncgVW1sXt0hCCkeWgP4iteQK1nz8h VbQYMPFklu4tBgl28A0rKjlTwEVLlubRMsT9Rb/AOAhy6YDruaKXq08HoIQ8VOI= =WIbD -----END PGP SIGNATURE----- --Apple-Mail=_598F018F-D359-4BA5-A5E8-772B3556634B-- From nobody Tue Jan 5 06:50:02 2016 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AA3E11A8775 for ; Tue, 5 Jan 2016 06:50:00 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.983 X-Spam-Level: X-Spam-Status: No, score=-4.983 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_ADSP_CUSTOM_MED=0.001, FREEMAIL_FROM=0.001, HELO_EQ_FR=0.35, NML_ADSP_CUSTOM_MED=0.9, RCVD_IN_DNSWL_HI=-5, SPF_SOFTFAIL=0.665] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jrUz0bCz71Gm for ; Tue, 5 Jan 2016 06:49:59 -0800 (PST) Received: from sainfoin-out.extra.cea.fr (sainfoin-out.extra.cea.fr [132.167.192.145]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CA8081A8774 for ; Tue, 5 Jan 2016 06:49:58 -0800 (PST) Received: from pisaure.intra.cea.fr (pisaure.intra.cea.fr [132.166.88.21]) by sainfoin.extra.cea.fr (8.15.2/8.15.2/CEAnet-Internet-out-2.4) with ESMTP id u05EnuEp002284 for ; Tue, 5 Jan 2016 15:49:56 +0100 Received: from pisaure.intra.cea.fr (localhost [127.0.0.1]) by localhost (Postfix) with SMTP id 4085A204526 for ; Tue, 5 Jan 2016 15:57:22 +0100 (CET) Received: from muguet2.intra.cea.fr (muguet2.intra.cea.fr [132.166.192.7]) by pisaure.intra.cea.fr (Postfix) with ESMTP id 3059A204509 for ; Tue, 5 Jan 2016 15:57:22 +0100 (CET) Received: from [10.8.34.184] (is227335.intra.cea.fr [10.8.34.184]) by muguet2.intra.cea.fr (8.15.2/8.15.2/CEAnet-Intranet-out-1.4) with ESMTP id u05Enug9029826 for ; Tue, 5 Jan 2016 15:49:56 +0100 Subject: Re: To: ipv6@ietf.org References: From: Alexandre Petrescu Message-ID: <568BD814.4030100@gmail.com> Date: Tue, 5 Jan 2016 15:49:56 +0100 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.5.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit Archived-At: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 Jan 2016 14:50:00 -0000 I reviewed the changes. They look ok. I found one nit: > For this purpose, the Encapsulating Security Payload (ESP) is not > considered an extension headers. ^ strike s. Additionally, I think rfc2460bis lists all extension headers. If so, I would like to suggest to refer to the Mobility Header extension header. This extension header is defined in RFC6275 "Mobile IPv6". Is this ok? Alex Le 16/12/2015 08:56, Bob Hinden a écrit : > I published the -02 version of 6man working group draft of > rfc2460bis. Links below. > > It has the changes based on the discussion at the 6MAN session at the > Yokohama IETF. These include > > Added text to Section 4.8 "Defining New Extension Headers and > Options" clarifying why no new hop by hop extension headers should be > defined. > > Added text to Fragment Header process on handling exact duplicate > fragments. > > A few editorial changes. > > A diff from the -02 version can be found at: > > https://www.ietf.org/rfcdiff?url2=draft-ietf-6man-rfc2460bis-02 > > Please review the changes. > > Thanks, Bob > >> A New Internet-Draft is available from the on-line Internet-Drafts >> directories. This draft is a work item of the IPv6 Maintenance >> Working Group of the IETF. >> >> Title : Internet Protocol, Version 6 (IPv6) >> Specification Authors : Stephen E. Deering Robert M. >> Hinden Filename : draft-ietf-6man-rfc2460bis-02.txt Pages >> : 37 Date : 2015-12-15 >> >> Abstract: This document specifies version 6 of the Internet >> Protocol (IPv6), also sometimes referred to as IP Next Generation >> or IPng. It obsoletes RFC2460 >> >> >> The IETF datatracker status page for this draft is: >> https://datatracker.ietf.org/doc/draft-ietf-6man-rfc2460bis/ >> >> There's also a htmlized version available at: >> https://tools.ietf.org/html/draft-ietf-6man-rfc2460bis-02 >> >> A diff from the previous version is available at: >> https://www.ietf.org/rfcdiff?url2=draft-ietf-6man-rfc2460bis-02 >> >> >> 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/ >> >> >> -------------------------------------------------------------------- >> >> IETF IPv6 working group mailing list >> ipv6@ietf.org Administrative Requests: >> https://www.ietf.org/mailman/listinfo/ipv6 >> -------------------------------------------------------------------- From nobody Tue Jan 5 11:06:10 2016 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8A6991B2C11 for ; Tue, 5 Jan 2016 11:06:09 -0800 (PST) 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=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id loEzWwUefZWe for ; Tue, 5 Jan 2016 11:06:07 -0800 (PST) Received: from mail-pf0-x22a.google.com (mail-pf0-x22a.google.com [IPv6:2607:f8b0:400e:c00::22a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CA9021B2C19 for ; Tue, 5 Jan 2016 11:06:07 -0800 (PST) Received: by mail-pf0-x22a.google.com with SMTP id e65so171678954pfe.1 for ; Tue, 05 Jan 2016 11:06:07 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=subject:to:references:from:organization:message-id:date:user-agent :mime-version:in-reply-to:content-type:content-transfer-encoding; bh=O4KvcG6NB1UQIPnjiH1vYzsLxmHqzsGA9Gr5kyHHeUM=; b=p6TK4AlsPn3vMHK+grWVumK8GwXY6FdI40ici9k3BcJOqdjxrHvw51ysL1xdXVPQUu ihCHKIupyk78OpqFEOTzxnuQS4p6mLhnfiCuiwSWULXS8Q2HxScbeiZzAwhDSsqQc9W9 QVrOZ07A5immVJWwXPkRO5y+q+7RnEaMmwibItKb7zCNtDWoshgNQtF30QoVLb8Jxbzj sUGvnjHvMevLPl1DS3V/7bNhrmoLoo2Kbew8mQElwOxfChvUb0yqV1oDLTN4tyItYYlO 6uLCx0HdAt/GzbuaBlWjUJdULzRwi4frg3RPzh+zSgXcyrdN45+jSRN7BSz9vdnvSLS3 fxyg== X-Received: by 10.98.87.69 with SMTP id l66mr55991870pfb.85.1452020767370; Tue, 05 Jan 2016 11:06:07 -0800 (PST) Received: from ?IPv6:2406:e007:6264:1:28cc:dc4c:9703:6781? ([2406:e007:6264:1:28cc:dc4c:9703:6781]) by smtp.gmail.com with ESMTPSA id h90sm94440274pfj.23.2016.01.05.11.06.04 (version=TLSv1/SSLv3 cipher=OTHER); Tue, 05 Jan 2016 11:06:05 -0800 (PST) Subject: Re: To: Alexandre Petrescu , ipv6@ietf.org References: <568BD814.4030100@gmail.com> From: Brian E Carpenter Organization: University of Auckland Message-ID: <568C1432.8040600@gmail.com> Date: Wed, 6 Jan 2016 08:06:26 +1300 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.5.0 MIME-Version: 1.0 In-Reply-To: <568BD814.4030100@gmail.com> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Archived-At: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 Jan 2016 19:06:09 -0000 On 06/01/2016 03:49, Alexandre Petrescu wrote: > I reviewed the changes. They look ok. I found one nit: >=20 >> For this purpose, the Encapsulating Security Payload (ESP) is not >> considered an extension headers. > ^ strike s. >=20 > Additionally, I think rfc2460bis lists all extension headers. No it doesn't. We have an explicit IANA registry for that, as defined by = RFC 7045: http://www.iana.org/assignments/ipv6-parameters/ipv6-parameters.xhtml#ext= ension-header Brian >=20 > If so, I would like to suggest to refer to the Mobility Header extensio= n header. This extension header is defined in RFC6275 > "Mobile IPv6". >=20 > Is this ok? >=20 > Alex >=20 >=20 > Le 16/12/2015 08:56, Bob Hinden a =C3=A9crit : >> I published the -02 version of 6man working group draft of >> rfc2460bis. Links below. >> >> It has the changes based on the discussion at the 6MAN session at the >> Yokohama IETF. These include >> >> Added text to Section 4.8 "Defining New Extension Headers and >> Options" clarifying why no new hop by hop extension headers should be >> defined. >> >> Added text to Fragment Header process on handling exact duplicate >> fragments. >> >> A few editorial changes. >> >> A diff from the -02 version can be found at: >> >> https://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-6man-rfc2460bis-02 >> >> Please review the changes. >> >> Thanks, Bob >> >>> A New Internet-Draft is available from the on-line Internet-Drafts >>> directories. This draft is a work item of the IPv6 Maintenance >>> Working Group of the IETF. >>> >>> Title : Internet Protocol, Version 6 (IPv6) >>> Specification Authors : Stephen E. Deering Robert M. >>> Hinden Filename : draft-ietf-6man-rfc2460bis-02.txt Pages >>> : 37 Date : 2015-12-15 >>> >>> Abstract: This document specifies version 6 of the Internet >>> Protocol (IPv6), also sometimes referred to as IP Next Generation >>> or IPng. It obsoletes RFC2460 >>> >>> >>> The IETF datatracker status page for this draft is: >>> https://datatracker.ietf.org/doc/draft-ietf-6man-rfc2460bis/ >>> >>> There's also a htmlized version available at: >>> https://tools.ietf.org/html/draft-ietf-6man-rfc2460bis-02 >>> >>> A diff from the previous version is available at: >>> https://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-6man-rfc2460bis-02 >>> >>> >>> 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/ >>> >>> >>> -------------------------------------------------------------------- >>> >>> > IETF IPv6 working group mailing list >>> ipv6@ietf.org Administrative Requests: >>> https://www.ietf.org/mailman/listinfo/ipv6 >>> -------------------------------------------------------------------- >=20 > -------------------------------------------------------------------- > IETF IPv6 working group mailing list > ipv6@ietf.org > Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 > -------------------------------------------------------------------- >=20 From nobody Tue Jan 5 15:23:37 2016 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 224741A9107 for ; Tue, 5 Jan 2016 15:23:36 -0800 (PST) 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=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id I3g8Nny3UAZl for ; Tue, 5 Jan 2016 15:23:34 -0800 (PST) Received: from mail-qg0-x22e.google.com (mail-qg0-x22e.google.com [IPv6:2607:f8b0:400d:c04::22e]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6B7931AC3FF for ; Tue, 5 Jan 2016 15:23:33 -0800 (PST) Received: by mail-qg0-x22e.google.com with SMTP id b35so161083872qge.0 for ; Tue, 05 Jan 2016 15:23:33 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=subject:mime-version:content-type:from:in-reply-to:date:cc :message-id:references:to; bh=bO1CMXC/VF+SXnCWPAjPJ+z49A9xuyIoRpna1+hpZ5Y=; b=I8EfJGQ2xlI5bsuwYRi3evTC/iPnr3MZb8MVfuo7fpQsgYfg0S96X+BsoTz6mzH7Lo u/BRcvQAywIt3H3K3LAxRw57/HTPi8wfic1UG5W1dC5OZay83RYFX1jNhUgOS3KnYSLI e2U+SqkZ3RuaBOe8SZ+1RxhcBNfbedkygaTncJnHcCEQDd8+ZZq2ZZ1z4yc/+CKhJeWw XjkZmpsO5KtRNcePd72zT17+AU/dvFFMgor95maUZ8rYTCokBuF1AadBKildFIMitJJW dUgk/MlfEZcN9RdvBw859Yejt0z+dznIO4hZ852FOe2+SGxRZRto7dSnAtI+iOmaIkFY 2Lzg== X-Received: by 10.140.157.206 with SMTP id d197mr106460015qhd.3.1452036212586; Tue, 05 Jan 2016 15:23:32 -0800 (PST) Received: from [172.16.224.219] ([209.97.127.34]) by smtp.gmail.com with ESMTPSA id x137sm1393015qhx.23.2016.01.05.15.23.31 (version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Tue, 05 Jan 2016 15:23:31 -0800 (PST) Subject: Re: Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2104\)) Content-Type: multipart/signed; boundary="Apple-Mail=_7E2C0F12-B028-437C-AE98-B5F20D886352"; protocol="application/pgp-signature"; micalg=pgp-sha512 X-Pgp-Agent: GPGMail 2.5.2 From: Bob Hinden In-Reply-To: <568C1432.8040600@gmail.com> Date: Tue, 5 Jan 2016 15:23:28 -0800 Message-Id: References: <568BD814.4030100@gmail.com> <568C1432.8040600@gmail.com> To: Brian Carpenter X-Mailer: Apple Mail (2.2104) Archived-At: Cc: IPv6 List , Alexandre Petrescu , Bob Hinden X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 Jan 2016 23:23:36 -0000 --Apple-Mail=_7E2C0F12-B028-437C-AE98-B5F20D886352 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 > On Jan 5, 2016, at 11:06 AM, Brian E Carpenter = wrote: >=20 > On 06/01/2016 03:49, Alexandre Petrescu wrote: >> I reviewed the changes. They look ok. I found one nit: >>=20 >>> For this purpose, the Encapsulating Security Payload (ESP) is not >>> considered an extension headers. >> ^ strike s. >>=20 >> Additionally, I think rfc2460bis lists all extension headers. >=20 > No it doesn't. We have an explicit IANA registry for that, as defined = by RFC 7045: > = http://www.iana.org/assignments/ipv6-parameters/ipv6-parameters.xhtml#exte= nsion-header Correct. Looking at the document, I think it would make sense to add to = the end of Section 4 a reference to that IANA registry. Thanks, Bob >=20 > Brian >=20 >>=20 >> If so, I would like to suggest to refer to the Mobility Header = extension header. This extension header is defined in RFC6275 >> "Mobile IPv6". >>=20 >> Is this ok? >>=20 >> Alex >>=20 >>=20 >> Le 16/12/2015 08:56, Bob Hinden a =C3=A9crit : >>> I published the -02 version of 6man working group draft of >>> rfc2460bis. Links below. >>>=20 >>> It has the changes based on the discussion at the 6MAN session at = the >>> Yokohama IETF. These include >>>=20 >>> Added text to Section 4.8 "Defining New Extension Headers and >>> Options" clarifying why no new hop by hop extension headers should = be >>> defined. >>>=20 >>> Added text to Fragment Header process on handling exact duplicate >>> fragments. >>>=20 >>> A few editorial changes. >>>=20 >>> A diff from the -02 version can be found at: >>>=20 >>> https://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-6man-rfc2460bis-02 >>>=20 >>> Please review the changes. >>>=20 >>> Thanks, Bob >>>=20 >>>> A New Internet-Draft is available from the on-line Internet-Drafts >>>> directories. This draft is a work item of the IPv6 Maintenance >>>> Working Group of the IETF. >>>>=20 >>>> Title : Internet Protocol, Version 6 (IPv6) >>>> Specification Authors : Stephen E. Deering Robert M. >>>> Hinden Filename : draft-ietf-6man-rfc2460bis-02.txt Pages >>>> : 37 Date : 2015-12-15 >>>>=20 >>>> Abstract: This document specifies version 6 of the Internet >>>> Protocol (IPv6), also sometimes referred to as IP Next Generation >>>> or IPng. It obsoletes RFC2460 >>>>=20 >>>>=20 >>>> The IETF datatracker status page for this draft is: >>>> https://datatracker.ietf.org/doc/draft-ietf-6man-rfc2460bis/ >>>>=20 >>>> There's also a htmlized version available at: >>>> https://tools.ietf.org/html/draft-ietf-6man-rfc2460bis-02 >>>>=20 >>>> A diff from the previous version is available at: >>>> https://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-6man-rfc2460bis-02 >>>>=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 >>>>=20 >>>> = -------------------------------------------------------------------- >>>>=20 >>>>=20 >> IETF IPv6 working group mailing list >>>> ipv6@ietf.org Administrative Requests: >>>> https://www.ietf.org/mailman/listinfo/ipv6 >>>> = -------------------------------------------------------------------- >>=20 >> -------------------------------------------------------------------- >> IETF IPv6 working group mailing list >> ipv6@ietf.org >> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 >> -------------------------------------------------------------------- >>=20 >=20 > -------------------------------------------------------------------- > IETF IPv6 working group mailing list > ipv6@ietf.org > Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 > -------------------------------------------------------------------- --Apple-Mail=_7E2C0F12-B028-437C-AE98-B5F20D886352 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 - https://gpgtools.org iQEcBAEBCgAGBQJWjFBxAAoJEK7rdBF357uo7wIH/1/FLxODE/Mew2gmiOZeGl90 bKBbmYoEqur/gSKfDKzgAQcXzkaBA3J6bkF27iMVJ0ifhzxslT5AydnpU4AXAb3+ 8fxzxtIj9+bVG1oSuoKcRCvYxo6HK5PsGj63IdsTkdukXRAt04kFHZ6g9ylBU3lg Qpgqvaj+53UFX1apH6CeFnYgRPg2q90BkMHMDv3yRXQpwp4Ks3QXnny3wFSa1gF2 NzuOfrz3j7Z/Fi7wEzidDN39gHs4jOE5VTp9y/Tuihp1F642C2q2+GtOGif3mmTh aRpmlqMjAiIEzZsboisSZOjySC/X9LRV4C7U4AWqO67EQuCnog9eJZ4rCxy5PxU= =+OBr -----END PGP SIGNATURE----- --Apple-Mail=_7E2C0F12-B028-437C-AE98-B5F20D886352-- From nobody Tue Jan 5 18:54:23 2016 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 97ABB1A8A39 for ; Tue, 5 Jan 2016 18:54:21 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.501 X-Spam-Level: X-Spam-Status: No, score=-0.501 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0Sp0XkbMyBlO for ; Tue, 5 Jan 2016 18:54:19 -0800 (PST) Received: from fgont.go6lab.si (fgont.go6lab.si [91.239.96.14]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 841171A8A1C for ; Tue, 5 Jan 2016 18:54:19 -0800 (PST) Received: from [192.168.0.112] (unknown [190.49.45.213]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by fgont.go6lab.si (Postfix) with ESMTPSA id C329B20687F; Tue, 5 Jan 2016 21:53:53 -0500 (EST) Subject: Re: 6MAN WG Last Call - draft-ietf-6man-deprecate-atomfrag-generation To: "Eric Vyncke (evyncke)" , Bob Hinden , IPv6 List References: <7BEE06A2-0F6E-493F-B2C6-68DAB3774FD5@gmail.com> From: Fernando Gont X-Enigmail-Draft-Status: N1110 Message-ID: <568C775C.2030300@si6networks.com> Date: Tue, 5 Jan 2016 23:09:32 -0300 User-Agent: Mozilla/5.0 (X11; Linux i686; rv:38.0) Gecko/20100101 Thunderbird/38.4.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Archived-At: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Jan 2016 02:54:21 -0000 On 01/04/2016 02:04 PM, Eric Vyncke (evyncke) wrote: > Bob, thanks for the extended WGLC. > > I do not see a real value in this proposal (sorry Fernando & Tore): > 1) the attack vector can also be used with a packet-too-big MTU=1400, it > will force real fragments to be sent. So, deprecating atomic fragment has > little value or am I missing something? This is the bit you seem to be missing: In the case you describe, such packet will not trigger fragmentation, but rather a reduction of the assumed Path-MTU. -- i.e., even in the case a host is employing Path-MTU Discovery, an ICMPv6 PTB < 1280 would trigger fragmentation. i.e., you could trigger the use of fragmentation for traffic that would otherwise not employ fragmentation. (step #2 would be to perform a frag-based DoS attack -- although with the widespread filtering of fragments, at times just triggering fragmentation would do the trick (kernel.org was an example of this)). > 2) the core issue is that transit providers drop 'normal' fragments (as > opposed to the evil RFC 7112), this is the real problem that need to be > solved anyway because normal fragments will still happen Not really. The core of the issue is that you shouldn't employ fragmentation unless you really need it (stateful operation for an otherwise stateless protocol, etc., etc.). The widespread filtering of fragments simply means that if an attacker is able to trigger fragmentation, in many cases he will not need to perform any frag-based attack, because the network will, unfortunately, already filter the packets. Another core issue is that it is a bad idea to allow a random node to trigger the use of fragmentation for traffic that otherwise wouldn't employ it (e.g., TCP doing Path-MTU Discovery). > Sorry to start the year with a negative comment Hopefully the above clarifies the background ;-) Thanks! Best regards, -- Fernando Gont SI6 Networks e-mail: fgont@si6networks.com PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492 From nobody Wed Jan 6 04:22:58 2016 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 72DF31AD0A1 for ; Wed, 6 Jan 2016 04:22:56 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.983 X-Spam-Level: X-Spam-Status: No, score=-4.983 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_ADSP_CUSTOM_MED=0.001, FREEMAIL_FROM=0.001, HELO_EQ_FR=0.35, NML_ADSP_CUSTOM_MED=0.9, RCVD_IN_DNSWL_HI=-5, SPF_SOFTFAIL=0.665] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XmMSrimcdSZs for ; Wed, 6 Jan 2016 04:22:53 -0800 (PST) Received: from sainfoin-out.extra.cea.fr (sainfoin-out.extra.cea.fr [132.167.192.145]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 486431AD0BF for ; Wed, 6 Jan 2016 04:22:53 -0800 (PST) Received: from pisaure.intra.cea.fr (pisaure.intra.cea.fr [132.166.88.21]) by sainfoin.extra.cea.fr (8.15.2/8.15.2/CEAnet-Internet-out-2.4) with ESMTP id u06CModg014023; Wed, 6 Jan 2016 13:22:50 +0100 Received: from pisaure.intra.cea.fr (localhost [127.0.0.1]) by localhost (Postfix) with SMTP id A95A4200EC4; Wed, 6 Jan 2016 13:30:17 +0100 (CET) Received: from muguet1.intra.cea.fr (muguet1.intra.cea.fr [132.166.192.6]) by pisaure.intra.cea.fr (Postfix) with ESMTP id 9B53D200CBD; Wed, 6 Jan 2016 13:30:17 +0100 (CET) Received: from [10.8.34.184] (is227335.intra.cea.fr [10.8.34.184]) by muguet1.intra.cea.fr (8.15.2/8.15.2/CEAnet-Intranet-out-1.4) with ESMTP id u06CMofk023395; Wed, 6 Jan 2016 13:22:50 +0100 Subject: Re: To: Bob Hinden References: <568BD814.4030100@gmail.com> <568C1432.8040600@gmail.com> From: Alexandre Petrescu Message-ID: <568D071A.10403@gmail.com> Date: Wed, 6 Jan 2016 13:22:50 +0100 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.5.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Archived-At: Cc: IPv6 List X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Jan 2016 12:22:56 -0000 Le 06/01/2016 00:23, Bob Hinden a écrit : > >> On Jan 5, 2016, at 11:06 AM, Brian E Carpenter >> wrote: >> >> On 06/01/2016 03:49, Alexandre Petrescu wrote: >>> I reviewed the changes. They look ok. I found one nit: >>> >>>> For this purpose, the Encapsulating Security Payload (ESP) is >>>> not considered an extension headers. >>> ^ strike s. >>> >>> Additionally, I think rfc2460bis lists all extension headers. >> >> No it doesn't. We have an explicit IANA registry for that, as >> defined by RFC 7045: >> http://www.iana.org/assignments/ipv6-parameters/ipv6-parameters.xhtml#extension-header > >> > Correct. Looking at the document, I think it would make sense to add > to the end of Section 4 a reference to that IANA registry. I agree. Alex > > Thanks, Bob > > >> >> Brian >> >>> >>> If so, I would like to suggest to refer to the Mobility Header >>> extension header. This extension header is defined in RFC6275 >>> "Mobile IPv6". >>> >>> Is this ok? >>> >>> Alex >>> >>> >>> Le 16/12/2015 08:56, Bob Hinden a écrit : >>>> I published the -02 version of 6man working group draft of >>>> rfc2460bis. Links below. >>>> >>>> It has the changes based on the discussion at the 6MAN session >>>> at the Yokohama IETF. These include >>>> >>>> Added text to Section 4.8 "Defining New Extension Headers and >>>> Options" clarifying why no new hop by hop extension headers >>>> should be defined. >>>> >>>> Added text to Fragment Header process on handling exact >>>> duplicate fragments. >>>> >>>> A few editorial changes. >>>> >>>> A diff from the -02 version can be found at: >>>> >>>> https://www.ietf.org/rfcdiff?url2=draft-ietf-6man-rfc2460bis-02 >>>> >>>> >>>> Please review the changes. >>>> >>>> Thanks, Bob >>>> >>>>> A New Internet-Draft is available from the on-line >>>>> Internet-Drafts directories. This draft is a work item of the >>>>> IPv6 Maintenance Working Group of the IETF. >>>>> >>>>> Title : Internet Protocol, Version 6 (IPv6) >>>>> Specification Authors : Stephen E. Deering Robert M. >>>>> Hinden Filename : draft-ietf-6man-rfc2460bis-02.txt >>>>> Pages : 37 Date : 2015-12-15 >>>>> >>>>> Abstract: This document specifies version 6 of the Internet >>>>> Protocol (IPv6), also sometimes referred to as IP Next >>>>> Generation or IPng. It obsoletes RFC2460 >>>>> >>>>> >>>>> The IETF datatracker status page for this draft is: >>>>> https://datatracker.ietf.org/doc/draft-ietf-6man-rfc2460bis/ >>>>> >>>>> There's also a htmlized version available at: >>>>> https://tools.ietf.org/html/draft-ietf-6man-rfc2460bis-02 >>>>> >>>>> A diff from the previous version is available at: >>>>> https://www.ietf.org/rfcdiff?url2=draft-ietf-6man-rfc2460bis-02 >>>>> >>>>> >>>>> >>>>> 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/ >>>>> >>>>> >>>>> -------------------------------------------------------------------- >>>>> >>>>> >>> >>>>> IETF IPv6 working group mailing list >>>>> ipv6@ietf.org Administrative Requests: >>>>> https://www.ietf.org/mailman/listinfo/ipv6 >>>>> -------------------------------------------------------------------- >>> >>> >>>>> -------------------------------------------------------------------- >>> IETF IPv6 working group mailing list ipv6@ietf.org Administrative >>> Requests: https://www.ietf.org/mailman/listinfo/ipv6 >>> -------------------------------------------------------------------- >>> >> >> >>> -------------------------------------------------------------------- >> IETF IPv6 working group mailing list ipv6@ietf.org Administrative >> Requests: https://www.ietf.org/mailman/listinfo/ipv6 >> -------------------------------------------------------------------- > From nobody Wed Jan 6 04:34:56 2016 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AA76B1B2AA9 for ; Wed, 6 Jan 2016 04:34:49 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.983 X-Spam-Level: X-Spam-Status: No, score=-4.983 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_ADSP_CUSTOM_MED=0.001, FREEMAIL_FROM=0.001, HELO_EQ_FR=0.35, NML_ADSP_CUSTOM_MED=0.9, RCVD_IN_DNSWL_HI=-5, SPF_SOFTFAIL=0.665] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bo_2FJpsuJoO for ; Wed, 6 Jan 2016 04:34:45 -0800 (PST) Received: from cirse-out.extra.cea.fr (cirse-out.extra.cea.fr [132.167.192.142]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 890D21B2AAF for ; Wed, 6 Jan 2016 04:34:45 -0800 (PST) Received: from pisaure.intra.cea.fr (pisaure.intra.cea.fr [132.166.88.21]) by cirse.extra.cea.fr (8.15.2/8.15.2/CEAnet-Internet-out-2.4) with ESMTP id u06CYhW5025536; Wed, 6 Jan 2016 13:34:43 +0100 Received: from pisaure.intra.cea.fr (localhost [127.0.0.1]) by localhost (Postfix) with SMTP id F2BC72035FB; Wed, 6 Jan 2016 13:42:09 +0100 (CET) Received: from muguet1.intra.cea.fr (muguet1.intra.cea.fr [132.166.192.6]) by pisaure.intra.cea.fr (Postfix) with ESMTP id E675F2034BA; Wed, 6 Jan 2016 13:42:09 +0100 (CET) Received: from [10.8.34.184] (is227335.intra.cea.fr [10.8.34.184]) by muguet1.intra.cea.fr (8.15.2/8.15.2/CEAnet-Intranet-out-1.4) with ESMTP id u06CYgmX002171; Wed, 6 Jan 2016 13:34:42 +0100 Subject: Re: To: Brian E Carpenter References: <568BD814.4030100@gmail.com> <568C1432.8040600@gmail.com> From: Alexandre Petrescu Message-ID: <568D09E2.6010107@gmail.com> Date: Wed, 6 Jan 2016 13:34:42 +0100 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.5.0 MIME-Version: 1.0 In-Reply-To: <568C1432.8040600@gmail.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Archived-At: Cc: ipv6@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Jan 2016 12:34:49 -0000 Le 05/01/2016 20:06, Brian E Carpenter a écrit : > On 06/01/2016 03:49, Alexandre Petrescu wrote: >> I reviewed the changes. They look ok. I found one nit: >> >>> For this purpose, the Encapsulating Security Payload (ESP) is not >>> considered an extension headers. >> ^ strike s. >> >> Additionally, I think rfc2460bis lists all extension headers. > > No it doesn't. We have an explicit IANA registry for that, as defined by RFC 7045: > http://www.iana.org/assignments/ipv6-parameters/ipv6-parameters.xhtml#extension-header I can agree one should rather look explicitly at a IANA registry to find all extensions headers. At the same time, it would be expected that EH text in rfc2460 would apply equally well to each particular EH. Especially, what EHs were "currently defined" at the time of 2460 became more numerous now for new2460. For example, the following text: > 4.2. Options > > Two of the currently-defined extension headers -- the Hop-by-Hop > Options header and the Destination Options header -- carry a variable > number of type-length-value (TLV) encoded "options", of the following > format: should rather say "_Three_ of the currently-defined extension headers -- the Hop-by-Hop Options header, the Destination Options header and the Mobility Header -- carry a variable number of TLVs...". Or maybe it could say "Some of the EHs (e.g. HbH, DO, MH, other) carry a variable number of TLVs". Otherwise, 2460 reads as _only two_ _currently-defined_ EHs carry TLVs. Which doesn't read quite right because the new MH (absent when 2460 was out) carries a variable number of TLVs too. For ref the Mobility Header is at: http://tools.ietf.org/html/rfc6275#section-6.1 Yours, Alex or > > Brian > >> >> If so, I would like to suggest to refer to the Mobility Header extension header. This extension header is defined in RFC6275 >> "Mobile IPv6". >> >> Is this ok? >> >> Alex >> >> >> Le 16/12/2015 08:56, Bob Hinden a écrit : >>> I published the -02 version of 6man working group draft of >>> rfc2460bis. Links below. >>> >>> It has the changes based on the discussion at the 6MAN session at the >>> Yokohama IETF. These include >>> >>> Added text to Section 4.8 "Defining New Extension Headers and >>> Options" clarifying why no new hop by hop extension headers should be >>> defined. >>> >>> Added text to Fragment Header process on handling exact duplicate >>> fragments. >>> >>> A few editorial changes. >>> >>> A diff from the -02 version can be found at: >>> >>> https://www.ietf.org/rfcdiff?url2=draft-ietf-6man-rfc2460bis-02 >>> >>> Please review the changes. >>> >>> Thanks, Bob >>> >>>> A New Internet-Draft is available from the on-line Internet-Drafts >>>> directories. This draft is a work item of the IPv6 Maintenance >>>> Working Group of the IETF. >>>> >>>> Title : Internet Protocol, Version 6 (IPv6) >>>> Specification Authors : Stephen E. Deering Robert M. >>>> Hinden Filename : draft-ietf-6man-rfc2460bis-02.txt Pages >>>> : 37 Date : 2015-12-15 >>>> >>>> Abstract: This document specifies version 6 of the Internet >>>> Protocol (IPv6), also sometimes referred to as IP Next Generation >>>> or IPng. It obsoletes RFC2460 >>>> >>>> >>>> The IETF datatracker status page for this draft is: >>>> https://datatracker.ietf.org/doc/draft-ietf-6man-rfc2460bis/ >>>> >>>> There's also a htmlized version available at: >>>> https://tools.ietf.org/html/draft-ietf-6man-rfc2460bis-02 >>>> >>>> A diff from the previous version is available at: >>>> https://www.ietf.org/rfcdiff?url2=draft-ietf-6man-rfc2460bis-02 >>>> >>>> >>>> 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/ >>>> >>>> >>>> -------------------------------------------------------------------- >>>> >>>> >> IETF IPv6 working group mailing list >>>> ipv6@ietf.org Administrative Requests: >>>> https://www.ietf.org/mailman/listinfo/ipv6 >>>> -------------------------------------------------------------------- >> >> -------------------------------------------------------------------- >> IETF IPv6 working group mailing list >> ipv6@ietf.org >> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 >> -------------------------------------------------------------------- >> > > From nobody Wed Jan 6 06:17:06 2016 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F08611B2BBC for ; Wed, 6 Jan 2016 06:17:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.242 X-Spam-Level: X-Spam-Status: No, score=0.242 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DATE_IN_PAST_06_12=1.543, J_CHICKENPOX_35=0.6, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7hxt7nT5SoTz for ; Wed, 6 Jan 2016 06:17:02 -0800 (PST) Received: from fgont.go6lab.si (fgont.go6lab.si [91.239.96.14]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5A15E1ACEEA for ; Wed, 6 Jan 2016 06:17:02 -0800 (PST) Received: from [192.168.0.112] (unknown [190.49.45.213]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by fgont.go6lab.si (Postfix) with ESMTPSA id 0BD35206889; Wed, 6 Jan 2016 09:16:35 -0500 (EST) Subject: Re: 6MAN WG Last Call - draft-ietf-6man-deprecate-atomfrag-generation To: Bob Hinden , "Eric Vyncke (evyncke)" References: <7BEE06A2-0F6E-493F-B2C6-68DAB3774FD5@gmail.com> <696861A5-7714-4A3F-8ACE-8D7F25A89A81@gmail.com> From: Fernando Gont X-Enigmail-Draft-Status: N1110 Message-ID: <568C9C26.6060804@si6networks.com> Date: Wed, 6 Jan 2016 01:46:30 -0300 User-Agent: Mozilla/5.0 (X11; Linux i686; rv:38.0) Gecko/20100101 Thunderbird/38.4.0 MIME-Version: 1.0 In-Reply-To: <696861A5-7714-4A3F-8ACE-8D7F25A89A81@gmail.com> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 8bit Archived-At: Cc: IPv6 List X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Jan 2016 14:17:04 -0000 On 01/04/2016 04:08 PM, Bob Hinden wrote: >> I do not see a real value in this proposal (sorry Fernando & >> Tore): 1) the attack vector can also be used with a packet-too-big >> MTU=1400, it will force real fragments to be sent. So, deprecating >> atomic fragment has little value or am I missing something? > > My understand the attack is forcing “atomic” fragments to be sent. > Before this change (now removed in rfc1981bis and rfc2460bis) this > could be triggered by sending a packet too big with an MTU of less > than 1280. > > The case you mention would cause two fragments to be sent (assuming > the MTU of the packet was >1400), not an atomic fragement. The text > removed was specific about MTUs < 1280. Eric's case will not really trigger fragmentation of any sort for the typical TCP+PMTUD case -- it will just cause the assumed Path-MTU to be decreased... but without triggering any sort of fragmentation. The cornercase we're deprecating in rfc2460bis was the only vector an attacker had to trigger fragmentation in any arbitrary flow. Thanks, -- Fernando Gont SI6 Networks e-mail: fgont@si6networks.com PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492 From nobody Wed Jan 6 07:47:30 2016 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B7B471A88EA for ; Wed, 6 Jan 2016 07:47:29 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.511 X-Spam-Level: X-Spam-Status: No, score=-14.511 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8FMsxG6gBkgV for ; Wed, 6 Jan 2016 07:47:27 -0800 (PST) Received: from alln-iport-7.cisco.com (alln-iport-7.cisco.com [173.37.142.94]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BC8E41A8855 for ; Wed, 6 Jan 2016 07:47:27 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=4234; q=dns/txt; s=iport; t=1452095247; x=1453304847; h=from:to:subject:date:message-id:references:in-reply-to: content-id:content-transfer-encoding:mime-version; bh=VvBDWrXLEtBOiYEQ7V8Ppl+ae1SgTJWs0/Ex3Luzweo=; b=ITtEhMeoQf+NNCkxjbHSzflzSa8azR6jVSenF+wv0OPb1jeiWAwxCzdm VOw7LSzDFQq1dPMTqFdDu3TwYWF0YxdAQ+VDsle2z5wRL1ql3m07j7gcA RWJMr+bXXXkXLmw6UC8r+KcXCXtHPDqJ7cLgNpXzwiO6Gyxdk3AlT+jKV M=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0D8AQDONY1W/4YNJK1egzpSbQaIU7NVA?= =?us-ascii?q?Q2BZBqFdQIcgQU4FAEBAQEBAQGBCoQ1AQEEIxFVAgEIDgoCAiYCAgIwFRACBAE?= =?us-ascii?q?SiC+xK5BdAQEBAQEBAQMBAQEBAQEdgQGFVQGEfoRVGIMGgUkFlwoBhUGIE4FcS?= =?us-ascii?q?ocjhTGKVINyASABAUKECnKEWYEIAQEB?= X-IronPort-AV: E=Sophos;i="5.20,529,1444694400"; d="scan'208";a="224724412" Received: from alln-core-12.cisco.com ([173.36.13.134]) by alln-iport-7.cisco.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 06 Jan 2016 15:47:26 +0000 Received: from XCH-RTP-011.cisco.com (xch-rtp-011.cisco.com [64.101.220.151]) by alln-core-12.cisco.com (8.14.5/8.14.5) with ESMTP id u06FlQaH023906 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Wed, 6 Jan 2016 15:47:26 GMT Received: from xch-rtp-015.cisco.com (64.101.220.155) by XCH-RTP-011.cisco.com (64.101.220.151) with Microsoft SMTP Server (TLS) id 15.0.1104.5; Wed, 6 Jan 2016 10:47:25 -0500 Received: from xch-rtp-015.cisco.com ([64.101.220.155]) by XCH-RTP-015.cisco.com ([64.101.220.155]) with mapi id 15.00.1104.009; Wed, 6 Jan 2016 10:47:26 -0500 From: "Eric Vyncke (evyncke)" To: Fernando Gont , Bob Hinden , IPv6 List Subject: Re: 6MAN WG Last Call - draft-ietf-6man-deprecate-atomfrag-generation Thread-Topic: 6MAN WG Last Call - draft-ietf-6man-deprecate-atomfrag-generation Thread-Index: AQHRSCdI2BdjRKpLAkOViS/LrjGptZ7vB1kA Date: Wed, 6 Jan 2016 15:47:25 +0000 Message-ID: References: <7BEE06A2-0F6E-493F-B2C6-68DAB3774FD5@gmail.com> <568C775C.2030300@si6networks.com> In-Reply-To: <568C775C.2030300@si6networks.com> Accept-Language: fr-FR, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.5.9.151119 x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.55.56.4] Content-Type: text/plain; charset="utf-8" Content-ID: <5435FC1EFADC114992AF097B6CE2C06D@emea.cisco.com> Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Jan 2016 15:47:29 -0000 RmVybmFuZCAoYW5kIEJvYiksDQoNCkZpcnN0IHRoYW5rcyBmb3IgeW91ciByZXBsaWVzLg0KICgN CkFib3V0IFBUQiA+IDEyODA6IEkgaGF2ZSB0byByZWFkIFJGQzI0NjBiaXMsIGJ1dCwgdGhlICdv bGQnIFJGQyAyNDYwDQpzdGF0ZXMgdGhhdCB3aGVuIHRoZSBwYXRoIE1UVSBmb3Igb25lIGRlc3Rp bmF0aW9uIGlzIHNtYWxsZXIgdGhhbiB0aGUNCnBoeXNpY2FsIE1UVSwgdGhlbiBlaXRoZXIgZnJh Z21lbnRhdGlvbiAoYmFkKSBvciBhcHBsaWNhdGlvbiAocHJlZmVycmVkKQ0KbXVzdCBhZGFwdC4g VG8gYmUgaG9uZXN0LCBJIGRvIG5vdCBoYXZlIGFueSBkYXRhIGJhY2tpbmcgaG93DQpob3N0cy9h cHBsaWNhdGlvbnMgcmVhY3QgaW4gdGhhdCBjYXNlLiBJZiBob3N0cyBjb21tb25seSBkbyBmcmFn bWVudGF0aW9uDQpiZWNhdXNlIGFwcCBpcyBpZ25vcmFudCBvZiB0aGUgTVRVLCB0aGVuIHRoZSBh dHRhY2sgaXMgYWxzbyBwb3NzaWJsZSBvbg0Kbm9uIGF0b21pYyBmcmFnbWVudC4gQWdhaW4sIEkg c2hvdWxkIHJlYWQgUkZDMjQ2MCBiaXMgcmVnYXJkaW5nIHRoZSBwTVRVZA0KcGFydC4NCg0KVGhl biwgd2UgYWdyZWUgb24gdGhlIGZhY3QgdGhhdCBmcmFnbWVudGF0aW9uIHNob3VsZCByZWFsbHkg YmUgZGlzY291cmFnZWQNCmZvciBzZWN1cml0eSBhbmQgcGVyZm9ybWFuY2UgcmVhc29ucyA6LSkg QW5kIHdlIGFyZSBhbHNvIGluICd2aW9sZW50Jw0KYWdyZWVtZW50IG9uIHRoZSBmYWN0IHRoYXQg dGhpcyBpcyByZWFsbHkgbm90IHNlY3VyZSB0byBhbGxvdyBhbnkgbm9kZSB0bw0KcmVkdWNlIHRo ZSBNVFUgYmV0d2VlbiB0d28gb3RoZXIgcGFydGllcy4uLiBPVE9IIG5vdCBhbiBlYXN5IHByb2Js ZW0gdG8NCmZpeC4NCg0KUmVnYXJkcw0KDQotw6lyaWMNCg0KDQpPbiA2LzAxLzE2IDAzOjA5LCAi RmVybmFuZG8gR29udCIgPGZnb250QHNpNm5ldHdvcmtzLmNvbT4gd3JvdGU6DQoNCj5PbiAwMS8w NC8yMDE2IDAyOjA0IFBNLCBFcmljIFZ5bmNrZSAoZXZ5bmNrZSkgd3JvdGU6DQo+PiBCb2IsIHRo YW5rcyBmb3IgdGhlIGV4dGVuZGVkIFdHTEMuDQo+PiANCj4+IEkgZG8gbm90IHNlZSBhIHJlYWwg dmFsdWUgaW4gdGhpcyBwcm9wb3NhbCAoc29ycnkgRmVybmFuZG8gJiBUb3JlKToNCj4+IDEpIHRo ZSBhdHRhY2sgdmVjdG9yIGNhbiBhbHNvIGJlIHVzZWQgd2l0aCBhIHBhY2tldC10b28tYmlnIE1U VT0xNDAwLCBpdA0KPj4gd2lsbCBmb3JjZSByZWFsIGZyYWdtZW50cyB0byBiZSBzZW50LiBTbywg ZGVwcmVjYXRpbmcgYXRvbWljIGZyYWdtZW50DQo+Pmhhcw0KPj4gbGl0dGxlIHZhbHVlIG9yIGFt IEkgbWlzc2luZyBzb21ldGhpbmc/DQo+DQo+VGhpcyBpcyB0aGUgYml0IHlvdSBzZWVtIHRvIGJl IG1pc3Npbmc6IEluIHRoZSBjYXNlIHlvdSBkZXNjcmliZSwgc3VjaA0KPnBhY2tldCB3aWxsIG5v dCB0cmlnZ2VyIGZyYWdtZW50YXRpb24sIGJ1dCByYXRoZXIgYSByZWR1Y3Rpb24gb2YgdGhlDQo+ YXNzdW1lZCBQYXRoLU1UVS4gLS0gaS5lLiwgZXZlbiBpbiB0aGUgY2FzZSBhIGhvc3QgaXMgZW1w bG95aW5nIFBhdGgtTVRVDQo+RGlzY292ZXJ5LCBhbiBJQ01QdjYgUFRCIDwgMTI4MCB3b3VsZCB0 cmlnZ2VyIGZyYWdtZW50YXRpb24uIGkuZS4sIHlvdQ0KPmNvdWxkIHRyaWdnZXIgdGhlIHVzZSBv ZiBmcmFnbWVudGF0aW9uIGZvciB0cmFmZmljIHRoYXQgd291bGQgb3RoZXJ3aXNlDQo+bm90IGVt cGxveSBmcmFnbWVudGF0aW9uLiAoc3RlcCAjMiB3b3VsZCBiZSB0byBwZXJmb3JtIGEgZnJhZy1i YXNlZCBEb1MNCj5hdHRhY2sgLS0gYWx0aG91Z2ggd2l0aCB0aGUgd2lkZXNwcmVhZCBmaWx0ZXJp bmcgb2YgZnJhZ21lbnRzLCBhdCB0aW1lcw0KPmp1c3QgdHJpZ2dlcmluZyBmcmFnbWVudGF0aW9u IHdvdWxkIGRvIHRoZSB0cmljayAoa2VybmVsLm9yZyB3YXMgYW4NCj5leGFtcGxlIG9mIHRoaXMp KS4NCj4NCj4NCj4NCj4+IDIpIHRoZSBjb3JlIGlzc3VlIGlzIHRoYXQgdHJhbnNpdCBwcm92aWRl cnMgZHJvcCAnbm9ybWFsJyBmcmFnbWVudHMgKGFzDQo+PiBvcHBvc2VkIHRvIHRoZSBldmlsIFJG QyA3MTEyKSwgdGhpcyBpcyB0aGUgcmVhbCBwcm9ibGVtIHRoYXQgbmVlZCB0byBiZQ0KPj4gc29s dmVkIGFueXdheSBiZWNhdXNlIG5vcm1hbCBmcmFnbWVudHMgd2lsbCBzdGlsbCBoYXBwZW4NCj4N Cj5Ob3QgcmVhbGx5LiBUaGUgY29yZSBvZiB0aGUgaXNzdWUgaXMgdGhhdCB5b3Ugc2hvdWxkbid0 IGVtcGxveQ0KPmZyYWdtZW50YXRpb24gdW5sZXNzIHlvdSByZWFsbHkgbmVlZCBpdCAoc3RhdGVm dWwgb3BlcmF0aW9uIGZvciBhbg0KPm90aGVyd2lzZSBzdGF0ZWxlc3MgcHJvdG9jb2wsIGV0Yy4s IGV0Yy4pLg0KPg0KPlRoZSB3aWRlc3ByZWFkIGZpbHRlcmluZyBvZiBmcmFnbWVudHMgc2ltcGx5 IG1lYW5zIHRoYXQgaWYgYW4gYXR0YWNrZXINCj5pcyBhYmxlIHRvIHRyaWdnZXIgZnJhZ21lbnRh dGlvbiwgaW4gbWFueSBjYXNlcyBoZSB3aWxsIG5vdCBuZWVkIHRvDQo+cGVyZm9ybSBhbnkgZnJh Zy1iYXNlZCBhdHRhY2ssIGJlY2F1c2UgdGhlIG5ldHdvcmsgd2lsbCwgdW5mb3J0dW5hdGVseSwN Cj5hbHJlYWR5IGZpbHRlciB0aGUgcGFja2V0cy4NCj4NCj5Bbm90aGVyIGNvcmUgaXNzdWUgaXMg dGhhdCBpdCBpcyBhIGJhZCBpZGVhIHRvIGFsbG93IGEgcmFuZG9tIG5vZGUgdG8NCj50cmlnZ2Vy IHRoZSB1c2Ugb2YgZnJhZ21lbnRhdGlvbiBmb3IgdHJhZmZpYyB0aGF0IG90aGVyd2lzZSB3b3Vs ZG4ndA0KPmVtcGxveSBpdCAoZS5nLiwgVENQIGRvaW5nIFBhdGgtTVRVIERpc2NvdmVyeSkuDQo+ DQo+DQo+DQo+PiBTb3JyeSB0byBzdGFydCB0aGUgeWVhciB3aXRoIGEgbmVnYXRpdmUgY29tbWVu dA0KPg0KPkhvcGVmdWxseSB0aGUgYWJvdmUgY2xhcmlmaWVzIHRoZSBiYWNrZ3JvdW5kIDstKQ0K Pg0KPlRoYW5rcyENCj4NCj5CZXN0IHJlZ2FyZHMsDQo+LS0gDQo+RmVybmFuZG8gR29udA0KPlNJ NiBOZXR3b3Jrcw0KPmUtbWFpbDogZmdvbnRAc2k2bmV0d29ya3MuY29tDQo+UEdQIEZpbmdlcnBy aW50OiA2NjY2IDMxQzYgRDQ4NCA2M0IyIDhGQjEgRTNDNCBBRTI1IDBENTUgMUQ0RSA3NDkyDQo+ DQo+DQo+DQo+DQoNCg== From nobody Wed Jan 6 09:52:34 2016 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 664EE1A002C for ; Wed, 6 Jan 2016 09:52:33 -0800 (PST) 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=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nmMG47OGbB_c for ; Wed, 6 Jan 2016 09:52:31 -0800 (PST) Received: from mail-qk0-x231.google.com (mail-qk0-x231.google.com [IPv6:2607:f8b0:400d:c09::231]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 094821A002A for ; Wed, 6 Jan 2016 09:52:31 -0800 (PST) Received: by mail-qk0-x231.google.com with SMTP id q19so99800704qke.3 for ; Wed, 06 Jan 2016 09:52:30 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=subject:mime-version:content-type:from:in-reply-to:date:cc :message-id:references:to; bh=KAzC6TMsnc768i7dmF0fZxGoWmbHbie+m8oUTO/zjRQ=; b=dTGezZEUVZIi28vtO5VG8+YlqVD2onnAw4Q2g8pG3myjb8sb1oCFa+RTBFsQBnKV+K Qz+ChbeDW3VJwcBwZwFtEZ64jqolx2AuvQLDREOnnTLdxhxEPmKawJLGs8XHrjAlrAQR A0px32n2YW2NG4wVeJxkU0DEmHcm+CSKmL29iCdoOZ1PCkgj8PD1srLBE3wnTIaU82iQ YAXjReOP4qMtySvU23zjoHQG1Kxy3aptmHUIQHZ8zvrsPIaMFLGpRhPTSZbZjudC85EY sNjWYfr8buFhj4X2dGUVfScrCN09ByB7ctJa+z2Y5jnPd3py9bJBJgkK9QXL52eAGBT8 KQsw== X-Received: by 10.55.74.197 with SMTP id x188mr132532494qka.104.1452102750223; Wed, 06 Jan 2016 09:52:30 -0800 (PST) Received: from ?IPv6:2601:647:4d00:abf0:9da0:a0b9:5a03:1507? ([2601:647:4d00:abf0:9da0:a0b9:5a03:1507]) by smtp.gmail.com with ESMTPSA id z62sm15993404qka.26.2016.01.06.09.52.28 (version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Wed, 06 Jan 2016 09:52:29 -0800 (PST) Subject: Re: Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2104\)) Content-Type: multipart/signed; boundary="Apple-Mail=_9DA49187-F10E-463F-80F0-C001D6389768"; protocol="application/pgp-signature"; micalg=pgp-sha512 X-Pgp-Agent: GPGMail 2.5.2 From: Bob Hinden In-Reply-To: <568D09E2.6010107@gmail.com> Date: Wed, 6 Jan 2016 09:52:27 -0800 Message-Id: <1A3A7792-52A1-425F-BAB2-69D677959DFC@gmail.com> References: <568BD814.4030100@gmail.com> <568C1432.8040600@gmail.com> <568D09E2.6010107@gmail.com> To: Alexandre Petrescu X-Mailer: Apple Mail (2.2104) Archived-At: Cc: IPv6 List , Bob Hinden X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Jan 2016 17:52:33 -0000 --Apple-Mail=_9DA49187-F10E-463F-80F0-C001D6389768 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Alexandre, > On Jan 6, 2016, at 4:34 AM, Alexandre Petrescu = wrote: >=20 >=20 >=20 > Le 05/01/2016 20:06, Brian E Carpenter a =C3=A9crit : >> On 06/01/2016 03:49, Alexandre Petrescu wrote: >>> I reviewed the changes. They look ok. I found one nit: >>>=20 >>>> For this purpose, the Encapsulating Security Payload (ESP) is not >>>> considered an extension headers. >>> ^ strike s. >>>=20 >>> Additionally, I think rfc2460bis lists all extension headers. >>=20 >> No it doesn't. We have an explicit IANA registry for that, as defined = by RFC 7045: >> = http://www.iana.org/assignments/ipv6-parameters/ipv6-parameters.xhtml#exte= nsion-header >=20 > I can agree one should rather look explicitly at a IANA registry to = find all extensions headers. >=20 > At the same time, it would be expected that EH text in rfc2460 would = apply equally well to each particular EH. >=20 > Especially, what EHs were "currently defined" at the time of 2460 = became more numerous now for new2460. >=20 > For example, the following text: >> 4.2. Options >>=20 >> Two of the currently-defined extension headers -- the Hop-by-Hop >> Options header and the Destination Options header -- carry a = variable >> number of type-length-value (TLV) encoded "options", of the = following >> format: >=20 > should rather say "_Three_ of the currently-defined extension headers = -- the Hop-by-Hop Options header, the Destination Options header and the = Mobility Header -- carry a variable number of TLVs...". >=20 > Or maybe it could say "Some of the EHs (e.g. HbH, DO, MH, other) carry = a variable number of TLVs". >=20 > Otherwise, 2460 reads as _only two_ _currently-defined_ EHs carry = TLVs. Which doesn't read quite right because the new MH (absent when = 2460 was out) carries a variable number of TLVs too. I think it referring to the extension headers defined in this document. = But I agree it could be clearer, and will fix. Thanks, Bob >=20 > For ref the Mobility Header is at: > http://tools.ietf.org/html/rfc6275#section-6.1 >=20 > Yours, >=20 > Alex >=20 >=20 > or >>=20 >> Brian >>=20 >>>=20 >>> If so, I would like to suggest to refer to the Mobility Header = extension header. This extension header is defined in RFC6275 >>> "Mobile IPv6". >>>=20 >>> Is this ok? >>>=20 >>> Alex >>>=20 >>>=20 >>> Le 16/12/2015 08:56, Bob Hinden a =C3=A9crit : >>>> I published the -02 version of 6man working group draft of >>>> rfc2460bis. Links below. >>>>=20 >>>> It has the changes based on the discussion at the 6MAN session at = the >>>> Yokohama IETF. These include >>>>=20 >>>> Added text to Section 4.8 "Defining New Extension Headers and >>>> Options" clarifying why no new hop by hop extension headers should = be >>>> defined. >>>>=20 >>>> Added text to Fragment Header process on handling exact duplicate >>>> fragments. >>>>=20 >>>> A few editorial changes. >>>>=20 >>>> A diff from the -02 version can be found at: >>>>=20 >>>> https://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-6man-rfc2460bis-02 >>>>=20 >>>> Please review the changes. >>>>=20 >>>> Thanks, Bob >>>>=20 >>>>> A New Internet-Draft is available from the on-line Internet-Drafts >>>>> directories. This draft is a work item of the IPv6 Maintenance >>>>> Working Group of the IETF. >>>>>=20 >>>>> Title : Internet Protocol, Version 6 (IPv6) >>>>> Specification Authors : Stephen E. Deering Robert M. >>>>> Hinden Filename : draft-ietf-6man-rfc2460bis-02.txt Pages >>>>> : 37 Date : 2015-12-15 >>>>>=20 >>>>> Abstract: This document specifies version 6 of the Internet >>>>> Protocol (IPv6), also sometimes referred to as IP Next Generation >>>>> or IPng. It obsoletes RFC2460 >>>>>=20 >>>>>=20 >>>>> The IETF datatracker status page for this draft is: >>>>> https://datatracker.ietf.org/doc/draft-ietf-6man-rfc2460bis/ >>>>>=20 >>>>> There's also a htmlized version available at: >>>>> https://tools.ietf.org/html/draft-ietf-6man-rfc2460bis-02 >>>>>=20 >>>>> A diff from the previous version is available at: >>>>> https://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-6man-rfc2460bis-02 >>>>>=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 >>>>>=20 >>>>> = -------------------------------------------------------------------- >>>>>=20 >>>>>=20 >>> IETF IPv6 working group mailing list >>>>> ipv6@ietf.org Administrative Requests: >>>>> https://www.ietf.org/mailman/listinfo/ipv6 >>>>> = -------------------------------------------------------------------- >>>=20 >>> -------------------------------------------------------------------- >>> IETF IPv6 working group mailing list >>> ipv6@ietf.org >>> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 >>> -------------------------------------------------------------------- >>>=20 >>=20 >>=20 >=20 > -------------------------------------------------------------------- > IETF IPv6 working group mailing list > ipv6@ietf.org > Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 > -------------------------------------------------------------------- --Apple-Mail=_9DA49187-F10E-463F-80F0-C001D6389768 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 - https://gpgtools.org iQEcBAEBCgAGBQJWjVRbAAoJEK7rdBF357uooGkH/1zXC/7kdeFQsKKz32jAOLM6 BPx3sFc/zNaAbCpxTqDtai0cBEsyGoM3sbpxWpI0bvMVR0cowXLkj9cIK/s33+aK 58v9/PN21chWfOHjvsknUCGB+x+0ca6cJaM2NwdHOGCXkHDQrp7LRxBiGokMcLWl plRdytJRvmeFYGFX0ZdeCCX51ZVBoU41q3ZjKsAQD84LbJGpvKsTHraGCmoD9Hvo STr47uVmrx8jiXBWEiW8e/gNIFVJGhq26n32VGEIR/1i/VXfeQSVPtM3G5tN1hcC C1cSxuNOFR9GDCA+EPmUjo9tol4wjpjab7+9/jGqVbO9ZQEjaifBHLPnJZ53ugQ= =/JCM -----END PGP SIGNATURE----- --Apple-Mail=_9DA49187-F10E-463F-80F0-C001D6389768-- From nobody Thu Jan 7 05:39:57 2016 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 29BBB1A89B4 for ; Thu, 7 Jan 2016 05:39:56 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.301 X-Spam-Level: X-Spam-Status: No, score=-1.301 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, J_CHICKENPOX_35=0.6, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DELG5hb46ohV for ; Thu, 7 Jan 2016 05:39:54 -0800 (PST) Received: from fgont.go6lab.si (fgont.go6lab.si [91.239.96.14]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 521431A89B1 for ; Thu, 7 Jan 2016 05:39:54 -0800 (PST) Received: from [192.168.0.112] (unknown [190.49.44.171]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by fgont.go6lab.si (Postfix) with ESMTPSA id 549B920687C; Thu, 7 Jan 2016 08:39:42 -0500 (EST) Subject: Re: 6MAN WG Last Call - draft-ietf-6man-deprecate-atomfrag-generation To: "Eric Vyncke (evyncke)" , Bob Hinden , IPv6 List References: <7BEE06A2-0F6E-493F-B2C6-68DAB3774FD5@gmail.com> <568C775C.2030300@si6networks.com> From: Fernando Gont X-Enigmail-Draft-Status: N1110 Message-ID: <568E69AA.2090100@si6networks.com> Date: Thu, 7 Jan 2016 10:35:38 -0300 User-Agent: Mozilla/5.0 (X11; Linux i686; rv:38.0) Gecko/20100101 Thunderbird/38.4.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Archived-At: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Jan 2016 13:39:56 -0000 Hi, Eric, On 01/06/2016 12:47 PM, Eric Vyncke (evyncke) wrote: > Fernand (and Bob), > > First thanks for your replies. > ( > About PTB > 1280: I have to read RFC2460bis, but, the 'old' RFC 2460 > states that when the path MTU for one destination is smaller than the > physical MTU, then either fragmentation (bad) or application (preferred) > must adapt. That can't be possible. If it was, Path-MTU Discovery would be impossible: You *always* send packets smaller than the physical MTU. Then PMTU operates between min(IP_MIN_MTU) and min (Physical_MTU, Path-MTU). (where IP_MIN_MTU is 68 for IPv4 and 1280 for IPv6). When you employ a protocol that can segment data (TCP, SCTP, etc) you never fall back to fragmentation (that's the whole point of doing Path-MTU Discovery). You just keep segmenting the app data at the transport layer at appropriate chunk sizes. In IPv4, you never reduce past 68 bytes. In IPv6, you never reduce past 1280 bytes. However, RFC2460 supported a corner case where if you were to receive an ICMPv6 PTB < 1280, you'd not reduce the size of your data chunk, but just start sending atomic fragments. draft-ietf-6man-deprecate-atomfrag-generation discusses why this is not a good idea. But the short version of the answer is that you don't want to employ fragmentation unless you really have to. Hence, generating atomic fragments doesn't make much sense. > To be honest, I do not have any data backing how > hosts/applications react in that case. If hosts commonly do fragmentation > because app is ignorant of the MTU, then the attack is also possible on > non atomic fragment. When an app employs TCP+PMTUD or the like, they would never employ fragmentation, modulo this corner case. > Then, we agree on the fact that fragmentation should really be discouraged > for security and performance reasons :-) And we are also in 'violent' > agreement on the fact that this is really not secure to allow any node to > reduce the MTU between two other parties... OTOH not an easy problem to > fix. This case is actually quite worse, because you're not simply reducing the MTU between two nodes, but also triggering fragmentation. IN IPv6, since the minimum MTU is quite large (1280 bytes), an attacker that reduces the MTU between two node just causes a performance penalty (kind of small if the real PMTU was e.g. 1500 bytes). BUt an attacker that can trigger the use of fragmentation opens the door to a number of fragmentation-based attacks... and, because of the widespread filtering of IPv6 fragments, at times just triggering fragmentation already results in a DoS scenario. Thanks! Cheers, -- Fernando Gont SI6 Networks e-mail: fgont@si6networks.com PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492 From nobody Sun Jan 10 18:30:17 2016 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A4A041A6F3C for ; Sun, 10 Jan 2016 18:30:16 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.1 X-Spam-Level: X-Spam-Status: No, score=-0.1 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id efSIh3sBOIeD for ; Sun, 10 Jan 2016 18:30:14 -0800 (PST) Received: from mail-io0-x22c.google.com (mail-io0-x22c.google.com [IPv6:2607:f8b0:4001:c06::22c]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 94B6C1A6F39 for ; Sun, 10 Jan 2016 18:30:14 -0800 (PST) Received: by mail-io0-x22c.google.com with SMTP id 1so289069253ion.1 for ; Sun, 10 Jan 2016 18:30:14 -0800 (PST) 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=PniSqEsF1Ug7WNd4JM93aaBGGnCOI4VANJ+HSsjImZw=; b=uBLgzAZr0AqowmdKWlactZYgHPO9HlZFisYVGF5H9aLyUamNUrxm2Jn3gnLcmzUGY2 Esot7incM4fO1TnZtKtPJf2c8xS61AraNvg5mOlAT2m88VmVea+c27sRbECTWMnF8Gxt Sanoby/tHa2sME3zJ8C8eJMgkZ0jHiJ0tmIwCeffx31veXMJ0nfW/tO+hXK0j2Q32wGC JyfSAtvoiNsFk66LfiaziwI0auk4RYzR5AaTjihfep2Nrr7DOACtRFWt6MpB8HMJpC6J XG0lLuQybi1OVX6uWbC8XOajeKBImMnezinWM/yubtrnM99lbJbtPH9Gdwf9ygBmAFn1 9lBg== X-Received: by 10.107.137.72 with SMTP id l69mr80469647iod.36.1452479413924; Sun, 10 Jan 2016 18:30:13 -0800 (PST) MIME-Version: 1.0 Received: by 10.64.142.72 with HTTP; Sun, 10 Jan 2016 18:29:34 -0800 (PST) In-Reply-To: <7BEE06A2-0F6E-493F-B2C6-68DAB3774FD5@gmail.com> References: <7BEE06A2-0F6E-493F-B2C6-68DAB3774FD5@gmail.com> From: Qiong Date: Mon, 11 Jan 2016 10:29:34 +0800 Message-ID: Subject: Re: 6MAN WG Last Call - draft-ietf-6man-deprecate-atomfrag-generation To: Bob Hinden Content-Type: multipart/alternative; boundary=001a113f3acc82bbce052905b70a Archived-At: Cc: IPv6 List X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 11 Jan 2016 02:30:16 -0000 --001a113f3acc82bbce052905b70a Content-Type: text/plain; charset=UTF-8 Dear All, I support publication of this document as an RFC. A few small comments: In abstract you seem to imply that the vulnerability relies partly on "widespread filtering of packets with extension headers". Actually, atomic fragments open the door to all fragmentation-based attacks. Similarly, in Section 1 you wrote "there are scenarios in which the generation of IPv6 atomic fragments can introduce an attack vector that can be exploited for denial of service purposes", but the attack vectors are introduced in all scenarios. Appendix A contains valuable information. IMHO, it should be stressed earlier in the document that many of the most popular implementations do not generate atomic fragments, something like "this document aligns the specifications with practice". On Tue, Dec 15, 2015 at 4:57 PM, Bob Hinden wrote: > This message restarts a two week 6MAN Working Group Last Call on advancing: > > Title : Deprecation of the Generation of IPv6 Atomic Fragments > Authors : Fernando Gont > Will(Shucheng) Liu > Tore Anderson > Filename : draft-ietf-6man-deprecate-atomfrag-generation-04.txt > Pages : 9 > Date : 2015-11-26 > > > https://tools.ietf.org/html/draft-ietf-6man-deprecate-atomfrag-generation-04 > > as an Informational Document. Substantive comments and statements of > support for publishing this document should be directed to the mailing > list. Editorial suggestions can be sent to the authors. This last call > will end on 12 January 2016. This is a four week last call to account for > the holidays in December. > > Best regards, > Ole & Bob > > > > -------------------------------------------------------------------- > IETF IPv6 working group mailing list > ipv6@ietf.org > Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 > -------------------------------------------------------------------- > > -- ============================================== Qiong Sun China Telecom Beijing Research Institude Open source code: lightweight 4over6: *http://sourceforge.net/projects/laft6/ * PCP-natcoord:* http://sourceforge.net/projects/pcpportsetdemo/ * =============================================== --001a113f3acc82bbce052905b70a Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Dear All,

I support publication of this document as an RFC.
=
=C2=A0
A few small comments:
=C2=A0
In abstract you seem= to imply that the vulnerability relies partly on "widespread filterin= g of packets with extension headers". Actually, atomic fragments open = the door to all fragmentation-based attacks.
=C2=A0
Similarly, = in Section 1 you wrote "there are scenarios in which the generation of= IPv6 atomic fragments can introduce an attack vector that can be exploited= for denial of service purposes", but the attack vectors are introduce= d in all scenarios.
=C2=A0
Appendix A contains valuable informa= tion. IMHO, it should be stressed earlier in the document that many of the = most popular implementations do not generate atomic fragments, something li= ke "this document aligns the specifications with practice".
=
=C2=A0

On Tue, Dec 15, 2015 at 4:57 PM, Bob= Hinden <bob.hinden@gmail.com> wrote:
This message restarts a two week 6MAN Working Group Last Call on advancing= :

=C2=A0 =C2=A0Title=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0: Deprecation of= the Generation of IPv6 Atomic Fragments
=C2=A0 =C2=A0Authors=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0: Fernando Gont
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0Will(Shucheng) Liu
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0Tore Anderson
=C2=A0 =C2=A0Filename=C2=A0 =C2=A0 =C2=A0 =C2=A0 : draft-ietf-6man-deprecat= e-atomfrag-generation-04.txt
=C2=A0 =C2=A0Pages=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0: 9
=C2=A0 =C2=A0Date=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 : 2015-11-26

=C2=A0 =C2=A0https://too= ls.ietf.org/html/draft-ietf-6man-deprecate-atomfrag-generation-04

as an Informational Document.=C2=A0 Substantive comments and statements of = support for publishing this document should be directed to the mailing list= .=C2=A0 Editorial suggestions can be sent to the authors.=C2=A0 This last c= all will end on 12 January 2016.=C2=A0 This is a four week last call to acc= ount for the holidays in December.

Best regards,
Ole & Bob



-------------------------------------------------------------------- IETF IPv6 working group mailing list
ipv6@ietf.org
Administrative Requests: https://www.ietf.org/mailman/list= info/ipv6
--------------------------------------------------------------------




--
=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 s= ource code:
lightweight 4over6: http://sourceforge.net/projects/laft6/<= /i>
PCP-natcoord: http://sourceforge.net/projects/pcpportsetdemo/<= /a>
=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

--001a113f3acc82bbce052905b70a-- From nobody Sun Jan 10 19:28:16 2016 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 664221A6FB0 for ; Sun, 10 Jan 2016 19:28:14 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JX21psIz_Acz for ; Sun, 10 Jan 2016 19:28:13 -0800 (PST) Received: from tsinghua.edu.cn (smtp10.tsinghua.edu.cn [166.111.204.39]) by ietfa.amsl.com (Postfix) with ESMTP id 4FE101A6FAC for ; Sun, 10 Jan 2016 19:28:12 -0800 (PST) Received: from [127.0.0.1] (unknown [58.200.129.130]) by app5 (Coremail) with SMTP id DsxvpgC3_g5KIZNWpnEMAA--.24532S3; Mon, 11 Jan 2016 11:28:11 +0800 (CST) Message-ID: <5693214C.60101@cernet.edu.cn> Date: Mon, 11 Jan 2016 11:28:12 +0800 From: Xing Li User-Agent: Thunderbird 2.0.0.24 (Windows/20100228) MIME-Version: 1.0 To: IPv6 List Subject: Re: 6MAN WG Last Call - draft-ietf-6man-deprecate-atomfrag-generation References: <7BEE06A2-0F6E-493F-B2C6-68DAB3774FD5@gmail.com> In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-CM-TRANSID: DsxvpgC3_g5KIZNWpnEMAA--.24532S3 X-Coremail-Antispam: 1UD129KBjDUn29KB7ZKAUJUUUUU529EdanIXcx71UUUUU7v73 VFW2AGmfu7bjvjm3AaLaJ3UjIYCTnIWjDUYxBIdaVFxhVjvjDU0xZFpf9x0UUUUUUUUUjd = X-CM-SenderInfo: p0lqwqxfhu0vvwohv3gofq/ Archived-At: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 11 Jan 2016 03:28:14 -0000 I support publication of this document. xing From nobody Mon Jan 11 06:56:11 2016 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 65C091A01BA for ; Mon, 11 Jan 2016 06:56:09 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UELTWSic3goX for ; Mon, 11 Jan 2016 06:56:07 -0800 (PST) Received: from tsinghua.edu.cn (smtp07.tsinghua.edu.cn [166.111.204.36]) by ietfa.amsl.com (Postfix) with ESMTP id C39A31A0193 for ; Mon, 11 Jan 2016 06:56:06 -0800 (PST) Received: from [59.66.24.14] (unknown [59.66.24.14]) by app4 (Coremail) with SMTP id DcxvpgDnPw+EwpNWfxsOAA--.27844S3; Mon, 11 Jan 2016 22:56:04 +0800 (CST) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 8.1 \(1993\)) Subject: Re: 6MAN WG Last Call - draft-ietf-6man-deprecate-atomfrag-generation From: Congxiao Bao In-Reply-To: Date: Mon, 11 Jan 2016 23:10:48 +0800 Content-Transfer-Encoding: 7bit Message-Id: <71808BE1-D394-4C99-91A3-13A6AB2EC3E6@cernet.edu.cn> References: <7BEE06A2-0F6E-493F-B2C6-68DAB3774FD5@gmail.com> To: bob.hinden@gmail.com, ipv6@ietf.org X-Mailer: Apple Mail (2.1993) X-CM-TRANSID: DcxvpgDnPw+EwpNWfxsOAA--.27844S3 X-Coremail-Antispam: 1UD129KBjDUn29KB7ZKAUJUUUUU529EdanIXcx71UUUUU7v73 VFW2AGmfu7bjvjm3AaLaJ3UjIYCTnIWjp_UUU5W7k0a2IF6F4UM7kC6x804xWl14x267AK xVWUJVW8JwAFc2x0x2IEx4CE42xK8VAvwI8IcIk0rVWrJVCq3wAFIxvE14AKwVWUJVWUGw A2ocxC64kIII0Yj41l84ACjcxK6xIIjxv20xvE14v26r1j6r1xM28EF7xvwVC0I7IYx2IY 6xkF7I0E14v26r1j6r4UM28EF7xvwVC2z280aVAFwI0_Jr0_Gr1l84ACjcxK6I8E87Iv6x kF7I0E14v26r1j6r4UM2AIxVAIcxkEcVAq07x20xvEncxIr21l5I8CrVACY4xI64kE6c02 F40Ex7xfMcIj6xIIjxv20xvE14v26r1j6r18McIj6I8E87Iv67AKxVWUJVW8JwAm72CE4I kC6x0Yz7v_Jr0_Gr1lF7xvr2IYc2Ij64vIr41lF7xvr2IYc2Ij64vIr40E4x8a64kEw24l c2xSY4AK67AK6ry5MxAIw28IcxkI7VAKI48JMI8I3I0E5I8CrVAFwI0_Jr0_Jr4lx2IqxV Cjr7xvwVAFwI0_JrI_JrWlx4CE17CEb7AF67AKxVWUXVWUAwCIc40Y0x0EwIxGrwCI42IY 6xIIjxv20xvE14v26r1j6r1xMIIF0xvE2Ix0cI8IcVCY1x0267AKxVWUJVW8JwCI42IY6x AIw20EY4v20xvaj40_WFyUJVCq3wCI42IY6I8E87Iv67AKxVWUJVW8JwCI42IY6I8E87Iv 6xkF7I0E14v26r1j6r4UYxBIdaVFxhVjvjDU0xZFpf9x0UUjRcUUUUUU= X-CM-SenderInfo: pfrqw5xldrquphuqv3oohg3hdfq/ Archived-At: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 11 Jan 2016 14:56:09 -0000 I support the publication of this document. Congxiao Bao From nobody Mon Jan 11 23:27:12 2016 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1E7821A0273 for ; Mon, 11 Jan 2016 23:27:11 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.399 X-Spam-Level: X-Spam-Status: No, score=-1.399 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, J_CHICKENPOX_35=0.6, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id b9g4mOC85CEh for ; Mon, 11 Jan 2016 23:27:09 -0800 (PST) Received: from mail-qk0-x233.google.com (mail-qk0-x233.google.com [IPv6:2607:f8b0:400d:c09::233]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 045211A020D for ; Mon, 11 Jan 2016 23:27:09 -0800 (PST) Received: by mail-qk0-x233.google.com with SMTP id n135so240376785qka.2 for ; Mon, 11 Jan 2016 23:27:08 -0800 (PST) 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=T8KLjx9zPnsHriHMXDjJMOJgxcftEGGOfPmwFhxXGgQ=; b=ceW/RM3GwIMU4CQu1tHIrvspbFOH1SGIMODc0cf/3H+sWRTaY5G0O6q+AKCxZZJQl8 6PQL7GtteBIQwk3AFb8lZ4ZvjUgLvasN7eukcD/2ns1xYh9PtonGulXzT3sS09Gm4FB2 z0KrVKegF5gtYYBb5/Id9qsd3oVRCKFrDcMpDOFybOsEhddpE12SqXbq8wlTYbi4JMup +PwmRslvGPENYAbPhtUAAPdCSlunOJlpzACSlvoV/9m/YSQyvCNO3sQ1UrImmRLy8fOW +FnNBY5jY8L/CrxXZVfNhu9INNO/63zkCh27C1aQx3ZB69qp/nYiM3NRIioJSrmEPp6T mrYw== MIME-Version: 1.0 X-Received: by 10.13.219.6 with SMTP id d6mr112091476ywe.228.1452583628215; Mon, 11 Jan 2016 23:27:08 -0800 (PST) Received: by 10.129.39.131 with HTTP; Mon, 11 Jan 2016 23:27:08 -0800 (PST) In-Reply-To: <568E69AA.2090100@si6networks.com> References: <7BEE06A2-0F6E-493F-B2C6-68DAB3774FD5@gmail.com> <568C775C.2030300@si6networks.com> <568E69AA.2090100@si6networks.com> Date: Tue, 12 Jan 2016 15:27:08 +0800 Message-ID: Subject: Re: 6MAN WG Last Call - draft-ietf-6man-deprecate-atomfrag-generation From: Tina Tsou To: Fernando Gont Content-Type: multipart/alternative; boundary=001a114fac282a9dd605291dfbfc Archived-At: Cc: IPv6 List , Bob Hinden X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 Jan 2016 07:27:11 -0000 --001a114fac282a9dd605291dfbfc Content-Type: text/plain; charset=UTF-8 Dear all, I support publication of this document. Suggestion: Please note earlier in this document that many popular OS do not support the functionality being deprecated. That is, the aforementioned functionality was never widely supported. Thank you, Tina On Thursday, January 7, 2016, Fernando Gont wrote: > Hi, Eric, > > On 01/06/2016 12:47 PM, Eric Vyncke (evyncke) wrote: > > Fernand (and Bob), > > > > First thanks for your replies. > > ( > > About PTB > 1280: I have to read RFC2460bis, but, the 'old' RFC 2460 > > states that when the path MTU for one destination is smaller than the > > physical MTU, then either fragmentation (bad) or application (preferred) > > must adapt. > > That can't be possible. If it was, Path-MTU Discovery would be impossible: > > You *always* send packets smaller than the physical MTU. Then PMTU > operates between min(IP_MIN_MTU) and min (Physical_MTU, Path-MTU). > (where IP_MIN_MTU is 68 for IPv4 and 1280 for IPv6). > > When you employ a protocol that can segment data (TCP, SCTP, etc) you > never fall back to fragmentation (that's the whole point of doing > Path-MTU Discovery). You just keep segmenting the app data at the > transport layer at appropriate chunk sizes. > > In IPv4, you never reduce past 68 bytes. In IPv6, you never reduce past > 1280 bytes. However, RFC2460 supported a corner case where if you were > to receive an ICMPv6 PTB < 1280, you'd not reduce the size of your data > chunk, but just start sending atomic fragments. > > draft-ietf-6man-deprecate-atomfrag-generation discusses why this is not > a good idea. But the short version of the answer is that you don't want > to employ fragmentation unless you really have to. Hence, generating > atomic fragments doesn't make much sense. > > > > To be honest, I do not have any data backing how > > hosts/applications react in that case. If hosts commonly do fragmentation > > because app is ignorant of the MTU, then the attack is also possible on > > non atomic fragment. > > When an app employs TCP+PMTUD or the like, they would never employ > fragmentation, modulo this corner case. > > > > > Then, we agree on the fact that fragmentation should really be > discouraged > > for security and performance reasons :-) And we are also in 'violent' > > agreement on the fact that this is really not secure to allow any node to > > reduce the MTU between two other parties... OTOH not an easy problem to > > fix. > > This case is actually quite worse, because you're not simply reducing > the MTU between two nodes, but also triggering fragmentation. IN IPv6, > since the minimum MTU is quite large (1280 bytes), an attacker that > reduces the MTU between two node just causes a performance penalty (kind > of small if the real PMTU was e.g. 1500 bytes). BUt an attacker that can > trigger the use of fragmentation opens the door to a number of > fragmentation-based attacks... and, because of the widespread filtering > of IPv6 fragments, at times just triggering fragmentation already > results in a DoS scenario. > > Thanks! > > Cheers, > -- > Fernando Gont > SI6 Networks > e-mail: fgont@si6networks.com > PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492 > > > > > -------------------------------------------------------------------- > IETF IPv6 working group mailing list > ipv6@ietf.org > Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 > -------------------------------------------------------------------- > --001a114fac282a9dd605291dfbfc Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Dear a= ll,

I support publication of this documen= t.

Suggestion: Please note earlier in this document that many popula= r OS do=C2=A0not support the functionality being deprecated. That is, the= =C2=A0aforementioned functionality was never widely supported.


=
Thank you,
= Tina

On Thursday, January 7, 2016, Fern= ando Gont <fgont@si6networks.co= m> wrote:
Hi, Eric,

On 01/06/2016 12:47 PM, Eric Vyncke (evyncke) wrote:
> Fernand (and Bob),
>
> First thanks for your replies.
>=C2=A0 (
> About PTB > 1280: I have to read RFC2460bis, but, the 'old'= RFC 2460
> states that when the path MTU for one destination is smaller than the<= br> > physical MTU, then either fragmentation (bad) or application (preferre= d)
> must adapt.

That can't be possible.=C2=A0 If it was, Path-MTU Discovery would be im= possible:

You *always* send packets smaller than the physical MTU. Then PMTU
operates between min(IP_MIN_MTU) and min (Physical_MTU, Path-MTU).
(where IP_MIN_MTU is 68 for IPv4 and 1280 for IPv6).

When you employ a protocol that can segment data (TCP, SCTP, etc) you
never fall back to fragmentation (that's the whole point of doing
Path-MTU Discovery). You just keep segmenting the app data at the
transport layer at appropriate chunk sizes.

In IPv4, you never reduce past 68 bytes. In IPv6, you never reduce past
1280 bytes. However, RFC2460 supported a corner case where if you were
to receive an ICMPv6 PTB < 1280, you'd not reduce the size of your d= ata
chunk, but just start sending atomic fragments.

draft-ietf-6man-deprecate-atomfrag-generation discusses why this is not
a good idea. But the short version of the answer is that you don't want=
to employ fragmentation unless you really have to. Hence, generating
atomic fragments doesn't make much sense.


> To be honest, I do not have any data backing how
> hosts/applications react in that case. If hosts commonly do fragmentat= ion
> because app is ignorant of the MTU, then the attack is also possible o= n
> non atomic fragment.

When an app employs TCP+PMTUD or the like, they would never employ
fragmentation, modulo this corner case.



> Then, we agree on the fact that fragmentation should really be discour= aged
> for security and performance reasons :-) And we are also in 'viole= nt'
> agreement on the fact that this is really not secure to allow any node= to
> reduce the MTU between two other parties... OTOH not an easy problem t= o
> fix.

This case is actually quite worse, because you're not simply reducing the MTU between two nodes, but also triggering fragmentation. IN IPv6,
since the minimum MTU is quite large (1280 bytes), an attacker that
reduces the MTU between two node just causes a performance penalty (kind of small if the real PMTU was e.g. 1500 bytes). BUt an attacker that can trigger the use of fragmentation opens the door to a number of
fragmentation-based attacks... and, because of the widespread filtering
of IPv6 fragments, at times just triggering fragmentation already
results in a DoS scenario.

Thanks!

Cheers,
--
Fernando Gont
SI6 Networks
e-mail: fgont@si6networks.com
PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492




--------------------------------------------------------------------
IETF IPv6 working group mailing list
ipv6@ietf.org
Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------
--001a114fac282a9dd605291dfbfc-- From nobody Tue Jan 12 09:29:08 2016 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6839A1A00F0 for ; Tue, 12 Jan 2016 09:29:07 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.4 X-Spam-Level: X-Spam-Status: No, score=-1.4 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, J_CHICKENPOX_35=0.6, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DNMOP9BsIbTK for ; Tue, 12 Jan 2016 09:29:05 -0800 (PST) Received: from mail-yk0-x22a.google.com (mail-yk0-x22a.google.com [IPv6:2607:f8b0:4002:c07::22a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9049D1A00F6 for ; Tue, 12 Jan 2016 09:29:05 -0800 (PST) Received: by mail-yk0-x22a.google.com with SMTP id x67so460041757ykd.2 for ; Tue, 12 Jan 2016 09:29:05 -0800 (PST) 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=aP1a/JCBueGACpbJ3imvjfLhxszlfI9UEKb0WiuGhLU=; b=y7AJDOqmBgMGjyppRIWBSXm/tr3hpdVZZMU6Az0rDWA1veIu9ShmeNP0XW7m2+CQn9 nPXPV3+G1v4I/Z76CX6vJl+sEl9CQpUy06T0flH05oWOHK3P3ua58FrGV4pdkfVHN1Xy vWxt6vvEVREDdyYxEemfAh9FVDkx4fiy6wGkWzilPuxMdgxj1xTNkIORJ96rP8nrREXs p6+5+obalZnWVe7Pg6PP0PLGwyh1oQw/SCHN286h3l6CNOz04ogiojkWl6BrCRLPUwP5 KBJ4/yyJb6QnqF2uDutSWdKTEF9Zt8xO/aac733eoLL2ta/q9PZ8P8UW7N7E+qkzNMjo fXbw== MIME-Version: 1.0 X-Received: by 10.129.94.70 with SMTP id s67mr95152768ywb.145.1452619744931; Tue, 12 Jan 2016 09:29:04 -0800 (PST) Received: by 10.129.12.215 with HTTP; Tue, 12 Jan 2016 09:29:04 -0800 (PST) In-Reply-To: References: <7BEE06A2-0F6E-493F-B2C6-68DAB3774FD5@gmail.com> <568C775C.2030300@si6networks.com> <568E69AA.2090100@si6networks.com> Date: Tue, 12 Jan 2016 11:29:04 -0600 Message-ID: Subject: Re: 6MAN WG Last Call - draft-ietf-6man-deprecate-atomfrag-generation From: Alberto Leiva To: Tina Tsou Content-Type: text/plain; charset=UTF-8 Archived-At: Cc: Fernando Gont , IPv6 List , Bob Hinden X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 Jan 2016 17:29:07 -0000 Looks like I'm doing this disturbingly late. I'm an idiot; sorry. Fernando asked for a summary paragraph of the atomic fragment + Linux API issue. I understand if you guys don't want it; I think it's not that meaningful as an argument compared to the other stuff already included, and I wish I weren't potentially stalling publication of the draft. But FWIW, here it is. (I would sandwich it between the two "Finally, " blocks in section 4 since the relationship between DF and Fragment Header has already been explained by then): There are also drawbacks to the atomic fragment approach implementation-wise: Even when the IPv6 endpoint answers atomic fragments correctly, packet-handling API might tend to obscure fragmentation-related information for simplifying purposes. If a translator does not have reliable access to the fragment header, it cannot safely derive the corresponding desired DF value. Assuming fragment assembly is active in the forwarding pipeline (for firewalling or other potential reasons), Netfilter (starting from Linux version 3.13) is an example of a framework that hinders access to the information RFC 6145 uses to infer Path MTU information. More reading: https://github.com/NICMx/Jool/wiki/nf_defrag_ipv4-and-nf_defrag_ipv6#implementation-gotchas That analysis is from more than a year ago; it doesn't cover newer kernels. If you want to include this, then maybe I should check whether this quirk is also present in really new kernels. ----------------------- Also Nitpick: There are two paragraphs in section 4 that start with "Finally, ". Isn't that misleading? ----------------------- I support this document with a passion. Alberto On Tue, Jan 12, 2016 at 1:27 AM, Tina Tsou wrote: > Dear all, > > I support publication of this document. > > Suggestion: Please note earlier in this document that many popular OS do not > support the functionality being deprecated. That is, the aforementioned > functionality was never widely supported. > > > Thank you, > Tina > > On Thursday, January 7, 2016, Fernando Gont wrote: >> >> Hi, Eric, >> >> On 01/06/2016 12:47 PM, Eric Vyncke (evyncke) wrote: >> > Fernand (and Bob), >> > >> > First thanks for your replies. >> > ( >> > About PTB > 1280: I have to read RFC2460bis, but, the 'old' RFC 2460 >> > states that when the path MTU for one destination is smaller than the >> > physical MTU, then either fragmentation (bad) or application (preferred) >> > must adapt. >> >> That can't be possible. If it was, Path-MTU Discovery would be >> impossible: >> >> You *always* send packets smaller than the physical MTU. Then PMTU >> operates between min(IP_MIN_MTU) and min (Physical_MTU, Path-MTU). >> (where IP_MIN_MTU is 68 for IPv4 and 1280 for IPv6). >> >> When you employ a protocol that can segment data (TCP, SCTP, etc) you >> never fall back to fragmentation (that's the whole point of doing >> Path-MTU Discovery). You just keep segmenting the app data at the >> transport layer at appropriate chunk sizes. >> >> In IPv4, you never reduce past 68 bytes. In IPv6, you never reduce past >> 1280 bytes. However, RFC2460 supported a corner case where if you were >> to receive an ICMPv6 PTB < 1280, you'd not reduce the size of your data >> chunk, but just start sending atomic fragments. >> >> draft-ietf-6man-deprecate-atomfrag-generation discusses why this is not >> a good idea. But the short version of the answer is that you don't want >> to employ fragmentation unless you really have to. Hence, generating >> atomic fragments doesn't make much sense. >> >> >> > To be honest, I do not have any data backing how >> > hosts/applications react in that case. If hosts commonly do >> > fragmentation >> > because app is ignorant of the MTU, then the attack is also possible on >> > non atomic fragment. >> >> When an app employs TCP+PMTUD or the like, they would never employ >> fragmentation, modulo this corner case. >> >> >> >> > Then, we agree on the fact that fragmentation should really be >> > discouraged >> > for security and performance reasons :-) And we are also in 'violent' >> > agreement on the fact that this is really not secure to allow any node >> > to >> > reduce the MTU between two other parties... OTOH not an easy problem to >> > fix. >> >> This case is actually quite worse, because you're not simply reducing >> the MTU between two nodes, but also triggering fragmentation. IN IPv6, >> since the minimum MTU is quite large (1280 bytes), an attacker that >> reduces the MTU between two node just causes a performance penalty (kind >> of small if the real PMTU was e.g. 1500 bytes). BUt an attacker that can >> trigger the use of fragmentation opens the door to a number of >> fragmentation-based attacks... and, because of the widespread filtering >> of IPv6 fragments, at times just triggering fragmentation already >> results in a DoS scenario. >> >> Thanks! >> >> Cheers, >> -- >> Fernando Gont >> SI6 Networks >> e-mail: fgont@si6networks.com >> PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492 >> >> >> >> >> -------------------------------------------------------------------- >> IETF IPv6 working group mailing list >> ipv6@ietf.org >> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 >> -------------------------------------------------------------------- > > > -------------------------------------------------------------------- > IETF IPv6 working group mailing list > ipv6@ietf.org > Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 > -------------------------------------------------------------------- > From nobody Tue Jan 12 10:43:53 2016 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 11BA31A1BA9 for ; Tue, 12 Jan 2016 10:43:49 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.978 X-Spam-Level: X-Spam-Status: No, score=-0.978 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FM_FORGED_GMAIL=0.622, FREEMAIL_FROM=0.001, MIME_8BIT_HEADER=0.3, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Vc_hzEBpTd4P for ; Tue, 12 Jan 2016 10:43:47 -0800 (PST) Received: from mail-io0-x230.google.com (mail-io0-x230.google.com [IPv6:2607:f8b0:4001:c06::230]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 609CC1A1B91 for ; Tue, 12 Jan 2016 10:43:47 -0800 (PST) Received: by mail-io0-x230.google.com with SMTP id 77so362068845ioc.2 for ; Tue, 12 Jan 2016 10:43:47 -0800 (PST) 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=JUREnjBwA9teov0wmFAuF1adDEBMc6eO1TfWZRUvuw4=; b=bvG9TDNCiwa7Djflb8EN5sVCIecHLncJ52aKZzMXPZlOl8+4SbV1qqeue5c/gVp02L zurowhZd2bbJe7qcAOozOly3heejqSZj4nwEKzedYljc9KNmvJAD7ElmqF0GMeoHZYNA Tas/qEaF1hJz/6QCduIj1ngm57d8ELGxOyxF/+QT8FBbBkZr+RH7v0YT/NBA/QWhcGI3 b/zGVcQB2MmucdPQjr5/h55hw4UDX5hNx+/OMBvdfXpGwlB1DCK0aNFD7Qsymosiaver KWp3CLQNH71j5Y2FMU3NPuv4cbnYKFHydfFDhTKb98bRTC+Mh2PTsAlX3+iJeVoUE1u0 VVaA== MIME-Version: 1.0 X-Received: by 10.107.137.151 with SMTP id t23mr98077832ioi.172.1452624226794; Tue, 12 Jan 2016 10:43:46 -0800 (PST) Sender: jinmei.tatuya@gmail.com Received: by 10.107.129.80 with HTTP; Tue, 12 Jan 2016 10:43:46 -0800 (PST) In-Reply-To: <7BEE06A2-0F6E-493F-B2C6-68DAB3774FD5@gmail.com> References: <7BEE06A2-0F6E-493F-B2C6-68DAB3774FD5@gmail.com> Date: Tue, 12 Jan 2016 10:43:46 -0800 X-Google-Sender-Auth: RQNaB3TtmHhSSBJvn2IAkSqGrJ4 Message-ID: Subject: Re: 6MAN WG Last Call - draft-ietf-6man-deprecate-atomfrag-generation From: =?UTF-8?B?56We5piO6YGU5ZOJ?= To: Bob Hinden Content-Type: text/plain; charset=UTF-8 Archived-At: Cc: IPv6 List X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 Jan 2016 18:43:49 -0000 On Tue, Dec 15, 2015 at 12:57 AM, Bob Hinden wrote: > This message restarts a two week 6MAN Working Group Last Call on advancing: > > Title : Deprecation of the Generation of IPv6 Atomic Fragments > Authors : Fernando Gont > Will(Shucheng) Liu > Tore Anderson > Filename : draft-ietf-6man-deprecate-atomfrag-generation-04.txt > Pages : 9 > Date : 2015-11-26 > > https://tools.ietf.org/html/draft-ietf-6man-deprecate-atomfrag-generation-04 > > as an Informational Document. Substantive comments and statements > of support for publishing this document should be directed to the > mailing list. Editorial suggestions can be sent to the authors. I wouldn't be opposed to publishing this document. I have a few comments on the 04 version however, which may better be addressed before the publication: - The title seems to be misleading to me. On starting to re-read the latest version almost forgetting past discussions, I first wondered why this is supposed to be "Informational" if it "deprecates" a standard feature. I then found it actually does not insist on deprecating it by updating RFC2460, merely saying the authors the believed atomic fragment is a bad idea. The title confused me, and I guess it will confuse other future readers. So I suggest renaming it something like "Issues with the Generation of IPv6 Atomic Fragments" or if some stronger word is preferred, "The Generation of IPv6 Atomic Fragments is Considered Harmful". - This arguments in Section 4 seem to be a bit weak to me: o There exists a fair share of evidence of ICMPv6 Packet Too Big messages being dropped on the public Internet (for instance, that is one of the reasons for which PLPMTUD [RFC4821] was produced). [...] This being the case, using atomic fragments for attacks would also be less appealing, so we might argue we don't have to worry about it too much. A possible counter argument to this might be that we don't want to allow any possibility of attacks while for legitimate cases we rather want it to always work. I might buy it, but the seemingly arbitrary use of a particular point for the suggested conclusion rather makes the whole tone of the document look unfair IMO. It may be only me, in which case I won't argue this should be necessarily addressed, but if some others have the same impression providing more neutral and/or discussion might help. - Appendix A: it's a bit surprising to me that some BSD variants are listed here: o FreeBSD 8.0 o NetBSD 5.1 The generation of atomic fragments was supported in quite an early version of the KAME IPv6 stack, from which many of BSD variants were derived. One repository log suggests it had been supported since around 2002: https://github.com/kame/kame/commit/eaaefeddf7c2878fe03f649b2da4d8535427aeb0 And, while I don't have an environment to readily check the actual behavior right now, the latest version of both FreeBSD and NetBSD still seems to have essentially the same code. In fact, according to RFC6946 later versions of FreeBSD can generate atomic fragments: +---------------------+---------------------+-----------------------+ | Operating System | Generates atomic | Implements this | | | fragments | specification | +---------------------+---------------------+-----------------------+ | FreeBSD 8.0 | No | No | +---------------------+---------------------+-----------------------+ | FreeBSD 8.2 | Yes | No | +---------------------+---------------------+-----------------------+ | FreeBSD 9.0 | Yes | No | +---------------------+---------------------+-----------------------+ So the result for 8.0 rather seems to be an intermittent regression. Like the previous point, I would find it unfair to only refer to an exceptional case that would support the conclusion of the authors. Perhaps (hopefully) that was not the intent of the authors, but if it's written more carefully so it won't look like picking specific evidences for a particular conclusion, I would accept it more comfortably. -- JINMEI, Tatuya From nobody Wed Jan 13 13:01:28 2016 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5C15D1A00F5 for ; Wed, 13 Jan 2016 13:01:26 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.002 X-Spam-Level: X-Spam-Status: No, score=-2.002 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id g_dYsOGJccRt for ; Wed, 13 Jan 2016 13:01:25 -0800 (PST) Received: from cowbell.employees.org (cowbell.employees.org [65.50.211.142]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 28EDF1A00F3 for ; Wed, 13 Jan 2016 13:01:25 -0800 (PST) Received: from cowbell.employees.org (localhost [127.0.0.1]) by cowbell.employees.org (Postfix) with ESMTP id 2AE2FD78A2 for ; Wed, 13 Jan 2016 13:01:24 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=employees.org; h=from :content-type:subject:date:message-id:to:mime-version; s= selector1; bh=EercClmtRT3/6bxMYQz7l9CAyvI=; b=nRYUQle1BQ4JuRXaLv 4dOGqdFaf0Q8pqCQuhhS74lzirgPY47/WdXF+ygT3x2kZNNfF9gP0oa/DwZ0jhGr tA0lYe3V1Ru3ZICvdt5JI3N7lUI7ORktWaPr6xgcNzMoq/vLMQxvNzvxdQgJv7rl qx9UhcXP95kns+JGVarjM0W7U= DomainKey-Signature: a=rsa-sha1; c=nofws; d=employees.org; h=from :content-type:subject:date:message-id:to:mime-version; q=dns; s= selector1; b=EUpnKMpMPNWVubx66FLkKhZ5hxrAvUC9aDRNc9rchwMuhZ99nn5 adyO/LyfGZOjo292/kWiHjdvNQWstY0AbzS4kTaGbV0WjGahEsujAtlgKokGUcj7 Fc4G5CIJJSGE6Mh6DR9FFucCxl2guQzD1rlkbcFMTZUtnlHcoRJTz654= Received: from h.hanazo.no (cm-84.215.10.233.getinternet.no [84.215.10.233]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: otroan) by cowbell.employees.org (Postfix) with ESMTPSA id E320BD78A5 for ; Wed, 13 Jan 2016 13:01:23 -0800 (PST) Received: from [IPv6:::1] (localhost [IPv6:::1]) by h.hanazo.no (Postfix) with ESMTP id 026F3E0F90A for ; Wed, 13 Jan 2016 22:01:20 +0100 (CET) From: otroan@employees.org X-Pgp-Agent: GPGMail 2.6b2 Content-Type: multipart/signed; boundary="Apple-Mail=_0481B916-6421-4DFD-98C7-78E862E5A745"; protocol="application/pgp-signature"; micalg=pgp-sha512 Subject: RFC2460bis hop limit text Date: Wed, 13 Jan 2016 22:01:19 +0100 Message-Id: <1DA06950-D86A-466A-829C-4B3869C4D65A@employees.org> To: 6man WG Mime-Version: 1.0 (Mac OS X Mail 9.2 \(3112\)) X-Mailer: Apple Mail (2.3112) Archived-At: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 Jan 2016 21:01:26 -0000 --Apple-Mail=_0481B916-6421-4DFD-98C7-78E862E5A745 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii After discussing a related issue with a forwarding implementation I'm = working on, I think 2460bis hop limit text has an issue: Hop Limit 8-bit unsigned integer. Decremented by 1 by each node that forwards the packet. The packet is discarded if Hop Limit is decremented to zero, or is received with a zero Hop Limit. According to RFC1812 receiving a packet with TTL =3D 0 is perfectly = fine. I suggest we instead say something like: Hop Limit 8-bit unsigned integer. Decremented by 1 by each node that forwards the packet. The packet is discarded if Hop Limit is already zero or decremented to zero. In addition add the note: (almost verbatim from 1812) Note: A node must not discard a datagram just because it was received with hop limit equal to zero or one; if it is to the node and = otherwise valid, the node must attempt to receive it. Ole --Apple-Mail=_0481B916-6421-4DFD-98C7-78E862E5A745 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 - https://gpgtools.org iQIcBAEBCgAGBQJWlrsgAAoJEL7aWKiYQt92JRwQAM7VYXqcN6SyESzYvFsTCwpb seuEM7GLyD6r6JkvaCClRzyl2WQxhedyzo/mZPwiYhWJnWC0niAlX8VWdoUUIujE JkmOsBwzYWN9uoEVF4xJw0WYs2VmEOzWUWAzGSzP3D2DS1ZBKUzY8RIm/Z9FIJoV KcE9ARWXlDpp44+1XWfe9x5EMn/U1W/ZdWX8IzECqNT74uV10sJ8Oi9JsL93hjg8 rcJ8LQE2mRrvioEArSuw2rWpjziwmRWFkf6fATOiv+JDXc0cIhgbk6+JiA9jARjl R95w+M5Yu0cXnZ2zhvV1aTi8XVKjdmqWhR+hTAuNLHhCRyuZqTt+KD3uA+9AAiPJ KRLtUhM9QF14E2mWxhEEPWqxQfxM7s0HSYjHYmKZpt11PDi7+SjCFY1YN+IIttZ4 eAW0ToKuzZ/x1QNdOhDp2pihw6DuP5viX5vL4gQNS57mgCPOQn231Bwu3tLgpRmY IAkyqhb+7bawoj0P5N74S34K5Ni+aEd0C1W9wqbzWB4JPJXIBX1chu374xgTWpf1 rO2ovH0zTPv0m27VHTJQRUX0PC30Cb3mA/VCkexuNC8MasL2S/lR1HUGjb5zzqGG tfJkEmvhphl9OupD9/iaWXXn4bM61oGh9QXhGozFOEsZCOJ1D3fOwOty4jqQhL1n VG8Md4qrdd2e3mRHAnI7 =Xy0V -----END PGP SIGNATURE----- --Apple-Mail=_0481B916-6421-4DFD-98C7-78E862E5A745-- From nobody Wed Jan 13 13:25:29 2016 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4C15C1A0191 for ; Wed, 13 Jan 2016 13:25:28 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.7 X-Spam-Level: X-Spam-Status: No, score=-1.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, MIME_8BIT_HEADER=0.3, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Rh1pbsFEOpVt for ; Wed, 13 Jan 2016 13:25:27 -0800 (PST) Received: from mail-io0-x22e.google.com (mail-io0-x22e.google.com [IPv6:2607:f8b0:4001:c06::22e]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1FFFF1A0151 for ; Wed, 13 Jan 2016 13:25:27 -0800 (PST) Received: by mail-io0-x22e.google.com with SMTP id 1so385532351ion.1 for ; Wed, 13 Jan 2016 13:25:27 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=subject:mime-version:content-type:from:in-reply-to:date:cc :message-id:references:to; bh=PbMAx9vtdz5I0qNUg2hxLnQjCX/4dD+5buJly7q3/Vk=; b=094NoHppToEqyhQeFx0Mhe+WV8pDwor+3uUBy7+3QHOqlNpRg7awXhslsdlyzq+kp7 VqJjTXPDO7QaJH5y8to8yXqOH4YZUvSZAGR6JuhIMVxpPGNS5HufSVNEyvJz7m5qLLuJ H/l9+VwdQme2bHbWZ6X208zleBNnHMUjQjoXHUfrA1haDoZYGPSu6mVPQJqst1YGJuSk 152GBOTTmZSjMNlDRwzkwuxX7BRzsTNPNYaRJJe5Y3WnK9e9y26iN+WKloS2o6TYC74l l12tHezPWBL7/3v5ix4Qpyt76oqzVxCB2RroBC0npZgVMXgrlYhAsarqn0GQR8pdY1op G53A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:subject:mime-version:content-type:from :in-reply-to:date:cc:message-id:references:to; bh=PbMAx9vtdz5I0qNUg2hxLnQjCX/4dD+5buJly7q3/Vk=; b=JQiXkIgn2JqIywatUFWFBJN5huJvWnDx9DPBNzuaPOGQ/AHj+axbMWK0+T79UTbm6E 39K6Snoxy0z9bVRPM7lbXeUTARyurvvrx6BJjyiy/V8bkothXiE56kCibqom7R+aUlej vkAj3Vsc8sWzH5VMOZXHaPneAvVarXwDSAHVkYS/L8BYxY8AX4ARcGgY6bJy4Z4/XHNv m6LNnTvVXNsh1q2K3l/ELMNUsCgfwTgH3o/c3U7TWrBgCvjPbVFo8HZsz02qMvlU0uYm +fn6l3rr6chbvIOq4AQVe1L6VwcGYwyGfJxUMDeT/3x+TsVKXUBtDOOWExva6YpRSaKg UzGg== X-Gm-Message-State: ALoCoQmbclye4ZNUK3UL7rXTct4FFUZAroAZj+LBtcVfQdA6Kd8ZvY8YRNGExg3ZICB4zJ/6mh9xu86RBHcD2I21Wmba4MNWdQ== X-Received: by 10.107.166.85 with SMTP id p82mr1150075ioe.146.1452720326569; Wed, 13 Jan 2016 13:25:26 -0800 (PST) Received: from [172.16.224.219] ([209.97.127.34]) by smtp.gmail.com with ESMTPSA id q5sm1551757igh.6.2016.01.13.13.25.24 (version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Wed, 13 Jan 2016 13:25:25 -0800 (PST) Subject: Re: RFC2460bis hop limit text Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2104\)) Content-Type: multipart/signed; boundary="Apple-Mail=_9F67847F-EAFB-4F43-BD6E-EC7393CF04F9"; protocol="application/pgp-signature"; micalg=pgp-sha512 X-Pgp-Agent: GPGMail 2.5.2 From: Bob Hinden In-Reply-To: <1DA06950-D86A-466A-829C-4B3869C4D65A@employees.org> Date: Wed, 13 Jan 2016 13:25:24 -0800 Message-Id: References: <1DA06950-D86A-466A-829C-4B3869C4D65A@employees.org> To: =?utf-8?Q?Ole_Tr=C3=B8an?= X-Mailer: Apple Mail (2.2104) Archived-At: Cc: IPv6 List , Bob Hinden X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 Jan 2016 21:25:28 -0000 --Apple-Mail=_9F67847F-EAFB-4F43-BD6E-EC7393CF04F9 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Ole, > On Jan 13, 2016, at 1:01 PM, otroan@employees.org wrote: >=20 > After discussing a related issue with a forwarding implementation I'm = working on, I think 2460bis hop limit text has an issue: >=20 > Hop Limit 8-bit unsigned integer. Decremented by 1 by > each node that forwards the packet. The > packet is discarded if Hop Limit is > decremented to zero, or is received with a > zero Hop Limit. >=20 > According to RFC1812 receiving a packet with TTL =3D 0 is perfectly = fine. I agree, the text could be clearer. >=20 > I suggest we instead say something like: >=20 > Hop Limit 8-bit unsigned integer. Decremented by 1 by > each node that forwards the packet. The > packet is discarded if Hop Limit is > already zero or decremented to zero. >=20 > In addition add the note: (almost verbatim from 1812) > Note: A node must not discard a datagram just because it was received > with hop limit equal to zero or one; if it is to the node and = otherwise > valid, the node must attempt to receive it. This text is fine for me. I will incorporate it in the next draft if = there isn=E2=80=99t any push back on the list. Thanks, Bob >=20 > Ole >=20 > -------------------------------------------------------------------- > IETF IPv6 working group mailing list > ipv6@ietf.org > Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 > -------------------------------------------------------------------- --Apple-Mail=_9F67847F-EAFB-4F43-BD6E-EC7393CF04F9 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 - https://gpgtools.org iQEcBAEBCgAGBQJWlsDFAAoJEK7rdBF357uoUkgH/j4t3NFiKCS3793nsJ+IOdlV isu7Nmwutge1GlZZIi1lh87jCAi366rNlyPqkKqa1W9/iiJnJJDQY2B6rqq4Xlc+ eq42igNaM5oPhsNKIex892Rq9UoMeu34+bJeGDRBRo0KyUMibo0TdzUqjGeF0a/h DD6jbv60KApW2xRbQH2fm4DG1bOTahJvcoj93qI4M4sHfadqFliHiITX1H062apw F0JsBOmC23REGNvZMV0AuvG6thJSc+Ckl7y4RKiGZc4oiT5p8VCd409YYGV+FAfw 8AChYK3Lr0XnJ6Ll+V1gijxE2/lMsNZkxyKrNTunoQKOB+5ugnAzojytUaR+pZo= =CA4M -----END PGP SIGNATURE----- --Apple-Mail=_9F67847F-EAFB-4F43-BD6E-EC7393CF04F9-- From nobody Wed Jan 13 14:40:17 2016 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B17451A8752 for ; Wed, 13 Jan 2016 14:40:15 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.201 X-Spam-Level: X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FcFn8MuT359w for ; Wed, 13 Jan 2016 14:40:13 -0800 (PST) Received: from phx-mbsout-02.mbs.boeing.net (phx-mbsout-02.mbs.boeing.net [130.76.184.179]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 65BBF1A1BE7 for ; Wed, 13 Jan 2016 14:40:13 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by phx-mbsout-02.mbs.boeing.net (8.14.4/8.14.4/DOWNSTREAM_MBSOUT) with SMTP id u0DMeCo7062625; Wed, 13 Jan 2016 15:40:12 -0700 Received: from XCH15-06-08.nw.nos.boeing.com (xch15-06-08.nw.nos.boeing.com [137.136.238.222]) by phx-mbsout-02.mbs.boeing.net (8.14.4/8.14.4/UPSTREAM_MBSOUT) with ESMTP id u0DMeBjn062603 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=OK); Wed, 13 Jan 2016 15:40:11 -0700 Received: from XCH15-06-11.nw.nos.boeing.com (2002:8988:efdc::8988:efdc) by XCH15-06-08.nw.nos.boeing.com (2002:8988:eede::8988:eede) with Microsoft SMTP Server (TLS) id 15.0.1130.7; Wed, 13 Jan 2016 14:40:10 -0800 Received: from XCH15-06-11.nw.nos.boeing.com ([137.136.239.220]) by XCH15-06-11.nw.nos.boeing.com ([137.136.239.220]) with mapi id 15.00.1130.005; Wed, 13 Jan 2016 14:40:10 -0800 From: "Manfredi, Albert E" To: Bob Hinden Subject: RE: RFC2460bis hop limit text Thread-Topic: RFC2460bis hop limit text Thread-Index: AQHRTkWd24ttYKHoxkeh5jJ7WVl/BJ76e2QA//+IwEA= Date: Wed, 13 Jan 2016 22:40:10 +0000 Message-ID: <0bcdfde5feed4ed4afa9732ec69015b6@XCH15-06-11.nw.nos.boeing.com> References: <1DA06950-D86A-466A-829C-4B3869C4D65A@employees.org> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [137.136.248.6] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-TM-AS-MML: disable Archived-At: Cc: IPv6 List X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 Jan 2016 22:40:15 -0000 PiAtLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KPiBGcm9tOiBpcHY2IFttYWlsdG86aXB2Ni1i b3VuY2VzQGlldGYub3JnXSBPbiBCZWhhbGYgT2YgQm9iIEhpbmRlbg0KDQo+ID4gT24gSmFuIDEz LCAyMDE2LCBhdCAxOjAxIFBNLCBvdHJvYW5AZW1wbG95ZWVzLm9yZyB3cm90ZToNCj4gPiBJIHN1 Z2dlc3Qgd2UgaW5zdGVhZCBzYXkgc29tZXRoaW5nIGxpa2U6DQo+ID4NCj4gPiAgICBIb3AgTGlt aXQgICAgIDgtYml0IHVuc2lnbmVkIGludGVnZXIuICBEZWNyZW1lbnRlZCBieSAxIGJ5DQo+ID4g ICAgICAgICAgICAgICAgICAgICAgICBlYWNoIG5vZGUgdGhhdCBmb3J3YXJkcyB0aGUgcGFja2V0 LiAgVGhlDQo+ID4gICAgICAgICAgICAgICAgICAgICAgICBwYWNrZXQgaXMgZGlzY2FyZGVkIGlm IEhvcCBMaW1pdCBpcw0KPiA+ICAgICAgICAgICAgICAgICAgICAgICAgIGFscmVhZHkgemVybyBv ciBkZWNyZW1lbnRlZCB0byB6ZXJvLg0KPiA+DQo+ID4gSW4gYWRkaXRpb24gYWRkIHRoZSBub3Rl OiAoYWxtb3N0IHZlcmJhdGltIGZyb20gMTgxMikNCj4gPiAgTm90ZTogQSBub2RlIG11c3Qgbm90 IGRpc2NhcmQgYSBkYXRhZ3JhbSBqdXN0IGJlY2F1c2UgaXQgd2FzIHJlY2VpdmVkDQo+ID4gIHdp dGggaG9wIGxpbWl0IGVxdWFsIHRvIHplcm8gb3Igb25lOyBpZiBpdCBpcyB0byB0aGUgbm9kZSBh bmQgb3RoZXJ3aXNlDQo+ID4gIHZhbGlkLCB0aGUgbm9kZSBtdXN0IGF0dGVtcHQgdG8gcmVjZWl2 ZSBpdC4NCj4gDQo+IFRoaXMgdGV4dCBpcyBmaW5lIGZvciBtZS4gIEkgd2lsbCBpbmNvcnBvcmF0 ZSBpdCBpbiB0aGUgbmV4dCBkcmFmdCBpZiB0aGVyZQ0KPiBpc27igJl0IGFueSBwdXNoIGJhY2sg b24gdGhlIGxpc3QuDQoNCklzbid0IHRoaXMgc3RpbGwgSG9wIExpbWl0IGRlZmluaXRpb24gY29u ZnVzaW5nPyBJdCBzb3VuZHMgbGlrZSBhIHBhY2tldCB3aXRoIFRUTCAwIGlzIG5vdCB2YWxpZC4g VGhlICJvciBkZWNyZW1lbnRlZCB0byB6ZXJvIiBwYXJ0LCBzcGVjaWZpY2FsbHksIGlzIGNvbmZ1 c2luZyB0byBtZS4NCg0KIlRoZSBwYWNrZXQgaXMgZGlzY2FyZGVkIGlmIEhvcCBMaW1pdCBpcyBh bHJlYWR5IHplcm8gb3IgZGVjcmVtZW50ZWQgdG8gemVyby4iDQoNCkEgcGFja2V0IHdob3NlIFRU TCBiZWNvbWVzIGRlY3JlbWVudGVkIHRvIDAgd2hpbGUgdHJhdmVyc2luZyB0aGUgcm91dGVyIGlz IG5vdCB0byBiZSBkaXNjYXJkZWQuIFJGQyAxODEyIHNheXMgdGhhdCBhIHBhY2tldCAqaXMgbm90 IGZvcndhcmRlZCogaWYgdGhlIFRUTCB2YWx1ZSBpcyB6ZXJvIHVwb24gYXJyaXZhbC4NCg0KRm9y IGV4YW1wbGUsIGEgcGFja2V0IGFycml2aW5nIHdpdGggVFRMIDEgaXMgZGVjcmVtZW50ZWQgYnkg dGhlIHJvdXRlciB0byBUVEwgMCwgYW5kIGZvcndhcmRlZCB0byB0aGUgbmV4dCBob3AuDQoNCkEg cGFja2V0IGFycml2aW5nIHdpdGggVFRMIDAgaXMgbm90IGZvcndhcmRlZCAqYnV0KiBpdCBpcyB2 YWxpZCBpZiBhZGRyZXNzZWQgdG8gdGhlIHJvdXRlciBpdHNlbGYsIG9yIGFkZHJlc3NlZCB0byBh bnkgb3RoZXIgaG9zdCB3aXRoaW4gdGhlIHNhbWUgSVAgc3VibmV0IGFzIHRoYXQgcm91dGVyIGlu dGVyZmFjZS4NCg0KSG93IGFib3V0Og0KDQpIb3AgTGltaXQgICAgIDgtYml0IHVuc2lnbmVkIGlu dGVnZXIuICBEZWNyZW1lbnRlZCBieSAxIGJ5DQogICAgICAgICAgICAgIGVhY2ggbm9kZSB0aGF0 IGZvcndhcmRzIHRoZSBwYWNrZXQuICBUaGUNCiAgICAgICAgICAgICAgcGFja2V0IGlzIG5vdCBm b3J3YXJkZWQgaWYgSG9wIExpbWl0IGlzDQogICAgICAgICAgICAgIGFscmVhZHkgemVybyB3aGVu IHRoZSBwYWNrZXQgYXJyaXZlcyBhdCB0aGUNCiAgICAgICAgICAgICAgcm91dGVyLiBJZiB0aGUg cGFja2V0IHdpdGggVFRMIDAgYXJyaXZlcw0KICAgICAgICAgICAgICBhZGRyZXNzZWQgdG8gdGhl IHJvdXRlciwgaXQgbXVzdCBiZQ0KICAgICAgICAgICAgICByZWNlaXZlZCBieSB0aGUgcm91dGVy LiANCg0KQmVydA0K From nobody Wed Jan 13 15:12:19 2016 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 723771A886E for ; Wed, 13 Jan 2016 15:12:18 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.002 X-Spam-Level: X-Spam-Status: No, score=-2.002 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UVc6qJTAMJCy for ; Wed, 13 Jan 2016 15:12:17 -0800 (PST) Received: from cowbell.employees.org (cowbell.employees.org [65.50.211.142]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2398E1A886C for ; Wed, 13 Jan 2016 15:12:17 -0800 (PST) Received: from cowbell.employees.org (localhost [127.0.0.1]) by cowbell.employees.org (Postfix) with ESMTP id 376F4D78A5; Wed, 13 Jan 2016 15:12:16 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=employees.org; h=subject :mime-version:content-type:from:in-reply-to:date:cc:message-id :references:to; s=selector1; bh=XGteSJcZE1DUBP6tUpesiR2vFiE=; b= fptwTHPa7irILg8hHPzk4Srezh0RTei7saeq67ZD0GpOVHUsGh4bWbttswCQqHHj 88LP1uMYsmhkXGm20aY05qnFYv5dWAT2+JYUz69+UP0eeOMpRNOUmL9LDn+mY9Xe 3FfgJ0W4z4ek0gcNTfCpxuPPwZvmdbRU8DyV65gr4CU= DomainKey-Signature: a=rsa-sha1; c=nofws; d=employees.org; h=subject :mime-version:content-type:from:in-reply-to:date:cc:message-id :references:to; q=dns; s=selector1; b=LTHHAoLSXHqrXCWDga1Nr1wdx7 CdKa6URmkDr+qe06alMTmF1m5VXRX0WOtE9xDv4Fzu2qQkRcwf+oGVRdcgoOqI5I 7cqsC5mQYOmZzOtJ9oIvjA060kuOiUZgaVdA8T6CeoPJT8959V+ZSZVyMIlv7Lh1 CCQ6IB00/OYOkhhtk= Received: from h.hanazo.no (cm-84.215.10.233.getinternet.no [84.215.10.233]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: otroan) by cowbell.employees.org (Postfix) with ESMTPSA id 7EA8AD7887; Wed, 13 Jan 2016 15:12:15 -0800 (PST) Received: from [IPv6:::1] (localhost [IPv6:::1]) by h.hanazo.no (Postfix) with ESMTP id 378BCE1168B; Thu, 14 Jan 2016 00:12:13 +0100 (CET) Subject: Re: RFC2460bis hop limit text Mime-Version: 1.0 (Mac OS X Mail 9.2 \(3112\)) Content-Type: multipart/signed; boundary="Apple-Mail=_95C8276F-F002-4493-941B-C7FA52A272A5"; protocol="application/pgp-signature"; micalg=pgp-sha512 X-Pgp-Agent: GPGMail 2.6b2 From: otroan@employees.org In-Reply-To: <0bcdfde5feed4ed4afa9732ec69015b6@XCH15-06-11.nw.nos.boeing.com> Date: Thu, 14 Jan 2016 00:12:11 +0100 Message-Id: <052C3A02-060D-432D-854A-2630EC462D80@employees.org> References: <1DA06950-D86A-466A-829C-4B3869C4D65A@employees.org> <0bcdfde5feed4ed4afa9732ec69015b6@XCH15-06-11.nw.nos.boeing.com> To: "Manfredi, Albert E" X-Mailer: Apple Mail (2.3112) Archived-At: Cc: 6man WG , Bob Hinden X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 Jan 2016 23:12:18 -0000 --Apple-Mail=_95C8276F-F002-4493-941B-C7FA52A272A5 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Bert, >>> I suggest we instead say something like: >>>=20 >>> Hop Limit 8-bit unsigned integer. Decremented by 1 by >>> each node that forwards the packet. The >>> packet is discarded if Hop Limit is >>> already zero or decremented to zero. >>>=20 >>> In addition add the note: (almost verbatim from 1812) >>> Note: A node must not discard a datagram just because it was = received >>> with hop limit equal to zero or one; if it is to the node and = otherwise >>> valid, the node must attempt to receive it. >>=20 >> This text is fine for me. I will incorporate it in the next draft if = there >> isn=E2=80=99t any push back on the list. >=20 > Isn't this still Hop Limit definition confusing? It sounds like a = packet with TTL 0 is not valid. The "or decremented to zero" part, = specifically, is confusing to me. Any suggestion how we can make it clear that the whole paragraph only = applies for nodes forwarding the packet? > "The packet is discarded if Hop Limit is already zero or decremented = to zero." >=20 > A packet whose TTL becomes decremented to 0 while traversing the = router is not to be discarded. RFC 1812 says that a packet *is not = forwarded* if the TTL value is zero upon arrival. >=20 > For example, a packet arriving with TTL 1 is decremented by the router = to TTL 0, and forwarded to the next hop. No, that packet is discarded. > A packet arriving with TTL 0 is not forwarded *but* it is valid if = addressed to the router itself, or addressed to any other host within = the same IP subnet as that router interface. >=20 > How about: >=20 > Hop Limit 8-bit unsigned integer. Decremented by 1 by > each node that forwards the packet. The > packet is not forwarded if Hop Limit is > already zero when the packet arrives at the > router. If the packet with TTL 0 arrives > addressed to the router, it must be > received by the router. So, that's not quite right either, since a forwarding node is supposed = to drop any packet with hop limit <=3D 1 (prior to decrementing). Best regards, Ole --Apple-Mail=_95C8276F-F002-4493-941B-C7FA52A272A5 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 - https://gpgtools.org iQIcBAEBCgAGBQJWltnMAAoJEL7aWKiYQt9201kP/j0KGeWFRUK83a/eQUD0P34R HJRJrg/dpMqDYhO+lhfAyYx90U22iCyuLysa47TThRhtJxQyQSdSh7M0DEFBQg5B 8rkv2bKywlG6MvUQ5fr91t1hwORBVxzqwO31nloC/mVej/lcI0NOh71FuWDk6YJL erypbNxO/KvDVDFt7W16h/UydlR2bjy+wj2IhSEErE6Lr891OrxW2/HKIQ9UoMRc I0ea+qRB+Vdrnow1tcK3UDhzC6ab9PJn3r67W+MBqcQtGf63QdZLqQfyolF2vTxe 8KK3uHatmI5DUl2ifK6cwFsCZvnT6gIB5oYKh9WDZT6PhIeyk5W5i7XZwYru86FQ 3fSFEPIBqJhImyVNOc1SoS4KPvG384HOcZm36ey7aVN/ChrpDWikWtb/W0pkszgQ OV+wnsgfFN+GZKKNXsUjUgbKH7sLtr3BMbLABmTL6hyLY1U05jjFu9oZP7w+SBEE CmPGv+oDUdpkVAewML9+mRm1VCQDCMCjmItfpE4v5hDxyK9M0YuQ6rrD89Ag2/j9 IFGWuKKMRfn2XGzS4z/u/fR2P8sPK4hlWCzzXHsiCW0sIIud6b+EybneuN/jOJFq wexk+FLFBvJ1iSjHslbf2+w80HDFvSM0QWCB+Cl5ZVhyoxzTsc8EN01RfDEy4m5K 8VzwSiYxR58xcvwlL7Mt =DkP/ -----END PGP SIGNATURE----- --Apple-Mail=_95C8276F-F002-4493-941B-C7FA52A272A5-- From nobody Wed Jan 13 15:14:44 2016 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 68CB41A8885 for ; Wed, 13 Jan 2016 15:14:42 -0800 (PST) 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=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id l49IpvAwwfHM for ; Wed, 13 Jan 2016 15:14:41 -0800 (PST) Received: from mail-qk0-x22c.google.com (mail-qk0-x22c.google.com [IPv6:2607:f8b0:400d:c09::22c]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E65AC1A8883 for ; Wed, 13 Jan 2016 15:14:40 -0800 (PST) Received: by mail-qk0-x22c.google.com with SMTP id t64so41814409qke.1 for ; Wed, 13 Jan 2016 15:14:40 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=subject:mime-version:content-type:from:in-reply-to:date:cc :message-id:references:to; bh=L6iUZAsOmLF3xxoGDRXmIZB/uhPuyhBYQ4oQ0GFczqs=; b=nY3on4T1RYI0DxLf9A1/KtqLyM/KQBIRW/W05VmKck/OzcU3NOHI5D4NhSLefIZ8j0 rQVp1jyR6M/C354KOfjvbPH1gBteYysDg2wYUUNYwfsOqNDJ11RNH9UFP/lNdnzsNOE+ qwd7Nrt/8UNQOoAlKC4IozChvDweTaNMDbKWYMhbC3ahU+Xok6y8d+hBK5jdYP1Eauvr jYWC8bCOA77wueGrJICdCl4dVPdgUQqrWbxDJ2qMJHEHDdhi8iPMkwq912dQBXXcPYsw VEvIrNn2vTp2qov7L/1sEhGTLSahb6cLaHU4Ogh6uzwQAbbZx+PqJsldpMAOe6Q4ZakF 9vsA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:subject:mime-version:content-type:from :in-reply-to:date:cc:message-id:references:to; bh=L6iUZAsOmLF3xxoGDRXmIZB/uhPuyhBYQ4oQ0GFczqs=; b=fAdhrDJaeSWvILlj5RppnVzUzUZAXJlN8qkNlJxvo2kc6SCzBYxUrDdtIfA0Wh9o0B 4pzPgocdMVz2YdKxMYXBHWhczSjzIRlBMgNDMtw65gCYbT4On9S4NET9FnNJ7gWBs4dm HOF9DltfIaxeD5gVz8kLJuEKeo2tGopEOO4d44l17MMpFocMMDIjycpimWaugHT5A2bk IR1q093E6ukWVsyZsMcNL6Ip8+7lI1XNF/3FgsqDfFHmIfdtyIX+7U+GdL1QEk2zkZgu 463Y5Tj2X2s0HdCMZTYYZ59JKWMfLF8lgeHz3neYAMsdG1FZw6eP1uaHtOM5UoUb/CB2 A92Q== X-Gm-Message-State: ALoCoQlK2nq1MBnp0LTSeK9PmbMfs0vgKZ40ImOJYHw5zzlWqDeb2AaxH5ifJFHz3O01YFMkIuPzaaDBynoCbutt7xL3co21Ow== X-Received: by 10.55.72.146 with SMTP id v140mr1040233qka.63.1452726880136; Wed, 13 Jan 2016 15:14:40 -0800 (PST) Received: from [172.16.224.219] ([209.97.127.34]) by smtp.gmail.com with ESMTPSA id r63sm1417347qkr.17.2016.01.13.15.14.38 (version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Wed, 13 Jan 2016 15:14:38 -0800 (PST) Subject: Re: RFC2460bis hop limit text Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2104\)) Content-Type: multipart/signed; boundary="Apple-Mail=_BA9CDB9B-E02C-4115-9EF2-395150EE82C2"; protocol="application/pgp-signature"; micalg=pgp-sha512 X-Pgp-Agent: GPGMail 2.5.2 From: Bob Hinden In-Reply-To: <0bcdfde5feed4ed4afa9732ec69015b6@XCH15-06-11.nw.nos.boeing.com> Date: Wed, 13 Jan 2016 15:14:35 -0800 Message-Id: <2B824C71-AD8D-4B5E-834E-B158BCD1FEC8@gmail.com> References: <1DA06950-D86A-466A-829C-4B3869C4D65A@employees.org> <0bcdfde5feed4ed4afa9732ec69015b6@XCH15-06-11.nw.nos.boeing.com> To: "Manfredi, Albert E" X-Mailer: Apple Mail (2.2104) Archived-At: Cc: IPv6 List , Bob Hinden X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 Jan 2016 23:14:42 -0000 --Apple-Mail=_BA9CDB9B-E02C-4115-9EF2-395150EE82C2 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Bert, >>=20 > Isn't this still Hop Limit definition confusing? It sounds like a = packet with TTL 0 is not valid. The "or decremented to zero" part, = specifically, is confusing to me. RFC2460 is clear that if the hop limit is decremented to zero, the = packet should be discarded: Hop Limit 8-bit unsigned integer. Decremented by 1 by each node that forwards the packet. The packet is discarded if Hop Limit is decremented to zero. The issue here is what happens if it arrives with a hop limit of zero. = This is based on Errata 4279. http://www.rfc-editor.org/errata_search.php?rfc=3D2460 I believe if is is being forwarded it should be dropped, if it=E2=80=99s = addressed to the node, it should be processed normally. Bob >=20 > "The packet is discarded if Hop Limit is already zero or decremented = to zero." >=20 > A packet whose TTL becomes decremented to 0 while traversing the = router is not to be discarded. RFC 1812 says that a packet *is not = forwarded* if the TTL value is zero upon arrival. >=20 > For example, a packet arriving with TTL 1 is decremented by the router = to TTL 0, and forwarded to the next hop. >=20 > A packet arriving with TTL 0 is not forwarded *but* it is valid if = addressed to the router itself, or addressed to any other host within = the same IP subnet as that router interface. >=20 > How about: >=20 > Hop Limit 8-bit unsigned integer. Decremented by 1 by > each node that forwards the packet. The > packet is not forwarded if Hop Limit is > already zero when the packet arrives at the > router. If the packet with TTL 0 arrives > addressed to the router, it must be > received by the router. >=20 --Apple-Mail=_BA9CDB9B-E02C-4115-9EF2-395150EE82C2 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 - https://gpgtools.org iQEcBAEBCgAGBQJWltpcAAoJEK7rdBF357uo5e4IAIFztrjATcicxx0OwRRgS9md J7AkVzjMdc+redSVEX2msDLwZJ0yRlWtHmloOc8x+6G5pVbSaA0KUw3E+zoRP+KM EOUll7zesFqDXMcu8HN01A9b6Blykim1yFsxNtALFP+dii6Q2DPnyeerxHinpt43 xJB/4BQzkzRuwIfiJV1xAa4dvgtVNSWEk9I7Y1BL1cxzCElmMf4X3WEuzBojYi8E mgL6o+CM56jkPMpCeQi00Ru1SFebVyTektR4wH9Zv7Yl/amvwmnDdRcD7edLve5V AxSMmSrbf1J4bMwuZzdjVm93lHl+zPx45Gz62h0GjXTQ2q1tDVJC/fUkk+C/g/A= =K8HA -----END PGP SIGNATURE----- --Apple-Mail=_BA9CDB9B-E02C-4115-9EF2-395150EE82C2-- From nobody Wed Jan 13 15:58:43 2016 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 393F81ACEC7 for ; Wed, 13 Jan 2016 15:58:42 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.201 X-Spam-Level: X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YMAZ6tJrK2Oc for ; Wed, 13 Jan 2016 15:58:40 -0800 (PST) Received: from phx-mbsout-02.mbs.boeing.net (phx-mbsout-02.mbs.boeing.net [130.76.184.179]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 847B81ACEC4 for ; Wed, 13 Jan 2016 15:58:40 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by phx-mbsout-02.mbs.boeing.net (8.14.4/8.14.4/DOWNSTREAM_MBSOUT) with SMTP id u0DNweUx043161; Wed, 13 Jan 2016 16:58:40 -0700 Received: from XCH15-06-10.nw.nos.boeing.com (xch15-06-10.nw.nos.boeing.com [137.136.239.219]) by phx-mbsout-02.mbs.boeing.net (8.14.4/8.14.4/UPSTREAM_MBSOUT) with ESMTP id u0DNwcOk043157 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=OK); Wed, 13 Jan 2016 16:58:38 -0700 Received: from XCH15-06-11.nw.nos.boeing.com (2002:8988:efdc::8988:efdc) by XCH15-06-10.nw.nos.boeing.com (2002:8988:efdb::8988:efdb) with Microsoft SMTP Server (TLS) id 15.0.1130.7; Wed, 13 Jan 2016 15:58:37 -0800 Received: from XCH15-06-11.nw.nos.boeing.com ([137.136.239.220]) by XCH15-06-11.nw.nos.boeing.com ([137.136.239.220]) with mapi id 15.00.1130.005; Wed, 13 Jan 2016 15:58:37 -0800 From: "Manfredi, Albert E" To: Bob Hinden Subject: RE: RFC2460bis hop limit text Thread-Topic: RFC2460bis hop limit text Thread-Index: AQHRTkWd24ttYKHoxkeh5jJ7WVl/BJ76e2QA//+IwECAAJXCgP//fnDg Date: Wed, 13 Jan 2016 23:58:37 +0000 Message-ID: <28e41b59e47b414aa31bb02fab145a33@XCH15-06-11.nw.nos.boeing.com> References: <1DA06950-D86A-466A-829C-4B3869C4D65A@employees.org> <0bcdfde5feed4ed4afa9732ec69015b6@XCH15-06-11.nw.nos.boeing.com> <2B824C71-AD8D-4B5E-834E-B158BCD1FEC8@gmail.com> In-Reply-To: <2B824C71-AD8D-4B5E-834E-B158BCD1FEC8@gmail.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [137.136.248.6] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-TM-AS-MML: disable Archived-At: Cc: IPv6 List X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 Jan 2016 23:58:42 -0000 PiAtLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KPiBGcm9tOiBCb2IgSGluZGVuIFttYWlsdG86 Ym9iLmhpbmRlbkBnbWFpbC5jb21dDQoNCg0KPiBSRkMyNDYwIGlzIGNsZWFyIHRoYXQgaWYgdGhl IGhvcCBsaW1pdCBpcyBkZWNyZW1lbnRlZCB0byB6ZXJvLCB0aGUgcGFja2V0DQo+IHNob3VsZCBi ZSBkaXNjYXJkZWQ6DQo+IA0KPiAgSG9wIExpbWl0ICAgICAgICAgICAgICA4LWJpdCB1bnNpZ25l ZCBpbnRlZ2VyLiAgRGVjcmVtZW50ZWQgYnkgMSBieQ0KPiAgICAgICAgICAgICAgICAgICAgICAg ICBlYWNoIG5vZGUgdGhhdCBmb3J3YXJkcyB0aGUgcGFja2V0LiBUaGUgcGFja2V0DQo+ICAgICAg ICAgICAgICAgICAgICAgICAgIGlzIGRpc2NhcmRlZCBpZiBIb3AgTGltaXQgaXMgZGVjcmVtZW50 ZWQgdG8NCj4gICAgICAgICAgICAgICAgICAgICAgICAgemVyby4NCj4gDQo+IFRoZSBpc3N1ZSBo ZXJlIGlzIHdoYXQgaGFwcGVucyBpZiBpdCBhcnJpdmVzIHdpdGggYSBob3AgbGltaXQgb2YgemVy by4gIFRoaXMNCj4gaXMgYmFzZWQgb24gRXJyYXRhIDQyNzkuDQo+IA0KPiAgICAgaHR0cDovL3d3 dy5yZmMtZWRpdG9yLm9yZy9lcnJhdGFfc2VhcmNoLnBocD9yZmM9MjQ2MA0KPiANCj4gSSBiZWxp ZXZlIGlmIGlzIGlzIGJlaW5nIGZvcndhcmRlZCBpdCBzaG91bGQgYmUgZHJvcHBlZCwgaWYgaXTi gJlzIGFkZHJlc3NlZCB0bw0KPiB0aGUgbm9kZSwgaXQgc2hvdWxkIGJlIHByb2Nlc3NlZCBub3Jt YWxseS4NCg0KTXkgYmFkLiBZb3UgYW5kIE9sZSBhcmUgcmlnaHQuIEkgd2VudCBiYWNrIHRvIFJG QyA3OTEsIHdoaWNoIHNheXMgdGhlIHNhbWUgdGhpbmc6DQoNClRpbWUgdG8gTGl2ZTogIDggYml0 cw0KDQogICAgVGhpcyBmaWVsZCBpbmRpY2F0ZXMgdGhlIG1heGltdW0gdGltZSB0aGUgZGF0YWdy YW0gaXMgYWxsb3dlZCB0bw0KICAgIHJlbWFpbiBpbiB0aGUgaW50ZXJuZXQgc3lzdGVtLiAgSWYg dGhpcyBmaWVsZCBjb250YWlucyB0aGUgdmFsdWUNCiAgICB6ZXJvLCB0aGVuIHRoZSBkYXRhZ3Jh bSBtdXN0IGJlIGRlc3Ryb3llZC4gLi4uDQoNClNvIFJGQyAxODEyIGlzIHRyeWluZyB0byBhY2Nv bW1vZGF0ZSBtaXNiZWhhdmlvciwgdG8gc29tZSBkZWdyZWUsIHdoZW4gaXQgc2F5czoNCg0KICAg VFRMIGV4cGlyYXRpb24gaXMgaW50ZW5kZWQgdG8gY2F1c2UgZGF0YWdyYW1zIHRvIGJlIGRpc2Nh cmRlZCBieQ0KICAgcm91dGVycywgYnV0IG5vdCBieSB0aGUgZGVzdGluYXRpb24gaG9zdC4gIEhv c3RzIHRoYXQgYWN0IGFzIHJvdXRlcnMNCiAgIGJ5IGZvcndhcmRpbmcgZGF0YWdyYW1zIG11c3Qg dGhlcmVmb3JlIGZvbGxvdyB0aGUgcm91dGVyJ3MgcnVsZXMgZm9yDQogICBUVEwuDQoNClNlZW1z IHRvIGNvbnRyYWRpY3QgUkZDIDc5MSBhbmQgUkZDIDI0NjAuIFRoZWlyIGluc3RydWN0aW9ucyBh cmUgbm90IGxpbWl0ZWQgdG8gcm91dGVycy4gVGhleSdyZSBhbHNvIHRlbGxpbmcgaG9zdHMgdG8g ZGVzdHJveSB0aGVzZSBwYWNrZXRzLiAoUkZDIDE4MTIgbWVudGlvbnMgc3BlY2lhbCBjYXNlcywg ZS5nLiB1c2VkIGJ5IGRpYWdub3N0aWMgdG9vbHMuKSBTbyBldmlkZW50bHksIHRoZXJlIHdhcyBh IGNoYW5nZSBvZiBoZWFydCBhdCB0aGUgSUVURiwgYWZ0ZXIgUkZDIDc5MT8NCg0KT2theSwgaG93 IGFib3V0IHRoaXM6DQoNCkhvcCBMaW1pdCAgICAgOC1iaXQgdW5zaWduZWQgaW50ZWdlci4gIERl Y3JlbWVudGVkIGJ5IDEgYnkNCiAgICAgICAgICAgICAgZWFjaCBub2RlIHRoYXQgZm9yd2FyZHMg dGhlIHBhY2tldC4gIFRoZQ0KICAgICAgICAgICAgICBwYWNrZXQgaXMgbm90IGZvcndhcmRlZCBp ZiBIb3AgTGltaXQgaXMNCiAgICAgICAgICAgICAgYWxyZWFkeSB6ZXJvIHdoZW4gdGhlIHBhY2tl dCBhcnJpdmVzIGF0IHRoZQ0KICAgICAgICAgICAgICByb3V0ZXIsIG9yIGJlY29tZXMgZGVjcmVt ZW50ZWQgdG8gemVybyB3aGVuDQogICAgICAgICAgICAgIHRyYXZlcnNpbmcgdGhlIHJvdXRlci4g SG93ZXZlciBkZXN0aW5hdGlvbg0KICAgICAgICAgICAgICBob3N0cywgaW5jbHVkaW5nIHJvdXRl cnMsIG11c3QgcmVjZWl2ZSBhbmQNCiAgICAgICAgICAgICAgcHJvY2VzcyBwYWNrZXRzIGFkZHJl c3NlZCB0byBhbiBJUCBpbnRlcmZhY2UNCiAgICAgICAgICAgICAgZXZlbiBpZiBUVEwgaXMgemVy bywgdG8gYWNjb21tb2RhdGUNCiAgICAgICAgICAgICAgbWlzYmVoYXZpbmcgaG9zdHMuDQoNCkJl cnQNCg0K From nobody Wed Jan 13 18:37:54 2016 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 343691B2A93 for ; Wed, 13 Jan 2016 18:37:53 -0800 (PST) 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=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RqtyAHPNEL1P for ; Wed, 13 Jan 2016 18:37:51 -0800 (PST) Received: from mail-pf0-x22f.google.com (mail-pf0-x22f.google.com [IPv6:2607:f8b0:400e:c00::22f]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2BC481B2A90 for ; Wed, 13 Jan 2016 18:37:51 -0800 (PST) Received: by mail-pf0-x22f.google.com with SMTP id 65so91331128pff.2 for ; Wed, 13 Jan 2016 18:37:51 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=subject:to:references:from:organization:message-id:date:user-agent :mime-version:in-reply-to:content-type:content-transfer-encoding; bh=pL8qYNCpAo4xnbOol/2CRpj6ygd/kUGQW1yKkAo0Szw=; b=dMPNC2kCPOxLsnDKDikf4M14RgUOuB85UChNEVJEwPgvFXL+EChPaF8QzJYoUQTqW3 o0WRmD0o8aH/0VYKo+B1zl+6zjnTGy30eTR5fUTQNGyodX8glqRgswJ3ZAVJfJJCs813 YGX9WwIpcOSvyE2V5BxkrgW22bvzUwedwdYgKXd9hhvisUBt4NIj+o2e/xW+FpbsWLKS Ap0sGpY1uCTxjh3DuzXWFGvvHlP+JQoh0nyZLbZJciIENHH1oh22EnP4ix+iaR5aC0/b m/wKZUy6YizgbC2aoY88tjNcz+SqN5kuTuJGQNar+tnycnZlZhav5uaQ/FGd2gmf/Kn/ 8WHA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:subject:to:references:from:organization :message-id:date:user-agent:mime-version:in-reply-to:content-type :content-transfer-encoding; bh=pL8qYNCpAo4xnbOol/2CRpj6ygd/kUGQW1yKkAo0Szw=; b=mHAZTDpdndp/6AuhOjxx1BMN9rlCg23JXXk3pGPMZGh5wg2qa8gWf6tUVXZuTP1vXH sMajOzP45B/lAi4vLYBY2QRYYll6rzpOSfHKsPx2dGhFAJ+Ltxk/RtFyBk2EF8fl2yB+ mCZzNRfcgfo8b9jLAo7/twqUWI9KbirF7y8DjfMJEi2K3wnZwa766qwOnjDgonnWbIcM EDZO7EE/a/40Cg/jZ+tUzP9I3oA1HR9kVkxr7zfSo9r1Q5Bdyywf+ZhnEBxQ531i+IQh 1axbwACUd8lxe0y2BImy+50uqjWOODTjv28ZJfEkAe1sWX/tpr8VkJW5xNOSiBJEsaUv ea4w== X-Gm-Message-State: ALoCoQni7ImKszakaIIq6qYKkl90VJC60jUcsDIv9JLzYLje8pvVTGvCLJtJXpC23MGzcySiUnA2y28ib/kVsP92Eh85dt9jFQ== X-Received: by 10.98.74.9 with SMTP id x9mr2348783pfa.14.1452739070835; Wed, 13 Jan 2016 18:37:50 -0800 (PST) Received: from ?IPv6:2406:e007:7472:1:28cc:dc4c:9703:6781? ([2406:e007:7472:1:28cc:dc4c:9703:6781]) by smtp.gmail.com with ESMTPSA id g87sm5471618pfj.1.2016.01.13.18.37.48 for (version=TLSv1/SSLv3 cipher=OTHER); Wed, 13 Jan 2016 18:37:49 -0800 (PST) Subject: Re: RFC2460bis hop limit text To: ipv6@ietf.org References: <1DA06950-D86A-466A-829C-4B3869C4D65A@employees.org> <0bcdfde5feed4ed4afa9732ec69015b6@XCH15-06-11.nw.nos.boeing.com> <2B824C71-AD8D-4B5E-834E-B158BCD1FEC8@gmail.com> From: Brian E Carpenter Organization: University of Auckland Message-ID: <56970A02.2090503@gmail.com> Date: Thu, 14 Jan 2016 15:37:54 +1300 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.5.0 MIME-Version: 1.0 In-Reply-To: <2B824C71-AD8D-4B5E-834E-B158BCD1FEC8@gmail.com> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Archived-At: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 Jan 2016 02:37:53 -0000 On 14/01/2016 12:14, Bob Hinden wrote: > Bert, >=20 >>> >> Isn't this still Hop Limit definition confusing? It sounds like a pack= et with TTL 0 is not valid. The "or decremented to zero" part, specifical= ly, is confusing to me. >=20 > RFC2460 is clear that if the hop limit is decremented to zero, the pack= et should be discarded: >=20 > Hop Limit 8-bit unsigned integer. Decremented by 1 by > each node that forwards the packet. The packet > is discarded if Hop Limit is decremented to > zero. >=20 > The issue here is what happens if it arrives with a hop limit of zero. = This is based on Errata 4279. >=20 > http://www.rfc-editor.org/errata_search.php?rfc=3D2460 >=20 > I believe if is is being forwarded it should be dropped, if it=E2=80=99= s addressed to the node, it should be processed normally. That's a reasonable choice we can make, but it is a protocol change compared to RFC 2460. Looking at Erratum 4279, which doesn't resolve the dubious text at all, I am troubled by these words "Following the instructions in that case would result in decrementing the= hop limit from 0 to -1 (so, 255)...". Er, no. Properly written (micro)code asked to decrement an unsigned integ= er will not change 0 to -1; it will throw an error. We should definitely mak= e this clear in the 2460bis text. Brian From nobody Thu Jan 14 15:52:09 2016 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1E77F1A87B8 for ; Thu, 14 Jan 2016 15:52:07 -0800 (PST) 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=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Rq5yqq3te4ti for ; Thu, 14 Jan 2016 15:52:05 -0800 (PST) Received: from mail-qg0-x236.google.com (mail-qg0-x236.google.com [IPv6:2607:f8b0:400d:c04::236]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 433041A8795 for ; Thu, 14 Jan 2016 15:52:05 -0800 (PST) Received: by mail-qg0-x236.google.com with SMTP id e32so408132417qgf.3 for ; Thu, 14 Jan 2016 15:52:05 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=subject:mime-version:content-type:from:in-reply-to:date:cc :message-id:references:to; bh=qxOLwA93TQb3Ch952I9PEiJtF14P4cW9pmGRYgSq4MY=; b=SBt4jWO0oablxFJ1pjVhq5CwnZDAngMwrVDmTisd0rvYQ4+YrpXMrFlhVshnqVMbZn /nRRN8uEGt5XFe/WOHjJBhjuKRVyQKsyTM4c5pKENd1M4NXiMajBWl9ynFtGlP6REs04 hRXqUAS1pxMlykuN4GhoIcFkUUK+cDh+ggfJpYuPHKRWidSI4ncFxW5Oo9AtpihiB7O9 TGzOH3qLu69uIvzeE/V/1ckrUxBxB4DkzlkeshOzzwMXosIJz0vp7J7F3D3mpK2epkWQ wap/BNX8nIV0DfstPiJGxOF66y2lUjxch2Vd1ag8EVP0fYwLdIkDVGaR1Np0EJDdgcwB Ji3g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:subject:mime-version:content-type:from :in-reply-to:date:cc:message-id:references:to; bh=qxOLwA93TQb3Ch952I9PEiJtF14P4cW9pmGRYgSq4MY=; b=hLcNfDI97GrplyRb4izLLuz+HreOv9U7CjNTh72rAdYTQJ+LmJX7LnwfUnIXGf5ihM mUsynD54d9CoAxSsvGdNFOrJbIQyhG/UsRC2Zx7bcjeQ++KqLGph5FkTdKzm6FEzHvuH I562lzp9uXAGUJNMVGZ126ExnlxZTrxfTvVByTOGyKB/RCq8khbuevVV0Od9RZ7VIe+A 1HvcC+PTW8m9DEN7FYLjepl+TFpivFJCmVWMT+jyqiEXUzH6IK0k/ve0yV2Si4nlev7Z l4owtaltVrw2kndWPWUXfKT/0iMb/89yKGgesnQdgrDxMhYAPGatgeO+J2LR/Pa4NEkt 373w== X-Gm-Message-State: ALoCoQlHAwoICjRAgWAf56jJIBSMAJH4hC4wUusTkQMrGE0JbJv6F5XC8Z9u4AkCGdH5R/ZR+5ZMjTFq9otv3mFrAhZQ6m5y4w== X-Received: by 10.140.19.148 with SMTP id 20mr9744081qgh.60.1452815524459; Thu, 14 Jan 2016 15:52:04 -0800 (PST) Received: from [172.16.224.219] ([209.97.127.34]) by smtp.gmail.com with ESMTPSA id d62sm3436778qga.41.2016.01.14.15.52.02 (version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Thu, 14 Jan 2016 15:52:02 -0800 (PST) Subject: Re: RFC2460bis hop limit text Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2104\)) Content-Type: multipart/signed; boundary="Apple-Mail=_AE6C0053-0FA4-4BFB-9067-146EA5BA650A"; protocol="application/pgp-signature"; micalg=pgp-sha512 X-Pgp-Agent: GPGMail 2.5.2 From: Bob Hinden In-Reply-To: <28e41b59e47b414aa31bb02fab145a33@XCH15-06-11.nw.nos.boeing.com> Date: Thu, 14 Jan 2016 15:51:59 -0800 Message-Id: References: <1DA06950-D86A-466A-829C-4B3869C4D65A@employees.org> <0bcdfde5feed4ed4afa9732ec69015b6@XCH15-06-11.nw.nos.boeing.com> <2B824C71-AD8D-4B5E-834E-B158BCD1FEC8@gmail.com> <28e41b59e47b414aa31bb02fab145a33@XCH15-06-11.nw.nos.boeing.com> To: "Manfredi, Albert E" X-Mailer: Apple Mail (2.2104) Archived-At: Cc: IPv6 List , Bob Hinden X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 Jan 2016 23:52:07 -0000 --Apple-Mail=_AE6C0053-0FA4-4BFB-9067-146EA5BA650A Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Bert, > .. > So RFC 1812 is trying to accommodate misbehavior, to some degree, when = it says: >=20 > TTL expiration is intended to cause datagrams to be discarded by > routers, but not by the destination host. Hosts that act as routers > by forwarding datagrams must therefore follow the router's rules for > TTL. >=20 > Seems to contradict RFC 791 and RFC 2460. Their instructions are not = limited to routers. They're also telling hosts to destroy these packets. = (RFC 1812 mentions special cases, e.g. used by diagnostic tools.) So = evidently, there was a change of heart at the IETF, after RFC 791? >=20 > Okay, how about this: >=20 > Hop Limit 8-bit unsigned integer. Decremented by 1 by > each node that forwards the packet. The > packet is not forwarded if Hop Limit is > already zero when the packet arrives at the > router, or becomes decremented to zero when > traversing the router. However destination > hosts, including routers, must receive and > process packets addressed to an IP interface > even if TTL is zero, to accommodate > misbehaving hosts. >=20 s/TTL/Hop Limit/ :-) How about: Hop Limit 8-bit unsigned integer. Decremented by 1 by each node that forwards the packet. When forwarding, the packet is discarded if Hop Limit was zero when received or is decremented to zero. A node that is the destination of a packet should not discard a packet with hop limit equal to zero, it should process the packet normally. Accomplishes the same thing and matches the style of the document. Thanks, Bob --Apple-Mail=_AE6C0053-0FA4-4BFB-9067-146EA5BA650A 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 - https://gpgtools.org iQEcBAEBCgAGBQJWmDSgAAoJEK7rdBF357uoYiMIALCWNaMOEwIxQfnkVyo30Mr9 Z0hBTdQ+4mrEIj7hJGlJ/jjof1a9y9H2lVCwz7PYy2JjCcmJciIYLtByx3kAmv7u qaYZDVAjDAS31OE96Gygh9v858HtNS/7XCGjJqsA1aJ7EKqajQ+6AMHMWk9Ws7vI LphCTuI1E1jcSpjXXx3QTrQJZhVNAgxuFUriFeCehdPQTujVlCWaRpxrBSl5e9PI mWKcdGzuR+fof4gUkSVjcBUOhWG0Nk/EYFbZHQjJJdDGdNOvzF7rdbLx41pKWPxY yFEPfWpsgf/TjJ9QfTxjNkSUdqEOPYRq8f3snjtssZtovvH/66iarlunyIl+uqM= =cE+J -----END PGP SIGNATURE----- --Apple-Mail=_AE6C0053-0FA4-4BFB-9067-146EA5BA650A-- From nobody Thu Jan 14 15:57:12 2016 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C76A61A88CB for ; Thu, 14 Jan 2016 15:57:10 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.201 X-Spam-Level: X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ToRu2g9ZAG2B for ; Thu, 14 Jan 2016 15:57:09 -0800 (PST) Received: from phx-mbsout-01.mbs.boeing.net (phx-mbsout-01.mbs.boeing.net [130.76.184.178]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AECB11A88C9 for ; Thu, 14 Jan 2016 15:57:09 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by phx-mbsout-01.mbs.boeing.net (8.14.4/8.14.4/DOWNSTREAM_MBSOUT) with SMTP id u0ENv8ti032078; Thu, 14 Jan 2016 16:57:08 -0700 Received: from XCH15-06-07.nw.nos.boeing.com (xch15-06-07.nw.nos.boeing.com [137.136.238.213]) by phx-mbsout-01.mbs.boeing.net (8.14.4/8.14.4/UPSTREAM_MBSOUT) with ESMTP id u0ENv87D032068 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=OK); Thu, 14 Jan 2016 16:57:08 -0700 Received: from XCH15-06-11.nw.nos.boeing.com (2002:8988:efdc::8988:efdc) by XCH15-06-07.nw.nos.boeing.com (2002:8988:eed5::8988:eed5) with Microsoft SMTP Server (TLS) id 15.0.1130.7; Thu, 14 Jan 2016 15:57:06 -0800 Received: from XCH15-06-11.nw.nos.boeing.com ([137.136.239.220]) by XCH15-06-11.nw.nos.boeing.com ([137.136.239.220]) with mapi id 15.00.1130.005; Thu, 14 Jan 2016 15:57:07 -0800 From: "Manfredi, Albert E" To: Bob Hinden Subject: RE: RFC2460bis hop limit text Thread-Topic: RFC2460bis hop limit text Thread-Index: AQHRTyaZIHAIasV/lUmw52mCC2+SNp77r5WQ Date: Thu, 14 Jan 2016 23:57:07 +0000 Message-ID: <63682210dc654683aacee48561774c12@XCH15-06-11.nw.nos.boeing.com> References: <1DA06950-D86A-466A-829C-4B3869C4D65A@employees.org> <0bcdfde5feed4ed4afa9732ec69015b6@XCH15-06-11.nw.nos.boeing.com> <2B824C71-AD8D-4B5E-834E-B158BCD1FEC8@gmail.com> <28e41b59e47b414aa31bb02fab145a33@XCH15-06-11.nw.nos.boeing.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [137.136.248.6] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-TM-AS-MML: disable Archived-At: Cc: IPv6 List X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 Jan 2016 23:57:11 -0000 > -----Original Message----- > From: Bob Hinden [mailto:bob.hinden@gmail.com] > How about: >=20 > Hop Limit 8-bit unsigned integer. Decremented by 1 by > each node that forwards the packet. When > forwarding, the packet is discarded if Hop > Limit was zero when received or is decremented > to zero. A node that is the destination of a > packet should not discard a packet with hop > limit equal to zero, it should process the > packet normally. >=20 > Accomplishes the same thing and matches the style of the document. It's a deal! Thanks. Bert From nobody Thu Jan 14 16:02:19 2016 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 38FAE1A8A94 for ; Thu, 14 Jan 2016 16:02:18 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.298 X-Spam-Level: X-Spam-Status: No, score=0.298 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, MIME_8BIT_HEADER=0.3, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Ch2Z802qm1hO for ; Thu, 14 Jan 2016 16:02:15 -0800 (PST) Received: from fgont.go6lab.si (fgont.go6lab.si [IPv6:2001:67c:27e4::14]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 845761A8A46 for ; Thu, 14 Jan 2016 16:02:15 -0800 (PST) Received: from [192.168.1.133] (unknown [186.128.174.1]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by fgont.go6lab.si (Postfix) with ESMTPSA id 1AE122068A1; Fri, 15 Jan 2016 01:02:05 +0100 (CET) Subject: Re: 6MAN WG Last Call - draft-ietf-6man-deprecate-atomfrag-generation To: =?UTF-8?B?56We5piO6YGU5ZOJ?= , Bob Hinden References: <7BEE06A2-0F6E-493F-B2C6-68DAB3774FD5@gmail.com> From: Fernando Gont X-Enigmail-Draft-Status: N1110 Message-ID: <5698339D.5010203@si6networks.com> Date: Thu, 14 Jan 2016 20:47:41 -0300 User-Agent: Mozilla/5.0 (X11; Linux i686; rv:38.0) Gecko/20100101 Thunderbird/38.4.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Archived-At: Cc: IPv6 List X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 15 Jan 2016 00:02:18 -0000 Hi, Jinmei, On 01/12/2016 03:43 PM, 神明é”哉 wrote: > > I have a few comments on the 04 version however, which may better be > addressed before the publication: > > - The title seems to be misleading to me. On starting to re-read the > latest version almost forgetting past discussions, I first wondered > why this is supposed to be "Informational" if it "deprecates" a > standard feature. I then found it actually does not insist on > deprecating it by updating RFC2460, merely saying the authors > the believed atomic fragment is a bad idea. FWIW, this version documents the issues associated with atomic fragments, and why such support is removed from RFC2460bis. > The title confused me, > and I guess it will confuse other future readers. So I suggest > renaming it something like "Issues with the Generation of IPv6 > Atomic Fragments" or if some stronger word is preferred, "The > Generation of IPv6 Atomic Fragments is Considered Harmful". Any of the two above sound fine to me. I'll stick with "Issues..." unless folks argue in favor of the second option you suggested. > - This arguments in Section 4 seem to be a bit weak to me: > > o There exists a fair share of evidence of ICMPv6 Packet Too Big > messages being dropped on the public Internet (for instance, that > is one of the reasons for which PLPMTUD [RFC4821] was produced)., if anythin > [...] > > This being the case, using atomic fragments for attacks would also > be less appealing, so we might argue we don't have to worry about it > too much. Two comments on this one: 1) This is not the key or sole argument, but, if anything, just one of the reasons for removing such support. 2) When you have functionality that cannot be relied upon, it cannot be employed for legitimate purposes (it is not reliable), but is a potential security lingering. > A possible counter argument to this might be that we > don't want to allow any possibility of attacks while for legitimate > cases we rather want it to always work. That's exactly the point. > I might buy it, but the > seemingly arbitrary use of a particular point for the suggested > conclusion rather makes the whole tone of the document look unfair > IMO. It may be only me, in which case I won't argue this should be > necessarily addressed, but if some others have the same impression > providing more neutral and/or discussion might help. I will go through the whole document with a fresh look and try to improve it in this respect. > - Appendix A: it's a bit surprising to me that some BSD variants are > listed here: > > o FreeBSD 8.0 > o NetBSD 5.1 > > The generation of atomic fragments was supported in quite an early > version of the KAME IPv6 stack, from which many of BSD variants were > derived. One repository log suggests it had been supported since > around 2002: > https://github.com/kame/kame/commit/eaaefeddf7c2878fe03f649b2da4d8535427aeb0 > > And, while I don't have an environment to readily check the actual > behavior right now, the latest version of both FreeBSD and NetBSD > still seems to have essentially the same code. In fact, according > to RFC6946 later versions of FreeBSD can generate atomic fragments: > > +---------------------+---------------------+-----------------------+ > | Operating System | Generates atomic | Implements this | > | | fragments | specification | > +---------------------+---------------------+-----------------------+ > | FreeBSD 8.0 | No | No | > +---------------------+---------------------+-----------------------+ > | FreeBSD 8.2 | Yes | No | > +---------------------+---------------------+-----------------------+ > | FreeBSD 9.0 | Yes | No | > +---------------------+---------------------+-----------------------+ > > So the result for 8.0 rather seems to be an intermittent regression. > Like the previous point, I would find it unfair to only refer to an > exceptional case that would support the conclusion of the authors. FWIW, this was never meant to be unfair, but was rather included asn example of an OS that fails to generate them. FWIW, I used FreeBSD 8.0 a lot for testing, courses, etc.... so the test on FreeBSD 8.0 was purely coincidential.... Do you think we should include, e.g., a later version of FreeBSD to show that later versions do support it? > Perhaps (hopefully) that was not the intent of the authors, but if > it's written more carefully so it won't look like picking specific > evidences for a particular conclusion, I would accept it more > comfortably. As noted, that wasn't intentional. That sid, I think that, in this sort of cases, showing sample platforms where functionality doesn't work is of more value than showing platforms where the functionality does work -- because in order to rely on it, it is important that it works in most cases. Otherwise, you cannot rely on functionality that only works on a subset of systems/pĺatforms (particularly when, as noted RFC6145 itself, there are options to make the consumer protocols of these atomic fragments reliable). Thanks! Best regards, -- Fernando Gont SI6 Networks e-mail: fgont@si6networks.com PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492 From nobody Thu Jan 14 17:32:11 2016 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1B8B41B2E46 for ; Thu, 14 Jan 2016 17:32:09 -0800 (PST) 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=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cXvnSua27Zzv for ; Thu, 14 Jan 2016 17:32:07 -0800 (PST) Received: from mail-qg0-x230.google.com (mail-qg0-x230.google.com [IPv6:2607:f8b0:400d:c04::230]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4DCE71B2E45 for ; Thu, 14 Jan 2016 17:32:07 -0800 (PST) Received: by mail-qg0-x230.google.com with SMTP id e32so409617020qgf.3 for ; Thu, 14 Jan 2016 17:32:07 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=subject:mime-version:content-type:from:in-reply-to:date:cc :message-id:references:to; bh=FDxlCwzBgpoAe8mNnRPkndbLhvlNMOm1ZYTajexQNzU=; b=0IH2PUQgOSOHgRKGHAkw0Jo/x9Pp+S8L58+RxW/pgoGFE/EqZRVF18I+YyaBzdcClP gQBi3q1qhHDHAfUlqLu4h+k8T8jUpCSJDgOaJ2fcGWNlngDs9Y365EkWy0deXPh16cR3 xkW1CFhNkU6tiMqbsLnLQCBevhS3rRdC0oEGSvA0RIkBnoz76Ey67wAdgq9R4zKngfV3 c7JFiKud4PdptRZo+48jxVBNwNvYy22QA/p5VEtR003xW1USpG7yfE26975nRtyuYmeQ AWZ1M7JTU6yzgYYTLPrhDIj7NU8pnLOZt/hy5rvyPTY26ENTGkX7+hb7hLRWsgtmJgLg UZgg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:subject:mime-version:content-type:from :in-reply-to:date:cc:message-id:references:to; bh=FDxlCwzBgpoAe8mNnRPkndbLhvlNMOm1ZYTajexQNzU=; b=kH7lCZD9XUPhvKQLcsaSA4h5DT8kRo133Rda2DaUsoyB/ONAnC6XgZT/ULhDfsCuu3 trhi+Jk74MHiVfJDvrEXsL/mbQrDmdCf/s1tzzR/1bzyvchjU3tMC55kWjc95wwPpiw8 /rvnl/kDafUpvF6ny/FtX0y7CveY0/s+fEqrSwcDmDlJ+xZ1LetzMDkto8ETYsqv96A/ s/T0QginvIayh7MF+Dgle6plmoAMbzR5ZrYylTZTeotFKaOLZ8o0PR1SX5IcvXnbATDg 5VlbE6XxMC8FQtlKIc7Qip4jcBy/3w22sBvjuC2407mBrjxygGfvyX+jb6aDLgoj3dOK 6x7Q== X-Gm-Message-State: ALoCoQnxNYSLAdKN7OrK33Zvuv0ljcZpj44hwc2zoe2Tw6cTR6BXnKDajh7EMiDr9Auf0pWeFWPB0a2qClXKldP12SFpJxYuqQ== X-Received: by 10.140.231.137 with SMTP id b131mr10854533qhc.63.1452821526598; Thu, 14 Jan 2016 17:32:06 -0800 (PST) Received: from [10.0.0.24] (c-71-202-19-53.hsd1.ca.comcast.net. [71.202.19.53]) by smtp.gmail.com with ESMTPSA id j23sm3598968qge.23.2016.01.14.17.32.05 (version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Thu, 14 Jan 2016 17:32:05 -0800 (PST) Subject: Re: RFC2460bis hop limit text Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2104\)) Content-Type: multipart/signed; boundary="Apple-Mail=_648D62AC-30FA-4A5E-9944-9468FF55833E"; protocol="application/pgp-signature"; micalg=pgp-sha512 X-Pgp-Agent: GPGMail 2.5.2 From: Bob Hinden In-Reply-To: <63682210dc654683aacee48561774c12@XCH15-06-11.nw.nos.boeing.com> Date: Thu, 14 Jan 2016 17:32:03 -0800 Message-Id: <6E682912-BDE7-409E-A06A-1A034F505FFF@gmail.com> References: <1DA06950-D86A-466A-829C-4B3869C4D65A@employees.org> <0bcdfde5feed4ed4afa9732ec69015b6@XCH15-06-11.nw.nos.boeing.com> <2B824C71-AD8D-4B5E-834E-B158BCD1FEC8@gmail.com> <28e41b59e47b414aa31bb02fab145a33@XCH15-06-11.nw.nos.boeing.com> <63682210dc654683aacee48561774c12@XCH15-06-11.nw.nos.boeing.com> To: "Manfredi, Albert E" X-Mailer: Apple Mail (2.2104) Archived-At: Cc: IPv6 List , Bob Hinden X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 15 Jan 2016 01:32:09 -0000 --Apple-Mail=_648D62AC-30FA-4A5E-9944-9468FF55833E Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Bert, > On Jan 14, 2016, at 3:57 PM, Manfredi, Albert E = wrote: >=20 >> -----Original Message----- >> From: Bob Hinden [mailto:bob.hinden@gmail.com] >=20 >> How about: >>=20 >> Hop Limit 8-bit unsigned integer. Decremented by 1 by >> each node that forwards the packet. When >> forwarding, the packet is discarded if Hop >> Limit was zero when received or is = decremented >> to zero. A node that is the destination of = a >> packet should not discard a packet with hop >> limit equal to zero, it should process the >> packet normally. >>=20 >> Accomplishes the same thing and matches the style of the document. >=20 > It's a deal! Thanks. Thanks, will be in the next version. Bob >=20 > Bert >=20 --Apple-Mail=_648D62AC-30FA-4A5E-9944-9468FF55833E 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 - https://gpgtools.org iQEcBAEBCgAGBQJWmEwTAAoJEK7rdBF357uoKaIIAIWoWND210MSQ2Bfn2+aa+QS pByp1MXD9grU9og7NEupmt8DhMPkou7PCVwqP/MGHgpKuvb8Y4t2qZy8t/kSOQF5 wGEV6YP0NyM1XPvcl9mK8vznayra+pS3Eg8tQNzuVUwOlo3pT1ODP8PUoB996W4Q KTylkk8KIYkqGxZTczYYgGUVSccy+LFwovdphdjssafxAijCAdiko2qnWqKwFP+9 jhAHr+S6jm/D9IeXLiLgPU7YebyMJjcucZJIfefdxcGzV9nUnwaqbHgXMzbqITiW HJjUNlOmW3krPrj05PnnAXI79MpPNqUx1aa7RFHkLhUcsJdGmBBrVnFkipl+Afs= =AMsr -----END PGP SIGNATURE----- --Apple-Mail=_648D62AC-30FA-4A5E-9944-9468FF55833E-- From nobody Fri Jan 15 04:00:35 2016 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A8C631B2BAF for ; Fri, 15 Jan 2016 04:00:33 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.799 X-Spam-Level: X-Spam-Status: No, score=0.799 tagged_above=-999 required=5 tests=[BAYES_50=0.8, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, SPF_HELO_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Y7iXLKapnXYm for ; Fri, 15 Jan 2016 04:00:26 -0800 (PST) Received: from emea01-db3-obe.outbound.protection.outlook.com (mail-db3on0781.outbound.protection.outlook.com [IPv6:2a01:111:f400:fe04::781]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1A1101B2BB0 for ; Fri, 15 Jan 2016 04:00:24 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=btconnect.onmicrosoft.com; s=selector1-btconnect-com; h=From:To:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=pg9F9aQ6yhWisKaTW/z6xYvb7D8tnDtKEs7D5FDXqz4=; b=Iutruev95Kx1u9SBTfywL9tdSk0x213DYF29ZhRg46QYD5PccBEFfS+UTpAAlzQnGYOchL/nvC563aG0+SEfhgz1XM/iR3swi6y2p0oMq5uET8zw7z4Z35oc0bRXS8kIMYv1Yn9sng5rpD2cK6EZ8ZBdWPVHb7u86N8eanmkADA= Authentication-Results: spf=none (sender IP is ) smtp.mailfrom=ietfc@btconnect.com; Received: from pc6 (86.185.87.133) by AMXPR07MB054.eurprd07.prod.outlook.com (10.242.67.143) with Microsoft SMTP Server (TLS) id 15.1.365.19; Fri, 15 Jan 2016 12:00:00 +0000 Message-ID: <008d01d14f8b$e6760e00$4001a8c0@gateway.2wire.net> From: t.petch To: Bob Hinden , "Manfredi, Albert E" References: <1DA06950-D86A-466A-829C-4B3869C4D65A@employees.org> <0bcdfde5feed4ed4afa9732ec69015b6@XCH15-06-11.nw.nos.boeing.com> <2B824C71-AD8D-4B5E-834E-B158BCD1FEC8@gmail.com> <28e41b59e47b414aa31bb02fab145a33@XCH15-06-11.nw.nos.boeing.com> <63682210dc654683aacee48561774c12@XCH15-06-11.nw.nos.boeing.com> <6E682912-BDE7-409E-A06A-1A034F505FFF@gmail.com> Subject: Re: RFC2460bis hop limit text Date: Fri, 15 Jan 2016 11:56:31 +0000 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1106 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 X-Originating-IP: [86.185.87.133] X-ClientProxiedBy: AM3PR02CA0079.eurprd02.prod.outlook.com (25.163.180.47) To AMXPR07MB054.eurprd07.prod.outlook.com (10.242.67.143) X-Microsoft-Exchange-Diagnostics: 1; AMXPR07MB054; 2:yTmzif7oYs68N0ah5JLKXwwqG82vp4LW1me657knQ6rl4qFrdldtsip6YPAg4pMxgPsYZ5F7jRvIYhh2PjSxGqJpysfXQ0YE4l1O6K/k1tvhsDMGCljOPlgw1Od8BMl+9lObU+lkd8MHW0cpzq7+ew==; 3:ZblrdzE3dwOyvWboEIjsH97aF+2F4FBaPEJKTiKWFMKMsJ7hsigs9M9tfRopEztmZGg41dINwHwNGr9wbuSYKEh5ubmLb9onV9sbnWtHMJi9pjzokOaDREAT/k7d0rlU; 25:kdgYmtwhnQa3aT0yAASMoTuB5xziQSTZtAySVEAV93qUIvXZKF2auAYxhdo/jSpBbaxCNb19Fs3hUZY5VNBiE9a04fMSJJFihPD24j+u617D9nWG0hHrUyGkTQrXlGZglMcZPQwRC0KW9HPagwDzv7eWPMuZDzQ5I1GhPDk4LNaMjtKgW4rdrkMZAu2LNAS0FGIWDTwePEte+9H4nPFOXL8fWLC+QB8XcIO653BdkLjSaaIe/axpIfrqAVzU7KXV; 4:exLib8YXmEtIkhkgV8NFziOqcCYvUA9OLGfeYLMO7o0D832k8VDd18V1f9aBQO9lpLGkcAGyDhAdNVag2bYv9I8ZAyzNdPdpVvSvIW2UPS3I57vixOyytAWwRvtArlp+pEDFyd3sLbIlDlTbgZf76yN22zzKGhZGuB5vdUB+bsq3Ehsn6ho00qHLlHNBI6Tp0UTOb80MfN809n4WpX1hFqhNyPb4Ws7xpNCSLVMvbbcKSdBUHeG3LULj5kwvSV1RhX0hdIv1rLiEALACbubD7oUzIpYYz/jHBBuc+kgmoTc7bcoCjwiKsKEoeacdSbxFcc7mfD+pqamwq64ptxwRe/j5hEW5K4VMKq7Z5OHMQjpY57Jcjwi2K3A3UQsf0hrq X-Microsoft-Antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:AMXPR07MB054; X-MS-Office365-Filtering-Correlation-Id: 1661268d-0bd2-4cf6-b110-08d31da3687e X-Microsoft-Antispam-PRVS: X-Exchange-Antispam-Report-Test: UriScan:; X-Exchange-Antispam-Report-CFA-Test: BCL:0; PCL:0; RULEID:(601004)(2401047)(520078)(8121501046)(5005006)(10201501046)(3002001); SRVR:AMXPR07MB054; BCL:0; PCL:0; RULEID:; SRVR:AMXPR07MB054; X-Forefront-PRVS: 08220FA8D6 X-Forefront-Antispam-Report: SFV:NSPM; SFS:(10019020)(979002)(6009001)(199003)(189002)(13464003)(164054003)(51444003)(24454002)(377454003)(50466002)(62236002)(5001960100002)(122386002)(101416001)(3846002)(76176999)(50986999)(84392002)(1456003)(50226001)(44736004)(44716002)(14496001)(87976001)(81816999)(19580405001)(77096005)(92566002)(189998001)(97736004)(81156007)(5001770100001)(66066001)(5004730100002)(81686999)(47776003)(19580395003)(230700001)(1096002)(33646002)(1556002)(2906002)(586003)(116806002)(105586002)(40100003)(93886004)(61296003)(23756003)(106356001)(6116002)(4326007)(86362001)(42186005)(5008740100001)(7059030)(74416001)(7726001)(969003)(989001)(999001)(1009001)(1019001); DIR:OUT; SFP:1102; SCL:1; SRVR:AMXPR07MB054; H:pc6; FPR:; SPF:None; PTR:InfoNoRecords; A:0; MX:1; LANG:en; Received-SPF: None (protection.outlook.com: btconnect.com does not designate permitted sender hosts) X-Microsoft-Exchange-Diagnostics: =?iso-8859-1?Q?1; AMXPR07MB054; 23:12DpOCog9xnGQ2on+K2J84PMAQuuc88H1gfptyOE?= =?iso-8859-1?Q?AI6blyM3QgwWtF2SlMg7UVW6hzUc84AO5HT3EyEpWNLffPjr6qPRBOhIxQ?= =?iso-8859-1?Q?xNA5e/BohQ13QdUOmgQ6GlELNca2pcMARdHiAwDLCz5+pzTODJvvcvKWfA?= =?iso-8859-1?Q?e7czsDcZ6HxqRDd1Jj6rDTrhUIUvhSq9IC44h9zRTWRa6VKbx/LTX29CC2?= =?iso-8859-1?Q?syrtwcmqYyIe7ko9oQ3c/vlb6bN57D/0nFj4BioIimpntkdjmY+Ja3zeVd?= =?iso-8859-1?Q?wJ3VHhEujfnBJ+6GifOpy3xHmZpxwhoN0k5t4KMp13QS5y6eg6cf2dpr0q?= =?iso-8859-1?Q?Y9fA6zfllDVKiMC5XE2EgvT9gkAWXUlgVw4uB2W/Ckfl8WFnUWW2CFgXGv?= =?iso-8859-1?Q?Vdnqda4H8SpB8FZddx8ESSmw0GLsV+/bbJtjHRoGN55w/0xY2vEI2d5Zsu?= =?iso-8859-1?Q?SKcr+K4raFJzbeDO5sgyp+sLrFAGsuCCqK2skSrZkC893QtvQapaaB9TZr?= =?iso-8859-1?Q?9HRnUX+2G5YLnuDVzwTm3iTrakFDj5bnBogKY8CLx6mEGxvaQU5YrzTUe1?= =?iso-8859-1?Q?gTT9FT6TBYamtJQ2ruAVT/p+9nCp0+NJR9kgPDO7bdUoTfsuuvYYTb4+Q0?= =?iso-8859-1?Q?3nwd4gCb6Ml6n+Q7k46JU7v1YB3Zcf+0Ev20XXezB+nEOrQ2ndzeQS66cc?= =?iso-8859-1?Q?wuDrMMBgBwxvIKhlAF2xZmTL0jdxTBYfiNGcL0Qe/HVLebSSJqQTf7tbs1?= =?iso-8859-1?Q?9khbYfjZtjDQuSfyi8s9wp6H8xQ774hKQ4AJs0nXeN58DMr2M5RQfiOGuI?= =?iso-8859-1?Q?4U0Wwzm/wDLuRvF2dz9Pz5uLpdf1AJ1emj1zSYuePVs5wZZtxDXHr3+rRQ?= =?iso-8859-1?Q?8LXRI3FQE0AwlDF95PoeJ4HDmoPNybomzxuhRLhDwzs3v1OW0I3DEZYq/0?= =?iso-8859-1?Q?Q3EKp9xcNOw/VN3BRfu6vJ7717rAn6ZJqszVgjydy2+rkayy15qgQ0GTW1?= =?iso-8859-1?Q?qh9NnN72YSRP+qv4F6mA9KTFTA7faloA8GlW685b4aiEbPh15VqvCeugV1?= =?iso-8859-1?Q?qmoeNpVQqYy+WzSTJ5uPx/UteBbqmN6qM9Qd1Pf1tkuy9nAazUtDLYcWed?= =?iso-8859-1?Q?A+mBXczcxh2IxDJlZupzSAnVKyqZ7TYN2opWeLRbSc+wcGQc07WYTVcJXU?= =?iso-8859-1?Q?M7xvEq6M8YJVFMQXKQ/oUYOJIC3RJnYJ4sCddI82C/JXMVGO5XE0uSiTr4?= =?iso-8859-1?Q?swLzdAFIbRCG/K1plAPm+zem/5OPQqTUQ15KnN2kgP8n1d6HoY8e6OpKjN?= =?iso-8859-1?Q?53nkxZnqKCNY7KY1DmWVHs/IKbNu04e9Znv0sLHTNCPmcBF5p6NldS7nn6?= =?iso-8859-1?Q?JTQdsmC5eHnqUK1qAGthyC9wR8kRPNbqrw1o8/7HBktrMKQf1q/Nz3Cgb/?= =?iso-8859-1?Q?Sz4LMZiMtFlYAvZdp76EFA5nLJ5iD/ebnVWd7Pmlr0xsnVGqQIKF2X8bCu?= =?iso-8859-1?Q?2vHLqeZc0w7IOEqDUInIM5/z2OeIrkI7YNSX7/LO8JTvH4I1X0SrBjnalD?= =?iso-8859-1?Q?faSxzdJRdmKAVR4Ctn+rgr9CQ=3D?= X-Microsoft-Exchange-Diagnostics: 1; AMXPR07MB054; 5:kgO0H7zqKZrq2R4DJaNTQeSQg15pk6LTYoOWJjf2VFYB82E0FFgq7ohr4sOP34qi63lFjcKNsuDv601b5MzcUpKunoyXmFVL+9Nkuc4HobETLFnhJU3w3UFud6sWSBqLszhj4t31FhGXY4iabNgbCQ==; 24:26vzb20SbgklUMlEw7A5kGEl6gRRuy4CFH6j3pMYxvOQgWFJK18kjgmjpC8d7uU4wnb9sdA2CBbGwKSIuWd9un/7/9OaKoWQBCHNXkuZoJU= SpamDiagnosticOutput: 1:23 SpamDiagnosticMetadata: NSPM X-OriginatorOrg: btconnect.com X-MS-Exchange-CrossTenant-OriginalArrivalTime: 15 Jan 2016 12:00:00.7431 (UTC) X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted X-MS-Exchange-Transport-CrossTenantHeadersStamped: AMXPR07MB054 Archived-At: Cc: Bob Hinden , IPv6 List X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 15 Jan 2016 12:00:33 -0000 ----- Original Message ----- From: "Bob Hinden" To: "Manfredi, Albert E" Cc: "IPv6 List" ; "Bob Hinden" Sent: Friday, January 15, 2016 1:32 AM Bert, > On Jan 14, 2016, at 3:57 PM, Manfredi, Albert E wrote: > >> -----Original Message----- >> From: Bob Hinden [mailto:bob.hinden@gmail.com] > >> How about: >> >> Hop Limit 8-bit unsigned integer. Decremented by 1 by >> each node that forwards the packet. When >> forwarding, the packet is discarded if Hop >> Limit was zero when received or is decremented >> to zero. A node that is the destination of a >> packet should not discard a packet with hop >> limit equal to zero, it should process the >> packet normally. >> >> Accomplishes the same thing and matches the style of the document. > > It's a deal! Thanks. Thanks, will be in the next version. One ambiguity that I have never resolved is whether the decrementing is conceptually performed on the ingress or egress interface, or in a process between the two. I used to encounter, some time ago, routers that, by design, performed it on the egress interface and so emitted datagrams with a count of zero, and regarded themselves as conformant to the IPv4 specifications. I read the RFC and decided that I could not tell, just that it was clear that hosts should expect and process datagrams with a count of zero. Reading this thread I am left wondering; I think that the ambiguity is still there but that it probably does not matter. Tom Petch Bob > > Bert > From nobody Fri Jan 15 04:17:09 2016 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 089C01B2BF7 for ; Fri, 15 Jan 2016 04:17:08 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.002 X-Spam-Level: X-Spam-Status: No, score=-2.002 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uDmSVv91FtjX for ; Fri, 15 Jan 2016 04:17:01 -0800 (PST) Received: from cowbell.employees.org (cowbell.employees.org [IPv6:2001:1868:a000:17::142]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 64A261B2BEE for ; Fri, 15 Jan 2016 04:17:01 -0800 (PST) Received: from cowbell.employees.org (localhost [127.0.0.1]) by cowbell.employees.org (Postfix) with ESMTP id 6160FD7887; Fri, 15 Jan 2016 04:17:00 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=employees.org; h=subject :mime-version:content-type:from:in-reply-to:date:cc:message-id :references:to; s=selector1; bh=0vFTj/GIxcgmquy06EsLDAsQFI0=; b= nuwp7R2BjjVkDpkarUSsTWJ0dXL5nc99mdmiNISkdb6xVDFPtwVS77H1OCIuqaDc KuqtBJYB0mDQpKwdPdOnfJzdWNQvD6yOAFX1GbouOItQrKgnhDcBtQYjwepN6xtN UE9+jvBfiGT8+8DqDL+thj3k8TMOs5iYwtlOHuofs/E= DomainKey-Signature: a=rsa-sha1; c=nofws; d=employees.org; h=subject :mime-version:content-type:from:in-reply-to:date:cc:message-id :references:to; q=dns; s=selector1; b=SIErFkleXAcZPelClKtIim2+R5 GOZzPHoSlD0PycBiHF32ACIMsEXvL5QNB9m4qHybtl0ZGW+hBhVa15PAYfMx/Iu5 84NqjnHcNKnCc5NvYd6NYyVMe+O/Wdn/BGOY45zh8rYEqibwFfJQEK+CDo3oUi0L 9CbIIEk7F3qDnyjfQ= Received: from h.hanazo.no (cm-84.215.10.233.getinternet.no [84.215.10.233]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: otroan) by cowbell.employees.org (Postfix) with ESMTPSA id 741CBD7886; Fri, 15 Jan 2016 04:16:59 -0800 (PST) Received: from [IPv6:::1] (localhost [IPv6:::1]) by h.hanazo.no (Postfix) with ESMTP id AE000E48CDA; Fri, 15 Jan 2016 13:16:56 +0100 (CET) Subject: Re: RFC2460bis hop limit text Mime-Version: 1.0 (Mac OS X Mail 9.2 \(3112\)) Content-Type: multipart/signed; boundary="Apple-Mail=_C407E0D9-A686-417C-9B40-32593E9F1D26"; protocol="application/pgp-signature"; micalg=pgp-sha512 X-Pgp-Agent: GPGMail 2.6b2 From: otroan@employees.org X-Priority: 3 In-Reply-To: <008d01d14f8b$e6760e00$4001a8c0@gateway.2wire.net> Date: Fri, 15 Jan 2016 13:16:55 +0100 Message-Id: References: <1DA06950-D86A-466A-829C-4B3869C4D65A@employees.org> <0bcdfde5feed4ed4afa9732ec69015b6@XCH15-06-11.nw.nos.boeing.com> <2B824C71-AD8D-4B5E-834E-B158BCD1FEC8@gmail.com> <28e41b59e47b414aa31bb02fab145a33@XCH15-06-11.nw.nos.boeing.com> <63682210dc654683aacee48561774c12@XCH15-06-11.nw.nos.boeing.com> <6E682912-BDE7-409E-A06A-1A034F505FFF@gmail.com> <008d01d14f8b$e6760e00$4001a8c0@gateway.2wire.net> To: "t.petch" X-Mailer: Apple Mail (2.3112) Archived-At: Cc: 6man WG , Bob Hinden X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 15 Jan 2016 12:17:08 -0000 --Apple-Mail=_C407E0D9-A686-417C-9B40-32593E9F1D26 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Tom, >>> Hop Limit 8-bit unsigned integer. Decremented by 1 by >>> each node that forwards the packet. When >>> forwarding, the packet is discarded if Hop >>> Limit was zero when received or is > decremented >>> to zero. A node that is the destination of > a >>> packet should not discard a packet with hop >>> limit equal to zero, it should process the >>> packet normally. >>>=20 >>> Accomplishes the same thing and matches the style of the document. >>=20 >> It's a deal! Thanks. >=20 > Thanks, will be in the next version. >=20 > >=20 > One ambiguity that I have never resolved is whether the decrementing = is > conceptually performed on the ingress or egress interface, or in a > process between the two. I used to encounter, some time ago, routers > that, by design, performed it on the egress interface and so emitted > datagrams with a count of zero, and regarded themselves as conformant = to > the IPv4 specifications. I read the RFC and decided that I could not > tell, just that it was clear that hosts should expect and process > datagrams with a count of zero. >=20 > Reading this thread I am left wondering; I think that the ambiguity is > still there but that it probably does not matter. do you still see ambiguity in the above text? isn't "discarded if Hop Limit is decremented to zero" pretty clear? hosts have always been expected to process datagrams with TTL/HLIM of = zero, and routers have never been supposed to send them. cheers, Ole --Apple-Mail=_C407E0D9-A686-417C-9B40-32593E9F1D26 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 - https://gpgtools.org iQIcBAEBCgAGBQJWmOM4AAoJEL7aWKiYQt92y58P/3d8X16W9Bh3oFUr48h1VKv/ ABJqx3+ztDHyD/QZP9r2b+ZxOwmZ9SFRsB8H2unooTmu03eM6Qimxf4NkTjIakUk SFwx49ztrsDrQyOsbOZ/sDU64LwdXDH837nomvdOZfAGOMaWT7ic9teC0i4bR5BF ebsypRzuwdo7vB1TGEMRa89tRbUe6guGgxEWzLd2bwxE0KDdYATjmL7YU+ELJn9C UKtwPqqQukg04OxvIBRaPglRTXxzdzoUT6yxfzjFmpovbZMMCRqagdkEcM5e+ocw UgikdfgsZcTBpgfKBJukrbmvS/9TGJ7/iUn+/KKgTYn1aM2e1m+dqk+bn+WB/S9f sEUx1Vt7IB+7CMOTIzqix9PeZVJVVk9kBawFNlJwNLfx4zMktO1fdEomossmXDMk B/tI43ReuBUMhGe8G+WQKtMCRStZAAn3OeSWgxqUZxT3PN4PMlGPjVWz0wI3eoN3 IlCLUlIpD7hF7l/NQACYPMh07iFJT1uBny6BLxWbf/oMMkngdLCsSrduhX0q54lX 0l8g9DZTndLSH5NvG5PHqvWjhRq7OP8VBr5NIUF9D+9al17Ppu0Sg+csOmSqShvL GLLpqxUYWo/k1l5V3Xe3T0LCTZn6NLT6tq9G+7MvB8xeX1R/nGvgkkXlIHwjf8Hr NSP1J7lX44MsTwjp7Jle =0ERW -----END PGP SIGNATURE----- --Apple-Mail=_C407E0D9-A686-417C-9B40-32593E9F1D26-- From nobody Fri Jan 15 04:28:06 2016 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 80ADB1B2C18 for ; Fri, 15 Jan 2016 04:28:05 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.502 X-Spam-Level: X-Spam-Status: No, score=-14.502 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 85nBye8cAdSD for ; Fri, 15 Jan 2016 04:28:04 -0800 (PST) Received: from alln-iport-4.cisco.com (alln-iport-4.cisco.com [173.37.142.91]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 369F01B2BF8 for ; Fri, 15 Jan 2016 04:28:04 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2148; q=dns/txt; s=iport; t=1452860884; x=1454070484; h=from:to:subject:date:message-id:references:in-reply-to: content-transfer-encoding:mime-version; bh=KqB861CAuVDyoka3AvVDmKeKXzCEwWt4haPwjAzjXYw=; b=lLT8VoVfuJKbfQKlUOKOX+Wf3rqzmdN+LwYU3/OZDw/pDaUA3fD+f0vX asq8RR5qspot06oI71rAtuOwXgZveIr11u+jQzmuKJzlu1EaQefNU75nd Z+oQdjWvKerlSBsIdvSU7d3VduDsCCv1Vdmim6+vUBZAgpA9nFTelA72j o=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0D+AQBu5ZhW/5RdJa1egzqBPwaIUrMuA?= =?us-ascii?q?Q2BY4YPAoE0OBQBAQEBAQEBgQqENAEBAQQ6SwQCAQgRBAEBHwkHMhQJCAIEARI?= =?us-ascii?q?IiCHBFgEBAQEBAQEBAQEBAQEBAQEBAQEBGYZVhH+BPIJ1hQwFlxkBjVaPCI5cA?= =?us-ascii?q?SABAUKECnKEZ0KBCAEBAQ?= X-IronPort-AV: E=Sophos;i="5.22,299,1449532800"; d="scan'208";a="226959004" Received: from rcdn-core-12.cisco.com ([173.37.93.148]) by alln-iport-4.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 15 Jan 2016 12:27:52 +0000 Received: from XCH-ALN-001.cisco.com (xch-aln-001.cisco.com [173.36.7.11]) by rcdn-core-12.cisco.com (8.14.5/8.14.5) with ESMTP id u0FCRq6T000562 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Fri, 15 Jan 2016 12:27:52 GMT Received: from xch-rcd-001.cisco.com (173.37.102.11) by XCH-ALN-001.cisco.com (173.36.7.11) with Microsoft SMTP Server (TLS) id 15.0.1104.5; Fri, 15 Jan 2016 06:27:52 -0600 Received: from xch-rcd-001.cisco.com ([173.37.102.11]) by XCH-RCD-001.cisco.com ([173.37.102.11]) with mapi id 15.00.1104.009; Fri, 15 Jan 2016 06:27:52 -0600 From: "Pascal Thubert (pthubert)" To: "otroan@employees.org" , 6man WG Subject: RE: RFC2460bis hop limit text Thread-Topic: RFC2460bis hop limit text Thread-Index: AQHRTkWZpEDVZoM6KEqsmjX6QzByXJ78gSsQ Date: Fri, 15 Jan 2016 12:27:39 +0000 Deferred-Delivery: Fri, 15 Jan 2016 12:27:26 +0000 Message-ID: <2c6ca9e4b8444daaa1e5449c3f6cdd09@XCH-RCD-001.cisco.com> References: <1DA06950-D86A-466A-829C-4B3869C4D65A@employees.org> In-Reply-To: <1DA06950-D86A-466A-829C-4B3869C4D65A@employees.org> Accept-Language: fr-FR, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.60.6.31] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 15 Jan 2016 12:28:05 -0000 Hello Ole: Basically the text prevents a host to send a packet to another host on link= with TTL =3D=3D 0.=20 Seems that with the new text, the zero value becomes totally non-sensical, = a protocol error. I agree that's the best way to minimize the change to RFC= 2460 but it still looks like we're losing something. I'd have preferred a text that allows a router to route a packet only if it= is received with a non-zero TTL and forces the router to decrement the TTL= when doing so. =20 The same text saying nothing about hosts so a node could send and receive p= ackets with a 0 TTL, which is an alternate way to make sure that a packet d= oes not leave the link even if you do not have the LLA of the destination. Is that out of reach? Pascal > -----Original Message----- > From: ipv6 [mailto:ipv6-bounces@ietf.org] On Behalf Of > otroan@employees.org > Sent: mercredi 13 janvier 2016 22:01 > To: 6man WG > Subject: RFC2460bis hop limit text >=20 > After discussing a related issue with a forwarding implementation I'm wor= king > on, I think 2460bis hop limit text has an issue: >=20 > Hop Limit 8-bit unsigned integer. Decremented by 1 by > each node that forwards the packet. The > packet is discarded if Hop Limit is > decremented to zero, or is received with a > zero Hop Limit. >=20 > According to RFC1812 receiving a packet with TTL =3D 0 is perfectly fine. >=20 > I suggest we instead say something like: >=20 > Hop Limit 8-bit unsigned integer. Decremented by 1 by > each node that forwards the packet. The > packet is discarded if Hop Limit is > already zero or decremented to zero. >=20 > In addition add the note: (almost verbatim from 1812) > Note: A node must not discard a datagram just because it was received > with hop limit equal to zero or one; if it is to the node and otherwise > valid, the node must attempt to receive it. >=20 > Ole From nobody Fri Jan 15 04:40:08 2016 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6342A1A1EF5 for ; Fri, 15 Jan 2016 04:40:07 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.002 X-Spam-Level: X-Spam-Status: No, score=-2.002 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 90jVWfEx28d3 for ; Fri, 15 Jan 2016 04:40:05 -0800 (PST) Received: from cowbell.employees.org (cowbell.employees.org [65.50.211.142]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 991781A1B4B for ; Fri, 15 Jan 2016 04:40:05 -0800 (PST) Received: from cowbell.employees.org (localhost [127.0.0.1]) by cowbell.employees.org (Postfix) with ESMTP id 32993D7895; Fri, 15 Jan 2016 04:40:05 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=employees.org; h=subject :mime-version:content-type:from:in-reply-to:date:cc:message-id :references:to; s=selector1; bh=bdvQcYqYIMLL/NM+3ECs3EeY2w8=; b= HeoKRa1eM6po49GMlO042H8cqz95P87GlcfeJUukzkJrWSbxGWMFsfwFlGFj9EQb UgN7RhpoXobNAcwTfYWOuf5aEa/VkTTfU/C2jK/UtHlXSvbSKejbopLxyfGd18Ev 0FLYIxoJbfdp1WEQmp1Z4HKU9MI/XhsvBeTLk5Z32Dc= DomainKey-Signature: a=rsa-sha1; c=nofws; d=employees.org; h=subject :mime-version:content-type:from:in-reply-to:date:cc:message-id :references:to; q=dns; s=selector1; b=cEkwTwNzyRyfuZmwpxfu3T6JjM G56RVZMfBMIhc4RnXLA0SUzVv5xpMgrZa00XvtBtvJFjnBuEIypIlQodLEBvmza1 TCJY1HQK+KVpCMNUW3y96I+zVHYQ31GCHJt5pKq3lUCkTDVYld6w81EXO1k2N7i9 IM8hV20FQP27ZT4F0= Received: from h.hanazo.no (cm-84.215.10.233.getinternet.no [84.215.10.233]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: otroan) by cowbell.employees.org (Postfix) with ESMTPSA id E830AD7887; Fri, 15 Jan 2016 04:40:04 -0800 (PST) Received: from [IPv6:::1] (localhost [IPv6:::1]) by h.hanazo.no (Postfix) with ESMTP id 82183E4974B; Fri, 15 Jan 2016 13:40:00 +0100 (CET) Subject: Re: RFC2460bis hop limit text Mime-Version: 1.0 (Mac OS X Mail 9.2 \(3112\)) Content-Type: multipart/signed; boundary="Apple-Mail=_5A33C494-0414-4ED6-9FF4-1E62FE645BDD"; protocol="application/pgp-signature"; micalg=pgp-sha512 X-Pgp-Agent: GPGMail 2.6b2 From: otroan@employees.org In-Reply-To: <2c6ca9e4b8444daaa1e5449c3f6cdd09@XCH-RCD-001.cisco.com> Date: Fri, 15 Jan 2016 13:39:59 +0100 Message-Id: <07E018D6-AE95-4901-885B-4477E7186C98@employees.org> References: <1DA06950-D86A-466A-829C-4B3869C4D65A@employees.org> <2c6ca9e4b8444daaa1e5449c3f6cdd09@XCH-RCD-001.cisco.com> To: "Pascal Thubert (pthubert)" X-Mailer: Apple Mail (2.3112) Archived-At: Cc: 6man WG X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 15 Jan 2016 12:40:07 -0000 --Apple-Mail=_5A33C494-0414-4ED6-9FF4-1E62FE645BDD Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Pascal, > Basically the text prevents a host to send a packet to another host on = link with TTL =3D=3D 0. >=20 > Seems that with the new text, the zero value becomes totally = non-sensical, a protocol error. I agree that's the best way to minimize = the change to RFC 2460 but it still looks like we're losing something. >=20 > I'd have preferred a text that allows a router to route a packet only = if it is received with a non-zero TTL and forces the router to decrement = the TTL when doing so. >=20 > The same text saying nothing about hosts so a node could send and = receive packets with a 0 TTL, which is an alternate way to make sure = that a packet does not leave the link even if you do not have the LLA of = the destination. >=20 > Is that out of reach? sending with HLIM of 1 will also ensure that a packet does not leave the = link. cheers, Ole --Apple-Mail=_5A33C494-0414-4ED6-9FF4-1E62FE645BDD 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 - https://gpgtools.org iQIcBAEBCgAGBQJWmOigAAoJEL7aWKiYQt92TsIP/1mAQ8CIvlh7NKUt/D4qJoij KW6FfYiUQihFv9TxNhJmjj/7Pb9mFx+0d22okt401hFfcSyB4Gl/7p8z9GzqQpTR aANvaxMsykx8lAisw1gTHwYvxv7QpPgs50W8DM2ROvW8+Cm75e6vSHrc33+clHaH lYBZ4qZHQchoQvSOfcsUFzXkmpNLCVzGlY1zdyh1J4oV5+EDMJEDsoqIwucPxsmr VOasU4O9ywZ8KglR/736Tu6Goau1hKLU6EGxUio+8+OEM11A7baFzTMfkp+q3igN J8GzTr9+rWQUXMO9M7nO1vl3ZdwvDWicXKtKqhSO7BfsKw3BYx9IHE58wc49Vw0C ni/e30JoQGHHDx2aqt5mDohrWy2LYoLe4Wtt+amabpIoF/dFHXdT9DU+9Wlfq3D5 jt53VI3G3+sbuhpVH+eprLIK9CS6R546bDYZjrJvhcMBR4zw4blzxfJoOSl/ovRY RszXNL8tiA0jvXGS/iUxpBeogYaJkaMfKBEKJctrY5RJSIhj8LzzcOhfoLPJdcbz TLqij3cEfwCCe9GbE6kQsww6LQWw2ZXFvw5VvoOC1UyFuKjRLcoLJLS3/fyPhJ1s Dtv1p7A0aB5L9J9r4cZ2D6qFoYGLNMbcaDD4JvaUvl8rGGZ9GtSMNNUGvTx47dXX ipDpmMwhCih2za7n0XZL =o82q -----END PGP SIGNATURE----- --Apple-Mail=_5A33C494-0414-4ED6-9FF4-1E62FE645BDD-- From nobody Fri Jan 15 11:09:20 2016 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CB5921B3179 for ; Fri, 15 Jan 2016 11:09:19 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.978 X-Spam-Level: X-Spam-Status: No, score=-0.978 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FM_FORGED_GMAIL=0.622, FREEMAIL_FROM=0.001, MIME_8BIT_HEADER=0.3, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7SW1Pavxz8m0 for ; Fri, 15 Jan 2016 11:09:19 -0800 (PST) Received: from mail-ig0-x231.google.com (mail-ig0-x231.google.com [IPv6:2607:f8b0:4001:c05::231]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D796C1B3178 for ; Fri, 15 Jan 2016 11:09:18 -0800 (PST) Received: by mail-ig0-x231.google.com with SMTP id ik10so19470868igb.1 for ; Fri, 15 Jan 2016 11:09:18 -0800 (PST) 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=M+Gr+7/YTFIWYUGwltabcJfnRjlVI2aSDfimhaANgn0=; b=iFKN+Od61R9+UpDg3LJ7TUZMTTldoSrh0QQJrQlNyftD7u8S35ni+tYufziR8Qi3Fc lJZgIOeA9KdYks+EnBrO2H7GgfSxtl+hos7L6jrNOyV+TW/LEM7xb5e6rxL8gMH8HtKf ZdOOfPrhR0gR3oVtxt6ryv7iX1B0hZKgny2EqBBSxwthXxSpIcx1yBL2pxFbFw1grEBO ufGDIeZ5Lb7YM4QwQkbk/gc3fY5VpIFGC/5avYfA/IRngpuhAs4451XshQqCiYTI5KUx F/BltNwKWN54m/OYhS7IeubqUqF8zlVYNrM5XzMcYmktCZnnUQ4FhD4hIbLGE0eHGAQX HY5w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:sender:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=M+Gr+7/YTFIWYUGwltabcJfnRjlVI2aSDfimhaANgn0=; b=Rbe8rqzczcfw2hM44NNO1H+cM8wTLE9OdLkX0rfRuRXuAkKXr+qWRHlIdTpkArrDAK +m7ztpipNtGG5S1dsdmij5ul1jQ73JC2idKSe7YED0yowGJo4Cix4vo+Gu0bRYq65VrK foQRU2gcZU/vcCYGCdN00c1w2qSzQuQbQgzq1AEOMOPiyPuZPonfG8hbYs7fFG2nIIn9 zU/NslHTCV7Vo2dMCeQemagVeZC61LnRX0+BRxR+NKYrVpXyL+wFircM4S1IO7mYVIxP FQ5iz9B/mdEv+7CzFvDiGc6CHPj/0VVNUXshtLJs1+RolO1Mm3SRaRjJJ1Unr1boJD7I 7YDA== X-Gm-Message-State: AG10YOTTyi1HuRVf0akqPgUbocQt5Ewi8XqrMYb2pXw4CaFrx952vRKeSDwFNStgZHJ4yqql7+C1bfYlnZmvTw== MIME-Version: 1.0 X-Received: by 10.50.13.100 with SMTP id g4mr154559igc.64.1452884958298; Fri, 15 Jan 2016 11:09:18 -0800 (PST) Sender: jinmei.tatuya@gmail.com Received: by 10.107.129.80 with HTTP; Fri, 15 Jan 2016 11:09:18 -0800 (PST) In-Reply-To: <5698339D.5010203@si6networks.com> References: <7BEE06A2-0F6E-493F-B2C6-68DAB3774FD5@gmail.com> <5698339D.5010203@si6networks.com> Date: Fri, 15 Jan 2016 11:09:18 -0800 X-Google-Sender-Auth: JxsebR0IR7pyRteX7KPat3DHjrU Message-ID: Subject: Re: 6MAN WG Last Call - draft-ietf-6man-deprecate-atomfrag-generation From: =?UTF-8?B?56We5piO6YGU5ZOJ?= To: Fernando Gont Content-Type: text/plain; charset=UTF-8 Archived-At: Cc: IPv6 List , Bob Hinden X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 15 Jan 2016 19:09:20 -0000 At Thu, 14 Jan 2016 20:47:41 -0300, Fernando Gont wrote: > > I have a few comments on the 04 version however, which may better be > > addressed before the publication: > > > > - The title seems to be misleading to me. On starting to re-read the > > latest version almost forgetting past discussions, I first wondered > > why this is supposed to be "Informational" if it "deprecates" a > > standard feature. I then found it actually does not insist on > > deprecating it by updating RFC2460, merely saying the authors > > the believed atomic fragment is a bad idea. > > FWIW, this version documents the issues associated with atomic > fragments, and why such support is removed from RFC2460bis. Ah, okay. I now vaguely recall such discussions...in that case, it would make more sense to me that this document explains it more explicitly, referring to rfc2460bis. Then we probably don't have to adjust the document title. Any of the rest of the comments are rather subjective matters. After all, I'm not opposed to the conclusion per se, and the "unfair" (to me) facts are still facts anyway. So if it's only me who wish it to be more neutral/fair, I wouldn't insist on any changes. -- JINMEI, Tatuya From nobody Fri Jan 15 14:50:40 2016 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C4FFC1B3360 for ; Fri, 15 Jan 2016 14:50:39 -0800 (PST) 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=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YB-1YvxU9tbD for ; Fri, 15 Jan 2016 14:50:38 -0800 (PST) Received: from mail-qg0-x230.google.com (mail-qg0-x230.google.com [IPv6:2607:f8b0:400d:c04::230]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 222FF1B335E for ; Fri, 15 Jan 2016 14:50:38 -0800 (PST) Received: by mail-qg0-x230.google.com with SMTP id b35so389181861qge.0 for ; Fri, 15 Jan 2016 14:50:38 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=subject:mime-version:content-type:from:in-reply-to:date:cc :message-id:references:to; bh=wPL/MWzo/VcRgITpW861ti9BVBWLUQXzskQ3EZZ1s+A=; b=j3xcam7aB0/Dn+hYal+twEILJoe12Mepnup7jlUC2CzW6BJL+dO7UYn3hipIIgWR5t eSpyoYgWlkXKp+ZdhznsIjzG2MNPQmMiOZpSG45yK5Il29lq8aP+VEcUjJmXio5u9viY qLFIyUwR6VQZ36tTGzZDIcxcIA7vA0wKilo8D6//59jXaaswN4yW4HXJ/bUlUJIT+Gpg 68Ju16kLCyyK+fci34WU3h+88DZUVjjAdP6sMJOWaPYW7p+ZV+Ov4+j3K7JN66YQ36+q EqCGcr3+KCY0Ygg+HZ6PQtCRETJax+92V3eKzQTkeGuoQ5rfZFc51q6GHGi9qgAImmGn AZJQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:subject:mime-version:content-type:from :in-reply-to:date:cc:message-id:references:to; bh=wPL/MWzo/VcRgITpW861ti9BVBWLUQXzskQ3EZZ1s+A=; b=Z0oeDIfRJxJNLoHqkoCoaPn5fhUujp1Y8oIRMGgdETVA6AXSLHY2rhKEHTjDIr4CmY /puqZfIt+3QBL5XjE9H9g9j8xa1tRZAfISEV6NzdZ92bsWC1BK8TTme0DVyjIaT7dY7Z NQD1lJqpL6UVV2F2wiowhGi+xkSL880BFORDchDzpzUWL2bNQ2ulZHLbHLJo31YFlCYn ZUASfhF7xytEzIlCLal37nxjcnEE54yGg+OcD02PPvlWcpUMWt3/8a3ASvEAKy/IiaGJ rZkhFmvpy+aOrTpn9+zYYTcT93wQfNM2W2ER/xc1+yUxRg+VF1wlw0F8KruF9EoamMd0 F7yA== X-Gm-Message-State: ALoCoQnzTX1+TpRC9jP78PV27KIXnEqCGyWdm0t/HSyJtmvT9JWZzu1JOCNRBJx2DavE1jhR+jOEH7uslg/Anq+AxGYQTe+yew== X-Received: by 10.140.101.70 with SMTP id t64mr16450624qge.61.1452898237380; Fri, 15 Jan 2016 14:50:37 -0800 (PST) Received: from [172.16.224.219] ([209.97.127.34]) by smtp.gmail.com with ESMTPSA id t26sm5381522qkl.47.2016.01.15.14.50.35 (version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Fri, 15 Jan 2016 14:50:35 -0800 (PST) Subject: Re: RFC2460bis hop limit text Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2104\)) Content-Type: multipart/signed; boundary="Apple-Mail=_3EAF943F-1A9F-4AC8-B9CF-06999DF39BFB"; protocol="application/pgp-signature"; micalg=pgp-sha512 X-Pgp-Agent: GPGMail 2.5.2 From: Bob Hinden In-Reply-To: <2c6ca9e4b8444daaa1e5449c3f6cdd09@XCH-RCD-001.cisco.com> Date: Fri, 15 Jan 2016 14:50:32 -0800 Message-Id: <9E8580D8-CA6A-4688-ABC3-2D3A32D9015E@gmail.com> References: <1DA06950-D86A-466A-829C-4B3869C4D65A@employees.org> <2c6ca9e4b8444daaa1e5449c3f6cdd09@XCH-RCD-001.cisco.com> To: "Pascal Thubert (pthubert)" X-Mailer: Apple Mail (2.2104) Archived-At: Cc: IPv6 List , Bob Hinden X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 15 Jan 2016 22:50:39 -0000 --Apple-Mail=_3EAF943F-1A9F-4AC8-B9CF-06999DF39BFB Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Pascal, > On Jan 15, 2016, at 4:27 AM, Pascal Thubert (pthubert) = wrote: >=20 > Hello Ole: >=20 > Basically the text prevents a host to send a packet to another host on = link with TTL =3D=3D 0. >=20 > Seems that with the new text, the zero value becomes totally = non-sensical, a protocol error. I agree that's the best way to minimize = the change to RFC 2460 but it still looks like we're losing something. >=20 > I'd have preferred a text that allows a router to route a packet only = if it is received with a non-zero TTL and forces the router to decrement = the TTL when doing so. The current text does that: Decremented by 1 by each node that forwards the packet. The packet is not forwarded if Hop Limit is already zero when the packet arrives at the router, or becomes decremented to zero when traversing the router. Note the field is called =E2=80=9CHop Limit=E2=80=9D in IPv6. >=20 > The same text saying nothing about hosts so a node could send and = receive packets with a 0 TTL, which is an alternate way to make sure = that a packet does not leave the link even if you do not have the LLA of = the destination. This isn=E2=80=99t prohibited, but I don=E2=80=99t see this spec would = need to say anything about it. Bob --Apple-Mail=_3EAF943F-1A9F-4AC8-B9CF-06999DF39BFB 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 - https://gpgtools.org iQEcBAEBCgAGBQJWmXe5AAoJEK7rdBF357uovMMH/0Zgk1RrF76Ly0ESDspV5jo8 MxKJnmgPZ0MbixfPTtKoRnALH6+6YaEMr+57ICR7qvTfLWR3jDYhTfx23EyoHpJf 7q8q3uGTNRmcEM91pGQaibcYT58BJ2D97aoDTYkkz2dqPe/8VgqAZ5mPZ1DNPpfh EmCILe2rkCQiPyuTb4XFLc0dNEsQC4dOI0KcPqt9I55jTQk6UbDD7+l+tuYGc+S/ kQaUu8yfGMKXAvHPWpv2CrTdfpInfcPT+RwksD5zTW4M1rfoT8uir+aUBUY0QQeP +fapb7mr1wRLFoABK8BeOqc0JU02D+irEMGy2ARVe0mK+AHoRfUvHj0xXgbvnjY= =CNsg -----END PGP SIGNATURE----- --Apple-Mail=_3EAF943F-1A9F-4AC8-B9CF-06999DF39BFB-- From nobody Fri Jan 15 16:10:20 2016 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DF8CF1B341F for ; Fri, 15 Jan 2016 16:10:19 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.7 X-Spam-Level: X-Spam-Status: No, score=-1.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, MIME_8BIT_HEADER=0.3, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZleYiZ2YLh9Q for ; Fri, 15 Jan 2016 16:10:18 -0800 (PST) Received: from mail-io0-x236.google.com (mail-io0-x236.google.com [IPv6:2607:f8b0:4001:c06::236]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8690E1B3362 for ; Fri, 15 Jan 2016 16:10:18 -0800 (PST) Received: by mail-io0-x236.google.com with SMTP id q21so502854989iod.0 for ; Fri, 15 Jan 2016 16:10:18 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=subject:mime-version:content-type:from:in-reply-to:date:cc :message-id:references:to; bh=EAfZ6guZuOfQzIR/g9vYdWTq0LQIqMB1Gdl/LLh3Uls=; b=nel5UpxhMmFNj6jNAL6bptaBMxEP7zijn6+krRjQGoXsMAt7w90QD+wGE4YtCNhvmA 3tTnQs5oaZry/6ebTRWuWQez0ntZZvs1BGNeZLA96J7ggWl/WXH6zpj9DzIVsFZKO5tW yyRSXevxJ+dNA+ZKp5y4P451UtCeA6OauTJNguht7xuAqoN+b0yOpszG2zZr/NWghU6n HoktCa6xt++oJ/hh98eCZCsl3EeUl/ig1GS8OAlk3JP7xHuW2Nuj2iUxStBULe4sakzN TVTOI+Kre5lO2U4qPqpfF48Ic90g6r1st+tLdk5/OtBe38x89t7TowbCwDzMzc6KbNvL OjqQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:subject:mime-version:content-type:from :in-reply-to:date:cc:message-id:references:to; bh=EAfZ6guZuOfQzIR/g9vYdWTq0LQIqMB1Gdl/LLh3Uls=; b=fZlwVKDdUdh8+4Ue8W2QlHtHz6H8nwGvHEoC0E9sLBXhevmJ7GA3e0H96f7/FPSrQ0 bGHDmXKxk2xZhoM/PGCNUfDQIChhvR/q8C138fYBdUg3bzbqKUbczmRUMdISnopiLnWk WCABq2RVFeMSCIjALIfJVkZsdraA2WNuSlepuXsFIXXH9b4R+oihlHkBxh6P41LzG8ok D8gJAJGgj8OJHjKEoQodac4jzcZYzGD4z58K9uPsEHzFK8VPPEXS5gDYqdhEkxIlAfLY TxATmJvntUbu7ehM4ib9y3KnUOusch+cEvJ/3itJjql35X/GJuQn7PseLb4SGxgVjrXb VU9Q== X-Gm-Message-State: ALoCoQl1Bc4XZPb99/Me0hiGlUeMJK1rJyIWkJIeW4W+TQ/42dXe1gTHhQH4W78vxlyFaefeGqB5PLT3EFRKiPJPeFHKb2BU9Q== X-Received: by 10.107.8.135 with SMTP id h7mr12937241ioi.93.1452903017975; Fri, 15 Jan 2016 16:10:17 -0800 (PST) Received: from [172.16.224.219] ([209.97.127.34]) by smtp.gmail.com with ESMTPSA id v17sm5135403ioi.24.2016.01.15.16.10.16 (version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Fri, 15 Jan 2016 16:10:16 -0800 (PST) Subject: Re: 6MAN WG Last Call - draft-ietf-6man-deprecate-atomfrag-generation Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2104\)) Content-Type: multipart/signed; boundary="Apple-Mail=_70583AEA-7DB0-45E5-BD7E-2E6A1C48E520"; protocol="application/pgp-signature"; micalg=pgp-sha512 X-Pgp-Agent: GPGMail 2.5.2 From: Bob Hinden In-Reply-To: Date: Fri, 15 Jan 2016 16:10:13 -0800 Message-Id: <67950D21-A68A-41F9-96DB-B759F5B10E12@gmail.com> References: <7BEE06A2-0F6E-493F-B2C6-68DAB3774FD5@gmail.com> <5698339D.5010203@si6networks.com> To: =?utf-8?B?56We5piO6YGU5ZOJ?= X-Mailer: Apple Mail (2.2104) Archived-At: Cc: Fernando Gont , Bob Hinden , IPv6 List X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 16 Jan 2016 00:10:20 -0000 --Apple-Mail=_70583AEA-7DB0-45E5-BD7E-2E6A1C48E520 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Jinmei, > On Jan 15, 2016, at 11:09 AM, =E7=A5=9E=E6=98=8E=E9=81=94=E5=93=89 = wrote: >=20 > At Thu, 14 Jan 2016 20:47:41 -0300, > Fernando Gont wrote: >=20 >>> I have a few comments on the 04 version however, which may better be >>> addressed before the publication: >>>=20 >>> - The title seems to be misleading to me. On starting to re-read = the >>> latest version almost forgetting past discussions, I first wondered >>> why this is supposed to be "Informational" if it "deprecates" a >>> standard feature. I then found it actually does not insist on >>> deprecating it by updating RFC2460, merely saying the authors >>> the believed atomic fragment is a bad idea. >>=20 >> FWIW, this version documents the issues associated with atomic >> fragments, and why such support is removed from RFC2460bis. >=20 > Ah, okay. I now vaguely recall such discussions...in that case, it > would make more sense to me that this document explains it more > explicitly, referring to rfc2460bis. Then we probably don't have to > adjust the document title. I liked your idea of changing the title for the reasons you stated. = Someone who hasn=E2=80=99t read the discussions, will be confused. Bob >=20 > Any of the rest of the comments are rather subjective matters. After > all, I'm not opposed to the conclusion per se, and the "unfair" (to > me) facts are still facts anyway. So if it's only me who wish it to > be more neutral/fair, I wouldn't insist on any changes. >=20 > -- > JINMEI, Tatuya --Apple-Mail=_70583AEA-7DB0-45E5-BD7E-2E6A1C48E520 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 - https://gpgtools.org iQEcBAEBCgAGBQJWmYpmAAoJEK7rdBF357uo028H/jQpiEr9x3z0xYDStZnGtVk3 ADbPue2+a+nQPFAd7cOeTMF7H5fvIgIkPHkadX+iuHDv+JD7g13xxk8GxWpjmEpf JlHq6ASB9uhkCbEfuouMMltgIGyYEtp1LyAO5r+70yOrOSkRMV1Amz3ubMewo8Le STuRyja/acI10kPaFVJ0W3VgRFDBURCo/lL89VghxQlAK3oOm6Qj6Nf0zURP0XI7 REPiJMThAfKHAEL0FyiFOjIBwC/wzaHWAykcDW1DtQmAFxWoIAiFoPNbtkdpFFML mrxjrWvLAmt+ZLuQiMNrcteAcqBJ3z06y8s53XkrLiH9uF1OlibpjDE0XbOYn/A= =qbF0 -----END PGP SIGNATURE----- --Apple-Mail=_70583AEA-7DB0-45E5-BD7E-2E6A1C48E520-- From nobody Fri Jan 15 16:11:22 2016 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B62731B342F for ; Fri, 15 Jan 2016 16:11:20 -0800 (PST) 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=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id r78Y9EACD8u3 for ; Fri, 15 Jan 2016 16:11:19 -0800 (PST) Received: from mail-io0-x232.google.com (mail-io0-x232.google.com [IPv6:2607:f8b0:4001:c06::232]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6455D1B342D for ; Fri, 15 Jan 2016 16:11:19 -0800 (PST) Received: by mail-io0-x232.google.com with SMTP id g73so309323724ioe.3 for ; Fri, 15 Jan 2016 16:11:19 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=subject:mime-version:content-type:from:in-reply-to:date:cc :message-id:references:to; bh=Jccqs1rxFDoNs7I8A1yo05bn7AE++ihvixYGGCzdZQE=; b=BqVrgzpemdj1xR8uiRPZFnnC+YEEsVL/BlmZbz5KEVqio0OLKDbJWdb0zjkKBTdntX PDYKFa8JMRHAhVN2eUUJE+ywm79pYeUCy5xgAgL7bMJa3j3Xf2/kEI9SqYj7Vl58Q1+6 5mwPLDFyRwFbfZbaztpqubs8Kf7cSgP3Kyb+I5Zid1zs9AexcFL5Qo2nyc6bD0dA4s29 RSc8V+1IlPsHmQDfZcfEcAhxTza+++YLrKssuCZ76dZNbqoRmw60fErao8C2JSvUVaLd nGuPaLxbLTUohlzXHJ2JP8gqkRYL7hHjLksipziW0PqTEsL476+SmaaUz+B3BosQF3nJ Ar3w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:subject:mime-version:content-type:from :in-reply-to:date:cc:message-id:references:to; bh=Jccqs1rxFDoNs7I8A1yo05bn7AE++ihvixYGGCzdZQE=; b=Ax5A88X0KbhyiddgCGZlMkWcAF87nio7/KKR8ZTuPsG3Air2fFAs3rJ2GXK2asJJIc G5kVR4Dn2/k2WP0PfR1Hb4VYB/vK0eq6xVrfucreuoGFikUzecrS1aHcEMu2oQgqPab7 PkT22fhuoqr5qll0CpMMeg78hfMobR2oGrbZir8ic9tK4fShXTwzWSRtzlzx1TzzaeMN cXTI/DffDMbflr4M1xuX4Ol8d/ZE3T9MpNNEWAwMKmCHOLRbWlKFf7hPJrDwaJBaKGlo Uer/JmSUVfbySm2TsFPbXQQaT3ruGqxFNgybk5cBSaXn0++V1rv7RcbjDP4tzfBCP9XC P7IA== X-Gm-Message-State: ALoCoQm+i0ueoB7SgM9CrHlVk3NfxctRgNAkKDWtJ9gb/FNB5USA3Nlowg91LjVpr9T3+YSWMpK2yF443MoaSTt2S6duyn0ZXw== X-Received: by 10.107.166.85 with SMTP id p82mr12835705ioe.146.1452903078901; Fri, 15 Jan 2016 16:11:18 -0800 (PST) Received: from [172.16.224.219] ([209.97.127.34]) by smtp.gmail.com with ESMTPSA id v17sm5135403ioi.24.2016.01.15.16.11.17 (version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Fri, 15 Jan 2016 16:11:18 -0800 (PST) Subject: Re: Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2104\)) Content-Type: multipart/signed; boundary="Apple-Mail=_FA1B1CAF-EA84-4B1A-8E56-000DDEB651E4"; protocol="application/pgp-signature"; micalg=pgp-sha512 X-Pgp-Agent: GPGMail 2.5.2 From: Bob Hinden In-Reply-To: <021E64FECA7E5A4699562F4E6671648173AF36E8@XCH-PHX-503.sw.nos.boeing.com> Date: Fri, 15 Jan 2016 16:11:17 -0800 Message-Id: <21469FFA-4605-422A-9DE6-28BC2FE637B1@gmail.com> References: <20150804195752.5065.13523.idtracker@ietfa.amsl.com> <5671BA23.7010902@gmail.com> <5672EA99.5010908@si6networks.com> <56730530.7000309@gmail.com> <56731B9C.6050607@si6networks.com> <56735141.8070909@gmail.com> <567457F0.2080504@gmail.com> <5675A8B8.2040102@gmail.com> <021E64FECA7E5A4699562F4E6671648173AF36E8@XCH-PHX-503.sw.nos.boeing.com> To: IPv6 List X-Mailer: Apple Mail (2.2104) Archived-At: Cc: Bob Hinden X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 16 Jan 2016 00:11:20 -0000 --Apple-Mail=_FA1B1CAF-EA84-4B1A-8E56-000DDEB651E4 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 I have reviewed this email thread regarding the IID text. I generally = agree that we can do better than the current text regarding how IIDs are = created. Thanks for the suggestions. I will work on an update along = the lines as has been suggested. However, I am not comfortable removing the "Modified EUI-64=E2=80=9D = text altogether as part of advancing this spec to Internet Standard, I = think it better move it to an appendix. This document will obsolete = RFC4291 and we do have running code that uses the =E2=80=9CModified = EUI-64=E2=80=9D IIDs. I hope to have some new text for review early next week. Thanks, Bob --Apple-Mail=_FA1B1CAF-EA84-4B1A-8E56-000DDEB651E4 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 - https://gpgtools.org iQEcBAEBCgAGBQJWmYqlAAoJEK7rdBF357uoaPoIALI60EYFM36s46Jf08RVLi1O 3RmJHeZF54emYLHmHRM4C5Pda8gwDCZ38yWm3Dwu+XsdjnqeGu0C39yjjADnDcy/ Bsfwm6nKtDa7+/Xw89oSeTF0Jjj/I2uCCgCrF/g95IbZfQOLNd2R0kWLYl/uIKcm gwgABDBjXE4TzVp6cur1Ofz2KLmRyzOhmW/VjPkenM0DI67UZrjFNgYJ2jDwhUSr TXWwWIpjXKfF7A8qdjqX2cGaXv0a6aZxMYTYpJQenYtvah65bil+jlJnMAZIbNIJ cJRc6kSMoVdE9k630UDNSQ1Q/SPERFE3sYbiOUrqUWXPcyBZH0kuYknMZwkzViM= =HJOt -----END PGP SIGNATURE----- --Apple-Mail=_FA1B1CAF-EA84-4B1A-8E56-000DDEB651E4-- From nobody Fri Jan 15 23:18:57 2016 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 332E61A03A2 for ; Fri, 15 Jan 2016 23:18:56 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id P0iYo-NB1Asz for ; Fri, 15 Jan 2016 23:18:54 -0800 (PST) Received: from fgont.go6lab.si (fgont.go6lab.si [91.239.96.14]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3D8431A03A1 for ; Fri, 15 Jan 2016 23:18:54 -0800 (PST) Received: from [192.168.0.103] (unknown [190.49.56.115]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by fgont.go6lab.si (Postfix) with ESMTPSA id D4F1F2068A0; Sat, 16 Jan 2016 08:18:49 +0100 (CET) From: Fernando Gont Subject: Re: RFC2460bis hop limit text To: otroan@employees.org, 6man WG References: <1DA06950-D86A-466A-829C-4B3869C4D65A@employees.org> Message-ID: <5699E52A.8090907@si6networks.com> Date: Sat, 16 Jan 2016 03:37:30 -0300 User-Agent: Mozilla/5.0 (X11; Linux i686; rv:38.0) Gecko/20100101 Thunderbird/38.4.0 MIME-Version: 1.0 In-Reply-To: <1DA06950-D86A-466A-829C-4B3869C4D65A@employees.org> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit Archived-At: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 16 Jan 2016 07:18:56 -0000 Hi, Ole, On 01/13/2016 06:01 PM, otroan@employees.org wrote: > After discussing a related issue with a forwarding implementation I'm working on, I think 2460bis hop limit text has an issue: > > Hop Limit 8-bit unsigned integer. Decremented by 1 by > each node that forwards the packet. The > packet is discarded if Hop Limit is > decremented to zero, or is received with a > zero Hop Limit. > > According to RFC1812 receiving a packet with TTL = 0 is perfectly fine. > > I suggest we instead say something like: > > Hop Limit 8-bit unsigned integer. Decremented by 1 by > each node that forwards the packet. The > packet is discarded if Hop Limit is > already zero or decremented to zero. > > In addition add the note: (almost verbatim from 1812) > Note: A node must not discard a datagram just because it was received > with hop limit equal to zero or one; if it is to the node and otherwise > valid, the node must attempt to receive it. I agree the intent, but: This text you suggest: Hop Limit 8-bit unsigned integer. Decremented by 1 by each node that forwards the packet. The packet is discarded if Hop Limit is already zero or decremented to zero. Seems to convey the same meaning. Maybe you mean something like: ....the packet is discarded if a packet must be forwarded and the forwarding node finds that the Hop Limit is 0 or is decremented to zero. Thanks, -- Fernando Gont SI6 Networks e-mail: fgont@si6networks.com PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492 From nobody Fri Jan 15 23:19:07 2016 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5E5731A03E1 for ; Fri, 15 Jan 2016 23:19:05 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IixCiVNvapQf for ; Fri, 15 Jan 2016 23:19:03 -0800 (PST) Received: from fgont.go6lab.si (fgont.go6lab.si [91.239.96.14]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 36F911A03B3 for ; Fri, 15 Jan 2016 23:19:02 -0800 (PST) Received: from [192.168.0.103] (unknown [190.49.56.115]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by fgont.go6lab.si (Postfix) with ESMTPSA id ACF872068A0; Sat, 16 Jan 2016 08:18:58 +0100 (CET) Subject: Re: RFC2460bis hop limit text To: Bob Hinden , "Manfredi, Albert E" References: <1DA06950-D86A-466A-829C-4B3869C4D65A@employees.org> <0bcdfde5feed4ed4afa9732ec69015b6@XCH15-06-11.nw.nos.boeing.com> <2B824C71-AD8D-4B5E-834E-B158BCD1FEC8@gmail.com> <28e41b59e47b414aa31bb02fab145a33@XCH15-06-11.nw.nos.boeing.com> From: Fernando Gont X-Enigmail-Draft-Status: N1110 Message-ID: <5699E8B8.3030002@gont.com.ar> Date: Sat, 16 Jan 2016 03:52:40 -0300 User-Agent: Mozilla/5.0 (X11; Linux i686; rv:38.0) Gecko/20100101 Thunderbird/38.4.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit Archived-At: Cc: IPv6 List X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 16 Jan 2016 07:19:05 -0000 Hi, Bob, On 01/14/2016 08:51 PM, Bob Hinden wrote: > > s/TTL/Hop Limit/ :-) > > How about: > > Hop Limit 8-bit unsigned integer. Decremented by 1 by > each node that forwards the packet. When > forwarding, the packet is discarded if Hop > Limit was zero when received or is decremented > to zero. A node that is the destination of a > packet should not discard a packet with hop > limit equal to zero, it should process the > packet normally. > > Accomplishes the same thing and matches the style of the document. I'd probably s/it/but/ in "it should process the..." Thanks, -- Fernando Gont e-mail: fernando@gont.com.ar || fgont@si6networks.com PGP Fingerprint: 7809 84F5 322E 45C7 F1C9 3945 96EE A9EF D076 FFF1 From nobody Fri Jan 15 23:19:23 2016 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B44151A039E for ; Fri, 15 Jan 2016 23:19:21 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.601 X-Spam-Level: X-Spam-Status: No, score=-1.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, MIME_8BIT_HEADER=0.3, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CXuGsy0ryHeW for ; Fri, 15 Jan 2016 23:19:20 -0800 (PST) Received: from fgont.go6lab.si (fgont.go6lab.si [IPv6:2001:67c:27e4::14]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A4A6A1A039A for ; Fri, 15 Jan 2016 23:19:20 -0800 (PST) Received: from [192.168.0.103] (unknown [190.49.56.115]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by fgont.go6lab.si (Postfix) with ESMTPSA id B24282069BE; Sat, 16 Jan 2016 08:19:14 +0100 (CET) Subject: Re: 6MAN WG Last Call - draft-ietf-6man-deprecate-atomfrag-generation To: =?UTF-8?B?56We5piO6YGU5ZOJ?= References: <7BEE06A2-0F6E-493F-B2C6-68DAB3774FD5@gmail.com> <5698339D.5010203@si6networks.com> From: Fernando Gont X-Enigmail-Draft-Status: N1110 Message-ID: <5699EA87.30703@si6networks.com> Date: Sat, 16 Jan 2016 04:00:23 -0300 User-Agent: Mozilla/5.0 (X11; Linux i686; rv:38.0) Gecko/20100101 Thunderbird/38.4.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Archived-At: Cc: Bob Hinden , IPv6 List X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 16 Jan 2016 07:19:21 -0000 Hi, Jinmei, On 01/15/2016 04:09 PM, 神明é”哉 wrote: >>> I have a few comments on the 04 version however, which may better be >>> addressed before the publication: >>> >>> - The title seems to be misleading to me. On starting to re-read the >>> latest version almost forgetting past discussions, I first wondered >>> why this is supposed to be "Informational" if it "deprecates" a >>> standard feature. I then found it actually does not insist on >>> deprecating it by updating RFC2460, merely saying the authors >>> the believed atomic fragment is a bad idea. >> >> FWIW, this version documents the issues associated with atomic >> fragments, and why such support is removed from RFC2460bis. > > Ah, okay. I now vaguely recall such discussions...in that case, it > would make more sense to me that this document explains it more > explicitly, referring to rfc2460bis. Then we probably don't have to > adjust the document title. Will do. > Any of the rest of the comments are rather subjective matters. After > all, I'm not opposed to the conclusion per se, and the "unfair" (to > me) facts are still facts anyway. So if it's only me who wish it to > be more neutral/fair, I wouldn't insist on any changes. Okay. We'll try to tweak the text a bit anyway. Thanks so much! Best regards, -- Fernando Gont SI6 Networks e-mail: fgont@si6networks.com PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492 From nobody Sat Jan 16 00:10:54 2016 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 492521A1A83 for ; Sat, 16 Jan 2016 00:10:54 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.601 X-Spam-Level: X-Spam-Status: No, score=-1.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, MIME_8BIT_HEADER=0.3, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Q0FJDQXOz54H for ; Sat, 16 Jan 2016 00:10:53 -0800 (PST) Received: from fgont.go6lab.si (fgont.go6lab.si [91.239.96.14]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 646721A1A82 for ; Sat, 16 Jan 2016 00:10:53 -0800 (PST) Received: from [192.168.0.103] (unknown [190.49.56.115]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by fgont.go6lab.si (Postfix) with ESMTPSA id 8CAE62068A0; Sat, 16 Jan 2016 09:10:48 +0100 (CET) Subject: Re: 6MAN WG Last Call - draft-ietf-6man-deprecate-atomfrag-generation To: Bob Hinden , =?UTF-8?B?56We5piO6YGU5ZOJ?= References: <7BEE06A2-0F6E-493F-B2C6-68DAB3774FD5@gmail.com> <5698339D.5010203@si6networks.com> <67950D21-A68A-41F9-96DB-B759F5B10E12@gmail.com> From: Fernando Gont X-Enigmail-Draft-Status: N1110 Message-ID: <5699FAFE.9090908@si6networks.com> Date: Sat, 16 Jan 2016 05:10:38 -0300 User-Agent: Mozilla/5.0 (X11; Linux i686; rv:38.0) Gecko/20100101 Thunderbird/38.4.0 MIME-Version: 1.0 In-Reply-To: <67950D21-A68A-41F9-96DB-B759F5B10E12@gmail.com> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit Archived-At: Cc: IPv6 List X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 16 Jan 2016 08:10:54 -0000 Hi, Bob, On 01/15/2016 09:10 PM, Bob Hinden wrote: >> On Jan 15, 2016, at 11:09 AM, 神明é”哉 wrote: >> >> At Thu, 14 Jan 2016 20:47:41 -0300, >> Fernando Gont wrote: >> >>>> I have a few comments on the 04 version however, which may better be >>>> addressed before the publication: >>>> >>>> - The title seems to be misleading to me. On starting to re-read the >>>> latest version almost forgetting past discussions, I first wondered >>>> why this is supposed to be "Informational" if it "deprecates" a >>>> standard feature. I then found it actually does not insist on >>>> deprecating it by updating RFC2460, merely saying the authors >>>> the believed atomic fragment is a bad idea. >>> >>> FWIW, this version documents the issues associated with atomic >>> fragments, and why such support is removed from RFC2460bis. >> >> Ah, okay. I now vaguely recall such discussions...in that case, it >> would make more sense to me that this document explains it more >> explicitly, referring to rfc2460bis. Then we probably don't have to >> adjust the document title. > > I liked your idea of changing the title for the reasons you stated. Someone who hasn’t read the discussions, will be confused. Sounds reasonable. Which of the two options suggested by Jinmei should we apply? Thanks! Best regards, -- Fernando Gont SI6 Networks e-mail: fgont@si6networks.com PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492 From nobody Sat Jan 16 02:09:00 2016 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CE42D1A6F3F for ; Sat, 16 Jan 2016 02:08:59 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UNPIYCI-z0mc for ; Sat, 16 Jan 2016 02:08:58 -0800 (PST) Received: from fgont.go6lab.si (fgont.go6lab.si [91.239.96.14]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BA3211A6F3E for ; Sat, 16 Jan 2016 02:08:58 -0800 (PST) Received: from [192.168.0.103] (unknown [190.49.56.115]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by fgont.go6lab.si (Postfix) with ESMTPSA id 1A6B32069BF; Sat, 16 Jan 2016 11:08:49 +0100 (CET) Subject: Re: To: Bob Hinden , IPv6 List References: <20150804195752.5065.13523.idtracker@ietfa.amsl.com> <5671BA23.7010902@gmail.com> <5672EA99.5010908@si6networks.com> <56730530.7000309@gmail.com> <56731B9C.6050607@si6networks.com> <56735141.8070909@gmail.com> <567457F0.2080504@gmail.com> <5675A8B8.2040102@gmail.com> <021E64FECA7E5A4699562F4E6671648173AF36E8@XCH-PHX-503.sw.nos.boeing.com> <21469FFA-4605-422A-9DE6-28BC2FE637B1@gmail.com> From: Fernando Gont X-Enigmail-Draft-Status: N1110 Message-ID: <569A1413.3020709@si6networks.com> Date: Sat, 16 Jan 2016 06:57:39 -0300 User-Agent: Mozilla/5.0 (X11; Linux i686; rv:38.0) Gecko/20100101 Thunderbird/38.4.0 MIME-Version: 1.0 In-Reply-To: <21469FFA-4605-422A-9DE6-28BC2FE637B1@gmail.com> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 8bit Archived-At: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 16 Jan 2016 10:09:00 -0000 Hi, Bob, On 01/15/2016 09:11 PM, Bob Hinden wrote: > I have reviewed this email thread regarding the IID text. I > generally agree that we can do better than the current text regarding > how IIDs are created. Thanks for the suggestions. I will work on an > update along the lines as has been suggested. > > However, I am not comfortable removing the "Modified EUI-64” text > altogether as part of advancing this spec to Internet Standard, I > think it better move it to an appendix. This document will obsolete > RFC4291 and we do have running code that uses the “Modified EUI-64” > IIDs. I think that it's acceptable to leave text regarding Modified EUI-64 in an appendix. However, the main body should refer to default-iids regarding the details of how IIDs are generated. Thanks! Cheers, -- Fernando Gont SI6 Networks e-mail: fgont@si6networks.com PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492 From nobody Sat Jan 16 10:00:15 2016 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EEC891A9150 for ; Sat, 16 Jan 2016 10:00:12 -0800 (PST) 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=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gOpNTkqyHork for ; Sat, 16 Jan 2016 10:00:11 -0800 (PST) Received: from mail-qg0-x231.google.com (mail-qg0-x231.google.com [IPv6:2607:f8b0:400d:c04::231]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4403C1A914F for ; Sat, 16 Jan 2016 10:00:11 -0800 (PST) Received: by mail-qg0-x231.google.com with SMTP id b35so400657137qge.0 for ; Sat, 16 Jan 2016 10:00:11 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=subject:mime-version:content-type:from:in-reply-to:date:cc :message-id:references:to; bh=dE8CzEYO2hxz9IxlAakQ31Evw7OG4AdWNuJGxC2039A=; b=hRTGouQfPljAgS9ouUVHm5zYW7aO2pGiVqYzDilz/eBKH/1SlXGYvfiubigvp8smS1 MqkHd6MtvWXM6gONG6Z5KAL6gHThFtN7eFyXnffHNGGra6+sN2Fk7/FTcExK5+eaNUlL dBWe/LuZPKvc7lmtSbPeo4lzvnUgBMS9fN9s2OrPLshipXvNTCdtAZHLGzlSiixQJxKZ eL6BK61N+NUUp3nKSiiru6JG06y8TbK+XadrHpFGbRj/QtuW3YbRZpY67LMNjtnj0F8u WIkHLPD1IkyuGDPqAFW87MT8m1vYY3qtt9PN4m9O9rlqihWICk60H99kw+2wovklxQYd xwqg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:subject:mime-version:content-type:from :in-reply-to:date:cc:message-id:references:to; bh=dE8CzEYO2hxz9IxlAakQ31Evw7OG4AdWNuJGxC2039A=; b=Vf6ZV3tXC06HXHt6W9KxcxKRv2Xj87YNFo2hA6dMucMXyD0g4zhNlfijNuIFrjOKon Ldejm/Khwkeibk9wFtylyAX/cksvp2DHFFFVH8ZD3RdDdYwRrglAp8F4nNtBhEdthYPl zDQLHtFSSB7CNS9BQFXgC2P0JC9BUPSX24+xnnaQAvqX5M+WxsMi2MWWOozbDqeZeix8 gFmpKvhwWPIUyq0uNw9qL+bMEKPTwlCksSUBj+PS7nCAC+jd2O7KhtrO8pFCHdQG97L4 5MI3WO88EuOp0jguVTSF3wswPR1HrBe244SyJynk9MEIOwDYQgpScX28Pvwh12tLVD7R whCQ== X-Gm-Message-State: ALoCoQngXGPiMXhGC0L1zD3ttfO8SXvAgJa18PKAB8RCDtc/A5Bs09R/lmKv28KBACjCiyWTO99Xf5KSvg9miAGXtOVU98/t6Q== X-Received: by 10.140.221.17 with SMTP id r17mr22733358qhb.94.1452967210475; Sat, 16 Jan 2016 10:00:10 -0800 (PST) Received: from [10.0.0.24] (c-71-202-19-53.hsd1.ca.comcast.net. [71.202.19.53]) by smtp.gmail.com with ESMTPSA id a197sm6760634qhc.25.2016.01.16.10.00.09 (version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Sat, 16 Jan 2016 10:00:09 -0800 (PST) Subject: Re: 6MAN WG Last Call - draft-ietf-6man-deprecate-atomfrag-generation Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2104\)) Content-Type: multipart/signed; boundary="Apple-Mail=_0A887599-E543-489E-96D1-0BC271004B5E"; protocol="application/pgp-signature"; micalg=pgp-sha512 X-Pgp-Agent: GPGMail 2.5.2 From: Bob Hinden In-Reply-To: <5699FAFE.9090908@si6networks.com> Date: Sat, 16 Jan 2016 10:00:07 -0800 Message-Id: <487CE247-6EE4-4DE2-B981-279AE560CF47@gmail.com> References: <7BEE06A2-0F6E-493F-B2C6-68DAB3774FD5@gmail.com> <5698339D.5010203@si6networks.com> <67950D21-A68A-41F9-96DB-B759F5B10E12@gmail.com> <5699FAFE.9090908@si6networks.com> To: Fernando Gont X-Mailer: Apple Mail (2.2104) Archived-At: Cc: IPv6 List , Bob Hinden , =?utf-8?B?56We5piO6YGU5ZOJ?= X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 16 Jan 2016 18:00:13 -0000 --Apple-Mail=_0A887599-E543-489E-96D1-0BC271004B5E Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Fernando, > On Jan 16, 2016, at 12:10 AM, Fernando Gont = wrote: >=20 > Hi, Bob, >=20 > On 01/15/2016 09:10 PM, Bob Hinden wrote: >>> On Jan 15, 2016, at 11:09 AM, =E7=A5=9E=E6=98=8E=E9=81=94=E5=93=89 = wrote: >>>=20 >>> At Thu, 14 Jan 2016 20:47:41 -0300, >>> Fernando Gont wrote: >>>=20 >>>>> I have a few comments on the 04 version however, which may better = be >>>>> addressed before the publication: >>>>>=20 >>>>> - The title seems to be misleading to me. On starting to re-read = the >>>>> latest version almost forgetting past discussions, I first = wondered >>>>> why this is supposed to be "Informational" if it "deprecates" a >>>>> standard feature. I then found it actually does not insist on >>>>> deprecating it by updating RFC2460, merely saying the authors >>>>> the believed atomic fragment is a bad idea. >>>>=20 >>>> FWIW, this version documents the issues associated with atomic >>>> fragments, and why such support is removed from RFC2460bis. >>>=20 >>> Ah, okay. I now vaguely recall such discussions...in that case, it >>> would make more sense to me that this document explains it more >>> explicitly, referring to rfc2460bis. Then we probably don't have to >>> adjust the document title. >>=20 >> I liked your idea of changing the title for the reasons you stated. = Someone who hasn=E2=80=99t read the discussions, will be confused. >=20 > Sounds reasonable. Which of the two options suggested by Jinmei should > we apply? I could go either way, a slight preference for the second (that is, = harmful). Thanks, Bob Bob --Apple-Mail=_0A887599-E543-489E-96D1-0BC271004B5E 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 - https://gpgtools.org iQEcBAEBCgAGBQJWmoUnAAoJEK7rdBF357uoh3gH/28I5DWVh3nTTojpgyQErfpT lbbZ9jMYE7dLpJhnCOEMPI2KRXhA7MfyPci7jTfdvoaP1KMMYc7HneNsntVbFd47 TknOmYn1tk7jOpI/QBWQ+EPlA/egICdHs7UBAjk85L+5+w2NNbVkCJkc/wlG9JrN lNYJ+f0G8tgFBoPbE3iObgp7j56HPTFzkwWihL3nbQrOrXXFAVHM5UmPWfA46vCB ClzJ7N+LMYuhhmo4Eg55uBPvU0mNeXwh/UFLPOZabQzNTcqQOvpuGAbWGxHDxxns Mc/K6vTb/0YjDayGcRU99o0XTx8QUKc3ZIcd1Ei1MKMnd8hZ2NnOtyCCzPq89Mg= =QLcl -----END PGP SIGNATURE----- --Apple-Mail=_0A887599-E543-489E-96D1-0BC271004B5E-- From nobody Mon Jan 18 00:17:18 2016 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 75E341B3258 for ; Mon, 18 Jan 2016 00:17:17 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.399 X-Spam-Level: * X-Spam-Status: No, score=1.399 tagged_above=-999 required=5 tests=[BAYES_50=0.8, HTML_MESSAGE=0.001, J_CHICKENPOX_16=0.6, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AYjZYQDtxpcm for ; Mon, 18 Jan 2016 00:17:15 -0800 (PST) Received: from mx1.bupt.edu.cn (mx1.bupt.edu.cn [211.68.68.2]) by ietfa.amsl.com (Postfix) with ESMTP id 01B8B1B3257 for ; Mon, 18 Jan 2016 00:17:15 -0800 (PST) Received: from mx1.bupt.edu.cn (unknown [127.0.0.1]) by mx1.bupt.edu.cn (AnyMacro(G7)) with SMTP id 6FE7619F45F for ; Mon, 18 Jan 2016 16:17:13 +0800 (HKT) Received: from WeiGengyuPC (unknown [114.254.161.150]) by mx1.bupt.edu.cn (AnyMacro(G7)) with ESMTPA id 342E519F45D for ; Mon, 18 Jan 2016 16:17:13 +0800 (HKT) Message-ID: <09178529BD77411993873F761BE6F722@WeiGengyuPC> From: "weigengyu" To: Subject: draft-ietf-6man-default-iids-08 Date: Mon, 18 Jan 2016 16:17:14 +0800 Organization: BUPT MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_001D_01D1520B.B189EFE0" X-Priority: 3 X-MSMail-Priority: Normal Importance: Normal X-Mailer: Microsoft Windows Live Mail 16.4.3528.331 X-MimeOLE: Produced By Microsoft MimeOLE V16.4.3528.331 Archived-At: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 18 Jan 2016 08:17:17 -0000 ÕâÊÇÒ»·â MIME ¸ñʽµÄ¶à·½Óʼþ¡£ ------=_NextPart_000_001D_01D1520B.B189EFE0 Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: quoted-printable Hi,=20 I have a question about draft-ietf-6man-default-iids-08.=20 Whether an IPv6 address of a host would be changed? If it is, in what situations does the IPv6 address change?=20 In Page 3 of the draft,=20 =A1=B0As a result of the aforementioned issues, this document recommends the implementation of an alternative scheme ([RFC7217]) as the default stable IID generation scheme for SLAAC, such that the aforementioned issues are mitigated.=A1=B1 In Page 7 of RFC7212,=20 =A1=B0Compute a random (but stable) identifier with the expression: RID =3D F(Prefix, Net_Iface, Network_ID, DAD_Counter, secret_key)=A1=B1 And in page 9 of RFC7252, =A1=B02. The Interface Identifier is finally obtained by taking as many bits from the RID value (computed in the previous step) as necessary, starting from the least significant bit.=A1=B1=20 If a host which does not move is rebooted, whether its IPv6 address = changes? If a host move out and back, eg, leave home to go to an office in the = morning and get back in the evening,=20 whether its IPv6 address changes? =20 Regards, Gengyu WEI Network Technology Center School of Computer=20 Beijing University of Posts and Telecommunications ------=_NextPart_000_001D_01D1520B.B189EFE0 Content-Type: text/html; charset="gb2312" Content-Transfer-Encoding: quoted-printable
Hi,
 
I have a question about draft-ietf-6man-default-iids-08.
 
Whether an IPv6 address of a host would be changed?
If it is, in what situations does the IPv6 address change?
 
In Page 3 of the draft,
=A1=B0As a result of the aforementioned issues, this document = recommends
the implementation of an alternative scheme ([RFC7217]) as = the
default stable IID generation scheme for SLAAC, such that the
aforementioned issues are mitigated.=A1=B1
 
In Page 7 of RFC7212,
=A1=B0Compute a random (but stable) identifier with the = expression:
RID =3D F(Prefix, Net_Iface, Network_ID, DAD_Counter, = secret_key)=A1=B1
 
And in page 9 of RFC7252,
=A1=B02. The Interface Identifier is finally obtained by taking as = many
bits from the RID value (computed in the previous step) as
necessary, starting from the least significant bit.=A1=B1
 
 
If a host which does not move is rebooted, whether its IPv6 address = changes?
If a host move out and back, eg, leave home to go to an office in = the=20 morning and get back in the evening,
whether its IPv6 address changes?  
 
 
Regards,
 
Gengyu=20 WEI
Network Technology Center
School of Computer
Beijing = University of=20 Posts and Telecommunications
------=_NextPart_000_001D_01D1520B.B189EFE0-- From nobody Tue Jan 19 23:27:46 2016 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0BFF31A873C for ; Tue, 19 Jan 2016 23:27:46 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.601 X-Spam-Level: X-Spam-Status: No, score=-3.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, J_CHICKENPOX_35=0.6, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BfGDsH6PmuTE for ; Tue, 19 Jan 2016 23:27:43 -0800 (PST) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 194A91A8740 for ; Tue, 19 Jan 2016 23:27:41 -0800 (PST) Received: from 172.18.7.190 (EHLO lhreml402-hub.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id CHD15500; Wed, 20 Jan 2016 07:27:39 +0000 (GMT) Received: from lhreml704-cah.china.huawei.com (10.201.5.130) by lhreml402-hub.china.huawei.com (10.201.5.241) with Microsoft SMTP Server (TLS) id 14.3.235.1; Wed, 20 Jan 2016 07:27:38 +0000 Received: from SZXEMA412-HUB.china.huawei.com (10.82.72.71) by lhreml704-cah.china.huawei.com (10.201.5.130) with Microsoft SMTP Server (TLS) id 14.3.235.1; Wed, 20 Jan 2016 07:27:37 +0000 Received: from SZXEMA509-MBS.china.huawei.com ([169.254.2.243]) by SZXEMA412-HUB.china.huawei.com ([10.82.72.71]) with mapi id 14.03.0235.001; Wed, 20 Jan 2016 15:27:33 +0800 From: "Liushucheng (Will)" To: Tina Tsou , Fernando Gont Subject: RE: 6MAN WG Last Call - draft-ietf-6man-deprecate-atomfrag-generation Thread-Topic: 6MAN WG Last Call - draft-ietf-6man-deprecate-atomfrag-generation Thread-Index: AQHRNxa4EHl4eocyV0SccTcC9MUYMJ7rL50AgAIqqQCAAOSDgIABbYMAgAd0swCADRhcAA== Date: Wed, 20 Jan 2016 07:27:33 +0000 Message-ID: References: <7BEE06A2-0F6E-493F-B2C6-68DAB3774FD5@gmail.com> <568C775C.2030300@si6networks.com> <568E69AA.2090100@si6networks.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.66.78.84] Content-Type: multipart/alternative; boundary="_000_C9B5F12337F6F841B35C404CF0554ACB89666E9CSZXEMA509MBSchi_" MIME-Version: 1.0 X-CFilter-Loop: Reflected X-Mirapoint-Virus-RAPID-Raw: score=unknown(0), refid=str=0001.0A020206.569F36EB.0109, ss=1, re=0.000, recu=0.000, reip=0.000, cl=1, cld=1, fgs=0, ip=169.254.2.243, so=2013-06-18 04:22:30, dmn=2013-03-21 17:37:32 X-Mirapoint-Loop-Id: 2094197c4705d1ea19ae1ca744cb09c4 Archived-At: Cc: Bob Hinden , IPv6 List X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Jan 2016 07:27:46 -0000 --_000_C9B5F12337F6F841B35C404CF0554ACB89666E9CSZXEMA509MBSchi_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SGkgVGluYSwNCg0KDQoNClRoYW5rcyBmb3IgeW91ciBjb21tZW50cy4NCg0KDQoNClllcywgYSBu dW1iZXIgb2YgZm9sa3MgaGF2ZSBub3RlZCB0aGlzIG9uIHRoZSBsaXN0IGFuZCBvZmYtbGlzdC4g V2Ugd2lsbCBwdXQgYSBiaXQgbW9yZSBzdHJlc3Mgb24gaXQgaW4gdGhlIGRyYWZ0Lg0KDQpSZWdh cmRzLA0KV2lsbCAoU2h1Y2hlbmcgTElVKQ0KDQpGcm9tOiBpcHY2IFttYWlsdG86aXB2Ni1ib3Vu Y2VzQGlldGYub3JnXSBPbiBCZWhhbGYgT2YgVGluYSBUc291DQpTZW50OiBUdWVzZGF5LCBKYW51 YXJ5IDEyLCAyMDE2IDM6MjcgUE0NClRvOiBGZXJuYW5kbyBHb250DQpDYzogSVB2NiBMaXN0OyBC b2IgSGluZGVuDQpTdWJqZWN0OiBSZTogNk1BTiBXRyBMYXN0IENhbGwgLSBkcmFmdC1pZXRmLTZt YW4tZGVwcmVjYXRlLWF0b21mcmFnLWdlbmVyYXRpb24NCg0KRGVhciBhbGwsDQoNCkkgc3VwcG9y dCBwdWJsaWNhdGlvbiBvZiB0aGlzIGRvY3VtZW50Lg0KDQpTdWdnZXN0aW9uOiBQbGVhc2Ugbm90 ZSBlYXJsaWVyIGluIHRoaXMgZG9jdW1lbnQgdGhhdCBtYW55IHBvcHVsYXIgT1MgZG8gbm90IHN1 cHBvcnQgdGhlIGZ1bmN0aW9uYWxpdHkgYmVpbmcgZGVwcmVjYXRlZC4gVGhhdCBpcywgdGhlIGFm b3JlbWVudGlvbmVkIGZ1bmN0aW9uYWxpdHkgd2FzIG5ldmVyIHdpZGVseSBzdXBwb3J0ZWQuDQoN Cg0KVGhhbmsgeW91LA0KVGluYQ0KDQpPbiBUaHVyc2RheSwgSmFudWFyeSA3LCAyMDE2LCBGZXJu YW5kbyBHb250IDxmZ29udEBzaTZuZXR3b3Jrcy5jb208bWFpbHRvOmZnb250QHNpNm5ldHdvcmtz LmNvbT4+IHdyb3RlOg0KSGksIEVyaWMsDQoNCk9uIDAxLzA2LzIwMTYgMTI6NDcgUE0sIEVyaWMg VnluY2tlIChldnluY2tlKSB3cm90ZToNCj4gRmVybmFuZCAoYW5kIEJvYiksDQo+DQo+IEZpcnN0 IHRoYW5rcyBmb3IgeW91ciByZXBsaWVzLg0KPiAgKA0KPiBBYm91dCBQVEIgPiAxMjgwOiBJIGhh dmUgdG8gcmVhZCBSRkMyNDYwYmlzLCBidXQsIHRoZSAnb2xkJyBSRkMgMjQ2MA0KPiBzdGF0ZXMg dGhhdCB3aGVuIHRoZSBwYXRoIE1UVSBmb3Igb25lIGRlc3RpbmF0aW9uIGlzIHNtYWxsZXIgdGhh biB0aGUNCj4gcGh5c2ljYWwgTVRVLCB0aGVuIGVpdGhlciBmcmFnbWVudGF0aW9uIChiYWQpIG9y IGFwcGxpY2F0aW9uIChwcmVmZXJyZWQpDQo+IG11c3QgYWRhcHQuDQoNClRoYXQgY2FuJ3QgYmUg cG9zc2libGUuICBJZiBpdCB3YXMsIFBhdGgtTVRVIERpc2NvdmVyeSB3b3VsZCBiZSBpbXBvc3Np YmxlOg0KDQpZb3UgKmFsd2F5cyogc2VuZCBwYWNrZXRzIHNtYWxsZXIgdGhhbiB0aGUgcGh5c2lj YWwgTVRVLiBUaGVuIFBNVFUNCm9wZXJhdGVzIGJldHdlZW4gbWluKElQX01JTl9NVFUpIGFuZCBt aW4gKFBoeXNpY2FsX01UVSwgUGF0aC1NVFUpLg0KKHdoZXJlIElQX01JTl9NVFUgaXMgNjggZm9y IElQdjQgYW5kIDEyODAgZm9yIElQdjYpLg0KDQpXaGVuIHlvdSBlbXBsb3kgYSBwcm90b2NvbCB0 aGF0IGNhbiBzZWdtZW50IGRhdGEgKFRDUCwgU0NUUCwgZXRjKSB5b3UNCm5ldmVyIGZhbGwgYmFj ayB0byBmcmFnbWVudGF0aW9uICh0aGF0J3MgdGhlIHdob2xlIHBvaW50IG9mIGRvaW5nDQpQYXRo LU1UVSBEaXNjb3ZlcnkpLiBZb3UganVzdCBrZWVwIHNlZ21lbnRpbmcgdGhlIGFwcCBkYXRhIGF0 IHRoZQ0KdHJhbnNwb3J0IGxheWVyIGF0IGFwcHJvcHJpYXRlIGNodW5rIHNpemVzLg0KDQpJbiBJ UHY0LCB5b3UgbmV2ZXIgcmVkdWNlIHBhc3QgNjggYnl0ZXMuIEluIElQdjYsIHlvdSBuZXZlciBy ZWR1Y2UgcGFzdA0KMTI4MCBieXRlcy4gSG93ZXZlciwgUkZDMjQ2MCBzdXBwb3J0ZWQgYSBjb3Ju ZXIgY2FzZSB3aGVyZSBpZiB5b3Ugd2VyZQ0KdG8gcmVjZWl2ZSBhbiBJQ01QdjYgUFRCIDwgMTI4 MCwgeW91J2Qgbm90IHJlZHVjZSB0aGUgc2l6ZSBvZiB5b3VyIGRhdGENCmNodW5rLCBidXQganVz dCBzdGFydCBzZW5kaW5nIGF0b21pYyBmcmFnbWVudHMuDQoNCmRyYWZ0LWlldGYtNm1hbi1kZXBy ZWNhdGUtYXRvbWZyYWctZ2VuZXJhdGlvbiBkaXNjdXNzZXMgd2h5IHRoaXMgaXMgbm90DQphIGdv b2QgaWRlYS4gQnV0IHRoZSBzaG9ydCB2ZXJzaW9uIG9mIHRoZSBhbnN3ZXIgaXMgdGhhdCB5b3Ug ZG9uJ3Qgd2FudA0KdG8gZW1wbG95IGZyYWdtZW50YXRpb24gdW5sZXNzIHlvdSByZWFsbHkgaGF2 ZSB0by4gSGVuY2UsIGdlbmVyYXRpbmcNCmF0b21pYyBmcmFnbWVudHMgZG9lc24ndCBtYWtlIG11 Y2ggc2Vuc2UuDQoNCg0KPiBUbyBiZSBob25lc3QsIEkgZG8gbm90IGhhdmUgYW55IGRhdGEgYmFj a2luZyBob3cNCj4gaG9zdHMvYXBwbGljYXRpb25zIHJlYWN0IGluIHRoYXQgY2FzZS4gSWYgaG9z dHMgY29tbW9ubHkgZG8gZnJhZ21lbnRhdGlvbg0KPiBiZWNhdXNlIGFwcCBpcyBpZ25vcmFudCBv ZiB0aGUgTVRVLCB0aGVuIHRoZSBhdHRhY2sgaXMgYWxzbyBwb3NzaWJsZSBvbg0KPiBub24gYXRv bWljIGZyYWdtZW50Lg0KDQpXaGVuIGFuIGFwcCBlbXBsb3lzIFRDUCtQTVRVRCBvciB0aGUgbGlr ZSwgdGhleSB3b3VsZCBuZXZlciBlbXBsb3kNCmZyYWdtZW50YXRpb24sIG1vZHVsbyB0aGlzIGNv cm5lciBjYXNlLg0KDQoNCg0KPiBUaGVuLCB3ZSBhZ3JlZSBvbiB0aGUgZmFjdCB0aGF0IGZyYWdt ZW50YXRpb24gc2hvdWxkIHJlYWxseSBiZSBkaXNjb3VyYWdlZA0KPiBmb3Igc2VjdXJpdHkgYW5k IHBlcmZvcm1hbmNlIHJlYXNvbnMgOi0pIEFuZCB3ZSBhcmUgYWxzbyBpbiAndmlvbGVudCcNCj4g YWdyZWVtZW50IG9uIHRoZSBmYWN0IHRoYXQgdGhpcyBpcyByZWFsbHkgbm90IHNlY3VyZSB0byBh bGxvdyBhbnkgbm9kZSB0bw0KPiByZWR1Y2UgdGhlIE1UVSBiZXR3ZWVuIHR3byBvdGhlciBwYXJ0 aWVzLi4uIE9UT0ggbm90IGFuIGVhc3kgcHJvYmxlbSB0bw0KPiBmaXguDQoNClRoaXMgY2FzZSBp cyBhY3R1YWxseSBxdWl0ZSB3b3JzZSwgYmVjYXVzZSB5b3UncmUgbm90IHNpbXBseSByZWR1Y2lu Zw0KdGhlIE1UVSBiZXR3ZWVuIHR3byBub2RlcywgYnV0IGFsc28gdHJpZ2dlcmluZyBmcmFnbWVu dGF0aW9uLiBJTiBJUHY2LA0Kc2luY2UgdGhlIG1pbmltdW0gTVRVIGlzIHF1aXRlIGxhcmdlICgx MjgwIGJ5dGVzKSwgYW4gYXR0YWNrZXIgdGhhdA0KcmVkdWNlcyB0aGUgTVRVIGJldHdlZW4gdHdv IG5vZGUganVzdCBjYXVzZXMgYSBwZXJmb3JtYW5jZSBwZW5hbHR5IChraW5kDQpvZiBzbWFsbCBp ZiB0aGUgcmVhbCBQTVRVIHdhcyBlLmcuIDE1MDAgYnl0ZXMpLiBCVXQgYW4gYXR0YWNrZXIgdGhh dCBjYW4NCnRyaWdnZXIgdGhlIHVzZSBvZiBmcmFnbWVudGF0aW9uIG9wZW5zIHRoZSBkb29yIHRv IGEgbnVtYmVyIG9mDQpmcmFnbWVudGF0aW9uLWJhc2VkIGF0dGFja3MuLi4gYW5kLCBiZWNhdXNl IG9mIHRoZSB3aWRlc3ByZWFkIGZpbHRlcmluZw0Kb2YgSVB2NiBmcmFnbWVudHMsIGF0IHRpbWVz IGp1c3QgdHJpZ2dlcmluZyBmcmFnbWVudGF0aW9uIGFscmVhZHkNCnJlc3VsdHMgaW4gYSBEb1Mg c2NlbmFyaW8uDQoNClRoYW5rcyENCg0KQ2hlZXJzLA0KLS0NCkZlcm5hbmRvIEdvbnQNClNJNiBO ZXR3b3Jrcw0KZS1tYWlsOiBmZ29udEBzaTZuZXR3b3Jrcy5jb208amF2YXNjcmlwdDo7Pg0KUEdQ IEZpbmdlcnByaW50OiA2NjY2IDMxQzYgRDQ4NCA2M0IyIDhGQjEgRTNDNCBBRTI1IDBENTUgMUQ0 RSA3NDkyDQoNCg0KDQoNCi0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tDQpJRVRGIElQdjYgd29ya2luZyBncm91cCBtYWls aW5nIGxpc3QNCmlwdjZAaWV0Zi5vcmc8amF2YXNjcmlwdDo7Pg0KQWRtaW5pc3RyYXRpdmUgUmVx dWVzdHM6IGh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vaXB2Ng0KLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0NCg== --_000_C9B5F12337F6F841B35C404CF0554ACB89666E9CSZXEMA509MBSchi_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 5a6L5L2TOw0KCXBhbm9zZS0xOjIgMSA2IDAgMyAxIDEgMSAxIDE7fQ0KQGZvbnQtZmFjZQ0KCXtm b250LWZhbWlseToiQ2FtYnJpYSBNYXRoIjsNCglwYW5vc2UtMToyIDQgNSAzIDUgNCA2IDMgMiA0 O30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6Q2FsaWJyaTsNCglwYW5vc2UtMToyIDE1IDUg MiAyIDIgNCAzIDIgNDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OiJcQOWui+S9kyI7DQoJ cGFub3NlLTE6MiAxIDYgMCAzIDEgMSAxIDEgMTt9DQovKiBTdHlsZSBEZWZpbml0aW9ucyAqLw0K cC5Nc29Ob3JtYWwsIGxpLk1zb05vcm1hbCwgZGl2Lk1zb05vcm1hbA0KCXttYXJnaW46MGNtOw0K CW1hcmdpbi1ib3R0b206LjAwMDFwdDsNCglmb250LXNpemU6MTIuMHB0Ow0KCWZvbnQtZmFtaWx5 OuWui+S9kzt9DQphOmxpbmssIHNwYW4uTXNvSHlwZXJsaW5rDQoJe21zby1zdHlsZS1wcmlvcml0 eTo5OTsNCgljb2xvcjpibHVlOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0KYTp2aXNp dGVkLCBzcGFuLk1zb0h5cGVybGlua0ZvbGxvd2VkDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsN Cgljb2xvcjpwdXJwbGU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQpwLk1zb1BsYWlu VGV4dCwgbGkuTXNvUGxhaW5UZXh0LCBkaXYuTXNvUGxhaW5UZXh0DQoJe21zby1zdHlsZS1wcmlv cml0eTo5OTsNCgltc28tc3R5bGUtbGluazoi57qv5paH5pysIENoYXIiOw0KCW1hcmdpbjowY207 DQoJbWFyZ2luLWJvdHRvbTouMDAwMXB0Ow0KCWZvbnQtc2l6ZToxMC41cHQ7DQoJZm9udC1mYW1p bHk6IkNhbGlicmkiLHNhbnMtc2VyaWY7fQ0Kc3Bhbi5FbWFpbFN0eWxlMTcNCgl7bXNvLXN0eWxl LXR5cGU6cGVyc29uYWwtcmVwbHk7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLHNhbnMtc2VyaWY7 DQoJY29sb3I6IzFGNDk3RDt9DQpzcGFuLkNoYXINCgl7bXNvLXN0eWxlLW5hbWU6Iue6r+aWh+ac rCBDaGFyIjsNCgltc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJbXNvLXN0eWxlLWxpbms657qv5paH 5pysOw0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIixzYW5zLXNlcmlmO30NCi5Nc29DaHBEZWZhdWx0 DQoJe21zby1zdHlsZS10eXBlOmV4cG9ydC1vbmx5Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIixz YW5zLXNlcmlmO30NCkBwYWdlIFdvcmRTZWN0aW9uMQ0KCXtzaXplOjYxMi4wcHQgNzkyLjBwdDsN CgltYXJnaW46NzIuMHB0IDkwLjBwdCA3Mi4wcHQgOTAuMHB0O30NCmRpdi5Xb3JkU2VjdGlvbjEN Cgl7cGFnZTpXb3JkU2VjdGlvbjE7fQ0KLS0+PC9zdHlsZT48IS0tW2lmIGd0ZSBtc28gOV0+PHht bD4NCjxvOnNoYXBlZGVmYXVsdHMgdjpleHQ9ImVkaXQiIHNwaWRtYXg9IjEwMjYiIC8+DQo8L3ht bD48IVtlbmRpZl0tLT48IS0tW2lmIGd0ZSBtc28gOV0+PHhtbD4NCjxvOnNoYXBlbGF5b3V0IHY6 ZXh0PSJlZGl0Ij4NCjxvOmlkbWFwIHY6ZXh0PSJlZGl0IiBkYXRhPSIxIiAvPg0KPC9vOnNoYXBl bGF5b3V0PjwveG1sPjwhW2VuZGlmXS0tPg0KPC9oZWFkPg0KPGJvZHkgbGFuZz0iWkgtQ04iIGxp bms9ImJsdWUiIHZsaW5rPSJwdXJwbGUiPg0KPGRpdiBjbGFzcz0iV29yZFNlY3Rpb24xIj4NCjxw IGNsYXNzPSJNc29QbGFpblRleHQiPjxzcGFuIGxhbmc9IkVOLVVTIj5IaSBUaW5hLDxvOnA+PC9v OnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPjxzcGFuIGxhbmc9IkVOLVVT Ij48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij48 c3BhbiBsYW5nPSJFTi1VUyI+VGhhbmtzIGZvciB5b3VyIGNvbW1lbnRzLiA8bzpwPjwvbzpwPjwv c3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij48c3BhbiBsYW5nPSJFTi1VUyI+PG86 cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+PHNwYW4g bGFuZz0iRU4tVVMiPlllcywgYSBudW1iZXIgb2YgZm9sa3MgaGF2ZSBub3RlZCB0aGlzIG9uIHRo ZSBsaXN0IGFuZCBvZmYtbGlzdC4gV2Ugd2lsbCBwdXQgYSBiaXQgbW9yZSBzdHJlc3Mgb24gaXQg aW4gdGhlIGRyYWZ0LjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtmb250LWZhbWlseTom cXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8 L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9InRleHQtYWxpZ246 anVzdGlmeTt0ZXh0LWp1c3RpZnk6aW50ZXItaWRlb2dyYXBoIj48c3BhbiBsYW5nPSJFTi1VUyIg c3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90Oyxz YW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPlJlZ2FyZHMsPG86cD48L286cD48L3NwYW4+PC9wPg0K PHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9InRleHQtYWxpZ246anVzdGlmeTt0ZXh0LWp1c3Rp Znk6aW50ZXItaWRlb2dyYXBoIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZTox MC41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMx RjQ5N0QiPldpbGwgKFNodWNoZW5nIExJVSk8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7 Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0Qi PjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxkaXYgc3R5bGU9ImJvcmRlcjpub25lO2Jv cmRlci1sZWZ0OnNvbGlkIGJsdWUgMS41cHQ7cGFkZGluZzowY20gMGNtIDBjbSA0LjBwdCI+DQo8 ZGl2Pg0KPGRpdiBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLXRvcDpzb2xpZCAjRTFFMUUxIDEu MHB0O3BhZGRpbmc6My4wcHQgMGNtIDBjbSAwY20iPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGI+ PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZx dW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZiI+RnJvbTo8L3NwYW4+PC9iPjxzcGFuIGxhbmc9 IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJp JnF1b3Q7LHNhbnMtc2VyaWYiPiBpcHY2IFttYWlsdG86aXB2Ni1ib3VuY2VzQGlldGYub3JnXQ0K PGI+T24gQmVoYWxmIE9mIDwvYj5UaW5hIFRzb3U8YnI+DQo8Yj5TZW50OjwvYj4gVHVlc2RheSwg SmFudWFyeSAxMiwgMjAxNiAzOjI3IFBNPGJyPg0KPGI+VG86PC9iPiBGZXJuYW5kbyBHb250PGJy Pg0KPGI+Q2M6PC9iPiBJUHY2IExpc3Q7IEJvYiBIaW5kZW48YnI+DQo8Yj5TdWJqZWN0OjwvYj4g UmU6IDZNQU4gV0cgTGFzdCBDYWxsIC0gZHJhZnQtaWV0Zi02bWFuLWRlcHJlY2F0ZS1hdG9tZnJh Zy1nZW5lcmF0aW9uPG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bh bj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyI+RGVhciBhbGws PG86cD48L286cD48L3NwYW4+PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFu IGxhbmc9IkVOLVVTIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6 ZToxMC4wcHQiPkkgc3VwcG9ydCBwdWJsaWNhdGlvbiBvZiB0aGlzIGRvY3VtZW50Ljxicj4NCjxi cj4NClN1Z2dlc3Rpb246IFBsZWFzZSBub3RlIGVhcmxpZXIgaW4gdGhpcyBkb2N1bWVudCB0aGF0 IG1hbnkgcG9wdWxhciBPUyBkbyZuYnNwO25vdCBzdXBwb3J0IHRoZSBmdW5jdGlvbmFsaXR5IGJl aW5nIGRlcHJlY2F0ZWQuIFRoYXQgaXMsIHRoZSZuYnNwO2Fmb3JlbWVudGlvbmVkIGZ1bmN0aW9u YWxpdHkgd2FzIG5ldmVyIHdpZGVseSBzdXBwb3J0ZWQuPC9zcGFuPjxzcGFuIGxhbmc9IkVOLVVT Ij48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj48c3BhbiBsYW5nPSJFTi1VUyI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPC9k aXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiPjxvOnA+ Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdCI+VGhhbmsgeW91 LDwvc3Bhbj48c3BhbiBsYW5nPSJFTi1VUyI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+ DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJm b250LXNpemU6MTAuMHB0Ij5UaW5hPGJyPg0KPC9zcGFuPjxzcGFuIGxhbmc9IkVOLVVTIj48YnI+ DQpPbiBUaHVyc2RheSwgSmFudWFyeSA3LCAyMDE2LCBGZXJuYW5kbyBHb250ICZsdDs8YSBocmVm PSJtYWlsdG86ZmdvbnRAc2k2bmV0d29ya3MuY29tIj5mZ29udEBzaTZuZXR3b3Jrcy5jb208L2E+ Jmd0OyB3cm90ZTo8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8YmxvY2txdW90ZSBzdHlsZT0iYm9y ZGVyOm5vbmU7Ym9yZGVyLWxlZnQ6c29saWQgI0NDQ0NDQyAxLjBwdDtwYWRkaW5nOjBjbSAwY20g MGNtIDYuMHB0O21hcmdpbi1sZWZ0OjQuOHB0O21hcmdpbi1yaWdodDowY20iPg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiPkhpLCBFcmljLDxicj4NCjxicj4NCk9uIDAx LzA2LzIwMTYgMTI6NDcgUE0sIEVyaWMgVnluY2tlIChldnluY2tlKSB3cm90ZTo8YnI+DQomZ3Q7 IEZlcm5hbmQgKGFuZCBCb2IpLDxicj4NCiZndDs8YnI+DQomZ3Q7IEZpcnN0IHRoYW5rcyBmb3Ig eW91ciByZXBsaWVzLjxicj4NCiZndDsmbmJzcDsgKDxicj4NCiZndDsgQWJvdXQgUFRCICZndDsg MTI4MDogSSBoYXZlIHRvIHJlYWQgUkZDMjQ2MGJpcywgYnV0LCB0aGUgJ29sZCcgUkZDIDI0NjA8 YnI+DQomZ3Q7IHN0YXRlcyB0aGF0IHdoZW4gdGhlIHBhdGggTVRVIGZvciBvbmUgZGVzdGluYXRp b24gaXMgc21hbGxlciB0aGFuIHRoZTxicj4NCiZndDsgcGh5c2ljYWwgTVRVLCB0aGVuIGVpdGhl ciBmcmFnbWVudGF0aW9uIChiYWQpIG9yIGFwcGxpY2F0aW9uIChwcmVmZXJyZWQpPGJyPg0KJmd0 OyBtdXN0IGFkYXB0Ljxicj4NCjxicj4NClRoYXQgY2FuJ3QgYmUgcG9zc2libGUuJm5ic3A7IElm IGl0IHdhcywgUGF0aC1NVFUgRGlzY292ZXJ5IHdvdWxkIGJlIGltcG9zc2libGU6PGJyPg0KPGJy Pg0KWW91ICphbHdheXMqIHNlbmQgcGFja2V0cyBzbWFsbGVyIHRoYW4gdGhlIHBoeXNpY2FsIE1U VS4gVGhlbiBQTVRVPGJyPg0Kb3BlcmF0ZXMgYmV0d2VlbiBtaW4oSVBfTUlOX01UVSkgYW5kIG1p biAoUGh5c2ljYWxfTVRVLCBQYXRoLU1UVSkuPGJyPg0KKHdoZXJlIElQX01JTl9NVFUgaXMgNjgg Zm9yIElQdjQgYW5kIDEyODAgZm9yIElQdjYpLjxicj4NCjxicj4NCldoZW4geW91IGVtcGxveSBh IHByb3RvY29sIHRoYXQgY2FuIHNlZ21lbnQgZGF0YSAoVENQLCBTQ1RQLCBldGMpIHlvdTxicj4N Cm5ldmVyIGZhbGwgYmFjayB0byBmcmFnbWVudGF0aW9uICh0aGF0J3MgdGhlIHdob2xlIHBvaW50 IG9mIGRvaW5nPGJyPg0KUGF0aC1NVFUgRGlzY292ZXJ5KS4gWW91IGp1c3Qga2VlcCBzZWdtZW50 aW5nIHRoZSBhcHAgZGF0YSBhdCB0aGU8YnI+DQp0cmFuc3BvcnQgbGF5ZXIgYXQgYXBwcm9wcmlh dGUgY2h1bmsgc2l6ZXMuPGJyPg0KPGJyPg0KSW4gSVB2NCwgeW91IG5ldmVyIHJlZHVjZSBwYXN0 IDY4IGJ5dGVzLiBJbiBJUHY2LCB5b3UgbmV2ZXIgcmVkdWNlIHBhc3Q8YnI+DQoxMjgwIGJ5dGVz LiBIb3dldmVyLCBSRkMyNDYwIHN1cHBvcnRlZCBhIGNvcm5lciBjYXNlIHdoZXJlIGlmIHlvdSB3 ZXJlPGJyPg0KdG8gcmVjZWl2ZSBhbiBJQ01QdjYgUFRCICZsdDsgMTI4MCwgeW91J2Qgbm90IHJl ZHVjZSB0aGUgc2l6ZSBvZiB5b3VyIGRhdGE8YnI+DQpjaHVuaywgYnV0IGp1c3Qgc3RhcnQgc2Vu ZGluZyBhdG9taWMgZnJhZ21lbnRzLjxicj4NCjxicj4NCmRyYWZ0LWlldGYtNm1hbi1kZXByZWNh dGUtYXRvbWZyYWctZ2VuZXJhdGlvbiBkaXNjdXNzZXMgd2h5IHRoaXMgaXMgbm90PGJyPg0KYSBn b29kIGlkZWEuIEJ1dCB0aGUgc2hvcnQgdmVyc2lvbiBvZiB0aGUgYW5zd2VyIGlzIHRoYXQgeW91 IGRvbid0IHdhbnQ8YnI+DQp0byBlbXBsb3kgZnJhZ21lbnRhdGlvbiB1bmxlc3MgeW91IHJlYWxs eSBoYXZlIHRvLiBIZW5jZSwgZ2VuZXJhdGluZzxicj4NCmF0b21pYyBmcmFnbWVudHMgZG9lc24n dCBtYWtlIG11Y2ggc2Vuc2UuPGJyPg0KPGJyPg0KPGJyPg0KJmd0OyBUbyBiZSBob25lc3QsIEkg ZG8gbm90IGhhdmUgYW55IGRhdGEgYmFja2luZyBob3c8YnI+DQomZ3Q7IGhvc3RzL2FwcGxpY2F0 aW9ucyByZWFjdCBpbiB0aGF0IGNhc2UuIElmIGhvc3RzIGNvbW1vbmx5IGRvIGZyYWdtZW50YXRp b248YnI+DQomZ3Q7IGJlY2F1c2UgYXBwIGlzIGlnbm9yYW50IG9mIHRoZSBNVFUsIHRoZW4gdGhl IGF0dGFjayBpcyBhbHNvIHBvc3NpYmxlIG9uPGJyPg0KJmd0OyBub24gYXRvbWljIGZyYWdtZW50 Ljxicj4NCjxicj4NCldoZW4gYW4gYXBwIGVtcGxveXMgVENQJiM0MztQTVRVRCBvciB0aGUgbGlr ZSwgdGhleSB3b3VsZCBuZXZlciBlbXBsb3k8YnI+DQpmcmFnbWVudGF0aW9uLCBtb2R1bG8gdGhp cyBjb3JuZXIgY2FzZS48YnI+DQo8YnI+DQo8YnI+DQo8YnI+DQomZ3Q7IFRoZW4sIHdlIGFncmVl IG9uIHRoZSBmYWN0IHRoYXQgZnJhZ21lbnRhdGlvbiBzaG91bGQgcmVhbGx5IGJlIGRpc2NvdXJh Z2VkPGJyPg0KJmd0OyBmb3Igc2VjdXJpdHkgYW5kIHBlcmZvcm1hbmNlIHJlYXNvbnMgOi0pIEFu ZCB3ZSBhcmUgYWxzbyBpbiAndmlvbGVudCc8YnI+DQomZ3Q7IGFncmVlbWVudCBvbiB0aGUgZmFj dCB0aGF0IHRoaXMgaXMgcmVhbGx5IG5vdCBzZWN1cmUgdG8gYWxsb3cgYW55IG5vZGUgdG88YnI+ DQomZ3Q7IHJlZHVjZSB0aGUgTVRVIGJldHdlZW4gdHdvIG90aGVyIHBhcnRpZXMuLi4gT1RPSCBu b3QgYW4gZWFzeSBwcm9ibGVtIHRvPGJyPg0KJmd0OyBmaXguPGJyPg0KPGJyPg0KVGhpcyBjYXNl IGlzIGFjdHVhbGx5IHF1aXRlIHdvcnNlLCBiZWNhdXNlIHlvdSdyZSBub3Qgc2ltcGx5IHJlZHVj aW5nPGJyPg0KdGhlIE1UVSBiZXR3ZWVuIHR3byBub2RlcywgYnV0IGFsc28gdHJpZ2dlcmluZyBm cmFnbWVudGF0aW9uLiBJTiBJUHY2LDxicj4NCnNpbmNlIHRoZSBtaW5pbXVtIE1UVSBpcyBxdWl0 ZSBsYXJnZSAoMTI4MCBieXRlcyksIGFuIGF0dGFja2VyIHRoYXQ8YnI+DQpyZWR1Y2VzIHRoZSBN VFUgYmV0d2VlbiB0d28gbm9kZSBqdXN0IGNhdXNlcyBhIHBlcmZvcm1hbmNlIHBlbmFsdHkgKGtp bmQ8YnI+DQpvZiBzbWFsbCBpZiB0aGUgcmVhbCBQTVRVIHdhcyBlLmcuIDE1MDAgYnl0ZXMpLiBC VXQgYW4gYXR0YWNrZXIgdGhhdCBjYW48YnI+DQp0cmlnZ2VyIHRoZSB1c2Ugb2YgZnJhZ21lbnRh dGlvbiBvcGVucyB0aGUgZG9vciB0byBhIG51bWJlciBvZjxicj4NCmZyYWdtZW50YXRpb24tYmFz ZWQgYXR0YWNrcy4uLiBhbmQsIGJlY2F1c2Ugb2YgdGhlIHdpZGVzcHJlYWQgZmlsdGVyaW5nPGJy Pg0Kb2YgSVB2NiBmcmFnbWVudHMsIGF0IHRpbWVzIGp1c3QgdHJpZ2dlcmluZyBmcmFnbWVudGF0 aW9uIGFscmVhZHk8YnI+DQpyZXN1bHRzIGluIGEgRG9TIHNjZW5hcmlvLjxicj4NCjxicj4NClRo YW5rcyE8YnI+DQo8YnI+DQpDaGVlcnMsPGJyPg0KLS08YnI+DQpGZXJuYW5kbyBHb250PGJyPg0K U0k2IE5ldHdvcmtzPGJyPg0KZS1tYWlsOiA8YSBocmVmPSJqYXZhc2NyaXB0OjsiPmZnb250QHNp Nm5ldHdvcmtzLmNvbTwvYT48YnI+DQpQR1AgRmluZ2VycHJpbnQ6IDY2NjYgMzFDNiBENDg0IDYz QjIgOEZCMSBFM0M0IEFFMjUgMEQ1NSAxRDRFIDc0OTI8YnI+DQo8YnI+DQo8YnI+DQo8YnI+DQo8 YnI+DQotLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLTxicj4NCklFVEYgSVB2NiB3b3JraW5nIGdyb3VwIG1haWxpbmcgbGlz dDxicj4NCjxhIGhyZWY9ImphdmFzY3JpcHQ6OyI+aXB2NkBpZXRmLm9yZzwvYT48YnI+DQpBZG1p bmlzdHJhdGl2ZSBSZXF1ZXN0czogPGEgaHJlZj0iaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1h bi9saXN0aW5mby9pcHY2IiB0YXJnZXQ9Il9ibGFuayI+DQpodHRwczovL3d3dy5pZXRmLm9yZy9t YWlsbWFuL2xpc3RpbmZvL2lwdjY8L2E+PGJyPg0KLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS08bzpwPjwvbzpwPjwvc3Bh bj48L3A+DQo8L2Jsb2NrcXVvdGU+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2JvZHk+DQo8 L2h0bWw+DQo= --_000_C9B5F12337F6F841B35C404CF0554ACB89666E9CSZXEMA509MBSchi_-- From nobody Wed Jan 20 00:43:21 2016 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 59A311B3927 for ; Wed, 20 Jan 2016 00:43:18 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.201 X-Spam-Level: X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZnK6ckj1iY96 for ; Wed, 20 Jan 2016 00:43:15 -0800 (PST) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 245611B3926 for ; Wed, 20 Jan 2016 00:43:14 -0800 (PST) Received: from 172.18.7.190 (EHLO lhreml402-hub.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id CDE60163; Wed, 20 Jan 2016 08:43:10 +0000 (GMT) Received: from LHREML705-CAH.china.huawei.com (10.201.5.168) by lhreml402-hub.china.huawei.com (10.201.5.241) with Microsoft SMTP Server (TLS) id 14.3.235.1; Wed, 20 Jan 2016 08:43:08 +0000 Received: from SZXEMA413-HUB.china.huawei.com (10.82.72.72) by lhreml705-cah.china.huawei.com (10.201.5.168) with Microsoft SMTP Server (TLS) id 14.3.235.1; Wed, 20 Jan 2016 08:43:06 +0000 Received: from SZXEMA509-MBS.china.huawei.com ([169.254.2.243]) by SZXEMA413-HUB.china.huawei.com ([10.82.72.72]) with mapi id 14.03.0235.001; Wed, 20 Jan 2016 16:43:01 +0800 From: "Liushucheng (Will)" To: Qiong , Bob Hinden Subject: RE: 6MAN WG Last Call - draft-ietf-6man-deprecate-atomfrag-generation Thread-Topic: 6MAN WG Last Call - draft-ietf-6man-deprecate-atomfrag-generation Thread-Index: AQHRNxa4EHl4eocyV0SccTcC9MUYMJ71O4cAgA8LhwA= Date: Wed, 20 Jan 2016 08:43:00 +0000 Message-ID: References: <7BEE06A2-0F6E-493F-B2C6-68DAB3774FD5@gmail.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.66.78.84] Content-Type: multipart/alternative; boundary="_000_C9B5F12337F6F841B35C404CF0554ACB89666F18SZXEMA509MBSchi_" MIME-Version: 1.0 X-CFilter-Loop: Reflected X-Mirapoint-Virus-RAPID-Raw: score=unknown(0), refid=str=0001.0A020203.569F489F.0170, ss=1, re=0.000, recu=0.000, reip=0.000, cl=1, cld=1, fgs=0, ip=169.254.2.243, so=2013-06-18 04:22:30, dmn=2013-03-21 17:37:32 X-Mirapoint-Loop-Id: f82711b48aa1c6a893f7bd085a2dae66 Archived-At: Cc: IPv6 List X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Jan 2016 08:43:18 -0000 --_000_C9B5F12337F6F841B35C404CF0554ACB89666F18SZXEMA509MBSchi_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SGkgUWlvbmcsDQoNClRoYW5rcyBmb3IgeW91ciBjb21tZW50cy4gUGxlYXNlIHNlZSBteSByZXNw b25zZSBiZWxvdyBpbmxpbmUgc3RhcnRzIHdpdGggW1dpbGxdLg0KDQpSZWdhcmRzLA0KV2lsbCAo U2h1Y2hlbmcgTElVKQ0KDQpGcm9tOiBpcHY2IFttYWlsdG86aXB2Ni1ib3VuY2VzQGlldGYub3Jn XSBPbiBCZWhhbGYgT2YgUWlvbmcNClNlbnQ6IE1vbmRheSwgSmFudWFyeSAxMSwgMjAxNiAxMDoz MCBBTQ0KVG86IEJvYiBIaW5kZW4NCkNjOiBJUHY2IExpc3QNClN1YmplY3Q6IFJlOiA2TUFOIFdH IExhc3QgQ2FsbCAtIGRyYWZ0LWlldGYtNm1hbi1kZXByZWNhdGUtYXRvbWZyYWctZ2VuZXJhdGlv bg0KDQpEZWFyIEFsbCwNCg0KSSBzdXBwb3J0IHB1YmxpY2F0aW9uIG9mIHRoaXMgZG9jdW1lbnQg YXMgYW4gUkZDLg0KDQpBIGZldyBzbWFsbCBjb21tZW50czoNCg0KSW4gYWJzdHJhY3QgeW91IHNl ZW0gdG8gaW1wbHkgdGhhdCB0aGUgdnVsbmVyYWJpbGl0eSByZWxpZXMgcGFydGx5IG9uICJ3aWRl c3ByZWFkIGZpbHRlcmluZyBvZiBwYWNrZXRzIHdpdGggZXh0ZW5zaW9uIGhlYWRlcnMiLiBBY3R1 YWxseSwgYXRvbWljIGZyYWdtZW50cyBvcGVuIHRoZSBkb29yIHRvIGFsbCBmcmFnbWVudGF0aW9u LWJhc2VkIGF0dGFja3MuDQogW1dpbGxdIEhvdyBhYm91dCBjaGFuZ2luZyB0aGUgQWJzdHJhY3Qg dG8gdGhpcz8NCiAgICJSRkMyNDYwIHJlcXVpcmVzIHRoYXQgd2hlbiBhIGhvc3QgcmVjZWl2ZXMg YW4gSUNNUHY2ICJQYWNrZXQgVG9vIEJpZyINCiAgIG1lc3NhZ2UgcmVwb3J0aW5nIGFuIE1UVSBz bWFsbGVyIHRoYW4gMTI4MCBieXRlcywgdGhlIGhvc3QgaW5jbHVkZXMgYQ0KICAgRnJhZ21lbnQg SGVhZGVyIGluIGFsbCBzdWJzZXF1ZW50IHBhY2tldHMgc2VudCB0byB0aGF0IGRlc3RpbmF0aW9u LA0KICAgd2l0aG91dCByZWR1Y2luZyB0aGUgYXNzdW1lZCBQYXRoLU1UVS4gIFRoZSBzaW1wbGlj aXR5IHdpdGggd2hpY2gNCiAgIElDTVB2NiAiUGFja2V0IFRvbyBCaWciIG1lc3NhZ2VzIGNhbiBi ZSBmb3JnZWQgbWVhbnMgdGhhdCBhbg0KICAgYXR0YWNrZXIgY2FuIGxldmVyYWdlIHRoaXMgZnVu Y3Rpb25hbGl0eSB0byB0cmlnZ2VyIHRoZSB1c2Ugb2YNCiAgIGZyYWdtZW50YXRpb24sIGFuZCBz dWJzZXF1ZW50bHkgcGVyZm9ybSBhbnkgZnJhZ21lbnRhdGlvbi1iYXNlZA0KICAgYXR0YWNrLiBU aGlzIGRvY3VtZW50IGRpc2N1c3NlcyB3aHkgdGhlIGFmb3JlbWVudGlvbmVkIGZ1bmN0aW9uYWxp dHkNCiAgIGlzIHVuZGVzaXJhYmxlLCBkb2N1bWVudGluZyB0aGUgbW90aXZhdGlvbiBmb3IgcmVt b3ZpbmcgdGhpcw0KICAgZnVuY3Rpb25hbGl0eSBmcm9tIFtyZmMyNDYwYmlzXS7igJ0NCg0KU2lt aWxhcmx5LCBpbiBTZWN0aW9uIDEgeW91IHdyb3RlICJ0aGVyZSBhcmUgc2NlbmFyaW9zIGluIHdo aWNoIHRoZSBnZW5lcmF0aW9uIG9mIElQdjYgYXRvbWljIGZyYWdtZW50cyBjYW4gaW50cm9kdWNl IGFuIGF0dGFjayB2ZWN0b3IgdGhhdCBjYW4gYmUgZXhwbG9pdGVkIGZvciBkZW5pYWwgb2Ygc2Vy dmljZSBwdXJwb3NlcyIsIGJ1dCB0aGUgYXR0YWNrIHZlY3RvcnMgYXJlIGludHJvZHVjZWQgaW4g YWxsIHNjZW5hcmlvcy4NCiBbV2lsbF0gV2Ugd2lsbCB1cGRhdGUgdGhlIGRyYWZ0IHRvIHJlZmxl Y3QgdGhpcy4NCg0KQXBwZW5kaXggQSBjb250YWlucyB2YWx1YWJsZSBpbmZvcm1hdGlvbi4gSU1I TywgaXQgc2hvdWxkIGJlIHN0cmVzc2VkIGVhcmxpZXIgaW4gdGhlIGRvY3VtZW50IHRoYXQgbWFu eSBvZiB0aGUgbW9zdCBwb3B1bGFyIGltcGxlbWVudGF0aW9ucyBkbyBub3QgZ2VuZXJhdGUgYXRv bWljIGZyYWdtZW50cywgc29tZXRoaW5nIGxpa2UgInRoaXMgZG9jdW1lbnQgYWxpZ25zIHRoZSBz cGVjaWZpY2F0aW9ucyB3aXRoIHByYWN0aWNlIi4NCltXaWxsXSBXaWxsIGRvLg0KDQpDaGVlcnMs DQpXaWxsIChTaHVjaGVuZyBMSVUpDQoNCk9uIFR1ZSwgRGVjIDE1LCAyMDE1IGF0IDQ6NTcgUE0s IEJvYiBIaW5kZW4gPGJvYi5oaW5kZW5AZ21haWwuY29tPG1haWx0bzpib2IuaGluZGVuQGdtYWls LmNvbT4+IHdyb3RlOg0KVGhpcyBtZXNzYWdlIHJlc3RhcnRzIGEgdHdvIHdlZWsgNk1BTiBXb3Jr aW5nIEdyb3VwIExhc3QgQ2FsbCBvbiBhZHZhbmNpbmc6DQoNCiAgIFRpdGxlICAgICAgICAgICA6 IERlcHJlY2F0aW9uIG9mIHRoZSBHZW5lcmF0aW9uIG9mIElQdjYgQXRvbWljIEZyYWdtZW50cw0K ICAgQXV0aG9ycyAgICAgICAgIDogRmVybmFuZG8gR29udA0KICAgICAgICAgICAgICAgICAgICAg V2lsbChTaHVjaGVuZykgTGl1DQogICAgICAgICAgICAgICAgICAgICBUb3JlIEFuZGVyc29uDQog ICBGaWxlbmFtZSAgICAgICAgOiBkcmFmdC1pZXRmLTZtYW4tZGVwcmVjYXRlLWF0b21mcmFnLWdl bmVyYXRpb24tMDQudHh0DQogICBQYWdlcyAgICAgICAgICAgOiA5DQogICBEYXRlICAgICAgICAg ICAgOiAyMDE1LTExLTI2DQoNCiAgIGh0dHBzOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1p ZXRmLTZtYW4tZGVwcmVjYXRlLWF0b21mcmFnLWdlbmVyYXRpb24tMDQNCg0KYXMgYW4gSW5mb3Jt YXRpb25hbCBEb2N1bWVudC4gIFN1YnN0YW50aXZlIGNvbW1lbnRzIGFuZCBzdGF0ZW1lbnRzIG9m IHN1cHBvcnQgZm9yIHB1Ymxpc2hpbmcgdGhpcyBkb2N1bWVudCBzaG91bGQgYmUgZGlyZWN0ZWQg dG8gdGhlIG1haWxpbmcgbGlzdC4gIEVkaXRvcmlhbCBzdWdnZXN0aW9ucyBjYW4gYmUgc2VudCB0 byB0aGUgYXV0aG9ycy4gIFRoaXMgbGFzdCBjYWxsIHdpbGwgZW5kIG9uIDEyIEphbnVhcnkgMjAx Ni4gIFRoaXMgaXMgYSBmb3VyIHdlZWsgbGFzdCBjYWxsIHRvIGFjY291bnQgZm9yIHRoZSBob2xp ZGF5cyBpbiBEZWNlbWJlci4NCg0KQmVzdCByZWdhcmRzLA0KT2xlICYgQm9iDQoNCg0KDQotLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLQ0KSUVURiBJUHY2IHdvcmtpbmcgZ3JvdXAgbWFpbGluZyBsaXN0DQppcHY2QGlldGYu b3JnPG1haWx0bzppcHY2QGlldGYub3JnPg0KQWRtaW5pc3RyYXRpdmUgUmVxdWVzdHM6IGh0dHBz Oi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vaXB2Ng0KLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0NCg0KDQoN Ci0tDQo9PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09DQpRaW9u ZyBTdW4NCkNoaW5hIFRlbGVjb20gQmVpamluZyBSZXNlYXJjaCBJbnN0aXR1ZGUNCg0KDQpPcGVu IHNvdXJjZSBjb2RlOg0KbGlnaHR3ZWlnaHQgNG92ZXI2OiBodHRwOi8vc291cmNlZm9yZ2UubmV0 L3Byb2plY3RzL2xhZnQ2Lw0KUENQLW5hdGNvb3JkOiBodHRwOi8vc291cmNlZm9yZ2UubmV0L3By b2plY3RzL3BjcHBvcnRzZXRkZW1vLw0KPT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT0NCg== --_000_C9B5F12337F6F841B35C404CF0554ACB89666F18SZXEMA509MBSchi_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 5a6L5L2TOw0KCXBhbm9zZS0xOjIgMSA2IDAgMyAxIDEgMSAxIDE7fQ0KQGZvbnQtZmFjZQ0KCXtm b250LWZhbWlseToiQ2FtYnJpYSBNYXRoIjsNCglwYW5vc2UtMToyIDQgNSAzIDUgNCA2IDMgMiA0 O30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6Q2FsaWJyaTsNCglwYW5vc2UtMToyIDE1IDUg MiAyIDIgNCAzIDIgNDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OiJcQOWui+S9kyI7DQoJ cGFub3NlLTE6MiAxIDYgMCAzIDEgMSAxIDEgMTt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5 OuW+rui9r+mbhem7kTsNCglwYW5vc2UtMToyIDExIDUgMyAyIDIgNCAyIDIgNDt9DQpAZm9udC1m YWNlDQoJe2ZvbnQtZmFtaWx5OiJcQOW+rui9r+mbhem7kSI7DQoJcGFub3NlLTE6MiAxMSA1IDMg MiAyIDQgMiAyIDQ7fQ0KLyogU3R5bGUgRGVmaW5pdGlvbnMgKi8NCnAuTXNvTm9ybWFsLCBsaS5N c29Ob3JtYWwsIGRpdi5Nc29Ob3JtYWwNCgl7bWFyZ2luOjBjbTsNCgltYXJnaW4tYm90dG9tOi4w MDAxcHQ7DQoJZm9udC1zaXplOjEyLjBwdDsNCglmb250LWZhbWlseTrlrovkvZM7fQ0KYTpsaW5r LCBzcGFuLk1zb0h5cGVybGluaw0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6Ymx1 ZTsNCgl0ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lO30NCmE6dmlzaXRlZCwgc3Bhbi5Nc29IeXBl cmxpbmtGb2xsb3dlZA0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6cHVycGxlOw0K CXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0Kc3Bhbi5FbWFpbFN0eWxlMTcNCgl7bXNvLXN0 eWxlLXR5cGU6cGVyc29uYWwtcmVwbHk7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLHNhbnMtc2Vy aWY7DQoJY29sb3I6IzFGNDk3RDt9DQouTXNvQ2hwRGVmYXVsdA0KCXttc28tc3R5bGUtdHlwZTpl eHBvcnQtb25seTt9DQpAcGFnZSBXb3JkU2VjdGlvbjENCgl7c2l6ZTo2MTIuMHB0IDc5Mi4wcHQ7 DQoJbWFyZ2luOjcyLjBwdCA5MC4wcHQgNzIuMHB0IDkwLjBwdDt9DQpkaXYuV29yZFNlY3Rpb24x DQoJe3BhZ2U6V29yZFNlY3Rpb24xO30NCi0tPjwvc3R5bGU+PCEtLVtpZiBndGUgbXNvIDldPjx4 bWw+DQo8bzpzaGFwZWRlZmF1bHRzIHY6ZXh0PSJlZGl0IiBzcGlkbWF4PSIxMDI2IiAvPg0KPC94 bWw+PCFbZW5kaWZdLS0+PCEtLVtpZiBndGUgbXNvIDldPjx4bWw+DQo8bzpzaGFwZWxheW91dCB2 OmV4dD0iZWRpdCI+DQo8bzppZG1hcCB2OmV4dD0iZWRpdCIgZGF0YT0iMSIgLz4NCjwvbzpzaGFw ZWxheW91dD48L3htbD48IVtlbmRpZl0tLT4NCjwvaGVhZD4NCjxib2R5IGxhbmc9IlpILUNOIiBs aW5rPSJibHVlIiB2bGluaz0icHVycGxlIj4NCjxkaXYgY2xhc3M9IldvcmRTZWN0aW9uMSI+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZTox MC41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMx RjQ5N0QiPkhpIFFpb25nLDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtmb250LWZhbWls eTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+PG86cD4mbmJz cDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4t VVMiIHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVv dDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj5UaGFua3MgZm9yIHlvdXIgY29tbWVudHMuIFBs ZWFzZSBzZWUgbXkgcmVzcG9uc2UgYmVsb3cgaW5saW5lIHN0YXJ0cyB3aXRoIFtXaWxsXS48bzpw PjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1V UyIgc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90 OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJ0ZXh0LWFsaWduOmp1c3RpZnk7dGV4dC1qdXN0 aWZ5OmludGVyLWlkZW9ncmFwaCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6 MTAuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjoj MUY0OTdEIj5SZWdhcmRzLDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiIHN0eWxlPSJ0ZXh0LWFsaWduOmp1c3RpZnk7dGV4dC1qdXN0aWZ5OmludGVyLWlkZW9ncmFw aCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5 OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj5XaWxsIChTaHVj aGVuZyBMSVUpPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNw YW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5OiZxdW90 O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpw Pjwvc3Bhbj48L3A+DQo8ZGl2IHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItbGVmdDpzb2xpZCBi bHVlIDEuNXB0O3BhZGRpbmc6MGNtIDBjbSAwY20gNC4wcHQiPg0KPGRpdj4NCjxkaXYgc3R5bGU9 ImJvcmRlcjpub25lO2JvcmRlci10b3A6c29saWQgI0UxRTFFMSAxLjBwdDtwYWRkaW5nOjMuMHB0 IDBjbSAwY20gMGNtIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxiPjxzcGFuIGxhbmc9IkVOLVVT IiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7 LHNhbnMtc2VyaWYiPkZyb206PC9zcGFuPjwvYj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZv bnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlm Ij4gaXB2NiBbbWFpbHRvOmlwdjYtYm91bmNlc0BpZXRmLm9yZ10NCjxiPk9uIEJlaGFsZiBPZiA8 L2I+UWlvbmc8YnI+DQo8Yj5TZW50OjwvYj4gTW9uZGF5LCBKYW51YXJ5IDExLCAyMDE2IDEwOjMw IEFNPGJyPg0KPGI+VG86PC9iPiBCb2IgSGluZGVuPGJyPg0KPGI+Q2M6PC9iPiBJUHY2IExpc3Q8 YnI+DQo8Yj5TdWJqZWN0OjwvYj4gUmU6IDZNQU4gV0cgTGFzdCBDYWxsIC0gZHJhZnQtaWV0Zi02 bWFuLWRlcHJlY2F0ZS1hdG9tZnJhZy1nZW5lcmF0aW9uPG86cD48L286cD48L3NwYW4+PC9wPg0K PC9kaXY+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIj48 bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIj5EZWFyIEFsbCw8bzpwPjwvbzpwPjwvc3Bhbj48L3A+ DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyI+ PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJiYWNrZ3JvdW5kOndoaXRlIj48c3BhbiBsYW5nPSJFTi1V UyIgc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q75b6u6L2v6ZuF6buR JnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6YmxhY2siPkkgc3VwcG9ydCBwdWJsaWNhdGlvbiBvZiB0 aGlzIGRvY3VtZW50IGFzIGFuIFJGQy48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxk aXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0iYmFja2dyb3VuZDp3aGl0ZSI+PHNwYW4g bGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O+W+ rui9r+mbhem7kSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOmJsYWNrIj4mbmJzcDs8bzpwPjwvbzpw Pjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0i YmFja2dyb3VuZDp3aGl0ZSI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAu NXB0O2ZvbnQtZmFtaWx5OiZxdW90O+W+rui9r+mbhem7kSZxdW90OyxzYW5zLXNlcmlmO2NvbG9y OmJsYWNrIj5BIGZldyBzbWFsbCBjb21tZW50czo8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rp dj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0iYmFja2dyb3VuZDp3aGl0ZSI+ PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5OiZx dW90O+W+rui9r+mbhem7kSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOmJsYWNrIj4mbmJzcDs8bzpw PjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBz dHlsZT0iYmFja2dyb3VuZDp3aGl0ZSI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNp emU6MTAuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O+W+rui9r+mbhem7kSZxdW90OyxzYW5zLXNlcmlm O2NvbG9yOmJsYWNrIj5JbiBhYnN0cmFjdCB5b3Ugc2VlbSB0byBpbXBseSB0aGF0IHRoZSB2dWxu ZXJhYmlsaXR5IHJlbGllcyBwYXJ0bHkgb24gJnF1b3Q7d2lkZXNwcmVhZCBmaWx0ZXJpbmcgb2Yg cGFja2V0cyB3aXRoIGV4dGVuc2lvbiBoZWFkZXJzJnF1b3Q7Lg0KIEFjdHVhbGx5LCBhdG9taWMg ZnJhZ21lbnRzIG9wZW4gdGhlIGRvb3IgdG8gYWxsIGZyYWdtZW50YXRpb24tYmFzZWQgYXR0YWNr cy48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIiBzdHlsZT0ibWFyZ2luLWxlZnQ6NS41cHQ7YmFja2dyb3VuZDp3aGl0ZSI+PHNwYW4gbGFu Zz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O+W+rui9 r+mbhem7kSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOmJsYWNrIj4mbmJzcDs8L3NwYW4+PGI+PGk+ PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5OiZx dW90O+W+rui9r+mbhem7kSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPltXaWxsXQ0K PC9zcGFuPjwvaT48L2I+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuNXB0 O2ZvbnQtZmFtaWx5OiZxdW90O+W+rui9r+mbhem7kSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMx RjQ5N0QiPkhvdyBhYm91dCBjaGFuZ2luZyB0aGUgQWJzdHJhY3QgdG8gdGhpcz88bzpwPjwvbzpw Pjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWxlZnQ6NS41 cHQ7YmFja2dyb3VuZDp3aGl0ZSI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6 MTAuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O+W+rui9r+mbhem7kSZxdW90OyxzYW5zLXNlcmlmO2Nv bG9yOiMxRjQ5N0QiPiZuYnNwOyZuYnNwOyAmcXVvdDtSRkMyNDYwIHJlcXVpcmVzIHRoYXQgd2hl biBhIGhvc3QgcmVjZWl2ZXMgYW4gSUNNUHY2ICZxdW90O1BhY2tldCBUb28gQmlnJnF1b3Q7PG86 cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1s ZWZ0OjUuNXB0O2JhY2tncm91bmQ6d2hpdGUiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9u dC1zaXplOjEwLjVwdDtmb250LWZhbWlseTomcXVvdDvlvq7ova/pm4Xpu5EmcXVvdDssc2Fucy1z ZXJpZjtjb2xvcjojMUY0OTdEIj4mbmJzcDsmbmJzcDsgbWVzc2FnZSByZXBvcnRpbmcgYW4gTVRV IHNtYWxsZXIgdGhhbiAxMjgwIGJ5dGVzLCB0aGUgaG9zdCBpbmNsdWRlcyBhPG86cD48L286cD48 L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0OjUuNXB0 O2JhY2tncm91bmQ6d2hpdGUiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEw LjVwdDtmb250LWZhbWlseTomcXVvdDvlvq7ova/pm4Xpu5EmcXVvdDssc2Fucy1zZXJpZjtjb2xv cjojMUY0OTdEIj4mbmJzcDsmbmJzcDsgRnJhZ21lbnQgSGVhZGVyIGluIGFsbCBzdWJzZXF1ZW50 IHBhY2tldHMgc2VudCB0byB0aGF0IGRlc3RpbmF0aW9uLDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tbGVmdDo1LjVwdDtiYWNrZ3JvdW5k OndoaXRlIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1m YW1pbHk6JnF1b3Q75b6u6L2v6ZuF6buRJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+ Jm5ic3A7Jm5ic3A7IHdpdGhvdXQgcmVkdWNpbmcgdGhlIGFzc3VtZWQgUGF0aC1NVFUuJm5ic3A7 IFRoZSBzaW1wbGljaXR5IHdpdGggd2hpY2g8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWxlZnQ6NS41cHQ7YmFja2dyb3VuZDp3aGl0ZSI+ PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5OiZx dW90O+W+rui9r+mbhem7kSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPiZuYnNwOyZu YnNwOyBJQ01QdjYgJnF1b3Q7UGFja2V0IFRvbyBCaWcmcXVvdDsgbWVzc2FnZXMgY2FuIGJlIGZv cmdlZCBtZWFucyB0aGF0IGFuPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05v cm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0OjUuNXB0O2JhY2tncm91bmQ6d2hpdGUiPjxzcGFuIGxh bmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtmb250LWZhbWlseTomcXVvdDvlvq7o va/pm4Xpu5EmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj4mbmJzcDsmbmJzcDsgYXR0 YWNrZXIgY2FuIGxldmVyYWdlIHRoaXMgZnVuY3Rpb25hbGl0eSB0byB0cmlnZ2VyIHRoZSB1c2Ug b2Y8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFy Z2luLWxlZnQ6NS41cHQ7YmFja2dyb3VuZDp3aGl0ZSI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxl PSJmb250LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O+W+rui9r+mbhem7kSZxdW90Oyxz YW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPiZuYnNwOyZuYnNwOyBmcmFnbWVudGF0aW9uLCBhbmQg c3Vic2VxdWVudGx5IHBlcmZvcm0gYW55IGZyYWdtZW50YXRpb24tYmFzZWQ8bzpwPjwvbzpwPjwv c3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWxlZnQ6NS41cHQ7 YmFja2dyb3VuZDp3aGl0ZSI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAu NXB0O2ZvbnQtZmFtaWx5OiZxdW90O+W+rui9r+mbhem7kSZxdW90OyxzYW5zLXNlcmlmO2NvbG9y OiMxRjQ5N0QiPiZuYnNwOyZuYnNwOyBhdHRhY2suIFRoaXMgZG9jdW1lbnQgZGlzY3Vzc2VzIHdo eSB0aGUgYWZvcmVtZW50aW9uZWQgZnVuY3Rpb25hbGl0eTxvOnA+PC9vOnA+PC9zcGFuPjwvcD4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tbGVmdDo1LjVwdDtiYWNrZ3JvdW5k OndoaXRlIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1m YW1pbHk6JnF1b3Q75b6u6L2v6ZuF6buRJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+ Jm5ic3A7Jm5ic3A7IGlzIHVuZGVzaXJhYmxlLCBkb2N1bWVudGluZyB0aGUgbW90aXZhdGlvbiBm b3IgcmVtb3ZpbmcgdGhpczxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiIHN0eWxlPSJtYXJnaW4tbGVmdDo1LjVwdDtiYWNrZ3JvdW5kOndoaXRlIj48c3BhbiBsYW5n PSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q75b6u6L2v 6ZuF6buRJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+Jm5ic3A7Jm5ic3A7IGZ1bmN0 aW9uYWxpdHkgZnJvbSBbcmZjMjQ2MGJpc10u4oCdPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0OjUuNXB0O2JhY2tncm91bmQ6d2hp dGUiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtmb250LWZhbWls eTomcXVvdDvlvq7ova/pm4Xpu5EmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj48bzpw PiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIiBzdHlsZT0iYmFja2dyb3VuZDp3aGl0ZSI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJm b250LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O+W+rui9r+mbhem7kSZxdW90OyxzYW5z LXNlcmlmO2NvbG9yOmJsYWNrIj5TaW1pbGFybHksIGluIFNlY3Rpb24gMSB5b3Ugd3JvdGUgJnF1 b3Q7dGhlcmUgYXJlIHNjZW5hcmlvcyBpbiB3aGljaCB0aGUgZ2VuZXJhdGlvbiBvZiBJUHY2IGF0 b21pYyBmcmFnbWVudHMgY2FuIGludHJvZHVjZSBhbiBhdHRhY2sNCiB2ZWN0b3IgdGhhdCBjYW4g YmUgZXhwbG9pdGVkIGZvciBkZW5pYWwgb2Ygc2VydmljZSBwdXJwb3NlcyZxdW90OywgYnV0IHRo ZSBhdHRhY2sgdmVjdG9ycyBhcmUgaW50cm9kdWNlZCBpbiBhbGwgc2NlbmFyaW9zLjxvOnA+PC9v OnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxl PSJiYWNrZ3JvdW5kOndoaXRlIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZTox MC41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q75b6u6L2v6ZuF6buRJnF1b3Q7LHNhbnMtc2VyaWY7Y29s b3I6YmxhY2siPiZuYnNwOzwvc3Bhbj48Yj48aT48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZv bnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q75b6u6L2v6ZuF6buRJnF1b3Q7LHNhbnMt c2VyaWY7Y29sb3I6IzFGNDk3RCI+W1dpbGxdDQo8L3NwYW4+PC9pPjwvYj48Yj48c3BhbiBsYW5n PSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q75b6u6L2v 6ZuF6buRJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+V2Ugd2lsbCB1cGRhdGUgdGhl IGRyYWZ0IHRvIHJlZmxlY3QgdGhpcy48L3NwYW4+PC9iPjxiPjxzcGFuIGxhbmc9IkVOLVVTIiBz dHlsZT0iZm9udC1zaXplOjEwLjVwdDtmb250LWZhbWlseTomcXVvdDvlvq7ova/pm4Xpu5EmcXVv dDssc2Fucy1zZXJpZjtjb2xvcjpibGFjayI+PG86cD48L286cD48L3NwYW4+PC9iPjwvcD4NCjwv ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJiYWNrZ3JvdW5kOndoaXRl Ij48Yj48aT48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1m YW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPjxvOnA+ Jm5ic3A7PC9vOnA+PC9zcGFuPjwvaT48L2I+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5 bGU9ImJhY2tncm91bmQ6d2hpdGUiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXpl OjEwLjVwdDtmb250LWZhbWlseTomcXVvdDvlvq7ova/pm4Xpu5EmcXVvdDssc2Fucy1zZXJpZjtj b2xvcjpibGFjayI+QXBwZW5kaXggQSBjb250YWlucyB2YWx1YWJsZSBpbmZvcm1hdGlvbi4gSU1I TywgaXQgc2hvdWxkIGJlIHN0cmVzc2VkIGVhcmxpZXIgaW4gdGhlIGRvY3VtZW50IHRoYXQgbWFu eSBvZiB0aGUgbW9zdCBwb3B1bGFyIGltcGxlbWVudGF0aW9ucw0KIGRvIG5vdCBnZW5lcmF0ZSBh dG9taWMgZnJhZ21lbnRzLCBzb21ldGhpbmcgbGlrZSAmcXVvdDt0aGlzIGRvY3VtZW50IGFsaWdu cyB0aGUgc3BlY2lmaWNhdGlvbnMgd2l0aCBwcmFjdGljZSZxdW90Oy48bzpwPjwvbzpwPjwvc3Bh bj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0iYmFja2dyb3VuZDp3aGl0ZSI+PGI+ PGk+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5 OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj5bV2lsbF0NCjwv c3Bhbj48L2k+PC9iPjxiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjVw dDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3 RCI+V2lsbCBkby48bzpwPjwvbzpwPjwvc3Bhbj48L2I+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1h bCIgc3R5bGU9ImJhY2tncm91bmQ6d2hpdGUiPjxiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0i Zm9udC1zaXplOjEwLjVwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2Vy aWY7Y29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9iPjwvcD4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJiYWNrZ3JvdW5kOndoaXRlIj48Yj48c3BhbiBsYW5nPSJF Ti1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZx dW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPkNoZWVycyw8bzpwPjwvbzpwPjwvc3Bhbj48 L2I+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9ImJhY2tncm91bmQ6d2hpdGUiPjxi PjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtmb250LWZhbWlseTom cXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+V2lsbCAoU2h1Y2hl bmcgTElVKTwvc3Bhbj48L2I+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAu NXB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0 OTdEIj48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJiYWNrZ3JvdW5kOndoaXRlIj48c3BhbiBsYW5nPSJFTi1V UyIgc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q75b6u6L2v6ZuF6buR JnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6YmxhY2siPiZuYnNwOzwvc3Bhbj48c3BhbiBsYW5nPSJF Ti1VUyI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PjxzcGFuIGxhbmc9IkVOLVVTIj5PbiBUdWUsIERlYyAxNSwgMjAxNSBhdCA0OjU3IFBNLCBCb2Ig SGluZGVuICZsdDs8YSBocmVmPSJtYWlsdG86Ym9iLmhpbmRlbkBnbWFpbC5jb20iIHRhcmdldD0i X2JsYW5rIj5ib2IuaGluZGVuQGdtYWlsLmNvbTwvYT4mZ3Q7IHdyb3RlOjxvOnA+PC9vOnA+PC9z cGFuPjwvcD4NCjxibG9ja3F1b3RlIHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItbGVmdDpzb2xp ZCAjQ0NDQ0NDIDEuMHB0O3BhZGRpbmc6MGNtIDBjbSAwY20gNi4wcHQ7bWFyZ2luLWxlZnQ6NC44 cHQ7bWFyZ2luLXJpZ2h0OjBjbSI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2lu LWJvdHRvbToxMi4wcHQiPjxzcGFuIGxhbmc9IkVOLVVTIj5UaGlzIG1lc3NhZ2UgcmVzdGFydHMg YSB0d28gd2VlayA2TUFOIFdvcmtpbmcgR3JvdXAgTGFzdCBDYWxsIG9uIGFkdmFuY2luZzo8YnI+ DQo8YnI+DQombmJzcDsgJm5ic3A7VGl0bGUmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5i c3A7ICZuYnNwOzogRGVwcmVjYXRpb24gb2YgdGhlIEdlbmVyYXRpb24gb2YgSVB2NiBBdG9taWMg RnJhZ21lbnRzPGJyPg0KJm5ic3A7ICZuYnNwO0F1dGhvcnMmbmJzcDsgJm5ic3A7ICZuYnNwOyAm bmJzcDsgJm5ic3A7OiBGZXJuYW5kbyBHb250PGJyPg0KJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5i c3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwO1dpbGwo U2h1Y2hlbmcpIExpdTxicj4NCiZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5i c3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDtUb3JlIEFuZGVyc29uPGJyPg0K Jm5ic3A7ICZuYnNwO0ZpbGVuYW1lJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7IDogZHJhZnQt aWV0Zi02bWFuLWRlcHJlY2F0ZS1hdG9tZnJhZy1nZW5lcmF0aW9uLTA0LnR4dDxicj4NCiZuYnNw OyAmbmJzcDtQYWdlcyZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7OiA5 PGJyPg0KJm5ic3A7ICZuYnNwO0RhdGUmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7 ICZuYnNwOyA6IDIwMTUtMTEtMjY8YnI+DQo8YnI+DQombmJzcDsgJm5ic3A7PGEgaHJlZj0iaHR0 cHM6Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LWlldGYtNm1hbi1kZXByZWNhdGUtYXRvbWZy YWctZ2VuZXJhdGlvbi0wNCIgdGFyZ2V0PSJfYmxhbmsiPmh0dHBzOi8vdG9vbHMuaWV0Zi5vcmcv aHRtbC9kcmFmdC1pZXRmLTZtYW4tZGVwcmVjYXRlLWF0b21mcmFnLWdlbmVyYXRpb24tMDQ8L2E+ PGJyPg0KPGJyPg0KYXMgYW4gSW5mb3JtYXRpb25hbCBEb2N1bWVudC4mbmJzcDsgU3Vic3RhbnRp dmUgY29tbWVudHMgYW5kIHN0YXRlbWVudHMgb2Ygc3VwcG9ydCBmb3IgcHVibGlzaGluZyB0aGlz IGRvY3VtZW50IHNob3VsZCBiZSBkaXJlY3RlZCB0byB0aGUgbWFpbGluZyBsaXN0LiZuYnNwOyBF ZGl0b3JpYWwgc3VnZ2VzdGlvbnMgY2FuIGJlIHNlbnQgdG8gdGhlIGF1dGhvcnMuJm5ic3A7IFRo aXMgbGFzdCBjYWxsIHdpbGwgZW5kIG9uIDEyIEphbnVhcnkgMjAxNi4mbmJzcDsgVGhpcyBpcyBh IGZvdXINCiB3ZWVrIGxhc3QgY2FsbCB0byBhY2NvdW50IGZvciB0aGUgaG9saWRheXMgaW4gRGVj ZW1iZXIuPGJyPg0KPGJyPg0KQmVzdCByZWdhcmRzLDxicj4NCk9sZSAmYW1wOyBCb2I8YnI+DQo8 YnI+DQo8YnI+DQo8YnI+DQotLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLTxicj4NCklFVEYgSVB2NiB3b3JraW5nIGdyb3Vw IG1haWxpbmcgbGlzdDxicj4NCjxhIGhyZWY9Im1haWx0bzppcHY2QGlldGYub3JnIj5pcHY2QGll dGYub3JnPC9hPjxicj4NCkFkbWluaXN0cmF0aXZlIFJlcXVlc3RzOiA8YSBocmVmPSJodHRwczov L3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL2lwdjYiIHRhcmdldD0iX2JsYW5rIj4NCmh0 dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vaXB2NjwvYT48YnI+DQotLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLTxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvYmxvY2txdW90ZT4NCjwvZGl2Pg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiPjxicj4NCjxiciBjbGVhcj0iYWxsIj4N Cjxicj4NCi0tIDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIiBzdHlsZT0ibWFyZ2luLWJvdHRvbToxMi4wcHQiPjxzcGFuIGxhbmc9IkVOLVVTIj49PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PGJyPg0KUWlvbmcgU3Vu PGJyPg0KQ2hpbmEgVGVsZWNvbSBCZWlqaW5nIFJlc2VhcmNoIEluc3RpdHVkZTxicj4NCjxicj4N Cjxicj4NCk9wZW4gc291cmNlIGNvZGU6PGJyPg0KbGlnaHR3ZWlnaHQgNG92ZXI2OiA8aT48YSBo cmVmPSJodHRwOi8vc291cmNlZm9yZ2UubmV0L3Byb2plY3RzL2xhZnQ2LyIgdGFyZ2V0PSJfYmxh bmsiPmh0dHA6Ly9zb3VyY2Vmb3JnZS5uZXQvcHJvamVjdHMvbGFmdDYvPC9hPjwvaT48YnI+DQpQ Q1AtbmF0Y29vcmQ6PGk+IDxhIGhyZWY9Imh0dHA6Ly9zb3VyY2Vmb3JnZS5uZXQvcHJvamVjdHMv cGNwcG9ydHNldGRlbW8vIiB0YXJnZXQ9Il9ibGFuayI+DQpodHRwOi8vc291cmNlZm9yZ2UubmV0 L3Byb2plY3RzL3BjcHBvcnRzZXRkZW1vLzwvYT4gPC9pPjxicj4NCj09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9k aXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvYm9keT4NCjwvaHRtbD4NCg== --_000_C9B5F12337F6F841B35C404CF0554ACB89666F18SZXEMA509MBSchi_-- From nobody Wed Jan 20 15:23:35 2016 Return-Path: X-Original-To: ipv6@ietf.org Delivered-To: ipv6@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id A53611B2A98; Wed, 20 Jan 2016 15:23:32 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: Subject: I-D Action: draft-ietf-6man-deprecate-atomfrag-generation-05.txt X-Test-IDTracker: no X-IETF-IDTracker: 6.13.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20160120232332.1443.9829.idtracker@ietfa.amsl.com> Date: Wed, 20 Jan 2016 15:23:32 -0800 Archived-At: Cc: ipv6@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.15 List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Jan 2016 23:23:32 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the IPv6 Maintenance Working Group of the IETF. Title : Generation of IPv6 Atomic Fragments Considered Harmful Authors : Fernando Gont Will(Shucheng) Liu Tore Anderson Filename : draft-ietf-6man-deprecate-atomfrag-generation-05.txt Pages : 10 Date : 2016-01-20 Abstract: RFC2460 requires that when a host receives an ICMPv6 "Packet Too Big" message reporting an MTU smaller than 1280 bytes, the host includes a Fragment Header in all subsequent packets sent to that destination, without reducing the assumed Path-MTU. The simplicity with which ICMPv6 "Packet Too Big" messages can be forged means that an attacker can leverage this functionality (the generation of IPv6 atomic fragments) to trigger the use of fragmentation for any arbitrary IPv6 flow, and subsequently perform any fragmentation-based attack. This document discusses the security implications of the generation of IPv6 atomic fragments and a number of interoperability issues associated with IPv6 atomic fragments, and concludes that the aforementioned functionality is undesirable, thus documenting the motivation for removing this functionality in the revision of the core IPv6 protocol specification [I-D.ietf-6man-rfc2460bis]. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-6man-deprecate-atomfrag-generation/ There's also a htmlized version available at: https://tools.ietf.org/html/draft-ietf-6man-deprecate-atomfrag-generation-05 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-6man-deprecate-atomfrag-generation-05 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 nobody Wed Jan 20 15:36:49 2016 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 71B6B1B2ACA for ; Wed, 20 Jan 2016 15:36:48 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.301 X-Spam-Level: X-Spam-Status: No, score=-1.301 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, J_CHICKENPOX_16=0.6, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GzEo_ChcAffg for ; Wed, 20 Jan 2016 15:36:47 -0800 (PST) Received: from fgont.go6lab.si (fgont.go6lab.si [91.239.96.14]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C33FC1B2AC4 for ; Wed, 20 Jan 2016 15:36:46 -0800 (PST) Received: from [192.168.3.107] (unknown [181.165.125.191]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by fgont.go6lab.si (Postfix) with ESMTPSA id 9852320698D; Thu, 21 Jan 2016 00:36:42 +0100 (CET) Subject: Re: draft-ietf-6man-default-iids-08 To: weigengyu , ipv6@ietf.org References: <09178529BD77411993873F761BE6F722@WeiGengyuPC> From: Fernando Gont X-Enigmail-Draft-Status: N1110 Message-ID: <56A01A43.2030705@si6networks.com> Date: Wed, 20 Jan 2016 20:37:39 -0300 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.4.0 MIME-Version: 1.0 In-Reply-To: <09178529BD77411993873F761BE6F722@WeiGengyuPC> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 8bit Archived-At: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Jan 2016 23:36:48 -0000 Hello, Gengyu, On 01/18/2016 05:17 AM, weigengyu wrote: > > I have a question about draft-ietf-6man-default-iids-08. > > Whether an IPv6 address of a host would be changed? > If it is, in what situations does the IPv6 address change? When a node moves from one network to another. It will certainly change when the Prefix used for auto-configuration changes, and may also change if such prefix stays the same but the network (e.g, SSID) changes. > In Page 3 of the draft, > “As a result of the aforementioned issues, this document recommends > the implementation of an alternative scheme ([RFC7217]) as the > default stable IID generation scheme for SLAAC, such that the > aforementioned issues are mitigated.” > > In Page 7 of RFC7212, > “Compute a random (but stable) identifier with the expression: > RID = F(Prefix, Net_Iface, Network_ID, DAD_Counter, secret_key)” > > And in page 9 of RFC7252, > “2. The Interface Identifier is finally obtained by taking as many > bits from the RID value (computed in the previous step) as > necessary, starting from the least significant bit.” > > > If a host which does not move is rebooted, whether its IPv6 address changes? It will not, since the secret_key will stay the same. > If a host move out and back, eg, leave home to go to an office in the > morning and get back in the evening, > whether its IPv6 address changes? It will not. That's one of the design goals of RFC7217. Thanks! Best regards, -- Fernando Gont SI6 Networks e-mail: fgont@si6networks.com PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492 From nobody Thu Jan 21 07:10:02 2016 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A04691B305D for ; Thu, 21 Jan 2016 07:10:00 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.399 X-Spam-Level: * X-Spam-Status: No, score=1.399 tagged_above=-999 required=5 tests=[BAYES_50=0.8, HTML_MESSAGE=0.001, J_CHICKENPOX_16=0.6, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Jrjjz_rX0L-n for ; Thu, 21 Jan 2016 07:09:57 -0800 (PST) Received: from mx1.bupt.edu.cn (mx1.bupt.edu.cn [211.68.68.2]) by ietfa.amsl.com (Postfix) with ESMTP id 4CFEA1A88B1 for ; Thu, 21 Jan 2016 07:09:57 -0800 (PST) Received: from mx1.bupt.edu.cn (unknown [127.0.0.1]) by mx1.bupt.edu.cn (AnyMacro(G7)) with SMTP id BBAE019F3DC for ; Thu, 21 Jan 2016 23:09:55 +0800 (HKT) Received: from WeiGengyuPC (unknown [221.219.184.182]) by mx1.bupt.edu.cn (AnyMacro(G7)) with ESMTPA id 7DD0719F383; Thu, 21 Jan 2016 23:09:55 +0800 (HKT) Message-ID: From: "weigengyu" To: "Ray Hunter" References: <569F7519.1050102@globis.net> In-Reply-To: <569F7519.1050102@globis.net> Subject: Re: draft-ietf-6man-default-iids-08 Date: Thu, 21 Jan 2016 23:09:57 +0800 Organization: BUPT MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_000C_01D154A0.D8C1DFE0" X-Priority: 3 X-MSMail-Priority: Normal Importance: Normal X-Mailer: Microsoft Windows Live Mail 16.4.3528.331 X-MimeOLE: Produced By Microsoft MimeOLE V16.4.3528.331 Archived-At: Cc: 6man WG X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Jan 2016 15:10:00 -0000 ÕâÊÇÒ»·â MIME ¸ñʽµÄ¶à·½Óʼþ¡£ ------=_NextPart_000_000C_01D154A0.D8C1DFE0 Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: quoted-printable Hi RayH,=20 Thank you for your explanations.=20 In Page 8 of RFC7212,=20 secret_key: A secret key that is not known by the attacker. The secret key SHOULD be of at least 128 bits. It MUST be initialized to a pseudo-random number (see [RFC4086] for randomness requirements for security) when the operating system is installed or when the IPv6 protocol stack is "bootstrapped" for the first time. An implementation MAY provide the means for the system administrator to display and change the secret key. Based on the above descriptions, it seems that the secret key needs = changing for randomness.=20 If the secrete key is changge the new generate IPv6 address will be = different.=20 Is it right? Regards,=20 Gengyu WEI Network Technology Center School of Computer=20 Beijing University of Posts and Telecommunications From: Ray Hunter=20 Sent: Wednesday, January 20, 2016 7:52 PM To: weigengyu=20 Cc: 6man WG=20 Subject: Re: draft-ietf-6man-default-iids-08 Inline Subject: draft-ietf-6man-default-iids-08=20 From: "weigengyu" =20 Date: Mon, 18 Jan 2016 16:17:14 +0800=20 To: =20 Hi,=20 I have a question about draft-ietf-6man-default-iids-08.=20 Whether an IPv6 address of a host would be changed? Yes, it can change over time, in some circumstances. If it is, in what situations does the IPv6 address change?=20 see below. the RID =3D F(Prefix, Net_Iface, Network_ID, DAD_Counter, secret_key) If any of the input variables change, the RID will change, and the = resulting IPv6 address will very likely change. In Page 3 of the draft,=20 =A1=B0As a result of the aforementioned issues, this document = recommends the implementation of an alternative scheme ([RFC7217]) as the default stable IID generation scheme for SLAAC, such that the aforementioned issues are mitigated.=A1=B1 In Page 7 of RFC7212,=20 =A1=B0Compute a random (but stable) identifier with the expression: RID =3D F(Prefix, Net_Iface, Network_ID, DAD_Counter, = secret_key)=A1=B1 And in page 9 of RFC7252, =A1=B02. The Interface Identifier is finally obtained by taking as = many bits from the RID value (computed in the previous step) as necessary, starting from the least significant bit.=A1=B1=20 If a host which does not move is rebooted, whether its IPv6 address = changes? In the case of a reboot, it could be assumed that the variables (prefix, = Net_Iface, Network_ID, DAD_Counter, secret_key) do NOT change (i.e. = values are likely to be non-volatile over a reboot). Therefore, the IPv6 = address should not change. An exception could be if a node does not have local storage to remember = the value for e.g. the DAD_Counter. There is generally a VERY SMALL chance that nodes may produce a = collision, given sufficient entropy into the RID function. How this is achieved is an implementation issue. One corner case is that If nodes do not remember e.g. the DAD_counter = over reboots. If there were two or more identical nodes, node-1 could = claim an IPv6 address before the other nodes booted, and node-2 to = node-n would detect a collision and increment their DAD_Counter and = "back off". Previously the collision may have occurred in a different = order (because one of the nodes node-2 to node-n booted faster) and node = 1 "backed off". That would give the nodes different address assignments. = Worse still: the IPv6 addresses would remain the same, but they'd = actually be assigned to different machines. So that's something to watch out for in implementations of identical = nodes connected to identical networks, especially without local = non-volatile storage. In that case, some other check should be performed to establish a = machine's identity (other than just keying on the IPv6 address), if this = is critical. rfc7217 also suggests using a different source for Network_ID, which can = greatly mitigate this risk e.g. using the burned in MAC address. If a host move out and back, eg, leave home to go to an office in the = morning and get back in the evening, whether its IPv6 address changes? = IPv6 address in the office would almost certainly be different to home, = as "prefix" will certainly be very different (unless using a VPN = tunnel). When returning home, it could be presumed the node will have remembered = the previous values of prefix, Net_Iface, Network_ID, DAD_Counter, = secret_key and thus obtain the same IPv6 address in the evening as in the morning. But strictly speaking, that's an implementation issue. Regards, Gengyu WEI Network Technology Center School of Computer=20 Beijing University of Posts and Telecommunications regards, RayH ------=_NextPart_000_000C_01D154A0.D8C1DFE0 Content-Type: text/html; charset="gb2312" Content-Transfer-Encoding: quoted-printable
Hi RayH,
 
Thank you for your explanations.
 
In Page 8 of RFC7212,
secret_key:
A secret key that is not known by the attacker. The secret
key SHOULD be of at least 128 bits. It MUST be initialized to
a pseudo-random number (see [RFC4086] for randomness
requirements for security) when the operating system is
installed or when the IPv6 protocol stack is "bootstrapped"
for the first time. An implementation MAY provide the means
for the system administrator to display and change the secret
key.
 
Based on the above descriptions, it seems that the secret key needs = changing for randomness.
If  the secrete key is changge the new generate IPv6 address = will be=20 different.
Is it right?
Regards,
 
Gengyu=20 WEI
Network Technology Center
School of Computer
Beijing = University of=20 Posts and Telecommunications
 
From: Ray Hunter
Sent: Wednesday, January 20, 2016 7:52 PM
Cc: 6man WG=20
Subject: Re: = draft-ietf-6man-default-iids-08
 
Inline

Subject:=20
draft-ietf-6man-default-iids-08
From:=20
"weigengyu" <weigengyu@bupt.ed= u.cn>
Date: =
Mon, 18 = Jan 2016=20 16:17:14 +0800
To: =
<ipv6@ietf.org= >

Hi,
 
I have a question about draft-ietf-6man-default-iids-08.
 
Whether an IPv6 address of a host would be=20 changed?
Yes, it can change over = time, in=20 some circumstances.
If it is, in what situations does the IPv6 address change?=20
see below.


the RID =3D = F(Prefix,=20 Net_Iface, Network_ID, DAD_Counter, secret_key)

If any of the = input=20 variables change, the RID will change, and the resulting IPv6 address = will very=20 likely change.
 
In Page 3 of the draft,
=A1=B0As a result of the aforementioned issues, this document = recommends
the implementation of an alternative scheme ([RFC7217]) as = the
default stable IID generation scheme for SLAAC, such that = the
aforementioned issues are mitigated.=A1=B1
 
In Page 7 of RFC7212,
=A1=B0Compute a random (but stable) identifier with the = expression:
RID =3D F(Prefix, Net_Iface, Network_ID, DAD_Counter, = secret_key)=A1=B1
 
And in page 9 of RFC7252,
=A1=B02. The Interface Identifier is finally obtained by taking = as many
bits from the RID value (computed in the previous step) as
necessary, starting from the least significant bit.=A1=B1
 
 
If a host which does not move is rebooted, whether its IPv6 = address=20 changes?
In the case of a reboot, = it could=20 be assumed that the variables (prefix, Net_Iface, Network_ID, = DAD_Counter,=20 secret_key) do NOT change (i.e. values are likely to be non-volatile = over a=20 reboot). Therefore, the IPv6 address should not change.

An = exception=20 could be if a node does not have local storage to remember the value for = e.g.=20 the DAD_Counter.

There is generally a VERY SMALL chance that = nodes may=20 produce a collision, given sufficient entropy into the RID = function.

How=20 this is achieved is an implementation issue.

One corner case is = that If=20 nodes do not remember e.g. the DAD_counter over reboots. If there were = two or=20 more identical nodes, node-1 could claim an IPv6 address before the = other nodes=20 booted, and node-2 to node-n would detect a collision and increment = their=20 DAD_Counter and "back off". Previously the collision may have occurred = in a=20 different order (because one of the nodes node-2 to node-n booted = faster) and=20 node 1 "backed off". That would give the nodes different address = assignments.=20 Worse still: the IPv6 addresses would remain the same, but they'd = actually be=20 assigned to different machines.

So that's something to watch out = for in=20 implementations of identical nodes connected to identical networks, = especially=20 without local non-volatile storage.

In that case, some other = check should=20 be performed to establish a machine's identity (other than just keying = on the=20 IPv6 address), if this is critical.

rfc7217 also suggests using a = different source for Network_ID, which can greatly mitigate this risk = e.g. using=20 the burned in MAC address.

If a host move out and back, eg, leave home to go to an office in = the=20 morning and get back in the evening, whether its IPv6 address=20 changes?  

IPv6 = address=20 in the office would almost certainly be different to home, as "prefix" = will=20 certainly be very different (unless using a VPN tunnel).

When = returning=20 home, it could be presumed the node will have remembered the previous = values of=20 prefix, Net_Iface, Network_ID, DAD_Counter, secret_key

and thus = obtain=20 the same IPv6 address in the evening as in the morning.

But = strictly=20 speaking, that's an implementation issue.

 
 
Regards,
 
Gengyu=20 WEI
Network Technology Center
School of Computer
Beijing = University=20 of Posts and=20 Telecommunications

regards,RayH
------=_NextPart_000_000C_01D154A0.D8C1DFE0-- From nobody Thu Jan 21 07:17:32 2016 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0EE3D1B31CD for ; Thu, 21 Jan 2016 07:17:31 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.537 X-Spam-Level: X-Spam-Status: No, score=0.537 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, J_CHICKENPOX_16=0.6, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, STOX_REPLY_TYPE=0.439] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nq6oxm2l9eOo for ; Thu, 21 Jan 2016 07:17:30 -0800 (PST) Received: from mx1.bupt.edu.cn (mx1.bupt.edu.cn [211.68.68.2]) by ietfa.amsl.com (Postfix) with ESMTP id EFBD51B31C9 for ; Thu, 21 Jan 2016 07:17:29 -0800 (PST) Received: from mx1.bupt.edu.cn (unknown [127.0.0.1]) by mx1.bupt.edu.cn (AnyMacro(G7)) with SMTP id 4324519F383 for ; Thu, 21 Jan 2016 23:17:29 +0800 (HKT) Received: from WeiGengyuPC (unknown [221.219.184.182]) by mx1.bupt.edu.cn (AnyMacro(G7)) with ESMTPA id 1AE9619F36F; Thu, 21 Jan 2016 23:17:29 +0800 (HKT) Message-ID: <1EF23A58A95F41E98C04B18F00559596@WeiGengyuPC> From: "weigengyu" To: , "Fernando Gont" References: <09178529BD77411993873F761BE6F722@WeiGengyuPC> <56A01A43.2030705@si6networks.com> In-Reply-To: <56A01A43.2030705@si6networks.com> Subject: Re: draft-ietf-6man-default-iids-08 Date: Thu, 21 Jan 2016 23:17:31 +0800 Organization: BUPT MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="UTF-8"; reply-type=original Content-Transfer-Encoding: 8bit X-Priority: 3 X-MSMail-Priority: Normal Importance: Normal X-Mailer: Microsoft Windows Live Mail 16.4.3528.331 X-MimeOLE: Produced By Microsoft MimeOLE V16.4.3528.331 Archived-At: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Jan 2016 15:17:31 -0000 Hi Fernando, Thank you for your explanations. My question is ralated to whether the secure key is changed. In page 8 of RFC7212, secret_key: A secret key that is not known by the attacker. The secret key SHOULD be of at least 128 bits. It MUST be initialized to a pseudo-random number (see [RFC4086] for randomness requirements for security) when the operating system is installed or when the IPv6 protocol stack is "bootstrapped" for the first time. An implementation MAY provide the means for the system administrator to display and change the secret key. Based on the above descriptions, it seems that the secret key needs changing for randomness. If the secrete key is changge the new generate IPv6 address will be different. The same problem has also been sent to RayH. I gesst that each time the new generated IPv6 address is differen as RID is effected by F() with a parameter of the secure key which is an randomness. Regards, Gengyu WEI Network Technology Center School of Computer Beijing University of Posts and Telecommunications -----原始邮件----- From: Fernando Gont Sent: Thursday, January 21, 2016 7:37 AM To: weigengyu ; ipv6@ietf.org Subject: Re: draft-ietf-6man-default-iids-08 Hello, Gengyu, On 01/18/2016 05:17 AM, weigengyu wrote: > > I have a question about draft-ietf-6man-default-iids-08. > > Whether an IPv6 address of a host would be changed? > If it is, in what situations does the IPv6 address change? When a node moves from one network to another. It will certainly change when the Prefix used for auto-configuration changes, and may also change if such prefix stays the same but the network (e.g, SSID) changes. > In Page 3 of the draft, > “As a result of the aforementioned issues, this document recommends > the implementation of an alternative scheme ([RFC7217]) as the > default stable IID generation scheme for SLAAC, such that the > aforementioned issues are mitigated.†> > In Page 7 of RFC7212, > “Compute a random (but stable) identifier with the expression: > RID = F(Prefix, Net_Iface, Network_ID, DAD_Counter, secret_key)†> > And in page 9 of RFC7252, > “2. The Interface Identifier is finally obtained by taking as many > bits from the RID value (computed in the previous step) as > necessary, starting from the least significant bit.†> > > If a host which does not move is rebooted, whether its IPv6 address > changes? It will not, since the secret_key will stay the same. > If a host move out and back, eg, leave home to go to an office in the > morning and get back in the evening, > whether its IPv6 address changes? It will not. That's one of the design goals of RFC7217. Thanks! Best regards, -- Fernando Gont SI6 Networks e-mail: fgont@si6networks.com PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492 From nobody Thu Jan 21 21:08:49 2016 Return-Path: X-Original-To: ipv6@ietf.org Delivered-To: ipv6@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 227801B3848; Thu, 21 Jan 2016 21:08:47 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: Subject: I-D Action: draft-ietf-6man-rfc4291bis-01.txt X-Test-IDTracker: no X-IETF-IDTracker: 6.13.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20160122050847.7503.12366.idtracker@ietfa.amsl.com> Date: Thu, 21 Jan 2016 21:08:47 -0800 Archived-At: Cc: ipv6@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.15 List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 22 Jan 2016 05:08:47 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the IPv6 Maintenance Working Group of the IETF. Title : IP Version 6 Addressing Architecture Authors : Robert M. Hinden Stephen E. Deering Filename : draft-ietf-6man-rfc4291bis-01.txt Pages : 30 Date : 2016-01-21 Abstract: This specification defines the addressing architecture of the IP Version 6 (IPv6) protocol. The document includes the IPv6 addressing model, text representations of IPv6 addresses, definition of IPv6 unicast addresses, anycast addresses, and multicast addresses, and an IPv6 node's required addresses. This document obsoletes RFC 4291, "IP Version 6 Addressing Architecture". The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-6man-rfc4291bis/ There's also a htmlized version available at: https://tools.ietf.org/html/draft-ietf-6man-rfc4291bis-01 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-6man-rfc4291bis-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 nobody Thu Jan 21 21:17:10 2016 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7D4B71B384B for ; Thu, 21 Jan 2016 21:17:08 -0800 (PST) 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=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0Orkq6Anz0hV for ; Thu, 21 Jan 2016 21:17:06 -0800 (PST) Received: from mail-ig0-x22f.google.com (mail-ig0-x22f.google.com [IPv6:2607:f8b0:4001:c05::22f]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9C80D1B3849 for ; Thu, 21 Jan 2016 21:17:06 -0800 (PST) Received: by mail-ig0-x22f.google.com with SMTP id ik10so3910438igb.1 for ; Thu, 21 Jan 2016 21:17:06 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=content-type:mime-version:subject:from:date:cc:message-id :references:to; bh=9k1mQ3fMVsguLT8FugLqfyQynGiFmX/AfOlF9vjM1o4=; b=VzzjGR8yM8I4v7Z4ojwFgz3W8b4Dlugqm1HpTBJeqYu9D+3jOR/BQfwrV18UJJM64L KjHyAuuVWZALY+J6axbX916AN8HCsa+UVlbzZFLXIpKfDckOcYnE7EICqwshOjW6AVXx UoZ/cdaKVLku2OdqKsiOLuhT+7GXuPt2XDGSqNhML0ZIQ5AJu6QA1OL4oEcM0yKLX/vv DvVWqzvcIG8CkB+P38xxiEyeUH5KgCUKRThPI1dDyM0+4ecSo/Sw7n29pmenFb3AEOyo ddnYMOCVuagENPjMUrgHhB+x3Uq4IS7DPs5JE1hghOW9dINBp2WIEx+3w2Dk1/HdXmK2 BoPQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:content-type:mime-version:subject:from:date:cc :message-id:references:to; bh=9k1mQ3fMVsguLT8FugLqfyQynGiFmX/AfOlF9vjM1o4=; b=LzgyRuHt982bKiPGtK3T2WJsdRgZ+qUJy3+51dn4nW28vZnuMbM1AiBfPWHltPaVYd VEWEAxlJx/xdiVxUUkxGq6ZIHz3uQGAQb8YWmcu190QHysgOjbHObMMHg6NRI28g7RFn MMb4bBY/RY9OnBAgDHcpMGTpmfvltMUFwQ7TrZajBrBnmOaMac+OCHsPbjtI7SK19C5d dlE8ab590xCEzOF89egvlyc/ED5atAjcjRA1m3xtOrfcqyBPXSyn2IayasQ3+4zkGcZY fblJKWclWGK9XPYDKewSQ3Ymflud6SrOmt/UmxeA8w5+DWya6/RdXngwZnVwwDu8GtIn 6CoA== X-Gm-Message-State: AG10YOTf2gje9Xm4M/CBuCsRzx+4RMWak9d6z3RAzMQh4OuRuwge0k24efWQ7UP6UpcSmA== X-Received: by 10.50.43.133 with SMTP id w5mr1525800igl.52.1453439826095; Thu, 21 Jan 2016 21:17:06 -0800 (PST) Received: from [10.0.0.24] (c-71-202-19-53.hsd1.ca.comcast.net. [71.202.19.53]) by smtp.gmail.com with ESMTPSA id a5sm725950iga.7.2016.01.21.21.17.05 (version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Thu, 21 Jan 2016 21:17:05 -0800 (PST) Content-Type: multipart/signed; boundary="Apple-Mail=_C52D60D8-D899-48C0-9661-B6D80A32345A"; protocol="application/pgp-signature"; micalg=pgp-sha512 Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2104\)) Subject: X-Pgp-Agent: GPGMail 2.5.2 From: Bob Hinden Date: Thu, 21 Jan 2016 21:17:03 -0800 Message-Id: <751EAA65-656A-4520-813E-3FD3CE2D1D63@gmail.com> References: <20150804195752.5065.13523.idtracker@ietfa.amsl.com> To: IPv6 List X-Mailer: Apple Mail (2.2104) Archived-At: Cc: Bob Hinden X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 22 Jan 2016 05:17:08 -0000 --Apple-Mail=_C52D60D8-D899-48C0-9661-B6D80A32345A Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Hi, I published the second 6man w.g. version (-01) version of the RFC4291bis = draft. See links below. This is based on the discussion on the mailing list. The changes in = this version to revise Section 2.4.1 on Interface Identifiers to reflect = current approach, this included saying Modified EUI-64 identifiers are = not recommended and moved the text describing the format to Appendix A. = There were a few editorial changes as well. A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-6man-rfc4291bis-01 This is part of the project to move the core IPv6 specifications to = Internet Standard. Thanks, Bob > On Jan 21, 2016, at 9:08 PM, internet-drafts@ietf.org wrote: >=20 > A new version of I-D, draft-ietf-6man-rfc4291bis-01.txt > has been successfully submitted by Robert M. Hinden and posted to the > IETF repository. >=20 > Name: draft-ietf-6man-rfc4291bis > Revision: 01 > Title: IP Version 6 Addressing Architecture > Document date: 2016-01-21 > Group: 6man > Pages: 30 > URL: = https://www.ietf.org/internet-drafts/draft-ietf-6man-rfc4291bis-01.txt > Status: = https://datatracker.ietf.org/doc/draft-ietf-6man-rfc4291bis/ > Htmlized: = https://tools.ietf.org/html/draft-ietf-6man-rfc4291bis-01 > Diff: = https://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-6man-rfc4291bis-01 >=20 > Abstract: > This specification defines the addressing architecture of the IP > Version 6 (IPv6) protocol. The document includes the IPv6 = addressing > model, text representations of IPv6 addresses, definition of IPv6 > unicast addresses, anycast addresses, and multicast addresses, and = an > IPv6 node's required addresses. >=20 > This document obsoletes RFC 4291, "IP Version 6 Addressing > Architecture". --Apple-Mail=_C52D60D8-D899-48C0-9661-B6D80A32345A 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 - https://gpgtools.org iQEcBAEBCgAGBQJWobtQAAoJEK7rdBF357uoW2kH/0/EblcJUzFwP8UUOwkaSlRn KGMqFw9phUomLUXbyjo8HDH4jT1id8cGFB6P67idTQLosABqcOqsKHTZvSN5/ZZI F6pVZqelBd08A5BUf2Zvn2wnb//McbTYOHZnXSqK2CYtkZGUx6EH3p/eQJLCEB8U /k38zUSU6YhONi14Oh/o5voCfebwilycRiYyiIeuynUaE6JyNhjEghln8+tCjqO0 diKsQLiECtfGRLpbXSy9tQluz4Q07P4INEJQefaUbTPLR0D5W70gCp0r3XnaaTFe SBw7Uiv92w+z50KYtK0OZbr1vgA8UYw4nDbyUWJqIUPE5bN6htoqt9WbgTvufM4= =Umqp -----END PGP SIGNATURE----- --Apple-Mail=_C52D60D8-D899-48C0-9661-B6D80A32345A-- From nobody Thu Jan 21 22:59:37 2016 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 60E191A892F; Thu, 21 Jan 2016 22:59:28 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 2.852 X-Spam-Level: ** X-Spam-Status: No, score=2.852 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, FH_RELAY_NODNS=1.451, HTML_MESSAGE=0.001, LOCALPART_IN_SUBJECT=1.107, RDNS_NONE=0.793] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id d8784W_iMKK8; Thu, 21 Jan 2016 22:59:20 -0800 (PST) Received: from mxfz.ruijie.com.cn (unknown [120.35.11.201]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id F0AB01A8928; Thu, 21 Jan 2016 22:59:19 -0800 (PST) Received: from FZEX2.ruijie.com.cn ([fe80::8d50:8240:513b:8e5b]) by fzex.ruijie.com.cn ([fe80::40d6:9d36:49e3:7754%11]) with mapi id 14.03.0123.003; Fri, 22 Jan 2016 14:59:10 +0800 From: To: Subject: draft-ietf-6man-rfc4291bis Thread-Topic: draft-ietf-6man-rfc4291bis Thread-Index: AdFU4RKwUF4WpW4TQYC0mBT9kDYUOgAAPYXg Date: Fri, 22 Jan 2016 06:59:09 +0000 Message-ID: Accept-Language: zh-CN, en-US Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [192.168.21.106] Content-Type: multipart/alternative; boundary="_000_C3CD550189AC3744AC5CB5640DF4A5889A2C9546fzex2ruijiecomc_" MIME-Version: 1.0 Archived-At: Cc: ipv6@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 22 Jan 2016 06:59:28 -0000 --_000_C3CD550189AC3744AC5CB5640DF4A5889A2C9546fzex2ruijiecomc_ Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: base64 ZHJhZnQtaWV0Zi02bWFuLXJmYzQyOTFiaXMNCjIuNC42PGh0dHBzOi8vdG9vbHMuaWV0Zi5vcmcv aHRtbC9kcmFmdC1pZXRmLTZtYW4tcmZjNDI5MWJpcy0wMSNzZWN0aW9uLTIuNC42Pi4gIExpbmst TG9jYWwgSVB2NiBVbmljYXN0IEFkZHJlc3Nlcw0KDQoNCg0KDQoNCiAgIExpbmstTG9jYWwgYWRk cmVzc2VzIGFyZSBmb3IgdXNlIG9uIGEgc2luZ2xlIGxpbmsuICBMaW5rLUxvY2FsDQoNCiAgIGFk ZHJlc3NlcyBoYXZlIHRoZSBmb2xsb3dpbmcgZm9ybWF0Og0KDQoNCg0KICAgfCAgIDEwICAgICB8 DQoNCiAgIHwgIGJpdHMgICAgfCAgICAgICAgIDU0IGJpdHMgICAgICAgICB8ICAgICAgICAgIDY0 IGJpdHMgICAgICAgICAgIHwNCg0KICAgKy0tLS0tLS0tLS0rLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLSstLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tKw0KDQogICB8MTExMTExMTAxMHwgICAg ICAgICAgIDAgICAgICAgICAgICAgfCAgICAgICBpbnRlcmZhY2UgSUQgICAgICAgICB8DQoNCiAg ICstLS0tLS0tLS0tKy0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0rLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLSsNCg0KVGhlIGRlZmluaXRpb24gaXMgd3JvbmcuVGhlIG1pZGRsZSA1NCBiaXRz IGNhbiBiZSBhbnkgdmFsdWUuUGxlYXNlIGZpeCBpdC4NCg0K --_000_C3CD550189AC3744AC5CB5640DF4A5889A2C9546fzex2ruijiecomc_ Content-Type: text/html; charset="gb2312" Content-Transfer-Encoding: quoted-printable

draft-ietf-6= man-rfc4291bis

2.4.6.  Link-Local IPv6 Unicast Addresses

 
 
   Link-Local addresses are for use on a=
 single link.  Link-Local
   addresses have the following format:<=
o:p>
 
   |   10    &n=
bsp;|
   |  bits    | =
;        54 bits    =
     |        &=
nbsp; 64 bits           |=

   +----------+-----------------=
--------+----------------------------+
   |1111111010|    &=
nbsp;      0      &n=
bsp;      |       in=
terface ID         |
   +----------+-----------------=
--------+----------------------------+

 

The definition is wrong.The mid= dle 54 bits can be any value.Please fix it.

 

--_000_C3CD550189AC3744AC5CB5640DF4A5889A2C9546fzex2ruijiecomc_-- From nobody Fri Jan 22 05:03:29 2016 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 777081A212A; Fri, 22 Jan 2016 05:03:27 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.498 X-Spam-Level: X-Spam-Status: No, score=-1.498 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, FROM_LOCAL_NOVOWEL=0.5, HK_RANDOM_ENVFROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ToLx-TDxyYJT; Fri, 22 Jan 2016 05:03:25 -0800 (PST) Received: from mail-vk0-x22f.google.com (mail-vk0-x22f.google.com [IPv6:2607:f8b0:400c:c05::22f]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 702491A1F1D; Fri, 22 Jan 2016 05:03:25 -0800 (PST) Received: by mail-vk0-x22f.google.com with SMTP id e64so41031810vkg.0; Fri, 22 Jan 2016 05:03:25 -0800 (PST) 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=ysvRAy0g1HNzDSsSXqn60Qi40gz0eJOa0OJBxUAn3XM=; b=xJitH7BOufb12senzgjww/mES1jGsetBNepPtGZAP5zhXKc7BXI9lD2DG+kSnXuCgx yisFiYEi82eWERBArldRhQDYsH2omisK5ZM8GwqOFrP3wUDsfN1yuNitckGVBWd40MjD V/Z7yTFE9iyRgHEArTl+ZxcJVw4fAsbeUtobbIqh9+spc4romBPdg5NJA72saBm0bW/T +kvKOtkqcL8ydH9IyJ0JHKk+DuaO1t/zkB4fGV87JHwXd88fjP1kel3TRCMIBzrI+RJd Htoek6e/fKhfvXfHXmdCBt3Hgos+RW0VfeWMs15nteh4hLaNO/8R9375+qIYt7lpZVcG iBYA== 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:date :message-id:subject:from:to:cc:content-type; bh=ysvRAy0g1HNzDSsSXqn60Qi40gz0eJOa0OJBxUAn3XM=; b=bXfPAzZ87LH6+OTCQSGpXWeYkJxczvA+/OVNAjEWR7ViIySLyRNzA6/BbIkDDs028f 0JhB+ZucYoC9VX30KC6xJ/cDhzuE1/cPIpOAVRmV54pJqCvHUk5cFXADo067h9qvc0tg BzJv8xI7qLnJD3qhiRk4l2kYIWBM95KoqGB5s/NmJ3mE+BeRRcSYEzX/sdKjs/e/zv0y vvLER+Hki0ONuzWvMl3CFgjoXh/KgI7aS+5VEbWR1R7fq40BUnDW3tkyM19JOr7XPyZD hFGZ7Ku7YzifcQ05s0j19Mp+uxsqamifJsSTOHuvxz1WO97TLurHjFmRXrV6s1qsOesU xNRQ== X-Gm-Message-State: AG10YOQEQdG0lkf8SgCrhsEEsPpahny1pMl8AT21UHdsj91mhHqP2thC0VbiUpEKakmVDdjNpAdrwjyM/lvzXA== MIME-Version: 1.0 X-Received: by 10.31.6.143 with SMTP id 137mr1747718vkg.133.1453467804491; Fri, 22 Jan 2016 05:03:24 -0800 (PST) Received: by 10.103.99.1 with HTTP; Fri, 22 Jan 2016 05:03:24 -0800 (PST) Received: by 10.103.99.1 with HTTP; Fri, 22 Jan 2016 05:03:24 -0800 (PST) In-Reply-To: References: Date: Sat, 23 Jan 2016 00:03:24 +1100 Message-ID: Subject: Re: draft-ietf-6man-rfc4291bis From: Mark Smith To: yhb@ruijie.com.cn Content-Type: multipart/alternative; boundary=001a1143d3382dea3e0529ebd817 Archived-At: Cc: 6man WG , draft-ietf-6man-rfc4291bis@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 22 Jan 2016 13:03:27 -0000 --001a1143d3382dea3e0529ebd817 Content-Type: text/plain; charset=UTF-8 On 22 Jan 2016 5:29 PM, wrote: > > draft-ietf-6man-rfc4291bis > > 2.4.6. Link-Local IPv6 Unicast Addresses > > > > > > Link-Local addresses are for use on a single link. Link-Local > > addresses have the following format: > > > > | 10 | > > | bits | 54 bits | 64 bits | > > +----------+-------------------------+----------------------------+ > > |1111111010| 0 | interface ID | > > +----------+-------------------------+----------------------------+ > > > > The definition is wrong.The middle 54 bits can be any value.Please fix it. > How did you come to that conclusion? Some implementations might be tolerant of non-zero values in those 54 bits, but that doesn't make the definition wrong. > > > > -------------------------------------------------------------------- > IETF IPv6 working group mailing list > ipv6@ietf.org > Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 > -------------------------------------------------------------------- > --001a1143d3382dea3e0529ebd817 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On 22 Jan 2016 5:29 PM, <yhb@ruijie= .com.cn> wrote:
>
> draft-ietf-6man-rfc4291bis
>
> 2.4.6.=C2=A0 Link-Local IPv6 Unicast Addresses
>
> =C2=A0
>
> =C2=A0
>
> =C2=A0=C2=A0 Link-Local addresses are for use on a single link.=C2=A0 = Link-Local
>
> =C2=A0=C2=A0 addresses have the following format:
>
> =C2=A0
>
> =C2=A0=C2=A0 |=C2=A0=C2=A0 10=C2=A0=C2=A0 =C2=A0=C2=A0|
>
> =C2=A0=C2=A0 |=C2=A0 bits=C2=A0=C2=A0=C2=A0 |=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0 54 bits=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0 |=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 64 bits=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 |
>
> =C2=A0=C2=A0 +----------+-------------------------+-------------------= ---------+
>
> =C2=A0=C2=A0 |1111111010|=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0 0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0 |=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 interface ID=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 |
>
> =C2=A0=C2=A0 +----------+-------------------------+-------------------= ---------+
>
> =C2=A0
>
> The definition is wrong.The middle 54 bits can be any value.Please fix= it.
>

How did you come to that conclusion?

Some implementations might be tolerant of non-zero values in= those 54 bits, but that doesn't make the definition wrong.

> =C2=A0
>
>
> -------------------------------------------------------------------- > IETF IPv6 working group mailing list
> ipv6@ietf.org
> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
> -------------------------------------------------------------------- >

--001a1143d3382dea3e0529ebd817-- From nobody Fri Jan 22 05:18:02 2016 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CFC1E1A6EFB; Fri, 22 Jan 2016 05:18:00 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.094 X-Spam-Level: X-Spam-Status: No, score=0.094 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HELO_EQ_NL=0.55, HOST_EQ_NL=1.545, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UJcK7PmnZMH7; Fri, 22 Jan 2016 05:17:59 -0800 (PST) Received: from mail.sintact.nl (mail.sintact.nl [IPv6:2001:9e0:803::6]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 25B6C1A6EE8; Fri, 22 Jan 2016 05:17:58 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by mail.sintact.nl (Postfix) with ESMTP id 4741A90; Fri, 22 Jan 2016 14:17:56 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=steffann.nl; h= x-mailer:references:message-id:date:date:in-reply-to:from:from :content-type:content-type:mime-version:subject:subject:received :received; s=mail; t=1453468674; bh=Ph8pUEnlN+E20Eyp4rR/UuHcvDjc tIwdnNTYkJc5RRE=; b=h4QrGrSKoLIi1Fr+d/H1pbQU87etVb7/liIdMnP9lDyc ACDPrxvh28petWCzdOfjvOIbHcWM9N0b8rVXMcy73pjBsc4/avNqtMR3YimYzBSq X/lGzfRvrkaffepl6mE3agomfxJi6kKMUgGU3mZUASD0MRM7NnwF11Qn+2oySys= 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 10026) with ESMTP id nLXo2VKvCH9u; Fri, 22 Jan 2016 14:17:54 +0100 (CET) Received: from [IPv6:2a00:8640:1::a94f:4207:3eb5:96b1] (unknown [IPv6:2a00:8640:1:0:a94f:4207:3eb5:96b1]) by mail.sintact.nl (Postfix) with ESMTPSA id 367F034; Fri, 22 Jan 2016 14:17:53 +0100 (CET) Subject: Re: draft-ietf-6man-rfc4291bis Mime-Version: 1.0 (Mac OS X Mail 9.2 \(3112\)) Content-Type: multipart/signed; boundary="Apple-Mail=_7BC4299D-1022-4DF6-84BF-52C3370E2A40"; protocol="application/pgp-signature"; micalg=pgp-sha256 X-Pgp-Agent: GPGMail 2.6b2 X-Clacks-Overhead: GNU Terry Pratchett From: Sander Steffann In-Reply-To: Date: Fri, 22 Jan 2016 14:17:52 +0100 Message-Id: References: To: Mark Smith X-Mailer: Apple Mail (2.3112) Archived-At: Cc: 6man WG , yhb@ruijie.com.cn, draft-ietf-6man-rfc4291bis@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 22 Jan 2016 13:18:01 -0000 --Apple-Mail=_7BC4299D-1022-4DF6-84BF-52C3370E2A40 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Hi, >> | 10 | >> | bits | 54 bits | 64 bits = | >> = +----------+-------------------------+----------------------------+ >> |1111111010| 0 | interface ID = | >> = +----------+-------------------------+----------------------------+ >>=20 >> The definition is wrong.The middle 54 bits can be any value.Please = fix it. >=20 > How did you come to that conclusion? >=20 > Some implementations might be tolerant of non-zero values in those 54 = bits, but that doesn't make the definition wrong. It has always been interesting that a /10 is reserved for link-local = while only a /64 is commonly used. The 54 bits in the middle could be = anything, but they are always 0. FreeBSD even uses that assumption to = store the scope-id in those bits: = https://www.freebsd.org/doc/en_US.ISO8859-1/books/developers-handbook/ipv6= .html#ipv6-scope-index I *did* go WTF when Gert D=C3=B6ring pointed that out to me... Cheers, Sander --Apple-Mail=_7BC4299D-1022-4DF6-84BF-52C3370E2A40 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----- iQEcBAEBCAAGBQJWoiwAAAoJEEZCmN6EpRAQDzIH/28cIn6nyrLWyfnYq97S0KCh A22RXcpzGJXNaSd3unkzSc9j0j6CPsn2g5UVzVQh6BMWwrmAyGr50ts8exPDYgVJ AxM1p/HGicgNjEVohmBP9JzJHhAegPOqSVnsSFdAdJIzVyDnwaVv3pAbeO8eCIBG ygyFf8QRdY6qsigu+m00eJwfhcZSmsHWLI3nXV1EQJq4LwhpOknUvL+lj58UvvbL SC23FhOL7ereCADkj6rOawc6CO5cv9k2CI2T5QRBgxSJ6ZsbqsDYxEyOulSiTwgp +oJdSj7BS3btyPiL9hyZpIv7Gk20qPwCKQb4N9G0mAFhXFtmFyd/by0m3LPjXlk= =KUzh -----END PGP SIGNATURE----- --Apple-Mail=_7BC4299D-1022-4DF6-84BF-52C3370E2A40-- From nobody Fri Jan 22 09:00:12 2016 Return-Path: X-Original-To: ipv6@ietf.org Delivered-To: ipv6@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 51F7E1B2A0B; Fri, 22 Jan 2016 09:00:10 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: Subject: I-D Action: draft-ietf-6man-rfc2460bis-03.txt X-Test-IDTracker: no X-IETF-IDTracker: 6.13.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20160122170010.6234.60280.idtracker@ietfa.amsl.com> Date: Fri, 22 Jan 2016 09:00:10 -0800 Archived-At: Cc: ipv6@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.15 List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 22 Jan 2016 17:00:10 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the IPv6 Maintenance Working Group of the IETF. Title : Internet Protocol, Version 6 (IPv6) Specification Authors : Stephen E. Deering Robert M. Hinden Filename : draft-ietf-6man-rfc2460bis-03.txt Pages : 37 Date : 2016-01-22 Abstract: This document specifies version 6 of the Internet Protocol (IPv6). It obsoletes RFC2460 The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-6man-rfc2460bis/ There's also a htmlized version available at: https://tools.ietf.org/html/draft-ietf-6man-rfc2460bis-03 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-6man-rfc2460bis-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 nobody Fri Jan 22 09:08:50 2016 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CF7511B2A69 for ; Fri, 22 Jan 2016 09:08:48 -0800 (PST) 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=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xVo3b1XcyRq9 for ; Fri, 22 Jan 2016 09:08:47 -0800 (PST) Received: from mail-qg0-x22a.google.com (mail-qg0-x22a.google.com [IPv6:2607:f8b0:400d:c04::22a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1AA651B2A27 for ; Fri, 22 Jan 2016 09:08:47 -0800 (PST) Received: by mail-qg0-x22a.google.com with SMTP id e32so62434610qgf.3 for ; Fri, 22 Jan 2016 09:08:47 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=from:content-type:subject:date:message-id:cc:to:mime-version; bh=cabvhxgiBTyZC/HvfBnOdWKvS5+A1EqSxu53siZK+AM=; b=PRK5wtLzsH/StYkB2GurBj5/pgfrnW+qiQYDL5oFA44MJ/bh/wUYY26zujiraEeWQp PtjsfEEbMKEJK2mR4TDmhoHVxjPG9aQwO9CSJrNZCDZxiUPSPMtznxslYJEODcw3O7cb UjrLiWkC2DPZnToZNzuMqP6d0sAl6ahinwWd1eb97yTkHzsCNABGFncGZJ2EEvmcgOmL B6tb9Xi3LFghlZV0gd2dHO8HS6SjSDeLEcuRuKeBrOCpqfxQ6FNOJtaeMaH08MtClfwp gYN8OWlhplndGiLOe4E1Lf3bSghAJlh+VnS7IC/XTmMkawMm/8UKjqPHHJT924qP9ulP OkfQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:from:content-type:subject:date:message-id:cc:to :mime-version; bh=cabvhxgiBTyZC/HvfBnOdWKvS5+A1EqSxu53siZK+AM=; b=B3n5qG8Wd3qDiiwkQfIxoNuHPhOeAV5eEo/c6vHvn3mN8X6F53jFAWnamcGtusY9/y sRBk2s1Po626in7vkvu8buBdP4bzxkuVBacy0Mts9B0TcccZcP9d9BTCOfxN6aKPtdzx aE4tmOPGQkuq4O0E/RbDfDu4yN4w72bHGMREfpRDTnXxkU8xF2Uku3UGpiaEmKAZ+6qX mF0U4CQJxw/cTCQ9ykMknRPOx7lBrSvxp+hpU2d1a+mXv1udcxtvqCsNRzubQkfFG1Mz lmP1CodU28JEjSqAZk90QbxQvi2MuqWprIDE83RLmMeD0sqaNaiN9tDxqpo9uyOA6NLe ltug== X-Gm-Message-State: AG10YOQwt8w6njnbqJww75m7hP3rnqdebSzlff5qyJZHRcWpYkEVjm/9F9acM1vC5UmS1w== X-Received: by 10.140.144.16 with SMTP id 16mr5258988qhq.81.1453482526333; Fri, 22 Jan 2016 09:08:46 -0800 (PST) Received: from ?IPv6:2601:647:4d00:abf0:146:3b18:5d4a:b519? ([2601:647:4d00:abf0:146:3b18:5d4a:b519]) by smtp.gmail.com with ESMTPSA id w63sm3130388qgw.6.2016.01.22.09.08.44 (version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Fri, 22 Jan 2016 09:08:45 -0800 (PST) From: Bob Hinden X-Pgp-Agent: GPGMail 2.5.2 Content-Type: multipart/signed; boundary="Apple-Mail=_0D65F5A9-6B69-405B-B1D1-69909BBFC786"; protocol="application/pgp-signature"; micalg=pgp-sha512 Subject: Date: Fri, 22 Jan 2016 09:08:41 -0800 Message-Id: <47F937E4-49D4-43CD-9D0A-26DFD0867D4A@gmail.com> To: IPv6 List Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2104\)) X-Mailer: Apple Mail (2.2104) Archived-At: Cc: Bob Hinden X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 22 Jan 2016 17:08:49 -0000 --Apple-Mail=_0D65F5A9-6B69-405B-B1D1-69909BBFC786 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Hi, I published the -03 version of 6man working group draft of rfc2460bis. = Links below. The changes include: Clarified the text about decrementing the hop limit as discussed = on the list. Removed "IP Next Generation" from the Abstract. Add a reference to the end of Section 4 to the IPv6 Extension Header IANA registry. Editorial changes. A diff from the -02 version can be found at: https://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-6man-rfc2460bis-03 Please review the changes. This is part of the project to move the core IPv6 specifications to = Internet Standard. Thanks, Bob > A New Internet-Draft is available from the on-line Internet-Drafts = directories. > This draft is a work item of the IPv6 Maintenance Working Group of the = IETF. >=20 > Title : Internet Protocol, Version 6 (IPv6) = Specification > Authors : Stephen E. Deering > Robert M. Hinden > Filename : draft-ietf-6man-rfc2460bis-03.txt > Pages : 37 > Date : 2016-01-22 >=20 > Abstract: > This document specifies version 6 of the Internet Protocol (IPv6). > It obsoletes RFC2460 >=20 >=20 > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-ietf-6man-rfc2460bis/ >=20 > There's also a htmlized version available at: > https://tools.ietf.org/html/draft-ietf-6man-rfc2460bis-03 >=20 > A diff from the previous version is available at: > https://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-6man-rfc2460bis-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/ --Apple-Mail=_0D65F5A9-6B69-405B-B1D1-69909BBFC786 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 - https://gpgtools.org iQEcBAEBCgAGBQJWomIZAAoJEK7rdBF357uoCioH/3oDo4zvCjJPnqCI+eOmYe5B MCUnd+H+S0TELz00e6qaEm+sfEhuR5tE9cUCvi6Chv5qOespXFCyjkRJnZLq6NNv HCojNd3+fMyitjJqlqla+27+mFR30oP0pL/FhumvIB69Q3wyYQr8MmhQNUOt/09z 2M4GHLXkBodjigCIUTUH+S1qmZm//fl1PT6Bana+lI7KvkHS49alQb+GDZo+vAZY NViTaha+d3LnOgBOPON4FDXjblJLzT/ne7JyJHiguNb5wTVYmrlwOlpK2v/EL9od 25v4w6GDeHoJGGefX8BlnZZnAbOLksijVtlAjC7F3wUDav71AWsl9JITRyUnArM= =q1Fk -----END PGP SIGNATURE----- --Apple-Mail=_0D65F5A9-6B69-405B-B1D1-69909BBFC786-- From nobody Fri Jan 22 11:10:56 2016 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C584A1B2C60; Fri, 22 Jan 2016 11:10:54 -0800 (PST) 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=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id da9kh7Q8RCyJ; Fri, 22 Jan 2016 11:10:53 -0800 (PST) Received: from mail-pf0-x22e.google.com (mail-pf0-x22e.google.com [IPv6:2607:f8b0:400e:c00::22e]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0AA0A1B2C5E; Fri, 22 Jan 2016 11:10:52 -0800 (PST) Received: by mail-pf0-x22e.google.com with SMTP id q63so47957564pfb.1; Fri, 22 Jan 2016 11:10:52 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=subject:to:references:cc:from:organization:message-id:date :user-agent:mime-version:in-reply-to:content-type :content-transfer-encoding; bh=vDsBNEHgYY7Efck3jAO/QJjXe6CVlG9O8+74Sc9Y2Fw=; b=C33c+gGI9USsDzOnQekEBqFTt3jQHvMHvlJPgAWkqefOLFZM1kMSIdckrIHzoBH/6G kFyhQuRmidjL6BcmV6tnAqNikKaW7p5FR/xjxdHmrFqUGuUaXF6xc9/Vmq+aglwfQfhg pH6e2YVWuOtNV/WroliFmNlo36kulVRJ9BN90SLq0phxBROSxgxSyUgehyuLTQ563k2L DoK0XI1GVhU3mo3IIF9yvkLauETasEo4vipwjVM4j34CmxIwu9Vls6HCT/1lbjbWU+DP JghcVNDmdwGXLIJkZarpfeZCighnDJl58QJeCuD1psWAYpYNhwGFR38w+24jH+eI4/Ah 2M9A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:subject:to:references:cc:from:organization :message-id:date:user-agent:mime-version:in-reply-to:content-type :content-transfer-encoding; bh=vDsBNEHgYY7Efck3jAO/QJjXe6CVlG9O8+74Sc9Y2Fw=; b=jJMwosQffUFakb++8o9AAsIb7E9nX4PMXlNH9l8iolOoE3HdDlQQOJaXqGkAG9P/bV Zw+xggxmyX+WwBK8QMTVpVdfn9/dWk6VHnKPt8Mk6ap3ODh6ubc3fhf7Y0TcxjtNB0H5 irn0YSp/psEuIZpqR226930KHpnfM1zpzHNBjy1UM/1JWyDpiXhLUs1R6igsD6VHGs+W UZPeSXjmc2I29N6rfk2BG3Tv6Pq1QnUdsDKs9iNCztHZzrbspU6fq26rATCl4zQlpae3 7yNNnaIoaG/VUiGEO/JZa/A+G4h78LGlb6k4scIHjgyzXZcFTWcItBCxSRc2ly0GumbS mbhg== X-Gm-Message-State: AG10YOTRXQjgqZvUAaDuI1ousKID70iebZey3T8kU6JzRiElq/0UqsspBRN/AqmUquJscQ== X-Received: by 10.98.72.130 with SMTP id q2mr6741112pfi.154.1453489852642; Fri, 22 Jan 2016 11:10:52 -0800 (PST) Received: from ?IPv6:2406:e007:7e5d:1:28cc:dc4c:9703:6781? ([2406:e007:7e5d:1:28cc:dc4c:9703:6781]) by smtp.gmail.com with ESMTPSA id f27sm11478951pfj.0.2016.01.22.11.10.49 (version=TLSv1/SSLv3 cipher=OTHER); Fri, 22 Jan 2016 11:10:51 -0800 (PST) Subject: Re: draft-ietf-6man-rfc4291bis To: Sander Steffann , Mark Smith References: From: Brian E Carpenter Organization: University of Auckland Message-ID: <56A27EC5.1060204@gmail.com> Date: Sat, 23 Jan 2016 08:11:01 +1300 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.5.1 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Archived-At: Cc: yhb@ruijie.com.cn, 6man WG , draft-ietf-6man-rfc4291bis@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 22 Jan 2016 19:10:54 -0000 On 23/01/2016 02:17, Sander Steffann wrote: > Hi, >=20 >>> | 10 | >>> | bits | 54 bits | 64 bits = | >>> +----------+-------------------------+----------------------------= + >>> |1111111010| 0 | interface ID = | >>> +----------+-------------------------+----------------------------= + >>> >>> The definition is wrong.The middle 54 bits can be any value.Please fi= x it. >> >> How did you come to that conclusion? >> >> Some implementations might be tolerant of non-zero values in those 54 = bits, but that doesn't make the definition wrong. >=20 > It has always been interesting that a /10 is reserved for link-local wh= ile only a /64 is commonly used. The 54 bits in the middle could be anyth= ing,=20 No, the standard has always said that they *are* zero. We attempted to cl= arify this in RFC 7421 - please see the bottom of this page: http://tools.ietf.org/html/rfc7421#page-11 > but they are always 0. FreeBSD even uses that assumption It's not an assumption; it's the standard. > to store the scope-id in those bits: >=20 > https://www.freebsd.org/doc/en_US.ISO8859-1/books/developers-handbook/i= pv6.html#ipv6-scope-index >=20 > I *did* go WTF when Gert D=C3=B6ring pointed that out to me... But it has nothing to do with bits on the wire; it's just a bit of magic inside the stack. As that manual entry says "When you specify scoped addr= es to the command line, NEVER write the embedded form..." Brian From nobody Fri Jan 22 11:22:29 2016 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 76CCF1B29EC for ; Fri, 22 Jan 2016 11:22:28 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.201 X-Spam-Level: X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id idMF4de4xHbM for ; Fri, 22 Jan 2016 11:22:26 -0800 (PST) Received: from phx-mbsout-02.mbs.boeing.net (phx-mbsout-02.mbs.boeing.net [130.76.184.179]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AAD051AD0A0 for ; Fri, 22 Jan 2016 11:22:26 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by phx-mbsout-02.mbs.boeing.net (8.14.4/8.14.4/DOWNSTREAM_MBSOUT) with SMTP id u0MJMPdV064774; Fri, 22 Jan 2016 12:22:26 -0700 Received: from XCH15-06-09.nw.nos.boeing.com (xch15-06-09.nw.nos.boeing.com [137.136.239.172]) by phx-mbsout-02.mbs.boeing.net (8.14.4/8.14.4/UPSTREAM_MBSOUT) with ESMTP id u0MJMGcP064661 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=OK); Fri, 22 Jan 2016 12:22:16 -0700 Received: from XCH15-06-11.nw.nos.boeing.com (2002:8988:efdc::8988:efdc) by XCH15-06-09.nw.nos.boeing.com (2002:8988:efac::8988:efac) with Microsoft SMTP Server (TLS) id 15.0.1130.7; Fri, 22 Jan 2016 11:22:15 -0800 Received: from XCH15-06-11.nw.nos.boeing.com ([137.136.239.220]) by XCH15-06-11.nw.nos.boeing.com ([137.136.239.220]) with mapi id 15.00.1130.005; Fri, 22 Jan 2016 11:22:16 -0800 From: "Manfredi, Albert E" To: Bob Hinden , IPv6 List Subject: RE: Thread-Topic: Thread-Index: AQHRVTebqd9Qx0rCnEWSph6aCHg9ZJ8H6TLA Date: Fri, 22 Jan 2016 19:22:16 +0000 Message-ID: References: <47F937E4-49D4-43CD-9D0A-26DFD0867D4A@gmail.com> In-Reply-To: <47F937E4-49D4-43CD-9D0A-26DFD0867D4A@gmail.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [137.136.248.6] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-TM-AS-MML: disable Archived-At: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 22 Jan 2016 19:22:28 -0000 > -----Original Message----- > From: ipv6 [mailto:ipv6-bounces@ietf.org] On Behalf Of Bob Hinden > I published the -03 version of 6man working group draft of rfc2460bis. L= inks > below. >=20 > The changes include: >=20 > Clarified the text about decrementing the hop limit as discussed on= the > list. >=20 > Removed "IP Next Generation" from the Abstract. >=20 > Add a reference to the end of Section 4 to the IPv6 Extension > Header IANA registry. >=20 > Editorial changes. >=20 > A diff from the -02 version can be found at: >=20 > https://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-6man-rfc2460bis-03 Bob, Did we decide to not include anything about byte transmission order, along = the lines of RFC 791 Appendix B? Thanks. Bert From nobody Fri Jan 22 11:56:11 2016 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 381CC1B2CF3; Fri, 22 Jan 2016 11:56:10 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.094 X-Spam-Level: X-Spam-Status: No, score=0.094 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HELO_EQ_NL=0.55, HOST_EQ_NL=1.545, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iU7MYBbHrIbP; Fri, 22 Jan 2016 11:56:08 -0800 (PST) Received: from mail.sintact.nl (mail.sintact.nl [83.247.10.6]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6FA901B2CF0; Fri, 22 Jan 2016 11:56:08 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by mail.sintact.nl (Postfix) with ESMTP id 5A97190; Fri, 22 Jan 2016 20:56:05 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=steffann.nl; h= x-mailer:references:message-id:date:date:in-reply-to:from:from :content-type:content-type:mime-version:subject:subject:received :received; s=mail; t=1453492563; bh=pW2nb3016bmxZosDCyLXG7eWZbkN wvjiM+KAXXpk/TE=; b=hrqXWbidhJF5EztJ8gbUHBSk7inVWp1Tqr3eMRwwclJh x9gA7m51gpCldmRoVq+AWFO1QR09NqQGAYKQ20k9/pgBlB+AKBHtVCMuFX2+Bwqw iI88kSCGiCLJjwHOYUjgNetJWvjVncgpBXM71PYlsu20jTJwKDTk7JMhY/Ww7F8= 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 10026) with ESMTP id h8PmRzDPqMoY; Fri, 22 Jan 2016 20:56:03 +0100 (CET) Received: from [IPv6:2a00:8640:1::71c8:d06b:f247:8276] (unknown [IPv6:2a00:8640:1:0:71c8:d06b:f247:8276]) by mail.sintact.nl (Postfix) with ESMTPSA id A7C2B37; Fri, 22 Jan 2016 20:56:02 +0100 (CET) Subject: Re: draft-ietf-6man-rfc4291bis Mime-Version: 1.0 (Mac OS X Mail 9.2 \(3112\)) Content-Type: multipart/signed; boundary="Apple-Mail=_7C7014CD-EA5F-4970-B79D-02461920D9AD"; protocol="application/pgp-signature"; micalg=pgp-sha256 X-Pgp-Agent: GPGMail 2.6b2 X-Clacks-Overhead: GNU Terry Pratchett From: Sander Steffann In-Reply-To: <56A27EC5.1060204@gmail.com> Date: Fri, 22 Jan 2016 20:56:01 +0100 Message-Id: References: <56A27EC5.1060204@gmail.com> To: Brian E Carpenter X-Mailer: Apple Mail (2.3112) Archived-At: Cc: yhb@ruijie.com.cn, 6man WG , draft-ietf-6man-rfc4291bis@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 22 Jan 2016 19:56:10 -0000 --Apple-Mail=_7C7014CD-EA5F-4970-B79D-02461920D9AD Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Hi Brian, >> It has always been interesting that a /10 is reserved for link-local = while only a /64 is commonly used. The 54 bits in the middle could be = anything, >=20 > No, the standard has always said that they *are* zero. We attempted to = clarify this > in RFC 7421 - please see the bottom of this page: > http://tools.ietf.org/html/rfc7421#page-11 True, I still had RFC 1884 in mind. RFC 2373 already updated that. I = feel old now :) >> but they are always 0. FreeBSD even uses that assumption >=20 > It's not an assumption; it's the standard. >=20 >> to store the scope-id in those bits: >>=20 >> = https://www.freebsd.org/doc/en_US.ISO8859-1/books/developers-handbook/ipv6= .html#ipv6-scope-index >>=20 >> I *did* go WTF when Gert D=C3=B6ring pointed that out to me... >=20 > But it has nothing to do with bits on the wire; it's just a bit of = magic > inside the stack. As that manual entry says "When you specify scoped = addres > to the command line, NEVER write the embedded form..." It will be a hell of a mess when some future RFC decides to use other = parts of fe80::/10 though :) It's still reserved space, even if it = isn't being used today. Maybe we should be pragmatic and explicitly = document fe80::/64 as the only bit of fe80::/10 that can ever be used, = to make sure some future RFC doesn't define that space and cause = problems for existing implementations. It's not likely we'll ever do = that anyway and there is plenty of other address space future RFCs can = use. Cheers, Sander --Apple-Mail=_7C7014CD-EA5F-4970-B79D-02461920D9AD 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----- iQEcBAEBCAAGBQJWoolRAAoJEKAtA7D+JBO5EPQH/RVk0a3O4bwNrOXJgnaNkx0Z DJ0rAkoDFBYZ4wIM21oLP0kfi0ociF2MtR3HmQCE2atWbhoe1HBJzf2MjC8pfAzx oOG88J/cXGQ2sTtj/vqQ8PRPhLLM5YwTpGXIb/9sMWhw/Bw7qTrdDmphZTEg+8ul NOkfiA/rGVIuc+eRM7TUD6QnsAFbRzqysw2yTB/YLbiU1Ujz/gt8E5Tx4Ra23581 vh6GGz0XtD/mdGiWnK6WHtuOlFah3kB7jBObasKOxrHfgKB8+2Kmi8F9NwdIUH7q X9VNoAe/xIVVmYOLyMZdKUAoqql5w4kmyyY+iQCQdI36Yq6idws+qKeOhcsffXI= =IlrF -----END PGP SIGNATURE----- --Apple-Mail=_7C7014CD-EA5F-4970-B79D-02461920D9AD-- From nobody Fri Jan 22 13:36:48 2016 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 665D51A8978; Fri, 22 Jan 2016 13:36:47 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QWmszKn5aZIj; Fri, 22 Jan 2016 13:36:45 -0800 (PST) Received: from fgont.go6lab.si (fgont.go6lab.si [91.239.96.14]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3A1C21A8977; Fri, 22 Jan 2016 13:36:45 -0800 (PST) Received: from [192.168.3.107] (unknown [181.165.125.191]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by fgont.go6lab.si (Postfix) with ESMTPSA id 26A332069FC; Fri, 22 Jan 2016 22:36:40 +0100 (CET) Subject: Re: draft-ietf-6man-rfc4291bis To: Sander Steffann , Mark Smith References: From: Fernando Gont X-Enigmail-Draft-Status: N1110 Message-ID: <56A27712.1060003@si6networks.com> Date: Fri, 22 Jan 2016 15:38:10 -0300 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.5.1 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 8bit Archived-At: Cc: yhb@ruijie.com.cn, 6man WG , draft-ietf-6man-rfc4291bis@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 22 Jan 2016 21:36:47 -0000 On 01/22/2016 10:17 AM, Sander Steffann wrote: > Hi, > >>> | 10 | >>> | bits | 54 bits | 64 bits | >>> +----------+-------------------------+----------------------------+ >>> |1111111010| 0 | interface ID | >>> +----------+-------------------------+----------------------------+ >>> >>> The definition is wrong.The middle 54 bits can be any value.Please fix it. >> >> How did you come to that conclusion? >> >> Some implementations might be tolerant of non-zero values in those 54 bits, but that doesn't make the definition wrong. > > It has always been interesting that a /10 is reserved for link-local while only a /64 is commonly used. The 54 bits in the middle could be anything, but they are always 0. FreeBSD even uses that assumption to store the scope-id in those bits: > > https://www.freebsd.org/doc/en_US.ISO8859-1/books/developers-handbook/ipv6.html#ipv6-scope-index > > I *did* go WTF when Gert Döring pointed that out to me... I don't recall what I was doing, but I do recall meaning to use such link-locals and find it was not possible. Another "WTF" was that on some platforms 2001:db8::/64 seem to be blocked by the kernel, and not usable at all. Thanks, -- Fernando Gont SI6 Networks e-mail: fgont@si6networks.com PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492 From nobody Fri Jan 22 13:55:40 2016 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 248151A8A4F for ; Fri, 22 Jan 2016 13:55:40 -0800 (PST) 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=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RbOELhv9czfq for ; Fri, 22 Jan 2016 13:55:39 -0800 (PST) Received: from mail-pf0-x22b.google.com (mail-pf0-x22b.google.com [IPv6:2607:f8b0:400e:c00::22b]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id ED0BA1A8A4E for ; Fri, 22 Jan 2016 13:55:38 -0800 (PST) Received: by mail-pf0-x22b.google.com with SMTP id q63so49869027pfb.1 for ; Fri, 22 Jan 2016 13:55:38 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=subject:to:references:from:organization:message-id:date:user-agent :mime-version:in-reply-to:content-type:content-transfer-encoding; bh=Md8Apze3EvTU4NIjlyvCkOKnbPR0vhyH1ttnIIIyyt8=; b=EhQS1sd9xvFwU4FtDnUORj3vjkaE/o5izlR2o0LdhaUQYe0ETMNsF35ldxBH81h7Ws +5a59NelNF/BCDK98igAuvV2XYI3y9dKnCVaGGmgHi7UN7qdInU5Sp0RGdeNkG/DHHqj 2oOvHBbcrBjvepzonrDqsRLs7nKFrNuRU1tHRmkcOKnE06WmrZ4p2SJHSoosS14kfaW+ RsmsMcfWovEJ7Wh5q0BEgGxaGLSI4rMKj6ECUMKOHHed4tPYv0kNGz3MOxtl+ikDfBPL IkoBwj3Rp+qF0pb+6WqUoqo1oVotZKrF3l1MnvPPV4eZiPhIp9V3VYvKby1PKIfuMgFM 83xw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:subject:to:references:from:organization :message-id:date:user-agent:mime-version:in-reply-to:content-type :content-transfer-encoding; bh=Md8Apze3EvTU4NIjlyvCkOKnbPR0vhyH1ttnIIIyyt8=; b=Qo59TILLkh6cIP0YoYfeLyjbxR0mdtXSLrrM+FziN6Op/PisdRzMEUUe8/y/WpkRoA cwGvS9zUUpzpqJDmjwzn5tJ5OD+BplsZSqOXSRLBQSH0pFmW0Z99iTaH0eE0D1SOnh5Q 3d6wdN8yI2Am+j6rb8+dBE4cmD29xEWfjPgpTXPy5bkCmWQnCvzj4eHoglZl87E1Pzeg Zh59RPXCoYUJLHitdMSlQDz6GdEv0rYjXqzolwySu/AcZI+NNDw1LImgzLue86y+3usP bJzjuRWSXRsiBc5DHdGdYGLQvMmXJJ7nc0fowSj5r4w79kXV/moE2hwyLhe4IPMcrzXh swJQ== X-Gm-Message-State: AG10YOS/1NTJXkBbtGnS7phWOrhxHjp+kiCrLSextlguE+KMLZ9tzNFOauXVjgPaNdl2UQ== X-Received: by 10.98.11.151 with SMTP id 23mr7720341pfl.93.1453499738544; Fri, 22 Jan 2016 13:55:38 -0800 (PST) Received: from ?IPv6:2406:e007:7e5d:1:28cc:dc4c:9703:6781? ([2406:e007:7e5d:1:28cc:dc4c:9703:6781]) by smtp.gmail.com with ESMTPSA id t70sm11904615pfi.8.2016.01.22.13.55.35 (version=TLSv1/SSLv3 cipher=OTHER); Fri, 22 Jan 2016 13:55:37 -0800 (PST) Subject: Re: To: "Manfredi, Albert E" , Bob Hinden , IPv6 List References: <47F937E4-49D4-43CD-9D0A-26DFD0867D4A@gmail.com> From: Brian E Carpenter Organization: University of Auckland Message-ID: <56A2A562.8050400@gmail.com> Date: Sat, 23 Jan 2016 10:55:46 +1300 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.5.1 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Archived-At: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 22 Jan 2016 21:55:40 -0000 On 23/01/2016 08:22, Manfredi, Albert E wrote: ... > > Did we decide to not include anything about byte transmission order, along the lines of RFC 791 Appendix B? It's there: The data transmission order for IPv6 is the same as for IPv4 as defined in Appendix B of [RFC0791]. Brian From nobody Fri Jan 22 14:04:11 2016 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D970F1A8A8C; Fri, 22 Jan 2016 14:04:09 -0800 (PST) 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=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0BgJ9Pzt3NBA; Fri, 22 Jan 2016 14:04:08 -0800 (PST) Received: from mail-pa0-x235.google.com (mail-pa0-x235.google.com [IPv6:2607:f8b0:400e:c03::235]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6A77F1A8A8D; Fri, 22 Jan 2016 14:04:08 -0800 (PST) Received: by mail-pa0-x235.google.com with SMTP id cy9so47960656pac.0; Fri, 22 Jan 2016 14:04:08 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=subject:to:references:cc:from:organization:message-id:date :user-agent:mime-version:in-reply-to:content-type :content-transfer-encoding; bh=RsxeTQLkE30PO3DDGxHhSuXNCmfwHqN0w3lfRfEgn08=; b=PZP6i8m79A2J0mJ9IP31U78Gfpog8Jc6dSaR3G3W0jATj0p+cebJ4q3XZd2Vz6EZFT HmxxeKx3zhb9qCrhrMRt/kD01YjK8rXkBw0nQ+VwFIghRG1aAjjZnd7xgWOlrCGQhY7d IbC7iz7oKkp3S5v53OOnanvsdn7pD1HvQXHTivrjCi8lB71nZ2scUryRIqvhh95jDUbw AtHZ5yrn8cruioq+/RDxTHjRqcJNX7TK/OA8ezRekftqngbVYEUkhZ98rKjHZVExyV2t TomLaBNu8sATYFGLTOCaBVnEJgyKuGEE+N8r6Ayyyp6ZcGbQTxJe7Ly93mgxt1yA7uxa BRKg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:subject:to:references:cc:from:organization :message-id:date:user-agent:mime-version:in-reply-to:content-type :content-transfer-encoding; bh=RsxeTQLkE30PO3DDGxHhSuXNCmfwHqN0w3lfRfEgn08=; b=ewzH8CyXJu3Ui53vlVUPxNCyzbAm8K+A3R9og4wDaaGuiXLMs8LQ/pwpA4NPTebkNv cvfFIj6KnUQWPEB5tq1DQSLP3NG6a9pl0EEniaIae7Fo1euqGBK4r+ZysQ1Ds0j44qwf GEdGX4WopO3GxorPgUfSZ8uQaGYEo8abtL5QezIFBte1DwNCOKIpSnnOF9X2ldNmwgVT FDF+U2h5RU7odhZl88ObN8Ep5ZZvwgHgOamgfep9mexIflcYUVE2UojOtFOjp9UJRD0Y qd3b6Vg0klcNoAOUz7Ul75WBkTOZDN0l46LFmQgYwwRvMXrF6rYFM0WZupCTfECgMPR7 +swA== X-Gm-Message-State: AG10YOTMCEWFJyn3IL+bgFE9yG8PelQvi/3lF+Z6ql/MxWp8P2m9V+C2ygmCLjTUu0l4tA== X-Received: by 10.67.15.73 with SMTP id fm9mr7848261pad.130.1453500248041; Fri, 22 Jan 2016 14:04:08 -0800 (PST) Received: from ?IPv6:2406:e007:7e5d:1:28cc:dc4c:9703:6781? ([2406:e007:7e5d:1:28cc:dc4c:9703:6781]) by smtp.gmail.com with ESMTPSA id b84sm11895431pfj.25.2016.01.22.14.04.04 (version=TLSv1/SSLv3 cipher=OTHER); Fri, 22 Jan 2016 14:04:07 -0800 (PST) Subject: 2001:db8 [was Re: draft-ietf-6man-rfc4291bis] To: Fernando Gont , Sander Steffann , Mark Smith References: <56A27712.1060003@si6networks.com> From: Brian E Carpenter Organization: University of Auckland Message-ID: <56A2A760.9050906@gmail.com> Date: Sat, 23 Jan 2016 11:04:16 +1300 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.5.1 MIME-Version: 1.0 In-Reply-To: <56A27712.1060003@si6networks.com> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Archived-At: Cc: 6man WG , yhb@ruijie.com.cn, draft-ietf-6man-rfc4291bis@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 22 Jan 2016 22:04:10 -0000 On 23/01/2016 07:38, Fernando Gont wrote: > Another "WTF" was that on some platforms 2001:db8::/64 seem to be > blocked by the kernel, and not usable at all. That seems quite reasonable, though. (Don't you mean 2001:db8::/32?) Which platforms, BTW? And was it connect or send that complained? (I have a reason for asking that takes a while to explain...) Brian From nobody Fri Jan 22 14:44:18 2016 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 476F71A8F35; Fri, 22 Jan 2016 14:44:17 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fqdAyFfm0m6P; Fri, 22 Jan 2016 14:44:15 -0800 (PST) Received: from fgont.go6lab.si (fgont.go6lab.si [IPv6:2001:67c:27e4::14]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CBA1A1A8F34; Fri, 22 Jan 2016 14:44:14 -0800 (PST) Received: from [192.168.3.107] (unknown [181.165.125.191]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by fgont.go6lab.si (Postfix) with ESMTPSA id EEE362069FC; Fri, 22 Jan 2016 23:44:09 +0100 (CET) Subject: Re: draft-ietf-6man-rfc4291bis To: Brian E Carpenter , Sander Steffann , Mark Smith References: <56A27EC5.1060204@gmail.com> From: Fernando Gont X-Enigmail-Draft-Status: N1110 Message-ID: <56A2A689.7020707@si6networks.com> Date: Fri, 22 Jan 2016 19:00:41 -0300 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.5.1 MIME-Version: 1.0 In-Reply-To: <56A27EC5.1060204@gmail.com> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Archived-At: Cc: 6man WG , yhb@ruijie.com.cn, draft-ietf-6man-rfc4291bis@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 22 Jan 2016 22:44:17 -0000 On 01/22/2016 04:11 PM, Brian E Carpenter wrote: > On 23/01/2016 02:17, Sander Steffann wrote: >> Hi, >> >>>> | 10 | >>>> | bits | 54 bits | 64 bits | >>>> +----------+-------------------------+----------------------------+ >>>> |1111111010| 0 | interface ID | >>>> +----------+-------------------------+----------------------------+ >>>> >>>> The definition is wrong.The middle 54 bits can be any value.Please fix it. >>> >>> How did you come to that conclusion? >>> >>> Some implementations might be tolerant of non-zero values in those 54 bits, but that doesn't make the definition wrong. >> >> It has always been interesting that a /10 is reserved for link-local while only a /64 is commonly used. The 54 bits in the middle could be anything, > > No, the standard has always said that they *are* zero. We attempted to clarify this > in RFC 7421 - please see the bottom of this page: > http://tools.ietf.org/html/rfc7421#page-11 > >> but they are always 0. FreeBSD even uses that assumption > > It's not an assumption; it's the standard. Without looking back at the specs right now I seem to recall finding the definition of ll addresses as fe80::/10 confusing in that respect. The current behavior implies fe80::/64 rather than fe80::/10. (This was a gotcha for me when I found that fe80::/10 doesn't actually work. For instance, when you play with ll addresses in BSD, you have to manually force the corresponding words to be zero, since the kernel will always return the scope and interface index in such words). FWIW, I'd say that, for the most part, RFC7421 implicitly talks about longer prefixes rather than shorter ones... Thanks, -- Fernando Gont SI6 Networks e-mail: fgont@si6networks.com PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492 From nobody Fri Jan 22 14:44:29 2016 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5A3961A8F3D; Fri, 22 Jan 2016 14:44:28 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id msWVu8gRvys8; Fri, 22 Jan 2016 14:44:27 -0800 (PST) Received: from fgont.go6lab.si (fgont.go6lab.si [IPv6:2001:67c:27e4::14]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E50BF1A8F3C; Fri, 22 Jan 2016 14:44:26 -0800 (PST) Received: from [192.168.3.107] (unknown [181.165.125.191]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by fgont.go6lab.si (Postfix) with ESMTPSA id 0CE7A2069FE; Fri, 22 Jan 2016 23:44:22 +0100 (CET) Subject: Re: 2001:db8 [was Re: draft-ietf-6man-rfc4291bis] To: Brian E Carpenter , Sander Steffann , Mark Smith References: <56A27712.1060003@si6networks.com> <56A2A760.9050906@gmail.com> From: Fernando Gont X-Enigmail-Draft-Status: N1110 Message-ID: <56A2A8C2.7040902@si6networks.com> Date: Fri, 22 Jan 2016 19:10:10 -0300 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.5.1 MIME-Version: 1.0 In-Reply-To: <56A2A760.9050906@gmail.com> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Archived-At: Cc: 6man WG , yhb@ruijie.com.cn, draft-ietf-6man-rfc4291bis@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 22 Jan 2016 22:44:28 -0000 Hi, Brian, On 01/22/2016 07:04 PM, Brian E Carpenter wrote: > On 23/01/2016 07:38, Fernando Gont wrote: > >> Another "WTF" was that on some platforms 2001:db8::/64 seem to be >> blocked by the kernel, and not usable at all. > > That seems quite reasonable, though. (Don't you mean 2001:db8::/32?) I meant 2001:db8::/32, sorry. FWIW, I don't think it's a reasonable out-of-the-box behavior. Sample scenario: I was meaning to use this addresses in a virtual network for a training course. Since they didn't work as expected, I ended up using ULAs. -- it'd been great to be able to use 2001:db8::/16 so that documentation could use the same addresses as in the actual vrtual network we were employing. > Which platforms, BTW? And was it connect or send that complained? > > (I have a reason for asking that takes a while to explain...) I'll double-check and come back to you, since I had written notes about this. -- iirc, it was bsd platforms that wouldn't even forward packets containing these addresses -- and there was no way to override this. Thanks, -- Fernando Gont SI6 Networks e-mail: fgont@si6networks.com PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492 From nobody Fri Jan 22 14:44:41 2016 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 643451A8F3F for ; Fri, 22 Jan 2016 14:44:39 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3KbNo77T0PlW for ; Fri, 22 Jan 2016 14:44:35 -0800 (PST) Received: from fgont.go6lab.si (fgont.go6lab.si [91.239.96.14]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A38741A8F44 for ; Fri, 22 Jan 2016 14:44:32 -0800 (PST) Received: from [192.168.3.107] (unknown [181.165.125.191]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by fgont.go6lab.si (Postfix) with ESMTPSA id 4840A2069FC; Fri, 22 Jan 2016 23:44:29 +0100 (CET) Subject: Re: To: Brian E Carpenter , "Manfredi, Albert E" , Bob Hinden , IPv6 List References: <47F937E4-49D4-43CD-9D0A-26DFD0867D4A@gmail.com> <56A2A562.8050400@gmail.com> From: Fernando Gont Message-ID: <56A2A914.3060107@si6networks.com> Date: Fri, 22 Jan 2016 19:11:32 -0300 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.5.1 MIME-Version: 1.0 In-Reply-To: <56A2A562.8050400@gmail.com> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit Archived-At: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 22 Jan 2016 22:44:39 -0000 On 01/22/2016 06:55 PM, Brian E Carpenter wrote: > On 23/01/2016 08:22, Manfredi, Albert E wrote: > ... >> >> Did we decide to not include anything about byte transmission order, along the lines of RFC 791 Appendix B? > > It's there: > > The data transmission order for IPv6 is the same as for IPv4 as > defined in Appendix B of [RFC0791]. (without looking at the relevant rfcs): Why not deine that in this very rfc? Otherwise this would be kind of a normative reference to ipv4 in an ipv6 std... Thanks, -- Fernando Gont SI6 Networks e-mail: fgont@si6networks.com PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492 From nobody Sat Jan 23 00:41:18 2016 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DAFFB1B344D for ; Sat, 23 Jan 2016 00:41:17 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.202 X-Spam-Level: X-Spam-Status: No, score=-4.202 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tlKFq8H1vpeA for ; Sat, 23 Jan 2016 00:41:16 -0800 (PST) Received: from bizet.nethelp.no (bizet.nethelp.no [195.1.209.33]) by ietfa.amsl.com (Postfix) with SMTP id 8B3911B344A for ; Sat, 23 Jan 2016 00:41:15 -0800 (PST) Received: (qmail 73870 invoked from network); 23 Jan 2016 08:41:13 -0000 Received: from bizet.nethelp.no (HELO localhost) (195.1.209.33) by bizet.nethelp.no with SMTP; 23 Jan 2016 08:41:13 -0000 Date: Sat, 23 Jan 2016 09:41:12 +0100 (CET) Message-Id: <20160123.094112.74677233.sthaug@nethelp.no> To: brian.e.carpenter@gmail.com Subject: Re: 2001:db8 From: sthaug@nethelp.no In-Reply-To: <56A2A760.9050906@gmail.com> References: <56A27712.1060003@si6networks.com> <56A2A760.9050906@gmail.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 Archived-At: Cc: ipv6@ietf.org, yhb@ruijie.com.cn, fgont@si6networks.com, draft-ietf-6man-rfc4291bis@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 23 Jan 2016 08:41:18 -0000 > > Another "WTF" was that on some platforms 2001:db8::/64 seem to be > > blocked by the kernel, and not usable at all. > > That seems quite reasonable, though. (Don't you mean 2001:db8::/32?) > > Which platforms, BTW? And was it connect or send that complained? That seems quite *un*reasonable to me. I would certainly vote with my wallet and refuse to buy such equipment. Steinar Haug, AS2116 From nobody Sat Jan 23 06:38:59 2016 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E83851B371C; Sat, 23 Jan 2016 06:38:57 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.027 X-Spam-Level: X-Spam-Status: No, score=-1.027 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FM_FORGED_GMAIL=0.622, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MfeRYSXZ4Ev0; Sat, 23 Jan 2016 06:38:56 -0800 (PST) Received: from mail-ig0-x231.google.com (mail-ig0-x231.google.com [IPv6:2607:f8b0:4001:c05::231]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6C8B01B371B; Sat, 23 Jan 2016 06:38:56 -0800 (PST) Received: by mail-ig0-x231.google.com with SMTP id t15so9521013igr.0; Sat, 23 Jan 2016 06:38:56 -0800 (PST) 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=n3hefJZOvCgLGH+xgCfpG5aE1Q4vuXRwkNAU4ySrns0=; b=zrmTuC/bynRGdP0RITeCES8TlFnZgk4KXnJEYONRoDq8Sad4D9bTRzSqZX7s49u8GS beD5gUqVvGi/9+2ud9epYPVzypEl2OxaaXV1Mu8RRnTCvDBhhYhl8TLugcZSt5O934F0 4HFZXjUNSI3T1u4MC1ChJmN2zkjIYM86TJoIqKsHF+LXNOwE+LKR+MdvYcM4uLbkxrSh GYn1mYSGUcLAN6tporS0eQ6BzQ8ZMfQO6ntuvBmlKd+tTOvFJc26nuOYp/8hsd3eOdW6 g3dprIqTW98yFvrnZFIBgKQY09L+FMKADtqi5HzKYTObQt6O0GJi9wC9qQ9Ij9V35b2F AZjA== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ieee-org.20150623.gappssmtp.com; s=20150623; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type; bh=n3hefJZOvCgLGH+xgCfpG5aE1Q4vuXRwkNAU4ySrns0=; b=hIZ88dEEWir8lHHmlVkUu64kNVjuQKWQOhW0Ig9M98w8VwnHFviQIP8k12R7SYe+Vq B3An4/WZMVg5Ox5CuxGAVkLlx99XANEcjZ7N/SvDTMkm8YJ1ZkIiSJVjY8mr76gcmkK7 PgczD14I7uHNRct2juSQDK3ZFxGbvxeCENXHT2Lby5ZEDMx0rbXZFgdiEo0SpRoD4rzw xvScADcRBv/kPcgykexzNZgLUlywcybO8Rlwg4E9tQ1zdegMOgzHQtcpOjRUDZxYNTmy rwGFHqDU1ua9poBNY9TjFy3RPcCOrFtrwc0p7gtUeWGotpF+O6tL3g2zG/K8gKn7XtWJ 0/2g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:sender:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=n3hefJZOvCgLGH+xgCfpG5aE1Q4vuXRwkNAU4ySrns0=; b=HiqXjw3TnMtcsEUh4LM92yYqPPaSB29oghBCK3e+XLi8pz08IhgHVV4+VigMeh2qN/ wPxKMpPllfSrDn4QZZvkBNgo6C7LuSIY9K2VzUNYwQZsfsvK7TG8yoop6Gb4H3WHSTTU x0OfYEW4kSitAQuBO4tkvM/tzpkE9gGnzrB+4IrNpZF9ehc9n4cp+/wONW6iadOT20ar 2mfq5rOlUxMXc5N81UZ41TIV5XmeuY53l26DXcLx4dUPAduQcvm987xyPks41nGCZTUd kpZl3BoG0j0H9lgTmsvBszNzD3OfcEXsdKfy+ZL04z39xFb+IrVgEWli5wk7xDubpkmw 6S9w== X-Gm-Message-State: AG10YORBpjLDmM6KKeWm1PJYtXs64H6H1CJK6Stad1s/6nlK6l3bS5VTSYObCCzPXi12EZ9mXGUdMI9JAzILfA== MIME-Version: 1.0 X-Received: by 10.50.131.201 with SMTP id oo9mr8685995igb.68.1453559935836; Sat, 23 Jan 2016 06:38:55 -0800 (PST) Sender: kerlyn2001@gmail.com Received: by 10.79.67.130 with HTTP; Sat, 23 Jan 2016 06:38:55 -0800 (PST) In-Reply-To: <20160123.094112.74677233.sthaug@nethelp.no> References: <56A27712.1060003@si6networks.com> <56A2A760.9050906@gmail.com> <20160123.094112.74677233.sthaug@nethelp.no> Date: Sat, 23 Jan 2016 09:38:55 -0500 X-Google-Sender-Auth: EWfNf-dJBKxp_dF-KoKSImuhSjc Message-ID: Subject: Re: 2001:db8 From: Kerry Lynn To: sthaug@nethelp.no Content-Type: multipart/alternative; boundary=047d7b2e47c8a2ada6052a014b15 Archived-At: Cc: yhb@ruijie.com.cn, 6man 6man , draft-ietf-6man-rfc4291bis@ietf.org, Fernando Gont X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 23 Jan 2016 14:38:58 -0000 --047d7b2e47c8a2ada6052a014b15 Content-Type: text/plain; charset=UTF-8 On Sat, Jan 23, 2016 at 3:41 AM, wrote: > > > Another "WTF" was that on some platforms 2001:db8::/64 seem to be > > > blocked by the kernel, and not usable at all. > > > > That seems quite reasonable, though. (Don't you mean 2001:db8::/32?) > > > > Which platforms, BTW? And was it connect or send that complained? > > That seems quite *un*reasonable to me. I would certainly vote with > my wallet and refuse to buy such equipment. > > To quote from RFC 3849: "This is *not* a local-use address prefix, and the filters may be used in both local and public contexts." (Emphasis mine.) I think it's a reasonable choice to filter bogus packets at the source. Kerry Lynn > Steinar Haug, AS2116 > > -------------------------------------------------------------------- > IETF IPv6 working group mailing list > ipv6@ietf.org > Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 > -------------------------------------------------------------------- > --047d7b2e47c8a2ada6052a014b15 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On S= at, Jan 23, 2016 at 3:41 AM, <sthaug@nethelp.no> wrote:
=
> > Another "WTF" was that on some platfor= ms 2001:db8::/64 seem to be
> > blocked by the kernel, and not usable at all.
>
> That seems quite reasonable, though. (Don't you mean 2001:db8::/32= ?)
>
> Which platforms, BTW? And was it connect or send that complained?

That seems quite *un*reasonable to me. I would certainly vote with
my wallet and refuse to buy such equipment.

To quote from RFC 3849:
"This is *not* a local-use address= prefix, and the filters may be used
=C2=A0 =C2=A0in both local and public conte= xts." =C2=A0(Emphasis mine.)

I think it's a reasonable choice to filter= bogus packets at the source.

Kerry Lynn
=C2=A0
Steinar Haug, AS2116

--------------------------------------------------------------------
IETF IPv6 working group mailing list
ipv6@ietf.org
Administrative Requests: https://www.ietf.org/mailman/list= info/ipv6
--------------------------------------------------------------------

--047d7b2e47c8a2ada6052a014b15-- From nobody Sat Jan 23 08:30:54 2016 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 089701B390D for ; Sat, 23 Jan 2016 08:30:54 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.299 X-Spam-Level: X-Spam-Status: No, score=-4.299 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=0.001, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.001] autolearn=unavailable Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ADVm30h54Q2d for ; Sat, 23 Jan 2016 08:30:53 -0800 (PST) Received: from vs-a.tc.umn.edu (vs-a.tc.umn.edu [134.84.119.220]) by ietfa.amsl.com (Postfix) with ESMTP id E9CB21B3909 for ; Sat, 23 Jan 2016 08:30:52 -0800 (PST) Received: from mail-pa0-f50.google.com (mail-pa0-f50.google.com [209.85.220.50]) by vs-a.tc.umn.edu (UMN smtpd) with ESMTP (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128/128); for ; Sat, 23 Jan 2016 10:30:49 -0600 (CST) X-Umn-Remote-Mta: [N] mail-pa0-f50.google.com [209.85.220.50] #+LO+TS+TR X-Umn-Classification: local Received: by mail-pa0-f50.google.com with SMTP id ho8so57539797pac.2 for ; Sat, 23 Jan 2016 08:30:49 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=umn.edu; s=google; h=references:in-reply-to:mime-version:content-transfer-encoding :content-type:message-id:cc:from:subject:date:to; bh=4flSHpbWMNtGfrbaj+wR1J+our8l5VmoYSfOzqZez/w=; b=mTgJr8s9PiiZew6Bt3/9IhR7cuMrPrRSSsF0sPclnZDoDoe/bxWlMoYh7ZHvRz0qq8 ZVdFCr1SoJrtPOu6DnAjleD9TPo/9J3RbTNVDWMKRSIXXa84rR5JkC+tU6u/jLMADPP/ TgXB76/Usk2RBOZ6zmrv+yORQX7JOOqOCwKjI= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:references:in-reply-to:mime-version :content-transfer-encoding:content-type:message-id:cc:from:subject :date:to; bh=4flSHpbWMNtGfrbaj+wR1J+our8l5VmoYSfOzqZez/w=; b=QrfK+TXPnM5pESXv9GyGssRz8Zz8hifCgotTBN6fcFHClTsgT9I1W7ie87So3OEbr0 vUN84RpCdE2391irIFJsFoXHrPqQ/odpPGcaCn+hdwvdFjIuPC41b6eExygW+WDvnmOX y6w8VvNpr8LLvbxVH0v7jHr74ParYaDFHaZaOs+I4BOq5rJnzpV7trsi6BjQT4oy5FBg ui6bXZ9l8uN8MUevyFic1ic2NpiU04xszHNvS461mBHJiWyO2eeMbWeM6hOIrkMaeCsc 3l01PA2G/BAxM72bOLqE3mQQ647ZvozeCg519L4Ozd/E/Rhwu2cJCzmWLfQZ1vJaFYkB 0yMQ== X-Gm-Message-State: AG10YOS9MBktvo3QZvWdR0ZgDM4TN0N1I54UG4Di2blrLT4SSZRJ1IhgquPTDIvDys227eB8ZtFgmrWAkYXb/cmib/V4pbzURNS/0zoXNxqOV7XQ5WU/Kkjb/OAOaXc+4xI= X-Received: by 10.67.7.200 with SMTP id de8mr13267794pad.28.1453566648922; Sat, 23 Jan 2016 08:30:48 -0800 (PST) X-Received: by 10.67.7.200 with SMTP id de8mr13267761pad.28.1453566648650; Sat, 23 Jan 2016 08:30:48 -0800 (PST) Received: from [10.10.2.169] ([70.102.70.91]) by smtp.gmail.com with ESMTPSA id sm8sm17381248pac.43.2016.01.23.08.30.46 (version=TLSv1/SSLv3 cipher=OTHER); Sat, 23 Jan 2016 08:30:46 -0800 (PST) References: <56A27712.1060003@si6networks.com> <56A2A760.9050906@gmail.com> <20160123.094112.74677233.sthaug@nethelp.no> In-Reply-To: Mime-Version: 1.0 (1.0) Content-Transfer-Encoding: 7bit Content-Type: multipart/alternative; boundary=Apple-Mail-7D6A624B-5F8D-416B-AB00-73C2DF4B0AF3 Message-Id: X-Mailer: iPad Mail (13D15) From: David Farmer Subject: Re: 2001:db8 Date: Sat, 23 Jan 2016 08:30:45 -0800 To: Kerry Lynn Archived-At: Cc: 6man 6man , draft-ietf-6man-rfc4291bis@ietf.org, yhb@ruijie.com.cn, Fernando Gont X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 23 Jan 2016 16:30:54 -0000 --Apple-Mail-7D6A624B-5F8D-416B-AB00-73C2DF4B0AF3 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable > On Jan 23, 2016, at 06:38, Kerry Lynn wrote: >=20 >> On Sat, Jan 23, 2016 at 3:41 AM, wrote: >> > > Another "WTF" was that on some platforms 2001:db8::/64 seem to be >> > > blocked by the kernel, and not usable at all. >> > >> > That seems quite reasonable, though. (Don't you mean 2001:db8::/32?) >> > >> > Which platforms, BTW? And was it connect or send that complained? >>=20 >> That seems quite *un*reasonable to me. I would certainly vote with >> my wallet and refuse to buy such equipment. > To quote from RFC 3849: > "This is *not* a local-use address prefix, and the filters may be used > in both local and public contexts." (Emphasis mine.) >=20 > I think it's a reasonable choice to filter bogus packets at the source. I agree that is reasonable default behavior, and clearly the intent of RFC 3= 849. However, I think it is equally reasonable to expect some way to overri= de such default behavior. As stated I read it says, ok to filter or not to f= ilter. Otherwise, I would have expected more than just a permissive to be u= sed, and a recommendation or stronger yet a requirement to filter. --=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=3D David Farmer Email: farmer@umn.edu Office of Information Technology University of Minnesota =20 2218 University Ave SE Phone: +1-612-626-0815 Minneapolis, MN 55414-3029 Cell: +1-612-812-9952 =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 --Apple-Mail-7D6A624B-5F8D-416B-AB00-73C2DF4B0AF3 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable

On Jan 23, 2016, at 06:= 38, Kerry Lynn <kerlyn@ieee.org>= ; wrote:

On Sat, Jan 23, 2016 at 3:41= AM, <sthaug@nethelp.no> wrote:
> > A= nother "WTF" was that on some platforms 2001:db8::/64 seem to be
> > blocked by the kernel, and not usable at all.
>
> That seems quite reasonable, though. (Don't you mean 2001:db8::/32?) >
> Which platforms, BTW? And was it connect or send that complained?

That seems quite *un*reasonable to me. I would certainly vote with
my wallet and refuse to buy such equipment.

To quote from RFC 3849:
"This is *not* a local-use address prefix, a= nd the filters may be used
   in both local and public contexts."  = (Emphasis mine.)

I think it's a reasonable choice to filter bogus packets at the so= urce.

I agree that= is reasonable default behavior, and clearly the intent of RFC 3849.  H= owever, I think it is equally reasonable to expect some way to override such= default behavior.  As stated I read it says, ok to filter or not to fi= lter.  Otherw= ise, I would have expected more than just a permissive to be used, and a rec= ommendation or stronger yet a requirement to filter.


-- 
=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=
= David Farmer                   &= nbsp;      Email: farmer@um= n.edu
Office of Information Technology
University of Minnesota   &nbs= p;
M= inneapolis, MN 55414-3029   Cell: +1-612-812-9952
=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

= --Apple-Mail-7D6A624B-5F8D-416B-AB00-73C2DF4B0AF3-- From nobody Sat Jan 23 08:34:48 2016 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 74BF61B3915; Sat, 23 Jan 2016 08:34:47 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.902 X-Spam-Level: X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PNphZ5zIVvFk; Sat, 23 Jan 2016 08:34:46 -0800 (PST) Received: from tuna.sandelman.ca (tuna.sandelman.ca [209.87.249.19]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EC7721A6F33; Sat, 23 Jan 2016 08:34:45 -0800 (PST) Received: from sandelman.ca (obiwan.sandelman.ca [209.87.249.21]) by tuna.sandelman.ca (Postfix) with ESMTP id 891972015D; Sat, 23 Jan 2016 11:42:58 -0500 (EST) Received: from obiwan.sandelman.ca (ip6-localhost [IPv6:::1]) by sandelman.ca (Postfix) with ESMTP id 5A2FC63751; Sat, 23 Jan 2016 11:34:44 -0500 (EST) From: Michael Richardson To: 6man WG , draft-ietf-6man-rfc4291bis@ietf.org Subject: Re: 2001:db8 [was Re: draft-ietf-6man-rfc4291bis] In-Reply-To: <56A2A760.9050906@gmail.com> References: <56A27712.1060003@si6networks.com> <56A2A760.9050906@gmail.com> X-Mailer: MH-E 8.6; nmh 1.6+dev; GNU Emacs 24.4.2 X-Face: $\n1pF)h^`}$H>Hk{L"x@)JS7<%Az}5RyS@k9X%29-lHB$Ti.V>2bi.~ehC0; <'$9xN5Ub# z!G,p`nR&p7Fz@^UXIn156S8.~^@MJ*mMsD7=QFeq%AL4m Archived-At: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 23 Jan 2016 16:34:47 -0000 --=-=-= Content-Type: text/plain Brian E Carpenter wrote: > On 23/01/2016 07:38, Fernando Gont wrote: >> Another "WTF" was that on some platforms 2001:db8::/64 seem to be >> blocked by the kernel, and not usable at all. > That seems quite reasonable, though. (Don't you mean 2001:db8::/32?) It's not reasonable to me. It should be possible to setup a lab of equipment according to the documentation that was provided, exactly as documented. If someone wants to put a warning into a GUI... that's fine. -- Michael Richardson , Sandelman Software Works -= IPv6 IoT consulting =- --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.12 (GNU/Linux) iQEVAwUBVqOroYCLcPvd0N1lAQKoLAf+MD6l3BVT1wpbFvApg1YMx9Lj0QYEFoIj jyK4vJxSC2X3d6y2sJv9Fn6qjoAQY58XKFZxMFLkyUBwmbXzx6YiMqL1bhW8gKKI AEshan4+cZ/ZGvRSb9G2CpgqNllaB0IC9fNE+zcDzP1bq5H9UnIqRHyHWIq2bV9b 2o3suX+h5iXki0s7Jymii25bfuOAVqd31BxpV2pvwkxuAhtQKejv22LJY3x1IvhB +KW5Z5UTZ0vn8/hvNcHfO4fnpJbZmejhoOoXcw0/Rmm/c0H0M+9PJ3vKEwGVkbXJ QuhzK4BA3j+2QVxOCkmLh2Bzczvt0mAdsHpIwsDIVLViLaS4yFOX6g== =SpEB -----END PGP SIGNATURE----- --=-=-=-- From nobody Sat Jan 23 15:02:40 2016 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4294A1B2AB0; Sat, 23 Jan 2016 15:02:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.498 X-Spam-Level: X-Spam-Status: No, score=-1.498 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, FROM_LOCAL_NOVOWEL=0.5, HK_RANDOM_ENVFROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qdQx6PRRkOv0; Sat, 23 Jan 2016 15:02:36 -0800 (PST) Received: from mail-vk0-x235.google.com (mail-vk0-x235.google.com [IPv6:2607:f8b0:400c:c05::235]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 61FC01B2AAA; Sat, 23 Jan 2016 15:02:36 -0800 (PST) Received: by mail-vk0-x235.google.com with SMTP id n1so57968043vkb.3; Sat, 23 Jan 2016 15:02:36 -0800 (PST) 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=yGm3LFBQTvMRKQRsN2LDX8sbUIp8qfFLKjXxlcL4a2A=; b=PBC6BLpy9rKnsokSNBFnPdGPYo9imTHoh4zTF0bQRaTRt1kx/Urlv8OU0AIA8QQyKi pDiLzBM5OkK4bVaV0nWbaG91SAzfubhsm7xaNvKMXQNVMXt/5NAeQP0ebh5Tp+hg+0i0 3hjHo6dEbgtcBM/JMNAr71NRsAIahlOLsu0UZXSBFFXx7iSXIQVE9gjX5yKRJw/hXM0F d4MoiClJxYF9UMtXiGvcm9kHhjvlh2d4pjQiznBHOHra9mvVYnwEs+aX8g3r7XNCby8/ 7CS/Kp45ZbrM76RVXIxejXW0yhUQ+AQtszn5YNrLf09a71CQcetWyY+k/Vag75WCMePR ZU3A== 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:date :message-id:subject:from:to:cc:content-type; bh=yGm3LFBQTvMRKQRsN2LDX8sbUIp8qfFLKjXxlcL4a2A=; b=RPc6A+ujDhOhvgQOXmrC2DgI95Ycfxwp1cgf5QORC0W8d4ozlYI0P3MWzZa+d60xyx ub7qTqNYYWmf7O353TcvpvEs6cZUwbHkwNYDbGw8PIhI2x/GGUgWo1TNVSjwvPGDoAEA 6874fJ6APGKub+j1+9/hRLoQcIPzKIzLOY7mZec1SG7L1uzw3JF/tb4u7fbFLSuadaX/ ynIN8edfDnRSPWexEtrG88nE7YbkDWEDiN0rcAHuX26OUZcpsxDCyir2SbRxjWlwTE0E uNAgWyJq+q/si7T5Zb9WdJXXXV1YaMQvL6elwy1cfbWZss8JZ1bMysRrjnBX6ig5Ktl1 azVQ== X-Gm-Message-State: AG10YOSMzrZC+xd+zUlshpEkDlvddcr2bAvhUXaTy0XJ4nvXb/rIvni40i62WRFKpXCXwjijbnyCNnbLEI7FLg== MIME-Version: 1.0 X-Received: by 10.31.107.138 with SMTP id k10mr6085360vki.27.1453590155197; Sat, 23 Jan 2016 15:02:35 -0800 (PST) Received: by 10.103.99.1 with HTTP; Sat, 23 Jan 2016 15:02:35 -0800 (PST) Received: by 10.103.99.1 with HTTP; Sat, 23 Jan 2016 15:02:35 -0800 (PST) In-Reply-To: <28158.1453566884@obiwan.sandelman.ca> References: <56A27712.1060003@si6networks.com> <56A2A760.9050906@gmail.com> <28158.1453566884@obiwan.sandelman.ca> Date: Sun, 24 Jan 2016 10:02:35 +1100 Message-ID: Subject: Re: 2001:db8 [was Re: draft-ietf-6man-rfc4291bis] From: Mark Smith To: Michael Richardson Content-Type: multipart/alternative; boundary=001a11478cb8d984eb052a085498 Archived-At: Cc: 6man WG , draft-ietf-6man-rfc4291bis@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 23 Jan 2016 23:02:38 -0000 --001a11478cb8d984eb052a085498 Content-Type: text/plain; charset=UTF-8 On 24 Jan 2016 3:04 AM, "Michael Richardson" wrote: > > > Brian E Carpenter wrote: > > On 23/01/2016 07:38, Fernando Gont wrote: > > >> Another "WTF" was that on some platforms 2001:db8::/64 seem to be > >> blocked by the kernel, and not usable at all. > > > That seems quite reasonable, though. (Don't you mean 2001:db8::/32?) > > It's not reasonable to me. It should be possible to setup a lab of equipment > according to the documentation that was provided, exactly as documented. > While I sympathise with the viewpoint, that is using that documentation prefix for more documentation. I think ULAs for training labs are better, and would show that documentation prefixes should not be used on live networks of any type. > If someone wants to put a warning into a GUI... that's fine. > > -- > Michael Richardson , Sandelman Software Works > -= IPv6 IoT consulting =- > > > > > -------------------------------------------------------------------- > IETF IPv6 working group mailing list > ipv6@ietf.org > Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 > -------------------------------------------------------------------- > --001a11478cb8d984eb052a085498 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On 24 Jan 2016 3:04 AM, "Michael Richardson" <mcr+ietf@sandelman.ca> wrote:
>
>
> Brian E Carpenter <b= rian.e.carpenter@gmail.com> wrote:
> =C2=A0 =C2=A0 > On 23/01/2016 07:38, Fernando Gont wrote:
>
> =C2=A0 =C2=A0 >> Another "WTF" was that on some platfo= rms 2001:db8::/64 seem to be
> =C2=A0 =C2=A0 >> blocked by the kernel, and not usable at all. >
> =C2=A0 =C2=A0 > That seems quite reasonable, though. (Don't you= mean 2001:db8::/32?)
>
> It's not reasonable to me.=C2=A0 It should be possible to setup a = lab of equipment
> according to the documentation that was provided, exactly as documente= d.
>

While I sympathise with the viewpoint, that is using that do= cumentation prefix for more documentation.

I think ULAs for training labs are better, and would show th= at documentation prefixes should not be used on live networks of any type.<= /p>

> If someone wants to put a warning into a GUI... that= 9;s fine.
>
> --
> Michael Richardson <mcr+= IETF@sandelman.ca>, Sandelman Software Works
> =C2=A0-=3D IPv6 IoT consulting =3D-
>
>
>
>
> -------------------------------------------------------------------- > IETF IPv6 working group mailing list
> ipv6@ietf.org
> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
> -------------------------------------------------------------------- >

--001a11478cb8d984eb052a085498-- From nobody Sat Jan 23 15:21:21 2016 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 16D2F1B2AF3; Sat, 23 Jan 2016 15:21:20 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.003 X-Spam-Level: X-Spam-Status: No, score=-0.003 tagged_above=-999 required=5 tests=[BAYES_40=-0.001, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pM0rUvEmCA43; Sat, 23 Jan 2016 15:21:18 -0800 (PST) Received: from mail1.oneunified.net (mail1.oneunified.net [63.85.42.215]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A500B1B2AF2; Sat, 23 Jan 2016 15:21:18 -0800 (PST) X-OneUnified-MailScanner-Watermark: 1454196076.64709@GsC10KbSHLWlZqpVibWExA X-OneUnified-MailScanner-From: ray@oneunified.net X-OneUnified-MailScanner: Found to be clean X-OneUnified-MailScanner-ID: u0NNLFjT013292 X-OneUnified-MailScanner-Information: Please contact the ISP for more information Received: from Ray (mail1.oneunified.net [63.85.42.215]) by mail1.oneunified.net (8.14.4/8.14.4/Debian-4) with ESMTP id u0NNLFjT013292; Sat, 23 Jan 2016 23:21:15 GMT From: "Raymond Burkholder" To: "'6man WG'" , References: <56A27712.1060003@si6networks.com> <56A2A760.9050906@gmail.com> <28158.1453566884@obiwan.sandelman.ca> In-Reply-To: Subject: RE: 2001:db8 [was Re: draft-ietf-6man-rfc4291bis] Date: Sat, 23 Jan 2016 19:21:12 -0400 Message-ID: <28bf01d15634$c0491c40$40db54c0$@oneunified.net> MIME-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Outlook 16.0 Content-Language: en-us Thread-Index: AQJXASurk8R8qgvdvgcdU859B1BnhwGfJZAHAzRJ2bAByIUhDgJggptqAeAaxZICYo3Mnp2UbYmA Archived-At: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 23 Jan 2016 23:21:20 -0000 >> >> It's not reasonable to me. It should be possible to setup a lab of equi= pment >> according to the documentation that was provided, exactly as documented. >> >While I sympathise with the viewpoint, that is using that documentation pr= efix for more documentation. >I think ULAs for training labs are better, and would show that documentati= on prefixes should not be used on live networks of any type. I believe it goes both ways. When writing documentation, you want to test = what you documented. So, you build something with the documentation addres= ses, prove that it works, then put into documentation verbatim. --=20 This message has been scanned for viruses and dangerous content by MailScanner, and is believed to be clean. From nobody Sat Jan 23 15:58:34 2016 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3FA921B2C15; Sat, 23 Jan 2016 15:58:33 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 3.602 X-Spam-Level: *** X-Spam-Status: No, score=3.602 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DATE_IN_PAST_06_12=1.543, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, MIME_HTML_ONLY=0.723, RCVD_IN_SBL_CSS=3.335, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id stphw3Zf8v9Q; Sat, 23 Jan 2016 15:58:32 -0800 (PST) Received: from mail-yk0-x230.google.com (mail-yk0-x230.google.com [IPv6:2607:f8b0:4002:c07::230]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 166B51B2C14; Sat, 23 Jan 2016 15:58:32 -0800 (PST) Received: by mail-yk0-x230.google.com with SMTP id k129so126917605yke.0; Sat, 23 Jan 2016 15:58:32 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:subject:from:to:cc:mime-version:content-type :content-transfer-encoding; bh=t3HjtHIwmuXk7nxOLppRXrvSRKzEYK7V9sY48wENKRI=; b=wmTs3gTNIH/DFo8FFTA3/w6GK8B/EgjejqnTT1THQ5TnDh7Nn2wsGNveEYgTuJ3AWB qDlqxuTZqZ5PJ4beQ7quug+gVYowO8+DaEoRtOBnuc41N1bWKrFBRWsMpcNBiY8emIGB djU+79WNKNtsqlGvRRGnalf8s/0Q0G2QXv5KpZm8k8WxlOpVs5BFye1y9BdYj+Hwg1Ko 5WkZWWektEg4wwVYydLLIbprlEwlnjhyjfPCzQouPajCmC8XTjNYpmR03Jqh5NeT9Fe/ oJCG7PKOzpdGzeG2SzZlw1+LpnMOAg0e3LpwBGa4wkPHwJ1a8GcJzkAH9uZHI9UraIUF Z/RA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:message-id:date:subject:from:to:cc:mime-version :content-type:content-transfer-encoding; bh=t3HjtHIwmuXk7nxOLppRXrvSRKzEYK7V9sY48wENKRI=; b=GqwMmxQodmepJszOwzFz1qSLnDwREhap+UAs7L4MYvmkbYE4c9ynMWErVLkQNJ6Kcc uzWJZNUt1GZRbdkwcWsaaWn+wPsUUcQgnRBun5zQUhRon1oJrDNwmUzmTwnQRa3AbU3Y USl0hNJ8J810l6cKQqD0nL7WNjtR4R0iMXYNjHJxPiqlUGeHWedcWx10lg8yk4aAD6IJ u3HjgBssR0j08oK0qNXDglfbAjFscrizrCBMpoecCQvGlRnLyuqStxoQbZuJxb+WduSW nyfSpGR3pZ7SXeZOTZPntrln6aWv0Q8vltOaRCzcwI2ql0Mven+Lhglg8qqcWtPl5C5a Nj/Q== X-Gm-Message-State: AG10YOTTMmuWcl2jEzRyLPW9QyHw78v993Fd3cXUSa9tfadwRIk5mZw0qeJQsGJf+jrkEg== X-Received: by 10.129.77.68 with SMTP id a65mr5711044ywb.180.1453593511392; Sat, 23 Jan 2016 15:58:31 -0800 (PST) Received: from [10.220.117.174] ([186.167.248.1]) by smtp.gmail.com with ESMTPSA id m188sm9082281ywe.46.2016.01.23.15.58.28 (version=TLSv1/SSLv3 cipher=OTHER); Sat, 23 Jan 2016 15:58:30 -0800 (PST) Message-ID: <56a413a6.c5e30d0a.b212.ffff9088@mx.google.com> Date: Sat, 23 Jan 2016 13:21:05 -0430 Subject: Re: 2001:db8 From: Alejandro Acosta To: Kerry Lynn , sthaug@nethelp.no MIME-Version: 1.0 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: base64 Archived-At: Cc: 6man 6man , yhb@ruijie.com.cn, draft-ietf-6man-rfc4291bis@ietf.org, Fernando Gont X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 23 Jan 2016 23:58:33 -0000 RG9lcyBmaWx0ZXIgbWVhbiB0byBibG9jaz8uIDxodG1sPjxoZWFkPjxtZXRhIGh0dHAtZXF1aXY9 IkNvbnRlbnQtVHlwZSIgY29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PVVURi04Ij48L2hlYWQ+ PGJvZHk+PGRpdiBjbGFzcz0icXVvdGUiIHN0eWxlPSJsaW5lLWhlaWdodDogMS41Ij48YnI+PGJy Pi0tLS0tLS0tIE9yaWdpbmFsIE1lc3NhZ2UgLS0tLS0tLS08YnI+U3ViamVjdDogUmU6IDIwMDE6 ZGI4PGJyPkZyb206IEtlcnJ5IEx5bm4gPGtlcmx5bkBpZWVlLm9yZz48YnI+VG86IHN0aGF1Z0Bu ZXRoZWxwLm5vPGJyPkNDOiB5aGJAcnVpamllLmNvbS5jbiw2bWFuIDZtYW4gPGlwdjZAaWV0Zi5v cmc+LGRyYWZ0LWlldGYtNm1hbi1yZmM0MjkxYmlzQGlldGYub3JnLEZlcm5hbmRvIEdvbnQgPGZn b250QHNpNm5ldHdvcmtzLmNvbT48YnI+PGJyPjxiciB0eXBlPSJhdHRyaWJ1dGlvbiI+PGJsb2Nr cXVvdGUgY2xhc3M9InF1b3RlIiBzdHlsZT0ibWFyZ2luOjAgMCAwIC44ZXg7Ym9yZGVyLWxlZnQ6 MXB4ICNjY2Mgc29saWQ7cGFkZGluZy1sZWZ0OjFleCI+PGRpdiBkaXI9Imx0ciI+PGRpdiBjbGFz cz0iZ21haWxfZXh0cmEiPjxkaXYgY2xhc3M9ImdtYWlsX3F1b3RlIj5PbiBTYXQsIEphbiAyMywg MjAxNiBhdCAzOjQxIEFNLCAgPHNwYW4gZGlyPSJsdHIiPiZsdDs8YSBocmVmPSJtYWlsdG86c3Ro YXVnQG5ldGhlbHAubm8iIHRhcmdldD0iX2JsYW5rIj5zdGhhdWdAbmV0aGVscC5ubzwvYT4mZ3Q7 PC9zcGFuPiB3cm90ZTo8YnI+PGJsb2NrcXVvdGUgY2xhc3M9ImdtYWlsX3F1b3RlIiBzdHlsZT0i bWFyZ2luOjBweCAwcHggMHB4IDAuOGV4O2JvcmRlci1sZWZ0LXdpZHRoOjFweDtib3JkZXItbGVm dC1jb2xvcjpyZ2IoMjA0LDIwNCwyMDQpO2JvcmRlci1sZWZ0LXN0eWxlOnNvbGlkO3BhZGRpbmct bGVmdDoxZXgiPiZndDsgJmd0OyBBbm90aGVyICJXVEYiIHdhcyB0aGF0IG9uIHNvbWUgcGxhdGZv cm1zIDIwMDE6ZGI4OjovNjQgc2VlbSB0byBiZTxicj4KJmd0OyAmZ3Q7IGJsb2NrZWQgYnkgdGhl IGtlcm5lbCwgYW5kIG5vdCB1c2FibGUgYXQgYWxsLjxicj4KJmd0Ozxicj4KJmd0OyBUaGF0IHNl ZW1zIHF1aXRlIHJlYXNvbmFibGUsIHRob3VnaC4gKERvbid0IHlvdSBtZWFuIDIwMDE6ZGI4Ojov MzI/KTxicj4KJmd0Ozxicj4KJmd0OyBXaGljaCBwbGF0Zm9ybXMsIEJUVz8gQW5kIHdhcyBpdCBj b25uZWN0IG9yIHNlbmQgdGhhdCBjb21wbGFpbmVkPzxicj4KPGJyPgpUaGF0IHNlZW1zIHF1aXRl ICp1bipyZWFzb25hYmxlIHRvIG1lLiBJIHdvdWxkIGNlcnRhaW5seSB2b3RlIHdpdGg8YnI+Cm15 IHdhbGxldCBhbmQgcmVmdXNlIHRvIGJ1eSBzdWNoIGVxdWlwbWVudC48YnI+Cjxicj48L2Jsb2Nr cXVvdGU+PGRpdj5UbyBxdW90ZSBmcm9tIFJGQyAzODQ5OjwvZGl2PjxkaXY+IjxzcGFuIHN0eWxl PSJjb2xvcjpyZ2IoMCwwLDApO2ZvbnQtc2l6ZToxMy4zMzMzcHgiPlRoaXMgaXMgKm5vdCogYSBs b2NhbC11c2UgYWRkcmVzcyBwcmVmaXgsIGFuZCB0aGUgZmlsdGVycyBtYXkgYmUgdXNlZDwvc3Bh bj48L2Rpdj48ZGl2PjxzcGFuIHN0eWxlPSJjb2xvcjpyZ2IoMCwwLDApO2ZvbnQtc2l6ZToxMy4z MzMzcHgiPiZuYnNwOyAmbmJzcDtpbiBib3RoIGxvY2FsIGFuZCBwdWJsaWMgY29udGV4dHMuIiAm bmJzcDsoRW1waGFzaXMgbWluZS4pPC9zcGFuPjwvZGl2PjxkaXY+PHNwYW4gc3R5bGU9ImNvbG9y OnJnYigwLDAsMCk7Zm9udC1zaXplOjEzLjMzMzNweCI+PGJyPjwvc3Bhbj48L2Rpdj48ZGl2Pjxz cGFuIHN0eWxlPSJjb2xvcjpyZ2IoMCwwLDApO2ZvbnQtc2l6ZToxMy4zMzMzcHgiPkkgdGhpbmsg aXQncyBhIHJlYXNvbmFibGUgY2hvaWNlIHRvIGZpbHRlciBib2d1cyBwYWNrZXRzIGF0IHRoZSBz b3VyY2UuPC9zcGFuPjwvZGl2PjxkaXY+PHNwYW4gc3R5bGU9ImNvbG9yOnJnYigwLDAsMCk7Zm9u dC1zaXplOjEzLjMzMzNweCI+PGJyPjwvc3Bhbj48L2Rpdj48ZGl2PjxzcGFuIHN0eWxlPSJjb2xv cjpyZ2IoMCwwLDApO2ZvbnQtc2l6ZToxMy4zMzMzcHgiPktlcnJ5IEx5bm48L3NwYW4+PC9kaXY+ PGRpdj4mbmJzcDs8L2Rpdj48YmxvY2txdW90ZSBjbGFzcz0iZ21haWxfcXVvdGUiIHN0eWxlPSJt YXJnaW46MHB4IDBweCAwcHggMC44ZXg7Ym9yZGVyLWxlZnQtd2lkdGg6MXB4O2JvcmRlci1sZWZ0 LWNvbG9yOnJnYigyMDQsMjA0LDIwNCk7Ym9yZGVyLWxlZnQtc3R5bGU6c29saWQ7cGFkZGluZy1s ZWZ0OjFleCI+ClN0ZWluYXIgSGF1ZywgQVMyMTE2PGJyPgo8YnI+Ci0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tPGJyPgpJ RVRGIElQdjYgd29ya2luZyBncm91cCBtYWlsaW5nIGxpc3Q8YnI+CjxhIGhyZWY9Im1haWx0bzpp cHY2QGlldGYub3JnIj5pcHY2QGlldGYub3JnPC9hPjxicj4KQWRtaW5pc3RyYXRpdmUgUmVxdWVz dHM6IDxhIGhyZWY9Imh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vaXB2NiIg cmVsPSJub3JlZmVycmVyIiB0YXJnZXQ9Il9ibGFuayI+aHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFp bG1hbi9saXN0aW5mby9pcHY2PC9hPjxicj4KLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS08YnI+CjwvYmxvY2txdW90ZT48 L2Rpdj48YnI+PC9kaXY+PC9kaXY+CjwvYmxvY2txdW90ZT48L2Znb250QHNpNm5ldHdvcmtzLmNv bT48L2lwdjZAaWV0Zi5vcmc+PC9rZXJseW5AaWVlZS5vcmc+PC9kaXY+PC9ib2R5PjwvaHRtbD4= From nobody Sat Jan 23 17:40:31 2016 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AD4881B3A92 for ; Sat, 23 Jan 2016 17:40:29 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.634 X-Spam-Level: * X-Spam-Status: No, score=1.634 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, J_CHICKENPOX_42=0.6, MANGLED_OFF=2.3, NORMAL_HTTP_TO_IP=0.001, T_FILL_THIS_FORM_SHORT=0.01] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jT9-Y9ydIgxQ for ; Sat, 23 Jan 2016 17:40:27 -0800 (PST) Received: from mail-yk0-x229.google.com (mail-yk0-x229.google.com [IPv6:2607:f8b0:4002:c07::229]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5DC711B3A90 for ; Sat, 23 Jan 2016 17:40:27 -0800 (PST) Received: by mail-yk0-x229.google.com with SMTP id a85so127276651ykb.1 for ; Sat, 23 Jan 2016 17:40:27 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=kumari-net.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :content-type; bh=MkswBjjyfvRbRbZDQnuqUo8bC+YryjxBAI+uiDy1yhI=; b=ENxeT19VNvlPUdqEwO5ET/Hi23yGPQ2zykPfQgoBsM8FtHqzKZn9YjXOwaFTXFSEzx OSr8xsOsVB4OdcBkanM574FsAuyBpYQLyYSmEcb1COJU7IKSiPWJV6m6yZ80NQfphCLS +tIs2pRHaXtgAy/YPbOf6J1Gaj/fMovwYIXnxh2/vF+8NdLp4zphMZ3iLDG/9ubyU8U+ /N7FY7lkK4MbbnHT1PJLp8Ywofj2T5LkOkewyM96kwZN8ueCTf2uif2iSsmu/SaX+fJp /IcOp/ihB0YCPGFX+hhnNxXbjoIP4jTpJrZRGxasp5NjMpOtlUO/omuP1gV0NlFPAfrj aj1Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:content-type; bh=MkswBjjyfvRbRbZDQnuqUo8bC+YryjxBAI+uiDy1yhI=; b=jPEeiOP1YHiIGUkBjI6Ks94ta6AlccvuzsXgmzW7ABA6Th/l++88MZREfBuYH5dUAD HewVyJIGXdPv1Qd6XBDJ8ur8jMMNlNyYTtQYE0rQ4LVxy9YYEwNE4gaMRYnXSYCjgwVY dGShJ1qtnyTPwuhjG72rRLX2SOc0ixO/IWZxwh0SnDtUPBXirEQfN9Wcu1OsWluUK8VI Sp8kXi1T6M2EAVpPwwDkg8YfJjY6P7t+cXXdF5meO27Etw7MZrwzKfi1FsV3xnMJWb5J r5pS0wydGQCu4GgF/ynLckDl4fJyM0gShQ5mq3tY+l34zNJb41qhMNc9NdowyUr8fE0z Z76g== X-Gm-Message-State: AG10YOQog1PA0NJV6dh/M6au2BALm4YX3JF3C6ajUH8zcXrjX8IyWvDbxiuvxqTx82lcuE/2hGHyq4Q6tXBoMMTe X-Received: by 10.129.89.139 with SMTP id n133mr4536404ywb.333.1453599626608; Sat, 23 Jan 2016 17:40:26 -0800 (PST) MIME-Version: 1.0 References: <56A27712.1060003@si6networks.com> <56A2A760.9050906@gmail.com> <28158.1453566884@obiwan.sandelman.ca> In-Reply-To: <28158.1453566884@obiwan.sandelman.ca> From: Warren Kumari Date: Sun, 24 Jan 2016 01:40:16 +0000 Message-ID: Subject: Re: 2001:db8 [was Re: draft-ietf-6man-rfc4291bis] To: Michael Richardson , 6man WG , draft-ietf-6man-rfc4291bis@ietf.org Content-Type: multipart/alternative; boundary=001a11491bf663f4c5052a0a89c4 Archived-At: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 24 Jan 2016 01:40:29 -0000 --001a11491bf663f4c5052a0a89c4 Content-Type: text/plain; charset=UTF-8 On Sat, Jan 23, 2016 at 11:34 AM Michael Richardson wrote: > > Brian E Carpenter wrote: > > On 23/01/2016 07:38, Fernando Gont wrote: > > >> Another "WTF" was that on some platforms 2001:db8::/64 seem to be > >> blocked by the kernel, and not usable at all. > > > That seems quite reasonable, though. (Don't you mean 2001:db8::/32?) > > It's not reasonable to me. It should be possible to setup a lab of > equipment > according to the documentation that was provided, exactly as documented. > > If someone wants to put a warning into a GUI... that's fine. > Counterpoint: If you don't automatically filter, this stuff leaks into tables, etc. The Internet is no longer a place where you can assume that everyone playing has clue.... -------------------------- route-views>show bgp ipv6 unicast 2001:db8::/32 longer-prefixes BGP table version is 553396, local router ID is 128.223.51.103 Status codes: s suppressed, d damped, h history, * valid, > best, i - internal, r RIB-failure, S Stale, m multipath, b backup-path, f RT-Filter, x best-external, a additional-path, c RIB-compressed, Origin codes: i - IGP, e - EGP, ? - incomplete RPKI validation codes: V valid, I invalid, N Not found Network Next Hop Metric LocPrf Weight Path *> 2001:DB8:0:FF::ABCF/128 2001:B08:2:280::4:100 0 3277 3267 41313 ? ------------------- Wombat:~ wkumari$ whois -h whois.cymru.com AS41313 AS Name NOVATEL-AS _Novatel_ Eood,BG ------------------- route-views>traceroute ipv6 2001:DB8:0:FF::ABCF Type escape sequence to abort. Tracing the route to 2001:DB8:0:FF::ABCF 1 vl-51-gw.uoregon.edu (2001:468:D01:33::1) [AS 3582] 1 msec 0 msec 0 msec 2 2001:468:D01:2::9 [AS 3582] 0 msec 1 msec * 3 * * !H route-views> --------------- Looking at V4: wkumari@vimes:~$ whois 192.0.2.0 | grep -v '#' | head NetRange: 192.0.2.0 - 192.0.2.255 CIDR: 192.0.2.0/24 NetName: TEST-NET-1 NetHandle: NET-192-0-2-0-1 Parent: NET192 (NET-192-0-0-0-0) NetType: IANA Special Use route-views>sho ip bgp 192.0.2.0/24 BGP routing table entry for 192.0.2.0/24, version 810163 Paths: (1 available, best #1, table default) Not advertised to any peer Refresh Epoch 1 20771 47872 12615 8866 8717 5421 80.241.176.31 from 80.241.176.31 (80.241.176.30) Origin IGP, localpref 100, valid, external, best rx pathid: 0, tx pathid: 0x0 wkumari@vimes:~$ whois as5421 | tail -20 role: Sofia University St. Kliment Ohridski NCC address: 5, James Bourchier Blvd. address: 1164 Sofia address: Bulgaria phone: +35928161579 org: ORG-UoS32-RIPE admin-c: HUBY-RIPE tech-c: HUBY-RIPE tech-c: MP24687-RIPE nic-hdl: NCC123-RIPE abuse-mailbox: 123@ucc.uni-sofia.bg mnt-by: AS5421-MNT created: 2013-11-12T14:18:16Z last-modified: 2013-11-12T14:18:16Z source: RIPE # Filtered % This query was served by the RIPE Database Query Service version 1.84.1 (DB-1) Wombat:~ wkumari$ traceroute 192.0.2.1 traceroute to 192.0.2.1 (192.0.2.1), 64 hops max, 52 byte packets 1 10.10.10.254 (10.10.10.254) 10.884 ms 2.628 ms 0.902 ms 2 172.20.0.1 (172.20.0.1) 3.901 ms 12.389 ms 1.824 ms 3 12.197.88.1 (12.197.88.1) 2.102 ms 2.084 ms 2.246 ms 4 * * * 5 * * * 192.0.2.0/24 is one of the IPv4 documentation prefixes. It is being leaked into the table by AS5421 (Sofia University St. Kliment Ohridski). If you don't automatically filter bogons these data, they *will* leak into the global tables. Traceroute leaves my access-point, the hotel (Hyatt) NAT and then packets get dropped once they enter ATT. Belt *and* suspenders *and* duct tape *and* baling wire... W > > -- > Michael Richardson , Sandelman Software Works > -= IPv6 IoT consulting =- > > > > -------------------------------------------------------------------- > IETF IPv6 working group mailing list > ipv6@ietf.org > Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 > -------------------------------------------------------------------- > --001a11491bf663f4c5052a0a89c4 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On Sat, Jan 23, 2016 at 11:34 AM Michael Richardson &= lt;mcr+ietf@sandelman.ca>= wrote:
=
Brian E Carpenter <brian.e.carpenter@gmail.com> wrote:
=C2=A0 =C2=A0 > On 23/01/2016 07:38, Fernando Gont wrote:

=C2=A0 =C2=A0 >> Another "WTF" was that on some platforms 2= 001:db8::/64 seem to be
=C2=A0 =C2=A0 >> blocked by the kernel, and not usable at all.

=C2=A0 =C2=A0 > That seems quite reasonable, though. (Don't you mean= 2001:db8::/32?)

It's not reasonable to me.=C2=A0 It should be possible to setup a lab o= f equipment
according to the documentation that was provided, exactly as documented.
If someone wants to put a warning into a GUI... that's fine.

Counterpoint:

If you don= 't automatically filter, this stuff leaks into tables, etc.
T= he Internet is no longer a place where you can assume that everyone playing= has clue....

--------------------------
route-views>show bgp ipv6 unicast 2001:db8::/32 longer-prefixes
BGP table version is 553396, local router ID is 128.223.51.103
Status codes: s suppressed, d damped, h history, * valid, > best, = i - internal,
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 r = RIB-failure, S Stale, m multipath, b backup-path, f RT-Filter,
= =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 x best-external, a additio= nal-path, c RIB-compressed,
Origin codes: i - IGP, e - EGP, ? - i= ncomplete
RPKI validation codes: V valid, I invalid, N Not found<= /div>

=C2=A0 =C2=A0 =C2=A0Network =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0Next Hop =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Metric LocPr= f Weight Path
=C2=A0*> =C2=A02001:DB8:0:FF::ABCF/128
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A02001:B08:2:280::4:100
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 0 3277 3267 41313 ?
= -------------------
Wombat:~ wkumari$ whois -h whois.cymru.com AS41313
AS Name
NOVATEL-AS _Novatel_ Eood,BG
-------------------
route-views>traceroute ipv6 2001:DB8:0:FF::ABCF
Ty= pe escape sequence to abort.
Tracing the route to 2001:DB8:0:FF::= ABCF

=C2=A0 1 vl-51-gw.uoregon.edu (2001:468:D01:33::1) [AS 3582] 1 msec 0 msec 0= msec
=C2=A0 2 2001:468:D01:2::9 [AS 3582] 0 msec 1 msec *
<= div>=C2=A0 3 =C2=A0* =C2=A0* =C2=A0!H
route-views>
=
---------------

Looking at V4:=C2=A0
wkumari@vimes:~$ whois 192.0.2.0 | grep -v '#' | head
<= div>NetRange: =C2=A0 =C2=A0 =C2=A0 192.0.2.0 - 192.0.2.255
CIDR: = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 192.0.2.= 0/24
NetName: =C2=A0 =C2=A0 =C2=A0 =C2=A0TEST-NET-1
NetHandle: =C2=A0 =C2=A0 =C2=A0NET-192-0-2-0-1
Parent: =C2=A0 = =C2=A0 =C2=A0 =C2=A0 NET192 (NET-192-0-0-0-0)
NetType: =C2=A0 =C2= =A0 =C2=A0 =C2=A0IANA Special Use

route= -views>sho ip bgp 192.0.2.0/24
=
BGP routing table entry for 192.0.2.0/= 24, version 810163
Paths: (1 available, best #1, table defaul= t)
=C2=A0 Not advertised to any peer
=C2=A0 Refresh Epo= ch 1
=C2=A0 20771 47872 12615 8866 8717 5421
=C2=A0 =C2= =A0 80.241.176.31 from 80.241.176.31 (80.241.176.30)
=C2=A0 =C2= =A0 =C2=A0 Origin IGP, localpref 100, valid, external, best
=C2= =A0 =C2=A0 =C2=A0 rx pathid: 0, tx pathid: 0x0


wkumari@vimes:~$ whois as5421 | tail -20
<= br>
role: =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Sofia University St.= Kliment Ohridski NCC
address: =C2=A0 =C2=A0 =C2=A0 =C2=A05, Jame= s Bourchier Blvd.
address: =C2=A0 =C2=A0 =C2=A0 =C2=A01164 Sofia<= /div>
address: =C2=A0 =C2=A0 =C2=A0 =C2=A0Bulgaria
phone: =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0+35928161579
org: =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0ORG-UoS32-RIPE
admin-c: =C2=A0 =C2=A0 = =C2=A0 =C2=A0HUBY-RIPE
tech-c: =C2=A0 =C2=A0 =C2=A0 =C2=A0 HUBY-R= IPE
tech-c: =C2=A0 =C2=A0 =C2=A0 =C2=A0 MP24687-RIPE
ni= c-hdl: =C2=A0 =C2=A0 =C2=A0 =C2=A0NCC123-RIPE
abuse-mailbox: =C2= =A0123@ucc.uni-sofia.bg
mnt-by: =C2=A0 =C2=A0 =C2=A0 =C2=A0 AS5421-MNT
created: =C2=A0= =C2=A0 =C2=A0 =C2=A02013-11-12T14:18:16Z
last-modified: =C2=A020= 13-11-12T14:18:16Z
source: =C2=A0 =C2=A0 =C2=A0 =C2=A0 RIPE # Fil= tered

% This query was served by the RIPE Database= Query Service version 1.84.1 (DB-1)

Wo= mbat:~ wkumari$ traceroute 192.0.2.1
traceroute to 192.0.2.1 (192= .0.2.1), 64 hops max, 52 byte packets
=C2=A01 =C2=A010.10.10.254 = (10.10.10.254) =C2=A010.884 ms =C2=A02.628 ms =C2=A00.902 ms
=C2= =A02 =C2=A0172.20.0.1 (172.20.0.1) =C2=A03.901 ms =C2=A012.389 ms =C2=A01.8= 24 ms
=C2=A03 =C2=A012.197.88.1 (12.197.88.1) =C2=A02.102 ms =C2= =A02.084 ms =C2=A02.246 ms
=C2=A04 =C2=A0* * *
=C2=A05 = =C2=A0* * *


192.0.2.0/24 is one of the IPv4 documentation prefixes. = It is being leaked into the table by AS5421 (Sofia University St. Kliment O= hridski).
If you don't automatically filter bogons these data= , they *will* leak into the global tables.

Tracero= ute leaves my access-point, the hotel (Hyatt) NAT and then packets get drop= ped once they enter ATT.

Belt *and* suspenders *an= d* duct tape *and* baling wire...

W

=
=C2=A0

--
Michael Richardson <mcr+IETF@sandelman.ca>, Sandelman Software Works
=C2=A0-=3D IPv6 IoT consulting =3D-



--------------------------------------------------------------------
IETF IPv6 working group mailing list
ipv6@ietf.org
Administrative Requests: https://www.ietf.org/mailman/list= info/ipv6
--------------------------------------------------------------------
--001a11491bf663f4c5052a0a89c4-- From nobody Sun Jan 24 06:07:21 2016 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7F4251B313B; Sun, 24 Jan 2016 06:07:19 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id j9xV5iH1oaNf; Sun, 24 Jan 2016 06:07:17 -0800 (PST) Received: from fgont.go6lab.si (fgont.go6lab.si [91.239.96.14]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 785FB1B313A; Sun, 24 Jan 2016 06:07:17 -0800 (PST) Received: from [192.168.2.101] (unknown [181.165.125.191]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by fgont.go6lab.si (Postfix) with ESMTPSA id C0BE42069D3; Sun, 24 Jan 2016 15:07:09 +0100 (CET) Subject: Re: 2001:db8 To: Kerry Lynn , sthaug@nethelp.no References: <56A27712.1060003@si6networks.com> <56A2A760.9050906@gmail.com> <20160123.094112.74677233.sthaug@nethelp.no> From: Fernando Gont X-Enigmail-Draft-Status: N1110 Message-ID: <56A4B761.1040601@si6networks.com> Date: Sun, 24 Jan 2016 08:37:05 -0300 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.5.1 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Archived-At: Cc: yhb@ruijie.com.cn, 6man 6man , draft-ietf-6man-rfc4291bis@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 24 Jan 2016 14:07:19 -0000 On 01/23/2016 11:38 AM, Kerry Lynn wrote: > On Sat, Jan 23, 2016 at 3:41 AM, > wrote: > > > > Another "WTF" was that on some platforms 2001:db8::/64 seem to be > > > blocked by the kernel, and not usable at all. > > > > That seems quite reasonable, though. (Don't you mean 2001:db8::/32?) > > > > Which platforms, BTW? And was it connect or send that complained? > > That seems quite *un*reasonable to me. I would certainly vote with > my wallet and refuse to buy such equipment. > > To quote from RFC 3849: > "This is *not* a local-use address prefix, and the filters may be used > in both local and public contexts." (Emphasis mine.) > > I think it's a reasonable choice to filter bogus packets at the source. I find it unreasonable that this is the only crap that the boxes in question filter, and, even more, than there's no way to override this. Id also expect that something that is used in documentation is usable in a local context -- otherwise, how could I possibly e.g. deliver a virtual network to students, and at the same time document such network using a prefix that is IETF-friendly for that purpose? -- the only option I've seen has been to use ULAs, but then one is not really supposed to use ULAs for that. Thanks, -- Fernando Gont SI6 Networks e-mail: fgont@si6networks.com PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492 From nobody Sun Jan 24 06:07:33 2016 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0B2591B313C; Sun, 24 Jan 2016 06:07:32 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id t_GwfL_rWfrN; Sun, 24 Jan 2016 06:07:24 -0800 (PST) Received: from fgont.go6lab.si (fgont.go6lab.si [91.239.96.14]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0D2F71B3140; Sun, 24 Jan 2016 06:07:24 -0800 (PST) Received: from [192.168.2.101] (unknown [181.165.125.191]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by fgont.go6lab.si (Postfix) with ESMTPSA id 180FD206A0A; Sun, 24 Jan 2016 15:07:18 +0100 (CET) Subject: Re: 2001:db8 To: Alejandro Acosta , Kerry Lynn , sthaug@nethelp.no References: <56a413a6.c5e30d0a.b212.ffff9088@mx.google.com> From: Fernando Gont Message-ID: <56A4B7CA.6090606@si6networks.com> Date: Sun, 24 Jan 2016 08:38:50 -0300 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.5.1 MIME-Version: 1.0 In-Reply-To: <56a413a6.c5e30d0a.b212.ffff9088@mx.google.com> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Archived-At: Cc: 6man 6man , yhb@ruijie.com.cn, draft-ietf-6man-rfc4291bis@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 24 Jan 2016 14:07:32 -0000 On 01/23/2016 02:51 PM, Alejandro Acosta wrote: > Does filter mean to block?. > > > -------- Original Message -------- > Subject: Re: 2001:db8 > From: Kerry Lynn > To: sthaug@nethelp.no > CC: yhb@ruijie.com.cn,6man 6man > ,draft-ietf-6man-rfc4291bis@ietf.org,Fernando Gont > > > On Sat, Jan 23, 2016 at 3:41 AM, > wrote: > > > > Another "WTF" was that on some platforms 2001:db8::/64 seem > to be > > > blocked by the kernel, and not usable at all. > > > > That seems quite reasonable, though. (Don't you mean > 2001:db8::/32?) > > > > Which platforms, BTW? And was it connect or send that complained? > > That seems quite *un*reasonable to me. I would certainly vote with > my wallet and refuse to buy such equipment. > > To quote from RFC 3849: > "This is *not* a local-use address prefix, and the filters may be used > in both local and public contexts." (Emphasis mine.) > > I think it's a reasonable choice to filter bogus packets at the source. In this context, yes. -- Fernando Gont SI6 Networks e-mail: fgont@si6networks.com PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492 From nobody Sun Jan 24 06:07:46 2016 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D9FD51B3144; Sun, 24 Jan 2016 06:07:44 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4-vmfbC1f_El; Sun, 24 Jan 2016 06:07:42 -0800 (PST) Received: from fgont.go6lab.si (fgont.go6lab.si [IPv6:2001:67c:27e4::14]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0719D1B3149; Sun, 24 Jan 2016 06:07:36 -0800 (PST) Received: from [192.168.2.101] (unknown [181.165.125.191]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by fgont.go6lab.si (Postfix) with ESMTPSA id BC784206A13; Sun, 24 Jan 2016 15:07:31 +0100 (CET) Subject: Re: 2001:db8 [was Re: draft-ietf-6man-rfc4291bis] To: Mark Smith , Michael Richardson References: <56A27712.1060003@si6networks.com> <56A2A760.9050906@gmail.com> <28158.1453566884@obiwan.sandelman.ca> From: Fernando Gont X-Enigmail-Draft-Status: N1110 Message-ID: <56A4D946.5040604@si6networks.com> Date: Sun, 24 Jan 2016 11:01:42 -0300 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.5.1 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit Archived-At: Cc: draft-ietf-6man-rfc4291bis@ietf.org, 6man WG X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 24 Jan 2016 14:07:45 -0000 On 01/23/2016 08:02 PM, Mark Smith wrote: > > On 24 Jan 2016 3:04 AM, "Michael Richardson" > wrote: >> >> >> Brian E Carpenter > wrote: >> > On 23/01/2016 07:38, Fernando Gont wrote: >> >> >> Another "WTF" was that on some platforms 2001:db8::/64 seem to be >> >> blocked by the kernel, and not usable at all. >> >> > That seems quite reasonable, though. (Don't you mean 2001:db8::/32?) >> >> It's not reasonable to me. It should be possible to setup a lab of > equipment >> according to the documentation that was provided, exactly as documented. >> > > While I sympathise with the viewpoint, that is using that documentation > prefix for more documentation. > > I think ULAs for training labs are better, and would show that > documentation prefixes should not be used on live networks of any type. Then, how do you document such lab while still complying with our rules for documentation? A prefix that can only be used to write on paper is not of much use... and to some extent a waste of address space... -- Fernando Gont SI6 Networks e-mail: fgont@si6networks.com PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492 From nobody Sun Jan 24 06:07:55 2016 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4EAA81B3153; Sun, 24 Jan 2016 06:07:47 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ns1m4rIeqH4u; Sun, 24 Jan 2016 06:07:46 -0800 (PST) Received: from fgont.go6lab.si (fgont.go6lab.si [IPv6:2001:67c:27e4::14]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4D4181B313C; Sun, 24 Jan 2016 06:07:41 -0800 (PST) Received: from [192.168.2.101] (unknown [181.165.125.191]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by fgont.go6lab.si (Postfix) with ESMTPSA id 0E39A206A12; Sun, 24 Jan 2016 15:07:37 +0100 (CET) Subject: Re: 2001:db8 [was Re: draft-ietf-6man-rfc4291bis] To: Raymond Burkholder , '6man WG' , draft-ietf-6man-rfc4291bis@ietf.org References: <56A27712.1060003@si6networks.com> <56A2A760.9050906@gmail.com> <28158.1453566884@obiwan.sandelman.ca> <28bf01d15634$c0491c40$40db54c0$@oneunified.net> From: Fernando Gont X-Enigmail-Draft-Status: N1110 Message-ID: <56A4D9D5.7010507@si6networks.com> Date: Sun, 24 Jan 2016 11:04:05 -0300 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.5.1 MIME-Version: 1.0 In-Reply-To: <28bf01d15634$c0491c40$40db54c0$@oneunified.net> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit Archived-At: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 24 Jan 2016 14:07:47 -0000 On 01/23/2016 08:21 PM, Raymond Burkholder wrote: >>> >>> It's not reasonable to me. It should be possible to setup a lab of equipment >>> according to the documentation that was provided, exactly as documented. >>> >> While I sympathise with the viewpoint, that is using that documentation prefix for more documentation. >> I think ULAs for training labs are better, and would show that documentation prefixes should not be used on live networks of any type. > > I believe it goes both ways. When writing documentation, you want to test what you documented. So, you build something with the documentation addresses, prove that it works, then put into documentation verbatim. Exactly. And not just that: at times you also want to show the output of actual commands, tests, etc. And if the documentation prefixes are not usable, you have to resort to use a different prefix, then "patch" the output. -- this wastes manpower, and also potentially introduces errors (and, at times, it may not even be possible (think about screen captures of a GUI)). -- Fernando Gont SI6 Networks e-mail: fgont@si6networks.com PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492 From nobody Sun Jan 24 06:17:28 2016 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3FC7B1A1A3D; Sun, 24 Jan 2016 06:17:27 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id C7CR03VL7_C4; Sun, 24 Jan 2016 06:17:25 -0800 (PST) Received: from fgont.go6lab.si (fgont.go6lab.si [IPv6:2001:67c:27e4::14]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 736CC1A1A3C; Sun, 24 Jan 2016 06:17:25 -0800 (PST) Received: from [192.168.2.101] (unknown [181.165.125.191]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by fgont.go6lab.si (Postfix) with ESMTPSA id 30A4F206A12; Sun, 24 Jan 2016 15:07:42 +0100 (CET) Subject: Re: 2001:db8 [was Re: draft-ietf-6man-rfc4291bis] To: Warren Kumari , Michael Richardson , 6man WG , draft-ietf-6man-rfc4291bis@ietf.org References: <56A27712.1060003@si6networks.com> <56A2A760.9050906@gmail.com> <28158.1453566884@obiwan.sandelman.ca> From: Fernando Gont X-Enigmail-Draft-Status: N1110 Message-ID: <56A4DADB.50400@si6networks.com> Date: Sun, 24 Jan 2016 11:08:27 -0300 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.5.1 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit Archived-At: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 24 Jan 2016 14:17:27 -0000 On 01/23/2016 10:40 PM, Warren Kumari wrote: [....] > > > Counterpoint: > > If you don't automatically filter, this stuff leaks into tables, etc. > The Internet is no longer a place where you can assume that everyone > playing has clue.... [....] > If you don't automatically filter bogons these data, they *will* leak > into the global tables. > > Traceroute leaves my access-point, the hotel (Hyatt) NAT and then > packets get dropped once they enter ATT. > > Belt *and* suspenders *and* duct tape *and* baling wire... I guess I would complain less if: 1) Said platform were to drop other crap 2) There was an option to override this behavior The above said, I'm left with the question: "If you want to, say, provide a virtual network for training (along with documentation), and/or show the output of tools run on said network, which prefix would you use, while still complying with IETF documentation 'rules'?". Cheers, -- Fernando Gont SI6 Networks e-mail: fgont@si6networks.com PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492 From nobody Sun Jan 24 06:49:36 2016 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DBCCC1A0013; Sun, 24 Jan 2016 06:49:34 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.902 X-Spam-Level: X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xWSEPYlvhkQx; Sun, 24 Jan 2016 06:49:33 -0800 (PST) Received: from tuna.sandelman.ca (tuna.sandelman.ca [IPv6:2607:f0b0:f:3:216:3eff:fe7c:d1f3]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 653E71A0011; Sun, 24 Jan 2016 06:49:33 -0800 (PST) Received: from sandelman.ca (obiwan.sandelman.ca [209.87.249.21]) by tuna.sandelman.ca (Postfix) with ESMTP id 36B842002A; Sun, 24 Jan 2016 09:57:49 -0500 (EST) Received: from obiwan.sandelman.ca (ip6-localhost [IPv6:::1]) by sandelman.ca (Postfix) with ESMTP id 250FB63751; Sun, 24 Jan 2016 09:49:32 -0500 (EST) From: Michael Richardson To: "Raymond Burkholder" Subject: Re: 2001:db8 [was Re: draft-ietf-6man-rfc4291bis] In-Reply-To: <28bf01d15634$c0491c40$40db54c0$@oneunified.net> References: <56A27712.1060003@si6networks.com> <56A2A760.9050906@gmail.com> <28158.1453566884@obiwan.sandelman.ca> <28bf01d15634$c0491c40$40db54c0$@oneunified.net> X-Mailer: MH-E 8.6; nmh 1.6+dev; GNU Emacs 24.4.2 X-Face: $\n1pF)h^`}$H>Hk{L"x@)JS7<%Az}5RyS@k9X%29-lHB$Ti.V>2bi.~ehC0; <'$9xN5Ub# z!G,p`nR&p7Fz@^UXIn156S8.~^@MJ*mMsD7=QFeq%AL4m Archived-At: Cc: draft-ietf-6man-rfc4291bis@ietf.org, '6man WG' X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 24 Jan 2016 14:49:35 -0000 --=-=-= Content-Type: text/plain Raymond Burkholder wrote: > I believe it goes both ways. When writing documentation, you want to > test what you documented. So, you build something with the > documentation addresses, prove that it works, then put into > documentation verbatim. Exactly. (Using a ULA would convince some people that they can only use a ULA in certain situations where in fact, a ULA would be wrong) -- Michael Richardson , Sandelman Software Works -= IPv6 IoT consulting =- --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.12 (GNU/Linux) iQEVAwUBVqTkeYCLcPvd0N1lAQJpjQgAvbVYKQLudgvxg1t6PcMNTFWbR9fpQ2OS SL3cAJNqHuxG9MsHrfPnKp3d2kFzo+g5Vrhe1ahlLP0NHIwU4+KsEDZpC2uveSoV vRU/t1puWOBPpW0xIqTQcImm3ldE0dhfrG7qkWPpRY3eteYPq6B3K0ELHwBrfzs2 llzvJNL0C5msl9hk35SnSZhjMyquvvBtZO3wnlHj4UrDdb6V3x9+1p0tk0MNomMj fuzsnmDDNI0CRbMl1NrLZm4NAcicYN0rQPhfqkqS1GDNYQcN2BoZDEU7sgCEsbZ9 Ry/lOdSSJBYDMnZuy8PmyCrKTvUVtmwy1jcm8NEJqgdke3VVbv5K8Q== =9ZPO -----END PGP SIGNATURE----- --=-=-=-- From nobody Sun Jan 24 06:52:41 2016 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B75011A0029; Sun, 24 Jan 2016 06:52:39 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.902 X-Spam-Level: X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id B-v34HmKm6qD; Sun, 24 Jan 2016 06:52:38 -0800 (PST) Received: from tuna.sandelman.ca (tuna.sandelman.ca [209.87.249.19]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 998091A002D; Sun, 24 Jan 2016 06:52:38 -0800 (PST) Received: from sandelman.ca (obiwan.sandelman.ca [209.87.249.21]) by tuna.sandelman.ca (Postfix) with ESMTP id C8C4F2002A; Sun, 24 Jan 2016 10:00:54 -0500 (EST) Received: from obiwan.sandelman.ca (ip6-localhost [IPv6:::1]) by sandelman.ca (Postfix) with ESMTP id B97A863751; Sun, 24 Jan 2016 09:52:37 -0500 (EST) From: Michael Richardson To: Warren Kumari Subject: Re: 2001:db8 [was Re: draft-ietf-6man-rfc4291bis] In-Reply-To: References: <56A27712.1060003@si6networks.com> <56A2A760.9050906@gmail.com> <28158.1453566884@obiwan.sandelman.ca> X-Mailer: MH-E 8.6; nmh 1.6+dev; GNU Emacs 24.4.2 X-Face: $\n1pF)h^`}$H>Hk{L"x@)JS7<%Az}5RyS@k9X%29-lHB$Ti.V>2bi.~ehC0; <'$9xN5Ub# z!G,p`nR&p7Fz@^UXIn156S8.~^@MJ*mMsD7=QFeq%AL4m Archived-At: Cc: draft-ietf-6man-rfc4291bis@ietf.org, 6man WG X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 24 Jan 2016 14:52:39 -0000 --=-=-= Content-Type: text/plain Warren Kumari wrote: > Counterpoint: > If you don't automatically filter, this stuff leaks into tables, etc. > The Internet is no longer a place where you can assume that everyone playing > has clue.... Nobody said that it shouldn't be filtered by default, but the default needs to be an explicit list, not compiled in code, which it appears has occured. There are probably a dozen prefixes that should never go into the DFZ, and I have no problem if a router manufacturer provides a prefix-list that is pre-initialized with those values. But, using that should be at the operator's discretion. > 192.0.2.0/24 is one of the IPv4 documentation prefixes. It is being leaked > into the table by AS5421 (Sofia University St. Kliment Ohridski). > If you don't automatically filter bogons these data, they *will* leak into > the global tables. Nobody is arguing otherwise. -- Michael Richardson , Sandelman Software Works -= IPv6 IoT consulting =- --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.12 (GNU/Linux) iQEVAwUBVqTlLYCLcPvd0N1lAQJqQAgApBWxlTShPaWu/HvB7fGBqpkq3bTvhaML NMKBrXKFNWwtQPPoueYnja3eED4w9YsIIvwlsPp6bEk44B2ZfZItrkXqArS3vrLP 4Srln1tY99yrMmI2ki2vny8X56wDbOiQAm8agFD+qNYt8XKOmxjYkueY1e8Ax+q6 nSbqwgLbz60SNxzZjr96pmfudBXZmT7eqmFKAm+lN+hiOVbS8s8JEKwzNmdu+5Lk EO9h6YR4WgpQpUtyFmpDkP7OycGKBlo1tlgD6o8wzZ0EgthuVY6jGGKzqzA1E1tB 2Z2dxX68bfcD3GhbGREThr/DtYr3XF7Pu2UnfY2Sy3ZuFRyFayKU/g== =QXUc -----END PGP SIGNATURE----- --=-=-=-- From nobody Sun Jan 24 06:54:02 2016 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 703BA1A0029; Sun, 24 Jan 2016 06:54:01 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.902 X-Spam-Level: X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YkYZj3obfP99; Sun, 24 Jan 2016 06:54:00 -0800 (PST) Received: from tuna.sandelman.ca (tuna.sandelman.ca [IPv6:2607:f0b0:f:3:216:3eff:fe7c:d1f3]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4E9791A0026; Sun, 24 Jan 2016 06:54:00 -0800 (PST) Received: from sandelman.ca (obiwan.sandelman.ca [IPv6:2607:f0b0:f:2::247]) by tuna.sandelman.ca (Postfix) with ESMTP id 975142002A; Sun, 24 Jan 2016 10:02:16 -0500 (EST) Received: from obiwan.sandelman.ca (ip6-localhost [IPv6:::1]) by sandelman.ca (Postfix) with ESMTP id 842AA63751; Sun, 24 Jan 2016 09:53:59 -0500 (EST) From: Michael Richardson To: Fernando Gont Subject: Re: 2001:db8 In-Reply-To: <56A4B761.1040601@si6networks.com> References: <56A27712.1060003@si6networks.com> <56A2A760.9050906@gmail.com> <20160123.094112.74677233.sthaug@nethelp.no> <56A4B761.1040601@si6networks.com> X-Mailer: MH-E 8.6; nmh 1.6+dev; GNU Emacs 24.4.2 X-Face: $\n1pF)h^`}$H>Hk{L"x@)JS7<%Az}5RyS@k9X%29-lHB$Ti.V>2bi.~ehC0; <'$9xN5Ub# z!G,p`nR&p7Fz@^UXIn156S8.~^@MJ*mMsD7=QFeq%AL4m Date: Sun, 24 Jan 2016 09:53:59 -0500 Message-ID: <30230.1453647239@obiwan.sandelman.ca> Archived-At: Cc: draft-ietf-6man-rfc4291bis@ietf.org, 6man 6man , yhb@ruijie.com.cn X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 24 Jan 2016 14:54:01 -0000 Fernando Gont wrote: > Id also expect that something that is used in documentation is usable in > a local context -- otherwise, how could I possibly e.g. deliver a > virtual network to students, and at the same time document such network > using a prefix that is IETF-friendly for that purpose? > -- the only option I've seen has been to use ULAs, but then one is not > really supposed to use ULAs for that. And, ULAs don't fit into the 2000::/3 filter that you'd want to write to include or exclude things. -- ] Never tell me the odds! | ipv6 mesh networks [ ] Michael Richardson, Sandelman Software Works | network architect [ ] mcr@sandelman.ca http://www.sandelman.ca/ | ruby on rails [ From nobody Sun Jan 24 08:04:08 2016 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B85291A1A06 for ; Sun, 24 Jan 2016 08:04:06 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.902 X-Spam-Level: X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UDaz9tgQSO6h for ; Sun, 24 Jan 2016 08:04:05 -0800 (PST) Received: from tuna.sandelman.ca (tuna.sandelman.ca [IPv6:2607:f0b0:f:3:216:3eff:fe7c:d1f3]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 265A01A1A02 for ; Sun, 24 Jan 2016 08:04:05 -0800 (PST) Received: from sandelman.ca (obiwan.sandelman.ca [IPv6:2607:f0b0:f:2::247]) by tuna.sandelman.ca (Postfix) with ESMTP id 45B012002A for ; Sun, 24 Jan 2016 11:12:21 -0500 (EST) Received: from obiwan.sandelman.ca (ip6-localhost [IPv6:::1]) by sandelman.ca (Postfix) with ESMTP id F343063751 for ; Sun, 24 Jan 2016 11:04:03 -0500 (EST) From: Michael Richardson To: ipv6@ietf.org Subject: should the IPv6 "default" route really be ::/0? X-Attribution: mcr X-Mailer: MH-E 8.6; nmh 1.6+dev; GNU Emacs 24.4.2 X-Face: $\n1pF)h^`}$H>Hk{L"x@)JS7<%Az}5RyS@k9X%29-lHB$Ti.V>2bi.~ehC0; <'$9xN5Ub# z!G,p`nR&p7Fz@^UXIn156S8.~^@MJ*mMsD7=QFeq%AL4m Archived-At: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 24 Jan 2016 16:04:06 -0000 <#secure method=pgpmime mode=sign> I've been dog-fooding v6-over-IPsec for IPv6 access of late? (i.e. instead of sixxs/he/aiccu/etc. on my laptop when at the legacy coffee shop.) Naively, this involves building a tunnel from myip/128 -> ::/0. A stupidity of the BSD/Linux WIDE/XFRM IPsec architecture is that it has an additional firewall in the output path that encrypts the packets. If there is *no route* for the destination, then the packets get no-route error, never get to the output path and never get encrypted. Back in the day, I tried to convince Itojun that we should have a virtual interface for IPsec tunnels, and that the IPsec policy (which is source sensitive as well as destination sensitive) should live in the routing table. It's too bad we didn't go that way because it would have given us SADR much earlier, and would have made the need for application involvement clearer long ago. Itojun asked me a simple question which I couldn't answer: What is the scope of this virtual interface? I've never been able to adequately answer the question. I made sure that the right route gets created; historically on Linux the route was added out the same interface as the default pointed, towards the same next-hop router, but in a mixed v4/v6 situation, there isn't a default v6 route to "emulate", and I also asked my self the question: Why am I building a route to ::/0? That's not the Internet. The Internet is at 2000::/3. I see no reason why I should be routing traffic in the f000::/3 range, which is all special use: multicast, link-local, ULA, etc. Which lead me to ask: why does it mean when a RA says it a default route? (Part of this email is prompted by the 2001:db8 discussion). What prefixes should a host always have some other route for? i.e. filter by longest prefix-match out. DNS64/NAT64 certainly takes advantage of ::/0 covering 0::/3, which includes, 64::/96. But that also covers all the v4-mapped address spaces, and the like. What if hosts started considering "default route" to really mean 2000::/3? Or should we instead suggest that hosts should include blackhole routes for things like: f000::/3? Now, in my tunnel case, I'm using the IPsec tunnel to get IPv6, not exactly for security. I'd like the tunnel to remain up, even if I have IPv6, because it gives mobileIP-like connectivity, and if I had native IPv6, I might want to use a binding update. If I had native IPv6, I'd have a ::/0 route, but that's less specific than 2000::/3, so my native traffic goes the wrong way if I don't put my 2000::/3 route on the correct interface. So I have to use ::/0 for my extrusion, just at a lower metric, so that the two potentially two ::/0 can compete properly... And that is the reason why I started thinking that maybe it was the system that was wrong to use a ::/0 route for default. -- Michael Richardson , Sandelman Software Works -= IPv6 IoT consulting =- From nobody Sun Jan 24 08:06:35 2016 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5A5111A1A2D; Sun, 24 Jan 2016 08:06:34 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.902 X-Spam-Level: X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 32jacMPOPvnk; Sun, 24 Jan 2016 08:06:33 -0800 (PST) Received: from mail1.oneunified.net (mail1.oneunified.net [63.85.42.215]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 10E541A1A2C; Sun, 24 Jan 2016 08:06:32 -0800 (PST) X-OneUnified-MailScanner-Watermark: 1454256389.38378@jtaZGVLwhKyvg6p90DIMDw X-OneUnified-MailScanner-From: ray@oneunified.net X-OneUnified-MailScanner: Found to be clean X-OneUnified-MailScanner-ID: u0OG6QBC022764 X-OneUnified-MailScanner-Information: Please contact the ISP for more information Received: from Ray (mail1.oneunified.net [63.85.42.215]) by mail1.oneunified.net (8.14.4/8.14.4/Debian-4) with ESMTP id u0OG6QBC022764; Sun, 24 Jan 2016 16:06:27 GMT From: "Raymond Burkholder" To: , "'6man WG'" References: <56A27712.1060003@si6networks.com> <56A2A760.9050906@gmail.com> <28158.1453566884@obiwan.sandelman.ca> <29930.1453647157@obiwan.sandelman.ca> In-Reply-To: <29930.1453647157@obiwan.sandelman.ca> Subject: RE: 2001:db8 [was Re: draft-ietf-6man-rfc4291bis] Date: Sun, 24 Jan 2016 12:06:20 -0400 Message-ID: <02ee01d156c1$2af63370$80e29a50$@oneunified.net> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 16.0 Thread-Index: AQJXASurk8R8qgvdvgcdU859B1BnhwGfJZAHAzRJ2bAByIUhDgJggptqAeAaxZIBxyUKTQFMqfcXnY/8bVA= Content-Language: en-us Archived-At: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 24 Jan 2016 16:06:34 -0000 > Nobody said that it shouldn't be filtered by default, but the default needs > to be an explicit list, not compiled in code, which it appears has occured. > > There are probably a dozen prefixes that should never go into the DFZ, and I > have no problem if a router manufacturer provides a prefix-list that is > pre-initialized with those values. But, using that should be at the > operator's discretion. Otherwise we'll end up with what happened with 240.0.0.0/4, where it was hard-coded and can't be re-used without herculean effort. But too late for that particular case, but is a reminder not to do the same wrong thing over again. -- This message has been scanned for viruses and dangerous content by MailScanner, and is believed to be clean. From nobody Sun Jan 24 08:38:43 2016 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4AFF41A1B51; Sun, 24 Jan 2016 08:38:41 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.702 X-Spam-Level: X-Spam-Status: No, score=-2.702 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_LOW=-0.7, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PgfJoFi-rmEb; Sun, 24 Jan 2016 08:38:39 -0800 (PST) Received: from maila2.tigertech.net (maila2.tigertech.net [208.80.4.152]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D4D0C1A1B4B; Sun, 24 Jan 2016 08:38:39 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by maila2.tigertech.net (Postfix) with ESMTP id 5DB8125F048; Sun, 24 Jan 2016 08:38:39 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=joelhalpern.com; s=1.tigertech; t=1453653519; bh=x1JybpOCl7/wncA0vflW3KNUbHuh87pXTtn0QsczM+Q=; h=Subject:To:References:Cc:From:Date:In-Reply-To:From; b=kW81pgH6lwsUlnw6r7iKYQ11Ct9aYMZ/Ppz3sNF3Pt5lgtXa2mzN8NopKC3MFQ6Qg Yb0rjs5Z++A3SbNOu2wUoHVM56fA3PHD1rwWU2qPQPkPeCCR4JHmuTRhX3SE29CTQN H/R3P0gbRaYI5O8iCxMBL8lHbKAQDdoNXWAwWt74= X-Virus-Scanned: Debian amavisd-new at maila2.tigertech.net Received: from Joels-MacBook-Pro.local (209-255-163-147.ip.mcleodusa.net [209.255.163.147]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by maila2.tigertech.net (Postfix) with ESMTPSA id AAEC925F046; Sun, 24 Jan 2016 08:38:38 -0800 (PST) Subject: Re: 2001:db8 [was Re: draft-ietf-6man-rfc4291bis] To: Fernando Gont , Mark Smith , Michael Richardson References: <56A27712.1060003@si6networks.com> <56A2A760.9050906@gmail.com> <28158.1453566884@obiwan.sandelman.ca> <56A4D946.5040604@si6networks.com> From: "Joel M. Halpern" Message-ID: <56A4FE06.2090705@joelhalpern.com> Date: Sun, 24 Jan 2016 11:38:30 -0500 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:38.0) Gecko/20100101 Thunderbird/38.5.1 MIME-Version: 1.0 In-Reply-To: <56A4D946.5040604@si6networks.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Cc: 6man WG , draft-ietf-6man-rfc4291bis@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 24 Jan 2016 16:38:41 -0000 Documenting a Lab is quite different from documenting a protocol. We found, far too often, that IP addresses used in RFCs and similar documents were being copied verbatim into networks that then leaked into the operational world. This was not a guess. This was an observed property. So the IETF took a decision to reserve a block of addresses for use in documentation that would never appear on the wire, anywhere. It was the only way we could find to resolve this problem. And it seems to have significantly improved the situation. Yes, it is a rule we made. Yes, we could change it. But before asking that it be changed, please look at the potential risk, and include those observed risks in any discussion of changing the rules. Yours, Joel On 1/24/16 9:01 AM, Fernando Gont wrote: > On 01/23/2016 08:02 PM, Mark Smith wrote: >> >> On 24 Jan 2016 3:04 AM, "Michael Richardson" > > wrote: >>> >>> >>> Brian E Carpenter > > wrote: >>> > On 23/01/2016 07:38, Fernando Gont wrote: >>> >>> >> Another "WTF" was that on some platforms 2001:db8::/64 seem to be >>> >> blocked by the kernel, and not usable at all. >>> >>> > That seems quite reasonable, though. (Don't you mean 2001:db8::/32?) >>> >>> It's not reasonable to me. It should be possible to setup a lab of >> equipment >>> according to the documentation that was provided, exactly as documented. >>> >> >> While I sympathise with the viewpoint, that is using that documentation >> prefix for more documentation. >> >> I think ULAs for training labs are better, and would show that >> documentation prefixes should not be used on live networks of any type. > > Then, how do you document such lab while still complying with our rules > for documentation? > > A prefix that can only be used to write on paper is not of much use... > and to some extent a waste of address space... > From nobody Sun Jan 24 11:45:30 2016 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E98171ACEEF for ; Sun, 24 Jan 2016 11:45:28 -0800 (PST) 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=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7IXuXiNMv7sA for ; Sun, 24 Jan 2016 11:45:27 -0800 (PST) Received: from mail-pa0-x232.google.com (mail-pa0-x232.google.com [IPv6:2607:f8b0:400e:c03::232]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9269E1ACEB1 for ; Sun, 24 Jan 2016 11:45:27 -0800 (PST) Received: by mail-pa0-x232.google.com with SMTP id yy13so68939408pab.3 for ; Sun, 24 Jan 2016 11:45:27 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=subject:to:references:from:organization:message-id:date:user-agent :mime-version:in-reply-to:content-type:content-transfer-encoding; bh=eSVVSBoZiqI82qsepunD1bm8Vn2SfFCRveik/F0OHOA=; b=GL7s4xhrHgDMNSZ2+/aNxUimLFYWTgv3SUBTJRZ8WxoUnnPTBrxY/E1NVyzNC54eBd +VcOPu0sOOCobPu5SD8T39JVQvBlHYLyNGkyrFlY0ElnMbeMA0gRAzpVv1mlR32S5JdP j41QPwMon2pLqOgpY1SSCI5CLZEneG8BHl1k+iHyNkKehdZkXkrcZby7LZOhFdiPG57j Rd6USmc2geSz+RR1Qp38YF8K0PGEIFBYkTZZvlQgPeKMPosFSZIKIiDud+wQYU/10sc7 H5l7ApPqZ3s7IWkvWPlP8i8vqBcY3fsmNeKr5eatDB7tVyU0j8scIcwpAjRXBdbnJ/nZ /LYQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:subject:to:references:from:organization :message-id:date:user-agent:mime-version:in-reply-to:content-type :content-transfer-encoding; bh=eSVVSBoZiqI82qsepunD1bm8Vn2SfFCRveik/F0OHOA=; b=i3uv4MWp44hWhQ7s5rc34g4VIYFwuNEvv4kZWo/Z1T3oSCv967SLmaDOzRFt57xsBm OxhananQVBHI+xMDJibUKpM84mRruS9+MYL+bHPUSBqRPq5lLjOrw8FJ3Pa/qRWROdkb FreXiTgSqJi524IeWe1Cr2v2KHJcJgN7wsnPi++zBvR0IVGw0V6/Y3aZitFxMeEpQlkT 5Uh6iMv6jg+XFtpLUbMdhZirMBAB01BRo30pCRKK9zVxCmFrhuKJoGbovDQ+Ep9zZHKV tR5M4pjbX2jVSNfUdWZlfEw4ZmnI3y4QhcQrwNU0b13N1GeQeJFHh8Htxo8AfZ9Jz0yU vTww== X-Gm-Message-State: AG10YOQ9IKVuJ0PbjFIdK5eL4WK3YjFAGMNj+MpSxDz+Xa9eQAGjddz7Zdv+VauQ+Z3esg== X-Received: by 10.66.149.7 with SMTP id tw7mr20784841pab.72.1453664727242; Sun, 24 Jan 2016 11:45:27 -0800 (PST) Received: from ?IPv6:2406:e007:614b:1:28cc:dc4c:9703:6781? ([2406:e007:614b:1:28cc:dc4c:9703:6781]) by smtp.gmail.com with ESMTPSA id dg12sm23248149pac.47.2016.01.24.11.45.24 (version=TLSv1/SSLv3 cipher=OTHER); Sun, 24 Jan 2016 11:45:26 -0800 (PST) Subject: Re: should the IPv6 "default" route really be ::/0? To: Michael Richardson , ipv6@ietf.org References: <13430.1453651443@obiwan.sandelman.ca> From: Brian E Carpenter Organization: University of Auckland Message-ID: <56A529D4.3030707@gmail.com> Date: Mon, 25 Jan 2016 08:45:24 +1300 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.5.1 MIME-Version: 1.0 In-Reply-To: <13430.1453651443@obiwan.sandelman.ca> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Archived-At: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 24 Jan 2016 19:45:29 -0000 Just getting at one sub-issue: On 25/01/2016 05:04, Michael Richardson wrote: ... > That's not the Internet. The Internet is at 2000::/3. Well, no, and that is the crux of the problem. That's only the part of the Internet that IANA is currently handing out prefixes for. 4000::/3 is part of the Internet too. The Internet is ::/0 minus the prefixes that aren't the Internet. Neatly defined in https://tools.ietf.org/html/draft-ietf-6man-rfc4291bis-01#section-2.3 as "(everything else)" No single prefix correctly identifies "everything else". (I had a rather useless idea many years ago called "holemaps", which would have been data structures expressing the holes in a given prefix, i.e. invalid sub-prefixes, and "everything else" is in fact ::/0 plus a holemap.) Brian From nobody Sun Jan 24 12:33:22 2016 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3CE221B329A for ; Sun, 24 Jan 2016 12:33:21 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.303 X-Spam-Level: X-Spam-Status: No, score=-2.303 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=unavailable Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XvMNzDdT4qEZ for ; Sun, 24 Jan 2016 12:33:19 -0800 (PST) Received: from bizet.nethelp.no (bizet.nethelp.no [195.1.209.33]) by ietfa.amsl.com (Postfix) with SMTP id C40D71B3297 for ; Sun, 24 Jan 2016 12:33:18 -0800 (PST) Received: (qmail 20104 invoked from network); 24 Jan 2016 20:33:16 -0000 Received: from bizet.nethelp.no (HELO localhost) (195.1.209.33) by bizet.nethelp.no with SMTP; 24 Jan 2016 20:33:16 -0000 Date: Sun, 24 Jan 2016 21:33:16 +0100 (CET) Message-Id: <20160124.213316.74735914.sthaug@nethelp.no> To: jmh@joelhalpern.com Subject: Re: 2001:db8 From: sthaug@nethelp.no In-Reply-To: <56A4FE06.2090705@joelhalpern.com> References: <56A4D946.5040604@si6networks.com> <56A4FE06.2090705@joelhalpern.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 Archived-At: Cc: fgont@si6networks.com, ipv6@ietf.org, draft-ietf-6man-rfc4291bis@ietf.org, mcr+ietf@sandelman.ca X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 24 Jan 2016 20:33:21 -0000 > So the IETF took a decision to reserve a block of addresses for use in > documentation that would never appear on the wire, anywhere. It was the > only way we could find to resolve this problem. And it seems to have > significantly improved the situation. This decision *may* have improved the situation - however, "would never appear on the wire, anywhere" is simply not the case. The following boxes will happy route prefixes under 2001:db8::/32, as verified in the lab just now (pingable, appears in routing protocols): Juniper MX104 JunOS 14.1R6.4 Cisco ASR1001 IOS XE 15.4(3)S4 Huawei NE5000 VRP 8.90 Huawei NE40E-M2F VRP 8.100 > Yes, it is a rule we made. Yes, we could change it. But before asking > that it be changed, please look at the potential risk, and include those > observed risks in any discussion of changing the rules. I would be happy with a router which kept 2001:db8::/32 off the wire by default, but which also let me explicitly *turn off* the default behavior. A router which completely prevented me from using 2001:db8::/32 would make me rather unhappy, and I would probably vote with my wallet. Steinar Haug, AS2116 From nobody Sun Jan 24 16:53:57 2016 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A6B901B364A; Sun, 24 Jan 2016 16:53:56 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.498 X-Spam-Level: X-Spam-Status: No, score=-1.498 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, FROM_LOCAL_NOVOWEL=0.5, HK_RANDOM_ENVFROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id n9prszclzCSw; Sun, 24 Jan 2016 16:53:54 -0800 (PST) Received: from mail-vk0-x236.google.com (mail-vk0-x236.google.com [IPv6:2607:f8b0:400c:c05::236]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9C23F1B3648; Sun, 24 Jan 2016 16:53:54 -0800 (PST) Received: by mail-vk0-x236.google.com with SMTP id e64so66761208vkg.0; Sun, 24 Jan 2016 16:53:54 -0800 (PST) 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=kpcAmzzQnsU8JJB8QW+7VAamY6n0btBgnMn1YKwcPro=; b=x7+L61cMzFobBeAtFsc2o/9j+/4pCiHefTABUkwUAhjjP/y/sUqi8aTp+cliv/xruR uLZe5og7bLUgiRd1dc+Bl743JpBsA3P1nB5yFzAmh1TIoItNCAdjsYr+USoifJ+uboCF 8C2M2HMUepXqDbcVOTGEL8gr3MirTiYZLYWb6k2ena9khNKt4Xz9AE7w+HAZC/ubsKmQ D7T1BmR70vfWO0S3/a9f5Sl5yc88jt7MdMXpw04iPnR3YojbbS0J87YSJJZ9l9+e4jF7 K7fslDdZq6tzjw0ZmHWWCsE9TjKcedUuI586lkdnGp4W+DgYOd7CERWteZMluLJr+r+b Xt5A== 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:date :message-id:subject:from:to:cc:content-type; bh=kpcAmzzQnsU8JJB8QW+7VAamY6n0btBgnMn1YKwcPro=; b=ORyrbQKIqwGyfEnr6DUM67+Q/6+yqygDGoUS3+aFKnio2Swz05YKgkatXtr2R1218X yMmNRph4QTjrtcPDRBEBIkwQ9b40iRxWt0TyWCFLZAv9zJTajNq0lOMHnKvhjiY3nWs1 3s6GcnUxXP84IqhylDAf9wPhjg0RgjTOBUD9ZdYR1gbrduKNYGPpMPMbrIwBCahmscv4 2wVzfLtKHt38KPsQ0Xr0nfijIv0WF0v7T4LR824ExMf7pJVO8MgNFU7uwc/THLVJJXj7 vKpQrUnKEooqVw7vzCGhGZLdhrx9FPdA6Ve6nAuPPUbO1zS1my7DBHZv1pyET5n3BKmT 20ig== X-Gm-Message-State: AG10YOQAsJN1unTSQ9149LJ4bZiPja6SiQvSjCVJTAK9wxcoWVMmK8ZwubKLmGkZoflE6HyDy/zd19Hym0DijA== MIME-Version: 1.0 X-Received: by 10.31.6.143 with SMTP id 137mr9218945vkg.133.1453683233618; Sun, 24 Jan 2016 16:53:53 -0800 (PST) Received: by 10.103.99.1 with HTTP; Sun, 24 Jan 2016 16:53:53 -0800 (PST) Received: by 10.103.99.1 with HTTP; Sun, 24 Jan 2016 16:53:53 -0800 (PST) In-Reply-To: <56A4D946.5040604@si6networks.com> References: <56A27712.1060003@si6networks.com> <56A2A760.9050906@gmail.com> <28158.1453566884@obiwan.sandelman.ca> <56A4D946.5040604@si6networks.com> Date: Mon, 25 Jan 2016 11:53:53 +1100 Message-ID: Subject: Re: 2001:db8 [was Re: draft-ietf-6man-rfc4291bis] From: Mark Smith To: Fernando Gont Content-Type: multipart/alternative; boundary=001a1143d338c18124052a1e0048 Archived-At: Cc: 6man WG , draft-ietf-6man-rfc4291bis@ietf.org, Michael Richardson X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 25 Jan 2016 00:53:56 -0000 --001a1143d338c18124052a1e0048 Content-Type: text/plain; charset=UTF-8 On 25 Jan 2016 00:37, "Fernando Gont" wrote: > > On 01/23/2016 08:02 PM, Mark Smith wrote: > > > > On 24 Jan 2016 3:04 AM, "Michael Richardson" > > wrote: > >> > >> > >> Brian E Carpenter > > wrote: > >> > On 23/01/2016 07:38, Fernando Gont wrote: > >> > >> >> Another "WTF" was that on some platforms 2001:db8::/64 seem to be > >> >> blocked by the kernel, and not usable at all. > >> > >> > That seems quite reasonable, though. (Don't you mean 2001:db8::/32?) > >> > >> It's not reasonable to me. It should be possible to setup a lab of > > equipment > >> according to the documentation that was provided, exactly as documented. > >> > > > > While I sympathise with the viewpoint, that is using that documentation > > prefix for more documentation. > > > > I think ULAs for training labs are better, and would show that > > documentation prefixes should not be used on live networks of any type. > > Then, how do you document such lab while still complying with our rules > for documentation? > If you're recording the lab configuration for later reference, then you'd record the ULA addresses used. If you're writing documentation to demonstrate an addressing concept or to present in a presentation, then 2001:db8::/32 should be used. It's a second hand story that I heard a long time ago, however there was an instance where a company used their own IPv4 address space in early IPv4 training course notes, which students then took back to their own network and used. I think it was also leaked into the DFZ more than once (if I recall it might have been Sun and address space that started with 131.) So I see the documentation prefix to be purely used in documentation, not on any live equipment, to help prevent reuse in other networks. Using ULAs in labs, including in training course labs, also creates an opportunity to discuss how to use and generate ULAs, and why they have the random component, and use the problems of reusing a prefix like the documentation prefix or site-locals. Regards, Mark. > A prefix that can only be used to write on paper is not of much use... > and to some extent a waste of address space... > > -- > Fernando Gont > SI6 Networks > e-mail: fgont@si6networks.com > PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492 > > > > --001a1143d338c18124052a1e0048 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On 25 Jan 2016 00:37, "Fernando Gont" <fgont@si6networks.com> wrote:
>
> On 01/23/2016 08:02 PM, Mark Smith wrote:
> >
> > On 24 Jan 2016 3:04 AM, "Michael Richardson" <mcr+ietf@sandelman.ca
> > <mailto:mcr%2Biet= f@sandelman.ca>> wrote:
> >>
> >>
> >> Brian E Carpenter <brian.e.carpenter@gmail.com
> > <mailto:brian.e= .carpenter@gmail.com>> wrote:
> >>=C2=A0 =C2=A0 =C2=A0> On 23/01/2016 07:38, Fernando Gont wr= ote:
> >>
> >>=C2=A0 =C2=A0 =C2=A0>> Another "WTF" was that = on some platforms 2001:db8::/64 seem to be
> >>=C2=A0 =C2=A0 =C2=A0>> blocked by the kernel, and not us= able at all.
> >>
> >>=C2=A0 =C2=A0 =C2=A0> That seems quite reasonable, though. = (Don't you mean 2001:db8::/32?)
> >>
> >> It's not reasonable to me.=C2=A0 It should be possible to= setup a lab of
> > equipment
> >> according to the documentation that was provided, exactly as = documented.
> >>
> >
> > While I sympathise with the viewpoint, that is using that documen= tation
> > prefix for more documentation.
> >
> > I think ULAs for training labs are better, and would show that > > documentation prefixes should not be used on live networks of any= type.
>
> Then, how do you document such lab while still complying with our rule= s
> for documentation?
>

If you're recording the lab configuration for later refe= rence, then you'd record the ULA addresses used.

If you're writing documentation to demonstrate an addres= sing concept or to present in a presentation, then 2001:db8::/32 should be = used.

It's a second hand story that I heard a long time ago, h= owever there was an instance where a company used their own IPv4 address sp= ace in early IPv4 training course notes, which students then took back to t= heir own network and used. I think it was also leaked into the DFZ more tha= n once (if I recall it might have been Sun and address space that started w= ith 131.)

So I see the documentation prefix to be purely used in docum= entation, not on any live equipment, to help prevent reuse in other network= s. Using ULAs in labs, including in training course labs, also creates an o= pportunity to discuss how to use and generate ULAs, and why they have the r= andom component, and use the problems of reusing a prefix like the document= ation prefix or site-locals.

Regards,
Mark.

> A prefix that can only be used to write on paper is not= of much use...
> and to some extent a waste of address space...
>
> --
> Fernando Gont
> SI6 Networks
> e-mail: fgont@si6networks.com=
> PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492
>
>
>
>

--001a1143d338c18124052a1e0048-- From nobody Sun Jan 24 20:24:59 2016 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 39D4D1A700C for ; Sun, 24 Jan 2016 20:24:58 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.277 X-Spam-Level: X-Spam-Status: No, score=-1.277 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fJlcQvbjG2ey for ; Sun, 24 Jan 2016 20:24:56 -0800 (PST) Received: from mail-yk0-x233.google.com (mail-yk0-x233.google.com [IPv6:2607:f8b0:4002:c07::233]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B7DA91A700A for ; Sun, 24 Jan 2016 20:24:56 -0800 (PST) Received: by mail-yk0-x233.google.com with SMTP id v14so148588921ykd.3 for ; Sun, 24 Jan 2016 20:24:56 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=kumari-net.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc:content-type; bh=NQ7dBDwbGQ30RI1vUzm9Mn4SQreX4CyYl0hlcH2Wlzo=; b=CB/j6c/dDJwgx3jeeJLiAvZ4NRPj1KoG3y6IU1TRAf6xP99CZRlQM1kzvy3rSTPLbQ 5b8DBAmYCIdcCqzb34MdAItA1V2CXqfue4aw7cKS3jQUUjRyG3QK/0tutItGTSrFDS0U j6bURIfO2SubrB6Sn2y071uNFVfPrr6wOVbXXX/R8L5+6gs0bfezDM5lExQGwrBSxGsW iJh4ZOTxYZZU+6mkzDaT3AF87G0Se4K5GZYnJnxCNbyDAjcXFvSHoQaojkQzVKzYMIiG 13Ww3WvuVFml6C4r5/hEtylBfcenRr1uf82EItVKMCsj9BTjzqjFRbLANEFT99MOgoUO xY8w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc:content-type; bh=NQ7dBDwbGQ30RI1vUzm9Mn4SQreX4CyYl0hlcH2Wlzo=; b=BOY9cHqQrBCbpR63zxVeQw+bxP5r31SuD4A2drIBUEH2LXbjdID0gL7/mj5wqOhnDV 3zbAHXFtwGEMuHfLqfHhw9zsrZGPBCxLK49ewK70BiWBZZpllz7lR/tT1k7otpZ+ILzY jMsafxgMzlccm9/pjAZoYFxA/aY6Ct7ysK3Acyiblq68TwULbZJIiBWQ+5Wlp0jftElP LfTeUSOMIVw9G6dEIs6aGbAO/vW0yL6ZOXjluRQLp9TT/Alf52OmERulmK02KzSj/MRg iWuB9nJZ53uG4or8jbRpkd8zWRCXnYyXrDzBcSu+M8eLEHyNRJk/IEdWi91kA0uImmy+ mGhQ== X-Gm-Message-State: AG10YORPd+/Yf17/xS8Ipvs1PIzC6GlHWEWyH2l5b1pZb0r7MYoe8/n0lqgIYHFWnLfCgUNMoUnNUAwnpa+ct0af X-Received: by 10.13.231.132 with SMTP id q126mr2084345ywe.203.1453695895997; Sun, 24 Jan 2016 20:24:55 -0800 (PST) MIME-Version: 1.0 References: <56A4D946.5040604@si6networks.com> <56A4FE06.2090705@joelhalpern.com> <20160124.213316.74735914.sthaug@nethelp.no> In-Reply-To: <20160124.213316.74735914.sthaug@nethelp.no> From: Warren Kumari Date: Mon, 25 Jan 2016 04:24:46 +0000 Message-ID: Subject: Re: 2001:db8 To: sthaug@nethelp.no, jmh@joelhalpern.com Content-Type: multipart/alternative; boundary=94eb2c088c1e7e444f052a20f328 Archived-At: Cc: fgont@si6networks.com, ipv6@ietf.org, draft-ietf-6man-rfc4291bis@ietf.org, mcr+ietf@sandelman.ca X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 25 Jan 2016 04:24:58 -0000 --94eb2c088c1e7e444f052a20f328 Content-Type: text/plain; charset=UTF-8 So, I may have missed it, but was it said *which* platform it was that didn't allow this? W On Sun, Jan 24, 2016, 12:33 PM wrote: > > So the IETF took a decision to reserve a block of addresses for use in > > documentation that would never appear on the wire, anywhere. It was the > > only way we could find to resolve this problem. And it seems to have > > significantly improved the situation. > > This decision *may* have improved the situation - however, "would never > appear on the wire, anywhere" is simply not the case. > > The following boxes will happy route prefixes under 2001:db8::/32, as > verified in the lab just now (pingable, appears in routing protocols): > > Juniper MX104 JunOS 14.1R6.4 > Cisco ASR1001 IOS XE 15.4(3)S4 > Huawei NE5000 VRP 8.90 > Huawei NE40E-M2F VRP 8.100 > > > Yes, it is a rule we made. Yes, we could change it. But before asking > > that it be changed, please look at the potential risk, and include those > > observed risks in any discussion of changing the rules. > > I would be happy with a router which kept 2001:db8::/32 off the wire > by default, but which also let me explicitly *turn off* the default > behavior. > > A router which completely prevented me from using 2001:db8::/32 would > make me rather unhappy, and I would probably vote with my wallet. > > Steinar Haug, AS2116 > > -------------------------------------------------------------------- > IETF IPv6 working group mailing list > ipv6@ietf.org > Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 > -------------------------------------------------------------------- > --94eb2c088c1e7e444f052a20f328 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

So, I may have missed it, but was it said *which* platform i= t was that didn't allow this?

W


On Sun, Jan 24, 2016, 12:33= PM=C2=A0 <sthaug@nethelp.no>= ; wrote:
> So the IETF took a de= cision to reserve a block of addresses for use in
> documentation that would never appear on the wire, anywhere.=C2=A0 It = was the
> only way we could find to resolve this problem.=C2=A0 And it seems to = have
> significantly improved the situation.

This decision *may* have improved the situation - however, "would neve= r
appear on the wire, anywhere" is simply not the case.

The following boxes will happy route prefixes under 2001:db8::/32, as
verified in the lab just now (pingable, appears in routing protocols):

Juniper MX104=C2=A0 =C2=A0 JunOS 14.1R6.4
Cisco ASR1001=C2=A0 =C2=A0 IOS XE 15.4(3)S4
Huawei NE5000=C2=A0 =C2=A0 VRP 8.90
Huawei NE40E-M2F VRP 8.100

> Yes, it is a rule we made.=C2=A0 Yes, we could change it.=C2=A0 But be= fore asking
> that it be changed, please look at the potential risk, and include tho= se
> observed risks in any discussion of changing the rules.

I would be happy with a router which kept 2001:db8::/32 off the wire
by default, but which also let me explicitly *turn off* the default
behavior.

A router which completely prevented me from using 2001:db8::/32 would
make me rather unhappy, and I would probably vote with my wallet.

Steinar Haug, AS2116

--------------------------------------------------------------------
IETF IPv6 working group mailing list
ipv6@ietf.org
Administrative Requests: https://www.ietf.org/mailman/list= info/ipv6
--------------------------------------------------------------------
--94eb2c088c1e7e444f052a20f328-- From nobody Mon Jan 25 00:20:18 2016 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9F7EE1A1BD2; Mon, 25 Jan 2016 00:20:09 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.309 X-Spam-Level: X-Spam-Status: No, score=-0.309 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DATE_IN_PAST_03_06=1.592, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jxk6ctdHKnU9; Mon, 25 Jan 2016 00:20:08 -0800 (PST) Received: from fgont.go6lab.si (fgont.go6lab.si [IPv6:2001:67c:27e4::14]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E08BF1A0370; Mon, 25 Jan 2016 00:20:07 -0800 (PST) Received: from [192.168.2.101] (unknown [181.165.125.191]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by fgont.go6lab.si (Postfix) with ESMTPSA id 40A782069BB; Mon, 25 Jan 2016 09:20:01 +0100 (CET) Subject: Re: 2001:db8 To: Warren Kumari , sthaug@nethelp.no, jmh@joelhalpern.com References: <56A4D946.5040604@si6networks.com> <56A4FE06.2090705@joelhalpern.com> <20160124.213316.74735914.sthaug@nethelp.no> From: Fernando Gont Message-ID: <56A5A782.5070809@si6networks.com> Date: Mon, 25 Jan 2016 01:41:38 -0300 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.5.1 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Archived-At: Cc: draft-ietf-6man-rfc4291bis@ietf.org, ipv6@ietf.org, mcr+ietf@sandelman.ca X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 25 Jan 2016 08:20:09 -0000 On 01/25/2016 01:24 AM, Warren Kumari wrote: > So, I may have missed it, but was it said *which* platform it was that > didn't allow this? I seem to recall it was FreeBSD. I could re-check if there's interest... Thanks, -- Fernando Gont SI6 Networks e-mail: fgont@si6networks.com PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492 From nobody Mon Jan 25 00:20:23 2016 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0B3131A0370 for ; Mon, 25 Jan 2016 00:20:18 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id T4qsMLWzIdQR for ; Mon, 25 Jan 2016 00:20:13 -0800 (PST) Received: from fgont.go6lab.si (fgont.go6lab.si [91.239.96.14]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7868F1A1BBC for ; Mon, 25 Jan 2016 00:20:13 -0800 (PST) Received: from [192.168.2.101] (unknown [181.165.125.191]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by fgont.go6lab.si (Postfix) with ESMTPSA id 6BFF5206A16; Mon, 25 Jan 2016 09:20:08 +0100 (CET) Subject: Re: should the IPv6 "default" route really be ::/0? To: Michael Richardson , ipv6@ietf.org References: <13430.1453651443@obiwan.sandelman.ca> From: Fernando Gont X-Enigmail-Draft-Status: N1110 Message-ID: <56A5DB09.7060708@si6networks.com> Date: Mon, 25 Jan 2016 05:21:29 -0300 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.5.1 MIME-Version: 1.0 In-Reply-To: <13430.1453651443@obiwan.sandelman.ca> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit Archived-At: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 25 Jan 2016 08:20:18 -0000 On 01/24/2016 01:04 PM, Michael Richardson wrote: > > <#secure method=pgpmime mode=sign> > > I've been dog-fooding v6-over-IPsec for IPv6 access of late? > (i.e. instead of sixxs/he/aiccu/etc. on my laptop when at the legacy coffee > shop.) > > Naively, this involves building a tunnel from myip/128 -> ::/0. > A stupidity of the BSD/Linux WIDE/XFRM IPsec architecture is that it has an > additional firewall in the output path that encrypts the packets. > If there is *no route* for the destination, then the packets get no-route > error, never get to the output path and never get encrypted. > > Back in the day, I tried to convince Itojun that we should have a virtual > interface for IPsec tunnels, and that the IPsec policy (which is source > sensitive as well as destination sensitive) should live in the routing > table. It's too bad we didn't go that way because it would have given us > SADR much earlier, and would have made the need for application involvement > clearer long ago. Itojun asked me a simple question which I couldn't answer: > What is the scope of this virtual interface? Maybe it's too late at night, but... what do you mean by scope of the *interface*? > I made sure that the right route gets created; historically on Linux the > route was added out the same interface as the default pointed, towards the > same next-hop router, but in a mixed v4/v6 situation, there isn't a default > v6 route to "emulate", and I also asked my self the question: Not sure I follow... could you elaborate a bit? > Why am I building a route to ::/0? > > That's not the Internet. The Internet is at 2000::/3. > I see no reason why I should be routing traffic in the f000::/3 range, > which is all special use: multicast, link-local, ULA, etc. link-locals should have more specific routes. ULAs, at the end of the day are kinda globals... so the ::/0 is a catchall.. > Which lead me to ask: why does it mean when a RA says it a default route? > (Part of this email is prompted by the 2001:db8 discussion). > What prefixes should a host always have some other route for? > i.e. filter by longest prefix-match out. that you send it anything for which you don't have a more specific router. You'll always have that for link-locals and loopback... > Now, in my tunnel case, I'm using the IPsec tunnel to get IPv6, not exactly > for security. I'd like the tunnel to remain up, even if I have IPv6, because > it gives mobileIP-like connectivity, and if I had native IPv6, I might want > to use a binding update. If I had native IPv6, I'd have a ::/0 route, but > that's less specific than 2000::/3, so my native traffic goes the wrong way > if I don't put my 2000::/3 route on the correct interface. > > So I have to use ::/0 for my extrusion, just at a lower metric, so that the > two potentially two ::/0 can compete properly... And that is the reason why > I started thinking that maybe it was the system that was wrong to use a ::/0 > route for default. Note sure what you mean. Usually, if you want your secured tunnel to override yu default route, you include two routes: ::/1 and 8000::/1, so that that's more specific than ::/0. Some VPN clients do this sort of thing. -- that said, security-wise this is APITA and a risk, since a local node could always install more specific outes e.g. via ICMPv6 Redirects, RAs with more specific routes, etc. Please see RFC7359. Thanks, -- Fernando Gont SI6 Networks e-mail: fgont@si6networks.com PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492 From nobody Mon Jan 25 00:26:28 2016 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2EBE91B29D6; Mon, 25 Jan 2016 00:26:26 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rQsVIs5f8tr5; Mon, 25 Jan 2016 00:26:25 -0800 (PST) Received: from fgont.go6lab.si (fgont.go6lab.si [91.239.96.14]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id F0FDE1A0AF1; Mon, 25 Jan 2016 00:26:24 -0800 (PST) Received: from [192.168.2.101] (unknown [181.165.125.191]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by fgont.go6lab.si (Postfix) with ESMTPSA id A56D92069BB; Mon, 25 Jan 2016 09:26:20 +0100 (CET) Subject: Re: 2001:db8 [was Re: draft-ietf-6man-rfc4291bis] To: "Joel M. Halpern" , Mark Smith , Michael Richardson References: <56A27712.1060003@si6networks.com> <56A2A760.9050906@gmail.com> <28158.1453566884@obiwan.sandelman.ca> <56A4D946.5040604@si6networks.com> <56A4FE06.2090705@joelhalpern.com> From: Fernando Gont X-Enigmail-Draft-Status: N1110 Message-ID: <56A5DC75.60903@si6networks.com> Date: Mon, 25 Jan 2016 05:27:33 -0300 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.5.1 MIME-Version: 1.0 In-Reply-To: <56A4FE06.2090705@joelhalpern.com> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit Archived-At: Cc: 6man WG , draft-ietf-6man-rfc4291bis@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 25 Jan 2016 08:26:26 -0000 On 01/24/2016 01:38 PM, Joel M. Halpern wrote: > Documenting a Lab is quite different from documenting a protocol. > > We found, far too often, that IP addresses used in RFCs and similar > documents were being copied verbatim into networks that then leaked into > the operational world. This was not a guess. This was an observed > property. > > So the IETF took a decision to reserve a block of addresses for use in > documentation that would never appear on the wire, anywhere. It was the > only way we could find to resolve this problem. And it seems to have > significantly improved the situation. > > Yes, it is a rule we made. Yes, we could change it. My understanding is that, in many platforms, 2001:db8::/16 is no different from ULAs in this respect: just another bogon to filter. However, the particular platform I was referring to had a hardcoded filter for this one. -- i.e., such filtering is not widespread. > But before asking > that it be changed, please look at the potential risk, and include those > observed risks in any discussion of changing the rules. I'm not asking for it to be changed (not so far, at least). I'm rather asking what's the prefix I'm supposed to use for e.g. delivering and documenting a lab. If that's something other than 2001:1db8::/16, I'm not sure why in this case this would not produce the "copy&paste" problem you're referring to -- whether folks c&p from RFCs or from some PDF someone is providing seems rather irrelevant. Thanks, -- Fernando Gont SI6 Networks e-mail: fgont@si6networks.com PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492 From nobody Mon Jan 25 00:36:28 2016 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3AE391B29FC for ; Mon, 25 Jan 2016 00:36:27 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.202 X-Spam-Level: X-Spam-Status: No, score=-4.202 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qA7WwjjP5rkz for ; Mon, 25 Jan 2016 00:36:25 -0800 (PST) Received: from bizet.nethelp.no (bizet.nethelp.no [195.1.209.33]) by ietfa.amsl.com (Postfix) with SMTP id EE3E71B29F6 for ; Mon, 25 Jan 2016 00:36:24 -0800 (PST) Received: (qmail 49828 invoked from network); 25 Jan 2016 08:36:23 -0000 Received: from bizet.nethelp.no (HELO localhost) (195.1.209.33) by bizet.nethelp.no with SMTP; 25 Jan 2016 08:36:23 -0000 Date: Mon, 25 Jan 2016 09:36:22 +0100 (CET) Message-Id: <20160125.093622.74711890.sthaug@nethelp.no> To: fgont@si6networks.com Subject: Re: 2001:db8 From: sthaug@nethelp.no In-Reply-To: <56A5A782.5070809@si6networks.com> References: <20160124.213316.74735914.sthaug@nethelp.no> <56A5A782.5070809@si6networks.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 Archived-At: Cc: ipv6@ietf.org, draft-ietf-6man-rfc4291bis@ietf.org, mcr+ietf@sandelman.ca X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 25 Jan 2016 08:36:27 -0000 > > So, I may have missed it, but was it said *which* platform it was that > > didn't allow this? > > I seem to recall it was FreeBSD. I could re-check if there's interest... Just tested FreeBSD 9.3 and 10.2: 2001:db8::/32 prefixes just work, with no apparent problems. Steinar Haug, AS2116 From nobody Mon Jan 25 00:45:22 2016 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CEB671A8754; Mon, 25 Jan 2016 00:45:21 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MJUea_i1cIrx; Mon, 25 Jan 2016 00:45:20 -0800 (PST) Received: from fgont.go6lab.si (fgont.go6lab.si [IPv6:2001:67c:27e4::14]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AF7C41A03A3; Mon, 25 Jan 2016 00:45:20 -0800 (PST) Received: from [192.168.2.101] (unknown [181.165.125.191]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by fgont.go6lab.si (Postfix) with ESMTPSA id 71980206A16; Mon, 25 Jan 2016 09:45:15 +0100 (CET) Subject: Re: 2001:db8 To: sthaug@nethelp.no References: <20160124.213316.74735914.sthaug@nethelp.no> <56A5A782.5070809@si6networks.com> <20160125.093622.74711890.sthaug@nethelp.no> From: Fernando Gont Message-ID: <56A5E0F6.2020807@si6networks.com> Date: Mon, 25 Jan 2016 05:46:46 -0300 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.5.1 MIME-Version: 1.0 In-Reply-To: <20160125.093622.74711890.sthaug@nethelp.no> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit Archived-At: Cc: ipv6@ietf.org, draft-ietf-6man-rfc4291bis@ietf.org, mcr+ietf@sandelman.ca X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 25 Jan 2016 08:45:22 -0000 On 01/25/2016 05:36 AM, sthaug@nethelp.no wrote: >>> So, I may have missed it, but was it said *which* platform it was that >>> didn't allow this? >> >> I seem to recall it was FreeBSD. I could re-check if there's interest... > > Just tested FreeBSD 9.3 and 10.2: 2001:db8::/32 prefixes just work, > with no apparent problems. Having a FreeBSD box acting as a router? -- I seem to recall that was the scenario in which I found issues (freebsd 8 or the like.. but should check). -- Fernando Gont SI6 Networks e-mail: fgont@si6networks.com PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492 From nobody Mon Jan 25 01:14:26 2016 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 059A81B2A3A for ; Mon, 25 Jan 2016 01:14:25 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.202 X-Spam-Level: X-Spam-Status: No, score=-4.202 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=unavailable Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pm0SUdpUyNqI for ; Mon, 25 Jan 2016 01:14:22 -0800 (PST) Received: from bizet.nethelp.no (bizet.nethelp.no [195.1.209.33]) by ietfa.amsl.com (Postfix) with SMTP id 14A391B2A3C for ; Mon, 25 Jan 2016 01:14:21 -0800 (PST) Received: (qmail 52149 invoked from network); 25 Jan 2016 09:14:20 -0000 Received: from bizet.nethelp.no (HELO localhost) (195.1.209.33) by bizet.nethelp.no with SMTP; 25 Jan 2016 09:14:20 -0000 Date: Mon, 25 Jan 2016 10:14:20 +0100 (CET) Message-Id: <20160125.101420.41673285.sthaug@nethelp.no> To: fgont@si6networks.com Subject: Re: 2001:db8 From: sthaug@nethelp.no In-Reply-To: <56A5E0F6.2020807@si6networks.com> References: <56A5A782.5070809@si6networks.com> <20160125.093622.74711890.sthaug@nethelp.no> <56A5E0F6.2020807@si6networks.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 Archived-At: Cc: ipv6@ietf.org, draft-ietf-6man-rfc4291bis@ietf.org, mcr+ietf@sandelman.ca X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 25 Jan 2016 09:14:25 -0000 > >>> So, I may have missed it, but was it said *which* platform it was that > >>> didn't allow this? > >> > >> I seem to recall it was FreeBSD. I could re-check if there's interest... > > > > Just tested FreeBSD 9.3 and 10.2: 2001:db8::/32 prefixes just work, > > with no apparent problems. > > Having a FreeBSD box acting as a router? -- I seem to recall that was > the scenario in which I found issues (freebsd 8 or the like.. but should > check). Yes I have that too :-) Works fine with FreeBSD 9.3 and 10.2, not checked FreeBSD 8. Steinar Haug, AS2116 From nobody Mon Jan 25 07:39:14 2016 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8FE541B2C3D for ; Mon, 25 Jan 2016 07:39:12 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.902 X-Spam-Level: X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id U3_Nvw49dHb5 for ; Mon, 25 Jan 2016 07:39:11 -0800 (PST) Received: from tuna.sandelman.ca (tuna.sandelman.ca [IPv6:2607:f0b0:f:3:216:3eff:fe7c:d1f3]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D7BA61B2C3C for ; Mon, 25 Jan 2016 07:39:10 -0800 (PST) Received: from sandelman.ca (obiwan.sandelman.ca [IPv6:2607:f0b0:f:2::247]) by tuna.sandelman.ca (Postfix) with ESMTP id 1D482200A3; Mon, 25 Jan 2016 10:47:30 -0500 (EST) Received: from obiwan.sandelman.ca (ip6-localhost [IPv6:::1]) by sandelman.ca (Postfix) with ESMTP id 5E60063751; Mon, 25 Jan 2016 10:39:09 -0500 (EST) From: Michael Richardson To: Fernando Gont Subject: Re: 2001:db8 [was Re: draft-ietf-6man-rfc4291bis] In-Reply-To: <56A5DC75.60903@si6networks.com> References: <56A27712.1060003@si6networks.com> <56A2A760.9050906@gmail.com> <28158.1453566884@obiwan.sandelman.ca> <56A4D946.5040604@si6networks.com> <56A4FE06.2090705@joelhalpern.com> <56A5DC75.60903@si6networks.com> X-Mailer: MH-E 8.6; nmh 1.6+dev; GNU Emacs 24.4.2 X-Face: $\n1pF)h^`}$H>Hk{L"x@)JS7<%Az}5RyS@k9X%29-lHB$Ti.V>2bi.~ehC0; <'$9xN5Ub# z!G,p`nR&p7Fz@^UXIn156S8.~^@MJ*mMsD7=QFeq%AL4m Archived-At: Cc: 6man WG X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 25 Jan 2016 15:39:12 -0000 --=-=-= Content-Type: text/plain Fernando Gont wrote: > I'm not asking for it to be changed (not so far, at least). I'm rather > asking what's the prefix I'm supposed to use for e.g. delivering and > documenting a lab. If that's something other than 2001:1db8::/16, I'm I would not be opposed to have a few additional prefixes allocated for lab use. In particular, I'd prefer it if the prefixes differed in the first digit or two, so I'd love to have, for instance: 2201:1db8::/16 2601:1db8::/16 2C01:1db8::/16 2F01:1db8::/16 3601:1db8::/16 3C01:1db8::/16 or something like that reserved for lab use... (Yes, and AS112'ed) -- Michael Richardson , Sandelman Software Works -= IPv6 IoT consulting =- --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.12 (GNU/Linux) iQEVAwUBVqZBmoCLcPvd0N1lAQJFhggAk82eKjnPx8BwT0Tmf3+2hr1FAXSWM9OS vBxtZcIoBNu3vYH9vfq+mV7p6PbitnoJHwbqsckn9ucV9G46KgrdocDNfm39w37P mnbi0iAv63VfLMeEZGCafsoxyLz8DR90XgYCNr94j+eOqGaLYHUAVl2JH0BWwLL8 CCqSYWgve1K0cDmqr/g9hc8FsITSrCynXGDTja7QBeXFTTEY/ERNKnO5eVnm6G1/ JJz7OnFksWSsdsoR/B6Dp65QfK7cZv1p+qEGu2ly9uRoYheKjgLiik7nsD6Idy0F xKyE9wHSdodF3KWyaTgE1x4ZaJIRnx78s4OmShbstkuECmJWuljedQ== =az1E -----END PGP SIGNATURE----- --=-=-=-- From nobody Mon Jan 25 07:42:55 2016 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0C59F1B2C55 for ; Mon, 25 Jan 2016 07:42:54 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.902 X-Spam-Level: X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NoPALXeZSm6W for ; Mon, 25 Jan 2016 07:42:53 -0800 (PST) Received: from tuna.sandelman.ca (tuna.sandelman.ca [209.87.249.19]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DA30A1B2C51 for ; Mon, 25 Jan 2016 07:42:52 -0800 (PST) Received: from sandelman.ca (obiwan.sandelman.ca [IPv6:2607:f0b0:f:2::247]) by tuna.sandelman.ca (Postfix) with ESMTP id ACBE4200A5; Mon, 25 Jan 2016 10:51:12 -0500 (EST) Received: from obiwan.sandelman.ca (ip6-localhost [IPv6:::1]) by sandelman.ca (Postfix) with ESMTP id 017D263751; Mon, 25 Jan 2016 10:42:52 -0500 (EST) From: Michael Richardson To: Brian E Carpenter Subject: Re: should the IPv6 "default" route really be ::/0? In-Reply-To: <56A529D4.3030707@gmail.com> References: <13430.1453651443@obiwan.sandelman.ca> <56A529D4.3030707@gmail.com> X-Mailer: MH-E 8.6; nmh 1.6+dev; GNU Emacs 24.4.2 X-Face: $\n1pF)h^`}$H>Hk{L"x@)JS7<%Az}5RyS@k9X%29-lHB$Ti.V>2bi.~ehC0; <'$9xN5Ub# z!G,p`nR&p7Fz@^UXIn156S8.~^@MJ*mMsD7=QFeq%AL4m Archived-At: Cc: ipv6@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 25 Jan 2016 15:42:54 -0000 --=-=-= Content-Type: text/plain Brian E Carpenter wrote: > Just getting at one sub-issue: > On 25/01/2016 05:04, Michael Richardson wrote: > ... >> That's not the Internet. The Internet is at 2000::/3. > Well, no, and that is the crux of the problem. That's only the part > of the Internet that IANA is currently handing out prefixes for. > 4000::/3 is part of the Internet too. I didn't know that we had moved into the second /3 block. The converse of what I'm asking might be: - should hosts have a default blackhole route for any other prefixes? -- Michael Richardson , Sandelman Software Works -= IPv6 IoT consulting =- --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.12 (GNU/Linux) iQEVAwUBVqZCeYCLcPvd0N1lAQK2xgf+OXRl3RlqaYmBZzhx8sOU4X76WLFpNDYQ 0tCiuI3qhzQaxS8ZehcYEReOVztLc8+0tRA6hyzxano+7lhZDMTGMfvJQpk3UF0r z0vPlIesPyt+4Ojvv2D1FyCD79tqB3MdBVaHkNzW+QZPJbb/FwbyoAAJ2QzcrI0N AeCVCP/k6Ap5ghcLt1GCpkSno9uk/IdgfU9e1u7fisolV6Z1YLVlJqA4j/JJk8/a o4Pd7mYYPykr0YezdLnj/zzpy3zft95R1XwWqQZCvMap3b00pdPfi3wsndG+PlXy EBAaYnp2yziUcjfVdj6qYr6ncbqaQL1sDXkhJzZqt+zr2V+DUERlUQ== =4PHh -----END PGP SIGNATURE----- --=-=-=-- From nobody Mon Jan 25 08:00:57 2016 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 586261B2C8D for ; Mon, 25 Jan 2016 08:00:55 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.902 X-Spam-Level: X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 03wPQ6LGN_BQ for ; Mon, 25 Jan 2016 08:00:51 -0800 (PST) Received: from tuna.sandelman.ca (tuna.sandelman.ca [IPv6:2607:f0b0:f:3:216:3eff:fe7c:d1f3]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9E9E41B2CA1 for ; Mon, 25 Jan 2016 08:00:41 -0800 (PST) Received: from sandelman.ca (obiwan.sandelman.ca [209.87.249.21]) by tuna.sandelman.ca (Postfix) with ESMTP id 9296C200A5; Mon, 25 Jan 2016 11:09:01 -0500 (EST) Received: from obiwan.sandelman.ca (ip6-localhost [IPv6:::1]) by sandelman.ca (Postfix) with ESMTP id D1D9663751; Mon, 25 Jan 2016 11:00:40 -0500 (EST) From: Michael Richardson To: Fernando Gont Subject: Re: should the IPv6 "default" route really be ::/0? In-Reply-To: <56A5DB09.7060708@si6networks.com> References: <13430.1453651443@obiwan.sandelman.ca> <56A5DB09.7060708@si6networks.com> X-Mailer: MH-E 8.6; nmh 1.6+dev; GNU Emacs 24.4.2 X-Face: $\n1pF)h^`}$H>Hk{L"x@)JS7<%Az}5RyS@k9X%29-lHB$Ti.V>2bi.~ehC0; <'$9xN5Ub# z!G,p`nR&p7Fz@^UXIn156S8.~^@MJ*mMsD7=QFeq%AL4m Archived-At: Cc: ipv6@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 25 Jan 2016 16:00:55 -0000 --=-=-= Content-Type: text/plain Fernando Gont wrote: >> Back in the day, I tried to convince Itojun that we should have a virtual >> interface for IPsec tunnels, and that the IPsec policy (which is source >> sensitive as well as destination sensitive) should live in the routing >> table. It's too bad we didn't go that way because it would have given us >> SADR much earlier, and would have made the need for application involvement >> clearer long ago. Itojun asked me a simple question which I couldn't answer: >> What is the scope of this virtual interface? > Maybe it's too late at night, but... what do you mean by scope of the > *interface*? I agree that I was a bit confused at the question too. If I build a virtual interface for use by an IPsec tunnel, what is the scope of this interface? for instance, what kinds of multicast should go out through this interface? >> I made sure that the right route gets created; historically on Linux the >> route was added out the same interface as the default pointed, towards the >> same next-hop router, but in a mixed v4/v6 situation, there isn't a default >> v6 route to "emulate", and I also asked my self the question: > Not sure I follow... could you elaborate a bit? In v4 land, if I had: 0.0.0.0/0 -> dev eth0 via 192.168.1.1 and I added a tunnel from 10.0.0.1/32 to 10.0.0.0/8, then I added a route like: 10.0.0.0/8 -> dev eth0 via 192.168.1.1 and a policy on eth0 that said: src:10.0.0.1/32 dst:10.0.0.0/8 -> ENCRYPT Note how the nexthop for the inside route came from the nexthop from the outside. If you follow the same logic with v6 inside, you wind up trying to do: route: dst:2001:db8::1/16 -> dev eth0 via 192.168.1.1 which is totally wrong. Fortunately on Linux, one can now omit the "via xxxx" part, and wind up with: dst:2001:db8::/16 -> dev eth0 which routes it to the interface, which along with the policy: src:2001:db8::1 dst: 2001:db8::/16 -> ENCRYPT via 192.0.2.1 does the trick, at the cost of having slightly locked you to the state of the eth0. It ought to work with "dev lo", but on Linux this seems to fail, so I have to route to "dummy0"... at which point I have a virtual interface again. >> Why am I building a route to ::/0? >> >> That's not the Internet. The Internet is at 2000::/3. >> I see no reason why I should be routing traffic in the f000::/3 range, >> which is all special use: multicast, link-local, ULA, etc. > link-locals should have more specific routes. ULAs, at the end of the > day are kinda globals... so the ::/0 is a catchall.. Yes, but link-locals are /64 routes, and we have no /10 route to blackhole the rest of them. I rather wonder if we should have a blackhole for ULA space, at the option of a router. Or rather, a router might list a prefix in an anti-PIO, to say, "and never route traffic to prefix X to me". I guess that's getting too much into a routing protocol... >> Now, in my tunnel case, I'm using the IPsec tunnel to get IPv6, not exactly >> for security. I'd like the tunnel to remain up, even if I have IPv6, because >> it gives mobileIP-like connectivity, and if I had native IPv6, I might want >> to use a binding update. If I had native IPv6, I'd have a ::/0 route, but >> that's less specific than 2000::/3, so my native traffic goes the wrong way >> if I don't put my 2000::/3 route on the correct interface. >> >> So I have to use ::/0 for my extrusion, just at a lower metric, so that the >> two potentially two ::/0 can compete properly... And that is the reason why >> I started thinking that maybe it was the system that was wrong to use a ::/0 >> route for default. > Note sure what you mean. Usually, if you want your secured tunnel to > override yu default route, you include two routes: ::/1 and 8000::/1, so > that that's more specific than ::/0. Some VPN clients do this sort of thing. Yes, FreeS/WAN first did this in 1998. It's a hack, and it was done because you couldn't change the default route without pulling the rug out from you. If you aren't using the tunnel for security, but rather, connectivity, then having it as a ::/0 route with a higher or lower metric makes more sense. -- Michael Richardson , Sandelman Software Works -= IPv6 IoT consulting =- --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.12 (GNU/Linux) iQEVAwUBVqZGpYCLcPvd0N1lAQKfmQgAp2AseBpyYDo4FManVZGd9BKYzYd20CUF aWzXKOKc589o0yhi7IBLHe75jS5hRUPxvoRjpF0oP0wk92RfUEkzLFao6dg5fQH3 93G5jC3ufswmCfzHs6XifjnmFzZXxp+4nUgqj9rWcNxI3uOWAD/R/iPIzh1HIGS9 fjiT7gNnNtuaFao+t8HJqiDmYGfZa3lP9SVTvw/OAzhOpJ7kOODd/1Y4svSX4+31 GaiMiwO7heC2hg/TIXuvcEdfuYQYDYQNRzkX7E1fwTwP8886EeIUTAfZeC2AcF96 UjhifXSunN3/vqYyiJwA+IKTL2JnB4V0pYPgWh+Bqyjd37TvQ97L5w== =Esj+ -----END PGP SIGNATURE----- --=-=-=-- From nobody Mon Jan 25 08:23:43 2016 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id ECE711B2CEB for ; Mon, 25 Jan 2016 08:23:40 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.3 X-Spam-Level: X-Spam-Status: No, score=-4.3 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, MIME_QP_LONG_LINE=0.001, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 50aG3s20oksz for ; Mon, 25 Jan 2016 08:23:39 -0800 (PST) Received: from vs-a.tc.umn.edu (vs-a.tc.umn.edu [134.84.119.220]) by ietfa.amsl.com (Postfix) with ESMTP id A0C861B2CE7 for ; Mon, 25 Jan 2016 08:23:39 -0800 (PST) Received: from mail-io0-f174.google.com (mail-io0-f174.google.com [209.85.223.174]) by vs-a.tc.umn.edu (UMN smtpd) with ESMTP (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128/128); for ; Mon, 25 Jan 2016 10:23:36 -0600 (CST) X-Umn-Remote-Mta: [N] mail-io0-f174.google.com [209.85.223.174] #+LO+TS+TR X-Umn-Classification: local Received: by mail-io0-f174.google.com with SMTP id q21so157057935iod.0 for ; Mon, 25 Jan 2016 08:23:36 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=umn.edu; s=google; h=references:in-reply-to:mime-version:content-transfer-encoding :content-type:message-id:cc:from:subject:date:to; bh=Ax5kwb/w50n5AmZHRD6fCnmSyluN2XEJIk20pL+Xcoo=; b=Q77B5J7rxCyQBlTn0QWDAhO86Z95uK0hTwLO6SbOnDL0doeKg2bbVbxbe6mfC35o8V KVJ5KMtz5ZvFff4HfKPJp3hbyBE2xAQDkK1fVzKJY0z8Tfuef6eErHzvmzB50PyPCxzE p7Cq6SYyt5N7PRLwqgvAr9mEOhMXOcXP9WzAc= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:references:in-reply-to:mime-version :content-transfer-encoding:content-type:message-id:cc:from:subject :date:to; bh=Ax5kwb/w50n5AmZHRD6fCnmSyluN2XEJIk20pL+Xcoo=; b=i7efScQUGWB7vaLHyhKjeb9hqQKibCHg/mEil1Q8EMUl5PiI8ZQlrdt6qUVzAYQbhA 4QJQ/WOBR3qmptVXCEa/d6uzeNKIepgBnWxDiFneGbaWWotO7PWKYg1H2rfWgXblkG2W TljMYf3TE9NisjGtcktCjaCOhJ5n20ujkHH3FiepdmXO7VNOdsvtTigP5BfJuxrCQ/UK q+e6DyXS9iJXLzS4GIatGVYaVwr8KkuIoGeykx02i16YbImOMDp+GUVRhaKnJjgMELJz HC8Nb1tKUWa2UGt9/IHi3IvwNhVUut8+eN/ylZ2Mvuewm8iMnuklIvqWjr5vOq2P273U f4qg== X-Gm-Message-State: AG10YOQf9kNTnZ/j7GFLXCAHXKP/pCrZe5ixj2t6RWFn53vmRrURoyGfD+UUZTlkEa3x2SyERWjHlG0ikFpMHpsUgf4YjbmdC7xNL5Q14YmvSRFbAUCgqsD70KHK6N1BH58= X-Received: by 10.107.40.76 with SMTP id o73mr16368659ioo.157.1453739015855; Mon, 25 Jan 2016 08:23:35 -0800 (PST) X-Received: by 10.107.40.76 with SMTP id o73mr16368638ioo.157.1453739015487; Mon, 25 Jan 2016 08:23:35 -0800 (PST) Received: from ?IPv6:2601:449:8400:9fc8:9838:54b2:69b0:c018? ([2601:449:8400:9fc8:9838:54b2:69b0:c018]) by smtp.gmail.com with ESMTPSA id ux7sm6450910igb.12.2016.01.25.08.23.33 (version=TLSv1/SSLv3 cipher=OTHER); Mon, 25 Jan 2016 08:23:33 -0800 (PST) References: <13430.1453651443@obiwan.sandelman.ca> <56A529D4.3030707@gmail.com> <29791.1453736571@obiwan.sandelman.ca> In-Reply-To: <29791.1453736571@obiwan.sandelman.ca> Mime-Version: 1.0 (1.0) Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Message-Id: X-Mailer: iPad Mail (13D15) From: David Farmer Subject: Re: should the IPv6 "default" route really be ::/0? Date: Mon, 25 Jan 2016 10:23:32 -0600 To: Michael Richardson Archived-At: Cc: ipv6@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 25 Jan 2016 16:23:41 -0000 > On Jan 25, 2016, at 09:42, Michael Richardson wrot= e: >=20 > Brian E Carpenter wrote: >> Just getting at one sub-issue: >=20 >>> On 25/01/2016 05:04, Michael Richardson wrote: >>> ... >>> That's not the Internet. The Internet is at 2000::/3. >=20 >> Well, no, and that is the crux of the problem. That's only the part >> of the Internet that IANA is currently handing out prefixes for. >> 4000::/3 is part of the Internet too. >=20 > I didn't know that we had moved into the second /3 block. >=20 > The converse of what I'm asking might be: > - should hosts have a default blackhole route for any other prefixes? NO!! =20 While not released for allocation 4000::/3 is explicitly intended for global= unicast allocation and nothing should be done that interferes with that. W= e do not want a situation where addresses become unusable in the future when= we need them, like IPv4 with 248.0.0.0/4. I think it could be reasonable to filter routing and traffic at administrati= ve boundaries for unallocated IPv6 blocks. However, doing something statica= lly on a host level is asking to make problems for the future. That said, i= f there was an automated way for a host to update its policy from a well-kno= wn source, like maybe Team-Cymru, something like that might be workable. Bu= t, if it's happening at administrative boundaries, is it really necessary to= do it at the host level too? =20 Personally, I think this should be done at administrative boundaries, not at= the host level, especially considering the difficulty and the many ways the= necessary automation could go wrong at a host level. But, YMMV! --=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=3D David Farmer Email: farmer@umn.edu Office of Information Technology University of Minnesota =20 2218 University Ave SE Phone: +1-612-626-0815 Minneapolis, MN 55414-3029 Cell: +1-612-812-9952 =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 From nobody Mon Jan 25 09:34:31 2016 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A14021B3799 for ; Mon, 25 Jan 2016 09:34:30 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.902 X-Spam-Level: X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uQPSfT4ZWjlv for ; Mon, 25 Jan 2016 09:34:29 -0800 (PST) Received: from tuna.sandelman.ca (tuna.sandelman.ca [IPv6:2607:f0b0:f:3:216:3eff:fe7c:d1f3]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2A3BF1B3794 for ; Mon, 25 Jan 2016 09:34:29 -0800 (PST) Received: from sandelman.ca (obiwan.sandelman.ca [IPv6:2607:f0b0:f:2::247]) by tuna.sandelman.ca (Postfix) with ESMTP id 110E4200A5; Mon, 25 Jan 2016 12:42:49 -0500 (EST) Received: from obiwan.sandelman.ca (ip6-localhost [IPv6:::1]) by sandelman.ca (Postfix) with ESMTP id 20F4F63751; Mon, 25 Jan 2016 12:34:28 -0500 (EST) From: Michael Richardson To: David Farmer Subject: Re: should the IPv6 "default" route really be ::/0? In-Reply-To: References: <13430.1453651443@obiwan.sandelman.ca> <56A529D4.3030707@gmail.com> <29791.1453736571@obiwan.sandelman.ca> X-Mailer: MH-E 8.6; nmh 1.6+dev; GNU Emacs 24.4.2 X-Face: $\n1pF)h^`}$H>Hk{L"x@)JS7<%Az}5RyS@k9X%29-lHB$Ti.V>2bi.~ehC0; <'$9xN5Ub# z!G,p`nR&p7Fz@^UXIn156S8.~^@MJ*mMsD7=QFeq%AL4m Archived-At: Cc: ipv6@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 25 Jan 2016 17:34:30 -0000 --=-=-= Content-Type: text/plain David Farmer wrote: >> The converse of what I'm asking might be: >> - should hosts have a default blackhole route for any other prefixes? > NO!! > While not released for allocation 4000::/3 is explicitly intended for > global unicast allocation and nothing should be done that interferes > with that. We do not want a situation where addresses become unusable > in the future when we need them, like IPv4 with 248.0.0.0/4. Well, I was thinking about f000:/3 and parts of 0::/3, not 4000::/3. So I definitely take your point. -- Michael Richardson , Sandelman Software Works -= IPv6 IoT consulting =- --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.12 (GNU/Linux) iQEVAwUBVqZcoYCLcPvd0N1lAQLIYgf/W7hWmEqLWM67tjkWdYjHAuUDOKy5weG+ y/wJ9HTZcdA1MzYVZHYgOPh5aXkV3IH2qAxyY13Hft/uaBKSMFDC5UPmIh/HejtO 77NgD+/jjq+7gmlSTguZb8ynLEwZiI/RY8P74dyweGRedfVL5qu7+UJBIu99uOZ1 lucTGc6pzJW5YTDMpwdEkFLqi5nm6tf3ITonRX6LZ6M6IZfmUn9zoF7fYOKmd84K 4tSqaZpFVtyKq+iaybrzgsqZylpWkDrUMiHZQUAPcLrzFb1Tvh1O8aW2R8dKApFe obEqefPG0SdKgWssJAp9PODNpV2IrDjS62CYc0tfhWRYOlYuqXG+rw== =ZugV -----END PGP SIGNATURE----- --=-=-=-- From nobody Mon Jan 25 09:51:55 2016 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 255811B37F0 for ; Mon, 25 Jan 2016 09:51:51 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZnZGpohYcYTI for ; Mon, 25 Jan 2016 09:51:49 -0800 (PST) Received: from uillean.fuaim.com (uillean.fuaim.com [206.197.161.140]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DBF581B37EB for ; Mon, 25 Jan 2016 09:51:49 -0800 (PST) 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 ACAD3880C7 for ; Mon, 25 Jan 2016 09:51:49 -0800 (PST) Received: from clemson.local (unknown [76.21.129.88]) (using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by clairseach.fuaim.com (Postfix) with ESMTP id 6863D328081B for ; Mon, 25 Jan 2016 09:51:49 -0800 (PST) Subject: Re: draft-ietf-6man-rfc4291bis To: ipv6@ietf.org References: <56A27EC5.1060204@gmail.com> <56A2A689.7020707@si6networks.com> From: Brian Haberman Message-ID: <56A660AF.6010703@innovationslab.net> Date: Mon, 25 Jan 2016 12:51:43 -0500 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:38.0) Gecko/20100101 Thunderbird/38.5.1 MIME-Version: 1.0 In-Reply-To: <56A2A689.7020707@si6networks.com> Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="Pwg3sm6bPoOuMvOM3ufG9EssiklOfNUQh" Archived-At: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 25 Jan 2016 17:51:51 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --Pwg3sm6bPoOuMvOM3ufG9EssiklOfNUQh Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable On 1/22/16 5:00 PM, Fernando Gont wrote: > On 01/22/2016 04:11 PM, Brian E Carpenter wrote: >> On 23/01/2016 02:17, Sander Steffann wrote: >>> Hi, >>> >>>>> | 10 | >>>>> | bits | 54 bits | 64 bits = | >>>>> +----------+-------------------------+--------------------------= --+ >>>>> |1111111010| 0 | interface ID = | >>>>> +----------+-------------------------+--------------------------= --+ >>>>> >>>>> The definition is wrong.The middle 54 bits can be any value.Please = fix it. >>>> >>>> How did you come to that conclusion? >>>> >>>> Some implementations might be tolerant of non-zero values in those 5= 4 bits, but that doesn't make the definition wrong. >>> >>> It has always been interesting that a /10 is reserved for link-local = while only a /64 is commonly used. The 54 bits in the middle could be any= thing,=20 >> >> No, the standard has always said that they *are* zero. We attempted to= clarify this >> in RFC 7421 - please see the bottom of this page: >> http://tools.ietf.org/html/rfc7421#page-11 >> >>> but they are always 0. FreeBSD even uses that assumption >> >> It's not an assumption; it's the standard. >=20 > Without looking back at the specs right now I seem to recall finding th= e > definition of ll addresses as fe80::/10 confusing in that respect. > The current behavior implies fe80::/64 rather than fe80::/10. FE80::/10 is defined as link-scoped unicast. FE80::/64 is defined as link-local address space. There is nothing in the specs that would preclude a new format in the link-scoped unicast address space. It just needs to be defined. Regards, Brian --Pwg3sm6bPoOuMvOM3ufG9EssiklOfNUQh 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 iQEcBAEBCAAGBQJWpmC0AAoJEBOZRqCi7goqfDMH/jEWwdhxSyRbxARTPA0BRO9c Mf++bA11kVrUlludPKcC/11DX7MQKzGjC36pz/6DEAq/bpwehEO9jRhZ95DPsuC7 lumCtKCWbMrwSc8wu+bPhBoBSZbJNfAxQxoTguq2hPAvcdy4p4wCh0RY6vnWKlWO HETnrIU32FZMPz+3MQJKgEmz1mvOUt1NDnvxhwMX27xlSonbfaqluhESCtLRLaUS 74SxdIl2Akpx2O4mc/jw8RA9UGs1ksTBFC2r4N0Evn85ygJ7fQu1CmaFubqDmQ5V Ixrzy9P9nRW16wijVaQnUCTkzJ6tZuFXla3xaLFw8QqkMKEjtEHre2azM87dbDc= =gmu0 -----END PGP SIGNATURE----- --Pwg3sm6bPoOuMvOM3ufG9EssiklOfNUQh-- From nobody Mon Jan 25 09:58:04 2016 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E2DC81B37FD for ; Mon, 25 Jan 2016 09:58:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kgRANe3MLnRR for ; Mon, 25 Jan 2016 09:58:02 -0800 (PST) Received: from uillean.fuaim.com (uillean.fuaim.com [206.197.161.140]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C13D81B37FC for ; Mon, 25 Jan 2016 09:58:02 -0800 (PST) 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 A1B31880C7 for ; Mon, 25 Jan 2016 09:58:02 -0800 (PST) Received: from clemson.local (unknown [76.21.129.88]) (using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by clairseach.fuaim.com (Postfix) with ESMTP id 5EC7E328081B for ; Mon, 25 Jan 2016 09:58:02 -0800 (PST) Subject: Re: should the IPv6 "default" route really be ::/0? To: ipv6@ietf.org References: <13430.1453651443@obiwan.sandelman.ca> <56A5DB09.7060708@si6networks.com> <1100.1453737640@obiwan.sandelman.ca> From: Brian Haberman Message-ID: <56A66228.9020306@innovationslab.net> Date: Mon, 25 Jan 2016 12:58:00 -0500 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:38.0) Gecko/20100101 Thunderbird/38.5.1 MIME-Version: 1.0 In-Reply-To: <1100.1453737640@obiwan.sandelman.ca> Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="J8O9efmDW2rIHxHq3C7kqCL4TligGPLMO" Archived-At: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 25 Jan 2016 17:58:04 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --J8O9efmDW2rIHxHq3C7kqCL4TligGPLMO Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Hi Michael, On 1/25/16 11:00 AM, Michael Richardson wrote: >=20 > Fernando Gont wrote: > >> Back in the day, I tried to convince Itojun that we should have = a virtual > >> interface for IPsec tunnels, and that the IPsec policy (which is= source > >> sensitive as well as destination sensitive) should live in the r= outing > >> table. It's too bad we didn't go that way because it would have= given us > >> SADR much earlier, and would have made the need for application = involvement > >> clearer long ago. Itojun asked me a simple question which I cou= ldn't answer: > >> What is the scope of this virtual interface? >=20 > > Maybe it's too late at night, but... what do you mean by scope of= the > > *interface*? >=20 > I agree that I was a bit confused at the question too. >=20 > If I build a virtual interface for use by an IPsec tunnel, what is the = scope > of this interface? for instance, what kinds of multicast should go out = through this > interface? Not all interfaces have explicit scopes and that is discussed in RFC 4007= =2E Regards, Brian --J8O9efmDW2rIHxHq3C7kqCL4TligGPLMO 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 iQEcBAEBCAAGBQJWpmIpAAoJEBOZRqCi7goqQKIIAL6WGO8ibvwJar4ieo3uzo4r lAg9edqFJimMlteP8QyDBK48JFn4mUCCPDnEt7TSrJgS4AsKTd9qk7gHqLclyJdG Imk9cU9MWwp+fAgLilV+OCBiOh7P9YIep/tQycIyU+TcwaNYaQd6kwGgQZiD/s+W jlQF4xn0de+kebaL6Sn21ovDSHV9vRpyxmOMKPQFtulwAjN/yHQzZV0O7t19TUJJ eYW8z8rTshGO2lt86Cp/BC0A8VhQgVK6K+drjaAg9l2z/9SUhf/F6HUCNp+icBYs szO/zSy2jrVabqA5KDEnRnGyb+oZ9Uw6MvP4eAmo8+idcuADv0lI5uqBdczo4cg= =QPGR -----END PGP SIGNATURE----- --J8O9efmDW2rIHxHq3C7kqCL4TligGPLMO-- From nobody Mon Jan 25 10:40:05 2016 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2161A1B38E7 for ; Mon, 25 Jan 2016 10:40:02 -0800 (PST) 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=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lVrQo-lqHt8x for ; Mon, 25 Jan 2016 10:39:58 -0800 (PST) Received: from mail-pf0-x234.google.com (mail-pf0-x234.google.com [IPv6:2607:f8b0:400e:c00::234]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0F9D81B38D3 for ; Mon, 25 Jan 2016 10:39:58 -0800 (PST) Received: by mail-pf0-x234.google.com with SMTP id e65so86286379pfe.0 for ; Mon, 25 Jan 2016 10:39:58 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=subject:to:references:cc:from:organization:message-id:date :user-agent:mime-version:in-reply-to:content-type :content-transfer-encoding; bh=DjSX01LXgdSqT8qIDVsfbsNA2Vx8X32YfuxohEQJvXk=; b=dDIFbOHRaXl2yNKSIRRtV/Xe8i8elLBjHs3Mg612Ca3410NT7L3ErIPXINhelrjJLE /BrN3M3YfS/usfZ0J3EJmGMeobL6xiFTryl3ntRWZ2I9tpMwdDzuLDeQG1Z8GH8gBPWJ 1X4AOkfmsJcBqbg3A7SWLOvlxr0TgiyFoEu+Wxnf5hC/ijfh2VmID8RXaEMEOpW4k56B B87mNpAciER+j33n4lCGmpxp5aAUoghzjOsYftQjwzjJu8VCrcneA+Yjysmf1MmN28ww dkbMqHugzzHRuy5QPMVAEJdpEk8kQ4UggovkO8SpWtsxlcnIXS8cVYRnV+J1xUD3mgI1 F/9Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:subject:to:references:cc:from:organization :message-id:date:user-agent:mime-version:in-reply-to:content-type :content-transfer-encoding; bh=DjSX01LXgdSqT8qIDVsfbsNA2Vx8X32YfuxohEQJvXk=; b=aH5Jrmh/+CFGvyNf9No4YG3ErU19IE7jAqXYUw9AbBIHrSOceAPFR1FoXxrVaZxI21 cOjT+qrIXBXX5wtA0iJv2gQOqaX0FN5GpjidjaknEgjJTT/gZeMqZAZwflDSjLH0917W h/BPJrPxFpVmF/mYcmTj6xdzEXefecECH1Z7rlDGO+0Yyv35gcCWypnglJg0Ws+4Znyf kQfbqAP3hJZoB2a5c3wDLUTQ9omzgHCCsjxAqPNeMw8NNOC50paBwbOEdmRkIrteqy1/ 439/yTiCyIgOjbfkQoA0qSkU1DukdpVONal7DDyoaoe+1ZoVp2eu5U2z6TwhkgMRxSu7 IkEA== X-Gm-Message-State: AG10YOQ/WnQyic5uzk3JD8L0NS5g3zEKt61jgYpRIzYPZSrpaFgmIpRvcnp0BBKgSF1Mzw== X-Received: by 10.98.68.78 with SMTP id r75mr28290749pfa.136.1453747197756; Mon, 25 Jan 2016 10:39:57 -0800 (PST) Received: from ?IPv6:2406:e007:6dd1:1:28cc:dc4c:9703:6781? ([2406:e007:6dd1:1:28cc:dc4c:9703:6781]) by smtp.gmail.com with ESMTPSA id v7sm30230884pfa.77.2016.01.25.10.39.54 (version=TLSv1/SSLv3 cipher=OTHER); Mon, 25 Jan 2016 10:39:56 -0800 (PST) Subject: Re: should the IPv6 "default" route really be ::/0? To: Michael Richardson , David Farmer References: <13430.1453651443@obiwan.sandelman.ca> <56A529D4.3030707@gmail.com> <29791.1453736571@obiwan.sandelman.ca> <22116.1453743268@obiwan.sandelman.ca> From: Brian E Carpenter Organization: University of Auckland Message-ID: <56A66BFD.607@gmail.com> Date: Tue, 26 Jan 2016 07:39:57 +1300 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.5.1 MIME-Version: 1.0 In-Reply-To: <22116.1453743268@obiwan.sandelman.ca> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Archived-At: Cc: ipv6@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 25 Jan 2016 18:40:02 -0000 On 26/01/2016 06:34, Michael Richardson wrote: > > David Farmer wrote: > >> The converse of what I'm asking might be: > >> - should hosts have a default blackhole route for any other prefixes? > > > NO!! > > > While not released for allocation 4000::/3 is explicitly intended for > > global unicast allocation and nothing should be done that interferes > > with that. We do not want a situation where addresses become unusable > > in the future when we need them, like IPv4 with 248.0.0.0/4. > > Well, I was thinking about f000:/3 and parts of 0::/3, not 4000::/3. > So I definitely take your point. And that was my point too - the Internet (including the future Internet) is ::/0 with holes in it. Given the tools we have, ::/0 seems to be the best approximation. Brian From nobody Mon Jan 25 10:57:26 2016 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0F79E1B391A for ; Mon, 25 Jan 2016 10:57:26 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.902 X-Spam-Level: X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4QioAjE0YKto for ; Mon, 25 Jan 2016 10:57:24 -0800 (PST) Received: from tuna.sandelman.ca (tuna.sandelman.ca [IPv6:2607:f0b0:f:3:216:3eff:fe7c:d1f3]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 437371B3918 for ; Mon, 25 Jan 2016 10:57:24 -0800 (PST) Received: from sandelman.ca (obiwan.sandelman.ca [IPv6:2607:f0b0:f:2::247]) by tuna.sandelman.ca (Postfix) with ESMTP id 5CE22200A5; Mon, 25 Jan 2016 14:05:44 -0500 (EST) Received: from obiwan.sandelman.ca (ip6-localhost [IPv6:::1]) by sandelman.ca (Postfix) with ESMTP id 2F6B563751; Mon, 25 Jan 2016 13:57:23 -0500 (EST) From: Michael Richardson To: Brian Haberman Subject: Re: should the IPv6 "default" route really be ::/0? In-Reply-To: <56A66228.9020306@innovationslab.net> References: <13430.1453651443@obiwan.sandelman.ca> <56A5DB09.7060708@si6networks.com> <1100.1453737640@obiwan.sandelman.ca> <56A66228.9020306@innovationslab.net> X-Mailer: MH-E 8.6; nmh 1.6+dev; GNU Emacs 24.4.2 X-Face: $\n1pF)h^`}$H>Hk{L"x@)JS7<%Az}5RyS@k9X%29-lHB$Ti.V>2bi.~ehC0; <'$9xN5Ub# z!G,p`nR&p7Fz@^UXIn156S8.~^@MJ*mMsD7=QFeq%AL4m Archived-At: Cc: ipv6@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 25 Jan 2016 18:57:26 -0000 --=-=-= Content-Type: text/plain Brian Haberman wrote: >> If I build a virtual interface for use by an IPsec tunnel, what is the scope >> of this interface? for instance, what kinds of multicast should go out through this >> interface? > Not all interfaces have explicit scopes and that is discussed in RFC > 4007. I think that 4007 is after the conversation with Itojun, by perhaps 10 years. I guess you refer to section 5, last paragraph (wish we had anchors to link directly..) and I guess the question of virtual interfaces and IPsec could be examined again. (There is a lot of "but that's not how XYZ did it" in the Linux and BSD stacks, often forming a loop of arrows.) -- Michael Richardson , Sandelman Software Works -= IPv6 IoT consulting =- --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.12 (GNU/Linux) iQEVAwUBVqZwEICLcPvd0N1lAQL+OwgAgA004ntzR4cvKhWw8uVqs1ifagcL7Nt+ Dw5Sef7LmnjDnXAXLUDJVUel2uon+gsBLoZt6PUJVdvNeGtiVr+n6gKPdwjeN3xF 59o4SJilKXGkcpv9wbVwfXX2gut93vy/tUjSy4XWzq0K2n8UZZAnOTQiSIz+i0Ye XCzxoWTxhQu/SgNSOGBO5yYzUi5NRVl0C62SNv3ymR/5nGhUq1WPbEqYQTnRmy6b 5V0kYoWVipDqDLsQ5/NT5IrxKwoTy8/aCRInbfsQKg5si2STtK255yGhIku1xqPe WWRrue77naOF9MRzL0PaTMK7VojdpK3sEc3xAQMI4TBF7hTC6wJ2Ig== =zveo -----END PGP SIGNATURE----- --=-=-=-- From nobody Mon Jan 25 11:27:31 2016 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9CC391B3891 for ; Mon, 25 Jan 2016 11:27:29 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Focd5ksbne6a for ; Mon, 25 Jan 2016 11:27:28 -0800 (PST) Received: from uillean.fuaim.com (uillean.fuaim.com [206.197.161.140]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 56BA11ACD3F for ; Mon, 25 Jan 2016 11:27:28 -0800 (PST) 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 1A7E3880C7 for ; Mon, 25 Jan 2016 11:27:28 -0800 (PST) Received: from clemson.local (unknown [76.21.129.88]) (using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by clairseach.fuaim.com (Postfix) with ESMTP id C49CD328081B for ; Mon, 25 Jan 2016 11:27:27 -0800 (PST) Subject: Re: should the IPv6 "default" route really be ::/0? To: ipv6@ietf.org References: <13430.1453651443@obiwan.sandelman.ca> <56A5DB09.7060708@si6networks.com> <1100.1453737640@obiwan.sandelman.ca> <56A66228.9020306@innovationslab.net> <8005.1453748243@obiwan.sandelman.ca> From: Brian Haberman Message-ID: <56A67719.9000908@innovationslab.net> Date: Mon, 25 Jan 2016 14:27:21 -0500 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:38.0) Gecko/20100101 Thunderbird/38.5.1 MIME-Version: 1.0 In-Reply-To: <8005.1453748243@obiwan.sandelman.ca> Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="8FcvsqjwvSlgqitHxJPjLSBQigqT2pQo1" Archived-At: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 25 Jan 2016 19:27:29 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --8FcvsqjwvSlgqitHxJPjLSBQigqT2pQo1 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable On 1/25/16 1:57 PM, Michael Richardson wrote: >=20 > Brian Haberman wrote: > >> If I build a virtual interface for use by an IPsec tunnel, what = is the scope > >> of this interface? for instance, what kinds of multicast should = go out through this > >> interface? >=20 > > Not all interfaces have explicit scopes and that is discussed in = RFC > > 4007. >=20 > I think that 4007 is after the conversation with Itojun, by perhaps 10 = years. >=20 > I guess you refer to section 5, last paragraph (wish we had anchors to = link > directly..) and I guess the question of virtual interfaces and IPsec co= uld be > examined again. My point is that there has been thought put into the scope of interfaces and that is captured in 4007. At this point, I am not sure we should be trying to figure out what Itojun meant given that we have 4007 as a tool.= >=20 > (There is a lot of "but that's not how XYZ did it" in the Linux and BSD= > stacks, often forming a loop of arrows.) >=20 There are times where I wish the IETF had a way to give code developers a rap on the knuckles [1]. The IETF cannot, but individual contributors can push on those entities to do the right thing. Regards, Brian [1] http://dictionary.cambridge.org/us/dictionary/english/a-rap-on-over-the-k= nuckles >=20 > -- > Michael Richardson , Sandelman Software Works > -=3D IPv6 IoT consulting =3D- >=20 >=20 >=20 >=20 >=20 > -------------------------------------------------------------------- > IETF IPv6 working group mailing list > ipv6@ietf.org > Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 > -------------------------------------------------------------------- >=20 --8FcvsqjwvSlgqitHxJPjLSBQigqT2pQo1 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 iQEcBAEBCAAGBQJWpnceAAoJEBOZRqCi7goq6W0H/0iv7/rNl+GJxBFBStQkQXP6 xnkUKSp2GlJQGsQHFwQGzwvYd77WlCdkvG+WUOC/Qn1j4KckGY8GR4eTLtxNrDTO FdlQr7rGa4rWN/f5+eflAVbKZBdOB+4MZdi1MN5pPZQYfp6uCKjArt9dEBarx3XM 1+hU4aG26vlzZSIcafENYm+EOQXU0t9WjKpIP6MOyQ+BX4HPMbgqqb9PbMa+f5kc R4psGlvePu452IMW82JNi+fHEyN/k0Ls2+Iz3WC3lTXR+2NURO8p+N/hlJR2ieTD Hs9hM7cSjEVsIeL4AMdb+zhi/cGPqFASgw9nqGEueDMdiwAeqknQmh0keJ2tMos= =cpo6 -----END PGP SIGNATURE----- --8FcvsqjwvSlgqitHxJPjLSBQigqT2pQo1-- From nobody Mon Jan 25 13:06:47 2016 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 109A31A0264 for ; Mon, 25 Jan 2016 13:06:47 -0800 (PST) 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=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Bj63LsWhjYzf for ; Mon, 25 Jan 2016 13:06:45 -0800 (PST) Received: from mail-qk0-x22d.google.com (mail-qk0-x22d.google.com [IPv6:2607:f8b0:400d:c09::22d]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 776501A0262 for ; Mon, 25 Jan 2016 13:06:45 -0800 (PST) Received: by mail-qk0-x22d.google.com with SMTP id x1so59696374qkc.1 for ; Mon, 25 Jan 2016 13:06:45 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=subject:mime-version:content-type:from:in-reply-to:date:cc :message-id:references:to; bh=9yvv/c5F0edzpmVm9SvrriD7dZNbIYsA108JGREC4zE=; b=augRceG2P+LQ4gOiD5M3A2fkwJUohlbDGISd0nmYHr03vvI0/VapTZzCtgcPO0YT8d K/OeQC0NOOQIQaQdgpp702g6qaslcPxiwIhsZ+xgE72yYVqYw38js0SmL3ZrdKiZX900 Esi4OXaYY6sCLwFjwo9G3DaWkqQQF/aPOkyNItkzRFGPy0RXqznf4jdzMu7ycDI6GNis Z1l9/rYHOQSk7YlM5YILMAMn5U3BudTk9NV6+4l16MBhD1pq1ptavxRpcoOV9qRXsdZL 4n/Uc/A9oj1yoOFCbzoBVaKatiNs4c4dafNZulAlwuCbchfF4NVb5LMTn5rpZk57P08+ c4uw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:subject:mime-version:content-type:from :in-reply-to:date:cc:message-id:references:to; bh=9yvv/c5F0edzpmVm9SvrriD7dZNbIYsA108JGREC4zE=; b=MRDo9CGxk/7CKy0BtzIxTjA2TDzyRMhGMsLgh6ihL3xTXhlG4bGrSSZzZpogOWt1dr AWQ+sVoE5J2+kVO9C/nx2cMugw+CCfNMdH18saoFM61orHeWEaZJhT7QjGJupn8KcmSz O1M72XNX1xE9v8CSi/ZRQZm9aZWjyICppIhbh0CaFjJjXyHZqATC+mMI+hE3gF5Dp5Xw lf+39O/DMpQb7S1cvzRH04dx2YwgCXT4zWeChOSzVMQks8/vyz7uivfV4wZZSmQxk4Q5 PFMb8+I3JgacoTZLvpa3WPL0NCMyqJmKLBHkE6pRE/6u/f9JHNfCW9GQTrv/CA7cJ3Ec tZuw== X-Gm-Message-State: AG10YOQua8TJmLpNwbdKhfMf0U50vFjamrmjL6/39Z+iWWTCEj9pGREcz2ypDhlorEaMtg== X-Received: by 10.55.77.206 with SMTP id a197mr23541165qkb.43.1453756004663; Mon, 25 Jan 2016 13:06:44 -0800 (PST) Received: from [172.16.224.219] ([209.97.127.34]) by smtp.gmail.com with ESMTPSA id c190sm9485531qkb.27.2016.01.25.13.06.42 (version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Mon, 25 Jan 2016 13:06:42 -0800 (PST) Subject: Re: should the IPv6 "default" route really be ::/0? Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2104\)) Content-Type: multipart/signed; boundary="Apple-Mail=_15F75468-F3C9-4AEF-9BC5-203D35CB7AE7"; protocol="application/pgp-signature"; micalg=pgp-sha512 X-Pgp-Agent: GPGMail 2.5.2 From: Bob Hinden In-Reply-To: <29791.1453736571@obiwan.sandelman.ca> Date: Mon, 25 Jan 2016 13:06:40 -0800 Message-Id: <65F677A5-7A48-424D-A62B-46B43DECB405@gmail.com> References: <13430.1453651443@obiwan.sandelman.ca> <56A529D4.3030707@gmail.com> <29791.1453736571@obiwan.sandelman.ca> To: Michael Richardson X-Mailer: Apple Mail (2.2104) Archived-At: Cc: IPv6 List , Bob Hinden X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 25 Jan 2016 21:06:47 -0000 --Apple-Mail=_15F75468-F3C9-4AEF-9BC5-203D35CB7AE7 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Michael, > On Jan 25, 2016, at 7:42 AM, Michael Richardson = wrote: >=20 >=20 > Brian E Carpenter wrote: >> Just getting at one sub-issue: >=20 >> On 25/01/2016 05:04, Michael Richardson wrote: >> ... >>> That's not the Internet. The Internet is at 2000::/3. >=20 >> Well, no, and that is the crux of the problem. That's only the part >> of the Internet that IANA is currently handing out prefixes for. >> 4000::/3 is part of the Internet too. >=20 > I didn't know that we had moved into the second /3 block. We have not started allocating prefixes out of 4000::/3. See: = https://www.iana.org/assignments/ipv6-address-space/ipv6-address-space.xml= Bob >=20 > The converse of what I'm asking might be: > - should hosts have a default blackhole route for any other = prefixes? >=20 > -- > Michael Richardson , Sandelman Software Works > -=3D IPv6 IoT consulting =3D- >=20 >=20 >=20 > -------------------------------------------------------------------- > IETF IPv6 working group mailing list > ipv6@ietf.org > Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 > -------------------------------------------------------------------- --Apple-Mail=_15F75468-F3C9-4AEF-9BC5-203D35CB7AE7 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 - https://gpgtools.org iQEcBAEBCgAGBQJWpo5hAAoJEK7rdBF357uou5kH/2XLtapmF8BYP1JA9wrujOoq 76cXbnJEk7sRqtv2kuxEUorAetgj4h65WGVXqPhK5JslKtjx6xOd9x7IyPU8bZ7r LZaV87yTuCom32mdobt+6/ZQDpip4HNEPFVo0wgjig+5EA1vViZYQGFAl6rADVL6 RL642R6N//UwwBULjgf6VcKXWPb8GvY/0LN7mppTAPYS0c2/DKXx2fAHiaa7dX+E XF35gzEDxYeFM/uTUAtydvn50oIy/NdiY7kLgJJ9MA0r4z9LIzbf/Stg/mmwyJY/ sl4qtbvIHxGLC0vm/Byh6ZRbgRk4eHtPmkjI5fHEEPBoHkcjAHYY15lg5EB++0A= =NIx3 -----END PGP SIGNATURE----- --Apple-Mail=_15F75468-F3C9-4AEF-9BC5-203D35CB7AE7-- From nobody Mon Jan 25 13:17:22 2016 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4E6C31A02BE for ; Mon, 25 Jan 2016 13:17:21 -0800 (PST) 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=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oFrWgM4GTrve for ; Mon, 25 Jan 2016 13:17:19 -0800 (PST) Received: from mail-pf0-x22b.google.com (mail-pf0-x22b.google.com [IPv6:2607:f8b0:400e:c00::22b]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 95D161A02B1 for ; Mon, 25 Jan 2016 13:17:19 -0800 (PST) Received: by mail-pf0-x22b.google.com with SMTP id 65so173911pfd.2 for ; Mon, 25 Jan 2016 13:17:19 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=subject:to:references:cc:from:organization:message-id:date :user-agent:mime-version:in-reply-to:content-type :content-transfer-encoding; bh=KDsYLu5wNeeH5lT/Ax8rNSRqYMycHTl4gBsn8/aLyGc=; b=mLeTWLfgZ+YoBesRMkG2tHzVROzD/i9zBMxjXV31+3gahQrxk886y27Vw8HDATJfcT EKXbZ7oizHb1GgHMNBKSURoFlmaHyhwih4SzvrCH0z+/DVI203P9UqiSRvdOT0CBdYgs Ucux1tqTNjnHb2cjRtwPpDe3svT/PQfK9QsuFnhRIiJy7fRGiSh/1M6eivR5psg2NmXa aYkEUNwhBkTi3GJUSROxtQdimU/As/rK6DurGUpWviggb0JTVwZtThI2R0bxkidxoER+ X3/4mpDA4OCElN+oe50VCeKFBdUppubesL1mLhJsO2h6DG4ymYAz0UZH0J+W8rO/ktvU daDg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:subject:to:references:cc:from:organization :message-id:date:user-agent:mime-version:in-reply-to:content-type :content-transfer-encoding; bh=KDsYLu5wNeeH5lT/Ax8rNSRqYMycHTl4gBsn8/aLyGc=; b=Sf2E5fa+AxymgVxK1nK+zz9VVCteJjyF+77H8gFIRZmKQjeS/XbK+KQLqSMcW2PwrQ skfL03fERF61HCYXwzZrlW3lpVRbfpJbLVsbTdBO8CO1WlPcqfnK4M1A6YjoeN3OsK7B ZgEb+dByhnpLJF7o7ajrf+nkVjVNXeC6ZZJzUJliU8bNq3C9gJcEdcKvf5SyhhpOUSZJ U31O22DrbiTH3p1uvP+AdOw4CCeI7wQY/vmciCcpkXmG7jWcdkz4XDnQW2JIU9e8qYpW zATccxp4cuhW/F3+2hE26RayFrN9NmC7QSQfHXjT40bwPlBO8VqaTCNmu0nAqM28CjBs 0aqA== X-Gm-Message-State: AG10YOQXorhZ2jMC2DjVbqwrP8SiMTMekIx1uod7OoquI/aH5VTZAYkbzLCSrrGDUl2hOA== X-Received: by 10.98.79.80 with SMTP id d77mr29119135pfb.55.1453756639223; Mon, 25 Jan 2016 13:17:19 -0800 (PST) Received: from ?IPv6:2001:df0:0:2006:c0da:ac17:5f6d:8e76? ([2001:df0:0:2006:c0da:ac17:5f6d:8e76]) by smtp.gmail.com with ESMTPSA id y26sm30709700pfi.88.2016.01.25.13.17.15 (version=TLSv1/SSLv3 cipher=OTHER); Mon, 25 Jan 2016 13:17:17 -0800 (PST) Subject: Re: should the IPv6 "default" route really be ::/0? To: Bob Hinden , Michael Richardson References: <13430.1453651443@obiwan.sandelman.ca> <56A529D4.3030707@gmail.com> <29791.1453736571@obiwan.sandelman.ca> <65F677A5-7A48-424D-A62B-46B43DECB405@gmail.com> From: Brian E Carpenter Organization: University of Auckland Message-ID: <56A690DE.2080308@gmail.com> Date: Tue, 26 Jan 2016 10:17:18 +1300 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.5.1 MIME-Version: 1.0 In-Reply-To: <65F677A5-7A48-424D-A62B-46B43DECB405@gmail.com> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Archived-At: Cc: IPv6 List X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 25 Jan 2016 21:17:21 -0000 On 26/01/2016 10:06, Bob Hinden wrote: > Michael, > >> On Jan 25, 2016, at 7:42 AM, Michael Richardson wrote: >> >> >> Brian E Carpenter wrote: >>> Just getting at one sub-issue: >> >>> On 25/01/2016 05:04, Michael Richardson wrote: >>> ... >>>> That's not the Internet. The Internet is at 2000::/3. >> >>> Well, no, and that is the crux of the problem. That's only the part >>> of the Internet that IANA is currently handing out prefixes for. >>> 4000::/3 is part of the Internet too. >> >> I didn't know that we had moved into the second /3 block. > > We have not started allocating prefixes out of 4000::/3. No. But that isn't the point. The point is to burn ROMs that will still work when prefixes in 4000::/3 *are* allocated. Brian > > See: https://www.iana.org/assignments/ipv6-address-space/ipv6-address-space.xml > > Bob > >> >> The converse of what I'm asking might be: >> - should hosts have a default blackhole route for any other prefixes? >> >> -- >> Michael Richardson , Sandelman Software Works >> -= IPv6 IoT consulting =- >> >> >> >> -------------------------------------------------------------------- >> IETF IPv6 working group mailing list >> ipv6@ietf.org >> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 >> -------------------------------------------------------------------- > From nobody Mon Jan 25 13:31:03 2016 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 750A81A0393 for ; Mon, 25 Jan 2016 13:31:01 -0800 (PST) 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=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zoD7YQrkmsPi for ; Mon, 25 Jan 2016 13:31:00 -0800 (PST) Received: from mail-qg0-x231.google.com (mail-qg0-x231.google.com [IPv6:2607:f8b0:400d:c04::231]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D0D661A038A for ; Mon, 25 Jan 2016 13:30:59 -0800 (PST) Received: by mail-qg0-x231.google.com with SMTP id 6so119416429qgy.1 for ; Mon, 25 Jan 2016 13:30:59 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=subject:mime-version:content-type:from:in-reply-to:date:cc :message-id:references:to; bh=yZKmt2HxqE+AJjGunSyHLaJ7NBou6Kyu0buYNBPwHbM=; b=OJVo95S3pddTMNkBv8nqmB3f37FKAsKg8cYrPjrmCC6W+Hv2tjrX4zGycd8lNDA1ef 2+GA7Xy8FryrRuNQPL9+i9+c0hAxfXsS5+oDTlvS0vLp3+szFUsyNWGdI5F9LmqOKudb zD5UTIFqNoACxHZzUcai/vTEdQMbEoYx7zFTg57x1dULC9ncxSthvHYj4tLcebQr0JqX amtPg2c1r7vVo6y2Zw+eWJOKAH/Zb2AImJ91nL4R8WwpFp7P5t9tz6sJhyJNHpCezoZj XkMKk5LGelG9TnKvb2h86tXR1AE0Xt1ys6s/fYePVSnBkzm1T/d6V8enC6Gj0I5fm0PV IjfA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:subject:mime-version:content-type:from :in-reply-to:date:cc:message-id:references:to; bh=yZKmt2HxqE+AJjGunSyHLaJ7NBou6Kyu0buYNBPwHbM=; b=FDQ+3LqOgpdf+qMc4dmIh9NsHiqeAefCxD0VIDSt97u3iTN9Qdsdl0JpZYMcDLTvT+ ZnwJgmHsd70VDeK+QLu+o2/dS3wBJjaug1KDxcvOQv8fvLDd7D1G01Z3ujN3njR7tQuL kZF8qb7l6rhliMp3CSTHMvywOR2H1+suADs2OwhazCAzMlFMprWwkBhNlQOkvi6dcOWv d9atFwBb+OeWg1RewQD00uQWhqWdZR2HH7XdthQK1H50xGjb5drOGptJk9kfC1kwc2sf 4qfp+vhCZ4rx1/6PKm6yFtil7a9MYygJivS56Y3Smz2K9y92gRMSHNAO/s02FXuH0eZZ d3bA== X-Gm-Message-State: AG10YOSPl1ittxpB8Cq+HhB5yWKeqGyZ+EzDAHfEYRLSDahFlChaEP5FZNsqk71kI3+Wuw== X-Received: by 10.140.28.66 with SMTP id 60mr23695814qgy.74.1453757459003; Mon, 25 Jan 2016 13:30:59 -0800 (PST) Received: from [172.16.224.219] ([209.97.127.34]) by smtp.gmail.com with ESMTPSA id y127sm9526283qky.4.2016.01.25.13.30.57 (version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Mon, 25 Jan 2016 13:30:57 -0800 (PST) Subject: Re: should the IPv6 "default" route really be ::/0? Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2104\)) Content-Type: multipart/signed; boundary="Apple-Mail=_7E49454F-54C4-4F9A-8001-CC9E4E19D1A8"; protocol="application/pgp-signature"; micalg=pgp-sha512 X-Pgp-Agent: GPGMail 2.5.2 From: Bob Hinden In-Reply-To: <56A690DE.2080308@gmail.com> Date: Mon, 25 Jan 2016 13:30:56 -0800 Message-Id: <60307788-240F-4268-836B-FB489F06F198@gmail.com> References: <13430.1453651443@obiwan.sandelman.ca> <56A529D4.3030707@gmail.com> <29791.1453736571@obiwan.sandelman.ca> <65F677A5-7A48-424D-A62B-46B43DECB405@gmail.com> <56A690DE.2080308@gmail.com> To: Brian Carpenter X-Mailer: Apple Mail (2.2104) Archived-At: Cc: Michael Richardson , Bob Hinden , IPv6 List X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 25 Jan 2016 21:31:01 -0000 --Apple-Mail=_7E49454F-54C4-4F9A-8001-CC9E4E19D1A8 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Brian, > On Jan 25, 2016, at 1:17 PM, Brian E Carpenter = wrote: >=20 > On 26/01/2016 10:06, Bob Hinden wrote: >> Michael, >>=20 >>> On Jan 25, 2016, at 7:42 AM, Michael Richardson = wrote: >>>=20 >>>=20 >>> Brian E Carpenter wrote: >>>> Just getting at one sub-issue: >>>=20 >>>> On 25/01/2016 05:04, Michael Richardson wrote: >>>> ... >>>>> That's not the Internet. The Internet is at 2000::/3. >>>=20 >>>> Well, no, and that is the crux of the problem. That's only the part >>>> of the Internet that IANA is currently handing out prefixes for. >>>> 4000::/3 is part of the Internet too. >>>=20 >>> I didn't know that we had moved into the second /3 block. >>=20 >> We have not started allocating prefixes out of 4000::/3. >=20 > No. But that isn't the point. The point is to burn ROMs that will > still work when prefixes in 4000::/3 *are* allocated. Yes, I wasn=E2=80=99t suggesting otherwise. As you pointed out RFC4291 = (and bis) makes it clear these are all global unicast. Bob >=20 > Brian >=20 >>=20 >> See: = https://www.iana.org/assignments/ipv6-address-space/ipv6-address-space.xml= >>=20 >> Bob >>=20 >>>=20 >>> The converse of what I'm asking might be: >>> - should hosts have a default blackhole route for any other = prefixes? >>>=20 >>> -- >>> Michael Richardson , Sandelman Software Works >>> -=3D IPv6 IoT consulting =3D- >>>=20 >>>=20 >>>=20 >>> -------------------------------------------------------------------- >>> IETF IPv6 working group mailing list >>> ipv6@ietf.org >>> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 >>> -------------------------------------------------------------------- >>=20 --Apple-Mail=_7E49454F-54C4-4F9A-8001-CC9E4E19D1A8 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 - https://gpgtools.org iQEcBAEBCgAGBQJWppQQAAoJEK7rdBF357uoe4MH/Aqd0bVWzTe18F8zh0vS7QUe FJ9imXrKhM0+GebghYUdLrwwFb8rWI7oajc6s1g0IEsEIXDPPv4ezlFHKq6Ks5Rr FZSSS+eJ7MwK9O/eobCyRyVJNesWEPnSUBHSL/k/AFvYjZKSuN8HxmEKWSyuSF8c Gu2UPNL1MXwLyPA7kbd5LCkVx3SGoAVp/fhIcLp+ICNuCqiDcZ27WwLCce6y4ZZw 0p0WKBgnx9CnvZU/I4j8Ht6PIL7+vOpnw3xABSmr8wzrZiHuMDlQa355k0LvmHAb KBigo1oBsA3HvU9BChbqOdifsn235S3iJ0Q93ncjYfaZH3qk+BZ7KrGSERLknYU= =UcPP -----END PGP SIGNATURE----- --Apple-Mail=_7E49454F-54C4-4F9A-8001-CC9E4E19D1A8-- From nobody Mon Jan 25 21:31:58 2016 Return-Path: X-Original-To: ipv6@ietf.org Delivered-To: ipv6@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 79C8C1B2EBE; Mon, 25 Jan 2016 21:31:56 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: Subject: I-D Action: draft-ietf-6man-default-iids-09.txt X-Test-IDTracker: no X-IETF-IDTracker: 6.13.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20160126053156.7514.72206.idtracker@ietfa.amsl.com> Date: Mon, 25 Jan 2016 21:31:56 -0800 Archived-At: Cc: ipv6@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.15 List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 26 Jan 2016 05:31:56 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the IPv6 Maintenance Working Group of the IETF. Title : Recommendation on Stable IPv6 Interface Identifiers Authors : Fernando Gont Alissa Cooper Dave Thaler Will Liu Filename : draft-ietf-6man-default-iids-09.txt Pages : 22 Date : 2016-01-25 Abstract: This document changes the recommended default Interface Identifier generation scheme for SLAAC to that specified in RFC7217, and recommends against embedding link-layer addresses in IPv6 Interface Identifiers. It formally updates RFC2464, RFC2467, RFC2470, RFC2491, RFC2492, RFC2497, RFC2590, RFC3146, RFC3572, RFC4291, RFC4338, RFC4391, RFC5072, and RFC5121, which require IPv6 Interface Identifiers to be derived from the underlying link-layer address. Additionally, this document provides advice about the generation of Interface Identifiers with Dynamic Host Configuration Protocol version 6 (DHCPv6) (thus updating RFC3315) and manual configuration. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-6man-default-iids/ There's also a htmlized version available at: https://tools.ietf.org/html/draft-ietf-6man-default-iids-09 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-6man-default-iids-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 nobody Mon Jan 25 23:26:54 2016 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9C97F1A6F3B for ; Mon, 25 Jan 2016 23:26:53 -0800 (PST) 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_20=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YP5YRBHWgQsV for ; Mon, 25 Jan 2016 23:26:51 -0800 (PST) Received: from fgont.go6lab.si (fgont.go6lab.si [IPv6:2001:67c:27e4::14]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 93DAA1A6F3A for ; Mon, 25 Jan 2016 23:26:51 -0800 (PST) Received: from [192.168.3.107] (unknown [181.165.125.191]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by fgont.go6lab.si (Postfix) with ESMTPSA id 3314C2069BC; Tue, 26 Jan 2016 08:26:43 +0100 (CET) Subject: Re: draft-ietf-6man-default-iids-08 To: weigengyu , ipv6@ietf.org References: <09178529BD77411993873F761BE6F722@WeiGengyuPC> <56A01A43.2030705@si6networks.com> <1EF23A58A95F41E98C04B18F00559596@WeiGengyuPC> From: Fernando Gont X-Enigmail-Draft-Status: N1110 Message-ID: <56A70851.7060307@gont.com.ar> Date: Tue, 26 Jan 2016 02:46:57 -0300 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.5.1 MIME-Version: 1.0 In-Reply-To: <1EF23A58A95F41E98C04B18F00559596@WeiGengyuPC> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Archived-At: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 26 Jan 2016 07:26:53 -0000 Hi, Gengyu, On 01/21/2016 12:17 PM, weigengyu wrote: > Hi Fernando, > > Thank you for your explanations. > > My question is ralated to whether the secure key is changed. No, it is not. The whole stability of the scheme depends on the key remaining stable. > In page 8 of RFC7212, > secret_key: > A secret key that is not known by the attacker. The secret > key SHOULD be of at least 128 bits. It MUST be initialized to > a pseudo-random number (see [RFC4086] for randomness > requirements for security) when the operating system is > installed or when the IPv6 protocol stack is "bootstrapped" > for the first time. An implementation MAY provide the means > for the system administrator to display and change the secret > key. > > Based on the above descriptions, it seems that the secret key needs > changing for randomness. No. It just needs to be random. Changing the key has nothing to do with randomness. > If the secrete key is changge the new generate IPv6 address will be > different. > The same problem has also been sent to RayH. > > I gesst that each time the new generated IPv6 address is differen as RID > is effected by F() with a parameter of the secure key which is an > randomness. You set/initialize they secret key when you install the system. ANd always keep the same value. -- no changes at all. Thanks, -- Fernando Gont e-mail: fernando@gont.com.ar || fgont@si6networks.com PGP Fingerprint: 7809 84F5 322E 45C7 F1C9 3945 96EE A9EF D076 FFF1 From nobody Tue Jan 26 00:03:06 2016 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 25F231A7005 for ; Tue, 26 Jan 2016 00:03:05 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.983 X-Spam-Level: X-Spam-Status: No, score=-3.983 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_ADSP_CUSTOM_MED=0.001, FREEMAIL_FROM=0.001, FREEMAIL_REPLY=1, HELO_EQ_FR=0.35, NML_ADSP_CUSTOM_MED=0.9, RCVD_IN_DNSWL_HI=-5, SPF_SOFTFAIL=0.665] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JaiA4uLcLPe7 for ; Tue, 26 Jan 2016 00:03:03 -0800 (PST) Received: from cirse-out.extra.cea.fr (cirse-out.extra.cea.fr [132.167.192.142]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4718D1A6FFE for ; Tue, 26 Jan 2016 00:03:03 -0800 (PST) Received: from pisaure.intra.cea.fr (pisaure.intra.cea.fr [132.166.88.21]) by cirse.extra.cea.fr (8.15.2/8.15.2/CEAnet-Internet-out-2.4) with ESMTP id u0Q831VG006785 for ; Tue, 26 Jan 2016 09:03:01 +0100 Received: from pisaure.intra.cea.fr (localhost [127.0.0.1]) by localhost (Postfix) with SMTP id 846B3201485 for ; Tue, 26 Jan 2016 09:10:56 +0100 (CET) Received: from muguet1.intra.cea.fr (muguet1.intra.cea.fr [132.166.192.6]) by pisaure.intra.cea.fr (Postfix) with ESMTP id 7C895201179 for ; Tue, 26 Jan 2016 09:10:56 +0100 (CET) Received: from [132.166.84.67] ([132.166.84.67]) by muguet1.intra.cea.fr (8.15.2/8.15.2/CEAnet-Intranet-out-1.4) with ESMTP id u0Q830I2003358 for ; Tue, 26 Jan 2016 09:03:00 +0100 Subject: Re: 2001:db8 [was Re: draft-ietf-6man-rfc4291bis] To: ipv6@ietf.org References: <56A27712.1060003@si6networks.com> <56A2A760.9050906@gmail.com> <28158.1453566884@obiwan.sandelman.ca> <56A4D946.5040604@si6networks.com> From: Alexandre Petrescu Message-ID: <56A72834.1010203@gmail.com> Date: Tue, 26 Jan 2016 10:03:00 +0200 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.5.1 MIME-Version: 1.0 In-Reply-To: <56A4D946.5040604@si6networks.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit Archived-At: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 26 Jan 2016 08:03:05 -0000 Le 24/01/2016 16:01, Fernando Gont a écrit : > On 01/23/2016 08:02 PM, Mark Smith wrote: >> >> On 24 Jan 2016 3:04 AM, "Michael Richardson" > > wrote: >>> >>> >>> Brian E Carpenter > > wrote: >>> > On 23/01/2016 07:38, Fernando Gont wrote: >>> >>> >> Another "WTF" was that on some platforms 2001:db8::/64 seem to be >>> >> blocked by the kernel, and not usable at all. >>> >>> > That seems quite reasonable, though. (Don't you mean 2001:db8::/32?) >>> >>> It's not reasonable to me. It should be possible to setup a lab of >> equipment >>> according to the documentation that was provided, exactly as documented. >>> >> >> While I sympathise with the viewpoint, that is using that documentation >> prefix for more documentation. >> >> I think ULAs for training labs are better, and would show that >> documentation prefixes should not be used on live networks of any type. > > Then, how do you document such lab while still complying with our rules > for documentation? > > A prefix that can only be used to write on paper is not of much use... > and to some extent a waste of address space... There is documentation and documentation. Documentation that gets very widely advertised (e.g. a Stevens book) should certainly use 2001:db8. But documentation with limited audience should use ULAs or real addresses. One should use specific means to protect that documentation from public viewing, like strong access control. I got used to handwriting 2001:db8 on paper, on drawing boards, and not on computers. Paper: made of cellulose extracted from wood. Virtual paper: powerpoint, electronic documents, machine writing. Virtual network: virtual box, virtual machines. An address typed on a virtual box should not be 2001:db8 because the stack is real although the machine is virtual. Alex > From nobody Tue Jan 26 00:04:42 2016 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D00831A7002 for ; Tue, 26 Jan 2016 00:04:41 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.983 X-Spam-Level: X-Spam-Status: No, score=-4.983 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_ADSP_CUSTOM_MED=0.001, FREEMAIL_FROM=0.001, HELO_EQ_FR=0.35, NML_ADSP_CUSTOM_MED=0.9, RCVD_IN_DNSWL_HI=-5, SPF_SOFTFAIL=0.665] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lZx4Hs2YscAi for ; Tue, 26 Jan 2016 00:04:40 -0800 (PST) Received: from cirse-out.extra.cea.fr (cirse-out.extra.cea.fr [132.167.192.142]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CEA491A0381 for ; Tue, 26 Jan 2016 00:04:39 -0800 (PST) Received: from pisaure.intra.cea.fr (pisaure.intra.cea.fr [132.166.88.21]) by cirse.extra.cea.fr (8.15.2/8.15.2/CEAnet-Internet-out-2.4) with ESMTP id u0Q84cqR007734 for ; Tue, 26 Jan 2016 09:04:38 +0100 Received: from pisaure.intra.cea.fr (localhost [127.0.0.1]) by localhost (Postfix) with SMTP id 8AB182053D2 for ; Tue, 26 Jan 2016 09:12:33 +0100 (CET) Received: from muguet1.intra.cea.fr (muguet1.intra.cea.fr [132.166.192.6]) by pisaure.intra.cea.fr (Postfix) with ESMTP id 80A0F2050F2 for ; Tue, 26 Jan 2016 09:12:33 +0100 (CET) Received: from [132.166.84.67] ([132.166.84.67]) by muguet1.intra.cea.fr (8.15.2/8.15.2/CEAnet-Intranet-out-1.4) with ESMTP id u0Q84bMH004637 for ; Tue, 26 Jan 2016 09:04:37 +0100 Subject: Re: 2001:db8 [was Re: draft-ietf-6man-rfc4291bis] To: ipv6@ietf.org References: <56A27712.1060003@si6networks.com> <56A2A760.9050906@gmail.com> <28158.1453566884@obiwan.sandelman.ca> <28bf01d15634$c0491c40$40db54c0$@oneunified.net> <56A4D9D5.7010507@si6networks.com> From: Alexandre Petrescu Message-ID: <56A72895.1040102@gmail.com> Date: Tue, 26 Jan 2016 10:04:37 +0200 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.5.1 MIME-Version: 1.0 In-Reply-To: <56A4D9D5.7010507@si6networks.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit Archived-At: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 26 Jan 2016 08:04:42 -0000 Le 24/01/2016 16:04, Fernando Gont a écrit : > On 01/23/2016 08:21 PM, Raymond Burkholder wrote: >>>> >>>> It's not reasonable to me. It should be possible to setup a lab of equipment >>>> according to the documentation that was provided, exactly as documented. >>>> >>> While I sympathise with the viewpoint, that is using that documentation prefix for more documentation. >>> I think ULAs for training labs are better, and would show that documentation prefixes should not be used on live networks of any type. >> >> I believe it goes both ways. When writing documentation, you want to test what you documented. So, you build something with the documentation addresses, prove that it works, then put into documentation verbatim. > > Exactly. And not just that: at times you also want to show the output of > actual commands, tests, etc. And if the documentation prefixes are not > usable, you have to resort to use a different prefix, then "patch" the > output. -- this wastes manpower, and also potentially introduces errors > (and, at times, it may not even be possible (think about screen captures > of a GUI)). If the audience is limited, a teacher can use real addresses, not the 2001:db8. Just tell them to keep these addresses safe from public view. The 2001:db8 is a documentation prefix, yes, but not the only prefix usable for such purpose. Alex > From nobody Tue Jan 26 00:06:45 2016 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 54EA01A701C for ; Tue, 26 Jan 2016 00:06:44 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.983 X-Spam-Level: X-Spam-Status: No, score=-4.983 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_ADSP_CUSTOM_MED=0.001, FREEMAIL_FROM=0.001, HELO_EQ_FR=0.35, NML_ADSP_CUSTOM_MED=0.9, RCVD_IN_DNSWL_HI=-5, SPF_SOFTFAIL=0.665] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id C4-bFt63hkjv for ; Tue, 26 Jan 2016 00:06:42 -0800 (PST) Received: from sainfoin-out.extra.cea.fr (sainfoin-out.extra.cea.fr [132.167.192.145]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 61CCE1A701A for ; Tue, 26 Jan 2016 00:06:42 -0800 (PST) Received: from pisaure.intra.cea.fr (pisaure.intra.cea.fr [132.166.88.21]) by sainfoin.extra.cea.fr (8.15.2/8.15.2/CEAnet-Internet-out-2.4) with ESMTP id u0Q86eES025990 for ; Tue, 26 Jan 2016 09:06:40 +0100 Received: from pisaure.intra.cea.fr (localhost [127.0.0.1]) by localhost (Postfix) with SMTP id 95AE0203886 for ; Tue, 26 Jan 2016 09:14:35 +0100 (CET) Received: from muguet1.intra.cea.fr (muguet1.intra.cea.fr [132.166.192.6]) by pisaure.intra.cea.fr (Postfix) with ESMTP id 83F392014BB for ; Tue, 26 Jan 2016 09:14:35 +0100 (CET) Received: from [132.166.84.67] ([132.166.84.67]) by muguet1.intra.cea.fr (8.15.2/8.15.2/CEAnet-Intranet-out-1.4) with ESMTP id u0Q86dr7006238 for ; Tue, 26 Jan 2016 09:06:39 +0100 Subject: Re: 2001:db8 [was Re: draft-ietf-6man-rfc4291bis] To: ipv6@ietf.org References: <56A27712.1060003@si6networks.com> <56A2A760.9050906@gmail.com> <28158.1453566884@obiwan.sandelman.ca> <28bf01d15634$c0491c40$40db54c0$@oneunified.net> <29252.1453646972@obiwan.sandelman.ca> From: Alexandre Petrescu Message-ID: <56A7290F.6090404@gmail.com> Date: Tue, 26 Jan 2016 10:06:39 +0200 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.5.1 MIME-Version: 1.0 In-Reply-To: <29252.1453646972@obiwan.sandelman.ca> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit Archived-At: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 26 Jan 2016 08:06:44 -0000 Le 24/01/2016 16:49, Michael Richardson a écrit : > > Raymond Burkholder wrote: > > I believe it goes both ways. When writing documentation, you want to > > test what you documented. So, you build something with the > > documentation addresses, prove that it works, then put into > > documentation verbatim. > > Exactly. > > (Using a ULA would convince some people that they can only use a ULA in > certain situations where in fact, a ULA would be wrong) I agree. At that point give a LL, a multicast, or a global address. Just tell the readers of that paper to not re-distribute because it's just an example, or because it can clash with others, or because it's the real address on our secure network and we dont want others to know it. Alex > > -- > Michael Richardson , Sandelman Software Works > -= IPv6 IoT consulting =- > > > > > > -------------------------------------------------------------------- > IETF IPv6 working group mailing list > ipv6@ietf.org > Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 > -------------------------------------------------------------------- > From nobody Tue Jan 26 01:43:05 2016 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5A5F11A889B for ; Tue, 26 Jan 2016 01:43:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.237 X-Spam-Level: * X-Spam-Status: No, score=1.237 tagged_above=-999 required=5 tests=[BAYES_50=0.8, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, STOX_REPLY_TYPE=0.439] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id w-MZLx_24fTQ for ; Tue, 26 Jan 2016 01:43:00 -0800 (PST) Received: from mx1.bupt.edu.cn (mx1.bupt.edu.cn [211.68.68.2]) by ietfa.amsl.com (Postfix) with ESMTP id 2E7691A8894 for ; Tue, 26 Jan 2016 01:43:00 -0800 (PST) Received: from mx1.bupt.edu.cn (unknown [127.0.0.1]) by mx1.bupt.edu.cn (AnyMacro(G7)) with SMTP id 376F919F44E for ; Tue, 26 Jan 2016 17:42:58 +0800 (HKT) Received: from WeiGengyuPC (unknown [10.103.241.89]) by mx1.bupt.edu.cn (AnyMacro(G7)) with ESMTPA id D6DBE19F426; Tue, 26 Jan 2016 17:42:57 +0800 (HKT) Message-ID: <92ABDA2561174C3EA800EE0A06AA05C2@WeiGengyuPC> From: "weigengyu" To: "Fernando Gont" References: <09178529BD77411993873F761BE6F722@WeiGengyuPC> <56A01A43.2030705@si6networks.com> <1EF23A58A95F41E98C04B18F00559596@WeiGengyuPC> <56A70851.7060307@gont.com.ar> In-Reply-To: <56A70851.7060307@gont.com.ar> Subject: Re: draft-ietf-6man-default-iids-08 Date: Tue, 26 Jan 2016 17:42:58 +0800 Organization: BUPT MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="UTF-8"; reply-type=original Content-Transfer-Encoding: 8bit X-Priority: 3 X-MSMail-Priority: Normal Importance: Normal X-Mailer: Microsoft Windows Live Mail 16.4.3528.331 X-MimeOLE: Produced By Microsoft MimeOLE V16.4.3528.331 Archived-At: Cc: ipv6@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 26 Jan 2016 09:43:03 -0000 Hi Gont; I want to make further clarification by the following questoins. > >> I gesst that each time the new generated IPv6 address is differen as RID >> is effected by F() with a parameter of the secure key which is an >> randomness. > You set/initialize they secret key when you install the system. ANd > always keep the same value. -- no changes at all. It means that the secret key is intializazed by a peseudo random generator, and then it keeps no change at all after it is initialized. Then the secret key becomes a constant, and the computer/node should remember it in order to keep it unchanged. right? I still question it, how long does the secret key keep unchanged? There are not any words about it in the related RFCs. The principle of security is based on RFC4086 "Randomness Requirements for Security". It seems that gurrantting the key secure by RFC4076, the key as a ramdomness should be changed frequently. Anything wrong? Regards, Gengyu WEI Network Technology Center School of Computer Beijing University of Posts and Telecommunications -----原始邮件----- From: Fernando Gont Sent: Tuesday, January 26, 2016 1:46 PM To: weigengyu ; ipv6@ietf.org Subject: Re: draft-ietf-6man-default-iids-08 Hi, Gengyu, On 01/21/2016 12:17 PM, weigengyu wrote: > Hi Fernando, > > Thank you for your explanations. > > My question is ralated to whether the secure key is changed. No, it is not. The whole stability of the scheme depends on the key remaining stable. > In page 8 of RFC7212, > secret_key: > A secret key that is not known by the attacker. The secret > key SHOULD be of at least 128 bits. It MUST be initialized to > a pseudo-random number (see [RFC4086] for randomness > requirements for security) when the operating system is > installed or when the IPv6 protocol stack is "bootstrapped" > for the first time. An implementation MAY provide the means > for the system administrator to display and change the secret > key. > > Based on the above descriptions, it seems that the secret key needs > changing for randomness. No. It just needs to be random. Changing the key has nothing to do with randomness. > If the secrete key is changge the new generate IPv6 address will be > different. > The same problem has also been sent to RayH. > > I gesst that each time the new generated IPv6 address is differen as RID > is effected by F() with a parameter of the secure key which is an > randomness. You set/initialize they secret key when you install the system. ANd always keep the same value. -- no changes at all. Thanks, -- Fernando Gont e-mail: fernando@gont.com.ar || fgont@si6networks.com PGP Fingerprint: 7809 84F5 322E 45C7 F1C9 3945 96EE A9EF D076 FFF1 From nobody Tue Jan 26 02:12:48 2016 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 22CDD1A8940 for ; Tue, 26 Jan 2016 02:12:47 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id N9Of3mVp6H9a for ; Tue, 26 Jan 2016 02:12:45 -0800 (PST) Received: from fgont.go6lab.si (fgont.go6lab.si [IPv6:2001:67c:27e4::14]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D70541A894B for ; Tue, 26 Jan 2016 02:12:44 -0800 (PST) Received: from [192.168.3.107] (unknown [181.165.125.191]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by fgont.go6lab.si (Postfix) with ESMTPSA id A31AD206A15; Tue, 26 Jan 2016 11:12:39 +0100 (CET) Subject: Re: draft-ietf-6man-default-iids-08 To: weigengyu , Fernando Gont References: <09178529BD77411993873F761BE6F722@WeiGengyuPC> <56A01A43.2030705@si6networks.com> <1EF23A58A95F41E98C04B18F00559596@WeiGengyuPC> <56A70851.7060307@gont.com.ar> <92ABDA2561174C3EA800EE0A06AA05C2@WeiGengyuPC> From: Fernando Gont X-Enigmail-Draft-Status: N1110 Message-ID: <56A7462C.6090104@si6networks.com> Date: Tue, 26 Jan 2016 07:10:52 -0300 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.5.1 MIME-Version: 1.0 In-Reply-To: <92ABDA2561174C3EA800EE0A06AA05C2@WeiGengyuPC> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Archived-At: Cc: ipv6@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 26 Jan 2016 10:12:47 -0000 On 01/26/2016 06:42 AM, weigengyu wrote: > Hi Gont; > > I want to make further clarification by the following questoins. > >> >>> I gesst that each time the new generated IPv6 address is differen as RID >>> is effected by F() with a parameter of the secure key which is an >>> randomness. > >> You set/initialize they secret key when you install the system. ANd >> always keep the same value. -- no changes at all. > > It means that the secret key is intializazed by a peseudo random > generator, and then it keeps no change at all after it is initialized. > Then the secret key becomes a constant, and the computer/node should > remember it in order to keep it unchanged. > right? Yes. > I still question it, how long does the secret key keep unchanged? > There are not any words about it in the related RFCs. As long as you want addresses to remain stable. -- we never say you should change it. And we note that the ability to view/manually set the secret_key is so that if you e.g. reinstall the OS, you can manually set the same key as before s that you get the same addresses. > The principle of security is based on RFC4086 "Randomness Requirements > for Security". > It seems that gurrantting the key secure by RFC4076, the key as a > ramdomness should be changed frequently. > Anything wrong? We reference RFC4086 to specify what we mean by random -- since if the secret_key is not really random, you could argue that it could be known or guessable. But that's it. Yes, in general, you usually change change keys frequently. But not in this case. Since the IIDs are generated as a result of a hash function, if you change the secret_key you obviously change the IID/address. -- Fernando Gont SI6 Networks e-mail: fgont@si6networks.com PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492 From nobody Tue Jan 26 03:15:43 2016 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8A8AB1AD0AD for ; Tue, 26 Jan 2016 03:15:41 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.002 X-Spam-Level: X-Spam-Status: No, score=-2.002 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ivtOv0M9z83x for ; Tue, 26 Jan 2016 03:15:39 -0800 (PST) Received: from cowbell.employees.org (cowbell.employees.org [IPv6:2001:1868:a000:17::142]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 82C211AD06F for ; Tue, 26 Jan 2016 03:15:39 -0800 (PST) Received: from cowbell.employees.org (localhost [127.0.0.1]) by cowbell.employees.org (Postfix) with ESMTP id D14BBD788E; Tue, 26 Jan 2016 03:15:37 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=employees.org; h=subject :mime-version:content-type:from:in-reply-to:date:cc:message-id :references:to; s=selector1; bh=ammBekDgq3KTxkXZ6SCCl/3z2D0=; b= Dih0++xxyVfW8r7E6yoczno3kpe/0uV6NCC3EqMzQc/LT5/1Z8hi7xdpqy9zycrR iQ8B4SrtZqw0CSPLuIrR3pfwyFdwg2tq6y3rYmUXVeEzH63Z2m3cTkMSwa5KGWzq TzEQ4CMuli6xh9++p03vKhidk3Z7nAjta/YTnSbDkT8= DomainKey-Signature: a=rsa-sha1; c=nofws; d=employees.org; h=subject :mime-version:content-type:from:in-reply-to:date:cc:message-id :references:to; q=dns; s=selector1; b=KcxMgIhkMb/UmGRlzwTo4msTlT FYOW1zxsXjip9pJRNcJAGHb2jF51UIAP59x5IzRSwcD0bIfHAxuI3ZFlHT33P+Al LaV4YXKP2m0klS34SqVSiYOdO5jYwBjOhO1V+8NpaMfLea/wKnm07cItQtEY2rFF vSCehH3MUXRTjlQEM= Received: from h.hanazo.no (unknown [173.38.220.61]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: otroan) by cowbell.employees.org (Postfix) with ESMTPSA id 95233D7881; Tue, 26 Jan 2016 03:15:37 -0800 (PST) Received: from [IPv6:::1] (localhost [IPv6:::1]) by h.hanazo.no (Postfix) with ESMTP id 03792F5F83F; Tue, 26 Jan 2016 12:15:35 +0100 (CET) Subject: Conclusion of: 6MAN WG Last Call - draft-ietf-6man-ipv6-mibs-obsolete Mime-Version: 1.0 (Mac OS X Mail 9.2 \(3112\)) Content-Type: multipart/signed; boundary="Apple-Mail=_0518B739-6A6F-4DA3-AD4C-1F625C50F3DB"; protocol="application/pgp-signature"; micalg=pgp-sha512 X-Pgp-Agent: GPGMail 2.6b2 From: otroan@employees.org In-Reply-To: <5C5991B4-EAF8-4BC9-8F99-90D9017ACC5C@gmail.com> Date: Tue, 26 Jan 2016 12:15:34 +0100 Message-Id: References: <5C5991B4-EAF8-4BC9-8F99-90D9017ACC5C@gmail.com> To: 6man WG , draft-ietf-6man-ipv6-mibs-obsolete@tools.ietf.org X-Mailer: Apple Mail (2.3112) Archived-At: Cc: Bob Hinden X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 26 Jan 2016 11:15:41 -0000 --Apple-Mail=_0518B739-6A6F-4DA3-AD4C-1F625C50F3DB Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii This concludes the working group last call of = draft-ietf-6man-ipv6-mibs-obsolete. We find there is consensus to advance the document with the changes = proposed by Mike Heard. Authors, can you please revise the document, so we can initiate the = process of advancing it to the IESG. Best regards, Ole > On 19 Nov 2015, at 19:34, Bob Hinden wrote: >=20 > This message restarts a two week 6MAN Working Group Last Call on = advancing: >=20 > Title : Republishing the IPV6-specific MIB modules as = obsolete > Authors : Bill Fenner > Filename : draft-ietf-6man-ipv6-mibs-obsolete-00.txt > Pages : 63 > Date : 2014-08-25 >=20 > http://datatracker.ietf.org/doc/draft-ietf-6man-ipv6-mibs-obsolete/ >=20 > as an Informational Document. Substantive comments and statements of = support for publishing this document should be directed to the mailing = list. Editorial suggestions can be sent to the authors. This last call = will end on 3 December 2015. >=20 > Best regards, > Ole & Bob >=20 >=20 --Apple-Mail=_0518B739-6A6F-4DA3-AD4C-1F625C50F3DB 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 - https://gpgtools.org iQIcBAEBCgAGBQJWp1VWAAoJEL7aWKiYQt92RIwQAJiaESf6fnWlTop/zvhby+3T hFKGJxGSL1YMcux3nSws92+f+WSthGlBA2LfVyA34AhT5f0jvod+7JMtwY4Yk0O4 zNgTTuSKTOk0InWoFJG3QMvzdpPk5Io24ARNSnhEO8N9mys8KNf+uYvwlikkcdr+ 8fFDde0PEeG4I7t+zvpcsSXHiFsrM752t27abmHUQre29hqzlSmpk0kSWivIya4z ++teLt12dJZOVKWu3e/wfVzEdj8/r9Zp4eAFd7jInd+zU9L98CAFqH8fdADOHoAE gKreV/lMP6KYiYpz/TshQDpvTCmgefht7PUq15IWy4z2Ekp9bDieRfJfiJL5EGpG N6lNbwsOkzwJFI4GwFyPqYs1Bm90sBop3eAh/m9gUfe907tQV43cs6GeAjX3KXnx nO4X0dLeBThb68U4/dS/MLOXauyKXxBZGmzmWFYe0oC7CUrCKS/znM84/BCY/Jvj lMLKvnPHumy3rBI3f6REEWhYrZm/nO+4P4FZitdgAOlGP+d84qNXXdy6EccZfQ2e nQtgUB6YMwkqblgV3N077mPchX7YJVMTanh0eNsU5gi2V3KRImmj6t0LBU+jMMNQ 638LeJL898LSvteONP5ubBNL5cYCnjdC/RmjwtMMYHjhC5mSMEIOI+/3mz/l/UHE i9SOqt5la/c0NA/X1+zS =YxOY -----END PGP SIGNATURE----- --Apple-Mail=_0518B739-6A6F-4DA3-AD4C-1F625C50F3DB-- From nobody Tue Jan 26 03:24:18 2016 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 93AC81AD241 for ; Tue, 26 Jan 2016 03:24:17 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id w78hyA7mtAQt for ; Tue, 26 Jan 2016 03:24:15 -0800 (PST) Received: from globis01.globis.net (mail.globis.net [IPv6:2001:470:1f15:62e::2]) by ietfa.amsl.com (Postfix) with ESMTP id A8DE91AD21C for ; Tue, 26 Jan 2016 03:24:15 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by globis01.globis.net (Postfix) with ESMTP id 30D784016F; Tue, 26 Jan 2016 12:24:14 +0100 (CET) X-Virus-Scanned: Debian amavisd-new at globis01.globis.net 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 49hxobnejjAG; Tue, 26 Jan 2016 12:24:11 +0100 (CET) Received: from Rays-MacBook-Pro.local (178-84-244-32.dynamic.upc.nl [178.84.244.32]) (Authenticated sender: v6ops@globis.net) by globis01.globis.net (Postfix) with ESMTPA id 9D6054016E; Tue, 26 Jan 2016 12:24:11 +0100 (CET) Message-ID: <56A7575A.2000707@globis.net> Date: Tue, 26 Jan 2016 12:24:10 +0100 From: "Ray Hunter (v6ops)" User-Agent: Postbox 4.0.8 (Macintosh/20151105) MIME-Version: 1.0 To: draft-ietf-6man-default-iids@tools.ietf.org Subject: draft-ietf-6man-default-iids v 09 Content-Type: multipart/alternative; boundary="------------070603090706060406010102" Archived-At: Cc: 6man X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 26 Jan 2016 11:24:17 -0000 This is a multi-part message in MIME format. --------------070603090706060406010102 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit I have read version 09 and support the intent of this draft. I have some editorial suggestions, and find the current formulation of the requirements unnecessarily onerous. Suggested textual changes below: s/As a result of the aforementioned issues, this document recommends the implementation of an alternative scheme ([RFC7217]) as the default stable IID generation scheme for SLAAC, such that the aforementioned issues are mitigated./To mitigate the aforementioned issues, this document RECOMMENDS "A Method for Generating Semantically Opaque Interface Identifiers with IPv6 Stateless Address Autoconfiguration (SLAAC)" [RFC7217] as the default method for generating IPv6 Interface Identifiers to be used with IPv6 Stateless Address Autoconfiguration (SLAAC)./ /Generation of IPv6 Interface Identifiers with SLAAC/ IMVHO The title of Section 3 has potential to cause confusion. How about: s/Generation of IPv6 Interface Identifiers with SLAAC/Requirements for Automatic IPv6 Addresses Generation Incorporating Interface Identifiers/ In the requirements, nothing really immediately breaks if the algorithm is non-compliant, so a SHOULD is more appropriate IMHO I also find it problematic to specify how to test compliance with a "MUST". This proposed standard as currently written might also make existing implementations non-compliant with existing IETF standards, and thus create a major commercial headache. suggest: s/Link layers MUST define a mechanism /Standards defining how IPv6 packets are transmitted over a specific link layer technology SHOULD define a mechanism / s/The resulting Interface Identifiers remain stable/The resulting Interface Identifiers SHOULD remain stable/ s/The resulting Interface Identifiers must change when addresses are configured for different prefixes./The resulting Interface Identifiers SHOULD change when addresses are configured for different prefixes./ s/it must be difficult for an outside entity to tell whether the addresses have been generated by the same host/it SHOULD be difficult for an outside entity to tell whether the addresses have been generated by the same host/ s/It must be difficult for an outside entity to predict the Interface Identifiers that will be generated by the algorithm,/It SHOULD be difficult for an outside entity to predict the Interface Identifiers that will be generated by the algorithm,/ s/The resulting Interface Identifiers must be semantically opaque./The resulting Interface Identifiers SHOULD be semantically opaque./ Section 5 is out of scope IMHO and should be removed entirely. If admins manually assign static addresses they're on their own. s/how each of the RFCs /how each of the following existing RFCs / -- regards, RayH --------------070603090706060406010102 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit I have read version 09 and support the intent of this draft.

I have some editorial suggestions, and find the current formulation of the requirements unnecessarily onerous.

Suggested textual changes below:

s/As a result of the aforementioned issues, this document recommends the implementation of an alternative scheme ([RFC7217]) as the default stable IID generation scheme for SLAAC, such that the aforementioned issues are mitigated./To mitigate the aforementioned issues, this document RECOMMENDS "A Method for Generating Semantically Opaque Interface Identifiers with IPv6 Stateless Address Autoconfiguration (SLAAC)" [RFC7217] as the default method for generating IPv6 Interface Identifiers to be used with IPv6 Stateless Address Autoconfiguration (SLAAC)./

/Generation of IPv6 Interface Identifiers with SLAAC/

IMVHO The title of Section 3 has potential to cause confusion.

How about:

s/Generation of IPv6 Interface Identifiers with SLAAC/Requirements for Automatic IPv6 Addresses Generation Incorporating Interface Identifiers/

In the requirements, nothing really immediately breaks if the algorithm is non-compliant, so a SHOULD is more appropriate IMHO
I also find it problematic to specify how to test compliance with a "MUST".
This proposed standard as currently written might also make existing implementations non-compliant with existing IETF standards, and thus create a major commercial headache.

suggest:

s/Link layers MUST define a mechanism /Standards defining how IPv6 packets are transmitted over a specific link layer technology SHOULD define a mechanism /

s/The resulting Interface Identifiers remain stable/The resulting Interface Identifiers SHOULD remain stable/

s/The resulting Interface Identifiers must change when addresses are configured for different prefixes./The resulting Interface Identifiers SHOULD change when addresses are configured for different prefixes./

s/it must be difficult for an outside entity to tell whether the addresses have been generated by the same host/it SHOULD be difficult for an outside entity to tell whether the addresses have been generated by the same host/

s/It must be difficult for an outside entity to predict the Interface Identifiers that will be generated by the algorithm,/It SHOULD be difficult for an outside entity to predict the Interface Identifiers that will be generated by the algorithm,/

s/The resulting Interface Identifiers must be semantically opaque./The resulting Interface Identifiers SHOULD be semantically opaque./


Section 5 is out of scope IMHO and should be removed entirely. If admins manually assign static addresses they're on their own.

s/how each of the RFCs /how each of the following existing RFCs /


--
regards,
RayH
--------------070603090706060406010102-- From nobody Tue Jan 26 11:29:15 2016 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2D6861B2BEE for ; Tue, 26 Jan 2016 11:29:15 -0800 (PST) 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=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BRgORJJVmhcr for ; Tue, 26 Jan 2016 11:29:13 -0800 (PST) Received: from mail-pa0-x22f.google.com (mail-pa0-x22f.google.com [IPv6:2607:f8b0:400e:c03::22f]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CF1731B2BED for ; Tue, 26 Jan 2016 11:29:13 -0800 (PST) Received: by mail-pa0-x22f.google.com with SMTP id uo6so104217275pac.1 for ; Tue, 26 Jan 2016 11:29:13 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=subject:to:references:from:organization:message-id:date:user-agent :mime-version:in-reply-to:content-type:content-transfer-encoding; bh=HJJI9EufD0P0lkvKuzUrLkb+W3tXeqXGRe0DPPKIN2Q=; b=E3YRI/fKdwVcofEOoEZOphLA5jms+F61omerfctYsJxBhIcWBAwmLToYtnaqXnDtbK UwmTGcKjumuxRSLmQrFLjNyEYMjLGTuviZ4rSl488EwdmwDKYknldD9afLuZVSV9F4jP TKnxCGjaKV+aKKoA/7kLdc4qBdBcdiNXVyagk+wCY5GyrFh8uEju26YZVPlv9EDJG2od KC4//5Sm9+ZKTKGe7OOhsy6gHOTVF45nxjkgrCjC91+SqjkJvnK2mPyhHp6CRuTG9JDD 9OY7SRubwrNPEMTo0bibubm8W1fz/4XD3kOatn7hU3U7j63AGjOfvFrldxyCPhoTJD9I vCtA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:subject:to:references:from:organization :message-id:date:user-agent:mime-version:in-reply-to:content-type :content-transfer-encoding; bh=HJJI9EufD0P0lkvKuzUrLkb+W3tXeqXGRe0DPPKIN2Q=; b=C4t0ThR5FQbxpoU9p87TmvGKsFJB+wBtFWshdUpWRV/6wHMJr1wInz1kC6RmNefFb1 uqdnaqbymbbh5hLc+FytxxB3eY5ye0CvGT/SlFd+HOgbUiZJ53+HeoFZCpbYLYwinzBy Hyy0GLSayd+6QWjPBQ+jXbQsknyQ3MvPmJypZbRaK7IZifIwORDrMvbXvWEweL9uNuF4 g10HfWgnWEXxEuljgU/2KDX0Ot+cjB1t/adatXy4t2AmVKdbuG/MmeiJLuzP7bZd7A2c Em5WJE78FKkA1IagdK3UJF/IVnU/f3UOa+nAlnOb59LnpioIrzPDKR3B3vHKuoTcNcrf uN4g== X-Gm-Message-State: AG10YOTGiV9NNnT+9oI7F2e6Nw6YhbFc3YoNevhcSTh0UxXgkMp+D5cKabMm07Q/uf0ODg== X-Received: by 10.66.102.106 with SMTP id fn10mr36894648pab.60.1453836553415; Tue, 26 Jan 2016 11:29:13 -0800 (PST) Received: from ?IPv6:2406:e007:477e:1:28cc:dc4c:9703:6781? ([2406:e007:477e:1:28cc:dc4c:9703:6781]) by smtp.gmail.com with ESMTPSA id f16sm3598498pff.18.2016.01.26.11.29.10 (version=TLSv1/SSLv3 cipher=OTHER); Tue, 26 Jan 2016 11:29:12 -0800 (PST) Subject: Re: 2001:db8 [was Re: draft-ietf-6man-rfc4291bis] To: Alexandre Petrescu , ipv6@ietf.org References: <56A27712.1060003@si6networks.com> <56A2A760.9050906@gmail.com> <28158.1453566884@obiwan.sandelman.ca> <28bf01d15634$c0491c40$40db54c0$@oneunified.net> <29252.1453646972@obiwan.sandelman.ca> <56A7290F.6090404@gmail.com> From: Brian E Carpenter Organization: University of Auckland Message-ID: <56A7C90C.6060905@gmail.com> Date: Wed, 27 Jan 2016 08:29:16 +1300 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.5.1 MIME-Version: 1.0 In-Reply-To: <56A7290F.6090404@gmail.com> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Archived-At: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 26 Jan 2016 19:29:15 -0000 On 26/01/2016 21:06, Alexandre Petrescu wrote: ... > Just tell the readers of that paper to not re-distribute > because it's just an example, or because it can clash with others, or because it's the real address on our secure network and we > dont want others to know it. Honestly this is naive. If you give an example, somebody somewhere *will* try it out on the live Internet. Because that's what humans do. About the first thing we had to do when we started taking TCP/IP seriously at CERN (around 1986) was renumber everything to get away from 1.0.0.0/8. Because some early documentation used that as an example. Humans haven't changed much since 1986. Brian From nobody Tue Jan 26 11:41:38 2016 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CEB451B2C18 for ; Tue, 26 Jan 2016 11:41:36 -0800 (PST) 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=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id x2cVlIo2D1s9 for ; Tue, 26 Jan 2016 11:41:35 -0800 (PST) Received: from mail-pa0-x22f.google.com (mail-pa0-x22f.google.com [IPv6:2607:f8b0:400e:c03::22f]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2AA3A1B2C16 for ; Tue, 26 Jan 2016 11:41:35 -0800 (PST) Received: by mail-pa0-x22f.google.com with SMTP id cy9so102446164pac.0 for ; Tue, 26 Jan 2016 11:41:35 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=subject:to:references:cc:from:organization:message-id:date :user-agent:mime-version:in-reply-to:content-type :content-transfer-encoding; bh=iqOHehFjgNo4shGD8V9MB6kGdV4d9lZpGQJEIhnWK/Y=; b=VIqwI7jbbOPWsum95Q2AwUTxNO695Ew+puGyiKKzIhrV3f+S2GMfCzFi1OwlX9qLUn BLOzaZ750tDdRK0gr1+Pt3Mlr1y5UUPaUvlzraCoEZoT6EClkNOdyAKCtiVR+evGrPEn Z5FOkBL7DY4Va7/3BbVyyb5s0WA0sv0gaBpmHZf69V1jsm4SCXVHzPUKnuKwYC4H67wb pkapbEB3S7wIWIZYDT/G3lugWKcYcPo57H7t654pwp8suAniQgXpOVNLHQ1m+H86Rnge qxnXF+ju0fChlX1RLZ/4GCnoVQ2eDw//wo/UPR3ACPJRVMdtJtc/ruDB9G2cOpjhBPHx LYXw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:subject:to:references:cc:from:organization :message-id:date:user-agent:mime-version:in-reply-to:content-type :content-transfer-encoding; bh=iqOHehFjgNo4shGD8V9MB6kGdV4d9lZpGQJEIhnWK/Y=; b=jEgHKI83Oa1yRDc48+/1V0r67Xd8OnkmEb6gB0mNIw2+TOt4jJmAkMJKzA7Rh+7BDz Ikjv0ApzBbY6qfVjnMNBEONcKKd1K5dhC2fx7MMWDSFj3Eg7T8XOKCgh41niy9yqoS55 3CMIlXmMON5+7s136wYhsG4bnshwMQuS8SdftxJ7HlZpmjx7U9MSPOJdLmlkhpWT9K3h kwrlAeuDu0rwGL8LfzGP72v5fOqfnXclCIdNC4KTcV8r2HdcKtxFe23im1pNelEJ4KU3 0MUz2NAIGdt61OU4P+Jg1vabhI1clTA86zvavQPvcwX9YPg+Ypnj6kpEB1vUbH4d6/wC PW2w== X-Gm-Message-State: AG10YOQS9HyyEsoQtTd04u2ejZlNvFDLZlTQdAqXNCiTju3g0K8Vb6jAWBwY0/ZTckgG0g== X-Received: by 10.67.14.234 with SMTP id fj10mr13662110pad.149.1453837294803; Tue, 26 Jan 2016 11:41:34 -0800 (PST) Received: from ?IPv6:2406:e007:477e:1:28cc:dc4c:9703:6781? ([2406:e007:477e:1:28cc:dc4c:9703:6781]) by smtp.gmail.com with ESMTPSA id wa17sm3567169pac.38.2016.01.26.11.41.31 (version=TLSv1/SSLv3 cipher=OTHER); Tue, 26 Jan 2016 11:41:33 -0800 (PST) Subject: Re: draft-ietf-6man-default-iids v 09 To: "Ray Hunter (v6ops)" , draft-ietf-6man-default-iids@tools.ietf.org References: <56A7575A.2000707@globis.net> From: Brian E Carpenter Organization: University of Auckland Message-ID: <56A7CBF0.2070203@gmail.com> Date: Wed, 27 Jan 2016 08:41:36 +1300 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.5.1 MIME-Version: 1.0 In-Reply-To: <56A7575A.2000707@globis.net> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Archived-At: Cc: 6man X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 26 Jan 2016 19:41:37 -0000 On 27/01/2016 00:24, Ray Hunter (v6ops) wrote: > I have read version 09 and support the intent of this draft. Ditto. I briefly checked all the specific updates to IPv6-over-foo and didn't find any obvious errors, but I think everybody should have a look at those. > I have some editorial suggestions, and find the current formulation of the requirements unnecessarily onerous. I disagree. I think stating the requirements explicitly is useful. However, I do have one question. Should we add a note that use of the privacy extensions (RFC 4941) is RECOMMENDED for situations where resistance to tracking is more important than stable addresses? ... > Section 5 is out of scope IMHO and should be removed entirely. If admins manually assign static addresses they're on their own. I disagree that it's out of scope. On the contrary, giving this warning is very much in scope - if someone is reading this document, their likely default solution is manual addressing. I know such people; they're across the road in IT Services. Brian From nobody Tue Jan 26 16:13:23 2016 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0CE601A0267 for ; Tue, 26 Jan 2016 16:13:22 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.309 X-Spam-Level: X-Spam-Status: No, score=-0.309 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DATE_IN_PAST_03_06=1.592, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GprJfdMH9vFn for ; Tue, 26 Jan 2016 16:13:20 -0800 (PST) Received: from fgont.go6lab.si (fgont.go6lab.si [IPv6:2001:67c:27e4::14]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1350A1A0266 for ; Tue, 26 Jan 2016 16:13:20 -0800 (PST) Received: from [192.168.3.107] (unknown [181.165.125.191]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by fgont.go6lab.si (Postfix) with ESMTPSA id E0AF0206A28; Wed, 27 Jan 2016 01:13:14 +0100 (CET) Subject: Re: draft-ietf-6man-default-iids v 09 To: Brian E Carpenter , "Ray Hunter (v6ops)" , draft-ietf-6man-default-iids@tools.ietf.org References: <56A7575A.2000707@globis.net> <56A7CBF0.2070203@gmail.com> From: Fernando Gont X-Enigmail-Draft-Status: N1110 Message-ID: <56A7D87A.5000809@si6networks.com> Date: Tue, 26 Jan 2016 17:35:06 -0300 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.5.1 MIME-Version: 1.0 In-Reply-To: <56A7CBF0.2070203@gmail.com> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Archived-At: Cc: 6man X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 Jan 2016 00:13:22 -0000 Hi, Brian, On 01/26/2016 04:41 PM, Brian E Carpenter wrote: > On 27/01/2016 00:24, Ray Hunter (v6ops) wrote: >> I have read version 09 and support the intent of this draft. > > Ditto. I briefly checked all the specific updates to IPv6-over-foo and didn't find > any obvious errors, but I think everybody should have a look at those. > >> I have some editorial suggestions, and find the current formulation of the requirements unnecessarily onerous. > > I disagree. I think stating the requirements explicitly is useful. FWIW, we ended up clarifying the requirements. Me, I'd be fine with just recommending RFC7217 without spelling out the requirements. > However, I do have one question. Should we add a note that use of the privacy > extensions (RFC 4941) is RECOMMENDED for situations where resistance to tracking > is more important than stable addresses? I'd consider that to be out-of-scope, and/or part of a more general document. This one just focuses on stable addresses, and spans all versions of those -- I'd been fine with just having this doc focus on the stable slaac addresses. > ... >> Section 5 is out of scope IMHO and should be removed entirely. If admins manually assign static addresses they're on their own. > > I disagree that it's out of scope. On the contrary, giving this warning is very much > in scope - if someone is reading this document, their likely default solution is > manual addressing. I know such people; they're across the road in IT Services. As currently entitled, the document provides recommendations on stable addresses, and manually-configured addresses is just one of those -- so the recommendation would be in scope. As noted above, I'd been equally happy to have the document just focus on the stable slaac addressess... but the wg thought that it was better to tackle all stable addresses. Thanks! Best regards, -- Fernando Gont SI6 Networks e-mail: fgont@si6networks.com PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492 From nobody Tue Jan 26 16:13:36 2016 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 322C71A0275 for ; Tue, 26 Jan 2016 16:13:32 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8JMhq1pRYCzJ for ; Tue, 26 Jan 2016 16:13:29 -0800 (PST) Received: from fgont.go6lab.si (fgont.go6lab.si [91.239.96.14]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id ED93B1A0266 for ; Tue, 26 Jan 2016 16:13:28 -0800 (PST) Received: from [192.168.3.107] (unknown [181.165.125.191]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by fgont.go6lab.si (Postfix) with ESMTPSA id ED7CC206A2D; Wed, 27 Jan 2016 01:13:21 +0100 (CET) Subject: Re: 2001:db8 [was Re: draft-ietf-6man-rfc4291bis] To: Brian E Carpenter , Alexandre Petrescu , ipv6@ietf.org References: <56A27712.1060003@si6networks.com> <56A2A760.9050906@gmail.com> <28158.1453566884@obiwan.sandelman.ca> <28bf01d15634$c0491c40$40db54c0$@oneunified.net> <29252.1453646972@obiwan.sandelman.ca> <56A7290F.6090404@gmail.com> <56A7C90C.6060905@gmail.com> From: Fernando Gont Message-ID: <56A80268.2010605@si6networks.com> Date: Tue, 26 Jan 2016 20:34:00 -0300 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.5.1 MIME-Version: 1.0 In-Reply-To: <56A7C90C.6060905@gmail.com> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit Archived-At: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 Jan 2016 00:13:32 -0000 On 01/26/2016 04:29 PM, Brian E Carpenter wrote: > On 26/01/2016 21:06, Alexandre Petrescu wrote: > ... >> Just tell the readers of that paper to not re-distribute >> because it's just an example, or because it can clash with others, or because it's the real address on our secure network and we >> dont want others to know it. > > Honestly this is naive. > > If you give an example, somebody somewhere *will* try it out on the live Internet. > Because that's what humans do. +1 -- Fernando Gont SI6 Networks e-mail: fgont@si6networks.com PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492 From nobody Tue Jan 26 16:46:08 2016 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 594C91A1A7C for ; Tue, 26 Jan 2016 16:46:06 -0800 (PST) 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=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id u3NfVLec3rkZ for ; Tue, 26 Jan 2016 16:46:04 -0800 (PST) Received: from mail-pf0-x232.google.com (mail-pf0-x232.google.com [IPv6:2607:f8b0:400e:c00::232]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C6A9C1A1A78 for ; Tue, 26 Jan 2016 16:46:04 -0800 (PST) Received: by mail-pf0-x232.google.com with SMTP id q63so110434041pfb.1 for ; Tue, 26 Jan 2016 16:46:04 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=subject:to:references:cc:from:organization:message-id:date :user-agent:mime-version:in-reply-to:content-type :content-transfer-encoding; bh=hhq0aE12bmbQF6zTPd82EizK8h3vr7uku0OuWsf3w70=; b=dCGRzrTUVdnZBylHlD342pRRSzynh6asv5/frG5UUKFA9UwQz+KfrcypiQxCUGXFFd itPy98VPm+omCqtp5ePDlrSusAIlU/S9OREGsI0p8/4Z4bwm34tLapO/CE14gYZGR8ud +WEmJyzc4NY7cCiKGx1M/EJJIYO4jVcWWAAKKbWlUmVcdD7FVcx1OIR3y1q843hnGiL6 xOqTUmxcL4bBTLfQdpcQaU3Z8/UkjXBXEGR2+Df0CHoP0rgJQIfY2iYCRf+VJiUpdqgM wpRe4gJKmpnX+XzYFu0grQQ8UKXXNRaHmIgzDMDJSE4ny4fIKCLtOwhiqlErlxf4SnY9 x1UA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:subject:to:references:cc:from:organization :message-id:date:user-agent:mime-version:in-reply-to:content-type :content-transfer-encoding; bh=hhq0aE12bmbQF6zTPd82EizK8h3vr7uku0OuWsf3w70=; b=UE495LgEnK5V1c7mrWQKUIsqK2FTF/zbHy/RkEkrGP2n0oNsvD+JywpAQzz7NO/Sck UKHHDCqM2ck4GtQ7dd6ClGCvDsFxYtdm4jGULm8qYNBCrd6zPAb3f1U6HHwpSSzg44hU Vm5C4b/dCuTC76+2+JfeIQGQbfuIurDgxwfUAxV0/dt3xdkSduXMQi8Zazyr5ydxeYJt sRfaiuyvOQkWiHFooz8fK4Nr2lQLFgsRihYVWTPdSfKUJYwpOquISw+RUmDRZi1Z4f/+ eQdHgXMjGnrw1qq+khgR9KBiWhQ5nxoieCwbiIzy0g6WXIMd5RABH6Jj5fnP//0cq5rR lOOg== X-Gm-Message-State: AG10YOSXK/WMoLM3PJrhu5ywUhQRjKp67ZZ5eYFtGeH0vBvlQdDBkIzvKFg9LPfmuoFxMw== X-Received: by 10.98.76.149 with SMTP id e21mr38688585pfj.89.1453855564525; Tue, 26 Jan 2016 16:46:04 -0800 (PST) Received: from ?IPv6:2406:e007:477e:1:28cc:dc4c:9703:6781? ([2406:e007:477e:1:28cc:dc4c:9703:6781]) by smtp.gmail.com with ESMTPSA id a62sm4376743pfj.40.2016.01.26.16.46.00 (version=TLSv1/SSLv3 cipher=OTHER); Tue, 26 Jan 2016 16:46:02 -0800 (PST) Subject: Re: draft-ietf-6man-default-iids v 09 To: Fernando Gont , "Ray Hunter (v6ops)" , draft-ietf-6man-default-iids@tools.ietf.org References: <56A7575A.2000707@globis.net> <56A7CBF0.2070203@gmail.com> <56A7D87A.5000809@si6networks.com> From: Brian E Carpenter Organization: University of Auckland Message-ID: <56A8134D.4090408@gmail.com> Date: Wed, 27 Jan 2016 13:46:05 +1300 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.5.1 MIME-Version: 1.0 In-Reply-To: <56A7D87A.5000809@si6networks.com> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Archived-At: Cc: 6man X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 Jan 2016 00:46:06 -0000 On 27/01/2016 09:35, Fernando Gont wrote: ... >> However, I do have one question. Should we add a note that use of the privacy >> extensions (RFC 4941) is RECOMMENDED for situations where resistance to tracking >> is more important than stable addresses? > > I'd consider that to be out-of-scope, and/or part of a more general > document. Fine. But assume that someone is trying to figure what to implement in their stack. I think this document needs to tell them that there are other possibilities. > This one just focuses on stable addresses, and spans all versions of > those -- I'd been fine with just having this doc focus on the stable > slaac addresses. Here's what I've just noticed. Although the word "stable" is in the title, it isn't mentioned in the Abstract and it first appears in the text in quotes, as if it doesn't really mean what it seems to mean. I think this needs a few small changes to make it perfect: In the Abstract, 2nd-last line, s/Interface Identifiers/stable Interface Identifiers/ In the Introduction, OLD [RFC4862] specifies Stateless Address Autoconfiguration (SLAAC) for IPv6 [RFC2460], which typically results in hosts configuring one or more "stable" addresses composed of a network prefix advertised by a local router, and an Interface Identifier (IID) [RFC4291] that typically embeds a link-layer address (e.g., an IEEE LAN MAC address). NEW [RFC4862] specifies Stateless Address Autoconfiguration (SLAAC) for IPv6 [RFC2460], which typically results in hosts configuring one or more stable addresses composed of a network prefix advertised by a local router, and an Interface Identifier (IID) [RFC4291] that typically embeds a link-layer address (e.g., an IEEE LAN MAC address). Where stable addresses are not desirable, privacy extensions [RFC4941] allow for frequently changing IIDs. The scope of the present document is for cases where stable IIDs are required. Rgds Brian From nobody Tue Jan 26 17:28:01 2016 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7D87C1AC3CA for ; Tue, 26 Jan 2016 17:27:59 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.001 X-Spam-Level: X-Spam-Status: No, score=-2.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RP_MATCHES_RCVD=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id a2RxbDDbu31f for ; Tue, 26 Jan 2016 17:27:55 -0800 (PST) Received: from mta-p8.oit.umn.edu (mta-p8.oit.umn.edu [134.84.196.208]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 27F3E1AC3C6 for ; Tue, 26 Jan 2016 17:27:55 -0800 (PST) Received: from localhost (unknown [127.0.0.1]) by mta-p8.oit.umn.edu (Postfix) with ESMTP id 1F057C27 for ; Wed, 27 Jan 2016 01:27:56 +0000 (UTC) X-Virus-Scanned: amavisd-new at umn.edu Received: from mta-p8.oit.umn.edu ([127.0.0.1]) by localhost (mta-p8.oit.umn.edu [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xYRws8d4i4YL for ; Tue, 26 Jan 2016 19:27:55 -0600 (CST) Received: from mail-ig0-f173.google.com (mail-ig0-f173.google.com [209.85.213.173]) (using TLSv1.2 with cipher AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by mta-p8.oit.umn.edu (Postfix) with ESMTPS id D88A89C8 for ; Tue, 26 Jan 2016 19:27:55 -0600 (CST) Received: by mail-ig0-f173.google.com with SMTP id h5so2235604igh.0 for ; Tue, 26 Jan 2016 17:27:53 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=umn.edu; s=google; h=reply-to:subject:references:to:cc:from:organization:message-id:date :user-agent:mime-version:in-reply-to:content-type :content-transfer-encoding; bh=QHvxcVgbnp5QncOIEBJ80MtFkL9AeTElVtbZ1H/4Hao=; b=p6Lz15eIPccQz8jFSeqD+1RaTlMlPsIGEzug/mkDDTr6I1K47+IUOzvARpBG/JIrN/ R9feWi7InQmbRhT1UId0vv6TpFZJNQh9PXb/iOVrFtiXh/B7dueAa/VhTx4b+Eh3OiqS STzDMxnIlvAdmGnkrOCPbjEAPPu9kaNqTsgYw= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:reply-to:subject:references:to:cc:from :organization:message-id:date:user-agent:mime-version:in-reply-to :content-type:content-transfer-encoding; bh=QHvxcVgbnp5QncOIEBJ80MtFkL9AeTElVtbZ1H/4Hao=; b=CmfH3D5dsHRg6ZWYCepl+hAF/VtPUCrk3auUpKy9KcCqUbIkcsR7ZVKvmeWfHJJ393 7CBOaeoSJnlV01wmPi3IXh0Msp5jlTsm+o5JfpHKnMdtWBkswFeXMYo0qN3Civ/4WqM1 unRY2c7eRANYVESInbzYpW7eu5+6tYfZvpU5U5DDR+SxjolA7ubX+8GCRDe52JVJ0slB PwGdGp/tenI85Rr/MttV1nityWMkCdhhXSFxYULFY5xzbbWLxSOPEZP4Jfws08Ji3nTQ SKOl0eWiEW6ly1shnE5F61sr415IXmKKZC1R8/C+lDqlEt1DDIJyKZNrlRVJORb823Sa +PFQ== X-Gm-Message-State: AG10YOShN35UvjD1nzkVtA95gbNyB3/WbRHNBFS3EGSKBom7JS1L7Zd6Zv+aonWxdsw+FYrb6b5vhXo/3HdApW01kKtOkXW8SUu7h8H1pSxitlf+/RWp8KN/Y4wByk3y5AM= X-Received: by 10.50.112.234 with SMTP id it10mr4655486igb.14.1453858073773; Tue, 26 Jan 2016 17:27:53 -0800 (PST) X-Received: by 10.50.112.234 with SMTP id it10mr4655474igb.14.1453858073628; Tue, 26 Jan 2016 17:27:53 -0800 (PST) Received: from x-10-104-134-78.uofm-secure.wireless.umn.edu ([2607:ea00:107:2001:480:5121:b7e3:1706]) by smtp.gmail.com with ESMTPSA id m132sm2076523ioa.42.2016.01.26.17.27.51 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 26 Jan 2016 17:27:51 -0800 (PST) Subject: Re: draft-ietf-6man-default-iids v 09 References: <56A7575A.2000707@globis.net> <56A7CBF0.2070203@gmail.com> <56A7D87A.5000809@si6networks.com> <56A8134D.4090408@gmail.com> To: Brian E Carpenter , Fernando Gont , "Ray Hunter (v6ops)" , draft-ietf-6man-default-iids@tools.ietf.org From: David Farmer Organization: University of Minnesota Message-ID: <56A81D15.4000103@umn.edu> Date: Tue, 26 Jan 2016 19:27:49 -0600 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:38.0) Gecko/20100101 Thunderbird/38.5.1 MIME-Version: 1.0 In-Reply-To: <56A8134D.4090408@gmail.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Cc: 6man X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: David Farmer List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 Jan 2016 01:27:59 -0000 On 1/26/16 18:46 , Brian E Carpenter wrote: ... > In the Abstract, 2nd-last line, > s/Interface Identifiers/stable Interface Identifiers/ > > In the Introduction, > > OLD > [RFC4862] specifies Stateless Address Autoconfiguration (SLAAC) for > IPv6 [RFC2460], which typically results in hosts configuring one or > more "stable" addresses composed of a network prefix advertised by a > local router, and an Interface Identifier (IID) [RFC4291] that > typically embeds a link-layer address (e.g., an IEEE LAN MAC > address). > > NEW > [RFC4862] specifies Stateless Address Autoconfiguration (SLAAC) for > IPv6 [RFC2460], which typically results in hosts configuring one or > more stable addresses composed of a network prefix advertised by a > local router, and an Interface Identifier (IID) [RFC4291] that > typically embeds a link-layer address (e.g., an IEEE LAN MAC > address). Where stable addresses are not desirable, privacy > extensions [RFC4941] allow for frequently changing IIDs. > The scope of the present document is for cases where stable > IIDs are required. I like these changes, but I think the two sentence added should be a separate paragraph. Thanks -- ================================================ David Farmer Email: farmer@umn.edu Office of Information Technology University of Minnesota 2218 University Ave SE Phone: 1-612-626-0815 Minneapolis, MN 55414-3029 Cell: 1-612-812-9952 ================================================ From nobody Tue Jan 26 22:40:43 2016 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 137371ACE5E for ; Tue, 26 Jan 2016 22:40:35 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.502 X-Spam-Level: X-Spam-Status: No, score=-0.502 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oYLRjBfRkK0Q for ; Tue, 26 Jan 2016 22:40:28 -0800 (PST) Received: from mx1.bupt.edu.cn (mx1.bupt.edu.cn [211.68.68.2]) by ietfa.amsl.com (Postfix) with ESMTP id 8FAF31ACE96 for ; Tue, 26 Jan 2016 22:40:25 -0800 (PST) Received: from mx1.bupt.edu.cn (unknown [127.0.0.1]) by mx1.bupt.edu.cn (AnyMacro(G7)) with SMTP id 8416819F450 for ; Wed, 27 Jan 2016 14:40:23 +0800 (HKT) Received: from WeiGengyuPC (unknown [10.103.241.89]) by mx1.bupt.edu.cn (AnyMacro(G7)) with ESMTPA id 5460619F3D8; Wed, 27 Jan 2016 14:40:22 +0800 (HKT) Message-ID: From: "weigengyu" To: "David Farmer" , "Brian E Carpenter" , "Fernando Gont" , "Ray Hunter \(v6ops\)" , References: <56A7575A.2000707@globis.net> <56A7CBF0.2070203@gmail.com> <56A7D87A.5000809@si6networks.com> <56A8134D.4090408@gmail.com> <56A81D15.4000103@umn.edu> In-Reply-To: <56A81D15.4000103@umn.edu> Subject: Re: draft-ietf-6man-default-iids v 09 Date: Wed, 27 Jan 2016 14:40:25 +0800 Organization: BUPT MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="utf-8"; reply-type=response Content-Transfer-Encoding: 8bit X-Priority: 3 X-MSMail-Priority: Normal Importance: Normal X-Mailer: Microsoft Windows Live Mail 16.4.3528.331 X-MimeOLE: Produced By Microsoft MimeOLE V16.4.3528.331 Archived-At: Cc: 6man X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 Jan 2016 06:40:35 -0000 Hi Brian and all, I like it too, it also answers what I concern. And I agree david's suggestion, i.e. the two sentence added should be a separate paragraph." > Where stable addresses are not desirable, privacy extensions [RFC4941] > allow for frequently changing IIDs. > The scope of the present document is for cases where stable IIDs are > required. Regards, Gengyu WEI Network Technology Center School of Computer Beijing University of Posts and Telecommunications -----原始邮件----- From: David Farmer Sent: Wednesday, January 27, 2016 9:27 AM To: Brian E Carpenter ; Fernando Gont ; Ray Hunter (v6ops) ; draft-ietf-6man-default-iids@tools.ietf.org Cc: 6man Subject: Re: draft-ietf-6man-default-iids v 09 On 1/26/16 18:46 , Brian E Carpenter wrote: ... > In the Abstract, 2nd-last line, > s/Interface Identifiers/stable Interface Identifiers/ > > In the Introduction, > > OLD > [RFC4862] specifies Stateless Address Autoconfiguration (SLAAC) for > IPv6 [RFC2460], which typically results in hosts configuring one or > more "stable" addresses composed of a network prefix advertised by a > local router, and an Interface Identifier (IID) [RFC4291] that > typically embeds a link-layer address (e.g., an IEEE LAN MAC > address). > > NEW > [RFC4862] specifies Stateless Address Autoconfiguration (SLAAC) for > IPv6 [RFC2460], which typically results in hosts configuring one or > more stable addresses composed of a network prefix advertised by a > local router, and an Interface Identifier (IID) [RFC4291] that > typically embeds a link-layer address (e.g., an IEEE LAN MAC > address). Where stable addresses are not desirable, privacy > extensions [RFC4941] allow for frequently changing IIDs. > The scope of the present document is for cases where stable > IIDs are required. I like these changes, but I think the two sentence added should be a separate paragraph. Thanks -- ================================================ David Farmer Email: farmer@umn.edu Office of Information Technology University of Minnesota 2218 University Ave SE Phone: 1-612-626-0815 Minneapolis, MN 55414-3029 Cell: 1-612-812-9952 ================================================ -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From nobody Tue Jan 26 23:38:44 2016 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 75D3A1B3529 for ; Tue, 26 Jan 2016 23:38:43 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 3.081 X-Spam-Level: *** X-Spam-Status: No, score=3.081 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FH_HOST_EQ_D_D_D_D=0.765, FH_HOST_EQ_D_D_D_DB=0.888, HELO_MISMATCH_NET=0.611, HOST_EQ_NL=1.545, HOST_EQ_STATIC=1.172, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dnWPJ41zurBP for ; Tue, 26 Jan 2016 23:38:41 -0800 (PST) Received: from globis01.globis.net (092-111-140-212.static.chello.nl [92.111.140.212]) by ietfa.amsl.com (Postfix) with ESMTP id E59171B3526 for ; Tue, 26 Jan 2016 23:38:40 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by globis01.globis.net (Postfix) with ESMTP id E0E5540170; Wed, 27 Jan 2016 08:38:39 +0100 (CET) X-Virus-Scanned: Debian amavisd-new at globis01.globis.net 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 FJLXQ3H7M3Gt; Wed, 27 Jan 2016 08:38:37 +0100 (CET) Received: from Rays-MacBook-Pro.local (178-84-244-32.dynamic.upc.nl [178.84.244.32]) (Authenticated sender: v6ops@globis.net) by globis01.globis.net (Postfix) with ESMTPA id 058DF40159; Wed, 27 Jan 2016 08:38:36 +0100 (CET) Message-ID: <56A873FB.5070002@globis.net> Date: Wed, 27 Jan 2016 08:38:35 +0100 From: "Ray Hunter (v6ops)" User-Agent: Postbox 4.0.8 (Macintosh/20151105) MIME-Version: 1.0 To: Brian E Carpenter Subject: Re: draft-ietf-6man-default-iids v 09 References: <56A7575A.2000707@globis.net> <56A7CBF0.2070203@gmail.com> In-Reply-To: <56A7CBF0.2070203@gmail.com> Content-Type: multipart/alternative; boundary="------------030805080509010906050607" Archived-At: Cc: draft-ietf-6man-default-iids@tools.ietf.org, 6man X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 Jan 2016 07:38:43 -0000 This is a multi-part message in MIME format. --------------030805080509010906050607 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit > Brian E Carpenter > 26 Jan 2016 20:41 > On 27/01/2016 00:24, Ray Hunter (v6ops) wrote: >> I have read version 09 and support the intent of this draft. > > Ditto. I briefly checked all the specific updates to IPv6-over-foo and didn't find > any obvious errors, but I think everybody should have a look at those. > >> I have some editorial suggestions, and find the current formulation of the requirements unnecessarily onerous. > > I disagree. I think stating the requirements explicitly is useful. I gave plenty of feedback to Fernando whilst he wrote RFC7217, so I know the content and background. If I filter through this document I can extract 4 threads of what it intends to do: 1. DEPRECATE IPv6 Interface Identifiers constructed in Modified EUI-64 format (as defined in https://tools.ietf.org/html/rfc4291#section-2.5.1) 2. Mandate that RFC7217 SHOULD be the default method of generating IPv6 Interface Identifiers to be used with IPv6 Stateless Address Autoconfiguration (SLAAC) 3. Document how 1 & 2 impacts text of existing standards 4. When specifying how to transport IPv6 over various link media (IPv6-over-FOO), alternatives or a substitute for RFC7217 MAY be mandated, but these alternatives or the substitute MUST meet certain requirements (which are met be RFC7217). Now those are all things the I can support. But the current text doesn't do that: it updates existing standards without providing a pathway for existing implementations using Interface Identifiers constructed in Modified EUI-64 format to remain compliant with IETF Standards Track RFCs. To me, slightly restructuring the text around the 4 intentions would make the intentions clearer, and avoid unintended consequences, like making existing implementations non-compliant over an issue that quite frankly doesn't actually break any functionality. > However, I do have one question. Should we add a note that use of the privacy > extensions (RFC 4941) is RECOMMENDED for situations where resistance to tracking > is more important than stable addresses? > > ... >> Section 5 is out of scope IMHO and should be removed entirely. If admins manually assign static addresses they're on their own. > > I disagree that it's out of scope. On the contrary, giving this warning is very much > in scope - if someone is reading this document, their likely default solution is > manual addressing. I know such people; they're across the road in IT Services. > > Brian > Ray Hunter (v6ops) > 26 Jan 2016 12:24 > I have read version 09 and support the intent of this draft. > > I have some editorial suggestions, and find the current formulation of > the requirements unnecessarily onerous. > > Suggested textual changes below: > > s/As a result of the aforementioned issues, this document recommends > the implementation of an alternative scheme ([RFC7217]) as the default > stable IID generation scheme for SLAAC, such that the aforementioned > issues are mitigated./To mitigate the aforementioned issues, this > document RECOMMENDS "A Method for Generating Semantically Opaque > Interface Identifiers with IPv6 Stateless Address Autoconfiguration > (SLAAC)" [RFC7217] as the default method for generating IPv6 Interface > Identifiers to be used with IPv6 Stateless Address Autoconfiguration > (SLAAC)./ > > /Generation of IPv6 Interface Identifiers with SLAAC/ > > IMVHO The title of Section 3 has potential to cause confusion. > > How about: > > s/Generation of IPv6 Interface Identifiers with SLAAC/Requirements for > Automatic IPv6 Addresses Generation Incorporating Interface Identifiers/ > > In the requirements, nothing really immediately breaks if the > algorithm is non-compliant, so a SHOULD is more appropriate IMHO > I also find it problematic to specify how to test compliance with a > "MUST". > This proposed standard as currently written might also make existing > implementations non-compliant with existing IETF standards, and thus > create a major commercial headache. > > suggest: > > s/Link layers MUST define a mechanism /Standards defining how IPv6 > packets are transmitted over a specific link layer technology SHOULD > define a mechanism / > > s/The resulting Interface Identifiers remain stable/The resulting > Interface Identifiers SHOULD remain stable/ > > s/The resulting Interface Identifiers must change when addresses are > configured for different prefixes./The resulting Interface Identifiers > SHOULD change when addresses are configured for different prefixes./ > > s/it must be difficult for an outside entity to tell whether the > addresses have been generated by the same host/it SHOULD be difficult > for an outside entity to tell whether the addresses have been > generated by the same host/ > > s/It must be difficult for an outside entity to predict the Interface > Identifiers that will be generated by the algorithm,/It SHOULD be > difficult for an outside entity to predict the Interface Identifiers > that will be generated by the algorithm,/ > > s/The resulting Interface Identifiers must be semantically opaque./The > resulting Interface Identifiers SHOULD be semantically opaque./ > > > Section 5 is out of scope IMHO and should be removed entirely. If > admins manually assign static addresses they're on their own. > > s/how each of the RFCs /how each of the following existing RFCs / > > -- regards, RayH --------------030805080509010906050607 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: 7bit

26 Jan 2016 20:41
On 27/01/2016 00:24, Ray Hunter (v6ops) wrote:

I have read version 09 and support the intent of this draft.


Ditto. I briefly checked all the specific updates to IPv6-over-foo and didn't find
any obvious errors, but I think everybody should have a look at those.


I have some editorial suggestions, and find the current formulation of the requirements unnecessarily onerous.


I disagree. I think stating the requirements explicitly is useful.
I gave plenty of feedback to Fernando whilst he wrote RFC7217, so I know the content and background.

If I filter through this document I can extract 4 threads of what it intends to do:

1. DEPRECATE IPv6 Interface Identifiers constructed in Modified EUI-64 format (as defined in https://tools.ietf.org/html/rfc4291#section-2.5.1)

2. Mandate that RFC7217 SHOULD be the default method of generating IPv6 Interface Identifiers to be used with IPv6 Stateless Address Autoconfiguration (SLAAC)

3. Document how 1 & 2 impacts text of existing standards

4. When specifying how to transport IPv6 over various link media (IPv6-over-FOO), alternatives or a substitute for RFC7217 MAY be mandated, but these alternatives or the substitute MUST meet certain requirements (which are met be RFC7217).

Now those are all things the I can support.

But the current text doesn't do that: it updates existing standards without providing a pathway for existing implementations using Interface Identifiers constructed in Modified EUI-64 format to remain compliant with IETF Standards Track RFCs.

To me, slightly restructuring the text around the 4 intentions would make the intentions clearer, and avoid unintended consequences, like making existing implementations non-compliant over an issue that quite frankly doesn't actually break any functionality.
However, I do have one question. Should we add a note that use of the privacy
extensions (RFC 4941) is RECOMMENDED for situations where resistance to tracking
is more important than stable addresses?

...

Section 5 is out of scope IMHO and should be removed entirely. If admins manually assign static addresses they're on their own.


I disagree that it's out of scope. On the contrary, giving this warning is very much
in scope - if someone is reading this document, their likely default solution is
manual addressing. I know such people; they're across the road in IT Services.

    Brian
26 Jan 2016 12:24
I have read version 09 and support the intent of this draft.

I have some editorial suggestions, and find the current formulation of the requirements unnecessarily onerous.

Suggested textual changes below:

s/As a result of the aforementioned issues, this document recommends the implementation of an alternative scheme ([RFC7217]) as the default stable IID generation scheme for SLAAC, such that the aforementioned issues are mitigated./To mitigate the aforementioned issues, this document RECOMMENDS "A Method for Generating Semantically Opaque Interface Identifiers with IPv6 Stateless Address Autoconfiguration (SLAAC)" [RFC7217] as the default method for generating IPv6 Interface Identifiers to be used with IPv6 Stateless Address Autoconfiguration (SLAAC)./

/Generation of IPv6 Interface Identifiers with SLAAC/

IMVHO The title of Section 3 has potential to cause confusion.

How about:

s/Generation of IPv6 Interface Identifiers with SLAAC/Requirements for Automatic IPv6 Addresses Generation Incorporating Interface Identifiers/

In the requirements, nothing really immediately breaks if the algorithm is non-compliant, so a SHOULD is more appropriate IMHO
I also find it problematic to specify how to test compliance with a "MUST".
This proposed standard as currently written might also make existing implementations non-compliant with existing IETF standards, and thus create a major commercial headache.

suggest:

s/Link layers MUST define a mechanism /Standards defining how IPv6 packets are transmitted over a specific link layer technology SHOULD define a mechanism /

s/The resulting Interface Identifiers remain stable/The resulting Interface Identifiers SHOULD remain stable/

s/The resulting Interface Identifiers must change when addresses are configured for different prefixes./The resulting Interface Identifiers SHOULD change when addresses are configured for different prefixes./

s/it must be difficult for an outside entity to tell whether the addresses have been generated by the same host/it SHOULD be difficult for an outside entity to tell whether the addresses have been generated by the same host/

s/It must be difficult for an outside entity to predict the Interface Identifiers that will be generated by the algorithm,/It SHOULD be difficult for an outside entity to predict the Interface Identifiers that will be generated by the algorithm,/

s/The resulting Interface Identifiers must be semantically opaque./The resulting Interface Identifiers SHOULD be semantically opaque./


Section 5 is out of scope IMHO and should be removed entirely. If admins manually assign static addresses they're on their own.

s/how each of the RFCs /how each of the following existing RFCs /



--
regards,
RayH
--------------030805080509010906050607-- From nobody Tue Jan 26 23:42:44 2016 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 116541ACE5C for ; Tue, 26 Jan 2016 23:42:43 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hakbTvwbI8Ww for ; Tue, 26 Jan 2016 23:42:41 -0800 (PST) Received: from nagasaki.bogus.com (nagasaki.bogus.com [IPv6:2001:418:1::81]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9255B1A1A8B for ; Tue, 26 Jan 2016 23:42:41 -0800 (PST) Received: from mb-2.local ([IPv6:2601:647:4204:51:bdb7:e6de:47d4:f9fc]) (authenticated bits=0) by nagasaki.bogus.com (8.14.9/8.14.9) with ESMTP id u0R7gd2A084640 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Wed, 27 Jan 2016 07:42:40 GMT (envelope-from joelja@bogus.com) Subject: Re: draft-ietf-6man-rfc4291bis To: Brian Haberman , ipv6@ietf.org References: <56A27EC5.1060204@gmail.com> <56A2A689.7020707@si6networks.com> <56A660AF.6010703@innovationslab.net> From: joel jaeggli X-Enigmail-Draft-Status: N1110 Message-ID: <56A874EE.9050100@bogus.com> Date: Tue, 26 Jan 2016 23:42:38 -0800 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.11; rv:44.0) Gecko/20100101 Thunderbird/44.0 MIME-Version: 1.0 In-Reply-To: <56A660AF.6010703@innovationslab.net> Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="m7HvXITFcPm626W1wP7ootfnnRkE2HGVn" Archived-At: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 Jan 2016 07:42:43 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --m7HvXITFcPm626W1wP7ootfnnRkE2HGVn Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable On 1/25/16 9:51 AM, Brian Haberman wrote: >=20 >=20 > On 1/22/16 5:00 PM, Fernando Gont wrote: >> On 01/22/2016 04:11 PM, Brian E Carpenter wrote: >>> On 23/01/2016 02:17, Sander Steffann wrote: >>>> Hi, >>>> >>>>>> | 10 | >>>>>> | bits | 54 bits | 64 bits = | >>>>>> +----------+-------------------------+-------------------------= ---+ >>>>>> |1111111010| 0 | interface ID = | >>>>>> +----------+-------------------------+-------------------------= ---+ >>>>>> >>>>>> The definition is wrong.The middle 54 bits can be any value.Please= fix it. >>>>> >>>>> How did you come to that conclusion? >>>>> >>>>> Some implementations might be tolerant of non-zero values in those = 54 bits, but that doesn't make the definition wrong. >>>> >>>> It has always been interesting that a /10 is reserved for link-local= while only a /64 is commonly used. The 54 bits in the middle could be an= ything,=20 >>> >>> No, the standard has always said that they *are* zero. We attempted t= o clarify this >>> in RFC 7421 - please see the bottom of this page: >>> http://tools.ietf.org/html/rfc7421#page-11 >>> >>>> but they are always 0. FreeBSD even uses that assumption >>> >>> It's not an assumption; it's the standard. >> >> Without looking back at the specs right now I seem to recall finding t= he >> definition of ll addresses as fe80::/10 confusing in that respect. >> The current behavior implies fe80::/64 rather than fe80::/10. >=20 > FE80::/10 is defined as link-scoped unicast. > FE80::/64 is defined as link-local address space. >=20 > There is nothing in the specs that would preclude a new format in the > link-scoped unicast address space. It just needs to be defined. I think it's quite reasonable that we shouldn't infill sparse address space with assumptions. If we reserved something but didn't allocate it, it's unallocated, not a free-for-all; seems like the basic conservative assumption. It is reasonable to allow for the configuration of unallocated resources. After all it's not always the case that software has to change to account for new usage, but it's also reasonable to accept that such usage may be allowable under common defaults. > Regards, > Brian >=20 >=20 >=20 > -------------------------------------------------------------------- > IETF IPv6 working group mailing list > ipv6@ietf.org > Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 > -------------------------------------------------------------------- >=20 --m7HvXITFcPm626W1wP7ootfnnRkE2HGVn 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 Comment: GPGTools - http://gpgtools.org iEYEARECAAYFAlaodO4ACgkQ8AA1q7Z/VrIeagCdHr9akr7MjBuuRWqjhmThcsWe 5sYAn167JBzgc8sXPAflljekC8Kjj1T6 =tIkG -----END PGP SIGNATURE----- --m7HvXITFcPm626W1wP7ootfnnRkE2HGVn-- From nobody Tue Jan 26 23:51:56 2016 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C69871B3552 for ; Tue, 26 Jan 2016 23:51:54 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.983 X-Spam-Level: X-Spam-Status: No, score=-4.983 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_ADSP_CUSTOM_MED=0.001, FREEMAIL_FROM=0.001, HELO_EQ_FR=0.35, NML_ADSP_CUSTOM_MED=0.9, RCVD_IN_DNSWL_HI=-5, SPF_SOFTFAIL=0.665] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9rYjl6yWu7vV for ; Tue, 26 Jan 2016 23:51:53 -0800 (PST) Received: from cirse-out.extra.cea.fr (cirse-out.extra.cea.fr [132.167.192.142]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DE3C61B3551 for ; Tue, 26 Jan 2016 23:51:52 -0800 (PST) Received: from pisaure.intra.cea.fr (pisaure.intra.cea.fr [132.166.88.21]) by cirse.extra.cea.fr (8.15.2/8.15.2/CEAnet-Internet-out-2.4) with ESMTP id u0R7poTF028445; Wed, 27 Jan 2016 08:51:50 +0100 Received: from pisaure.intra.cea.fr (localhost [127.0.0.1]) by localhost (Postfix) with SMTP id 15C37201680; Wed, 27 Jan 2016 08:59:47 +0100 (CET) Received: from muguet1.intra.cea.fr (muguet1.intra.cea.fr [132.166.192.6]) by pisaure.intra.cea.fr (Postfix) with ESMTP id 0024F200CC7; Wed, 27 Jan 2016 08:59:46 +0100 (CET) Received: from [132.166.84.97] ([132.166.84.97]) by muguet1.intra.cea.fr (8.15.2/8.15.2/CEAnet-Intranet-out-1.4) with ESMTP id u0R7pnBw017405; Wed, 27 Jan 2016 08:51:49 +0100 Subject: Re: 2001:db8 [was Re: draft-ietf-6man-rfc4291bis] To: Brian E Carpenter References: <56A27712.1060003@si6networks.com> <56A2A760.9050906@gmail.com> <28158.1453566884@obiwan.sandelman.ca> <28bf01d15634$c0491c40$40db54c0$@oneunified.net> <29252.1453646972@obiwan.sandelman.ca> <56A7290F.6090404@gmail.com> <56A7C90C.6060905@gmail.com> From: Alexandre Petrescu Message-ID: <56A87715.3020200@gmail.com> Date: Wed, 27 Jan 2016 09:51:49 +0200 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.5.1 MIME-Version: 1.0 In-Reply-To: <56A7C90C.6060905@gmail.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Archived-At: Cc: ipv6@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 Jan 2016 07:51:55 -0000 Le 26/01/2016 21:29, Brian E Carpenter a écrit : > On 26/01/2016 21:06, Alexandre Petrescu wrote: > ... >> Just tell the readers of that paper to not re-distribute >> because it's just an example, or because it can clash with others, or because it's the real address on our secure network and we >> dont want others to know it. > > Honestly this is naive. When people give examples of credit card numbers, license plates or new bank notes, they often bar it with a "fake" diagonal. That seems naïve too yet it's common practice against counterfeit. > If you give an example, somebody somewhere *will* try it out on the live Internet. > Because that's what humans do. Yes. > About the first thing we had to do when we started taking TCP/IP seriously at > CERN (around 1986) was renumber everything to get away from 1.0.0.0/8. Because > some early documentation used that as an example. Humans haven't changed much > since 1986. The first thing I type on a computer to see whether it supports IPv6 is ifconfig eth0 add 1::1/128 because that's the fastest way to check. Alex > > Brian > n From nobody Wed Jan 27 01:04:35 2016 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7C2091B36F5 for ; Wed, 27 Jan 2016 01:04:34 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.499 X-Spam-Level: X-Spam-Status: No, score=-1.499 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, FROM_LOCAL_NOVOWEL=0.5, HK_RANDOM_ENVFROM=0.001, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id t-kS0ssKYyXH for ; Wed, 27 Jan 2016 01:04:33 -0800 (PST) Received: from mail-vk0-x22b.google.com (mail-vk0-x22b.google.com [IPv6:2607:f8b0:400c:c05::22b]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2D9BD1B36F1 for ; Wed, 27 Jan 2016 01:04:33 -0800 (PST) Received: by mail-vk0-x22b.google.com with SMTP id n1so1273513vkb.3 for ; Wed, 27 Jan 2016 01:04:33 -0800 (PST) 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=uTVhfnNlbyBJbIH8teeX4EwaEzBGvjtqCvQaSHJSH1s=; b=OWtLenQmlgBAbBH85EISdj4/Etjnjtf1Psjbj5/RAT3d7LNdgIZr3hvdZ+T7diMUCb yFdKSbWqplkt2c4zF+2hrDksDcylVUpWS36i3ypbKlbhxhuA7SpWkc7IZ3JvFYF/ixLC gp7HRqLYhoQ3v2pVLb4w7MWg83v/ZZ5F3oXM7xAnQasCAsC59DFzLSxAHuyDMxOeLVgC gw5wFrCKNvimh0kJ60yGbIzg9RhYdiy0UFEP2fSrjXEusVibIO2wvVFGAnWOz+jsj3xA W915ZpD6i0zDVvA/Xoa8zKtgle0I8iesZfM9JhFF8aDYT8oNn1Xn35ESBGeweu047Qhp 2IQw== 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=uTVhfnNlbyBJbIH8teeX4EwaEzBGvjtqCvQaSHJSH1s=; b=fS2aw9W7NlrdZdhLdxoi+lKHWEfmsJRQ5/RpfnmlZkvUbgbzyBDa44xPrpRTb0OboU LF9Vn+JQlhYyr1D4bUPQc2ULAGyl5kcwwFVw46N/CRd9pLD2IEBVVvkAhRMFHMGp1OOa ZpoEY07P9ksBEZ5Na56Iq5cJwwyG4oJ/kzuwyf2dg7lPDmdAs2sUIwU8EwQC5YHK8qXy YcUinvtG9lus3mfKYWGjSVOqpy72ql30Mu8BO0bXCPFyqybM/qaQdes8GuMgS+ErWwCG RPM9YkLheuI2PR2oZdiNIM+PPtRbsZSKiMOC8mhL5q6J+5/eq5yFlcI682LKa/XQRca2 Mesg== X-Gm-Message-State: AG10YOQl35NmrZ28WkFoAIzxbjhnTHKDHpxhk5pZtWLKqD1xejlKl6syGKv97/d8Ek8AYhOXOEMYMN3kJHzgXw== X-Received: by 10.31.188.142 with SMTP id m136mr17761403vkf.89.1453885472105; Wed, 27 Jan 2016 01:04:32 -0800 (PST) MIME-Version: 1.0 Received: by 10.103.99.1 with HTTP; Wed, 27 Jan 2016 01:04:02 -0800 (PST) In-Reply-To: <56A7CBF0.2070203@gmail.com> References: <56A7575A.2000707@globis.net> <56A7CBF0.2070203@gmail.com> From: Mark Smith Date: Wed, 27 Jan 2016 20:04:02 +1100 Message-ID: Subject: Re: draft-ietf-6man-default-iids v 09 To: Brian E Carpenter Content-Type: text/plain; charset=UTF-8 Archived-At: Cc: "Ray Hunter \(v6ops\)" , draft-ietf-6man-default-iids@tools.ietf.org, 6man X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 Jan 2016 09:04:34 -0000 On 27 January 2016 at 06:41, Brian E Carpenter wrote: > On 27/01/2016 00:24, Ray Hunter (v6ops) wrote: >> I have read version 09 and support the intent of this draft. > > Ditto. I briefly checked all the specific updates to IPv6-over-foo and didn't find > any obvious errors, but I think everybody should have a look at those. > >> I have some editorial suggestions, and find the current formulation of the requirements unnecessarily onerous. > > I disagree. I think stating the requirements explicitly is useful. > > However, I do have one question. Should we add a note that use of the privacy > extensions (RFC 4941) is RECOMMENDED for situations where resistance to tracking > is more important than stable addresses? > I agree with providing a brief reference to this. There are now many IPv6 related RFCs, so reference to related ones can only make finding IPv6 information easier. > ... >> Section 5 is out of scope IMHO and should be removed entirely. If admins manually assign static addresses they're on their own. > > I disagree that it's out of scope. On the contrary, giving this warning is very much > in scope - if someone is reading this document, their likely default solution is > manual addressing. I know such people; they're across the road in IT Services. > I think I may have suggested including some text about good static/manual addresses. I think it is useful to include just for completeness as SLAAC, DHCPv6 and manual addresses are all both address generation and address configuration methods, and the IIDs generated and configured using any of them should all have good privacy properties. Regards, Mark. From nobody Wed Jan 27 01:41:16 2016 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4A5DE1B379C for ; Wed, 27 Jan 2016 01:41:15 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id b0tsZ_VOb8iB for ; Wed, 27 Jan 2016 01:41:13 -0800 (PST) Received: from fgont.go6lab.si (fgont.go6lab.si [91.239.96.14]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C68291B3793 for ; Wed, 27 Jan 2016 01:41:12 -0800 (PST) Received: from [192.168.3.107] (unknown [181.165.125.191]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by fgont.go6lab.si (Postfix) with ESMTPSA id 5E3E9206A36; Wed, 27 Jan 2016 10:41:07 +0100 (CET) Subject: Re: draft-ietf-6man-default-iids v 09 To: Brian E Carpenter , "Ray Hunter (v6ops)" , draft-ietf-6man-default-iids@tools.ietf.org References: <56A7575A.2000707@globis.net> <56A7CBF0.2070203@gmail.com> <56A7D87A.5000809@si6networks.com> <56A8134D.4090408@gmail.com> From: Fernando Gont X-Enigmail-Draft-Status: N1110 Message-ID: <56A87C54.4080408@si6networks.com> Date: Wed, 27 Jan 2016 05:14:12 -0300 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.5.1 MIME-Version: 1.0 In-Reply-To: <56A8134D.4090408@gmail.com> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Archived-At: Cc: 6man X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 Jan 2016 09:41:15 -0000 Hi, Brian, On 01/26/2016 09:46 PM, Brian E Carpenter wrote: > On 27/01/2016 09:35, Fernando Gont wrote: > ... >>> However, I do have one question. Should we add a note that use of the privacy >>> extensions (RFC 4941) is RECOMMENDED for situations where resistance to tracking >>> is more important than stable addresses? >> >> I'd consider that to be out-of-scope, and/or part of a more general >> document. > > Fine. But assume that someone is trying to figure what to implement in > their stack. I think this document needs to tell them that there are > other possibilities. There are a couple of things to note here: 1) RFC4941 is implemented along with stable addresses. So the work we're doing here is pretty much orthogonal to temp addresses. It *is* the case, though, that at times RFC7217 may be good enough to an extent that RFC4941 may be deemed as unnecessary (in some scenarios). But, again, that's pretty much orthogonal. 2) If anything, I guess one might include non-normative text in the security considerations section. But my take is that we started tackling the well-known problem of stable SLAAC IIDs, then we augmented the wok to tackle all stable addresses, and I'm of the idea that eventually, the more onerous the project, the less feasible it is. One could, for instance, envision that a whole document could try to address the problem of tracking/correlation, in which addressing (including recommendations regarding whether to enable RFC4941 or not) would be one of the items... >> This one just focuses on stable addresses, and spans all versions of >> those -- I'd been fine with just having this doc focus on the stable >> slaac addresses. > > Here's what I've just noticed. Although the word "stable" is in the title, > it isn't mentioned in the Abstract and it first appears in the text in quotes, > as if it doesn't really mean what it seems to mean. > > I think this needs a few small changes to make it perfect: > > In the Abstract, 2nd-last line, > s/Interface Identifiers/stable Interface Identifiers/ > > In the Introduction, > > OLD > [RFC4862] specifies Stateless Address Autoconfiguration (SLAAC) for > IPv6 [RFC2460], which typically results in hosts configuring one or > more "stable" addresses composed of a network prefix advertised by a > local router, and an Interface Identifier (IID) [RFC4291] that > typically embeds a link-layer address (e.g., an IEEE LAN MAC > address). > > NEW > [RFC4862] specifies Stateless Address Autoconfiguration (SLAAC) for > IPv6 [RFC2460], which typically results in hosts configuring one or > more stable addresses composed of a network prefix advertised by a > local router, and an Interface Identifier (IID) [RFC4291] that > typically embeds a link-layer address (e.g., an IEEE LAN MAC > address). Where stable addresses are not desirable, privacy > extensions [RFC4941] allow for frequently changing IIDs. > The scope of the present document is for cases where stable > IIDs are required. I'm 100% in agreement with you. Unless anyone argues against, I will apply the suggested change. Thanks! Best regards, -- Fernando Gont SI6 Networks e-mail: fgont@si6networks.com PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492 From nobody Wed Jan 27 01:41:32 2016 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 10D1F1B37AB for ; Wed, 27 Jan 2016 01:41:31 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Rj8rdvP0oVdG for ; Wed, 27 Jan 2016 01:41:29 -0800 (PST) Received: from fgont.go6lab.si (fgont.go6lab.si [91.239.96.14]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 661841B37A8 for ; Wed, 27 Jan 2016 01:41:24 -0800 (PST) Received: from [192.168.3.107] (unknown [181.165.125.191]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by fgont.go6lab.si (Postfix) with ESMTPSA id C621F206A38; Wed, 27 Jan 2016 10:41:19 +0100 (CET) Subject: Re: draft-ietf-6man-default-iids v 09 To: "Ray Hunter (v6ops)" , Brian E Carpenter References: <56A7575A.2000707@globis.net> <56A7CBF0.2070203@gmail.com> <56A873FB.5070002@globis.net> From: Fernando Gont X-Enigmail-Draft-Status: N1110 Message-ID: <56A88DFF.80208@gont.com.ar> Date: Wed, 27 Jan 2016 06:29:35 -0300 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.5.1 MIME-Version: 1.0 In-Reply-To: <56A873FB.5070002@globis.net> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit Archived-At: Cc: draft-ietf-6man-default-iids@tools.ietf.org, 6man X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 Jan 2016 09:41:31 -0000 Hi, Ray, On 01/27/2016 04:38 AM, Ray Hunter (v6ops) wrote: [....] > > If I filter through this document I can extract 4 threads of what it > intends to do: > > 1. DEPRECATE IPv6 Interface Identifiers constructed in Modified EUI-64 > format (as defined in https://tools.ietf.org/html/rfc4291#section-2.5.1) Strictly speaking, we simply recommend against Modified EUI64 as a default IID generation scheme. > 2. Mandate that RFC7217 SHOULD be the default method of generating IPv6 > Interface Identifiers to be used with IPv6 Stateless Address > Autoconfiguration (SLAAC) > > 3. Document how 1 & 2 impacts text of existing standards > > 4. When specifying how to transport IPv6 over various link media > (IPv6-over-FOO), alternatives or a substitute for RFC7217 MAY be > mandated, but these alternatives or the substitute MUST meet certain > requirements (which are met be RFC7217). Actually, what we tried to do is to spell out the properties that we want in the algorithm that is the default for IID generation with slaac. That, I could be equally as happy with just recommending RFC7217. > Now those are all things the I can support. > > But the current text doesn't do that: it updates existing standards > without providing a pathway for existing implementations using Interface > Identifiers constructed in Modified EUI-64 format to remain compliant > with IETF Standards Track RFCs. Not sure what you mean. Do you mean that: a) It is not clear in the document that each ipv6-over-foo should now do rfc7217 rather than modified eui64, or, b) That i we mandate rfc7217 in all of them, implementations that currently do modified eui64 would now become non-compliant? > To me, slightly restructuring the text around the 4 intentions would > make the intentions clearer, and avoid unintended consequences, like > making existing implementations non-compliant over an issue that quite > frankly doesn't actually break any functionality. Well, one could argue that: a) right now we do have a requirement to do modified eui-64, which does have negative security implications b) there are a number of the standards that concern security, without necessarily affecting interoperability. And particularly in the light of all the snowden thing, recommending something that does not allow trivial tracking seems to be warranted. That said, what would you propose as a way forward? Or, put another way, what the specific bit that concerns you? -- Fernando Gont e-mail: fernando@gont.com.ar || fgont@si6networks.com PGP Fingerprint: 7809 84F5 322E 45C7 F1C9 3945 96EE A9EF D076 FFF1 From nobody Wed Jan 27 01:41:46 2016 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 55AE31B37AD for ; Wed, 27 Jan 2016 01:41:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rX1TdnbkivZ3 for ; Wed, 27 Jan 2016 01:41:34 -0800 (PST) Received: from fgont.go6lab.si (fgont.go6lab.si [IPv6:2001:67c:27e4::14]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DD6CC1B3794 for ; Wed, 27 Jan 2016 01:41:30 -0800 (PST) Received: from [192.168.3.107] (unknown [181.165.125.191]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by fgont.go6lab.si (Postfix) with ESMTPSA id B7A69206A36; Wed, 27 Jan 2016 10:41:26 +0100 (CET) Subject: Re: draft-ietf-6man-default-iids v 09 To: "Ray Hunter (v6ops)" , draft-ietf-6man-default-iids@tools.ietf.org References: <56A7575A.2000707@globis.net> From: Fernando Gont X-Enigmail-Draft-Status: N1110 Message-ID: <56A89031.1090307@si6networks.com> Date: Wed, 27 Jan 2016 06:38:57 -0300 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.5.1 MIME-Version: 1.0 In-Reply-To: <56A7575A.2000707@globis.net> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit Archived-At: Cc: 6man X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 Jan 2016 09:41:38 -0000 Hi, Ray, On 01/26/2016 08:24 AM, Ray Hunter (v6ops) wrote: > I have read version 09 and support the intent of this draft. > > I have some editorial suggestions, and find the current formulation of > the requirements unnecessarily onerous. > > Suggested textual changes below: > > s/As a result of the aforementioned issues, this document recommends the > implementation of an alternative scheme ([RFC7217]) as the default > stable IID generation scheme for SLAAC, such that the aforementioned > issues are mitigated./To mitigate the aforementioned issues, this > document RECOMMENDS "A Method for Generating Semantically Opaque > Interface Identifiers with IPv6 Stateless Address Autoconfiguration > (SLAAC)" [RFC7217] as the default method for generating IPv6 Interface > Identifiers to be used with IPv6 Stateless Address Autoconfiguration > (SLAAC)./ mm... this was in the Intro? -- I wouldn't use normative language there.... > > /Generation of IPv6 Interface Identifiers with SLAAC/ > > IMVHO The title of Section 3 has potential to cause confusion. > > How about: > > s/Generation of IPv6 Interface Identifiers with SLAAC/Requirements for > Automatic IPv6 Addresses Generation Incorporating Interface Identifiers/ This seems confusing. Every address has an IID, so the "Incorporating.." pat seems superfluous. > In the requirements, nothing really immediately breaks if the algorithm > is non-compliant, so a SHOULD is more appropriate IMHO > I also find it problematic to specify how to test compliance with a "MUST". > This proposed standard as currently written might also make existing > implementations non-compliant with existing IETF standards, and thus > create a major commercial headache. > > suggest: > > s/Link layers MUST define a mechanism /Standards defining how IPv6 > packets are transmitted over a specific link layer technology SHOULD > define a mechanism / > > s/The resulting Interface Identifiers remain stable/The resulting > Interface Identifiers SHOULD remain stable/ [..] > > s/The resulting Interface Identifiers must be semantically opaque./The > resulting Interface Identifiers SHOULD be semantically opaque./ If anything, hw about just using a single normative wod in the introduction of the requirements, rather than one per requirement? Thanks! Best regards, -- Fernando Gont SI6 Networks e-mail: fgont@si6networks.com PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492 From nobody Wed Jan 27 02:08:28 2016 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 10DA71B37F2 for ; Wed, 27 Jan 2016 02:08:24 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 3.081 X-Spam-Level: *** X-Spam-Status: No, score=3.081 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FH_HOST_EQ_D_D_D_D=0.765, FH_HOST_EQ_D_D_D_DB=0.888, HELO_MISMATCH_NET=0.611, HOST_EQ_NL=1.545, HOST_EQ_STATIC=1.172, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZjNDXT902CYe for ; Wed, 27 Jan 2016 02:08:20 -0800 (PST) Received: from globis01.globis.net (092-111-140-212.static.chello.nl [92.111.140.212]) by ietfa.amsl.com (Postfix) with ESMTP id A3CF21B37EF for ; Wed, 27 Jan 2016 02:08:19 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by globis01.globis.net (Postfix) with ESMTP id 030E940170; Wed, 27 Jan 2016 11:08:19 +0100 (CET) X-Virus-Scanned: Debian amavisd-new at globis01.globis.net 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 7WPWGwh5QcCO; Wed, 27 Jan 2016 11:08:08 +0100 (CET) Received: from Rays-MacBook-Pro.local (178-84-244-32.dynamic.upc.nl [178.84.244.32]) (Authenticated sender: v6ops@globis.net) by globis01.globis.net (Postfix) with ESMTPA id C7DE340159; Wed, 27 Jan 2016 11:08:08 +0100 (CET) Message-ID: <56A89708.4040704@globis.net> Date: Wed, 27 Jan 2016 11:08:08 +0100 From: "Ray Hunter (v6ops)" User-Agent: Postbox 4.0.8 (Macintosh/20151105) MIME-Version: 1.0 To: Fernando Gont Subject: Re: draft-ietf-6man-default-iids v 09 References: <56A7575A.2000707@globis.net> <56A7CBF0.2070203@gmail.com> <56A873FB.5070002@globis.net> <56A88DFF.80208@gont.com.ar> In-Reply-To: <56A88DFF.80208@gont.com.ar> Content-Type: multipart/alternative; boundary="------------090105030508000201030804" Archived-At: Cc: draft-ietf-6man-default-iids@tools.ietf.org, 6man X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 Jan 2016 10:08:25 -0000 This is a multi-part message in MIME format. --------------090105030508000201030804 Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit > Fernando Gont > 27 Jan 2016 10:29 > Hi, Ray, > > On 01/27/2016 04:38 AM, Ray Hunter (v6ops) wrote: > [....] >> If I filter through this document I can extract 4 threads of what it >> intends to do: >> >> 1. DEPRECATE IPv6 Interface Identifiers constructed in Modified EUI-64 >> format (as defined in https://tools.ietf.org/html/rfc4291#section-2.5.1) > > Strictly speaking, we simply recommend against Modified EUI64 as a > default IID generation scheme. > If the intention was only a recommendation, then an Informational RFC "Modified EUI64 IIDs are considered harmful" would suffice IMHO. And I think that we have that already. > >> 2. Mandate that RFC7217 SHOULD be the default method of generating IPv6 >> Interface Identifiers to be used with IPv6 Stateless Address >> Autoconfiguration (SLAAC) >> >> 3. Document how 1& 2 impacts text of existing standards >> >> 4. When specifying how to transport IPv6 over various link media >> (IPv6-over-FOO), alternatives or a substitute for RFC7217 MAY be >> mandated, but these alternatives or the substitute MUST meet certain >> requirements (which are met be RFC7217). > > Actually, what we tried to do is to spell out the properties that we > want in the algorithm that is the default for IID generation with slaac. > > That, I could be equally as happy with just recommending RFC7217. > > >> Now those are all things the I can support. >> >> But the current text doesn't do that: it updates existing standards >> without providing a pathway for existing implementations using Interface >> Identifiers constructed in Modified EUI-64 format to remain compliant >> with IETF Standards Track RFCs. > > Not sure what you mean. > > Do you mean that: > > a) It is not clear in the document that each ipv6-over-foo should now do > rfc7217 rather than modified eui64, or, > > b) That i we mandate rfc7217 in all of them, implementations that > currently do modified eui64 would now become non-compliant? b) > >> To me, slightly restructuring the text around the 4 intentions would >> make the intentions clearer, and avoid unintended consequences, like >> making existing implementations non-compliant over an issue that quite >> frankly doesn't actually break any functionality. > > Well, one could argue that: > > a) right now we do have a requirement to do modified eui-64, which does > have negative security implications > > b) there are a number of the standards that concern security, without > necessarily affecting interoperability. And particularly in the light of > all the snowden thing, recommending something that does not allow > trivial tracking seems to be warranted. Agreed, but the "negativesecurity implications" haven't stopped the Internet functioning, or slowed adoption of IPv6. > > That said, what would you propose as a way forward? Or, put another way, > what the specific bit that concerns you? 1) I think the document structure could be formed around the intentions to make the document clearer and easier to read. I've already posted 4 suggested sections. 2) The text needs to be formulated so that existing implementations using modified EUI-64 IIDs remain standards compliant (so that existing products don't immediately get commercially disqualified), whilst still ensuring that 7217 (or functional equivalent) is preferred, and eventually replaces all use of modified EUI-64 IIDs. That to me calls out for an explicit "deprecate" of modified EUI-64 IIDs, and a definition of a suitable replacement. I don't see the word "deprecate" anywhere in the current text. > > Ray Hunter (v6ops) > 27 Jan 2016 08:38 > > >> Brian E Carpenter >> 26 Jan 2016 20:41 >> On 27/01/2016 00:24, Ray Hunter (v6ops) wrote: >>> I have read version 09 and support the intent of this draft. >> >> Ditto. I briefly checked all the specific updates to IPv6-over-foo and didn't find >> any obvious errors, but I think everybody should have a look at those. >> >>> I have some editorial suggestions, and find the current formulation of the requirements unnecessarily onerous. >> >> I disagree. I think stating the requirements explicitly is useful. > I gave plenty of feedback to Fernando whilst he wrote RFC7217, so I > know the content and background. > > If I filter through this document I can extract 4 threads of what it > intends to do: > > 1. DEPRECATE IPv6 Interface Identifiers constructed in Modified EUI-64 > format (as defined in https://tools.ietf.org/html/rfc4291#section-2.5.1) > > 2. Mandate that RFC7217 SHOULD be the default method of generating > IPv6 Interface Identifiers to be used with IPv6 Stateless Address > Autoconfiguration (SLAAC) > > 3. Document how 1 & 2 impacts text of existing standards > > 4. When specifying how to transport IPv6 over various link media > (IPv6-over-FOO), alternatives or a substitute for RFC7217 MAY be > mandated, but these alternatives or the substitute MUST meet certain > requirements (which are met be RFC7217). > > Now those are all things the I can support. > > But the current text doesn't do that: it updates existing standards > without providing a pathway for existing implementations using > Interface Identifiers constructed in Modified EUI-64 format to remain > compliant with IETF Standards Track RFCs. > > To me, slightly restructuring the text around the 4 intentions would > make the intentions clearer, and avoid unintended consequences, like > making existing implementations non-compliant over an issue that quite > frankly doesn't actually break any functionality. >> However, I do have one question. Should we add a note that use of the privacy >> extensions (RFC 4941) is RECOMMENDED for situations where resistance to tracking >> is more important than stable addresses? >> >> ... >>> Section 5 is out of scope IMHO and should be removed entirely. If admins manually assign static addresses they're on their own. >> >> I disagree that it's out of scope. On the contrary, giving this warning is very much >> in scope - if someone is reading this document, their likely default solution is >> manual addressing. I know such people; they're across the road in IT Services. >> >> Brian >> Ray Hunter (v6ops) >> 26 Jan 2016 12:24 >> I have read version 09 and support the intent of this draft. >> >> I have some editorial suggestions, and find the current formulation >> of the requirements unnecessarily onerous. >> >> Suggested textual changes below: >> >> s/As a result of the aforementioned issues, this document recommends >> the implementation of an alternative scheme ([RFC7217]) as the >> default stable IID generation scheme for SLAAC, such that the >> aforementioned issues are mitigated./To mitigate the aforementioned >> issues, this document RECOMMENDS "A Method for Generating >> Semantically Opaque Interface Identifiers with IPv6 Stateless Address >> Autoconfiguration (SLAAC)" [RFC7217] as the default method for >> generating IPv6 Interface Identifiers to be used with IPv6 Stateless >> Address Autoconfiguration (SLAAC)./ >> >> /Generation of IPv6 Interface Identifiers with SLAAC/ >> >> IMVHO The title of Section 3 has potential to cause confusion. >> >> How about: >> >> s/Generation of IPv6 Interface Identifiers with SLAAC/Requirements >> for Automatic IPv6 Addresses Generation Incorporating Interface >> Identifiers/ >> >> In the requirements, nothing really immediately breaks if the >> algorithm is non-compliant, so a SHOULD is more appropriate IMHO >> I also find it problematic to specify how to test compliance with a >> "MUST". >> This proposed standard as currently written might also make existing >> implementations non-compliant with existing IETF standards, and thus >> create a major commercial headache. >> >> suggest: >> >> s/Link layers MUST define a mechanism /Standards defining how IPv6 >> packets are transmitted over a specific link layer technology SHOULD >> define a mechanism / >> >> s/The resulting Interface Identifiers remain stable/The resulting >> Interface Identifiers SHOULD remain stable/ >> >> s/The resulting Interface Identifiers must change when addresses are >> configured for different prefixes./The resulting Interface >> Identifiers SHOULD change when addresses are configured for different >> prefixes./ >> >> s/it must be difficult for an outside entity to tell whether the >> addresses have been generated by the same host/it SHOULD be difficult >> for an outside entity to tell whether the addresses have been >> generated by the same host/ >> >> s/It must be difficult for an outside entity to predict the Interface >> Identifiers that will be generated by the algorithm,/It SHOULD be >> difficult for an outside entity to predict the Interface Identifiers >> that will be generated by the algorithm,/ >> >> s/The resulting Interface Identifiers must be semantically >> opaque./The resulting Interface Identifiers SHOULD be semantically >> opaque./ >> >> >> Section 5 is out of scope IMHO and should be removed entirely. If >> admins manually assign static addresses they're on their own. >> >> s/how each of the RFCs /how each of the following existing RFCs / >> >> > > Brian E Carpenter > 26 Jan 2016 20:41 > On 27/01/2016 00:24, Ray Hunter (v6ops) wrote: >> I have read version 09 and support the intent of this draft. > > Ditto. I briefly checked all the specific updates to IPv6-over-foo and didn't find > any obvious errors, but I think everybody should have a look at those. > >> I have some editorial suggestions, and find the current formulation of the requirements unnecessarily onerous. > > I disagree. I think stating the requirements explicitly is useful. > > However, I do have one question. Should we add a note that use of the privacy > extensions (RFC 4941) is RECOMMENDED for situations where resistance to tracking > is more important than stable addresses? > > ... >> Section 5 is out of scope IMHO and should be removed entirely. If admins manually assign static addresses they're on their own. > > I disagree that it's out of scope. On the contrary, giving this warning is very much > in scope - if someone is reading this document, their likely default solution is > manual addressing. I know such people; they're across the road in IT Services. > > Brian > Ray Hunter (v6ops) > 26 Jan 2016 12:24 > I have read version 09 and support the intent of this draft. > > I have some editorial suggestions, and find the current formulation of > the requirements unnecessarily onerous. > > Suggested textual changes below: > > s/As a result of the aforementioned issues, this document recommends > the implementation of an alternative scheme ([RFC7217]) as the default > stable IID generation scheme for SLAAC, such that the aforementioned > issues are mitigated./To mitigate the aforementioned issues, this > document RECOMMENDS "A Method for Generating Semantically Opaque > Interface Identifiers with IPv6 Stateless Address Autoconfiguration > (SLAAC)" [RFC7217] as the default method for generating IPv6 Interface > Identifiers to be used with IPv6 Stateless Address Autoconfiguration > (SLAAC)./ > > /Generation of IPv6 Interface Identifiers with SLAAC/ > > IMVHO The title of Section 3 has potential to cause confusion. > > How about: > > s/Generation of IPv6 Interface Identifiers with SLAAC/Requirements for > Automatic IPv6 Addresses Generation Incorporating Interface Identifiers/ > > In the requirements, nothing really immediately breaks if the > algorithm is non-compliant, so a SHOULD is more appropriate IMHO > I also find it problematic to specify how to test compliance with a > "MUST". > This proposed standard as currently written might also make existing > implementations non-compliant with existing IETF standards, and thus > create a major commercial headache. > > suggest: > > s/Link layers MUST define a mechanism /Standards defining how IPv6 > packets are transmitted over a specific link layer technology SHOULD > define a mechanism / > > s/The resulting Interface Identifiers remain stable/The resulting > Interface Identifiers SHOULD remain stable/ > > s/The resulting Interface Identifiers must change when addresses are > configured for different prefixes./The resulting Interface Identifiers > SHOULD change when addresses are configured for different prefixes./ > > s/it must be difficult for an outside entity to tell whether the > addresses have been generated by the same host/it SHOULD be difficult > for an outside entity to tell whether the addresses have been > generated by the same host/ > > s/It must be difficult for an outside entity to predict the Interface > Identifiers that will be generated by the algorithm,/It SHOULD be > difficult for an outside entity to predict the Interface Identifiers > that will be generated by the algorithm,/ > > s/The resulting Interface Identifiers must be semantically opaque./The > resulting Interface Identifiers SHOULD be semantically opaque./ > > > Section 5 is out of scope IMHO and should be removed entirely. If > admins manually assign static addresses they're on their own. > > s/how each of the RFCs /how each of the following existing RFCs / > > -- regards, RayH --------------090105030508000201030804 Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: 7bit

27 Jan 2016 10:29
Hi, Ray,

On 01/27/2016 04:38 AM, Ray Hunter (v6ops) wrote:
[....]

If I filter through this document I can extract 4 threads of what it
intends to do:

1. DEPRECATE IPv6 Interface Identifiers constructed in Modified EUI-64
format (as defined in https://tools.ietf.org/html/rfc4291#section-2.5.1)


Strictly speaking, we simply recommend against Modified EUI64 as a
default IID generation scheme.
If the intention was only a recommendation, then an Informational RFC "Modified EUI64 IIDs are considered harmful" would suffice IMHO. And I think that we have that already.




2. Mandate that RFC7217 SHOULD be the default method of generating IPv6
Interface Identifiers to be used with IPv6 Stateless Address
Autoconfiguration (SLAAC)

3. Document how 1 & 2 impacts text of existing standards

4. When specifying how to transport IPv6 over various link media
(IPv6-over-FOO), alternatives or a substitute for RFC7217 MAY be
mandated, but these alternatives or the substitute MUST meet certain
requirements (which are met be RFC7217).


Actually, what we tried to do is to spell out the properties that we
want in the algorithm that is the default for IID generation with slaac.

That, I could be equally as happy with just recommending RFC7217.




Now those are all things the I can support.

But the current text doesn't do that: it updates existing standards
without providing a pathway for existing implementations using Interface
Identifiers constructed in Modified EUI-64 format to remain compliant
with IETF Standards Track RFCs.


Not sure what you mean.

Do you mean that:

a) It is not clear in the document that each ipv6-over-foo should now do
rfc7217 rather than modified eui64, or,

b) That i we mandate rfc7217 in all of them, implementations that
currently do modified eui64 would now become non-compliant?
b)


To me, slightly restructuring the text around the 4 intentions would
make the intentions clearer, and avoid unintended consequences, like
making existing implementations non-compliant over an issue that quite
frankly doesn't actually break any functionality.


Well, one could argue that:

a) right now we do have a requirement to do modified eui-64, which does
have negative security implications

b) there are a number of the standards that concern security, without
necessarily affecting interoperability. And particularly in the light of
all the snowden thing, recommending something that does not allow
trivial tracking seems to be warranted.
Agreed, but the "negative security implications" haven't stopped the Internet functioning, or slowed adoption of IPv6.

That said, what would you propose as a way forward? Or, put another way,
what the specific bit that concerns you?

1) I think the document structure could be formed around the intentions to make the document clearer and easier to read. I've already posted 4 suggested sections.

2) The text needs to be formulated so that existing implementations using modified EUI-64 IIDs remain standards compliant (so that existing products don't immediately get commercially disqualified), whilst still ensuring that 7217 (or functional equivalent) is preferred, and eventually replaces all use of modified EUI-64 IIDs.

That to me calls out for an explicit "deprecate" of modified EUI-64 IIDs, and a definition of a suitable replacement.

I don't see the word "deprecate" anywhere in the current text.
27 Jan 2016 08:38


26 Jan 2016 20:41
On 27/01/2016 00:24, Ray Hunter (v6ops) wrote:

I have read version 09 and support the intent of this draft.


Ditto. I briefly checked all the specific updates to IPv6-over-foo and didn't find
any obvious errors, but I think everybody should have a look at those.


I have some editorial suggestions, and find the current formulation of the requirements unnecessarily onerous.


I disagree. I think stating the requirements explicitly is useful.
I gave plenty of feedback to Fernando whilst he wrote RFC7217, so I know the content and background.

If I filter through this document I can extract 4 threads of what it intends to do:

1. DEPRECATE IPv6 Interface Identifiers constructed in Modified EUI-64 format (as defined in https://tools.ietf.org/html/rfc4291#section-2.5.1)

2. Mandate that RFC7217 SHOULD be the default method of generating IPv6 Interface Identifiers to be used with IPv6 Stateless Address Autoconfiguration (SLAAC)

3. Document how 1 & 2 impacts text of existing standards

4. When specifying how to transport IPv6 over various link media (IPv6-over-FOO), alternatives or a substitute for RFC7217 MAY be mandated, but these alternatives or the substitute MUST meet certain requirements (which are met be RFC7217).

Now those are all things the I can support.

But the current text doesn't do that: it updates existing standards without providing a pathway for existing implementations using Interface Identifiers constructed in Modified EUI-64 format to remain compliant with IETF Standards Track RFCs.

To me, slightly restructuring the text around the 4 intentions would make the intentions clearer, and avoid unintended consequences, like making existing implementations non-compliant over an issue that quite frankly doesn't actually break any functionality.
However, I do have one question. Should we add a note that use of the privacy
extensions (RFC 4941) is RECOMMENDED for situations where resistance to tracking
is more important than stable addresses?

...

Section 5 is out of scope IMHO and should be removed entirely. If admins manually assign static addresses they're on their own.


I disagree that it's out of scope. On the contrary, giving this warning is very much
in scope - if someone is reading this document, their likely default solution is
manual addressing. I know such people; they're across the road in IT Services.

    Brian
26 Jan 2016 12:24
I have read version 09 and support the intent of this draft.

I have some editorial suggestions, and find the current formulation of the requirements unnecessarily onerous.

Suggested textual changes below:

s/As a result of the aforementioned issues, this document recommends the implementation of an alternative scheme ([RFC7217]) as the default stable IID generation scheme for SLAAC, such that the aforementioned issues are mitigated./To mitigate the aforementioned issues, this document RECOMMENDS "A Method for Generating Semantically Opaque Interface Identifiers with IPv6 Stateless Address Autoconfiguration (SLAAC)" [RFC7217] as the default method for generating IPv6 Interface Identifiers to be used with IPv6 Stateless Address Autoconfiguration (SLAAC)./

/Generation of IPv6 Interface Identifiers with SLAAC/

IMVHO The title of Section 3 has potential to cause confusion.

How about:

s/Generation of IPv6 Interface Identifiers with SLAAC/Requirements for Automatic IPv6 Addresses Generation Incorporating Interface Identifiers/

In the requirements, nothing really immediately breaks if the algorithm is non-compliant, so a SHOULD is more appropriate IMHO
I also find it problematic to specify how to test compliance with a "MUST".
This proposed standard as currently written might also make existing implementations non-compliant with existing IETF standards, and thus create a major commercial headache.

suggest:

s/Link layers MUST define a mechanism /Standards defining how IPv6 packets are transmitted over a specific link layer technology SHOULD define a mechanism /

s/The resulting Interface Identifiers remain stable/The resulting Interface Identifiers SHOULD remain stable/

s/The resulting Interface Identifiers must change when addresses are configured for different prefixes./The resulting Interface Identifiers SHOULD change when addresses are configured for different prefixes./

s/it must be difficult for an outside entity to tell whether the addresses have been generated by the same host/it SHOULD be difficult for an outside entity to tell whether the addresses have been generated by the same host/

s/It must be difficult for an outside entity to predict the Interface Identifiers that will be generated by the algorithm,/It SHOULD be difficult for an outside entity to predict the Interface Identifiers that will be generated by the algorithm,/

s/The resulting Interface Identifiers must be semantically opaque./The resulting Interface Identifiers SHOULD be semantically opaque./


Section 5 is out of scope IMHO and should be removed entirely. If admins manually assign static addresses they're on their own.

s/how each of the RFCs /how each of the following existing RFCs /



26 Jan 2016 20:41
On 27/01/2016 00:24, Ray Hunter (v6ops) wrote:

I have read version 09 and support the intent of this draft.


Ditto. I briefly checked all the specific updates to IPv6-over-foo and didn't find
any obvious errors, but I think everybody should have a look at those.


I have some editorial suggestions, and find the current formulation of the requirements unnecessarily onerous.


I disagree. I think stating the requirements explicitly is useful.

However, I do have one question. Should we add a note that use of the privacy
extensions (RFC 4941) is RECOMMENDED for situations where resistance to tracking
is more important than stable addresses?

...

Section 5 is out of scope IMHO and should be removed entirely. If admins manually assign static addresses they're on their own.


I disagree that it's out of scope. On the contrary, giving this warning is very much
in scope - if someone is reading this document, their likely default solution is
manual addressing. I know such people; they're across the road in IT Services.

    Brian
26 Jan 2016 12:24
I have read version 09 and support the intent of this draft.

I have some editorial suggestions, and find the current formulation of the requirements unnecessarily onerous.

Suggested textual changes below:

s/As a result of the aforementioned issues, this document recommends the implementation of an alternative scheme ([RFC7217]) as the default stable IID generation scheme for SLAAC, such that the aforementioned issues are mitigated./To mitigate the aforementioned issues, this document RECOMMENDS "A Method for Generating Semantically Opaque Interface Identifiers with IPv6 Stateless Address Autoconfiguration (SLAAC)" [RFC7217] as the default method for generating IPv6 Interface Identifiers to be used with IPv6 Stateless Address Autoconfiguration (SLAAC)./

/Generation of IPv6 Interface Identifiers with SLAAC/

IMVHO The title of Section 3 has potential to cause confusion.

How about:

s/Generation of IPv6 Interface Identifiers with SLAAC/Requirements for Automatic IPv6 Addresses Generation Incorporating Interface Identifiers/

In the requirements, nothing really immediately breaks if the algorithm is non-compliant, so a SHOULD is more appropriate IMHO
I also find it problematic to specify how to test compliance with a "MUST".
This proposed standard as currently written might also make existing implementations non-compliant with existing IETF standards, and thus create a major commercial headache.

suggest:

s/Link layers MUST define a mechanism /Standards defining how IPv6 packets are transmitted over a specific link layer technology SHOULD define a mechanism /

s/The resulting Interface Identifiers remain stable/The resulting Interface Identifiers SHOULD remain stable/

s/The resulting Interface Identifiers must change when addresses are configured for different prefixes./The resulting Interface Identifiers SHOULD change when addresses are configured for different prefixes./

s/it must be difficult for an outside entity to tell whether the addresses have been generated by the same host/it SHOULD be difficult for an outside entity to tell whether the addresses have been generated by the same host/

s/It must be difficult for an outside entity to predict the Interface Identifiers that will be generated by the algorithm,/It SHOULD be difficult for an outside entity to predict the Interface Identifiers that will be generated by the algorithm,/

s/The resulting Interface Identifiers must be semantically opaque./The resulting Interface Identifiers SHOULD be semantically opaque./


Section 5 is out of scope IMHO and should be removed entirely. If admins manually assign static addresses they're on their own.

s/how each of the RFCs /how each of the following existing RFCs /



--
regards,
RayH
--------------090105030508000201030804-- From nobody Wed Jan 27 03:35:45 2016 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C232D1A700F for ; Wed, 27 Jan 2016 03:35:43 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KLy3V18vYnFH for ; Wed, 27 Jan 2016 03:35:40 -0800 (PST) Received: from fgont.go6lab.si (fgont.go6lab.si [91.239.96.14]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4F7601A6FC0 for ; Wed, 27 Jan 2016 03:35:40 -0800 (PST) Received: from [192.168.2.101] (unknown [181.165.125.191]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by fgont.go6lab.si (Postfix) with ESMTPSA id 638A4206A25; Wed, 27 Jan 2016 12:35:36 +0100 (CET) Subject: Re: draft-ietf-6man-default-iids v 09 To: "Ray Hunter (v6ops)" , Fernando Gont References: <56A7575A.2000707@globis.net> <56A7CBF0.2070203@gmail.com> <56A873FB.5070002@globis.net> <56A88DFF.80208@gont.com.ar> <56A89708.4040704@globis.net> From: Fernando Gont X-Enigmail-Draft-Status: N1110 Message-ID: <56A8A844.8040307@si6networks.com> Date: Wed, 27 Jan 2016 08:21:40 -0300 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.5.1 MIME-Version: 1.0 In-Reply-To: <56A89708.4040704@globis.net> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit Archived-At: Cc: draft-ietf-6man-default-iids@tools.ietf.org, 6man X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 Jan 2016 11:35:43 -0000 Hi, Ray, On 01/27/2016 07:08 AM, Ray Hunter (v6ops) wrote: >> Hi, Ray, >> >> On 01/27/2016 04:38 AM, Ray Hunter (v6ops) wrote: >> [....] >>> If I filter through this document I can extract 4 threads of what it >>> intends to do: >>> >>> 1. DEPRECATE IPv6 Interface Identifiers constructed in Modified EUI-64 >>> format (as defined in https://tools.ietf.org/html/rfc4291#section-2.5.1) >> >> Strictly speaking, we simply recommend against Modified EUI64 as a >> default IID generation scheme. >> > If the intention was only a recommendation, then an Informational RFC > "Modified EUI64 IIDs are considered harmful" would suffice IMHO. And I > think that we have that already. It's not just a recommendation. Part of SLAAC is what you put in the IID, not just what you send on the wire. At the end of the day, if you do something really stupid like, say, having all implemetations set a hardcoded IID ("say, 1"), then stuff does break. -- So stuff does not break as long as IIDs are generated e.g. such that values have a uniform distribution. And if they change frequently, they can beome an operational nightmare (e.g., ACLs fail). So I disagree with that line of reasoning. >>> But the current text doesn't do that: it updates existing standards >>> without providing a pathway for existing implementations using Interface >>> Identifiers constructed in Modified EUI-64 format to remain compliant >>> with IETF Standards Track RFCs. >> >> Not sure what you mean. >> >> Do you mean that: >> >> a) It is not clear in the document that each ipv6-over-foo should now do >> rfc7217 rather than modified eui64, or, >> >> b) That i we mandate rfc7217 in all of them, implementations that >> currently do modified eui64 would now become non-compliant? > b) My two comments here are: 1) I can perfectly live with a s/MUST/SHOULD/. Would that address your concern? 2) At the end of the day, yes, if you change a rule, legacy equipment will not be "forward-compliant". But that's the whole point of standardizing stuff: defining where we want things to go. >>> To me, slightly restructuring the text around the 4 intentions would >>> make the intentions clearer, and avoid unintended consequences, like >>> making existing implementations non-compliant over an issue that quite >>> frankly doesn't actually break any functionality. >> >> Well, one could argue that: >> >> a) right now we do have a requirement to do modified eui-64, which does >> have negative security implications >> >> b) there are a number of the standards that concern security, without >> necessarily affecting interoperability. And particularly in the light of >> all the snowden thing, recommending something that does not allow >> trivial tracking seems to be warranted. > Agreed, but the "negativesecurity implications" haven't stopped the > Internet functioning, or slowed adoption of IPv6. ...nor has the implications of tobacco on the human body folks stop smoking... still doctors advice against smoking. >> That said, what would you propose as a way forward? Or, put another way, >> what the specific bit that concerns you? > > 1) I think the document structure could be formed around the intentions > to make the document clearer and easier to read. I've already posted 4 > suggested sections. Going back to your suggestions in this respect: > 1. DEPRECATE IPv6 Interface Identifiers constructed in Modified EUI-64 format (as defined in https://tools.ietf.org/html/rfc4291#section-2.5.1) We're not meaning to do that. We're just ecommending against thier use as a default iid generation algorithm. > 2. Mandate that RFC7217 SHOULD be the default method of generating IPv6 Interface Identifiers to be used with IPv6 Stateless Address Autoconfiguration (SLAAC) I think this bit is clear, already. > 3. Document how 1 & 2 impacts text of existing standards You mean how we patch the corresponding RFCs, or what? > 4. When specifying how to transport IPv6 over various link media (IPv6-over-FOO), alternatives or a substitute for RFC7217 MAY be mandated, but these alternatives or the substitute MUST meet certain requirements (which are met be RFC7217). This is essentially the same as 2. -- not sue why you imply this is a different item... Back to your message: > 2) The text needs to be formulated so that existing implementations > using modified EUI-64 IIDs remain standards compliant (so that existing > products don't immediately get commercially disqualified), whilst still > ensuring that 7217 (or functional equivalent) is preferred, and > eventually replaces all use of modified EUI-64 IIDs. Would this be addressed by s/MUST/SHOULD/g so to speak? > That to me calls out for an explicit "deprecate" of modified EUI-64 > IIDs, and a definition of a suitable replacement. > > I don't see the word "deprecate" anywhere in the current text. Actually the opposite. We don't want to ban modified eui-64 exactly for that reason. We just want to recommend against them (and recommend rfc7217 instead) as the default iid generation scheme. -- Fernando Gont SI6 Networks e-mail: fgont@si6networks.com PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492 From nobody Wed Jan 27 04:13:59 2016 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C7ADA1A87D7 for ; Wed, 27 Jan 2016 04:13:57 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vhLqci5ybl1Y for ; Wed, 27 Jan 2016 04:13:55 -0800 (PST) Received: from globis01.globis.net (mail.globis.net [IPv6:2001:470:1f15:62e::2]) by ietfa.amsl.com (Postfix) with ESMTP id A07F01A87DB for ; Wed, 27 Jan 2016 04:13:54 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by globis01.globis.net (Postfix) with ESMTP id A3CA240170; Wed, 27 Jan 2016 13:13:53 +0100 (CET) X-Virus-Scanned: Debian amavisd-new at globis01.globis.net 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 3WEE7ozPahN6; Wed, 27 Jan 2016 13:13:50 +0100 (CET) Received: from Rays-MacBook-Pro.local (178-84-244-32.dynamic.upc.nl [178.84.244.32]) (Authenticated sender: v6ops@globis.net) by globis01.globis.net (Postfix) with ESMTPA id 3AA4F40159; Wed, 27 Jan 2016 13:13:50 +0100 (CET) Message-ID: <56A8B47D.9010907@globis.net> Date: Wed, 27 Jan 2016 13:13:49 +0100 From: "Ray Hunter (v6ops)" User-Agent: Postbox 4.0.8 (Macintosh/20151105) MIME-Version: 1.0 To: Fernando Gont Subject: Re: draft-ietf-6man-default-iids v 09 References: <56A7575A.2000707@globis.net> <56A7CBF0.2070203@gmail.com> <56A873FB.5070002@globis.net> <56A88DFF.80208@gont.com.ar> <56A89708.4040704@globis.net> <56A8A844.8040307@si6networks.com> In-Reply-To: <56A8A844.8040307@si6networks.com> Content-Type: multipart/alternative; boundary="------------000307080902010108050509" Archived-At: Cc: draft-ietf-6man-default-iids@tools.ietf.org, 6man , Fernando Gont X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 Jan 2016 12:13:58 -0000 This is a multi-part message in MIME format. --------------000307080902010108050509 Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit > Fernando Gont > 27 Jan 2016 12:21 > Hi, Ray, > > On 01/27/2016 07:08 AM, Ray Hunter (v6ops) wrote: >>> Hi, Ray, >>> >>> On 01/27/2016 04:38 AM, Ray Hunter (v6ops) wrote: >>> [....] >>>> If I filter through this document I can extract 4 threads of what it >>>> intends to do: >>>> >>>> 1. DEPRECATE IPv6 Interface Identifiers constructed in Modified EUI-64 >>>> format (as defined in https://tools.ietf.org/html/rfc4291#section-2.5.1) >>> Strictly speaking, we simply recommend against Modified EUI64 as a >>> default IID generation scheme. >>> >> If the intention was only a recommendation, then an Informational RFC >> "Modified EUI64 IIDs are considered harmful" would suffice IMHO. And I >> think that we have that already. > > It's not just a recommendation. Part of SLAAC is what you put in the > IID, not just what you send on the wire. At the end of the day, if you > do something really stupid like, say, having all implemetations set a > hardcoded IID ("say, 1"), then stuff does break. -- So stuff does not > break as long as IIDs are generated e.g. such that values have a uniform > distribution. > > And if they change frequently, they can beome an operational nightmare > (e.g., ACLs fail). > > So I disagree with that line of reasoning. > > >>>> But the current text doesn't do that: it updates existing standards >>>> without providing a pathway for existing implementations using Interface >>>> Identifiers constructed in Modified EUI-64 format to remain compliant >>>> with IETF Standards Track RFCs. >>> Not sure what you mean. >>> >>> Do you mean that: >>> >>> a) It is not clear in the document that each ipv6-over-foo should now do >>> rfc7217 rather than modified eui64, or, >>> >>> b) That i we mandate rfc7217 in all of them, implementations that >>> currently do modified eui64 would now become non-compliant? >> b) > > My two comments here are: > > 1) I can perfectly live with a s/MUST/SHOULD/. Would that address your > concern? > > 2) At the end of the day, yes, if you change a rule, legacy equipment > will not be "forward-compliant". But that's the whole point of > standardizing stuff: defining where we want things to go. If purchasing departments state "equipment shall be compliant to RFC XXXX IETF Standards Track documents" then this will lead to acute problems. >>>> To me, slightly restructuring the text around the 4 intentions would >>>> make the intentions clearer, and avoid unintended consequences, like >>>> making existing implementations non-compliant over an issue that quite >>>> frankly doesn't actually break any functionality. >>> Well, one could argue that: >>> >>> a) right now we do have a requirement to do modified eui-64, which does >>> have negative security implications >>> >>> b) there are a number of the standards that concern security, without >>> necessarily affecting interoperability. And particularly in the light of >>> all the snowden thing, recommending something that does not allow >>> trivial tracking seems to be warranted. >> Agreed, but the "negativesecurity implications" haven't stopped the >> Internet functioning, or slowed adoption of IPv6. > > ...nor has the implications of tobacco on the human body folks stop > smoking... still doctors advice against smoking. We're in violent agreement that something has to be done, and even very much in line with the "what". We're just debating the "how". >>> That said, what would you propose as a way forward? Or, put another way, >>> what the specific bit that concerns you? >> 1) I think the document structure could be formed around the intentions >> to make the document clearer and easier to read. I've already posted 4 >> suggested sections. > > Going back to your suggestions in this respect: > >> 1. DEPRECATE IPv6 Interface Identifiers constructed in Modified EUI-64 format (as defined in https://tools.ietf.org/html/rfc4291#section-2.5.1) > > We're not meaning to do that. We're just ecommending against thier use > as a default iid generation algorithm. > If they aren't the default, why retain them at all? If EUI64 IIDs remain in use, then they're harmful. e.g in a chain of Internet cafes, you can't (easily) track any RFC7217 generated address across sites, but you can trivially track any (link local) EUI64 IID if it remains configured (in parallel to RFC7217). You can of course also track MAC addresses, but that's outside IETF remit. >> 2. Mandate that RFC7217 SHOULD be the default method of generating IPv6 Interface Identifiers to be used with IPv6 Stateless Address Autoconfiguration (SLAAC) > > I think this bit is clear, already. > >> 3. Document how 1& 2 impacts text of existing standards > > You mean how we patch the corresponding RFCs, or what? > Correct. How they'd be patched. As per current section 6 but clarifying the impact of applying 1+2, rather than actually immediately updating the standards docs. Today, if we apply section 6 literally as written (cut and paste), then any text specifying EUI64 IIDs disappears completely from all standards, and virtually all current code is non-compliant. >> 4. When specifying how to transport IPv6 over various link media (IPv6-over-FOO), alternatives or a substitute for RFC7217 MAY be mandated, but these alternatives or the substitute MUST meet certain requirements (which are met be RFC7217). > > This is essentially the same as 2. -- not sue why you imply this is a > different item... Nope. It's effect is more akin to https://tools.ietf.org/html/rfc6564, which does not itself define any new extension headers, but does set requirements on any future standards for extension headers. > > Back to your message: > >> 2) The text needs to be formulated so that existing implementations >> using modified EUI-64 IIDs remain standards compliant (so that existing >> products don't immediately get commercially disqualified), whilst still >> ensuring that 7217 (or functional equivalent) is preferred, and >> eventually replaces all use of modified EUI-64 IIDs. > > Would this be addressed by s/MUST/SHOULD/g so to speak? > Not really. Section 6 completely deletes current text, and replaces it with new text. > >> That to me calls out for an explicit "deprecate" of modified EUI-64 >> IIDs, and a definition of a suitable replacement. >> >> I don't see the word "deprecate" anywhere in the current text. > > Actually the opposite. We don't want to ban modified eui-64 exactly for > that reason. We just want to recommend against them (and recommend > rfc7217 instead) as the default iid generation scheme. That's not what's written in the current text IMHO. -- regards, RayH --------------000307080902010108050509 Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: 7bit

27 Jan 2016 12:21
Hi, Ray,

On 01/27/2016 07:08 AM, Ray Hunter (v6ops) wrote:

Hi, Ray,

On 01/27/2016 04:38 AM, Ray Hunter (v6ops) wrote:
[....]

If I filter through this document I can extract 4 threads of what it
intends to do:

1. DEPRECATE IPv6 Interface Identifiers constructed in Modified EUI-64
format (as defined in https://tools.ietf.org/html/rfc4291#section-2.5.1)

Strictly speaking, we simply recommend against Modified EUI64 as a
default IID generation scheme.


If the intention was only a recommendation, then an Informational RFC
"Modified EUI64 IIDs are considered harmful" would suffice IMHO. And I
think that we have that already.


It's not just a recommendation. Part of SLAAC is what you put in the
IID, not just what you send on the wire. At the end of the day, if you
do something really stupid like, say, having all implemetations set a
hardcoded IID ("say, 1"), then stuff does break. -- So stuff does not
break as long as IIDs are generated e.g. such that values have a uniform
distribution.

And if they change frequently, they can beome an operational nightmare
(e.g., ACLs fail).

So I disagree with that line of reasoning.



But the current text doesn't do that: it updates existing standards
without providing a pathway for existing implementations using Interface
Identifiers constructed in Modified EUI-64 format to remain compliant
with IETF Standards Track RFCs.

Not sure what you mean.

Do you mean that:

a) It is not clear in the document that each ipv6-over-foo should now do
rfc7217 rather than modified eui64, or,

b) That i we mandate rfc7217 in all of them, implementations that
currently do modified eui64 would now become non-compliant?

b)


My two comments here are:

1) I can perfectly live with a s/MUST/SHOULD/. Would that address your
concern?

2) At the end of the day, yes, if you change a rule, legacy equipment
will not be "forward-compliant". But that's the whole point of
standardizing stuff: defining where we want things to go.
If purchasing departments state "equipment shall be compliant to RFC XXXX IETF Standards Track documents" then this will lead to acute problems. 
To me, slightly restructuring the text around the 4 intentions would
make the intentions clearer, and avoid unintended consequences, like
making existing implementations non-compliant over an issue that quite
frankly doesn't actually break any functionality.

Well, one could argue that:

a) right now we do have a requirement to do modified eui-64, which does
have negative security implications

b) there are a number of the standards that concern security, without
necessarily affecting interoperability. And particularly in the light of
all the snowden thing, recommending something that does not allow
trivial tracking seems to be warranted.

Agreed, but the "negativesecurity implications" haven't stopped the
Internet functioning, or slowed adoption of IPv6.


...nor has the implications of tobacco on the human body folks stop
smoking... still doctors advice against smoking.
We're in violent agreement that something has to be done, and even very much in line with the "what".

We're just debating the "how".

 
That said, what would you propose as a way forward? Or, put another way,
what the specific bit that concerns you?

1) I think the document structure could be formed around the intentions
to make the document clearer and easier to read. I've already posted 4
suggested sections.


Going back to your suggestions in this respect:


1. DEPRECATE IPv6 Interface Identifiers constructed in Modified EUI-64 format (as defined in https://tools.ietf.org/html/rfc4291#section-2.5.1)


We're not meaning to do that. We're just ecommending against thier use
as a default iid generation algorithm.
If they aren't the default, why retain them at all?

If EUI64 IIDs remain in use, then they're harmful.

e.g in a chain of Internet cafes, you can't (easily) track any RFC7217 generated address across sites, but you can trivially track any (link local) EUI64 IID if it remains configured (in parallel to RFC7217). You can of course also track MAC addresses, but that's outside IETF remit.
 
2. Mandate that RFC7217 SHOULD be the default method of generating IPv6 Interface Identifiers to be used with IPv6 Stateless Address Autoconfiguration (SLAAC)


I think this bit is clear, already.




3. Document how 1 & 2 impacts text of existing standards


You mean how we patch the corresponding RFCs, or what?





Correct.



How they'd be patched.



As per current section 6 but clarifying the impact of applying 1+2, 
rather than actually immediately updating the standards docs.



Today, if we apply section 6 literally as written (cut and paste), then 
any text specifying EUI64 IIDs disappears completely from all standards,
 and virtually all current code is non-compliant.





  
4. When specifying how to transport IPv6 over various link media (IPv6-over-FOO), alternatives or a substitute for RFC7217 MAY be mandated, but these alternatives or the substitute MUST meet certain requirements (which are met be RFC7217).


This is essentially the same as 2. -- not sue why you imply this is a
different item...




Nope. It's effect is more akin to https://tools.ietf.org/html/rfc6564, 
which does not itself define any new extension headers, but does set 
requirements on any future standards for extension headers.





  

    

Back to your message:




2) The text needs to be formulated so that existing implementations
using modified EUI-64 IIDs remain standards compliant (so that existing
products don't immediately get commercially disqualified), whilst still
ensuring that 7217 (or functional equivalent) is preferred, and
eventually replaces all use of modified EUI-64 IIDs.


Would this be addressed by s/MUST/SHOULD/g so to speak?





Not really. Section 6 completely deletes current text, and replaces it 
with new text.



  

    




That to me calls out for an explicit "deprecate" of modified EUI-64
IIDs, and a definition of a suitable replacement.

I don't see the word "deprecate" anywhere in the current text.


Actually the opposite. We don't want to ban modified eui-64 exactly for
that reason. We just want to recommend against them (and recommend
rfc7217 instead) as the default iid generation scheme.




That's not what's written in the current text IMHO.




-- 


regards,

RayH

  





--------------000307080902010108050509--


From nobody Wed Jan 27 04:48:49 2016
Return-Path: 
X-Original-To: ipv6@ietfa.amsl.com
Delivered-To: ipv6@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5AC961A88C7 for ; Wed, 27 Jan 2016 04:48:48 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.901
X-Spam-Level: 
X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id As9-ScGK5Wjr for ; Wed, 27 Jan 2016 04:48:42 -0800 (PST)
Received: from fgont.go6lab.si (fgont.go6lab.si [IPv6:2001:67c:27e4::14]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 858701A88B8 for ; Wed, 27 Jan 2016 04:48:42 -0800 (PST)
Received: from [192.168.2.101] (unknown [181.165.125.191]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by fgont.go6lab.si (Postfix) with ESMTPSA id DC6A3206A25; Wed, 27 Jan 2016 13:48:36 +0100 (CET)
Subject: Re: draft-ietf-6man-default-iids v 09
To: "Ray Hunter (v6ops)" 
References: <56A7575A.2000707@globis.net> <56A7CBF0.2070203@gmail.com> <56A873FB.5070002@globis.net> <56A88DFF.80208@gont.com.ar> <56A89708.4040704@globis.net> <56A8A844.8040307@si6networks.com> <56A8B47D.9010907@globis.net>
From: Fernando Gont 
X-Enigmail-Draft-Status: N1110
Message-ID: <56A8BC44.2060008@si6networks.com>
Date: Wed, 27 Jan 2016 09:47:00 -0300
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.5.1
MIME-Version: 1.0
In-Reply-To: <56A8B47D.9010907@globis.net>
Content-Type: text/plain; charset=windows-1252
Content-Transfer-Encoding: 7bit
Archived-At: 
Cc: draft-ietf-6man-default-iids@tools.ietf.org, 6man , Fernando Gont 
X-BeenThere: ipv6@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "IPv6 Maintenance Working Group \(6man\)" 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 27 Jan 2016 12:48:48 -0000

Hi, Ray,

On 01/27/2016 09:13 AM, Ray Hunter (v6ops) wrote:
>>
>> My two comments here are:
>>
>> 1) I can perfectly live with a s/MUST/SHOULD/. Would that address your
>> concern?
>>
>> 2) At the end of the day, yes, if you change a rule, legacy equipment
>> will not be "forward-compliant". But that's the whole point of
>> standardizing stuff: defining where we want things to go.
> If purchasing departments state "equipment shall be compliant to RFC
> XXXX IETF Standards Track documents" then this will lead to acute problems.

Well, that's already the case is they require an implementation to be
compliant with RFC7217.

With that in mind, it's impossible to do any work in the IETF. Clearly,
one cannot require an implementation for something that was published
earlier last month.



>>>> That said, what would you propose as a way forward? Or, put another way,
>>>> what the specific bit that concerns you?
>>> 1) I think the document structure could be formed around the intentions
>>> to make the document clearer and easier to read. I've already posted 4
>>> suggested sections.
>>
>> Going back to your suggestions in this respect:
>>
>>> 1. DEPRECATE IPv6 Interface Identifiers constructed in Modified EUI-64 format (as defined in https://tools.ietf.org/html/rfc4291#section-2.5.1)
>>
>> We're not meaning to do that. We're just ecommending against thier use
>> as a default iid generation algorithm.
>>
> If they aren't the default, why retain them at all?

1) The default should be safe... then you can override (if available)
and shoot yourself in the foot

2) If we recommend (say, "SHOULD"), RFC7217, and there are nodes that
not implement it, then they will probably do modified-eui64 -- i.e.,
what they do now.



> If EUI64 IIDs remain in use, then they're harmful.
> 
> e.g in a chain of Internet cafes, you can't (easily) track any RFC7217
> generated address across sites, but you can trivially track any (link
> local) EUI64 IID if it remains configured (in parallel to RFC7217). You
> can of course also track MAC addresses, but that's outside IETF remit.

RFC7217 is alternative to modified eui64, and 7217 says that if you use
it, you shouldn't use anything else for slaac stable addresses.  --
i.e., theres not going to be simultaneous use of rfc7217 and modiied eui64.

Besides, if you deprecate modiied eui64, then rfc7217 becomes even more
mandatory.. Otherwise, how does a node do slaac?



>>> 2. Mandate that RFC7217 SHOULD be the default method of generating IPv6 Interface Identifiers to be used with IPv6 Stateless Address Autoconfiguration (SLAAC)
>>
>> I think this bit is clear, already.
>>
>>> 3. Document how 1 & 2 impacts text of existing standards
>>
>> You mean how we patch the corresponding RFCs, or what?
>>
> Correct.
> 
> How they'd be patched.
> 
> As per current section 6 but clarifying the impact of applying 1+2,
> rather than actually immediately updating the standards docs.
> 
> Today, if we apply section 6 literally as written (cut and paste), then
> any text specifying EUI64 IIDs disappears completely from all standards,
> and virtually all current code is non-compliant.

No, it doesn't. THe modified eui64 bit remains in an appendix of rfc4291bis.

"Current code" will always be compliant with "the specs of the time the
product was produced".

Clearly, if we change a spec, legacy nodes will not be compliant...
otherwise, we'd not be changing the spec. i.e., this happens "by
definition", so to speak.


>>> 4. When specifying how to transport IPv6 over various link media (IPv6-over-FOO), alternatives or a substitute for RFC7217 MAY be mandated, but these alternatives or the substitute MUST meet certain requirements (which are met be RFC7217).
>>
>> This is essentially the same as 2. -- not sue why you imply this is a
>> different item...
> Nope. It's effect is more akin to https://tools.ietf.org/html/rfc6564,
> which does not itself define any new extension headers, but does set
> requirements on any future standards for extension headers.

Do you mean "for future ipv6-over-foo" or for the existing ipv6 over foo?



>> Back to your message:
>>
>>> 2) The text needs to be formulated so that existing implementations
>>> using modified EUI-64 IIDs remain standards compliant (so that existing
>>> products don't immediately get commercially disqualified), whilst still
>>> ensuring that 7217 (or functional equivalent) is preferred, and
>>> eventually replaces all use of modified EUI-64 IIDs.
>>
>> Would this be addressed by s/MUST/SHOULD/g so to speak?
>>
> Not really. Section 6 completely deletes current text, and replaces it
> with new text.

How do you expect to change recommendations without deleting text from
the specs that we're updating? -- I don't really follow.



>>> That to me calls out for an explicit "deprecate" of modified EUI-64
>>> IIDs, and a definition of a suitable replacement.
>>>
>>> I don't see the word "deprecate" anywhere in the current text.
>>
>> Actually the opposite. We don't want to ban modified eui-64 exactly for
>> that reason. We just want to recommend against them (and recommend
>> rfc7217 instead) as the default iid generation scheme.
> That's not what's written in the current text IMHO.

Do we ever say we're deprecating modified eui64?

P.S.: At the time, I had an I-D entitled "deprecating eui64" or the
like, and the title was explicitly changed because of this...

Thanks!

Cheers,
-- 
Fernando Gont
SI6 Networks
e-mail: fgont@si6networks.com
PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492





From nobody Wed Jan 27 10:55:01 2016
Return-Path: 
X-Original-To: ipv6@ietfa.amsl.com
Delivered-To: ipv6@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9D5A81B2B49 for ; Wed, 27 Jan 2016 10:54:59 -0800 (PST)
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=-1.9,  DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LH1YSTx19eUP for ; Wed, 27 Jan 2016 10:54:58 -0800 (PST)
Received: from mail-pa0-x230.google.com (mail-pa0-x230.google.com [IPv6:2607:f8b0:400e:c03::230]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 871AB1B2B55 for ; Wed, 27 Jan 2016 10:54:58 -0800 (PST)
Received: by mail-pa0-x230.google.com with SMTP id yy13so8876097pab.3 for ; Wed, 27 Jan 2016 10:54:58 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;  h=subject:to:references:cc:from:organization:message-id:date :user-agent:mime-version:in-reply-to:content-type :content-transfer-encoding; bh=pHpLNKPIP3YzT93ROFEoqSH+/PBwrtDNd206Aubu7/g=; b=XFjmpOSk1fMSgglebjuGy1Dc6KXWB3vtrTMktBOhRaL2iO3BGOZ0IyjU61yFqfggBH tn0Y9UzD0uvVu+LEbcnvgvi+iCmONU+35rvkAQrRnmkx0yFh/rcEfTJrfEidopXHAE4e fIEWVbDNtiY/DZJva7MQesYPoXbwGDBoqdaME0KMwGM/ze+/J9F4H/aFNLKv4EpyBZje FZDw9H0eQ5MhXqQ2E7hnK2BJvSxzlx7/FG59bUq/GrloDZAwes3lwCncUfjtOA0KxSBR DZwuSRZdMcphoYL+Opa1bOpHqD+vHCB+7cry8IawctEhkmLN3puHHDUguHP1c0mTvcz/ Vr5g==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:subject:to:references:cc:from:organization :message-id:date:user-agent:mime-version:in-reply-to:content-type :content-transfer-encoding; bh=pHpLNKPIP3YzT93ROFEoqSH+/PBwrtDNd206Aubu7/g=; b=bNG+YWwMaqn53p5WF82YREakJUYe8buKr2LjsiG9NCdXI8yCsuQgtkHrzB+wflhwru zDWMsmMu9LXRTuNYDge87+8f/wAHKP0OfUIvXUZVK5MUNDB2BxGLNVjWEJ0XvyO2yzJI V7W0rz1IdqQo651HQFT1AJk/x205DYo1gyy0J/6Vfa5hEWXQ35qsegMj8Rp7jlpxJbgR Ndi9i/RScTbR9WqwTj3YbqlqyeCU4lBaqn6XCCDHma6NcW3YFutx4qAguc6dklkgZCIW 9DJptajxYEVXHbp+5BNIXWb6EpAGyykaym/c8/6hOea+zCSEo7QMbYSsHadVVqwb6RAi u93g==
X-Gm-Message-State: AG10YOSJ7xqgF+uvRAEuumbVm5B7l819ysBl/Q0BnV6kMUJY3M0co018VDqt3hEANyHb8A==
X-Received: by 10.66.236.129 with SMTP id uu1mr44871334pac.158.1453920898122;  Wed, 27 Jan 2016 10:54:58 -0800 (PST)
Received: from ?IPv6:2406:e007:756a:1:28cc:dc4c:9703:6781? ([2406:e007:756a:1:28cc:dc4c:9703:6781]) by smtp.gmail.com with ESMTPSA id m75sm10738794pfj.38.2016.01.27.10.54.54 (version=TLSv1/SSLv3 cipher=OTHER); Wed, 27 Jan 2016 10:54:56 -0800 (PST)
Subject: Re: draft-ietf-6man-default-iids v 09
To: "Ray Hunter (v6ops)" 
References: <56A7575A.2000707@globis.net> <56A7CBF0.2070203@gmail.com> <56A873FB.5070002@globis.net>
From: Brian E Carpenter 
Organization: University of Auckland
Message-ID: <56A91286.9000602@gmail.com>
Date: Thu, 28 Jan 2016 07:55:02 +1300
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.5.1
MIME-Version: 1.0
In-Reply-To: <56A873FB.5070002@globis.net>
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit
Archived-At: 
Cc: draft-ietf-6man-default-iids@tools.ietf.org, 6man 
X-BeenThere: ipv6@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "IPv6 Maintenance Working Group \(6man\)" 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 27 Jan 2016 18:54:59 -0000

Taking the bull by the horns:
On 27/01/2016 20:38, Ray Hunter (v6ops) wrote:

...
> But the current text doesn't do that: it updates existing standards without providing a pathway for existing implementations
> using Interface Identifiers constructed in Modified EUI-64 format to remain compliant with IETF Standards Track RFCs.

I believe that is correct. While it doesn't formally deprecate Modified EUI-64,
it does remove it from all the IPv6-over-foo standards.

> 
> To me, slightly restructuring the text around the 4 intentions would make the intentions clearer, and avoid unintended
> consequences, like making existing implementations non-compliant over an issue that quite frankly doesn't actually break any
> functionality.

I don't think it's an unintended consequence at all. On the contrary, I think it's
exactly what we should do. And yes, it will hopefully affect future procurements.

This will *not* break any running code, except if someone is making false deductions
from IID formats. It's years since Windows stopped using Modified EUI-64 by default,
and we seem to have survived that. (There are a couple of observational studies in
published research that make deductions from IID formats, but is anyone really running
tools that contain logic like "if IID looks like Modified EUI-64 then do this, else
do that"?)

   Brian


From nobody Wed Jan 27 11:50:47 2016
Return-Path: 
X-Original-To: ipv6@ietfa.amsl.com
Delivered-To: ipv6@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 36DC01B305E; Wed, 27 Jan 2016 11:50:44 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.378
X-Spam-Level: 
X-Spam-Status: No, score=-0.378 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FM_FORGED_GMAIL=0.622, FREEMAIL_FROM=0.001, J_CHICKENPOX_51=0.6, MIME_8BIT_HEADER=0.3, SPF_PASS=-0.001] autolearn=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hsfMNapckuGs; Wed, 27 Jan 2016 11:50:42 -0800 (PST)
Received: from mail-ig0-x229.google.com (mail-ig0-x229.google.com [IPv6:2607:f8b0:4001:c05::229]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 410171B305D; Wed, 27 Jan 2016 11:50:42 -0800 (PST)
Received: by mail-ig0-x229.google.com with SMTP id z14so91779292igp.1; Wed, 27 Jan 2016 11:50:42 -0800 (PST)
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=dClkdn9iam2RzScYaUo5EJoWvTxh+8XZZk1hTZKUphI=; b=HQbKXJ6fuZyxo8jXaVu+T8S8hqKvKDWV4b2CWjfc1BuTwEsy7dz5V1Vnj501tEKqwf c1VUoBKS0qFoOTk6X+5uY8IM4hhGZv+QHg4URGAfeZVOKAKsr/1KN0cNJQko7VDjPtSd tP8OXLMB3PpHtFU75g2p/H8jcYAG3GtcqNDkUIboEoNn5f66mc1YLO5mR7PCn7mkarl8 n8iDNnM7d2OZkqgJTyC6AquiylEo3gzTvFwmd1AvAlmIol/JAxBaHd6hqva1h3BtUPLn OeL/rCqFZyqeHSI9FRpFqSm/Y6HUuucbB+87vz6Xv4t327r0fNKOZPxIW3Laj7Q4HAp3 s8VA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:sender:in-reply-to:references:date :message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=dClkdn9iam2RzScYaUo5EJoWvTxh+8XZZk1hTZKUphI=; b=Xg3cIlvxggFQE9vzObUiqiMVwesyK0N/thx4XZ3OZp9FDwqjHdyt9vEJMnionCFihl kMlU0Io+FN8yOwUaDyzW8G9c92l5z4jTAEltnYZ4DeX+266iSpppjkqewU44riCeO58Z Yd7g2qTYRpQog+JiBS1fQrm3wfsuvUBY6TwFRYFVWs95JZjtrzO19HBGL2kKets7KUsn aGsfEiRQ8J/JGuiptlaHJo/xbxbUwvICF+ttB20qELfwpQGww+wLqvovWLU5yCyJse8V bXtWbrmFtwM+WPj7u4UbyCRRagIJi5yR915rUeXWNi4XecD/lOL76qMphXgyvcQy5lcZ 7Faw==
X-Gm-Message-State: AG10YOQotu5j3u/fJzJbCQT1+GsV6bOfEcyrg9u+h3ugM7aqx4lqFNamLHtFgvfKz56cQzWe/BMUMOAg+9mvLQ==
MIME-Version: 1.0
X-Received: by 10.50.155.106 with SMTP id vv10mr28399886igb.41.1453924241604;  Wed, 27 Jan 2016 11:50:41 -0800 (PST)
Sender: jinmei.tatuya@gmail.com
Received: by 10.107.136.90 with HTTP; Wed, 27 Jan 2016 11:50:41 -0800 (PST)
In-Reply-To: 
References:   
Date: Wed, 27 Jan 2016 11:50:41 -0800
X-Google-Sender-Auth: XO7jGde8RcZYj0I8ypim5574MIU
Message-ID: 
Subject: Re: draft-ietf-6man-rfc4291bis
From: =?UTF-8?B?56We5piO6YGU5ZOJ?= 
To: Sander Steffann 
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
Archived-At: 
Cc: yhb@ruijie.com.cn, 6man WG , draft-ietf-6man-rfc4291bis@ietf.org
X-BeenThere: ipv6@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "IPv6 Maintenance Working Group \(6man\)" 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 27 Jan 2016 19:50:44 -0000

At Fri, 22 Jan 2016 14:17:52 +0100,
Sander Steffann  wrote:

> It has always been interesting that a /10 is reserved for link-local
> while only a /64 is commonly used. The 54 bits in the middle could
> be anything, but they are always 0. FreeBSD even uses that
> assumption to store the scope-id in those bits:

> https://www.freebsd.org/doc/en_US.ISO8859-1/books/developers-handbook/ipv=
6.html#ipv6-scope-index
>
> I *did* go WTF when Gert D=C3=B6ring pointed that out to me...

We all knew it was an ugly hack, and we wouldn't implement it that way
if we wrote the stack today.  But any long-lived thing like BSDs and
IPv6 has historical context.  I'd say it's a bit unfair to just go WTF
without at least learning that.  In case you're willing to learn it,
I'm pasting relevant text below from a book I co-authored.

--
JINMEI, Tatuya

Since the 16-bit field embedding the zone ID should be 0 in the wire
according to the address format, using this field for implementation
specific purpose may be justified as long as it is restricted inside
the kernel.  Still, you may wonder why we need to be bothered with the
strange form while the sockaddr_in6{} structure should be able to
contain complete information in a cleaner way.

This is primarily for historical and compatibility reasons.  At the
time the KAME project started, the sockaddr_in6{} structure did not
have the sin6_scope_id field (see RFC2133), and link-local addresses
had to be disambiguated in an implementation-dependent manner.  The
embedded form was a KAME-specific workaround to this problem.  It was
used anywhere in the kernel for representing IPv6 addresses, including
some protocol independent parts of the kernel like the routing table
or the routing socket API.

Since then, several applications have been developed, and some of
those had to care about the embedded form directly.  Among those were
routing tools such as route6d, a RIPng daemon (which will be described
in Chapter 1 of Book-II).  Such programs had to deal with the embedded
form of IPv6 link-local addresses through the routing socket.  Another
example is system administration tools that directly refer to the
kernel memory, such as the netstat program.  These applications needed
to clear the embedded zone ID and set the sin6_scope_id correctly
before showing the address to the user.

In 1999, RFC2553 solved the ambiguity issue by adding the
sin6_scope_id field to the sockaddr_in6{} structure.  The KAME and BSD
implementations supported the new API, and updated most IPv6-related
interfaces accordingly, including input and output system calls on an
AF_INET6 socket.  Unfortunately, however, it seemed too late to update
the routing table structure and the routing socket interface: routing
tools were so tightly associated with the embedded form; on the other
hand, the routing interface is generally protocol-independent and the
KAME developers did not think it acceptable for the BSD community to
introduce IPv6-specific changes to such a general interface.

Therefore, the current kernel implementation adopts a "hybrid"
approach as shown in Figure XX (omitted here).  The IPv6 protocol
stack in the kernel generally maintains IPv6 addresses in the
sockaddr_in6{} structure with the zone ID being both embedded in the
sin6_addr field and specified in the sin6_scope_id field.  In the
protocol independent routing table, the zone ID is only embedded
within the sin6_addr field.  The IPv6 protocol stack is responsible
for clearing or restoring the sin6_scope_id field when it deals with
the routing table.  The same relationship applies to the protocol
independent interface address structures, since these are tightly
related to the routing table and can often be exchanged with the
routing table transparently.

Ordinary applications, when they ever need to care about address
scopes, can and should only be aware of the sin6_scope_id field.  They
must not directly refer to or set the second 16-bit of an IPv6 address
assuming the embedded form.  When an application passes an IPv6
address through a standard AF_INET6 socket (e.g., as the packet's
destination address), the IPv6 protocol stack will convert the
structure into its internal "hybrid" form.  Similarly, when the kernel
passes an IPv6 address to an application, the protocol stack will make
sure that the embedded part is cleared and the sin6_scope_id field is
set appropriately.

Finally, applications that need to interact with the kernel part
maintaining the embedded form are required special handling by
themselves.  They should directly interpret the embedded form assuming
the kernel implementation, and, when necessary, convert the address in
the non-embedded form using the standard sin6_scope_id field before
passing the address to the kernel through the AF_INET6 socket
interface.  Some management tools that directly access the kernel
memory image via the kvm interface or IPv6 routing daemons using the
routing socket belong to this category.

Another effect of the embedded form is that network masks can be
contiguous.  For example, we can apply the natural 64-bit contiguous
mask for FE80:1:: to represent "FE80::%1/64".  On the other hand, if
the link identifier were in fact stored in the sin6_scope_id field, we
would need a non-contiguous mask for the separate field.  This is not
a big deal, though, since BSD's routing routines can naturally handle
non-contiguous masks.

In any event, applications should generally avoid relying on the
kernel specific details whenever possible.  Indeed, the applications
should not even be aware of such details.  There are plenty of reasons
for this:

- The first obvious reason is portability.  Since the embedded form is
  specific to the KAME and BSD kernel implementations, applications that
  take an action relying on that particular form will not work on other
  operating systems.
- Secondly, address ambiguity is not specific to link-local or
  interface-local addresses; any non-global multicast addresses are
  inherently ambiguous.  Thus, an ad-hoc check specific to
  interface-local or link-local scopes assuming the embedded form can be
  the source of a bug in the future.  It should also be noted that we
  cannot embed the zone ID for unicast prefix based multicast addresses,
  which does not have enough space in the address format.
- Third, this is vulnerable to future changes of the embedded form in
  the kernel.  For example, the embedded position may change or the
  zone ID may not actually be the interface index, even though such a
  drastic change will unlikely be made due to compatibility issues.
- Fourth, we may not always be able to
  assume the embedded field is zero for a packet received from the
  wire.
  In fact, there is a new standard format of link-local multicast
  addresses that requires the second 16-bit of the address be a non-0 value
  [RFC4489].
  Additionally, while it is moot whether other link-local addresses
  with the second 16-bit field being non-0 is valid or not in terms of
  the address architecture specification, it would at least make the
  validation procedure more complex with the embedded internal form.
- Finally, the embedded field is a 16-bit integer, while the
  standard sin6_scope_id field is 32-bit.  This mismatch may
  cause annoying corner case or error handling.


From nobody Wed Jan 27 14:05:57 2016
Return-Path: 
X-Original-To: ipv6@ietfa.amsl.com
Delivered-To: ipv6@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id ABDA81B2BF8; Wed, 27 Jan 2016 14:05:55 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.978
X-Spam-Level: 
X-Spam-Status: No, score=-0.978 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FM_FORGED_GMAIL=0.622, FREEMAIL_FROM=0.001, MIME_8BIT_HEADER=0.3, SPF_PASS=-0.001] autolearn=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id g_zOn4frcfdn; Wed, 27 Jan 2016 14:05:54 -0800 (PST)
Received: from mail-io0-x22c.google.com (mail-io0-x22c.google.com [IPv6:2607:f8b0:4001:c06::22c]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 85DC91B2BE0; Wed, 27 Jan 2016 14:05:54 -0800 (PST)
Received: by mail-io0-x22c.google.com with SMTP id f81so34771748iof.0; Wed, 27 Jan 2016 14:05:54 -0800 (PST)
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=KU0XWoV4aCLac10Y6gH0Kpkh+dnt6LkfL02YieMvglA=; b=PggmpuAcLZEtzbQzdDfWrxrhdE81ImGPtf6sBY2H/5z4OHeTnGShbouN31io6U26+c iTokJTG3SuXS0Z+BgA3Ifu8IjBAbagZ3sTuX4YZVOcG1QSXdcyRwIUth680mDzZSXtVB VSozHu53Jdsf9HQQMAUsWwprolSn+0bqt0T5Cxsqujduf5Tv6sIM+KFsVv7XgIzttRBn qJ/NQfK+m0RCgQaasA90cUIhqNOYbMlt22hGqKSALaOXPXm8CLbJNJ325KBw/anOV2BD vq0vp0C2dW+2sfLVe+kQcBX+FvUpSpKUUnFTCEskQak6lUf11ZA7/V6NnhtuqJFyfmsa 2GXw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:sender:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=KU0XWoV4aCLac10Y6gH0Kpkh+dnt6LkfL02YieMvglA=; b=KshVP5lYNQqFeOIzQmBUS7gOpVdamVtIi0tgaY/jXpCqK6M56NnGQET+MX1/rdwJ5E nEKnz4Hvrp8k4atlzuHUxKj4BGKWdxjKXXzKyI3FVWOWKqgYkuWZmSDEEb+n6irs1P2n RrkF1e1JFDIUnrAxrylxnLdrP0jBfdzgCzIK4WNmtQMO4pjrajyCWoGubHFw8VRTSalt GuTvghhinVtEMnBFvWuoDy5tdQUo/wENcNlW8nEsoMZCP3nSKrVnszYx4YLU0hPKIiD2 dLaOMqSzaYv2H/22oTeyaFuJS7t6KGkVi3iF3C296bMLIXFFqHRY3PKvIdX2I/DPIZJ7 PBKw==
X-Gm-Message-State: AG10YOStSfyThqUfjCUkVegIJMm5p+gXuperqCkJ8eryxNMAZVf8/DlbpurbYTAjakJ50iOCg6jDQUTkSZc3LQ==
MIME-Version: 1.0
X-Received: by 10.107.198.202 with SMTP id w193mr184660iof.178.1453932353923;  Wed, 27 Jan 2016 14:05:53 -0800 (PST)
Sender: jinmei.tatuya@gmail.com
Received: by 10.107.136.90 with HTTP; Wed, 27 Jan 2016 14:05:53 -0800 (PST)
In-Reply-To: <20160125.101420.41673285.sthaug@nethelp.no>
References: <56A5A782.5070809@si6networks.com> <20160125.093622.74711890.sthaug@nethelp.no> <56A5E0F6.2020807@si6networks.com> <20160125.101420.41673285.sthaug@nethelp.no>
Date: Wed, 27 Jan 2016 14:05:53 -0800
X-Google-Sender-Auth: tw3IjPgXG10j5WYAVtA02dItzVw
Message-ID: 
Subject: Re: 2001:db8
From: =?UTF-8?B?56We5piO6YGU5ZOJ?= 
To: sthaug@nethelp.no
Content-Type: text/plain; charset=UTF-8
Archived-At: 
Cc: Fernando Gont , IPv6 IPv6 List , draft-ietf-6man-rfc4291bis@ietf.org, Michael Richardson 
X-BeenThere: ipv6@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "IPv6 Maintenance Working Group \(6man\)" 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 27 Jan 2016 22:05:55 -0000

At Mon, 25 Jan 2016 10:14:20 +0100 (CET),
sthaug@nethelp.no wrote:

> > >>> So, I may have missed it, but was it said *which* platform it was that
> > >>> didn't allow this?
> > >>
> > >> I seem to recall it was FreeBSD. I could re-check if there's interest...
> > >
> > > Just tested FreeBSD 9.3 and 10.2: 2001:db8::/32 prefixes just work,
> > > with no apparent problems.
> >
> > Having a FreeBSD box acting as a router? -- I seem to recall that was
> > the scenario in which I found issues (freebsd 8 or the like.. but should
> > check).
>
> Yes I have that too :-)  Works fine with FreeBSD 9.3 and 10.2, not
> checked FreeBSD 8.

So, while all the implementation-independent discussions of this
thread are interesting and possibly useful, we don't yet know if such
a box exists in the real world, right?  It's also surprising to me if
an out-of-box FreeBSD node (whether configured with enabling/disabling
IPv6 forwarding) really rejects 200a:db8::/32 by default, and without
any interface to override it.

--
JINMEI, Tatuya


From nobody Thu Jan 28 11:27:45 2016
Return-Path: 
X-Original-To: ipv6@ietfa.amsl.com
Delivered-To: ipv6@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F333B1B35B5 for ; Thu, 28 Jan 2016 11:27:43 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.852
X-Spam-Level: 
X-Spam-Status: No, score=-0.852 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DATE_IN_PAST_12_24=1.049, SPF_PASS=-0.001] autolearn=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TfUjUDekzY8A for ; Thu, 28 Jan 2016 11:27:42 -0800 (PST)
Received: from fgont.go6lab.si (fgont.go6lab.si [IPv6:2001:67c:27e4::14]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DD8FA1A89F5 for ; Thu, 28 Jan 2016 11:27:41 -0800 (PST)
Received: from [192.168.2.101] (unknown [181.165.125.191]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by fgont.go6lab.si (Postfix) with ESMTPSA id E0AE5206A39; Thu, 28 Jan 2016 20:27:36 +0100 (CET)
Subject: Re: draft-ietf-6man-default-iids v 09
To: Brian E Carpenter , "Ray Hunter (v6ops)" 
References: <56A7575A.2000707@globis.net> <56A7CBF0.2070203@gmail.com> <56A873FB.5070002@globis.net> <56A91286.9000602@gmail.com>
From: Fernando Gont 
X-Enigmail-Draft-Status: N1110
Message-ID: <56A91DC5.7030700@si6networks.com>
Date: Wed, 27 Jan 2016 16:43:01 -0300
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.5.1
MIME-Version: 1.0
In-Reply-To: <56A91286.9000602@gmail.com>
Content-Type: text/plain; charset=windows-1252
Content-Transfer-Encoding: 7bit
Archived-At: 
Cc: draft-ietf-6man-default-iids@tools.ietf.org, 6man 
X-BeenThere: ipv6@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "IPv6 Maintenance Working Group \(6man\)" 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 28 Jan 2016 19:27:44 -0000

Hi, Brian,

On 01/27/2016 03:55 PM, Brian E Carpenter wrote:
>> To me, slightly restructuring the text around the 4 intentions would make the intentions clearer, and avoid unintended
>> consequences, like making existing implementations non-compliant over an issue that quite frankly doesn't actually break any
>> functionality.
> 
> I don't think it's an unintended consequence at all. On the contrary, I think it's
> exactly what we should do. And yes, it will hopefully affect future procurements.
> 
> This will *not* break any running code, except if someone is making false deductions
> from IID formats. It's years since Windows stopped using Modified EUI-64 by default,
> and we seem to have survived that.

Additionally, Linux has already moved away from Modified-EUI64, and my
understanding is that starting next year, distros will start shipping
with RFC7217 on by default.

We have spefici guidance on the subject RFC7258, that is clearly not an
argument in favor of modified eui-64, but rather than contrary.

Let's move on.


> (There are a couple of observational studies in
> published research that make deductions from IID formats, 

We have included something in:
. But you'll see that
the modified-eui64 percentage is very small.

(The addr6 tool in  makes
this kind of study very easy to do).


> but is anyone really running
> tools that contain logic like "if IID looks like Modified EUI-64 then do this, else
> do that"?)

They shouldn't.

Thanks!

Cheers,
-- 
Fernando Gont
SI6 Networks
e-mail: fgont@si6networks.com
PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492





From nobody Thu Jan 28 15:56:46 2016
Return-Path: 
X-Original-To: ipv6@ietfa.amsl.com
Delivered-To: ipv6@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4661C1B2AEF for ; Thu, 28 Jan 2016 15:56:44 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.003
X-Spam-Level: 
X-Spam-Status: No, score=-2.003 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RP_MATCHES_RCVD=-0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yU_es95eOf7R for ; Thu, 28 Jan 2016 15:56:43 -0800 (PST)
Received: from dougbarton.us (dougbarton.us [208.79.90.218]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 43BF81B2AE4 for ; Thu, 28 Jan 2016 15:56:43 -0800 (PST)
Received: from [192.168.0.179] (172-7-206-56.lightspeed.irvnca.sbcglobal.net [172.7.206.56]) by dougbarton.us (Postfix) with ESMTPSA id CFE9D3A0BD for ; Thu, 28 Jan 2016 23:56:42 +0000 (UTC)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=dougbarton.us; s=dkim; t=1454025402; bh=mkWjJji4BVQv5Z8E68d0HLti+xeuEo/qXRBLP0Rw0/A=; h=Subject:To:References:From:Date:In-Reply-To; b=Q/1WbXkkvu5uuBX8tDMEyycxy/fQSg0l4oElIbU/vYmlCq6z19HtPPDbPkXB5aJsi TZ2HjoNALslNIfGfq0Fia+v4WpMTKOV+wT9iIYjfL0maYRDVovxrlKD9KkM03wZj5K 1UxtMmPh8wIaaw51vm84Pz4xE9Cd87lGSQbh2x8U=
Subject: Re: 2001:db8 [was Re: draft-ietf-6man-rfc4291bis]
To: ipv6@ietf.org
References:    <56A27712.1060003@si6networks.com> <56A2A760.9050906@gmail.com> <28158.1453566884@obiwan.sandelman.ca> 
From: Doug Barton 
Message-ID: <56AAAABA.4060800@dougbarton.us>
Date: Thu, 28 Jan 2016 15:56:42 -0800
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.5.1
MIME-Version: 1.0
In-Reply-To: 
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 7bit
Archived-At: 
X-BeenThere: ipv6@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "IPv6 Maintenance Working Group \(6man\)" 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 28 Jan 2016 23:56:44 -0000

On 01/23/2016 05:40 PM, Warren Kumari wrote:
> Counterpoint:
>
> If you don't automatically filter, this stuff leaks into tables, etc.

Internal vs. border is a very real and important distinction here. On 
the border I would have no objection to documentation prefixes being in 
a default block rule, but it should have a way to be turned off.

As someone who writes a non-zero amount of documentation/teaching 
material, the ability to use examples verbatim is priceless.

I have also found it useful in the past to use a documentation prefix to 
provision a point to point link on secondary interfaces between hosts, 
precisely because that prefix should never show up on the larger 
network; and using it did not interfere with any other "proper" prefixes 
that were actually (or might be in the future) in use.

Being draconian about not routing documentation prefixes in 
hardware/software is overstepping.

Doug


From nobody Fri Jan 29 09:24:35 2016
Return-Path: 
X-Original-To: ipv6@ietfa.amsl.com
Delivered-To: ipv6@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0CA851A88C4 for ; Fri, 29 Jan 2016 09:24:34 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 1.237
X-Spam-Level: *
X-Spam-Status: No, score=1.237 tagged_above=-999 required=5 tests=[BAYES_50=0.8, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, STOX_REPLY_TYPE=0.439] autolearn=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id S7WnWXuibcok for ; Fri, 29 Jan 2016 09:24:32 -0800 (PST)
Received: from mx1.bupt.edu.cn (mx1.bupt.edu.cn [211.68.68.2]) by ietfa.amsl.com (Postfix) with ESMTP id C66AA1A88B4 for ; Fri, 29 Jan 2016 09:24:30 -0800 (PST)
Received: from mx1.bupt.edu.cn (unknown [127.0.0.1]) by mx1.bupt.edu.cn (AnyMacro(G7)) with SMTP id 8252819F426 for ; Sat, 30 Jan 2016 01:24:28 +0800 (HKT)
Received: from WeiGengyuPC (unknown [61.51.147.59]) by mx1.bupt.edu.cn (AnyMacro(G7)) with ESMTPA id 1F7F319F3FE; Sat, 30 Jan 2016 01:24:28 +0800 (HKT)
Message-ID: <5E87D8CCBDBA41519FE19C79D89D9127@WeiGengyuPC>
From: "weigengyu" 
To: "Fernando Gont" 
References: <47F937E4-49D4-43CD-9D0A-26DFD0867D4A@gmail.com>  <56A2A562.8050400@gmail.com> <56A2A914.3060107@si6networks.com>
In-Reply-To: <56A2A914.3060107@si6networks.com>
Subject: Re: 
Date: Sat, 30 Jan 2016 01:24:31 +0800
Organization: BUPT
MIME-Version: 1.0
Content-Type: text/plain; format=flowed; charset="utf-8"; reply-type=original
Content-Transfer-Encoding: 8bit
X-Priority: 3
X-MSMail-Priority: Normal
Importance: Normal
X-Mailer: Microsoft Windows Live Mail 16.4.3528.331
X-MimeOLE: Produced By Microsoft MimeOLE V16.4.3528.331
Archived-At: 
Cc: ipv6@ietf.org
X-BeenThere: ipv6@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "IPv6 Maintenance Working Group \(6man\)" 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 29 Jan 2016 17:24:34 -0000

Hi Fernando,

One suggestion.
This draft should add some decriptions about DAD process.

In RFC7217, "
5.4. Duplicate Address Detection
Duplicate Address Detection MUST be performed on all unicast
addresses prior to assigning them to an interface, regardless of
whether they are obtained through stateless autoconfiguration,
DHCPv6, or manual configuration, with the following exceptions

It should also be noted that Duplicate Address Detection must be
performed prior to assigning an address to an interface in order to
prevent multiple nodes from using the same address simultaneously. "

If a node returns back into a network and trys to use the already existed 
stable address,
because the IPv6 address is not tentative, DAD process will not run.
IPv6 address confilts may occurr.
In order to prevent from this, it is required to do DAD process.

It seems that the existing IPv6 addresses must be tentative when new IPv6 
address becomes prefered.
The node will have to do DAD process the same as accessing a new network.

Or, the node must do DAD process when changing the accessing networks.
Right?

Regards,

Gengyu WEI
Network Technology Center
School of Computer
Beijing University of Posts and Telecommunications
-----原始邮件----- 
From: Fernando Gont
Sent: Saturday, January 23, 2016 6:11 AM
To: Brian E Carpenter ; Manfredi, Albert E ; Bob Hinden ; IPv6 List
Subject: Re:

On 01/22/2016 06:55 PM, Brian E Carpenter wrote:
> On 23/01/2016 08:22, Manfredi, Albert E wrote:
> ...
>>
>> Did we decide to not include anything about byte transmission order, 
>> along the lines of RFC 791 Appendix B?
>
> It's there:
>
>    The data transmission order for IPv6 is the same as for IPv4 as
>    defined in Appendix B of [RFC0791].

(without looking at the relevant rfcs):
Why not deine that in this very rfc? Otherwise this would be kind of a
normative reference to ipv4 in an ipv6 std...

Thanks,
-- 
Fernando Gont
SI6 Networks
e-mail: fgont@si6networks.com
PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492




--------------------------------------------------------------------
IETF IPv6 working group mailing list
ipv6@ietf.org
Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------