From nobody Tue Jun 7 07:33:15 2016 Return-Path: X-Original-To: int-dir@ietfa.amsl.com Delivered-To: int-dir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6E8E312D69C; Tue, 7 Jun 2016 07:33:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com 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 3xNIFMxaaF0g; Tue, 7 Jun 2016 07:33:12 -0700 (PDT) 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 BF44012D694; Tue, 7 Jun 2016 07:33:12 -0700 (PDT) Received: by mail-qg0-x22e.google.com with SMTP id 93so59068378qgx.2; Tue, 07 Jun 2016 07:33:12 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:from:date:message-id:subject:to:cc; bh=Lde3qU5JegGlkNlXdEuC+9vWWtrhiQLjp2yY8kJDl5Y=; b=IYi/2PZdtp3Q23+54lAMKJwOzqC99nZzqvTKNkbEwlep3k2LKn4606hcfPJbWJiZjS qw/4Dkif43VHKET/a3tzD8N56wEUUZIOAT0XZcqjyS8PgiKfNYXhpfpAib36SZbsnVQD u8oi5hkAojmjkmTOmUx4hMIUuL2suMm49TQ0Seao3xvnl3/7m1kRizMnMQywd4u+l1qZ PV0XGrb8j9ooKOuaKsJjtk8B3mQR5Yofz6KE5lreyUU1v7R09h4x37rx2gUb0ibA3F5U htanBJYXIGqxo3xwCS5QNnddc9B3m6mBXpoKWGmllkGtjzx9QmZXTz4Umdqn53z/WOY1 wE5A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:from:date:message-id:subject:to:cc; bh=Lde3qU5JegGlkNlXdEuC+9vWWtrhiQLjp2yY8kJDl5Y=; b=f2GuNTcKey/MXCChKu5XwoqvMjTjgi9NvjJaowxTCJbRU6iJSNz164RrcQMY8kobVr itmIl6zNj0T44GSe93KYaG7G2CkTerz9hl86gWwUPdWH8et6Rb/t8kHUencpKNrViLe0 1OIoeFzUeX4F+YsQTwIgUOn5bavU+xpM/DFjGduc9ENZ5d9f026Wji/hyma/gpdQ4fRo gILNlaXdpFlp1KYSwgbEQsqLeWJjvV/1PoRMe71K2GGWlR1EnqZkoIwrL2mGVPobBXpP TILqNgn3kEWqngu9kxqFU67aP11F4Wypg8sKaRqjpHlaqYBDciba86dIF1q2kx4VMLQl Zbiw== X-Gm-Message-State: ALyK8tIZTcZB7tpoOWHvoiEq7uJbb/hBO7yD13paV669xYx3nRpIkBkvY1o/hos9uPYYbvr0nie5m/L28XkU3A== X-Received: by 10.140.18.244 with SMTP id 107mr20191012qgf.95.1465309991870; Tue, 07 Jun 2016 07:33:11 -0700 (PDT) MIME-Version: 1.0 Received: by 10.55.160.87 with HTTP; Tue, 7 Jun 2016 07:33:11 -0700 (PDT) From: Zhen Cao Date: Tue, 7 Jun 2016 22:33:11 +0800 Message-ID: To: int-dir@ietf.org, int-ads@ietf.org Content-Type: text/plain; charset=UTF-8 Archived-At: Cc: draft-ietf-6man-multi-homed-host-06@ietf.org Subject: [Int-dir] INT area directorate review for draft-ietf-6man-multi-homed-host-06 X-BeenThere: int-dir@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "This list is for discussion between the members of the Internet Area directorate." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 Jun 2016 14:33:14 -0000 Hi, I am an assigned INT directorate reviewer for draft-ietf-6man-multi- homed-host-06.txt. These comments were written primarily for the benefit of the Internet Area Directors. Document editors and shepherd(s) should treat these comments just like they would treat comments from any other IETF contributors and resolve them along with any other Last Call comments that have been received. For more details on the INT Directorate, see http://www.ietf.org/iesg/direc torate.html. Thank authors for this work. Overall, this is a well-written draft. It clearly specifies what a multi-homed host needs to take into account while making default route and source address selections, especially when a certain in-path filter/middleboxes may prevent successful communication. One cent for discussion as below: >3.2. Default Router Selection > >Default Router Selection is modified as follows: A host SHOULD select >default routers for each prefix it is assigned an address in. >Routers that have advertised the prefix in its Router Advertisement >message SHOULD be preferred over routers that do not advertise the >prefix. If both routers have not advertised the prefix, how will the host make the decision? A normal daily example is a host being connected to the Internet via one router, and at the same time connected to a VPN to a private domain which is further connected to global Internet. If the host initiates communication with some public internet address(not advertised by either link), it is sometimes undefined which route to take because both links connect to that destination. From my understanding, route metric will be take into account in this case. I do experience different VPN clients behave differently because their assignment of the VPN link metric. A note to this case might be useful for readers. Many thanks, Zhen From nobody Tue Jun 7 07:50:23 2016 Return-Path: X-Original-To: int-dir@ietfa.amsl.com Delivered-To: int-dir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9997912D69C; Tue, 7 Jun 2016 07:50:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com 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 eGuqXJDhGg3e; Tue, 7 Jun 2016 07:50:21 -0700 (PDT) Received: from mail-qk0-x235.google.com (mail-qk0-x235.google.com [IPv6:2607:f8b0:400d:c09::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 4394512D13B; Tue, 7 Jun 2016 07:42:22 -0700 (PDT) Received: by mail-qk0-x235.google.com with SMTP id s186so69490067qkc.1; Tue, 07 Jun 2016 07:42:22 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=zKM5O+gZD71fcIbBipUbivku4WT7gLVMjjq5xR4PN80=; b=zaGoIrJ/ddu1jmTUaWZhrGf3FHc9uaACViaF22EoLZfKRQ8U/7fehccCuiWuyfF2O2 Xog1szTgjiomPrimsLDSORupWCONeozfF51ih463q1f84ZnBJ5Y83hvj1QWPJkSELGb8 bt3FrtkJF8QBVj29EGoW1J3KOPBrXa8JNTQRVMKJFFxAkc0r7Y8R7Qs89vg5NwO7wpiJ EehG9ewBW25E8v1WLbw7j3TGdqPEp2czW/Hf1LCWeOZaOvG6SdyL3axY6BWM2CJVbMfY KZC9e7QmaM4TAWRaNzMoM2cdADET7tCcrSutZzPcULWSQh7s5Yqe8Lq67IKcV0kSdY7h 5sAQ== 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; bh=zKM5O+gZD71fcIbBipUbivku4WT7gLVMjjq5xR4PN80=; b=YNtH8NIsfivPX/rKKzcqhiNgLdxL0VR2tc+R8rVk/OdldtXyiYdGJEyxP05JSTUZlL JinwyS8pxHEhvZklCZu5xUj6MdNTId/0jd2Uzo59gPhkTz5wXGZiGnLZfRQWOc//0pU0 39NkAZpVBGrO5En1bbuY67eWZro9w9mQR1hWV/yVElW9TolF0in4g5wq3cK9skpJ8NQ6 BLBeDOQd1SYXuZGhMND5RkCYX6KxGfwZhv6S7B2jfiQ7VxTsMs2ZR6rEyKcTY+5wAcpv R1rbPEI3WIxxTW/tzU3x2grHyV9spCc20xeiA2gxnMvshHMpqGI+f3BCe6Se4LhPBzJ3 ADwA== X-Gm-Message-State: ALyK8tKz5DTGSU2wyvKeYsWGQifq6sGwZBk+hGAqKlGyxCN/qcZoBfGUz8BXQP8QeT+Gl94VA9FJve91YznVWg== X-Received: by 10.55.154.136 with SMTP id c130mr21003582qke.79.1465310541346; Tue, 07 Jun 2016 07:42:21 -0700 (PDT) MIME-Version: 1.0 Received: by 10.55.160.87 with HTTP; Tue, 7 Jun 2016 07:42:20 -0700 (PDT) In-Reply-To: References: From: Zhen Cao Date: Tue, 7 Jun 2016 22:42:20 +0800 Message-ID: To: int-dir@ietf.org, int-ads@ietf.org Content-Type: text/plain; charset=UTF-8 Archived-At: Cc: draft-ietf-6man-multi-homed-host@tools.ietf.org Subject: Re: [Int-dir] INT area directorate review for draft-ietf-6man-multi-homed-host-06 X-BeenThere: int-dir@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "This list is for discussion between the members of the Internet Area directorate." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 Jun 2016 14:50:22 -0000 Excuse me for resending due to the use of a wrong author email alias. I am an assigned INT directorate reviewer for draft-ietf-6man-multi- homed-host-06.txt. These comments were written primarily for the benefit of the Internet Area Directors. Document editors and shepherd(s) should treat these comments just like they would treat comments from any other IETF contributors and resolve them along with any other Last Call comments that have been received. For more details on the INT Directorate, see http://www.ietf.org/iesg/direc torate.html. Thank authors for this work. Overall, this is a well-written draft. It clearly specifies what a multi-homed host needs to take into account while making default route and source address selections, especially when a certain in-path filter/middleboxes may prevent successful communication. I believe it is in a good shape for publication. One cent for discussion as below: >3.2. Default Router Selection > >Default Router Selection is modified as follows: A host SHOULD select >default routers for each prefix it is assigned an address in. >Routers that have advertised the prefix in its Router Advertisement >message SHOULD be preferred over routers that do not advertise the >prefix. If both routers have not advertised the prefix, how will the host make the decision? A normal daily example is a host being connected to the Internet via one router, and at the same time connected to a VPN to a private domain which is further connected to global Internet. If the host initiates communication with some public internet address(not advertised by either link), it is sometimes undefined which route to take because both links connect to that destination. From my understanding, route metric will be take into account in this case. I do experience different VPN clients behave differently because their assignment of the VPN link metric. A note to this case might be useful for readers. Many thanks, Zhen From nobody Tue Jun 7 13:11:13 2016 Return-Path: X-Original-To: int-dir@ietfa.amsl.com Delivered-To: int-dir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A25B712D0DD; Tue, 7 Jun 2016 13:11:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com 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 G1xRgBKLd_xE; Tue, 7 Jun 2016 13:11:10 -0700 (PDT) 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 E833212B02C; Tue, 7 Jun 2016 13:11:09 -0700 (PDT) Received: by mail-pf0-x22f.google.com with SMTP id t190so7121686pfb.3; Tue, 07 Jun 2016 13:11:09 -0700 (PDT) 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-transfer-encoding; bh=BcT/Zko7sqX2NDp0A2soC6Us8j5ZS3Iwr3BTMBv5VnY=; b=Bt0BcFHwg5qK5Lf1geDpmAIZCcetfdx+uTEwWs8rj8vrp1c43vhYJltwR66eUqh8HO 3473ZgVJmz13QjBTGhEQyPul4A5+CROGukbUZkqcn2g9NdQFHJt/9jOoDVYDtF1O17o5 AfbyKYTJoFNl9P4XMWoowGpsNRq2wsjQ7NadQiOzcuA3ojfPXBdLBJnmfIynjTB9YnwA dbNn5IbTuEw3YFytYMn9qbrZUxNZia92zmQrNs2Bb3ZozHKdNy1XIVIr352eMRod4aXF pDEvVFpuBC6V9lYAe9Ey3UsP54+faY/BU1L+cQg28l2Re9do2MWylEOOy1KHPRBQ1azD 8EAA== 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-transfer-encoding; bh=BcT/Zko7sqX2NDp0A2soC6Us8j5ZS3Iwr3BTMBv5VnY=; b=i/xWKwVx4Qgs6+lM6ZEyKKPrU9iIuzSpOY+XF9pEzjIqQzNTOUri41p3RwHkS0V6Yg ynOnKczNyhAQS1vArST03uaBJ3EfLb+iDnLv4+tp/aVxYUwvbG+KvXxN7BnLBUqIbkLz Cy6zPcmGLiIgwh08Wr8XNf8ZmAPNiKz2DAVU7XmyMYHw6asz0cPvJBKG7WBCBcbNYBbw nKafPyAQuXtujo4p6yLTv2WW4mm/HBeH2uukjhbji2FRQ55fVbs+yT/xX5+bxdmjdXsH y+PU2VUlJqIeGJI5pY86kIBVwMgfwUvd1OgdyJ5u8VKCoMOIGpZYuzW/9M/iNBqiNN/E YUVg== X-Gm-Message-State: ALyK8tIf7g/KO0GSYNFL7ByH9mBKCz0AHykPMqX0mQZoRtIqVEa8XIqRXKNweiZilGrAag== X-Received: by 10.98.157.89 with SMTP id i86mr1221252pfd.121.1465330269478; Tue, 07 Jun 2016 13:11:09 -0700 (PDT) Received: from ?IPv6:2406:e007:4237:1:7dc1:250d:e80b:1cec? ([2406:e007:4237:1:7dc1:250d:e80b:1cec]) by smtp.gmail.com with ESMTPSA id ce8sm35050306pad.44.2016.06.07.13.11.01 (version=TLSv1/SSLv3 cipher=OTHER); Tue, 07 Jun 2016 13:11:06 -0700 (PDT) To: Zhen Cao , int-dir@ietf.org, int-ads@ietf.org References: From: Brian E Carpenter Organization: University of Auckland Message-ID: Date: Wed, 8 Jun 2016 08:11:04 +1200 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.1.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-multi-homed-host@tools.ietf.org Subject: Re: [Int-dir] INT area directorate review for draft-ietf-6man-multi-homed-host-06 X-BeenThere: int-dir@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "This list is for discussion between the members of the Internet Area directorate." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 Jun 2016 20:11:12 -0000 Hi Zhen, Thanks for the review. On 08/06/2016 02:42, Zhen Cao wrote: > Excuse me for resending due to the use of a wrong author email alias. > > I am an assigned INT directorate reviewer for draft-ietf-6man-multi- > homed-host-06.txt. These comments were written > primarily for the benefit of the Internet Area Directors. Document > editors and shepherd(s) should treat these comments just like they > would treat comments from any other IETF contributors and resolve them > along with any other Last Call comments that have been received. For > more details on the INT Directorate, see http://www.ietf.org/iesg/direc > torate.html. > > Thank authors for this work. > > Overall, this is a well-written draft. It clearly specifies what a > multi-homed host needs to take into account while making default route > and source address selections, especially when a certain in-path > filter/middleboxes may prevent successful communication. > > I believe it is in a good shape for publication. > > One cent for discussion as below: > >> 3.2. Default Router Selection >> >> Default Router Selection is modified as follows: A host SHOULD select >> default routers for each prefix it is assigned an address in. >> Routers that have advertised the prefix in its Router Advertisement >> message SHOULD be preferred over routers that do not advertise the >> prefix. > > If both routers have not advertised the prefix, how will the host make > the decision? You mean, no router advertised it? We could simply state that this case is out of scope for the document, but I guess it would be clearer to state that normal routing metrics will apply. > A normal daily example is a host being connected to the Internet via > one router, and at the same time connected to a VPN to a private > domain which is further connected to global Internet. If the host > initiates communication with some public internet address(not > advertised by either link), it is sometimes undefined which route to > take because both links connect to that destination. From my > understanding, route metric will be take into account in this case. I > do experience different VPN clients behave differently because their > assignment of the VPN link metric. A note to this case might be > useful for readers. I've had no experience of that with IPv6. I did have it for IPv4 with a previous employer, and the VPN came with a very complex set of host routes that answered this question. Brian From nobody Tue Jun 7 18:52:31 2016 Return-Path: X-Original-To: int-dir@ietfa.amsl.com Delivered-To: int-dir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8239C12D10D; Tue, 7 Jun 2016 18:52:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.699 X-Spam-Level: X-Spam-Status: No, score=-2.699 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, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com 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 NO_Q6CckIxsm; Tue, 7 Jun 2016 18:52:27 -0700 (PDT) Received: from mail-qk0-x235.google.com (mail-qk0-x235.google.com [IPv6:2607:f8b0:400d:c09::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 3394C12D0F8; Tue, 7 Jun 2016 18:52:27 -0700 (PDT) Received: by mail-qk0-x235.google.com with SMTP id i187so104704460qkd.3; Tue, 07 Jun 2016 18:52:27 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=iiEKRUub5tdhPvlx6j8VtvJ7Q3qW9++UAD+7Q32g2t0=; b=M1gRaEhLCE8FlvmG+XFu3odHRr0Y1BWsY4U9ncd2y5oyKMRSsncZuWD+cVswWYFrQK SO51+v0XWPGZ0M1nLKeI6b2L2HF1Lrvt8qDJ/mw0/3wjrV4DpPYYX+9YB/LTVTu/mduU CgE2Cnq5yv8dp2seWNU6qMj3xiRSzk6fS75cqNzsf8HehIMy0DZvK65yxDKDKXaWjIdR Dtff908r11UQd/loOnQruGsg1MKXYSyuyoNxE/FKRkbd3RXnD2BpF6Sh6oJ+LhfIqAHc 58iJ7BMMKPBQVYG9ptosuN5axLJsVnma8IgDtFpUjwyuCbuuYkzekdpG2REponCzcK0t YgWw== 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; bh=iiEKRUub5tdhPvlx6j8VtvJ7Q3qW9++UAD+7Q32g2t0=; b=du4mMgO/c3fO5MyURycz+zD0mv9c3CbB9iGxDAlfSeiEE4OuF4zLsp7ENMAlYUpANT aFpYZS7UrzLiG7AORG44+O70zo5+vca8/RnH8ao+PhqPXlT5B+0Gv88Qi3hwVRw7Z4mo p6RiubKtPVIbt87syD0PBsVPTLA4/vDyR8tcg4ONMMSUgavJSd2GXyCNIUQHSGL64Z/o f07l0RDD23B0SFp3thHpfPU8lqZQYShzrJqTDspZwjYyzXa0qofwfbI20pJ3zTpbkU8N UGfHb9sA4hIakKpTRuaH3dmhHCB8Vj9MDfyAVK8G2viloM1lUL0eiALUlkVQFr2LUovf 1Jjw== X-Gm-Message-State: ALyK8tJGRqgHKbZjhrbDOezFo6n8Vga5hbGyv58ClJtHgZWRXXffDvcph1WJ/WXejsvqcknkPZWi3XGywIOsAQ== X-Received: by 10.55.178.6 with SMTP id b6mr2573626qkf.70.1465350746200; Tue, 07 Jun 2016 18:52:26 -0700 (PDT) MIME-Version: 1.0 Received: by 10.55.160.87 with HTTP; Tue, 7 Jun 2016 18:52:25 -0700 (PDT) In-Reply-To: References: From: Zhen Cao Date: Wed, 8 Jun 2016 09:52:25 +0800 Message-ID: To: Brian E Carpenter Content-Type: multipart/alternative; boundary=94eb2c06f3dcb2deea0534ba8ed8 Archived-At: Cc: draft-ietf-6man-multi-homed-host@tools.ietf.org, int-ads@ietf.org, int-dir@ietf.org Subject: Re: [Int-dir] INT area directorate review for draft-ietf-6man-multi-homed-host-06 X-BeenThere: int-dir@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "This list is for discussion between the members of the Internet Area directorate." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 Jun 2016 01:52:29 -0000 --94eb2c06f3dcb2deea0534ba8ed8 Content-Type: text/plain; charset=UTF-8 On Wed, Jun 8, 2016 at 4:11 AM, Brian E Carpenter < brian.e.carpenter@gmail.com> wrote: > Hi Zhen, > > Thanks for the review. > > On 08/06/2016 02:42, Zhen Cao wrote: > > Excuse me for resending due to the use of a wrong author email alias. > > > > I am an assigned INT directorate reviewer for draft-ietf-6man-multi- > > homed-host-06.txt. These comments were written > > primarily for the benefit of the Internet Area Directors. Document > > editors and shepherd(s) should treat these comments just like they > > would treat comments from any other IETF contributors and resolve them > > along with any other Last Call comments that have been received. For > > more details on the INT Directorate, see http://www.ietf.org/iesg/direc > > torate.html. > > > > Thank authors for this work. > > > > Overall, this is a well-written draft. It clearly specifies what a > > multi-homed host needs to take into account while making default route > > and source address selections, especially when a certain in-path > > filter/middleboxes may prevent successful communication. > > > > I believe it is in a good shape for publication. > > > > One cent for discussion as below: > > > >> 3.2. Default Router Selection > >> > >> Default Router Selection is modified as follows: A host SHOULD select > >> default routers for each prefix it is assigned an address in. > >> Routers that have advertised the prefix in its Router Advertisement > >> message SHOULD be preferred over routers that do not advertise the > >> prefix. > > > > If both routers have not advertised the prefix, how will the host make > > the decision? > > You mean, no router advertised it? > We could simply state that this case > is out of scope for the document, but I guess it would be clearer to > state that normal routing metrics will apply. > Good to me. > > > A normal daily example is a host being connected to the Internet via > > one router, and at the same time connected to a VPN to a private > > domain which is further connected to global Internet. If the host > > initiates communication with some public internet address(not > > advertised by either link), it is sometimes undefined which route to > > take because both links connect to that destination. From my > > understanding, route metric will be take into account in this case. I > > do experience different VPN clients behave differently because their > > assignment of the VPN link metric. A note to this case might be > > useful for readers. > > I've had no experience of that with IPv6. I did have it for IPv4 with a > previous employer, and the VPN came with a very complex set of host routes > that answered this question. > Exactly true. Cheers, Zhen > > Brian > > > --94eb2c06f3dcb2deea0534ba8ed8 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On Wed, Jun 8, 2016 at 4:11 AM, Brian E Carpenter <= ;brian.e.c= arpenter@gmail.com> wrote:
= Hi Zhen,

