From nobody Fri Jul 1 08:39:27 2016 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 62B8712D755 for ; Fri, 1 Jul 2016 08:39:24 -0700 (PDT) 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 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 hf4KQca_4sOM for ; Fri, 1 Jul 2016 08:39:22 -0700 (PDT) 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 9578B12D757 for ; Fri, 1 Jul 2016 08:39:15 -0700 (PDT) Received: from clairseach.fuaim.com (clairseach-high.fuaim.com [206.197.161.158]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by uillean.fuaim.com (Postfix) with ESMTP id 7E4DB8814A for ; Fri, 1 Jul 2016 08:39:15 -0700 (PDT) Received: from clemson.jhuapl.edu (swifi-nat.jhuapl.edu [128.244.87.133]) (using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by clairseach.fuaim.com (Postfix) with ESMTP id 42FC23280ADF for ; Fri, 1 Jul 2016 08:39:15 -0700 (PDT) Subject: Fwd: New Version Notification for draft-bchv-rfc6890bis-00.txt References: <20160701153641.24636.69476.idtracker@ietfa.amsl.com> To: "ipv6@ietf.org" From: Brian Haberman X-Forwarded-Message-Id: <20160701153641.24636.69476.idtracker@ietfa.amsl.com> Message-ID: <8cb3aa9b-e157-794b-2dbf-f63e20cfdc62@innovationslab.net> Date: Fri, 1 Jul 2016 11:39:07 -0400 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:45.0) Gecko/20100101 Thunderbird/45.1.1 MIME-Version: 1.0 In-Reply-To: <20160701153641.24636.69476.idtracker@ietfa.amsl.com> Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="iviS927KtRf3r4VaCLgx34n82QP6f3sMt" Archived-At: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 01 Jul 2016 15:39:24 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --iviS927KtRf3r4VaCLgx34n82QP6f3sMt Content-Type: multipart/mixed; boundary="DLQj3FhOLbT8Kd9ENrpl5bSAUO8ghKh8s" From: Brian Haberman To: "ipv6@ietf.org" Message-ID: <8cb3aa9b-e157-794b-2dbf-f63e20cfdc62@innovationslab.net> Subject: Fwd: New Version Notification for draft-bchv-rfc6890bis-00.txt References: <20160701153641.24636.69476.idtracker@ietfa.amsl.com> In-Reply-To: <20160701153641.24636.69476.idtracker@ietfa.amsl.com> --DLQj3FhOLbT8Kd9ENrpl5bSAUO8ghKh8s Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable All, This draft is intended to fix the issue raised by Brian Carpenter with respect to the IANA special-purpose address registries. It incorporates the proposed change that updates the ULA entry in the registry and adds a reference to find more info on the prefix. Comments/suggestions are encouraged. Regards, Brian -------- Forwarded Message -------- Subject: New Version Notification for draft-bchv-rfc6890bis-00.txt Date: Fri, 01 Jul 2016 08:36:41 -0700 From: internet-drafts@ietf.org To: Ronald Bonica , Michelle Cotton , Brian Haberman , Leo Vegoda , Ron Bonica , Michelle S. Cotton A new version of I-D, draft-bchv-rfc6890bis-00.txt has been successfully submitted by Brian Haberman and posted to the IETF repository. Name: draft-bchv-rfc6890bis Revision: 00 Title: Special-Purpose IP Address Registries Document date: 2016-07-01 Group: Individual Submission Pages: 22 URL: https://www.ietf.org/internet-drafts/draft-bchv-rfc6890bis-00.txt Status: https://datatracker.ietf.org/doc/draft-bchv-rfc6890bis/ Htmlized: https://tools.ietf.org/html/draft-bchv-rfc6890bis-00 Abstract: This memo updates the IANA IPv6 Special-Purpose Address Registries to address issues raised by the definition of a global prefix. For completeness, this memo contains all the assignments made by RFC 6890 to the IANA Special-Purpose Address Registries. This memo obsoletes RFC 6890. Please note that it may take a couple of minutes from the time of submiss= ion until the htmlized version and diff are available at tools.ietf.org. The IETF Secretariat --DLQj3FhOLbT8Kd9ENrpl5bSAUO8ghKh8s-- --iviS927KtRf3r4VaCLgx34n82QP6f3sMt Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- iQEcBAEBCAAGBQJXdo6gAAoJEBOZRqCi7goqokwIAMiLzhYuCpay/TCtDes1NlBo XeaX/Ar/RjWE2kROj/HvF5zJIfGUXm0WmdfVPpEHi6HOpqSRTnxo7gaieX02sa38 E/rCGSj6xILkMzboMI9wygyzDOHjDdEjqo6C039OaJ6ZhVjQaDj3tsriwhqo5XbS mQ6MkVwghVuMpUKo4gNO1mPyEmtF7fvYGrdA4eV3B8a1o2ohKDUK7zC6GbwGft1I hh0eI8Qkq0z5+Xa1+L/T0tmSXEv41DPPZq5fAAtqpXR7u3Al4oAJpdZfki1PkZpQ KFRGDGYqEDPH0fIlG0FWK3ha6fGTndF1VecvOM0N1lI9Wr2a73Oedn/mt1h5Y+c= =ePQo -----END PGP SIGNATURE----- --iviS927KtRf3r4VaCLgx34n82QP6f3sMt-- From nobody Fri Jul 8 05:04:46 2016 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 677EB12D1B8 for ; Fri, 8 Jul 2016 05:04:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.45 X-Spam-Level: X-Spam-Status: No, score=-2.45 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_ENVFROM_END_DIGIT=0.25, 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 dYh0dV2tAdyf for ; Fri, 8 Jul 2016 05:04:42 -0700 (PDT) Received: from mail-it0-x242.google.com (mail-it0-x242.google.com [IPv6:2607:f8b0:4001:c0b::242]) (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 8BC4C12D16B for ; Fri, 8 Jul 2016 05:04:40 -0700 (PDT) Received: by mail-it0-x242.google.com with SMTP id u186so3241017ita.1 for ; Fri, 08 Jul 2016 05:04:40 -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=EKh09wzP/whfb4K3aQOToYYW97qWV47vJmzTZ1gPhFk=; b=L2NswgkqN+AOjwEypUUdZbePZbGnKhv7PNIivlQry1TtSriQf+qHYi2zVPHppHBKu1 KvCUarXfjI5d9Tlg32+8ZKUS1gNLqTnnp//pMMvSkb5C7a1UN1xjIpJz9f1xwSm5WUZ1 OtahsswwvcSOvpUwQv68XIFCrdDMn/DITn6l8pRjFth7oMwvunrEQo/XBZZBZRZZMyNi rVm991yJwvIToyE5u0qWoXagC4WbFWPPz16B7vxaYaIrkhKR6bOSS8UV/8kbGBBKO7jo 63D4F85jngtakzoyPLUvWEcx746txoDgJqNtol8rU+XNdD6NqqJrjaRgfAhNt8P3tPMi Bj2A== 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=EKh09wzP/whfb4K3aQOToYYW97qWV47vJmzTZ1gPhFk=; b=RH5AT/nD9unTQf3EeByqessjCaEQYeGo2Ui9PzgfW+eV0d/WZ2sHJhYFFPAmK/Czn6 UxJz8treaALKhCM9ciZzQ+a/+QkGqCzej63SeQU1DmIanH82U57ecACptHNUYRJONeBA iRtftbNd+azbIBe9RuDY39VbpOZFdKe77ezEvn8ATZph8hZWzTzAWzFYCexS7rt1Nr+B zpmF2ywq1u2sDI9awoYmOLeDpNdnhDO5otQSlri2BvwXZl4CHmeTWdN/p5vWSqQOBEfF ZyXpG0yIPC+HY142jsvpkWMwtfgeqFbaMJ/oPJZAHjtQznBEa39YXd/KWq8dsOa0gnYD fxrg== X-Gm-Message-State: ALyK8tL6P9MN9it783yn5ZNHZu4ZJzDhR/dIag/1yhyAe6a2XksSAOIKnKxGVVulqu5Vdi+2pmB2gOKxuY7oZw== X-Received: by 10.36.200.131 with SMTP id w125mr2600012itf.80.1467979479768; Fri, 08 Jul 2016 05:04:39 -0700 (PDT) MIME-Version: 1.0 Received: by 10.64.187.37 with HTTP; Fri, 8 Jul 2016 05:04:20 -0700 (PDT) In-Reply-To: References: <20160706005825.22318.33162.idtracker@ietfa.amsl.com> From: Jen Linkova Date: Fri, 8 Jul 2016 14:04:20 +0200 Message-ID: Subject: Fwd: New Version Notification for draft-bowbakova-rtgwg-enterprise-pa-multihoming-00.txt To: 6man Content-Type: multipart/mixed; boundary=94eb2c05ab586e0a4005371e9b6f Archived-At: Cc: "Fred Baker \(fred\)" , cbowers@juniper.net X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 08 Jul 2016 12:04:44 -0000 --94eb2c05ab586e0a4005371e9b6f Content-Type: text/plain; charset=UTF-8 This draft has been sent for review to RTGWG and v6ops already. I believe this document might be of interest for 6man as well (especially Section 4). Feedback is highly appreciated. Thanks! ---------- Forwarded message ---------- > > From: > Subject: New Version Notification for draft-bowbakova-rtgwg-enterprise-pa-multihoming-00.txt > Date: July 5, 2016 at 5:58:25 PM PDT > To: Chris Bowers , Jen Linkova , "Fred Baker" , "J. Linkova" > > > A new version of I-D, draft-bowbakova-rtgwg-enterprise-pa-multihoming-00.txt > has been successfully submitted by Fred Baker and posted to the > IETF repository. > > Name: draft-bowbakova-rtgwg-enterprise-pa-multihoming > Revision: 00 > Title: Enterprise Multihoming using Provider-Assigned Addresses without Network Prefix Translation: Requirements and Solution > Document date: 2016-07-05 > Group: Individual Submission > Pages: 44 > URL: https://www.ietf.org/internet-drafts/draft-bowbakova-rtgwg-enterprise-pa-multihoming-00.txt > Status: https://datatracker.ietf.org/doc/draft-bowbakova-rtgwg-enterprise-pa-multihoming/ > Htmlized: https://tools.ietf.org/html/draft-bowbakova-rtgwg-enterprise-pa-multihoming-00 > > > Abstract: > Connecting an enterprise site to multiple ISPs using provider- > assigned addresses is difficult without the use of some form of > Network Address Translation (NAT). Much has been written on this > topic over the last 10 to 15 years, but it still remains a problem > without a clearly defined or widely implemented solution. Any > multihoming solution without NAT requires hosts at the site to have > addresses from each ISP and to select the egress ISP by selecting a > source address for outgoing packets. It also requires routers at the > site to take into account those source addresses when forwarding > packets out towards the ISPs. > > This document attempts to define a complete solution to this problem. > It covers the behavior of routers to forward traffic taking into > account source address, and it covers the behavior of host to select > appropriate source addresses. It also covers any possible role that > routers might play in providing information to hosts to help them > select appropriate source addresses. In the process of exploring > potential solutions, this documents also makes explicit requirements > for how the solution would be expected to behave from the perspective > of an enterprise site network administrator . > > > > > Please note that it may take a couple of minutes from the time of submission > until the htmlized version and diff are available at tools.ietf.org. > > The IETF Secretariat > -- SY, Jen Linkova aka Furry --94eb2c05ab586e0a4005371e9b6f Content-Type: application/pgp-signature; name="signature.asc" Content-Disposition: attachment; filename="signature.asc" Content-Transfer-Encoding: base64 X-Attachment-Id: 8fab61512946aac7_0.0.1 LS0tLS1CRUdJTiBQR1AgU0lHTkFUVVJFLS0tLS0NCkNvbW1lbnQ6IEdQR1Rvb2xzIC0gaHR0cDov L2dwZ3Rvb2xzLm9yZw0KDQppUUlWQXdVQlYzMHpNa2F5QU9TL0VROE1BUUtvd0EvK1B5VVM3VzB4 d3Q3VEt5QmQzNDgxdzQ5NXFlTnp3NkUzDQpCNlVpYU83MnRMbGt3citzZGRuVkdwbVBmbCtHMTdw NXpPc2t6MHBIRFJmVEpUZlBZRUFuTlZpNDVScGhkWUtlDQpUTXljNGxsRXJUdWNNUStBbCtldjJE eFVUaHg3S3BmZzB1L0szZFYwM3J5dTJqWkNnNDVDMXM3Ty9ZTE00VjRoDQoycThiMjQ3eEI5QnJR VTVqaVpOVm5wUk16ZVJLY1JyMXd1Q1NZdFh1cUR4cllPVzViVHpZOTd4TmZzcDhlTmxzDQp2Zk4w eitXNU55QmpGZEZtQUFFWWxwZ2tuM2hMUVd6djdwRERscW1nZUlkQ281L0tVd25NR01RZ1BKSnFO OVZqDQo4Q1JjMnU1S01naFd1a050bFlCWVYzejZzN0swODBxbmNSRGkyV044VmZTOExmRENYblZJ bDdVa3Z6eW41a2ZlDQp2aDBFcFZrRnBia0I0dEUvRktLNkpTV0w1S2JSWXBJTVN1OXc1WjhydjRQ WDRtOUI5MmhaUTByRmhjNExIQWJjDQpKcnJLSXNhTnQzNXVqeU04eHdMN0hSYnVKQmZ6YUFuTkwx SFB5V1JYYjdSN3FSMjhFcW9FN2owZG9McWx4d2puDQpjUlMzMjc5RndpMWZUazdEU1NLYk1qNGJH Uytla1dWMHptQW93OWtCeGdHMTBLL2lZTW1UVkNhUHZOTi9YM1ZRDQoxOXB1Y3l4TmUzRjNBS21J Y3I0R29LYUJXZWNiaFNsdmlDNnNoeFF2N2x2RURGU0RjcXJVQVFNbUlrYy9zWWZpDQpMOU45b2R4 b1RyMlBWVEE0NUlHT1F0ZlptenBRMktudktDTFpGYng5b0VuZW91b2RuVmk0UE9pQnN2czJValZm DQpiSG01ZUY0dE5qMD0NCj1tKzJRDQotLS0tLUVORCBQR1AgU0lHTkFUVVJFLS0tLS0NCg== --94eb2c05ab586e0a4005371e9b6f-- From nobody Fri Jul 8 06:56:47 2016 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 02EE212D1A4 for ; Fri, 8 Jul 2016 06:56:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.353 X-Spam-Level: X-Spam-Status: No, score=-5.353 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_ADSP_CUSTOM_MED=0.001, FREEMAIL_FROM=0.001, NML_ADSP_CUSTOM_MED=0.9, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_SOFTFAIL=0.665] 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 W_1LXcqc_-hr for ; Fri, 8 Jul 2016 06:56:42 -0700 (PDT) Received: from oxalide-out.extra.cea.fr (oxalide-out.extra.cea.fr [132.168.224.8]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 291C112D16B for ; Fri, 8 Jul 2016 06:56:41 -0700 (PDT) Received: from pisaure.intra.cea.fr (pisaure.intra.cea.fr [132.166.88.21]) by oxalide.extra.cea.fr (8.15.2/8.15.2/CEAnet-Internet-out-2.4) with ESMTP id u68DueX8012424 for ; Fri, 8 Jul 2016 15:56:40 +0200 Received: from pisaure.intra.cea.fr (localhost [127.0.0.1]) by localhost (Postfix) with SMTP id 4A221202853 for ; Fri, 8 Jul 2016 15:56:40 +0200 (CEST) Received: from muguet2.intra.cea.fr (muguet2.intra.cea.fr [132.166.192.7]) by pisaure.intra.cea.fr (Postfix) with ESMTP id 37301200EFE for ; Fri, 8 Jul 2016 15:56:40 +0200 (CEST) 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 u68DueX8023572 for ; Fri, 8 Jul 2016 15:56:40 +0200 Subject: Reference to "3333" value of RFC2464 "IPv6 over Ethernet" To: IPv6 References: <20160701153641.24636.69476.idtracker@ietfa.amsl.com> <8cb3aa9b-e157-794b-2dbf-f63e20cfdc62@innovationslab.net> From: Alexandre Petrescu Message-ID: <6c26fb03-7218-ff28-3488-887f6cd0f1fe@gmail.com> Date: Fri, 8 Jul 2016 15:56:39 +0200 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: <8cb3aa9b-e157-794b-2dbf-f63e20cfdc62@innovationslab.net> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Archived-At: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 08 Jul 2016 13:56:44 -0000 Hello, RFC2464 "IPv6 over Ethernet" says: > 7. Address Mapping -- Multicast > > An IPv6 packet with a multicast destination address DST, consisting > of the sixteen octets DST[1] through DST[16], is transmitted to the > Ethernet multicast address whose first two octets are the value 3333 > hexadecimal and whose last four octets are the last four octets of > DST. Where is this "3333" value defined? Obviously an RFC is not the place to define an Ethernet multicast address. Alex From nobody Fri Jul 8 07:21:12 2016 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5B4B612B051 for ; Fri, 8 Jul 2016 07:21:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.45 X-Spam-Level: X-Spam-Status: No, score=-2.45 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_ENVFROM_END_DIGIT=0.25, 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 O3-OpIINcV-2 for ; Fri, 8 Jul 2016 07:21:08 -0700 (PDT) Received: from mail-it0-x241.google.com (mail-it0-x241.google.com [IPv6:2607:f8b0:4001:c0b::241]) (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 40CEE12B00F for ; Fri, 8 Jul 2016 07:21:08 -0700 (PDT) Received: by mail-it0-x241.google.com with SMTP id u186so4492863ita.1 for ; Fri, 08 Jul 2016 07:21:08 -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=Uyg84o6T0P1+zJhHQd7boupjuwTo5OrOymGP67Lu6mE=; b=Gp5BwyEYNfOgI4MdjaTDSzcwEuUdgEilzNML5NBdp74w0fbUvuyYG7TNASoh275HNl CkSQROsBdrH/OYBeFK+n1MR7+T2+ZEFsMF/xPWfEms0cNI18rPTxQUxBDabW/JIOO+/e 6WJgQX9Antjspbp2BESmAOe/FzWZAH1wm0FTqHVmAKC54am2T3xPi22U2hBA7zd1p7XL xk65H7Z+3h2Cx7g057pHkwXkMV7+IvBnkiTdz/2oW6IdyAZYRJlNkVW/bcnbnjrpJ4XL W2RVyGaHVpld0gpaZb/94/gEbgf6pUqhFNBXQnnh9Ccah+H/g/U/VBqUnJ1yj8aH8ge6 aU3Q== 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=Uyg84o6T0P1+zJhHQd7boupjuwTo5OrOymGP67Lu6mE=; b=nDbBzQknnhGiGP3duuv07wJI3ctbuR0l2wX4xMusVPivzyCk0ifXHfJbiONOkoAyDq qe1cJUx2GoOgoHJIPz2k2MBS7go9ItknWR430UXvFugkhIno7Vlfh6y3ebkGi0+M8YwO MELXvYgKlzlR3b4vhgAnVgAs7jYQ3wZU+omXu5Ws0OS3uzPHXgFvk8/QbyHDHA4OXaJM ROgheRFob2/ZmqT4Do/PP3EERbscIhD2QYxQ8UMJXjS8XVt9IttCFxPqCDTSYYNtdEMl Ua9hfLDCEMw0q4djNEvAbspYADwyBPSY8gGCalgkRflTrpzWp/oVMZBuPEMXeI7Ni+oG kj3A== X-Gm-Message-State: ALyK8tKYJd4AptIsvq80FmSZlV4wB986AMAVMIDM2FuIPqGrnr6dFkDAorQ/xALl7pFzU5D5j8EsJsIj3Hctkw== X-Received: by 10.36.155.198 with SMTP id o189mr3613717itd.54.1467987667595; Fri, 08 Jul 2016 07:21:07 -0700 (PDT) MIME-Version: 1.0 Received: by 10.64.187.37 with HTTP; Fri, 8 Jul 2016 07:20:47 -0700 (PDT) In-Reply-To: <6c26fb03-7218-ff28-3488-887f6cd0f1fe@gmail.com> References: <20160701153641.24636.69476.idtracker@ietfa.amsl.com> <8cb3aa9b-e157-794b-2dbf-f63e20cfdc62@innovationslab.net> <6c26fb03-7218-ff28-3488-887f6cd0f1fe@gmail.com> From: Jen Linkova Date: Fri, 8 Jul 2016 16:20:47 +0200 Message-ID: Subject: Re: Reference to "3333" value of RFC2464 "IPv6 over Ethernet" To: Alexandre Petrescu Content-Type: text/plain; charset=UTF-8 Archived-At: Cc: IPv6 X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 08 Jul 2016 14:21:10 -0000 On Fri, Jul 8, 2016 at 3:56 PM, Alexandre Petrescu wrote: > Hello, > > RFC2464 "IPv6 over Ethernet" says: >> >> 7. Address Mapping -- Multicast >> >> An IPv6 packet with a multicast destination address DST, consisting >> of the sixteen octets DST[1] through DST[16], is transmitted to the >> Ethernet multicast address whose first two octets are the value 3333 >> hexadecimal and whose last four octets are the last four octets of >> DST. > > > Where is this "3333" value defined? Obviously an RFC is not the place to > define an Ethernet multicast address. https://tools.ietf.org/html/rfc5342#section-2.3.1 Please note that it has 'local; bit set so that OUI range (33-33-XX did not need to be purchased). > > Alex > > -------------------------------------------------------------------- > IETF IPv6 working group mailing list > ipv6@ietf.org > Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 > -------------------------------------------------------------------- -- SY, Jen Linkova aka Furry From nobody Fri Jul 8 07:49:28 2016 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6A0D912D09F for ; Fri, 8 Jul 2016 07:49:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.333 X-Spam-Level: X-Spam-Status: No, score=-5.333 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_ADSP_CUSTOM_MED=0.001, FREEMAIL_FROM=0.001, NML_ADSP_CUSTOM_MED=0.9, RCVD_IN_DNSWL_HI=-5, SPF_SOFTFAIL=0.665] 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 XpAp2RCSmSPP for ; Fri, 8 Jul 2016 07:49:25 -0700 (PDT) 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 24E1E12B063 for ; Fri, 8 Jul 2016 07:49:24 -0700 (PDT) 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 u68EnMCD016075; Fri, 8 Jul 2016 16:49:22 +0200 Received: from pisaure.intra.cea.fr (localhost [127.0.0.1]) by localhost (Postfix) with SMTP id 954712096E7; Fri, 8 Jul 2016 16:49:22 +0200 (CEST) Received: from muguet2.intra.cea.fr (muguet2.intra.cea.fr [132.166.192.7]) by pisaure.intra.cea.fr (Postfix) with ESMTP id 876DC2096E4; Fri, 8 Jul 2016 16:49:22 +0200 (CEST) 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 u68EnMue032369; Fri, 8 Jul 2016 16:49:22 +0200 Subject: Re: Reference to "3333" value of RFC2464 "IPv6 over Ethernet" To: Jen Linkova References: <20160701153641.24636.69476.idtracker@ietfa.amsl.com> <8cb3aa9b-e157-794b-2dbf-f63e20cfdc62@innovationslab.net> <6c26fb03-7218-ff28-3488-887f6cd0f1fe@gmail.com> From: Alexandre Petrescu Message-ID: <2240c1fd-e8f2-478b-ea41-b01aec9f5954@gmail.com> Date: Fri, 8 Jul 2016 16:49:22 +0200 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; format=flowed Content-Transfer-Encoding: 8bit Archived-At: Cc: IPv6 X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 08 Jul 2016 14:49:27 -0000 Le 08/07/2016 à 16:20, Jen Linkova a écrit : > On Fri, Jul 8, 2016 at 3:56 PM, Alexandre Petrescu > wrote: >> Hello, >> >> RFC2464 "IPv6 over Ethernet" says: >>> >>> 7. Address Mapping -- Multicast >>> >>> An IPv6 packet with a multicast destination address DST, consisting >>> of the sixteen octets DST[1] through DST[16], is transmitted to the >>> Ethernet multicast address whose first two octets are the value 3333 >>> hexadecimal and whose last four octets are the last four octets of >>> DST. >> >> >> Where is this "3333" value defined? Obviously an RFC is not the place to >> define an Ethernet multicast address. > > https://tools.ietf.org/html/rfc5342#section-2.3.1 > > Please note that it has 'local; bit set so that OUI range (33-33-XX > did not need to be purchased). Why isn't this address listed by IEEE "GROUP MAC PUBLIC LISTING"? https://standards.ieee.org/develop/regauth/grpmac/public.html Why IEEE lists _other_ addresses that can be used for same role: 01-80-C2-00-00-1D ISO/IEC JTC1/SC6 ISO/IEC 9542 "All Multicast Capable Intermediate Systems Address" RFC5342 says: > All MAC-48 multicast identifiers prefixed "33-33" (that is, the 2**32 > multicast MAC identifiers in the range from 33-33-00-00-00-00 to > 33-33-FF-FF-FF-FF) are used by the IETF for global IPv6 multicast > [RFC2464]. What does "global IPv6 multicast" mean? The term "global" is misleading because of that 'local' bit set you said above, and because RFC2464 is happening only on a link. Maybe it meant "IPv6 multicast"? Why does it refer to RFC2464? RFC2464 is only for Ethernet, not for other kinds of links. It reads as if all Internet-connected nodes were on Ethernet and as if any IP multicast address could be mapped into the 32bits left of a MAC multicast address (they cant - they are 112bit length). Alex > > >> >> Alex >> >> -------------------------------------------------------------------- >> IETF IPv6 working group mailing list >> ipv6@ietf.org >> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 >> -------------------------------------------------------------------- > > > From nobody Fri Jul 8 08:31:56 2016 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 67A0112D096 for ; Fri, 8 Jul 2016 08:31:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.45 X-Spam-Level: X-Spam-Status: No, score=-2.45 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_ENVFROM_END_DIGIT=0.25, 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 EXzCT0MZoGG8 for ; Fri, 8 Jul 2016 08:31:53 -0700 (PDT) Received: from mail-pf0-x244.google.com (mail-pf0-x244.google.com [IPv6:2607:f8b0:400e:c00::244]) (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 687F812D5D6 for ; Fri, 8 Jul 2016 08:31:52 -0700 (PDT) Received: by mail-pf0-x244.google.com with SMTP id i123so8343118pfg.3 for ; Fri, 08 Jul 2016 08:31:52 -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=685IH3pgZMqZoa51O87Kioe8BzZzjZR8cKifP+9tJIE=; b=LNF8U+KrpkNjMpZ28DrDDZCmfTcDQcQUXAy4jKRi0LibV3s3UFEvVZkuCl7Wg/jZCb BHxZc898Ug23eVD5ZWqpFd9G6DaYh0WjaDyudgko9E2N1whWat8XHvVgQ9gA6/lRnDf4 bfjNaVF8txdCrhybUdkG5wxHozrXbrf6frogyYSWdWANAeCyC3HWbEUUABrcOoz5hzzl 92WyPFBDV4NonSJ2uYPykDVpZxB7Xf6uMN6LRUUaOzsg/UPg9Ntj/T2S1JZT1JQR/a98 sXk7asCaLppHCrySFHL+v7VkiP6NClBCaDysiEBW77kwNSSHtEX5qQv6rODZX3FR2pIL Ll5w== 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=685IH3pgZMqZoa51O87Kioe8BzZzjZR8cKifP+9tJIE=; b=LWm0xxnAUJJ0rnnKYnyRMuggrCvhMhub1zzq3H+WX7A2o1XeteCjnwq82aibHqlwng RVseLMLtH61v2z6NbVlGtDnwPLARKCrSYnyzj4DRb8BMD6OkKKASohXWh2qfXKcsMGdi TzMxrcuo6Jm7FzfC7KdnF8RHkBi4dAAi7GbaLWQxE/+RS9ErhRMz8GpvWiBnakY0j4yc nU5Ax7+rqihYBXGNzsCOYClubm3RKDYFJ9Zdb2ysIACa1EfHMVlzvb1eO89HdVdpbp1v hji9LZkrj6G9vO1CHXsdUdxZBj3cSE7HaBDSz8szYo7+6reN5DU3s7IxW3rZPoc32Vvu TmEA== X-Gm-Message-State: ALyK8tIp3KDaEw2bnW7sKFaDbi+91raex5/PlaNLfVRLI89g40VwKzi2JaSZeizms7mQf/sVksBfutbzqchaKw== X-Received: by 10.107.189.70 with SMTP id n67mr8634152iof.72.1467991911820; Fri, 08 Jul 2016 08:31:51 -0700 (PDT) MIME-Version: 1.0 Received: by 10.64.187.37 with HTTP; Fri, 8 Jul 2016 08:31:32 -0700 (PDT) In-Reply-To: <2240c1fd-e8f2-478b-ea41-b01aec9f5954@gmail.com> References: <20160701153641.24636.69476.idtracker@ietfa.amsl.com> <8cb3aa9b-e157-794b-2dbf-f63e20cfdc62@innovationslab.net> <6c26fb03-7218-ff28-3488-887f6cd0f1fe@gmail.com> <2240c1fd-e8f2-478b-ea41-b01aec9f5954@gmail.com> From: Jen Linkova Date: Fri, 8 Jul 2016 17:31:32 +0200 Message-ID: Subject: Re: Reference to "3333" value of RFC2464 "IPv6 over Ethernet" To: Alexandre Petrescu Content-Type: text/plain; charset=UTF-8 Archived-At: Cc: IPv6 X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 08 Jul 2016 15:31:55 -0000 On Fri, Jul 8, 2016 at 4:49 PM, Alexandre Petrescu wrote: >>> RFC2464 "IPv6 over Ethernet" says: >>>> 7. Address Mapping -- Multicast >>>> >>>> An IPv6 packet with a multicast destination address DST, consisting >>>> of the sixteen octets DST[1] through DST[16], is transmitted to the >>>> Ethernet multicast address whose first two octets are the value 3333 >>>> hexadecimal and whose last four octets are the last four octets of >>>> DST. >>> >>> >>> Where is this "3333" value defined? Obviously an RFC is not the place to >>> define an Ethernet multicast address. >> >> >> https://tools.ietf.org/html/rfc5342#section-2.3.1 >> >> Please note that it has 'local; bit set so that OUI range (33-33-XX >> did not need to be purchased). > > > Why isn't this address listed by IEEE "GROUP MAC PUBLIC LISTING"? > https://standards.ieee.org/develop/regauth/grpmac/public.html > Why IEEE lists _other_ addresses that can be used for same role: > 01-80-C2-00-00-1D ISO/IEC JTC1/SC6 ISO/IEC 9542 > "All Multicast Capable Intermediate Systems Address" Because the OUI 33-33- is *locally administered* (it has the Local bit set). It is not allocated by any registry. The link you are referring to lists addresses from the Universally Administered Address Block. > RFC5342 says: >> >> All MAC-48 multicast identifiers prefixed "33-33" (that is, the 2**32 >> multicast MAC identifiers in the range from 33-33-00-00-00-00 to >> 33-33-FF-FF-FF-FF) are used by the IETF for global IPv6 multicast >> [RFC2464]. > > > What does "global IPv6 multicast" mean? The term "global" is misleading > because of that 'local' bit set you said above, and because RFC2464 is > happening only on a link. Maybe it meant "IPv6 multicast"? > > Why does it refer to RFC2464? RFC2464 is only for Ethernet, not for other > kinds of links. > > It reads as if all Internet-connected nodes were on Ethernet and as if any > IP multicast address could be mapped into the 32bits left of a MAC multicast > address (they cant - they are 112bit length). AFAIR RFC3307 has some recommendations on how to minimize the chance of address collision. -- SY, Jen Linkova aka Furry From nobody Fri Jul 8 09:16:45 2016 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7D4D112B02E for ; Fri, 8 Jul 2016 09:16:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.333 X-Spam-Level: X-Spam-Status: No, score=-5.333 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_ADSP_CUSTOM_MED=0.001, FREEMAIL_FROM=0.001, NML_ADSP_CUSTOM_MED=0.9, RCVD_IN_DNSWL_HI=-5, SPF_SOFTFAIL=0.665] 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 5xwg3sWoZ0IM for ; Fri, 8 Jul 2016 09:16:39 -0700 (PDT) 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 A02C012B02D for ; Fri, 8 Jul 2016 09:16:39 -0700 (PDT) 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 u68GGbuO015835; Fri, 8 Jul 2016 18:16:37 +0200 Received: from pisaure.intra.cea.fr (localhost [127.0.0.1]) by localhost (Postfix) with SMTP id 5A78F2097EB; Fri, 8 Jul 2016 18:16:37 +0200 (CEST) Received: from muguet1.intra.cea.fr (muguet1.intra.cea.fr [132.166.192.6]) by pisaure.intra.cea.fr (Postfix) with ESMTP id 4CC5020982B; Fri, 8 Jul 2016 18:16:37 +0200 (CEST) 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 u68GGaW8009131; Fri, 8 Jul 2016 18:16:37 +0200 Subject: Re: Reference to "3333" value of RFC2464 "IPv6 over Ethernet" To: Jen Linkova References: <20160701153641.24636.69476.idtracker@ietfa.amsl.com> <8cb3aa9b-e157-794b-2dbf-f63e20cfdc62@innovationslab.net> <6c26fb03-7218-ff28-3488-887f6cd0f1fe@gmail.com> <2240c1fd-e8f2-478b-ea41-b01aec9f5954@gmail.com> From: Alexandre Petrescu Message-ID: <79e33db6-48d1-2da1-60b5-10109d4d4e1d@gmail.com> Date: Fri, 8 Jul 2016 18:16:37 +0200 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; format=flowed Content-Transfer-Encoding: 8bit Archived-At: Cc: IPv6 X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 08 Jul 2016 16:16:42 -0000 Le 08/07/2016 à 17:31, Jen Linkova a écrit : > On Fri, Jul 8, 2016 at 4:49 PM, Alexandre Petrescu > wrote: >>>> RFC2464 "IPv6 over Ethernet" says: >>>>> 7. Address Mapping -- Multicast >>>>> >>>>> An IPv6 packet with a multicast destination address DST, consisting >>>>> of the sixteen octets DST[1] through DST[16], is transmitted to the >>>>> Ethernet multicast address whose first two octets are the value 3333 >>>>> hexadecimal and whose last four octets are the last four octets of >>>>> DST. >>>> >>>> >>>> Where is this "3333" value defined? Obviously an RFC is not the place to >>>> define an Ethernet multicast address. >>> >>> >>> https://tools.ietf.org/html/rfc5342#section-2.3.1 >>> >>> Please note that it has 'local; bit set so that OUI range (33-33-XX >>> did not need to be purchased). >> >> >> Why isn't this address listed by IEEE "GROUP MAC PUBLIC LISTING"? >> https://standards.ieee.org/develop/regauth/grpmac/public.html > >> Why IEEE lists _other_ addresses that can be used for same role: >> 01-80-C2-00-00-1D ISO/IEC JTC1/SC6 ISO/IEC 9542 >> "All Multicast Capable Intermediate Systems Address" > > Because the OUI 33-33- is *locally administered* (it has the Local bit set). > It is not allocated by any registry. The link you are referring to > lists addresses > from the Universally Administered Address Block. Ah! I see, ok. Still, it looks too much like an allocation. Maybe it should be at IANA, not in RFC. And the doubt about IETF allocating MAC addresses still holds in my mind. For example, can some non-IP protocol use "33-33-" to transmit non-IP datagrams to multicast MAC destinations? If no, is it because it belongs somehow to IETF? An example non-IP message is WSMP or CAM/DENM which get transmitted over 802.11p without IP headers. Currently they dont use "33-33-" as dst MAC address, but use "ff-ff-". I guess that in your logic, if "33-33-" is used then it can only be IPv6 and, reversely, if IPv6 is used then that could only be with "33-33-". I could agree with this logic if this "33-33-" address where considered in many other SDO documents, not just RFC. > >> RFC5342 says: >>> >>> All MAC-48 multicast identifiers prefixed "33-33" (that is, the 2**32 >>> multicast MAC identifiers in the range from 33-33-00-00-00-00 to >>> 33-33-FF-FF-FF-FF) are used by the IETF for global IPv6 multicast >>> [RFC2464]. >> >> >> What does "global IPv6 multicast" mean? The term "global" is misleading >> because of that 'local' bit set you said above, and because RFC2464 is >> happening only on a link. Maybe it meant "IPv6 multicast"? >> >> Why does it refer to RFC2464? RFC2464 is only for Ethernet, not for other >> kinds of links. >> >> It reads as if all Internet-connected nodes were on Ethernet and as if any >> IP multicast address could be mapped into the 32bits left of a MAC multicast >> address (they cant - they are 112bit length). > > AFAIR RFC3307 has some recommendations on how to minimize the chance > of address collision. Ok... but they are all for IPv6 multicast addresses, not for MAC multicast addresses. It's next to impossible to make sure "33-33-" will not collide with some other organization using the same "33-33-" but without IP. Alex > From nobody Fri Jul 8 11:45:56 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 87BCF12D83F; Fri, 8 Jul 2016 11:45:54 -0700 (PDT) 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-12.txt X-Test-IDTracker: no X-IETF-IDTracker: 6.25.1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20160708184554.32103.81652.idtracker@ietfa.amsl.com> Date: Fri, 08 Jul 2016 11:45:54 -0700 Archived-At: Cc: ipv6@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.17 List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 08 Jul 2016 18:45:55 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the IPv6 Maintenance 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-12.txt Pages : 23 Date : 2016-07-08 Abstract: This document changes the recommended default IID generation scheme for cases where SLAAC is used to generate a stable IPv6 address. It recommends using the mechanism specified in RFC7217 in such cases, and recommends embedding stable 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, by removing the text in these RFCs that required the IPv6 Interface Identifiers to be derived from the underlying stable link-layer address, and replacing this text with recommendations consistent with those in this document. Additionally, this document updates RFC3315 by specifying additional requirements on the generation of Interface Identifiers used in Dynamic Host Configuration Protocol version 6 (DHCPv6). It also provides advice to system administrators who employ manual configuration. This document does not change any existing recommendations concerning the use of temporary addresses as specified in RFC 4941. 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-12 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-6man-default-iids-12 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 Jul 8 12:30:07 2016 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C2FC512D57B for ; Fri, 8 Jul 2016 12:30:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.45 X-Spam-Level: X-Spam-Status: No, score=-2.45 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_ENVFROM_END_DIGIT=0.25, 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 915gI01ODOa4 for ; Fri, 8 Jul 2016 12:30:03 -0700 (PDT) Received: from mail-it0-x22f.google.com (mail-it0-x22f.google.com [IPv6:2607:f8b0:4001:c0b::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 B8BE912D567 for ; Fri, 8 Jul 2016 12:30:03 -0700 (PDT) Received: by mail-it0-x22f.google.com with SMTP id f6so11074294ith.1 for ; Fri, 08 Jul 2016 12:30:03 -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=YXe2qbaGjOMVYgQrmVlGP94G7I3vhhUICoULe7G8ESU=; b=BCLs+t25IdGrj0FLwODLApW06zWC+egg0PFrX1N+wREYyNFZE5S7pm1KpYPsDf3aOP o6cWLFhykacQcmsM7xyL2Ot6AItisCnpnqfY5ibwsAV05UIQhb/7RuX7tAsA0jI+SIi8 nzI/IxYLffQQW29r/1K/3ASj4z590gJC8sa7j7rdYH1sTKFqMAHUERh00qT/7lb9+hHB QUlrBEoHvGpfeYjtOEp70+GmsOVwjzSxFch6LQ+T2HE4nLDNU6PhNWOVlJnPk5ST6SAK g4aRUA3j9cZbiRljzWJ9VVGjdrdvFisEETXAvDukb73oaoBePpY4onuEVPCBvZwm3FGu zGFg== 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=YXe2qbaGjOMVYgQrmVlGP94G7I3vhhUICoULe7G8ESU=; b=KhInVoS8WrI/998stD0MEPR6sy1n8FLRH6/z44jurOTkibLTHkxXTMDkuaoBYLvmI3 YLkgR8A3prfvtCt75wd2nBMRrZpt/SnIKp1Ud/N80voSAdF19xN8C3q0KdxIWEEmbi4t 9bDIfANhR5QrPn3u18NSblURtTsLOO7hYkZI/AVyGswKQBDdczmYzxOJDZJF8PZwN2uG AnyRrkzDoVABTzSOmcfgy2ssPQfvLm8NXTpBmBrSpmEJuy7evTzELPbYjhPaI8TZZH37 lqrdqgIwkCvi7Kvp/HLAxBYYcQ5vUDp2BnltkNDDnaabTsvhW48RdrrjhRX0PYSsil35 r9Tg== X-Gm-Message-State: ALyK8tJ7LE9SK+ZeO3t9CrxV518uscMS75U3t6ww5hzec9yUyCvSG+hSDiYt8MznmiHbN5rN13XkLheXFh8hmA== X-Received: by 10.36.155.198 with SMTP id o189mr219318itd.54.1468006203023; Fri, 08 Jul 2016 12:30:03 -0700 (PDT) MIME-Version: 1.0 Received: by 10.64.187.37 with HTTP; Fri, 8 Jul 2016 12:29:43 -0700 (PDT) In-Reply-To: <79e33db6-48d1-2da1-60b5-10109d4d4e1d@gmail.com> References: <20160701153641.24636.69476.idtracker@ietfa.amsl.com> <8cb3aa9b-e157-794b-2dbf-f63e20cfdc62@innovationslab.net> <6c26fb03-7218-ff28-3488-887f6cd0f1fe@gmail.com> <2240c1fd-e8f2-478b-ea41-b01aec9f5954@gmail.com> <79e33db6-48d1-2da1-60b5-10109d4d4e1d@gmail.com> From: Jen Linkova Date: Fri, 8 Jul 2016 21:29:43 +0200 Message-ID: Subject: Re: Reference to "3333" value of RFC2464 "IPv6 over Ethernet" To: Alexandre Petrescu Content-Type: text/plain; charset=UTF-8 Archived-At: Cc: IPv6 X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 08 Jul 2016 19:30:06 -0000 On Fri, Jul 8, 2016 at 6:16 PM, Alexandre Petrescu wrote: > Still, it looks too much like an allocation. Maybe it should be at IANA, > not in RFC. And the doubt about IETF allocating MAC addresses still holds > in my mind. I'm afraid we begin to discuss nuances of what the word 'allocation' means. There is a global registry and if you want a globally unique MAC addresses - you can pay and get an OUI. Or you can assign the MAC address yourself (with Local bit set to 1) but that address has no guarantee of being unique. > For example, can some non-IP protocol use "33-33-" to transmit non-IP > datagrams to multicast MAC destinations? If no, is it because it belongs > somehow to IETF? I can not see why it can not. It might be the wisest decision as I'd expect some implementations bugs to strike back.. > An example non-IP message is WSMP or CAM/DENM which get transmitted over > 802.11p without IP headers. Currently they dont use "33-33-" as dst MAC > address, but use "ff-ff-". > > I guess that in your logic, if "33-33-" is used then it can only be IPv6 Not at all. What makes you think that '33-33' can be only used by IPv6? 33-33- has Local bit set, which means 'that MAC address was not assigned from the global pool of unique addresses but was assigned by a local administrator'. Someone else can pick up the same address. > and, reversely, if IPv6 is used then that could only be with "33-33-". I'd say 'SHOULD'. Because it is possible that multicast IPv6 packet may have unicast MAC address (see https://tools.ietf.org/html/rfc6085). However if we are talking about multicast MACs - so far the standard defines the only way (AFAIK) of choosing the destination MAC so I'd expect the implementations following the standards to use 33-33. > I could agree with this logic if this "33-33-" address where considered in > many other SDO documents, not just RFC. >> AFAIR RFC3307 has some recommendations on how to minimize the chance >> of address collision. > > > Ok... but they are all for IPv6 multicast addresses, not for MAC multicast > addresses. Yes, but the idea is 'how to choose your IPv6 mcast addresses to minimize the collision of the resulting MAC addresses'. > It's next to impossible to make sure "33-33-" will not collide with some > other organization using the same "33-33-" but without IP. Absolutely, '33-33-*' might not be globally unique. Someone (who has never heard about how IPv6 works...) might decide to use 33-33- for their new shiny protocol. However I'm not sure why it matters so much if 33-33 is used for IPv6 multicast only. Nothing prevents you from sending various protocols over Ethernet, so the host should be able to look at ethertype and find out what is inside. (there will be broken implementations indeed so that's why if I were developing a new protocol today I'd rather refrain away from using MAC addresses 33-33-*) -- SY, Jen Linkova aka Furry From nobody Fri Jul 8 12:36:06 2016 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8D5E312D882 for ; Fri, 8 Jul 2016 12:36:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.353 X-Spam-Level: X-Spam-Status: No, score=-5.353 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_ADSP_CUSTOM_MED=0.001, FREEMAIL_FROM=0.001, NML_ADSP_CUSTOM_MED=0.9, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_SOFTFAIL=0.665] 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 iVU-uDvVBb0i for ; Fri, 8 Jul 2016 12:36:02 -0700 (PDT) Received: from oxalide-out.extra.cea.fr (oxalide-out.extra.cea.fr [132.168.224.8]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 711DB12D862 for ; Fri, 8 Jul 2016 12:36:02 -0700 (PDT) Received: from pisaure.intra.cea.fr (pisaure.intra.cea.fr [132.166.88.21]) by oxalide.extra.cea.fr (8.15.2/8.15.2/CEAnet-Internet-out-2.4) with ESMTP id u68Ja0Cw013454 for ; Fri, 8 Jul 2016 21:36:00 +0200 Received: from pisaure.intra.cea.fr (localhost [127.0.0.1]) by localhost (Postfix) with SMTP id 9534020989A for ; Fri, 8 Jul 2016 21:36:00 +0200 (CEST) Received: from muguet2.intra.cea.fr (muguet2.intra.cea.fr [132.166.192.7]) by pisaure.intra.cea.fr (Postfix) with ESMTP id 8FA25209813 for ; Fri, 8 Jul 2016 21:36:00 +0200 (CEST) Received: from [132.166.84.71] ([132.166.84.71]) by muguet2.intra.cea.fr (8.15.2/8.15.2/CEAnet-Intranet-out-1.4) with ESMTP id u68Ja0nH008372 for ; Fri, 8 Jul 2016 21:36:00 +0200 Subject: Fwd: I-D Action: draft-ernst-its-ipv6-over-80211ocb-00.txt References: <20160708155547.32197.48846.idtracker@ietfa.amsl.com> To: IPv6 From: Alexandre Petrescu X-Forwarded-Message-Id: <20160708155547.32197.48846.idtracker@ietfa.amsl.com> Message-ID: <6d07c727-987a-f831-3d82-239503be885e@gmail.com> Date: Fri, 8 Jul 2016 21:35:59 +0200 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: <20160708155547.32197.48846.idtracker@ietfa.amsl.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.17 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 08 Jul 2016 19:36:04 -0000 Hi, I just submitted this Internet Draft. It is in the ITS BoF at IETF ietf.org/mailman/listinfo/its It tells about the use of multicast at link-layer for IPv6 over 802.11-OCB (Out of the Context of a BSSID, aka 802.11p). It is intended for discussion. Alex -------- Message transfr -------- Sujet : I-D Action: draft-ernst-its-ipv6-over-80211ocb-00.txt Date : Fri, 8 Jul 2016 08:55:47 -0700 De : internet-drafts@ietf.org Rpondre : internet-drafts@ietf.org Pour : i-d-announce@ietf.org A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : Transmission of IPv6 Packets over IEEE 802.11-OCB Networks Authors : Thierry Ernst Alexandre Petrescu Filename : draft-ernst-its-ipv6-over-80211ocb-00.txt Pages : 5 Date : 2016-07-08 Abstract: In this document the mapping of multicast IPv6 addresses to MAC addresses of 802.11-OCB is proposed. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ernst-its-ipv6-over-80211ocb/ There's also a htmlized version available at: https://tools.ietf.org/html/draft-ernst-its-ipv6-over-80211ocb-00 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ _______________________________________________ I-D-Announce mailing list I-D-Announce@ietf.org https://www.ietf.org/mailman/listinfo/i-d-announce Internet-Draft directories: http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt From nobody Fri Jul 8 12:53:27 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 165E112D87A; Fri, 8 Jul 2016 12:53:19 -0700 (PDT) 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-13.txt X-Test-IDTracker: no X-IETF-IDTracker: 6.25.1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20160708195319.32176.57373.idtracker@ietfa.amsl.com> Date: Fri, 08 Jul 2016 12:53:19 -0700 Archived-At: Cc: ipv6@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.17 List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 08 Jul 2016 19:53:19 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the IPv6 Maintenance 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-13.txt Pages : 23 Date : 2016-07-08 Abstract: This document changes the recommended default IID generation scheme for cases where SLAAC is used to generate a stable IPv6 address. It recommends using the mechanism specified in RFC7217 in such cases, and recommends against embedding stable 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, by removing the text in these RFCs that required the IPv6 Interface Identifiers to be derived from the underlying stable link-layer address, and replacing this text with recommendations consistent with those in this document. Additionally, this document updates RFC3315 by specifying additional requirements on the generation of Interface Identifiers used in Dynamic Host Configuration Protocol version 6 (DHCPv6). It also provides advice to system administrators who employ manual configuration. This document does not change any existing recommendations concerning the use of temporary addresses as specified in RFC 4941. 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-13 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-6man-default-iids-13 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 Jul 8 13:11:56 2016 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5335D12B04F for ; Fri, 8 Jul 2016 13:11:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.721 X-Spam-Level: X-Spam-Status: No, score=-2.721 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, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cooperw.in header.b=jz1+hd87; dkim=pass (1024-bit key) header.d=messagingengine.com header.b=qv+Nnowa 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 QL35EuQr17PE for ; Fri, 8 Jul 2016 13:11:53 -0700 (PDT) Received: from out1-smtp.messagingengine.com (out1-smtp.messagingengine.com [66.111.4.25]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 08C2612B065 for ; Fri, 8 Jul 2016 13:11:53 -0700 (PDT) Received: from compute3.internal (compute3.nyi.internal [10.202.2.43]) by mailout.nyi.internal (Postfix) with ESMTP id 77AF9204AC for ; Fri, 8 Jul 2016 16:11:52 -0400 (EDT) Received: from frontend1 ([10.202.2.160]) by compute3.internal (MEProxy); Fri, 08 Jul 2016 16:11:52 -0400 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=cooperw.in; h= content-transfer-encoding:content-type:date:from:in-reply-to :message-id:mime-version:references:subject:to:x-sasl-enc :x-sasl-enc; s=mesmtp; bh=ftwsmh42+ca4LsHhPQSmhK9q+6A=; b=jz1+hd 87WoK0balWwPGzEyT3z90U8UiLH6ml8a4Otjc9cK/aobUr60xDQ8436dODZyTVKV w5CxDhETEpXS5LpWXmc41GjtplbQeWmM3zzMRtvVeGe9KF3jAEeWs+ePaCIsR4Ey pZeNXaU4blSLkLmTdSB10qbHWhxwbn/iZpoBM= DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d= messagingengine.com; h=content-transfer-encoding:content-type :date:from:in-reply-to:message-id:mime-version:references :subject:to:x-sasl-enc:x-sasl-enc; s=smtpout; bh=ftwsmh42+ca4LsH hPQSmhK9q+6A=; b=qv+Nnowam3k7s4Hup0kxkDVYQUcESCAEpEMrpfX4tDJVazX c2KdOa3vx2Jlv74OlQKz2KCszC+rPyFTpuuiLmPIcI75IRJhwm6ftH96WAzKDJ0d AisP0r3ZP4/lFM54+Op17XMb1gr1x6sGfeyyg9gFse4Y6XqKbQOM5sHt5e80= X-Sasl-enc: bl2//8HsYQBpyjB09Lr2VPP3wB0LndkzNOt0McK6oCAi 1468008712 Received: from dhcp-171-68-20-46.cisco.com (dhcp-171-68-20-46.cisco.com [171.68.20.46]) by mail.messagingengine.com (Postfix) with ESMTPA id 1A854F29F4 for ; Fri, 8 Jul 2016 16:11:52 -0400 (EDT) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) Subject: Re: I-D Action: draft-ietf-6man-default-iids-13.txt From: Alissa Cooper In-Reply-To: <20160708195319.32176.57373.idtracker@ietfa.amsl.com> Date: Fri, 8 Jul 2016 13:11:51 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <1B214DEC-E146-446E-B9B9-E46C54598B13@cooperw.in> References: <20160708195319.32176.57373.idtracker@ietfa.amsl.com> To: IETF IPv6 Mailing List X-Mailer: Apple Mail (2.3124) Archived-At: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 08 Jul 2016 20:11:55 -0000 Note that the -12 version of this document contains the bulk of the = updates. It had a typo in the abstract, which is fixed in the -13. Based on list discussion, we made a bunch of changes: * Adopted Jinmei=E2=80=99s text in Section 1. * Otherwise made changes to clarify that the scope of this document=E2=80=99= s recommendations is cases where an IID would have otherwise been = generated using SLAAC by embedding a _stable_ link-layer address. * Boiled the recommendations in Section 3 down to their essence. The = compounding of MUSTs and SHOULDs in -11 seemed like a problem that was = causing confusion. The basic recommendations now are that nodes SHOULD = employ 7217 as the default scheme when they need to generate a stable = IPv6 address with SLAAC and that nodes SHOULD NOT employ IPv6 address = generation schemes that embed a stable link-layer address in the IID. * Changed the updates to IPv6-over-foo documents in Section 6 to = directly reflect the two requirements above. Again, this seemed cleaner = that compounding a =E2=80=9CMUST follow RFCXXXX=E2=80=9D requirement = with the SHOULD/SHOULD NOT requirements in Section 3. Hopefully this resolves the issues raised during WGLC. Alissa > On Jul 8, 2016, at 12:53 PM, internet-drafts@ietf.org wrote: >=20 >=20 > A New Internet-Draft is available from the on-line Internet-Drafts = directories. > This draft is a work item of the IPv6 Maintenance of the IETF. >=20 > Title : Recommendation on Stable IPv6 Interface = Identifiers > Authors : Fernando Gont > Alissa Cooper > Dave Thaler > Will Liu > Filename : draft-ietf-6man-default-iids-13.txt > Pages : 23 > Date : 2016-07-08 >=20 > Abstract: > This document changes the recommended default IID generation scheme > for cases where SLAAC is used to generate a stable IPv6 address. It > recommends using the mechanism specified in RFC7217 in such cases, > and recommends against embedding stable 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, by removing the = text > in these RFCs that required the IPv6 Interface Identifiers to be > derived from the underlying stable link-layer address, and replacing > this text with recommendations consistent with those in this > document. Additionally, this document updates RFC3315 by specifying > additional requirements on the generation of Interface Identifiers > used in Dynamic Host Configuration Protocol version 6 (DHCPv6). It > also provides advice to system administrators who employ manual > configuration. This document does not change any existing > recommendations concerning the use of temporary addresses as > specified in RFC 4941. >=20 >=20 > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-ietf-6man-default-iids/ >=20 > There's also a htmlized version available at: > https://tools.ietf.org/html/draft-ietf-6man-default-iids-13 >=20 > A diff from the previous version is available at: > https://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-6man-default-iids-13 >=20 >=20 > Please note that it may take a couple of minutes from the time of = submission > until the htmlized version and diff are available at tools.ietf.org. >=20 > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ >=20 > _______________________________________________ > I-D-Announce mailing list > I-D-Announce@ietf.org > https://www.ietf.org/mailman/listinfo/i-d-announce > Internet-Draft directories: http://www.ietf.org/shadow.html > or ftp://ftp.ietf.org/ietf/1shadow-sites.txt From nobody Fri Jul 8 15:10: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 B2DB512D51D; Fri, 8 Jul 2016 15:10:47 -0700 (PDT) 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-maxra-01.txt X-Test-IDTracker: no X-IETF-IDTracker: 6.25.1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20160708221047.32201.45893.idtracker@ietfa.amsl.com> Date: Fri, 08 Jul 2016 15:10:47 -0700 Archived-At: Cc: ipv6@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.17 List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 08 Jul 2016 22:10: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 of the IETF. Title : Support for adjustable maximum router lifetimes per-link Authors : Suresh Krishnan Jouni Korhonen Samita Chakrabarti Erik Nordmark Andrew Yourtchenko Filename : draft-ietf-6man-maxra-01.txt Pages : 6 Date : 2016-07-08 Abstract: The neighbor discovery protocol specifies the maximum time allowed between sending unsolicited multicast Router Advertisements from a router interface as well as the maximum router lifetime. It also allows the limits to be overridden by link-layer specific documents. This document allows for overriding these values on a per-link basis. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-6man-maxra/ There's also a htmlized version available at: https://tools.ietf.org/html/draft-ietf-6man-maxra-01 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-6man-maxra-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 Sat Jul 9 00:42:31 2016 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 48ABB12B009 for ; Sat, 9 Jul 2016 00:42:30 -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 tcw1XZ16G6FQ for ; Sat, 9 Jul 2016 00:42:28 -0700 (PDT) Received: from mail-wm0-x22f.google.com (mail-wm0-x22f.google.com [IPv6:2a00:1450:400c:c09::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 84D9012B02B for ; Sat, 9 Jul 2016 00:42:27 -0700 (PDT) Received: by mail-wm0-x22f.google.com with SMTP id f65so8988130wmi.0 for ; Sat, 09 Jul 2016 00:42:27 -0700 (PDT) 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-transfer-encoding; bh=QKlNY52Lae64pec6m1YYRXxOp11VirKKYYnZHHz2OXs=; b=P4loq6YwV7xakpbDFAVkgNXGu9XEULDKReg8it5VVeKkJjrmSVahTJBNXeXorMh7LZ g6peshwDGmim6sbiYcV6/2fEJySblKilXqgJLotNJZMrz55z5o43psOBWQQEd/EyNPBH 8sLRnmdn/fBge1fSTyrrEuXCiz9vKOC6ydo9rm3P6bPOnwizDxxI6egCcehSRjYlBZ+G j6e52X34lvr+H4g4lOCrZQr39gXPHz3gsUOU69P76ysJ7mZFU7erh6IpnPvV21pyn7/9 lcK4Jy7fVcqPus8ho94xXT2eyPlN+Xb//Gu0w3Gj0cr+qYHShhtYipvJAOlsIs9Zk9zy TjMw== 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-transfer-encoding; bh=QKlNY52Lae64pec6m1YYRXxOp11VirKKYYnZHHz2OXs=; b=fFUmdAQUBjIsgyxkO2BTgzYQOxt67XGbSoZjQuqiKl1AN1ctPrJZFloiu7yTKno3c5 p+vChyUN6pW2fU7EFNl/ZRyrqY4K+j8lI+5VKygngGrKoO08/L2nmwAJiyg2Ec7+daWu kxiqolVyJrLKcjxkhFei8jgz4DyPoX9ahGjUzFKA9Zyg4SJmkFdEPO8uPdaR4QGaygtq JCTHVqBJvd1WCEbwLbJmcpi82MVCQJrY0+Y8DpRKaqnjFbCBqmUxVM4ST+zlLgOkrfyP FaaTHQ2pUFTPH9FozcBFrr6fEa1ZnUsgUCaH+gyGR4D9a1G+Pd0aQP6AxMP1gxwALqbe FEyA== X-Gm-Message-State: ALyK8tLeMGL540GZAWd+Iu9FByXavfznHHEVDER/le6EPO9t/CO8iQ9Tp24hI2oc/6dtLA== X-Received: by 10.28.63.216 with SMTP id m207mr2160252wma.73.1468050145731; Sat, 09 Jul 2016 00:42:25 -0700 (PDT) Received: from [10.0.1.29] (cpc66883-mort6-2-0-cust696.19-2.cable.virginm.net. [92.233.126.185]) by smtp.gmail.com with ESMTPSA id b84sm6692063wmb.6.2016.07.09.00.42.24 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sat, 09 Jul 2016 00:42:25 -0700 (PDT) Subject: Re: I-D Action: draft-ietf-6man-default-iids-13.txt To: Alissa Cooper , IETF IPv6 Mailing List References: <20160708195319.32176.57373.idtracker@ietfa.amsl.com> <1B214DEC-E146-446E-B9B9-E46C54598B13@cooperw.in> From: Brian E Carpenter Organization: University of Auckland Message-ID: Date: Sat, 9 Jul 2016 19:42:38 +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: <1B214DEC-E146-446E-B9B9-E46C54598B13@cooperw.in> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Archived-At: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 09 Jul 2016 07:42:30 -0000 NB the useful diff is at https://tools.ietf.org/rfcdiff?url1=3Ddraft-ietf-6man-default-iids-11.txt= ?url2=3Ddraft-ietf-6man-default-iids-13.txt Regards Brian On 09/07/2016 08:11, Alissa Cooper wrote: > Note that the -12 version of this document contains the bulk of the upd= ates. It had a typo in the abstract, which is fixed in the -13. >=20 > Based on list discussion, we made a bunch of changes: >=20 > * Adopted Jinmei=E2=80=99s text in Section 1. >=20 > * Otherwise made changes to clarify that the scope of this document=E2=80= =99s recommendations is cases where an IID would have otherwise been gene= rated using SLAAC by embedding a _stable_ link-layer address. >=20 > * Boiled the recommendations in Section 3 down to their essence. The co= mpounding of MUSTs and SHOULDs in -11 seemed like a problem that was caus= ing confusion. The basic recommendations now are that nodes SHOULD employ= 7217 as the default scheme when they need to generate a stable IPv6 addr= ess with SLAAC and that nodes SHOULD NOT employ IPv6 address generation s= chemes that embed a stable link-layer address in the IID. >=20 > * Changed the updates to IPv6-over-foo documents in Section 6 to direct= ly reflect the two requirements above. Again, this seemed cleaner that co= mpounding a =E2=80=9CMUST follow RFCXXXX=E2=80=9D requirement with the SH= OULD/SHOULD NOT requirements in Section 3. >=20 > Hopefully this resolves the issues raised during WGLC. >=20 > Alissa >=20 >=20 >=20 >> On Jul 8, 2016, at 12:53 PM, internet-drafts@ietf.org wrote: >> >> >> A New Internet-Draft is available from the on-line Internet-Drafts dir= ectories. >> This draft is a work item of the IPv6 Maintenance of the IETF. >> >> Title : Recommendation on Stable IPv6 Interface Ident= ifiers >> Authors : Fernando Gont >> Alissa Cooper >> Dave Thaler >> Will Liu >> Filename : draft-ietf-6man-default-iids-13.txt >> Pages : 23 >> Date : 2016-07-08 >> >> Abstract: >> This document changes the recommended default IID generation scheme >> for cases where SLAAC is used to generate a stable IPv6 address. It= >> recommends using the mechanism specified in RFC7217 in such cases, >> and recommends against embedding stable 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, by removing the tex= t >> in these RFCs that required the IPv6 Interface Identifiers to be >> derived from the underlying stable link-layer address, and replacing= >> this text with recommendations consistent with those in this >> document. Additionally, this document updates RFC3315 by specifying= >> additional requirements on the generation of Interface Identifiers >> used in Dynamic Host Configuration Protocol version 6 (DHCPv6). It >> also provides advice to system administrators who employ manual >> configuration. This document does not change any existing >> recommendations concerning the use of temporary addresses as >> specified in RFC 4941. >> >> >> 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-13 >> >> A diff from the previous version is available at: >> https://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-6man-default-iids-13 >> >> >> Please note that it may take a couple of minutes from the time of subm= ission >> until the htmlized version and diff are available at tools.ietf.org. >> >> Internet-Drafts are also available by anonymous FTP at: >> ftp://ftp.ietf.org/internet-drafts/ >> >> _______________________________________________ >> I-D-Announce mailing list >> I-D-Announce@ietf.org >> https://www.ietf.org/mailman/listinfo/i-d-announce >> Internet-Draft directories: http://www.ietf.org/shadow.html >> or ftp://ftp.ietf.org/ietf/1shadow-sites.txt >=20 > -------------------------------------------------------------------- > IETF IPv6 working group mailing list > ipv6@ietf.org > Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 > -------------------------------------------------------------------- >=20 From nobody Sun Jul 10 07:30:28 2016 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3874D12B006 for ; Sun, 10 Jul 2016 07:30:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.189 X-Spam-Level: X-Spam-Status: No, score=-3.189 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-1.287, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] 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 SiSYQ1RTk3ND for ; Sun, 10 Jul 2016 07:30:25 -0700 (PDT) Received: from givry.fdupont.fr (givry.fdupont.fr [IPv6:2001:41d0:1:6d55:211:5bff:fe98:d51e]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DF401127071 for ; Sun, 10 Jul 2016 07:30:24 -0700 (PDT) Received: from givry.fdupont.fr (localhost [IPv6:::1]) by givry.fdupont.fr (8.14.7/8.14.7) with ESMTP id u6AETPDl030250; Sun, 10 Jul 2016 16:29:25 +0200 (CEST) (envelope-from dupont@givry.fdupont.fr) Message-Id: <201607101429.u6AETPDl030250@givry.fdupont.fr> From: Francis Dupont To: Alexandre Petrescu Subject: Re: Reference to "3333" value of RFC2464 "IPv6 over Ethernet" In-reply-to: Your message of Fri, 08 Jul 2016 15:56:39 +0200. <6c26fb03-7218-ff28-3488-887f6cd0f1fe@gmail.com> Date: Sun, 10 Jul 2016 16:29:25 +0200 Archived-At: Cc: IPv6 X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 10 Jul 2016 14:30:27 -0000 In your previous mail you wrote: > RFC2464 "IPv6 over Ethernet" says: > > 7. Address Mapping -- Multicast > > > > An IPv6 packet with a multicast destination address DST, consisting > > of the sixteen octets DST[1] through DST[16], is transmitted to the > > Ethernet multicast address whose first two octets are the value 3333 > > hexadecimal and whose last four octets are the last four octets of > > DST. > > Where is this "3333" value defined? Obviously an RFC is not the place > to define an Ethernet multicast address. => in the RFC you cited. Two remarks: - 3 means local (so it can be defined where you want) and multicast. - this was introduced before the 33rd IETF (I remembered I had to update one of two IPv6 implementations for this 3333 in the IPv6 over Ethernet show during this IETF, nearly 21 years ago). Regards Francis.Dupont@fdupont.fr From nobody Mon Jul 11 05:35:08 2016 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E742012D0BE for ; Mon, 11 Jul 2016 05:35:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.353 X-Spam-Level: X-Spam-Status: No, score=-5.353 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_ADSP_CUSTOM_MED=0.001, FREEMAIL_FROM=0.001, NML_ADSP_CUSTOM_MED=0.9, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_SOFTFAIL=0.665] 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 TrzXVAHNUz5Z for ; Mon, 11 Jul 2016 05:35:05 -0700 (PDT) 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 3153A12B01F for ; Mon, 11 Jul 2016 05:35:04 -0700 (PDT) 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 u6BCZ12A006519; Mon, 11 Jul 2016 14:35:01 +0200 Received: from pisaure.intra.cea.fr (localhost [127.0.0.1]) by localhost (Postfix) with SMTP id AED5520A1B0; Mon, 11 Jul 2016 14:35:01 +0200 (CEST) Received: from muguet1.intra.cea.fr (muguet1.intra.cea.fr [132.166.192.6]) by pisaure.intra.cea.fr (Postfix) with ESMTP id 9835D20A188; Mon, 11 Jul 2016 14:35:01 +0200 (CEST) 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 u6BCZ1Ru016800; Mon, 11 Jul 2016 14:35:01 +0200 Subject: Re: Reference to "3333" value of RFC2464 "IPv6 over Ethernet" To: Francis Dupont References: <201607101429.u6AETPDl030250@givry.fdupont.fr> From: Alexandre Petrescu Message-ID: <33b73dae-99e2-ef99-854b-97647334507b@gmail.com> Date: Mon, 11 Jul 2016 14:35:00 +0200 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.2.0 MIME-Version: 1.0 In-Reply-To: <201607101429.u6AETPDl030250@givry.fdupont.fr> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit Archived-At: Cc: IPv6 X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.17 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 Jul 2016 12:35:07 -0000 Hi Francis, Thanks for the reply. Le 10/07/2016 16:29, Francis Dupont a crit : > In your previous mail you wrote: > >> RFC2464 "IPv6 over Ethernet" says: >> > 7. Address Mapping -- Multicast >> > >> > An IPv6 packet with a multicast destination address DST, consisting >> > of the sixteen octets DST[1] through DST[16], is transmitted to the >> > Ethernet multicast address whose first two octets are the value 3333 >> > hexadecimal and whose last four octets are the last four octets of >> > DST. >> >> Where is this "3333" value defined? Obviously an RFC is not the place >> to define an Ethernet multicast address. > > => in the RFC you cited. Two remarks: > - 3 means local (so it can be defined where you want) and multicast. Ok - 3 00000011 means 'local' and 'multicast'. Could have also been 7 or 15. > - this was introduced before the 33rd IETF (I remembered I had to > update one of two IPv6 implementations for this 3333 in the IPv6 > over Ethernet show during this IETF, nearly 21 years ago). Ah, that's why 3333! I wonder whether at that time existed the allocation of 01-00-5E- MAC global multicast addresses managed by IANA. http://www.iana.org/assignments/ethernet-numbers/ethernet-numbers.xhtml#ethernet-numbers-1 Alex > > Regards > > Francis.Dupont@fdupont.fr > From nobody Mon Jul 11 09:22:07 2016 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 707CF12D5B1 for ; Mon, 11 Jul 2016 09:22:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.188 X-Spam-Level: X-Spam-Status: No, score=-3.188 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, LOTS_OF_MONEY=0.001, RP_MATCHES_RCVD=-1.287, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] 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 sCNY1K5R2Iwh for ; Mon, 11 Jul 2016 09:22:03 -0700 (PDT) Received: from givry.fdupont.fr (givry.fdupont.fr [IPv6:2001:41d0:1:6d55:211:5bff:fe98:d51e]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id ABC5812D599 for ; Mon, 11 Jul 2016 09:22:02 -0700 (PDT) Received: from givry.fdupont.fr (localhost [IPv6:::1]) by givry.fdupont.fr (8.14.7/8.14.7) with ESMTP id u6BGL0FL027624; Mon, 11 Jul 2016 18:21:00 +0200 (CEST) (envelope-from dupont@givry.fdupont.fr) Message-Id: <201607111621.u6BGL0FL027624@givry.fdupont.fr> From: Francis Dupont To: Alexandre Petrescu Subject: Re: Reference to "3333" value of RFC2464 "IPv6 over Ethernet" In-reply-to: Your message of Mon, 11 Jul 2016 14:35:00 +0200. <33b73dae-99e2-ef99-854b-97647334507b@gmail.com> Date: Mon, 11 Jul 2016 18:21:00 +0200 Archived-At: Cc: IPv6 X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.17 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 Jul 2016 16:22:04 -0000 In your previous mail you wrote: > I wonder whether at that time existed the allocation of 01-00-5E- > MAC global multicast addresses managed by IANA. => 01:00:5e was far before IPv6 and as far as I can remember this was used before 33:33 was specified (the 00 I-D was published the July 16, 1995) so just before the IETF meeting... Note that according to my archives the idea to use 33:33 was from June 95: (to identify the message I selected these lines from the header) To: ipng@sunroof.Eng.Sun.COM Subject: (IPng 192) IPv6 ethertype, multicast address mapping, etc. Date: Fri, 16 Jun 1995 18:32:30 PDT From: Steve Deering Message-Id: <95Jun16.183244pdt.75270@digit.parc.xerox.com> ... On another Ethernet-related topic, we have never specified how IPv6 multicast addresses are to be mapped to Ethernet multicast addresses. I believe that some of the prototype IPv6 implementations are curently using the same mapping as IPv4, that is, replacing the low-order 23 bits of the ethernet address 01-00-5E-00-00-00 with the low-order 23 bits of the IP multicast address. It would be nice to use a slightly more efficient mapping for IPv6 (extracting 23 bits is sorta fiddly). I propose the following: replace the low-order 32 bits of the ethernet address 33-33-00-00-00-00 with the low-order 32 bits of the IPv6 multicast address. The 33-33- prefix has both the Group (Multicast) bit set and the Locally Administered bit set. (They are the lowest-order and second lowest-order bits, respectively, of the first octet, in the canonical address representation.) It would be more politically correct to use a Universally Administered prefix, but those are handed out by the IEEE at $1000 per 24-bit chunk, which would mean we'd have to pay a quarter of a million dollars to get 32 bits of ethernet multicast address space, even though almost all the the 46 bits of total ethernet multicast address space is unused and will never be used. If we instead use the locally- administered space, we don't have to pay anyone, but we run the hazard of colliding with some other local usage of that 33-33- prefix. I suspect that such collisions are highly improbable (I did check the database of known ethernet address usage maintained at MIT, and there was no known conflict recorded there), but if anyone knows of any existing use of that prefix, please speak up -- I'd like to settle this question before the end of the month. By the way, this mapping would apply to Ethernet and FDDI, but *not* to Token Ring, where most host adapters have insufficient multicast address filtering to deal with proper multicast addresses. Instead, on Token Rings, IPv6 multicast addresses would all be mapped to the single "functional" address already allocated to IP, that is 03-00-00-20-00-00 in canonical form (see RFC 1469, IP Multicast over Token-Ring LANs). Regards Francis.Dupont@fdupont.fr From nobody Mon Jul 11 12:59:00 2016 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8669012D592 for ; Mon, 11 Jul 2016 12:58:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.22 X-Spam-Level: X-Spam-Status: No, score=-4.22 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, LOTS_OF_MONEY=0.001, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] 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 fM3CHZoyb8jg for ; Mon, 11 Jul 2016 12:58:57 -0700 (PDT) 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 AD43412D0CB for ; Mon, 11 Jul 2016 12:58:57 -0700 (PDT) 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 u6BJwuZb010491; Mon, 11 Jul 2016 12:58:57 -0700 Received: from XCH15-06-11.nw.nos.boeing.com (xch15-06-11.nw.nos.boeing.com [137.136.239.220]) by phx-mbsout-01.mbs.boeing.net (8.14.4/8.14.4/UPSTREAM_MBSOUT) with ESMTP id u6BJwpfM010339 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=OK); Mon, 11 Jul 2016 12:58:52 -0700 Received: from XCH15-06-11.nw.nos.boeing.com (2002:8988:efdc::8988:efdc) by XCH15-06-11.nw.nos.boeing.com (2002:8988:efdc::8988:efdc) with Microsoft SMTP Server (TLS) id 15.0.1178.4; Mon, 11 Jul 2016 12:58:51 -0700 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.1178.000; Mon, 11 Jul 2016 12:58:51 -0700 From: "Manfredi, Albert E" To: Francis Dupont Subject: RE: Reference to "3333" value of RFC2464 "IPv6 over Ethernet" Thread-Topic: Reference to "3333" value of RFC2464 "IPv6 over Ethernet" Thread-Index: AQHR25A2RqIIsZ6d+kWxSgpDBrH7LqATpPww Date: Mon, 11 Jul 2016 19:58:50 +0000 Message-ID: <996d004c00c84661b641033c91e0f5da@XCH15-06-11.nw.nos.boeing.com> References: Your message of Mon, 11 Jul 2016 14:35:00 +0200. <33b73dae-99e2-ef99-854b-97647334507b@gmail.com> <201607111621.u6BGL0FL027624@givry.fdupont.fr> In-Reply-To: <201607111621.u6BGL0FL027624@givry.fdupont.fr> 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 X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.17 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 Jul 2016 19:58:59 -0000 All of which seems on the surface to be a "belts and suspenders" approach t= o IPv6 over Ethernet. After all, IPv6 payload can be differentiated from IP= v4 payload, so there should be no reason for this multicast or for the IPv6= "type" in unicast, to be different from IPv4? Unless the problem is that IPv4 implementations don't bother checking for I= P version? Would have been nice to avoid this extra complication, I think. Bert -----Original Message----- From: ipv6 [mailto:ipv6-bounces@ietf.org] On Behalf Of Francis Dupont Sent: Monday, July 11, 2016 12:21 To: Alexandre Petrescu Cc: IPv6 Subject: Re: Reference to "3333" value of RFC2464 "IPv6 over Ethernet" In your previous mail you wrote: > I wonder whether at that time existed the allocation of 01-00-5E- > MAC global multicast addresses managed by IANA. =3D> 01:00:5e was far before IPv6 and as far as I can remember this was used before 33:33 was specified (the 00 I-D was published the July 16, 1995) so just before the IETF meeting... Note that according to my archives the idea to use 33:33 was from June 95: (to identify the message I selected these lines from the header) To: ipng@sunroof.Eng.Sun.COM Subject: (IPng 192) IPv6 ethertype, multicast address mapping, etc. Date: Fri, 16 Jun 1995 18:32:30 PDT From: Steve Deering Message-Id: <95Jun16.183244pdt.75270@digit.parc.xerox.com>=20 ... On another Ethernet-related topic, we have never specified how IPv6 multica= st addresses are to be mapped to Ethernet multicast addresses. I believe that some of the prototype IPv6 implementations are curently using the same mapping as IPv4, that is, replacing the low-order 23 bits of the ethernet address 01-00-5E-00-00-00 with the low-order 23 bits of the IP multicast address. It would be nice to use a slightly more efficient mapping for IPv6 (extracting 23 bits is sorta fiddly). I propose the following: replace the low-order 32 bits of the ethernet address 33-33-00-00-00-00 with the low-order 32 bits of the IPv6 multicast address. The 33-33- prefix has both the Group (Multicast) bit set and the Locally Administered bit set. (They are the lowest-order and second lowest-order bits, respectively, of the first octet, in the canonical address representation.) It would be more politically correct to use a Universally Administered prefix, but those are handed out by the IEEE at $1000 per 24-bit chunk, which would mean we'd have to pay a quarter of a million dollars to get 32 bits of ethernet multicast address space, even though almost all the the 46 bits of total ethernet multicast address space is unused and will never be used. If we instead use the locally- administered space, we don't have to pay anyone, but we run the hazard of colliding with some other local usage of that 33-33- prefix. I suspect that such collisions are highly improbable (I did check the database of known ethernet address usage maintained at MIT, and there was no known conflict recorded there), but if anyone knows of any existing use of that prefix, please speak up -- I'd like to settle this question before the end of the month. By the way, this mapping would apply to Ethernet and FDDI, but *not* to Token Ring, where most host adapters have insufficient multicast address filtering to deal with proper multicast addresses. Instead, on Token Rings, IPv6 multicast addresses would all be mapped to the single "functional" address already allocated to IP, that is 03-00-00-20-00-00 in canonical form (see RFC 1469, IP Multicast over Token-Ring LANs). Regards Francis.Dupont@fdupont.fr -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From nobody Wed Jul 13 05:53:43 2016 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 156E212DF64 for ; Wed, 13 Jul 2016 05:53:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.352 X-Spam-Level: X-Spam-Status: No, score=-5.352 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_ADSP_CUSTOM_MED=0.001, FREEMAIL_FROM=0.001, LOTS_OF_MONEY=0.001, NML_ADSP_CUSTOM_MED=0.9, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_SOFTFAIL=0.665] autolearn=unavailable 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 nHlmebHb2x6e for ; Wed, 13 Jul 2016 05:53:40 -0700 (PDT) Received: from oxalide-out.extra.cea.fr (oxalide-out.extra.cea.fr [132.168.224.8]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 40EDA12D784 for ; Wed, 13 Jul 2016 05:50:34 -0700 (PDT) Received: from pisaure.intra.cea.fr (pisaure.intra.cea.fr [132.166.88.21]) by oxalide.extra.cea.fr (8.15.2/8.15.2/CEAnet-Internet-out-2.4) with ESMTP id u6DCoVhb003875; Wed, 13 Jul 2016 14:50:31 +0200 Received: from pisaure.intra.cea.fr (localhost [127.0.0.1]) by localhost (Postfix) with SMTP id 4A91920800F; Wed, 13 Jul 2016 14:50:31 +0200 (CEST) Received: from muguet1.intra.cea.fr (muguet1.intra.cea.fr [132.166.192.6]) by pisaure.intra.cea.fr (Postfix) with ESMTP id 3CB9C207F49; Wed, 13 Jul 2016 14:50:31 +0200 (CEST) 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 u6DCoVrO031527; Wed, 13 Jul 2016 14:50:31 +0200 Subject: Re: Reference to "3333" value of RFC2464 "IPv6 over Ethernet" To: Francis Dupont References: <201607111621.u6BGL0FL027624@givry.fdupont.fr> From: Alexandre Petrescu Message-ID: Date: Wed, 13 Jul 2016 14:50:31 +0200 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.2.0 MIME-Version: 1.0 In-Reply-To: <201607111621.u6BGL0FL027624@givry.fdupont.fr> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit Archived-At: Cc: IPv6 X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.17 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 Jul 2016 12:53:41 -0000 Le 11/07/2016 18:21, Francis Dupont a crit : > In your previous mail you wrote: > >> I wonder whether at that time existed the allocation of 01-00-5E- >> MAC global multicast addresses managed by IANA. > > => 01:00:5e was far before IPv6 and as far as I can remember this > was used before 33:33 was specified (the 00 I-D was published the > July 16, 1995) so just before the IETF meeting... Note that according > to my archives the idea to use 33:33 was from June 95: This confirms more and more that 3333 stands for IETF 33, which looks cool. But a less cool 0x3 could have accommodated more Group IDs from IPv6 multicast addresses. Whereas 0x3333 can prefix 32bits of Group ID, 0x3 could prefix 40bits of Group ID. (in RFC4291 "IPv6 addr arch" the Group ID is 112 bits long). Allow me now to comment on this message: > (to identify the message I selected these lines from the header) > > To: ipng@sunroof.Eng.Sun.COM Subject: (IPng 192) IPv6 ethertype, > multicast address mapping, etc. Date: Fri, 16 Jun 1995 18:32:30 PDT > From: Steve Deering Message-Id: > <95Jun16.183244pdt.75270@digit.parc.xerox.com> ... > > On another Ethernet-related topic, we have never specified how IPv6 > multicast addresses are to be mapped to Ethernet multicast addresses. > I believe that some of the prototype IPv6 implementations are > curently using the same mapping as IPv4, that is, replacing the > low-order 23 bits of the ethernet address 01-00-5E-00-00-00 with the > low-order 23 bits of the IP multicast address. It would be nice to > use a slightly more efficient mapping for IPv6 (extracting 23 bits > is sorta fiddly). I propose the following: > > replace the low-order 32 bits of the ethernet address > 33-33-00-00-00-00 with the low-order 32 bits of the IPv6 multicast > address. > > The 33-33- prefix has both the Group (Multicast) bit set and the > Locally Administered bit set. (They are the lowest-order and second > lowest-order bits, respectively, of the first octet, in the canonical > address representation.) For information, there is talk recently about privacy uses of the L bit in the MAC address field of a MAC header carrying IPv6 packets. This would make it for two distinct Local prefixes both for IETF. > It would be more politically correct to use a Universally > Administered prefix, but those are handed out by the IEEE at $1000 > per 24-bit chunk, which would mean we'd have to pay a quarter of a > million dollars to get 32 bits of ethernet multicast address space, I dont understand why this reasoning was not pushed further. Using 0x3 instead of 0x3333 would have saved even more money. > even though almost all the the 46 bits of total ethernet multicast > address space is unused and will never be used. I dont understand this claim of never expected be used. The length of the Group ID in an IPv6 multicast address is 112bits. The number of reserved Group IDs grows more and more (all-nodes, all-routers, all-ntp-servers...). One day there will be no place left in the MAC addresses to map each of these Group IDs. > If we instead use the locally- administered space, we don't have to > pay anyone, Yes. > but we run the hazard of colliding with some other local usage of > that 33-33- prefix. I suspect that such collisions are highly > improbable (I did check the database of known ethernet address usage > maintained at MIT, and there was no known conflict recorded there), > but if anyone knows of any existing use of that prefix, please speak > up -- I'd like to settle this question before the end of the month. Well we are now many years later, but I think the collision risk may have grown: - there are more non-IP protocols sitting on EthernetII headers than were at the time. - some other non-multicast but IP protocols considering the use of the L bit appear. - the 33-33 number is not mentioned anywhere by IEEE nowhere. > By the way, this mapping would apply to Ethernet and FDDI, but *not* > to Token Ring, where most host adapters have insufficient multicast > address filtering to deal with proper multicast addresses. Instead, > on Token Rings, IPv6 multicast addresses would all be mapped to the > single "functional" address already allocated to IP, that is > 03-00-00-20-00-00 in canonical form (see RFC 1469, IP Multicast over > Token-Ring LANs). This RFC is now Historic because IPv4. The IPv6-over-token-ring RFC2470 does use 03-00- instead of 33-33-. The IPv6-over-802154 RFC4944 uses a 16bit multicast MAC address which is binary 100XXXXX-XXXXXXXX. Other non-Ethernet IEEE links not using 33-33- are "IEEE 1394 highperf serial" RFC3146 - MCA type 2, and "IEEE 802.16" - bridged, so supposedly 48 1s. On some undocumented yet popular links like USB or LTE the 33-33- is used. Alex > Regards > > Francis.Dupont@fdupont.fr > From nobody Wed Jul 13 20:21:49 2016 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7ED2F12B01F; Wed, 13 Jul 2016 20:21:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.221 X-Spam-Level: X-Spam-Status: No, score=-4.221 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] 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 243FP6ZwjbLZ; Wed, 13 Jul 2016 20:21:46 -0700 (PDT) Received: from usplmg20.ericsson.net (usplmg20.ericsson.net [198.24.6.45]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B098212B009; Wed, 13 Jul 2016 20:21:42 -0700 (PDT) X-AuditID: c618062d-f79886d000002334-f3-5786fa4823b3 Received: from EUSAAHC003.ericsson.se (Unknown_Domain [147.117.188.81]) by usplmg20.ericsson.net (Symantec Mail Security) with SMTP id D4.DB.09012.84AF6875; Thu, 14 Jul 2016 04:34:49 +0200 (CEST) Received: from EUSAAMB107.ericsson.se ([147.117.188.124]) by EUSAAHC003.ericsson.se ([147.117.188.81]) with mapi id 14.03.0294.000; Wed, 13 Jul 2016 23:21:41 -0400 From: Suresh Krishnan To: "draft-ietf-6man-multi-homed-host@ietf.org" Subject: AD evaluation: draft-ietf-6man-multi-homed-host-07 Thread-Topic: AD evaluation: draft-ietf-6man-multi-homed-host-07 Thread-Index: AdHdftZ4HPvmG4yhTjm6ydPcMELyCg== Date: Thu, 14 Jul 2016 03:21:40 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [147.117.188.11] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFrrHLMWRmVeSWpSXmKPExsUyuXRPoK7nr7Zwgx0qFn9+zGS3eHn2PZMD k8eSJT+ZAhijuGxSUnMyy1KL9O0SuDLurLnOVjCXuWLGvyPMDYzHmboYOTkkBEwkWtd8Y4Ow xSQu3FsPZHNxCAkcZZTY/uwNE4SznFHi+p8tYB1sQB0bdn4Gs0UEYiVWTTnGDmIzC2hJrH79 nxXEFhawlpi0qocdosZBovfCTFYIW09i+/MnYDaLgKrEmS1XwGxeAV+JC89OsIDYjEBXfD+1 hgliprjErSfzoS4VkFiy5zwzhC0q8fLxP1YIW0ni4+/5UDfoSCzY/YkNwtaWWLbwNTPEfEGJ kzOfsExgFJmFZOwsJC2zkLTMQtKygJFlFSNHaXFBTm66kcEmRmCoH5Ng093BeH+65yFGAQ5G JR7eBY1t4UKsiWXFlbmHGCU4mJVEeC3/AIV4UxIrq1KL8uOLSnNSiw8xSnOwKInzij1SDBcS SE8sSc1OTS1ILYLJMnFwSjUwbozyP3i3nP+nZU6P1r8rxVf+6G/9w1xrL7h8lzq7n2m+eY/6 zzXW93ZU6Zmr7WY3d9o98Wg1e15S+jGuFJuFmTEzIxRdrX973N98WJdx7kVtWZUdx1+v9fxc r5jku3lX+YKPtjs+xs213bKzZdWDnhir7sNLxTdmWDtdf2XfHBjh+YE3+cByJZbijERDLeai 4kQAV60ou3ECAAA= Archived-At: Cc: IETF IPv6 Mailing List X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.17 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 Jul 2016 03:21:47 -0000 Hi all,=0A= I have gone through draft-ietf-6man-multi-homed-host-07 and have not = =0A= found any issues that prevent the draft from progressing. Thanks for cleari= ng =0A= up the issues brought up in the the INT directorate reviews. I will go ahea= d =0A= and send the draft into IETF Last Call (a 3 week last call to account for t= he =0A= IETF week in between).=0A= =0A= Thanks=0A= Suresh=0A= From nobody Thu Jul 14 03:01: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 599C712D8B5; Thu, 14 Jul 2016 03:01:07 -0700 (PDT) Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit From: The IESG To: "IETF-Announce" Subject: Last Call: (Routing packets from hosts in a multi-prefix network) to Proposed Standard X-Test-IDTracker: no X-IETF-IDTracker: 6.27.0 Auto-Submitted: auto-generated Precedence: bulk Sender: Message-ID: <20160714100107.30344.57113.idtracker@ietfa.amsl.com> Date: Thu, 14 Jul 2016 03:01:07 -0700 Archived-At: Cc: ipv6@ietf.org, suresh.krishnan@ericsson.com, jounikor@gmail.com, draft-ietf-6man-multi-homed-host@ietf.org, 6man-chairs@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.17 Reply-To: ietf@ietf.org List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 Jul 2016 10:01:07 -0000 The IESG has received a request from the IPv6 Maintenance WG (6man) to consider the following document: - 'Routing packets from hosts in a multi-prefix network' as Proposed Standard The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send substantive comments to the ietf@ietf.org mailing lists by 2016-08-04. Exceptionally, comments may be sent to iesg@ietf.org instead. In either case, please retain the beginning of the Subject line to allow automated sorting. Abstract This document describes expected IPv6 host behavior in a scenario that has more than one prefix, each allocated by an upstream network that implements BCP 38 ingress filtering, when the host has multiple routers to choose from. It also applies to other scenarios such as the usage of stateful firewalls that effectively act as address-based filters. This host behavior may interact with source address selection in a given implementation, but logically follows it. Given that the network or host is, or appears to be, multihomed with multiple provider-allocated addresses, that the host has elected to use a source address in a given prefix, and that some but not all neighboring routers are advertising that prefix in their Router Advertisement Prefix Information Options, this document specifies to which router a host should present its transmission. It updates RFC 4861. The file can be obtained via https://datatracker.ietf.org/doc/draft-ietf-6man-multi-homed-host/ IESG discussion can be tracked via https://datatracker.ietf.org/doc/draft-ietf-6man-multi-homed-host/ballot/ No IPR declarations have been submitted directly on this I-D. From nobody Sat Jul 16 05:00:36 2016 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EBADF12D0AB for ; Sat, 16 Jul 2016 05:00:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.336 X-Spam-Level: X-Spam-Status: No, score=-1.336 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, SPF_HELO_PASS=-0.001, SPF_SOFTFAIL=0.665] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=employees.org; domainkeys=pass (1024-bit key) header.from=otroan@employees.org header.d=employees.org 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 nXZVAgHaRTYW for ; Sat, 16 Jul 2016 05:00:32 -0700 (PDT) Received: from incoming.kjsl.com (inbound02.kjsl.com [IPv6:2001:1868:2002::144]) (using TLSv1.2 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BBF1812D0A1 for ; Sat, 16 Jul 2016 05:00:30 -0700 (PDT) Received: from cowbell.employees.org ([IPv6:2001:1868:a000:17::142]) by ironport02.kjsl.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 16 Jul 2016 12:00:29 +0000 Received: from cowbell.employees.org (localhost [127.0.0.1]) by cowbell.employees.org (Postfix) with ESMTP id 631D19CC7C; Sat, 16 Jul 2016 05:00:28 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=employees.org; h=from :content-type:subject:date:message-id:cc:to:mime-version; s= selector1; bh=Hodx1DDf9h3XLtgGQIFO1VYcvoU=; b=EcOLHQE08e81YHqhHO FLhne4Ofox0Z3i4WvG/Os/ukgSLZyYc1jmG7kYif7BZpghaTRhLEcmf5r+Xvjonq O9OBAljbKsN2xWWPyIAWiZPqOfZdBZt4rCSNCFbTp1csXPesU/jKJXgNo2GnU3dC 4jJvUBCd2gW8xvty3gt1QKR/U= DomainKey-Signature: a=rsa-sha1; c=nofws; d=employees.org; h=from :content-type:subject:date:message-id:cc:to:mime-version; q=dns; s=selector1; b=O9CAHT4C9IzzKF7zPzAtwQjCjttfsh7nWXKJ1DI88R25DPCH mahtwPzO0r2nJXNw1yS/vrd11U+JubsjIpVmMWDLFlKvVrTC4mjzSnfiOXGmK1Fr 95DXSNN1jV8QDC17tMsbhentLukVJdMZ3bcqXkav+EFbCXVkHIvLFouBELw= Received: from h.hanazo.no (dhcp-8959.meeting.ietf.org [31.133.137.89]) (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 1103C9CC4F; Sat, 16 Jul 2016 05:00:28 -0700 (PDT) Received: from [IPv6:::1] (localhost [IPv6:::1]) by h.hanazo.no (Postfix) with ESMTP id E0E5828C57F8; Sat, 16 Jul 2016 14:00:25 +0200 (CEST) From: otroan@employees.org X-Pgp-Agent: GPGMail Content-Type: multipart/signed; boundary="Apple-Mail=_116698C0-A968-4933-BF95-7516F26398C7"; protocol="application/pgp-signature"; micalg=pgp-sha512 Subject: Minute takers and Jabber scribe Date: Sat, 16 Jul 2016 14:00:25 +0200 Message-Id: <3E6A4B8D-E515-47D0-9D11-7136E46496CE@employees.org> To: 6man WG Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) X-Mailer: Apple Mail (2.3124) Archived-At: Cc: 6man-chairs@tools.ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.17 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 Jul 2016 12:00:34 -0000 --Apple-Mail=_116698C0-A968-4933-BF95-7516F26398C7 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Can we please get one or two volunteers (the more the merrier) doing the = minutes and a Jabber scribe for the 6MAN meeting on Tuesday? The intention is to do the minutes using the Etherpad, allowing multiple = minute takers to contribute simultaneously: https://tools.ietf.org/wg/6man/minutes Best regards, Ole --Apple-Mail=_116698C0-A968-4933-BF95-7516F26398C7 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 iQEcBAEBCgAGBQJXiiHZAAoJED4aXnjSQuKWGq8H/2k4UdAlhZZ6WmhUk12wXTbF /1SyJtWA217te6ikJshgr6QNQFzXeQocCP+q71WrxCCGuRZoBC/S+BaZzu/BorRU oTUZYsgY4e4Xm/1S1bUOFq3VyFvhfitnBT0uLVI8HW18Kq1tunDgznOlLrQvG7zF tq7WfQlcNHX6Uy4R8loiZZNB2ltgnEXUIXsUS0gDu+pbKF7FD31fNg8ghR0reDpH +EN8vOAdH0yVQ9jLuYJFMHY6fB7e5sSFvHzvFYUEeDzJSwyHrAgY+YUEtTumNcAa wIFAlZ/0KJmoiw5Dt1/sPZRUJBkKr+pJiMuvEppgOVkEMNbrVI0ovj2PcDo+9iA= =D5EO -----END PGP SIGNATURE----- --Apple-Mail=_116698C0-A968-4933-BF95-7516F26398C7-- From nobody Sat Jul 16 05:23:58 2016 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D912312B027 for ; Sat, 16 Jul 2016 05:23:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.565 X-Spam-Level: X-Spam-Status: No, score=-0.565 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, LOTS_OF_MONEY=0.001, RCVD_IN_SORBS_WEB=0.77, SPF_HELO_PASS=-0.001, SPF_SOFTFAIL=0.665] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=employees.org; domainkeys=pass (1024-bit key) header.from=otroan@employees.org header.d=employees.org 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 0_midFDeDiGk for ; Sat, 16 Jul 2016 05:23:54 -0700 (PDT) Received: from incoming.kjsl.com (inbound02.kjsl.com [IPv6:2001:1868:2002::144]) (using TLSv1.2 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2EB3012B00B for ; Sat, 16 Jul 2016 05:23:53 -0700 (PDT) Received: from cowbell.employees.org ([65.50.211.142]) by ironport02.kjsl.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 16 Jul 2016 12:23:53 +0000 Received: from cowbell.employees.org (localhost [127.0.0.1]) by cowbell.employees.org (Postfix) with ESMTP id 102D99CC4F; Sat, 16 Jul 2016 05:23:52 -0700 (PDT) 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=gxdNoiAHkxdgZeVjK5G8kWc8ysA=; b= cX3aq9u93qcFcwej11oElmz6SYeO44G924SB2mNDuPCmLS1YUUTkyFLdO1nzsif4 OK8ciU7dsHxy+aIXku6ETOnK48pl7oX9koJrUI8C2+TJwdbhy0sgXchdLhlqUljg YzURG/YXT8Qw5CAjwQpsoAai+XuXkYUbnotydoQgDTs= 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=ekS2qdjX8qufD8kcFUE7SnfGP+ G0rdWlnQi4ngNz/yKMrJNKpZ/Ge+y2tjbm6U5IEyvK+obwibtTvL8IbMzF88ZKtM Vzp09UeQCZivfwPo3dwpiLOdO2QL6JtiZddpNKn99tFkL5HrfVOuXQz1A3ibA8cd qm+gCAinOGW8VjFiQ= Received: from h.hanazo.no (dhcp-8959.meeting.ietf.org [31.133.137.89]) (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 97B1D9CC4E; Sat, 16 Jul 2016 05:23:51 -0700 (PDT) Received: from [IPv6:::1] (localhost [IPv6:::1]) by h.hanazo.no (Postfix) with ESMTP id 549C728CFB20; Sat, 16 Jul 2016 14:23:49 +0200 (CEST) Subject: Re: Reference to "3333" value of RFC2464 "IPv6 over Ethernet" Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) Content-Type: multipart/signed; boundary="Apple-Mail=_4B1BADFA-0DFD-4131-BC91-95E4E0BBD0B3"; protocol="application/pgp-signature"; micalg=pgp-sha512 X-Pgp-Agent: GPGMail From: otroan@employees.org In-Reply-To: Date: Sat, 16 Jul 2016 14:23:49 +0200 Message-Id: <517260B0-B759-4F79-8D9A-730909BDE0D8@employees.org> References: <201607111621.u6BGL0FL027624@givry.fdupont.fr> To: Alexandre Petrescu X-Mailer: Apple Mail (2.3124) Archived-At: Cc: Francis Dupont , 6man WG X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.17 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 Jul 2016 12:23:57 -0000 --Apple-Mail=_4B1BADFA-0DFD-4131-BC91-95E4E0BBD0B3 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=windows-1252 > This confirms more and more that 3333 stands for IETF 33, which looks cool. but it doesn't. it comes from: https://www.parc.com/util/map.html which was Steve's employer at the time. Best regards, Ole > > But a less cool 0x3 could have accommodated more Group IDs from IPv6 > multicast addresses. Whereas 0x3333 can prefix 32bits of Group ID, 0x3 > could prefix 40bits of Group ID. > > (in RFC4291 "IPv6 addr arch" the Group ID is 112 bits long). > > Allow me now to comment on this message: > >> (to identify the message I selected these lines from the header) >> >> To: ipng@sunroof.Eng.Sun.COM Subject: (IPng 192) IPv6 ethertype, >> multicast address mapping, etc. Date: Fri, 16 Jun 1995 18:32:30 PDT >> From: Steve Deering Message-Id: >> <95Jun16.183244pdt.75270@digit.parc.xerox.com> ... >> >> On another Ethernet-related topic, we have never specified how IPv6 >> multicast addresses are to be mapped to Ethernet multicast addresses. >> I believe that some of the prototype IPv6 implementations are >> curently using the same mapping as IPv4, that is, replacing the >> low-order 23 bits of the ethernet address 01-00-5E-00-00-00 with the >> low-order 23 bits of the IP multicast address. It would be nice to >> use a slightly more efficient mapping for IPv6 (extracting 23 bits >> is sorta fiddly). I propose the following: >> >> replace the low-order 32 bits of the ethernet address >> 33-33-00-00-00-00 with the low-order 32 bits of the IPv6 multicast >> address. >> >> The 33-33- prefix has both the Group (Multicast) bit set and the >> Locally Administered bit set. (They are the lowest-order and second >> lowest-order bits, respectively, of the first octet, in the canonical >> address representation.) > > For information, there is talk recently about privacy uses of the L bit > in the MAC address field of a MAC header carrying IPv6 packets. > > This would make it for two distinct Local prefixes both for IETF. > >> It would be more politically correct to use a Universally >> Administered prefix, but those are handed out by the IEEE at $1000 >> per 24-bit chunk, which would mean we'd have to pay a quarter of a >> million dollars to get 32 bits of ethernet multicast address space, > > I dont understand why this reasoning was not pushed further. Using 0x3 > instead of 0x3333 would have saved even more money. > >> even though almost all the the 46 bits of total ethernet multicast >> address space is unused and will never be used. > > I dont understand this claim of never expected be used. > > The length of the Group ID in an IPv6 multicast address is 112bits. > > The number of reserved Group IDs grows more and more (all-nodes, > all-routers, all-ntp-servers...). > > One day there will be no place left in the MAC addresses to map each of > these Group IDs. > >> If we instead use the locally- administered space, we don't have to >> pay anyone, > > Yes. > >> but we run the hazard of colliding with some other local usage of >> that 33-33- prefix. I suspect that such collisions are highly >> improbable (I did check the database of known ethernet address usage >> maintained at MIT, and there was no known conflict recorded there), >> but if anyone knows of any existing use of that prefix, please speak >> up -- I'd like to settle this question before the end of the month. > > Well we are now many years later, but I think the collision risk may > have grown: > > - there are more non-IP protocols sitting on EthernetII headers than > were at the time. > - some other non-multicast but IP protocols considering the use of the > L bit appear. > - the 33-33 number is not mentioned anywhere by IEEE nowhere. > >> By the way, this mapping would apply to Ethernet and FDDI, but *not* >> to Token Ring, where most host adapters have insufficient multicast >> address filtering to deal with proper multicast addresses. Instead, >> on Token Rings, IPv6 multicast addresses would all be mapped to the >> single "functional" address already allocated to IP, that is >> 03-00-00-20-00-00 in canonical form (see RFC 1469, IP Multicast over >> Token-Ring LANs). > > This RFC is now Historic because IPv4. The IPv6-over-token-ring RFC2470 > does use 03-00- instead of 33-33-. > > The IPv6-over-802154 RFC4944 uses a 16bit multicast MAC address which is > binary 100XXXXX-XXXXXXXX. Other non-Ethernet IEEE links not using > 33-33- are "IEEE 1394 highperf serial" RFC3146 - MCA type 2, and "IEEE > 802.16" - bridged, so supposedly 48 1s. > > On some undocumented yet popular links like USB or LTE the 33-33- is used. > > Alex > > >> Regards >> >> Francis.Dupont@fdupont.fr >> > > -------------------------------------------------------------------- > IETF IPv6 working group mailing list > ipv6@ietf.org > Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 > -------------------------------------------------------------------- --Apple-Mail=_4B1BADFA-0DFD-4131-BC91-95E4E0BBD0B3 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 iQEcBAEBCgAGBQJXiidVAAoJED4aXnjSQuKW/yMH/3mHpEOZEDhHzx49Fh12beXz aGYp5h/6HGcru5lu1nZ12UOAPJeCsRnVThhhsHbC/mipbgn69NMLi8MCkpklll0h d1DMF5CObdXe9qW7KlCHTiG+d6XYVoMFbXJfHh8xodxrtP6nsHvv4rbVUAH4UDvH Q4WF9jU0ys7dQ5rqU5uSUlfeTD6DqdqEH4l3qPHeRk6rZbjnBrMhfvtXr/5dpQth AzKky4siU3MiCaEukozpMD7LxJZibEfa/PjJ64JSSlaNx5VNc0IdrxmNFc9y4G78 wjO6NuBoT1HckVX+Sh25Q+stB0WRrmm6CYJ3rsxt+EIOOGvnJCrtTPUdzyXE/5E= =qFDr -----END PGP SIGNATURE----- --Apple-Mail=_4B1BADFA-0DFD-4131-BC91-95E4E0BBD0B3-- From nobody Sat Jul 16 20:57:41 2016 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B993012B020 for ; Sat, 16 Jul 2016 20:57:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.199 X-Spam-Level: X-Spam-Status: No, score=-1.199 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, HK_RANDOM_FROM=0.999, LOTS_OF_MONEY=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=no 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 A9HZ1CzjHxPy for ; Sat, 16 Jul 2016 20:57:37 -0700 (PDT) Received: from mail-vk0-x230.google.com (mail-vk0-x230.google.com [IPv6:2607:f8b0:400c:c05::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 7B7B912B004 for ; Sat, 16 Jul 2016 20:57:37 -0700 (PDT) Received: by mail-vk0-x230.google.com with SMTP id j126so148000023vkg.3 for ; Sat, 16 Jul 2016 20:57:37 -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=G1G3jWpeeLO5pu3MdknHoq/GscRbml3nvV8aT7onisY=; b=TEBbTMhef5QLapdreFmLR4eMBJ0WvEjJVG/sJ0a2od8+TlWSxs9f8jaqrSAhD20sj6 Yd2OU8si0NdGmNCCQoXtWNAHjfDSbTySqUwAzlPecuAF/6t2LmOEDqp7LzlvV21YIbkM u/A8yFbhqKeIpHy0bqdK7NhdO632JE5LCOToX4dgar2gCW2ArNnOMGF+zofQAppVRhWv zrSMr1GFF2IaC+W0e9NmQlfR9JtJBcQ1I4yRydoywhLMRQZgKr0ggai3Cn208SPyhwYV qYWxP458m9AOhvl0/CRWwdMZgGiPjqrArsdzapmVjdBZKOmt53opWy3Xg98z8yFnssCt sYOw== 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=G1G3jWpeeLO5pu3MdknHoq/GscRbml3nvV8aT7onisY=; b=RL7XmcjB/4wlbFvA9gPJEytpJE+L/b8CCuSk23tCpgbU/KIiSAMAhwY52owC8cyrqY nEuzQm/UFXS/eLCGQkHDgGV/V18mR52Ey5UtZwvjD9vhSSu9sXdoOl+zuVYTUb6EI4E5 Uwsg3wY84O95hAAUF+tkGWL1RqZ2oryYXquckrk+KcBUuIx+chCUZO4NAGQrCPxMjVVt 1AiEZ7amLaVycJ6o+mRFareVZY44b881osAvzFMcNrs40JUtikUCdHfpFmYi6HoiGMPn sgXNu+d5fxFWlIFJe869jzzKaafVy8EKp/euPIF+rfWb3ypWuUMCmQJZ5ucypIzsyaqj XH+A== X-Gm-Message-State: ALyK8tIWcHhgaTb2WWbjUOMnLe+lXRtYjSdtesjDW+9owIiXad3hjWXwcPrlJzMtvWLtdXxOKD5Ynddw+7Zd3g== X-Received: by 10.159.55.199 with SMTP id q65mr14715638uaq.125.1468727856432; Sat, 16 Jul 2016 20:57:36 -0700 (PDT) MIME-Version: 1.0 Received: by 10.159.39.233 with HTTP; Sat, 16 Jul 2016 20:57:07 -0700 (PDT) In-Reply-To: <517260B0-B759-4F79-8D9A-730909BDE0D8@employees.org> References: <201607111621.u6BGL0FL027624@givry.fdupont.fr> <517260B0-B759-4F79-8D9A-730909BDE0D8@employees.org> From: Mark Smith Date: Sun, 17 Jul 2016 13:57:07 +1000 Message-ID: Subject: Re: Reference to "3333" value of RFC2464 "IPv6 over Ethernet" To: Ole Troan Content-Type: text/plain; charset=UTF-8 Archived-At: Cc: Alexandre Petrescu , Francis Dupont , 6man WG X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 17 Jul 2016 03:57:40 -0000 On 16 July 2016 at 22:23, wrote: >> This confirms more and more that 3333 stands for IETF 33, which looks cool. > > but it doesn't. it comes from: > https://www.parc.com/util/map.html > > which was Steve's employer at the time. > I wonder if that was intended to be changed at some point, meaning buying the required number of contiguous official OUIs. Obviously too late now, however having been the victim of an upstream supplier forcing us to route parts of their RFC1918 address space in our network, I really don't agree with turning private, non-unique, local scope address spaces into ones visible outside your network or embedded in global products/protocols/software. Regards, Mark. > Best regards, > Ole > >> >> But a less cool 0x3 could have accommodated more Group IDs from IPv6 >> multicast addresses. Whereas 0x3333 can prefix 32bits of Group ID, 0x3 >> could prefix 40bits of Group ID. >> >> (in RFC4291 "IPv6 addr arch" the Group ID is 112 bits long). >> >> Allow me now to comment on this message: >> >>> (to identify the message I selected these lines from the header) >>> >>> To: ipng@sunroof.Eng.Sun.COM Subject: (IPng 192) IPv6 ethertype, >>> multicast address mapping, etc. Date: Fri, 16 Jun 1995 18:32:30 PDT >>> From: Steve Deering Message-Id: >>> <95Jun16.183244pdt.75270@digit.parc.xerox.com> ... >>> >>> On another Ethernet-related topic, we have never specified how IPv6 >>> multicast addresses are to be mapped to Ethernet multicast addresses. >>> I believe that some of the prototype IPv6 implementations are >>> curently using the same mapping as IPv4, that is, replacing the >>> low-order 23 bits of the ethernet address 01-00-5E-00-00-00 with the >>> low-order 23 bits of the IP multicast address. It would be nice to >>> use a slightly more efficient mapping for IPv6 (extracting 23 bits >>> is sorta fiddly). I propose the following: >>> >>> replace the low-order 32 bits of the ethernet address >>> 33-33-00-00-00-00 with the low-order 32 bits of the IPv6 multicast >>> address. >>> >>> The 33-33- prefix has both the Group (Multicast) bit set and the >>> Locally Administered bit set. (They are the lowest-order and second >>> lowest-order bits, respectively, of the first octet, in the canonical >>> address representation.) >> >> For information, there is talk recently about privacy uses of the L bit >> in the MAC address field of a MAC header carrying IPv6 packets. >> >> This would make it for two distinct Local prefixes both for IETF. >> >>> It would be more politically correct to use a Universally >>> Administered prefix, but those are handed out by the IEEE at $1000 >>> per 24-bit chunk, which would mean we'd have to pay a quarter of a >>> million dollars to get 32 bits of ethernet multicast address space, >> >> I dont understand why this reasoning was not pushed further. Using 0x3 >> instead of 0x3333 would have saved even more money. >> >>> even though almost all the the 46 bits of total ethernet multicast >>> address space is unused and will never be used. >> >> I dont understand this claim of never expected be used. >> >> The length of the Group ID in an IPv6 multicast address is 112bits. >> >> The number of reserved Group IDs grows more and more (all-nodes, >> all-routers, all-ntp-servers...). >> >> One day there will be no place left in the MAC addresses to map each of >> these Group IDs. >> >>> If we instead use the locally- administered space, we don't have to >>> pay anyone, >> >> Yes. >> >>> but we run the hazard of colliding with some other local usage of >>> that 33-33- prefix. I suspect that such collisions are highly >>> improbable (I did check the database of known ethernet address usage >>> maintained at MIT, and there was no known conflict recorded there), >>> but if anyone knows of any existing use of that prefix, please speak >>> up -- I'd like to settle this question before the end of the month. >> >> Well we are now many years later, but I think the collision risk may >> have grown: >> >> - there are more non-IP protocols sitting on EthernetII headers than >> were at the time. >> - some other non-multicast but IP protocols considering the use of the >> L bit appear. >> - the 33-33 number is not mentioned anywhere by IEEE nowhere. >> >>> By the way, this mapping would apply to Ethernet and FDDI, but *not* >>> to Token Ring, where most host adapters have insufficient multicast >>> address filtering to deal with proper multicast addresses. Instead, >>> on Token Rings, IPv6 multicast addresses would all be mapped to the >>> single "functional" address already allocated to IP, that is >>> 03-00-00-20-00-00 in canonical form (see RFC 1469, IP Multicast over >>> Token-Ring LANs). >> >> This RFC is now Historic because IPv4. The IPv6-over-token-ring RFC2470 >> does use 03-00- instead of 33-33-. >> >> The IPv6-over-802154 RFC4944 uses a 16bit multicast MAC address which is >> binary 100XXXXX-XXXXXXXX. Other non-Ethernet IEEE links not using >> 33-33- are "IEEE 1394 highperf serial" RFC3146 - MCA type 2, and "IEEE >> 802.16" - bridged, so supposedly 48 1s. >> >> On some undocumented yet popular links like USB or LTE the 33-33- is used. >> >> Alex >> >> >>> Regards >>> >>> Francis.Dupont@fdupont.fr >>> >> >> -------------------------------------------------------------------- >> 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 Sun Jul 17 05:19:00 2016 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8E22212D1DC for ; Sun, 17 Jul 2016 05:18:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -15.807 X-Spam-Level: X-Spam-Status: No, score=-15.807 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, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-1.287, 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 R25X5jYw9RjT for ; Sun, 17 Jul 2016 05:18:56 -0700 (PDT) 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 8249112D501 for ; Sun, 17 Jul 2016 05:18:56 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=9943; q=dns/txt; s=iport; t=1468757936; x=1469967536; h=from:to:cc:subject:date:message-id:mime-version; bh=15Ct1Otlrfn93DJiYMYFBud0jOW8/xgHI6qxZt1/Nks=; b=DXlKtpjcPkkQ6Bpl79YC2HwV6ecraslBr6tKSSNPh1l6Y9CGOiqfvDP0 sE0cdesNsUCQeuLT8utm9VxdVhvO2fwLa8tgVj9zlVFXcvpCOIcZCcwYU b7UaAZ5ja/C7kZ1eV46Cr7K8Ni9CyMHtYEwX5/oyrtoDL0js8MwF/zHqc U=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0CEAgB4dotX/40NJK1bgnFOVnysW4cXh?= =?us-ascii?q?QSBeSKFLkoegQQ4FAEBAQEBAQFlJ4RcAQEEAQEBIQpBCwUNAQgOCioCBB8GCyc?= =?us-ascii?q?EDgUIiA4DDwgOsESJLg2EHgEBAQEBAQEBAQEBAQEBAQEBAQEBARcFineBOYEKg?= =?us-ascii?q?hSCaoJaBYgfkFE0AYYShjGCFIFyhFmIc4glh3gBHjaCCxyBTG4BAYgYAQEB?= X-IronPort-AV: E=Sophos;i="5.28,378,1464652800"; d="scan'208,217";a="297971584" Received: from alln-core-8.cisco.com ([173.36.13.141]) by alln-iport-4.cisco.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 17 Jul 2016 12:18:55 +0000 Received: from XCH-RCD-005.cisco.com (xch-rcd-005.cisco.com [173.37.102.15]) by alln-core-8.cisco.com (8.14.5/8.14.5) with ESMTP id u6HCIt6n011313 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Sun, 17 Jul 2016 12:18:55 GMT Received: from xch-rcd-003.cisco.com (173.37.102.13) by XCH-RCD-005.cisco.com (173.37.102.15) with Microsoft SMTP Server (TLS) id 15.0.1210.3; Sun, 17 Jul 2016 07:18:55 -0500 Received: from xch-rcd-003.cisco.com ([173.37.102.13]) by XCH-RCD-003.cisco.com ([173.37.102.13]) with mapi id 15.00.1210.000; Sun, 17 Jul 2016 07:18:55 -0500 From: "Toerless Eckert (eckert)" To: Jen Linkova Subject: Re: Reference to "3333" value of RFC2464 "IPv6 over Ethernet" Thread-Topic: Reference to "3333" value of RFC2464 "IPv6 over Ethernet" Thread-Index: AQHR4CViV9jx7H/Zc0qof+nWbhqxdA== Date: Sun, 17 Jul 2016 12:18:54 +0000 Message-ID: <2f437218b23a44238ccdcb4e7318da8d@XCH-RCD-003.cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted Content-Type: multipart/alternative; boundary="_000_2f437218b23a44238ccdcb4e7318da8dXCHRCD003ciscocom_" MIME-Version: 1.0 Archived-At: Cc: Alexandre Petrescu , IPv6 X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 17 Jul 2016 12:18:58 -0000 --_000_2f437218b23a44238ccdcb4e7318da8dXCHRCD003ciscocom_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MzMzMyBpcyBmb3IgaXB2NiBtdWx0aWNhc3QuIFRoYXQgb3RoZXIgYWRkcmVzcyBtZW50aW9uZWQg aW4gdGhlIHRocmVhZCBpcyBwcm9iYWJseSBmb3IgaXNpcywgd2hpY2ggZG9lcyBub3QgdXNlIGlw L2lwdnQNCg0KdHlwb3MgPSBzbWFydHBob25lDQoNCk9uIEp1bCA4LCAyMDE2IDg6MzIgQU0sIEpl biBMaW5rb3ZhIDxmdXJyeTEzQGdtYWlsLmNvbT4gd3JvdGU6DQpPbiBGcmksIEp1bCA4LCAyMDE2 IGF0IDQ6NDkgUE0sIEFsZXhhbmRyZSBQZXRyZXNjdQ0KPGFsZXhhbmRyZS5wZXRyZXNjdUBnbWFp bC5jb20+IHdyb3RlOg0KPj4+IFJGQzI0NjQgIklQdjYgb3ZlciBFdGhlcm5ldCIgc2F5czoNCj4+ Pj4gNy4gIEFkZHJlc3MgTWFwcGluZyAtLSBNdWx0aWNhc3QNCj4+Pj4NCj4+Pj4gQW4gSVB2NiBw YWNrZXQgd2l0aCBhIG11bHRpY2FzdCBkZXN0aW5hdGlvbiBhZGRyZXNzIERTVCwgY29uc2lzdGlu Zw0KPj4+PiBvZiB0aGUgc2l4dGVlbiBvY3RldHMgRFNUWzFdIHRocm91Z2ggRFNUWzE2XSwgaXMg dHJhbnNtaXR0ZWQgdG8gdGhlDQo+Pj4+IEV0aGVybmV0IG11bHRpY2FzdCBhZGRyZXNzIHdob3Nl IGZpcnN0IHR3byBvY3RldHMgYXJlIHRoZSB2YWx1ZSAzMzMzDQo+Pj4+IGhleGFkZWNpbWFsIGFu ZCB3aG9zZSBsYXN0IGZvdXIgb2N0ZXRzIGFyZSB0aGUgbGFzdCBmb3VyIG9jdGV0cyBvZg0KPj4+ PiBEU1QuDQo+Pj4NCj4+Pg0KPj4+IFdoZXJlIGlzIHRoaXMgIjMzMzMiIHZhbHVlIGRlZmluZWQ/ ICBPYnZpb3VzbHkgYW4gUkZDIGlzIG5vdCB0aGUgcGxhY2UgdG8NCj4+PiBkZWZpbmUgYW4gRXRo ZXJuZXQgbXVsdGljYXN0IGFkZHJlc3MuDQo+Pg0KPj4NCj4+IGh0dHBzOi8vdG9vbHMuaWV0Zi5v cmcvaHRtbC9yZmM1MzQyI3NlY3Rpb24tMi4zLjENCj4+DQo+PiBQbGVhc2Ugbm90ZSB0aGF0IGl0 IGhhcyAnbG9jYWw7IGJpdCBzZXQgc28gdGhhdCBPVUkgcmFuZ2UgKDMzLTMzLVhYDQo+PiBkaWQg bm90IG5lZWQgdG8gYmUgcHVyY2hhc2VkKS4NCj4NCj4NCj4gV2h5IGlzbid0IHRoaXMgYWRkcmVz cyBsaXN0ZWQgYnkgSUVFRSAiR1JPVVAgTUFDIFBVQkxJQyBMSVNUSU5HIj8NCj4gaHR0cHM6Ly9z dGFuZGFyZHMuaWVlZS5vcmcvZGV2ZWxvcC9yZWdhdXRoL2dycG1hYy9wdWJsaWMuaHRtbA0KDQo+ IFdoeSBJRUVFIGxpc3RzIF9vdGhlcl8gYWRkcmVzc2VzIHRoYXQgY2FuIGJlIHVzZWQgZm9yIHNh bWUgcm9sZToNCj4gMDEtODAtQzItMDAtMDAtMUQgSVNPL0lFQyBKVEMxL1NDNiBJU08vSUVDIDk1 NDINCj4gIkFsbCBNdWx0aWNhc3QgQ2FwYWJsZSBJbnRlcm1lZGlhdGUgU3lzdGVtcyBBZGRyZXNz Ig0KDQpCZWNhdXNlIHRoZSBPVUkgMzMtMzMtIGlzICpsb2NhbGx5IGFkbWluaXN0ZXJlZCogKGl0 IGhhcyB0aGUgTG9jYWwgYml0IHNldCkuDQpJdCBpcyBub3QgYWxsb2NhdGVkIGJ5IGFueSByZWdp c3RyeS4gVGhlIGxpbmsgeW91IGFyZSByZWZlcnJpbmcgdG8NCmxpc3RzIGFkZHJlc3Nlcw0KZnJv bSB0aGUgVW5pdmVyc2FsbHkgQWRtaW5pc3RlcmVkIEFkZHJlc3MgQmxvY2suDQoNCj4gUkZDNTM0 MiBzYXlzOg0KPj4NCj4+ICAgQWxsIE1BQy00OCBtdWx0aWNhc3QgaWRlbnRpZmllcnMgcHJlZml4 ZWQgIjMzLTMzIiAodGhhdCBpcywgdGhlIDIqKjMyDQo+PiAgICBtdWx0aWNhc3QgTUFDIGlkZW50 aWZpZXJzIGluIHRoZSByYW5nZSBmcm9tIDMzLTMzLTAwLTAwLTAwLTAwIHRvDQo+PiAgICAzMy0z My1GRi1GRi1GRi1GRikgYXJlIHVzZWQgYnkgdGhlIElFVEYgZm9yIGdsb2JhbCBJUHY2IG11bHRp Y2FzdA0KPj4gICAgW1JGQzI0NjRdLg0KPg0KPg0KPiBXaGF0IGRvZXMgImdsb2JhbCBJUHY2IG11 bHRpY2FzdCIgbWVhbj8gIFRoZSB0ZXJtICJnbG9iYWwiIGlzIG1pc2xlYWRpbmcNCj4gYmVjYXVz ZSBvZiB0aGF0ICdsb2NhbCcgYml0IHNldCB5b3Ugc2FpZCBhYm92ZSwgYW5kIGJlY2F1c2UgUkZD MjQ2NCBpcw0KPiBoYXBwZW5pbmcgb25seSBvbiBhIGxpbmsuICBNYXliZSBpdCBtZWFudCAiSVB2 NiBtdWx0aWNhc3QiPw0KPg0KPiBXaHkgZG9lcyBpdCByZWZlciB0byBSRkMyNDY0PyAgUkZDMjQ2 NCBpcyBvbmx5IGZvciBFdGhlcm5ldCwgbm90IGZvciBvdGhlcg0KPiBraW5kcyBvZiBsaW5rcy4N Cj4NCj4gSXQgcmVhZHMgYXMgaWYgYWxsIEludGVybmV0LWNvbm5lY3RlZCBub2RlcyB3ZXJlIG9u IEV0aGVybmV0IGFuZCBhcyBpZiBhbnkNCj4gSVAgbXVsdGljYXN0IGFkZHJlc3MgY291bGQgYmUg bWFwcGVkIGludG8gdGhlIDMyYml0cyBsZWZ0IG9mIGEgTUFDIG11bHRpY2FzdA0KPiBhZGRyZXNz ICh0aGV5IGNhbnQgLSB0aGV5IGFyZSAxMTJiaXQgbGVuZ3RoKS4NCg0KQUZBSVIgIFJGQzMzMDcg aGFzIHNvbWUgcmVjb21tZW5kYXRpb25zIG9uIGhvdyB0byBtaW5pbWl6ZSB0aGUgY2hhbmNlDQpv ZiBhZGRyZXNzIGNvbGxpc2lvbi4NCg0KLS0NClNZLCBKZW4gTGlua292YSBha2EgRnVycnkNCg0K LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0NCklFVEYgSVB2NiB3b3JraW5nIGdyb3VwIG1haWxpbmcgbGlzdA0KaXB2NkBp ZXRmLm9yZw0KQWRtaW5pc3RyYXRpdmUgUmVxdWVzdHM6IGh0dHBzOi8vd3d3LmlldGYub3JnL21h aWxtYW4vbGlzdGluZm8vaXB2Ng0KLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0NCg== --_000_2f437218b23a44238ccdcb4e7318da8dXCHRCD003ciscocom_ Content-Type: text/html; charset="utf-8" Content-ID: <7A9FC8BD65EAE14AB6B2BD58280C3D9F@emea.cisco.com> Content-Transfer-Encoding: base64 PGh0bWw+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIgY29udGVudD0i dGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjwvaGVhZD4NCjxib2R5Pg0KPHAgZGlyPSJsdHIi PjMzMzMgaXMgZm9yIGlwdjYgbXVsdGljYXN0LiBUaGF0IG90aGVyIGFkZHJlc3MgbWVudGlvbmVk IGluIHRoZSB0aHJlYWQgaXMgcHJvYmFibHkgZm9yIGlzaXMsIHdoaWNoIGRvZXMgbm90IHVzZSBp cC9pcHZ0PC9wPg0KPHAgZGlyPSJsdHIiPnR5cG9zID0gc21hcnRwaG9uZTwvcD4NCjxkaXYgY2xh c3M9InF1b3RlIj5PbiBKdWwgOCwgMjAxNiA4OjMyIEFNLCBKZW4gTGlua292YSAmbHQ7ZnVycnkx M0BnbWFpbC5jb20mZ3Q7IHdyb3RlOjxiciB0eXBlPSJhdHRyaWJ1dGlvbiI+DQo8YmxvY2txdW90 ZSBjbGFzcz0icXVvdGUiIHN0eWxlPSJtYXJnaW46MCAwIDAgLjhleDtib3JkZXItbGVmdDoxcHgg I2NjYyBzb2xpZDtwYWRkaW5nLWxlZnQ6MWV4Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRvciIgY29u dGVudD0iTWljcm9zb2Z0IEV4Y2hhbmdlIFNlcnZlciI+DQo8IS0tIGNvbnZlcnRlZCBmcm9tIHRl eHQgLS0+PHN0eWxlPjwhLS0gLkVtYWlsUXVvdGUgeyBtYXJnaW4tbGVmdDogMXB0OyBwYWRkaW5n LWxlZnQ6IDRwdDsgYm9yZGVyLWxlZnQ6ICM4MDAwMDAgMnB4IHNvbGlkOyB9IC0tPjwvc3R5bGU+ PGZvbnQgc2l6ZT0iMiI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMHB0OyI+DQo8ZGl2IGNsYXNz PSJQbGFpblRleHQiPk9uIEZyaSwgSnVsIDgsIDIwMTYgYXQgNDo0OSBQTSwgQWxleGFuZHJlIFBl dHJlc2N1PGJyPg0KJmx0O2FsZXhhbmRyZS5wZXRyZXNjdUBnbWFpbC5jb20mZ3Q7IHdyb3RlOjxi cj4NCiZndDsmZ3Q7Jmd0OyBSRkMyNDY0ICZxdW90O0lQdjYgb3ZlciBFdGhlcm5ldCZxdW90OyBz YXlzOjxicj4NCiZndDsmZ3Q7Jmd0OyZndDsgNy4mbmJzcDsgQWRkcmVzcyBNYXBwaW5nIC0tIE11 bHRpY2FzdDxicj4NCiZndDsmZ3Q7Jmd0OyZndDs8YnI+DQomZ3Q7Jmd0OyZndDsmZ3Q7IEFuIElQ djYgcGFja2V0IHdpdGggYSBtdWx0aWNhc3QgZGVzdGluYXRpb24gYWRkcmVzcyBEU1QsIGNvbnNp c3Rpbmc8YnI+DQomZ3Q7Jmd0OyZndDsmZ3Q7IG9mIHRoZSBzaXh0ZWVuIG9jdGV0cyBEU1RbMV0g dGhyb3VnaCBEU1RbMTZdLCBpcyB0cmFuc21pdHRlZCB0byB0aGU8YnI+DQomZ3Q7Jmd0OyZndDsm Z3Q7IEV0aGVybmV0IG11bHRpY2FzdCBhZGRyZXNzIHdob3NlIGZpcnN0IHR3byBvY3RldHMgYXJl IHRoZSB2YWx1ZSAzMzMzPGJyPg0KJmd0OyZndDsmZ3Q7Jmd0OyBoZXhhZGVjaW1hbCBhbmQgd2hv c2UgbGFzdCBmb3VyIG9jdGV0cyBhcmUgdGhlIGxhc3QgZm91ciBvY3RldHMgb2Y8YnI+DQomZ3Q7 Jmd0OyZndDsmZ3Q7IERTVC48YnI+DQomZ3Q7Jmd0OyZndDs8YnI+DQomZ3Q7Jmd0OyZndDs8YnI+ DQomZ3Q7Jmd0OyZndDsgV2hlcmUgaXMgdGhpcyAmcXVvdDszMzMzJnF1b3Q7IHZhbHVlIGRlZmlu ZWQ/Jm5ic3A7IE9idmlvdXNseSBhbiBSRkMgaXMgbm90IHRoZSBwbGFjZSB0bzxicj4NCiZndDsm Z3Q7Jmd0OyBkZWZpbmUgYW4gRXRoZXJuZXQgbXVsdGljYXN0IGFkZHJlc3MuPGJyPg0KJmd0OyZn dDs8YnI+DQomZ3Q7Jmd0Ozxicj4NCiZndDsmZ3Q7IDxhIGhyZWY9Imh0dHBzOi8vdG9vbHMuaWV0 Zi5vcmcvaHRtbC9yZmM1MzQyI3NlY3Rpb24tMi4zLjEiIHRhcmdldD0iX0JMQU5LIj5odHRwczov L3Rvb2xzLmlldGYub3JnL2h0bWwvcmZjNTM0MiNzZWN0aW9uLTIuMy4xPC9hPjxicj4NCiZndDsm Z3Q7PGJyPg0KJmd0OyZndDsgUGxlYXNlIG5vdGUgdGhhdCBpdCBoYXMgJ2xvY2FsOyBiaXQgc2V0 IHNvIHRoYXQgT1VJIHJhbmdlICgzMy0zMy1YWDxicj4NCiZndDsmZ3Q7IGRpZCBub3QgbmVlZCB0 byBiZSBwdXJjaGFzZWQpLjxicj4NCiZndDs8YnI+DQomZ3Q7PGJyPg0KJmd0OyBXaHkgaXNuJ3Qg dGhpcyBhZGRyZXNzIGxpc3RlZCBieSBJRUVFICZxdW90O0dST1VQIE1BQyBQVUJMSUMgTElTVElO RyZxdW90Oz88YnI+DQomZ3Q7IDxhIGhyZWY9Imh0dHBzOi8vc3RhbmRhcmRzLmllZWUub3JnL2Rl dmVsb3AvcmVnYXV0aC9ncnBtYWMvcHVibGljLmh0bWwiIHRhcmdldD0iX0JMQU5LIj4NCmh0dHBz Oi8vc3RhbmRhcmRzLmllZWUub3JnL2RldmVsb3AvcmVnYXV0aC9ncnBtYWMvcHVibGljLmh0bWw8 L2E+PGJyPg0KPGJyPg0KJmd0OyBXaHkgSUVFRSBsaXN0cyBfb3RoZXJfIGFkZHJlc3NlcyB0aGF0 IGNhbiBiZSB1c2VkIGZvciBzYW1lIHJvbGU6PGJyPg0KJmd0OyAwMS04MC1DMi0wMC0wMC0xRCBJ U08vSUVDIEpUQzEvU0M2IElTTy9JRUMgOTU0Mjxicj4NCiZndDsgJnF1b3Q7QWxsIE11bHRpY2Fz dCBDYXBhYmxlIEludGVybWVkaWF0ZSBTeXN0ZW1zIEFkZHJlc3MmcXVvdDs8YnI+DQo8YnI+DQpC ZWNhdXNlIHRoZSBPVUkgMzMtMzMtIGlzICpsb2NhbGx5IGFkbWluaXN0ZXJlZCogKGl0IGhhcyB0 aGUgTG9jYWwgYml0IHNldCkuPGJyPg0KSXQgaXMgbm90IGFsbG9jYXRlZCBieSBhbnkgcmVnaXN0 cnkuIFRoZSBsaW5rIHlvdSBhcmUgcmVmZXJyaW5nIHRvPGJyPg0KbGlzdHMgYWRkcmVzc2VzPGJy Pg0KZnJvbSB0aGUgVW5pdmVyc2FsbHkgQWRtaW5pc3RlcmVkIEFkZHJlc3MgQmxvY2suPGJyPg0K PGJyPg0KJmd0OyBSRkM1MzQyIHNheXM6PGJyPg0KJmd0OyZndDs8YnI+DQomZ3Q7Jmd0OyZuYnNw OyZuYnNwOyBBbGwgTUFDLTQ4IG11bHRpY2FzdCBpZGVudGlmaWVycyBwcmVmaXhlZCAmcXVvdDsz My0zMyZxdW90OyAodGhhdCBpcywgdGhlIDIqKjMyPGJyPg0KJmd0OyZndDsmbmJzcDsmbmJzcDsm bmJzcDsgbXVsdGljYXN0IE1BQyBpZGVudGlmaWVycyBpbiB0aGUgcmFuZ2UgZnJvbSAzMy0zMy0w MC0wMC0wMC0wMCB0bzxicj4NCiZndDsmZ3Q7Jm5ic3A7Jm5ic3A7Jm5ic3A7IDMzLTMzLUZGLUZG LUZGLUZGKSBhcmUgdXNlZCBieSB0aGUgSUVURiBmb3IgZ2xvYmFsIElQdjYgbXVsdGljYXN0PGJy Pg0KJmd0OyZndDsmbmJzcDsmbmJzcDsmbmJzcDsgW1JGQzI0NjRdLjxicj4NCiZndDs8YnI+DQom Z3Q7PGJyPg0KJmd0OyBXaGF0IGRvZXMgJnF1b3Q7Z2xvYmFsIElQdjYgbXVsdGljYXN0JnF1b3Q7 IG1lYW4/Jm5ic3A7IFRoZSB0ZXJtICZxdW90O2dsb2JhbCZxdW90OyBpcyBtaXNsZWFkaW5nPGJy Pg0KJmd0OyBiZWNhdXNlIG9mIHRoYXQgJ2xvY2FsJyBiaXQgc2V0IHlvdSBzYWlkIGFib3ZlLCBh bmQgYmVjYXVzZSBSRkMyNDY0IGlzPGJyPg0KJmd0OyBoYXBwZW5pbmcgb25seSBvbiBhIGxpbmsu Jm5ic3A7IE1heWJlIGl0IG1lYW50ICZxdW90O0lQdjYgbXVsdGljYXN0JnF1b3Q7Pzxicj4NCiZn dDs8YnI+DQomZ3Q7IFdoeSBkb2VzIGl0IHJlZmVyIHRvIFJGQzI0NjQ/Jm5ic3A7IFJGQzI0NjQg aXMgb25seSBmb3IgRXRoZXJuZXQsIG5vdCBmb3Igb3RoZXI8YnI+DQomZ3Q7IGtpbmRzIG9mIGxp bmtzLjxicj4NCiZndDs8YnI+DQomZ3Q7IEl0IHJlYWRzIGFzIGlmIGFsbCBJbnRlcm5ldC1jb25u ZWN0ZWQgbm9kZXMgd2VyZSBvbiBFdGhlcm5ldCBhbmQgYXMgaWYgYW55PGJyPg0KJmd0OyBJUCBt dWx0aWNhc3QgYWRkcmVzcyBjb3VsZCBiZSBtYXBwZWQgaW50byB0aGUgMzJiaXRzIGxlZnQgb2Yg YSBNQUMgbXVsdGljYXN0PGJyPg0KJmd0OyBhZGRyZXNzICh0aGV5IGNhbnQgLSB0aGV5IGFyZSAx MTJiaXQgbGVuZ3RoKS48YnI+DQo8YnI+DQpBRkFJUiZuYnNwOyBSRkMzMzA3IGhhcyBzb21lIHJl Y29tbWVuZGF0aW9ucyBvbiBob3cgdG8gbWluaW1pemUgdGhlIGNoYW5jZTxicj4NCm9mIGFkZHJl c3MgY29sbGlzaW9uLjxicj4NCjxicj4NCi0tIDxicj4NClNZLCBKZW4gTGlua292YSBha2EgRnVy cnk8YnI+DQo8YnI+DQotLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLTxicj4NCklFVEYgSVB2NiB3b3JraW5nIGdyb3VwIG1h aWxpbmcgbGlzdDxicj4NCmlwdjZAaWV0Zi5vcmc8YnI+DQpBZG1pbmlzdHJhdGl2ZSBSZXF1ZXN0 czogPGEgaHJlZj0iaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9pcHY2IiB0 YXJnZXQ9Il9CTEFOSyI+DQpodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL2lw djY8L2E+PGJyPg0KLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS08YnI+DQo8L2Rpdj4NCjwvc3Bhbj48L2ZvbnQ+PC9ibG9j a3F1b3RlPg0KPC9kaXY+DQo8L2JvZHk+DQo8L2h0bWw+DQo= --_000_2f437218b23a44238ccdcb4e7318da8dXCHRCD003ciscocom_-- From nobody Sun Jul 17 21:39:50 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 1D5A012B00D; Sun, 17 Jul 2016 21:39:46 -0700 (PDT) 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-07.txt X-Test-IDTracker: no X-IETF-IDTracker: 6.28.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20160718043946.30611.74497.idtracker@ietfa.amsl.com> Date: Sun, 17 Jul 2016 21:39:46 -0700 Archived-At: Cc: ipv6@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.17 List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 18 Jul 2016 04:39:46 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the IPv6 Maintenance 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-07.txt Pages : 11 Date : 2016-07-17 Abstract: 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. 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-07 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-6man-deprecate-atomfrag-generation-07 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 Jul 18 00:08:39 2016 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 03FA712D0F9 for ; Mon, 18 Jul 2016 00:08:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.111 X-Spam-Level: X-Spam-Status: No, score=-4.111 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, T_DKIM_INVALID=0.01] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=fail (1024-bit key) reason="fail (message has been altered)" header.d=jisc365.onmicrosoft.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 mjRty7O7uxTz for ; Mon, 18 Jul 2016 00:08:36 -0700 (PDT) Received: from eu-smtp-delivery-189.mimecast.com (eu-smtp-delivery-189.mimecast.com [146.101.78.189]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6F3C912B02D for <6man@ietf.org>; Mon, 18 Jul 2016 00:08:36 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=jisc365.onmicrosoft.com; s=selector1-jisc-ac-uk; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=V5WeJPSWeyZJ3pQcFy+Hu2x49kcH6O3Ji9BenOmZV+Q=; b=ZK3yf1c0FatL5UD/UiOy4+yPwY2h9meNo18kkSyFHTJ+XsK+YFfIheVwj7oDc/IQYQZdYlOICfGmQBbtvkFKjb/KlqZ1INoQsy9gaQxRGzlJonT6RZXu1fCCoLDPTOJV61n0qaNCPnJ3W7XquqigBykNwxuXFq8+fsGVo976r+M= Received: from EUR02-HE1-obe.outbound.protection.outlook.com (mail-he1eur02lp0184.outbound.protection.outlook.com [213.199.180.184]) (Using TLS) by eu-smtp-1.mimecast.com with ESMTP id uk-mta-67-JaihBM6ZO8u966kwFK5tgQ-1; Mon, 18 Jul 2016 08:08:30 +0100 Received: from AMSPR07MB455.eurprd07.prod.outlook.com (10.242.106.148) by AMSPR07MB455.eurprd07.prod.outlook.com (10.242.106.148) with Microsoft SMTP Server (TLS) id 15.1.539.14; Mon, 18 Jul 2016 07:08:28 +0000 Received: from AMSPR07MB455.eurprd07.prod.outlook.com ([10.242.106.148]) by AMSPR07MB455.eurprd07.prod.outlook.com ([10.242.106.148]) with mapi id 15.01.0539.019; Mon, 18 Jul 2016 07:08:28 +0000 From: Tim Chown To: "6man@ietf.org" <6man@ietf.org> Subject: Review of draft-ietf-6man-rfc2460bis-05 Thread-Topic: Review of draft-ietf-6man-rfc2460bis-05 Thread-Index: AQHR4MMvH0STN4+pj0+OuQzU+jg5Gw== Date: Mon, 18 Jul 2016 07:08:28 +0000 Message-ID: Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-mailer: Apple Mail (2.3124) x-ms-exchange-messagesentrepresentingtype: 1 x-originating-ip: [2001:67c:370:136:7440:a90d:15f3:c6a0] x-ms-office365-filtering-correlation-id: 8a837f1a-4f3a-4b29-9eec-08d3aeda51b3 x-microsoft-exchange-diagnostics: 1; AMSPR07MB455; 20:UD/PF2O7ckdSmNIYcjfPyGLAZOdXaSOGk0u75lLPb3C3nTnbxC18PR1ErpuoqmIOokSACfgwROkmOlp6rN/uYDHBC9nnbpVQa0Msbo9cLK2evlbHdzgWn7aWmP3bPLIwPTwiJPSHTLKxVWqb9HtKXghcZwg7zkjLXQs6KGOnHEk= x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:AMSPR07MB455; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(192374486261705); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(601004)(2401047)(8121501046)(5005006)(10201501046)(3002001); SRVR:AMSPR07MB455; BCL:0; PCL:0; RULEID:; SRVR:AMSPR07MB455; x-forefront-prvs: 00073DB75F x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(6009001)(7916002)(57704003)(199003)(189002)(87936001)(57306001)(36756003)(122556002)(82746002)(5640700001)(77096005)(83716003)(2900100001)(305945005)(97736004)(110136002)(189998001)(4326007)(3660700001)(6116002)(102836003)(586003)(86362001)(230783001)(2906002)(74482002)(33656002)(3280700002)(11100500001)(101416001)(50986999)(10400500002)(8936002)(50226002)(7736002)(7846002)(81166006)(81156014)(68736007)(2501003)(106356001)(8676002)(2351001)(92566002)(229853001)(106116001)(5002640100001)(105586002)(3826002)(104396002); DIR:OUT; SFP:1101; SCL:1; SRVR:AMSPR07MB455; H:AMSPR07MB455.eurprd07.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; A:1; MX:1; LANG:en; spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-ID: <20C4F5FBE49A3D4B9D026541CE88EB25@eurprd07.prod.outlook.com> MIME-Version: 1.0 X-OriginatorOrg: jisc.ac.uk X-MS-Exchange-CrossTenant-originalarrivaltime: 18 Jul 2016 07:08:28.5380 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 48f9394d-8a14-4d27-82a6-f35f12361205 X-MS-Exchange-Transport-CrossTenantHeadersStamped: AMSPR07MB455 X-MC-Unique: JaihBM6ZO8u966kwFK5tgQ-1 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: base64 Archived-At: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.17 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 Jul 2016 07:08:39 -0000 SGksDQoNCk9sZSBhc2tlZCBtZSB0byByZXZpZXcgZHJhZnQtaWV0Zi02bWFuLXJmYzI0NjBiaXMt MDUuDQoNCkdlbmVyYWxseSwgdGhlIGRvY3VtZW50IGxvb2tzIHRvIGJlIGluIGdvb2Qgc2hhcGUu IFBlcnNvbmFsbHksIEkgYWdyZWUgd2l0aCB0aGUgY2hhbmdlcyBtYWRlLiBJdCBsb29rcyBjbG9z ZSB0byBiZWluZyByZWFkeSBmb3IgdGhlIGZvdXIgd2VlayBJRVRGIExhc3QgQ2FsbCwgYXMgcGVy IFJGQzY0MTAuICBUaGUgZm91ciBrZXkgY3JpdGVyaWEgZm9yIHByb21vdGlvbiB0byBJUyBhcyBs aXN0ZWQgaW4gUkZDNjQxMCBzZWVtIHRvIGhhdmUgYmVlbiBtZXQgKHdpZGVzcHJlYWQgZGVwbG95 bWVudCB3aXRoIHN1Y2Nlc3NmdWwgb3BlcmF0aW9uYWwgZXhwZXJpZW5jZSwgZXJyYXRhIGFkZHJl c3NlZCwgbm8gdW51c2VkIGZlYXR1cmVzIHRoYXQgd291bGQgZ3JlYXRseSBpbmNyZWFzZSBpbXBs ZW1lbnRhdGlvbiBjb21wbGV4aXR5LCBhbmQgbm90IElQUiBlbmN1bWJlcmVkKS4NCg0KV2hlcmUg Y2hhbmdlcyB0byBSRkMyNDYwIGhhdmUgYmVlbiBtYWRlIHdpdGggcmVzcGVjdCB0byBSRkNzIHB1 Ymxpc2hlZCBzaW5jZSB0aGUgb3JpZ2luYWwgcHVibGljYXRpb24gb2YgUkZDMjQ2MCwgdGhlcmUg aXMgc29tZSBpbmNvbnNpc3RlbmN5IGFzIHRvIHdoZXRoZXIgdGhvc2UgUkZDcyBhcmUgZXhwbGlj aXRseSBjaXRlZCwgb3IgdGhlaXIg4oCYbWVzc2FnZeKAmSBqdXN0IGluY29ycG9yYXRlZCBhcyBh biB1cGRhdGUuICBTb21lIGNvbnNpc3RlbmN5IHdvdWxkIGJlIGRlc2lyYWJsZTsgc3BlY2lmaWMg b2NjdXJyZW5jZXMgYXJlIGxpc3RlZCBiZWxvdy4NCg0KVGhlIGNvbW1lbnRzIGJlbG93IGFyZSBs YXJnZWx5IGNsYXJpZmljYXRpb24gaW4gbmF0dXJlLiANCg0KQ29tbWVudHM6DQoNClNlY3Rpb24g MToNCg0KcC4zIG9uIHRoZSBzY29wZSBmaWVsZCBmb3IgbXVsdGljYXN0IGFkZHJlc3NlcyB0aGVy ZSBjb3VsZCBub3cgYmUgYSByZWZlcmVuY2UgdG8gUkZDNzM0Ni4NCg0KcC4zIHRoZSBFSCB0ZXh0 IHNob3VsZCBwcm9iYWJseSBubyBsb25nZXIgbWVudGlvbiDigJxncmVhdGVyIGZsZXhpYmlsaXR5 IGZvciBpbnRyb2R1Y2luZyBuZXcgb3B0aW9ucyBpbiB0aGUgZnV0dXJl4oCdLiBJbiAxOTk4IHll cywgYnV0IG5vdCBub3csIHdpdGggdGhlIGJlbmVmaXQgb2YgaGluZHNpZ2h0LiBMYXRlciBzZWN0 aW9ucyBkaXNjdXNzIHRoaXMgaW4gbW9yZSBkZXRhaWwuDQoNCnAuMyBpbiB0aGUgZmxvdyBsYWJl bCB0ZXh0LCBkZWxldGUg4oCYZm9y4oCZLg0KDQpTZWN0aW9uIDM6DQoNCnAuNiB0aGUgRGVzdGlu YXRpb24gQWRkcmVzcyBkZXN0aW5hdGlvbiB0YWxrcyBvZiB0aGUgUm91dGluZyBIZWFkZXIsIGJ1 dCB0aGlzIGhhcyBub3cgYmVlbiByZW1vdmVkIGZyb20gdGhlIGxpc3Qgb2YgRUhzIHJlcXVpcmVk IGZvciBhIOKAmGZ1bGwgaW1wbGVtZW50YXRpb27igJkgRUhzIG9uIHAuOC4gKHNlZSBtb3JlIG9u IHRoaXMgYmVsb3cpLg0KDQpTZWN0aW9uIDQ6DQoNCnAuNiB0aGVyZSBpcyBub3cgbW9yZSB0aGFu IGEg4oCcc21hbGwgbnVtYmVy4oCdIG9mIEVIcyBkZWZpbmVkLiBUaGlzIGRvY3VtZW50IG9ubHkg ZGVmaW5lcyAvIGRpc2N1c3NlcyBhIHNtYWxsIG51bWJlciBleHBsaWNpdGx5LCBidXQgYSBmdWxs ZXIgbGlzdCBpcyBpbmNsdWRlZCBpbiBSRkM3MDQ1LiBJIHRoaW5rIGl04oCZcyBmaW5lIHRoYXQg d2Ugc2hvdWxkIGtlZXAgMjQ2MCBqdXN0IHJlZmVycmluZyB0byB0aGUg4oCYY29yZeKAmSBoZWFk ZXJzICh0aGUgb25lcyByZXF1aXJlZCBmb3IgYSAnZnVsbCBpbXBsZW1lbnRhdGlvbuKAmSBvbiBw LjgpLCBidXQgdGhlcmUgbWF5IGJlIGFuIGFyZ3VtZW50IHRvIHJlZmVyIHRvIFJGQzcwNDUgYXMg YSBwb2ludGVyIHRvIHRoZSBuZXcg4oCcSVB2NiBFeHRlbnNpb24gSGVhZGVyIFR5cGVz4oCdIGxp c3QgbWFpbnRhaW5lZCBieSBJQU5BLiBPciBtYXliZSB0aGF0IHBvaW50ZXIgc2hvdWxkIGJlIGlu IFNlY3Rpb24gOT8NCg0KcC43IGRvIHdlIG5lZWQgdG8gYmUgY2xlYXJlciBpbiB0aGUgbWVhbmlu ZyBvZiDigJxwcm9jZXNzZWTigJ0gaGVyZT8gSXMg4oCcZXhhbWluaW5n4oCdIGEgZm9ybSBvZiDi gJxwcm9jZXNzaW5n4oCdLiAgSXQgbWlnaHQgcmVhZCBiZXR0ZXIgaWYgdGhlIFJGQzcwNDUgTm90 ZSB3YXMgcGxhY2VkIGFmdGVyIHRoZSBwYXJhZ3JhcGggb24gcC44IHRoYXQgc3RhdGVzIHRoZSBI b2J5LWJ5LUhvcCBleGNlcHRpb24uIA0KDQpwLjcgbm90ZSB0aGF0IGZpcmV3YWxscyB3b3VsZCBi ZSBhbiBleGFtcGxlIG9mIG5vZGVzIHRoYXQgbWlnaHQgcHJvY2VzcyBFSHMgYmV5b25kIHRoZSBI YkggaGVhZGVyLiBEbyB3ZSBuZWVkIHRvIGJlIGNsZWFyIHRoYXQgMjQ2MCB0YWxrcyBvZiBub3Jt YWwgcHJvY2Vzc2luZywgbm90IHByb2Nlc3NpbmcgZm9yIHNlY3VyaXR5IHJlYXNvbnMgKGZpcmV3 YWxsLCBJRFMsIOKApik/DQoNCnAuOCBpbiB0aGUg4oCcSWYsIGFzIGEgcmVzdWx04oCm4oCdIHBh cmFncmFwaCwgaXMgdGhlIHRleHQgbm93IGNvbnRyYWRpY3RvcnkgdG8gUkZDNzA0NSwgd2hpY2gg c2F5cyAiSWYgYSBmb3J3YXJkaW5nIG5vZGUgZGlzY2FyZHMgYSBwYWNrZXQgY29udGFpbmluZyBh IHN0YW5kYXJkIElQdjYgZXh0ZW5zaW9uIGhlYWRlciwgaXQgTVVTVCBiZSB0aGUgcmVzdWx0IG9m IGEgY29uZmlndXJhYmxlIHBvbGljeSBhbmQgbm90IGp1c3QgdGhlIHJlc3VsdCBvZiBhIGZhaWx1 cmUgdG8gcmVjb2duaXNlIHN1Y2ggYSBoZWFkZXIu4oCdPyBUaGUgMjQ2MC1iaXMgdGV4dCBpbXBs aWVzIGEgZGlzY2FyZCwgd2hpbGUgNzA0NSBpbXBsaWVzIHRoYXQgc2hvdWxkbuKAmXQgaGFwcGVu IHVubGVzcyBhcyBhIHJlc3VsdCBvZiBjb25maWd1cmVkIHBvbGljeT8NCg0KcC44IHNob3VsZCB3 ZSBiZSByZW1vdmluZyB0aGUgUm91dGluZyBoZWFkZXIgZnJvbSB0aGUgbGlzdCBoZXJlPyBZZXMs IFJIMCBpcyBkZXByZWNhdGVkLCBidXQgSSB1bmRlcnN0YW5kIHRoYXQgU1BSSU5HIGlzIHVzaW5n IHRoZSBSSCwgYW5kIHRoZXJlIGFyZSBhbHNvIHRoZSBUeXBlIDIgYW5kIFR5cGUgMyBSSHMgZGVm aW5lZCBpbiBSRkM2Mjc1IChNb2JpbGl0eSB1c2UpIGFuZCBSRkMgNjU1NCAoUlBMIHVzZSkuDQoN CnAuOSB0aGUgdGV4dCBzYXlpbmcg4oCcaW4gYW55IG9yZGVy4oCdIG1pZ2h0IGJlIGxlc3MgYW1i aWd1b3VzIGlmIHN0YXRlZCBhcyDigJxhcHBlYXJpbmcgaW4gYW55IG9yZGVy4oCdIChpLmUuIGVt cGhhc2lzZSB0aGUgRUhzIGFyZSBwcm9jZXNzZWQgc2VxdWVudGlhbGx5LCBubyBtYXR0ZXIgd2hh dCBvcmRlciB0aGV5IGFyZSBpbiwgcmF0aGVyIHRoYW4gdGhlIG5vZGUgcHJvY2Vzc2luZyB0aGUg RUhzIGluIGFueSBvcmRlcikuDQoNCnAuMTQgaW4gdGhlIOKAnElmLCBhZnRlciBwcm9jZXNzaW5n 4oCm4oCdIHBhcmFncmFwaCwgaXNu4oCZdCB0aGlzIHRydWUgcmVnYXJkbGVzcyBvZiBhbHRlcmF0 aW9ucyB0byB0aGUgUkg/ICBJcyB0aGlzIHN1cGVyZmx1b3VzPw0KDQpwLjE1IHRoZSAoKikgbm90 ZSBmb3Ig4oCccmVjZW50bHnigJ0gbG9va3MgYSBiaXQgdWdseS4gSnVzdCBtYWtlIGl0IG5vcm1h bCB0ZXh0Pw0KDQpwLjE2IEEgbm90ZSBhYm91dCBSRkM3MTEyIHdvdWxkIGJlIGJlc3QgcGxhY2Vk IGFmdGVyIHRoZSDigJxUaGUgRnJhZ21lbnRhYmxlIFBhcnTigJ0gcGFyYWdyYXBoLiBBcyBpdCBz dGFuZHMsIHRoZSBSRkM3MTEyIHByaW5jaXBsZSAoYWxsIEVIcyBpbiB0aGUgZmlyc3QgZnJhZykg aXNu4oCZdCBtZW50aW9uZWQgdW50aWwgZnVydGhlciBpbnRvIHRoZSBkb2N1bWVudCwgb24gcC4x NyBpdGVtICgzKSwgYW5kIGV2ZW4gdGhlbiA3MTEyIGlzbuKAmXQgY2l0ZWQuICBBIG5vdGUgYWJv dXQgbm90IGNyZWF0aW5nIG92ZXJsYXBwaW5nIGZyYWdtZW50cyBjb3VsZCBhbHNvIGJlIGluc2Vy dGVkIGhlcmUsIGFzIHBlciBSRkM1NzIyLg0KDQpwLjE2IHNob3VsZCB3ZSBtZW50aW9uIGhlcmUg dGhhdCBORCBtZXNzYWdlcyBzaG91bGQgbm90IGJlIGZyYWdtZW50ZWQsIGFzIHBlciBSRkM2OTgw LCBzZWN0aW9uIDY/DQoNCnAuMTcgdGhpcyBkaWFncmFtIGVtcGhhc2lzZXMgdGhlIG1vZGVsIHRo YXQgUkZDNzExMiByZXF1aXJlcywgd2l0aCB0aGUgRUhzIGluIHRoZSBmaXJzdCBmcmFnLiAgTWF5 YmUgbm90ZSB0aGF0IGluIHRoZSB0ZXh0Lg0KDQpwLjE4IHRoZSDigJxGcmFnbWVudHMgbXVzdCBu b3QgYmUgY3JlYXRlZOKApuKAnSBsaW5lIGlzIGEgZHVwbGljYXRpb24gb2YgdGhlIGxhc3QgcGFy YWdyYXBoIG9uIHAuMTkuICBNb3ZlIHRoYXQgbGFyZ2VyIHBhcmEgZm9yd2FyZD8gICBBbHNvIHBl cmhhcHMgbm90ZSB0aGUgcmVxdWlyZW1lbnQgdG8gc2xpbmt5IGRpc2NhcmQsIGFzIHBlciBSRkM1 NzIyPw0KDQpwLjIwIHBhcmFncmFwaCAyIHNob3VsZCByZWZlciB0byBSRkM2OTQ2IG9uIGhhbmRs aW5nIG9mIGF0b21pYyBmcmFnbWVudHM/DQoNCnAuMjAgSSBzdWdnZXN0IG51bWJlcmluZyB0aGUg Zm91ciBsaXN0ZWQgZXJyb3IgY29uZGl0aW9ucywgZm9yIGNsYXJpdHkuDQoNCnAuMjAgaXMgdGhl IDYwIHNlY29uZCBydWxlIGNvbW1vbmx5IGltcGxlbWVudGVkPyBUaGlzIHNlZW1zIGEgdmVyeSBo aWdoIHZhbHVlLCBhbmQgY291bGQgY29udHJpYnV0ZSB0byBEb1MgZWZmZWN0aXZlbmVzcz8NCg0K cC4yMCB0aGUgZm91cnRoIGNvbmRpdGlvbiBjb3VsZCBjaXRlIFJGQzcxMTINCg0KcC4yMCBhZGQg YSBmaWZ0aCBlcnJvciBjb25kaXRpb24gb2Ygb3ZlcmxhcHBpbmcgZnJhZ21lbnRzLCBhcyBwZXIg UkZDNTcyMj8NCg0KcC4yMSBwYXJhIDIsIGlzIGl0IGNvbW1vbiB0aGF0IHN1Y2ggaGVhZGVycyBt YXkgZGlmZmVyPyAgVGhlIGltcGxpY2F0aW9uIG9mIHAuMTcgcG9pbnQgKDEpIGlzIHRoYXQgdGhl eeKAmWQgYmUgdGhlIHNhbWU/DQoNCnAuMjIgaXMgTmV4dCBIZWFkZXIgdmFsdWUgNTkgdXNlZCBp biBwcmFjdGljZT8gKEp1c3QgY3VyaW91c+KApiBpdCB3YXMgb21pdHRlZCBmcm9tIFJGQzcwNDUp Lg0KDQpwLjIyIGluIHNlY3Rpb24gNC44LCBjaXRlIFJGQzY1NjQsIHdoaWNoIGFwcGVhcnMgdG8g YmUgdGhlIGZvcm1hdCB1c2VkIGluIHRoZSBsYXR0ZXIgcGFydCBvZiB0aGF0IHNlY3Rpb24uDQoN CnAuMjMg4oCcRGVmaW5pbmcgbmV34oCm4oCdIHNlbnRlbmNlIGR1cGxpY2F0ZXMgdGhlIHN0YXJ0 IG9mIHRoZSBwYXJhZ3JhcGg/DQoNClNlY3Rpb24gNToNCg0KcC4yNCBEbyB3ZSBhZGQgYSBub3Rl IGhlcmUgYWJvdXQgUExQTVRVRCwgb3IganVzdCBsZWF2ZSB0aGF0IHRvIFJGQzE5ODEtYmlzPyBJ IHdvdWxkIHByb2JhYmx5IHNheSB0aGUgbGF0dGVyLg0KDQpwLjI0IGhvdyBzdHJvbmcgaXMg4oCc ZGlzY291cmFnZWTigJ0/ICBJIHJlbWVtYmVyIHdlbGwgZHJhZnQtYm9uaWNhLTZtYW4tZnJhZy1k ZXByZWNhdGUtMDIgOykNCg0KU2VjdGlvbiA4Og0KDQpwLjI2IGFkZCBhIHJlZmVyZW5jZSB0byBS RkM2OTM1IHdpdGggcmVzcGVjdCB0byB0dW5uZWxzIGFuZCBVRFAgY2hlY2tzdW1zPw0KDQpwLjI2 IGlzIHRoZSB0ZXh0IGluIDguMiBjb25zaXN0ZW50IHdpdGggdGhlIHRleHQgb24gcGFnZSA2IGFi b3V0IHRoZSBIb3AgTGltaXQ/IA0KDQpwLjI3IGlzIHRoZSB0ZXh0IGluIDguNCBjb25zaXN0ZW50 IHdpdGggVHlwZSAyIGFuZCBUeXBlIDMgUkggdXNlPyAoSSBkb27igJl0IGZvbGxvdyBSUEwgaW4g ZW5vdWdoIGRldGFpbC4uLikNCg0KDQpCZXN0IHdpc2hlcywNClRpbSANCg0KDQoNCg== From nobody Mon Jul 18 04:00:59 2016 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E9BBD12D854 for ; Mon, 18 Jul 2016 04:00:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.111 X-Spam-Level: X-Spam-Status: No, score=-4.111 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, T_DKIM_INVALID=0.01] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=fail (1024-bit key) reason="fail (message has been altered)" header.d=jisc365.onmicrosoft.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 GodvgmUuiqik for ; Mon, 18 Jul 2016 04:00:54 -0700 (PDT) Received: from eu-smtp-delivery-189.mimecast.com (eu-smtp-delivery-189.mimecast.com [146.101.78.189]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BADC712D88D for <6man@ietf.org>; Mon, 18 Jul 2016 04:00:45 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=jisc365.onmicrosoft.com; s=selector1-jisc-ac-uk; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=sLIqByaYqeOxFbXI0OJMfbMPlCYH/FHmpDaQVKgjpHA=; b=BgJ+uD2aGzQowEw6xxivQoC3kY6e8+APzGyhqg59PoqxvT+Ast4QO/nFP9k9mEmvzMj7ZqKxqcyticLJneJeWM2fAQRtX3WDsFR6KQ6RCJR80Fn8aPa6xmz36Tg0mtXXkTutKyte1PBvHVsBV9W38t1QzD8Jr7rtcjdAyCz7Xho= Received: from EUR01-HE1-obe.outbound.protection.outlook.com (mail-he1eur01lp0215.outbound.protection.outlook.com [213.199.154.215]) (Using TLS) by eu-smtp-1.mimecast.com with ESMTP id uk-mta-13-ptn2HOdXOIe4uoCgBRcT_A-1; Mon, 18 Jul 2016 12:00:38 +0100 Received: from AMSPR07MB455.eurprd07.prod.outlook.com (10.242.106.148) by AMSPR07MB456.eurprd07.prod.outlook.com (10.242.106.149) with Microsoft SMTP Server (TLS) id 15.1.534.14; Mon, 18 Jul 2016 11:00:36 +0000 Received: from AMSPR07MB455.eurprd07.prod.outlook.com ([10.242.106.148]) by AMSPR07MB455.eurprd07.prod.outlook.com ([10.242.106.148]) with mapi id 15.01.0539.019; Mon, 18 Jul 2016 11:00:36 +0000 From: Tim Chown To: "6man@ietf.org" <6man@ietf.org> Subject: Review of draft-ietf-6man-rfc1981bis-02 Thread-Topic: Review of draft-ietf-6man-rfc1981bis-02 Thread-Index: AQHR4OOcHTdtd97/T0uoAf+Lc9/n0Q== Date: Mon, 18 Jul 2016 11:00:36 +0000 Message-ID: <89394068-B340-4B04-BA26-A3876E53F66C@jisc.ac.uk> Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-mailer: Apple Mail (2.3124) x-ms-exchange-messagesentrepresentingtype: 1 x-originating-ip: [2001:67c:370:152:91c8:1613:ed42:694] x-ms-office365-filtering-correlation-id: b09ee07c-04df-4130-0af4-08d3aefabf3a x-microsoft-exchange-diagnostics: 1; AMSPR07MB456; 20:BnGb1nsQ4gr5PpYdEIaA0SIRN8mrue2F9BO3A0oDZnRg0gtOic6u1jz/Hqa9OS1lAzsSXIPCfddEhM78xHUEMu3sBWZWlTWYCryUjl6R0dje6QQAeAoHrftDc+UPaUZzRYvW6YgvZm+71j942c+VIgdzbZxAxY21MpFEuv5aatI= x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:AMSPR07MB456; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(192374486261705); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(601004)(2401047)(5005006)(8121501046)(10201501046)(3002001); SRVR:AMSPR07MB456; BCL:0; PCL:0; RULEID:; SRVR:AMSPR07MB456; x-forefront-prvs: 00073DB75F x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(6009001)(7916002)(189002)(199003)(586003)(305945005)(81166006)(2501003)(10400500002)(92566002)(57306001)(2906002)(8676002)(105586002)(106356001)(82746002)(2351001)(106116001)(101416001)(229853001)(3660700001)(81156014)(77096005)(4326007)(3280700002)(7846002)(50226002)(102836003)(7736002)(2900100001)(74482002)(6116002)(8936002)(11100500001)(122556002)(33656002)(189998001)(50986999)(86362001)(230783001)(83716003)(87936001)(110136002)(68736007)(5002640100001)(36756003)(5640700001)(97736004)(3826002)(104396002); DIR:OUT; SFP:1101; SCL:1; SRVR:AMSPR07MB456; H:AMSPR07MB455.eurprd07.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; MX:1; A:1; LANG:en; spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-ID: MIME-Version: 1.0 X-OriginatorOrg: jisc.ac.uk X-MS-Exchange-CrossTenant-originalarrivaltime: 18 Jul 2016 11:00:36.0749 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 48f9394d-8a14-4d27-82a6-f35f12361205 X-MS-Exchange-Transport-CrossTenantHeadersStamped: AMSPR07MB456 X-MC-Unique: ptn2HOdXOIe4uoCgBRcT_A-1 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: base64 Archived-At: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.17 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 Jul 2016 11:00:58 -0000 SGksDQoNCk9sZSBhc2tlZCBmb3IgYSByZXZpZXcgb2YgZHJhZnQtaWV0Zi02bWFuLXJmYzE5ODFi aXMtMDIuDQoNCk92ZXJhbGwsIHRoZSBkb2N1bWVudCBsb29rcyBjbG9zZSB0byBiZWluZyByZWFk eS4gQnV0IGFuIGltcG9ydGFudCBvcGVuIHF1ZXN0aW9uIGlzIHdoZXRoZXIgUE1UVUQgbWVldHMg YWxsIHRoZSBjcml0ZXJpYSBmb3IgcHJvbW90aW9uIHRvIElTLCBhcyBwZXIgUkZDNjQxMCwgaS5l LiB0aGF0IGl0IGhhcyAiYSBoaWdoIGRlZ3JlZSBvZiB0ZWNobmljYWwgbWF0dXJpdHkgYW5kIGJ5 IGEgZ2VuZXJhbGx5IGhlbGQgYmVsaWVmIHRoYXQgdGhlIHNwZWNpZmllZCBwcm90b2NvbCBvciBz ZXJ2aWNlIHByb3ZpZGVzIHNpZ25pZmljYW50IGJlbmVmaXQgdG8gdGhlIEludGVybmV0IGNvbW11 bml0eeKAnSBhbmQgaXQgaGFzICJ3aWRlc3ByZWFkIGRlcGxveW1lbnQgYW5kIHN1Y2Nlc3NmdWwg b3BlcmF0aW9uYWwgZXhwZXJpZW5jZeKAnS4gVGhlIHF1ZXN0aW9uIGlzIG9uIHRoZSB3b3JkIOKA nHN1Y2Nlc3NmdWzigJ0sIGdpdmVuIHRoZSByb2J1c3RuZXNzIGlzc3VlcyBvZiBQVEIgbWVzc2Fn ZSB0cmFuc21pc3Npb24gYW5kIHJlY2VpcHQuIA0KDQpSZWxhdGVkLCBvbmUgZ2VuZXJhbCBjb21t ZW50IGlzIHRoZSBsZXZlbCB0byB3aGljaCBQTFBNVFVEIChSRkM0ODIxKSBpcyDigJhwdXNoZWTi gJkgaW4gdGhpcyBkb2N1bWVudC4gSXQgaXMgbWVudGlvbmVkIGluIFNlY3Rpb24gMSwgYnV0IHRo ZW4gbm90IGVsc2V3aGVyZSBpbiB0aGUgZG9jdW1lbnQsIHdoZXJlIFBhY2tldGl6YXRpb24gTGF5 ZXIgUE1UVUQgaXNzdWVzIGFyZSBkaXNjdXNzZWQgaW4gYSBmZXcgcGxhY2VzLCBlLmcuIFNlY3Rp b24gNS4xIHBhcmFncmFwaCAyIHdoaWNoIHNlZW1zIHRvIHN1Z2dlc3Qgbm90IHVzaW5nIHRoZSA0 ODIxIGFwcHJvYWNoLiAgU29tZSBjb25zaXN0ZW5jeSBtaWdodCBiZSBkZXNpcmFibGUgaGVyZT8N Cg0KVGhlcmUgaXMgYSBsYXJnZSAiSW1wbGVtZW50YXRpb24gSXNzdWVzIiBzZWN0aW9uIChTZWN0 aW9uIDUpLCBmcm9tIHRoZSBub2Rl4oCZcyBwZXJzcGVjdGl2ZSwgYnV0IG5vdCBtdWNoIHRoYXQg SSBjYW4gc2VlIG9uIGhhbmRsaW5nIG9mIFBNVFVELXJlbGF0ZWQgbWVzc2FnZXMgKFBUQikgYnkg bm9kZXMgb24gYSBwYXRoIGZyb20gdGhlIHJlcG9ydGVyIHRvIHRoZSBvcmlnaW5hbCBwYWNrZXQg c2VuZGVyLiBUaGVyZeKAmXMgYSBsaXR0bGUgb24gdGhpcyBpbiB0aGUgU2VjdXJpdHkgQ29uc2lk ZXJhdGlvbnMuIElzIHRoZXJlLCBmb3IgZXhhbXBsZSwgdmFsdWUgaW4gYWRkaW5nIGEgcmVmZXJl bmNlIHRvIFJGQzQ4OTAgc29tZXdoZXJlLCBhbmQgdGhhdCBmYWlsdXJlIG9mIHNpdGVzIHRvIGFk aGVyZSB0byA0ODkwIGlzIGEgcmVhc29uIGZvciB1c2luZyB0aGUgNDgyMSBhcHByb2FjaD8NCg0K T3RoZXIgY29tbWVudHM6DQoNClNlY3Rpb24gMToNCg0KcC4zIGRvZXMgdGhlIG1pbmltYWwgaW1w bGVtZW50YXRpb24gdGV4dCBiZWxvbmcgaGVyZSwgb3IgaW4gdGhlIElQdjYgTm9kZSBSZXF1aXJl bWVudHMgZG9jdW1lbnQgKHdoaWNoIGlzIGFsc28gdW5kZXIgcmV2aXNpb24pPw0KDQpwLjMgYWZ0 ZXIgdGhlIOKAnE5vZGVzIG5vdCBpbXBsZW1lbnRpbmfigKbigJ0gcGFyYWdyYXBoLCBpcyBpdCB3 b3J0aCBub3RpbmcgdGhhdCB1c2Ugb2YgMTI4MCBNVFUgZ2l2ZXMgc29tZSBsZXZlbCBvZiByb2J1 c3RuZXNzL3ByZWRpY3RhYmlsaXR5IGF0IHRoZSBleHBlbnNlIG9mIHJlZHVjZWQgcGVyZm9ybWFu Y2U/IEEgMTI4MCBNVFUgaXMgYmVpbmcgdXNlZCBpbiBwcmFjdGljZSBpbiBhIG51bWJlciBvZiBz Y2VuYXJpb3MvZGVwbG95bWVudHMuIEFuZCBpbiAyNDYwLWJpcyB3ZSBoYXZlIHRleHQgdGhhdCBk aXNjb3VyYWdlcyBmcmFnbWVudGF0aW9uIGFuZCBwcmVmZXJzIHRyYW5zbWlzc2lvbiBvZiAxMjgw IE1UVSBub24tZnJhZ21lbnRlZCBwYWNrZXRzIChzZWN0aW9uIDUsIHBlbnVsdGltYXRlIHBhcmFn cmFwaCkuIA0KDQpwLjMgdGhlIG5vdGUgaGVyZSBvbiBQTFBNVFVEIChSRkM0ODIxKSBpcyBhcHBy b3ByaWF0ZSwgYnV0IGFzIHN0YXRlZCBhYm92ZSwgaXMgdGhpcyBzZW50aW1lbnQgY2FycmllZCBj b25zaXN0ZW50bHkgdGhyb3VnaCB0aGUgcmVzdCBvZiB0aGUgZG9jdW1lbnQ/ICBBcyBpdCBzdGFu ZHMsIGl0IHNlZW1zIHRoaXMgbm90ZSB3YXMgcGFyYWNodXRlZCBpbiBoZXJlLCB3aXRob3V0IG90 aGVyIHBhcnRzIG9mIDE5ODFiaXMgYmVpbmcgdXBkYXRlZCB0byByZWZsZWN0IHRoZSBhZGRpdGlv bi4NCg0KcC4zIGZ1cnRoZXIsIGlzIHVzZSBvZiBvbmUsIGVpdGhlciwgb3IgYm90aCBhcHByb2Fj aGVzIHJlY29tbWVuZGVkLCBnaXZlbiB0aGUgdmFndWVuZXNzIG9mIHRoZSB0ZXh0IGFib3V0IOKA nGRlbGl2ZXJ5IG9mIElDTVAgbWVzc2FnZXMgbm90IGJlaW5nIGFzc3VyZWTigJ0gKGZvciBzb21l IHZhbHVlIG9mIOKAnGFzc3VyZWTigJ0pPyAgZS5nLiBSRkM0ODIxIHNheXMgaXQgcmVsYXhlcyB0 aGUgcmVxdWlyZW1lbnRzIG9mIFJGQzE5ODEgYW5kIOKAnHJlc29sdmVzIHJvYnVzdG5lc3MgcHJv YmxlbXPigJ0sIGJ1dCB0aGUgdGV4dCBoZXJlIGRvZXNu4oCZdCBnbyBmdXJ0aGVyLiAgRG9lcyBp dCBuZWVkIHRvPw0KDQpTZWN0aW9uIDQ6DQoNCnAuNiBkbyB3ZSBoYXZlIGNvbmZpZGVuY2UgdGhh dCB0aGUgNSBtaW51dGUg4oCYTVVTVOKAmSBoZXJlIGlzIG9ic2VydmVkIGluIGNvbW1vbiBpbXBs ZW1lbnRhdGlvbnM/ICAoSSBkb27igJl0IGtub3csIGJ1dCBpZiBtb3ZpbmcgdG8gSVMgd2Ugc2hv dWxkIGNoZWNrIG9uIGV4aXN0aW5nIHByYWN0aWNlPykNCg0KU2VjdGlvbiA1Og0KDQpwLjcgU2Vj b25kIHBhcmEgaW4gNS4xLCBhcyBhYm92ZSwgdGhlIHRleHQgaXNu4oCZdCB3aG9sbHkgaW4gc3lu YyB3aXRoIGFkdmljZSBvbiB1c2Ugb2YgUkZDNDgyMT8NCg0KcC43IGxhc3QgcGFyYSBvZiA1LjEs IGluIDI0NjAtYmlzIHdlIHNheSB1bm5lY2Vzc2FyeSBmcmFnbWVudGF0aW9uIGlzIOKAnGRpc2Nv dXJhZ2Vk4oCdLiAgQSByZWZlcmVuY2UgdG8gW0ZSQUddIGlzIHVzZWQsIGJ1dCBpcyBkYXRlZDsg dGhlcmUgd2FzIGFsc28gZHJhZnQtYm9uaWNhLTZtYW4tZnJhZy1kZXByZWNhdGUtMDIsIHdoaWNo IGV4cHJlc3NlcyBzZW50aW1lbnQgYnV0IHdhcyBjb25zaWRlcmVkIHRvbyDigJxkcmFzdGljIiB0 byBiZSBhZG9wdGVkIGJ5IDZtYW4uDQoNCnAuOCBpZiBORCBpcyBtZW50aW9uZWQgaGVyZSwgc2hv dWxkIHdlIGNpdGUgUkZDNjk4MCBvbiBub3QgZnJhZ21lbnRpbmcgTkQgbWVzc2FnZXM/DQoNCnAu OCB0aGVyZeKAmXMgbWVudGlvbiBoZXJlIG9mIFJIMCwgd2hpY2ggb2YgY291cnNlIGlzIGRlcHJl Y2F0ZWQ7IHRoZXJlIGFyZSBvdGhlciB2YWxpZCBSSCB0eXBlcyB0aG91Z2gsIGJ1dCB0aGlzIHRl eHQgbmVlZHMgdXBkYXRpbmcgdG8gcmVtb3ZlIHJlZmVyZW5jZSB0byBSSDAuIEl0IG1pZ2h0IGFs c28gYmUgd29ydGggYWRkaW5nIGEgcG9pbnRlciBoZXJlIHRvIHRoZSB0ZXh0IGluIDI0NjAtYmlz IGFib3V0IG5vdCBieSBkZWZhdWx0IHVzaW5nIHRoZSByZXZlcnNlIHBhdGggZnJvbSBhbnkgUkgg dG8gc2VuZCBhbiBJQ01QIG1lc3NhZ2UgYmFjayB0byB0aGUgc2VuZGVyIChzZWN0aW9uIDguNCBv ZiAyNDYwLWJpcyk/ICANCg0KcC4xMCBJbiA1LjQsIFRDUCBsYXllciBpbnRlcmFjdGlvbnMsIHJl ZmVyZW5jaW5nIFJGQzc0MTQgbWlnaHQgYmUgdXNlZnVsIHJlaW5mb3JjZW1lbnQuDQoNCnAuMTAg ZG8gd2UgaGF2ZSBleGFtcGxlcyBvZiB0aGUgMTAgbWludXRlIHJ1bGUgb24gc3RhbGUgUE1UVSBp bmZvcm1hdGlvbiBiZWluZyBpbXBsZW1lbnRlZCwgYW5kIGZlZWRiYWNrIGZyb20gdGhhdD8gKEFn YWluLCBJIGRvbuKAmXQga25vdywgYnV04oCmKQ0KDQpwLjExIHRoZXJl4oCZcyBtb3JlIHBhY2tl dGl6YXRpb24gbGF5ZXIgY29tbWVudGFyeSBoZXJlIGluIHRoZSBib3R0b20gaGFsZiBvZiB0aGUg cGFnZTsgYWdhaW4gaG93IGRvZXMgdGhpcyBzaXQgd2l0aCBSRkM0ODIxPw0KDQpwLjEyIGlzIGl0 IHdvcnRoIGEgVHJhbnNwb3J0IEFyZWEgcGVyc29uIHJldmlld2luZyB0aGUgZXhhbXBsZXMgb2Yg b3RoZXIgdHJhbnNwb3J0IHByb3RvY29scyBnaXZlbiBoZXJlLCBhbmQgYWRkaW5nIG1vcmUgdG9w aWNhbCBleGFtcGxlcz8NCg0KU2VjdGlvbiA2Og0KDQpwLjEzIHdoaWxlIGEg4oCYbWFsaWNpb3Vz IHBhcnR54oCZIG1heSBjYXVzZSBwcm9ibGVtcyBieSBzdG9wcGluZyBhIOKAmHZpY3RpbeKAmSBy ZWNlaXZpbmcgUGFja2V0IFRvbyBCaWcgbWVzc2FnZXMsIGZhaWx1cmUgb2Ygc2l0ZXMgdG8gYWRo ZXJlIHRvIFJGQzQ4OTAgaXMgcHJvYmFibHkgYSBtb3JlIGxpa2VseSBjYXVzZS4gU2hvdWxkIHRo aXMgYmUgbWVudGlvbmVkIHNvbWV3aGVyZT8NCg0KcC4xMyBpcyBpdCB3b3J0aCBhZGRpbmcgYSBu b3RlIGFib3V0IG5vZGVzIG9uIGEgcGF0aCBpbnNlcnRpbmcgYW4gRUggcG90ZW50aWFsbHkgY2F1 c2luZyBQVEIgbWVzc2FnZXMgdG8gZ28gdG8gdGhlIG9yaWdpbmFsIHNvdXJjZSBhbmQgbm90IHRo ZSDigJhvZmZlbmRlcuKAmSB0aGF0IG1hZGUgdGhlIHBhY2tldCB0b28gYmlnPw0KDQpUaW0gDQoN Cg0KDQo= From nobody Mon Jul 18 09:23:52 2016 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A169012DACA for ; Mon, 18 Jul 2016 09:23:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.111 X-Spam-Level: X-Spam-Status: No, score=-4.111 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, T_DKIM_INVALID=0.01] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=fail (1024-bit key) reason="fail (message has been altered)" header.d=jisc365.onmicrosoft.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 lo5IX5zRv2f7 for ; Mon, 18 Jul 2016 09:23:48 -0700 (PDT) Received: from eu-smtp-delivery-189.mimecast.com (eu-smtp-delivery-189.mimecast.com [207.82.80.189]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B66C812DAC6 for <6man@ietf.org>; Mon, 18 Jul 2016 09:23:47 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=jisc365.onmicrosoft.com; s=selector1-jisc-ac-uk; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=pWBdxMnYHY99HZXffnFYHnDg310lHjZgMiabdXMIEts=; b=FWtdt0k3CgJeuhyqKkc2DdIenBgo4ORKLcIbIOGJ/ulZlXSXN3JRnmg7B/YkyxCc85G8KrwgadZVRD2rEkTI0vIWm9F1d6AC3O8pgH4wVssW+TD4w6gNm8rA47tBU5oIoYq3Q/NtdkYDDYrcOX+cIWZSog9rf5lN6Pctpap9h1g= Received: from EUR01-HE1-obe.outbound.protection.outlook.com (mail-he1eur01lp0209.outbound.protection.outlook.com [213.199.154.209]) (Using TLS) by eu-smtp-1.mimecast.com with ESMTP id uk-mta-32-gRWfoKB9MVe_rrEWsHrSNg-1; Mon, 18 Jul 2016 17:23:42 +0100 Received: from AMSPR07MB455.eurprd07.prod.outlook.com (10.242.106.148) by AMSPR07MB456.eurprd07.prod.outlook.com (10.242.106.149) with Microsoft SMTP Server (TLS) id 15.1.534.14; Mon, 18 Jul 2016 16:23:41 +0000 Received: from AMSPR07MB455.eurprd07.prod.outlook.com ([10.242.106.148]) by AMSPR07MB455.eurprd07.prod.outlook.com ([10.242.106.148]) with mapi id 15.01.0539.019; Mon, 18 Jul 2016 16:23:40 +0000 From: Tim Chown To: "6man@ietf.org" <6man@ietf.org> Subject: Review of draft-ietf-6man-rfc4291bis-03 Thread-Topic: Review of draft-ietf-6man-rfc4291bis-03 Thread-Index: AQHR4RC+xYFxcuOtaEGrzTtOTNUtzQ== Date: Mon, 18 Jul 2016 16:23:40 +0000 Message-ID: <563E68A2-582C-46E3-BFEF-42C0FD746101@jisc.ac.uk> Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-mailer: Apple Mail (2.3124) x-ms-exchange-messagesentrepresentingtype: 1 x-originating-ip: [2001:67c:370:152:7c81:1522:50da:c10] x-ms-office365-filtering-correlation-id: c9a6a0b0-f7a8-4b9d-db85-08d3af27e15d x-microsoft-exchange-diagnostics: 1; AMSPR07MB456; 20:CxenYRRe3HguRebpfFby5FLwtK5vluLBhZBobukt2lXdcWJKv8y4lN3IGzDTOVtpVKIzQ4MY5XJl9ScRq35WEjq3iOGpvdgH+BQy1sfD1IaaFRcuxyKKm0hN8nROJdN3JQNt3CFnompFDF20etOUF/pVFzvtr2jTWBNnAorhbdk= x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:AMSPR07MB456; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(278428928389397)(100405760836317); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(601004)(2401047)(5005006)(8121501046)(10201501046)(3002001); SRVR:AMSPR07MB456; BCL:0; PCL:0; RULEID:; SRVR:AMSPR07MB456; x-forefront-prvs: 00073DB75F x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(6009001)(7916002)(54534003)(189002)(199003)(57704003)(586003)(305945005)(10400500002)(2501003)(81166006)(92566002)(2906002)(106356001)(8676002)(105586002)(2351001)(57306001)(106116001)(82746002)(229853001)(3660700001)(122556002)(77096005)(4326007)(101416001)(81156014)(3280700002)(7846002)(50226002)(102836003)(6116002)(74482002)(2900100001)(8936002)(7736002)(189998001)(50986999)(86362001)(230783001)(83716003)(87936001)(33656002)(110136002)(36756003)(68736007)(5002640100001)(5640700001)(97736004)(3826002)(104396002); DIR:OUT; SFP:1101; SCL:1; SRVR:AMSPR07MB456; H:AMSPR07MB455.eurprd07.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; MX:1; A:1; LANG:en; spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-ID: MIME-Version: 1.0 X-OriginatorOrg: jisc.ac.uk X-MS-Exchange-CrossTenant-originalarrivaltime: 18 Jul 2016 16:23:40.6960 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 48f9394d-8a14-4d27-82a6-f35f12361205 X-MS-Exchange-Transport-CrossTenantHeadersStamped: AMSPR07MB456 X-MC-Unique: gRWfoKB9MVe_rrEWsHrSNg-1 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: base64 Archived-At: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.17 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 Jul 2016 16:23:50 -0000 SGkgYWdhaW4sDQoNCk9sZSBhc2tlZCBtZSB0byByZXZpZXcgZHJhZnQtaWV0Zi02bWFuLXJmYzQy OTFiaXMtMDMgYXMgd2VsbC4NCg0KVGhpcyBkb2N1bWVudCBhbHNvIGFwcGVhcnMgdG8gYmUgY2xv c2UgdG8gYmVpbmcgcmVhZHkuIEl0IHNlZW1zIHRvIG1lZXQgdGhlIGNyaXRlcmlhIG9mIFJGQzY0 MTAgYXMgYSBjYW5kaWRhdGUgZm9yIGFkdmFuY2VtZW50IHRvIElTLg0KDQpBIGdlbmVyYWwgcXVl c3Rpb24gZXhpc3RzIGFzIHBlciB0aGUgb3RoZXIgdHdvIC1iaXMgZG9jdW1lbnRzIGFzIHRvIHdo ZXRoZXIgbmV3IG1hdGVyaWFsIHRoYXTigJlzIGluY29ycG9yYXRlZCBzaG91bGQgaW5jbHVkZSBy ZWZlcmVuY2VzIGZvciB0aGUgUkZDcyB0aGUgdXBkYXRlcyBkcmF3IGZyb20uIEFnYWluLCB0aGF0 IHNlZW1zIGEgbGl0dGxlIGluY29uc2lzdGVudCBpbiB0aGlzIGRvY3VtZW50LiBUd28gb3RoZXIg Z2VuZXJhbCBxdWVzdGlvbnMgYXJlIHdoZXRoZXIgVUxBcyBzaG91bGQgYmUgZXhwbGljaXRseSBj YWxsZWQgb3V0IGhlcmUgKGFzIGEgcmVwbGFjZW1lbnQgZm9yIHNpdGUtbG9jYWxzKSwgYW5kIHdo ZXRoZXIgd2Ugc2hvdWxkIGFkZCBJQU5BIHJlZ2lzdHJ5IHBvaW50ZXJzIGluIHRoZSBJQU5BIHNl Y3Rpb24gKG5vIGFjdGlvbiBmb3IgSUFOQSwgYnV0IGEgcmVhZGVyIHdpbGwgdGhlbiBrbm93IHdo aWNoIHJlZ2lzdHJpZXMgYXJlIGluIHVzZSkuICBUaGVyZSBpcyBubyBtZW50aW9uIG9mIFVMQXMg aW4gdGhlIGNoYW5nZSBsb2csIHNvIGl04oCZcyBub3QgY2xlYXIgaWYgaXTigJlzIGJlZW4gZGlz Y3Vzc2VkIGFuZCByZWplY3RlZCwgb3Igbm90Lg0KDQpHZW5lcmFsIGNvbW1lbnRzOg0KDQpTZWN0 aW9uIDI6DQoNCnAuIDcgaXQgbG9va3MgbGlrZSB0aGUgbmV3IFNlY3Rpb24gMi4yLjMgdGFrZXMg dGV4dC9jb250ZW50IGZyb20gUkZDNTk1MiwgYnV0IGRvZXMgbm90IGNpdGUgaXQuIFNob3VsZCBp dD8gDQoNCnAuOSBhbmQgcC4xMCAtIGlzIHRoZXJlIGEgcmVxdWlyZW1lbnQgdG8gYWRkIGEgcmVm ZXJlbmNlIHRvIFJGQzQxOTMgZm9yIFVMQXMgaGVyZT8gVGhleSBhcmUgZGVmaW5lZCBhdCBHbG9i YWwgc2NvcGUsIGJ1dCBoYXZlIGEgc3BlY2lmaWMgYmluYXJ5IHByZWZpeCB0aGF0IGNvdWxkIGJl IGFkZGVkIHRvIHRoZSB0YWJsZSBvbiBwLjkuIFdoaWxlIHRyZWF0ZWQgaW4gcHJpbmNpcGxlIGJ5 IGFwcGxpY2F0aW9ucyBhcyBHbG9iYWwgc2NvcGUgYWRkcmVzc2VzLCB0aGVpciBoYW5kbGluZy91 c2UgY2FuIGRpZmZlciwgZS5nLiB0aHJvdWdoIFJGQzY3MjQtYmFzZWQgYWRkcmVzcyBzZWxlY3Rp b24uICBUaGF0IHNhaWQsIEkgbm90ZSB0aGF0IFJGQzQxOTMgZG9lcyBub3Qgc2F5IGl0IGZvcm1h bGx5IHVwZGF0ZXMgUkZDNDE5Mi4NCg0KcC4xMSBwcmFnbWF0aWNhbGx5LCBzaG91bGQgdGhlcmUg YmUgYSBtZW50aW9uIG9mIFJGQzc0MjEgKFdoeSAvNjQ/KSBhdCB0aGUgZW5kIG9mIFNlY3Rpb24g Mi40PyAgQmVjYXVzZSBhc3N1bXB0aW9ucyAqYXJlKiBub3cgbWFkZSBhYm91dCB0aGUgNjQtYml0 IGJvdW5kYXJ5IDEwIHllYXJzIG9uIGZyb20gdGhlIG9yaWdpbmFsIHB1YmxpY2F0aW9uIG9mIDQy OTEuDQoNCnAuMTEgdGhpcyBzZWN0aW9uIG9uIElJRHMgYWRkcyByZWZlcmVuY2VzIHRvIFJGQzc3 MjEgKHNlY3VyaXR5ICYgcHJpdmFjeSBjb25zaWRlcmF0aW9ucykgYW5kIFJGQzcyMTcgKHN0YWJs ZSBwcml2YWN5IElJRHMpLCBidXQgZG9lc27igJl0IGRpZmZlcmVudGlhdGUgYmV0d2VlbiDigJx0 ZW1wb3JhcnkiIGFkZHJlc3NlcyAoYXMgcGVyIFJGQzQ5NDEpIGFuZCByZWd1bGFyIGFkZHJlc3Nl cy4gU2hvdWxkIGl0Pw0KDQpwLjExIHRoZXJlIGlzIG5vIHJlYXNvbiBnaXZlbiBoZXJlIGZvciB0 aGUgSUVFRSBNQUMgZGVyaXZlZCBJSURzIGJlaW5nIG5vIGxvbmdlciByZWNvbW1lbmRlZC4gVGhp cyBjb3VsZCBiZSB3cml0dGVuIHRvIGJlIG1vcmUgY2xlYXJseSBpbnRlZ3JhdGVkIHdpdGggdGhl IHJlZmVyZW5jZSB0byBSRkM3NzIxIGFib3ZlLg0KDQpwLjE0IGFnYWluLCBzaG91bGQgdGhlIHNp dGUtbG9jYWwgc2VjdGlvbiBiZSByZXBsYWNlZCB3aXRoIFVMQXM/DQoNCnAuMTYgdGhlcmUgaXMg bm8gcmVmZXJlbmNlIHRvIFJGQzczNzEgKG11bHRpY2FzdCBhZGRyZXNzIGFyY2hpdGVjdHVyZSB1 cGRhdGUpIG9yIFJGQzczNDYgKG11bHRpY2FzdCBzY29wZXMpOyBzaG91bGQgdGhlc2UgYmUgYWRk ZWQ/DQoNCnAuMTYgaXQgc2VlbXMgdGhhdCBSRkM3MzcxIGNoYW5nZXMgd2VyZSBiYWNrZWQgb3V0 IGluIHRoZSAtMDIgdmVyc2lvbiBvZiB0aGlzIGJpcyBkb2N1bWVudCwgb24gdGhlIGdyb3VuZHMg dGhhdCBpbXBsZW1lbnRhdGlvbnMgaGFkbuKAmXQgY2hhbmdlZCB0byByZWZsZWN0IHRoaXMuICBU aGlzIHN1cnByaXNlZCBtZSwgYnV0IEkgYXNzdW1lIHRoaXMgd2FzIGRpc2N1c3NlZCBhbmQgdGhl cmUgaXMgV0cgY29uc2Vuc3VzIHRvIGRvIHRoaXM/IA0KDQpwLjE3IGEgZ29vZCBjaHVuayBvZiB0 aGlzIHBhZ2UgaXMgY29waWVkIGZyb20gUkZDNzM0Niwgd2l0aG91dCBjaXRpbmcgaXQuDQoNClNl Y3Rpb24gMyAoSUFOQSk6DQoNCnAuMjEgdGhlcmUgaXMgbm8gbWVudGlvbiBvZiBSRkM1NDUzLCB3 aGljaCBjcmVhdGVkIHRoZSBJQU5BIHJlZ2lzdHJ5IGZvciByZXNlcnZlZCBJUHY2IGludGVyZmFj ZSBpZGVudGlmaWVycy4gU2hvdWxkIHRoZXJlIGJlPw0KDQpwLjIxICB0aGVyZSBpcyBubyBtZW50 aW9uIG9mIHRoZSBJQU5BIElQdjYgU3BlY2lhbC1QdXJwb3NlIEFkZHJlc3MgUmVnaXN0cnksIGFz IHBlciBSRkM2ODkwLiBTaG91bGQgdGhlcmUgYmU/DQoNCnAuMjEgc2hvdWxkIFNlY3Rpb24gNiBv ZiBSRkM3MzQ2IGJlIGNhcHR1cmVkIGhlcmU/DQoNCkFwcGVuZGl4IEENCg0KcC4yNCBSRkM3MTM2 IHRhbGtzIGFib3V0IHRoZSAobGFjayBvZikgbWVhbmluZyBpbiBJSUQgYml0cywgZXNwLiByZWxh dGVkIHRvIHRoZSB1LGcgYml0cy4gRG8gd2UgbmVlZCB0byByZWZlciB0byB0aGlzIGluIEFwcGVu ZGl4IEEsIHdoZXJlIElFRUUgTUFDLWJhc2VkIElJRHMgYXJlIGRpc2N1c3NlZD8gT3IgaXMgdGhp cyBub3QgaW1wb3J0YW50IGdpdmVuIHdl4oCZcmUgbm90IHJlY29tbWVuZGluZyB0aGlzIGZvcm0g b2YgSUlEIGdlbmVyYXRpb24gYW55IG1vcmU/DQoNCk90aGVyIGNvbW1lbnRzOg0KDQpSRkM2MDUy IG9uIElQdjYgQWRkcmVzc2luZyBvZiBJUHY0L0lQdjYgVHJhbnNsYXRvcnMgc3RhdGVzIGl0IGZv cm1hbGx5IHVwZGF0ZXMgUkZDNDI5MS4gIEl0IHJlc2VydmVzIDY0OmZmOWI6Oi85NiBhcyBhIHdl bGwta25vd24gcHJlZml4LiBUaG91Z2ggaXQgdGhlbiBhbHNvIHNheXMgaW4gdGhlIHRleHQgdGhh dCBubyB1cGRhdGVzIHRvIFJGQzQyOTEgYXJlIHJlcXVpcmVkLiBEbyB3ZSBuZWVkIHRvIGNoYW5n ZSBhbnl0aGluZyBpbiA0MjkxYmlzIG9uIGFjY291bnQgb2YgUkZDNjA1MiBvciBub3Q/DQoNClRp bSANCg0KDQoNCg== From nobody Mon Jul 18 12:03:22 2016 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 445A412B077; Mon, 18 Jul 2016 12:03:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.188 X-Spam-Level: X-Spam-Status: No, score=-3.188 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-1.287, SPF_PASS=-0.001] 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 Yr3IcjwRsKkU; Mon, 18 Jul 2016 12:03:14 -0700 (PDT) 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 3356512B01E; Mon, 18 Jul 2016 12:03:14 -0700 (PDT) Received: from sandelman.ca (obiwan.sandelman.ca [209.87.249.21]) by tuna.sandelman.ca (Postfix) with ESMTP id 69223200A7; Mon, 18 Jul 2016 15:12:38 -0400 (EDT) Received: from obiwan.sandelman.ca (localhost [IPv6:::1]) by sandelman.ca (Postfix) with ESMTP id 391C5638D1; Mon, 18 Jul 2016 15:03:13 -0400 (EDT) From: Michael Richardson To: roll@ietf.org Subject: impacts of rfc2460bis on draft-ietf-roll-useofrplinfo X-Attribution: mcr X-Mailer: MH-E 8.6; nmh 1.6+dev; GNU Emacs 24.5.1 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@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.17 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 Jul 2016 19:03:16 -0000 --=-=-= Content-Type: text/plain The ROLL document draft-ietf-roll-useofrplinfo documents RFC6553 (a Hop-by-Hop critical option) and 6554 (a form of Source Routing Header, RH3). There is work on 6lo to allocate additional 6lowpan IPHC codes such that the work in ROLL: https://datatracker.ietf.org/doc/draft-ietf-roll-routing-dispatch/ can know what kinds of things we need to compress. A number of things are constrained by the need to always remove the RFC6553 Hop-by-Hop option RPI option which had been marked critical: i.e. drop packet if you don't understand it. As a result of the change in RFC2460bis, which says that intermediate hosts will in general not examine hop-by-hop options, but should just ignore them, we can make certain simplications to the useofrplinfo document. (rfc2460bis, section 4, page 8, "NOTE: While...) (It is unclear what end-hosts can/should do. I will assume they can also ignore hop-by-hop options if they haven't been told to pay attention to them). https://goo.gl/cxWkP5 this is a reference to an RFC diff between: draft-ietf-roll-useofrplinfo-06.txt and draft-richardson-roll-useofrplinfo-2460bis-00.txt (Note we have only re-analyzed storing mode , so please ignore changes in section 6) The summary is that in storing mode we never need to use per-hop IPv6-in-IPv6 encapsulation with the 2460bis text. Packets originating from not-RPL aware nodes (i.e. 6LN leafs or Internet nodes), need to be encapsulated so that the RPI option can be added, but no complex considerations need apply for where to remove the RPI, as it can be left in place until the end-host. -- Michael Richardson , Sandelman Software Works -= IPv6 IoT consulting =- --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 iQEVAwUBV40n7YCLcPvd0N1lAQIRCQgAlC7K8hRhC6Ttbtz8ZMaj4AZo+P2Tcx32 gHWoJvIkA4aJ9Tfyw9aO/DjH39exoGBZfCKrQp6VuKH2wnp+4B3CJWSbY0sAYsVI z+EEt7wmtDG+NF1kX6AhR/Pi9VE3hlYrCRdqgoFpksbk10P1/hVuXCodl4j1bKv0 v58QvnOLmHStHwM7YAo81LoZk06yrsY4s82tzGLfVaV3OthqhW7/MmISGM37xPSU mG8tVsmhu93S8IyFaTN9K7pkbNqvoOqStX39QjDtZZlgPQWKON52KYSENLedgf6O /hqIE1XXqL4C1f2MxMEeWYEBoSl5GlGqMezGelf74IKZost/gJN6RQ== =Xqq4 -----END PGP SIGNATURE----- --=-=-=-- From nobody Mon Jul 18 14:55:04 2016 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C979312D8C3 for ; Mon, 18 Jul 2016 14:55:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.347 X-Spam-Level: X-Spam-Status: No, score=-2.347 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FORGED_FROMDOMAIN=0.001, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=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 X6XUCz_fJbfq for ; Mon, 18 Jul 2016 14:55:00 -0700 (PDT) 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 9B198127071 for ; Mon, 18 Jul 2016 14:55:00 -0700 (PDT) Received: by mail-io0-x22c.google.com with SMTP id m101so3087931ioi.2 for ; Mon, 18 Jul 2016 14:55:00 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:from:date:message-id:subject:to; bh=zCuSyOMkzzyGKEf8MwrTFZV611QmLHlEvrojmcKzoAg=; b=ptSyesDf74UAP9qVhJ7210R/3bBxZ3uacoQZknnvPOXixnOOIZvJXc0cmt95uafJhV 6Ao7QXDQ4SSnXD9VCl/1LTZa7A4+lh102z6L4tkyh9/E4QKm6aEjrdaHaPPn2QMNrs+R 7H+ORLHZ0mqqm/t3sFUHxzWqS7IdJ26KdRYvho7Set7R1nSSK3wLRHniqnWjjoEi+eBe aSp9r6hHjBHgamHTbfSEELlsaYaBiXt6zCAPCcjs+ldW9Gl4N1YZh4czD3muvOE1u/k6 sCArLU2l/5DCU77s2QtmnBJ3m/pCGuocjmS8trEkAWXw+6K6O37mFjsSKm+PkcztJZmK t0ew== 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:from:date:message-id:subject :to; bh=zCuSyOMkzzyGKEf8MwrTFZV611QmLHlEvrojmcKzoAg=; b=i7VrDKGgBOMPUmvLUnTdMgxUSwd2LgHoF21izFceqFZb5NXc5NMh9IxXdUZkpZFVSE i0mZrXBMCN5r8VCMeistvzr8wbsTwX7F7ZQwctwz21mMNT86YWRqheBHGJ1icgQKQ4dd RGMnF9jd6mcU9q87LsDEFGQVOeiu92gNLiVYcR+LYnDWBGMkuVGbYlX0qwlB03Lv5yzZ fHGw5kmO8KkE/stvpOkqtZwMbUlw4qsp7qmVt+GS/fYJxGyvEkTaMTCZb9/ykyEkfxRx 83O5uTVIJJHG9uxZBDbxeB0q2waXZ92Eq5Ap7mwLjOb6NqDxBO6+HNmggJpIT4DcQlpg PfNg== X-Gm-Message-State: ALyK8tK/UQ0qLLBKMRYpuCpslacH7/KHpWuh3Axy33h+FaQaHDC2Fs60inLPNZntxc/dpr1BTCkfhLbqtZv7yQ== X-Received: by 10.107.13.70 with SMTP id 67mr11303406ion.75.1468878899847; Mon, 18 Jul 2016 14:54:59 -0700 (PDT) MIME-Version: 1.0 Sender: kerlyn2001@gmail.com Received: by 10.107.9.22 with HTTP; Mon, 18 Jul 2016 14:54:59 -0700 (PDT) From: Kerry Lynn Date: Mon, 18 Jul 2016 17:54:59 -0400 X-Google-Sender-Auth: EeILpEIgE83tj8ZLEV0D__9azic Message-ID: Subject: Comments on draft-bchv-rfc6890bis-00.txt To: 6man 6man Content-Type: multipart/alternative; boundary=001a113ff9940b32750537f00576 Archived-At: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.17 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 Jul 2016 21:55:03 -0000 --001a113ff9940b32750537f00576 Content-Type: text/plain; charset=UTF-8 Hi Brian, I think there may be a problem with the general approach taken by this draft. I certainly don't have the full context, but it seems that before RFC 6890 there were separate RFCs to describe IPv4 and IPv6 Special-Purpose Address Registries. RFC 6890 obsoleted RFCs 4773, 5156, 5735, and 5736 and apparently attempted to define a set of common predicates that would apply to both address families. I've not been able to find archived versions of the pre-RFC 6890 registries, but many of the predicates in the current python ipaddress library, which claim to conform to the IPv4 and IPv6 Special-Purpose Registries, contain terms that no longer appear (e.g. is_private, is_link_local, etc). See https://docs.python.org/3/library/ipaddress.html. If we change "Global" to "Globally Routable" in the IPv6 registry http://www.iana.org/assignments/iana-ipv6-special-registry without also doing so in the IPv4 registry http://www.iana.org/assignments/iana-ipv4-special-registry then we will once again have divergent terminology and I'm not sure that is what's intended. Kerry Lynn --001a113ff9940b32750537f00576 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hi Brian,

I think there may be a = problem with the general approach taken by this draft.

I= certainly don't have the full context, but it seems that before RFC 68= 90
there were separate RFCs to describe IPv4 and IPv6 Special-Pur= pose
Address Registries.=C2=A0 RFC 6890 obsoleted RFCs 4773, 5156= , 5735, and
5736 and apparently attempted to define a set of comm= on predicates that
would apply to both address families.

I've not been able to find archived versions of the pr= e-RFC 6890 registries,
but many of the predicates in the current = python ipaddress library, which
claim to conform to the IPv4 and = IPv6 Special-Purpose Registries, contain
terms that no longer app= ear (e.g. is_private, is_link_local, etc).=C2=A0 See

If we change "= ;Global" to "Globally Routable" in the IPv6 registry
h= ttp://www.iana.org/assignments/iana-ipv6-special-registry
without also doing so in the IPv4 registry
then we will once again= have divergent terminology and I'm not sure that
is what'= ;s intended.

Kerry Lynn

--001a113ff9940b32750537f00576-- From nobody Mon Jul 18 22:29:02 2016 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7862012D0E2; Mon, 18 Jul 2016 22:29:01 -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 ACwsQlC4tf_H; Mon, 18 Jul 2016 22:29:00 -0700 (PDT) Received: from mail-wm0-x22d.google.com (mail-wm0-x22d.google.com [IPv6:2a00:1450:400c: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 A657B12D08F; Mon, 18 Jul 2016 22:28:59 -0700 (PDT) Received: by mail-wm0-x22d.google.com with SMTP id o80so11727731wme.1; Mon, 18 Jul 2016 22:28:59 -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=BlDnyk/gP83XS7vzrB9KBqbrGZEKxsD7+w8yL1B/hrU=; b=KYnEg8vFSRD3K+VUA9mEIklyPAxyiJ6CxVbMiliOBnct6sUy/NeU37JYl+2FrWxU/9 uLC6a3kqYb6kyBmHyVxrmo9qsf3oqv/6rOjs4YxOSlYBmj9pi1EgKVtFuQShDRwtEDA5 3BqytCblgRCJz/27NHB0ZH5ojpu+ET3zanRFwCncldgMqHyMHWLdpmCmdCVr0q1/MN6V a6Azd8dXt8QL4wRqzUFtpXrVUcejElo339jyPzxBUQhTFM066cgvWwY17Oavt6fm/qWk KQGV3CMqXL4X7v6qK7/GU+9LFImw3BvN65GkXeM++6pb8wbvrGdl/yIWHppWdq+wTI8t t++g== 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=BlDnyk/gP83XS7vzrB9KBqbrGZEKxsD7+w8yL1B/hrU=; b=LwXObDjk5GT5vR8vNvXmz4SZRc0tKTvNTPq1wGnO2nSH47Wak6PbF+uNz0h05m8y9c +YuZra43GOz5paIA7JUSYS0OiPobxWoRHhhibQ3q3go3mJ0XDN9GPiNfAmZE+jzfzTmz nfBo0lUi5qCxpyCcgxalW5D9+9VPk70e5iRzQAZUwGNxbB/65+wQxarZFyCtaZtniDY/ M76mRsNpEh7l4bqPLGFfHad7gaY5alsmCkLyff3BbxBXp8VInWG5SsDoQVK1XnUzLwfe dsJfccCETi2K44p5M9pp0zFcwcnBsLcSPKRuUDAzzRfN5K8aMLgV5EeM2uarpeuWyH19 B86A== X-Gm-Message-State: ALyK8tIIZUQh3DZuSoG+NfTbom9If2BCR4OT6GrhJhZYpFx0OSFMOOxTjP7AOeGnnv8izg== X-Received: by 10.194.176.34 with SMTP id cf2mr4617336wjc.172.1468906138114; Mon, 18 Jul 2016 22:28:58 -0700 (PDT) Received: from ?IPv6:2001:67c:370:136:28cc:dc4c:9703:6781? ([2001:67c:370:136:28cc:dc4c:9703:6781]) by smtp.gmail.com with ESMTPSA id i195sm21946093wmg.1.2016.07.18.22.28.56 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 18 Jul 2016 22:28:57 -0700 (PDT) Subject: Re: impacts of rfc2460bis on draft-ietf-roll-useofrplinfo To: Michael Richardson , roll@ietf.org References: <24554.1468868593@obiwan.sandelman.ca> From: Brian E Carpenter Organization: University of Auckland Message-ID: <799ab640-bed0-22a6-a9df-97f78c3f0bf8@gmail.com> Date: Tue, 19 Jul 2016 17:28:58 +1200 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.2.0 MIME-Version: 1.0 In-Reply-To: <24554.1468868593@obiwan.sandelman.ca> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Archived-At: Cc: 6man@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 Jul 2016 05:29:01 -0000 On 19/07/2016 07:03, Michael Richardson wrote: > > The ROLL document draft-ietf-roll-useofrplinfo documents RFC6553 (a > Hop-by-Hop critical option) and 6554 (a form of Source Routing Header, RH3). > There is work on 6lo to allocate additional 6lowpan IPHC codes such that > the work in ROLL: > https://datatracker.ietf.org/doc/draft-ietf-roll-routing-dispatch/ can > know what kinds of things we need to compress. > > A number of things are constrained by the need to always remove the > RFC6553 Hop-by-Hop option RPI option which had been marked critical: > i.e. drop packet if you don't understand it. > > As a result of the change in RFC2460bis, which says that intermediate hosts > will in general not examine hop-by-hop options, but should just ignore > them, we can make certain simplications to the useofrplinfo document. > (rfc2460bis, section 4, page 8, "NOTE: While...) You can already do that, because RFC7045 section 2.2 updates RFC2460: " The IPv6 Hop-by-Hop Options header SHOULD be processed by intermediate forwarding nodes as described in [RFC2460]." which of course means that forwarding nodes MAY ignore HbH. > (It is unclear what end-hosts can/should do. I will assume they can > also ignore hop-by-hop options if they haven't been told to pay attention to > them). If they are 00 options, yes, RFC2460 is clear that for all options: The Option Type identifiers are internally encoded such that their highest-order two bits specify the action that must be taken if the processing IPv6 node does not recognize the Option Type: 00 - skip over this option and continue processing the header. Brian > > https://goo.gl/cxWkP5 this is a reference to an RFC diff between: > draft-ietf-roll-useofrplinfo-06.txt > and draft-richardson-roll-useofrplinfo-2460bis-00.txt > > (Note we have only re-analyzed storing mode , so please ignore changes in > section 6) > > The summary is that in storing mode we never need to use per-hop > IPv6-in-IPv6 encapsulation with the 2460bis text. Packets originating from > not-RPL aware nodes (i.e. 6LN leafs or Internet nodes), need to be > encapsulated so that the RPI option can be added, but no complex > considerations need apply for where to remove the RPI, as it can be left in > place until the end-host. > > -- > 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 Jul 18 22:50:01 2016 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 267AC12B041 for ; Mon, 18 Jul 2016 22:50:00 -0700 (PDT) X-Quarantine-ID: X-Virus-Scanned: amavisd-new at amsl.com X-Amavis-Alert: BANNED, message contains text/plain,.exe,addrProps.py 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 zEJ1DTVrFmmf for ; Mon, 18 Jul 2016 22:49:58 -0700 (PDT) Received: from mail-wm0-x231.google.com (mail-wm0-x231.google.com [IPv6:2a00:1450:400c: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 1490E12B037 for ; Mon, 18 Jul 2016 22:49:58 -0700 (PDT) Received: by mail-wm0-x231.google.com with SMTP id r190so24243716wmr.0 for ; Mon, 18 Jul 2016 22:49:58 -0700 (PDT) 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; bh=n3d19j2QMVvv0BwWnmaRwzHgkIeArvjmM7WgtNhWHxs=; b=bnu6quaCHDBMfWR1WUA4DQ/2s7Lt5svgmIAVijOwmH5wmvwOe7P8+sZ/GShEJJbmdL ZcSdSoEOVyCOrEr/a8w+veDPHEa4xFAxHzJJCTwuBH1JcDfNfNTQ7ZZu9bq7i57YEQYX /Ops48IM/+XNi0uXIzOLcfsOysiJQmSJvAd7dRL6QlbyVuukFKhos1VAHlTgLAxrapAp Z6nHut6mTbw4kFwdVnsLrjMXWstbvoSb5mbS1NFEcotIieVNZW2FgN/Bcno81mNDuwNT EqJVqy9+uD0qLUpznonqwg6qeeBu+ZMV1Zl8SNkgvqAsgtg5Q9tHkQn4Aysg92m0WZBh 4ytw== 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; bh=n3d19j2QMVvv0BwWnmaRwzHgkIeArvjmM7WgtNhWHxs=; b=lTU0BY8vm1KRw1rGxIz5GGwVHjNmilocUU8rVyCYsxKaeXOdyKyXNzmQaPFPsYVJ+s F46TpZ7F7bnbp6XHWu+Qhbj8U4JvIU/Aw8LbFVDnQSYEcY/ww7oKTntiiIC9jyYqs5l4 xKs2bcKzJjBMblvdciY874DQNLS3UsCuSMyPeZWJBYNz8tV9Br7HpSuTl4CGknM2vfW2 vzUP4pFTdLpvI+8lMELNkdEGCzIsqgfaLCPQLsjLJi/ndL9MF0+kCemABE3hrgjJCtrr pMuV186hrnPq3E9L5/CxvClgXkgp9Ais1N8uRMaQ8YhXhjRUKW+XaxUbxB3+xEpROfMm PJsg== X-Gm-Message-State: ALyK8tJOuGTcVPTbN5QkP59B+NFsstzfaxicOagOw9a7DoYsTZvE8uZSigyoJeLORVNyYw== X-Received: by 10.194.121.134 with SMTP id lk6mr4145039wjb.88.1468907396547; Mon, 18 Jul 2016 22:49:56 -0700 (PDT) Received: from ?IPv6:2001:67c:370:176:28cc:dc4c:9703:6781? ([2001:67c:370:176:28cc:dc4c:9703:6781]) by smtp.gmail.com with ESMTPSA id l6sm4710550wjf.18.2016.07.18.22.49.55 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 18 Jul 2016 22:49:55 -0700 (PDT) Subject: Re: Comments on draft-bchv-rfc6890bis-00.txt To: Kerry Lynn , 6man 6man References: From: Brian E Carpenter Organization: University of Auckland Message-ID: <64775099-aca6-85ba-c3ee-f44694b1bdf0@gmail.com> Date: Tue, 19 Jul 2016 17:49:57 +1200 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.2.0 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/mixed; boundary="------------B61361C98C95003D3646EB5A" Archived-At: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 Jul 2016 05:50:00 -0000 This is a multi-part message in MIME format. --------------B61361C98C95003D3646EB5A Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit On 19/07/2016 09:54, Kerry Lynn wrote: > Hi Brian, > > I think there may be a problem with the general approach taken by this > draft. > > I certainly don't have the full context, but it seems that before RFC 6890 > there were separate RFCs to describe IPv4 and IPv6 Special-Purpose > Address Registries. RFC 6890 obsoleted RFCs 4773, 5156, 5735, and > 5736 and apparently attempted to define a set of common predicates that > would apply to both address families. > > I've not been able to find archived versions of the pre-RFC 6890 registries, > but many of the predicates in the current python ipaddress library, which > claim to conform to the IPv4 and IPv6 Special-Purpose Registries, contain > terms that no longer appear (e.g. is_private, is_link_local, etc). See > https://docs.python.org/3/library/ipaddress.html. To be specific, the one that *this* Brian tripped over was is_global, which surprised me by returning False for ULAs, which are clearly defined as having global unicast scope. is_link_local is beyond dispute I think. is_private is an interesting one - I assumed the Python module author had invented it. Python returns is_private = False for 100.64.0.0. I think that's a bug. (The attached Python3 script may amuse you.) > > If we change "Global" to "Globally Routable" in the IPv6 registry > http://www.iana.org/assignments/iana-ipv6-special-registry > without also doing so in the IPv4 registry > http://www.iana.org/assignments/iana-ipv4-special-registry > then we will once again have divergent terminology and I'm not sure that > is what's intended. 'Global' is an undefined property for IPv4 in the Python library. But then, scope has never been formalised for IPv4 unicast. Brian C --------------B61361C98C95003D3646EB5A Content-Type: text/plain; charset=UTF-8; name="addrProps.py" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="addrProps.py" aW1wb3J0IGlwYWRkcmVzcw0KcHJpbnQoIlRoaXMgd2lsbCB0ZWxsIHlvdSB3aGF0IFB5dGhv biBiZWxpZXZlcyBhcmUgdGhlIHByb3BlcnRpZXMgb2YgYW55IElQIGFkZHJlc3MiKQ0Kd2hp bGUgVHJ1ZToNCiAgICBwcmludCgiUGxlYXNlIGVudGVyIGFuIElQIGFkZHJlc3M6IikNCiAg ICBfbCA9IGlucHV0KCkNCiAgICBpZiAncScgaW4gX2wgb3IgJ1EnIGluIF9sOg0KICAgICAg ICBicmVhaw0KICAgIHRyeToNCiAgICAgICBfbCA9IGlwYWRkcmVzcy5JUHY2QWRkcmVzcyhf bCkNCiAgICBleGNlcHQ6DQogICAgICAgIHRyeToNCiAgICAgICAgICAgX2wgPSBpcGFkZHJl c3MuSVB2NEFkZHJlc3MoX2wpDQogICAgICAgIGV4Y2VwdDoNCiAgICAgICAgICAgIHByaW50 KCJJbnZhbGlkIikNCiAgICAgICAgICAgIGNvbnRpbnVlDQogICAgIyBOb3cgZGlzcGxheSBh ZGRyZXNzIHByb3BlcnRpZXMNCiAgICBwcmludCgiVGhhdCdzIiwgX2wpDQogICAgdHJ5Og0K ICAgICAgICBwcmludCgiR2xvYmFsIiwgX2wuaXNfZ2xvYmFsKQ0KICAgIGV4Y2VwdDoNCiAg ICAgICAgcHJpbnQoIkdsb2JhbCAodW5kZWZpbmVkIGZvciBJUHY0KSIpDQogICAgcHJpbnQo IlByaXZhdGUiLCBfbC5pc19wcml2YXRlKQ0KICAgIHByaW50KCJVbnNwZWNpZmllZCIsIF9s LmlzX3Vuc3BlY2lmaWVkKQ0KICAgIHByaW50KCJSZXNlcnZlZCIsIF9sLmlzX3Jlc2VydmVk KQ0KICAgIHByaW50KCJMb29wYmFjayIsIF9sLmlzX2xvb3BiYWNrKQ0KICAgIHByaW50KCJM aW5rIExvY2FsIiwgX2wuaXNfbGlua19sb2NhbCkNCiAgICBwcmludCgiTXVsdGljYXN0Iiwg X2wuaXNfbXVsdGljYXN0KQ0KICAgIHByaW50KCkNCnByaW50KCJHb29kYnllIikNCg== --------------B61361C98C95003D3646EB5A-- From nobody Mon Jul 18 23:20:51 2016 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9E7D212D119 for ; Mon, 18 Jul 2016 23:20:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.347 X-Spam-Level: X-Spam-Status: No, score=-2.347 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FORGED_FROMDOMAIN=0.001, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=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 54LoVC6K-mZL for ; Mon, 18 Jul 2016 23:20:48 -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 6857D12D0DE for ; Mon, 18 Jul 2016 23:20:48 -0700 (PDT) Received: by mail-io0-x233.google.com with SMTP id m101so10574371ioi.2 for ; Mon, 18 Jul 2016 23:20:48 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to:cc; bh=PG14crL3/9qDfin21lAARhgez17NPfwF8l93/nzEMVI=; b=D6Amj7Kp3PtUdMtKj+VECMsIbRd7k7jnihfoo8YkYUIxoxHfidml/sBX+IDqAdJkK3 OgH6KqrypUSYVFFjZnr9uexlenmjo5OP4FEM87wLpt04Gb/SIaqa3r1Pqe2Oaxr1mZaH rgW6FyJwz9626M/Zocpm+sKDFnnJbS8LFGcudYNaGAlEuwk8FoNH/pSMiqAoOnfJwFo6 YM7dIvSm8ZGxsBM2g/kdrxdUTK96/fZZtjBOhJt/OYJPpgOWmT3Hyx+PBartU1hvsTjH I7xwnl0lslGRQSm6tXYxO11/905xD+EmZUGN4NEr24hNe94mgY2GWBFhvwas2NLlssEL X6pQ== 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:from :date:message-id:subject:to:cc; bh=PG14crL3/9qDfin21lAARhgez17NPfwF8l93/nzEMVI=; b=IS7NTuHI3hT0pSyAADwYEOYlGBEBeuKw+0LrdOSCGCHcwrPtJM635peCUfGAR7PTKD KtK2zDEtjI6J4YFNen+Fcc9g/hbZmUVoncxbXahzRIfi6vHFwyuouAXyZTbAsAw0DYxZ lwR0gnCJxn01m0BzbFv9VuRCLA1dQ8cfyW0THIYBcvEMQhtmJ+cWxnT9WWZp1JTzj49M 6v7IMh3gATLOu7+Yv0FStbi9XVuNQMOSmox8t9/kvX+TOMJRlGxuFB163ihH8eKDi6jB pKELliF8vksWcXkkzzBlc6H/GBrDMRudx+6+6JaUn/+MT9y+gMJTQOGG6Ze2Vej67niG 8r6g== X-Gm-Message-State: ALyK8tKER58RaXmZllFlC25ufLZfZKHDE39UAwA98sszDp8GteB2/Y3MlCfQH3W5unl6aeznEH+RTgGURbGIpA== X-Received: by 10.107.171.131 with SMTP id u125mr3690064ioe.111.1468909247687; Mon, 18 Jul 2016 23:20:47 -0700 (PDT) MIME-Version: 1.0 Sender: kerlyn2001@gmail.com Received: by 10.107.9.22 with HTTP; Mon, 18 Jul 2016 23:20:45 -0700 (PDT) In-Reply-To: <64775099-aca6-85ba-c3ee-f44694b1bdf0@gmail.com> References: <64775099-aca6-85ba-c3ee-f44694b1bdf0@gmail.com> From: Kerry Lynn Date: Tue, 19 Jul 2016 02:20:45 -0400 X-Google-Sender-Auth: 1MzCbp7xDSEog-P_WRTGxub4BJ8 Message-ID: Subject: Re: Comments on draft-bchv-rfc6890bis-00.txt To: Brian Haberman , Brian E Carpenter Content-Type: multipart/alternative; boundary=001a1148b080ea71ab0537f715ea Archived-At: Cc: 6man 6man X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 Jul 2016 06:20:50 -0000 --001a1148b080ea71ab0537f715ea Content-Type: text/plain; charset=UTF-8 On Tue, Jul 19, 2016 at 1:49 AM, Brian E Carpenter < brian.e.carpenter@gmail.com> wrote: > On 19/07/2016 09:54, Kerry Lynn wrote: > > Hi Brian, > > > > I think there may be a problem with the general approach taken by this > > draft. > > > > I certainly don't have the full context, but it seems that before RFC > 6890 > > there were separate RFCs to describe IPv4 and IPv6 Special-Purpose > > Address Registries. RFC 6890 obsoleted RFCs 4773, 5156, 5735, and > > 5736 and apparently attempted to define a set of common predicates that > > would apply to both address families. > > > > I've not been able to find archived versions of the pre-RFC 6890 > registries, > > but many of the predicates in the current python ipaddress library, which > > claim to conform to the IPv4 and IPv6 Special-Purpose Registries, contain > > terms that no longer appear (e.g. is_private, is_link_local, etc). See > > https://docs.python.org/3/library/ipaddress.html. > > To be specific, the one that *this* Brian tripped over was is_global, > which surprised me by returning False for ULAs, which are clearly defined > as having global unicast scope. is_link_local is beyond dispute I think. > is_private is an interesting one - I assumed the Python module author had > invented it. > > Python returns is_private = False for 100.64.0.0. I think that's a bug. > > (The attached Python3 script may amuse you.) > > > > > If we change "Global" to "Globally Routable" in the IPv6 registry > > http://www.iana.org/assignments/iana-ipv6-special-registry > > without also doing so in the IPv4 registry > > http://www.iana.org/assignments/iana-ipv4-special-registry > > then we will once again have divergent terminology and I'm not sure that > > is what's intended. > > 'Global' is an undefined property for IPv4 in the Python library. But then, > scope has never been formalised for IPv4 unicast. > > I'm not sure it was very clear that I was trying to make three points: 1. The Python library you're using is currently flawed, in that it claims consistency with the IPv4 and IPv6 Special-Purpose Address Registries but uses obsolete terminology. 2. The "fix" for these registries should probably come in the form of an update so that it leaves in place the unifying language intended by RFC 6890. (As a practical matter, I think obsoleting RFC 6890 may leave the RFCs it obsoletes in some nether state.) 3. Whatever term is chosen to replace "Global" should apply equally to IPv4 unicast (my preference being "Public"). Regards, Kerry Brian C > --001a1148b080ea71ab0537f715ea Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On T= ue, Jul 19, 2016 at 1:49 AM, Brian E Carpenter <brian.e.carpente= r@gmail.com> wrote:
On 19/07/2016 09:54, Kerry Lynn wrote:
> Hi Brian,
>
> I think there may be a problem with the general approach taken by this=
> draft.
>
> I certainly don't have the full context, but it seems that before = RFC 6890
> there were separate RFCs to describe IPv4 and IPv6 Special-Purpose
> Address Registries.=C2=A0 RFC 6890 obsoleted RFCs 4773, 5156, 5735, an= d
> 5736 and apparently attempted to define a set of common predicates tha= t
> would apply to both address families.
>
> I've not been able to find archived versions of the pre-RFC 6890 r= egistries,
> but many of the predicates in the current python ipaddress library, wh= ich
> claim to conform to the IPv4 and IPv6 Special-Purpose Registries, cont= ain
> terms that no longer appear (e.g. is_private, is_link_local, etc).=C2= =A0 See
> https://docs.python.org/3/library/ipaddress.htm= l.

To be specific, the one that *this* Brian tripped over was is_global= ,
which surprised me by returning False for ULAs, which are clearly defined as having global unicast scope. is_link_local is beyond dispute I think. is_private is an interesting one - I assumed the Python module author had invented it.

Python returns is_private =3D False for 100.64.0.0. I think that's a bu= g.

(The attached Python3 script may amuse you.)

>
> If we change "Global" to "Globally Routable" in th= e IPv6 registry
> http://www.iana.org/assignments/iana-= ipv6-special-registry
> without also doing so in the IPv4 registry
> http://www.iana.org/assignments/iana-= ipv4-special-registry
> then we will once again have divergent terminology and I'm not sur= e that
> is what's intended.

'Global' is an undefined property for IPv4 in the Python lib= rary. But then,
scope has never been formalised for IPv4 unicast.

I'm not sure it was very clear that I was trying = to make three points:

1. The Python library you= 9;re using is currently flawed, in that it claims
=C2=A0 =C2=A0 c= onsistency with the IPv4 and IPv6 Special-Purpose Address Registries
<= div>=C2=A0 =C2=A0 but uses obsolete terminology.

2= . The "fix" for these registries should probably come in the form= of an
=C2=A0 =C2=A0 update so that it leaves in place the unifyi= ng language intended by
=C2=A0 =C2=A0 RFC 6890. =C2=A0(As a pract= ical matter, I think obsoleting RFC 6890 may
=C2=A0 =C2=A0 leave = the RFCs it obsoletes in some nether state.)

3. Wh= atever term is chosen to replace "Global" should apply equally to=
=C2=A0 =C2=A0 IPv4 unicast (my preference being "Public&quo= t;).

Regards, Kerry

=C2=A0 =C2=A0Brian C

--001a1148b080ea71ab0537f715ea-- From nobody Tue Jul 19 00:46:29 2016 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C8CFF12DC70 for ; Tue, 19 Jul 2016 00:46:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.188 X-Spam-Level: X-Spam-Status: No, score=-3.188 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-1.287, SPF_PASS=-0.001] 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 RiSHW886uzID for ; Tue, 19 Jul 2016 00:46:26 -0700 (PDT) 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 2E46D12D0E0 for <6man@ietf.org>; Tue, 19 Jul 2016 00:46:26 -0700 (PDT) Received: from sandelman.ca (obiwan.sandelman.ca [IPv6:2607:f0b0:f:2::247]) by tuna.sandelman.ca (Postfix) with ESMTP id 11B4A20183 for <6man@ietf.org>; Tue, 19 Jul 2016 03:55:52 -0400 (EDT) Received: from obiwan.sandelman.ca (localhost [IPv6:::1]) by sandelman.ca (Postfix) with ESMTP id 12412638D1 for <6man@ietf.org>; Tue, 19 Jul 2016 03:46:25 -0400 (EDT) From: Michael Richardson To: 6man@ietf.org Subject: 2460bis - section 4.2 -- hop-by-hop option writeup. X-Attribution: mcr X-Mailer: MH-E 8.6; nmh 1.6+dev; GNU Emacs 24.5.1 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.17 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 Jul 2016 07:46:28 -0000 --=-=-= Content-Type: text/plain While I recognize that section 4 has text: NOTE: While [RFC2460] required that all nodes must examine and process the Hop-by-Hop Options header, it is now expected that nodes along a packet's delivery path only examine and process the Hop-by- Hop Options header if explicitly configured to do so. which means that most nodes will never look at the Hop-by-Hop header, I thought that section 4.2 was going to going to obsolete the discard actions-when-not-understood. Aside from making it clearer that the packets will almost never be dropped, doing so eventually 4x the number of hop-by-hop option numbes available. I think that we agreed to change this, then I guess the decision was that the NOTE: above solved it all, and we decided not to change this part? I'd prefer to change this text. I'd write: --- /tmp/k6 2016-07-19 03:43:57.287438396 -0400 +++ /tmp/k7 2016-07-19 03:45:15.751903442 -0400 @@ -1,19 +1,7 @@ - The Option Type identifiers are internally encoded such that their - highest-order two bits specify the action that must be taken if the - processing IPv6 node does not recognize the Option Type: + The Option Type identifiers were previously internally encoded such that + the highest-order two bits specified an action that must be taken if the + processing IPv6 node did not recognize the option type. + The recommended action (in the absense of an explicitely configured ACL), + is that unknown hop-by-hop options are simply skipped, and the next header + is examined. - - - 00 - skip over this option and continue processing the header. - - 01 - discard the packet. - - 10 - discard the packet and, regardless of whether or not the - packet's Destination Address was a multicast address, send an - ICMP Parameter Problem, Code 2, message to the packet's - Source Address, pointing to the unrecognized Option Type. - - 11 - discard the packet and, only if the packet's Destination - Address was not a multicast address, send an ICMP Parameter - Problem, Code 2, message to the packet's Source Address, - pointing to the unrecognized Option Type. -- Michael Richardson , Sandelman Software Works -= IPv6 IoT consulting =- --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 iQEVAwUBV43azYCLcPvd0N1lAQKl7wf+MM5tqWvo1966PUJzXBuUue7MusRmiqQ4 NzNRqh398tgy+oTxUGkHi8dBXV/SDitTdEGYjUtt8J3xsDzMs1MwgHh8+48e9SCT CEJ2JGjF4HXsL71mfiR0tpiHkBifP+FFy9hy8xpOx8EJk1pLUh/VO5eRTyZepamw mvUfvOLEh47h4DkGGI34gHabfzLPE7S9HWw0gU7pR405hrzN2SHL4rFtxI2BXxAB Fc21K5gZdg2qAYV7upamA/2B4G3xvEvxydd68T4MD+q/Tc2F5ierudhSkTX1KCmA pZPsEProGtl4yT5+s3WNrLDe//vTZ9RE4RBjqftJqr137SsKylCOKA== =uZj/ -----END PGP SIGNATURE----- --=-=-=-- From nobody Tue Jul 19 00:59:42 2016 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8EB7212D15F for ; Tue, 19 Jul 2016 00:59:40 -0700 (PDT) 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 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 ol19RL_ntCFe for ; Tue, 19 Jul 2016 00:59:39 -0700 (PDT) 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 EED5312D1B1 for ; Tue, 19 Jul 2016 00:59:38 -0700 (PDT) Received: from clairseach.fuaim.com (clairseach-high.fuaim.com [206.197.161.158]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by uillean.fuaim.com (Postfix) with ESMTP id E0A44880C2 for ; Tue, 19 Jul 2016 00:59:38 -0700 (PDT) Received: from dhcp-b3c7.meeting.ietf.org (dhcp-b3c7.meeting.ietf.org [31.133.179.199]) (using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by clairseach.fuaim.com (Postfix) with ESMTP id 5017D3280ADF for ; Tue, 19 Jul 2016 00:59:38 -0700 (PDT) Subject: Re: Comments on draft-bchv-rfc6890bis-00.txt References: <64775099-aca6-85ba-c3ee-f44694b1bdf0@gmail.com> To: 6man 6man From: Brian Haberman Message-ID: Date: Tue, 19 Jul 2016 03:59:31 -0400 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:45.0) Gecko/20100101 Thunderbird/45.2.0 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="tAwogR5heCtMjie7sWUngAoOkdU4Ttle1" Archived-At: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 Jul 2016 07:59:40 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --tAwogR5heCtMjie7sWUngAoOkdU4Ttle1 Content-Type: multipart/mixed; boundary="PaLmNSax9q1ucVpdBd9bSaDFqvQoiCCRd" From: Brian Haberman To: 6man 6man Message-ID: Subject: Re: Comments on draft-bchv-rfc6890bis-00.txt References: <64775099-aca6-85ba-c3ee-f44694b1bdf0@gmail.com> In-Reply-To: --PaLmNSax9q1ucVpdBd9bSaDFqvQoiCCRd Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Hi Kerry, On 7/19/16 2:20 AM, Kerry Lynn wrote: > On Tue, Jul 19, 2016 at 1:49 AM, Brian E Carpenter < > brian.e.carpenter@gmail.com> wrote: >=20 >> On 19/07/2016 09:54, Kerry Lynn wrote: >>> Hi Brian, >>> >>> I think there may be a problem with the general approach taken by thi= s >>> draft. >>> >>> I certainly don't have the full context, but it seems that before RFC= >> 6890 >>> there were separate RFCs to describe IPv4 and IPv6 Special-Purpose >>> Address Registries. RFC 6890 obsoleted RFCs 4773, 5156, 5735, and >>> 5736 and apparently attempted to define a set of common predicates th= at >>> would apply to both address families. >>> >>> I've not been able to find archived versions of the pre-RFC 6890 >> registries, >>> but many of the predicates in the current python ipaddress library, w= hich >>> claim to conform to the IPv4 and IPv6 Special-Purpose Registries, con= tain >>> terms that no longer appear (e.g. is_private, is_link_local, etc). S= ee >>> https://docs.python.org/3/library/ipaddress.html. >> >> To be specific, the one that *this* Brian tripped over was is_global, >> which surprised me by returning False for ULAs, which are clearly defi= ned >> as having global unicast scope. is_link_local is beyond dispute I thin= k. >> is_private is an interesting one - I assumed the Python module author = had >> invented it. >> >> Python returns is_private =3D False for 100.64.0.0. I think that's a b= ug. >> >> (The attached Python3 script may amuse you.) >> >>> >>> If we change "Global" to "Globally Routable" in the IPv6 registry >>> http://www.iana.org/assignments/iana-ipv6-special-registry >>> without also doing so in the IPv4 registry >>> http://www.iana.org/assignments/iana-ipv4-special-registry >>> then we will once again have divergent terminology and I'm not sure t= hat >>> is what's intended. I have not made any changes to the IPv4 registry based on the proposed changes. *If* someone thinks a specific change is applicable/necessary, we should consider it. Keep in mind that this document is larger in scope than just 6man though. >> >> 'Global' is an undefined property for IPv4 in the Python library. But = then, >> scope has never been formalised for IPv4 unicast. >> >> I'm not sure it was very clear that I was trying to make three points:= >=20 > 1. The Python library you're using is currently flawed, in that it clai= ms > consistency with the IPv4 and IPv6 Special-Purpose Address Registri= es > but uses obsolete terminology. Agreed, but I think some of the issue may be the way 6890 defined things WRT "global". >=20 > 2. The "fix" for these registries should probably come in the form of a= n > update so that it leaves in place the unifying language intended by= > RFC 6890. (As a practical matter, I think obsoleting RFC 6890 may > leave the RFCs it obsoletes in some nether state.) This draft wholly replaces 6890 with just the primary change of "global" to "globally reachable". The meta-data will allow the relationships between RFCs to remain. So, I don't see any issue with the state of obsoleted RFCs. >=20 > 3. Whatever term is chosen to replace "Global" should apply equally to > IPv4 unicast (my preference being "Public"). I am not sure how using "public" changes the issue, but we can discuss that during the f2f session. Regards, Brian --PaLmNSax9q1ucVpdBd9bSaDFqvQoiCCRd-- --tAwogR5heCtMjie7sWUngAoOkdU4Ttle1 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- iQEcBAEBCAAGBQJXjd3oAAoJEBOZRqCi7goqixkH/1wtkJi6Tot7ewzXfvr1mriI otJypWE26szTbZDJ9PY90hzlcSV3aFX2n6IS+eydbBcZPwGqvNL+DSZmpAjCF9+g /mEdYaeaRadWzdsv6KD5wfC0ixselZ/Adaf0F10CjmE1DVp95o4ZZBS5Lms66Q3i Am3rpKSx/CUlPi3aS/+BVW7O00aOSHldhvRoDP+UvIDNyu5SKLJ+VRJF4VHTz9D/ r8YXgLONlwKc05hC/OpnFfcmNWPiFITzSx12a67OZqfImQRwUIjBX4JjxAjPYZ1P f4bQLqZZ5jvRCvtvZwQVzKs22Q9rhrTkDrptudROw40rqrc4h7FLMxJ0O/R6HxE= =xv66 -----END PGP SIGNATURE----- --tAwogR5heCtMjie7sWUngAoOkdU4Ttle1-- From nobody Tue Jul 19 01:00:15 2016 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 24DD912D0E9 for ; Tue, 19 Jul 2016 01:00: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 E7S-MOvZefQ0 for ; Tue, 19 Jul 2016 01:00:10 -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 0D6FF12D15F for ; Tue, 19 Jul 2016 01:00:03 -0700 (PDT) Received: by mail-wm0-x235.google.com with SMTP id o80so16061598wme.1 for ; Tue, 19 Jul 2016 01:00:02 -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=VZcm3Um/qJYgWJREoMdiQt9mEvI5TCX4BxK+4nFT0Mo=; b=wvFx7KcbyByQnVpwFTItbAfXl9xvfhNJbNUH8eC/W9h+gRGP8g6mkENtZsMS9Y+GIj BpuzxNUPJhMUfc0qHMekvkfjIclfbxfQszg/TYvVFJ/CITeAHPofAjAyHnFBTgNS58TA Zl49cbT0eRC2NKpx+9m9XC4PGweETyxL42O1V0kDf3sB1TUvJTyGmGnfA9lKvABFkETD W6L5nA3GfKq3AJF+fN7UBFOiOy9ueddBrrsz2riE3k1HLucWUp6J2Bk2e564o1dl1AFC lbyniAtzn+SHOryl2rqNZYUCuX0851qCF8cEGRdLEk79vYbkPvfsAFZZhk6EOh2y2ow8 N9sQ== 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=VZcm3Um/qJYgWJREoMdiQt9mEvI5TCX4BxK+4nFT0Mo=; b=f9k46VkCFjYl5tct4DNWxuXeMJSDtDY+0XLaijX5dF/7bd7F6sg7muFk3l66ijMqJJ tU2WiG7qV5wEXdghF7s61RGPkadz2MBBJV6hcfXicuDu1+J7VPoCoikjJXAmiF74LkOO LlODgsJP7AXR+7iq2dczJYc/gHELR1NXMUxz+FAjvtDhBTk1tFvg8GIrd1xzgzUxQ47H 3N8neXbzGcXGFg6Qy2Xj7DO1OJVWw5EnL9ysNipQ8iHyPNLlqb9R8/KaClSuO7tuHqzj qaj73Zb07KYnTk/5/raw28MZkg1bVd9KG/jzCugfIgUtRC3EGcggsD9UhBZ385ufoA1J lALQ== X-Gm-Message-State: ALyK8tKwuf+WQjEMKZjXsZrfwExcIXDmdln3ItXSmNOIqnciCeMtWIWFnDWE1dPAsPeKYA== X-Received: by 10.194.59.100 with SMTP id y4mr4868727wjq.24.1468915201558; Tue, 19 Jul 2016 01:00:01 -0700 (PDT) Received: from ?IPv6:2001:67c:370:176:28cc:dc4c:9703:6781? ([2001:67c:370:176:28cc:dc4c:9703:6781]) by smtp.gmail.com with ESMTPSA id u6sm5289001wjv.16.2016.07.19.01.00.00 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 19 Jul 2016 01:00:00 -0700 (PDT) Subject: Re: Comments on draft-bchv-rfc6890bis-00.txt To: Kerry Lynn References: <64775099-aca6-85ba-c3ee-f44694b1bdf0@gmail.com> From: Brian E Carpenter Organization: University of Auckland Message-ID: Date: Tue, 19 Jul 2016 20:00:02 +1200 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.2.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Archived-At: Cc: Brian Haberman , 6man 6man X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 Jul 2016 08:00:14 -0000 Kerry, On 19/07/2016 18:20, Kerry Lynn wrote: > On Tue, Jul 19, 2016 at 1:49 AM, Brian E Carpenter < > brian.e.carpenter@gmail.com> wrote: > >> On 19/07/2016 09:54, Kerry Lynn wrote: >>> Hi Brian, >>> >>> I think there may be a problem with the general approach taken by this >>> draft. >>> >>> I certainly don't have the full context, but it seems that before RFC >> 6890 >>> there were separate RFCs to describe IPv4 and IPv6 Special-Purpose >>> Address Registries. RFC 6890 obsoleted RFCs 4773, 5156, 5735, and >>> 5736 and apparently attempted to define a set of common predicates that >>> would apply to both address families. >>> >>> I've not been able to find archived versions of the pre-RFC 6890 >> registries, >>> but many of the predicates in the current python ipaddress library, which >>> claim to conform to the IPv4 and IPv6 Special-Purpose Registries, contain >>> terms that no longer appear (e.g. is_private, is_link_local, etc). See >>> https://docs.python.org/3/library/ipaddress.html. >> >> To be specific, the one that *this* Brian tripped over was is_global, >> which surprised me by returning False for ULAs, which are clearly defined >> as having global unicast scope. is_link_local is beyond dispute I think. >> is_private is an interesting one - I assumed the Python module author had >> invented it. >> >> Python returns is_private = False for 100.64.0.0. I think that's a bug. >> >> (The attached Python3 script may amuse you.) >> >>> >>> If we change "Global" to "Globally Routable" in the IPv6 registry >>> http://www.iana.org/assignments/iana-ipv6-special-registry >>> without also doing so in the IPv4 registry >>> http://www.iana.org/assignments/iana-ipv4-special-registry >>> then we will once again have divergent terminology and I'm not sure that >>> is what's intended. >> >> 'Global' is an undefined property for IPv4 in the Python library. But then, >> scope has never been formalised for IPv4 unicast. >> >> I'm not sure it was very clear that I was trying to make three points: > > 1. The Python library you're using is currently flawed, in that it claims > consistency with the IPv4 and IPv6 Special-Purpose Address Registries > but uses obsolete terminology. After the dust has settled we can track down the author of that module to see what can be done without breaking running code. > > 2. The "fix" for these registries should probably come in the form of an > update so that it leaves in place the unifying language intended by > RFC 6890. (As a practical matter, I think obsoleting RFC 6890 may > leave the RFCs it obsoletes in some nether state.) I think that is the intention (and the side effects on older RFCs need to be checked). > > 3. Whatever term is chosen to replace "Global" should apply equally to > IPv4 unicast (my preference being "Public"). Well, as I said, the notion of unicast scope was never developed for IPv4. I would also prefer it if the "Global-bis" property was also defined for IPv4, but that isn't a decision for 6man. As for "Public" that isn't quite the same semantics as "Globally Routeable" which is really the implication of "Not (Link-Local or ULA)" in IPv6 or "Not (Link-Local or RFC1918 or RFC6598)" in IPv4. There's no very obviously correct answer for all this. I think draft-bchv-rfc6890bis-00 is a reasonable compromise. Rgds Brian C From nobody Tue Jul 19 01:36:19 2016 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6554712DC4E for ; Tue, 19 Jul 2016 01:36:15 -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 UijGcUkLUJHZ for ; Tue, 19 Jul 2016 01:36:14 -0700 (PDT) Received: from mail-wm0-x230.google.com (mail-wm0-x230.google.com [IPv6:2a00:1450:400c:c09::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 CC7C412DCD5 for ; Tue, 19 Jul 2016 01:36:13 -0700 (PDT) Received: by mail-wm0-x230.google.com with SMTP id o80so17401990wme.1 for ; Tue, 19 Jul 2016 01:36:13 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=to:from:subject:organization:message-id:date:user-agent :mime-version:content-transfer-encoding; bh=VLJfEjVCJ4xxJXyNggpY+qfK6bxXgSWsMEaDxGZ4gm4=; b=uGNqiu8w0K51vbkLGkjoTdJf1bH1wPsRfVrpPJm+Zjp4cKqipcxSviKyRQueokxdP/ upX2gHS10x+x0ShdEPl2WDuSsJfUPmXQG/LCQtlYnYYEQjrDq8D0CBAS6nzPJIX9SlHr v8liiNoKvvMid7vvxUoI8rFh6D39eYO+S5QOf3orDK+Tf5xp+tHfyHdWja6aOQ4BU3PF 7EDPF7BC9ezdg2HLVnPxVTltIZBhTYiWM2xRN8NyWWwcjkPLn3y23AkRFBS+isaQEVqQ 4FmYM0gElV0gIuJyp/DQAq0fy+1yoah9/2UBO/9puvoSCu/nkeGRYLW5HfjvbB5ndLv5 FonQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:to:from:subject:organization:message-id:date :user-agent:mime-version:content-transfer-encoding; bh=VLJfEjVCJ4xxJXyNggpY+qfK6bxXgSWsMEaDxGZ4gm4=; b=My41bKynCX7cYcsfeEMFmWUGn+gxJZ6dHLM30UbVy1q8fF6bww8dsSxLM2knhz3M6F V152BdYzRIw3MT0E7vZy6cS9mrdU8tFQYwvKy4xy92lSJlSIYe1xJncxkihno3COzbKa 3G6PbB9xuy+7oTgcCj2hZ02pvImWjmI8Vd2rqowRWSbVWbl1rZhoVTwYsjKmv+5rx+gJ wtgMO8NQHVjgADRqboYYE+N1exOQ4Xrlz6Be4thDoUXuLpyqsKOnAWT7N4ziYr0nJuFW CZ8UUkrIRrMR7uQjLzp+klqkLGajO6XtZNvIRfVNEf0H1w80X624QrezFq897WTNtT5V CDpg== X-Gm-Message-State: ALyK8tJQtHESzKlzRDjDiXejE56Scrwub7feN7ZMgzCQAsnKKY5r4KJsM3TPifWsPb57TQ== X-Received: by 10.194.206.133 with SMTP id lo5mr5084403wjc.115.1468917372003; Tue, 19 Jul 2016 01:36:12 -0700 (PDT) Received: from ?IPv6:2001:67c:370:176:28cc:dc4c:9703:6781? ([2001:67c:370:176:28cc:dc4c:9703:6781]) by smtp.gmail.com with ESMTPSA id b130sm20913834wmg.3.2016.07.19.01.36.10 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 19 Jul 2016 01:36:10 -0700 (PDT) To: 6man From: Brian E Carpenter Subject: draft-ietf-6man-default-iids and RFC4291 Organization: University of Auckland Message-ID: <16e7823a-4847-6d6b-4bda-48e0812e9e04@gmail.com> Date: Tue, 19 Jul 2016 20:36:12 +1200 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.2.0 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Archived-At: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 Jul 2016 08:36:15 -0000 If we add a citation of 4291 to draft-ietf-6man-default-iids, please note the difference that is coming soon in 4291bis: RFC4291 says For all unicast addresses, except those that start with the binary value 000, Interface IDs are required to be 64 bits long and to be constructed in Modified EUI-64 format. RFC4291bis says For all unicast addresses, except those that start with the binary value 000, Interface IDs are required to be 64 bits long. If derived from an IEEE MAC-layer address, they must be constructed in Modified EUI-64 format. That's to say, 4291bis also leaves the question open to the implementor. -- Regards Brian Carpenter (Don't blame me, I voted Remain.) From nobody Tue Jul 19 01:51:32 2016 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 93F2912DD10 for ; Tue, 19 Jul 2016 01:51:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.221 X-Spam-Level: X-Spam-Status: No, score=-4.221 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=jisc365.onmicrosoft.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 9lryzKTwOkDF for ; Tue, 19 Jul 2016 01:51:21 -0700 (PDT) Received: from eu-smtp-delivery-189.mimecast.com (eu-smtp-delivery-189.mimecast.com [207.82.80.189]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 04FB612DD03 for <6man@ietf.org>; Tue, 19 Jul 2016 01:51:20 -0700 (PDT) Received: from EUR02-VE1-obe.outbound.protection.outlook.com (mail-ve1eur02lp0054.outbound.protection.outlook.com [213.199.154.54]) (Using TLS) by eu-smtp-1.mimecast.com with ESMTP id uk-mta-44-XqDPxTnBPumihOiUABrBvw-1; Tue, 19 Jul 2016 09:51:14 +0100 X-MC-Unique: XqDPxTnBPumihOiUABrBvw-1 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=jisc365.onmicrosoft.com; s=selector1-jisc-ac-uk; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=rP23JSm1pRO5FBNYhagtaaQIXnunRDjl3USCNtNA4m8=; b=Di8wdb455qpZtnqpl7N8HPRSEM4to/CIYKHTWwlBB5MirTrirxe2d+opNqQLrbOmttdynKZMNwxBkbfHjXgM5Djn6A6i4ltll6KBleD38PoZaw931DzXeh6U/wzZSQa8McDfdB8FpLSXBZc8faSbhR6gtgoe7k8vtmzehs47wuw= Received: from AMSPR07MB455.eurprd07.prod.outlook.com (10.242.106.148) by AMSPR07MB455.eurprd07.prod.outlook.com (10.242.106.148) with Microsoft SMTP Server (TLS) id 15.1.539.14; Tue, 19 Jul 2016 08:51:13 +0000 Received: from AMSPR07MB455.eurprd07.prod.outlook.com ([10.242.106.148]) by AMSPR07MB455.eurprd07.prod.outlook.com ([10.242.106.148]) with mapi id 15.01.0539.019; Tue, 19 Jul 2016 08:51:13 +0000 From: Tim Chown To: Michael Richardson Subject: Re: 2460bis - section 4.2 -- hop-by-hop option writeup. Thread-Topic: 2460bis - section 4.2 -- hop-by-hop option writeup. Thread-Index: AQHR4ZG0ehM6npQqGEaHOAaRSnR6Q6AfcomA Date: Tue, 19 Jul 2016 08:51:13 +0000 Message-ID: <8CA80B5C-CDF5-4AFB-8117-432AD7ACB119@jisc.ac.uk> References: <26148.1468914385@obiwan.sandelman.ca> In-Reply-To: <26148.1468914385@obiwan.sandelman.ca> Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-mailer: Apple Mail (2.3124) authentication-results: spf=none (sender IP is ) smtp.mailfrom=Tim.Chown@jisc.ac.uk; x-ms-exchange-messagesentrepresentingtype: 1 x-originating-ip: [31.133.155.0] x-ms-office365-filtering-correlation-id: 7e685372-e492-4d91-92a5-08d3afb1d69f x-microsoft-exchange-diagnostics: 1; AMSPR07MB455; 20:3Habu1GRK77xyb/N935lK3oURYYMLs9A82jK5kcOmCSVaYT9xBSkhkBTkbMK9siIxJuZkln4uaMA7R8SHqAD9vr8I7fxzXvo+KROwJJDiyMhsaXLEAeIkp0JAOpGfKrn1f2NSgeigluux7g8DH1TIu60Tn9AK9TAIP8VipyM9Bs= x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:AMSPR07MB455; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:; x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(102415321)(601004)(2401047)(8121501046)(5005006)(10201501046)(3002001); SRVR:AMSPR07MB455; BCL:0; PCL:0; RULEID:; SRVR:AMSPR07MB455; x-forefront-prvs: 000800954F x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(6009001)(7916002)(189002)(51444003)(24454002)(199003)(50986999)(101416001)(50226002)(8936002)(76176999)(10400500002)(99936001)(74482002)(33656002)(2906002)(11100500001)(3280700002)(19580405001)(19580395003)(106116001)(106356001)(5002640100001)(105586002)(81166006)(81156014)(7736002)(7846002)(92566002)(8676002)(68736007)(36756003)(2900100001)(77096005)(305945005)(2950100001)(57306001)(87936001)(82746002)(66066001)(15975445007)(122556002)(83716003)(102836003)(3846002)(6116002)(86362001)(586003)(110136002)(97736004)(189998001)(3660700001)(4326007)(230783001)(7756004)(104396002); DIR:OUT; SFP:1101; SCL:1; SRVR:AMSPR07MB455; H:AMSPR07MB455.eurprd07.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; MX:1; A:1; LANG:en; received-spf: None (protection.outlook.com: jisc.ac.uk does not designate permitted sender hosts) spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: multipart/signed; boundary="Apple-Mail=_CB2F8087-5066-448A-9FD3-99694F1DA949"; protocol="application/pgp-signature"; micalg=pgp-sha512 MIME-Version: 1.0 X-OriginatorOrg: jisc.ac.uk X-MS-Exchange-CrossTenant-originalarrivaltime: 19 Jul 2016 08:51:13.2784 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 48f9394d-8a14-4d27-82a6-f35f12361205 X-MS-Exchange-Transport-CrossTenantHeadersStamped: AMSPR07MB455 Archived-At: Cc: "6man@ietf.org" <6man@ietf.org> X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 Jul 2016 08:51:31 -0000 --Apple-Mail=_CB2F8087-5066-448A-9FD3-99694F1DA949 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 Hi, > On 19 Jul 2016, at 08:46, Michael Richardson = wrote: >=20 >=20 > While I recognize that section 4 has text: >=20 > NOTE: While [RFC2460] required that all nodes must examine and > process the Hop-by-Hop Options header, it is now expected that nodes > along a packet's delivery path only examine and process the Hop-by- > Hop Options header if explicitly configured to do so. >=20 > which means that most nodes will never look at the Hop-by-Hop header, = I > thought that section 4.2 was going to going to obsolete the discard > actions-when-not-understood. Aside from making it clearer that the = packets > will almost never be dropped, doing so eventually 4x the number of = hop-by-hop > option numbes available. >=20 > I think that we agreed to change this, then I guess the decision was = that the > NOTE: above solved it all, and we decided not to change this part? > I'd prefer to change this text. I commented on this in my review also. One option is to refer to = RFC7045, since the text in 2460bis is at odds with what is said there. So perhaps what you say below, also citing RFC7045, is appropriate. Tim >=20 > I'd write: >=20 > --- /tmp/k6 2016-07-19 03:43:57.287438396 -0400 > +++ /tmp/k7 2016-07-19 03:45:15.751903442 -0400 > @@ -1,19 +1,7 @@ > - The Option Type identifiers are internally encoded such that their > - highest-order two bits specify the action that must be taken if = the > - processing IPv6 node does not recognize the Option Type: > + The Option Type identifiers were previously internally encoded = such that > + the highest-order two bits specified an action that must be taken = if the > + processing IPv6 node did not recognize the option type. > + The recommended action (in the absense of an explicitely = configured ACL), > + is that unknown hop-by-hop options are simply skipped, and the = next header > + is examined. >=20 > - > - > - 00 - skip over this option and continue processing the header. > - > - 01 - discard the packet. > - > - 10 - discard the packet and, regardless of whether or not the > - packet's Destination Address was a multicast address, send = an > - ICMP Parameter Problem, Code 2, message to the packet's > - Source Address, pointing to the unrecognized Option Type. > - > - 11 - discard the packet and, only if the packet's Destination > - Address was not a multicast address, send an ICMP = Parameter > - Problem, Code 2, message to the packet's Source Address, > - pointing to the unrecognized Option Type. >=20 >=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=_CB2F8087-5066-448A-9FD3-99694F1DA949 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 iQIcBAEBCgAGBQJXjepDAAoJELg9LkJo0sOWMGAQAJ/CGZaRFRckjTEU67wguFz0 S9QbdOVE7BcWqZ81xfFb3FdBjQ41nfdsOLRpJBWRmNNX0afqFlxRLFE3OYToJvTw A97ss08MGVBmr/A2wgohhk/+nE8hOO0diFI6/q8GE+qittqeO7JK9nmWERnftPQ4 5J6Hmu7RVayTgSk3CPgFKzbRTqnifeBaksz0PYY1m6v1JPuWrtOzo2LVlFoDayZh B9FQ6BNLtpXaDfiHKPeErz4Rh78x/nmdLBMDzbf0jVxZd4AOoHiI+kXSWaL9R8oG GrXUtDjEZxtfAraH2Vv1QP6LvaRpmatT6n8PFilXEjJTVaG95lqOalsBeEBrIQ5i t3afqWut1Hjcx9RVxgPu1Jeb6IlY1nJd4TRHtMjwF4tvtJxjRdsI5PWJW5f2Cpxk 5X0W6v22QZ4Uc12NESKg8BQf5pwLm2zliaMLA6F6lRFsLt9f798FWiuFl0zF/Me7 31t/6Mb0/6EJIqE0cv890Z8f68ES5BXlJiC0opdD20hSzKeQsxPf6qHMM6Wcp8W4 /4AeIB7Ur8vL0IIU06EjoExlQ0XM0rMuN0foi/WqQE+EUa8Yb1ml1xZ2J8jUpngT 5hcEIiauXMWVrHRJMpkN2W2OM/T/E9SgGCIkb6jwbteRKjYqTmXSuua8TP0e8a6j BSvZ8028kbeliK4qU+tj =W1pf -----END PGP SIGNATURE----- --Apple-Mail=_CB2F8087-5066-448A-9FD3-99694F1DA949-- From nobody Tue Jul 19 01:56:42 2016 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4506C12DB3F for ; Tue, 19 Jul 2016 01:56:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.987 X-Spam-Level: X-Spam-Status: No, score=-3.987 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, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-1.287, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=google.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 kPSC475A0eia for ; Tue, 19 Jul 2016 01:56:37 -0700 (PDT) Received: from mail-it0-x230.google.com (mail-it0-x230.google.com [IPv6:2607:f8b0:4001:c0b::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 532A112DD57 for <6man@ietf.org>; Tue, 19 Jul 2016 01:56:28 -0700 (PDT) Received: by mail-it0-x230.google.com with SMTP id f6so13823776ith.0 for <6man@ietf.org>; Tue, 19 Jul 2016 01:56:28 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:from:date:message-id:subject:to:cc; bh=XPlVmxT4RojdSBbijgfLiZcLEI2+W8WDYUJhXX6K/ts=; b=n9gmMERWLDJMlI3d7nHd3eUD0D7ZjDwpRW0X6bXktxpnM7ewHwsAOXNKA1zjP5+m/B UC25pe7cFSDs9cI4niNrDkvK5H1uLUAj26F3Fyu4Ev0pYNzUVBx6vkKu9lFPlYTdx75N 2SeBkm5Ufg4JuG55dvQ03npCDBsaG3Pn5npcTMoFlZzJQ6TUP/qOb76EBCt5pfXcxGuZ LaWoP8MErOl1ULnXbEFz3Y0PQJJJl8KBZYntaBB1kyhjBT89+PI/JKO/0xER7683P/Mv QxgMVEIygOK2TVx6virUMwwQIQ7hhmsZIGo+78zx+XQRUjhrDz0yoWGzhw60XxRcbus2 FdBA== 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=XPlVmxT4RojdSBbijgfLiZcLEI2+W8WDYUJhXX6K/ts=; b=ffIGeZQygHHZOsZCp43I9nnmIlywFbOuMO7hOiLt1DnJGCirLDpwiUTfbpnhOhodXP lDRNkuK836x9uvwYcW8x0zMDGE8golcbNdiK+Av8teNeK8mSLhNJuNkfl5ED8krIfO4F kduwBjopZ/6O1hrFT2IOkSGmkvhnU7jYJwxaTfYdZPI0cyfM8FNkrThyHbblXrnf++Fh mw9FeuB5prC2muk5CmOrbcK/cW9DH76mmbYHLixDm2cpqBy9cY5O5f0/qkEDDVL5gT18 VK2obLgErcnclzN5ax7j3SrjyrfUwhrgjti0O7ZzKf8VMwW+D//Ys/xKs8XQy0Y2ftWE bj0w== X-Gm-Message-State: ALyK8tJFlCaR1u1+Kli226CKsMePhVlbYE1cpdsC6K/l7sRAd1PJCqz5juzHPRdcfGNA6dWEeBWgb/kZ16nJyyfB X-Received: by 10.36.47.6 with SMTP id j6mr39946027itj.82.1468918587569; Tue, 19 Jul 2016 01:56:27 -0700 (PDT) MIME-Version: 1.0 Received: by 10.65.15.99 with HTTP; Tue, 19 Jul 2016 01:56:07 -0700 (PDT) From: Lorenzo Colitti Date: Tue, 19 Jul 2016 10:56:07 +0200 Message-ID: Subject: rfc6106bis incompatible with RFC7844 To: draft-ietf-6man-rdnss-rfc6106bis@tools.ietf.org Content-Type: multipart/alternative; boundary=001a1144130c9e52030537f94291 Archived-At: Cc: "6man@ietf.org" <6man@ietf.org> X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 Jul 2016 08:56:40 -0000 --001a1144130c9e52030537f94291 Content-Type: text/plain; charset=UTF-8 Hi, [Sending comments while the draft is blocked so we can process them before IETF last call starts. Let me know if I should wait and send this to IETF last call instead.] RFC 7844, which was recently published, says: When these options enable stateless address configuration, hosts using the anonymity profile SHOULD use stateless address configuration instead of stateful address configuration, because stateless configuration requires fewer information disclosures than stateful configuration. That text is in direct conflict with at least this text in 6106bis: The DNS options from Router Advertisements and DHCP SHOULD be stored into the DNS Repository and Resolver Repository so that information from DHCP appears there first and therefore takes precedence. Given that RFC 7844 documents recent IETF consensus, I think we need to resolve this incompatibility. Cheers, Lorenzo --001a1144130c9e52030537f94291 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hi,

[Sending comments while the draft i= s blocked so we can process them before IETF last call starts. Let me know = if I should wait and send this to IETF last call instead.]

RFC=C2=A07844, which was recently published, says:

<= /div>
=C2=A0 =C2=A0When these
=C2=A0 =C2=A0options enabl= e stateless address configuration, hosts using the
=C2=A0 =C2=A0a= nonymity profile SHOULD use stateless address configuration instead
=C2=A0 =C2=A0of stateful address configuration, because stateless config= uration
=C2=A0 =C2=A0requires fewer information disclosures than = stateful configuration.

That text is in dire= ct conflict with at least this text in 6106bis:

=C2=A0 =C2=A0The DNS options from Router Advertisements
=C2=A0= =C2=A0and DHCP SHOULD be stored into the DNS Repository and Resolver
=
=C2=A0 =C2=A0Repository so that information from DHCP appears there fi= rst and
=C2=A0 =C2=A0therefore takes precedence.
=
Given that RFC 7844 documents recent IETF consensus, I think= we need to resolve this incompatibility.

Cheers,<= /div>
Lorenzo
--001a1144130c9e52030537f94291-- From nobody Tue Jul 19 01:58:17 2016 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BF4C012DD6E for ; Tue, 19 Jul 2016 01:58:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.353 X-Spam-Level: X-Spam-Status: No, score=-5.353 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_ADSP_CUSTOM_MED=0.001, FREEMAIL_FROM=0.001, NML_ADSP_CUSTOM_MED=0.9, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_SOFTFAIL=0.665] 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 2ikg7l4njmq0 for ; Tue, 19 Jul 2016 01:58:14 -0700 (PDT) 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 3E88A12DD60 for ; Tue, 19 Jul 2016 01:58:00 -0700 (PDT) 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 u6J8vwf5005889 for ; Tue, 19 Jul 2016 10:57:58 +0200 Received: from pisaure.intra.cea.fr (localhost [127.0.0.1]) by localhost (Postfix) with SMTP id 612F72035E3 for ; Tue, 19 Jul 2016 10:57:58 +0200 (CEST) Received: from muguet2.intra.cea.fr (muguet2.intra.cea.fr [132.166.192.7]) by pisaure.intra.cea.fr (Postfix) with ESMTP id 4DFCF2035BB for ; Tue, 19 Jul 2016 10:57:58 +0200 (CEST) Received: from [132.166.84.158] ([132.166.84.158]) by muguet2.intra.cea.fr (8.15.2/8.15.2/CEAnet-Intranet-out-1.4) with ESMTP id u6J8vvgi005235 for ; Tue, 19 Jul 2016 10:57:58 +0200 Subject: IPv6-over-80211 may have more privacy issues than RFC2464 Ethernet To: IPv6 References: <563E68A2-582C-46E3-BFEF-42C0FD746101@jisc.ac.uk> From: Alexandre Petrescu Message-ID: <9ea46211-be4b-d054-766d-e6fcac001d9f@gmail.com> Date: Tue, 19 Jul 2016 10:57:55 +0200 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.2.0 MIME-Version: 1.0 In-Reply-To: <563E68A2-582C-46E3-BFEF-42C0FD746101@jisc.ac.uk> 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.17 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 Jul 2016 08:58:16 -0000 Hi, I would suggest to consider that it is on _wifi_ that there are more IP address privacy concerns, rather than on Ethernet RFC2464. I suspect that RFC2464 Ethernet Frame Format is not what gets on the wireless. On wireless we see 802.11 Data Headers not EthernetII headers. A conversion between these two headers happens in each computer, yes. The problem is that there is no RFC "IPv6-over-wifi" to patch. It would be in that fictitious document that the solution to privacy worries - e.g. random MAC or random IID - would be expressed. That is why I am saying that there is need of advice of what to put in a potential "IPv6-over-80211" new document. Alex PS: this also applies to IPv6-over-cellular networks using RFC2464 inside the computer but obviously not on the network. From nobody Tue Jul 19 02:17:02 2016 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2AC6F12DB64 for ; Tue, 19 Jul 2016 02:17:01 -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 MCWo9tle8eSQ for ; Tue, 19 Jul 2016 02:16:56 -0700 (PDT) Received: from mail-lf0-x22e.google.com (mail-lf0-x22e.google.com [IPv6:2a00:1450:4010:c07::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 1B6E712DEC0 for <6man@ietf.org>; Tue, 19 Jul 2016 02:08:41 -0700 (PDT) Received: by mail-lf0-x22e.google.com with SMTP id l69so8078220lfg.1 for <6man@ietf.org>; Tue, 19 Jul 2016 02:08:40 -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=21r3VzIMtndsJqScy77w/IhA/hj4w9zKzHkQkK0LWXY=; b=ba1hqsmyvyq8q/uDRBHPu1J0QjwwVN3yaiFQuepdS5ecPxq6bojEUITSsg+JrOYwyq hxMX4EUJSp7QIGFfYzhMwRqtGnWFHvyeiEsLax38ZL6tSSfNHvy7Ra8WFbZT18i8b1Ca oJuZnOstRphEq6I/vi5yJuIssAKvMbCYpLYJ3S0D00Rs7wmNUUnZ83YCyCmQI2Hf6XOZ gB5993getDW7iL1n3h5pLNgmCHfWsl4IKHaKa3AVnJitM9qG8/1dJqKlhlljgOYKDvJT 1xt55okdMA0zNb2GOKBuks1rlD0txv0+JsSPF3jPcYwEIXujtuww7Ho9Qq6cGnRrz+py yBHA== 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=21r3VzIMtndsJqScy77w/IhA/hj4w9zKzHkQkK0LWXY=; b=Cp3/pJf0Mx82+0Ha7o0/I11z/K40rNC+ppcDrm4aZyzYOB1PoGQ1cCVPua83+Khjpg Esbqgctu37pzZODnHk/PbMwBDV0YOFvOTkP856Z72v8UyGi8WHMXeVCFgUVCacWCTpS0 WG/2L7MHqWoDjGlXOJxwRgSG/0dSP+VAa2GeDRpyJBUTvdNhyjzj0RyZO4EFscAGF4gZ 6wHZPuBEAN8T6LEuHxeLaW6QTIvIXyrEm0nrS+bV4RBra4q5Ld9DG5fChNfrXdyg64LB Raud+4cL5a+PLIJG2jXHDnhH1erHyKvInUy+nBwTr9QBNn5X24HhD53dMmxvSDRTe2UW JRUg== X-Gm-Message-State: ALyK8tJqET2DYgNbpqFNmqVJb/LEMPG2T6FzfnRDoSnmS3Oizylu7unQLgVlyJ0SVAb0XQ== X-Received: by 10.25.38.149 with SMTP id m143mr1985637lfm.107.1468919319041; Tue, 19 Jul 2016 02:08:39 -0700 (PDT) Received: from ?IPv6:2001:67c:370:176:28cc:dc4c:9703:6781? ([2001:67c:370:176:28cc:dc4c:9703:6781]) by smtp.gmail.com with ESMTPSA id e22sm5228355lji.1.2016.07.19.02.08.37 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 19 Jul 2016 02:08:38 -0700 (PDT) Subject: Re: 2460bis - section 4.2 -- hop-by-hop option writeup. To: Tim Chown , Michael Richardson References: <26148.1468914385@obiwan.sandelman.ca> <8CA80B5C-CDF5-4AFB-8117-432AD7ACB119@jisc.ac.uk> From: Brian E Carpenter Organization: University of Auckland Message-ID: <01e5e580-6d66-9ec3-fac5-d0e28aa31a3a@gmail.com> Date: Tue, 19 Jul 2016 21:08:39 +1200 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.2.0 MIME-Version: 1.0 In-Reply-To: <8CA80B5C-CDF5-4AFB-8117-432AD7ACB119@jisc.ac.uk> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Archived-At: Cc: "6man@ietf.org" <6man@ietf.org> X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 Jul 2016 09:17:01 -0000 On 19/07/2016 20:51, Tim Chown wrote: > Hi, > >> On 19 Jul 2016, at 08:46, Michael Richardson wrote: >> >> >> While I recognize that section 4 has text: >> >> NOTE: While [RFC2460] required that all nodes must examine and >> process the Hop-by-Hop Options header, it is now expected that nodes >> along a packet's delivery path only examine and process the Hop-by- >> Hop Options header if explicitly configured to do so. >> >> which means that most nodes will never look at the Hop-by-Hop header, I >> thought that section 4.2 was going to going to obsolete the discard >> actions-when-not-understood. Aside from making it clearer that the packets >> will almost never be dropped, doing so eventually 4x the number of hop-by-hop >> option numbes available. >> >> I think that we agreed to change this, then I guess the decision was that the >> NOTE: above solved it all, and we decided not to change this part? >> I'd prefer to change this text. > > I commented on this in my review also. One option is to refer to RFC7045, since the text in 2460bis is at odds with what is said there. > > So perhaps what you say below, also citing RFC7045, is appropriate. People objected to the text in 7045 because it was basically (and intentionally) pragmatic. So the formulation in 2460bis was intentionally different than 7045. Brian > > Tim > >> >> I'd write: >> >> --- /tmp/k6 2016-07-19 03:43:57.287438396 -0400 >> +++ /tmp/k7 2016-07-19 03:45:15.751903442 -0400 >> @@ -1,19 +1,7 @@ >> - The Option Type identifiers are internally encoded such that their >> - highest-order two bits specify the action that must be taken if the >> - processing IPv6 node does not recognize the Option Type: >> + The Option Type identifiers were previously internally encoded such that >> + the highest-order two bits specified an action that must be taken if the >> + processing IPv6 node did not recognize the option type. >> + The recommended action (in the absense of an explicitely configured ACL), >> + is that unknown hop-by-hop options are simply skipped, and the next header >> + is examined. >> >> - >> - >> - 00 - skip over this option and continue processing the header. >> - >> - 01 - discard the packet. >> - >> - 10 - discard the packet and, regardless of whether or not the >> - packet's Destination Address was a multicast address, send an >> - ICMP Parameter Problem, Code 2, message to the packet's >> - Source Address, pointing to the unrecognized Option Type. >> - >> - 11 - discard the packet and, only if the packet's Destination >> - Address was not a multicast address, send an ICMP Parameter >> - Problem, Code 2, message to the packet's Source Address, >> - pointing to the unrecognized Option Type. >> >> >> -- >> 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 >> -------------------------------------------------------------------- > > > > -------------------------------------------------------------------- > IETF IPv6 working group mailing list > ipv6@ietf.org > Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 > -------------------------------------------------------------------- > From nobody Tue Jul 19 02:19:06 2016 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E3FB612DEF4 for ; Tue, 19 Jul 2016 02:19:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.347 X-Spam-Level: X-Spam-Status: No, score=-2.347 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FORGED_FROMDOMAIN=0.001, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=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 rspf4mmRQM_H for ; Tue, 19 Jul 2016 02:19:00 -0700 (PDT) Received: from mail-io0-x234.google.com (mail-io0-x234.google.com [IPv6:2607:f8b0:4001:c06::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 BFAEE12DEF6 for ; Tue, 19 Jul 2016 02:09:19 -0700 (PDT) Received: by mail-io0-x234.google.com with SMTP id m101so13473505ioi.2 for ; Tue, 19 Jul 2016 02:09:19 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to:cc; bh=OWiYoAZB78lGxqJ9ueRHf3zL8Z1idOJh0SRJ7R+tEyg=; b=zuRdtwyxaFOBb2bNLMcyTL2V69z3PtlIU1PnpyQm2kApQaXfD/KeFX6SmaXIVZdILk hS+L54aawDyLNfQW6etUNUnjJtChjyWCoUmNW4/ueZ24It6yt9M7GlgsIEML64CMtTrs 2PZuoz95PWyM0k8sv2PpX0F8gG4xojX0rLrDuG6NjBmw7dGioI1EIxCbzopZXfQXZcFU 7nmfKq7BE0I/qTQYyXajytSYxLXTMdV0lM3acKOEeicMopPN+4TyAZddgoV7Qjd5L+lD qAE1OA0q5txVZLp1B1ptfpG1KDMvnP79nCymW83MBtZym+2lfIaYAKVx6193/ytkZRf6 Ip/Q== 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:from :date:message-id:subject:to:cc; bh=OWiYoAZB78lGxqJ9ueRHf3zL8Z1idOJh0SRJ7R+tEyg=; b=KOT8NjhaqaPo4ulx9xSdSVdMULEC7D7ZYl4dTPTeBnf6dSJNdptR125PHhZhOIsFco A1mEzQG8aLBxiyaS9+qDwzBbMJO6hUX50YUDD0O9BftLSMB6Ey50Q/HNvlp4mimFZ+Hf 0i8ALejrIAb7f5YHBlXGKXC+wNL9yfZO3QtVpx2VIhcoc9ikh8UXGjALkmvzKzbw5htr nPpKHPx+TmLZhT0kNL93eW2vfp3Gf/5TIIjHPyE3vFaS0xNuDjn5gTo426LD6hsrioTW 7B3bA466RYRF0WJTNeAa8h3STSG1EEuuBokNXOatsWt6sBDULrWyeyziqLcvr2VR55Ev D9sQ== X-Gm-Message-State: ALyK8tIISEQ5+6iy0pFvhrO+IRBJu7R2eICQGBtrXOBhWftCbmqYuT8TPOL/FKerqjjOMqawtlw7ZEn9DjsySg== X-Received: by 10.107.13.70 with SMTP id 67mr13265536ion.75.1468919359008; Tue, 19 Jul 2016 02:09:19 -0700 (PDT) MIME-Version: 1.0 Sender: kerlyn2001@gmail.com Received: by 10.107.9.22 with HTTP; Tue, 19 Jul 2016 02:09:18 -0700 (PDT) In-Reply-To: References: <64775099-aca6-85ba-c3ee-f44694b1bdf0@gmail.com> From: Kerry Lynn Date: Tue, 19 Jul 2016 05:09:18 -0400 X-Google-Sender-Auth: _EGkwozvC4oxiEY7ZOA9CSMpmfQ Message-ID: Subject: Re: Comments on draft-bchv-rfc6890bis-00.txt To: Brian Haberman Content-Type: multipart/alternative; boundary=001a113ff99498f5a50537f97085 Archived-At: Cc: 6man 6man X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 Jul 2016 09:19:05 -0000 --001a113ff99498f5a50537f97085 Content-Type: text/plain; charset=UTF-8 On Tue, Jul 19, 2016 at 3:59 AM, Brian Haberman wrote: > Hi Kerry, > > On 7/19/16 2:20 AM, Kerry Lynn wrote: > > On Tue, Jul 19, 2016 at 1:49 AM, Brian E Carpenter < > > brian.e.carpenter@gmail.com> wrote: > > > >> On 19/07/2016 09:54, Kerry Lynn wrote: > >>> Hi Brian, > >>> > >>> I think there may be a problem with the general approach taken by this > >>> draft. > >>> > >>> I certainly don't have the full context, but it seems that before RFC > >> 6890 > >>> there were separate RFCs to describe IPv4 and IPv6 Special-Purpose > >>> Address Registries. RFC 6890 obsoleted RFCs 4773, 5156, 5735, and > >>> 5736 and apparently attempted to define a set of common predicates that > >>> would apply to both address families. > >>> > >>> I've not been able to find archived versions of the pre-RFC 6890 > >> registries, > >>> but many of the predicates in the current python ipaddress library, > which > >>> claim to conform to the IPv4 and IPv6 Special-Purpose Registries, > contain > >>> terms that no longer appear (e.g. is_private, is_link_local, etc). See > >>> https://docs.python.org/3/library/ipaddress.html. > >> > >> To be specific, the one that *this* Brian tripped over was is_global, > >> which surprised me by returning False for ULAs, which are clearly > defined > >> as having global unicast scope. is_link_local is beyond dispute I think. > >> is_private is an interesting one - I assumed the Python module author > had > >> invented it. > >> > >> Python returns is_private = False for 100.64.0.0. I think that's a bug. > >> > >> (The attached Python3 script may amuse you.) > >> > >>> > >>> If we change "Global" to "Globally Routable" in the IPv6 registry > >>> http://www.iana.org/assignments/iana-ipv6-special-registry > >>> without also doing so in the IPv4 registry > >>> http://www.iana.org/assignments/iana-ipv4-special-registry > >>> then we will once again have divergent terminology and I'm not sure > that > >>> is what's intended. > > I have not made any changes to the IPv4 registry based on the proposed > changes. *If* someone thinks a specific change is applicable/necessary, > we should consider it. Keep in mind that this document is larger in > scope than just 6man though. > > But RFC 6890 apparently *did* make changes to the IPv4 registry, so if we obsolete RFC 6890 do those changes remain in effect? > >> > >> 'Global' is an undefined property for IPv4 in the Python library. But > then, > >> scope has never been formalised for IPv4 unicast. > >> > >> I'm not sure it was very clear that I was trying to make three points: > > > > 1. The Python library you're using is currently flawed, in that it claims > > consistency with the IPv4 and IPv6 Special-Purpose Address Registries > > but uses obsolete terminology. > > Agreed, but I think some of the issue may be the way 6890 defined things > WRT "global". > > I haven't been able to locate a copy of the IPv4 registry as it existed before being restructured, but I infer that it used predictates like "private" and "link local" which were made obsolete by RFC 6890. > > > 2. The "fix" for these registries should probably come in the form of an > > update so that it leaves in place the unifying language intended by > > RFC 6890. (As a practical matter, I think obsoleting RFC 6890 may > > leave the RFCs it obsoletes in some nether state.) > > This draft wholly replaces 6890 with just the primary change of "global" > to "globally reachable". The meta-data will allow the relationships > between RFCs to remain. So, I don't see any issue with the state of > obsoleted RFCs. > > See above. > > > > 3. Whatever term is chosen to replace "Global" should apply equally to > > IPv4 unicast (my preference being "Public"). > > I am not sure how using "public" changes the issue, but we can discuss > that during the f2f session. > > I suspect that when the IPv4 registry was restructured, private==false became global==true. Regards, Kerry > Regards, > Brian > > > > -------------------------------------------------------------------- > IETF IPv6 working group mailing list > ipv6@ietf.org > Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 > -------------------------------------------------------------------- > > --001a113ff99498f5a50537f97085 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On T= ue, Jul 19, 2016 at 3:59 AM, Brian Haberman <brian@innovationslab= .net> wrote:
Hi Kerry,

On 7/19/16 2:20 AM, Kerry Lynn wrote:
> On Tue, Jul 19, 2016 at 1:49 AM, Brian E Carpenter <
> brian.e.carpenter@gmail= .com> wrote:
>
>> On 19/07/2016 09:54, Kerry Lynn wrote:
>>> Hi Brian,
>>>
>>> I think there may be a problem with the general approach taken= by this
>>> draft.
>>>
>>> I certainly don't have the full context, but it seems that= before RFC
>> 6890
>>> there were separate RFCs to describe IPv4 and IPv6 Special-Pur= pose
>>> Address Registries.=C2=A0 RFC 6890 obsoleted RFCs 4773, 5156, = 5735, and
>>> 5736 and apparently attempted to define a set of common predic= ates that
>>> would apply to both address families.
>>>
>>> I've not been able to find archived versions of the pre-RF= C 6890
>> registries,
>>> but many of the predicates in the current python ipaddress lib= rary, which
>>> claim to conform to the IPv4 and IPv6 Special-Purpose Registri= es, contain
>>> terms that no longer appear (e.g. is_private, is_link_local, e= tc).=C2=A0 See
>>> https://docs.python.org/3/library/ipadd= ress.html.
>>
>> To be specific, the one that *this* Brian tripped over was is_glob= al,
>> which surprised me by returning False for ULAs, which are clearly = defined
>> as having global unicast scope. is_link_local is beyond dispute I = think.
>> is_private is an interesting one - I assumed the Python module aut= hor had
>> invented it.
>>
>> Python returns is_private =3D False for 100.64.0.0. I think that&#= 39;s a bug.
>>
>> (The attached Python3 script may amuse you.)
>>
>>>
>>> If we change "Global" to "Globally Routable&quo= t; in the IPv6 registry
>>> http://www.iana.org/assignmen= ts/iana-ipv6-special-registry
>>> without also doing so in the IPv4 registry
>>> http://www.iana.org/assignmen= ts/iana-ipv4-special-registry
>>> then we will once again have divergent terminology and I'm= not sure that
>>> is what's intended.

I have not made any changes to the IPv4 registry based on the p= roposed
changes. *If* someone thinks a specific change is applicable/necessary,
we should consider it. Keep in mind that this document is larger in
scope than just 6man though.

But RFC 6890 apparently *did*= make changes to the IPv4 registry, so if
we obsolete RFC 6890 do= those changes remain in effect?
=C2=A0
>>
>> 'Global' is an undefined property for IPv4 in the Python l= ibrary. But then,
>> scope has never been formalised for IPv4 unicast.
>>
>> I'm not sure it was very clear that I was trying to make three= points:
>
> 1. The Python library you're using is currently flawed, in that it= claims
>=C2=A0 =C2=A0 =C2=A0consistency with the IPv4 and IPv6 Special-Purpose = Address Registries
>=C2=A0 =C2=A0 =C2=A0but uses obsolete terminology.

Agreed, but I think some of the issue may be the way 6890 defined th= ings
WRT "global".

I haven't been able to lo= cate a copy of the IPv4 registry as it existed before
being restr= uctured, but I infer that it used predictates like "private" and = "link
local" which were made obsolete by RFC 6890.

>
> 2. The "fix" for these registries should probably come in th= e form of an
>=C2=A0 =C2=A0 =C2=A0update so that it leaves in place the unifying lang= uage intended by
>=C2=A0 =C2=A0 =C2=A0RFC 6890.=C2=A0 (As a practical matter, I think obs= oleting RFC 6890 may
>=C2=A0 =C2=A0 =C2=A0leave the RFCs it obsoletes in some nether state.)<= br>
This draft wholly replaces 6890 with just the primary change of &quo= t;global"
to "globally reachable". The meta-data will allow the relationshi= ps
between RFCs to remain. So, I don't see any issue with the state of
obsoleted RFCs.

See above.=C2=A0
>
> 3. Whatever term is chosen to replace "Global" should apply = equally to
>=C2=A0 =C2=A0 =C2=A0IPv4 unicast (my preference being "Public"= ;).

I am not sure how using "public" changes the issue, but we= can discuss
that during the f2f session.

I suspect that when the IPv4 registry was restructure= d, private=3D=3Dfalse
became global=3D=3Dtrue.

Regards, Kerry
=C2=A0
Regards,
Brian



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


--001a113ff99498f5a50537f97085-- From nobody Tue Jul 19 02:21:15 2016 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DEB3C12DDFB for ; Tue, 19 Jul 2016 02:21:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -15.808 X-Spam-Level: X-Spam-Status: No, score=-15.808 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.287, 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 igsmGx1wM4CK for ; Tue, 19 Jul 2016 02:21:08 -0700 (PDT) Received: from alln-iport-3.cisco.com (alln-iport-3.cisco.com [173.37.142.90]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D42AE12DDFC for <6man@ietf.org>; Tue, 19 Jul 2016 02:10:14 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1570; q=dns/txt; s=iport; t=1468919414; x=1470129014; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=1f1ClhE3GSoXYMYO/Y3/g8oOPw1SZw//pMJ+nZ+Jswg=; b=AC3T/Aupitb0qlOVLSBLSwm65H/r9lHmdM73EYYBBBWJQpm5iSOJllNe 4365PoarePSmyS5wIE1UoXdRY3V2/zzR+xYExNi6bWZaTkQi1Aw/34hZ7 +Wn4GU31ByRQ3MHe4i6k32Q2z0z1BhEmwvSMbiV7JVrpY5PksncRYUl9U 4=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0BUAgBW7Y1X/5BdJa1bgz9WfLhlgXoih?= =?us-ascii?q?XgCgTE4FAEBAQEBAQFlJ4RcAQEEAQEBODQLBQsCAQgYHhAnCyUCBA4FiCgIDr0?= =?us-ascii?q?lAQEBAQEBAQEBAQEBAQEBAQEBAQEBFwWIIoJVgTmDB4Msgi8FiB+RBQGOYY83k?= =?us-ascii?q?B0BHjaCGIFbbogQAQEB?= X-IronPort-AV: E=Sophos;i="5.28,388,1464652800"; d="scan'208";a="298817050" Received: from rcdn-core-8.cisco.com ([173.37.93.144]) by alln-iport-3.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 19 Jul 2016 09:10:14 +0000 Received: from XCH-RCD-003.cisco.com (xch-rcd-003.cisco.com [173.37.102.13]) by rcdn-core-8.cisco.com (8.14.5/8.14.5) with ESMTP id u6J9AD4i024386 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Tue, 19 Jul 2016 09:10:14 GMT Received: from xch-aln-003.cisco.com (173.36.7.13) by XCH-RCD-003.cisco.com (173.37.102.13) with Microsoft SMTP Server (TLS) id 15.0.1210.3; Tue, 19 Jul 2016 04:10:13 -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.1210.000; Tue, 19 Jul 2016 04:10:13 -0500 From: "Bernie Volz (volz)" To: Lorenzo Colitti Subject: Re: rfc6106bis incompatible with RFC7844 Thread-Topic: rfc6106bis incompatible with RFC7844 Thread-Index: AQHR4Zt/uso17U4kq0aZsbg3GzLdD6Afd38E Date: Tue, 19 Jul 2016 09:10:13 +0000 Message-ID: <2B7003A8-06A8-4CE5-8FFA-5CB2643F84E9@cisco.com> References: 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 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Cc: "6man@ietf.org" <6man@ietf.org>, "draft-ietf-6man-rdnss-rfc6106bis@tools.ietf.org" X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 Jul 2016 09:21:13 -0000 Lorenzo: I don't see a conflict here. If a host uses both methods, dhcp should be pr= eferred for dns options. If it uses only SLAAC then there is no dhcp suppli= ed data. - Bernie (from iPhone) > On Jul 19, 2016, at 10:56 AM, Lorenzo Colitti wrote: >=20 > Hi, >=20 > [Sending comments while the draft is blocked so we can process them befor= e IETF last call starts. Let me know if I should wait and send this to IETF= last call instead.] >=20 > RFC 7844, which was recently published, says: >=20 > When these > options enable stateless address configuration, hosts using the > anonymity profile SHOULD use stateless address configuration instead > of stateful address configuration, because stateless configuration > requires fewer information disclosures than stateful configuration. >=20 > That text is in direct conflict with at least this text in 6106bis: >=20 > The DNS options from Router Advertisements > and DHCP SHOULD be stored into the DNS Repository and Resolver > Repository so that information from DHCP appears there first and > therefore takes precedence. >=20 > Given that RFC 7844 documents recent IETF consensus, I think we need to r= esolve this incompatibility. >=20 > Cheers, > Lorenzo > -------------------------------------------------------------------- > IETF IPv6 working group mailing list > ipv6@ietf.org > Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 > -------------------------------------------------------------------- From nobody Tue Jul 19 02:27:43 2016 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B2A1312DDCB for ; Tue, 19 Jul 2016 02:27:41 -0700 (PDT) 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 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 2Ly6NuE4Fd7V for ; Tue, 19 Jul 2016 02:27:39 -0700 (PDT) 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 9B75A12DE8A for ; Tue, 19 Jul 2016 02:15:40 -0700 (PDT) Received: from clairseach.fuaim.com (clairseach-high.fuaim.com [206.197.161.158]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by uillean.fuaim.com (Postfix) with ESMTP id 8D47A880D1 for ; Tue, 19 Jul 2016 02:15:40 -0700 (PDT) Received: from dhcp-b3c7.meeting.ietf.org (unknown [IPv6:2001:67c:370:176:88e:1d5a:508e:55a2]) (using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by clairseach.fuaim.com (Postfix) with ESMTP id 01E4E3280ADF for ; Tue, 19 Jul 2016 02:15:39 -0700 (PDT) Subject: Re: Comments on draft-bchv-rfc6890bis-00.txt References: <64775099-aca6-85ba-c3ee-f44694b1bdf0@gmail.com> To: "ipv6@ietf.org" From: Brian Haberman Message-ID: Date: Tue, 19 Jul 2016 05:15:32 -0400 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:45.0) Gecko/20100101 Thunderbird/45.2.0 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="GqcKcmsrsEF9NDP803AHpW47JLMSvk93u" Archived-At: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 Jul 2016 09:27:42 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --GqcKcmsrsEF9NDP803AHpW47JLMSvk93u Content-Type: multipart/mixed; boundary="hg8erK8BnNHMMH4NNfprHE3POwKgW5FTS" From: Brian Haberman To: "ipv6@ietf.org" Message-ID: Subject: Re: Comments on draft-bchv-rfc6890bis-00.txt References: <64775099-aca6-85ba-c3ee-f44694b1bdf0@gmail.com> In-Reply-To: --hg8erK8BnNHMMH4NNfprHE3POwKgW5FTS Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Hi Kerry, On 7/19/16 5:09 AM, Kerry Lynn wrote: > On Tue, Jul 19, 2016 at 3:59 AM, Brian Haberman > wrote: >=20 >> Hi Kerry, >> >> On 7/19/16 2:20 AM, Kerry Lynn wrote: >>> On Tue, Jul 19, 2016 at 1:49 AM, Brian E Carpenter < >>> brian.e.carpenter@gmail.com> wrote: >>> >>>> On 19/07/2016 09:54, Kerry Lynn wrote: >>>>> Hi Brian, >>>>> >>>>> I think there may be a problem with the general approach taken by t= his >>>>> draft. >>>>> >>>>> I certainly don't have the full context, but it seems that before R= FC >>>> 6890 >>>>> there were separate RFCs to describe IPv4 and IPv6 Special-Purpose >>>>> Address Registries. RFC 6890 obsoleted RFCs 4773, 5156, 5735, and >>>>> 5736 and apparently attempted to define a set of common predicates = that >>>>> would apply to both address families. >>>>> >>>>> I've not been able to find archived versions of the pre-RFC 6890 >>>> registries, >>>>> but many of the predicates in the current python ipaddress library,= >> which >>>>> claim to conform to the IPv4 and IPv6 Special-Purpose Registries, >> contain >>>>> terms that no longer appear (e.g. is_private, is_link_local, etc). = See >>>>> https://docs.python.org/3/library/ipaddress.html. >>>> >>>> To be specific, the one that *this* Brian tripped over was is_global= , >>>> which surprised me by returning False for ULAs, which are clearly >> defined >>>> as having global unicast scope. is_link_local is beyond dispute I th= ink. >>>> is_private is an interesting one - I assumed the Python module autho= r >> had >>>> invented it. >>>> >>>> Python returns is_private =3D False for 100.64.0.0. I think that's a= bug. >>>> >>>> (The attached Python3 script may amuse you.) >>>> >>>>> >>>>> If we change "Global" to "Globally Routable" in the IPv6 registry >>>>> http://www.iana.org/assignments/iana-ipv6-special-registry >>>>> without also doing so in the IPv4 registry >>>>> http://www.iana.org/assignments/iana-ipv4-special-registry >>>>> then we will once again have divergent terminology and I'm not sure= >> that >>>>> is what's intended. >> >> I have not made any changes to the IPv4 registry based on the proposed= >> changes. *If* someone thinks a specific change is applicable/necessary= , >> we should consider it. Keep in mind that this document is larger in >> scope than just 6man though. >> >> But RFC 6890 apparently *did* make changes to the IPv4 registry, so if= > we obsolete RFC 6890 do those changes remain in effect? >=20 Yes. All the registry changes made in 6890 are carried over in this draft modulo the changes I mentioned to the ULA entry and the TEREDO entry (to address a filed erratum). >=20 >>>> >>>> 'Global' is an undefined property for IPv4 in the Python library. Bu= t >> then, >>>> scope has never been formalised for IPv4 unicast. >>>> >>>> I'm not sure it was very clear that I was trying to make three point= s: >>> >>> 1. The Python library you're using is currently flawed, in that it cl= aims >>> consistency with the IPv4 and IPv6 Special-Purpose Address Regist= ries >>> but uses obsolete terminology. >> >> Agreed, but I think some of the issue may be the way 6890 defined thin= gs >> WRT "global". >> >> I haven't been able to locate a copy of the IPv4 registry as it existe= d > before > being restructured, but I infer that it used predictates like "private"= and > "link > local" which were made obsolete by RFC 6890. I am not sure of that, but I can ask a few of the co-authors since they work for IANA. >=20 >> >>> 2. The "fix" for these registries should probably come in the form of= an >>> update so that it leaves in place the unifying language intended = by >>> RFC 6890. (As a practical matter, I think obsoleting RFC 6890 ma= y >>> leave the RFCs it obsoletes in some nether state.) >> >> This draft wholly replaces 6890 with just the primary change of "globa= l" >> to "globally reachable". The meta-data will allow the relationships >> between RFCs to remain. So, I don't see any issue with the state of >> obsoleted RFCs. >> >> See above. >=20 >>> >>> 3. Whatever term is chosen to replace "Global" should apply equally t= o >>> IPv4 unicast (my preference being "Public"). >> >> I am not sure how using "public" changes the issue, but we can discuss= >> that during the f2f session. >> >> I suspect that when the IPv4 registry was restructured, private=3D=3Df= alse > became global=3D=3Dtrue. No. For example, the 10/8 entry has Global =3D False. Regards, Brian --hg8erK8BnNHMMH4NNfprHE3POwKgW5FTS-- --GqcKcmsrsEF9NDP803AHpW47JLMSvk93u Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- iQEcBAEBCAAGBQJXje+6AAoJEBOZRqCi7goqFmcIANcBJERgb/2M/0VtoDgbsPSm 2A8NwIOKN//g5mvA+9uJe5zp1XoJ/wcrN6tB9LfM14hTIgkQap7M0UmVjLbFTG4m 88LVHOuzec7X1QVrxq4g695H9LTz8Ahhz64M5jJXX3B6pALXSuovC6VqaXl4W9Yc tb4TsAKrB2XKKV2bi0nSANLTNOQpkGUB0QXuz2UFNj5y9dPEXp/IEJkz0FGxGIqg bjuDbaQJJ0mtRjmK0LZnhQfo2sxIlJ2BcGgz9nkpVgFzqBP7O5u4savZngEsOZec H1AIvvTPCs06maKZHutbNTxqizzqyuj4uVP/9OlrJv7mHWCoNYmtsNKOb6Cc5oM= =rZbl -----END PGP SIGNATURE----- --GqcKcmsrsEF9NDP803AHpW47JLMSvk93u-- From nobody Tue Jul 19 02:32:43 2016 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CB5FA12DF1A for ; Tue, 19 Jul 2016 02:32:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.347 X-Spam-Level: X-Spam-Status: No, score=-2.347 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FORGED_FROMDOMAIN=0.001, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=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 a6Qm5M0U_ZdV for ; Tue, 19 Jul 2016 02:32:40 -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 6B8CB12DDB5 for ; Tue, 19 Jul 2016 02:22:52 -0700 (PDT) Received: by mail-io0-x233.google.com with SMTP id 38so13834822iol.0 for ; Tue, 19 Jul 2016 02:22:52 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to:cc; bh=qaxrQan91Obja765qQckRPRSvHQoOTi5XbgvqBqRVWM=; b=oBuZdTazW3KeTturIUg06qyrZY9hBGfMRxrDBXkjoM76JkhOG68t4EsrSTxceX1rPt Ilw4nWCDkLLtI4fdzLN8mhw8AnHm7k9NMFz7hPF5pI+O7OTR3iLfwYDd15Sg9HelhvVJ 6vg/6d9tvi8tERxNHSeKOJoyC6eBfsY+ACCdXsKnxeSeyfwsstrtkvodDG/hbJtqWigV lbXfvKz4uFoTYOSq7ndUVCVJAigPdqp+tp9uagSMOg8JFVxXQWrySCqs8G27TARyQMxn zlvhG2WeJoVOox+MScQzILaBzP6oUhdPLQX6B2nxhLt/V872uH+SGiaYS9Rzf5WXhEf9 ktkw== 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:from :date:message-id:subject:to:cc; bh=qaxrQan91Obja765qQckRPRSvHQoOTi5XbgvqBqRVWM=; b=VCyRUw7E+llb78B2h0LzfqlecqqMhg6jKEjUZWlPJm/HlBBjTa27yyui6Vy9+0z3Q1 Z402scyiXigIfC4musLnM/umcKvX6YgfTvbK71XSL4ByGrD94shznBwKl+5DH1SAlBsu ee4rOXxX9aqqc663Dvjl4nHY1G+KX1OetZWebJDNlBnQvUt5MnlRRhjewaqWzfmQyM/3 Rp3/UhxG6YMMIV8Ho0F72AuqD+dOdmY/JQouM6NhM/3J2Fw6jdIJ3mFE9fbd6HaZ11FR uLdrB4hGPXrkYiPQJFn3bDVnmWaldx+GRgoPlPYjv7be0ihazL9UU7oBlyP+M0hos61i XvBg== X-Gm-Message-State: ALyK8tK3QgpQlqvU+nEmXmxBXvaGXCxp7393Q9UN5Im1f7DZck1dnhGIyZzcZL6okSnfhk8namHrtdWhzY/D6w== X-Received: by 10.107.171.2 with SMTP id u2mr619553ioe.111.1468920171823; Tue, 19 Jul 2016 02:22:51 -0700 (PDT) MIME-Version: 1.0 Sender: kerlyn2001@gmail.com Received: by 10.107.9.22 with HTTP; Tue, 19 Jul 2016 02:22:51 -0700 (PDT) In-Reply-To: <16e7823a-4847-6d6b-4bda-48e0812e9e04@gmail.com> References: <16e7823a-4847-6d6b-4bda-48e0812e9e04@gmail.com> From: Kerry Lynn Date: Tue, 19 Jul 2016 05:22:51 -0400 X-Google-Sender-Auth: FwqE_W0M5VeOfioRTHmLcGvoM6o Message-ID: Subject: Re: draft-ietf-6man-default-iids and RFC4291 To: Brian E Carpenter Content-Type: multipart/alternative; boundary=94eb2c05ea7e0b87360537f9a1b0 Archived-At: Cc: 6man X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 Jul 2016 09:32:42 -0000 --94eb2c05ea7e0b87360537f9a1b0 Content-Type: text/plain; charset=UTF-8 On Tue, Jul 19, 2016 at 4:36 AM, Brian E Carpenter < brian.e.carpenter@gmail.com> wrote: > If we add a citation of 4291 to draft-ietf-6man-default-iids, please > note the difference that is coming soon in 4291bis: > > RFC4291 says > For all unicast addresses, except those that start with the binary > value 000, Interface IDs are required to be 64 bits long and to be > constructed in Modified EUI-64 format. > > RFC4291bis says > For all unicast addresses, except those that start with the binary > value 000, Interface IDs are required to be 64 bits long. If derived > from an IEEE MAC-layer address, they must be constructed in Modified > EUI-64 format. > > The interesting wrinkle here is how one interprets the phrase "IEEE MAC- layer address". I get the sense that many people interpret this as a 48-bit hardware address with the U/L bit set to zero. The point that Pascal made at the mic is that 6LoWPAN (and other 6lo IPv6-over-foo specs) specify a method for generating an IID by first creating a locally assigned 48-bit MAC-layer address by right justifying a short locally assigned L2 address in a field of zeros, setting the U/L bit to one, then using this as the basis for forming a Modified EUI-64 according to RFC4291 Appendix A. I don't see the RFC4291bis language as affecting this approach. Regards, Kerry > That's to say, 4291bis also leaves the question open to the implementor. > > -- > Regards > Brian Carpenter > (Don't blame me, I voted Remain.) > > > -------------------------------------------------------------------- > IETF IPv6 working group mailing list > ipv6@ietf.org > Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 > -------------------------------------------------------------------- > --94eb2c05ea7e0b87360537f9a1b0 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On T= ue, Jul 19, 2016 at 4:36 AM, Brian E Carpenter <brian.e.carpente= r@gmail.com> wrote:
If we a= dd a citation of 4291 to draft-ietf-6man-default-iids, please
note the difference that is coming soon in 4291bis:

RFC4291 says
=C2=A0 =C2=A0For all unicast addresses, except those that start with the bi= nary
=C2=A0 =C2=A0value 000, Interface IDs are required to be 64 bits long and t= o be
=C2=A0 =C2=A0constructed in Modified EUI-64 format.

RFC4291bis says
=C2=A0 =C2=A0For all unicast addresses, except those that start with the bi= nary
=C2=A0 =C2=A0value 000, Interface IDs are required to be 64 bits long.=C2= =A0 If derived
=C2=A0 =C2=A0from an IEEE MAC-layer address, they must be constructed in Mo= dified
=C2=A0 =C2=A0EUI-64 format.

The interesting wrinkle here is how one interprets th= e phrase "IEEE MAC-
layer address".=C2=A0 I get the sen= se that many people interpret this as a 48-bit
hardware address w= ith the U/L bit set to zero.

The point that Pascal= made at the mic is that 6LoWPAN (and other 6lo
IPv6-over-foo spe= cs) specify a method for generating an IID by first
creating a lo= cally assigned 48-bit MAC-layer address by right justifying
a sho= rt locally assigned L2 address in a field of zeros, setting the U/L bit
to one, then using this as the basis for forming a Modified EUI-64
according to RFC4291 Appendix A.

I don= 9;t see the RFC4291bis language as affecting this approach.

<= /div>
Regards, Kerry
=C2=A0
That's to say, 4291bis also leaves the question open to the implementor= .

--
Regards
=C2=A0 =C2=A0Brian Carpenter
=C2=A0 =C2=A0(Don't blame me, I voted Remain.)


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

--94eb2c05ea7e0b87360537f9a1b0-- From nobody Tue Jul 19 02:35:09 2016 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B1F2012DDE5 for ; Tue, 19 Jul 2016 02:35:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.987 X-Spam-Level: X-Spam-Status: No, score=-3.987 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, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-1.287, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=google.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 0L5axcx3yAut for ; Tue, 19 Jul 2016 02:35:03 -0700 (PDT) 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 CE09112DE56 for <6man@ietf.org>; Tue, 19 Jul 2016 02:26:41 -0700 (PDT) Received: by mail-io0-x232.google.com with SMTP id 38so13902936iol.0 for <6man@ietf.org>; Tue, 19 Jul 2016 02:26:41 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=aDixXIJSe3ySBN8CxWrhMe/U24q89hEB2TrSi05YRMI=; b=Hc+M1qwcSgLVdPJvu3JwQsY0Vl9PfgEkN5b3y67bBRnPZ53WXj+Gxoqabnf2ldrdV3 og8C0dkrbA+y3zu1s9vYd1K2ve9tiIBmxk5BHHSMpycjCl4AqVl8iqVlKH7xUAXSCp2O kCdqwZ24AOrI+agh+FwqmQ+SklcrFTuO1z6qlYCGA0aTEcI86cT+AbZJPjQPdBOtZnYD dzqzTWOxsl1C3RkbhJzUUErfbltJSxtttj6QzDbDM8VrCbOio/APxcUy+nTUYrjxgybi cvNOW0wsQY51RCTgX1Ry4L1iYJkmGdlbimiSzn7c4mFYdS1AFzV05EWqOFn88pyXP8B7 aOeA== 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=aDixXIJSe3ySBN8CxWrhMe/U24q89hEB2TrSi05YRMI=; b=Cn0XjEzDamoFkuScihDxR+V+7CMc1mdIOubaalDJ8lkio08iLp6DdpOt5tPXEeVkoZ Iq+aBKRCNakkDirAtxHv7ZqzjmTQqt8Z9cltOa3DzpJAvhylqPnMQ4x4e9ceGHYzVZXv Fuu/bsWNGuWyWzp5ozmKINVkHFSXskxI25QVFFX0B/GCe7FdmBJJ2pP5CW5ihYqHcFdZ uGr9ZfgtaeqEHGGRR/rh32c5FPEENP38yuQev409Sa2nB6Jkb8j/CRdMkn76mYP7KjUV DxzLupnZHRROcrfltOAJIWNZyEZENQMG9LvMkVOSpIuwecRd0Fokdh3hFORkfRQCwSWf J8YQ== X-Gm-Message-State: ALyK8tKmXyQpouJSCM5YgIMCOru6KuyMmGs2VUHJjDOPJZkZJtXkzCU6o/dMxSK9QGCcNxDSpC0Nq8G1FJ9825Dv X-Received: by 10.107.50.3 with SMTP id y3mr9794064ioy.94.1468920401038; Tue, 19 Jul 2016 02:26:41 -0700 (PDT) MIME-Version: 1.0 Received: by 10.65.15.99 with HTTP; Tue, 19 Jul 2016 02:26:21 -0700 (PDT) In-Reply-To: <2B7003A8-06A8-4CE5-8FFA-5CB2643F84E9@cisco.com> References: <2B7003A8-06A8-4CE5-8FFA-5CB2643F84E9@cisco.com> From: Lorenzo Colitti Date: Tue, 19 Jul 2016 11:26:21 +0200 Message-ID: Subject: Re: rfc6106bis incompatible with RFC7844 To: "Bernie Volz (volz)" Content-Type: multipart/alternative; boundary=001a11446db6b57f760537f9ae1c Archived-At: Cc: "6man@ietf.org" <6man@ietf.org>, "draft-ietf-6man-rdnss-rfc6106bis@tools.ietf.org" X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 Jul 2016 09:35:08 -0000 --001a11446db6b57f760537f9ae1c Content-Type: text/plain; charset=UTF-8 Then we should probably note that hosts using the anonymity protocol will prefer stateless address configuration, and thus may not start DHCP at all if they receive DNS information from the RA. Otherwise, a network administrator may configure both DHCPv6 and RDNSS for DNS information thinking that hosts will prefer DHCPv6, and then find that the hosts just don't use DHCPv6 at all because they already have DNS servers. On Tue, Jul 19, 2016 at 11:10 AM, Bernie Volz (volz) wrote: > Lorenzo: > > I don't see a conflict here. If a host uses both methods, dhcp should be > preferred for dns options. If it uses only SLAAC then there is no dhcp > supplied data. > > - Bernie (from iPhone) > > > On Jul 19, 2016, at 10:56 AM, Lorenzo Colitti > wrote: > > > > Hi, > > > > [Sending comments while the draft is blocked so we can process them > before IETF last call starts. Let me know if I should wait and send this to > IETF last call instead.] > > > > RFC 7844, which was recently published, says: > > > > When these > > options enable stateless address configuration, hosts using the > > anonymity profile SHOULD use stateless address configuration instead > > of stateful address configuration, because stateless configuration > > requires fewer information disclosures than stateful configuration. > > > > That text is in direct conflict with at least this text in 6106bis: > > > > The DNS options from Router Advertisements > > and DHCP SHOULD be stored into the DNS Repository and Resolver > > Repository so that information from DHCP appears there first and > > therefore takes precedence. > > > > Given that RFC 7844 documents recent IETF consensus, I think we need to > resolve this incompatibility. > > > > Cheers, > > Lorenzo > > -------------------------------------------------------------------- > > IETF IPv6 working group mailing list > > ipv6@ietf.org > > Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 > > -------------------------------------------------------------------- > --001a11446db6b57f760537f9ae1c Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Then we should probably note that hosts using the anonymit= y protocol will prefer stateless address configuration, and thus may not st= art DHCP at all if they receive DNS information from the RA.

=
Otherwise, a network administrator may configure both DHCPv6 and RDNSS= for DNS information thinking that hosts will prefer DHCPv6, and then find = that the hosts just don't use DHCPv6 at all because they already have D= NS servers.

On Tue, Jul 19, 2016 at 11:10 AM, Bernie Volz (volz) <volz@cisco.com> wrote:
Lorenzo:

I don't see a conflict here. If a host uses both methods, dhcp should b= e preferred for dns options. If it uses only SLAAC then there is no dhcp su= pplied data.

- Bernie (from iPhone)

> On Jul 19, 2016, at 10:56 AM, Lorenzo Colitti <lorenzo@google.com> wrote:
>
> Hi,
>
> [Sending comments while the draft is blocked so we can process them be= fore IETF last call starts. Let me know if I should wait and send this to I= ETF last call instead.]
>
> RFC 7844, which was recently published, says:
>
>=C2=A0 =C2=A0 When these
>=C2=A0 =C2=A0 options enable stateless address configuration, hosts usi= ng the
>=C2=A0 =C2=A0 anonymity profile SHOULD use stateless address configurat= ion instead
>=C2=A0 =C2=A0 of stateful address configuration, because stateless conf= iguration
>=C2=A0 =C2=A0 requires fewer information disclosures than stateful conf= iguration.
>
> That text is in direct conflict with at least this text in 6106bis: >
>=C2=A0 =C2=A0 The DNS options from Router Advertisements
>=C2=A0 =C2=A0 and DHCP SHOULD be stored into the DNS Repository and Res= olver
>=C2=A0 =C2=A0 Repository so that information from DHCP appears there fi= rst and
>=C2=A0 =C2=A0 therefore takes precedence.
>
> Given that RFC 7844 documents recent IETF consensus, I think we need t= o resolve this incompatibility.
>
> Cheers,
> Lorenzo
> ----------------------------------------------------------= ----------
> IETF IPv6 working group mailing list
> ipv6@ietf.org
> Administrative Requests: https://www.ietf.org/mailman= /listinfo/ipv6
> --------------------------------------------------------------------

--001a11446db6b57f760537f9ae1c-- From nobody Tue Jul 19 02:37:23 2016 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 384A812DF4B for ; Tue, 19 Jul 2016 02:37:19 -0700 (PDT) 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 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 UUILdMIjRmz2 for ; Tue, 19 Jul 2016 02:37:17 -0700 (PDT) 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 6E4C612DFB1 for ; Tue, 19 Jul 2016 02:29:16 -0700 (PDT) Received: from [IPv6:2001:67c:370:160:829:75a1:d800:dc03] (unknown [IPv6:2001:67c:370:160:829:75a1:d800:dc03]) (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 0E628825CA; Tue, 19 Jul 2016 11:29:14 +0200 (CEST) Subject: Re: draft-ietf-6man-default-iids and RFC4291 To: Brian E Carpenter , 6man References: <16e7823a-4847-6d6b-4bda-48e0812e9e04@gmail.com> From: Fernando Gont Message-ID: <578DF296.3010007@si6networks.com> Date: Tue, 19 Jul 2016 11:27:50 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.8.0 MIME-Version: 1.0 In-Reply-To: <16e7823a-4847-6d6b-4bda-48e0812e9e04@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.17 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 Jul 2016 09:37:19 -0000 On 07/19/2016 10:36 AM, Brian E Carpenter wrote: > If we add a citation of 4291 to draft-ietf-6man-default-iids, please > note the difference that is coming soon in 4291bis: > > RFC4291 says > For all unicast addresses, except those that start with the binary > value 000, Interface IDs are required to be 64 bits long and to be > constructed in Modified EUI-64 format. > > RFC4291bis says > For all unicast addresses, except those that start with the binary > value 000, Interface IDs are required to be 64 bits long. If derived > from an IEEE MAC-layer address, they must be constructed in Modified > EUI-64 format. > > That's to say, 4291bis also leaves the question open to the implementor. FWIW, I think 4291bis should actualy reference default-iids here. Thanks, -- Fernando Gont SI6 Networks e-mail: fgont@si6networks.com PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492 From nobody Tue Jul 19 02:37:59 2016 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 92A4F12DEE1 for ; Tue, 19 Jul 2016 02:37:56 -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 wYqzcqmjpJwG for ; Tue, 19 Jul 2016 02:37:52 -0700 (PDT) Received: from mail-lf0-x22a.google.com (mail-lf0-x22a.google.com [IPv6:2a00:1450:4010: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 13FDE12DEDD for ; Tue, 19 Jul 2016 02:29:47 -0700 (PDT) Received: by mail-lf0-x22a.google.com with SMTP id g62so8550846lfe.3 for ; Tue, 19 Jul 2016 02:29:46 -0700 (PDT) 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-transfer-encoding; bh=FxjyUdNESFh+iajpbZG6ukrRZAEQF4AmDbtaXXGBY28=; b=sZ+HYjgrKvdSKaCQ1D5Lcar59AOjQb5Gh3WSbtjrkMC6BCPYLXI4hqj57Jl8IWoAw7 r4DJsDWdF2At3bLDgR+n9Cg+4pzCxqeepmsxHiMbfsLx93xBY6f7cjzACaFbB9F1f75U RKGs/N6ZBBgZygS0iEvJ9Wcs0uIwtXqt2cUF8xeN3WYC1nyifFYPkjc9TZrrMvEURybD DsmDy3mXUxsri+v9iqLiSwVKkQgpaRpXCnzdX6koPBI0F8nlVmrloo/DXdoaqG374f/3 Bo72ds9bO4gJmSicOdvhhMR3wcnVHOA30Pp2jTrkRl8TX863AJegEir364z/FXrRJ46X GsUQ== 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-transfer-encoding; bh=FxjyUdNESFh+iajpbZG6ukrRZAEQF4AmDbtaXXGBY28=; b=L0LOTxHyWDt6D4c6Hnfnxn/hRIJ2CGghRe9ywDDo7kDVpP6sr/E7fenUVYQzSdBxhQ +y3Ed0NUoFL7/RUo1qkn+BpJ7exBweCv0hlnudOPk7ThTFYpQGESzpbMAMW9peA43iFn 3fdzZXjwCQ3PqJte4Lb5R7dpsbrioutpdn+kmwAHD89zufGEi00ItFxVqHJzjrW41ZO5 ErT0zeE1/jELJUG0Qu5/8IlYiuo+pBLV7r8wHjeTmOGnrZyWWZBF8p4mAV7kfzYPUd/F j4xX5VHEKD9ouInZ+ngW0ikNLBJJdflR/KMvj898F9Te/aeHiMSVYkmXqGGndPNFy7tg /btg== X-Gm-Message-State: ALyK8tLr394XlCeDv+FwnAbsJ0Rsmv028R+CBNCk0BsS8ftctl5vLRZHmXhD3nkyAUgwkg== X-Received: by 10.25.28.16 with SMTP id c16mr3626564lfc.79.1468920584889; Tue, 19 Jul 2016 02:29:44 -0700 (PDT) Received: from ?IPv6:2001:67c:370:176:28cc:dc4c:9703:6781? ([2001:67c:370:176:28cc:dc4c:9703:6781]) by smtp.gmail.com with ESMTPSA id g42sm145082lji.40.2016.07.19.02.29.43 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 19 Jul 2016 02:29:43 -0700 (PDT) Subject: Re: IPv6-over-80211 may have more privacy issues than RFC2464 Ethernet To: ipv6@ietf.org References: <563E68A2-582C-46E3-BFEF-42C0FD746101@jisc.ac.uk> <9ea46211-be4b-d054-766d-e6fcac001d9f@gmail.com> From: Brian E Carpenter Organization: University of Auckland Message-ID: <956dc9eb-a724-47ab-d7cb-94483ec349f5@gmail.com> Date: Tue, 19 Jul 2016 21:29:45 +1200 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.2.0 MIME-Version: 1.0 In-Reply-To: <9ea46211-be4b-d054-766d-e6fcac001d9f@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.17 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 Jul 2016 09:37:56 -0000 On 19/07/2016 20:57, Alexandre Petrescu wrote: > Hi, > > I would suggest to consider that it is on _wifi_ that there are more IP > address privacy concerns, rather than on Ethernet RFC2464. > > I suspect that RFC2464 Ethernet Frame Format is not what gets on the > wireless. On wireless we see 802.11 Data Headers not EthernetII > headers. A conversion between these two headers happens in each > computer, yes. > > The problem is that there is no RFC "IPv6-over-wifi" to patch. There's a reason for that: above the driver, the IP layer doesn't see *any* differences between 802.11 and any form of 802.3. So the RFC for 802.11 is RFC2464. Privacy issues arose first for wired broadcast networks - in 1983, Ethernet on yellow co-axial cables was wide open to eavesdroppers. > It would > be in that fictitious document that the solution to privacy worries - > e.g. random MAC or random IID - would be expressed. > > That is why I am saying that there is need of advice of what to put in a > potential "IPv6-over-80211" new document. Disagree. The issue may be more acute for wireless but it also applies to 802.3. At the level of IID formation or MAC address randomization, I don't think the technology matters - assume that eavesdropping is always possible. Brian > > Alex > PS: this also applies to IPv6-over-cellular networks using RFC2464 > inside the computer but obviously not on the network. > > -------------------------------------------------------------------- > IETF IPv6 working group mailing list > ipv6@ietf.org > Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 > -------------------------------------------------------------------- > From nobody Tue Jul 19 02:40:10 2016 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F009012DC6E for ; Tue, 19 Jul 2016 02:40:08 -0700 (PDT) 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 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 kpoA3EyguPUg for ; Tue, 19 Jul 2016 02:40:06 -0700 (PDT) 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 F213C12DF44 for ; Tue, 19 Jul 2016 02:32:46 -0700 (PDT) Received: from clairseach.fuaim.com (clairseach-high.fuaim.com [206.197.161.158]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by uillean.fuaim.com (Postfix) with ESMTP id E1E8C880C2 for ; Tue, 19 Jul 2016 02:32:46 -0700 (PDT) Received: from dhcp-b3c7.meeting.ietf.org (unknown [IPv6:2001:67c:370:176:88e:1d5a:508e:55a2]) (using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by clairseach.fuaim.com (Postfix) with ESMTP id 796843280ADF for ; Tue, 19 Jul 2016 02:32:46 -0700 (PDT) Subject: Re: Comments on draft-bchv-rfc6890bis-00.txt To: ipv6@ietf.org References: <64775099-aca6-85ba-c3ee-f44694b1bdf0@gmail.com> From: Brian Haberman Message-ID: Date: Tue, 19 Jul 2016 05:32:39 -0400 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:45.0) Gecko/20100101 Thunderbird/45.2.0 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="gUGves9bwItpkjSfLaPex8rxTSWt9NMkO" Archived-At: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 Jul 2016 09:40:09 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --gUGves9bwItpkjSfLaPex8rxTSWt9NMkO Content-Type: multipart/mixed; boundary="fCpkutw2QMF1dpVv3x8ECAoXkaQi95AX9" From: Brian Haberman To: ipv6@ietf.org Message-ID: Subject: Re: Comments on draft-bchv-rfc6890bis-00.txt References: <64775099-aca6-85ba-c3ee-f44694b1bdf0@gmail.com> In-Reply-To: --fCpkutw2QMF1dpVv3x8ECAoXkaQi95AX9 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable >>> I haven't been able to locate a copy of the IPv4 registry as it exist= ed >> before >> being restructured, but I infer that it used predictates like "private= " and >> "link >> local" which were made obsolete by RFC 6890. >=20 > I am not sure of that, but I can ask a few of the co-authors since they= > work for IANA. http://web.archive.org/web/20070630230311/http://www.iana.org/assignments= /iana-ipv6-special-registry https://web.archive.org/web/20120524215600/http://www.iana.org/assignment= s/iana-ipv4-special-registry/iana-ipv4-special-registry.xml Brian --fCpkutw2QMF1dpVv3x8ECAoXkaQi95AX9-- --gUGves9bwItpkjSfLaPex8rxTSWt9NMkO Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- iQEcBAEBCAAGBQJXjfO8AAoJEBOZRqCi7goqe+4H/0MJ9hgbR2mbfiiPSzDFJbyr bT13Hq8BSCKWMZr4LpB+NOhnA8BqUisjDycDK8C5Zr4Rm4tnQqXizf9ijyoMJwzk Pt9eKwTbIJl0Q097beHutrdVChFbHm/B18oTONRBzyycVnr5EEINgpRn2eLu7TBR Ufux/yPPHUhrrHwaL5uDETWLJBPE7u2xbrj1OSa58iWMpzMziup2RAjM6zJmsicJ 7gmsbTR2t0S36rrYCOZIUvfLN2J/Zm/iiMJ4MT9IMraKsiwrVIlZe/QBCkNITR0P 29iGAH+p+fYw4KcOIOu8rn90yl4xHm64Hwl3G0G0vQ1ItZrk7yhlksFKEGSZW6Y= =bVAm -----END PGP SIGNATURE----- --gUGves9bwItpkjSfLaPex8rxTSWt9NMkO-- From nobody Tue Jul 19 02:41:16 2016 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 741FB12DFCD for ; Tue, 19 Jul 2016 02:41: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 B2NBYcZcQ3qN for ; Tue, 19 Jul 2016 02:41:12 -0700 (PDT) Received: from mail-lf0-x231.google.com (mail-lf0-x231.google.com [IPv6:2a00:1450:4010:c07::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 78BF512DF69 for ; Tue, 19 Jul 2016 02:34:05 -0700 (PDT) Received: by mail-lf0-x231.google.com with SMTP id b199so8765099lfe.0 for ; Tue, 19 Jul 2016 02:34:05 -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=hUmHEONazOA6au8lUE74GPSj7ZY5v0pnoIc7uoYASe8=; b=omihDhCJZWsVgV+NblCu6+mIVg8R/4KgLGDFt6UTlgw3tifElbCh0bPYC/iYWo3LPZ yNwphjvy8K8ueohfnZ64gwMFsCw99/8+yrnX2Je5eiT9uw779rV2+p/RhDKmpfNTbf+x nuxHhom0Mf5pRpbrcXe7m9if6ODcbIUd5j6dZwKTl3MhH+NcpWsvQDgDKrsOSdvNexQo W7qm0PDJ4J/6Z21E0nloFhVr15K0jR+TEKIgLUoKkGzY+eT7V83C0s1LkN6bFvkhpp3y eFLpstMPaCuKPFvsVWiCr3YWehjl8WQ7B89N0yLOXd1EUXfGi9qKbFtET3QJ1gjipauk yLWQ== 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=hUmHEONazOA6au8lUE74GPSj7ZY5v0pnoIc7uoYASe8=; b=BRpgyviPnPze/ZGRjGA7iyzRZRO81L3wS5K9EkoqVWZ8N1QTnTu3EHO+oGQyRoJOZu ydsePhZuPl50a3OdKnzfiTJdUioeKr8Yr8Sp4LEKhqwrDofDom2wglbn9+cm93CAQCwb aj9l+0ltGyiU9T09hOeIPhrsfDEsgQ/MdrnYa+GKqlmt6K1dIF4fsAQ6ThrdeMV0B/BM 51z1UkNKngZawlipzS1QvLfvdyyt2avnhFAssTt+1QkMZ3BeXmEua2veJYD7EScDfc7/ 5MyG3M8btSv5dFyV+NV1ni8fSPaqUR7BG+tX9pzVMgWbCBny+0NAXlOrzlBVEmAjbu8U iCFg== X-Gm-Message-State: ALyK8tJa+b7ocTkjeCVqe04OY7jNs1jaLv2Fx/ZYZ5Tzd3uAiUr5USAgmpVU9e2OO0eDfg== X-Received: by 10.25.157.19 with SMTP id g19mr16409691lfe.216.1468920843322; Tue, 19 Jul 2016 02:34:03 -0700 (PDT) Received: from ?IPv6:2001:67c:370:176:28cc:dc4c:9703:6781? ([2001:67c:370:176:28cc:dc4c:9703:6781]) by smtp.gmail.com with ESMTPSA id e65sm2759695lji.32.2016.07.19.02.34.02 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 19 Jul 2016 02:34:02 -0700 (PDT) Subject: Re: draft-ietf-6man-default-iids and RFC4291 To: Kerry Lynn References: <16e7823a-4847-6d6b-4bda-48e0812e9e04@gmail.com> From: Brian E Carpenter Organization: University of Auckland Message-ID: Date: Tue, 19 Jul 2016 21:34:04 +1200 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.2.0 MIME-Version: 1.0 In-Reply-To: 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.17 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 Jul 2016 09:41:14 -0000 On 19/07/2016 21:22, Kerry Lynn wrote: > On Tue, Jul 19, 2016 at 4:36 AM, Brian E Carpenter < > brian.e.carpenter@gmail.com> wrote: > >> If we add a citation of 4291 to draft-ietf-6man-default-iids, please >> note the difference that is coming soon in 4291bis: >> >> RFC4291 says >> For all unicast addresses, except those that start with the binary >> value 000, Interface IDs are required to be 64 bits long and to be >> constructed in Modified EUI-64 format. >> >> RFC4291bis says >> For all unicast addresses, except those that start with the binary >> value 000, Interface IDs are required to be 64 bits long. If derived >> from an IEEE MAC-layer address, they must be constructed in Modified >> EUI-64 format. >> > The interesting wrinkle here is how one interprets the phrase "IEEE MAC- > layer address". I get the sense that many people interpret this as a 48-bit > hardware address with the U/L bit set to zero. > > The point that Pascal made at the mic is that 6LoWPAN (and other 6lo > IPv6-over-foo specs) specify a method for generating an IID by first > creating a locally assigned 48-bit MAC-layer address by right justifying > a short locally assigned L2 address in a field of zeros, setting the U/L bit > to one, then using this as the basis for forming a Modified EUI-64 > according to RFC4291 Appendix A. > > I don't see the RFC4291bis language as affecting this approach. Agreed. My point was that 4291bis does *not* provide a normative fall back; it just provides an "if" statement, which doesn't resolve Lorenzo's issue about the choice left open by draft-ietf-6man-default-iids in its current form. Brian > > Regards, Kerry > > >> That's to say, 4291bis also leaves the question open to the implementor. >> >> -- >> Regards >> Brian Carpenter >> (Don't blame me, I voted Remain.) >> >> >> -------------------------------------------------------------------- >> IETF IPv6 working group mailing list >> ipv6@ietf.org >> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 >> -------------------------------------------------------------------- >> > From nobody Tue Jul 19 02:54:05 2016 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 06ED912DE4A for ; Tue, 19 Jul 2016 02:54:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.347 X-Spam-Level: X-Spam-Status: No, score=-2.347 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FORGED_FROMDOMAIN=0.001, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=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 HG6QLump886j for ; Tue, 19 Jul 2016 02:54:01 -0700 (PDT) Received: from mail-io0-x231.google.com (mail-io0-x231.google.com [IPv6:2607:f8b0:4001:c06::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 29B8612DE35 for ; Tue, 19 Jul 2016 02:48:06 -0700 (PDT) Received: by mail-io0-x231.google.com with SMTP id m101so14177407ioi.2 for ; Tue, 19 Jul 2016 02:48:06 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to:cc; bh=al+cdQSDsncHKTlTlSwIzDQ2bvOJ11pvaAs7goDgoy8=; b=QVME9D2dC+x7XmxnU8SoXGrx+XqAp1y14MdwRSAPQR4k0Mw3O9WmwJSzAFcxIb++4W dy+KDQ+sroAi50/r1S0AOpMR+r4jzZqmLS5y88HQfcHXucrolKuIptcGRKbXh3Wf34qA 2i0Edtcp5UtF04VI91dIy3HUCJDSVQSebjHkUadgPjHVcMkZ0Yp9IRo0CrC+8fDmnROO NLpFbxruFN1YRZIepeO3hZ8GCW/Go1YlFuZbeuM7Jj7AOBV9pcTbE0o4b0G/7P8qwbet SQOM6JTLdxfp4rxMGqLUgzwxM6eZTdw4V94rHjcxhYuZ0iM90WJ/05MXd7emmAyDKUSJ jIJA== 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:from :date:message-id:subject:to:cc; bh=al+cdQSDsncHKTlTlSwIzDQ2bvOJ11pvaAs7goDgoy8=; b=bwn7jWX59x0eCveQpfwVhfHE1Uc3bLTG8y7IaIu3J/r8WvVNH/Q67TZQYBkQ4P6vtj tQol9W9pCkRpUn/BvpUFzpdj0EQ1WopYOTePLwsZzOp9ydEUWvhDAJOQP8rIM3zCJJ7r 45rVp5DPB1NtG67K22acI98HS3LAKD1DNQFsMVnqgSbQRdrsp5qGRxNzZ7sZmaqdue7n bBbRvGlgYikT+j97cGsgreOZg0zzbYpIKBXqkfPeZtF5hCHDyjpDtUoPEFvyt3Yr4t+D OoMU0jwBh7NSNRkPcwzGwkK6sWJcWujtxAS6g0a2OERITEo11qE1fWslvHqLtchVBmv/ +OwQ== X-Gm-Message-State: ALyK8tLZDZyFs9hCXmMn7zbVsVko9E0TBYfk6QtdiUAknOJsaZsw97DX8zYfgNjWaagl0KmowN2h0xG9sLPaew== X-Received: by 10.107.13.70 with SMTP id 67mr13429031ion.75.1468921685343; Tue, 19 Jul 2016 02:48:05 -0700 (PDT) MIME-Version: 1.0 Sender: kerlyn2001@gmail.com Received: by 10.107.9.22 with HTTP; Tue, 19 Jul 2016 02:48:04 -0700 (PDT) In-Reply-To: References: <64775099-aca6-85ba-c3ee-f44694b1bdf0@gmail.com> From: Kerry Lynn Date: Tue, 19 Jul 2016 05:48:04 -0400 X-Google-Sender-Auth: NE_ZOa_E1oughD_DGE9Um_qG-k8 Message-ID: Subject: Re: Comments on draft-bchv-rfc6890bis-00.txt To: Brian Haberman Content-Type: multipart/alternative; boundary=001a113ff994420e230537f9fb3e Archived-At: Cc: "ipv6@ietf.org" X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 Jul 2016 09:54:03 -0000 --001a113ff994420e230537f9fb3e Content-Type: text/plain; charset=UTF-8 On Tue, Jul 19, 2016 at 5:15 AM, Brian Haberman wrote: > Hi Kerry, > > On 7/19/16 5:09 AM, Kerry Lynn wrote: > > >> But RFC 6890 apparently *did* make changes to the IPv4 registry, so if > > we obsolete RFC 6890 do those changes remain in effect? > > > > Yes. All the registry changes made in 6890 are carried over in this > draft modulo the changes I mentioned to the ULA entry and the TEREDO > entry (to address a filed erratum). > Mea culpa. I somehow missed that ALL the tables are included in the bis :-/ Regards, Kerry --001a113ff994420e230537f9fb3e Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On T= ue, Jul 19, 2016 at 5:15 AM, Brian Haberman <brian@innovationslab= .net> wrote:
Hi Kerry,

On 7/19/16 5:09 AM, Kerry Lynn wrote:
<= snip>=C2=A0
>> But RFC 6890 apparently *did* make changes to the IPv4 registry, s= o if
> we obsolete RFC 6890 do those changes remain in effect?
>

Yes. All the registry changes made in 6890 are carried over in = this
draft modulo the changes I mentioned to the ULA entry and the TEREDO
entry (to address a filed erratum).

Mea= culpa.=C2=A0 I somehow missed that ALL the tables are included in the bis = :-/

Regards, Kerry=C2=A0
--001a113ff994420e230537f9fb3e-- From nobody Tue Jul 19 02:55:32 2016 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2972E12DDCD for ; Tue, 19 Jul 2016 02:55:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.333 X-Spam-Level: X-Spam-Status: No, score=-5.333 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_ADSP_CUSTOM_MED=0.001, FREEMAIL_FROM=0.001, NML_ADSP_CUSTOM_MED=0.9, RCVD_IN_DNSWL_HI=-5, SPF_SOFTFAIL=0.665] 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 6mE9DJuJvV_N for ; Tue, 19 Jul 2016 02:55:24 -0700 (PDT) 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 2114912E035 for ; Tue, 19 Jul 2016 02:49:31 -0700 (PDT) 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 u6J9nU1i028383; Tue, 19 Jul 2016 11:49:30 +0200 Received: from pisaure.intra.cea.fr (localhost [127.0.0.1]) by localhost (Postfix) with SMTP id E8394203AB5; Tue, 19 Jul 2016 11:49:29 +0200 (CEST) Received: from muguet1.intra.cea.fr (muguet1.intra.cea.fr [132.166.192.6]) by pisaure.intra.cea.fr (Postfix) with ESMTP id D9D6F203658; Tue, 19 Jul 2016 11:49:29 +0200 (CEST) Received: from [132.166.84.158] ([132.166.84.158]) by muguet1.intra.cea.fr (8.15.2/8.15.2/CEAnet-Intranet-out-1.4) with ESMTP id u6J9nTIS000521; Tue, 19 Jul 2016 11:49:29 +0200 Subject: Re: IPv6-over-80211 may have more privacy issues than RFC2464 Ethernet To: Brian E Carpenter , ipv6@ietf.org References: <563E68A2-582C-46E3-BFEF-42C0FD746101@jisc.ac.uk> <9ea46211-be4b-d054-766d-e6fcac001d9f@gmail.com> <956dc9eb-a724-47ab-d7cb-94483ec349f5@gmail.com> From: Alexandre Petrescu Message-ID: <2b2f210d-cef8-a8b3-f65a-7bb1e28aea0d@gmail.com> Date: Tue, 19 Jul 2016 11:49:29 +0200 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.2.0 MIME-Version: 1.0 In-Reply-To: <956dc9eb-a724-47ab-d7cb-94483ec349f5@gmail.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.17 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 Jul 2016 09:55:31 -0000 Le 19/07/2016 11:29, Brian E Carpenter a crit : > On 19/07/2016 20:57, Alexandre Petrescu wrote: >> Hi, >> >> I would suggest to consider that it is on _wifi_ that there are >> more IP address privacy concerns, rather than on Ethernet RFC2464. >> >> I suspect that RFC2464 Ethernet Frame Format is not what gets on >> the wireless. On wireless we see 802.11 Data Headers not >> EthernetII headers. A conversion between these two headers >> happens in each computer, yes. >> >> The problem is that there is no RFC "IPv6-over-wifi" to patch. > > There's a reason for that: above the driver, the IP layer doesn't > see *any* differences between 802.11 and any form of 802.3. I agree. But I think it should. There are many differences between 802.11 WiFi and Ethernet that should be reckoned: MTU size, QoS parameters, and more. > So the RFC for 802.11 is RFC2464. Privacy issues arose first for > wired broadcast networks - in 1983, Ethernet on yellow co-axial > cables was wide open to eavesdroppers. I can agree. I meant that WiFi is easier to listening the media unnoticed rather than cutting or plugging wires which is more noticeable. This translates into some implemented mechanisms of protection privacy which involve 802.11-specific parameters like ESSID - MAC address generators. Such description can not be in an RFC2464 update because Ethernet does not have ESSID, MSISDN on cellular, or similar. >> It would be in that fictitious document that the solution to >> privacy worries - e.g. random MAC or random IID - would be >> expressed. >> >> That is why I am saying that there is need of advice of what to >> put in a potential "IPv6-over-80211" new document. > > Disagree. The issue may be more acute for wireless but it also > applies to 802.3. At the level of IID formation or MAC address > randomization, I don't think the technology matters - assume that > eavesdropping is always possible. I can agree. But the protection is different on different media. On 802.3 the privacy protection mechanisms may be different than on 802.11. Alex > > Brian > >> >> Alex PS: this also applies to IPv6-over-cellular networks using >> RFC2464 inside the computer but obviously not on the network. >> >> -------------------------------------------------------------------- >> >> >> 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 Jul 19 02:56:19 2016 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B9B8B12DEC9 for ; Tue, 19 Jul 2016 02:56:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.358 X-Spam-Level: X-Spam-Status: No, score=-0.358 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FORGED_FROMDOMAIN=0.001, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.001, HTML_MESSAGE=0.001, HTTPS_HTTP_MISMATCH=1.989, 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 QTh7Qj8Sdt0S for ; Tue, 19 Jul 2016 02:56:05 -0700 (PDT) Received: from mail-it0-x22d.google.com (mail-it0-x22d.google.com [IPv6:2607:f8b0:4001:c0b::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 1BE7112DEAE for ; Tue, 19 Jul 2016 02:50:18 -0700 (PDT) Received: by mail-it0-x22d.google.com with SMTP id f6so14841157ith.0 for ; Tue, 19 Jul 2016 02:50:18 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to:cc; bh=Blzv4QG+IhNnmTDUbVDZL6ajn8+Vd0XbVmTsGmiUj6U=; b=afNg0Ov1mW5BOBB5kLRD54LLuATl76+GZJ2JJ2MB+ur5vato0niCRtnljqPTH4XAI5 ZebVHmganB3mtNK4ws5SrBxlmMmRg+z7z6qbqV/ht15PzwOQoXcJP9IKRyVC9EXfMlqw ijsYRfRc5zKc3B6eKPdJWCw1DkIfUw6yeMuMel0PA3aLqyXNiyCIaxb6JyOjy4SbSeqr bpns/qUG9d56Iou5AJAyqxYXS7sZFH6dMDHfnqTtiuGcdSoFWVqhP6qubAojUvG/awF2 iPWuFRNCuYJ+kDpHo8oeqCbfijhn1LtHJaEQjdLJI34/yZfTFhKCnW4q4R9Ga+Ec2t9k SiwA== 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:from :date:message-id:subject:to:cc; bh=Blzv4QG+IhNnmTDUbVDZL6ajn8+Vd0XbVmTsGmiUj6U=; b=ikaMy7Lahp5+QV7rifVcwUNv/IpVFC2j9r/jwNMXPTbg5jDsiqwUNtPyQILCoHibL0 zcd30n652+irRIsC5OgVI5EsJCMP7ixaoMfK0mVT/0K3Q2e2l9wD6DeJ/3sKSzFZYrKT /ppa0NogMhTu3ScWMQQXvKuEtjtapC83h5UlHWmLynreKplc+Imp4UIEiimaidU7R1wb q3ImWRzZXrLgAsIn1FeMyD4bA3ug6LtgDboO1qFQ81dHblyHEuKE+bE3GdAK5PlpsXNu KLvfg+XuGg6WWFuXpX2ItfaalPHX5DEfli9MpXYgGO7eU8WXGmBVtZD7nx89hmYJcYU1 e09Q== X-Gm-Message-State: ALyK8tLJt7dX80+HJ0RSX7vB30TTgeRM5euB1pwlLjCjKNSjM6HWeI4yaozhjMnLzF6/um9IvxHjRE7SvK7+4Q== X-Received: by 10.36.154.65 with SMTP id l62mr2688060ite.79.1468921817428; Tue, 19 Jul 2016 02:50:17 -0700 (PDT) MIME-Version: 1.0 Sender: kerlyn2001@gmail.com Received: by 10.107.9.22 with HTTP; Tue, 19 Jul 2016 02:50:16 -0700 (PDT) In-Reply-To: References: <64775099-aca6-85ba-c3ee-f44694b1bdf0@gmail.com> From: Kerry Lynn Date: Tue, 19 Jul 2016 05:50:16 -0400 X-Google-Sender-Auth: PcNqBS9L3n8OORhBjaEsD7oRWbg Message-ID: Subject: Re: Comments on draft-bchv-rfc6890bis-00.txt To: Brian Haberman Content-Type: multipart/alternative; boundary=94eb2c114852218d150537fa03da Archived-At: Cc: 6man 6man X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 Jul 2016 09:56:19 -0000 --94eb2c114852218d150537fa03da Content-Type: text/plain; charset=UTF-8 On Tue, Jul 19, 2016 at 5:32 AM, Brian Haberman wrote: > >>> I haven't been able to locate a copy of the IPv4 registry as it existed > >> before > >> being restructured, but I infer that it used predictates like "private" > and > >> "link > >> local" which were made obsolete by RFC 6890. > > > > I am not sure of that, but I can ask a few of the co-authors since they > > work for IANA. > > > http://web.archive.org/web/20070630230311/http://www.iana.org/assignments/iana-ipv6-special-registry > > > https://web.archive.org/web/20120524215600/http://www.iana.org/assignments/iana-ipv4-special-registry/iana-ipv4-special-registry.xml > > Thanks. No mention of "private", "link local", etc. > Brian > > > -------------------------------------------------------------------- > IETF IPv6 working group mailing list > ipv6@ietf.org > Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 > -------------------------------------------------------------------- > > --94eb2c114852218d150537fa03da Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On T= ue, Jul 19, 2016 at 5:32 AM, Brian Haberman <brian@innovationslab= .net> wrote:
>>> I haven't been able to locate a copy of the IPv4 regist= ry as it existed
>> before
>> being restructured, but I infer that it used predictates like &quo= t;private" and
>> "link
>> local" which were made obsolete by RFC 6890.
>
> I am not sure of that, but I can ask a few of the co-authors since the= y
> work for IANA.

http://web.archive.org/web/20070630230311/http://www.iana.org/assign= ments/iana-ipv6-special-registry

https://web.archive.org/web/2012052421560= 0/http://www.iana.org/assignments/iana-ipv4-special-registry/iana-ipv4-spec= ial-registry.xml

Thanks.=C2=A0 No mention of "private", "link local&q= uot;, etc.
=C2=A0
Brian


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


--94eb2c114852218d150537fa03da-- From nobody Tue Jul 19 03:01:54 2016 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 02E7A12B04E for ; Tue, 19 Jul 2016 03:01:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.347 X-Spam-Level: X-Spam-Status: No, score=-2.347 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FORGED_FROMDOMAIN=0.001, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=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 bGTVzpLdTgF9 for ; Tue, 19 Jul 2016 03:01:51 -0700 (PDT) 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 34A3212D131 for ; Tue, 19 Jul 2016 02:56:55 -0700 (PDT) Received: by mail-io0-x230.google.com with SMTP id m101so14329720ioi.2 for ; Tue, 19 Jul 2016 02:56:55 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to:cc; bh=yWktlOiVl+HRTvjBBxi6DnqP/suNoPkvKqF2E/eqWMM=; b=TMeRQL8FT1LG8KwbOlcrzZ+mWIECUwTY3K1fkxHghg981Nm798G29LedJAWiawo5I6 sl46y7isZgw2/VQgW1Qr5gHbkbqaV/4jMS4r5JvR7bnXDlVJRSgoBoh183LtsN50Dv92 JtScIpU92qQDVAej/jHc/jSUnLyVoB0a91BxpmxDx7rBFKAMZwTEgZTJnZX1ZmvPx9vC SSJf40GA3zG2HLeSXmjlTBct4SbhlF4oKwEymr4Ka46TBIXzZ9eltj6C0FFpgVaxefD1 FHMRiZsR6gYm69jUsv9gX3JPrdis6+nImL7JDD0gCehIPUONhY0qmjRD9pRxLElo8zr6 HeTQ== 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:from :date:message-id:subject:to:cc; bh=yWktlOiVl+HRTvjBBxi6DnqP/suNoPkvKqF2E/eqWMM=; b=QumWjX4g1CBtcZ/vLJQKa4c6IA0o2h524yz/yzpCX4CJqYJHCgZjj/6PNxrsMOf1rd v0i5rkQ2qCfsfSMkGlrJioCHf4Wd57st2RvCoTjV5BBKfBkLKKsaQ5gEtPojdTKg8v1o kwfzzuWA81Poz0bHlFLqeqRzX3pnQyQtW9UEXp/+BRBHRnYKjoKJ/fRledU3vA/Gwq3b nwWATL1scLY/IWEEHbRtMTdhP0oORvvKjulGY55lFKF0gm3b/8tjB8+01Nd2h8+TKHyA 3+ZdOx7Wp5+QonQX+kd2BXE9qdJYgZFZj72LNMorNfaZ5UHOLHnpicjWsmRtiwGjnvhv l+Tw== X-Gm-Message-State: ALyK8tKuyRPxFOQFlu3VukAevuHHrtBmKphFlwZZoWV3gknwF4JyazNlbn80ITfCwMki45/Lt/Lcp+oSCH0vVw== X-Received: by 10.107.13.70 with SMTP id 67mr13461339ion.75.1468922214451; Tue, 19 Jul 2016 02:56:54 -0700 (PDT) MIME-Version: 1.0 Sender: kerlyn2001@gmail.com Received: by 10.107.9.22 with HTTP; Tue, 19 Jul 2016 02:56:53 -0700 (PDT) In-Reply-To: <578DF296.3010007@si6networks.com> References: <16e7823a-4847-6d6b-4bda-48e0812e9e04@gmail.com> <578DF296.3010007@si6networks.com> From: Kerry Lynn Date: Tue, 19 Jul 2016 05:56:53 -0400 X-Google-Sender-Auth: RfiCWmHUxvvz7eQ_sctCFsJoXoM Message-ID: Subject: Re: draft-ietf-6man-default-iids and RFC4291 To: Fernando Gont Content-Type: multipart/alternative; boundary=001a113ff994cb93ae0537fa1ae2 Archived-At: Cc: 6man X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 Jul 2016 10:01:53 -0000 --001a113ff994cb93ae0537fa1ae2 Content-Type: text/plain; charset=UTF-8 On Tue, Jul 19, 2016 at 5:27 AM, Fernando Gont wrote: > On 07/19/2016 10:36 AM, Brian E Carpenter wrote: > > If we add a citation of 4291 to draft-ietf-6man-default-iids, please > > note the difference that is coming soon in 4291bis: > > > > RFC4291 says > > For all unicast addresses, except those that start with the binary > > value 000, Interface IDs are required to be 64 bits long and to be > > constructed in Modified EUI-64 format. > > > > RFC4291bis says > > For all unicast addresses, except those that start with the binary > > value 000, Interface IDs are required to be 64 bits long. If derived > > from an IEEE MAC-layer address, they must be constructed in Modified > > EUI-64 format. > > > > That's to say, 4291bis also leaves the question open to the implementor. > > > FWIW, I think 4291bis should actualy reference default-iids here. > > I think not, since that assumes the bis language only covers IIDs derived from stable IEEE MAC-layer addresses. Kerry > 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 > -------------------------------------------------------------------- > --001a113ff994cb93ae0537fa1ae2 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On T= ue, Jul 19, 2016 at 5:27 AM, Fernando Gont <fgont@si6networks.com&= gt; wrote:
On 07/= 19/2016 10:36 AM, Brian E Carpenter wrote:
> If we add a citation of 4291 to draft-ietf-6man-default-iids, please > note the difference that is coming soon in 4291bis:
>
> RFC4291 says
>=C2=A0 =C2=A0 For all unicast addresses, except those that start with t= he binary
>=C2=A0 =C2=A0 value 000, Interface IDs are required to be 64 bits long = and to be
>=C2=A0 =C2=A0 constructed in Modified EUI-64 format.
>
> RFC4291bis says
>=C2=A0 =C2=A0 For all unicast addresses, except those that start with t= he binary
>=C2=A0 =C2=A0 value 000, Interface IDs are required to be 64 bits long.= =C2=A0 If derived
>=C2=A0 =C2=A0 from an IEEE MAC-layer address, they must be constructed = in Modified
>=C2=A0 =C2=A0 EUI-64 format.
>
> That's to say, 4291bis also leaves the question open to the implem= entor.


FWIW, I think 4291bis should actualy reference default-iids here.
I think not, since that assumes the bis language only= covers IIDs derived
from stable IEEE MAC-layer addresses.
<= div>
Kerry
=C2=A0
Thanks,
--
Fernando Gont
SI6 Networks
e-mail: fgont@si6networks.com<= br> 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/list= info/ipv6
--------------------------------------------------------------------

--001a113ff994cb93ae0537fa1ae2-- From nobody Tue Jul 19 03:03:53 2016 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0FF2612D186 for ; Tue, 19 Jul 2016 03:03:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.189 X-Spam-Level: X-Spam-Status: No, score=-3.189 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-1.287, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] 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 2TVKxkliroXm for ; Tue, 19 Jul 2016 03:03:49 -0700 (PDT) Received: from givry.fdupont.fr (givry.fdupont.fr [IPv6:2001:41d0:1:6d55:211:5bff:fe98:d51e]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 854D312DDAA for ; Tue, 19 Jul 2016 02:59:23 -0700 (PDT) Received: from givry.fdupont.fr (localhost [IPv6:::1]) by givry.fdupont.fr (8.14.7/8.14.7) with ESMTP id u6J9vx4F013776; Tue, 19 Jul 2016 11:57:59 +0200 (CEST) (envelope-from dupont@givry.fdupont.fr) Message-Id: <201607190957.u6J9vx4F013776@givry.fdupont.fr> From: Francis Dupont To: Brian E Carpenter Subject: Re: IPv6-over-80211 may have more privacy issues than RFC2464 Ethernet In-reply-to: Your message of Tue, 19 Jul 2016 21:29:45 +1200. <956dc9eb-a724-47ab-d7cb-94483ec349f5@gmail.com> Date: Tue, 19 Jul 2016 11:57:59 +0200 Archived-At: Cc: ipv6@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 Jul 2016 10:03:52 -0000 I have another kind of counter-argument: if we publish an IPv6-over-80211 document, it should specify the real MTU of 802.11 which is not 1500 but larger. As in the real world everybody without significant exceptions clearly ignore that and use only 1500 MTU there is no need at all for a specific document (vs reusing the 802.3 one). Regards Francis.Dupont@fdupont.fr From nobody Tue Jul 19 03:05:22 2016 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 54A6312D5A9 for ; Tue, 19 Jul 2016 03:05:20 -0700 (PDT) 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 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 8UorObJe0-j5 for ; Tue, 19 Jul 2016 03:05:17 -0700 (PDT) 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 4428912DC22 for ; Tue, 19 Jul 2016 03:01:31 -0700 (PDT) Received: from [IPv6:2001:67c:370:160:829:75a1:d800:dc03] (unknown [IPv6:2001:67c:370:160:829:75a1:d800:dc03]) (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 B33988009B; Tue, 19 Jul 2016 12:01:29 +0200 (CEST) Subject: Re: draft-ietf-6man-default-iids and RFC4291 To: Brian E Carpenter , Kerry Lynn References: <16e7823a-4847-6d6b-4bda-48e0812e9e04@gmail.com> From: Fernando Gont Message-ID: <578DFA62.6020109@si6networks.com> Date: Tue, 19 Jul 2016 12:01:06 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.8.0 MIME-Version: 1.0 In-Reply-To: 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.17 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 Jul 2016 10:05:21 -0000 On 07/19/2016 11:34 AM, Brian E Carpenter wrote: > On 19/07/2016 21:22, Kerry Lynn wrote: >> On Tue, Jul 19, 2016 at 4:36 AM, Brian E Carpenter < >> brian.e.carpenter@gmail.com> wrote: >> >>> If we add a citation of 4291 to draft-ietf-6man-default-iids, please >>> note the difference that is coming soon in 4291bis: >>> >>> RFC4291 says >>> For all unicast addresses, except those that start with the binary >>> value 000, Interface IDs are required to be 64 bits long and to be >>> constructed in Modified EUI-64 format. >>> >>> RFC4291bis says >>> For all unicast addresses, except those that start with the binary >>> value 000, Interface IDs are required to be 64 bits long. If derived >>> from an IEEE MAC-layer address, they must be constructed in Modified >>> EUI-64 format. >>> >> The interesting wrinkle here is how one interprets the phrase "IEEE MAC- >> layer address". I get the sense that many people interpret this as a 48-bit >> hardware address with the U/L bit set to zero. >> >> The point that Pascal made at the mic is that 6LoWPAN (and other 6lo >> IPv6-over-foo specs) specify a method for generating an IID by first >> creating a locally assigned 48-bit MAC-layer address by right justifying >> a short locally assigned L2 address in a field of zeros, setting the U/L bit >> to one, then using this as the basis for forming a Modified EUI-64 >> according to RFC4291 Appendix A. >> >> I don't see the RFC4291bis language as affecting this approach. > > Agreed. My point was that 4291bis does *not* provide a normative fall > back; it just provides an "if" statement, which doesn't resolve Lorenzo's > issue about the choice left open by draft-ietf-6man-default-iids in its > current form. You mean for the case where a node employs non-stable only? Thanks, -- Fernando Gont SI6 Networks e-mail: fgont@si6networks.com PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492 From nobody Tue Jul 19 03:13:20 2016 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 65F7112D103 for ; Tue, 19 Jul 2016 03:13:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.188 X-Spam-Level: X-Spam-Status: No, score=-3.188 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-1.287, SPF_PASS=-0.001] 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 roa7oEDlCi8J for ; Tue, 19 Jul 2016 03:13:17 -0700 (PDT) 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 3389712D19B for <6man@ietf.org>; Tue, 19 Jul 2016 03:13:17 -0700 (PDT) Received: from sandelman.ca (obiwan.sandelman.ca [209.87.249.21]) by tuna.sandelman.ca (Postfix) with ESMTP id BACA120183; Tue, 19 Jul 2016 06:22:42 -0400 (EDT) Received: from obiwan.sandelman.ca (localhost [IPv6:::1]) by sandelman.ca (Postfix) with ESMTP id 6ACA1638D1; Tue, 19 Jul 2016 06:13:15 -0400 (EDT) From: Michael Richardson To: 6man@ietf.org Subject: proposed text for header injection revision 05 X-Attribution: mcr X-Mailer: MH-E 8.6; nmh 1.6+dev; GNU Emacs 24.5.1 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: Mark Townsley X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 Jul 2016 10:13:18 -0000 --=-=-= Content-Type: text/plain for 2nd paragraph: An approach an intermediate node/router may take to include an additional extension header in an IPv6 packet that it did not originate is to encapsulate the original packet in a new IPv6 header. As the source address of this IPv6 packet would then be the router, any number of additional extension headers may be placed after this new header, prior to the original packet. A system making use of this mechanism will have to specify how to construct the rest of the IPv6 header, in particulate, such a specification needs to carefully consider what the destination address will be. -- Michael Richardson , Sandelman Software Works -= IPv6 IoT consulting =- --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 iQEVAwUBV439OICLcPvd0N1lAQLR7AgAj+rtYKPmPglq4+BeWSloRcVCBoMLEi+y /Cq/AZKY65oeD/OGIpSkRNCpuJU/usroujF5vljF0qIktNQW3/l1sfynlM4xAOHN uUE7apiiFLEc4WvCv0iUKVJb4Pg/jJ+S7CfH0D4iI20SC/zKVNolXG9J7Nb/4J27 d+ynkXEeLyIr4bwwDzOPIPuUT1E6gJ+BCZ7rHrgGeTKunHqt5gXSTuG285LtXe0B fW31SdYpSt/riZ5+glwU5wS8S6to0oCUkDCM/aXor6piwCqFsumqZ2gHH6V0UWPQ I1QN892qOycvw3HFr02sL87BiKTnYgof5clh6yGu5BoD9fhD5QOqsA== =tSlT -----END PGP SIGNATURE----- --=-=-=-- From nobody Tue Jul 19 03:14:28 2016 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5EFC512B006 for ; Tue, 19 Jul 2016 03:14:27 -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 YhLiCjaNMZkA for ; Tue, 19 Jul 2016 03:14:25 -0700 (PDT) Received: from mail-wm0-x22a.google.com (mail-wm0-x22a.google.com [IPv6:2a00:1450:400c:c09::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 4165012D1D0 for ; Tue, 19 Jul 2016 03:14:25 -0700 (PDT) Received: by mail-wm0-x22a.google.com with SMTP id i5so20437565wmg.0 for ; Tue, 19 Jul 2016 03:14:25 -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=PDELriktxI62Fxihkz3cM9iJKEavAzH4iKWYz0QdyQU=; b=eMngEg7kUw7srIY4WNl6R9AFxe2o4tiGpNvqVclac2EclxMVGv5JN97vJ5i/Q+Intu JpEpyBrVZDx9iJXg7VICnN+dl0l1CwF1pBEPhDCu0h77WCFOhbcHp4CsPEzltmhWwp+P Qir9EGjtep4re1MmvS8nw/h8uy2z0ZwtvBeTMRM2NaZrrXTfMCVUAWOEZ6dlLphcjIrd KZQyfvB9eg2H/zZUL72km9Y2Vm1vVDnuZZTG9ro320a1Y1HWPagjPtfun1BEUCHaESi2 dmSf8H7UWEo1QOxyDCkN7dSZ5+KI42H8NAw+sgt5flVs+4UBcKw9W7IBLlqbpEbc50qZ E0Eg== 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=PDELriktxI62Fxihkz3cM9iJKEavAzH4iKWYz0QdyQU=; b=i6kKSpYOuQOtuWr4m5n6SiJD5hjo8zlKQiJ47Z8szANAqvXO8gbvpO/5uBhuvKld7t 6N+TxNapmLd3cJcNCMZ+IOUCuZ1D6bhgximF4zHw/iPMYG0847Nj3cYUnuq0l7JiX0TO y77gL2qH4kMRNZxQ+A+iTe9pI8SJTbTr7S3eWuSdNoav2u5Cu4yznKQALBdS5hEbeaIc lHpl9qqexIy+8ZPX7MK2nKRXTBlUDHEB444SFVsTixN+FsrMrO/zgSQ/PpLHC1NvUjWv gX/5P2fsc+jeKrm8CqiFipoXLcfjAQ080bC67KUb6ttdHe5/nwCiA2xnO2Vfobo9VSjc EZhQ== X-Gm-Message-State: ALyK8tJLBk3exMhky/B7jIOCQAESfOgByCNlAy/7AwOVaWr22jUkOdY/mKhKhLRQu/ZvJA== X-Received: by 10.28.9.67 with SMTP id 64mr3184300wmj.36.1468923263736; Tue, 19 Jul 2016 03:14:23 -0700 (PDT) Received: from ?IPv6:2001:67c:370:176:28cc:dc4c:9703:6781? ([2001:67c:370:176:28cc:dc4c:9703:6781]) by smtp.gmail.com with ESMTPSA id z5sm21593409wme.5.2016.07.19.03.14.22 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 19 Jul 2016 03:14:23 -0700 (PDT) Subject: Re: draft-ietf-6man-default-iids and RFC4291 To: Fernando Gont , Kerry Lynn References: <16e7823a-4847-6d6b-4bda-48e0812e9e04@gmail.com> <578DFA62.6020109@si6networks.com> From: Brian E Carpenter Organization: University of Auckland Message-ID: <45ed6027-4dd5-4be6-f461-4a66f95df629@gmail.com> Date: Tue, 19 Jul 2016 22:14:25 +1200 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.2.0 MIME-Version: 1.0 In-Reply-To: <578DFA62.6020109@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.17 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 Jul 2016 10:14:27 -0000 On 19/07/2016 22:01, Fernando Gont wrote: > On 07/19/2016 11:34 AM, Brian E Carpenter wrote: >> On 19/07/2016 21:22, Kerry Lynn wrote: >>> On Tue, Jul 19, 2016 at 4:36 AM, Brian E Carpenter < >>> brian.e.carpenter@gmail.com> wrote: >>> >>>> If we add a citation of 4291 to draft-ietf-6man-default-iids, please >>>> note the difference that is coming soon in 4291bis: >>>> >>>> RFC4291 says >>>> For all unicast addresses, except those that start with the binary >>>> value 000, Interface IDs are required to be 64 bits long and to be >>>> constructed in Modified EUI-64 format. >>>> >>>> RFC4291bis says >>>> For all unicast addresses, except those that start with the binary >>>> value 000, Interface IDs are required to be 64 bits long. If derived >>>> from an IEEE MAC-layer address, they must be constructed in Modified >>>> EUI-64 format. >>>> >>> The interesting wrinkle here is how one interprets the phrase "IEEE MAC- >>> layer address". I get the sense that many people interpret this as a 48-bit >>> hardware address with the U/L bit set to zero. >>> >>> The point that Pascal made at the mic is that 6LoWPAN (and other 6lo >>> IPv6-over-foo specs) specify a method for generating an IID by first >>> creating a locally assigned 48-bit MAC-layer address by right justifying >>> a short locally assigned L2 address in a field of zeros, setting the U/L bit >>> to one, then using this as the basis for forming a Modified EUI-64 >>> according to RFC4291 Appendix A. >>> >>> I don't see the RFC4291bis language as affecting this approach. >> >> Agreed. My point was that 4291bis does *not* provide a normative fall >> back; it just provides an "if" statement, which doesn't resolve Lorenzo's >> issue about the choice left open by draft-ietf-6man-default-iids in its >> current form. > > You mean for the case where a node employs non-stable only? Well, yes, or any case in which the implementor decides to "escape" from draft-ietf-6man-default-iids for any other reason. Brian From nobody Tue Jul 19 03:15:09 2016 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5235412D533 for ; Tue, 19 Jul 2016 03:15:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.353 X-Spam-Level: X-Spam-Status: No, score=-5.353 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_ADSP_CUSTOM_MED=0.001, FREEMAIL_FROM=0.001, NML_ADSP_CUSTOM_MED=0.9, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_SOFTFAIL=0.665] 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 QiRiNODV5dQ3 for ; Tue, 19 Jul 2016 03:15:07 -0700 (PDT) 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 B6B2812D534 for ; Tue, 19 Jul 2016 03:14:45 -0700 (PDT) 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 u6JAEhEQ005844 for ; Tue, 19 Jul 2016 12:14:43 +0200 Received: from pisaure.intra.cea.fr (localhost [127.0.0.1]) by localhost (Postfix) with SMTP id D5A36203AB3 for ; Tue, 19 Jul 2016 12:14:43 +0200 (CEST) Received: from muguet1.intra.cea.fr (muguet1.intra.cea.fr [132.166.192.6]) by pisaure.intra.cea.fr (Postfix) with ESMTP id C202F2038E6 for ; Tue, 19 Jul 2016 12:14:43 +0200 (CEST) Received: from [132.166.84.150] ([132.166.84.150]) by muguet1.intra.cea.fr (8.15.2/8.15.2/CEAnet-Intranet-out-1.4) with ESMTP id u6JAEgTv020605 for ; Tue, 19 Jul 2016 12:14:43 +0200 Subject: HbH used by Router Alert in MLDv2? To: ipv6@ietf.org References: <16e7823a-4847-6d6b-4bda-48e0812e9e04@gmail.com> From: Alexandre Petrescu Message-ID: Date: Tue, 19 Jul 2016 12:14:40 +0200 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.2.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Archived-At: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 Jul 2016 10:15:08 -0000 Hi, I suspect HbH is used in Router Alert options and MLDv2, which is used at computer startup to signal presence and belonging to some multicast groups needed later by ND. If so, then the RFC2460bis suggested modifications would imply that all computers would have to be specifically enabled to continue use this HbH? Alex From nobody Tue Jul 19 03:31:15 2016 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8F55812B05A; Tue, 19 Jul 2016 03:31:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.188 X-Spam-Level: X-Spam-Status: No, score=-3.188 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-1.287, SPF_PASS=-0.001] 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 G8GLhULbwMwc; Tue, 19 Jul 2016 03:31:07 -0700 (PDT) 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 D112A12B049; Tue, 19 Jul 2016 03:31:07 -0700 (PDT) Received: from sandelman.ca (obiwan.sandelman.ca [IPv6:2607:f0b0:f:2::247]) by tuna.sandelman.ca (Postfix) with ESMTP id 7197C20183; Tue, 19 Jul 2016 06:40:34 -0400 (EDT) Received: from obiwan.sandelman.ca (localhost [IPv6:::1]) by sandelman.ca (Postfix) with ESMTP id 0FE5D638D1; Tue, 19 Jul 2016 06:31:07 -0400 (EDT) From: Michael Richardson To: roll@ietf.org, 6man@ietf.org Subject: Re: impacts of rfc2460bis on draft-ietf-roll-useofrplinfo In-Reply-To: <799ab640-bed0-22a6-a9df-97f78c3f0bf8@gmail.com> References: <24554.1468868593@obiwan.sandelman.ca> <799ab640-bed0-22a6-a9df-97f78c3f0bf8@gmail.com> X-Mailer: MH-E 8.6; nmh 1.6+dev; GNU Emacs 24.5.1 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.17 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 Jul 2016 10:31:10 -0000 --=-=-= Content-Type: text/plain Brian E Carpenter wrote: >> >> The ROLL document draft-ietf-roll-useofrplinfo documents RFC6553 (a >> Hop-by-Hop critical option) and 6554 (a form of Source Routing Header, RH3). >> There is work on 6lo to allocate additional 6lowpan IPHC codes such that >> the work in ROLL: >> https://datatracker.ietf.org/doc/draft-ietf-roll-routing-dispatch/ can >> know what kinds of things we need to compress. >> >> A number of things are constrained by the need to always remove the >> RFC6553 Hop-by-Hop option RPI option which had been marked critical: >> i.e. drop packet if you don't understand it. >> >> As a result of the change in RFC2460bis, which says that intermediate hosts >> will in general not examine hop-by-hop options, but should just ignore >> them, we can make certain simplications to the useofrplinfo document. >> (rfc2460bis, section 4, page 8, "NOTE: While...) > You can already do that, because RFC7045 section 2.2 updates RFC2460: > " The IPv6 Hop-by-Hop Options header SHOULD be processed by > intermediate forwarding nodes as described in [RFC2460]." > which of course means that forwarding nodes MAY ignore HbH. It's not what *I* want to do, it's what *I* can expect *others* to do. So 7045 doesn't help me. > 00 - skip over this option and continue processing the header. A type=10 option was allocated by RFC6553 I think it was a mistake. We have discussed changing it as we add compression for 6553, 6554 and IPIP (which would be a flag day anyway). This was considered undesireable, because there was a desire not to leak our headers; that the internet would drop our packets if we screwed up. But, it turns out that the internet won't drop out packets, so we might as well optimize the situation so that if we don't need to remove our Hob-by-Hop header, then we don't need extra IPIP headers. -- Michael Richardson , Sandelman Software Works -= IPv6 IoT consulting =- --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 iQEVAwUBV44BZoCLcPvd0N1lAQLDrAgAvFKzmGFSAvAyAL7yRB1IkhiQpv0W/JA1 3OAxOlIpTBMZ/hRLSbfIzSePYFwAhI9IJc9eo5ecWidxjmpIQT/tjZwUIp6EiYP1 MfQpzSR0lsPiCfvYNAe5JViokwR24z2RMqCsGOCxmRmL7eHzloamzwehqwQr4oFo CZAd3VoZoIxXWAwvO/80tNaN8Z0qDhZiQsi263fvbS+sK0GCx4OOWZP8ryLHMDA9 JfAn1gfT5MuXJwK0ss2OWvbLH+bGn/h5vVqfTjL/kpKVYKzf49+mKyjAjFUdY6MP LYbeqWeWQQ4+XSxJOcyRH2txWdI/6XNIoSI0mFPr1bfIT12uMS+H+A== =Wkhf -----END PGP SIGNATURE----- --=-=-=-- From nobody Tue Jul 19 03:31:43 2016 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9729712B05A for ; Tue, 19 Jul 2016 03:31:41 -0700 (PDT) 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 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 N0MucOihg5hf for ; Tue, 19 Jul 2016 03:31:40 -0700 (PDT) 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 1957A12D0BF for ; Tue, 19 Jul 2016 03:31:40 -0700 (PDT) Received: from [IPv6:2001:67c:370:160:829:75a1:d800:dc03] (unknown [IPv6:2001:67c:370:160:829:75a1:d800:dc03]) (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 08886824CE; Tue, 19 Jul 2016 12:31:38 +0200 (CEST) Subject: Re: draft-ietf-6man-default-iids and RFC4291 To: Brian E Carpenter , Kerry Lynn References: <16e7823a-4847-6d6b-4bda-48e0812e9e04@gmail.com> <578DFA62.6020109@si6networks.com> <45ed6027-4dd5-4be6-f461-4a66f95df629@gmail.com> From: Fernando Gont X-Enigmail-Draft-Status: N1110 Message-ID: <578E0179.6010103@si6networks.com> Date: Tue, 19 Jul 2016 12:31:21 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.8.0 MIME-Version: 1.0 In-Reply-To: <45ed6027-4dd5-4be6-f461-4a66f95df629@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.17 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 Jul 2016 10:31:41 -0000 On 07/19/2016 12:14 PM, Brian E Carpenter wrote: [...] >>> >>> Agreed. My point was that 4291bis does *not* provide a normative fall >>> back; it just provides an "if" statement, which doesn't resolve Lorenzo's >>> issue about the choice left open by draft-ietf-6man-default-iids in its >>> current form. >> >> You mean for the case where a node employs non-stable only? > > Well, yes, or any case in which the implementor decides to "escape" from > draft-ietf-6man-default-iids for any other reason. My take is that if you decide not to follow the SHOULD in default-iids, you need to specify whatever algorithm you want to use (i.e., the nus is on the folk that decided not to follow default-iids). Regarding non-stable IIDs, I guess that "hole" is filled by the non-stable-iids I presented today? Cheers, -- Fernando Gont SI6 Networks e-mail: fgont@si6networks.com PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492 From nobody Tue Jul 19 04:08:46 2016 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9EBCA12D501 for ; Tue, 19 Jul 2016 04:08:45 -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 kkXGnNOtHYA1 for ; Tue, 19 Jul 2016 04:08:44 -0700 (PDT) Received: from mail-wm0-x231.google.com (mail-wm0-x231.google.com [IPv6:2a00:1450:400c: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 F2BE512D4FB for ; Tue, 19 Jul 2016 04:08:43 -0700 (PDT) Received: by mail-wm0-x231.google.com with SMTP id q128so15459005wma.1 for ; Tue, 19 Jul 2016 04:08:43 -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=g+0x8wi4yQcFUz5f3TY5WgyiorXNgFlm461HQWVjNsU=; b=bH+AnwBxOxFgM2+n3upOEbMd9kLhLgZ2RVLyN8tGVf8ePxp6x5YAXVdbQS4Vr1bsGf E/pESJi5cVlXppK98MsMt//a6504WgUD9CdDZn6HdIDkZSsIwBstQwdeVdhAQEIVuLto LdVzzIKG+oeWlcHG/ijGP+yvxW5MAyfIUH1TcN53LTJ8VSt4wo6TQ/UCBmuLOVhMTFQC zTrKHHWLYMNTAfT+5IeI1MKbGAceuYCozE7+VXvGg2SdAEtS16A+jj6zBZbnJ66WjRfM oV+Tt12JmiqFdqgiVIADmZM3Cz7yL34BUsUHipPgoZL8h73WGvy4QYwYNovtQKIGQEZD c17A== 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=g+0x8wi4yQcFUz5f3TY5WgyiorXNgFlm461HQWVjNsU=; b=d74Rhk0Cx4yPYZgpOd/T0FATMvgsJVQiPXPcQHiH0oJB+4Y94BHr3s5kO3cL3OgdYi u99W3l9IbM7AVZ+rgMBtBfg5sv2aKAVsIZpI258WXSOw0rlcaOyknRah7Z/R9xbf62LU O2l5rQ/bKXU8VFlDlXCfR9pmvRKTC/NwMZ1VHHf8yFKUHmqY4k7skqmlAVppVpzipN9K AjbfwkXuF4BAtpNjfRLg05XLVwuYF0HQKO7eG9CH3QrOrDPg9jsGUD5Jbv7JeO2C+a+J iuBX+/e62RmvsLwQoY818wGuIrkHhG30syHfjjdV8gx5D2Vt+xPZZifOlg1tHS8DHV6+ 290A== X-Gm-Message-State: ALyK8tI5OS3TjE5qKfzmAG4dLg5T8kN+0Oa6nm83F2CTomYVDKcm6F7+zlhgz9m4QYAFpA== X-Received: by 10.28.38.196 with SMTP id m187mr3316372wmm.81.1468926522471; Tue, 19 Jul 2016 04:08:42 -0700 (PDT) Received: from ?IPv6:2001:67c:370:176:28cc:dc4c:9703:6781? ([2001:67c:370:176:28cc:dc4c:9703:6781]) by smtp.gmail.com with ESMTPSA id d64sm5261881wmc.22.2016.07.19.04.08.41 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 19 Jul 2016 04:08:41 -0700 (PDT) Subject: Re: draft-ietf-6man-default-iids and RFC4291 To: Fernando Gont , Kerry Lynn References: <16e7823a-4847-6d6b-4bda-48e0812e9e04@gmail.com> <578DFA62.6020109@si6networks.com> <45ed6027-4dd5-4be6-f461-4a66f95df629@gmail.com> <578E0179.6010103@si6networks.com> From: Brian E Carpenter Organization: University of Auckland Message-ID: <7e9b8b17-fa89-fec9-42ba-fa7f582d9250@gmail.com> Date: Tue, 19 Jul 2016 23:08:44 +1200 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.2.0 MIME-Version: 1.0 In-Reply-To: <578E0179.6010103@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.17 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 Jul 2016 11:08:45 -0000 On 19/07/2016 22:31, Fernando Gont wrote: > On 07/19/2016 12:14 PM, Brian E Carpenter wrote: > [...] >>>> >>>> Agreed. My point was that 4291bis does *not* provide a normative fall >>>> back; it just provides an "if" statement, which doesn't resolve Lorenzo's >>>> issue about the choice left open by draft-ietf-6man-default-iids in its >>>> current form. >>> >>> You mean for the case where a node employs non-stable only? >> >> Well, yes, or any case in which the implementor decides to "escape" from >> draft-ietf-6man-default-iids for any other reason. > > My take is that if you decide not to follow the SHOULD in default-iids, > you need to specify whatever algorithm you want to use (i.e., the nus is > on the folk that decided not to follow default-iids). Yes. And for this, 4291bis doesn't define a default. > Regarding non-stable IIDs, I guess that "hole" is filled by the > non-stable-iids I presented today? Yes, I think so. Brian From nobody Tue Jul 19 04:14:50 2016 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B09C412B02B; Tue, 19 Jul 2016 04:14:45 -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 jE38ZbDEwS3s; Tue, 19 Jul 2016 04:14:44 -0700 (PDT) Received: from mail-lf0-x235.google.com (mail-lf0-x235.google.com [IPv6:2a00:1450:4010:c07::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 9CD6C12B057; Tue, 19 Jul 2016 04:05:44 -0700 (PDT) Received: by mail-lf0-x235.google.com with SMTP id b199so10925064lfe.0; Tue, 19 Jul 2016 04:05:44 -0700 (PDT) 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-transfer-encoding; bh=+HsL9aVKwCvPHY3O//I1f42Yzh722DBZoRa6Dj6vE5E=; b=ToI5gaTPuBvAo5ctQj7Sb4uMl7tBkaSCHIu4pM0s2gFQbTkdJUjiQN/xUosloGGL2p Yg6l87LLRVGGLiefinGHVbshO5LvXvUkOIxbJc4GYeIX2LjtQtwpFTefFGq/0clSqAva h68Bi8F/X36YQ+dujCC2ugommQBfSwKRMSnva6hhKq801xw9JbjqwAq70BAV/6WottGA 1sh85O5YCVGRMG9PDrjSDO1CWcm/02iLqSAexMnnYjgNwZEqp/kg73yMeyoJpYqDZjII KiaHUSVWxHi+0exBPhnG3FW/s5GTZrdwJem2hxsV5G5SY9Q4FKbKJd37feQhXJ0mAro7 weFA== 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-transfer-encoding; bh=+HsL9aVKwCvPHY3O//I1f42Yzh722DBZoRa6Dj6vE5E=; b=C+XzwBBbtG047CZboPuRktbEvw2Sojg/7GtT//xEJpUkSrhAFH91zq0dVC3xZPlVE5 c1eeATHSKhSvmkRL4OrdtdlkK1VMyhsTtPx5PNTFYiC66ydECQMtcjpwHVlIC+k2R9J8 j0CsMZCrptUIN+Ezsr7aTAEMQOsqBMw0PRqspIrU8qwEhf4hqcNLK/Ii1Quf4UI3cbHr x/TvwmKNxMQvei5rQRMh8iPSNyK7B7clDazHWdHH80+tXVOc+BuimnRhA5Eb4Dogzlyg vJmNyCA3XeWjedMLQSZJDc0+1EDmHD1OfaIHFuRH1wZXYPkATRZYFEXHvUU0K40PQZB1 ajpA== X-Gm-Message-State: ALyK8tK8eqaOdNNMtRFXphDqpc3u1sWtalDdFuYKsBdHN/ToCopi+28ZxM1r9DZhBsMdCA== X-Received: by 10.25.212.5 with SMTP id l5mr5958901lfg.73.1468926342730; Tue, 19 Jul 2016 04:05:42 -0700 (PDT) Received: from ?IPv6:2001:67c:370:176:28cc:dc4c:9703:6781? ([2001:67c:370:176:28cc:dc4c:9703:6781]) by smtp.gmail.com with ESMTPSA id 17sm5542994ljj.49.2016.07.19.04.05.41 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 19 Jul 2016 04:05:41 -0700 (PDT) Subject: Re: impacts of rfc2460bis on draft-ietf-roll-useofrplinfo To: Michael Richardson , roll@ietf.org, 6man@ietf.org References: <24554.1468868593@obiwan.sandelman.ca> <799ab640-bed0-22a6-a9df-97f78c3f0bf8@gmail.com> <30725.1468924267@obiwan.sandelman.ca> From: Brian E Carpenter Organization: University of Auckland Message-ID: Date: Tue, 19 Jul 2016 23:05:44 +1200 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.2.0 MIME-Version: 1.0 In-Reply-To: <30725.1468924267@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.17 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 Jul 2016 11:14:46 -0000 On 19/07/2016 22:31, Michael Richardson wrote: > > Brian E Carpenter wrote: > >> > >> The ROLL document draft-ietf-roll-useofrplinfo documents RFC6553 (a > >> Hop-by-Hop critical option) and 6554 (a form of Source Routing Header, RH3). > >> There is work on 6lo to allocate additional 6lowpan IPHC codes such that > >> the work in ROLL: > >> https://datatracker.ietf.org/doc/draft-ietf-roll-routing-dispatch/ can > >> know what kinds of things we need to compress. > >> > >> A number of things are constrained by the need to always remove the > >> RFC6553 Hop-by-Hop option RPI option which had been marked critical: > >> i.e. drop packet if you don't understand it. > >> > >> As a result of the change in RFC2460bis, which says that intermediate hosts > >> will in general not examine hop-by-hop options, but should just ignore > >> them, we can make certain simplications to the useofrplinfo document. > >> (rfc2460bis, section 4, page 8, "NOTE: While...) > > > You can already do that, because RFC7045 section 2.2 updates RFC2460: > > " The IPv6 Hop-by-Hop Options header SHOULD be processed by > > intermediate forwarding nodes as described in [RFC2460]." > > which of course means that forwarding nodes MAY ignore HbH. > > It's not what *I* want to do, it's what *I* can expect *others* to do. > So 7045 doesn't help me. Well, it legitimizes a router simply ignoring a HbH header. Isn't that useful? > > > 00 - skip over this option and continue processing the header. > > A type=10 option was allocated by RFC6553 > > I think it was a mistake. Agreed. Brian > We have discussed changing it as we add > compression for 6553, 6554 and IPIP (which would be a flag day anyway). > This was considered undesireable, because there was a desire not to leak > our headers; that the internet would drop our packets if we screwed up. > > But, it turns out that the internet won't drop out packets, so we might > as well optimize the situation so that if we don't need to remove our > Hob-by-Hop header, then we don't need extra IPIP headers. > > -- > Michael Richardson , Sandelman Software Works > -= IPv6 IoT consulting =- > > > From nobody Tue Jul 19 04:38:02 2016 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1E6BF12D0F5; Tue, 19 Jul 2016 04:37:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -15.808 X-Spam-Level: X-Spam-Status: No, score=-15.808 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.287, 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 Zqof3eRfrefz; Tue, 19 Jul 2016 04:37:54 -0700 (PDT) Received: from rcdn-iport-4.cisco.com (rcdn-iport-4.cisco.com [173.37.86.75]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2037712D0BF; Tue, 19 Jul 2016 04:37:54 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2996; q=dns/txt; s=iport; t=1468928274; x=1470137874; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=B5WntOcXl5Z1i9LNkhxrQa/xldw0K9lb/NnEf5b/zAk=; b=UIiMwLH9W2L5lmPKot+ZknfmIGNL1eEtdZvFz29EFt0Y7VuGeF3uQtRB 8AVy/DoD0mcTzVHUvx4/80b7zoadP77CfsXJkFEAlVGKeD/cyhqojiq7J HApxMzAvloGFvcL8b75XeRn/xMBfyDbHhYUEFOOklX4B341UlCHkfWmmu M=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0AABgAhEI5X/5FdJa1cgz9WfKxMjBqBe?= =?us-ascii?q?iKCQYM3AoEvOhIBAQEBAQEBZSeEXAEBBAEBAWwLBQsCAQgYLiEGCyUCBA4FiBY?= =?us-ascii?q?DDwgOuFQNhB4BAQEBAQEBAQEBAQEBAQEBAQEBAQEXBYYqgXiCVYJDgX2DLIIvB?= =?us-ascii?q?Y5Eiiw0AYYShjGCHo83iCWHeAElCiWDc24BiA8BAQE?= X-IronPort-AV: E=Sophos;i="5.28,389,1464652800"; d="scan'208";a="127460276" Received: from rcdn-core-9.cisco.com ([173.37.93.145]) by rcdn-iport-4.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 19 Jul 2016 11:37:53 +0000 Received: from XCH-RCD-002.cisco.com (xch-rcd-002.cisco.com [173.37.102.12]) by rcdn-core-9.cisco.com (8.14.5/8.14.5) with ESMTP id u6JBbr2h027809 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Tue, 19 Jul 2016 11:37:53 GMT Received: from xch-rcd-001.cisco.com (173.37.102.11) by XCH-RCD-002.cisco.com (173.37.102.12) with Microsoft SMTP Server (TLS) id 15.0.1210.3; Tue, 19 Jul 2016 06:37:52 -0500 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.1210.000; Tue, 19 Jul 2016 06:37:52 -0500 From: "Pascal Thubert (pthubert)" To: Routing Over Low power and Lossy networks Subject: Re: [Roll] impacts of rfc2460bis on draft-ietf-roll-useofrplinfo Thread-Topic: [Roll] impacts of rfc2460bis on draft-ietf-roll-useofrplinfo Thread-Index: AQHR4X59TqNb256fWESru62KIaaKWqAf4iWAgAAJrAD//7UpVw== Date: Tue, 19 Jul 2016 11:37:52 +0000 Message-ID: References: <24554.1468868593@obiwan.sandelman.ca> <799ab640-bed0-22a6-a9df-97f78c3f0bf8@gmail.com> <30725.1468924267@obiwan.sandelman.ca>, In-Reply-To: Accept-Language: fr-FR, en-US Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Cc: Michael Richardson , "6man@ietf.org" <6man@ietf.org> X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 Jul 2016 11:37:56 -0000 Actually Brian: What is really needed here is not for routers but for the end hosts to igno= re a HbH they are not programmed to recognize.=20 The new text says all nodes on the path do. This seems to include the recei= ver in which case we're good. This will not change that most open implementations of RPL (all but a proto= type implementing this draft) actually do header insertion. Regards, Pascal > Le 19 juil. 2016 =E0 13:14, Brian E Carpenter a =E9crit : >=20 >> On 19/07/2016 22:31, Michael Richardson wrote: >>=20 >> Brian E Carpenter wrote: >>>>=20 >>>> The ROLL document draft-ietf-roll-useofrplinfo documents RFC6553 (a >>>> Hop-by-Hop critical option) and 6554 (a form of Source Routing Header,= RH3). >>>> There is work on 6lo to allocate additional 6lowpan IPHC codes such th= at >>>> the work in ROLL: >>>> https://datatracker.ietf.org/doc/draft-ietf-roll-routing-dispatch/ can >>>> know what kinds of things we need to compress. >>>>=20 >>>> A number of things are constrained by the need to always remove the >>>> RFC6553 Hop-by-Hop option RPI option which had been marked critical: >>>> i.e. drop packet if you don't understand it. >>>>=20 >>>> As a result of the change in RFC2460bis, which says that intermediate = hosts >>>> will in general not examine hop-by-hop options, but should just ignore >>>> them, we can make certain simplications to the useofrplinfo document. >>>> (rfc2460bis, section 4, page 8, "NOTE: While...) >>=20 >>> You can already do that, because RFC7045 section 2.2 updates RFC2460: >>> " The IPv6 Hop-by-Hop Options header SHOULD be processed by >>> intermediate forwarding nodes as described in [RFC2460]." >>> which of course means that forwarding nodes MAY ignore HbH. >>=20 >> It's not what *I* want to do, it's what *I* can expect *others* to do. >> So 7045 doesn't help me. >=20 > Well, it legitimizes a router simply ignoring a HbH header. Isn't that us= eful? >=20 >>=20 >>> 00 - skip over this option and continue processing the header. >>=20 >> A type=3D10 option was allocated by RFC6553 >>=20 >> I think it was a mistake. >=20 > Agreed. > Brian >=20 >> We have discussed changing it as we add >> compression for 6553, 6554 and IPIP (which would be a flag day anyway). >> This was considered undesireable, because there was a desire not to leak >> our headers; that the internet would drop our packets if we screwed up. >>=20 >> But, it turns out that the internet won't drop out packets, so we might >> as well optimize the situation so that if we don't need to remove our >> Hob-by-Hop header, then we don't need extra IPIP headers. >>=20 >> -- >> Michael Richardson , Sandelman Software Works >> -=3D IPv6 IoT consulting =3D- >=20 > _______________________________________________ > Roll mailing list > Roll@ietf.org > https://www.ietf.org/mailman/listinfo/roll From nobody Tue Jul 19 04:43:15 2016 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D9F14126FDC; Tue, 19 Jul 2016 04:43:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -8.187 X-Spam-Level: X-Spam-Status: No, score=-8.187 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-1.287] 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 hx8aEkmGCOJ2; Tue, 19 Jul 2016 04:43:12 -0700 (PDT) Received: from zinfandel.tools.ietf.org (zinfandel.tools.ietf.org [IPv6:2001:1890:123a::1:2a]) (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 1EB2D12D0BF; Tue, 19 Jul 2016 04:43:12 -0700 (PDT) Received: from localhost ([::1]:49583 helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.82_1-5b7a7c0-XX) (envelope-from ) id 1bPTQb-0007fd-Ua; Tue, 19 Jul 2016 04:43:09 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "6man issue tracker" X-Trac-Version: 0.12.5 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.12.5, by Edgewall Software To: draft-ietf-6man-rfc1981bis@ietf.org, bob.hinden@gmail.com, otroan@employees.org X-Trac-Project: 6man Date: Tue, 19 Jul 2016 11:43:09 -0000 X-URL: https://tools.ietf.org/wg/6man/ Subject: Re: [6man] #13 (rfc1981bis): Regardless of whether it decrements the Hop Limit X-Trac-Ticket-URL: https://trac.tools.ietf.org/wg/6man/trac/ticket/13#comment:2 Message-ID: <078.0c4d2c6c2af8f36cb22231f7e4a9508a@trac.tools.ietf.org> References: <063.619648224ba7526b1a01dde1bfcb2e37@trac.tools.ietf.org> X-Trac-Ticket-ID: 13 In-Reply-To: <063.619648224ba7526b1a01dde1bfcb2e37@trac.tools.ietf.org> X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: draft-ietf-6man-rfc1981bis@ietf.org, bob.hinden@gmail.com, otroan@employees.org, 6man@ietf.org X-SA-Exim-Mail-From: trac+6man@trac.tools.ietf.org X-SA-Exim-Scanned: No (on zinfandel.tools.ietf.org); SAEximRunCond expanded to false Resent-To: draft-ietf-6man-rfc1981bis@ietf.org Resent-Message-Id: <20160719114312.1EB2D12D0BF@ietfa.amsl.com> Resent-Date: Tue, 19 Jul 2016 04:43:12 -0700 (PDT) Resent-From: trac+6man@trac.tools.ietf.org Archived-At: Cc: 6man@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.17 Reply-To: 6man@ietf.org List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 Jul 2016 11:43:14 -0000 #13: Regardless of whether it decrements the Hop Limit Changes (by otroan@employees.org): * status: new => closed * resolution: => wontfix -- -------------------------+------------------------------------------------- Reporter: | Owner: draft-ietf-6man- otroan@employees.org | rfc1981bis@ietf.org Type: defect | Status: closed Priority: major | Milestone: Component: rfc1981bis | Version: Severity: In WG Last | Resolution: wontfix Call | Keywords: | -------------------------+------------------------------------------------- Ticket URL: 6man From nobody Tue Jul 19 04:46:24 2016 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7214A12D1D1 for ; Tue, 19 Jul 2016 04:46:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -8.187 X-Spam-Level: X-Spam-Status: No, score=-8.187 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-1.287] 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 iKvCjBlGFSsv for ; Tue, 19 Jul 2016 04:46:21 -0700 (PDT) Received: from zinfandel.tools.ietf.org (zinfandel.tools.ietf.org [IPv6:2001:1890:123a::1:2a]) (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 DA2D912D1B8 for <6man@ietf.org>; Tue, 19 Jul 2016 04:46:21 -0700 (PDT) Received: from localhost ([::1]:50309 helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.82_1-5b7a7c0-XX) (envelope-from ) id 1bPTTh-0003Wq-GD; Tue, 19 Jul 2016 04:46:21 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "6man issue tracker" X-Trac-Version: 0.12.5 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.12.5, by Edgewall Software To: otroan@employees.org X-Trac-Project: 6man Date: Tue, 19 Jul 2016 11:46:21 -0000 X-URL: https://tools.ietf.org/wg/6man/ Subject: [6man] #15 (rfc2460bis): Inconsistent use of citations for updated-by documents X-Trac-Ticket-URL: https://trac.tools.ietf.org/wg/6man/trac/ticket/15 Message-ID: <063.b885e57935dabfebbd1a7b0f945add41@trac.tools.ietf.org> X-Trac-Ticket-ID: 15 X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: otroan@employees.org, 6man@ietf.org X-SA-Exim-Mail-From: trac+6man@trac.tools.ietf.org X-SA-Exim-Scanned: No (on zinfandel.tools.ietf.org); SAEximRunCond expanded to false Archived-At: Cc: 6man@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.17 Reply-To: 6man@ietf.org List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 Jul 2016 11:46:23 -0000 #15: Inconsistent use of citations for updated-by documents Inconsistent use of citations to updated text (e.g. no citations of RFC6564, RFC7522) -- ----------------------------------+----------------- Reporter: otroan@employees.org | Owner: Type: defect | Status: new Priority: minor | Milestone: Component: rfc2460bis | Version: Severity: In WG Last Call | Keywords: ----------------------------------+----------------- Ticket URL: 6man From nobody Tue Jul 19 04:47:18 2016 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CF21412D501; Tue, 19 Jul 2016 04:47:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -8.187 X-Spam-Level: X-Spam-Status: No, score=-8.187 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-1.287] 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 B6wuIzSnOdb6; Tue, 19 Jul 2016 04:47:13 -0700 (PDT) Received: from zinfandel.tools.ietf.org (zinfandel.tools.ietf.org [IPv6:2001:1890:123a::1:2a]) (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 515A912D1D3; Tue, 19 Jul 2016 04:47:13 -0700 (PDT) Received: from localhost ([::1]:50518 helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.82_1-5b7a7c0-XX) (envelope-from ) id 1bPTUX-00005P-2t; Tue, 19 Jul 2016 04:47:13 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "6man issue tracker" X-Trac-Version: 0.12.5 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.12.5, by Edgewall Software To: draft-ietf-6man-rfc4291bis@ietf.org, otroan@employees.org X-Trac-Project: 6man Date: Tue, 19 Jul 2016 11:47:13 -0000 X-URL: https://tools.ietf.org/wg/6man/ Subject: [6man] #16 (rfc4291bis): Consistency of citations X-Trac-Ticket-URL: https://trac.tools.ietf.org/wg/6man/trac/ticket/16 Message-ID: <063.d05aafbe4ec9aa2e420997eec8813db6@trac.tools.ietf.org> X-Trac-Ticket-ID: 16 X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: draft-ietf-6man-rfc4291bis@ietf.org, otroan@employees.org, 6man@ietf.org X-SA-Exim-Mail-From: trac+6man@trac.tools.ietf.org X-SA-Exim-Scanned: No (on zinfandel.tools.ietf.org); SAEximRunCond expanded to false Resent-To: draft-ietf-6man-rfc4291bis@ietf.org Resent-Message-Id: <20160719114713.515A912D1D3@ietfa.amsl.com> Resent-Date: Tue, 19 Jul 2016 04:47:13 -0700 (PDT) Resent-From: trac+6man@trac.tools.ietf.org Archived-At: Cc: 6man@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.17 Reply-To: 6man@ietf.org List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 Jul 2016 11:47:15 -0000 #16: Consistency of citations -- -------------------------+------------------------------------------------- Reporter: | Owner: draft-ietf-6man-rfc4291bis@ietf.org otroan@employees.org | Status: new Type: defect | Milestone: Priority: minor | Version: Component: rfc4291bis | Keywords: Severity: In WG Last | Call | -------------------------+------------------------------------------------- Ticket URL: 6man From nobody Tue Jul 19 04:48:13 2016 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8AA4712D1D3; Tue, 19 Jul 2016 04:48:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -8.187 X-Spam-Level: X-Spam-Status: No, score=-8.187 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-1.287] 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 U9Pe12uRMNiy; Tue, 19 Jul 2016 04:48:11 -0700 (PDT) Received: from zinfandel.tools.ietf.org (zinfandel.tools.ietf.org [IPv6:2001:1890:123a::1:2a]) (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 3AE5B12D1B8; Tue, 19 Jul 2016 04:48:11 -0700 (PDT) Received: from localhost ([::1]:50585 helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.82_1-5b7a7c0-XX) (envelope-from ) id 1bPTVT-0005nM-0G; Tue, 19 Jul 2016 04:48:11 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "6man issue tracker" X-Trac-Version: 0.12.5 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.12.5, by Edgewall Software To: draft-ietf-6man-rfc1981bis@ietf.org, otroan@employees.org X-Trac-Project: 6man Date: Tue, 19 Jul 2016 11:48:10 -0000 X-URL: https://tools.ietf.org/wg/6man/ Subject: [6man] #17 (rfc1981bis): Consistency of citations X-Trac-Ticket-URL: https://trac.tools.ietf.org/wg/6man/trac/ticket/17 Message-ID: <063.3c1cff841f76537f75ee7e9f4a5e0afb@trac.tools.ietf.org> X-Trac-Ticket-ID: 17 X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: draft-ietf-6man-rfc1981bis@ietf.org, otroan@employees.org, 6man@ietf.org X-SA-Exim-Mail-From: trac+6man@trac.tools.ietf.org X-SA-Exim-Scanned: No (on zinfandel.tools.ietf.org); SAEximRunCond expanded to false Resent-To: draft-ietf-6man-rfc1981bis@ietf.org Resent-Message-Id: <20160719114811.3AE5B12D1B8@ietfa.amsl.com> Resent-Date: Tue, 19 Jul 2016 04:48:11 -0700 (PDT) Resent-From: trac+6man@trac.tools.ietf.org Archived-At: Cc: 6man@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.17 Reply-To: 6man@ietf.org List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 Jul 2016 11:48:12 -0000 #17: Consistency of citations -- -------------------------+------------------------------------------------- Reporter: | Owner: draft-ietf-6man-rfc1981bis@ietf.org otroan@employees.org | Status: new Type: defect | Milestone: Priority: major | Version: Component: rfc1981bis | Keywords: Severity: In WG Last | Call | -------------------------+------------------------------------------------- Ticket URL: 6man From nobody Tue Jul 19 04:50:57 2016 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4FEF112D123 for ; Tue, 19 Jul 2016 04:50:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -8.187 X-Spam-Level: X-Spam-Status: No, score=-8.187 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-1.287] 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 1YmFDcruQ2b6 for ; Tue, 19 Jul 2016 04:50:53 -0700 (PDT) Received: from zinfandel.tools.ietf.org (zinfandel.tools.ietf.org [IPv6:2001:1890:123a::1:2a]) (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 C081D12D187 for <6man@ietf.org>; Tue, 19 Jul 2016 04:50:53 -0700 (PDT) Received: from localhost ([::1]:50659 helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.82_1-5b7a7c0-XX) (envelope-from ) id 1bPTY5-0000Ql-J7; Tue, 19 Jul 2016 04:50:53 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: "6man issue tracker" X-Trac-Version: 0.12.5 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.12.5, by Edgewall Software To: otroan@employees.org X-Trac-Project: 6man Date: Tue, 19 Jul 2016 11:50:53 -0000 X-URL: https://tools.ietf.org/wg/6man/ Subject: =?utf-8?q?=5B6man=5D_=2318_=28rfc2460bis=29=3A_Routing_header_sh?= =?utf-8?q?ould_be_added_to_=E2=80=9Cfull_implementation=E2=80=9D?= =?utf-8?q?_list=3F?= X-Trac-Ticket-URL: https://trac.tools.ietf.org/wg/6man/trac/ticket/18 Message-ID: <063.2ee166527d206b4a27af42eb56ddd139@trac.tools.ietf.org> X-Trac-Ticket-ID: 18 X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: otroan@employees.org, 6man@ietf.org X-SA-Exim-Mail-From: trac+6man@trac.tools.ietf.org X-SA-Exim-Scanned: No (on zinfandel.tools.ietf.org); SAEximRunCond expanded to false Archived-At: Cc: 6man@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.17 Reply-To: 6man@ietf.org List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 Jul 2016 11:50:55 -0000 #18: Routing header should be added to “full implementation” list? While text on RH0 is removed, hosts still need to implement routing header support. Regardless of RH0 deprecation. (Since hosts as the final destination does not have to support the specific header type). -- ----------------------------------+----------------- Reporter: otroan@employees.org | Owner: Type: defect | Status: new Priority: major | Milestone: Component: rfc2460bis | Version: Severity: In WG Last Call | Keywords: ----------------------------------+----------------- Ticket URL: 6man From nobody Tue Jul 19 04:52:12 2016 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 291FD12D539; Tue, 19 Jul 2016 04:52:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -8.187 X-Spam-Level: X-Spam-Status: No, score=-8.187 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-1.287] 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 diu7MhrC0G_r; Tue, 19 Jul 2016 04:52:09 -0700 (PDT) Received: from zinfandel.tools.ietf.org (zinfandel.tools.ietf.org [IPv6:2001:1890:123a::1:2a]) (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 966B312D1B8; Tue, 19 Jul 2016 04:52:09 -0700 (PDT) Received: from localhost ([::1]:50679 helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.82_1-5b7a7c0-XX) (envelope-from ) id 1bPTZJ-0000BV-E2; Tue, 19 Jul 2016 04:52:09 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "6man issue tracker" X-Trac-Version: 0.12.5 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.12.5, by Edgewall Software To: draft-ietf-6man-rfc1981bis@ietf.org, otroan@employees.org X-Trac-Project: 6man Date: Tue, 19 Jul 2016 11:52:09 -0000 X-URL: https://tools.ietf.org/wg/6man/ Subject: [6man] #19 (rfc1981bis): Remove RH0 text. X-Trac-Ticket-URL: https://trac.tools.ietf.org/wg/6man/trac/ticket/19 Message-ID: <063.9b93238756973457e04b2a7e6c93f73d@trac.tools.ietf.org> X-Trac-Ticket-ID: 19 X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: draft-ietf-6man-rfc1981bis@ietf.org, otroan@employees.org, 6man@ietf.org X-SA-Exim-Mail-From: trac+6man@trac.tools.ietf.org X-SA-Exim-Scanned: No (on zinfandel.tools.ietf.org); SAEximRunCond expanded to false Resent-To: draft-ietf-6man-rfc1981bis@ietf.org Resent-Message-Id: <20160719115209.966B312D1B8@ietfa.amsl.com> Resent-Date: Tue, 19 Jul 2016 04:52:09 -0700 (PDT) Resent-From: trac+6man@trac.tools.ietf.org Archived-At: Cc: 6man@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.17 Reply-To: 6man@ietf.org List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 Jul 2016 11:52:11 -0000 #19: Remove RH0 text. Remove references to RH0, replace with generic routing header text. -- -------------------------+------------------------------------------------- Reporter: | Owner: draft-ietf-6man-rfc1981bis@ietf.org otroan@employees.org | Status: new Type: defect | Milestone: Priority: major | Version: Component: rfc1981bis | Keywords: Severity: In WG Last | Call | -------------------------+------------------------------------------------- Ticket URL: 6man From nobody Tue Jul 19 04:53:19 2016 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8025112D501; Tue, 19 Jul 2016 04:53:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -8.187 X-Spam-Level: X-Spam-Status: No, score=-8.187 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-1.287] 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 7xedaqKVNThD; Tue, 19 Jul 2016 04:53:15 -0700 (PDT) Received: from zinfandel.tools.ietf.org (zinfandel.tools.ietf.org [IPv6:2001:1890:123a::1:2a]) (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 80A6612D56E; Tue, 19 Jul 2016 04:53:15 -0700 (PDT) Received: from localhost ([::1]:50706 helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.82_1-5b7a7c0-XX) (envelope-from ) id 1bPTaN-0000IQ-8b; Tue, 19 Jul 2016 04:53:15 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "6man issue tracker" X-Trac-Version: 0.12.5 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.12.5, by Edgewall Software To: draft-ietf-6man-rfc4291bis@ietf.org, otroan@employees.org X-Trac-Project: 6man Date: Tue, 19 Jul 2016 11:53:15 -0000 X-URL: https://tools.ietf.org/wg/6man/ Subject: [6man] #20 (rfc4291bis): Site-local X-Trac-Ticket-URL: https://trac.tools.ietf.org/wg/6man/trac/ticket/20 Message-ID: <063.b29004adee61477f53c85e1085499f4e@trac.tools.ietf.org> X-Trac-Ticket-ID: 20 X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: draft-ietf-6man-rfc4291bis@ietf.org, otroan@employees.org, 6man@ietf.org X-SA-Exim-Mail-From: trac+6man@trac.tools.ietf.org X-SA-Exim-Scanned: No (on zinfandel.tools.ietf.org); SAEximRunCond expanded to false Resent-To: draft-ietf-6man-rfc4291bis@ietf.org Resent-Message-Id: <20160719115315.80A6612D56E@ietfa.amsl.com> Resent-Date: Tue, 19 Jul 2016 04:53:15 -0700 (PDT) Resent-From: trac+6man@trac.tools.ietf.org Archived-At: Cc: 6man@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.17 Reply-To: 6man@ietf.org List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 Jul 2016 11:53:17 -0000 #20: Site-local Remove sections on site local addresses. What to do with ULA? -- -------------------------+------------------------------------------------- Reporter: | Owner: draft-ietf-6man-rfc4291bis@ietf.org otroan@employees.org | Status: new Type: defect | Milestone: Priority: major | Version: Component: rfc4291bis | Keywords: Severity: In WG Last | Call | -------------------------+------------------------------------------------- Ticket URL: 6man From nobody Tue Jul 19 05:11:16 2016 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7CBCD12D5DE for ; Tue, 19 Jul 2016 05:11:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.566 X-Spam-Level: X-Spam-Status: No, score=-0.566 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_SORBS_WEB=0.77, SPF_HELO_PASS=-0.001, SPF_SOFTFAIL=0.665] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=employees.org; domainkeys=pass (1024-bit key) header.from=otroan@employees.org header.d=employees.org 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 AqsO0aSnjOdC for ; Tue, 19 Jul 2016 05:11:12 -0700 (PDT) Received: from incoming.kjsl.com (inbound02.kjsl.com [IPv6:2001:1868:2002::144]) (using TLSv1.2 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4180A12D5D2 for ; Tue, 19 Jul 2016 05:11:12 -0700 (PDT) Received: from cowbell.employees.org ([65.50.211.142]) by ironport02.kjsl.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 19 Jul 2016 12:11:10 +0000 Received: from cowbell.employees.org (localhost [127.0.0.1]) by cowbell.employees.org (Postfix) with ESMTP id D89FA9CC4F; Tue, 19 Jul 2016 05:11:09 -0700 (PDT) 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=ib6MFi6xXnK+acqRxEUps483xpc=; b= OBNATlhJaKexm1RmBq/OZphfyDQjNrfCLoGBPzimnLNVgyLZjTKXwVlKxjsMuzgn pAT+Ml32xM3rijtcbstJeJF7MbftTvuiX1C967zChCukGxVDW7KsY7r4rAvDbzkh FG5sXlZDWs1W3i6Ggs6OP8cdybY7mG3au3THxwFHtfo= 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=ByEMppZk+WfIq6K0f3SOeC3JUb s48u2n8Z9pg0YOteCHWIyMpvC7PoWzqYrHZGfcl0K4XPEWjTJ/evT+SzXvlWVCrM /7EbhoRVKVwTzvUFFkevxphHuKYCX42ILD/y5wJVXQjvQt10Hz/2DEv/s/nnnJmu rM6OT3QfcAt+slVIQ= Received: from h.hanazo.no (unknown [212.185.100.101]) (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 987889CC4E; Tue, 19 Jul 2016 05:11:09 -0700 (PDT) Received: from [IPv6:::1] (localhost [IPv6:::1]) by h.hanazo.no (Postfix) with ESMTP id 12D922B1FDCF; Tue, 19 Jul 2016 14:11:04 +0200 (CEST) Subject: Re: draft-ietf-6man-default-iids and RFC4291 Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) Content-Type: multipart/signed; boundary="Apple-Mail=_A7E70ADE-ED9C-4751-B7D4-CB92C073A374"; protocol="application/pgp-signature"; micalg=pgp-sha512 X-Pgp-Agent: GPGMail From: otroan@employees.org In-Reply-To: <7e9b8b17-fa89-fec9-42ba-fa7f582d9250@gmail.com> Date: Tue, 19 Jul 2016 14:11:03 +0200 Message-Id: References: <16e7823a-4847-6d6b-4bda-48e0812e9e04@gmail.com> <578DFA62.6020109@si6networks.com> <45ed6027-4dd5-4be6-f461-4a66f95df629@gmail.com> <578E0179.6010103@si6networks.com> <7e9b8b17-fa89-fec9-42ba-fa7f582d9250@gmail.com> To: Brian E Carpenter X-Mailer: Apple Mail (2.3124) Archived-At: Cc: Fernando Gont , 6man WG X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 Jul 2016 12:11:15 -0000 --Apple-Mail=_A7E70ADE-ED9C-4751-B7D4-CB92C073A374 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii >> [...] >>>>>=20 >>>>> Agreed. My point was that 4291bis does *not* provide a normative = fall >>>>> back; it just provides an "if" statement, which doesn't resolve = Lorenzo's >>>>> issue about the choice left open by draft-ietf-6man-default-iids = in its >>>>> current form. >>>>=20 >>>> You mean for the case where a node employs non-stable only? >>>=20 >>> Well, yes, or any case in which the implementor decides to "escape" = from >>> draft-ietf-6man-default-iids for any other reason. >>=20 >> My take is that if you decide not to follow the SHOULD in = default-iids, >> you need to specify whatever algorithm you want to use (i.e., the nus = is >> on the folk that decided not to follow default-iids). >=20 > Yes. And for this, 4291bis doesn't define a default. Right, and I don't think leaving that open is a problem. In most of the implementations I work on the default is to require = manual configuration. Link-locals are created by modified EUI-64. I don't think we have any = intention of changing that. [...] Cheers, Ole --Apple-Mail=_A7E70ADE-ED9C-4751-B7D4-CB92C073A374 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 iQEcBAEBCgAGBQJXjhjXAAoJED4aXnjSQuKWsgYH/jl6rYEkdx5wEsxCWdxB0m69 RyM6glRSpKe3jegst7X6THGU+INTsvIc+ALtWFVhHoFnAQYxunL14baTiJK6MS2+ Ho4t1kAG3mpgc7aboaiHechf2U7zsyIHCFFTdDdVJ8hgLdG8ONNgGwlQ4+VJqXXO wJCiidC6hJljG8rYXZfgbprtPfRoK3Lu4+z3+fd7NXoBtpHmd0FYcsiCGZr5YupV fjeA6HQ+n245tScT6js78MrykuxaazonEbxq2Ocap+ot8xGFcnKgCwFBzbaXNkMT //mnn6biePVCfE9ulxoecoBj3Ovbweu93N9vL7zqWfh2uUQhaE2AaASdJ3vpR/g= =GhoU -----END PGP SIGNATURE----- --Apple-Mail=_A7E70ADE-ED9C-4751-B7D4-CB92C073A374-- From nobody Tue Jul 19 05:14:53 2016 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 73EEE12D0B1 for ; Tue, 19 Jul 2016 05:14:51 -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 xPccwFphiA74 for ; Tue, 19 Jul 2016 05:14:49 -0700 (PDT) Received: from mail-oi0-x22b.google.com (mail-oi0-x22b.google.com [IPv6:2607:f8b0:4003:c06::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 89B6312D0C8 for ; Tue, 19 Jul 2016 05:14:48 -0700 (PDT) Received: by mail-oi0-x22b.google.com with SMTP id w18so22251278oiw.3 for ; Tue, 19 Jul 2016 05:14:48 -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=pOX1cCkJphIfDM96x0Uo2zFSWEnqItY7bFv15XEMwf0=; b=pJHIevV/jJtd6Xboq24QFEAkrgMVREV8K0sfP96kMlXwWmPGzX8HIUnQdXaXiQ2pYE /Egmy2AZXniVKzyZhmAPI5jpWJzi1xW7tecce86iuyYguwvn3uHy+9zdB6c/4tnQcfT0 x6C1TYw4JwO5zL4zfEMgsXOMmxOWNoC4k5qYHRbalKzQ/T45O0uDPTwwG/ahUx0DKs3K XylLzESSIuirGgc0wdgxz6BSkgB5AQokSOwg/DIyYFj+kk7SIo5Po/J3gNwmglEUiMqX uLZi2IIukd8gEE6zWpJRSZxNGYFGwSUwNrhLONZVvPKIt6MTQ4dpniMA/klyVK0KSBgY xt9A== 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=pOX1cCkJphIfDM96x0Uo2zFSWEnqItY7bFv15XEMwf0=; b=BvvdtdQEHXj/1iPSk77uzhtCTHWPV/4lrxBuGWf7mDtlak/JQQ6D7oIxZ2phJR1/uP Z75MuSbeZWV1ORg703ooZJ+rciZQxnQVIrf4C+CrJjf+mTenc7zP3VEp8kc3k4Q+qSn2 VGXYP//jzekEkXofuLJZZS84mzCD1UW/cjcZjdvu8f0c3XMR2/1Tb4Jv0zcZvt87jMgC M4hRFbSXif/24xoG9nIOADXlCFrnOSab8W/Arj6H/ZP8p6bRwR5aYngBUnFG9MzmtCWR /wt4bAZ6bDUZOExQWwKGx7mbaIy3roRXKl/vSBMMAXyrnCCkJEepRvvqrVK/F/gGaTNW ADKA== X-Gm-Message-State: ALyK8tLc8j7jt7uR0VgZgBTAHibWzB6Rs8cChxOkBx2Smey9TWTGiNNz0jS70/Rw+uR7wSu+yrkhY7O7YJZEPQ== X-Received: by 10.202.245.214 with SMTP id t205mr9033344oih.202.1468930487966; Tue, 19 Jul 2016 05:14:47 -0700 (PDT) MIME-Version: 1.0 Received: by 10.182.172.66 with HTTP; Tue, 19 Jul 2016 05:14:47 -0700 (PDT) In-Reply-To: <6c26fb03-7218-ff28-3488-887f6cd0f1fe@gmail.com> References: <20160701153641.24636.69476.idtracker@ietfa.amsl.com> <8cb3aa9b-e157-794b-2dbf-f63e20cfdc62@innovationslab.net> <6c26fb03-7218-ff28-3488-887f6cd0f1fe@gmail.com> From: Hemant Singh Date: Tue, 19 Jul 2016 08:14:47 -0400 Message-ID: Subject: Re: Reference to "3333" value of RFC2464 "IPv6 over Ethernet" To: Alexandre Petrescu Content-Type: multipart/alternative; boundary=001a113df090ef609d0537fc07f9 Archived-At: Cc: IPv6 X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 Jul 2016 12:14:51 -0000 --001a113df090ef609d0537fc07f9 Content-Type: text/plain; charset=UTF-8 Sorry for the delayed reply. I read IETF emails sporadically. See section 2.3.1 of RFC7042 for the definition. IANA has also reserved the address. http://www.iana.org/assignments/ethernet-numbers/ethernet-numbers.xhtml#ethernet-numbers-3 Search at the above URL for rfc7042 and you will find the IPv6 multicast mac first two octets in 3333. Hemant On Fri, Jul 8, 2016 at 9:56 AM, Alexandre Petrescu < alexandre.petrescu@gmail.com> wrote: > > Where is this "3333" value defined? Obviously an RFC is not the place to > define an Ethernet multicast address. > > Alex > > -------------------------------------------------------------------- > IETF IPv6 working group mailing list > ipv6@ietf.org > Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 > -------------------------------------------------------------------- > --001a113df090ef609d0537fc07f9 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Sorry for the delayed reply.=C2=A0 I read IETF emails spor= adically.=C2=A0 See section 2.3.1 of RFC7042 for the definition.=C2=A0 IANA= has also reserved the address.


Search at the above URL fo= r rfc7042 and you will find the IPv6 multicast mac first two octets in 3333= .

Hemant

On Fri, Jul 8, 2016 at 9:56 AM, Alexandre Petrescu <alexandre.petrescu@gmail.com> wrote:

Where is this "3333" value defined?=C2=A0 Obviously an RFC is not= the place to define an Ethernet multicast address.

Alex

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

--001a113df090ef609d0537fc07f9-- From nobody Tue Jul 19 05:17:42 2016 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6C2BD12D60B for ; Tue, 19 Jul 2016 05:17:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.336 X-Spam-Level: X-Spam-Status: No, score=-1.336 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, SPF_HELO_PASS=-0.001, SPF_SOFTFAIL=0.665] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=employees.org; domainkeys=pass (1024-bit key) header.from=otroan@employees.org header.d=employees.org 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 xt8xnMEdyEGl for ; Tue, 19 Jul 2016 05:17:39 -0700 (PDT) Received: from incoming.kjsl.com (inbound02.kjsl.com [IPv6:2001:1868:2002::144]) (using TLSv1.2 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5381B12D60A for ; Tue, 19 Jul 2016 05:17:38 -0700 (PDT) Received: from cowbell.employees.org ([IPv6:2001:1868:a000:17::142]) by ironport02.kjsl.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 19 Jul 2016 12:17:37 +0000 Received: from cowbell.employees.org (localhost [127.0.0.1]) by cowbell.employees.org (Postfix) with ESMTP id AB8149CC4F; Tue, 19 Jul 2016 05:17:36 -0700 (PDT) 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=R0QysoX1NsV1Ca9D8CrHlbyvjaU=; b= q//y7X8tYuL3D5V5PzzB31DVGT7DR9JtI592Sv8s/5Ad++x+mqKgcykHS40nwimj wSsnpTS6wu4xk0HuB4wP3b/xtFMNpf1p9zWAtpQu05hMZR31SaXPh4Hy6vmROvFk s9/jNrWHuEyOg0LveXeChqX16YPbIzmMEG2CH7tWs8w= 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=k7d+eqHxPNeIO3GgUaoto1T4ZX fsbHX6+sPHUcwgEnWwRbwd29O7iYvnocymUxGBqbwlJt9ErGlX/YAC/s/H+BH25B oqsgzup4zPkVfPa7rHQ94BfTEcyA0Ek3k7dbcLiBkmFCovuUFU3xtGWuKCpf5AmO HvYyW+v8C227A+9cA= Received: from h.hanazo.no (unknown [212.185.100.101]) (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 4E89F9CC4E; Tue, 19 Jul 2016 05:17:36 -0700 (PDT) Received: from [IPv6:::1] (localhost [IPv6:::1]) by h.hanazo.no (Postfix) with ESMTP id 5130E2B225B2; Tue, 19 Jul 2016 14:17:30 +0200 (CEST) Subject: Re: HbH used by Router Alert in MLDv2? Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) Content-Type: multipart/signed; boundary="Apple-Mail=_AF0AA066-952E-4C25-9F92-A6779E38F866"; protocol="application/pgp-signature"; micalg=pgp-sha512 X-Pgp-Agent: GPGMail From: otroan@employees.org In-Reply-To: Date: Tue, 19 Jul 2016 14:17:30 +0200 Message-Id: <94EE6767-6B5F-47C3-90E5-E3BCF82011E0@employees.org> References: <16e7823a-4847-6d6b-4bda-48e0812e9e04@gmail.com> To: Alexandre Petrescu X-Mailer: Apple Mail (2.3124) Archived-At: Cc: 6man WG X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 Jul 2016 12:17:41 -0000 --Apple-Mail=_AF0AA066-952E-4C25-9F92-A6779E38F866 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Alex, > I suspect HbH is used in Router Alert options and MLDv2, which is used = at computer startup to signal presence and belonging to some multicast = groups needed later by ND. >=20 > If so, then the RFC2460bis suggested modifications would imply that = all computers would have to be specifically enabled to continue use this = HbH? Wouldn't it only be multicast routers that would need to do that? If I remember correctly non-multicast routers do not listen to MLD and = multicast routers do ignore MLD reports for link-local multicast = addresses. (As discussed on a different thread it is arguable how much = value there is in sending MLD reports for link-local multicast in the = first place). Cheers, Ole --Apple-Mail=_AF0AA066-952E-4C25-9F92-A6779E38F866 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 iQEcBAEBCgAGBQJXjhpaAAoJED4aXnjSQuKWLToIAIdC56K8GWlR0w9S/c/58DJg 7BqnYs/tFgt9FUd3LNFBc4TQ9ARHsoKDq73iAI8NwGA7PVPW25y/VVDvfee/5tnT /E8pWGWq05DIFLznkYWd1ShtPSqoeYrqyQGl2ukXi7MgdwKbfKKQrHuAWUm3lsmK bIcnIqX29PUAfWwW7uLQoL/HyMQ+hG087omkaWRljSNKzddeop0Bs1/kOpVml4Oo ff9MIkvmDym2Ky4Ww4RSkuN6QnjhCw5tpKaSYctxnbJKIOo+6+dsCsIo9GqTolpK BJQhV+UuGraOHPSzQJ9b2V5Asq3rhrA7C9DGDxz6gCQpNU6Jb9e+OeYDDtiCCKE= =lIT3 -----END PGP SIGNATURE----- --Apple-Mail=_AF0AA066-952E-4C25-9F92-A6779E38F866-- From nobody Tue Jul 19 05:22:12 2016 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6525712D5D3 for ; Tue, 19 Jul 2016 05:22:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -15.808 X-Spam-Level: X-Spam-Status: No, score=-15.808 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.287, 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 u3eJfusa5iVQ for ; Tue, 19 Jul 2016 05:22:08 -0700 (PDT) Received: from alln-iport-8.cisco.com (alln-iport-8.cisco.com [173.37.142.95]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 383ED12D61C for ; Tue, 19 Jul 2016 05:22:07 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1504; q=dns/txt; s=iport; t=1468930927; x=1470140527; h=from:to:subject:date:message-id:references:in-reply-to: content-id:content-transfer-encoding:mime-version; bh=slAqHnTpBKsRHToA/veUMdchaqC8jfvMeRrJCg8YKBQ=; b=iJAKNttqgw9p4cHS8Dp/uh/GPYtgqJCziAU8ov8s4OpRB5jDK4xkli18 /E+uSeGdUjd82hxBAMxf1IojDCyacfI9Bfr1cetZtbnDGOal13BC4VCV3 yqBqblP5cwuRhFgrGiZDF6K4qkKzYGn4br5EhbTpRjdeoEzVLWsJrnOzf 4=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0BWAgDHGo5X/4wNJK1cgz9WfAasR4wag?= =?us-ascii?q?XoihXgCHIETOBQBAQEBAQEBZSeEXQEFAQEhETobAgEIGgImAgICHwYLFQsFAgQ?= =?us-ascii?q?BEogWAxcOrlyJXg2EHgEBAQEBAQEBAQEBAQEBAQEBAQEZBYEBhSmETYJDgX0Xg?= =?us-ascii?q?mqCWgWIH5BRNAGMQ4IejzeIJYd4AR42g3NuhxF/AQEB?= X-IronPort-AV: E=Sophos;i="5.28,389,1464652800"; d="scan'208";a="299430838" Received: from alln-core-7.cisco.com ([173.36.13.140]) by alln-iport-8.cisco.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 19 Jul 2016 12:22:06 +0000 Received: from XCH-RTP-014.cisco.com (xch-rtp-014.cisco.com [64.101.220.154]) by alln-core-7.cisco.com (8.14.5/8.14.5) with ESMTP id u6JCM6Nf011067 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Tue, 19 Jul 2016 12:22:06 GMT Received: from xch-rtp-015.cisco.com (64.101.220.155) by XCH-RTP-014.cisco.com (64.101.220.154) with Microsoft SMTP Server (TLS) id 15.0.1210.3; Tue, 19 Jul 2016 08:22:05 -0400 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.1210.000; Tue, 19 Jul 2016 08:22:05 -0400 From: "Eric Vyncke (evyncke)" To: Alexandre Petrescu , "ipv6@ietf.org" Subject: Re: HbH used by Router Alert in MLDv2? Thread-Topic: HbH used by Router Alert in MLDv2? Thread-Index: AQHR4aZ7Lkf6Gm5wCUaod7MaTo12dqAgEaaA Date: Tue, 19 Jul 2016 12:22:05 +0000 Message-ID: References: <16e7823a-4847-6d6b-4bda-48e0812e9e04@gmail.com> In-Reply-To: Accept-Language: fr-FR, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.6.3.160329 x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.61.240.222] 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.17 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 Jul 2016 12:22:10 -0000 QUZBSUsgTm8sIGJlY2F1c2Ugb25seSBNTEQgbGlzdGVuZXJzIHdpbGwgYWN0dWFsbHkgcmVjZWl2 ZSB0aGUgcGFja2V0DQooaS5lLiBUaGV5IGFyZSBtZW1iZXIgb2YgdGhlIGRlc3RpbmF0aW9uIGdy b3VwKSBhbmQgbm90IGZvcndhcmQgdGhpcw0KcGFja2V0IGFueXdheSBhcyBNTEQgcGFja2V0cyBh cmUgbm90IGZvcndhcmRlZC4NCg0KU28sIHRoZSBIYkggaXMgcmF0aGVyIHVzZWxlc3MgYXMgYSB0 cmlnZ2VyIGluIHRoaXMgY2FzZSBiZWNhdXNlIE1MRA0Kcm91dGVycyB3aWxsIGhhdmUgdG8gcGFy c2UgYW55d2F5IHRoZSBmdWxsIGNoYWluIGFzIHRoZXkgcmVjZWl2ZSBpdA0KDQotw6lyaWMNCg0K T24gMTkvMDcvMTYgMTI6MTQsICJpcHY2IG9uIGJlaGFsZiBvZiBBbGV4YW5kcmUgUGV0cmVzY3Ui DQo8aXB2Ni1ib3VuY2VzQGlldGYub3JnIG9uIGJlaGFsZiBvZiBhbGV4YW5kcmUucGV0cmVzY3VA Z21haWwuY29tPiB3cm90ZToNCg0KPkhpLA0KPg0KPkkgc3VzcGVjdCBIYkggaXMgdXNlZCBpbiBS b3V0ZXIgQWxlcnQgb3B0aW9ucyBhbmQgTUxEdjIsIHdoaWNoIGlzIHVzZWQNCj5hdCBjb21wdXRl ciBzdGFydHVwIHRvIHNpZ25hbCBwcmVzZW5jZSBhbmQgYmVsb25naW5nIHRvIHNvbWUgbXVsdGlj YXN0DQo+Z3JvdXBzIG5lZWRlZCBsYXRlciBieSBORC4NCj4NCj5JZiBzbywgdGhlbiB0aGUgUkZD MjQ2MGJpcyBzdWdnZXN0ZWQgbW9kaWZpY2F0aW9ucyB3b3VsZCBpbXBseSB0aGF0IGFsbA0KPmNv bXB1dGVycyB3b3VsZCBoYXZlIHRvIGJlIHNwZWNpZmljYWxseSBlbmFibGVkIHRvIGNvbnRpbnVl IHVzZSB0aGlzIEhiSD8NCj4NCj5BbGV4DQo+DQo+LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0NCj5JRVRGIElQdjYgd29y a2luZyBncm91cCBtYWlsaW5nIGxpc3QNCj5pcHY2QGlldGYub3JnDQo+QWRtaW5pc3RyYXRpdmUg UmVxdWVzdHM6IGh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vaXB2Ng0KPi0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tDQoNCg== From nobody Tue Jul 19 05:32:51 2016 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6DB6D12D670 for ; Tue, 19 Jul 2016 05:32:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.336 X-Spam-Level: X-Spam-Status: No, score=-1.336 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, SPF_HELO_PASS=-0.001, SPF_SOFTFAIL=0.665] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=employees.org; domainkeys=pass (1024-bit key) header.from=otroan@employees.org header.d=employees.org 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 eEoqZSmGSzzj for ; Tue, 19 Jul 2016 05:32:47 -0700 (PDT) Received: from incoming.kjsl.com (inbound02.kjsl.com [IPv6:2001:1868:2002::144]) (using TLSv1.2 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D6A4312D67B for <6man@ietf.org>; Tue, 19 Jul 2016 05:32:41 -0700 (PDT) Received: from cowbell.employees.org ([IPv6:2001:1868:a000:17::142]) by ironport02.kjsl.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 19 Jul 2016 12:32:41 +0000 Received: from cowbell.employees.org (localhost [127.0.0.1]) by cowbell.employees.org (Postfix) with ESMTP id 29E799CC7C; Tue, 19 Jul 2016 05:32:37 -0700 (PDT) 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=wkZGgDqgEwmDgi3QfUWhYVvLR9I=; b= tIjcVYvIhmovabw1f4TRxEH9OBlBUm2IbcPyrmzbNJketJ1Kpo5lvZmf4dy0LmCQ N7ZTfd62lPWNTEmQnwLpi7cKsZBDSfG5IryD7uYN3wHxcKXad20rUcsWrIAsKlnR 6Xy3EA5lo63hjPYUP/yj5ztHuoKHLzw8s6ILLbcO2tg= 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=sKlHBN0DM6ICLMX8jJuD8N95kr lYOdHNtwtCire1MOF4vFdX3yAj475pdJi+K6FXW2yvX4RDZo9nS0rcR6SPP9Vcal mug7unzPM4aL3Cxvgt+vglrLHXU8mR5ld228G7Zjg5D88+e8YpzHnLmlf15Ddpdp ewiOuXAwM2LvF/oVk= Received: from h.hanazo.no (unknown [212.185.100.101]) (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 A9FE89CC4E; Tue, 19 Jul 2016 05:32:36 -0700 (PDT) Received: from [IPv6:::1] (localhost [IPv6:::1]) by h.hanazo.no (Postfix) with ESMTP id 736712B282CA; Tue, 19 Jul 2016 14:32:34 +0200 (CEST) Subject: Re: 2460bis - section 4.2 -- hop-by-hop option writeup. Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) Content-Type: multipart/signed; boundary="Apple-Mail=_FEE34488-84A9-403F-8321-B5DDC220225B"; protocol="application/pgp-signature"; micalg=pgp-sha512 X-Pgp-Agent: GPGMail From: otroan@employees.org In-Reply-To: <26148.1468914385@obiwan.sandelman.ca> Date: Tue, 19 Jul 2016 14:32:33 +0200 Message-Id: References: <26148.1468914385@obiwan.sandelman.ca> To: Michael Richardson X-Mailer: Apple Mail (2.3124) Archived-At: Cc: 6man@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 Jul 2016 12:32:49 -0000 --Apple-Mail=_FEE34488-84A9-403F-8321-B5DDC220225B Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Michael, > While I recognize that section 4 has text: >=20 > NOTE: While [RFC2460] required that all nodes must examine and > process the Hop-by-Hop Options header, it is now expected that nodes > along a packet's delivery path only examine and process the Hop-by- > Hop Options header if explicitly configured to do so. >=20 > which means that most nodes will never look at the Hop-by-Hop header, = I > thought that section 4.2 was going to going to obsolete the discard > actions-when-not-understood. Aside from making it clearer that the = packets > will almost never be dropped, doing so eventually 4x the number of = hop-by-hop > option numbes available. >=20 > I think that we agreed to change this, then I guess the decision was = that the > NOTE: above solved it all, and we decided not to change this part? > I'd prefer to change this text. >=20 > I'd write: >=20 > --- /tmp/k6 2016-07-19 03:43:57.287438396 -0400 > +++ /tmp/k7 2016-07-19 03:45:15.751903442 -0400 > @@ -1,19 +1,7 @@ > - The Option Type identifiers are internally encoded such that their > - highest-order two bits specify the action that must be taken if = the > - processing IPv6 node does not recognize the Option Type: > + The Option Type identifiers were previously internally encoded = such that > + the highest-order two bits specified an action that must be taken = if the > + processing IPv6 node did not recognize the option type. > + The recommended action (in the absense of an explicitely = configured ACL), > + is that unknown hop-by-hop options are simply skipped, and the = next header > + is examined. >=20 > - > - > - 00 - skip over this option and continue processing the header. > - > - 01 - discard the packet. > - > - 10 - discard the packet and, regardless of whether or not the > - packet's Destination Address was a multicast address, send = an > - ICMP Parameter Problem, Code 2, message to the packet's > - Source Address, pointing to the unrecognized Option Type. > - > - 11 - discard the packet and, only if the packet's Destination > - Address was not a multicast address, send an ICMP = Parameter > - Problem, Code 2, message to the packet's Source Address, > - pointing to the unrecognized Option Type. I don't think we can do this in 2460bis. The option flags are also used = for the Destination options header. There is anyway legacy implementations, meaning that new options cannot = reuse the space. For your particular problem, it sounds like you don't really want a = mandatory option, why not reclassify the RPL option instead of trying to = make 2460 fit the corner you've been painted into :-)). While other options e.g. the jumbo option really does require mandatory = behaviour... Of course making processing the whole header optional, makes failing to = enable it in the jumbo case a configuration error. The compromise here, apart from trying to shoehorn the changes within = the limitations of 6410, is to allow limited domains to use HBH as = defined in 2460, while at the same time let the open Internet ignore and = forward. Cheers, Ole --Apple-Mail=_FEE34488-84A9-403F-8321-B5DDC220225B 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 iQEcBAEBCgAGBQJXjh3iAAoJED4aXnjSQuKWJFwH/i5EROlEAIEJkg5RdRgZhrEU /qzLlMBJr40zZ1pac+6Cz+5SYrj+5f64xcNTKfuD1bEyEHk/mlO22rCX7OgMpAIt ewtAh/+WbsY/kjhq9aC6oyYsuex9RadFEoRRkg/MhufG/dSQgrvVr056vJrHT8QD F45bH5ifA9Imq6F9V4AuM8mtlQFLrMSGW+H4sWXzp9NEf93IrjZ56R8FXl7+rqLq Uadt719oP6bDV0NWdOuDtxEdAfYqk/D86XO4tilJY4ZG0oAdPWdCMAJ0stoeomRS 4/5DIe9UWRn2SqDHUmWszC+7AIjzpiIWZUTwU4v98yxCYcr3Ypqjcgp3lET43Es= =OH6L -----END PGP SIGNATURE----- --Apple-Mail=_FEE34488-84A9-403F-8321-B5DDC220225B-- From nobody Tue Jul 19 05:33:39 2016 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B14D512D697 for ; Tue, 19 Jul 2016 05:33:37 -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=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=venaas-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 n_rnUysgeqy0 for ; Tue, 19 Jul 2016 05:33:35 -0700 (PDT) Received: from mail-lf0-x22c.google.com (mail-lf0-x22c.google.com [IPv6:2a00:1450:4010:c07::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 A618A12D670 for ; Tue, 19 Jul 2016 05:33:33 -0700 (PDT) Received: by mail-lf0-x22c.google.com with SMTP id f93so12881479lfi.2 for ; Tue, 19 Jul 2016 05:33:33 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=venaas-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=eaJeJsnA/VJ5Sc1JS6e0NwF09r69f0Ja8oIT9cCcF9U=; b=SGCHbCMC9ia6dR5SO9dXiyLEUmOmwWjQcFc5VPe72UFEiiNfJ9VdKtD4OfiLSN4XQX wdpwTzljyAvo+lidb6SJD8F0Y8zQNJwW1p7Ijtm06rNZ+S0PHC4Y4QdWRlwNyG2VtVZF r5yAa9nlcZiF1jVvbRAQNJq9Q8/6tG/rbR0ORO21xsKLcELmH0asrF/GtShu90p2jMa0 2lPQ5TaxJFWZUMqNEFM4UyHDOXDgJ5oefTVXqhTNHZd0LPCJhr2S/fvnwS4/Y4GbRFx2 EKPrgaAB/FigkabfkcIyqsg8TYhHdCJn2Fl+Oq+U4Zo4P1Co4rXyeyu7PB39dqZAXWc8 R+IQ== 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-transfer-encoding; bh=eaJeJsnA/VJ5Sc1JS6e0NwF09r69f0Ja8oIT9cCcF9U=; b=ZwDL21WEKggCL2ZRIMIUn6CQJRc1i9bE4Oqa+ZHNtTDjwkcUuiFzh66wbYNHg0qONC k7pxp0uUSuRhevidOMBxPiXCT1iEfkuvAwnvNAjfNR/pMn5sbsFawloB+0L2oPDNmrcQ NlSWdMA/XDZiIRKy2F1znBSd/5OEAW+FFzZHeCBU2S+fbHRVrgwSZE0z+NVaNieK9kHA O3HNCp2Lcu9IY8B6t5EKkQO+rGcA+gQLJ/5VVYvQi1PeSGM/3mDNddAI+0QnSMgf0Apy dyABwzpzorEestZgdygOv9zufjEv4B7ayVWRWqpuRQtbPcOLhWMKcuQHwqgFeq4doK7m d+jw== X-Gm-Message-State: ALyK8tLmMf5Q6OyPUxNllJlA0PmLOrYjc2Amm1ZbMGpxQLx40SUo7v9qAnoO8j+gdc0HAAYpK6nJerJ4z3mEcw== X-Received: by 10.25.40.141 with SMTP id o135mr17211764lfo.151.1468931611669; Tue, 19 Jul 2016 05:33:31 -0700 (PDT) MIME-Version: 1.0 Received: by 10.25.165.72 with HTTP; Tue, 19 Jul 2016 05:33:31 -0700 (PDT) In-Reply-To: References: <16e7823a-4847-6d6b-4bda-48e0812e9e04@gmail.com> From: Stig Venaas Date: Tue, 19 Jul 2016 05:33:31 -0700 Message-ID: Subject: Re: HbH used by Router Alert in MLDv2? To: "Eric Vyncke (evyncke)" Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Archived-At: Cc: Alexandre Petrescu , "ipv6@ietf.org" X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 Jul 2016 12:33:38 -0000 Router Alert is required in MLD messages, but I don't see much point. I wonder if it could be used as a way to prevent forwarding though. That is, if someone tries to illegally send an MLD packet to a remote unicast address or non-link-local group address, then this could make it easier for the local router to discard it. Of course someone trying to do something bad could send an MLD report without RA. I suspect receivers may not check for presence of RA. Stig On Tue, Jul 19, 2016 at 5:22 AM, Eric Vyncke (evyncke) wrote: > AFAIK No, because only MLD listeners will actually receive the packet > (i.e. They are member of the destination group) and not forward this > packet anyway as MLD packets are not forwarded. > > So, the HbH is rather useless as a trigger in this case because MLD > routers will have to parse anyway the full chain as they receive it > > -=C3=A9ric > > On 19/07/16 12:14, "ipv6 on behalf of Alexandre Petrescu" > wrote: > >>Hi, >> >>I suspect HbH is used in Router Alert options and MLDv2, which is used >>at computer startup to signal presence and belonging to some multicast >>groups needed later by ND. >> >>If so, then the RFC2460bis suggested modifications would imply that all >>computers would have to be specifically enabled to continue use this HbH? >> >>Alex >> >>-------------------------------------------------------------------- >>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 Jul 19 05:58:50 2016 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D097512D80E for ; Tue, 19 Jul 2016 05:58:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.601 X-Spam-Level: X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] 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 C5kd3CGydXGO for ; Tue, 19 Jul 2016 05:58:45 -0700 (PDT) Received: from mx1.ernw.net (mx1.ernw.net [62.159.96.78]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 57E9712D83D for ; Tue, 19 Jul 2016 05:55:50 -0700 (PDT) Received: from mail1.ernw.net (unknown [IPv6:fd00:2001:0:d001::30]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "mail1.ernw.net", Issuer "ernw ca1" (verified OK)) by mx1.ernw.net (Postfix) with ESMTPS id 6A2FB27393; Tue, 19 Jul 2016 14:55:48 +0200 (CEST) Received: from ws26.ernw.net (unknown [172.31.1.70]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (Client CN "ws26.ernw.net", Issuer "ernw ca1" (verified OK)) by mail1.ernw.net (Postfix) with ESMTPS id 308483B11FE; Tue, 19 Jul 2016 14:55:48 +0200 (CEST) Received: by ws26.ernw.net (Postfix, from userid 1002) id 2268E9E7A; Tue, 19 Jul 2016 14:55:48 +0200 (CEST) Date: Tue, 19 Jul 2016 14:55:48 +0200 From: Enno Rey To: Stig Venaas Subject: Re: HbH used by Router Alert in MLDv2? Message-ID: <20160719125548.GI78053@ernw.de> References: <16e7823a-4847-6d6b-4bda-48e0812e9e04@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.24 (2015-08-30) Archived-At: Cc: "ipv6@ietf.org" , Alexandre Petrescu X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 Jul 2016 12:58:49 -0000 Hi, On Tue, Jul 19, 2016 at 05:33:31AM -0700, Stig Venaas wrote: > Router Alert is required in MLD messages, but I don't see much point. > I wonder if it could be used as a way to prevent forwarding though. > That is, if someone tries to illegally send an MLD packet to a remote > unicast address or non-link-local group address, then this could make > it easier for the local router to discard it. Of course someone trying > to do something bad could send an MLD report without RA. I suspect > receivers may not check for presence of RA. your assumption is correct. As of https://www.its.fh-muenster.de/doc/Security_Implications_of_MLD_in_IPv6_Networks.pdf there's a number of MLD implementations that do *not* care for the presence of RA. more precisely: at the time of lab testing there were some implementations. I doubt this has changed in the interim though. best Enno > > Stig > > > On Tue, Jul 19, 2016 at 5:22 AM, Eric Vyncke (evyncke) > wrote: > > AFAIK No, because only MLD listeners will actually receive the packet > > (i.e. They are member of the destination group) and not forward this > > packet anyway as MLD packets are not forwarded. > > > > So, the HbH is rather useless as a trigger in this case because MLD > > routers will have to parse anyway the full chain as they receive it > > > > -??ric > > > > On 19/07/16 12:14, "ipv6 on behalf of Alexandre Petrescu" > > wrote: > > > >>Hi, > >> > >>I suspect HbH is used in Router Alert options and MLDv2, which is used > >>at computer startup to signal presence and belonging to some multicast > >>groups needed later by ND. > >> > >>If so, then the RFC2460bis suggested modifications would imply that all > >>computers would have to be specifically enabled to continue use this HbH? > >> > >>Alex > >> > >>-------------------------------------------------------------------- > >>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 > -------------------------------------------------------------------- -- Enno Rey ERNW GmbH - Carl-Bosch-Str. 4 - 69115 Heidelberg - www.ernw.de Tel. +49 6221 480390 - Fax 6221 419008 - Cell +49 173 6745902 Handelsregister Mannheim: HRB 337135 Geschaeftsfuehrer: Enno Rey ======================================================= Blog: www.insinuator.net || Conference: www.troopers.de Twitter: @Enno_Insinuator ======================================================= From nobody Tue Jul 19 08:11:16 2016 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CD77012E1CE for ; Tue, 19 Jul 2016 08:11:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -15.807 X-Spam-Level: X-Spam-Status: No, score=-15.807 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, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-1.287, 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 hy7RSEgNLQGs for ; Tue, 19 Jul 2016 08:11:14 -0700 (PDT) Received: from alln-iport-6.cisco.com (alln-iport-6.cisco.com [173.37.142.93]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0716512E0F6 for <6man@ietf.org>; Tue, 19 Jul 2016 07:47:11 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2359; q=dns/txt; s=iport; t=1468939632; x=1470149232; h=from:to:subject:date:message-id:mime-version; bh=N3PsB5DCm6jou1sujSgJIZ0wKpf3zgBohDp/MEjCUc8=; b=PTvoUne6on3l8teBW8iTRmR6K71SMm4+8AXpSIfyFby3XVZRjo7Rxv8q c4fylSs87+1r8hoBuyHTEAU+XRSDKUtiC1wAigIxYqJ8sgw1YNgqJQJDf f3533T4XLm6HN1y5sbAIbxXpMRE2CQS+OdAYmJOf3uuYR8AGlVKpaoY+G Y=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0BRAgACPY5X/5pdJa1cgnFOgVizXYUEg?= =?us-ascii?q?XqGOIETOBQBAQEBAQEBZRwLhFMQI2gBCwE+AgQwJwSIQ550j2OOCgEBAQcCASS?= =?us-ascii?q?SOIJaBZkkAY5hgWuNTIZfiT4BHjaCCxyBTIgUfwEBAQ?= X-IronPort-AV: E=Sophos;i="5.28,389,1464652800"; d="scan'208,217";a="299674692" Received: from rcdn-core-3.cisco.com ([173.37.93.154]) by alln-iport-6.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 19 Jul 2016 14:47:11 +0000 Received: from XCH-ALN-001.cisco.com (xch-aln-001.cisco.com [173.36.7.11]) by rcdn-core-3.cisco.com (8.14.5/8.14.5) with ESMTP id u6JElBJP001709 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL) for <6man@ietf.org>; Tue, 19 Jul 2016 14:47:11 GMT Received: from xch-aln-003.cisco.com (173.36.7.13) by XCH-ALN-001.cisco.com (173.36.7.11) with Microsoft SMTP Server (TLS) id 15.0.1210.3; Tue, 19 Jul 2016 09:47:10 -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.1210.000; Tue, 19 Jul 2016 09:47:10 -0500 From: "Bernie Volz (volz)" To: "6man@ietf.org" <6man@ietf.org> Subject: draft-ietf-6man-default-iids - keeping section 6 Thread-Topic: draft-ietf-6man-default-iids - keeping section 6 Thread-Index: AQHR4cxtQINtIihplU+cSpytPki4bQ== Date: Tue, 19 Jul 2016 14:47:10 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.6.6.160626 x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.86.251.121] Content-Type: multipart/alternative; boundary="_000_D3B3B5AC30DB1volzciscocom_" MIME-Version: 1.0 Archived-At: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 Jul 2016 15:11:16 -0000 --_000_D3B3B5AC30DB1volzciscocom_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SGk6DQoNCkkgd291bGQgcHJlZmVyIHlvdSBrZWVwIHNlY3Rpb24gNi4gSGF2aW5nIHdvcmtlZCBv biBhIGJpcyBkb2N1bWVudCByZWNlbnRseSwgaXQgbWFrZXMgZmluZGluZyBhdCBsZWFzdCB0aGUg bW9zdCBjcml0aWNhbCBjaGFuZ2VzIG11Y2ggZWFzaWVyIHdoZW4gcmV2aWV3aW5nIHRoZSBkb2N1 bWVudHMgdGhhdCB1cGRhdGUgdGhlIGJpcyBkb2N1bWVudC4NCg0KSSBkb27igJl0IG1pbmQgaWYg eW91IHdlcmUgdG8ganVzdCBlbnVtZXJhdGUgdGhlIHByaW1hcnkgc2VjdGlvbnMgdGhhdCBuZWVk IHVwZGF0aW5nIChvciBhcmUgaW1wYWN0ZWQgYnkgdGhlIG5ldyBkb2N1bWVudCkg4oCTIHJhdGhl ciB0aGFuIHByb3ZpZGluZyB0aGUgY29tcGxldGUgdGV4dC4NCg0KSW4gdGhlIGNhc2Ugb2YgdGhl IGJpcyBkb2N1bWVudCBJIHdhcyB3b3JraW5nIG9uLCB0aGVyZSB3ZXJlIHNldmVyYWwgZG9jdW1l bnRzIHRoYXQgY2xhaW1lZCB0aGV5IHVwZGF0ZWQgaXQgYnV0IGl0IHR1cm5lZCBvdXQgdGhleSBk aWQgbm90Lg0KDQotIEJlcm5pZQ0K --_000_D3B3B5AC30DB1volzciscocom_ Content-Type: text/html; charset="utf-8" Content-ID: <7471EA1490FE704BA961BFDA3A4852A5@emea.cisco.com> Content-Transfer-Encoding: base64 PGh0bWw+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIgY29udGVudD0i dGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjwvaGVhZD4NCjxib2R5IHN0eWxlPSJ3b3JkLXdy YXA6IGJyZWFrLXdvcmQ7IC13ZWJraXQtbmJzcC1tb2RlOiBzcGFjZTsgLXdlYmtpdC1saW5lLWJy ZWFrOiBhZnRlci13aGl0ZS1zcGFjZTsgY29sb3I6IHJnYigwLCAwLCAwKTsgZm9udC1zaXplOiAx MnB4OyBmb250LWZhbWlseTogQ2FsaWJyaSwgc2Fucy1zZXJpZjsiPg0KPGRpdj5IaTo8L2Rpdj4N CjxkaXY+PGJyPg0KPC9kaXY+DQo8ZGl2Pkkgd291bGQgcHJlZmVyIHlvdSBrZWVwIHNlY3Rpb24g Ni4gSGF2aW5nIHdvcmtlZCBvbiBhIGJpcyBkb2N1bWVudCByZWNlbnRseSwgaXQgbWFrZXMgZmlu ZGluZyBhdCBsZWFzdCB0aGUgbW9zdCBjcml0aWNhbCBjaGFuZ2VzIG11Y2ggZWFzaWVyIHdoZW4g cmV2aWV3aW5nIHRoZSBkb2N1bWVudHMgdGhhdCB1cGRhdGUgdGhlIGJpcyBkb2N1bWVudC48L2Rp dj4NCjxkaXY+PGJyPg0KPC9kaXY+DQo8ZGl2PkkgZG9u4oCZdCBtaW5kIGlmIHlvdSB3ZXJlIHRv IGp1c3QgZW51bWVyYXRlIHRoZSBwcmltYXJ5IHNlY3Rpb25zIHRoYXQgbmVlZCB1cGRhdGluZyAo b3IgYXJlIGltcGFjdGVkIGJ5IHRoZSBuZXcgZG9jdW1lbnQpIOKAkyByYXRoZXIgdGhhbiBwcm92 aWRpbmcgdGhlIGNvbXBsZXRlIHRleHQuPC9kaXY+DQo8ZGl2Pjxicj4NCjwvZGl2Pg0KPGRpdj5J biB0aGUgY2FzZSBvZiB0aGUgYmlzIGRvY3VtZW50IEkgd2FzIHdvcmtpbmcgb24sIHRoZXJlIHdl cmUgc2V2ZXJhbCBkb2N1bWVudHMgdGhhdCBjbGFpbWVkIHRoZXkgdXBkYXRlZCBpdCBidXQgaXQg dHVybmVkIG91dCB0aGV5IGRpZCBub3QuPC9kaXY+DQo8ZGl2Pjxicj4NCjwvZGl2Pg0KPGRpdj4t IEJlcm5pZTwvZGl2Pg0KPC9ib2R5Pg0KPC9odG1sPg0K --_000_D3B3B5AC30DB1volzciscocom_-- From nobody Tue Jul 19 09:08:38 2016 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D90E912D894 for ; Tue, 19 Jul 2016 09:08:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.353 X-Spam-Level: X-Spam-Status: No, score=-5.353 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_ADSP_CUSTOM_MED=0.001, FREEMAIL_FROM=0.001, NML_ADSP_CUSTOM_MED=0.9, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_SOFTFAIL=0.665] 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 sXRoT4UBxBb0 for ; Tue, 19 Jul 2016 09:08:35 -0700 (PDT) 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 A9D9A12D7DC for ; Tue, 19 Jul 2016 09:00:36 -0700 (PDT) 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 u6JG0TUx019730; Tue, 19 Jul 2016 18:00:29 +0200 Received: from pisaure.intra.cea.fr (localhost [127.0.0.1]) by localhost (Postfix) with SMTP id D9B3C2028E3; Tue, 19 Jul 2016 18:00:29 +0200 (CEST) Received: from muguet2.intra.cea.fr (muguet2.intra.cea.fr [132.166.192.7]) by pisaure.intra.cea.fr (Postfix) with ESMTP id C323B20280C; Tue, 19 Jul 2016 18:00:29 +0200 (CEST) Received: from [132.166.85.0] ([132.166.85.0]) by muguet2.intra.cea.fr (8.15.2/8.15.2/CEAnet-Intranet-out-1.4) with ESMTP id u6JG0Sxq007758; Tue, 19 Jul 2016 18:00:29 +0200 Subject: Re: HbH used by Router Alert in MLDv2? To: otroan@employees.org References: <16e7823a-4847-6d6b-4bda-48e0812e9e04@gmail.com> <94EE6767-6B5F-47C3-90E5-E3BCF82011E0@employees.org> From: Alexandre Petrescu Message-ID: <92365468-099b-7757-1f43-2499ffbf0632@gmail.com> Date: Tue, 19 Jul 2016 18:00:28 +0200 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.2.0 MIME-Version: 1.0 In-Reply-To: <94EE6767-6B5F-47C3-90E5-E3BCF82011E0@employees.org> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit Archived-At: Cc: 6man WG X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 Jul 2016 16:08:37 -0000 Le 19/07/2016 14:17, otroan@employees.org a crit : > Alex, > >> I suspect HbH is used in Router Alert options and MLDv2, which is >> used at computer startup to signal presence and belonging to some >> multicast groups needed later by ND. >> >> If so, then the RFC2460bis suggested modifications would imply >> that all computers would have to be specifically enabled to >> continue use this HbH? > > Wouldn't it only be multicast routers that would need to do that? I think any IPv6 machines (router and host) sends MLD messages when it boots, but I am not sure whether each MLD message is mandated to contain a Router Alert. > If I remember correctly non-multicast routers do not listen to MLD > and multicast routers do ignore MLD reports for link-local multicast > addresses. (As discussed on a different thread it is arguable how > much value there is in sending MLD reports for link-local multicast > in the first place). If there is an effort to develop IEEE MAC multicast then the MLD reports for link-local multicast addressing make sense. IF there is no such effort in view, then it would make sense to rather make a linux bug report. Alex > > Cheers, Ole > From nobody Tue Jul 19 09:09:01 2016 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 57FA312D7D6 for ; Tue, 19 Jul 2016 09:09:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.353 X-Spam-Level: X-Spam-Status: No, score=-5.353 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_ADSP_CUSTOM_MED=0.001, FREEMAIL_FROM=0.001, NML_ADSP_CUSTOM_MED=0.9, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_SOFTFAIL=0.665] 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 7vsNARyCajEZ for ; Tue, 19 Jul 2016 09:08:58 -0700 (PDT) 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 8218C12D79B for ; Tue, 19 Jul 2016 09:01:07 -0700 (PDT) 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 u6JG13pl020162; Tue, 19 Jul 2016 18:01:03 +0200 Received: from pisaure.intra.cea.fr (localhost [127.0.0.1]) by localhost (Postfix) with SMTP id B80B72031D2; Tue, 19 Jul 2016 18:01:03 +0200 (CEST) Received: from muguet2.intra.cea.fr (muguet2.intra.cea.fr [132.166.192.7]) by pisaure.intra.cea.fr (Postfix) with ESMTP id A4AF0200802; Tue, 19 Jul 2016 18:01:03 +0200 (CEST) Received: from [132.166.85.0] ([132.166.85.0]) by muguet2.intra.cea.fr (8.15.2/8.15.2/CEAnet-Intranet-out-1.4) with ESMTP id u6JG13LR008432; Tue, 19 Jul 2016 18:01:03 +0200 Subject: Re: HbH used by Router Alert in MLDv2? To: "Eric Vyncke (evyncke)" , "ipv6@ietf.org" References: <16e7823a-4847-6d6b-4bda-48e0812e9e04@gmail.com> From: Alexandre Petrescu Message-ID: Date: Tue, 19 Jul 2016 18:01:03 +0200 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.2.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Archived-At: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 Jul 2016 16:09:01 -0000 Le 19/07/2016 à 14:22, Eric Vyncke (evyncke) a écrit : > AFAIK No, because only MLD listeners will actually receive the packet > (i.e. They are member of the destination group) and not forward this > packet anyway as MLD packets are not forwarded. > > So, the HbH is rather useless as a trigger in this case because MLD > routers will have to parse anyway the full chain as they receive it Where is MLD being specified/maintained these days? Alex > > -éric > > On 19/07/16 12:14, "ipv6 on behalf of Alexandre Petrescu" > wrote: > >> Hi, >> >> I suspect HbH is used in Router Alert options and MLDv2, which is used >> at computer startup to signal presence and belonging to some multicast >> groups needed later by ND. >> >> If so, then the RFC2460bis suggested modifications would imply that all >> computers would have to be specifically enabled to continue use this HbH? >> >> Alex >> >> -------------------------------------------------------------------- >> IETF IPv6 working group mailing list >> ipv6@ietf.org >> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 >> -------------------------------------------------------------------- > From nobody Tue Jul 19 09:12:20 2016 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 09D6F12D0B4 for ; Tue, 19 Jul 2016 09:12:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.353 X-Spam-Level: X-Spam-Status: No, score=-5.353 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_ADSP_CUSTOM_MED=0.001, FREEMAIL_FROM=0.001, NML_ADSP_CUSTOM_MED=0.9, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_SOFTFAIL=0.665] 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 wEzK6OkDQnrJ for ; Tue, 19 Jul 2016 09:12:10 -0700 (PDT) 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 3528F12D6B9 for ; Tue, 19 Jul 2016 09:06:38 -0700 (PDT) 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 u6JG6ajS024050 for ; Tue, 19 Jul 2016 18:06:36 +0200 Received: from pisaure.intra.cea.fr (localhost [127.0.0.1]) by localhost (Postfix) with SMTP id B2E3D206A40 for ; Tue, 19 Jul 2016 18:06:36 +0200 (CEST) Received: from muguet2.intra.cea.fr (muguet2.intra.cea.fr [132.166.192.7]) by pisaure.intra.cea.fr (Postfix) with ESMTP id 9FDB42031D2 for ; Tue, 19 Jul 2016 18:06:36 +0200 (CEST) Received: from [132.166.85.0] ([132.166.85.0]) by muguet2.intra.cea.fr (8.15.2/8.15.2/CEAnet-Intranet-out-1.4) with ESMTP id u6JG6aHq012316 for ; Tue, 19 Jul 2016 18:06:36 +0200 Subject: 2464 - link-local multicast address mapping To: IPv6 References: <26148.1468914385@obiwan.sandelman.ca> From: Alexandre Petrescu Message-ID: <1ac389c5-22ca-2283-d09c-a26bea9c7a75@gmail.com> Date: Tue, 19 Jul 2016 18:06:36 +0200 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.2.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Archived-At: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 Jul 2016 16:12:12 -0000 Hi, Currently the RFC2464 multicast address mapping says: > An IPv6 packet with a multicast destination address DST, consisting > of the sixteen octets DST[1] through DST[16], is transmitted to the > Ethernet multicast address whose first two octets are the value 3333 > hexadecimal and whose last four octets are the last four octets of > DST. I think this mapping should happen only for link-scoped IPv6 destination addresses, not other scopes. I.e. the last four octets of a _link-local_ IPv6 address should get mapped into that MAC address (ff02::XXXX:XXXX -> 33-33-XX-XX-XX-XX); multicast addresses of other scopes than ff02 should not get mapped. Alex From nobody Tue Jul 19 09:19:04 2016 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8013A12D849 for ; Tue, 19 Jul 2016 09:19:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.353 X-Spam-Level: X-Spam-Status: No, score=-5.353 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_ADSP_CUSTOM_MED=0.001, FREEMAIL_FROM=0.001, NML_ADSP_CUSTOM_MED=0.9, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_SOFTFAIL=0.665] 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 F823N8mhaOkx for ; Tue, 19 Jul 2016 09:18:59 -0700 (PDT) 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 5D97312D607 for ; Tue, 19 Jul 2016 09:17:14 -0700 (PDT) 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 u6JGH9x7030973; Tue, 19 Jul 2016 18:17:09 +0200 Received: from pisaure.intra.cea.fr (localhost [127.0.0.1]) by localhost (Postfix) with SMTP id D53C42031D2; Tue, 19 Jul 2016 18:17:09 +0200 (CEST) Received: from muguet2.intra.cea.fr (muguet2.intra.cea.fr [132.166.192.7]) by pisaure.intra.cea.fr (Postfix) with ESMTP id C5FD6202406; Tue, 19 Jul 2016 18:17:09 +0200 (CEST) Received: from [132.166.85.0] ([132.166.85.0]) by muguet2.intra.cea.fr (8.15.2/8.15.2/CEAnet-Intranet-out-1.4) with ESMTP id u6JGH9NQ019854; Tue, 19 Jul 2016 18:17:09 +0200 Subject: Re: Reference to "3333" value of RFC2464 "IPv6 over Ethernet" To: "Toerless Eckert (eckert)" , Jen Linkova References: <2f437218b23a44238ccdcb4e7318da8d@XCH-RCD-003.cisco.com> From: Alexandre Petrescu Message-ID: <5d4c7db8-76cf-8e87-4102-2b5ae9b9817f@gmail.com> Date: Tue, 19 Jul 2016 18:17:08 +0200 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.2.0 MIME-Version: 1.0 In-Reply-To: <2f437218b23a44238ccdcb4e7318da8d@XCH-RCD-003.cisco.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Archived-At: Cc: IPv6 X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 Jul 2016 16:19:01 -0000 Thanks for the reply. I could not find "C9" or "multicast" in ISIS IPv6 RFC5308. Is there a reference RFC for the ISIS use of it. (the other address is 01-80-C2-00-00-1D ISO/IEC JTC1/SC6 ISO/IEC 9542 "All Multicast Capable Intermediate Systems Address") Alex Le 17/07/2016 à 14:18, Toerless Eckert (eckert) a écrit : > 3333 is for ipv6 multicast. That other address mentioned in the thread > is probably for isis, which does not use ip/ipvt > > typos = smartphone > > On Jul 8, 2016 8:32 AM, Jen Linkova wrote: > > On Fri, Jul 8, 2016 at 4:49 PM, Alexandre Petrescu > wrote: > >>> RFC2464 "IPv6 over Ethernet" says: > >>>> 7. Address Mapping -- Multicast > >>>> > >>>> An IPv6 packet with a multicast destination address DST, consisting > >>>> of the sixteen octets DST[1] through DST[16], is transmitted to the > >>>> Ethernet multicast address whose first two octets are the value 3333 > >>>> hexadecimal and whose last four octets are the last four octets of > >>>> DST. > >>> > >>> > >>> Where is this "3333" value defined? Obviously an RFC is not the place to > >>> define an Ethernet multicast address. > >> > >> > >> https://tools.ietf.org/html/rfc5342#section-2.3.1 > >> > >> Please note that it has 'local; bit set so that OUI range (33-33-XX > >> did not need to be purchased). > > > > > > Why isn't this address listed by IEEE "GROUP MAC PUBLIC LISTING"? > > https://standards.ieee.org/develop/regauth/grpmac/public.html > > > Why IEEE lists _other_ addresses that can be used for same role: > > 01-80-C2-00-00-1D ISO/IEC JTC1/SC6 ISO/IEC 9542 > > "All Multicast Capable Intermediate Systems Address" > > Because the OUI 33-33- is *locally administered* (it has the Local > bit set). > It is not allocated by any registry. The link you are referring to > lists addresses > from the Universally Administered Address Block. > > > RFC5342 says: > >> > >> All MAC-48 multicast identifiers prefixed "33-33" (that is, the 2**32 > >> multicast MAC identifiers in the range from 33-33-00-00-00-00 to > >> 33-33-FF-FF-FF-FF) are used by the IETF for global IPv6 multicast > >> [RFC2464]. > > > > > > What does "global IPv6 multicast" mean? The term "global" is misleading > > because of that 'local' bit set you said above, and because RFC2464 is > > happening only on a link. Maybe it meant "IPv6 multicast"? > > > > Why does it refer to RFC2464? RFC2464 is only for Ethernet, not for other > > kinds of links. > > > > It reads as if all Internet-connected nodes were on Ethernet and as if any > > IP multicast address could be mapped into the 32bits left of a MAC multicast > > address (they cant - they are 112bit length). > > AFAIR RFC3307 has some recommendations on how to minimize the chance > of address collision. > > -- > SY, Jen Linkova aka Furry > > -------------------------------------------------------------------- > IETF IPv6 working group mailing list > ipv6@ietf.org > Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 > -------------------------------------------------------------------- > From nobody Tue Jul 19 09:23:19 2016 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 249DC12D747 for ; Tue, 19 Jul 2016 09:23:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.333 X-Spam-Level: X-Spam-Status: No, score=-5.333 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_ADSP_CUSTOM_MED=0.001, FREEMAIL_FROM=0.001, NML_ADSP_CUSTOM_MED=0.9, RCVD_IN_DNSWL_HI=-5, SPF_SOFTFAIL=0.665] 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 Kl3UwHgnwmsG for ; Tue, 19 Jul 2016 09:23:14 -0700 (PDT) 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 3D32312D1B7 for ; Tue, 19 Jul 2016 09:22:46 -0700 (PDT) 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 u6JGMiU2030575 for ; Tue, 19 Jul 2016 18:22:44 +0200 Received: from pisaure.intra.cea.fr (localhost [127.0.0.1]) by localhost (Postfix) with SMTP id 5E10B20294A for ; Tue, 19 Jul 2016 18:22:44 +0200 (CEST) Received: from muguet2.intra.cea.fr (muguet2.intra.cea.fr [132.166.192.7]) by pisaure.intra.cea.fr (Postfix) with ESMTP id 4B1CE20293E for ; Tue, 19 Jul 2016 18:22:44 +0200 (CEST) Received: from [132.166.85.0] ([132.166.85.0]) by muguet2.intra.cea.fr (8.15.2/8.15.2/CEAnet-Intranet-out-1.4) with ESMTP id u6JGMiVv023006 for ; Tue, 19 Jul 2016 18:22:44 +0200 Subject: Re: IPv6-over-80211 may have more privacy issues than RFC2464 Ethernet To: ipv6@ietf.org References: <201607190957.u6J9vx4F013776@givry.fdupont.fr> From: Alexandre Petrescu Message-ID: <78156616-ee91-eb29-6e44-ae4a708ee1d4@gmail.com> Date: Tue, 19 Jul 2016 18:22:43 +0200 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.2.0 MIME-Version: 1.0 In-Reply-To: <201607190957.u6J9vx4F013776@givry.fdupont.fr> 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.17 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 Jul 2016 16:23:18 -0000 Le 19/07/2016 11:57, Francis Dupont a crit : > I have another kind of counter-argument: if we publish > an IPv6-over-80211 document, it should specify the real MTU > of 802.11 which is not 1500 but larger. As in the real world > everybody without significant exceptions clearly ignore that > and use only 1500 MTU there is no need at all for a specific > document (vs reusing the 802.3 one). I would like to at least identify this number. One some other list someone says 2308 bytes, but is that specified somewhere? As for the counter-argument: I tend to agree that one should be careful not to break existing computers having MTU 1500bytes forever. To address part of that the PMTUD mechanism was designed, I think. Alex > > Regards > > Francis.Dupont@fdupont.fr > > -------------------------------------------------------------------- > IETF IPv6 working group mailing list > ipv6@ietf.org > Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 > -------------------------------------------------------------------- > From nobody Tue Jul 19 09:24:49 2016 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2839F12D686 for ; Tue, 19 Jul 2016 09:24:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.333 X-Spam-Level: X-Spam-Status: No, score=-5.333 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_ADSP_CUSTOM_MED=0.001, FREEMAIL_FROM=0.001, NML_ADSP_CUSTOM_MED=0.9, RCVD_IN_DNSWL_HI=-5, SPF_SOFTFAIL=0.665] 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 GFtejV8Mukyi for ; Tue, 19 Jul 2016 09:24:46 -0700 (PDT) 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 4354412D1D8 for ; Tue, 19 Jul 2016 09:24:28 -0700 (PDT) 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 u6JGOR7v031460 for ; Tue, 19 Jul 2016 18:24:27 +0200 Received: from pisaure.intra.cea.fr (localhost [127.0.0.1]) by localhost (Postfix) with SMTP id 5593720317E for ; Tue, 19 Jul 2016 18:24:27 +0200 (CEST) Received: from muguet2.intra.cea.fr (muguet2.intra.cea.fr [132.166.192.7]) by pisaure.intra.cea.fr (Postfix) with ESMTP id 427DE20293E for ; Tue, 19 Jul 2016 18:24:27 +0200 (CEST) Received: from [132.166.85.0] ([132.166.85.0]) by muguet2.intra.cea.fr (8.15.2/8.15.2/CEAnet-Intranet-out-1.4) with ESMTP id u6JGOQQY024055 for ; Tue, 19 Jul 2016 18:24:27 +0200 Subject: Re: [6man] #20 (rfc4291bis): Site-local To: ipv6@ietf.org References: <063.b29004adee61477f53c85e1085499f4e@trac.tools.ietf.org> From: Alexandre Petrescu Message-ID: Date: Tue, 19 Jul 2016 18:24:26 +0200 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.2.0 MIME-Version: 1.0 In-Reply-To: <063.b29004adee61477f53c85e1085499f4e@trac.tools.ietf.org> 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.17 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 Jul 2016 16:24:48 -0000 Mention ULA MAY be used in some of the places where people felt a need for site-local addresses, and in other places too. Alex Le 19/07/2016 13:53, 6man issue tracker a crit : > #20: Site-local > > Remove sections on site local addresses. What to do with ULA? > From nobody Tue Jul 19 09:33:21 2016 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6040212D5F6 for ; Tue, 19 Jul 2016 09:33:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.333 X-Spam-Level: X-Spam-Status: No, score=-5.333 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_ADSP_CUSTOM_MED=0.001, FREEMAIL_FROM=0.001, NML_ADSP_CUSTOM_MED=0.9, RCVD_IN_DNSWL_HI=-5, SPF_SOFTFAIL=0.665] 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 JmEqb6pgMIpC for ; Tue, 19 Jul 2016 09:33:18 -0700 (PDT) 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 7F52612D606 for ; Tue, 19 Jul 2016 09:33:14 -0700 (PDT) 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 u6JGXCXd004999; Tue, 19 Jul 2016 18:33:12 +0200 Received: from pisaure.intra.cea.fr (localhost [127.0.0.1]) by localhost (Postfix) with SMTP id 7F4B1207B72; Tue, 19 Jul 2016 18:33:12 +0200 (CEST) Received: from muguet2.intra.cea.fr (muguet2.intra.cea.fr [132.166.192.7]) by pisaure.intra.cea.fr (Postfix) with ESMTP id 721B220317E; Tue, 19 Jul 2016 18:33:12 +0200 (CEST) Received: from [132.166.85.0] ([132.166.85.0]) by muguet2.intra.cea.fr (8.15.2/8.15.2/CEAnet-Intranet-out-1.4) with ESMTP id u6JGXBIM029364; Tue, 19 Jul 2016 18:33:12 +0200 Subject: Re: Reference to "3333" value of RFC2464 "IPv6 over Ethernet" To: Hemant Singh References: <20160701153641.24636.69476.idtracker@ietfa.amsl.com> <8cb3aa9b-e157-794b-2dbf-f63e20cfdc62@innovationslab.net> <6c26fb03-7218-ff28-3488-887f6cd0f1fe@gmail.com> From: Alexandre Petrescu Message-ID: Date: Tue, 19 Jul 2016 18:33:10 +0200 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.2.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 X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 Jul 2016 16:33:20 -0000 Le 19/07/2016 à 14:14, Hemant Singh a écrit : > Sorry for the delayed reply. I read IETF emails sporadically. See > section 2.3.1 of RFC7042 for the definition. IANA has also reserved > the address. > > http://www.iana.org/assignments/ethernet-numbers/ethernet-numbers.xhtml#ethernet-numbers-3 But that URL does not show the 33-33 address as an allocation proper, along with other allocations. It shows it as a given, in an introductory paragraph. It has this 'L' Local Authority bit set, it is not defined by IEEE, it's not a IANA OUI, and so on. > Search at the above URL for rfc7042 and you will find the IPv6 > multicast mac first two octets in 3333. Ok, thanks. But I dont think an RFC is a place to allocate a number which belongs to a somehow fuzzy border between IP and MAC. There are many non-IP protocols running on this MAC and their designers would not all read this RFC - risking collisions. Alex > > Hemant > > On Fri, Jul 8, 2016 at 9:56 AM, Alexandre Petrescu > > > wrote: > > > Where is this "3333" value defined? Obviously an RFC is not the > place to define an Ethernet multicast address. > > Alex > > -------------------------------------------------------------------- > IETF IPv6 working group mailing list ipv6@ietf.org > Administrative Requests: > https://www.ietf.org/mailman/listinfo/ipv6 > -------------------------------------------------------------------- > > From nobody Tue Jul 19 09:47:11 2016 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C130F12D74D for ; Tue, 19 Jul 2016 09:47:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.922 X-Spam-Level: X-Spam-Status: No, score=-101.922 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, USER_IN_WHITELIST=-100] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=junipernetworks.onmicrosoft.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 hS8JVmr04TP9 for ; Tue, 19 Jul 2016 09:47:08 -0700 (PDT) Received: from NAM01-SN1-obe.outbound.protection.outlook.com (mail-sn1nam01on0104.outbound.protection.outlook.com [104.47.32.104]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0A21412D67F for ; Tue, 19 Jul 2016 09:47:08 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=junipernetworks.onmicrosoft.com; s=selector1-juniper-net; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=cSGbnzcS1/47p5teE+1VvXT05AoTd3TSRL9O6un8eNg=; b=k9AdfGo12B1P7YGqDeLRl4abHvfUchzImx0IjefBjJT3gFfrpTUr7alW4H0kLp3nKLKxOn/46m11ezSRiVDMh/EdVgut6CX/aWk6pG/MwkmovLd/cZ+E53ZwrkEqsaqsRzs3HPq09TEBLPZqusuyh+5aUn7GVCygo2lDSGJFtfU= Received: from BLUPR0501MB2051.namprd05.prod.outlook.com (10.164.23.21) by BLUPR0501MB2050.namprd05.prod.outlook.com (10.164.23.20) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P384) id 15.1.544.10; Tue, 19 Jul 2016 16:47:06 +0000 Received: from BLUPR0501MB2051.namprd05.prod.outlook.com ([10.164.23.21]) by BLUPR0501MB2051.namprd05.prod.outlook.com ([10.164.23.21]) with mapi id 15.01.0539.018; Tue, 19 Jul 2016 16:47:06 +0000 From: Ron Bonica To: Stig Venaas , "Eric Vyncke (evyncke)" Subject: RE: HbH used by Router Alert in MLDv2? Thread-Topic: HbH used by Router Alert in MLDv2? Thread-Index: AQHR4aZ00Yc5b81LokaPO5WxoZTJ7aAfrQWAgAADMoCAAEUUsA== Date: Tue, 19 Jul 2016 16:47:06 +0000 Message-ID: References: <16e7823a-4847-6d6b-4bda-48e0812e9e04@gmail.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=rbonica@juniper.net; x-originating-ip: [66.129.241.10] x-ms-office365-filtering-correlation-id: e6823e9b-52cd-4110-ac47-08d3aff45194 x-microsoft-exchange-diagnostics: 1; BLUPR0501MB2050; 6:vUFeTr3+iCne5dzcjkt8iOra8ieFuxCuvyIh45l9E8O6GCyKSyyByvI5gclLAJ8efUP1RcZUSh9xRNiyqFqOUifsX/18YelbhNSfeaWcSMPOal4OYBH90QfKuA3N+tNZo0m1m1dgs4CDMUB7A4H2wWQ9oZXsc0TaxK3TV/P4osNYX6OdZYmjR8n5WI3goVoq9Qf4dE9xnSaXSDA+TZki23c2mPZVgSVjsflf5LxaXOYPP4NRbQE8zKOn7XO1DN6Nqwt54B2idHk+88lugjMjdIW+Rf0a18DSypVL+6E1Pbw+i4+EUYB+9kp+RUCfA8DGIYW7Qq2WsQwx0Vgxc2TZDg==; 5:fFsMVN4JlkbUAkjijYRBtlh3AyiUkqu+sGKH7oUfTRU0ezr+gfVUHDDhqxBvpj9bPOebJ3r8xl+QnUT6HlwdmABxQrFxXcqo6vHGFeJ4N78W0HEXq/UStpkVfGqhEgdNiQtuLZgFQ7tnScOXg8VEvg==; 24:+I2++QhH7HA1neINxYpZ0nYZ5ayHirsAWThtQ62x/BFPqFqauF+4otwqrMraQ2PoMcAuBOdIEPOyRH6waaZD6PS0TOopnWvKphAwq1drMvc=; 7:cZvng6RHO7eGG6DXhHw2W7PnDUOmMO8WSyoLem8kJ2y0QD1oGdEP9+LDYwY/V5skwajx33miePW6O5z12AIHqN8KGnnM0eCwvHbOu6hCES33yoJiZJ8mcmDQVW+AOc+hawJgrqui99pwCmlQn4rKnBiDnHlV/SgC/rEn2UvBkR4925jLZ7EpG3X+8mApgP1gjkPykTd/DuIt9uL77T8kHDNctSknFm2YrSHt1fSPo8TVAMJeyGOirBC2dyLvIn24 x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:BLUPR0501MB2050; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(95692535739014); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(601004)(2401047)(8121501046)(5005006)(10201501046)(3002001)(6055026); SRVR:BLUPR0501MB2050; BCL:0; PCL:0; RULEID:; SRVR:BLUPR0501MB2050; x-forefront-prvs: 000800954F x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(7916002)(24454002)(377454003)(189002)(54094003)(37854004)(13464003)(199003)(7736002)(305945005)(7696003)(87936001)(5002640100001)(4326007)(15975445007)(66066001)(5003600100003)(122556002)(77096005)(189998001)(8676002)(2950100001)(2900100001)(2906002)(586003)(105586002)(6116002)(102836003)(93886004)(3846002)(7846002)(99286002)(86362001)(92566002)(5001770100001)(97736004)(15650500001)(81156014)(81166006)(3660700001)(3280700002)(33656002)(11100500001)(10400500002)(76576001)(74316002)(101416001)(9686002)(8936002)(106356001)(106116001)(50986999)(19580395003)(19580405001)(68736007)(54356999)(76176999); DIR:OUT; SFP:1102; SCL:1; SRVR:BLUPR0501MB2050; H:BLUPR0501MB2051.namprd05.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; MX:1; A:1; LANG:en; received-spf: None (protection.outlook.com: juniper.net does not designate permitted sender hosts) spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-OriginatorOrg: juniper.net X-MS-Exchange-CrossTenant-originalarrivaltime: 19 Jul 2016 16:47:06.2616 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: bea78b3c-4cdb-4130-854a-1d193232e5f4 X-MS-Exchange-Transport-CrossTenantHeadersStamped: BLUPR0501MB2050 Archived-At: Cc: Alexandre Petrescu , "ipv6@ietf.org" X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 Jul 2016 16:47:11 -0000 U3RpZywNCg0KTGlrZXdpc2UsIFJTVlAgcmVsaWVzIG9uIHRoZSBSb3V0ZXIgQWxlcnQgT3B0aW9u LiBBbmQsIGxpa2V3aXNlLCBJIGRvbid0IHNlZSBtdWNoIHBvaW50Lg0KDQpTb21lIHZlbmRvcnMg c2V0IHRoZSBkZXN0aW5hdGlvbiBhZGRyZXNzIGluIHRoZSBSU1ZQIG1lc3NhZ2UgdG8gdGhlIG5l eHQgaG9wIGFuZCBjaGFuZ2UgdGhlIGRlc3RpbmF0aW9uIGFkZHJlc3MgYXQgZWFjaCBob3AuIElu IHRoaXMgY2FzZSwgdGhlIFJvdXRlciBBbGVydCBpc24ndCBuZWVkZWQuIFRoaXMgd29ya3Mgd2Vs bCB0b2RheS4NCg0KSSB3b25kZXIgaWYgNm1hbiBzaG91bGQgc2VuZCBhIHJlcXVlc3QgdG8gdGhl IFBJTSBhbmQgUlNWUCBXR3MgYXNraW5nIHRoZW0gdG8gYXZvaWQgdGhlIFJvdXRlciBBbGVydCBP cHRpb24gaW4gdGhlIGZ1dHVyZT8gU2luY2UgdGhlcmUgYXJlIHJlbGF0aXZlbHkgZmV3IFJTVlAt b3Zlci1JUHY2IGltcGxlbWVudGF0aW9ucywgc3VjaCBhIHJlY29tbWVuZGF0aW9uIG1pZ2h0IGhh dmUgYSBzaWduaWZpY2FudCBpbXBhY3QuDQoNCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgUm9uDQoNCj4gLS0tLS1PcmlnaW5hbCBN ZXNzYWdlLS0tLS0NCj4gRnJvbTogaXB2NiBbbWFpbHRvOmlwdjYtYm91bmNlc0BpZXRmLm9yZ10g T24gQmVoYWxmIE9mIFN0aWcgVmVuYWFzDQo+IFNlbnQ6IFR1ZXNkYXksIEp1bHkgMTksIDIwMTYg ODozNCBBTQ0KPiBUbzogRXJpYyBWeW5ja2UgKGV2eW5ja2UpIDxldnluY2tlQGNpc2NvLmNvbT4N Cj4gQ2M6IEFsZXhhbmRyZSBQZXRyZXNjdSA8YWxleGFuZHJlLnBldHJlc2N1QGdtYWlsLmNvbT47 IGlwdjZAaWV0Zi5vcmcNCj4gU3ViamVjdDogUmU6IEhiSCB1c2VkIGJ5IFJvdXRlciBBbGVydCBp biBNTER2Mj8NCj4gDQo+IFJvdXRlciBBbGVydCBpcyByZXF1aXJlZCBpbiBNTEQgbWVzc2FnZXMs IGJ1dCBJIGRvbid0IHNlZSBtdWNoIHBvaW50Lg0KPiBJIHdvbmRlciBpZiBpdCBjb3VsZCBiZSB1 c2VkIGFzIGEgd2F5IHRvIHByZXZlbnQgZm9yd2FyZGluZyB0aG91Z2guDQo+IFRoYXQgaXMsIGlm IHNvbWVvbmUgdHJpZXMgdG8gaWxsZWdhbGx5IHNlbmQgYW4gTUxEIHBhY2tldCB0byBhIHJlbW90 ZSB1bmljYXN0DQo+IGFkZHJlc3Mgb3Igbm9uLWxpbmstbG9jYWwgZ3JvdXAgYWRkcmVzcywgdGhl biB0aGlzIGNvdWxkIG1ha2UgaXQgZWFzaWVyIGZvciB0aGUNCj4gbG9jYWwgcm91dGVyIHRvIGRp c2NhcmQgaXQuIE9mIGNvdXJzZSBzb21lb25lIHRyeWluZyB0byBkbyBzb21ldGhpbmcgYmFkDQo+ IGNvdWxkIHNlbmQgYW4gTUxEIHJlcG9ydCB3aXRob3V0IFJBLiBJIHN1c3BlY3QgcmVjZWl2ZXJz IG1heSBub3QgY2hlY2sgZm9yDQo+IHByZXNlbmNlIG9mIFJBLg0KPiANCj4gU3RpZw0KPiANCj4g DQo+IE9uIFR1ZSwgSnVsIDE5LCAyMDE2IGF0IDU6MjIgQU0sIEVyaWMgVnluY2tlIChldnluY2tl KSA8ZXZ5bmNrZUBjaXNjby5jb20+DQo+IHdyb3RlOg0KPiA+IEFGQUlLIE5vLCBiZWNhdXNlIG9u bHkgTUxEIGxpc3RlbmVycyB3aWxsIGFjdHVhbGx5IHJlY2VpdmUgdGhlIHBhY2tldA0KPiA+IChp LmUuIFRoZXkgYXJlIG1lbWJlciBvZiB0aGUgZGVzdGluYXRpb24gZ3JvdXApIGFuZCBub3QgZm9y d2FyZCB0aGlzDQo+ID4gcGFja2V0IGFueXdheSBhcyBNTEQgcGFja2V0cyBhcmUgbm90IGZvcndh cmRlZC4NCj4gPg0KPiA+IFNvLCB0aGUgSGJIIGlzIHJhdGhlciB1c2VsZXNzIGFzIGEgdHJpZ2dl ciBpbiB0aGlzIGNhc2UgYmVjYXVzZSBNTEQNCj4gPiByb3V0ZXJzIHdpbGwgaGF2ZSB0byBwYXJz ZSBhbnl3YXkgdGhlIGZ1bGwgY2hhaW4gYXMgdGhleSByZWNlaXZlIGl0DQo+ID4NCj4gPiAtw6ly aWMNCj4gPg0KPiA+IE9uIDE5LzA3LzE2IDEyOjE0LCAiaXB2NiBvbiBiZWhhbGYgb2YgQWxleGFu ZHJlIFBldHJlc2N1Ig0KPiA+IDxpcHY2LWJvdW5jZXNAaWV0Zi5vcmcgb24gYmVoYWxmIG9mIGFs ZXhhbmRyZS5wZXRyZXNjdUBnbWFpbC5jb20+DQo+IHdyb3RlOg0KPiA+DQo+ID4+SGksDQo+ID4+ DQo+ID4+SSBzdXNwZWN0IEhiSCBpcyB1c2VkIGluIFJvdXRlciBBbGVydCBvcHRpb25zIGFuZCBN TER2Miwgd2hpY2ggaXMgdXNlZA0KPiA+PmF0IGNvbXB1dGVyIHN0YXJ0dXAgdG8gc2lnbmFsIHBy ZXNlbmNlIGFuZCBiZWxvbmdpbmcgdG8gc29tZSBtdWx0aWNhc3QNCj4gPj5ncm91cHMgbmVlZGVk IGxhdGVyIGJ5IE5ELg0KPiA+Pg0KPiA+PklmIHNvLCB0aGVuIHRoZSBSRkMyNDYwYmlzIHN1Z2dl c3RlZCBtb2RpZmljYXRpb25zIHdvdWxkIGltcGx5IHRoYXQNCj4gPj5hbGwgY29tcHV0ZXJzIHdv dWxkIGhhdmUgdG8gYmUgc3BlY2lmaWNhbGx5IGVuYWJsZWQgdG8gY29udGludWUgdXNlIHRoaXMN Cj4gSGJIPw0KPiA+Pg0KPiA+PkFsZXgNCj4gPj4NCj4gPj4tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLQ0KPiA+PklFVEYg SVB2NiB3b3JraW5nIGdyb3VwIG1haWxpbmcgbGlzdA0KPiA+PmlwdjZAaWV0Zi5vcmcNCj4gPj5B ZG1pbmlzdHJhdGl2ZSBSZXF1ZXN0czogaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0 aW5mby9pcHY2DQo+ID4+LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0NCj4gPg0KPiA+IC0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tDQo+ID4gSUVU RiBJUHY2IHdvcmtpbmcgZ3JvdXAgbWFpbGluZyBsaXN0DQo+ID4gaXB2NkBpZXRmLm9yZw0KPiA+ IEFkbWluaXN0cmF0aXZlIFJlcXVlc3RzOiBodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xp c3RpbmZvL2lwdjYNCj4gPiAtLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLQ0KPiANCj4gLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0NCj4gSUVURiBJ UHY2IHdvcmtpbmcgZ3JvdXAgbWFpbGluZyBsaXN0DQo+IGlwdjZAaWV0Zi5vcmcNCj4gQWRtaW5p c3RyYXRpdmUgUmVxdWVzdHM6IGh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8v aXB2Ng0KPiAtLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLQ0K From nobody Tue Jul 19 15:01:34 2016 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 16E0F12D8FE for ; Tue, 19 Jul 2016 15:01:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.199 X-Spam-Level: X-Spam-Status: No, score=-1.199 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, HK_RANDOM_FROM=0.999, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=no 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 O9bKQ8-GKZsh for ; Tue, 19 Jul 2016 15:01:30 -0700 (PDT) Received: from mail-vk0-x22d.google.com (mail-vk0-x22d.google.com [IPv6:2607:f8b0:400c:c05::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 5DF4512B00F for ; Tue, 19 Jul 2016 15:01:30 -0700 (PDT) Received: by mail-vk0-x22d.google.com with SMTP id s189so43980195vkh.1 for ; Tue, 19 Jul 2016 15:01:30 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc; bh=XPBvazGe+mtZsGauaDweHAlDfURSROMrmstdFwaVM9Q=; b=rmJADMmNOllxks+vebTpoSFi4pcCBfBZAWCyZWzFZ5ZhZQiJb/IZ/S93HEZruCo3R3 RhzMydIwiqhjdIBezEuCQClRJBXpKFIXCFD40yZbVhO5xp9Bs+bT5ZQgNAR+tK1d9Pyt 5HfccsheQ+WIrz4j/r1gH/GN5UO7POv/sqBJ2eg7TZG8ckiOMZrpu0/MJG1uvgQWyG1v XY8BN+onmXuBbfC4RTzN3cgCzYTQLbUM4YzuScP/76dLT19gxkewrpj/gkW8q3W9GqDG 1LAS8SSvBrzVLhsckwZidCvx95uDAZl5yIO+YVZLtHASxtjNZ571CdoaCiWVzqSwsx2f 2lDA== 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; bh=XPBvazGe+mtZsGauaDweHAlDfURSROMrmstdFwaVM9Q=; b=HpAcLY0L2vfjsE9pVTO9fs8SJ5vQerW1PoHWuiNvg7wbugpxg4YyjbnHfktOLf7x+C 2fCdMAcntHhc2mk4H+ao304NmztQEtFQrcK2Ij20s+fUre99U2czE9YYI6Cp2FArQ2Yw SO2fcGyEpYma3AehgPYyhJNYOyxOnG3mcVjmsH+pPoWr+ZHooEn2MkfgoPZecLuDolnd E33vOeP8jqOCZCe5Ej3ZBNmDmHmAZxc/YGWsqsujgUzwikRmHFAWxtSj60yKG4OgS+3U Ng2xL3HaxUW6F3K3jSgXwQeLlwPaLA1aCqdOObFhOYxhHJfnu39atidQ8QzL83CBcaQb lySQ== X-Gm-Message-State: ALyK8tLiQxs6+sxpcE0AkMjRapIRQl8UZ07cDGls7e7r+w+C6r/lBB0lLvMdXUzKgirXivFdN2fprfhnsOwfiA== MIME-Version: 1.0 X-Received: by 10.159.33.168 with SMTP id 37mr22730929uac.142.1468965689377; Tue, 19 Jul 2016 15:01:29 -0700 (PDT) Received: by 10.159.39.233 with HTTP; Tue, 19 Jul 2016 15:01:29 -0700 (PDT) Received: by 10.159.39.233 with HTTP; Tue, 19 Jul 2016 15:01:29 -0700 (PDT) In-Reply-To: <1ac389c5-22ca-2283-d09c-a26bea9c7a75@gmail.com> References: <26148.1468914385@obiwan.sandelman.ca> <1ac389c5-22ca-2283-d09c-a26bea9c7a75@gmail.com> Date: Wed, 20 Jul 2016 08:01:29 +1000 Message-ID: Subject: Re: 2464 - link-local multicast address mapping From: Mark Smith To: Alexandre Petrescu Content-Type: multipart/alternative; boundary=001a113df53c1a49110538043a08 Archived-At: Cc: 6man WG X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 Jul 2016 22:01:32 -0000 --001a113df53c1a49110538043a08 Content-Type: text/plain; charset=UTF-8 On 20 Jul 2016 2:12 AM, "Alexandre Petrescu" wrote: > > Hi, > > Currently the RFC2464 multicast address mapping says: > >> An IPv6 packet with a multicast destination address DST, consisting >> of the sixteen octets DST[1] through DST[16], is transmitted to the >> Ethernet multicast address whose first two octets are the value 3333 >> hexadecimal and whose last four octets are the last four octets of >> DST. > > > I think this mapping should happen only for link-scoped IPv6 destination addresses, not other scopes. > > I.e. the last four octets of a _link-local_ IPv6 address should get mapped into that MAC address (ff02::XXXX:XXXX -> 33-33-XX-XX-XX-XX); multicast addresses of other scopes than ff02 should not get mapped. > I think you're assuming that there are no other nodes on the link are members of the > link-local scope group, or that there is no more than one multicast router on the link. Multicast address scopes are only indicating boundary of the multicast forwarding domain, not where multicast group members are or are not. Regards, Mark. > Alex > > -------------------------------------------------------------------- > IETF IPv6 working group mailing list > ipv6@ietf.org > Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 > -------------------------------------------------------------------- --001a113df53c1a49110538043a08 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

On 20 Jul 2016 2:12 AM, "Alexandre Petrescu" <<= a href=3D"mailto:alexandre.petrescu@gmail.com">alexandre.petrescu@gmail.com= > wrote:
>
> Hi,
>
> Currently the RFC2464 multicast address mapping says:
>
>> =C2=A0 =C2=A0An IPv6 packet with a multicast destination address D= ST, consisting
>> =C2=A0 =C2=A0of the sixteen octets DST[1] through DST[16], is tran= smitted to the
>> =C2=A0 =C2=A0Ethernet multicast address whose first two octets are= the value 3333
>> =C2=A0 =C2=A0hexadecimal and whose last four octets are the last f= our octets of
>> =C2=A0 =C2=A0DST.
>
>
> I think this mapping should happen only for link-scoped IPv6 destinati= on addresses, not other scopes.
>
> I.e. the last four octets of a _link-local_ IPv6 address should get ma= pped into that MAC address (ff02::XXXX:XXXX -> 33-33-XX-XX-XX-XX); multi= cast addresses of other scopes than ff02 should not get mapped.
>

I think you're assuming that there are no other nodes on= the link are members of the > link-local scope group, or that there is = no more than one multicast router on the link.

Multicast address scopes are only indicating boundary of the= multicast forwarding domain, not where multicast group members are or are = not.

Regards,
Mark.

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

--001a113df53c1a49110538043a08-- From nobody Tue Jul 19 15:09:41 2016 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1E5C112B025; Tue, 19 Jul 2016 15:09:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.199 X-Spam-Level: X-Spam-Status: No, score=-1.199 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, HK_RANDOM_FROM=0.999, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=no 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 60i5UheQ_diV; Tue, 19 Jul 2016 15:09:38 -0700 (PDT) Received: from mail-vk0-x232.google.com (mail-vk0-x232.google.com [IPv6:2607:f8b0:400c:c05::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 A560F12D0A6; Tue, 19 Jul 2016 15:09:38 -0700 (PDT) Received: by mail-vk0-x232.google.com with SMTP id g1so31779725vkb.3; Tue, 19 Jul 2016 15:09:38 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc; bh=z07QcyjUSBXWds4lysUWF+VgPL5z7JIZWdzWGPJ+CRE=; b=a+KFlH/7yf6YYxQpAlhyrt2tQNqIc75uF4e4MfTGwwqKTLquyk53sUqGgZQuR2AM3m ZvNF7E7bxw5Sen3f4kbsTCEqTuNwWcxXAAlH7Ag61MLCaPpNqc0Xi9uHFlsuXBVWyi4b r9WHtl9wYcRczhUMwDLgaqcoAp9XU+a13kKK34qWhweQm545y7W7HwgS7aqg1JGMfA8h vKM3GOQhUMXrQPu00EO3XU+8pTO3EHg7Co0upnBHZQwzqC2jC3ED1xho3C0jA88oAmtu MuwvIQkfBBokXS4oF3m+rJ8kNVswnuYBMp27JaiBNPG1qrAqGhBfTn7wyJ3vvVEJ/UDk fIKg== 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; bh=z07QcyjUSBXWds4lysUWF+VgPL5z7JIZWdzWGPJ+CRE=; b=Od4lGhMqasVgar2N62ehei0ExtYSLiMFwztsr/EhZXQUGFsVRRnSHxxVvi5pt4rYF+ ZRHuJdXOIiZ8HpfiUR5yK/qnyhfAP2WUQw5LG/eqXDhvEVl5qli3K50JwDl+OUqOczOk l7jBHDaYYSF46WMRfZJpsAi5WQnj3oPlR1OpezA3p6ic7eMFwg2MxWAWjXxbax0NeskS WdJfwZgHgsl7Zfyhvw56ivO+L9yYcYH2cuC9gOSZCn7o7JyCVoFdheqLh0L6EkyQMWKa kHywdOCt+ioLePXGou6GUcmuRxTKgAqER8aJuhyysk3worOvIB6r+beFHhsgws68mWED FL4Q== X-Gm-Message-State: ALyK8tKNj75v2op8KTD63EV9EYCvnw6u5JoUkg5dlADhlIeUfp42jxC3ZAdXxhhBIuAeZrxHl14s8wUrwHz9ug== MIME-Version: 1.0 X-Received: by 10.176.6.40 with SMTP id f37mr19454187uaf.8.1468966177600; Tue, 19 Jul 2016 15:09:37 -0700 (PDT) Received: by 10.159.39.233 with HTTP; Tue, 19 Jul 2016 15:09:37 -0700 (PDT) Received: by 10.159.39.233 with HTTP; Tue, 19 Jul 2016 15:09:37 -0700 (PDT) In-Reply-To: <063.b29004adee61477f53c85e1085499f4e@trac.tools.ietf.org> References: <063.b29004adee61477f53c85e1085499f4e@trac.tools.ietf.org> Date: Wed, 20 Jul 2016 08:09:37 +1000 Message-ID: Subject: Re: [6man] #20 (rfc4291bis): Site-local From: Mark Smith To: 6man@ietf.org Content-Type: multipart/alternative; boundary=94eb2c1246e033fc3d053804577c Archived-At: Cc: draft-ietf-6man-rfc4291bis@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 Jul 2016 22:09:40 -0000 --94eb2c1246e033fc3d053804577c Content-Type: text/plain; charset=UTF-8 On 19 Jul 2016 9:53 PM, "6man issue tracker" wrote: > > #20: Site-local > > Remove sections on site local addresses. > What to do with ULA? > I'd mention something like, " ULAs are for local network addressing beyond the local link, providing a local network routed address space that is independent of a global address space if present (for example, supplied by the network's current Internet service provider). This decoupling allows the global address space to be replaced without disrupting new and on going local network communications using ULA addresses." Regards, Mark. > -- > -------------------------+------------------------------------------------- > Reporter: | Owner: draft-ietf-6man-rfc4291bis@ietf.org > otroan@employees.org | Status: new > Type: defect | Milestone: > Priority: major | Version: > Component: rfc4291bis | Keywords: > Severity: In WG Last | > Call | > -------------------------+------------------------------------------------- > > Ticket URL: > 6man > > -------------------------------------------------------------------- > IETF IPv6 working group mailing list > ipv6@ietf.org > Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 > -------------------------------------------------------------------- --94eb2c1246e033fc3d053804577c Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

On 19 Jul 2016 9:53 PM, "6man issue tracker" <<= a href=3D"mailto:trac%2B6man@trac.tools.ietf.org">trac+6man@trac.tools.ietf= .org> wrote:
>
> #20: Site-local
>
> =C2=A0Remove sections on site local addresses.
> =C2=A0What to do with ULA?
>

I'd mention something like,

" ULAs are for local network addressing beyond the loca= l link, providing a local network routed address space that is independent = of a global address space if present (for example, supplied by the network&= #39;s current Internet service provider). This decoupling allows the global= address space to be replaced without disrupting new and on going local net= work communications using ULA addresses."

Regards,
Mark.

> --
> -------------------------+--------------------------------------------= -----
> =C2=A0Reporter:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0= |=C2=A0 =C2=A0 =C2=A0 Owner:=C2=A0 draft-ietf-6man-rfc4291bis@ietf.org
> =C2=A0 otroan@employees.org=C2=A0 =C2=A0|=C2=A0 =C2=A0 =C2=A0Status:=C2=A0 new
> =C2=A0 =C2=A0 =C2=A0Type:=C2=A0 defect=C2=A0 =C2=A0 =C2=A0 =C2=A0|=C2= =A0 Milestone:
> =C2=A0Priority:=C2=A0 major=C2=A0 =C2=A0 =C2=A0 =C2=A0 |=C2=A0 =C2=A0 = Version:
> Component:=C2=A0 rfc4291bis=C2=A0 =C2=A0|=C2=A0 =C2=A0Keywords:
> =C2=A0Severity:=C2=A0 In WG Last=C2=A0 =C2=A0|
> =C2=A0 Call=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0|
> -------------------------+--------------------------------------------= -----
>
> Ticket URL: <https://trac.tools.ietf.org/wg/6man/trac/ticket/20>
> 6man <https://tools.iet= f.org/wg/6man/>
>
> -------------------------------------------------------------------- > IETF IPv6 working group mailing list
> ipv6@ietf.org
> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
> --------------------------------------------------------------------

--94eb2c1246e033fc3d053804577c-- From nobody Tue Jul 19 15:40:06 2016 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8107612D8FE for ; Tue, 19 Jul 2016 15:40:04 -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 TGVhd4GfkKH5 for ; Tue, 19 Jul 2016 15:40:02 -0700 (PDT) Received: from mail-oi0-x22b.google.com (mail-oi0-x22b.google.com [IPv6:2607:f8b0:4003:c06::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 A731012D850 for ; Tue, 19 Jul 2016 15:40:02 -0700 (PDT) Received: by mail-oi0-x22b.google.com with SMTP id j185so46885184oih.0 for ; Tue, 19 Jul 2016 15:40:02 -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=lI6ZtHIGIKobU986AGIlkuJWJYOi3TjzIBbM9GyLYaA=; b=MURPnW2ugrR3k2gIhvUCjmSpEmbYr+8TfW4WU8pGoWrrv7cqeJHN7TVfvz3h2xbiQO RM9a4tuBAG6CBYUZdHbYf2BJVPLbj+2HsfjIa+gzvp1r7dKZbEFdsOkSGCpabSgLt+tx XTTrN00qmofQOKG0lE2CLdEz7+d2sUjE78wDfhbTFKCcxdLR4yrjgImbWl77gr+t0UXW 7Jn7baEIJQfigkJ89huXSqi6iCaBALdQkz6/x5F03G5p5gdCeD9pD/e6dqZbGgdJBvZ7 n31PQHlLmX0MmU8pluAq/cs7lqQ+aWqh4oHZz/zXGSZ47KIMLHMmVOnEDudUQ7EXUYY8 cX+w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=lI6ZtHIGIKobU986AGIlkuJWJYOi3TjzIBbM9GyLYaA=; b=RCRUX6uzAl+QJgaV0gV1Hm4btUJTb8N26lmXFDgVn8hKlb2c3qBE3t/SQ6Xezf607L SYoxMYVjdI9XsL4+Xum6Gyn+FP4j4I7+dCzHDopIanK6DyJTzf6z3LiaduBqItnpGfwH cPVeBYS9v4cyWHRcnv11F9M7WU2sXIYx5I89938kCG93ZAOgByUpSmF6XcUL9ySRIre9 gKiCf8A46ZPt7Ol1RuIP5pUwtS6qd6HrrUKGeAY74zJX4T/NCuZmgQPwZX6BgN3bY0R+ ByOZNIUr3HwB6mch+UIQmKtmuw5QpXSbFriySLwYSWXRWlZ4oXZ9MHNftNVeQOpWnsS/ y3Aw== X-Gm-Message-State: ALyK8tKp+y5x0ZH71zWleB+joMdZMCvr5MqBvIWXCkQrGPJotN36V+ufQVgMSoHfK+DTiFnKswt9rDKXAyL6Hg== X-Received: by 10.202.245.214 with SMTP id t205mr10812105oih.202.1468968001972; Tue, 19 Jul 2016 15:40:01 -0700 (PDT) MIME-Version: 1.0 Received: by 10.182.172.66 with HTTP; Tue, 19 Jul 2016 15:40:01 -0700 (PDT) In-Reply-To: <5d4c7db8-76cf-8e87-4102-2b5ae9b9817f@gmail.com> References: <2f437218b23a44238ccdcb4e7318da8d@XCH-RCD-003.cisco.com> <5d4c7db8-76cf-8e87-4102-2b5ae9b9817f@gmail.com> From: Hemant Singh Date: Tue, 19 Jul 2016 18:40:01 -0400 Message-ID: Subject: Re: Reference to "3333" value of RFC2464 "IPv6 over Ethernet" To: Alexandre Petrescu Content-Type: multipart/alternative; boundary=001a113df090f1ccbb053804c3bb Archived-At: Cc: IPv6 X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 Jul 2016 22:40:05 -0000 --001a113df090f1ccbb053804c3bb Content-Type: text/plain; charset=UTF-8 As others have said, it's rfc2464 that mentions the multicast mac first two octects for IPv6 multicast traffic. One should not expect the same for IS-IS because IS-IS is a link-layer routing protocol. From day one, IS-IS defines the two multicast mac-address for use with link-layer multicast. Hemant On Tue, Jul 19, 2016 at 12:17 PM, Alexandre Petrescu < alexandre.petrescu@gmail.com> wrote: > Thanks for the reply. > > I could not find "C9" or "multicast" in ISIS IPv6 RFC5308. Is there a > reference RFC for the ISIS use of it. > > (the other address is 01-80-C2-00-00-1D ISO/IEC JTC1/SC6 ISO/IEC 9542 > "All Multicast Capable Intermediate Systems Address") > > Alex > > > >> >> > -------------------------------------------------------------------- > IETF IPv6 working group mailing list > ipv6@ietf.org > Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 > -------------------------------------------------------------------- > --001a113df090f1ccbb053804c3bb Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
As others have said, it's rfc2464 that mentions the mu= lticast mac first two octects for IPv6 multicast traffic.=C2=A0 One should = not expect the same for IS-IS because IS-IS is a link-layer routing protoco= l.=C2=A0 From day one, IS-IS defines the two multicast mac-address for use = with link-layer multicast.

Hemant

On Tue, Jul 19, 2016 at 12:17 PM, Al= exandre Petrescu <alexandre.petrescu@gmail.com> w= rote:
Thanks for the reply.

I could not find "C9" or "multicast" in ISIS IPv6 RFC53= 08.=C2=A0 Is there a reference RFC for the ISIS use of it.

(the other address is 01-80-C2-00-00-1D ISO/IEC JTC1/SC6 ISO/IEC 9542
=C2=A0"All Multicast Capable Intermediate Systems Address")

Alex





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

--001a113df090f1ccbb053804c3bb-- From nobody Wed Jul 20 01:04:16 2016 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0E0E012B005 for ; Wed, 20 Jul 2016 01:04:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -15.808 X-Spam-Level: X-Spam-Status: No, score=-15.808 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.287, 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 YgMEeF8oW3qM for ; Wed, 20 Jul 2016 01:04:08 -0700 (PDT) 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 6701E12B017 for <6man@ietf.org>; Wed, 20 Jul 2016 01:04:08 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1273; q=dns/txt; s=iport; t=1469001848; x=1470211448; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=CWL4Vq+RQUor0eIo1WSgS38HqAmE9bwT2pYE70bSs0E=; b=K7aELDE4pOEzReVXDnUGBm7XqUPQHJt1ZYgHLFgdtMZczWOjh+rejUdm 8x6o9B5IxU8r96B1e8LDADif9ymXTNb2w9RqkUfz7JJfqnVwc7mSmB7RE OTcG7BJEa+IzkAi1Cn3nhMwfPXhK6Zep8vP4tqlPAdt2GQapgEBQC+P1N k=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0D1AQAQMI9X/49dJa1dgz9WfAa4aYF6I?= =?us-ascii?q?oJBgzcCgTM4FAEBAQEBAQFlJ4RcAQEEAQEBODQLBQsCAQgYHhAnCyUCBA4FiCg?= =?us-ascii?q?IDr1CAQEBAQEBAQEBAQEBAQEBAQEBAQEBFwWGKoF4CIJNhECDLIIvAQSIH5EHA?= =?us-ascii?q?Y5hjziQHwEeNoILHIFMboZxfwEBAQ?= X-IronPort-AV: E=Sophos;i="5.28,393,1464652800"; d="scan'208";a="299903263" Received: from rcdn-core-7.cisco.com ([173.37.93.143]) by alln-iport-7.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 20 Jul 2016 08:04:07 +0000 Received: from XCH-RTP-005.cisco.com (xch-rtp-005.cisco.com [64.101.220.145]) by rcdn-core-7.cisco.com (8.14.5/8.14.5) with ESMTP id u6K847U9018794 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Wed, 20 Jul 2016 08:04:07 GMT Received: from xch-rtp-010.cisco.com (64.101.220.150) by XCH-RTP-005.cisco.com (64.101.220.145) with Microsoft SMTP Server (TLS) id 15.0.1210.3; Wed, 20 Jul 2016 04:04:06 -0400 Received: from xch-rtp-010.cisco.com ([64.101.220.150]) by XCH-RTP-010.cisco.com ([64.101.220.150]) with mapi id 15.00.1210.000; Wed, 20 Jul 2016 04:04:06 -0400 From: "Stefano Previdi (sprevidi)" To: Michael Richardson Subject: Re: proposed text for header injection revision 05 Thread-Topic: proposed text for header injection revision 05 Thread-Index: AQHR4l1JL5yBKQvtgU62rFkcVCSovA== Date: Wed, 20 Jul 2016 08:04:06 +0000 Message-ID: References: <26582.1468923195@obiwan.sandelman.ca> In-Reply-To: <26582.1468923195@obiwan.sandelman.ca> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.61.86.161] Content-Type: text/plain; charset="us-ascii" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Cc: "Mark Townsley \(townsley\)" , "6man@ietf.org" <6man@ietf.org> X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.17 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 Jul 2016 08:04:11 -0000 Hi, I clearly prefer and support Mark's suggestion of removing entirely the sec= ond paragraph. s. > On Jul 19, 2016, at 12:13 PM, Michael Richardson = wrote: >=20 >=20 > for 2nd paragraph: >=20 > An approach an intermediate node/router may take to include an additional > extension header in an IPv6 packet that it did not originate is to > encapsulate the original packet in a new IPv6 header. As the > source address of this IPv6 packet would then be the router, any > number of additional extension headers may be placed after this new heade= r, > prior to the original packet. A system making use of this mechanism will > have to specify how to construct the rest of the IPv6 header, in particul= ate, > such a specification needs to carefully consider what the destination add= ress > will be. >=20 >=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 > -------------------------------------------------------------------- From nobody Wed Jul 20 01:19:18 2016 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 759B512B040 for ; Wed, 20 Jul 2016 01:19:17 -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 R8xJocoP1a3V for ; Wed, 20 Jul 2016 01:19:15 -0700 (PDT) Received: from mail-wm0-x22a.google.com (mail-wm0-x22a.google.com [IPv6:2a00:1450:400c:c09::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 40E8E127078 for ; Wed, 20 Jul 2016 01:19:14 -0700 (PDT) Received: by mail-wm0-x22a.google.com with SMTP id q128so45945239wma.1 for ; Wed, 20 Jul 2016 01:19:14 -0700 (PDT) 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-transfer-encoding; bh=tqstaDGoSjGAUqsXUs3/zAyB9t2vJUGbtTetdUqdfAc=; b=Wt1KyVFIMrrpjws96sNSOJ7NIHwGIT6zVbTkuTJqtyObPW97lsMOSOeh3GLSdOVd2/ ABpfsfknwRDlIjNs8d5W993LYqr2eHb/w40y18kVvcqOS4+cAUTXMTCl10f+QiunCpus stFher5HMRnhM5vrxvQr5W9jsKsDBHtFGCgc96hvNhIKfkceGtZ0QvUkEm0b9AAameP8 qDsO1snCgBi0J1RbOGdmugIuX/2TJG6+BcXFTSYFZYPKoFSy6qsXKHL+Zw6/GzMg8JT1 yYmKyXt3PE1UfRiMXoevFkMt30r1tY6SjGaJcq5BAgrK3gBt6OZ5yTzt81HLlFshHZQW MSZQ== 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-transfer-encoding; bh=tqstaDGoSjGAUqsXUs3/zAyB9t2vJUGbtTetdUqdfAc=; b=I2HfT4EEDMHi29BfFiLZkOavia+VrXfKqTYfHYnFyZRMb6EDLwaOlPpbUOjM1pVFhu JqeNPRvbiHIbrpHw4IiUSCMeRLFEa/k/ZMy9+y3n2MytABzHWaY8aXy5d/I3i8xEttYf p0itE+RytPJv7LTP+oVlwz3NJOD7n8vYnRtINRGgJH1pyl6PMxhjhcAbq3ynyTPo7y94 tofuTW2iG2kKqqmHzMFowrENDnIa2cO1Txq7j+wK3uOOP5yMMVG1ohF8Fyud/eDsHoRV Ac8wUaCztfnNAWgJuGO83hy9AsTOY4Kc9j7h8AZ/fPZQiZp332BA03WRe7e2adehS+YT mxeA== X-Gm-Message-State: ALyK8tKqsW6QunGWsA6lq/6DA/HY0JPRr307Y5UFmUPhGS1BlSidb6kZlwlUpkkYbOyFqg== X-Received: by 10.28.34.212 with SMTP id i203mr10645038wmi.102.1469002753154; Wed, 20 Jul 2016 01:19:13 -0700 (PDT) Received: from ?IPv6:2001:67c:370:176:28cc:dc4c:9703:6781? ([2001:67c:370:176:28cc:dc4c:9703:6781]) by smtp.gmail.com with ESMTPSA id f187sm3795550wmf.15.2016.07.20.01.19.12 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 20 Jul 2016 01:19:12 -0700 (PDT) Subject: Re: draft-ietf-6man-default-iids - keeping section 6 To: ipv6@ietf.org References: From: Brian E Carpenter Organization: University of Auckland Message-ID: Date: Wed, 20 Jul 2016 20:19:17 +1200 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.2.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Archived-At: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.17 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 Jul 2016 08:19:17 -0000 On 20/07/2016 02:47, Bernie Volz (volz) wrote: > Hi: >=20 > I would prefer you keep section 6. Having worked on a bis document rece= ntly, it makes finding at least the most critical changes much easier whe= n reviewing the documents that update the bis document. >=20 > I don=E2=80=99t mind if you were to just enumerate the primary sections= that need updating (or are impacted by the new document) =E2=80=93 rathe= r than providing the complete text. Yes, I think that helps the reader without annoying her with repetition. = Something like: The requirement to use Blahblah instead of Blah applies to the following:= Section x of [RFCxxxx] Section y of [RFCyyyy] etc. Brian >=20 > In the case of the bis document I was working on, there were several do= cuments that claimed they updated it but it turned out they did not. >=20 > - Bernie >=20 >=20 >=20 > -------------------------------------------------------------------- > IETF IPv6 working group mailing list > ipv6@ietf.org > Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 > -------------------------------------------------------------------- >=20 From nobody Wed Jul 20 01:24:46 2016 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 792A112B039 for ; Wed, 20 Jul 2016 01:24:45 -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 AWXtVS7ZRP-G for ; Wed, 20 Jul 2016 01:24:43 -0700 (PDT) Received: from mail-lf0-x233.google.com (mail-lf0-x233.google.com [IPv6:2a00:1450:4010: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 253A912B037 for ; Wed, 20 Jul 2016 01:24:43 -0700 (PDT) Received: by mail-lf0-x233.google.com with SMTP id g62so32845302lfe.3 for ; Wed, 20 Jul 2016 01:24:43 -0700 (PDT) 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-transfer-encoding; bh=e5kbpfO6qJGyH+OiIoMathHEJ40nMf6fr19yjweYjkE=; b=fPfyNgrOeuBmQmE17WD5pAxguYJAvFSy2otCEwuNgCaaY7kccOwXJi1RBHiZswPjhg Ebx09IGjtpLtRxdlILiitrjFUfSjSZo0C2Pf/HtCLKwxmoSZTIh8XMhMtFfLwTv20HBZ P0bnawKyioXhkwmy3/YVpvmDjR4x9aNiJqMBatg1EdyDGMp1UWytu7CN2tq1udfshJdg l6sMSzigO2POYYHKUbuvM0biRR4Q3XNmVW3HdONmeo51JxKQHCLQXGxu5vXpkz8MjheI GIoJbv55o2H5kXqKimVKV23X9PRKFxMN6wGO8EvNfx5SC+G/PNfY83ZDz1msVolCkPzb j0kw== 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-transfer-encoding; bh=e5kbpfO6qJGyH+OiIoMathHEJ40nMf6fr19yjweYjkE=; b=k+g1jblbw2psEe1VD+TZ2baOmyx+Bsrc+E04xJRSmat9o2MWzxPqlmLvSxkby3RGsg Dy3fxuyJCEg3DSItkFjftIVI0UTyOtA618vt0in0ylH99KFjzymj99Q5X69SqmY16u2L WO4lGVNLD1yrfgkt9+dHFkMnR/jMLZpNOoHnjL1Mq/mA4mnI6bTcfjY2e4DVYf+KWHWu 8rlitL26Feg86RJSzfQv2f65fGUkHdG8zJPcpG+NuqF4qUYcNSb+t1taFt/8dEnw+g8k MFVv0GaGabzfAOkIuIG8msWfFNN+qyXnx2mSrQvP/JmZZfprSIgAKNKlxcgkD1aevdpb sjFQ== X-Gm-Message-State: ALyK8tIrveaWIOY4g+lHWOX8cAGDQf6vhCummyAwFa6j0lIcoqSvD380KE3Ot+lo/Wp2IA== X-Received: by 10.46.5.23 with SMTP id 23mr8263032ljf.64.1469003081070; Wed, 20 Jul 2016 01:24:41 -0700 (PDT) Received: from ?IPv6:2001:67c:370:176:28cc:dc4c:9703:6781? ([2001:67c:370:176:28cc:dc4c:9703:6781]) by smtp.gmail.com with ESMTPSA id 20sm364951lja.34.2016.07.20.01.24.40 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 20 Jul 2016 01:24:40 -0700 (PDT) Subject: Re: [6man] #20 (rfc4291bis): Site-local To: ipv6@ietf.org References: <063.b29004adee61477f53c85e1085499f4e@trac.tools.ietf.org> From: Brian E Carpenter Organization: University of Auckland Message-ID: Date: Wed, 20 Jul 2016 20:24:44 +1200 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.2.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Archived-At: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.17 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 Jul 2016 08:24:46 -0000 I don't think the addressing architecture needs to discuss ULA. ULA is just a class of GUA with an operational restriction on its routing; that is not an issue for the addressing architecture. Regards Brian Carpenter (Don't blame me, I voted Remain.) On 20/07/2016 04:24, Alexandre Petrescu wrote: > Mention ULA MAY be used in some of the places where people felt a need > for site-local addresses, and in other places too. >=20 > Alex >=20 > Le 19/07/2016 =C3=A0 13:53, 6man issue tracker a =C3=A9crit : >> #20: Site-local >> >> Remove sections on site local addresses. What to do with ULA? >> >=20 > -------------------------------------------------------------------- > IETF IPv6 working group mailing list > ipv6@ietf.org > Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 > -------------------------------------------------------------------- > . >=20 From nobody Wed Jul 20 01:29:50 2016 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 44A3512D9CE for ; Wed, 20 Jul 2016 01:29:49 -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 CQEU-TpnlePE for ; Wed, 20 Jul 2016 01:29:46 -0700 (PDT) Received: from mail-wm0-x230.google.com (mail-wm0-x230.google.com [IPv6:2a00:1450:400c:c09::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 222EA12B004 for <6man@ietf.org>; Wed, 20 Jul 2016 01:29:46 -0700 (PDT) Received: by mail-wm0-x230.google.com with SMTP id o80so57160073wme.1 for <6man@ietf.org>; Wed, 20 Jul 2016 01:29:46 -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=oFDukP5Q4DCfaThh0J4irOoefTvfIvq/LGux/Ns+wdE=; b=a/fruEVLDjIqWqP8LZyDZ7RNt1GaXNThNiP0AOPdjx9xdH4RUduw+eTrdkFAfFSfVE PDG/UzvAl2bkjHOssGJzowF4JxoYPjX2QbVtUUg8GaDB02QU1ktMvdjuAHSSRZy7X8K/ hdlVHGCaAPTj9jtfGngLlQUtC8c2PXp8qNc5LsOYZ1ShRVmXvdkXbbCxHxmZlOgX32B2 TwAzsCbxIYn/Wd7kLp2KlrDmfZC/NYlkOjdq+fkBkluyt3LHJLx+Qnfq1fwqFyiuHLlh /YO8K4k9OWYDKpiUhi3SBitoXqEQxedmQ7zUKR620ZjSinEwteBBRTsKIXedBZNJ5JeG 7RMQ== 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=oFDukP5Q4DCfaThh0J4irOoefTvfIvq/LGux/Ns+wdE=; b=V6WqIcCQu5Szzvoh4NXgzQlkzTG00RzAhxcJJpr4Qn25tf6RfTo+dKZYPseRsT4Oi8 ziQGS+55rlYHkR4oaJuu/7u8ZTjmDw6y3iiQBAT9fsSsTKy6DCtMbgTFyMAWoimiASOx V5wz72tNZ6NP++l2jLOrUHsq/8s4N4fqw6l8ufhiFPYqeZv9Vjnn1I/RdgbCRypCroZ6 x/FlzYhSTvRa+2ug/7+lgoJTk4cHexNZ8PCIS5ga9TbmGNOKZ1cDZF/4NoiHtyfsQNb7 pDT8OKnad8jMcoWn9nsGL62WT4+gMKMfVaA92XWNKEUuBKMRosnMqRP3mB/ViLAWxVot 7fvg== X-Gm-Message-State: ALyK8tIiqInUn2KeoRYBJ/yS4qpgzbtLkJABn///WH/KE85pkckIfC6YEBU3ckcoWJ23cg== X-Received: by 10.28.48.71 with SMTP id w68mr9752307wmw.4.1469003384668; Wed, 20 Jul 2016 01:29:44 -0700 (PDT) Received: from ?IPv6:2001:67c:370:176:28cc:dc4c:9703:6781? ([2001:67c:370:176:28cc:dc4c:9703:6781]) by smtp.gmail.com with ESMTPSA id p83sm3837163wma.18.2016.07.20.01.29.43 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 20 Jul 2016 01:29:44 -0700 (PDT) Subject: Re: proposed text for header injection revision 05 To: "Stefano Previdi (sprevidi)" , Michael Richardson References: <26582.1468923195@obiwan.sandelman.ca> From: Brian E Carpenter Organization: University of Auckland Message-ID: Date: Wed, 20 Jul 2016 20:29:48 +1200 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.2.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Archived-At: Cc: "Mark Townsley \(townsley\)" , "6man@ietf.org" <6man@ietf.org> X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.17 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 Jul 2016 08:29:49 -0000 On 20/07/2016 20:04, Stefano Previdi (sprevidi) wrote: > Hi, > > I clearly prefer and support Mark's suggestion of removing entirely the second paragraph. > > s. > If we do that I want to see the famous "processed" clarified to make its intended meaning unambiguous: With one exception, extension headers are not processed, modified, inserted or deleted by any node along a packet's delivery path, ... The second paragraph is a compromise that avoids that clarification. Brian > > > >> On Jul 19, 2016, at 12:13 PM, Michael Richardson wrote: >> >> >> for 2nd paragraph: >> >> An approach an intermediate node/router may take to include an additional >> extension header in an IPv6 packet that it did not originate is to >> encapsulate the original packet in a new IPv6 header. As the >> source address of this IPv6 packet would then be the router, any >> number of additional extension headers may be placed after this new header, >> prior to the original packet. A system making use of this mechanism will >> have to specify how to construct the rest of the IPv6 header, in particulate, >> such a specification needs to carefully consider what the destination address >> will be. >> >> >> -- >> 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 >> -------------------------------------------------------------------- > > -------------------------------------------------------------------- > IETF IPv6 working group mailing list > ipv6@ietf.org > Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 > -------------------------------------------------------------------- > From nobody Wed Jul 20 02:28:54 2016 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B90BB12B01F for ; Wed, 20 Jul 2016 02:28:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -15.808 X-Spam-Level: X-Spam-Status: No, score=-15.808 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_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-1.287, 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 tnOCk_bYtwl4 for ; Wed, 20 Jul 2016 02:28:51 -0700 (PDT) Received: from rcdn-iport-8.cisco.com (rcdn-iport-8.cisco.com [173.37.86.79]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D1460128E18 for <6man@ietf.org>; Wed, 20 Jul 2016 02:28:50 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1898; q=dns/txt; s=iport; t=1469006930; x=1470216530; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=+/7p/gn4CCYpL9QxAbXzxVHDR6qVTy0jTMDkx/gP8OE=; b=IEj+4xtJUUUrpicZT8Ehb5L/YaGyKZ15k4uQBvTiOWK9dw0/AIAEyXsI NIpdb9hjQjYFa4NEZf9xsXWvTxNTUukyeC0R+DxD2uWvq6SyAoGOrj1pz iN4D0NchLx860hKGNUppcO24V7j175ARkN5ymHj7IZCcZWaY28MdT4/Ik E=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0ADAgB6Q49X/5RdJa1dgz9WfAa4aoF6I?= =?us-ascii?q?oJBgzcCgTA4FAEBAQEBAQFlJ4RcAQEEAQEBODQLBQcEAgEIEQQBAQEeCQcnCxQ?= =?us-ascii?q?JCAIEAQ0FCIggCA69RAEBAQEBAQEBAQEBAQEBAQEBAQEBARcFhiqETYobBYgfk?= =?us-ascii?q?QcBjlqPQJAfAR42ggscgUxuhnF/AQEB?= X-IronPort-AV: E=Sophos;i="5.28,393,1464652800"; d="scan'208";a="126068424" Received: from rcdn-core-12.cisco.com ([173.37.93.148]) by rcdn-iport-8.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 20 Jul 2016 09:28:49 +0000 Received: from XCH-RCD-010.cisco.com (xch-rcd-010.cisco.com [173.37.102.20]) by rcdn-core-12.cisco.com (8.14.5/8.14.5) with ESMTP id u6K9SowC021935 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Wed, 20 Jul 2016 09:28:50 GMT Received: from xch-rcd-008.cisco.com (173.37.102.18) by XCH-RCD-010.cisco.com (173.37.102.20) with Microsoft SMTP Server (TLS) id 15.0.1210.3; Wed, 20 Jul 2016 04:28:49 -0500 Received: from xch-rcd-008.cisco.com ([173.37.102.18]) by XCH-RCD-008.cisco.com ([173.37.102.18]) with mapi id 15.00.1210.000; Wed, 20 Jul 2016 04:28:49 -0500 From: "Frank Brockners (fbrockne)" To: "Stefano Previdi (sprevidi)" , Michael Richardson Subject: RE: proposed text for header injection revision 05 Thread-Topic: proposed text for header injection revision 05 Thread-Index: AQHR4aYwA280KLTH+UCJWKsifmyTz6AhSxcA///D0dA= Date: Wed, 20 Jul 2016 09:28:49 +0000 Message-ID: <23919a662393402abfa6d669adf4244e@XCH-RCD-008.cisco.com> References: <26582.1468923195@obiwan.sandelman.ca> In-Reply-To: Accept-Language: de-DE, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.61.244.97] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Cc: "Mark Townsley \(townsley\)" , "6man@ietf.org" <6man@ietf.org> X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.17 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 Jul 2016 09:28:53 -0000 +1 Frank -----Original Message----- From: ipv6 [mailto:ipv6-bounces@ietf.org] On Behalf Of Stefano Previdi (spr= evidi) Sent: Mittwoch, 20. Juli 2016 10:04 To: Michael Richardson Cc: Mark Townsley (townsley) ; 6man@ietf.org Subject: Re: proposed text for header injection revision 05 Hi, I clearly prefer and support Mark's suggestion of removing entirely the sec= ond paragraph. s. > On Jul 19, 2016, at 12:13 PM, Michael Richardson = wrote: >=20 >=20 > for 2nd paragraph: >=20 > An approach an intermediate node/router may take to include an=20 > additional extension header in an IPv6 packet that it did not=20 > originate is to encapsulate the original packet in a new IPv6 header. =20 > As the source address of this IPv6 packet would then be the router,=20 > any number of additional extension headers may be placed after this=20 > new header, prior to the original packet. A system making use of this=20 > mechanism will have to specify how to construct the rest of the IPv6=20 > header, in particulate, such a specification needs to carefully=20 > consider what the destination address will be. >=20 >=20 > -- > Michael Richardson , Sandelman Software Works=20 > -=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 > -------------------------------------------------------------------- -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From nobody Wed Jul 20 02:40:55 2016 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 27A9B12D08F for ; Wed, 20 Jul 2016 02:40:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.333 X-Spam-Level: X-Spam-Status: No, score=-5.333 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_ADSP_CUSTOM_MED=0.001, FREEMAIL_FROM=0.001, NML_ADSP_CUSTOM_MED=0.9, RCVD_IN_DNSWL_HI=-5, SPF_SOFTFAIL=0.665] 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 iCZrLrBwffDT for ; Wed, 20 Jul 2016 02:40:52 -0700 (PDT) Received: from oxalide-out.extra.cea.fr (oxalide-out.extra.cea.fr [132.168.224.8]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 450EE12B01C for ; Wed, 20 Jul 2016 02:40:52 -0700 (PDT) Received: from pisaure.intra.cea.fr (pisaure.intra.cea.fr [132.166.88.21]) by oxalide.extra.cea.fr (8.15.2/8.15.2/CEAnet-Internet-out-2.4) with ESMTP id u6K9en4H024161; Wed, 20 Jul 2016 11:40:49 +0200 Received: from pisaure.intra.cea.fr (localhost [127.0.0.1]) by localhost (Postfix) with SMTP id 6F63F204119; Wed, 20 Jul 2016 11:40:49 +0200 (CEST) Received: from muguet1.intra.cea.fr (muguet1.intra.cea.fr [132.166.192.6]) by pisaure.intra.cea.fr (Postfix) with ESMTP id 5F660203FC9; Wed, 20 Jul 2016 11:40:49 +0200 (CEST) Received: from [132.166.84.207] ([132.166.84.207]) by muguet1.intra.cea.fr (8.15.2/8.15.2/CEAnet-Intranet-out-1.4) with ESMTP id u6K9emFp016798; Wed, 20 Jul 2016 11:40:48 +0200 Subject: Re: 2464 - link-local multicast address mapping To: Mark Smith References: <26148.1468914385@obiwan.sandelman.ca> <1ac389c5-22ca-2283-d09c-a26bea9c7a75@gmail.com> From: Alexandre Petrescu Message-ID: Date: Wed, 20 Jul 2016 11:40:47 +0200 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.2.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Archived-At: Cc: 6man WG X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.17 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 Jul 2016 09:40:54 -0000 Le 20/07/2016 à 00:01, Mark Smith a écrit : > On 20 Jul 2016 2:12 AM, "Alexandre Petrescu" > > > wrote: >> >> Hi, >> >> Currently the RFC2464 multicast address mapping says: >> >>> An IPv6 packet with a multicast destination address DST, >>> consisting of the sixteen octets DST[1] through DST[16], is >>> transmitted to the Ethernet multicast address whose first two >>> octets are the value 3333 hexadecimal and whose last four octets >>> are the last four octets of DST. >> >> >> I think this mapping should happen only for link-scoped IPv6 > destination addresses, not other scopes. >> >> I.e. the last four octets of a _link-local_ IPv6 address should >> get > mapped into that MAC address (ff02::XXXX:XXXX -> 33-33-XX-XX-XX-XX); > multicast addresses of other scopes than ff02 should not get mapped. >> > > I think you're assuming that there are no other nodes on the link > are members of the > link-local scope group, or that there is no more > than one multicast router on the link. Yes, I do assume so. > Multicast address scopes are only indicating boundary of the > multicast forwarding domain, not where multicast group members are or > are not. But an Ethernet 33-33- scope can only be a link scope. A reverse mapping from an Ethernet scope back to a > link-local scope would make no sense. (I also assume mapping to be bidirectional). Alex > > Regards, Mark. > >> Alex >> >> -------------------------------------------------------------------- >> >> IETF IPv6 working group mailing list >> ipv6@ietf.org Administrative >> Requests:https://www.ietf.org/mailman/listinfo/ipv6 > >> -------------------------------------------------------------------- > From nobody Wed Jul 20 02:50:08 2016 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6030F12D0EC for ; Wed, 20 Jul 2016 02:50:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.353 X-Spam-Level: X-Spam-Status: No, score=-5.353 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_ADSP_CUSTOM_MED=0.001, FREEMAIL_FROM=0.001, NML_ADSP_CUSTOM_MED=0.9, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_SOFTFAIL=0.665] 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 xXRryXerfuSp for ; Wed, 20 Jul 2016 02:50:05 -0700 (PDT) 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 EED2512D0A5 for ; Wed, 20 Jul 2016 02:50:04 -0700 (PDT) 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 u6K9o0HS009396; Wed, 20 Jul 2016 11:50:00 +0200 Received: from pisaure.intra.cea.fr (localhost [127.0.0.1]) by localhost (Postfix) with SMTP id F042E204050; Wed, 20 Jul 2016 11:49:59 +0200 (CEST) Received: from muguet2.intra.cea.fr (muguet2.intra.cea.fr [132.166.192.7]) by pisaure.intra.cea.fr (Postfix) with ESMTP id DEA30202C2C; Wed, 20 Jul 2016 11:49:59 +0200 (CEST) Received: from [132.166.84.207] ([132.166.84.207]) by muguet2.intra.cea.fr (8.15.2/8.15.2/CEAnet-Intranet-out-1.4) with ESMTP id u6K9nxfW013816; Wed, 20 Jul 2016 11:49:59 +0200 Subject: Re: Reference to "3333" value of RFC2464 "IPv6 over Ethernet" To: Hemant Singh References: <2f437218b23a44238ccdcb4e7318da8d@XCH-RCD-003.cisco.com> <5d4c7db8-76cf-8e87-4102-2b5ae9b9817f@gmail.com> From: Alexandre Petrescu Message-ID: <90610692-08a8-1c15-4f79-62263808fa98@gmail.com> Date: Wed, 20 Jul 2016 11:49:59 +0200 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.2.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 X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.17 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 Jul 2016 09:50:07 -0000 Le 20/07/2016 à 00:40, Hemant Singh a écrit : > As others have said, it's rfc2464 that mentions the multicast mac > first two octects for IPv6 multicast traffic. The problem is that that RFC has no authority outside the group of IP users. Nobody reads it other than people who use IP. That means the non-IP people can use 33-33- multicast group without worrying to clash anything. They set the L local bit just like anybody else. Where IPv6 to use a multicast address within the IANA OUI 01-00-5E- (not the C9 of IS-IS) then there would be no such risk: IEEE assigns that OUI to IETF, IETF is sure to be alone on it, it has no L bit set. > One should not expect the same for IS-IS because IS-IS is a > link-layer routing protocol. From day one, IS-IS defines the two > multicast mac-address for use with link-layer multicast. Does IS-IS also make use of 01-00-5E- multicast IANA OUI? (in addition to that C9). Alex > > Hemant > > On Tue, Jul 19, 2016 at 12:17 PM, Alexandre Petrescu > > > wrote: > > Thanks for the reply. > > I could not find "C9" or "multicast" in ISIS IPv6 RFC5308. Is there > a reference RFC for the ISIS use of it. > > (the other address is 01-80-C2-00-00-1D ISO/IEC JTC1/SC6 ISO/IEC > 9542 "All Multicast Capable Intermediate Systems Address") > > Alex > > > > > > -------------------------------------------------------------------- > IETF IPv6 working group mailing list ipv6@ietf.org > Administrative Requests: > https://www.ietf.org/mailman/listinfo/ipv6 > -------------------------------------------------------------------- > > From nobody Wed Jul 20 03:03:15 2016 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A32FE12D0A5 for ; Wed, 20 Jul 2016 03:03:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -15.808 X-Spam-Level: X-Spam-Status: No, score=-15.808 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.287, 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 Y_rViJI-WDx4 for ; Wed, 20 Jul 2016 03:03:08 -0700 (PDT) Received: from alln-iport-2.cisco.com (alln-iport-2.cisco.com [173.37.142.89]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 76DFA12D178 for <6man@ietf.org>; Wed, 20 Jul 2016 03:03:08 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=3150; q=dns/txt; s=iport; t=1469008988; x=1470218588; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=eQEPwFuRlJ0izS3NFED1//q2gxrxxxPTM3jDrp0qA7Q=; b=Jw0kTYyV9fLuW9n8eC/dqMwl0t5uOmrzjy84V/7Jo7oT6LXEWnSzChn7 GF8rzAtPxHdlTNmNkKwtMV3p8fEgjLjF643yP6jiKscy92sXtDq9br7W0 dHNTdgWQgnPPCSHBe1JG9HpQ7z9kAo+jpUCj28KWFS506Bg12lHWR9QCw U=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0ADAgD4So9X/4kNJK1dgz9WfAa4a4F6I?= =?us-ascii?q?oJBgzcCgS44FAEBAQEBAQFlJ4RcAQEFAQE4NAsMBAIBCBEEAQEBHgkHJwsUCQg?= =?us-ascii?q?CBAENBQgMiBwOvT4BAQEBAQEBAQEBAQEBAQEBAQEBAQEXBYYqhE2KGwWIH4tFh?= =?us-ascii?q?UIBjlqPQJAfAR42ggscgUxuhnF/AQEB?= X-IronPort-AV: E=Sophos;i="5.28,393,1464652800"; d="scan'208";a="298509822" Received: from alln-core-4.cisco.com ([173.36.13.137]) by alln-iport-2.cisco.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 20 Jul 2016 10:03:07 +0000 Received: from XCH-ALN-008.cisco.com (xch-aln-008.cisco.com [173.36.7.18]) by alln-core-4.cisco.com (8.14.5/8.14.5) with ESMTP id u6KA37G5014289 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Wed, 20 Jul 2016 10:03:07 GMT Received: from xch-rcd-001.cisco.com (173.37.102.11) by XCH-ALN-008.cisco.com (173.36.7.18) with Microsoft SMTP Server (TLS) id 15.0.1210.3; Wed, 20 Jul 2016 05:03:06 -0500 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.1210.000; Wed, 20 Jul 2016 05:03:06 -0500 From: "Pascal Thubert (pthubert)" To: "Frank Brockners (fbrockne)" , "Stefano Previdi (sprevidi)" , Michael Richardson Subject: RE: proposed text for header injection revision 05 Thread-Topic: proposed text for header injection revision 05 Thread-Index: AQHR4aY5NZawrgb030qoQPr6BVJAHaAhSxcAgAAXrID//7OnMA== Date: Wed, 20 Jul 2016 10:02:46 +0000 Deferred-Delivery: Wed, 20 Jul 2016 10:02:39 +0000 Message-ID: <28d08d741f4443b28a21f6b44b9bd842@XCH-RCD-001.cisco.com> References: <26582.1468923195@obiwan.sandelman.ca> <23919a662393402abfa6d669adf4244e@XCH-RCD-008.cisco.com> In-Reply-To: <23919a662393402abfa6d669adf4244e@XCH-RCD-008.cisco.com> 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.61.239.149] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Cc: "Mark Townsley \(townsley\)" , "6man@ietf.org" <6man@ietf.org> X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.17 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 Jul 2016 10:03:13 -0000 Same here. Mark's point that in the real world encapsulation is not necessarily THE te= chnique extends beyond Segment routing. All the open implementations of RPL= that I am aware of do header insertion. And are pretty happy with it. There's an effort in the ROLL community (useofrplinfo draft) to figure out = how encapsulation would work, and there's a prototype based on openWSN, but= that proves extremely difficult in some cases, and expensive in energy. Cheers, Pascal > -----Original Message----- > From: ipv6 [mailto:ipv6-bounces@ietf.org] On Behalf Of Frank Brockners > (fbrockne) > Sent: mercredi 20 juillet 2016 11:29 > To: Stefano Previdi (sprevidi) ; Michael Richardson > > Cc: Mark Townsley (townsley) ; 6man@ietf.org > Subject: RE: proposed text for header injection revision 05 >=20 > +1 >=20 > Frank >=20 > -----Original Message----- > From: ipv6 [mailto:ipv6-bounces@ietf.org] On Behalf Of Stefano Previdi > (sprevidi) > Sent: Mittwoch, 20. Juli 2016 10:04 > To: Michael Richardson > Cc: Mark Townsley (townsley) ; 6man@ietf.org > Subject: Re: proposed text for header injection revision 05 >=20 > Hi, >=20 > I clearly prefer and support Mark's suggestion of removing entirely the s= econd > paragraph. >=20 > s. >=20 >=20 >=20 >=20 > > On Jul 19, 2016, at 12:13 PM, Michael Richardson > wrote: > > > > > > for 2nd paragraph: > > > > An approach an intermediate node/router may take to include an > > additional extension header in an IPv6 packet that it did not > > originate is to encapsulate the original packet in a new IPv6 header. > > As the source address of this IPv6 packet would then be the router, > > any number of additional extension headers may be placed after this > > new header, prior to the original packet. A system making use of this > > mechanism will have to specify how to construct the rest of the IPv6 > > header, in particulate, such a specification needs to carefully > > consider what the destination address will be. > > > > > > -- > > Michael Richardson , Sandelman Software Works > > -=3D IPv6 IoT consulting =3D- > > > > > > > > -------------------------------------------------------------------- > > 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 > -------------------------------------------------------------------- > IETF IPv6 working group mailing list > ipv6@ietf.org > Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 > -------------------------------------------------------------------- From nobody Wed Jul 20 03:44:06 2016 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C984C12D1A2 for ; Wed, 20 Jul 2016 03:44:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.336 X-Spam-Level: X-Spam-Status: No, score=-1.336 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, SPF_HELO_PASS=-0.001, SPF_SOFTFAIL=0.665] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=employees.org; domainkeys=pass (1024-bit key) header.from=otroan@employees.org header.d=employees.org 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 hWXyiEsGNzRK for ; Wed, 20 Jul 2016 03:44:02 -0700 (PDT) Received: from incoming.kjsl.com (inbound02.kjsl.com [IPv6:2001:1868:2002::144]) (using TLSv1.2 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 09B4A12D18B for ; Wed, 20 Jul 2016 03:43:54 -0700 (PDT) Received: from cowbell.employees.org ([IPv6:2001:1868:a000:17::142]) by ironport02.kjsl.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 20 Jul 2016 10:43:54 +0000 Received: from cowbell.employees.org (localhost [127.0.0.1]) by cowbell.employees.org (Postfix) with ESMTP id 0440C9CC7C; Wed, 20 Jul 2016 03:43:53 -0700 (PDT) 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=kI2mNIvHImGZ2ZT4fj8RbuL1Efw=; b= hzfa/CB1w1P17TCo4zLldKJ+zmA8lIfnDb80qUq9gT1m1C2LNRN+TfHs34h3dSgf XAxC0QwUjH+6m4iaSSbkwQo2eAX6gl2koSxU9ch4pQEWENWjvkCr6YUXjMKObDwb 6z1XPmAoeCgBJkTnw3EM3xHjyhXBM5JozISo6aGjWHs= 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=gKTUGhergSi7cx0bnpsxVkwjcl DrnEsibXrVoQ2nLizHSMNxXumZ14SlUY3fSqABiDQ93+TnHlt9Kl51G5V4RYz6t4 OPWF+7v8IOMrXUX4gNCyPrSEIuwtTwf0Be3FWMfjEwCxJIqNDzvxsdZISYLSv5xB c6VL6PmLl1uZe/NQ0= Received: from h.hanazo.no (unknown [193.110.199.36]) (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 B92AE9CC4F; Wed, 20 Jul 2016 03:43:52 -0700 (PDT) Received: from [IPv6:::1] (localhost [IPv6:::1]) by h.hanazo.no (Postfix) with ESMTP id E2CEE2B6FB95; Wed, 20 Jul 2016 12:43:52 +0200 (CEST) Subject: Re: draft-ietf-6man-default-iids - keeping section 6 Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) Content-Type: multipart/signed; boundary="Apple-Mail=_3E57CAA0-1E2C-457D-AD02-CDEB00E31461"; protocol="application/pgp-signature"; micalg=pgp-sha512 X-Pgp-Agent: GPGMail From: otroan@employees.org In-Reply-To: Date: Wed, 20 Jul 2016 12:43:52 +0200 Message-Id: <85EF1F7A-A4F6-4480-8B98-64E5F7359EEC@employees.org> References: To: Brian E Carpenter X-Mailer: Apple Mail (2.3124) Archived-At: Cc: 6man WG X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.17 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 Jul 2016 10:44:04 -0000 --Apple-Mail=_3E57CAA0-1E2C-457D-AD02-CDEB00E31461 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 >> I would prefer you keep section 6. Having worked on a bis document = recently, it makes finding at least the most critical changes much = easier when reviewing the documents that update the bis document. >>=20 >> I don=E2=80=99t mind if you were to just enumerate the primary = sections that need updating (or are impacted by the new document) =E2=80=93= rather than providing the complete text. >=20 > Yes, I think that helps the reader without annoying her with = repetition. Something > like: >=20 > The requirement to use Blahblah instead of Blah applies to the = following: >=20 > Section x of [RFCxxxx] > Section y of [RFCyyyy] >=20 > etc. that might be a good compromise. Best regards, Ole --Apple-Mail=_3E57CAA0-1E2C-457D-AD02-CDEB00E31461 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 iQEcBAEBCgAGBQJXj1XoAAoJED4aXnjSQuKWolQIAIcjP6cR3305Y/fITB/1Gder vtCm88N5sa6YyLwj8fI9M77UPCgJgLgacxa5Mbmd/MqjZVC1TgN3218fKWp8DfRe /S3S2yrPUILx48ajEvrX6IY15T+ldeST9r4svCrShKZZhEJrkPp7vj25wnfC4ydJ Gj9Mqgqb9PsfuDxDKvrWkza943nGakHbj+1LCPZ7Wf6rX/JUPg96sBDlA8zO0mWe lXZ7RUaDBvxMfGTrrmrV71uT0Ch0QlMRttEAyFzeg8SxTnHKTKNGCW6L4fN8wHRQ cYo8tcEoONirfPEUiy+vHIeV3V0IhrTBOONhsnKQ9n71pHS/Nxm8sgP8Oomlz3Q= =1U3n -----END PGP SIGNATURE----- --Apple-Mail=_3E57CAA0-1E2C-457D-AD02-CDEB00E31461-- From nobody Wed Jul 20 03:55:18 2016 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6DE8612D09C for ; Wed, 20 Jul 2016 03:55:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.566 X-Spam-Level: X-Spam-Status: No, score=-0.566 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_SORBS_WEB=0.77, SPF_HELO_PASS=-0.001, SPF_SOFTFAIL=0.665] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=employees.org; domainkeys=pass (1024-bit key) header.from=otroan@employees.org header.d=employees.org 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 hWQGL8ohyZr8 for ; Wed, 20 Jul 2016 03:55:15 -0700 (PDT) Received: from incoming.kjsl.com (inbound02.kjsl.com [IPv6:2001:1868:2002::144]) (using TLSv1.2 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D51AE12D0F7 for <6man@ietf.org>; Wed, 20 Jul 2016 03:55:14 -0700 (PDT) Received: from cowbell.employees.org ([65.50.211.142]) by ironport02.kjsl.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 20 Jul 2016 10:55:13 +0000 Received: from cowbell.employees.org (localhost [127.0.0.1]) by cowbell.employees.org (Postfix) with ESMTP id B55109CC7C; Wed, 20 Jul 2016 03:55:12 -0700 (PDT) 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=r8jTOJqq8cM8B8+CeH7OvR8IGtk=; b= gcuBwQVcG/W7ZC8DBbN+OrKWlrLhgf1aS0o6DHz477MXJJg2uxhpCAJfKuseBaD5 9aQChLJTnqFWWkVKXRPU/K7BC1PgUEAcM4Do0mA1aw2IvZVkVI/7oadU3ICg9IzN ZCOGXpIOT+IMNczdQ5i83eoa8/gzfa4B5cwUzsKt1g4= 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=QzF172SToU+9VPDwQrdRxKJaEN h9tCEMWjYl1+WFA9NWd6Qb1/VnS4Zu3E6OkVVfkX7nZ2h1CD7sIcWle+XC2hUP88 nJXWNgfu15MjSZQPondrFpMUVGm2V5f9Acgj8CfDIoQE2JSlj4EOv+XrI9pDT2nm 9ugsf1sdRR5B5lRus= Received: from h.hanazo.no (unknown [193.110.199.36]) (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 4C5B59CC4E; Wed, 20 Jul 2016 03:55:12 -0700 (PDT) Received: from [IPv6:::1] (localhost [IPv6:::1]) by h.hanazo.no (Postfix) with ESMTP id 6FFAC2B702E6; Wed, 20 Jul 2016 12:55:13 +0200 (CEST) Subject: Re: proposed text for header injection revision 05 Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) Content-Type: multipart/signed; boundary="Apple-Mail=_B676A5A7-F747-48F0-9DAC-159F968868B5"; protocol="application/pgp-signature"; micalg=pgp-sha512 X-Pgp-Agent: GPGMail From: otroan@employees.org In-Reply-To: Date: Wed, 20 Jul 2016 12:55:12 +0200 Message-Id: <2EBFA6F2-00A3-45E1-BE0E-3531AF75726A@employees.org> References: <26582.1468923195@obiwan.sandelman.ca> To: Brian E Carpenter X-Mailer: Apple Mail (2.3124) Archived-At: Cc: Michael Richardson , "6man@ietf.org" <6man@ietf.org>, "Mark Townsley \(townsley\)" X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.17 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 Jul 2016 10:55:16 -0000 --Apple-Mail=_B676A5A7-F747-48F0-9DAC-159F968868B5 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii >> I clearly prefer and support Mark's suggestion of removing entirely = the second paragraph. >>=20 >> s. >>=20 >=20 > If we do that I want to see the famous "processed" clarified to make = its > intended meaning unambiguous: >=20 > With one exception, extension headers are not processed, modified, = inserted > or deleted by any node along a packet's delivery path, ... that text seems to say that in the exception case extension headers can = be modified, inserted or deleted. I'm pretty sure that's not what we want to say. ;-) > The second paragraph is a compromise that avoids that clarification. yes, I fear that the suggestion of deleting that paragraph will lead us = into the same round of disagreements that led up to that compromise. let's assume we cannot find consensus on removing the paragraph, nor can = we find consensus on adding the "processed" clarification. I don't mind tweaking the second paragraph if that's required. currently it says: The current approach to allowing a header to be inserted is to encapsulate the packet using another IPv6 header and including the additional extension header after the first IPv6 header, for example, as defined in [RFC2473]. Michael proposed: An approach an intermediate node/router may take to include an = additional extension header in an IPv6 packet that it did not originate is to encapsulate the original packet in a new IPv6 header. As the source address of this IPv6 packet would then be the router, any number of additional extension headers may be placed after this new = header, prior to the original packet. A system making use of this mechanism = will have to specify how to construct the rest of the IPv6 header, in = particulate, such a specification needs to carefully consider what the destination = address will be. or simply: One approach to inserting Extension Headers by a node other than the = source of the packet is to encapsulate the packet using a new IPv6 header and including the = additional Extension Headers as specified in section 3.1 of RFC2473. any others? a case of the beer for the winner! ;-) Best regards, Ole --Apple-Mail=_B676A5A7-F747-48F0-9DAC-159F968868B5 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 iQEcBAEBCgAGBQJXj1iRAAoJED4aXnjSQuKWKwcIAKDT89DpxPzQakckwiPo0EiT lPuB9K+Kuk2P0bzsbOqVJSlnJhdKLRykvjD2437Yh623iM+WhX0c29Gm3mXFecqv 9VFUfsxt3vxS2HiN/Vgxs2drpURdaBf1C0zpLJncfIDXO4oGaNPh8mNqD7Rcad8T r7sUnjG5c2kfIFsOL8AUp9hPrlHzdO9VX7o6SDqtIaEjKrvnh3f6nquYeHjm0UH7 Y+mOs6zFgO/DsZP5Bb9Mf25Uq9xlu//s/NfqHG5QKZNHgQFItjUs6AcYnvVUHRzh NmvSUYFBHJlmMyyazDUQ0DC05flYj6/v09+wTUdsQcTA6TnfuZ8Y568ntcVUgog= =mAQ2 -----END PGP SIGNATURE----- --Apple-Mail=_B676A5A7-F747-48F0-9DAC-159F968868B5-- From nobody Wed Jul 20 05:24:40 2016 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9184B12D177 for ; Wed, 20 Jul 2016 05:24:36 -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=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=venaas-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 Ma0RCMuU6MRN for ; Wed, 20 Jul 2016 05:24:34 -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 2220612D1D1 for ; Wed, 20 Jul 2016 05:24:34 -0700 (PDT) Received: by mail-lf0-x229.google.com with SMTP id b199so37161128lfe.0 for ; Wed, 20 Jul 2016 05:24:34 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=venaas-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=1NeNBGVlEbISlnfXuhu6R/PapXGwIRZRgkcPGC7xYjI=; b=rlNt1pCrNJK7ZIz9Uds6A8Qv3KgIRn3EUGaAQhPXclfSsMd7pzlCZZb42DAstYcjJk TRIXKTP3lIVrzqf32pb6Z8KubPvK7dPrqDA88eA6OMpZdU+O+qdEd83eDoTtU09rUE8c 3ZPfp5+Hujl24NS4v+DAa0dx4N5Qc8DT4loAPkTSq2sU19LjppbqV9cPsBKfmvb2KdqT yHRkm/HFa/be2xFCIMkRL3tYEtdnfQwU4f8NvHAS6EWfsVb6Ri15/zTFJqDtBE02Ca90 2XBonvEYmTlNTV8Gkvioghfr9po5YMBYN0Ac4Yp4xjaKqFWBAw3yIAX+B/+DXaZW9d4S jJlg== 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-transfer-encoding; bh=1NeNBGVlEbISlnfXuhu6R/PapXGwIRZRgkcPGC7xYjI=; b=mYQiMAORst5tuOs+krVBtxUJJhdMJ/D0+2jlIQLhNOkf+ZD4++8e4XXMeOnHfxgzyL BUlEfenS8LPrTRDkHOR0Orru/ce6XvKBp1DYhjbGTL+yqYgzd7b9/k1KcFuIr82JaSiM jf+MZpa2krgwwOyODPORKrgVc+HEhxUxxMCUGLXbgnx74qUoiwD5fQn8Pa5pAvDppBlD MfToPBwMWSgMZtSw/w3qdgykrScUFVQSiC+SjlEqCZ8WH34HhVkm/Qc+GqOPJOInehMC keEkBjzc7dmwXDw146330dRO/mAUA4Vwq8hakkqykt298iFlJVdBcMiWTV0ugE/0aJpP F+jQ== X-Gm-Message-State: ALyK8tJH+CPYPzTcuFsQFeYjLdDXGp8mDbpH6k+6xb9sLt1uAR/n3/eEunQVzGMzG/JHI97wNje3YZZBMW5etg== X-Received: by 10.25.21.197 with SMTP id 66mr18340517lfv.99.1469017472229; Wed, 20 Jul 2016 05:24:32 -0700 (PDT) MIME-Version: 1.0 Received: by 10.25.165.72 with HTTP; Wed, 20 Jul 2016 05:24:31 -0700 (PDT) In-Reply-To: References: <26148.1468914385@obiwan.sandelman.ca> <1ac389c5-22ca-2283-d09c-a26bea9c7a75@gmail.com> From: Stig Venaas Date: Wed, 20 Jul 2016 05:24:31 -0700 Message-ID: Subject: Re: 2464 - link-local multicast address mapping To: Alexandre Petrescu Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Archived-At: Cc: 6man WG X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.17 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 Jul 2016 12:24:36 -0000 Hi On Wed, Jul 20, 2016 at 2:40 AM, Alexandre Petrescu wrote: > > > Le 20/07/2016 =C3=A0 00:01, Mark Smith a =C3=A9crit : >> >> On 20 Jul 2016 2:12 AM, "Alexandre Petrescu" >> > >> wrote: >>> >>> >>> Hi, >>> >>> Currently the RFC2464 multicast address mapping says: >>> >>>> An IPv6 packet with a multicast destination address DST, >>>> consisting of the sixteen octets DST[1] through DST[16], is >>>> transmitted to the Ethernet multicast address whose first two >>>> octets are the value 3333 hexadecimal and whose last four octets >>>> are the last four octets of DST. >>> >>> >>> >>> I think this mapping should happen only for link-scoped IPv6 Why? Both for IPv4 and IPv6 you need to have some destination multicast MAC address for any IP/IPv6 multicast packet, regardless of scope. >> >> destination addresses, not other scopes. >>> >>> >>> I.e. the last four octets of a _link-local_ IPv6 address should >>> get >> >> mapped into that MAC address (ff02::XXXX:XXXX -> 33-33-XX-XX-XX-XX); >> multicast addresses of other scopes than ff02 should not get mapped. >>> >>> >> >> I think you're assuming that there are no other nodes on the link >> are members of the > link-local scope group, or that there is no more >> than one multicast router on the link. > > > Yes, I do assume so. It's fairly common to have multiple multicast routers on the link, and there can definitely be multiple members of a link-local group (or any group) on the link. >> Multicast address scopes are only indicating boundary of the >> multicast forwarding domain, not where multicast group members are or >> are not. > > > But an Ethernet 33-33- scope can only be a link scope. A reverse Why? > mapping from an Ethernet scope back to a > link-local scope would make > no sense. > > (I also assume mapping to be bidirectional). What do you mean by bidirectional? As you wrote, you cannot do a reverse mapping. Stig > Alex > >> >> Regards, Mark. >> >>> Alex >>> >>> -------------------------------------------------------------------- >>> >>> > 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 Jul 20 05:56:12 2016 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8E08512D5F7 for ; Wed, 20 Jul 2016 05:56: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 Qu2M7gJLMYpY for ; Wed, 20 Jul 2016 05:56:05 -0700 (PDT) Received: from mail-wm0-x22c.google.com (mail-wm0-x22c.google.com [IPv6:2a00:1450:400c: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 138AC12DC00 for <6man@ietf.org>; Wed, 20 Jul 2016 05:55:58 -0700 (PDT) Received: by mail-wm0-x22c.google.com with SMTP id q128so55233097wma.1 for <6man@ietf.org>; Wed, 20 Jul 2016 05:55:57 -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=E63BY5jmUEVnWGZmBW55eGIw2q/Zcl2/YAZJlbm9IMs=; b=so3p1pZrQWWv/tP/je/YSOIM596CSA+o+3xEeoCin0ghuonxerrGVRp+LQqML7mdhn EwhrOrO6TYJ7VAN9dKIo/odQEtguZuAU3qSqir4fWv5aPgXe9eecS4KJLyfiy/l8LCjH gMRPZNcL7SGf8vgVdz3viCDxTFw4uMi1aXIzbfFAwgkOWHiZ3W+IE2A+m+6sFwhhFLSn hUwdjG0Y659dOu5kOqABuDS8yMWVi3ThGDGm5QO8QbpUidSGa2ZkXMv6pwxIF7fVXzYC 1OLolgLhLfuOH5loi0E7gUiRpW1rp/UOzzzxmLWOMrRuDVColpcBTKdAZN8AJthbHPgg RDCA== 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=E63BY5jmUEVnWGZmBW55eGIw2q/Zcl2/YAZJlbm9IMs=; b=JI0K+Un5+1/Lrb+gN6lksRns6DNBjockHOSVc1t44yQlKd9OED5NprBJBN+AAKcSDC wqw30DleLTJqXtXBlj3nRSwv36p2p7dsc86Mhzp4ncKWVCqmmgMHIwKXJLmsSKleS0re 5rKH0nc/6VDVz9Pmp4917LnCllXflQHRt3NzGza8tj4/FSUpzRu6svC6BfLdIYvKvhnr sIvZWZtl7rOmy8rXnGUd2o1XJhTTQo+i1yzJSpl7Bra2XAzwPtWPayQHg1Vl7HhpBJXz HbTXBB/QFSRJzW08q/aMi7z4xDkm117bxDRH4Kir5UF7x8MegPTAPu7UdIOkbvRdetBM YCOA== X-Gm-Message-State: ALyK8tJaSTcFLtm6Jzcx1RpqluUpHLLoRcKuPgVQV4duVed+UUXxUZWbvchxlYXLjTrYPw== X-Received: by 10.195.12.115 with SMTP id ep19mr1242449wjd.165.1469019356545; Wed, 20 Jul 2016 05:55:56 -0700 (PDT) Received: from ?IPv6:2001:67c:370:176:28cc:dc4c:9703:6781? ([2001:67c:370:176:28cc:dc4c:9703:6781]) by smtp.gmail.com with ESMTPSA id v189sm31296092wmv.12.2016.07.20.05.55.55 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 20 Jul 2016 05:55:55 -0700 (PDT) Subject: Re: proposed text for header injection revision 05 To: otroan@employees.org References: <26582.1468923195@obiwan.sandelman.ca> <2EBFA6F2-00A3-45E1-BE0E-3531AF75726A@employees.org> From: Brian E Carpenter Organization: University of Auckland Message-ID: <679eb1c4-8385-9d4e-420c-cb1efabfbb9e@gmail.com> Date: Thu, 21 Jul 2016 00:56:01 +1200 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.2.0 MIME-Version: 1.0 In-Reply-To: <2EBFA6F2-00A3-45E1-BE0E-3531AF75726A@employees.org> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Archived-At: Cc: Michael Richardson , "6man@ietf.org" <6man@ietf.org>, "Mark Townsley \(townsley\)" X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.17 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 Jul 2016 12:56:11 -0000 Below... On 20/07/2016 22:55, otroan@employees.org wrote: >>> I clearly prefer and support Mark's suggestion of removing entirely the second paragraph. >>> >>> s. >>> >> >> If we do that I want to see the famous "processed" clarified to make its >> intended meaning unambiguous: >> >> With one exception, extension headers are not processed, modified, inserted >> or deleted by any node along a packet's delivery path, ... > > that text seems to say that in the exception case extension headers can be modified, inserted or deleted. > I'm pretty sure that's not what we want to say. ;-) > >> The second paragraph is a compromise that avoids that clarification. > > yes, I fear that the suggestion of deleting that paragraph will lead us into the same round of disagreements that led up to that compromise. > > let's assume we cannot find consensus on removing the paragraph, nor can we find consensus on adding the "processed" clarification. > > I don't mind tweaking the second paragraph if that's required. > currently it says: > > The current approach to allowing a header to be inserted is to > encapsulate the packet using another IPv6 header and including the > additional extension header after the first IPv6 header, for example, > as defined in [RFC2473]. > > Michael proposed: > > An approach an intermediate node/router may take to include an additional > extension header in an IPv6 packet that it did not originate is to > encapsulate the original packet in a new IPv6 header. As the > source address of this IPv6 packet would then be the router, any > number of additional extension headers may be placed after this new header, > prior to the original packet. A system making use of this mechanism will > have to specify how to construct the rest of the IPv6 header, in particulate, > such a specification needs to carefully consider what the destination address > will be. > > or simply: > > One approach to inserting Extension Headers by a node other than the source of the packet > is to encapsulate the packet using a new IPv6 header and including the additional > Extension Headers as specified in section 3.1 of RFC2473. Yes, that occurred to me during the meeting. "The current approach..." implies that it is almost BCP, but "One approach..." leaves the field open. Can we compromise on that? I hope so. Brian > > any others? a case of the beer for the winner! ;-) > > Best regards, > Ole > From nobody Wed Jul 20 05:57:48 2016 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D9E5B12D620 for ; Wed, 20 Jul 2016 05:57:45 -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=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 gIJWjkrcyfrr for ; Wed, 20 Jul 2016 05:57:44 -0700 (PDT) Received: from mail-oi0-x230.google.com (mail-oi0-x230.google.com [IPv6:2607:f8b0:4003: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 100DB12DBAD for ; Wed, 20 Jul 2016 05:52:17 -0700 (PDT) Received: by mail-oi0-x230.google.com with SMTP id j185so69631627oih.0 for ; Wed, 20 Jul 2016 05:52:17 -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=xFOdv+DcUlVz/dLpLQxMBMgtcVFR6B0K8BFGW2L/0hw=; b=yesMoycLHTcOOW7kC3UOVu/8WVPNm1UsxZZ9zqEv1NyB7Ky3XyHo13dsNkPeSFl4Rx bJqzIZ5vDfz5LpDx2no+zQnQ1dyHx/0oi2Mw/x9jveoH8A4VL5qVLpOMinmEVxqPcgE4 3l7+IXkzXfzeU+lUiCFteuE5I9pY7zJ9MuhWDEMerVkf8HZoym09FnAd0mUrBCYrmOr+ 7RiDGeI88Wo2XrwMVdOXU463DdWwYVQYY0owJ8DlHCtzJQMbz4XnD9kj1jXnp/0noufG idq0IGz+HafrgVwrVEEFzHl6HE1EFpFwqSTAMuy4gTPJOjXjl4FJmswJgRzBr4kw8IBu d4JQ== 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=xFOdv+DcUlVz/dLpLQxMBMgtcVFR6B0K8BFGW2L/0hw=; b=QWOO4xjcoYnFYd3fCzLKXoX1f/WSHZJ8EVUqwwDIZCMbkmS6QWry5+yKr9H9JerLQf bzHMXh4uguFkH1wkICmBRizoegaCSfxhiF0pAecaX7Xjws8mzqdTNRM6iCOkDcKCUEkN dGzlRiqUruIic8EO//RCh3Z1PKC/tMrMuuzbm2/XtmRCPXwHLMR5MPOi5tLExro5352R I0kOK1BM5ICrwa48HqnFzPTkACTl7F6Bn85TkekIZRe77dge5ilELojnmHLS+V7DBAjb AtJ5PQUVC8e1e5qJKADp6vGIUzzEOtsriF1ZCl2/NwyPcZgDpL+0VvDRRr3f6X2uuXhp hJQQ== X-Gm-Message-State: ALyK8tJEp3AmcRAKplNiLhHKofIcZIeu6VrtcrPbR2JtZIvnBML/techlrSSOfSRHe816XlVeHl9CQ4ZL8j+Aw== X-Received: by 10.157.38.242 with SMTP id i47mr27808383otd.123.1469019136520; Wed, 20 Jul 2016 05:52:16 -0700 (PDT) MIME-Version: 1.0 Received: by 10.182.172.66 with HTTP; Wed, 20 Jul 2016 05:52:15 -0700 (PDT) In-Reply-To: <90610692-08a8-1c15-4f79-62263808fa98@gmail.com> References: <2f437218b23a44238ccdcb4e7318da8d@XCH-RCD-003.cisco.com> <5d4c7db8-76cf-8e87-4102-2b5ae9b9817f@gmail.com> <90610692-08a8-1c15-4f79-62263808fa98@gmail.com> From: Hemant Singh Date: Wed, 20 Jul 2016 08:52:15 -0400 Message-ID: Subject: Re: Reference to "3333" value of RFC2464 "IPv6 over Ethernet" To: Alexandre Petrescu Content-Type: multipart/alternative; boundary=001a113c6868cd211b053810ab4b Archived-At: Cc: IPv6 X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.17 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 Jul 2016 12:57:46 -0000 --001a113c6868cd211b053810ab4b Content-Type: text/plain; charset=UTF-8 On Wed, Jul 20, 2016 at 5:49 AM, Alexandre Petrescu < alexandre.petrescu@gmail.com> wrote: > > > >Does IS-IS also make use of 01-00-5E- multicast IANA OUI? (in addition to > that C9). No. For Level-1 adjacencies, the packets are sent to 01-80-C2-00-00-14, and for Level-2 adjacencies, the packets are sent to 01-80-C2-00-00-15 Hemant --001a113c6868cd211b053810ab4b Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On Wed, Jul 20, 2016 at 5:49 AM, Alexandre Petrescu &= lt;alexan= dre.petrescu@gmail.com> wrote:

>Does IS-IS also make use of 01-00-5E- multicast IANA OUI? (i= n addition to that C9).

No.=C2=A0 For Level= -1 adjacencies, the packets are sent to 01-80-C2-00-00-14, and for Level-2 = adjacencies, the packets are sent to 01-80-C2-00-00-15=C2=A0

=
Hemant

--001a113c6868cd211b053810ab4b-- From nobody Wed Jul 20 08:11:57 2016 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A158112D815 for ; Wed, 20 Jul 2016 08:11:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.111 X-Spam-Level: X-Spam-Status: No, score=-4.111 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, T_DKIM_INVALID=0.01] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=fail (1024-bit key) reason="fail (message has been altered)" header.d=jisc365.onmicrosoft.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 vVNOX-D7kVed for ; Wed, 20 Jul 2016 08:11:38 -0700 (PDT) Received: from eu-smtp-delivery-189.mimecast.com (eu-smtp-delivery-189.mimecast.com [207.82.80.189]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DC35212D979 for <6man@ietf.org>; Wed, 20 Jul 2016 08:11:26 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=jisc365.onmicrosoft.com; s=selector1-jisc-ac-uk; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=TZap93wjfWCqpve/L+WzjIZ+HQQ4YCpk+SM20q/moXE=; b=SWL5BTi4opf4kMwA8jghdv2wJbbVhbRqv0XFg8EzAvup094ZDU16epoN8gaNWNBtPH0sbHzGDP8iIv00SNeobyX6i6V/v97OEq+RdFLC55cIcmQV+CqsYpUa7vHGOL4B25sZZ3UCdvrmgU/3t0rTSnTFhNTysILpKRw9Z767Dmg= Received: from EUR03-DB5-obe.outbound.protection.outlook.com (mail-db5eur03lp0086.outbound.protection.outlook.com [94.245.120.86]) (Using TLS) by eu-smtp-1.mimecast.com with ESMTP id uk-mta-58-DaNgdMAhP8mriqxwnaJqfA-1; Wed, 20 Jul 2016 16:11:20 +0100 Received: from AMSPR07MB455.eurprd07.prod.outlook.com (10.242.106.148) by AMSPR07MB456.eurprd07.prod.outlook.com (10.242.106.149) with Microsoft SMTP Server (TLS) id 15.1.534.14; Wed, 20 Jul 2016 15:11:06 +0000 Received: from AMSPR07MB455.eurprd07.prod.outlook.com ([10.242.106.148]) by AMSPR07MB455.eurprd07.prod.outlook.com ([10.242.106.148]) with mapi id 15.01.0539.021; Wed, 20 Jul 2016 15:11:06 +0000 From: Tim Chown To: "Pascal Thubert (pthubert)" Subject: Re: [Roll] impacts of rfc2460bis on draft-ietf-roll-useofrplinfo Thread-Topic: [Roll] impacts of rfc2460bis on draft-ietf-roll-useofrplinfo Thread-Index: AQHR4Scc3IsoEvP+qkam64X61wE+OqAfOpcAgABUa4CAAAmsAIAACPsAgAHOPYA= Date: Wed, 20 Jul 2016 15:11:06 +0000 Message-ID: References: <24554.1468868593@obiwan.sandelman.ca> <799ab640-bed0-22a6-a9df-97f78c3f0bf8@gmail.com> <30725.1468924267@obiwan.sandelman.ca> In-Reply-To: Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-mailer: Apple Mail (2.3124) x-ms-exchange-messagesentrepresentingtype: 1 x-originating-ip: [2001:67c:370:160:7d03:333f:9868:5854] x-ms-office365-filtering-correlation-id: 945269d2-8eec-4492-a1cb-08d3b0b0129c x-microsoft-exchange-diagnostics: 1; AMSPR07MB456; 20:L5bbxqeWUpDrJwLQ8jK+pTm2oq4QdmBwYWq6TMXblWRH7zJsrIVQ44HnTKtzZ8CzE8DuD0kfEogQ/9g/vbyuQyKcSGfvWuvQfugJgYvJ+Fj57Sgp05SSof9nkFw3dcXMabF7CZK3Fjht8hxQUQK+h1ZafhO5dkVQ463rQIKnoRo= x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:AMSPR07MB456; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(120809045254105)(95692535739014); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(601004)(2401047)(5005006)(8121501046)(10201501046)(3002001); SRVR:AMSPR07MB456; BCL:0; PCL:0; RULEID:; SRVR:AMSPR07MB456; x-forefront-prvs: 000947967F x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(6009001)(7916002)(24454002)(199003)(189002)(8936002)(74482002)(3280700002)(586003)(8676002)(81156014)(7846002)(2950100001)(2900100001)(3660700001)(81166006)(76176999)(15975445007)(2906002)(93886004)(102836003)(110136002)(82746002)(6116002)(19580395003)(19580405001)(122556002)(7736002)(305945005)(11100500001)(97736004)(4326007)(77096005)(50226002)(92566002)(106356001)(101416001)(83716003)(105586002)(57306001)(5002640100001)(106116001)(50986999)(230783001)(36756003)(86362001)(87936001)(10400500002)(189998001)(33656002)(68736007)(3826002)(104396002); DIR:OUT; SFP:1101; SCL:1; SRVR:AMSPR07MB456; H:AMSPR07MB455.eurprd07.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; A:1; MX:1; LANG:en; spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-ID: <8290B68AB5D40B4AAA680371A4D3E482@eurprd07.prod.outlook.com> MIME-Version: 1.0 X-OriginatorOrg: jisc.ac.uk X-MS-Exchange-CrossTenant-originalarrivaltime: 20 Jul 2016 15:11:06.0137 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 48f9394d-8a14-4d27-82a6-f35f12361205 X-MS-Exchange-Transport-CrossTenantHeadersStamped: AMSPR07MB456 X-MC-Unique: DaNgdMAhP8mriqxwnaJqfA-1 Content-Type: text/plain; charset=WINDOWS-1252 Content-Transfer-Encoding: quoted-printable Archived-At: Cc: Michael Richardson , Routing Over Low power and Lossy networks , "6man@ietf.org" <6man@ietf.org> X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.17 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 Jul 2016 15:11:40 -0000 Hi Pascal, What RFC6554 (defining the RPL Type 3 RH) appears to say is: 1. If the SRH specifies the complete path from source to destination, the router places the SRH directly in the datagram itself. 2. If the SRH only specifies a subset of the path from source to destination, the router uses IPv6-in-IPv6 tunneling [RFC2473] and places the SRH in the outer IPv6 header. Use of tunneling ensures that the datagram is delivered unmodified and that ICMP errors return to the source of the SRH rather than the source of the original datagram. Which seems to suggest otherwise. Is it case 2 where insertion is happening rather than tunnelling? Case 1 is= at the source, which is compliant with RFC2460. Curious to know... Tim > On 19 Jul 2016, at 12:37, Pascal Thubert (pthubert) = wrote: >=20 > Actually Brian: >=20 > What is really needed here is not for routers but for the end hosts to ig= nore a HbH they are not programmed to recognize.=20 >=20 > The new text says all nodes on the path do. This seems to include the rec= eiver in which case we're good. >=20 > This will not change that most open implementations of RPL (all but a pro= totype implementing this draft) actually do header insertion. >=20 > Regards, >=20 > Pascal >=20 >> Le 19 juil. 2016 =E0 13:14, Brian E Carpenter a =E9crit : >>=20 >>> On 19/07/2016 22:31, Michael Richardson wrote: >>>=20 >>> Brian E Carpenter wrote: >>>>>=20 >>>>> The ROLL document draft-ietf-roll-useofrplinfo documents RFC6553 (a >>>>> Hop-by-Hop critical option) and 6554 (a form of Source Routing Header= , RH3). >>>>> There is work on 6lo to allocate additional 6lowpan IPHC codes such t= hat >>>>> the work in ROLL: >>>>> https://datatracker.ietf.org/doc/draft-ietf-roll-routing-dispatch/ ca= n >>>>> know what kinds of things we need to compress. >>>>>=20 >>>>> A number of things are constrained by the need to always remove the >>>>> RFC6553 Hop-by-Hop option RPI option which had been marked critical: >>>>> i.e. drop packet if you don't understand it. >>>>>=20 >>>>> As a result of the change in RFC2460bis, which says that intermediate= hosts >>>>> will in general not examine hop-by-hop options, but should just ignor= e >>>>> them, we can make certain simplications to the useofrplinfo document. >>>>> (rfc2460bis, section 4, page 8, "NOTE: While...) >>>=20 >>>> You can already do that, because RFC7045 section 2.2 updates RFC2460: >>>> " The IPv6 Hop-by-Hop Options header SHOULD be processed by >>>> intermediate forwarding nodes as described in [RFC2460]." >>>> which of course means that forwarding nodes MAY ignore HbH. >>>=20 >>> It's not what *I* want to do, it's what *I* can expect *others* to do. >>> So 7045 doesn't help me. >>=20 >> Well, it legitimizes a router simply ignoring a HbH header. Isn't that u= seful? >>=20 >>>=20 >>>> 00 - skip over this option and continue processing the header. >>>=20 >>> A type=3D10 option was allocated by RFC6553 >>>=20 >>> I think it was a mistake. >>=20 >> Agreed. >> Brian >>=20 >>> We have discussed changing it as we add >>> compression for 6553, 6554 and IPIP (which would be a flag day anyway). >>> This was considered undesireable, because there was a desire not to lea= k >>> our headers; that the internet would drop our packets if we screwed up. >>>=20 >>> But, it turns out that the internet won't drop out packets, so we might >>> as well optimize the situation so that if we don't need to remove our >>> Hob-by-Hop header, then we don't need extra IPIP headers. >>>=20 >>> -- >>> Michael Richardson , Sandelman Software Works >>> -=3D IPv6 IoT consulting =3D- >>=20 >> _______________________________________________ >> Roll mailing list >> Roll@ietf.org >> https://www.ietf.org/mailman/listinfo/roll >=20 > -------------------------------------------------------------------- > IETF IPv6 working group mailing list > ipv6@ietf.org > Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 > -------------------------------------------------------------------- From nobody Wed Jul 20 08:57:20 2016 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2004E12D7B9; Wed, 20 Jul 2016 08:57:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.188 X-Spam-Level: X-Spam-Status: No, score=-3.188 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-1.287, SPF_PASS=-0.001] 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 1AZCrnReitDb; Wed, 20 Jul 2016 08:57:17 -0700 (PDT) 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 3E00312D661; Wed, 20 Jul 2016 08:57:17 -0700 (PDT) Received: from sandelman.ca (obiwan.sandelman.ca [IPv6:2607:f0b0:f:2::247]) by tuna.sandelman.ca (Postfix) with ESMTP id B2FD8200A5; Wed, 20 Jul 2016 12:06:47 -0400 (EDT) Received: from obiwan.sandelman.ca (localhost [IPv6:::1]) by sandelman.ca (Postfix) with ESMTP id 33729638D1; Wed, 20 Jul 2016 11:57:16 -0400 (EDT) From: Michael Richardson To: Mark Smith Subject: Re: [6man] #20 (rfc4291bis): Site-local In-Reply-To: References: <063.b29004adee61477f53c85e1085499f4e@trac.tools.ietf.org> X-Mailer: MH-E 8.6; nmh 1.6+dev; GNU Emacs 24.5.1 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@ietf.org, draft-ietf-6man-rfc4291bis@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.17 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 Jul 2016 15:57:19 -0000 --=-=-= Content-Type: text/plain Mark Smith wrote: >> #20: Site-local >> >> Remove sections on site local addresses. >> What to do with ULA? > I'd mention something like, > " ULAs are for local network addressing beyond the local link, > providing a local network routed address space that is independent of > a global address space if present (for example, supplied by the > network's current Internet service provider). This decoupling allows > the global address space to be replaced without disrupting new and on > going local network communications using ULA addresses." okay. I like it. Is it worth adding: "rfc6724 provides recommendations as to when to select a ULA address" -- Michael Richardson , Sandelman Software Works -= IPv6 IoT consulting =- --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 iQEVAwUBV4+fWYCLcPvd0N1lAQJppAgAjQQIC4FwMB85lZ9qoB//SC2MSPxHH4Zl sBNfKnRXl0Lm7iNhVHswKDgFBLPBC88QQP/CYN+5If9+gdZQxppDEYbU6zMr6NsS yN0oij+03V9WK05D++2/512eEGOoxo1mjaghV8YD4/fqtE7Y4A+z8PMrgWuDX/PJ xRVN2Axc9acy5S5Y9GQAesAvOWwiOyf6l+9Ic6SKlVd/W++biep3yBltgwFrVrX5 39MkLhFWFsgJs/AJo7c/yiTswkU7ujRatPfXOmxWftdzqMasuYLJNB2tcLIkk3Ik FAOWXkfLaE3KWdCzfTXl489yb80ug+FBV1Ar5jK1vddl5KYiJ1Lw/Q== =TgnQ -----END PGP SIGNATURE----- --=-=-=-- From nobody Wed Jul 20 09:06:43 2016 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A3D1512D87A for ; Wed, 20 Jul 2016 09:06:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.206 X-Spam-Level: X-Spam-Status: No, score=-3.206 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-1.287, SPF_PASS=-0.001, UNPARSEABLE_RELAY=0.001] 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 Y__yfNaPTL8H for ; Wed, 20 Jul 2016 09:06:38 -0700 (PDT) Received: from relais-inet.orange.com (relais-nor34.orange.com [80.12.70.34]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CF3FB12D882 for <6man@ietf.org>; Wed, 20 Jul 2016 09:06:31 -0700 (PDT) Received: from opfednr03.francetelecom.fr (unknown [xx.xx.xx.67]) by opfednr20.francetelecom.fr (ESMTP service) with ESMTP id 8628940390; Wed, 20 Jul 2016 18:06:30 +0200 (CEST) Received: from Exchangemail-eme2.itn.ftgroup (unknown [xx.xx.31.63]) by opfednr03.francetelecom.fr (ESMTP service) with ESMTP id 51EE01A0069; Wed, 20 Jul 2016 18:06:30 +0200 (CEST) Received: from OPEXCLILMA3.corporate.adroot.infra.ftgroup ([fe80::60a9:abc3:86e6:2541]) by OPEXCLILM6E.corporate.adroot.infra.ftgroup ([fe80::f5a7:eab1:c095:d9ec%18]) with mapi id 14.03.0301.000; Wed, 20 Jul 2016 18:06:29 +0200 From: To: "otroan@employees.org" , Brian E Carpenter Subject: RE: proposed text for header injection revision 05 Thread-Topic: proposed text for header injection revision 05 Thread-Index: AQHR4nU6h4vLxeQww0+BVdTDYdzJpqAheyOQ Date: Wed, 20 Jul 2016 16:06:29 +0000 Message-ID: <787AE7BB302AE849A7480A190F8B933008DE9E22@OPEXCLILMA3.corporate.adroot.infra.ftgroup> References: <26582.1468923195@obiwan.sandelman.ca> <2EBFA6F2-00A3-45E1-BE0E-3531AF75726A@employees.org> In-Reply-To: <2EBFA6F2-00A3-45E1-BE0E-3531AF75726A@employees.org> Accept-Language: fr-FR, en-US Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.168.234.1] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Cc: Michael Richardson , "6man@ietf.org" <6man@ietf.org>, "Mark Townsley \(townsley\)" X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.17 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 Jul 2016 16:06:41 -0000 Hi Ole, all,=20 I'm for removing that text as it does not add any recommendation at all.=20 Cheers, Med > -----Message d'origine----- > De=A0: ipv6 [mailto:ipv6-bounces@ietf.org] De la part de > otroan@employees.org > Envoy=E9=A0: mercredi 20 juillet 2016 12:55 > =C0=A0: Brian E Carpenter > Cc=A0: Michael Richardson; 6man@ietf.org; Mark Townsley (townsley) > Objet=A0: Re: proposed text for header injection revision 05 >=20 > >> I clearly prefer and support Mark's suggestion of removing entirely th= e > second paragraph. > >> > >> s. > >> > > > > If we do that I want to see the famous "processed" clarified to make it= s > > intended meaning unambiguous: > > > > With one exception, extension headers are not processed, modified, > inserted > > or deleted by any node along a packet's delivery path, ... >=20 > that text seems to say that in the exception case extension headers can b= e > modified, inserted or deleted. > I'm pretty sure that's not what we want to say. ;-) >=20 > > The second paragraph is a compromise that avoids that clarification. >=20 > yes, I fear that the suggestion of deleting that paragraph will lead us > into the same round of disagreements that led up to that compromise. >=20 > let's assume we cannot find consensus on removing the paragraph, nor can > we find consensus on adding the "processed" clarification. >=20 > I don't mind tweaking the second paragraph if that's required. > currently it says: >=20 > The current approach to allowing a header to be inserted is to > encapsulate the packet using another IPv6 header and including the > additional extension header after the first IPv6 header, for example, > as defined in [RFC2473]. >=20 > Michael proposed: >=20 > An approach an intermediate node/router may take to include an > additional > extension header in an IPv6 packet that it did not originate is to > encapsulate the original packet in a new IPv6 header. As the > source address of this IPv6 packet would then be the router, any > number of additional extension headers may be placed after this new > header, > prior to the original packet. A system making use of this mechanism > will > have to specify how to construct the rest of the IPv6 header, in > particulate, > such a specification needs to carefully consider what the destination > address > will be. >=20 > or simply: >=20 > One approach to inserting Extension Headers by a node other than the > source of the packet > is to encapsulate the packet using a new IPv6 header and including the > additional > Extension Headers as specified in section 3.1 of RFC2473. >=20 > any others? a case of the beer for the winner! ;-) >=20 > Best regards, > Ole From nobody Wed Jul 20 09:24:15 2016 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 91F1D12D7FB; Wed, 20 Jul 2016 09:24:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -15.808 X-Spam-Level: X-Spam-Status: No, score=-15.808 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.287, 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 cASG7MgUgK5O; Wed, 20 Jul 2016 09:24:12 -0700 (PDT) Received: from rcdn-iport-2.cisco.com (rcdn-iport-2.cisco.com [173.37.86.73]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CE47312D821; Wed, 20 Jul 2016 09:24:11 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=5067; q=dns/txt; s=iport; t=1469031851; x=1470241451; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=1MphemYKGSEpW5t37LK8UuxpOkzf3WbsLXBPFocoZQg=; b=JxKAh07bCusW+CgrxNVAE7ILYM8ApTHFKhQFW0/RFeWc2+LfmsKg5XyA KU1eD5KHeK0Vy93QIJL9DzV/zuGuc/+uWUo47/Bl8eKRopZENjRi89Gmw 6XO+gx6PtDloYRZUi53zQU+IVz1bGYLYzM5+kCUdP2eMj5d/DWokUjadF Y=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0AfAgDDpI9X/4cNJK1dDoMxVnysQYwbg?= =?us-ascii?q?XoigkGDNwKBMzgUAQEBAQEBAWUnhFwBAQQBAQFsCwULAgEIGC4hBgslAgQOBYg?= =?us-ascii?q?WAw8IDrkbDYQIAQEBAQEBAQEBAQEBAQEBAQEBAQEBFwWGKoF4CIJNgkOBWSSDL?= =?us-ascii?q?IIvBYgfhiWKLjQBhhKGMYIejzmIJYd6AR42gzg7bgGFYoFEAQEB?= X-IronPort-AV: E=Sophos;i="5.28,395,1464652800"; d="scan'208";a="130870143" Received: from alln-core-2.cisco.com ([173.36.13.135]) by rcdn-iport-2.cisco.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 20 Jul 2016 16:24:10 +0000 Received: from XCH-RCD-005.cisco.com (xch-rcd-005.cisco.com [173.37.102.15]) by alln-core-2.cisco.com (8.14.5/8.14.5) with ESMTP id u6KGOAgL019193 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Wed, 20 Jul 2016 16:24:10 GMT Received: from xch-rcd-001.cisco.com (173.37.102.11) by XCH-RCD-005.cisco.com (173.37.102.15) with Microsoft SMTP Server (TLS) id 15.0.1210.3; Wed, 20 Jul 2016 11:24:10 -0500 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.1210.000; Wed, 20 Jul 2016 11:24:10 -0500 From: "Pascal Thubert (pthubert)" To: Tim Chown Subject: Re: [Roll] impacts of rfc2460bis on draft-ietf-roll-useofrplinfo Thread-Topic: [Roll] impacts of rfc2460bis on draft-ietf-roll-useofrplinfo Thread-Index: AQHR4X59TqNb256fWESru62KIaaKWqAf4iWAgAAJrAD//7UpV4ACIboA///AmR8= Date: Wed, 20 Jul 2016 16:24:10 +0000 Message-ID: <87F2A4F0-7EFA-4898-BEEF-6CCC89670464@cisco.com> References: <24554.1468868593@obiwan.sandelman.ca> <799ab640-bed0-22a6-a9df-97f78c3f0bf8@gmail.com> <30725.1468924267@obiwan.sandelman.ca> , In-Reply-To: Accept-Language: fr-FR, en-US Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Cc: Michael Richardson , Routing Over Low power and Lossy networks , "6man@ietf.org" <6man@ietf.org> X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.17 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 Jul 2016 16:24:13 -0000 Hello Tim: The spec of the case that requires IP in IP (in effect the root relaying a = packet as opposed to sourcing it) was not followed by implementors.=20 People figured that the overhead for encapsulation limited the size of the = network to 2 or 3 hops.=20 This is now somewhat alleviated by the new 6LoRH compression schema. Thus a= first tentative implementation of Michael's draft in openWSN. But the architectural value vs. energy/ bandwidth cost is still hardly conv= incing for the world outside IETF.=20 Regards, Pascal > Le 20 juil. 2016 =E0 17:11, Tim Chown a =E9crit : >=20 > Hi Pascal, >=20 > What RFC6554 (defining the RPL Type 3 RH) appears to say is: >=20 > 1. If the SRH specifies the complete path from source to > destination, the router places the SRH directly in the datagram > itself. >=20 > 2. If the SRH only specifies a subset of the path from source to > destination, the router uses IPv6-in-IPv6 tunneling [RFC2473] and > places the SRH in the outer IPv6 header. Use of tunneling > ensures that the datagram is delivered unmodified and that ICMP > errors return to the source of the SRH rather than the source of > the original datagram. >=20 > Which seems to suggest otherwise. >=20 > Is it case 2 where insertion is happening rather than tunnelling? Case 1 = is at the source, which is compliant with RFC2460. Curious to know... >=20 > Tim >=20 >> On 19 Jul 2016, at 12:37, Pascal Thubert (pthubert) = wrote: >>=20 >> Actually Brian: >>=20 >> What is really needed here is not for routers but for the end hosts to i= gnore a HbH they are not programmed to recognize.=20 >>=20 >> The new text says all nodes on the path do. This seems to include the re= ceiver in which case we're good. >>=20 >> This will not change that most open implementations of RPL (all but a pr= ototype implementing this draft) actually do header insertion. >>=20 >> Regards, >>=20 >> Pascal >>=20 >>>> Le 19 juil. 2016 =E0 13:14, Brian E Carpenter a =E9crit : >>>>=20 >>>> On 19/07/2016 22:31, Michael Richardson wrote: >>>>=20 >>>> Brian E Carpenter wrote: >>>>>>=20 >>>>>> The ROLL document draft-ietf-roll-useofrplinfo documents RFC6553 (a >>>>>> Hop-by-Hop critical option) and 6554 (a form of Source Routing Heade= r, RH3). >>>>>> There is work on 6lo to allocate additional 6lowpan IPHC codes such = that >>>>>> the work in ROLL: >>>>>> https://datatracker.ietf.org/doc/draft-ietf-roll-routing-dispatch/ c= an >>>>>> know what kinds of things we need to compress. >>>>>>=20 >>>>>> A number of things are constrained by the need to always remove the >>>>>> RFC6553 Hop-by-Hop option RPI option which had been marked critical: >>>>>> i.e. drop packet if you don't understand it. >>>>>>=20 >>>>>> As a result of the change in RFC2460bis, which says that intermediat= e hosts >>>>>> will in general not examine hop-by-hop options, but should just igno= re >>>>>> them, we can make certain simplications to the useofrplinfo document= . >>>>>> (rfc2460bis, section 4, page 8, "NOTE: While...) >>>>=20 >>>>> You can already do that, because RFC7045 section 2.2 updates RFC2460: >>>>> " The IPv6 Hop-by-Hop Options header SHOULD be processed by >>>>> intermediate forwarding nodes as described in [RFC2460]." >>>>> which of course means that forwarding nodes MAY ignore HbH. >>>>=20 >>>> It's not what *I* want to do, it's what *I* can expect *others* to do. >>>> So 7045 doesn't help me. >>>=20 >>> Well, it legitimizes a router simply ignoring a HbH header. Isn't that = useful? >>>=20 >>>>=20 >>>>> 00 - skip over this option and continue processing the header. >>>>=20 >>>> A type=3D10 option was allocated by RFC6553 >>>>=20 >>>> I think it was a mistake. >>>=20 >>> Agreed. >>> Brian >>>=20 >>>> We have discussed changing it as we add >>>> compression for 6553, 6554 and IPIP (which would be a flag day anyway)= . >>>> This was considered undesireable, because there was a desire not to le= ak >>>> our headers; that the internet would drop our packets if we screwed up= . >>>>=20 >>>> But, it turns out that the internet won't drop out packets, so we migh= t >>>> as well optimize the situation so that if we don't need to remove our >>>> Hob-by-Hop header, then we don't need extra IPIP headers. >>>>=20 >>>> -- >>>> Michael Richardson , Sandelman Software Works >>>> -=3D IPv6 IoT consulting =3D- >>>=20 >>> _______________________________________________ >>> Roll mailing list >>> Roll@ietf.org >>> https://www.ietf.org/mailman/listinfo/roll >>=20 >> -------------------------------------------------------------------- >> IETF IPv6 working group mailing list >> ipv6@ietf.org >> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 >> -------------------------------------------------------------------- >=20 From nobody Wed Jul 20 10:05:07 2016 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3921012D169 for ; Wed, 20 Jul 2016 10:05:06 -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 FjmJctUD2-AZ for ; Wed, 20 Jul 2016 10:05:04 -0700 (PDT) Received: from mail-wm0-x233.google.com (mail-wm0-x233.google.com [IPv6:2a00:1450:400c: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 88C3012D73C for ; Wed, 20 Jul 2016 10:05:03 -0700 (PDT) Received: by mail-wm0-x233.google.com with SMTP id q128so64250249wma.1 for ; Wed, 20 Jul 2016 10:05:03 -0700 (PDT) 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-transfer-encoding; bh=0m4JiWLTZxgsPaF7d0DfZ6cpwOrurwFf+PL+qWpBTzQ=; b=UDsMguVMqr+09/YgWbUAxqx16x+ozneVV9yaJViSJuy7dorkIOF97X7K7dRx8bx/Uu oN8nTRlJEUyXCPAqN1PjWcgGMwlEZBbIj+7ItiqcZ1VuJ/BAqrvqfmbh5YSPQkqsgyJm SlS6mx298zC9wzo2h+AKwEPFBYwQk9nZoZl2DuitDLnpHShvREwjRogYX0nc7lYWf6xy L1h22C2qhQD4Eh9UyP/koA0Me8Zo/TJoaVeiIxqZRsBUAntAuRtMrjA+Oh6Xg9YZL2+Y KXmpD7p8ucOjPR1KlPIZc7qHARfISg90K/CdO8+Bf+wPC3fPalmLBNehWi6mhBd7Sf2Q ugDA== 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-transfer-encoding; bh=0m4JiWLTZxgsPaF7d0DfZ6cpwOrurwFf+PL+qWpBTzQ=; b=VYiUcX6OVJT9GMgFwXMX95WkA9ZZQ7ejsadcOcLZE4SDC3DKIhYW/hrBE1GJb9gCj9 y/9NuhYT2N5XPHZ/u4ko0nNhA0lP2jHLVF6fxFlVJ5QPNXBO5LiQW93rD+jB2bZYXmBK SDL3iLLjOkbIse861csEvyTt6ap1sHX/529NRLUotcWNpmB+MNQ3AkXaFNZuvLD7PtYc QSAQ9ySf3vq+fpADAlr1tQiNgjtf97YFPX4XxTq8JbJ1UDs6SR3scpFNI7PkZP5o5/3+ jQLDnhhExtDBo4eFCB74mIkE0K2yxT1T5tRNcMB2exHCdJT5Wvhs0BXJ9iycsA/T/m95 tmzw== X-Gm-Message-State: ALyK8tLq8bTBdxC6vrdHuxZ4ZfuDMzlrwP10jORmjdfOBFRl/YGss1EoM6J+trDZC5MiTg== X-Received: by 10.194.100.134 with SMTP id ey6mr2387890wjb.170.1469034301900; Wed, 20 Jul 2016 10:05:01 -0700 (PDT) Received: from ?IPv6:2001:67c:370:176:28cc:dc4c:9703:6781? ([2001:67c:370:176:28cc:dc4c:9703:6781]) by smtp.gmail.com with ESMTPSA id q23sm6015268wme.17.2016.07.20.10.05.00 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 20 Jul 2016 10:05:01 -0700 (PDT) Subject: Re: [6man] #20 (rfc4291bis): Site-local To: ipv6@ietf.org References: <063.b29004adee61477f53c85e1085499f4e@trac.tools.ietf.org> <18674.1469030236@obiwan.sandelman.ca> From: Brian E Carpenter Organization: University of Auckland Message-ID: Date: Thu, 21 Jul 2016 05:05:06 +1200 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.2.0 MIME-Version: 1.0 In-Reply-To: <18674.1469030236@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.17 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 Jul 2016 17:05:06 -0000 On 21/07/2016 03:57, Michael Richardson wrote: > > Mark Smith wrote: > >> #20: Site-local > >> > >> Remove sections on site local addresses. > >> What to do with ULA? > > > I'd mention something like, > > > " ULAs are for local network addressing beyond the local link, > > providing a local network routed address space that is independent of > > a global address space if present (for example, supplied by the > > network's current Internet service provider). This decoupling allows > > the global address space to be replaced without disrupting new and on > > going local network communications using ULA addresses." > > okay. I like it. > > Is it worth adding: "rfc6724 provides recommendations as to when to select a > ULA address" Please no. None of this is addressing architecture; actually it's about what gets announced in BGP4. It doesn't belong here. Brian From nobody Wed Jul 20 10:17:16 2016 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 12C5E12D83B; Wed, 20 Jul 2016 10:17:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.188 X-Spam-Level: X-Spam-Status: No, score=-3.188 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-1.287, SPF_PASS=-0.001] 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 iXhCB47HDxD6; Wed, 20 Jul 2016 10:17:13 -0700 (PDT) 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 8BC7712D7F9; Wed, 20 Jul 2016 10:17:12 -0700 (PDT) Received: from sandelman.ca (obiwan.sandelman.ca [209.87.249.21]) by tuna.sandelman.ca (Postfix) with ESMTP id 66893200A5; Wed, 20 Jul 2016 13:26:43 -0400 (EDT) Received: from obiwan.sandelman.ca (localhost [IPv6:::1]) by sandelman.ca (Postfix) with ESMTP id AB823638D1; Wed, 20 Jul 2016 13:17:11 -0400 (EDT) From: Michael Richardson To: roll@ietf.org Subject: Re: impacts of rfc2460bis on draft-ietf-roll-useofrplinfo In-Reply-To: References: <24554.1468868593@obiwan.sandelman.ca> <799ab640-bed0-22a6-a9df-97f78c3f0bf8@gmail.com> <30725.1468924267@obiwan.sandelman.ca> X-Mailer: MH-E 8.6; nmh 1.6+dev; GNU Emacs 24.5.1 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@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.17 Precedence: list Reply-To: roll@ietf.org List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Jul 2016 17:17:15 -0000 --=-=-= Content-Type: text/plain Brian E Carpenter wrote: >> > intermediate forwarding nodes as described in [RFC2460]." >> > which of course means that forwarding nodes MAY ignore HbH. >> >> It's not what *I* want to do, it's what *I* can expect *others* to do. >> So 7045 doesn't help me. > Well, it legitimizes a router simply ignoring a HbH header. Isn't that > useful? It doesn't tell me what behaviour I can expect, just what I'm allowed to do myself. In RPL networks, we don't want to ignore that HbH header, we simply want to avoid having to go through conniptions to remove it. today, at ROLL, we went through some slides to explain the improvements that 2460bis "Note" does for us. Here are the link to the slides: The ROLL WG meeting we seemed to have consensus in the room to wait for rfc2460bis to progress, and to have a normative reference to it in useofrplinfo. I have merged the changes that were shown in the links I posted before: https://goo.gl/cxWkP5 this is a reference to an RFC diff between: draft-ietf-roll-useofrplinfo-06.txt and draft-richardson-roll-useofrplinfo-2460bis-00.txt I have merged the changes into draft-ietf-roll-useofrplinfo-07, so you can now see the changes directly in the datatracker. -- Michael Richardson , Sandelman Software Works -= IPv6 IoT consulting =- --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 iQEVAwUBV4+yE4CLcPvd0N1lAQKaWggAg43wNScct9yBk9ree9dobIezBOIFVMQn BfklpkaPF2vdC46SvdN5YGeFyGAm9eDpEv/KCr72mN4a+6M/oBPv541+xJ2wqMYg tZ3sUE/u1zzv1MZa86XUUeT70LiqJMviHtarbZIq7ouA3mZuhxiDohC0fcfuzWMn s4oPsl7IJCYqfE08NBvubBcYc5T/NzFBC8IjLgXU6NHgsvo9yOoY22f7zIJln/J4 K91OKDPk3sIFVwAxZ5YIbAsry1K7SBXfo9fPg9yX7qNgnqmiFWATW9yqCVZYxeZe JnfxuXOgxOy09+1qRZMPrqVMnwXlJIrFr8fgh0t04kbX3xKTJh+cJA== =wSQ+ -----END PGP SIGNATURE----- --=-=-=-- From nobody Wed Jul 20 10:22:58 2016 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5E81912B055 for ; Wed, 20 Jul 2016 10:22:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.333 X-Spam-Level: X-Spam-Status: No, score=-5.333 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_ADSP_CUSTOM_MED=0.001, FREEMAIL_FROM=0.001, NML_ADSP_CUSTOM_MED=0.9, RCVD_IN_DNSWL_HI=-5, SPF_SOFTFAIL=0.665] 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 5H2PRrRQMChU for ; Wed, 20 Jul 2016 10:22:54 -0700 (PDT) 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 D95AB12B060 for ; Wed, 20 Jul 2016 10:22:53 -0700 (PDT) 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 u6KHMpLj007115; Wed, 20 Jul 2016 19:22:51 +0200 Received: from pisaure.intra.cea.fr (localhost [127.0.0.1]) by localhost (Postfix) with SMTP id 5B8F4206379; Wed, 20 Jul 2016 19:22:51 +0200 (CEST) Received: from muguet2.intra.cea.fr (muguet2.intra.cea.fr [132.166.192.7]) by pisaure.intra.cea.fr (Postfix) with ESMTP id 4BE53201293; Wed, 20 Jul 2016 19:22:51 +0200 (CEST) Received: from [132.166.84.60] ([132.166.84.60]) by muguet2.intra.cea.fr (8.15.2/8.15.2/CEAnet-Intranet-out-1.4) with ESMTP id u6KHMpKb005606; Wed, 20 Jul 2016 19:22:51 +0200 Subject: Re: 2464 - link-local multicast address mapping To: Stig Venaas References: <26148.1468914385@obiwan.sandelman.ca> <1ac389c5-22ca-2283-d09c-a26bea9c7a75@gmail.com> From: Alexandre Petrescu Message-ID: <5c775ad5-3e88-5d0e-f221-d36c5d4d5b38@gmail.com> Date: Wed, 20 Jul 2016 19:22:49 +0200 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.2.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Archived-At: Cc: 6man WG X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.17 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 Jul 2016 17:22:56 -0000 Le 20/07/2016 à 14:24, Stig Venaas a écrit : > Hi > > On Wed, Jul 20, 2016 at 2:40 AM, Alexandre Petrescu > wrote: >> >> >> Le 20/07/2016 à 00:01, Mark Smith a écrit : >>> >>> On 20 Jul 2016 2:12 AM, "Alexandre Petrescu" >>> >> > wrote: >>>> >>>> >>>> Hi, >>>> >>>> Currently the RFC2464 multicast address mapping says: >>>> >>>>> An IPv6 packet with a multicast destination address DST, >>>>> consisting of the sixteen octets DST[1] through DST[16], is >>>>> transmitted to the Ethernet multicast address whose first >>>>> two octets are the value 3333 hexadecimal and whose last four >>>>> octets are the last four octets of DST. >>>> >>>> >>>> >>>> I think this mapping should happen only for link-scoped IPv6 > > Why? Both for IPv4 and IPv6 you need to have some destination > multicast MAC address for any IP/IPv6 multicast packet, regardless > of scope. It woudlnt make sense to map a global-scope IPv6 multicast address into a - by definition local - Ethernet multicast address. There is not enough place in there. As such reverse mapping would be impossible. >>> destination addresses, not other scopes. >>>> >>>> >>>> I.e. the last four octets of a _link-local_ IPv6 address >>>> should get >>> >>> mapped into that MAC address (ff02::XXXX:XXXX -> >>> 33-33-XX-XX-XX-XX); multicast addresses of other scopes than ff02 >>> should not get mapped. >>>> >>>> >>> >>> I think you're assuming that there are no other nodes on the >>> link are members of the > link-local scope group, or that there >>> is no more than one multicast router on the link. >> >> >> Yes, I do assume so. > > It's fairly common to have multiple multicast routers on the link, > and there can definitely be multiple members of a link-local group > (or any group) on the link. Yes certainly there can be multiple IP multicast routers on a link. But I dont see how that supports mapping a global multicast address into an Ethernet address. >>> Multicast address scopes are only indicating boundary of the >>> multicast forwarding domain, not where multicast group members >>> are or are not. >> >> >> But an Ethernet 33-33- scope can only be a link scope. A reverse > > Why? Because the whole world is not (and can not) be Ethernet - there are other link types as well. As such its scope can only be local. > >> mapping from an Ethernet scope back to a > link-local scope would >> make no sense. >> >> (I also assume mapping to be bidirectional). > > What do you mean by bidirectional? As you wrote, you cannot do a > reverse mapping. Bidirectional - map from IP address to MAC address, and vice-versa. 'Mapping' suggests me ability to translate and reversely too. Or maybe this RFC2464 'mapping' means to translate into only one direction? (translate an IP to MAC but not vice-versa) Alex > > Stig > >> Alex >> >>> >>> Regards, Mark. >>> >>>> Alex >>>> >>>> -------------------------------------------------------------------- >>>> >>>> >> >>>> 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 Jul 20 10:24:56 2016 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2103B12D0D8 for ; Wed, 20 Jul 2016 10:24:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.333 X-Spam-Level: X-Spam-Status: No, score=-5.333 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_ADSP_CUSTOM_MED=0.001, FREEMAIL_FROM=0.001, NML_ADSP_CUSTOM_MED=0.9, RCVD_IN_DNSWL_HI=-5, SPF_SOFTFAIL=0.665] 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 gJd3uBYOoK-7 for ; Wed, 20 Jul 2016 10:24:52 -0700 (PDT) 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 779EF12D08E for ; Wed, 20 Jul 2016 10:24:52 -0700 (PDT) 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 u6KHOmS5007925; Wed, 20 Jul 2016 19:24:48 +0200 Received: from pisaure.intra.cea.fr (localhost [127.0.0.1]) by localhost (Postfix) with SMTP id 6ABA7206BB5; Wed, 20 Jul 2016 19:24:48 +0200 (CEST) Received: from muguet2.intra.cea.fr (muguet2.intra.cea.fr [132.166.192.7]) by pisaure.intra.cea.fr (Postfix) with ESMTP id 4F9F8206E89; Wed, 20 Jul 2016 19:24:48 +0200 (CEST) Received: from [132.166.84.60] ([132.166.84.60]) by muguet2.intra.cea.fr (8.15.2/8.15.2/CEAnet-Intranet-out-1.4) with ESMTP id u6KHOl9P006796; Wed, 20 Jul 2016 19:24:47 +0200 Subject: Re: Reference to "3333" value of RFC2464 "IPv6 over Ethernet" To: Hemant Singh References: <2f437218b23a44238ccdcb4e7318da8d@XCH-RCD-003.cisco.com> <5d4c7db8-76cf-8e87-4102-2b5ae9b9817f@gmail.com> <90610692-08a8-1c15-4f79-62263808fa98@gmail.com> From: Alexandre Petrescu Message-ID: <6bd94ded-6446-ddac-3e7e-3be25ec742db@gmail.com> Date: Wed, 20 Jul 2016 19:24:47 +0200 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.2.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 X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.17 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 Jul 2016 17:24:54 -0000 Can IS-IS run on IPv6 and if so which MAC multicast address? Alex Le 20/07/2016 à 14:52, Hemant Singh a écrit : > > > On Wed, Jul 20, 2016 at 5:49 AM, Alexandre Petrescu > > wrote: > > > >Does IS-IS also make use of 01-00-5E- multicast IANA OUI? (in > addition to that C9). > > > No. For Level-1 adjacencies, the packets are sent to 01-80-C2-00-00-14, > and for Level-2 adjacencies, the packets are sent to 01-80-C2-00-00-15 > > Hemant > From nobody Wed Jul 20 10:25:04 2016 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6D14C12D77F; Wed, 20 Jul 2016 10:24:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.188 X-Spam-Level: X-Spam-Status: No, score=-3.188 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-1.287, SPF_PASS=-0.001] 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 a4FlMJbmgerX; Wed, 20 Jul 2016 10:24:56 -0700 (PDT) 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 B6DF812D88E; Wed, 20 Jul 2016 10:24:56 -0700 (PDT) Received: from sandelman.ca (obiwan.sandelman.ca [IPv6:2607:f0b0:f:2::247]) by tuna.sandelman.ca (Postfix) with ESMTP id 8BC47200A5; Wed, 20 Jul 2016 13:34:27 -0400 (EDT) Received: from obiwan.sandelman.ca (localhost [IPv6:::1]) by sandelman.ca (Postfix) with ESMTP id D65EB638D1; Wed, 20 Jul 2016 13:24:55 -0400 (EDT) From: Michael Richardson To: roll@ietf.org, otroan@employees.org Subject: Re: 2460bis - section 4.2 -- hop-by-hop option writeup. In-Reply-To: References: <26148.1468914385@obiwan.sandelman.ca> X-Mailer: MH-E 8.6; nmh 1.6+dev; GNU Emacs 24.5.1 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@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.17 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 Jul 2016 17:24:58 -0000 --=-=-= Content-Type: text/plain otroan@employees.org wrote: > I don't think we can do this in 2460bis. The option flags are also used > for the Destination options header. > There is anyway legacy implementations, meaning that new options cannot > reuse the space. Ah, I hadn't realized this. > For your particular problem, it sounds like you don't really want a > mandatory option, why not reclassify the RPL option instead of trying > to make 2460 fit the corner you've been painted into :-)). Okay, so I want to re-open this possibility as part of the flag day caused by deploying of 6LoRH. Specifically, about updating RFC6553 such that the Option code changes from 0x63 to 0x23. I think that this should be tied to deployment of 6LoRH. -- Michael Richardson , Sandelman Software Works -= IPv6 IoT consulting =- --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 iQEVAwUBV4+z4oCLcPvd0N1lAQJZLgf+KbX5A4sOiIZ/b83AoEN/ElwfIE48teSf Qr9YUmJWnBaDTpSAm9eq/WX4jIyfF92NCDTzdFV11to+D8Yi/EjQlTwdVLFgzOH8 oqoRe5LjHpp9qNP6tsAMVylEpBoo95w9y3n6C/0kTk0cSokUQJP8PSGgqT0ejgYu jh/4tXo/q4iYRBGALGAnoHyANwzof1CXN1TeTZmmYQCJ7/XbwoNtTSGf5VChTb/A eTAqfq85F5Hru4LBz6jdWPlQvjL3huHbjcHBBC4ZQoqN0EZcTUNHlIaWi2GKVqfi zoq4ojKewbzCnibWrwOwbhk8ISdZbHgObvqctppCuk7/oG3jQbkMZw== =6bMa -----END PGP SIGNATURE----- --=-=-=-- From nobody Wed Jul 20 10:30:27 2016 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EB49112D8F2 for ; Wed, 20 Jul 2016 10:30:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.332 X-Spam-Level: X-Spam-Status: No, score=-5.332 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_ADSP_CUSTOM_MED=0.001, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, NML_ADSP_CUSTOM_MED=0.9, RCVD_IN_DNSWL_HI=-5, SPF_SOFTFAIL=0.665] 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 DCujDRzewadR for ; Wed, 20 Jul 2016 10:30:23 -0700 (PDT) Received: from oxalide-out.extra.cea.fr (oxalide-out.extra.cea.fr [132.168.224.8]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8A33912D0D8 for ; Wed, 20 Jul 2016 10:30:22 -0700 (PDT) Received: from pisaure.intra.cea.fr (pisaure.intra.cea.fr [132.166.88.21]) by oxalide.extra.cea.fr (8.15.2/8.15.2/CEAnet-Internet-out-2.4) with ESMTP id u6KHUKp0020772 for ; Wed, 20 Jul 2016 19:30:20 +0200 Received: from pisaure.intra.cea.fr (localhost [127.0.0.1]) by localhost (Postfix) with SMTP id 592B0206E2C for ; Wed, 20 Jul 2016 19:30:20 +0200 (CEST) Received: from muguet2.intra.cea.fr (muguet2.intra.cea.fr [132.166.192.7]) by pisaure.intra.cea.fr (Postfix) with ESMTP id 4F317206E24 for ; Wed, 20 Jul 2016 19:30:20 +0200 (CEST) Received: from [132.166.84.60] ([132.166.84.60]) by muguet2.intra.cea.fr (8.15.2/8.15.2/CEAnet-Intranet-out-1.4) with ESMTP id u6KHUJh9010799 for ; Wed, 20 Jul 2016 19:30:20 +0200 To: IPv6 From: Alexandre Petrescu Subject: Re: Reference to "3333" value of RFC2464 "IPv6 over Ethernet" Message-ID: <34d7ea88-e5c3-af83-e05f-2d29c81a8b04@gmail.com> Date: Wed, 20 Jul 2016 19:30:19 +0200 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.2.0 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="------------D34035F745ADF26E687CEDA4" Archived-At: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.17 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 Jul 2016 17:30:25 -0000 This is a multi-part message in MIME format. --------------D34035F745ADF26E687CEDA4 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Let me start a separate thread to continue this discussion: Can IS-IS run on IPv6 and if so which MAC multicast address? Alex Le 20/07/2016 à 14:52, Hemant Singh a écrit : > > > On Wed, Jul 20, 2016 at 5:49 AM, Alexandre Petrescu > > > wrote: > > > >Does IS-IS also make use of 01-00-5E- multicast IANA OUI? (in > addition to that C9). > > > No. For Level-1 adjacencies, the packets are sent to 01-80-C2-00-00-14, > and for Level-2 adjacencies, the packets are sent to 01-80-C2-00-00-15 > > Hemant > --------------D34035F745ADF26E687CEDA4 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit

Let me start a separate thread to continue this discussion:

Can IS-IS run on IPv6 and if so which MAC multicast address?

Alex


Le 20/07/2016 à 14:52, Hemant Singh a écrit :


On Wed, Jul 20, 2016 at 5:49 AM, Alexandre Petrescu
<alexandre.petrescu@gmail.com <mailto:alexandre.petrescu@gmail.com>> wrote:


    >Does IS-IS also make use of 01-00-5E- multicast IANA OUI? (in
    addition to that C9).


No.  For Level-1 adjacencies, the packets are sent to 01-80-C2-00-00-14,
and for Level-2 adjacencies, the packets are sent to 01-80-C2-00-00-15

Hemant

--------------D34035F745ADF26E687CEDA4-- From nobody Wed Jul 20 10:31:22 2016 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6F4CC12D904 for ; Wed, 20 Jul 2016 10:31:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.352 X-Spam-Level: X-Spam-Status: No, score=-5.352 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_ADSP_CUSTOM_MED=0.001, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, NML_ADSP_CUSTOM_MED=0.9, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_SOFTFAIL=0.665] 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 1KHJLBHopHQT for ; Wed, 20 Jul 2016 10:31:18 -0700 (PDT) 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 146C312D91B for ; Wed, 20 Jul 2016 10:31:15 -0700 (PDT) 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 u6KHVEhp002199 for ; Wed, 20 Jul 2016 19:31:14 +0200 Received: from pisaure.intra.cea.fr (localhost [127.0.0.1]) by localhost (Postfix) with SMTP id 130DA206E2B for ; Wed, 20 Jul 2016 19:31:14 +0200 (CEST) Received: from muguet2.intra.cea.fr (muguet2.intra.cea.fr [132.166.192.7]) by pisaure.intra.cea.fr (Postfix) with ESMTP id 08434206379 for ; Wed, 20 Jul 2016 19:31:14 +0200 (CEST) Received: from [132.166.84.60] ([132.166.84.60]) by muguet2.intra.cea.fr (8.15.2/8.15.2/CEAnet-Intranet-out-1.4) with ESMTP id u6KHVDsR011390 for ; Wed, 20 Jul 2016 19:31:13 +0200 To: IPv6 From: Alexandre Petrescu Subject: Re: 2464 - link-local multicast address mapping Message-ID: <183c2fe8-987d-dfb6-f70d-7f6ad6eba3ef@gmail.com> Date: Wed, 20 Jul 2016 19:31:13 +0200 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.2.0 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="------------F65A186B2254EE2177A47F57" Archived-At: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.17 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 Jul 2016 17:31:20 -0000 This is a multi-part message in MIME format. --------------F65A186B2254EE2177A47F57 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit [let me start a separate thread here] Le 20/07/2016 à 14:24, Stig Venaas a écrit : > Hi > > On Wed, Jul 20, 2016 at 2:40 AM, Alexandre Petrescu > wrote: >> >> >> Le 20/07/2016 à 00:01, Mark Smith a écrit : >>> >>> On 20 Jul 2016 2:12 AM, "Alexandre Petrescu" >>> >> > wrote: >>>> >>>> >>>> Hi, >>>> >>>> Currently the RFC2464 multicast address mapping says: >>>> >>>>> An IPv6 packet with a multicast destination address DST, >>>>> consisting of the sixteen octets DST[1] through DST[16], is >>>>> transmitted to the Ethernet multicast address whose first >>>>> two octets are the value 3333 hexadecimal and whose last four >>>>> octets are the last four octets of DST. >>>> >>>> >>>> >>>> I think this mapping should happen only for link-scoped IPv6 > > Why? Both for IPv4 and IPv6 you need to have some destination > multicast MAC address for any IP/IPv6 multicast packet, regardless > of scope. It woudlnt make sense to map a global-scope IPv6 multicast address into a - by definition local - Ethernet multicast address. There is not enough place in there. As such reverse mapping would be impossible. >>> destination addresses, not other scopes. >>>> >>>> >>>> I.e. the last four octets of a _link-local_ IPv6 address >>>> should get >>> >>> mapped into that MAC address (ff02::XXXX:XXXX -> >>> 33-33-XX-XX-XX-XX); multicast addresses of other scopes than ff02 >>> should not get mapped. >>>> >>>> >>> >>> I think you're assuming that there are no other nodes on the >>> link are members of the > link-local scope group, or that there >>> is no more than one multicast router on the link. >> >> >> Yes, I do assume so. > > It's fairly common to have multiple multicast routers on the link, > and there can definitely be multiple members of a link-local group > (or any group) on the link. Yes certainly there can be multiple IP multicast routers on a link. But I dont see how that supports mapping a global multicast address into an Ethernet address. >>> Multicast address scopes are only indicating boundary of the >>> multicast forwarding domain, not where multicast group members >>> are or are not. >> >> >> But an Ethernet 33-33- scope can only be a link scope. A reverse > > Why? Because the whole world is not (and can not) be Ethernet - there are other link types as well. As such its scope can only be local. > >> mapping from an Ethernet scope back to a > link-local scope would >> make no sense. >> >> (I also assume mapping to be bidirectional). > > What do you mean by bidirectional? As you wrote, you cannot do a > reverse mapping. Bidirectional - map from IP address to MAC address, and vice-versa. 'Mapping' suggests me ability to translate and reversely too. Or maybe this RFC2464 'mapping' means to translate into only one direction? (translate an IP to MAC but not vice-versa) Alex > > Stig > >> Alex >> >>> >>> Regards, Mark. >>> >>>> Alex >>>> >>>> -------------------------------------------------------------------- >>>> >>>> >> >>>> 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 -------------------------------------------------------------------- --------------F65A186B2254EE2177A47F57 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit

[let me start a separate thread here]

Le 20/07/2016 à 14:24, Stig Venaas a écrit :
Hi

On Wed, Jul 20, 2016 at 2:40 AM, Alexandre Petrescu
<alexandre.petrescu@gmail.com> wrote:


Le 20/07/2016 à 00:01, Mark Smith a écrit :

On 20 Jul 2016 2:12 AM, "Alexandre Petrescu"
<alexandre.petrescu@gmail.com
<mailto:alexandre.petrescu@gmail.com>> wrote:


Hi,

Currently the RFC2464 multicast address mapping says:

An IPv6 packet with a multicast destination address DST,
consisting of the sixteen octets DST[1] through DST[16], is
transmitted to the Ethernet multicast address whose first
two octets are the value 3333 hexadecimal and whose last four
octets are the last four octets of DST.



I think this mapping should happen only for link-scoped IPv6

Why? Both for IPv4 and IPv6 you need to have some destination
multicast MAC address for any IP/IPv6 multicast packet, regardless
of scope.

It woudlnt make sense to map a global-scope IPv6 multicast address into
a - by definition local - Ethernet multicast address.

There is not enough place in there.  As such reverse mapping would be
impossible.

destination addresses, not other scopes.


I.e. the last four octets of a _link-local_ IPv6 address
should get

mapped into that MAC address (ff02::XXXX:XXXX ->
33-33-XX-XX-XX-XX); multicast addresses of other scopes than ff02
should not get mapped.



I think you're assuming that there are no other nodes on the
link are members of the > link-local scope group, or that there
is no more than one multicast router on the link.


Yes, I do assume so.

It's fairly common to have multiple multicast routers on the link,
and there can definitely be multiple members of a link-local group
(or any group) on the link.

Yes certainly there can be multiple IP multicast routers on a link.  But
I dont see how that supports mapping a global multicast address into an
Ethernet address.

Multicast address scopes are only indicating boundary of the
multicast forwarding domain, not where multicast group members
are or are not.


But an Ethernet 33-33- scope can only be a link scope.  A reverse

Why?

Because the whole world is not (and can not) be Ethernet - there are
other link types as well.  As such its scope can only be local.


mapping from an Ethernet scope back to a > link-local scope would
make no sense.

(I also assume mapping to be bidirectional).

What do you mean by bidirectional? As you wrote, you cannot do a
reverse mapping.

Bidirectional - map from IP address to MAC address, and vice-versa.
'Mapping' suggests me ability to translate and reversely too.

Or maybe this RFC2464 'mapping' means to translate into only one
direction?  (translate an IP to MAC but not vice-versa)

Alex


Stig

Alex


Regards, Mark.

Alex

--------------------------------------------------------------------




IETF IPv6 working group mailing list

ipv6@ietf.org <mailto:ipv6@ietf.org> Administrative
Requests:https://www.ietf.org/mailman/listinfo/ipv6

<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
--------------------------------------------------------------------
--------------F65A186B2254EE2177A47F57-- From nobody Wed Jul 20 10:47:22 2016 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4DF7A12D94D for ; Wed, 20 Jul 2016 10:47:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.465 X-Spam-Level: X-Spam-Status: No, score=-2.465 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, MIME_HTML_ONLY=0.723, RP_MATCHES_RCVD=-1.287, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] 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 JXCV7DYdAh7C for ; Wed, 20 Jul 2016 10:47:20 -0700 (PDT) Received: from linfre.de (linfre.de [83.151.26.85]) (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 9C81E12D935 for ; Wed, 20 Jul 2016 10:47:19 -0700 (PDT) Received: from [127.0.0.1] (109.47.0.97) by linfreserv (Axigen) with (ECDHE-RSA-AES256-SHA encrypted) ESMTPSA id 064036; Wed, 20 Jul 2016 19:47:08 +0200 Content-Type: text/html; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable X-Mailer: BlackBerry Email (10.3.2.2876) Message-ID: <20160720174708.5996626.43795.64328@linfre.de> Date: Wed, 20 Jul 2016 19:47:08 +0200 Subject: AW: Reference to "3333" value of RFC2464 "IPv6 over Ethernet" From: Karsten Thomann In-Reply-To: <34d7ea88-e5c3-af83-e05f-2d29c81a8b04@gmail.com> References: <34d7ea88-e5c3-af83-e05f-2d29c81a8b04@gmail.com> To: Alexandre Petrescu , IPv6 X-AXIGEN-DK-Result: No records DomainKey-Status: no signature X-AxigenSpam-Level: 7 Archived-At: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.17 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 Jul 2016 17:47:21 -0000 = =
Hi Alex, 

IS-IS runs directly on ethernet over clns (iso), as it isn't an = IP protocol, even if it can route ipv4 and ipv6.

Kars= ten
=

= = =
Gesende= t von meinem BlackBerry
= =
Von: Alexandre Petres= cu
Gesendet: Mittwoch, 20. Juli 2016 19:30
An= : IPv6
Betreff: Re: Reference to "3333" value of RFC24= 64 "IPv6 over Ethernet"

=20 =20 =20

Let me start a separate thread to continue this discussion:

Can IS-IS run on IPv6 and if so which MAC multicast address?

Alex


Le 20/07/2016 =C3=A0 14:52, Hemant Singh a =C3=A9crit :


On Wed, Jul 20, 2016 at 5:49 AM, Alexandre Petrescu
<alexandre.petrescu@gmail.com <mailto:alexandre.petrescu@gmail.com>> wrote:


    >Does IS-IS also make use of 01-00-5E- multic= ast IANA OUI? (in
    addition to that C9).


No.  For Level-1 adjacencies, the packets are sent to 01-80-C2-00-00-14,
and for Level-2 adjacencies, the packets are sent to 01-80-C2-00-00-15

Hemant

=20
From nobody Wed Jul 20 10:49:09 2016 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AD03512D954 for ; Wed, 20 Jul 2016 10:49:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.333 X-Spam-Level: X-Spam-Status: No, score=-5.333 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_ADSP_CUSTOM_MED=0.001, FREEMAIL_FROM=0.001, NML_ADSP_CUSTOM_MED=0.9, RCVD_IN_DNSWL_HI=-5, SPF_SOFTFAIL=0.665] 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 FQA73CQxNS62 for ; Wed, 20 Jul 2016 10:49:06 -0700 (PDT) Received: from oxalide-out.extra.cea.fr (oxalide-out.extra.cea.fr [132.168.224.8]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 79D1412D13A for ; Wed, 20 Jul 2016 10:49:05 -0700 (PDT) Received: from pisaure.intra.cea.fr (pisaure.intra.cea.fr [132.166.88.21]) by oxalide.extra.cea.fr (8.15.2/8.15.2/CEAnet-Internet-out-2.4) with ESMTP id u6KHn30L027751; Wed, 20 Jul 2016 19:49:03 +0200 Received: from pisaure.intra.cea.fr (localhost [127.0.0.1]) by localhost (Postfix) with SMTP id 40B1C206E7E; Wed, 20 Jul 2016 19:49:03 +0200 (CEST) Received: from muguet1.intra.cea.fr (muguet1.intra.cea.fr [132.166.192.6]) by pisaure.intra.cea.fr (Postfix) with ESMTP id 29FE8206E2B; Wed, 20 Jul 2016 19:49:03 +0200 (CEST) Received: from [132.166.84.60] ([132.166.84.60]) by muguet1.intra.cea.fr (8.15.2/8.15.2/CEAnet-Intranet-out-1.4) with ESMTP id u6KHn2tt015927; Wed, 20 Jul 2016 19:49:03 +0200 Subject: Re: AW: Reference to "3333" value of RFC2464 "IPv6 over Ethernet" To: Karsten Thomann , IPv6 References: <34d7ea88-e5c3-af83-e05f-2d29c81a8b04@gmail.com> <20160720174708.5996626.43795.64328@linfre.de> From: Alexandre Petrescu Message-ID: <1db61704-5e1b-bb27-7b20-b10685453139@gmail.com> Date: Wed, 20 Jul 2016 19:49:02 +0200 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.2.0 MIME-Version: 1.0 In-Reply-To: <20160720174708.5996626.43795.64328@linfre.de> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Archived-At: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.17 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 Jul 2016 17:49:09 -0000 Le 20/07/2016 à 19:47, Karsten Thomann a écrit : > Hi Alex, > > IS-IS runs directly on ethernet over clns (iso), as it isn't an IP > protocol, even if it can route ipv4 and ipv6. I dont understand 'it can route ipv6'. I wonder whether an IS-IS packet can carry an IPv6 header? (something like IPv6-over-ISIS?) Alex > > Karsten > > Gesendet von meinem BlackBerry > *Von: *Alexandre Petrescu > *Gesendet: *Mittwoch, 20. Juli 2016 19:30 > *An: *IPv6 > *Betreff: *Re: Reference to "3333" value of RFC2464 "IPv6 over Ethernet" > > > Let me start a separate thread to continue this discussion: > > Can IS-IS run on IPv6 and if so which MAC multicast address? > > Alex > > > Le 20/07/2016 à 14:52, Hemant Singh a écrit : >> >> >> On Wed, Jul 20, 2016 at 5:49 AM, Alexandre Petrescu >> > >> wrote: >> >> >> >Does IS-IS also make use of 01-00-5E- multicast IANA OUI? (in >> addition to that C9). >> >> >> No. For Level-1 adjacencies, the packets are sent to 01-80-C2-00-00-14, >> and for Level-2 adjacencies, the packets are sent to 01-80-C2-00-00-15 >> >> Hemant >> > From nobody Wed Jul 20 11:02:58 2016 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 440A812D991 for ; Wed, 20 Jul 2016 11:02:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.189 X-Spam-Level: X-Spam-Status: No, score=-3.189 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-1.287, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] 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 hkWdyn9zfUMz for ; Wed, 20 Jul 2016 11:02:46 -0700 (PDT) Received: from linfre.de (linfre.de [83.151.26.85]) (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 95B2112D9C3 for ; Wed, 20 Jul 2016 11:02:34 -0700 (PDT) Received: from [127.0.0.1] (109.47.0.97) by linfreserv (Axigen) with (ECDHE-RSA-AES256-SHA encrypted) ESMTPSA id 1B44FF; Wed, 20 Jul 2016 20:02:23 +0200 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable X-Mailer: BlackBerry Email (10.3.2.2876) Message-ID: <20160720180223.5996626.91730.64332@linfre.de> Date: Wed, 20 Jul 2016 20:02:23 +0200 Subject: AW: Reference to "3333" value of RFC2464 "IPv6 over Ethernet" From: Karsten Thomann In-Reply-To: <1db61704-5e1b-bb27-7b20-b10685453139@gmail.com> References: <34d7ea88-e5c3-af83-e05f-2d29c81a8b04@gmail.com> <20160720174708.5996626.43795.64328@linfre.de> <1db61704-5e1b-bb27-7b20-b10685453139@gmail.com> To: Alexandre Petrescu , IPv6 X-AXIGEN-DK-Result: No records DomainKey-Status: no signature X-AxigenSpam-Level: 6 Archived-At: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.17 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 Jul 2016 18:02:57 -0000 As it is a routing protocol it is only providing routing information and is= n't carrying any IP payload within it's packets. It's the same with ospf, only that ospf3 and ipv6 share the same layer 3 pr= otocol (ipv6). Ospf wouldn't transport any payload except routing information, so there is= also no ipv6 over ospf=E2=80=8E3. Gesendet=C2=A0von=C2=A0meinem=C2=A0BlackBerry =C2=A0 Originalnachricht =C2=A0 Von: Alexandre Petrescu Gesendet: Mittwoch, 20. Juli 2016 19:50 An: Karsten Thomann; IPv6 Betreff: Re: AW: Reference to "3333" value of RFC2464 "IPv6 over Ethernet" Le 20/07/2016 =C3=A0 19:47, Karsten Thomann a =C3=A9crit : > Hi Alex, > > IS-IS runs directly on ethernet over clns (iso), as it isn't an IP > protocol, even if it can route ipv4 and ipv6. I dont understand 'it can route ipv6'. I wonder whether an IS-IS=20 packet can carry an IPv6 header? (something like IPv6-over-ISIS?) Alex > > Karsten > > Gesendet von meinem BlackBerry > *Von: *Alexandre Petrescu > *Gesendet: *Mittwoch, 20. Juli 2016 19:30 > *An: *IPv6 > *Betreff: *Re: Reference to "3333" value of RFC2464 "IPv6 over Ethernet" > > > Let me start a separate thread to continue this discussion: > > Can IS-IS run on IPv6 and if so which MAC multicast address? > > Alex > > > Le 20/07/2016 =C3=A0 14:52, Hemant Singh a =C3=A9crit : >> >> >> On Wed, Jul 20, 2016 at 5:49 AM, Alexandre Petrescu >> > >> wrote: >> >> >> >Does IS-IS also make use of 01-00-5E- multicast IANA OUI? (in >> addition to that C9). >> >> >> No. For Level-1 adjacencies, the packets are sent to 01-80-C2-00-00-14, >> and for Level-2 adjacencies, the packets are sent to 01-80-C2-00-00-15 >> >> Hemant >> > From nobody Wed Jul 20 11:14:06 2016 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6D77912D9E4 for ; Wed, 20 Jul 2016 11:14:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.333 X-Spam-Level: X-Spam-Status: No, score=-5.333 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_ADSP_CUSTOM_MED=0.001, FREEMAIL_FROM=0.001, NML_ADSP_CUSTOM_MED=0.9, RCVD_IN_DNSWL_HI=-5, SPF_SOFTFAIL=0.665] 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 rgy25X4oHAQX for ; Wed, 20 Jul 2016 11:14:02 -0700 (PDT) Received: from oxalide-out.extra.cea.fr (oxalide-out.extra.cea.fr [132.168.224.8]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BC08812D9C6 for ; Wed, 20 Jul 2016 11:14:01 -0700 (PDT) Received: from pisaure.intra.cea.fr (pisaure.intra.cea.fr [132.166.88.21]) by oxalide.extra.cea.fr (8.15.2/8.15.2/CEAnet-Internet-out-2.4) with ESMTP id u6KIDxou004887; Wed, 20 Jul 2016 20:13:59 +0200 Received: from pisaure.intra.cea.fr (localhost [127.0.0.1]) by localhost (Postfix) with SMTP id 9511A206F46; Wed, 20 Jul 2016 20:13:59 +0200 (CEST) Received: from muguet2.intra.cea.fr (muguet2.intra.cea.fr [132.166.192.7]) by pisaure.intra.cea.fr (Postfix) with ESMTP id 875DA206E75; Wed, 20 Jul 2016 20:13:59 +0200 (CEST) Received: from [132.166.84.60] ([132.166.84.60]) by muguet2.intra.cea.fr (8.15.2/8.15.2/CEAnet-Intranet-out-1.4) with ESMTP id u6KIDx1h001837; Wed, 20 Jul 2016 20:13:59 +0200 Subject: Re: Reference to "3333" value of RFC2464 "IPv6 over Ethernet" To: Karsten Thomann , IPv6 References: <34d7ea88-e5c3-af83-e05f-2d29c81a8b04@gmail.com> <20160720174708.5996626.43795.64328@linfre.de> <1db61704-5e1b-bb27-7b20-b10685453139@gmail.com> <20160720180223.5996626.91730.64332@linfre.de> From: Alexandre Petrescu Message-ID: <40fbdc2a-cb47-756b-d1c6-a8ff44883c55@gmail.com> Date: Wed, 20 Jul 2016 20:13:58 +0200 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.2.0 MIME-Version: 1.0 In-Reply-To: <20160720180223.5996626.91730.64332@linfre.de> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Archived-At: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.17 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 Jul 2016 18:14:05 -0000 Le 20/07/2016 à 20:02, Karsten Thomann a écrit : > As it is a routing protocol it is only providing routing information > and isn't carrying any IP payload within it's packets. It's the same > with ospf, only that ospf3 and ipv6 share the same layer 3 protocol > (ipv6). Ospf wouldn't transport any payload except routing > information, so there is also no ipv6 over ospf‎3. Ah I see what you mean. So yes there is no collision risk here: IS-IS uses its MAC multicast address, and IPv6 uses another MAC multicast address. It's still strange though how the former MAC address is more global although IS-IS has local operation, whereas the other one is more local whereas IPv6 can be considered a global protocol. Alex > > Gesendet von meinem BlackBerry Originalnachricht Von: Alexandre > Petrescu Gesendet: Mittwoch, 20. Juli 2016 19:50 An: Karsten Thomann; > IPv6 Betreff: Re: AW: Reference to "3333" value of RFC2464 "IPv6 over > Ethernet" > > > > Le 20/07/2016 à 19:47, Karsten Thomann a écrit : >> Hi Alex, >> >> IS-IS runs directly on ethernet over clns (iso), as it isn't an IP >> protocol, even if it can route ipv4 and ipv6. > > I dont understand 'it can route ipv6'. I wonder whether an IS-IS > packet can carry an IPv6 header? (something like IPv6-over-ISIS?) > > Alex > >> >> Karsten >> >> Gesendet von meinem BlackBerry *Von: *Alexandre Petrescu *Gesendet: >> *Mittwoch, 20. Juli 2016 19:30 *An: *IPv6 *Betreff: *Re: Reference >> to "3333" value of RFC2464 "IPv6 over Ethernet" >> >> >> Let me start a separate thread to continue this discussion: >> >> Can IS-IS run on IPv6 and if so which MAC multicast address? >> >> Alex >> >> >> Le 20/07/2016 à 14:52, Hemant Singh a écrit : >>> >>> >>> On Wed, Jul 20, 2016 at 5:49 AM, Alexandre Petrescu >>> >> > wrote: >>> >>> >>>> Does IS-IS also make use of 01-00-5E- multicast IANA OUI? (in >>> addition to that C9). >>> >>> >>> No. For Level-1 adjacencies, the packets are sent to >>> 01-80-C2-00-00-14, and for Level-2 adjacencies, the packets are >>> sent to 01-80-C2-00-00-15 >>> >>> Hemant >>> >> > From nobody Wed Jul 20 12:43:25 2016 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 020AF12D589 for ; Wed, 20 Jul 2016 12:43:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.188 X-Spam-Level: X-Spam-Status: No, score=-3.188 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-1.287, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] 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 Hy5VVrDAoq5z for ; Wed, 20 Jul 2016 12:43:22 -0700 (PDT) Received: from linfre.de (linfre.de [83.151.26.85]) (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 A18D812D0A7 for ; Wed, 20 Jul 2016 12:43:21 -0700 (PDT) Received: from linne.localnet (91.248.63.195) by linfreserv (Axigen) with (ECDHE-RSA-AES256-SHA encrypted) ESMTPSA id 01BDEF; Wed, 20 Jul 2016 21:43:10 +0200 From: Karsten Thomann To: Alexandre Petrescu Subject: Re: Reference to "3333" value of RFC2464 "IPv6 over Ethernet" Date: Wed, 20 Jul 2016 21:43:10 +0000 Message-ID: <1809954.0HI66GtkN6@linne> User-Agent: KMail/4.13.0.0 (Windows/6.1; KDE/4.13.3; i686; git-a6cb62d; 2014-12-22) In-Reply-To: <40fbdc2a-cb47-756b-d1c6-a8ff44883c55@gmail.com> References: <34d7ea88-e5c3-af83-e05f-2d29c81a8b04@gmail.com> <20160720180223.5996626.91730.64332@linfre.de> <40fbdc2a-cb47-756b-d1c6-a8ff44883c55@gmail.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="nextPart3072129.TjIZ89NcAb" Content-Transfer-Encoding: 7Bit X-AXIGEN-DK-Result: No records DomainKey-Status: no signature X-AxigenSpam-Level: 5 Archived-At: Cc: IPv6 X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.17 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 Jul 2016 19:43:24 -0000 This is a multi-part message in MIME format. --nextPart3072129.TjIZ89NcAb Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="iso-8859-1" Am Mittwoch, 20. Juli 2016, 20:13:58 schrieb Alexandre Petrescu: > Le 20/07/2016 =E0 20:02, Karsten Thomann a =E9crit : > > As it is a routing protocol it is only providing routing informatio= n > >=20 > > and isn't carrying any IP payload within it's packets. It's the sa= me > > with ospf, only that ospf3 and ipv6 share the same layer 3 protoco= l > > (ipv6). Ospf wouldn't transport any payload except routing > >=20 > > information, so there is also no ipv6 over ospf?3. >=20 > Ah I see what you mean. So yes there is no collision risk here: IS-I= S > uses its MAC multicast address, and IPv6 uses another MAC multicast a= ddress. >=20 > It's still strange though how the former MAC address is more global > although IS-IS has local operation, whereas the other one is more loc= al > whereas IPv6 can be considered a global protocol. I think we are getting a bit off-topic for this list, so only a very sh= ort answer. MAC addresses and IP addresses operate at different layers and are assi= gned and managed by=20 different organisations, so there are different meanings for the same w= ord. >=20 > Alex >=20 > > Gesendet von meinem BlackBerry Originalnachricht Von: Alexandre > > Petrescu Gesendet: Mittwoch, 20. Juli 2016 19:50 An: Karsten Thoman= n; > > IPv6 Betreff: Re: AW: Reference to "3333" value of RFC2464 "IPv6 ov= er > > Ethernet" > >=20 > > Le 20/07/2016 =E0 19:47, Karsten Thomann a =E9crit : > >> Hi Alex, > >>=20 > >> IS-IS runs directly on ethernet over clns (iso), as it isn't an IP= > >> protocol, even if it can route ipv4 and ipv6. > >=20 > > I dont understand 'it can route ipv6'. I wonder whether an IS-IS > > packet can carry an IPv6 header? (something like IPv6-over-ISIS?) > >=20 > > Alex > >=20 > >> Karsten > >>=20 > >> Gesendet von meinem BlackBerry *Von: *Alexandre Petrescu *Gesendet= : > >> *Mittwoch, 20. Juli 2016 19:30 *An: *IPv6 *Betreff: *Re: Reference= > >> to "3333" value of RFC2464 "IPv6 over Ethernet" > >>=20 > >>=20 > >> Let me start a separate thread to continue this discussion: > >>=20 > >> Can IS-IS run on IPv6 and if so which MAC multicast address? > >>=20 > >> Alex > >>=20 > >> Le 20/07/2016 =E0 14:52, Hemant Singh a =E9crit : > >>> On Wed, Jul 20, 2016 at 5:49 AM, Alexandre Petrescu > >>> >>>=20 > >>> > wrote: > >>>> Does IS-IS also make use of 01-00-5E- multicast IANA OUI? (in > >>>=20 > >>> addition to that C9). > >>>=20 > >>>=20 > >>> No. For Level-1 adjacencies, the packets are sent to > >>> 01-80-C2-00-00-14, and for Level-2 adjacencies, the packets are > >>> sent to 01-80-C2-00-00-15 > >>>=20 > >>> Hemant --nextPart3072129.TjIZ89NcAb Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset="iso-8859-1"

Am Mittwoch, 20. Juli= 2016, 20:13:58 schrieb Alexandre Petrescu:

>= ; Le 20/07/2016 =E0 20:02, Karsten Thomann a =E9crit :

>= ; > As it is a routing protocol it is only providing routing informa= tion

>= ; >

>= ; > and isn't carrying any IP payload within it's packets. It's the= same

>= ; > with ospf, only that ospf3 and ipv6 share the same layer 3 prot= ocol

>= ; > (ipv6). Ospf wouldn't transport any payload except routing

>= ; >

>= ; > information, so there is also no ipv6 over ospf?3.

>= ;

>= ; Ah I see what you mean. So yes there is no collision risk here: IS-I= S

>= ; uses its MAC multicast address, and IPv6 uses another MAC multicast a= ddress.

>= ;

>= ; It's still strange though how the former MAC address is more global

>= ; although IS-IS has local operation, whereas the other one is more loc= al

>= ; whereas IPv6 can be considered a global protocol.

 

I think we are gettin= g a bit off-topic for this list, so only a very short answer.

 

MAC addresses and IP = addresses operate at different layers and are assigned and managed by d= ifferent organisations, so there are different meanings for the same wo= rd.

 

 

>= ;

>= ; Alex

>= ;

>= ; > Gesendet von meinem BlackBerry Originalnachricht Von: Alexandre<= /p>

>= ; > Petrescu Gesendet: Mittwoch, 20. Juli 2016 19:50 An: Karsten Tho= mann;

>= ; > IPv6 Betreff: Re: AW: Reference to "3333" value of RFC= 2464 "IPv6 over

>= ; > Ethernet"

>= ; >

>= ; > Le 20/07/2016 =E0 19:47, Karsten Thomann a =E9crit :

>= ; >> Hi Alex,

>= ; >>

>= ; >> IS-IS runs directly on ethernet over clns (iso), as it isn't= an IP

>= ; >> protocol, even if it can route ipv4 and ipv6.

>= ; >

>= ; > I dont understand 'it can route ipv6'. I wonder whether an IS-IS=

>= ; > packet can carry an IPv6 header? (something like IPv6-over-ISIS?= )

>= ; >

>= ; > Alex

>= ; >

>= ; >> Karsten

>= ; >>

>= ; >> Gesendet von meinem BlackBerry *Von: *Alexandre Petrescu *Ge= sendet:

>= ; >> *Mittwoch, 20. Juli 2016 19:30 *An: *IPv6 *Betreff: *Re: Ref= erence

>= ; >> to "3333" value of RFC2464 "IPv6 over Etherne= t"

>= ; >>

>= ; >>

>= ; >> Let me start a separate thread to continue this discussion:<= /p>

>= ; >>

>= ; >> Can IS-IS run on IPv6 and if so which MAC multicast address?=

>= ; >>

>= ; >> Alex

>= ; >>

>= ; >> Le 20/07/2016 =E0 14:52, Hemant Singh a =E9crit :

>= ; >>> On Wed, Jul 20, 2016 at 5:49 AM, Alexandre Petrescu

>= ; >>> <alexandre.petrescu@gmail.com

>= ; >>>

>= ; >>> <mailto:alexandre.petrescu@gmail.com>> wrote:

>= ; >>>> Does IS-IS also make use of 01-00-5E- multicast IANA= OUI? (in

>= ; >>>

>= ; >>> addition to that C9).

>= ; >>>

>= ; >>>

>= ; >>> No. For Level-1 adjacencies, the packets are sent to

=

>= ; >>> 01-80-C2-00-00-14, and for Level-2 adjacencies, the pack= ets are

>= ; >>> sent to 01-80-C2-00-00-15

>= ; >>>

>= ; >>> Hemant

 

--nextPart3072129.TjIZ89NcAb-- From nobody Wed Jul 20 17:21:19 2016 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B3A2612D8AE; Wed, 20 Jul 2016 17:21:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.188 X-Spam-Level: X-Spam-Status: No, score=-3.188 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-1.287, SPF_PASS=-0.001] 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 7K31YqjT83jS; Wed, 20 Jul 2016 17:21:15 -0700 (PDT) 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 9006C12D106; Wed, 20 Jul 2016 17:21:15 -0700 (PDT) Received: from sandelman.ca (obiwan.sandelman.ca [IPv6:2607:f0b0:f:2::247]) by tuna.sandelman.ca (Postfix) with ESMTP id 35E5C200A3; Wed, 20 Jul 2016 20:30:47 -0400 (EDT) Received: from obiwan.sandelman.ca (localhost [IPv6:::1]) by sandelman.ca (Postfix) with ESMTP id 79CF8638D1; Wed, 20 Jul 2016 20:21:14 -0400 (EDT) From: Michael Richardson To: roll@ietf.org Subject: Re: impacts of rfc2460bis on draft-ietf-roll-useofrplinfo In-Reply-To: <6180.1469035031@obiwan.sandelman.ca> References: <24554.1468868593@obiwan.sandelman.ca> <799ab640-bed0-22a6-a9df-97f78c3f0bf8@gmail.com> <30725.1468924267@obiwan.sandelman.ca> <6180.1469035031@obiwan.sandelman.ca> X-Mailer: MH-E 8.6; nmh 1.6+dev; GNU Emacs 24.5.1 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@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.17 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 Jul 2016 00:21:18 -0000 --=-=-= Content-Type: text/plain Michael Richardson wrote: > today, at ROLL, we went through some slides to explain the improvements that > 2460bis "Note" does for us. Here are the link to the slides: https://www.ietf.org/proceedings/96/slides/slides-96-roll-2.pdf starting at slide 9. I will probably fix some minor typos and fill some missing labels to make it stand-alone -- Michael Richardson , Sandelman Software Works -= IPv6 IoT consulting =- --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 iQEVAwUBV5AVd4CLcPvd0N1lAQK/Jgf/dB4AIGy57vB6Y67wWVPFxXhWhCItRN6T RO4fURTiiXWv3k3Giir5vx8cPyixOG2S20e4JVKv9KEnAfgJT9BURo7eROIRfX91 LbjZHHEk2ojhSVyJFH9hJlqZGmhkJ6thAcQsRkRLAVP5ONeIkuoAfk6QbrgTvchn JWHlN3gAv4R3ga1S+zxtlGRFc/lnGdKsjhrfmhvy/axVDrgYpcpy0pm7pgJfkOEe ekmjAdzOsQIKxzhcqTreXnxT+vw6DhZPyYr2uxBlcXxeHLh3CqqdHoYTegv2T4wo pdeoaL0wP2rNE337oNVSQNh6xPu//vXsWkP6v/Jns4eLx8Q3jcuZEQ== =3JOZ -----END PGP SIGNATURE----- --=-=-=-- From nobody Wed Jul 20 17:23:42 2016 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1126612D7B4 for ; Wed, 20 Jul 2016 17:23:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.699 X-Spam-Level: X-Spam-Status: No, score=-1.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, FREEMAIL_REPLY=1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=no 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 u_d13IiKe698 for ; Wed, 20 Jul 2016 17:23:39 -0700 (PDT) Received: from mail-oi0-x22a.google.com (mail-oi0-x22a.google.com [IPv6:2607:f8b0:4003:c06::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 7594712D106 for ; Wed, 20 Jul 2016 17:23:39 -0700 (PDT) Received: by mail-oi0-x22a.google.com with SMTP id l65so95249209oib.1 for ; Wed, 20 Jul 2016 17:23:39 -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=Q57ml4asqxmDRtmtn594zYrmq1xKSdeU9HDeGfYQQpg=; b=VXQ2ashbvigBB+bXdZEVAw0D5A2ox9NPhDkrsVQwBdyoeBYSxIeEAZOci1nQwysjOi ScT6jIRxAlb1w9prngjhF0u9ReCoFpc4XMllOZnAdzvaO3mljyodoy0Nejs1Xoo+5ana H8GNfpaDVuLowP7tGUZ+DSTASdKbXmol6D3gN/Mm0dUzsAdC3SCvFi9M/Fshlyu7SfMz WdIbtCePgl2R11W8GI+id0UzIrpn9tjNAoaSS19e4IduxnscTWV2WZ0/1cKDAwVKd3VL UDtdRs7UWsqD2QjISTM5f2J8vAXlp7xgBd3rQ88bU/7VkvTk9OTCwSN2FsujSGFzTZJm +F+w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=Q57ml4asqxmDRtmtn594zYrmq1xKSdeU9HDeGfYQQpg=; b=dfBhGm25KhEVIsug0J2jQyx3s40oRuHXVGVfA9DH21eS/Ou3vfQXQPYd2DfbLmZH2B JT0f3fLZs3YeoL9cI08Cb6UQC5mqfzaHaN0irn1qWF1wyza4tEjgGEpmu8ZAh2nCukTf SIHAm2tN+qRvCEOp1OTFUVHpUIhb1au8q50F51xgHQphnBVwhQOI9Dz0m4RzYw0Gomge Uob1ri3SQceNOaImC3z/+WXyX/xFk9ftMagjD8TbthmsQSvx2pPD/YB1RKPBIT4noXM+ elpwrLeUD5ypeVEUT+zwnM8DviufLM08+tJ70L3F/TcGmdEieekUQS8Hxoqi3ka3Ivid 6qOw== X-Gm-Message-State: ALyK8tI9ajjwuocy9v/EWhLHrE3qxKIBqRpoUHKP8Va3cCDdQ6TNsonHDXj/QMk9G2MODRCv/QTpuhaZ/7yCPQ== X-Received: by 10.157.26.100 with SMTP id u33mr22065758otu.16.1469060618777; Wed, 20 Jul 2016 17:23:38 -0700 (PDT) MIME-Version: 1.0 Received: by 10.182.172.66 with HTTP; Wed, 20 Jul 2016 17:23:37 -0700 (PDT) In-Reply-To: <6bd94ded-6446-ddac-3e7e-3be25ec742db@gmail.com> References: <2f437218b23a44238ccdcb4e7318da8d@XCH-RCD-003.cisco.com> <5d4c7db8-76cf-8e87-4102-2b5ae9b9817f@gmail.com> <90610692-08a8-1c15-4f79-62263808fa98@gmail.com> <6bd94ded-6446-ddac-3e7e-3be25ec742db@gmail.com> From: Hemant Singh Date: Wed, 20 Jul 2016 20:23:37 -0400 Message-ID: Subject: Re: Reference to "3333" value of RFC2464 "IPv6 over Ethernet" To: Alexandre Petrescu Content-Type: multipart/alternative; boundary=001a1134f21055faf205381a5431 Archived-At: Cc: IPv6 X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.17 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 Jul 2016 00:23:41 -0000 --001a1134f21055faf205381a5431 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Please read rfc 5308 and also rfc1195. Many folks have already said IS-IS does not run at the IP layer and thus the question does not arise if IS-IS runs on IPv6. IS-IS is extensible in that it uses TLV's to support IPv4 and IPv6 adjacency information between routing peers. IS-IS running at the link layer decided long time back to use two mac-addresses to multicast messages to. We should stop chasing IS-IS for any rfc2460bis or other rfc bis and any multicast IPv6 mac discussion. Hemant On Wed, Jul 20, 2016 at 1:24 PM, Alexandre Petrescu < alexandre.petrescu@gmail.com> wrote: > Can IS-IS run on IPv6 and if so which MAC multicast address? > > Alex > > > Le 20/07/2016 =C3=A0 14:52, Hemant Singh a =C3=A9crit : > >> >> >> On Wed, Jul 20, 2016 at 5:49 AM, Alexandre Petrescu >> > >> wrote: >> >> >> >Does IS-IS also make use of 01-00-5E- multicast IANA OUI? (in >> addition to that C9). >> >> >> No. For Level-1 adjacencies, the packets are sent to 01-80-C2-00-00-14, >> and for Level-2 adjacencies, the packets are sent to 01-80-C2-00-00-15 >> >> Hemant >> >> --001a1134f21055faf205381a5431 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Please read rfc 5308 and also rfc1195.=C2=A0 Many folks ha= ve already said IS-IS does not run at the IP layer and thus the question do= es not arise if IS-IS runs on IPv6.=C2=A0 IS-IS is extensible in that it us= es TLV's to support IPv4 and IPv6 adjacency information between routing= peers. =C2=A0 IS-IS running at the link layer decided long time back to us= e two mac-addresses to multicast messages to.

We should = stop chasing IS-IS for any rfc2460bis or other rfc bis and any multicast IP= v6 mac discussion.=C2=A0


Hemant


On Wed= , Jul 20, 2016 at 1:24 PM, Alexandre Petrescu <alexandre.petres= cu@gmail.com> wrote:
Can IS= -IS run on IPv6 and if so which MAC multicast address?

Alex


Le 20/07/2016 =C3=A0 14:52, Hemant Singh a =C3=A9crit :


On Wed, Jul 20, 2016 at 5:49 AM, Alexandre Petrescu
 <alexa= ndre.petrescu@gmail.com <mailto:alexandre.petrescu@gmail.com>> wrot= e:


=C2=A0 =C2=A0 >Does IS-IS also make use of 01-00-5E- multicast IANA OUI?= (in
=C2=A0 =C2=A0 addition to that C9).


No.=C2=A0 For Level-1 adjacencies, the packets are sent to 01-80-C2-00-00-1= 4,
and for Level-2 adjacencies, the packets are sent to 01-80-C2-00-00-15

Hemant


--001a1134f21055faf205381a5431-- From nobody Wed Jul 20 22:45:10 2016 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E60D512DA09; Wed, 20 Jul 2016 22:45:08 -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 kcNQPPaul8Cw; Wed, 20 Jul 2016 22:45:07 -0700 (PDT) Received: from mail-qt0-x22e.google.com (mail-qt0-x22e.google.com [IPv6:2607:f8b0:400d:c0d::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 F0B3612D10F; Wed, 20 Jul 2016 22:45:06 -0700 (PDT) Received: by mail-qt0-x22e.google.com with SMTP id x25so38360308qtx.2; Wed, 20 Jul 2016 22:45:06 -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=YV1eL83sudldoG/YW5MFapxurd2DdI1U048XUMJzGe4=; b=UrB7i5Er0gnxt69/OgqEw/MFMu/ifmKmKbZNrPP/jpzp5gjOp9kt7BktDcSq4dVRJO u80N45drZe0Mh0a0kTDcmV/7OyldlPv2ZenvyTfe2SV+73H0p6mwHBjZJP6jR1kFcwVi jEADfAxt+uYjFKV/0ywxroxtuu/eC6LqrjBd/9iCAHQ6QbxMHYL0ELp2VTtQKm0f+Qnl QzNv+ZNYIYirnMr3hfnzN+sn26/dBfUCjjby9B5Rx1xTt4mFf3Ae/kaY1FxN1035PQBh bjvBc7i2mXZLDJDlK2us7td/CiZDeoAHJmLavcYkGK/wa9uBING4x14hTNw22lkhp6C6 pPsA== 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=YV1eL83sudldoG/YW5MFapxurd2DdI1U048XUMJzGe4=; b=OC1zjUJfBIMxjNgbVe66R9stiageDmj60Riua87wRwKWQ2LQmFZF4c+zjgY0Pjbbfg RvFLNmEmu8DtorTrtp8tVDaBfHi15bmrqgYMu9mN41qi0RQbbZBg9vdV+gOpor5x9Q2J oUP51pyd9vGFFWblxn65+ijI08ySTU6rI5ZVaym8u5O4ZHZP5M9o/J/0xWMs0X7QChnK g/UDgS+os1DPX1dcgEloe3oVwafC58Q6FvbWino6hTGn23xBjQpqKkTtRJBRz3KUojtT 5/Onm4KkAelEv4RxiH3ORuTiW/8gjbmpD4tIEXkCO9MHDl2uc9pEUQw85X8lI9UTiZmP Rpbg== X-Gm-Message-State: ALyK8tICdGfespxkT+KcVNvFyun6NYCitEELQceL2VwnNpAUwkmhtiD1GfT2Gcv3yFHY+Q== X-Received: by 10.200.49.203 with SMTP id i11mr77613247qte.40.1469079906098; Wed, 20 Jul 2016 22:45:06 -0700 (PDT) Received: from ?IPv6:2001:67c:370:136:28cc:dc4c:9703:6781? ([2001:67c:370:136:28cc:dc4c:9703:6781]) by smtp.gmail.com with ESMTPSA id o84sm3436798qke.38.2016.07.20.22.45.04 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 20 Jul 2016 22:45:05 -0700 (PDT) Subject: Re: impacts of rfc2460bis on draft-ietf-roll-useofrplinfo To: Michael Richardson , roll@ietf.org References: <24554.1468868593@obiwan.sandelman.ca> <799ab640-bed0-22a6-a9df-97f78c3f0bf8@gmail.com> <30725.1468924267@obiwan.sandelman.ca> <6180.1469035031@obiwan.sandelman.ca> <2070.1469060474@obiwan.sandelman.ca> From: Brian E Carpenter Organization: University of Auckland Message-ID: Date: Thu, 21 Jul 2016 17:45:11 +1200 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.2.0 MIME-Version: 1.0 In-Reply-To: <2070.1469060474@obiwan.sandelman.ca> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Archived-At: Cc: 6man@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.17 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 Jul 2016 05:45:09 -0000 On 21/07/2016 12:21, Michael Richardson wrote: > > Michael Richardson wrote: > > today, at ROLL, we went through some slides to explain the improvements that > > 2460bis "Note" does for us. Here are the link to the slides: > > https://www.ietf.org/proceedings/96/slides/slides-96-roll-2.pdf > starting at slide 9. > I will probably fix some minor typos and fill some missing labels > to make it stand-alone Again, I'm OK with the "Note" as a compromise to get us to Internet Standard. Without the "Note" the compromise breaks. Remember, for Internet Standard we are focussed on proven Internet-wide interoperability. Once that's done I think we should circle around again and look seriously at this and other "local use" issues. What should we say on top of Internet-wide standard about local use? We have a clear local use mechanism for DSCPs. We argued through the same issue for the latest revision of the flow label standard. For that matter, ULAs and NPTv6 also touch local use issues. I think it's a future work item after shipping 2460bis. From nobody Thu Jul 21 01:03:21 2016 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 77D6312DB1F for ; Thu, 21 Jul 2016 01:03:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.45 X-Spam-Level: X-Spam-Status: No, score=-2.45 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_ENVFROM_END_DIGIT=0.25, 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 DxZabQk9a5dB for ; Thu, 21 Jul 2016 01:03:17 -0700 (PDT) Received: from mail-it0-x229.google.com (mail-it0-x229.google.com [IPv6:2607:f8b0:4001:c0b::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 38DA012DAC4 for <6man@ietf.org>; Thu, 21 Jul 2016 01:03:17 -0700 (PDT) Received: by mail-it0-x229.google.com with SMTP id f6so8531146ith.1 for <6man@ietf.org>; Thu, 21 Jul 2016 01:03:17 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=G2aRTL0y0AH7NXjAmMIjRlROiUWXAnbOs/xOqUut2wA=; b=EfEvHNiPIIaDdaMdr4tI7YykCy2tdkcrdDDy67TeqVrSGb0pvc18mxyIRmtYc9sHfC zxdxdOvn9cG0kB5QW0AU6JgP7DSEGm4Kj+fC6QkCbm/PGYwG6GrSl2j7tazdINkXBrD9 Rp1KKTv9UU4WdTcyB5b2qzFmovBZlRcityrM2+cswels3/IgCxE+q0ui7yoSJa2W0vq+ rjKd+MuagSFY7lMn6tTDVZi1eTViuvDlMgQxlgFCA4LDUh5YhI+Rdi7s/NlwzLPgPhFJ FgotBXC0LiJJe3lNbWohJldmcebddwWiJ9cvJQHhaIBUtxxkzUeYEPsFeHPMYFcIkhUx OmGQ== 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-transfer-encoding; bh=G2aRTL0y0AH7NXjAmMIjRlROiUWXAnbOs/xOqUut2wA=; b=EqSVWHQ7eXQ8xmX4+Bvya9HZ1ktnJ84vvOApfEfJOQVkGGqiMMNkvY01Mr1nju6Fjg 9GAi2opVWNX884uvy/xDZ9P8fhA6CReMo9hB8o914EIqGuV7MTyPsdGmrDkCd0vfxtXQ 0p3Z67nAvBzNOfNbJmgmPCBZBcxlw6GvooLbhV0OxehiqXQEGj55+2SgO9NT9YpdrhpK Ho1+mqStiwliKdF0SqtmhrVp27Bn+ue2ZNtPDfSpwLtWujR+Kio+NPBYT0bL73HhYBGS YRhF2WrjWeLz8pyQ9F9Kei7QJMYUcRA7zQY7S/QYbylU+qvV2xJS2SC5dbT/4dwsR1kz qnug== X-Gm-Message-State: ALyK8tISxxrDnD4hctjEC5a6nuTMYZs1wdgRLgsQ30TZtfgi3H6rbyz3nJNWlbZ2VTKB+txxAnd8YB9i3nJf3A== X-Received: by 10.36.155.194 with SMTP id o185mr666237itd.54.1469088196465; Thu, 21 Jul 2016 01:03:16 -0700 (PDT) MIME-Version: 1.0 Received: by 10.64.187.37 with HTTP; Thu, 21 Jul 2016 01:02:57 -0700 (PDT) In-Reply-To: <787AE7BB302AE849A7480A190F8B933008DE9E22@OPEXCLILMA3.corporate.adroot.infra.ftgroup> References: <26582.1468923195@obiwan.sandelman.ca> <2EBFA6F2-00A3-45E1-BE0E-3531AF75726A@employees.org> <787AE7BB302AE849A7480A190F8B933008DE9E22@OPEXCLILMA3.corporate.adroot.infra.ftgroup> From: Jen Linkova Date: Thu, 21 Jul 2016 10:02:57 +0200 Message-ID: Subject: Re: proposed text for header injection revision 05 To: mohamed.boucadair@orange.com Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Archived-At: Cc: Michael Richardson , "6man@ietf.org" <6man@ietf.org>, "Mark Townsley \(townsley\)" X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.17 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 Jul 2016 08:03:19 -0000 On Wed, Jul 20, 2016 at 6:06 PM, wrote: > Hi Ole, all, > > I'm for removing that text as it does not add any recommendation at all. Seconded. I can not see what we are trying to achieve by having that second paragraph. It does not add any value and should be removed. > > Cheers, > Med > >> -----Message d'origine----- >> De : ipv6 [mailto:ipv6-bounces@ietf.org] De la part de >> otroan@employees.org >> Envoy=C3=A9 : mercredi 20 juillet 2016 12:55 >> =C3=80 : Brian E Carpenter >> Cc : Michael Richardson; 6man@ietf.org; Mark Townsley (townsley) >> Objet : Re: proposed text for header injection revision 05 >> >> >> I clearly prefer and support Mark's suggestion of removing entirely t= he >> second paragraph. >> >> >> >> s. >> >> >> > >> > If we do that I want to see the famous "processed" clarified to make i= ts >> > intended meaning unambiguous: >> > >> > With one exception, extension headers are not processed, modified, >> inserted >> > or deleted by any node along a packet's delivery path, ... >> >> that text seems to say that in the exception case extension headers can = be >> modified, inserted or deleted. >> I'm pretty sure that's not what we want to say. ;-) >> >> > The second paragraph is a compromise that avoids that clarification. >> >> yes, I fear that the suggestion of deleting that paragraph will lead us >> into the same round of disagreements that led up to that compromise. >> >> let's assume we cannot find consensus on removing the paragraph, nor can >> we find consensus on adding the "processed" clarification. >> >> I don't mind tweaking the second paragraph if that's required. >> currently it says: >> >> The current approach to allowing a header to be inserted is to >> encapsulate the packet using another IPv6 header and including the >> additional extension header after the first IPv6 header, for example, >> as defined in [RFC2473]. >> >> Michael proposed: >> >> An approach an intermediate node/router may take to include an >> additional >> extension header in an IPv6 packet that it did not originate is to >> encapsulate the original packet in a new IPv6 header. As the >> source address of this IPv6 packet would then be the router, any >> number of additional extension headers may be placed after this new >> header, >> prior to the original packet. A system making use of this mechanism >> will >> have to specify how to construct the rest of the IPv6 header, in >> particulate, >> such a specification needs to carefully consider what the destination >> address >> will be. >> >> or simply: >> >> One approach to inserting Extension Headers by a node other than the >> source of the packet >> is to encapsulate the packet using a new IPv6 header and including the >> additional >> Extension Headers as specified in section 3.1 of RFC2473. >> >> any others? a case of the beer for the winner! ;-) >> >> Best regards, >> Ole > > -------------------------------------------------------------------- > IETF IPv6 working group mailing list > ipv6@ietf.org > Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 > -------------------------------------------------------------------- --=20 SY, Jen Linkova aka Furry From nobody Thu Jul 21 01:25:20 2016 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7911912DBDD for ; Thu, 21 Jul 2016 01:25:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.333 X-Spam-Level: X-Spam-Status: No, score=-5.333 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_ADSP_CUSTOM_MED=0.001, FREEMAIL_FROM=0.001, NML_ADSP_CUSTOM_MED=0.9, RCVD_IN_DNSWL_HI=-5, SPF_SOFTFAIL=0.665] 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 kAi70mYWVYt4 for ; Thu, 21 Jul 2016 01:25:16 -0700 (PDT) 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 93DC312DBDA for ; Thu, 21 Jul 2016 01:25:16 -0700 (PDT) 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 u6L8PC0Q010641; Thu, 21 Jul 2016 10:25:12 +0200 Received: from pisaure.intra.cea.fr (localhost [127.0.0.1]) by localhost (Postfix) with SMTP id 30908204584; Thu, 21 Jul 2016 10:25:12 +0200 (CEST) Received: from muguet2.intra.cea.fr (muguet2.intra.cea.fr [132.166.192.7]) by pisaure.intra.cea.fr (Postfix) with ESMTP id 1EEF4204526; Thu, 21 Jul 2016 10:25:12 +0200 (CEST) Received: from [132.166.84.1] ([132.166.84.1]) by muguet2.intra.cea.fr (8.15.2/8.15.2/CEAnet-Intranet-out-1.4) with ESMTP id u6L8PBpN027726; Thu, 21 Jul 2016 10:25:11 +0200 Subject: Re: Reference to "3333" value of RFC2464 "IPv6 over Ethernet" To: Hemant Singh References: <2f437218b23a44238ccdcb4e7318da8d@XCH-RCD-003.cisco.com> <5d4c7db8-76cf-8e87-4102-2b5ae9b9817f@gmail.com> <90610692-08a8-1c15-4f79-62263808fa98@gmail.com> <6bd94ded-6446-ddac-3e7e-3be25ec742db@gmail.com> From: Alexandre Petrescu Message-ID: <86d2022e-aabf-764a-dc55-9957cdc916fe@gmail.com> Date: Thu, 21 Jul 2016 10:25:11 +0200 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.2.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 X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.17 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 Jul 2016 08:25:18 -0000 Le 21/07/2016 à 02:23, Hemant Singh a écrit : > Please read rfc 5308 and also rfc1195. Many folks have already said > IS-IS does not run at the IP layer and thus the question does not > arise if IS-IS runs on IPv6. IS-IS is extensible in that it uses > TLV's to support IPv4 and IPv6 adjacency information between routing > peers. IS-IS running at the link layer decided long time back to use > two mac-addresses to multicast messages to. That's fine. > We should stop chasing IS-IS for any rfc2460bis or other rfc bis and > any multicast IPv6 mac discussion. Misunderstanding. I am not chasing IS-IS, but I point out that IS-IS seems to be using a globally unique (OUI) for its MAC multicast addresses, even though IS-IS is obviously a local protocol. This MAC address is allocated at IEEE and noted at IANA. And, on the other hand, IPv6 global protocol seems to be using a 'locally administered' MAC multicast address (no OUI), which is not allocated by IEEE in any way; it is however noted at IANA. In other words: why IS-IS deserves an OUI whereas IPv6 gets along with only a locally-administered MAC? That's not normal. Alex > > > Hemant > > > On Wed, Jul 20, 2016 at 1:24 PM, Alexandre Petrescu > > > wrote: > > Can IS-IS run on IPv6 and if so which MAC multicast address? > > Alex > > > Le 20/07/2016 à 14:52, Hemant Singh a écrit : > > > > On Wed, Jul 20, 2016 at 5:49 AM, Alexandre Petrescu > > >> wrote: > > >> Does IS-IS also make use of 01-00-5E- multicast IANA OUI? (in > addition to that C9). > > > No. For Level-1 adjacencies, the packets are sent to > 01-80-C2-00-00-14, and for Level-2 adjacencies, the packets are sent > to 01-80-C2-00-00-15 > > Hemant > > From nobody Thu Jul 21 01:33:44 2016 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C5BD012D0BC for ; Thu, 21 Jul 2016 01:33:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.566 X-Spam-Level: X-Spam-Status: No, score=-0.566 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_SORBS_WEB=0.77, SPF_HELO_PASS=-0.001, SPF_SOFTFAIL=0.665] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=employees.org; domainkeys=pass (1024-bit key) header.from=otroan@employees.org header.d=employees.org 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 i8LM4mWi4ZhS for ; Thu, 21 Jul 2016 01:33:36 -0700 (PDT) Received: from incoming.kjsl.com (inbound02.kjsl.com [IPv6:2001:1868:2002::144]) (using TLSv1.2 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B411512B02A for <6man@ietf.org>; Thu, 21 Jul 2016 01:33:36 -0700 (PDT) Received: from cowbell.employees.org ([65.50.211.142]) by ironport02.kjsl.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 21 Jul 2016 08:33:34 +0000 Received: from cowbell.employees.org (localhost [127.0.0.1]) by cowbell.employees.org (Postfix) with ESMTP id BA0579CC4F; Thu, 21 Jul 2016 01:33:33 -0700 (PDT) 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=TzC0xUHS2VAHQ5T5hvnVWWzGDBQ=; b= piQW8Xd9V9vdw/NGIhyHPBL36bObkjyu74GrDMZOo2maxjoGAStZ6sOi/2hkdIk6 g4nFrBB5th5qLkrM0UUfdbFueDVVyTLrmL5BN1BWttXhZ0T805xCUQPqmDu219pu MyPyF5u6pEV1EgP6Qo/ek8RlBtES4CWnTwVE4lEx5JE= 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=HVeYuNfmpD+a0367XJkA4tfW+4 4Wlk5tNLePtSbqBnbVXzrFWJ/32OFai3KTUUa3aeHpcp6cw2NZt61JqaevikNDRz H+Uy3vy1t/D3fAWUQy9Ungll0S8oBkphYXNRyBKb/ot7Ps+NFPyeHNrm+9cksUDF qxX9Xv48k/UUhH15I= Received: from h.hanazo.no (2.150.3.47.tmi.telenormobil.no [2.150.3.47]) (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 6343C9CC4E; Thu, 21 Jul 2016 01:33:33 -0700 (PDT) Received: from [IPv6:::1] (localhost [IPv6:::1]) by h.hanazo.no (Postfix) with ESMTP id 0B6AB2B92049; Thu, 21 Jul 2016 10:33:30 +0200 (CEST) Subject: Re: proposed text for header injection revision 05 Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) Content-Type: multipart/signed; boundary="Apple-Mail=_C7AAB67F-1651-4841-86B6-882F9C59CB71"; protocol="application/pgp-signature"; micalg=pgp-sha512 X-Pgp-Agent: GPGMail From: otroan@employees.org In-Reply-To: Date: Thu, 21 Jul 2016 10:33:29 +0200 Message-Id: References: <26582.1468923195@obiwan.sandelman.ca> <2EBFA6F2-00A3-45E1-BE0E-3531AF75726A@employees.org> <787AE7BB302AE849A7480A190F8B933008DE9E22@OPEXCLILMA3.corporate.adroot.infra.ftgroup> To: Jen Linkova X-Mailer: Apple Mail (2.3124) Archived-At: Cc: Michael Richardson , "6man@ietf.org" <6man@ietf.org>, "Mark Townsley \(townsley\)" X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.17 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 Jul 2016 08:33:43 -0000 --Apple-Mail=_C7AAB67F-1651-4841-86B6-882F9C59CB71 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Jen, >> I'm for removing that text as it does not add any recommendation at = all. >=20 > Seconded. I can not see what we are trying to achieve by having that > second paragraph. It does not add any value and should be removed. Not to pick on you, but can you pretend to represent the people who want = the second paragraph removed for a little while? The below text represents a compromise between those who want an = outright prohibition on inserting / modifying / deleting extension = headers and those who want to leave the current 2460 ambiguity = ambiguous. The compromise is quite a balancing act. =46rom what I heard during the = meeting and on this thread, it does not seem like we will achieve = consensus on text without the second paragraph. I'm fine with you being unhappy with the below text. :-) But can you _live_ with it? And if not, why not? Does it break interoperability, does it prohibit = future work in this space? =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D The insertion of Extension Headers by any node other than the source of the packet breaks PMTU-discovery and can result in ICMP error messages being sent to the source of the packet that did not insert the header. One approach to inserting Extension Headers by a node other than the = source of the packet is to encapsulate the packet using a new IPv6 header and including = the additional Extension Headers as specified in section 3.1 of RFC2473. =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D Best regards, Ole --Apple-Mail=_C7AAB67F-1651-4841-86B6-882F9C59CB71 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 iQEcBAEBCgAGBQJXkIjZAAoJED4aXnjSQuKWECQH/j4d9ZPyaT9bVrGSEQqc4ek9 mHYqT8b3Tr5MO2/3lJWuv2liB76f8xvH3mjLQsLRvtsDBSvywta2OYetPCHrsd2o qb2/9aCj2bXCkHeK4JfNi9CjaSdDktOeLU1mNE1CZGL2b3E6pi3vhfE0w6HaKU0s 6EQ8SpdXicPJLOnVxWZFIyVDFMXZBJmTXF0O0s/Qe+wa69XD4QzPif9hfhiZfq77 dJWGlKZ92oV0tdm95jzMClb4hf/OnuQIwWHaBCU/ISt2rDPtrHRAefT/jhf80SmS OT/R9nr+z6KqkgiWaF38jPqzSX2btJ/F31uKQbeafQ+Jg3G3BQ4mQx54TWpceFw= =CQac -----END PGP SIGNATURE----- --Apple-Mail=_C7AAB67F-1651-4841-86B6-882F9C59CB71-- From nobody Thu Jul 21 01:47:55 2016 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CC6E812DB07 for ; Thu, 21 Jul 2016 01:47:54 -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 rkJi-4sJfY2a for ; Thu, 21 Jul 2016 01:47:48 -0700 (PDT) Received: from mail-wm0-x22d.google.com (mail-wm0-x22d.google.com [IPv6:2a00:1450:400c: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 C9F1312D0AC for <6man@ietf.org>; Thu, 21 Jul 2016 01:47:42 -0700 (PDT) Received: by mail-wm0-x22d.google.com with SMTP id i5so16197324wmg.0 for <6man@ietf.org>; Thu, 21 Jul 2016 01:47:42 -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=2NMjYo8DriPbG3k6BqCre779dbz3jaqpSVEV2lQnPTs=; b=kfZ4wrFvEVIS8+szMcnYue/GvW+ltcyMydsA+CtQVETeBVijrvfAjX2P79T8sedcH3 8tapVLF63YNlbIUX9Nwa4oBYSKNmtGZM56tfJCuhBP+d/UnaoMAnDToKX0RIRFUNeZD6 n3s2moYqv9t3D3J8LepPDxQZsuYdfdN1djhwrZU7L4USpxInF80E+OamYd+Wy/rBPRMH GpjnRQYlgA06q0+0Oyivstf6+iaU8WeHd5QQfZT2+vRcaVEXtT+YOPPb1cdwQ5rWlTF6 v9YqFEMJG/nsAXtLHlBvukmH4oVATa6cZY8l8tHydMSUWlxH7D56QiAr85sMW6mEyhlw JXvA== 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=2NMjYo8DriPbG3k6BqCre779dbz3jaqpSVEV2lQnPTs=; b=WGQpOtsOGNhyPdWHQ8xs6t+jhGk9/h/VCSL/HKcsXupqWvGhsXV8+ubs5Jn4lNb1kU IhVz8f917PR0g1t/CFNFJbtUZJWk8rU2se2T6+f21ltnOI4lmb6e9YaFDyBRcmFUUynW SLqgxMuGcvyqfi0NI6i4ZRnNd8vvM8yYa2SUc9n2qhU4qNTdZo49z4JQJJOzndVtswS+ ByP127xX1gXrDfnHyUAcP9pWwbbzDMCPj+Qs7hej+rjlV/sa4iOncFIqyEDHiRjmMAd3 jvgHUK2zj41zrsNpl8URrIO5KuY2Rr1imi5kyiTVWkw6ywN22PXJxFDfDYfncovf+/EW NHTA== X-Gm-Message-State: ALyK8tLD+lcCiqzDqHesDFf8HfSKrgUJ8vCyoH+m8jj1M+j0jdhKzWVulY1LYfcDPpP9Jg== X-Received: by 10.28.152.5 with SMTP id a5mr16388667wme.76.1469090861208; Thu, 21 Jul 2016 01:47:41 -0700 (PDT) Received: from ?IPv6:2001:67c:370:152:28cc:dc4c:9703:6781? ([2001:67c:370:152:28cc:dc4c:9703:6781]) by smtp.gmail.com with ESMTPSA id g8sm5271555wjk.27.2016.07.21.01.47.39 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 21 Jul 2016 01:47:40 -0700 (PDT) Subject: Re: proposed text for header injection revision 05 To: Jen Linkova , mohamed.boucadair@orange.com References: <26582.1468923195@obiwan.sandelman.ca> <2EBFA6F2-00A3-45E1-BE0E-3531AF75726A@employees.org> <787AE7BB302AE849A7480A190F8B933008DE9E22@OPEXCLILMA3.corporate.adroot.infra.ftgroup> From: Brian E Carpenter Organization: University of Auckland Message-ID: <0445fd4c-3d96-73f5-035e-570f165faf9b@gmail.com> Date: Thu, 21 Jul 2016 20:47:47 +1200 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.2.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Archived-At: Cc: Michael Richardson , "6man@ietf.org" <6man@ietf.org>, "Mark Townsley \(townsley\)" X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.17 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 Jul 2016 08:47:55 -0000 On 21/07/2016 20:02, Jen Linkova wrote: > On Wed, Jul 20, 2016 at 6:06 PM, wrote:= >> Hi Ole, all, >> >> I'm for removing that text as it does not add any recommendation at al= l. >=20 > Seconded. I can not see what we are trying to achieve by having that > second paragraph. It does not add any value and should be removed. So, can we go back to the version at https://tools.ietf.org/html/draft-ietf-6man-rfc2460bis-01#page-7 which does add value? Again: that second paragraph is part of a compromise between those who wa= nt to explicitly forbid any insertion of headers and those who don't. Remove= it and you break the compromise. Brian >=20 >> >> Cheers, >> Med >> >>> -----Message d'origine----- >>> De : ipv6 [mailto:ipv6-bounces@ietf.org] De la part de >>> otroan@employees.org >>> Envoy=C3=A9 : mercredi 20 juillet 2016 12:55 >>> =C3=80 : Brian E Carpenter >>> Cc : Michael Richardson; 6man@ietf.org; Mark Townsley (townsley) >>> Objet : Re: proposed text for header injection revision 05 >>> >>>>> I clearly prefer and support Mark's suggestion of removing entirely= the >>> second paragraph. >>>>> >>>>> s. >>>>> >>>> >>>> If we do that I want to see the famous "processed" clarified to make= its >>>> intended meaning unambiguous: >>>> >>>> With one exception, extension headers are not processed, modified= , >>> inserted >>>> or deleted by any node along a packet's delivery path, ... >>> >>> that text seems to say that in the exception case extension headers c= an be >>> modified, inserted or deleted. >>> I'm pretty sure that's not what we want to say. ;-) >>> >>>> The second paragraph is a compromise that avoids that clarification.= >>> >>> yes, I fear that the suggestion of deleting that paragraph will lead = us >>> into the same round of disagreements that led up to that compromise. >>> >>> let's assume we cannot find consensus on removing the paragraph, nor = can >>> we find consensus on adding the "processed" clarification. >>> >>> I don't mind tweaking the second paragraph if that's required. >>> currently it says: >>> >>> The current approach to allowing a header to be inserted is to >>> encapsulate the packet using another IPv6 header and including the= >>> additional extension header after the first IPv6 header, for examp= le, >>> as defined in [RFC2473]. >>> >>> Michael proposed: >>> >>> An approach an intermediate node/router may take to include an >>> additional >>> extension header in an IPv6 packet that it did not originate is to >>> encapsulate the original packet in a new IPv6 header. As the >>> source address of this IPv6 packet would then be the router, any >>> number of additional extension headers may be placed after this new= >>> header, >>> prior to the original packet. A system making use of this mechanis= m >>> will >>> have to specify how to construct the rest of the IPv6 header, in >>> particulate, >>> such a specification needs to carefully consider what the destinati= on >>> address >>> will be. >>> >>> or simply: >>> >>> One approach to inserting Extension Headers by a node other than th= e >>> source of the packet >>> is to encapsulate the packet using a new IPv6 header and including = the >>> additional >>> Extension Headers as specified in section 3.1 of RFC2473. >>> >>> any others? a case of the beer for the winner! ;-) >>> >>> Best regards, >>> Ole >> >> -------------------------------------------------------------------- >> IETF IPv6 working group mailing list >> ipv6@ietf.org >> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 >> -------------------------------------------------------------------- >=20 >=20 >=20 From nobody Thu Jul 21 01:58:51 2016 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 113F312B017; Thu, 21 Jul 2016 01:58:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -15.808 X-Spam-Level: X-Spam-Status: No, score=-15.808 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.287, 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 3qQlESmQ6lo3; Thu, 21 Jul 2016 01:58:42 -0700 (PDT) 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 4ADBC12D0AC; Thu, 21 Jul 2016 01:58:42 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2554; q=dns/txt; s=iport; t=1469091522; x=1470301122; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=HYUTTTfYvfwC3Wu+RvDT89Qg7DqdxzWvifEVZEFWlFM=; b=jvde2XxKMD3I1ekzACACCxhIkEvYJGXEtE1TeFvhJYWj9bPWYi0oWJh7 g00MzGof5r3dK1EYIc3EY458paI+n0JMLWh/V95dyp24U+XX0DCUMSbTm hw7nzwCH8p4d6zfjhBWTsjIzRBznPCmU+wI2PbW79FwxRscM3PffbWBPa 8=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0AlAgDxjZBX/5xdJa1dgz9WfAa4XIF7I?= =?us-ascii?q?oV4AhyBEDgUAQEBAQEBAWUcC4RdAQUBASEROgsQAgEIGAICJgICAiULFRACBA4?= =?us-ascii?q?FG4gVDq9OjWkBAQEBAQEBAQEBAQEBAQEBAQEBAQEXBYEBiHOBA4QqBhCDAYJaA?= =?us-ascii?q?QSZJgGGFYhVjzqQIAEeNoILHIFMbgGGWH8BAQE?= X-IronPort-AV: E=Sophos;i="5.28,398,1464652800"; d="scan'208";a="300428671" Received: from rcdn-core-5.cisco.com ([173.37.93.156]) by alln-iport-7.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 21 Jul 2016 08:58:41 +0000 Received: from XCH-ALN-003.cisco.com (xch-aln-003.cisco.com [173.36.7.13]) by rcdn-core-5.cisco.com (8.14.5/8.14.5) with ESMTP id u6L8wf97012248 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Thu, 21 Jul 2016 08:58:41 GMT Received: from xch-aln-003.cisco.com (173.36.7.13) by XCH-ALN-003.cisco.com (173.36.7.13) with Microsoft SMTP Server (TLS) id 15.0.1210.3; Thu, 21 Jul 2016 03:58:40 -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.1210.000; Thu, 21 Jul 2016 03:58:40 -0500 From: "Bernie Volz (volz)" To: "otroan@employees.org" Subject: Re: [dhcwg] draft-ietf-6man-default-iids Section 4 & 6.9 (DHCPv6) Thread-Topic: [dhcwg] draft-ietf-6man-default-iids Section 4 & 6.9 (DHCPv6) Thread-Index: AQHR4yonS2aKHoWIFECnh5Wt1IH5QqAi5eGA///ArQA= Date: Thu, 21 Jul 2016 08:58:40 +0000 Message-ID: References: <43CE5CAD-2D98-4A75-BF33-E5B415B1013C@employees.org> In-Reply-To: <43CE5CAD-2D98-4A75-BF33-E5B415B1013C@employees.org> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.6.6.160626 x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.86.251.56] Content-Type: text/plain; charset="utf-8" Content-ID: <57C0EB814611EF4F9F30A3FD65B1C5D4@emea.cisco.com> Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: Cc: "dhcwg@ietf.org" , "draft-ietf-6man-default-iids@ietf.org" , "dhcpv6bis@ietf.org" , "ipv6@ietf.org" X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.17 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 Jul 2016 08:58:44 -0000 T2xlOg0KDQooSSBmaXhlZCA2bWFuIG1haWxpbmcgbGlzdCBhZGRyZXNzLikNCg0KVGhhdCBpcyBw cm9iYWJseSB0aGUgYmVzdCBzb2x1dGlvbiBhbmQgSSB3b3VsZCBzdXBwb3J0IHRoYXQuDQoNCldl IGNhbiBzdGlsbCBkaXNjdXNzIGNoYW5naW5nIHNvbWUgb2YgdGhlIHRleHQgaW4gMzMxNWJpcywg YnV0IHRoYXQgY2FuDQp0aGVuIGJlIGRvbmUgd2l0aG91dCA2bWFuIGludm9sdmVtZW50LiAoV2Ug ZG8gc3RpbGwgaGF2ZSB0aGUgb2xkZXIgdGV4dCBpbg0Kd2hhdCBpcyBub3cgU2VjdGlvbiAxMi4x IG9mIGRyYWZ0LWlldGYtZGhjLXJmYzMzMTViaXMtMDUsIHNvIHNob3VsZCByZWFsbHkNCmNsZWFu IHRoYXQgdXAuKQ0KDQotIEJlcm5pZQ0KDQoNCk9uIDcvMjEvMTYsIDQ6NDUgQU0sICJvdHJvYW5A ZW1wbG95ZWVzLm9yZyIgPG90cm9hbkBlbXBsb3llZXMub3JnPiB3cm90ZToNCg0KPkJlcm5pZSwg ZXQgYWwsDQo+DQo+VGhlIGZpcnN0IGxpbmUgb2YgdGhlIGFic3RyYWN0IHNheXM6DQo+ICAgIlRo aXMgZG9jdW1lbnQgY2hhbmdlcyB0aGUgcmVjb21tZW5kZWQgZGVmYXVsdCBJSUQgZ2VuZXJhdGlv biBzY2hlbWUNCj4gICBmb3IgY2FzZXMgd2hlcmUgU0xBQUMgaXMgdXNlZCB0byBnZW5lcmF0ZSBh IHN0YWJsZSBJUHY2IGFkZHJlc3MuIg0KPg0KPkknbSBub3QgY29udmluY2VkIHRoYXQgd2UgbmVl ZCB0byBoYXZlIHRoZSBESENQIHBhcmFncmFwaCB0aGVyZSBhdCBhbGwuDQo+V291bGQgdGhhdCB3 b3JrIGZvciB5b3U/DQo+DQo+QmVzdCByZWdhcmRzLA0KPk9sZQ0KPg0KPg0KPj4gT24gMjEgSnVs IDIwMTYsIGF0IDEwOjMwLCBCZXJuaWUgVm9seiAodm9seikgPHZvbHpAY2lzY28uY29tPiB3cm90 ZToNCj4+IA0KPj4gQWxpc3NhLCBldCBhbDoNCj4+IA0KPj4gQmFzZWQgb24gYSBjb252ZXJzYXRp b24gYmV0d2VlbiBzb21lIG9mIHRoZSBkcmFmdC1pZXRmLWRoYy1yZmMzMzE1YmlzDQo+PmNvYXV0 aG9ycyBhbmQgaW4gdGhlIERIQyBXRyBzZXNzaW9uIFdlZG5lc2RheSAoNy8yMCkgbW9ybmluZywg d2UgYXJlIG5vdA0KPj5pbiBmYXZvciBvZiB0aGUgcmVwbGFjZW1lbnQgdGV4dCBhcyBpdCBjdXJy ZW50bHkgc3RhbmRzLiBXZSB3aWxsIHdvcmsNCj4+c29tZXRoaW5nIHVwIGFuZCBzZW5kIGl0IHRv IHlvdSBhcyBzb29uIGFzIHdlIGNhbi4NCj4+IA0KPj4gV2UgYXJlIGxpa2VseSB0byBzaW1wbGlm eSB0aGUgcmVwbGFjZW1lbnQgdGV4dCB0byBzb21ldGhpbmcgbGlrZSB0aGUNCj4+Zm9sbG93aW5n IChidXQgdGhpcyBpcyBvbmx5IG15IHByb3Bvc2FsIGFuZCBoYXMgbm90IGJlZW4gcmV2aWV3ZWQg YnkNCj4+b3RoZXJzKToNCj4+IA0KPj4gICAgIEJ5IGRlZmF1bHQsIERIQ1B2NiBzZXJ2ZXIgaW1w bGVtZW50YXRpb25zIFNIT1VMRCBOT1QgZ2VuZXJhdGUNCj4+ICAgICBwcmVkaWN0YWJsZSBJUHY2 IGFkZHJlc3NlcyAoW1JGQzc3MjFdKS4gREhDUHY2IHNlcnZlcnMgU0hPVUxEDQo+PiAgICAgTk9U IGFzc2lnbiBhZGRyZXNzZXMgdGhhdCB1c2UgYSByZXNlcnZlZCBJUHY2IEludGVyZmFjZSBJZGVu dGlmaWVyDQo+PiAgICAgKFtSRkM1NDUzXSwgW1JGQzcxMzZdLCBhbmQgW0lBTkFSRVNFUlZFRElJ RF0pLg0KPj4gDQo+PiBXZSBhcmUgdHJhY2tpbmcgdGhpcyBpc3N1ZSBhdA0KPj5odHRwczovL3Ry YWMudG9vbHMuaWV0Zi5vcmcvZ3JvdXAvZGhjcHY2YmlzL3RpY2tldC8xNjYuDQo+PiANCj4+IC0g QmVybmllDQo+PiBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f Xw0KPj4gZGhjd2cgbWFpbGluZyBsaXN0DQo+PiBkaGN3Z0BpZXRmLm9yZw0KPj4gaHR0cHM6Ly93 d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9kaGN3Zw0KPg0KDQo= From nobody Thu Jul 21 02:03:41 2016 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A3DD312DBEA for ; Thu, 21 Jul 2016 02:03:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.189 X-Spam-Level: X-Spam-Status: No, score=-3.189 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-1.287, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] 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 lKscotutPWOm for ; Thu, 21 Jul 2016 02:03:37 -0700 (PDT) Received: from givry.fdupont.fr (givry.fdupont.fr [IPv6:2001:41d0:1:6d55:211:5bff:fe98:d51e]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DA02912DC25 for ; Thu, 21 Jul 2016 02:03:36 -0700 (PDT) Received: from givry.fdupont.fr (localhost [IPv6:::1]) by givry.fdupont.fr (8.14.7/8.14.7) with ESMTP id u6L92AFc088476; Thu, 21 Jul 2016 11:02:10 +0200 (CEST) (envelope-from dupont@givry.fdupont.fr) Message-Id: <201607210902.u6L92AFc088476@givry.fdupont.fr> From: Francis Dupont To: Alexandre Petrescu Subject: Re: Reference to "3333" value of RFC2464 "IPv6 over Ethernet" In-reply-to: Your message of Thu, 21 Jul 2016 10:25:11 +0200. <86d2022e-aabf-764a-dc55-9957cdc916fe@gmail.com> Date: Thu, 21 Jul 2016 11:02:10 +0200 Archived-At: Cc: IPv6 X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.17 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 Jul 2016 09:03:39 -0000 IS-IS is not an IETF protocol but an OSI ISO one. Regards Francis.Dupont@fdupont.fr From nobody Thu Jul 21 02:09:55 2016 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6ED9812DB5D for ; Thu, 21 Jul 2016 02:09:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.288 X-Spam-Level: X-Spam-Status: No, score=-3.288 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=-1.287, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=swm.pp.se 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 mjDakPCrvOPl for ; Thu, 21 Jul 2016 02:09:52 -0700 (PDT) Received: from uplift.swm.pp.se (ipv6.swm.pp.se [IPv6:2a00:801::f]) (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 1D4AA12DBDD for ; Thu, 21 Jul 2016 02:09:52 -0700 (PDT) Received: by uplift.swm.pp.se (Postfix, from userid 501) id A6769A5; Thu, 21 Jul 2016 11:09:48 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=swm.pp.se; s=mail; t=1469092188; bh=8ho9ayg1Ym5Kao51CjUnMyNLPVdLTNiEIifIAQiek7U=; h=Date:From:To:cc:Subject:In-Reply-To:References:From; b=QDLCbyayqvM/rP4da2SP8TmLdVmXjJ/cRzNi37romEmUMeU1TRDcFGLEb3nd5XhQ4 MhehvKH59IDRHEfImQO4hBIc/g99qQqiu8+vyWX86HYVQPovh/zLcuNSQkZhCjbRtO XJ5fYntp/REIOxb2hEYyUH2gKKdF5GKvv3FkFX94= Received: from localhost (localhost [127.0.0.1]) by uplift.swm.pp.se (Postfix) with ESMTP id 9FE16A4; Thu, 21 Jul 2016 11:09:48 +0200 (CEST) Date: Thu, 21 Jul 2016 11:09:48 +0200 (CEST) From: Mikael Abrahamsson To: Hemant Singh Subject: Re: Reference to "3333" value of RFC2464 "IPv6 over Ethernet" In-Reply-To: Message-ID: References: <2f437218b23a44238ccdcb4e7318da8d@XCH-RCD-003.cisco.com> <5d4c7db8-76cf-8e87-4102-2b5ae9b9817f@gmail.com> <90610692-08a8-1c15-4f79-62263808fa98@gmail.com> <6bd94ded-6446-ddac-3e7e-3be25ec742db@gmail.com> User-Agent: Alpine 2.02 (DEB 1266 2009-07-14) Organization: People's Front Against WWW MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Archived-At: Cc: IPv6 X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.17 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 Jul 2016 09:09:54 -0000 On Wed, 20 Jul 2016, Hemant Singh wrote: > We should stop chasing IS-IS for any rfc2460bis or other rfc bis and any > multicast IPv6 mac discussion. I agree. So whilst there are implementations of ISIS that run over either IP or UDP-in-IP, and there is draft text that describe this, I don't think this is anything that needs to be brought up in 2460bis context. -- Mikael Abrahamsson email: swmike@swm.pp.se From nobody Thu Jul 21 02:12:10 2016 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CBA5112DC34 for ; Thu, 21 Jul 2016 02:12:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.588 X-Spam-Level: X-Spam-Status: No, score=-5.588 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_MED=-2.3, RP_MATCHES_RCVD=-1.287, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=swm.pp.se 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 sZciD_GObaWM for ; Thu, 21 Jul 2016 02:12:08 -0700 (PDT) Received: from uplift.swm.pp.se (swm.pp.se [212.247.200.143]) (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 61FEA12DC43 for ; Thu, 21 Jul 2016 02:12:02 -0700 (PDT) Received: by uplift.swm.pp.se (Postfix, from userid 501) id 7FBBCA4; Thu, 21 Jul 2016 11:11:59 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=swm.pp.se; s=mail; t=1469092320; bh=FiLmMaiyq5q2HvEAxC/hXB9BAp1X/WPdJX054p4CpcA=; h=Date:From:To:cc:Subject:In-Reply-To:References:From; b=sDynS+YF20sTNAe7YxwQCpQJwwKQJLg8IVhpND9ulTM+jPkq8JwSVOi0SQPrOAy3i IznC5G0m8XNRjjoGcHSSoNhI6kVX+PblWavFhc9JqSaDfB4vQxFIhZ2qoMTqT+OzS8 4AytpG1Fx4q5PZ05a9T6vxxsDAfedOT2dICXLAMk= Received: from localhost (localhost [127.0.0.1]) by uplift.swm.pp.se (Postfix) with ESMTP id CEFD5A2; Thu, 21 Jul 2016 11:11:59 +0200 (CEST) Date: Thu, 21 Jul 2016 11:11:59 +0200 (CEST) From: Mikael Abrahamsson To: Francis Dupont Subject: Re: Reference to "3333" value of RFC2464 "IPv6 over Ethernet" In-Reply-To: <201607210902.u6L92AFc088476@givry.fdupont.fr> Message-ID: References: <201607210902.u6L92AFc088476@givry.fdupont.fr> User-Agent: Alpine 2.02 (DEB 1266 2009-07-14) Organization: People's Front Against WWW MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Archived-At: Cc: IPv6 X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.17 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 Jul 2016 09:12:10 -0000 On Thu, 21 Jul 2016, Francis Dupont wrote: > IS-IS is not an IETF protocol but an OSI ISO one. Since there is an active IETF working group called "isis" that actively develops ISIS related standards using IETF RFC process, I would argue the opposite. Yes, ISIS started in OSI, but most of all implementations now implement ISIS protocol mechanisms based on documents that are handled by IETF. -- Mikael Abrahamsson email: swmike@swm.pp.se From nobody Thu Jul 21 02:24:15 2016 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A1C3B127078 for ; Thu, 21 Jul 2016 02:24:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.189 X-Spam-Level: X-Spam-Status: No, score=-3.189 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-1.287, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] 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 KPZW72ZjTqnp for ; Thu, 21 Jul 2016 02:24:07 -0700 (PDT) Received: from linfre.de (linfre.de [83.151.26.85]) (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 1EE5C12DC4C for ; Thu, 21 Jul 2016 02:24:07 -0700 (PDT) Received: from e7240.linfre (91.97.109.144) by linfreserv (Axigen) with (ECDHE-RSA-AES256-SHA encrypted) ESMTPSA id 217DF0; Thu, 21 Jul 2016 11:23:59 +0200 From: Karsten Thomann To: ipv6@ietf.org Subject: Re: Reference to "3333" value of RFC2464 "IPv6 over Ethernet" Date: Thu, 21 Jul 2016 11:23:58 +0200 Message-ID: <2007986.l75Eys8xCF@e7240.linfre> User-Agent: KMail/5.2.2 (Linux/4.6.3-1-default; KDE/5.23.0; x86_64; ; ) In-Reply-To: <86d2022e-aabf-764a-dc55-9957cdc916fe@gmail.com> References: <2f437218b23a44238ccdcb4e7318da8d@XCH-RCD-003.cisco.com> <86d2022e-aabf-764a-dc55-9957cdc916fe@gmail.com> MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="iso-8859-1" X-AXIGEN-DK-Result: No records DomainKey-Status: no signature X-AxigenSpam-Level: 7 Archived-At: Cc: Alexandre Petrescu X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.17 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 Jul 2016 09:24:09 -0000 Am Donnerstag, 21. Juli 2016, 10:25:11 CEST schrieb Alexandre Petrescu: > Le 21/07/2016 =E0 02:23, Hemant Singh a =E9crit : > > Please read rfc 5308 and also rfc1195. Many folks have already said > > IS-IS does not run at the IP layer and thus the question does not > > arise if IS-IS runs on IPv6. IS-IS is extensible in that it uses > > TLV's to support IPv4 and IPv6 adjacency information between routing > > peers. IS-IS running at the link layer decided long time back to use > > two mac-addresses to multicast messages to. >=20 > That's fine. >=20 > > We should stop chasing IS-IS for any rfc2460bis or other rfc bis and > > any multicast IPv6 mac discussion. Support >=20 > Misunderstanding. >=20 > I am not chasing IS-IS, but I point out that IS-IS seems to be using a > globally unique (OUI) for its MAC multicast addresses, even though IS-IS > is obviously a local protocol. This MAC address is allocated at IEEE > and noted at IANA. IS-IS has no OUI, it has reserved MAC addresses from a special purpose rang= e,=20 take a look at http://standards.ieee.org/develop/regauth/grpmac/public.html for assignements from that range. I didn't understand the meaning of "local protocol" in your sentence. >=20 > And, on the other hand, IPv6 global protocol seems to be using a > 'locally administered' MAC multicast address (no OUI), which is not > allocated by IEEE in any way; it is however noted at IANA. As I've already written in another mail, that are completely different laye= rs. The IEEE allows free use of MAC adresses if the locally administered bit is= =20 set.=20 >=20 > In other words: why IS-IS deserves an OUI whereas IPv6 gets along with > only a locally-administered MAC? That's not normal. Short answer: History. >=20 > Alex >=20 > > Hemant > >=20 > >=20 > > On Wed, Jul 20, 2016 at 1:24 PM, Alexandre Petrescu > > > > > wrote: > >=20 > > Can IS-IS run on IPv6 and if so which MAC multicast address? > >=20 > > Alex > >=20 > >=20 > > Le 20/07/2016 =E0 14:52, Hemant Singh a =E9crit : > >=20 > >=20 > >=20 > > On Wed, Jul 20, 2016 at 5:49 AM, Alexandre Petrescu > > > > >=20 > > >> wrote: > >> Does IS-IS also make use of 01-00-5E- multicast IANA OUI? (in > >=20 > > addition to that C9). > >=20 > >=20 > > No. For Level-1 adjacencies, the packets are sent to > > 01-80-C2-00-00-14, and for Level-2 adjacencies, the packets are sent > > to 01-80-C2-00-00-15 > >=20 > > Hemant >=20 > -------------------------------------------------------------------- > IETF IPv6 working group mailing list > ipv6@ietf.org > Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 > -------------------------------------------------------------------- From nobody Thu Jul 21 06:46:57 2016 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F13F312B01A for ; Thu, 21 Jul 2016 06:46:54 -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=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=venaas-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 EBU8UxccxTku for ; Thu, 21 Jul 2016 06:46:39 -0700 (PDT) Received: from mail-lf0-x232.google.com (mail-lf0-x232.google.com [IPv6:2a00:1450:4010:c07::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 8F32F12D0F5 for ; Thu, 21 Jul 2016 06:46:38 -0700 (PDT) Received: by mail-lf0-x232.google.com with SMTP id b199so62552470lfe.0 for ; Thu, 21 Jul 2016 06:46:38 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=venaas-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=6MoU8LzcRX81P7jJzgNtE7pWvaOkYLvnITS1AEMeRk8=; b=y1Yf1+DH1MgmooxHNFEM+aq5AcDXwvqEh9UxwabpmM82Ef+FYnky+fZ/7mKgUKulxf xbyxQd39OGKQlGISkPjFlyk67TopeYbdMhfIkrCOC07QLth8F6IUHK6GDOJ0Hj9tDV6x Y0T9TWdR9ocC9mTRrVoMfamKp0Byw28d6hFpMEhzfXW6buPujI7UjE3P30CFH1OvphiD niqsgFecSaFtshBINqv+xbOj083klhrGC88rV19yThV46atsHsaPwFXECMzYZpoHsPyB UvNZk86id4CbKJR1VRU0NaV8DHjZmPtSGzw9ewoQv25iSJSb8sMQBKl7cEJEc7cwrbsH jiiQ== 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-transfer-encoding; bh=6MoU8LzcRX81P7jJzgNtE7pWvaOkYLvnITS1AEMeRk8=; b=hVRfg8/Af8WELx0dlBTfMZA7rwKzw8KPwnuqumKNYYmVEpDY+VW1l3bbErcEOIKWto VvJIAxA8jLlh4jnYv36kEMXh9EPSCpEDpRRKpn/7trQXCXIn1OxFtqzS3w2o61FvfHsX BMeoXC9hL2OdSdacDu9YpVNXe9sQ4R0IQljWNRt+JnK+vXNiu6nQAfahuYDtpGozbfTV NTEi8oMFGdZS8niY0312LU6CbPQnKVtzbitS2vFmaPgrqoqDULV5Uou4g9rYd5+aQaBy SajI/yW+CsU97m0Xue02yAAHOvllQXRCNYxp50ZRTrCIfdYCud1W2ZTIzsiX9uzQONkI RAgw== X-Gm-Message-State: ALyK8tI567ipFvqhzfaGafA55LPVsT+VDet9b5oY98PugiyNt/D8Xx42LRI3n+isbjR5dG96rRILDZTtdbwJsg== X-Received: by 10.25.40.141 with SMTP id o135mr23846009lfo.151.1469108796624; Thu, 21 Jul 2016 06:46:36 -0700 (PDT) MIME-Version: 1.0 Received: by 10.25.165.72 with HTTP; Thu, 21 Jul 2016 06:46:35 -0700 (PDT) In-Reply-To: <5c775ad5-3e88-5d0e-f221-d36c5d4d5b38@gmail.com> References: <26148.1468914385@obiwan.sandelman.ca> <1ac389c5-22ca-2283-d09c-a26bea9c7a75@gmail.com> <5c775ad5-3e88-5d0e-f221-d36c5d4d5b38@gmail.com> From: Stig Venaas Date: Thu, 21 Jul 2016 06:46:35 -0700 Message-ID: Subject: Re: 2464 - link-local multicast address mapping To: Alexandre Petrescu Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Archived-At: Cc: 6man WG X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.17 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 Jul 2016 13:46:55 -0000 Hi On Wed, Jul 20, 2016 at 10:22 AM, Alexandre Petrescu wrote: > > > Le 20/07/2016 =C3=A0 14:24, Stig Venaas a =C3=A9crit : >> >> Hi >> >> On Wed, Jul 20, 2016 at 2:40 AM, Alexandre Petrescu >> wrote: >>> >>> >>> >>> Le 20/07/2016 =C3=A0 00:01, Mark Smith a =C3=A9crit : >>>> >>>> >>>> On 20 Jul 2016 2:12 AM, "Alexandre Petrescu" >>>> >>> > wrote: >>>>> >>>>> >>>>> >>>>> Hi, >>>>> >>>>> Currently the RFC2464 multicast address mapping says: >>>>> >>>>>> An IPv6 packet with a multicast destination address DST, >>>>>> consisting of the sixteen octets DST[1] through DST[16], is >>>>>> transmitted to the Ethernet multicast address whose first >>>>>> two octets are the value 3333 hexadecimal and whose last four >>>>>> octets are the last four octets of DST. >>>>> >>>>> >>>>> >>>>> >>>>> I think this mapping should happen only for link-scoped IPv6 >> >> >> Why? Both for IPv4 and IPv6 you need to have some destination >> multicast MAC address for any IP/IPv6 multicast packet, regardless >> of scope. > > > It woudlnt make sense to map a global-scope IPv6 multicast address into > a - by definition local - Ethernet multicast address. I know the local means locally assigned, but it is the same mapping regardless of scope. Even a global scope multicast packet need to have a defined MAC mapping so that a NIC can be programmed to receive the appropriate packets. Since only the last 4 octets from the IP address is in the MAC address, there can be many IP multicast addresses using the same MAC address. Hence in some cases a NIC could receive a packet it isn't interested in. But this cannot really be avoided when you map an IPv6 address into 48 bits or less. > There is not enough place in there. As such reverse mapping would be > impossible. > >>>> destination addresses, not other scopes. >>>>> >>>>> >>>>> >>>>> I.e. the last four octets of a _link-local_ IPv6 address >>>>> should get >>>> >>>> >>>> mapped into that MAC address (ff02::XXXX:XXXX -> >>>> 33-33-XX-XX-XX-XX); multicast addresses of other scopes than ff02 >>>> should not get mapped. >>>>> >>>>> >>>>> >>>> >>>> I think you're assuming that there are no other nodes on the >>>> link are members of the > link-local scope group, or that there >>>> is no more than one multicast router on the link. >>> >>> >>> >>> Yes, I do assume so. >> >> >> It's fairly common to have multiple multicast routers on the link, >> and there can definitely be multiple members of a link-local group >> (or any group) on the link. > > > Yes certainly there can be multiple IP multicast routers on a link. But > I dont see how that supports mapping a global multicast address into an > Ethernet address. I don't know why it matters how many routers there are. >>>> Multicast address scopes are only indicating boundary of the >>>> multicast forwarding domain, not where multicast group members >>>> are or are not. >>> >>> >>> >>> But an Ethernet 33-33- scope can only be a link scope. A reverse >> >> >> Why? > > > Because the whole world is not (and can not) be Ethernet - there are > other link types as well. As such its scope can only be local. A global scope multicast packet might be forwarded across multiple links. On each link it traverses it will have some local link address. So you can say the L3 address is global, while the L2 address is just for the link. >> >>> mapping from an Ethernet scope back to a > link-local scope would >>> make no sense. >>> >>> (I also assume mapping to be bidirectional). >> >> >> What do you mean by bidirectional? As you wrote, you cannot do a >> reverse mapping. > > > Bidirectional - map from IP address to MAC address, and vice-versa. > 'Mapping' suggests me ability to translate and reversely too. > > Or maybe this RFC2464 'mapping' means to translate into only one > direction? (translate an IP to MAC but not vice-versa) Yes, it's only in one direction. Stig > Alex > > >> >> Stig >> >>> Alex >>> >>>> >>>> Regards, Mark. >>>> >>>>> Alex >>>>> >>>>> -------------------------------------------------------------------- >>>>> >>>>> >>> >>>>> > 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 Thu Jul 21 07:54:34 2016 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9F9CB12D6A6 for ; Thu, 21 Jul 2016 07:54:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.333 X-Spam-Level: X-Spam-Status: No, score=-5.333 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_ADSP_CUSTOM_MED=0.001, FREEMAIL_FROM=0.001, NML_ADSP_CUSTOM_MED=0.9, RCVD_IN_DNSWL_HI=-5, SPF_SOFTFAIL=0.665] 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 aBccJ4Ef2pLJ for ; Thu, 21 Jul 2016 07:54:30 -0700 (PDT) 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 E37A112D53B for ; Thu, 21 Jul 2016 07:54:29 -0700 (PDT) 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 u6LEsQSU025868; Thu, 21 Jul 2016 16:54:26 +0200 Received: from pisaure.intra.cea.fr (localhost [127.0.0.1]) by localhost (Postfix) with SMTP id 1E5F0207E08; Thu, 21 Jul 2016 16:54:26 +0200 (CEST) Received: from muguet2.intra.cea.fr (muguet2.intra.cea.fr [132.166.192.7]) by pisaure.intra.cea.fr (Postfix) with ESMTP id 0F125207A16; Thu, 21 Jul 2016 16:54:26 +0200 (CEST) Received: from [132.166.84.87] ([132.166.84.87]) by muguet2.intra.cea.fr (8.15.2/8.15.2/CEAnet-Intranet-out-1.4) with ESMTP id u6LEsPoD009861; Thu, 21 Jul 2016 16:54:25 +0200 Subject: Re: Reference to "3333" value of RFC2464 "IPv6 over Ethernet" To: Karsten Thomann , ipv6@ietf.org References: <2f437218b23a44238ccdcb4e7318da8d@XCH-RCD-003.cisco.com> <86d2022e-aabf-764a-dc55-9957cdc916fe@gmail.com> <2007986.l75Eys8xCF@e7240.linfre> From: Alexandre Petrescu Message-ID: <8a7c2460-ca23-f281-e3cd-03e69bbcb533@gmail.com> Date: Thu, 21 Jul 2016 16:54:25 +0200 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.2.0 MIME-Version: 1.0 In-Reply-To: <2007986.l75Eys8xCF@e7240.linfre> 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.17 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 Jul 2016 14:54:32 -0000 Le 21/07/2016 11:23, Karsten Thomann a crit : > Am Donnerstag, 21. Juli 2016, 10:25:11 CEST schrieb Alexandre > Petrescu: >> Le 21/07/2016 02:23, Hemant Singh a crit : >>> Please read rfc 5308 and also rfc1195. Many folks have already >>> said IS-IS does not run at the IP layer and thus the question >>> does not arise if IS-IS runs on IPv6. IS-IS is extensible in >>> that it uses TLV's to support IPv4 and IPv6 adjacency information >>> between routing peers. IS-IS running at the link layer decided >>> long time back to use two mac-addresses to multicast messages >>> to. >> >> That's fine. >> >>> We should stop chasing IS-IS for any rfc2460bis or other rfc bis >>> and any multicast IPv6 mac discussion. > Support > >> >> Misunderstanding. >> >> I am not chasing IS-IS, but I point out that IS-IS seems to be >> using a globally unique (OUI) for its MAC multicast addresses, even >> though IS-IS is obviously a local protocol. This MAC address is >> allocated at IEEE and noted at IANA. > > IS-IS has no OUI, it has reserved MAC addresses from a special > purpose range, take a look at > http://standards.ieee.org/develop/regauth/grpmac/public.html for > assignements from that range. > > I didn't understand the meaning of "local protocol" in your > sentence. By 'local protocol' I mean that it happens locally in closed environments. I can't send send an IS-IS packet from here to Japan, as I would do with ping6 for example. >> And, on the other hand, IPv6 global protocol seems to be using a >> 'locally administered' MAC multicast address (no OUI), which is >> not allocated by IEEE in any way; it is however noted at IANA. > As I've already written in another mail, that are completely > different layers. The IEEE allows free use of MAC adresses if the > locally administered bit is set. Yes, and the address for 01-80-C2- for IS-IS does not have that 'locally-administered' bit set. I.e. it's a 'globally unique' (OUI enforced) even though IS-IS is more of a local nature (cant send packets to Japan as I do with ping6). It's maybe a stretch, but that's how I see it. >> In other words: why IS-IS deserves an OUI whereas IPv6 gets along >> with only a locally-administered MAC? That's not normal. > Short answer: History. That's fine. Alex > >> >> Alex >> >>> Hemant >>> >>> >>> On Wed, Jul 20, 2016 at 1:24 PM, Alexandre Petrescu >>> >> > wrote: >>> >>> Can IS-IS run on IPv6 and if so which MAC multicast address? >>> >>> Alex >>> >>> >>> Le 20/07/2016 14:52, Hemant Singh a crit : >>> >>> >>> >>> On Wed, Jul 20, 2016 at 5:49 AM, Alexandre Petrescu >>> >> >>> >> >>> >> wrote: >>>> Does IS-IS also make use of 01-00-5E- multicast IANA OUI? (in >>> >>> addition to that C9). >>> >>> >>> No. For Level-1 adjacencies, the packets are sent to >>> 01-80-C2-00-00-14, and for Level-2 adjacencies, the packets are >>> sent to 01-80-C2-00-00-15 >>> >>> Hemant >> >> -------------------------------------------------------------------- >> >> IETF IPv6 working group mailing list >> ipv6@ietf.org Administrative Requests: >> https://www.ietf.org/mailman/listinfo/ipv6 >> -------------------------------------------------------------------- > >> > > From nobody Thu Jul 21 08:02:22 2016 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EE26C12D63B for ; Thu, 21 Jul 2016 08:02:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.333 X-Spam-Level: X-Spam-Status: No, score=-5.333 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_ADSP_CUSTOM_MED=0.001, FREEMAIL_FROM=0.001, NML_ADSP_CUSTOM_MED=0.9, RCVD_IN_DNSWL_HI=-5, SPF_SOFTFAIL=0.665] 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 J_4wOzNOHZTf for ; Thu, 21 Jul 2016 08:02:19 -0700 (PDT) Received: from oxalide-out.extra.cea.fr (oxalide-out.extra.cea.fr [132.168.224.8]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3EF8012D5F9 for ; Thu, 21 Jul 2016 08:02:18 -0700 (PDT) Received: from pisaure.intra.cea.fr (pisaure.intra.cea.fr [132.166.88.21]) by oxalide.extra.cea.fr (8.15.2/8.15.2/CEAnet-Internet-out-2.4) with ESMTP id u6LF2Fam014648; Thu, 21 Jul 2016 17:02:15 +0200 Received: from pisaure.intra.cea.fr (localhost [127.0.0.1]) by localhost (Postfix) with SMTP id 3BD9A206618; Thu, 21 Jul 2016 17:02:15 +0200 (CEST) Received: from muguet1.intra.cea.fr (muguet1.intra.cea.fr [132.166.192.6]) by pisaure.intra.cea.fr (Postfix) with ESMTP id 2D1192073A9; Thu, 21 Jul 2016 17:02:15 +0200 (CEST) Received: from [132.166.84.87] ([132.166.84.87]) by muguet1.intra.cea.fr (8.15.2/8.15.2/CEAnet-Intranet-out-1.4) with ESMTP id u6LF2ETL023599; Thu, 21 Jul 2016 17:02:14 +0200 Subject: Re: 2464 - link-local multicast address mapping To: Stig Venaas References: <26148.1468914385@obiwan.sandelman.ca> <1ac389c5-22ca-2283-d09c-a26bea9c7a75@gmail.com> <5c775ad5-3e88-5d0e-f221-d36c5d4d5b38@gmail.com> From: Alexandre Petrescu Message-ID: <22d11b1c-0416-65f8-28a8-5b6cdff5e71f@gmail.com> Date: Thu, 21 Jul 2016 17:02:14 +0200 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.2.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Archived-At: Cc: 6man WG X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.17 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 Jul 2016 15:02:21 -0000 Hi, Le 21/07/2016 à 15:46, Stig Venaas a écrit : [...] >>>>>> I think this mapping should happen only for link-scoped >>>>>> IPv6 >>> >>> >>> Why? Both for IPv4 and IPv6 you need to have some destination >>> multicast MAC address for any IP/IPv6 multicast packet, >>> regardless of scope. >> >> >> It woudlnt make sense to map a global-scope IPv6 multicast address >> into a - by definition local - Ethernet multicast address. > > I know the local means locally assigned, but it is the same mapping > regardless of scope. Even a global scope multicast packet need to > have a defined MAC mapping so that a NIC can be programmed to receive > the appropriate packets. Hmm, I would agree, but I also think that the NIC of the default router should not be programmed in some special way to receive appropriate packets multicast packets. I think it's sufficient for it to have a normal unicast IP and MAC address, and be present in the default router list of the sender. > Since only the last 4 octets from the IP address is in the MAC > address, there can be many IP multicast addresses using the same MAC > address. That's not good, right? These groups are different groups. > Hence in some cases a NIC could receive a packet it isn't interested > in. But this cannot really be avoided when you map an IPv6 address > into 48 bits or less. No. It could be avoided if (1) only the link-local ff02 addresses would be mapped (and not all scopes), (2) Group IDs in IPv6 for link-local scope would be of max length 3 bytes. But yes, this is in a fictitious IPv6 world. Alex > >> There is not enough place in there. As such reverse mapping would >> be impossible. >> >>>>> destination addresses, not other scopes. >>>>>> >>>>>> >>>>>> >>>>>> I.e. the last four octets of a _link-local_ IPv6 address >>>>>> should get >>>>> >>>>> >>>>> mapped into that MAC address (ff02::XXXX:XXXX -> >>>>> 33-33-XX-XX-XX-XX); multicast addresses of other scopes than >>>>> ff02 should not get mapped. >>>>>> >>>>>> >>>>>> >>>>> >>>>> I think you're assuming that there are no other nodes on the >>>>> link are members of the > link-local scope group, or that >>>>> there is no more than one multicast router on the link. >>>> >>>> >>>> >>>> Yes, I do assume so. >>> >>> >>> It's fairly common to have multiple multicast routers on the >>> link, and there can definitely be multiple members of a >>> link-local group (or any group) on the link. >> >> >> Yes certainly there can be multiple IP multicast routers on a link. >> But I dont see how that supports mapping a global multicast address >> into an Ethernet address. > > I don't know why it matters how many routers there are. > >>>>> Multicast address scopes are only indicating boundary of the >>>>> multicast forwarding domain, not where multicast group >>>>> members are or are not. >>>> >>>> >>>> >>>> But an Ethernet 33-33- scope can only be a link scope. A >>>> reverse >>> >>> >>> Why? >> >> >> Because the whole world is not (and can not) be Ethernet - there >> are other link types as well. As such its scope can only be >> local. > > A global scope multicast packet might be forwarded across multiple > links. On each link it traverses it will have some local link > address. So you can say the L3 address is global, while the L2 > address is just for the link. > >>> >>>> mapping from an Ethernet scope back to a > link-local scope >>>> would make no sense. >>>> >>>> (I also assume mapping to be bidirectional). >>> >>> >>> What do you mean by bidirectional? As you wrote, you cannot do a >>> reverse mapping. >> >> >> Bidirectional - map from IP address to MAC address, and >> vice-versa. 'Mapping' suggests me ability to translate and >> reversely too. >> >> Or maybe this RFC2464 'mapping' means to translate into only one >> direction? (translate an IP to MAC but not vice-versa) > > Yes, it's only in one direction. > > Stig > >> Alex >> >> >>> >>> Stig >>> >>>> Alex >>>> >>>>> >>>>> Regards, Mark. >>>>> >>>>>> Alex >>>>>> >>>>>> -------------------------------------------------------------------- >>>>>> >>>>>> >>>> >>>>>> >> >>>>>> 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 Thu Jul 21 08:58:31 2016 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A154D120727 for ; Thu, 21 Jul 2016 08:58:29 -0700 (PDT) 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_PASS=-0.001] 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 fIw8kOSyMNjy for ; Thu, 21 Jul 2016 08:58:27 -0700 (PDT) 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 6B1E612D77B for <6man@ietf.org>; Thu, 21 Jul 2016 08:58:17 -0700 (PDT) Received: from [IPv6:2001:67c:370:160:edc0:90e6:9974:4873] (unknown [IPv6:2001:67c:370:160:edc0:90e6:9974:4873]) (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 45EB482A88; Thu, 21 Jul 2016 17:58:15 +0200 (CEST) Subject: Re: proposed text for header injection revision 05 To: Brian E Carpenter , Jen Linkova , mohamed.boucadair@orange.com References: <26582.1468923195@obiwan.sandelman.ca> <2EBFA6F2-00A3-45E1-BE0E-3531AF75726A@employees.org> <787AE7BB302AE849A7480A190F8B933008DE9E22@OPEXCLILMA3.corporate.adroot.infra.ftgroup> <0445fd4c-3d96-73f5-035e-570f165faf9b@gmail.com> From: Fernando Gont X-Enigmail-Draft-Status: N1110 Message-ID: <614711c4-9e69-3ddc-67f2-0d20394169ad@si6networks.com> Date: Thu, 21 Jul 2016 17:58:04 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.2.0 MIME-Version: 1.0 In-Reply-To: <0445fd4c-3d96-73f5-035e-570f165faf9b@gmail.com> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Archived-At: Cc: Michael Richardson , "6man@ietf.org" <6man@ietf.org>, "Mark Townsley \(townsley\)" X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.17 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 Jul 2016 15:58:29 -0000 On 07/21/2016 10:47 AM, Brian E Carpenter wrote: > On 21/07/2016 20:02, Jen Linkova wrote: >> On Wed, Jul 20, 2016 at 6:06 PM, wrote: >>> Hi Ole, all, >>> >>> I'm for removing that text as it does not add any recommendation at all. >> >> Seconded. I can not see what we are trying to achieve by having that >> second paragraph. It does not add any value and should be removed. > > So, can we go back to the version at > https://tools.ietf.org/html/draft-ietf-6man-rfc2460bis-01#page-7 > which does add value? > > Again: that second paragraph is part of a compromise between those who want > to explicitly forbid any insertion of headers and those who don't. Remove > it and you break the compromise. What I wonder, in all of this discussion, if whether such "compromise" is really a comprimise. My take boils down to these three questions, which I have asked, but never got an answer: 1) Is a router that inserts an EH compliant with RFC2460? (yes/no) 2) Is a router that inserts an EH compliant with RFC2460bis? (yes/no) 3) If the response to #1 and #2 match, please make that clear. If they don't, please make it clear that you're changing the spec. P.S.: The errata I filed for RFC2460 implicitly begs that these questions be answered. FWIW, me, I don't care about the specific outcome, but rather about #3 above being acted upon. Thanks, -- Fernando Gont SI6 Networks e-mail: fgont@si6networks.com PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492 From nobody Thu Jul 21 09:21:30 2016 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 32C9512D50E for ; Thu, 21 Jul 2016 09:21:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.45 X-Spam-Level: X-Spam-Status: No, score=-2.45 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_ENVFROM_END_DIGIT=0.25, 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 R6BrRfTmHawZ for ; Thu, 21 Jul 2016 09:21:27 -0700 (PDT) Received: from mail-io0-x22a.google.com (mail-io0-x22a.google.com [IPv6:2607:f8b0:4001:c06::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 56D0B12D0EA for <6man@ietf.org>; Thu, 21 Jul 2016 09:21:27 -0700 (PDT) Received: by mail-io0-x22a.google.com with SMTP id q83so80839315iod.1 for <6man@ietf.org>; Thu, 21 Jul 2016 09:21: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=OpkW7zVYQLZ6StMKYroPC1y4ti5a6ZSYhYMkpMQuBYQ=; b=PVRYjz3b7GOGh/9FjNqNFrobAgEL4/ZHB1j/3MkOrLHIokONS1oTzLQVzci1SwacYB EDe03qMrRYBikzhMbyt174Z+2UsS7gumJ1q895odGVDOeS1J/5mFm+v8qfMCJGn0afcO y3oNXI5KoPoxSc43+zXydoKXgbushQ044644F36SOx1/eOkXzGzloMyYyn1bc73dSr7e mPJrPN3Fcy0FabyYzYBMklfJ4BSVuemYM+/ApQ7NJ5/o3/gzxnLWBRY8SVWTPUOSHJ9T mhXqRoLFJ1geWoYnlJ5b2U3AtAgSl0PInY9ULhxUf+Bn0IW9B/WxwkWhI9/csLmFqNkV WvOw== 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=OpkW7zVYQLZ6StMKYroPC1y4ti5a6ZSYhYMkpMQuBYQ=; b=ZaTz33Ei2XE5AXMVXQmfHcR4/tcpPaEaZlnQedzo+yjqeVdFW32b3GqEg/4mQfQNSn hP6y1YYM47MHbg/2wXcjFl7eb5+jLxB4Lb+KWLzHZURqg2x260238Cuqd8O/o+2o8sHT PMy2Ea3e+JRbH7Rg3Qi9ufgeGkdNaiKgVuBM2ts6kEg8WCgnxztD84RYQySMSy4EWuOi wfP2TdXQK8ddE5Dmi5+yi5pWVqdsubl4GkJ2ATQ7rFfG71BNBupeDismaobxHDtebKSZ FJVf1s7Qr1GQsHJ0eosak6sSylvhbOqHgGTDuu8XmxB4U31lqKPVEA7BOY8V1UzlUeoq DSyw== X-Gm-Message-State: ALyK8tLMqXozAdsxCpiUcVqs997LHTvq/1lUgjGaxwLfe5yyyH/DXQhd+wrP/CDy3uWwnDpRqQJ+E6ppyE1bjA== X-Received: by 10.107.189.6 with SMTP id n6mr3613983iof.72.1469118086589; Thu, 21 Jul 2016 09:21:26 -0700 (PDT) MIME-Version: 1.0 Received: by 10.64.187.37 with HTTP; Thu, 21 Jul 2016 09:21:07 -0700 (PDT) In-Reply-To: References: <26582.1468923195@obiwan.sandelman.ca> <2EBFA6F2-00A3-45E1-BE0E-3531AF75726A@employees.org> <787AE7BB302AE849A7480A190F8B933008DE9E22@OPEXCLILMA3.corporate.adroot.infra.ftgroup> From: Jen Linkova Date: Thu, 21 Jul 2016 18:21:07 +0200 Message-ID: Subject: Re: proposed text for header injection revision 05 To: Ole Troan Content-Type: text/plain; charset=UTF-8 Archived-At: Cc: Michael Richardson , "6man@ietf.org" <6man@ietf.org>, "Mark Townsley \(townsley\)" X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.17 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 Jul 2016 16:21:29 -0000 On Thu, Jul 21, 2016 at 10:33 AM, wrote: > Not to pick on you, but can you pretend to represent the people who want the second paragraph removed for a little while? I'll try to ;) > The below text represents a compromise between those who want an outright prohibition on inserting / modifying / deleting extension headers and those who want to leave the current 2460 ambiguity ambiguous. > > The compromise is quite a balancing act. From what I heard during the meeting and on this thread, it does not seem like we will achieve consensus on text without the second paragraph. > > I'm fine with you being unhappy with the below text. :-) > But can you _live_ with it? Well, I'm not sure how that second paragraph represents a compromise as it juts says 'one possible way to do it is to encapsulate' (so I was thinking that we should not add any text which does not add much value. However after thinking about it for a while I think I'm quite happy with it as I read it as 'you *can* insert headers - for example by doing encapsulation or somehow else..' So, disregard my previous statement ;) > And if not, why not? Does it break interoperability, does it prohibit future work in this space? As long as we do explicitly prohibit inserting/modifying - I'm fine with it. Actually I like the recent version (which says 'One approach' instead of 'Current approach'). The only comment: it is not clear if the first paragraph talks about ICMP packet too big only or about sending ICMP back to host (e.g. "destination unreachable') in general. Do you think it would make sense to rephrase it slightly: "The insertion of Extension Headers by any node other than the source of the packet can break PMTU-discovery. If ICMPv6 messages (error or informational, such as "packet too big" or "echo reply" etc) sent to the source of the packet that did not insert the header, the source host might not be able to recognize/parse it correctly". What I'm trying to say, there is not just PMTUD problem which needs to be kept in mind while inserting EHs, but generating ICMP in general (traceroute/ping/etc). > > > =========== > The insertion of Extension Headers by any node other than the source > of the packet breaks PMTU-discovery and can result in ICMP error > messages being sent to the source of the packet that did not insert > the header. > > One approach to inserting Extension Headers by a node other than the source of the packet > is to encapsulate the packet using a new IPv6 header and including the additional > Extension Headers as specified in section 3.1 of RFC2473. > =========== > > > > Best regards, > Ole -- SY, Jen Linkova aka Furry From nobody Thu Jul 21 09:39:19 2016 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 64F6612D76B for ; Thu, 21 Jul 2016 09:39:17 -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 OSL9uRnPCq-m for ; Thu, 21 Jul 2016 09:39:04 -0700 (PDT) Received: from mail-lf0-x22f.google.com (mail-lf0-x22f.google.com [IPv6:2a00:1450:4010:c07::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 7C9F412D7BB for <6man@ietf.org>; Thu, 21 Jul 2016 09:39:01 -0700 (PDT) Received: by mail-lf0-x22f.google.com with SMTP id g62so66694753lfe.3 for <6man@ietf.org>; Thu, 21 Jul 2016 09:39:01 -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=xRgWx42gqCKQHetu5/bct6KN0NrJdJFEp36PNYcY6ws=; b=kr4YAW8ZecnOSg5czcF+wTWrgL21SSjPe3S4dTM3gCBWdyofGX5WwFHESohmRKtgH+ m8dKTfzesev8ePYQHNCf8+7G5yWztZhkfiRpZJEKZGPLNKMK+aTM5ewqKxdou2e0R9iz 3W6it1tIx8mZapZ98UT7/j1hFw0N+D9tbvMHN8FeK1mBXFO6erNvcov1+KEddpMEVxPs HTg9JQeaNzp8BCErFK8JJDyy1FgGBTAp6jUvgovh1HjGSKxFjBYIImy3CimW+DcTEOIs /6y5IVONuZ6O+q1MdgmlS9eGIRVwQ+iGv84GdxtLqoJ3OkNyJlLIhPjHjg9gy3oEQ5Km AUAw== 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=xRgWx42gqCKQHetu5/bct6KN0NrJdJFEp36PNYcY6ws=; b=h0ys/g+u2k1GhC+rqOg4ArsQlxlsE5wXu1Kyt8FqUooS06hQ3qV4t9Kwl6I2kB+OMS KDMaZExz+MnPORbsNknQrqbSk5xwU8DH/+8tMnli0AAFgYykVcWizfSJWWMl2wuCYb5w LBYUmuXtzKIZvVg6sF4WzOZUf3biVzc+mpgWAuqiq2/d7ak2Rm3QVS7eKejP3OMREcmq sarWrBnxLmp81o2rUuPaRuH5ojlvT9w1w+sZEvVF28MLqlcUQnDbrvaKA80R/va1IPJ2 0yNp+/nYTN29KFjdtlrkoovFf+L4setDw1nYtxnNn+Oz9dVzgh0b1TnMunZRrzv7gB6f HYwg== X-Gm-Message-State: ALyK8tLOtzCBtL1aFQ+RjMZQvZHqeq8DbGvW+PUFZI4lllxFP0okY6nEiqsoG9F+uIpTuQ== X-Received: by 10.25.24.153 with SMTP id 25mr23352420lfy.103.1469119139569; Thu, 21 Jul 2016 09:38:59 -0700 (PDT) Received: from ?IPv6:2001:67c:370:136:28cc:dc4c:9703:6781? ([2001:67c:370:136:28cc:dc4c:9703:6781]) by smtp.gmail.com with ESMTPSA id o10sm2032367lfo.47.2016.07.21.09.38.57 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 21 Jul 2016 09:38:58 -0700 (PDT) Subject: Re: proposed text for header injection revision 05 To: Fernando Gont , Jen Linkova , mohamed.boucadair@orange.com References: <26582.1468923195@obiwan.sandelman.ca> <2EBFA6F2-00A3-45E1-BE0E-3531AF75726A@employees.org> <787AE7BB302AE849A7480A190F8B933008DE9E22@OPEXCLILMA3.corporate.adroot.infra.ftgroup> <0445fd4c-3d96-73f5-035e-570f165faf9b@gmail.com> <614711c4-9e69-3ddc-67f2-0d20394169ad@si6networks.com> From: Brian E Carpenter Organization: University of Auckland Message-ID: Date: Fri, 22 Jul 2016 04:39:04 +1200 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.2.0 MIME-Version: 1.0 In-Reply-To: <614711c4-9e69-3ddc-67f2-0d20394169ad@si6networks.com> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Archived-At: Cc: Michael Richardson , "6man@ietf.org" <6man@ietf.org>, "Mark Townsley \(townsley\)" X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.17 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 Jul 2016 16:39:17 -0000 Fernando, I understand your frustration but this is where we are:... On 22/07/2016 03:58, Fernando Gont wrote: > On 07/21/2016 10:47 AM, Brian E Carpenter wrote: >> On 21/07/2016 20:02, Jen Linkova wrote: >>> On Wed, Jul 20, 2016 at 6:06 PM, wrote: >>>> Hi Ole, all, >>>> >>>> I'm for removing that text as it does not add any recommendation at all. >>> >>> Seconded. I can not see what we are trying to achieve by having that >>> second paragraph. It does not add any value and should be removed. >> >> So, can we go back to the version at >> https://tools.ietf.org/html/draft-ietf-6man-rfc2460bis-01#page-7 >> which does add value? >> >> Again: that second paragraph is part of a compromise between those who want >> to explicitly forbid any insertion of headers and those who don't. Remove >> it and you break the compromise. > > What I wonder, in all of this discussion, if whether such "compromise" > is really a comprimise. > > My take boils down to these three questions, which I have asked, but > never got an answer: > > 1) Is a router that inserts an EH compliant with RFC2460? (yes/no) Some people say Yes. Some people say No. > 2) Is a router that inserts an EH compliant with RFC2460bis? (yes/no) Some people say Yes. Some people say No. > 3) If the response to #1 and #2 match, please make that clear. If they > don't, please make it clear that you're changing the spec. We aren't changing it in the compromise proposal, i.e. we are leaving it undecided. IMHO, Brian > > P.S.: The errata I filed for RFC2460 implicitly begs that these > questions be answered. FWIW, me, I don't care about the specific > outcome, but rather about #3 above being acted upon. > > Thanks, > From nobody Thu Jul 21 11:56:44 2016 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 27D8E12D83C for ; Thu, 21 Jul 2016 11:56:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.566 X-Spam-Level: X-Spam-Status: No, score=-0.566 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_SORBS_WEB=0.77, SPF_HELO_PASS=-0.001, SPF_SOFTFAIL=0.665] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=employees.org; domainkeys=pass (1024-bit key) header.from=otroan@employees.org header.d=employees.org 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 mh0ryHmgsj-W for ; Thu, 21 Jul 2016 11:56:41 -0700 (PDT) Received: from incoming.kjsl.com (inbound02.kjsl.com [IPv6:2001:1868:2002::144]) (using TLSv1.2 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 24F3512D83B for <6man@ietf.org>; Thu, 21 Jul 2016 11:56:40 -0700 (PDT) Received: from cowbell.employees.org ([65.50.211.142]) by ironport02.kjsl.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 21 Jul 2016 18:56:38 +0000 Received: from cowbell.employees.org (localhost [127.0.0.1]) by cowbell.employees.org (Postfix) with ESMTP id 5E46C9CC4F; Thu, 21 Jul 2016 11:56:37 -0700 (PDT) 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=h7ioh4V2uLkDYP5UncAmXLM6cA4=; b= Q1sUhlTzAMojhvVrIpjy2UfxvF1fKKYrOKDd4OocmC9SeNv+2idXc+vck2TDK0cH zOkvqMsCyk6FLQARPxqk6egybmN7Ps+mPgCh/0pw0Mm1fHCDrtgiVFLLSBZqFZtS MiIYrhyVhTNRgetSAyxJDPn2KcBnoB6PAa74BKOnAI4= 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=XsRDEZkteNbDgdCrSjUq+FbQ+o zFPGPgi1JkLlfT7jFzcCCXF+1esTjf2mr3L6X7nBf88yNJfR/QmwW61Vc7dbCKUo PsxsUMLDEa2qc+LVdEWbMBk+zHYGjpTD5anUsUHmd+XANcIRB/+QnZEghD2m+JvQ 0e3NRiTBJgt5T4fjU= Received: from h.hanazo.no (2.150.16.190.tmi.telenormobil.no [2.150.16.190]) (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 69FD09CC4E; Thu, 21 Jul 2016 11:56:36 -0700 (PDT) Received: from [IPv6:::1] (localhost [IPv6:::1]) by h.hanazo.no (Postfix) with ESMTP id D864E2BD1445; Thu, 21 Jul 2016 20:56:28 +0200 (CEST) Subject: Re: proposed text for header injection revision 05 Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) Content-Type: multipart/signed; boundary="Apple-Mail=_B6831629-83EB-47CC-ABAF-C49DB00A9041"; protocol="application/pgp-signature"; micalg=pgp-sha512 X-Pgp-Agent: GPGMail From: otroan@employees.org In-Reply-To: Date: Thu, 21 Jul 2016 20:56:28 +0200 Message-Id: <38D9248F-A52E-4FED-BEE6-0A89CCD7623B@employees.org> References: <26582.1468923195@obiwan.sandelman.ca> <2EBFA6F2-00A3-45E1-BE0E-3531AF75726A@employees.org> <787AE7BB302AE849A7480A190F8B933008DE9E22@OPEXCLILMA3.corporate.adroot.infra.ftgroup> To: Jen Linkova X-Mailer: Apple Mail (2.3124) Archived-At: Cc: Michael Richardson , "6man@ietf.org" <6man@ietf.org>, "Mark Townsley \(townsley\)" X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.17 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 Jul 2016 18:56:43 -0000 --Apple-Mail=_B6831629-83EB-47CC-ABAF-C49DB00A9041 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Jen, [...] >> And if not, why not? Does it break interoperability, does it prohibit = future work in this space? >=20 > As long as we do explicitly prohibit inserting/modifying - I'm fine = with it. s/do/don't?? > Actually I like the recent version (which says 'One approach' instead > of 'Current approach'). > The only comment: it is not clear if the first paragraph talks about > ICMP packet too big only or about sending ICMP > back to host (e.g. "destination unreachable') in general. Do you think > it would make sense to rephrase it slightly: it was meant as an _and_. both PMTUD and ICMP error messages break. it is not an exhaustive list though, e.g. AH would also break. ICMP Echo would probably work though. cheers, Ole >=20 > "The insertion of Extension Headers by any node other than the source > of the packet can break PMTU-discovery. If ICMPv6 messages (error or > informational, > such as "packet too big" or "echo reply" etc) sent to the source of > the packet that did not insert > the header, the source host might not be able to recognize/parse it > correctly". >=20 > What I'm trying to say, there is not just PMTUD problem which needs to > be kept in mind while inserting EHs, > but generating ICMP in general (traceroute/ping/etc). >=20 >>=20 >>=20 >> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D >> The insertion of Extension Headers by any node other than the = source >> of the packet breaks PMTU-discovery and can result in ICMP error >> messages being sent to the source of the packet that did not insert >> the header. >>=20 >> One approach to inserting Extension Headers by a node other than = the source of the packet >> is to encapsulate the packet using a new IPv6 header and including = the additional >> Extension Headers as specified in section 3.1 of RFC2473. >> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D >>=20 >>=20 >>=20 >> Best regards, >> Ole >=20 >=20 >=20 > -- > SY, Jen Linkova aka Furry --Apple-Mail=_B6831629-83EB-47CC-ABAF-C49DB00A9041 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 iQEcBAEBCgAGBQJXkRrcAAoJED4aXnjSQuKWpegH/AwZ/ZpLbdZl53ivabqGJnMQ hmmV1l9oio9z2u0Awv3Oq4dNHZAWtsY5Vnl9esrK3ediE1n+2bc7VPDbLFbkGSRY ToT8SrHzlTX3VPqNUhAr7VJGnH0rP+P+/AKDXPXPyz/2wD2zBrdWdV/V2PSXGTNV ri/mBkvHa5Wcj3X/OBp3CHSHXGqDqmS5ZWOGQmZBjct2VnKUZFvt+hU2MIVJMCYK b28joGIJ+hymSqJGf1KgcgUHRZQLRa+TnXoEFhbKfjtj/5l6CN1w2QG6yiLJl5eM AIbbl0xYFHFfgkqUbcLq820YQRP9uR+5qXUS1fH//3m17hQHNo4Ak6KXch4Q8+s= =Akqd -----END PGP SIGNATURE----- --Apple-Mail=_B6831629-83EB-47CC-ABAF-C49DB00A9041-- From nobody Thu Jul 21 15:53:22 2016 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5F8DA12D89B for ; Thu, 21 Jul 2016 15:53:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.45 X-Spam-Level: X-Spam-Status: No, score=-2.45 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_ENVFROM_END_DIGIT=0.25, 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 WC4CdR3RQgxn for ; Thu, 21 Jul 2016 15:53:18 -0700 (PDT) Received: from mail-io0-x22f.google.com (mail-io0-x22f.google.com [IPv6:2607:f8b0:4001:c06::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 B809B12B010 for <6man@ietf.org>; Thu, 21 Jul 2016 15:53:18 -0700 (PDT) Received: by mail-io0-x22f.google.com with SMTP id q83so89875609iod.1 for <6man@ietf.org>; Thu, 21 Jul 2016 15:53:18 -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=2uMN7SeVfVXCOCiefIxkws5ZSH6NUa1CgNC5EUcN+9s=; b=DhqvahdsOVWFFbxrqwVAfRF9+LTtR3wmYKHQuIBr/pZz5/6fOuy6q2Xd1J4hN8BL10 PI1YOVO76ulzstI+p22tQ77RZSQZLI9U0eBaBGaeZ14nRplfNR/zavIA+1dgSC04iiVG O0qmQzYmP1ql7x+2me7EnLI3N3nznhYLXGjWbhu1zjTsTzcgAVFlTJTWV4jH0MxX+fK9 n4xYRutm7L/MEEUAVpv4cIlh7mRuupGv1yCpmYLj/XluhYWqtBhqHFSkyHfxOecyE8fR DYjcV3cjum7qiSUQNJ/DaAS0911yrsw1R4ebpZijLYvppis8UcE2d2VRvoDfXkX6RdAJ ESlw== 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=2uMN7SeVfVXCOCiefIxkws5ZSH6NUa1CgNC5EUcN+9s=; b=X7rAp1OxoK0Qf28fMVRA3btGJdWtHm/UO34nI50LftBls7pFlk5CMhA2yNTzP03Bpr iPpXPcmNXL4xZATuoVnT5CGAQ9DgJ26lFOE2qkZ85gJ0FA2v66SLk4kmxBGzhhA3TVcM pyJUyVIxnUNU8sMpGWkpVcvGvzLdj8N9SFRLEbc3OqOdl7A6IRg9fPPH9dm3JDvn44Wm XLNv3k+AjgkS0CbKKgCZSukjoVb+xTE1DEKngHOxNuTwJH4WUWpDDpRESJ4vlRL32zLb yGFWi4mqpmJSMx8y4ylLuGc85qywflv0jTueHUd9MuF1AF0bLQZRvzFyBSzBohN0jDfh jvzg== X-Gm-Message-State: AEkooutU+bqgNuq30tycYU62IM1YX9gXcXUKfkjjLoqJBIV/NkLfbuD+gaQcTNX76j9C7CKBH0y5NCyF3tcPsQ== X-Received: by 10.107.170.13 with SMTP id t13mr1005369ioe.2.1469141597958; Thu, 21 Jul 2016 15:53:17 -0700 (PDT) MIME-Version: 1.0 Received: by 10.64.187.37 with HTTP; Thu, 21 Jul 2016 15:52:58 -0700 (PDT) In-Reply-To: <38D9248F-A52E-4FED-BEE6-0A89CCD7623B@employees.org> References: <26582.1468923195@obiwan.sandelman.ca> <2EBFA6F2-00A3-45E1-BE0E-3531AF75726A@employees.org> <787AE7BB302AE849A7480A190F8B933008DE9E22@OPEXCLILMA3.corporate.adroot.infra.ftgroup> <38D9248F-A52E-4FED-BEE6-0A89CCD7623B@employees.org> From: Jen Linkova Date: Fri, 22 Jul 2016 00:52:58 +0200 Message-ID: Subject: Re: proposed text for header injection revision 05 To: Ole Troan Content-Type: text/plain; charset=UTF-8 Archived-At: Cc: Michael Richardson , "6man@ietf.org" <6man@ietf.org>, "Mark Townsley \(townsley\)" X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.17 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 Jul 2016 22:53:20 -0000 Ole, On Thu, Jul 21, 2016 at 8:56 PM, wrote: >> As long as we do explicitly prohibit inserting/modifying - I'm fine with it. > > s/do/don't?? Isn't it great when people can read your mind? ;) I mean "don't" indeed, thanks for correction! >> The only comment: it is not clear if the first paragraph talks about >> ICMP packet too big only or about sending ICMP >> back to host (e.g. "destination unreachable') in general. Do you think >> it would make sense to rephrase it slightly: > > it was meant as an _and_. both PMTUD and ICMP error messages break. > it is not an exhaustive list though, e.g. AH would also break. Ah, OK. It was not very clear (IMHO) but it might be just me.. > ICMP Echo would probably work though. Yeah, you are right, I stand corrected. -- SY, Jen Linkova aka Furry From nobody Thu Jul 21 17:18:15 2016 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 35D7412DAF5 for ; Thu, 21 Jul 2016 17:18:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.987 X-Spam-Level: X-Spam-Status: No, score=-3.987 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, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-1.287, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=pobox.com; domainkeys=pass (1024-bit key) header.from=heard@pobox.com header.d=pobox.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 PT9yuhrLUvpI for ; Thu, 21 Jul 2016 17:18:12 -0700 (PDT) Received: from sasl.smtp.pobox.com (pb-smtp2.pobox.com [64.147.108.71]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2601412DB0D for ; Thu, 21 Jul 2016 17:18:10 -0700 (PDT) Received: from sasl.smtp.pobox.com (unknown [127.0.0.1]) by pb-smtp2.pobox.com (Postfix) with ESMTP id 310CE2E087 for ; Thu, 21 Jul 2016 20:18:05 -0400 (EDT) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=pobox.com; h=mime-version :from:date:message-id:subject:to:content-type; s=sasl; bh=BawLqL kLaYHwwSLN5/565FvO7NQ=; b=a1gQGfUIRP3+X6bqYYw5OJDxAO5ujDRMjqMEBD bzD9GNX+wB+FEJfGxqt0kH8kLDy8m9cYYCMYKAh1gC9C4tJRUZONKCfNQkVJ4/sN xc+69KNBLJwZcXX5r95TDPH3lnEhiDparE3tjKcfOjZrszGEqvCCS1mg1WG9z/Iq R8HWA= DomainKey-Signature: a=rsa-sha1; c=nofws; d=pobox.com; h=mime-version :from:date:message-id:subject:to:content-type; q=dns; s=sasl; b= N9PV6+0H9PKucVz8ptarYbtYnmk3GLNrY1P+nFj5pIX7NE2odjU94MzQIuTKfmWf 8QqhqpKWmM4o6p+4q3BJszI6H2PCkLrn3MROkb+J1FjLeG/gu2n1DlhF5VtwICen JPN/GCwWINPFy8lwG9vsEVHVMqZtydvDCzV8Ay8MsGE= Received: from pb-smtp2.nyi.icgroup.com (unknown [127.0.0.1]) by pb-smtp2.pobox.com (Postfix) with ESMTP id 1C73A2E086 for ; Thu, 21 Jul 2016 20:18:05 -0400 (EDT) Received: from mail-vk0-f53.google.com (unknown [209.85.213.53]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by pb-smtp2.pobox.com (Postfix) with ESMTPSA id D47FA2E085 for ; Thu, 21 Jul 2016 20:18:03 -0400 (EDT) Received: by mail-vk0-f53.google.com with SMTP id s189so136045762vkh.1 for ; Thu, 21 Jul 2016 17:18:03 -0700 (PDT) X-Gm-Message-State: AEkoousZiTOEm0bGWa5euuG6Pmv7pDFL/moTHGCCZ9AIE9Vl27uc73IkEO/n42cz5zXKl5+vKSQSijQTV7Grzg== X-Received: by 10.31.194.19 with SMTP id s19mr428361vkf.126.1469146683411; Thu, 21 Jul 2016 17:18:03 -0700 (PDT) MIME-Version: 1.0 Received: by 10.31.130.207 with HTTP; Thu, 21 Jul 2016 17:17:44 -0700 (PDT) From: "C. M. Heard" Date: Thu, 21 Jul 2016 17:17:44 -0700 X-Gmail-Original-Message-ID: Message-ID: Subject: Re: proposed text for header injection revision 05 To: 6man WG Content-Type: multipart/alternative; boundary=001a1143179e301b9905382e5e5b X-Pobox-Relay-ID: C1A954A8-4FA1-11E6-AEE2-EE617A1B28F4-06080547!pb-smtp2.pobox.com Archived-At: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.17 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 Jul 2016 00:18:13 -0000 --001a1143179e301b9905382e5e5b Content-Type: text/plain; charset=UTF-8 Hello everyone, I will probably get splattered with dead cats and rotten tomatoes for saying this, but if the only way that consensus can be achieved on 2460bis is to leave it ambiguous, then it's just not ready to be an Internet Standard. If I were on the IESG and a spec that came to me with a known ambiguity, I would vote to send it back to the WG with instructions to resubmit it after the ambiguity was fixed. I think it's clear, if not actually obvious, that the original intent of 2460 was that no intermediate IPv6 node would change the length of an IP datagram. If that's the correct technical approach, then let's say so explicitly in 2460 bis, and then we can advance it to IS. If that's not the correct technical approach, then let's change the rule and stay at PS. Mike Heard --001a1143179e301b9905382e5e5b Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hello everyone,

I will probably get spl= attered with dead cats and rotten tomatoes for saying this, but if the only= way that consensus can be achieved on 2460bis is to leave it ambiguous, th= en it's just not ready to be an Internet Standard. If I were on the IES= G and a spec that came to me with a known ambiguity, I would vote to send i= t back to the WG with instructions to resubmit it after the ambiguity was f= ixed.

I think it's clear, if not actually obvi= ous, that the original intent of 2460 was that no intermediate IPv6 node wo= uld change the length of an IP datagram. If that's the correct technica= l approach, then let's say so explicitly in 2460 bis, and then we can a= dvance it to IS. If that's not the correct technical approach, then let= 's change the rule and stay at PS.

Mike Heard<= /div>
--001a1143179e301b9905382e5e5b-- From nobody Thu Jul 21 22:35:29 2016 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 49DA012DF2C for ; Thu, 21 Jul 2016 22:35:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -8.188 X-Spam-Level: X-Spam-Status: No, score=-8.188 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-1.287, SPF_PASS=-0.001] 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 IyZb2BAl0baK for ; Thu, 21 Jul 2016 22:35:27 -0700 (PDT) Received: from mx.pao1.isc.org (mx.pao1.isc.org [149.20.64.53]) (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 171D512DF2B for <6man@ietf.org>; Thu, 21 Jul 2016 22:35:26 -0700 (PDT) Received: from zmx1.isc.org (zmx1.isc.org [149.20.0.20]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mx.pao1.isc.org (Postfix) with ESMTPS id 3F1673493A5 for <6man@ietf.org>; Fri, 22 Jul 2016 05:35:25 +0000 (UTC) Received: from zmx1.isc.org (localhost [127.0.0.1]) by zmx1.isc.org (Postfix) with ESMTPS id 2F21D16003E for <6man@ietf.org>; Fri, 22 Jul 2016 05:35:25 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by zmx1.isc.org (Postfix) with ESMTP id 17403160043 for <6man@ietf.org>; Fri, 22 Jul 2016 05:35:25 +0000 (UTC) Received: from zmx1.isc.org ([127.0.0.1]) by localhost (zmx1.isc.org [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id Ljniu8GonneC for <6man@ietf.org>; Fri, 22 Jul 2016 05:35:25 +0000 (UTC) Received: from rock.dv.isc.org (p4FC080C4.dip0.t-ipconnect.de [79.192.128.196]) by zmx1.isc.org (Postfix) with ESMTPSA id BA37916003E for <6man@ietf.org>; Fri, 22 Jul 2016 05:35:24 +0000 (UTC) Received: from rock.dv.isc.org (localhost [IPv6:::1]) by rock.dv.isc.org (Postfix) with ESMTP id E90564F26BC8 for <6man@ietf.org>; Fri, 22 Jul 2016 15:35:22 +1000 (EST) To: 6man@ietf.org From: Mark Andrews Subject: IPV6_USE_MIN_MTU and TCP Date: Fri, 22 Jul 2016 15:35:22 +1000 Message-Id: <20160722053522.E90564F26BC8@rock.dv.isc.org> Archived-At: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.17 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 Jul 2016 05:35:28 -0000 What does this list believe the advertised MSS should be on a TCP connection if IPV6_USE_MIN_MTU=1 has been set on a socket? What does this list believe the transmitted TCP segment size should be on a TCP connection if IPV6_USE_MIN_MTU=1 has been set on a socket? This covers the inbound and outbound paths. Mark -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka@isc.org From nobody Fri Jul 22 00:08:45 2016 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3CD2712D9FD for ; Fri, 22 Jul 2016 00:08:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-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 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 mmzX777YnNvt for ; Fri, 22 Jul 2016 00:08:42 -0700 (PDT) Received: from mail-wm0-x229.google.com (mail-wm0-x229.google.com [IPv6:2a00:1450:400c:c09::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 D70D412D918 for ; Fri, 22 Jul 2016 00:08:39 -0700 (PDT) Received: by mail-wm0-x229.google.com with SMTP id q128so45127994wma.1 for ; Fri, 22 Jul 2016 00:08:39 -0700 (PDT) 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-transfer-encoding; bh=m0ZcHQ0z+AvkUAd2a8mqx0ZzB4ofYBc351V1ycDCIUw=; b=Qjh2GcYTbcn6cq4/NL/S+DZRpHnwHTYjctTG/klieyBtaOjlHViiDg/laCtZNE5pRt AqZD4l8tyMPx8f6ABGaK/lm7O1G33quY3LQPl6JkR+gKzplwcVTbFgh5udtdi4bkh8ub ApHOc6hatuWkIY8sTPKari8YgKamXGeUxnL7wIggJNtX8aUr7Y2d4tZRt9fEbJLjezXe 8v0cvHW5nawyqyk2INMjMqrkixqs1ATw5GN5u6837VSB/4PMlnl13cVVPRBaPMrB6tQI 6WYvuoQkYHjrLPi+UwxX4M/z+DjgzLuFhu1cAlAdA4/oB/sgAYFtYr0fC5jOliIJoyPG dgFg== 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-transfer-encoding; bh=m0ZcHQ0z+AvkUAd2a8mqx0ZzB4ofYBc351V1ycDCIUw=; b=SFA/6CQmJUfe7Mq3CLnHak+sWizboSLocM44u3f9WqUZn1RJDpUMl+AeAMWWoz2nzr UjC8H45+2g9FyEywz3vfNYT8ne5mw1ovhLVvJPhONFE5UjKw+XOXucGAjO7RtfBVW4lF a8tUKeA0x/OFHbdMqOXKo0T7H/gm79R09XyoRcuReZD8PagPjbYCWlSP0tTCE1W7CNvp YUJxkiBLtlAdPiZ19s2C7ZnH7gAVBu8YUJ14mVwsC3V8WVE0OTjmCUq/7UaFI2oAeuE6 TzDJREHuPx8xcAVsw0qHVJOjlFRTy9pZcEoQ60a/g+5Phcfr4W/ubqsQOu4xddjh6l9M kLBA== X-Gm-Message-State: AEkoous0YW9UeXzLlXoQwfwaaki30OkckrOLUUfUp2t0vE0OpvbfwkvrTqSBISY6yxq9zQ== X-Received: by 10.28.60.136 with SMTP id j130mr3562414wma.93.1469171318218; Fri, 22 Jul 2016 00:08:38 -0700 (PDT) Received: from ?IPv6:2001:67c:370:176:28cc:dc4c:9703:6781? ([2001:67c:370:176:28cc:dc4c:9703:6781]) by smtp.gmail.com with ESMTPSA id a21sm10757457wma.10.2016.07.22.00.08.37 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 22 Jul 2016 00:08:37 -0700 (PDT) Subject: Re: proposed text for header injection revision 05 To: "C. M. Heard" , 6man WG References: From: Brian E Carpenter Organization: University of Auckland Message-ID: <12a0c21d-662c-a45a-aaa4-25d929739c85@gmail.com> Date: Fri, 22 Jul 2016 19:08:46 +1200 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.2.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.17 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 Jul 2016 07:08:44 -0000 On 22/07/2016 12:17, C. M. Heard wrote: > Hello everyone, > > I will probably get splattered with dead cats and rotten tomatoes for > saying this, but if the only way that consensus can be achieved on 2460bis > is to leave it ambiguous, then it's just not ready to be an Internet > Standard. If I were on the IESG and a spec that came to me with a known > ambiguity, I would vote to send it back to the WG with instructions to > resubmit it after the ambiguity was fixed. That is the risk in a compromise, of course. Perhaps we should ask for guidance from the AD. > I think it's clear, if not actually obvious, that the original intent of > 2460 was that no intermediate IPv6 node would change the length of an IP > datagram. I am certain of that, from the extract from meeting minutes that I cited some weeks ago. And of course IPsec also limits what you can change. Brian > If that's the correct technical approach, then let's say so > explicitly in 2460 bis, and then we can advance it to IS. If that's not the > correct technical approach, then let's change the rule and stay at PS. > > Mike Heard > > > > -------------------------------------------------------------------- > IETF IPv6 working group mailing list > ipv6@ietf.org > Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 > -------------------------------------------------------------------- > From nobody Fri Jul 22 00:12:52 2016 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A69BF12DA04 for ; Fri, 22 Jul 2016 00:12:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.188 X-Spam-Level: X-Spam-Status: No, score=-3.188 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-1.287, SPF_PASS=-0.001] 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 P90X0m6ap5Jx for ; Fri, 22 Jul 2016 00:12:49 -0700 (PDT) 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 03C0012D9FD for <6man@ietf.org>; Fri, 22 Jul 2016 00:12:48 -0700 (PDT) Received: from sandelman.ca (obiwan.sandelman.ca [209.87.249.21]) by tuna.sandelman.ca (Postfix) with ESMTP id C61DF200A5 for <6man@ietf.org>; Fri, 22 Jul 2016 03:22:21 -0400 (EDT) Received: from obiwan.sandelman.ca (localhost [IPv6:::1]) by sandelman.ca (Postfix) with ESMTP id B5243638BE for <6man@ietf.org>; Fri, 22 Jul 2016 03:12:44 -0400 (EDT) From: Michael Richardson To: "6man\@ietf.org" <6man@ietf.org> Subject: Re: proposed text for header injection revision 05 In-Reply-To: References: <26582.1468923195@obiwan.sandelman.ca> <2EBFA6F2-00A3-45E1-BE0E-3531AF75726A@employees.org> <787AE7BB302AE849A7480A190F8B933008DE9E22@OPEXCLILMA3.corporate.adroot.infra.ftgroup> X-Mailer: MH-E 8.6; nmh 1.6+dev; GNU Emacs 24.5.1 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.17 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 Jul 2016 07:12:50 -0000 --=-=-= Content-Type: text/plain Jen Linkova wrote: > As long as we do explicitly prohibit inserting/modifying - I'm fine with > it. Actually I like the recent version (which says 'One approach' instead > of 'Current approach'). The only comment: it is not clear if the first > paragraph talks about ICMP packet too big only or about sending ICMP back > to host (e.g. "destination unreachable') in general. Do you think it would An interpretation I heard in the hallway.: > "The insertion of Extension Headers by any node other than the source of > the packet can break PMTU-discovery. .. but I don't care about PMTU, so I'll just do it anyway. It seems that our haven't prohibited anything, just told people what the consequences are. (And what about AH...? Oh, sadly, nobody uses that) -- Michael Richardson , Sandelman Software Works -= IPv6 IoT consulting =- --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 iQEVAwUBV5HHaYCLcPvd0N1lAQKSMAf+Pw/Qz4NpthjlCzKq3+1dlaq1LH6f3wq+ xx1+Pb7fXE+LVweSLAqdcYTCXZmg2bAO2AsFMo2BZTSehzJv9Xia1IpCqSqgXoA+ WnWSHOb4y9006ByuCu3MjAqVZB6PdjO6lrjWObRR4bhBhGQfExgOqMiJZt/AX1j+ AW9uuyRQjNK942QAgxLRyfrIYHrXU6J+Rfo+/ang/fvcfDPIH982OhS3JGopGuQW /strWXh4G3ls+Rz4bX8hGvzjyVmx7iWMP4ySEK1izevCYRfb2nmo1gEpJFCgSfU5 mMTXtKIhwRFCiEuZaF9bKQk4c1SG/loj8gLRTnpm7GZTEl5Z5w2UVg== =fzIp -----END PGP SIGNATURE----- --=-=-=-- From nobody Fri Jul 22 01:21:47 2016 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4FD0E12DA24 for ; Fri, 22 Jul 2016 01:21: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=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=venaas-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 Do3Cl19BXkj0 for ; Fri, 22 Jul 2016 01:21:44 -0700 (PDT) Received: from mail-lf0-x22d.google.com (mail-lf0-x22d.google.com [IPv6:2a00:1450:4010:c07::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 B391312D630 for ; Fri, 22 Jul 2016 01:21:43 -0700 (PDT) Received: by mail-lf0-x22d.google.com with SMTP id f93so79823815lfi.2 for ; Fri, 22 Jul 2016 01:21:43 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=venaas-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=f35x+ahrTf0AN4he5gfCRNTYhLIUy2liwZ+HmrcWZrU=; b=bsbYNsq5IZb/9l16ecvLYgG7Vry+GNGckhiR5CXmyj8kq2J44hcEa1NNY9JMus0XUE HhTFHl7azF3ukWyAQZssNKg8yfgXsYFUH+w4X1YbDQT8CxxZ9gYGktky59iO0vAS0q7r IfTIjGNuT0hO4TtZSfb6ZTLLhxE1MsHWXsVunKbquDoaGxZuLRwkNDCih1wpBEt9iQwV GmAEqTGy5sIawvYDKU2b24zp7ccp4QpvgzZSVJJJZjfuRsvQaGchf6gKRJ+NpRT3PB69 uWJ19uE/EYTRcgAGLZIHXk4EAjvVDh9wv8jzRT2TmvRwuSgVpRP2nkxR8/g+QJ0apQir uaNA== 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-transfer-encoding; bh=f35x+ahrTf0AN4he5gfCRNTYhLIUy2liwZ+HmrcWZrU=; b=WAIGXX0DiuFNSBsmMY3k4YaC+d/9eTDaj4bVo9h1JwbVRPDi4UN3iK7N7Ajbx2ps+h rcC8Kn7ht/QbTRpd6KhrEw04uxcGxMreU+GSQqtfAYFDCV2GgnFCk74OAalwrzHOVHye u/hZ4pv/Pk0bAhxNyr6hbV6clBG8tp2RF+EQ5CuKKr8Wz7bD0GMTq+P9bpDcN1wpiKz8 kFKPzUPqYjKnVH28sItknWjzk3qM7dOhtZ++1ZTeUGDORrzNaMzuk24scrxdKnXmwuSi 9o8O/nCZCcvXKE3A8bu4MnRKV9pLc/VPzqUIsC26bCl9AhYreqFFC+xFwX8MFT9XiQYF ZDqA== X-Gm-Message-State: AEkoouu0A7psNI2EtEKFRbU0V5djiQLvEeOtQZnrE6duaFrLJRFPqoab+ROPenxjBNYAaLFAwN/d32P2/DLdgA== X-Received: by 10.25.0.149 with SMTP id 143mr1826191lfa.71.1469175701601; Fri, 22 Jul 2016 01:21:41 -0700 (PDT) MIME-Version: 1.0 Received: by 10.25.165.72 with HTTP; Fri, 22 Jul 2016 01:21:40 -0700 (PDT) In-Reply-To: <22d11b1c-0416-65f8-28a8-5b6cdff5e71f@gmail.com> References: <26148.1468914385@obiwan.sandelman.ca> <1ac389c5-22ca-2283-d09c-a26bea9c7a75@gmail.com> <5c775ad5-3e88-5d0e-f221-d36c5d4d5b38@gmail.com> <22d11b1c-0416-65f8-28a8-5b6cdff5e71f@gmail.com> From: Stig Venaas Date: Fri, 22 Jul 2016 01:21:40 -0700 Message-ID: Subject: Re: 2464 - link-local multicast address mapping To: Alexandre Petrescu Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Archived-At: Cc: 6man WG X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.17 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 Jul 2016 08:21:46 -0000 Hi On Thu, Jul 21, 2016 at 8:02 AM, Alexandre Petrescu wrote: > Hi, > > Le 21/07/2016 =C3=A0 15:46, Stig Venaas a =C3=A9crit : > [...] >>>>>>> >>>>>>> I think this mapping should happen only for link-scoped >>>>>>> IPv6 >>>> >>>> >>>> >>>> Why? Both for IPv4 and IPv6 you need to have some destination >>>> multicast MAC address for any IP/IPv6 multicast packet, >>>> regardless of scope. >>> >>> >>> >>> It woudlnt make sense to map a global-scope IPv6 multicast address >>> into a - by definition local - Ethernet multicast address. >> >> >> I know the local means locally assigned, but it is the same mapping >> regardless of scope. Even a global scope multicast packet need to >> have a defined MAC mapping so that a NIC can be programmed to receive >> the appropriate packets. > > > Hmm, I would agree, but I also think that the NIC of the default router > should not be programmed in some special way to receive appropriate > packets multicast packets. I think it's sufficient for it to have a > normal unicast IP and MAC address, and be present in the default router > list of the sender. The NIC of the receiver is programmed so that it can filter and receive only packets that are likely to be for the host, including multicast packet= s. Note that there may be hashing used so it can pick up some MACs that are not for the host. >> Since only the last 4 octets from the IP address is in the MAC >> address, there can be many IP multicast addresses using the same MAC >> address. > > > That's not good, right? These groups are different groups. The host stack will still do verification and discard packets it doesn't wa= nt. The main issue is that the NIC may pick up packets that the host doesn't care about. >> Hence in some cases a NIC could receive a packet it isn't interested >> in. But this cannot really be avoided when you map an IPv6 address >> into 48 bits or less. > > > No. It could be avoided if (1) only the link-local ff02 addresses would > be mapped (and not all scopes), (2) Group IDs in IPv6 for link-local > scope would be of max length 3 bytes. > > But yes, this is in a fictitious IPv6 world. Right. So in particular, it is a bad idea if someone uses a multicast address where the last 4 bytes are just ::1 as it looks just like ff02::1 a= t L2, so all host NICs would pick up the packets. Note that for SSM we will always have such problems as the NIC has no idea about the multicast source. Some IGMP snoopers/proxies do though, so that can help. Stig > Alex > > > > > >> >>> There is not enough place in there. As such reverse mapping would >>> be impossible. >>> >>>>>> destination addresses, not other scopes. >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> I.e. the last four octets of a _link-local_ IPv6 address >>>>>>> should get >>>>>> >>>>>> >>>>>> >>>>>> mapped into that MAC address (ff02::XXXX:XXXX -> >>>>>> 33-33-XX-XX-XX-XX); multicast addresses of other scopes than >>>>>> ff02 should not get mapped. >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>> >>>>>> I think you're assuming that there are no other nodes on the >>>>>> link are members of the > link-local scope group, or that >>>>>> there is no more than one multicast router on the link. >>>>> >>>>> >>>>> >>>>> >>>>> Yes, I do assume so. >>>> >>>> >>>> >>>> It's fairly common to have multiple multicast routers on the >>>> link, and there can definitely be multiple members of a >>>> link-local group (or any group) on the link. >>> >>> >>> >>> Yes certainly there can be multiple IP multicast routers on a link. >>> But I dont see how that supports mapping a global multicast address >>> into an Ethernet address. >> >> >> I don't know why it matters how many routers there are. >> >>>>>> Multicast address scopes are only indicating boundary of the >>>>>> multicast forwarding domain, not where multicast group >>>>>> members are or are not. >>>>> >>>>> >>>>> >>>>> >>>>> But an Ethernet 33-33- scope can only be a link scope. A >>>>> reverse >>>> >>>> >>>> >>>> Why? >>> >>> >>> >>> Because the whole world is not (and can not) be Ethernet - there >>> are other link types as well. As such its scope can only be >>> local. >> >> >> A global scope multicast packet might be forwarded across multiple >> links. On each link it traverses it will have some local link >> address. So you can say the L3 address is global, while the L2 >> address is just for the link. >> >>>> >>>>> mapping from an Ethernet scope back to a > link-local scope >>>>> would make no sense. >>>>> >>>>> (I also assume mapping to be bidirectional). >>>> >>>> >>>> >>>> What do you mean by bidirectional? As you wrote, you cannot do a >>>> reverse mapping. >>> >>> >>> >>> Bidirectional - map from IP address to MAC address, and >>> vice-versa. 'Mapping' suggests me ability to translate and >>> reversely too. >>> >>> Or maybe this RFC2464 'mapping' means to translate into only one >>> direction? (translate an IP to MAC but not vice-versa) >> >> >> Yes, it's only in one direction. >> >> Stig >> >>> Alex >>> >>> >>>> >>>> Stig >>>> >>>>> Alex >>>>> >>>>>> >>>>>> Regards, Mark. >>>>>> >>>>>>> Alex >>>>>>> >>>>>>> -------------------------------------------------------------------= - >>>>>>> >>>>>>> >>>>> >>>>>>> >>> >>>>>>> > 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 Fri Jul 22 02:13:12 2016 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7261412DA87 for ; Fri, 22 Jul 2016 02:13:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.189 X-Spam-Level: X-Spam-Status: No, score=-3.189 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-1.287, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] 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 UVk1eVZbGbN2 for ; Fri, 22 Jul 2016 02:13:08 -0700 (PDT) Received: from givry.fdupont.fr (givry.fdupont.fr [IPv6:2001:41d0:1:6d55:211:5bff:fe98:d51e]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E267A12DA7D for ; Fri, 22 Jul 2016 02:13:06 -0700 (PDT) Received: from givry.fdupont.fr (localhost [IPv6:::1]) by givry.fdupont.fr (8.14.7/8.14.7) with ESMTP id u6M9Bco9077775; Fri, 22 Jul 2016 11:11:38 +0200 (CEST) (envelope-from dupont@givry.fdupont.fr) Message-Id: <201607220911.u6M9Bco9077775@givry.fdupont.fr> From: Francis Dupont To: "C. M. Heard" Subject: Re: proposed text for header injection revision 05 In-reply-to: Your message of Thu, 21 Jul 2016 17:17:44 -0700. Date: Fri, 22 Jul 2016 11:11:38 +0200 Archived-At: Cc: 6man WG X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.17 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 Jul 2016 09:13:11 -0000 In your previous mail you wrote: > I think it's clear, if not actually obvious, that the original intent of > 2460 was that no intermediate IPv6 node would change the length of an IP > datagram. If that's the correct technical approach, then let's say so > explicitly in 2460 bis, and then we can advance it to IS. If that's not the > correct technical approach, then let's change the rule and stay at PS. => it was so header injection should be forbidden without any text about other approach (i.e, KISS) and the whole stuff advance to IS (as I asked at the mike some meetings ago). Regards Francis.Dupont@fdupont.fr From nobody Fri Jul 22 02:22:18 2016 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 82F4412D1D8 for ; Fri, 22 Jul 2016 02:22:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.189 X-Spam-Level: X-Spam-Status: No, score=-3.189 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-1.287, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] 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 Dlc0sZO330_m for ; Fri, 22 Jul 2016 02:22:14 -0700 (PDT) Received: from linfre.de (linfre.de [83.151.26.85]) (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 C60E312DBDC for ; Fri, 22 Jul 2016 02:22:13 -0700 (PDT) Received: from e7240.linfre (91.248.60.116) by linfreserv (Axigen) with (ECDHE-RSA-AES256-SHA encrypted) ESMTPSA id 1CC519; Fri, 22 Jul 2016 11:22:06 +0200 From: Karsten Thomann To: Alexandre Petrescu Subject: Re: Reference to "3333" value of RFC2464 "IPv6 over Ethernet" Date: Fri, 22 Jul 2016 11:22:05 +0200 Message-ID: <8076169.DCen8hcVym@e7240.linfre> User-Agent: KMail/5.2.2 (Linux/4.6.3-1-default; KDE/5.23.0; x86_64; ; ) In-Reply-To: <8a7c2460-ca23-f281-e3cd-03e69bbcb533@gmail.com> References: <2f437218b23a44238ccdcb4e7318da8d@XCH-RCD-003.cisco.com> <2007986.l75Eys8xCF@e7240.linfre> <8a7c2460-ca23-f281-e3cd-03e69bbcb533@gmail.com> MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="iso-8859-1" X-AXIGEN-DK-Result: No records DomainKey-Status: no signature X-AxigenSpam-Level: 5 Archived-At: Cc: ipv6@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.17 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 Jul 2016 09:22:16 -0000 Hi, Am Donnerstag, 21. Juli 2016, 16:54:25 CEST schrieb Alexandre Petrescu: > Le 21/07/2016 =E0 11:23, Karsten Thomann a =E9crit : > > Am Donnerstag, 21. Juli 2016, 10:25:11 CEST schrieb Alexandre > >=20 > > Petrescu: > >> Le 21/07/2016 =E0 02:23, Hemant Singh a =E9crit : > >>> Please read rfc 5308 and also rfc1195. Many folks have already > >>> said IS-IS does not run at the IP layer and thus the question > >>> does not arise if IS-IS runs on IPv6. IS-IS is extensible in > >>> that it uses TLV's to support IPv4 and IPv6 adjacency information > >>> between routing peers. IS-IS running at the link layer decided > >>> long time back to use two mac-addresses to multicast messages > >>> to. > >>=20 > >> That's fine. > >>=20 > >>> We should stop chasing IS-IS for any rfc2460bis or other rfc bis > >>> and any multicast IPv6 mac discussion. > >=20 > > Support > >=20 > >> Misunderstanding. > >>=20 > >> I am not chasing IS-IS, but I point out that IS-IS seems to be > >> using a globally unique (OUI) for its MAC multicast addresses, even > >> though IS-IS is obviously a local protocol. This MAC address is > >> allocated at IEEE and noted at IANA. > >=20 > > IS-IS has no OUI, it has reserved MAC addresses from a special > > purpose range, take a look at > > http://standards.ieee.org/develop/regauth/grpmac/public.html for > > assignements from that range. > >=20 > > I didn't understand the meaning of "local protocol" in your > > sentence. >=20 > By 'local protocol' I mean that it happens locally in closed > environments. I can't send send an IS-IS packet from here to Japan, as > I would do with ping6 for example. Yes and No. CLNS isn't really used anymore to transport anything except IS-IS, but=20 technically within a global backbone which uses IS-IS you can reach every=20 router within the network via e.g. clns ping to the ISO address of the othe= r=20 router. As the ISO protocol family lost the protocal "war" against IP, ther= e=20 is simply no interdomain connectivity left to get CLNS packets from one=20 carrier to another. >=20 > >> And, on the other hand, IPv6 global protocol seems to be using a > >> 'locally administered' MAC multicast address (no OUI), which is > >> not allocated by IEEE in any way; it is however noted at IANA. > >=20 > > As I've already written in another mail, that are completely > > different layers. The IEEE allows free use of MAC adresses if the > > locally administered bit is set. >=20 > Yes, and the address for 01-80-C2- for IS-IS does not have that > 'locally-administered' bit set. I.e. it's a 'globally unique' (OUI > enforced) even though IS-IS is more of a local nature (cant send packets > to Japan as I do with ping6). >=20 > It's maybe a stretch, but that's how I see it. As I explained above, CLNS was "global" and there were times where it was=20 possible to reach big parts of the World via CLNS beneath IP. I highly recommend to read something about the history of IP and ISO=20 protocols, I don't know where I read about it, but a short version is at=20 http://spectrum.ieee.org/computing/networks/osi-the-internet-that-wasnt As Stig Venaas already wrote in the other thread, the multicast addresses f= rom=20 33-33 are used as a link local optimization to allow the host to discard=20 unwanted multicast traffic at the MAC layer, instead of the IP Layer. >=20 > >> In other words: why IS-IS deserves an OUI whereas IPv6 gets along > >> with only a locally-administered MAC? That's not normal. > >=20 > > Short answer: History. >=20 > That's fine. >=20 > Alex >=20 > >> Alex > >>=20 > >>> Hemant > >>>=20 > >>>=20 > >>> On Wed, Jul 20, 2016 at 1:24 PM, Alexandre Petrescu > >>> >>> > wrote: > >>>=20 > >>> Can IS-IS run on IPv6 and if so which MAC multicast address? > >>>=20 > >>> Alex > >>>=20 > >>>=20 > >>> Le 20/07/2016 =E0 14:52, Hemant Singh a =E9crit : > >>>=20 > >>>=20 > >>>=20 > >>> On Wed, Jul 20, 2016 at 5:49 AM, Alexandre Petrescu > >>> >>> > >>> >>>=20 > >>> >> wrote: > >>>> Does IS-IS also make use of 01-00-5E- multicast IANA OUI? (in > >>>=20 > >>> addition to that C9). > >>>=20 > >>>=20 > >>> No. For Level-1 adjacencies, the packets are sent to > >>> 01-80-C2-00-00-14, and for Level-2 adjacencies, the packets are > >>> sent to 01-80-C2-00-00-15 > >>>=20 > >>> Hemant > >>=20 > >> -------------------------------------------------------------------- >=20 > IETF IPv6 working group mailing list >=20 > >> ipv6@ietf.org Administrative Requests: > >> https://www.ietf.org/mailman/listinfo/ipv6 > >> -------------------------------------------------------------------- From nobody Fri Jul 22 02:47:09 2016 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 20D7612DF36 for ; Fri, 22 Jul 2016 02:47:09 -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 ai2vRQNlAlrs for ; Fri, 22 Jul 2016 02:47:07 -0700 (PDT) Received: from mail-wm0-x22c.google.com (mail-wm0-x22c.google.com [IPv6:2a00:1450:400c: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 EEE5A12D0A8 for ; Fri, 22 Jul 2016 02:47:06 -0700 (PDT) Received: by mail-wm0-x22c.google.com with SMTP id f65so50638941wmi.0 for ; Fri, 22 Jul 2016 02:47:06 -0700 (PDT) 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-transfer-encoding; bh=hFJsahZNAxJ962looJgyrZB5wc+aE8AMIOn89trhFas=; b=O/UpTu3ZSmfeZLEt/UWbc582U3glWrRcR9YVt6Guqy9nAeyiY3uOKs43kCGoLApZQL 9X9Ld5Kerdjk5Q3LxtCiP1wJTA4wmYhyjOkMLYuNWantQQTeGGFIkewEGsTKmVcWpNXs h6SgfzN13GCR/hmF2P50NMlo6eEMgGBL0u1gm4Da9cluw8JToGHM7J67QKSnBA6vOkOG 4GTHhi/suStpr+pYWHu3F5AO44bl85up2CwOCNL91oWfO+eimzXVktWsxiMUCjX9mJH/ DuUjyIu9KoPGDfLJY2dCmEOqEAXWj0excQurb4b2e4bS3FJBv6UJAzKFW0p8HwjGvogf 4Cig== 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-transfer-encoding; bh=hFJsahZNAxJ962looJgyrZB5wc+aE8AMIOn89trhFas=; b=h5/eVutyANLe+NAJTHZmaaTxgAfYPv/O9waPAxAyt5/SZhCASL863JC/EDv5z0ZKYs yj8mvm1ozrRGLdkcYFUR3LJAZZE5U7ZPx0o7imgGfuU3Vb70m6pd/tD3SwSTRXVJy/xC qbbh5CxDypf7mM4B0nKhBtOFmIjyTLv5VKOfrrl0rHMA7kCFx+WS+mUOV2y/ZyFhwrmJ zMpZPIuSdyEepq9nbHzJXV5z+KDR4PcByo3j+oIP6fi2bNsMtH/s9nw9dtpWcu6OGsqX Cc8h2vpm+S4YbviE/Oxuv9trfmqdlBFqogZ6S6A3xQaFK1lB4NbE5EkVC7st77RRvHPQ xZbA== X-Gm-Message-State: AEkoouvHWnoffuMqFgLyVRlQMLmv0cd/Mg8PATaGltZ3U+jBHRCoQ40xAlzmtEWw2Celig== X-Received: by 10.28.216.67 with SMTP id p64mr4485619wmg.56.1469180825244; Fri, 22 Jul 2016 02:47:05 -0700 (PDT) Received: from ?IPv6:2001:67c:370:176:28cc:dc4c:9703:6781? ([2001:67c:370:176:28cc:dc4c:9703:6781]) by smtp.gmail.com with ESMTPSA id a203sm11932227wma.0.2016.07.22.02.47.04 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 22 Jul 2016 02:47:04 -0700 (PDT) Subject: Re: proposed text for header injection revision 05 To: ipv6@ietf.org References: <201607220911.u6M9Bco9077775@givry.fdupont.fr> From: Brian E Carpenter Organization: University of Auckland Message-ID: <948512bb-c741-0509-8442-2d230c5bca49@gmail.com> Date: Fri, 22 Jul 2016 21:47:13 +1200 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.2.0 MIME-Version: 1.0 In-Reply-To: <201607220911.u6M9Bco9077775@givry.fdupont.fr> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Archived-At: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.17 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 Jul 2016 09:47:09 -0000 On 22/07/2016 21:11, Francis Dupont wrote: > In your previous mail you wrote: > >> I think it's clear, if not actually obvious, that the original intent of >> 2460 was that no intermediate IPv6 node would change the length of an IP >> datagram. If that's the correct technical approach, then let's say so >> explicitly in 2460 bis, and then we can advance it to IS. If that's not the >> correct technical approach, then let's change the rule and stay at PS. > > => it was so header injection should be forbidden without any text > about other approach (i.e, KISS) and the whole stuff advance to IS > (as I asked at the mike some meetings ago). What I seem to have heard this week is that many people think that the proposed compromise is ambiguous (which is true) and that *therefore* it is not acceptable in an Internet Standard. If that is the consensus, then it does seem to me that there is no choice but to state the original (pre-RFC1888) intent that with the exception of HbH, extension headers MUST NOT be modified, inserted or deleted by forwarding nodes. In terms of the old text, this is just s/processed/processed, modified, inserted or deleted/ in the appropriate sentence. (To be clear, that doesn't affect the routing header because it is only modified by the destination host, even though that isn't the final destination of the packet.) If we do that, we don't require either of the two new paragraphs, but they remain valid if we want to keep them. Brian From nobody Fri Jul 22 02:53:07 2016 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D6F1A12DC50 for ; Fri, 22 Jul 2016 02:53:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.189 X-Spam-Level: X-Spam-Status: No, score=-3.189 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-1.287, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] 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 zHueFSsX7Hvu for ; Fri, 22 Jul 2016 02:52:58 -0700 (PDT) Received: from givry.fdupont.fr (givry.fdupont.fr [IPv6:2001:41d0:1:6d55:211:5bff:fe98:d51e]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 178A912DB9C for ; Fri, 22 Jul 2016 02:52:57 -0700 (PDT) Received: from givry.fdupont.fr (localhost [IPv6:::1]) by givry.fdupont.fr (8.14.7/8.14.7) with ESMTP id u6M9pT2M080346; Fri, 22 Jul 2016 11:51:29 +0200 (CEST) (envelope-from dupont@givry.fdupont.fr) Message-Id: <201607220951.u6M9pT2M080346@givry.fdupont.fr> From: Francis Dupont To: Brian E Carpenter Subject: Re: proposed text for header injection revision 05 In-reply-to: Your message of Fri, 22 Jul 2016 21:47:13 +1200. <948512bb-c741-0509-8442-2d230c5bca49@gmail.com> Date: Fri, 22 Jul 2016 11:51:29 +0200 Archived-At: Cc: ipv6@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.17 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 Jul 2016 09:53:02 -0000 In your previous mail you wrote: > If that is the consensus, then it does seem to me that there is > no choice but to state the original (pre-RFC1888) intent that > with the exception of HbH, extension headers MUST NOT be modified, > inserted or deleted by forwarding nodes. In terms of the old > text, this is just s/processed/processed, modified, inserted or deleted/ > in the appropriate sentence. > > (To be clear, that doesn't affect the routing header because it > is only modified by the destination host, even though that isn't > the final destination of the packet.) => I agree that clarifying the term "processed" is the simplest solution so the best. > If we do that, we don't require either of the two new paragraphs, > but they remain valid if we want to keep them. => IMHO we should have minimal normative text, i.e., remove not normative text which doesn't really help (2nd paragraph) and avoid redundant normative (so the first paragraph, of course only if we can get a consensus about the "processed" clarification). Thanks Francis.Dupont@fdupont.fr From nobody Fri Jul 22 03:39:12 2016 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 59D1212E030 for ; Fri, 22 Jul 2016 03:39:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.333 X-Spam-Level: X-Spam-Status: No, score=-5.333 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_ADSP_CUSTOM_MED=0.001, FREEMAIL_FROM=0.001, NML_ADSP_CUSTOM_MED=0.9, RCVD_IN_DNSWL_HI=-5, SPF_SOFTFAIL=0.665] 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 U4jmvH--35Ss for ; Fri, 22 Jul 2016 03:39:09 -0700 (PDT) Received: from oxalide-out.extra.cea.fr (oxalide-out.extra.cea.fr [132.168.224.8]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D05BF12DD41 for ; Fri, 22 Jul 2016 03:39:08 -0700 (PDT) Received: from pisaure.intra.cea.fr (pisaure.intra.cea.fr [132.166.88.21]) by oxalide.extra.cea.fr (8.15.2/8.15.2/CEAnet-Internet-out-2.4) with ESMTP id u6MAd6L8026269; Fri, 22 Jul 2016 12:39:06 +0200 Received: from pisaure.intra.cea.fr (localhost [127.0.0.1]) by localhost (Postfix) with SMTP id 58E4B204A1F; Fri, 22 Jul 2016 12:39:06 +0200 (CEST) Received: from muguet1.intra.cea.fr (muguet1.intra.cea.fr [132.166.192.6]) by pisaure.intra.cea.fr (Postfix) with ESMTP id 4AB852047EB; Fri, 22 Jul 2016 12:39:06 +0200 (CEST) Received: from [132.166.84.23] ([132.166.84.23]) by muguet1.intra.cea.fr (8.15.2/8.15.2/CEAnet-Intranet-out-1.4) with ESMTP id u6MAd5QI014800; Fri, 22 Jul 2016 12:39:06 +0200 Subject: Re: Reference to "3333" value of RFC2464 "IPv6 over Ethernet" To: Karsten Thomann References: <2f437218b23a44238ccdcb4e7318da8d@XCH-RCD-003.cisco.com> <2007986.l75Eys8xCF@e7240.linfre> <8a7c2460-ca23-f281-e3cd-03e69bbcb533@gmail.com> <8076169.DCen8hcVym@e7240.linfre> From: Alexandre Petrescu Message-ID: Date: Fri, 22 Jul 2016 12:39:05 +0200 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.2.0 MIME-Version: 1.0 In-Reply-To: <8076169.DCen8hcVym@e7240.linfre> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit Archived-At: Cc: ipv6@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.17 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 Jul 2016 10:39:11 -0000 Le 22/07/2016 11:22, Karsten Thomann a crit : > Hi, > > Am Donnerstag, 21. Juli 2016, 16:54:25 CEST schrieb Alexandre > Petrescu: >> Le 21/07/2016 11:23, Karsten Thomann a crit : >>> Am Donnerstag, 21. Juli 2016, 10:25:11 CEST schrieb Alexandre >>> >>> Petrescu: >>>> Le 21/07/2016 02:23, Hemant Singh a crit : >>>>> Please read rfc 5308 and also rfc1195. Many folks have >>>>> already said IS-IS does not run at the IP layer and thus the >>>>> question does not arise if IS-IS runs on IPv6. IS-IS is >>>>> extensible in that it uses TLV's to support IPv4 and IPv6 >>>>> adjacency information between routing peers. IS-IS running at >>>>> the link layer decided long time back to use two >>>>> mac-addresses to multicast messages to. >>>> >>>> That's fine. >>>> >>>>> We should stop chasing IS-IS for any rfc2460bis or other rfc >>>>> bis and any multicast IPv6 mac discussion. >>> >>> Support >>> >>>> Misunderstanding. >>>> >>>> I am not chasing IS-IS, but I point out that IS-IS seems to be >>>> using a globally unique (OUI) for its MAC multicast addresses, >>>> even though IS-IS is obviously a local protocol. This MAC >>>> address is allocated at IEEE and noted at IANA. >>> >>> IS-IS has no OUI, it has reserved MAC addresses from a special >>> purpose range, take a look at >>> http://standards.ieee.org/develop/regauth/grpmac/public.html for >>> assignements from that range. >>> >>> I didn't understand the meaning of "local protocol" in your >>> sentence. >> >> By 'local protocol' I mean that it happens locally in closed >> environments. I can't send send an IS-IS packet from here to >> Japan, as I would do with ping6 for example. > Yes and No. CLNS isn't really used anymore to transport anything > except IS-IS, but technically within a global backbone which uses > IS-IS you can reach every router within the network via e.g. clns > ping to the ISO address of the other router. As the ISO protocol > family lost the protocal "war" against IP, there is simply no > interdomain connectivity left to get CLNS packets from one carrier to > another. So that's local in the ISO protocol family. >>>> And, on the other hand, IPv6 global protocol seems to be using >>>> a 'locally administered' MAC multicast address (no OUI), which >>>> is not allocated by IEEE in any way; it is however noted at >>>> IANA. >>> >>> As I've already written in another mail, that are completely >>> different layers. The IEEE allows free use of MAC adresses if >>> the locally administered bit is set. >> >> Yes, and the address for 01-80-C2- for IS-IS does not have that >> 'locally-administered' bit set. I.e. it's a 'globally unique' >> (OUI enforced) even though IS-IS is more of a local nature (cant >> send packets to Japan as I do with ping6). >> >> It's maybe a stretch, but that's how I see it. > > As I explained above, CLNS was "global" That would be global in geographical terms, but not global in universality terms as IP is. That makes CLNS local. > and there were times where it was possible to reach big parts of the > World via CLNS beneath IP. I highly recommend to read something about > the history of IP and ISO protocols, I don't know where I read about > it, but a short version is at > http://spectrum.ieee.org/computing/networks/osi-the-internet-that-wasnt I will read that some time. The problem is not only to reach a very far point (Japan) but also to start from here. I.e. use my laptop on wifi to ping Japan - that is global reach. (or otherwise see the tortue dancing on kame.net) Everything else is local. That's why I continue to think that if a local protocol like IS-IS deserves a global OUI for its MAC multicast addressing then a global protocol like IPv6 deserves that even more. 33-33- is not such. > As Stig Venaas already wrote in the other thread, the multicast > addresses from 33-33 are used as a link local optimization to allow > the host to discard unwanted multicast traffic at the MAC layer, > instead of the IP Layer. Ok. Alex > >> >>>> In other words: why IS-IS deserves an OUI whereas IPv6 gets >>>> along with only a locally-administered MAC? That's not >>>> normal. >>> >>> Short answer: History. >> >> That's fine. >> >> Alex >> >>>> Alex >>>> >>>>> Hemant >>>>> >>>>> >>>>> On Wed, Jul 20, 2016 at 1:24 PM, Alexandre Petrescu >>>>> >>>> > wrote: >>>>> >>>>> Can IS-IS run on IPv6 and if so which MAC multicast address? >>>>> >>>>> Alex >>>>> >>>>> >>>>> Le 20/07/2016 14:52, Hemant Singh a crit : >>>>> >>>>> >>>>> >>>>> On Wed, Jul 20, 2016 at 5:49 AM, Alexandre Petrescu >>>>> >>>> >>>>> >>>> >>>>> >> wrote: >>>>>> Does IS-IS also make use of 01-00-5E- multicast IANA OUI? >>>>>> (in >>>>> >>>>> addition to that C9). >>>>> >>>>> >>>>> No. For Level-1 adjacencies, the packets are sent to >>>>> 01-80-C2-00-00-14, and for Level-2 adjacencies, the packets >>>>> are sent to 01-80-C2-00-00-15 >>>>> >>>>> Hemant >>>> >>>> -------------------------------------------------------------------- >> >> >>>> IETF IPv6 working group mailing list >> >>>> ipv6@ietf.org Administrative Requests: >>>> https://www.ietf.org/mailman/listinfo/ipv6 >>>> -------------------------------------------------------------------- > >>>> > > From nobody Fri Jul 22 04:47:50 2016 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AF42912D13D for ; Fri, 22 Jul 2016 04:47:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -15.808 X-Spam-Level: X-Spam-Status: No, score=-15.808 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.287, 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 hubTlrRXjg4b for ; Fri, 22 Jul 2016 04:47:47 -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 B79BC12D5CF for ; Fri, 22 Jul 2016 04:47:47 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=3061; q=dns/txt; s=iport; t=1469188067; x=1470397667; h=from:to:subject:date:message-id:references:in-reply-to: content-transfer-encoding:mime-version; bh=45yi+CHO29ISHpJk4sf7qSIoGo29RMXu1L9T/jSpK90=; b=SDiPZ50yepmA5rNlW9Q3R8BRukBgtS5qlsQ5sHX3Zn0T5Gspq9j0h55N htEKILxYAF/FyDOWMdyobH1DzOZzDJp32GS0DvNu3zI3zDpQe6P+rxwS/ rxpU7gzum1g4FoBX2k9MaO0EObY/UVnyxmt/RDPaQpGg40glHmCLnecJw g=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0A6AgAJB5JX/4oNJK1dgz9WfAa4WIF7I?= =?us-ascii?q?4V5AoEzOBQBAQEBAQEBXSeEXAEBBQEBODQXBAIBCBABBAEBAR4JBycLFAkIAgQ?= =?us-ascii?q?BEgiIKA68IgEBAQEBAQEBAQEBAQEBAQEBAQEBARcFhiqETYQjAQGFdgWIIJEGA?= =?us-ascii?q?Y5lgXOICYVFkCABHjaDc26HIDZ/AQEB?= X-IronPort-AV: E=Sophos;i="5.28,404,1464652800"; d="scan'208";a="299157174" Received: from alln-core-5.cisco.com ([173.36.13.138]) by alln-iport-5.cisco.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 22 Jul 2016 11:47:46 +0000 Received: from XCH-RCD-005.cisco.com (xch-rcd-005.cisco.com [173.37.102.15]) by alln-core-5.cisco.com (8.14.5/8.14.5) with ESMTP id u6MBlkSr006829 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Fri, 22 Jul 2016 11:47:46 GMT Received: from xch-rcd-001.cisco.com (173.37.102.11) by XCH-RCD-005.cisco.com (173.37.102.15) with Microsoft SMTP Server (TLS) id 15.0.1210.3; Fri, 22 Jul 2016 06:47:45 -0500 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.1210.000; Fri, 22 Jul 2016 06:47:45 -0500 From: "Pascal Thubert (pthubert)" To: Brian E Carpenter , "ipv6@ietf.org" Subject: RE: proposed text for header injection revision 05 Thread-Topic: proposed text for header injection revision 05 Thread-Index: AQHR4/kNNZawrgb030qoQPr6BVJAHaAkh+uA///IbNA= Date: Fri, 22 Jul 2016 11:46:18 +0000 Deferred-Delivery: Fri, 22 Jul 2016 11:43:26 +0000 Message-ID: <3dc4d07398e249f0a33192001665756d@XCH-RCD-001.cisco.com> References: <201607220911.u6M9Bco9077775@givry.fdupont.fr> <948512bb-c741-0509-8442-2d230c5bca49@gmail.com> In-Reply-To: <948512bb-c741-0509-8442-2d230c5bca49@gmail.com> 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.61.166.39] 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.17 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 Jul 2016 11:47:49 -0000 Hello Brian: The word "processed" cannot be kept because many intermediate boxes read th= e EHs (and transport headers) and act on them. It was indicated at the mee= ting that "reading" is a form of "processing".=20 People will not unplug their middle boxes no will they stop adding them, wh= atever we write now in a spec. We sometimes have discrepancy between the deployed world and the standards,= e.g. with the HbH EH. The world judges the specs and makes what it can of = them. It is good that in that particular occasion, this group listened to t= he world, and made the processing optional. In a more general fashion, publishing a document that is not followed by th= e reality of the world does not help. It makes the document less relevant, = I'm afraid.=20 For IS level, I'd rather go for a document that is fully relevant, even if = that means slightly ambiguous. Cheers, Pascal > -----Original Message----- > From: ipv6 [mailto:ipv6-bounces@ietf.org] On Behalf Of Brian E Carpenter > Sent: vendredi 22 juillet 2016 11:47 > To: ipv6@ietf.org > Subject: Re: proposed text for header injection revision 05 >=20 > On 22/07/2016 21:11, Francis Dupont wrote: > > In your previous mail you wrote: > > > >> I think it's clear, if not actually obvious, that the original > >> intent of > >> 2460 was that no intermediate IPv6 node would change the length of > >> an IP datagram. If that's the correct technical approach, then let's > >> say so explicitly in 2460 bis, and then we can advance it to IS. If > >> that's not the correct technical approach, then let's change the rule= and stay > at PS. > > > > =3D> it was so header injection should be forbidden without any text > > about other approach (i.e, KISS) and the whole stuff advance to IS (as > > I asked at the mike some meetings ago). >=20 > What I seem to have heard this week is that many people think that the > proposed compromise is ambiguous (which is true) and that > *therefore* it is not acceptable in an Internet Standard. >=20 > If that is the consensus, then it does seem to me that there is no choice= but to > state the original (pre-RFC1888) intent that with the exception of HbH, e= xtension > headers MUST NOT be modified, inserted or deleted by forwarding nodes. In > terms of the old text, this is just s/processed/processed, modified, inse= rted or > deleted/ in the appropriate sentence. >=20 > (To be clear, that doesn't affect the routing header because it is only m= odified > by the destination host, even though that isn't the final destination of = the > packet.) >=20 > If we do that, we don't require either of the two new paragraphs, but the= y > remain valid if we want to keep them. >=20 > Brian >=20 > -------------------------------------------------------------------- > IETF IPv6 working group mailing list > ipv6@ietf.org > Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 > -------------------------------------------------------------------- From nobody Fri Jul 22 04:50:51 2016 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BAF4612DC5F for ; Fri, 22 Jul 2016 04:50:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.336 X-Spam-Level: X-Spam-Status: No, score=-1.336 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, SPF_HELO_PASS=-0.001, SPF_SOFTFAIL=0.665] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=employees.org; domainkeys=pass (1024-bit key) header.from=otroan@employees.org header.d=employees.org 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 KkSZhXO-_29t for ; Fri, 22 Jul 2016 04:50:47 -0700 (PDT) Received: from incoming.kjsl.com (inbound02.kjsl.com [IPv6:2001:1868:2002::144]) (using TLSv1.2 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7559812D9B5 for ; Fri, 22 Jul 2016 04:50:47 -0700 (PDT) Received: from cowbell.employees.org ([IPv6:2001:1868:a000:17::142]) by ironport02.kjsl.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 22 Jul 2016 11:50:45 +0000 Received: from cowbell.employees.org (localhost [127.0.0.1]) by cowbell.employees.org (Postfix) with ESMTP id E50479CC4F; Fri, 22 Jul 2016 04:50:44 -0700 (PDT) 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=heOuXPSiHbiVqAECILijQgf24qc=; b= d5kjFTOfMv7f3gCaCU39l6RGzUYdVWteaiof5x6r/1Wu27o4dCVQ19sRbYMHwjbg Tj8B/XkICRCStJev/pNFcCMCF+VZgtdkQadTRH5eMc4SflY8bvpyf8tMQGk+D6u5 2XfXG8OGVwpqM4zxXBZjEss7z3Fr9XNSOHwzGbh9uWU= 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=kiQYIWb2cN8FjvXS3jgA55Q8uG vpbQi47lOO4U5PbI3lQU4yt0wVM1BajFMelh/SKr3tCO9TEmGRN94UayuPgTRoB/ 9ymrEKvecvsPnZ84Nnh+DwAiW8YzKzC5o70csM/D8QU2xHUbqSUbaJhLcIOhahCE HrT7KSpig4imCLGc8= Received: from h.hanazo.no (2.150.37.0.tmi.telenormobil.no [2.150.37.0]) (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 2BBBC9CC4E; Fri, 22 Jul 2016 04:50:44 -0700 (PDT) Received: from [IPv6:::1] (localhost [IPv6:::1]) by h.hanazo.no (Postfix) with ESMTP id 47B2D2BEADF1; Fri, 22 Jul 2016 13:50:33 +0200 (CEST) Subject: Re: proposed text for header injection revision 05 Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) Content-Type: multipart/signed; boundary="Apple-Mail=_BADC44E5-CEF3-4879-9B9C-CE7D0E5538C4"; protocol="application/pgp-signature"; micalg=pgp-sha512 X-Pgp-Agent: GPGMail From: otroan@employees.org In-Reply-To: <948512bb-c741-0509-8442-2d230c5bca49@gmail.com> Date: Fri, 22 Jul 2016 13:50:32 +0200 Message-Id: References: <201607220911.u6M9Bco9077775@givry.fdupont.fr> <948512bb-c741-0509-8442-2d230c5bca49@gmail.com> To: Brian E Carpenter X-Mailer: Apple Mail (2.3124) Archived-At: Cc: 6man WG X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.17 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 Jul 2016 11:50:49 -0000 --Apple-Mail=_BADC44E5-CEF3-4879-9B9C-CE7D0E5538C4 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii >>> I think it's clear, if not actually obvious, that the original = intent of >>> 2460 was that no intermediate IPv6 node would change the length of = an IP >>> datagram. If that's the correct technical approach, then let's say = so >>> explicitly in 2460 bis, and then we can advance it to IS. If that's = not the >>> correct technical approach, then let's change the rule and stay at = PS. >>=20 >> =3D> it was so header injection should be forbidden without any text >> about other approach (i.e, KISS) and the whole stuff advance to IS >> (as I asked at the mike some meetings ago). >=20 > What I seem to have heard this week is that many people think that > the proposed compromise is ambiguous (which is true) and that > *therefore* it is not acceptable in an Internet Standard. I cannot in RFC2026 or RFC6410 find that lack ambiguity is a requirement = to advance a document. =46rom RFC5218 you could imply that protocol design that allowed it to = be used in ways outside of our wildest expectations, is what makes for = successful protocols. > If that is the consensus, then it does seem to me that there is > no choice but to state the original (pre-RFC1888) intent that > with the exception of HbH, extension headers MUST NOT be modified, > inserted or deleted by forwarding nodes. In terms of the old > text, this is just s/processed/processed, modified, inserted or = deleted/ > in the appropriate sentence. >=20 > (To be clear, that doesn't affect the routing header because it > is only modified by the destination host, even though that isn't > the final destination of the packet.) >=20 > If we do that, we don't require either of the two new paragraphs, > but they remain valid if we want to keep them. Reading through this thread... I'm not quite sure what the perceived = ambiguity actually is. Is it _just_ for the exception, i.e. the HBH header? Cause I cannot see any ambiguity for the other headers: With one exception, extension headers are not examined or processed by any node along a packet's delivery path, until the packet reaches the node (or each of the set of nodes, in the case of multicast) identified in the Destination Address field of the IPv6 header. (I don't know of a single router implementation or deployment that does = not violate this though. If we want to take deployment experience into account, it would make = more sense to remove that paragraph than to strengthen it.) Best regards, Ole --Apple-Mail=_BADC44E5-CEF3-4879-9B9C-CE7D0E5538C4 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 iQEcBAEBCgAGBQJXkgiJAAoJED4aXnjSQuKWnc8H/iq46wiVtfQXEVNWYeUnNrBo nnrMTH6xucYkQ8iTWlumnhETSYETD7Bt+XrHgvQP6ef8E9806RwN/IpGzJe5IZKF +BBZHgX5FtFiFwNvW33Gyi0HndNV4mPtSioMxIJrPYbRF5YVPXgROqSjQjgJoeVv f17lNqCkiWLPz56SQ3yk5QCm5DwQoNWhlhyaHWV7ZWTMgCOsUKwrf5oUdWSco+T1 B2GjoH3cd6wiqYeGaorQLVyddkRGuEY/hURoYKV0bfSRVwjpbmR7+D2afhbXrL95 6HSq+c3YGSquITpCVj2rESE8iXmL/GxIpOWjqFih1dxR/rJY721P6UxB6eZOISc= =gRpV -----END PGP SIGNATURE----- --Apple-Mail=_BADC44E5-CEF3-4879-9B9C-CE7D0E5538C4-- From nobody Fri Jul 22 05:34:25 2016 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CEC1912D147 for ; Fri, 22 Jul 2016 05:34:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.189 X-Spam-Level: X-Spam-Status: No, score=-3.189 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-1.287, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] 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 ghM_SK3czfQP for ; Fri, 22 Jul 2016 05:34:22 -0700 (PDT) Received: from givry.fdupont.fr (givry.fdupont.fr [IPv6:2001:41d0:1:6d55:211:5bff:fe98:d51e]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0B6BB12D508 for <6man@ietf.org>; Fri, 22 Jul 2016 05:34:21 -0700 (PDT) Received: from givry.fdupont.fr (localhost [IPv6:::1]) by givry.fdupont.fr (8.14.7/8.14.7) with ESMTP id u6MCWqL1090164; Fri, 22 Jul 2016 14:32:52 +0200 (CEST) (envelope-from dupont@givry.fdupont.fr) Message-Id: <201607221232.u6MCWqL1090164@givry.fdupont.fr> From: Francis Dupont To: Mark Andrews Subject: Re: IPV6_USE_MIN_MTU and TCP In-reply-to: Your message of Fri, 22 Jul 2016 15:35:22 +1000. <20160722053522.E90564F26BC8@rock.dv.isc.org> Date: Fri, 22 Jul 2016 14:32:52 +0200 Archived-At: Cc: 6man@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.17 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 Jul 2016 12:34:24 -0000 In your previous mail you wrote: > What does this list believe the advertised MSS should be on a TCP > connection if IPV6_USE_MIN_MTU=1 has been set on a socket? => IPV6_USE_MIN_MTU=1 means the PMTU doesn't work (broken, e.g., because of PTB ICMP filtering, or too slow, or ...). So the MTU to use is 1280. > What does this list believe the transmitted TCP segment size should > be on a TCP connection if IPV6_USE_MIN_MTU=1 has been set on a > socket? => either ignore the IPV6_USE_MIN_MTU=1 (perhaps not the best idea) or use 1280-. Note in the first option it must be consistent, i.e., not ignoring at the TCP layer and enforcing it at the IP layer (one of the reasons IMHO it is not a good idea). I don't remember if my IPv6 code implements it but for me the clear way is to have a flag in the IP part of the PCB and to apply it when the MSS in computed. Regards Francis.Dupont@fdupont.fr From nobody Fri Jul 22 05:47:43 2016 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 95E1012DB03 for ; Fri, 22 Jul 2016 05:47:41 -0700 (PDT) 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 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 lzSNOhf9CURf for ; Fri, 22 Jul 2016 05:47:39 -0700 (PDT) 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 C238E12DB3B for <6man@ietf.org>; Fri, 22 Jul 2016 05:47:38 -0700 (PDT) Received: from [IPv6:2001:67c:370:160:edc0:90e6:9974:4873] (unknown [IPv6:2001:67c:370:160:edc0:90e6:9974:4873]) (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 4A28882CC6; Fri, 22 Jul 2016 14:47:36 +0200 (CEST) Subject: Re: proposed text for header injection revision 05 To: Brian E Carpenter , Jen Linkova , mohamed.boucadair@orange.com References: <26582.1468923195@obiwan.sandelman.ca> <2EBFA6F2-00A3-45E1-BE0E-3531AF75726A@employees.org> <787AE7BB302AE849A7480A190F8B933008DE9E22@OPEXCLILMA3.corporate.adroot.infra.ftgroup> <0445fd4c-3d96-73f5-035e-570f165faf9b@gmail.com> <614711c4-9e69-3ddc-67f2-0d20394169ad@si6networks.com> From: Fernando Gont X-Enigmail-Draft-Status: N1110 Message-ID: <3edee5c1-3444-bc7d-31e5-1bb29810e857@si6networks.com> Date: Thu, 21 Jul 2016 18:58:39 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.2.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Archived-At: Cc: Michael Richardson , "6man@ietf.org" <6man@ietf.org>, "Mark Townsley \(townsley\)" X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.17 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 Jul 2016 12:47:41 -0000 On 07/21/2016 06:39 PM, Brian E Carpenter wrote: > > On 22/07/2016 03:58, Fernando Gont wrote: >> On 07/21/2016 10:47 AM, Brian E Carpenter wrote: >>> On 21/07/2016 20:02, Jen Linkova wrote: >>>> On Wed, Jul 20, 2016 at 6:06 PM, wrote: >>>>> Hi Ole, all, >>>>> >>>>> I'm for removing that text as it does not add any recommendation at all. >>>> >>>> Seconded. I can not see what we are trying to achieve by having that >>>> second paragraph. It does not add any value and should be removed. >>> >>> So, can we go back to the version at >>> https://tools.ietf.org/html/draft-ietf-6man-rfc2460bis-01#page-7 >>> which does add value? >>> >>> Again: that second paragraph is part of a compromise between those who want >>> to explicitly forbid any insertion of headers and those who don't. Remove >>> it and you break the compromise. >> >> What I wonder, in all of this discussion, if whether such "compromise" >> is really a comprimise. >> >> My take boils down to these three questions, which I have asked, but >> never got an answer: >> >> 1) Is a router that inserts an EH compliant with RFC2460? (yes/no) > > Some people say Yes. Some people say No. > >> 2) Is a router that inserts an EH compliant with RFC2460bis? (yes/no) > > Some people say Yes. Some people say No. > >> 3) If the response to #1 and #2 match, please make that clear. If they >> don't, please make it clear that you're changing the spec. > > We aren't changing it in the compromise proposal, i.e. we are leaving > it undecided. I think that's a bad outcome. We're doing a bis document, and if there's a known ambiguity, we should clarify it. My own take is that in RFC2460 forbids it (Bob et al confirming that), and that rfc2460bis opens the door for it to be possible. If we're going that way, fair enough, but let's spell that out clearly. I think that whether EHs can be inserted or not is much of an architectural point of view that it would be a shame that we publish a bis document of a 20+ years protocol spec and are not able to answer such question. Note, again: I don't care much about the outcome. I care ambiguities in specs, which, in my experience, sooner or later (but always) lead to trouble. 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 Jul 22 08:23:58 2016 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1260D12DC0A for ; Fri, 22 Jul 2016 08:23:57 -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 ZR8LcKIzyJTR for ; Fri, 22 Jul 2016 08:23:55 -0700 (PDT) Received: from mail-wm0-x22f.google.com (mail-wm0-x22f.google.com [IPv6:2a00:1450:400c:c09::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 A40B912DC32 for ; Fri, 22 Jul 2016 08:23:48 -0700 (PDT) Received: by mail-wm0-x22f.google.com with SMTP id f65so61596353wmi.0 for ; Fri, 22 Jul 2016 08:23:48 -0700 (PDT) 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-transfer-encoding; bh=Rf+XjAW2TU01+72mxrfZprgPnonMFFwqc2DRDGuamKA=; b=ZIpZ82xDmmW90bfLHYH+ccil8czHfJjtZFdsYgNUe66Hj8rZw7KbA6W43SPtMHt0+x /Y0tSspGtDDuzv6cIe0ABo9/oWsTKlZuD0gY6annxL/77WGXE7hs5P8pMLtOkRkH30Vt 9UV5wStD7P2wsmH2MA/e8nIDqweBB4mu+HDKUuW9D54FJdv06wQX/qfSE/0ZluRGiOTj dBo+Z9GpbNm6t5oDYN32Agiy67PgzvzURHoAyi9Rzizk6aasdpTAZ3TzhbMvp+c5jG9s B4iUh1ANZh7XiOZSyd/jV3BER8ywWW0VpqDQQZa4mRmI8jIexJ8XOePm442ojNZ6C+kK di/Q== 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-transfer-encoding; bh=Rf+XjAW2TU01+72mxrfZprgPnonMFFwqc2DRDGuamKA=; b=NuzBvmx3WmJcFSlVUTxq/YK8M1IXARmG+dbOEMzQOPH5cTo7ZepqX+oiCAmYK3zGJr Wm8EDkAd2wvdprfZMEv6A/IodTqLoQIz3/6K60bONPuZTTEXLFlmBhmbGDopwctg0+GE KsfdHwRTs57XQDnsbBohF0of5d+jdst3EX3BStgLVPxzLAPpEQDtu+G+Hlm2NHGpZvdI ZZq/zEzyFAPPlRvAUs9hBR0l4u7RkCRbp1GDYpW1oa5IuRX0Ofebqf8Ad4W+07ET0a7C 9XjkN8Uorfz/gZIhL4Y1DHfpbOEZKyK5JWXx9bvWbtt9E33ZFPPxiHbwNl0g453EuWvj VVcw== X-Gm-Message-State: ALyK8tLIzTnhNhFOfzPUA9A7SggE0dei04ur/tYG1SwUbBHURREI9SlZrXAUuodaUsooLA== X-Received: by 10.28.1.74 with SMTP id 71mr24792057wmb.4.1469201025106; Fri, 22 Jul 2016 08:23:45 -0700 (PDT) Received: from ?IPv6:2001:67c:370:136:28cc:dc4c:9703:6781? ([2001:67c:370:136:28cc:dc4c:9703:6781]) by smtp.gmail.com with ESMTPSA id va3sm1416431wjb.18.2016.07.22.08.23.44 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 22 Jul 2016 08:23:44 -0700 (PDT) Subject: Re: proposed text for header injection revision 05 To: "Pascal Thubert (pthubert)" , "ipv6@ietf.org" References: <201607220911.u6M9Bco9077775@givry.fdupont.fr> <948512bb-c741-0509-8442-2d230c5bca49@gmail.com> <3dc4d07398e249f0a33192001665756d@XCH-RCD-001.cisco.com> From: Brian E Carpenter Organization: University of Auckland Message-ID: Date: Sat, 23 Jul 2016 03:23:53 +1200 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.2.0 MIME-Version: 1.0 In-Reply-To: <3dc4d07398e249f0a33192001665756d@XCH-RCD-001.cisco.com> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Archived-At: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.17 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 Jul 2016 15:23:57 -0000 On 22/07/2016 23:46, Pascal Thubert (pthubert) wrote: > Hello Brian: > > The word "processed" cannot be kept because many intermediate boxes read the EHs (and transport headers) and act on them. It was indicated at the meeting that "reading" is a form of "processing". "Processed" is unclear, but the actual old text is "examined or processed" which is definitely violated by many middleboxes. The 2460bis text has dropped "examined" which recognizes the reality of firewalls. > People will not unplug their middle boxes no will they stop adding them, whatever we write now in a spec. Correct. > > We sometimes have discrepancy between the deployed world and the standards, e.g. with the HbH EH. The world judges the specs and makes what it can of them. It is good that in that particular occasion, this group listened to the world, and made the processing optional. We didn't. The current 2460bis text is just as vague about "processed" as 2460, in fact. Brian > > In a more general fashion, publishing a document that is not followed by the reality of the world does not help. It makes the document less relevant, I'm afraid. > > For IS level, I'd rather go for a document that is fully relevant, even if that means slightly ambiguous. > > Cheers, > > Pascal > >> -----Original Message----- >> From: ipv6 [mailto:ipv6-bounces@ietf.org] On Behalf Of Brian E Carpenter >> Sent: vendredi 22 juillet 2016 11:47 >> To: ipv6@ietf.org >> Subject: Re: proposed text for header injection revision 05 >> >> On 22/07/2016 21:11, Francis Dupont wrote: >>> In your previous mail you wrote: >>> >>>> I think it's clear, if not actually obvious, that the original >>>> intent of >>>> 2460 was that no intermediate IPv6 node would change the length of >>>> an IP datagram. If that's the correct technical approach, then let's >>>> say so explicitly in 2460 bis, and then we can advance it to IS. If >>>> that's not the correct technical approach, then let's change the rule and stay >> at PS. >>> >>> => it was so header injection should be forbidden without any text >>> about other approach (i.e, KISS) and the whole stuff advance to IS (as >>> I asked at the mike some meetings ago). >> >> What I seem to have heard this week is that many people think that the >> proposed compromise is ambiguous (which is true) and that >> *therefore* it is not acceptable in an Internet Standard. >> >> If that is the consensus, then it does seem to me that there is no choice but to >> state the original (pre-RFC1888) intent that with the exception of HbH, extension >> headers MUST NOT be modified, inserted or deleted by forwarding nodes. In >> terms of the old text, this is just s/processed/processed, modified, inserted or >> deleted/ in the appropriate sentence. >> >> (To be clear, that doesn't affect the routing header because it is only modified >> by the destination host, even though that isn't the final destination of the >> packet.) >> >> If we do that, we don't require either of the two new paragraphs, but they >> remain valid if we want to keep them. >> >> Brian >> >> -------------------------------------------------------------------- >> IETF IPv6 working group mailing list >> ipv6@ietf.org >> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 >> -------------------------------------------------------------------- > . > From nobody Fri Jul 22 08:36:21 2016 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5988812DB8C for ; Fri, 22 Jul 2016 08:36:19 -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 H83TB9jpi5un for ; Fri, 22 Jul 2016 08:36:17 -0700 (PDT) Received: from mail-wm0-x22f.google.com (mail-wm0-x22f.google.com [IPv6:2a00:1450:400c:c09::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 8F17F12D756 for ; Fri, 22 Jul 2016 08:36:17 -0700 (PDT) Received: by mail-wm0-x22f.google.com with SMTP id i5so71733587wmg.0 for ; Fri, 22 Jul 2016 08:36:17 -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=KB3O2uIxB1Yr7X46+DF1q9mZjupyIBhoJWeVefJVdP4=; b=nQcIpmExIywFosbmjqm31uCVDV3NoTX+yb9gUMdEK+yMFyEF9x9E5FGrEx9LJYnLhp f/1zRLl6QTesGQo6aaLfsQZEDQUwf3akqkNpNqOlyF0EddF71zRpU/iZ4QMxX22832YB ckSnpoXT56MsdNshjIb8eNm6EjuUAhTNCIFwPEw9GmR4fkGnSg2tyYd5/StVGFqSMe4/ IQCJz26dg/cueuJ9fgWWn1s45nRRsTUYcJ59lr2UgqxHV7sBxkLN1bvBjLcdcnOGQQDV G4Df4Bt2ouJumYYETYV9RD6sno/BO4tkWdpeqrNJZB6DXIA2uY8QIpHREXeIBCZc3w6m Vx/Q== 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=KB3O2uIxB1Yr7X46+DF1q9mZjupyIBhoJWeVefJVdP4=; b=cHZ5FNZrgC+0v4DC2uV6YLsw1CYyT6/1hZC1WDzCP683Q36ffa2YHgPTBreJcLJmNc BSWLKPwIlIjVOGoXSEs7xfPmPDW/rsFuyDZzbmC2d5OgFrUmli7QraRo/RKjEOlTqBEX Zt5ev4+jgDmaYMRnUsd49MvrP5F52oWcIo1ruDXxBszX5tUL2HpdMu/wseeM15sTLNGK LwdttysqUfRi6yCaDRKUqUu5ezD610f3m3onH+sYKSsfBRzSY4iycJzlOl4ZwNgqTlOy UeXWEzEbqQkRFZ+XM8rB4+BI3wQF5+3/qGrhNAnNBZTvGea+lE2QVbpYr4/8ucKuHb8b C4uw== X-Gm-Message-State: AEkoouvwFhLiVtKb5qxhx/VlTmB0lT+uSs3L36v5nax/yKEWuOCcQdirdTX1eFFGP6t3ug== X-Received: by 10.28.142.135 with SMTP id q129mr4861956wmd.41.1469201776055; Fri, 22 Jul 2016 08:36:16 -0700 (PDT) Received: from ?IPv6:2001:67c:370:136:28cc:dc4c:9703:6781? ([2001:67c:370:136:28cc:dc4c:9703:6781]) by smtp.gmail.com with ESMTPSA id kc6sm1463147wjb.3.2016.07.22.08.36.15 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 22 Jul 2016 08:36:15 -0700 (PDT) Subject: Re: proposed text for header injection revision 05 To: otroan@employees.org References: <201607220911.u6M9Bco9077775@givry.fdupont.fr> <948512bb-c741-0509-8442-2d230c5bca49@gmail.com> From: Brian E Carpenter Organization: University of Auckland Message-ID: Date: Sat, 23 Jul 2016 03:36:24 +1200 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.2.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Archived-At: Cc: 6man WG X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.17 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 Jul 2016 15:36:19 -0000 On 22/07/2016 23:50, otroan@employees.org wrote: >>>> I think it's clear, if not actually obvious, that the original intent of >>>> 2460 was that no intermediate IPv6 node would change the length of an IP >>>> datagram. If that's the correct technical approach, then let's say so >>>> explicitly in 2460 bis, and then we can advance it to IS. If that's not the >>>> correct technical approach, then let's change the rule and stay at PS. >>> >>> => it was so header injection should be forbidden without any text >>> about other approach (i.e, KISS) and the whole stuff advance to IS >>> (as I asked at the mike some meetings ago). >> >> What I seem to have heard this week is that many people think that >> the proposed compromise is ambiguous (which is true) and that >> *therefore* it is not acceptable in an Internet Standard. > > I cannot in RFC2026 or RFC6410 find that lack ambiguity is a requirement to advance a document. That's probably true. But it's still a matter of community consensus; it's above my pay grade to determine that. > > From RFC5218 you could imply that protocol design that allowed it to be used in ways outside of our wildest expectations, is what makes for successful protocols. > >> If that is the consensus, then it does seem to me that there is >> no choice but to state the original (pre-RFC1888) intent that >> with the exception of HbH, extension headers MUST NOT be modified, >> inserted or deleted by forwarding nodes. In terms of the old >> text, this is just s/processed/processed, modified, inserted or deleted/ >> in the appropriate sentence. >> >> (To be clear, that doesn't affect the routing header because it >> is only modified by the destination host, even though that isn't >> the final destination of the packet.) >> >> If we do that, we don't require either of the two new paragraphs, >> but they remain valid if we want to keep them. > > Reading through this thread... I'm not quite sure what the perceived ambiguity actually is. > Is it _just_ for the exception, i.e. the HBH header? > > Cause I cannot see any ambiguity for the other headers: > > With one exception, extension headers are not examined or processed > by any node along a packet's delivery path, until the packet reaches > the node (or each of the set of nodes, in the case of multicast) > identified in the Destination Address field of the IPv6 header. Does "process" include insert, delete or modify? I say yes, others say no. (Again, "examined" is already deleted in 2460bis.) > > (I don't know of a single router implementation or deployment that does not violate this though. > If we want to take deployment experience into account, it would make more sense to remove that paragraph than to strengthen it.) Well, we have experience or at least definite knowledge that inserting a header breaks PMTUD. We also have experience that "processing" fragment headers by dropping them breaks IPv6. Sorry about this but I thought we had compromise wording. Now it seems we don't. Regards Brian > > Best regards, > Ole > From nobody Fri Jul 22 09:57:44 2016 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A6B7312DE5B for ; Fri, 22 Jul 2016 09:57:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FREEMAIL_FORGED_FROMDOMAIN=0.001, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=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 wjQCmC3A1txe for ; Fri, 22 Jul 2016 09:57:41 -0700 (PDT) Received: from mail-qt0-x22c.google.com (mail-qt0-x22c.google.com [IPv6:2607:f8b0:400d:c0d::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 B825412DE55 for <6man@ietf.org>; Fri, 22 Jul 2016 09:57:41 -0700 (PDT) Received: by mail-qt0-x22c.google.com with SMTP id u25so64953671qtb.1 for <6man@ietf.org>; Fri, 22 Jul 2016 09:57:41 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to:cc; bh=g2m9sL+FB0Ug8ZuZiUSIzvMtY2LBrXTZNrftM7wWv7I=; b=Gpgb3U8mIMPgF+d+dcy3sEVpPnYtE5H+eqDUJDLROyYMFwSMd3fcKdIigSnai5HU7e KFkz94/z1OiNxciFUqMoHGNL/ThZEOTUCzUdO3ssAzMeZ489LFjCfPRnYg294gfjYmd2 q2nGEIRwrl08yQiXEgkOrCqQfMW+OchNBbLlEPdtif/AZzF8byxdLbxWb8xbcC94DFWa V6PUVmciDpEvt4RIEl8+I2kWiMepWFu/Pr1f+nTHNCyh1e17SaCaaLpRd2MGqjJMLUDG aM8YAZZ+ZdEjKJNO/DDgHiX8tTpjaRkc6kHLY0Lz2oirL7Mo+2pDmDqG/OpXg+PPn6QT FLWw== 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:from :date:message-id:subject:to:cc; bh=g2m9sL+FB0Ug8ZuZiUSIzvMtY2LBrXTZNrftM7wWv7I=; b=AqxtlP+C72iKYviYFMIekO89VIElB4WQmfLYkp4mrlm1tLwfogstTATiauYQWUsM+o 5tTGiD/9tjn62MHKqXaMqLXfalqkNF/Osah3irN1Kkfacvn99lOW4HFjWJl133hdrR6n Vdw8TXYj91GIpcksjUzMtw0WB5UbpSw/KzrIFzKDhjaJ2aDcTZ5ls+1plcPGOylEZW8a M0cXpE0U8qbKzVO1FAb+P6ghssi5l6JKGv5NN1JJVWmt+xiWU8UHy8dM8jwlT0vTAxWm lId7bjIdV64f4MkOwn/5wesTOyJ0dtngiKZx+1yjsxHrFvH1tnvi3FQmXBuakCTlspvq iETg== X-Gm-Message-State: AEkoouvJQrvsCXxKg75ggThYZS7U5yAQYV24Genx0LMRml7OvrsCRHXcmJXhgB78BOd0BeTfKOVDKLwRLid0wA== X-Received: by 10.200.47.253 with SMTP id m58mr7592465qta.60.1469206660832; Fri, 22 Jul 2016 09:57:40 -0700 (PDT) MIME-Version: 1.0 Sender: jinmei.tatuya@gmail.com Received: by 10.237.33.154 with HTTP; Fri, 22 Jul 2016 09:57:40 -0700 (PDT) In-Reply-To: <3edee5c1-3444-bc7d-31e5-1bb29810e857@si6networks.com> References: <26582.1468923195@obiwan.sandelman.ca> <2EBFA6F2-00A3-45E1-BE0E-3531AF75726A@employees.org> <787AE7BB302AE849A7480A190F8B933008DE9E22@OPEXCLILMA3.corporate.adroot.infra.ftgroup> <0445fd4c-3d96-73f5-035e-570f165faf9b@gmail.com> <614711c4-9e69-3ddc-67f2-0d20394169ad@si6networks.com> <3edee5c1-3444-bc7d-31e5-1bb29810e857@si6networks.com> From: =?UTF-8?B?56We5piO6YGU5ZOJ?= Date: Fri, 22 Jul 2016 09:57:40 -0700 X-Google-Sender-Auth: ytB430bWY7cWzmiv-l14nwNeBUs Message-ID: Subject: Re: proposed text for header injection revision 05 To: Fernando Gont Content-Type: text/plain; charset=UTF-8 Archived-At: Cc: "6man@ietf.org" <6man@ietf.org>, Michael Richardson , "Mark Townsley \(townsley\)" X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.17 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 Jul 2016 16:57:44 -0000 At Thu, 21 Jul 2016 18:58:39 +0200, Fernando Gont wrote: > >> My take boils down to these three questions, which I have asked, but > >> never got an answer: > >> > >> 1) Is a router that inserts an EH compliant with RFC2460? (yes/no) > > > > Some people say Yes. Some people say No. > > > >> 2) Is a router that inserts an EH compliant with RFC2460bis? (yes/no) > > > > Some people say Yes. Some people say No. > > > >> 3) If the response to #1 and #2 match, please make that clear. If they > >> don't, please make it clear that you're changing the spec. > I think that's a bad outcome. We're doing a bis document, and if there's > a known ambiguity, we should clarify it. > > My own take is that in RFC2460 forbids it (Bob et al confirming that), > and that rfc2460bis opens the door for it to be possible. If we're going > that way, fair enough, but let's spell that out clearly. > > I think that whether EHs can be inserted or not is much of an > architectural point of view that it would be a shame that we publish a > bis document of a 20+ years protocol spec and are not able to answer > such question. > > Note, again: I don't care much about the outcome. I care ambiguities in > specs, which, in my experience, sooner or later (but always) lead to > trouble. I agree. And, if the least bad consensus/compromise that this wg could reach is to leave the ambiguity, I'd at very least like to see text that explicitly says it was ambiguous in the previous version of the spec and is still kept ambiguous intentionally due to varied opinions. I still oppose to just keeping the text ambiguous. -- JINMEI, Tatuya From nobody Fri Jul 22 11:48:04 2016 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7C03812D091 for ; Fri, 22 Jul 2016 11:48:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.022 X-Spam-Level: X-Spam-Status: No, score=0.022 tagged_above=-999 required=5 tests=[BAYES_40=-0.001, HTML_MESSAGE=0.001, MIME_HTML_ONLY=0.723, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H2=-0.001] autolearn=no 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 mCjh1AG9Xz_X for ; Fri, 22 Jul 2016 11:48:01 -0700 (PDT) Received: from atl4mhob04.myregisteredsite.com (atl4mhob04.myregisteredsite.com [209.17.115.42]) by ietfa.amsl.com (Postfix) with ESMTP id CED8B12E099 for ; Fri, 22 Jul 2016 11:47:56 -0700 (PDT) Received: from atl4oxapp103 ([10.30.71.140]) by atl4mhob04.myregisteredsite.com (8.14.4/8.14.4) with ESMTP id u6MIltn4016053 for ; Fri, 22 Jul 2016 14:47:55 -0400 Date: Fri, 22 Jul 2016 14:47:55 -0400 (EDT) From: Randy Turner To: ipv6@ietf.org Message-ID: <489138271.16809.1469213275935@webmail.networksolutionsemail.com> Subject: 2460bis-05 MIME-Version: 1.0 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: 7bit X-Priority: 3 Importance: Medium X-Mailer: Open-Xchange Mailer v7.8.1-Rev11 X-Originating-Client: open-xchange-appsuite Archived-At: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.17 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 Jul 2016 18:48:03 -0000

Hi All,

In section 4 of 2460bis-05, there is a description of what a "full" implementation would consist of...can someone elaborate on the definition of "full" ?  Is this a conformance thing?

Thanks,

Randy

From nobody Fri Jul 22 13:40:34 2016 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9265D12D149 for ; Fri, 22 Jul 2016 13:40:33 -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 ViRk-4qHiOm2 for ; Fri, 22 Jul 2016 13:40:31 -0700 (PDT) Received: from mail-oi0-x22d.google.com (mail-oi0-x22d.google.com [IPv6:2607:f8b0:4003:c06::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 D2C4012D135 for <6man@ietf.org>; Fri, 22 Jul 2016 13:40:31 -0700 (PDT) Received: by mail-oi0-x22d.google.com with SMTP id j185so178841591oih.0 for <6man@ietf.org>; Fri, 22 Jul 2016 13:40:31 -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=wSzHp06KNjNFWEecSNq1jT0clgtNhjDOHLNAb37FCaE=; b=EBwsL8dTKm9FWhduYsqPMuUqZalJoJJiwdJEmBiq6L5PkmTpS0pP71Qo7+Qi3rKySY 8JktXC7tTyKdbDN7kQn2mGjpIuEkUgtJHvTPD6xRqpzVAvnCeL82RnVQ7HFmlDAMZtdP qOIu5hjnCFIZWLQ44ekj0LXMar73+7EpBnIpYSQpeesaKxCqcx+IEwe9MNN1cbbav6Ei fhamQuMbpfjRqMmV+5Nyt4dq0KbZAWYCtfHkbeza2ykX1wuDINyQ48ENFOrYDaMj3In8 e8rZLYBBeuIXnTBiBQ7LWOfMis4TThjgEOPfYAImnNM3bp2bKImg1n0cUWVw7De8CmXH SKiQ== 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=wSzHp06KNjNFWEecSNq1jT0clgtNhjDOHLNAb37FCaE=; b=MVZuwYl0gegMTKQ8VTcVf1q2dm9otOqY5+vhzZB5NIN4xeu+v5eETVKc3KbgAJoQrL P9oBVRJPoWwTx5U3xgkayrYwKZ8N+C1G/b3sd/LsYkAKSkF2CaMDfuJLGiTU7RPTMWxO BKcc7p0T/w474wgsUppT1U9C/ZydbF1T7tLALWrq0NkuAJFgIM/8f3Xe6SwPhRidLsvA D6nsw82nCPH6EbhLCmZeMwRnj4yu62XkBAF2w+hWmoMTHvMvm99aVwPizR9spISMWFVZ 7ebnYhalb10/HjOoR75Yhilc0WXQOG7OgYR/0G0di/GEKEdyQ8Dxcmnj0QaPhl2ZOTsv YUzA== X-Gm-Message-State: AEkoouuYicLaDJ4LVWTPrbE0GwdXRlQ3VzSuRQZoSOOaCKBtCTuQVFgVLqjuzewHAq1c+r8GHr+FsCIl++m7gQ== X-Received: by 10.157.34.201 with SMTP id y67mr3006416ota.138.1469220031060; Fri, 22 Jul 2016 13:40:31 -0700 (PDT) MIME-Version: 1.0 Received: by 10.182.172.66 with HTTP; Fri, 22 Jul 2016 13:40:30 -0700 (PDT) In-Reply-To: References: <26582.1468923195@obiwan.sandelman.ca> <2EBFA6F2-00A3-45E1-BE0E-3531AF75726A@employees.org> <787AE7BB302AE849A7480A190F8B933008DE9E22@OPEXCLILMA3.corporate.adroot.infra.ftgroup> <0445fd4c-3d96-73f5-035e-570f165faf9b@gmail.com> <614711c4-9e69-3ddc-67f2-0d20394169ad@si6networks.com> <3edee5c1-3444-bc7d-31e5-1bb29810e857@si6networks.com> From: Hemant Singh Date: Fri, 22 Jul 2016 16:40:30 -0400 Message-ID: Subject: Re: proposed text for header injection revision 05 To: =?UTF-8?B?56We5piO6YGU5ZOJ?= Content-Type: multipart/alternative; boundary=94eb2c0332a60c62ab05383f72f1 Archived-At: Cc: "Mark Townsley \(townsley\)" , Fernando Gont , "6man@ietf.org" <6man@ietf.org>, Michael Richardson X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.17 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 Jul 2016 20:40:33 -0000 --94eb2c0332a60c62ab05383f72f1 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable +1 to the email below. The bis doc should acknowledge that old text was deliberately ambiguous and is now being clarified. Additionally, the doc should also say "MPTUD, ICMP, AH, IPSec" break if any intermediate node adds an EH header., It's probably three times already in this mailer that folks have had to answer what breaks. Lastly, please also mention if the rule is not complied with, a new packet checksum needs to be computed. There is also potential to leak packets outside of a specific domain where users may want to add EH by intermediate nodes and then proper receive behavior of nodes breaks down= . Hemant On Fri, Jul 22, 2016 at 12:57 PM, =E7=A5=9E=E6=98=8E=E9=81=94=E5=93=89 wrote: > . > > I agree. > > And, if the least bad consensus/compromise that this wg could reach is > to leave the ambiguity, I'd at very least like to see text that > explicitly says it was ambiguous in the previous version of the spec > and is still kept ambiguous intentionally due to varied opinions. I > still oppose to just keeping the text ambiguous. > > -- > JINMEI, Tatuya > > -------------------------------------------------------------------- > --94eb2c0332a60c62ab05383f72f1 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
+1 to the email below. =C2=A0=C2=A0

The= bis doc should acknowledge that old text was deliberately ambiguous and is= now being clarified.=C2=A0 Additionally, the doc should also say =C2=A0&qu= ot;MPTUD, ICMP, AH, IPSec" break if any intermediate node adds an EH h= eader., =C2=A0 It's probably three times already in this mailer that fo= lks have had to answer what breaks. =C2=A0 Lastly, please also mention if t= he rule is not complied with, a new packet checksum needs to be computed. = =C2=A0 There is also potential to leak packets outside of a specific domain= where users may want to add EH by intermediate nodes and then proper recei= ve behavior of nodes breaks down.

Hemant

On Fri, Jul 22, 2016 at= 12:57 PM, =E7=A5=9E=E6=98=8E=E9=81=94=E5=93=89 <jinmei@wide.ad.jp>= wrote:
.

I agree.

And, if the least bad consensus/compromise that this wg could reach is
to leave the ambiguity, I'd at very least like to see text that
explicitly says it was ambiguous in the previous version of the spec
and is still kept ambiguous intentionally due to varied opinions.=C2=A0 I still oppose to just keeping the text ambiguous.

--
JINMEI, Tatuya

--------------------------------------------------------------------

--94eb2c0332a60c62ab05383f72f1-- From nobody Fri Jul 22 16:37:53 2016 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 931CD12DA11 for ; Fri, 22 Jul 2016 16:37:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.199 X-Spam-Level: X-Spam-Status: No, score=-1.199 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, HK_RANDOM_FROM=0.999, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=no 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 AikK3wElZyfb for ; Fri, 22 Jul 2016 16:37:49 -0700 (PDT) Received: from mail-vk0-x234.google.com (mail-vk0-x234.google.com [IPv6:2607:f8b0:400c:c05::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 D07A912D7A4 for <6man@ietf.org>; Fri, 22 Jul 2016 16:37:48 -0700 (PDT) Received: by mail-vk0-x234.google.com with SMTP id w127so177392788vkh.2 for <6man@ietf.org>; Fri, 22 Jul 2016 16:37:48 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc; bh=lgfplilZYBKjHEoza2Xi17qfzmzvflO2d2hd1lJvfaA=; b=tYaH+d3MxywySh98M4qU0yg37fd1720ONNOCTXNKmzHUisYuy+64Idxw+7UTB4gT+1 VBDg757oG5Yj6Xqyiy6xg7S9R8m5E/XjE/43YLJvE1quuTwdY+OmgXmS1bc2gtOj2exn qQ0OzK4i17vH+RJxpNV69pHXvvvxHo+Ss3r6wFPeiCjmVrSdY+dui6TV1y9UgDF5hWWm +T0dkOf26qzfoUkKrX9TPXoWTVq7yn9krKamQdvYZKda1JWKPazRwpMQ/uQmR94qpqt6 BMLyEJU3XLgqBCQv5aYOtiXRIFyHRMJlhS646ntp/xfCfLeGAQDsuGFMiePtTLSb8os8 Uz8g== 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; bh=lgfplilZYBKjHEoza2Xi17qfzmzvflO2d2hd1lJvfaA=; b=AED0xqPI/HGgbGagJx493pgZAzDRGPoPSlKHxfqe90lA5n6rJ4OrsXbylasgk51Ln3 2Jq7KXwnUK6aTNiKhuOGRtAEuXqtMvLcBy3McbQpEIWc1/5cwb9Yilf7J6KcIeaY1sYi AqoJevto0ttTLQGAUdIyckJhwCYVza+/XNbAwXH+V831SUhQbGz5trJMJGmQvsQgrHZs G3r8t7YHNXv8ddd6ZqHvHsZpEdbd2L+vFYYJ83zz/cRZ0FUIFiXRNukRer3Z54NEFQBO YcaBIKXxpfGp+dr/dh+ul8bxqSGUbOKJ2QMuMc3InNA/nona9azqow3FDsNkgKB69RXK /b0A== X-Gm-Message-State: AEkoouuKlyhnidg7bwAxK8Qrn5iqqY9sLGnWJRIpSd2sifxZ0XLnkBNYc5qF6hwV+4rbUUTi8Sx4jxmb8LiVzA== MIME-Version: 1.0 X-Received: by 10.159.55.199 with SMTP id q65mr3295791uaq.125.1469230667805; Fri, 22 Jul 2016 16:37:47 -0700 (PDT) Received: by 10.159.39.233 with HTTP; Fri, 22 Jul 2016 16:37:47 -0700 (PDT) Received: by 10.159.39.233 with HTTP; Fri, 22 Jul 2016 16:37:47 -0700 (PDT) In-Reply-To: References: <26582.1468923195@obiwan.sandelman.ca> <2EBFA6F2-00A3-45E1-BE0E-3531AF75726A@employees.org> <787AE7BB302AE849A7480A190F8B933008DE9E22@OPEXCLILMA3.corporate.adroot.infra.ftgroup> <0445fd4c-3d96-73f5-035e-570f165faf9b@gmail.com> <614711c4-9e69-3ddc-67f2-0d20394169ad@si6networks.com> <3edee5c1-3444-bc7d-31e5-1bb29810e857@si6networks.com> Date: Sat, 23 Jul 2016 09:37:47 +1000 Message-ID: Subject: Re: proposed text for header injection revision 05 From: Mark Smith To: Hemant Singh Content-Type: multipart/alternative; boundary=94eb2c04c9a60c3ac0053841ec07 Archived-At: Cc: "Mark Townsley \(townsley\)" , Michael Richardson , "6man@ietf.org" <6man@ietf.org>, =?UTF-8?B?56We5piO6YGU5ZOJ?= , Fernando Gont X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.17 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 Jul 2016 23:37:51 -0000 --94eb2c04c9a60c3ac0053841ec07 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On 23 Jul 2016 6:10 AM, "Hemant Singh" wrote: > > +1 to the email below. > > The bis doc should acknowledge that old text was deliberately ambiguous and is now being clarified. I haven't seen any evidence of international ambiguity. Brian found an email from Steve Deering explicitly stating that if you want to add an EH to a packet you add it via encapsulation within another IPv6 packet. The following is not ambiguous. "With one exception, extension headers are not examined or processed by any node along a packet's delivery path, until the packet reaches the node (or each of the set of nodes, in the case of multicast) identified in the Destination Address field of the IPv6 header." For those claiming it is, you must explain to the rest of us how you insert EHs with out "examining" or "processing" the existing EHs. >Additionally, the doc should also say "MPTUD, ICMP, AH, IPSec" break if any intermediate node adds an EH header., It's probably three times already in this mailer that folks have had to answer what breaks. Lastly, please also mention if the rule is not complied with, a new packet checksum needs to be computed. There is also potential to leak packets outside of a specific domain where users may want to add EH by intermediate nodes and then proper receive behavior of nodes breaks down. > > Hemant > > > On Fri, Jul 22, 2016 at 12:57 PM, =E7=A5=9E=E6=98=8E=E9=81=94=E5=93=89 wrote: >> >> . >> >> I agree. >> >> And, if the least bad consensus/compromise that this wg could reach is >> to leave the ambiguity, I'd at very least like to see text that >> explicitly says it was ambiguous in the previous version of the spec >> and is still kept ambiguous intentionally due to varied opinions. I >> still oppose to just keeping the text ambiguous. >> >> -- >> JINMEI, Tatuya >> >> -------------------------------------------------------------------- > > > > -------------------------------------------------------------------- > IETF IPv6 working group mailing list > ipv6@ietf.org > Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 > -------------------------------------------------------------------- > --94eb2c04c9a60c3ac0053841ec07 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

On 23 Jul 2016 6:10 AM, "Hemant Singh" <hemantietf@gmail.com> wrote:
>
> +1 to the email below. =C2=A0=C2=A0
>
> The bis doc should acknowledge that old text was deliberately ambiguou= s and is now being clarified.=C2=A0

I haven't seen any evidence of international ambiguity. = Brian found an email from Steve Deering explicitly stating that if you want= to add an EH to a packet you add it via encapsulation within another IPv6 = packet.

The following is not ambiguous.

"With one exception, extension headers are not examined= or processed by any node along a packet's delivery path, until the pac= ket reaches the node (or each of the set of nodes, in the case of multicast= ) identified in the Destination Address field of the IPv6 header."

For those claiming it is, you must explain to the rest of us= how you insert EHs with out "examining" or "processing"= ; the existing EHs.

>Additionally, the doc should also say =C2=A0"MPTUD,= ICMP, AH, IPSec" break if any intermediate node adds an EH header., = =C2=A0 It's probably three times already in this mailer that folks have= had to answer what breaks. =C2=A0 Lastly, please also mention if the rule = is not complied with, a new packet checksum needs to be computed. =C2=A0 Th= ere is also potential to leak packets outside of a specific domain where us= ers may want to add EH by intermediate nodes and then proper receive behavi= or of nodes breaks down.
>
> Hemant
>
>
> On Fri, Jul 22, 2016 at 12:57 PM, =E7=A5=9E=E6=98=8E=E9=81=94=E5=93=89= <jinmei@wide.ad.jp> wrote:<= br> >>
>> .
>>
>> I agree.
>>
>> And, if the least bad consensus/compromise that this wg could reac= h is
>> to leave the ambiguity, I'd at very least like to see text tha= t
>> explicitly says it was ambiguous in the previous version of the sp= ec
>> and is still kept ambiguous intentionally due to varied opinions.= =C2=A0 I
>> still oppose to just keeping the text ambiguous.
>>
>> --
>> JINMEI, Tatuya
>>
>> ------------------------------------------------------------------= --
>
>
>
> -------------------------------------------------------------------- > IETF IPv6 working group mailing list
> ipv6@ietf.org
> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
> -------------------------------------------------------------------- >

--94eb2c04c9a60c3ac0053841ec07-- From nobody Fri Jul 22 17:10:58 2016 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4E47812D603 for ; Fri, 22 Jul 2016 17:10:56 -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 m6Pmp5WEKScx for ; Fri, 22 Jul 2016 17:10:54 -0700 (PDT) Received: from mail-oi0-x236.google.com (mail-oi0-x236.google.com [IPv6:2607:f8b0:4003: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 7EC6612D5A1 for <6man@ietf.org>; Fri, 22 Jul 2016 17:10:54 -0700 (PDT) Received: by mail-oi0-x236.google.com with SMTP id l72so184479485oig.2 for <6man@ietf.org>; Fri, 22 Jul 2016 17:10:54 -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=mkORO7l/9E1c88QPBkNjX8qoJVWAI86aA0sffoVlka8=; b=PWS1lmbcTm4Fbc+WZp1o+QP6pu9ZbkSJL7kXkTwI4wAdPVxhjvbwMBavpCAAG5Bm2D Si9H85qBXJqLozSvzz8DB1gxRhAOPQdv/ulUbxX5Q9xzlfUFKz4d4JvF3dvPFS2k/S/T zNeeXGKdOqiF7snlxIBpkap7C4zX7DHFN8lNMdFQYkKEajBrzH47aykdngimGBh9SuVd j+lsxvyuNHRv0W3j8ZJ74BwboH48gp3DmjbziQitSj6gW9i7zitsj8Chl6N+/buYrkI7 yjVeDqCSRxIwhsjfNzpoqxoTq1Z4s6n3+A43e8T8za75fs+VIeJ3kgm2eXQaj2LlejSy /+FA== 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=mkORO7l/9E1c88QPBkNjX8qoJVWAI86aA0sffoVlka8=; b=gMseQHRB68wGwkqr8vFsCJ/xu+L/+0OTwqmTGByWnNkRvIwA5+i9b0uWW4dQKqX8CE sdtsuFzG7mT9CAos65jhLHlBbG8NG1j7GzXCnWToy2+2Od5DyYrOTReVEEUoSQEB/8gg uzkuTIK1AZmyDHSc8gW8ccLqcyiHkYvfkbyvg7p4QCdLIHrRK9zHm0nbCw0Y+EppLBa9 wwhLCALqFSCNtcQbBew+uQ7y50aD4anmm/brzLykSJpSSy+hMLSSXTYCHqgpqqRXgpsA Tw84pR1gkYzxM0m/oZdipZu0B1ytD0jwhhbxVLSTKjGVFlFn3xAku4Hy5Z9876JAGdie zMgQ== X-Gm-Message-State: AEkoouula6ifYw272JqKWtnV/e2QgoFGNXURlWm8InsMUPSPj6jvFvr+K6thUB4jigHpTTtlB3BQkR8hUYFw1g== X-Received: by 10.157.34.201 with SMTP id y67mr3484690ota.138.1469232653890; Fri, 22 Jul 2016 17:10:53 -0700 (PDT) MIME-Version: 1.0 Received: by 10.182.172.66 with HTTP; Fri, 22 Jul 2016 17:10:53 -0700 (PDT) In-Reply-To: References: <26582.1468923195@obiwan.sandelman.ca> <2EBFA6F2-00A3-45E1-BE0E-3531AF75726A@employees.org> <787AE7BB302AE849A7480A190F8B933008DE9E22@OPEXCLILMA3.corporate.adroot.infra.ftgroup> <0445fd4c-3d96-73f5-035e-570f165faf9b@gmail.com> <614711c4-9e69-3ddc-67f2-0d20394169ad@si6networks.com> <3edee5c1-3444-bc7d-31e5-1bb29810e857@si6networks.com> From: Hemant Singh Date: Fri, 22 Jul 2016 20:10:53 -0400 Message-ID: Subject: Re: proposed text for header injection revision 05 To: Mark Smith Content-Type: multipart/alternative; boundary=94eb2c0332a66d7ac50538426221 Archived-At: Cc: "Mark Townsley \(townsley\)" , Michael Richardson , "6man@ietf.org" <6man@ietf.org>, =?UTF-8?B?56We5piO6YGU5ZOJ?= , Fernando Gont X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.17 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 Jul 2016 00:10:56 -0000 --94eb2c0332a66d7ac50538426221 Content-Type: text/plain; charset=UTF-8 Sorry, my bad for including "intentional". It's just ambiguous related to the term "processed" which is not clear and called out by many others as ambiguous. Hemant On Fri, Jul 22, 2016 at 7:37 PM, Mark Smith wrote: > > I haven't seen any evidence of international ambiguity. Brian found an > email from Steve Deering explicitly stating that if you want to add an EH > to a packet you add it via encapsulation within another IPv6 packet. > > The following is not ambiguous. > > "With one exception, extension headers are not examined or processed by > any node along a packet's delivery path, until the packet reaches the node > (or each of the set of nodes, in the case of multicast) identified in the > Destination Address field of the IPv6 header." > > For those claiming it is, you must explain to the rest of us how you > insert EHs with out "examining" or "processing" the existing EHs. > > > --94eb2c0332a66d7ac50538426221 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Sorry, my bad for including "intentional". =C2= =A0 It's just=C2=A0ambiguous related to the term "processed" = which is not clear and called out by many others as=C2=A0ambiguous.
Hemant

On Fri, Jul 22, 2016 at 7:37 PM, Mark Smith <markzzzsmith@gmail.= com> wrote:


I haven't seen any evidence of international ambi= guity. Brian found an email from Steve Deering explicitly stating that if y= ou want to add an EH to a packet you add it via encapsulation within anothe= r IPv6 packet.

The following is not ambiguous.

"With one exception, extension headers are not examined= or processed by any node along a packet's delivery path, until the pac= ket reaches the node (or each of the set of nodes, in the case of multicast= ) identified in the Destination Address field of the IPv6 header."

For those claiming it is, you must explain to the rest of us= how you insert EHs with out "examining" or "processing"= ; the existing EHs.


--94eb2c0332a66d7ac50538426221-- From nobody Fri Jul 22 19:21:37 2016 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 65A6012D8F9 for ; Fri, 22 Jul 2016 19:21:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.2 X-Spam-Level: X-Spam-Status: No, score=-1.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, FROM_LOCAL_NOVOWEL=0.5, HK_RANDOM_ENVFROM=0.001, HK_RANDOM_FROM=0.999, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=no 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 Eav_d--xyhOM for ; Fri, 22 Jul 2016 19:21:35 -0700 (PDT) Received: from mail-vk0-x22c.google.com (mail-vk0-x22c.google.com [IPv6:2607:f8b0:400c:c05::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 C0D9812D8F4 for <6man@ietf.org>; Fri, 22 Jul 2016 19:21:34 -0700 (PDT) Received: by mail-vk0-x22c.google.com with SMTP id s189so179859966vkh.1 for <6man@ietf.org>; Fri, 22 Jul 2016 19:21:34 -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=pBSFea4Shkg98hcNEgc/Pz7Iy7QW0w4h+YVjbx0yNOw=; b=heol+hws0cJbCXTo9XNDk5pPEu7/xi+EPquf5A4bRz9ACqTg2wXf53lhO4sT6iQIq0 2nYUSEC33BCLW0LLQ640GZO+dHmZv4hH+nn2roJlGODwtYtMerrQo6lH3CWlCKgSchNH HofT+MDWlwAIaoF3iUdVSKh/pcaoFvAsL2+qxUtlYlkZI/m1oDGVXgt1iFijvT9de7g4 IBXuvMW5d67E7/fdr7U5q5V8RMoIAaRdpq+nfeM2Z8DF03P9NTuEKfbM8SOwVzOYFWFO HmSYfMduVXLx8ox7y89EiL0WU5UjPshijIZbDvV6fr83mbDWRn0glZvjhUdK3a3Isbtc myWg== 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=pBSFea4Shkg98hcNEgc/Pz7Iy7QW0w4h+YVjbx0yNOw=; b=GUvkXX9hG2ujfeWnDBEZpQjqEWpIf1P8IkfXee3fqiYtph/w6AmZEkOH2gzmokK77+ dvoXqHhkVfMzpdTEp2IjkB8HpfcnHg0HGVGHSGEI3uGEQQZSNnQ6dXnXB1eeaLFF623d 8pMDmPeDgk8hIo9C+7kTj+JuCFnq37go995/szqjPZLBqNygsS2KtKJnBiwRhdSIa88D +34jCMnEQIWkGVN1PUxHg1pkRb4tKDyAkeolGlz1dxN1crPCTAoSeDV/J7CPCIAYUeMV 8N4b/grwkuVQOWsMYXqyNMDtKLC+Z1hpZIPYEEO7B8FBHBpbQlW1hPgIuIlDeEKNytZI m2nQ== X-Gm-Message-State: AEkoouvLRMPULzh3HiNqJge2dUhjKs+nv0s+qLFXf8cBlOfGC5iDMhefEN/IocdQ+CMkPKN8wY/Kw3YJNiwkRQ== X-Received: by 10.176.2.242 with SMTP id 105mr3578427uah.140.1469240493654; Fri, 22 Jul 2016 19:21:33 -0700 (PDT) MIME-Version: 1.0 Received: by 10.159.39.233 with HTTP; Fri, 22 Jul 2016 19:21:04 -0700 (PDT) In-Reply-To: References: <26582.1468923195@obiwan.sandelman.ca> <2EBFA6F2-00A3-45E1-BE0E-3531AF75726A@employees.org> <787AE7BB302AE849A7480A190F8B933008DE9E22@OPEXCLILMA3.corporate.adroot.infra.ftgroup> <0445fd4c-3d96-73f5-035e-570f165faf9b@gmail.com> <614711c4-9e69-3ddc-67f2-0d20394169ad@si6networks.com> <3edee5c1-3444-bc7d-31e5-1bb29810e857@si6networks.com> From: Mark Smith Date: Sat, 23 Jul 2016 11:51:04 +0930 Message-ID: Subject: Re: proposed text for header injection revision 05 To: Hemant Singh Content-Type: text/plain; charset=UTF-8 Archived-At: Cc: "Mark Townsley \(townsley\)" , Michael Richardson , "6man@ietf.org" <6man@ietf.org>, =?UTF-8?B?56We5piO6YGU5ZOJ?= , Fernando Gont X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.17 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 Jul 2016 02:21:36 -0000 On 23 July 2016 at 09:40, Hemant Singh wrote: > Sorry, my bad for including "intentional". It's just ambiguous related to > the term "processed" which is not clear and called out by many others as > ambiguous. I think the claim of ambiguity is dubious. Processing is what computers do, and these devices are specialised computers. If the word 'processing' hasn't been clarified, then it means performing any actions on the EHs. I think this is what actually happened: 1. Some people thought the way to solve their problem was to insert EHs into existing, in flight packets 2. They didn't consult RFC2460 to see if was acceptable to do that 3. They now want a loophole created in RFC2460bis to accommodate behaviour that isn't permitted, claiming that RFC2460 is ambiguous. I have two fundamental objections: - I've dealt with devices that silently change packets or frames in flight, intentionally or in error, and know how hard they can be to troubleshoot. Packets that are not modified in flight in any way at all would be the ideal, because if the packet that arrived wasn't the packet sent, then something is broken in the network, and network processing of packets would be no more than look at a value or values in the packet fields and then perform the small set of actions necessary to forwarding them.+ - i don't agree with trying to make non-compliant behaviour compliant by creating a spec loophole using a claimed ambiguity, when an understanding of the meaning of the words "examine" and "processed" are fundamental to the field of computing and networking. The heart of a computer is the Central Processing Unit! I understand people have work they've put effort into that would be non-compliant if this loophole isn't created. However, just because the work exists doesn't mean it now has to be accommodated in the specifications. I think the discussion about what and what not to put in regarding what inserting EHs breaks also shows that this area is not fully understood or investigated. I think that is also another sign that the consequences of inserting EHs into existing packets isn't known and complete. It think it needs to be properly understood and documented, and then if the benefits are worth the drawbacks, the specification could be updated to permit it. Regards, Mark. + If you look at the early versions of IP (e.g., RFC675, various IENs), for versions 1 through 3 (1974 through 1978) it seems the only modification of packets that is permitted in the network is fragmentation (which isn't really modification, rather it is replacement of one packet with the creation of multiple new packets carrying the original packet's data). There is no TTL field or hop count field. I think that indicates that during that design period there was an expectation that packets were not to be modified in flight at all, which is the simplest thing to do - just look at them and forward them, no modification required. TTL or Hop Count fields are a reasonable safety measure, however they're per-packet overhead and additional per-hop processing to mitigate what should be a short lived and transient state of a loop. Ideally, if entirely loop free routing protocols had been invented (which was probably the expectation between 1974 and 1978), there'd be no need to have and pay the price of TTL or Hop Count fields in each and every packet and the cost of modifying them at each hop. > Hemant > > On Fri, Jul 22, 2016 at 7:37 PM, Mark Smith wrote: >> >> >> I haven't seen any evidence of international ambiguity. Brian found an >> email from Steve Deering explicitly stating that if you want to add an EH to >> a packet you add it via encapsulation within another IPv6 packet. >> >> The following is not ambiguous. >> >> "With one exception, extension headers are not examined or processed by >> any node along a packet's delivery path, until the packet reaches the node >> (or each of the set of nodes, in the case of multicast) identified in the >> Destination Address field of the IPv6 header." >> >> For those claiming it is, you must explain to the rest of us how you >> insert EHs with out "examining" or "processing" the existing EHs. >> >> > From nobody Fri Jul 22 19:41:20 2016 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3EFDD12DA39 for ; Fri, 22 Jul 2016 19:41:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.2 X-Spam-Level: X-Spam-Status: No, score=-1.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, FROM_LOCAL_NOVOWEL=0.5, HK_RANDOM_ENVFROM=0.001, HK_RANDOM_FROM=0.999, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=no 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 JwgeZhoejjj5 for ; Fri, 22 Jul 2016 19:41:17 -0700 (PDT) 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 5F41412D8F7 for ; Fri, 22 Jul 2016 19:41:17 -0700 (PDT) Received: by mail-vk0-x22b.google.com with SMTP id n129so134968183vke.3 for ; Fri, 22 Jul 2016 19:41:17 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=6KWjCcXcjjH1c1dd2W2h20roIgiK0csJ1iZ4KrSZRQY=; b=w99mzAC7b365E7tXvrnPGE+NwtkSA9nHKYypb+k3GwC3avSYFSIS9QfoFDzsnSpxgo mwz6zx6kQDqX658BFGYgzO6IPdMQdnhUSxmeRiWZX/FSRfU0MvtKRbAg+TSD+VenjKO3 PdpEuYZ4Q8nuWX8fY8ScmZ4F2rHvMfQLrK1hjxtfwEAd0NisEndyvSEvWcLoXD0Ga2VP lFcTNjNXuLykJ81rxRS15E6E9Axj6l5QQt+F1D6lJoOuuojQqW2Z23Mk1lR3A6WRUG50 L317ac39EDP1qEZjzO84r0Ty3lqeSl1Q45uFpLgrBjPuHfSgN2hhXPpGSaN+qilLQ6XS ACag== 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-transfer-encoding; bh=6KWjCcXcjjH1c1dd2W2h20roIgiK0csJ1iZ4KrSZRQY=; b=nNxqDsyV3KHwT+XTZMpyRrr2N+UNZx4IWENQb9Etff63VwwtFVuvRJHiV9WEWWXEkh Ivdrpu0eDlcdD75ZpsmAQPCPzE5vRwQXy1wwnhfiNGAkYmdbF98jniWqnK4g9lY3o6WT FnEuOtAGjKjTldYRrud6qTSE+VMXe9zilGdx+hAl4Y3p1DDN+0k82FGEKhVIFw8PWky6 fanFrxJ+ivAZw0MCizGsinj/9UC/6xlCSuouDJCOKp4IlRw09nIbSfaSENOGeO45HdFj rPj5UXL/VfMMZdTbwbl/xc8UKAH8vYY0UkWWSu+SKO6+pRnqUMRHlm5GEbdmobZTwOS+ GdOg== X-Gm-Message-State: AEkoout3LJ9neIvw9w/nfmJyau0xjXdPjKFXNg2711/LVw9Y7cUkSGyHptbh2sQry7BYyi5SX+zuxFGubIqNig== X-Received: by 10.176.2.242 with SMTP id 105mr3615351uah.140.1469241676447; Fri, 22 Jul 2016 19:41:16 -0700 (PDT) MIME-Version: 1.0 Received: by 10.159.39.233 with HTTP; Fri, 22 Jul 2016 19:40:47 -0700 (PDT) In-Reply-To: <3dc4d07398e249f0a33192001665756d@XCH-RCD-001.cisco.com> References: <201607220911.u6M9Bco9077775@givry.fdupont.fr> <948512bb-c741-0509-8442-2d230c5bca49@gmail.com> <3dc4d07398e249f0a33192001665756d@XCH-RCD-001.cisco.com> From: Mark Smith Date: Sat, 23 Jul 2016 12:10:47 +0930 Message-ID: Subject: Re: proposed text for header injection revision 05 To: "Pascal Thubert (pthubert)" Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Archived-At: Cc: "ipv6@ietf.org" X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.17 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 Jul 2016 02:41:19 -0000 On 22 July 2016 at 21:16, Pascal Thubert (pthubert) wr= ote: > Hello Brian: > > The word "processed" cannot be kept because many intermediate boxes read = the EHs (and transport headers) and act on them. It was indicated at the m= eeting that "reading" is a form of "processing". > > People will not unplug their middle boxes no will they stop adding them, = whatever we write now in a spec. > Formally accommodating middle boxes is actually a formal statement that the IETF don't think end-to-end encryption (more generally Internet confidentiality) is necessary or useful. > We sometimes have discrepancy between the deployed world and the standard= s, e.g. with the HbH EH. The world judges the specs and makes what it can o= f them. It is good that in that particular occasion, this group listened to= the world, and made the processing optional. > > In a more general fashion, publishing a document that is not followed by = the reality of the world does not help. It makes the document less relevant= , I'm afraid. > > For IS level, I'd rather go for a document that is fully relevant, even i= f that means slightly ambiguous. > > Cheers, > > Pascal > >> -----Original Message----- >> From: ipv6 [mailto:ipv6-bounces@ietf.org] On Behalf Of Brian E Carpenter >> Sent: vendredi 22 juillet 2016 11:47 >> To: ipv6@ietf.org >> Subject: Re: proposed text for header injection revision 05 >> >> On 22/07/2016 21:11, Francis Dupont wrote: >> > In your previous mail you wrote: >> > >> >> I think it's clear, if not actually obvious, that the original >> >> intent of >> >> 2460 was that no intermediate IPv6 node would change the length of >> >> an IP datagram. If that's the correct technical approach, then let's >> >> say so explicitly in 2460 bis, and then we can advance it to IS. If >> >> that's not the correct technical approach, then let's change the rul= e and stay >> at PS. >> > >> > =3D> it was so header injection should be forbidden without any text >> > about other approach (i.e, KISS) and the whole stuff advance to IS (as >> > I asked at the mike some meetings ago). >> >> What I seem to have heard this week is that many people think that the >> proposed compromise is ambiguous (which is true) and that >> *therefore* it is not acceptable in an Internet Standard. >> >> If that is the consensus, then it does seem to me that there is no choic= e but to >> state the original (pre-RFC1888) intent that with the exception of HbH, = extension >> headers MUST NOT be modified, inserted or deleted by forwarding nodes. I= n >> terms of the old text, this is just s/processed/processed, modified, ins= erted or >> deleted/ in the appropriate sentence. >> >> (To be clear, that doesn't affect the routing header because it is only = modified >> by the destination host, even though that isn't the final destination of= the >> packet.) >> >> If we do that, we don't require either of the two new paragraphs, but th= ey >> remain valid if we want to keep them. >> >> Brian >> >> -------------------------------------------------------------------- >> 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 Fri Jul 22 19:58:12 2016 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2B05812B039 for ; Fri, 22 Jul 2016 19:58:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.221 X-Spam-Level: X-Spam-Status: No, score=-4.221 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] 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 eE-bYiOKP8dZ for ; Fri, 22 Jul 2016 19:58:10 -0700 (PDT) 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 5E4D112B02F for <6man@ietf.org>; Fri, 22 Jul 2016 19:58:10 -0700 (PDT) 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 u6N2w90F053188; Fri, 22 Jul 2016 19:58:09 -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 u6N2w8CN053184 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=OK); Fri, 22 Jul 2016 19:58:08 -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.1178.4; Fri, 22 Jul 2016 19:58:08 -0700 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.1178.000; Fri, 22 Jul 2016 19:58:08 -0700 From: "Manfredi, Albert E" To: Mark Smith Subject: RE: proposed text for header injection revision 05 Thread-Topic: proposed text for header injection revision 05 Thread-Index: AQHR43EgnpSV4pcNgEix9r4HF1U/yaAlIsYAgAA+QgCAADGIgIAACUCAgAAkXwD//5MMUA== Date: Sat, 23 Jul 2016 02:58:08 +0000 Message-ID: <6c188e4e509d4b84917098a47659a06e@XCH15-06-11.nw.nos.boeing.com> References: <26582.1468923195@obiwan.sandelman.ca> <2EBFA6F2-00A3-45E1-BE0E-3531AF75726A@employees.org> <787AE7BB302AE849A7480A190F8B933008DE9E22@OPEXCLILMA3.corporate.adroot.infra.ftgroup> <0445fd4c-3d96-73f5-035e-570f165faf9b@gmail.com> <614711c4-9e69-3ddc-67f2-0d20394169ad@si6networks.com> <3edee5c1-3444-bc7d-31e5-1bb29810e857@si6networks.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: "6man@ietf.org" <6man@ietf.org> X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.17 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 Jul 2016 02:58:12 -0000 > -----Original Message----- > From: ipv6 [mailto:ipv6-bounces@ietf.org] On Behalf Of Mark Smith > I think this is what actually happened: >=20 > 1. Some people thought the way to solve their problem was to insert > EHs into existing, in flight packets > 2. They didn't consult RFC2460 to see if was acceptable to do that > 3. They now want a loophole created in RFC2460bis to accommodate > behaviour that isn't permitted, claiming that RFC2460 is ambiguous. >=20 > I have two fundamental objections: >=20 > - I've dealt with devices that silently change packets or frames in > flight, intentionally or in error, and know how hard they can be to > troubleshoot. Packets that are not modified in flight in any way at > all would be the ideal, because if the packet that arrived wasn't the > packet sent, then something is broken in the network, and network > processing of packets would be no more than look at a value or values > in the packet fields and then perform the small set of actions > necessary to forwarding them.+ >=20 > - i don't agree with trying to make non-compliant behaviour compliant > by creating a spec loophole using a claimed ambiguity, when an > understanding of the meaning of the words "examine" and "processed" > are fundamental to the field of computing and networking. The heart of > a computer is the Central Processing Unit! >=20 > I understand people have work they've put effort into that would be > non-compliant if this loophole isn't created. However, just because > the work exists doesn't mean it now has to be accommodated in the > specifications. +1. That's why, in my opinion, the only way to wiggle out of this state of = affairs to is require that the datagram be restored to its original self, b= efore delivery to the destination host or to the next administrative domain= downstream (whichever comes first). Although this measure would not automatically exonerate those networks that= want to continue to corrupt packets left and right, and are looking for ab= solution. I think the practice does go against the intent of RFC 2460, and = there's no way around that. Bert From nobody Sat Jul 23 04:39:55 2016 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C3BA212DA34 for ; Sat, 23 Jul 2016 04:39:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.188 X-Spam-Level: X-Spam-Status: No, score=-3.188 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-1.287, SPF_PASS=-0.001] 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 sAgz94IZqEsA for ; Sat, 23 Jul 2016 04:39:53 -0700 (PDT) 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 D82E712D0AC for ; Sat, 23 Jul 2016 04:39:52 -0700 (PDT) Received: from sandelman.ca (obiwan.sandelman.ca [IPv6:2607:f0b0:f:2::247]) by tuna.sandelman.ca (Postfix) with ESMTP id DEA53203AD; Sat, 23 Jul 2016 07:49:32 -0400 (EDT) Received: from obiwan.sandelman.ca (localhost [IPv6:::1]) by sandelman.ca (Postfix) with ESMTP id CF094638BE; Sat, 23 Jul 2016 07:39:51 -0400 (EDT) From: Michael Richardson To: 6man WG , otroan@employees.org Subject: Re: proposed text for header injection revision 05 In-Reply-To: References: <201607220911.u6M9Bco9077775@givry.fdupont.fr> <948512bb-c741-0509-8442-2d230c5bca49@gmail.com> X-Mailer: MH-E 8.6; nmh 1.6+dev; GNU Emacs 24.5.1 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.17 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 Jul 2016 11:39:55 -0000 --=-=-= Content-Type: text/plain otroan@employees.org wrote: > With one exception, extension headers are not examined or processed > by any node along a packet's delivery path, until the packet reaches > the node (or each of the set of nodes, in the case of multicast) > identified in the Destination Address field of the IPv6 header. > (I don't know of a single router implementation or deployment that does > not violate this though. okay, they examined, and the result affects the processing of the packet, but are they mutated by all router implementations? > If we want to take deployment experience into account, it would make > more sense to remove that paragraph than to strengthen it.) I think that this is key: We need a document that reflects what really happens out there, as this has material impact on what we can do in the future. (I think that the biggest argument for not mutilating packets in the middle is because that's how we got NAT and SPUD/PLUS/etc. I'd rather document how to do safe, sane (and consensual[%]) changes to packets.) [%]-https://en.wikipedia.org/wiki/Safe,_sane_and_consensual -- Michael Richardson , Sandelman Software Works -= IPv6 IoT consulting =- --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 iQEVAwUBV5NXhYCLcPvd0N1lAQKkiQf/eBpLzX619KwG30AhQ2BToX5nJhhIf0Ul F94l94l/1SDSWfgXTpRedooC8tk9mjADyYRYss2oArv2lbEQKsxbAEiAODh1n7AC /1KgHGhGcXFBXsYndIBXS6N7IbXHwqQYLhiztWqheP34XccG4iXCyo0ngXN1EMBh BZ7EfAR+NmFTfel5e3b2+049uvcSQuZM0I1FdU+FbGeOlQ7H1+akpZ27lLtRQmDm COcaoHEbo+rXkhaS057I6UfTX0ihImHuVXJ535Agto7jBaCcl8lw0xAjnKL02Pzp ZxKmiT8CCnPGrxlca9WMJOvUBY5Ol7S7gs5g7OEmzeHTdtN7BtzeRw== =DFCI -----END PGP SIGNATURE----- --=-=-=-- From nobody Sat Jul 23 04:41:14 2016 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9DB8912DAA4 for ; Sat, 23 Jul 2016 04:41:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.188 X-Spam-Level: X-Spam-Status: No, score=-3.188 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-1.287, SPF_PASS=-0.001] 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 lwiMJv-Kp4Af for ; Sat, 23 Jul 2016 04:41:11 -0700 (PDT) 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 5C3BA12DAA0 for ; Sat, 23 Jul 2016 04:41:11 -0700 (PDT) Received: from sandelman.ca (obiwan.sandelman.ca [IPv6:2607:f0b0:f:2::247]) by tuna.sandelman.ca (Postfix) with ESMTP id 90F57203AD; Sat, 23 Jul 2016 07:50:51 -0400 (EDT) Received: from obiwan.sandelman.ca (localhost [IPv6:::1]) by sandelman.ca (Postfix) with ESMTP id 776F2638BE; Sat, 23 Jul 2016 07:41:10 -0400 (EDT) From: Michael Richardson To: Brian E Carpenter Subject: Re: proposed text for header injection revision 05 In-Reply-To: References: <201607220911.u6M9Bco9077775@givry.fdupont.fr> <948512bb-c741-0509-8442-2d230c5bca49@gmail.com> X-Mailer: MH-E 8.6; nmh 1.6+dev; GNU Emacs 24.5.1 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.17 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 Jul 2016 11:41:12 -0000 --=-=-= Content-Type: text/plain Brian E Carpenter wrote: > Sorry about this but I thought we had compromise wording. Now it seems > we don't. We got rather rough consensus around ambiguous language because that language permitted everyone to interpret it their way. -- Michael Richardson , Sandelman Software Works -= IPv6 IoT consulting =- --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 iQEVAwUBV5NX04CLcPvd0N1lAQIDMwgAt/4H/QeD/npWDlBgOE5OquJgWgphqm3S jxerwaWUIPY3xOfsEcZhBxBXaKdFqiIGduADROW9n4o2WElTbelxrZqr/hsDqPm9 PFD0B9w6+MVxI4F6co3K3tRr8Lfdr92NPa+al71s5AR6lde5U0tIEgBnN5/IcJHG 8gZFvkXuL6DSIWWw5X/yyRPuILO7n5fGyT2FCRAWf/7582K8LS629oh9yx/hMxny XZdrfkOgg/iaw6JkWXuSwV3zHY58CoadQ4uGJIroLjxViZEI7qWm+pvR02J94UeS ht8dlkj9j6lbPWtNf8Q+UXsMkBOZIZE0JS0Hbl/q9zicHYdffylf5w== =tjPQ -----END PGP SIGNATURE----- --=-=-=-- From nobody Sat Jul 23 04:44:52 2016 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 34B4512D898 for ; Sat, 23 Jul 2016 04:44:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.188 X-Spam-Level: X-Spam-Status: No, score=-3.188 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-1.287, SPF_PASS=-0.001] 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 lZSISAzOscOD for ; Sat, 23 Jul 2016 04:44:50 -0700 (PDT) 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 DCEF212D134 for <6man@ietf.org>; Sat, 23 Jul 2016 04:44:49 -0700 (PDT) Received: from sandelman.ca (obiwan.sandelman.ca [209.87.249.21]) by tuna.sandelman.ca (Postfix) with ESMTP id 2195D203AD for <6man@ietf.org>; Sat, 23 Jul 2016 07:54:30 -0400 (EDT) Received: from obiwan.sandelman.ca (localhost [IPv6:::1]) by sandelman.ca (Postfix) with ESMTP id 0B166638BE for <6man@ietf.org>; Sat, 23 Jul 2016 07:44:49 -0400 (EDT) From: Michael Richardson To: "6man\@ietf.org" <6man@ietf.org> Subject: Re: proposed text for header injection revision 05 In-Reply-To: References: <26582.1468923195@obiwan.sandelman.ca> <2EBFA6F2-00A3-45E1-BE0E-3531AF75726A@employees.org> <787AE7BB302AE849A7480A190F8B933008DE9E22@OPEXCLILMA3.corporate.adroot.infra.ftgroup> <0445fd4c-3d96-73f5-035e-570f165faf9b@gmail.com> <614711c4-9e69-3ddc-67f2-0d20394169ad@si6networks.com> <3edee5c1-3444-bc7d-31e5-1bb29810e857@si6networks.com> X-Mailer: MH-E 8.6; nmh 1.6+dev; GNU Emacs 24.5.1 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.17 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 Jul 2016 11:44:51 -0000 --=-=-= Content-Type: text/plain Hemant Singh wrote: > ambiguous and is now being clarified. Additionally, the doc should > also say "MPTUD, ICMP, AH, IPSec" break if any intermediate node adds To be clear: it breaks IPsec AH, but has no affect on IPsec ESP. I'd love to hear that IPsec AH is widely used somewhere, but I have no evidence of it. The last time I thought AH might have been useful was when defining SEND, but it turned out to be impossible due to an unfortunate way we overspecified what to do when the SPI# isn't recognized. I think that PMTUD is already broken, so I don't put much value on that argument. I'm not in favour of adding/removing headers in the middle; I just want some technical arguments that hold water. -- Michael Richardson , Sandelman Software Works -= IPv6 IoT consulting =- --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 iQEVAwUBV5NYroCLcPvd0N1lAQKaTAgAswaN3JyF6VuKZbBdp4jR36GOdaCPdMkP RKSv+GWG8A3ZKRXSUMKESvF5E8vhz0ivbE/D6f6a8RX3CtAlBI7PJkuBCz7byYSN ueg/ig3hYHlKr3ZaYtcV9O/R3j8E2lDu5umTOCoO0KRMe+i68cUTTgzaHPy0Ecfz 2/xwCkkOwTI+bgGls1h83+ZZ/D2zGtkhuWRPbR36xpcc2gQ+l3r1qZ0QIrU7hwTy Q7YkH71NdbbsLa+mNny41ipLW90fuJpqZpcIKB8z1SHfmXXySiKwtdp2wTSnCJAQ pm9+VUpG2Vw7cVSxB3yZCEfCxlOhZD1sz0iw297C+I6WUzbWWWmEzg== =sy4B -----END PGP SIGNATURE----- --=-=-=-- From nobody Sat Jul 23 07:43:23 2016 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EA93512D0E6 for ; Sat, 23 Jul 2016 07:43:21 -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 pLKp_IfSaSh7 for ; Sat, 23 Jul 2016 07:43:20 -0700 (PDT) Received: from mail-oi0-x22e.google.com (mail-oi0-x22e.google.com [IPv6:2607:f8b0:4003: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 58844127071 for <6man@ietf.org>; Sat, 23 Jul 2016 07:43:20 -0700 (PDT) Received: by mail-oi0-x22e.google.com with SMTP id l65so199477789oib.1 for <6man@ietf.org>; Sat, 23 Jul 2016 07:43:20 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=t74gffMSRD2KzeyFs9caGKgyXPbaDDnyJTwR0F6CtDE=; b=pk84/1Cux6QQ+rEsZM/9ipcLGVI6ALAy7lquxLR8JxQTfidcOgI68Mj3FSOaLJvETJ ugz5iT/LWbFlhRjFz6lDmaYSH2rKjXERdEOsqR4FHH78In/F+PtUnNO59Q60djmCOXzu wlz589FDgi7VxlVm/ab0MOSM4iX+JXVEc3eHMVRNj0ilBxIvDRsyEt9vUDkcoHaCuZ+6 ADlzXPXzAsYBaQIYjsRMpGWuD7IHfP7NO/3na/5Ri1WDqj0gDAHmnwAjbBDFf3VEsmA8 uFVYJhaZjLAx46oivxdxcOJTMtO7KeAFeod2roZe4Df+ZSttaHstnwJHj0QrV5FlfED1 4YQA== 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=t74gffMSRD2KzeyFs9caGKgyXPbaDDnyJTwR0F6CtDE=; b=NkNvrz5gXM+nIqkzuxvYDilEScOWrSzT3WRTRusj7M3S1nQ96NHwB0PvuHZh/XPjT3 H3pbShkJ++n7Np5QlUlycygdkadOIYXv+7hwZ8mF8HqJ82BhtQueZtRR+ZdgErt45AnZ uwJ4ZDf8vm9Ofo6xa9mtuk34bZu6LGIlrEeY72qYvRZ1Ymf3JSXoduBkO4kNIhMLWWG7 C+KzhAtHT5VPCt8i/mbTcYay1RAZxfpOwEtjsHNOLcS/VoA19e6TPfJ6wP3CtqItBNa5 k838XFNHlcpxGlsrbQtzr0NpXyRb9E41/L11rALhBfGfYtyjvyCFSotepb0QEWEAbO6Z pTQw== X-Gm-Message-State: AEkoouuR14f7mAYVFIUPZjzd3uEy4EdujtuxzRSAZlN6C3c4BzHCnN1aBCbSQSfWPkYNazatT2HkdN8kOIWknw== X-Received: by 10.202.190.69 with SMTP id o66mr5167098oif.7.1469284999647; Sat, 23 Jul 2016 07:43:19 -0700 (PDT) MIME-Version: 1.0 Received: by 10.182.172.66 with HTTP; Sat, 23 Jul 2016 07:43:18 -0700 (PDT) In-Reply-To: References: <26582.1468923195@obiwan.sandelman.ca> <2EBFA6F2-00A3-45E1-BE0E-3531AF75726A@employees.org> <787AE7BB302AE849A7480A190F8B933008DE9E22@OPEXCLILMA3.corporate.adroot.infra.ftgroup> <0445fd4c-3d96-73f5-035e-570f165faf9b@gmail.com> <614711c4-9e69-3ddc-67f2-0d20394169ad@si6networks.com> <3edee5c1-3444-bc7d-31e5-1bb29810e857@si6networks.com> From: Hemant Singh Date: Sat, 23 Jul 2016 10:43:18 -0400 Message-ID: Subject: Re: proposed text for header injection revision 05 To: Mark Smith Content-Type: multipart/alternative; boundary=001a113dd2947ab3bc05384e92c5 Archived-At: Cc: "Mark Townsley \(townsley\)" , Michael Richardson , "6man@ietf.org" <6man@ietf.org>, =?UTF-8?B?56We5piO6YGU5ZOJ?= , Fernando Gont X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.17 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 Jul 2016 14:43:22 -0000 --001a113dd2947ab3bc05384e92c5 Content-Type: text/plain; charset=UTF-8 Some obvious use cases should be considered. Some folks have said we have a controlled closed domain where we remove added headers before the packet egresses the domain. But what about an ICMP error in such a domain leaking out? What happens when tunnels are used - the original packet was modified by a middle node with an EH, the packet is later encapsulated in a tunnel by another node. What closed domain boundary can catch such a packet? See Erik Nordmark's April 6th, 2016 email on this thread. Additionally, a middle node can also initiate an attack by adding an EH with a bogus next header value, which downstream nodes don't recognize and drop the packet; a source node can do the same. Hemant On Fri, Jul 22, 2016 at 10:21 PM, Mark Smith wrote: > > > > I think the discussion about what and what not to put in regarding > what inserting EHs breaks also shows that this area is not fully > understood or investigated. I think that is also another sign that the > consequences of inserting EHs into existing packets isn't known and > complete. It think it needs to be properly understood and documented, > and then if the benefits are worth the drawbacks, the specification > could be updated to permit it. > > > Regards, > Mark. > > > > > > > > --001a113dd2947ab3bc05384e92c5 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Some obvious use cases should be considered. =C2=A0 Some f= olks have said we have a controlled closed domain where we remove added hea= ders before the packet egresses the domain. =C2=A0 But what about an ICMP e= rror in such a domain leaking out? What happens when tunnels are used - the= original packet was modified by a middle node with an EH, the packet is la= ter encapsulated in a tunnel by another node.=C2=A0 What closed domain boun= dary can catch such a packet?=C2=A0 See Erik Nordmark's April 6th, 2016= email on this thread.

Additionally, a middle node can a= lso initiate an attack by adding an EH with a bogus next header value, whic= h downstream nodes don't recognize and drop the packet; a source node c= an do the same.


Hemant


On Fri, Jul 22, 2016 at= 10:21 PM, Mark Smith <markzzzsmith@gmail.com> wrote:



I think the discussion about what and what not to put in regarding
what inserting EHs breaks also shows that this area is not fully
understood or investigated. I think that is also another sign that the
consequences of inserting EHs into existing packets isn't known and
complete. It think it needs to be properly understood and documented,
and then if the benefits are worth the drawbacks, the specification
could be updated to permit it.


Regards,
Mark.








--001a113dd2947ab3bc05384e92c5-- From nobody Sat Jul 23 12:09:19 2016 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5E75512B068 for ; Sat, 23 Jul 2016 12:09:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-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 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 ilgnHP-d_hcT for ; Sat, 23 Jul 2016 12:09:15 -0700 (PDT) Received: from mail-wm0-x229.google.com (mail-wm0-x229.google.com [IPv6:2a00:1450:400c:c09::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 5414A128874 for ; Sat, 23 Jul 2016 12:09:15 -0700 (PDT) Received: by mail-wm0-x229.google.com with SMTP id o80so106113838wme.1 for ; Sat, 23 Jul 2016 12:09:15 -0700 (PDT) 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-transfer-encoding; bh=jRXy7XfK0AVWfxp7wVARhyy9UBu63FweHEbhcWaktRM=; b=tdCkaDgbaKGgYkTLgDIUSxCA8u67L2p2AEez8s0qVXqHMUwG7Ay0QEXukup9KKmXg/ lyiH23Q7P4rf2ub4BtU9JNq2ttqW7NBXw1M1ItAAJELic8QkgCo58AiHZPX5m7yI9VM6 B/eQO3mqj27azD4J9DGMyK1+vJQrAMDpK6rGSUiBy9gcrkc5377LEX7z/+s7DgHDzsZ1 ifZq71h8wmqn+5NkARz7moRY2MQ1ZTboxc9/au+IAzoH16eLkME9nIZjbAYatkAokqlW /obh/fB2PP1PQ7fPlpQrhzEebf6IVYy6337dSnjAJEv2E4ejI8psiP9Gz6QALdDc7hc5 rSEw== 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-transfer-encoding; bh=jRXy7XfK0AVWfxp7wVARhyy9UBu63FweHEbhcWaktRM=; b=Iev5yewF3+AuPncpjIbvJHUoqfacXWGBdSeJOqwuyVmV9GlbPcMti6X3tUD4JgKYlw K9r3AV3hCjBqyAb8R6/ALs9VdRGnb9lBv0QlzzgPli04LJ8E47B1aB3qfaECBTc/qlt/ sHMPlv5JaTMbcxJGsmCByjmazIK/Rc9VwndlWpoJFYeNCEm0J3l90r3Q3LDNZXIaCtlV DG+0XYbKp8n5nJFA5jSzMEefbaDsvt7qNaU6q1HN8anvnyzGaJH7f0RWXmN4PtKWrqYE d7g+1IjyE0GH3Wl+/J8hVMYkwRsAWNduLCmXydK+DtHbTPXo3MvyEDSqm5yi5lw5WRpg PPeQ== X-Gm-Message-State: AEkoouvKly32QvNG/KjK2x1okpQpXDYSXnfioC/0behz17LMufH1zY8e73z9n9D3mcnb+g== X-Received: by 10.28.125.80 with SMTP id y77mr11965822wmc.25.1469300953628; Sat, 23 Jul 2016 12:09:13 -0700 (PDT) Received: from [10.54.82.123] ([88.128.80.134]) by smtp.gmail.com with ESMTPSA id g8sm7151454wjj.48.2016.07.23.12.09.12 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sat, 23 Jul 2016 12:09:12 -0700 (PDT) Subject: Re: proposed text for header injection revision 05 To: ipv6@ietf.org References: <26582.1468923195@obiwan.sandelman.ca> <2EBFA6F2-00A3-45E1-BE0E-3531AF75726A@employees.org> <787AE7BB302AE849A7480A190F8B933008DE9E22@OPEXCLILMA3.corporate.adroot.infra.ftgroup> <0445fd4c-3d96-73f5-035e-570f165faf9b@gmail.com> <614711c4-9e69-3ddc-67f2-0d20394169ad@si6networks.com> <3edee5c1-3444-bc7d-31e5-1bb29810e857@si6networks.com> From: Brian E Carpenter Organization: University of Auckland Message-ID: Date: Sun, 24 Jul 2016 07:09:11 +1200 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.2.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.17 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 Jul 2016 19:09:17 -0000 Hemant, On 24/07/2016 02:43, Hemant Singh wrote: > Some obvious use cases should be considered. Some folks have said we have > a controlled closed domain where we remove added headers before the packet > egresses the domain. But what about an ICMP error in such a domain > leaking out? What happens when tunnels are used - the original packet was > modified by a middle node with an EH, the packet is later encapsulated in a > tunnel by another node. What closed domain boundary can catch such a > packet? See Erik Nordmark's April 6th, 2016 email on this thread. > > Additionally, a middle node can also initiate an attack by adding an EH > with a bogus next header value, which downstream nodes don't recognize and > drop the packet; a source node can do the same. They can do that whatever we write in RFCs, so I don't think that's a convincing argument. A more sinister attack is to use an extension header to exploit a buffer overflow bug in a target system, but again: they can do that whatever we write in RFCs. I agree that we could consider a local-use model (already allowed for diffserv bits) but I see that as a topic for *after* we fix the Internet-wide standard. I would remond people, however, that we've had local-use model for diffserv for almost 20 years and TSVWG is still debating how to standardise inter-domain aspects of diffserv. Brian > > > Hemant > > > On Fri, Jul 22, 2016 at 10:21 PM, Mark Smith wrote: > >> >> >> >> I think the discussion about what and what not to put in regarding >> what inserting EHs breaks also shows that this area is not fully >> understood or investigated. I think that is also another sign that the >> consequences of inserting EHs into existing packets isn't known and >> complete. It think it needs to be properly understood and documented, >> and then if the benefits are worth the drawbacks, the specification >> could be updated to permit it. >> >> >> Regards, >> Mark. >> >> >> >> >> >> >> >> > > > > -------------------------------------------------------------------- > IETF IPv6 working group mailing list > ipv6@ietf.org > Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 > -------------------------------------------------------------------- > From nobody Sat Jul 23 15:44:58 2016 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1647412B027 for ; Sat, 23 Jul 2016 15:44:57 -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 LF4KDrgDsCzP for ; Sat, 23 Jul 2016 15:44:55 -0700 (PDT) Received: from mail-oi0-x234.google.com (mail-oi0-x234.google.com [IPv6:2607:f8b0:4003:c06::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 4FD171288B8 for ; Sat, 23 Jul 2016 15:44:55 -0700 (PDT) Received: by mail-oi0-x234.google.com with SMTP id l72so208498052oig.2 for ; Sat, 23 Jul 2016 15:44:55 -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=9pZ/pq3svepFq3gLyML1fQitbyEGv52hc79Y4gQXh+k=; b=AJ/rmvMvG9ipJphEVkr3GlLkoSzGFgzZ30KuKwes/Y/Muj+5PapSIKxWv/w2Ep8fOJ r7HQr6W8zlw3ZeDIzJLW702e7ar45MBus+muvPxdtSk2/7V6ClaN42ZZeUTk9E/4tNwN wtD11Pxrqn2XGG2OZ0mc3DSL6hEqkZK6BMA66c+uV4M/A3qv+A6Wi+6shJxTpFBe9ylm Vy8eg545fZtWTUUmJ839+QymtA22m/65e7rYb5oT2en59hOOw5RMjw3tqjuVGhIMKqt3 aLXHR8x4KAngH2mqp+RWzj4GbMOlMquFB0FOKFGs8Gwxt59EI+a2uZOmPsaNMhqOkKZn 5uYg== 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=9pZ/pq3svepFq3gLyML1fQitbyEGv52hc79Y4gQXh+k=; b=GAiLROTuJ3ULMizyDP5vqlkLpeM+diy1vUOReXStim1tCivj/xf3Z8I8xejppgh8Pj muqNWy3MczPgovI4QhEBlrGcQuCTAw2JqYKwcSTbwX4tZC5x0iPM9SylxaRuKQcZA+1b uv70f6EJEpdlyq0i23MxdT69DN0yl6tg4KMwMFJqVFt1C5yt31oBfhWouYpMyvxMyMnH 137vzzV5iofFPs1TsDuhtiQN4bXIGIHaaMUr3NA8OGRf3yqub9IrMEBNd9hLpCF6hq8O kvMISIgaCSGoklvMlIGkDmrnvfFWnKoS2qiDnpUifUm75KHnjNkzM+RRjxwiL2ov7JZz L3UQ== X-Gm-Message-State: AEkoouvg6StFHg7IcIGtRxJXv7278I9Rrrd6Yl9ohLaherGeU6cKES/czzR9KsE7Y/JnJZj07qeU6VAwUFcJSw== X-Received: by 10.202.213.135 with SMTP id m129mr5279318oig.89.1469313894651; Sat, 23 Jul 2016 15:44:54 -0700 (PDT) MIME-Version: 1.0 Received: by 10.182.172.66 with HTTP; Sat, 23 Jul 2016 15:44:53 -0700 (PDT) In-Reply-To: References: <26582.1468923195@obiwan.sandelman.ca> <2EBFA6F2-00A3-45E1-BE0E-3531AF75726A@employees.org> <787AE7BB302AE849A7480A190F8B933008DE9E22@OPEXCLILMA3.corporate.adroot.infra.ftgroup> <0445fd4c-3d96-73f5-035e-570f165faf9b@gmail.com> <614711c4-9e69-3ddc-67f2-0d20394169ad@si6networks.com> <3edee5c1-3444-bc7d-31e5-1bb29810e857@si6networks.com> From: Hemant Singh Date: Sat, 23 Jul 2016 18:44:53 -0400 Message-ID: Subject: Re: proposed text for header injection revision 05 To: Brian E Carpenter Content-Type: multipart/alternative; boundary=001a113b0606c11e780538554ca8 Archived-At: Cc: IPv6 X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.17 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 Jul 2016 22:44:57 -0000 --001a113b0606c11e780538554ca8 Content-Type: text/plain; charset=UTF-8 As MarkZZZ said, extension headers are not well understood. Further, we have to look into use-case models. Why not combine all this pending work in a new draft that collects requirements and use cases for the extension headers processing by middle nodes. This way guidance is available to the community, But let's move rfc2460bis forward. Here is text to help move the bis doc forward. OLD: With one exception, extension headers are not examined or processed NEW: With one exception, by default, extension headers are not examined or processed Now implementations on middle nodes are free to do what they want and the default behavior is not examine and process EH by a middle node., Hemant On Sat, Jul 23, 2016 at 3:09 PM, Brian E Carpenter < brian.e.carpenter@gmail.com> wrote: > > > They can do that whatever we write in RFCs, so I don't think that's a > convincing argument. A more sinister attack is to use an extension header > to exploit a buffer overflow bug in a target system, but again: they can > do that whatever we write in RFCs. > > I agree that we could consider a local-use model (already allowed for > diffserv bits) but I see that as a topic for *after* we fix the > Internet-wide standard. I would remond people, however, that we've had > local-use model for diffserv for almost 20 years and TSVWG is still > debating how to standardise inter-domain aspects of diffserv. > > Brian > > --001a113b0606c11e780538554ca8 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
As MarkZZZ said, extension headers are not well understood= .=C2=A0 Further, we have to look into use-case models. =C2=A0 Why not combi= ne all this pending work in a new draft that collects requirements and use = cases for the extension headers processing by middle nodes. =C2=A0 This way= guidance is available to the community, =C2=A0 But let's move rfc2460b= is forward.=C2=A0 Here is text to help move the bis doc forward.

OLD:

With one exception, extension header= s are not examined or processed

NEW:

=


With one exception, by default, extension header=
s are not examined or processed

= 

Now implementations on middle node=
s are free to do what they want and the default behavior is not examine and=
 process EH by a middle node.,

Hemant


<= div class=3D"gmail_quote">On Sat, Jul 23, 2016 at 3:09 PM, Brian E Carpente= r <brian.e.carpenter@gmail.com> wrote:


They can do that whatever we write in RFCs, so I don't think tha= t's a
convincing argument. A more sinister attack is to use an extension header to exploit a buffer overflow bug in a target system, but again: they can do that whatever we write in RFCs.

I agree that we could consider a local-use model (already allowed for
diffserv bits) but I see that as a topic for *after* we fix the
Internet-wide standard. I would remond people, however, that we've had<= br> local-use model for diffserv for almost 20 years and TSVWG is still
debating how to standardise inter-domain aspects of diffserv.

=C2=A0 =C2=A0 Brian


--001a113b0606c11e780538554ca8-- From nobody Mon Jul 25 03:45:58 2016 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DAF1812D79B for ; Mon, 25 Jul 2016 03:45:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -15.808 X-Spam-Level: X-Spam-Status: No, score=-15.808 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.287, 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 iLF3ofQV-0NB for ; Mon, 25 Jul 2016 03:45:56 -0700 (PDT) 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 CD97812D5BF for ; Mon, 25 Jul 2016 03:45:55 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=896; q=dns/txt; s=iport; t=1469443555; x=1470653155; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=VYRoe9uTb3SpRE2bhZg1VQMxidUerhpvxiMQLX6CGn8=; b=mhH1WSr6o5Nws5cTTMGxW6Lhs7B51FMHgfg2yv7gtmAwSLH8+h/bJkz2 GkDpeavbjFpvo7icFtZV889huQ10Xetu0EkekGJwXI75Tc4XVtjze+vQb uNn5LU0uTLEM17/J3EvTL3qckfDIJWM15aF42bhBgA6vrsgdSXR9QI+wJ w=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0BVAgCW7JVX/5pdJa1dgz+BWLhdgXyGH?= =?us-ascii?q?QIcgRw4FAEBAQEBAQFdJ4RdAQQBIxFABRACASICJgICAjAVEAIEAQ0ZiBQIpAe?= =?us-ascii?q?NLwEBAQEBAQEBAQEBAQEBAQEBAQEBARyBAYUpgXiKFiuCLwWTZoVCAYE0jTqBV?= =?us-ascii?q?o1pkCABHjaDc4g3fwEBAQ?= X-IronPort-AV: E=Sophos;i="5.28,419,1464652800"; d="scan'208";a="127814310" Received: from rcdn-core-3.cisco.com ([173.37.93.154]) by rcdn-iport-7.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 25 Jul 2016 10:45:55 +0000 Received: from XCH-RTP-010.cisco.com (xch-rtp-010.cisco.com [64.101.220.150]) by rcdn-core-3.cisco.com (8.14.5/8.14.5) with ESMTP id u6PAjs6m028904 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Mon, 25 Jul 2016 10:45:55 GMT Received: from xch-rtp-010.cisco.com (64.101.220.150) by XCH-RTP-010.cisco.com (64.101.220.150) with Microsoft SMTP Server (TLS) id 15.0.1210.3; Mon, 25 Jul 2016 06:45:54 -0400 Received: from xch-rtp-010.cisco.com ([64.101.220.150]) by XCH-RTP-010.cisco.com ([64.101.220.150]) with mapi id 15.00.1210.000; Mon, 25 Jul 2016 06:45:54 -0400 From: "Stefano Previdi (sprevidi)" To: Brian E Carpenter , =?utf-8?B?T2xlIFRyw7hhbg==?= Subject: Lack of consensus Thread-Topic: Lack of consensus Thread-Index: AQHR5mG33cOY/aEZdEuKqa7OApk3Fg== Date: Mon, 25 Jul 2016 10:45:54 +0000 Message-ID: References: <201607220911.u6M9Bco9077775@givry.fdupont.fr> <948512bb-c741-0509-8442-2d230c5bca49@gmail.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.61.207.56] Content-Type: text/plain; charset="utf-8" Content-ID: <67C682113771E045BB5A89E49D16537B@emea.cisco.com> Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: Cc: 6man WG X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.17 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 Jul 2016 10:45:57 -0000 QnJpYW4sIE9sZSwNCg0KWy4uLl0NCg0KDQo+PiBJIGNhbm5vdCBpbiBSRkMyMDI2IG9yIFJGQzY0 MTAgZmluZCB0aGF0IGxhY2sgYW1iaWd1aXR5IGlzIGEgcmVxdWlyZW1lbnQgdG8gYWR2YW5jZSBh IGRvY3VtZW50Lg0KPiANCj4gVGhhdCdzIHByb2JhYmx5IHRydWUuIEJ1dCBpdCdzIHN0aWxsIGEg bWF0dGVyIG9mIGNvbW11bml0eSBjb25zZW5zdXM7DQoNCg0KaXQgbG9va3MgdG8gbWUgd2UgYXJl IHN0YWxsZWQgaW50byBhIG5vbi1jb25zZW5zdXMgc2l0dWF0aW9uIGFuZCBlYWNoIHRpbWUgd2Ug dHJ5IHRvIHJlYWNoIHNvbWUgY29tcHJvbWlzZSB3ZSBmYWxsIGJhY2sgaW50byBhIGxvbmcgZGlz Y3Vzc2lvbiAobGl2ZSBvciB0aHJvdWdoIGVtYWlscykuDQoNClRoZSBjbG9zZXIgd2UgZ290IHRv IGEgZm9ybSBvZiBjb25zZW5zdXMgd2FzIGR1cmluZyB0aGUgbWVldGluZyBhZnRlciBNYXJr4oCZ IHN1Z2dlc3Rpb24gdG8gcmVtb3ZlIHRoZSBzZWNvbmQgcGFyYWdyYXBoLiBIb3dldmVyLCB0aGUg c2l0dWF0aW9uIGhhbmdlZCBzaW5jZS4NCg0KQXQgdGhpcyBzdGFnZSB3aGF0IGFyZSB0aGUgb3B0 aW9ucyBpZiBjb25zZW5zdXMgaW4gbm90IHJlYWNoZWQgb24gYSBzcGVjaWZpYyBwaWVjZSBvZiB0 ZXh0ID8NCg0KVGhhbmtzDQpzLg0KDQoNCg== From nobody Mon Jul 25 05:27:44 2016 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A974F12D817 for ; Mon, 25 Jul 2016 05:27:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.221 X-Spam-Level: X-Spam-Status: No, score=-4.221 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=jisc365.onmicrosoft.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 VdHl2Tc9-4_J for ; Mon, 25 Jul 2016 05:27:40 -0700 (PDT) Received: from eu-smtp-delivery-189.mimecast.com (eu-smtp-delivery-189.mimecast.com [146.101.78.189]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7813A12D747 for ; Mon, 25 Jul 2016 05:27:40 -0700 (PDT) Received: from EUR01-DB5-obe.outbound.protection.outlook.com (mail-db5eur01lp0182.outbound.protection.outlook.com [213.199.154.182]) (Using TLS) by eu-smtp-1.mimecast.com with ESMTP id uk-mta-33-LSqIgdZ-M9WO9VdeXvMcfw-1; Mon, 25 Jul 2016 13:27:34 +0100 X-MC-Unique: LSqIgdZ-M9WO9VdeXvMcfw-1 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=jisc365.onmicrosoft.com; s=selector1-jisc-ac-uk; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=Qu40QQaORpMaOoAA7fvaMiPHsaYmLNn7b52tgQj+P0c=; b=cDsimqPwqPK3hW6o4CvMNU0eAo7DJV/BuRXW3sBUWmWl+K3Jbawm71uvCzqgM3EnQAy/XnocUbljXDhyCaxVEdd2n78xTEDCHO1XSCjZVV6Qjup0/rijs6D2AgawnP7Gmvf7HhEYGZlsK4Mn8xR4NEjMWKpI+2VnMUTU+J8DDF8= Received: from AMSPR07MB455.eurprd07.prod.outlook.com (10.242.106.148) by AMSPR07MB453.eurprd07.prod.outlook.com (10.242.106.143) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P384) id 15.1.544.10; Mon, 25 Jul 2016 12:27:30 +0000 Received: from AMSPR07MB455.eurprd07.prod.outlook.com ([10.242.106.148]) by AMSPR07MB455.eurprd07.prod.outlook.com ([10.242.106.148]) with mapi id 15.01.0539.023; Mon, 25 Jul 2016 12:27:31 +0000 From: Tim Chown To: 6man WG Subject: Re: proposed text for header injection revision 05 Thread-Topic: proposed text for header injection revision 05 Thread-Index: AQHR4/kNlst2D/fkNkGzHiWFCp0fOqAkNBmAgAAidACAAY9ZgIADMlGA Date: Mon, 25 Jul 2016 12:27:31 +0000 Message-ID: <74CA7221-777D-433B-BC4F-F3EBE6E0F816@jisc.ac.uk> References: <201607220911.u6M9Bco9077775@givry.fdupont.fr> <948512bb-c741-0509-8442-2d230c5bca49@gmail.com> <838.1469273991@obiwan.sandelman.ca> In-Reply-To: <838.1469273991@obiwan.sandelman.ca> Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-mailer: Apple Mail (2.3124) authentication-results: spf=none (sender IP is ) smtp.mailfrom=Tim.Chown@jisc.ac.uk; x-ms-exchange-messagesentrepresentingtype: 1 x-originating-ip: [2001:a88:d510:1101:e562:f526:a39d:e3a0] x-ms-office365-filtering-correlation-id: 6f65f9ea-9a5f-44ef-6fab-08d3b4870cc6 x-microsoft-exchange-diagnostics: 1; AMSPR07MB453; 20:eOvv4BhgAKTh3Huy9KSyB6iCcUN8EPdvhoDVVZSYmXswNVMCib1TrfOUVW0dZH8gmBuFE6JgT+y0b3tiDbnnVxyRc7HJpfxQdoZZJv32IXcnK+Cxu3cfZpommw7Z3V0RIKTrh8L79Lsu0XWb7hNzoBswIoDrrF8MUq0OXeBod5M= x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:AMSPR07MB453; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(192374486261705)(100405760836317); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(102415321)(601004)(2401047)(8121501046)(5005006)(3002001)(10201501046); SRVR:AMSPR07MB453; BCL:0; PCL:0; RULEID:; SRVR:AMSPR07MB453; x-forefront-prvs: 0014E2CF50 x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(979002)(6009001)(7916002)(189002)(51444003)(24454002)(199003)(2906002)(102836003)(101416001)(5002640100001)(6116002)(8936002)(92566002)(81156014)(81166006)(10400500002)(189998001)(19580395003)(19580405001)(110136002)(586003)(122556002)(93886004)(3280700002)(4326007)(8676002)(50986999)(76176999)(7846002)(106356001)(7736002)(83716003)(2950100001)(86362001)(105586002)(106116001)(77096005)(36756003)(68736007)(3660700001)(33656002)(74482002)(50226002)(87936001)(57306001)(99936001)(305945005)(2900100001)(82746002)(97736004)(3826002)(104396002)(969003)(989001)(999001)(1009001)(1019001); DIR:OUT; SFP:1101; SCL:1; SRVR:AMSPR07MB453; H:AMSPR07MB455.eurprd07.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; MX:1; A:1; LANG:en; received-spf: None (protection.outlook.com: jisc.ac.uk does not designate permitted sender hosts) spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: multipart/signed; boundary="Apple-Mail=_1D56EA39-3E19-4D27-A1BB-2798582E37B9"; protocol="application/pgp-signature"; micalg=pgp-sha512 MIME-Version: 1.0 X-OriginatorOrg: jisc.ac.uk X-MS-Exchange-CrossTenant-originalarrivaltime: 25 Jul 2016 12:27:31.5676 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 48f9394d-8a14-4d27-82a6-f35f12361205 X-MS-Exchange-Transport-CrossTenantHeadersStamped: AMSPR07MB453 Archived-At: Cc: Michael Richardson X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.17 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 Jul 2016 12:27:44 -0000 --Apple-Mail=_1D56EA39-3E19-4D27-A1BB-2798582E37B9 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 Hi, > On 23 Jul 2016, at 12:39, Michael Richardson = wrote: >=20 > I think that this is key: We need a document that reflects what really > happens out there, as this has material impact on what we can do in = the > future. >=20 > (I think that the biggest argument for not mutilating packets in the = middle > is because that's how we got NAT and SPUD/PLUS/etc. I'd rather = document > how to do safe, sane (and consensual[%]) changes to packets.) I like the spirit of what Michael wrote above. Perhaps a way forward is = by following this principle, for which I have a strawman short and long = answer below. The snag is whether there is room in 2460bis to be = pragmatic in this way. In short: 1. We push RFC2460bis forward such that it simply states what we have = widespread successful deployment of today (which is a requirement for = Internet Standard anyway) 2. We document the (harmful) side-effects of EH insertion on path = (preferably within 2460, or as a separate document that might be updated = with experience later). 3. We agree that if in the future we identify cases where EH insertion = can be done =93safely and sanely=94 (for a value of =93safely and = sanely=94 tbd), then we will document these, as Experimental or Proposed = Standards appropriately. Such an approach would capture current practice in 2460, ensure = understanding of consequences of EH insertion are known, and leave the = door open for future innovation. Were that agreed, =93all=94 we=92d need = to do is agree what each means in practice. ** 1. RFC2460bis reflecting current practice ** Current practice is that nodes on a path, i.e. routers, are expected to = examine the HBH Options header, but we have already noted in 2460bis as = it is that routers in high-performance scenarios may not actually have = capacity to do this fully, or even partially. So the new =93where = explicitly configured to do so=94 text seems in line with current = practice, relaxing the previous requirement. Many might say examining in this case is one form of processing, so just = saying =93processing=94 and removing =93examining=94 seems reasonable = too. Current practice is also that intermediate nodes on a path might also = process EHs in any situation where they might need to look past the EH = chain into the transport headers or deeper, e.g. at an IDS/firewall, or = a load balancer. In that light, the current paragraph in 2460bis: "With one exception, extension headers are not processed by any node along a packet's delivery path, until the packet reaches the node (or each of the set of nodes, in the case of multicast) identified in the Destination Address field of the IPv6 header. Note: If an intermediate forwarding node examines an extension header for any reason, it must do so in accordance with the provisions of = [RFC7045]." reads a little clumsily. It says the exception is only the HBH Options = header, then implies you can do more, so long as you=92re RFC7045 = compliant. Not ideal. I think Ole suggested we might consider dropping this paragraph = altogether, but we can probably do better. Perhaps something like: =93If an intermediate node needs to inspect transport headers or beyond, e.g. for security or load balancing purposes, it must examine all EHs in accordance with the provisions of [RFC7045]. Otherwise, except for handing of the HBH Option header as described below, EHs are not expected to be processed by nodes on a packet=92s delivery path, until the packet reaches the node (or each of the set of nodes, in the case of multicast) identified in the Destination Address field of the IPv6 = header." So we would still be ducking the explicit calling out of what =93process=94= means, but the use of =93expected=94 is a little stronger than one we = have now, and the presence of pragmatic EH processing cases as per = RFC7045 is stated. ** 2. Document the side-effects of EH insertion on path ** Currently the =93health warning" in 2460bis says: "The insertion of Extension Headers by any node other than the source of the packet breaks PMTU-discovery and can result in ICMP error messages being sent to the source of the packet that did not insert the header.=94 We should add to this the comments from the list about IPSec AH (however = little it may be used) and re-calculating checksums. It wouldn=92t be = hard to come up with some text. I would certainly change =93that did = not insert the header=94 to =93rather than the node that inserted the = header.=94 The text from RFC6554 is nice, which says "Use of tunnelling = ensures that the datagram is delivered unmodified and that ICMP errors = return to the source of the SRH rather than the source of the original = datagram." And of course we also have this contentious paragraph: "The current approach to allowing a header to be inserted is to encapsulate the packet using another IPv6 header and including the additional extension header after the first IPv6 header, for example, as defined in [RFC2473].=94 I am fine with it being removed, BUT to get consensus we could ground it = in a Proposed Standard example, e.g. we could say: =93One approach to allowing a header to be inserted is to encapsulate the packet using another IPv6 header and including the additional extension header after the first IPv6 header, for example, as defined for the RPL Type 3 Routing Header as described in Section 2 of [RFC6554].=94 This also removes use of the word =93current=94, which would look silly = in a few years time. I would advocate this being in 2460bis rather than a separate document, = but if the latter helps with consensus, and later updates with = experience from whoever is inserting EHs, so be it. ** 3. Document header insertion use cases ** So the open question here, is what are those use cases? It seems they are currently around scenarios where an IPv6 packet enters = a domain where IPv6 Routing Headers are used, to allow that packet to be = passed around that domain with RHs being used to =93steer=94 the packet = while it remains in that domain, from which it may or may not emerge. The two cases I am aware of here are RPL and SPRING, which at least = originally were targeted at single administrative domains. For RPL, RFC6554 (defining the Type 3 RH) says in Section 2: " 1. If the SRH specifies the complete path from source to destination, the router places the SRH directly in the datagram itself. 2. If the SRH only specifies a subset of the path from source to destination, the router uses IPv6-in-IPv6 tunneling [RFC2473] and places the SRH in the outer IPv6 header. Use of tunneling ensures that the datagram is delivered unmodified and that ICMP errors return to the source of the SRH rather than the source of the original datagram." So in this case it seems that encapsulation is used, not EH insertion. = However, some implementations are apparently inserting (based on list = comments) on the grounds of conserving battery and/or bandwidth, but = that seems to not be to the spec. Michael has documented RPL cases in = draft-ietf-roll-useofrplinfo-07. For SPRING, draft-ietf-6man-segment-routing-header-01 (defining the Type = 4 RH) says in Section 5: "The Segment Routing Header (SRH) is simply another type of the routing header as described in RFC 2460 [RFC2460] and is: o inserted by an SR edge router when entering the segment routing domain or by the originating host itself. The source host can even be outside the SR domain; o inspected and acted upon when reaching the destination address of the IP header per RFC 2460 [RFC2460]." So in this case =93inserted=94 is ambiguous; it could mean true = insertion, or encapsulation. It seems we should look at these cases more closely, as I assume these = are the cases that those objecting to EH insertion being explicitly = outlawed in 2460bis are concerned about. Or are there other current use = cases for EH insertion? If so, are they described in IETF documents? And then we try to ensure Michael=92s "safe, sane and consensual = changes=94 can be done in practice. Tim --Apple-Mail=_1D56EA39-3E19-4D27-A1BB-2798582E37B9 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 iQIcBAEBCgAGBQJXlgYIAAoJELg9LkJo0sOW81UP/0m6dh3UMxT6RbMryir9vMu4 kKJvLImWz2t36qEzbi3lVmi5HE9OJAjJGoRn/D90+aONO1Iawk3LauViNedT4idW ayOtnIP5FRPxBtfTVOLzRxhvCdfZ9m8qX/G3MRBlSt7HlILWrVzX3mGnD0xCA+FB E3J7fIqlt7kFZtb6eS+mvyKtBr+OuA6MuL5aJ5gn6nrdqjqPDFoeX3mYX8zt1kME xwBx5WC3Fhn48VzAkElBuSYx54ggEo8l4L+XoznpCrAIBxgQzTMUPjFNCCMFpLrC RlWzIzh3duj0F4cHGBJDw/F4OCp99MHCRxbKeg4gJ+xvb3y5wZ7MDe4SCNOJDaxh J7WSnKCE76xOI8v2W0k5HTW9v+NUX9VTPASizvgrNBi6MZWIij5/wMtMicFzstkI xas3ZMVfafaddefeULqXfnawmPm1DSJS3a2zXKLroPp7VsDTMyBptEqczAznXejG mfB47nouAXRMpoIWXq6dWLCGbdq5+weYRjYjBtYcAcPqaTHfZs3SGJpq1WuIQnz8 8SX7QTeWEV51M4t9D2M/92EiNkBi/4nCqMtTbk+HLjCKCQVidlNOVyjwxePzPVd6 Gi+RrRtnTOpZctc6AynG2WBFzqBVZaI80La6mbC02vL7ZX+Cqy6p68RU73ryu/vu l5h1Z/sjk5KSMOPzgFh1 =DjQy -----END PGP SIGNATURE----- --Apple-Mail=_1D56EA39-3E19-4D27-A1BB-2798582E37B9-- From nobody Mon Jul 25 08:52:41 2016 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 333F112D096 for ; Mon, 25 Jul 2016 08:52:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.988 X-Spam-Level: X-Spam-Status: No, score=-3.988 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, RP_MATCHES_RCVD=-1.287, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=pobox.com; domainkeys=pass (1024-bit key) header.from=heard@pobox.com header.d=pobox.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 uKPkc6PhliS4 for ; Mon, 25 Jul 2016 08:52:38 -0700 (PDT) Received: from sasl.smtp.pobox.com (pb-smtp2.pobox.com [64.147.108.71]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6325112D86B for ; Mon, 25 Jul 2016 08:52:34 -0700 (PDT) Received: from sasl.smtp.pobox.com (unknown [127.0.0.1]) by pb-smtp2.pobox.com (Postfix) with ESMTP id B33DA2E2B2 for ; Mon, 25 Jul 2016 11:52:33 -0400 (EDT) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=pobox.com; h=mime-version :in-reply-to:references:from:date:message-id:subject:to :content-type; s=sasl; bh=Ski196j32AdU9+ySIzu2vQ3sRHI=; b=DRdRWx gS/TbotOYIKmEx64lEfLKfCzSKbBOG/Ymoj5P7Ad574AryLyPVmfK85SJ7yw4VfX Y02bH6LmoALd4Dyg01GJwb2S72QmpkjGOOe78kRozHqZJD9rYoUGB+kX2gmXDrHk qRIMu+qiz6zMJAcc8BcSiuH8am/kJ1woM41QU= DomainKey-Signature: a=rsa-sha1; c=nofws; d=pobox.com; h=mime-version :in-reply-to:references:from:date:message-id:subject:to :content-type; q=dns; s=sasl; b=dZBpC7sU6sQwz3r3xTqDzlA6ZkSaZNix HDmsEPoGrXe6Q0y6C5Iz+HPw1cih3TOZEp61o/lXrCS8H18+VIHefPbVI6eSs+vu +0bOSrFBi0zSdoXA2flmf1GFiK1iuXS4P/493nZ5RZg12xes1YrOvX0CLjwjkXi+ IsK/n3zRABk= Received: from pb-smtp2.nyi.icgroup.com (unknown [127.0.0.1]) by pb-smtp2.pobox.com (Postfix) with ESMTP id ABCDB2E2B1 for ; Mon, 25 Jul 2016 11:52:33 -0400 (EDT) Received: from mail-vk0-f41.google.com (unknown [209.85.213.41]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by pb-smtp2.pobox.com (Postfix) with ESMTPSA id 6072E2E2B0 for ; Mon, 25 Jul 2016 11:52:33 -0400 (EDT) Received: by mail-vk0-f41.google.com with SMTP id s189so249228844vkh.1 for ; Mon, 25 Jul 2016 08:52:33 -0700 (PDT) X-Gm-Message-State: AEkoousEjNNps4T1F55ZniGDZOeMFkoS3ZYXGX4Q1coJMv0FQf5dcAF/qMIK/vVl//PSrOOEH8uChJvP/3gtnQ== X-Received: by 10.176.69.183 with SMTP id u52mr8814180uau.123.1469461952970; Mon, 25 Jul 2016 08:52:32 -0700 (PDT) MIME-Version: 1.0 Received: by 10.31.233.1 with HTTP; Mon, 25 Jul 2016 08:52:13 -0700 (PDT) In-Reply-To: References: <201607220911.u6M9Bco9077775@givry.fdupont.fr> From: "C. M. Heard" Date: Mon, 25 Jul 2016 08:52:13 -0700 X-Gmail-Original-Message-ID: Message-ID: Subject: Re: proposed text for header injection revision 05 To: 6man WG Content-Type: text/plain; charset=UTF-8 X-Pobox-Relay-ID: CCF15F14-527F-11E6-B1A8-EE617A1B28F4-06080547!pb-smtp2.pobox.com Archived-At: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.17 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 Jul 2016 15:52:40 -0000 On Thu, 21 Jul 2016 18:58:39 +0200, Fernando Gont wrote: > Note, again: I don't care much about the outcome. But we should care about the outcome. If an extension headers is inserted by any node other than the source of the packet, any ICMP error message related to that header goes back to the original source of the packet, not to the node that inserted the offending header. If that's not a fatal technical flaw, I don't know what is. Echoing Brian Carpenter, let's please go back to the version at https://tools.ietf.org/html/draft-ietf-6man-rfc2460bis-01#page-7, which unambiguously addresses the issue, reflects the original intent of RFC 2460, and has no known technical omissions. //cmh From nobody Mon Jul 25 11:10:03 2016 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A337012D9C7 for ; Mon, 25 Jul 2016 11:10:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.566 X-Spam-Level: X-Spam-Status: No, score=-0.566 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_SORBS_WEB=0.77, SPF_HELO_PASS=-0.001, SPF_SOFTFAIL=0.665] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=employees.org; domainkeys=pass (1024-bit key) header.from=otroan@employees.org header.d=employees.org 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 vRHKtBuhMBku for ; Mon, 25 Jul 2016 11:10:00 -0700 (PDT) Received: from incoming.kjsl.com (inbound02.kjsl.com [IPv6:2001:1868:2002::144]) (using TLSv1.2 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0093A12D9C5 for ; Mon, 25 Jul 2016 11:09:59 -0700 (PDT) Received: from cowbell.employees.org ([65.50.211.142]) by ironport02.kjsl.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 25 Jul 2016 18:09:58 +0000 Received: from cowbell.employees.org (localhost [127.0.0.1]) by cowbell.employees.org (Postfix) with ESMTP id 59E419CC7C; Mon, 25 Jul 2016 11:09:57 -0700 (PDT) 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=f8jfxDBf8NBkKSOA8RjNDAiUhDo=; b= GTvQ8jdAnD1uV6vV4XRoMIUk5zkr0SDAdXIvvMVA7va95vF4PYm4eeDwMEub30u2 KQI++xF10qI984YCBEvBioTK2/wn/rqzVFpXSpiS4X7j0zVjMHw4LtUq9J6PVvvt ijzFttF2yfAr5PRsmLD1PUV5Bbbu2q1ekKT4HyMwDGk= 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=Tk9fn3wM3m5y1On6BukXrBwE9D hS/3BPsYmFem3IyIlQ8c/Wk6NbtRHlkpZ0Wj2ee9csv25Q3WNl2r6DgteJBAMqDo ZipFktqbt8hbUUXzi4MaskxiGcR59fPF8+dQEf7tircmvOxtrn+4UNQaNkfKRxUX Yzr1uY1dCKIX90uOk= Received: from h.hanazo.no (ti0140a400-2322.bb.online.no [88.88.61.28]) (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 D9A739CC4F; Mon, 25 Jul 2016 11:09:56 -0700 (PDT) Received: from [IPv6:::1] (localhost [IPv6:::1]) by h.hanazo.no (Postfix) with ESMTP id 371FA2C0EACC; Mon, 25 Jul 2016 20:10:02 +0200 (CEST) Subject: Re: proposed text for header injection revision 05 Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) Content-Type: multipart/signed; boundary="Apple-Mail=_DB372CC7-88CD-409E-A7F5-30084F4834E4"; protocol="application/pgp-signature"; micalg=pgp-sha512 X-Pgp-Agent: GPGMail From: otroan@employees.org In-Reply-To: <74CA7221-777D-433B-BC4F-F3EBE6E0F816@jisc.ac.uk> Date: Mon, 25 Jul 2016 20:10:01 +0200 Message-Id: <2F673E60-74CB-450B-8034-78EEB6B955A5@employees.org> References: <201607220911.u6M9Bco9077775@givry.fdupont.fr> <948512bb-c741-0509-8442-2d230c5bca49@gmail.com> <838.1469273991@obiwan.sandelman.ca> <74CA7221-777D-433B-BC4F-F3EBE6E0F816@jisc.ac.uk> To: Tim Chown X-Mailer: Apple Mail (2.3124) Archived-At: Cc: Michael Richardson , 6man WG X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.17 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 Jul 2016 18:10:01 -0000 --Apple-Mail=_DB372CC7-88CD-409E-A7F5-30084F4834E4 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 Tim, > Current practice is also that intermediate nodes on a path might also = process EHs in any situation where they might need to look past the EH = chain into the transport headers or deeper, e.g. at an IDS/firewall, or = a load balancer. In that light, the current paragraph in 2460bis: >=20 > "With one exception, extension headers are not processed by any node > along a packet's delivery path, until the packet reaches the node = (or > each of the set of nodes, in the case of multicast) identified in = the > Destination Address field of the IPv6 header. Note: If an > intermediate forwarding node examines an extension header for any > reason, it must do so in accordance with the provisions of = [RFC7045]." >=20 > reads a little clumsily. It says the exception is only the HBH Options = header, then implies you can do more, so long as you=92re RFC7045 = compliant. Not ideal. >=20 > I think Ole suggested we might consider dropping this paragraph = altogether, but we can probably do better. Perhaps something like: My comment was intended to show that the argument used about "original = intent" didn't necessarily matter much to the people implementing or = deploying the protocol. I do think it has value to clearly state that in the IPv6 architecture = there are only hosts and routers. And that a correctly implemented and = deployed IPv6 network does not examine nor process anything beyond the = initial IPv6 header (minus the HBH header). =46rom an Internet architecture point of view I cannot see how we can = say anything else. I would be very reluctant to introduce any language in 2460bis allowing = middleboxes. >=20 > =93If an intermediate node needs to inspect transport headers or = beyond, > e.g. for security or load balancing purposes, it must examine all EHs > in accordance with the provisions of [RFC7045]. Otherwise, except for > handing of the HBH Option header as described below, EHs are not > expected to be processed by nodes on a packet=92s delivery path, = until > the packet reaches the node (or each of the set of nodes, in the case > of multicast) identified in the Destination Address field of the IPv6 = header." >=20 > So we would still be ducking the explicit calling out of what = =93process=94 means, but the use of =93expected=94 is a little stronger = than one we have now, and the presence of pragmatic EH processing cases = as per RFC7045 is stated. Best regards, Ole --Apple-Mail=_DB372CC7-88CD-409E-A7F5-30084F4834E4 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 iQEcBAEBCgAGBQJXllX5AAoJED4aXnjSQuKWEigIAIX/JA7oItpx/YLUl244Jv7Z T/xu08pOM5hgtGieLeo/R3S4oEP/wgDbf1i9xjtROjgGCmsrMqf999eiL03keUF6 O0V6BbJ1YQWf30SuadNReD3zCtkblNHrnYs3fVMGRdmKqiLMj9271ZXNughbmrop 24r35P969mDF9R6aSUsbii3zQwDJ+ukzBIBSwlaPiIMGSxbgNFYluBCEW7CsWUQO 45TfMV9cSok9Zycze2afmBkQakMnF4S09xJRuOVSYUSidNfI106kR36yVRhGnoyH 80O0yS7tclUn0+e4ZxUMmzlOzwEgfDD5ItB96u4sRwIj3pKWGoo43RoGzvq1e/c= =UTP0 -----END PGP SIGNATURE----- --Apple-Mail=_DB372CC7-88CD-409E-A7F5-30084F4834E4-- From nobody Mon Jul 25 11:18:51 2016 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C3B0D12D56D for ; Mon, 25 Jul 2016 11:18:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.566 X-Spam-Level: X-Spam-Status: No, score=-0.566 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_SORBS_WEB=0.77, SPF_HELO_PASS=-0.001, SPF_SOFTFAIL=0.665] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=employees.org; domainkeys=pass (1024-bit key) header.from=otroan@employees.org header.d=employees.org 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 Ypa3A3vqqHl1 for ; Mon, 25 Jul 2016 11:18:47 -0700 (PDT) Received: from incoming.kjsl.com (inbound02.kjsl.com [IPv6:2001:1868:2002::144]) (using TLSv1.2 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9E85A12D1D1 for ; Mon, 25 Jul 2016 11:18:47 -0700 (PDT) Received: from cowbell.employees.org ([65.50.211.142]) by ironport02.kjsl.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 25 Jul 2016 18:18:46 +0000 Received: from cowbell.employees.org (localhost [127.0.0.1]) by cowbell.employees.org (Postfix) with ESMTP id B72C79CC4F; Mon, 25 Jul 2016 11:18:45 -0700 (PDT) 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=T7zEIUwwzwGIR8Wi2kRkgq3CmOg=; b= VjlFqf9ThiBWHDobKDmCVUQbd2jXI5vzkOF9vfCPHac0F7UhKvvDBgCh2sswZyY/ cpejYgr1UsSPrxAnrNTwiPxyKUFw/JjdUu1gIHXMT6yASb0Scv4aOfEmeh9tIeBH 2nfiZBdWfGMbFQwxFpJoYE+VzFgO4evQbNdmfyb6Dko= 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=P7pqSUlH9HrGVUOdRoJb5IZc3D HzuqCpF/BzB+Baw9Du/02K3yPlvfAxVyhE8Kqu5fMDRZkBhxfaI4PHoOg42fXm4H +G6YB25T1i+ZdlCDB9v6ux3uH4J19Kx6c0TkTUOOVbiqDFHxc+X5au048i3WKIiR DXzDf9DldRX4deqlc= Received: from h.hanazo.no (ti0140a400-2322.bb.online.no [88.88.61.28]) (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 7CF7C9CC4E; Mon, 25 Jul 2016 11:18:45 -0700 (PDT) Received: from [IPv6:::1] (localhost [IPv6:::1]) by h.hanazo.no (Postfix) with ESMTP id 923BE2C0EF3C; Mon, 25 Jul 2016 20:18:51 +0200 (CEST) Subject: Re: Lack of consensus Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) Content-Type: multipart/signed; boundary="Apple-Mail=_F727EFCF-3BB8-43CF-9EE5-0A717EA24C38"; protocol="application/pgp-signature"; micalg=pgp-sha512 X-Pgp-Agent: GPGMail From: otroan@employees.org In-Reply-To: Date: Mon, 25 Jul 2016 20:18:51 +0200 Message-Id: References: <201607220911.u6M9Bco9077775@givry.fdupont.fr> <948512bb-c741-0509-8442-2d230c5bca49@gmail.com> To: "Stefano Previdi (sprevidi)" X-Mailer: Apple Mail (2.3124) Archived-At: Cc: 6man WG , Suresh Krishnan X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.17 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 Jul 2016 18:18:49 -0000 --Apple-Mail=_F727EFCF-3BB8-43CF-9EE5-0A717EA24C38 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Stefano, >>> I cannot in RFC2026 or RFC6410 find that lack ambiguity is a = requirement to advance a document. >>=20 >> That's probably true. But it's still a matter of community consensus; >=20 >=20 > it looks to me we are stalled into a non-consensus situation and each = time we try to reach some compromise we fall back into a long discussion = (live or through emails). >=20 > The closer we got to a form of consensus was during the meeting after = Mark=E2=80=99 suggestion to remove the second paragraph. However, the = situation hanged since. >=20 > At this stage what are the options if consensus in not reached on a = specific piece of text ? That's a good question. If the working group would be willing to live = with and respect the outcome, we could ask our AD to make a decision. Or = we could leave this issue open and revisit it in Seoul, or we could give = up on making 2460 Internet standard. When Bob is back mid-August I'll initiate a discussion with our ADs and = see if we can come up with any other ways forward. As an observation; the text we are discussing is not protocol = specification, it is protocol politics. And while I believe enshrining = our values into protocols is fundamental to IETF work, - like routers = not being allowed to look beyond the IPv6 header, or the 64 bit = boundary, it is always navigation in rocky waters. Best regards, Ole --Apple-Mail=_F727EFCF-3BB8-43CF-9EE5-0A717EA24C38 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 iQEcBAEBCgAGBQJXllgLAAoJED4aXnjSQuKWpTUH/1YB/gvK21wi2qCodek+FaA2 TPJ5nrw5XVHbcoWxk4/mNLmiSwVG1oXa5xLibVb+LgAIDpC+6eCjDQNLRXfvE9M0 o8bq2E2sRsrQ0W3qSR0wG3isL9o4wllrn+7jKf9520ZK6BcXp4TSyZqUPToSsHCk BWpo+KChxJbrAUO0QesRwj5o0eLZEH7n36ChpwkaMVOToSLMsGYJHe4FfgNpOEYz cdKPJ87mRSfVvv3CLqWqVk53EWNDcGTk5W6wRgccl3Z2R4x7mQRpF2GtlG5RzfK2 Y5asDrbJz/c/7A0XMNzPBcK6gg0Eugfq+grJMeATHQpdYzYwMODoYrWeXSwdyxE= =VabG -----END PGP SIGNATURE----- --Apple-Mail=_F727EFCF-3BB8-43CF-9EE5-0A717EA24C38-- From nobody Mon Jul 25 11:29:56 2016 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E686812D1D0 for ; Mon, 25 Jul 2016 11:29:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.221 X-Spam-Level: X-Spam-Status: No, score=-4.221 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=jisc365.onmicrosoft.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 AD-r95B41YSi for ; Mon, 25 Jul 2016 11:29:51 -0700 (PDT) Received: from eu-smtp-delivery-189.mimecast.com (eu-smtp-delivery-189.mimecast.com [146.101.78.189]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C01F212D0B1 for ; Mon, 25 Jul 2016 11:29:50 -0700 (PDT) Received: from EUR01-VE1-obe.outbound.protection.outlook.com (mail-ve1eur01lp0247.outbound.protection.outlook.com [213.199.154.247]) (Using TLS) by eu-smtp-1.mimecast.com with ESMTP id uk-mta-7-APWGKAoUORKC1ubqO7lPcw-1; Mon, 25 Jul 2016 19:29:46 +0100 X-MC-Unique: APWGKAoUORKC1ubqO7lPcw-1 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=jisc365.onmicrosoft.com; s=selector1-jisc-ac-uk; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=R0kVabKjf0TdEVkCqU/JmhbA06NMZ6yTsge/8sMvRpA=; b=jL78uKJXX3HLokqBHawUHk2U0nmPuJJ58j3MMU+4lLkHCkgg5nJ5uWyADlixBLSQopp+CiCPbwtCLLfQYbT1K07vifMlZhhJYHVBM0DboaGeVmzrvXd0XAoCwV+huJQAsLf4exUhwOuwl4n2LvEBAVbz519V9DS0tpeTzjHCviM= Received: from AMSPR07MB455.eurprd07.prod.outlook.com (10.242.106.148) by AMSPR07MB453.eurprd07.prod.outlook.com (10.242.106.143) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P384) id 15.1.544.10; Mon, 25 Jul 2016 18:29:33 +0000 Received: from AMSPR07MB455.eurprd07.prod.outlook.com ([10.242.106.148]) by AMSPR07MB455.eurprd07.prod.outlook.com ([10.242.106.148]) with mapi id 15.01.0539.023; Mon, 25 Jul 2016 18:29:33 +0000 From: Tim Chown To: "otroan@employees.org" Subject: Re: proposed text for header injection revision 05 Thread-Topic: proposed text for header injection revision 05 Thread-Index: AQHR4/kNlst2D/fkNkGzHiWFCp0fOqAkNBmAgAAidACAAY9ZgIADMlGAgABfXICAAAXAAA== Date: Mon, 25 Jul 2016 18:29:33 +0000 Message-ID: <0326DD45-677E-4E51-BBFE-6B135912D76F@jisc.ac.uk> References: <201607220911.u6M9Bco9077775@givry.fdupont.fr> <948512bb-c741-0509-8442-2d230c5bca49@gmail.com> <838.1469273991@obiwan.sandelman.ca> <74CA7221-777D-433B-BC4F-F3EBE6E0F816@jisc.ac.uk> <2F673E60-74CB-450B-8034-78EEB6B955A5@employees.org> In-Reply-To: <2F673E60-74CB-450B-8034-78EEB6B955A5@employees.org> Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-mailer: Apple Mail (2.3124) authentication-results: spf=none (sender IP is ) smtp.mailfrom=Tim.Chown@jisc.ac.uk; x-ms-exchange-messagesentrepresentingtype: 1 x-originating-ip: [2001:a88:d510:1101:829:f3ee:fc02:77e0] x-ms-office365-filtering-correlation-id: c230666f-aaab-49e4-e382-08d3b4b9a040 x-microsoft-exchange-diagnostics: 1; AMSPR07MB453; 20:77YIriKgndL4IE7RAlXDSJJQA/u/8Z7aWOl7JZuOeTZUjr1sROC0xC/CwKDaqL9Cz/kcapW3cOnjLSSygpT0RgmTkbmEKPKdcwb0ToufGbCJL6PF+vpbVoUCM7Aj3v9uXtsyf8VWv1F56VDWPJSUGM1MD8jr+B2k9YFGJPYY0Kk= x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:AMSPR07MB453; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(192374486261705); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(102415321)(601004)(2401047)(8121501046)(5005006)(10201501046)(3002001); SRVR:AMSPR07MB453; BCL:0; PCL:0; RULEID:; SRVR:AMSPR07MB453; x-forefront-prvs: 0014E2CF50 x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(6009001)(7916002)(189002)(24454002)(51444003)(199003)(101416001)(102836003)(6116002)(5002640100001)(586003)(8936002)(92566002)(81156014)(81166006)(1730700003)(19580405001)(19580395003)(122556002)(5640700001)(2906002)(93886004)(11100500001)(3280700002)(189998001)(2501003)(10400500002)(4326007)(8676002)(110136002)(50986999)(76176999)(7846002)(68736007)(7736002)(83716003)(82746002)(305945005)(86362001)(77096005)(106116001)(33656002)(57306001)(106356001)(36756003)(3660700001)(50226002)(74482002)(87936001)(2351001)(99936001)(2950100001)(105586002)(97736004)(2900100001)(3826002)(104396002); DIR:OUT; SFP:1101; SCL:1; SRVR:AMSPR07MB453; H:AMSPR07MB455.eurprd07.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; MX:1; A:1; LANG:en; received-spf: None (protection.outlook.com: jisc.ac.uk does not designate permitted sender hosts) spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: multipart/signed; boundary="Apple-Mail=_EEC4F520-EE79-4C89-98C6-374C6AC324F3"; protocol="application/pgp-signature"; micalg=pgp-sha512 MIME-Version: 1.0 X-OriginatorOrg: jisc.ac.uk X-MS-Exchange-CrossTenant-originalarrivaltime: 25 Jul 2016 18:29:33.7986 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 48f9394d-8a14-4d27-82a6-f35f12361205 X-MS-Exchange-Transport-CrossTenantHeadersStamped: AMSPR07MB453 Archived-At: Cc: Michael Richardson , 6man WG X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.17 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 Jul 2016 18:29:54 -0000 --Apple-Mail=_EEC4F520-EE79-4C89-98C6-374C6AC324F3 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 Hi Ole, > On 25 Jul 2016, at 19:10, otroan@employees.org wrote: >=20 > Tim, >=20 >> Current practice is also that intermediate nodes on a path might also = process EHs in any situation where they might need to look past the EH = chain into the transport headers or deeper, e.g. at an IDS/firewall, or = a load balancer. In that light, the current paragraph in 2460bis: >>=20 >> "With one exception, extension headers are not processed by any node >> along a packet's delivery path, until the packet reaches the node = (or >> each of the set of nodes, in the case of multicast) identified in = the >> Destination Address field of the IPv6 header. Note: If an >> intermediate forwarding node examines an extension header for any >> reason, it must do so in accordance with the provisions of = [RFC7045]." >>=20 >> reads a little clumsily. It says the exception is only the HBH = Options header, then implies you can do more, so long as you=92re = RFC7045 compliant. Not ideal. >>=20 >> I think Ole suggested we might consider dropping this paragraph = altogether, but we can probably do better. Perhaps something like: >=20 > My comment was intended to show that the argument used about "original = intent" didn't necessarily matter much to the people implementing or = deploying the protocol. So it seems. > I do think it has value to clearly state that in the IPv6 architecture = there are only hosts and routers. And that a correctly implemented and = deployed IPv6 network does not examine nor process anything beyond the = initial IPv6 header (minus the HBH header). >=20 > =46rom an Internet architecture point of view I cannot see how we can = say anything else. >=20 > I would be very reluctant to introduce any language in 2460bis = allowing middle boxes. I understand that, and that would be my preference too, but the current = 2460bis introduces a =93handle EHs as per RFC7045=94 sentence (which = pragmatically is what we want to do), and as a reminder RFC7045 then = says this on forwarding nodes: "Any forwarding node along an IPv6 packet's path, which forwards the packet for any reason, SHOULD do so regardless of any extension headers that are present, as required by RFC 2460. Exceptionally, if a forwarding node is designed to examine extension headers for any reason, such as firewalling, it MUST recognise and deal appropriately with all standard IPv6 extension header types and SHOULD recognise and deal appropriately with experimental IPv6 extension header = types.=94 So the middlebox (firewall) behaviour is implicitly included in 2460bis = already. Though in this case you could read it as firewalling based on = EH contents, not transport headers or beyond, but you=92d need to = attempt to look through the whole chain up to the transport header = regardless of whether that was then inspected too. >> =93If an intermediate node needs to inspect transport headers or = beyond, >> e.g. for security or load balancing purposes, it must examine all EHs >> in accordance with the provisions of [RFC7045]. Otherwise, except for >> handing of the HBH Option header as described below, EHs are not >> expected to be processed by nodes on a packet=92s delivery path, = until >> the packet reaches the node (or each of the set of nodes, in the case >> of multicast) identified in the Destination Address field of the IPv6 = header.=94 So one could rewrite this as: "If an intermediate forwarding node is designed to examine extension headers for any reason, such as firewalling, it must do so in accordance with the provisions of [RFC7045]. Otherwise, except for handing of the HBH Option header as described below, EHs are not expected to be processed by nodes on a packet=92s delivery path, until the packet reaches the node (or each of the set of nodes, in the case of multicast) identified in the Destination Address field of the IPv6 = header.=94 which is then using the same language as RFC7045. Delete =93expected to = be=94 if preferred. I think that ordering reads better. >> So we would still be ducking the explicit calling out of what = =93process=94 means, but the use of =93expected=94 is a little stronger = than one we have now, and the presence of pragmatic EH processing cases = as per RFC7045 is stated. >=20 > Best regards, > Ole Tim --Apple-Mail=_EEC4F520-EE79-4C89-98C6-374C6AC324F3 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 iQIcBAEBCgAGBQJXllrkAAoJELg9LkJo0sOWm+sP/jNRAOd5+7UsxMLqDnTgaHE0 kOQUG7q/ir3pSGVb8sFJMNJ9KjchWJ4W7l9UA1zSXcG+wXIkGNoSoLp4KuDjNvd6 7v4rEhwOWIGMYw9JhfEwWLMbZLbMIAlBWU+0uJjPFnrFoAVh7ixslC+1YQ1VW9ia QjVU9H55Tyinvy1LLxhb3gCtuA6rZOxrAqaDpCPMhXrobTsOPjHNOpEwn+KAIHs/ 7fPF+f4V8VNPMLEmsP3QnUZB0NuRAlEJ4nKylZFfL0nqB264sfm2pzpI5iWzqLzr Ii4JWe45d4b0HdYNAwr5Rc/Wo6iGR19/k41ED5vs7oypawWDvCXnWwxe2njS8J5x zAOPtPLW0ehgUGk9cXAIr20kY/Eg2ujx4HryFTiDEybEfbsFQO6FirK2S1AnSNjO NNtGNS60h9IwTfH+HBUg12mlExw/EZiFBhrOwFbWgzUvjgcz1FbMnBlypp6b1RU8 6xuCQEVeOaEpdPqAsVmTjID3I+hNjEKPJRCwBgHDda00NjWc31w7CRhGP9m6BV6L SJ/qI772DNm/mENFdNEKKST0fhPQ3rhd3trZjYCrVm3ErnTn3jdQCizZONrqxE7F 2TKpR1vAo091HusN2x34iAJpLp4c5rKNNW3ag8HfX74nLKNFZCjFtILe9Y1hDXPP o30nJwhYncN2YOvqErXh =T5Kf -----END PGP SIGNATURE----- --Apple-Mail=_EEC4F520-EE79-4C89-98C6-374C6AC324F3-- From nobody Mon Jul 25 11:33:11 2016 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C59BC12D1D0 for ; Mon, 25 Jul 2016 11:33:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FREEMAIL_FORGED_FROMDOMAIN=0.001, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=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 A-Zg60E2YuIv for ; Mon, 25 Jul 2016 11:33:08 -0700 (PDT) Received: from mail-qk0-x230.google.com (mail-qk0-x230.google.com [IPv6:2607:f8b0:400d:c09::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 36CAF12D0B1 for <6man@ietf.org>; Mon, 25 Jul 2016 11:33:08 -0700 (PDT) Received: by mail-qk0-x230.google.com with SMTP id p74so171914896qka.0 for <6man@ietf.org>; Mon, 25 Jul 2016 11:33:08 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to:cc; bh=eYW/hY9UQLDl91iZx1jj/T8xgoS5RQzLTiEaZ5WS4V4=; b=aySYPAQNLQTAeBkETKLPVLCZ9E/whXE7BKmYv5aSga8olCsAh1IiahOw4iHgYb/BLg fv0Uy5f6HFxM28lD2sz8cyI6W9tssY7iULSjXmiC/B5TfsH/wztcaTMAG/nUMWAJm3I6 yxyZtaslFM7nOTlfQus9O0jGqGHNY9+dTvtMUCzbWslPOUplDqmesXmyxjvaOeNnCUuB V/o1qoO0Jy0UX6YDOEp9IZcvK8VFWAosuZfSK/cLSA73mmpAYnNdjuy9wEtal9z4v+VM OsKF5GCxJBQFzaQRGpxG9nQ1/0FvHxM58IdU7ollYewwPW/phql6qAH6bg7fQgyEdVHC loqw== 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:from :date:message-id:subject:to:cc; bh=eYW/hY9UQLDl91iZx1jj/T8xgoS5RQzLTiEaZ5WS4V4=; b=VNzIaTOb4Q6nvi36CyCxiBh9FeX43CH7GUnLf9y+NJ5ZS1qL6k4tjFLEGlVrWn6fVX R8tEpu8efDQ52PhwxGzQtLKoD3L+UkCZXRA2AsLM5YhA/RuacOW/zEPbfEtwzimfKpBu bPc4RdE//X9bZFDlrLTTYGIgHBNWc7NZEZWjemdBFH9mdoHE2oWJD+kxseuQTyCsBXL3 +0xIN3BgbTsai3ymCZucRxGVYyO0zsFW00dR6YnTP5L+zXmbjIm4EvDETbynO+lhb5dV EvIHtSp9Ku2qSfsEE2ms2Vsv7s9MPTC2vq838kDkXnEHDYTlszeJH5XoWgTElpOp6TJN v15w== X-Gm-Message-State: AEkoousw5Z1tiUct0F/kD9TlVTdGn/FGW4GXWl3RSJZFPYgdpboWU9PDYf5MoTW6QNf85GViUhV1zZUS661t0A== X-Received: by 10.55.98.205 with SMTP id w196mr24031726qkb.65.1469471587395; Mon, 25 Jul 2016 11:33:07 -0700 (PDT) MIME-Version: 1.0 Sender: jinmei.tatuya@gmail.com Received: by 10.237.33.154 with HTTP; Mon, 25 Jul 2016 11:33:06 -0700 (PDT) In-Reply-To: <1967.1469274288@obiwan.sandelman.ca> References: <26582.1468923195@obiwan.sandelman.ca> <2EBFA6F2-00A3-45E1-BE0E-3531AF75726A@employees.org> <787AE7BB302AE849A7480A190F8B933008DE9E22@OPEXCLILMA3.corporate.adroot.infra.ftgroup> <0445fd4c-3d96-73f5-035e-570f165faf9b@gmail.com> <614711c4-9e69-3ddc-67f2-0d20394169ad@si6networks.com> <3edee5c1-3444-bc7d-31e5-1bb29810e857@si6networks.com> <1967.1469274288@obiwan.sandelman.ca> From: =?UTF-8?B?56We5piO6YGU5ZOJ?= Date: Mon, 25 Jul 2016 11:33:06 -0700 X-Google-Sender-Auth: Y62janse3HGuqGG4rOwx30dR-ws Message-ID: Subject: Re: proposed text for header injection revision 05 To: Michael Richardson Content-Type: text/plain; charset=UTF-8 Archived-At: Cc: "6man@ietf.org" <6man@ietf.org> X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.17 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 Jul 2016 18:33:10 -0000 At Sat, 23 Jul 2016 07:44:48 -0400, Michael Richardson wrote: > I'd love to hear that IPsec AH is widely used somewhere, but I have no > evidence of it. The last time I thought AH might have been useful was when > defining SEND, but it turned out to be impossible due to an unfortunate way > we overspecified what to do when the SPI# isn't recognized. > > I think that PMTUD is already broken, so I don't put much value on that > argument. I'm not sure if another round of showing the same points helps this topic, but I have provided another example: inserting an EH in an intermediate node would break the expectation of the source node that (rightly) assumes an IPv6 packet of 1280 bytes or shorter won't be dropped due to a "packet too big" error. Many existing DNS server implementations rely on this assumption. -- JINMEI, Tatuya From nobody Mon Jul 25 12:42:09 2016 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9033A12D5B5 for ; Mon, 25 Jul 2016 12:42:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.188 X-Spam-Level: X-Spam-Status: No, score=-3.188 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-1.287, SPF_PASS=-0.001] 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 kLhnsTT9qc5b for ; Mon, 25 Jul 2016 12:42:06 -0700 (PDT) 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 EE03412B044 for <6man@ietf.org>; Mon, 25 Jul 2016 12:42:05 -0700 (PDT) Received: from sandelman.ca (obiwan.sandelman.ca [IPv6:2607:f0b0:f:2::247]) by tuna.sandelman.ca (Postfix) with ESMTP id A8B7C20183; Mon, 25 Jul 2016 15:51:53 -0400 (EDT) Received: from obiwan.sandelman.ca (localhost [IPv6:::1]) by sandelman.ca (Postfix) with ESMTP id BFBCC638BE; Mon, 25 Jul 2016 15:42:04 -0400 (EDT) From: Michael Richardson To: "6man\@ietf.org" <6man@ietf.org>, =?us-ascii?Q?=3D=3FUTF-8=3FB=3F56We5?= =?us-ascii?Q?piO6YGU5ZOJ=3F=3D?= Subject: Re: proposed text for header injection revision 05 In-Reply-To: References: <26582.1468923195@obiwan.sandelman.ca> <2EBFA6F2-00A3-45E1-BE0E-3531AF75726A@employees.org> <787AE7BB302AE849A7480A190F8B933008DE9E22@OPEXCLILMA3.corporate.adroot.infra.ftgroup> <0445fd4c-3d96-73f5-035e-570f165faf9b@gmail.com> <614711c4-9e69-3ddc-67f2-0d20394169ad@si6networks.com> <3edee5c1-3444-bc7d-31e5-1bb29810e857@si6networks.com> <1967.1469274288@obiwan.sandelman.ca> X-Mailer: MH-E 8.6; nmh 1.6+dev; GNU Emacs 24.5.1 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.17 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 Jul 2016 19:42:07 -0000 --=-=-= Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable =E7=A5=9E=E6=98=8E=E9=81=94=E5=93=89 wrote: >> I'd love to hear that IPsec AH is widely used somewhere, but I have = no >> evidence of it. The last time I thought AH might have been useful w= as when >> defining SEND, but it turned out to be impossible due to an unfortun= ate way >> we overspecified what to do when the SPI# isn't recognized. >> >> I think that PMTUD is already broken, so I don't put much value on t= hat >> argument. > I'm not sure if another round of showing the same points helps this > topic, but I have provided another example: inserting an EH in an > intermediate node would break the expectation of the source node that > (rightly) assumes an IPv6 packet of 1280 bytes or shorter won't be > dropped due to a "packet too big" error. Many existing DNS server > implementations rely on this assumption. So, we write text that says that systems inserting headers must run on a network which has a large enough MTU that 1280 byte packets are never dropped. NOTE: This is true regardless of how the header is inserted. i.e. this is true if you insert using IPIP header!! We did exactly this in 6lowpan/6lo/RPL. Myself: I see this is basically the NAT discussion again. We try to ignore something that is really happening, and the result is that we paint outselves into a corner, because we failed to negotiate when it was time. Or, we go the SIP way, and define how the interaction with intermediaries is going to be treated. =2D- Michael Richardson , Sandelman Software Works -=3D IPv6 IoT consulting =3D- --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 iQEVAwUBV5ZrioCLcPvd0N1lAQJduwgAuhR2hxsZyHy7wm36YiSmydCggu5o9CJk RmXVWXmwadjzQT+FpcDNBCfZIFQ9PmCoRE4vlrAGc72z+brgsSBIE1tvPw+OPecM oVdQ3kEL3NrUttJ+vBdoAKKPqm4FVY2l60uLDxIo8nSBajvMkq9tOW0CzK3Osrmu SVJOYc1hC6sFS7b3/6u027vUwBaXMRbf4p0M4NO/lgSD5Xn3ud/dItvtODMTsI9W r2s76vWu4rIuhhc/Ca/t7oJY+Hn2FexGZwjjr3fDDeN5MgNl36Dub4Np+gXiB3vW R+RRGu6rAHMQUV/3XUobWInnBflyPk+3uNWddKgkiNUKg7XQEKWjlw== =yaDL -----END PGP SIGNATURE----- --=-=-=-- From nobody Mon Jul 25 19:12:40 2016 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2D68212D62D for ; Mon, 25 Jul 2016 19:12:39 -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 ixFlfC_vmcR0 for ; Mon, 25 Jul 2016 19:12:37 -0700 (PDT) Received: from mail-pa0-x22b.google.com (mail-pa0-x22b.google.com [IPv6:2607:f8b0:400e:c03::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 6D1CB12D1A2 for ; Mon, 25 Jul 2016 19:12:37 -0700 (PDT) Received: by mail-pa0-x22b.google.com with SMTP id iw10so66657573pac.2 for ; Mon, 25 Jul 2016 19:12:37 -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=tHYOFte3ldLoVzwZoPxcvSjsK2TmkyJdaV5AWVtMM+8=; b=bcrpt200nW15bmh/fPfqrDS4b/yu8Y7xBtiRMKq8HlsFKY8/lU05RdBpDSLV3tHTC7 NhYHkbroax8+KOxryM9GzJA47RDi5tpMF08ykeSE0iYs+nKXSR6UriT3JqZ1HDOYBHPC xYOobpr5GxnkBxDDe5Vocudd9wfRQQQu2LX/i1jJv971ihn+G6F72NjP85ib/1yvy4n0 IAXHl1PvL98nBbaNl8Uu44j3gQSOrst7DuqBCkUh8vm83EyN2ZJltgYKmlzWUavDwjem qLp2bm9ufHzlynXN+03oHWX+qAwLV8GoK9X9EMRCyj7ON2p8qparOW8nS7GWztTQkuA9 5ZmQ== 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=tHYOFte3ldLoVzwZoPxcvSjsK2TmkyJdaV5AWVtMM+8=; b=J0qA6HkCCyVfzGc5G9LCfLcE4BgyU9+jr+84if+p33w39Q3OL4ftA8wjE/Dr8in6y/ 47XItUwOt6SyCOCUzM4Me0wPcvikVyt5lOznDACGRm2OPI8Z3Ki+sMJLSjeVIokw9Ma1 utV46se9EoY6PKzMwmkKNmd2iSNtS9uYVmjtYe0dWa+hxh46YGwkOrGZraj2CFIYSZQZ LVkxCpE/Cpp85prKoKrL4W8zrlRgBlXHBkJnUmQ3Bx+o7mT2EnerrpAAJLw70r50/Yhq kxMf0dnDZVqiySsvzoEUAZD4meZ0fNbLEOMKKAvDZHrKypz60q7vskRo0KSEgFhlpXNj K9+A== X-Gm-Message-State: AEkoouv1nT1bd5tEUvLc66cE9bTgy9V07lk54DNHc1XRftzRBXlelZprg71DORrY7amVcw== X-Received: by 10.66.138.108 with SMTP id qp12mr34768010pab.65.1469499156788; Mon, 25 Jul 2016 19:12:36 -0700 (PDT) Received: from [192.168.178.23] (1.216.69.111.dynamic.snap.net.nz. [111.69.216.1]) by smtp.gmail.com with ESMTPSA id c66sm43014425pfd.24.2016.07.25.19.12.33 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 25 Jul 2016 19:12:35 -0700 (PDT) Subject: Re: Lack of consensus To: otroan@employees.org, "Stefano Previdi (sprevidi)" References: <201607220911.u6M9Bco9077775@givry.fdupont.fr> <948512bb-c741-0509-8442-2d230c5bca49@gmail.com> From: Brian E Carpenter Organization: University of Auckland Message-ID: <18213e8b-117a-a443-36fd-df96d56e14de@gmail.com> Date: Tue, 26 Jul 2016 14:12:33 +1200 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.2.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Archived-At: Cc: 6man WG , Suresh Krishnan X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.17 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 Jul 2016 02:12:39 -0000 On 26/07/2016 06:18, otroan@employees.org wrote: > Stefano, >=20 >>>> I cannot in RFC2026 or RFC6410 find that lack ambiguity is a require= ment to advance a document. >>> >>> That's probably true. But it's still a matter of community consensus;= >> >> >> it looks to me we are stalled into a non-consensus situation and each = time we try to reach some compromise we fall back into a long discussion = (live or through emails). >> >> The closer we got to a form of consensus was during the meeting after = Mark=E2=80=99 suggestion to remove the second paragraph. However, the sit= uation hanged since. >> >> At this stage what are the options if consensus in not reached on a sp= ecific piece of text ? >=20 > That's a good question. If the working group would be willing to live w= ith and respect the outcome, we could ask our AD to make a decision. Or w= e could leave this issue open and revisit it in Seoul, or we could give u= p on making 2460 Internet standard. >=20 > When Bob is back mid-August I'll initiate a discussion with our ADs and= see if we can come up with any other ways forward. >=20 > As an observation; the text we are discussing is not protocol specifica= tion, it is protocol politics. And while I believe enshrining our values = into protocols is fundamental to IETF work, - like routers not being allo= wed to look beyond the IPv6 header, or the 64 bit boundary, it is always= navigation in rocky waters. It is. However, I think we haven't been crisp enough in one respect in th= is discussion. Let me try to explain, even in my current jet-lagged state: IMHO the goal of taking IPv6 to Internet Standard is to freeze a version = of the spec that guarantees *Internet-wide* interoperability. We know that t= here are several challenges to Internet-wide interoperability: #1. The flow label. There are agreed compromises in RFC6437. #2. The traffic class field. That's a complicated story, basically solved= because RFC2474 defines the DSCP as locally significant and mutable. #3. DPI beyond the 40 byte header. That has too many aspects for a single= email, but the fact is that the Internet is not transparent to arbitrary extension headers. That can break PMTUD and/or fragmentation, among other= things. Again there are some compromises in RFC7045 but the problems remain. #4. Others that I have forgotten... So, for *Internet-wide* interoperability, I think we must mitigate #3 as much as possible and I think that is why we should forbid extension header manipulation. However, for both the flow label and the traffic class we have got round the problem: For the flow label, we have language like: " A node that forwards a flow whose flow label value in arriving packets is zero MAY change the flow label value. ... o The option to set the flow label in a forwarding node, if implemented, would presumably be of value in first-hop or ingress routers. ... In situations where the covert channel risk is considered significant, the only certain defense is for a firewall to rewrite non-zero flow labels. This would be an exceptional violation of the rule that the flow label, once set to a non-zero value, must not be changed." In other words, the flow label may be created by a router and may be overwritten by a firewall. For the traffic class, we have language like: " Nodes MAY rewrite the DS field as needed to provide a desired local or end-to-end service. Specifications of DS field translations at DS boundaries are the subject of service level agreements between providers and users, and are outside the scope of this document." In other words, the traffic class may change en route and in particular at administrative boundaries. To me the long-term solution for extension headers has to be along the same lines - but it's complicated, because inserting, deleting or modifying extension headers has more profound implications for Internet-wide interoperability than either the flow label or the traffic class. There are implications for fragmentation, PMTUD, DPI, and probably more. So I don't see how we resolve them in the short term. It's the tussle between that and one particular application for locally-significant extension headers that has led us to this lack of consensus. An approach that was discussed and rejected for the flow-label was to write specific language about domain-specific use of the flow label. As far as I can see, we only have two choices in the present case: 1) Write some specific language about domain-specific use of extension headers. 2) Declare rough consensus for the present text and defer the question of domain-specific extension headers until later. OK, it goes against my preference, but here is some text for 1): Normally, extension headers are not processed by any node along a packet's delivery path, until the packet reaches the node (or each of the set of nodes, in the case of multicast) identified in the Destination Address field of the IPv6 header. Note: If an intermediate forwarding node examines an extension header for any reason, it must do so in accordance with the provisions of [RFC7045]. At the Destination node, normal demultiplexing on the Next Header field of the IPv6 header invokes the module to process the first extension header, or the upper-layer header if no extension header is present. The contents and semantics of each extension header determine whether or not to proceed to the next header. Therefore, extension headers must be processed strictly in the order they appear in the packet; a receiver must not, for example, scan through a packet looking for a particular kind of extension header and process that header prior to processing all preceding ones. There are two exceptions to this process. 1. The Hop-by-Hop Options header carries information that may be exami= ned and processed by every node along a packet's delivery path, including the source and destination nodes. The Hop-by-Hop Options header, when present, must immediately follow the IPv6 header. Its presence is indicated by the value zero in the Next Header field of the IPv6 header. NOTE: While [RFC2460] required that all nodes must examine and process the Hop-by-Hop Options header, it is now expected that nodes along a packet's delivery path only examine and process the Hop-by- Hop Options header if explicitly configured to do so. 2. In a given administrative domain, locally significant extension headers may be inserted and deleted, if and only if any packet leaving the given domain is strictly identical to the packet prior to such insertion and removal. (This can be justified in a Standard because it is based on running code, as far as I know.) Regards Brian From nobody Mon Jul 25 21:18:29 2016 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4EA1312D099 for ; Mon, 25 Jul 2016 21:18:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.988 X-Spam-Level: X-Spam-Status: No, score=-3.988 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, RP_MATCHES_RCVD=-1.287, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=pobox.com; domainkeys=pass (1024-bit key) header.from=heard@pobox.com header.d=pobox.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 onVWLWW6ATbG for ; Mon, 25 Jul 2016 21:18:26 -0700 (PDT) Received: from sasl.smtp.pobox.com (pb-smtp2.pobox.com [64.147.108.71]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 19E9C12B031 for ; Mon, 25 Jul 2016 21:18:24 -0700 (PDT) Received: from sasl.smtp.pobox.com (unknown [127.0.0.1]) by pb-smtp2.pobox.com (Postfix) with ESMTP id 42FA12FFDC for ; Tue, 26 Jul 2016 00:18:22 -0400 (EDT) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=pobox.com; h=mime-version :in-reply-to:references:from:date:message-id:subject:to:cc :content-type; s=sasl; bh=fffzhLpwMiH+0yoMntZnl4QrvEA=; b=XVVAYn KC55JKg4jA547t+HOZ4ejiT/pk/SrTpj2jqiIaIDLBJt/eJ8TyiDucq+SxkrOWRG 1qaGbbJcc4xxcmsgDo3Dvr7k8+Ao0ZZl6e2wtZ5kAXmfCjHTuQ6e/HYA1yMTTtaL 9ZRN0natoM+v2kS4VJNnATetCVU61Z90GunZQ= DomainKey-Signature: a=rsa-sha1; c=nofws; d=pobox.com; h=mime-version :in-reply-to:references:from:date:message-id:subject:to:cc :content-type; q=dns; s=sasl; b=HtBVsP3pGUsLixj/nnStZgh97hO2Yrp5 InSc3AYWt2wfoace5j/zz41y6UcVcMcGVQnZ+fVlP6AKonnZ3jT5wCtaFHxBJeCD kca8NV9daCAqnYB2/WM3hLWzhekUE4tecCEzjk6SloEdAFEme9L5MJkm8thWBc+I W2VQtaugPhk= Received: from pb-smtp2.nyi.icgroup.com (unknown [127.0.0.1]) by pb-smtp2.pobox.com (Postfix) with ESMTP id 3B1D02FFDA for ; Tue, 26 Jul 2016 00:18:22 -0400 (EDT) Received: from mail-yw0-f176.google.com (unknown [209.85.161.176]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by pb-smtp2.pobox.com (Postfix) with ESMTPSA id E67152FFD9 for ; Tue, 26 Jul 2016 00:18:21 -0400 (EDT) Received: by mail-yw0-f176.google.com with SMTP id r9so182507798ywg.0 for ; Mon, 25 Jul 2016 21:18:21 -0700 (PDT) X-Gm-Message-State: AEkooutsftfAE8iOiS0G6EBrpo37aF7mN0pHf018Va1S1fkV8nj2HRSBHkoHnPQde+dqhtQ8XQxQqDMq61jRag== X-Received: by 10.31.199.135 with SMTP id x129mr8249271vkf.27.1469506701510; Mon, 25 Jul 2016 21:18:21 -0700 (PDT) MIME-Version: 1.0 Received: by 10.31.233.1 with HTTP; Mon, 25 Jul 2016 21:18:02 -0700 (PDT) In-Reply-To: <8874.1469475409@obiwan.sandelman.ca> References: <201607220911.u6M9Bco9077775@givry.fdupont.fr> <8874.1469475409@obiwan.sandelman.ca> From: "C. M. Heard" Date: Mon, 25 Jul 2016 21:18:02 -0700 X-Gmail-Original-Message-ID: Message-ID: Subject: Re: proposed text for header injection revision 05 To: Michael Richardson Content-Type: text/plain; charset=UTF-8 X-Pobox-Relay-ID: FD2776BA-52E7-11E6-93D3-EE617A1B28F4-06080547!pb-smtp2.pobox.com Archived-At: Cc: 6man WG X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.17 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 Jul 2016 04:18:27 -0000 On Mon, Jul 25, 2016 at 12:36 PM, Michael Richardson wrote: > C. M. Heard wrote: > > But we should care about the outcome. If an extension headers is > > inserted by any node other than the source of the packet, any ICMP > > error message related to that header goes back to the original source > > of the packet, not to the node that inserted the offending header. > > Right, they go back to the big-bank Cisco PIX firewall, which discards all > the ICMPs, because "security". So what does it matter? Because not every node is behind such a (brain-dead) firewall. //cmh From nobody Mon Jul 25 21:37:53 2016 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AD86E12D0DB for ; Mon, 25 Jul 2016 21:37:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.988 X-Spam-Level: X-Spam-Status: No, score=-3.988 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, RP_MATCHES_RCVD=-1.287, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=pobox.com; domainkeys=pass (1024-bit key) header.from=heard@pobox.com header.d=pobox.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 MLseR54Oayr6 for ; Mon, 25 Jul 2016 21:37:51 -0700 (PDT) Received: from sasl.smtp.pobox.com (pb-smtp2.pobox.com [64.147.108.71]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6B5CF12D60D for ; Mon, 25 Jul 2016 21:37:51 -0700 (PDT) Received: from sasl.smtp.pobox.com (unknown [127.0.0.1]) by pb-smtp2.pobox.com (Postfix) with ESMTP id 7B0D62C17A for ; Tue, 26 Jul 2016 00:37:50 -0400 (EDT) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=pobox.com; h=mime-version :in-reply-to:references:from:date:message-id:subject:to:cc :content-type; s=sasl; bh=LCyh4VmBcBxchP1QJy364K1+f04=; b=RcwOnL VY79kAyw4exQOmOt7v3i7ie2ss1Z6pw0I/L8ONDmZRPe5rQjaPmPsoekl02RjAPL yahn2Oty9TayEgyOD4fddxgK1hNVVs3WDOwf9IkDGxTrzlPOPwhAecozFVbsy29H GFbSGw2eAVMDZ9r0hqBtW4NJYzRrA43GI2DVI= DomainKey-Signature: a=rsa-sha1; c=nofws; d=pobox.com; h=mime-version :in-reply-to:references:from:date:message-id:subject:to:cc :content-type; q=dns; s=sasl; b=ixo6tHUo+G6d9Yjns6pbc2KdLShu/8Rc 4GbLdNzwLxFPX38y+YrxAxGEIgPIq/CDQMreqw/qB5//4Ln04Al7e7O3wdJOaV9O gLsSPyDaZq6PDG/vyc/0bGcstDT07jN2xFyUzBZFTUjhwOaUcSy11JYdpTDoNYHy u3PD7xTcDqE= Received: from pb-smtp2.nyi.icgroup.com (unknown [127.0.0.1]) by pb-smtp2.pobox.com (Postfix) with ESMTP id 7326F2C178 for ; Tue, 26 Jul 2016 00:37:50 -0400 (EDT) Received: from mail-yw0-f174.google.com (unknown [209.85.161.174]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by pb-smtp2.pobox.com (Postfix) with ESMTPSA id 0BACA2C175 for ; Tue, 26 Jul 2016 00:37:50 -0400 (EDT) Received: by mail-yw0-f174.google.com with SMTP id z8so161006067ywa.1 for ; Mon, 25 Jul 2016 21:37:50 -0700 (PDT) X-Gm-Message-State: AEkoouvfaRGoylXmCe3shtO9VKnDtltZ3tQ6trS08n3rcEJ8dbJHccURHnO3pIa8Vu/WZr6z1MEHZVR062u90w== X-Received: by 10.176.6.232 with SMTP id g95mr9313843uag.95.1469507869576; Mon, 25 Jul 2016 21:37:49 -0700 (PDT) MIME-Version: 1.0 Received: by 10.31.233.1 with HTTP; Mon, 25 Jul 2016 21:37:30 -0700 (PDT) In-Reply-To: References: <201607220911.u6M9Bco9077775@givry.fdupont.fr> <8874.1469475409@obiwan.sandelman.ca> From: "C. M. Heard" Date: Mon, 25 Jul 2016 21:37:30 -0700 X-Gmail-Original-Message-ID: Message-ID: Subject: Re: proposed text for header injection revision 05 To: 6man WG Content-Type: text/plain; charset=UTF-8 X-Pobox-Relay-ID: B566927C-52EA-11E6-90A5-EE617A1B28F4-06080547!pb-smtp2.pobox.com Archived-At: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.17 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 Jul 2016 04:37:52 -0000 On Tue, 26 Jul 2016 14:12:33 +1200, Brian E Carpenter wrote: > 2. In a given administrative domain, locally significant extension > headers may be inserted and deleted, if and only if any packet > leaving the given domain is strictly identical to the packet prior > to such insertion and removal. If we do this, could we a least also add text requiring said administrative domain to prevent ICMP error messages relating to the inserted header from being sent to the original source of the packet? And that the header insertion be done in such a way so as to not break PMTUD? //cmh P.S. I am having a hard time seeing why the SPRING proponents are fighting so hard for header insertion, since they have already agreed to use encapsulation, in agreement with the text in https://tools.ietf.org/html/draft-ietf-6man-rfc2460bis-01#page-7 From nobody Mon Jul 25 23:45:20 2016 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2AAA812B027 for ; Mon, 25 Jul 2016 23:45:19 -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 9RG6PRjP2CwL for ; Mon, 25 Jul 2016 23:45:17 -0700 (PDT) Received: from mail-pa0-x231.google.com (mail-pa0-x231.google.com [IPv6:2607:f8b0:400e:c03::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 30FBC126579 for ; Mon, 25 Jul 2016 23:45:17 -0700 (PDT) Received: by mail-pa0-x231.google.com with SMTP id fi15so69094877pac.1 for ; Mon, 25 Jul 2016 23:45:17 -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=w9L6sH1EBdGkzTn1BzW3GIsZ3vsjd2LYHQvFI2D8nR8=; b=wRT/6/HERubpQg4+AyQHPyMYxdGsg8sjtsowA5mhC41SheSislufGD813CUKvAq5b/ NENqEgaXvXbPtyvx8o/Oq+DqPEVQw8lCVAU2Q1A/UHfHDUZGTXc9aC0+5RRzm+Wk5F3M 4RuJyKXTEM5nqB9XvrCAvDeVpIAThwLf3uQPtC73qkZ3TomZu+4EpJTJYuPOnyW2nsjD E9OLdB1N95XSK0SGWOTcw7Dk13W13kvxG/Zi3vXUTHMLkWisz6bUAS7tc7cWD+C3Tt34 9JqmBrycs29RmQx478CwtNlInjIcMs4d8Q1tNWLXiNwTg4/FnBWiiO+4hJ6GqWq4AX0l 26ZQ== 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=w9L6sH1EBdGkzTn1BzW3GIsZ3vsjd2LYHQvFI2D8nR8=; b=jT60gvpC+jz1G1Y0XJSCxweM19Wxa2I2ebzyDz3obygXArJ1ShhPBEYv9pcDE5pcet 3oXgtM7hqCrVjCJTnFXarVsMRi+xrTarJLuie0ZezaqMxxBr8o10p7X8ryjRE6dadklp 6fxQyaC4GrcBNi1YepwxV4AJH71r2lGusZSIbtz0RTcCQlTikICuLzdcDQQ80oVX6sL9 K/j3NAUj/BoIalEYv0zAJfOQ3VKEP0EioCrnwG8gf/3Omqrgl4BjYJ3x8LCGaRp45TYI X1wjdW6iEUfbEYPWQwajNGaoZy0Nk56ErvShQ4l0p6HDGnsSrNi5K3S6t4vzi3DSWog5 huEg== X-Gm-Message-State: AEkoouvtG02KD545ajnHREF76f0y3JEs6UCAGNLyeiLBVd/4Tw76OqCX1KW1bTHYM9vayw== X-Received: by 10.66.55.3 with SMTP id n3mr36247105pap.66.1469515516695; Mon, 25 Jul 2016 23:45:16 -0700 (PDT) Received: from [192.168.178.23] (1.216.69.111.dynamic.snap.net.nz. [111.69.216.1]) by smtp.gmail.com with ESMTPSA id m128sm44705211pfm.42.2016.07.25.23.45.14 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 25 Jul 2016 23:45:16 -0700 (PDT) Subject: Re: proposed text for header injection revision 05 To: "C. M. Heard" , 6man WG References: <201607220911.u6M9Bco9077775@givry.fdupont.fr> <8874.1469475409@obiwan.sandelman.ca> From: Brian E Carpenter Organization: University of Auckland Message-ID: <44b60589-3639-6213-29c3-8cf1d5e04316@gmail.com> Date: Tue, 26 Jul 2016 18:45:14 +1200 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.2.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.17 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 Jul 2016 06:45:19 -0000 On 26/07/2016 16:37, C. M. Heard wrote: > On Tue, 26 Jul 2016 14:12:33 +1200, Brian E Carpenter wrote: >> 2. In a given administrative domain, locally significant extension >> headers may be inserted and deleted, if and only if any packet >> leaving the given domain is strictly identical to the packet prior >> to such insertion and removal. > > If we do this, could we a least also add text requiring said administrative > domain to prevent ICMP error messages relating to the inserted header > from being sent to the original source of the packet? And that the > header insertion be done in such a way so as to not break PMTUD? I think those would be problems that could only harm hosts inside the private domain. Do we care, in the Internet-wide interoperability spec? (But indeed, my preference is to leave that analysis until later, i.e. not make this change. However, I'm a compromise seeker.) > //cmh > > P.S. I am having a hard time seeing why the SPRING proponents > are fighting so hard for header insertion, since they have already > agreed to use encapsulation, in agreement with the text in > https://tools.ietf.org/html/draft-ietf-6man-rfc2460bis-01#page-7 Um, something about running code... Brian From nobody Tue Jul 26 00:16:01 2016 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BCF7212B071 for ; Tue, 26 Jul 2016 00:15:58 -0700 (PDT) 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, RCVD_IN_MSPIKE_H2=-0.001] 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 DWCz_KW7MvrR for ; Tue, 26 Jul 2016 00:15:57 -0700 (PDT) Received: from brown.birch.relay.mailchannels.net (brown.birch.relay.mailchannels.net [23.83.209.23]) (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 06EAD12B014 for ; Tue, 26 Jul 2016 00:15:56 -0700 (PDT) X-Sender-Id: totalchoicehosting|x-authuser|slblake@petri-meat.com Received: from relay.mailchannels.net (localhost [127.0.0.1]) by relay.mailchannels.net (Postfix) with ESMTP id C689C20E2C; Tue, 26 Jul 2016 07:15:55 +0000 (UTC) Received: from elom.tchmachines.com (ip-10-107-69-155.us-west-2.compute.internal [10.107.69.155]) by relay.mailchannels.net (Postfix) with ESMTPA id 5326220E52; Tue, 26 Jul 2016 07:15:53 +0000 (UTC) X-Sender-Id: totalchoicehosting|x-authuser|slblake@petri-meat.com Received: from elom.tchmachines.com (elom.tchmachines.com [10.107.128.240]) (using TLSv1 with cipher DHE-RSA-AES256-SHA) by 0.0.0.0:2500 (trex/5.7.3); Tue, 26 Jul 2016 07:15:55 +0000 X-MC-Relay: Neutral X-MailChannels-SenderId: totalchoicehosting|x-authuser|slblake@petri-meat.com X-MailChannels-Auth-Id: totalchoicehosting X-MC-Loop-Signature: 1469517353681:1200041506 X-MC-Ingress-Time: 1469517353680 Received: from [127.0.0.1] (port=50970 helo=elom.tchmachines.com) by elom.tchmachines.com with esmtpa (Exim 4.87) (envelope-from ) id 1bRwak-00025E-VZ; Tue, 26 Jul 2016 03:15:51 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII; format=flowed Content-Transfer-Encoding: 7bit Date: Tue, 26 Jul 2016 03:15:50 -0400 From: Steven Blake To: Brian E Carpenter Subject: Re: Lack of consensus In-Reply-To: <18213e8b-117a-a443-36fd-df96d56e14de@gmail.com> References: <201607220911.u6M9Bco9077775@givry.fdupont.fr> <948512bb-c741-0509-8442-2d230c5bca49@gmail.com> <18213e8b-117a-a443-36fd-df96d56e14de@gmail.com> Message-ID: <880306fd49db04f4d08958a61512b7d9@petri-meat.com> X-Sender: slblake@petri-meat.com User-Agent: Roundcube Webmail/1.1.4 X-AuthUser: slblake@petri-meat.com Archived-At: Cc: 6man WG X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.17 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 Jul 2016 07:15:59 -0000 On 2016-07-25 22:12, Brian E Carpenter wrote: > So, for *Internet-wide* interoperability, I think we must mitigate #3 > as much as possible and I think that is why we should forbid extension > header manipulation. > > However, for both the flow label and the traffic class we have got > round > the problem: > > For the flow label, we have language like: > > " A node that forwards a flow whose flow label value in arriving > packets is zero MAY change the flow label value. > ... > o The option to set the flow label in a forwarding node, if > implemented, would presumably be of value in first-hop or ingress > routers. > ... > In situations where the covert channel risk is considered > significant, the only certain defense is for a firewall to rewrite > non-zero flow labels. This would be an exceptional violation of the > rule that the flow label, once set to a non-zero value, must not be > changed." > > In other words, the flow label may be created by a router and may be > overwritten by a firewall. > > For the traffic class, we have language like: > > " Nodes MAY rewrite the DS field as needed to provide a desired local > or end-to-end service. Specifications of DS field translations at > DS > boundaries are the subject of service level agreements between > providers and users, and are outside the scope of this document." > > In other words, the traffic class may change en route and in particular > at administrative boundaries. [snip] > To me the long-term solution for extension headers has to be along the > same lines - but it's complicated, because inserting, deleting or > modifying extension headers has more profound implications for > Internet-wide interoperability than either the flow label or the > traffic class. There are implications for fragmentation, PMTUD, > DPI, and probably more. So I don't see how we resolve them in the > short term. It's the tussle between that and one particular application > for locally-significant extension headers that has led us to this > lack of consensus. > > An approach that was discussed and rejected for the flow-label was > to write specific language about domain-specific use of the flow > label. As far as I can see, we only have two choices in the present > case: > > 1) Write some specific language about domain-specific use of extension > headers. > 2) Declare rough consensus for the present text and defer the question > of domain-specific extension headers until later. > > OK, it goes against my preference, but here is some text for 1): > > Normally, extension headers are not processed by any node > along a packet's delivery path, until the packet reaches the node > (or > each of the set of nodes, in the case of multicast) identified in > the > Destination Address field of the IPv6 header. Note: If an > intermediate forwarding node examines an extension header for any > reason, it must do so in accordance with the provisions of > [RFC7045]. > At the Destination node, normal demultiplexing on the Next Header > field of the IPv6 header invokes the module to process the first > extension header, or the upper-layer header if no extension header > is > present. The contents and semantics of each extension header > determine whether or not to proceed to the next header. Therefore, > extension headers must be processed strictly in the order they > appear > in the packet; a receiver must not, for example, scan through a > packet looking for a particular kind of extension header and process > that header prior to processing all preceding ones. > > There are two exceptions to this process. > > 1. The Hop-by-Hop Options header carries information that may be > examined > and processed by every node along a packet's delivery path, > including > the source and destination nodes. The Hop-by-Hop Options header, > when present, must immediately follow the IPv6 header. Its presence > is indicated by the value zero in the Next Header field of the IPv6 > header. > > NOTE: While [RFC2460] required that all nodes must examine and > process the Hop-by-Hop Options header, it is now expected that nodes > along a packet's delivery path only examine and process the Hop-by- > Hop Options header if explicitly configured to do so. > > 2. In a given administrative domain, locally significant extension > headers may be inserted and deleted, if and only if any packet > leaving the given domain is strictly identical to the packet prior > to such insertion and removal. Identical except for possible changes to the flow label and traffic class field, as described above? And the hop limit field, obviously. "Strictly identical" could be misinterpreted here. > (This can be justified in a Standard because it is based on running > code, as far as I know.) > > Regards > Brian Aside: I assume we are still calling it the "traffic class" field instead of DS field (2474, 3260) + ECN field (3168) because those RFCs are only at Proposed? Regards, // Steve From nobody Tue Jul 26 00:45:08 2016 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CE7E512B046 for ; Tue, 26 Jul 2016 00:45:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -15.808 X-Spam-Level: X-Spam-Status: No, score=-15.808 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.287, 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 d4zKEE4mseET for ; Tue, 26 Jul 2016 00:45:05 -0700 (PDT) Received: from rcdn-iport-9.cisco.com (rcdn-iport-9.cisco.com [173.37.86.80]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B0D8512B028 for ; Tue, 26 Jul 2016 00:45:05 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2492; q=dns/txt; s=iport; t=1469519105; x=1470728705; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=Oltcgd0Lx8GhJMkFvf0fMSAAXtASSHeac2MBIYoTpmY=; b=gwbkkC7EaBjGA2KFBJZFCfgfP5jDXfpAIE8zAzXbu/ImxDxMJjNU2OTU Z6Z3o4MAKLn0NXK7QDtSAiRYU/srabEJAT2Y95fyT8Zk7aItyQ7tUZeTk KCR/ColK25spt6X4toLkikUWbYbKj20jiuCYBc2TpjTiIssoZuSaWfgaH E=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0BAAgAAFJdX/4ENJK1dgz+BUga4coF9h?= =?us-ascii?q?h0CHIEgOBQBAQEBAQEBXRwLhFwBAQQBIxFABQULAgEIGAICJgICAjAVEAIEDgU?= =?us-ascii?q?UiBUIqQ2NXAEBAQEBAQEBAQEBAQEBAQEBAQEegQGFKYF4glWHQSuCLwWZMQGOd?= =?us-ascii?q?48/jCyDdwEeNoIQHIFMbodDfwEBAQ?= X-IronPort-AV: E=Sophos;i="5.28,423,1464652800"; d="scan'208";a="127837356" Received: from alln-core-9.cisco.com ([173.36.13.129]) by rcdn-iport-9.cisco.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 26 Jul 2016 07:45:04 +0000 Received: from XCH-RTP-009.cisco.com (xch-rtp-009.cisco.com [64.101.220.149]) by alln-core-9.cisco.com (8.14.5/8.14.5) with ESMTP id u6Q7j4Ii003377 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Tue, 26 Jul 2016 07:45:04 GMT Received: from xch-rtp-010.cisco.com (64.101.220.150) by XCH-RTP-009.cisco.com (64.101.220.149) with Microsoft SMTP Server (TLS) id 15.0.1210.3; Tue, 26 Jul 2016 03:45:03 -0400 Received: from xch-rtp-010.cisco.com ([64.101.220.150]) by XCH-RTP-010.cisco.com ([64.101.220.150]) with mapi id 15.00.1210.000; Tue, 26 Jul 2016 03:45:03 -0400 From: "Stefano Previdi (sprevidi)" To: "otroan@employees.org" Subject: Re: Lack of consensus Thread-Topic: Lack of consensus Thread-Index: AQHR5qEOqAnkt6uaE0+f2MnrwMbVvaAqmQmA Date: Tue, 26 Jul 2016 07:45:03 +0000 Message-ID: References: <201607220911.u6M9Bco9077775@givry.fdupont.fr> <948512bb-c741-0509-8442-2d230c5bca49@gmail.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.61.216.140] Content-Type: text/plain; charset="utf-8" Content-ID: <4EA81BFDE66D9A409A5CE73209AF565D@emea.cisco.com> Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: Cc: 6man WG , Suresh Krishnan X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.17 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 Jul 2016 07:45:07 -0000 DQo+IE9uIEp1bCAyNSwgMjAxNiwgYXQgODoxOCBQTSwgb3Ryb2FuQGVtcGxveWVlcy5vcmcgd3Jv dGU6DQo+IA0KPiBTdGVmYW5vLA0KPiANCj4+Pj4gSSBjYW5ub3QgaW4gUkZDMjAyNiBvciBSRkM2 NDEwIGZpbmQgdGhhdCBsYWNrIGFtYmlndWl0eSBpcyBhIHJlcXVpcmVtZW50IHRvIGFkdmFuY2Ug YSBkb2N1bWVudC4NCj4+PiANCj4+PiBUaGF0J3MgcHJvYmFibHkgdHJ1ZS4gQnV0IGl0J3Mgc3Rp bGwgYSBtYXR0ZXIgb2YgY29tbXVuaXR5IGNvbnNlbnN1czsNCj4+IA0KPj4gDQo+PiBpdCBsb29r cyB0byBtZSB3ZSBhcmUgc3RhbGxlZCBpbnRvIGEgbm9uLWNvbnNlbnN1cyBzaXR1YXRpb24gYW5k IGVhY2ggdGltZSB3ZSB0cnkgdG8gcmVhY2ggc29tZSBjb21wcm9taXNlIHdlIGZhbGwgYmFjayBp bnRvIGEgbG9uZyBkaXNjdXNzaW9uIChsaXZlIG9yIHRocm91Z2ggZW1haWxzKS4NCj4+IA0KPj4g VGhlIGNsb3NlciB3ZSBnb3QgdG8gYSBmb3JtIG9mIGNvbnNlbnN1cyB3YXMgZHVyaW5nIHRoZSBt ZWV0aW5nIGFmdGVyIE1hcmvigJkgc3VnZ2VzdGlvbiB0byByZW1vdmUgdGhlIHNlY29uZCBwYXJh Z3JhcGguIEhvd2V2ZXIsIHRoZSBzaXR1YXRpb24gaGFuZ2VkIHNpbmNlLg0KPj4gDQo+PiBBdCB0 aGlzIHN0YWdlIHdoYXQgYXJlIHRoZSBvcHRpb25zIGlmIGNvbnNlbnN1cyBpbiBub3QgcmVhY2hl ZCBvbiBhIHNwZWNpZmljIHBpZWNlIG9mIHRleHQgPw0KPiANCj4gVGhhdCdzIGEgZ29vZCBxdWVz dGlvbi4gSWYgdGhlIHdvcmtpbmcgZ3JvdXAgd291bGQgYmUgd2lsbGluZyB0byBsaXZlIHdpdGgg YW5kIHJlc3BlY3QgdGhlIG91dGNvbWUsIHdlIGNvdWxkIGFzayBvdXIgQUQgdG8gbWFrZSBhIGRl Y2lzaW9uLiBPciB3ZSBjb3VsZCBsZWF2ZSB0aGlzIGlzc3VlIG9wZW4gYW5kIHJldmlzaXQgaXQg aW4gU2VvdWwsIG9yIHdlIGNvdWxkIGdpdmUgdXAgb24gbWFraW5nIDI0NjAgSW50ZXJuZXQgc3Rh bmRhcmQuDQoNCg0KanVzdCBmb3IgbWUgdG8gdW5kZXJzdGFuZC4gTGVhdmUgYW55IHRleHQgcmVn YXJkaW5nIGhlYWRlciBpbnNlcnRpb24gb3V0IG9mIHNjb3BlIG9mIHJmYzI0NjBiaXMgaXNu4oCZ dCBhbiBvcHRpb24gPw0KDQoNCj4gV2hlbiBCb2IgaXMgYmFjayBtaWQtQXVndXN0IEknbGwgaW5p dGlhdGUgYSBkaXNjdXNzaW9uIHdpdGggb3VyIEFEcyBhbmQgc2VlIGlmIHdlIGNhbiBjb21lIHVw IHdpdGggYW55IG90aGVyIHdheXMgZm9yd2FyZC4NCj4gDQo+IEFzIGFuIG9ic2VydmF0aW9uOyB0 aGUgdGV4dCB3ZSBhcmUgZGlzY3Vzc2luZyBpcyBub3QgcHJvdG9jb2wgc3BlY2lmaWNhdGlvbiwg aXQgaXMgcHJvdG9jb2wgcG9saXRpY3MuDQoNCg0KaW5kZWVkIGFuZCB0aGF04oCZcyB3aHkgSSBh c2tlZCBpZiB0aGUgb3B0aW9uIHRvIGxlYXZlIHRoaXMgb3V0c2lkZSB0aGUgc2NvcGUgaXMgcmVh bGlzdGljLg0KDQoNCj4gQW5kIHdoaWxlIEkgYmVsaWV2ZSBlbnNocmluaW5nIG91ciB2YWx1ZXMg aW50byBwcm90b2NvbHMgaXMgZnVuZGFtZW50YWwgdG8gSUVURiB3b3JrLCAtIGxpa2Ugcm91dGVy cyBub3QgYmVpbmcgYWxsb3dlZCB0byAgbG9vayBiZXlvbmQgdGhlIElQdjYgaGVhZGVyLCBvciB0 aGUgNjQgYml0IGJvdW5kYXJ5LCBpdCBpcyBhbHdheXMgbmF2aWdhdGlvbiBpbiByb2NreSB3YXRl cnMuDQoNCg0Ka25vd2luZyB0aGF0IHJvdXRlcnMgZG8gYWxyZWFkeSBkbyB3YXkgbW9yZSB0aGFu IHdoYXQgdGhlIOKAnHNwZWNz4oCdIGFsbG93cyB0aGVtIHRvIGRvLg0KDQpIZWxsIGlzIGZ1bGwg b2YgY29kZXJzLi4uDQoNCnMuDQoNCg0KPiANCj4gQmVzdCByZWdhcmRzLA0KPiBPbGUNCg0K From nobody Tue Jul 26 01:53:33 2016 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6571D12B036 for ; Tue, 26 Jul 2016 01:53:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.2 X-Spam-Level: X-Spam-Status: No, score=-1.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, FROM_LOCAL_NOVOWEL=0.5, HK_RANDOM_ENVFROM=0.001, HK_RANDOM_FROM=0.999, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=no 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 numvJJZxdzOf for ; Tue, 26 Jul 2016 01:53:31 -0700 (PDT) Received: from mail-yw0-x233.google.com (mail-yw0-x233.google.com [IPv6:2607:f8b0:4002:c05::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 429E8127058 for <6man@ietf.org>; Tue, 26 Jul 2016 01:53:31 -0700 (PDT) Received: by mail-yw0-x233.google.com with SMTP id z8so678912ywa.1 for <6man@ietf.org>; Tue, 26 Jul 2016 01:53:31 -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=8za1OzOOQpv4LEQ7bmzsLSU7c3uSPz65MT/IwuYVscA=; b=LAHKfssSgY8TNoVC8a03qficNOg4TYYgv2eM6qxEiUTaDcBW21IlKfObKUTJZg5CDK uAxI1KcM6Qa4/asmxhpw1nZXsVzO9adOd65WSn1sgWc6iJOjVjO9aA5gbLCpZeYLsZzk hvPeCnz3tjPwC1zGH1Zj24dblQ7RWxoMvqWZkAKICPhIASJvOh9t3uvmauN/iuJa1AHZ 8r2ptP8gKjnAk2zu9xNki8eUngYjgMrrtBljJRTxBvy8pty62rvzv4leRCX/A3w92qpi bbzlyI5nMvDg8ALdcsgpJwTO+wYQX7+m9zzZvzs5eFIlde8DBPFoikg4OTYNXDorGI0l SsIA== 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=8za1OzOOQpv4LEQ7bmzsLSU7c3uSPz65MT/IwuYVscA=; b=JOQ7HOI4x0XC/nGMx00Ycioj+OwLWY3xU4B6QVTvkP/2ZzHe155/WJZOVeDJ+ZFOw0 +qYc/lxVG8zi6nNZ9xOxPZw4HFhvlRPbwPJ7vtJ59BmNwUzSdp0qPfqxs7mevgj7H2fn 9vq62FxXWe9WqQ71p8RYaHjWlJWO3aVNZkX3F/YZ/RoWRGPtOiX5O4Bgf88i+ASVJ9So kWMqjARANy1qkfQLK/HvlwTxZshbZ0U6/3iAYZA9BjFWaG6jUGCzORWWBMy36NLLMrWh Fq2EydkQOMEfDuUtuk248fa3hayi5HlEblf0KCFFtGL1mlQHrApcc3AwNyUhSVVAME2M ew7Q== X-Gm-Message-State: AEkoouuF+6+PXkl/Ff3z26I498Qp5GReGfn3dfiLLsWEcc11IuFY/TjRYwR9wyv8EAFuay8wZzpAs328dqIhyA== X-Received: by 10.31.93.129 with SMTP id r123mr9750801vkb.149.1469523210441; Tue, 26 Jul 2016 01:53:30 -0700 (PDT) MIME-Version: 1.0 Received: by 10.159.39.233 with HTTP; Tue, 26 Jul 2016 01:53:00 -0700 (PDT) In-Reply-To: <9999.1469475724@obiwan.sandelman.ca> References: <26582.1468923195@obiwan.sandelman.ca> <2EBFA6F2-00A3-45E1-BE0E-3531AF75726A@employees.org> <787AE7BB302AE849A7480A190F8B933008DE9E22@OPEXCLILMA3.corporate.adroot.infra.ftgroup> <0445fd4c-3d96-73f5-035e-570f165faf9b@gmail.com> <614711c4-9e69-3ddc-67f2-0d20394169ad@si6networks.com> <3edee5c1-3444-bc7d-31e5-1bb29810e857@si6networks.com> <1967.1469274288@obiwan.sandelman.ca> <9999.1469475724@obiwan.sandelman.ca> From: Mark Smith Date: Tue, 26 Jul 2016 18:53:00 +1000 Message-ID: Subject: Re: proposed text for header injection revision 05 To: Michael Richardson Content-Type: text/plain; charset=UTF-8 Archived-At: Cc: "6man@ietf.org" <6man@ietf.org>, =?UTF-8?B?56We5piO6YGU5ZOJ?= X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.17 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 Jul 2016 08:53:32 -0000 On 26 July 2016 at 05:42, Michael Richardson wrote: > > > Myself: I see this is basically the NAT discussion again. We try to ignore > something that is really happening, and the result is that we paint > outselves into a corner, because we failed to negotiate when it was > time. > Or, we go the SIP way, and define how the interaction with > intermediaries is going to be treated. > I think the EH insertion comparison with NAT is interesting. In the inside to outside direction, when the NAT modifies the packet it changes the source address of the packet to its own outside address. So it is really re-originating the packet after it has made its modifications, because it is stating it is the source of those changes. In the 'hosts and routers' model, that makes the NAT a host in that direction. Prior to the NAT, the source address is the origin host of the packet, and post the NAT, the NAT is the new source of the modified packet. The source address is reflecting the device that originated the packet into the network that the packet is being sent into. Things that assume the source address is the device that originated the packet, such as PMTUD and troubleshooting, should work in this direction. In the outside to inside direction, only the destination address is changed, so the NAT is not reflecting that it effectively re-originated the packet into the inside network by updating the source address. In the hosts and routers model, it is neither a host or a router, because it is doing more than just forwarding but doing less than a host (i.e., in the least, not setting the source address to its own address). Things such as PMTUD are not going to work in this direction. Troubleshooting is harder too, although since there is usually an obvious boundary between the inside and outside networks that can be deduced from the boundary between the inside private addressing and the outside public addressing, the NAT device at that boundary becomes the first device to suspect to have failed. Inserting EHs has none of these attributes or indicators of whether or not and where the EH might have been inserted in the network, as the packet's source address will never be updated when the EH is added, and there is no EH insertion boundary that can be as easily deduced from the type of address being used in either the source or destination address in the packet. Regards, Mark. From nobody Tue Jul 26 02:16:00 2016 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 47FAD126FDC for ; Tue, 26 Jul 2016 02:15:58 -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 i4DPEPkjc_iu for ; Tue, 26 Jul 2016 02:15:56 -0700 (PDT) Received: from stereo.hq.phicoh.net (stereo.hq.phicoh.net [130.37.15.35]) by ietfa.amsl.com (Postfix) with ESMTP id 56177120727 for ; Tue, 26 Jul 2016 02:15:56 -0700 (PDT) Received: from stereo.hq.phicoh.net (localhost [::ffff:127.0.0.1]) by stereo.hq.phicoh.net with esmtp (Smail #91) id m1bRySw-0000CuC; Tue, 26 Jul 2016 11:15:54 +0200 Message-Id: To: ipv6@ietf.org Subject: Re: Lack of consensus From: Philip Homburg Sender: pch-bBB316E3E@u-1.phicoh.com References: <201607220911.u6M9Bco9077775@givry.fdupont.fr> <948512bb-c741-0509-8442-2d230c5bca49@gmail.com> <18213e8b-117a-a443-36fd-df96d56e14de@gmail.com> In-reply-to: Your message of "Tue, 26 Jul 2016 14:12:33 +1200 ." <18213e8b-117a-a443-36fd-df96d56e14de@gmail.com> Date: Tue, 26 Jul 2016 11:15:53 +0200 Archived-At: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.17 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 Jul 2016 09:15:58 -0000 In your letter dated Tue, 26 Jul 2016 14:12:33 +1200 you wrote: > 2. In a given administrative domain, locally significant extension > headers may be inserted and deleted, if and only if any packet > leaving the given domain is strictly identical to the packet > prior to such insertion and removal. What about adding some text to the effect: headers can be inserted only if there is a very low probability that an error ICMP will be generated based on the packet with the header inserted. In particular the node that inserts the header makes sure that the new packet will not trigger any MTU limits and checks the packet for any parameter problems or routing issues. From nobody Tue Jul 26 03:30:30 2016 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7EC3A12D0B3 for ; Tue, 26 Jul 2016 03:30:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.111 X-Spam-Level: X-Spam-Status: No, score=-4.111 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, T_DKIM_INVALID=0.01] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=fail (1024-bit key) reason="fail (message has been altered)" header.d=jisc365.onmicrosoft.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 LidV-pmrrSJ2 for ; Tue, 26 Jul 2016 03:30:26 -0700 (PDT) Received: from eu-smtp-delivery-189.mimecast.com (eu-smtp-delivery-189.mimecast.com [146.101.78.189]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 761E612B02D for ; Tue, 26 Jul 2016 03:30:26 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=jisc365.onmicrosoft.com; s=selector1-jisc-ac-uk; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=NX8kID5S0noi8cXAoTjYe1P5ae38Z280z2Rs7r3IXLE=; b=fS3N1MdwItoKb8T5NzW2VN+nF0TokHzUOAgE88foolOe4CnAY09KERLm4kVjAFZ9dW4PyrPzL10fDjDMokwqoHNToDpHk9OedrTTAHDxNngmFDQR/sQQl6g7rRnZEwMu04vCTFcGzYZyl8kd6Il+EyL4icm+9DNgCHGVtP3cOTk= Received: from EUR01-VE1-obe.outbound.protection.outlook.com (mail-ve1eur01lp0247.outbound.protection.outlook.com [213.199.154.247]) (Using TLS) by eu-smtp-1.mimecast.com with ESMTP id uk-mta-27-ZUFU6hvWPjOvC8GovFzgNA-1; Tue, 26 Jul 2016 11:30:18 +0100 Received: from AMSPR07MB455.eurprd07.prod.outlook.com (10.242.106.148) by AMSPR07MB453.eurprd07.prod.outlook.com (10.242.106.143) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P384) id 15.1.544.10; Tue, 26 Jul 2016 10:30:15 +0000 Received: from AMSPR07MB455.eurprd07.prod.outlook.com ([10.242.106.148]) by AMSPR07MB455.eurprd07.prod.outlook.com ([10.242.106.148]) with mapi id 15.01.0539.023; Tue, 26 Jul 2016 10:30:16 +0000 From: Tim Chown To: 6man WG Subject: Which use cases are using direct EH insertion? Thread-Topic: Which use cases are using direct EH insertion? Thread-Index: AQHR5yizW9O1LklItkaddsrl+FhZhw== Date: Tue, 26 Jul 2016 10:30:15 +0000 Message-ID: References: <201607220911.u6M9Bco9077775@givry.fdupont.fr> <948512bb-c741-0509-8442-2d230c5bca49@gmail.com> <18213e8b-117a-a443-36fd-df96d56e14de@gmail.com> In-Reply-To: Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-mailer: Apple Mail (2.3124) x-ms-exchange-messagesentrepresentingtype: 1 x-originating-ip: [2001:a88:d510:1101:829:f3ee:fc02:77e0] x-ms-office365-filtering-correlation-id: d08ad087-7859-4c12-7378-08d3b53fd5af x-microsoft-exchange-diagnostics: 1; AMSPR07MB453; 20:KuxDm4v4lN8wIPRU+J3Sa7JePCGavRNoD9sxDiG0aFyi2KGTNCzuuhCaVbSvrYVifS/xms2uoh86QWNV2xV2t3ba7Pt8M8wBP7y4gInSo8rvaZ282+1YVKqMwkxbXc31gr1COt9sxbazrFvOEyJGye7BjzOF7ZfEjl5BSwH58BM= x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:AMSPR07MB453; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(158342451672863); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(601004)(2401047)(8121501046)(5005006)(10201501046)(3002001); SRVR:AMSPR07MB453; BCL:0; PCL:0; RULEID:; SRVR:AMSPR07MB453; x-forefront-prvs: 00159D1518 x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(6009001)(7916002)(189002)(199003)(102836003)(6116002)(5002640100001)(101416001)(586003)(8936002)(92566002)(81156014)(81166006)(2906002)(450100001)(122556002)(93886004)(3280700002)(107886002)(189998001)(10400500002)(110136002)(8676002)(50986999)(7846002)(76176999)(7736002)(68736007)(305945005)(83716003)(86362001)(77096005)(106116001)(3660700001)(57306001)(36756003)(50226002)(106356001)(33656002)(74482002)(87936001)(97736004)(2900100001)(229853001)(2950100001)(82746002)(105586002)(3826002)(104396002); DIR:OUT; SFP:1101; SCL:1; SRVR:AMSPR07MB453; H:AMSPR07MB455.eurprd07.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; MX:1; A:1; LANG:en; spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-ID: <30D8392689973A44A6B3FEE9E56FAF44@eurprd07.prod.outlook.com> MIME-Version: 1.0 X-OriginatorOrg: jisc.ac.uk X-MS-Exchange-CrossTenant-originalarrivaltime: 26 Jul 2016 10:30:15.9972 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 48f9394d-8a14-4d27-82a6-f35f12361205 X-MS-Exchange-Transport-CrossTenantHeadersStamped: AMSPR07MB453 X-MC-Unique: ZUFU6hvWPjOvC8GovFzgNA-1 Content-Type: text/plain; charset=WINDOWS-1252 Content-Transfer-Encoding: quoted-printable Archived-At: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.17 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 Jul 2016 10:30:28 -0000 Hi, I=92m still not clear as to where in any current IETF RFC/I-D there is text= stating that a new EH should be inserted into an existing packet traversin= g a path, rather than encapsulated. For the Type 4 RH used for Segment Routing, in draft-ietf-6man-segment-rout= ing-header-01 it says in Section 2: " While the source routing model defined in [RFC2460] doesn't mandate which node is allowed to insert (or modify) the SRH, it is assumed in this document that the SRH is inserted in the packet by its source. For example: o At the node originating the packet (host, server). o At the ingress node of an SR domain where the ingress node receives an IPv6 packet and encapsulates it into an outer IPv6 header followed by a Segment Routing header.=94 and then in Section 2.2.1: "The outer header with the SRH is no different from any other tunneling encapsulation mechanism and allows a network operator to implement traffic engineering mechanisms so to efficiently steer traffic across his infrastructure." So that implies encapsulation. For the Type 3 RH used in RPL, in RFC6554 it says in Section 2: =93There are two cases that determine how to include an SRH when a RPL router requires the use of an SRH to deliver a datagram to its destination. 1. If the SRH specifies the complete path from source to destination, the router places the SRH directly in the datagram itself. 2. If the SRH only specifies a subset of the path from source to destination, the router uses IPv6-in-IPv6 tunneling [RFC2473] and places the SRH in the outer IPv6 header. Use of tunneling ensures that the datagram is delivered unmodified and that ICMP errors return to the source of the SRH rather than the source of the original datagram.=94 Which also implies encapsulation. So who is actually doing direct EH insertion into packets today? Am I misin= terpreting the above documents, or are there use cases that are not being s= tandardised in IETF documents? Tim From nobody Tue Jul 26 03:37:51 2016 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 07AA912D626 for ; Tue, 26 Jul 2016 03:37:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.111 X-Spam-Level: X-Spam-Status: No, score=-4.111 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, T_DKIM_INVALID=0.01] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=fail (1024-bit key) reason="fail (message has been altered)" header.d=jisc365.onmicrosoft.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 EgojmjtUUgxQ for ; Tue, 26 Jul 2016 03:37:47 -0700 (PDT) Received: from eu-smtp-delivery-189.mimecast.com (eu-smtp-delivery-189.mimecast.com [146.101.78.189]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 883D412D664 for ; Tue, 26 Jul 2016 03:37:36 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=jisc365.onmicrosoft.com; s=selector1-jisc-ac-uk; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=c9QNldKFHTvpg/m1h5Kv/6m7f7s3fXdCUSCYIj1SMjQ=; b=ORibJ5crMguWCKh4aJbNvhjoFL9+QaP5hQqgz6PjoAzilrtz9iMe375YXjO5cXEg4vF0qUHyUoIaDhdm+NAQH3ioYNAM5rnetc1gUu6ec964WYiT9NuH7Jz0Q/1LIxFeN+Updhj+XSOQWoBoyi7Fz2ozl4dSvvQeJNe+OT9N47Y= Received: from EUR01-VE1-obe.outbound.protection.outlook.com (mail-ve1eur01lp0247.outbound.protection.outlook.com [213.199.154.247]) (Using TLS) by eu-smtp-1.mimecast.com with ESMTP id uk-mta-57-orq77Z3kO2uo69Bv_0lVcA-1; Tue, 26 Jul 2016 11:37:29 +0100 Received: from AMSPR07MB455.eurprd07.prod.outlook.com (10.242.106.148) by AMSPR07MB453.eurprd07.prod.outlook.com (10.242.106.143) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P384) id 15.1.544.10; Tue, 26 Jul 2016 10:37:27 +0000 Received: from AMSPR07MB455.eurprd07.prod.outlook.com ([10.242.106.148]) by AMSPR07MB455.eurprd07.prod.outlook.com ([10.242.106.148]) with mapi id 15.01.0539.023; Tue, 26 Jul 2016 10:37:27 +0000 From: Tim Chown To: Brian E Carpenter Subject: Re: proposed text for header injection revision 05 Thread-Topic: proposed text for header injection revision 05 Thread-Index: AQHR4/kNlst2D/fkNkGzHiWFCp0fOqApUUtjgADQZp6AAAUzAIAAI7AAgABBSwA= Date: Tue, 26 Jul 2016 10:37:27 +0000 Message-ID: <1E0C1BF5-510D-46A1-B0E8-69A302E1C3F9@jisc.ac.uk> References: <201607220911.u6M9Bco9077775@givry.fdupont.fr> <8874.1469475409@obiwan.sandelman.ca> <44b60589-3639-6213-29c3-8cf1d5e04316@gmail.com> In-Reply-To: <44b60589-3639-6213-29c3-8cf1d5e04316@gmail.com> Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-mailer: Apple Mail (2.3124) x-ms-exchange-messagesentrepresentingtype: 1 x-originating-ip: [2001:a88:d510:1101:829:f3ee:fc02:77e0] x-ms-office365-filtering-correlation-id: 4981b883-bbd4-4870-9ec5-08d3b540d6fb x-microsoft-exchange-diagnostics: 1; AMSPR07MB453; 20:mcBGuOil9tzuKXKqM4nhsgKjkBcEFl+2Ng7paNk86hwVpJXreo+IbH5TfaD+fbQRV8pExh6ey7j4GSOZ6Wh8s2D5/mgyRJTFn+oU2NuqBqbUvGnclUkUUwVhPXxWYyej8AK9aN3DBfoRfeCh9oCPgMV5tCyAJKiRYC4SeLlbtPo= x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:AMSPR07MB453; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(17755550239193); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(601004)(2401047)(8121501046)(5005006)(10201501046)(3002001); SRVR:AMSPR07MB453; BCL:0; PCL:0; RULEID:; SRVR:AMSPR07MB453; x-forefront-prvs: 00159D1518 x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(6009001)(7916002)(189002)(24454002)(199003)(102836003)(6116002)(5002640100001)(101416001)(586003)(8936002)(92566002)(81156014)(81166006)(11100500001)(19580395003)(19580405001)(2906002)(122556002)(93886004)(3280700002)(189998001)(10400500002)(4326007)(110136002)(8676002)(50986999)(7846002)(76176999)(7736002)(68736007)(305945005)(83716003)(86362001)(77096005)(106116001)(3660700001)(8666005)(57306001)(15975445007)(36756003)(50226002)(106356001)(33656002)(74482002)(87936001)(97736004)(2900100001)(2950100001)(82746002)(105586002)(7059030)(3826002)(104396002); DIR:OUT; SFP:1101; SCL:1; SRVR:AMSPR07MB453; H:AMSPR07MB455.eurprd07.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; MX:1; A:1; LANG:en; spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-ID: MIME-Version: 1.0 X-OriginatorOrg: jisc.ac.uk X-MS-Exchange-CrossTenant-originalarrivaltime: 26 Jul 2016 10:37:27.7990 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 48f9394d-8a14-4d27-82a6-f35f12361205 X-MS-Exchange-Transport-CrossTenantHeadersStamped: AMSPR07MB453 X-MC-Unique: orq77Z3kO2uo69Bv_0lVcA-1 Content-Type: text/plain; charset=WINDOWS-1252 Content-Transfer-Encoding: quoted-printable Archived-At: Cc: "C. M. Heard" , 6man WG X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.17 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 Jul 2016 10:37:50 -0000 > On 26 Jul 2016, at 07:45, Brian E Carpenter = wrote: >=20 > On 26/07/2016 16:37, C. M. Heard wrote: >> On Tue, 26 Jul 2016 14:12:33 +1200, Brian E Carpenter wrote: >>> 2. In a given administrative domain, locally significant extension >>> headers may be inserted and deleted, if and only if any packet >>> leaving the given domain is strictly identical to the packet prior >>> to such insertion and removal. >>=20 >> If we do this, could we a least also add text requiring said administrat= ive >> domain to prevent ICMP error messages relating to the inserted header >> from being sent to the original source of the packet? And that the >> header insertion be done in such a way so as to not break PMTUD? >=20 > I think those would be problems that could only harm hosts inside the pri= vate > domain. Do we care, in the Internet-wide interoperability spec? > (But indeed, my preference is to leave that analysis until later, i.e. > not make this change. However, I'm a compromise seeker.) You=92d probably then need to say =93originating administrative domain=94, = to keep the side effects limited to the domain using header insertion. Thou= gh RFC7045 would now probably also see any leaking packets traverse all the= way to their destination while carrying the unintended inserted EH (and pr= obably then dropped by the site firewall=85). >> //cmh >>=20 >> P.S. I am having a hard time seeing why the SPRING proponents >> are fighting so hard for header insertion, since they have already >> agreed to use encapsulation, in agreement with the text in >> https://tools.ietf.org/html/draft-ietf-6man-rfc2460bis-01#page-7 >=20 > Um, something about running code=85 Ah, OK, well that=92s the same question as my last email. Perhaps this sho= uld be written up as an IETF doc, even if only individual submission / Expe= rimental. Tim From nobody Tue Jul 26 04:40:26 2016 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 28A4112D689 for ; Tue, 26 Jul 2016 04:40:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.188 X-Spam-Level: X-Spam-Status: No, score=-3.188 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-1.287, SPF_PASS=-0.001] 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 WozaPranpHVQ for ; Tue, 26 Jul 2016 04:40:22 -0700 (PDT) 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 14A7D12D61F for ; Tue, 26 Jul 2016 04:40:21 -0700 (PDT) Received: from sandelman.ca (obiwan.sandelman.ca [IPv6:2607:f0b0:f:2::247]) by tuna.sandelman.ca (Postfix) with ESMTP id C20E9200A7; Tue, 26 Jul 2016 07:50:11 -0400 (EDT) Received: from obiwan.sandelman.ca (localhost [IPv6:::1]) by sandelman.ca (Postfix) with ESMTP id 978E9638BE; Tue, 26 Jul 2016 07:40:20 -0400 (EDT) From: Michael Richardson To: Brian E Carpenter , 6man WG Subject: Re: Lack of consensus In-Reply-To: <18213e8b-117a-a443-36fd-df96d56e14de@gmail.com> References: <201607220911.u6M9Bco9077775@givry.fdupont.fr> <948512bb-c741-0509-8442-2d230c5bca49@gmail.com> <18213e8b-117a-a443-36fd-df96d56e14de@gmail.com> X-Mailer: MH-E 8.6; nmh 1.6+dev; GNU Emacs 24.5.1 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.17 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 Jul 2016 11:40:24 -0000 --=-=-= Content-Type: text/plain Brian E Carpenter wrote: > 1) Write some specific language about domain-specific use of extension > headers. ... > OK, it goes against my preference, but here is some text for 1): I like your text. (I'm still uncomfortable about the corner we painted outself into which concluded with 7045, but... that's out of scope) I am also reluctant to specify this, but I prefer to specify this than leave 2460bis ambiguous. > (This can be justified in a Standard because it is based on running > code, as far as I know.) And that's really important: we learn from the world and adapt. -- Michael Richardson , Sandelman Software Works -= IPv6 IoT consulting =- --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 iQEVAwUBV5dMIYCLcPvd0N1lAQKB1Qf+Idj2ypiuDTRIU+ZMrOI/H2PugfE/BYtp O50dI7kaAXDYptG+qPzqMt8aweW8FXPiLI7dSjoJ1Uc1Gs3pJsEEBwfv+D1Upsqd Cmbt1tbIvrzV7Bk4S1HYsDKVLJ7Vnvc+UDRgL5GS5a0NUnfQP0W2vI6N2+5jrddF HTrdEJXOimkb+n9nGba4Wvntky7kEmY9mFzsgAaQJUXQCLXU0x7GeiXcQjonJYJT HbRG2RZzEyNGAM67CBIKD6qpjRr91QUAEtSyG9FSNf8kb4ID13c5JbCF9G4899dP OXZSLapRr8WbO0LeZyFKzGLuw/74wuU2LN0R1qm+NgZQJMw9D3iDuw== =VzpT -----END PGP SIGNATURE----- --=-=-=-- From nobody Tue Jul 26 05:39:03 2016 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4E93C12D7BC for ; Tue, 26 Jul 2016 05:39:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.906 X-Spam-Level: X-Spam-Status: No, score=-3.906 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-1.287, SPF_PASS=-0.001, UNPARSEABLE_RELAY=0.001] 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 kmqrpTvjkwdg for ; Tue, 26 Jul 2016 05:38:59 -0700 (PDT) Received: from relais-inet.orange.com (relais-nor34.orange.com [80.12.70.34]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 907B612D7AA for ; Tue, 26 Jul 2016 05:38:59 -0700 (PDT) Received: from opfednr03.francetelecom.fr (unknown [xx.xx.xx.67]) by opfednr27.francetelecom.fr (ESMTP service) with ESMTP id DF73CA05A9; Tue, 26 Jul 2016 14:38:57 +0200 (CEST) Received: from Exchangemail-eme2.itn.ftgroup (unknown [xx.xx.31.21]) by opfednr03.francetelecom.fr (ESMTP service) with ESMTP id B09671A0081; Tue, 26 Jul 2016 14:38:57 +0200 (CEST) Received: from OPEXCLILMA3.corporate.adroot.infra.ftgroup ([fe80::60a9:abc3:86e6:2541]) by OPEXCLILM6C.corporate.adroot.infra.ftgroup ([fe80::d9f5:9741:7525:a199%18]) with mapi id 14.03.0301.000; Tue, 26 Jul 2016 14:38:57 +0200 From: To: Tim Chown , 6man WG Subject: RE: Which use cases are using direct EH insertion? Thread-Topic: Which use cases are using direct EH insertion? Thread-Index: AQHR5yizW9O1LklItkaddsrl+FhZh6AqpHSA Date: Tue, 26 Jul 2016 12:38:56 +0000 Message-ID: <787AE7BB302AE849A7480A190F8B933008DEC973@OPEXCLILMA3.corporate.adroot.infra.ftgroup> References: <201607220911.u6M9Bco9077775@givry.fdupont.fr> <948512bb-c741-0509-8442-2d230c5bca49@gmail.com> <18213e8b-117a-a443-36fd-df96d56e14de@gmail.com> In-Reply-To: Accept-Language: fr-FR, en-US Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.168.234.5] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.17 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 Jul 2016 12:39:01 -0000 Hi Tim,=20 FWIW, a case we are investigating is documented in an individual draft: htt= ps://tools.ietf.org/html/draft-jacquenet-sfc-ipv6-eh-00#section-4=20 EH insertion in that draft can be either be done with encapsulation or with= out encapsulation. Please note that this is an individual proposal and the = IETF endorsed specification in NSH which does not rely on EHs. Cheers, Med > -----Message d'origine----- > De=A0: ipv6 [mailto:ipv6-bounces@ietf.org] De la part de Tim Chown > Envoy=E9=A0: mardi 26 juillet 2016 12:30 > =C0=A0: 6man WG > Objet=A0: Which use cases are using direct EH insertion? >=20 > Hi, >=20 > I'm still not clear as to where in any current IETF RFC/I-D there is text > stating that a new EH should be inserted into an existing packet > traversing a path, rather than encapsulated. >=20 > For the Type 4 RH used for Segment Routing, in draft-ietf-6man-segment- > routing-header-01 it says in Section 2: >=20 > " While the source routing model defined in [RFC2460] doesn't mandate > which node is allowed to insert (or modify) the SRH, it is assumed in > this document that the SRH is inserted in the packet by its source. > For example: >=20 > o At the node originating the packet (host, server). >=20 > o At the ingress node of an SR domain where the ingress node > receives an IPv6 packet and encapsulates it into an outer IPv6 > header followed by a Segment Routing header." >=20 > and then in Section 2.2.1: >=20 > "The outer header with the SRH is no different from any other > tunneling encapsulation mechanism and allows a network operator to > implement traffic engineering mechanisms so to efficiently steer > traffic across his infrastructure." >=20 > So that implies encapsulation. >=20 > For the Type 3 RH used in RPL, in RFC6554 it says in Section 2: >=20 > "There are two cases that determine how to include an SRH when a RPL > router requires the use of an SRH to deliver a datagram to its > destination. >=20 > 1. If the SRH specifies the complete path from source to > destination, the router places the SRH directly in the datagram > itself. >=20 > 2. If the SRH only specifies a subset of the path from source to > destination, the router uses IPv6-in-IPv6 tunneling [RFC2473] and > places the SRH in the outer IPv6 header. Use of tunneling > ensures that the datagram is delivered unmodified and that ICMP > errors return to the source of the SRH rather than the source of > the original datagram." >=20 > Which also implies encapsulation. >=20 > So who is actually doing direct EH insertion into packets today? Am I > misinterpreting the above documents, or are there use cases that are not > being standardised in IETF documents? >=20 > Tim >=20 > -------------------------------------------------------------------- > IETF IPv6 working group mailing list > ipv6@ietf.org > Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 > -------------------------------------------------------------------- From nobody Tue Jul 26 06:35:18 2016 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6D21D12DCA6 for ; Tue, 26 Jul 2016 06:35:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.566 X-Spam-Level: X-Spam-Status: No, score=-0.566 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_SORBS_WEB=0.77, SPF_HELO_PASS=-0.001, SPF_SOFTFAIL=0.665] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=employees.org; domainkeys=pass (1024-bit key) header.from=otroan@employees.org header.d=employees.org 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 7-AJ16ZAKrdG for ; Tue, 26 Jul 2016 06:35:12 -0700 (PDT) Received: from incoming.kjsl.com (inbound02.kjsl.com [IPv6:2001:1868:2002::144]) (using TLSv1.2 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3CC2412DCA9 for ; Tue, 26 Jul 2016 06:17:57 -0700 (PDT) Received: from cowbell.employees.org ([65.50.211.142]) by ironport02.kjsl.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 26 Jul 2016 13:17:56 +0000 Received: from cowbell.employees.org (localhost [127.0.0.1]) by cowbell.employees.org (Postfix) with ESMTP id DBFC99CC7C; Tue, 26 Jul 2016 06:17:54 -0700 (PDT) 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=xZyePqbrB6wVWm5cC9pvOgHRoew=; b= JYnkJRiS86UegzODsPRl+wwwf4r3aBKlq78ufVYvmZHMlcT2sihH4b6Axx2v4FO7 /a6nj5i58zpsErloa1JQoYunTkRUhKkXruNRvI+Ddt0Aqz5CAXLIdYqgY0FfzMNW +S0NqdJngEV7Ka33Mg9Nc79pOGeL2hCPrNIsHPTPGt0= 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=Q34D/rdSN8pTvDP5W81+Y+9cMR xc5/Cr4TwOUqd4aKNwWKZg11DP39QOKbFvRvD//nriYy/k5JQ2Jt87BNDAinFnK+ AZR9Kdsntvlvjd98+cKtrKsGniYX0Sn8u2QTymAO45g2imEELWXHG/9M0ocDh8TW Ig5BgEVZx7L6CeVdM= Received: from h.hanazo.no (ti0140a400-2322.bb.online.no [88.88.61.28]) (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 6223A9CC4F; Tue, 26 Jul 2016 06:17:54 -0700 (PDT) Received: from [IPv6:::1] (localhost [IPv6:::1]) by h.hanazo.no (Postfix) with ESMTP id AE0E02C4496D; Tue, 26 Jul 2016 15:17:44 +0200 (CEST) Subject: Re: Which use cases are using direct EH insertion? Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) Content-Type: multipart/signed; boundary="Apple-Mail=_5D163069-81B1-475C-BC7D-8F28C2E39287"; protocol="application/pgp-signature"; micalg=pgp-sha512 X-Pgp-Agent: GPGMail From: otroan@employees.org In-Reply-To: Date: Tue, 26 Jul 2016 15:17:44 +0200 Message-Id: <505CFBC0-F53F-4614-B634-92D0E9A322B6@employees.org> References: <201607220911.u6M9Bco9077775@givry.fdupont.fr> <948512bb-c741-0509-8442-2d230c5bca49@gmail.com> <18213e8b-117a-a443-36fd-df96d56e14de@gmail.com> To: Tim Chown X-Mailer: Apple Mail (2.3124) Archived-At: Cc: 6man WG X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.17 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 Jul 2016 13:35:17 -0000 --Apple-Mail=_5D163069-81B1-475C-BC7D-8F28C2E39287 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 Tim, > I=92m still not clear as to where in any current IETF RFC/I-D there is = text stating that a new EH should be inserted into an existing packet = traversing a path, rather than encapsulated. >=20 > For the Type 4 RH used for Segment Routing, in = draft-ietf-6man-segment-routing-header-01 it says in Section 2: >=20 > " While the source routing model defined in [RFC2460] doesn't mandate > which node is allowed to insert (or modify) the SRH, it is assumed = in > this document that the SRH is inserted in the packet by its source. > For example: >=20 > o At the node originating the packet (host, server). >=20 > o At the ingress node of an SR domain where the ingress node > receives an IPv6 packet and encapsulates it into an outer IPv6 > header followed by a Segment Routing header.=94 >=20 > and then in Section 2.2.1: >=20 > "The outer header with the SRH is no different from any other > tunneling encapsulation mechanism and allows a network operator to > implement traffic engineering mechanisms so to efficiently steer > traffic across his infrastructure." >=20 > So that implies encapsulation. >=20 > For the Type 3 RH used in RPL, in RFC6554 it says in Section 2: >=20 > =93There are two cases that determine how to include an SRH when a RPL > router requires the use of an SRH to deliver a datagram to its > destination. >=20 > 1. If the SRH specifies the complete path from source to > destination, the router places the SRH directly in the datagram > itself. >=20 > 2. If the SRH only specifies a subset of the path from source to > destination, the router uses IPv6-in-IPv6 tunneling [RFC2473] = and > places the SRH in the outer IPv6 header. Use of tunneling > ensures that the datagram is delivered unmodified and that ICMP > errors return to the source of the SRH rather than the source of > the original datagram.=94 >=20 > Which also implies encapsulation. >=20 > So who is actually doing direct EH insertion into packets today? Am I = misinterpreting the above documents, or are there use cases that are not = being standardised in IETF documents? Indeed, which is leaves me unconvinced that any changes are needed with = regards to the perceived ambiguity. Any proposal of header injection would have to stand on its own feet. Cheers, Ole --Apple-Mail=_5D163069-81B1-475C-BC7D-8F28C2E39287 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 iQEcBAEBCgAGBQJXl2L4AAoJED4aXnjSQuKWKaMH/24DEe7lSoX+j5EVSG7IbDkC o6mo5ateIgX0nzzwroxoCBfBH2cOBTevY68Qc8ipF09FvCple/MO59/AHd7FouFb 1v124guldrHnAesEA0cZHvp66dV8kB/X0SPlRFx2YY1TmwmDbhCv3ZBxNCFrzz2d lEVaWuwvin4xBLTDkajLEJg4/WOjeZF86CIfV6Zk/fJvLjG7YjoBdsKUeGqKmtR0 9Yz2rfEQLnQJCvcqPD1gABbIKgzz9GSH8TRV3duo7gl0sI4vlKpisXJQq1EWvyLC rfimZ73v7jWqckdgk2axloFr/Spp79aRC6kw4ThM/6T+tbhztt8H6QytUrsbzVI= =dW67 -----END PGP SIGNATURE----- --Apple-Mail=_5D163069-81B1-475C-BC7D-8F28C2E39287-- From nobody Tue Jul 26 08:00:03 2016 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 635FF12DC31 for ; Tue, 26 Jul 2016 08:00:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.5 X-Spam-Level: X-Spam-Status: No, score=-0.5 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, HK_RANDOM_FROM=0.999, SPF_PASS=-0.001] autolearn=no 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 gZ_eiAXd9CIl for ; Tue, 26 Jul 2016 07:59:57 -0700 (PDT) Received: from mail-ua0-x22b.google.com (mail-ua0-x22b.google.com [IPv6:2607:f8b0:400c:c08::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 92B4612DAD8 for ; Tue, 26 Jul 2016 07:28:49 -0700 (PDT) Received: by mail-ua0-x22b.google.com with SMTP id k90so2045466uak.0 for ; Tue, 26 Jul 2016 07:28:49 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=CUa4aj4RQfb/ICvXLfLmlgGbDEtF/x5cPdrDbwMwEFw=; b=ZITJNwGsMErJesyY9rye6bFHK30qyrv3VdWV1ymfKgMnAdboqwbw9D9Kfx/jSAdTsm hkBW+EovyG9esgSZYUHCzTlcng1408oHGqqG8mUgVnnEtTsld2G1Q1DbjFmzX4zUgLXa m3Ms/A4hzYnMIdjlIDOaWW8slcA+CNsPsFflwtGoCqXfFqpnl7g7ABmUI7onzdp8mv6o 6k1Ttqz//B8+ZqgbyrMmhcZ6TIbXUOfvcqb+VKVjhGd9nruKfN6/RcsKXjxfIMO9UphS K25xacwEzU7OXe/RWSvJcl8yckgdQASgIC2gKgl59Z8aY7Ft27fKtAoPDUqYbbpHy2GB UMHg== 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-transfer-encoding; bh=CUa4aj4RQfb/ICvXLfLmlgGbDEtF/x5cPdrDbwMwEFw=; b=GKkVt87cK3hKLajYFIU4ULsukyjzORq1J05NIBq9sCxgmBg0PqDUNkYjS1XoLMeylw sJdito+Q1bzknskSUG6OSUkHJikGgsVT8RIfSg+xKH3MO/NFVY7S8h17VodpFLn8QLRh YuofdtW3M0GijlbZmfuiwqhGLAXHFaGmK0xZT19ngkCrORhzfhyBnY4bHYDoK54JSmTe VmMZ+0sr1Ih9E9mAWFd0PG5uU2DTP0dz530tj0RJaTj1OOR4f7DJrBYeXffzYssdkauI 6NLU6fLfbGQZi7SnFtjnEKxNnJ+U2EdH9LjxbVrfjAb58vFhoRDzshETyH/ITLy4PR51 u2WA== X-Gm-Message-State: AEkoouuHLEmVaukGPnADpfkTiLb96v4Xb1BV1ZLu5yfe7manXYQRrtO9fCk9/A7RUuFPIWCXzHIWlybY1uxf7w== X-Received: by 10.159.55.199 with SMTP id q65mr10311659uaq.125.1469543328572; Tue, 26 Jul 2016 07:28:48 -0700 (PDT) MIME-Version: 1.0 Received: by 10.159.39.233 with HTTP; Tue, 26 Jul 2016 07:28:19 -0700 (PDT) In-Reply-To: <505CFBC0-F53F-4614-B634-92D0E9A322B6@employees.org> References: <201607220911.u6M9Bco9077775@givry.fdupont.fr> <948512bb-c741-0509-8442-2d230c5bca49@gmail.com> <18213e8b-117a-a443-36fd-df96d56e14de@gmail.com> <505CFBC0-F53F-4614-B634-92D0E9A322B6@employees.org> From: Mark Smith Date: Wed, 27 Jul 2016 00:28:19 +1000 Message-ID: Subject: Re: Which use cases are using direct EH insertion? To: Ole Troan Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Archived-At: Cc: 6man WG X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.17 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 Jul 2016 15:00:01 -0000 On 26 July 2016 at 23:17, wrote: > Tim, > >> I=E2=80=99m still not clear as to where in any current IETF RFC/I-D ther= e is text stating that a new EH should be inserted into an existing packet = traversing a path, rather than encapsulated. >> >> For the Type 4 RH used for Segment Routing, in draft-ietf-6man-segment-r= outing-header-01 it says in Section 2: >> >> " While the source routing model defined in [RFC2460] doesn't mandate >> which node is allowed to insert (or modify) the SRH, it is assumed in >> this document that the SRH is inserted in the packet by its source. >> For example: >> >> o At the node originating the packet (host, server). >> >> o At the ingress node of an SR domain where the ingress node >> receives an IPv6 packet and encapsulates it into an outer IPv6 >> header followed by a Segment Routing header.=E2=80=9D >> >> and then in Section 2.2.1: >> >> "The outer header with the SRH is no different from any other >> tunneling encapsulation mechanism and allows a network operator to >> implement traffic engineering mechanisms so to efficiently steer >> traffic across his infrastructure." >> >> So that implies encapsulation. >> >> For the Type 3 RH used in RPL, in RFC6554 it says in Section 2: >> >> =E2=80=9CThere are two cases that determine how to include an SRH when a= RPL >> router requires the use of an SRH to deliver a datagram to its >> destination. >> >> 1. If the SRH specifies the complete path from source to >> destination, the router places the SRH directly in the datagram >> itself. >> This one sounds to me like it is saying routers insert the SRH into an existing packet, as routers don't originate packets, hosts do (or the host component of a router i.e., the control plane.). >> 2. If the SRH only specifies a subset of the path from source to >> destination, the router uses IPv6-in-IPv6 tunneling [RFC2473] and >> places the SRH in the outer IPv6 header. Use of tunneling >> ensures that the datagram is delivered unmodified and that ICMP >> errors return to the source of the SRH rather than the source of >> the original datagram.=E2=80=9D >> >> Which also implies encapsulation. >> >> So who is actually doing direct EH insertion into packets today? Am I mi= sinterpreting the above documents, or are there use cases that are not bein= g standardised in IETF documents? > > Indeed, which is leaves me unconvinced that any changes are needed with r= egards to the perceived ambiguity. > Any proposal of header injection would have to stand on its own feet. > > Cheers, > Ole > > -------------------------------------------------------------------- > IETF IPv6 working group mailing list > ipv6@ietf.org > Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 > -------------------------------------------------------------------- > From nobody Tue Jul 26 08:53:48 2016 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id ACD3912D745 for ; Tue, 26 Jul 2016 08:53:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.988 X-Spam-Level: X-Spam-Status: No, score=-3.988 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, RP_MATCHES_RCVD=-1.287, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=pobox.com; domainkeys=pass (1024-bit key) header.from=heard@pobox.com header.d=pobox.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 T5mlgXhpBEye for ; Tue, 26 Jul 2016 08:53:43 -0700 (PDT) Received: from sasl.smtp.pobox.com (pb-smtp1.pobox.com [64.147.108.70]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7229F12DB0E for ; Tue, 26 Jul 2016 08:32:16 -0700 (PDT) Received: from sasl.smtp.pobox.com (unknown [127.0.0.1]) by pb-smtp1.pobox.com (Postfix) with ESMTP id B7F232DC6F for ; Tue, 26 Jul 2016 11:32:12 -0400 (EDT) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=pobox.com; h=mime-version :from:date:message-id:subject:to:cc:content-type :content-transfer-encoding; s=sasl; bh=EwefPyfeollWE7WSdJK+FPIFv zw=; b=ReYVgp5WTJMZ5owNRb+DHjLNFqjLn7YuxUhKcXtS9h1l4ikQK4iz9hX0M jdnxEOcY9j47/QBbrGyN/bkVKJ+WFzB3cytUkcXiTu31e4KYCiT7CFzrMuk92g1v YSVRDviX72L9hGFrEyGgzcYxnCpNpqPJzFW2blrP72dd6RRSGU= DomainKey-Signature: a=rsa-sha1; c=nofws; d=pobox.com; h=mime-version :from:date:message-id:subject:to:cc:content-type :content-transfer-encoding; q=dns; s=sasl; b=tj/QnCf4wmdibTDyi/l NL7NX4lkjqsa1GSRQvFKivr8D1Rvm5RsMYY33pag7rwAuTHUvljqGszaCQxjyxoD e1bMbVCaqYFBv8ZEYhCST20yME/iH0uY4a0Pa/a9De3S53caTS7WI4nHfNOpM2fm eVWqYPXCm6vp7gnu/KKoXCR8= Received: from pb-smtp1.nyi.icgroup.com (unknown [127.0.0.1]) by pb-smtp1.pobox.com (Postfix) with ESMTP id AEA992DC6E for ; Tue, 26 Jul 2016 11:32:12 -0400 (EDT) Received: from mail-yw0-f174.google.com (unknown [209.85.161.174]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by pb-smtp1.pobox.com (Postfix) with ESMTPSA id 480672DC6A for ; Tue, 26 Jul 2016 11:32:12 -0400 (EDT) Received: by mail-yw0-f174.google.com with SMTP id u134so17921460ywg.3 for ; Tue, 26 Jul 2016 08:32:12 -0700 (PDT) X-Gm-Message-State: AEkoout+UebeVxOBfhR6PMcBlpD71Zc73y0EFZ1hwbUeVHugfT8UIy71IQm4nRy2yuKoDuNevO+NbZE3S3yulg== X-Received: by 10.31.157.139 with SMTP id g133mr8724437vke.49.1469547131682; Tue, 26 Jul 2016 08:32:11 -0700 (PDT) MIME-Version: 1.0 Received: by 10.31.233.1 with HTTP; Tue, 26 Jul 2016 08:31:51 -0700 (PDT) From: "C. M. Heard" Date: Tue, 26 Jul 2016 08:31:51 -0700 X-Gmail-Original-Message-ID: Message-ID: Subject: Re: proposed text for header injection revision 05 To: Brian E Carpenter , Tim Chown Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-Pobox-Relay-ID: 1F85D108-5346-11E6-A490-89D312518317-06080547!pb-smtp1.pobox.com Archived-At: Cc: 6man WG X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.17 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 Jul 2016 15:53:47 -0000 On Tue, Jul 26, 2016 at 3:37 AM, Tim Chown wrote: >> On 26 Jul 2016, at 07:45, Brian E Carpenter wrote: >> On 26/07/2016 16:37, C. M. Heard wrote: >>> On Tue, 26 Jul 2016 14:12:33 +1200, Brian E Carpenter wrote: >>>> 2. In a given administrative domain, locally significant extension >>>> headers may be inserted and deleted, if and only if any packet >>>> leaving the given domain is strictly identical to the packet prior >>>> to such insertion and removal. >>> >>> If we do this, could we a least also add text requiring said administra= tive >>> domain to prevent ICMP error messages relating to the inserted header >>> from being sent to the original source of the packet? And that the >>> header insertion be done in such a way so as to not break PMTUD? >> >> I think those would be problems that could only harm hosts inside the pr= ivate >> domain. Do we care, in the Internet-wide interoperability spec? >> (But indeed, my preference is to leave that analysis until later, i.e. >> not make this change. However, I'm a compromise seeker.) > > You=E2=80=99d probably then need to say =E2=80=9Coriginating administrati= ve domain=E2=80=9D, to keep > the side effects limited to the domain using header insertion. My concern is not what happens to hosts within the originating administrati= ve domain; it's collateral damage to hosts outside that domain. After all, the proposed compromise text does not not require the consent of hosts whose packets might be modified by injected headers. So, how about: 2. In a given administrative domain, locally significant extension headers may be inserted and deleted, if and only if (a) any packet leaving the given domain is strictly identical to the packet prior to such insertion and removal and (b) no ICMP error messages resulting from the inserted header leave the domain where the header was inserted. >>> P.S. I am having a hard time seeing why the SPRING proponents >>> are fighting so hard for header insertion, since they have already >>> agreed to use encapsulation, in agreement with the text in >>> https://tools.ietf.org/html/draft-ietf-6man-rfc2460bis-01#page-7 >> >> Um, something about running code=E2=80=A6 Yes, but is it deployed widely enough to justify promotion to IS? I have to say that if we are going to leave the door to header injection open, I'm deeply uncomfortable with this method of doing so. I would much prefer to see a mandate equivalent to the text in https://tools.ietf.org/html/draft-ietf-6man-rfc2460bis-01#page-7 for the general internet, and explicitly leave for further study the question of inserting locally significant EHs in particular administrative domains. I envision that such further study would result in an applicability statement similar to that in RFC 6936 for zero UDP checksums, and hopefully in significant implementation experience before being elevated to IS. //cmh From nobody Tue Jul 26 08:56:30 2016 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C93C712DBCE for ; Tue, 26 Jul 2016 08:56:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.111 X-Spam-Level: X-Spam-Status: No, score=-4.111 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, T_DKIM_INVALID=0.01] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=fail (1024-bit key) reason="fail (message has been altered)" header.d=jisc365.onmicrosoft.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 OYdWNB9d074d for ; Tue, 26 Jul 2016 08:56:14 -0700 (PDT) Received: from eu-smtp-delivery-189.mimecast.com (eu-smtp-delivery-189.mimecast.com [207.82.80.189]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2917212DCF9 for ; Tue, 26 Jul 2016 08:36:30 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=jisc365.onmicrosoft.com; s=selector1-jisc-ac-uk; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=77lO3ms4ptHzpCA8JgfTIxgiJhq5rLy6OYX+1XjhOXI=; b=aHsd/LJ2Pg8cWl1E+Dv8qoaxix9uTALSYSg+WGw/TUnWC8NiHPWI78mrJBjPB2O5dv+YfouG/NQfhnipWrhEwM26lPbFNQy9LBR09Q6AD9JVRv2hgCHmlcpf1JquDm94U0tQop4pgQIJf315wmMGx/b157VlajX9wrquBfr19Ic= Received: from EUR01-HE1-obe.outbound.protection.outlook.com (mail-he1eur01lp0207.outbound.protection.outlook.com [213.199.154.207]) (Using TLS) by eu-smtp-1.mimecast.com with ESMTP id uk-mta-26-qGqyqRt0MsCxiliyJekogw-1; Tue, 26 Jul 2016 16:36:22 +0100 Received: from AMSPR07MB455.eurprd07.prod.outlook.com (10.242.106.148) by AMSPR07MB454.eurprd07.prod.outlook.com (10.242.106.145) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P384) id 15.1.544.10; Tue, 26 Jul 2016 15:36:20 +0000 Received: from AMSPR07MB455.eurprd07.prod.outlook.com ([10.242.106.148]) by AMSPR07MB455.eurprd07.prod.outlook.com ([10.242.106.148]) with mapi id 15.01.0539.023; Tue, 26 Jul 2016 15:36:20 +0000 From: Tim Chown To: Mark Smith Subject: Re: Which use cases are using direct EH insertion? Thread-Topic: Which use cases are using direct EH insertion? Thread-Index: AQHR5yizPrgcIvGDPEKIMG4oXEEYxqAqsd4AgAATuYCAABNsAA== Date: Tue, 26 Jul 2016 15:36:20 +0000 Message-ID: References: <201607220911.u6M9Bco9077775@givry.fdupont.fr> <948512bb-c741-0509-8442-2d230c5bca49@gmail.com> <18213e8b-117a-a443-36fd-df96d56e14de@gmail.com> <505CFBC0-F53F-4614-B634-92D0E9A322B6@employees.org> In-Reply-To: Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-mailer: Apple Mail (2.3124) x-ms-exchange-messagesentrepresentingtype: 1 x-originating-ip: [2001:a88:d510:1101:829:f3ee:fc02:77e0] x-ms-office365-filtering-correlation-id: 28fd0e0e-4c03-4c53-6655-08d3b56a9784 x-microsoft-exchange-diagnostics: 1; AMSPR07MB454; 20:y2fjKyIpWW0CtqhJZn1fIAxdvrqc4o9EhsVg3xiaVSygZPt8citriOjaHbZnheTGZXMnPiUesPJ3IVVNZgvrxuFFIuXhaoOFu5tHwcF/e6PHy/ATSys+JJxB3NNLAhbg+jI7S5zBPE7V/p8GBUaU45eXMD2yUo2kC0jT/RGOSZc= x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:AMSPR07MB454; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(158342451672863)(17755550239193); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(601004)(2401047)(8121501046)(5005006)(10201501046)(3002001); SRVR:AMSPR07MB454; BCL:0; PCL:0; RULEID:; SRVR:AMSPR07MB454; x-forefront-prvs: 00159D1518 x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(6009001)(7916002)(85644002)(189002)(24454002)(199003)(57306001)(8936002)(122556002)(81156014)(81166006)(50986999)(82746002)(50226002)(101416001)(19580395003)(19580405001)(36756003)(3280700002)(10400500002)(76176999)(7736002)(97736004)(106356001)(189998001)(2906002)(1411001)(93886004)(7846002)(8676002)(305945005)(106116001)(92566002)(77096005)(4326007)(110136002)(83716003)(74482002)(2900100001)(33656002)(68736007)(2950100001)(15975445007)(102836003)(86362001)(5002640100001)(11100500001)(586003)(87936001)(105586002)(561944003)(6116002)(3660700001)(3826002)(104396002); DIR:OUT; SFP:1101; SCL:1; SRVR:AMSPR07MB454; H:AMSPR07MB455.eurprd07.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; MX:1; A:1; LANG:en; spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-ID: <66D2CB4BC684CC449A864BEC4974A89F@eurprd07.prod.outlook.com> MIME-Version: 1.0 X-OriginatorOrg: jisc.ac.uk X-MS-Exchange-CrossTenant-originalarrivaltime: 26 Jul 2016 15:36:20.1028 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 48f9394d-8a14-4d27-82a6-f35f12361205 X-MS-Exchange-Transport-CrossTenantHeadersStamped: AMSPR07MB454 X-MC-Unique: qGqyqRt0MsCxiliyJekogw-1 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: base64 Archived-At: Cc: 6man WG X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.17 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 Jul 2016 15:56:29 -0000 SGkgTWFyaywNCg0KPiBPbiAyNiBKdWwgMjAxNiwgYXQgMTU6MjgsIE1hcmsgU21pdGggPG1hcmt6 enpzbWl0aEBnbWFpbC5jb20+IHdyb3RlOg0KPiANCj4gT24gMjYgSnVseSAyMDE2IGF0IDIzOjE3 LCAgPG90cm9hbkBlbXBsb3llZXMub3JnPiB3cm90ZToNCj4+IFRpbSwNCj4+IA0KPj4+IEnigJlt IHN0aWxsIG5vdCBjbGVhciBhcyB0byB3aGVyZSBpbiBhbnkgY3VycmVudCBJRVRGIFJGQy9JLUQg dGhlcmUgaXMgdGV4dCBzdGF0aW5nIHRoYXQgYSBuZXcgRUggc2hvdWxkIGJlIGluc2VydGVkIGlu dG8gYW4gZXhpc3RpbmcgcGFja2V0IHRyYXZlcnNpbmcgYSBwYXRoLCByYXRoZXIgdGhhbiBlbmNh cHN1bGF0ZWQuDQo+Pj4gDQo+Pj4gRm9yIHRoZSBUeXBlIDQgUkggdXNlZCBmb3IgU2VnbWVudCBS b3V0aW5nLCBpbiBkcmFmdC1pZXRmLTZtYW4tc2VnbWVudC1yb3V0aW5nLWhlYWRlci0wMSBpdCBz YXlzIGluIFNlY3Rpb24gMjoNCj4+PiANCj4+PiAiIFdoaWxlIHRoZSBzb3VyY2Ugcm91dGluZyBt b2RlbCBkZWZpbmVkIGluIFtSRkMyNDYwXSBkb2Vzbid0IG1hbmRhdGUNCj4+PiAgd2hpY2ggbm9k ZSBpcyBhbGxvd2VkIHRvIGluc2VydCAob3IgbW9kaWZ5KSB0aGUgU1JILCBpdCBpcyBhc3N1bWVk IGluDQo+Pj4gIHRoaXMgZG9jdW1lbnQgdGhhdCB0aGUgU1JIIGlzIGluc2VydGVkIGluIHRoZSBw YWNrZXQgYnkgaXRzIHNvdXJjZS4NCj4+PiAgRm9yIGV4YW1wbGU6DQo+Pj4gDQo+Pj4gIG8gIEF0 IHRoZSBub2RlIG9yaWdpbmF0aW5nIHRoZSBwYWNrZXQgKGhvc3QsIHNlcnZlcikuDQo+Pj4gDQo+ Pj4gIG8gIEF0IHRoZSBpbmdyZXNzIG5vZGUgb2YgYW4gU1IgZG9tYWluIHdoZXJlIHRoZSBpbmdy ZXNzIG5vZGUNCj4+PiAgICAgcmVjZWl2ZXMgYW4gSVB2NiBwYWNrZXQgYW5kIGVuY2Fwc3VsYXRl cyBpdCBpbnRvIGFuIG91dGVyIElQdjYNCj4+PiAgICAgaGVhZGVyIGZvbGxvd2VkIGJ5IGEgU2Vn bWVudCBSb3V0aW5nIGhlYWRlci7igJ0NCj4+PiANCj4+PiBhbmQgdGhlbiBpbiBTZWN0aW9uIDIu Mi4xOg0KPj4+IA0KPj4+ICJUaGUgb3V0ZXIgaGVhZGVyIHdpdGggdGhlIFNSSCBpcyBubyBkaWZm ZXJlbnQgZnJvbSBhbnkgb3RoZXINCj4+PiAgdHVubmVsaW5nIGVuY2Fwc3VsYXRpb24gbWVjaGFu aXNtIGFuZCBhbGxvd3MgYSBuZXR3b3JrIG9wZXJhdG9yIHRvDQo+Pj4gIGltcGxlbWVudCB0cmFm ZmljIGVuZ2luZWVyaW5nIG1lY2hhbmlzbXMgc28gdG8gZWZmaWNpZW50bHkgc3RlZXINCj4+PiAg dHJhZmZpYyBhY3Jvc3MgaGlzIGluZnJhc3RydWN0dXJlLiINCj4+PiANCj4+PiBTbyB0aGF0IGlt cGxpZXMgZW5jYXBzdWxhdGlvbi4NCj4+PiANCj4+PiBGb3IgdGhlIFR5cGUgMyBSSCB1c2VkIGlu IFJQTCwgaW4gUkZDNjU1NCBpdCBzYXlzIGluIFNlY3Rpb24gMjoNCj4+PiANCj4+PiDigJxUaGVy ZSBhcmUgdHdvIGNhc2VzIHRoYXQgZGV0ZXJtaW5lIGhvdyB0byBpbmNsdWRlIGFuIFNSSCB3aGVu IGEgUlBMDQo+Pj4gIHJvdXRlciByZXF1aXJlcyB0aGUgdXNlIG9mIGFuIFNSSCB0byBkZWxpdmVy IGEgZGF0YWdyYW0gdG8gaXRzDQo+Pj4gIGRlc3RpbmF0aW9uLg0KPj4+IA0KPj4+ICAxLiAgSWYg dGhlIFNSSCBzcGVjaWZpZXMgdGhlIGNvbXBsZXRlIHBhdGggZnJvbSBzb3VyY2UgdG8NCj4+PiAg ICAgIGRlc3RpbmF0aW9uLCB0aGUgcm91dGVyIHBsYWNlcyB0aGUgU1JIIGRpcmVjdGx5IGluIHRo ZSBkYXRhZ3JhbQ0KPj4+ICAgICAgaXRzZWxmLg0KPj4+IA0KPiANCj4gVGhpcyBvbmUgc291bmRz IHRvIG1lIGxpa2UgaXQgaXMgc2F5aW5nIHJvdXRlcnMgaW5zZXJ0IHRoZSBTUkggaW50byBhbg0K PiBleGlzdGluZyBwYWNrZXQsIGFzIHJvdXRlcnMgZG9uJ3Qgb3JpZ2luYXRlIHBhY2tldHMsIGhv c3RzIGRvIChvciB0aGUNCj4gaG9zdCBjb21wb25lbnQgb2YgYSByb3V0ZXIgaS5lLiwgdGhlIGNv bnRyb2wgcGxhbmUuKS4NCg0KSSB0aGluayB0aGlzIGlzIHRoZSBwb2ludCB0aGF0IE1pY2hhZWwg d2FzIHJldmlld2luZyBpbiBkcmFmdC1yaWNoYXJkc29uLXJvbGwtdXNlb2ZycGxpbmZvLTI0NjBi aXMtMDEsIGxvb2tpbmcgYXQgYSB2YXJpZXR5IG9mIGZsb3cgc2NlbmFyaW9zLCBvbiB0aGUgYXNz dW1wdGlvbiBpdOKAmXMgYWxsIGVuY2FwIHdpdGggbm8gZGlyZWN0IGluc2VydGlvbiwgaS5lLiBo aXMgZHJhZnQgc2F5cyAiVGhpcyBkb2N1bWVudCBhc3N1bWVzIHRoZSBydWxlIHRoYXQgYSBIZWFk ZXIgY2Fubm90IGJlIGluc2VydGVkIG9yIHJlbW92ZWQgb24gdGhlIGZseSBpbnNpZGUgYW4gSVB2 NiBwYWNrZXQgdGhhdCBpcyBiZWluZyByb3V0ZWQu4oCdICANCiANCj4+PiAgMi4gIElmIHRoZSBT Ukggb25seSBzcGVjaWZpZXMgYSBzdWJzZXQgb2YgdGhlIHBhdGggZnJvbSBzb3VyY2UgdG8NCj4+ PiAgICAgIGRlc3RpbmF0aW9uLCB0aGUgcm91dGVyIHVzZXMgSVB2Ni1pbi1JUHY2IHR1bm5lbGlu ZyBbUkZDMjQ3M10gYW5kDQo+Pj4gICAgICBwbGFjZXMgdGhlIFNSSCBpbiB0aGUgb3V0ZXIgSVB2 NiBoZWFkZXIuICBVc2Ugb2YgdHVubmVsaW5nDQo+Pj4gICAgICBlbnN1cmVzIHRoYXQgdGhlIGRh dGFncmFtIGlzIGRlbGl2ZXJlZCB1bm1vZGlmaWVkIGFuZCB0aGF0IElDTVANCj4+PiAgICAgIGVy cm9ycyByZXR1cm4gdG8gdGhlIHNvdXJjZSBvZiB0aGUgU1JIIHJhdGhlciB0aGFuIHRoZSBzb3Vy Y2Ugb2YNCj4+PiAgICAgIHRoZSBvcmlnaW5hbCBkYXRhZ3JhbS7igJ0NCj4+PiANCj4+PiBXaGlj aCBhbHNvIGltcGxpZXMgZW5jYXBzdWxhdGlvbi4NCj4+PiANCj4+PiBTbyB3aG8gaXMgYWN0dWFs bHkgZG9pbmcgZGlyZWN0IEVIIGluc2VydGlvbiBpbnRvIHBhY2tldHMgdG9kYXk/IEFtIEkgbWlz aW50ZXJwcmV0aW5nIHRoZSBhYm92ZSBkb2N1bWVudHMsIG9yIGFyZSB0aGVyZSB1c2UgY2FzZXMg dGhhdCBhcmUgbm90IGJlaW5nIHN0YW5kYXJkaXNlZCBpbiBJRVRGIGRvY3VtZW50cz8NCj4+IA0K Pj4gSW5kZWVkLCB3aGljaCBpcyBsZWF2ZXMgbWUgdW5jb252aW5jZWQgdGhhdCBhbnkgY2hhbmdl cyBhcmUgbmVlZGVkIHdpdGggcmVnYXJkcyB0byB0aGUgcGVyY2VpdmVkIGFtYmlndWl0eS4NCj4+ IEFueSBwcm9wb3NhbCBvZiBoZWFkZXIgaW5qZWN0aW9uIHdvdWxkIGhhdmUgdG8gc3RhbmQgb24g aXRzIG93biBmZWV0Lg0KPj4gDQo+PiBDaGVlcnMsDQo+PiBPbGUNCg0KQmVzdCB3aXNoZXMsDQpU aW0NCg0KPj4gDQo+PiAtLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLQ0KPj4gSUVURiBJUHY2IHdvcmtpbmcgZ3JvdXAgbWFp bGluZyBsaXN0DQo+PiBpcHY2QGlldGYub3JnDQo+PiBBZG1pbmlzdHJhdGl2ZSBSZXF1ZXN0czog aHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9pcHY2DQo+PiAtLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LQ0KPj4gDQo+IA0KDQo= From nobody Tue Jul 26 09:07:48 2016 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2334712D81B for ; Tue, 26 Jul 2016 09:07:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.11 X-Spam-Level: X-Spam-Status: No, score=-4.11 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, T_DKIM_INVALID=0.01] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=fail (1024-bit key) reason="fail (body has been altered)" header.d=jisc365.onmicrosoft.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 IzpmQH60hvm0 for ; Tue, 26 Jul 2016 09:07:44 -0700 (PDT) Received: from eu-smtp-delivery-189.mimecast.com (eu-smtp-delivery-189.mimecast.com [146.101.78.189]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9998B12DB3A for ; Tue, 26 Jul 2016 08:56:24 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=jisc365.onmicrosoft.com; s=selector1-jisc-ac-uk; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=0IMBi2XlvO3Kig94e6b1ldsbqh1t7YeYnleYMB/h+CU=; b=TneDLVsb0KHXdGfLCLxEie1LbOt2xtpdh5RLohigo8WwXaiU3Cw42BYkGZI1THmYM3Y/laBqZWf/U4kiYk6pTHw08KaZqcSNwEfvqacDPBcX0uyrNqp1NRYoRbIlMC5RMXXepdXro/cJ7hZl0Pgdlqbd/tGyf62ceJGnjs8prQE= Received: from EUR03-AM5-obe.outbound.protection.outlook.com (mail-am5eur03lp0116.outbound.protection.outlook.com [213.199.154.116]) (Using TLS) by eu-smtp-1.mimecast.com with ESMTP id uk-mta-59-4L0wvDxWMG2U8yurGqzsqw-1; Tue, 26 Jul 2016 16:56:15 +0100 Received: from AMSPR07MB455.eurprd07.prod.outlook.com (10.242.106.148) by AMSPR07MB454.eurprd07.prod.outlook.com (10.242.106.145) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P384) id 15.1.544.10; Tue, 26 Jul 2016 15:56:13 +0000 Received: from AMSPR07MB455.eurprd07.prod.outlook.com ([10.242.106.148]) by AMSPR07MB455.eurprd07.prod.outlook.com ([10.242.106.148]) with mapi id 15.01.0539.023; Tue, 26 Jul 2016 15:56:13 +0000 From: Tim Chown To: Randy Turner Subject: Re: 2460bis-05 Thread-Topic: 2460bis-05 Thread-Index: AQHR5Emkb9xEnGdNlU2I7ykCszVooqAq5E4A Date: Tue, 26 Jul 2016 15:56:13 +0000 Message-ID: <3A6F8207-249F-4E38-A697-79362A8E82FC@jisc.ac.uk> References: <489138271.16809.1469213275935@webmail.networksolutionsemail.com> In-Reply-To: <489138271.16809.1469213275935@webmail.networksolutionsemail.com> Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-mailer: Apple Mail (2.3124) x-ms-exchange-messagesentrepresentingtype: 1 x-originating-ip: [2001:a88:d510:1101:829:f3ee:fc02:77e0] x-ms-office365-filtering-correlation-id: 7b0c5e65-07eb-4ec5-eef0-08d3b56d5efb x-microsoft-exchange-diagnostics: 1; AMSPR07MB454; 20:swIKkZ3+uP4nRffV6aTJHOkqF6Z63v3hGARySazEHTl/nbEW+UdgCtKZUDkEATGYquw8Pbsb1CiNs1H+WKQg8mIe2DsCYAykISUX40cyezZb47bIsf/fbYeCk2swH/Bt9UKeekTE5wuU7pKyBxy3NthJVTjCc2+Z1agCnaZ6wTg= x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:AMSPR07MB454; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:; x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(601004)(2401047)(8121501046)(5005006)(10201501046)(3002001); SRVR:AMSPR07MB454; BCL:0; PCL:0; RULEID:; SRVR:AMSPR07MB454; x-forefront-prvs: 00159D1518 x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(7916002)(53754006)(189002)(24454002)(199003)(33656002)(68736007)(2900100001)(15975445007)(102836003)(2950100001)(19617315012)(110136002)(16236675004)(83716003)(74482002)(87936001)(105586002)(6116002)(3660700001)(11100500001)(586003)(86362001)(5002640100001)(3280700002)(36756003)(10400500002)(122556002)(81166006)(81156014)(57306001)(8936002)(50986999)(50226002)(19580405001)(101416001)(19580395003)(82746002)(7846002)(4326007)(77096005)(8676002)(106116001)(7906003)(92566002)(106356001)(76176999)(7736002)(97736004)(2906002)(189998001)(3826002)(104396002); DIR:OUT; SFP:1101; SCL:1; SRVR:AMSPR07MB454; H:AMSPR07MB455.eurprd07.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; MX:1; A:1; LANG:en; spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM MIME-Version: 1.0 X-OriginatorOrg: jisc.ac.uk X-MS-Exchange-CrossTenant-originalarrivaltime: 26 Jul 2016 15:56:13.6611 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 48f9394d-8a14-4d27-82a6-f35f12361205 X-MS-Exchange-Transport-CrossTenantHeadersStamped: AMSPR07MB454 X-MC-Unique: 4L0wvDxWMG2U8yurGqzsqw-1 Content-Type: multipart/alternative; boundary="_000_3A6F8207249F4E38A69779362A8E82FCjiscacuk_" Archived-At: Cc: "ipv6@ietf.org" X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.17 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 Jul 2016 16:07:46 -0000 --_000_3A6F8207249F4E38A69779362A8E82FCjiscacuk_ Content-Type: text/plain; charset=WINDOWS-1252 Content-Transfer-Encoding: quoted-printable On 22 Jul 2016, at 19:47, Randy Turner > wrote: Hi All, In section 4 of 2460bis-05, there is a description of what a "full" impleme= ntation would consist of...can someone elaborate on the definition of "full= " ? Is this a conformance thing Well, RFC2460 forms part of various conformance and interoperability tests,= e.g. see https://www.iol.unh.edu/testing/ip/ipv6/test-suites, so the core = conformance test suite there tests against a handful of RFCs (i.e. RFC2460,= RFC4861, RFC4862, RFC4443, RFC5095 and RFC1981), so would only include the= EHs defined in RFC2460, less RH0 which was deprecated with RFC5095. If you=92re interested in what capabilities a generic IPv6 node should have= , then RFC6434 is a place to look (and an update to that is underway). Tim --_000_3A6F8207249F4E38A69779362A8E82FCjiscacuk_ Content-Type: text/html; charset=WINDOWS-1252 Content-ID: Content-Transfer-Encoding: quoted-printable
On 22 Jul 2016, at 19:47, Randy Turner <rturner@amalfisystems.com> w= rote:

Hi All,

In section 4 of 2460bis-05, there is a description of what a = "full" implementation would consist of...can someone elaborate on= the definition of "full" ?  Is this a conformance thing

Well, RFC2460 forms part of various conformance and interoperability tests,= e.g. see https://www.iol.unh.edu/testing/ip/ipv6/test-suites, so = the core conformance test suite there tests against a handful of RFCs (i.e. RFC2460, RFC= 4861, RFC4862, RFC4443, RFC5095 and RFC1981), so would only include = the EHs defined in RFC2460, less RH0 which was deprecated with RFC5095.

If you=92re interested in what capabilities a generic IPv6 node should= have, then RFC6434 is a place to look (and an update to that is underway).=

Tim

--_000_3A6F8207249F4E38A69779362A8E82FCjiscacuk_-- From nobody Tue Jul 26 09:28:42 2016 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5A7B812D125 for ; Tue, 26 Jul 2016 09:28:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.619 X-Spam-Level: X-Spam-Status: No, score=-2.619 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01] 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 Uvw4N5qW2tQQ for ; Tue, 26 Jul 2016 09:28:36 -0700 (PDT) Received: from atl4mhob06.myregisteredsite.com (atl4mhob06.myregisteredsite.com [209.17.115.44]) by ietfa.amsl.com (Postfix) with ESMTP id DBD0912B00F for ; Tue, 26 Jul 2016 09:28:35 -0700 (PDT) Received: from mailpod.hostingplatform.com ([10.30.71.208]) by atl4mhob06.myregisteredsite.com (8.14.4/8.14.4) with ESMTP id u6QGSXPj004632 for ; Tue, 26 Jul 2016 12:28:33 -0400 Received: (qmail 23593 invoked by uid 0); 26 Jul 2016 16:28:33 -0000 X-TCPREMOTEIP: 73.207.234.73 X-Authenticated-UID: rturner@amalfisystems.com Received: from unknown (HELO ?10.0.1.25?) (rturner@amalfisystems.com@73.207.234.73) by 0 with ESMTPA; 26 Jul 2016 16:28:33 -0000 Content-Type: multipart/alternative; boundary="Apple-Mail=_F5591F40-4758-4DAA-8D79-E559D4883D20" Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) Subject: Re: 2460bis-05 From: Randy Turner In-Reply-To: <3A6F8207-249F-4E38-A697-79362A8E82FC@jisc.ac.uk> Date: Tue, 26 Jul 2016 12:28:32 -0400 Message-Id: <0A9918AB-E46B-4AAF-A1F2-D3FE3F671F5B@amalfisystems.com> References: <489138271.16809.1469213275935@webmail.networksolutionsemail.com> <3A6F8207-249F-4E38-A697-79362A8E82FC@jisc.ac.uk> To: Tim Chown X-Mailer: Apple Mail (2.3124) Archived-At: Cc: "ipv6@ietf.org" X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.17 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 Jul 2016 16:28:41 -0000 --Apple-Mail=_F5591F40-4758-4DAA-8D79-E559D4883D20 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 Hi, I wasn=92t asking about what the RFC was about, I was asking about the = definition of =93full=94, and whether or not there might be a better = term for what is implied in section 4 of 2460bis=20 R. > On Jul 26, 2016, at 11:56 AM, Tim Chown wrote: >=20 >> On 22 Jul 2016, at 19:47, Randy Turner > wrote: >> Hi All, >>=20 >> In section 4 of 2460bis-05, there is a description of what a "full" = implementation would consist of...can someone elaborate on the = definition of "full" ? Is this a conformance thing >>=20 > Well, RFC2460 forms part of various conformance and interoperability = tests, e.g. see https://www.iol.unh.edu/testing/ip/ipv6/test-suites = , so the core = conformance test suite there tests against a handful of RFCs (i.e. = RFC2460, RFC4861, RFC4862, RFC4443, RFC5095 and RFC1981), so would only = include the EHs defined in RFC2460, less RH0 which was deprecated with = RFC5095. >=20 > If you=92re interested in what capabilities a generic IPv6 node should = have, then RFC6434 is a place to look (and an update to that is = underway). >=20 > Tim >=20 --Apple-Mail=_F5591F40-4758-4DAA-8D79-E559D4883D20 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=windows-1252 Hi,

I = wasn=92t asking about what the RFC was about, I was asking about the = definition of =93full=94, and whether or not there might be a better = term for what is implied in section 4 of 2460bis 

R.

On Jul 26, 2016, at 11:56 AM, Tim Chown <Tim.Chown@jisc.ac.uk> wrote:

On 22 Jul 2016, at 19:47, Randy Turner <rturner@amalfisystems.com> wrote:

Hi All,

In section 4 of = 2460bis-05, there is a description of what a "full" implementation would = consist of...can someone elaborate on the definition of "full" ? =  Is this a conformance thing

Well, RFC2460 forms part of various conformance and interoperability = tests, e.g. see https://www.iol.unh.edu/testing/ip/ipv6/test-suites, so = the core conformance test suite there tests against a handful of RFCs (i.e. RFC2460,= RFC4861, RFC4862, RFC4443, RFC5095 and RFC1981), so would only = include the EHs defined in RFC2460, less RH0 which was deprecated with RFC5095.

If you=92re interested in what capabilities a generic = IPv6 node should have, then RFC6434 is a place to look (and an update to = that is underway).

Tim


= --Apple-Mail=_F5591F40-4758-4DAA-8D79-E559D4883D20-- From nobody Tue Jul 26 10:17:07 2016 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4315C12D836 for ; Tue, 26 Jul 2016 10:17:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.11 X-Spam-Level: X-Spam-Status: No, score=-4.11 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, T_DKIM_INVALID=0.01] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=fail (1024-bit key) reason="fail (body has been altered)" header.d=jisc365.onmicrosoft.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 5gUXCE4VL21Z for ; Tue, 26 Jul 2016 10:17:03 -0700 (PDT) Received: from eu-smtp-delivery-189.mimecast.com (eu-smtp-delivery-189.mimecast.com [146.101.78.189]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 143CB12D830 for ; Tue, 26 Jul 2016 10:17:02 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=jisc365.onmicrosoft.com; s=selector1-jisc-ac-uk; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=NBkG1d4lNKIfWd78bPfuCmnK2n/sQayfGbmwkkIjKLg=; b=mTOVimXdAIpz2RXIcXctS7fpvjb7yg3CnBmx0TluBDcylnPMptKlwpScesFZPnTNvnqIv/6Hl49L7feMFRLfXk7FZDAVBrtIVme5dlQbjpTpl711D/ehiuB2gGAf9rDm1KgmpLzBYHcMaU13fdopFJmovrjbI7v+eoFLC4YWyAY= Received: from EUR01-DB5-obe.outbound.protection.outlook.com (mail-db5eur01lp0182.outbound.protection.outlook.com [213.199.154.182]) (Using TLS) by eu-smtp-1.mimecast.com with ESMTP id uk-mta-19-kbfwZoOvOaaJTLP4kF6Jlw-1; Tue, 26 Jul 2016 18:16:57 +0100 Received: from AMSPR07MB455.eurprd07.prod.outlook.com (10.242.106.148) by AMSPR07MB456.eurprd07.prod.outlook.com (10.242.106.149) with Microsoft SMTP Server (TLS) id 15.1.534.14; Tue, 26 Jul 2016 17:16:55 +0000 Received: from AMSPR07MB455.eurprd07.prod.outlook.com ([10.242.106.148]) by AMSPR07MB455.eurprd07.prod.outlook.com ([10.242.106.148]) with mapi id 15.01.0539.023; Tue, 26 Jul 2016 17:16:56 +0000 From: Tim Chown To: Randy Turner Subject: Re: 2460bis-05 Thread-Topic: 2460bis-05 Thread-Index: AQHR5Emkb9xEnGdNlU2I7ykCszVooqAq5E4AgAAIngCAAA3wgA== Date: Tue, 26 Jul 2016 17:16:55 +0000 Message-ID: <9DE6D3F8-2DA8-483B-BF74-9C348BE80931@jisc.ac.uk> References: <489138271.16809.1469213275935@webmail.networksolutionsemail.com> <3A6F8207-249F-4E38-A697-79362A8E82FC@jisc.ac.uk> <0A9918AB-E46B-4AAF-A1F2-D3FE3F671F5B@amalfisystems.com> In-Reply-To: <0A9918AB-E46B-4AAF-A1F2-D3FE3F671F5B@amalfisystems.com> Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-mailer: Apple Mail (2.3124) x-ms-exchange-messagesentrepresentingtype: 1 x-originating-ip: [212.188.254.49] x-ms-office365-filtering-correlation-id: 08c5b75b-a559-4cdd-2398-08d3b578a521 x-microsoft-exchange-diagnostics: 1; AMSPR07MB456; 20:gjFECyLVCpVEiWg7QyJo4Izxw52GWtN9PBDBS++M8rWIFs5W4tZo4T6nh7BS06TdVu6TLulmUv2lLrowCENKx1V0TvjJUOn6iUgV/A1CnOpdt54+tjFRHjLUZ5cuJBiXKu+9RAp7LsPhpOZBiq1pZNFL35pTtXRrnRCjc6b+XIg= x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:AMSPR07MB456; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(274715658323672); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(601004)(2401047)(5005006)(8121501046)(3002001)(10201501046); SRVR:AMSPR07MB456; BCL:0; PCL:0; RULEID:; SRVR:AMSPR07MB456; x-forefront-prvs: 00159D1518 x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(7916002)(24454002)(53754006)(189002)(199003)(377454003)(77096005)(10400500002)(2900100001)(101416001)(110136002)(19617315012)(57306001)(66066001)(189998001)(3280700002)(68736007)(33656002)(3660700001)(74482002)(92566002)(87936001)(36756003)(15975445007)(86362001)(5002640100001)(97736004)(105586002)(106116001)(106356001)(122556002)(76176999)(8676002)(16236675004)(81156014)(2906002)(50986999)(2950100001)(4326007)(6116002)(3846002)(102836003)(7846002)(50226002)(82746002)(7906003)(19580405001)(586003)(83716003)(19580395003)(7736002)(8936002)(81166006)(104396002); DIR:OUT; SFP:1101; SCL:1; SRVR:AMSPR07MB456; H:AMSPR07MB455.eurprd07.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; MX:1; A:1; LANG:en; spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM MIME-Version: 1.0 X-OriginatorOrg: jisc.ac.uk X-MS-Exchange-CrossTenant-originalarrivaltime: 26 Jul 2016 17:16:55.9226 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 48f9394d-8a14-4d27-82a6-f35f12361205 X-MS-Exchange-Transport-CrossTenantHeadersStamped: AMSPR07MB456 X-MC-Unique: kbfwZoOvOaaJTLP4kF6Jlw-1 Content-Type: multipart/alternative; boundary="_000_9DE6D3F82DA8483BBF749C348BE80931jiscacuk_" Archived-At: Cc: "ipv6@ietf.org" X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.17 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 Jul 2016 17:17:06 -0000 --_000_9DE6D3F82DA8483BBF749C348BE80931jiscacuk_ Content-Type: text/plain; charset=WINDOWS-1252 Content-Transfer-Encoding: quoted-printable On 26 Jul 2016, at 17:28, Randy Turner > wrote: Hi, I wasn=92t asking about what the RFC was about, I was asking about the defi= nition of =93full=94, and whether or not there might be a better term for w= hat is implied in section 4 of 2460bis I don=92t believe =93full implementation=94 is defined anywhere. And of cou= rse 18 years have since passed and (for example) the requirement on AH/ESP = support was relaxed some time ago. So you could suggest an alternative. UNH= -IOH refer to 2460 as their IPv6 core requirement test, but =93core impleme= ntation=94 doesn=92t sound quite right. I suspect there may not be much ap= petite to change it. Tim R. On Jul 26, 2016, at 11:56 AM, Tim Chown > wrote: On 22 Jul 2016, at 19:47, Randy Turner > wrote: Hi All, In section 4 of 2460bis-05, there is a description of what a "full" impleme= ntation would consist of...can someone elaborate on the definition of "full= " ? Is this a conformance thing Well, RFC2460 forms part of various conformance and interoperability tests,= e.g. see https://www.iol.unh.edu/testing/ip/ipv6/test-suites, so the core = conformance test suite there tests against a handful of RFCs (i.e. RFC2460,= RFC4861, RFC4862, RFC4443, RFC5095 and RFC1981), so would only include the= EHs defined in RFC2460, less RH0 which was deprecated with RFC5095. If you=92re interested in what capabilities a generic IPv6 node should have= , then RFC6434 is a place to look (and an update to that is underway). Tim --_000_9DE6D3F82DA8483BBF749C348BE80931jiscacuk_ Content-Type: text/html; charset=WINDOWS-1252 Content-ID: <89504AEBFF1F544FB93FA05A95E878D5@eurprd07.prod.outlook.com> Content-Transfer-Encoding: quoted-printable
On 26 Jul 2016, at 17:28, Randy Turner <rturner@amalfisystems.com> w= rote:

Hi,

I wasn=92t asking about what the RFC was about, I was askin= g about the definition of =93full=94, and whether or not there might be a b= etter term for what is implied in section 4 of 2460bis 

I don=92t believe =93full implementation=94 is defined anywhere. And of cou= rse 18 years have since passed and (for example) the requirement on AH/ESP = support was relaxed some time ago. So you could suggest an alternative. UNH= -IOH refer to 2460 as their IPv6 core requirement test, but =93core implementation=94 doesn=92t sound quite righ= t.  I suspect there may not be much appetite to change it.

Tim

R.

On Jul 26, 2016, at 11:56 AM, Tim Chown <Tim.Chown@jisc.ac.uk> wrote:
On 22 Jul 2016, at 19:47, Randy Turner <rturner@amalfisystems.com> w= rote:

Hi All,

In section 4 of 2460bis-05, there is a description of what a = "full" implementation would consist of...can someone elaborate on= the definition of "full" ?  Is this a conformance thing

Well, RFC2460 forms part of various conformance and interoperability tests,= e.g. see https://www.iol.unh.edu/testing/ip/ipv6/test-suites, so = the core conformance test suite there tests against a handful of RFCs (i.e. RFC2460, RFC= 4861, RFC4862, RFC4443, RFC5095 and RFC1981), so would only include = the EHs defined in RFC2460, less RH0 which was deprecated with RFC5095.

If you=92re interested in what capabilities a generic IPv6 = node should have, then RFC6434 is a place to look (and an update to that is= underway).

Tim



--_000_9DE6D3F82DA8483BBF749C348BE80931jiscacuk_-- From nobody Tue Jul 26 11:51:17 2016 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 845F912D8D4 for ; Tue, 26 Jul 2016 11:51:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.188 X-Spam-Level: X-Spam-Status: No, score=-3.188 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-1.287, SPF_PASS=-0.001] 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 NEP71V_h78cX for ; Tue, 26 Jul 2016 11:51:13 -0700 (PDT) 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 BBDBA12D59E for <6man@ietf.org>; Tue, 26 Jul 2016 11:51:13 -0700 (PDT) Received: from sandelman.ca (obiwan.sandelman.ca [IPv6:2607:f0b0:f:2::247]) by tuna.sandelman.ca (Postfix) with ESMTP id 29132203C3; Tue, 26 Jul 2016 15:01:04 -0400 (EDT) Received: from obiwan.sandelman.ca (localhost [IPv6:::1]) by sandelman.ca (Postfix) with ESMTP id 165C7638BE; Tue, 26 Jul 2016 14:51:12 -0400 (EDT) From: Michael Richardson To: Mark Smith Subject: Re: proposed text for header injection revision 05 In-Reply-To: References: <26582.1468923195@obiwan.sandelman.ca> <2EBFA6F2-00A3-45E1-BE0E-3531AF75726A@employees.org> <787AE7BB302AE849A7480A190F8B933008DE9E22@OPEXCLILMA3.corporate.adroot.infra.ftgroup> <0445fd4c-3d96-73f5-035e-570f165faf9b@gmail.com> <614711c4-9e69-3ddc-67f2-0d20394169ad@si6networks.com> <3edee5c1-3444-bc7d-31e5-1bb29810e857@si6networks.com> <1967.1469274288@obiwan.sandelman.ca> <9999.1469475724@obiwan.sandelman.ca> X-Mailer: MH-E 8.6; nmh 1.6+dev; GNU Emacs 24.5.1 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@ietf.org" <6man@ietf.org>, =?us-ascii?Q?=3D=3FUTF-8=3FB=3F56We5piO6YGU5ZOJ=3F=3D?= X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.17 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 Jul 2016 18:51:15 -0000 --=-=-= Content-Type: text/plain Mark Smith wrote: > In the inside to outside direction, when the NAT modifies the packet > it changes the source address of the packet to its own outside > address. So it is really re-originating the packet after it has made > its modifications, because it is stating it is the source of those > changes. You mean, the NAT *REMOVED* the IP header, and inserted it's own. It happened to have the same dst IP in the typical N:1 NAPT situation. Some NAT44s also mess with the TCP options, and one is known to rewrite the TCP sequence numbers, which makes it closer in many ways to a transparent application layer gateway. It didn't leave the original IP header in place as an IPIP header. That's really important. > Inserting EHs has none of these attributes or indicators of whether or > not and where the EH might have been inserted in the network, as the > packet's source address will never be updated when the EH is added, > and there is no EH insertion boundary that can be as easily deduced > from the type of address being used in either the source or > destination address in the packet. The analogy is really to say that we failed to provide a way to detect/discover the NAT, and negotiate with it in order to discover what things it would do for us, or to us. If we are going to permit anything in the middle to look at anything other than dst, flowlabel and DSCP, (or to modify anything), then let's not repeat the failure we had in v4 in IPv6. (Back in 1996, I had designed an authenticated ICMP mechanism to permit IPsec to traverse firewalls, doing end-to-end AH with hop-by-hop ESP so that authorized firewalls could perform their audit function. People thought I had six heads...) -- Michael Richardson , Sandelman Software Works -= IPv6 IoT consulting =- --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 iQEVAwUBV5exHYCLcPvd0N1lAQJqqgf+MFkdldAu5K07LAsxDwviA+muipqq5nJN SFJ8yAYa2yaUiHkTZsRVFVmD2BA5099kL7Q3HOfUt+lCrbJeivwfK2q0Bb96tDx5 bbZqbOjHwjmgv7qN0oCcJBm673ayOkQvj+Vf3bwgOtatIi0ve6k17HKdzh8zqmq7 MIdhontm+3K1mmksTVCU8Dby+7/xw+aZC4+RTSyPDqKt091s0+RKmzQqNWNRVddA WruT44/qWZIxhiJZnDwtx5nAnckvhXiz3/rnf+H2jJyi87eHMwpkHZdiRlbCcifF 2+Aj9rF0W/7YvLFt/JaWYb3W/7WAWrFqg4JBI58Nwkg7yoZct78kGQ== =ePra -----END PGP SIGNATURE----- --=-=-=-- From nobody Tue Jul 26 13:17:14 2016 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 855E012D942 for ; Tue, 26 Jul 2016 13:17:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.92 X-Spam-Level: X-Spam-Status: No, score=-1.92 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01] 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 QupJUSmoIuoe for ; Tue, 26 Jul 2016 13:17:12 -0700 (PDT) Received: from serval.cherry.relay.mailchannels.net (serval.cherry.relay.mailchannels.net [23.83.223.163]) (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 DEC5712D941 for ; Tue, 26 Jul 2016 13:17:08 -0700 (PDT) X-Sender-Id: totalchoicehosting|x-authuser|slblake@petri-meat.com Received: from relay.mailchannels.net (localhost [127.0.0.1]) by relay.mailchannels.net (Postfix) with ESMTP id 59E5FE0EE7; Tue, 26 Jul 2016 20:17:03 +0000 (UTC) Received: from elom.tchmachines.com (ip-10-120-4-226.us-west-2.compute.internal [10.120.4.226]) by relay.mailchannels.net (Postfix) with ESMTPA id 701EEE076F; Tue, 26 Jul 2016 20:17:02 +0000 (UTC) X-Sender-Id: totalchoicehosting|x-authuser|slblake@petri-meat.com Received: from elom.tchmachines.com ([TEMPUNAVAIL]. [10.92.147.53]) (using TLSv1 with cipher DHE-RSA-AES256-SHA) by 0.0.0.0:2500 (trex/5.7.3); Tue, 26 Jul 2016 20:17:03 +0000 X-MC-Relay: Neutral X-MailChannels-SenderId: totalchoicehosting|x-authuser|slblake@petri-meat.com X-MailChannels-Auth-Id: totalchoicehosting X-MC-Loop-Signature: 1469564222705:1720045575 X-MC-Ingress-Time: 1469564222704 Received: from [127.0.0.1] (port=59808 helo=elom.tchmachines.com) by elom.tchmachines.com with esmtpa (Exim 4.87) (envelope-from ) id 1bS8mb-0007p5-Bd; Tue, 26 Jul 2016 16:16:53 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8; format=flowed Date: Tue, 26 Jul 2016 16:16:53 -0400 From: Steven Blake To: Tim Chown Subject: Re: Which use cases are using direct EH insertion? In-Reply-To: References: <201607220911.u6M9Bco9077775@givry.fdupont.fr> <948512bb-c741-0509-8442-2d230c5bca49@gmail.com> <18213e8b-117a-a443-36fd-df96d56e14de@gmail.com> Message-ID: <9dac3b40eb2e6fcf339da6fa1a44f9ad@petri-meat.com> X-Sender: slblake@petri-meat.com User-Agent: Roundcube Webmail/1.1.4 X-AuthUser: slblake@petri-meat.com Content-Transfer-Encoding: quoted-printable Archived-At: Cc: 6man WG X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.17 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 Jul 2016 20:17:13 -0000 On 2016-07-26 06:30, Tim Chown wrote: > Hi, >=20 > I=E2=80=99m still not clear as to where in any current IETF RFC/I-D the= re is > text stating that a new EH should be inserted into an existing packet > traversing a path, rather than encapsulated. [snip] > So who is actually doing direct EH insertion into packets today? Am I > misinterpreting the above documents, or are there use cases that are > not being standardised in IETF documents? >=20 > Tim If I am reading it correctly, draft-brockners-inband-oam-transport-00=20 "Encapsulations for In-band OAM Data" inserts a Hop-by-Hop extension=20 header with OAM options at the ingress router of an administrative=20 domain, and strips it at the egress router (Sec. 3). I think that=20 Comcast showed a demo of this protocol at Bits-n-Bites (but that demo=20 may have used GUE encapsulation edge-to-edge; I don't recall exactly). Regards, // Steve From nobody Tue Jul 26 13:57:45 2016 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7B54512D967 for ; Tue, 26 Jul 2016 13:57:40 -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 5BywGeJOJimW for ; Tue, 26 Jul 2016 13:57:38 -0700 (PDT) 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 02E3712D961 for ; Tue, 26 Jul 2016 13:57:38 -0700 (PDT) Received: by mail-pf0-x22a.google.com with SMTP id y134so3211238pfg.0 for ; Tue, 26 Jul 2016 13:57:37 -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=JSXMZnPImD4JkxJW6kzTeJRPKO56O0Zrc2DtY8lT91I=; b=UwKIPa1Hy/58PzSOdLfa9+GJpgur1vPmuPIL7s+/UN9RzgO7fiJ4yzNpPGbW4J08Hx v5JYdfqdOyqBylPHCoIwUsrCry3431fNH4YX+zrgeHkC2MCJU8rJbFubD5vTCVfxROjP Qtrw3Y7Kj3BxJgP6Y+dqjj7Zb1/RNVLUOxchoDhKmEn8hDZ8Re7Ffj7x92EtlZl2RZcS I6ShvhvJrZRAuS1UUywOHMNJJbFJUukLNW5pdbyUxGYEAC0JgEw3/juJs4xWDxMxLVOf db6oiyBPgWNeVPM9nViFcrHZvoxIUOGhzI7qrqn1HPWYuMc3/LC7OTPgjbz1fWiZnd7c zVNQ== 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=JSXMZnPImD4JkxJW6kzTeJRPKO56O0Zrc2DtY8lT91I=; b=Ki11ZCRn/XYJyip7hFfXf90A7JRritbGTuSStJ4EG8/DVtqmvSoetCO6dOQbl0gtoR 74xP+vmqTSXHaGi1kS31wOtEqnDUsurmHM6Z4ouK7joykbmQH0O1Tc1L3Y47TfDFgp6k NuqCZtDSpkUSqO+dWBg36HMlMZVAFmelgobfTG9WtzfwSI644S06OYkxDWo2XpXCA+Xp 9oLmU5OVkpwaLM23UFakzaVEeM04QYFbr+EaY/XscA+lcnozX2DzJe7mbGfomodQLY2a M6WgjvRK+gGq2NmO3E10Z0oqoJ6U75t0atZvf+RFEHVXnnoLBvrFfhjzTyihEcSAYlfu Y6Yw== X-Gm-Message-State: AEkooushiUkhnHEk6OQmPG6QLJVjyk0fR0iWuHdVQJoJpWdAu27meb5xdIjunrXGHzcfEg== X-Received: by 10.98.149.22 with SMTP id p22mr42932517pfd.88.1469566657342; Tue, 26 Jul 2016 13:57:37 -0700 (PDT) Received: from ?IPv6:2406:e007:4fd5:1:28cc:dc4c:9703:6781? ([2406:e007:4fd5:1:28cc:dc4c:9703:6781]) by smtp.gmail.com with ESMTPSA id x9sm3558950pfk.79.2016.07.26.13.57.34 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 26 Jul 2016 13:57:36 -0700 (PDT) Subject: Re: 2460bis-05 To: Tim Chown , Randy Turner References: <489138271.16809.1469213275935@webmail.networksolutionsemail.com> <3A6F8207-249F-4E38-A697-79362A8E82FC@jisc.ac.uk> <0A9918AB-E46B-4AAF-A1F2-D3FE3F671F5B@amalfisystems.com> <9DE6D3F8-2DA8-483B-BF74-9C348BE80931@jisc.ac.uk> From: Brian E Carpenter Organization: University of Auckland Message-ID: <18512b21-4414-70c9-a1c8-f46e135420d0@gmail.com> Date: Wed, 27 Jul 2016 08:57:37 +1200 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.2.0 MIME-Version: 1.0 In-Reply-To: <9DE6D3F8-2DA8-483B-BF74-9C348BE80931@jisc.ac.uk> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Archived-At: Cc: "ipv6@ietf.org" X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.17 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 Jul 2016 20:57:40 -0000 On 27/07/2016 05:16, Tim Chown wrote: > On 26 Jul 2016, at 17:28, Randy Turner > wrote: >=20 > Hi, >=20 > I wasn=E2=80=99t asking about what the RFC was about, I was asking abou= t the definition of =E2=80=9Cfull=E2=80=9D, and whether or not there migh= t be a better term for what is implied in section 4 of 2460bis >=20 > I don=E2=80=99t believe =E2=80=9Cfull implementation=E2=80=9D is define= d anywhere. And of course 18 years have since passed and (for example) th= e requirement on AH/ESP support was relaxed some time ago. So you could s= uggest an alternative. UNH-IOH refer to 2460 as their IPv6 core requireme= nt test, but =E2=80=9Ccore implementation=E2=80=9D doesn=E2=80=99t sound = quite right. I suspect there may not be much appetite to change it. Something seems to tell me that "full implementation" was intended to sug= gest that a low-end device could treat those headers (and in particular fragme= ntation) as optional. But then it couldn't communicate with the world at large. In any case it's a bit vague, and I think Randy has raised a good questio= n. The current status of AH means that we need to change this text anyway. S= omething like: A normal implementation of IPv6 supports the following extension heade= rs: Hop-by-Hop Options Fragment Destination Options Encapsulating Security Payload Regards Brian >=20 > Tim >=20 > R. >=20 > On Jul 26, 2016, at 11:56 AM, Tim Chown > wrote: >=20 > On 22 Jul 2016, at 19:47, Randy Turner > wrote: >=20 > Hi All, >=20 > In section 4 of 2460bis-05, there is a description of what a "full" imp= lementation would consist of...can someone elaborate on the definition of= "full" ? Is this a conformance thing >=20 > Well, RFC2460 forms part of various conformance and interoperability te= sts, e.g. see https://www.iol.unh.edu/testing/ip/ipv6/test-suites, so the= core conformance test suite there tests against a handful of RFCs (i.e. = RFC2460, RFC4861, RFC4862, RFC4443, RFC5095 and RFC1981), so would only i= nclude the EHs defined in RFC2460, less RH0 which was deprecated with RFC= 5095. >=20 > If you=E2=80=99re interested in what capabilities a generic IPv6 node s= hould have, then RFC6434 is a place to look (and an update to that is und= erway). >=20 > Tim >=20 >=20 >=20 >=20 >=20 >=20 > -------------------------------------------------------------------- > IETF IPv6 working group mailing list > ipv6@ietf.org > Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 > -------------------------------------------------------------------- >=20 From nobody Tue Jul 26 14:32:08 2016 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8832F12D9A9 for ; Tue, 26 Jul 2016 14:32:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FREEMAIL_FORGED_FROMDOMAIN=0.001, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=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 2WCE-POFw1pT for ; Tue, 26 Jul 2016 14:32:05 -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 C199D12D9A5 for <6man@ietf.org>; Tue, 26 Jul 2016 14:32:04 -0700 (PDT) Received: by mail-qk0-x235.google.com with SMTP id p74so18407135qka.0 for <6man@ietf.org>; Tue, 26 Jul 2016 14:32:04 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to:cc; bh=bRlQFoLinGZKZpsf+8Bsw6Chp5qFuAyjNjwECrv/J18=; b=zYemPkPfcevIynoMqVMBpjuSHGDIak/ncqeuxCYDmNjXee+nNLCVQ2o5N9vGhSf3pP XSydJ3/CbPw1rfMRKpmSNJQc4N9WI9345V+xj86l9fYPkvk1jW2h0VgjEhiElnPZSVkB iZV3CtzCcgMAZvz2VQCvCXm7oSz040gc20bbLKkFcx/lpYaBX9kzKhSN19CBvsCGQNST Jhz8ooqKURdM4QxeYXeqO1RhL0hmA2ysQOq8oj0S0d0Sa3qWod7c8m0gorYaRvKaRTCn 4H675TJYRsWqRnLtbE02upN4j9vj5pzds4/B7rRIZJ30MX7L3z4honiLitDnHxcyVBP8 cfxA== 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:from :date:message-id:subject:to:cc; bh=bRlQFoLinGZKZpsf+8Bsw6Chp5qFuAyjNjwECrv/J18=; b=J3jb8btk0ryzenA1Jkfob3shO8EiCYrYp8srX9qIvsIqxjHhsYJZrk/SwNf+nKrdpP z0Lh0KcpMkZX5vKuR1jpbiarbKgeL4IAWjYzeH2UM3EwFSXr8SFAq4kn+fDPi70nTMhK qh8AcY+AmtylZRt6brRTuNEqXofqdxyZG2DvVLsa0oeTNM8Dr3q96n+HYAAHLQQyWCQy uOJScFaVOFUKMfLVp8ClHoT1lff61TJVzP0JC2sUnhQUXP50p/skqO3r37/jeSGjUeZh GekSHFKJN3HfXsXCZ8/9JhC+FSyNioZQLvCmlzgdSxO5SeRw4Okj9H2pw18onuVQh/Ha cN+Q== X-Gm-Message-State: AEkoouvIrPMENJGz6qhrOM/rLpcJxqch4zBb103pe0pvRr6W1qDhWz4h6o4UBE0parLIUdgFWRdOWVeScpOmnA== X-Received: by 10.55.162.1 with SMTP id l1mr30685803qke.176.1469568723944; Tue, 26 Jul 2016 14:32:03 -0700 (PDT) MIME-Version: 1.0 Sender: jinmei.tatuya@gmail.com Received: by 10.237.33.154 with HTTP; Tue, 26 Jul 2016 14:32:03 -0700 (PDT) In-Reply-To: <20160722053522.E90564F26BC8@rock.dv.isc.org> References: <20160722053522.E90564F26BC8@rock.dv.isc.org> From: =?UTF-8?B?56We5piO6YGU5ZOJ?= Date: Tue, 26 Jul 2016 14:32:03 -0700 X-Google-Sender-Auth: 1YvLjt639BCRgWJgzqI5TCRE9_I Message-ID: Subject: Re: IPV6_USE_MIN_MTU and TCP To: Mark Andrews Content-Type: text/plain; charset=UTF-8 Archived-At: Cc: "6man@ietf.org" <6man@ietf.org> X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.17 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 Jul 2016 21:32:06 -0000 At Fri, 22 Jul 2016 15:35:22 +1000, Mark Andrews wrote: > What does this list believe the advertised MSS should be on a TCP > connection if IPV6_USE_MIN_MTU=1 has been set on a socket? > > What does this list believe the transmitted TCP segment size should > be on a TCP connection if IPV6_USE_MIN_MTU=1 has been set on a > socket? I don't have a strong opinion, but for the latter it would be natural to set it to 1280- so the outgoing TCP packets sent from the socket won't be fragmented. For the former, I'm not sure - essentially IPV6_USE_MIN_MTU is to avoid path MTU discovery, and PMTUD is a one-way protocol. In that sense it might be awkward if a node that doesn't perform PMTUD tries to specify something about it. In any case, I guess we implicitly ignored the use of the option for TCP when we discussed the API spec that resulted in RFC3542. The RFC states: Unicast applications should usually let the kernel perform path MTU discovery [RFC-1981], as long as the kernel supports it, and should not care about the path MTU. Some applications, however, might not want to incur the overhead of path MTU discovery, especially if the applications only send a single datagram to a destination. A potential example is a DNS server. I don't remember all details of the discussion at that time, but I guess an unstated assumption here is that for TCP application this "overhead" would usually be acceptable. This is not to say we shouldn't clarify the use of it for TCP today, though. More recent operational observations, most notably a view that "PMTUD is dead", may require a revisit of this point. -- JINMEI, Tatuya From nobody Tue Jul 26 16:39:12 2016 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 530A512D1B2 for ; Tue, 26 Jul 2016 16:39:10 -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 fCykAOEjm_Ml for ; Tue, 26 Jul 2016 16:39:09 -0700 (PDT) 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 EB4C312D1A6 for ; Tue, 26 Jul 2016 16:39:08 -0700 (PDT) Received: by mail-io0-x236.google.com with SMTP id q83so50740445iod.1 for ; Tue, 26 Jul 2016 16:39:08 -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=JwBirELaxw5H4J4KWNLD47UpPFKufxYrv1lixcktyN0=; b=VejZJRvnoHvkkVvOqTuo4iERHGg3HsvLmZwn8eeHYr8qHJx8/2YZUua+l2nSvMNXjk wfYzApugG0AiCQIdI6OcZZYI1fSdYazJj6dM+CA0YRYLYBX/uxLhiB0b0/mySDy5STI+ Rf5IzR2LkZ0P3DA3Mem6veRp7D+5OYU1DzUeEd+ARrTO1hv/sbjXsNSLWCR5QEfiC/2O bwt1KEzNnbv3a/JQC+0iJQm72trUTF8506ghc1SLeNN0sOiRFdFAiSw6B+OEroLwxlbW +eqprSuj/1LqGXOjY25Tynu83KR2m+dQ3r3I9nG6f8UKWxe9WoWMswkf20ENH5tVE60R LV1A== 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=JwBirELaxw5H4J4KWNLD47UpPFKufxYrv1lixcktyN0=; b=VZ/QGVNQC8hn2L44vKFCCLctDonCV+7ZfMtGZcow3Uc2njk7XrO1+4KaSvf7h65fo3 jd8w2ZRM0Q6gqho7EBoxcrj+2BrLCWhpLsiJVtYmgNKj+EoRQ870kTkajWAgzkAwMBDO ZGZ/wD2wUKpYk0BIzz7E4b8/WbAxTBlyhzdpg6WWE2VFolb3ELVqs3G4sAoCinuc6KQL VA7WRL1b29SxqXPwV4AAYXUiPuDSQ3IOo58Wn54e3Os/yRJGDpfx1pTMJhksnT833+0y IDbKO/kdyTtX9j3MUsLHKvTVb6BzUAsrJDkWxQTmABBUG65WY/Njw2z3PnbDl3tYp493 Z2KA== X-Gm-Message-State: AEkooutoxn1cnTXff5yvi7I2OO8bR6LlIiRDHbiXyfhhyZ0lKXvTpnKpEbFe0jtaXQNINoWIIkc7mgDtQc3PLQ== X-Received: by 10.157.34.201 with SMTP id y67mr13911468ota.138.1469576348250; Tue, 26 Jul 2016 16:39:08 -0700 (PDT) MIME-Version: 1.0 Received: by 10.182.188.4 with HTTP; Tue, 26 Jul 2016 16:39:07 -0700 (PDT) In-Reply-To: <9dac3b40eb2e6fcf339da6fa1a44f9ad@petri-meat.com> References: <201607220911.u6M9Bco9077775@givry.fdupont.fr> <948512bb-c741-0509-8442-2d230c5bca49@gmail.com> <18213e8b-117a-a443-36fd-df96d56e14de@gmail.com> <9dac3b40eb2e6fcf339da6fa1a44f9ad@petri-meat.com> From: Hemant Singh Date: Tue, 26 Jul 2016 19:39:07 -0400 Message-ID: Subject: Re: Which use cases are using direct EH insertion? To: Steven Blake , fbrockne@cisco.com, shwethab@cisco.com, cpignata@cisco.com, hannes@rtbrick.com Content-Type: multipart/alternative; boundary=94eb2c0332a63537cf0538926895 Archived-At: Cc: 6man WG X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.17 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 Jul 2016 23:39:10 -0000 --94eb2c0332a63537cf0538926895 Content-Type: text/plain; charset=UTF-8 A question related to draft-brockners-inband-oam... How does a router determine it is an egress router and strips the oam options? Is it because the packet destination matches an IP/IPv6 address configured on the router? Or is there a configuration needed on this router to deem it as an egress router to oam options? Thanks, Hemant On Tue, Jul 26, 2016 at 4:16 PM, Steven Blake wrote: > > > If I am reading it correctly, draft-brockners-inband-oam-transport-00 > "Encapsulations for In-band OAM Data" inserts a Hop-by-Hop extension header > with OAM options at the ingress router of an administrative domain, and > strips it at the egress router (Sec. 3). I think that Comcast showed a > demo of this protocol at Bits-n-Bites (but that demo may have used GUE > encapsulation edge-to-edge; I don't recall exactly). > > > Regards, > > // Steve > > > --94eb2c0332a63537cf0538926895 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
A question related to =C2=A0draft-brockners-inband-oam...<= div>
How does a router determine it is an egress router and s= trips the oam options? =C2=A0 Is it because the packet destination matches = an IP/IPv6 address configured on the router?=C2=A0 Or is there a configurat= ion needed on this router to deem it as an egress router to oam options?

Thanks,

Hemant

On Tue, Jul 26, 2016 at 4:= 16 PM, Steven Blake <slblake@petri-meat.com> wrote:
If I am reading it correctly, draft-brockners-inband-oam-transport-00 "= ;Encapsulations for In-band OAM Data" inserts a Hop-by-Hop extension h= eader with OAM options at the ingress router of an administrative domain, a= nd strips it at the egress router (Sec. 3).=C2=A0 I think that Comcast show= ed a demo of this protocol at Bits-n-Bites (but that demo may have used GUE= encapsulation edge-to-edge; I don't recall exactly).


Regards,

// Steve



--94eb2c0332a63537cf0538926895-- From nobody Tue Jul 26 22:20:52 2016 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E121312D16F for ; Tue, 26 Jul 2016 22:20:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -15.807 X-Spam-Level: X-Spam-Status: No, score=-15.807 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, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-1.287, 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 pVzP-ePtMWLW for ; Tue, 26 Jul 2016 22:20:48 -0700 (PDT) Received: from rcdn-iport-8.cisco.com (rcdn-iport-8.cisco.com [173.37.86.79]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6BA9012B04C for ; Tue, 26 Jul 2016 22:20:48 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=7246; q=dns/txt; s=iport; t=1469596848; x=1470806448; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=XCvTyR80MuOXDWA9MZ+FtGhyeipWWF2b/IFUphc6Ems=; b=dRlhUoE+wuEgZjhXTAU0f8MsUAaWw3enYCT2X8MRELScYzF4lynU1rIo e4L4sZDJePD0pYuUG9uRnUC+Lxk7fGsD0dcp7n7tue91MNvJroLDZepG8 JlJUDP65iyJYSDzWKMSwoOBOe9iDCkjR3WTuJcYVT+IFGeO2lkJzj1lj7 8=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0B5AgA0RJhX/5RdJa1egnFOVnwGrFqHH?= =?us-ascii?q?IUFgX0khXkCgTo4FAEBAQEBAQFdJ4RcAQEEAXkFCwIBCBEDAQIoByERFAkIAgQ?= =?us-ascii?q?BDQWIFwMPCA62PQ2EEgEBAQEBAQEBAQEBAQEBAQEBAQEBARyGKoRNgkOCHR6FH?= =?us-ascii?q?QWYfTQBhheGMoIyjz+IKIQFg3cBHjaDeG6HQn8BAQE?= X-IronPort-AV: E=Sophos;i="5.28,428,1464652800"; d="scan'208,217";a="128579164" Received: from rcdn-core-12.cisco.com ([173.37.93.148]) by rcdn-iport-8.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 27 Jul 2016 05:20:24 +0000 Received: from XCH-ALN-007.cisco.com (xch-aln-007.cisco.com [173.36.7.17]) by rcdn-core-12.cisco.com (8.14.5/8.14.5) with ESMTP id u6R5KO6h015492 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Wed, 27 Jul 2016 05:20:24 GMT Received: from xch-aln-008.cisco.com (173.36.7.18) by XCH-ALN-007.cisco.com (173.36.7.17) with Microsoft SMTP Server (TLS) id 15.0.1210.3; Wed, 27 Jul 2016 00:20:23 -0500 Received: from xch-aln-008.cisco.com ([173.36.7.18]) by XCH-ALN-008.cisco.com ([173.36.7.18]) with mapi id 15.00.1210.000; Wed, 27 Jul 2016 00:20:23 -0500 From: "Shwetha Bhandari (shwethab)" To: Hemant Singh , Steven Blake , "Frank Brockners (fbrockne)" , "Carlos Pignataro (cpignata)" , "hannes@rtbrick.com" Subject: Re: Which use cases are using direct EH insertion? Thread-Topic: Which use cases are using direct EH insertion? Thread-Index: AQHR5yjA8oANLZSfXU24znE7aR8Es6AresyAgAA4gYCAALpYAA== Date: Wed, 27 Jul 2016 05:20:23 +0000 Message-ID: References: <201607220911.u6M9Bco9077775@givry.fdupont.fr> <948512bb-c741-0509-8442-2d230c5bca49@gmail.com> <18213e8b-117a-a443-36fd-df96d56e14de@gmail.com> <9dac3b40eb2e6fcf339da6fa1a44f9ad@petri-meat.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.5.6.150930 x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.65.73.87] Content-Type: multipart/alternative; boundary="_000_D3BE3FA238E919shwethabciscocom_" MIME-Version: 1.0 Archived-At: Cc: 6man WG X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.17 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 Jul 2016 05:20:51 -0000 --_000_D3BE3FA238E919shwethabciscocom_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable >How does a router determine it is an egress router and strips the oam opti= ons? Is it because the packet destination matches an IP/IPv6 address conf= igured on the router? Or is there a configuration needed on this router to= deem it as an egress router to oam options? The decision to add/remove the HbyH options/header is based on classificati= on of flows and/or interfaces as entering/leaving the domain. In our curren= t implementation of In-band OAM (in fd.io ) it is done by pushing this configuration on the doma= in's perimeter nodes. > I think that Comcast showed a demo of this protocol at Bits-n-Bites (but= that demo may have used GUE encapsulation edge-to-edge; I don't recall exa= ctly). In the demo it was purely IPv6 edge to edge no encap. Thanks, Shwetha From: Hemant Singh > Date: Wednesday, July 27, 2016 at 5:09 AM To: Steven Blake >, "= Frank Brockners (fbrockne)" >= , Shwetha bhandari >, "Carlos= Pignataro (cpignata)" >, "ha= nnes@rtbrick.com" > Cc: Tim Chown >, 6man WG = > Subject: Re: Which use cases are using direct EH insertion? A question related to draft-brockners-inband-oam... How does a router determine it is an egress router and strips the oam optio= ns? Is it because the packet destination matches an IP/IPv6 address confi= gured on the router? Or is there a configuration needed on this router to = deem it as an egress router to oam options? Thanks, Hemant On Tue, Jul 26, 2016 at 4:16 PM, Steven Blake > wrote: If I am reading it correctly, draft-brockners-inband-oam-transport-00 "Enca= psulations for In-band OAM Data" inserts a Hop-by-Hop extension header with= OAM options at the ingress router of an administrative domain, and strips = it at the egress router (Sec. 3). I think that Comcast showed a demo of th= is protocol at Bits-n-Bites (but that demo may have used GUE encapsulation = edge-to-edge; I don't recall exactly). Regards, // Steve --_000_D3BE3FA238E919shwethabciscocom_ Content-Type: text/html; charset="us-ascii" Content-ID: <528F0C8EFBA90246A36C31BD98C84E04@emea.cisco.com> Content-Transfer-Encoding: quoted-printable
>How does a router determine it is an egress router and strips the = oam options?   Is it because the packet destination matches an IP/IPv6= address configured on the router?  Or is there a configuration needed= on this router to deem it as an egress router to oam options?

The decision to add/remove the HbyH options/header is based on classif= ication of flows and/or interfaces as entering/leaving the domain. In our c= urrent implementation of In-band OAM (in fd.io&nb= sp;) it is done by pushing this configuration on the domain's perimeter nod= es.

>  I think that Comcast showed a demo of this protocol at Bits= -n-Bites (but that demo may have used GUE encapsulation edge-to-edge; I don= 't recall exactly).

In the demo it was purely IPv6 edge to edge no encap.

Thanks,
Shwetha

From: Hemant Singh <hemantietf@gmail.com>
Date: Wednesday, July 27, 2016 at 5= :09 AM
To: Steven Blake <slblake@petri-meat.com>, "Frank Bro= ckners (fbrockne)" <fbrockne@= cisco.com>, Shwetha bhandari <shwethab@cisco.com>, "Carlos Pignataro (cpignata)" <cpignata@cisco.com>, "hannes@rtbrick.com" <hannes@rtbrick.com>
Cc: Tim Chown <Tim.Chown@jisc.ac.uk>, 6man WG <ipv6@ietf.org>
Subject: Re: Which use cases are us= ing direct EH insertion?

A question related to  draft-brockners-inband-oam...

How does a router determine it is an egress router and strips the oam = options?   Is it because the packet destination matches an IP/IPv6 add= ress configured on the router?  Or is there a configuration needed on = this router to deem it as an egress router to oam options?

Thanks,

Hemant

On Tue, Jul 26, 2016 at 4:16 PM, Steven Blake <slblake@pet= ri-meat.com> wrote:

If I am reading it correctly, draft-brockners-inband-oam-transport-0= 0 "Encapsulations for In-band OAM Data" inserts a Hop-by-Hop exte= nsion header with OAM options at the ingress router of an administrative do= main, and strips it at the egress router (Sec. 3).  I think that Comcast showed a demo of this protocol at Bits-n-Bi= tes (but that demo may have used GUE encapsulation edge-to-edge; I don't re= call exactly).


Regards,

// Steve



--_000_D3BE3FA238E919shwethabciscocom_-- From nobody Wed Jul 27 05:57:12 2016 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3319C12D75A for ; Wed, 27 Jul 2016 05:57:11 -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 4-8lpXR3wwjM for ; Wed, 27 Jul 2016 05:57:08 -0700 (PDT) Received: from mail-oi0-x235.google.com (mail-oi0-x235.google.com [IPv6:2607:f8b0:4003:c06::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 7D40312E183 for ; Wed, 27 Jul 2016 05:57:08 -0700 (PDT) Received: by mail-oi0-x235.google.com with SMTP id j185so15914765oih.0 for ; Wed, 27 Jul 2016 05:57:08 -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=euj/1jqnmB0YPSExFi4lE30X6xCckPuu6XEYzfVx2kg=; b=DNf+Kr3rNsPTskTpXCtPsdeWTnNJWn4bsxmJvCEZc4TEDNpnCprQBVPsgKQszBO4bN xP0wpb9jj0XsoVDMiYfQUNWT4IaSy9GczwrpTlzcKviePwFk/ff68dz34yykYNSRRV11 8iS6fAjFBQMbFWJ/QdAjydcDtuAoXD1LmN9rRHgMhrkSav3h68hey98itsfxjbEFcc56 ras9CRSp6cPSVLGWSUHnS0soPbEkp/lgxL0Fk9R04SBnsKtUX2R8aNN6LyOblnMhzUaf /NoSAgkIO+B5+4xsr3UQPooGJmffgJIiDxYpjI73oAG+SKyxuav2kdQKA+r4UD1fJP9K QyiA== 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=euj/1jqnmB0YPSExFi4lE30X6xCckPuu6XEYzfVx2kg=; b=XwOxhT+urJrEA5aTHHnxoaSnjejU0mGbsWYeZXbDk073q70Snks6DD7nZ7R3FORq/8 cG7sfg9aYXE75qC56fwnnlsSo5vnlQtpVOlp7+KrdnDeJYNLtbdQHmL67aMTqCBTB3sw 4YWa8EtoEbdxuCK5A8+CCJw4fc64ZDCqxRkKA6/gdsPIddVGG0+mTcFMyqaJaqHuUp2K b4Yh63aBnbbv2O7oO/N6Y5ux4fgHgc62NVGAuqwxskQvVDgwXDXvtF4wOWJ8yDWZlUDJ u4lCiLo9SkEc88qkG3FzTLJF7oYWSuA60DMaRygd+HgzmMvs1pF/ZIQdtGag4TuU/AXw V2WQ== X-Gm-Message-State: AEkooutTCgB/yIn5Afmx/WXQMaSAZ8kngZWYasQCMOlpGWGGjOSDspMRI5p34CalAEXPm++8YijZNrZaTFjGzQ== X-Received: by 10.202.213.135 with SMTP id m129mr14766435oig.89.1469624227674; Wed, 27 Jul 2016 05:57:07 -0700 (PDT) MIME-Version: 1.0 Received: by 10.182.188.4 with HTTP; Wed, 27 Jul 2016 05:57:07 -0700 (PDT) In-Reply-To: References: <201607220911.u6M9Bco9077775@givry.fdupont.fr> <948512bb-c741-0509-8442-2d230c5bca49@gmail.com> <18213e8b-117a-a443-36fd-df96d56e14de@gmail.com> <9dac3b40eb2e6fcf339da6fa1a44f9ad@petri-meat.com> From: Hemant Singh Date: Wed, 27 Jul 2016 08:57:07 -0400 Message-ID: Subject: Re: Which use cases are using direct EH insertion? To: "Shwetha Bhandari (shwethab)" Content-Type: multipart/alternative; boundary=001a113b06060b3ea305389d8eac Archived-At: Cc: "hannes@rtbrick.com" , 6man WG X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.17 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 Jul 2016 12:57:11 -0000 --001a113b06060b3ea305389d8eac Content-Type: text/plain; charset=UTF-8 If section 3.1.2 related to ingress, we have text that says "insertion of the in-band OAM header is enabled at the required edge nodes by means of configuration." However, the same text does not exist in the egress section in 3.1.4. Why not add common text for ingress/egress before any of these two sections start? How does classification of flows signal to the egress router to strip options? thanks, Hemant On Wed, Jul 27, 2016 at 1:20 AM, Shwetha Bhandari (shwethab) < shwethab@cisco.com> wrote: > > The decision to add/remove the HbyH options/header is based on > classification of flows and/or interfaces as entering/leaving the domain. > In our current implementation of In-band OAM (in fd.io > ) it is done by pushing > this configuration on the domain's perimeter nodes. > > > --001a113b06060b3ea305389d8eac Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
If section 3.1.2 related to ingress, we have text tha= t says "insertion= of=C2=A0the in= -band OAM header is enabled at the required edge nodes by means=C2=A0of configuration." =C2=A0However, the same text does not exist in the egress section= in 3.1.4.=C2=A0 Why not add common text for ingress/egress before any of t= hese two sections start?

How does classification o= f flows signal to the egress router to strip options? =C2=A0
=
thanks,

Hemant

On Wed, Jul 27, 2016 at 1:20 AM, S= hwetha Bhandari (shwethab) <shwethab@cisco.com> wrote:
<= blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-l= eft-width:1px;border-left-style:solid;border-left-color:rgb(204,204,204);pa= dding-left:1ex">

The decision to add/remove the HbyH options/header is based on = classification of flows and/or interfaces as entering/leaving the domain. I= n our current implementation of In-band OAM (in fd.io=C2=A0) it is done by pushing this configuration on the doma= in's perimeter nodes.


--001a113b06060b3ea305389d8eac-- From nobody Wed Jul 27 08:11:31 2016 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 13DC012DBAF for ; Wed, 27 Jul 2016 08:11:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.347 X-Spam-Level: X-Spam-Status: No, score=-2.347 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FORGED_FROMDOMAIN=0.001, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=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 ZKp0abIm_gsA for ; Wed, 27 Jul 2016 08:11:28 -0700 (PDT) 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 D462212DBBB for ; Wed, 27 Jul 2016 08:11:27 -0700 (PDT) Received: by mail-io0-x22c.google.com with SMTP id 38so73015978iol.0 for ; Wed, 27 Jul 2016 08:11:27 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to:cc; bh=wJZKe0TrYro3OJ6buA20qp1VExaadDLIwjPPgnrGz00=; b=A+9iJb6U+IA5RXEA0Obx8dljBuE6OTvjjtQK+b/kNP7ELkQMSxaZJjAnoxNp8FnP5T FZFz4IFd+qkS5bRngiqZeXkRmGinw5BF94hDP3vCCQ8LMH+C4+7X6Z+jKBW4Kj0dNMbo XGRkE6zBmhG7qWepb809tjkL1lfd3Zvn/rPl/H7kRv74KKrYgqW8Sow22RoRZjZS66Qo 4rG1fn25F5MTaOW3EOApQnzylxAHKBaUo+97heAHvg8q69HYpCmDo9A4e1wH0gCSNahg mS2M4ikJIEm6FMiwcCwEowV2U1ESgs435Ry/rr4gdeSO7/7b4qJnDP6Rhn8mGJOmwnTG lM4Q== 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:from :date:message-id:subject:to:cc; bh=wJZKe0TrYro3OJ6buA20qp1VExaadDLIwjPPgnrGz00=; b=b3DF/WQMz/weV0Jt5li/PVGsMUk/iYq9vdFGJBAW5CVk4kIWhlyxknRhm/GCq1x0y1 aGe0h6ktsuDbUNgeGMse3zopc6M5K2glXX0I0aK8gOinOqSnvB6PRPQ2vdH6F6Oir75V Xds1dwEd5DFpsADcqtPFGsoJMwlk7YyX+KZVmTguXcVG1BsbblEB0ZEMzMlC03PevGRH Wd+Yl2Tmn+K+9/sJ5Oo4p2drs8pgn3de3OX/1Rs7VchOExQOY1otkox7Re65tDmYyJEs FWplgaTyLcqQNgR6/CSFm8YziInnGKkgytFDPxtm4HDAT4uSHqPe8GawalP/botkqwsd ig3Q== X-Gm-Message-State: AEkoouuEdTA+h0ByHI7W7hGsmLxRWFdfnfS9CVS/JIVvY6gJYVi5rz1OumKcXzE0ATi1BZQDbdnFC+xjepkl3g== X-Received: by 10.107.13.70 with SMTP id 67mr33067524ion.75.1469632287200; Wed, 27 Jul 2016 08:11:27 -0700 (PDT) MIME-Version: 1.0 Sender: kerlyn2001@gmail.com Received: by 10.107.9.22 with HTTP; Wed, 27 Jul 2016 08:11:26 -0700 (PDT) In-Reply-To: <18512b21-4414-70c9-a1c8-f46e135420d0@gmail.com> References: <489138271.16809.1469213275935@webmail.networksolutionsemail.com> <3A6F8207-249F-4E38-A697-79362A8E82FC@jisc.ac.uk> <0A9918AB-E46B-4AAF-A1F2-D3FE3F671F5B@amalfisystems.com> <9DE6D3F8-2DA8-483B-BF74-9C348BE80931@jisc.ac.uk> <18512b21-4414-70c9-a1c8-f46e135420d0@gmail.com> From: Kerry Lynn Date: Wed, 27 Jul 2016 11:11:26 -0400 X-Google-Sender-Auth: bpDIgaBcSpWp3gP5xkIxJyBJu_g Message-ID: Subject: Re: 2460bis-05 To: Brian E Carpenter Content-Type: multipart/alternative; boundary=001a113ff9946de8db05389f6e44 Archived-At: Cc: "ipv6@ietf.org" X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.17 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 Jul 2016 15:11:30 -0000 --001a113ff9946de8db05389f6e44 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On Tue, Jul 26, 2016 at 4:57 PM, Brian E Carpenter < brian.e.carpenter@gmail.com> wrote: > On 27/07/2016 05:16, Tim Chown wrote: > > On 26 Jul 2016, at 17:28, Randy Turner > wrote: > > > > Hi, > > > > I wasn=E2=80=99t asking about what the RFC was about, I was asking abou= t the > definition of =E2=80=9Cfull=E2=80=9D, and whether or not there might be a= better term for > what is implied in section 4 of 2460bis > > > > I don=E2=80=99t believe =E2=80=9Cfull implementation=E2=80=9D is define= d anywhere. And of course > 18 years have since passed and (for example) the requirement on AH/ESP > support was relaxed some time ago. So you could suggest an alternative. > UNH-IOH refer to 2460 as their IPv6 core requirement test, but =E2=80=9Cc= ore > implementation=E2=80=9D doesn=E2=80=99t sound quite right. I suspect the= re may not be much > appetite to change it. > > Something seems to tell me that "full implementation" was intended to > suggest > that a low-end device could treat those headers (and in particular > fragmentation) > as optional. But then it couldn't communicate with the world at large. > In any case it's a bit vague, and I think Randy has raised a good questio= n. > The current status of AH means that we need to change this text anyway. > Something > like: > > A normal implementation of IPv6 supports the following extension > headers: > > s/A normal/An unconstrained ? Kerry > Hop-by-Hop Options > Fragment > Destination Options > Encapsulating Security Payload > > Regards > Brian > > > > > Tim > > > > R. > > > > On Jul 26, 2016, at 11:56 AM, Tim Chown Tim.Chown@jisc.ac.uk>> wrote: > > > > On 22 Jul 2016, at 19:47, Randy Turner > wrote: > > > > Hi All, > > > > In section 4 of 2460bis-05, there is a description of what a "full" > implementation would consist of...can someone elaborate on the definition > of "full" ? Is this a conformance thing > > > > Well, RFC2460 forms part of various conformance and interoperability > tests, e.g. see https://www.iol.unh.edu/testing/ip/ipv6/test-suites, so > the core conformance test suite there tests against a handful of RFCs (i.= e. > RFC2460, RFC4861, RFC4862, RFC4443, RFC5095 and RFC1981), so would only > include the EHs defined in RFC2460, less RH0 which was deprecated with > RFC5095. > > > > If you=E2=80=99re interested in what capabilities a generic IPv6 node s= hould > have, then RFC6434 is a place to look (and an update to that is underway)= . > > > > Tim > > > > > > > > > > > > > > -------------------------------------------------------------------- > > 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 > -------------------------------------------------------------------- > --001a113ff9946de8db05389f6e44 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On T= ue, Jul 26, 2016 at 4:57 PM, Brian E Carpenter <brian.e.carpente= r@gmail.com> wrote:
On 27/0= 7/2016 05:16, Tim Chown wrote:
> On 26 Jul 2016, at 17:28, Randy Turner <rturner@amalfisystems.com<mailto:= rturner@amalfisystems.com&= gt;> wrote:
>
> Hi,
>
> I wasn=E2=80=99t asking about what the RFC was about, I was asking abo= ut the definition of =E2=80=9Cfull=E2=80=9D, and whether or not there might= be a better term for what is implied in section 4 of 2460bis
>
> I don=E2=80=99t believe =E2=80=9Cfull implementation=E2=80=9D is defin= ed anywhere. And of course 18 years have since passed and (for example) the= requirement on AH/ESP support was relaxed some time ago. So you could sugg= est an alternative. UNH-IOH refer to 2460 as their IPv6 core requirement te= st, but =E2=80=9Ccore implementation=E2=80=9D doesn=E2=80=99t sound quite r= ight.=C2=A0 I suspect there may not be much appetite to change it.

Something seems to tell me that "full implementation" was = intended to suggest
that a low-end device could treat those headers (and in particular fragment= ation)
as optional. But then it couldn't communicate with the world at large.<= br> In any case it's a bit vague, and I think Randy has raised a good quest= ion.
The current status of AH means that we need to change this text anyway. Som= ething
like:

=C2=A0 =C2=A0A normal implementation of IPv6 supports the following extensi= on headers:

s/A normal/An unconstrained ?

Kerry
=C2=A0
=C2=A0 =C2=A0 =C2=A0 Hop-by-Hop Options
=C2=A0 =C2=A0 =C2=A0 Fragment
=C2=A0 =C2=A0 =C2=A0 Destination Options
=C2=A0 =C2=A0 =C2=A0 Encapsulating Security Payload

Regards
=C2=A0 =C2=A0Brian

>
> Tim
>
> R.
>
> On Jul 26, 2016, at 11:56 AM, Tim Chown <Tim.Chown@jisc.ac.uk<mailto:Tim.Chown@jisc.ac.uk>> wrote:
>
> On 22 Jul 2016, at 19:47, Randy Turner <rturner@amalfisystems.com<mailto:rturner@amalfisystems.com>> wrote: >
> Hi All,
>
> In section 4 of 2460bis-05, there is a description of what a "ful= l" implementation would consist of...can someone elaborate on the defi= nition of "full" ?=C2=A0 Is this a conformance thing
>
> Well, RFC2460 forms part of various conformance and interoperability t= ests, e.g. see https://www.iol.unh.edu/testing/ip= /ipv6/test-suites, so the core conformance test suite there tests again= st a handful of RFCs (i.e. RFC2460, RFC4861, RFC4862, RFC4443, RFC5095 and = RFC1981), so would only include the EHs defined in RFC2460, less RH0 which = was deprecated with RFC5095.
>
> If you=E2=80=99re interested in what capabilities a generic IPv6 node = should have, then RFC6434 is a place to look (and an update to that is unde= rway).
>
> Tim
>
>
>
>
>
>
> ---------------------------------------------------------------= -----
> 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/list= info/ipv6
--------------------------------------------------------------------

--001a113ff9946de8db05389f6e44-- From nobody Wed Jul 27 12:49:36 2016 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 660C112D534; Wed, 27 Jul 2016 12:49:31 -0700 (PDT) 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 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 3Ot0XcsssmpX; Wed, 27 Jul 2016 12:49:29 -0700 (PDT) Received: from eidolon.nox.tf (eidolon.nox.tf [IPv6:2a07:2ec0:2185::]) (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 0EA3512D0C2; Wed, 27 Jul 2016 12:49:29 -0700 (PDT) Received: from equinox by eidolon.nox.tf with local (Exim 4.87) (envelope-from ) id 1bSUpX-000Fvv-QF; Wed, 27 Jul 2016 21:49:25 +0200 Date: Wed, 27 Jul 2016 21:49:23 +0200 From: David Lamparter To: 6man <6man@ietf.org> Subject: RFC 6724 rule 5.5 implementation guidance (was: Linux 6724 rule 5.5, ...enterprise-pa-multihoming) Message-ID: <20160727194923.GG996866@eidolon> References: <20160706005825.22318.33162.idtracker@ietfa.amsl.com> <1D424B70-9241-453D-85FF-A296A4DCE653@cisco.com> <20160720125458.GO255916@eidolon> <0b8fe558-768f-6407-6a58-26df0f3817c6@gmail.com> <20160720143410.GS255916@eidolon> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.24 (2015-08-30) Archived-At: Cc: "v6ops@ietf.org" , Praveen Balasubramanian , "Fred Baker \(fred\)" , Jen Linkova X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.17 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 Jul 2016 19:49:31 -0000 On Thu, Jul 21, 2016 at 07:25:45PM +1200, Brian E Carpenter wrote: > On 21/07/2016 02:34, David Lamparter wrote: > > On Thu, Jul 21, 2016 at 01:22:15AM +1200, Brian E Carpenter wrote: > >> Please tell us ASAP if there is anything we should add to > >> https://tools.ietf.org/html/draft-ietf-6man-multi-homed-host-03#section-3.2 > >> or thereabouts. I believe we need to ship the following text (or something similar) /somewhere/: (Some points - particularly 7, 8 & 10 - might need some arguing about. Text below is what I /believe/ to be reasonable, but I may of course have overlooked some scenarios...) Cheers / hoping for feedback, -David P.S.: Praveen - this is what I was wondering about when I asked you @ Bits'n'Bytes in Berlin. Can you provide some insight into how Windows implements this? --- section: Rule 5.5 implementation considerations Since neither RFC 4861 nor RFC 4191 detailed notes on how to "remember which next-hops advertised which prefixes" [RFC 6724], these are listed here: 1. Note RFC 6724 mentions "SA or SA's prefix". This is redundant for SLAAC-derived addresses but needs to be considered for DHCPv6 and admin-configured addresses. If a router advertises a particular prefix, addresses in that prefix SHOULD be preferred regardless of the mechanism used to configure them. 2. Neither L nor A bit in the Prefix Information Option (PIO) are specified anywhere to have an impact on source address selection. Hosts SHOULD consider all PIOs regardless of L/A bit values for the purposes of source address selection. 3. When using non-default routes learned from Route Information Options, hosts SHOULD apply the rules in the same manner, preferring source addresses inside prefixes advertised by the nexthop of the specific route used. 4. Routers MAY advertise more than one prefix (e.g. during renumbering), which hosts SHOULD honor up to a limit imposed by security considerations. 5. More than one router MAY advertise the same prefix. In particular, homenet routers implementing RFCs 7695 and 7788 will exhibit this behaviour by default and in normal operation. Hosts SHOULD be able to correctly retain identical prefixes for multiple routers, up to a limit imposed by security considerations. 6. A router MAY choose to include prefix information only in some of its RAs, for example when the sum of RA options exceeds the link's MTU. A host MUST NOT rely on all RAs including all information. This also means a host MUST NOT implement rule 5.5 by keeping a copy of the last RA packet, as that packet may not have all information. 7. Entries on a router's list of advertised prefixes need to be expired using the prefix's (TBD: valid or preferred?) lifetime. Hosts SHOULD apply the same rules regarding lifetimes as if they were configuring an address from that prefix. 8. A host MAY dismiss a router's list of advertised prefixes if all routes via that router expire. If a host does so, it MUST ensure that additional routes learned from Route Information Options cause it to retain the list even if the default route expires (i.e. had a lower lifetime), or is not added to begin with. 9. Hosts MUST NOT use link-layer addresses to identify routers. Not only is this information unreliable on some media (e.g. 802.11 with aggressive controller-based optimizations), but it also conflicts with (future) approaches to exploit rule 5.5 for multihoming scenarios. Hosts MUST use IPv6 link-local addresses to identify routers for this purpose. 10. Hosts SHOULD retain prefix information even if they have no address inside that prefix. Not doing so delays the application of improved source address selection for DHCPv6 and admin-configured addresses until the next receipt of a RA packet. This can be visible to the user as a temporary period of failed service, or, if RAs are infrequent, be interpreted as entirely broken connectivity. section: Security Considerations Retaining additional information from router advertisements opens hosts to another avenue of memory exhaustion attacks by malicious on-link hosts. Implementations MUST cap the amount of data retained. section: Privacy Considerations If hosts incorrectly mix prefix information across multiple interfaces, it becomes possible for malicious on-link hosts (or routers) to enumerate all of a host's IPv6 addresses. Hosts therefore MUST keep this information strictly scoped to the respective interface. Routers generally gain a method of insight into a host's addresses. This extends existing considerations applying to rogue RAs. The problem is particularly relevant on link layers where the broadcast domain is shattered into non-transitive subdomains (e.g. Private VLANs [RFC 5517]). Even if RAs are secured in some way, privacy is not provided between multiple routers on the same link. section: Acknowledgements This text/section/... was added by David Lamparter based on implementation observations and discussions with Lorenzo Colitti and Jen Linkova. From nobody Wed Jul 27 13:19:12 2016 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7E46A12D580; Wed, 27 Jul 2016 13:19:06 -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 z6adB7mRZcVA; Wed, 27 Jul 2016 13:19:04 -0700 (PDT) Received: from mail-pf0-x235.google.com (mail-pf0-x235.google.com [IPv6:2607:f8b0:400e:c00::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 A0EAA12D57B; Wed, 27 Jul 2016 13:19:04 -0700 (PDT) Received: by mail-pf0-x235.google.com with SMTP id y134so14052685pfg.0; Wed, 27 Jul 2016 13:19:04 -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=ZR2xNoawQ9Lh18uaZKMsyPcmxL4k6izo2AFCLzfG4RA=; b=sGb6tJlOCMGIcnZ5/fDD7X9Y9koYLgGnfJQGNZY98cTSmZNiUHervJUwRLB3jdaz5o ikwXr8gq6gbjv1AllXm2TFmsvQ+obd+CE+umXNzVlBMmTzXemguwZQvbavlAqDTzocmh QqT2N7TJRk8L5Qnjwt31EYdDsHJKFlai0Yb87rap6ISSXPgdkME5hwmcnocLUgXkQKNU 5XWcLPnOTrp+IcqUM2RX8edYpf4wLS+12XgjEyHUO05fz8c3MfCmZN4w3EFu8DEn1Rmy rAdmH782+iPSP+CSVPXm5DLBFuLL2fRV18miA79B92LSP523MWOnE2V6C2rSBszPbNeY GGsw== 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=ZR2xNoawQ9Lh18uaZKMsyPcmxL4k6izo2AFCLzfG4RA=; b=GoRHYx2D7WlK0wA7CCbxrE9sNzFbfaSboUpkp5ykhJ8IQOAbqJxosG7aS0XWr3eWnw G122YhnUnFqClvCbjOe9zLXXm+jXjivQ25IP1xo68T+5krRn2mav5FiLtfYEkz8RttGO TU9F5M3IgyJp2nxOWwiX7Bgb83ms0mPFgpXlf53IccIPh+HIkO0OPIUlvrNooKj9sidY 65bCQMHjmyp3miaPn1f7h6HP8483kHUbuArNJ/nRE2N5R/mtZEqYvhY7PE2zMDKSHyCZ ELp0xjoYm/lC1weShOXzUnVzn4j9aXOkFdy6nXZy5/4k1cvA3wSTQ5AvouH8dXH8+5Xy ybzg== X-Gm-Message-State: AEkoouttSjnRmArt8yfHIUHjnfy1sNLpTBO8BlfKgH30tq7Yc04vs48jqqm+9CaiKYaEfQ== X-Received: by 10.98.59.70 with SMTP id i67mr52344793pfa.45.1469650744212; Wed, 27 Jul 2016 13:19:04 -0700 (PDT) Received: from ?IPv6:2406:e007:5502:1:28cc:dc4c:9703:6781? ([2406:e007:5502:1:28cc:dc4c:9703:6781]) by smtp.gmail.com with ESMTPSA id c82sm11205281pfb.72.2016.07.27.13.19.00 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 27 Jul 2016 13:19:03 -0700 (PDT) Subject: Re: RFC 6724 rule 5.5 implementation guidance To: David Lamparter , 6man <6man@ietf.org>, Suresh Krishnan References: <20160706005825.22318.33162.idtracker@ietfa.amsl.com> <1D424B70-9241-453D-85FF-A296A4DCE653@cisco.com> <20160720125458.GO255916@eidolon> <0b8fe558-768f-6407-6a58-26df0f3817c6@gmail.com> <20160720143410.GS255916@eidolon> <20160727194923.GG996866@eidolon> From: Brian E Carpenter Organization: University of Auckland Message-ID: <43025435-75bf-4334-b315-aaf964c1a40a@gmail.com> Date: Thu, 28 Jul 2016 08:19:04 +1200 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.2.0 MIME-Version: 1.0 In-Reply-To: <20160727194923.GG996866@eidolon> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Archived-At: Cc: Praveen Balasubramanian , "v6ops@ietf.org" , Jen Linkova , "Fred Baker \(fred\)" X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.17 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 Jul 2016 20:19:06 -0000 David, On 28/07/2016 07:49, David Lamparter wrote: > On Thu, Jul 21, 2016 at 07:25:45PM +1200, Brian E Carpenter wrote: >> On 21/07/2016 02:34, David Lamparter wrote: >>> On Thu, Jul 21, 2016 at 01:22:15AM +1200, Brian E Carpenter wrote: >>>> Please tell us ASAP if there is anything we should add to >>>> https://tools.ietf.org/html/draft-ietf-6man-multi-homed-host-03#section-3.2 >>>> or thereabouts. > > I believe we need to ship the following text (or something similar) > /somewhere/: I like what you wrote. I don't think such eminently practical information fits very well into IETF documents but I'd be interested in other opionions. draft-ietf-6man-multi-homed-host is in IETF LC and already on the IESG agenda, so if we should add this sort of material Suresh had better tell us to do so rather soon. One specific comment below... > > (Some points - particularly 7, 8 & 10 - might need some arguing about. > Text below is what I /believe/ to be reasonable, but I may of course > have overlooked some scenarios...) > > Cheers / hoping for feedback, > > -David > > > P.S.: Praveen - this is what I was wondering about when I asked you @ > Bits'n'Bytes in Berlin. Can you provide some insight into how Windows > implements this? > > --- > section: Rule 5.5 implementation considerations > > Since neither RFC 4861 nor RFC 4191 detailed notes on how to "remember > which next-hops advertised which prefixes" [RFC 6724], these are listed > here: > > 1. Note RFC 6724 mentions "SA or SA's prefix". This is redundant for > SLAAC-derived addresses but needs to be considered for DHCPv6 and > admin-configured addresses. If a router advertises a particular > prefix, addresses in that prefix SHOULD be preferred regardless of > the mechanism used to configure them. > > 2. Neither L nor A bit in the Prefix Information Option (PIO) are > specified anywhere to have an impact on source address selection. > Hosts SHOULD consider all PIOs regardless of L/A bit values for the > purposes of source address selection. Yes, including L=0 and A=0, as explicitly called out at the end of https://tools.ietf.org/html/draft-ietf-6man-multi-homed-host-07#section-2.1 Brian > > 3. When using non-default routes learned from Route Information Options, > hosts SHOULD apply the rules in the same manner, preferring source > addresses inside prefixes advertised by the nexthop of the specific > route used. > > 4. Routers MAY advertise more than one prefix (e.g. during renumbering), > which hosts SHOULD honor up to a limit imposed by security > considerations. > > 5. More than one router MAY advertise the same prefix. In particular, > homenet routers implementing RFCs 7695 and 7788 will exhibit this > behaviour by default and in normal operation. Hosts SHOULD be able > to correctly retain identical prefixes for multiple routers, up to a > limit imposed by security considerations. > > 6. A router MAY choose to include prefix information only in some of its > RAs, for example when the sum of RA options exceeds the link's MTU. > A host MUST NOT rely on all RAs including all information. This also > means a host MUST NOT implement rule 5.5 by keeping a copy of the > last RA packet, as that packet may not have all information. > > 7. Entries on a router's list of advertised prefixes need to be expired > using the prefix's (TBD: valid or preferred?) lifetime. Hosts SHOULD > apply the same rules regarding lifetimes as if they were configuring > an address from that prefix. > > 8. A host MAY dismiss a router's list of advertised prefixes if all > routes via that router expire. If a host does so, it MUST ensure > that additional routes learned from Route Information Options cause > it to retain the list even if the default route expires (i.e. had a > lower lifetime), or is not added to begin with. > > 9. Hosts MUST NOT use link-layer addresses to identify routers. Not > only is this information unreliable on some media (e.g. 802.11 with > aggressive controller-based optimizations), but it also conflicts > with (future) approaches to exploit rule 5.5 for multihoming > scenarios. Hosts MUST use IPv6 link-local addresses to identify > routers for this purpose. > > 10. Hosts SHOULD retain prefix information even if they have no address > inside that prefix. Not doing so delays the application of improved > source address selection for DHCPv6 and admin-configured addresses > until the next receipt of a RA packet. This can be visible to the > user as a temporary period of failed service, or, if RAs are > infrequent, be interpreted as entirely broken connectivity. > > > section: Security Considerations > > Retaining additional information from router advertisements opens hosts > to another avenue of memory exhaustion attacks by malicious on-link > hosts. Implementations MUST cap the amount of data retained. > > > section: Privacy Considerations > > If hosts incorrectly mix prefix information across multiple interfaces, > it becomes possible for malicious on-link hosts (or routers) to > enumerate all of a host's IPv6 addresses. Hosts therefore MUST keep > this information strictly scoped to the respective interface. > > Routers generally gain a method of insight into a host's addresses. > This extends existing considerations applying to rogue RAs. The problem > is particularly relevant on link layers where the broadcast domain is > shattered into non-transitive subdomains (e.g. Private VLANs [RFC > 5517]). Even if RAs are secured in some way, privacy is not provided > between multiple routers on the same link. > > > section: Acknowledgements > > This text/section/... was added by David Lamparter based on > implementation observations and discussions with Lorenzo Colitti and Jen > Linkova. > From nobody Wed Jul 27 17:47:37 2016 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9014B12DB6A; Wed, 27 Jul 2016 17:47:32 -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 Ke-3aE0GOC8n; Wed, 27 Jul 2016 17:47:31 -0700 (PDT) Received: from mail-oi0-x235.google.com (mail-oi0-x235.google.com [IPv6:2607:f8b0:4003:c06::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 CD17912DA20; Wed, 27 Jul 2016 17:47:30 -0700 (PDT) Received: by mail-oi0-x235.google.com with SMTP id w18so41930814oiw.3; Wed, 27 Jul 2016 17:47:30 -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=e8OuPnjkLXrvoiGM1I1qNriPkbjAJ46IcDtzIYk+Qxc=; b=xGmXCoqITA462rzfSm8jAkZXn0Zi1GEwrQuip2H92hz7NmPgz9l9ttaCuwUVyEajAn Cm4634ozkDqm22pqwCpbZsVlDKUgnoRMue3K8laoTpZnnoHzW/ma5C1HAEwZiLhvXKLE 5nE8lsNCs9We14KyDAtTa2QDd49/flRAtoztrwPfvEXkVd7NKKEzX2F3RjRYvx5vtkUz HYaXR/DIneMhW7a9AHmjgR4SmEvVrJoR3afncQRhtGFT9nwuv1+7X5swQvI7+BLOJ4rH gWIMEFY5DOQlc5bl5gKD+eaXZXXXfNhLsaqfYvvv0VBG9nTomGL4ZsoMgXQ3kiIRIKGB WEBg== 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=e8OuPnjkLXrvoiGM1I1qNriPkbjAJ46IcDtzIYk+Qxc=; b=guWSs1PPHbzl5kcE4wiuxw/siccWsZpUkMiFEYpcHljJJnaugJFfAT2eq6Ii0plZDS ezH1XNk6Jvv4Iz073xxyMOIuflNpOUHPKN5BwVi1AMoFOYBAb/tIs/Pf8G4AmRXr9ybm 0pgwkBIicCB3mzR8eAXATOpGjeDXsTEgIilBZAdQ9QkJBEctblEU+duTeUgHGvh9MGYU O0IVGjU23jfO9nVWE8ll2A6uCxAVLoKtipIv40Y+XnElIQXeITAgZ50CY8E8odPzSblp tDCqC4Kcq62r98W9dWCI9QCccjFBmfBwqhMpzX9Pw4do/yu1ZgQD8mCq8gRHtbj3ztzr pkuw== X-Gm-Message-State: AEkoousUBBtQ/fF0l+BQS5b3GU3l87m/2/IaakyDHXcruVn6BsiSuY1A+NP+q4+Va5EqcYbZAI9U+h3O7DffhQ== X-Received: by 10.202.171.80 with SMTP id u77mr19001492oie.29.1469666850177; Wed, 27 Jul 2016 17:47:30 -0700 (PDT) MIME-Version: 1.0 Received: by 10.182.188.4 with HTTP; Wed, 27 Jul 2016 17:47:29 -0700 (PDT) In-Reply-To: <20160727194923.GG996866@eidolon> References: <20160706005825.22318.33162.idtracker@ietfa.amsl.com> <1D424B70-9241-453D-85FF-A296A4DCE653@cisco.com> <20160720125458.GO255916@eidolon> <0b8fe558-768f-6407-6a58-26df0f3817c6@gmail.com> <20160720143410.GS255916@eidolon> <20160727194923.GG996866@eidolon> From: Hemant Singh Date: Wed, 27 Jul 2016 20:47:29 -0400 Message-ID: Subject: Re: [v6ops] RFC 6724 rule 5.5 implementation guidance (was: Linux 6724 rule 5.5, ...enterprise-pa-multihoming) To: David Lamparter Content-Type: multipart/alternative; boundary=001a113cc7dc8b09820538a77a17 Archived-At: Cc: Praveen Balasubramanian , "v6ops@ietf.org" , 6man <6man@ietf.org>, Jen Linkova X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.17 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 Jul 2016 00:47:32 -0000 --001a113cc7dc8b09820538a77a17 Content-Type: text/plain; charset=UTF-8 First, if the doc is in the IESG, so much text does not make sense to add to the doc at this juncture. Second, I agree with Brian that it is mostly practical information that does not belong in an IETF RFC. Third, it is too much text and the text has to be thoroughly reviewed by a wide audience. I reviewed the proposed text and see most items are not necessary. I have my review comments in line below preceded by "". On Wed, Jul 27, 2016 at 3:49 PM, David Lamparter wrote: > On Thu, Jul 21, 2016 at 07:25:45PM +1200, Brian E Carpenter wrote: > > > --- > section: Rule 5.5 implementation considerations > > Since neither RFC 4861 nor RFC 4191 detailed notes on how to "remember > which next-hops advertised which prefixes" [RFC 6724], these are listed > here: > It is deliberate. If a host tracks prefixes advertised by a specific router, RFC 4861 and RFC 4191 require a change which needs to be discussed. > > 1. Note RFC 6724 mentions "SA or SA's prefix". This is redundant for > SLAAC-derived addresses Not quite. Also, a renumbering takes place and Prefix A is advertised with reduced lifetime which eventually goes to zero. Now each destination that matches Prefix A is off-link. Router A advertised SA Prefix A and router B advertised SA Prefix B. Now router selection is needed at the host. What SLAAC address is used for SA requires more work that a redundant "on-link" for any SLAAC prefix. but needs to be considered for DHCPv6 and > admin-configured addresses. If a router advertises a particular > prefix, addresses in that prefix SHOULD be preferred regardless of > the mechanism used to configure them. > RFC4861 already covers a union of information from RA and DHCPv6 for use by the host. See section 6.3.4 in RFC4861 and this text: "Hosts accept the union of all received information;" > > 2. Neither L nor A bit in the Prefix Information Option (PIO) are > specified anywhere to have an impact on source address selection. > Hosts SHOULD consider all PIOs regardless of L/A bit values for the > purposes of source address selection. > No. If the lifetime in the PIO is zero, more work is needed to pick a source address. > > 3. When using non-default routes learned from Route Information Options, > hosts SHOULD apply the rules in the same manner, preferring source > addresses inside prefixes advertised by the nexthop of the specific > route used. > Minor comment first. IPv6 ND has no concept of a default route. ND specifies a default router for the link. The text in this item 3 is not needed. When a packet is to be sent out, the host performs a longest prefix match of the packet destination with prefixes in the Prefix List. If a match is found, the next-hop is the packet destination. If not, the packet is forwarded to the default router. If the host supports RFC 4191, the rules are already specified in RFC 4191 for routing table. > > 4. Routers MAY advertise more than one prefix (e.g. during renumbering), > which hosts SHOULD honor up to a limit imposed by security > considerations. > Already covered in RFC 4861 and RFC 4862. See section 5.5.4 in RFC 4862 and sections 6.3.5 and 12 in RFC 4861. > > 5. More than one router MAY advertise the same prefix. In particular, > homenet routers implementing RFCs 7695 and 7788 will exhibit this > behaviour by default and in normal operation. Hosts SHOULD be able > to correctly retain identical prefixes for multiple routers, up to a > limit imposed by security considerations. > > Could you please provide specific text and sections from the homenet RFCs to show why multiple routers advertise the same prefix and what is the reason for doing so. A topology diagram would help - maybe the diagram exists in a homenet doc. Then we can discuss. 6. A router MAY choose to include prefix information only in some of its > RAs, for example when the sum of RA options exceeds the link's MTU. > A host MUST NOT rely on all RAs including all information. This also > means a host MUST NOT implement rule 5.5 by keeping a copy of the > last RA packet, as that packet may not have all information. > Section 6.3.4 of RFC 4861 already covers such details and thus Rule 5.5 of RFC 6724 is fine. > > 7. Entries on a router's list of advertised prefixes need to be expired > using the prefix's (TBD: valid or preferred?) lifetime. Hosts SHOULD > apply the same rules regarding lifetimes as if they were configuring > an address from that prefix. > It is the Preferred Lifetime. RFC 4862 already includes the behavior you describe above for SLAAC addresses. DHCPv6 has address renew mechanisms to refresh address before the address expires. I don't see a need to text in item 7 above. > > 8. A host MAY dismiss a router's list of advertised prefixes if all > routes via that router expire. If a host does so, it MUST ensure that additional routes learned from Route Information Options cause > it to retain the list even if the default route expires (i.e. had a > lower lifetime), or is not added to begin with. > Text is not needed. Section 6.3.5 clears specifies how to timeout entries in the Prefix List and the Default Router List. > > 9. Hosts MUST NOT use link-layer addresses to identify routers. Not > only is this information unreliable on some media (e.g. 802.11 with > aggressive controller-based optimizations), but it also conflicts > with (future) approaches to exploit rule 5.5 for multihoming > scenarios. Hosts MUST use IPv6 link-local addresses to identify > routers for this purpose. > > If the RA includes a Source Link-layer address via the Source Link-layer address Option (SLAO), the host is legal to use the link-layer address. If a link does not use Source Link-layer address, then no SLAO is included in the RA. How is a packet forwarded by the host to the default router if the host does not know the link-layer address of the default router? More details on 802.11 optimizations are needed before the text in item 9 is considered. > 10. Hosts SHOULD retain prefix information even if they have no address > inside that prefix. Not doing so delays the application of improved > source address selection for DHCPv6 and admin-configured addresses > until the next receipt of a RA packet. This can be visible to the > user as a temporary period of failed service, or, if RAs are > infrequent, be interpreted as entirely broken connectivity. > > A better model exists if the hosts only use DHCPv6. The router sends an RA with no PIO with the M and O bits set, Thus hosts have all non-link-local destinations as off-link. > > section: Security Considerations > > Retaining additional information from router advertisements opens hosts > to another avenue of memory exhaustion attacks by malicious on-link > hosts. Implementations MUST cap the amount of data retained. > > RFC 4861, in section 5.3 already says "However, a node may garbage-collect entries prematurely if it is low on memory." > > section: Privacy Considerations > > If hosts incorrectly mix prefix information across multiple interfaces, > it becomes possible for malicious on-link hosts (or routers) to > enumerate all of a host's IPv6 addresses. Hosts therefore MUST keep > this information strictly scoped to the respective interface. > IPv6 ND and SLAAC are protocols that work for a specific interface. Thus this information is blatantly clear. If host mix information, it's a bug in the host implementation to fix. No new text to IETF RFCs is needed. > > Routers generally gain a method of insight into a host's addresses. > This extends existing considerations applying to rogue RAs. The problem > is particularly relevant on link layers where the broadcast domain is > shattered into non-transitive subdomains (e.g. Private VLANs [RFC > 5517]). Even if RAs are secured in some way, privacy is not provided > between multiple routers on the same link. > > Again, the RA is promiscuous for a specific private VLAN domain. It > is clear and obvious information. > Hemant > > --001a113cc7dc8b09820538a77a17 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
First, if the doc is in the IESG, so much text does not ma= ke sense to add to the doc at this juncture.=C2=A0
Second, I agree with= Brian that it is mostly practical information that does not belong in an I= ETF RFC.=C2=A0
Third, it is too much text and the text has to be = thoroughly reviewed by a wide audience.=C2=A0 I reviewed the proposed text = and see most items are not necessary. =C2=A0=C2=A0

I have my review comments in line below preceded by "<hs>"= .


O= n Wed, Jul 27, 2016 at 3:49 PM, David Lamparter <equinox@diac24.net&g= t; wrote:
On Thu, Jul 21, 2016 at 07:25:45PM +12= 00, Brian E Carpenter wrote:


---
section: Rule 5.5 implementation considerations

Since neither RFC 4861 nor RFC 4191 detailed notes on how to "remember=
which next-hops advertised which prefixes" [RFC 6724], these are liste= d
here:

<hs> It is deliberate.=C2= =A0 If a host tracks prefixes advertised by a specific router, RFC 4861 and= RFC 4191 require a change which needs to be discussed.

1. Note RFC 6724 mentions "SA or SA's prefix".=C2=A0 This is = redundant for
=C2=A0 =C2=A0SLAAC-derived addresses

<hs= > Not quite.=C2=A0 Also, a renumbering takes place and Prefix A is adver= tised with reduced lifetime which eventually goes to zero.=C2=A0 Now each d= estination that matches Prefix A is off-link. =C2=A0=C2=A0Router A advertis= ed SA Prefix A and router B advertised SA Prefix B.=C2=A0 Now router select= ion is needed at the host.=C2=A0 What SLAAC address is used for SA requires= more work that a redundant "on-link" for any SLAAC prefix.=C2=A0=

but needs to be considered for DHCPv= 6 and
=C2=A0 =C2=A0admin-configured addresses.=C2=A0 If a router advertises a par= ticular
=C2=A0 =C2=A0prefix, addresses in that prefix SHOULD be preferred regardles= s of
=C2=A0 =C2=A0the mechanism used to configure them.
<hs>RFC4861 already covers a union of information from RA= and DHCPv6 for use by the host.=C2=A0 See section 6.3.4 in RFC4861 and thi= s text: "Hosts accept the union of all received information;"
=C2=A0

2. Neither L nor A bit in the Prefix Information Option (PIO) are
=C2=A0 =C2=A0specified anywhere to have an impact on source address selecti= on.
=C2=A0 =C2=A0Hosts SHOULD consider all PIOs regardless of L/A bit values fo= r the
=C2=A0 =C2=A0purposes of source address selection.
<hs> No. If the lifetime in the PIO is zero, more work is= needed to pick a source address.=C2=A0

3. When using non-default routes learned from Route Information Options, =C2=A0 =C2=A0hosts SHOULD apply the rules in the same manner, preferring so= urce
=C2=A0 =C2=A0addresses inside prefixes advertised by the nexthop of the spe= cific
=C2=A0 =C2=A0route used.

<hs>Mino= r comment first.=C2=A0 IPv6 ND has no concept of a default route.=C2=A0 ND = specifies a default router for the link. =C2=A0 The text in this item 3 is = not needed.=C2=A0 When a packet is to be sent out, the host performs a long= est prefix match of the packet destination with prefixes in the Prefix List= .=C2=A0 If a match is found, the next-hop is the packet destination.=C2=A0 = If not, the packet is forwarded to the default router. =C2=A0 If the host s= upports RFC 4191, the rules are already specified in RFC 4191 for routing t= able.

4. Routers MAY advertise more than one prefix (e.g. during renumbering), =C2=A0 =C2=A0which hosts SHOULD honor up to a limit imposed by security
=C2=A0 =C2=A0considerations.

<hs>= Already covered in RFC 4861 and RFC 4862.=C2=A0 See section 5.5.4 in RFC 4= 862 and sections 6.3.5 and 12 in RFC 4861.=C2=A0

5. More than one router MAY advertise the same prefix.=C2=A0 In particular,=
=C2=A0 =C2=A0homenet routers implementing RFCs 7695 and 7788 will exhibit t= his
=C2=A0 =C2=A0behaviour by default and in normal operation.=C2=A0 Hosts SHOU= LD be able
=C2=A0 =C2=A0to correctly retain identical prefixes for multiple routers, u= p to a
=C2=A0 =C2=A0limit imposed by security considerations.

<hs> Could you please provide specific text and= sections from the homenet RFCs to show why multiple routers advertise the = same prefix and what is the reason for doing so.=C2=A0 A topology diagram w= ould help - maybe the diagram exists in a homenet doc. =C2=A0 Then we can d= iscuss.=C2=A0

6. A router MAY choose to include prefix information only in some of its =C2=A0 =C2=A0RAs, for example when the sum of RA options exceeds the link&#= 39;s MTU.
=C2=A0 =C2=A0A host MUST NOT rely on all RAs including all information.=C2= =A0 This also
=C2=A0 =C2=A0means a host MUST NOT implement rule 5.5 by keeping a copy of = the
=C2=A0 =C2=A0last RA packet, as that packet may not have all information.

<hs> Section 6.3.4 of RFC 4861 alr= eady covers such details and thus Rule 5.5 of RFC 6724 is fine. =C2=A0

7. Entries on a router's list of advertised prefixes need to be expired=
=C2=A0 =C2=A0using the prefix's (TBD: valid or preferred?) lifetime.=C2= =A0 Hosts SHOULD
=C2=A0 =C2=A0apply the same rules regarding lifetimes as if they were confi= guring
=C2=A0 =C2=A0an address from that prefix.

<hs> It is the Preferred Lifetime.=C2=A0 RFC 4862 already includes= the behavior you describe above for SLAAC addresses.=C2=A0 DHCPv6 has addr= ess renew mechanisms to refresh address before the address expires. =C2=A0 = I don't see a need to text in item 7 above. =C2=A0

8. A host MAY dismiss a router's list of advertised prefixes if all
=C2=A0 =C2=A0routes via that router expire. If a host does so, it MUST ensu= re
=C2=A0 =C2=A0that additional routes learned from Route Information Options = cause
=C2=A0 =C2=A0it to retain the list even if the default route expires (i.e. = had a
=C2=A0 =C2=A0lower lifetime), or is not added to begin with.

<hs> Text is not needed.=C2=A0 Section 6.3.5 cl= ears specifies how to timeout entries in the Prefix List and the Default Ro= uter List.=C2=A0

9. Hosts MUST NOT use link-layer addresses to identify routers.=C2=A0 Not =C2=A0 =C2=A0only is this information unreliable on some media (e.g. 802.11= with
=C2=A0 =C2=A0aggressive controller-based optimizations), but it also confli= cts
=C2=A0 =C2=A0with (future) approaches to exploit rule 5.5 for multihoming =C2=A0 =C2=A0scenarios.=C2=A0 Hosts MUST use IPv6 link-local addresses to i= dentify
=C2=A0 =C2=A0routers for this purpose.

<hs> If the RA includes a Source Link-layer add= ress via the Source Link-layer address Option (SLAO), the host is legal to = use the link-layer address.=C2=A0 If a link does not use Source Link-layer = address, then no SLAO is included in the RA. =C2=A0 How is a packet forward= ed by the host to the default router if the host does not know the link-lay= er address of the default router? =C2=A0 =C2=A0More details on 802.11 optim= izations are needed before the text in item 9 is considered. =C2=A0
=C2=A0
10. Hosts SHOULD retain prefix information even if they have no address
=C2=A0 =C2=A0 inside that prefix.=C2=A0 Not doing so delays the application= of improved
=C2=A0 =C2=A0 source address selection for DHCPv6 and admin-configured addr= esses
=C2=A0 =C2=A0 until the next receipt of a RA packet.=C2=A0 This can be visi= ble to the
=C2=A0 =C2=A0 user as a temporary period of failed service, or, if RAs are<= br> =C2=A0 =C2=A0 infrequent, be interpreted as entirely broken connectivity.
<hs> A better model exists if the hosts only us= e DHCPv6.=C2=A0 The router sends an RA with no PIO with the M and O bits se= t, =C2=A0Thus hosts have all non-link-local destinations as off-link. =C2= =A0=C2=A0

section: Security Considerations

Retaining additional information from router advertisements opens hosts
to another avenue of memory exhaustion attacks by malicious on-link
hosts.=C2=A0 Implementations MUST cap the amount of data retained.

<hs> RFC 4861, in section 5.3 already says &quo= t;However, a node may<= /span>=C2=A0garbage-co= llect entries prematurely if it is low on memory." =C2=A0
=

section: Privacy Considerations

If hosts incorrectly mix prefix information across multiple interfaces,
it becomes possible for malicious on-link hosts (or routers) to
enumerate all of a host's IPv6 addresses.=C2=A0 Hosts therefore MUST ke= ep
this information strictly scoped to the respective interface.

<hs> IPv6 ND and SLAAC are protocols that work= for a specific interface.=C2=A0 Thus this information is blatantly clear.= =C2=A0 If host mix information, it's a bug in the host implementation t= o fix.=C2=A0 No new text to IETF RFCs is needed. =C2=A0

Routers generally gain a method of insight into a host's addresses.
This extends existing considerations applying to rogue RAs.=C2=A0 The probl= em
is particularly relevant on link layers where the broadcast domain is
shattered into non-transitive subdomains (e.g. Private VLANs [RFC
5517]).=C2=A0 Even if RAs are secured in some way, privacy is not provided<= br> between multiple routers on the same link.

<hs>Again, the RA is promiscuous for a specific private VLAN domain.= =C2=A0 It is clear and obvious information.=C2=A0

=
Hemant=C2=A0
=C2=A0

--001a113cc7dc8b09820538a77a17-- From nobody Thu Jul 28 05:25:32 2016 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6A1F212D875; Thu, 28 Jul 2016 05:25:30 -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 RfnhRCyvdKom; Thu, 28 Jul 2016 05:25:28 -0700 (PDT) Received: from mail-oi0-x232.google.com (mail-oi0-x232.google.com [IPv6:2607:f8b0:4003: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 CE17812D828; Thu, 28 Jul 2016 05:25:28 -0700 (PDT) Received: by mail-oi0-x232.google.com with SMTP id l72so60364562oig.2; Thu, 28 Jul 2016 05:25:28 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=Q4XlxQScRg7SMa0rJPuqpVLXDyGyKkJc9z+PFbXfaLo=; b=Fb+ihLhUED+yw4aOfLrxX+9FXb/5ajiCXIYoP3JAcT5aVPkA6jF4sQUR4IXhRiClnW LbHhWqbWdmyBU/Pgg4smQBuOIwH7EQ6kT8fP7lYO7kURxY8W4mThylkcGxRtxbK3IzbG 9Wrml0PprxF9pWMgcZYZCU3RptMahBGN0ycbqqP91Bud7d1cSQ//V5ICRZA4oIAgmR1P gAXHRitRx80TZfnyQGSGjmNH587MdxG7f5FWpoTKb6ug15VFmPXIykoiG2NPS2MN6+mJ b0ygG3DcP0vAN2YuVhZhMKqZGXFXP/OCYhiBwEcekAMl30EPjUKVJU9/HMVGtqpYNKjc khPw== 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=Q4XlxQScRg7SMa0rJPuqpVLXDyGyKkJc9z+PFbXfaLo=; b=F+Q7BmK14/d3D6d7Npyan8whNnERIdui9l9DJp5YAsvqqVs5xsUJB+Fpa4kncSNr8b H1MOBR8AQHnsktVEvz+Bh3fvGVSd6ekhdghCapsiLwr1acId7khcP4+X6aw8Ulsh6+SO IImR8P/Zs/1CjWGyFKvLPN7IpkswBeRFhSE1TiuOQL6geeWB8XPbHfbhRHC4CEU6dLwC GB/Uh3t2pCTOJt9q6rJfb0mM2kAcZA+o0DfeF4KgoxbgbpRcbpP2LCT36kun5a28gFQS /zQKQxikMJLUg7Tr0u70qyFZDl+xOwvMSfeU2MfjDjRPCfEmAxXLK+4HAnr5/JdUgZmQ GlIA== X-Gm-Message-State: AEkooutH8kyRzP2fkz3HK4/adAY+lgrRMO2R+F/zEFkPhhgFi75+07zttdh3wWCrw7sNkY0QKfOlnx2CI23blA== X-Received: by 10.202.253.149 with SMTP id b143mr20948539oii.34.1469708728292; Thu, 28 Jul 2016 05:25:28 -0700 (PDT) MIME-Version: 1.0 Received: by 10.182.188.4 with HTTP; Thu, 28 Jul 2016 05:25:27 -0700 (PDT) In-Reply-To: <43025435-75bf-4334-b315-aaf964c1a40a@gmail.com> References: <20160706005825.22318.33162.idtracker@ietfa.amsl.com> <1D424B70-9241-453D-85FF-A296A4DCE653@cisco.com> <20160720125458.GO255916@eidolon> <0b8fe558-768f-6407-6a58-26df0f3817c6@gmail.com> <20160720143410.GS255916@eidolon> <20160727194923.GG996866@eidolon> <43025435-75bf-4334-b315-aaf964c1a40a@gmail.com> From: Hemant Singh Date: Thu, 28 Jul 2016 08:25:27 -0400 Message-ID: Subject: Re: [v6ops] RFC 6724 rule 5.5 implementation guidance To: Brian E Carpenter Content-Type: multipart/alternative; boundary=001a113de8d2ac75380538b13aef Archived-At: Cc: Praveen Balasubramanian , "v6ops@ietf.org" , 6man <6man@ietf.org>, Suresh Krishnan X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.17 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 Jul 2016 12:25:30 -0000 --001a113de8d2ac75380538b13aef Content-Type: text/plain; charset=UTF-8 Brian/Fred, Does it make sense to add a new section towards the end of the draft below. The new section is titled "Changes to RFC 4861" and lists specific changes in the new section. Thanks, Hemant On Wed, Jul 27, 2016 at 4:19 PM, Brian E Carpenter < brian.e.carpenter@gmail.com> wrote: > David, > > > https://tools.ietf.org/html/draft-ietf-6man-multi-homed-host-03 > > > --001a113de8d2ac75380538b13aef Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Brian/Fred,

Does it make sense to add a= new section towards the end of the draft below.=C2=A0 The new section is t= itled "Changes to RFC 4861" and lists specific changes in the new= section.=C2=A0

Thanks,

H= emant

On Wed, = Jul 27, 2016 at 4:19 PM, Brian E Carpenter <brian.e.carpenter@gm= ail.com> wrote:
David,


https://tools.iet= f.org/html/draft-ietf-6man-multi-homed-host-03

--001a113de8d2ac75380538b13aef-- From nobody Thu Jul 28 16:24:23 2016 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2B00A12D989; Thu, 28 Jul 2016 16:24:18 -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 zrtNaosCnGsS; Thu, 28 Jul 2016 16:24:16 -0700 (PDT) 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 AE8AE12D091; Thu, 28 Jul 2016 16:24:16 -0700 (PDT) Received: by mail-pf0-x22e.google.com with SMTP id y134so26295030pfg.0; Thu, 28 Jul 2016 16:24:16 -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=VwfX8PmzTL8hdsLabwjjSbVgHp1pnZUi7EXlsK1CiXo=; b=dU3JiaBL/MZeamkZM+VUh5jFC64DZvIUN+7vGKfWCsHfh80c0jKbJJf98W7YiXUOMX zGmchiyvXOvBTz7cQw2Y9zGIkDK3wWZx8NM/Cpsi9CUYGvSHKI0UfPSZNAy+u90nJwoT MtnVxVz/WacRo8UcH6fgzLCuXdNiRLWETlhAKOJB6W+rVB8K0hqHgjiUMOCMkulllIc1 BX/PFPzMOhRFXWsTAqlzbtOmwapTJBEUhXfbyGGjcXEudsSZSpVHcSS1QazObc+SoMZK EiuUrpJMrFVu1EMax/TFQH6JXIqjGmeyFAgEhLBKmzjNQjPUZBZaUk71mV4Jg54N42eG LjPQ== 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=VwfX8PmzTL8hdsLabwjjSbVgHp1pnZUi7EXlsK1CiXo=; b=csx8TVZVbiQNZlsAEQWGeM/PlElRrTrraoGqQ+ySPbZ0ejLyEDUA3QJ4+6PSbpYMhr 7FThQS71yCVRJ6tt/7r2uX4AIiBtVNGQtBcFmfTDmC11aVjnMAwp06TiNHGbQjDG/sLF DOfXMNFnpPz+O2ANuQbQzJJD7O4EBH+OlGbSx7LY+3k9TbwaQmmiv6we0uP/sdlvOC5m oTK6fqI2oZktvaQS1z5zcZuwDLwl6Jtdwd2znr7sKoYnhAXvSeVdrE42cln2oF/yqxvY NIy2VdUFSCKrEpZX7STgX7d3RXQc/JHU+SRRZJn5PyOdsxdNAFKcKa3I+tA6RE3a0Ups GWIw== X-Gm-Message-State: AEkooutbphLm1Q+VofJubvQx5A0hBBYgWQ1O8C0Iju8vkD3lILQJFSJpn2y8p0He3lnK0w== X-Received: by 10.98.129.5 with SMTP id t5mr63314745pfd.32.1469748256299; Thu, 28 Jul 2016 16:24:16 -0700 (PDT) Received: from ?IPv6:2406:e007:5061:1:28cc:dc4c:9703:6781? ([2406:e007:5061:1:28cc:dc4c:9703:6781]) by smtp.gmail.com with ESMTPSA id q1sm19641845pfd.48.2016.07.28.16.24.13 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 28 Jul 2016 16:24:15 -0700 (PDT) Subject: Re: [v6ops] RFC 6724 rule 5.5 implementation guidance To: Hemant Singh References: <20160706005825.22318.33162.idtracker@ietfa.amsl.com> <1D424B70-9241-453D-85FF-A296A4DCE653@cisco.com> <20160720125458.GO255916@eidolon> <0b8fe558-768f-6407-6a58-26df0f3817c6@gmail.com> <20160720143410.GS255916@eidolon> <20160727194923.GG996866@eidolon> <43025435-75bf-4334-b315-aaf964c1a40a@gmail.com> From: Brian E Carpenter Organization: University of Auckland Message-ID: Date: Fri, 29 Jul 2016 11:24:20 +1200 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.2.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Archived-At: Cc: Praveen Balasubramanian , "v6ops@ietf.org" , 6man <6man@ietf.org>, Suresh Krishnan X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.17 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 Jul 2016 23:24:18 -0000 Hemant, On 29/07/2016 00:25, Hemant Singh wrote: > Brian/Fred, > > Does it make sense to add a new section towards the end of the draft > below. The new section is titled "Changes to RFC 4861" and lists specific > changes in the new section. We do say this in the Introduction: "Nevertheless, implementers of Sections 5.2, 6.2.3, 6.3.4 and 8 of RFC 4861 will need to extend their implementations accordingly." Is that specific enough? I think it's very hard to say more without making assumptions about individual implementations. (Reminder: the IETF Last Call on draft-ietf-6man-multi-homed-host expires 2016-08-04.) Regards Brian > > Thanks, > > Hemant > > On Wed, Jul 27, 2016 at 4:19 PM, Brian E Carpenter < > brian.e.carpenter@gmail.com> wrote: > >> David, >> >> >> https://tools.ietf.org/html/draft-ietf-6man-multi-homed-host-03 >> >> >> > From nobody Thu Jul 28 16:32:01 2016 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2513512D99A; Thu, 28 Jul 2016 16:31:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 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 5qEu9iwuYddu; Thu, 28 Jul 2016 16:31:54 -0700 (PDT) Received: from mail-oi0-x229.google.com (mail-oi0-x229.google.com [IPv6:2607:f8b0:4003:c06::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 D22E312D98E; Thu, 28 Jul 2016 16:31:53 -0700 (PDT) Received: by mail-oi0-x229.google.com with SMTP id w18so84804804oiw.3; Thu, 28 Jul 2016 16:31:53 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=ciH32M/CClTinkQ0k6jNhVhoOv1kmKcyivsWpEg3eDA=; b=Nsz/tMejAc8cgqicfHUrrQhIbnfTv8DEig5gYrS8HxmmqpOBRiuc7idwPWKdf/EJeX bixMA1IXXOLiWVpQRf/tvIWUtT+tvylbxGlc13L62b2Re2H7SIM0RT5yZzNERlUi4Gyb tLyW3LL2oOixArWYWZZxzJ7xZufeTpT6/0JF9CRH+OTMfbSiXCyChWX/sjrXj0ufOPQc Xqn2OwHfvDDnVWOdSkdc0znrhpJhOizOBjR4bm6FrrPFEPui9G29SwC46YTUS3vHexsQ Kyo8CImNizF4OqxV/YSET1cAMNOvjcWYQEI/utY2V2wjdjtZRvCaHWQCup5VGvnkkrGj 6c+g== 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=ciH32M/CClTinkQ0k6jNhVhoOv1kmKcyivsWpEg3eDA=; b=cR4+VryF+R5WAKDkPFprDHnyuUYY5UWB+oNLxrpTDYQXil2Ct5XJJ8vDANn+AiIL2u mwxzxsm4Iy02MTyN6n+Bw2ojGyFd1/UL+hKwc6M8NT7/uIEdPaVuDcZVFkLl4ogi+Vne rlmdPDFjpJpGyM992s6fI4p96IZ/DCFoA43t9FuFIYcVPTkj4oF8WcIuT4pZZGCnlKyb 44FbtH/bQt57gbXe+vbTkO/m59A4Wz6p5KDETVx7k0bLygP1/5EhElneHZWBqNAEMbmH KMOumyuRNsFpMAhtwvxcG9S4igRAsCPxbhShnzKV6qem+u1g4bK2y32xzjViV1Y7jijg VtPw== X-Gm-Message-State: AEkooutQESuI5PjHNiu+Vt1Z8pk57/AQ03fGIQ4YhiMNbS+GJShZkNM0r29rGMUoeWkXKXwsOuc9pwuaAaRS1g== X-Received: by 10.157.34.201 with SMTP id y67mr22279210ota.138.1469748713306; Thu, 28 Jul 2016 16:31:53 -0700 (PDT) MIME-Version: 1.0 Received: by 10.182.188.4 with HTTP; Thu, 28 Jul 2016 16:31:52 -0700 (PDT) In-Reply-To: References: <20160706005825.22318.33162.idtracker@ietfa.amsl.com> <1D424B70-9241-453D-85FF-A296A4DCE653@cisco.com> <20160720125458.GO255916@eidolon> <0b8fe558-768f-6407-6a58-26df0f3817c6@gmail.com> <20160720143410.GS255916@eidolon> <20160727194923.GG996866@eidolon> <43025435-75bf-4334-b315-aaf964c1a40a@gmail.com> From: Hemant Singh Date: Thu, 28 Jul 2016 19:31:52 -0400 Message-ID: Subject: Re: [v6ops] RFC 6724 rule 5.5 implementation guidance To: Brian E Carpenter Content-Type: multipart/alternative; boundary=94eb2c0332a6f745e20538ba894d Archived-At: Cc: Praveen Balasubramanian , "v6ops@ietf.org" , 6man <6man@ietf.org>, Suresh Krishnan X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.17 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 Jul 2016 23:31:55 -0000 --94eb2c0332a6f745e20538ba894d Content-Type: text/plain; charset=UTF-8 Brian, Ok, works for me - we can skip adding the new section. Thanks to you and Fred for working on this doc. Hemant On Thu, Jul 28, 2016 at 7:24 PM, Brian E Carpenter < brian.e.carpenter@gmail.com> wrote: > Hemant, > > > We do say this in the Introduction: > "Nevertheless, implementers of Sections 5.2, 6.2.3, 6.3.4 and 8 of RFC > 4861 will need to extend their implementations accordingly." > Is that specific enough? I think it's very hard to say more without > making assumptions about individual implementations. > > (Reminder: the IETF Last Call on draft-ietf-6man-multi-homed-host expires > 2016-08-04.) > > Regards > Brian > > --94eb2c0332a6f745e20538ba894d Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

Brian,

Ok, works for me - we can = skip adding the new section.=C2=A0 Thanks to you and Fred for working on th= is doc.

Hemant


On Thu, Jul 28, 2016 at 7:24 PM, Brian E = Carpenter <brian.e.carpenter@gmail.com> wrote:
=
Hemant,


We do say this in the Introduction:
"Nevertheless, implementers of Sections 5.2, 6.2.3, 6.3.4 and 8 of RFC=
4861 will need to extend their implementations accordingly."
Is that specific enough? I think it's very hard to say more without
making assumptions about individual implementations.

(Reminder: the IETF Last Call on draft-ietf-6man-multi-homed-host expires 2= 016-08-04.)

Regards
=C2=A0 =C2=A0 Brian

--94eb2c0332a6f745e20538ba894d-- From nobody Thu Jul 28 20:36:41 2016 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 837C912D7E7; Thu, 28 Jul 2016 20:36:39 -0700 (PDT) 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, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001] 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 PxDH3E3Jd4-4; Thu, 28 Jul 2016 20:36:38 -0700 (PDT) Received: from usplmg20.ericsson.net (usplmg20.ericsson.net [198.24.6.45]) (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 1790112D5E7; Thu, 28 Jul 2016 20:36:38 -0700 (PDT) X-AuditID: c618062d-980fb98000000a08-21-579acf70604b Received: from EUSAAHC006.ericsson.se (Unknown_Domain [147.117.188.90]) by (Symantec Mail Security) with SMTP id 4B.15.02568.07FCA975; Fri, 29 Jul 2016 05:37:20 +0200 (CEST) Received: from EUSAAMB107.ericsson.se ([147.117.188.124]) by EUSAAHC006.ericsson.se ([147.117.188.90]) with mapi id 14.03.0301.000; Thu, 28 Jul 2016 23:30:19 -0400 From: Suresh Krishnan To: Brian E Carpenter , David Lamparter , 6man <6man@ietf.org> Subject: Re: RFC 6724 rule 5.5 implementation guidance Thread-Topic: RFC 6724 rule 5.5 implementation guidance Thread-Index: AQHR6EQfqWT8cYqVCk+WGMHdBIsRjg== Date: Fri, 29 Jul 2016 03:30:18 +0000 Message-ID: References: <20160706005825.22318.33162.idtracker@ietfa.amsl.com> <1D424B70-9241-453D-85FF-A296A4DCE653@cisco.com> <20160720125458.GO255916@eidolon> <0b8fe558-768f-6407-6a58-26df0f3817c6@gmail.com> <20160720143410.GS255916@eidolon> <20160727194923.GG996866@eidolon> <43025435-75bf-4334-b315-aaf964c1a40a@gmail.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [147.117.188.12] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFprCIsWRmVeSWpSXmKPExsUyuXRPlG7B+VnhBgv2S1isXHGXyaLt4j4m izWNG5gt3q87w2Zx8vAcJov1p98xWrzuecxocfrYXmYHDo8pvzeyenzZK+Wxc9Zddo8Fm0o9 liz5yeTRuuMvewBbFJdNSmpOZllqkb5dAlfGlDNzGQu6eSou73zE1sD4lrOLkZNDQsBE4vmk J2xdjFwcQgIbGCVW/nvEBOEsZ5S4+Oc8K0gVG1DVhp2fmUBsEYFCiUf/JoLZzALHGCV+7IsG sYUFzCQaF+xngagxl7jf9QHI5gCy9SSmvuMDCbMIqEpM2/aRHcTmFfCVaP04gxFi1wFmiRNv 17OBJBgFxCS+n1oDNV9c4taT+UwQlwpILNlznhnCFpV4+fgfK4StJDHn9TVmiHodiQW7P7FB 2NoSyxa+ZoZYJihxcuYTlgmMIrOQjJ2FpGUWkpZZSFoWMLKsYuQoLS7IyU03MtjECIyrYxJs ujsY70/3PMQowMGoxMOr4DErXIg1say4MvcQowQHs5IIr+pZoBBvSmJlVWpRfnxRaU5q8SFG aQ4WJXFesUeK4UIC6YklqdmpqQWpRTBZJg5OqQZGsakCG9RbGbccd173W0tTe63Z210rffcf 04/OiMiXYOBPvvX4d1b89mOlVscWRYTd6hS+NynlYlufmf73feU7Tj9JYuXt+JJ7P/rplcn1 k4zP39zramyyoG1iwH39M3tDVxks337+R2Pdqesrjx9d0Rzvsmibl+f7JTPSC9arnXe/P2XC 8V8n9yqxFGckGmoxFxUnAgAYT2V5pwIAAA== Archived-At: Cc: Praveen Balasubramanian , "v6ops@ietf.org" , Jen Linkova , "Fred Baker \(fred\)" X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.17 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 Jul 2016 03:36:39 -0000 Hi Brian,=0A= =0A= On 07/27/2016 04:19 PM, Brian E Carpenter wrote:=0A= > David,=0A= >=0A= > On 28/07/2016 07:49, David Lamparter wrote:=0A= >> On Thu, Jul 21, 2016 at 07:25:45PM +1200, Brian E Carpenter wrote:=0A= >>> On 21/07/2016 02:34, David Lamparter wrote:=0A= >>>> On Thu, Jul 21, 2016 at 01:22:15AM +1200, Brian E Carpenter wrote:=0A= >>>>> Please tell us ASAP if there is anything we should add to=0A= >>>>> https://tools.ietf.org/html/draft-ietf-6man-multi-homed-host-03#secti= on-3.2=0A= >>>>> or thereabouts.=0A= >>=0A= >> I believe we need to ship the following text (or something similar)=0A= >> /somewhere/:=0A= >=0A= > I like what you wrote. I don't think such eminently practical information= =0A= > fits very well into IETF documents but I'd be interested in other opionio= ns.=0A= > draft-ietf-6man-multi-homed-host is in IETF LC and already on the IESG ag= enda,=0A= > so if we should add this sort of material Suresh had better tell us to=0A= > do so rather soon. One specific comment below...=0A= =0A= I agree with your assessment that this is closely tied to implementation = =0A= details and does not belong here, but I am also fine if you would like to a= dd =0A= some form of generic explanatory text in this regard. Feel free to discuss = =0A= text proposals until the IETF Last Call completes. If there are no other La= st =0A= Call comments we can handle this text addition along with any that are =0A= necessitated by IESG evaluation.=0A= =0A= Thanks=0A= Suresh=0A= =0A= =0A=