Thanks for the review.

On 08/06/2016 02:42, Zhen Cao wrote:
> Excuse me for resending due to the use of a wrong author email alias.<= br> >
> I am an assigned INT directorate reviewer for draft-ietf-6man-multi- > homed-host-06.txt. These comments were written
> primarily for the benefit of the Internet Area Directors. Document
> editors and shepherd(s) should treat these comments just like they
> would treat comments from any other IETF contributors and resolve them=
> along with any other Last Call comments that have been received. For > more details on the INT Directorate, see http://www.ietf.org/iesg= /direc
> torate.html.
>
> Thank authors for this work.
>
> Overall, this is a well-written draft. It clearly specifies what a
> multi-homed host needs to take into account while making default route=
> and source address selections, especially when a certain in-path
> filter/middleboxes may prevent successful communication.
>
> I believe it is in a good shape for publication.
>
> One cent for discussion as below:
>
>> 3.2.=C2=A0 Default Router Selection
>>
>> Default Router Selection is modified as follows: A host SHOULD sel= ect
>> default routers for each prefix it is assigned an address in.
>> Routers that have advertised the prefix in its Router Advertisemen= t
>> message SHOULD be preferred over routers that do not advertise the=
>> prefix.
>
> If both routers have not advertised the prefix, how will the host make=
> the decision?

You mean, no router advertised it?
=C2=A0
We could simply state that this case
is out of scope for the document, but I guess it would be clearer to
state that normal routing metrics will apply.

Good to me.=C2=A0
=C2=A0

> A normal daily example is a host being connected to the Internet via > one router, and at the same time connected to a VPN to a private
> domain which is further connected to global Internet.=C2=A0 If the hos= t
> initiates communication with some public internet address(not
> advertised by either link), it is sometimes undefined which route to > take because both links connect to that destination.=C2=A0 From my
> understanding, route metric will be take into account in this case.=C2= =A0 I
> do experience different VPN clients behave differently because their > assignment of the VPN link metric.=C2=A0 A note to this case might be<= br> > useful for readers.

I've had no experience of that with IPv6. I did have it for IPv4= with a
previous employer, and the VPN came with a very complex set of host routes<= br> that answered this question.

Exactly tr= ue.=C2=A0

Cheers,
Zhen
=C2=A0<= /div>

=C2=A0 =C2=A0 Brian



--94eb2c06f3dcb2deea0534ba8ed8-- From nobody Sat Jun 11 00:49:24 2016 Return-Path: X-Original-To: int-dir@ietfa.amsl.com Delivered-To: int-dir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 965B412DA59; Sat, 11 Jun 2016 00:49:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham autolearn_force=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 AfBYRzIqnicu; Sat, 11 Jun 2016 00:49:21 -0700 (PDT) Received: from gallus.zimbra.h.bitbit.net (gallus.zimbra.h.bitbit.net [87.238.49.226]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CB83812D816; Sat, 11 Jun 2016 00:49:17 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by gallus.zimbra.h.bitbit.net (Postfix) with ESMTP id B121EC1733; Sat, 11 Jun 2016 09:49:15 +0200 (CEST) Received: from gallus.zimbra.h.bitbit.net ([127.0.0.1]) by localhost (gallus.zimbra.h.bitbit.net [127.0.0.1]) (amavisd-new, port 10032) with ESMTP id HqkvfUTBj1pt; Sat, 11 Jun 2016 09:49:14 +0200 (CEST) Received: from localhost (localhost [127.0.0.1]) by gallus.zimbra.h.bitbit.net (Postfix) with ESMTP id 81BFCC17A8; Sat, 11 Jun 2016 09:49:14 +0200 (CEST) X-Virus-Scanned: amavisd-new at gallus.zimbra.h.bitbit.net Received: from gallus.zimbra.h.bitbit.net ([127.0.0.1]) by localhost (gallus.zimbra.h.bitbit.net [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id 2-54QiUZaMwj; Sat, 11 Jun 2016 09:49:14 +0200 (CEST) Received: from envy (cm-84.208.172.143.getinternet.no [84.208.172.143]) by gallus.zimbra.h.bitbit.net (Postfix) with ESMTPSA id D8CFAC1733; Sat, 11 Jun 2016 09:49:13 +0200 (CEST) Date: Sat, 11 Jun 2016 09:49:10 +0200 From: Tore Anderson To: Carlos =?UTF-8?B?SmVzw7pz?= Bernardos Cano Message-ID: <20160611094910.601ccb99@envy> In-Reply-To: <1462213046.4232.31.camel@it.uc3m.es> References: <1462213046.4232.31.camel@it.uc3m.es> Organization: Redpill Linpro X-Mailer: Claws Mail 3.13.2 (GTK+ 2.24.30; x86_64-redhat-linux-gnu) MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Archived-At: Cc: draft-ietf-6man-deprecate-atomfrag-generation@ietf.org, int-ads@ietf.org, int-dir@ietf.org Subject: Re: [Int-dir] INT area directorate review for draft-ietf-6man-deprecate-atomfrag-generation X-BeenThere: int-dir@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "This list is for discussion between the members of the Internet Area directorate." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 11 Jun 2016 07:49:22 -0000 Hello Carlos, thank you for your review, and apologies for the much belated reply. * Carlos Jes=C3=BAs Bernardos Cano > Overall, the document is mature, well written and I find it useful. I > do not see any reason to hold up publication. Thank you! > Some minor detailed suggestions follow: >=20 > - Section 1: The text says: 'Section 5 of [RFC2460] states that, when a > host receives an ICMPv6 "Packet Too Big" message [RFC4443] advertising > an MTU smaller than 1280 bytes (the minimum IPv6 MTU), the host is not > required to reduce the assumed Path-MTU, but must simply include a > Fragment Header in all subsequent packets sent to that destination.' >=20 > RFC2460 actually says 'In response to an IPv6 packet that is sent to an > IPv4 destination (i.e., a packet that undergoes translation from IPv6 > to IPv4), the originating IPv6 node may receive an ICMP Packet Too Big > message reporting a Next-Hop MTU less than 1280.' >=20 > While the document states later that 'an IPv6 node cannot easily limit > its exposure to the aforementioned attack vector by only generating > IPv6 atomic fragments towards IPv4 destinations behind a stateless > translator', it would help the reader to add that piece of context from > the very beginning of the document. Point taken. What do you think about amending Section 1 like so: [RFC2460] specifies the IPv6 fragmentation mechanism, which allows IPv6 packets to be fragmented into smaller pieces such that they can fit in the Path-MTU to the intended destination(s). An IPv4/IPv6 translator implementing the Stateless IP/ICMP Translation algorithm [RFC6145] may legitimately generate ICMPv6 "Packet Too Big" messages [RFC4443] advertising a "Next-Hop MTU" smaller than 1280 (the minimum IPv6 MTU). Section 5 of [RFC2460] states that, upon receiving such an ICMPv6 message, hosts are not required to reduce the assumed Path-MTU, but must simply include a Fragment Header in all subsequent packets sent to that destination. [...] > - Section 2: Again, I think it would help adding the context about > RFC2460 using atomic fragments only for the purpose of helping an > IPv6- to-IPv4 translating router can obtain a suitable > Identification value to use in resulting IPv4 fragments. Section 2 says: o As noted in Section 3, SIIT [RFC6145] (including derivative protocols such as Stateful NAT64 [RFC6146]) is the only technology which currently makes use of atomic fragments. And section 3 says: We note that SIIT essentially employs the Fragment Header of IPv6 atomic fragments to signal the translator how to set the DF bit of IPv4 datagrams (the DF bit is cleared when the IPv6 packet contains a Fragment Header, and is otherwise set to 1 when the IPv6 packet does not contain an IPv6 Fragment Header). I feel it would be redundant to duplicate this text in section 2. Isn't the reference too section 3 sufficient? > - Section 3: when discussing IPv4 Identification collision rates, it > would be helpful adding some numbers/equations there to get an idea of > what rates we are talking about. I leave this one to Fernando. > - Appendix A: what does 'Linux kernel current' mean? This is very > minor, as this section is probably to be removed, but in case it > remains after publication as RFC, current should be replaced by the > kernel version number. This one too; I don't know which kernel version =C2=ABcurrent=C2=BB refers = to. Tore From nobody Sat Jun 11 00:57:48 2016 Return-Path: X-Original-To: int-dir@ietfa.amsl.com Delivered-To: int-dir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2705012D1B1; Sat, 11 Jun 2016 00:57:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham autolearn_force=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 F2OreSxCKG55; Sat, 11 Jun 2016 00:57:46 -0700 (PDT) Received: from gallus.zimbra.h.bitbit.net (gallus.zimbra.h.bitbit.net [87.238.49.226]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2BA5C12D0C3; Sat, 11 Jun 2016 00:57:46 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by gallus.zimbra.h.bitbit.net (Postfix) with ESMTP id D0145C17A4; Sat, 11 Jun 2016 09:57:44 +0200 (CEST) Received: from gallus.zimbra.h.bitbit.net ([127.0.0.1]) by localhost (gallus.zimbra.h.bitbit.net [127.0.0.1]) (amavisd-new, port 10032) with ESMTP id ICa-qQCoO12i; Sat, 11 Jun 2016 09:57:43 +0200 (CEST) Received: from localhost (localhost [127.0.0.1]) by gallus.zimbra.h.bitbit.net (Postfix) with ESMTP id D9A9DC17EF; Sat, 11 Jun 2016 09:57:43 +0200 (CEST) X-Virus-Scanned: amavisd-new at gallus.zimbra.h.bitbit.net Received: from gallus.zimbra.h.bitbit.net ([127.0.0.1]) by localhost (gallus.zimbra.h.bitbit.net [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id nrmOt10RLtaI; Sat, 11 Jun 2016 09:57:43 +0200 (CEST) Received: from envy (cm-84.208.172.143.getinternet.no [84.208.172.143]) by gallus.zimbra.h.bitbit.net (Postfix) with ESMTPSA id 0B7B3C17A4; Sat, 11 Jun 2016 09:57:42 +0200 (CEST) Date: Sat, 11 Jun 2016 09:57:41 +0200 From: Tore Anderson To: "Bernie Volz (volz)" Message-ID: <20160611095741.7051c616@envy> In-Reply-To: <709d2969e3c84daeb02b9d72853c0f17@XCH-ALN-003.cisco.com> References: <1462213046.4232.31.camel@it.uc3m.es> <709d2969e3c84daeb02b9d72853c0f17@XCH-ALN-003.cisco.com> Organization: Redpill Linpro X-Mailer: Claws Mail 3.13.2 (GTK+ 2.24.30; x86_64-redhat-linux-gnu) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Archived-At: Cc: "draft-ietf-6man-deprecate-atomfrag-generation@ietf.org" , "int-ads@ietf.org" , "cjbc@it.uc3m.es" , "int-dir@ietf.org" Subject: Re: [Int-dir] INT area directorate review for draft-ietf-6man-deprecate-atomfrag-generation X-BeenThere: int-dir@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "This list is for discussion between the members of the Internet Area directorate." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 11 Jun 2016 07:57:47 -0000 Hello Bernie, thank you for your review, and apologies for the much belated reply. * Bernie Volz (volz) > A few other minor nits when I looked over this document: > > In section 3: > > - "2. The IPv4 node ... 1260 bytes". It might be useful to indicate > how this 1260 came to be (as someone might easily confuse this with a > typo for 1280?). This is really 1280 still but because the IPv4 > header is 20 bytes shorter than the IPv6 header, the figure is 1260 > for IPv4 packets. How about this? 2. The IPv4 node is located behind an IPv4 link with an MTU smaller than 1260 bytes. An IPv4 Path MTU of 1260 corresponds to an IPv6 Path MTU of 1280, due to an option-less IPv4 header being 20 bytes shorter than the IPv6 header. > - The text "proposing as a workaround" is odd? Should "as" be dropped? Agreed. We'll make sure to drop the "as". > In section 6, "some of [the] tests" (the is missing). Not a bit deal > as I'm sure RFC-Editor would fix. Good catch, thank you. Tore From nobody Sat Jun 11 02:16:16 2016 Return-Path: X-Original-To: int-dir@ietfa.amsl.com Delivered-To: int-dir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BFE2F12DA65; Sat, 11 Jun 2016 02:16:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham autolearn_force=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 sK37BQ-hcwH8; Sat, 11 Jun 2016 02:16:13 -0700 (PDT) Received: from gallus.zimbra.h.bitbit.net (gallus.zimbra.h.bitbit.net [87.238.49.226]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2FA4A12DA58; Sat, 11 Jun 2016 02:16:13 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by gallus.zimbra.h.bitbit.net (Postfix) with ESMTP id 38578C159C; Sat, 11 Jun 2016 11:16:11 +0200 (CEST) Received: from gallus.zimbra.h.bitbit.net ([127.0.0.1]) by localhost (gallus.zimbra.h.bitbit.net [127.0.0.1]) (amavisd-new, port 10032) with ESMTP id QsEP3QOIJAsY; Sat, 11 Jun 2016 11:16:09 +0200 (CEST) Received: from localhost (localhost [127.0.0.1]) by gallus.zimbra.h.bitbit.net (Postfix) with ESMTP id BABBAC1733; Sat, 11 Jun 2016 11:16:09 +0200 (CEST) X-Virus-Scanned: amavisd-new at gallus.zimbra.h.bitbit.net Received: from gallus.zimbra.h.bitbit.net ([127.0.0.1]) by localhost (gallus.zimbra.h.bitbit.net [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id LVRQMTul4zRm; Sat, 11 Jun 2016 11:16:09 +0200 (CEST) Received: from envy (cm-84.208.172.143.getinternet.no [84.208.172.143]) by gallus.zimbra.h.bitbit.net (Postfix) with ESMTPSA id 5E071C159C; Sat, 11 Jun 2016 11:16:09 +0200 (CEST) Date: Sat, 11 Jun 2016 11:16:07 +0200 From: Tore Anderson To: Ted Lemon Message-ID: <20160611111607.46db7057@envy> In-Reply-To: References: Organization: Redpill Linpro X-Mailer: Claws Mail 3.13.2 (GTK+ 2.24.30; x86_64-redhat-linux-gnu) MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Archived-At: Cc: draft-ietf-6man-deprecate-atomfrag-generation@ietf.org, int-ads@ietf.org, int-dir@ietf.org Subject: Re: [Int-dir] INT area directorate review for draft-ietf-6man-deprecate-atomfrag-generation X-BeenThere: int-dir@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "This list is for discussion between the members of the Internet Area directorate." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 11 Jun 2016 09:16:15 -0000 Hello Ted, thank you for your review, and apologies for the much belated reply. * Ted Lemon > This document doesn=E2=80=99t appear to actually recommend a course of ac= tion other > than in the Abstract. It seems to me that this document is arguing > (perhaps?) that firewalls should drop atomic fragments, or perhaps that > hosts should. But it never gives any actual advice. >=20 > It seems to me that the document could be substantially improved by > explicitly saying what behaviors are being recommended here. Otherwise, > the statement in the Abstract that this is intended to motivate changes to > the core IPv6 protocol specifications seems to leave whoever does that wi= th > the task of reading this document, thinking through the problem the autho= rs > have already thought through, and trying to come up with the right changes > to the base spec. >=20 > While doable, this seems unnecessary given that the authors have put a lot > of thought into this. Even if the document were to recommend a course of > action that wasn=E2=80=99t ultimately followed, walking through the reaso= ning > behind those recommendations would likely be helpful. Given that the > document is informational, this advice could be described as a > recommendation for future work, and not as advice to implementors. >=20 > It might also be useful, and would likely render any worries about this > document being treated as normative, if the authors were to talk about wh= at > to do to clean up existing implementations if the decision is taken to > retain the atomic fragment functionality. I see your point. The document used to normatively recommend a course of action, by updating specific problematic text in the existing standards. However, later on all of its recommendations were incorporated in 1981bis, 2460bis and 6145bis. They were therefore removed from this draft. The remaining purpose of this draft is thus to document the reasoning behind the change, which it does not need to be normative to do. This might have been self-evident for those of us involved in the developement of this draft, but I can see that this isn't so for a new reader. To remedy that, I suggest inserting a new section like this: 4. Conclusion Taking all of the above considerations into account, we recommend that IPv6 atomic fragments are deprecated. In particular: o IPv4/IPv6 translators should be updated to not generate ICMPv6 Packet Too Big errors containing a Path MTU value smaller than the minimum IPv6 MTU of 1280 bytes. This will ensure that current IPv6 nodes will never have a legitimate need to start generating IPv6 atomic fragments. o The recommendation in the previous bullet ensures there no longer are any valid reasons for ICMPv6 Packet Too Big errors containing a Path MTU value smaller than the minimum IPv6 MTU to exist. IPv6 nodes should therefore be updated to ignore them as invalid. We note that these recommendations have been incorporated in [RFC1981bis], [RFC2460bis] and [RFC6145bis]. How does that read to you? > Some minor detailed suggestions follow: >=20 > OLD: > Once the attack > packet has been sent, it will be the aforementioned routers > themselves the ones dropping their own traffic. > NEW: > Once the attack > packet has been sent, the aforementioned routers > will themselves be the ones dropping their own traffic. Agree. Your NEW text reads better. > o As noted in Section 3, SIIT [RFC6145] (including derivative >=20 > Expand SIIT acronym? Yep, agreed. > 2. The IPv4 node is located behind an IPv4 link with an MTU smaller > than 1260 bytes >=20 > It would be helpful to talk about when this might happen. It=E2=80=99s = not clear > to me that this is a plausible real-world scenario in these modern times, > but if it is it would be good to identify the situations in which the > proposed change will create operational problems. I don't think that any > use case you might list here would lead the reader to conclude that > therefore we need to keep atomic fragments, but such use cases should be > discussed, or the lack of any known such use cases should be discussed, f= or > completeness. I am not aware of any significant deployment of <1260-byte MTU links in the IPv4 Internet today (which makes all of this complicated and insecure atomic fragment stuff oh so much more pointless to begin with). But the IPv4 standard does allow them, and the Internet is a large place, so I'm sure there are some of these links to be found somewhere. Anyway, how about adding a new paragraph at the end (and rewriting the current last paragraph to not suggest it's the last one): [RFC6145] is the only "consumer" of IPv6 atomic fragments, and it correctly and diligently notes (in Section 6) the possible interoperability problems of relying on IPv6 atomic fragments, proposing as a workaround that leads to more robust behavior and simplified code. Finally, we believe that IPv4 links with an MTU smaller than 1260 bytes are very uncommonly found in the modern Internet. At the same time, we note that the sole purpose of IPv6 atomic fragments is to make such links compatible with IPv4/IPv6 translation. We surmise, therefore, that IPv6 atomic fragments are useful in only a miniscule number of "real world" situations. How does that read to you? Tore From nobody Sat Jun 11 04:11:03 2016 Return-Path: X-Original-To: int-dir@ietfa.amsl.com Delivered-To: int-dir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B477E12DB01; Sat, 11 Jun 2016 04:11:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -15.947 X-Spam-Level: X-Spam-Status: No, score=-15.947 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, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-1.426, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com 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 1USqDx1QPSsq; Sat, 11 Jun 2016 04:11:00 -0700 (PDT) Received: from alln-iport-5.cisco.com (alln-iport-5.cisco.com [173.37.142.92]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4C20212B01A; Sat, 11 Jun 2016 04:10:55 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1275; q=dns/txt; s=iport; t=1465643455; x=1466853055; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=ZsxhrQ3ib/YR+hEZkuI67jhCmFCjtxKiePHWjrQenkQ=; b=Y2GXgiW3Mk61DVdLbwQ3a4tDoYQYbMMJJO0j7xujWQLs2/W1YzTyMMfi ORvBH1QrznMunlj88UQKEr+5N29lO+gQFY0ze37zUdax9PtlwVGxPuc7W wpg8chRqiV/79aKvfJ4a4XufBriXavj1BLoV9byeWufG9UmDLw6S6+gr5 Y=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0AsBQDm8FtX/4ENJK1dgz6BU7sigXmGF?= =?us-ascii?q?wKBJjoSAQEBAQEBAWUnhEoBAQEDATo/BQsCAQgYHhAyJQIEDgWIKAi+EQEBAQE?= =?us-ascii?q?BAQEBAQEBAQEBAQEBAQEBARyIHoJWhECDLIIvAQSYYQGOJ48gj20BJAEvggQfF?= =?us-ascii?q?oE1booIAQEB?= X-IronPort-AV: E=Sophos;i="5.26,455,1459814400"; d="scan'208";a="282561557" Received: from alln-core-9.cisco.com ([173.36.13.129]) by alln-iport-5.cisco.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 11 Jun 2016 11:10:54 +0000 Received: from XCH-RCD-004.cisco.com (xch-rcd-004.cisco.com [173.37.102.14]) by alln-core-9.cisco.com (8.14.5/8.14.5) with ESMTP id u5BBAsrY000348 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Sat, 11 Jun 2016 11:10:54 GMT Received: from xch-aln-003.cisco.com (173.36.7.13) by XCH-RCD-004.cisco.com (173.37.102.14) with Microsoft SMTP Server (TLS) id 15.0.1104.5; Sat, 11 Jun 2016 06:10:53 -0500 Received: from xch-aln-003.cisco.com ([173.36.7.13]) by XCH-ALN-003.cisco.com ([173.36.7.13]) with mapi id 15.00.1104.009; Sat, 11 Jun 2016 06:10:53 -0500 From: "Bernie Volz (volz)" To: Tore Anderson Thread-Topic: [Int-dir] INT area directorate review for draft-ietf-6man-deprecate-atomfrag-generation Thread-Index: AQHRpJ7qLlqoMRkhJkuLisO6VwGSMZ+l9qLwgD6BzYD//+IpmA== Date: Sat, 11 Jun 2016 11:10:53 +0000 Message-ID: <7FA2A343-8FDA-49EC-B5BC-5C14987229FA@cisco.com> References: <1462213046.4232.31.camel@it.uc3m.es> <709d2969e3c84daeb02b9d72853c0f17@XCH-ALN-003.cisco.com>, <20160611095741.7051c616@envy> In-Reply-To: <20160611095741.7051c616@envy> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Cc: "draft-ietf-6man-deprecate-atomfrag-generation@ietf.org" , "int-ads@ietf.org" , "cjbc@it.uc3m.es" , "int-dir@ietf.org" Subject: Re: [Int-dir] INT area directorate review for draft-ietf-6man-deprecate-atomfrag-generation X-BeenThere: int-dir@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "This list is for discussion between the members of the Internet Area directorate." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 11 Jun 2016 11:11:02 -0000 Hi: Proposed changes look fine. Thanks. - Bernie (from iPad) > On Jun 11, 2016, at 3:57 AM, Tore Anderson wrot= e: >=20 > Hello Bernie, thank you for your review, and apologies for the much > belated reply. >=20 > * Bernie Volz (volz) >=20 >> A few other minor nits when I looked over this document: >>=20 >> In section 3: >>=20 >> - "2. The IPv4 node ... 1260 bytes". It might be useful to indicate >> how this 1260 came to be (as someone might easily confuse this with a >> typo for 1280?). This is really 1280 still but because the IPv4 >> header is 20 bytes shorter than the IPv6 header, the figure is 1260 >> for IPv4 packets. >=20 > How about this? >=20 > 2. The IPv4 node is located behind an IPv4 link with an MTU smaller > than 1260 bytes. An IPv4 Path MTU of 1260 corresponds to an IPv6 > Path MTU of 1280, due to an option-less IPv4 header being 20 > bytes shorter than the IPv6 header. >=20 >> - The text "proposing as a workaround" is odd? Should "as" be dropped? >=20 > Agreed. We'll make sure to drop the "as". >=20 >> In section 6, "some of [the] tests" (the is missing). Not a bit deal >> as I'm sure RFC-Editor would fix. >=20 > Good catch, thank you. >=20 > Tore From nobody Sat Jun 11 04:37:22 2016 Return-Path: X-Original-To: int-dir@ietfa.amsl.com Delivered-To: int-dir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 91DE712DB17 for ; Sat, 11 Jun 2016 04:37:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=fugue-com.20150623.gappssmtp.com 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 TKvr3QoGpC_J for ; Sat, 11 Jun 2016 04:37:18 -0700 (PDT) Received: from mail-lf0-x229.google.com (mail-lf0-x229.google.com [IPv6:2a00:1450:4010: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 6BC8612DB16 for ; Sat, 11 Jun 2016 04:37:14 -0700 (PDT) Received: by mail-lf0-x229.google.com with SMTP id q132so22171524lfe.3 for ; Sat, 11 Jun 2016 04:37:14 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=fugue-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=UkDfXEUweBBg6JvRCveZqWIZla2fxVRc6HlGmiuBrrI=; b=BcEBifl+aXidTf82WVVTJeDEbzYI6mZS0DtzuD8I8ujkq6asS5g/WiDYq2R0TgJwi4 1SYQo21PGur3RfHfn+v0ljMygb/eSP3AdvKzhv3jR45Ti+Z+LedG2cwHWfdU0gBw6S2+ rd2Oi4CUi3yFD9uLf1a6Dip8OB7JkHVDasH7ON+XHmEOqoHqqj+pL9R9k2kbUPinO7Xf OOIk0gSrTdvth0UsTqtGrlkQwpYR+jjfR3rQ2ozexXpnWdpxxzWQ+TJ7PeVn3z5/GkhM JHnsbmrBjidaRGgqRJO70JAxNN++9xjk4jl2Rk/NfcIVdL51yDUo+mImJcdiVBRYo0Dn BT7g== 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; bh=UkDfXEUweBBg6JvRCveZqWIZla2fxVRc6HlGmiuBrrI=; b=D+bVdYYUynmg6A7vCUBqJ7qYxoLf3yYTshXwmCdav1GRkkJqJDifECYU2MfDMX+w3D Oubr0v8s1cNYR75Rpz9NnCQibSo/jZ547TvjzPwtjxMdDhs1vwHm2nR1jnA5eJpvIRzr tSrpX7qBssPe68VbNYtBT0s7yB27K4/tQOFnEGHshjS/ZySH1kNa93HPsVd76B0gPuIn unAdQhEcXdeVtIVPNW9EGZ+gmHgZxbVlqQez67Mv4RoFTHbhThbk8LlOHUkC+Gsygpx7 ayK6Es6QLogGNLl7lyO3NE2hIwl4OsWs/E0S9XsKa7wcNilV02vwk+oXdKdiJwpVFmbD baCw== X-Gm-Message-State: ALyK8tIpGf1DAlWe7m/68cRoMdwGYot7uGrA+EBVCZr2XwKEQSEFb/j55vIJuPL4Ezw14i7OpLq+D+o4dVPLaA== X-Received: by 10.25.210.205 with SMTP id j196mr1738624lfg.139.1465645032553; Sat, 11 Jun 2016 04:37:12 -0700 (PDT) MIME-Version: 1.0 Received: by 10.25.153.135 with HTTP; Sat, 11 Jun 2016 04:36:32 -0700 (PDT) In-Reply-To: <20160611111607.46db7057@envy> References: <20160611111607.46db7057@envy> From: Ted Lemon Date: Sat, 11 Jun 2016 07:36:32 -0400 Message-ID: To: Tore Anderson Content-Type: multipart/alternative; boundary=001a11403562885d410534ff131b Archived-At: Cc: draft-ietf-6man-deprecate-atomfrag-generation@ietf.org, int-ads@ietf.org, int-dir@ietf.org Subject: Re: [Int-dir] INT area directorate review for draft-ietf-6man-deprecate-atomfrag-generation X-BeenThere: int-dir@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "This list is for discussion between the members of the Internet Area directorate." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 11 Jun 2016 11:37:19 -0000 --001a11403562885d410534ff131b Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Tore, thanks, your proposed changes address all the issues I raised. It hadn't crossed my mind that this document might already have had its intended effect! :) On Sat, Jun 11, 2016 at 5:16 AM, Tore Anderson wrote: > Hello Ted, thank you for your review, and apologies for the much > belated reply. > > * Ted Lemon > > > This document doesn=E2=80=99t appear to actually recommend a course of = action > other > > than in the Abstract. It seems to me that this document is arguing > > (perhaps?) that firewalls should drop atomic fragments, or perhaps that > > hosts should. But it never gives any actual advice. > > > > It seems to me that the document could be substantially improved by > > explicitly saying what behaviors are being recommended here. Otherwis= e, > > the statement in the Abstract that this is intended to motivate changes > to > > the core IPv6 protocol specifications seems to leave whoever does that > with > > the task of reading this document, thinking through the problem the > authors > > have already thought through, and trying to come up with the right > changes > > to the base spec. > > > > While doable, this seems unnecessary given that the authors have put a > lot > > of thought into this. Even if the document were to recommend a course = of > > action that wasn=E2=80=99t ultimately followed, walking through the rea= soning > > behind those recommendations would likely be helpful. Given that the > > document is informational, this advice could be described as a > > recommendation for future work, and not as advice to implementors. > > > > It might also be useful, and would likely render any worries about this > > document being treated as normative, if the authors were to talk about > what > > to do to clean up existing implementations if the decision is taken to > > retain the atomic fragment functionality. > > I see your point. > > The document used to normatively recommend a course of action, by > updating specific problematic text in the existing standards. > > However, later on all of its recommendations were incorporated in > 1981bis, 2460bis and 6145bis. They were therefore removed from this > draft. The remaining purpose of this draft is thus to document the > reasoning behind the change, which it does not need to be normative to > do. > > This might have been self-evident for those of us involved in the > developement of this draft, but I can see that this isn't so for a new > reader. > > To remedy that, I suggest inserting a new section like this: > > 4. Conclusion > > Taking all of the above considerations into account, we recommend > that IPv6 atomic fragments are deprecated. > > In particular: > > o IPv4/IPv6 translators should be updated to not generate ICMPv6 > Packet Too Big errors containing a Path MTU value smaller than the > minimum IPv6 MTU of 1280 bytes. This will ensure that current IPv6 > nodes will never have a legitimate need to start generating IPv6 > atomic fragments. > > o The recommendation in the previous bullet ensures there no longer > are any valid reasons for ICMPv6 Packet Too Big errors containing > a Path MTU value smaller than the minimum IPv6 MTU to exist. IPv6 > nodes should therefore be updated to ignore them as invalid. > > We note that these recommendations have been incorporated in > [RFC1981bis], [RFC2460bis] and [RFC6145bis]. > > How does that read to you? > > > Some minor detailed suggestions follow: > > > > OLD: > > Once the attack > > packet has been sent, it will be the aforementioned routers > > themselves the ones dropping their own traffic. > > NEW: > > Once the attack > > packet has been sent, the aforementioned routers > > will themselves be the ones dropping their own traffic. > > Agree. Your NEW text reads better. > > > o As noted in Section 3, SIIT [RFC6145] (including derivative > > > > Expand SIIT acronym? > > Yep, agreed. > > > 2. The IPv4 node is located behind an IPv4 link with an MTU smaller > > than 1260 bytes > > > > It would be helpful to talk about when this might happen. It=E2=80=99= s not > clear > > to me that this is a plausible real-world scenario in these modern time= s, > > but if it is it would be good to identify the situations in which the > > proposed change will create operational problems. I don't think that a= ny > > use case you might list here would lead the reader to conclude that > > therefore we need to keep atomic fragments, but such use cases should b= e > > discussed, or the lack of any known such use cases should be discussed, > for > > completeness. > > I am not aware of any significant deployment of <1260-byte MTU links in > the IPv4 Internet today (which makes all of this complicated and > insecure atomic fragment stuff oh so much more pointless to begin with). > But the IPv4 standard does allow them, and the Internet is a large > place, so I'm sure there are some of these links to be found somewhere. > > Anyway, how about adding a new paragraph at the end (and rewriting the > current last paragraph to not suggest it's the last one): > > [RFC6145] is the only "consumer" of IPv6 atomic fragments, and it > correctly and diligently notes (in Section 6) the possible > interoperability problems of relying on IPv6 atomic fragments, > proposing as a workaround that leads to more robust behavior and > simplified code. > > Finally, we believe that IPv4 links with an MTU smaller than 1260 > bytes are very uncommonly found in the modern Internet. At the same > time, we note that the sole purpose of IPv6 atomic fragments is to > make such links compatible with IPv4/IPv6 translation. We surmise, > therefore, that IPv6 atomic fragments are useful in only a miniscule > number of "real world" situations. > > How does that read to you? > > Tore > --001a11403562885d410534ff131b Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Tore, thanks, your proposed changes address all the issues= I raised. =C2=A0 It hadn't crossed my mind that this document might al= ready have had its intended effect! =C2=A0 :)

On Sat, Jun 11, 2016 at 5:16 AM, Tore And= erson <tore@redpill-linpro.com> wrote:
Hello Ted, thank you for your review, and apologies for = the much
belated reply.

* Ted Lemon

> This document doesn=E2=80=99t appear to actually recommend a course of= action other
> than in the Abstract.=C2=A0 =C2=A0It seems to me that this document is= arguing
> (perhaps?) that firewalls should drop atomic fragments, or perhaps tha= t
> hosts should.=C2=A0 =C2=A0But it never gives any actual advice.
>
> It seems to me that the document could be substantially improved by > explicitly saying what behaviors are being recommended here.=C2=A0 =C2= =A0Otherwise,
> the statement in the Abstract that this is intended to motivate change= s to
> the core IPv6 protocol specifications seems to leave whoever does that= with
> the task of reading this document, thinking through the problem the au= thors
> have already thought through, and trying to come up with the right cha= nges
> to the base spec.
>
> While doable, this seems unnecessary given that the authors have put a= lot
> of thought into this.=C2=A0 Even if the document were to recommend a c= ourse of
> action that wasn=E2=80=99t ultimately followed, walking through the re= asoning
> behind those recommendations would likely be helpful.=C2=A0 =C2=A0Give= n that the
> document is informational, this advice could be described as a
> recommendation for future work, and not as advice to implementors.
>
> It might also be useful, and would likely render any worries about thi= s
> document being treated as normative, if the authors were to talk about= what
> to do to clean up existing implementations if the decision is taken to=
> retain the atomic fragment functionality.

I see your point.

The document used to normatively recommend a course of action, by
updating specific problematic text in the existing standards.

However, later on all of its recommendations were incorporated in
1981bis, 2460bis and 6145bis. They were therefore removed from this
draft. The remaining purpose of this draft is thus to document the
reasoning behind the change, which it does not need to be normative to
do.

This might have been self-evident for those of us involved in the
developement of this draft, but I can see that this isn't so for a new<= br> reader.

To remedy that, I suggest inserting a new section like this:

=C2=A0 4. Conclusion

=C2=A0 Taking all of the above considerations into account, we recommend =C2=A0 that IPv6 atomic fragments are deprecated.

=C2=A0 In particular:

=C2=A0 o IPv4/IPv6 translators should be updated to not generate ICMPv6
=C2=A0 =C2=A0 Packet Too Big errors containing a Path MTU value smaller tha= n the
=C2=A0 =C2=A0 minimum IPv6 MTU of 1280 bytes. This will ensure that current= IPv6
=C2=A0 =C2=A0 nodes will never have a legitimate need to start generating I= Pv6
=C2=A0 =C2=A0 atomic fragments.

=C2=A0 o The recommendation in the previous bullet ensures there no longer<= br> =C2=A0 =C2=A0 are any valid reasons for ICMPv6 Packet Too Big errors contai= ning
=C2=A0 =C2=A0 a Path MTU value smaller than the minimum IPv6 MTU to exist. = IPv6
=C2=A0 =C2=A0 nodes should therefore be updated to ignore them as invalid.<= br>
=C2=A0 We note that these recommendations have been incorporated in
=C2=A0 [RFC1981bis], [RFC2460bis] and [RFC6145bis].

How does that read to you?

> Some minor detailed suggestions follow:
>
> OLD:
>=C2=A0 =C2=A0Once the attack
>=C2=A0 =C2=A0packet has been sent, it will be the aforementioned router= s
>=C2=A0 =C2=A0themselves the ones dropping their own traffic.
> NEW:
>=C2=A0 =C2=A0Once the attack
>=C2=A0 =C2=A0packet has been sent, the aforementioned routers
>=C2=A0 =C2=A0will themselves be the ones dropping their own traffic.
Agree. Your NEW text reads better.

>=C2=A0 =C2=A0o=C2=A0 As noted in Section 3, SIIT [RFC6145] (including d= erivative
>
> Expand SIIT acronym?

Yep, agreed.

>=C2=A0 =C2=A02.=C2=A0 The IPv4 node is located behind an IPv4 link with= an MTU smaller
>=C2=A0 =C2=A0 =C2=A0 =C2=A0than 1260 bytes
>
> It would be helpful to talk about when this might happen.=C2=A0 =C2=A0= It=E2=80=99s not clear
> to me that this is a plausible real-world scenario in these modern tim= es,
> but if it is it would be good to identify the situations in which the<= br> > proposed change will create operational problems.=C2=A0 I don't th= ink that any
> use case you might list here would lead the reader to conclude that > therefore we need to keep atomic fragments, but such use cases should = be
> discussed, or the lack of any known such use cases should be discussed= , for
> completeness.

I am not aware of any significant deployment of <1260-byte MTU li= nks in
the IPv4 Internet today (which makes all of this complicated and
insecure atomic fragment stuff oh so much more pointless to begin with). But the IPv4 standard does allow them, and the Internet is a large
place, so I'm sure there are some of these links to be found somewhere.=

Anyway, how about adding a new paragraph at the end (and rewriting the
current last paragraph to not suggest it's the last one):

=C2=A0 =C2=A0[RFC6145] is the only "consumer" of IPv6 atomic frag= ments, and it
=C2=A0 =C2=A0correctly and diligently notes (in Section 6) the possible
=C2=A0 =C2=A0interoperability problems of relying on IPv6 atomic fragments,=
=C2=A0 =C2=A0proposing as a workaround that leads to more robust behavior a= nd
=C2=A0 =C2=A0simplified code.

=C2=A0 =C2=A0Finally, we believe that IPv4 links with an MTU smaller than 1= 260
=C2=A0 =C2=A0bytes are very uncommonly found in the modern Internet. At the= same
=C2=A0 =C2=A0time, we note that the sole purpose of IPv6 atomic fragments i= s to
=C2=A0 =C2=A0make such links compatible with IPv4/IPv6 translation. We surm= ise,
=C2=A0 =C2=A0therefore, that IPv6 atomic fragments are useful in only a min= iscule
=C2=A0 =C2=A0number of "real world" situations.

How does that read to you?

Tore

--001a11403562885d410534ff131b-- From nobody Thu Jun 16 01:00:02 2016 Return-Path: X-Original-To: int-dir@ietfa.amsl.com Delivered-To: int-dir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EDB3012D0D8; Thu, 16 Jun 2016 01:00:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com 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 jKha4ME6HZSk; Thu, 16 Jun 2016 00:59:59 -0700 (PDT) Received: from mail-io0-x233.google.com (mail-io0-x233.google.com [IPv6:2607:f8b0:4001:c06::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 D330112D0A7; Thu, 16 Jun 2016 00:59:58 -0700 (PDT) Received: by mail-io0-x233.google.com with SMTP id f30so34576005ioj.2; Thu, 16 Jun 2016 00:59:58 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=tl40fPUX+NsNGVp/mzYvMFvg2OBMRr8y8970JiRuhzI=; b=wsYbO5+vk9hxWlSjdhmkd/4jguVZS28swcvNSq4DdZnwtPM50wPrvUAtRaaDlX7Mpv yc/JHdpeuwTZj8ZIl9AWdp+5muywCifBkyfqXFmA02lZFXupxwZlSO8E69f7sis4bO/B CELJ2cKTosFIJjODSaack7fnsybesg/gSVqaixS6Lh9yym+nvNvDdXUAD0i6M6b6JWCi UAKND66GBJPmnc7IBxw46AsJVVDcHKZCb72hu9h5C4KUh7++xs+f+/rX3y1d+N9Un7M/ zc40EQVVtKqNCpxXhiwKAXW42SdP1SxlVbHUVheN9e7iaY5AwY982j7CFzxEDh2FE1WH NOcQ== 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; bh=tl40fPUX+NsNGVp/mzYvMFvg2OBMRr8y8970JiRuhzI=; b=ArqcHGjKJw/G+Q+5kuQlnl9MOyXGd0z9LMHwpQZXfG0Y/R1W/W2fYBYmB9GGlsHDKx uJDFMHtTi/H1zlnCeZGzOaqbZxr+nc6G3+BY0jM4naPINIe6fszEMVx/QSpI8dpS/Aak Z6GlkqvbYYljZEO9/QFUQ0HYaiQjc2G5U1+248RgDrxoBgMIolnoVPwcyJU5ovvXxtD0 Le0f/TI6BeM25+lfgxt7x/AZtnBu4ixSAkLBS4naXzTEd7aUqGFVE2Akl3gneHds0H5N x2s1i15ghf8buXTHpxPpKr4IeavnWFPxLgfG2iQOWLsAtRZwVz3ZmFBsSuYJzOWWcYjh wVrA== X-Gm-Message-State: ALyK8tLVJZWQZS+WISGI6Nr6/oebiFqB6DSIHwKmDJl/EYRmSELnFw2BvUCx6t/ak5NOFXlfz7UsUCMJmufHRg== X-Received: by 10.107.174.198 with SMTP id n67mr5478698ioo.96.1466063998130; Thu, 16 Jun 2016 00:59:58 -0700 (PDT) MIME-Version: 1.0 Received: by 10.36.149.2 with HTTP; Thu, 16 Jun 2016 00:59:57 -0700 (PDT) In-Reply-To: References: From: GangChen Date: Thu, 16 Jun 2016 15:59:57 +0800 Message-ID: To: Ralph Droms Content-Type: text/plain; charset=UTF-8 Archived-At: Cc: draft-ietf-mif-happy-eyeballs-extension.all@tools.ietf.org, int-ads@ietf.org, "" Subject: Re: [Int-dir] INTDIR review of draft-ietf-mif-happy-eyeballs-extension-09 X-BeenThere: int-dir@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "This list is for discussion between the members of the Internet Area directorate." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Jun 2016 08:00:01 -0000 Dear Ralph, I apologize for this late reply. Thank you for the comments. Those are informative for us. Please see my replies inline. 2016-05-04 5:15 GMT+08:00, Ralph Droms : > I am an assigned INT directorate reviewer for > draft-ietf-mif-happy-eyeballs-extension-09. These comments were > written primarily for the benefit of the Internet Area > Directors. Document editors and shepherd(s) should treat these > comments just like they would treat comments from any other IETF > contributors and resolve them along with any other Last Call comments > that have been received. For more details on the INT Directorate, see > http://www.ietf.org/iesg/directorate.html. > > In my opinion, the documents lacks - and needs - a clear statement of > purpose. What result is the document trying to achieve? Who is the > audience? How would the audience put the contents of the document to > use? the draft mainly intends to address the issue where a node has selected an interface and obtained a valid IP address from the network, but Internet connectivity is not available. Such scenario is described in the "WiFi is broken" of use cases section. The purpose of HE-MIF is to avoid such issue. The audience is supposed to be connection manager implementors or web browser developer, who could integrate the HE-MIF framework into their implementations. This comment inspire me to re-construct the draft to clear the purpose statement. It's may probably be better to combine section 1 and 3, since the section 3 is major use cases description that may help to state the issue HE-MIF targeted. > The document must be edited carefully for english language usage > before publication. I would consider this issue to be worthy of a > "Discuss" on the document. I found that the document is unclear in > several areas, which prevented me from understanding the meaning of > that text. For example, in section 2, does "within a single home." > mean a device in one home or a device with just one interface? In > section 5.1, does: > > users may dedicatedly prefer a 3GPP > network interface to seek high-reliability or security benefits even > to manually turn off WiFi interface. > > mean: > > users may turn off a device's WiFi interface to guarantee use of a > 3GPP network interface to assure higher reliability or security. Your interpretation is correct and great example to me. I have realized there are several similiar language issues. Those days, I'm inviting english knowledged persons to help me fix the bugs. we will publish an new version to promote the readability. > Some sections seem to make observations about conditions that might > have an influence on an implementation of MIF-HE, but don't have any > actionable guidance for implementors. This lack of clarity is related > to the lack of a clear statement of purpose for the document. For > example, in section 5.1: > > The decision on mergence of > policies may be made by implementations, by node administrators, even > by other standards investigating customer behavior. However, it's > worth to note that a demand from users should be normally considered > higher priority than from other actors. > > I don't see anything in this text that I would consider actionable as > an implementor. The draft is virtually not a algorithm, but requirements for the algorithm or implementations. The section 5.1 reflects the wg discussion outcome. The actionable for implementors is to open an interface to accept user's input expressing their preference. And, this preference should be superior to other inputs. > It is unclear where the document explicitly choosing one interface as > "faster". Section 5.2 includes text about "the outcome of each > connection attempt"; does this text refer to recording the connection > time and using that time as the basis for future interface selection? It's correct. A timer is used to flush each cache entry and triger next connection attempt. > How does HE-MIF interact with HE for selecting between IPv4 and IPv6? HE-MIF and HE are two parallel threads. They don't have compulsive interactions. In other words, a device use HE-MIF to choose the faster interface, afterwards it may use HE to select suitable IP family or it just uses default address selection to determine. I hope above could clarify. Many thanks Best Regards Gang > From nobody Fri Jun 17 07:15:48 2016 Return-Path: X-Original-To: int-dir@ietfa.amsl.com Delivered-To: int-dir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 10FF812D52B for ; Fri, 17 Jun 2016 07:15:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_LOW=-0.7] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=it-uc3m-es.20150623.gappssmtp.com 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 k5cGbE1Ka72S for ; Fri, 17 Jun 2016 07:15:45 -0700 (PDT) Received: from mail-wm0-x235.google.com (mail-wm0-x235.google.com [IPv6:2a00:1450:400c:c09::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 2305112D633 for ; Fri, 17 Jun 2016 07:15:42 -0700 (PDT) Received: by mail-wm0-x235.google.com with SMTP id f126so73884wma.1 for ; Fri, 17 Jun 2016 07:15:42 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=it-uc3m-es.20150623.gappssmtp.com; s=20150623; h=message-id:subject:from:reply-to:to:cc:date:in-reply-to:references :organization:mime-version:content-transfer-encoding; bh=QMLenloMIZn4CEHdlBQixp1SB0HyD3Cjyp19xxcT0gM=; b=FhWDy6hKlkOowak2pt8wBS6rmODGu55dhRG9nukTCTHW0RTdn2VunLd2Nby5nP5e7d uKAdkjVRw4v2t1KvKWqVP9p6Er/KS5udwffG5coOUOUqvAu89U6y9FmiFviLcWanaxFd jP7bYGieK1Hbvr7kMS3lEL1St9eD1A6NuPjjbac0ICV0zypGVo3eLQSeNlcr2fSwLiAb 56a7V0Xncd3/I1Gwb2MJ2mdh0XxXt5Gm0tR9Sks/OaA/J+Pe5FsluKUgQOI5SURCBFmk LsAaaZltaBTR1B/SbjVGux5qCdKRyjPZxAcTclNWvLVfZCaSBJ7dHiSxOLQuU0DFligU 4M5g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:message-id:subject:from:reply-to:to:cc:date :in-reply-to:references:organization:mime-version :content-transfer-encoding; bh=QMLenloMIZn4CEHdlBQixp1SB0HyD3Cjyp19xxcT0gM=; b=LUZ6zKMoLS+NbT1wsgy9qAhBxaVYz9TyJJJiZhVc7oJ02rwST5zPjY/3cpMkYGgTI7 TnVWxxlHfWOJ8/Rvs88kHVu9+gyPkpl8CZA9yLXy+2J1NhpEBXixWuDGTKSIfP/2qtEJ sbv5giEPTwYk3zWyrUVyy5h9nUwKe0fcs3QX4JEDXYhbaBNjaBCjVCdfmVRVbY7J02ll 6S81jLNWRcHE6V5jIZBhBKfQMD6nsdC0Uv9ZRp0rO+Nmfb2Hiz2X8+ZMBJG9Hvq1W7e/ Fiph/Ves+t4bRj5TDyLr/orizVd3/b7PQJ5k6IP7225F6oK8VnbsvwXWTXsVdW817lE5 gBGQ== X-Gm-Message-State: ALyK8tLeHWtISuAT9l1LPMgrXeEE34UYdwinbZIWAAwLgdN4j7hi7/3twhnAME7XcaowiivG X-Received: by 10.28.224.5 with SMTP id x5mr20157487wmg.11.1466172939814; Fri, 17 Jun 2016 07:15:39 -0700 (PDT) Received: from ?IPv6:2001:720:410:1010:2247:47ff:fedb:3d7e? ([2001:720:410:1010:2247:47ff:fedb:3d7e]) by smtp.gmail.com with ESMTPSA id xs9sm46119936wjc.11.2016.06.17.07.15.38 (version=TLSv1/SSLv3 cipher=OTHER); Fri, 17 Jun 2016 07:15:39 -0700 (PDT) Message-ID: <1466172938.4418.26.camel@it.uc3m.es> From: Carlos =?ISO-8859-1?Q?Jes=FAs?= Bernardos Cano To: Tore Anderson Date: Fri, 17 Jun 2016 16:15:38 +0200 In-Reply-To: <20160611094910.601ccb99@envy> References: <1462213046.4232.31.camel@it.uc3m.es> <20160611094910.601ccb99@envy> Organization: Universidad Carlos III de Madrid Content-Type: text/plain; charset="UTF-8" X-Mailer: Evolution 3.18.5.1-1+b1 Mime-Version: 1.0 Content-Transfer-Encoding: 8bit Archived-At: Cc: draft-ietf-6man-deprecate-atomfrag-generation@ietf.org, int-ads@ietf.org, int-dir@ietf.org Subject: Re: [Int-dir] INT area directorate review for draft-ietf-6man-deprecate-atomfrag-generation X-BeenThere: int-dir@ietf.org X-Mailman-Version: 2.1.17 Precedence: list Reply-To: cjbc@it.uc3m.es List-Id: "This list is for discussion between the members of the Internet Area directorate." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 17 Jun 2016 14:15:46 -0000 Hi Tore, Sorry for the late reply. Please see inline below. On Sat, 2016-06-11 at 09:49 +0200, Tore Anderson wrote: > Hello Carlos, thank you for your review, and apologies for the much > belated reply. > > * Carlos Jesús Bernardos Cano > > > > > Overall, the document is mature, well written and I find it useful. > > I > > do not see any reason to hold up publication. > Thank you! > > > > > Some minor detailed suggestions follow: > > > > - Section 1: The text says: 'Section 5 of [RFC2460] states that, > > when a > > host receives an ICMPv6 "Packet Too Big" message [RFC4443] > > advertising > > an MTU smaller than 1280 bytes (the minimum IPv6 MTU), the host is > > not > > required to reduce the assumed Path-MTU, but must simply include a > > Fragment Header in all subsequent packets sent to that > > destination.' > > > > RFC2460 actually says 'In response to an IPv6 packet that is sent > > to an > > IPv4 destination (i.e., a packet that undergoes translation from > > IPv6 > > to IPv4), the originating IPv6 node may receive an ICMP Packet Too > > Big > > message reporting a Next-Hop MTU less than 1280.' > > > > While the document states later that 'an IPv6 node cannot easily > > limit > > its exposure to the aforementioned attack vector by only generating > > IPv6 atomic fragments towards IPv4 destinations behind a stateless > > translator', it would help the reader to add that piece of context > > from > > the very beginning of the document. > Point taken. What do you think about amending Section 1 like so: > >    [RFC2460] specifies the IPv6 fragmentation mechanism, which allows >    IPv6 packets to be fragmented into smaller pieces such that they > can >    fit in the Path-MTU to the intended destination(s). > >    An IPv4/IPv6 translator implementing the Stateless IP/ICMP >    Translation algorithm [RFC6145] may legitimately generate ICMPv6 >    "Packet Too Big" messages [RFC4443] advertising a "Next-Hop MTU" >    smaller than 1280 (the minimum IPv6 MTU). > >    Section 5 of [RFC2460] states that, upon receiving such an ICMPv6 >    message, hosts are not required to reduce the assumed Path-MTU, > but >    must simply include a Fragment Header in all subsequent packets > sent >    to that destination. [...] [Carlos] That's sounds good to me. Thanks! > > > > > - Section 2: Again, I think it would help adding the context about > >   RFC2460 using atomic fragments only for the purpose of helping an > >   IPv6- to-IPv4 translating router can obtain a suitable > >   Identification value to use in resulting IPv4 fragments. > Section 2 says: > >    o  As noted in Section 3, SIIT [RFC6145] (including derivative >       protocols such as Stateful NAT64 [RFC6146]) is the only > technology >       which currently makes use of atomic fragments. > > And section 3 says: > >    We note that SIIT essentially employs the Fragment Header of IPv6 >    atomic fragments to signal the translator how to set the DF bit of >    IPv4 datagrams (the DF bit is cleared when the IPv6 packet > contains a >    Fragment Header, and is otherwise set to 1 when the IPv6 packet > does >    not contain an IPv6 Fragment Header). > > I feel it would be redundant to duplicate this text in section 2. > Isn't > the reference too section 3 sufficient? [Carlos] Well, I don't have a very strong position on this. IMHO, it makes more readable the document to be a bit redundant, but make the text clearer in Section 2, but I agree that the document, as is, is not missing information. Thanks! Carlos > > > > > - Section 3: when discussing IPv4 Identification collision rates, > > it > > would be helpful adding some numbers/equations there to get an idea > > of > > what rates we are talking about. > I leave this one to Fernando. > > > > > - Appendix A: what does 'Linux kernel current' mean? This is very > > minor, as this section is probably to be removed, but in case it > > remains after publication as RFC, current should be replaced by the > > kernel version number. > This one too; I don't know which kernel version «current» refers to. > > Tore